Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

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

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

On Fri, Aug 14 2015 at 04:52 -0600, Ohad Ben-Cohen wrote: On Thu, Aug 13, 2015 at 6:25 PM, Andy Gross agr...@codeaurora.org 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

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

On Thu, Aug 13 2015 at 00:34 -0600, Ohad Ben-Cohen wrote: On Wed, Jul 29, 2015 at 12:51 AM, Lina Iyer lina.i...@linaro.org 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

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

On Thu, Aug 13, 2015 at 6:25 PM, Andy Gross agr...@codeaurora.org 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

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

On Wed, Jul 29, 2015 at 12:51 AM, Lina Iyer lina.i...@linaro.org 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

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

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 lina.i...@linaro.org 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

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

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 lina.i...@linaro.org 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

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

Hi Lina, On Thu, Jul 2, 2015 at 11:30 PM, Lina Iyer lina.i...@linaro.org 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

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

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 lina.i...@linaro.org 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

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

Hi Lina, On Sat, Jun 27, 2015 at 6:05 AM, Lina Iyer lina.i...@linaro.org 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

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

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