[RESEND][PATCH] ASoC: ams-delta: Convert to use snd_soc_register_card()
The old method of registering with the ASoC core by creating a
soc-audio platform device no longer works for Amstrad Delta sound card
after recent changes to drvdata handling (commit
0998d0631001288a5974afc0b2a5f568bcdecb4d, 'device-core: Ensure drvdata =
NULL when no driver is bound'.
Use snd_soc_register_card() method instead, as suggested by the ASoC
core generated warning message, and move both the card and codec
platform device registration to the arch board file where those belong.
Created and tested against linux-3.6-rc5.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
On Thu, 6 Sep 2012 15:36:35 Mark Brown wrote:
On Sat, Sep 01, 2012 at 11:09:18AM +0200, Janusz Krzysztofik wrote:
I see your point, however for now I can see no better way of referencing
the data (of type struct snd_soc_card) then passing it to
snd_soc_register_card(). But for this to work, I would have to register
successfully an ams-delta specific platform device first, not the soc-
audio. This, even if still done from the sound/soc/omap/ams-delta.c, not
from an arch board file, would require now not existing ams-delta ASoC
platform driver probe/remove callbacks at least. I'm still not convinced
if such modification would be acceptable in the middle of the rc cycle.
If there is a simpler, less intrusive way to do this, then sorry, I
still can't see it.
Like I already said just make it a static variable.
Mark,
Sorry, I was still not able to understand what you actually meant, and
to come out with a working fix other than I initially proposed. If what
I've prepared now is not acceptable as a fix, than hard luck, please
consider queueing it for 3.7, and 3.6 must go with Amstrad Delta sound
not working unless someone else is still able to fix it.
Tony,
Please give your ack on the arch/arm/mach-omap1 bits if acceptable. I
believe there should be no merge conflicts if this change goes through
sound/soc.
Thanks,
Janusz
arch/arm/mach-omap1/board-ams-delta.c | 12 ++
sound/soc/omap/ams-delta.c| 63 +++-
2 files changed, 42 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index c534698..5ab9c6b 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -444,16 +444,28 @@ static struct omap1_cam_platform_data
ams_delta_camera_platform_data = {
.lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
};
+static struct platform_device ams_delta_audio_device = {
+ .name = ams-delta-audio,
+ .id = -1,
+};
+
+static struct platform_device cx20442_codec_device = {
+ .name = cx20442-codec,
+ .id = -1,
+};
+
static struct platform_device *ams_delta_devices[] __initdata = {
latch1_gpio_device,
latch2_gpio_device,
ams_delta_kp_device,
ams_delta_camera_device,
+ ams_delta_audio_device,
};
static struct platform_device *late_devices[] __initdata = {
ams_delta_nand_device,
ams_delta_lcd_device,
+ cx20442_codec_device,
};
static void __init ams_delta_init(void)
diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c
index 7d4fa8e..7b18b74 100644
--- a/sound/soc/omap/ams-delta.c
+++ b/sound/soc/omap/ams-delta.c
@@ -575,56 +575,53 @@ static struct snd_soc_card ams_delta_audio_card = {
};
/* Module init/exit */
-static struct platform_device *ams_delta_audio_platform_device;
-static struct platform_device *cx20442_platform_device;
-
-static int __init ams_delta_module_init(void)
+static __devinit int ams_delta_probe(struct platform_device *pdev)
{
+ struct snd_soc_card *card = ams_delta_audio_card;
int ret;
- if (!(machine_is_ams_delta()))
- return -ENODEV;
-
- ams_delta_audio_platform_device =
- platform_device_alloc(soc-audio, -1);
- if (!ams_delta_audio_platform_device)
- return -ENOMEM;
+ card-dev = pdev-dev;
- platform_set_drvdata(ams_delta_audio_platform_device,
- ams_delta_audio_card);
-
- ret = platform_device_add(ams_delta_audio_platform_device);
- if (ret)
- goto err;
-
- /*
-* Codec platform device could be registered from elsewhere (board?),
-* but I do it here as it makes sense only if used with the card.
-*/
- cx20442_platform_device =
- platform_device_register_simple(cx20442-codec, -1, NULL, 0);
+ ret = snd_soc_register_card(card);
+ if (ret) {
+ dev_err(pdev-dev, snd_soc_register_card failed (%d)\n, ret);
+ card-dev = NULL;
+ return ret;
+ }
return 0;
-err:
- platform_device_put(ams_delta_audio_platform_device);
- return ret;
}
-late_initcall(ams_delta_module_init);
-static void __exit
Re: [RESEND][PATCH] ASoC: ams-delta: Convert to use snd_soc_register_card()
Mark, Please note we have an Ack from Tony. http://mailman.alsa-project.org/pipermail/alsa-devel/2012-September/055493.html Thanks, Janusz --- Subject: Re: [PATCH] ASoC: ams-delta: Convert to use snd_soc_register_card() Date: niedziela, 16 września 2012, 13:44:23 From: Tony Lindgren t...@atomide.com To: Janusz Krzysztofik jkrzy...@tis.icnet.pl Cc: Mark Brown broo...@opensource.wolfsonmicro.com, Liam Girdwood l...@ti.com, linux-omap@vger.kernel.org, linux-arm-ker...@lists.infradead.org, alsa-de...@alsa-project.org * Janusz Krzysztofik jkrzy...@tis.icnet.pl [120916 12:18]: Tony, Please give your ack on the arch/arm/mach-omap1 bits if acceptable. I believe there should be no merge conflicts if this change goes through sound/soc. Yes looks good to me: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: ams-delta: Convert to use snd_soc_register_card()
Dnia niedziela, 16 września 2012 21:17:03 Janusz Krzysztofik pisze:
The old method of registering with the ASoC core by creating a
soc-audio platform device no longer works for Amstrad Delta sound card
after recent changes to drvdata handling (commit
0998d0631001288a5974afc0b2a5f568bcdecb4d, 'device-core: Ensure drvdata =
NULL when no driver is bound'.
Use snd_soc_register_card() method instead, as suggested by the ASoC
core generated warning message, and move both the card and codec
platform device registration to the arch board file where those belong.
Hi Mark,
Is something wrong with this patch? Any chance for it to find its way into 3.7?
Thanks,
Janusz
Created and tested against linux-3.6-rc5.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
On Thu, 6 Sep 2012 15:36:35 Mark Brown wrote:
On Sat, Sep 01, 2012 at 11:09:18AM +0200, Janusz Krzysztofik wrote:
I see your point, however for now I can see no better way of referencing
the data (of type struct snd_soc_card) then passing it to
snd_soc_register_card(). But for this to work, I would have to register
successfully an ams-delta specific platform device first, not the soc-
audio. This, even if still done from the sound/soc/omap/ams-delta.c, not
from an arch board file, would require now not existing ams-delta ASoC
platform driver probe/remove callbacks at least. I'm still not convinced
if such modification would be acceptable in the middle of the rc cycle.
If there is a simpler, less intrusive way to do this, then sorry, I
still can't see it.
Like I already said just make it a static variable.
Mark,
Sorry, I was still not able to understand what you actually meant, and
to come out with a working fix other than I initially proposed. If what
I've prepared now is not acceptable as a fix, than hard luck, please
consider queueing it for 3.7, and 3.6 must go with Amstrad Delta sound
not working unless someone else is still able to fix it.
Tony,
Please give your ack on the arch/arm/mach-omap1 bits if acceptable. I
believe there should be no merge conflicts if this change goes through
sound/soc.
Thanks,
Janusz
arch/arm/mach-omap1/board-ams-delta.c | 12 ++
sound/soc/omap/ams-delta.c| 63 +++-
2 files changed, 42 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index c534698..5ab9c6b 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -444,16 +444,28 @@ static struct omap1_cam_platform_data
ams_delta_camera_platform_data = {
.lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
};
+static struct platform_device ams_delta_audio_device = {
+ .name = ams-delta-audio,
+ .id = -1,
+};
+
+static struct platform_device cx20442_codec_device = {
+ .name = cx20442-codec,
+ .id = -1,
+};
+
static struct platform_device *ams_delta_devices[] __initdata = {
latch1_gpio_device,
latch2_gpio_device,
ams_delta_kp_device,
ams_delta_camera_device,
+ ams_delta_audio_device,
};
static struct platform_device *late_devices[] __initdata = {
ams_delta_nand_device,
ams_delta_lcd_device,
+ cx20442_codec_device,
};
static void __init ams_delta_init(void)
diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c
index 7d4fa8e..7b18b74 100644
--- a/sound/soc/omap/ams-delta.c
+++ b/sound/soc/omap/ams-delta.c
@@ -575,56 +575,53 @@ static struct snd_soc_card ams_delta_audio_card = {
};
/* Module init/exit */
-static struct platform_device *ams_delta_audio_platform_device;
-static struct platform_device *cx20442_platform_device;
-
-static int __init ams_delta_module_init(void)
+static __devinit int ams_delta_probe(struct platform_device *pdev)
{
+ struct snd_soc_card *card = ams_delta_audio_card;
int ret;
- if (!(machine_is_ams_delta()))
- return -ENODEV;
-
- ams_delta_audio_platform_device =
- platform_device_alloc(soc-audio, -1);
- if (!ams_delta_audio_platform_device)
- return -ENOMEM;
+ card-dev = pdev-dev;
- platform_set_drvdata(ams_delta_audio_platform_device,
- ams_delta_audio_card);
-
- ret = platform_device_add(ams_delta_audio_platform_device);
- if (ret)
- goto err;
-
- /*
- * Codec platform device could be registered from elsewhere (board?),
- * but I do it here as it makes sense only if used with the card.
- */
- cx20442_platform_device =
- platform_device_register_simple(cx20442-codec, -1, NULL, 0);
+ ret = snd_soc_register_card(card);
+ if (ret) {
+ dev_err(pdev-dev, snd_soc_register_card failed (%d)\n, ret);
+ card-dev = NULL
Re: [PATCH 04/29] ARM: OMAP1: Move board-ams-delta.h from plat to mach
On Wed, 19 Sep 2012 14:05:43 Tony Lindgren wrote: This is only used by omap1. And to fix things properly, this should not be included from the drivers at all. Akced-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl I'll take care of updating the drivers when I have some spare time. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ASoC: ams-delta: Convert to use snd_soc_register_card()
The old method of registering with the ASoC core by creating a
soc-audio platform device no longer works for Amstrad Delta sound card
after recent changes to drvdata handling (commit
0998d0631001288a5974afc0b2a5f568bcdecb4d, 'device-core: Ensure drvdata =
NULL when no driver is bound'.
Use snd_soc_register_card() method instead, as suggested by the ASoC
core generated warning message, and move both the card and codec
platform device registration to the arch board file where those belong.
Created and tested against linux-3.6-rc5.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
On Thu, 6 Sep 2012 15:36:35 Mark Brown wrote:
On Sat, Sep 01, 2012 at 11:09:18AM +0200, Janusz Krzysztofik wrote:
I see your point, however for now I can see no better way of referencing
the data (of type struct snd_soc_card) then passing it to
snd_soc_register_card(). But for this to work, I would have to register
successfully an ams-delta specific platform device first, not the soc-
audio. This, even if still done from the sound/soc/omap/ams-delta.c, not
from an arch board file, would require now not existing ams-delta ASoC
platform driver probe/remove callbacks at least. I'm still not convinced
if such modification would be acceptable in the middle of the rc cycle.
If there is a simpler, less intrusive way to do this, then sorry, I
still can't see it.
Like I already said just make it a static variable.
Mark,
Sorry, I was still not able to understand what you actually meant, and
to come out with a working fix other than I initially proposed. If what
I've prepared now is not acceptable as a fix, than hard luck, please
consider queueing it for 3.7, and 3.6 must go with Amstrad Delta sound
not working unless someone else is still able to fix it.
Tony,
Please give your ack on the arch/arm/mach-omap1 bits if acceptable. I
believe there should be no merge conflicts if this change goes through
sound/soc.
Thanks,
Janusz
arch/arm/mach-omap1/board-ams-delta.c | 12 ++
sound/soc/omap/ams-delta.c| 63 +++-
2 files changed, 42 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index c534698..5ab9c6b 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -444,16 +444,28 @@ static struct omap1_cam_platform_data
ams_delta_camera_platform_data = {
.lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
};
+static struct platform_device ams_delta_audio_device = {
+ .name = ams-delta-audio,
+ .id = -1,
+};
+
+static struct platform_device cx20442_codec_device = {
+ .name = cx20442-codec,
+ .id = -1,
+};
+
static struct platform_device *ams_delta_devices[] __initdata = {
latch1_gpio_device,
latch2_gpio_device,
ams_delta_kp_device,
ams_delta_camera_device,
+ ams_delta_audio_device,
};
static struct platform_device *late_devices[] __initdata = {
ams_delta_nand_device,
ams_delta_lcd_device,
+ cx20442_codec_device,
};
static void __init ams_delta_init(void)
diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c
index 7d4fa8e..7b18b74 100644
--- a/sound/soc/omap/ams-delta.c
+++ b/sound/soc/omap/ams-delta.c
@@ -575,56 +575,53 @@ static struct snd_soc_card ams_delta_audio_card = {
};
/* Module init/exit */
-static struct platform_device *ams_delta_audio_platform_device;
-static struct platform_device *cx20442_platform_device;
-
-static int __init ams_delta_module_init(void)
+static __devinit int ams_delta_probe(struct platform_device *pdev)
{
+ struct snd_soc_card *card = ams_delta_audio_card;
int ret;
- if (!(machine_is_ams_delta()))
- return -ENODEV;
-
- ams_delta_audio_platform_device =
- platform_device_alloc(soc-audio, -1);
- if (!ams_delta_audio_platform_device)
- return -ENOMEM;
+ card-dev = pdev-dev;
- platform_set_drvdata(ams_delta_audio_platform_device,
- ams_delta_audio_card);
-
- ret = platform_device_add(ams_delta_audio_platform_device);
- if (ret)
- goto err;
-
- /*
-* Codec platform device could be registered from elsewhere (board?),
-* but I do it here as it makes sense only if used with the card.
-*/
- cx20442_platform_device =
- platform_device_register_simple(cx20442-codec, -1, NULL, 0);
+ ret = snd_soc_register_card(card);
+ if (ret) {
+ dev_err(pdev-dev, snd_soc_register_card failed (%d)\n, ret);
+ card-dev = NULL;
+ return ret;
+ }
return 0;
-err:
- platform_device_put(ams_delta_audio_platform_device);
- return ret;
}
-late_initcall(ams_delta_module_init);
-static void __exit
Re: [alsa-devel] [PATCH v3 00/15] ASoC: OMAP: Convert to use dmaengine
Dnia piątek, 14 września 2012 15:05:43 Peter Ujfalusi pisze: Hello, Changes since v2: - As it has been discussed the no_wakeup parameter has been replaced with flags for the dmaengine APIs Changes since v1: - Support for pause/resume for OMAP audio via dmaengine - dmaengine: support for NO_PERIOD_WAKEUP in cyclic mode - OMAP to keep supporting NO_PERIOD_WAKEUP for audio - Other plaforms can also try to enable this mode since we have now generic interface to do so. This series will switch the OMAP audio to use dmaengine. The final patch which does the switch was based on Russell King's earlier patch. The first 10 patch is to prepare the OMAP audio drivers for a smooth change to dmaengine: - sDMA FRAME sync mode is removed and replaced with PACKET mode - dai drivers no longer need to configure sDMA sync mode - dai drivers does not need to specify the DMA word length - with the exception of the omap-hdmi driver which requires 32bit word length regardless of the audio format in use - the McPDM driver used (to my surprise) hackish way of getting the DMA channel and address - via defines from some header files After the conversion OMAP audio support should have the same features as before, no regressions expected. I have tested the series on: - BeagleBoard (audio via McBSP): - aplay/arecord. In element mode and in threshold mode with different period sizes - mplayer -ao alsa: for direct ALSA access - mplayer -ao pulse: via PulseAudio to test NO_PERIOD_WAKEUP feature - OMAP4 Blaze (audio via McPDM and DMIC) - aplay/arecord - mplayer -ao alsa: for direct ALSA access - mplayer -ao pulse: via PulseAudio to test NO_PERIOD_WAKEUP feature The patches has been generated against: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-3.7 Janusz: Can you retest this series on OMAP1 to be sure I have not broken it? Hi Peter, It looks like you haven't :-). For OMAP1: Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [RFC update 0/2] dmaengine/ASoC: omap: Enable element mode in cyclic DMA
On Tue, 4 Sep 2012 15:08:00 Peter Ujfalusi wrote: Enable the element mode (thus allowing mono playback and probably unblocking OMAP1, OMAP2420) in OMAP dmaengine and omap-pcm. Janusz: would it be possible for you to test Russell's series plus this on OMAP1 to make sure that we do not broke it? Hi, I can confirm that sound works for me as before, both capture and playback, on my OMAP1 Amstrad Delta with Russell's and Peter's patches applied on top of linux-3.6-rc3, with the OMAP DMA engine driver built in. I was not able make audible tests with applications other than a soft phone as I didn't get back home for this weekend, but I think that the asterisk soft phone is quite a demanding use case. The only thing I'm not sure about is why the sysfs provided bytes_transferred values never change from their initial zeros. For OMAP1: Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [RFC update 0/2] dmaengine/ASoC: omap: Enable element mode in cyclic DMA
On Tue, 4 Sep 2012 15:08:00 Peter Ujfalusi wrote: Hi Russell, Enable the element mode (thus allowing mono playback and probably unblocking OMAP1, OMAP2420) in OMAP dmaengine and omap-pcm. Janusz: would it be possible for you to test Russell's series plus this on OMAP1 to make sure that we do not broke it? Hi Peter, Russell, I'll be happy to make this test for you. This will take some time (I work away from home), but I expect to have it done by Monday. BTW, I haven't been following OMAP development very closely last weeks, and I didn't even know about the OMAP DMA engine availability. Which Linux version should I base my test on? Would 3.6-rc be OK? Or l-o master? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH] ASoC: ams-delta: fix card initalization failure
Dnia piątek, 31 sierpnia 2012 14:31:04 Mark Brown pisze: On Wed, Aug 29, 2012 at 07:04:48AM +0200, Janusz Krzysztofik wrote: On Tue, 28 Aug 2012 11:13:39 Mark Brown wrote: The above looks like you already have a platform driver? Mark, I should have rather answered: No, ams-delta.c is not a platform driver, only a module which registeres a soc-audio device and provides device specific data and callbacks to the soc-audio platform driver. All I'm suggesting is changing the above to use platform rather than driver data. ... s/drvdata/platdata/ in the code. Taking the above into account, I would have to apply this substitue to the soc-core.c, which is actually the platform driver for the ams-delta ASoC device, and this would break a lot of other cards. If you can't do this then just referencing the data directly in the code would be better than this bodge, it'd be much less fragile. I see your point, however for now I can see no better way of referencing the data (of type struct snd_soc_card) then passing it to snd_soc_register_card(). But for this to work, I would have to register successfully an ams-delta specific platform device first, not the soc- audio. This, even if still done from the sound/soc/omap/ams-delta.c, not from an arch board file, would require now not existing ams-delta ASoC platform driver probe/remove callbacks at least. I'm still not convinced if such modification would be acceptable in the middle of the rc cycle. If there is a simpler, less intrusive way to do this, then sorry, I still can't see it. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH] ASoC: ams-delta: fix card initalization failure
On Mon, 27 Aug 2012 14:38:35 Mark Brown wrote: On Mon, Aug 27, 2012 at 11:28:30PM +0200, Janusz Krzysztofik wrote: - platform_set_drvdata(ams_delta_audio_platform_device, - ams_delta_audio_card); - - ret = platform_device_add(ams_delta_audio_platform_device); - if (ret) - goto err; The real fix here is that you should be using platform data here, not driver data. Is there some reason not to do that? Mark, Do you think the change you propose is suitable for the rc cycle? I'm trying to fix a regression in the first place. Converting the ams-delta asoc to a platform driver is on my todo list and I'm going to take care of this as soon as I have enough spare time. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH] ASoC: ams-delta: fix card initalization failure
On Tue, 28 Aug 2012 11:13:39 Mark Brown wrote: On Tue, Aug 28, 2012 at 05:13:05PM +0200, Janusz Krzysztofik wrote: On Mon, 27 Aug 2012 14:38:35 Mark Brown wrote: On Mon, Aug 27, 2012 at 11:28:30PM +0200, Janusz Krzysztofik wrote: - platform_set_drvdata(ams_delta_audio_platform_device, - ams_delta_audio_card); The real fix here is that you should be using platform data here, not driver data. Is there some reason not to do that? Do you think the change you propose is suitable for the rc cycle? I'm trying to fix a regression in the first place. Converting the ams- delta asoc to a platform driver is on my todo list and I'm going to take care of this as soon as I have enough spare time. The above looks like you already have a platform driver? All I'm suggesting is changing the above to use platform rather than driver data. The ams-delta asoc driver doesn't use snd_soc_register_card() so far, but relays solely on soc_probe() doing this for it, which in turn expects to find a snc_soc_card structure in drvdata. How is it supposed to find that structure if I pass it over platform data instead? Am I missing something? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ASoC: ams-delta: fix card initalization failure
Since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d, 'device-core: Ensure drvdata = NULL when no driver is bound', the Amstrad Delta sound card no longer initializes correctly due to drvdata reset to NULL by an upper layer before the codec device, required for successful card setup, is registered. Fix this by moving the codec registration bits up, before the card is probed for. Created and tested against linux-3.6-rc3 Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- sound/soc/omap/ams-delta.c | 18 ++ 1 files changed, 10 insertions(+), 8 deletions(-) diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c index 7d4fa8e..270de9c 100644 --- a/sound/soc/omap/ams-delta.c +++ b/sound/soc/omap/ams-delta.c @@ -590,20 +590,22 @@ static int __init ams_delta_module_init(void) if (!ams_delta_audio_platform_device) return -ENOMEM; - platform_set_drvdata(ams_delta_audio_platform_device, - ams_delta_audio_card); - - ret = platform_device_add(ams_delta_audio_platform_device); - if (ret) - goto err; - /* * Codec platform device could be registered from elsewhere (board?), * but I do it here as it makes sense only if used with the card. +* Moreover, it must be registered before the card is probed for, +* or the card setup fails due to drvdata reset by upper layers. */ cx20442_platform_device = platform_device_register_simple(cx20442-codec, -1, NULL, 0); - return 0; + + platform_set_drvdata(ams_delta_audio_platform_device, +ams_delta_audio_card); + + ret = platform_device_add(ams_delta_audio_platform_device); + if (!ret) + return ret; + err: platform_device_put(ams_delta_audio_platform_device); return ret; -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] omap: dma: Clear status registers on enable/disable irq.
On Tue, 15 May 2012 14:35:08 Oleg Matcovschi wrote:
Use omap_disable_channel_irq() function instead of directly accessing CICR.
The omap_disable_chanel_irq() function clears pending interrupts
and disables interrupt on channel.
Functions omap2_enable_irq_lch()/omap2_disable_irq_lch() clear interrupt
status register.
Signed-off-by: Oleg Matcovschi oleg.matcovs...@ti.com
---
v1 initial revision
v2 Review by Tony Lindgren
My Tested-by: on OMAP1 still valid for v2 if you care.
Thanks,
Janusz
---
arch/arm/plat-omap/dma.c | 59 +
1 files changed, 28 insertions(+), 31 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 3ec7ec5..3d5d593 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -563,22 +563,25 @@ EXPORT_SYMBOL(omap_set_dma_dest_burst_mode);
static inline void omap_enable_channel_irq(int lch)
{
- u32 status;
-
/* Clear CSR */
if (cpu_class_is_omap1())
- status = p-dma_read(CSR, lch);
- else if (cpu_class_is_omap2())
+ p-dma_read(CSR, lch);
+ else
p-dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR, lch);
/* Enable some nice interrupts. */
p-dma_write(dma_chan[lch].enabled_irqs, CICR, lch);
}
-static void omap_disable_channel_irq(int lch)
+static inline void omap_disable_channel_irq(int lch)
{
- if (cpu_class_is_omap2())
- p-dma_write(0, CICR, lch);
+ /* disable channel interrupts */
+ p-dma_write(0, CICR, lch);
+ /* Clear CSR */
+ if (cpu_class_is_omap1())
+ p-dma_read(CSR, lch);
+ else
+ p-dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR, lch);
}
void omap_enable_dma_irq(int lch, u16 bits)
@@ -622,14 +625,14 @@ static inline void disable_lnk(int lch)
l = p-dma_read(CLNK_CTRL, lch);
/* Disable interrupts */
+ omap_disable_channel_irq(lch);
+
if (cpu_class_is_omap1()) {
- p-dma_write(0, CICR, lch);
/* Set the STOP_LNK bit */
l |= 1 14;
}
if (cpu_class_is_omap2()) {
- omap_disable_channel_irq(lch);
/* Clear the ENABLE_LNK bit */
l = ~(1 15);
}
@@ -647,6 +650,9 @@ static inline void omap2_enable_irq_lch(int lch)
return;
spin_lock_irqsave(dma_chan_lock, flags);
+ /* clear IRQ STATUS */
+ p-dma_write(1 lch, IRQSTATUS_L0, lch);
+ /* Enable interrupt */
val = p-dma_read(IRQENABLE_L0, lch);
val |= 1 lch;
p-dma_write(val, IRQENABLE_L0, lch);
@@ -662,9 +668,12 @@ static inline void omap2_disable_irq_lch(int lch)
return;
spin_lock_irqsave(dma_chan_lock, flags);
+ /* Disable interrupt */
val = p-dma_read(IRQENABLE_L0, lch);
val = ~(1 lch);
p-dma_write(val, IRQENABLE_L0, lch);
+ /* clear IRQ STATUS */
+ p-dma_write(1 lch, IRQSTATUS_L0, lch);
spin_unlock_irqrestore(dma_chan_lock, flags);
}
@@ -735,11 +744,8 @@ int omap_request_dma(int dev_id, const char *dev_name,
}
if (cpu_class_is_omap2()) {
- omap2_enable_irq_lch(free_ch);
omap_enable_channel_irq(free_ch);
- /* Clear the CSR register and IRQ status register */
- p-dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR, free_ch);
- p-dma_write(1 free_ch, IRQSTATUS_L0, 0);
+ omap2_enable_irq_lch(free_ch);
}
*dma_ch_out = free_ch;
@@ -758,27 +764,19 @@ void omap_free_dma(int lch)
return;
}
- if (cpu_class_is_omap1()) {
- /* Disable all DMA interrupts for the channel. */
- p-dma_write(0, CICR, lch);
- /* Make sure the DMA transfer is stopped. */
- p-dma_write(0, CCR, lch);
- }
-
- if (cpu_class_is_omap2()) {
+ /* Disable interrupt for logical channel */
+ if (cpu_class_is_omap2())
omap2_disable_irq_lch(lch);
- /* Clear the CSR register and IRQ status register */
- p-dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR, lch);
- p-dma_write(1 lch, IRQSTATUS_L0, lch);
+ /* Disable all DMA interrupts for the channel. */
+ omap_disable_channel_irq(lch);
- /* Disable all DMA interrupts for the channel. */
- p-dma_write(0, CICR, lch);
+ /* Make sure the DMA transfer is stopped. */
+ p-dma_write(0, CCR, lch);
- /* Make sure the DMA transfer is stopped. */
- p-dma_write(0, CCR, lch);
+ /* Clear registers */
+ if (cpu_class_is_omap2())
omap_clear_dma(lch);
- }
spin_lock_irqsave(dma_chan_lock, flags);
dma_chan[lch].dev_id = -1;
@@ -926,8 +924,7 @@ void omap_stop_dma(int lch)
u32 l;
/* Disable all interrupts on the channel */
- if
Re: [PATCH] omap: dma: Clear status registers on enable/disable irq.
On Sunday 06 of May 2012 18:50:16 Jarkko Nikula wrote: On 05/04/2012 10:39 PM, Janusz Krzysztofik wrote: This seems like a nice fix to me. As it affects all omaps, I'd like to see some tested-by from Janusz/Jarkko/Peter. Can you guys give it a try with some audio tests? OK, I can do, but perhaps not before next Saturday, when I'm back home, able to actually listen to the audio, not only watch the IRQ counters rising up ;-). Ok from omap3 Tested-by: Jarkko Nikula jarkko.nik...@bitmer.com Works for me on OMAP1. Tested-by: Janusz Krzyszofik jkrzy...@tis.inet.pl -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP1: USB: fix ocpi_enable compile problem on non-1610 builds
On Friday 11 of May 2012 09:53:07 Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [120510 15:31]: Janusz Krzysztofik reported the following build break on OMAP1 builds that don't include CONFIG_ARCH_OMAP16XX: LD .tmp_vmlinux1 arch/arm/mach-omap1/built-in.o: In function `omap1_usb_init': lcd_dma.c:(.init.text+0x1420): undefined reference to `ocpi_enable' make: *** [.tmp_vmlinux1] Error 1 This was caused by commit d3645d39ad0ed9f09535065676ea0ba114f93cdf (ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus). Fix by declaring an empty ocpi_enable() on non-16XX builds, which should work until the OCPI code is moved out to drivers/. Thanks applying into fixes-for-cleanup branch. Tony FWIW, works with OMAP1510 only config on my Amstrad Delta. Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V7 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
Dnia czwartek, 3 maja 2012 13:28:58 Vaibhav Hiremath pisze: Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz) This patch series cleans up the existing 32k-sync timer implementation, movind SoC init code to respective files (mach-omap1/timer32k.c and mach-omap2/timer.c) and uses kernel parameter to override the default clocksource of counter_32k, also in order to support some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP, adds hwmod lookup for omap2+ devices, and if lookup fails then fall back to gp-timer. if(use_gptimer_clksrc == true) gptimer clocksource init; else if (counter_32 init == false) /* Fallback to gptimer */ gptimer clocksource init(; With this, we should be able to support multi-omap boot including devices with/without 32k-sync timer. This patch-series has been boot tested on AM37xEVM platform, it would be helpful if somebody help me to validate it on OMAP1/2 platforms. The patches are also available at (based on linux-omap/master) - https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup Tried to test this branch, merged into 3.4-rc6, and with my Amstrad Delta fixes applied, using my custom Amstrad Delta config, but initially failed because an unrelated issue rised to the surface: | LD .tmp_vmlinux1 | arch/arm/mach-omap1/built-in.o: In function `omap1_usb_init': | lcd_dma.c:(.init.text+0x1420): undefined reference to `ocpi_enable' | make: *** [.tmp_vmlinux1] Error 1 Apparently introduced with commit d3645d39ad0ed9f09535065676ea0ba114f93cdf, ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus, looks like one or more symbols exported by the not linked in arch/arm/mach-omap1/ocpi.o may be missing for non-OMAP16xx configs. Otherwise, if configured with OMAP16xx selected, builds and seems to work correctly for me, to the extent possible to verify without physical access to the hardware. However, please note that the Amstrad Delta doesn't make use of the 32k timer, only mpu_timer. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gpio/omap: fix incorrect initialization of omap_gpio_mod_init
On Mon, 7 May 2012 10:52:28 DebBarma, Tarun Kanti wrote: On Sun, May 6, 2012 at 3:25 AM, Grazvydas Ignotas nota...@gmail.com wrote: On Mon, Apr 30, 2012 at 10:20 AM, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: Initialization of irqenable, irqstatus registers is the common operation done in this function for all OMAP platforms, viz. OMAP1, OMAP2+. The latter _gpio_rmw()'s which supposedly got introduced wrongly to take care of OMAP2+ platforms were overwriting initially programmed OMAP1 value breaking functionality on OMAP1. Hi, I can confirm that my other issues with GPIO on Amstrad Delta were not related, and this patch is still required for GPIO interrupts hardware being correctly initialized on OMAP1 in 3.4-rc6. You can add my Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl if you wish. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3.4-rc6] MTD: NAND: ams-delta: fix request_mem_region() failure
Dnia wtorek, 8 maja 2012 10:11:46 Artem Bityutskiy pisze: On Tue, 2012-05-08 at 10:03 +0300, Artem Bityutskiy wrote: On Mon, 2012-05-07 at 22:51 +0200, Janusz Krzysztofik wrote: A call to request_mem_region() has been introduced in the omap- gpio driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40, gpio/omap: Use devm_ API and add request_mem_region). This change prevented the Amstrad Delta NAND driver, which was doing the same in order to take control over OMAP MPU I/O lines that the NAND device hangs off, from loading successfully. Aiaiai found out that your patch adds this gcc warning: Successfully built configuration l2_omap1_defconfig,arm,arm-unknown- linux-gnueabi-, results: --- before_patching.log +++ after_patching.log @@ @@ +drivers/mtd/nand/ams-delta.c: In function 'ams_delta_cleanup': +drivers/mtd/nand/ams-delta.c:285:19: warning: unused variable 'res' [-Wunused-variable] But I've fixed this up and pushed to l2-mtd.git. Many thanks for this. From the commit message I have an impression that you are not going to implement that longer term plan. I just didn't state 'I'll do it for the next merge window' because my spare time resources are limited, and I've at least one set of changes to the Amstrad Delta code still waiting on my todo list. I'll try to implement that long term plan as my spare time permits. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3.4-rc6] MTD: NAND: ams-delta: fix request_mem_region() failure
A call to request_mem_region() has been introduced in the omap-gpio
driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
gpio/omap: Use devm_ API and add request_mem_region). This change
prevented the Amstrad Delta NAND driver, which was doing the same in
order to take control over OMAP MPU I/O lines that the NAND device hangs
off, from loading successfully.
The I/O lines and corresponding registers used by the NAND driver are a
subset of those used for the GPIO function. Then, to avoid run time
collisions, all MPUIO GPIO lines should be marked as requested while
initializing the NAND driver, and vice versa, a single MPUIO GPIO line
already requested before the NAND driver initialization is attempted
should prevent the NAND device from being started successfully.
There is another driver, omap-keypad, which also manipulates MPUIO
registers, but has never been calling request_mem_region() on startup,
so it's not affected by the change in the gpio-omap and works correctly.
It uses the depreciated omap_read/write functions for accessing MPUIO
registers. Unlike the NAND driver, these I/O lines and registers are
separate from those used by the GPIO driver. However, both register sets
are non-contiguous and overlapping, so it would be impractical to
request the two sets separately, one from the gpio-omap, the other form
the omap-keypad driver.
In order to solve all these issues correctly, a solution first suggested
by Artem Bityutskiy, then closer specified by Tony Lindgren while they
commented the initial version of this fix, should be implemented. The
gpio-omap driver should export a few functions which would allow the
other two drivers to access MPUIO registers in a safe manner instead of
trying to manage them in parallel to the GPIO driver. However, such a
big change, affecting 3 drivers all together, is not suitable for the rc
cycle, and should be prepared for the merge window. Then, an
alternative solution is proposed as a regression fix.
For the ams-delta NAND driver to initialize correctly in coexistence
with the changed GPIO driver, drop the request_mem_region() call from
the former, especially as this call is going to be removed while the
long-term solution is implemented.
Tested on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Tony Lindgren t...@atomide.com
---
Artem, Tony,
I hope the changelog message is now good enough to make you satisfied,
and render the Tony's Ack valid.
Changes against initial version:
* a comment replacing the removed function call added,
* more details on the three drivers coexistance and possible interaction
provided,
* a hopefuly decent long-term plan to properly fix all identified issues
proposed.
drivers/mtd/nand/ams-delta.c | 16 ++--
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 7341695..358162a 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -212,18 +212,17 @@ static int __devinit ams_delta_init(struct
platform_device *pdev)
/* Link the private data with the MTD structure */
ams_delta_mtd-priv = this;
- if (!request_mem_region(res-start, resource_size(res),
- dev_name(pdev-dev))) {
- dev_err(pdev-dev, request_mem_region failed\n);
- err = -EBUSY;
- goto out_free;
- }
+ /*
+* Don't try to request the memory region from here,
+* it should have been already requested from the
+* gpio-omap driver and requesting it again would fail.
+*/
io_base = ioremap(res-start, resource_size(res));
if (io_base == NULL) {
dev_err(pdev-dev, ioremap failed\n);
err = -EIO;
- goto out_release_io;
+ goto out_free;
}
this-priv = io_base;
@@ -271,8 +270,6 @@ out_gpio:
platform_set_drvdata(pdev, NULL);
gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
iounmap(io_base);
-out_release_io:
- release_mem_region(res-start, resource_size(res));
out_free:
kfree(ams_delta_mtd);
out:
@@ -293,7 +290,6 @@ static int __devexit ams_delta_cleanup(struct
platform_device *pdev)
gpio_free_array(_mandatory_gpio, ARRAY_SIZE(_mandatory_gpio));
gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
iounmap(io_base);
- release_mem_region(res-start, resource_size(res));
/* Free the MTD device structure */
kfree(ams_delta_mtd);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.4-rc4] ARM: OMAP1: Amstrad Delta: Fix wrong IRQ base in FIQ handler
Dnia piątek, 4 maja 2012 09:59:49 Tony Lindgren pisze: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [120430 10:30]: Commit 384ebe1c2849160d040df3e68634ec506f13d9ff, gpio/omap: Add DT support to GPIO driver, introduced dynamic IRQ numbering of OMAP GPIO interrupts, breaking all IH_GPIO_BASE based IRQ number calculations. This issue was corrected in the OMAP GPIO driver and the related header file with commit 25db711df3258d125dc1209800317e5c0ef3c870, gpio/omap: Fix IRQ handling for SPARSE_IRQ. However, the Amstrad Delta FIQ handler, which replaces the gpio-omap driver in serving GPIO interrupts on this board, still uses that outdated method. Fix it. Thanks applying into fixes. Hi Tony, Thanks for taking this patch, but I ca't see it applied into your fixes branch (the last one sitting there is Linux 3.4-rc4 by Linus). Am I missing something? Regards, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
On Fri, 4 May 2012 10:11:25 Tony Lindgren wrote: Hi, * Janusz Krzysztofik jkrzy...@tis.icnet.pl [120430 11:15]: Dnia czwartek, 26 kwietnia 2012 08:20:59 Artem Bityutskiy pisze: On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote: Both drivers use separate subsets of registers that belong to the OMAP1 MPU I/O device, but are used for controlling different sets of I/O pins. The NAND driver reads/writes the folowing registers: - OMAP_MPUIO_INPUT_LATCH, - OMAP_MPUIO_OUTPUT, - OMAP_MPUIO_IO_CNTL, while the keypad driver - the following: - OMAP_MPUIO_KBR_LATCH, - OMAP_MPUIO_KBC, - OMAP_MPUIO_KBD_MASKIT - OMAP_MPUIO_GPIO_DEBOUNCING. Both subsets are non-overlapping, and we rely on the drivers being free of bugs and doing their job correctly, not stepping on each others' feet, I guess. First of all, I think this information should be in the commit message. Also, some sort of comment in the driver code would be nice. If locking the memory region is too coarse approach, the should have a small separate omap-specific MPUIO subsystem which will be used by drivers to access MPUIO? Another question - should request_mem_region() be also removed from the omap-gpio driver then? I think it is more sensible to put a comment there that it is sharing MPIO with other drivers, instead of having an illusion of exclusive memory region ownership. But this is up to the OMAP community - I can take this patch to my l2-mtd tree if you get an ack from Tony or other OMAP guys. Tony, Would I get your Ack for this fix if I extend the commit message as Artem suggested? If not, what do you think should be a correct way to fix the regression? Well how about adding some exported functions to drivers/gpio/gpio_omap.c like omap_mpuio_latch? For the regression fix, if you guys want to do what Janusz is suggesting, then assuming the patch description also contains some decent long term plan to properly fix it: Acked-by: Tony Lindgren t...@atomide.com Thanks. Now that we know you prefer to keep the memory requested from inside the gpio-omap, which I was about to suggest to drop back as an alternative fix, I'll try to cook a new description for my patch, and perhaps add a comment replacing the request_mem_region function removed from the ams-delta NAND driver, in order to satisfy both yours and Artem's comments in a few days. Regards, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: dma: Clear status registers on enable/disable irq.
Dnia piątek, 4 maja 2012 09:51:46 Tony Lindgren pisze: Hi, * Oleg Matcovschi oleg.matcovs...@ti.com [120420 13:49]: Use omap_disable_channel_irq() function instead of directly accessing CICR. The omap_disable_chanel_irq() function clears pending interrupts and disables interrupt on channel. Functions omap2_enable_irq_lch()/omap2_disable_irq_lch() clear interrupt status register. This seems like a nice fix to me. As it affects all omaps, I'd like to see some tested-by from Janusz/Jarkko/Peter. Can you guys give it a try with some audio tests? OK, I can do, but perhaps not before next Saturday, when I'm back home, able to actually listen to the audio, not only watch the IRQ counters rising up ;-). Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V6 1/3] ARM: OMAP1: FIX: check possible error condition in timer_init
Dnia piątek, 4 maja 2012 10:43:02 Tony Lindgren pisze: Hi, * Kevin Hilman khil...@ti.com [120502 13:11]: Vaibhav Hiremath hvaib...@ti.com writes: OMAP1, omap_32k_timer_init() function always returns true, irrespective of whether error occurred while initializing 32k sync counter as a kernel clocksource or not and execution will never fallback to mpu_timer clocksource init code. This patch adds check for return value from function omap_init_clocksource_32k(), and fallback to omap_mpu_timer_init() in case of failure/error from omap_init_clocksource_32k(). Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com --- This is new patch addition compared to original series (=V5). Also, note that, this patch is only compile tested, since I do not have omap1 board with me to validate it. Kevin, can you help me to validate it. I boot tested on OMAP1 (5912/OSK) with 32k timer and MPU timer Kconfigs. Works fine, but needs small change below for compile warnings. Otherwise, looks good. We need at least one tested-by on some 15xx platform for these changes. Janusz, can you please give this series a try on your board too? Sure, but in a week or so. I'm still trying to follow the l-o list, but please always Cc: me for testing any changes on Amstrad Delta whenever you see fit. Regards, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.4-rc4] ARM: OMAP1: Amstrad Delta: Fix wrong IRQ base in FIQ handler
Commit 384ebe1c2849160d040df3e68634ec506f13d9ff, gpio/omap: Add DT support to GPIO driver, introduced dynamic IRQ numbering of OMAP GPIO interrupts, breaking all IH_GPIO_BASE based IRQ number calculations. This issue was corrected in the OMAP GPIO driver and the related header file with commit 25db711df3258d125dc1209800317e5c0ef3c870, gpio/omap: Fix IRQ handling for SPARSE_IRQ. However, the Amstrad Delta FIQ handler, which replaces the gpio-omap driver in serving GPIO interrupts on this board, still uses that outdated method. Fix it. Created and tested against linux-3.4-rc4. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- arch/arm/mach-omap1/ams-delta-fiq.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap1/ams-delta-fiq.c b/arch/arm/mach-omap1/ams-delta-fiq.c index fcce7ff..cfd98b1 100644 --- a/arch/arm/mach-omap1/ams-delta-fiq.c +++ b/arch/arm/mach-omap1/ams-delta-fiq.c @@ -48,7 +48,7 @@ static irqreturn_t deferred_fiq(int irq, void *dev_id) struct irq_chip *irq_chip = NULL; int gpio, irq_num, fiq_count; - irq_desc = irq_to_desc(IH_GPIO_BASE); + irq_desc = irq_to_desc(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK)); if (irq_desc) irq_chip = irq_desc-irq_data.chip; -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
Dnia czwartek, 26 kwietnia 2012 08:20:59 Artem Bityutskiy pisze: On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote: Both drivers use separate subsets of registers that belong to the OMAP1 MPU I/O device, but are used for controlling different sets of I/O pins. The NAND driver reads/writes the folowing registers: - OMAP_MPUIO_INPUT_LATCH, - OMAP_MPUIO_OUTPUT, - OMAP_MPUIO_IO_CNTL, while the keypad driver - the following: - OMAP_MPUIO_KBR_LATCH, - OMAP_MPUIO_KBC, - OMAP_MPUIO_KBD_MASKIT - OMAP_MPUIO_GPIO_DEBOUNCING. Both subsets are non-overlapping, and we rely on the drivers being free of bugs and doing their job correctly, not stepping on each others' feet, I guess. First of all, I think this information should be in the commit message. Also, some sort of comment in the driver code would be nice. If locking the memory region is too coarse approach, the should have a small separate omap-specific MPUIO subsystem which will be used by drivers to access MPUIO? Another question - should request_mem_region() be also removed from the omap-gpio driver then? I think it is more sensible to put a comment there that it is sharing MPIO with other drivers, instead of having an illusion of exclusive memory region ownership. But this is up to the OMAP community - I can take this patch to my l2-mtd tree if you get an ack from Tony or other OMAP guys. Tony, Would I get your Ack for this fix if I extend the commit message as Artem suggested? If not, what do you think should be a correct way to fix the regression? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio/omap: fix incorrect initialization of omap_gpio_mod_init
On Friday 27 of April 2012 14:09:11 Tarun Kanti DebBarma wrote: Breaking commit: ab985f0f7c2c0ef90b7c832f0c04f470dda0593d Initialization of irqenable, irqstatus registers is the common operation done in this function for all OMAP platforms, viz. OMAP1, OMAP2+. The latter _gpio_rmw()'s to irqenable register was overwriting the correctly programmed OMAP1 value at the beginning. As a result, even though it worked on OMAP2+ platforms it was breaking OMAP1 functionality. On close observation it is found that the first _gpio_rmw() which is supposedly done to take care of OMAP1 platform is generic enough and takes care of OMAP2+ platform as well. Therefore remove the latter _gpio_rmw() to irqenable as they are redundant now. Writing to ctrl and debounce_en registers for OMAP2+ platforms are modified to match the original(pre-cleanup) code where the registers are initialized with 0. In the cleanup series since we are using _gpio_rmw(reg, 0, 1), instead of __raw_writel(), we are just reading and writing the same values to ctrl and debounce_en. This is not an issue for debounce_en register because it has 0x0 as the default value. But in the case of ctrl register the default value is 0x2 (GATINGRATIO = 0x1) so that we end up writing 0x2 instead of intended 0 value. Therefore correcting it to _gpio_rmw(reg, l, 0), where l = 0x so that registers are initialized to 0. Also, changing the sequence and logic of initializing the irqstatus. Hi, Sorry for not responding in 2 days, as I promissed. The reason is that there are still more issues with GPIO on my Amstrad Delta, for example those introduced with commit 384ebe1c2849160d040df3e68634ec506f13d9ff, and I'm still trying to understand and fix them. Than, it's hard for me to provide you with my Tested-by: before I'm confident those other issues are not related. Anyway, and with respect to Kevin's comments, reverting the irqstatus vs. irqenable initialization order doesn't seem to break anything for me, and changes to debounce_en and ctrl register handling seem not relevant to my test machine. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
Dnia środa, 25 kwietnia 2012 18:13:38 Artem Bityutskiy pisze: On Tue, 2012-04-17 at 15:49 +0200, Janusz Krzysztofik wrote: A call to request_mem_region() has been introduced in the omap-gpio driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40, gpio/omap: Use devm_ API and add request_mem_region). This change prevented the Amstrad Delta NAND driver, which was doing the same in order to take control over OMAP MPU I/O lines that the NAND device hangs off, from loading successfully. There is another driver, omap-keypad, which also manipulates OMAP MPUIO registers, but has never been calling request_mem_region() on startup, so it's not affected by the change in the gpio-omap and works correctly. Drop request_mem_region() call and related bits from ams-delta NAND driver. Created and tested against linux-3.4-rc3. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl How about race conditions? Where is the guarantee that these 2 drivers won't affect each other when doing I/O at the same time to the same HW resources? Both drivers use separate subsets of registers that belong to the OMAP1 MPU I/O device, but are used for controlling different sets of I/O pins. The NAND driver reads/writes the folowing registers: - OMAP_MPUIO_INPUT_LATCH, - OMAP_MPUIO_OUTPUT, - OMAP_MPUIO_IO_CNTL, while the keypad driver - the following: - OMAP_MPUIO_KBR_LATCH, - OMAP_MPUIO_KBC, - OMAP_MPUIO_KBD_MASKIT - OMAP_MPUIO_GPIO_DEBOUNCING. Both subsets are non-overlapping, and we rely on the drivers being free of bugs and doing their job correctly, not stepping on each others' feet, I guess. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function
Dnia wtorek, 24 kwietnia 2012 21:06:59 DebBarma, Tarun Kanti pisze: Hi Janusz, Here is the patch, with attachment as well. I have just tested on OMAP4 platform. Testing on other OMAP2+ platforms is pending. In the meantime can you please validate on OMAP1 platform and confirm? Thanks. Hi, Please give me a day or two. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function
On Thursday 02 of February 2012 23:00:37 Tarun Kanti DebBarma wrote:
With register offsets now defined for respective OMAP versions we can get rid
of cpu_class_* checks. This function now has common initialization code for
all OMAP versions...
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Sorry for being so late with my comment for chanes already present in
mainline, but this patch breaks GPIO on Amstrad Delta at least, and I
have neither enough spare time nor enough experience with non OMAP1
machines to provide a solution myself.
---
arch/arm/mach-omap1/gpio16xx.c | 35 +-
drivers/gpio/gpio-omap.c | 77
2 files changed, 57 insertions(+), 55 deletions(-)
...
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f39d9e4..a948351 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
...
@@ -898,62 +896,30 @@ static void __init omap_gpio_show_rev(struct gpio_bank
*bank)
*/
static struct lock_class_key gpio_lock_class;
-/* TODO: Cleanup cpu_is_* checks */
static void omap_gpio_mod_init(struct gpio_bank *bank)
{
- if (cpu_class_is_omap2()) {
- if (cpu_is_omap44xx()) {
- __raw_writel(0x, bank-base +
- OMAP4_GPIO_IRQSTATUSCLR0);
- __raw_writel(0x, bank-base +
- OMAP4_GPIO_DEBOUNCENABLE);
- /* Initialize interface clk ungated, module enabled */
- __raw_writel(0, bank-base + OMAP4_GPIO_CTRL);
- } else if (cpu_is_omap34xx()) {
- __raw_writel(0x, bank-base +
- OMAP24XX_GPIO_IRQENABLE1);
- __raw_writel(0x, bank-base +
- OMAP24XX_GPIO_IRQSTATUS1);
- __raw_writel(0x, bank-base +
- OMAP24XX_GPIO_DEBOUNCE_EN);
-
- /* Initialize interface clk ungated, module enabled */
- __raw_writel(0, bank-base + OMAP24XX_GPIO_CTRL);
- }
- } else if (cpu_class_is_omap1()) {
- if (bank_is_mpuio(bank)) {
- __raw_writew(0x, bank-base +
- OMAP_MPUIO_GPIO_MASKIT / bank-stride);
- mpuio_init(bank);
- }
- if (cpu_is_omap15xx() bank-method == METHOD_GPIO_1510) {
- __raw_writew(0x, bank-base
- + OMAP1510_GPIO_INT_MASK);
- __raw_writew(0x, bank-base
- + OMAP1510_GPIO_INT_STATUS);
- }
- if (cpu_is_omap16xx() bank-method == METHOD_GPIO_1610) {
- __raw_writew(0x, bank-base
- + OMAP1610_GPIO_IRQENABLE1);
- __raw_writew(0x, bank-base
- + OMAP1610_GPIO_IRQSTATUS1);
- __raw_writew(0x0014, bank-base
- + OMAP1610_GPIO_SYSCONFIG);
+ void __iomem *base = bank-base;
+ u32 l = 0x;
- /*
- * Enable system clock for GPIO module.
- * The CAM_CLK_CTRL *is* really the right place.
- */
- omap_writel(omap_readl(ULPD_CAM_CLK_CTRL) | 0x04,
- ULPD_CAM_CLK_CTRL);
- }
- if (cpu_is_omap7xx() bank-method == METHOD_GPIO_7XX) {
- __raw_writel(0x, bank-base
- + OMAP7XX_GPIO_INT_MASK);
- __raw_writel(0x, bank-base
- + OMAP7XX_GPIO_INT_STATUS);
- }
+ if (bank-width == 16)
+ l = 0x;
+
+ if (bank_is_mpuio(bank)) {
+ __raw_writel(l, bank-base + bank-regs-irqenable);
+ return;
}
+
+ _gpio_rmw(base, bank-regs-irqenable, l, bank-regs-irqenable_inv);
+ _gpio_rmw(base, bank-regs-irqstatus, l,
+ bank-regs-irqenable_inv == false);
+ _gpio_rmw(base, bank-regs-irqenable, l, bank-regs-debounce_en != 0);
+ _gpio_rmw(base, bank-regs-irqenable, l, bank-regs-ctrl != 0);
bank-regs-irqenable trgister is manipulated 3 times in a row, each
time based on different criteria. This breaks GPIO on Amstrad Delta at
least, and generally looks wrong. I was only able to verify that
commenting out the above two lines
[PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
A call to request_mem_region() has been introduced in the omap-gpio
driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
gpio/omap: Use devm_ API and add request_mem_region). This change
prevented the Amstrad Delta NAND driver, which was doing the same in
order to take control over OMAP MPU I/O lines that the NAND device hangs
off, from loading successfully.
There is another driver, omap-keypad, which also manipulates OMAP MPUIO
registers, but has never been calling request_mem_region() on startup,
so it's not affected by the change in the gpio-omap and works correctly.
Drop request_mem_region() call and related bits from ams-delta NAND
driver.
Created and tested against linux-3.4-rc3.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/mtd/nand/ams-delta.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 7341695..af76da3 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -212,18 +212,11 @@ static int __devinit ams_delta_init(struct
platform_device *pdev)
/* Link the private data with the MTD structure */
ams_delta_mtd-priv = this;
- if (!request_mem_region(res-start, resource_size(res),
- dev_name(pdev-dev))) {
- dev_err(pdev-dev, request_mem_region failed\n);
- err = -EBUSY;
- goto out_free;
- }
-
io_base = ioremap(res-start, resource_size(res));
if (io_base == NULL) {
dev_err(pdev-dev, ioremap failed\n);
err = -EIO;
- goto out_release_io;
+ goto out_free;
}
this-priv = io_base;
@@ -271,8 +264,6 @@ out_gpio:
platform_set_drvdata(pdev, NULL);
gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
iounmap(io_base);
-out_release_io:
- release_mem_region(res-start, resource_size(res));
out_free:
kfree(ams_delta_mtd);
out:
@@ -293,7 +284,6 @@ static int __devexit ams_delta_cleanup(struct
platform_device *pdev)
gpio_free_array(_mandatory_gpio, ARRAY_SIZE(_mandatory_gpio));
gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
iounmap(io_base);
- release_mem_region(res-start, resource_size(res));
/* Free the MTD device structure */
kfree(ams_delta_mtd);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] ASoC: OMAP: ams-delta: drop .set_bias_level callback
This functionality has already been implemented in the cx20442 codec
driver (commit f75a8ff67d161b5166a2c2360bb2ffaefd5eb853, ASoC: cx20442:
add bias control over a platform provided regulator), no need to keep
it here duplicated.
Once done, remove the no longer used AMS_DELTA_LATCH2_MODEM_NRESET
symbol from the board header file and a call to the regulator_toggle()
helper function from the old API wrapper found in the board file. While
being at it, simplify the way the modem .pm callback handles the
regulator and drop that helper function and its related consumer setup
completely.
Depends on patches 1/3 and 2/3 for clean apply and keep things working.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Tony Lindgren t...@atomide.com
---
v2 - v3 changes: none.
Changes against initial version:
* don't move consumer setup elements, now named to indicated their
modem related purpose, down the file,
* don't track the regulator enable/disable state, compare new target
power state with the old one instead; thanks to Mark Brown for
suggesting this simplification,
* actually drop all references to AMS_DELTA_LATCH2_MODEM_NRESET.
arch/arm/mach-omap1/board-ams-delta.c | 42 +++-
arch/arm/plat-omap/include/plat/board-ams-delta.h |1 -
sound/soc/omap/ams-delta.c| 32
3 files changed, 7 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 2fb2cbb..cb6afe6 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -18,7 +18,6 @@
#include linux/input.h
#include linux/interrupt.h
#include linux/leds.h
-#include linux/mutex.h
#include linux/platform_device.h
#include linux/regulator/consumer.h
#include linux/regulator/fixed.h
@@ -291,35 +290,8 @@ static struct platform_device modem_nreset_device = {
struct modem_private_data {
struct regulator *regulator;
- struct {
- struct mutex lock;
- bool enabled;
- } consumer;
};
-static int regulator_toggle(struct modem_private_data *priv, bool enable)
-{
- int err = 0;
-
- mutex_lock(priv-consumer.lock);
- if (IS_ERR(priv-regulator)) {
- err = PTR_ERR(priv-regulator);
- } else if (enable) {
- if (!priv-consumer.enabled) {
- err = regulator_enable(priv-regulator);
- priv-consumer.enabled = true;
- }
- } else {
- if (priv-consumer.enabled) {
- err = regulator_disable(priv-regulator);
- priv-consumer.enabled = false;
- }
- }
- mutex_unlock(priv-consumer.lock);
-
- return err;
-}
-
static struct modem_private_data modem_priv;
void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
@@ -330,8 +302,6 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask,
u16 value)
for (; bit ngpio; bit++, bitpos = bitpos 1) {
if (!(mask bitpos))
continue;
- else if (base + bit == AMS_DELTA_GPIO_PIN_MODEM_NRESET)
- regulator_toggle(modem_priv, (value bitpos) != 0);
else
gpio_set_value(base + bit, (value bitpos) != 0);
}
@@ -530,10 +500,16 @@ static void modem_pm(struct uart_port *port, unsigned int
state, unsigned old)
{
struct modem_private_data *priv = port-private_data;
+ if (IS_ERR(priv-regulator))
+ return;
+
if (state == old)
return;
- regulator_toggle(priv, state == 0);
+ if (state == 0)
+ regulator_enable(priv-regulator);
+ else if (old == 0)
+ regulator_disable(priv-regulator);
}
static struct plat_serial8250_port ams_delta_modem_ports[] = {
@@ -593,7 +569,6 @@ static int __init late_init(void)
gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
/* Initialize the modem_nreset regulator consumer before use */
- mutex_init(modem_priv.consumer.lock);
modem_priv.regulator = ERR_PTR(-ENODEV);
ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC,
@@ -606,9 +581,6 @@ static int __init late_init(void)
/*
* Once the modem device is registered, the modem_nreset
* regulator can be requested on behalf of that device.
-* In addition to the modem .pm callback, that regulator
-* is still used via the ams_delta_latch_write() wrapper
-* by the ASoC driver until updated.
*/
modem_priv.regulator = regulator_get(ams_delta_modem_device.dev,
RESET#);
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index 027e79e..ad6f865 100644
[PATCH v3 2/3] ARM: OMAP1: ams-delta: update the modem to use regulator API
After the CX20442 codec driver already takes care of enabling the codec
power for itself (commit f75a8ff67d161b5166a2c2360bb2ffaefd5eb853,
ASoC: cx20442: add bias control over a platform provided regulator),
but before dropping the old bias control method from the Amstrad Delta
ASoC sound card file, which in fact keeps the modem power always on,
even on the ASoC device close for now, extend the modem setup with a
power management callback which toggles the regulator up to the modem's
needs, reusing the previously set up regulator consumer for this. Also,
drop the MODEM_NRESET pin setup from the modem initialization procedure,
as this operation was already ineffective since patch 1/3, and not
needed because the regulator is set up as initially enabled.
Depends on patch 1/3 ARM: OMAP1: ams-delta: set up regulator over modem
reset GPIO pin to apply cleanly.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: Tony Lindgren t...@atomide.com
---
No functional changes against initial version.
arch/arm/mach-omap1/board-ams-delta.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 949997c..2fb2cbb 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -526,6 +526,16 @@ static void __init ams_delta_init(void)
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
+static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
+{
+ struct modem_private_data *priv = port-private_data;
+
+ if (state == old)
+ return;
+
+ regulator_toggle(priv, state == 0);
+}
+
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
.membase= IOMEM(MODEM_VIRT),
@@ -536,6 +546,8 @@ static struct plat_serial8250_port ams_delta_modem_ports[]
= {
.iotype = UPIO_MEM,
.regshift = 1,
.uartclk= BASE_BAUD * 16,
+ .pm = modem_pm,
+ .private_data = modem_priv,
},
{ },
};
@@ -584,9 +596,8 @@ static int __init late_init(void)
mutex_init(modem_priv.consumer.lock);
modem_priv.regulator = ERR_PTR(-ENODEV);
- ams_delta_latch2_write(
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
+ ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC,
+ AMS_DELTA_LATCH2_MODEM_CODEC);
err = platform_device_register(ams_delta_modem_device);
if (err)
@@ -595,8 +606,9 @@ static int __init late_init(void)
/*
* Once the modem device is registered, the modem_nreset
* regulator can be requested on behalf of that device.
-* The regulator is used via ams_delta_latch_write()
-* by the modem and ASoC drivers until updated.
+* In addition to the modem .pm callback, that regulator
+* is still used via the ams_delta_latch_write() wrapper
+* by the ASoC driver until updated.
*/
modem_priv.regulator = regulator_get(ams_delta_modem_device.dev,
RESET#);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] Amstrad Delta: access MODEM_RESET GPIO pin over a regulator
The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down (bring into/out of a reset state) two distinct on-board devices simultaneously: the modem, and the voice codec. As a consequence, that bit is, or can be, manipulated concurrently by two drivers, or their platform provided hooks. Instead of updating those drivers to use the gpiolib API as a new method of controlling the MODEM_NRESET pin state, like it was done to other drivers accessing latch2 pins, and still being vulnerable to potential concurrency conflicts, or trying to solve that sharing issue with a custom piece of code, set up a fixed regulator device on top of that GPIO pin and update both drivers to manipulate that regulator, not the GPIO pin directly. This is v3 of this series, with Mark's Ack for ASoC subtree touching changes already collected, rebased on top of linux-omap/ams-delta tip, commit da564a05b3aefe403062411b67d64b7e992718f7. There were initially 4 patches in the series, but patch 2/4, ASoC: cx20442: add bias control over a platform provided regulator, has been since then applied by Liam to the ASoC tree (thanks!) and is already present in mainline (commit f75a8ff67d161b5166a2c2360bb2ffaefd5eb853), hence omitted from this submission. v2 - v3 changes: * fix section mismatch issue present in previous versions of patch 1/3. v2 changes against initial version: * in both the codec and the modem callbacks, don't track the regulator enable/disable state, compare new target bias level (the codec case) or power state (the modem case) with the old value instead; thanks to Mark Brown who suggested this solution, * a few other minor changes, mostly stylistic. Janusz Krzysztofik (3): ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin ARM: OMAP1: ams-delta: update the modem to use regulator API ASoC: OMAP: ams-delta: drop .set_bias_level callback arch/arm/mach-omap1/Kconfig |2 + arch/arm/mach-omap1/board-ams-delta.c | 94 +++-- arch/arm/plat-omap/include/plat/board-ams-delta.h |1 - sound/soc/omap/ams-delta.c| 32 --- 4 files changed, 87 insertions(+), 42 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin
The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available
as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down
(bring into/out of a reset state) two distinct on-board devices
simultaneously: the modem, and the voice codec. As a consequence, that
bit is, or can be, manipulated concurrently by two drivers, or their
platform provided hooks.
Instead of updating those drivers to use the gpiolib API as a new method
of controlling the MODEM_NRESET pin state, like it was done to other
drivers accessing latch2 pins, and still being vulnerable to potential
concurrency conflicts, or trying to solve that sharing issue with a
custom piece of code, set up a fixed regulator device on top of that
GPIO pin, with the intention of updating both drivers to manipulate that
regulator, not the GPIO pin directly.
Before the ASoC driver is updated and the modem platform data expanded
with a power management callback for switching its power, the
ams_delta_latch_write() function, which still provides the old API for
accessing latch2 functionality from not updated drivers, is modified to
toggle the regulator instead of the MODEM_NRESET GPIO pin. A helper
function provided for balancing the regulator enable/disable operations,
together with the consumer data needed for tracking the regulator state,
will be removed once the drivers are updated.
Depends on patch series ARM: OMAP1: ams-delta: replace custom I/O with
GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
v2 - v3 changes:
* fix section mismatch isue.
Changes against initial version:
* rename consumer setup elements to match their final, modem only
related purpose,
* initialize the regulator pointer and mutex before first use, then
omit testing that pointer against NULL value
arch/arm/mach-omap1/Kconfig |2 +
arch/arm/mach-omap1/board-ams-delta.c | 104 +++--
2 files changed, 100 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index 5b1edba..4b6a774 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -157,6 +157,8 @@ config MACH_AMS_DELTA
select FIQ
select GPIO_GENERIC_PLATFORM
select LEDS_GPIO_REGISTER
+ select REGULATOR
+ select REGULATOR_FIXED_VOLTAGE
help
Support for the Amstrad E3 (codename Delta) videophone. Say Y here
if you have such a device.
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index ce50fe1..949997c 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -18,7 +18,11 @@
#include linux/input.h
#include linux/interrupt.h
#include linux/leds.h
+#include linux/mutex.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/regulator/fixed.h
+#include linux/regulator/machine.h
#include linux/serial_8250.h
#include linux/export.h
@@ -237,11 +241,6 @@ static const struct gpio latch_gpios[] __initconst = {
.label = scard_cmdvcc,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = modem_nreset,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC,
.flags = GPIOF_OUT_INIT_LOW,
.label = modem_codec,
@@ -258,6 +257,71 @@ static const struct gpio latch_gpios[] __initconst = {
},
};
+static struct regulator_consumer_supply modem_nreset_consumers[] = {
+ REGULATOR_SUPPLY(RESET#, serial8250.1),
+ REGULATOR_SUPPLY(POR, cx20442-codec),
+};
+
+static struct regulator_init_data modem_nreset_data = {
+ .constraints= {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .boot_on= 1,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(modem_nreset_consumers),
+ .consumer_supplies = modem_nreset_consumers,
+};
+
+static struct fixed_voltage_config modem_nreset_config = {
+ .supply_name= modem_nreset,
+ .microvolts = 330,
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ .startup_delay = 25000,
+ .enable_high= 1,
+ .enabled_at_boot= 1,
+ .init_data = modem_nreset_data,
+};
+
+static struct platform_device modem_nreset_device = {
+ .name = reg-fixed-voltage,
+ .id = -1,
+ .dev= {
+ .platform_data = modem_nreset_config,
+ },
+};
+
+struct modem_private_data {
+ struct regulator *regulator;
+ struct {
+ struct mutex lock;
+ bool enabled;
+ } consumer;
+};
+
+static int regulator_toggle(struct modem_private_data *priv, bool enable)
+{
+ int err = 0;
+
+ mutex_lock(priv-consumer.lock);
+ if (IS_ERR(priv-regulator
Re: [GIT PULL 3/5] First set of omap1 related changes
On Thu, 1 Mar 2012 15:31:01 Tony Lindgren wrote: I've pushed ams-delta branch that's based on -rc5 merged with what Arnd pulled yesterday as -rc1 has i2c-omap.c a compile bug for omap1. I've applied these two patches there as the second one depends on what got pulled: ARM: OMAP1: ams-delta: clean up init data section assignments ARM: OMAP1: ams-delta: fix incorrect section tags Thanks! Looks like your patch ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin causes the following error with CONFIG_DEBUG_SECTION_MISMATCH=y: arch/arm/mach-omap1/board-ams-delta.c:273:36: error: modem_nreset_config causes a section type conflict So care to update and repost that (and possibly the following two patches) with your missing fixes? OK, I will, in a couple of days. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 3/5] First set of omap1 related changes
On Wed, 29 Feb 2012 13:13:31 Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [120229 12:35]: On Wednesday 29 February 2012, Tony Lindgren wrote: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap omap1 Janusz Krzysztofik (7): ARM: OMAP1: ams-delta: register latch dependent devices later ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio ARM: OMAP1: ams-delta: supersede custom led device by leds- gpio LED: drop leds-ams-delta driver MTD: NAND: ams-delta: use GPIO instead of custom I/O omapfb: lcd_ams_delta: drive control lines over GPIO input: serio: ams-delta: toggle keyboard power over GPIO Since these are all for ams-delta, I pulled them into next/boards together with other board specific updates. OK makes sense. Any chance for the continuation series [1] as well as two section mismatch related fixes [2] [3] getting your attention? NB, that continuation series needs another section mismatch fix, which I was planing to submit once there was a stable base for it. Thanks, Janusz [1] http://www.spinics.net/lists/linux-omap/msg64146.html [2] http://www.spinics.net/lists/linux-omap/msg64441.html [3] http://www.spinics.net/lists/linux-omap/msg64442.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/11]O MAP/ASoC: Move and merge McBSP driver under ASoC
On Wednesday 15 of February 2012 17:56:15 Ujfalusi, Peter wrote: Hi, CC-ing Janusz, since he is the only one I know who have, and use OMAP1 with audio... Janusz: if your time allows would you be able to test this series on OMAP1 (it compiles...)? for OMAP1: Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP1: ams-delta: correct init data section assignments
On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:
There is no optimisation to adding __refdata to stuff. That's screaming
that you have lots of bugs here.
Thanks for your teaching. I find those aspects not very exhaustively documented
under Documentation/, so any hints are much appreciated.
-static struct map_desc ams_delta_io_desc[] __initdata = {
+static struct map_desc ams_delta_io_desc[] __initconst = {
You're not making this comst so don't change it to __initconst.
OK, however, I think there must be a bug in gcc, otherwise it should probably
never accept such wrong constructs, while sometimes it does (not only mine,
see [1]).
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initconst = {
This change probably adds a bug. Are you sure this will never be used
outside init context?
I may be wrong, but before I've changed this, and now once again, I've verified
that a copy of this data is made inside __init omap_init_fb() by means of a
structure assignment operation.
-static struct omap_usb_config ams_delta_usb_config __initdata = {
+static struct omap_usb_config ams_delta_usb_config __initdata_or_module
= {
Even if you don't have modules enabled, have you checked whether the
driver can be bound and unbound via
/sys/bus/platform/driver/name/{bind,unbind} ?
No, I didn't even think of it, I am afraid.
I suspect this is a bug.
Indeed, that data is not copied on init, only pointed to, moreover, the
ohci-omap driver provides bind/unbind opearations.
BTW, what are those bind/unbind operations intended for in case of a driver
dedicated to a non-hotplugable SoC hardware exclusively?
-static struct resource ams_delta_nand_resources[] = {
+static struct resource ams_delta_nand_resources[] __initconst_or_module
= {
This change definitely adds a bug. The resources are _used_ _all_ _the_
_time_ _the_ _device_ _is_ _registered_. Try catting /proc/iomem after
boot.
Indeed, I didn't think of that. I expected that standard init data of only
those devices which can be actually found during init should be copied for
runtime access, then all (found and not found) dropped instead of keeping them
all in memory for only some of them being actually used.
-static struct i2c_board_info ams_delta_camera_board_info[] = {
+static struct i2c_board_info __initconst_or_module
+ams_delta_camera_board_info[] = {
No. It's
static struct foo blah[] __whatever_init_attribute
not
static struct foo __whatever_init_attribute blah[]
I've no idea where this fucked idea came from but it's something that's
wasting a lot of review time with complaints like this about it.
My bad, I blindly copied that pattern from another broken example under
arch/arm instead of examining the docs carefully enough.
-static struct soc_camera_link ams_delta_iclink = {
+static struct soc_camera_link ams_delta_iclink __initconst_or_module =
{
Probably buggy.
Indeed. Even if the soc-camera-pdrv driver doesn't support
unbindind/rebinding, it doesn't seem to make a copy of that platform data,
only stores a pointer to it for runtime access, wich I missed.
-static struct platform_device *ams_delta_devices[] __initdata = {
+static struct platform_device *ams_delta_devices[] __initconst = {
Missing const. If you can't const it, don't put it in __initconst.
I gave up trying to use both const and __initconst together after my gcc-4.2.4
(and not only mine, see [1], [2]) refused to accept such constructs a few
times. Now I see that this false reporting may probably happen in presence of
other
incorrect uses of __initconst without const or __initdata with const.
Hopefully better patches will follow.
Thanks,
Janusz
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/062421.html
[2] http://permalink.gmane.org/gmane.linux.kernel.commits.head/202285
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP1: ams-delta: fix incorrect section tags
While resolving section mismatches introduced with recent patches
to for-next, a few dangerous, driver bind/unbind unaware section
tagging already present in mainline have been identified. Fix them.
Created and tested against linux-3.3-rc2.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 88909cc..41589ed 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -163,7 +163,7 @@ static struct omap_lcd_config ams_delta_lcd_config = {
.ctrl_name = internal,
};
-static struct omap_usb_config ams_delta_usb_config __initdata = {
+static struct omap_usb_config ams_delta_usb_config = {
.register_host = 1,
.hmc_mode = 16,
.pins[0]= 2,
@@ -202,7 +202,7 @@ static const struct matrix_keymap_data
ams_delta_keymap_data = {
.keymap_size= ARRAY_SIZE(ams_delta_keymap),
};
-static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
+static struct omap_kp_platform_data ams_delta_kp_data = {
.rows = 8,
.cols = 8,
.keymap_data= ams_delta_keymap_data,
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP1: ams-delta: clean up init data section assignments
The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced with recent Amstrad Delta patch series, some of them rising
up only when building with CONFIG_MODULES not set.
While being at it, section tagging of all init data found in the board
file have been revised and hopefully corrected and/or optimized.
Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 18 +-
drivers/input/serio/ams_delta_serio.c |2 +-
drivers/mtd/nand/ams-delta.c |2 +-
drivers/video/omap/lcd_ams_delta.c|2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..bfe6fd1 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -150,7 +150,7 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
}
};
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initdata = {
.ctrl_name = internal,
};
@@ -167,7 +167,7 @@ static struct omap_board_config_kernel ams_delta_config[]
__initdata = {
#define LATCH1_GPIO_BASE 232
#define LATCH1_NGPIO 8
-static struct resource latch1_resources[] __initconst = {
+static struct resource latch1_resources[] = {
[0] = {
.name = dat,
.start = LATCH1_PHYS,
@@ -176,7 +176,7 @@ static struct resource latch1_resources[] __initconst = {
},
};
-static struct bgpio_pdata latch1_pdata __initconst = {
+static struct bgpio_pdata latch1_pdata = {
.base = LATCH1_GPIO_BASE,
.ngpio = LATCH1_NGPIO,
};
@@ -191,7 +191,7 @@ static struct platform_device latch1_gpio_device = {
},
};
-static struct resource latch2_resources[] __initconst = {
+static struct resource latch2_resources[] = {
[0] = {
.name = dat,
.start = LATCH2_PHYS,
@@ -200,7 +200,7 @@ static struct resource latch2_resources[] __initconst = {
},
};
-static struct bgpio_pdata latch2_pdata __initconst = {
+static struct bgpio_pdata latch2_pdata = {
.base = AMS_DELTA_LATCH2_GPIO_BASE,
.ngpio = AMS_DELTA_LATCH2_NGPIO,
};
@@ -215,7 +215,7 @@ static struct platform_device latch2_gpio_device = {
},
};
-static struct gpio latch_gpios[] __initconst = {
+static const struct gpio latch_gpios[] __initconst = {
{
.gpio = LATCH1_GPIO_BASE + 6,
.flags = GPIOF_OUT_INIT_LOW,
@@ -322,7 +322,7 @@ static struct platform_device ams_delta_lcd_device = {
.id = -1,
};
-static struct gpio_led gpio_leds[] __initconst = {
+static const struct gpio_led gpio_leds[] __initconst = {
{
.name= camera,
.gpio= LATCH1_GPIO_BASE + 0,
@@ -358,7 +358,7 @@ static struct gpio_led gpio_leds[] __initconst = {
},
};
-static struct gpio_led_platform_data leds_pdata __initconst = {
+static const struct gpio_led_platform_data leds_pdata __initconst = {
.leds = gpio_leds,
.num_leds = ARRAY_SIZE(gpio_leds),
};
@@ -415,7 +415,7 @@ static struct platform_device *ams_delta_devices[]
__initdata = {
ams_delta_camera_device,
};
-static struct platform_device *late_devices[] __initconst = {
+static struct platform_device *late_devices[] __initdata = {
ams_delta_nand_device,
ams_delta_lcd_device,
};
diff --git a/drivers/input/serio/ams_delta_serio.c
b/drivers/input/serio/ams_delta_serio.c
index 0571e2e..bd5b10e 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -103,7 +103,7 @@ static void ams_delta_serio_close(struct serio *serio)
gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
}
-static struct gpio ams_delta_gpios[] __initconst_or_module = {
+static const struct gpio ams_delta_gpios[] __initconst_or_module = {
{
.gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
.flags = GPIOF_DIR_IN,
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 85934dc..7341695 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -145,7 +145,7 @@ static int ams_delta_nand_ready(struct mtd_info *mtd)
return gpio_get_value(AMS_DELTA_GPIO_PIN_NAND_RB);
}
-static struct gpio _mandatory_gpio[] __initconst_or_module = {
+static const struct gpio _mandatory_gpio[] = {
{
.gpio = AMS_DELTA_GPIO_PIN_NAND_NCE,
.flags = GPIOF_OUT_INIT_HIGH,
diff --git a/drivers/video/omap/lcd_ams_delta.c
b/drivers/video/omap/lcd_ams_delta.c
index 0e71e28..d3a3113 100644
--- a/drivers/video
[PATCH] ARM: OMAP1: ams-delta: clean up init data section assignments
The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced mostly with recent Amstrad Delta patch series, some of them
rising up only when building with CONFIG_MODULES not set.
While being at it, section assignments of all init data found in the
board file have been revised and hopefully optimised.
Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 35 +
drivers/input/serio/ams_delta_serio.c |2 +-
drivers/mtd/nand/ams-delta.c |2 +-
drivers/video/omap/lcd_ams_delta.c|2 +-
4 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..dc2455f 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -126,7 +126,7 @@ static const unsigned int ams_delta_keymap[] = {
#define LATCH2_PHYS0x0800
#define LATCH2_VIRT0xEC00
-static struct map_desc ams_delta_io_desc[] __initdata = {
+static struct map_desc ams_delta_io_desc[] __initconst = {
/* AMS_DELTA_LATCH1 */
{
.virtual= LATCH1_VIRT,
@@ -150,17 +150,17 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
}
};
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initconst = {
.ctrl_name = internal,
};
-static struct omap_usb_config ams_delta_usb_config __initdata = {
+static struct omap_usb_config ams_delta_usb_config __initdata_or_module = {
.register_host = 1,
.hmc_mode = 16,
.pins[0]= 2,
};
-static struct omap_board_config_kernel ams_delta_config[] __initdata = {
+static struct omap_board_config_kernel ams_delta_config[] __initconst = {
{ OMAP_TAG_LCD, ams_delta_lcd_config },
};
@@ -181,7 +181,7 @@ static struct bgpio_pdata latch1_pdata __initconst = {
.ngpio = LATCH1_NGPIO,
};
-static struct platform_device latch1_gpio_device = {
+static struct platform_device latch1_gpio_device __refdata = {
.name = basic-mmio-gpio,
.id = 0,
.resource = latch1_resources,
@@ -205,7 +205,7 @@ static struct bgpio_pdata latch2_pdata __initconst = {
.ngpio = AMS_DELTA_LATCH2_NGPIO,
};
-static struct platform_device latch2_gpio_device = {
+static struct platform_device latch2_gpio_device __refdata = {
.name = basic-mmio-gpio,
.id = 1,
.resource = latch2_resources,
@@ -271,7 +271,7 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask,
u16 value)
}
EXPORT_SYMBOL(ams_delta_latch_write);
-static struct resource ams_delta_nand_resources[] = {
+static struct resource ams_delta_nand_resources[] __initconst_or_module = {
[0] = {
.start = OMAP1_MPUIO_BASE,
.end= OMAP1_MPUIO_BASE +
@@ -280,14 +280,14 @@ static struct resource ams_delta_nand_resources[] = {
},
};
-static struct platform_device ams_delta_nand_device = {
+static struct platform_device ams_delta_nand_device __refdata = {
.name = ams-delta-nand,
.id = -1,
.num_resources = ARRAY_SIZE(ams_delta_nand_resources),
.resource = ams_delta_nand_resources,
};
-static struct resource ams_delta_kp_resources[] = {
+static struct resource ams_delta_kp_resources[] __initconst_or_module = {
[0] = {
.start = INT_KEYBOARD,
.end= INT_KEYBOARD,
@@ -300,14 +300,14 @@ static const struct matrix_keymap_data
ams_delta_keymap_data = {
.keymap_size= ARRAY_SIZE(ams_delta_keymap),
};
-static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
+static struct omap_kp_platform_data ams_delta_kp_data __initconst_or_module = {
.rows = 8,
.cols = 8,
.keymap_data= ams_delta_keymap_data,
.delay = 9,
};
-static struct platform_device ams_delta_kp_device = {
+static struct platform_device ams_delta_kp_device __refdata = {
.name = omap-keypad,
.id = -1,
.dev= {
@@ -363,7 +363,8 @@ static struct gpio_led_platform_data leds_pdata __initconst
= {
.num_leds = ARRAY_SIZE(gpio_leds),
};
-static struct i2c_board_info ams_delta_camera_board_info[] = {
+static struct i2c_board_info __initconst_or_module
+ams_delta_camera_board_info[] = {
{
I2C_BOARD_INFO(ov6650, 0x60),
},
@@ -387,7 +388,7 @@ static int ams_delta_camera_power(struct device *dev, int
power)
#define ams_delta_camera_power NULL
#endif
-static struct soc_camera_link ams_delta_iclink
Re: [PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs
On Wednesday 08 of February 2012 12:16:13 Igor Grinberg wrote: ... After updating omap1_defconfig, there are several section mismatch warnings seen. Hopefully, I will have time to fix those tomorrow (unless someone will be kind enough to fix them before me). Sound like introduced with my recent ams-delta patches, sorry. I'll have a look at them. Thanks, Janusz The mismatches are: WARNING: vmlinux.o(.data+0xb7e4): Section mismatch in reference from the variable latch1_gpio_device to the (unknown reference) .init.rodata:(unknown) The variable latch1_gpio_device references the (unknown reference) __initconst (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: vmlinux.o(.data+0xb8f4): Section mismatch in reference from the variable latch1_gpio_device to the (unknown reference) .init.rodata:(unknown) The variable latch1_gpio_device references the (unknown reference) __initconst (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: vmlinux.o(.data+0xb974): Section mismatch in reference from the variable latch2_gpio_device to the (unknown reference) .init.rodata:(unknown) The variable latch2_gpio_device references the (unknown reference) __initconst (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: vmlinux.o(.data+0xba84): Section mismatch in reference from the variable latch2_gpio_device to the (unknown reference) .init.rodata:(unknown) The variable latch2_gpio_device references the (unknown reference) __initconst (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: vmlinux.o(.data+0xbb04): Section mismatch in reference from the variable ams_delta_kp_device to the (unknown reference) .init.data:(unknown) The variable ams_delta_kp_device references the (unknown reference) __initdata (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESUBMIT][PATCH v2 1/4] ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin
The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available
as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down
(bring into/out of a reset state) two distinct on-board devices
simultaneously: the modem, and the voice codec. As a consequence, that
bit is, or can be, manipulated concurrently by two drivers, or their
platform provided hooks.
Instead of updating those drivers to use the gpiolib API as a new method
of controlling the MODEM_NRESET pin state, like it was done to other
drivers accessing latch2 pins, and still being vulnerable to potential
concurrency conflicts, or trying to solve that sharing issue with a
custom piece of code, set up a fixed regulator device on top of that
GPIO pin, with the intention of updating both drivers to manipulate that
regulator, not the GPIO pin directly.
Before the ASoC driver is updated and the modem platform data expanded
with a power management callback for switching its power, the
ams_delta_latch_write() function, which still provides the old API for
accessing latch2 functionality from not updated drivers, is modified to
toggle the regulator instead of the MODEM_NRESET GPIO pin. A helper
function provided for balancing the regulator enable/disable operations,
together with the consumer data needed for tracking the regulator state,
will be removed once the drivers are updated.
Depends on patch series ARM: OMAP1: ams-delta: replace custom I/O with
GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: Tony Lindgren t...@atomide.com
---
Changes against initial version:
* rename consumer setup elements to match their final, modem only
related purpose,
* initialize the regulator pointer and mutex before first use, then
omit testing that pointer against NULL value.
arch/arm/mach-omap1/Kconfig |2 +
arch/arm/mach-omap1/board-ams-delta.c | 104 +++--
2 files changed, 100 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index 5b1edba..4b6a774 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -157,6 +157,8 @@ config MACH_AMS_DELTA
select FIQ
select GPIO_GENERIC_PLATFORM
select LEDS_GPIO_REGISTER
+ select REGULATOR
+ select REGULATOR_FIXED_VOLTAGE
help
Support for the Amstrad E3 (codename Delta) videophone. Say Y here
if you have such a device.
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..43dcbda 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -18,7 +18,11 @@
#include linux/input.h
#include linux/interrupt.h
#include linux/leds.h
+#include linux/mutex.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/regulator/fixed.h
+#include linux/regulator/machine.h
#include linux/serial_8250.h
#include linux/export.h
@@ -237,11 +241,6 @@ static struct gpio latch_gpios[] __initconst = {
.label = scard_cmdvcc,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = modem_nreset,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC,
.flags = GPIOF_OUT_INIT_LOW,
.label = modem_codec,
@@ -258,6 +257,71 @@ static struct gpio latch_gpios[] __initconst = {
},
};
+static struct regulator_consumer_supply modem_nreset_consumers[] __initconst =
{
+ REGULATOR_SUPPLY(RESET#, serial8250.1),
+ REGULATOR_SUPPLY(POR, cx20442-codec),
+};
+
+static struct regulator_init_data modem_nreset_data __initconst = {
+ .constraints= {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .boot_on= 1,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(modem_nreset_consumers),
+ .consumer_supplies = modem_nreset_consumers,
+};
+
+static struct fixed_voltage_config modem_nreset_config __initconst = {
+ .supply_name= modem_nreset,
+ .microvolts = 330,
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ .startup_delay = 25000,
+ .enable_high= 1,
+ .enabled_at_boot= 1,
+ .init_data = modem_nreset_data,
+};
+
+static struct platform_device modem_nreset_device = {
+ .name = reg-fixed-voltage,
+ .id = -1,
+ .dev= {
+ .platform_data = modem_nreset_config,
+ },
+};
+
+struct modem_private_data {
+ struct regulator *regulator;
+ struct {
+ struct mutex lock;
+ bool enabled;
+ } consumer;
+};
+
+static int regulator_toggle(struct modem_private_data *priv, bool enable)
+{
+ int err = 0;
+
+ mutex_lock(priv-consumer.lock);
+ if (IS_ERR
[RESUBMIT][PATCH v2 3/4] ARM: OMAP1: ams-delta: update the modem to use regulator API
After the CX20442 codec driver already takes care of enabling the codec
power for itself, but before dropping the old bias control method from
the Amstrad Delta ASoC sound card file, which in fact keeps the modem
power always on, even after the ASoC device close for now, extend the
modem setup with a power management callback, which toggles the
regulator up to the modem's needs, reusing the previously set up
regulator consumer for this. Also, drop the MODEM_NRESET pin setup from
the modem initialization procedure, as this operation was already
ineffective since patch 1/4, and not needed because the regulator is set
up as initially enabled.
Depends on patch 1/4 ARM: OMAP1: ams-delta: set up a regulator over the
modem reset GPIO pin to apply cleanly, and requires patch 2/4 ASoC:
cx20442: add bias control over a platform provided regulator for the
sound card / codec bundle to still work.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: Tony Lindgren t...@atomide.com
---
No functional changes against initial version.
arch/arm/mach-omap1/board-ams-delta.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 43dcbda..cfcf871 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -526,6 +526,16 @@ static void __init ams_delta_init(void)
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
+static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
+{
+ struct modem_private_data *priv = port-private_data;
+
+ if (state == old)
+ return;
+
+ regulator_toggle(priv, state == 0);
+}
+
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
.membase= IOMEM(MODEM_VIRT),
@@ -536,6 +546,8 @@ static struct plat_serial8250_port ams_delta_modem_ports[]
= {
.iotype = UPIO_MEM,
.regshift = 1,
.uartclk= BASE_BAUD * 16,
+ .pm = modem_pm,
+ .private_data = modem_priv,
},
{ },
};
@@ -584,9 +596,8 @@ static int __init late_init(void)
mutex_init(modem_priv.consumer.lock);
modem_priv.regulator = ERR_PTR(-ENODEV);
- ams_delta_latch2_write(
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
+ ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC,
+ AMS_DELTA_LATCH2_MODEM_CODEC);
err = platform_device_register(ams_delta_modem_device);
if (err)
@@ -595,8 +606,9 @@ static int __init late_init(void)
/*
* Once the modem device is registered, the modem_nreset
* regulator can be requested on behalf of that device.
-* The regulator is used via ams_delta_latch_write()
-* by the modem and ASoC drivers until updated.
+* In addition to the modem .pm callback, that regulator
+* is still used via the ams_delta_latch_write() wrapper
+* by the ASoC driver until updated.
*/
modem_priv.regulator = regulator_get(ams_delta_modem_device.dev,
RESET#);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESUBMIT][PATCH v2 4/4] ASoC: OMAP: ams-delta: drop .set_bias_level callback
This functionality has just been implemented in the cx20442 codec
driver, no need to keep it here duplicated.
Once done, remove the no longer used AMS_DELTA_LATCH2_MODEM_NRESET
symbol from the board header file and a call to the regulator_toggle()
helper function from the old API wrapper found in the board file. While
being at it, simplify the way the modem .pm callback handles the
regulator and drop that helper function and its related consumer setup
completely.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Tony Lindgren t...@atomide.com
---
Changes against initial version:
* don't move consumer setup elements, now named to indicated their
modem related purpose, down the file,
* don't track the regulator enavble/disable state, compare new target
power state with the old one instead; thanks to Mark Brown for
suggesting this simplification,
* actually drop all references to AMS_DELTA_LATCH2_MODEM_NRESET.
arch/arm/mach-omap1/board-ams-delta.c | 42 +++-
arch/arm/plat-omap/include/plat/board-ams-delta.h |1 -
sound/soc/omap/ams-delta.c| 32
3 files changed, 7 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index cfcf871..6ab5331 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -18,7 +18,6 @@
#include linux/input.h
#include linux/interrupt.h
#include linux/leds.h
-#include linux/mutex.h
#include linux/platform_device.h
#include linux/regulator/consumer.h
#include linux/regulator/fixed.h
@@ -291,35 +290,8 @@ static struct platform_device modem_nreset_device = {
struct modem_private_data {
struct regulator *regulator;
- struct {
- struct mutex lock;
- bool enabled;
- } consumer;
};
-static int regulator_toggle(struct modem_private_data *priv, bool enable)
-{
- int err = 0;
-
- mutex_lock(priv-consumer.lock);
- if (IS_ERR(priv-regulator)) {
- err = PTR_ERR(priv-regulator);
- } else if (enable) {
- if (!priv-consumer.enabled) {
- err = regulator_enable(priv-regulator);
- priv-consumer.enabled = true;
- }
- } else {
- if (priv-consumer.enabled) {
- err = regulator_disable(priv-regulator);
- priv-consumer.enabled = false;
- }
- }
- mutex_unlock(priv-consumer.lock);
-
- return err;
-}
-
static struct modem_private_data modem_priv;
void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
@@ -330,8 +302,6 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask,
u16 value)
for (; bit ngpio; bit++, bitpos = bitpos 1) {
if (!(mask bitpos))
continue;
- else if (base + bit == AMS_DELTA_GPIO_PIN_MODEM_NRESET)
- regulator_toggle(modem_priv, (value bitpos) != 0);
else
gpio_set_value(base + bit, (value bitpos) != 0);
}
@@ -530,10 +500,16 @@ static void modem_pm(struct uart_port *port, unsigned int
state, unsigned old)
{
struct modem_private_data *priv = port-private_data;
+ if (IS_ERR(priv-regulator))
+ return;
+
if (state == old)
return;
- regulator_toggle(priv, state == 0);
+ if (state == 0)
+ regulator_enable(priv-regulator);
+ else if (old == 0)
+ regulator_disable(priv-regulator);
}
static struct plat_serial8250_port ams_delta_modem_ports[] = {
@@ -593,7 +569,6 @@ static int __init late_init(void)
gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
/* Initialize the modem_nreset regulator consumer before use */
- mutex_init(modem_priv.consumer.lock);
modem_priv.regulator = ERR_PTR(-ENODEV);
ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC,
@@ -606,9 +581,6 @@ static int __init late_init(void)
/*
* Once the modem device is registered, the modem_nreset
* regulator can be requested on behalf of that device.
-* In addition to the modem .pm callback, that regulator
-* is still used via the ams_delta_latch_write() wrapper
-* by the ASoC driver until updated.
*/
modem_priv.regulator = regulator_get(ams_delta_modem_device.dev,
RESET#);
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index 027e79e..ad6f865 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
@@ -30,7 +30,6 @@
#define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
#define AMD_DELTA_LATCH2_SCARD_CMDVCC
[RESUBMIT][PATCH v2 0/4] Amstrad Delta: access MODEM_RESET GPIO pin over a regulator
The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down (bring into/out of a reset state) two distinct on-board devices simultaneously: the modem, and the voice codec. As a consequence, that bit is, or can be, manipulated concurrently by two drivers, or their platform provided hooks. Instead of updating those drivers to use the gpiolib API as a new method of controlling the MODEM_NRESET pin state, like it was done to other drivers accessing latch2 pins, and still being vulnerable to potential concurrency conflicts, or trying to solve that sharing issue with a custom piece of code, set up a fixed regulator device on top of that GPIO pin and update both drivers to manipulate that regulator, not the GPIO pin directly. I'm resubmitting v2 of this series, originally posted on 30 Dec 2011, with Mark's Ack already collected, now rebased on top of current linux-omap/omap1 tip, commit 967809bd7faf71ddc29c8081e0f21db8b201a0f4. Since patch 2/4, ASoC: cx20442: add bias control over a platform provided regulator, has already been applied by Liam (thanks!) and is already present in mainline, I've omitted it from this submission. v2 changes against initial version: * in both the codec and the modem callbacks, don't track the regulator enable/disable state, compare new target bias level (the codec case) or power state (the modem case) with the old value instead; thanks to Mark Brown who suggested this solution, * a few other minor changes, mostly stylistic. Janusz Krzysztofik (3): ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin ARM: OMAP1: ams-delta: update the modem to use regulator API ASoC: OMAP: ams-delta: drop .set_bias_level callback arch/arm/mach-omap1/Kconfig |2 + arch/arm/mach-omap1/board-ams-delta.c | 94 +++-- arch/arm/plat-omap/include/plat/board-ams-delta.h |1 - sound/soc/omap/ams-delta.c| 32 --- 4 files changed, 87 insertions(+), 42 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] Amstrad Delta: access MODEM_RESET GPIO pin over a regulator
The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down (bring into/out of a reset state) two distinct on-board devices simultaneously: the modem, and the voice codec. As a consequence, that bit is, or can be, manipulated concurrently by two drivers, or their platform provided hooks. Instead of updating those drivers to use the gpiolib API as a new method of controlling the MODEM_NRESET pin state, like it was done to other drivers accessing latch2 pins, and still being vulnerable to potential concurrency conflicts, or trying to solve that sharing issue with a custom piece of code, set up a fixed regulator device on top of that GPIO pin and update both drivers to manipulate that regulator, not the GPIO pin directly. Changes against initial version: * in both the codec and the modem callbacks, don't track the regulator enable/disable state, compare new targert bias level (the codec case) or power state (the modem case) with the old value instead; thanks to Mark Brown who suggested this solution, * a few other minor changes, mostly stylistic. Janusz Krzysztofik (4): ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin ASoC: cx20442: add bias control over a platform provided regulator ARM: OMAP1: ams-delta: update the modem to use regulator API ASoC: OMAP: ams-delta: drop .set_bias_level callback arch/arm/mach-omap1/Kconfig |2 + arch/arm/mach-omap1/board-ams-delta.c | 94 +++-- arch/arm/plat-omap/include/plat/board-ams-delta.h |1 - sound/soc/codecs/cx20442.c| 48 ++- sound/soc/omap/ams-delta.c| 34 5 files changed, 133 insertions(+), 46 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin
The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available
as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down
(bring into/out of a reset state) two distinct on-board devices
simultaneously: the modem, and the voice codec. As a consequence, that
bit is, or can be, manipulated concurrently by two drivers, or their
platform provided hooks.
Instead of updating those drivers to use the gpiolib API as a new method
of controlling the MODEM_NRESET pin state, like it was done to other
drivers accessing latch2 pins, and still being vulnerable to potential
concurrency conflicts, or trying to solve that sharing issue with a
custom piece of code, set up a fixed regulator device on top of that
GPIO pin, with the intention of updating both drivers to manipulate that
regulator, not the GPIO pin directly.
Before the ASoC driver is updated and the modem platform data expanded
with a power management callback for switching its power, the
ams_delta_latch_write() function, which still provides the old API for
accessing latch2 functionality from not updated drivers, is modified to
toggle the regulator instead of the MODEM_NRESET GPIO pin. A helper
function provided for balancing the regulator enable/disable operations,
together with the consumer data needed for tracking the regulator state,
will be removed once the drivers are updated.
Depends on patch series ARM: OMAP1: ams-delta: replace custom I/O with
GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes against initial version:
* rename consumer setup elements to match their final, modem only
related purpose,
* initialize the regulator pointer and mutex before first use, then
omit testing that pointer against NULL value.
arch/arm/mach-omap1/Kconfig |2 +
arch/arm/mach-omap1/board-ams-delta.c | 104 +++--
2 files changed, 100 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index 5b1edba..4b6a774 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -157,6 +157,8 @@ config MACH_AMS_DELTA
select FIQ
select GPIO_GENERIC_PLATFORM
select LEDS_GPIO_REGISTER
+ select REGULATOR
+ select REGULATOR_FIXED_VOLTAGE
help
Support for the Amstrad E3 (codename Delta) videophone. Say Y here
if you have such a device.
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 673cf21..074d3b5 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -18,7 +18,11 @@
#include linux/input.h
#include linux/interrupt.h
#include linux/leds.h
+#include linux/mutex.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/regulator/fixed.h
+#include linux/regulator/machine.h
#include linux/serial_8250.h
#include linux/export.h
@@ -237,11 +241,6 @@ static struct gpio latch_gpios[] __initconst = {
.label = scard_cmdvcc,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = modem_nreset,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC,
.flags = GPIOF_OUT_INIT_LOW,
.label = modem_codec,
@@ -258,6 +257,71 @@ static struct gpio latch_gpios[] __initconst = {
},
};
+static struct regulator_consumer_supply modem_nreset_consumers[] __initconst =
{
+ REGULATOR_SUPPLY(RESET#, serial8250.1),
+ REGULATOR_SUPPLY(POR, cx20442-codec),
+};
+
+static struct regulator_init_data modem_nreset_data __initconst = {
+ .constraints= {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .boot_on= 1,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(modem_nreset_consumers),
+ .consumer_supplies = modem_nreset_consumers,
+};
+
+static struct fixed_voltage_config modem_nreset_config __initconst = {
+ .supply_name= modem_nreset,
+ .microvolts = 330,
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ .startup_delay = 25000,
+ .enable_high= 1,
+ .enabled_at_boot= 1,
+ .init_data = modem_nreset_data,
+};
+
+static struct platform_device modem_nreset_device = {
+ .name = reg-fixed-voltage,
+ .id = -1,
+ .dev= {
+ .platform_data = modem_nreset_config,
+ },
+};
+
+struct modem_private_data {
+ struct regulator *regulator;
+ struct {
+ struct mutex lock;
+ bool enabled;
+ } consumer;
+};
+
+static int regulator_toggle(struct modem_private_data *priv, bool enable)
+{
+ int err = 0;
+
+ mutex_lock(priv-consumer.lock);
+ if (IS_ERR(priv-regulator
[PATCH v2 2/4] ASoC: cx20442: add bias control over a platform provided regulator
Now that a regulator device for controlling the codec chip reset state
over a platform agnostic regulator API is available on the only board
using this driver so far, extend the driver with a bias control function
which will request virtual power to the codec chip from that virtual
regulator, and will supersede the present implementation existing at the
sound card level.
Thanks to the regulator sharing mechanism, both the old (the sound card)
and the new (the codec) implementations should coexist smoothly until
the sound card file is updated. For this to work as expected, update the
sound card .set_bias_level callback to not touch codec-dapm.bias_level.
While extending the cx20442 structure, drop unused control_type member.
Created against linxu-3.2-rc6, tested on top of patch 1/4 ARM: OMAP1:
ams-delta: set up a regulator over the modem reset GPIO pin.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes against initial version:
* don't track the regulator enable/disable state, compare new bias
level against the old one instead; thanks to Mark Brown for suggesting
this change,
* update the Amstrad Delta sound card file to not touch the codec bias
level for the above change to work as expected,
* display a warning if getting the regulator fails.
sound/soc/codecs/cx20442.c | 48 ++-
sound/soc/omap/ams-delta.c |8 ++
2 files changed, 49 insertions(+), 7 deletions(-)
diff --git a/sound/soc/codecs/cx20442.c b/sound/soc/codecs/cx20442.c
index bc7067d..941c527 100644
--- a/sound/soc/codecs/cx20442.c
+++ b/sound/soc/codecs/cx20442.c
@@ -16,6 +16,7 @@
#include linux/tty.h
#include linux/slab.h
#include linux/module.h
+#include linux/regulator/consumer.h
#include sound/core.h
#include sound/initval.h
@@ -25,8 +26,8 @@
struct cx20442_priv {
- enum snd_soc_control_type control_type;
void *control_data;
+ struct regulator *por;
};
#define CX20442_PM 0x0
@@ -324,6 +325,38 @@ static struct snd_soc_dai_driver cx20442_dai = {
},
};
+static int cx20442_set_bias_level(struct snd_soc_codec *codec,
+ enum snd_soc_bias_level level)
+{
+ struct cx20442_priv *cx20442 = snd_soc_codec_get_drvdata(codec);
+ int err = 0;
+
+ switch (level) {
+ case SND_SOC_BIAS_PREPARE:
+ if (codec-dapm.bias_level != SND_SOC_BIAS_STANDBY)
+ break;
+ if (IS_ERR(cx20442-por))
+ err = PTR_ERR(cx20442-por);
+ else
+ err = regulator_enable(cx20442-por);
+ break;
+ case SND_SOC_BIAS_STANDBY:
+ if (codec-dapm.bias_level != SND_SOC_BIAS_PREPARE)
+ break;
+ if (IS_ERR(cx20442-por))
+ err = PTR_ERR(cx20442-por);
+ else
+ err = regulator_disable(cx20442-por);
+ break;
+ default:
+ break;
+ }
+ if (!err)
+ codec-dapm.bias_level = level;
+
+ return err;
+}
+
static int cx20442_codec_probe(struct snd_soc_codec *codec)
{
struct cx20442_priv *cx20442;
@@ -331,9 +364,13 @@ static int cx20442_codec_probe(struct snd_soc_codec *codec)
cx20442 = kzalloc(sizeof(struct cx20442_priv), GFP_KERNEL);
if (cx20442 == NULL)
return -ENOMEM;
- snd_soc_codec_set_drvdata(codec, cx20442);
+ cx20442-por = regulator_get(codec-dev, POR);
+ if (IS_ERR(cx20442-por))
+ dev_warn(codec-dev, failed to get the regulator);
cx20442-control_data = NULL;
+
+ snd_soc_codec_set_drvdata(codec, cx20442);
codec-hw_write = NULL;
codec-card-pop_time = 0;
@@ -350,6 +387,12 @@ static int cx20442_codec_remove(struct snd_soc_codec
*codec)
tty_hangup(tty);
}
+ if (!IS_ERR(cx20442-por)) {
+ /* should be already in STANDBY, hence disabled */
+ regulator_put(cx20442-por);
+ }
+
+ snd_soc_codec_set_drvdata(codec, NULL);
kfree(cx20442);
return 0;
}
@@ -359,6 +402,7 @@ static const u8 cx20442_reg;
static struct snd_soc_codec_driver cx20442_codec_dev = {
.probe =cx20442_codec_probe,
.remove = cx20442_codec_remove,
+ .set_bias_level = cx20442_set_bias_level,
.reg_cache_default = cx20442_reg,
.reg_cache_size = 1,
.reg_word_size = sizeof(u8),
diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c
index be81bc7..0462c7e 100644
--- a/sound/soc/omap/ams-delta.c
+++ b/sound/soc/omap/ams-delta.c
@@ -431,22 +431,20 @@ static int ams_delta_set_bias_level(struct snd_soc_card
*card,
struct snd_soc_dapm_context *dapm,
enum snd_soc_bias_level level)
{
- struct snd_soc_codec *codec = card-rtd-codec
[PATCH v2 4/4] ASoC: OMAP: ams-delta: drop .set_bias_level callback
This functionality has just been implemented in the cx20442 codec
driver, no need to keep it here duplicated.
Once done, remove the no longer used AMS_DELTA_LATCH2_MODEM_NRESET
symbol from the board header file and a call to the regulator_toggle()
helper function from the old API wrapper found in the board file. While
being at it, simplify the way the modem .pm callback handles the
regulator, and drop that no longer used helper function and its related
consumer setup elements completely.
Depends on patch 3/4 ARM: OMAP1: ams-delta: update the modem to use
regulator API
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes against initial version:
* don't move consumer setup elements, now named to indicated their
modem related purpose, down the file,
* don't track the regulator enavble/disable state, compare new target
power state with the old one instead; thanks to Mark Brown for
suggesting this simplification,
* actually drop all references to AMS_DELTA_LATCH2_MODEM_NRESET.
arch/arm/mach-omap1/board-ams-delta.c | 42 +++-
arch/arm/plat-omap/include/plat/board-ams-delta.h |1 -
sound/soc/omap/ams-delta.c| 32
3 files changed, 7 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 3389237..704fee6 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -18,7 +18,6 @@
#include linux/input.h
#include linux/interrupt.h
#include linux/leds.h
-#include linux/mutex.h
#include linux/platform_device.h
#include linux/regulator/consumer.h
#include linux/regulator/fixed.h
@@ -291,35 +290,8 @@ static struct platform_device modem_nreset_device = {
struct modem_private_data {
struct regulator *regulator;
- struct {
- struct mutex lock;
- bool enabled;
- } consumer;
};
-static int regulator_toggle(struct modem_private_data *priv, bool enable)
-{
- int err = 0;
-
- mutex_lock(priv-consumer.lock);
- if (IS_ERR(priv-regulator)) {
- err = PTR_ERR(priv-regulator);
- } else if (enable) {
- if (!priv-consumer.enabled) {
- err = regulator_enable(priv-regulator);
- priv-consumer.enabled = true;
- }
- } else {
- if (priv-consumer.enabled) {
- err = regulator_disable(priv-regulator);
- priv-consumer.enabled = false;
- }
- }
- mutex_unlock(priv-consumer.lock);
-
- return err;
-}
-
static struct modem_private_data modem_priv;
void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
@@ -330,8 +302,6 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask,
u16 value)
for (; bit ngpio; bit++, bitpos = bitpos 1) {
if (!(mask bitpos))
continue;
- else if (base + bit == AMS_DELTA_GPIO_PIN_MODEM_NRESET)
- regulator_toggle(modem_priv, (value bitpos) != 0);
else
gpio_set_value(base + bit, (value bitpos) != 0);
}
@@ -530,10 +500,16 @@ static void modem_pm(struct uart_port *port, unsigned int
state, unsigned old)
{
struct modem_private_data *priv = port-private_data;
+ if (IS_ERR(priv-regulator))
+ return;
+
if (state == old)
return;
- regulator_toggle(priv, state == 0);
+ if (state == 0)
+ regulator_enable(priv-regulator);
+ else if (old == 0)
+ regulator_disable(priv-regulator);
}
static struct plat_serial8250_port ams_delta_modem_ports[] = {
@@ -593,7 +569,6 @@ static int __init late_init(void)
gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
/* Initialize the modem_nreset regulator consumer before use */
- mutex_init(modem_priv.consumer.lock);
modem_priv.regulator = ERR_PTR(-ENODEV);
ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC,
@@ -606,9 +581,6 @@ static int __init late_init(void)
/*
* Once the modem device is registered, the modem_nreset
* regulator can be requested on behalf of that device.
-* In addition to the modem .pm callback, that regulator
-* is still used via the ams_delta_latch_write() wrapper
-* by the ASoC driver until updated.
*/
modem_priv.regulator = regulator_get(ams_delta_modem_device.dev,
RESET#);
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index 027e79e..ad6f865 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
@@ -30,7 +30,6 @@
#define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
#define
[PATCH v2 3/4] ARM: OMAP1: ams-delta: update the modem to use regulator API
After the CX20442 codec driver already takes care of enabling the codec
power for itself, but before dropping the old bias control method from
the Amstrad Delta ASoC sound card file, which in fact keeps the modem
power always on, even after the ASoC device close for now, extend the
modem setup with a power management callback, which toggles the
regulator up to the modem's needs, reusing the previously set up
regulator consumer for this. Also, drop the MODEM_NRESET pin setup from
the modem initialization procedure, as this operation was already
ineffective since patch 1/4, and not needed because the regulator is set
up as initially enabled.
Depends on patch 1/4 ARM: OMAP1: ams-delta: set up a regulator over the
modem reset GPIO pin to apply cleanly, and requires patch 2/4 ASoC:
cx20442: add bias control over a platform provided regulator for the
sound card / codec bundle to still work.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
No functional changes against initial version.
arch/arm/mach-omap1/board-ams-delta.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 074d3b5..3389237 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -526,6 +526,16 @@ static void __init ams_delta_init(void)
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
+static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
+{
+ struct modem_private_data *priv = port-private_data;
+
+ if (state == old)
+ return;
+
+ regulator_toggle(priv, state == 0);
+}
+
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
.membase= IOMEM(MODEM_VIRT),
@@ -536,6 +546,8 @@ static struct plat_serial8250_port ams_delta_modem_ports[]
= {
.iotype = UPIO_MEM,
.regshift = 1,
.uartclk= BASE_BAUD * 16,
+ .pm = modem_pm,
+ .private_data = modem_priv,
},
{ },
};
@@ -584,9 +596,8 @@ static int __init late_init(void)
mutex_init(modem_priv.consumer.lock);
modem_priv.regulator = ERR_PTR(-ENODEV);
- ams_delta_latch2_write(
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
+ ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC,
+ AMS_DELTA_LATCH2_MODEM_CODEC);
err = platform_device_register(ams_delta_modem_device);
if (err)
@@ -595,8 +606,9 @@ static int __init late_init(void)
/*
* Once the modem device is registered, the modem_nreset
* regulator can be requested on behalf of that device.
-* The regulator is used via ams_delta_latch_write()
-* by the modem and ASoC drivers until updated.
+* In addition to the modem .pm callback, that regulator
+* is still used via the ams_delta_latch_write() wrapper
+* by the ASoC driver until updated.
*/
modem_priv.regulator = regulator_get(ams_delta_modem_device.dev,
RESET#);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 2/4] ASoC: cx20442: add bias control over a platform provided regulator
On Monday 26 of December 2011 at 12:02:01, Mark Brown wrote:
On Sat, Dec 24, 2011 at 12:12:22AM +0100, Janusz Krzysztofik wrote:
+ case SND_SOC_BIAS_ON:
+ case SND_SOC_BIAS_PREPARE:
+ if (IS_ERR(cx20442-por.regulator)) {
+ err = PTR_ERR(cx20442-por.regulator);
+ } else if (!cx20442-por.enabled) {
+ err = regulator_enable(cx20442-por.regulator);
+ if (!err)
+ cx20442-por.enabled = true;
+ }
+ break;
+ case SND_SOC_BIAS_STANDBY:
+ case SND_SOC_BIAS_OFF:
+ if (IS_ERR(cx20442-por.regulator)) {
+ err = PTR_ERR(cx20442-por.regulator);
+ } else if (cx20442-por.enabled) {
+ err = regulator_disable(cx20442-por.regulator);
+ if (!err)
+ cx20442-por.enabled = false;
+ }
+ }
+ mutex_unlock(cx20442-por.lock);
You can avoid the mutex and simplify the code by relying on the fact
that the only possible transitions are:
OFF - STANDBY - PREPARE - ON
which would look a lot more natural - you shouldn't need to remember if
the regulator is enabled, you should just turn it on in the STANDBY to
PREPARE transition and turn it off in the ON to PREPARE or PREPARE to
STANDBY transitions.
Can I assume STANDBY or OFF at the time the codec .remove method is
called? If not, is there a helper function available which can be called
in order to perform all those ON - PREPARE - STANDBY [- OFF] transitions
before calling regulator_put()?
Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 2/4] ASoC: cx20442: add bias control over a platform provided regulator
On Monday 26 of December 2011 at 12:02:01, Mark Brown wrote:
On Sat, Dec 24, 2011 at 12:12:22AM +0100, Janusz Krzysztofik wrote:
+ case SND_SOC_BIAS_ON:
+ case SND_SOC_BIAS_PREPARE:
+ if (IS_ERR(cx20442-por.regulator)) {
+ err = PTR_ERR(cx20442-por.regulator);
+ } else if (!cx20442-por.enabled) {
+ err = regulator_enable(cx20442-por.regulator);
+ if (!err)
+ cx20442-por.enabled = true;
+ }
+ break;
+ case SND_SOC_BIAS_STANDBY:
+ case SND_SOC_BIAS_OFF:
+ if (IS_ERR(cx20442-por.regulator)) {
+ err = PTR_ERR(cx20442-por.regulator);
+ } else if (cx20442-por.enabled) {
+ err = regulator_disable(cx20442-por.regulator);
+ if (!err)
+ cx20442-por.enabled = false;
+ }
+ }
+ mutex_unlock(cx20442-por.lock);
You can avoid the mutex and simplify the code by relying on the fact
that the only possible transitions are:
OFF - STANDBY - PREPARE - ON
which would look a lot more natural - you shouldn't need to remember if
the regulator is enabled, you should just turn it on in the STANDBY to
PREPARE transition and turn it off in the ON to PREPARE or PREPARE to
STANDBY transitions.
OK, will do, thanks for the hint.
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ASoC: OMAP: ams-delta: drop .set_bias_level callback
On Monday 26 of December 2011 at 12:03:49, Mark Brown wrote:
On Sat, Dec 24, 2011 at 12:12:24AM +0100, Janusz Krzysztofik wrote:
+struct regulator_consumer_data {
+ struct mutex lock;
+ struct regulator *regulator;
+ bool enabled;
+};
+
+static int regulator_toggle(struct regulator_consumer_data *consumer,
+ bool enable)
+{
+ int err = 0;
+
+ if (!consumer-regulator)
+ return -ENODEV;
+
+ mutex_lock(consumer-lock);
+ if (IS_ERR(consumer-regulator)) {
+ err = PTR_ERR(consumer-regulator);
+ } else if (enable) {
+ if (!consumer-enabled) {
+ err = regulator_enable(consumer-regulator);
+ consumer-enabled = true;
+ }
+ } else {
+ if (consumer-enabled) {
+ err = regulator_disable(consumer-regulator);
+ consumer-enabled = false;
+ }
+ }
+ mutex_unlock(consumer-lock);
+
+ return err;
+}
+
Why's this code not been dropped and what is it for?
It is, and will be, used by another regulator consumer, the modem. The
device is controlled by the generic serial8250 driver, extended with a
custom .pm hook which enables/disables the regulator. The above code,
temporarily shared with the ASoC device before updated, is now just
moved down the board file where the modem related bits are located (see
patch 3/4).
Any hints like that for the codec driver?
Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ASoC: OMAP: ams-delta: drop .set_bias_level callback
On Monday 26 of December 2011 at 18:23:50, Mark Brown wrote: On Mon, Dec 26, 2011 at 01:30:22PM +0100, Janusz Krzysztofik wrote: Why's this code not been dropped and what is it for? It is, and will be, used by another regulator consumer, the modem. The device is controlled by the generic serial8250 driver, extended with a custom .pm hook which enables/disables the regulator. The above code, temporarily shared with the ASoC device before updated, is now just moved down the board file where the modem related bits are located (see patch 3/4). Any hints like that for the codec driver? The main thing that looks bad here is that you're keeping track of the state of the regulator by hand. It may be that the upper layers aren't reference counting in which case you might need this but it certainly looks very suspicious as-is. OK, I can try to examine how the serial8250 driver tracks the device power state when calling the .pm hook and if it looks safe to drop that regulator state manual tracking. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Amstrad Delta: access MODEM_RESET GPIO pin over a regulator
The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down (bring into/out of a reset state) two distinct on-board devices simultaneously: the modem, and the voice codec. As a consequence, that bit is, or can be, manipulated concurrently by two drivers, or their platform provided hooks. Instead of updating those drivers to use the gpiolib API as a new method of controlling the MODEM_NRESET pin state, like it was done to other drivers accessing latch2 pins, and still being vulnerable to potential concurrency conflicts, or trying to solve that sharing issue with a custom piece of code, set up a fixed regulator device on top of that GPIO pin and update both drivers to manipulate that regulator, not the GPIO pin directly. Janusz Krzysztofik (4): ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin ASoC: cx20442: add bias control over a platform provided regulator ARM: OMAP1: ams-delta: update the modem to use regulator API ASoC: OMAP: ams-delta: drop .set_bias_level callback arch/arm/mach-omap1/Kconfig |2 + arch/arm/mach-omap1/board-ams-delta.c | 116 +++-- arch/arm/plat-omap/include/plat/board-ams-delta.h |1 - sound/soc/codecs/cx20442.c| 58 ++- sound/soc/omap/ams-delta.c| 34 -- 5 files changed, 165 insertions(+), 46 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin
The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available
as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down
(bring into/out of a reset state) two distinct on-board devices
simultaneously: the modem, and the voice codec. As a consequence, that
bit is, or can be, manipulated concurrently by two drivers, or their
platform provided hooks.
Instead of updating those drivers to use the gpiolib API as a new method
of controlling the MODEM_NRESET pin state, like it was done to other
drivers accessing latch2 pins, and still being vulnerable to potential
concurrency conflicts, or trying to solve that sharing issue with a
custom piece of code, set up a fixed regulator device on top of that
GPIO pin, with the intention of updating both drivers to manipulate that
regulator, not the GPIO pin directly.
Before the ASoC driver is updated to use that regulator, and the modem
platform data expanded with a power management callback for switching
its power, the ams_delta_latch_write() function, which still provides
the old API for accessing latch2 functionality from not updated drivers,
is modified to toggle the regulator instead of the MODEM_NRESET GPIO
pin. A helper function provided for balancing the regulator
enable/disable operations, together with the regulator consumer data
needed for maintaining its state, will be reused by the above mentioned
modem power management callback once implemented.
Depends on patch series ARM: OMAP1: ams-delta: replace custom I/O with
GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/Kconfig |2 +
arch/arm/mach-omap1/board-ams-delta.c | 103 +++--
2 files changed, 99 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index 5b1edba..4b6a774 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -157,6 +157,8 @@ config MACH_AMS_DELTA
select FIQ
select GPIO_GENERIC_PLATFORM
select LEDS_GPIO_REGISTER
+ select REGULATOR
+ select REGULATOR_FIXED_VOLTAGE
help
Support for the Amstrad E3 (codename Delta) videophone. Say Y here
if you have such a device.
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 673cf21..b5a1a3b 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -18,7 +18,11 @@
#include linux/input.h
#include linux/interrupt.h
#include linux/leds.h
+#include linux/mutex.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/regulator/fixed.h
+#include linux/regulator/machine.h
#include linux/serial_8250.h
#include linux/export.h
@@ -237,11 +241,6 @@ static struct gpio latch_gpios[] __initconst = {
.label = scard_cmdvcc,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = modem_nreset,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC,
.flags = GPIOF_OUT_INIT_LOW,
.label = modem_codec,
@@ -258,6 +257,73 @@ static struct gpio latch_gpios[] __initconst = {
},
};
+static struct regulator_consumer_supply modem_nreset_consumers[] __initconst =
{
+ REGULATOR_SUPPLY(RESET#, serial8250.1),
+ REGULATOR_SUPPLY(POR, cx20442-codec),
+};
+
+static struct regulator_init_data modem_nreset_data __initconst = {
+ .constraints= {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .boot_on= 1,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(modem_nreset_consumers),
+ .consumer_supplies = modem_nreset_consumers,
+};
+
+static struct fixed_voltage_config modem_nreset_config __initconst = {
+ .supply_name= modem_nreset,
+ .microvolts = 330,
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ .startup_delay = 25000,
+ .enable_high= 1,
+ .enabled_at_boot= 1,
+ .init_data = modem_nreset_data,
+};
+
+static struct platform_device modem_nreset_device = {
+ .name = reg-fixed-voltage,
+ .id = -1,
+ .dev= {
+ .platform_data = modem_nreset_config,
+ },
+};
+
+struct regulator_consumer_data {
+ struct mutex lock;
+ struct regulator *regulator;
+ bool enabled;
+};
+
+static int regulator_toggle(struct regulator_consumer_data *consumer,
+ bool enable)
+{
+ int err = 0;
+
+ if (!consumer-regulator)
+ return -ENODEV;
+
+ mutex_lock(consumer-lock);
+ if (IS_ERR(consumer-regulator)) {
+ err = PTR_ERR(consumer-regulator);
+ } else if (enable) {
+ if (!consumer-enabled
[PATCH 2/4] ASoC: cx20442: add bias control over a platform provided regulator
Now that a regulator device for controlling the codec chip reset state
over a platform agnostic regulator API is available on the only board
using this driver so far, extend the driver with a bias control function
which will request virtual power to the codec chip from that virtual
regulator, and will supersede the present implementation existing at the
sound card level.
Thanks to the regulator sharing mechanism, both the old (the sound card)
and the new (the codec) implementations will coexist smoothly until the
sound card file is updated.
While extending the cx20442 structure, drop unused control_type member.
Created against linxu-3.2-rc6, tested on top of patch 1/4 ARM: OMAP1:
ams-delta: set up regulator over modem reset GPIO pin.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
sound/soc/codecs/cx20442.c | 58 ++-
1 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/cx20442.c b/sound/soc/codecs/cx20442.c
index bc7067d..d159c23 100644
--- a/sound/soc/codecs/cx20442.c
+++ b/sound/soc/codecs/cx20442.c
@@ -16,6 +16,7 @@
#include linux/tty.h
#include linux/slab.h
#include linux/module.h
+#include linux/regulator/consumer.h
#include sound/core.h
#include sound/initval.h
@@ -25,8 +26,12 @@
struct cx20442_priv {
- enum snd_soc_control_type control_type;
void *control_data;
+ struct {
+ struct mutex lock;
+ struct regulator *regulator;
+ bool enabled;
+ } por;
};
#define CX20442_PM 0x0
@@ -324,6 +329,41 @@ static struct snd_soc_dai_driver cx20442_dai = {
},
};
+static int cx20442_set_bias_level(struct snd_soc_codec *codec,
+ enum snd_soc_bias_level level)
+{
+ struct cx20442_priv *cx20442 = snd_soc_codec_get_drvdata(codec);
+ int err = 0;
+
+ mutex_lock(cx20442-por.lock);
+ switch (level) {
+ case SND_SOC_BIAS_ON:
+ case SND_SOC_BIAS_PREPARE:
+ if (IS_ERR(cx20442-por.regulator)) {
+ err = PTR_ERR(cx20442-por.regulator);
+ } else if (!cx20442-por.enabled) {
+ err = regulator_enable(cx20442-por.regulator);
+ if (!err)
+ cx20442-por.enabled = true;
+ }
+ break;
+ case SND_SOC_BIAS_STANDBY:
+ case SND_SOC_BIAS_OFF:
+ if (IS_ERR(cx20442-por.regulator)) {
+ err = PTR_ERR(cx20442-por.regulator);
+ } else if (cx20442-por.enabled) {
+ err = regulator_disable(cx20442-por.regulator);
+ if (!err)
+ cx20442-por.enabled = false;
+ }
+ }
+ mutex_unlock(cx20442-por.lock);
+ if (!err)
+ codec-dapm.bias_level = level;
+
+ return err;
+}
+
static int cx20442_codec_probe(struct snd_soc_codec *codec)
{
struct cx20442_priv *cx20442;
@@ -331,9 +371,12 @@ static int cx20442_codec_probe(struct snd_soc_codec *codec)
cx20442 = kzalloc(sizeof(struct cx20442_priv), GFP_KERNEL);
if (cx20442 == NULL)
return -ENOMEM;
- snd_soc_codec_set_drvdata(codec, cx20442);
+ mutex_init(cx20442-por.lock);
+ cx20442-por.regulator = regulator_get(codec-dev, POR);
cx20442-control_data = NULL;
+
+ snd_soc_codec_set_drvdata(codec, cx20442);
codec-hw_write = NULL;
codec-card-pop_time = 0;
@@ -350,6 +393,16 @@ static int cx20442_codec_remove(struct snd_soc_codec
*codec)
tty_hangup(tty);
}
+ mutex_lock(cx20442-por.lock);
+ if (!IS_ERR(cx20442-por.regulator)) {
+ if (cx20442-por.enabled)
+ regulator_disable(cx20442-por.regulator);
+ regulator_put(cx20442-por.regulator);
+ cx20442-por.regulator = ERR_PTR(-ENODEV);
+ }
+ mutex_unlock(cx20442-por.lock);
+
+ snd_soc_codec_set_drvdata(codec, NULL);
kfree(cx20442);
return 0;
}
@@ -359,6 +412,7 @@ static const u8 cx20442_reg;
static struct snd_soc_codec_driver cx20442_codec_dev = {
.probe =cx20442_codec_probe,
.remove = cx20442_codec_remove,
+ .set_bias_level = cx20442_set_bias_level,
.reg_cache_default = cx20442_reg,
.reg_cache_size = 1,
.reg_word_size = sizeof(u8),
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: OMAP1: ams-delta: update the modem to use regulator API
After the CX20442 codec driver already takes care of enabling the codec
power for itself, but before dropping the old bias control method from
the Amstrad Delta ASoC sound card file, which in fact keeps the modem
power always on, even after the ASoC device close for now, extend the
modem setup with a power management callback, which toggles the
regulator up to the modem's needs, reusing the previously set up
regulator consumer for this. Also, drop the MODEM_NRESET pin setup from
the modem initialization procedure, as this operation was already
ineffective since patch 1/4, and not needed because the regulator is set
up as initially enabled.
Depends on patch 1/4 ARM: OMAP1: ams-delta: set up regulator over modem
reset GPIO pin to apply cleanly, and requires patch 2/4 ASoC: cx20442:
add bias control over a platform provided regulator for the sound card
/ codec bundle to still work correctly in coexistence with the modem.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 20 +++-
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index b5a1a3b..9b52aeb 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -528,6 +528,14 @@ static void __init ams_delta_init(void)
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
+static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
+{
+ struct regulator_consumer_data *consumer = port-private_data;
+
+ if (state != old)
+ regulator_toggle(consumer, state == 0);
+}
+
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
.membase= IOMEM(MODEM_VIRT),
@@ -538,6 +546,8 @@ static struct plat_serial8250_port ams_delta_modem_ports[]
= {
.iotype = UPIO_MEM,
.regshift = 1,
.uartclk= BASE_BAUD * 16,
+ .pm = modem_pm,
+ .private_data = modem_nreset,
},
{ },
};
@@ -582,9 +592,8 @@ static int __init late_init(void)
}
gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
- ams_delta_latch2_write(
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
+ ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC,
+ AMS_DELTA_LATCH2_MODEM_CODEC);
err = platform_device_register(ams_delta_modem_device);
if (err)
@@ -593,8 +602,9 @@ static int __init late_init(void)
/*
* Once the modem device is registered, the modem_nreset
* regulator can be requested on behalf of that device.
-* The regulator is used via ams_delta_latch_write()
-* by the modem and ASoC drivers until updated.
+* In addition to the modem .pm callback, that regulator
+* is still used via the ams_delta_latch_write() wrapper
+* by the ASoC driver until updated.
*/
mutex_init(modem_nreset.lock);
modem_nreset.regulator = regulator_get(ams_delta_modem_device.dev,
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ASoC: OMAP: ams-delta: drop .set_bias_level callback
This functionality has just been implemented in the cx20442 codec
driver, no need to keep it here duplicated.
Once done, remove the no longer needed AMS_DELTA_LATCH2_MODEM_NRESET
symbol from the Amstrad Delta header file, and a call to the
regulator_toggle() helper function from the old API wrapper found in the
board file. While being at it, move that function definition, together
with the regulator consumer related data structure, down to the modem
related section for better readability.
Depends on patch 3/4 ARM: OMAP1: ams-delta: update the modem to use
regulator API
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 75 ++---
arch/arm/plat-omap/include/plat/board-ams-delta.h |1 -
sound/soc/omap/ams-delta.c| 34 -
3 files changed, 36 insertions(+), 74 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 9b52aeb..945c4db 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -289,41 +289,6 @@ static struct platform_device modem_nreset_device = {
},
};
-struct regulator_consumer_data {
- struct mutex lock;
- struct regulator *regulator;
- bool enabled;
-};
-
-static int regulator_toggle(struct regulator_consumer_data *consumer,
- bool enable)
-{
- int err = 0;
-
- if (!consumer-regulator)
- return -ENODEV;
-
- mutex_lock(consumer-lock);
- if (IS_ERR(consumer-regulator)) {
- err = PTR_ERR(consumer-regulator);
- } else if (enable) {
- if (!consumer-enabled) {
- err = regulator_enable(consumer-regulator);
- consumer-enabled = true;
- }
- } else {
- if (consumer-enabled) {
- err = regulator_disable(consumer-regulator);
- consumer-enabled = false;
- }
- }
- mutex_unlock(consumer-lock);
-
- return err;
-}
-
-static struct regulator_consumer_data modem_nreset;
-
void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
{
int bit = 0;
@@ -333,7 +298,7 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask,
u16 value)
if (!(mask bitpos))
continue;
if (base + bit == AMS_DELTA_GPIO_PIN_MODEM_NRESET)
- regulator_toggle(modem_nreset, (value bitpos) != 0);
+ continue;
else
gpio_set_value(base + bit, (value bitpos) != 0);
}
@@ -528,6 +493,39 @@ static void __init ams_delta_init(void)
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
+struct regulator_consumer_data {
+ struct mutex lock;
+ struct regulator *regulator;
+ bool enabled;
+};
+
+static int regulator_toggle(struct regulator_consumer_data *consumer,
+ bool enable)
+{
+ int err = 0;
+
+ if (!consumer-regulator)
+ return -ENODEV;
+
+ mutex_lock(consumer-lock);
+ if (IS_ERR(consumer-regulator)) {
+ err = PTR_ERR(consumer-regulator);
+ } else if (enable) {
+ if (!consumer-enabled) {
+ err = regulator_enable(consumer-regulator);
+ consumer-enabled = true;
+ }
+ } else {
+ if (consumer-enabled) {
+ err = regulator_disable(consumer-regulator);
+ consumer-enabled = false;
+ }
+ }
+ mutex_unlock(consumer-lock);
+
+ return err;
+}
+
static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
{
struct regulator_consumer_data *consumer = port-private_data;
@@ -536,6 +534,8 @@ static void modem_pm(struct uart_port *port, unsigned int
state, unsigned old)
regulator_toggle(consumer, state == 0);
}
+static struct regulator_consumer_data modem_nreset;
+
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
.membase= IOMEM(MODEM_VIRT),
@@ -602,9 +602,6 @@ static int __init late_init(void)
/*
* Once the modem device is registered, the modem_nreset
* regulator can be requested on behalf of that device.
-* In addition to the modem .pm callback, that regulator
-* is still used via the ams_delta_latch_write() wrapper
-* by the ASoC driver until updated.
*/
mutex_init(modem_nreset.lock);
modem_nreset.regulator = regulator_get(ams_delta_modem_device.dev,
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index 027e79e..ad6f865 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include
Re: [PATCH v2 1/7 v2] ARM: OMAP1: ams-delta: register latch dependent devices later
On Wednesday 21 of December 2011 at 21:07:29, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111221 11:20]:
On Wednesday 21 of December 2011 at 20:08:15, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111220 13:23]:
In preparation to converting Amstrad Delta on-board latches to
basic_mmio_gpio devices, registration of platform devices which depend
on latches and will require initialization of their GPIO pins first,
should be moved out of .machine_init down to late_initcall level, as the
gpio-generic driver is not available until device_initcall time. The
latch reset operation, which will be replaced with GPIO initialization,
must also be moved to late_initcall for the same reason.
Since there was already another, separate arch_initcall function for
setting up one of those latch dependent devices, the on-board modem
device, reuse that function, i.e., rename it to a name that matches the
new purpose, extend with other device setup relocated from
.machine_init, and move down to the late_initcall level.
While being at it, add missing gpio_free() in case the modem platform
device registration fails.
Thanks to Tony Lindgren t...@atomide.com who suggested this approach
instead of shifting up the gpio-generic driver initialization.
In addition, defer registration of the Amstrad Delta ASoC and serio
devices, done from their device driver files, until late_initcall time,
as those drivers will depend on their GPIO pins already requested from
the board late_init() function until updated to register their GPIO pins
themselves.
Created and tested against linux-3.2-rc6.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Planning to apply this series. Dmitry, care to ack the
drivers/input/serio/
related change?
Don't we need Jarkko's or Mark's or Liam's ack as well for the change to
the sound/soc/omap/ams-delta.c file?
Yes, you're right.
Jarkko, Mark or Liam, care to ack this change, moving the Amstrad Delta
sound card registration to late_initcall?
Thanks,
Janusz
Changes since the initial version of this patch:
* use late_initcall() unconditionally in modules, requested by Russell
King (thanks!); an updated patch 7/7 will follow,
* in the changelog message, move credits to Tony up a bit, since the
person responsible for other changes (he might not necessarily like)
is me, not him ;).
Comments copied from this patch initial submission:
This patch was not present in the initial submission, it replaces the
old patch 1/10, providing an alternative solution not touching the
gpio-generic driver.
arch/arm/mach-omap1/board-ams-delta.c | 28
drivers/input/serio/ams_delta_serio.c |2 +-
sound/soc/omap/ams-delta.c|2 +-
3 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index b0f15d2..50987c9 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -275,11 +275,14 @@ static struct omap1_cam_platform_data
ams_delta_camera_platform_data = {
};
static struct platform_device *ams_delta_devices[] __initdata = {
- ams_delta_nand_device,
ams_delta_kp_device,
+ ams_delta_camera_device,
+};
+
+static struct platform_device *late_devices[] __initdata = {
+ ams_delta_nand_device,
ams_delta_lcd_device,
ams_delta_led_device,
- ams_delta_camera_device,
};
static void __init ams_delta_init(void)
@@ -307,9 +310,6 @@ static void __init ams_delta_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
- /* Clear latch2 (NAND, LCD, modem enable) */
- ams_delta_latch2_write(~0, 0);
-
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
#ifdef CONFIG_LEDS_TRIGGERS
@@ -345,13 +345,18 @@ static struct platform_device
ams_delta_modem_device = {
},
};
-static int __init ams_delta_modem_init(void)
+static int __init late_init(void)
{
int err;
if (!machine_is_ams_delta())
return -ENODEV;
+ /* Clear latch2 (NAND, LCD, modem enable) */
+ ams_delta_latch2_write(~0, 0);
+
+ platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
+
omap_cfg_reg(M14_1510_GPIO2);
ams_delta_modem_ports[0].irq =
gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
@@ -367,9 +372,16 @@ static int __init ams_delta_modem_init(void
Re: [PATCH v2 5/7] MTD: NAND: ams-delta: use GPIO instead of custom I/O
On Wednesday 21 of December 2011 at 20:12:12, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 14:41]: Don't use Amstrad Delta custom I/O functions for controlling the device, use GPIO API instead. While being at it, add missing gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB). Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Cc: David Woodhouse dw...@infradead.org Cc: Tony Lindgren t...@atomide.com Artem, care to ack this one? BTW, following the get_maintainer.pl script suggestions, I tried to include Artem in the Cc: list, but that script provided me with an invalid Artem's email address at nokia.com, and I gave up once my email gateway refused to accept that message. Now I've verified that several half or more year old commits signed by Artem were the sources of that apparently outdated information. Looks like the get_maintainer.pl script needs improvement, or should be used with care by people who don't follow all email address changes ;). Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7 v2] ARM: OMAP1: ams-delta: register latch dependent devices later
On Wednesday 21 of December 2011 at 20:08:15, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111220 13:23]:
In preparation to converting Amstrad Delta on-board latches to
basic_mmio_gpio devices, registration of platform devices which depend
on latches and will require initialization of their GPIO pins first,
should be moved out of .machine_init down to late_initcall level, as the
gpio-generic driver is not available until device_initcall time. The
latch reset operation, which will be replaced with GPIO initialization,
must also be moved to late_initcall for the same reason.
Since there was already another, separate arch_initcall function for
setting up one of those latch dependent devices, the on-board modem
device, reuse that function, i.e., rename it to a name that matches the
new purpose, extend with other device setup relocated from
.machine_init, and move down to the late_initcall level.
While being at it, add missing gpio_free() in case the modem platform
device registration fails.
Thanks to Tony Lindgren t...@atomide.com who suggested this approach
instead of shifting up the gpio-generic driver initialization.
In addition, defer registration of the Amstrad Delta ASoC and serio
devices, done from their device driver files, until late_initcall time,
as those drivers will depend on their GPIO pins already requested from
the board late_init() function until updated to register their GPIO pins
themselves.
Created and tested against linux-3.2-rc6.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Planning to apply this series. Dmitry, care to ack the drivers/input/serio/
related change?
Don't we need Jarkko's or Mark's or Liam's ack as well for the change to
the sound/soc/omap/ams-delta.c file?
Thanks,
Janusz
Regards,
Tony
---
Changes since the initial version of this patch:
* use late_initcall() unconditionally in modules, requested by Russell
King (thanks!); an updated patch 7/7 will follow,
* in the changelog message, move credits to Tony up a bit, since the
person responsible for other changes (he might not necessarily like)
is me, not him ;).
Comments copied from this patch initial submission:
This patch was not present in the initial submission, it replaces the
old patch 1/10, providing an alternative solution not touching the
gpio-generic driver.
arch/arm/mach-omap1/board-ams-delta.c | 28
drivers/input/serio/ams_delta_serio.c |2 +-
sound/soc/omap/ams-delta.c|2 +-
3 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index b0f15d2..50987c9 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -275,11 +275,14 @@ static struct omap1_cam_platform_data
ams_delta_camera_platform_data = {
};
static struct platform_device *ams_delta_devices[] __initdata = {
- ams_delta_nand_device,
ams_delta_kp_device,
+ ams_delta_camera_device,
+};
+
+static struct platform_device *late_devices[] __initdata = {
+ ams_delta_nand_device,
ams_delta_lcd_device,
ams_delta_led_device,
- ams_delta_camera_device,
};
static void __init ams_delta_init(void)
@@ -307,9 +310,6 @@ static void __init ams_delta_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
- /* Clear latch2 (NAND, LCD, modem enable) */
- ams_delta_latch2_write(~0, 0);
-
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
#ifdef CONFIG_LEDS_TRIGGERS
@@ -345,13 +345,18 @@ static struct platform_device ams_delta_modem_device
= {
},
};
-static int __init ams_delta_modem_init(void)
+static int __init late_init(void)
{
int err;
if (!machine_is_ams_delta())
return -ENODEV;
+ /* Clear latch2 (NAND, LCD, modem enable) */
+ ams_delta_latch2_write(~0, 0);
+
+ platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
+
omap_cfg_reg(M14_1510_GPIO2);
ams_delta_modem_ports[0].irq =
gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
@@ -367,9 +372,16 @@ static int __init ams_delta_modem_init(void)
AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
- return platform_device_register(ams_delta_modem_device);
+ err = platform_device_register(ams_delta_modem_device);
+ if (err)
+ goto gpio_free;
+ return 0;
+
+gpio_free:
+ gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
+ return err;
}
-arch_initcall(ams_delta_modem_init);
+late_initcall(late_init);
static void __init ams_delta_map_io(void)
{
diff --git a/drivers/input
Re: [PATCH] input: serio: ams-delta: toggle keyboard power over GPIO
On Wednesday 21 of December 2011 at 20:09:45, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111220 13:39]:
Don't use Amstrad Delta custom I/O functions once GPIO interface is
available for the underlying hardware.
While requesting and initializing GPIO pins used, also take care of one
extra pin KEYBRD_DATAOUT which, even if not used by the driver, belongs
to the device and affects its functioning.
Once done, move the driver initialization back to the device_initcall
level, reverting the temporary chane introduced with patch 1/7 ARM:
OMAP1: ams-delta: register latch dependent devices later. That change
is no longer required once the driver takes care of registering used
GPIO pins, and it's better to initialize the device before others using
the latch2 based GPIO pins, otherwise a garbage is reported on boot,
perhaps due to random data already captured by the FIQ handler while the
keyboard related latch bits are written with random values during
initialization of those other latch2 dependent devices.
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
I'm assuming Dmitry's ack for an earlier version of this patch also
covers this one when applying.
Hi Dmitry,
Can we assume your ack still valid for this version?
Thanks,
Janusz
Regards,
Tony
---
Hi,
I'm submitting only this one refreshed on top of updated 1/7. All others
(2/7-6/7) don't require any refresh, can be rebased smoothly.
Thanks,
Janusz
Changes against version 2:
* refreshed on top of updated patch 1/7 v2,
* changelog: corrected patch 1/7 summary (was inaccurate).
Changes against initial version:
* was 9/10,
* rebased on top of v2 of patch 2/7, just in case,
* moved AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT pin handling from the board
code to the driver,
* reverted a temporary change to the driver initcall level, introduced
by the new solution provided with patch 1/7.
arch/arm/mach-omap1/board-ams-delta.c | 10
arch/arm/plat-omap/include/plat/board-ams-delta.h |2 -
drivers/input/serio/ams_delta_serio.c | 53
:x 3 files changed, 32 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 3aba8f9..673cf21 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -227,16 +227,6 @@ static struct gpio latch_gpios[] __initconst = {
.label = dockit2,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = keybrd_pwr,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = keybrd_dataout,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_SCARD_RSTIN,
.flags = GPIOF_OUT_INIT_LOW,
.label = scard_rstin,
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index e9ad673..027e79e 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
@@ -28,8 +28,6 @@
#if defined (CONFIG_MACH_AMS_DELTA)
-#define AMD_DELTA_LATCH2_KEYBRD_PWR0x0100
-#define AMD_DELTA_LATCH2_KEYBRD_DATA 0x0200
#define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
#define AMD_DELTA_LATCH2_SCARD_CMDVCC 0x0800
#define AMS_DELTA_LATCH2_MODEM_NRESET 0x1000
diff --git a/drivers/input/serio/ams_delta_serio.c
b/drivers/input/serio/ams_delta_serio.c
index 835d37a..ef1ec40 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -92,8 +92,7 @@ static irqreturn_t ams_delta_serio_interrupt(int irq,
void *dev_id)
static int ams_delta_serio_open(struct serio *serio)
{
/* enable keyboard */
- ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR,
- AMD_DELTA_LATCH2_KEYBRD_PWR);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 1);
return 0;
}
@@ -101,9 +100,32 @@ static int ams_delta_serio_open(struct serio *serio)
static void ams_delta_serio_close(struct serio *serio)
{
/* disable keyboard */
- ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR, 0);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
}
+static struct gpio _gpios[] __initconst_or_module = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
+ .flags = GPIOF_DIR_IN,
+ .label = serio-data,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_CLK,
+ .flags = GPIOF_DIR_IN,
+ .label = serio-clock,
+ },
+ {
+ .gpio
Re: [PATCH 07/10] ASoC: OMAP: ams-delta: Drive modem/codec pins over GPIO API
On Wednesday 21 of December 2011 at 19:33:44, Liam Girdwood wrote: On Sun, 2011-12-11 at 21:12 +0100, Janusz Krzysztofik wrote: Don't use Amstrad Delta custom I/O functions any longer, replace them with GPIO. Old pin definitions, no longer used by the modem bits either, can be dropped. Depends on patch 2/10 ARM: OMAP1: Convert Amstrad E3 latches to basic_mmio_gpio. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Applied. Hi, I'm sorry, but I've probably missed to infrom you explicitly, i.e. other than in a cover letter to v2 of this series, that this particular patch has been dropped from the series. I've already started working on an alternative solution, which I intend to submit as a separate set. It will be free of potentail problems with two devices, a modem and the sound card, accessing the same GPIO pins concurrently. For the MODEM_NRESET pin I've already set up a virtual regulator on top of it, and for the MODEM_CODEC pin I'll probably choose a virtual clock (pinmux would match the hardware more closely here, but it looks too complicated to me). Moreover, I've already started to move all those GPIO pin related functions, i.e. bias control, digital mute and line discipline interaction, from the board file to the codec driver, where all those seem to belong. Having this patch applied will conflict with the regultor and the clock solutions, taking control over those two GPIO pins. Please revert this patch, or reset it if still possible. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7][RESEND] ARM: OMAP1: ams-delta: register latch dependent devices later
On Tuesday 20 of December 2011 at 19:06:11, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 14:57]: Resending because of a typo in the Cc: list, sorry. 8-- In preparation to converting Amstrad Delta on-board latches to basic_mmio_gpio devices, registration of platform devices which depend on latches and will require initialization of their GPIO pins first, should be moved out of .machine_init down to late_initcall level, as the gpio-generic driver is not available until device_initcall time. The latch reset operation, which will be replaced with GPIO initialization, must also be moved to late_initcall for the same reason. Since there was already another, separate arch_initcall function for setting up one of those latch dependent devices, the on-board modem device, reuse that function, i.e., rename it to a name that matches the new purpose, extend with other device setup relocated from .machine_init, and move down to the late_initcall level. While being at it, add missing gpio_free() in case the modem platform device registration fails. In addition, defer registration of the Amstrad Delta ASoC and serio devices, done from their device driver files, until late_initcall time, as those drivers will depend on their GPIO pins already requested from the board late_init() function until updated to register their GPIO pins themselves. Thanks to Tony Lindgren t...@atomide.com who suggested this approach instead of shifting up the gpio-generic driver initialization. ... --- a/drivers/input/serio/ams_delta_serio.c +++ b/drivers/input/serio/ams_delta_serio.c @@ -165,6 +165,9 @@ serio: kfree(ams_delta_serio); return err; } +#ifndef MODULE +late_initcall(ams_delta_serio_init); +#else module_init(ams_delta_serio_init); static void __exit ams_delta_serio_exit(void) @@ -175,3 +178,4 @@ static void __exit ams_delta_serio_exit(void) gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA); } module_exit(ams_delta_serio_exit); +#endif diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c index ccb8a6a..1764a3b 100644 --- a/sound/soc/omap/ams-delta.c +++ b/sound/soc/omap/ams-delta.c @@ -636,6 +636,9 @@ err: platform_device_put(ams_delta_audio_platform_device); return ret; } +#ifndef MODULE +late_initcall(ams_delta_module_init); +#else module_init(ams_delta_module_init); static void __exit ams_delta_module_exit(void) @@ -657,6 +660,7 @@ static void __exit ams_delta_module_exit(void) platform_device_unregister(ams_delta_audio_platform_device); } module_exit(ams_delta_module_exit); +#endif MODULE_AUTHOR(Janusz Krzysztofik jkrzy...@tis.icnet.pl); MODULE_DESCRIPTION(ALSA SoC driver for Amstrad E3 (Delta) videophone); This looks a bit odd.. I think these drivers should be converted to a proper platform_driver so you can get rid of the machine_is_ams_delta check in the init. Then you can rely on the probe to match the device. Mostly true, but first of all, I don't pretend to solve all problems with all Amstrad Delta specific drivers in this patch series. I'm concentrating on converting latches to GPIO pins, and updating those drivers to access those pins with gpiolib API instead of accessing the latches with the board specific API. Nothing more. Now, regarding the serio driver, you are absolutely right, the device registration could be better moved out of the driver file to the board file. I'll probably do this some time in the future, once I'm ready with the latches related stuff, i.e. the ams_delta_latch_write() is finally removed from the board file as no longer used by any driver, and find some spare time again. For now, I'm moving that serio device/driver initialization to late_initcall with patch 2/7, and back to device_initcall once converted to gpiolib (patch 7/7). Is this acceptable? If not, let's drop those forward and back moves, and the driver will get broken with 2/7, but get repaired with 7/7, OK? Regarding the sound card: the sound/soc/omap/ams-delta.c file is not a device driver per se, but rather a piece of code which sets up a platform device representing the sound card, i.e., provides platform device description and platform data, including device specific callbacks, to be used by the generic 'soc-audio' driver. There is no single platform_driver_register() called from that file, only platform_device_register() or alike. That code seems to belong logically to the board setup, but was always maintained, among 12 others, and for reasons not known to me with my relatively short experience as a kernel developer, inside the sound/soc/omap/ subtree, not under arch/arm/mach- omap1/. Like all those 12 others, including sdp4430 which is quite recent I guess, it makes use of the machine_is_* function as if it was a part of a board files set. Then, the only
Re: [alsa-devel] [PATCH v2 1/7][RESEND] ARM: OMAP1: ams-delta: register latch dependent devices later
On Tuesday 20 of December 2011 at 21:40:46, Russell King - ARM Linux wrote: On Tue, Dec 20, 2011 at 12:28:32AM +0100, Janusz Krzysztofik wrote: diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c index d4d08bd..56ffd7c 100644 --- a/drivers/input/serio/ams_delta_serio.c +++ b/drivers/input/serio/ams_delta_serio.c @@ -165,6 +165,9 @@ serio: kfree(ams_delta_serio); return err; } +#ifndef MODULE +late_initcall(ams_delta_serio_init); +#else module_init(ams_delta_serio_init); static void __exit ams_delta_serio_exit(void) @@ -175,3 +178,4 @@ static void __exit ams_delta_serio_exit(void) gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA); } module_exit(ams_delta_serio_exit); +#endif It's worth noting: #ifndef MODULE #define late_initcall(fn) __define_initcall(7,fn,7) #else /* MODULE */ #define late_initcall(fn) module_init(fn) So really, all these ifndefs aren't required. Just change the module_init() to late_initcall(). Thanks, I'll follow your pattern. My reason for using those ifdefery was a comment still found in include/linux/init.h: #else /* MODULE */ /* Don't use these in modules, but some people do... */ #define early_initcall(fn) module_init(fn) #define core_initcall(fn) module_init(fn) ... #define late_initcall(fn) module_init(fn) Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7 v2] ARM: OMAP1: ams-delta: register latch dependent devices later
In preparation to converting Amstrad Delta on-board latches to
basic_mmio_gpio devices, registration of platform devices which depend
on latches and will require initialization of their GPIO pins first,
should be moved out of .machine_init down to late_initcall level, as the
gpio-generic driver is not available until device_initcall time. The
latch reset operation, which will be replaced with GPIO initialization,
must also be moved to late_initcall for the same reason.
Since there was already another, separate arch_initcall function for
setting up one of those latch dependent devices, the on-board modem
device, reuse that function, i.e., rename it to a name that matches the
new purpose, extend with other device setup relocated from
.machine_init, and move down to the late_initcall level.
While being at it, add missing gpio_free() in case the modem platform
device registration fails.
Thanks to Tony Lindgren t...@atomide.com who suggested this approach
instead of shifting up the gpio-generic driver initialization.
In addition, defer registration of the Amstrad Delta ASoC and serio
devices, done from their device driver files, until late_initcall time,
as those drivers will depend on their GPIO pins already requested from
the board late_init() function until updated to register their GPIO pins
themselves.
Created and tested against linux-3.2-rc6.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes since the initial version of this patch:
* use late_initcall() unconditionally in modules, requested by Russell
King (thanks!); an updated patch 7/7 will follow,
* in the changelog message, move credits to Tony up a bit, since the
person responsible for other changes (he might not necessarily like)
is me, not him ;).
Comments copied from this patch initial submission:
This patch was not present in the initial submission, it replaces the
old patch 1/10, providing an alternative solution not touching the
gpio-generic driver.
arch/arm/mach-omap1/board-ams-delta.c | 28
drivers/input/serio/ams_delta_serio.c |2 +-
sound/soc/omap/ams-delta.c|2 +-
3 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index b0f15d2..50987c9 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -275,11 +275,14 @@ static struct omap1_cam_platform_data
ams_delta_camera_platform_data = {
};
static struct platform_device *ams_delta_devices[] __initdata = {
- ams_delta_nand_device,
ams_delta_kp_device,
+ ams_delta_camera_device,
+};
+
+static struct platform_device *late_devices[] __initdata = {
+ ams_delta_nand_device,
ams_delta_lcd_device,
ams_delta_led_device,
- ams_delta_camera_device,
};
static void __init ams_delta_init(void)
@@ -307,9 +310,6 @@ static void __init ams_delta_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
- /* Clear latch2 (NAND, LCD, modem enable) */
- ams_delta_latch2_write(~0, 0);
-
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
#ifdef CONFIG_LEDS_TRIGGERS
@@ -345,13 +345,18 @@ static struct platform_device ams_delta_modem_device = {
},
};
-static int __init ams_delta_modem_init(void)
+static int __init late_init(void)
{
int err;
if (!machine_is_ams_delta())
return -ENODEV;
+ /* Clear latch2 (NAND, LCD, modem enable) */
+ ams_delta_latch2_write(~0, 0);
+
+ platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
+
omap_cfg_reg(M14_1510_GPIO2);
ams_delta_modem_ports[0].irq =
gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
@@ -367,9 +372,16 @@ static int __init ams_delta_modem_init(void)
AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
- return platform_device_register(ams_delta_modem_device);
+ err = platform_device_register(ams_delta_modem_device);
+ if (err)
+ goto gpio_free;
+ return 0;
+
+gpio_free:
+ gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
+ return err;
}
-arch_initcall(ams_delta_modem_init);
+late_initcall(late_init);
static void __init ams_delta_map_io(void)
{
diff --git a/drivers/input/serio/ams_delta_serio.c
b/drivers/input/serio/ams_delta_serio.c
index d4d08bd..835d37a 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -165,7 +165,7 @@ serio:
kfree(ams_delta_serio);
return err;
}
-module_init(ams_delta_serio_init);
+late_initcall(ams_delta_serio_init);
static void __exit ams_delta_serio_exit(void)
{
diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c
index ccb8a6a..be81bc7
[PATCH] input: serio: ams-delta: toggle keyboard power over GPIO
Don't use Amstrad Delta custom I/O functions once GPIO interface is
available for the underlying hardware.
While requesting and initializing GPIO pins used, also take care of one
extra pin KEYBRD_DATAOUT which, even if not used by the driver, belongs
to the device and affects its functioning.
Once done, move the driver initialization back to the device_initcall
level, reverting the temporary chane introduced with patch 1/7 ARM:
OMAP1: ams-delta: register latch dependent devices later. That change
is no longer required once the driver takes care of registering used
GPIO pins, and it's better to initialize the device before others using
the latch2 based GPIO pins, otherwise a garbage is reported on boot,
perhaps due to random data already captured by the FIQ handler while the
keyboard related latch bits are written with random values during
initialization of those other latch2 dependent devices.
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Hi,
I'm submitting only this one refreshed on top of updated 1/7. All others
(2/7-6/7) don't require any refresh, can be rebased smoothly.
Thanks,
Janusz
Changes against version 2:
* refreshed on top of updated patch 1/7 v2,
* changelog: corrected patch 1/7 summary (was inaccurate).
Changes against initial version:
* was 9/10,
* rebased on top of v2 of patch 2/7, just in case,
* moved AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT pin handling from the board
code to the driver,
* reverted a temporary change to the driver initcall level, introduced
by the new solution provided with patch 1/7.
arch/arm/mach-omap1/board-ams-delta.c | 10
arch/arm/plat-omap/include/plat/board-ams-delta.h |2 -
drivers/input/serio/ams_delta_serio.c | 53
:x 3 files changed, 32 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 3aba8f9..673cf21 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -227,16 +227,6 @@ static struct gpio latch_gpios[] __initconst = {
.label = dockit2,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = keybrd_pwr,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = keybrd_dataout,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_SCARD_RSTIN,
.flags = GPIOF_OUT_INIT_LOW,
.label = scard_rstin,
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index e9ad673..027e79e 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
@@ -28,8 +28,6 @@
#if defined (CONFIG_MACH_AMS_DELTA)
-#define AMD_DELTA_LATCH2_KEYBRD_PWR0x0100
-#define AMD_DELTA_LATCH2_KEYBRD_DATA 0x0200
#define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
#define AMD_DELTA_LATCH2_SCARD_CMDVCC 0x0800
#define AMS_DELTA_LATCH2_MODEM_NRESET 0x1000
diff --git a/drivers/input/serio/ams_delta_serio.c
b/drivers/input/serio/ams_delta_serio.c
index 835d37a..ef1ec40 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -92,8 +92,7 @@ static irqreturn_t ams_delta_serio_interrupt(int irq, void
*dev_id)
static int ams_delta_serio_open(struct serio *serio)
{
/* enable keyboard */
- ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR,
- AMD_DELTA_LATCH2_KEYBRD_PWR);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 1);
return 0;
}
@@ -101,9 +100,32 @@ static int ams_delta_serio_open(struct serio *serio)
static void ams_delta_serio_close(struct serio *serio)
{
/* disable keyboard */
- ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR, 0);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
}
+static struct gpio _gpios[] __initconst_or_module = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
+ .flags = GPIOF_DIR_IN,
+ .label = serio-data,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_CLK,
+ .flags = GPIOF_DIR_IN,
+ .label = serio-clock,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = serio-power,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = serio-dataout,
+ },
+};
+
static int __init ams_delta_serio_init(void)
{
int err;
@@ -123,19 +145,11 @@ static int __init ams_delta_serio_init(void)
strlcpy
[PATCH v2 0/7] ARM: OMAP1: ams-delta: replace custom I/O with GPIO
The Amstrad Delta board has two extra output ports used for driving input lines of different on-board devices. Those ports are now controlled with custom functions, provided by the board arch code and used by several device drivers. The idea behind the series is to replace those custom I/O functions with gpiolib API. This way, existing drivers can be made less platform dependent, and some of them perhaps even superseded with generic GPIO based drivers after the board platform device descriptions are converted. Moreover, should a new driver for the on-board Smart Card controller ever be created, it could be designed as a generic GPIO based driver, not a custom one. Changes against initial version: * the initial patch, which tried to move the gpio-generic driver initialization up to the postcore_initcall level, replaced with an alternative solution, moving the on-board devices initialization down to late_initcall; thanks to Tony Lindgren who suggested this solution, * dropped patches introducing changes to the modem and ASoC device handling; those will be addressed in a separate patch series, * final cleanups also dropped until those remaining devices are updated, * the serio driver now takes care of one more GPIO pin which, even if not used, belongs to the device interface and affects its functioning, * misc code and changelog cosmetic cleanups, * rebased on top of 3.2-rc6. Thanks to those who reviewed the initial submission and responded with their comments or Acks. Janusz Janusz Krzysztofik (7): ARM: OMAP1: ams-delta: register latch dependent devices later ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio ARM: OMAP1: ams-delta: supersede custom led device by leds-gpio LED: drop leds-ams-delta driver MTD: NAND: ams-delta: use GPIO instead of custom I/O omapfb: lcd_ams_delta: drive control lines over GPIO input: serio: ams-delta: toggle keyboard power over GPIO arch/arm/mach-omap1/Kconfig |2 + arch/arm/mach-omap1/board-ams-delta.c | 226 + arch/arm/plat-omap/include/plat/board-ams-delta.h | 48 ++--- drivers/input/serio/ams_delta_serio.c | 51 +++-- drivers/leds/Kconfig |7 - drivers/leds/Makefile |1 - drivers/leds/leds-ams-delta.c | 137 - drivers/mtd/nand/ams-delta.c | 74 +-- drivers/video/omap/lcd_ams_delta.c| 27 ++- sound/soc/omap/ams-delta.c|4 + 10 files changed, 318 insertions(+), 259 deletions(-) delete mode 100644 drivers/leds/leds-ams-delta.c -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/7] ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio
Once ready, ams-delta specific device drivers currently calling custom
ams_delta_latch[12]_write() functions can be updated to call generic
gpio_set_value() instead, which will make them less platform dependent.
Even more, some custom ams-delta only drivers can perhaps be dropped
from the tree after converting selected ams-delta platform devices to
follow generic GPIO based device models.
Depends on patch 1/7, ARM: OMAP1: ams-delta: register latch dependent
devices later.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes against initial version:
* refreshed on top of patch 1/7, which is the old 1/10 replacement,
* no need to BUG_ON() if GPIO request fails inside late_init(), can
return with error from there insted,
* dropped leading underscores from local symbols, variable and function
names (no namespace conflicts expected).
arch/arm/mach-omap1/Kconfig |1 +
arch/arm/mach-omap1/board-ams-delta.c | 237 ++---
arch/arm/plat-omap/include/plat/board-ams-delta.h | 43 +++-
3 files changed, 242 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index 73f287d..d2606b1 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -155,6 +155,7 @@ config MACH_AMS_DELTA
bool Amstrad E3 (Delta)
depends on ARCH_OMAP1 ARCH_OMAP15XX
select FIQ
+ select GPIO_GENERIC_PLATFORM
help
Support for the Amstrad E3 (codename Delta) videophone. Say Y here
if you have such a device.
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 50987c9..cff2711 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -11,6 +11,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include linux/basic_mmio_gpio.h
#include linux/gpio.h
#include linux/kernel.h
#include linux/init.h
@@ -40,9 +41,6 @@
#include mach/ams-delta-fiq.h
-static u8 ams_delta_latch1_reg;
-static u16 ams_delta_latch2_reg;
-
static const unsigned int ams_delta_keymap[] = {
KEY(0, 0, KEY_F1), /* Advert*/
@@ -121,39 +119,32 @@ static const unsigned int ams_delta_keymap[] = {
KEY(7, 3, KEY_LEFTCTRL),/* Vol down */
};
-void ams_delta_latch1_write(u8 mask, u8 value)
-{
- ams_delta_latch1_reg = ~mask;
- ams_delta_latch1_reg |= value;
- *(volatile __u8 *) AMS_DELTA_LATCH1_VIRT = ams_delta_latch1_reg;
-}
-
-void ams_delta_latch2_write(u16 mask, u16 value)
-{
- ams_delta_latch2_reg = ~mask;
- ams_delta_latch2_reg |= value;
- *(volatile __u16 *) AMS_DELTA_LATCH2_VIRT = ams_delta_latch2_reg;
-}
+#define LATCH1_PHYS0x0100
+#define LATCH1_VIRT0xEA00
+#define MODEM_PHYS 0x0400
+#define MODEM_VIRT 0xEB00
+#define LATCH2_PHYS0x0800
+#define LATCH2_VIRT0xEC00
static struct map_desc ams_delta_io_desc[] __initdata = {
/* AMS_DELTA_LATCH1 */
{
- .virtual= AMS_DELTA_LATCH1_VIRT,
- .pfn= __phys_to_pfn(AMS_DELTA_LATCH1_PHYS),
+ .virtual= LATCH1_VIRT,
+ .pfn= __phys_to_pfn(LATCH1_PHYS),
.length = 0x0100,
.type = MT_DEVICE
},
/* AMS_DELTA_LATCH2 */
{
- .virtual= AMS_DELTA_LATCH2_VIRT,
- .pfn= __phys_to_pfn(AMS_DELTA_LATCH2_PHYS),
+ .virtual= LATCH2_VIRT,
+ .pfn= __phys_to_pfn(LATCH2_PHYS),
.length = 0x0100,
.type = MT_DEVICE
},
/* AMS_DELTA_MODEM */
{
- .virtual= AMS_DELTA_MODEM_VIRT,
- .pfn= __phys_to_pfn(AMS_DELTA_MODEM_PHYS),
+ .virtual= MODEM_VIRT,
+ .pfn= __phys_to_pfn(MODEM_PHYS),
.length = 0x0100,
.type = MT_DEVICE
}
@@ -173,6 +164,190 @@ static struct omap_board_config_kernel ams_delta_config[]
__initdata = {
{ OMAP_TAG_LCD, ams_delta_lcd_config },
};
+static struct resource latch1_resources[] __initconst = {
+ [0] = {
+ .name = dat,
+ .start = LATCH1_PHYS,
+ .end= LATCH1_PHYS + (AMS_DELTA_LATCH1_NGPIO - 1) / 8,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct bgpio_pdata latch1_pdata __initconst = {
+ .base = AMS_DELTA_LATCH1_GPIO_BASE,
+ .ngpio = AMS_DELTA_LATCH1_NGPIO,
+};
+
+static struct platform_device latch1_gpio_device = {
+ .name = basic-mmio-gpio,
+ .id = 0,
+ .resource = latch1_resources
[PATCH v2 4/7] LED: drop leds-ams-delta driver
This driver is no longer needed after the Amstrad Delta on-board LED
devices have been converted to leds-gpio compatible.
Created against linux-3.2-rc6.
Requires patch 3/7 ARM: OMAP1: ams-delta: supersede custom led device
by leds-gpio for those LEDs to still work.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: Richard Purdie rpur...@rpsys.net
---
Changes against initial version:
* no functional changes,
* rebased on top of linux-3.2-rc6, just in case.
drivers/leds/Kconfig |7 --
drivers/leds/Makefile |1 -
drivers/leds/leds-ams-delta.c | 137 -
3 files changed, 0 insertions(+), 145 deletions(-)
delete mode 100644 drivers/leds/leds-ams-delta.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ff203a4..3523746 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -74,13 +74,6 @@ config LEDS_S3C24XX
This option enables support for LEDs connected to GPIO lines
on Samsung S3C24XX series CPUs, such as the S3C2410 and S3C2440.
-config LEDS_AMS_DELTA
- tristate LED Support for the Amstrad Delta (E3)
- depends on LEDS_CLASS
- depends on MACH_AMS_DELTA
- help
- This option enables support for the LEDs on Amstrad Delta (E3).
-
config LEDS_NET48XX
tristate LED Support for Soekris net48xx series Error LED
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index e4f6bf5..f2b75b2 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -12,7 +12,6 @@ obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
obj-$(CONFIG_LEDS_LM3530) += leds-lm3530.o
obj-$(CONFIG_LEDS_MIKROTIK_RB532) += leds-rb532.o
obj-$(CONFIG_LEDS_S3C24XX) += leds-s3c24xx.o
-obj-$(CONFIG_LEDS_AMS_DELTA) += leds-ams-delta.o
obj-$(CONFIG_LEDS_NET48XX) += leds-net48xx.o
obj-$(CONFIG_LEDS_NET5501) += leds-net5501.o
obj-$(CONFIG_LEDS_WRAP)+= leds-wrap.o
diff --git a/drivers/leds/leds-ams-delta.c b/drivers/leds/leds-ams-delta.c
deleted file mode 100644
index 8c00937..000
--- a/drivers/leds/leds-ams-delta.c
+++ /dev/null
@@ -1,137 +0,0 @@
-/*
- * LEDs driver for Amstrad Delta (E3)
- *
- * Copyright (C) 2006 Jonathan McDowell nood...@earth.li
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/module.h
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/leds.h
-#include plat/board-ams-delta.h
-
-/*
- * Our context
- */
-struct ams_delta_led {
- struct led_classdev cdev;
- u8 bitmask;
-};
-
-static void ams_delta_led_set(struct led_classdev *led_cdev,
- enum led_brightness value)
-{
- struct ams_delta_led *led_dev =
- container_of(led_cdev, struct ams_delta_led, cdev);
-
- if (value)
- ams_delta_latch1_write(led_dev-bitmask, led_dev-bitmask);
- else
- ams_delta_latch1_write(led_dev-bitmask, 0);
-}
-
-static struct ams_delta_led ams_delta_leds[] = {
- {
- .cdev = {
- .name = ams-delta::camera,
- .brightness_set = ams_delta_led_set,
- },
- .bitmask= AMS_DELTA_LATCH1_LED_CAMERA,
- },
- {
- .cdev = {
- .name = ams-delta::advert,
- .brightness_set = ams_delta_led_set,
- },
- .bitmask= AMS_DELTA_LATCH1_LED_ADVERT,
- },
- {
- .cdev = {
- .name = ams-delta::email,
- .brightness_set = ams_delta_led_set,
- },
- .bitmask= AMS_DELTA_LATCH1_LED_EMAIL,
- },
- {
- .cdev = {
- .name = ams-delta::handsfree,
- .brightness_set = ams_delta_led_set,
- },
- .bitmask= AMS_DELTA_LATCH1_LED_HANDSFREE,
- },
- {
- .cdev = {
- .name = ams-delta::voicemail,
- .brightness_set = ams_delta_led_set,
- },
- .bitmask= AMS_DELTA_LATCH1_LED_VOICEMAIL,
- },
- {
- .cdev = {
- .name = ams-delta::voice,
- .brightness_set = ams_delta_led_set,
- },
- .bitmask= AMS_DELTA_LATCH1_LED_VOICE,
- },
-};
-
-static int ams_delta_led_probe(struct platform_device *pdev)
-{
- int i, ret;
-
- for (i = 0; i ARRAY_SIZE(ams_delta_leds); i
[PATCH v2 5/7] MTD: NAND: ams-delta: use GPIO instead of custom I/O
Don't use Amstrad Delta custom I/O functions for controlling the device,
use GPIO API instead.
While being at it, add missing gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB).
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: David Woodhouse dw...@infradead.org
Cc: Tony Lindgren t...@atomide.com
---
Changes against initial version:
* no functional changes,
* rebased on top of v2 of patch 2/7, just in case.
Comments copied from initial submission:
Hi,
I considered dropping the Amstrad Delta NAND driver and moving to either
gpio-nand or gen_nand, but finally decided to keep it for now.
The problem with the gpio-nand is that it seems to match a different
hardware interface model. Having no knowledge about the original
hardware that driver was designed in mind, I'd rather not try to
modify it, and creating another GPIO based NAND driver also seems not
a really good idea.
If I decided to use gen_nand instead, I would have to move virtually all
of the old driver callback functions somewhere under arch, either to the
board file or to a new one, and still use some hacks unless either
nand_base.c or plat_nand.c is modified.
I'm willing to take one of those two approaches in a follow up series if
I get a positive feedback.
Thanks,
Janusz
arch/arm/mach-omap1/board-ams-delta.c | 30
arch/arm/plat-omap/include/plat/board-ams-delta.h |6 --
drivers/mtd/nand/ams-delta.c | 74 ++--
3 files changed, 52 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 034d009..cc6f962 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -237,36 +237,6 @@ static struct gpio latch_gpios[] __initconst = {
.label = lcd_ndisp,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_NAND_NCE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = nand_nce,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_NAND_NRE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = nand_nre,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_NAND_NWP,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = nand_nwp,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_NAND_NWE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = nand_nwe,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_NAND_ALE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = nand_ale,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_NAND_CLE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = nand_cle,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
.flags = GPIOF_OUT_INIT_LOW,
.label = keybrd_pwr,
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index a0f86ca..3e57833 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
@@ -30,12 +30,6 @@
#define AMS_DELTA_LATCH2_LCD_VBLEN 0x0001
#define AMS_DELTA_LATCH2_LCD_NDISP 0x0002
-#define AMS_DELTA_LATCH2_NAND_NCE 0x0004
-#define AMS_DELTA_LATCH2_NAND_NRE 0x0008
-#define AMS_DELTA_LATCH2_NAND_NWP 0x0010
-#define AMS_DELTA_LATCH2_NAND_NWE 0x0020
-#define AMS_DELTA_LATCH2_NAND_ALE 0x0040
-#define AMS_DELTA_LATCH2_NAND_CLE 0x0080
#define AMD_DELTA_LATCH2_KEYBRD_PWR0x0100
#define AMD_DELTA_LATCH2_KEYBRD_DATA 0x0200
#define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 9e6b498..5769bd2 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -26,7 +26,7 @@
#include asm/io.h
#include mach/hardware.h
#include asm/sizes.h
-#include asm/gpio.h
+#include linux/gpio.h
#include plat/board-ams-delta.h
/*
@@ -34,8 +34,6 @@
*/
static struct mtd_info *ams_delta_mtd = NULL;
-#define NAND_MASK (AMS_DELTA_LATCH2_NAND_NRE | AMS_DELTA_LATCH2_NAND_NWE |
AMS_DELTA_LATCH2_NAND_CLE | AMS_DELTA_LATCH2_NAND_ALE |
AMS_DELTA_LATCH2_NAND_NCE | AMS_DELTA_LATCH2_NAND_NWP)
-
/*
* Define partitions for flash devices
*/
@@ -68,10 +66,9 @@ static void ams_delta_write_byte(struct mtd_info *mtd,
u_char byte)
writew(0, io_base + OMAP_MPUIO_IO_CNTL);
writew(byte, this-IO_ADDR_W);
- ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NWE, 0);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_NAND_NWE, 0);
ndelay(40);
- ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NWE,
- AMS_DELTA_LATCH2_NAND_NWE);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_NAND_NWE, 1);
}
static u_char
[PATCH v2 3/7] ARM: OMAP1: ams-delta: supersede custom led device by leds-gpio
Now that the Amstrad Delta on-board latches have been converted to GPIO
devices, use the generic driver to control on-board LEDs which hang off
those latches.
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes against initial version:
* no functional changes,
* refreshed on top of v2 of patch 2/7,
* dropped leading underscores from local symbols, variable and function
names (no namespace conflicts expected).
arch/arm/mach-omap1/Kconfig |1 +
arch/arm/mach-omap1/board-ams-delta.c | 87 +++-
arch/arm/plat-omap/include/plat/board-ams-delta.h | 19 -
3 files changed, 49 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index d2606b1..ed7e864 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -156,6 +156,7 @@ config MACH_AMS_DELTA
depends on ARCH_OMAP1 ARCH_OMAP15XX
select FIQ
select GPIO_GENERIC_PLATFORM
+ select LEDS_GPIO_REGISTER
help
Support for the Amstrad E3 (codename Delta) videophone. Say Y here
if you have such a device.
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index cff2711..034d009 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -164,18 +164,21 @@ static struct omap_board_config_kernel ams_delta_config[]
__initdata = {
{ OMAP_TAG_LCD, ams_delta_lcd_config },
};
+#define LATCH1_GPIO_BASE 232
+#define LATCH1_NGPIO 8
+
static struct resource latch1_resources[] __initconst = {
[0] = {
.name = dat,
.start = LATCH1_PHYS,
- .end= LATCH1_PHYS + (AMS_DELTA_LATCH1_NGPIO - 1) / 8,
+ .end= LATCH1_PHYS + (LATCH1_NGPIO - 1) / 8,
.flags = IORESOURCE_MEM,
},
};
static struct bgpio_pdata latch1_pdata __initconst = {
- .base = AMS_DELTA_LATCH1_GPIO_BASE,
- .ngpio = AMS_DELTA_LATCH1_NGPIO,
+ .base = LATCH1_GPIO_BASE,
+ .ngpio = LATCH1_NGPIO,
};
static struct platform_device latch1_gpio_device = {
@@ -214,42 +217,12 @@ static struct platform_device latch2_gpio_device = {
static struct gpio latch_gpios[] __initconst = {
{
- .gpio = AMS_DELTA_GPIO_PIN_LED_CAMERA,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = led_camera,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_LED_ADVERT,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = led_advert,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_LED_EMAIL,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = led_email,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_LED_HANDSFREE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = led_handsfree,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_LED_VOICEMAIL,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = led_voicemail,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_LED_VOICE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = led_voice,
- },
- {
- .gpio = AMS_DELTA_LATCH1_GPIO_BASE + 6,
+ .gpio = LATCH1_GPIO_BASE + 6,
.flags = GPIOF_OUT_INIT_LOW,
.label = dockit1,
},
{
- .gpio = AMS_DELTA_LATCH1_GPIO_BASE + 7,
+ .gpio = LATCH1_GPIO_BASE + 7,
.flags = GPIOF_OUT_INIT_LOW,
.label = dockit2,
},
@@ -399,9 +372,45 @@ static struct platform_device ams_delta_lcd_device = {
.id = -1,
};
-static struct platform_device ams_delta_led_device = {
- .name = ams-delta-led,
- .id = -1
+static struct gpio_led gpio_leds[] __initconst = {
+ {
+ .name= camera,
+ .gpio= LATCH1_GPIO_BASE + 0,
+ .default_state = LEDS_GPIO_DEFSTATE_OFF,
+#ifdef CONFIG_LEDS_TRIGGERS
+ .default_trigger = ams_delta_camera,
+#endif
+ },
+ {
+ .name= advert,
+ .gpio= LATCH1_GPIO_BASE + 1,
+ .default_state = LEDS_GPIO_DEFSTATE_OFF,
+ },
+ {
+ .name= email,
+ .gpio= LATCH1_GPIO_BASE + 2,
+ .default_state = LEDS_GPIO_DEFSTATE_OFF,
+ },
+ {
+ .name= handsfree,
+ .gpio= LATCH1_GPIO_BASE + 3,
+ .default_state = LEDS_GPIO_DEFSTATE_OFF,
+ },
+ {
+ .name= voicemail,
+ .gpio
[PATCH v2 6/7] omapfb: lcd_ams_delta: drive control lines over GPIO
Don't use Amstrad Delta custom I/O functions any longer, use GPIO API
instead.
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
Changes against initial version:
* was 8/10,
* no functional changes,
* rebased on top of v2 of patch 2/7, just in case.
arch/arm/mach-omap1/board-ams-delta.c | 10 ---
arch/arm/plat-omap/include/plat/board-ams-delta.h |2 -
drivers/video/omap/lcd_ams_delta.c| 27 +++-
3 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index cc6f962..3aba8f9 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -227,16 +227,6 @@ static struct gpio latch_gpios[] __initconst = {
.label = dockit2,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_LCD_VBLEN,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = lcd_vblen,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_LCD_NDISP,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = lcd_ndisp,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
.flags = GPIOF_OUT_INIT_LOW,
.label = keybrd_pwr,
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index 3e57833..e9ad673 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
@@ -28,8 +28,6 @@
#if defined (CONFIG_MACH_AMS_DELTA)
-#define AMS_DELTA_LATCH2_LCD_VBLEN 0x0001
-#define AMS_DELTA_LATCH2_LCD_NDISP 0x0002
#define AMD_DELTA_LATCH2_KEYBRD_PWR0x0100
#define AMD_DELTA_LATCH2_KEYBRD_DATA 0x0200
#define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
diff --git a/drivers/video/omap/lcd_ams_delta.c
b/drivers/video/omap/lcd_ams_delta.c
index 6978ae4..73b211b 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -25,6 +25,7 @@
#include linux/io.h
#include linux/delay.h
#include linux/lcd.h
+#include linux/gpio.h
#include plat/board-ams-delta.h
#include mach/hardware.h
@@ -98,29 +99,41 @@ static struct lcd_ops ams_delta_lcd_ops = {
/* omapfb panel section */
+static struct gpio _gpios[] __initconst_or_module = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_LCD_VBLEN,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = lcd_vblen,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_LCD_NDISP,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = lcd_ndisp,
+ },
+};
+
static int ams_delta_panel_init(struct lcd_panel *panel,
struct omapfb_device *fbdev)
{
- return 0;
+ return gpio_request_array(_gpios, ARRAY_SIZE(_gpios));
}
static void ams_delta_panel_cleanup(struct lcd_panel *panel)
{
+ gpio_free_array(_gpios, ARRAY_SIZE(_gpios));
}
static int ams_delta_panel_enable(struct lcd_panel *panel)
{
- ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_NDISP,
- AMS_DELTA_LATCH2_LCD_NDISP);
- ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_VBLEN,
- AMS_DELTA_LATCH2_LCD_VBLEN);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_LCD_NDISP, 1);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_LCD_VBLEN, 1);
return 0;
}
static void ams_delta_panel_disable(struct lcd_panel *panel)
{
- ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_VBLEN, 0);
- ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_NDISP, 0);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_LCD_VBLEN, 0);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_LCD_NDISP, 0);
}
static unsigned long ams_delta_panel_get_caps(struct lcd_panel *panel)
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/7] input: serio: ams-delta: toggle keyboard power over GPIO
Don't use Amstrad Delta custom I/O functions once GPIO interface is
available for the underlying hardware.
While requesting and initializing GPIO pins used, also take care of one
extra pin KEYBRD_DATAOUT which, even if not used by the driver, belongs
to the device and affects its functioning.
Once done, move the driver initialization back to the device_initcall
level, reverting the temporary chane introduced with patch 1/7 ARM:
OMAP1: ams-delta: register latch dependent devices from late_initcall.
That change is no longer required once the driver takes care of
registering used GPIO pins, and it's better to initialize the device
before others using the latch2 based GPIO pins, otherwise a garbage is
reported on boot, perhaps due to random data already captured by the FIQ
handler while the keyboard related latch bits are written with random
values during initialization of those other latch2 dependent devices.
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes against initial version:
* was 9/10,
* rebased on top of v2 of patch 2/7, just in case,
* moved AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT pin handling from the board
code to the driver,
* reverted a temporary change to the driver initcall level, introduced
by the new solution provided with patch 1/7.
arch/arm/mach-omap1/board-ams-delta.c | 10
arch/arm/plat-omap/include/plat/board-ams-delta.h |2 -
drivers/input/serio/ams_delta_serio.c | 55 -
3 files changed, 31 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 3aba8f9..673cf21 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -227,16 +227,6 @@ static struct gpio latch_gpios[] __initconst = {
.label = dockit2,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = keybrd_pwr,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = keybrd_dataout,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_SCARD_RSTIN,
.flags = GPIOF_OUT_INIT_LOW,
.label = scard_rstin,
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index e9ad673..027e79e 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
@@ -28,8 +28,6 @@
#if defined (CONFIG_MACH_AMS_DELTA)
-#define AMD_DELTA_LATCH2_KEYBRD_PWR0x0100
-#define AMD_DELTA_LATCH2_KEYBRD_DATA 0x0200
#define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
#define AMD_DELTA_LATCH2_SCARD_CMDVCC 0x0800
#define AMS_DELTA_LATCH2_MODEM_NRESET 0x1000
diff --git a/drivers/input/serio/ams_delta_serio.c
b/drivers/input/serio/ams_delta_serio.c
index 56ffd7c..ef1ec40 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -92,8 +92,7 @@ static irqreturn_t ams_delta_serio_interrupt(int irq, void
*dev_id)
static int ams_delta_serio_open(struct serio *serio)
{
/* enable keyboard */
- ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR,
- AMD_DELTA_LATCH2_KEYBRD_PWR);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 1);
return 0;
}
@@ -101,9 +100,32 @@ static int ams_delta_serio_open(struct serio *serio)
static void ams_delta_serio_close(struct serio *serio)
{
/* disable keyboard */
- ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR, 0);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
}
+static struct gpio _gpios[] __initconst_or_module = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
+ .flags = GPIOF_DIR_IN,
+ .label = serio-data,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_CLK,
+ .flags = GPIOF_DIR_IN,
+ .label = serio-clock,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = serio-power,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = serio-dataout,
+ },
+};
+
static int __init ams_delta_serio_init(void)
{
int err;
@@ -123,19 +145,11 @@ static int __init ams_delta_serio_init(void)
strlcpy(ams_delta_serio-phys, GPIO/serio0,
sizeof(ams_delta_serio-phys));
- err = gpio_request(AMS_DELTA_GPIO_PIN_KEYBRD_DATA, serio-data);
+ err = gpio_request_array(_gpios, ARRAY_SIZE(_gpios));
if (err) {
- pr_err
[PATCH v2 1/7][RESEND] ARM: OMAP1: ams-delta: register latch dependent devices later
Resending because of a typo in the Cc: list, sorry.
8--
In preparation to converting Amstrad Delta on-board latches to
basic_mmio_gpio devices, registration of platform devices which depend
on latches and will require initialization of their GPIO pins first,
should be moved out of .machine_init down to late_initcall level, as the
gpio-generic driver is not available until device_initcall time. The
latch reset operation, which will be replaced with GPIO initialization,
must also be moved to late_initcall for the same reason.
Since there was already another, separate arch_initcall function for
setting up one of those latch dependent devices, the on-board modem
device, reuse that function, i.e., rename it to a name that matches the
new purpose, extend with other device setup relocated from
.machine_init, and move down to the late_initcall level.
While being at it, add missing gpio_free() in case the modem platform
device registration fails.
In addition, defer registration of the Amstrad Delta ASoC and serio
devices, done from their device driver files, until late_initcall time,
as those drivers will depend on their GPIO pins already requested from
the board late_init() function until updated to register their GPIO pins
themselves.
Thanks to Tony Lindgren t...@atomide.com who suggested this approach
instead of shifting up the gpio-generic driver initialization.
Created and tested against linux-3.2-rc6.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
This patch was not present in the initial submission, it replaces the
old patch 1/10, providing an alternative solution not touching the
gpio-generic driver.
Thanks,
Janusz
arch/arm/mach-omap1/board-ams-delta.c | 28
drivers/input/serio/ams_delta_serio.c |4
sound/soc/omap/ams-delta.c|4
3 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index b0f15d2..50987c9 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -275,11 +275,14 @@ static struct omap1_cam_platform_data
ams_delta_camera_platform_data = {
};
static struct platform_device *ams_delta_devices[] __initdata = {
- ams_delta_nand_device,
ams_delta_kp_device,
+ ams_delta_camera_device,
+};
+
+static struct platform_device *late_devices[] __initdata = {
+ ams_delta_nand_device,
ams_delta_lcd_device,
ams_delta_led_device,
- ams_delta_camera_device,
};
static void __init ams_delta_init(void)
@@ -307,9 +310,6 @@ static void __init ams_delta_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
- /* Clear latch2 (NAND, LCD, modem enable) */
- ams_delta_latch2_write(~0, 0);
-
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
#ifdef CONFIG_LEDS_TRIGGERS
@@ -345,13 +345,18 @@ static struct platform_device ams_delta_modem_device = {
},
};
-static int __init ams_delta_modem_init(void)
+static int __init late_init(void)
{
int err;
if (!machine_is_ams_delta())
return -ENODEV;
+ /* Clear latch2 (NAND, LCD, modem enable) */
+ ams_delta_latch2_write(~0, 0);
+
+ platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
+
omap_cfg_reg(M14_1510_GPIO2);
ams_delta_modem_ports[0].irq =
gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
@@ -367,9 +372,16 @@ static int __init ams_delta_modem_init(void)
AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
- return platform_device_register(ams_delta_modem_device);
+ err = platform_device_register(ams_delta_modem_device);
+ if (err)
+ goto gpio_free;
+ return 0;
+
+gpio_free:
+ gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
+ return err;
}
-arch_initcall(ams_delta_modem_init);
+late_initcall(late_init);
static void __init ams_delta_map_io(void)
{
diff --git a/drivers/input/serio/ams_delta_serio.c
b/drivers/input/serio/ams_delta_serio.c
index d4d08bd..56ffd7c 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -165,6 +165,9 @@ serio:
kfree(ams_delta_serio);
return err;
}
+#ifndef MODULE
+late_initcall(ams_delta_serio_init);
+#else
module_init(ams_delta_serio_init);
static void __exit ams_delta_serio_exit(void)
@@ -175,3 +178,4 @@ static void __exit ams_delta_serio_exit(void)
gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA);
}
module_exit(ams_delta_serio_exit);
+#endif
diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c
index ccb8a6a..1764a3b 100644
--- a/sound/soc/omap/ams-delta.c
+++ b/sound/soc/omap/ams-delta.c
@@ -636,6 +636,9 @@ err
Re: [PATCH v2 2/7] ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio
On Tuesday 20 of December 2011 at 01:06:00, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 14:41]:
Once ready, ams-delta specific device drivers currently calling custom
ams_delta_latch[12]_write() functions can be updated to call generic
gpio_set_value() instead, which will make them less platform dependent.
Even more, some custom ams-delta only drivers can perhaps be dropped
from the tree after converting selected ams-delta platform devices to
follow generic GPIO based device models.
Depends on patch 1/7, ARM: OMAP1: ams-delta: register latch dependent
devices later.
Hmm looking at this maybe you can move the all the latch stuff into
a device driver?
The latch stuff is just platform data for the existing gpio-generic aka
basic_mmio_gpio driver. I'm not sure if creating a new custom driver by
just squashing an existig driver code with a board specific platform
data is a good idea.
Then you can have the other drivers register with it and let the
module dependencies take care of the init order?
It it was more complicated than providing just platform data, not even a
single custom callback, to an existing gpio-generic driver, creating a
custom driver might help indeed. However, I think I have all issues with
initialization order already sorted out without inventing a new driver.
You should only register the platform_device entries in your board-*.c
file, I don't think you actually need to do anything there to power
up things in the board-*.c file execept for the 8250.c driver?
Exactly, but not in a single patch. With this patch, I keep the old API
for all drivers to still work, that's why I have to handle GPIO pins on
behalf of them until updated. Those are updated step by step throghout
the following patches of the series.
+static struct gpio latch_gpios[] __initconst = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_LED_CAMERA,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = led_camera,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_LED_ADVERT,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = led_advert,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_LED_EMAIL,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = led_email,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_LED_HANDSFREE,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = led_handsfree,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_LED_VOICEMAIL,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = led_voicemail,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_LED_VOICE,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = led_voice,
+ },
+ {
+ .gpio = AMS_DELTA_LATCH1_GPIO_BASE + 6,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = dockit1,
+ },
+ {
+ .gpio = AMS_DELTA_LATCH1_GPIO_BASE + 7,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = dockit2,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_LCD_VBLEN,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = lcd_vblen,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_LCD_NDISP,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = lcd_ndisp,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_NAND_NCE,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = nand_nce,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_NAND_NRE,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = nand_nre,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_NAND_NWP,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = nand_nwp,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_NAND_NWE,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = nand_nwe,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_NAND_ALE,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = nand_ale,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_NAND_CLE,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = nand_cle,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = keybrd_pwr,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = keybrd_dataout,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_SCARD_RSTIN,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = scard_rstin,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_SCARD_CMDVCC,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = scard_cmdvcc,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ .flags
Re: [PATCH v2 2/7] ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio
On Tuesday 20 of December 2011 at 02:04:46, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 16:28]: On Tuesday 20 of December 2011 at 01:06:00, Tony Lindgren wrote: This part especially looks like it really should be just a regular device driver under drivers/ somewhere. I really don't understand what kind of a driver you might mean here. The latch_gpios[] table is initially filled with all latch1 and latch2 GPIO pins in order to register and initialize them from the board file until they are handled by respective existing device drivers (leds, nand, lcd, serio, serial8250, asoc) instead of those drivers accessing the latches with those old ams_delta_latch[12]_write() functions. That table will get almost empty after the transision process is completed, holding only pins not used by any drivers / connected to unsued devices, in order to initialize them from the board file for power saving purposes. A separate driver for the purpose of initializing a few GPIO pins seems an overkill. OK maybe update the comments a bit to describe how that table will mostly disappear? It's not obvious from glancing over this patch series :) To be sure, do you mean in-line comments? Or the changelog message? Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/7 v2] ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio
Resubmitting with the changelog extended.
8-
Once ready, ams-delta specific device drivers currently calling custom
ams_delta_latch[12]_write() functions can be updated to call generic
gpio_set_value() instead, which will make them less platform dependent.
Even more, some custom ams-delta only drivers can perhaps be dropped
from the tree after converting selected ams-delta platform devices to
follow generic GPIO based device models.
The latch_gpios[] table is initially filled with all latch1 and latch2
GPIO pins in order to register and initialize them from the board file
until those are handled by respective existing device drivers (leds,
nand, lcd, serio, asoc, serial). That table will get almost empty after
the transision process is completed, holding only pins not used by any
drivers / connected to unused devices, in order to initialize them from
the board file for power saving purposes.
The new ams_delta_latch_write() function is a unified replacement for
those removed ams_delta_latch[12]_write(), and serves as a temporary
wrapper over gpio_set_value(), providing the old API for those not yet
updated device drivers, and will be removed after all custom drivers are
converted or replaced.
Depends on patch 1/7, ARM: OMAP1: ams-delta: register latch dependent
devices later.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes against initial version:
* refreshed on top of patch 1/7, which is the old 1/10 replacement,
* no need to BUG_ON() if GPIO request fails inside late_init(), can
return with error from there instead,
* dropped leading underscores from local symbols, variable and function
names (no namespace conflicts expected).
arch/arm/mach-omap1/Kconfig |1 +
arch/arm/mach-omap1/board-ams-delta.c | 237 ++---
arch/arm/plat-omap/include/plat/board-ams-delta.h | 43 +++-
3 files changed, 242 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index 73f287d..d2606b1 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -155,6 +155,7 @@ config MACH_AMS_DELTA
bool Amstrad E3 (Delta)
depends on ARCH_OMAP1 ARCH_OMAP15XX
select FIQ
+ select GPIO_GENERIC_PLATFORM
help
Support for the Amstrad E3 (codename Delta) videophone. Say Y here
if you have such a device.
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 50987c9..cff2711 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -11,6 +11,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include linux/basic_mmio_gpio.h
#include linux/gpio.h
#include linux/kernel.h
#include linux/init.h
@@ -40,9 +41,6 @@
#include mach/ams-delta-fiq.h
-static u8 ams_delta_latch1_reg;
-static u16 ams_delta_latch2_reg;
-
static const unsigned int ams_delta_keymap[] = {
KEY(0, 0, KEY_F1), /* Advert*/
@@ -121,39 +119,32 @@ static const unsigned int ams_delta_keymap[] = {
KEY(7, 3, KEY_LEFTCTRL),/* Vol down */
};
-void ams_delta_latch1_write(u8 mask, u8 value)
-{
- ams_delta_latch1_reg = ~mask;
- ams_delta_latch1_reg |= value;
- *(volatile __u8 *) AMS_DELTA_LATCH1_VIRT = ams_delta_latch1_reg;
-}
-
-void ams_delta_latch2_write(u16 mask, u16 value)
-{
- ams_delta_latch2_reg = ~mask;
- ams_delta_latch2_reg |= value;
- *(volatile __u16 *) AMS_DELTA_LATCH2_VIRT = ams_delta_latch2_reg;
-}
+#define LATCH1_PHYS0x0100
+#define LATCH1_VIRT0xEA00
+#define MODEM_PHYS 0x0400
+#define MODEM_VIRT 0xEB00
+#define LATCH2_PHYS0x0800
+#define LATCH2_VIRT0xEC00
static struct map_desc ams_delta_io_desc[] __initdata = {
/* AMS_DELTA_LATCH1 */
{
- .virtual= AMS_DELTA_LATCH1_VIRT,
- .pfn= __phys_to_pfn(AMS_DELTA_LATCH1_PHYS),
+ .virtual= LATCH1_VIRT,
+ .pfn= __phys_to_pfn(LATCH1_PHYS),
.length = 0x0100,
.type = MT_DEVICE
},
/* AMS_DELTA_LATCH2 */
{
- .virtual= AMS_DELTA_LATCH2_VIRT,
- .pfn= __phys_to_pfn(AMS_DELTA_LATCH2_PHYS),
+ .virtual= LATCH2_VIRT,
+ .pfn= __phys_to_pfn(LATCH2_PHYS),
.length = 0x0100,
.type = MT_DEVICE
},
/* AMS_DELTA_MODEM */
{
- .virtual= AMS_DELTA_MODEM_VIRT,
- .pfn= __phys_to_pfn(AMS_DELTA_MODEM_PHYS),
+ .virtual= MODEM_VIRT,
+ .pfn= __phys_to_pfn(MODEM_PHYS
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
On Sunday 11 of December 2011 at 21:11:59, Janusz Krzysztofik wrote:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Please ignore this patch, I'm going to submit a replacement, based on an
alternative approach suggested by Tony.
Thanks,
Janusz
Created against linux-3.2-rc5.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/gpio/gpio-generic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
index 4e24436..a6eaf38 100644
--- a/drivers/gpio/gpio-generic.c
+++ b/drivers/gpio/gpio-generic.c
@@ -528,7 +528,7 @@ static int __init bgpio_platform_init(void)
{
return platform_driver_register(bgpio_driver);
}
-module_init(bgpio_platform_init);
+postcore_initcall(bgpio_platform_init);
static void __exit bgpio_platform_exit(void)
{
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]: On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Hmm, can't you do all that in the order you want in ams_delta_modem_init()? Or make that into a late_initcall so you have generic-gpio available? It seems that the pieces of code you're talking about don't need to be initialized early, just needs to be done in the right order to get things working. Hi, I'm almost done with moving registration of all latch dependent devices down to a late_initcall hook, however while working on this, I've found still another arrangement, yet better in my opinion: 1) generic-gpio driver registration moved from device_initcall up to subsys_initcall, 2) latch dependent device registration left at arch_initcall, as it is now, 3) a temporary hack, removed with the last patch in the series, that requests GPIO pins on behalf of device drivers before those are updated, placed between subsys_initcall and device_initcall, i.e., at fs_initcall or rootfs_initcall; both look ugly, but this is only for a while, in order to keep things working while in the transition, 4) the modem init hook, once updated with extra GPIO setup that must be done on behalf of the 8250 driver, which is not prepared for accepting any extra init hooks passed with the device platform data, moved down to late_initcall, as suggested, 5) once all drivers are updated, the hack is removed, and an initialization of unused pins added to that late_initcall modem hook, perhaps renamed in order to not suggest it is still modem only related. What do you think? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
(adding Mark Brown and Liam Girdwood - regulator experts - to Cc:) On Wednesday 14 of December 2011 at 19:21:49, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111214 04:40]: On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]: On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Hmm, can't you do all that in the order you want in ams_delta_modem_init()? Or make that into a late_initcall so you have generic-gpio available? It seems that the pieces of code you're talking about don't need to be initialized early, just needs to be done in the right order to get things working. Hi, I'm almost done with moving registration of all latch dependent devices down to a late_initcall hook, however while working on this, I've found still another arrangement, yet better in my opinion: 1) generic-gpio driver registration moved from device_initcall up to subsys_initcall, 2) latch dependent device registration left at arch_initcall, as it is now, 3) a temporary hack, removed with the last patch in the series, that requests GPIO pins on behalf of device drivers before those are updated, placed between subsys_initcall and device_initcall, i.e., at fs_initcall or rootfs_initcall; both look ugly, but this is only for a while, in order to keep things working while in the transition, 4) the modem init hook, once updated with extra GPIO setup that must be done on behalf of the 8250 driver, which is not prepared for accepting any extra init hooks passed with the device platform data, moved down to late_initcall, as suggested, 5) once all drivers are updated, the hack is removed, and an initialization of unused pins added to that late_initcall modem hook, perhaps renamed in order to not suggest it is still modem only related. What do you think? Sounds better for sure than what we currently have :) Hmm, better doesn't necessarily mean good enough... I forgot about the sound device, which shares its latch based GPIO pins with the modem, so should be registered after the modem. To make things still more complicated, one of those GPIO pins provides power to both devices, so a still better solution I'd like to introduce would be a GPIO controlled regulator device which feeds both the modem and the sound card with power. I've had a look at both generic regulator drivers, fixed.c and gpio- regulator.c, both controlling devices over GPIO pins, and found those drivers registered at subsys_initcall level, calling gpio_request*() at probe time. Then again, we would need that base_mmio_gpio driver already registered before subsys_initcall. Any suggestions? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
(adding Greg Kroah-Hartman and linux-ser...@vger.kernel.org to Cc:)
On Monday 12 of December 2011 at 19:04:56, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111211 11:41]:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Care to explain a bit more why you need to initialize those devices
early on?
Let me try.
From patch 2/10 ARM: OMAP1: ams-delta: Convert latches to
basic_mmio_gpio:
@@ -307,8 +487,8 @@ static void __init ams_delta_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
- /* Clear latch2 (NAND, LCD, modem enable) */
- ams_delta_latch2_write(~0, 0);
+ platform_add_devices(_latch_devices, ARRAY_SIZE(_latch_devices));
+ BUG_ON(gpio_request_array(_latch_gpios, ARRAY_SIZE(_latch_gpios)));
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
Here I'm accessing the latches from ams_delta_init() (.init_machine
hook) with gpio_request_array() in order to:
a) clear their contents,
b) avoid accessing them, from ams_delta_latch_write(), never requested.
I could imagine clearing their contents with something like
*(volatile __u8 *) AMS_DELTA_LATCH2_VIRT = 0;
*(volatile __u16 *) AMS_DELTA_LATCH2_VIRT = 0;
instead, i.e., the way the old code used to, than accessing those GPIO
pins not requested, until they are finally requested by drivers updated
to use gpiolib with successive patche. Would this be acceptable?
However,
From patch 6/10 ARM: OMAP1: ams-delta: Use GPIO API in modem setup:
@@ -482,6 +472,12 @@ static void __init ams_delta_init(void)
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
+static void _modem_pm(struct uart_port *port, unsigned int state, unsigned
old)
+{
+ if (state != old)
+ gpio_set_value(AMS_DELTA_GPIO_PIN_MODEM_NRESET, state == 0);
+}
+
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
.membase= IOMEM(_MODEM_VIRT),
@@ -492,6 +488,7 @@ static struct plat_serial8250_port
ams_delta_modem_ports[] = {
.iotype = UPIO_MEM,
.regshift = 1,
.uartclk= BASE_BAUD * 16,
+ .pm = _modem_pm,
},
{ },
};
@@ -504,6 +501,24 @@ static struct platform_device ams_delta_modem_device = {
},
};
+static struct gpio _modem_gpios[] __initconst = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_IRQ,
+ .flags = GPIOF_DIR_IN,
+ .label = modem_irq,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ .flags = GPIOF_OUT_INIT_HIGH,
+ .label = modem_nreset,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC,
+ .flags = GPIOF_OUT_INIT_HIGH,
+ .label = modem_codec,
+ },
+};
+
static int __init ams_delta_modem_init(void)
{
int err;
@@ -515,16 +530,11 @@ static int __init ams_delta_modem_init(void)
ams_delta_modem_ports[0].irq =
gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
- err = gpio_request(AMS_DELTA_GPIO_PIN_MODEM_IRQ, modem);
+ err = gpio_request_array(_modem_gpios, ARRAY_SIZE(_modem_gpios));
if (err) {
- pr_err(Couldn't request gpio pin for modem\n);
+ pr_err(Couldn't request gpio pins for modem\n);
return err;
}
- gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
-
- ams_delta_latch2_write(
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
return platform_device_register(ams_delta_modem_device);
}
Before the change, only one GPIO pin, that IRQ, driven with omap_gpio
driver which is registered from postcore, was gpio_request()ed. Now, two
more, gpio-generic driven pins, are also requested _and_ initialized in
order to make the modem accessible. The ams_delta_modem_init() is
installed with arch_initcall().
I could imagine initializing those modem pins the old way I've suggested
above, but I can see no good solution to delegate calling of that
gpio_request*() to the 8250 driver. For me, the only hook passed to the
driver with platform_data that can be suitable is the .pm hook. However,
when I tried to remove powering up the modem (rising up
AMS_DELTA_GPIO_PIN_MODEM_NRESET) from the arch init and do this only
from that .pm hook, the device was not detected, so I wonder if and when
that hook is called, and if it is before probe, then perhaps powering
up the modem chip from there is too late for the device to get up before
being examined. But then, maybe if we initialize the pin the old way
from arch init, it would be enough for the device
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]: On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Hmm, can't you do all that in the order you want in ams_delta_modem_init()? Or make that into a late_initcall so you have generic-gpio available? It seems that the pieces of code you're talking about don't need to be initialized early, just needs to be done in the right order to get things working. I think I've got it, thanks! Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] ARM: OMAP1: ams-delta: replace custom I/O with GPIO
The Amstrad Delta board has two extra output ports used for driving input lines of different on-board devices. Those ports are now controlled with custom functions, provided by the board arch code and used by several device drivers. The idea behind the series is to replace those custom I/O functions with gpiolib API. This way, existing drivers can be made less platform dependent, and some of them perhaps even superseded with generic GPIO based drivers after the board platform device descriptions are converted. Moreover, should a new driver for the on-board Smart Card controller ever be created, it could be designed as a generic GPIO based driver, not a custom one. Janusz Krzysztofik (10): GPIO: gpio-generic: Move initialization up to postcore ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio ARM: OMAP1: ams-delta: supersede custom led device by leds-gpio LED: drop leds-ams-delta driver MTD: NAND: ams-delta: use GPIO instead of custom I/O ARM: OMAP1: ams-delta: Use GPIO API in modem setup ASoC: OMAP: ams-delta: Drive modem/codec pins over GPIO API omapfb: lcd_ams_delta: Drive control lines over GPIO input: serio: ams-delta: toggle keyboard power over GPIO ARM: OMAP1: ams-delta: drop custom I/O functions arch/arm/mach-omap1/Kconfig |2 + arch/arm/mach-omap1/board-ams-delta.c | 220 + arch/arm/plat-omap/include/plat/board-ams-delta.h | 50 ++--- drivers/gpio/gpio-generic.c |2 +- drivers/input/serio/ams_delta_serio.c | 45 +++-- drivers/leds/Kconfig |7 - drivers/leds/Makefile |1 - drivers/leds/leds-ams-delta.c | 137 - drivers/mtd/nand/ams-delta.c | 74 +-- drivers/video/omap/lcd_ams_delta.c| 27 ++- sound/soc/omap/ams-delta.c| 21 ++- 11 files changed, 309 insertions(+), 277 deletions(-) delete mode 100644 drivers/leds/leds-ams-delta.c -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Created against linux-3.2-rc5.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/gpio/gpio-generic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
index 4e24436..a6eaf38 100644
--- a/drivers/gpio/gpio-generic.c
+++ b/drivers/gpio/gpio-generic.c
@@ -528,7 +528,7 @@ static int __init bgpio_platform_init(void)
{
return platform_driver_register(bgpio_driver);
}
-module_init(bgpio_platform_init);
+postcore_initcall(bgpio_platform_init);
static void __exit bgpio_platform_exit(void)
{
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] ARM: OMAP1: ams-delta: Convert latches to basic_mmio_gpio
Once done, ams-delta specific device drivers currently calling custom
ams_delta_latch[12]_write() functions can call generic gpio_set_value()
instead, which will make them less platform dependent. Even more, some
custom ams-delta only drivers perhaps can be dropped from the tree after
converting selected ams-delta platform devices to follow generic GPIO
based device models.
Created against linux-3.2-rc5.
Requires patch 1/10 GPIO: gpio-generic: Move initialization up to
postcore to work correctly.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/Kconfig |1 +
arch/arm/mach-omap1/board-ams-delta.c | 235 ++---
arch/arm/plat-omap/include/plat/board-ams-delta.h | 43 +++-
3 files changed, 241 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index 73f287d..1b5f283 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -154,6 +154,7 @@ config MACH_NOKIA770
config MACH_AMS_DELTA
bool Amstrad E3 (Delta)
depends on ARCH_OMAP1 ARCH_OMAP15XX
+ select GPIO_GENERIC_PLATFORM
select FIQ
help
Support for the Amstrad E3 (codename Delta) videophone. Say Y here
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index b0f15d2..d88419e 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -11,6 +11,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include linux/basic_mmio_gpio.h
#include linux/gpio.h
#include linux/kernel.h
#include linux/init.h
@@ -40,9 +41,6 @@
#include mach/ams-delta-fiq.h
-static u8 ams_delta_latch1_reg;
-static u16 ams_delta_latch2_reg;
-
static const unsigned int ams_delta_keymap[] = {
KEY(0, 0, KEY_F1), /* Advert*/
@@ -121,39 +119,32 @@ static const unsigned int ams_delta_keymap[] = {
KEY(7, 3, KEY_LEFTCTRL),/* Vol down */
};
-void ams_delta_latch1_write(u8 mask, u8 value)
-{
- ams_delta_latch1_reg = ~mask;
- ams_delta_latch1_reg |= value;
- *(volatile __u8 *) AMS_DELTA_LATCH1_VIRT = ams_delta_latch1_reg;
-}
-
-void ams_delta_latch2_write(u16 mask, u16 value)
-{
- ams_delta_latch2_reg = ~mask;
- ams_delta_latch2_reg |= value;
- *(volatile __u16 *) AMS_DELTA_LATCH2_VIRT = ams_delta_latch2_reg;
-}
+#define _LATCH1_PHYS 0x0100
+#define _LATCH1_VIRT 0xEA00
+#define _MODEM_PHYS0x0400
+#define _MODEM_VIRT0xEB00
+#define _LATCH2_PHYS 0x0800
+#define _LATCH2_VIRT 0xEC00
static struct map_desc ams_delta_io_desc[] __initdata = {
/* AMS_DELTA_LATCH1 */
{
- .virtual= AMS_DELTA_LATCH1_VIRT,
- .pfn= __phys_to_pfn(AMS_DELTA_LATCH1_PHYS),
+ .virtual= _LATCH1_VIRT,
+ .pfn= __phys_to_pfn(_LATCH1_PHYS),
.length = 0x0100,
.type = MT_DEVICE
},
/* AMS_DELTA_LATCH2 */
{
- .virtual= AMS_DELTA_LATCH2_VIRT,
- .pfn= __phys_to_pfn(AMS_DELTA_LATCH2_PHYS),
+ .virtual= _LATCH2_VIRT,
+ .pfn= __phys_to_pfn(_LATCH2_PHYS),
.length = 0x0100,
.type = MT_DEVICE
},
/* AMS_DELTA_MODEM */
{
- .virtual= AMS_DELTA_MODEM_VIRT,
- .pfn= __phys_to_pfn(AMS_DELTA_MODEM_PHYS),
+ .virtual= _MODEM_VIRT,
+ .pfn= __phys_to_pfn(_MODEM_PHYS),
.length = 0x0100,
.type = MT_DEVICE
}
@@ -173,6 +164,195 @@ static struct omap_board_config_kernel ams_delta_config[]
__initdata = {
{ OMAP_TAG_LCD, ams_delta_lcd_config },
};
+static struct resource _latch1_resources[] __initconst = {
+ [0] = {
+ .name = dat,
+ .start = _LATCH1_PHYS,
+ .end= _LATCH1_PHYS + ((AMS_DELTA_LATCH1_NGPIO - 1) / 8),
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct bgpio_pdata _latch1_pdata __initconst = {
+ .base = AMS_DELTA_LATCH1_GPIO_BASE,
+ .ngpio = AMS_DELTA_LATCH1_NGPIO,
+};
+
+static struct platform_device _latch1_device = {
+ .name = basic-mmio-gpio,
+ .id = 0,
+ .resource = _latch1_resources,
+ .num_resources = ARRAY_SIZE(_latch1_resources),
+ .dev= {
+ .platform_data = _latch1_pdata,
+ },
+};
+
+static struct resource _latch2_resources[] __initconst = {
+ [0] = {
+ .name = dat,
+ .start = _LATCH2_PHYS,
+ .end
[PATCH 03/10] ARM: OMAP1: ams-delta: Supersede custom led device by leds-gpio
Now that the Amstrad Delta on-board latches have been converted to GPIO
devices, use the generic driver to control on-board LEDs which hang off
those latches.
Depends on patch 2/10 ARM: OMAP1: Convert Amstrad E3 latches to
basic_mmio_gpio.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/Kconfig |1 +
arch/arm/mach-omap1/board-ams-delta.c | 87 +++-
arch/arm/plat-omap/include/plat/board-ams-delta.h | 19 -
3 files changed, 49 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index 1b5f283..f362f83 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -155,6 +155,7 @@ config MACH_AMS_DELTA
bool Amstrad E3 (Delta)
depends on ARCH_OMAP1 ARCH_OMAP15XX
select GPIO_GENERIC_PLATFORM
+ select LEDS_GPIO_REGISTER
select FIQ
help
Support for the Amstrad E3 (codename Delta) videophone. Say Y here
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index d88419e..bdf7399 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -164,18 +164,21 @@ static struct omap_board_config_kernel ams_delta_config[]
__initdata = {
{ OMAP_TAG_LCD, ams_delta_lcd_config },
};
+#define _LATCH1_GPIO_BASE 232
+#define _LATCH1_NGPIO 8
+
static struct resource _latch1_resources[] __initconst = {
[0] = {
.name = dat,
.start = _LATCH1_PHYS,
- .end= _LATCH1_PHYS + ((AMS_DELTA_LATCH1_NGPIO - 1) / 8),
+ .end= _LATCH1_PHYS + ((_LATCH1_NGPIO - 1) / 8),
.flags = IORESOURCE_MEM,
},
};
static struct bgpio_pdata _latch1_pdata __initconst = {
- .base = AMS_DELTA_LATCH1_GPIO_BASE,
- .ngpio = AMS_DELTA_LATCH1_NGPIO,
+ .base = _LATCH1_GPIO_BASE,
+ .ngpio = _LATCH1_NGPIO,
};
static struct platform_device _latch1_device = {
@@ -219,42 +222,12 @@ static struct platform_device *_latch_devices[]
__initconst = {
static struct gpio _latch_gpios[] __initconst = {
{
- .gpio = AMS_DELTA_GPIO_PIN_LED_CAMERA,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = led_camera,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_LED_ADVERT,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = led_advert,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_LED_EMAIL,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = led_email,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_LED_HANDSFREE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = led_handsfree,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_LED_VOICEMAIL,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = led_voicemail,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_LED_VOICE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = led_voice,
- },
- {
- .gpio = AMS_DELTA_LATCH1_GPIO_BASE + 6,
+ .gpio = _LATCH1_GPIO_BASE + 6,
.flags = GPIOF_OUT_INIT_LOW,
.label = dockit1,
},
{
- .gpio = AMS_DELTA_LATCH1_GPIO_BASE + 7,
+ .gpio = _LATCH1_GPIO_BASE + 7,
.flags = GPIOF_OUT_INIT_LOW,
.label = dockit2,
},
@@ -404,9 +377,45 @@ static struct platform_device ams_delta_lcd_device = {
.id = -1,
};
-static struct platform_device ams_delta_led_device = {
- .name = ams-delta-led,
- .id = -1
+static struct gpio_led _gpio_leds[] __initconst = {
+ {
+ .name= camera,
+ .gpio= _LATCH1_GPIO_BASE + 0,
+ .default_state = LEDS_GPIO_DEFSTATE_OFF,
+#ifdef CONFIG_LEDS_TRIGGERS
+ .default_trigger = ams_delta_camera,
+#endif
+ },
+ {
+ .name= advert,
+ .gpio= _LATCH1_GPIO_BASE + 1,
+ .default_state = LEDS_GPIO_DEFSTATE_OFF,
+ },
+ {
+ .name= email,
+ .gpio= _LATCH1_GPIO_BASE + 2,
+ .default_state = LEDS_GPIO_DEFSTATE_OFF,
+ },
+ {
+ .name= handsfree,
+ .gpio= _LATCH1_GPIO_BASE + 3,
+ .default_state = LEDS_GPIO_DEFSTATE_OFF,
+ },
+ {
+ .name= voicemail,
+ .gpio= _LATCH1_GPIO_BASE + 4,
+ .default_state = LEDS_GPIO_DEFSTATE_OFF,
+ },
+ {
+ .name= voice,
+ .gpio= _LATCH1_GPIO_BASE
[PATCH 04/10] LED: Drop leds-ams-delta driver
This is no longer needed after the Amstrad Delta on-board LED devices
have been converted to leds-gpio compatible.
Created against linux-3.2-rc5.
Requires patch 3/10 ARM: OMAP1: ams-delta: Supersede custom led device
by leds-gpio for those LEDs to still work.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/leds/Kconfig |7 --
drivers/leds/Makefile |1 -
drivers/leds/leds-ams-delta.c | 137 -
3 files changed, 0 insertions(+), 145 deletions(-)
delete mode 100644 drivers/leds/leds-ams-delta.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ff203a4..3523746 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -74,13 +74,6 @@ config LEDS_S3C24XX
This option enables support for LEDs connected to GPIO lines
on Samsung S3C24XX series CPUs, such as the S3C2410 and S3C2440.
-config LEDS_AMS_DELTA
- tristate LED Support for the Amstrad Delta (E3)
- depends on LEDS_CLASS
- depends on MACH_AMS_DELTA
- help
- This option enables support for the LEDs on Amstrad Delta (E3).
-
config LEDS_NET48XX
tristate LED Support for Soekris net48xx series Error LED
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index e4f6bf5..f2b75b2 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -12,7 +12,6 @@ obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
obj-$(CONFIG_LEDS_LM3530) += leds-lm3530.o
obj-$(CONFIG_LEDS_MIKROTIK_RB532) += leds-rb532.o
obj-$(CONFIG_LEDS_S3C24XX) += leds-s3c24xx.o
-obj-$(CONFIG_LEDS_AMS_DELTA) += leds-ams-delta.o
obj-$(CONFIG_LEDS_NET48XX) += leds-net48xx.o
obj-$(CONFIG_LEDS_NET5501) += leds-net5501.o
obj-$(CONFIG_LEDS_WRAP)+= leds-wrap.o
diff --git a/drivers/leds/leds-ams-delta.c b/drivers/leds/leds-ams-delta.c
deleted file mode 100644
index 8c00937..000
--- a/drivers/leds/leds-ams-delta.c
+++ /dev/null
@@ -1,137 +0,0 @@
-/*
- * LEDs driver for Amstrad Delta (E3)
- *
- * Copyright (C) 2006 Jonathan McDowell nood...@earth.li
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/module.h
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/leds.h
-#include plat/board-ams-delta.h
-
-/*
- * Our context
- */
-struct ams_delta_led {
- struct led_classdev cdev;
- u8 bitmask;
-};
-
-static void ams_delta_led_set(struct led_classdev *led_cdev,
- enum led_brightness value)
-{
- struct ams_delta_led *led_dev =
- container_of(led_cdev, struct ams_delta_led, cdev);
-
- if (value)
- ams_delta_latch1_write(led_dev-bitmask, led_dev-bitmask);
- else
- ams_delta_latch1_write(led_dev-bitmask, 0);
-}
-
-static struct ams_delta_led ams_delta_leds[] = {
- {
- .cdev = {
- .name = ams-delta::camera,
- .brightness_set = ams_delta_led_set,
- },
- .bitmask= AMS_DELTA_LATCH1_LED_CAMERA,
- },
- {
- .cdev = {
- .name = ams-delta::advert,
- .brightness_set = ams_delta_led_set,
- },
- .bitmask= AMS_DELTA_LATCH1_LED_ADVERT,
- },
- {
- .cdev = {
- .name = ams-delta::email,
- .brightness_set = ams_delta_led_set,
- },
- .bitmask= AMS_DELTA_LATCH1_LED_EMAIL,
- },
- {
- .cdev = {
- .name = ams-delta::handsfree,
- .brightness_set = ams_delta_led_set,
- },
- .bitmask= AMS_DELTA_LATCH1_LED_HANDSFREE,
- },
- {
- .cdev = {
- .name = ams-delta::voicemail,
- .brightness_set = ams_delta_led_set,
- },
- .bitmask= AMS_DELTA_LATCH1_LED_VOICEMAIL,
- },
- {
- .cdev = {
- .name = ams-delta::voice,
- .brightness_set = ams_delta_led_set,
- },
- .bitmask= AMS_DELTA_LATCH1_LED_VOICE,
- },
-};
-
-static int ams_delta_led_probe(struct platform_device *pdev)
-{
- int i, ret;
-
- for (i = 0; i ARRAY_SIZE(ams_delta_leds); i++) {
- ams_delta_leds[i].cdev.flags |= LED_CORE_SUSPENDRESUME;
- ret = led_classdev_register(pdev-dev
[PATCH 05/10] MTD: NAND: ams-delta: Use GPIO instead of custom I/O
Don't use Amstrad Delta custom I/O functions for controlling the device,
use GPIO API instead.
While being at it, add missing gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB).
Depends on patch 2/10 ARM: OMAP1: Convert Amstrad E3 latches to
basic_mmio_gpio.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Hi,
I considered dropping the Amstrad Delta NAND driver and moving to either
gpio-nand or gen_nand, but finally decided to keep it for now.
The problem with the gpio-nand is that it seems to match a different
hardware interface model. Having no knowledge about the original
hardware that driver was designed in mind, I'd rather not try to
modify it, and creating another GPIO based NAND driver also seems not
a really good idea.
If I decided to use gen_nand instead, I would have to move virtually all
of the old driver callback functions somewhere under arch, either to the
board file or to a new one, and still use some hacks unless either
nand_base.c or plat_nand.c is modified.
I'm willing to take one of those two approaches in a follow up series if
I get a positive feedback.
Thanks,
Janusz
arch/arm/mach-omap1/board-ams-delta.c | 30
arch/arm/plat-omap/include/plat/board-ams-delta.h |6 --
drivers/mtd/nand/ams-delta.c | 74 ++--
3 files changed, 52 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index bdf7399..7670374 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -242,36 +242,6 @@ static struct gpio _latch_gpios[] __initconst = {
.label = lcd_ndisp,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_NAND_NCE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = nand_nce,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_NAND_NRE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = nand_nre,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_NAND_NWP,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = nand_nwp,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_NAND_NWE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = nand_nwe,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_NAND_ALE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = nand_ale,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_NAND_CLE,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = nand_cle,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
.flags = GPIOF_OUT_INIT_LOW,
.label = keybrd_pwr,
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index c096e14..b586078 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
@@ -30,12 +30,6 @@
#define AMS_DELTA_LATCH2_LCD_VBLEN 0x0001
#define AMS_DELTA_LATCH2_LCD_NDISP 0x0002
-#define AMS_DELTA_LATCH2_NAND_NCE 0x0004
-#define AMS_DELTA_LATCH2_NAND_NRE 0x0008
-#define AMS_DELTA_LATCH2_NAND_NWP 0x0010
-#define AMS_DELTA_LATCH2_NAND_NWE 0x0020
-#define AMS_DELTA_LATCH2_NAND_ALE 0x0040
-#define AMS_DELTA_LATCH2_NAND_CLE 0x0080
#define AMD_DELTA_LATCH2_KEYBRD_PWR0x0100
#define AMD_DELTA_LATCH2_KEYBRD_DATA 0x0200
#define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 9e6b498..5769bd2 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -26,7 +26,7 @@
#include asm/io.h
#include mach/hardware.h
#include asm/sizes.h
-#include asm/gpio.h
+#include linux/gpio.h
#include plat/board-ams-delta.h
/*
@@ -34,8 +34,6 @@
*/
static struct mtd_info *ams_delta_mtd = NULL;
-#define NAND_MASK (AMS_DELTA_LATCH2_NAND_NRE | AMS_DELTA_LATCH2_NAND_NWE |
AMS_DELTA_LATCH2_NAND_CLE | AMS_DELTA_LATCH2_NAND_ALE |
AMS_DELTA_LATCH2_NAND_NCE | AMS_DELTA_LATCH2_NAND_NWP)
-
/*
* Define partitions for flash devices
*/
@@ -68,10 +66,9 @@ static void ams_delta_write_byte(struct mtd_info *mtd,
u_char byte)
writew(0, io_base + OMAP_MPUIO_IO_CNTL);
writew(byte, this-IO_ADDR_W);
- ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NWE, 0);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_NAND_NWE, 0);
ndelay(40);
- ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NWE,
- AMS_DELTA_LATCH2_NAND_NWE);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_NAND_NWE, 1);
}
static u_char ams_delta_read_byte(struct mtd_info *mtd)
@@ -80,12 +77,11 @@ static u_char ams_delta_read_byte(struct mtd_info *mtd)
struct nand_chip *this = mtd-priv;
void __iomem *io_base = this-priv;
- ams_delta_latch2_write
[PATCH 06/10] ARM: OMAP1: ams-delta: Use GPIO API in modem setup
Don't use Amstrad Delta custom I/O functions for setting up modem
related pins, use GPIO API instead. However, keep old pin definitions
used by ams_delta_latch2_write() for now, as those are still used by the
Amstrad Delta ASoC driver.
While being at it, extend the device platform data with a power
management hook which toggles one of those new GPIO pins.
Depends on patch 2/10 ARM: OMAP1: Convert Amstrad E3 latches to
basic_mmio_gpio.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 44
1 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 7670374..5705481 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -262,16 +262,6 @@ static struct gpio _latch_gpios[] __initconst = {
.label = scard_cmdvcc,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = modem_nreset,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = modem_codec,
- },
- {
.gpio = AMS_DELTA_LATCH2_GPIO_BASE + 14,
.flags = GPIOF_OUT_INIT_LOW,
.label = hookflash1,
@@ -482,6 +472,12 @@ static void __init ams_delta_init(void)
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
+static void _modem_pm(struct uart_port *port, unsigned int state, unsigned old)
+{
+ if (state != old)
+ gpio_set_value(AMS_DELTA_GPIO_PIN_MODEM_NRESET, state == 0);
+}
+
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
.membase= IOMEM(_MODEM_VIRT),
@@ -492,6 +488,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[]
= {
.iotype = UPIO_MEM,
.regshift = 1,
.uartclk= BASE_BAUD * 16,
+ .pm = _modem_pm,
},
{ },
};
@@ -504,6 +501,24 @@ static struct platform_device ams_delta_modem_device = {
},
};
+static struct gpio _modem_gpios[] __initconst = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_IRQ,
+ .flags = GPIOF_DIR_IN,
+ .label = modem_irq,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ .flags = GPIOF_OUT_INIT_HIGH,
+ .label = modem_nreset,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC,
+ .flags = GPIOF_OUT_INIT_HIGH,
+ .label = modem_codec,
+ },
+};
+
static int __init ams_delta_modem_init(void)
{
int err;
@@ -515,16 +530,11 @@ static int __init ams_delta_modem_init(void)
ams_delta_modem_ports[0].irq =
gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
- err = gpio_request(AMS_DELTA_GPIO_PIN_MODEM_IRQ, modem);
+ err = gpio_request_array(_modem_gpios, ARRAY_SIZE(_modem_gpios));
if (err) {
- pr_err(Couldn't request gpio pin for modem\n);
+ pr_err(Couldn't request gpio pins for modem\n);
return err;
}
- gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
-
- ams_delta_latch2_write(
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
return platform_device_register(ams_delta_modem_device);
}
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10] ASoC: OMAP: ams-delta: Drive modem/codec pins over GPIO API
Don't use Amstrad Delta custom I/O functions any longer, replace them with GPIO. Old pin definitions, no longer used by the modem bits either, can be dropped. Depends on patch 2/10 ARM: OMAP1: Convert Amstrad E3 latches to basic_mmio_gpio. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- arch/arm/plat-omap/include/plat/board-ams-delta.h |2 -- sound/soc/omap/ams-delta.c| 21 - 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h b/arch/arm/plat-omap/include/plat/board-ams-delta.h index b586078..73fdab9 100644 --- a/arch/arm/plat-omap/include/plat/board-ams-delta.h +++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h @@ -34,8 +34,6 @@ #define AMD_DELTA_LATCH2_KEYBRD_DATA 0x0200 #define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400 #define AMD_DELTA_LATCH2_SCARD_CMDVCC 0x0800 -#define AMS_DELTA_LATCH2_MODEM_NRESET 0x1000 -#define AMS_DELTA_LATCH2_MODEM_CODEC 0x2000 #define AMS_DELTA_GPIO_PIN_KEYBRD_DATA 0 #define AMS_DELTA_GPIO_PIN_KEYBRD_CLK 1 diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c index ccb8a6a..389c488 100644 --- a/sound/soc/omap/ams-delta.c +++ b/sound/soc/omap/ams-delta.c @@ -268,7 +268,7 @@ static void cx81801_timeout(unsigned long data) /* Reconnect the codec DAI back from the modem to the CPU DAI * only if digital mute still off */ if (!muted) - ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC, 0); + gpio_set_value(AMS_DELTA_GPIO_PIN_MODEM_CODEC, 0); } /* @@ -378,8 +378,7 @@ static void cx81801_receive(struct tty_struct *tty, /* Apply config pulse by connecting the codec to the modem * if not already done */ if (apply) - ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC, - AMS_DELTA_LATCH2_MODEM_CODEC); + gpio_set_value(AMS_DELTA_GPIO_PIN_MODEM_CODEC, 1); break; } } @@ -438,13 +437,11 @@ static int ams_delta_set_bias_level(struct snd_soc_card *card, case SND_SOC_BIAS_PREPARE: case SND_SOC_BIAS_STANDBY: if (codec-dapm.bias_level == SND_SOC_BIAS_OFF) - ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_NRESET, - AMS_DELTA_LATCH2_MODEM_NRESET); + gpio_set_value(AMS_DELTA_GPIO_PIN_MODEM_NRESET, 1); break; case SND_SOC_BIAS_OFF: if (codec-dapm.bias_level != SND_SOC_BIAS_OFF) - ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_NRESET, - 0); + gpio_set_value(AMS_DELTA_GPIO_PIN_MODEM_NRESET, 0); } codec-dapm.bias_level = level; @@ -468,8 +465,7 @@ static int ams_delta_digital_mute(struct snd_soc_dai *dai, int mute) spin_unlock_bh(ams_delta_lock); if (apply) - ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC, - mute ? AMS_DELTA_LATCH2_MODEM_CODEC : 0); + gpio_set_value(AMS_DELTA_GPIO_PIN_MODEM_CODEC, mute); return 0; } @@ -503,6 +499,13 @@ static int ams_delta_cx20442_init(struct snd_soc_pcm_runtime *rtd) int ret; /* Codec is ready, now add/activate board specific controls */ + /* +* *_MODEM_CODEC and *_MODEM_NRESET GPIO pins manipulated above are +* assumed to be already requested from the board initialisation code, +* which should be done while setting up the modem device which those +* pins are used for control of in the first place. +*/ + /* Store a pointer to the codec structure for tty ldisc use */ cx20442_codec = codec; -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] omapfb: lcd_ams_delta: Drive control lines over GPIO
Don't use Amstrad Delta custom I/O functions any longer, use GPIO API
instead.
Depends on patch 5/10 MTD: NAND: ams-delta: Use GPIO instead of custom
I/O.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 10 ---
arch/arm/plat-omap/include/plat/board-ams-delta.h |2 -
drivers/video/omap/lcd_ams_delta.c| 27 +++-
3 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 5705481..b7422e3 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -232,16 +232,6 @@ static struct gpio _latch_gpios[] __initconst = {
.label = dockit2,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_LCD_VBLEN,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = lcd_vblen,
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_LCD_NDISP,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = lcd_ndisp,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
.flags = GPIOF_OUT_INIT_LOW,
.label = keybrd_pwr,
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index 73fdab9..1d0706e 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
@@ -28,8 +28,6 @@
#if defined (CONFIG_MACH_AMS_DELTA)
-#define AMS_DELTA_LATCH2_LCD_VBLEN 0x0001
-#define AMS_DELTA_LATCH2_LCD_NDISP 0x0002
#define AMD_DELTA_LATCH2_KEYBRD_PWR0x0100
#define AMD_DELTA_LATCH2_KEYBRD_DATA 0x0200
#define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
diff --git a/drivers/video/omap/lcd_ams_delta.c
b/drivers/video/omap/lcd_ams_delta.c
index 6978ae4..73b211b 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -25,6 +25,7 @@
#include linux/io.h
#include linux/delay.h
#include linux/lcd.h
+#include linux/gpio.h
#include plat/board-ams-delta.h
#include mach/hardware.h
@@ -98,29 +99,41 @@ static struct lcd_ops ams_delta_lcd_ops = {
/* omapfb panel section */
+static struct gpio _gpios[] __initconst_or_module = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_LCD_VBLEN,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = lcd_vblen,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_LCD_NDISP,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = lcd_ndisp,
+ },
+};
+
static int ams_delta_panel_init(struct lcd_panel *panel,
struct omapfb_device *fbdev)
{
- return 0;
+ return gpio_request_array(_gpios, ARRAY_SIZE(_gpios));
}
static void ams_delta_panel_cleanup(struct lcd_panel *panel)
{
+ gpio_free_array(_gpios, ARRAY_SIZE(_gpios));
}
static int ams_delta_panel_enable(struct lcd_panel *panel)
{
- ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_NDISP,
- AMS_DELTA_LATCH2_LCD_NDISP);
- ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_VBLEN,
- AMS_DELTA_LATCH2_LCD_VBLEN);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_LCD_NDISP, 1);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_LCD_VBLEN, 1);
return 0;
}
static void ams_delta_panel_disable(struct lcd_panel *panel)
{
- ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_VBLEN, 0);
- ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_NDISP, 0);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_LCD_VBLEN, 0);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_LCD_NDISP, 0);
}
static unsigned long ams_delta_panel_get_caps(struct lcd_panel *panel)
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/10] input: serio: ams-delta: Toggle keyboard power over GPIO
Don't use Amstrad Delta custom I/O functions once GPIO interface is
available for the underlying hardware.
Depends on patch 8/10 omapfb: lcd_ams_delta: Drive control lines over
GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c |5 --
arch/arm/plat-omap/include/plat/board-ams-delta.h |2 -
drivers/input/serio/ams_delta_serio.c | 45 +++-
3 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index b7422e3..587118c 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -232,11 +232,6 @@ static struct gpio _latch_gpios[] __initconst = {
.label = dockit2,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = keybrd_pwr,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
.flags = GPIOF_OUT_INIT_LOW,
.label = keybrd_dataout,
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index 1d0706e..004c827 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
@@ -28,8 +28,6 @@
#if defined (CONFIG_MACH_AMS_DELTA)
-#define AMD_DELTA_LATCH2_KEYBRD_PWR0x0100
-#define AMD_DELTA_LATCH2_KEYBRD_DATA 0x0200
#define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
#define AMD_DELTA_LATCH2_SCARD_CMDVCC 0x0800
diff --git a/drivers/input/serio/ams_delta_serio.c
b/drivers/input/serio/ams_delta_serio.c
index d4d08bd..1499c7d 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -92,8 +92,7 @@ static irqreturn_t ams_delta_serio_interrupt(int irq, void
*dev_id)
static int ams_delta_serio_open(struct serio *serio)
{
/* enable keyboard */
- ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR,
- AMD_DELTA_LATCH2_KEYBRD_PWR);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 1);
return 0;
}
@@ -101,9 +100,26 @@ static int ams_delta_serio_open(struct serio *serio)
static void ams_delta_serio_close(struct serio *serio)
{
/* disable keyboard */
- ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR, 0);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
}
+static struct gpio _gpios[] __initconst_or_module = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
+ .flags = GPIOF_DIR_IN,
+ .label = serio-data,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_CLK,
+ .flags = GPIOF_DIR_IN,
+ .label = serio-clock,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = serio-power,
+ },
+};
static int __init ams_delta_serio_init(void)
{
int err;
@@ -123,19 +139,11 @@ static int __init ams_delta_serio_init(void)
strlcpy(ams_delta_serio-phys, GPIO/serio0,
sizeof(ams_delta_serio-phys));
- err = gpio_request(AMS_DELTA_GPIO_PIN_KEYBRD_DATA, serio-data);
+ err = gpio_request_array(_gpios, ARRAY_SIZE(_gpios));
if (err) {
- pr_err(ams_delta_serio: Couldn't request gpio pin for data\n);
+ pr_err(ams_delta_serio: Couldn't request gpio pins\n);
goto serio;
}
- gpio_direction_input(AMS_DELTA_GPIO_PIN_KEYBRD_DATA);
-
- err = gpio_request(AMS_DELTA_GPIO_PIN_KEYBRD_CLK, serio-clock);
- if (err) {
- pr_err(ams_delta_serio: couldn't request gpio pin for
clock\n);
- goto gpio_data;
- }
- gpio_direction_input(AMS_DELTA_GPIO_PIN_KEYBRD_CLK);
err = request_irq(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK),
ams_delta_serio_interrupt, IRQ_TYPE_EDGE_RISING,
@@ -143,7 +151,7 @@ static int __init ams_delta_serio_init(void)
if (err 0) {
pr_err(ams_delta_serio: couldn't request gpio interrupt %d\n,
gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK));
- goto gpio_clk;
+ goto gpio;
}
/*
* Since GPIO register handling for keyboard clock pin is performed
@@ -157,10 +165,8 @@ static int __init ams_delta_serio_init(void)
dev_info(ams_delta_serio-dev, %s\n, ams_delta_serio-name);
return 0;
-gpio_clk:
- gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_CLK);
-gpio_data:
- gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA);
+gpio:
+ gpio_free_array(_gpios, ARRAY_SIZE(_gpios));
serio:
kfree(ams_delta_serio);
return err;
@@ -171,7 +177,6 @@ static void __exit ams_delta_serio_exit(void
[PATCH 10/10] ARM: OMAP1: ams-delta: Drop custom I/O functions
Those are no longer required after all drivers which used them have been
converted to the GPIO interface.
Depends on patch 9/10 input: serio: ams-delta: Toggle keyboard power
over GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 17 +++--
arch/arm/plat-omap/include/plat/board-ams-delta.h | 10 --
2 files changed, 3 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 587118c..bed43b4 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -258,19 +258,6 @@ static struct gpio _latch_gpios[] __initconst = {
},
};
-void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
-{
- int bit;
- u16 bitpos;
-
- for (bit = 0; bit ngpio; bit++) {
- bitpos = 1 bit;
- if (mask bitpos)
- gpio_set_value(base + bit, (value bitpos) != 0);
- }
-}
-EXPORT_SYMBOL(ams_delta_latch_write);
-
static struct resource ams_delta_nand_resources[] = {
[0] = {
.start = OMAP1_MPUIO_BASE,
@@ -441,7 +428,9 @@ static void __init ams_delta_init(void)
omap_register_i2c_bus(1, 100, NULL, 0);
platform_add_devices(_latch_devices, ARRAY_SIZE(_latch_devices));
- BUG_ON(gpio_request_array(_latch_gpios, ARRAY_SIZE(_latch_gpios)));
+ /* Initialize pins not used by any drivers */
+ gpio_request_array(_latch_gpios, ARRAY_SIZE(_latch_gpios));
+ gpio_free_array(_latch_gpios, ARRAY_SIZE(_latch_gpios));
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index 004c827..b09b69d 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
@@ -28,9 +28,6 @@
#if defined (CONFIG_MACH_AMS_DELTA)
-#define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
-#define AMD_DELTA_LATCH2_SCARD_CMDVCC 0x0800
-
#define AMS_DELTA_GPIO_PIN_KEYBRD_DATA 0
#define AMS_DELTA_GPIO_PIN_KEYBRD_CLK 1
#define AMS_DELTA_GPIO_PIN_MODEM_IRQ 2
@@ -58,13 +55,6 @@
#define AMS_DELTA_LATCH2_GPIO_BASE AMS_DELTA_GPIO_PIN_LCD_VBLEN
#define AMS_DELTA_LATCH2_NGPIO 16
-#ifndef __ASSEMBLY__
-void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value);
-#endif
-#define ams_delta_latch2_write(mask, value) \
- ams_delta_latch_write(AMS_DELTA_LATCH2_GPIO_BASE, \
- AMS_DELTA_LATCH2_NGPIO, (mask), (value))
-
#endif /* CONFIG_MACH_AMS_DELTA */
#endif /* __ASM_ARCH_OMAP_AMS_DELTA_H */
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5 v2] ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram
On Saturday 10 of December 2011 at 01:25:03, Russell King - ARM Linux wrote: On Fri, Dec 09, 2011 at 11:00:01AM +0100, Janusz Krzysztofik wrote: Those were BogoMIPS, ... I realise that. But which is which - is 70.40 from recalibrate_delay or is it 74.54? Your message is too vague to be able to interpret your results because it's impossible to work out what figure refers to which method. Yes, I realised what you had actually asked about after re-reading your answer, which I unfortunately did after I had already replied, sorry. ... Then, in case of a machine always booting at, let's say, 12 and then reprogrammed to 150 MHz, we actually scale up that less then the theoretical number, with a side effect of scaling up its error as well. Perhaps in this case, when the machine is going to run at that target rate until rebooted, we should rather decide to recalibrate to keep that error proportionally small compared to the target loops per jiffy value ... It really doesn't matter - udelay() etc is not designed to be mega accurate but good enough... Great, that's the answer to my initial question: loops per jiffy inaccuracy of 6% shouldn't matter. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5 v2] ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram
On Friday 09 of December 2011 at 09:42:45, Russell King - ARM Linux wrote: On Tue, Nov 29, 2011 at 01:25:32AM +0100, Janusz Krzysztofik wrote: However, the result of cpufreq_scale() differs from that of (re)calibrate_delay() by ca. 6%, i.e., 70.40 vs. 74.54. Please advise if this approximation is acceptable. You don't say which figure is what. Hi, Those were BogoMIPS, which you were talking about in your comment (http://www.spinics.net/lists/linux-omap/msg60811.html). Note that calibrate_delay() is itself inaccurate - the loops_per_jiffy is the number of loops which can be executed between two timer ticks _minus_ the time to process the timer interrupt itself. So, it's actually always a little less than the theoretical number of loops within that time period. I see. Then, in case of a machine always booting at, let's say, 12 and then reprogrammed to 150 MHz, we actually scale up that less then the theoretical number, with a side effect of scaling up its error as well. Perhaps in this case, when the machine is going to run at that target rate until rebooted, we should rather decide to recalibrate to keep that error proportionally small compared to the target loops per jiffy value, like it worked in my initial proposal? I think that your argument about unnecessarily wasting 10s of milliseconds has marginal importance here because we will be redoing that calibration only once, at boot time, and never later until next reboot. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5 v2] ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram
On Friday 09 of December 2011 at 11:00:01, Janusz Krzysztofik wrote: On Friday 09 of December 2011 at 09:42:45, Russell King - ARM Linux wrote: On Tue, Nov 29, 2011 at 01:25:32AM +0100, Janusz Krzysztofik wrote: However, the result of cpufreq_scale() differs from that of (re)calibrate_delay() by ca. 6%, i.e., 70.40 vs. 74.54. Please advise if this approximation is acceptable. You don't say which figure is what. Hi, Those were BogoMIPS, which you were talking about in your comment (http://www.spinics.net/lists/linux-omap/msg60811.html). Should also mention that I was getting the lower number as a result of cpufreq_scale(), and the higher when doing recalibrate_delay(). Janusz Note that calibrate_delay() is itself inaccurate - the loops_per_jiffy is the number of loops which can be executed between two timer ticks _minus_ the time to process the timer interrupt itself. So, it's actually always a little less than the theoretical number of loops within that time period. I see. Then, in case of a machine always booting at, let's say, 12 and then reprogrammed to 150 MHz, we actually scale up that less then the theoretical number, with a side effect of scaling up its error as well. Perhaps in this case, when the machine is going to run at that target rate until rebooted, we should rather decide to recalibrate to keep that error proportionally small compared to the target loops per jiffy value, like it worked in my initial proposal? I think that your argument about unnecessarily wasting 10s of milliseconds has marginal importance here because we will be redoing that calibration only once, at boot time, and never later until next reboot. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
