On Fri, Aug 14, 2015 at 6:24 PM, Lina Iyer wrote:
> Would you rather query the hwspinlock driver to see if the framework
> should take a s/w spinlock or not, IOW, raw-accessible or not?
Sorry, I'm afraid I rather not. This seems to make things even more
complicated without introducing any technic
On Thu, Aug 13 2015 at 00:34 -0600, Ohad Ben-Cohen wrote:
On Wed, Jul 29, 2015 at 12:51 AM, Lina Iyer wrote:
Let's not make this more complicated than needed, so please add the
hwcaps member to hwspinlock_device instead of to hwspinlock struct. We
could always change this later if it proves to
On Fri, Aug 14 2015 at 04:52 -0600, Ohad Ben-Cohen wrote:
On Thu, Aug 13, 2015 at 6:25 PM, Andy Gross wrote:
The issue in hardwiring this into the driver itself means forfeiting
extensibility. So on one side (w/ raw support), we get the ability to deal with
the lock number changing. On the ot
On Thu, Aug 13, 2015 at 6:25 PM, Andy Gross wrote:
> The issue in hardwiring this into the driver itself means forfeiting
> extensibility. So on one side (w/ raw support), we get the ability to deal
> with
> the lock number changing. On the other side (w/o raw), we'd have to probably
> tie this
On Thu, Aug 13, 2015 at 09:34:13AM +0300, Ohad Ben-Cohen wrote:
> On Wed, Jul 29, 2015 at 12:51 AM, Lina Iyer wrote:
> >> Let's not make this more complicated than needed, so please add the
> >> hwcaps member to hwspinlock_device instead of to hwspinlock struct. We
> >> could always change this la
On Wed, Jul 29, 2015 at 12:51 AM, Lina Iyer wrote:
>> Let's not make this more complicated than needed, so please add the
>> hwcaps member to hwspinlock_device instead of to hwspinlock struct. We
>> could always change this later if it proves to be insufficient.
>>
> But this could yield wrong loc
On Sat, Jul 18 2015 at 05:31 -0600, Ohad Ben-Cohen wrote:
Hi Lina,
On Thu, Jul 2, 2015 at 11:30 PM, Lina Iyer wrote:
You are right, RAW capability is not lock specific. But we dont want to
impose this on every lock in the bank either.
I'm not sure I'm following your concern here: drivers sti
Hi Lina,
On Thu, Jul 2, 2015 at 11:30 PM, Lina Iyer wrote:
> You are right, RAW capability is not lock specific. But we dont want to
> impose this on every lock in the bank either.
I'm not sure I'm following your concern here: drivers still need to
explicitly indicate RAW in order for this to ki
On Sat, Jun 27 2015 at 05:25 -0600, Ohad Ben-Cohen wrote:
Hi Lina,
On Sat, Jun 27, 2015 at 6:05 AM, Lina Iyer wrote:
Hi Ohad,
Any comments?
Sorry, I was under the impression the discussion with Bjorn is still open.
I am of the opinion that the platform driver and the framework should
hand
Hi Lina,
On Sat, Jun 27, 2015 at 6:05 AM, Lina Iyer wrote:
> Hi Ohad,
>
> Any comments?
Sorry, I was under the impression the discussion with Bjorn is still open.
Like Bjorn, I'm not so sure too we want to bind a specific lock to the
RAW capability since this is not a lock-specific hardware det
Hi Ohad,
Any comments?
Thanks,
Lina
On Tue, Jun 09 2015 at 10:23 -0600, Lina Iyer wrote:
This patch follows the discussion based on the first RFC series posted on the
mailing list [1]. The discussion resulted in a couple of directives for
hwspinlocks that do not want the framework imposing a s
This patch follows the discussion based on the first RFC series posted on the
mailing list [1]. The discussion resulted in a couple of directives for
hwspinlocks that do not want the framework imposing a s/w spinlock around the
hwspinlock.
i. The default should only be a s/w spinlock around the hw
12 matches
Mail list logo
