Hi Mike,
On Thu, Aug 18, 2011 at 1:53 PM, Mike Frysinger vapier@gentoo.org 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