Quantcast

RE: fsl-dcu not works on latest "drm-next"

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: fsl-dcu not works on latest "drm-next"

Meng Yi-2
I found that its regmap endianness issue, so I want to replace the "regmap".

Hi Stefan,
Do you have any idea about this?

Hi Mark,
Regmap endianness issue had caused some other drivers not work, like SPI etc.
Or this is fixed and I just don't know?

Thanks,
Meng

---------------------------------------------------------------------
From: Meng Yi
Sent: Tuesday, May 03, 2016 5:27 PM
To: '[hidden email]' <[hidden email]>; David Airlie <[hidden email]>; 'Stefan Agner' <[hidden email]>; '[hidden email]' <[hidden email]>
Subject: fsl-dcu not works on latest "drm-next"

Hi,


I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr, and got some log below. And fsl-dcu not works.

Since "drm-next" merged some branch , use git bisect had some problem ,

so I manually checked out that "fsl-dcu" works at d761701c55a99598477f3cb25c03d939a7711e74

And not works now. some log below:

--------------------------------------------------------------------

[drm] Initialized drm 1.1.0 20060810
panel supply power not found, using dummy regulator
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1106 drm_atomic_helper_wait_for_vblanks+0xff/0x124
[CRTC:24] vblank wait timed out
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc3+ #189
Hardware name: Freescale LS1021A
[<80209a7b>] (unwind_backtrace) from [<8020755f>] (show_stack+0xb/0xc)
[<8020755f>] (show_stack) from [<803676a3>] (dump_stack+0x5b/0x74)
[<803676a3>] (dump_stack) from [<80211a37>] (__warn+0x87/0xb0)
[<80211a37>] (__warn) from [<80211a7f>] (warn_slowpath_fmt+0x1f/0x28)
[<80211a7f>] (warn_slowpath_fmt) from [<803ca887>] (drm_atomic_helper_wait_for_vblanks+0xff/0x124)
[<803ca887>] (drm_atomic_helper_wait_for_vblanks) from [<803cb307>] (drm_atomic_helper_commit+0x43/0x5c)
[<803cb307>] (drm_atomic_helper_commit) from [<803cbe51>] (restore_fbdev_mode+0xad/0x16e)
[<803cbe51>] (restore_fbdev_mode) from [<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x19/0x44)
[<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<803ccf9d>] (drm_fb_helper_set_par+0x25/0x38)
[<803ccf9d>] (drm_fb_helper_set_par) from [<80397451>] (fbcon_init+0x1fd/0x2c0)
[<80397451>] (fbcon_init) from [<803b6051>] (visual_init+0x71/0xb4)
[<803b6051>] (visual_init) from [<803b6f95>] (do_bind_con_driver+0x105/0x1e4)
[<803b6f95>] (do_bind_con_driver) from [<803b7287>] (do_take_over_console+0xcf/0x108)
[<803b7287>] (do_take_over_console) from [<80397549>] (do_fbcon_takeover+0x35/0x7c)
[<80397549>] (do_fbcon_takeover) from [<802229db>] (notifier_call_chain+0x23/0x38)
[<802229db>] (notifier_call_chain) from [<80222b63>] (__blocking_notifier_call_chain+0x27/0x36)
[<80222b63>] (__blocking_notifier_call_chain) from [<80222b81>] (blocking_notifier_call_chain+0xf/0x14)
[<80222b81>] (blocking_notifier_call_chain) from [<8039bdf9>] (register_framebuffer+0x179/0x1d0)
[<8039bdf9>] (register_framebuffer) from [<803cd15f>] (drm_fb_helper_initial_config+0x1af/0x200)
[<803cd15f>] (drm_fb_helper_initial_config) from [<803cd593>] (drm_fbdev_cma_init+0x67/0xa8)
[<803cd593>] (drm_fbdev_cma_init) from [<803e2269>] (fsl_dcu_fbdev_init+0x11/0x14)
[<803e2269>] (fsl_dcu_fbdev_init) from [<803e18eb>] (fsl_dcu_load+0x81/0xba)
[<803e18eb>] (fsl_dcu_load) from [<803d2d51>] (drm_dev_register+0x3d/0x68)
[<803d2d51>] (drm_dev_register) from [<803e1ab7>] (fsl_dcu_drm_probe+0x193/0x240)
[<803e1ab7>] (fsl_dcu_drm_probe) from [<803e6d2d>] (platform_drv_probe+0x33/0x62)
[<803e6d2d>] (platform_drv_probe) from [<803e5e7d>] (driver_probe_device+0xb9/0x1a4)
[<803e5e7d>] (driver_probe_device) from [<803e5fad>] (__driver_attach+0x45/0x58)
[<803e5fad>] (__driver_attach) from [<803e4eeb>] (bus_for_each_dev+0x3b/0x46)
[<803e4eeb>] (bus_for_each_dev) from [<803e5897>] (bus_add_driver+0x7b/0x138)
[<803e5897>] (bus_add_driver) from [<803e6469>] (driver_register+0x4b/0x76)
[<803e6469>] (driver_register) from [<80201517>] (do_one_initcall+0xb3/0x138)
[<80201517>] (do_one_initcall) from [<80800a61>] (kernel_init_freeable+0xd1/0x168)
[<80800a61>] (kernel_init_freeable) from [<80558d13>] (kernel_init+0x7/0xb4)
[<80558d13>] (kernel_init) from [<80205261>] (ret_from_fork+0x11/0x30)
---[ end trace b7946726c4e290c4 ]---
Console: switching to colour frame buffer device 60x34
fsl-dcu 2ce0000.dcu: fb0:  frame buffer device
[drm] Initialized fsl-dcu-drm 1.1.0 20160425 on minor 0


