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())
>
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 im
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
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 th
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);
> +
> + /*
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 prepare
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
>>> include
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 au
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 fo
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 an
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
track
12 matches
Mail list logo
