Re: [PATCH 1/4] i2c: busses: i2c-st: Add ST I2C controller
Hi Pawel, On 10/02/2013 11:35 AM, Maxime Coquelin wrote: > > On 10/02/2013 11:02 AM, Wolfram Sang wrote: > +Optional properties : > +- 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. Are those properties specific to this binding, or intended to be generic? If specific to this binding, a vendor prefix should be present in the property name. If not, you probably want to document the properties in some common file. >>> Ok. >>> In last revision, I put this properties as specific to this binding. >>> Wolfram proposed to make this generic, but it looks like this IP is the >>> only one >>> needing such properties. >>> >>> Wolfram, what would you advise? >> It might be the only SoC now, but I could imagine that other will have >> something similar in the future. I am not perfectly sure, though. So, I >> asked for opinions from DT experts when I suggested those bindings. We >> could start with vendor specific bindings and generalize them later if >> similar ones appear. Yet my experience is that old drivers rarely get >> converted to the new bindings. > Ok. > But if I start with vendor specific bindings, we will have to support it > forever, right? I would be glad to have your opinion on this. Since there are no other vendors currently having this feature, should we put these properties vendor specific? Or put them generic in case of someone has the same feature in the future? 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 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 10/02/2013 11:02 AM, Wolfram Sang wrote: +Optional properties : +- 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. >>> Are those properties specific to this binding, or intended to be >>> generic? If specific to this binding, a vendor prefix should be present >>> in the property name. If not, you probably want to document the >>> properties in some common file. >> Ok. >> In last revision, I put this properties as specific to this binding. >> Wolfram proposed to make this generic, but it looks like this IP is the >> only one >> needing such properties. >> >> Wolfram, what would you advise? > It might be the only SoC now, but I could imagine that other will have > something similar in the future. I am not perfectly sure, though. So, I > asked for opinions from DT experts when I suggested those bindings. We > could start with vendor specific bindings and generalize them later if > similar ones appear. Yet my experience is that old drivers rarely get > converted to the new bindings. Ok. But if I start with vendor specific bindings, we will have to support it forever, right? > >> If you still prefer to make this properties generics, in which file should I >> document it? I don't see any common i2c binding document for now. > Yeah, it is missing sadly. That's on my todo-list, like many other > things... OK :-) 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 1/4] i2c: busses: i2c-st: Add ST I2C controller
> >> +Optional properties : > >> +- 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. > > Are those properties specific to this binding, or intended to be > > generic? If specific to this binding, a vendor prefix should be present > > in the property name. If not, you probably want to document the > > properties in some common file. > Ok. > In last revision, I put this properties as specific to this binding. > Wolfram proposed to make this generic, but it looks like this IP is the > only one > needing such properties. > > Wolfram, what would you advise? It might be the only SoC now, but I could imagine that other will have something similar in the future. I am not perfectly sure, though. So, I asked for opinions from DT experts when I suggested those bindings. We could start with vendor specific bindings and generalize them later if similar ones appear. Yet my experience is that old drivers rarely get converted to the new bindings. > If you still prefer to make this properties generics, in which file should I > document it? I don't see any common i2c binding document for now. Yeah, it is missing sadly. That's on my todo-list, like many other things... Regards, Wolfram signature.asc Description: Digital signature
Re: [PATCH 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 10/01/2013 10:45 PM, Stephen Warren wrote:
> On 10/01/2013 04:39 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.
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt
>> b/Documentation/devicetree/bindings/i2c/i2c-st.txt
>> +Required properties :
>> +- clocks : phandle to the I2C clock source
>> +- clock-names : from common clock binding: Shall be "ssc"
> I'd prefer to define that as:
>
> clock-names: Must contain "ssc".
> clocks: Must contain an entry for each name in clock-names. See the
> common clock bindings.
>
> That way, it makes it clear that clock-names is the primary lookup
> mechanism, rather than some auxiliary documentation.
OK. This will be done in next series.
>
>> +Recommended properties :
>> +- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
> s/Otherwise/If not specified,/
Done.
>
>> + the default 100 kHz frequency will be used. As only Normal and Fast modes
>> + are supported, possible values are 10 and 40.
> I think that's just optional. Since there's a well-defined sensible
> default, there's no need to recommend it.
OK, I move it to optional.
>> +Optional properties :
>> +- 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.
> Are those properties specific to this binding, or intended to be
> generic? If specific to this binding, a vendor prefix should be present
> in the property name. If not, you probably want to document the
> properties in some common file.
Ok.
In last revision, I put this properties as specific to this binding.
Wolfram proposed to make this generic, but it looks like this IP is the
only one
needing such properties.
Wolfram, what would you advise?
If you still prefer to make this properties generics, in which file should I
document it? I don't see any common i2c binding document for now.
>
>> +Examples :
> s/Examples/Example/ since there's just one.
Ok.
>
>> +i2c0: i2c@fed4 {
>> +compatible = "st,comms-ssc-i2c";
>> +reg = <0xfed4 0x110>;
>> +interrupts = ;
>> +clocks = <&CLK_S_ICN_REG_0>;
>> +clock-names = "ssc";
>> +clock-frequency = <40>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&pinctrl_i2c0_default>;
> That wasn't mentioned in the binding definition. You'd probably want to
> document the requirement for those two properties by saying something like:
>
> A pinctrl state named "default" must be defined, using the bindings in
> ../pinctrl/pinctrl-binding.txt.
Ok. I will also add the "sleep" state in the optional definitions.
Thanks for the review Stephen.
Regards,
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 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 10/01/2013 04:39 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.
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt
> b/Documentation/devicetree/bindings/i2c/i2c-st.txt
> +Required properties :
> +- clocks : phandle to the I2C clock source
> +- clock-names : from common clock binding: Shall be "ssc"
I'd prefer to define that as:
clock-names: Must contain "ssc".
clocks: Must contain an entry for each name in clock-names. See the
common clock bindings.
That way, it makes it clear that clock-names is the primary lookup
mechanism, rather than some auxiliary documentation.
> +Recommended properties :
> +- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
s/Otherwise/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.
I think that's just optional. Since there's a well-defined sensible
default, there's no need to recommend it.
> +Optional properties :
> +- 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.
Are those properties specific to this binding, or intended to be
generic? If specific to this binding, a vendor prefix should be present
in the property name. If not, you probably want to document the
properties in some common file.
> +Examples :
s/Examples/Example/ since there's just one.
> +i2c0: i2c@fed4 {
> + compatible = "st,comms-ssc-i2c";
> + reg = <0xfed4 0x110>;
> + interrupts = ;
> + clocks = <&CLK_S_ICN_REG_0>;
> + clock-names = "ssc";
> + clock-frequency = <40>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c0_default>;
That wasn't mentioned in the binding definition. You'd probably want to
document the requirement for those two properties by saying something like:
A pinctrl state named "default" must be defined, using the bindings in
../pinctrl/pinctrl-binding.txt.
--
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 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 09/24/2013 05:59 PM, Wolfram Sang wrote: >> "glitch" is is used to tune the I2C timing requirements, and has a >> nanosecond granularity. >> These values are added to default timing values. >> I'm not 100% sure, but it looks like the "samsung,i2c-sda-delay" in the >> i2c-s3c2410 driver. > For that, we have the generic "i2c-sda-hold-time-ns" property. The s3c > driver hasn't been converted to use it, sadly. > Ok, thank you for pointing this out. After some checks, this property doesn't match with what is done in this driver. In the v2 series I am sending, I removed the I2C timing tuning as it works on all the boards I have tested with. I will only keep the anti-glitch filtering, using private properties as I didn't find any generic ones that could fit. Regards, 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 1/4] i2c: busses: i2c-st: Add ST I2C controller
> "glitch" is is used to tune the I2C timing requirements, and has a > nanosecond granularity. > These values are added to default timing values. > I'm not 100% sure, but it looks like the "samsung,i2c-sda-delay" in the > i2c-s3c2410 driver. For that, we have the generic "i2c-sda-hold-time-ns" property. The s3c driver hasn't been converted to use it, sadly. signature.asc Description: Digital signature
Re: [PATCH 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 09/23/2013 11:06 PM, Stephen Warren wrote: > On 09/18/2013 04:01 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. >> diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt >> b/Documentation/devicetree/bindings/i2c/i2c-st.txt >> +I2C for ST platforms > If the HW block supports both I2C and SPI, the DT binding ought to > support that too. It's be best to create a single DT binding that > represents the IP block, and include a property that indicates whether > the device should operate in I2C or SPI mode. > > I suppose you could reasonably define different compatible values for > those two cases. However, the binding should be titled something more > like "ST SSC binding, for I2C mode operation" and "ST SSC binding, for > SPI mode operation", rather than "I2C for ST platforms", since the HW > includes an SSC block, not an I2C block. You are right Stephen. I will rename the title and change the compatible value as per your recommendation. >> +Required properties : >> +- compatible : Must be "st,comms-i2c" >> +- reg : Offset and length of the register set for the device >> +- interrupts : the interrupt number > It's an interrupt specifier, not an interrupt number. The format is > defined by the interrupt controller, not this binding. Ok. I will change to "the interrupt specifier". >> +- clocks : phandle to the I2C clock source > What about clock-names? It will be added in next revision. It will be named "ssc" >> +Recommended (non-standard) properties : > Usually you'd just say "Optional properties:", or perhaps "Recommended > properties:". I don't think adding "(non-standard)" serves any purpose. Ok. then I will remove all the "non-standard" occurences. >> +- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise >> + the default 100 kHz frequency will be used. As only Normal and Fast modes >> + are supported, possible values are 10 and 40. >> + >> +Optional (non-standard) properties: > Same here. > >> +- st,glitches : Enable timing glitch suppression support. > That property name doesn't really convey the "enables" that appears in > the property description to me... > >> +- st,glitch-clk : SCL line timinig glitch suppression value in ns. >> +- st,glitch-dat : SDA line timinig glitch suppression value in ns. > s/timinig/timing/ > >> +- st,hw-glitches : Enable filter glitch suppression support. >> +- st,hw-glitch-clk : SCL line filter glitch suppression value in us. >> +- st,hw-glitch-dat : SDA line filter glitch suppression value in us. > Those sound more like runtime configuration rather than HW description. > Can you rephrase the descriptions (and property names) more along the > lines of HW properties? Perhaps e.g.: > > st,needs-glitch-suppression: The board design needs timing glitch > suppression enabled to operate reliably. > > st,min-scl-pulse-width: The minimum valid SCL pulse width that is > allowed through the deglitch circuit. In units of ns. > > (I just made up those descriptions to give a feel for the flavor of > description that I expect. They likely need some adjustment to reflect > whatever they're actually intended to represent in HW). > > What is the difference between "glitch" and "hw-glitch"? "hw-glitch" is used to configure the anti-glitch filters. It suppresses the pulses with a width lower than x microseconds. "glitch" is is used to tune the I2C timing requirements, and has a nanosecond granularity. These values are added to default timing values. I'm not 100% sure, but it looks like the "samsung,i2c-sda-delay" in the i2c-s3c2410 driver. I agree the names and descriptions are not clear, and even misleading. I will come with a clearer implementation, as soon as I get clarification from HW team. 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 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 09/18/2013 04:01 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. > diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt > b/Documentation/devicetree/bindings/i2c/i2c-st.txt > +I2C for ST platforms If the HW block supports both I2C and SPI, the DT binding ought to support that too. It's be best to create a single DT binding that represents the IP block, and include a property that indicates whether the device should operate in I2C or SPI mode. I suppose you could reasonably define different compatible values for those two cases. However, the binding should be titled something more like "ST SSC binding, for I2C mode operation" and "ST SSC binding, for SPI mode operation", rather than "I2C for ST platforms", since the HW includes an SSC block, not an I2C block. > +Required properties : > +- compatible : Must be "st,comms-i2c" > +- reg : Offset and length of the register set for the device > +- interrupts : the interrupt number It's an interrupt specifier, not an interrupt number. The format is defined by the interrupt controller, not this binding. > +- clocks : phandle to the I2C clock source What about clock-names? > +Recommended (non-standard) properties : Usually you'd just say "Optional properties:", or perhaps "Recommended properties:". I don't think adding "(non-standard)" serves any purpose. > +- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise > + the default 100 kHz frequency will be used. As only Normal and Fast modes > + are supported, possible values are 10 and 40. > + > +Optional (non-standard) properties: Same here. > +- st,glitches : Enable timing glitch suppression support. That property name doesn't really convey the "enables" that appears in the property description to me... > +- st,glitch-clk : SCL line timinig glitch suppression value in ns. > +- st,glitch-dat : SDA line timinig glitch suppression value in ns. s/timinig/timing/ > +- st,hw-glitches : Enable filter glitch suppression support. > +- st,hw-glitch-clk : SCL line filter glitch suppression value in us. > +- st,hw-glitch-dat : SDA line filter glitch suppression value in us. Those sound more like runtime configuration rather than HW description. Can you rephrase the descriptions (and property names) more along the lines of HW properties? Perhaps e.g.: st,needs-glitch-suppression: The board design needs timing glitch suppression enabled to operate reliably. st,min-scl-pulse-width: The minimum valid SCL pulse width that is allowed through the deglitch circuit. In units of ns. (I just made up those descriptions to give a feel for the flavor of description that I expect. They likely need some adjustment to reflect whatever they're actually intended to represent in HW). What is the difference between "glitch" and "hw-glitch"? -- 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 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 09/18/2013 06:47 AM, Gabriel FERNANDEZ wrote: > On 18/09/2013 12:01, 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. > ... [entire patch quoted for a one-line comment] ... Please trim down the patch so you only quote relevant lines. Quoting the entire patch for a 1-line comment makes people wast time searching for your reply. -- 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 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 18/09/2013 12:01, 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.
>
> Cc: Srinivas Kandagatla
> Signed-off-by: Maxime Coquelin
> ---
> Documentation/devicetree/bindings/i2c/i2c-st.txt | 35 ++
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile |1 +
> drivers/i2c/busses/i2c-st.c | 713
> ++
> drivers/i2c/busses/i2c-st.h | 216 +++
> 5 files changed, 975 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st.txt
> create mode 100644 drivers/i2c/busses/i2c-st.c
> create mode 100644 drivers/i2c/busses/i2c-st.h
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt
> b/Documentation/devicetree/bindings/i2c/i2c-st.txt
> new file mode 100644
> index 000..a7d6381
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt
> @@ -0,0 +1,35 @@
> +I2C for ST platforms
> +
> +Required properties :
> +- compatible : Must be "st,comms-i2c"
> +- reg : Offset and length of the register set for the device
> +- interrupts : the interrupt number
> +- clocks : phandle to the I2C clock source
> +
> +Recommended (non-standard) properties :
> +- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
> + the default 100 kHz frequency will be used. As only Normal and Fast modes
> + are supported, possible values are 10 and 40.
> +
> +Optional (non-standard) properties:
> +- st,glitches : Enable timing glitch suppression support.
> +- st,glitch-clk : SCL line timinig glitch suppression value in ns.
> +- st,glitch-dat : SDA line timinig glitch suppression value in ns.
> +- st,hw-glitches : Enable filter glitch suppression support.
> +- st,hw-glitch-clk : SCL line filter glitch suppression value in us.
> +- st,hw-glitch-dat : SDA line filter glitch suppression value in us.
> +
> +Examples :
> +
> +i2c0: i2c@fed4{
Space before the '{'
> + compatible = "st,comms-i2c";
> + reg = <0xfed4 0x110>;
> + interrupts = ;
> + clocks = <&CLK_S_ICN_REG_0>;
> + clock-frequency = <40>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c0_default>;
> + st,glitches;
> + st,glitch-clk = 500;
> + st,glitch-dat = 500;
> +};
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index cdcbd83..18ff129 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -776,6 +776,16 @@ config I2C_RCAR
>This driver can also be built as a module. If so, the module
>will be called i2c-rcar.
>
> +config I2C_ST
> + tristate "STMicroelectronics SSC I2C support"
> + depends on ARCH_STI
> + help
> + Enable this option to add support for STMicroelectronics SoCs
> + hardware SSC (Synchronous Serial Controller) as an I2C controller.
> +
> + This driver can also be built as module. If so, the module
> + will be called i2c-st.
> +
> comment "External I2C/SMBus adapter drivers"
>
> config I2C_DIOLAN_U2C
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index d00997f..9ea5d422 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -92,5 +92,6 @@ obj-$(CONFIG_I2C_PCA_ISA) += i2c-pca-isa.o
> obj-$(CONFIG_I2C_SIBYTE) += i2c-sibyte.o
> obj-$(CONFIG_SCx200_ACB) += scx200_acb.o
> obj-$(CONFIG_SCx200_I2C) += scx200_i2c.o
> +obj-$(CONFIG_I2C_ST) += i2c-st.o
>
> ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
> diff --git a/drivers/i2c/busses/i2c-st.c b/drivers/i2c/busses/i2c-st.c
> new file mode 100644
> index 000..fa4451f
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-st.c
> @@ -0,0 +1,713 @@
> +/*
> + * Copyright (C) 2013 STMicroelectronics
> + *
> + * I2C master mode controller driver, used in STMicroelectronics devices.
> + *
> + * Author: Maxime Coquelin
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2, as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "i2c-st.h"
> +
> +#define DRIVER_NAME "st-i2c"
> +
> +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
