Hi Masahiro,
On 4 December 2014 at 00:27, Masahiro Yamada wrote:
> Hi Simon,
>
>
>
> On Wed, 3 Dec 2014 19:36:15 -0700
> Simon Glass wrote:
>
>> Hi Masahiro,
>>
>> On 3 December 2014 at 19:01, Masahiro Yamada
>> wrote:
>> > Hi Simon,
>> >
>> >
>> > More comments again.
>> >
>> >
>> > On Mon, 2
Hi Masahiro,
On 4 December 2014 at 00:24, Masahiro Yamada wrote:
> Hi Simon,
>
>
>
>
> On Wed, 3 Dec 2014 19:32:18 -0700
> Simon Glass wrote:
>
>> >
>> > BTW, I implemented an i2c driver for my Panasonic board base on this
>> > series,
>> > and I am playing around with it.
>> >
>> > I found a s
Hi Simon,
On Wed, 3 Dec 2014 19:36:15 -0700
Simon Glass wrote:
> Hi Masahiro,
>
> On 3 December 2014 at 19:01, Masahiro Yamada
> wrote:
> > Hi Simon,
> >
> >
> > More comments again.
> >
> >
> > On Mon, 24 Nov 2014 11:57:15 -0700
> >> +
> >> +static int i2c_probe_chip(struct udevice *bus, u
Hi Simon,
On Wed, 3 Dec 2014 19:32:18 -0700
Simon Glass wrote:
> >
> > BTW, I implemented an i2c driver for my Panasonic board base on this series,
> > and I am playing around with it.
> >
> > I found a strange behavior.
> >
> >
> > Assume an EEPROM chip is assigned with slave-address 0x50.
>
Hi Masahiro,
On 3 December 2014 at 21:36, Masahiro Yamada wrote:
> Hi Simon,
>
> I am testing this series on my board
> and found some bugs.
>
>
>
>
> On Mon, 24 Nov 2014 11:57:15 -0700
> Simon Glass wrote:
>
>
>> +
>> +static bool i2c_setup_offset(struct dm_i2c_chip *chip, uint offset,
>> +
Hi Simon,
I am testing this series on my board
and found some bugs.
On Mon, 24 Nov 2014 11:57:15 -0700
Simon Glass wrote:
> +
> +static bool i2c_setup_offset(struct dm_i2c_chip *chip, uint offset,
> + uint8_t offset_buf[], struct i2c_msg *msg)
> +{
> + if (!chip
Hi Masahiro,
On 3 December 2014 at 19:01, Masahiro Yamada wrote:
> Hi Simon,
>
>
> More comments again.
>
>
> On Mon, 24 Nov 2014 11:57:15 -0700
>> +
>> +static int i2c_probe_chip(struct udevice *bus, uint chip_addr)
>> +{
>> + struct dm_i2c_ops *ops = i2c_get_ops(bus);
>> + struct i2c_ms
Hi Masahiro,
On 3 December 2014 at 19:01, Masahiro Yamada wrote:
> Hi Simon,
>
>
> More comments again.
>
>
> On Mon, 24 Nov 2014 11:57:15 -0700
>> +
>> +static int i2c_probe_chip(struct udevice *bus, uint chip_addr)
>> +{
>> + struct dm_i2c_ops *ops = i2c_get_ops(bus);
>> + struct i2c_ms
Hi Simon,
More comments again.
On Mon, 24 Nov 2014 11:57:15 -0700
> +
> +static int i2c_probe_chip(struct udevice *bus, uint chip_addr)
> +{
> + struct dm_i2c_ops *ops = i2c_get_ops(bus);
> + struct i2c_msg msg[1];
> + uint8_t ch = 0;
> +
> + if (!ops->xfer)
> + retu
Hi Simon,
2014-12-04 0:13 GMT+09:00 Simon Glass :
>> If each driver does not have .set_bus_speed handler,
>> we cannot change the bus speed
>> because changing the bus speed involves some hardware
>> register(s) setting.
>>
>> We should not change i2c->speed_hz without changing the
>> actual spe
Hi Masahiro,
On 3 December 2014 at 06:24, Masahiro Yamada wrote:
> Hi Simon,
>
>
> A little more comments from me.
>
>
>
>
> On Mon, 24 Nov 2014 11:57:15 -0700
> Simon Glass wrote:
>
>> +int i2c_set_bus_speed(struct udevice *bus, unsigned int speed)
>> +{
>> + struct dm_i2c_ops *ops = i2c_g
Hi Masahiro,
On 1 December 2014 at 04:47, Masahiro Yamada wrote:
> Hi Simon,
>
>
> My review is still under way,
> but I have some comments below:
>
>
Thanks again for the comments, will tidy up a few other things too
before sending v4.
>
>
> On Mon, 24 Nov 2014 11:57:15 -0700
> Simon Glass wro
Hi Simon,
A little more comments from me.
On Mon, 24 Nov 2014 11:57:15 -0700
Simon Glass wrote:
> +int i2c_set_bus_speed(struct udevice *bus, unsigned int speed)
> +{
> + struct dm_i2c_ops *ops = i2c_get_ops(bus);
> + struct dm_i2c_bus *i2c = bus->uclass_priv;
> + int ret;
> +
>
Hi,
On 1 December 2014 at 23:29, Heiko Schocher wrote:
> Hello Simon,
>
> Am 02.12.2014 05:31, schrieb Simon Glass:
>>
>> +Heiko - are you OK with the new msg-based approach?
>
>
> Yes, you can add my acked-by to the hole series.
OK good, I'm going to continue on this line, and work through
Masa
Hello Simon,
Am 02.12.2014 05:31, schrieb Simon Glass:
+Heiko - are you OK with the new msg-based approach?
Yes, you can add my acked-by to the hole series.
bye,
Heiko
Hi Masahiro,
On 1 December 2014 at 04:47, Masahiro Yamada wrote:
Hi Simon,
My review is still under way,
but I have s
Hi Simon,
On Mon, 1 Dec 2014 21:31:29 -0700
Simon Glass wrote:
> +Heiko - are you OK with the new msg-based approach?
This approach looks much better to me.
> >> + .name = "i2c_generic_drv",
> >> + .id = UCLASS_I2C_GENERIC,
> >> +};
> >
> >
> > Can we move
+Heiko - are you OK with the new msg-based approach?
Hi Masahiro,
On 1 December 2014 at 04:47, Masahiro Yamada wrote:
> Hi Simon,
>
>
> My review is still under way,
> but I have some comments below:
>
>
>
>
> On Mon, 24 Nov 2014 11:57:15 -0700
> Simon Glass wrote:
>
>> +static bool i2c_setup_
Hi Simon,
My review is still under way,
but I have some comments below:
On Mon, 24 Nov 2014 11:57:15 -0700
Simon Glass wrote:
> +static bool i2c_setup_offset(struct dm_i2c_chip *chip, uint offset,
> + uint8_t offset_buf[], struct i2c_msg *msg)
> +{
> + if (!chip
Hi Simon,
On Thu, 27 Nov 2014 21:47:07 -0700
Simon Glass wrote:
> +Masahiro
> On Nov 24, 2014 11:58 AM, "Simon Glass" wrote:
>
> > The uclass implements the same operations as the current I2C framework but
> > makes some changes to make it fit driver model better:
> >
> > - Remove the chip ad
+Masahiro
On Nov 24, 2014 11:58 AM, "Simon Glass" wrote:
> The uclass implements the same operations as the current I2C framework but
> makes some changes to make it fit driver model better:
>
> - Remove the chip address from API calls
> - Remove the address length from API calls
> - Remove conc
The uclass implements the same operations as the current I2C framework but
makes some changes to make it fit driver model better:
- Remove the chip address from API calls
- Remove the address length from API calls
- Remove concept of 'current' I2C bus
- Drop all existing init functions
Signed-off
21 matches
Mail list logo
