From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Mark Brown <broonie@kernel.org>, <sameo@linux.intel.com>,
<lee.jones@linaro.org>, <lgirdwood@gmail.com>, <perex@perex.cz>,
<tiwai@suse.de>, <patches@opensource.wolfsonmicro.com>,
<alsa-devel@alsa-project.org>, <linux-kernel@vger.kernel.org>
Subject: Re: multi-codec support for arizona-ldo1 was Re: System with multiple arizona (wm5102) codecs
Date: Mon, 16 Nov 2015 13:57:55 +0000 [thread overview]
Message-ID: <20151116135755.GC18889@ck-lbox> (raw)
In-Reply-To: <20151116122947.GA9125@amd>
On Mon, Nov 16, 2015 at 01:29:47PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > Every single sound driver gets this right, none of them assume the name
> > > > is global. What makes you say that they assume names are global?
> >
> > > Ok, so you are saying that if I fix mfd initialization, sound will
> > > automagically switch from global regulators to device-specific
> > > regulators and things will start working?
> >
> > Yes.
>
> Ok, so something like this should be applied?
>
> (I'm not sure how to test it, as audio works before and after the
> patch.)
>
Apologies this all going down over the weekend I have only just
caught up. I will probably send a few other inline replies to the
thread.
> Thanks,
> Pavel
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
>
> commit d6005263acb94343645e719ee90b8940cb2545df
> Author: Pavel <pavel@ucw.cz>
> Date: Mon Nov 16 13:19:21 2015 +0100
>
> regulator_bulk_register() needs device to be already
> registered. Reorganize the code to make it so.
>
> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index 14fd5cb..e891f10 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
> @@ -147,12 +147,6 @@ static int mfd_add_device(struct device *parent, int id,
> pdev->dev.dma_parms = parent->dma_parms;
> pdev->dev.coherent_dma_mask = parent->coherent_dma_mask;
>
> - ret = regulator_bulk_register_supply_alias(
> - &pdev->dev, cell->parent_supplies,
> - parent, cell->parent_supplies,
> - cell->num_parent_supplies);
> - if (ret < 0)
> - goto fail_res;
This does look like it is too early, but really all we are doing
it adding the device pointer and the supply name into a lookup
table, neither of those things change across the stuff below. The
printout for the mapping does indeed appear to be broken (because
you can't dev_name on the device yet, until after it has been
added), but that will be all that should get fixed by this move.
>
> if (parent->of_node && cell->of_compatible) {
> for_each_child_of_node(parent->of_node, np) {
> @@ -169,12 +176,12 @@ static int mfd_add_device(struct device *parent, int id,
> ret = platform_device_add_data(pdev,
> cell->platform_data, cell->pdata_size);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
> }
>
> ret = mfd_platform_add_cell(pdev, cell, usage_count);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
>
> for (r = 0; r < cell->num_resources; r++) {
> res[r].name = cell->resources[r].name;
> @@ -210,22 +217,29 @@ static int mfd_add_device(struct device *parent, int id,
> if (has_acpi_companion(&pdev->dev)) {
> ret = acpi_check_resource_conflict(&res[r]);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
> }
> }
> }
>
> ret = platform_device_add_resources(pdev, res, cell->num_resources);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
>
> ret = platform_device_add(pdev);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
>
> if (cell->pm_runtime_no_callbacks)
> pm_runtime_no_callbacks(&pdev->dev);
>
> + ret = regulator_bulk_register_supply_alias(
> + &pdev->dev, cell->parent_supplies,
> + parent, cell->parent_supplies,
> + cell->num_parent_supplies);
> + if (ret < 0)
> + goto fail_alias;
> +
Furthermore, the trouble is that you can't move this to here. The
platform_device_add will usually cause the device to probe and
most devices request their supplies in their probe. Thus if you
only register the alias here then it will not be available when
the device needs it.
Thanks,
Charles
WARNING: multiple messages have this Message-ID (diff)
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: alsa-devel@alsa-project.org, sameo@linux.intel.com,
tiwai@suse.de, linux-kernel@vger.kernel.org,
patches@opensource.wolfsonmicro.com, lgirdwood@gmail.com,
Mark Brown <broonie@kernel.org>,
lee.jones@linaro.org
Subject: Re: multi-codec support for arizona-ldo1 was Re: System with multiple arizona (wm5102) codecs
Date: Mon, 16 Nov 2015 13:57:55 +0000 [thread overview]
Message-ID: <20151116135755.GC18889@ck-lbox> (raw)
In-Reply-To: <20151116122947.GA9125@amd>
On Mon, Nov 16, 2015 at 01:29:47PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > Every single sound driver gets this right, none of them assume the name
> > > > is global. What makes you say that they assume names are global?
> >
> > > Ok, so you are saying that if I fix mfd initialization, sound will
> > > automagically switch from global regulators to device-specific
> > > regulators and things will start working?
> >
> > Yes.
>
> Ok, so something like this should be applied?
>
> (I'm not sure how to test it, as audio works before and after the
> patch.)
>
Apologies this all going down over the weekend I have only just
caught up. I will probably send a few other inline replies to the
thread.
> Thanks,
> Pavel
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
>
> commit d6005263acb94343645e719ee90b8940cb2545df
> Author: Pavel <pavel@ucw.cz>
> Date: Mon Nov 16 13:19:21 2015 +0100
>
> regulator_bulk_register() needs device to be already
> registered. Reorganize the code to make it so.
>
> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index 14fd5cb..e891f10 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
> @@ -147,12 +147,6 @@ static int mfd_add_device(struct device *parent, int id,
> pdev->dev.dma_parms = parent->dma_parms;
> pdev->dev.coherent_dma_mask = parent->coherent_dma_mask;
>
> - ret = regulator_bulk_register_supply_alias(
> - &pdev->dev, cell->parent_supplies,
> - parent, cell->parent_supplies,
> - cell->num_parent_supplies);
> - if (ret < 0)
> - goto fail_res;
This does look like it is too early, but really all we are doing
it adding the device pointer and the supply name into a lookup
table, neither of those things change across the stuff below. The
printout for the mapping does indeed appear to be broken (because
you can't dev_name on the device yet, until after it has been
added), but that will be all that should get fixed by this move.
>
> if (parent->of_node && cell->of_compatible) {
> for_each_child_of_node(parent->of_node, np) {
> @@ -169,12 +176,12 @@ static int mfd_add_device(struct device *parent, int id,
> ret = platform_device_add_data(pdev,
> cell->platform_data, cell->pdata_size);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
> }
>
> ret = mfd_platform_add_cell(pdev, cell, usage_count);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
>
> for (r = 0; r < cell->num_resources; r++) {
> res[r].name = cell->resources[r].name;
> @@ -210,22 +217,29 @@ static int mfd_add_device(struct device *parent, int id,
> if (has_acpi_companion(&pdev->dev)) {
> ret = acpi_check_resource_conflict(&res[r]);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
> }
> }
> }
>
> ret = platform_device_add_resources(pdev, res, cell->num_resources);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
>
> ret = platform_device_add(pdev);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
>
> if (cell->pm_runtime_no_callbacks)
> pm_runtime_no_callbacks(&pdev->dev);
>
> + ret = regulator_bulk_register_supply_alias(
> + &pdev->dev, cell->parent_supplies,
> + parent, cell->parent_supplies,
> + cell->num_parent_supplies);
> + if (ret < 0)
> + goto fail_alias;
> +
Furthermore, the trouble is that you can't move this to here. The
platform_device_add will usually cause the device to probe and
most devices request their supplies in their probe. Thus if you
only register the alias here then it will not be available when
the device needs it.
Thanks,
Charles
next prev parent reply other threads:[~2015-11-16 14:14 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 11:54 System with multiple arizona (wm5102) codecs Pavel Machek
2015-09-14 11:52 ` Charles Keepax
2015-09-14 11:52 ` Charles Keepax
2015-09-14 13:31 ` Charles Keepax
2015-09-14 13:31 ` Charles Keepax
2015-09-14 20:11 ` Pavel Machek
2015-09-15 6:18 ` Pavel Machek
2015-09-15 8:06 ` Charles Keepax
2015-09-15 8:06 ` Charles Keepax
2015-09-15 8:35 ` Pavel Machek
2015-09-15 13:56 ` [alsa-devel] " Caleb Crome
2015-09-15 13:56 ` Caleb Crome
2015-09-15 14:09 ` [alsa-devel] " Mark Brown
2015-09-15 14:09 ` Mark Brown
2015-09-15 15:26 ` [alsa-devel] " Caleb Crome
2015-09-19 18:21 ` Mark Brown
2015-09-21 12:36 ` Pavel Machek
2015-10-12 9:00 ` multi-codec support for arizona-ldo1 was " Pavel Machek
2015-10-12 11:37 ` Charles Keepax
2015-10-12 11:37 ` Charles Keepax
2015-11-30 11:33 ` multi-card support for davinci-evm Pavel Machek
2015-11-30 11:37 ` multi-card support for arizona-core Pavel Machek
2015-11-30 11:37 ` Pavel Machek
2015-11-30 11:54 ` Mark Brown
2015-10-12 15:47 ` multi-codec support for arizona-ldo1 was Re: System with multiple arizona (wm5102) codecs Mark Brown
2015-10-12 20:11 ` Pavel Machek
2015-10-13 11:53 ` Mark Brown
2015-10-13 11:53 ` Mark Brown
2015-11-13 21:58 ` Pavel Machek
2015-11-13 22:53 ` Mark Brown
2015-11-14 7:44 ` Pavel Machek
2015-11-14 7:44 ` Pavel Machek
2015-11-14 12:39 ` Mark Brown
2015-11-14 17:59 ` Pavel Machek
2015-11-14 17:59 ` Pavel Machek
2015-11-14 18:49 ` Mark Brown
2015-11-14 21:16 ` Pavel Machek
2015-11-14 21:16 ` Pavel Machek
2015-11-15 0:14 ` Mark Brown
2015-11-15 0:14 ` Mark Brown
2015-11-16 7:45 ` Pavel Machek
2015-11-16 10:50 ` Mark Brown
2015-11-16 12:29 ` Pavel Machek
2015-11-16 12:29 ` Pavel Machek
2015-11-16 13:57 ` Charles Keepax [this message]
2015-11-16 13:57 ` Charles Keepax
2015-11-16 14:28 ` Charles Keepax
2015-11-16 14:28 ` Charles Keepax
2015-11-16 17:33 ` Mark Brown
2015-11-16 14:11 ` Charles Keepax
2015-11-16 14:11 ` Charles Keepax
2015-11-22 6:51 ` Pavel Machek
2015-11-22 6:51 ` Pavel Machek
2015-11-23 8:18 ` Lee Jones
2015-11-23 8:18 ` Lee Jones
2015-11-23 10:11 ` Pavel Machek
2015-11-23 10:25 ` Richard Fitzgerald
2015-11-23 10:25 ` Richard Fitzgerald
2015-11-23 11:30 ` Mark Brown
2015-11-23 11:46 ` Charles Keepax
2015-11-23 11:46 ` Charles Keepax
2015-11-23 14:31 ` Lee Jones
2015-11-23 15:00 ` Pavel Machek
2015-11-16 14:05 ` Charles Keepax
2015-11-16 14:05 ` Charles Keepax
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151116135755.GC18889@ck-lbox \
--to=ckeepax@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@opensource.wolfsonmicro.com \
--cc=pavel@ucw.cz \
--cc=perex@perex.cz \
--cc=sameo@linux.intel.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.