Re: [PATCH] i2c: busses: i2c-bcm2835: S-Register clear reserved bits
On 06/16/2015 09:40 AM, Silvan Wicki wrote: > The Datasheet mentions on page 31 that the bits 10-31 must be read as > don't care and written as 0. > https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf > > We cannot guarantee that we reed bits 10-31 as always 0 (becuase the > datasheet says read as don't care). We clear the bits with a bitmask to > prevent writing back unknown data at the reserved bits. I guess that's true. Acked-by: Stephen Warren -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] i2c: omap: improve duty cycle on SCL
On Tue, Jun 16, 2015 at 02:20:45PM -0500, Felipe Balbi wrote:
> With this patch we try to be as close to 50%
> duty cycle as possible. The reason for this
> is that some devices present an erratic behavior
> with certain duty cycles.
>
> One such example is TPS65218 PMIC which fails
> to change voltages when running @ 400kHz and
> duty cycle is lower than 34%.
>
> The idea of the patch is simple:
>
> calculate desired scl_period from requested scl
> and use 50% for tLow and 50% for tHigh.
>
> tLow is calculated with a DIV_ROUND_UP() to make
> sure it's slightly higher than tHigh and to make
> sure that we end up within I2C specifications.
>
> Kudos to Nishanth Menon and Dave Gerlach for helping
> debugging the TPS65218 problem found on AM437x SK.
>
> Signed-off-by: Felipe Balbi
Aaro, can you test this on N900 ?
> ---
> drivers/i2c/busses/i2c-omap.c | 86
> ---
> 1 file changed, 56 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 0e894193accf..034d2d1ff289 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -25,6 +25,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -39,6 +40,8 @@
> #include
> #include
>
> +#define NSECS_PER_SEC10
> +
> /* I2C controller revisions */
> #define OMAP_I2C_OMAP1_REV_2 0x20
>
> @@ -359,6 +362,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
> unsigned long fclk_rate = 1200;
> unsigned long internal_clk = 0;
> + unsigned long internal_clk_period = 0;
> + unsigned long scl_period = 0;
> struct clk *fclk;
>
> if (dev->rev >= OMAP_I2C_REV_ON_3430_3530) {
> @@ -395,52 +400,73 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> }
>
> if (!(dev->flags & OMAP_I2C_FLAG_SIMPLE_CLOCK)) {
> -
> /*
>* HSI2C controller internal clk rate should be 19.2 Mhz for
> - * HS and for all modes on 2430. On 34xx we can use lower rate
> - * to get longer filter period for better noise suppression.
> - * The filter is iclk (fclk for HS) period.
> + * HS and for all modes on 2430. For all other devices and
> + * speeds we will use a 12MHz internal clock.
>*/
> - if (dev->speed > 400 ||
> -dev->flags & OMAP_I2C_FLAG_FORCE_19200_INT_CLK)
> - internal_clk = 19200;
> - else if (dev->speed > 100)
> - internal_clk = 9600;
> - else
> - internal_clk = 4000;
> + if (dev->flags & OMAP_I2C_FLAG_FORCE_19200_INT_CLK ||
> + dev->speed > 400) {
> + internal_clk = 192;
> + internal_clk_period = NSECS_PER_SEC /
> + internal_clk; /* ns */
> + } else {
> + internal_clk = 1200;
> + internal_clk_period = NSECS_PER_SEC /
> + internal_clk; /* ns */
> + }
> +
> fclk = clk_get(dev->dev, "fck");
> - fclk_rate = clk_get_rate(fclk) / 1000;
> + fclk_rate = clk_get_rate(fclk);
> clk_put(fclk);
>
> /* Compute prescaler divisor */
> psc = fclk_rate / internal_clk;
> psc = psc - 1;
>
> + /*
> + * Here's the tricky part, we want to make sure our duty cycle
> + * is as close to 50% as possible. In order to achieve that, we
> + * will first figure out what's the period on chosen scl is,
> + * then divide that by two and calculate SCLL and SCLH based on
> + * that.
> + *
> + * SCLL and SCLH equations are as folows:
> + *
> + * SCLL = (tLow / iclk_period) - 7;
> + * SCLH = (tHigh / iclk_period) - 5;
> + *
> + * Where iclk_period is period of Internal Clock.
> + *
> + * tLow and tHigh will be basically half of scl_period where
> + * possible as long as we can match I2C spec's minimum limits
> + * for them.
> + */
> + scl_period = NSECS_PER_SEC / dev->speed;
> +
> /* If configured for High Speed */
> if (dev->speed > 400) {
> - unsigned long scl;
> + unsigned long fs_period;
> +
> + /*
> + * first phase of HS mode is up to
> + * 400kHz so we will use that.
> + */
> + fs_period = NSECS_PER_SEC / 400;
>
> /* For first phase o
[PATCH RESEND] i2c: omap: improve duty cycle on SCL
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such example is TPS65218 PMIC which fails
to change voltages when running @ 400kHz and
duty cycle is lower than 34%.
The idea of the patch is simple:
calculate desired scl_period from requested scl
and use 50% for tLow and 50% for tHigh.
tLow is calculated with a DIV_ROUND_UP() to make
sure it's slightly higher than tHigh and to make
sure that we end up within I2C specifications.
Kudos to Nishanth Menon and Dave Gerlach for helping
debugging the TPS65218 problem found on AM437x SK.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 86 ---
1 file changed, 56 insertions(+), 30 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0e894193accf..034d2d1ff289 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -25,6 +25,7 @@
*/
#include
+#include
#include
#include
#include
@@ -39,6 +40,8 @@
#include
#include
+#define NSECS_PER_SEC 10
+
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -359,6 +362,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long internal_clk = 0;
+ unsigned long internal_clk_period = 0;
+ unsigned long scl_period = 0;
struct clk *fclk;
if (dev->rev >= OMAP_I2C_REV_ON_3430_3530) {
@@ -395,52 +400,73 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
}
if (!(dev->flags & OMAP_I2C_FLAG_SIMPLE_CLOCK)) {
-
/*
* HSI2C controller internal clk rate should be 19.2 Mhz for
-* HS and for all modes on 2430. On 34xx we can use lower rate
-* to get longer filter period for better noise suppression.
-* The filter is iclk (fclk for HS) period.
+* HS and for all modes on 2430. For all other devices and
+* speeds we will use a 12MHz internal clock.
*/
- if (dev->speed > 400 ||
- dev->flags & OMAP_I2C_FLAG_FORCE_19200_INT_CLK)
- internal_clk = 19200;
- else if (dev->speed > 100)
- internal_clk = 9600;
- else
- internal_clk = 4000;
+ if (dev->flags & OMAP_I2C_FLAG_FORCE_19200_INT_CLK ||
+ dev->speed > 400) {
+ internal_clk = 192;
+ internal_clk_period = NSECS_PER_SEC /
+ internal_clk; /* ns */
+ } else {
+ internal_clk = 1200;
+ internal_clk_period = NSECS_PER_SEC /
+ internal_clk; /* ns */
+ }
+
fclk = clk_get(dev->dev, "fck");
- fclk_rate = clk_get_rate(fclk) / 1000;
+ fclk_rate = clk_get_rate(fclk);
clk_put(fclk);
/* Compute prescaler divisor */
psc = fclk_rate / internal_clk;
psc = psc - 1;
+ /*
+* Here's the tricky part, we want to make sure our duty cycle
+* is as close to 50% as possible. In order to achieve that, we
+* will first figure out what's the period on chosen scl is,
+* then divide that by two and calculate SCLL and SCLH based on
+* that.
+*
+* SCLL and SCLH equations are as folows:
+*
+* SCLL = (tLow / iclk_period) - 7;
+* SCLH = (tHigh / iclk_period) - 5;
+*
+* Where iclk_period is period of Internal Clock.
+*
+* tLow and tHigh will be basically half of scl_period where
+* possible as long as we can match I2C spec's minimum limits
+* for them.
+*/
+ scl_period = NSECS_PER_SEC / dev->speed;
+
/* If configured for High Speed */
if (dev->speed > 400) {
- unsigned long scl;
+ unsigned long fs_period;
+
+ /*
+* first phase of HS mode is up to
+* 400kHz so we will use that.
+*/
+ fs_period = NSECS_PER_SEC / 400;
/* For first phase of HS mode */
- scl = internal_clk / 400;
- fsscll = scl - (scl / 3) - 7;
- fssclh = (scl / 3) - 5;
+ fsscll = DIV_ROUND_UP(fs_period
Re: [PATCH] i2c: omap: improve duty cycle on SCL
On Tue, Jun 16, 2015 at 02:17:56PM -0500, Felipe Balbi wrote: > With this patch we try to be as close to 50% > duty cycle as possible. The reason for this > is that some devices present an erratic behavior > with certain duty cycles. > > One such example is TPS65218 PMIC which fails > to change voltages when running @ 400kHz and > duty cycle is lower than 34%. > > The idea of the patch is simple: > > calculate desired scl_period from requested scl > and use 50% for tLow and 50% for tHigh. > > tLow is calculated with a DIV_ROUND_UP() to make > sure it's slightly higher than tHigh and to make > sure that we end up within I2C specifications. > > Kudos to Nishanth Menon and Dave Gerlach for helping > debugging the TPS65218 problem found on AM437x SK. > > Signed-off-by: Felipe Balbi the patch is correct, but I sent the version written on top of v3.14, I'll resend correct version, sorry. -- balbi signature.asc Description: Digital signature
[PATCH] i2c: omap: improve duty cycle on SCL
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such example is TPS65218 PMIC which fails
to change voltages when running @ 400kHz and
duty cycle is lower than 34%.
The idea of the patch is simple:
calculate desired scl_period from requested scl
and use 50% for tLow and 50% for tHigh.
tLow is calculated with a DIV_ROUND_UP() to make
sure it's slightly higher than tHigh and to make
sure that we end up within I2C specifications.
Kudos to Nishanth Menon and Dave Gerlach for helping
debugging the TPS65218 problem found on AM437x SK.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 86 ---
1 file changed, 56 insertions(+), 30 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4be54fa32839..01e343bd6d97 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -29,6 +29,7 @@
*/
#include
+#include
#include
#include
#include
@@ -44,6 +45,8 @@
#include
#include
+#define NSECS_PER_SEC 10
+
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -347,6 +350,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long internal_clk = 0;
+ unsigned long internal_clk_period = 0;
+ unsigned long scl_period = 0;
struct clk *fclk;
if (dev->rev >= OMAP_I2C_REV_ON_3430_3530) {
@@ -383,52 +388,73 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
}
if (!(dev->flags & OMAP_I2C_FLAG_SIMPLE_CLOCK)) {
-
/*
* HSI2C controller internal clk rate should be 19.2 Mhz for
-* HS and for all modes on 2430. On 34xx we can use lower rate
-* to get longer filter period for better noise suppression.
-* The filter is iclk (fclk for HS) period.
+* HS and for all modes on 2430. For all other devices and
+* speeds we will use a 12MHz internal clock.
*/
- if (dev->speed > 400 ||
- dev->flags & OMAP_I2C_FLAG_FORCE_19200_INT_CLK)
- internal_clk = 19200;
- else if (dev->speed > 100)
- internal_clk = 9600;
- else
- internal_clk = 4000;
+ if (dev->flags & OMAP_I2C_FLAG_FORCE_19200_INT_CLK ||
+ dev->speed > 400) {
+ internal_clk = 192;
+ internal_clk_period = NSECS_PER_SEC /
+ internal_clk; /* ns */
+ } else {
+ internal_clk = 1200;
+ internal_clk_period = NSECS_PER_SEC /
+ internal_clk; /* ns */
+ }
+
fclk = clk_get(dev->dev, "fck");
- fclk_rate = clk_get_rate(fclk) / 1000;
+ fclk_rate = clk_get_rate(fclk);
clk_put(fclk);
/* Compute prescaler divisor */
psc = fclk_rate / internal_clk;
psc = psc - 1;
+ /*
+* Here's the tricky part, we want to make sure our duty cycle
+* is as close to 50% as possible. In order to achieve that, we
+* will first figure out what's the period on chosen scl is,
+* then divide that by two and calculate SCLL and SCLH based on
+* that.
+*
+* SCLL and SCLH equations are as folows:
+*
+* SCLL = (tLow / iclk_period) - 7;
+* SCLH = (tHigh / iclk_period) - 5;
+*
+* Where iclk_period is period of Internal Clock.
+*
+* tLow and tHigh will be basically half of scl_period where
+* possible as long as we can match I2C spec's minimum limits
+* for them.
+*/
+ scl_period = NSECS_PER_SEC / dev->speed;
+
/* If configured for High Speed */
if (dev->speed > 400) {
- unsigned long scl;
+ unsigned long fs_period;
+
+ /*
+* first phase of HS mode is up to
+* 400kHz so we will use that.
+*/
+ fs_period = NSECS_PER_SEC / 400;
/* For first phase of HS mode */
- scl = internal_clk / 400;
- fsscll = scl - (scl / 3) - 7;
- fssclh = (scl / 3) - 5;
+ fsscll = DIV_ROUND_UP(fs_period
[PATCH] i2c: tegra: apply size limit quirk
payload_size is a 12 bit field in the HW register, so add a limit for
this size. That way we gracefully reject the message beforehand instead
of generating an OOPS while transferring. Verified using some older
Tegra2 documentation and a more recent Jetson TK1 board.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-tegra.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 0a1b6eacef0fba..78a36681469674 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -669,6 +669,12 @@ static const struct i2c_algorithm tegra_i2c_algo = {
.functionality = tegra_i2c_func,
};
+/* payload size is only 12 bit */
+static struct i2c_adapter_quirks tegra_i2c_quirks = {
+ .max_read_len = 4096,
+ .max_write_len = 4096,
+};
+
static const struct tegra_i2c_hw_feature tegra20_i2c_hw = {
.has_continue_xfer_support = false,
.has_per_pkt_xfer_complete_irq = false,
@@ -739,6 +745,7 @@ static int tegra_i2c_probe(struct platform_device *pdev)
i2c_dev->base = base;
i2c_dev->div_clk = div_clk;
i2c_dev->adapter.algo = &tegra_i2c_algo;
+ i2c_dev->adapter.quirks = &tegra_i2c_quirks;
i2c_dev->irq = irq;
i2c_dev->cont_id = pdev->id;
i2c_dev->dev = &pdev->dev;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: tegra: don't advertise SMBUS_QUICK
This HW cannot send 0-byte-length messages and the driver discards them.
So, we should not advertise SMBUS_QUICK.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-tegra.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 1bcd75ea0b4cfd..0a1b6eacef0fba 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -656,8 +656,8 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg msgs[],
static u32 tegra_i2c_func(struct i2c_adapter *adap)
{
struct tegra_i2c_dev *i2c_dev = i2c_get_adapdata(adap);
- u32 ret = I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR |
- I2C_FUNC_PROTOCOL_MANGLING;
+ u32 ret = I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK) |
+ I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
if (i2c_dev->hw->has_continue_xfer_support)
ret |= I2C_FUNC_NOSTART;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg
Based on i2c-mux-gpio driver, similarly the register based mux
switch from one bus to another by setting a single register.
The register can be on PCIe bus, local bus, or any memory-mapped
address.
Signed-off-by: York Sun
CC: Wolfram Sang
CC: Peter Korsgaard
---
.../devicetree/bindings/i2c/i2c-mux-reg.txt| 69 ++
drivers/i2c/muxes/Kconfig | 11 +
drivers/i2c/muxes/Makefile |1 +
drivers/i2c/muxes/i2c-mux-reg.c| 239
drivers/i2c/muxes/i2c-mux-reg.h| 38
5 files changed, 358 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt
create mode 100644 drivers/i2c/muxes/i2c-mux-reg.c
create mode 100644 drivers/i2c/muxes/i2c-mux-reg.h
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt
b/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt
new file mode 100644
index 000..ad7cc4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt
@@ -0,0 +1,69 @@
+Register-based I2C Bus Mux
+
+This binding describes an I2C bus multiplexer that uses a single regsiter
+to route the I2C signals.
+
+Required properties:
+- compatible: i2c-mux-reg
+- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
+ port is connected to.
+* Standard I2C mux properties. See mux.txt in this directory.
+* I2C child bus nodes. See mux.txt in this directory.
+
+Optional properties:
+- reg: this pair of specifies the register to control the mux.
+ The depends on its parent node. It can be any memory-mapped
+ address. If omitted, the resource of this device will be used.
+- idle-state: value to set the muxer to when idle. When no value is
+ given, it defaults to the last value used.
+
+For each i2c child node, an I2C child bus will be created. They will
+be numbered based on their order in the device tree.
+
+Whenever an access is made to a device on a child bus, the value set
+in the revelant node's reg property will be output to the register.
+
+If an idle state is defined, using the idle-state (optional) property,
+whenever an access is not being made to a device on a child bus, the
+register will be set according to the idle value.
+
+If an idle state is not defined, the most recently used value will be
+left programmed into the register.
+
+Example of a mux on PCIe card, the host is a powerpc SoC (big endian):
+
+ i2c-mux {
+ /* the depends on the address translation
+* of the parent device. If omitted, device resource
+* will be used instead.
+*/
+ reg = <0x6028 0x4>;
+ compatible = "i2c-mux-reg";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-parent = <&i2c1>;
+ i2c@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ si5338: clock-generator@70 {
+ compatible = "silabs,si5338";
+ reg = <0x70>;
+ /* other stuff */
+ };
+ };
+
+ i2c@1 {
+ /* data is in little endian on pcie bus */
+ reg = <0x0100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ si5338: clock-generator@70 {
+ compatible = "silabs,si5338";
+ reg = <0x70>;
+ /* other stuff */
+ };
+ };
+ };
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index f6d313e..77c1257 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -29,6 +29,17 @@ config I2C_MUX_GPIO
This driver can also be built as a module. If so, the module
will be called i2c-mux-gpio.
+config I2C_MUX_REG
+ tristate "Register-based I2C multiplexer"
+ help
+ If you say yes to this option, support will be included for a
+ register based I2C multiplexer. This driver provides access to
+ I2C busses connected through a MUX, which is controlled
+ by a sinple register.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mux-reg.
+
config I2C_MUX_PCA9541
tristate "NXP PCA9541 I2C Master Selector"
help
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 465778b..bc517bb 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -4,6 +4,7 @@
obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE) += i2c-arb-gpio-challenge.o
obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
+obj-$(CONFIG_I2C_MUX_REG) += i2c-mux-reg.o
obj-$(CONFIG_I2C_MUX_PCA9541) += i2c-mux-pca954
[Patch v3] driver/clk/clk-si5338: Add common clock framework driver for si5338
SI5338 is a programmable clock generator. It has 4 sets of inputs, PLL, multisynth and dividers to make 4 outputs. This driver splits them into multiple clocks to comply with common clock framework. See Documentation/devicetree/bindings/clock/silabs,si5338.txt for details. COMMON_CLK in Kconfig is changed from bool to tristate so all common clock framework drivers can be selected by users. Export __clk_is_prepared from clk.c so drivers can check and unprepare clocks upon removal. Signed-off-by: York Sun CC: Mike Turquette CC: Sebastian Hesselbarth CC: Guenter Roeck CC: Andrey Filippov CC: Paul Bolle --- Change log: v3: Add calling unprepare upon removal Add registering to clkdev so the clk can be acquired when device tree is not in use Add a dev_info message when driver is removed Add missing "static" to two functions in clk-si5338.c Cosmatic fix in dt-bindings.clock/clk-si5338.h v2: Fix handling name prefix if the driver is unloaded and loaded again .../devicetree/bindings/clock/silabs,si5338.txt| 173 + drivers/clk/Kconfig| 14 +- drivers/clk/Makefile |1 + drivers/clk/clk-si5338.c | 3679 drivers/clk/clk-si5338.h | 305 ++ drivers/clk/clk.c |1 + include/dt-bindings/clock/clk-si5338.h | 68 + include/linux/platform_data/si5338.h | 49 + 8 files changed, 4289 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5338.txt create mode 100644 drivers/clk/clk-si5338.c create mode 100644 drivers/clk/clk-si5338.h create mode 100644 include/dt-bindings/clock/clk-si5338.h create mode 100644 include/linux/platform_data/si5338.h diff --git a/Documentation/devicetree/bindings/clock/silabs,si5338.txt b/Documentation/devicetree/bindings/clock/silabs,si5338.txt new file mode 100644 index 000..aeeb81d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/silabs,si5338.txt @@ -0,0 +1,173 @@ +Binding for Silicon Labs Si5338 programmable i2c clock generator. + +Reference +[1] Si5338 Data Sheet +http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5338.pdf + +The Si5338 is a programmable i2c clock generators with up to 4 output +clocks. It has 4 sets of possible input clocks + +IN1/IN2: differential +IN3: single-ended +IN4: single-ended +IN5/IN6: differential + +Additionally, IN1/IN2 can be used as XTAL with different setting. +The clock tree looks like below (without support of zero-delay) + + + IN1/IN2 IN3 IN4 IN5/IN6 + | | | | + --| | | | + | | | | | + | \ / \ / + | \ / \ / + | \ / \ / + XTAL REFCLKFBCLK + | | \ / | + | | \ /| + | | DIVREFCLK DIVFBCLK | + | | \ / | + | | \ / | + | | \ /| + | |PLL | + | | / | | \ | + | | / / \ \ | + | |/ / \ \ | + | | / | | \| + | | | | | || + | | MS0 MS1 MS2 MS3 | + | | | | | || + + OUT0 OUT1 OUT2 OUT3 + +The output clock can choose from any of the above clock as its source, with +exceptions: MS1 can only be used for OUT1, MS2 can only be used for OUT2, MS3 +can only be used for OUT3. + +==I2C device node== + +Required properties: +- compatible: shall be "silabs,si5338". +- reg: i2c device address, shall be 0x60, 0x61, 0x70, or 0x71 +- #clock-cells: shall be set to 1 for multiple outputs +- clocks: list of parent clocks in the order of , , , , + Note, xtal and in1/2 are mutually exclusive. Only one can be set. +- #address-cells: shall be set to 1. +- #size-cells: shall be set to 0. + +Optional properties if not set by platform driver: +- silab,ref-source: source of refclk, valid value is defined as + #define SI5338_REF_SRC_CLKIN12 0 + #define SI5338_REF_SRC_CLKIN3 1 + #define SI5338_REF_SRC_XTAL 4 +- silab,fb-source: source of fbclk, valid value is defined as + #define SI5338_FB_SRC_CLKIN42 + #define SI5338_FB_SRC_CLKIN56 3 + #define SI5338_FB_SRC_NOCLK 5 +- silabs,pll-source: source of pll, valid value is defined as + #define SI5338_PFD_IN_REF_REFCLK 0 + #define SI5338_PFD_IN_REF_FBCLK1 + #define SI5338_PFD_IN_REF_DIVREFCLK2 + #define SI5338_PFD_IN_REF_DIVFBCLK 3 + #define SI5338_PFD_IN_REF_XOCLK4 + #define SI5338_PFD_IN_REF_NOCLK5 +- silabs,pll-master: Pick one MS (0, 1, 2, or 3) to allow chaning PLL
[PATCH] i2c: busses: i2c-bcm2835: S-Register clear reserved bits
The Datasheet mentions on page 31 that the bits 10-31 must be read as
don't care and written as 0.
https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
We cannot guarantee that we reed bits 10-31 as always 0 (becuase the
datasheet says read as don't care). We clear the bits with a bitmask to
prevent writing back unknown data at the reserved bits.
Signed-off-by: Silvan Wicki
---
drivers/i2c/busses/i2c-bcm2835.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
index c9336a3..aa06da1 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -50,6 +50,8 @@
#define BCM2835_I2C_S_CLKT BIT(9)
#define BCM2835_I2C_S_LEN BIT(10) /* Fake bit for SW error reporting */
+#define BCM2835_I2C_BITMSK_S 0x03FF
+
#define BCM2835_I2C_TIMEOUT (msecs_to_jiffies(1000))
struct bcm2835_i2c_dev {
@@ -111,6 +113,7 @@ static irqreturn_t bcm2835_i2c_isr(int this_irq, void *data)
u32 val, err;
val = bcm2835_i2c_readl(i2c_dev, BCM2835_I2C_S);
+ val &= BCM2835_I2C_BITMSK_S;
bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_S, val);
err = val & (BCM2835_I2C_S_CLKT | BCM2835_I2C_S_ERR);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2] driver/clk/clk-si5338: Add common clock framework driver for si5338
On 06/16/2015 08:18 AM, York Sun wrote: > Paul, > > Thanks for reviewing. > > On 06/16/2015 01:21 AM, Paul Bolle wrote: >> One question and a few nits follow. >> >> On Mon, 2015-06-15 at 10:07 -0700, York Sun wrote: >>> SI5338 is a programmable clock generator. It has 4 sets of inputs, >>> PLL, multisynth and dividers to make 4 outputs. This driver splits >>> them into multiple clocks to comply with common clock framework. >>> >>> See Documentation/devicetree/bindings/clock/silabs,si5338.txt for >>> details. >>> >>> Signed-off-by: York Sun >>> CC: Mike Turquette >> >> Apparently that's now mturque...@baylibre.com . > > Thanks. Will change. > >> >>> CC: Sebastian Hesselbarth >>> CC: Guenter Roeck >>> CC: Andrey Filippov >> >>> --- a/drivers/clk/Kconfig >>> +++ b/drivers/clk/Kconfig >> >>> config COMMON_CLK >>> - bool >>> + tristate "Common Clock" >>> select HAVE_CLK_PREPARE >>> select CLKDEV_LOOKUP >>> select SRCU >> >> Why? The commit explanation doesn't mention this. Did you use an unclean >> tree? If not, you just created over a dozen of new modules: > > Thanks for catching this. I was testing building the driver within and outside > of kernel tree for another kernel version. If this driver is built-in, I don't > need to make it tristate. Will revert in next version. > Now I remember why I did this. COMMON_CLK wasn't an option users can select, because it is a bool and only selected by some platforms. I think it should be a tristate so one can build a driver with it. When it is selected, some drivers are built, either into kernel or as modules, up to user's choice. They are needed by common clock framework. I should add explanation in commit message. Or separate it into an individual patch. Which one is preferred? York -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2] driver/clk/clk-si5338: Add common clock framework driver for si5338
Paul,
Thanks for reviewing.
On 06/16/2015 01:21 AM, Paul Bolle wrote:
> One question and a few nits follow.
>
> On Mon, 2015-06-15 at 10:07 -0700, York Sun wrote:
>> SI5338 is a programmable clock generator. It has 4 sets of inputs,
>> PLL, multisynth and dividers to make 4 outputs. This driver splits
>> them into multiple clocks to comply with common clock framework.
>>
>> See Documentation/devicetree/bindings/clock/silabs,si5338.txt for
>> details.
>>
>> Signed-off-by: York Sun
>> CC: Mike Turquette
>
> Apparently that's now mturque...@baylibre.com .
Thanks. Will change.
>
>> CC: Sebastian Hesselbarth
>> CC: Guenter Roeck
>> CC: Andrey Filippov
>
>> --- a/drivers/clk/Kconfig
>> +++ b/drivers/clk/Kconfig
>
>> config COMMON_CLK
>> -bool
>> +tristate "Common Clock"
>> select HAVE_CLK_PREPARE
>> select CLKDEV_LOOKUP
>> select SRCU
>
> Why? The commit explanation doesn't mention this. Did you use an unclean
> tree? If not, you just created over a dozen of new modules:
Thanks for catching this. I was testing building the driver within and outside
of kernel tree for another kernel version. If this driver is built-in, I don't
need to make it tristate. Will revert in next version.
> $ git grep -nw CONFIG_COMMON_CLK -- "*Makefile*"
> arch/arm/mach-mmp/Makefile:13:ifeq ($(CONFIG_COMMON_CLK), )
> arch/arm/mach-shmobile/Makefile:21:ifndef CONFIG_COMMON_CLK
> arch/powerpc/platforms/512x/Makefile:4:obj-$(CONFIG_COMMON_CLK) +=
> clock-commonclk.o
> drivers/clk/Makefile:4:obj-$(CONFIG_COMMON_CLK) += clk.o
> drivers/clk/Makefile:5:obj-$(CONFIG_COMMON_CLK) += clk-divider.o
> drivers/clk/Makefile:6:obj-$(CONFIG_COMMON_CLK) += clk-fixed-factor.o
> drivers/clk/Makefile:7:obj-$(CONFIG_COMMON_CLK) += clk-fixed-rate.o
> drivers/clk/Makefile:8:obj-$(CONFIG_COMMON_CLK) += clk-gate.o
> drivers/clk/Makefile:9:obj-$(CONFIG_COMMON_CLK) += clk-mux.o
> drivers/clk/Makefile:10:obj-$(CONFIG_COMMON_CLK)+= clk-composite.o
> drivers/clk/Makefile:11:obj-$(CONFIG_COMMON_CLK)+=
> clk-fractional-divider.o
> drivers/clk/Makefile:12:obj-$(CONFIG_COMMON_CLK)+= clk-gpio-gate.o
> drivers/clk/Makefile:14:obj-$(CONFIG_COMMON_CLK)+= clk-conf.o
> drivers/clk/Makefile:59:ifeq ($(CONFIG_COMMON_CLK), y)
> drivers/clk/samsung/Makefile:5:obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
> drivers/gpu/drm/msm/Makefile:53:msm-$(CONFIG_COMMON_CLK) +=
> mdp/mdp4/mdp4_lvds_pll.o
> drivers/sh/Makefile:5:ifneq ($(CONFIG_COMMON_CLK),y)
>
>> +config COMMON_CLK_SI5338
>> +tristate "Clock driver for SiLabs 5338"
>> +depends on I2C
>> +select REGMAP_I2C
>> +select RATIONAL
>> +---help---
>> + This driver supports Silicon Labs 5338 programmable clock generators,
>> + using common clock framework. It needs parent clock as input(s).
>> + Internal clocks are registered with unique names in case multiple
>> + devices exist. See devicetree/bindings/clock/silabs,si5338.txt
>> + under Documentation for details.
>
>> --- /dev/null
>> +++ b/drivers/clk/clk-si5338.c
>
>> +unsigned long si5338_divrefclk_recalc_rate(struct clk_hw *hw,
>> + unsigned long parent_rate)
>> +{
>> +[...]
>> +}
>
> Can't this be made static? It compiles cleanly with static too. Is there
> some subtle issue I'm missing?
>
Absolutely. I must have missed them for some functions.
>> +static const struct clk_ops si5338_divrefclk_ops = {
>> +.recalc_rate = si5338_divrefclk_recalc_rate,
>> +};
>
>> +unsigned long si5338_divfbclk_recalc_rate(struct clk_hw *hw,
>> + unsigned long parent_rate)
>> +{
>> +[...]
>> +}
>
> Ditto.
>
>> +static const struct clk_ops si5338_divfbclk_ops = {
>> +.recalc_rate = si5338_divfbclk_recalc_rate,
>> +};
>
>> --- /dev/null
>> +++ b/include/dt-bindings/clock/clk-si5338.h
>
>> +#ifndef _DT_BINDINGS_CLK_DSI5338_H
>> +#define _DT_BINDINGS_CLK_DSI5338_H
>
> (I spotted a D that looks odd here.)
Me, too. It takes fresh eyes to spot this non-sense error.
>
> And git am whines:
> new blank line at EOF.
Thanks.
York
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2 12/12] Documentation: binding: add sclk adjustment properties to i2c-pxa
On Tuesday 16 June 2015 06:52 PM, Rob Herring wrote: On Mon, Jun 15, 2015 at 10:49 AM, Vaibhav Hiremath wrote: With addition of PXA910 family of devices, the TWSI module supports new feature which allows us to adjust SCLK. With DT properties i2c-pxa driver takes input configuration in nsec and converts it to respective bit-fields, - i2c-sclk-low-time-ns : SCLK low time (tlow) This property is used along with mode selection. - i2c-sclk-high-time-ns : SCLK high time (thigh) Signed-off-by: Vaibhav Hiremath --- Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt index 9657db5..0fafd91 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt @@ -23,12 +23,25 @@ Optional properties : - i2c-disable-after-xfer : If set, driver will disable I2C module after msg xfer and enable it again before xfer. + (Applicable to PXA910 family): + + - i2c-sclk-low-time-ns : SCLK low time (tlow), for standard/fast/high + speed mode. + This property is used along with mode selection. Driver uses this property + to set low/high time for standard and fast speed mode, as counter bit-field + is same for both. This belongs below both properties, and it should be clear that both properties are required if present. Technically, both properties are required only in case of high_mode. As mentioned above, in case of standard and fast mode we use tLow value. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2 12/12] Documentation: binding: add sclk adjustment properties to i2c-pxa
On Mon, Jun 15, 2015 at 10:49 AM, Vaibhav Hiremath wrote: > With addition of PXA910 family of devices, the TWSI module supports > new feature which allows us to adjust SCLK. > With DT properties i2c-pxa driver takes input configuration > in nsec and converts it to respective bit-fields, > > - i2c-sclk-low-time-ns : SCLK low time (tlow) >This property is used along with mode selection. > - i2c-sclk-high-time-ns : SCLK high time (thigh) > > Signed-off-by: Vaibhav Hiremath > --- > Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt > b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt > index 9657db5..0fafd91 100644 > --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt > +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt > @@ -23,12 +23,25 @@ Optional properties : > - i2c-disable-after-xfer : If set, driver will disable I2C module > after msg xfer and enable it again before xfer. > > + (Applicable to PXA910 family): > + > + - i2c-sclk-low-time-ns : SCLK low time (tlow), for standard/fast/high > + speed mode. > + This property is used along with mode selection. Driver uses this property > + to set low/high time for standard and fast speed mode, as counter > bit-field > + is same for both. This belongs below both properties, and it should be clear that both properties are required if present. > + - i2c-sclk-high-time-ns : SCLK high time (thigh), Used in case of high speed > + mode. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC]: Supporting PIO mode of operation in i2c_msg->flags
On Tuesday 16 June 2015 02:48 PM, Wolfram Sang wrote:
Any update on this?
Not yet.
a) there was no code to look at
Actually its simple question, whether we can call i2c_transfer in
pm_power_off fn, where interupts are disabled and i2c_transfer fn may
sleep.
Just to illustrate my point,
I just quickly created something for you. Correct me if I am wrong here.
pm_power_off Usecase:
=
File: arch/arm64/kernel/process.c
void machine_power_off(void)
{
local_irq_disable();
smp_send_stop();
if (pm_power_off)
pm_power_off();
}
Dummy pm_power_off Implementation:
=
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 03b70f8..e364a2a 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1170,7 +1170,10 @@ static int i2c_pxa_xfer(struct i2c_adapter *adap,
struct i2c_msg msgs[], int num
i2c_pxa_enable(i2c, true);
for (i = adap->retries; i >= 0; i--) {
- ret = i2c_pxa_do_xfer(i2c, msgs, num);
+ if (msgs[0].flags & I2C_M_PIO)
+ ret = i2c_pxa_do_pio_xfer(i2c, msgs, num);
+ else
+ ret = i2c_pxa_do_xfer(i2c, msgs, num);
if (ret != I2C_RETRY)
goto out;
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 0464e2d..2d7b11b 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -488,6 +488,52 @@ static void pm800_pages_exit(struct pm80x_chip *chip)
i2c_unregister_device(subchip->gpadc_page);
}
+static struct pm80x_chip *pm80x_chip_g;
+
+#define PM800_SW_PDOWN (1 << 5)
+
+static void pm800_power_off(void)
+{
+ u8 data, buf[2];
+ struct i2c_msg msgs[2];
+ struct i2c_client *client = pm80x_chip_g->client;
+
+ pr_info("turning off power\n");
+
+ /*
+* pm_power_off fn get called at the end of machine_power_off(),
+* so at this stage the irqs are disabled, so we have to use
+* PIO mode of I2C transaction for both read and write.
+*/
+ /* Read register first */
+ msgs[0].addr = client->addr;
+ msgs[0].flags = I2C_M_PIO;
+ msgs[0].len = 1;
+ msgs[0].buf = buf;
+
+ msgs[1].addr = client->addr;
+ msgs[1].flags = I2C_M_RD | I2C_M_PIO;
+ msgs[1].len = 1;
+ msgs[1].buf = &data;
+
+ buf[0] = PM800_WAKEUP1;
+ if ( __i2c_transfer(client->adapter, msgs, 2) < 0) {
+ pr_err("%s read register fails...\n", __func__);
+ WARN_ON(1);
+ }
+
+ /* issue SW power down */
+ msgs[0].addr = client->addr;
+ msgs[0].flags = I2C_M_PIO;
+ msgs[0].len = 2;
+ msgs[0].buf[0] = PM800_WAKEUP1;
+ msgs[0].buf[1] = data | PM800_SW_PDOWN;
+ if (__i2c_transfer(client->adapter, msgs, 1) < 0) {
+ pr_err("%s write data fails...\n", __func__);
+ WARN_ON(1);
+ }
+}
+
static int device_800_init(struct pm80x_chip *chip,
struct pm80x_platform_data *pdata)
{
@@ -612,6 +658,10 @@ static int pm800_probe(struct i2c_client *client,
if (pdata && pdata->plat_config)
pdata->plat_config(chip, pdata);
+ /* keep global copy, required in power_off fn */
+ pm80x_chip_g = chip;
+ pm_power_off = pm800_power_off;
+
return 0;
err_device_init:
diff --git a/include/uapi/linux/i2c.h b/include/uapi/linux/i2c.h
index 0e949cb..22fda83 100644
--- a/include/uapi/linux/i2c.h
+++ b/include/uapi/linux/i2c.h
@@ -76,6 +76,7 @@ struct i2c_msg {
#define I2C_M_IGNORE_NAK 0x1000 /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_NO_RD_ACK0x0800 /* if
I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_RECV_LEN 0x0400 /* length will be first
received byte */
+#define I2C_M_PIO 0x0200 /* pio mode of transaction */
__u16 len; /* msg length */
__u8 *buf; /* pointer to msg data */
};
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC]: Supporting PIO mode of operation in i2c_msg->flags
> Any update on this? Not yet. a) there was no code to look at b) have a look here for current pending patches: http://patchwork.ozlabs.org/project/linux-i2c/list/ I will answer when time is due. signature.asc Description: Digital signature
Re: [RFC]: Supporting PIO mode of operation in i2c_msg->flags
On Sunday 14 June 2015 05:42 PM, Vaibhav Hiremath wrote:
On Friday 12 June 2015 05:11 AM, Wolfram Sang wrote:
Current implementation:
Everyone probably does have their own custom implementation for this.
Or some other mechanism to achieve this (may be hardware support).
Do you have examples? It is easier to look at code.
As I mentioned in the "Problem Statement",
I2C interface for PMIC may need to be used at the end of poweroff
sequence where you cannot afford to sleep/schedule, as interrupt has
been disabled.
Earlier I was working on OMAP platform, where I remember we had
implemented something for such requirement, but as I am not in TI
anymore, I can not access the internal code.
Let me check whether I can share the current marvell codebase
outside.
/* We can also check i2c_check_functionality(adap,I2C_FUNC_PIO) */
if (msg->flags & I2C_M_PIO) {
/* PIO mode operation */
} else {
/* non-pio mode of operation */
}
I'd rather let the core decide. Like introduce a master_xfer_nosleep
callback and let the core use the standard or the nosleep one. We'd need
the same for smbus as well.
This leads to the question if we need a M_FLAG or expose the *_nosleep
functions directly?
I thought of it, but did not convince myself after looking at the usage
of this. This function would be used only when interrupt is disabled.
And I wonder about the demand for it. There are a number of SoCs with
designated I2C cores for the PMIC which do automated transfers.
This is exactly the same reason I did not propose it as a core change.
as I feel that the use of this is very minimal and with M_FLAG driver
can very well handle it.
Wolfram,
Any update on this?
If we could close on this, I can quickly change the code and submit the
patch for review.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-RESEND 0/3] i2c: core/pxa: Add support for hardware lock
On Wednesday 03 June 2015 12:15 AM, Vaibhav Hiremath wrote: To justify the need for hardware lock, lets take a real usecase scenario - In case of Marvell SoC, PXA910 silicon, both AP and CP are present and these two ARM cores are sharing one pair of I2C pins. In order to keep I2C transaction operated with atomic, hardware lock (RIPC) is required. This patch extends support for atomic operation by adding hardware lock support to the i2c-core. PATCH[1/3] : Core changes for hardware lock PATCH[2/3 & 3/3] : hardware lock support to i2c-pxa bus driver. Link to previous post: http://lkml.iu.edu/hypermail/linux/kernel/1104.3/02352.html http://lkml.iu.edu/hypermail/linux/kernel/1104.3/02353.html http://lkml.iu.edu/hypermail/linux/kernel/1104.3/02354.html TODO: - DT node addition I am using PXA1928 based platform which is still not available in Mainline, so it is based on, below patch-series Link to Rob's patches: https://lkml.org/lkml/2015/5/1/14 https://lkml.org/lkml/2015/5/19/1206 PMIC 88pm860 support http://www.spinics.net/lists/arm-kernel/msg422554.html Vaibhav Hiremath (3): i2c: core: append hardware lock with bus lock i2c: pxa: Add support for hardware lock i2c: pxa: Add pin ctrl support for CP core access Wolfram, Any update on this patch-series? Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2] driver/clk/clk-si5338: Add common clock framework driver for si5338
One question and a few nits follow.
On Mon, 2015-06-15 at 10:07 -0700, York Sun wrote:
> SI5338 is a programmable clock generator. It has 4 sets of inputs,
> PLL, multisynth and dividers to make 4 outputs. This driver splits
> them into multiple clocks to comply with common clock framework.
>
> See Documentation/devicetree/bindings/clock/silabs,si5338.txt for
> details.
>
> Signed-off-by: York Sun
> CC: Mike Turquette
Apparently that's now mturque...@baylibre.com .
> CC: Sebastian Hesselbarth
> CC: Guenter Roeck
> CC: Andrey Filippov
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> config COMMON_CLK
> - bool
> + tristate "Common Clock"
> select HAVE_CLK_PREPARE
> select CLKDEV_LOOKUP
> select SRCU
Why? The commit explanation doesn't mention this. Did you use an unclean
tree? If not, you just created over a dozen of new modules:
$ git grep -nw CONFIG_COMMON_CLK -- "*Makefile*"
arch/arm/mach-mmp/Makefile:13:ifeq ($(CONFIG_COMMON_CLK), )
arch/arm/mach-shmobile/Makefile:21:ifndef CONFIG_COMMON_CLK
arch/powerpc/platforms/512x/Makefile:4:obj-$(CONFIG_COMMON_CLK) +=
clock-commonclk.o
drivers/clk/Makefile:4:obj-$(CONFIG_COMMON_CLK) += clk.o
drivers/clk/Makefile:5:obj-$(CONFIG_COMMON_CLK) += clk-divider.o
drivers/clk/Makefile:6:obj-$(CONFIG_COMMON_CLK) += clk-fixed-factor.o
drivers/clk/Makefile:7:obj-$(CONFIG_COMMON_CLK) += clk-fixed-rate.o
drivers/clk/Makefile:8:obj-$(CONFIG_COMMON_CLK) += clk-gate.o
drivers/clk/Makefile:9:obj-$(CONFIG_COMMON_CLK) += clk-mux.o
drivers/clk/Makefile:10:obj-$(CONFIG_COMMON_CLK)+= clk-composite.o
drivers/clk/Makefile:11:obj-$(CONFIG_COMMON_CLK)+=
clk-fractional-divider.o
drivers/clk/Makefile:12:obj-$(CONFIG_COMMON_CLK)+= clk-gpio-gate.o
drivers/clk/Makefile:14:obj-$(CONFIG_COMMON_CLK)+= clk-conf.o
drivers/clk/Makefile:59:ifeq ($(CONFIG_COMMON_CLK), y)
drivers/clk/samsung/Makefile:5:obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
drivers/gpu/drm/msm/Makefile:53:msm-$(CONFIG_COMMON_CLK) +=
mdp/mdp4/mdp4_lvds_pll.o
drivers/sh/Makefile:5:ifneq ($(CONFIG_COMMON_CLK),y)
> +config COMMON_CLK_SI5338
> + tristate "Clock driver for SiLabs 5338"
> + depends on I2C
> + select REGMAP_I2C
> + select RATIONAL
> + ---help---
> + This driver supports Silicon Labs 5338 programmable clock generators,
> + using common clock framework. It needs parent clock as input(s).
> + Internal clocks are registered with unique names in case multiple
> + devices exist. See devicetree/bindings/clock/silabs,si5338.txt
> + under Documentation for details.
> --- /dev/null
> +++ b/drivers/clk/clk-si5338.c
> +unsigned long si5338_divrefclk_recalc_rate(struct clk_hw *hw,
> +unsigned long parent_rate)
> +{
> + [...]
> +}
Can't this be made static? It compiles cleanly with static too. Is there
some subtle issue I'm missing?
> +static const struct clk_ops si5338_divrefclk_ops = {
> + .recalc_rate = si5338_divrefclk_recalc_rate,
> +};
> +unsigned long si5338_divfbclk_recalc_rate(struct clk_hw *hw,
> +unsigned long parent_rate)
> +{
> + [...]
> +}
Ditto.
> +static const struct clk_ops si5338_divfbclk_ops = {
> + .recalc_rate = si5338_divfbclk_recalc_rate,
> +};
> --- /dev/null
> +++ b/include/dt-bindings/clock/clk-si5338.h
> +#ifndef _DT_BINDINGS_CLK_DSI5338_H
> +#define _DT_BINDINGS_CLK_DSI5338_H
(I spotted a D that looks odd here.)
And git am whines:
new blank line at EOF.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2 03/12] i2c: pxa: Return I2C_RETRY when timeout in pio mode
On Tuesday 16 June 2015 11:01 AM, Shubhrajyoti Datta wrote:
On Mon, Jun 15, 2015 at 9:19 PM, Vaibhav Hiremath
wrote:
From: Shouming Wang
In case of timeout in pio mode of operation return I2C_RETRY.
This behavior will be same as interrupt mode of operation.
Signed-off-by: Shouming Wang
[vaibhav.hirem...@linaro.org: Updated changelog]
Signed-off-by: Vaibhav Hiremath
---
drivers/i2c/busses/i2c-pxa.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 023e59f..632008f 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -745,8 +745,10 @@ static int i2c_pxa_do_pio_xfer(struct pxa_i2c *i2c,
ret = i2c->msg_idx;
out:
- if (timeout == 0)
+ if (timeout == 0) {
i2c_pxa_scream_blue_murder(i2c, "timeout");
+ ret = I2C_RETRY;
Can we use standard return types.
Unfortunately NO.
I2C_RETRY is used in many places, internal to the i2c-pcxa driver.
This return value is internal only and used internally to the driver.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
