> I still have to examine in depth all of the problems in the i2c-mux
> documented in Documentation/i2c/i2c-topology (thanks for having written
> those docs!), but at first sight it looks like the ATR is not going to
> introduce big problems because of how it works.
Assuming we are using the
Hi Vladimir,
On 09/09/19 05:56, Vladimir Zapolskiy wrote:
> Hi Luca, Jacopo, Wolfram, Peter,
>
> On 09/08/2019 11:45 PM, Vladimir Zapolskiy wrote:
>> Hi Luca, Jacopo, Wolfram, Peter,
>>
>> On 09/01/2019 05:31 PM, jacopo mondi wrote:
>>> Hi Luca,
>>>thanks for keep pushing this series! I hope
> Here i2c-0 is the "local" bus, i2c-4 and i2c-5 are the remote busses on
> ports 0 and 1. As you can see the eeproms are accessed using a name like
> "4-0050", meaning physical slave address 0x50 on bus 4. No alias is needed.
>
> Should you want to know the alias, perhaps for debugging (it's
Hi Vladimir,
On 09/09/19 16:10, Vladimir Zapolskiy wrote:
> Hi Wolfram,
>
> On 09/09/2019 10:22 AM, Wolfram Sang wrote:
>> Hi Vladimir,
>>
>>> I won't attend the LPC, however I would appreciate if you book some
>>
>> A pity. I would have liked to have you in the room. Let's see if we can
>> get
Hi Wolfram,
On 09/09/2019 10:22 AM, Wolfram Sang wrote:
> Hi Vladimir,
>
>> I won't attend the LPC, however I would appreciate if you book some
>
> A pity. I would have liked to have you in the room. Let's see if we can
> get enough input from you via mail here.
>
if it might help, I'll
Hi Vladimir,
> I won't attend the LPC, however I would appreciate if you book some
A pity. I would have liked to have you in the room. Let's see if we can
get enough input from you via mail here.
> time to review my original / alternative implementation of the TI
> DS90Ux9xx I2C bridge device
Hi Luca, Jacopo, Wolfram, Peter,
On 09/08/2019 11:45 PM, Vladimir Zapolskiy wrote:
> Hi Luca, Jacopo, Wolfram, Peter,
>
> On 09/01/2019 05:31 PM, jacopo mondi wrote:
>> Hi Luca,
>>thanks for keep pushing this series! I hope we can use part of this
>> for the (long time) on-going GMSL work...
Hi Luca, Jacopo, Wolfram, Peter,
On 09/01/2019 05:31 PM, jacopo mondi wrote:
> Hi Luca,
>thanks for keep pushing this series! I hope we can use part of this
> for the (long time) on-going GMSL work...
>
> I hope you will be patient enough to provide (another :) overview
> of this work during
Hi Peter,
On 04/09/19 10:09, Peter Rosin wrote:> Hi!
>
> [ Sorry about my absence. I've been meaning to comment on this series
> for a long time, but work and family keep interfering... ]
No problem, thanks for your comments. See below my reply.
>
> On 2019-09-03 09:31, Luca Ceresoli wrote:
Hi!
[ Sorry about my absence. I've been meaning to comment on this series
for a long time, but work and family keep interfering... ]
On 2019-09-03 09:31, Luca Ceresoli wrote:
> Hi Jacopo,
>
> thanks for your feedback.
>
> On 01/09/19 16:31, jacopo mondi wrote:
>> Hi Luca,
>>thanks for
> > One huge drawback for me is the attach/detach callbacks. One year ago, I
> > removed a similar callback from the I2C core ("[PATCH 0/2] i2c: remove
> > deprecated attach_adapter callback") because some drivers did a lot of
> > crazy things there. It took years to remove all that.
>
> Oh
Hi Wolfram,
On 02/09/19 22:42, Wolfram Sang wrote:
> Hi Luca,
>
>> + * Topology:
>> + *
>> + * Slave X @ 0x10
>> + * .-. |
>> + * .-. | |---+ B
>> + * | CPU |--A--| ATR |
>> + * `-' | |---+ C
>> + *
> Adding the ATR features to i2c-mux.c was very tricky and error-prone due
> to all of this code, that's why I have moved ATR to its own file in RFCv2.
I forgot to say that I like this.
signature.asc
Description: PGP signature
Hi Jacopo,
thanks for your feedback.
On 01/09/19 16:31, jacopo mondi wrote:
> Hi Luca,
>thanks for keep pushing this series! I hope we can use part of this
> for the (long time) on-going GMSL work...
>
> I hope you will be patient enough to provide (another :) overview
> of this work during
Hi Luca,
> + * Topology:
> + *
> + * Slave X @ 0x10
> + * .-. |
> + * .-. | |---+ B
> + * | CPU |--A--| ATR |
> + * `-' | |---+ C
> + * `-' |
> + * Slave Y @ 0x10
> + *
> + *
Hi Luca,
thanks for keep pushing this series! I hope we can use part of this
for the (long time) on-going GMSL work...
I hope you will be patient enough to provide (another :) overview
of this work during the BoF Wolfram has organized at LPC for the next
week.
In the meantime I would have
An ATR is a device that looks similar to an i2c-mux: it has an I2C
slave "upstream" port and N master "downstream" ports, and forwards
transactions from upstream to the appropriate downstream port. But is
is different in that the forwarded transaction has a different slave
address. The address
17 matches
Mail list logo
