On Thursday 22 March 2012 09:50:23 pm Daniel Vetter wrote:
> On Wed, Mar 21, 2012 at 02:29:47PM +0100, Jean Delvare wrote:
> > A udelay value of 20 leads to an I2C bus running at only 25 kbps.
> > I2C devices can typically operate faster than this, 50 kbps should
> > be fine for all devices (and
On Thursday 22 March 2012 09:50:23 pm Daniel Vetter wrote:
On Wed, Mar 21, 2012 at 02:29:47PM +0100, Jean Delvare wrote:
A udelay value of 20 leads to an I2C bus running at only 25 kbps.
I2C devices can typically operate faster than this, 50 kbps should
be fine for all devices (and
On Wed, Mar 21, 2012 at 02:29:47PM +0100, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
>
On Wed, Mar 21, 2012 at 02:29:47PM +0100, Jean Delvare wrote:
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW,
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So
