Hi,
I'll agree with Karl and Doug. If you (as a board vendor/maintainer/etc) want
to use I2C, it's *your* responsibility to provide the pullup resistors by
either including pullup resistors on the board or by enabling the internal
ones.
Either way, you should think a moment about the consequenc
he LOW period of the scl clock.
>
> Thanks Doug for the suggestion about division formulas.
>
> Tested-by: Heiko Stuebner
> Reviewed-by: Doug Anderson
> Tested-by: Doug Anderson
> Signed-off-by: Addy Ke
Reviewed-by: Max Schwarz
Tested-by: Max Schwarz
Cheers,
Hi Addy,
On Monday 13 October 2014 at 10:44:04, Addy Ke wrote:
> As show in I2C specification:
> - Standard-mode: the minimum HIGH period of the scl clock is 4.0us
> the minimum LOW period of the scl clock is 4.7us
> - Fast-mode: the minimum HIGH period of the scl clock is 0.6us
>
Hi Addy,
sorry for the long delay, I finally had time to look at your work.
On Thursday 09 October 2014 at 14:47:15, Addy Ke wrote:
> As show in I2C specification:
> - Standard-mode: the minimum HIGH period of the scl clock is 4.0us
> the minimum LOW period of the scl clock is 4.
ssed == 0 && cnt == 0)
Yes, looks correct and makes i2cdetect work for me on Radxa Rock.
Reviewed-By: Max Schwarz
Tested-By: Max Schwarz
Cheers,
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ol.
I'm sorry, I see now that subsys_initcall() gets mapped to module_init() if
the driver is built as a loadable module. Everything is fine ;-)
Acked-By: Max Schwarz
Cheers,
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
Hi Chris,
Am Montag, 22. September 2014, 15:24:35 schrieb Chris Zhong:
> Some device using this bus, such as regulators, they should register
> as early as possible, so the I2C bus master needs to be loaded early.
> Therefore initialize via subsys_initcall() is better.
You could also use probe de
thing and trigger an additional chunk read if
necessary:
/* are we finished? */
if (i2c->processed == i2c->msg->len)
rk3x_i2c_stop(i2c, i2c->error);
else
rk3x_i2c_prepare_read(i2c);
I'd like a clearer syntax as suggested by Sergei, though.
Apart from that,
Acked-By: Max Schwarz
Cheers,
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz
---
The driver cannot be used without a proper clock driver
supporting
Hi Wolfram,
thanks for your comments.
On Tuesday 10 June 2014 at 21:27:09, Wolfram Sang wrote:
> Checking if the spinlock is needed would be nice, but we can also fix
> this later.
I'm simply not sure about the spinlock. My knowledge about IRQ handling in
linux is limited.
We have an SMP syste
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz
---
Sorry for the resend, I forgot to CC the developers at Rockchip
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz
---
The driver cannot be used without a proper clock driver
supporting
Hi Wolfram,
thanks for the review!
> > +
> > + /* Settings */
> > + unsigned int scl_frequency;
> > +
> > + /* Synchronization & notification */
> > + spinlock_t lock;
>
> Why the lock? The core has per-adapter locks anyhow.
I'm using it to lock the rk3x_i2c struct during interrupts. It
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz
---
The driver cannot be used without a proper clock driver
supporting
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz
---
The driver cannot be used without a proper clock driver
supporting
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Tested on the Radxa Rock board, which is based on RK3188.
Signed-off-by: Max Schwarz
---
changes
Hello Heiko,
thanks for your comments.
> both the grf as well as the bus-idx are rockchip specific, so they should be
> prefixed (rockchip,grf, etc) and from my personal taste I would hope we
> could invest in an "n" and "e", to make it a full bus-index ;-)
I will change the names to rockchip,grf
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Tested on the Radxa Rock board, which is based on RK3188.
Signed-off-by: Max Schwarz
---
For
The MAC address retrieved from dt was not actually written to the
hardware. This meant proper communication was only possible after
changing the MAC address.
Fix that by always writing the mac address during probing.
Signed-off-by: Max Schwarz
---
I recently noticed this problem on the Radxa
19 matches
Mail list logo
