Re: [PATCH 1/5] ARM: shmobile: kzm9g legacy: Set i2c clks_per_count to 2
Hi Wolfram,
On Fri, Nov 7, 2014 at 6:24 AM, Wolfram Sang wrote:
>> Note that the L/H values still differ from the Transfer Rate Settings
>> example in Table 19.3 of the datasheet, which suggests 0x121/0xe7.
>
> Is the formula different or is it rounding errors?
The formula is different. It doesn't use absolute tLOW, tHIGH, and tF
values, but only the duty cycle of the clock.
It's similar in the R-Car Gen2 docs. Except that on Gen2, there's no
mention of using a duty cycle of 5/3 for High Speed like on AG5.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ARM: shmobile: r8a73a4 dtsi: Add SoC-specific IIC compatible properties
On Thu, Nov 06, 2014 at 12:52:10PM +0100, Geert Uytterhoeven wrote: > The IIC nodes used the generic compatible properties only. > This may cause the driver to fail when using Standard Speed on IIC > masters where the operational clock is driven by the 130 MHz HP clock. > > Add the SoC-specific compatible property to fix this. > > Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang signature.asc Description: Digital signature
Re: [PATCH 4/5] ARM: shmobile: sh73a0 dtsi: Add SoC-specific IIC compatible properties
On Thu, Nov 06, 2014 at 12:52:09PM +0100, Geert Uytterhoeven wrote: > The IIC nodes used the generic compatible properties only. > This causes the driver to fail when using Standard Speed, as the > operational clock is driven by the 104 MHz HP clock: > > i2c-sh_mobile e682.i2c: timing values out of range: L/H=0x208/0x1bf > i2c-sh_mobile: probe of e682.i2c failed with error -22 > > Add the SoC-specific compatible property to fix this. > > Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang signature.asc Description: Digital signature
Re: [PATCH 1/5] ARM: shmobile: kzm9g legacy: Set i2c clks_per_count to 2
On Thu, Nov 06, 2014 at 12:52:06PM +0100, Geert Uytterhoeven wrote: > On sh73a0/kzm9g-legacy, probing of the i2c masters fails with: > > i2c-sh_mobile i2c-sh_mobile.0: timing values out of range: L/H=0x208/0x1bf > sh_mobile: probe of i2c-sh_mobile.0 failed with error -22 Yay, so the warning I added found another bug \o/ > > According to the datasheet, the transfer rate is derived from the HP > clock (which runs at 104 MHz) divided by two. Hence > i2c_sh_mobile_platform_data.clks_per_count should be set to two. > > Now probing succeeds, and i2c works: > > i2c-sh_mobile i2c-sh_mobile.0: I2C adapter 0 with bus speed 10 Hz > (L/H=0x104/0xe0) > > Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang > --- > Note that the L/H values still differ from the Transfer Rate Settings > example in Table 19.3 of the datasheet, which suggests 0x121/0xe7. Is the formula different or is it rounding errors? Thanks, Wolfram signature.asc Description: Digital signature
Re: [PATCH 3/5] i2c: sh_mobile: Document SoC-specific bindings
On Thu, Nov 06, 2014 at 12:52:08PM +0100, Geert Uytterhoeven wrote: > Explicitly list the various SoC-specific compatible properties. > This allows checkpatch to validate DTSes. > > Signed-off-by: Geert Uytterhoeven Acked-by: Simon Horman > --- > Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt > b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt > index d2153ce36fa81404..c33e9a32d496ef10 100644 > --- a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt > +++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt > @@ -2,6 +2,15 @@ Device tree configuration for Renesas IIC (sh_mobile) driver > > Required properties: > - compatible : "renesas,iic-". "renesas,rmobile-iic" as > fallback > + Examples with soctypes are: > + - "renesas,iic-r8a73a4" (R-Mobile APE6) > + - "renesas,iic-r8a7740" (R-Mobile A1) > + - "renesas,iic-r8a7790" (R-Car H2) > + - "renesas,iic-r8a7791" (R-Car M2-W) > + - "renesas,iic-r8a7792" (R-Car V2H) > + - "renesas,iic-r8a7793" (R-Car M2-N) > + - "renesas,iic-r8a7794" (R-Car E2) > + - "renesas,iic-sh73a0" (SH-Mobile AG5) > - reg : address start and address range size of device > - interrupts : interrupt of device > - clocks : clock for device > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] i2c-imx: Use the preferred form for passing a size of a struct
From: Fabio Estevam According to Documentation/CodingStyle - Chapter 14: "The preferred form for passing a size of a struct is the following: p = kmalloc(sizeof(*p), ...); The alternative form where struct name is spelled out hurts readability and introduces an opportunity for a bug when the pointer variable type is changed but the corresponding sizeof that is passed to a memory allocator is not." So do it as recommeded. Signed-off-by: Fabio Estevam --- drivers/i2c/busses/i2c-imx.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c index c48e46a..47269e0 100644 --- a/drivers/i2c/busses/i2c-imx.c +++ b/drivers/i2c/busses/i2c-imx.c @@ -673,8 +673,7 @@ static int i2c_imx_probe(struct platform_device *pdev) if (IS_ERR(base)) return PTR_ERR(base); - i2c_imx = devm_kzalloc(&pdev->dev, sizeof(struct imx_i2c_struct), - GFP_KERNEL); + i2c_imx = devm_kzalloc(&pdev->dev, sizeof(*i2c_imx), GFP_KERNEL); if (!i2c_imx) return -ENOMEM; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] i2c-mxs: Use the preferred form for passing a size of a struct
From: Fabio Estevam According to Documentation/CodingStyle - Chapter 14: "The preferred form for passing a size of a struct is the following: p = kmalloc(sizeof(*p), ...); The alternative form where struct name is spelled out hurts readability and introduces an opportunity for a bug when the pointer variable type is changed but the corresponding sizeof that is passed to a memory allocator is not." So do it as recommeded. Signed-off-by: Fabio Estevam --- drivers/i2c/busses/i2c-mxs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c index 07e1be6..3e7893a 100644 --- a/drivers/i2c/busses/i2c-mxs.c +++ b/drivers/i2c/busses/i2c-mxs.c @@ -811,7 +811,7 @@ static int mxs_i2c_probe(struct platform_device *pdev) struct resource *res; int err, irq; - i2c = devm_kzalloc(dev, sizeof(struct mxs_i2c_dev), GFP_KERNEL); + i2c = devm_kzalloc(dev, sizeof(*i2c), GFP_KERNEL); if (!i2c) return -ENOMEM; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH V2] ACPI: Add _DEP(Operation Region Dependencies) support to fix battery issue on the Asus T100TA
On Thursday, November 06, 2014 08:19:52 AM Mika Westerberg wrote:
> On Wed, Nov 05, 2014 at 10:55:23PM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 05, 2014 10:54:14 AM Mika Westerberg wrote:
> > > On Mon, Oct 27, 2014 at 11:09:44PM +0800, Lan Tianyu wrote:
> > > > ACPI 5.0 introduces _DEP to designate device objects that OSPM should
> > > > assign a higher priority in start ordering due to future operation
> > > > region
> > > > accesses.
> > > >
> > > > On Asus T100TA, ACPI battery info are read from a I2C slave device via
> > > > I2C operation region. Before I2C operation region handler is installed,
> > > > battery _STA always returns 0. There is a _DEP method of designating
> > > > start order under battery device node.
> > > >
> > > > This patch is to implement _DEP feature to fix battery issue on the
> > > > Asus T100TA.
> > > > Introducing acpi_dep_list and adding dep_unmet count in the struct
> > > > acpi_device. During ACPI namespace scan, create struct acpi_dep_data
> > > > for a
> > > > valid pair of master (device pointed to by _DEP)/slave(device with
> > > > _DEP), record
> > > > master's and slave's ACPI handle in it and put it into acpi_dep_list.
> > > > The dep_unmet
> > > > count will increase by one if there is a device under its _DEP.
> > > > Driver's probe() should
> > > > return EPROBE_DEFER when find dep_unmet larger than 0. When I2C
> > > > operation
> > > > region handler is installed, remove all struct acpi_dep_data on the
> > > > acpi_dep_list
> > > > whose master is pointed to I2C host controller and decrease slave's
> > > > dep_unmet.
> > > > When dep_unmet decreases to 0, all _DEP conditions are met and then do
> > > > acpi_bus_attach()
> > > > for the device in order to resolve battery _STA issue on the Asus
> > > > T100TA.
> > >
> > > Is there a reason why the driver core can't handle this automatically in
> > > such way that when there are unmet dependencies, it will not probe the
> > > device? Or am I missing something?
> >
> > Yes, there is a reason: There's no way to represent such dependencies in the
> > driver core. :-)
> >
> > That's been discussed for several times (and I've even mentioned _DEP in one
> > of those discussions) and it's always ended up being seen as "complexity
> > nightmare".
>
> OK, I see.
>
> > > Now it looks like the driver itself needs to know about these and handle
> > > them somehow.
> >
> > The patch is missing the user of it which is going to be the battery driver
> > only for the time being. Tianyu, can you please include the battery changes
> > into the patch at least for now?
> >
> > > I'm asking this because there are other things like devices using GPIOs
> > > that also take advantage of _DEP, like this on Asus T100:
> > >
> > > Device (SDHB)
> > > {
> > > Name (_ADR, Zero) // _ADR: Address
> > > Name (_HID, "INT33BB") // _HID: Hardware ID
> > > ...
> > > Name (_DEP, Package (0x02) // _DEP: Dependencies
> > > {
> > > PEPD,
> > > GPO2
> > > })
> > >
> > > I don't know what PEPD is but GPO2 is the GPIO controller.
> >
> > Well, if you read the definition of _DEP in ACPI 5.1, it is all about
> > operation
> > regions, so this smells like abuse of sorts. In any case, it is hard to
> > argue
> > that _DEP is not internal to ACPI because of that definition.
>
> So if we have a device, like SDHB above (SDIO controller), that needs
> GPIOs for powering the SDIO card and that is done by using GPIO
> operation regions how do we ensure that the GPIO controller driver is
> there?
>
> I think the answer is that we just make sure the the GPIO driver is
> there before anything that is going to use it. E.g make it
> subsys_initcall() or so?
The current approach, which arguably is lame, has been to (1) compile in
all drivers that *may* be depended on (like all drviers registering operation
region handlers) and then (2) trick the devices to be registered in the right
order.
I'd rather have a more robust mechanism than that, but so far no one has
proposed anything remotely usable.
As far as _DEP is concerned, it seems that in *practice* it is used to
reflect functional dependencies between devices rather than the operation
regions thing only (as specified). In that case we may decide to follow
the practice rather than the spec (and move to update the spec to reflect
the practice at the same time), but that requires some consideration.
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c-qoriq: modified compatibility for correct prescaler
On Wed, 2014-10-29 at 09:59 +0100, Valentin Longchamp wrote:
> On 10/29/2014 12:08 AM, Scott Wood wrote:
> > On Fri, 2014-10-17 at 11:27 +0200, Valentin Longchamp wrote:
> >> With "fsl-i2c" compatibility the i2c frequency is not set
> >> correctly, because it sets no prescaler. According to the AN2919 from
> >> Freescale and the QorIQ (P2041) documentation, the source clock is 1/2
> >> the platform clock. This implies that a prescaler of 2 must be used.
> >>
> >> This changes the compatibility of the qoriq-i2c .dtsi files to pick the
> >> mpc8543, which uses the same driver but sets the correct prescaler.
> >>
> >> Signed-off-by: Rainer Boschung
> >> Signed-off-by: Valentin Longchamp
> >> ---
> >>
> >> arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi | 4 ++--
> >> arch/powerpc/boot/dts/fsl/qoriq-i2c-1.dtsi | 4 ++--
> >> 2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
> >> b/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
> >> index 5f9bf7d..aa6c366 100644
> >> --- a/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
> >> +++ b/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
> >> @@ -36,7 +36,7 @@ i2c@118000 {
> >>#address-cells = <1>;
> >>#size-cells = <0>;
> >>cell-index = <0>;
> >> - compatible = "fsl-i2c";
> >> + compatible = "fsl,mpc8543-i2c", "fsl-i2c";
> >>reg = <0x118000 0x100>;
> >>interrupts = <38 2 0 0>;
> >>dfsrr;
> >> @@ -46,7 +46,7 @@ i2c@118100 {
> >>#address-cells = <1>;
> >>#size-cells = <0>;
> >>cell-index = <1>;
> >> - compatible = "fsl-i2c";
> >> + compatible = "fsl,mpc8543-i2c", "fsl-i2c";
> >>reg = <0x118100 0x100>;
> >>interrupts = <38 2 0 0>;
> >>dfsrr;
> >
> > Are all chips that use this dtsi 100% compatible with mpc8543's i2c, or
> > just in ways the Linux driver cares about?
>
> I have just looked briefly at the mpc8548 RM (covers mpc8543) and its i2c
> controller looks the same as the qoriq's. I cannot however state if they are
> 100% compatible.
>
> If we wanted to be on the safe side and strict (since we are not sure that the
> hardware is 100% compatible), we maybe should add a fsl,qoriq-i2c compatible
> to
> the driver that does the same as mpc8543-i2c.
If we're going to change the device tree I'd rather just add a property
to say what the prescaler is.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] i2c: Add Imagination Technologies I2C SCB driver
On 11/06/2014 01:51 PM, Vladimir Zapolskiy wrote:
> Hi Ezequiel,
>
> On 05.11.2014 22:21, Ezequiel Garcia wrote:
>> From: James Hogan
>>
>> Add support for the IMG I2C Serial Control Bus (SCB) found on the
>> Pistachio and TZ1090 SoCs.
>>
>> Signed-off-by: James Hogan
>> [Ezequiel: code cleaning and rebasing]
>> Signed-off-by: Ezequiel Garcia
>> ---
>> drivers/i2c/busses/Kconfig | 10 +
>> drivers/i2c/busses/Makefile |1 +
>> drivers/i2c/busses/i2c-img-scb.c | 1397
>> ++
>> 3 files changed, 1408 insertions(+)
>> create mode 100644 drivers/i2c/busses/i2c-img-scb.c
>>
>
> [snip]
>
>> +static int img_i2c_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg *msgs,
>> +int num)
>> +{
>> +struct img_i2c *i2c = i2c_get_adapdata(i2c_adap);
>> +bool atomic = false;
>> +int i;
>> +
>> +if (i2c->mode == MODE_SUSPEND) {
>> +WARN(1, "refusing to service transaction in suspended state\n");
>> +return -EIO;
>> +}
>> +
>> +if (i2c->mode == MODE_FATAL)
>> +return -EIO;
>> +
>> +for (i = 0; i < num; i++) {
>> +if (likely(msgs[i].len))
>> +continue;
>> +/*
>> + * 0 byte reads are not possible because the slave could try
>> + * and pull the data line low, preventing a stop bit.
>> + */
>> +if (unlikely(msgs[i].flags & I2C_M_RD))
>> +return -EIO;
>> +/*
>> + * 0 byte writes are possible and used for probing, but we
>> + * cannot do them in automatic mode, so use atomic mode
>> + * instead.
>> + */
>> +atomic = true;
>> +}
>> +
>> +clk_prepare_enable(i2c->scb_clk);
>
> Does it make sense to add a check for returned error here?
>
Right, that makes sense.
--
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] i2c: Add Imagination Technologies I2C SCB driver
Hi Ezequiel,
On 05.11.2014 22:21, Ezequiel Garcia wrote:
> From: James Hogan
>
> Add support for the IMG I2C Serial Control Bus (SCB) found on the
> Pistachio and TZ1090 SoCs.
>
> Signed-off-by: James Hogan
> [Ezequiel: code cleaning and rebasing]
> Signed-off-by: Ezequiel Garcia
> ---
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile |1 +
> drivers/i2c/busses/i2c-img-scb.c | 1397
> ++
> 3 files changed, 1408 insertions(+)
> create mode 100644 drivers/i2c/busses/i2c-img-scb.c
>
[snip]
> +static int img_i2c_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg *msgs,
> + int num)
> +{
> + struct img_i2c *i2c = i2c_get_adapdata(i2c_adap);
> + bool atomic = false;
> + int i;
> +
> + if (i2c->mode == MODE_SUSPEND) {
> + WARN(1, "refusing to service transaction in suspended state\n");
> + return -EIO;
> + }
> +
> + if (i2c->mode == MODE_FATAL)
> + return -EIO;
> +
> + for (i = 0; i < num; i++) {
> + if (likely(msgs[i].len))
> + continue;
> + /*
> + * 0 byte reads are not possible because the slave could try
> + * and pull the data line low, preventing a stop bit.
> + */
> + if (unlikely(msgs[i].flags & I2C_M_RD))
> + return -EIO;
> + /*
> + * 0 byte writes are possible and used for probing, but we
> + * cannot do them in automatic mode, so use atomic mode
> + * instead.
> + */
> + atomic = true;
> + }
> +
> + clk_prepare_enable(i2c->scb_clk);
Does it make sense to add a check for returned error here?
> + for (i = 0; i < num; i++) {
> + struct i2c_msg *msg = &msgs[i];
> + unsigned long flags;
> +
> + spin_lock_irqsave(&i2c->lock, flags);
> +
> + /*
> + * Make a copy of the message struct. We mustn't modify the
> + * original or we'll confuse drivers and i2c-dev.
> + */
> + i2c->msg = *msg;
> + i2c->msg_status = 0;
> +
> + /*
[snip]
> +
> +static int img_i2c_resume(struct device *dev)
> +{
> + struct img_i2c *i2c = dev_get_drvdata(dev);
> +
> + clk_enable(i2c->sys_clk);
Same question as above.
> + img_i2c_init(i2c);
> +
> + return 0;
> +}
> +#endif /* CONFIG_PM_SLEEP */
> +
> +static SIMPLE_DEV_PM_OPS(img_i2c_pm, img_i2c_suspend, img_i2c_resume);
> +
> +static const struct of_device_id img_scb_i2c_match[] = {
> + { .compatible = "img,scb-i2c" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, img_scb_i2c_match);
> +
> +static struct platform_driver img_scb_i2c_driver = {
> + .driver = {
> + .name = "img-i2c-scb",
> + .of_match_table = img_scb_i2c_match,
> + .pm = &img_i2c_pm,
> + },
> + .probe = img_i2c_probe,
> + .remove = img_i2c_remove,
> +};
> +module_platform_driver(img_scb_i2c_driver);
> +
> +MODULE_AUTHOR("James Hogan ");
> +MODULE_DESCRIPTION("IMG host I2C driver");
> +MODULE_LICENSE("GPL");
>
--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 3/3] gpio: add support for the Diolan DLN-2 USB GPIO driver
From: Daniel Baluta
This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module.
Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 2.9 for the GPIO
module commands and responses.
[1] https://www.diolan.com/downloads/dln-api-manual.pdf
Signed-off-by: Daniel Baluta
Signed-off-by: Octavian Purdila
Acked-by: Linus Walleij
Reviewed-by: Johan Hovold
---
drivers/gpio/Kconfig | 12 +
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-dln2.c | 553 +++
3 files changed, 566 insertions(+)
create mode 100644 drivers/gpio/gpio-dln2.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0959ca9..23dfd5f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -905,4 +905,16 @@ config GPIO_VIPERBOARD
River Tech's viperboard.h for detailed meaning
of the module parameters.
+config GPIO_DLN2
+ tristate "Diolan DLN2 GPIO support"
+ depends on MFD_DLN2
+ select GPIOLIB_IRQCHIP
+
+ help
+ Select this option to enable GPIO driver for the Diolan DLN2
+ board.
+
+ This driver can also be built as a module. If so, the module
+ will be called gpio-dln2.
+
endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index e5d346c..e60677b 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_GPIO_CRYSTAL_COVE) += gpio-crystalcove.o
obj-$(CONFIG_GPIO_DA9052) += gpio-da9052.o
obj-$(CONFIG_GPIO_DA9055) += gpio-da9055.o
obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o
+obj-$(CONFIG_GPIO_DLN2)+= gpio-dln2.o
obj-$(CONFIG_GPIO_DWAPB) += gpio-dwapb.o
obj-$(CONFIG_GPIO_EM) += gpio-em.o
obj-$(CONFIG_GPIO_EP93XX) += gpio-ep93xx.o
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
new file mode 100644
index 000..978b51e
--- /dev/null
+++ b/drivers/gpio/gpio-dln2.c
@@ -0,0 +1,553 @@
+/*
+ * Driver for the Diolan DLN-2 USB-GPIO adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DLN2_GPIO_ID 0x01
+
+#define DLN2_GPIO_GET_PIN_COUNTDLN2_CMD(0x01, DLN2_GPIO_ID)
+#define DLN2_GPIO_SET_DEBOUNCE DLN2_CMD(0x04, DLN2_GPIO_ID)
+#define DLN2_GPIO_GET_DEBOUNCE DLN2_CMD(0x05, DLN2_GPIO_ID)
+#define DLN2_GPIO_PORT_GET_VAL DLN2_CMD(0x06, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_VAL DLN2_CMD(0x0B, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_OUT_VAL DLN2_CMD(0x0C, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_OUT_VAL DLN2_CMD(0x0D, DLN2_GPIO_ID)
+#define DLN2_GPIO_CONDITION_MET_EV DLN2_CMD(0x0F, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_ENABLE DLN2_CMD(0x10, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_DISABLE DLN2_CMD(0x11, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_DIRECTIONDLN2_CMD(0x13, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_DIRECTIONDLN2_CMD(0x14, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_EVENT_CFGDLN2_CMD(0x1E, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_EVENT_CFGDLN2_CMD(0x1F, DLN2_GPIO_ID)
+
+#define DLN2_GPIO_EVENT_NONE 0
+#define DLN2_GPIO_EVENT_CHANGE 1
+#define DLN2_GPIO_EVENT_LVL_HIGH 2
+#define DLN2_GPIO_EVENT_LVL_LOW3
+#define DLN2_GPIO_EVENT_CHANGE_RISING 0x11
+#define DLN2_GPIO_EVENT_CHANGE_FALLING 0x21
+#define DLN2_GPIO_EVENT_MASK 0x0F
+
+#define DLN2_GPIO_MAX_PINS 32
+
+struct dln2_irq_work {
+ struct work_struct work;
+ struct dln2_gpio *dln2;
+ int pin;
+ int type;
+};
+
+struct dln2_gpio {
+ struct platform_device *pdev;
+ struct gpio_chip gpio;
+
+ /*
+* Cache pin direction to save us one transfer, since the hardware has
+* separate commands to read the in and out values.
+*/
+ DECLARE_BITMAP(output_enabled, DLN2_GPIO_MAX_PINS);
+
+ DECLARE_BITMAP(irqs_masked, DLN2_GPIO_MAX_PINS);
+ DECLARE_BITMAP(irqs_enabled, DLN2_GPIO_MAX_PINS);
+ DECLARE_BITMAP(irqs_pending, DLN2_GPIO_MAX_PINS);
+ struct dln2_irq_work *irq_work;
+};
+
+struct dln2_gpio_pin {
+ __le16 pin;
+};
+
+struct dln2_gpio_pin_val {
+ __le16 pin __packed;
+ u8 value;
+};
+
+static int dln2_gpio_get_pin_count(struct platform_device *pdev)
+{
+ int ret;
+ __le16 count;
+ int len = sizeof(count);
+
+ ret = dln2_transfer_rx(pdev, DLN2_GPIO_GET_PIN_COUNT, &count, &len);
+ if (ret < 0)
+ return ret;
+ if (len < sizeof(count))
+ return -EPROTO;
+
+ return le16_to_cpu(count);
+}
+
+static in
[PATCH v11 2/3] i2c: add support for Diolan DLN-2 USB-I2C adapter
From: Laurentiu Palcu
This patch adds support for the Diolan DLN-2 I2C master module. Due
to hardware limitations it does not support SMBUS quick commands.
Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 6.2.2 for the I2C
master module commands and responses.
[1] https://www.diolan.com/downloads/dln-api-manual.pdf
Signed-off-by: Laurentiu Palcu
Signed-off-by: Octavian Purdila
Acked-by: Wolfram Sang
Reviewed-by: Johan Hovold
---
drivers/i2c/busses/Kconfig| 10 ++
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-dln2.c | 267 ++
3 files changed, 278 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-dln2.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 917c358..059e846 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -881,6 +881,16 @@ config I2C_DIOLAN_U2C
This driver can also be built as a module. If so, the module
will be called i2c-diolan-u2c.
+config I2C_DLN2
+ tristate "Diolan DLN-2 USB I2C adapter"
+ depends on MFD_DLN2
+ help
+ If you say yes to this option, support will be included for Diolan
+ DLN2, a USB to I2C interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-dln2.
+
config I2C_PARPORT
tristate "Parallel port adapter"
depends on PARPORT
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 78d56c5..cdac7f1 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_I2C_RCAR)+= i2c-rcar.o
# External I2C/SMBus adapter drivers
obj-$(CONFIG_I2C_DIOLAN_U2C) += i2c-diolan-u2c.o
+obj-$(CONFIG_I2C_DLN2) += i2c-dln2.o
obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o
obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
obj-$(CONFIG_I2C_ROBOTFUZZ_OSIF) += i2c-robotfuzz-osif.o
diff --git a/drivers/i2c/busses/i2c-dln2.c b/drivers/i2c/busses/i2c-dln2.c
new file mode 100644
index 000..010a5fa
--- /dev/null
+++ b/drivers/i2c/busses/i2c-dln2.c
@@ -0,0 +1,267 @@
+/*
+ * Driver for the Diolan DLN-2 USB-I2C adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Derived from:
+ * i2c-diolan-u2c.c
+ * Copyright (c) 2010-2011 Ericsson AB
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DLN2_I2C_MODULE_ID 0x03
+#define DLN2_I2C_CMD(cmd) DLN2_CMD(cmd, DLN2_I2C_MODULE_ID)
+
+/* I2C commands */
+#define DLN2_I2C_GET_PORT_COUNTDLN2_I2C_CMD(0x00)
+#define DLN2_I2C_ENABLEDLN2_I2C_CMD(0x01)
+#define DLN2_I2C_DISABLE DLN2_I2C_CMD(0x02)
+#define DLN2_I2C_IS_ENABLEDDLN2_I2C_CMD(0x03)
+#define DLN2_I2C_WRITE DLN2_I2C_CMD(0x06)
+#define DLN2_I2C_READ DLN2_I2C_CMD(0x07)
+#define DLN2_I2C_SCAN_DEVICES DLN2_I2C_CMD(0x08)
+#define DLN2_I2C_PULLUP_ENABLE DLN2_I2C_CMD(0x09)
+#define DLN2_I2C_PULLUP_DISABLEDLN2_I2C_CMD(0x0A)
+#define DLN2_I2C_PULLUP_IS_ENABLED DLN2_I2C_CMD(0x0B)
+#define DLN2_I2C_TRANSFER DLN2_I2C_CMD(0x0C)
+#define DLN2_I2C_SET_MAX_REPLY_COUNT DLN2_I2C_CMD(0x0D)
+#define DLN2_I2C_GET_MAX_REPLY_COUNT DLN2_I2C_CMD(0x0E)
+
+#define DLN2_I2C_MAX_XFER_SIZE 256
+#define DLN2_I2C_BUF_SIZE (DLN2_I2C_MAX_XFER_SIZE + 16)
+
+struct dln2_i2c {
+ struct platform_device *pdev;
+ struct i2c_adapter adapter;
+ u8 port;
+ /*
+* Buffer to hold the packet for read or write transfers. One is enough
+* since we can't have multiple transfers in parallel on the i2c bus.
+*/
+ void *buf;
+};
+
+static int dln2_i2c_enable(struct dln2_i2c *dln2, bool enable)
+{
+ int ret;
+ u16 cmd;
+ struct {
+ u8 port;
+ } tx;
+
+ tx.port = dln2->port;
+
+ if (enable)
+ cmd = DLN2_I2C_ENABLE;
+ else
+ cmd = DLN2_I2C_DISABLE;
+
+ ret = dln2_transfer_tx(dln2->pdev, cmd, &tx, sizeof(tx));
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int dln2_i2c_write(struct dln2_i2c *dln2, u8 addr,
+ u8 *data, u16 data_len)
+{
+ int ret;
+ struct {
+ u8 port;
+ u8 addr;
+ u8 mem_addr_len;
+ __le32 mem_addr;
+ __le16 buf_len;
+ u8 buf[DLN2_I2C_MAX_XFER_SIZE];
+ } __packed *tx = dln2->buf;
+ unsigned len;
+
+ BUILD_BUG_ON(sizeof(*tx) > DLN2_I2C_BUF_SIZE);
+
+ tx->port = dln2->port;
[PATCH v11 1/3] mfd: add support for Diolan DLN-2 devices
This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
Master Adapter DLN-2. Details about the device can be found here:
https://www.diolan.com/i2c/i2c_interface.html.
Information about the USB protocol can be found in the Programmer's
Reference Manual [1], see section 1.7.
Because the hardware has a single transmit endpoint and a single
receive endpoint the communication between the various DLN2 drivers
and the hardware will be muxed/demuxed by this driver.
Each DLN2 module will be identified by the handle field within the DLN2
message header. If a DLN2 module issues multiple commands in parallel
they will be identified by the echo counter field in the message header.
The DLN2 modules can use the dln2_transfer() function to issue a
command and wait for its response. They can also register a callback
that is going to be called when a specific event id is generated by
the device (e.g. GPIO interrupts). The device uses handle 0 for
sending events.
[1] https://www.diolan.com/downloads/dln-api-manual.pdf
Signed-off-by: Octavian Purdila
Reviewed-by: Johan Hovold
---
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile | 1 +
drivers/mfd/dln2.c | 763 +++
include/linux/mfd/dln2.h | 103 +++
4 files changed, 878 insertions(+)
create mode 100644 drivers/mfd/dln2.c
create mode 100644 include/linux/mfd/dln2.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index cbdb109..32d7cab 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -189,6 +189,17 @@ config MFD_DA9063
Additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_DLN2
+ tristate "Diolan DLN2 support"
+ select MFD_CORE
+ depends on USB
+ help
+
+ This adds support for Diolan USB-I2C/SPI/GPIO Master Adapter
+ DLN-2. Additional drivers such as I2C_DLN2, GPIO_DLN2,
+ etc. must be enabled in order to use the functionality of
+ the device.
+
config MFD_MC13XXX
tristate
depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8e679d6..53467e2 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_MFD_STW481X) += stw481x.o
obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
obj-$(CONFIG_MFD_HI6421_PMIC) += hi6421-pmic-core.o
+obj-$(CONFIG_MFD_DLN2) += dln2.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
new file mode 100644
index 000..9765a17
--- /dev/null
+++ b/drivers/mfd/dln2.c
@@ -0,0 +1,763 @@
+/*
+ * Driver for the Diolan DLN-2 USB adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Derived from:
+ * i2c-diolan-u2c.c
+ * Copyright (c) 2010-2011 Ericsson AB
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct dln2_header {
+ __le16 size;
+ __le16 id;
+ __le16 echo;
+ __le16 handle;
+};
+
+struct dln2_response {
+ struct dln2_header hdr;
+ __le16 result;
+};
+
+#define DLN2_GENERIC_MODULE_ID 0x00
+#define DLN2_GENERIC_CMD(cmd) DLN2_CMD(cmd, DLN2_GENERIC_MODULE_ID)
+#define CMD_GET_DEVICE_VER DLN2_GENERIC_CMD(0x30)
+#define CMD_GET_DEVICE_SN DLN2_GENERIC_CMD(0x31)
+
+#define DLN2_HW_ID 0x200
+#define DLN2_USB_TIMEOUT 200 /* in ms */
+#define DLN2_MAX_RX_SLOTS 16
+#define DLN2_MAX_URBS 16
+#define DLN2_RX_BUF_SIZE 512
+
+enum dln2_handle {
+ DLN2_HANDLE_EVENT = 0, /* don't change, hardware defined */
+ DLN2_HANDLE_CTRL,
+ DLN2_HANDLE_GPIO,
+ DLN2_HANDLE_I2C,
+ DLN2_HANDLES
+};
+
+/*
+ * Receive context used between the receive demultiplexer and the transfer
+ * routine. While sending a request the transfer routine will look for a free
+ * receive context and use it to wait for a response and to receive the URB and
+ * thus the response data.
+ */
+struct dln2_rx_context {
+ /* completion used to wait for a response */
+ struct completion done;
+
+ /* if non-NULL the URB contains the response */
+ struct urb *urb;
+
+ /* if true then this context is used to wait for a response */
+ bool in_use;
+};
+
+/*
+ * Receive contexts for a particular DLN2 module (i2c, gpio, etc.). We use the
+ * handle header field to identify the module in dln2_dev.mod_rx_slots and then
+ * the echo header field to index the slots field and find the receive context
+ * for
[PATCH v11 0/3] add support for Diolan DLN-2
This patch series adds support for Diolan USB-I2C/GPIO Master Adapter DLN-2. Details about device can be found here: https://www.diolan.com/i2c/i2c_interface.html. This patch series has been rebased against the for-mfd-next branch of the MFD tree. Changes since v10: * MFD: fix a couple of typos Changes since v9: * MFD: use decimal serial no, break the run callback loop (there can be only one entry per id), move up the declaration of a couple of variables, remove a couple of redundant __packed attributes, fix a typo and cleanup an error message, use unsigned long instead of int for timeout * I2C: none * GPIO: drop a couple of cpu_to_le16() due to receiving data type being u8 Daniel Baluta (1): gpio: add support for the Diolan DLN-2 USB GPIO driver Laurentiu Palcu (1): i2c: add support for Diolan DLN-2 USB-I2C adapter Octavian Purdila (1): mfd: add support for Diolan DLN-2 devices drivers/gpio/Kconfig | 12 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-dln2.c | 553 ++ drivers/i2c/busses/Kconfig| 10 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-dln2.c | 267 +++ drivers/mfd/Kconfig | 11 + drivers/mfd/Makefile | 1 + drivers/mfd/dln2.c| 763 ++ include/linux/mfd/dln2.h | 103 ++ 10 files changed, 1722 insertions(+) create mode 100644 drivers/gpio/gpio-dln2.c create mode 100644 drivers/i2c/busses/i2c-dln2.c create mode 100644 drivers/mfd/dln2.c create mode 100644 include/linux/mfd/dln2.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/3] mfd: add support for Diolan DLN-2 devices
On Thu, Nov 06, 2014 at 01:45:46PM +0200, Octavian Purdila wrote: > On Wed, Nov 5, 2014 at 7:11 PM, Johan Hovold wrote: > > On Wed, Nov 05, 2014 at 07:04:59PM +0200, Octavian Purdila wrote: > >> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO > >> Master Adapter DLN-2. Details about the device can be found here: > >> > >> https://www.diolan.com/i2c/i2c_interface.html. > >> > >> Information about the USB protocol can be found in the Programmer's > >> Reference Manual [1], see section 1.7. > >> > >> Because the hardware has a single transmit endpoint and a single > >> receive endpoint the communication between the various DLN2 drivers > >> and the hardware will be muxed/demuxed by this driver. > >> > >> Each DLN2 module will be identified by the handle field within the DLN2 > >> message header. If a DLN2 module issues multiple commands in parallel > >> they will be identified by the echo counter field in the message header. > >> > >> The DLN2 modules can use the dln2_transfer() function to issue a > >> command and wait for its response. They can also register a callback > >> that is going to be called when a specific event id is generated by > >> the device (e.g. GPIO interrupts). The device uses handle 0 for > >> sending events. > >> > >> [1] https://www.diolan.com/downloads/dln-api-manual.pdf > >> > >> Signed-off-by: Octavian Purdila > > > > Reviewed-by: Johan Hovold > > > > Just noticed checkpatch complains about two typos in the header file > > (since v9?). ;) > > > > Ah nice new checkpatch feature, I used checkpath before rebasing the > tree and missed those. I will fix the typos and submit v11 with your > review-by tags. Thanks a lot for your awesome reviews Johan ! You're welcome. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] ARM: shmobile: sh73a0 dtsi: Add SoC-specific IIC compatible properties
The IIC nodes used the generic compatible properties only.
This causes the driver to fail when using Standard Speed, as the
operational clock is driven by the 104 MHz HP clock:
i2c-sh_mobile e682.i2c: timing values out of range: L/H=0x208/0x1bf
i2c-sh_mobile: probe of e682.i2c failed with error -22
Add the SoC-specific compatible property to fix this.
Signed-off-by: Geert Uytterhoeven
---
arch/arm/boot/dts/sh73a0.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 030a5920312fa19b..d8def5a529da2882 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -138,7 +138,7 @@
i2c0: i2c@e682 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
reg = <0xe682 0x425>;
interrupts = <0 167 IRQ_TYPE_LEVEL_HIGH
0 168 IRQ_TYPE_LEVEL_HIGH
@@ -150,7 +150,7 @@
i2c1: i2c@e6822000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
reg = <0xe6822000 0x425>;
interrupts = <0 51 IRQ_TYPE_LEVEL_HIGH
0 52 IRQ_TYPE_LEVEL_HIGH
@@ -162,7 +162,7 @@
i2c2: i2c@e6824000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
reg = <0xe6824000 0x425>;
interrupts = <0 171 IRQ_TYPE_LEVEL_HIGH
0 172 IRQ_TYPE_LEVEL_HIGH
@@ -174,7 +174,7 @@
i2c3: i2c@e6826000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
reg = <0xe6826000 0x425>;
interrupts = <0 183 IRQ_TYPE_LEVEL_HIGH
0 184 IRQ_TYPE_LEVEL_HIGH
@@ -186,7 +186,7 @@
i2c4: i2c@e6828000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
reg = <0xe6828000 0x425>;
interrupts = <0 187 IRQ_TYPE_LEVEL_HIGH
0 188 IRQ_TYPE_LEVEL_HIGH
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] i2c: sh_mobile: Add support for r8a73a4 and sh73a0
Add support for r8a73a4 (R-Mobile APE6) and sh73a0 (SH-Mobile AG5).
On these SoCs, the operating clock runs faster that on previous SoCs,
and the internal SCL clock counter gets incremented every 2 clocks of
the operating clock, just like on R-Car Gen2.
Cfr. the "/2" in the calculation of ICCL/ICCH in section "I2C Bus
Interface (IIC)", subsection "Transfer Rate" of the datasheets.
Signed-off-by: Geert Uytterhoeven
---
drivers/i2c/busses/i2c-sh_mobile.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c
b/drivers/i2c/busses/i2c-sh_mobile.c
index 8b5e79cb4468a87f..8ac36e4ff40a09bb 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -626,17 +626,19 @@ static const struct sh_mobile_dt_config default_dt_config
= {
.clks_per_count = 1,
};
-static const struct sh_mobile_dt_config rcar_gen2_dt_config = {
+static const struct sh_mobile_dt_config fast_clock_dt_config = {
.clks_per_count = 2,
};
static const struct of_device_id sh_mobile_i2c_dt_ids[] = {
{ .compatible = "renesas,rmobile-iic", .data = &default_dt_config },
- { .compatible = "renesas,iic-r8a7790", .data = &rcar_gen2_dt_config },
- { .compatible = "renesas,iic-r8a7791", .data = &rcar_gen2_dt_config },
- { .compatible = "renesas,iic-r8a7792", .data = &rcar_gen2_dt_config },
- { .compatible = "renesas,iic-r8a7793", .data = &rcar_gen2_dt_config },
- { .compatible = "renesas,iic-r8a7794", .data = &rcar_gen2_dt_config },
+ { .compatible = "renesas,iic-r8a73a4", .data = &fast_clock_dt_config },
+ { .compatible = "renesas,iic-r8a7790", .data = &fast_clock_dt_config },
+ { .compatible = "renesas,iic-r8a7791", .data = &fast_clock_dt_config },
+ { .compatible = "renesas,iic-r8a7792", .data = &fast_clock_dt_config },
+ { .compatible = "renesas,iic-r8a7793", .data = &fast_clock_dt_config },
+ { .compatible = "renesas,iic-r8a7794", .data = &fast_clock_dt_config },
+ { .compatible = "renesas,iic-sh73a0", .data = &fast_clock_dt_config },
{},
};
MODULE_DEVICE_TABLE(of, sh_mobile_i2c_dt_ids);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] i2c: sh_mobile: Document SoC-specific bindings
Explicitly list the various SoC-specific compatible properties. This allows checkpatch to validate DTSes. Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt index d2153ce36fa81404..c33e9a32d496ef10 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt @@ -2,6 +2,15 @@ Device tree configuration for Renesas IIC (sh_mobile) driver Required properties: - compatible : "renesas,iic-". "renesas,rmobile-iic" as fallback +Examples with soctypes are: + - "renesas,iic-r8a73a4" (R-Mobile APE6) + - "renesas,iic-r8a7740" (R-Mobile A1) + - "renesas,iic-r8a7790" (R-Car H2) + - "renesas,iic-r8a7791" (R-Car M2-W) + - "renesas,iic-r8a7792" (R-Car V2H) + - "renesas,iic-r8a7793" (R-Car M2-N) + - "renesas,iic-r8a7794" (R-Car E2) + - "renesas,iic-sh73a0" (SH-Mobile AG5) - reg : address start and address range size of device - interrupts : interrupt of device - clocks : clock for device -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] ARM: shmobile: r8a73a4 dtsi: Add SoC-specific IIC compatible properties
The IIC nodes used the generic compatible properties only.
This may cause the driver to fail when using Standard Speed on IIC
masters where the operational clock is driven by the 130 MHz HP clock.
Add the SoC-specific compatible property to fix this.
Signed-off-by: Geert Uytterhoeven
---
Untested due to lack of hardware
arch/arm/boot/dts/r8a73a4.dtsi | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 7f57dc7f392aad30..5ac57babc3b95c99 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -106,7 +106,7 @@
i2c5: i2c@e60b {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
reg = <0 0xe60b 0 0x428>;
interrupts = <0 179 IRQ_TYPE_LEVEL_HIGH>;
@@ -205,7 +205,7 @@
i2c0: i2c@e650 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
reg = <0 0xe650 0 0x428>;
interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
@@ -214,7 +214,7 @@
i2c1: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
reg = <0 0xe651 0 0x428>;
interrupts = <0 175 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
@@ -223,7 +223,7 @@
i2c2: i2c@e652 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
reg = <0 0xe652 0 0x428>;
interrupts = <0 176 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
@@ -232,7 +232,7 @@
i2c3: i2c@e653 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
reg = <0 0xe653 0 0x428>;
interrupts = <0 177 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
@@ -241,7 +241,7 @@
i2c4: i2c@e654 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
reg = <0 0xe654 0 0x428>;
interrupts = <0 178 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
@@ -250,7 +250,7 @@
i2c6: i2c@e655 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
reg = <0 0xe655 0 0x428>;
interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
@@ -259,7 +259,7 @@
i2c7: i2c@e656 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
reg = <0 0xe656 0 0x428>;
interrupts = <0 185 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
@@ -268,7 +268,7 @@
i2c8: i2c@e657 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
reg = <0 0xe657 0 0x428>;
interrupts = <0 173 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] ARM: shmobile: sh73a0/r8a73a4: i2c-sh_mobile fixes
Hi Wolfram, Simon, Magnus,
This patch series revives i2c on sh73a0/kzm9g (both legacy and reference), and
on r8a73a4/ape6evm (reference).
On these SoCs, the operating clock runs faster that on previous SoCs,
and the internal SCL clock counter gets incremented every 2 clocks of
the operating clock, just like on R-Car Gen2. But if this knowledge is not
available to the driver, probing fails with e.g.
i2c-sh_mobile i2c-sh_mobile.0: timing values out of range: L/H=0x208/0x1bf
sh_mobile: probe of i2c-sh_mobile.0 failed with error -22
The series also updates the binding documentation to list the various
SoC-specific compatible properties, to allow checkpatch to validate DTSes.
This was tested on sh73a0/kzm9g (both legacy and reference).
This was not tested on r8a73a4/ape6evm due to lack of hardware.
Geert Uytterhoeven (5):
ARM: shmobile: kzm9g legacy: Set i2c clks_per_count to 2
i2c: sh_mobile: Add support for r8a73a4 and sh73a0
i2c: sh_mobile: Document SoC-specific bindings
ARM: shmobile: sh73a0 dtsi: Add SoC-specific IIC compatible properties
ARM: shmobile: r8a73a4 dtsi: Add SoC-specific IIC compatible
properties
.../devicetree/bindings/i2c/i2c-sh_mobile.txt| 9 +
arch/arm/boot/dts/r8a73a4.dtsi | 18 +-
arch/arm/boot/dts/sh73a0.dtsi| 10 +-
arch/arm/mach-shmobile/setup-sh73a0.c| 20
drivers/i2c/busses/i2c-sh_mobile.c | 14 --
5 files changed, 51 insertions(+), 20 deletions(-)
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] ARM: shmobile: kzm9g legacy: Set i2c clks_per_count to 2
On sh73a0/kzm9g-legacy, probing of the i2c masters fails with:
i2c-sh_mobile i2c-sh_mobile.0: timing values out of range: L/H=0x208/0x1bf
sh_mobile: probe of i2c-sh_mobile.0 failed with error -22
According to the datasheet, the transfer rate is derived from the HP
clock (which runs at 104 MHz) divided by two. Hence
i2c_sh_mobile_platform_data.clks_per_count should be set to two.
Now probing succeeds, and i2c works:
i2c-sh_mobile i2c-sh_mobile.0: I2C adapter 0 with bus speed 10 Hz
(L/H=0x104/0xe0)
Signed-off-by: Geert Uytterhoeven
---
Note that the L/H values still differ from the Transfer Rate Settings
example in Table 19.3 of the datasheet, which suggests 0x121/0xe7.
arch/arm/mach-shmobile/setup-sh73a0.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c
b/arch/arm/mach-shmobile/setup-sh73a0.c
index 2955a08a655d8889..179c2b65be9f6829 100644
--- a/arch/arm/mach-shmobile/setup-sh73a0.c
+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -188,11 +189,18 @@ static struct resource i2c4_resources[] = {
},
};
+static struct i2c_sh_mobile_platform_data i2c_platform_data = {
+ .clks_per_count = 2,
+};
+
static struct platform_device i2c0_device = {
.name = "i2c-sh_mobile",
.id = 0,
.resource = i2c0_resources,
.num_resources = ARRAY_SIZE(i2c0_resources),
+ .dev= {
+ .platform_data = &i2c_platform_data,
+ },
};
static struct platform_device i2c1_device = {
@@ -200,6 +208,9 @@ static struct platform_device i2c1_device = {
.id = 1,
.resource = i2c1_resources,
.num_resources = ARRAY_SIZE(i2c1_resources),
+ .dev= {
+ .platform_data = &i2c_platform_data,
+ },
};
static struct platform_device i2c2_device = {
@@ -207,6 +218,9 @@ static struct platform_device i2c2_device = {
.id = 2,
.resource = i2c2_resources,
.num_resources = ARRAY_SIZE(i2c2_resources),
+ .dev= {
+ .platform_data = &i2c_platform_data,
+ },
};
static struct platform_device i2c3_device = {
@@ -214,6 +228,9 @@ static struct platform_device i2c3_device = {
.id = 3,
.resource = i2c3_resources,
.num_resources = ARRAY_SIZE(i2c3_resources),
+ .dev= {
+ .platform_data = &i2c_platform_data,
+ },
};
static struct platform_device i2c4_device = {
@@ -221,6 +238,9 @@ static struct platform_device i2c4_device = {
.id = 4,
.resource = i2c4_resources,
.num_resources = ARRAY_SIZE(i2c4_resources),
+ .dev= {
+ .platform_data = &i2c_platform_data,
+ },
};
static const struct sh_dmae_slave_config sh73a0_dmae_slaves[] = {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/3] mfd: add support for Diolan DLN-2 devices
On Wed, Nov 5, 2014 at 7:11 PM, Johan Hovold wrote: > On Wed, Nov 05, 2014 at 07:04:59PM +0200, Octavian Purdila wrote: >> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO >> Master Adapter DLN-2. Details about the device can be found here: >> >> https://www.diolan.com/i2c/i2c_interface.html. >> >> Information about the USB protocol can be found in the Programmer's >> Reference Manual [1], see section 1.7. >> >> Because the hardware has a single transmit endpoint and a single >> receive endpoint the communication between the various DLN2 drivers >> and the hardware will be muxed/demuxed by this driver. >> >> Each DLN2 module will be identified by the handle field within the DLN2 >> message header. If a DLN2 module issues multiple commands in parallel >> they will be identified by the echo counter field in the message header. >> >> The DLN2 modules can use the dln2_transfer() function to issue a >> command and wait for its response. They can also register a callback >> that is going to be called when a specific event id is generated by >> the device (e.g. GPIO interrupts). The device uses handle 0 for >> sending events. >> >> [1] https://www.diolan.com/downloads/dln-api-manual.pdf >> >> Signed-off-by: Octavian Purdila > > Reviewed-by: Johan Hovold > > Just noticed checkpatch complains about two typos in the header file > (since v9?). ;) > Ah nice new checkpatch feature, I used checkpath before rebasing the tree and missed those. I will fix the typos and submit v11 with your review-by tags. Thanks a lot for your awesome reviews Johan ! -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: rk3x: fix bug that cause measured high_ns doesn't meet I2C spec
high_ns calculated from the low division of CLKDIV register is the sum of
actual measured high_ns and rise_ns. The rise time which related to
external pull-up resistor can be up to the maximum rise time in I2C spec.
In my test, if external pull-up resistor is 4.7K, rise_ns is about 700ns.
So the actual measured high_ns is about 3900ns, which is less than 4000ns
(the minimum high_ns in I2C spec).
Signed-off-by: Addy Ke
---
drivers/i2c/busses/i2c-rk3x.c | 58 +++
1 file changed, 37 insertions(+), 21 deletions(-)
diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index e276ffb..8e1cc2b 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -432,9 +432,12 @@ out:
static int rk3x_i2c_calc_divs(unsigned long i2c_rate, unsigned long scl_rate,
unsigned long *div_low, unsigned long *div_high)
{
+ unsigned long spec_min_low_ns, spec_min_high_ns;
+ unsigned long spec_max_data_hold_ns;
+ unsigned long spec_data_hold_buffer_ns;
+ unsigned long spec_max_rise_ns;
+
unsigned long min_low_ns, min_high_ns;
- unsigned long max_data_hold_ns;
- unsigned long data_hold_buffer_ns;
unsigned long max_low_ns, min_total_ns;
unsigned long i2c_rate_khz, scl_rate_khz;
@@ -453,30 +456,43 @@ static int rk3x_i2c_calc_divs(unsigned long i2c_rate,
unsigned long scl_rate,
if (WARN_ON(scl_rate < 1000))
scl_rate = 1000;
+ if (scl_rate <= 10) {
+ spec_min_low_ns = 4700;
+ spec_min_high_ns = 4000;
+ spec_max_rise_ns = 1000;
+ spec_max_data_hold_ns = 3450;
+ spec_data_hold_buffer_ns = 50;
+ } else {
+ spec_min_low_ns = 1300;
+ spec_min_high_ns = 600;
+ spec_max_rise_ns = 300;
+ spec_max_data_hold_ns = 900;
+ spec_data_hold_buffer_ns = 50;
+ }
+
/*
-* min_low_ns: The minimum number of ns we need to hold low
-* to meet i2c spec
-* min_high_ns: The minimum number of ns we need to hold high
-* to meet i2c spec
-* max_low_ns: The maximum number of ns we can hold low
-* to meet i2c spec
+* min_low_ns: The minimum number of ns we need to hold low.
+* The fall time in RK3X's I2C controller is approximately
+* equal to 0. So min_low_ns = spec_min_low_ns.
+* Note: low_ns should be (measured_low_ns + measured_fall_time)
+* and measured_low_ns must meet I2C spec.
*
-* Note: max_low_ns should be (max data hold time * 2 - buffer)
+* min_high_ns: The minimum number of ns we need to hold high.
+* The rise time which related to external pull-up resistor
+* can be up to spec_max_rise_ns.
+* So min_high_ns = spec_min_high_ns + spec_max_rise_ns
+* Note: high_ns should be (measured_high_ns + measured_rise_time)
+* and measured_high_ns must meet I2C spec.
+*
+* max_low_ns: The maximum number of ns we can hold low.
+* Note: max_low_ns should be (max_data_hold_time * 2 - buffer)
* This is because the i2c host on Rockchip holds the data line
* for half the low time.
*/
- if (scl_rate <= 10) {
- min_low_ns = 4700;
- min_high_ns = 4000;
- max_data_hold_ns = 3450;
- data_hold_buffer_ns = 50;
- } else {
- min_low_ns = 1300;
- min_high_ns = 600;
- max_data_hold_ns = 900;
- data_hold_buffer_ns = 50;
- }
- max_low_ns = max_data_hold_ns * 2 - data_hold_buffer_ns;
+ min_low_ns = spec_min_low_ns;
+ min_high_ns = spec_min_high_ns + spec_max_rise_ns;
+ max_low_ns = spec_max_data_hold_ns * 2 - spec_data_hold_buffer_ns;
+
min_total_ns = min_low_ns + min_high_ns;
/* Adjust to avoid overflow */
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
