Re: [RFC 0/2]convert ACPI driver model to Linux driver model

[Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

Hi,
On Wed, 2005-09-21 at 00:31 -0400, Adam Belay wrote:
> 
> On Mon, Sep 12, 2005 at 01:22:22PM +0800, Shaohua Li wrote:
> > Hi,
> > I'm sending the patches out not for merging but for comments. The
> > patches try to convert ACPI driver model to Linux driver model. There
> > are still many things unsettled. If you have any
> > comment/suggestion/requirement, please let me know.
> > 
> > 1. in my mind, acpi should export two sets of info in sysfs. One is
> > current namespace subsystem, it should just export the firmware info.
> > All acpi device/drivers related info don't export here. The other is
> > ACPI bus. It's similar with other buses like PCI bus.
> 
Thanks for your time to look at it.

> I'm not sure if we want to export the ACPI namespace in sysfs.  In
> theory, we can attach most of that information on to the device tree
> directly.  I agree that an ACPI bus would be useful.  I think it should
> represent every device that can't be enumerated by another standard.
I guess we can delay the discussion about if ACPI namespace should be in
sysfs. We can do it after converting ACPI to Linux driver model.

> > 
> > 2. I regard all devices which don't belong to physical buses in the DSDT
> > as ACPI bus devices. Ideally, PCI devices, PNP devices & other devices
> > should bind them to their physical buses. Since many devices listed in
> > DSDT aren't in ACPI bus, this makes it impossible to convert current
> > acpi driver model into Linux style. You might look at my patch, many
> > routines required by Linux driver model are empty. Though we can't
> > completely utilize the advantage of Linux driver model, the partial
> > convert still benefits us many such as sysfs support and suspend/resume
> > support.
> 
> This partial implementation has its advantages, but it's also important
> to have a well defined plan of transition.  I think we should migrate the
> ACPI code entirely to the linux driver model.  I've made some progress on
> this issue.
I have some troubles to migrate ACPI code entirely to linux driver model
(I mentioned in my previous email). It would be great to look at your
patches if possible.

> > 
> > 3. The acpi namespace hotplug interface looks strange. After we
> > introduce ACPI bus (CPU is in the bus), we can send hotplug event
> > through it. So I'd like to remove the namespace hotplug interface later.
> 
> Agreed.
> 
> > 
> > There are something to prevent us from completely converting ACPI driver
> > model to Linux style:
> > 1. Current ACPI driver model can register drivers for all devices listed
> > in DSDT. ACPI bus can't handle this.
> 
> I'm assuming you're referring to devices that don't need ACPI for
> enumeration.  All other types shouldn't be a problem.
Yes, exactly.

> 
> I've ran into this with some of my PCI bus code.  My current strategy is
> to move the responsibility of attaching firmware data to the specific
> device driver of the device in question rather than having the ACPI bus
> handle it.  The idea is that only ACPI-aware drivers will utilize ACPI,
> otherwise it will be ignored.  Essentially, ACPI aware devices will serve
> as anchoring points for ACPI objects, including those that belong to the
> ACPI Bus type.  Any comments?
So only devices belonging to ACPI bus can register ACPI driver and other
devices listed in ACPI table can have an ACPI handler and execute some
ACPI methods but they can't register an ACPI driver, right? Looks good.
I also have similar idea. In my mind, there are a firmware driver and an
ACPI driver. All devices listed in ACPI table are able to have a
firmware driver. Devices in ACPI bus can have an ACPI driver.

> 
> > 2. Current ACPI hotplug (CPU/IO) relays on separate .add/.start
> > callbacks, but Linux driver can only provide a .probe. We might split
> > ACPI hotplug support to separate drivers.
> > Since these, my patch just adds fake Linux driver model support, but it
> > still is very useful.
> 
> This was also an issue that I came across.
> 
> Could you explain the role of .add/.start and why it's necessary?  It
> may be reasonable to add this functionality to the Linux driver model
> so that other drivers can utilize it.
Let's see an example of ACPI PCI root bridge hotplug. When a new root
bridge is added, the root bridge's .added (scan PCI devices) method is
called. And after we we allocated resources to PCI devices under the
bridge, we start (call .start, add PCI devices into global PCI tree, as
a result, binding devices with drivers) the bridge. The processor driver
is another example. The seperate .add/.start makes the driver can work
on both the non-hotplug and hotplug cases. The syntax mixed the
functionalities of controlling the device and controlling hotplug the
device. 

Thanks,
Shaohua



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php