Re: [UPDATED v4] WM97xx touchscreen drivers
On Tue, Feb 05, 2008 at 06:20:15PM -0500, [EMAIL PROTECTED] wrote: > > The expectation of this driver is that the battery monitor driver will > > register as the "wm97xx-battery" device and use the wm97xx_read_aux_adc() > > function exported by the wm97xx-core driver to access the ADC. Is your > > driver using this interface? > Yes, but this makes the wm97xx-battery device depend on configuring in the > touchscreen. Indeed. Could you expand on why this is a problem? > The problem we're having is that when we updated wm97xx-core.c from > version 0.62 to 0.65 the ADC values returned by wm97xx_read_aux_adc() to > the battery driver changed. We did modify both versions to make the Version 0.62 predates our git history so I don't have the old version to hand. I can't spot anything obvious in the information I do have except perhaps something introduced when the drivers were split to start pulling out the codec parts. > struct wm97xx * global so the battery monitor could pass it to > wm97xx_read_aux_adc() (is there a better way?). Well, other than using wm97xx-battery to find it not really. To be honest I don't really see what this buys you over using the battery device since what you suggest means you need to wait until it is registered anyway. > > The intention is that these drivers should be able to coexist with the > > existing ASoC drivers as-is. We do have existing users doing this - the > They don't just coexist with soc, they depend on it. If you configure out > the AC97 driver under soc the touchscreen and battery drivers won't work > (but they'll build). What sorts of problems are you seeing? I've done a very large proportion of my touchscreen work with ASoC completely disabled and haven't noticed any issues. In this case I was using the non-ASoC PXA AC97 driver (CONFIG_SND_AC97_CODEC, sound/arm/pxa2xx-ac97.c). Within ASoC it should be possible to use the generic AC97 codec driver but I can't say I've ever tested that. > We used the same architecture as tosa and retained > the OH guys for the app framework (and platform assistance - thanks RP :). OK, that's good - sounds like you're doing something fairly standard. > The first release is publicly available; the release I'm working on was > aimed for the 2.6.24 merge window but some key stuff (ARM clock/power > management, USB gadget) changed causing me to re-engineer. I'm still > troubleshooting some 2.6.18-->24 port issues here (pxa27x_ac97 errors on > resume - we use deep sleep, not sleep on the pxa270), but can publicize a > source tarball and send you the link. Yes, that'd be really helpful. I don't have the hardware so any non working stuff isn't going to affect me too much :) . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED v4] WM97xx touchscreen drivers
> The expectation of this driver is that the battery monitor driver will > register as the "wm97xx-battery" device and use the wm97xx_read_aux_adc() > function exported by the wm97xx-core driver to access the ADC. Is your > driver using this interface? Yes, but this makes the wm97xx-battery device depend on configuring in the touchscreen. The problem we're having is that when we updated wm97xx-core.c from version 0.62 to 0.65 the ADC values returned by wm97xx_read_aux_adc() to the battery driver changed. We did modify both versions to make the struct wm97xx * global so the battery monitor could pass it to wm97xx_read_aux_adc() (is there a better way?). > The intention is that these drivers should be able to coexist with the > existing ASoC drivers as-is. We do have existing users doing this - the > first publicly available example that springs to mind is tosa which > also uses the wm9712 with touchscreen and battery, together with the > ASoC driver for audio (the ASoC bits of this have been merged since ASoC > was merged in 2006, the other bits are out of tree partly due to the > fact that they depend on this driver). They don't just coexist with soc, they depend on it. If you configure out the AC97 driver under soc the touchscreen and battery drivers won't work (but they'll build). We used the same architecture as tosa and retained the OH guys for the app framework (and platform assistance - thanks RP :). > The most obvious way forward if we can't resolve these problems with the > existing scheme is to pull out the core driver as you say above - this > is the approach already taken by the touch drivers to allow battery > monitoring while the touchscreen is in use. > In my mind the wm97xx-core module is independent and exposes an API backed by wm9712/13/etc. Layered above that, built into their respective code areas, are the sound, touchscreen, battery monitor, various platform usage of the aux ADC channels, etc. I'm not saying this is possible, without caveat, or practical, but I would say academically ideal. Thanks for keeping the conversations going, as I appreciate these drivers moving into mainline which reduces our maintenance impact. > Is your kernel (or the wm9712-related code at least) publicly available? > If not would it be possible for you to share it with me off-list? It > might help me understand what's going on here. > The first release is publicly available; the release I'm working on was aimed for the 2.6.24 merge window but some key stuff (ARM clock/power management, USB gadget) changed causing me to re-engineer. I'm still troubleshooting some 2.6.18-->24 port issues here (pxa27x_ac97 errors on resume - we use deep sleep, not sleep on the pxa270), but can publicize a source tarball and send you the link. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED v4] WM97xx touchscreen drivers
On Mon, Feb 04, 2008 at 02:00:24PM -0500, [EMAIL PROTECTED] wrote: > Mark Brown wrote: > > This patch series adds support for the touchscreen controllers provided > > by Wolfson Microelectronics WM97xx series chips in both polled and > > streaming modes. > I integrated this patch with our 2.6.24 kernel and it broke our APM-based > battery monitor, which uses an ADC channel on the 9712. Support for this The expectation of this driver is that the battery monitor driver will register as the "wm97xx-battery" device and use the wm97xx_read_aux_adc() function exported by the wm97xx-core driver to access the ADC. Is your driver using this interface? > multi-function chip series seems to be in a few places; would it make > sense to have one generic WM97xx driver in drivers/mfd and stack the > codec, touchscreen, etc, drivers logically above (in their respective > areas)? The intention is that these drivers should be able to coexist with the existing ASoC drivers as-is. We do have existing users doing this - the first publicly available example that springs to mind is tosa which also uses the wm9712 with touchscreen and battery, together with the ASoC driver for audio (the ASoC bits of this have been merged since ASoC was merged in 2006, the other bits are out of tree partly due to the fact that they depend on this driver). > In my experience with the Wolfson series a change to the sound > driver breaks touchscreen, a change to the touchscreen driver changes ADC > readings, etc, I'm disappointed to hear that, particularly with the wm9712 since that especially has had a reasonable degree of testing with our drivers over a fairly long time period. >so I wanted to open dialog on what the right direction may > be as various Wolfson code starts making its way into the mainline. The most obvious way forward if we can't resolve these problems with the existing scheme is to pull out the core driver as you say above - this is the approach already taken by the touch drivers to allow battery monitoring while the touchscreen is in use. Is your kernel (or the wm9712-related code at least) publicly available? If not would it be possible for you to share it with me off-list? It might help me understand what's going on here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED v4] WM97xx touchscreen drivers
Mark Brown wrote: > This patch series adds support for the touchscreen controllers provided > by Wolfson Microelectronics WM97xx series chips in both polled and > streaming modes. > I integrated this patch with our 2.6.24 kernel and it broke our APM-based battery monitor, which uses an ADC channel on the 9712. Support for this multi-function chip series seems to be in a few places; would it make sense to have one generic WM97xx driver in drivers/mfd and stack the codec, touchscreen, etc, drivers logically above (in their respective areas)? In my experience with the Wolfson series a change to the sound driver breaks touchscreen, a change to the touchscreen driver changes ADC readings, etc, so I wanted to open dialog on what the right direction may be as various Wolfson code starts making its way into the mainline. Thanks, Pete MacKay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED v4] WM97xx touchscreen drivers
Mark Brown wrote: > This patch series adds support for the touchscreen controllers provided > by Wolfson Microelectronics WM97xx series chips in both polled and > streaming modes. > > Changes since last submission: > - Fix from Dmitry Baryshkov for build with CONFIG_PM. - Add the web > site to the MAINTAINERS entry. Thanks. This serie "worksforme". Is it going to be merged during this window? -- With best wishes Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