And full log in the attachment.

does anybody have any idea about this?

Best Regards,
Meng Yi

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: fsl-dcu not works on latest "drm-next"

Stefan Agner
On 2016-05-24 19:14, Meng Yi wrote:
> I found that its regmap endianness issue, so I want to replace the "regmap".
Hm, replace with what? Note that we need some kind of endianness
convertion since the IP is big endian on LS1021a and little endian on
Vybrid (vf610).

Is it maybe just an issue with regmap/the big-endian property in the
device tree? Maybe this thread is interesting for you:
https://lkml.org/lkml/2016/3/23/233

[adding Alexander Stein, he might be able to tell more about this issue]

--
Stefan

>
> Hi Stefan,
> Do you have any idea about this?
>
> Hi Mark,
> Regmap endianness issue had caused some other drivers not work, like SPI etc.
> Or this is fixed and I just don't know?
>
> Thanks,
> Meng
>
> ---------------------------------------------------------------------
> From: Meng Yi
> Sent: Tuesday, May 03, 2016 5:27 PM
> To: '[hidden email]'
> <[hidden email]>; David Airlie <[hidden email]>;
> 'Stefan Agner' <[hidden email]>; '[hidden email]'
> <[hidden email]>
> Subject: fsl-dcu not works on latest "drm-next"
>
> Hi,
>
>
> I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr,
> and got some log below. And fsl-dcu not works.
>
> Since "drm-next" merged some branch , use git bisect had some problem ,
>
> so I manually checked out that "fsl-dcu" works at
> d761701c55a99598477f3cb25c03d939a7711e74
>
> And not works now. some log below:
>
> --------------------------------------------------------------------
>
> [drm] Initialized drm 1.1.0 20060810
> panel supply power not found, using dummy regulator
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] No driver support for vblank timestamp query.
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1106
> drm_atomic_helper_wait_for_vblanks+0xff/0x124
> [CRTC:24] vblank wait timed out
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc3+ #189
> Hardware name: Freescale LS1021A
> [<80209a7b>] (unwind_backtrace) from [<8020755f>] (show_stack+0xb/0xc)
> [<8020755f>] (show_stack) from [<803676a3>] (dump_stack+0x5b/0x74)
> [<803676a3>] (dump_stack) from [<80211a37>] (__warn+0x87/0xb0)
> [<80211a37>] (__warn) from [<80211a7f>] (warn_slowpath_fmt+0x1f/0x28)
> [<80211a7f>] (warn_slowpath_fmt) from [<803ca887>]
> (drm_atomic_helper_wait_for_vblanks+0xff/0x124)
> [<803ca887>] (drm_atomic_helper_wait_for_vblanks) from [<803cb307>]
> (drm_atomic_helper_commit+0x43/0x5c)
> [<803cb307>] (drm_atomic_helper_commit) from [<803cbe51>]
> (restore_fbdev_mode+0xad/0x16e)
> [<803cbe51>] (restore_fbdev_mode) from [<803ccf4d>]
> (drm_fb_helper_restore_fbdev_mode_unlocked+0x19/0x44)
> [<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked) from
> [<803ccf9d>] (drm_fb_helper_set_par+0x25/0x38)
> [<803ccf9d>] (drm_fb_helper_set_par) from [<80397451>] (fbcon_init+0x1fd/0x2c0)
> [<80397451>] (fbcon_init) from [<803b6051>] (visual_init+0x71/0xb4)
> [<803b6051>] (visual_init) from [<803b6f95>] (do_bind_con_driver+0x105/0x1e4)
> [<803b6f95>] (do_bind_con_driver) from [<803b7287>]
> (do_take_over_console+0xcf/0x108)
> [<803b7287>] (do_take_over_console) from [<80397549>]
> (do_fbcon_takeover+0x35/0x7c)
> [<80397549>] (do_fbcon_takeover) from [<802229db>]
> (notifier_call_chain+0x23/0x38)
> [<802229db>] (notifier_call_chain) from [<80222b63>]
> (__blocking_notifier_call_chain+0x27/0x36)
> [<80222b63>] (__blocking_notifier_call_chain) from [<80222b81>]
> (blocking_notifier_call_chain+0xf/0x14)
> [<80222b81>] (blocking_notifier_call_chain) from [<8039bdf9>]
> (register_framebuffer+0x179/0x1d0)
> [<8039bdf9>] (register_framebuffer) from [<803cd15f>]
> (drm_fb_helper_initial_config+0x1af/0x200)
> [<803cd15f>] (drm_fb_helper_initial_config) from [<803cd593>]
> (drm_fbdev_cma_init+0x67/0xa8)
> [<803cd593>] (drm_fbdev_cma_init) from [<803e2269>]
> (fsl_dcu_fbdev_init+0x11/0x14)
> [<803e2269>] (fsl_dcu_fbdev_init) from [<803e18eb>] (fsl_dcu_load+0x81/0xba)
> [<803e18eb>] (fsl_dcu_load) from [<803d2d51>] (drm_dev_register+0x3d/0x68)
> [<803d2d51>] (drm_dev_register) from [<803e1ab7>]
> (fsl_dcu_drm_probe+0x193/0x240)
> [<803e1ab7>] (fsl_dcu_drm_probe) from [<803e6d2d>]
> (platform_drv_probe+0x33/0x62)
> [<803e6d2d>] (platform_drv_probe) from [<803e5e7d>]
> (driver_probe_device+0xb9/0x1a4)
> [<803e5e7d>] (driver_probe_device) from [<803e5fad>] (__driver_attach+0x45/0x58)
> [<803e5fad>] (__driver_attach) from [<803e4eeb>] (bus_for_each_dev+0x3b/0x46)
> [<803e4eeb>] (bus_for_each_dev) from [<803e5897>] (bus_add_driver+0x7b/0x138)
> [<803e5897>] (bus_add_driver) from [<803e6469>] (driver_register+0x4b/0x76)
> [<803e6469>] (driver_register) from [<80201517>] (do_one_initcall+0xb3/0x138)
> [<80201517>] (do_one_initcall) from [<80800a61>]
> (kernel_init_freeable+0xd1/0x168)
> [<80800a61>] (kernel_init_freeable) from [<80558d13>] (kernel_init+0x7/0xb4)
> [<80558d13>] (kernel_init) from [<80205261>] (ret_from_fork+0x11/0x30)
> ---[ end trace b7946726c4e290c4 ]---
> Console: switching to colour frame buffer device 60x34
> fsl-dcu 2ce0000.dcu: fb0:  frame buffer device
> [drm] Initialized fsl-dcu-drm 1.1.0 20160425 on minor 0
>
>
> And full log in the attachment.
>
> does anybody have any idea about this?
>
> Best Regards,
> Meng Yi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fsl-dcu not works on latest "drm-next"

