Re: [alsa-devel] [PATCH 2/2] Add possibility to control the GPIO_STATUS shift
On Fri, Jul 17, 2009 at 10:01:16AM +0200, Marek Vasut wrote:
This patch allows tweaking the behaviour of GPIO_STATUS register shift quirk that's in wm97xx-core. The problem with GPIO_STATUS register being shifted by one doesn't appear on all hardware it seems and causes problems with accelerated touchscreen drivers on Palm hardware. Therefore an accelerated touchscreen driver can select if the shift is/isn't happening on the hardware.
Again, this isn't an ALSA patch.
I've done some checking internally and I'm very suspicous that what's going on here is actually the masking of some other bug elsewhere in the system. Which CPU are the systems you're observing this on using? There is at least one special case in the current code for GPIO register readbacks in the PXA AC97 driver code and there have been a number of interoperabilty issues in that area...
Dne Pá 17. července 2009 12:32:53 Mark Brown napsal(a):
On Fri, Jul 17, 2009 at 10:01:16AM +0200, Marek Vasut wrote:
This patch allows tweaking the behaviour of GPIO_STATUS register shift quirk that's in wm97xx-core. The problem with GPIO_STATUS register being shifted by one doesn't appear on all hardware it seems and causes problems with accelerated touchscreen drivers on Palm hardware. Therefore an accelerated touchscreen driver can select if the shift is/isn't happening on the hardware.
Again, this isn't an ALSA patch.
I've done some checking internally and I'm very suspicous that what's going on here is actually the masking of some other bug elsewhere in the system. Which CPU are the systems you're observing this on using? There is at least one special case in the current code for GPIO register readbacks in the PXA AC97 driver code and there have been a number of interoperabilty issues in that area...
About the mailer, same here, sending as attachment, sorry.
The CPU used is pxa270c5 and pxa270c0. The chip is WM1613 (seems to report itself as WM9712 though). Maybe it's correction in that chip? There's no datasheet available to it though.
On Fri, Jul 17, 2009 at 01:12:15PM +0200, Marek Vasut wrote:
The CPU used is pxa270c5 and pxa270c0. The chip is WM1613 (seems to report itself as WM9712 though). Maybe it's correction in that chip? There's no datasheet available to it though.
Ah, that is crucial information which you hadn't previously provided. If you rework the patch as adding support for WM1613 with the interface being one that enables a WM1613 mode rather than tweaking the GPIO offset that'd be OK.
Dne Pá 17. července 2009 13:22:15 Mark Brown napsal(a):
On Fri, Jul 17, 2009 at 01:12:15PM +0200, Marek Vasut wrote:
The CPU used is pxa270c5 and pxa270c0. The chip is WM1613 (seems to report itself as WM9712 though). Maybe it's correction in that chip? There's no datasheet available to it though.
Ah, that is crucial information which you hadn't previously provided. If you rework the patch as adding support for WM1613 with the interface being one that enables a WM1613 mode rather than tweaking the GPIO offset that'd be OK.
But how the heck am I supposed to detect it's wm1613 if it reports itself as wm9712 ? Apparently, on treo680 it reports itself as wm9713 (even better).
On Fri, Jul 17, 2009 at 01:26:08PM +0200, Marek Vasut wrote:
But how the heck am I supposed to detect it's wm1613 if it reports itself as wm9712 ? Apparently, on treo680 it reports itself as wm9713 (even better).
The same way your current patch does it. I'm just saying you should change the way the configuration is passed in so that it is clear that this is only useful for WM1613.
Dne Pá 17. července 2009 13:43:12 Mark Brown napsal(a):
On Fri, Jul 17, 2009 at 01:26:08PM +0200, Marek Vasut wrote:
But how the heck am I supposed to detect it's wm1613 if it reports itself as wm9712 ? Apparently, on treo680 it reports itself as wm9713 (even better).
The same way your current patch does it. I'm just saying you should change the way the configuration is passed in so that it is clear that this is only useful for WM1613.
But there might appear some other chips that have this issue.
On Fri, Jul 17, 2009 at 01:53:59PM +0200, Marek Vasut wrote:
Dne Pá 17. července 2009 13:43:12 Mark Brown napsal(a):
The same way your current patch does it. I'm just saying you should change the way the configuration is passed in so that it is clear that this is only useful for WM1613.
But there might appear some other chips that have this issue.
Then they can get handled the same way - it might be an idea to have the data that's passed in be a chip number to allow for this.
participants (2)
-
Marek Vasut -
Mark Brown