[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTinNfERyi_bTWc7LOKR1uRLC3E612ubFKBLxWB1E@mail.gmail.com>
Date: Tue, 19 Oct 2010 22:43:34 +0200
From: Ohad Ben-Cohen <ohad@...ery.com>
To: Grant Likely <grant.likely@...retlab.ca>
Cc: linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, akpm@...ux-foundation.org,
Greg KH <greg@...ah.com>, Tony Lindgren <tony@...mide.com>,
Benoit Cousson <b-cousson@...com>,
Hari Kanigeri <h-kanigeri2@...com>, Suman Anna <s-anna@...com>,
Simon Que <sque@...com>,
"Krishnamoorthy, Balaji T" <balajitk@...com>
Subject: Re: [PATCH 1/3] drivers: misc: add omap_hwspinlock driver
On Tue, Oct 19, 2010 at 7:01 PM, Grant Likely <grant.likely@...retlab.ca> wrote:
>> + struct omap_hwspinlock *omap_hwspinlock_request(void);
...
> ERR_PTR() is only appropriate when the caller actually cares about the
> failure code and has different behaviour depending on the result.
Agree; the hwspinlock users can surely live without an explicit error
code from the _request APIs, and some extra robustness can only do
good.
I'll remove it.
> Disabling irqs *might* be a concern as a source of RT latency. It
> might be better to make the caller responsible for managing local spin
> locks and irq disable/enable.
This a coming from an hardware requirement, rather than a choice the
user should take.
If a hwspinlock is taken over a long period of time, its other user
(with which we try to achieve synchronization) might be polling the
OMAP interconnect for too long (trying to take the hwspinlock) and
thus preventing it to be used for other transactions.
To prevent such lengthy polling on the interconnect, the hwspinlock
should only be used for very short period of times, with preemption
and interrupts disabled.
That's why we don't give users the choice whether to disable
interrupts or not - it's simply not a decision they should take.
Thanks,
Ohad.
--
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