On Sun, 7 Dec 2008, Wolfgang Denk wrote: > Dear [EMAIL PROTECTED], > > In message <[EMAIL PROTECTED]> you > wrote: >> >> As for the SM502, it is a multi-function chip that has more than just > video. >> I'm writing an I2C driver for it right now and I want to ask you guys > for >> your opinion. > > That's not new - the SM501 is pretty similar.
As a matter of fact, SM501 is an older, now nonexistent version of SM502. Its support in U-Boot is rudimentary. I'd rather removed that old sm501.c altogether and replaced it with a new sm502.c. That should work for old SM501 chips if there are still any in existence. Support is much better in Linux kernel -- it is almost fully supported out of the box, video, USB, sound etc. >> MPC8548 has _TWO_ I2C controllers and it is taken care of in fsl_i2c.c > by >> defining a "bus number." There is a function that one uses to set a > bus for >> consecutive operations with i2c_read() and friends (they do NOT take a > bus >> number as a parameter.) That means one sets a bus and then all the >> operations are done on that bus until it is changed again. > > That's the general idea, also for example for device handling: we set > a current device (or bus) with one command, and then continue to use > that. > >> This might be OK but it is definitely not portable and SOC-specific. > In my > > I think the "this" here refers to the specific implementation, not the > general approach, right? Yes. >> case I have a _THIRD_ I2C bus off of SM502... What do you think would > be a >> best approach to address this: >> >> a.) Rewrite _ALL_ I2C code to make those i2c_read() etc. functions to > take >> an additional parameter, bus number >> >> b.) Make a global var i2c_bus or something and add a global function > kinda >> i2c_set_bus() so all i2c_read()/i2c_write() functions use that > variable >> >> c.) Add a third bus for SM502 I2C adapter to fsl_i2c.c (horrible hack) >> >> d.) Make SM502 I2C a totally separate entity with its own set of > functions >> (like sm502_i2c_read() etc.) >> >> Please tell what you think. I personally lean towards option b.) but I > might >> be wrong :) > > I agree. OK, so I'll take that route. >> And there is another useful part of SM502 that's begging for > implementation >> -- USB controller with legacy KBD/Mouse support... > > Feel free to submit patches :-) Sure, but there are other things that must me done before that USB. I need Silicon Image Sil3124A SATA driver first :) --- ****************************************************************** * [EMAIL PROTECTED] KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ****************************************************************** _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
