Bug#281952: additional /proc/device-tree patch for this issue. ...

[Juergen Kreileder]

Sven Luther <sven.luther@wanadoo.fr> writes:

> On Sat, Jan 22, 2005 at 08:37:59PM +0100, Juergen Kreileder wrote:
>>
>>> As you see, the crux of this patch is to check for the existence
>>> of a via-pmu device in the firmware provided device-tree.
>>
>> This isn't really good enough.  My machine (G5) has a PMU, it's in
>> the
>
> Ah, yes. Is it a via-pmu ? I don't think so,

It's a via-pmu: 

,----[ dmesg | grep -i pmu ]
| via-pmu: Server Mode is disabled
| PMU driver 2 initialized for Core99, firmware: 0c
`----

> and so accordying to current kernel sources, there is no /dev/pmu
> created, which is the exclusive domain of via-pmu.c.

,----[ From linux-2.6.10/drivers/machintosh/via-pmu.c ]
| #ifdef CONFIG_PMAC_PBOOK
| 
| [...]
|  
| static struct file_operations pmu_device_fops __pmacdata = {
|         .read           = pmu_read,
|         .write          = pmu_write,
|         .poll           = pmu_fpoll,
|         .ioctl          = pmu_ioctl,
|         .open           = pmu_open,
|         .release        = pmu_release,
| };
| 
| static struct miscdevice pmu_device __pmacdata = {
|         PMU_MINOR, "pmu", &pmu_device_fops
| };
| 
| void pmu_device_init(void)
| {
|         if (!via)
|                 return;
|         if (misc_register(&pmu_device) < 0)
|                 printk(KERN_ERR "via-pmu: cannot register misc device.\n");
| }
| #endif /* CONFIG_PMAC_PBOOK */
`----

That means device 10:154 doesn't get registered unless CONFIG_PMAC_PBOOK
is set
=> I don't get /dev/pmu at all with udev. (Without udev accessing the
10:154 /dev/pmu will just give ENODEV.)

> Can you provide me with your /proc/device-tree/aliases content please ? 

,----[ ls /proc/device-tree/aliases ]
| cd          k2-cd          mac-io      pci4    sd1          uni-n   veo0
| cd1         k2-enet        macio-mpic  pci5    sd2          usb0    veo1
| cpu0        k2-fw          mouse       pci6    sd3          usb1    veo2
| cpu1        k2-mac-io      name        pci7    second-boot  usb-1a  veo3
| dart        k2-sata        nvram       rtc     u3           usb-1b  via-pmu
| eject-key   k2-uata        pci         sata    uata         usb2    vsp
| enet        keyboard       pci0        scca    ui2c         usb-2a  wireless
| first-boot  ki2c           pci1        sccb    ultra0       usb-2b
| fw          last-boot      pci2        screen  ultra1       usb-2c
| hd          linux,phandle  pci3        sd0     uni-mpic     usb3
`----

,----[ cat /proc/device-tree/aliases/via-pmu ]
| /ht/pci@3/mac-io/via-pmu
`----

> Do you know how we can check for machines which have a fblevel
> control ?

Maybe the tests in
linux/arch/ppc/platforms/pmac_backlight.c::register_backlight_controller
are what this code should use, ie. look for a backlight device:

,----
|         bk_node = find_devices("backlight");
| 
| #ifdef CONFIG_ADB_PMU
|         /* Special case for the old PowerBook since I can't test on it */
|         backlight_autosave = machine_is_compatible("AAPL,3400/2400")
|                 || machine_is_compatible("AAPL,3500");
|         if ((backlight_autosave
|              || machine_is_compatible("AAPL,PowerBook1998")
|              || machine_is_compatible("PowerBook1,1"))
|             && !strcmp(type, "pmu"))
|                 valid = 1;
| #endif
|         if (bk_node) {
|                 prop = get_property(bk_node, "backlight-control", NULL);
|                 if (prop && !strncmp(prop, type, strlen(type)))
|                         valid = 1;
|         }
`----

linux/arch/ppc64 doesn't have any backlight support so far.

The only thing that worked on my PowerMac G5 with a ppc64 kernel, when
I patched it to enable /dev/pmu without CONFIG_PMAC_PBOOK, was getting
events from the power button.


        Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux/java2-status/