Alexander Stein
On Tuesday 24 May 2016 23:20:02, Stefan Agner wrote:
> On 2016-05-24 19:14, Meng Yi wrote:
> > I found that its regmap endianness issue, so I want to replace the
> > "regmap".
> Hm, replace with what? Note that we need some kind of endianness
> convertion since the IP is big endian on LS1021a and little endian on
> Vybrid (vf610).

Yep, regmap is required and was broken meanwhile but should be fixed now. See
linked lkml post.

> Is it maybe just an issue with regmap/the big-endian property in the
> device tree? Maybe this thread is interesting for you:
> https://lkml.org/lkml/2016/3/23/233

AFAICT device tree should not been changed here. The "big-endian" property was
there fromt he beginning.

> > I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr,
> > and got some log below. And fsl-dcu not works.
> >
> > Since "drm-next" merged some branch , use git bisect had some problem ,
> >
> > so I manually checked out that "fsl-dcu" works at
> > d761701c55a99598477f3cb25c03d939a7711e74
> >
> > And not works now. some log below:

Which commit actually broke your kernel? And where to fetch it from? Is your
problem really caused by regmap?

Best regards,
Alexander

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: fsl-dcu not works on latest "drm-next"

Meng Yi-2
Hi Alexander,

> From: Alexander Stein [mailto:[hidden email]]
> Sent: Wednesday, May 25, 2016 4:32 PM
> To: Stefan Agner <[hidden email]>
> Cc: Meng Yi <[hidden email]>; [hidden email]; David Airlie
> <[hidden email]>; [hidden email]; [hidden email]; Mark
> Brown <[hidden email]>
> Subject: Re: fsl-dcu not works on latest "drm-next"
>
> On Tuesday 24 May 2016 23:20:02, Stefan Agner wrote:
> > On 2016-05-24 19:14, Meng Yi wrote:
> > > I found that its regmap endianness issue, so I want to replace the
> > > "regmap".
> > Hm, replace with what? Note that we need some kind of endianness
> > convertion since the IP is big endian on LS1021a and little endian on
> > Vybrid (vf610).
>
> Yep, regmap is required and was broken meanwhile but should be fixed now.
> See linked lkml post.
>
> > Is it maybe just an issue with regmap/the big-endian property in the
> > device tree? Maybe this thread is interesting for you:
> > https://lkml.org/lkml/2016/3/23/233
>
> AFAICT device tree should not been changed here. The "big-endian" property
> was there fromt he beginning.
>
> > > I just tested the latest drm-next branch on Freescale/NXP
> > > ls1021a-twr, and got some log below. And fsl-dcu not works.
> > >
> > > Since "drm-next" merged some branch , use git bisect had some
> > > problem ,
> > >
> > > so I manually checked out that "fsl-dcu" works at
> > > d761701c55a99598477f3cb25c03d939a7711e74
> > >
> > > And not works now. some log below:
>
> Which commit actually broke your kernel? And where to fetch it from? Is your
> problem really caused by regmap?

