Hi Mike, On Thu, Aug 18, 2011 at 1:53 PM, Mike Frysinger <[email protected]> wrote: > On Thursday, August 18, 2011 15:01:28 Simon Glass wrote: ... >> OK that's not how it is at the moment in some cases, but fair enough. >> We have been pushing Tegra in that directly as it happens, but >> certainly there is still a fair amount of mandatory init which should >> be moved into / called from drivers. > > if there's specific frameworks/arches that always init hardware, then in > general that's a bug and we should treat it as such (the u-boot policy doc > explicitly bans this). each framework (since they're all open coded in their > own way) will need to be reviewed. but hopefully there shouldn't be many.
OK ... >> Er ok, but I found one in stdio.c! > > i'd also vote that as a bug :). in looking at the history, i think this is > just a really old wart that we should burn off (it predates the git history > which goes back to 2000-2002). if there are specific devices that need i2c, > they themselves should be calling i2c_init(). > > i know Wolfgang is sometimes hesitant to change these long seated things, so > we might have to do what i was doing with the nand change ... the default is > kept for a while, but people get a build warning if they are implicitly opted > into the old behavior. and if a board porter hasnt picked up their pieces by > the time we drop the old behavior, well that's now their problem. most people > (the active) ones will continue to work. > > check out the commit here: > http://git.denx.de/?p=u-boot/u-boot- > blackfin.git;a=commit;h=df57f7de71fd1540991a0099be307a65679c53bb OK I see. ... >> We can't have a sensible console in U-Boot without keyboard and LCD - >> for me the splash screen is a separate issue. >> >> Yes the single-threaded problem does make it tricky. Am thinking about >> that problem now. > > if the hardware can be split up into the "prime the settings, wait for things > to prime, and then do something else", you could (ab)use the current board > callback system (where the board gets access to a few hooks along the way) to > split up the LCD init so that the polling-some-registers part doesnt really > happen. Yes - would like to hide all delays behind other running code, without firing up the second CPU. But LCD is the worst. > > if you wanted to talk about not touching the LCD at all *unless* someone > wanted to interact with the keyboard, that might be an interesting discussion. > we could add a hook to the shell interpreter where it would call a board func > upon first user input. then you could skip the LCD part in the default (since > you just want to boot linux automatically), but if someone wanted to interrupt > that and talk to u-boot to debug, you'd get a slight pause. optimize for the > common and make the uncommon [debug] step take a little longer. That's exactly the sort of thing that I think a driver framework would handle nicely, and generically. ... >> I suppose the ad-hoc nature of drivers means that people miss the >> 'generally accepted way' that things are supposed to be done. > > yes, but over the years i think (hope?) we've gotten better at catching this > when someone submits something new. > -mike > Yes, the code is definitely improving so I think you are right. Regards, Simon _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
