[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <51701F6F.7070206@ti.com>
Date: Thu, 18 Apr 2013 19:29:35 +0300
From: Grygorii Strashko <grygorii.strashko@...com>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC: Andrii Tseglytskyi <andrii.tseglytskyi@...com>,
Mark Brown <broonie@...nel.org>,
Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
<linux-kernel@...r.kernel.org>,
Mike Turquette <mturquette@...aro.org>,
Nishanth Menon <nm@...com>, Tero Kristo <t-kristo@...com>,
linux-omap <linux-omap@...r.kernel.org>,
linux-arm <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC v1] regulator: core: introduce regulator chain locking scheme
On 04/15/2013 07:40 PM, Mark Brown wrote:
> On Mon, Apr 15, 2013 at 07:21:25PM +0300, Andrii Tseglytskyi wrote:
>> On 04/15/2013 06:50 PM, Mark Brown wrote:
>>>> In addition, such locking scheme allows to have access to the supplier
>>>> regulator API from inside child's (consumer) regulator API.
>>> I've still not seen any use case articulated for doing this...
>> Use case is introduced in ABB series:
> Sorry, I meant any sensible use case.
Hi Mark,
Thanks for you comments. I'll split it to 3 patches:
- abstract locking out into helper functions;
- introduce regulator chain locking scheme
- allow reentrant calls into the regulator framework (with hope that is
has future,
may be can enable/disable it through constraints)
I understand that Regulator FW is common and wide used and we should
very careful here.
Regards,
- grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists