[PATCH/RFC 0/4]Bind physical devices with ACPI devices

[PATCH/RFC 0/4]Bind physical devices with ACPI devices

[Li Shaohua]

Hi,
ACPI provides many functionalities for physical devices. Such as for
suspend/resume, ACPI can tell us correct devices D-state for S3. There
are tons of devices enhancement for both realtime and boot time from
ACPI. To utilize ACPI, physical devices like PCI devices must know its
partner. The patches try to do this. After this is done, we can enhance
many features, such as improve suspend/resume.
These patches are against 2.6.10-rc1, please give your comments.

Thanks,
Shaohua

Re: [ACPI] [PATCH/RFC 0/4]Bind physical devices with ACPI devices

[Matthew Wilcox]

On Mon, Nov 08, 2004 at 12:11:06PM +0800, Li Shaohua wrote:
> ACPI provides many functionalities for physical devices. Such as for
> suspend/resume, ACPI can tell us correct devices D-state for S3. There
> are tons of devices enhancement for both realtime and boot time from
> ACPI. To utilize ACPI, physical devices like PCI devices must know its
> partner. The patches try to do this. After this is done, we can enhance
> many features, such as improve suspend/resume.
> These patches are against 2.6.10-rc1, please give your comments.

I don't think this is a great way to do it.  There's at least two other
examples of firmware that interacts with drivers in a similar way that you
could look at -- PA-RISC's PDC and Sun/Apple/IBM OpenFirmware.  I don't
know much about OpenFirmware, and I just redid the way parisc_device
works, so I'll discourse about that for a bit.

>From a driver's point of view, it's simple.  Call a function to get
a cookie (an acpi_handle for ACPI, I guess), then pass that cookie to
whatever functions necessary.  This is the code in the sym2 SCSI driver:

#ifdef CONFIG_PARISC
/*
 * Host firmware (PDC) keeps a table for altering SCSI capabilities.
 * Many newer machines export one channel of 53c896 chip as SE, 50-pin HD.
 * Also used for Multi-initiator SCSI clusters to set the SCSI Initiator ID.
 */
static int sym_read_parisc_pdc(struct sym_device *np, struct pdc_initiator *pdc)
{
        struct hardware_path hwpath;
        get_pci_node_path(np->pdev, &hwpath);
        if (!pdc_get_initiator(&hwpath, pdc))
                return 0;

        return SYM_PARISC_PDC;
}
#else
static int sym_read_parisc_pdc(struct sym_device *np, struct pdc_initiator *x)
{
        return 0;
}
#endif


Hm.. ACPI doesn't really hanve anything SCSI-related in it.  Let's look at
IDE's _GTM and _STM for examples.  

static void ide_acpi_gtm(struct hwif_s *hwif, struct acpi_timing_mode *tm)
{
	acpi_handle handle;
	acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL};
	acpi_status status;

	handle = acpi_get_gendev_handle(&hwif->gendev);
	status = acpi_evaluate_object(handle, "_GTM", NULL, &buffer);
	...
}

All we need is an acpi_get_gendev_handle that takes a struct device and
returns the acpi_handle for it.  Now, maybe that'd be best done by placing
a pointer in the struct device, but I bet it'd be just as good to walk
the namespace looking for the corresponding device.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [ACPI] [PATCH/RFC 0/4]Bind physical devices with ACPI devices

[Li Shaohua]

On Mon, 2004-11-08 at 21:56, Matthew Wilcox wrote:
> On Mon, Nov 08, 2004 at 12:11:06PM +0800, Li Shaohua wrote:
> > ACPI provides many functionalities for physical devices. Such as for
> > suspend/resume, ACPI can tell us correct devices D-state for S3. There
> > are tons of devices enhancement for both realtime and boot time from
> > ACPI. To utilize ACPI, physical devices like PCI devices must know its
> > partner. The patches try to do this. After this is done, we can enhance
> > many features, such as improve suspend/resume.
> > These patches are against 2.6.10-rc1, please give your comments.
> 
> I don't think this is a great way to do it.  There's at least two other
> examples of firmware that interacts with drivers in a similar way that you
> could look at -- PA-RISC's PDC and Sun/Apple/IBM OpenFirmware.  I don't
> know much about OpenFirmware, and I just redid the way parisc_device
> works, so I'll discourse about that for a bit.
> 
> From a driver's point of view, it's simple.  Call a function to get
> a cookie (an acpi_handle for ACPI, I guess), then pass that cookie to
> whatever functions necessary.  This is the code in the sym2 SCSI driver:
> 
> #ifdef CONFIG_PARISC
> /*
>  * Host firmware (PDC) keeps a table for altering SCSI capabilities.
>  * Many newer machines export one channel of 53c896 chip as SE, 50-pin HD.
>  * Also used for Multi-initiator SCSI clusters to set the SCSI Initiator ID.
>  */
> static int sym_read_parisc_pdc(struct sym_device *np, struct pdc_initiator *pdc)
> {
>         struct hardware_path hwpath;
>         get_pci_node_path(np->pdev, &hwpath);
>         if (!pdc_get_initiator(&hwpath, pdc))
>                 return 0;
> 
>         return SYM_PARISC_PDC;
> }
> #else
> static int sym_read_parisc_pdc(struct sym_device *np, struct pdc_initiator *x)
> {
>         return 0;
> }
> #endif
> 
> 
> Hm.. ACPI doesn't really hanve anything SCSI-related in it.  Let's look at
> IDE's _GTM and _STM for examples.  
> 
> static void ide_acpi_gtm(struct hwif_s *hwif, struct acpi_timing_mode *tm)
> {
> 	acpi_handle handle;
> 	acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL};
> 	acpi_status status;
> 
> 	handle = acpi_get_gendev_handle(&hwif->gendev);
> 	status = acpi_evaluate_object(handle, "_GTM", NULL, &buffer);
> 	...
> }
> 
> All we need is an acpi_get_gendev_handle that takes a struct device and
> returns the acpi_handle for it.  Now, maybe that'd be best done by placing
> a pointer in the struct device, but I bet it'd be just as good to walk
> the namespace looking for the corresponding device.
I would agree with you if ACPI just supports PCI bus type, but ACPI
supports many bus types. We can't get an ACPI handler if only has a
'struct device'. You might say we can get its bus type from device->bus,
but we need a 'switch-case' to get what exactly the bus type is, but
this can't apply for loadable module bus type.

