input: make mainstone-wm97xx.c depend on MACH_MAINSTONE instead of ARCH_PXA
Subsystems (4)
PATCH 1/1 input: make mainstone-wm97xx.c depend on MACH_MAINSTONE instead of ARCH_PXA
If this is totally mainstone specific.
--- drivers/input/touchscreen/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/input/touchscreen/Kconfig +1 -1
@@ -228,7 +228,7 @@ config TOUCHSCREEN_WM9713 config TOUCHSCREEN_WM97XX_MAINSTONE tristate "WM97xx Mainstone accelerated touch" - depends on TOUCHSCREEN_WM97XX && ARCH_PXA + depends on TOUCHSCREEN_WM97XX && MACH_MAINSTONE help Say Y here for support for streaming mode with WM97xx touchscreens on Mainstone systems.
Signature · 1 line
1.5.4.3
Eric,
Quoted 1 line · Eric Miao
If this is totally mainstone specific.
I had a quick glance at the driver, and I think it can be generalized to work on other PXA platforms with WM97xx codecs. If you'd like to I can try to enable it on EM-X270 to see if I'm right.
Quoted 18 lines
Signed-off-by Eric Miao <[email protected]>--- drivers/input/touchscreen/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)drivers/input/touchscreen/Kconfig +1
-1@@ -228,7 +228,7 @@ config TOUCHSCREEN_WM9713 config TOUCHSCREEN_WM97XX_MAINSTONE tristate "WM97xx Mainstone accelerated touch" - depends on TOUCHSCREEN_WM97XX && ARCH_PXA + depends on TOUCHSCREEN_WM97XX && MACH_MAINSTONE help Say Y here for support for streaming mode with WM97xx touchscreens on Mainstone systems.
Signature · 8 lines
Sincerely yours, Mike. ------------------------------------------------------------------- List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
Quoted 3 lines · Eric Miao
If this is totally mainstone specific.
Signed-off-by Eric Miao <[email protected]>
It is and it isn't. It's very thin and stands a reasonable chance of working with generic PXA systems - ideally at some point we will have the ability to pass platform data to AC97 devices which would let it run elsewhere. The driver was until very recently called pxa-wm97xx but renamed recently due to the fact that we can't assume it'll work on other things due to having the GPIO hookup hardcoded.
I'd rather let it be visible but I'm not *too* bothered either way.
Quoted 5 lines · Mark Brown
Quoted 3 lines · Eric Miao
If this is totally mainstone specific.
Signed-off-by Eric Miao <[email protected]>
Quoted 8 lines
It is and it isn't. It's very thin and stands a reasonable chance of working with generic PXA systems - ideally at some point we will have the ability to pass platform data to AC97 devices which would let it run elsewhere. The driver was until very recently called pxa-wm97xx but renamed recently due to the fact that we can't assume it'll work on other things due to having the GPIO hookup hardcoded.
I'd rather let it be visible but I'm not *too* bothered either way.
Mike Rapoport said it could be re-used for EM-X270, so I'd suggest this better to be PXA generic, and pass platform data as you advised.
Quoted 2 lines · Eric Miao
Mike Rapoport said it could be re-used for EM-X270, so I'd suggest this better to be PXA generic, and pass platform data as you advised.
Yeah, that's the ideal. Unfortunately passing platform data through AC97 is a bit of a can of worms :(
Quoted 7 lines · Mark Brown
Quoted 2 lines · Eric Miao
Mike Rapoport said it could be re-used for EM-X270, so I'd suggest this better to be PXA generic, and pass platform data as you advised.
Yeah, that's the ideal. Unfortunately passing platform data through AC97 is a bit of a can of worms :(
Probably something like the patch below may allow passing platform data at least for ASoC devices:
sound/soc/soc-core.c +4 -2
@@ -92,13 +92,15 @@ static int soc_ac97_dev_unregister(struct snd_soc_codec *codec)static void soc_ac97_device_release (struct device *dev){}/* register ac97 codec to bus */ -static int soc_ac97_dev_register (struct snd_soc_codec *codec) +static int soc_ac97_dev_register (struct snd_soc_device *socdev) { +struct snd_soc_codec *codec = socdev->codec;int err; codec->ac97->dev.bus = &ac97_bus_type; codec->ac97->dev.parent =NULL ; codec->ac97->dev.release = soc_ac97_device_release; + codec->ac97->dev.platform_data = socdev->dev->platform_data;snprintf (codec->ac97->dev.bus_id,BUS_ID_SIZE ,"%d-%d:%s" , codec->card->number,0 , codec->name);
@@ -1130,7 +1132,7 @@ int snd_soc_register_card(struct snd_soc_device *socdev)mutex_lock (&codec->mutex);#ifdef CONFIG_SND_SOC_AC97_BUS if (ac97) { - ret =soc_ac97_dev_register (codec); + ret =soc_ac97_dev_register (socdev);if (ret <0 ) {printk (KERN_ERR "asoc: AC97 device register failed\n" );snd_card_free (codec->card);
Quoted 5 lines
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
Signature · 2 lines
Sincerely yours, Mike.
Quoted 2 lines · Mike Rapoport
Probably something like the patch below may allow passing platform data at least for ASoC devices:
This needs to be something that can be used on all AC97 systems, not just ASoC ones (people use these devices on things like x86 too, for example). The last time someone proposed something to deal with this the ALSA maintainers were very reluctant to allow any sort of void * through the AC97 bus which stalled everything.
Quoted 3 lines · Eric Miao
If this is totally mainstone specific.
Signed-off-by Eric Miao <[email protected]>
Ok. Should probably be a -rc thing.