Re: Handling device shared SFR on dt platform

[Grant Likely <grant.likely@secretlab.ca>]

On Wed, 28 Mar 2012 21:45:14 +0200, Sylwester Nawrocki <snjw23@gmail.com> wrote:
> Hello Grant,
> 
> On 03/24/2012 08:32 PM, Grant Likely wrote:
> >
> > Generally, this is handled by having a third node for the shared
> > register block and both device nodes holding a phandle to it.
> > 
> > No, there isn't any common infrastructure for implementing this, but
> > it isn't very much code.
> 
> Thank you, that sounds good. I'm just wondering how to handle the shared
> resource access synchronisation. There is an IORESOURCE_MUXED resource type 
> flag which could be used to prevent drivers from stomping on each others 
> feet when accessing the shared register, if I understand the software muxed
> resource semantics correctly. That is, using something like 
> request_muxed_(mem_)region()/release_mem_region() for the shared register
> protection.
> 
> What concerns me, is an overhead from region request/ioremap(?)/release, just
> to access a single 32-bit register. I'm going to see if those accesses could
> be moved to only device driver's probe() and remove() callbacks and what might
> be the resulting power consumption increase from that, if any.

Personally, I'd just create a shared function used by both drivers to
access the register and protect it with a spinlock.  That way the
region only needs to be mapped once, and the overhead is as low as
possible.

g.