Hi, On Wed, Jun 18, 2008 at 01:48:26PM -0500, Menon, Nishanth wrote: > What issues do you see with the proposed patch set I have send out - > other than it bases itself on Linux kernel?
I've commented your first patch in the series; in short: - It shows nicely that it is easy to copy things over from Linux - that's a good sign that we didn't do too many things the wrong way. But note, it is *not* the main intention of u-boot-v2 to be a Linux clone. It is a bootloader, and it tries to be one with a neat design, combining the best of POSIX, Linux and U-Boot-v1. Copying *ideas* is good, but let's do it in a way that it still is u-boot. - Please don't bring in things which are not part of the current code base. If you add code for subsystems, the subsystems must be there first and *then* their users. Otherwhise we bloat the codebase and we disable the possibility to add *real* support for PCI, USB and S390 later :-) > It meets the following requirements: > > a) does meet all the use cases folks need with i2c: > > i) bare bone i2c arch -> don't use client drivers, just stick > around with adapter and use i2c_transfer or smbus ops which ever > you'd like. > ii) someone wants to write a client for a commonly used device > ->eeprom or the like.. feel free to do so. No problem with that. > iii) does it support multiple buses? Oh yeah it does. So does it > support multiples speed busses too. That's also a requirement. > b) does it fit in device-driver model? Yep it does. Sure. > c) Is it small? I don't see 6K a big overhead considering similar > addition due to devfs or nand support.. in fact my adapter driver > could be eating a chunk of that 6K. See above. Check how Sascha's code for console, serial or clocksource looks like. It really *looks* like Linux from the outside, but it is much, much smaller and better aligned for bootloader use. Back to my proposal: > > So I suppose the right way to proceed is: > > > > - let's first define use cases for what you want to achieve with the i2c > > support in u-boot-v2 > > > > - let's have a look at how it would integrate into the device/driver > > model and how the user-visible API would look like > > > > - write a small framework for i2c, with host+algo+device parts, heavily > > inspired by the best of Linux and the best of u-boot/u-boot-v2. Which part of i2c do we actually *need* in the bootloader? What's *your* use case? I assume we need i2c host controllers, that's quite clear. We also need an abstraction for i2c devices. The only devices I have seen which really needed a bootloader driver are a) eeproms b) RTCs c) analog/digital in/outputs (i.e. gpio expanders) Other use cases? Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ U-Boot-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/u-boot-users
