On Tue, Feb 1, 2011 at 1:38 AM, Andrew Morton <[email protected]> wrote:
> It's a little irritating having two hwspinlock.h's.
> hwspinlock_internal.h wold be a conventional approach. ?But it's not a
> big deal.
...
>> +/**
>> + * __hwspin_lock_timeout() - lock an hwspinlock with timeout limit
>> + * @hwlock: the hwspinlock to be locked
>> + * @timeout: timeout value in jiffies
>
> hm, why in jiffies?
>
> The problem here is that lazy programmers will use
>
> ? ? ? ?hwspin_lock_timeout(lock, 10, ...)
>
> and their code will work happily with HZ=100 but will explode with HZ=1000.
>
> IOW, this interface *requires* that all callers perform a
> seconds-to-jiffies conversion before calling hwspin_lock_timeout(). ?So
> why not reduce their effort and their ability to make mistakes by
> defining the API to take seconds?
I considered that, but then decided to use jiffies in order to be
consistent with wait_event_timeout/schedule_timeout (although I don't
return the remaining jiffies in case the lock is taken before the
timeout elapses), and also to allow user-selected granularity.
But I do kind of like the idea of not using jiffies. We can probably
even move to msecs, since anyway this is an error condition, and
people who needs a quick check should just use the trylock() version.
I'll do a quick respin of the patches with that and the
hwspinlock_internal.h comment above.
Thanks,
Ohad.
On Tue, 1 Feb 2011 08:20:13 +0200 Ohad Ben-Cohen <[email protected]> wrote:
> On Tue, Feb 1, 2011 at 1:38 AM, Andrew Morton <[email protected]> wrote:
> > It's a little irritating having two hwspinlock.h's.
> > hwspinlock_internal.h wold be a conventional approach. __But it's not a
> > big deal.
> ...
>
> >> +/**
> >> + * __hwspin_lock_timeout() - lock an hwspinlock with timeout limit
> >> + * @hwlock: the hwspinlock to be locked
> >> + * @timeout: timeout value in jiffies
> >
> > hm, why in jiffies?
> >
> > The problem here is that lazy programmers will use
> >
> > __ __ __ __hwspin_lock_timeout(lock, 10, ...)
> >
> > and their code will work happily with HZ=100 but will explode with HZ=1000.
> >
> > IOW, this interface *requires* that all callers perform a
> > seconds-to-jiffies conversion before calling hwspin_lock_timeout(). __So
> > why not reduce their effort and their ability to make mistakes by
> > defining the API to take seconds?
>
> I considered that, but then decided to use jiffies in order to be
> consistent with wait_event_timeout/schedule_timeout (although I don't
> return the remaining jiffies in case the lock is taken before the
> timeout elapses), and also to allow user-selected granularity.
>
> But I do kind of like the idea of not using jiffies. We can probably
> even move to msecs, since anyway this is an error condition, and
> people who needs a quick check should just use the trylock() version.
>
> I'll do a quick respin of the patches with that and the
> hwspinlock_internal.h comment above.
OK..
The patch series looks OK to me. But there isn't a lot of point in me
putting them into my tree. Maybe Tony or Russell or Greg can grab them
if they like the look of it all?
On Tue, Feb 1, 2011 at 8:38 AM, Andrew Morton <[email protected]> wrote:
>> I'll do a quick respin of the patches with that and the
>> hwspinlock_internal.h comment above.
>
> OK..
>
> The patch series looks OK to me.
Can I add your Acked-by on the non-omap parts when I respin the series ?
Thanks,
Ohad.
On Tue, 1 Feb 2011 09:36:22 +0200 Ohad Ben-Cohen <[email protected]> wrote:
> On Tue, Feb 1, 2011 at 8:38 AM, Andrew Morton <[email protected]> wrote:
> >> I'll do a quick respin of the patches with that and the
> >> hwspinlock_internal.h comment above.
> >
> > OK..
> >
> > The patch series looks OK to me.
>
> Can I add your Acked-by on the non-omap parts when I respin the series ?
spose so. I don't normally do acked-by's. I think it's my way of
avoiding getting blamed when it all blows up.
On Tue, Feb 1, 2011 at 9:40 AM, Andrew Morton <[email protected]> wrote:
> On Tue, 1 Feb 2011 09:36:22 +0200 Ohad Ben-Cohen <[email protected]> wrote:
>
>> On Tue, Feb 1, 2011 at 8:38 AM, Andrew Morton <[email protected]> wrote:
>> >> I'll do a quick respin of the patches with that and the
>> >> hwspinlock_internal.h comment above.
>> >
>> > OK..
>> >
>> > The patch series looks OK to me.
>>
>> Can I add your Acked-by on the non-omap parts when I respin the series ?
>
> spose so. ?I don't normally do acked-by's. ?I think it's my way of
> avoiding getting blamed when it all blows up.
I don't want to be breaking old habits then :)
>> > Maybe Tony or Russell or Greg can grab them
>> > if they like the look of it all?
Let's just wait a bit for Tony's or Russell's or Greg's answer.
Thanks,
Ohad.
On Mon, Jan 31, 2011 at 10:38:59PM -0800, Andrew Morton wrote:
> On Tue, 1 Feb 2011 08:20:13 +0200 Ohad Ben-Cohen <[email protected]> wrote:
>
> > On Tue, Feb 1, 2011 at 1:38 AM, Andrew Morton <[email protected]> wrote:
> > > It's a little irritating having two hwspinlock.h's.
> > > hwspinlock_internal.h wold be a conventional approach. __But it's not a
> > > big deal.
> > ...
> >
> > >> +/**
> > >> + * __hwspin_lock_timeout() - lock an hwspinlock with timeout limit
> > >> + * @hwlock: the hwspinlock to be locked
> > >> + * @timeout: timeout value in jiffies
> > >
> > > hm, why in jiffies?
> > >
> > > The problem here is that lazy programmers will use
> > >
> > > __ __ __ __hwspin_lock_timeout(lock, 10, ...)
> > >
> > > and their code will work happily with HZ=100 but will explode with HZ=1000.
> > >
> > > IOW, this interface *requires* that all callers perform a
> > > seconds-to-jiffies conversion before calling hwspin_lock_timeout(). __So
> > > why not reduce their effort and their ability to make mistakes by
> > > defining the API to take seconds?
> >
> > I considered that, but then decided to use jiffies in order to be
> > consistent with wait_event_timeout/schedule_timeout (although I don't
> > return the remaining jiffies in case the lock is taken before the
> > timeout elapses), and also to allow user-selected granularity.
> >
> > But I do kind of like the idea of not using jiffies. We can probably
> > even move to msecs, since anyway this is an error condition, and
> > people who needs a quick check should just use the trylock() version.
> >
> > I'll do a quick respin of the patches with that and the
> > hwspinlock_internal.h comment above.
>
> OK..
>
> The patch series looks OK to me. But there isn't a lot of point in me
> putting them into my tree. Maybe Tony or Russell or Greg can grab them
> if they like the look of it all?
As it's an arm-specific thing, it should probably go through Russell's
tree.
thanks,
greg k-h
On Tue, Feb 01, 2011 at 10:12:38AM +0200, Ohad Ben-Cohen wrote:
> On Tue, Feb 1, 2011 at 9:40 AM, Andrew Morton <[email protected]> wrote:
> > On Tue, 1 Feb 2011 09:36:22 +0200 Ohad Ben-Cohen <[email protected]> wrote:
> >
> >> On Tue, Feb 1, 2011 at 8:38 AM, Andrew Morton <[email protected]> wrote:
> >> >> I'll do a quick respin of the patches with that and the
> >> >> hwspinlock_internal.h comment above.
> >> >
> >> > OK..
> >> >
> >> > The patch series looks OK to me.
> >>
> >> Can I add your Acked-by on the non-omap parts when I respin the series ?
> >
> > spose so. ?I don't normally do acked-by's. ?I think it's my way of
> > avoiding getting blamed when it all blows up.
>
> I don't want to be breaking old habits then :)
>
> >> > Maybe Tony or Russell or Greg can grab them
> >> > if they like the look of it all?
>
> Let's just wait a bit for Tony's or Russell's or Greg's answer.
As it touches OMAP code, it makes sense to merge it through Tony's tree
as that should reduce the number of possible conflicts.
* Russell King - ARM Linux <[email protected]> [110202 04:10]:
> On Tue, Feb 01, 2011 at 10:12:38AM +0200, Ohad Ben-Cohen wrote:
> > On Tue, Feb 1, 2011 at 9:40 AM, Andrew Morton <[email protected]> wrote:
> > > On Tue, 1 Feb 2011 09:36:22 +0200 Ohad Ben-Cohen <[email protected]> wrote:
> > >
> > >> On Tue, Feb 1, 2011 at 8:38 AM, Andrew Morton <[email protected]> wrote:
> > >> >> I'll do a quick respin of the patches with that and the
> > >> >> hwspinlock_internal.h comment above.
> > >> >
> > >> > OK..
> > >> >
> > >> > The patch series looks OK to me.
> > >>
> > >> Can I add your Acked-by on the non-omap parts when I respin the series ?
> > >
> > > spose so. I don't normally do acked-by's. I think it's my way of
> > > avoiding getting blamed when it all blows up.
> >
> > I don't want to be breaking old habits then :)
> >
> > >> > Maybe Tony or Russell or Greg can grab them
> > >> > if they like the look of it all?
> >
> > Let's just wait a bit for Tony's or Russell's or Greg's answer.
>
> As it touches OMAP code, it makes sense to merge it through Tony's tree
> as that should reduce the number of possible conflicts.
OK I'll take them then.
Regards,
Tony