Hi Joel,
> >> An EEPROM ist at 0x50 in Linux. There is no write addr 0xa0 and read
> >> addr 0xa1.
> >
> > OK, I understand! Will test and resend with conforming addressing. Thanks
> > for all the feedback!
>
> Nice one Wolfram. I wondered why the standard tools didn't work, but
> hadn't gotten
Hi Joel,
> >> An EEPROM ist at 0x50 in Linux. There is no write addr 0xa0 and read
> >> addr 0xa1.
> >
> > OK, I understand! Will test and resend with conforming addressing. Thanks
> > for all the feedback!
>
> Nice one Wolfram. I wondered why the standard tools didn't work, but
> hadn't gotten
On 11 July 2018 at 06:59, Eddie James wrote:
>
>
> On 07/10/2018 02:39 PM, Wolfram Sang wrote:
>>>
>>> Sorry, what do you mean "show up as"? Yes, we could first shift all our
>>> addresses in user-space before passing them to the driver, so that the
>>> msg->addr field is exactly what the
On 11 July 2018 at 06:59, Eddie James wrote:
>
>
> On 07/10/2018 02:39 PM, Wolfram Sang wrote:
>>>
>>> Sorry, what do you mean "show up as"? Yes, we could first shift all our
>>> addresses in user-space before passing them to the driver, so that the
>>> msg->addr field is exactly what the
On Tue, 2018-07-10 at 12:52 -0500, Eddie James wrote:
>
> On 07/09/2018 05:41 PM, Wolfram Sang wrote:
> > > + cmd |= FIELD_PREP(I2C_CMD_ADDR, msg->addr >> 1);
> >
> > I just noticed this and wonder: Don't you need the LSB of the address?
> > It is not the RW flag, this is encoded in msg->flags.
On Tue, 2018-07-10 at 12:52 -0500, Eddie James wrote:
>
> On 07/09/2018 05:41 PM, Wolfram Sang wrote:
> > > + cmd |= FIELD_PREP(I2C_CMD_ADDR, msg->addr >> 1);
> >
> > I just noticed this and wonder: Don't you need the LSB of the address?
> > It is not the RW flag, this is encoded in msg->flags.
On 07/10/2018 02:39 PM, Wolfram Sang wrote:
Sorry, what do you mean "show up as"? Yes, we could first shift all our
addresses in user-space before passing them to the driver, so that the
msg->addr field is exactly what the hardware expects already... This would
be non-trivial for our users
On 07/10/2018 02:39 PM, Wolfram Sang wrote:
Sorry, what do you mean "show up as"? Yes, we could first shift all our
addresses in user-space before passing them to the driver, so that the
msg->addr field is exactly what the hardware expects already... This would
be non-trivial for our users
> Sorry, what do you mean "show up as"? Yes, we could first shift all our
> addresses in user-space before passing them to the driver, so that the
> msg->addr field is exactly what the hardware expects already... This would
> be non-trivial for our users considering all our documentation
> Sorry, what do you mean "show up as"? Yes, we could first shift all our
> addresses in user-space before passing them to the driver, so that the
> msg->addr field is exactly what the hardware expects already... This would
> be non-trivial for our users considering all our documentation
On 07/10/2018 01:50 PM, Wolfram Sang wrote:
+ cmd |= FIELD_PREP(I2C_CMD_ADDR, msg->addr >> 1);
I just noticed this and wonder: Don't you need the LSB of the address?
It is not the RW flag, this is encoded in msg->flags.
So, the hardware interprets the LSB as the RW flag. It wouldn't
On 07/10/2018 01:50 PM, Wolfram Sang wrote:
+ cmd |= FIELD_PREP(I2C_CMD_ADDR, msg->addr >> 1);
I just noticed this and wonder: Don't you need the LSB of the address?
It is not the RW flag, this is encoded in msg->flags.
So, the hardware interprets the LSB as the RW flag. It wouldn't
> > > + cmd |= FIELD_PREP(I2C_CMD_ADDR, msg->addr >> 1);
> > I just noticed this and wonder: Don't you need the LSB of the address?
> > It is not the RW flag, this is encoded in msg->flags.
>
> So, the hardware interprets the LSB as the RW flag. It wouldn't be possible
> to have a device
> > > + cmd |= FIELD_PREP(I2C_CMD_ADDR, msg->addr >> 1);
> > I just noticed this and wonder: Don't you need the LSB of the address?
> > It is not the RW flag, this is encoded in msg->flags.
>
> So, the hardware interprets the LSB as the RW flag. It wouldn't be possible
> to have a device
On 07/09/2018 05:41 PM, Wolfram Sang wrote:
+ cmd |= FIELD_PREP(I2C_CMD_ADDR, msg->addr >> 1);
I just noticed this and wonder: Don't you need the LSB of the address?
It is not the RW flag, this is encoded in msg->flags.
So, the hardware interprets the LSB as the RW flag. It wouldn't
On 07/09/2018 05:41 PM, Wolfram Sang wrote:
+ cmd |= FIELD_PREP(I2C_CMD_ADDR, msg->addr >> 1);
I just noticed this and wonder: Don't you need the LSB of the address?
It is not the RW flag, this is encoded in msg->flags.
So, the hardware interprets the LSB as the RW flag. It wouldn't
> + cmd |= FIELD_PREP(I2C_CMD_ADDR, msg->addr >> 1);
I just noticed this and wonder: Don't you need the LSB of the address?
It is not the RW flag, this is encoded in msg->flags.
Also, no seperate handling for 10 bit addresses? Technically, 7-bit 0x50
is different on the wire from 10-bit
> + cmd |= FIELD_PREP(I2C_CMD_ADDR, msg->addr >> 1);
I just noticed this and wonder: Don't you need the LSB of the address?
It is not the RW flag, this is encoded in msg->flags.
Also, no seperate handling for 10 bit addresses? Technically, 7-bit 0x50
is different on the wire from 10-bit
Execute I2C transfers from the FSI-attached I2C master. Use polling
instead of interrupts as we have no hardware IRQ over FSI.
Signed-off-by: Eddie James
Reviewed-by: Andy Shevchenko
---
drivers/i2c/busses/i2c-fsi.c | 195 ++-
1 file changed, 193
Execute I2C transfers from the FSI-attached I2C master. Use polling
instead of interrupts as we have no hardware IRQ over FSI.
Signed-off-by: Eddie James
Reviewed-by: Andy Shevchenko
---
drivers/i2c/busses/i2c-fsi.c | 195 ++-
1 file changed, 193
20 matches
Mail list logo
