Re: [patch] turn off backlight on 12" pbook
On Fri, 2003-10-31 at 19:58, Michael Schmitz wrote:
> > > Can the classic emulation be used for this?
> >
> > No. Unfortunately, Macsbug is useful for tracking HW access, but classic
> > emulation does no HW access, it all gets routed to underlying OS X drivers
>
> That's what I feared. I'll leave it to others, then.
>
> On the 2.6 front, I've _once_ been able to get the kernel to boot all the
> way, and backlight control did work as expected. 99% of the time though,
> the kernel barfs sometime after rivafb init. xmon output goes to serial
> which is utterly pointless on a flat panel iMac
Tried forcing use_screen to 1 in xmon ? if that doesn't work, you have
the option of using firewire debugging :) I pushed a working xmon over
firewire to my 2.6 tree, though to use it, you'd have to hack ordering
so that OHCI gets loaded before rivbafb, and probably hack a delay so
you have time to "attach" from the remote host
> so I'm resorting to poor
> man's debugger techniques. The console code appears to tweak the backlight
> state a couple of times (upon registering the backlight controller, the
> backlight gets turned on, then off, then on again) and depending on the
> amount of delay I introduce by adding printk() output, the crash happens
> at different times after rivafb init. I'm suspecting stray interrupts, or
> concurrent access to the graphics adapter by other code, or high bogon
> flux, or some such.
> Is there a way to delay registering the backlight controller until later time
> during boot?
I wouldn't trust such a solution. If there is a race, you'll only "move" it
by doing so. If for some reason, for example, we mustn't touch the card while
doing the backlight bit for a while, then you'd rather add delays here or
there and eventually a spinlock. Maybe those accesses are fifoed or you need
to make sure the engine is empty before doing them ? tried without
acceleration ? Or it's just a delay to wait for the PLL to lock properly.
Ben.
Reply to: