From: Samuel Ortiz <sameo@linux.intel.com>
To: Daniel Drake <dsd@laptop.org>
Cc: Paul Fox <pgf@laptop.org>, Andres Salomon <dilinger@queued.net>,
linux-kernel@vger.kernel.org
Subject: Re: MFD cell structure and sharing of resources
Date: Thu, 16 Dec 2010 11:35:50 +0100 [thread overview]
Message-ID: <20101216103550.GA5946@sortiz-mobl> (raw)
In-Reply-To: <AANLkTinrF-dxiw7OQ=dMhQPgKSqS6yYfDzdcnHfhMtyf@mail.gmail.com>
Hi Daniel,
On Fri, Dec 10, 2010 at 03:37:30PM +0000, Daniel Drake wrote:
> A few options that spring to mind:
>
> 1. Adjust the list of mfd cells in drivers/mfd/cs5535-mfd so that
> rather than being a list of resources, it is a list of drivers that
> rely on the mfd driver. The entries would be: gpio, mfgpt,
> olpc-xo1-pm, olpc-xo1-sci. olpc-xo1-pm would have the 2 resources it
> needs (pms & acpi), and the acpi resource would be duplicated into
> olpc-xo1-sci too.
>
> We'd then add a machine_is_olpc() check inside cs5535-mfd so that the
> OLPC-specific cells are only passed to mfd_add_devices on OLPC
> laptops.
>
> 2. Continue with Andres' olpc-xo1-pm patch that makes that driver act
> as a driver for both acpi & pms. When both resources are available, it
> could probe an olpc-xo1-sci platform device as a child of itself,
> having the ACPI resource shared on the platform_device level (similar
> to how MFD shares resources via cells).
This sounds like an acceptable solution to me.
> 3. For olpc-xo1-pm and olpc-xo1-sci, forget about hooking into MFD and
> go back to the route of looking for the appropriate device on the PCI
> bus and accessing the regions that way.
I see a 4th solution though:
Define and export a set of I/O routines from the MFD driver, for the shared
resources. The routines would take as arguments one of the shared module
(ACPI, PMS, etc..) and a register (and obviously a value for the writing
parts...), and do the I/O operation for your driver. This is similar to what
the twl driver does, although over i2c.
That means requesting and releasing the shared regions from the MFD driver,
before knowing if there is a user for it or not. I realize this could lead to
some resource conflicts, although this is very unlikely. Potentially, we could
have a callback into the MFD driver from the subdevice to let it know that the
resource is requested. But then your #2 solution would look better to me.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
next prev parent reply other threads:[~2010-12-16 10:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-10 15:37 MFD cell structure and sharing of resources Daniel Drake
2010-12-10 16:34 ` Daniel Drake
2010-12-16 10:35 ` Samuel Ortiz [this message]
2010-12-16 15:38 ` Daniel Drake
2010-12-24 10:45 ` Samuel Ortiz
2010-12-25 6:48 ` Andres Salomon
2010-12-25 14:23 ` Mark Brown
2010-12-24 23:56 ` Andres Salomon
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=20101216103550.GA5946@sortiz-mobl \
--to=sameo@linux.intel.com \
--cc=dilinger@queued.net \
--cc=dsd@laptop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pgf@laptop.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