> I'd have to have a remote host to attach in the first place. That's a > real sick idea there. I'd rather hack xmon over ethernet :-)
Well, it's actually far from beeing sick :) The nice thing is that the 1394 protocol let a node tap physical addresses in the memory of another node. The actual "meaning" of those addresses is dependent on the kind of node, but typically, if you enable it on the OHCI controller (done by default by our driver), the "remote" machine can tap directly to any memory location of the target. Writing a small stub just enabling that "feature" of the controller early is much more easier than writing an ethernet stub. Also, I already wrote the small horrible polled protocol for xmon to discuss with a remote host that way :) > > > 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 > > mdelays didn't help, already tried that. Moving a race until after the > screen has properly initialized (fbcon taken over from initial console) > would help some, plus prove it's a race. > > > 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. > > I'll try to wait_for_idle first. For applying a spinlock I'd have to know > what other tasks are accessing the card :-). Ben.