Since there are lots of merge commit, I had manually debugged that issue. And yes, it is caused by regmap.
I fetched the kernel from git://people.freedesktop.org/~airlied/linux

Best Regards,
Meng Yi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fsl-dcu not works on latest "drm-next"

Mark Brown-2
In reply to this post by Meng Yi-2
On Wed, May 25, 2016 at 02:14:09AM +0000, Meng Yi wrote:

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

> Regmap endianness issue had caused some other drivers not work, like SPI etc.
> Or this is fixed and I just don't know?

Without any description of the problem it is difficult to comment.
There were some drivers that were abusing the API by hacking round
things that need fixing (the main one I've seen is reporting things as
big endian instead of native endian to cause two layers of translation
to kick in) and one that was trying to use regmap to represent something
that just fundamentally wasn't a regmap so *any* change in regmap
internals was risky.

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fsl-dcu not works on latest "drm-next"

Alexander Stein
In reply to this post by Meng Yi-2
Hi,

On Wednesday 25 May 2016 08:58:31, Meng Yi wrote:

> > On Tuesday 24 May 2016 23:20:02, Stefan Agner wrote:
> > > On 2016-05-24 19:14, Meng Yi wrote:
> > > > I found that its regmap endianness issue, so I want to replace the
> > > > "regmap".
> > >
> > > Hm, replace with what? Note that we need some kind of endianness
> > > convertion since the IP is big endian on LS1021a and little endian on
> > > Vybrid (vf610).
> >
> > Yep, regmap is required and was broken meanwhile but should be fixed now.
> > See linked lkml post.
> >
> > > Is it maybe just an issue with regmap/the big-endian property in the
> > > device tree? Maybe this thread is interesting for you:
> > > https://lkml.org/lkml/2016/3/23/233
> >
> > AFAICT device tree should not been changed here. The "big-endian" property
> > was there fromt he beginning.
> >
> > > > I just tested the latest drm-next branch on Freescale/NXP
> > > > ls1021a-twr, and got some log below. And fsl-dcu not works.
> > > >
> > > > Since "drm-next" merged some branch , use git bisect had some
> > > > problem ,
> > > >
> > > > so I manually checked out that "fsl-dcu" works at
> > > > d761701c55a99598477f3cb25c03d939a7711e74
> >
> > > > And not works now. some log below:
> > Which commit actually broke your kernel? And where to fetch it from? Is
> > your problem really caused by regmap?
>
> Since there are lots of merge commit, I had manually debugged that issue.
> And yes, it is caused by regmap. I fetched the kernel from
> git://people.freedesktop.org/~airlied/linux

