ron minnich wrote:
On 5/28/07, Ben Hewson ben@hewson-venieri.com wrote:
device pnp 2e.a off end # ACPI
it's a pnp (multi-function) device The pnp can not be probed as PCI is, so we tell Config.lb that the base address is 2e (PNP devices usually appear at 2e or 4e) On base address 2e, it is device 0xa It is not enabled -- this is a common enable setting, at byte 0x30 in the pnp device config space for all pnp devices.
Since it is off, there are no real parameters to program it. End ends the block.
I will be glad when we move to dts syntax :)
Why does this enable ACPI? I wonder if this comment is a mistake. We would have to look at the chip itself to see.
device pci 11.4 on end # ACPI
this I have turned to "ON" and the ACPI is now being configured.
great, an ACPI-knowledgeable person will have to tell us what an ACPI device does. My ignorance is unlimited in this area .
Don't think that is me, sort of getting the hang of it, but it is slow going and I haven't even started on the ASL file yet.
What is the process for adding a #define in the Config.lb/Options.lb files.
I would like to declare an ACPI_IOBASE and possibly a HW_MONITOR_IOBASE that get used in 2 different files. Now I could #include a common file using a relative path but this seems messy to me as one file is in mainboard and the other in southbridge or even just hard code them.
Ideally it would be nice to include these as an option in Config.lb/Options.lb, but obviously it may be of limited use. The EPIA-M mainboard could make use of it, not sure about the other examples though.
Oh also while it is not an error as such in src/southbridge/via/vt8235/vt8235_lpc.c (EPIA-M)
there are the following 2 lines (115-116) // Set ACPI base address to IO 0x4000 pci_write_config16(dev, 0x88, 0x0401);
Now I know it is probably a bit anal (pardon the language) but I hate comments that don't match the code. I am just as guilty of this as the next person, where I write an initial comment and then later change the code but leave the comment the same. It just makes it harder for anyone coming along later. So shall I submit a patch or just forget it ?
Is I/O port 0x400-0x480 safe to use ? seems very low down address wise.
I am just glad OLPC does not do ACPI -- maybe OLPC will help kill ACPI in the long run :-)
thanks
ron
thanks Ben