Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component
On Sat, 2019-01-12 at 11:37 +0530, Rohit kumar wrote: > On 1/12/2019 3:19 AM, Pierre-Louis Bossart wrote: > > > Thanks for the overnight fix. This update fixes the issue on my > > > Skylake XPS13 test device (blind testing since I don't understand > > > what the code does). > > > > > > Tested-by: Pierre-Louis Bossart > > > > I need to take this back, this set of changes (initial+fix) causes an > > error with our HDMI support > > > > [ 17.437684] sof-audio sof-audio: created machine bxt-pcm512x > > [ 17.585279] bxt-pcm512x bxt-pcm512x: ASoC: failed to init link iDisp1 > > [ 17.585639] bxt-pcm512x bxt-pcm512x: snd_soc_register_card failed -517 > > > > Removing your changes restores the functionality > > > Looks like we should revert generic implementation for defering probe > and move to call from machine driver as done in v1. > https://lore.kernel.org/patchwork/patch/1027560/ > https://lore.kernel.org/patchwork/patch/1027561/ > > @Mark, Do you have suggestion to refine current patch? > > Adding some traces I can see that the the platform name we use doesn't > > seem compatible with your logic. All the Intel boards used a constant > > platform name matching the PCI ID, see e.g. [1], which IIRC is used to > > bind components. Liam, do you recall in more details if this is really > > required? Sorry, I cant quite remember why the PCI ID was used for the platform name, I think it started with the SKL generation as previous generations used "baytrail- pcm" and "haswell-pcm" as platform names IIRC. Perhaps Vinod will know. The platform name is only used by SOF when over writing the "legacy" platform name e.g. "baytrail-pcm" would become "sof-audio" and this is only used for binding DAI links (so that all legacy machine drivers can be reused without modification). Liam
Re: [alsa-devel] [PATCH] ASoC: Intel: fix Kconfig dependencies
On Thu, 2017-11-02 at 22:02 +0530, Vinod Koul wrote: > > > The BYT legacy drivers used DMAengine (dw) to load the firmware > and hence the > > > dependency. The Skylake and other drivers do not need that, so we > should > > > move this from toplevel to the BYT driver only. > > > > Ok, so Haswell also shouldn't select SND_SOC_INTEL_SST_FIRMWARE, > right? > > I am not sure on that. Liam? Haswell and Broadwell also use the DW DMAC for FW loading like the BYT legacy driver. Liam
Re: [alsa-devel] [PATCH] ASoC: Intel: fix Kconfig dependencies
On Thu, 2017-11-02 at 22:02 +0530, Vinod Koul wrote: > > > The BYT legacy drivers used DMAengine (dw) to load the firmware > and hence the > > > dependency. The Skylake and other drivers do not need that, so we > should > > > move this from toplevel to the BYT driver only. > > > > Ok, so Haswell also shouldn't select SND_SOC_INTEL_SST_FIRMWARE, > right? > > I am not sure on that. Liam? Haswell and Broadwell also use the DW DMAC for FW loading like the BYT legacy driver. Liam
Re: [RFC PATCH] ASoC: dpcm: Apply symmetry for DPCM
On Fri, 2015-12-11 at 11:33 +0800, Koro Chen wrote: > From: PC Liao > > DPCM does not fully support symmetry attributes. soc_pcm_apply_symmetry() > is skipped in soc_pcm_open() for DPCM, without being applied elsewhere. > So HW parameters cannot be correctly limited, and user space can do > playback/capture at different rates while HW actually does not support it. > soc_pcm_params_symmetry() will return error and the second stream stops. > > This patch adds soc_pcm_apply_symmetry() for FE, BE, and codec DAIs > in DPCM path that was skipped in soc_pcm_open(). > > Signed-off-by: PC Liao > Signed-off-by: Koro Chen Acked-by: Liam Girdwood -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] ASoC: dpcm: Apply symmetry for DPCM
On Fri, 2015-12-11 at 11:33 +0800, Koro Chen wrote: > From: PC Liao <pc.l...@mediatek.com> > > DPCM does not fully support symmetry attributes. soc_pcm_apply_symmetry() > is skipped in soc_pcm_open() for DPCM, without being applied elsewhere. > So HW parameters cannot be correctly limited, and user space can do > playback/capture at different rates while HW actually does not support it. > soc_pcm_params_symmetry() will return error and the second stream stops. > > This patch adds soc_pcm_apply_symmetry() for FE, BE, and codec DAIs > in DPCM path that was skipped in soc_pcm_open(). > > Signed-off-by: PC Liao <pc.l...@mediatek.com> > Signed-off-by: Koro Chen <koro.c...@mediatek.com> Acked-by: Liam Girdwood <liam.r.girdw...@linux.intel.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: dpcm: Make BE prepare possible in suspend state
On Wed, 2015-10-28 at 10:15 +0800, Koro Chen wrote: > During suspend/resume, there is a flow that if a driver does not support > SNDRV_PCM_INFO_RESUME, it will fail at snd_pcm_resume(), and user space > can then issue SNDRV_PCM_IOCTL_PREPARE to let audio continue to play. > > However, in dpcm_be_dai_prepare() it only allows BEs to be prepared > in state SND_SOC_DPCM_STATE_HW_PARAMS or SND_SOC_DPCM_STATE_STOP. > The BE state will then stay in SND_SOC_DPCM_STATE_SUSPEND, consequently > dpcm_be_dai_shutdown() is skipped in the end of playback and > be_substream->runtime is not cleared while this runtime is actually freed > by snd_pcm_detach_substream(). If another suspend comes, a NULL pointer > dereference will happen in snd_pcm_suspend() when accessing > BE substream's runtime. > > Signed-off-by: Koro Chen Acked-by: Liam Girdwood -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: dpcm: Make BE prepare possible in suspend state
On Wed, 2015-10-28 at 10:15 +0800, Koro Chen wrote: > During suspend/resume, there is a flow that if a driver does not support > SNDRV_PCM_INFO_RESUME, it will fail at snd_pcm_resume(), and user space > can then issue SNDRV_PCM_IOCTL_PREPARE to let audio continue to play. > > However, in dpcm_be_dai_prepare() it only allows BEs to be prepared > in state SND_SOC_DPCM_STATE_HW_PARAMS or SND_SOC_DPCM_STATE_STOP. > The BE state will then stay in SND_SOC_DPCM_STATE_SUSPEND, consequently > dpcm_be_dai_shutdown() is skipped in the end of playback and > be_substream->runtime is not cleared while this runtime is actually freed > by snd_pcm_detach_substream(). If another suspend comes, a NULL pointer > dereference will happen in snd_pcm_suspend() when accessing > BE substream's runtime. > > Signed-off-by: Koro Chen <koro.c...@mediatek.com> Acked-by: Liam Girdwood <liam.r.girdw...@linux.intel.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
On Thu, 2015-08-27 at 01:50 +, Lin, Mengdong wrote: > > -Original Message- > > From: Liam Girdwood [mailto:liam.r.girdw...@linux.intel.com] > > Sent: Wednesday, August 26, 2015 5:01 PM > > To: Jie, Yang > > Cc: Takashi Iwai; Dmitry Torokhov; Luis R. Rodriguez; > > joonas.lahti...@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; Greg > > Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis Rodriguez; > > lkml; yalin wang; Lin, Mengdong > > Subject: Re: Problems loading firmware using built-in drivers with kernels > > that > > use initramfs. > > > > On Wed, 2015-08-26 at 08:29 +, Jie, Yang wrote: > > > > -Original Message- > > > > From: Liam Girdwood [mailto:liam.r.girdw...@linux.intel.com] > > > > > > I think the options are to either :- > > > > > > > > 1) Don not support audio DSP drivers using topology data as built-in > > drivers. > > > > Audio is not really a critical system required for booting anyway. > > > > > > > > 2) Create a default PCM for every driver that has topology data on > > > > the assumption that every sound card will at least 1 PCM. This PCM > > > > can then be re-configured when the FW is loaded. > > > > > > Yep, this case is quite similar with what Linus described. > > > > > > Is it possible that we can probe pcm device after firmware is loaded > > > for this case? > > > > > > > The PCM devices are defined in the topology data so it is only possible to > > create the PCM device *after* the firmware is loaded in these drivers. > > > > Liam > > It seems this can prevent audio device driver in built-in mode to use > topology drivers. > > If topology is present, the vendor driver also uses request_firmware() to > load the topology data file in the probe phase. Then ASoC core will create > the sound card and its PCM devices. > > Shall we force the device drivers that depends on topology to be configured > as modules? Yes, this is probably the best/quickest solution for the short term until we can implement and test option 2. Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
On Thu, 2015-08-27 at 01:50 +, Lin, Mengdong wrote: -Original Message- From: Liam Girdwood [mailto:liam.r.girdw...@linux.intel.com] Sent: Wednesday, August 26, 2015 5:01 PM To: Jie, Yang Cc: Takashi Iwai; Dmitry Torokhov; Luis R. Rodriguez; joonas.lahti...@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; Greg Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis Rodriguez; lkml; yalin wang; Lin, Mengdong Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs. On Wed, 2015-08-26 at 08:29 +, Jie, Yang wrote: -Original Message- From: Liam Girdwood [mailto:liam.r.girdw...@linux.intel.com] I think the options are to either :- 1) Don not support audio DSP drivers using topology data as built-in drivers. Audio is not really a critical system required for booting anyway. 2) Create a default PCM for every driver that has topology data on the assumption that every sound card will at least 1 PCM. This PCM can then be re-configured when the FW is loaded. Yep, this case is quite similar with what Linus described. Is it possible that we can probe pcm device after firmware is loaded for this case? The PCM devices are defined in the topology data so it is only possible to create the PCM device *after* the firmware is loaded in these drivers. Liam It seems this can prevent audio device driver in built-in mode to use topology drivers. If topology is present, the vendor driver also uses request_firmware() to load the topology data file in the probe phase. Then ASoC core will create the sound card and its PCM devices. Shall we force the device drivers that depends on topology to be configured as modules? Yes, this is probably the best/quickest solution for the short term until we can implement and test option 2. Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
On Wed, 2015-08-26 at 08:29 +, Jie, Yang wrote: > > -Original Message- > > From: Liam Girdwood [mailto:liam.r.girdw...@linux.intel.com] > > I think the options are to either :- > > > > 1) Don not support audio DSP drivers using topology data as built-in > > drivers. > > Audio is not really a critical system required for booting anyway. > > > > 2) Create a default PCM for every driver that has topology data on the > > assumption that every sound card will at least 1 PCM. This PCM can then be > > re-configured when the FW is loaded. > > Yep, this case is quite similar with what Linus described. > > Is it possible that we can probe pcm device after firmware is loaded for this > case? > The PCM devices are defined in the topology data so it is only possible to create the PCM device *after* the firmware is loaded in these drivers. Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
On Wed, 2015-08-26 at 07:17 +0100, Jie, Yang wrote: > > -Original Message- > > From: Takashi Iwai [mailto:ti...@suse.de] > > Sent: Wednesday, August 26, 2015 1:33 PM > > To: Jie, Yang > > Cc: Dmitry Torokhov; Luis R. Rodriguez; Girdwood, Liam R; > > joonas.lahti...@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; Greg > > Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis > > Rodriguez; lkml > > Subject: Re: Problems loading firmware using built-in drivers with kernels > > that use initramfs. > > > > On Wed, 26 Aug 2015 07:12:46 +0200, > > Jie, Yang wrote: > > > > > > > -Original Message- > > > > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > > > > Sent: Wednesday, August 26, 2015 3:58 AM > > > > To: Takashi Iwai > > > > Cc: Luis R. Rodriguez; Girdwood, Liam R; Jie, Yang; > > > > joonas.lahti...@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; > > > > Greg Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; > > > > Luis Rodriguez; lkml > > > > Subject: Re: Problems loading firmware using built-in drivers with > > > > kernels that use initramfs. > > > > > > > > On Tue, Aug 25, 2015 at 12:46 PM, Takashi Iwai wrote: > > > > > On Tue, 25 Aug 2015 21:34:08 +0200, Luis R. Rodriguez wrote: > > > > >> > > > > >> On Tue, Aug 25, 2015 at 10:17:00AM +0100, David Woodhouse wrote: > > > > >> > Luis, did you tell me the other day that you made the kernel > > > > >> > get firmware directly from the file system? This regression > > > > >> > would be yours > > > > then? > > > > >> > > > > >> I didn't implement that, Linus did in 2012 (see commit > > > > >> abb139e75c2c titled > > > > >> "firmware: teach the kernel to load firmware files directly from > > > > >> the filesystem"). But we used to fallback to a userspace helper > > > > >> when the fw was not present and then Takashi made this optional > > > > >> via commit 7b1269f778782d titled "firmware: Make user-mode helper > > optional". > > > > >> Takashi noted in the Kconfig "The user-mode helper is no longer > > > > >> required unless you have a special firmware file that resides in > > > > >> a non-standard path". It was not clarified why that's true > > > > >> though, or what you'd need to do to ensure that the fw would be > > > > >> available. It would be good for us to elaborate on that. > > > > > > > > > > The recent udev already dropped the firmware loading feature. > > > > > > > > Note that even when we had udev helper to load the firmware it was > > > > not always reliable depending on the exact point where we requested > > firmware. > > > > If request happened in probe() path before we mounted root fs then > > > > we'd never get it loaded because we'd be waiting for devices settle > > > > before mounting rootfs. > > > > > > For request in probe(), is it possible to use > > > request_firmware_nowait() to wait rootfs mounted or timeout in another > > thread? > > > > > > It looks usermodehelper_disabled is 0(at probe()) at this case then no > > > waiting occurs here in our testing. > > > > It's possible -- and even with the normal request_firmware(), in theory. > > The > > missing piece is that you need to inform the helper to retry the f/w > > loading. > > Currently the direct f/w loader assumes that the file is there and returns > > error if not present. > > > > If we implement a retry, another question is how to trigger it, i.e. how the > > helper can know when a fs is mounted a new file is present. > > Got it, thanks Takashi and all. > > So looks we should(and already done for most audio firmware) implement it > as Dmitry and Linus proposed, that is to make sure request_firmware() calls > are not in driver's probe() paths. > > Yalin help posted sample code for this implementation(to request firmware > in device node open) and actually I also did similar for Broadwell ADSP driver > and will send out later, thank you all. Keyon, we have a similar situation to that of the FPGA example that Linus described when the DSP driver uses topology data. i.e. the audio driver will have no PCM devices that can be opened (to initiate the FW loading) until after the FW is loaded. The topology data is part of the FW and contains the PCMs, kcontrols, graphs etc. i.e. a PCM device is created for every PCM description found in the FW topology data. I think the options are to either :- 1) Don not support audio DSP drivers using topology data as built-in drivers. Audio is not really a critical system required for booting anyway. 2) Create a default PCM for every driver that has topology data on the assumption that every sound card will at least 1 PCM. This PCM can then be re-configured when the FW is loaded. Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
On Wed, 2015-08-26 at 08:29 +, Jie, Yang wrote: -Original Message- From: Liam Girdwood [mailto:liam.r.girdw...@linux.intel.com] I think the options are to either :- 1) Don not support audio DSP drivers using topology data as built-in drivers. Audio is not really a critical system required for booting anyway. 2) Create a default PCM for every driver that has topology data on the assumption that every sound card will at least 1 PCM. This PCM can then be re-configured when the FW is loaded. Yep, this case is quite similar with what Linus described. Is it possible that we can probe pcm device after firmware is loaded for this case? The PCM devices are defined in the topology data so it is only possible to create the PCM device *after* the firmware is loaded in these drivers. Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
On Wed, 2015-08-26 at 07:17 +0100, Jie, Yang wrote: -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, August 26, 2015 1:33 PM To: Jie, Yang Cc: Dmitry Torokhov; Luis R. Rodriguez; Girdwood, Liam R; joonas.lahti...@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; Greg Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis Rodriguez; lkml Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs. On Wed, 26 Aug 2015 07:12:46 +0200, Jie, Yang wrote: -Original Message- From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] Sent: Wednesday, August 26, 2015 3:58 AM To: Takashi Iwai Cc: Luis R. Rodriguez; Girdwood, Liam R; Jie, Yang; joonas.lahti...@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; Greg Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis Rodriguez; lkml Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs. On Tue, Aug 25, 2015 at 12:46 PM, Takashi Iwai ti...@suse.de wrote: On Tue, 25 Aug 2015 21:34:08 +0200, Luis R. Rodriguez wrote: On Tue, Aug 25, 2015 at 10:17:00AM +0100, David Woodhouse wrote: Luis, did you tell me the other day that you made the kernel get firmware directly from the file system? This regression would be yours then? I didn't implement that, Linus did in 2012 (see commit abb139e75c2c titled firmware: teach the kernel to load firmware files directly from the filesystem). But we used to fallback to a userspace helper when the fw was not present and then Takashi made this optional via commit 7b1269f778782d titled firmware: Make user-mode helper optional. Takashi noted in the Kconfig The user-mode helper is no longer required unless you have a special firmware file that resides in a non-standard path. It was not clarified why that's true though, or what you'd need to do to ensure that the fw would be available. It would be good for us to elaborate on that. The recent udev already dropped the firmware loading feature. Note that even when we had udev helper to load the firmware it was not always reliable depending on the exact point where we requested firmware. If request happened in probe() path before we mounted root fs then we'd never get it loaded because we'd be waiting for devices settle before mounting rootfs. For request in probe(), is it possible to use request_firmware_nowait() to wait rootfs mounted or timeout in another thread? It looks usermodehelper_disabled is 0(at probe()) at this case then no waiting occurs here in our testing. It's possible -- and even with the normal request_firmware(), in theory. The missing piece is that you need to inform the helper to retry the f/w loading. Currently the direct f/w loader assumes that the file is there and returns error if not present. If we implement a retry, another question is how to trigger it, i.e. how the helper can know when a fs is mounted a new file is present. Got it, thanks Takashi and all. So looks we should(and already done for most audio firmware) implement it as Dmitry and Linus proposed, that is to make sure request_firmware() calls are not in driver's probe() paths. Yalin help posted sample code for this implementation(to request firmware in device node open) and actually I also did similar for Broadwell ADSP driver and will send out later, thank you all. Keyon, we have a similar situation to that of the FPGA example that Linus described when the DSP driver uses topology data. i.e. the audio driver will have no PCM devices that can be opened (to initiate the FW loading) until after the FW is loaded. The topology data is part of the FW and contains the PCMs, kcontrols, graphs etc. i.e. a PCM device is created for every PCM description found in the FW topology data. I think the options are to either :- 1) Don not support audio DSP drivers using topology data as built-in drivers. Audio is not really a critical system required for booting anyway. 2) Create a default PCM for every driver that has topology data on the assumption that every sound card will at least 1 PCM. This PCM can then be re-configured when the FW is loaded. Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH v3] ASoC: Add support for NAU8825 codec to ASoC
On Mon, 2015-07-13 at 15:33 +0800, Chih-Chiang Chang wrote:
> +static void set_sys_clk(struct snd_soc_codec *codec, int sys_clk)
> +{
> +struct nau8825_priv *nau8825 = snd_soc_codec_get_drvdata(codec);
> +
> +pr_debug("%s :: sys_clk=%x\n", __func__, sys_clk);
> +switch (sys_clk) {
> +case NAU8825_INTERNALCLOCK:
> +regmap_update_bits(nau8825->regmap, NAU8825_CLK_DIVIDER,
> +NAU8825_SYSCLK_EN_MASK, NAU8825_SYSCLK_DIS);
> +regmap_update_bits(nau8825->regmap, NAU8825_FLL_6,
> +NAU8825_DCO_EN_MASK, NAU8825_DCO_EN);
> +regmap_update_bits(nau8825->regmap, NAU8825_CLK_DIVIDER,
> +NAU8825_SYSCLK_EN_MASK, NAU8825_SYSCLK_EN);
> +break;
> +case NAU8825_MCLK:
> +default:
> +regmap_update_bits(nau8825->regmap, NAU8825_FLL_6,
> +NAU8825_DCO_EN_MASK, NAU8825_DCO_DIS);
> +regmap_update_bits(nau8825->regmap, NAU8825_I2S_PCM_CTRL_2,
> +NAU8825_I2S_MS_MASK, NAU8825_I2S_MS_SLAVE);
> +/* FLL clock source from MCLK */
> +regmap_update_bits(nau8825->regmap, NAU8825_CLK_DIVIDER,
> +NAU8825_SYSCLK_EN_MASK, NAU8825_SYSCLK_DIS);
> +mdelay(2);
Probably best to sleep here rather than block, especially if this code
will be used in init/PM sequences.
Btw, is there anyway to check whether the FLL actually achieves lock
after the 2ms ?
> +regmap_update_bits(nau8825->regmap, NAU8825_CLK_DIVIDER,
> +NAU8825_SYSCLK_EN_MASK, NAU8825_SYSCLK_EN);
> +break;
> +}
> +}
> +
Thanks
Liam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH v3] ASoC: Add support for NAU8825 codec to ASoC
On Mon, 2015-07-13 at 15:33 +0800, Chih-Chiang Chang wrote:
+static void set_sys_clk(struct snd_soc_codec *codec, int sys_clk)
+{
+struct nau8825_priv *nau8825 = snd_soc_codec_get_drvdata(codec);
+
+pr_debug(%s :: sys_clk=%x\n, __func__, sys_clk);
+switch (sys_clk) {
+case NAU8825_INTERNALCLOCK:
+regmap_update_bits(nau8825-regmap, NAU8825_CLK_DIVIDER,
+NAU8825_SYSCLK_EN_MASK, NAU8825_SYSCLK_DIS);
+regmap_update_bits(nau8825-regmap, NAU8825_FLL_6,
+NAU8825_DCO_EN_MASK, NAU8825_DCO_EN);
+regmap_update_bits(nau8825-regmap, NAU8825_CLK_DIVIDER,
+NAU8825_SYSCLK_EN_MASK, NAU8825_SYSCLK_EN);
+break;
+case NAU8825_MCLK:
+default:
+regmap_update_bits(nau8825-regmap, NAU8825_FLL_6,
+NAU8825_DCO_EN_MASK, NAU8825_DCO_DIS);
+regmap_update_bits(nau8825-regmap, NAU8825_I2S_PCM_CTRL_2,
+NAU8825_I2S_MS_MASK, NAU8825_I2S_MS_SLAVE);
+/* FLL clock source from MCLK */
+regmap_update_bits(nau8825-regmap, NAU8825_CLK_DIVIDER,
+NAU8825_SYSCLK_EN_MASK, NAU8825_SYSCLK_DIS);
+mdelay(2);
Probably best to sleep here rather than block, especially if this code
will be used in init/PM sequences.
Btw, is there anyway to check whether the FLL actually achieves lock
after the 2ms ?
+regmap_update_bits(nau8825-regmap, NAU8825_CLK_DIVIDER,
+NAU8825_SYSCLK_EN_MASK, NAU8825_SYSCLK_EN);
+break;
+}
+}
+
Thanks
Liam
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH] ACPI: Adjust the return value of _REV on x86
On Tue, 2015-03-24 at 00:50 -0500, Mario Limonciello wrote: > I believe a majority of the kernel work is complete, but from some off > kernel mailing list discussions I understand that pulseaudio doesn't > understand the control interface that gets used for I2S for jack > detection. There is some work in progress here to standardise the jack kcontrols between HDA, ASoC and other ALSA drivers. I would expect this to be upstream in the next week or two. > UCM can't be used for it. UCM configs and jack support for this DSP and codec combination have now been upstreamed :) > This leads to a really confusing mixer design that needs a variety of > toggles manually changed when headphones or a headset get plugged in. Generic patches to support UCM jack switching are now upstream in pulseaudio too. > There have also been some stability problem with audio reported > after a few days usage. Can you send these to me privately. Thanks Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH] ACPI: Adjust the return value of _REV on x86
On Tue, 2015-03-24 at 00:50 -0500, Mario Limonciello wrote: I believe a majority of the kernel work is complete, but from some off kernel mailing list discussions I understand that pulseaudio doesn't understand the control interface that gets used for I2S for jack detection. There is some work in progress here to standardise the jack kcontrols between HDA, ASoC and other ALSA drivers. I would expect this to be upstream in the next week or two. UCM can't be used for it. UCM configs and jack support for this DSP and codec combination have now been upstreamed :) This leads to a really confusing mixer design that needs a variety of toggles manually changed when headphones or a headset get plugged in. Generic patches to support UCM jack switching are now upstream in pulseaudio too. There have also been some stability problem with audio reported after a few days usage. Can you send these to me privately. Thanks Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 1/2] ASoC: rt5677: Add ACPI device probing
On Tue, 2014-11-25 at 08:01 -0800, Darren Hart wrote: > > On 11/25/14 06:28, Liam Girdwood wrote: > > On Tue, 2014-11-25 at 12:11 +, Grant Likely wrote: > >> On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang wrote: > >>> The rt5677 codec driver looks for ACPI device ID "RT5677CE", > >>> which is specified in coreboot. This patch allows platform > >>> data to be obtained via ACPI > >>> > >>> Signed-off-by: Ben Zhang > >> > >> This looks like an ideal time to talk about shared DT and ACPI driver > >> bindings. This driver /already/ has a firmware binding. It is > >> documented in the kernel under > >> Documentation/bindings/sound/rt5677.txt. We now have a standard method > >> for sharing bindings between DT and ACPI in the _DSD method[1]. > >> Support for DSD is in linux-next and getting merged into v3.19. This > >> is exactly the case that _DSD should be used for passing additional > >> data to the driver, and it should use the existing binding. > >> > >> [1] > >> http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf > >> > >> For a long time we've had the rule on DT that new bindings must be > >> documented before we merge a patch. That rule I think has been a good > >> one, even if it is a little chaoitc. I think when it comes to ACPI > >> drivers that we should be requiring the same: Document the binding, > >> either in the kernel as a DT binding, or point to somewhere else that > >> has the binding documented. > >> > >> Also, since this patch is targeted at v3.19 or later, the > >> device-properties API should be used. Don't create something custom. > >> > > > > My sentiments exactly, there would be little point having bespoke device > > properties for every single device. Btw, we also need to align here with > > Windows too ! > > > > The Windows folks definitely know about _DSD (and helped define it), so > this is a good opportunity to work through that process. Liam, do you > have a good contact to start that discussion? > I do, I've contacted them off-list to align on this with Realtek. Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 1/2] ASoC: rt5677: Add ACPI device probing
On Tue, 2014-11-25 at 12:11 +, Grant Likely wrote: > On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang wrote: > > The rt5677 codec driver looks for ACPI device ID "RT5677CE", > > which is specified in coreboot. This patch allows platform > > data to be obtained via ACPI > > > > Signed-off-by: Ben Zhang > > This looks like an ideal time to talk about shared DT and ACPI driver > bindings. This driver /already/ has a firmware binding. It is > documented in the kernel under > Documentation/bindings/sound/rt5677.txt. We now have a standard method > for sharing bindings between DT and ACPI in the _DSD method[1]. > Support for DSD is in linux-next and getting merged into v3.19. This > is exactly the case that _DSD should be used for passing additional > data to the driver, and it should use the existing binding. > > [1] > http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf > > For a long time we've had the rule on DT that new bindings must be > documented before we merge a patch. That rule I think has been a good > one, even if it is a little chaoitc. I think when it comes to ACPI > drivers that we should be requiring the same: Document the binding, > either in the kernel as a DT binding, or point to somewhere else that > has the binding documented. > > Also, since this patch is targeted at v3.19 or later, the > device-properties API should be used. Don't create something custom. > My sentiments exactly, there would be little point having bespoke device properties for every single device. Btw, we also need to align here with Windows too ! Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 1/2] ASoC: rt5677: Add ACPI device probing
On Tue, 2014-11-25 at 12:11 +, Grant Likely wrote: On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang be...@chromium.org wrote: The rt5677 codec driver looks for ACPI device ID RT5677CE, which is specified in coreboot. This patch allows platform data to be obtained via ACPI Signed-off-by: Ben Zhang be...@chromium.org This looks like an ideal time to talk about shared DT and ACPI driver bindings. This driver /already/ has a firmware binding. It is documented in the kernel under Documentation/bindings/sound/rt5677.txt. We now have a standard method for sharing bindings between DT and ACPI in the _DSD method[1]. Support for DSD is in linux-next and getting merged into v3.19. This is exactly the case that _DSD should be used for passing additional data to the driver, and it should use the existing binding. [1] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf For a long time we've had the rule on DT that new bindings must be documented before we merge a patch. That rule I think has been a good one, even if it is a little chaoitc. I think when it comes to ACPI drivers that we should be requiring the same: Document the binding, either in the kernel as a DT binding, or point to somewhere else that has the binding documented. Also, since this patch is targeted at v3.19 or later, the device-properties API should be used. Don't create something custom. My sentiments exactly, there would be little point having bespoke device properties for every single device. Btw, we also need to align here with Windows too ! Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 1/2] ASoC: rt5677: Add ACPI device probing
On Tue, 2014-11-25 at 08:01 -0800, Darren Hart wrote: On 11/25/14 06:28, Liam Girdwood wrote: On Tue, 2014-11-25 at 12:11 +, Grant Likely wrote: On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang be...@chromium.org wrote: The rt5677 codec driver looks for ACPI device ID RT5677CE, which is specified in coreboot. This patch allows platform data to be obtained via ACPI Signed-off-by: Ben Zhang be...@chromium.org This looks like an ideal time to talk about shared DT and ACPI driver bindings. This driver /already/ has a firmware binding. It is documented in the kernel under Documentation/bindings/sound/rt5677.txt. We now have a standard method for sharing bindings between DT and ACPI in the _DSD method[1]. Support for DSD is in linux-next and getting merged into v3.19. This is exactly the case that _DSD should be used for passing additional data to the driver, and it should use the existing binding. [1] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf For a long time we've had the rule on DT that new bindings must be documented before we merge a patch. That rule I think has been a good one, even if it is a little chaoitc. I think when it comes to ACPI drivers that we should be requiring the same: Document the binding, either in the kernel as a DT binding, or point to somewhere else that has the binding documented. Also, since this patch is targeted at v3.19 or later, the device-properties API should be used. Don't create something custom. My sentiments exactly, there would be little point having bespoke device properties for every single device. Btw, we also need to align here with Windows too ! The Windows folks definitely know about _DSD (and helped define it), so this is a good opportunity to work through that process. Liam, do you have a good contact to start that discussion? I do, I've contacted them off-list to align on this with Realtek. Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] ASoC: dpcm: don't do hw_param when BE has done hw_param
On Sat, 2014-01-11 at 10:35 +0100, Takashi Iwai wrote: > At Fri, 10 Jan 2014 18:43:09 +, > Liam Girdwood wrote: > > > > On Fri, 2014-01-10 at 14:46 +0100, Takashi Iwai wrote: > > > At Fri, 10 Jan 2014 12:29:08 +, > > > Liam Girdwood wrote: > > > > > > > > The intention was to use the existing alsa-lib/tinyalsa PCM hw_params > > APIs. The BE would just export itself to usespace as a PCM (but without > > the capability for direct playback/capture - just format, rate setting) > > Does it mean that, from kernel perspective, a BE creates a dedicated > (virtual) PCM device and expose it to user-space? Or just through > special API? I'm thinking a virtual PCM if you agree. We could keep the same userspace API for configuration OR we could extend the API slightly to add some snd_pcm_virtual_() functions. Extending the API would imply the virtual PCM only supports a subset of PCM API calls (avoiding any confusion/mixing with regular PCM APIs). Thanks Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] ASoC: dpcm: don't do hw_param when BE has done hw_param
On Sat, 2014-01-11 at 10:35 +0100, Takashi Iwai wrote: At Fri, 10 Jan 2014 18:43:09 +, Liam Girdwood wrote: On Fri, 2014-01-10 at 14:46 +0100, Takashi Iwai wrote: At Fri, 10 Jan 2014 12:29:08 +, Liam Girdwood wrote: The intention was to use the existing alsa-lib/tinyalsa PCM hw_params APIs. The BE would just export itself to usespace as a PCM (but without the capability for direct playback/capture - just format, rate setting) Does it mean that, from kernel perspective, a BE creates a dedicated (virtual) PCM device and expose it to user-space? Or just through special API? I'm thinking a virtual PCM if you agree. We could keep the same userspace API for configuration OR we could extend the API slightly to add some snd_pcm_virtual_() functions. Extending the API would imply the virtual PCM only supports a subset of PCM API calls (avoiding any confusion/mixing with regular PCM APIs). Thanks Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] ASoC: dpcm: don't do hw_param when BE has done hw_param
On Fri, 2014-01-10 at 14:46 +0100, Takashi Iwai wrote: > At Fri, 10 Jan 2014 12:29:08 +, > Liam Girdwood wrote: > > > > On Fri, 2014-01-10 at 13:01 +0100, Takashi Iwai wrote: > > > At Fri, 10 Jan 2014 19:59:42 +0800, > > > Nenghua Cao wrote: > > > > > > > > On 01/10/2014 07:47 PM, Liam Girdwood wrote: > > > > > On Fri, 2014-01-10 at 19:21 +0800, Nenghua Cao wrote: > > > > >> On 01/10/2014 06:55 PM, Takashi Iwai wrote: > > > > >>> [Corrected mail addresses of both Mark and Liam] > > > > >>> > > > > >> Hi, Takashi: > > > > >> Thanks for correcting my mistake. > > > > >>> At Fri, 10 Jan 2014 13:36:35 +0800, > > > > >>> Nenghua Cao wrote: > > > > >>>> > > > > >>>> From: Nenghua Cao > > > > >>>> > > > > >>>> It fixes the following case: > > > > >>>> Two FEs connects the same BE; FE1 & BE path has been opened > > > > >>>> and hw_paramed. > > > > >>>> At this momment, FE2 & BE path is being opened and hw_paramed. The > > > > >>>> BE > > > > >>>> dai will do hw_param again even if it has done hw_param. It is not > > > > >>>> reasonable. > > > > >>>> FE1>BE > > > > >>>> FE2-^ > > > > >>> > > > > >>> What happens if FE2 tries to set up an incompatible hw_params? > > > > >>> (Through a quick glance, it won't work properly well, too, > > > > >>> though...) > > > > >>> > > > > > > > > > > The intention in this case would be for the DSP FE driver to determine > > > > > if it can perform format conversion or SRC to the running BE. If the > > > > > DSP > > > > > cant do the conversion then it should fail. > > > > > > > > > >> If FE2 uses an incompatible param, it will make FE1 doesn't work. > > > > >> Maybe > > > > >> FE2 works well. > > > > >> If FE2 uses the same param, BE hw_param function will be called twice > > > > >> (This is the most happening case). > > > > >> So we can't get benefits from it. > > > > > > > > > > We shouldn't be calling the hw_params() on the BE when it's already > > > > > configured in this case. So this seems like a bug. However :- > > > > > > > > > > /* only allow hw_params() if no connected FEs are running */ > > > > > if (!snd_soc_dpcm_can_be_params(fe, be, stream)) > > > > > continue; > > > > > > > > > > if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) > > > > > && > > > > > (be->dpcm[stream].state != > > > > > SND_SOC_DPCM_STATE_HW_PARAMS) && > > > > > (be->dpcm[stream].state != > > > > > SND_SOC_DPCM_STATE_HW_FREE)) > > > > > continue; > > > > > > > > > > We do do a test to check if any connected FEs are running (i.e. > > > > > triggered) prior to calling hw_params() on the BE. Can you confirm if > > > > > the FE was running in your case ? > > > > > > > > > Hi, Liam: > > > >I am so glad to hear from you. In my case, FE1 has called hw_param, > > > > and before FE1 calls prepare/trigger function, the scheduler switches to > > > > do FE2 open, hw_param. So hw_param is called twice. > > > > > > So basically the current implementation is racy about this. > > > > > > > This is a valid use case from the userspace perspective too. The BE in > > this case is a shared resource (whether userspace is aware or not) and > > I'd expect it to take the the last configured hw_params (in this case > > FE2 hw_params) before it is triggered. > > Yes, it's how the current code works. But, what if FE1 didn't know > that it's shared? (Actually how it can be informed explicitly?) It cant atm, although this is not a problem on Android. It can be fixed when we export the graph to userspace though. > FE1 will still try to feed data in wrong formats/rates/etc, won't it? > No, FE1 wont change it's
Re: [alsa-devel] [PATCH] ASoC: dpcm: don't do hw_param when BE has done hw_param
On Fri, 2014-01-10 at 13:01 +0100, Takashi Iwai wrote: > At Fri, 10 Jan 2014 19:59:42 +0800, > Nenghua Cao wrote: > > > > On 01/10/2014 07:47 PM, Liam Girdwood wrote: > > > On Fri, 2014-01-10 at 19:21 +0800, Nenghua Cao wrote: > > >> On 01/10/2014 06:55 PM, Takashi Iwai wrote: > > >>> [Corrected mail addresses of both Mark and Liam] > > >>> > > >> Hi, Takashi: > > >> Thanks for correcting my mistake. > > >>> At Fri, 10 Jan 2014 13:36:35 +0800, > > >>> Nenghua Cao wrote: > > >>>> > > >>>> From: Nenghua Cao > > >>>> > > >>>> It fixes the following case: > > >>>> Two FEs connects the same BE; FE1 & BE path has been opened and > > >>>> hw_paramed. > > >>>> At this momment, FE2 & BE path is being opened and hw_paramed. The BE > > >>>> dai will do hw_param again even if it has done hw_param. It is not > > >>>> reasonable. > > >>>> FE1>BE > > >>>> FE2-^ > > >>> > > >>> What happens if FE2 tries to set up an incompatible hw_params? > > >>> (Through a quick glance, it won't work properly well, too, though...) > > >>> > > > > > > The intention in this case would be for the DSP FE driver to determine > > > if it can perform format conversion or SRC to the running BE. If the DSP > > > cant do the conversion then it should fail. > > > > > >> If FE2 uses an incompatible param, it will make FE1 doesn't work. Maybe > > >> FE2 works well. > > >> If FE2 uses the same param, BE hw_param function will be called twice > > >> (This is the most happening case). > > >> So we can't get benefits from it. > > > > > > We shouldn't be calling the hw_params() on the BE when it's already > > > configured in this case. So this seems like a bug. However :- > > > > > > /* only allow hw_params() if no connected FEs are running */ > > > if (!snd_soc_dpcm_can_be_params(fe, be, stream)) > > > continue; > > > > > > if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) && > > > (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) && > > > (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE)) > > > continue; > > > > > > We do do a test to check if any connected FEs are running (i.e. > > > triggered) prior to calling hw_params() on the BE. Can you confirm if > > > the FE was running in your case ? > > > > > Hi, Liam: > >I am so glad to hear from you. In my case, FE1 has called hw_param, > > and before FE1 calls prepare/trigger function, the scheduler switches to > > do FE2 open, hw_param. So hw_param is called twice. > > So basically the current implementation is racy about this. > This is a valid use case from the userspace perspective too. The BE in this case is a shared resource (whether userspace is aware or not) and I'd expect it to take the the last configured hw_params (in this case FE2 hw_params) before it is triggered. Fwiw, a similar topic came up the conference this year wrt compressed streams. The question was about configuring the BE format and rate directly from userspace. This should be possible without too much effort since the BE is essentially a PCM. e.g. from userspace 1) configure FE1 hw_params 2) configure FE2 hw_params 3) optional - configure BE1 hw_params If step 3 is not performed then the values from step2 are used. > OTOH, not calling hw_params twice is also buggy. hw_params may be > called multiple times without hw_free for the same stream if user > wants to re-setup/update the parameters. OSS emulation layer does it, > for example. This is supported under DPCM unless the BE is triggered, but will always take the last hw_params sent from userspace. Liam > > Takashi > > > > > > Thanks > > > > > > Liam > > > > > >>> > > >>> Takashi > > >>> > > >>>> > > >>>> Signed-off-by: Nenghua Cao > > >>>> --- > > >>>> sound/soc/soc-pcm.c |1 - > > >>>> 1 files changed, 0 insertions(+), 1 deletions(-) > > >>>> > > >>>> diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c > > >>>> index 891b9a9..ec07e37 100644 > >
Re: [alsa-devel] [PATCH] ASoC: dpcm: don't do hw_param when BE has done hw_param
On Fri, 2014-01-10 at 19:21 +0800, Nenghua Cao wrote: > On 01/10/2014 06:55 PM, Takashi Iwai wrote: > > [Corrected mail addresses of both Mark and Liam] > > > Hi, Takashi: > Thanks for correcting my mistake. > > At Fri, 10 Jan 2014 13:36:35 +0800, > > Nenghua Cao wrote: > >> > >> From: Nenghua Cao > >> > >> It fixes the following case: > >> Two FEs connects the same BE; FE1 & BE path has been opened and > >> hw_paramed. > >> At this momment, FE2 & BE path is being opened and hw_paramed. The BE > >> dai will do hw_param again even if it has done hw_param. It is not > >> reasonable. > >> FE1>BE > >> FE2-^ > > > > What happens if FE2 tries to set up an incompatible hw_params? > > (Through a quick glance, it won't work properly well, too, though...) > > The intention in this case would be for the DSP FE driver to determine if it can perform format conversion or SRC to the running BE. If the DSP cant do the conversion then it should fail. > If FE2 uses an incompatible param, it will make FE1 doesn't work. Maybe > FE2 works well. > If FE2 uses the same param, BE hw_param function will be called twice > (This is the most happening case). > So we can't get benefits from it. We shouldn't be calling the hw_params() on the BE when it's already configured in this case. So this seems like a bug. However :- /* only allow hw_params() if no connected FEs are running */ if (!snd_soc_dpcm_can_be_params(fe, be, stream)) continue; if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE)) continue; We do do a test to check if any connected FEs are running (i.e. triggered) prior to calling hw_params() on the BE. Can you confirm if the FE was running in your case ? Thanks Liam > > > > Takashi > > > >> > >> Signed-off-by: Nenghua Cao > >> --- > >> sound/soc/soc-pcm.c |1 - > >> 1 files changed, 0 insertions(+), 1 deletions(-) > >> > >> diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c > >> index 891b9a9..ec07e37 100644 > >> --- a/sound/soc/soc-pcm.c > >> +++ b/sound/soc/soc-pcm.c > >> @@ -1339,7 +1339,6 @@ static int dpcm_be_dai_hw_params(struct > >> snd_soc_pcm_runtime *fe, int stream) > >>continue; > >> > >>if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) && > >> - (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) && > >>(be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE)) > >>continue; > >> > >> -- > >> 1.7.0.4 > >> > >> ___ > >> Alsa-devel mailing list > >> alsa-de...@alsa-project.org > >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] ASoC: dpcm: don't do hw_param when BE has done hw_param
On Fri, 2014-01-10 at 19:21 +0800, Nenghua Cao wrote: On 01/10/2014 06:55 PM, Takashi Iwai wrote: [Corrected mail addresses of both Mark and Liam] Hi, Takashi: Thanks for correcting my mistake. At Fri, 10 Jan 2014 13:36:35 +0800, Nenghua Cao wrote: From: Nenghua Cao nh...@marvell.com It fixes the following case: Two FEs connects the same BE; FE1 BE path has been opened and hw_paramed. At this momment, FE2 BE path is being opened and hw_paramed. The BE dai will do hw_param again even if it has done hw_param. It is not reasonable. FE1BE FE2-^ What happens if FE2 tries to set up an incompatible hw_params? (Through a quick glance, it won't work properly well, too, though...) The intention in this case would be for the DSP FE driver to determine if it can perform format conversion or SRC to the running BE. If the DSP cant do the conversion then it should fail. If FE2 uses an incompatible param, it will make FE1 doesn't work. Maybe FE2 works well. If FE2 uses the same param, BE hw_param function will be called twice (This is the most happening case). So we can't get benefits from it. We shouldn't be calling the hw_params() on the BE when it's already configured in this case. So this seems like a bug. However :- /* only allow hw_params() if no connected FEs are running */ if (!snd_soc_dpcm_can_be_params(fe, be, stream)) continue; if ((be-dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) (be-dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) (be-dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE)) continue; We do do a test to check if any connected FEs are running (i.e. triggered) prior to calling hw_params() on the BE. Can you confirm if the FE was running in your case ? Thanks Liam Takashi Signed-off-by: Nenghua Cao nh...@marvell.com --- sound/soc/soc-pcm.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 891b9a9..ec07e37 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1339,7 +1339,6 @@ static int dpcm_be_dai_hw_params(struct snd_soc_pcm_runtime *fe, int stream) continue; if ((be-dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) - (be-dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) (be-dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE)) continue; -- 1.7.0.4 ___ Alsa-devel mailing list alsa-de...@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] ASoC: dpcm: don't do hw_param when BE has done hw_param
On Fri, 2014-01-10 at 13:01 +0100, Takashi Iwai wrote: At Fri, 10 Jan 2014 19:59:42 +0800, Nenghua Cao wrote: On 01/10/2014 07:47 PM, Liam Girdwood wrote: On Fri, 2014-01-10 at 19:21 +0800, Nenghua Cao wrote: On 01/10/2014 06:55 PM, Takashi Iwai wrote: [Corrected mail addresses of both Mark and Liam] Hi, Takashi: Thanks for correcting my mistake. At Fri, 10 Jan 2014 13:36:35 +0800, Nenghua Cao wrote: From: Nenghua Cao nh...@marvell.com It fixes the following case: Two FEs connects the same BE; FE1 BE path has been opened and hw_paramed. At this momment, FE2 BE path is being opened and hw_paramed. The BE dai will do hw_param again even if it has done hw_param. It is not reasonable. FE1BE FE2-^ What happens if FE2 tries to set up an incompatible hw_params? (Through a quick glance, it won't work properly well, too, though...) The intention in this case would be for the DSP FE driver to determine if it can perform format conversion or SRC to the running BE. If the DSP cant do the conversion then it should fail. If FE2 uses an incompatible param, it will make FE1 doesn't work. Maybe FE2 works well. If FE2 uses the same param, BE hw_param function will be called twice (This is the most happening case). So we can't get benefits from it. We shouldn't be calling the hw_params() on the BE when it's already configured in this case. So this seems like a bug. However :- /* only allow hw_params() if no connected FEs are running */ if (!snd_soc_dpcm_can_be_params(fe, be, stream)) continue; if ((be-dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) (be-dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) (be-dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE)) continue; We do do a test to check if any connected FEs are running (i.e. triggered) prior to calling hw_params() on the BE. Can you confirm if the FE was running in your case ? Hi, Liam: I am so glad to hear from you. In my case, FE1 has called hw_param, and before FE1 calls prepare/trigger function, the scheduler switches to do FE2 open, hw_param. So hw_param is called twice. So basically the current implementation is racy about this. This is a valid use case from the userspace perspective too. The BE in this case is a shared resource (whether userspace is aware or not) and I'd expect it to take the the last configured hw_params (in this case FE2 hw_params) before it is triggered. Fwiw, a similar topic came up the conference this year wrt compressed streams. The question was about configuring the BE format and rate directly from userspace. This should be possible without too much effort since the BE is essentially a PCM. e.g. from userspace 1) configure FE1 hw_params 2) configure FE2 hw_params 3) optional - configure BE1 hw_params If step 3 is not performed then the values from step2 are used. OTOH, not calling hw_params twice is also buggy. hw_params may be called multiple times without hw_free for the same stream if user wants to re-setup/update the parameters. OSS emulation layer does it, for example. This is supported under DPCM unless the BE is triggered, but will always take the last hw_params sent from userspace. Liam Takashi Thanks Liam Takashi Signed-off-by: Nenghua Cao nh...@marvell.com --- sound/soc/soc-pcm.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 891b9a9..ec07e37 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1339,7 +1339,6 @@ static int dpcm_be_dai_hw_params(struct snd_soc_pcm_runtime *fe, int stream) continue; if ((be-dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) - (be-dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) (be-dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE)) continue; -- 1.7.0.4 ___ Alsa-devel mailing list alsa-de...@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] ASoC: dpcm: don't do hw_param when BE has done hw_param
On Fri, 2014-01-10 at 14:46 +0100, Takashi Iwai wrote: At Fri, 10 Jan 2014 12:29:08 +, Liam Girdwood wrote: On Fri, 2014-01-10 at 13:01 +0100, Takashi Iwai wrote: At Fri, 10 Jan 2014 19:59:42 +0800, Nenghua Cao wrote: On 01/10/2014 07:47 PM, Liam Girdwood wrote: On Fri, 2014-01-10 at 19:21 +0800, Nenghua Cao wrote: On 01/10/2014 06:55 PM, Takashi Iwai wrote: [Corrected mail addresses of both Mark and Liam] Hi, Takashi: Thanks for correcting my mistake. At Fri, 10 Jan 2014 13:36:35 +0800, Nenghua Cao wrote: From: Nenghua Cao nh...@marvell.com It fixes the following case: Two FEs connects the same BE; FE1 BE path has been opened and hw_paramed. At this momment, FE2 BE path is being opened and hw_paramed. The BE dai will do hw_param again even if it has done hw_param. It is not reasonable. FE1BE FE2-^ What happens if FE2 tries to set up an incompatible hw_params? (Through a quick glance, it won't work properly well, too, though...) The intention in this case would be for the DSP FE driver to determine if it can perform format conversion or SRC to the running BE. If the DSP cant do the conversion then it should fail. If FE2 uses an incompatible param, it will make FE1 doesn't work. Maybe FE2 works well. If FE2 uses the same param, BE hw_param function will be called twice (This is the most happening case). So we can't get benefits from it. We shouldn't be calling the hw_params() on the BE when it's already configured in this case. So this seems like a bug. However :- /* only allow hw_params() if no connected FEs are running */ if (!snd_soc_dpcm_can_be_params(fe, be, stream)) continue; if ((be-dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) (be-dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) (be-dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE)) continue; We do do a test to check if any connected FEs are running (i.e. triggered) prior to calling hw_params() on the BE. Can you confirm if the FE was running in your case ? Hi, Liam: I am so glad to hear from you. In my case, FE1 has called hw_param, and before FE1 calls prepare/trigger function, the scheduler switches to do FE2 open, hw_param. So hw_param is called twice. So basically the current implementation is racy about this. This is a valid use case from the userspace perspective too. The BE in this case is a shared resource (whether userspace is aware or not) and I'd expect it to take the the last configured hw_params (in this case FE2 hw_params) before it is triggered. Yes, it's how the current code works. But, what if FE1 didn't know that it's shared? (Actually how it can be informed explicitly?) It cant atm, although this is not a problem on Android. It can be fixed when we export the graph to userspace though. FE1 will still try to feed data in wrong formats/rates/etc, won't it? No, FE1 wont change it's params in this state. It will be up to the DSP driver to perform the conversion to then new formats or fail if the new format cannot be supported. At best, it should return an error when an incompatible hw_params setup is done by FE2, IMO. The re-setup by FE1 should be available freely. So, BE needs to remember who has set it up, then allows only the further re-setup by that FE, for example. Fwiw, a similar topic came up the conference this year wrt compressed streams. The question was about configuring the BE format and rate directly from userspace. This should be possible without too much effort since the BE is essentially a PCM. e.g. from userspace 1) configure FE1 hw_params 2) configure FE2 hw_params 3) optional - configure BE1 hw_params If step 3 is not performed then the values from step2 are used. I forgot about this discussion -- so how was the proposal to allow BE's hw_params? A new API, or a flag in hw_params? The intention was to use the existing alsa-lib/tinyalsa PCM hw_params APIs. The BE would just export itself to usespace as a PCM (but without the capability for direct playback/capture - just format, rate setting) Thanks Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: maintainers: update email address
From: Liam Girdwood I no longer work at TI. Signed-off-by: Liam Girdwood --- MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 915564e..3c2e275 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7082,7 +7082,7 @@ F:include/uapi/sound/ F: sound/ SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEMENT (ASoC) -M: Liam Girdwood +M: Liam Girdwood M: Mark Brown T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git L: alsa-de...@alsa-project.org (moderated for non-subscribers) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: maintainers: update email address
From: Liam Girdwood liam.r.girdw...@intel.com I no longer work at TI. Signed-off-by: Liam Girdwood liam.r.girdw...@intel.com --- MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 915564e..3c2e275 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7082,7 +7082,7 @@ F:include/uapi/sound/ F: sound/ SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEMENT (ASoC) -M: Liam Girdwood l...@ti.com +M: Liam Girdwood lgirdw...@gmail.com M: Mark Brown broo...@opensource.wolfsonmicro.com T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git L: alsa-de...@alsa-project.org (moderated for non-subscribers) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sound/sgtl5000: fix initial setting for DAC data source
On 28/11/12 09:20, Oskar Schirmer wrote: According to documentation bit 3:2 in register SSS_CTRL are reserved and zero, so the setting of 0x0008 does not make much sense. Instead, bit 4 should be set as is with power up, to reflect routing of I2S_IN to DAC correctly. Looks much like an off by one error. Could you resend this to alsa-devel and CC maintainers. Thanks Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sound/sgtl5000: fix initial setting for DAC data source
On 28/11/12 09:20, Oskar Schirmer wrote: According to documentation bit 3:2 in register SSS_CTRL are reserved and zero, so the setting of 0x0008 does not make much sense. Instead, bit 4 should be set as is with power up, to reflect routing of I2S_IN to DAC correctly. Looks much like an off by one error. Could you resend this to alsa-devel and CC maintainers. Thanks Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: core: Add regulator_is_supported_voltage_tol()
On 14/11/12 07:47, Mark Brown wrote: If consumers wish to set voltages based on a tolerance it stands to reason that they will also want to query for support in the same manner. Signed-off-by: Mark Brown Acked-by: Liam Girdwood -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: core: Add regulator_is_supported_voltage_tol()
On 14/11/12 07:47, Mark Brown wrote: If consumers wish to set voltages based on a tolerance it stands to reason that they will also want to query for support in the same manner. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com Acked-by: Liam Girdwood l...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] Query about alsa ucm (use case manager) config files
On 31/10/12 12:59, Ashish Chavan wrote: > Hi, >I am just curious to know if there is any centralized repository for > alsa use case manager configuration files. I tried searching and could > only find alsa-ucm-conf.git repo at alsa project git server, which is > actually an empty repo! > This is the correct place, but I've been busy with other stuff to push our configs upstream to date (will do so today now). The eventual contents of this repo are intended to be copied into :- /usr/share/alsa/ucm (or where ever alsa is installed on your distro) However, I've not had a chance to push the UCM Nexus and Pandaboard files from Arun to this repo yet due to some other ongoing work. FYI, Arun's current UCM configs are here :- http://cgit.collabora.com/git/android/platform/external/collabora/pulseaudio-android.git/log/data/alsa/ucm/Tuna/VoiceCall > How people share/reuse ucm configuration files for a specific codec? > In near future, I will be developing few ucm configuration files for > some codecs and wish to share them with rest of the world. I think even > though ucm configs are board/machine specific, it makes sense to share > them. Is there any other, more visible place to put these config files > than board specific distributions? > Interesting idea to create separate shareable codec UCM configuration. We currently have no way to "include" a shareable codec specific configuration into a machine specific configuration but it would probably not be too hard to add to the parser. Regards Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] Query about alsa ucm (use case manager) config files
On 31/10/12 12:59, Ashish Chavan wrote: Hi, I am just curious to know if there is any centralized repository for alsa use case manager configuration files. I tried searching and could only find alsa-ucm-conf.git repo at alsa project git server, which is actually an empty repo! This is the correct place, but I've been busy with other stuff to push our configs upstream to date (will do so today now). The eventual contents of this repo are intended to be copied into :- /usr/share/alsa/ucm (or where ever alsa is installed on your distro) However, I've not had a chance to push the UCM Nexus and Pandaboard files from Arun to this repo yet due to some other ongoing work. FYI, Arun's current UCM configs are here :- http://cgit.collabora.com/git/android/platform/external/collabora/pulseaudio-android.git/log/data/alsa/ucm/Tuna/VoiceCall How people share/reuse ucm configuration files for a specific codec? In near future, I will be developing few ucm configuration files for some codecs and wish to share them with rest of the world. I think even though ucm configs are board/machine specific, it makes sense to share them. Is there any other, more visible place to put these config files than board specific distributions? Interesting idea to create separate shareable codec UCM configuration. We currently have no way to include a shareable codec specific configuration into a machine specific configuration but it would probably not be too hard to add to the parser. Regards Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: core: Fast path non-deferred disables
On Fri, 2012-09-07 at 11:01 +0800, Mark Brown wrote: > Users (especially framework code) may end up passing in a zero deferral > time depending on runtime conditions or configuration. If they do then > just call regulator_disable() directly to save scheduling. > > Signed-off-by: Mark Brown Acked-by: Liam Girdwood -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: core: Fast path non-deferred disables
On Fri, 2012-09-07 at 11:01 +0800, Mark Brown wrote: Users (especially framework code) may end up passing in a zero deferral time depending on runtime conditions or configuration. If they do then just call regulator_disable() directly to save scheduling. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com Acked-by: Liam Girdwood l...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: core: Mark all DT based boards as having full constraints
On Fri, 2012-07-06 at 18:20 +0100, Mark Brown wrote: > Since DT doesn't provide an idiomatic mechanism for enabling full > constraints and since it's much more natural with DT to provide them > just assume that a DT enabled system has full constraints. > > Signed-off-by: Mark Brown Acked-by: Liam Girdwood -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: core: Mark all DT based boards as having full constraints
On Fri, 2012-07-06 at 18:20 +0100, Mark Brown wrote: Since DT doesn't provide an idiomatic mechanism for enabling full constraints and since it's much more natural with DT to provide them just assume that a DT enabled system has full constraints. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com Acked-by: Liam Girdwood l...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED v2][PATCH 0/6] regulator: voltage and current regulator framework
On Fri, 2008-02-22 at 11:22 +0800, eric miao wrote: > > I have a rough peek into the git tree on opensource.wolfsonmicro.com, > find another PMIC framework, and here instead is a regulator framework, > looks like a simplified or dedicated one. What is their relationship? > This is probably the old version you came across. It was tightly coupled to a particular PMIC and SoC CPU and not portable. The new version that I posted is portable and not tied to a particular PMIC or CPU architecture. The new version is hosted in the audioplus git repository (imx31 branch). > For those PMIC that covers additional features, like > - usb vbus detection (or pull-up/pull-down) > - audio codec > - touch screen > - battery monitor/ fuel gauge > - battery charger > - possible many others > > How do you plan to handle them? The WM8350 and MC13783 are both multi feature PMIC's like above. We handle WM8350 PMIC access via a bus manager. This controls IO access to the WM8350 so that client driver (including the regulator driver) IO does not collide. We also cache non volatile PMIC registers to speed up access. Please have a look at drivers/regulator/wm8350/wm8350-bus.c in the imx31 branch for details. Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED v2][PATCH 0/6] regulator: voltage and current regulator framework
On Fri, 2008-02-22 at 11:22 +0800, eric miao wrote: I have a rough peek into the git tree on opensource.wolfsonmicro.com, find another PMIC framework, and here instead is a regulator framework, looks like a simplified or dedicated one. What is their relationship? This is probably the old version you came across. It was tightly coupled to a particular PMIC and SoC CPU and not portable. The new version that I posted is portable and not tied to a particular PMIC or CPU architecture. The new version is hosted in the audioplus git repository (imx31 branch). For those PMIC that covers additional features, like - usb vbus detection (or pull-up/pull-down) - audio codec - touch screen - battery monitor/ fuel gauge - battery charger - possible many others How do you plan to handle them? The WM8350 and MC13783 are both multi feature PMIC's like above. We handle WM8350 PMIC access via a bus manager. This controls IO access to the WM8350 so that client driver (including the regulator driver) IO does not collide. We also cache non volatile PMIC registers to speed up access. Please have a look at drivers/regulator/wm8350/wm8350-bus.c in the imx31 branch for details. Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED v2][PATCH 0/6] regulator: voltage and current regulator framework
On Thu, 2008-02-21 at 08:41 +, Russell King - ARM Linux wrote: > On Wed, Feb 20, 2008 at 05:08:46PM +0000, Liam Girdwood wrote: > > This patch series provides a generic framework to allow device drivers > > to control voltage and current regulators on SoC based devices (e.g. > > phones, gps, media players). > > Note that I'm explicitly avoiding commenting on this as far as PXA3xx > devices go, until we're further down the road with PM support on that > SoC. It's not clear at present whether a generic PMIC framework will > be suitable for this SoC since it's my understanding from Marvell that > we need to talk to the PMIC from IRQs-off contexts. > > So don't take my silence as some sort of acceptance of this code; it > isn't. I wasn't ;) It then might be worth adding this functionality at a later stage when more can be said about PXA3xx PMIC support. We could always have a version of the _set() functions that are designed to handle this case. In the mean time this works well on 3 other SoC CPUs. Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED v2][PATCH 0/6] regulator: voltage and current regulator framework
On Thu, 2008-02-21 at 08:41 +, Russell King - ARM Linux wrote: On Wed, Feb 20, 2008 at 05:08:46PM +, Liam Girdwood wrote: This patch series provides a generic framework to allow device drivers to control voltage and current regulators on SoC based devices (e.g. phones, gps, media players). Note that I'm explicitly avoiding commenting on this as far as PXA3xx devices go, until we're further down the road with PM support on that SoC. It's not clear at present whether a generic PMIC framework will be suitable for this SoC since it's my understanding from Marvell that we need to talk to the PMIC from IRQs-off contexts. So don't take my silence as some sort of acceptance of this code; it isn't. I wasn't ;) It then might be worth adding this functionality at a later stage when more can be said about PXA3xx PMIC support. We could always have a version of the _set() functions that are designed to handle this case. In the mean time this works well on 3 other SoC CPUs. Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] regulator: regulator framework build.
This patch adds support to build the regulator core. Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]> --- drivers/Kconfig|2 ++ drivers/Makefile |1 + drivers/regulator/Kconfig | 32 drivers/regulator/Makefile |9 + 4 files changed, 44 insertions(+), 0 deletions(-) create mode 100644 drivers/regulator/Kconfig create mode 100644 drivers/regulator/Makefile diff --git a/drivers/Kconfig b/drivers/Kconfig index 3a0e354..cc5946c 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -62,6 +62,8 @@ source "drivers/hwmon/Kconfig" source "drivers/thermal/Kconfig" +source "drivers/regulator/Kconfig" + source "drivers/watchdog/Kconfig" source "drivers/ssb/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile index e5e394a..3d0264e 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -66,6 +66,7 @@ obj-$(CONFIG_W1) += w1/ obj-$(CONFIG_POWER_SUPPLY) += power/ obj-$(CONFIG_HWMON)+= hwmon/ obj-$(CONFIG_THERMAL) += thermal/ +obj-$(CONFIG_REGULATOR)+= regulator/ obj-$(CONFIG_WATCHDOG) += watchdog/ obj-$(CONFIG_PHONE)+= telephony/ obj-$(CONFIG_MD) += md/ diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig new file mode 100644 index 000..51b8d06 --- /dev/null +++ b/drivers/regulator/Kconfig @@ -0,0 +1,32 @@ +menu "Voltage and Current regulators" + +config REGULATOR + bool "Voltage and Current Regulator Support" + default n + help + Generic Voltage and Current Regulator support. + + This framework is designed to provide a generic interface to voltage + and current regulators within the Linux kernel. It's intended to + provide voltage and current control to client or consumer drivers and + also provide status information to user space applications through a + sysfs interface. + + The intention is to allow systems to dynamically control regulator + output in order to save power and prolong battery life. This applies + to both voltage regulators (where voltage output is controllable) and + current sinks (where current output is controllable). + + This framework safely compiles out if not selected so that client + drivers can still be used in systems with no software controllable + regulators. + + If unsure, say no. + +config REGULATOR_DEBUG + bool "Regulator debug support" + depends on REGULATOR + help + Say yes here to enable debugging support. + +endmenu diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile new file mode 100644 index 000..3f70871 --- /dev/null +++ b/drivers/regulator/Makefile @@ -0,0 +1,9 @@ +# +# Makefile for regulator drivers. +# + +obj-$(CONFIG_REGULATOR) += reg-core.o + +ifeq ($(CONFIG_REGULATOR_DEBUG),y) + EXTRA_CFLAGS+= -DDEBUG +endif -- 1.5.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] regulator: add maintainers.
Added Liam Girdwood and Mark Brown as maintainers. Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]> --- MAINTAINERS |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 082d1ee..1f7d3ce 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4254,6 +4254,15 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] S: Maintained +VOLTAGE AND CURRENT REGULATOR FRAMEWORK +P: Liam Girdwood +M: [EMAIL PROTECTED] +P: Mark Brown +M: [EMAIL PROTECTED] +W: http://opensource.wolfsonmicro.com/node/15 +T: git opensource.wolfsonmicro.com:/linux-2.6-audioplus.git +S: Supported + VT1211 HARDWARE MONITOR DRIVER P: Juerg Haefliger M: [EMAIL PROTECTED] -- 1.5.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] regulator: regulator core.
This patch provides the regulator framework core. The core also provides a
sysfs interface for userspace information.
Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]>
---
drivers/regulator/reg-core.c | 1049 ++
1 files changed, 1049 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/reg-core.c
diff --git a/drivers/regulator/reg-core.c b/drivers/regulator/reg-core.c
new file mode 100644
index 000..43610c6
--- /dev/null
+++ b/drivers/regulator/reg-core.c
@@ -0,0 +1,1049 @@
+/*
+ * regulator.c -- Voltage/Current Regulator framework.
+ *
+ * Copyright 2007 Wolfson Microelectronics PLC.
+ *
+ * Author: Liam Girdwood <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REGULATOR_VERSION "0.3"
+
+/* We need to undef the current macro (from include/asm/current.h) otherwise
+ * our "current" sysfs entry becomes "(get_current())".
+ */
+#undef current
+
+static DEFINE_MUTEX(list_mutex);
+static LIST_HEAD(regulator_cdevs);
+
+/**
+ * struct regulator_cdev
+ *
+ * Voltage / Current regulator class device. One for each regulator.
+ */
+struct regulator_cdev {
+ struct regulator_desc *desc;
+ int use_count;
+
+ struct list_head list;
+ struct list_head consumer_list;
+ struct blocking_notifier_head notifier;
+ struct mutex mutex;
+ struct module *owner;
+ struct class_device cdev;
+ struct regulation_constraints *constraints;
+ struct regulator_cdev *parent; /* for tree */
+
+ void *reg_data; /* regulator_cdev data */
+ void *vendor; /* regulator_cdev vendor extensions */
+};
+#define to_rcdev(cd) \
+ container_of(cd, struct regulator_cdev, cdev)
+
+/*
+ * struct regulator
+ *
+ * One for each consumer device.
+ */
+struct regulator {
+ struct device *dev;
+ struct list_head list;
+ int uA_load;
+ int uV_required;
+ int enabled;
+ struct device_attribute dev_attr;
+ struct regulator_cdev *rcdev;
+};
+
+static int _regulator_is_enabled(struct regulator_cdev *rcdev);
+static int _regulator_disable(struct regulator_cdev *rcdev);
+static int _regulator_get_voltage(struct regulator_cdev *rcdev);
+static int _regulator_get_current(struct regulator_cdev *rcdev);
+static unsigned int _regulator_get_mode(struct regulator_cdev *rcdev);
+
+static struct regulator *get_regulator_load(struct device *dev)
+{
+ struct regulator *regulator = NULL;
+ struct regulator_cdev *rcdev;
+
+ list_for_each_entry(rcdev, _cdevs, list) {
+ list_for_each_entry(regulator, >consumer_list, list) {
+ if (regulator->dev == dev)
+ return regulator;
+ }
+ }
+ return NULL;
+}
+
+static int regulator_check_voltage(struct regulator_cdev *rcdev, int uV)
+{
+ if (!rcdev->constraints) {
+ printk(KERN_ERR "%s: no constraints for %s\n", __func__,
+ rcdev->desc->name);
+ return -ENODEV;
+ }
+ if (!rcdev->constraints->valid_ops_mask & REGULATOR_CHANGE_VOLTAGE) {
+ printk(KERN_ERR "%s: operation not allowed for %s\n",
+ __func__, rcdev->desc->name);
+ return -EPERM;
+ }
+ if (uV > rcdev->constraints->max_uV ||
+ uV < rcdev->constraints->min_uV) {
+ printk(KERN_ERR "%s: invalid voltage %duV for %s\n",
+ __func__, uV, rcdev->desc->name);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int regulator_check_current(struct regulator_cdev *rcdev, int uA)
+{
+ if (!rcdev->constraints) {
+ printk(KERN_ERR "%s: no constraints for %s\n", __func__,
+ rcdev->desc->name);
+ return -ENODEV;
+ }
+ if (!rcdev->constraints->valid_ops_mask & REGULATOR_CHANGE_CURRENT) {
+ printk(KERN_ERR "%s: operation not allowed for %s\n",
+ __func__, rcdev->desc->name);
+ return -EPERM;
+ }
+ if (uA > rcdev->constraints->max_uA ||
+ uA < rcdev->constraints->min_uA) {
+ printk(KERN_ERR "%s: invalid current %duA for %s\n",
+ __func__, uA, rcdev->desc->name);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int regulator_check_mode(struct regulator_cd
[PATCH 2/6] regulator: regulator driver interface.
This interface allows regulator drivers to register their voltage and current
regulators with the core. It also has a notifier call chain for propagating
regulator events to clients.
Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]>
---
include/linux/regulator/regulator-drv.h | 119 +++
1 files changed, 119 insertions(+), 0 deletions(-)
create mode 100644 include/linux/regulator/regulator-drv.h
diff --git a/include/linux/regulator/regulator-drv.h
b/include/linux/regulator/regulator-drv.h
new file mode 100644
index 000..3c9b398
--- /dev/null
+++ b/include/linux/regulator/regulator-drv.h
@@ -0,0 +1,119 @@
+/*
+ * regulator-drv.h -- SoC Regulator support.
+ *
+ * Copyright (C) 2007, 2008 Wolfson Microelectronics PLC.
+ *
+ * Author: Liam Girdwood <[EMAIL PROTECTED]>
+ *
+ * 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.
+ *
+ * Regulator Driver Interface.
+ */
+
+
+#ifndef __LINUX_REGULATOR_DRV_H_
+#define __LINUX_REGULATOR_DRV_H_
+
+#include
+#include
+
+struct regulator_constraints;
+struct regulator_cdev;
+
+/**
+ * struct regulator_ops - regulator operations.
+ *
+ * This struct describes regulator operations.
+ */
+struct regulator_ops {
+
+ /* get/set regulator voltage */
+ int (*set_voltage)(struct regulator_cdev *, int uV);
+ int (*get_voltage)(struct regulator_cdev *);
+
+ /* get/set regulator current */
+ int (*set_current)(struct regulator_cdev *, int uA);
+ int (*get_current)(struct regulator_cdev *);
+
+ /* enable/disable regulator */
+ int (*enable)(struct regulator_cdev *);
+ int (*disable)(struct regulator_cdev *);
+ int (*is_enabled)(struct regulator_cdev *);
+
+ /* get/set regulator operating mode (defined in regulator.h) */
+ int (*set_mode)(struct regulator_cdev *, unsigned int mode);
+ unsigned int (*get_mode)(struct regulator_cdev *);
+
+ /* get most efficient regulator operating mode for load */
+ unsigned int (*get_optimum_mode)(struct regulator_cdev *, int input_uV,
+ int output_uV, int load_uA);
+};
+
+/*
+ * Regulators can either control voltage or current.
+ */
+enum regulator_type {
+ REGULATOR_VOLTAGE,
+ REGULATOR_CURRENT,
+};
+
+/**
+ * struct regulator_desc - Regulator descriptor
+ *
+ */
+struct regulator_desc {
+ const char *name;
+ int id;
+ struct regulator_ops *ops;
+ int irq;
+ enum regulator_type type;
+ struct module *owner;
+};
+
+/**
+ * regulator_register - register regulator
+ * @regulator: regulator source
+ * @reg_data: private regulator data
+ *
+ * Called by regulator drivers to register a regulator.
+ * Returns 0 on success.
+ */
+struct regulator_cdev *regulator_register(
+ struct regulator_desc *regulator_desc, void *reg_data);
+
+/**
+ * regulator_unregister - unregister regulator
+ * @regulator: regulator source
+ *
+ * Called by regulator drivers to unregister a regulator.
+ */
+void regulator_unregister(struct regulator_cdev *rcdev);
+
+/**
+ * regulator_notifier_call_chain - call regulator event notifier
+ * @regulator: regulator source
+ * @event: notifier block
+ * @data:
+ *
+ * Called by regulator drivers to notify clients a regulator event has
+ * occurred.
+ */
+int regulator_notifier_call_chain(struct regulator_cdev *rcdev,
+ unsigned long event, void *data);
+
+/**
+ * regulator_get_drvdata - get regulator driver data
+ * @regulator: regulator
+ */
+void *rcdev_get_drvdata (struct regulator_cdev *rcdev);
+
+/**
+ * regulator_get_id - get regulator ID
+ * @regulator: regulator
+ */
+int rcdev_get_id (struct regulator_cdev *rcdev);
+
+
+#endif
--
1.5.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] regulator: platform level interface.
This interface configures a regulator for use within a specific device. It
allows for the creation of voltage and current domains (with constraints) for
each regulator. Regulator constraints help prevent device damage by providing
protection for over voltage or over current events caused by buggy client
drivers.
This interface also allows the creation of a regulator tree whereby some
regulators are supplied by others (similar to a clock tree). This means a
parent regulator will be enabled before it's children are enabled and
disabled after it's children have all been disabled.
Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]>
---
include/linux/regulator/regulator-platform.h | 104 ++
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644 include/linux/regulator/regulator-platform.h
diff --git a/include/linux/regulator/regulator-platform.h
b/include/linux/regulator/regulator-platform.h
new file mode 100644
index 000..5558630
--- /dev/null
+++ b/include/linux/regulator/regulator-platform.h
@@ -0,0 +1,104 @@
+/*
+ * regulator-platform.h -- SoC Regulator support, platform driver API.
+ *
+ * Copyright (C) 2007, 2008 Wolfson Microelectronics PLC.
+ *
+ * Author: Liam Girdwood <[EMAIL PROTECTED]>
+ *
+ * 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.
+ *
+ * Regulator Platform Interface.
+ */
+
+
+#ifndef __LINUX_REGULATOR_PLATFORM_H_
+#define __LINUX_REGULATOR_PLATFORM_H_
+
+#include
+
+struct regulator;
+
+/*
+ * Regulator operation constraint flags. These flags are used to enable
+ * certain regulator operations.
+ *
+ * @VOLTAGE: Regulator output voltage can be changed by software on this
+ *board/machine.
+ * @CURRENT: Regulator output current can be changed by software on this
+ *board machine.
+ * @MODE: Regulator operating mode can be changed by software on this
+ *board machine.
+ * @STATUS: Regulator can be enabled and disabled.
+ * @DRMS: Dynamic Regulator Mode Switching is enabled for this regulator.
+ */
+
+#define REGULATOR_CHANGE_VOLTAGE 0x1
+#define REGULATOR_CHANGE_CURRENT 0x2
+#define REGULATOR_CHANGE_MODE 0x4
+#define REGULATOR_CHANGE_STATUS0x8
+#define REGULATOR_CHANGE_DRMS 0x10
+
+/**
+ * struct regulation_constraints - regulator operating constraints.
+ *
+ * This struct describes regulator and board/machine specific constraints.
+ */
+struct regulation_constraints {
+
+ char *name;
+
+ /* voltage output range - for voltage control */
+ int min_uV;
+ int max_uV;
+
+ /* current output range - for current control */
+ int min_uA;
+ int max_uA;
+
+ /* valid regulator operating modes for this machine */
+ unsigned int valid_modes_mask;
+
+ /* valid operations for regulator on this machine */
+ unsigned int valid_ops_mask;
+
+ /* input voltage */
+ int input_uV;
+};
+
+/**
+ * regulator_set_platform_source - set regulator source regulator
+ * @regulator: regulator source
+ * @parent: source or parent regulator
+ *
+ * Called by platform initialisation code to set the source supply or "parent"
+ * regulator for this regulator. This ensures that a regulator source will
+ * also be enabled by the core if it's child is enabled.
+ */
+int regulator_set_platform_source(const char *regulator_source,
+ const char *regulator_parent);
+
+/**
+ * regulator_get_platform_source - get regulator source regulator
+ * @regulator: regulator source
+ *
+ * Returns the regulator supply regulator or NULL if no supply regulator
+ * exists (i.e the regulator is supplied directly from USB, Line, Battery, etc)
+ */
+const char *regulator_get_platform_source(const char *regulator_name);
+
+
+/**
+ * regulator_set_platform_constraints - sets regulator constraints
+ * @regulator: regulator source
+ *
+ * Allows platform initialisation code to define and constrain regulator
+ * circuits e.g. valid voltage/current ranges, etc.
+ * NOTE: Constraints *must* be set by platform code in order for some
+ * regulator operations to proceed i.e. set_voltage, set_current, set_mode.
+ */
+int regulator_set_platform_constraints(const char *regulator_name,
+ struct regulation_constraints *constraints);
+
+#endif
--
1.5.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] regulator: consumer driver regulator control framework.
This framework provides voltage and current regulator control to allow consumer drivers to control their supply voltages and current levels. The framework is similar to the kernel clock interface in that client or consumer drivers can get() and put() a regulator (like they can with clocks atm). Consumers can also get() or set() :- voltage, current, operating mode. Consumers can also enable and disable regulators. The framework also compiles out if not in use so drivers can be reused in systems with no software PMIC power control. Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]> --- include/linux/regulator/regulator.h | 365 +++ 1 files changed, 365 insertions(+), 0 deletions(-) create mode 100644 include/linux/regulator/regulator.h diff --git a/include/linux/regulator/regulator.h b/include/linux/regulator/regulator.h new file mode 100644 index 000..7494968 --- /dev/null +++ b/include/linux/regulator/regulator.h @@ -0,0 +1,365 @@ +/* + * regulator.h -- SoC Regulator support. + * + * Copyright (C) 2007, 2008 Wolfson Microelectronics PLC. + * + * Author: Liam Girdwood <[EMAIL PROTECTED]> + * + * 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. + * + * Regulator Client Interface. + * + * A Power Management Regulator framework for SoC based devices. + * Features:- + * o Voltage and current level control. + * o Operating mode control. + * o Regulator status. + * o sysfs entries for showing client devices and status + * + * EXPERIMENTAL FEATURES: + * Dynamic Regulator operating Mode Switching (DRMS) - allows regulators + * to use most efficient operating mode depending upon voltage and load and + * is transparent to client drivers. + * + * e.g. Devices x,y,z share regulator r. Device x and y draw 20mA each during + * IO and 1mA at idle. Device z draws 100mA when under load and 5mA when + * idling. Regulator r has > 90% efficieny in NORMAL mode at loads > 100mA + * but this drops rapidly to 60% when below 100mA. Regulator r has > 90% + * efficiency in IDLE mode at loads < 10mA. Thus regulator r will operate + * in normal mode for loads > 10mA and in IDLE mode for load <= 10mA. + * + * Dynamic Regulator Voltage Selection (DRVS). Selects the lowest voltage + * output (within system constraints) for a regulator shared between several + * devices. This allows all devices to operate within their voltage range and + * will dynamically change the voltage when devices disable() thier supply + * to the next best level (thus saving power). This is based on an idea + * by Amit Kucheria in an RFC to lakml. + * + * e.g. devices x,y,z share regulator r. device x and y can operate between + * 1800mV and 1900mV, whilst device z can only operate at 1900mV. Regulator + * r will output 1900mV when all devices are in use and 1800mV when devices + * x and y are in use and device z is disabled. + */ + + +#ifndef __LINUX_REGULATOR_H_ +#define __LINUX_REGULATOR_H_ + +/* + * Regulator operating modes. + * + * Regulators can run in a variety of different operating modes depending on + * output load. This allows further system power savings by selecting the + * best (and most efficient) regulator mode for a desired load. + * + * Most drivers will only care about NORMAL. The modes below are generic and + * will probably not match the naming convention of your regulator data sheet + * but should match the use cases in the datasheet. + * + * In order of power efficiency (least efficient at top). + * + * Mode Description + * FAST Regulator can handle fast changes in it's load. + * e.g. useful in CPU voltage & frequency scaling where + * load can quickly increase with CPU freqency increases. + * + * NORMAL Normal regulator power supply mode. Most drivers will + * use this mode. + * + * IDLE Regulator runs in a more efficient mode for light + * loads. Can be used for devices that have a low power + * requirement during periods of inactivity. This mode + * may be more noisy than NORMAL and may not be able + * to handle fast load switching. + * + * STANDBYRegulator runs in the most efficient mode for very + * light loads. Can be used by devices when they are + * in a sleep/standby state. This mode is likely to be + * the most noisy and may not be able to handle fast load + * switching. + * + * NOTE: Most regulators will only support a subset of these modes. Some + * will only just support NORMAL. + */ + +#define REGULATOR_MODE_FAST0x1 +#define REGULATOR_MODE_NORMAL 0x2 +#define REGULATOR_MODE_IDLE0x4 +#define REGULATOR_MODE_STANDBY 0x8 +
[UPDATED v2][PATCH 0/6] regulator: voltage and current regulator framework
Version 2 with thanks to Sam Ravnborg, Mariusz Kozlowski, David Brownell and Laura Lawrence for their comments. This patch series provides a generic framework to allow device drivers to control voltage and current regulators on SoC based devices (e.g. phones, gps, media players). The intention is to allow systems to dynamically control regulator output in order to save power and prolong battery life. This applies to both voltage regulators (where voltage output is controllable) and current sinks (where current output is controllable). The framework is designed around SoC based devices but may also be relevant to non SoC devices. It's also been designed against two Power Management ICs (PMICs) currently on the market - namely the Freescale MC13783 and the Wolfson WM8350. However it is quite generic and should apply to all PMICs. The framework provides several interfaces :- 1. Client or Consumer driver API. This uses a similar API to the kernel clock interface in that client or consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current, mode, enable and disable. This should allow clients complete control over their supply voltage and current. This API also compiles out if not in use so drivers can be reused in systems with no PMIC power control. 2. Regulator driver API. This allows regulator drivers to register their regulators and provide operations to the core. It also has a notifier call chain for propagating regulator events to clients. 3. Platform API. This API is for platform/device specific code and allows the creation of voltage/current domains (with constraints) for each regulator. It can provide regulator constraints that will prevent device damage through over voltage or over current caused by buggy client drivers. It also allows the creation of a regulator tree whereby some regulators are supplied by others (similar to a clock tree). 4. Userspace. The framework also exports a lot of useful voltage/current data to userspace via sysfs. This could be used to monitor device and regulator power and status. Fwiw, there is a project page here :- http://opensource.wolfsonmicro.com/node/15 and code in our public git tree that currently shows this API in use:- http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=shortlog;h=imx31 All the relevant files are under include/linux/regulator and drivers/regulator. There are client drivers here :- http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=arch/arm/mach-mx3/cpufreq.c;h=77f03d85fef6b29b0ca2e820d38d9ebb068e7bf7;hb=imx31 http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=drivers/leds/leds-wm8350.c;h=a81bbf9154b4de13c029aee0613294562a03f506;hb=imx31 http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=drivers/video/backlight/wm8350_bl.c;h=3eafb83683b7f242ec78ff620431307c25e23202;hb=imx31 http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=sound/soc/imx/imx32ads-wm8350.c;h=aae347ac556203fbdb64d71f4dc0be7df250767a;hb=imx31 Patch follows. Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[UPDATED v2][PATCH 0/6] regulator: voltage and current regulator framework
Version 2 with thanks to Sam Ravnborg, Mariusz Kozlowski, David Brownell and Laura Lawrence for their comments. This patch series provides a generic framework to allow device drivers to control voltage and current regulators on SoC based devices (e.g. phones, gps, media players). The intention is to allow systems to dynamically control regulator output in order to save power and prolong battery life. This applies to both voltage regulators (where voltage output is controllable) and current sinks (where current output is controllable). The framework is designed around SoC based devices but may also be relevant to non SoC devices. It's also been designed against two Power Management ICs (PMICs) currently on the market - namely the Freescale MC13783 and the Wolfson WM8350. However it is quite generic and should apply to all PMICs. The framework provides several interfaces :- 1. Client or Consumer driver API. This uses a similar API to the kernel clock interface in that client or consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current, mode, enable and disable. This should allow clients complete control over their supply voltage and current. This API also compiles out if not in use so drivers can be reused in systems with no PMIC power control. 2. Regulator driver API. This allows regulator drivers to register their regulators and provide operations to the core. It also has a notifier call chain for propagating regulator events to clients. 3. Platform API. This API is for platform/device specific code and allows the creation of voltage/current domains (with constraints) for each regulator. It can provide regulator constraints that will prevent device damage through over voltage or over current caused by buggy client drivers. It also allows the creation of a regulator tree whereby some regulators are supplied by others (similar to a clock tree). 4. Userspace. The framework also exports a lot of useful voltage/current data to userspace via sysfs. This could be used to monitor device and regulator power and status. Fwiw, there is a project page here :- http://opensource.wolfsonmicro.com/node/15 and code in our public git tree that currently shows this API in use:- http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=shortlog;h=imx31 All the relevant files are under include/linux/regulator and drivers/regulator. There are client drivers here :- http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=arch/arm/mach-mx3/cpufreq.c;h=77f03d85fef6b29b0ca2e820d38d9ebb068e7bf7;hb=imx31 http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=drivers/leds/leds-wm8350.c;h=a81bbf9154b4de13c029aee0613294562a03f506;hb=imx31 http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=drivers/video/backlight/wm8350_bl.c;h=3eafb83683b7f242ec78ff620431307c25e23202;hb=imx31 http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=sound/soc/imx/imx32ads-wm8350.c;h=aae347ac556203fbdb64d71f4dc0be7df250767a;hb=imx31 Patch follows. Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] regulator: consumer driver regulator control framework.
This framework provides voltage and current regulator control to allow consumer drivers to control their supply voltages and current levels. The framework is similar to the kernel clock interface in that client or consumer drivers can get() and put() a regulator (like they can with clocks atm). Consumers can also get() or set() :- voltage, current, operating mode. Consumers can also enable and disable regulators. The framework also compiles out if not in use so drivers can be reused in systems with no software PMIC power control. Signed-off-by: Liam Girdwood [EMAIL PROTECTED] --- include/linux/regulator/regulator.h | 365 +++ 1 files changed, 365 insertions(+), 0 deletions(-) create mode 100644 include/linux/regulator/regulator.h diff --git a/include/linux/regulator/regulator.h b/include/linux/regulator/regulator.h new file mode 100644 index 000..7494968 --- /dev/null +++ b/include/linux/regulator/regulator.h @@ -0,0 +1,365 @@ +/* + * regulator.h -- SoC Regulator support. + * + * Copyright (C) 2007, 2008 Wolfson Microelectronics PLC. + * + * Author: Liam Girdwood [EMAIL PROTECTED] + * + * 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. + * + * Regulator Client Interface. + * + * A Power Management Regulator framework for SoC based devices. + * Features:- + * o Voltage and current level control. + * o Operating mode control. + * o Regulator status. + * o sysfs entries for showing client devices and status + * + * EXPERIMENTAL FEATURES: + * Dynamic Regulator operating Mode Switching (DRMS) - allows regulators + * to use most efficient operating mode depending upon voltage and load and + * is transparent to client drivers. + * + * e.g. Devices x,y,z share regulator r. Device x and y draw 20mA each during + * IO and 1mA at idle. Device z draws 100mA when under load and 5mA when + * idling. Regulator r has 90% efficieny in NORMAL mode at loads 100mA + * but this drops rapidly to 60% when below 100mA. Regulator r has 90% + * efficiency in IDLE mode at loads 10mA. Thus regulator r will operate + * in normal mode for loads 10mA and in IDLE mode for load = 10mA. + * + * Dynamic Regulator Voltage Selection (DRVS). Selects the lowest voltage + * output (within system constraints) for a regulator shared between several + * devices. This allows all devices to operate within their voltage range and + * will dynamically change the voltage when devices disable() thier supply + * to the next best level (thus saving power). This is based on an idea + * by Amit Kucheria in an RFC to lakml. + * + * e.g. devices x,y,z share regulator r. device x and y can operate between + * 1800mV and 1900mV, whilst device z can only operate at 1900mV. Regulator + * r will output 1900mV when all devices are in use and 1800mV when devices + * x and y are in use and device z is disabled. + */ + + +#ifndef __LINUX_REGULATOR_H_ +#define __LINUX_REGULATOR_H_ + +/* + * Regulator operating modes. + * + * Regulators can run in a variety of different operating modes depending on + * output load. This allows further system power savings by selecting the + * best (and most efficient) regulator mode for a desired load. + * + * Most drivers will only care about NORMAL. The modes below are generic and + * will probably not match the naming convention of your regulator data sheet + * but should match the use cases in the datasheet. + * + * In order of power efficiency (least efficient at top). + * + * Mode Description + * FAST Regulator can handle fast changes in it's load. + * e.g. useful in CPU voltage frequency scaling where + * load can quickly increase with CPU freqency increases. + * + * NORMAL Normal regulator power supply mode. Most drivers will + * use this mode. + * + * IDLE Regulator runs in a more efficient mode for light + * loads. Can be used for devices that have a low power + * requirement during periods of inactivity. This mode + * may be more noisy than NORMAL and may not be able + * to handle fast load switching. + * + * STANDBYRegulator runs in the most efficient mode for very + * light loads. Can be used by devices when they are + * in a sleep/standby state. This mode is likely to be + * the most noisy and may not be able to handle fast load + * switching. + * + * NOTE: Most regulators will only support a subset of these modes. Some + * will only just support NORMAL. + */ + +#define REGULATOR_MODE_FAST0x1 +#define REGULATOR_MODE_NORMAL 0x2 +#define REGULATOR_MODE_IDLE0x4 +#define REGULATOR_MODE_STANDBY 0x8 + +/* + * Regulator notifier events. + * + * @UNDER_VOLTAGE
[PATCH 2/6] regulator: regulator driver interface.
This interface allows regulator drivers to register their voltage and current
regulators with the core. It also has a notifier call chain for propagating
regulator events to clients.
Signed-off-by: Liam Girdwood [EMAIL PROTECTED]
---
include/linux/regulator/regulator-drv.h | 119 +++
1 files changed, 119 insertions(+), 0 deletions(-)
create mode 100644 include/linux/regulator/regulator-drv.h
diff --git a/include/linux/regulator/regulator-drv.h
b/include/linux/regulator/regulator-drv.h
new file mode 100644
index 000..3c9b398
--- /dev/null
+++ b/include/linux/regulator/regulator-drv.h
@@ -0,0 +1,119 @@
+/*
+ * regulator-drv.h -- SoC Regulator support.
+ *
+ * Copyright (C) 2007, 2008 Wolfson Microelectronics PLC.
+ *
+ * Author: Liam Girdwood [EMAIL PROTECTED]
+ *
+ * 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.
+ *
+ * Regulator Driver Interface.
+ */
+
+
+#ifndef __LINUX_REGULATOR_DRV_H_
+#define __LINUX_REGULATOR_DRV_H_
+
+#include linux/device.h
+#include linux/regulator/regulator.h
+
+struct regulator_constraints;
+struct regulator_cdev;
+
+/**
+ * struct regulator_ops - regulator operations.
+ *
+ * This struct describes regulator operations.
+ */
+struct regulator_ops {
+
+ /* get/set regulator voltage */
+ int (*set_voltage)(struct regulator_cdev *, int uV);
+ int (*get_voltage)(struct regulator_cdev *);
+
+ /* get/set regulator current */
+ int (*set_current)(struct regulator_cdev *, int uA);
+ int (*get_current)(struct regulator_cdev *);
+
+ /* enable/disable regulator */
+ int (*enable)(struct regulator_cdev *);
+ int (*disable)(struct regulator_cdev *);
+ int (*is_enabled)(struct regulator_cdev *);
+
+ /* get/set regulator operating mode (defined in regulator.h) */
+ int (*set_mode)(struct regulator_cdev *, unsigned int mode);
+ unsigned int (*get_mode)(struct regulator_cdev *);
+
+ /* get most efficient regulator operating mode for load */
+ unsigned int (*get_optimum_mode)(struct regulator_cdev *, int input_uV,
+ int output_uV, int load_uA);
+};
+
+/*
+ * Regulators can either control voltage or current.
+ */
+enum regulator_type {
+ REGULATOR_VOLTAGE,
+ REGULATOR_CURRENT,
+};
+
+/**
+ * struct regulator_desc - Regulator descriptor
+ *
+ */
+struct regulator_desc {
+ const char *name;
+ int id;
+ struct regulator_ops *ops;
+ int irq;
+ enum regulator_type type;
+ struct module *owner;
+};
+
+/**
+ * regulator_register - register regulator
+ * @regulator: regulator source
+ * @reg_data: private regulator data
+ *
+ * Called by regulator drivers to register a regulator.
+ * Returns 0 on success.
+ */
+struct regulator_cdev *regulator_register(
+ struct regulator_desc *regulator_desc, void *reg_data);
+
+/**
+ * regulator_unregister - unregister regulator
+ * @regulator: regulator source
+ *
+ * Called by regulator drivers to unregister a regulator.
+ */
+void regulator_unregister(struct regulator_cdev *rcdev);
+
+/**
+ * regulator_notifier_call_chain - call regulator event notifier
+ * @regulator: regulator source
+ * @event: notifier block
+ * @data:
+ *
+ * Called by regulator drivers to notify clients a regulator event has
+ * occurred.
+ */
+int regulator_notifier_call_chain(struct regulator_cdev *rcdev,
+ unsigned long event, void *data);
+
+/**
+ * regulator_get_drvdata - get regulator driver data
+ * @regulator: regulator
+ */
+void *rcdev_get_drvdata (struct regulator_cdev *rcdev);
+
+/**
+ * regulator_get_id - get regulator ID
+ * @regulator: regulator
+ */
+int rcdev_get_id (struct regulator_cdev *rcdev);
+
+
+#endif
--
1.5.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] regulator: platform level interface.
This interface configures a regulator for use within a specific device. It
allows for the creation of voltage and current domains (with constraints) for
each regulator. Regulator constraints help prevent device damage by providing
protection for over voltage or over current events caused by buggy client
drivers.
This interface also allows the creation of a regulator tree whereby some
regulators are supplied by others (similar to a clock tree). This means a
parent regulator will be enabled before it's children are enabled and
disabled after it's children have all been disabled.
Signed-off-by: Liam Girdwood [EMAIL PROTECTED]
---
include/linux/regulator/regulator-platform.h | 104 ++
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644 include/linux/regulator/regulator-platform.h
diff --git a/include/linux/regulator/regulator-platform.h
b/include/linux/regulator/regulator-platform.h
new file mode 100644
index 000..5558630
--- /dev/null
+++ b/include/linux/regulator/regulator-platform.h
@@ -0,0 +1,104 @@
+/*
+ * regulator-platform.h -- SoC Regulator support, platform driver API.
+ *
+ * Copyright (C) 2007, 2008 Wolfson Microelectronics PLC.
+ *
+ * Author: Liam Girdwood [EMAIL PROTECTED]
+ *
+ * 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.
+ *
+ * Regulator Platform Interface.
+ */
+
+
+#ifndef __LINUX_REGULATOR_PLATFORM_H_
+#define __LINUX_REGULATOR_PLATFORM_H_
+
+#include linux/regulator/regulator.h
+
+struct regulator;
+
+/*
+ * Regulator operation constraint flags. These flags are used to enable
+ * certain regulator operations.
+ *
+ * @VOLTAGE: Regulator output voltage can be changed by software on this
+ *board/machine.
+ * @CURRENT: Regulator output current can be changed by software on this
+ *board machine.
+ * @MODE: Regulator operating mode can be changed by software on this
+ *board machine.
+ * @STATUS: Regulator can be enabled and disabled.
+ * @DRMS: Dynamic Regulator Mode Switching is enabled for this regulator.
+ */
+
+#define REGULATOR_CHANGE_VOLTAGE 0x1
+#define REGULATOR_CHANGE_CURRENT 0x2
+#define REGULATOR_CHANGE_MODE 0x4
+#define REGULATOR_CHANGE_STATUS0x8
+#define REGULATOR_CHANGE_DRMS 0x10
+
+/**
+ * struct regulation_constraints - regulator operating constraints.
+ *
+ * This struct describes regulator and board/machine specific constraints.
+ */
+struct regulation_constraints {
+
+ char *name;
+
+ /* voltage output range - for voltage control */
+ int min_uV;
+ int max_uV;
+
+ /* current output range - for current control */
+ int min_uA;
+ int max_uA;
+
+ /* valid regulator operating modes for this machine */
+ unsigned int valid_modes_mask;
+
+ /* valid operations for regulator on this machine */
+ unsigned int valid_ops_mask;
+
+ /* input voltage */
+ int input_uV;
+};
+
+/**
+ * regulator_set_platform_source - set regulator source regulator
+ * @regulator: regulator source
+ * @parent: source or parent regulator
+ *
+ * Called by platform initialisation code to set the source supply or parent
+ * regulator for this regulator. This ensures that a regulator source will
+ * also be enabled by the core if it's child is enabled.
+ */
+int regulator_set_platform_source(const char *regulator_source,
+ const char *regulator_parent);
+
+/**
+ * regulator_get_platform_source - get regulator source regulator
+ * @regulator: regulator source
+ *
+ * Returns the regulator supply regulator or NULL if no supply regulator
+ * exists (i.e the regulator is supplied directly from USB, Line, Battery, etc)
+ */
+const char *regulator_get_platform_source(const char *regulator_name);
+
+
+/**
+ * regulator_set_platform_constraints - sets regulator constraints
+ * @regulator: regulator source
+ *
+ * Allows platform initialisation code to define and constrain regulator
+ * circuits e.g. valid voltage/current ranges, etc.
+ * NOTE: Constraints *must* be set by platform code in order for some
+ * regulator operations to proceed i.e. set_voltage, set_current, set_mode.
+ */
+int regulator_set_platform_constraints(const char *regulator_name,
+ struct regulation_constraints *constraints);
+
+#endif
--
1.5.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] regulator: regulator core.
This patch provides the regulator framework core. The core also provides a
sysfs interface for userspace information.
Signed-off-by: Liam Girdwood [EMAIL PROTECTED]
---
drivers/regulator/reg-core.c | 1049 ++
1 files changed, 1049 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/reg-core.c
diff --git a/drivers/regulator/reg-core.c b/drivers/regulator/reg-core.c
new file mode 100644
index 000..43610c6
--- /dev/null
+++ b/drivers/regulator/reg-core.c
@@ -0,0 +1,1049 @@
+/*
+ * regulator.c -- Voltage/Current Regulator framework.
+ *
+ * Copyright 2007 Wolfson Microelectronics PLC.
+ *
+ * Author: Liam Girdwood [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/device.h
+#include linux/err.h
+#include linux/mutex.h
+#include linux/regulator/regulator.h
+#include linux/regulator/regulator-drv.h
+#include linux/regulator/regulator-platform.h
+
+#define REGULATOR_VERSION 0.3
+
+/* We need to undef the current macro (from include/asm/current.h) otherwise
+ * our current sysfs entry becomes (get_current()).
+ */
+#undef current
+
+static DEFINE_MUTEX(list_mutex);
+static LIST_HEAD(regulator_cdevs);
+
+/**
+ * struct regulator_cdev
+ *
+ * Voltage / Current regulator class device. One for each regulator.
+ */
+struct regulator_cdev {
+ struct regulator_desc *desc;
+ int use_count;
+
+ struct list_head list;
+ struct list_head consumer_list;
+ struct blocking_notifier_head notifier;
+ struct mutex mutex;
+ struct module *owner;
+ struct class_device cdev;
+ struct regulation_constraints *constraints;
+ struct regulator_cdev *parent; /* for tree */
+
+ void *reg_data; /* regulator_cdev data */
+ void *vendor; /* regulator_cdev vendor extensions */
+};
+#define to_rcdev(cd) \
+ container_of(cd, struct regulator_cdev, cdev)
+
+/*
+ * struct regulator
+ *
+ * One for each consumer device.
+ */
+struct regulator {
+ struct device *dev;
+ struct list_head list;
+ int uA_load;
+ int uV_required;
+ int enabled;
+ struct device_attribute dev_attr;
+ struct regulator_cdev *rcdev;
+};
+
+static int _regulator_is_enabled(struct regulator_cdev *rcdev);
+static int _regulator_disable(struct regulator_cdev *rcdev);
+static int _regulator_get_voltage(struct regulator_cdev *rcdev);
+static int _regulator_get_current(struct regulator_cdev *rcdev);
+static unsigned int _regulator_get_mode(struct regulator_cdev *rcdev);
+
+static struct regulator *get_regulator_load(struct device *dev)
+{
+ struct regulator *regulator = NULL;
+ struct regulator_cdev *rcdev;
+
+ list_for_each_entry(rcdev, regulator_cdevs, list) {
+ list_for_each_entry(regulator, rcdev-consumer_list, list) {
+ if (regulator-dev == dev)
+ return regulator;
+ }
+ }
+ return NULL;
+}
+
+static int regulator_check_voltage(struct regulator_cdev *rcdev, int uV)
+{
+ if (!rcdev-constraints) {
+ printk(KERN_ERR %s: no constraints for %s\n, __func__,
+ rcdev-desc-name);
+ return -ENODEV;
+ }
+ if (!rcdev-constraints-valid_ops_mask REGULATOR_CHANGE_VOLTAGE) {
+ printk(KERN_ERR %s: operation not allowed for %s\n,
+ __func__, rcdev-desc-name);
+ return -EPERM;
+ }
+ if (uV rcdev-constraints-max_uV ||
+ uV rcdev-constraints-min_uV) {
+ printk(KERN_ERR %s: invalid voltage %duV for %s\n,
+ __func__, uV, rcdev-desc-name);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int regulator_check_current(struct regulator_cdev *rcdev, int uA)
+{
+ if (!rcdev-constraints) {
+ printk(KERN_ERR %s: no constraints for %s\n, __func__,
+ rcdev-desc-name);
+ return -ENODEV;
+ }
+ if (!rcdev-constraints-valid_ops_mask REGULATOR_CHANGE_CURRENT) {
+ printk(KERN_ERR %s: operation not allowed for %s\n,
+ __func__, rcdev-desc-name);
+ return -EPERM;
+ }
+ if (uA rcdev-constraints-max_uA ||
+ uA rcdev-constraints-min_uA) {
+ printk(KERN_ERR %s: invalid current %duA for %s\n,
+ __func__, uA, rcdev-desc-name);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int regulator_check_mode(struct regulator_cdev *rcdev, int mode)
+{
+ if (!rcdev-constraints) {
+ printk(KERN_ERR %s
[PATCH 5/6] regulator: regulator framework build.
This patch adds support to build the regulator core. Signed-off-by: Liam Girdwood [EMAIL PROTECTED] --- drivers/Kconfig|2 ++ drivers/Makefile |1 + drivers/regulator/Kconfig | 32 drivers/regulator/Makefile |9 + 4 files changed, 44 insertions(+), 0 deletions(-) create mode 100644 drivers/regulator/Kconfig create mode 100644 drivers/regulator/Makefile diff --git a/drivers/Kconfig b/drivers/Kconfig index 3a0e354..cc5946c 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -62,6 +62,8 @@ source drivers/hwmon/Kconfig source drivers/thermal/Kconfig +source drivers/regulator/Kconfig + source drivers/watchdog/Kconfig source drivers/ssb/Kconfig diff --git a/drivers/Makefile b/drivers/Makefile index e5e394a..3d0264e 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -66,6 +66,7 @@ obj-$(CONFIG_W1) += w1/ obj-$(CONFIG_POWER_SUPPLY) += power/ obj-$(CONFIG_HWMON)+= hwmon/ obj-$(CONFIG_THERMAL) += thermal/ +obj-$(CONFIG_REGULATOR)+= regulator/ obj-$(CONFIG_WATCHDOG) += watchdog/ obj-$(CONFIG_PHONE)+= telephony/ obj-$(CONFIG_MD) += md/ diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig new file mode 100644 index 000..51b8d06 --- /dev/null +++ b/drivers/regulator/Kconfig @@ -0,0 +1,32 @@ +menu Voltage and Current regulators + +config REGULATOR + bool Voltage and Current Regulator Support + default n + help + Generic Voltage and Current Regulator support. + + This framework is designed to provide a generic interface to voltage + and current regulators within the Linux kernel. It's intended to + provide voltage and current control to client or consumer drivers and + also provide status information to user space applications through a + sysfs interface. + + The intention is to allow systems to dynamically control regulator + output in order to save power and prolong battery life. This applies + to both voltage regulators (where voltage output is controllable) and + current sinks (where current output is controllable). + + This framework safely compiles out if not selected so that client + drivers can still be used in systems with no software controllable + regulators. + + If unsure, say no. + +config REGULATOR_DEBUG + bool Regulator debug support + depends on REGULATOR + help + Say yes here to enable debugging support. + +endmenu diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile new file mode 100644 index 000..3f70871 --- /dev/null +++ b/drivers/regulator/Makefile @@ -0,0 +1,9 @@ +# +# Makefile for regulator drivers. +# + +obj-$(CONFIG_REGULATOR) += reg-core.o + +ifeq ($(CONFIG_REGULATOR_DEBUG),y) + EXTRA_CFLAGS+= -DDEBUG +endif -- 1.5.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] regulator: add maintainers.
Added Liam Girdwood and Mark Brown as maintainers. Signed-off-by: Liam Girdwood [EMAIL PROTECTED] --- MAINTAINERS |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 082d1ee..1f7d3ce 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4254,6 +4254,15 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] S: Maintained +VOLTAGE AND CURRENT REGULATOR FRAMEWORK +P: Liam Girdwood +M: [EMAIL PROTECTED] +P: Mark Brown +M: [EMAIL PROTECTED] +W: http://opensource.wolfsonmicro.com/node/15 +T: git opensource.wolfsonmicro.com:/linux-2.6-audioplus.git +S: Supported + VT1211 HARDWARE MONITOR DRIVER P: Juerg Haefliger M: [EMAIL PROTECTED] -- 1.5.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] Voltage and current regulator framework
Regulator framework core :-
diff --git a/drivers/regulator/reg-core.c b/drivers/regulator/reg-core.c
new file mode 100644
index 000..1434697
--- /dev/null
+++ b/drivers/regulator/reg-core.c
@@ -0,0 +1,1036 @@
+/*
+ * regulator.c -- Voltage/Current Regulator framework.
+ *
+ * Copyright 2007 Wolfson Microelectronics PLC.
+ *
+ * Author: Liam Girdwood <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REGULATOR_VERSION "0.2"
+
+/* We need to undef the current macro (from include/asm/current.h) otherwise
+ * our "current" sysfs entry becomes "(get_current())".
+ */
+#undef current
+
+static DEFINE_MUTEX(list_mutex);
+static LIST_HEAD(regulator_cdevs);
+
+/**
+ * struct regulator_cdev
+ *
+ * Voltage / Current regulator class device. One for each regulator.
+ */
+struct regulator_cdev {
+ struct regulator_desc *desc;
+ int use_count;
+
+ struct list_head list;
+ struct list_head consumer_list;
+ struct blocking_notifier_head notifier;
+ struct mutex mutex;
+ struct module *owner;
+ struct class_device cdev;
+ struct regulation_constraints *constraints;
+ struct regulator_cdev *parent; /* for tree */
+
+ void *reg_data; /* regulator_cdev data */
+ void *vendor; /* regulator_cdev vendor extensions */
+};
+#define to_rcdev(cd) \
+ container_of(cd, struct regulator_cdev, cdev)
+
+/*
+ * struct regulator
+ *
+ * One for each consumer device.
+ */
+struct regulator {
+ struct device *dev;
+ struct list_head list;
+ int uA_load;
+ int uV_required;
+ int enabled;
+ struct device_attribute dev_attr;
+ struct regulator_cdev *rcdev;
+};
+
+static int _regulator_is_enabled(struct regulator_cdev *rcdev);
+static int _regulator_disable(struct regulator_cdev *rcdev);
+static int _regulator_get_voltage(struct regulator_cdev *rcdev);
+static int _regulator_get_current(struct regulator_cdev *rcdev);
+static unsigned int _regulator_get_mode(struct regulator_cdev *rcdev);
+
+static struct regulator *get_regulator_load(struct device *dev)
+{
+ struct regulator *regulator = NULL;
+ struct regulator_cdev *rcdev;
+
+ list_for_each_entry(rcdev, _cdevs, list) {
+ list_for_each_entry(regulator, >consumer_list, list) {
+ if (regulator->dev == dev)
+ return regulator;
+ }
+ }
+ return NULL;
+}
+
+static int regulator_check_voltage(struct regulator_cdev *rcdev, int uV)
+{
+ if (!rcdev->constraints) {
+ printk(KERN_ERR "%s: no constraints for %s\n", __func__,
+ rcdev->desc->name);
+ return -ENODEV;
+ }
+ if (!rcdev->constraints->valid_ops_mask & REGULATOR_CHANGE_VOLTAGE) {
+ printk(KERN_ERR "%s: operation not allowed for %s\n",
+ __func__, rcdev->desc->name);
+ return -EPERM;
+ }
+ if (uV > rcdev->constraints->max_uV ||
+ uV < rcdev->constraints->min_uV) {
+ printk(KERN_ERR "%s: invalid voltage %duV for %s\n",
+ __func__, uV, rcdev->desc->name);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int regulator_check_current(struct regulator_cdev *rcdev, int uA)
+{
+ if (!rcdev->constraints) {
+ printk(KERN_ERR "%s: no constraints for %s\n", __func__,
+ rcdev->desc->name);
+ return -ENODEV;
+ }
+ if (!rcdev->constraints->valid_ops_mask & REGULATOR_CHANGE_CURRENT) {
+ printk(KERN_ERR "%s: operation not allowed for %s\n",
+ __func__, rcdev->desc->name);
+ return -EPERM;
+ }
+ if (uA > rcdev->constraints->max_uA ||
+ uA < rcdev->constraints->min_uA) {
+ printk(KERN_ERR "%s: invalid current %duA for %s\n",
+ __func__, uA, rcdev->desc->name);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int regulator_check_mode(struct regulator_cdev *rcdev, int mode)
+{
+ if (!rcdev->constraints) {
+ printk(KERN_ERR "%s: no constraints for %s\n", __func__,
+ rcdev->desc->name);
+ return -ENODEV;
+ }
+ if (!rcdev->constraints->valid_ops_mask & REGULATOR_CHANGE_MODE) {
+ printk(KERN
[PATCH 5/4] Voltage and current regulator framework
Oops, there is a 5/4 as I forgot this :- Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] Voltage and current regulator framework
Regulator client / consumer API :- diff --git a/include/linux/regulator/regulator.h b/include/linux/regulator/regulator.h new file mode 100644 index 000..c604a2a --- /dev/null +++ b/include/linux/regulator/regulator.h @@ -0,0 +1,363 @@ +/* + * regulator.h -- SoC Regulator support. + * + * Copyright (C) 2007, 2008 Wolfson Microelectronics PLC. + * + * Author: Liam Girdwood <[EMAIL PROTECTED]> + * + * 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. + * + * Regulator Client Interface. + * + * A Power Management Regulator framework for SoC based devices. + * Features:- + * o Voltage and current level control. + * o Operating mode control. + * o Regulator status. + * o sysfs entries for showing client devices and status + * + * EXPERIMENTAL FEATURES: + * Dynamic Regulator operating Mode Switching (DRMS) - allows regulators + * to use most efficient operating mode depending upon voltage and load and + * is transparent to client drivers. + * + * e.g. Devices x,y,z share regulator r. Device x and y draw 20mA each during + * IO and 1mA at idle. Device z draws 100mA when under load and 5mA when + * idling. Regulator r has > 90% efficieny in NORMAL mode at loads > 100mA + * but this drops rapidly to 60% when below 100mA. Regulator r has > 90% + * efficiency in IDLE mode at loads < 10mA. Thus regulator r will operate + * in normal mode for loads > 10mA and in IDLE mode for load <= 10mA. + * + * Dynamic Regulator Voltage Selection (DRVS). Selects the lowest voltage + * output (within system constraints) for a regulator shared between several + * devices. This allows all devices to operate within their voltage range and + * will dynamically change the voltage when devices disable() thier supply + * to the next best level (thus saving power). This is based on an idea + * by Amit Kucheria in an RFC to lakml. + * + * e.g. devices x,y,z share regulator r. device x and y can operate between + * 1800mV and 1900mV, whilst device z can only operate at 1900mV. Regulator + * r will output 1900mV when all devices are in use and 1800mV when devices + * x and y are in use and device z is disabled. + */ + + +#ifndef __LINUX_REGULATOR_H_ +#define __LINUX_REGULATOR_H_ + +/* + * Regulator operating modes. + * + * Regulators can run in a variety of different operating modes depending on + * output load. This allows further system power savings by selecting the + * best (and most efficient) regulator mode for a desired load. + * + * Most drivers will only care about NORMAL. The modes below are generic and + * will probably not match the naming convention of your regulator data sheet + * but should match the use cases in the datasheet. + * + * In order of power efficiency (least efficient at top). + * + * Mode Description + * FAST Regulator can handle fast changes in it's load. + * e.g. useful in CPU voltage & frequency scaling where + * load can quickly increase with CPU freqency increases. + * + * NORMAL Normal regulator power supply mode. Most drivers will + * use this mode. + * + * IDLE Regulator runs in a more efficient mode for light + * loads. Can be used for devices that have a low power + * requirement during periods of inactivity. This mode + * may be more noisy than NORMAL and may not be able + * to handle fast load switching. + * + * STANDBYRegulator runs in the most efficient mode for very + * light loads. Can be used by devices when they are + * in a sleep/standby state. This mode is likely to be + * the most noisy and may not be able to handle fast load + * switching. + * + * NOTE: Most regulators will only support a subset of these modes. Some + * will only just support NORMAL. + */ + +#define REGULATOR_MODE_FAST0x1 +#define REGULATOR_MODE_NORMAL 0x2 +#define REGULATOR_MODE_IDLE0x4 +#define REGULATOR_MODE_STANDBY 0x8 + +/* + * Regulator notifier events. + * + * @UNDER_VOLTAGE: Regulator output is under voltage. + * @OVER_CURRENT: Regulator output current is too high. + * @POWER_ON: Regulator power ON event. + * @POWER_OFF: Regulator power OFF event. + * @REGULATION_OUT: Regulator output is out of regulation. + * @FAIL: Regulator output has failed. + * @OVER_TEMP: Regulator over temp. + */ + +#define REGULATOR_EVENT_UNDER_VOLTAGE 0x1 +#define REGULATOR_EVENT_OVER_CURRENT 0x2 +#define REGULATOR_EVENT_POWER_ON 0x4 +#define REGULATOR_EVENT_POWER_OFF 0x8 +#define REGULATOR_EVENT_REGULATION_OUT 0x10 +#define REGULATOR_EVENT_FAIL 0x20 +#define REGULATOR_EVENT_OVER_TEMP
[PATCH 0/4] Voltage and current regulator framework
This patch series provides a generic framework to allow device drivers to control voltage and current regulators on SoC based devices (e.g. phones, gps, media players). The intention is to allow systems to dynamically control regulator output in order to save power and prolong battery life. This applies to both voltage regulators (where voltage output is controllable) and current sinks (where current output is controllable). The framework is designed around SoC based devices but may also be relevant to non SoC devices. It's also been designed against two Power Management ICs (PMICs) currently on the market - namely the Freescale MC13783 and the Wolfson WM8350. However it is quite generic and should apply to all PMICs. The framework provides several interfaces :- 1. Client or Consumer driver API. This uses a similar API to the kernel clock interface in that client or consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current, mode, enable and disable. This should allow clients complete control over their supply voltage and current. This API also compiles out if not in use so drivers can be reused in systems with no PMIC power control. 2. Regulator driver API. This allows regulator drivers to register their regulators and provide operations to the core. It also has a notifier call chain for propagating regulator events to clients. 3. Platform API. This API is for platform/device specific code and allows the creation of voltage/current domains (with constraints) for each regulator. It can provide regulator constraints that will prevent device damage through over voltage or over current caused by buggy client drivers. It also allows the creation of a regulator tree whereby some regulators are supplied by others (similar to a clock tree). 4. Userspace. The framework also exports a lot of useful voltage/current data to userspace via sysfs. This could be used to monitor device and regulator power and status. Fwiw, there is code in our public git tree that currently shows this API in use:- http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=shortlog;h=imx31 All the relevant files are under include/linux/regulator and drivers/regulator. There are client drivers here :- http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=arch/arm/mach-mx3/cpufreq.c;h=77f03d85fef6b29b0ca2e820d38d9ebb068e7bf7;hb=imx31 http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=drivers/leds/leds-wm8350.c;h=a81bbf9154b4de13c029aee0613294562a03f506;hb=imx31 http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=drivers/video/backlight/wm8350_bl.c;h=3eafb83683b7f242ec78ff620431307c25e23202;hb=imx31 http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=sound/soc/imx/imx32ads-wm8350.c;h=aae347ac556203fbdb64d71f4dc0be7df250767a;hb=imx31 Patch follows. Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] Voltage and current regulator framework
Regulator driver API :-
diff --git a/include/linux/regulator/regulator-drv.h
b/include/linux/regulator/regulator-drv.h
new file mode 100644
index 000..3c9b398
--- /dev/null
+++ b/include/linux/regulator/regulator-drv.h
@@ -0,0 +1,119 @@
+/*
+ * regulator-drv.h -- SoC Regulator support.
+ *
+ * Copyright (C) 2007, 2008 Wolfson Microelectronics PLC.
+ *
+ * Author: Liam Girdwood <[EMAIL PROTECTED]>
+ *
+ * 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.
+ *
+ * Regulator Driver Interface.
+ */
+
+
+#ifndef __LINUX_REGULATOR_DRV_H_
+#define __LINUX_REGULATOR_DRV_H_
+
+#include
+#include
+
+struct regulator_constraints;
+struct regulator_cdev;
+
+/**
+ * struct regulator_ops - regulator operations.
+ *
+ * This struct describes regulator operations.
+ */
+struct regulator_ops {
+
+ /* get/set regulator voltage */
+ int (*set_voltage)(struct regulator_cdev *, int uV);
+ int (*get_voltage)(struct regulator_cdev *);
+
+ /* get/set regulator current */
+ int (*set_current)(struct regulator_cdev *, int uA);
+ int (*get_current)(struct regulator_cdev *);
+
+ /* enable/disable regulator */
+ int (*enable)(struct regulator_cdev *);
+ int (*disable)(struct regulator_cdev *);
+ int (*is_enabled)(struct regulator_cdev *);
+
+ /* get/set regulator operating mode (defined in regulator.h) */
+ int (*set_mode)(struct regulator_cdev *, unsigned int mode);
+ unsigned int (*get_mode)(struct regulator_cdev *);
+
+ /* get most efficient regulator operating mode for load */
+ unsigned int (*get_optimum_mode)(struct regulator_cdev *, int input_uV,
+ int output_uV, int load_uA);
+};
+
+/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] Voltage and current regulator framework
Platform interface :-
diff --git a/include/linux/regulator/regulator-platform.h
b/include/linux/regulator/regulator-platform.h
new file mode 100644
index 000..5558630
--- /dev/null
+++ b/include/linux/regulator/regulator-platform.h
@@ -0,0 +1,104 @@
+/*
+ * regulator-platform.h -- SoC Regulator support, platform driver API.
+ *
+ * Copyright (C) 2007, 2008 Wolfson Microelectronics PLC.
+ *
+ * Author: Liam Girdwood <[EMAIL PROTECTED]>
+ *
+ * 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.
+ *
+ * Regulator Platform Interface.
+ */
+
+
+#ifndef __LINUX_REGULATOR_PLATFORM_H_
+#define __LINUX_REGULATOR_PLATFORM_H_
+
+#include
+
+struct regulator;
+
+/*
+ * Regulator operation constraint flags. These flags are used to enable
+ * certain regulator operations.
+ *
+ * @VOLTAGE: Regulator output voltage can be changed by software on this
+ *board/machine.
+ * @CURRENT: Regulator output current can be changed by software on this
+ *board machine.
+ * @MODE: Regulator operating mode can be changed by software on this
+ *board machine.
+ * @STATUS: Regulator can be enabled and disabled.
+ * @DRMS: Dynamic Regulator Mode Switching is enabled for this regulator.
+ */
+
+#define REGULATOR_CHANGE_VOLTAGE 0x1
+#define REGULATOR_CHANGE_CURRENT 0x2
+#define REGULATOR_CHANGE_MODE 0x4
+#define REGULATOR_CHANGE_STATUS0x8
+#define REGULATOR_CHANGE_DRMS 0x10
+
+/**
+ * struct regulation_constraints - regulator operating constraints.
+ *
+ * This struct describes regulator and board/machine specific constraints.
+ */
+struct regulation_constraints {
+
+ char *name;
+
+ /* voltage output range - for voltage control */
+ int min_uV;
+ int max_uV;
+
+ /* current output range - for current control */
+ int min_uA;
+ int max_uA;
+
+ /* valid regulator operating modes for this machine */
+ unsigned int valid_modes_mask;
+
+ /* valid operations for regulator on this machine */
+ unsigned int valid_ops_mask;
+
+ /* input voltage */
+ int input_uV;
+};
+
+/**
+ * regulator_set_platform_source - set regulator source regulator
+ * @regulator: regulator source
+ * @parent: source or parent regulator
+ *
+ * Called by platform initialisation code to set the source supply or "parent"
+ * regulator for this regulator. This ensures that a regulator source will
+ * also be enabled by the core if it's child is enabled.
+ */
+int regulator_set_platform_source(const char *regulator_source,
+ const char *regulator_parent);
+
+/**
+ * regulator_get_platform_source - get regulator source regulator
+ * @regulator: regulator source
+ *
+ * Returns the regulator supply regulator or NULL if no supply regulator
+ * exists (i.e the regulator is supplied directly from USB, Line, Battery, etc)
+ */
+const char *regulator_get_platform_source(const char *regulator_name);
+
+
+/**
+ * regulator_set_platform_constraints - sets regulator constraints
+ * @regulator: regulator source
+ *
+ * Allows platform initialisation code to define and constrain regulator
+ * circuits e.g. valid voltage/current ranges, etc.
+ * NOTE: Constraints *must* be set by platform code in order for some
+ * regulator operations to proceed i.e. set_voltage, set_current, set_mode.
+ */
+int regulator_set_platform_constraints(const char *regulator_name,
+ struct regulation_constraints *constraints);
+
+#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] Voltage and current regulator framework
Platform interface :-
diff --git a/include/linux/regulator/regulator-platform.h
b/include/linux/regulator/regulator-platform.h
new file mode 100644
index 000..5558630
--- /dev/null
+++ b/include/linux/regulator/regulator-platform.h
@@ -0,0 +1,104 @@
+/*
+ * regulator-platform.h -- SoC Regulator support, platform driver API.
+ *
+ * Copyright (C) 2007, 2008 Wolfson Microelectronics PLC.
+ *
+ * Author: Liam Girdwood [EMAIL PROTECTED]
+ *
+ * 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.
+ *
+ * Regulator Platform Interface.
+ */
+
+
+#ifndef __LINUX_REGULATOR_PLATFORM_H_
+#define __LINUX_REGULATOR_PLATFORM_H_
+
+#include linux/regulator/regulator.h
+
+struct regulator;
+
+/*
+ * Regulator operation constraint flags. These flags are used to enable
+ * certain regulator operations.
+ *
+ * @VOLTAGE: Regulator output voltage can be changed by software on this
+ *board/machine.
+ * @CURRENT: Regulator output current can be changed by software on this
+ *board machine.
+ * @MODE: Regulator operating mode can be changed by software on this
+ *board machine.
+ * @STATUS: Regulator can be enabled and disabled.
+ * @DRMS: Dynamic Regulator Mode Switching is enabled for this regulator.
+ */
+
+#define REGULATOR_CHANGE_VOLTAGE 0x1
+#define REGULATOR_CHANGE_CURRENT 0x2
+#define REGULATOR_CHANGE_MODE 0x4
+#define REGULATOR_CHANGE_STATUS0x8
+#define REGULATOR_CHANGE_DRMS 0x10
+
+/**
+ * struct regulation_constraints - regulator operating constraints.
+ *
+ * This struct describes regulator and board/machine specific constraints.
+ */
+struct regulation_constraints {
+
+ char *name;
+
+ /* voltage output range - for voltage control */
+ int min_uV;
+ int max_uV;
+
+ /* current output range - for current control */
+ int min_uA;
+ int max_uA;
+
+ /* valid regulator operating modes for this machine */
+ unsigned int valid_modes_mask;
+
+ /* valid operations for regulator on this machine */
+ unsigned int valid_ops_mask;
+
+ /* input voltage */
+ int input_uV;
+};
+
+/**
+ * regulator_set_platform_source - set regulator source regulator
+ * @regulator: regulator source
+ * @parent: source or parent regulator
+ *
+ * Called by platform initialisation code to set the source supply or parent
+ * regulator for this regulator. This ensures that a regulator source will
+ * also be enabled by the core if it's child is enabled.
+ */
+int regulator_set_platform_source(const char *regulator_source,
+ const char *regulator_parent);
+
+/**
+ * regulator_get_platform_source - get regulator source regulator
+ * @regulator: regulator source
+ *
+ * Returns the regulator supply regulator or NULL if no supply regulator
+ * exists (i.e the regulator is supplied directly from USB, Line, Battery, etc)
+ */
+const char *regulator_get_platform_source(const char *regulator_name);
+
+
+/**
+ * regulator_set_platform_constraints - sets regulator constraints
+ * @regulator: regulator source
+ *
+ * Allows platform initialisation code to define and constrain regulator
+ * circuits e.g. valid voltage/current ranges, etc.
+ * NOTE: Constraints *must* be set by platform code in order for some
+ * regulator operations to proceed i.e. set_voltage, set_current, set_mode.
+ */
+int regulator_set_platform_constraints(const char *regulator_name,
+ struct regulation_constraints *constraints);
+
+#endif
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] Voltage and current regulator framework
Regulator driver API :-
diff --git a/include/linux/regulator/regulator-drv.h
b/include/linux/regulator/regulator-drv.h
new file mode 100644
index 000..3c9b398
--- /dev/null
+++ b/include/linux/regulator/regulator-drv.h
@@ -0,0 +1,119 @@
+/*
+ * regulator-drv.h -- SoC Regulator support.
+ *
+ * Copyright (C) 2007, 2008 Wolfson Microelectronics PLC.
+ *
+ * Author: Liam Girdwood [EMAIL PROTECTED]
+ *
+ * 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.
+ *
+ * Regulator Driver Interface.
+ */
+
+
+#ifndef __LINUX_REGULATOR_DRV_H_
+#define __LINUX_REGULATOR_DRV_H_
+
+#include linux/device.h
+#include linux/regulator/regulator.h
+
+struct regulator_constraints;
+struct regulator_cdev;
+
+/**
+ * struct regulator_ops - regulator operations.
+ *
+ * This struct describes regulator operations.
+ */
+struct regulator_ops {
+
+ /* get/set regulator voltage */
+ int (*set_voltage)(struct regulator_cdev *, int uV);
+ int (*get_voltage)(struct regulator_cdev *);
+
+ /* get/set regulator current */
+ int (*set_current)(struct regulator_cdev *, int uA);
+ int (*get_current)(struct regulator_cdev *);
+
+ /* enable/disable regulator */
+ int (*enable)(struct regulator_cdev *);
+ int (*disable)(struct regulator_cdev *);
+ int (*is_enabled)(struct regulator_cdev *);
+
+ /* get/set regulator operating mode (defined in regulator.h) */
+ int (*set_mode)(struct regulator_cdev *, unsigned int mode);
+ unsigned int (*get_mode)(struct regulator_cdev *);
+
+ /* get most efficient regulator operating mode for load */
+ unsigned int (*get_optimum_mode)(struct regulator_cdev *, int input_uV,
+ int output_uV, int load_uA);
+};
+
+/*
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] Voltage and current regulator framework
This patch series provides a generic framework to allow device drivers to control voltage and current regulators on SoC based devices (e.g. phones, gps, media players). The intention is to allow systems to dynamically control regulator output in order to save power and prolong battery life. This applies to both voltage regulators (where voltage output is controllable) and current sinks (where current output is controllable). The framework is designed around SoC based devices but may also be relevant to non SoC devices. It's also been designed against two Power Management ICs (PMICs) currently on the market - namely the Freescale MC13783 and the Wolfson WM8350. However it is quite generic and should apply to all PMICs. The framework provides several interfaces :- 1. Client or Consumer driver API. This uses a similar API to the kernel clock interface in that client or consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current, mode, enable and disable. This should allow clients complete control over their supply voltage and current. This API also compiles out if not in use so drivers can be reused in systems with no PMIC power control. 2. Regulator driver API. This allows regulator drivers to register their regulators and provide operations to the core. It also has a notifier call chain for propagating regulator events to clients. 3. Platform API. This API is for platform/device specific code and allows the creation of voltage/current domains (with constraints) for each regulator. It can provide regulator constraints that will prevent device damage through over voltage or over current caused by buggy client drivers. It also allows the creation of a regulator tree whereby some regulators are supplied by others (similar to a clock tree). 4. Userspace. The framework also exports a lot of useful voltage/current data to userspace via sysfs. This could be used to monitor device and regulator power and status. Fwiw, there is code in our public git tree that currently shows this API in use:- http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=shortlog;h=imx31 All the relevant files are under include/linux/regulator and drivers/regulator. There are client drivers here :- http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=arch/arm/mach-mx3/cpufreq.c;h=77f03d85fef6b29b0ca2e820d38d9ebb068e7bf7;hb=imx31 http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=drivers/leds/leds-wm8350.c;h=a81bbf9154b4de13c029aee0613294562a03f506;hb=imx31 http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=drivers/video/backlight/wm8350_bl.c;h=3eafb83683b7f242ec78ff620431307c25e23202;hb=imx31 http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-audioplus.git;a=blob;f=sound/soc/imx/imx32ads-wm8350.c;h=aae347ac556203fbdb64d71f4dc0be7df250767a;hb=imx31 Patch follows. Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] Voltage and current regulator framework
Regulator client / consumer API :- diff --git a/include/linux/regulator/regulator.h b/include/linux/regulator/regulator.h new file mode 100644 index 000..c604a2a --- /dev/null +++ b/include/linux/regulator/regulator.h @@ -0,0 +1,363 @@ +/* + * regulator.h -- SoC Regulator support. + * + * Copyright (C) 2007, 2008 Wolfson Microelectronics PLC. + * + * Author: Liam Girdwood [EMAIL PROTECTED] + * + * 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. + * + * Regulator Client Interface. + * + * A Power Management Regulator framework for SoC based devices. + * Features:- + * o Voltage and current level control. + * o Operating mode control. + * o Regulator status. + * o sysfs entries for showing client devices and status + * + * EXPERIMENTAL FEATURES: + * Dynamic Regulator operating Mode Switching (DRMS) - allows regulators + * to use most efficient operating mode depending upon voltage and load and + * is transparent to client drivers. + * + * e.g. Devices x,y,z share regulator r. Device x and y draw 20mA each during + * IO and 1mA at idle. Device z draws 100mA when under load and 5mA when + * idling. Regulator r has 90% efficieny in NORMAL mode at loads 100mA + * but this drops rapidly to 60% when below 100mA. Regulator r has 90% + * efficiency in IDLE mode at loads 10mA. Thus regulator r will operate + * in normal mode for loads 10mA and in IDLE mode for load = 10mA. + * + * Dynamic Regulator Voltage Selection (DRVS). Selects the lowest voltage + * output (within system constraints) for a regulator shared between several + * devices. This allows all devices to operate within their voltage range and + * will dynamically change the voltage when devices disable() thier supply + * to the next best level (thus saving power). This is based on an idea + * by Amit Kucheria in an RFC to lakml. + * + * e.g. devices x,y,z share regulator r. device x and y can operate between + * 1800mV and 1900mV, whilst device z can only operate at 1900mV. Regulator + * r will output 1900mV when all devices are in use and 1800mV when devices + * x and y are in use and device z is disabled. + */ + + +#ifndef __LINUX_REGULATOR_H_ +#define __LINUX_REGULATOR_H_ + +/* + * Regulator operating modes. + * + * Regulators can run in a variety of different operating modes depending on + * output load. This allows further system power savings by selecting the + * best (and most efficient) regulator mode for a desired load. + * + * Most drivers will only care about NORMAL. The modes below are generic and + * will probably not match the naming convention of your regulator data sheet + * but should match the use cases in the datasheet. + * + * In order of power efficiency (least efficient at top). + * + * Mode Description + * FAST Regulator can handle fast changes in it's load. + * e.g. useful in CPU voltage frequency scaling where + * load can quickly increase with CPU freqency increases. + * + * NORMAL Normal regulator power supply mode. Most drivers will + * use this mode. + * + * IDLE Regulator runs in a more efficient mode for light + * loads. Can be used for devices that have a low power + * requirement during periods of inactivity. This mode + * may be more noisy than NORMAL and may not be able + * to handle fast load switching. + * + * STANDBYRegulator runs in the most efficient mode for very + * light loads. Can be used by devices when they are + * in a sleep/standby state. This mode is likely to be + * the most noisy and may not be able to handle fast load + * switching. + * + * NOTE: Most regulators will only support a subset of these modes. Some + * will only just support NORMAL. + */ + +#define REGULATOR_MODE_FAST0x1 +#define REGULATOR_MODE_NORMAL 0x2 +#define REGULATOR_MODE_IDLE0x4 +#define REGULATOR_MODE_STANDBY 0x8 + +/* + * Regulator notifier events. + * + * @UNDER_VOLTAGE: Regulator output is under voltage. + * @OVER_CURRENT: Regulator output current is too high. + * @POWER_ON: Regulator power ON event. + * @POWER_OFF: Regulator power OFF event. + * @REGULATION_OUT: Regulator output is out of regulation. + * @FAIL: Regulator output has failed. + * @OVER_TEMP: Regulator over temp. + */ + +#define REGULATOR_EVENT_UNDER_VOLTAGE 0x1 +#define REGULATOR_EVENT_OVER_CURRENT 0x2 +#define REGULATOR_EVENT_POWER_ON 0x4 +#define REGULATOR_EVENT_POWER_OFF 0x8 +#define REGULATOR_EVENT_REGULATION_OUT 0x10 +#define REGULATOR_EVENT_FAIL 0x20 +#define REGULATOR_EVENT_OVER_TEMP 0x40 + +/* + * Convenience conversion
[PATCH 5/4] Voltage and current regulator framework
Oops, there is a 5/4 as I forgot this :- Signed-off-by: Liam Girdwood [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] Voltage and current regulator framework
Regulator framework core :-
diff --git a/drivers/regulator/reg-core.c b/drivers/regulator/reg-core.c
new file mode 100644
index 000..1434697
--- /dev/null
+++ b/drivers/regulator/reg-core.c
@@ -0,0 +1,1036 @@
+/*
+ * regulator.c -- Voltage/Current Regulator framework.
+ *
+ * Copyright 2007 Wolfson Microelectronics PLC.
+ *
+ * Author: Liam Girdwood [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/device.h
+#include linux/err.h
+#include linux/mutex.h
+#include linux/regulator/regulator.h
+#include linux/regulator/regulator-drv.h
+#include linux/regulator/regulator-platform.h
+
+#define REGULATOR_VERSION 0.2
+
+/* We need to undef the current macro (from include/asm/current.h) otherwise
+ * our current sysfs entry becomes (get_current()).
+ */
+#undef current
+
+static DEFINE_MUTEX(list_mutex);
+static LIST_HEAD(regulator_cdevs);
+
+/**
+ * struct regulator_cdev
+ *
+ * Voltage / Current regulator class device. One for each regulator.
+ */
+struct regulator_cdev {
+ struct regulator_desc *desc;
+ int use_count;
+
+ struct list_head list;
+ struct list_head consumer_list;
+ struct blocking_notifier_head notifier;
+ struct mutex mutex;
+ struct module *owner;
+ struct class_device cdev;
+ struct regulation_constraints *constraints;
+ struct regulator_cdev *parent; /* for tree */
+
+ void *reg_data; /* regulator_cdev data */
+ void *vendor; /* regulator_cdev vendor extensions */
+};
+#define to_rcdev(cd) \
+ container_of(cd, struct regulator_cdev, cdev)
+
+/*
+ * struct regulator
+ *
+ * One for each consumer device.
+ */
+struct regulator {
+ struct device *dev;
+ struct list_head list;
+ int uA_load;
+ int uV_required;
+ int enabled;
+ struct device_attribute dev_attr;
+ struct regulator_cdev *rcdev;
+};
+
+static int _regulator_is_enabled(struct regulator_cdev *rcdev);
+static int _regulator_disable(struct regulator_cdev *rcdev);
+static int _regulator_get_voltage(struct regulator_cdev *rcdev);
+static int _regulator_get_current(struct regulator_cdev *rcdev);
+static unsigned int _regulator_get_mode(struct regulator_cdev *rcdev);
+
+static struct regulator *get_regulator_load(struct device *dev)
+{
+ struct regulator *regulator = NULL;
+ struct regulator_cdev *rcdev;
+
+ list_for_each_entry(rcdev, regulator_cdevs, list) {
+ list_for_each_entry(regulator, rcdev-consumer_list, list) {
+ if (regulator-dev == dev)
+ return regulator;
+ }
+ }
+ return NULL;
+}
+
+static int regulator_check_voltage(struct regulator_cdev *rcdev, int uV)
+{
+ if (!rcdev-constraints) {
+ printk(KERN_ERR %s: no constraints for %s\n, __func__,
+ rcdev-desc-name);
+ return -ENODEV;
+ }
+ if (!rcdev-constraints-valid_ops_mask REGULATOR_CHANGE_VOLTAGE) {
+ printk(KERN_ERR %s: operation not allowed for %s\n,
+ __func__, rcdev-desc-name);
+ return -EPERM;
+ }
+ if (uV rcdev-constraints-max_uV ||
+ uV rcdev-constraints-min_uV) {
+ printk(KERN_ERR %s: invalid voltage %duV for %s\n,
+ __func__, uV, rcdev-desc-name);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int regulator_check_current(struct regulator_cdev *rcdev, int uA)
+{
+ if (!rcdev-constraints) {
+ printk(KERN_ERR %s: no constraints for %s\n, __func__,
+ rcdev-desc-name);
+ return -ENODEV;
+ }
+ if (!rcdev-constraints-valid_ops_mask REGULATOR_CHANGE_CURRENT) {
+ printk(KERN_ERR %s: operation not allowed for %s\n,
+ __func__, rcdev-desc-name);
+ return -EPERM;
+ }
+ if (uA rcdev-constraints-max_uA ||
+ uA rcdev-constraints-min_uA) {
+ printk(KERN_ERR %s: invalid current %duA for %s\n,
+ __func__, uA, rcdev-desc-name);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int regulator_check_mode(struct regulator_cdev *rcdev, int mode)
+{
+ if (!rcdev-constraints) {
+ printk(KERN_ERR %s: no constraints for %s\n, __func__,
+ rcdev-desc-name);
+ return -ENODEV;
+ }
+ if (!rcdev-constraints-valid_ops_mask REGULATOR_CHANGE_MODE) {
+ printk(KERN_ERR %s: operation not allowed for %s\n,
+ __func__, rcdev-desc-name);
+ return
Re: TR: codec audio Cirrus CS42L51 - Audio capture problems
On Wed, 2007-10-10 at 10:20 +0200, Pierre Savary wrote:
>
> I am currently writing a driver for the CS42L51 audio codec to work with
> at91sam9260, using I2C and I2S. I used the couple of files {
> /sound/soc/at91/eti_b1_wm8731.c , /sound/soc/codecs/wm8731.c } as a model.
> I succeeded in playing sounds using the codec (WAV or MP3), via /dev/dsp.
>
> Unfortunately, I encounter problems implementing the opposite, i.e.
> recording sounds. For example, when I launch the command "cat /dev/dsp >
> foo.wav", or the command "wavrec foo.wav", I get "read error: Input/output
> error".
>
> I have observed the clock signals and the RD signal (data sent from the
> codec), and when I launch the command, these signals seem correct (data is
> provided by the codec on RD pin and all signals are correctly synchronized
> together).
>
> I didn't modify the driver dedicated to the configuration of at91sam9260
> registers (at91-i2s.c) and it seems to me it should work in both ways
> (playback and record). I notably checked that the RFMR and RCMR registers of
> at91sam9260 were well configured.
>
> Do someone has an idea on where the error could come from ? I must precise
> that, as I don't work with a kernel debugger, I didn't localize where the
> error occurs.
>
Can you try "arecord -f cd -Dhw:0,0 > file.wav" as this will rule out
any OSS emulation or PCM plugin issues (this command will read directly
from your hardware).
Fwiw, this error is usually seen in capture when the upper alsa layers
don't receive any data from your hardware. This could mean your DMA or
your I2S port is not configured correctly.
Liam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: TR: codec audio Cirrus CS42L51 - Audio capture problems
On Wed, 2007-10-10 at 10:20 +0200, Pierre Savary wrote:
I am currently writing a driver for the CS42L51 audio codec to work with
at91sam9260, using I2C and I2S. I used the couple of files {
/sound/soc/at91/eti_b1_wm8731.c , /sound/soc/codecs/wm8731.c } as a model.
I succeeded in playing sounds using the codec (WAV or MP3), via /dev/dsp.
Unfortunately, I encounter problems implementing the opposite, i.e.
recording sounds. For example, when I launch the command cat /dev/dsp
foo.wav, or the command wavrec foo.wav, I get read error: Input/output
error.
I have observed the clock signals and the RD signal (data sent from the
codec), and when I launch the command, these signals seem correct (data is
provided by the codec on RD pin and all signals are correctly synchronized
together).
I didn't modify the driver dedicated to the configuration of at91sam9260
registers (at91-i2s.c) and it seems to me it should work in both ways
(playback and record). I notably checked that the RFMR and RCMR registers of
at91sam9260 were well configured.
Do someone has an idea on where the error could come from ? I must precise
that, as I don't work with a kernel debugger, I didn't localize where the
error occurs.
Can you try arecord -f cd -Dhw:0,0 file.wav as this will rule out
any OSS emulation or PCM plugin issues (this command will read directly
from your hardware).
Fwiw, this error is usually seen in capture when the upper alsa layers
don't receive any data from your hardware. This could mean your DMA or
your I2S port is not configured correctly.
Liam
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [RFC][PATCH] Get rid of dead code in sound/pci/ac97/ac97_patch.c
I'd prefer we keep this code in atm. The WM97xx touch driver needs it to eliminate any audio noise from the touchscreen ADC. I'll post the remaining touch driver patches in time for the next merge window. Liam On Tue, 2007-07-31 at 22:36 +0200, Michal Piotrowski wrote: > Hi, > > File /home/devel/linux-rdc/sound/pci/ac97/ac97_patch.c line 484 > Unknown CONFIG option! CONFIG_TOUCHSCREEN_WM9705 > > Regards, > Michal > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [RFC][PATCH] Get rid of dead code in sound/pci/ac97/ac97_patch.c
I'd prefer we keep this code in atm. The WM97xx touch driver needs it to eliminate any audio noise from the touchscreen ADC. I'll post the remaining touch driver patches in time for the next merge window. Liam On Tue, 2007-07-31 at 22:36 +0200, Michal Piotrowski wrote: Hi, File /home/devel/linux-rdc/sound/pci/ac97/ac97_patch.c line 484 Unknown CONFIG option! CONFIG_TOUCHSCREEN_WM9705 Regards, Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] Mic and Line In Capture AC97 slots issue
On Thu, 2007-05-10 at 02:45 +0530, Nobin Mathew wrote: > http://mailman.alsa-project.org/pipermail/alsa-devel/2007-May/000835.html > http://mailman.alsa-project.org/pipermail/alsa-devel/2007-May/000837.html > > the overrun issue was because my application was not fast enough. > > I resolved that problem by disabling capture of AC-Link slot4 in my > ac97 controller. > So capture happens only in slot3. > > According to ac97 spec Mic comes in Slot6 of AC-Link. > > I am using wolfson wm9713 codec. > > In this LineR and LineL are routed to LeftADC and RightADC. > > And Mic1 (Mic A) is also coonected to LeftADC and RightADC. > > > So i am assuming that Mic 1 will come in Slot3 and Slot4. > > But my application is taking only mono data, so XRUN will happen. > > > What is the correct configuration for this? > What should be the configuration if i want to capture both Line IN and Mic? > means AC-Link settings > At least 2 AC97 slots must be active in order to capture 2 separate channels (i.e. Mic1 and Line II). Hence, you will need to enable slots 3 & 4 for _stereo_ audio capture. Mono capture (1 AC97 slot) of Mic1, Line R & L can be accomplished on the WM9713 by mixing all the required signals into the Mono mixer and capturing the mixer output with either the left ADC (slot 3) or the right ADC (slot 4). The easiest way to set this up is to look at the audio diagram on page 13 of the datasheet and run alsamixer to change the mixers. alsactl can then be used to store your mixer settings. Liam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] Mic and Line In Capture AC97 slots issue
On Thu, 2007-05-10 at 02:45 +0530, Nobin Mathew wrote: http://mailman.alsa-project.org/pipermail/alsa-devel/2007-May/000835.html http://mailman.alsa-project.org/pipermail/alsa-devel/2007-May/000837.html the overrun issue was because my application was not fast enough. I resolved that problem by disabling capture of AC-Link slot4 in my ac97 controller. So capture happens only in slot3. According to ac97 spec Mic comes in Slot6 of AC-Link. I am using wolfson wm9713 codec. In this LineR and LineL are routed to LeftADC and RightADC. And Mic1 (Mic A) is also coonected to LeftADC and RightADC. So i am assuming that Mic 1 will come in Slot3 and Slot4. But my application is taking only mono data, so XRUN will happen. What is the correct configuration for this? What should be the configuration if i want to capture both Line IN and Mic? means AC-Link settings At least 2 AC97 slots must be active in order to capture 2 separate channels (i.e. Mic1 and Line II). Hence, you will need to enable slots 3 4 for _stereo_ audio capture. Mono capture (1 AC97 slot) of Mic1, Line R L can be accomplished on the WM9713 by mixing all the required signals into the Mono mixer and capturing the mixer output with either the left ADC (slot 3) or the right ADC (slot 4). The easiest way to set this up is to look at the audio diagram on page 13 of the datasheet and run alsamixer to change the mixers. alsactl can then be used to store your mixer settings. Liam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [ASoC] Mic record is not working with wm9713 ASoC driver
It's probably best to keep this thread on alsa-dev otherwise things start to get confusing when cross posting occurs. Liam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ASoC] Mic record is not working with wm9713 ASoC driver
On Wed, 2007-05-09 at 14:48 +0530, Nobin Mathew wrote: > I am trying to record mic with AsoC wm9713 driver. My Mic is connected "Mic > 1". I've replied to this duplicate post on alsa-dev. Liam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ASoC] Mic record is not working with wm9713 ASoC driver
On Wed, 2007-05-09 at 14:48 +0530, Nobin Mathew wrote: I am trying to record mic with AsoC wm9713 driver. My Mic is connected Mic 1. I've replied to this duplicate post on alsa-dev. Liam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [ASoC] Mic record is not working with wm9713 ASoC driver
It's probably best to keep this thread on alsa-dev otherwise things start to get confusing when cross posting occurs. Liam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OSS Support for AC97 low power codecs
Andrew,
Looks like I missed a critical diff line in the patch :-
--- a/include/linux/ac97_codec.h 2005-01-22 01:46:59.0 +
and added some PM stuff that is from a future patch.
Correct patch is attached.
Liam
On Wed, 2005-01-26 at 13:42, Liam Girdwood wrote:
> Hi Andrew,
>
> This is a resend of a patch that has been applied to 2.4. The low power
> codec functionality has also now been included in ALSA.
>
> I've attached a patch against 2.6.11-rc2 that checks the codec ID before
> doing an AC97 register reset. This allows the kernel to support low
> power codecs that are powered down by a reset command. This patch also
> fixes some other minor issues.
>
> Changes:-
>
> o Added AC97_DEFAULT_POWER_OFF to ac97_codec_ids[]
> o ac97_probe now checks hardwired codec ID's before sending a reset
> o Added support for WM9713
> o Moved the codec specific inits after the mixer setup as some init
> settings were being clobbered.
> o Added extra check so that default_digital_ops doesn't overwrite a
> valid codec_ops. (SPDIF)
>
> Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]>
>
> Liam
diff -ur a/sound/oss/ac97_codec.c b/sound/oss/ac97_codec.c
--- a/sound/oss/ac97_codec.c 2005-01-22 01:47:15.0 +
+++ b/sound/oss/ac97_codec.c 2005-01-26 13:22:23.0 +
@@ -71,6 +71,7 @@
static int wolfson_init04(struct ac97_codec * codec);
static int wolfson_init05(struct ac97_codec * codec);
static int wolfson_init11(struct ac97_codec * codec);
+static int wolfson_init13(struct ac97_codec * codec);
static int tritech_init(struct ac97_codec * codec);
static int tritech_maestro_init(struct ac97_codec * codec);
static int sigmatel_9708_init(struct ac97_codec *codec);
@@ -107,6 +108,7 @@
static struct ac97_ops wolfson_ops04 = { wolfson_init04, NULL, NULL };
static struct ac97_ops wolfson_ops05 = { wolfson_init05, NULL, NULL };
static struct ac97_ops wolfson_ops11 = { wolfson_init11, NULL, NULL };
+static struct ac97_ops wolfson_ops13 = { wolfson_init13, NULL, NULL };
static struct ac97_ops tritech_ops = { tritech_init, NULL, NULL };
static struct ac97_ops tritech_m_ops = { tritech_maestro_init, NULL, NULL };
static struct ac97_ops sigmatel_9708_ops = { sigmatel_9708_init, NULL, NULL };
@@ -171,6 +173,7 @@
{0x574D4C05, "Wolfson WM9705/WM9710", _ops05},
{0x574D4C09, "Wolfson WM9709", _ops},
{0x574D4C12, "Wolfson WM9711/9712", _ops11},
+ {0x574D4C13, "Wolfson WM9713", _ops13, AC97_DEFAULT_POWER_OFF},
{0x83847600, "SigmaTel STAC", _ops},
{0x83847604, "SigmaTel STAC9701/3/4/5", _ops},
{0x83847605, "SigmaTel STAC9704", _ops},
@@ -797,6 +800,9 @@
* Currently codec_wait is used to wait for AC97 codec
* reset to complete.
*
+ * Some codecs will power down when a register reset is
+ * performed. We now check for such codecs.
+ *
* Returns 1 (true) on success, or 0 (false) on failure.
*/
@@ -810,34 +816,17 @@
struct list_head *l;
struct ac97_driver *d;
- /* probing AC97 codec, AC97 2.0 says that bit 15 of register 0x00 (reset) should
- * be read zero.
- *
- * FIXME: is the following comment outdated? -jgarzik
- * Probing of AC97 in this way is not reliable, it is not even SAFE !!
- */
- codec->codec_write(codec, AC97_RESET, 0L);
-
- /* also according to spec, we wait for codec-ready state */
+ /* wait for codec-ready state */
if (codec->codec_wait)
codec->codec_wait(codec);
else
udelay(10);
-
- if ((audio = codec->codec_read(codec, AC97_RESET)) & 0x8000) {
- printk(KERN_ERR "ac97_codec: %s ac97 codec not present\n",
- (codec->id & 0x2) ? (codec->id&1 ? "4th" : "Tertiary")
- : (codec->id&1 ? "Secondary": "Primary"));
- return 0;
- }
-
- /* probe for Modem Codec */
- codec->modem = ac97_check_modem(codec);
- codec->name = NULL;
- codec->codec_ops = _ops;
-
+
+ /* will the codec power down if register reset ? */
id1 = codec->codec_read(codec, AC97_VENDOR_ID1);
id2 = codec->codec_read(codec, AC97_VENDOR_ID2);
+ codec->name = NULL;
+ codec->codec_ops = _ops;
for (i = 0; i < ARRAY_SIZE(ac97_codec_ids); i++) {
if (ac97_codec_ids[i].id == ((id1 << 16) | id2)) {
codec->type = ac97_codec_ids[i].id;
@@ -849,9 +838,34 @@
}
codec->model = (id1 << 16) | id2;
+ if ((codec->flags & AC97_DEFAULT_POWER_OFF) == 0) {
+ /* reset codec and wait for the ready bit before we continue */
+ codec->codec_write(codec, AC97_RESET, 0L);
+ if (codec->codec_wait)
+ codec->codec_wait(codec);
+ else
+ udelay(10);
+ }
+ /* probing AC97 codec, AC97 2.0 says that bit 15 of register 0x00 (reset) should
+ * be read zero.
+ *
+ * FIXME: is the following comment outdated? -jgarzik
+ * Probing of AC97 in this way is not relia
[PATCH] OSS Support for AC97 low power codecs
Hi Andrew,
This is a resend of a patch that has been applied to 2.4. The low power
codec functionality has also now been included in ALSA.
I've attached a patch against 2.6.11-rc2 that checks the codec ID before
doing an AC97 register reset. This allows the kernel to support low
power codecs that are powered down by a reset command. This patch also
fixes some other minor issues.
Changes:-
o Added AC97_DEFAULT_POWER_OFF to ac97_codec_ids[]
o ac97_probe now checks hardwired codec ID's before sending a reset
o Added support for WM9713
o Moved the codec specific inits after the mixer setup as some init
settings were being clobbered.
o Added extra check so that default_digital_ops doesn't overwrite a
valid codec_ops. (SPDIF)
Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]>
Liam
diff -ur a/sound/oss/ac97_codec.c b/sound/oss/ac97_codec.c
--- a/sound/oss/ac97_codec.c 2005-01-22 01:47:15.0 +
+++ b/sound/oss/ac97_codec.c 2005-01-26 13:22:23.0 +
@@ -71,6 +71,7 @@
static int wolfson_init04(struct ac97_codec * codec);
static int wolfson_init05(struct ac97_codec * codec);
static int wolfson_init11(struct ac97_codec * codec);
+static int wolfson_init13(struct ac97_codec * codec);
static int tritech_init(struct ac97_codec * codec);
static int tritech_maestro_init(struct ac97_codec * codec);
static int sigmatel_9708_init(struct ac97_codec *codec);
@@ -107,6 +108,7 @@
static struct ac97_ops wolfson_ops04 = { wolfson_init04, NULL, NULL };
static struct ac97_ops wolfson_ops05 = { wolfson_init05, NULL, NULL };
static struct ac97_ops wolfson_ops11 = { wolfson_init11, NULL, NULL };
+static struct ac97_ops wolfson_ops13 = { wolfson_init13, NULL, NULL };
static struct ac97_ops tritech_ops = { tritech_init, NULL, NULL };
static struct ac97_ops tritech_m_ops = { tritech_maestro_init, NULL, NULL };
static struct ac97_ops sigmatel_9708_ops = { sigmatel_9708_init, NULL, NULL };
@@ -171,6 +173,7 @@
{0x574D4C05, "Wolfson WM9705/WM9710", _ops05},
{0x574D4C09, "Wolfson WM9709", _ops},
{0x574D4C12, "Wolfson WM9711/9712", _ops11},
+ {0x574D4C13, "Wolfson WM9713", _ops13, AC97_DEFAULT_POWER_OFF},
{0x83847600, "SigmaTel STAC", _ops},
{0x83847604, "SigmaTel STAC9701/3/4/5", _ops},
{0x83847605, "SigmaTel STAC9704", _ops},
@@ -797,6 +800,9 @@
* Currently codec_wait is used to wait for AC97 codec
* reset to complete.
*
+ * Some codecs will power down when a register reset is
+ * performed. We now check for such codecs.
+ *
* Returns 1 (true) on success, or 0 (false) on failure.
*/
@@ -810,34 +816,17 @@
struct list_head *l;
struct ac97_driver *d;
- /* probing AC97 codec, AC97 2.0 says that bit 15 of register 0x00 (reset) should
- * be read zero.
- *
- * FIXME: is the following comment outdated? -jgarzik
- * Probing of AC97 in this way is not reliable, it is not even SAFE !!
- */
- codec->codec_write(codec, AC97_RESET, 0L);
-
- /* also according to spec, we wait for codec-ready state */
+ /* wait for codec-ready state */
if (codec->codec_wait)
codec->codec_wait(codec);
else
udelay(10);
-
- if ((audio = codec->codec_read(codec, AC97_RESET)) & 0x8000) {
- printk(KERN_ERR "ac97_codec: %s ac97 codec not present\n",
- (codec->id & 0x2) ? (codec->id&1 ? "4th" : "Tertiary")
- : (codec->id&1 ? "Secondary": "Primary"));
- return 0;
- }
-
- /* probe for Modem Codec */
- codec->modem = ac97_check_modem(codec);
- codec->name = NULL;
- codec->codec_ops = _ops;
-
+
+ /* will the codec power down if register reset ? */
id1 = codec->codec_read(codec, AC97_VENDOR_ID1);
id2 = codec->codec_read(codec, AC97_VENDOR_ID2);
+ codec->name = NULL;
+ codec->codec_ops = _ops;
for (i = 0; i < ARRAY_SIZE(ac97_codec_ids); i++) {
if (ac97_codec_ids[i].id == ((id1 << 16) | id2)) {
codec->type = ac97_codec_ids[i].id;
@@ -849,9 +838,34 @@
}
codec->model = (id1 << 16) | id2;
+ if ((codec->flags & AC97_DEFAULT_POWER_OFF) == 0) {
+ /* reset codec and wait for the ready bit before we continue */
+ codec->codec_write(codec, AC97_RESET, 0L);
+ if (codec->codec_wait)
+ codec->codec_wait(codec);
+ else
+ udelay(10);
+ }
+ /* probing AC97 codec, AC97 2.0 says that bit 15 of register 0x00 (reset) should
+ * be read zero.
+ *
+ * FIXME: is the following comment outdated? -jgarzik
+ * Probing of AC97 in this way is not reliable, it is not even SAFE !!
+ */
+ if ((audio = codec->codec_read(codec, AC97_RESET)) & 0x8000) {
+ printk(KERN_ERR "ac97_codec: %s ac97 codec not present\n",
+ (codec->id & 0x2) ? (codec->id&1 ? "4th" : "Tertiary")
+ : (codec->id&1 ? "Secondary": "Primary"));
+ return 0;
+ }
+
+ /* pr
[PATCH] OSS Support for AC97 low power codecs
Hi Andrew,
This is a resend of a patch that has been applied to 2.4. The low power
codec functionality has also now been included in ALSA.
I've attached a patch against 2.6.11-rc2 that checks the codec ID before
doing an AC97 register reset. This allows the kernel to support low
power codecs that are powered down by a reset command. This patch also
fixes some other minor issues.
Changes:-
o Added AC97_DEFAULT_POWER_OFF to ac97_codec_ids[]
o ac97_probe now checks hardwired codec ID's before sending a reset
o Added support for WM9713
o Moved the codec specific inits after the mixer setup as some init
settings were being clobbered.
o Added extra check so that default_digital_ops doesn't overwrite a
valid codec_ops. (SPDIF)
Signed-off-by: Liam Girdwood [EMAIL PROTECTED]
Liam
diff -ur a/sound/oss/ac97_codec.c b/sound/oss/ac97_codec.c
--- a/sound/oss/ac97_codec.c 2005-01-22 01:47:15.0 +
+++ b/sound/oss/ac97_codec.c 2005-01-26 13:22:23.0 +
@@ -71,6 +71,7 @@
static int wolfson_init04(struct ac97_codec * codec);
static int wolfson_init05(struct ac97_codec * codec);
static int wolfson_init11(struct ac97_codec * codec);
+static int wolfson_init13(struct ac97_codec * codec);
static int tritech_init(struct ac97_codec * codec);
static int tritech_maestro_init(struct ac97_codec * codec);
static int sigmatel_9708_init(struct ac97_codec *codec);
@@ -107,6 +108,7 @@
static struct ac97_ops wolfson_ops04 = { wolfson_init04, NULL, NULL };
static struct ac97_ops wolfson_ops05 = { wolfson_init05, NULL, NULL };
static struct ac97_ops wolfson_ops11 = { wolfson_init11, NULL, NULL };
+static struct ac97_ops wolfson_ops13 = { wolfson_init13, NULL, NULL };
static struct ac97_ops tritech_ops = { tritech_init, NULL, NULL };
static struct ac97_ops tritech_m_ops = { tritech_maestro_init, NULL, NULL };
static struct ac97_ops sigmatel_9708_ops = { sigmatel_9708_init, NULL, NULL };
@@ -171,6 +173,7 @@
{0x574D4C05, Wolfson WM9705/WM9710, wolfson_ops05},
{0x574D4C09, Wolfson WM9709, null_ops},
{0x574D4C12, Wolfson WM9711/9712, wolfson_ops11},
+ {0x574D4C13, Wolfson WM9713, wolfson_ops13, AC97_DEFAULT_POWER_OFF},
{0x83847600, SigmaTel STAC, null_ops},
{0x83847604, SigmaTel STAC9701/3/4/5, null_ops},
{0x83847605, SigmaTel STAC9704, null_ops},
@@ -797,6 +800,9 @@
* Currently codec_wait is used to wait for AC97 codec
* reset to complete.
*
+ * Some codecs will power down when a register reset is
+ * performed. We now check for such codecs.
+ *
* Returns 1 (true) on success, or 0 (false) on failure.
*/
@@ -810,34 +816,17 @@
struct list_head *l;
struct ac97_driver *d;
- /* probing AC97 codec, AC97 2.0 says that bit 15 of register 0x00 (reset) should
- * be read zero.
- *
- * FIXME: is the following comment outdated? -jgarzik
- * Probing of AC97 in this way is not reliable, it is not even SAFE !!
- */
- codec-codec_write(codec, AC97_RESET, 0L);
-
- /* also according to spec, we wait for codec-ready state */
+ /* wait for codec-ready state */
if (codec-codec_wait)
codec-codec_wait(codec);
else
udelay(10);
-
- if ((audio = codec-codec_read(codec, AC97_RESET)) 0x8000) {
- printk(KERN_ERR ac97_codec: %s ac97 codec not present\n,
- (codec-id 0x2) ? (codec-id1 ? 4th : Tertiary)
- : (codec-id1 ? Secondary: Primary));
- return 0;
- }
-
- /* probe for Modem Codec */
- codec-modem = ac97_check_modem(codec);
- codec-name = NULL;
- codec-codec_ops = default_ops;
-
+
+ /* will the codec power down if register reset ? */
id1 = codec-codec_read(codec, AC97_VENDOR_ID1);
id2 = codec-codec_read(codec, AC97_VENDOR_ID2);
+ codec-name = NULL;
+ codec-codec_ops = null_ops;
for (i = 0; i ARRAY_SIZE(ac97_codec_ids); i++) {
if (ac97_codec_ids[i].id == ((id1 16) | id2)) {
codec-type = ac97_codec_ids[i].id;
@@ -849,9 +838,34 @@
}
codec-model = (id1 16) | id2;
+ if ((codec-flags AC97_DEFAULT_POWER_OFF) == 0) {
+ /* reset codec and wait for the ready bit before we continue */
+ codec-codec_write(codec, AC97_RESET, 0L);
+ if (codec-codec_wait)
+ codec-codec_wait(codec);
+ else
+ udelay(10);
+ }
+ /* probing AC97 codec, AC97 2.0 says that bit 15 of register 0x00 (reset) should
+ * be read zero.
+ *
+ * FIXME: is the following comment outdated? -jgarzik
+ * Probing of AC97 in this way is not reliable, it is not even SAFE !!
+ */
+ if ((audio = codec-codec_read(codec, AC97_RESET)) 0x8000) {
+ printk(KERN_ERR ac97_codec: %s ac97 codec not present\n,
+ (codec-id 0x2) ? (codec-id1 ? 4th : Tertiary)
+ : (codec-id1 ? Secondary: Primary));
+ return 0;
+ }
+
+ /* probe for Modem Codec */
+ codec-modem = ac97_check_modem(codec);
+
+ /* enable SPDIF */
f = codec-codec_read(codec, AC97_EXTENDED_STATUS);
- if(f 4)
+ if((codec-codec_ops == null_ops) (f 4))
codec-codec_ops = default_digital_ops;
/* A device which thinks its a modem but isnt */
@@ -920,11 +934,6 @@
codec
Re: [PATCH] OSS Support for AC97 low power codecs
Andrew,
Looks like I missed a critical diff line in the patch :-
--- a/include/linux/ac97_codec.h 2005-01-22 01:46:59.0 +
and added some PM stuff that is from a future patch.
Correct patch is attached.
Liam
On Wed, 2005-01-26 at 13:42, Liam Girdwood wrote:
Hi Andrew,
This is a resend of a patch that has been applied to 2.4. The low power
codec functionality has also now been included in ALSA.
I've attached a patch against 2.6.11-rc2 that checks the codec ID before
doing an AC97 register reset. This allows the kernel to support low
power codecs that are powered down by a reset command. This patch also
fixes some other minor issues.
Changes:-
o Added AC97_DEFAULT_POWER_OFF to ac97_codec_ids[]
o ac97_probe now checks hardwired codec ID's before sending a reset
o Added support for WM9713
o Moved the codec specific inits after the mixer setup as some init
settings were being clobbered.
o Added extra check so that default_digital_ops doesn't overwrite a
valid codec_ops. (SPDIF)
Signed-off-by: Liam Girdwood [EMAIL PROTECTED]
Liam
diff -ur a/sound/oss/ac97_codec.c b/sound/oss/ac97_codec.c
--- a/sound/oss/ac97_codec.c 2005-01-22 01:47:15.0 +
+++ b/sound/oss/ac97_codec.c 2005-01-26 13:22:23.0 +
@@ -71,6 +71,7 @@
static int wolfson_init04(struct ac97_codec * codec);
static int wolfson_init05(struct ac97_codec * codec);
static int wolfson_init11(struct ac97_codec * codec);
+static int wolfson_init13(struct ac97_codec * codec);
static int tritech_init(struct ac97_codec * codec);
static int tritech_maestro_init(struct ac97_codec * codec);
static int sigmatel_9708_init(struct ac97_codec *codec);
@@ -107,6 +108,7 @@
static struct ac97_ops wolfson_ops04 = { wolfson_init04, NULL, NULL };
static struct ac97_ops wolfson_ops05 = { wolfson_init05, NULL, NULL };
static struct ac97_ops wolfson_ops11 = { wolfson_init11, NULL, NULL };
+static struct ac97_ops wolfson_ops13 = { wolfson_init13, NULL, NULL };
static struct ac97_ops tritech_ops = { tritech_init, NULL, NULL };
static struct ac97_ops tritech_m_ops = { tritech_maestro_init, NULL, NULL };
static struct ac97_ops sigmatel_9708_ops = { sigmatel_9708_init, NULL, NULL };
@@ -171,6 +173,7 @@
{0x574D4C05, Wolfson WM9705/WM9710, wolfson_ops05},
{0x574D4C09, Wolfson WM9709, null_ops},
{0x574D4C12, Wolfson WM9711/9712, wolfson_ops11},
+ {0x574D4C13, Wolfson WM9713, wolfson_ops13, AC97_DEFAULT_POWER_OFF},
{0x83847600, SigmaTel STAC, null_ops},
{0x83847604, SigmaTel STAC9701/3/4/5, null_ops},
{0x83847605, SigmaTel STAC9704, null_ops},
@@ -797,6 +800,9 @@
* Currently codec_wait is used to wait for AC97 codec
* reset to complete.
*
+ * Some codecs will power down when a register reset is
+ * performed. We now check for such codecs.
+ *
* Returns 1 (true) on success, or 0 (false) on failure.
*/
@@ -810,34 +816,17 @@
struct list_head *l;
struct ac97_driver *d;
- /* probing AC97 codec, AC97 2.0 says that bit 15 of register 0x00 (reset) should
- * be read zero.
- *
- * FIXME: is the following comment outdated? -jgarzik
- * Probing of AC97 in this way is not reliable, it is not even SAFE !!
- */
- codec-codec_write(codec, AC97_RESET, 0L);
-
- /* also according to spec, we wait for codec-ready state */
+ /* wait for codec-ready state */
if (codec-codec_wait)
codec-codec_wait(codec);
else
udelay(10);
-
- if ((audio = codec-codec_read(codec, AC97_RESET)) 0x8000) {
- printk(KERN_ERR ac97_codec: %s ac97 codec not present\n,
- (codec-id 0x2) ? (codec-id1 ? 4th : Tertiary)
- : (codec-id1 ? Secondary: Primary));
- return 0;
- }
-
- /* probe for Modem Codec */
- codec-modem = ac97_check_modem(codec);
- codec-name = NULL;
- codec-codec_ops = default_ops;
-
+
+ /* will the codec power down if register reset ? */
id1 = codec-codec_read(codec, AC97_VENDOR_ID1);
id2 = codec-codec_read(codec, AC97_VENDOR_ID2);
+ codec-name = NULL;
+ codec-codec_ops = null_ops;
for (i = 0; i ARRAY_SIZE(ac97_codec_ids); i++) {
if (ac97_codec_ids[i].id == ((id1 16) | id2)) {
codec-type = ac97_codec_ids[i].id;
@@ -849,9 +838,34 @@
}
codec-model = (id1 16) | id2;
+ if ((codec-flags AC97_DEFAULT_POWER_OFF) == 0) {
+ /* reset codec and wait for the ready bit before we continue */
+ codec-codec_write(codec, AC97_RESET, 0L);
+ if (codec-codec_wait)
+ codec-codec_wait(codec);
+ else
+ udelay(10);
+ }
+ /* probing AC97 codec, AC97 2.0 says that bit 15 of register 0x00 (reset) should
+ * be read zero.
+ *
+ * FIXME: is the following comment outdated? -jgarzik
+ * Probing of AC97 in this way is not reliable, it is not even SAFE !!
+ */
+ if ((audio = codec-codec_read(codec, AC97_RESET)) 0x8000) {
+ printk(KERN_ERR ac97_codec: %s ac97 codec not present\n,
+ (codec-id 0x2) ? (codec-id1 ? 4th : Tertiary)
+ : (codec-id1 ? Secondary: Primary));
+ return 0;
+ }
+
+ /* probe for Modem Codec */
+ codec
