On Sat, 2003-05-31 at 00:56, Mark A. Greer wrote:
> [snip] > My guess is > that your board's fw (or early kernel init code) is setting it up with > the correct value but on the other systems you mentioned, the fw doesn't > (and the reset value of 0x00 is returned). Basically, if I'm > interpreting the manual correctly, you probably need to do something > other than count on the fw setting up that field in that reg correctly. For boards derived from the linuxppc_2_4_devel tree, everything works. I've now done kernel ports for several MPC107 based boards, all derived from that tree, which use the "new way" you describe below. > [description of "old way" snipped] I think I may force the driver to run in polled mode on kernels which use the "old way". Many of them fail to initialise the vector in the EPIC. > The "new way" of initializing the openpic uses the openpic_set_sources() > routine which allows you to select just the vectors you want to > initialize and assign them the IRQ values that you want (independent of > their offset). Much nicer and it doesn't write to vectors/locations > that you don't want written. > > The problem for an I2C driver is that the IRQ is now board specific. > > So what to do? Well, the board-specific file needs to initialize the > I2C vector. Also, there has to be some mechanism for the board-specific > file to tell your driver what the IRQ is. Maybe the best solution is to > have the board-specific code set up the vector field in the IIVPR0 reg > with the proper IRQ and then your driver won't need to change. Seems > fairly clean but you'll have to hack the board-specific code of any > boards that will use the I2C driver. If there's any interest I could tidy up the driver and submit it into linuxppc_2_4_devel along with a patch that collects MPC107 configuration into one place. - Adrian Cox http://www.humboldt.co.uk/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
