[U-Boot] [PATCH] 7/12 Multiadapter/multibus I2C, drivers part 4
ksi at koi8.net
ksi at koi8.net
Thu Feb 19 20:52:48 CET 2009
On Thu, 19 Feb 2009, Heiko Schocher wrote:
> Hello ksi,
>
> ksi at koi8.net wrote:
> > On Thu, 19 Feb 2009, Heiko Schocher wrote:
> >
> >> Hello ksi,
> >>
> >> ksi at koi8.net wrote:
> >>> On Wed, 18 Feb 2009, Heiko Schocher wrote:
> >>>
> >>>> Hello Wolfgang,
> >>>>
> >>>> Wolfgang Denk wrote:
> >>>>> Dear ksi at koi8.net,
> >>>>>
> >>>>> In message <Pine.LNX.4.64ksi.0902171233390.30435 at home-gw.koi8.net> you wrote:
> >>>> [...]
> >>>>>>> What makes you insist that we cannot change a variable if we need to
> >>>>>>> be able to change one?
> >>>>>> It is NOT just variable. My approach uses i2c _BUS_, not _ADAPTER_. And
> >>>>>> number of busses can be bigger than number of adapters (e.g. when some
> >>>>>> busses a reached via muxes or switches.) When doing i2c_set_current_bus()
> >>>>>> you are switching _NOT_ adapters, but busses. That involves not only
> >>>>>> changing that global variable but also reprogramming muxes/switches for
> >>>>>> i2c_set_current_bus() to be consistent and hardware independent. Otherwise
> >>>>>> your code should know if that particular bus it is switching to is directly
> >>>>>> connected or switched and check the bus it is switching from for muxes. If
> >>>>>> they are switched, your code should disconnect the current bus switches,
> >>>>>> then do that i2c_set_current_bus() and connect the switches to the new bus
> >>>>>> after that.
> >>>>>>
> >>>>>> That means that code MUST somehow know the topology to take appropriate
> >>>>>> actions and properly configure those switches. That means you should somehow
> >>>>>> describe that topology for each and every board in CONFIG_* terms and make
> >>>>>> each and every place at U-Boot that invokes _ANY_ i2c function to take care
> >>>>>> of that switching.
> >>>>> You convinced me. This code must not be used before relocation to RAM,
> >>>>> then.
> >>>> But is is possible to use that code when running from flash, if
> >>>> this current pointer is writeable ...
> >>> It is not the pointer that must be writeable, it's what it is pointing to...
> >> But in your approach this is also not writeable! So we lost nothing, when
> >> using such a pointer.
> >
> > No, we did NOT. I can still cal adap[N]->init() and it will init the proper
>
> For what you will do this, when you can;t use the adapter, when running from
> flash? See Later, why you cannot use it.
Using multiple adapters while running from flash is an exception. I can let
myself call adapter-specific functions directly if needed, without changing
busses.
> > adapter. It does NOT require any global variables for it, it is
> > self-sufficient.
>
> But you could not switch busses, nor work with it, first because
> i2c_set_bus_num() don;t work for you and i2c_cur_bus is not writeable,
> so _all_ accesses with the API in i2c-core.c like for example
>
> int i2c_read(u_int8_t chip, unsigned int addr, int alen,
> u_int8_t *buffer, int len)
> {
> return(ADAP(i2c_cur_bus)->read(chip, addr, alen, buffer, len));
> }
>
> _will_ fail, when running from flash, because i2c_cur_bus is not
> writeable!
>
> So why will you initialize all adapters when running from flash?
>
> But this is no problem, when we make i2c_cur_bus or this pointer
> I would like to see, writeable. And think about my proposal for
> i2c_set_bus_num() and we have there also no problem with calling
> init() for an adapter.
I'm against using global variables at all. And I will never ever use them in
object's member functions, that's a blasphemy.
---
******************************************************************
* KSI at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
More information about the U-Boot
mailing list