Commit d761701c55a99598477f3cb25c03d939a7711e74 only has one child commit in
my repo. Both touch only i915 related things. Please do a proper bisect and
name the offending commit. On which commit you got that backtrace BTW?
From your backtrace I can't see anything related to regmap.

Best regards,
Alexander

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: fsl-dcu not works on latest "drm-next"

Meng Yi-2
In reply to this post by Mark Brown-2

Hi Mark,

>
> Without any description of the problem it is difficult to comment.
> There were some drivers that were abusing the API by hacking round things
> that need fixing (the main one I've seen is reporting things as big endian
> instead of native endian to cause two layers of translation to kick in) and one
> that was trying to use regmap to represent something that just fundamentally
> wasn't a regmap so *any* change in regmap internals was risky.

I was testing HDMI patches on latest "drm-next" branch, and found that it is not work.
And then I found the base tree was not working too. Then I debugged the base tree.

I read out the value of relevant register using "CodeWarrior TAP", find that endianness is not right.

Then I changed endianness of the value to be written that using " regmap_write" . It works.
But "regmap_update_bits" still have the problem.

I had checked log of regmap, and didn't find which commit caused that.

I am not familiar with regmap, can you give some advices?

Thanks,
Best Regards,
Meng Yi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: fsl-dcu not works on latest "drm-next"

Meng Yi-2
In reply to this post by Alexander Stein
Hi Alexander,
Thanks for your reply.

> Commit d761701c55a99598477f3cb25c03d939a7711e74 only has one child
> commit in my repo. Both touch only i915 related things. Please do a proper
> bisect and name the offending commit. On which commit you got that
> backtrace BTW?
> From your backtrace I can't see anything related to regmap.
>

It is weird that using bisect, for the commit log is not linear.
I mean a newer date commit may be merged before an older date commit, when jump to that older date commit, the newer one will be lost, even though it is merged before older one.
So, I think it's difficult to use git bisect.
" d761701c55a99598477f3cb25c03d939a7711e74 " is just an older one, I mean between this commit and the next commit, maybe lots of commits are lost. So, it looks like this commit have nothing to do with the problem.

According to the backtrace, looks like the vblank interrupt is not happen or  handled.
Then I found the irq is installed successfully, so the problem seems like the vblank irq is not properly setup. And here is the point , irq initia, irq handler and timing control code are using regmap.

I read out the value of relevant register using "CodeWarrior TAP", find that endianness is not right.

Then I changed endianness of the value to be written that using " regmap_write" . It works.
But "regmap_update_bits" still have the problem.

I had checked log of regmap, and didn't find which commit caused that.

Since I am not familiar with regmap, hope you can give me some advice.

Thanks,
Best Regards,
Meng Yi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fsl-dcu not works on latest "drm-next"

Mark Brown-2
In reply to this post by Meng Yi-2
On Wed, May 25, 2016 at 09:59:39AM +0000, Meng Yi wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> I read out the value of relevant register using "CodeWarrior TAP", find that endianness is not right.

> Then I changed endianness of the value to be written that using " regmap_write" . It works.
> But "regmap_update_bits" still have the problem.

> I had checked log of regmap, and didn't find which commit caused that.

You've not specifically described the problem here - what are the
endiannesses of both the CPU and the device you're talking to?  What
specifically is the endianess problem you are seeing, what are you
seeing and what do you expect to see?

> I am not familiar with regmap, can you give some advices?

Is the device described in the DT or regmap_config as having the
endianess that it actually has?  

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fsl-dcu not works on latest "drm-next"

Alexander Stein
In reply to this post by Meng Yi-2
On Wednesday 25 May 2016 10:25:29, Meng Yi wrote:

