On Wed, Mar 27, 2013 at 12:09:43AM -0700, Mike Turquette wrote:
> + /* set context for any reentrant calls */
> + atomic_set(_context, (int) get_current());
...
> + if (mutex_is_locked(_lock))
> + if ((void *) atomic_read(_context) == get_current())
> +
On Wed, 27 Mar 2013, Mike Turquette wrote:
> Quoting Laurent Pinchart (2013-03-27 02:08:15)
> > I wonder if it would make sense to abstract these operations in a generic
> > recursive mutex. Given that it would delay this patch past v3.10 I won't
> > push
> > for that.
> >
>
> Having a nice
On Wed, 27 Mar 2013, Mike Turquette wrote:
> Thanks for the review Thomas. I will steal your code and call it my own
> in the next version.
Sure.
> In particular getting rid of the atomics makes things much nicer.
I'd say using the helper functions and not having all these
conditionals makes
Quoting Thomas Gleixner (2013-03-27 04:09:17)
> On Wed, 27 Mar 2013, Ulf Hansson wrote:
> > On 27 March 2013 10:55, Viresh Kumar wrote:
> > > On 27 March 2013 15:10, Thomas Gleixner wrote:
> > >> On Wed, 27 Mar 2013, Mike Turquette wrote:
> > >>
> > >>> Reentrancy into the clock framework from
On Wed, 27 Mar 2013, Mike Turquette wrote:
> +/*** locking & reentrancy ***/
> +
> +static void clk_fwk_lock(void)
This function name sucks as much as the whole implementation does.
> +{
> + /* hold the framework-wide lock, context == NULL */
> + mutex_lock(_lock);
> +
> + /* set
On Wed, 27 Mar 2013, Ulf Hansson wrote:
> On 27 March 2013 10:55, Viresh Kumar wrote:
> > On 27 March 2013 15:10, Thomas Gleixner wrote:
> >> On Wed, 27 Mar 2013, Mike Turquette wrote:
> >>
> >>> Reentrancy into the clock framework from the clk.h api is necessary
> >>> for clocks that are
On 27 March 2013 10:55, Viresh Kumar wrote:
> On 27 March 2013 15:10, Thomas Gleixner wrote:
>> On Wed, 27 Mar 2013, Mike Turquette wrote:
>>
>>> Reentrancy into the clock framework from the clk.h api is necessary
>>> for clocks that are prepared and unprepared via i2c_transfer (which
>>>
Hi Thomas,
On Wednesday 27 March 2013 10:40:28 Thomas Gleixner wrote:
> On Wed, 27 Mar 2013, Mike Turquette wrote:
> > Reentrancy into the clock framework from the clk.h api is necessary
> > for clocks that are prepared and unprepared via i2c_transfer (which
> > includes many PMICs and discrete
On 27 March 2013 15:10, Thomas Gleixner wrote:
> On Wed, 27 Mar 2013, Mike Turquette wrote:
>
>> Reentrancy into the clock framework from the clk.h api is necessary
>> for clocks that are prepared and unprepared via i2c_transfer (which
>> includes many PMICs and discrete audio chips) as well as
On Wed, 27 Mar 2013, Mike Turquette wrote:
> Reentrancy into the clock framework from the clk.h api is necessary
> for clocks that are prepared and unprepared via i2c_transfer (which
> includes many PMICs and discrete audio chips) as well as for several
> other use cases.
That explanation sucks.
Hi Mike,
Thanks for the patch.
Please see below for a couple of comments.
On Wednesday 27 March 2013 00:09:43 Mike Turquette wrote:
> Reentrancy into the clock framework from the clk.h api is necessary for
> clocks that are prepared and unprepared via i2c_transfer (which includes
> many PMICs
Reentrancy into the clock framework from the clk.h api is necessary for
clocks that are prepared and unprepared via i2c_transfer (which includes
many PMICs and discrete audio chips) as well as for several other use
cases.
This patch implements reentrancy by adding two global atomic_t's which
Reentrancy into the clock framework from the clk.h api is necessary for
clocks that are prepared and unprepared via i2c_transfer (which includes
many PMICs and discrete audio chips) as well as for several other use
cases.
This patch implements reentrancy by adding two global atomic_t's which
Hi Mike,
Thanks for the patch.
Please see below for a couple of comments.
On Wednesday 27 March 2013 00:09:43 Mike Turquette wrote:
Reentrancy into the clock framework from the clk.h api is necessary for
clocks that are prepared and unprepared via i2c_transfer (which includes
many PMICs and
On Wed, 27 Mar 2013, Mike Turquette wrote:
Reentrancy into the clock framework from the clk.h api is necessary
for clocks that are prepared and unprepared via i2c_transfer (which
includes many PMICs and discrete audio chips) as well as for several
other use cases.
That explanation sucks.
On 27 March 2013 15:10, Thomas Gleixner t...@linutronix.de wrote:
On Wed, 27 Mar 2013, Mike Turquette wrote:
Reentrancy into the clock framework from the clk.h api is necessary
for clocks that are prepared and unprepared via i2c_transfer (which
includes many PMICs and discrete audio chips) as
Hi Thomas,
On Wednesday 27 March 2013 10:40:28 Thomas Gleixner wrote:
On Wed, 27 Mar 2013, Mike Turquette wrote:
Reentrancy into the clock framework from the clk.h api is necessary
for clocks that are prepared and unprepared via i2c_transfer (which
includes many PMICs and discrete audio
On 27 March 2013 10:55, Viresh Kumar viresh.ku...@linaro.org wrote:
On 27 March 2013 15:10, Thomas Gleixner t...@linutronix.de wrote:
On Wed, 27 Mar 2013, Mike Turquette wrote:
Reentrancy into the clock framework from the clk.h api is necessary
for clocks that are prepared and unprepared via
On Wed, 27 Mar 2013, Ulf Hansson wrote:
On 27 March 2013 10:55, Viresh Kumar viresh.ku...@linaro.org wrote:
On 27 March 2013 15:10, Thomas Gleixner t...@linutronix.de wrote:
On Wed, 27 Mar 2013, Mike Turquette wrote:
Reentrancy into the clock framework from the clk.h api is necessary
On Wed, 27 Mar 2013, Mike Turquette wrote:
+/*** locking reentrancy ***/
+
+static void clk_fwk_lock(void)
This function name sucks as much as the whole implementation does.
+{
+ /* hold the framework-wide lock, context == NULL */
+ mutex_lock(prepare_lock);
+
+ /* set
Quoting Thomas Gleixner (2013-03-27 04:09:17)
On Wed, 27 Mar 2013, Ulf Hansson wrote:
On 27 March 2013 10:55, Viresh Kumar viresh.ku...@linaro.org wrote:
On 27 March 2013 15:10, Thomas Gleixner t...@linutronix.de wrote:
On Wed, 27 Mar 2013, Mike Turquette wrote:
Reentrancy into the
On Wed, 27 Mar 2013, Mike Turquette wrote:
Thanks for the review Thomas. I will steal your code and call it my own
in the next version.
Sure.
In particular getting rid of the atomics makes things much nicer.
I'd say using the helper functions and not having all these
conditionals makes it
On Wed, 27 Mar 2013, Mike Turquette wrote:
Quoting Laurent Pinchart (2013-03-27 02:08:15)
I wonder if it would make sense to abstract these operations in a generic
recursive mutex. Given that it would delay this patch past v3.10 I won't
push
for that.
Having a nice implementation
On Wed, Mar 27, 2013 at 12:09:43AM -0700, Mike Turquette wrote:
+ /* set context for any reentrant calls */
+ atomic_set(prepare_context, (int) get_current());
...
+ if (mutex_is_locked(prepare_lock))
+ if ((void *) atomic_read(prepare_context) == get_current())
+
24 matches
Mail list logo
