On Sun, Jan 23, 2005 at 12:37:50PM +0100, Juergen Kreileder wrote:
> Sven Luther <[EMAIL PROTECTED]> 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: 

Ok, so where is the problem ? The /dev/pmu stuff would be accessible in
acme/control-center/whatever-it-is, nd everyone will be happy ? Unless you are
telling me that you don't have blacklight control for this one ? 

> That means device 10:154 doesn't get registered unless CONFIG_PMAC_PBOOK
> is set

Well, CONFIG_PMAC_PBOOK is enabled in the debian kernels, as should be.

> => I don't get /dev/pmu at all with udev. (Without udev accessing the
> 10:154 /dev/pmu will just give ENODEV.)

Ah. So, you are not using a debian kernel, and there is no reason to support
you at all :)

> > 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/[EMAIL PROTECTED]/mac-io/via-pmu
> `----

Ok.

> > 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:

Well, we need to test this from userland, not kernelland.

> ,----
> |         bk_node = find_devices("backlight");

Ok, so there is maybe a blacklight device somewhere in /proc/devices ? 

> | #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

But these don't have a /dev/pmu ? Or do they have it ? 

> |         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.

So ...

> 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.

Ok

Friendly,

Sven Luther



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to