> Hi Alexander,
> Thanks for your reply.
>
> > Commit d761701c55a99598477f3cb25c03d939a7711e74 only has one child
> > commit in my repo. Both touch only i915 related things. Please do a proper
> > bisect and name the offending commit. On which commit you got that
> > backtrace BTW?
> > From your backtrace I can't see anything related to regmap.
>
> It is weird that using bisect, for the commit log is not linear.
> I mean a newer date commit may be merged before an older date commit, when
> jump to that older date commit, the newer one will be lost, even though it
> is merged before older one. So, I think it's difficult to use git bisect.
> " d761701c55a99598477f3cb25c03d939a7711e74 " is just an older one, I mean
> between this commit and the next commit, maybe lots of commits are lost.
> So, it looks like this commit have nothing to do with the problem.

Why are commits lost? The order of commit dates is not straightforward, yes,
but that's not a problem at all.

> According to the backtrace, looks like the vblank interrupt is not happen or
>  handled. Then I found the irq is installed successfully, so the problem
> seems like the vblank irq is not properly setup. And here is the point ,
> irq initia, irq handler and timing control code are using regmap.

From your backtrace I guess wait_event_timeout is called in some atomic
context (might_sleep(); is called inside wait_event_timeout). This has nothing
to do with regmap.

> I read out the value of relevant register using "CodeWarrior TAP", find that
> endianness is not right.
>
> Then I changed endianness of the value to be written that using "
> regmap_write" . It works. But "regmap_update_bits" still have the problem.
>
> I had checked log of regmap, and didn't find which commit caused that.

The inital problem came up with 922a9f936e40001f9b921379aab90047d5990923
("regmap: mmio: Convert to regmap_bus and fix accessor usage"). The commits
9f9f8b863ad130ec0c25f378bdbad64ba71291de,
4f7d6dd4df8b388e2056c89b528254cdd79dea2a and
0dbdb76c0ca8e7caf27c9a210f64c4359e2974a4 tried to fix that. With those I could
successfully probe DCU.

Best regards,
Alexander

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: fsl-dcu not works on latest "drm-next"

Meng Yi-2
Hi Alexander,

> From your backtrace I guess wait_event_timeout is called in some atomic
> context (might_sleep(); is called inside wait_event_timeout). This has nothing
> to do with regmap.
>

Here is my view of point:
Since IRQ setup codes using regmap, and which is not setup properly, so wait_event_timeout.

>
> The inital problem came up with 922a9f936e40001f9b921379aab90047d5990923
> ("regmap: mmio: Convert to regmap_bus and fix accessor usage"). The
> commits 9f9f8b863ad130ec0c25f378bdbad64ba71291de,
> 4f7d6dd4df8b388e2056c89b528254cdd79dea2a and
> 0dbdb76c0ca8e7caf27c9a210f64c4359e2974a4 tried to fix that. With those I
> could successfully probe DCU.

Thanks for your information.
DCU was able to  be probed without those patches, and DCU still not works with those patches.

And here is my DTS and regmap_config,

Specified "big-endian" in DTS,

        dcu: dcu@2ce0000 {
            compatible = "fsl,ls1021a-dcu";
            reg = <0x0 0x2ce0000 0x0 0x10000>;
            interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
            clocks = <&platform_clk 0>;
            clock-names = "dcu";
            big-endian;
            status = "disabled";
        };

I can't tell the difference of "reg_format_endian" and " val_format_endian ", so I had tried four conditions.

static const struct regmap_config fsl_dcu_regmap_config = {
    .reg_bits = 32,
    .reg_stride = 4,
    .val_bits = 32,
    .cache_type = REGCACHE_RBTREE,
//  .reg_format_endian = REGMAP_ENDIAN_BIG,
//  .val_format_endian = REGMAP_ENDIAN_BIG,

    .volatile_reg = fsl_dcu_drm_is_volatile_reg,
};

Thanks,
Best Regards,
Meng Yi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: fsl-dcu not works on latest "drm-next"

Meng Yi-2
In reply to this post by Mark Brown-2
Hi Mark,

> You've not specifically described the problem here - what are the endiannesses
> of both the CPU and the device you're talking to?  What specifically is the
> endianess problem you are seeing, what are you seeing and what do you
> expect to see?
>

The CPU is little endian and the device DCU is big endian, specified big-endian in DTS,
       
