From: snjw23@gmail.com (Sylwester Nawrocki)
To: linux-arm-kernel@lists.infradead.org
Subject: Handling device shared SFR on dt platform
Date: Wed, 28 Mar 2012 21:45:14 +0200 [thread overview]
Message-ID: <4F736A4A.6050302@gmail.com> (raw)
In-Reply-To: <20120324193200.822AD3E0B06@localhost>
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.
--
Thanks,
Sylwester
next prev parent reply other threads:[~2012-03-28 19:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-21 22:38 Handling device shared SFR on dt platform Sylwester Nawrocki
2012-03-24 19:32 ` Grant Likely
2012-03-28 19:45 ` Sylwester Nawrocki [this message]
2012-04-03 16:04 ` Grant Likely
2012-04-04 20:35 ` Sylwester Nawrocki
2012-04-07 1:41 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F736A4A.6050302@gmail.com \
--to=snjw23@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).