Thanks,
Shaohua

Re: [ACPI] [PATCH/RFC 0/4]Bind physical devices with ACPI devices

[Matthew Wilcox]

On Tue, Nov 09, 2004 at 12:08:03AM +0800, Yu, Luming wrote:
> >On Mon, Nov 08, 2004 at 10:46:30PM +0800, Yu, Luming wrote:
> >> >All we need is an acpi_get_gendev_handle that takes a 
> >struct device and
> >> >returns the acpi_handle for it.  Now, maybe that'd be best 
> >> >done by placing
> >> >a pointer in the struct device, but I bet it'd be just as 
> >good to walk
> >> >the namespace looking for the corresponding device.
> 
>   We need not only able to locate acpi object IDE0
> but also we need to locate object PRIM underneath
> IDE0,  and MSTR underneath PRIM. Thus, IDE driver 
> can fully take advantage from ACPI, in terms of 
> configuration and power management.
> 
>   Maybe we need to invent a method called
> map_device_addr_to_acpi_handle to be  generic solution.

I think we're saying the same thing in different words here ...

Note that an acpi_get_gendev_handle() or map_device_addr_to_acpi_handle()
function doesn't *preclude* putting a void * in struct device.  It does
let us choose whether or not to do so.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

RE: [ACPI] [PATCH/RFC 0/4]Bind physical devices with ACPI devices

[Yu, Luming]

>On Mon, Nov 08, 2004 at 10:46:30PM +0800, Yu, Luming wrote:
>> >All we need is an acpi_get_gendev_handle that takes a 
>struct device and
>> >returns the acpi_handle for it.  Now, maybe that'd be best 
>> >done by placing
>> >a pointer in the struct device, but I bet it'd be just as 
>good to walk
>> >the namespace looking for the corresponding device.
>> 
>>   It will fail if you just simply walk namespace to find out 
>> the corresponding acpi object, because there are NO
>> hardware id or compatible id  can be passed in.
>> Please check function acpi_bus_match.
>
>It doesn't need the HID or CID.  Look at Shaohua's patches -- 
>they don't
>use HID or CID either.
>
Yes, I made a mistake, please forget that point.

But another statement I made should be valid.
That is how to use geographical address to
locate corresponding acpi object.

For example,  ACPI define IDE as the following:

Device (IDE0){ /* primary controller */
	Name (_ADR, 0)
	Method (_GTM )
	...
	Device(PRIM) /* primary adapter */
		Name (_ADR, 0)
		Method(_GTM)
		...
		Device(MSTR) /* master channel */
			Name (_ADR,0)
			Method(_GTF)

  We need not only able to locate acpi object IDE0
but also we need to locate object PRIM underneath
IDE0,  and MSTR underneath PRIM. Thus, IDE driver 
can fully take advantage from ACPI, in terms of 
configuration and power management.

  Maybe we need to invent a method called
map_device_addr_to_acpi_handle to be  generic solution.

Thanks,
Luming


  

Re: [ACPI] [PATCH/RFC 0/4]Bind physical devices with ACPI devices

[Matthew Wilcox]

On Mon, Nov 08, 2004 at 10:46:30PM +0800, Yu, Luming wrote:
> >All we need is an acpi_get_gendev_handle that takes a struct device and
> >returns the acpi_handle for it.  Now, maybe that'd be best 
> >done by placing
> >a pointer in the struct device, but I bet it'd be just as good to walk
> >the namespace looking for the corresponding device.
> 
>   It will fail if you just simply walk namespace to find out 
> the corresponding acpi object, because there are NO
> hardware id or compatible id  can be passed in.
> Please check function acpi_bus_match.

It doesn't need the HID or CID.  Look at Shaohua's patches -- they don't
use HID or CID either.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

RE: [ACPI] [PATCH/RFC 0/4]Bind physical devices with ACPI devices

[Yu, Luming]

>All we need is an acpi_get_gendev_handle that takes a struct device and
>returns the acpi_handle for it.  Now, maybe that'd be best 
>done by placing
>a pointer in the struct device, but I bet it'd be just as good to walk
>the namespace looking for the corresponding device.

  It will fail if you just simply walk namespace to find out 
the corresponding acpi object, because there are NO
hardware id or compatible id  can be passed in.
Please check function acpi_bus_match.
  The fundamental problem here is how to use device's geographical
address( or other information ) to locate the corresponding 
acpi object in namespace.

Thanks,
Luming