And here is my DTS and regmap_config,

Specified "big-endian" in DTS,

        dcu: dcu@2ce0000 {
            compatible = "fsl,ls1021a-dcu";
            reg = <0x0 0x2ce0000 0x0 0x10000>;
            interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
            clocks = <&platform_clk 0>;
            clock-names = "dcu";
            big-endian;
            status = "disabled";
        };

I can't tell the difference of "reg_format_endian" and " val_format_endian ", so I had tried four conditions. And all failed.

static const struct regmap_config fsl_dcu_regmap_config = {
    .reg_bits = 32,
    .reg_stride = 4,
    .val_bits = 32,
    .cache_type = REGCACHE_RBTREE,
//  .reg_format_endian = REGMAP_ENDIAN_BIG, //  .val_format_endian = REGMAP_ENDIAN_BIG,

    .volatile_reg = fsl_dcu_drm_is_volatile_reg, };


I expect that regmap write as big endian, and I am seeing is regmap write as little endian.

Thanks,
Best Regards,
Meng Yi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fsl-dcu not works on latest "drm-next"

Alexander Stein
In reply to this post by Meng Yi-2
On Thursday 26 May 2016 08:18:30, Meng Yi wrote:

> Hi Alexander,
>
> > From your backtrace I guess wait_event_timeout is called in some atomic
> > context (might_sleep(); is called inside wait_event_timeout). This has
> > nothing to do with regmap.
>
> Here is my view of point:
> Since IRQ setup codes using regmap, and which is not setup properly, so
> wait_event_timeout.
> > The inital problem came up with 922a9f936e40001f9b921379aab90047d5990923
> > ("regmap: mmio: Convert to regmap_bus and fix accessor usage"). The
> > commits 9f9f8b863ad130ec0c25f378bdbad64ba71291de,
> > 4f7d6dd4df8b388e2056c89b528254cdd79dea2a and
> > 0dbdb76c0ca8e7caf27c9a210f64c4359e2974a4 tried to fix that. With those I
> > could successfully probe DCU.
>
> Thanks for your information.
> DCU was able to  be probed without those patches, and DCU still not works
> with those patches.

Yes, sure. DCU was probed fine before
922a9f936e40001f9b921379aab90047d5990923. But this introduced a regression for
DCU and also DSPI on LS1021A which got fixed by the other 3 named commits.
I didn't try to use DCU for a while, maybe there is another regression.
Please try reverting 2ed94f6fde066fb37bc3553b786edb805561699e
If that helps the device tree probing does not work in regmap_get_val_endian

Best regards,
Alexander

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fsl-dcu not works on latest "drm-next"

Alexander Stein
In reply to this post by Meng Yi-2
On Thursday 26 May 2016 08:23:42, Meng Yi wrote:

> Hi Mark,
>
> > You've not specifically described the problem here - what are the
> > endiannesses of both the CPU and the device you're talking to?  What
> > specifically is the endianess problem you are seeing, what are you seeing
> > and what do you expect to see?
>
> The CPU is little endian and the device DCU is big endian, specified
> big-endian in DTS,
>
> And here is my DTS and regmap_config,
>
> Specified "big-endian" in DTS,
>
>         dcu: dcu@2ce0000 {
>             compatible = "fsl,ls1021a-dcu";
>             reg = <0x0 0x2ce0000 0x0 0x10000>;
>             interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
>             clocks = <&platform_clk 0>;
>             clock-names = "dcu";
>             big-endian;
>             status = "disabled";
>         };
>
> I can't tell the difference of "reg_format_endian" and " val_format_endian
> ", so I had tried four conditions. And all failed.
>
> static const struct regmap_config fsl_dcu_regmap_config = {
>     .reg_bits = 32,
>     .reg_stride = 4,
>     .val_bits = 32,
>     .cache_type = REGCACHE_RBTREE,

This needs to be a flat cache. See https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html or https://lkml.org/lkml/2016/3/24/281
max_register also needs an appropriate value.

> //  .reg_format_endian = REGMAP_ENDIAN_BIG, //  .val_format_endian =
> REGMAP_ENDIAN_BIG,
>
>     .volatile_reg = fsl_dcu_drm_is_volatile_reg, };
>
>
> I expect that regmap write as big endian, and I am seeing is regmap write as
> little endian.

Check your actual regmap reg_write function.

Best regards,
Alexander

Loading...