Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
Hi Wolfram,
On 11/01/2013 12:16 PM, Wolfram Sang wrote:
Hi,
...
diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt
b/Documentation/devicetree/bindings/i2c/i2c-st.txt
new file mode 100644
index 000..8b2fd0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt
@@ -0,0 +1,38 @@
+ST SSC binding, for I2C mode operation
+
+Required properties :
+- compatible : Must be "st,comms-i2c"
I personally don't care about naming here. Has there been a solution
now?
Srini proposes to add 2 compatible strings, as the IP is compatible with
two SSC IPs:
"st,comms-ssc-i2c"
"st,comms-ssc4-i2c"
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+ the default 100 kHz frequency will be used. As only Normal and Fast modes
+ are supported, possible values are 10 and 40.
+- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is
+ allowed through the deglitch circuit. In units of us.
+- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is
+ allowed through the deglitch circuit. In units of us.
Okay, so we had lots of dt bindings discussions at kernel summit. Since
we don't have unstable bindings yet, I have been convinced that it is
okay two have one or two vendor specific bindings before introducing a
generic one. That will create a little bit of cruft, but increases
chances that the generic bindings are proper. So, really sorry for going
back and forth, but it was important for the process. Vendor binding is
it now. Period.
...
No problem wolfram! Thanks for clarifying this thing.
+/**
+ * struct st_i2c_deglitch - Anti-glitch filter configuration
+ * @scl_min_width_us: SCL line minimum pulse width in ns
+ * @sda_min_width_us: SDA line minimum pulse width in ns
+ */
+struct st_i2c_deglitch {
+ u32 scl_min_width_us;
+ u32 sda_min_width_us;
+};
Minor: Why a seperate struct?
This not needed, I will move its fields into st_i2c_dev struct.
+/**
+ * st_i2c_handle_write() - Handle FIFO enmpty interrupt in case of read
+ * @i2c_dev: Controller's private data
+ */
+static void st_i2c_handle_read(struct st_i2c_dev *i2c_dev)
+{
+ struct st_i2c_client *c = _dev->client;
+ u32 ien;
+
+ /* Trash the address read back */
+ if (!c->xfered) {
+ readl(i2c_dev->base + SSC_RBUF);
+ st_i2c_clr_bits(i2c_dev->base + SSC_I2C, SSC_I2C_TXENB);
+ } else
+ st_i2c_read_rx_fifo(i2c_dev);
Braces around else branch.
Okay
+
+ if (!c->count) {
+ /* End of xfer, send stop or repstart */
+ st_i2c_terminate_xfer(i2c_dev);
+ } else if (c->count == 1) {
+ /* Penultimate byte to xfer, disable ACK gen. */
+ st_i2c_clr_bits(i2c_dev->base + SSC_I2C, SSC_I2C_ACKG);
+
+ /* Last received byte is to be handled by NACK interrupt */
+ ien = SSC_IEN_NACKEN | SSC_IEN_ARBLEN;
+ writel(ien, i2c_dev->base + SSC_IEN);
+
+ st_i2c_rd_fill_tx_fifo(i2c_dev, c->count);
+ } else
+ st_i2c_rd_fill_tx_fifo(i2c_dev, c->count - 1);
Braces around else branch.
Ditto
+}
+static int st_i2c_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct st_i2c_dev *i2c_dev;
+ struct resource *res;
+ u32 clk_rate;
+ struct i2c_adapter *adap;
+ int ret;
+
+ i2c_dev = devm_kzalloc(>dev, sizeof(*i2c_dev), GFP_KERNEL);
+ if (!i2c_dev)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ i2c_dev->base = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(i2c_dev->base))
+ return PTR_ERR(i2c_dev->base);
+
+ i2c_dev->irq = irq_of_parse_and_map(np, 0);
+ if (!i2c_dev->irq) {
+ dev_err(>dev, "IRQ missing or invalid\n");
+ return -EINVAL;
+ }
+
+ i2c_dev->clk = of_clk_get_by_name(np, "ssc");
+ if (IS_ERR(i2c_dev->clk)) {
+ dev_err(>dev, "Unable to request clock\n");
+ return PTR_ERR(i2c_dev->clk);
+ }
+
+ i2c_dev->mode = I2C_MODE_STANDARD;
+ ret = of_property_read_u32(np, "clock-frequency", _rate);
+ if ((!ret) && (clk_rate == 40))
+ i2c_dev->mode = I2C_MODE_FAST;
+
+ i2c_dev->dev = >dev;
+
+ ret = devm_request_irq(>dev, i2c_dev->irq, st_i2c_isr, 0,
+ pdev->name, i2c_dev);
Suggestion: Maybe threaded irq since you do fifo handling in the isr?
That's a good point, I will switch to threaded irq.
+ if (ret) {
+ dev_err(>dev, "Failed to request irq %i\n", i2c_dev->irq);
+ return ret;
+ }
+
+ pinctrl_pm_select_default_state(i2c_dev->dev);
+ /* In case idle state available, select it */
+ pinctrl_pm_select_idle_state(i2c_dev->dev);
+
+ ret =
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
Hi Wolfram,
On 11/01/2013 12:16 PM, Wolfram Sang wrote:
Hi,
...
diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt
b/Documentation/devicetree/bindings/i2c/i2c-st.txt
new file mode 100644
index 000..8b2fd0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt
@@ -0,0 +1,38 @@
+ST SSC binding, for I2C mode operation
+
+Required properties :
+- compatible : Must be st,comms-i2c
I personally don't care about naming here. Has there been a solution
now?
Srini proposes to add 2 compatible strings, as the IP is compatible with
two SSC IPs:
st,comms-ssc-i2c
st,comms-ssc4-i2c
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+ the default 100 kHz frequency will be used. As only Normal and Fast modes
+ are supported, possible values are 10 and 40.
+- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is
+ allowed through the deglitch circuit. In units of us.
+- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is
+ allowed through the deglitch circuit. In units of us.
Okay, so we had lots of dt bindings discussions at kernel summit. Since
we don't have unstable bindings yet, I have been convinced that it is
okay two have one or two vendor specific bindings before introducing a
generic one. That will create a little bit of cruft, but increases
chances that the generic bindings are proper. So, really sorry for going
back and forth, but it was important for the process. Vendor binding is
it now. Period.
...
No problem wolfram! Thanks for clarifying this thing.
+/**
+ * struct st_i2c_deglitch - Anti-glitch filter configuration
+ * @scl_min_width_us: SCL line minimum pulse width in ns
+ * @sda_min_width_us: SDA line minimum pulse width in ns
+ */
+struct st_i2c_deglitch {
+ u32 scl_min_width_us;
+ u32 sda_min_width_us;
+};
Minor: Why a seperate struct?
This not needed, I will move its fields into st_i2c_dev struct.
+/**
+ * st_i2c_handle_write() - Handle FIFO enmpty interrupt in case of read
+ * @i2c_dev: Controller's private data
+ */
+static void st_i2c_handle_read(struct st_i2c_dev *i2c_dev)
+{
+ struct st_i2c_client *c = i2c_dev-client;
+ u32 ien;
+
+ /* Trash the address read back */
+ if (!c-xfered) {
+ readl(i2c_dev-base + SSC_RBUF);
+ st_i2c_clr_bits(i2c_dev-base + SSC_I2C, SSC_I2C_TXENB);
+ } else
+ st_i2c_read_rx_fifo(i2c_dev);
Braces around else branch.
Okay
+
+ if (!c-count) {
+ /* End of xfer, send stop or repstart */
+ st_i2c_terminate_xfer(i2c_dev);
+ } else if (c-count == 1) {
+ /* Penultimate byte to xfer, disable ACK gen. */
+ st_i2c_clr_bits(i2c_dev-base + SSC_I2C, SSC_I2C_ACKG);
+
+ /* Last received byte is to be handled by NACK interrupt */
+ ien = SSC_IEN_NACKEN | SSC_IEN_ARBLEN;
+ writel(ien, i2c_dev-base + SSC_IEN);
+
+ st_i2c_rd_fill_tx_fifo(i2c_dev, c-count);
+ } else
+ st_i2c_rd_fill_tx_fifo(i2c_dev, c-count - 1);
Braces around else branch.
Ditto
+}
+static int st_i2c_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct st_i2c_dev *i2c_dev;
+ struct resource *res;
+ u32 clk_rate;
+ struct i2c_adapter *adap;
+ int ret;
+
+ i2c_dev = devm_kzalloc(pdev-dev, sizeof(*i2c_dev), GFP_KERNEL);
+ if (!i2c_dev)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ i2c_dev-base = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(i2c_dev-base))
+ return PTR_ERR(i2c_dev-base);
+
+ i2c_dev-irq = irq_of_parse_and_map(np, 0);
+ if (!i2c_dev-irq) {
+ dev_err(pdev-dev, IRQ missing or invalid\n);
+ return -EINVAL;
+ }
+
+ i2c_dev-clk = of_clk_get_by_name(np, ssc);
+ if (IS_ERR(i2c_dev-clk)) {
+ dev_err(pdev-dev, Unable to request clock\n);
+ return PTR_ERR(i2c_dev-clk);
+ }
+
+ i2c_dev-mode = I2C_MODE_STANDARD;
+ ret = of_property_read_u32(np, clock-frequency, clk_rate);
+ if ((!ret) (clk_rate == 40))
+ i2c_dev-mode = I2C_MODE_FAST;
+
+ i2c_dev-dev = pdev-dev;
+
+ ret = devm_request_irq(pdev-dev, i2c_dev-irq, st_i2c_isr, 0,
+ pdev-name, i2c_dev);
Suggestion: Maybe threaded irq since you do fifo handling in the isr?
That's a good point, I will switch to threaded irq.
+ if (ret) {
+ dev_err(pdev-dev, Failed to request irq %i\n, i2c_dev-irq);
+ return ret;
+ }
+
+ pinctrl_pm_select_default_state(i2c_dev-dev);
+ /* In case idle state available, select it */
+ pinctrl_pm_select_idle_state(i2c_dev-dev);
+
+ ret =
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 28/10/13 15:02, Maxime Coquelin wrote: >> >> 6> IMHO, the compatible string should be "vendor,-" >> rather than first SoC. > I agree. > In this case, we add support to revision 4 of SSC IP. Its not the revision its name of the new IP which is SSC4. However this driver is also compatible with old SSC IP, so It would be nice to have something like two compatible strings "st,comms-ssc-i2c" and "st,comms-ssc4-i2c" Thanks, srini > > Is "st,comms-ssc-v4" okay? -- 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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
Hi,
On Mon, Oct 14, 2013 at 02:46:49PM +0200, Maxime COQUELIN wrote:
> This patch adds support to SSC (Synchronous Serial Controller)
> I2C driver. This IP also supports SPI protocol, but this is not
> the aim of this driver.
>
> This IP is embedded in all ST SoCs for Set-top box platorms, and
> supports I2C Standard and Fast modes.
>
> Signed-off-by: Maxime Coquelin
> ---
> Documentation/devicetree/bindings/i2c/i2c-st.txt | 38 +
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile |1 +
> drivers/i2c/busses/i2c-st.c | 867
> ++
> 4 files changed, 916 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st.txt
> create mode 100644 drivers/i2c/busses/i2c-st.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt
> b/Documentation/devicetree/bindings/i2c/i2c-st.txt
> new file mode 100644
> index 000..8b2fd0b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt
> @@ -0,0 +1,38 @@
> +ST SSC binding, for I2C mode operation
> +
> +Required properties :
> +- compatible : Must be "st,comms-i2c"
I personally don't care about naming here. Has there been a solution
now?
> +- reg : Offset and length of the register set for the device
> +- interrupts : the interrupt specifier
> +- clock-names: Must contain "ssc".
> +- clocks: Must contain an entry for each name in clock-names. See the common
> + clock bindings.
> +- A pinctrl state named "default" must be defined, using the bindings in
> + ../pinctrl/pinctrl-binding.txt
> +
> +Optional properties :
> +- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
> + the default 100 kHz frequency will be used. As only Normal and Fast modes
> + are supported, possible values are 10 and 40.
> +- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is
> + allowed through the deglitch circuit. In units of us.
> +- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is
> + allowed through the deglitch circuit. In units of us.
Okay, so we had lots of dt bindings discussions at kernel summit. Since
we don't have unstable bindings yet, I have been convinced that it is
okay two have one or two vendor specific bindings before introducing a
generic one. That will create a little bit of cruft, but increases
chances that the generic bindings are proper. So, really sorry for going
back and forth, but it was important for the process. Vendor binding is
it now. Period.
...
> +/**
> + * struct st_i2c_deglitch - Anti-glitch filter configuration
> + * @scl_min_width_us: SCL line minimum pulse width in ns
> + * @sda_min_width_us: SDA line minimum pulse width in ns
> + */
> +struct st_i2c_deglitch {
> + u32 scl_min_width_us;
> + u32 sda_min_width_us;
> +};
Minor: Why a seperate struct?
> +/**
> + * st_i2c_handle_write() - Handle FIFO enmpty interrupt in case of read
> + * @i2c_dev: Controller's private data
> + */
> +static void st_i2c_handle_read(struct st_i2c_dev *i2c_dev)
> +{
> + struct st_i2c_client *c = _dev->client;
> + u32 ien;
> +
> + /* Trash the address read back */
> + if (!c->xfered) {
> + readl(i2c_dev->base + SSC_RBUF);
> + st_i2c_clr_bits(i2c_dev->base + SSC_I2C, SSC_I2C_TXENB);
> + } else
> + st_i2c_read_rx_fifo(i2c_dev);
Braces around else branch.
> +
> + if (!c->count) {
> + /* End of xfer, send stop or repstart */
> + st_i2c_terminate_xfer(i2c_dev);
> + } else if (c->count == 1) {
> + /* Penultimate byte to xfer, disable ACK gen. */
> + st_i2c_clr_bits(i2c_dev->base + SSC_I2C, SSC_I2C_ACKG);
> +
> + /* Last received byte is to be handled by NACK interrupt */
> + ien = SSC_IEN_NACKEN | SSC_IEN_ARBLEN;
> + writel(ien, i2c_dev->base + SSC_IEN);
> +
> + st_i2c_rd_fill_tx_fifo(i2c_dev, c->count);
> + } else
> + st_i2c_rd_fill_tx_fifo(i2c_dev, c->count - 1);
Braces around else branch.
> +}
> +static int st_i2c_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct st_i2c_dev *i2c_dev;
> + struct resource *res;
> + u32 clk_rate;
> + struct i2c_adapter *adap;
> + int ret;
> +
> + i2c_dev = devm_kzalloc(>dev, sizeof(*i2c_dev), GFP_KERNEL);
> + if (!i2c_dev)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + i2c_dev->base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(i2c_dev->base))
> + return PTR_ERR(i2c_dev->base);
> +
> + i2c_dev->irq = irq_of_parse_and_map(np, 0);
> + if (!i2c_dev->irq) {
> + dev_err(>dev, "IRQ missing or invalid\n");
> + return -EINVAL;
> + }
> +
> + i2c_dev->clk = of_clk_get_by_name(np, "ssc");
> + if (IS_ERR(i2c_dev->clk)) {
> +
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
Hi,
On Mon, Oct 14, 2013 at 02:46:49PM +0200, Maxime COQUELIN wrote:
This patch adds support to SSC (Synchronous Serial Controller)
I2C driver. This IP also supports SPI protocol, but this is not
the aim of this driver.
This IP is embedded in all ST SoCs for Set-top box platorms, and
supports I2C Standard and Fast modes.
Signed-off-by: Maxime Coquelin maxime.coque...@st.com
---
Documentation/devicetree/bindings/i2c/i2c-st.txt | 38 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-st.c | 867
++
4 files changed, 916 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st.txt
create mode 100644 drivers/i2c/busses/i2c-st.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt
b/Documentation/devicetree/bindings/i2c/i2c-st.txt
new file mode 100644
index 000..8b2fd0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt
@@ -0,0 +1,38 @@
+ST SSC binding, for I2C mode operation
+
+Required properties :
+- compatible : Must be st,comms-i2c
I personally don't care about naming here. Has there been a solution
now?
+- reg : Offset and length of the register set for the device
+- interrupts : the interrupt specifier
+- clock-names: Must contain ssc.
+- clocks: Must contain an entry for each name in clock-names. See the common
+ clock bindings.
+- A pinctrl state named default must be defined, using the bindings in
+ ../pinctrl/pinctrl-binding.txt
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+ the default 100 kHz frequency will be used. As only Normal and Fast modes
+ are supported, possible values are 10 and 40.
+- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is
+ allowed through the deglitch circuit. In units of us.
+- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is
+ allowed through the deglitch circuit. In units of us.
Okay, so we had lots of dt bindings discussions at kernel summit. Since
we don't have unstable bindings yet, I have been convinced that it is
okay two have one or two vendor specific bindings before introducing a
generic one. That will create a little bit of cruft, but increases
chances that the generic bindings are proper. So, really sorry for going
back and forth, but it was important for the process. Vendor binding is
it now. Period.
...
+/**
+ * struct st_i2c_deglitch - Anti-glitch filter configuration
+ * @scl_min_width_us: SCL line minimum pulse width in ns
+ * @sda_min_width_us: SDA line minimum pulse width in ns
+ */
+struct st_i2c_deglitch {
+ u32 scl_min_width_us;
+ u32 sda_min_width_us;
+};
Minor: Why a seperate struct?
+/**
+ * st_i2c_handle_write() - Handle FIFO enmpty interrupt in case of read
+ * @i2c_dev: Controller's private data
+ */
+static void st_i2c_handle_read(struct st_i2c_dev *i2c_dev)
+{
+ struct st_i2c_client *c = i2c_dev-client;
+ u32 ien;
+
+ /* Trash the address read back */
+ if (!c-xfered) {
+ readl(i2c_dev-base + SSC_RBUF);
+ st_i2c_clr_bits(i2c_dev-base + SSC_I2C, SSC_I2C_TXENB);
+ } else
+ st_i2c_read_rx_fifo(i2c_dev);
Braces around else branch.
+
+ if (!c-count) {
+ /* End of xfer, send stop or repstart */
+ st_i2c_terminate_xfer(i2c_dev);
+ } else if (c-count == 1) {
+ /* Penultimate byte to xfer, disable ACK gen. */
+ st_i2c_clr_bits(i2c_dev-base + SSC_I2C, SSC_I2C_ACKG);
+
+ /* Last received byte is to be handled by NACK interrupt */
+ ien = SSC_IEN_NACKEN | SSC_IEN_ARBLEN;
+ writel(ien, i2c_dev-base + SSC_IEN);
+
+ st_i2c_rd_fill_tx_fifo(i2c_dev, c-count);
+ } else
+ st_i2c_rd_fill_tx_fifo(i2c_dev, c-count - 1);
Braces around else branch.
+}
+static int st_i2c_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct st_i2c_dev *i2c_dev;
+ struct resource *res;
+ u32 clk_rate;
+ struct i2c_adapter *adap;
+ int ret;
+
+ i2c_dev = devm_kzalloc(pdev-dev, sizeof(*i2c_dev), GFP_KERNEL);
+ if (!i2c_dev)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ i2c_dev-base = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(i2c_dev-base))
+ return PTR_ERR(i2c_dev-base);
+
+ i2c_dev-irq = irq_of_parse_and_map(np, 0);
+ if (!i2c_dev-irq) {
+ dev_err(pdev-dev, IRQ missing or invalid\n);
+ return -EINVAL;
+ }
+
+ i2c_dev-clk = of_clk_get_by_name(np, ssc);
+ if (IS_ERR(i2c_dev-clk)) {
+ dev_err(pdev-dev, Unable to request clock\n);
+ return PTR_ERR(i2c_dev-clk);
+
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 28/10/13 15:02, Maxime Coquelin wrote: 6 IMHO, the compatible string should be vendor,IP-name-IP-version rather than first SoC. I agree. In this case, we add support to revision 4 of SSC IP. Its not the revision its name of the new IP which is SSC4. However this driver is also compatible with old SSC IP, so It would be nice to have something like two compatible strings st,comms-ssc-i2c and st,comms-ssc4-i2c Thanks, srini Is st,comms-ssc-v4 okay? -- 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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On Oct 29, 2013, at 8:19 AM, Maxime Coquelin wrote: > > On 10/28/2013 08:25 PM, Kumar Gala wrote: >> On Oct 14, 2013, at 7:46 AM, Maxime COQUELIN wrote: >> >>> This patch adds support to SSC (Synchronous Serial Controller) >>> I2C driver. This IP also supports SPI protocol, but this is not >>> the aim of this driver. >>> >>> This IP is embedded in all ST SoCs for Set-top box platorms, and >>> supports I2C Standard and Fast modes. >>> >>> Signed-off-by: Maxime Coquelin >>> --- >>> Documentation/devicetree/bindings/i2c/i2c-st.txt | 38 + >>> drivers/i2c/busses/Kconfig | 10 + >>> drivers/i2c/busses/Makefile |1 + >>> drivers/i2c/busses/i2c-st.c | 867 >>> ++ >>> 4 files changed, 916 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st.txt >>> create mode 100644 drivers/i2c/busses/i2c-st.c >>> >>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt >>> b/Documentation/devicetree/bindings/i2c/i2c-st.txt >>> new file mode 100644 >>> index 000..8b2fd0b >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt >>> @@ -0,0 +1,38 @@ >>> +ST SSC binding, for I2C mode operation >>> + >>> +Required properties : >>> +- compatible : Must be "st,comms-i2c" >>> +- reg : Offset and length of the register set for the device >>> +- interrupts : the interrupt specifier >>> +- clock-names: Must contain "ssc". >>> +- clocks: Must contain an entry for each name in clock-names. See the >>> common >>> + clock bindings. >>> +- A pinctrl state named "default" must be defined, using the bindings in >>> + ../pinctrl/pinctrl-binding.txt >>> + >>> +Optional properties : >>> +- clock-frequency : Desired I2C bus clock frequency in Hz. If not >>> specified, >>> + the default 100 kHz frequency will be used. As only Normal and Fast modes >>> + are supported, possible values are 10 and 40. >>> +- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is >>> + allowed through the deglitch circuit. In units of us. >>> +- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is >>> + allowed through the deglitch circuit. In units of us. >> i2c-min... should be vendor prefixed, st,i2c-min... > This was already discussed in earlier revisions of the patches. > Initially this was prefixed with "st,", but Wolfram asked to put these > properties as generic. > As explained in the cover letter, there are no I2C DT binding documentation > for now, but it is in Wolfram's ToDo list. > As soon as Wolfram has created the documentation, I will create a patch to > document > > i2c-min-scl-pulse-width-us and i2c-min-sda-pulse-width-us there. Missed that, would be good to maybe comment about that in the commit message.. Or is there some reason to not just put them into a i2c/i2c-bus.txt right now? >>> >>> +- A pinctrl state named "sleep" could be defined, using the bindings in >>> + ../pinctrl/pinctrl-binding.txt >> I don't see any reference to "sleep" in pinctrl-binding.txt > Right, I will correct that. > > Thanks for the review, > Maxime - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 10/28/2013 08:25 PM, Kumar Gala wrote: On Oct 14, 2013, at 7:46 AM, Maxime COQUELIN wrote: This patch adds support to SSC (Synchronous Serial Controller) I2C driver. This IP also supports SPI protocol, but this is not the aim of this driver. This IP is embedded in all ST SoCs for Set-top box platorms, and supports I2C Standard and Fast modes. Signed-off-by: Maxime Coquelin --- Documentation/devicetree/bindings/i2c/i2c-st.txt | 38 + drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile |1 + drivers/i2c/busses/i2c-st.c | 867 ++ 4 files changed, 916 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st.txt create mode 100644 drivers/i2c/busses/i2c-st.c diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt b/Documentation/devicetree/bindings/i2c/i2c-st.txt new file mode 100644 index 000..8b2fd0b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt @@ -0,0 +1,38 @@ +ST SSC binding, for I2C mode operation + +Required properties : +- compatible : Must be "st,comms-i2c" +- reg : Offset and length of the register set for the device +- interrupts : the interrupt specifier +- clock-names: Must contain "ssc". +- clocks: Must contain an entry for each name in clock-names. See the common + clock bindings. +- A pinctrl state named "default" must be defined, using the bindings in + ../pinctrl/pinctrl-binding.txt + +Optional properties : +- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified, + the default 100 kHz frequency will be used. As only Normal and Fast modes + are supported, possible values are 10 and 40. +- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is + allowed through the deglitch circuit. In units of us. +- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is + allowed through the deglitch circuit. In units of us. i2c-min... should be vendor prefixed, st,i2c-min... This was already discussed in earlier revisions of the patches. Initially this was prefixed with "st,", but Wolfram asked to put these properties as generic. As explained in the cover letter, there are no I2C DT binding documentation for now, but it is in Wolfram's ToDo list. As soon as Wolfram has created the documentation, I will create a patch to document i2c-min-scl-pulse-width-us and i2c-min-sda-pulse-width-us there. +- A pinctrl state named "sleep" could be defined, using the bindings in + ../pinctrl/pinctrl-binding.txt I don't see any reference to "sleep" in pinctrl-binding.txt Right, I will correct that. Thanks for the review, Maxime - k -- 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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 10/28/2013 08:25 PM, Kumar Gala wrote: On Oct 14, 2013, at 7:46 AM, Maxime COQUELIN wrote: This patch adds support to SSC (Synchronous Serial Controller) I2C driver. This IP also supports SPI protocol, but this is not the aim of this driver. This IP is embedded in all ST SoCs for Set-top box platorms, and supports I2C Standard and Fast modes. Signed-off-by: Maxime Coquelin maxime.coque...@st.com --- Documentation/devicetree/bindings/i2c/i2c-st.txt | 38 + drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile |1 + drivers/i2c/busses/i2c-st.c | 867 ++ 4 files changed, 916 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st.txt create mode 100644 drivers/i2c/busses/i2c-st.c diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt b/Documentation/devicetree/bindings/i2c/i2c-st.txt new file mode 100644 index 000..8b2fd0b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt @@ -0,0 +1,38 @@ +ST SSC binding, for I2C mode operation + +Required properties : +- compatible : Must be st,comms-i2c +- reg : Offset and length of the register set for the device +- interrupts : the interrupt specifier +- clock-names: Must contain ssc. +- clocks: Must contain an entry for each name in clock-names. See the common + clock bindings. +- A pinctrl state named default must be defined, using the bindings in + ../pinctrl/pinctrl-binding.txt + +Optional properties : +- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified, + the default 100 kHz frequency will be used. As only Normal and Fast modes + are supported, possible values are 10 and 40. +- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is + allowed through the deglitch circuit. In units of us. +- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is + allowed through the deglitch circuit. In units of us. i2c-min... should be vendor prefixed, st,i2c-min... This was already discussed in earlier revisions of the patches. Initially this was prefixed with st,, but Wolfram asked to put these properties as generic. As explained in the cover letter, there are no I2C DT binding documentation for now, but it is in Wolfram's ToDo list. As soon as Wolfram has created the documentation, I will create a patch to document i2c-min-scl-pulse-width-us and i2c-min-sda-pulse-width-us there. +- A pinctrl state named sleep could be defined, using the bindings in + ../pinctrl/pinctrl-binding.txt I don't see any reference to sleep in pinctrl-binding.txt Right, I will correct that. Thanks for the review, Maxime - k -- 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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On Oct 29, 2013, at 8:19 AM, Maxime Coquelin wrote: On 10/28/2013 08:25 PM, Kumar Gala wrote: On Oct 14, 2013, at 7:46 AM, Maxime COQUELIN wrote: This patch adds support to SSC (Synchronous Serial Controller) I2C driver. This IP also supports SPI protocol, but this is not the aim of this driver. This IP is embedded in all ST SoCs for Set-top box platorms, and supports I2C Standard and Fast modes. Signed-off-by: Maxime Coquelin maxime.coque...@st.com --- Documentation/devicetree/bindings/i2c/i2c-st.txt | 38 + drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile |1 + drivers/i2c/busses/i2c-st.c | 867 ++ 4 files changed, 916 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st.txt create mode 100644 drivers/i2c/busses/i2c-st.c diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt b/Documentation/devicetree/bindings/i2c/i2c-st.txt new file mode 100644 index 000..8b2fd0b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt @@ -0,0 +1,38 @@ +ST SSC binding, for I2C mode operation + +Required properties : +- compatible : Must be st,comms-i2c +- reg : Offset and length of the register set for the device +- interrupts : the interrupt specifier +- clock-names: Must contain ssc. +- clocks: Must contain an entry for each name in clock-names. See the common + clock bindings. +- A pinctrl state named default must be defined, using the bindings in + ../pinctrl/pinctrl-binding.txt + +Optional properties : +- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified, + the default 100 kHz frequency will be used. As only Normal and Fast modes + are supported, possible values are 10 and 40. +- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is + allowed through the deglitch circuit. In units of us. +- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is + allowed through the deglitch circuit. In units of us. i2c-min... should be vendor prefixed, st,i2c-min... This was already discussed in earlier revisions of the patches. Initially this was prefixed with st,, but Wolfram asked to put these properties as generic. As explained in the cover letter, there are no I2C DT binding documentation for now, but it is in Wolfram's ToDo list. As soon as Wolfram has created the documentation, I will create a patch to document i2c-min-scl-pulse-width-us and i2c-min-sda-pulse-width-us there. Missed that, would be good to maybe comment about that in the commit message.. Or is there some reason to not just put them into a i2c/i2c-bus.txt right now? +- A pinctrl state named sleep could be defined, using the bindings in + ../pinctrl/pinctrl-binding.txt I don't see any reference to sleep in pinctrl-binding.txt Right, I will correct that. Thanks for the review, Maxime - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On Oct 14, 2013, at 7:46 AM, Maxime COQUELIN wrote:
> This patch adds support to SSC (Synchronous Serial Controller)
> I2C driver. This IP also supports SPI protocol, but this is not
> the aim of this driver.
>
> This IP is embedded in all ST SoCs for Set-top box platorms, and
> supports I2C Standard and Fast modes.
>
> Signed-off-by: Maxime Coquelin
> ---
> Documentation/devicetree/bindings/i2c/i2c-st.txt | 38 +
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile |1 +
> drivers/i2c/busses/i2c-st.c | 867 ++
> 4 files changed, 916 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st.txt
> create mode 100644 drivers/i2c/busses/i2c-st.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt
> b/Documentation/devicetree/bindings/i2c/i2c-st.txt
> new file mode 100644
> index 000..8b2fd0b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt
> @@ -0,0 +1,38 @@
> +ST SSC binding, for I2C mode operation
> +
> +Required properties :
> +- compatible : Must be "st,comms-i2c"
> +- reg : Offset and length of the register set for the device
> +- interrupts : the interrupt specifier
> +- clock-names: Must contain "ssc".
> +- clocks: Must contain an entry for each name in clock-names. See the common
> + clock bindings.
> +- A pinctrl state named "default" must be defined, using the bindings in
> + ../pinctrl/pinctrl-binding.txt
> +
> +Optional properties :
> +- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
> + the default 100 kHz frequency will be used. As only Normal and Fast modes
> + are supported, possible values are 10 and 40.
> +- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is
> + allowed through the deglitch circuit. In units of us.
> +- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is
> + allowed through the deglitch circuit. In units of us.
i2c-min... should be vendor prefixed, st,i2c-min...
> +- A pinctrl state named "sleep" could be defined, using the bindings in
> + ../pinctrl/pinctrl-binding.txt
I don't see any reference to "sleep" in pinctrl-binding.txt
> +
> +
> +Example :
> +
> +i2c0: i2c@fed4 {
> + compatible = "st,comms-ssc-i2c";
> + reg = <0xfed4 0x110>;
> + interrupts = ;
> + clocks = <_S_ICN_REG_0>;
> + clock-names = "ssc";
> + clock-frequency = <40>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c0_default>;
> + i2c-min-scl-pulse-width-us = <0>;
> + i2c-min-sda-pulse-width-us = <5>;
> +};
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 10/18/2013 10:22 AM, Srinivas KANDAGATLA wrote: On 17/10/13 15:49, Lucas Stach wrote: Am Donnerstag, den 17.10.2013, 15:30 +0100 schrieb srinivas kandagatla: [...] Sorry to ask this but, Where is this requirement coming from? I have not spotted any thing as such in ePAPR specs. All the spec says is. === The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, *from most specific to most general.* They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices. The recommended format is “manufacturer,model”, where manufacturer is a string describing the name of the manufacturer (such as an OUI), and model specifies the model number. Example: compatible = “fsl,mpc8641-uart”, “ns16550"; In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641-uart. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type. === The more general compatible string in this case is "st,comms-ssc-i2c", rather than the first soc name. How can a first SOC name be more general? As this driver is not very specific to StiH415, it is generic driver for ST comms-ssc-i2c block. You just can't know if someone in the future decides to subtly change the register layout or make some other incompatible change to the comms-ssc-i2c block. This is not the case for comms-ssc-i2c block, This IP is kind of reused from past 10+ years(I think!!). Am not predicting the future here, but I am making a informed guess from past experience that this IP would not change in future. Having discussed with HW design team in charge of this IP, I also bet that this IP won't change in the future. Am still not happy with the idea of using first SoC for the compatible for following reasons: 1> Generic IPs can be integrated into various vendor SoCs. For example synopsis IP can be integrated by ST parts and other non-ST parts. What would be the first SoC name in this case? 2> Looking at example like "arm,pl310-cache", "arm,l220-cache"... or any other generic ips, why are these IPs not encoding the first SoC name in there compatible string? I think the answer is generic IP. 3> IMHO, the idea of first SoC might solve the problem you described, but why would some one know about the first SoC when this was available. In this case this IP was available may be 10+ years back on an ST40 platform. Having such old SoC names in compatible strings in the device trees for a modern chip looks bit confusing. 4> ST generic drivers which are in kernel still use st, name, so I would like this consistency across all the st drivers (at least the ones which are going to be used by mach-sti platforms). 5> ePAPR spec clearly says that compatible string should contain "most specific to most general" names. In this case using more generic name makes more sense than having a specific name because its generic IP. Allowing a single device driver to match against several devices. 6> IMHO, the compatible string should be "vendor,-" rather than first SoC. I agree. In this case, we add support to revision 4 of SSC IP. Is "st,comms-ssc-v4" okay? Thanks, Maxime -- 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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 10/18/2013 10:22 AM, Srinivas KANDAGATLA wrote: On 17/10/13 15:49, Lucas Stach wrote: Am Donnerstag, den 17.10.2013, 15:30 +0100 schrieb srinivas kandagatla: [...] Sorry to ask this but, Where is this requirement coming from? I have not spotted any thing as such in ePAPR specs. All the spec says is. === The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, *from most specific to most general.* They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices. The recommended format is “manufacturer,model”, where manufacturer is a string describing the name of the manufacturer (such as an OUI), and model specifies the model number. Example: compatible = “fsl,mpc8641-uart”, “ns16550; In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641-uart. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type. === The more general compatible string in this case is st,comms-ssc-i2c, rather than the first soc name. How can a first SOC name be more general? As this driver is not very specific to StiH415, it is generic driver for ST comms-ssc-i2c block. You just can't know if someone in the future decides to subtly change the register layout or make some other incompatible change to the comms-ssc-i2c block. This is not the case for comms-ssc-i2c block, This IP is kind of reused from past 10+ years(I think!!). Am not predicting the future here, but I am making a informed guess from past experience that this IP would not change in future. Having discussed with HW design team in charge of this IP, I also bet that this IP won't change in the future. Am still not happy with the idea of using first SoC for the compatible for following reasons: 1 Generic IPs can be integrated into various vendor SoCs. For example synopsis IP can be integrated by ST parts and other non-ST parts. What would be the first SoC name in this case? 2 Looking at example like arm,pl310-cache, arm,l220-cache... or any other generic ips, why are these IPs not encoding the first SoC name in there compatible string? I think the answer is generic IP. 3 IMHO, the idea of first SoC might solve the problem you described, but why would some one know about the first SoC when this was available. In this case this IP was available may be 10+ years back on an ST40 platform. Having such old SoC names in compatible strings in the device trees for a modern chip looks bit confusing. 4 ST generic drivers which are in kernel still use st,IP name, so I would like this consistency across all the st drivers (at least the ones which are going to be used by mach-sti platforms). 5 ePAPR spec clearly says that compatible string should contain most specific to most general names. In this case using more generic name makes more sense than having a specific name because its generic IP. Allowing a single device driver to match against several devices. 6 IMHO, the compatible string should be vendor,IP-name-IP-version rather than first SoC. I agree. In this case, we add support to revision 4 of SSC IP. Is st,comms-ssc-v4 okay? Thanks, Maxime -- 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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On Oct 14, 2013, at 7:46 AM, Maxime COQUELIN wrote:
This patch adds support to SSC (Synchronous Serial Controller)
I2C driver. This IP also supports SPI protocol, but this is not
the aim of this driver.
This IP is embedded in all ST SoCs for Set-top box platorms, and
supports I2C Standard and Fast modes.
Signed-off-by: Maxime Coquelin maxime.coque...@st.com
---
Documentation/devicetree/bindings/i2c/i2c-st.txt | 38 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-st.c | 867 ++
4 files changed, 916 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st.txt
create mode 100644 drivers/i2c/busses/i2c-st.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt
b/Documentation/devicetree/bindings/i2c/i2c-st.txt
new file mode 100644
index 000..8b2fd0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt
@@ -0,0 +1,38 @@
+ST SSC binding, for I2C mode operation
+
+Required properties :
+- compatible : Must be st,comms-i2c
+- reg : Offset and length of the register set for the device
+- interrupts : the interrupt specifier
+- clock-names: Must contain ssc.
+- clocks: Must contain an entry for each name in clock-names. See the common
+ clock bindings.
+- A pinctrl state named default must be defined, using the bindings in
+ ../pinctrl/pinctrl-binding.txt
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+ the default 100 kHz frequency will be used. As only Normal and Fast modes
+ are supported, possible values are 10 and 40.
+- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is
+ allowed through the deglitch circuit. In units of us.
+- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is
+ allowed through the deglitch circuit. In units of us.
i2c-min... should be vendor prefixed, st,i2c-min...
+- A pinctrl state named sleep could be defined, using the bindings in
+ ../pinctrl/pinctrl-binding.txt
I don't see any reference to sleep in pinctrl-binding.txt
+
+
+Example :
+
+i2c0: i2c@fed4 {
+ compatible = st,comms-ssc-i2c;
+ reg = 0xfed4 0x110;
+ interrupts = GIC_SPI 187 IRQ_TYPE_EDGE_RISING;
+ clocks = CLK_S_ICN_REG_0;
+ clock-names = ssc;
+ clock-frequency = 40;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_i2c0_default;
+ i2c-min-scl-pulse-width-us = 0;
+ i2c-min-sda-pulse-width-us = 5;
+};
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 17/10/13 15:49, Lucas Stach wrote: > Am Donnerstag, den 17.10.2013, 15:30 +0100 schrieb srinivas kandagatla: > [...] >> Sorry to ask this but, Where is this requirement coming from? >> I have not spotted any thing as such in ePAPR specs. >> >> >> All the spec says is. >> === >> The compatible property value consists of one or more strings that >> define the specific programming model for the device. This list of >> strings should be used by a client program for device driver selection. >> The property value consists of a concatenated list of null terminated >> strings, *from most specific to most general.* They allow a device to >> express its compatibility with a family of similar devices, potentially >> allowing a single device driver to match against several devices. >> The recommended format is “manufacturer,model”, where manufacturer is a >> string describing the name of the manufacturer (such as an OUI), and >> model specifies the model number. >> >> Example: >> compatible = “fsl,mpc8641-uart”, “ns16550"; >> In this example, an operating system would first try to locate a device >> driver that supported fsl,mpc8641-uart. If a driver was not found, it >> would then try to locate a driver that supported the more general >> ns16550 device type. >> === >> >> The more general compatible string in this case is "st,comms-ssc-i2c", >> rather than the first soc name. >> How can a first SOC name be more general? >> >> As this driver is not very specific to StiH415, it is generic driver for >> ST comms-ssc-i2c block. >> > > You just can't know if someone in the future decides to subtly change > the register layout or make some other incompatible change to the > comms-ssc-i2c block. > This is not the case for comms-ssc-i2c block, This IP is kind of reused from past 10+ years(I think!!). Am not predicting the future here, but I am making a informed guess from past experience that this IP would not change in future. Am still not happy with the idea of using first SoC for the compatible for following reasons: 1> Generic IPs can be integrated into various vendor SoCs. For example synopsis IP can be integrated by ST parts and other non-ST parts. What would be the first SoC name in this case? 2> Looking at example like "arm,pl310-cache", "arm,l220-cache"... or any other generic ips, why are these IPs not encoding the first SoC name in there compatible string? I think the answer is generic IP. 3> IMHO, the idea of first SoC might solve the problem you described, but why would some one know about the first SoC when this was available. In this case this IP was available may be 10+ years back on an ST40 platform. Having such old SoC names in compatible strings in the device trees for a modern chip looks bit confusing. 4> ST generic drivers which are in kernel still use st, name, so I would like this consistency across all the st drivers (at least the ones which are going to be used by mach-sti platforms). 5> ePAPR spec clearly says that compatible string should contain "most specific to most general" names. In this case using more generic name makes more sense than having a specific name because its generic IP. Allowing a single device driver to match against several devices. 6> IMHO, the compatible string should be "vendor,-" rather than first SoC. Thanks, srini > So as a general rule of thumb you take the first SoC where a particular > IP block appeared as the compatible string, so you can just pick the > name of the SoC where the incompatible change was made as the next > string and not need to invent generic and unspecific comms-ssc-i2c-v2 > compatibles. > > Regards, > Lucas > -- 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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 17/10/13 15:49, Lucas Stach wrote: Am Donnerstag, den 17.10.2013, 15:30 +0100 schrieb srinivas kandagatla: [...] Sorry to ask this but, Where is this requirement coming from? I have not spotted any thing as such in ePAPR specs. All the spec says is. === The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, *from most specific to most general.* They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices. The recommended format is “manufacturer,model”, where manufacturer is a string describing the name of the manufacturer (such as an OUI), and model specifies the model number. Example: compatible = “fsl,mpc8641-uart”, “ns16550; In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641-uart. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type. === The more general compatible string in this case is st,comms-ssc-i2c, rather than the first soc name. How can a first SOC name be more general? As this driver is not very specific to StiH415, it is generic driver for ST comms-ssc-i2c block. You just can't know if someone in the future decides to subtly change the register layout or make some other incompatible change to the comms-ssc-i2c block. This is not the case for comms-ssc-i2c block, This IP is kind of reused from past 10+ years(I think!!). Am not predicting the future here, but I am making a informed guess from past experience that this IP would not change in future. Am still not happy with the idea of using first SoC for the compatible for following reasons: 1 Generic IPs can be integrated into various vendor SoCs. For example synopsis IP can be integrated by ST parts and other non-ST parts. What would be the first SoC name in this case? 2 Looking at example like arm,pl310-cache, arm,l220-cache... or any other generic ips, why are these IPs not encoding the first SoC name in there compatible string? I think the answer is generic IP. 3 IMHO, the idea of first SoC might solve the problem you described, but why would some one know about the first SoC when this was available. In this case this IP was available may be 10+ years back on an ST40 platform. Having such old SoC names in compatible strings in the device trees for a modern chip looks bit confusing. 4 ST generic drivers which are in kernel still use st,IP name, so I would like this consistency across all the st drivers (at least the ones which are going to be used by mach-sti platforms). 5 ePAPR spec clearly says that compatible string should contain most specific to most general names. In this case using more generic name makes more sense than having a specific name because its generic IP. Allowing a single device driver to match against several devices. 6 IMHO, the compatible string should be vendor,IP-name-IP-version rather than first SoC. Thanks, srini So as a general rule of thumb you take the first SoC where a particular IP block appeared as the compatible string, so you can just pick the name of the SoC where the incompatible change was made as the next string and not need to invent generic and unspecific comms-ssc-i2c-v2 compatibles. Regards, Lucas -- 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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 16:53 Thu 17 Oct , Lee Jones wrote:
> On Thu, 17 Oct 2013, Jean-Christophe PLAGNIOL-VILLARD wrote:
>
> > On 10:33 Thu 17 Oct , srinivas kandagatla wrote:
> > > On 17/10/13 08:27, Maxime COQUELIN wrote:
> > > > ...
> > > >>> >> +
> > > >>> >> +static struct of_device_id st_i2c_match[] = {
> > > >>> >> + { .compatible = "st,comms-ssc-i2c", },
> > > >> > the rules is to put the first soc that use the ip in the compatible
> > > >> > as st,sti7100-scc-i2c
> > > > Ok. There are no plans to upstream the SH4 platforms, it will only
> > > > remains in stlinux.com.
> > > > Maybe I can set the first ARM platform (STiH415)?
> > > > That would give st,stih415-ssc-i2c.
> > > NAK, for st,stih415-ssc-i2c naming.
> > >
> > > IMO, this makes sense when the same IP integration done on different SOC
> > > changes slightly/very differently.
> > >
> > > But in this case the "comms" IP remains unchanged across all the SOCs.
> > >
> > > I would still prefer "st,comms-ssc-i2c", allowing a single device driver
> > > to match against several SoCs. ST "comms" IP it is integrated across all
> > > the STi series of SoCs, so we don't want to add new entry in compatible
> > > for every new SOC.
> >
> > you never need this you always the first SoC that's all
> >
> > see other bindings on at91 as example sorry NACK
>
> I'm guessing that using the first SoC is an I2C'isum.
>
> Guys, if you don't want to be too specific, just make it as generic as
> possible whilest still using the SoC as a POR: st,stih41x-ssc-i2c will
> do for now, as it covers all current bases.
except this is wrong the IP is used on much older SoC than the recent ARM ones
and the DT so please respect the rule first SoC used on
Best Regards,
J.
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 10:33 Thu 17 Oct , srinivas kandagatla wrote:
> On 17/10/13 08:27, Maxime COQUELIN wrote:
> > ...
> >>> >> +
> >>> >> +static struct of_device_id st_i2c_match[] = {
> >>> >> + { .compatible = "st,comms-ssc-i2c", },
> >> > the rules is to put the first soc that use the ip in the compatible
> >> > as st,sti7100-scc-i2c
> > Ok. There are no plans to upstream the SH4 platforms, it will only
> > remains in stlinux.com.
> > Maybe I can set the first ARM platform (STiH415)?
> > That would give st,stih415-ssc-i2c.
> NAK, for st,stih415-ssc-i2c naming.
>
> IMO, this makes sense when the same IP integration done on different SOC
> changes slightly/very differently.
>
> But in this case the "comms" IP remains unchanged across all the SOCs.
>
> I would still prefer "st,comms-ssc-i2c", allowing a single device driver
> to match against several SoCs. ST "comms" IP it is integrated across all
> the STi series of SoCs, so we don't want to add new entry in compatible
> for every new SOC.
you never need this you always the first SoC that's all
see other bindings on at91 as example sorry NACK
Best Regards,
J.
>
>
> Thanks,
> srini
>
> >
> > Thanks for the review,
> > Maxime
> >
> >> >
>
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 10/17/2013 04:16 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 09:27 Thu 17 Oct , Maxime COQUELIN wrote:
>> Hi Jean-Christophe,
>>
>> On 10/16/2013 05:14 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>
>>
>> ...
+
+static inline void st_i2c_set_bits(void __iomem *reg, u32 mask)
+{
+ writel(readl(reg) | mask, reg);
+}
+
+static inline void st_i2c_clr_bits(void __iomem *reg, u32 mask)
+{
+ writel(readl(reg) & ~mask, reg);
>>> use set_bit api and use relaxed version
>> Using the set_bit api here does not match with the purpose of these
>> functions.
>> We want to be able to set/clear multiple bits, and AFAICS the set_bit
>> api does not
>> provide this possibility.
>>
>> I took example on i2c-nomadik for these functions.
>>
> so factorize the code not copy and paste
I won't create a new API for this.
If this is blocking for you, then I will just remove this functions.
+}
+
+/* From I2C Specifications v0.5 */
+static struct st_i2c_timings i2c_timings[] = {
use readsl
>> Since the read content is flushed, I prefer keeping it as it is instead
>> of allocating
>> a buffer of the FIFO's size.
> keep point is to speedup the bus
I meant I will use readl_relaxed, not readl.
>>> use relaxed version as much as possible
>> I was not comfortable with the different possibilities (_raw_readl,
>> readl_relaxed, readl...).
>> I found this interresting discussion:
>> _http://comments.gmane.org/gmane.linux.ports.arm.kernel/117626
>> From what I understood, you are right, I should be able to use
>> readl_relaxed everywhere.
>>
>> Maybe I should perform a readl on the interrupt mask register before
>> returning from the interrupt handler,
>> in order to ensure that the write to the IEN register is effective
>> before the IRQ for the device is re-enabled at GIC level.
>> Maybe this could avoid the few spurious interrupts I face sometimes, I
>> will have a try.
> ok
I failed to reproduce the spurious interrupt without the patch, so I
can't say
whether performing a readl at this stage helps.
+}
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On Thu, 17 Oct 2013, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:33 Thu 17 Oct , srinivas kandagatla wrote:
> > On 17/10/13 08:27, Maxime COQUELIN wrote:
> > > ...
> > >>> >> +
> > >>> >> +static struct of_device_id st_i2c_match[] = {
> > >>> >> + { .compatible = "st,comms-ssc-i2c", },
> > >> > the rules is to put the first soc that use the ip in the compatible
> > >> > as st,sti7100-scc-i2c
> > > Ok. There are no plans to upstream the SH4 platforms, it will only
> > > remains in stlinux.com.
> > > Maybe I can set the first ARM platform (STiH415)?
> > > That would give st,stih415-ssc-i2c.
> > NAK, for st,stih415-ssc-i2c naming.
> >
> > IMO, this makes sense when the same IP integration done on different SOC
> > changes slightly/very differently.
> >
> > But in this case the "comms" IP remains unchanged across all the SOCs.
> >
> > I would still prefer "st,comms-ssc-i2c", allowing a single device driver
> > to match against several SoCs. ST "comms" IP it is integrated across all
> > the STi series of SoCs, so we don't want to add new entry in compatible
> > for every new SOC.
>
> you never need this you always the first SoC that's all
>
> see other bindings on at91 as example sorry NACK
I'm guessing that using the first SoC is an I2C'isum.
Guys, if you don't want to be too specific, just make it as generic as
possible whilest still using the SoC as a POR: st,stih41x-ssc-i2c will
do for now, as it covers all current bases.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 09:27 Thu 17 Oct , Maxime COQUELIN wrote:
> Hi Jean-Christophe,
>
> On 10/16/2013 05:14 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>
>
> ...
> >> +
> >> +static inline void st_i2c_set_bits(void __iomem *reg, u32 mask)
> >> +{
> >> + writel(readl(reg) | mask, reg);
> >> +}
> >> +
> >> +static inline void st_i2c_clr_bits(void __iomem *reg, u32 mask)
> >> +{
> >> + writel(readl(reg) & ~mask, reg);
> > use set_bit api and use relaxed version
> Using the set_bit api here does not match with the purpose of these
> functions.
> We want to be able to set/clear multiple bits, and AFAICS the set_bit
> api does not
> provide this possibility.
>
> I took example on i2c-nomadik for these functions.
>
so factorize the code not copy and paste
> >> +}
> >> +
> >> +/* From I2C Specifications v0.5 */
> >> +static struct st_i2c_timings i2c_timings[] = {
> >> + [I2C_MODE_STANDARD] = {
> >> + .rate = 10,
> >> + .rep_start_hold = 4000,
> >> + .rep_start_setup= 4700,
> >> + .start_hold = 4000,
> >> + .data_setup_time= 250,
> >> + .stop_setup_time= 4000,
> >> + .bus_free_time = 4700,
> >> + },
> >> + [I2C_MODE_FAST] = {
> >> + .rate = 40,
> >> + .rep_start_hold = 600,
> >> + .rep_start_setup= 600,
> >> + .start_hold = 600,
> >> + .data_setup_time= 100,
> >> + .stop_setup_time= 600,
> >> + .bus_free_time = 1300,
> >> + },
> >> +};
> > so how do you plane to support other rate that 100k and 400k?
> The SSC IP only supports Standard and Fast modes.
> There are no plans to support faster modes.
> >> +
> >> +static void st_i2c_flush_rx_fifo(struct st_i2c_dev *i2c_dev)
> >> +{
> >> + int count, i;
> >> +
> >> + /*
> >> + * Counter only counts up to 7 but fifo size is 8...
> >> + * When fifo is full, counter is 0 and RIR bit of status register is
> >> + * set
> >> + */
> >> + if (readl(i2c_dev->base + SSC_STA) & SSC_STA_RIR)
> >> + count = SSC_RXFIFO_SIZE;
> >> + else
> >> + count = readl(i2c_dev->base + SSC_RX_FSTAT) &
> >> + SSC_RX_FSTAT_STATUS;
> >> +
> >> + for (i = 0; i < count; i++)
> >> + readl(i2c_dev->base + SSC_RBUF);
> > use readsl
> Since the read content is flushed, I prefer keeping it as it is instead
> of allocating
> a buffer of the FIFO's size.
keep point is to speedup the bus
> >
> > use relaxed version as much as possible
> I was not comfortable with the different possibilities (_raw_readl,
> readl_relaxed, readl...).
> I found this interresting discussion:
> _http://comments.gmane.org/gmane.linux.ports.arm.kernel/117626
> From what I understood, you are right, I should be able to use
> readl_relaxed everywhere.
>
> Maybe I should perform a readl on the interrupt mask register before
> returning from the interrupt handler,
> in order to ensure that the write to the IEN register is effective
> before the IRQ for the device is re-enabled at GIC level.
> Maybe this could avoid the few spurious interrupts I face sometimes, I
> will have a try.
ok
>
> >> +}
> >> +
> ...
> >> +
> >> +static int st_i2c_wait_free_bus(struct st_i2c_dev *i2c_dev)
> >> +{
> >> + u32 sta;
> >> + int i;
> >> +
> >> + for (i = 0; i < 10; i++) {
> >> + sta = readl(i2c_dev->base + SSC_STA);
> >> + if (!(sta & SSC_STA_BUSY))
> >> + return 0;
> >> +
> >> + usleep_range(2000, 4000);
> > can not use interrupt?
> Sadly, no.
> There is no interrupt linked to the busy bit.
> >> + }
> >> +
> ...
> >> +
> >> +static struct of_device_id st_i2c_match[] = {
> >> + { .compatible = "st,comms-ssc-i2c", },
> > the rules is to put the first soc that use the ip in the compatible
> > as st,sti7100-scc-i2c
> Ok. There are no plans to upstream the SH4 platforms, it will only
> remains in stlinux.com.
> Maybe I can set the first ARM platform (STiH415)?
> That would give st,stih415-ssc-i2c.
no you need to put the first soc even not mainline dt is not relaated to linux
mainline of not we describe hw
IIRC it was even present before sh4, on st200 IIRC need to check my old
datasheet
Best Regards,
J.
>
> Thanks for the review,
> Maxime
>
> >
> > Best Regards,
> > J.
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
Am Donnerstag, den 17.10.2013, 15:30 +0100 schrieb srinivas kandagatla: [...] > Sorry to ask this but, Where is this requirement coming from? > I have not spotted any thing as such in ePAPR specs. > > > All the spec says is. > === > The compatible property value consists of one or more strings that > define the specific programming model for the device. This list of > strings should be used by a client program for device driver selection. > The property value consists of a concatenated list of null terminated > strings, *from most specific to most general.* They allow a device to > express its compatibility with a family of similar devices, potentially > allowing a single device driver to match against several devices. > The recommended format is “manufacturer,model”, where manufacturer is a > string describing the name of the manufacturer (such as an OUI), and > model specifies the model number. > > Example: > compatible = “fsl,mpc8641-uart”, “ns16550"; > In this example, an operating system would first try to locate a device > driver that supported fsl,mpc8641-uart. If a driver was not found, it > would then try to locate a driver that supported the more general > ns16550 device type. > === > > The more general compatible string in this case is "st,comms-ssc-i2c", > rather than the first soc name. > How can a first SOC name be more general? > > As this driver is not very specific to StiH415, it is generic driver for > ST comms-ssc-i2c block. > You just can't know if someone in the future decides to subtly change the register layout or make some other incompatible change to the comms-ssc-i2c block. So as a general rule of thumb you take the first SoC where a particular IP block appeared as the compatible string, so you can just pick the name of the SoC where the incompatible change was made as the next string and not need to invent generic and unspecific comms-ssc-i2c-v2 compatibles. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 17/10/13 15:19, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:33 Thu 17 Oct , srinivas kandagatla wrote:
>> On 17/10/13 08:27, Maxime COQUELIN wrote:
>>> ...
>>> +
>>> +static struct of_device_id st_i2c_match[] = {
>>> + { .compatible = "st,comms-ssc-i2c", },
> the rules is to put the first soc that use the ip in the compatible
> as st,sti7100-scc-i2c
>>> Ok. There are no plans to upstream the SH4 platforms, it will only
>>> remains in stlinux.com.
>>> Maybe I can set the first ARM platform (STiH415)?
>>> That would give st,stih415-ssc-i2c.
>> NAK, for st,stih415-ssc-i2c naming.
>>
>> IMO, this makes sense when the same IP integration done on different SOC
>> changes slightly/very differently.
>>
>> But in this case the "comms" IP remains unchanged across all the SOCs.
>>
>> I would still prefer "st,comms-ssc-i2c", allowing a single device driver
>> to match against several SoCs. ST "comms" IP it is integrated across all
>> the STi series of SoCs, so we don't want to add new entry in compatible
>> for every new SOC.
>
> you never need this you always the first SoC that's all
Sorry to ask this but, Where is this requirement coming from?
I have not spotted any thing as such in ePAPR specs.
All the spec says is.
===
The compatible property value consists of one or more strings that
define the specific programming model for the device. This list of
strings should be used by a client program for device driver selection.
The property value consists of a concatenated list of null terminated
strings, *from most specific to most general.* They allow a device to
express its compatibility with a family of similar devices, potentially
allowing a single device driver to match against several devices.
The recommended format is “manufacturer,model”, where manufacturer is a
string describing the name of the manufacturer (such as an OUI), and
model specifies the model number.
Example:
compatible = “fsl,mpc8641-uart”, “ns16550";
In this example, an operating system would first try to locate a device
driver that supported fsl,mpc8641-uart. If a driver was not found, it
would then try to locate a driver that supported the more general
ns16550 device type.
===
The more general compatible string in this case is "st,comms-ssc-i2c",
rather than the first soc name.
How can a first SOC name be more general?
As this driver is not very specific to StiH415, it is generic driver for
ST comms-ssc-i2c block.
Thanks,
srini
>
> see other bindings on at91 as example sorry NACK
>
> Best Regards,
> J.
>>
>>
>> Thanks,
>> srini
>>
>>>
>>> Thanks for the review,
>>> Maxime
>>>
>
>>
>
>
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 17/10/13 08:27, Maxime COQUELIN wrote:
> ...
>>> >> +
>>> >> +static struct of_device_id st_i2c_match[] = {
>>> >> + { .compatible = "st,comms-ssc-i2c", },
>> > the rules is to put the first soc that use the ip in the compatible
>> > as st,sti7100-scc-i2c
> Ok. There are no plans to upstream the SH4 platforms, it will only
> remains in stlinux.com.
> Maybe I can set the first ARM platform (STiH415)?
> That would give st,stih415-ssc-i2c.
NAK, for st,stih415-ssc-i2c naming.
IMO, this makes sense when the same IP integration done on different SOC
changes slightly/very differently.
But in this case the "comms" IP remains unchanged across all the SOCs.
I would still prefer "st,comms-ssc-i2c", allowing a single device driver
to match against several SoCs. ST "comms" IP it is integrated across all
the STi series of SoCs, so we don't want to add new entry in compatible
for every new SOC.
Thanks,
srini
>
> Thanks for the review,
> Maxime
>
>> >
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
Hi Jean-Christophe,
On 10/16/2013 05:14 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
...
>> +
>> +static inline void st_i2c_set_bits(void __iomem *reg, u32 mask)
>> +{
>> + writel(readl(reg) | mask, reg);
>> +}
>> +
>> +static inline void st_i2c_clr_bits(void __iomem *reg, u32 mask)
>> +{
>> + writel(readl(reg) & ~mask, reg);
> use set_bit api and use relaxed version
Using the set_bit api here does not match with the purpose of these
functions.
We want to be able to set/clear multiple bits, and AFAICS the set_bit
api does not
provide this possibility.
I took example on i2c-nomadik for these functions.
>> +}
>> +
>> +/* From I2C Specifications v0.5 */
>> +static struct st_i2c_timings i2c_timings[] = {
>> + [I2C_MODE_STANDARD] = {
>> + .rate = 10,
>> + .rep_start_hold = 4000,
>> + .rep_start_setup= 4700,
>> + .start_hold = 4000,
>> + .data_setup_time= 250,
>> + .stop_setup_time= 4000,
>> + .bus_free_time = 4700,
>> + },
>> + [I2C_MODE_FAST] = {
>> + .rate = 40,
>> + .rep_start_hold = 600,
>> + .rep_start_setup= 600,
>> + .start_hold = 600,
>> + .data_setup_time= 100,
>> + .stop_setup_time= 600,
>> + .bus_free_time = 1300,
>> + },
>> +};
> so how do you plane to support other rate that 100k and 400k?
The SSC IP only supports Standard and Fast modes.
There are no plans to support faster modes.
>> +
>> +static void st_i2c_flush_rx_fifo(struct st_i2c_dev *i2c_dev)
>> +{
>> + int count, i;
>> +
>> + /*
>> + * Counter only counts up to 7 but fifo size is 8...
>> + * When fifo is full, counter is 0 and RIR bit of status register is
>> + * set
>> + */
>> + if (readl(i2c_dev->base + SSC_STA) & SSC_STA_RIR)
>> + count = SSC_RXFIFO_SIZE;
>> + else
>> + count = readl(i2c_dev->base + SSC_RX_FSTAT) &
>> + SSC_RX_FSTAT_STATUS;
>> +
>> + for (i = 0; i < count; i++)
>> + readl(i2c_dev->base + SSC_RBUF);
> use readsl
Since the read content is flushed, I prefer keeping it as it is instead
of allocating
a buffer of the FIFO's size.
>
> use relaxed version as much as possible
I was not comfortable with the different possibilities (_raw_readl,
readl_relaxed, readl...).
I found this interresting discussion:
_http://comments.gmane.org/gmane.linux.ports.arm.kernel/117626
From what I understood, you are right, I should be able to use
readl_relaxed everywhere.
Maybe I should perform a readl on the interrupt mask register before
returning from the interrupt handler,
in order to ensure that the write to the IEN register is effective
before the IRQ for the device is re-enabled at GIC level.
Maybe this could avoid the few spurious interrupts I face sometimes, I
will have a try.
>> +}
>> +
...
>> +
>> +static int st_i2c_wait_free_bus(struct st_i2c_dev *i2c_dev)
>> +{
>> + u32 sta;
>> + int i;
>> +
>> + for (i = 0; i < 10; i++) {
>> + sta = readl(i2c_dev->base + SSC_STA);
>> + if (!(sta & SSC_STA_BUSY))
>> + return 0;
>> +
>> + usleep_range(2000, 4000);
> can not use interrupt?
Sadly, no.
There is no interrupt linked to the busy bit.
>> + }
>> +
...
>> +
>> +static struct of_device_id st_i2c_match[] = {
>> + { .compatible = "st,comms-ssc-i2c", },
> the rules is to put the first soc that use the ip in the compatible
> as st,sti7100-scc-i2c
Ok. There are no plans to upstream the SH4 platforms, it will only
remains in stlinux.com.
Maybe I can set the first ARM platform (STiH415)?
That would give st,stih415-ssc-i2c.
Thanks for the review,
Maxime
>
> Best Regards,
> J.
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
Hi Jean-Christophe,
On 10/16/2013 05:14 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
...
+
+static inline void st_i2c_set_bits(void __iomem *reg, u32 mask)
+{
+ writel(readl(reg) | mask, reg);
+}
+
+static inline void st_i2c_clr_bits(void __iomem *reg, u32 mask)
+{
+ writel(readl(reg) ~mask, reg);
use set_bit api and use relaxed version
Using the set_bit api here does not match with the purpose of these
functions.
We want to be able to set/clear multiple bits, and AFAICS the set_bit
api does not
provide this possibility.
I took example on i2c-nomadik for these functions.
+}
+
+/* From I2C Specifications v0.5 */
+static struct st_i2c_timings i2c_timings[] = {
+ [I2C_MODE_STANDARD] = {
+ .rate = 10,
+ .rep_start_hold = 4000,
+ .rep_start_setup= 4700,
+ .start_hold = 4000,
+ .data_setup_time= 250,
+ .stop_setup_time= 4000,
+ .bus_free_time = 4700,
+ },
+ [I2C_MODE_FAST] = {
+ .rate = 40,
+ .rep_start_hold = 600,
+ .rep_start_setup= 600,
+ .start_hold = 600,
+ .data_setup_time= 100,
+ .stop_setup_time= 600,
+ .bus_free_time = 1300,
+ },
+};
so how do you plane to support other rate that 100k and 400k?
The SSC IP only supports Standard and Fast modes.
There are no plans to support faster modes.
+
+static void st_i2c_flush_rx_fifo(struct st_i2c_dev *i2c_dev)
+{
+ int count, i;
+
+ /*
+ * Counter only counts up to 7 but fifo size is 8...
+ * When fifo is full, counter is 0 and RIR bit of status register is
+ * set
+ */
+ if (readl(i2c_dev-base + SSC_STA) SSC_STA_RIR)
+ count = SSC_RXFIFO_SIZE;
+ else
+ count = readl(i2c_dev-base + SSC_RX_FSTAT)
+ SSC_RX_FSTAT_STATUS;
+
+ for (i = 0; i count; i++)
+ readl(i2c_dev-base + SSC_RBUF);
use readsl
Since the read content is flushed, I prefer keeping it as it is instead
of allocating
a buffer of the FIFO's size.
use relaxed version as much as possible
I was not comfortable with the different possibilities (_raw_readl,
readl_relaxed, readl...).
I found this interresting discussion:
_http://comments.gmane.org/gmane.linux.ports.arm.kernel/117626
From what I understood, you are right, I should be able to use
readl_relaxed everywhere.
Maybe I should perform a readl on the interrupt mask register before
returning from the interrupt handler,
in order to ensure that the write to the IEN register is effective
before the IRQ for the device is re-enabled at GIC level.
Maybe this could avoid the few spurious interrupts I face sometimes, I
will have a try.
+}
+
...
+
+static int st_i2c_wait_free_bus(struct st_i2c_dev *i2c_dev)
+{
+ u32 sta;
+ int i;
+
+ for (i = 0; i 10; i++) {
+ sta = readl(i2c_dev-base + SSC_STA);
+ if (!(sta SSC_STA_BUSY))
+ return 0;
+
+ usleep_range(2000, 4000);
can not use interrupt?
Sadly, no.
There is no interrupt linked to the busy bit.
+ }
+
...
+
+static struct of_device_id st_i2c_match[] = {
+ { .compatible = st,comms-ssc-i2c, },
the rules is to put the first soc that use the ip in the compatible
as st,sti7100-scc-i2c
Ok. There are no plans to upstream the SH4 platforms, it will only
remains in stlinux.com.
Maybe I can set the first ARM platform (STiH415)?
That would give st,stih415-ssc-i2c.
Thanks for the review,
Maxime
Best Regards,
J.
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 17/10/13 08:27, Maxime COQUELIN wrote:
...
+
+static struct of_device_id st_i2c_match[] = {
+ { .compatible = st,comms-ssc-i2c, },
the rules is to put the first soc that use the ip in the compatible
as st,sti7100-scc-i2c
Ok. There are no plans to upstream the SH4 platforms, it will only
remains in stlinux.com.
Maybe I can set the first ARM platform (STiH415)?
That would give st,stih415-ssc-i2c.
NAK, for st,stih415-ssc-i2c naming.
IMO, this makes sense when the same IP integration done on different SOC
changes slightly/very differently.
But in this case the comms IP remains unchanged across all the SOCs.
I would still prefer st,comms-ssc-i2c, allowing a single device driver
to match against several SoCs. ST comms IP it is integrated across all
the STi series of SoCs, so we don't want to add new entry in compatible
for every new SOC.
Thanks,
srini
Thanks for the review,
Maxime
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 17/10/13 15:19, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 10:33 Thu 17 Oct , srinivas kandagatla wrote:
On 17/10/13 08:27, Maxime COQUELIN wrote:
...
+
+static struct of_device_id st_i2c_match[] = {
+ { .compatible = st,comms-ssc-i2c, },
the rules is to put the first soc that use the ip in the compatible
as st,sti7100-scc-i2c
Ok. There are no plans to upstream the SH4 platforms, it will only
remains in stlinux.com.
Maybe I can set the first ARM platform (STiH415)?
That would give st,stih415-ssc-i2c.
NAK, for st,stih415-ssc-i2c naming.
IMO, this makes sense when the same IP integration done on different SOC
changes slightly/very differently.
But in this case the comms IP remains unchanged across all the SOCs.
I would still prefer st,comms-ssc-i2c, allowing a single device driver
to match against several SoCs. ST comms IP it is integrated across all
the STi series of SoCs, so we don't want to add new entry in compatible
for every new SOC.
you never need this you always the first SoC that's all
Sorry to ask this but, Where is this requirement coming from?
I have not spotted any thing as such in ePAPR specs.
All the spec says is.
===
The compatible property value consists of one or more strings that
define the specific programming model for the device. This list of
strings should be used by a client program for device driver selection.
The property value consists of a concatenated list of null terminated
strings, *from most specific to most general.* They allow a device to
express its compatibility with a family of similar devices, potentially
allowing a single device driver to match against several devices.
The recommended format is “manufacturer,model”, where manufacturer is a
string describing the name of the manufacturer (such as an OUI), and
model specifies the model number.
Example:
compatible = “fsl,mpc8641-uart”, “ns16550;
In this example, an operating system would first try to locate a device
driver that supported fsl,mpc8641-uart. If a driver was not found, it
would then try to locate a driver that supported the more general
ns16550 device type.
===
The more general compatible string in this case is st,comms-ssc-i2c,
rather than the first soc name.
How can a first SOC name be more general?
As this driver is not very specific to StiH415, it is generic driver for
ST comms-ssc-i2c block.
Thanks,
srini
see other bindings on at91 as example sorry NACK
Best Regards,
J.
Thanks,
srini
Thanks for the review,
Maxime
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
Am Donnerstag, den 17.10.2013, 15:30 +0100 schrieb srinivas kandagatla: [...] Sorry to ask this but, Where is this requirement coming from? I have not spotted any thing as such in ePAPR specs. All the spec says is. === The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, *from most specific to most general.* They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices. The recommended format is “manufacturer,model”, where manufacturer is a string describing the name of the manufacturer (such as an OUI), and model specifies the model number. Example: compatible = “fsl,mpc8641-uart”, “ns16550; In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641-uart. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type. === The more general compatible string in this case is st,comms-ssc-i2c, rather than the first soc name. How can a first SOC name be more general? As this driver is not very specific to StiH415, it is generic driver for ST comms-ssc-i2c block. You just can't know if someone in the future decides to subtly change the register layout or make some other incompatible change to the comms-ssc-i2c block. So as a general rule of thumb you take the first SoC where a particular IP block appeared as the compatible string, so you can just pick the name of the SoC where the incompatible change was made as the next string and not need to invent generic and unspecific comms-ssc-i2c-v2 compatibles. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 09:27 Thu 17 Oct , Maxime COQUELIN wrote:
Hi Jean-Christophe,
On 10/16/2013 05:14 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
...
+
+static inline void st_i2c_set_bits(void __iomem *reg, u32 mask)
+{
+ writel(readl(reg) | mask, reg);
+}
+
+static inline void st_i2c_clr_bits(void __iomem *reg, u32 mask)
+{
+ writel(readl(reg) ~mask, reg);
use set_bit api and use relaxed version
Using the set_bit api here does not match with the purpose of these
functions.
We want to be able to set/clear multiple bits, and AFAICS the set_bit
api does not
provide this possibility.
I took example on i2c-nomadik for these functions.
so factorize the code not copy and paste
+}
+
+/* From I2C Specifications v0.5 */
+static struct st_i2c_timings i2c_timings[] = {
+ [I2C_MODE_STANDARD] = {
+ .rate = 10,
+ .rep_start_hold = 4000,
+ .rep_start_setup= 4700,
+ .start_hold = 4000,
+ .data_setup_time= 250,
+ .stop_setup_time= 4000,
+ .bus_free_time = 4700,
+ },
+ [I2C_MODE_FAST] = {
+ .rate = 40,
+ .rep_start_hold = 600,
+ .rep_start_setup= 600,
+ .start_hold = 600,
+ .data_setup_time= 100,
+ .stop_setup_time= 600,
+ .bus_free_time = 1300,
+ },
+};
so how do you plane to support other rate that 100k and 400k?
The SSC IP only supports Standard and Fast modes.
There are no plans to support faster modes.
+
+static void st_i2c_flush_rx_fifo(struct st_i2c_dev *i2c_dev)
+{
+ int count, i;
+
+ /*
+ * Counter only counts up to 7 but fifo size is 8...
+ * When fifo is full, counter is 0 and RIR bit of status register is
+ * set
+ */
+ if (readl(i2c_dev-base + SSC_STA) SSC_STA_RIR)
+ count = SSC_RXFIFO_SIZE;
+ else
+ count = readl(i2c_dev-base + SSC_RX_FSTAT)
+ SSC_RX_FSTAT_STATUS;
+
+ for (i = 0; i count; i++)
+ readl(i2c_dev-base + SSC_RBUF);
use readsl
Since the read content is flushed, I prefer keeping it as it is instead
of allocating
a buffer of the FIFO's size.
keep point is to speedup the bus
use relaxed version as much as possible
I was not comfortable with the different possibilities (_raw_readl,
readl_relaxed, readl...).
I found this interresting discussion:
_http://comments.gmane.org/gmane.linux.ports.arm.kernel/117626
From what I understood, you are right, I should be able to use
readl_relaxed everywhere.
Maybe I should perform a readl on the interrupt mask register before
returning from the interrupt handler,
in order to ensure that the write to the IEN register is effective
before the IRQ for the device is re-enabled at GIC level.
Maybe this could avoid the few spurious interrupts I face sometimes, I
will have a try.
ok
+}
+
...
+
+static int st_i2c_wait_free_bus(struct st_i2c_dev *i2c_dev)
+{
+ u32 sta;
+ int i;
+
+ for (i = 0; i 10; i++) {
+ sta = readl(i2c_dev-base + SSC_STA);
+ if (!(sta SSC_STA_BUSY))
+ return 0;
+
+ usleep_range(2000, 4000);
can not use interrupt?
Sadly, no.
There is no interrupt linked to the busy bit.
+ }
+
...
+
+static struct of_device_id st_i2c_match[] = {
+ { .compatible = st,comms-ssc-i2c, },
the rules is to put the first soc that use the ip in the compatible
as st,sti7100-scc-i2c
Ok. There are no plans to upstream the SH4 platforms, it will only
remains in stlinux.com.
Maybe I can set the first ARM platform (STiH415)?
That would give st,stih415-ssc-i2c.
no you need to put the first soc even not mainline dt is not relaated to linux
mainline of not we describe hw
IIRC it was even present before sh4, on st200 IIRC need to check my old
datasheet
Best Regards,
J.
Thanks for the review,
Maxime
Best Regards,
J.
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On Thu, 17 Oct 2013, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 10:33 Thu 17 Oct , srinivas kandagatla wrote:
On 17/10/13 08:27, Maxime COQUELIN wrote:
...
+
+static struct of_device_id st_i2c_match[] = {
+ { .compatible = st,comms-ssc-i2c, },
the rules is to put the first soc that use the ip in the compatible
as st,sti7100-scc-i2c
Ok. There are no plans to upstream the SH4 platforms, it will only
remains in stlinux.com.
Maybe I can set the first ARM platform (STiH415)?
That would give st,stih415-ssc-i2c.
NAK, for st,stih415-ssc-i2c naming.
IMO, this makes sense when the same IP integration done on different SOC
changes slightly/very differently.
But in this case the comms IP remains unchanged across all the SOCs.
I would still prefer st,comms-ssc-i2c, allowing a single device driver
to match against several SoCs. ST comms IP it is integrated across all
the STi series of SoCs, so we don't want to add new entry in compatible
for every new SOC.
you never need this you always the first SoC that's all
see other bindings on at91 as example sorry NACK
I'm guessing that using the first SoC is an I2C'isum.
Guys, if you don't want to be too specific, just make it as generic as
possible whilest still using the SoC as a POR: st,stih41x-ssc-i2c will
do for now, as it covers all current bases.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 10/17/2013 04:16 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 09:27 Thu 17 Oct , Maxime COQUELIN wrote:
Hi Jean-Christophe,
On 10/16/2013 05:14 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
...
+
+static inline void st_i2c_set_bits(void __iomem *reg, u32 mask)
+{
+ writel(readl(reg) | mask, reg);
+}
+
+static inline void st_i2c_clr_bits(void __iomem *reg, u32 mask)
+{
+ writel(readl(reg) ~mask, reg);
use set_bit api and use relaxed version
Using the set_bit api here does not match with the purpose of these
functions.
We want to be able to set/clear multiple bits, and AFAICS the set_bit
api does not
provide this possibility.
I took example on i2c-nomadik for these functions.
so factorize the code not copy and paste
I won't create a new API for this.
If this is blocking for you, then I will just remove this functions.
+}
+
+/* From I2C Specifications v0.5 */
+static struct st_i2c_timings i2c_timings[] = {
use readsl
Since the read content is flushed, I prefer keeping it as it is instead
of allocating
a buffer of the FIFO's size.
keep point is to speedup the bus
I meant I will use readl_relaxed, not readl.
use relaxed version as much as possible
I was not comfortable with the different possibilities (_raw_readl,
readl_relaxed, readl...).
I found this interresting discussion:
_http://comments.gmane.org/gmane.linux.ports.arm.kernel/117626
From what I understood, you are right, I should be able to use
readl_relaxed everywhere.
Maybe I should perform a readl on the interrupt mask register before
returning from the interrupt handler,
in order to ensure that the write to the IEN register is effective
before the IRQ for the device is re-enabled at GIC level.
Maybe this could avoid the few spurious interrupts I face sometimes, I
will have a try.
ok
I failed to reproduce the spurious interrupt without the patch, so I
can't say
whether performing a readl at this stage helps.
+}
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 10:33 Thu 17 Oct , srinivas kandagatla wrote:
On 17/10/13 08:27, Maxime COQUELIN wrote:
...
+
+static struct of_device_id st_i2c_match[] = {
+ { .compatible = st,comms-ssc-i2c, },
the rules is to put the first soc that use the ip in the compatible
as st,sti7100-scc-i2c
Ok. There are no plans to upstream the SH4 platforms, it will only
remains in stlinux.com.
Maybe I can set the first ARM platform (STiH415)?
That would give st,stih415-ssc-i2c.
NAK, for st,stih415-ssc-i2c naming.
IMO, this makes sense when the same IP integration done on different SOC
changes slightly/very differently.
But in this case the comms IP remains unchanged across all the SOCs.
I would still prefer st,comms-ssc-i2c, allowing a single device driver
to match against several SoCs. ST comms IP it is integrated across all
the STi series of SoCs, so we don't want to add new entry in compatible
for every new SOC.
you never need this you always the first SoC that's all
see other bindings on at91 as example sorry NACK
Best Regards,
J.
Thanks,
srini
Thanks for the review,
Maxime
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 16:53 Thu 17 Oct , Lee Jones wrote:
On Thu, 17 Oct 2013, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 10:33 Thu 17 Oct , srinivas kandagatla wrote:
On 17/10/13 08:27, Maxime COQUELIN wrote:
...
+
+static struct of_device_id st_i2c_match[] = {
+ { .compatible = st,comms-ssc-i2c, },
the rules is to put the first soc that use the ip in the compatible
as st,sti7100-scc-i2c
Ok. There are no plans to upstream the SH4 platforms, it will only
remains in stlinux.com.
Maybe I can set the first ARM platform (STiH415)?
That would give st,stih415-ssc-i2c.
NAK, for st,stih415-ssc-i2c naming.
IMO, this makes sense when the same IP integration done on different SOC
changes slightly/very differently.
But in this case the comms IP remains unchanged across all the SOCs.
I would still prefer st,comms-ssc-i2c, allowing a single device driver
to match against several SoCs. ST comms IP it is integrated across all
the STi series of SoCs, so we don't want to add new entry in compatible
for every new SOC.
you never need this you always the first SoC that's all
see other bindings on at91 as example sorry NACK
I'm guessing that using the first SoC is an I2C'isum.
Guys, if you don't want to be too specific, just make it as generic as
possible whilest still using the SoC as a POR: st,stih41x-ssc-i2c will
do for now, as it covers all current bases.
except this is wrong the IP is used on much older SoC than the recent ARM ones
and the DT so please respect the rule first SoC used on
Best Regards,
J.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
> +/**
> + * struct st_i2c_dev - private data of the controller
> + * @adap: I2C adapter for this controller
> + * @dev: device for this controller
> + * @base: virtual memory area
> + * @complete: completion of I2C message
> + * @irq: interrupt line for th controller
> + * @clk: hw ssc block clock
> + * @mode: I2C mode of the controller. Standard or Fast only supported
> + * @deglitch: Anti-glitch filters parameters
> + * @client: I2C transfert information
> + * @busy: I2C transfer on-going
> + */
> +struct st_i2c_dev {
> + struct i2c_adapter adap;
> + struct device *dev;
> + void __iomem*base;
> + struct completion complete;
> + int irq;
> + struct clk *clk;
> + int mode;
> + struct st_i2c_deglitch deglitch;
> + struct st_i2c_clientclient;
> + boolbusy;
> +};
> +
> +static inline void st_i2c_set_bits(void __iomem *reg, u32 mask)
> +{
> + writel(readl(reg) | mask, reg);
> +}
> +
> +static inline void st_i2c_clr_bits(void __iomem *reg, u32 mask)
> +{
> + writel(readl(reg) & ~mask, reg);
use set_bit api and use relaxed version
> +}
> +
> +/* From I2C Specifications v0.5 */
> +static struct st_i2c_timings i2c_timings[] = {
> + [I2C_MODE_STANDARD] = {
> + .rate = 10,
> + .rep_start_hold = 4000,
> + .rep_start_setup= 4700,
> + .start_hold = 4000,
> + .data_setup_time= 250,
> + .stop_setup_time= 4000,
> + .bus_free_time = 4700,
> + },
> + [I2C_MODE_FAST] = {
> + .rate = 40,
> + .rep_start_hold = 600,
> + .rep_start_setup= 600,
> + .start_hold = 600,
> + .data_setup_time= 100,
> + .stop_setup_time= 600,
> + .bus_free_time = 1300,
> + },
> +};
so how do you plane to support other rate that 100k and 400k?
> +
> +static void st_i2c_flush_rx_fifo(struct st_i2c_dev *i2c_dev)
> +{
> + int count, i;
> +
> + /*
> + * Counter only counts up to 7 but fifo size is 8...
> + * When fifo is full, counter is 0 and RIR bit of status register is
> + * set
> + */
> + if (readl(i2c_dev->base + SSC_STA) & SSC_STA_RIR)
> + count = SSC_RXFIFO_SIZE;
> + else
> + count = readl(i2c_dev->base + SSC_RX_FSTAT) &
> + SSC_RX_FSTAT_STATUS;
> +
> + for (i = 0; i < count; i++)
> + readl(i2c_dev->base + SSC_RBUF);
use readsl
use relaxed version as much as possible
> +}
> +
> +static void st_i2c_soft_reset(struct st_i2c_dev *i2c_dev)
> +{
> + /*
> + * FIFO needs to be emptied before reseting the IP,
> + * else the controller raises a BUSY error.
> + */
> + st_i2c_flush_rx_fifo(i2c_dev);
> +
> + st_i2c_set_bits(i2c_dev->base + SSC_CTL, SSC_CTL_SR);
> + st_i2c_clr_bits(i2c_dev->base + SSC_CTL, SSC_CTL_SR);
> +}
> +
> +/**
> + * st_i2c_hw_config() - Prepare SSC block, calculate and apply tuning timings
> + * @i2c_dev: Controller's private data
> + */
> +static void st_i2c_hw_config(struct st_i2c_dev *i2c_dev)
> +{
> + unsigned long rate;
> + u32 val, ns_per_clk;
> + struct st_i2c_timings *t = _timings[i2c_dev->mode];
> +
> + st_i2c_soft_reset(i2c_dev);
> +
> + val = SSC_CLR_REPSTRT | SSC_CLR_NACK | SSC_CLR_SSCARBL |
> + SSC_CLR_SSCAAS | SSC_CLR_SSCSTOP;
> + writel(val, i2c_dev->base + SSC_CLR);
> +
> + /* SSC Control register setup */
> + val = SSC_CTL_PO | SSC_CTL_PH | SSC_CTL_HB | SSC_CTL_DATA_WIDTH_9;
> + writel(val, i2c_dev->base + SSC_CTL);
> +
> + rate = clk_get_rate(i2c_dev->clk);
> + ns_per_clk = 10 / rate;
> +
> + /* Baudrate */
> + val = rate / (2 * t->rate);
> + writel(val, i2c_dev->base + SSC_BRG);
> +
> + /* Pre-scaler baudrate */
> + writel(1, i2c_dev->base + SSC_PRE_SCALER_BRG);
> +
> + /* Enable I2C mode */
> + writel(SSC_I2C_I2CM, i2c_dev->base + SSC_I2C);
> +
> + /* Repeated start hold time */
> + val = t->rep_start_hold / ns_per_clk;
> + writel(val, i2c_dev->base + SSC_REP_START_HOLD);
> +
> + /* Repeated start set up time */
> + val = t->rep_start_setup / ns_per_clk;
> + writel(val, i2c_dev->base + SSC_REP_START_SETUP);
> +
> + /* Start hold time */
> + val = t->start_hold / ns_per_clk;
> + writel(val, i2c_dev->base + SSC_START_HOLD);
> +
> + /* Data set up time */
> + val = t->data_setup_time / ns_per_clk;
> + writel(val, i2c_dev->base + SSC_DATA_SETUP);
> +
> + /* Stop set up time */
> + val = t->stop_setup_time / ns_per_clk;
> + writel(val, i2c_dev->base + SSC_STOP_SETUP);
> +
> + /* Bus free time */
> + val = t->bus_free_time / ns_per_clk;
> +
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
+/**
+ * struct st_i2c_dev - private data of the controller
+ * @adap: I2C adapter for this controller
+ * @dev: device for this controller
+ * @base: virtual memory area
+ * @complete: completion of I2C message
+ * @irq: interrupt line for th controller
+ * @clk: hw ssc block clock
+ * @mode: I2C mode of the controller. Standard or Fast only supported
+ * @deglitch: Anti-glitch filters parameters
+ * @client: I2C transfert information
+ * @busy: I2C transfer on-going
+ */
+struct st_i2c_dev {
+ struct i2c_adapter adap;
+ struct device *dev;
+ void __iomem*base;
+ struct completion complete;
+ int irq;
+ struct clk *clk;
+ int mode;
+ struct st_i2c_deglitch deglitch;
+ struct st_i2c_clientclient;
+ boolbusy;
+};
+
+static inline void st_i2c_set_bits(void __iomem *reg, u32 mask)
+{
+ writel(readl(reg) | mask, reg);
+}
+
+static inline void st_i2c_clr_bits(void __iomem *reg, u32 mask)
+{
+ writel(readl(reg) ~mask, reg);
use set_bit api and use relaxed version
+}
+
+/* From I2C Specifications v0.5 */
+static struct st_i2c_timings i2c_timings[] = {
+ [I2C_MODE_STANDARD] = {
+ .rate = 10,
+ .rep_start_hold = 4000,
+ .rep_start_setup= 4700,
+ .start_hold = 4000,
+ .data_setup_time= 250,
+ .stop_setup_time= 4000,
+ .bus_free_time = 4700,
+ },
+ [I2C_MODE_FAST] = {
+ .rate = 40,
+ .rep_start_hold = 600,
+ .rep_start_setup= 600,
+ .start_hold = 600,
+ .data_setup_time= 100,
+ .stop_setup_time= 600,
+ .bus_free_time = 1300,
+ },
+};
so how do you plane to support other rate that 100k and 400k?
+
+static void st_i2c_flush_rx_fifo(struct st_i2c_dev *i2c_dev)
+{
+ int count, i;
+
+ /*
+ * Counter only counts up to 7 but fifo size is 8...
+ * When fifo is full, counter is 0 and RIR bit of status register is
+ * set
+ */
+ if (readl(i2c_dev-base + SSC_STA) SSC_STA_RIR)
+ count = SSC_RXFIFO_SIZE;
+ else
+ count = readl(i2c_dev-base + SSC_RX_FSTAT)
+ SSC_RX_FSTAT_STATUS;
+
+ for (i = 0; i count; i++)
+ readl(i2c_dev-base + SSC_RBUF);
use readsl
use relaxed version as much as possible
+}
+
+static void st_i2c_soft_reset(struct st_i2c_dev *i2c_dev)
+{
+ /*
+ * FIFO needs to be emptied before reseting the IP,
+ * else the controller raises a BUSY error.
+ */
+ st_i2c_flush_rx_fifo(i2c_dev);
+
+ st_i2c_set_bits(i2c_dev-base + SSC_CTL, SSC_CTL_SR);
+ st_i2c_clr_bits(i2c_dev-base + SSC_CTL, SSC_CTL_SR);
+}
+
+/**
+ * st_i2c_hw_config() - Prepare SSC block, calculate and apply tuning timings
+ * @i2c_dev: Controller's private data
+ */
+static void st_i2c_hw_config(struct st_i2c_dev *i2c_dev)
+{
+ unsigned long rate;
+ u32 val, ns_per_clk;
+ struct st_i2c_timings *t = i2c_timings[i2c_dev-mode];
+
+ st_i2c_soft_reset(i2c_dev);
+
+ val = SSC_CLR_REPSTRT | SSC_CLR_NACK | SSC_CLR_SSCARBL |
+ SSC_CLR_SSCAAS | SSC_CLR_SSCSTOP;
+ writel(val, i2c_dev-base + SSC_CLR);
+
+ /* SSC Control register setup */
+ val = SSC_CTL_PO | SSC_CTL_PH | SSC_CTL_HB | SSC_CTL_DATA_WIDTH_9;
+ writel(val, i2c_dev-base + SSC_CTL);
+
+ rate = clk_get_rate(i2c_dev-clk);
+ ns_per_clk = 10 / rate;
+
+ /* Baudrate */
+ val = rate / (2 * t-rate);
+ writel(val, i2c_dev-base + SSC_BRG);
+
+ /* Pre-scaler baudrate */
+ writel(1, i2c_dev-base + SSC_PRE_SCALER_BRG);
+
+ /* Enable I2C mode */
+ writel(SSC_I2C_I2CM, i2c_dev-base + SSC_I2C);
+
+ /* Repeated start hold time */
+ val = t-rep_start_hold / ns_per_clk;
+ writel(val, i2c_dev-base + SSC_REP_START_HOLD);
+
+ /* Repeated start set up time */
+ val = t-rep_start_setup / ns_per_clk;
+ writel(val, i2c_dev-base + SSC_REP_START_SETUP);
+
+ /* Start hold time */
+ val = t-start_hold / ns_per_clk;
+ writel(val, i2c_dev-base + SSC_START_HOLD);
+
+ /* Data set up time */
+ val = t-data_setup_time / ns_per_clk;
+ writel(val, i2c_dev-base + SSC_DATA_SETUP);
+
+ /* Stop set up time */
+ val = t-stop_setup_time / ns_per_clk;
+ writel(val, i2c_dev-base + SSC_STOP_SETUP);
+
+ /* Bus free time */
+ val = t-bus_free_time / ns_per_clk;
+ writel(val, i2c_dev-base + SSC_BUS_FREE);
+
+ /* Prescalers set up */
+ val = rate / 1000;
+ writel(val, i2c_dev-base + SSC_PRSCALER);
+ writel(val,
