Dear k...@koi8.net,
In message you wrote:
>
> > It is not an unsolvable problem. We do have the global data structure,
> > and it has been (mis-) used for worse purposes before.
>
> Not so fast... And remember, there are other similar interfaces that are
> waiting in the line (e.g. SPI...)
So
Dear k...@koi8.net,
In message you wrote:
>
> > It is our task as software engineers to tell the hardware designers
> > which designs are easy to support, nd which will cause problems in
> > the software.
>
> It is not complex. Quite in the contrary, it is much simpler and more
> straightf
Dear k...@koi8.net,
In message you wrote:
>
> > But then - how often will it bbe necessary to switch adapters before
> > relocation? What is I2C being used for? To read the SPD data for the
> > RAM init code. Which other adapter would be needed?
>
> I can not tell it right away. There might be
Hello ksi,
k...@koi8.net wrote:
> On Mon, 16 Feb 2009, Wolfgang Denk wrote:
>
>
>> Dear k...@koi8.net,
>>
>> In message you wrote:
>>
>>> OK, please explain how that cur_adap_nr->hwadapnr gets assigned. Please also
>>> explain how can one invoke a function on other adapter than "current".
On Mon, 16 Feb 2009, Wolfgang Denk wrote:
> Dear Heiko,
>
> In message <49992beb.30...@denx.de> you wrote:
> >
> > >> Yes, thats a point. But do we need this before running from ram (except
> > >> one hardwareadapter)?
> > >
> > > Yes, see above.
> >
> > Yes, thats is a problem in my approach,
On Mon, 16 Feb 2009, Wolfgang Denk wrote:
> Dear k...@koi8.net,
>
> In message you wrote:
> >
> > Yep. But nobody's perfect and you can have a situation when you need to
> > access several busses before relocation. It is not hardware for U-Boot, it
> > is U-Boot for hardware. When hardware desi
On Mon, 16 Feb 2009, Wolfgang Denk wrote:
> Dear k...@koi8.net,
>
> In message you wrote:
> >
> > OK, please explain how that cur_adap_nr->hwadapnr gets assigned. Please also
> > explain how can one invoke a function on other adapter than "current".
> > Remember, i2c_init is quite often called
On Mon, 16 Feb 2009, Wolfgang Denk wrote:
> Dear k...@koi8.net,
>
> In message you wrote:
> >
> > > Can you please send your patches with some better commit messages.
> > > You only send your Signed-off-by, without any explanation. Please
> > > change this.
> >
> > There is not much sense in e
Dear Heiko,
In message <49992beb.30...@denx.de> you wrote:
>
> >> Yes, thats a point. But do we need this before running from ram (except
> >> one hardwareadapter)?
> >
> > Yes, see above.
>
> Yes, thats is a problem in my approach, and if we need more then one
> i2c bus when running from flash
Dear k...@koi8.net,
In message you wrote:
>
> Yep. But nobody's perfect and you can have a situation when you need to
> access several busses before relocation. It is not hardware for U-Boot, it
> is U-Boot for hardware. When hardware designers design their hardware they
> don't make their decis
Dear k...@koi8.net,
In message you wrote:
>
> OK, please explain how that cur_adap_nr->hwadapnr gets assigned. Please also
> explain how can one invoke a function on other adapter than "current".
> Remember, i2c_init is quite often called BEFORE the code is relocated to RAM
> so you can NOT chan
Dear k...@koi8.net,
In message you wrote:
>
> > Can you please send your patches with some better commit messages.
> > You only send your Signed-off-by, without any explanation. Please
> > change this.
>
> There is not much sense in extensive commit messages in this case, IMHO. It
> is not a bu
Hello ksi,
k...@koi8.net wrote:
> On Sun, 15 Feb 2009, Heiko Schocher wrote:
>> k...@koi8.net wrote:
>>> On Sat, 14 Feb 2009, Heiko Schocher wrote:
k...@koi8.net wrote:
>> k...@koi8.net wrote:
>>
>>> Here is the second attempt for initial portion of multibus/multiadapter
On Sun, 15 Feb 2009, Heiko Schocher wrote:
> Hello ksi,
>
> k...@koi8.net wrote:
> > On Sat, 14 Feb 2009, Heiko Schocher wrote:
> >
> >
> >> Hello ksi,
> >>
> >> k...@koi8.net wrote:
> >>
> >>> On Fri, 13 Feb 2009, Heiko Schocher wrote:
> >>>
> k...@koi8.net wrote:
>
Hello ksi,
k...@koi8.net wrote:
> On Sat, 14 Feb 2009, Heiko Schocher wrote:
>
>
>> Hello ksi,
>>
>> k...@koi8.net wrote:
>>
>>> On Fri, 13 Feb 2009, Heiko Schocher wrote:
>>>
k...@koi8.net wrote:
> Here is the second attempt for initial portion of multibus/mu
On Sat, 14 Feb 2009, Heiko Schocher wrote:
> Hello ksi,
>
> k...@koi8.net wrote:
> > On Fri, 13 Feb 2009, Heiko Schocher wrote:
> >> k...@koi8.net wrote:
> >>> Here is the second attempt for initial portion of multibus/multiadapter
> >>> I2C support.
> >>>
> >> Can you please send your patches
Hello ksi,
k...@koi8.net wrote:
> On Fri, 13 Feb 2009, Heiko Schocher wrote:
>> k...@koi8.net wrote:
>>> Here is the second attempt for initial portion of multibus/multiadapter
>>> I2C support.
>>>
>> Can you please send your patches with some better commit messages.
>> You only send your Signe
On Fri, 13 Feb 2009, Heiko Schocher wrote:
> Hello ksi,
>
> k...@koi8.net wrote:
> > Here is the second attempt for initial portion of multibus/multiadapter
> > I2C support.
> >
>
> Can you please send your patches with some better commit messages.
> You only send your Signed-off-by, without
Hello ksi,
k...@koi8.net wrote:
> Here is the second attempt for initial portion of multibus/multiadapter
> I2C support.
>
Can you please send your patches with some better commit messages.
You only send your Signed-off-by, without any explanation. Please
change this.
> This includes a set of
Here is the second attempt for initial portion of multibus/multiadapter
I2C support.
This includes a set of common files, all drivers in drivers/i2c and all
boards affected by these changes (config files, board files, and lib_xx
files.)
There is an illustrative example of multiadapter multibus I2
20 matches
Mail list logo
