* Re: [PATCH v4 1/8] dt-bindings: mfd: Add retu/tahvo ASIC chips bindings
From: Lee Jones @ 2017-04-11 13:57 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Aaro Koskinen, devicetree, Rob Herring,
Tony Lindgren, Mark Rutland
In-Reply-To: <20170404153036.6651-2-javier@osg.samsung.com>
On Tue, 04 Apr 2017, Javier Martinez Canillas wrote:
> There are Device Tree source files defining a device node for the
> retu/tahvo I2C chip, but there isn't a DT binding document for it.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
>
> Changes in v4:
> - Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
> - Add information about what functions the device serve (Lee Jones).
> - Avoid using MFD in Device Tree (Lee Jones).
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/mfd/retu.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/Documentation/devicetree/bindings/mfd/retu.txt b/Documentation/devicetree/bindings/mfd/retu.txt
> new file mode 100644
> index 000000000000..7df21a2b28ea
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/retu.txt
> @@ -0,0 +1,21 @@
> +* Device tree bindings for Nokia Retu and Tahvo multi-function device
> +
> +Retu and Tahvo are a multi-function devices found on Nokia Internet
> +Tablets (770, N800 and N810). The Retu chip provides watchdog timer
> +and power button control functionalities while Tahvo chip provides
> +USB transceiver functionality.
> +
> +Required properties:
> +- compatible: "nokia,retu" or "nokia,tahvo"
> +- reg: Specifies the I2C slave address of the ASIC chip
> +
> +Example:
> +
> +i2c0 {
> + retu: retu@1 {
> + compatible = "nokia,retu";
> + interrupt-parent = <&gpio4>;
> + interrupts = <12 IRQ_TYPE_EDGE_RISING>;
> + reg = <0x1>;
> + };
> +};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v4 7/8] mfd: tps6105x: Add OF device ID table
From: Lee Jones @ 2017-04-11 13:57 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Aaro Koskinen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Tony Lindgren
In-Reply-To: <20170404153036.6651-8-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Tue, 04 Apr 2017, Javier Martinez Canillas wrote:
> The driver doesn't have a struct of_device_id table but supported devices
> are registered via Device Trees. This is working on the assumption that a
> I2C device registered via OF will always match a legacy I2C device ID and
> that the MODALIAS reported will always be of the form i2c:<device>.
>
> But this could change in the future so the correct approach is to have a
> OF device ID table if the devices are registered via OF.
>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>
> ---
>
> Changes in v4: None
> Changes in v3:
> - Add a vendor prefix to the compatible string (Rob Herring).
>
> Changes in v2:
> - Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
>
> drivers/mfd/tps6105x.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> diff --git a/drivers/mfd/tps6105x.c b/drivers/mfd/tps6105x.c
> index baa12ea666fb..187848c93779 100644
> --- a/drivers/mfd/tps6105x.c
> +++ b/drivers/mfd/tps6105x.c
> @@ -173,9 +173,17 @@ static const struct i2c_device_id tps6105x_id[] = {
> };
> MODULE_DEVICE_TABLE(i2c, tps6105x_id);
>
> +static const struct of_device_id tps6105x_of_match[] = {
> + { .compatible = "ti,tps61050" },
> + { .compatible = "ti,tps61052" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, tps6105x_of_match);
> +
> static struct i2c_driver tps6105x_driver = {
> .driver = {
> .name = "tps6105x",
> + .of_match_table = tps6105x_of_match,
> },
> .probe = tps6105x_probe,
> .remove = tps6105x_remove,
--
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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 3/8] mfd: retu: Add OF device ID table
From: Lee Jones @ 2017-04-11 13:56 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Aaro Koskinen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Tony Lindgren
In-Reply-To: <20170404153036.6651-4-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Tue, 04 Apr 2017, Javier Martinez Canillas wrote:
> The driver doesn't have a struct of_device_id table but supported devices
> are registered via Device Trees. This is working on the assumption that a
> I2C device registered via OF will always match a legacy I2C device ID and
> that the MODALIAS reported will always be of the form i2c:<device>.
>
> But this could change in the future so the correct approach is to have a
> OF device ID table if the devices are registered via OF.
>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>
> ---
>
> Changes in v4:
> - Drop -mfd suffix in compatible string (Lee Jones).
>
> Changes in v3:
> - Add a vendor prefix to the compatible string (Rob Herring).
>
> Changes in v2:
> - Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
>
> drivers/mfd/retu-mfd.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
> index 53e1d386d2c0..e7d27b7861c1 100644
> --- a/drivers/mfd/retu-mfd.c
> +++ b/drivers/mfd/retu-mfd.c
> @@ -308,9 +308,17 @@ static const struct i2c_device_id retu_id[] = {
> };
> MODULE_DEVICE_TABLE(i2c, retu_id);
>
> +static const struct of_device_id retu_of_match[] = {
> + { .compatible = "nokia,retu" },
> + { .compatible = "nokia,tahvo" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, retu_of_match);
> +
> static struct i2c_driver retu_driver = {
> .driver = {
> .name = "retu-mfd",
> + .of_match_table = retu_of_match,
> },
> .probe = retu_probe,
> .remove = retu_remove,
--
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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/8] mfd: retu: Drop -mfd suffix from I2C device ID name
From: Lee Jones @ 2017-04-11 13:56 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Aaro Koskinen, devicetree, Rob Herring,
Tony Lindgren, Benoît Cousson, Mark Rutland, linux-omap,
Russell King, linux-arm-kernel
In-Reply-To: <20170404153036.6651-3-javier@osg.samsung.com>
On Tue, 04 Apr 2017, Javier Martinez Canillas wrote:
> It's not correct to encode the subsystem in the I2C device name, so
> drop the -mfd suffix. To maintain bisect-ability, change driver and
> platform code / DTS users in the same patch.
>
> Suggested-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 4 ++--
> arch/arm/mach-omap1/board-nokia770.c | 4 ++--
> drivers/mfd/retu-mfd.c | 4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
> index 7e5ffc583c90..1b06430c8013 100644
> --- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
> +++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
> @@ -15,8 +15,8 @@
> >;
> #address-cells = <1>;
> #size-cells = <0>;
> - retu_mfd: retu@1 {
> - compatible = "retu-mfd";
> + retu: retu@1 {
> + compatible = "retu";
> interrupt-parent = <&gpio4>;
> interrupts = <12 IRQ_TYPE_EDGE_RISING>;
> reg = <0x1>;
> diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c
> index ee8d9f553db4..06243c0b12d2 100644
> --- a/arch/arm/mach-omap1/board-nokia770.c
> +++ b/arch/arm/mach-omap1/board-nokia770.c
> @@ -233,10 +233,10 @@ static struct platform_device nokia770_cbus_device = {
>
> static struct i2c_board_info nokia770_i2c_board_info_2[] __initdata = {
> {
> - I2C_BOARD_INFO("retu-mfd", 0x01),
> + I2C_BOARD_INFO("retu", 0x01),
> },
> {
> - I2C_BOARD_INFO("tahvo-mfd", 0x02),
> + I2C_BOARD_INFO("tahvo", 0x02),
> },
> };
>
> diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
> index d4c114abeb75..53e1d386d2c0 100644
> --- a/drivers/mfd/retu-mfd.c
> +++ b/drivers/mfd/retu-mfd.c
> @@ -302,8 +302,8 @@ static int retu_remove(struct i2c_client *i2c)
> }
>
> static const struct i2c_device_id retu_id[] = {
> - { "retu-mfd", 0 },
> - { "tahvo-mfd", 0 },
> + { "retu", 0 },
> + { "tahvo", 0 },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, retu_id);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 2/2] devicetree: Document the max31760 device binding.
From: John Muir @ 2017-04-11 13:47 UTC (permalink / raw)
To: Rob Herring
Cc: Jean Delvare, Guenter Roeck, Jonathan Corbet, Pawel Moll,
Ian Campbell, Kumar Gala, devicetree, linux-hwmon, linux-doc,
Anatol Pomazau, Mark Segal
In-Reply-To: <20170410154249.r77b6vf3ctzn4kua@rob-hp-laptop>
> On Apr 10, 2017, at 8:42 AM, Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Apr 04, 2017 at 12:20:34PM -0700, John Muir wrote:
>> +MAX31760 fan controller
>> +-----------------------
>> +
>> +This device supports I2C only. Many properties of this device are configurable
>> +thorugh the hwmon interface. See also Documentation/hwmon/max31760.
>
> I really think we need to describe the fans as separate nodes and
> preferably with a common binding. This is the second fan controller
> binding recently[1].
>
> Features of the "hwmon interface" are not relevant to the binding.
> Bindings describe h/w.
It seems to me that referring to the hwmon interface is only helpful. You are suggesting removing those sentences? If so, can I add a link to the data sheet?
>
>> +Optional node properties:
>> +- maxim,fan1-enabled - 1 to enable, 0 to disable. Default: 1.
>> +- maxim,fan2-enabled - 1 to enable, 0 to disable. Default: 1.
>> +- maxim,fan1-label - String: Hwmon fan1_label.
>> +- maxim,fan2-label - String: Hwmon fan2_label.
>
> Perhaps 2 fan sub nodes. reg for fan number, status for enabled, and
> label for label.
OK.
Right now a fan’s number of pulses and the PWM frequency are configured using the hwmon sysfs interface (which defines standard controls for those), but as those are characteristics of the hardware, should they also be configured via the device tree binding?
>> +- maxim,pwm-zero-fan-can-fail - 0: Fan failure detection disabled when PWM is
>> + ramping to 0%.
>> + 1: Fan failure detection enabled for all PWM
>> + values.
>> + Default: 0.
>
> All these can be boolean…
OK. The only issue I see is when the default is ‘true’ in the device, but I’ll try to avoid that. Sometimes I wish that you could set a boolean to false in DTS files.
>
>> +- maxim,temp1-label - String: Hwmon temp1_label.
>> +- maxim,temp2-label - String: Hwmon temp2_label.
>> +- maxim,temp2-ideality - Set ideality factor for the remote temperature
>> + sensor. Integer with range 0 to 63,
>> + representing a multiplication factor of 0.9844
>> + to 1.0489. Default: 24 (1.0080).
>
> No maxim,temp1-ideality?
No - the device only lets you set the ideality of the ‘external' temperature sensor. I guess if there is an ideality for the internal temperature sensor, it would be hard-wired as a characteristic of the part that was used.
> Not sure what to do with these, but perhaps
> also as sub-nodes. Surely we have some bindings already for devices with
> multiple temp sensors. Don't invent something custom here.
I’ll look into it.
What is the best way to distinguish between ‘fan’ and ‘temp’ sub-nodes? Do I require a ‘compatible’ string?
Thanks!
John.
^ permalink raw reply
* Re: [PATCH v1 3/3] nvmem: dt: document SNVS LPGPR binding
From: Rob Herring @ 2017-04-11 13:35 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Oleksij Rempel, Srinivas Kandagatla, Maxime Ripard, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1e0f8a71-9dca-7aaa-a603-86ed3934da4d-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Mon, Apr 10, 2017 at 11:36 PM, Oleksij Rempel <ore-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> Hi,
>
>
> On 04/10/2017 08:22 PM, Rob Herring wrote:
>>
>> On Thu, Apr 06, 2017 at 09:31:07AM +0200, Oleksij Rempel wrote:
>>>
>>> Documenation bindings for the Low Power General Purpose Registe
>>
>>
>> s/Registe/Register/
>>
>>> available on i.MX6 SoCs in the Secure Non-Volatile Storage.
>>>
>>> Signed-off-by: Oleksij Rempel <o.rempel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>> Cc: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> Cc: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> ---
>>> Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt | 15
>>> +++++++++++++++
>>> 1 file changed, 15 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
>>> b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
>>> new file mode 100644
>>> index 000000000000..9a8be1a2d12e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
>>> @@ -0,0 +1,15 @@
>>> +Device tree bindings for Low Power General Purpose Registe found in
>>> i.MX6Q/D
>>> +Secure Non-Volatile Storage.
>>> +
>>> +Required properties:
>>> +- compatible: should be one of
>>> + "fsl,imx6q-snvs-lpgpr" (i.MX6Q/D/DL/S).
>>> +- offset: Should contain the offset relative to syscon parrent node.
>>
>>
>> typo
>
>
> ok.
>
>> +- regmap: Should contain a phandle pointing to syscon.
>>>
>>> +
>>> +Example:
>>> + snvs_lpgpr: snvs-lpgpr {
>>> + compatible = "fsl,imx6q-snvs-lpgpr";
>>> + regmap = <&snvs>;
>>> + offset = <0x68>;
>>
>>
>> Why does this need to be in DT? Is something going to refer to this
>> node? If not, the &snvs node should be enough information for the OS.
>
>
> Jes, it is refereed by other driver.
What I mean is snvs-lpgpr referenced elsewhere in DT, not by some
driver? You are not using the nvmem binding here so it doesn't seem
like it is. If that's the case, then you don't need this node. The
only information here is the offset which can be part of a driver for
the parent node. To put it another way, we don't want to fill DT with
a node per register.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/1] ARM: dts: dra7x-evm: Enable dual-role mode for USB1
From: Roger Quadros @ 2017-04-11 13:16 UTC (permalink / raw)
To: tony-4v6yS6AI5VpBDgjK7y7TUQ
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Roger Quadros, Sekhar Nori
In-Reply-To: <1491916575-16023-1-git-send-email-rogerq-l0cyMroinI0@public.gmane.org>
USB1 port is micro-AB type and can function as peripheral
as well as host. Enable dual-role mode for USB1.
We don't want to use the OTG controller block on this
platform as it limits host mode to high-speed. Instead
we rely on extcon framework to give us ID events for
dual-role mode detection.
Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/dra7-evm.dts | 3 ++-
arch/arm/boot/dts/dra72-evm-common.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4bc4b57..c408aaa 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -527,7 +527,8 @@
};
&usb1 {
- dr_mode = "peripheral";
+ dr_mode = "otg";
+ extcon = <&extcon_usb1>;
};
&usb2 {
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index ad24544..8578054 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -392,7 +392,8 @@
};
&usb1 {
- dr_mode = "peripheral";
+ dr_mode = "otg";
+ extcon = <&extcon_usb1>;
};
&usb2 {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/1] ARM: dts: dra7x-evm: Enable dual-role mode for USB1
From: Roger Quadros @ 2017-04-11 13:16 UTC (permalink / raw)
To: tony-4v6yS6AI5VpBDgjK7y7TUQ
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Roger Quadros
Hi Tony,
Dual role support for DWC3 is now in usb/next. With this patch we can
utilize dual-role mode on dra7x boards. Please queue for -next. Thanks.
cheers,
-roger
Roger Quadros (1):
ARM: dts: dra7x-evm: Enable dual-role mode for USB1
arch/arm/boot/dts/dra7-evm.dts | 3 ++-
arch/arm/boot/dts/dra72-evm-common.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: media: Add MAX2175 binding description
From: Laurent Pinchart @ 2017-04-11 12:58 UTC (permalink / raw)
To: Ramesh Shanmugasundaram
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
crope-X3B1VOXEql0@public.gmane.org, Chris Paterson,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <HK2PR06MB0545F9FBB1B27E91D80F906EC3000-jAC1QCBx2F1Af0bSEaWBKm0DtJ1/0DrXvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Hi Ramesh,
On Tuesday 11 Apr 2017 12:19:54 Ramesh Shanmugasundaram wrote:
> > On Tuesday 11 Apr 2017 09:57:45 Ramesh Shanmugasundaram wrote:
> >>> On Tuesday 07 Feb 2017 15:02:32 Ramesh Shanmugasundaram wrote:
> >>>> Add device tree binding documentation for MAX2175 Rf to bits tuner
> >>>> device.
> >>>>
> >>>> Signed-off-by: Ramesh Shanmugasundaram
> >>>> <ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
> >>>> ---
> >>>> .../devicetree/bindings/media/i2c/max2175.txt | 61 +++++++++++++
> >>>> .../devicetree/bindings/property-units.txt | 1 +
> >>>> 2 files changed, 62 insertions(+)
> >>>> create mode 100644
> >>>>
> >>>> Documentation/devicetree/bindings/media/i2c/max2175.txt
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/media/i2c/max2175.txt
> >>>> b/Documentation/devicetree/bindings/media/i2c/max2175.txt new file
> >>>> mode 100644 index 0000000..f591ab4
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> >
> > [snip]
> >
> >>>> +- maxim,am-hiz : empty property indicates AM Hi-Z filter
> >>>> path is
> >>>> + selected for AM antenna input. By default this
> >>>> + filter path is not used.
> >>>
> >>> Isn't this something that should be selected at runtime through a
> >>> control ? Or does the hardware design dictate whether the filter has
> >>> to be used or must not be used ?
> >>
> >> This is dictated by the h/w design and not selectable at run-time.
> >> I will update these changes in the next patchset.
> >
> > In that case I'm fine with a property, but could we name it in such a way
> > that it describes the hardware instead of instructing the software on how
> > to configure the device ? For instance (and this is a made-up example as I
> > don't know exactly how this works), if the AM Hi-Z filter is required when
> > dealing with AM frequencies and forbidden when dealing with other
> > frequency bands, and *if* boards have to be designed specifically for one
> > frequency band (AM, FM, VHF, L, ...) without any way to accept different
> > bands, then you could instead use
> >
> > maxim,frequency-band = "AM";
> >
> > and enable the filter accordingly in the driver. This would be in my
> > opinion a better system hardware description.
>
> I am not sure. The AM antenna input path has a default filter and AM Hi-Z
> filter. H/W dictates the path to be used for AM input only and this is
> fixed. The device can be configured to use different bands at runtime & not
> AM only. I could edit the description as below:
>
> - maxim,am-hiz : empty property indicates AM Hi-Z filter path
> usage for AM antenna input as dictated by hardware design. By default this
> filter path is not used.
>
> Is it any better? Do you still think the property name should be changed
> please?
I still think this should be renamed, but possibly because I don't understand
all the details of this particular feature :-). The property, as named and
documented above, describes a software features. It requests the driver to
enable the AM Hi-Z filter. DT properties should instead describe the hardware.
You should use a property that describes the hardware design, and use that to
infer, in the driver, whether to enable or disable the filter.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/5] mtd: nand: add support for Micron on-die ECC
From: Boris Brezillon @ 2017-04-11 12:51 UTC (permalink / raw)
To: Bean Huo (beanhuo)
Cc: Thomas Petazzoni,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org, Campbell,
richard-/L3Ra7n9ekc@public.gmane.org, Mark Rutland,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Cyrille Pitchen,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <414dd35931814ce38381a251917ad79f-aBoyCxvc2dBaXkNJqdKpEhSpLNRU/VIH@public.gmane.org>
Hi Bean,
On Mon, 3 Apr 2017 11:31:05 +0000
"Bean Huo (beanhuo)" <beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org> wrote:
> Hi, Boris and Thomas
>
> >>
> >> Ok, but I recommend that 70s should be the first choice on this single
> >> solution, it doesn't need to read twice to detect its bitflips count.
> >
> >That's exactly why we need to differentiate the 2 chips.
>
> Sorry for later this response.
> Below is the pseudo codes about how to differentiate these 2 series parallel
> NAND with on-die ECC:
>
> if (NAND == SLC ) { // on-die ECC only exists in SLC
> //check device ID byte 4
> if ((ID.byte4 & 0x02) == 0x02) {// internal ECC level ==10b
So here the MT29F1G08ABADAWP datasheet says 0x2 <=> 4bit/512bytes ECC.
> if (ID.byte4 & 0x80) {//on-Die ECC enabled
Did you read my last reply?
Thomas discovered that ID[4].bit7 is actually reflecting the ECC engine
state (1 if the engine is enabled, 0 if it's disabled), not whether the
NAND supports on-die ECC or not, so no this test is not reliable.
> if (ONFI.byte112 == 4)
> 60s SLC NAND with on-die ECC
> else if (ONFI.byte112 == 8)
> 70s SLC NAND with on-die ECC
This is completely fucked up! Now the ONFI param page says the NAND
requires 8bits/512bytes, while the ID bytes advertised an on-die ECC
providing 4bits/512bytes correctability.
So either your algorithm is wrong, or the ID and ONFI param page are
contracting (not sure what solution I'd prefer...).
> else
> Doesn't support on-die ECC
Sorry to say that, but I find it worrisome that even someone from Micron
is not able to get it right.
I think we'll stick to the model name to detect whether on-die ECC is
supported.
Regards,
Boris
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 5/7] doc_rst: media: New SDR formats PC16, PC18 & PC20
From: Laurent Pinchart @ 2017-04-11 12:39 UTC (permalink / raw)
To: Ramesh Shanmugasundaram
Cc: robh+dt, mark.rutland, mchehab, hverkuil, sakari.ailus, crope,
chris.paterson2, geert+renesas, linux-media, devicetree,
linux-renesas-soc
In-Reply-To: <1486479757-32128-6-git-send-email-ramesh.shanmugasundaram@bp.renesas.com>
Hi Ramesh,
Thank you for the patch.
On Tuesday 07 Feb 2017 15:02:35 Ramesh Shanmugasundaram wrote:
> This patch adds documentation for the three new SDR formats
>
> V4L2_SDR_FMT_PCU16BE
> V4L2_SDR_FMT_PCU18BE
> V4L2_SDR_FMT_PCU20BE
>
> Signed-off-by: Ramesh Shanmugasundaram
> <ramesh.shanmugasundaram@bp.renesas.com> ---
> .../media/uapi/v4l/pixfmt-sdr-pcu16be.rst | 55 +++++++++++++++++++
> .../media/uapi/v4l/pixfmt-sdr-pcu18be.rst | 55 +++++++++++++++++++
> .../media/uapi/v4l/pixfmt-sdr-pcu20be.rst | 54 +++++++++++++++++++
> Documentation/media/uapi/v4l/sdr-formats.rst | 3 ++
> 4 files changed, 167 insertions(+)
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
>
> diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
> b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst new file mode 100644
> index 0000000..2de1b1a
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
> @@ -0,0 +1,55 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2-SDR-FMT-PCU16BE:
> +
> +******************************
> +V4L2_SDR_FMT_PCU16BE ('PC16')
> +******************************
> +
> +Planar complex unsigned 16-bit big endian IQ sample
> +
> +Description
> +===========
> +
> +This format contains a sequence of complex number samples. Each complex
> +number consist of two parts called In-phase and Quadrature (IQ). Both I
> +and Q are represented as a 16 bit unsigned big endian number stored in
> +32 bit space. The remaining unused bits within the 32 bit space will be
> +padded with 0. I value starts first and Q value starts at an offset
> +equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
> +the 16 bits, bit 15:2 (14 bit) is data and bit 1:0 (2 bit) can be any
> +value.
This sounds very strange to me. Are the two lower bits always random ? What is
that used for ?
> +**Byte Order.**
> +Each cell is one byte.
> +
> +.. flat-table::
> + :header-rows: 1
> + :stub-columns: 0
> +
> + * - Offset:
> + - Byte B0
> + - Byte B1
> + - Byte B2
> + - Byte B3
> + * - start + 0:
> + - I'\ :sub:`0[13:6]`
> + - I'\ :sub:`0[5:0]; B1[1:0]=pad`
> + - pad
> + - pad
> + * - start + 4:
> + - I'\ :sub:`1[13:6]`
> + - I'\ :sub:`1[5:0]; B1[1:0]=pad`
> + - pad
> + - pad
> + * - ...
> + * - start + offset:
> + - Q'\ :sub:`0[13:6]`
> + - Q'\ :sub:`0[5:0]; B1[1:0]=pad`
> + - pad
> + - pad
> + * - start + offset + 4:
> + - Q'\ :sub:`1[13:6]`
> + - Q'\ :sub:`1[5:0]; B1[1:0]=pad`
> + - pad
> + - pad
> diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
> b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst new file mode 100644
> index 0000000..da8b26b
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
> @@ -0,0 +1,55 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2-SDR-FMT-PCU18BE:
> +
> +******************************
> +V4L2_SDR_FMT_PCU18BE ('PC18')
> +******************************
> +
> +Planar complex unsigned 18-bit big endian IQ sample
> +
> +Description
> +===========
> +
> +This format contains a sequence of complex number samples. Each complex
> +number consist of two parts called In-phase and Quadrature (IQ). Both I
> +and Q are represented as a 18 bit unsigned big endian number stored in
> +32 bit space. The remaining unused bits within the 32 bit space will be
> +padded with 0. I value starts first and Q value starts at an offset
> +equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
> +the 18 bits, bit 17:2 (16 bit) is data and bit 1:0 (2 bit) can be any
> +value.
> +
> +**Byte Order.**
> +Each cell is one byte.
> +
> +.. flat-table::
> + :header-rows: 1
> + :stub-columns: 0
> +
> + * - Offset:
> + - Byte B0
> + - Byte B1
> + - Byte B2
> + - Byte B3
> + * - start + 0:
> + - I'\ :sub:`0[17:10]`
> + - I'\ :sub:`0[9:2]`
> + - I'\ :sub:`0[1:0]; B2[5:0]=pad`
> + - pad
> + * - start + 4:
> + - I'\ :sub:`1[17:10]`
> + - I'\ :sub:`1[9:2]`
> + - I'\ :sub:`1[1:0]; B2[5:0]=pad`
> + - pad
> + * - ...
> + * - start + offset:
> + - Q'\ :sub:`0[17:10]`
> + - Q'\ :sub:`0[9:2]`
> + - Q'\ :sub:`0[1:0]; B2[5:0]=pad`
> + - pad
> + * - start + offset + 4:
> + - Q'\ :sub:`1[17:10]`
> + - Q'\ :sub:`1[9:2]`
> + - Q'\ :sub:`1[1:0]; B2[5:0]=pad`
> + - pad
> diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
> b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst new file mode 100644
> index 0000000..5499eed
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
> @@ -0,0 +1,54 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +.. _V4L2-SDR-FMT-PCU20BE:
> +
> +******************************
> +V4L2_SDR_FMT_PCU20BE ('PC20')
> +******************************
> +
> +Planar complex unsigned 20-bit big endian IQ sample
> +
> +Description
> +===========
> +
> +This format contains a sequence of complex number samples. Each complex
> +number consist of two parts called In-phase and Quadrature (IQ). Both I
> +and Q are represented as a 20 bit unsigned big endian number stored in
> +32 bit space. The remaining unused bits within the 32 bit space will be
> +padded with 0. I value starts first and Q value starts at an offset
> +equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
> +the 20 bits, bit 19:2 (18 bit) is data and bit 1:0 (2 bit) can be any
> +value.
> +
> +**Byte Order.**
> +Each cell is one byte.
> +
> +.. flat-table::
> + :header-rows: 1
> + :stub-columns: 0
> +
> + * - Offset:
> + - Byte B0
> + - Byte B1
> + - Byte B2
> + - Byte B3
> + * - start + 0:
> + - I'\ :sub:`0[19:12]`
> + - I'\ :sub:`0[11:4]`
> + - I'\ :sub:`0[3:0]; B2[3:0]=pad`
> + - pad
> + * - start + 4:
> + - I'\ :sub:`1[19:12]`
> + - I'\ :sub:`1[11:4]`
> + - I'\ :sub:`1[3:0]; B2[3:0]=pad`
> + - pad
> + * - ...
> + * - start + offset:
> + - Q'\ :sub:`0[19:12]`
> + - Q'\ :sub:`0[11:4]`
> + - Q'\ :sub:`0[3:0]; B2[3:0]=pad`
> + - pad
> + * - start + offset + 4:
> + - Q'\ :sub:`1[19:12]`
> + - Q'\ :sub:`1[11:4]`
> + - Q'\ :sub:`1[3:0]; B2[3:0]=pad`
> + - pad
> diff --git a/Documentation/media/uapi/v4l/sdr-formats.rst
> b/Documentation/media/uapi/v4l/sdr-formats.rst index f863c08..2037f5b
> 100644
> --- a/Documentation/media/uapi/v4l/sdr-formats.rst
> +++ b/Documentation/media/uapi/v4l/sdr-formats.rst
> @@ -17,3 +17,6 @@ These formats are used for :ref:`SDR <sdr>` interface
> only. pixfmt-sdr-cs08
> pixfmt-sdr-cs14le
> pixfmt-sdr-ru12le
> + pixfmt-sdr-pcu16be
> + pixfmt-sdr-pcu18be
> + pixfmt-sdr-pcu20be
--
Regards,
Laurent Pinchart
^ permalink raw reply
* RE: [PATCH v3 2/7] dt-bindings: media: Add MAX2175 binding description
From: Ramesh Shanmugasundaram @ 2017-04-11 12:19 UTC (permalink / raw)
To: Laurent Pinchart
Cc: robh+dt@kernel.org, mark.rutland@arm.com, mchehab@kernel.org,
hverkuil@xs4all.nl, sakari.ailus@linux.intel.com, crope@iki.fi,
Chris Paterson, geert+renesas@glider.be,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <6297638.5S79beP3Jj@avalon>
Hi Laurent,
> On Tuesday 11 Apr 2017 09:57:45 Ramesh Shanmugasundaram wrote:
> > > On Tuesday 07 Feb 2017 15:02:32 Ramesh Shanmugasundaram wrote:
> > >> Add device tree binding documentation for MAX2175 Rf to bits tuner
> > >> device.
> > >>
> > >> Signed-off-by: Ramesh Shanmugasundaram
> > >> <ramesh.shanmugasundaram@bp.renesas.com> ---
> > >>
> > >> .../devicetree/bindings/media/i2c/max2175.txt | 61
> +++++++++++++++
> > >> .../devicetree/bindings/property-units.txt | 1 +
> > >> 2 files changed, 62 insertions(+)
> > >> create mode 100644
> > >>
> > >> Documentation/devicetree/bindings/media/i2c/max2175.txt
> > >>
> > >> diff --git
> > >> a/Documentation/devicetree/bindings/media/i2c/max2175.txt
> > >> b/Documentation/devicetree/bindings/media/i2c/max2175.txt new file
> > >> mode 100644 index 0000000..f591ab4
> > >> --- /dev/null
> > >> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
>
> [snip]
>
> > >> +- maxim,am-hiz : empty property indicates AM Hi-Z filter
> path
> > >> is
> > >> + selected for AM antenna input. By default this
> > >> + filter path is not used.
> > >
> > > Isn't this something that should be selected at runtime through a
> > > control ? Or does the hardware design dictate whether the filter has
> > > to be used or must not be used ?
> >
> > This is dictated by the h/w design and not selectable at run-time.
> > I will update these changes in the next patchset.
>
> In that case I'm fine with a property, but could we name it in such a way
> that it describes the hardware instead of instructing the software on how
> to configure the device ? For instance (and this is a made-up example as I
> don't know exactly how this works), if the AM Hi-Z filter is required when
> dealing with AM frequencies and forbidden when dealing with other
> frequency bands, and
> *if* boards have to be designed specifically for one frequency band (AM,
> FM, VHF, L, ...) without any way to accept different bands, then you could
> instead use
>
> maxim,frequency-band = "AM";
>
> and enable the filter accordingly in the driver. This would be in my
> opinion a better system hardware description.
I am not sure. The AM antenna input path has a default filter and AM Hi-Z filter. H/W dictates the path to be used for AM input only and this is fixed. The device can be configured to use different bands at runtime & not AM only. I could edit the description as below:
- maxim,am-hiz : empty property indicates AM Hi-Z filter path usage for AM antenna
input as dictated by hardware design. By default this filter path is not used.
Is it any better? Do you still think the property name should be changed please?
Thanks,
Ramesh
^ permalink raw reply
* [PATCH v5 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: michael.hennerich @ 2017-04-11 12:16 UTC (permalink / raw)
To: wsa, peda, robh+dt, mark.rutland, linus.walleij
Cc: linux-i2c, devicetree, linux-gpio, linux-kernel,
Michael Hennerich
In-Reply-To: <1491912976-8396-1-git-send-email-michael.hennerich@analog.com>
From: Michael Hennerich <michael.hennerich@analog.com>
This patch adds support for the Analog Devices / Linear Technology
LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
The LTC4306 optionally provides two general purpose input/output pins
(GPIOs) that can be configured as logic inputs, opendrain outputs or
push-pull outputs via the generic GPIOLIB framework.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
---
Changes since v1:
- Sort makefile entries
- Sort driver includes
- Use proper defines
- Miscellaneous coding style fixups
- Rename mux select callback
- Revise i2c-mux-idle-disconnect handling
- Add ENABLE GPIO handling on error and device removal.
- Remove surplus of_match_device call.
Changes since v2:
- Stop double error reporting (i2c_mux_add_adapter)
- Change subject
- Split dt bindings to separate patch
Changes since v3:
- Change subject and add spaces
- Convert to I2C_MUX_LOCKED
- Convert to regmap
- Remove local register cache
- Restore previous ENABLE GPIO handling
- Initially pulse ENABLE low
- Eliminate i2c client struct in driver state structure
- Simplify error return path
- Misc minor cleanups
Changes since v4:
- Remove redundant includes
- Use regmap cache type REGCACHE_FLAT
- gpio_get restore double negates on return
- Implement gpio_get_direction
- Use unified device property interface
- mux_alloc exact number of channels
- Reword kconfig help text
---
MAINTAINERS | 8 +
drivers/i2c/muxes/Kconfig | 11 ++
drivers/i2c/muxes/Makefile | 1 +
drivers/i2c/muxes/i2c-mux-ltc4306.c | 322 ++++++++++++++++++++++++++++++++++++
4 files changed, 342 insertions(+)
create mode 100644 drivers/i2c/muxes/i2c-mux-ltc4306.c
diff --git a/MAINTAINERS b/MAINTAINERS
index c776906..9a27a19 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7698,6 +7698,14 @@ S: Maintained
F: Documentation/hwmon/ltc4261
F: drivers/hwmon/ltc4261.c
+LTC4306 I2C MULTIPLEXER DRIVER
+M: Michael Hennerich <michael.hennerich@analog.com>
+W: http://ez.analog.com/community/linux-device-drivers
+L: linux-i2c@vger.kernel.org
+S: Supported
+F: drivers/i2c/muxes/i2c-mux-ltc4306.c
+F: Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
+
LTP (Linux Test Project)
M: Mike Frysinger <vapier@gentoo.org>
M: Cyril Hrubis <chrubis@suse.cz>
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 10b3d17..1e160fc 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -30,6 +30,17 @@ config I2C_MUX_GPIO
This driver can also be built as a module. If so, the module
will be called i2c-mux-gpio.
+config I2C_MUX_LTC4306
+ tristate "LTC LTC4306/5 I2C multiplexer"
+ select GPIOLIB
+ select REGMAP_I2C
+ help
+ If you say yes here you get support for the Analog Devices
+ LTC4306 or LTC4305 I2C mux/switch devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mux-ltc4306.
+
config I2C_MUX_PCA9541
tristate "NXP PCA9541 I2C Master Selector"
help
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 9948fa4..ff7618c 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE) += i2c-arb-gpio-challenge.o
obj-$(CONFIG_I2C_DEMUX_PINCTRL) += i2c-demux-pinctrl.o
obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
+obj-$(CONFIG_I2C_MUX_LTC4306) += i2c-mux-ltc4306.o
obj-$(CONFIG_I2C_MUX_MLXCPLD) += i2c-mux-mlxcpld.o
obj-$(CONFIG_I2C_MUX_PCA9541) += i2c-mux-pca9541.o
obj-$(CONFIG_I2C_MUX_PCA954x) += i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-mux-ltc4306.c b/drivers/i2c/muxes/i2c-mux-ltc4306.c
new file mode 100644
index 0000000..311b1cc
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-mux-ltc4306.c
@@ -0,0 +1,322 @@
+/*
+ * Linear Technology LTC4306 and LTC4305 I2C multiplexer/switch
+ *
+ * Copyright (C) 2017 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ *
+ * Based on: i2c-mux-pca954x.c
+ *
+ * Datasheet: http://cds.linear.com/docs/en/datasheet/4306.pdf
+ */
+
+#include <linux/gpio/consumer.h>
+#include <linux/gpio/driver.h>
+#include <linux/i2c-mux.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#define LTC4305_MAX_NCHANS 2
+#define LTC4306_MAX_NCHANS 4
+
+#define LTC_REG_STATUS 0x0
+#define LTC_REG_CONFIG 0x1
+#define LTC_REG_MODE 0x2
+#define LTC_REG_SWITCH 0x3
+
+#define LTC_DOWNSTREAM_ACCL_EN BIT(6)
+#define LTC_UPSTREAM_ACCL_EN BIT(7)
+
+#define LTC_GPIO_ALL_INPUT 0xC0
+#define LTC_SWITCH_MASK 0xF0
+
+enum ltc_type {
+ ltc_4305,
+ ltc_4306,
+};
+
+struct chip_desc {
+ u8 nchans;
+ u8 num_gpios;
+};
+
+struct ltc4306 {
+ struct regmap *regmap;
+ struct gpio_chip gpiochip;
+ const struct chip_desc *chip;
+};
+
+static const struct chip_desc chips[] = {
+ [ltc_4305] = {
+ .nchans = LTC4305_MAX_NCHANS,
+ },
+ [ltc_4306] = {
+ .nchans = LTC4306_MAX_NCHANS,
+ .num_gpios = 2,
+ },
+};
+
+static bool ltc4306_is_volatile_reg(struct device *dev, unsigned int reg)
+{
+ return (reg == LTC_REG_CONFIG) ? true : false;
+}
+
+static const struct regmap_config ltc4306_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = LTC_REG_SWITCH,
+ .volatile_reg = ltc4306_is_volatile_reg,
+ .cache_type = REGCACHE_FLAT,
+};
+
+static int ltc4306_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(data->regmap, LTC_REG_CONFIG, &val);
+ if (ret < 0)
+ return ret;
+
+ return !!(val & BIT(1 - offset));
+}
+
+static void ltc4306_gpio_set(struct gpio_chip *chip, unsigned int offset,
+ int value)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+
+ regmap_update_bits(data->regmap, LTC_REG_CONFIG, BIT(5 - offset),
+ value ? BIT(5 - offset) : 0);
+}
+
+static int ltc4306_gpio_get_direction(struct gpio_chip *chip,
+ unsigned int offset)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(data->regmap, LTC_REG_MODE, &val);
+ if (ret < 0)
+ return ret;
+
+ return !!(val & BIT(7 - offset));
+}
+
+static int ltc4306_gpio_direction_input(struct gpio_chip *chip,
+ unsigned int offset)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+
+ return regmap_update_bits(data->regmap, LTC_REG_MODE,
+ BIT(7 - offset), BIT(7 - offset));
+}
+
+static int ltc4306_gpio_direction_output(struct gpio_chip *chip,
+ unsigned int offset, int value)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+
+ ltc4306_gpio_set(chip, offset, value);
+ return regmap_update_bits(data->regmap, LTC_REG_MODE,
+ BIT(7 - offset), 0);
+}
+
+static int ltc4306_gpio_set_config(struct gpio_chip *chip,
+ unsigned int offset, unsigned long config)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+ unsigned int val;
+
+ switch (pinconf_to_config_param(config)) {
+ case PIN_CONFIG_DRIVE_OPEN_DRAIN:
+ val = 0;
+ break;
+ case PIN_CONFIG_DRIVE_PUSH_PULL:
+ val = BIT(4 - offset);
+ break;
+ default:
+ return -ENOTSUPP;
+ }
+
+ return regmap_update_bits(data->regmap, LTC_REG_MODE,
+ BIT(4 - offset), val);
+}
+
+static int ltc4306_gpio_init(struct ltc4306 *data)
+{
+ struct device *dev = regmap_get_device(data->regmap);
+
+ if (!data->chip->num_gpios)
+ return 0;
+
+ data->gpiochip.label = dev_name(dev);
+ data->gpiochip.base = -1;
+ data->gpiochip.ngpio = data->chip->num_gpios;
+ data->gpiochip.parent = dev;
+ data->gpiochip.can_sleep = true;
+ data->gpiochip.get_direction = ltc4306_gpio_get_direction;
+ data->gpiochip.direction_input = ltc4306_gpio_direction_input;
+ data->gpiochip.direction_output = ltc4306_gpio_direction_output;
+ data->gpiochip.get = ltc4306_gpio_get;
+ data->gpiochip.set = ltc4306_gpio_set;
+ data->gpiochip.set_config = ltc4306_gpio_set_config;
+ data->gpiochip.owner = THIS_MODULE;
+
+ /* gpiolib assumes all GPIOs default input */
+ regmap_write(data->regmap, LTC_REG_MODE, LTC_GPIO_ALL_INPUT);
+
+ return devm_gpiochip_add_data(dev, &data->gpiochip, data);
+}
+
+static int ltc4306_select_mux(struct i2c_mux_core *muxc, u32 chan)
+{
+ struct ltc4306 *data = i2c_mux_priv(muxc);
+
+ return regmap_update_bits(data->regmap, LTC_REG_SWITCH,
+ LTC_SWITCH_MASK, BIT(7 - chan));
+}
+
+static int ltc4306_deselect_mux(struct i2c_mux_core *muxc, u32 chan)
+{
+ struct ltc4306 *data = i2c_mux_priv(muxc);
+
+ return regmap_update_bits(data->regmap, LTC_REG_SWITCH,
+ LTC_SWITCH_MASK, 0);
+}
+
+static const struct i2c_device_id ltc4306_id[] = {
+ { "ltc4305", ltc_4305 },
+ { "ltc4306", ltc_4306 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, ltc4306_id);
+
+static const struct of_device_id ltc4306_of_match[] = {
+ { .compatible = "lltc,ltc4305", .data = &chips[ltc_4305] },
+ { .compatible = "lltc,ltc4306", .data = &chips[ltc_4306] },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ltc4306_of_match);
+
+static int ltc4306_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct i2c_adapter *adap = to_i2c_adapter(client->dev.parent);
+ const struct chip_desc *chip;
+ struct i2c_mux_core *muxc;
+ struct ltc4306 *data;
+ struct gpio_desc *gpio;
+ bool idle_disc;
+ unsigned int val = 0;
+ int num, ret;
+
+ chip = of_device_get_match_data(&client->dev);
+
+ if (!chip)
+ chip = &chips[id->driver_data];
+
+ idle_disc = device_property_read_bool(&client->dev,
+ "i2c-mux-idle-disconnect");
+
+ muxc = i2c_mux_alloc(adap, &client->dev,
+ chip->nchans, sizeof(*data),
+ I2C_MUX_LOCKED, ltc4306_select_mux,
+ idle_disc ? ltc4306_deselect_mux : NULL);
+ if (!muxc)
+ return -ENOMEM;
+ data = i2c_mux_priv(muxc);
+ data->chip = chip;
+
+ i2c_set_clientdata(client, muxc);
+
+ data->regmap = devm_regmap_init_i2c(client, <c4306_regmap_config);
+ if (IS_ERR(data->regmap)) {
+ ret = PTR_ERR(data->regmap);
+ dev_err(&client->dev, "Failed to allocate register map: %d\n",
+ ret);
+ return ret;
+ }
+
+ /* Reset and enable the mux if an enable GPIO is specified. */
+ gpio = devm_gpiod_get_optional(&client->dev, "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(gpio))
+ return PTR_ERR(gpio);
+
+ if (gpio) {
+ udelay(1);
+ gpiod_set_value(gpio, 1);
+ }
+
+ /*
+ * Write the mux register at addr to verify
+ * that the mux is in fact present. This also
+ * initializes the mux to disconnected state.
+ */
+ if (regmap_write(data->regmap, LTC_REG_SWITCH, 0) < 0) {
+ dev_warn(&client->dev, "probe failed\n");
+ return -ENODEV;
+ }
+
+ if (device_property_read_bool(&client->dev,
+ "ltc,downstream-accelerators-enable"))
+ val |= LTC_DOWNSTREAM_ACCL_EN;
+
+ if (device_property_read_bool(&client->dev,
+ "ltc,upstream-accelerators-enable"))
+ val |= LTC_UPSTREAM_ACCL_EN;
+
+ if (regmap_write(data->regmap, LTC_REG_CONFIG, val) < 0)
+ return -ENODEV;
+
+ ret = ltc4306_gpio_init(data);
+ if (ret < 0)
+ return ret;
+
+ /* Now create an adapter for each channel */
+ for (num = 0; num < chip->nchans; num++) {
+ ret = i2c_mux_add_adapter(muxc, 0, num, 0);
+ if (ret) {
+ i2c_mux_del_adapters(muxc);
+ return ret;
+ }
+ }
+
+ dev_info(&client->dev,
+ "registered %d multiplexed busses for I2C switch %s\n",
+ num, client->name);
+
+ return 0;
+}
+
+static int ltc4306_remove(struct i2c_client *client)
+{
+ struct i2c_mux_core *muxc = i2c_get_clientdata(client);
+
+ i2c_mux_del_adapters(muxc);
+
+ return 0;
+}
+
+static struct i2c_driver ltc4306_driver = {
+ .driver = {
+ .name = "ltc4306",
+ .of_match_table = of_match_ptr(ltc4306_of_match),
+ },
+ .probe = ltc4306_probe,
+ .remove = ltc4306_remove,
+ .id_table = ltc4306_id,
+};
+
+module_i2c_driver(ltc4306_driver);
+
+MODULE_AUTHOR("Michael Hennerich <michael.hennerich@analog.com>");
+MODULE_DESCRIPTION("Linear Technology LTC4306, LTC4305 I2C mux/switch driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v5 1/2] dt-bindings: i2c: mux: ltc4306: Add dt-bindings for I2C multiplexer/switch
From: michael.hennerich @ 2017-04-11 12:16 UTC (permalink / raw)
To: wsa, peda, robh+dt, mark.rutland, linus.walleij
Cc: linux-i2c, devicetree, linux-gpio, linux-kernel,
Michael Hennerich
From: Michael Hennerich <michael.hennerich@analog.com>
This patch adds support for the Analog Devices / Linear Technology
LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
The LTC4306 optionally provides two general purpose input/output pins
(GPIOs) that can be configured as logic inputs, opendrain outputs or
push-pull outputs via the generic GPIOLIB framework.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/i2c/i2c-mux-ltc4306.txt | 61 ++++++++++++++++++++++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
new file mode 100644
index 0000000..1e98c6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
@@ -0,0 +1,61 @@
+* Linear Technology / Analog Devices I2C bus switch
+
+Required Properties:
+
+ - compatible: Must contain one of the following.
+ "lltc,ltc4305", "lltc,ltc4306"
+ - reg: The I2C address of the device.
+
+ The following required properties are defined externally:
+
+ - Standard I2C mux properties. See i2c-mux.txt in this directory.
+ - I2C child bus nodes. See i2c-mux.txt in this directory.
+
+Optional Properties:
+
+ - enable-gpios: Reference to the GPIO connected to the enable input.
+ - i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
+ children in idle state. This is necessary for example, if there are several
+ multiplexers on the bus and the devices behind them use same I2C addresses.
+ - gpio-controller: Marks the device node as a GPIO Controller.
+ - #gpio-cells: Should be two. The first cell is the pin number and
+ the second cell is used to specify flags.
+ See ../gpio/gpio.txt for more information.
+ - ltc,downstream-accelerators-enable: Enables the rise time accelerators
+ on the downstream port.
+ - ltc,upstream-accelerators-enable: Enables the rise time accelerators
+ on the upstream port.
+
+Example:
+
+ ltc4306: i2c-mux@4a {
+ compatible = "lltc,ltc4306";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4a>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ eeprom@50 {
+ compatible = "at,24c02";
+ reg = <0x50>;
+ };
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ eeprom@50 {
+ compatible = "at,24c02";
+ reg = <0x50>;
+ };
+ };
+ };
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] mfd: arizona: Add GPIO maintain state flag
From: Rob Herring @ 2017-04-11 12:15 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: Charles Keepax, Linus Walleij, Lee Jones, Alexandre Courbot,
Mark Rutland, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, patches
In-Reply-To: <1491903267.4826.8.camel@rf-debian.wolfsonmicro.main>
On Tue, Apr 11, 2017 at 4:34 AM, Richard Fitzgerald <rf@opensource.wolfsonmicro.com> wrote:
> On Mon, 2017-04-10 at 15:17 -0500, Rob Herring wrote:
>> On Fri, Apr 07, 2017 at 01:38:44PM +0100, Charles Keepax wrote:
>> > The Arizona devices only maintain the state of output GPIOs whilst the
>> > CODEC is active, this can cause issues if the CODEC suspends whilst
>> > something is relying on the state of one of its GPIOs. However, in
>> > many systems the CODEC GPIOs are used for audio related features
>> > and thus the state of the GPIOs is unimportant whilst the CODEC is
>> > suspended. Often keeping the CODEC resumed in such a system would
>> > incur a power impact that is unacceptable.
>> >
>> > Add a flag through the second cell of the GPIO specifier in device
>> > tree, to allow the user to select whether a GPIO being configured as
>> > an output should keep the CODEC resumed.
>>
>> If the whole codec can't be suspended, why does this need to be per
>> GPIO? You could just have a single boolean property.
>>
>
> Three reasons I can think of:
>
> 1) The GPIO binding already provides for passing extra information
> through the binding ("Exact meaning of each specifier cell is controller
> specific" as it says in the main gpio binding doc) so why add yet
> another custom property to do it?
While that statement is technically true, we do try to standardize flags. If every driver had its own set we'd end up with a mess.
> 2) Doing it through the gpio means that if ultimately the child DT node
> that is using it gets disabled (status="disabled") or that driver isn't
> in use the codec will be able to go to sleep. That won't happen with a
> brute-force "big lock".
>
> 3) The codec only has to be kept awake while any such GPIO is actually
> in use. See (2)
Fair enough.
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/2] drivers/serial: Add driver for Aspeed virtual UART
From: Andy Shevchenko @ 2017-04-11 12:15 UTC (permalink / raw)
To: Joel Stanley
Cc: Greg Kroah-Hartman, Jiri Slaby, Mark Rutland, Rob Herring,
Jeremy Kerr, linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree,
Benjamin Herrenschmidt, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <20170410040400.5509-3-joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
On Mon, Apr 10, 2017 at 7:04 AM, Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org> wrote:
> From: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
>
> This change adds a driver for the 16550-based Aspeed virtual UART
> device. We use a similar process to the of_serial driver for device
> probe, but expose some VUART-specific functions through sysfs too.
>
> The VUART is two UART 'front ends' connected by their FIFO (no actual
> serial line in between). One is on the BMC side (management controller)
> and one is on the host CPU side.
>
> This driver is for the BMC side. The sysfs files allow the BMC
> userspace, which owns the system configuration policy, to specify at
> what IO port and interrupt number the host side will appear to the host
> on the Host <-> BMC LPC bus. It could be different on a different system
> (though most of them use 3f8/4).
>
> OpenPOWER host firmware doesn't like it when the host-side of the
> VUART's FIFO is not drained. This driver only disables host TX discard
> mode when the port is in use. We set the VUART enabled bit when we bind
> to the device, and clear it on unbind.
>
> We don't want to do this on open/release, as the host may be using this
> bit to configure serial output modes, which is independent of whether
> the devices has been opened by BMC userspace.
> +static void aspeed_vuart_set_enabled(struct aspeed_vuart *vuart, bool enabled)
> +{
> + u8 reg;
> +
> + reg = readb(vuart->regs + ASPEED_VUART_GCRA);
> + reg &= ~ASPEED_VUART_GCRA_VUART_EN;
> + if (enabled)
> + reg |= ASPEED_VUART_GCRA_VUART_EN;
Usually the pattern is
if (something)
set x bit;
else
clear x bit;
It would make it one operation in any case and a bit more understandable.
> + writeb(reg, vuart->regs + ASPEED_VUART_GCRA);
> +}
> +
> +static void aspeed_vuart_set_host_tx_discard(struct aspeed_vuart *vuart,
> + bool discard)
> +{
> + u8 reg;
> +
> + reg = readb(vuart->regs + ASPEED_VUART_GCRA);
> +
> + /* If the DISABLE_HOST_TX_DISCARD bit is set, discard is disabled */
> + reg &= ~ASPEED_VUART_GCRA_DISABLE_HOST_TX_DISCARD;
> + if (!discard)
> + reg |= ASPEED_VUART_GCRA_DISABLE_HOST_TX_DISCARD;
Ditto.
> +
> + writeb(reg, vuart->regs + ASPEED_VUART_GCRA);
> +}
> + /* The 8510 core creates the mapping, which we grab a reference to
> + * for VUART-specific registers */
Hmm... What about multi-line style?
> + port.port.irq = irq_of_parse_and_map(np, 0);
The benefit of use platform_get_irq() is to get rid of some OF specific headers.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3 00/10] Nokia H4+ support
From: Marcel Holtmann @ 2017-04-11 11:36 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Greg Kroah-Hartman, Gustavo F. Padovan, Johan Hedberg,
Samuel Thibault, Pavel Machek, Tony Lindgren, Jiri Slaby,
Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller, Rob Herring
In-Reply-To: <20170410231041.vz35anezpzhscu4t@earth>
Hi Sebastian,
>>>>>> Here is PATCHv3 for the Nokia bluetooth patchset. I addressed all comments from
>>>>>> Rob and Pavel regarding the serdev patches and dropped the *.dts patches, since
>>>>>> they were queued by Tony. I also changed the patch order, so that the serdev
>>>>>> patches come first. All of them have Acked-by from Rob, so I think it makes
>>>>>> sense to merge them to serdev subsystem (now) and provide an immutable branch
>>>>>> for the bluetooth subsystem.
>>>>>
>>>>> Greg doesn't read cover letters generally and since the serdev patches
>>>>> are Cc rather than To him, he's probably not planning to pick them up.
>>>>
>>>> I wonder actually if we should merge all of these via bluetooth-next
>>>> tree with proper Ack from Greg. However it would be good to also get
>>>> buy in from Dave for merging this ultimately through net-next.
>>>
>>> I don't really care where it goes. I can take the whole thing in my
>>> tty/serial tree now if no one objects and I get an ack from the relevant
>>> maintainers {hint...}
>>
>> I think it is better if it goes thru BT tree. I have another driver
>> converted that is dependent on this series. There's a couple other
>> serdev changes on the list too, but this shouldn't depend on them.
>
> Is this waiting for something, or could it be queued to
> bluetooth-next then? It would be nice to finally have
> this in 4.12 :)
I would prefer if we can get an ACK from Greg. Then I merge it through the bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH v9 1/2] media: i2c/ov5645: add the device tree binding document
From: Todor Tomov @ 2017-04-11 11:28 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w, sakari.ailus-X3B1VOXEql0,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Todor Tomov
Add the document for ov5645 device tree binding.
Signed-off-by: Todor Tomov <todor.tomov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Acked-by: Sakari Ailus <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/media/i2c/ov5645.txt | 54 ++++++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5645.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5645.txt b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
new file mode 100644
index 0000000..fd7aec9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
@@ -0,0 +1,54 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5645 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1944V. It is programmable through a serial I2C
+interface.
+
+Required Properties:
+- compatible: Value should be "ovti,ov5645".
+- clocks: Reference to the xclk clock.
+- clock-names: Should be "xclk".
+- clock-frequency: Frequency of the xclk clock.
+- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This corresponds
+ to the hardware pin PWDNB which is physically active low.
+- reset-gpios: Chip reset GPIO. Polarity is GPIO_ACTIVE_LOW. This corresponds to
+ the hardware pin RESETB.
+- vdddo-supply: Chip digital IO regulator.
+- vdda-supply: Chip analog regulator.
+- vddd-supply: Chip digital core regulator.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ &i2c1 {
+ ...
+
+ ov5645: ov5645@78 {
+ compatible = "ovti,ov5645";
+ reg = <0x78>;
+
+ enable-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&camera_rear_default>;
+
+ clocks = <&clks 200>;
+ clock-names = "xclk";
+ clock-frequency = <23880000>;
+
+ vdddo-supply = <&camera_dovdd_1v8>;
+ vdda-supply = <&camera_avdd_2v8>;
+ vddd-supply = <&camera_dvdd_1v2>;
+
+ port {
+ ov5645_ep: endpoint {
+ clock-lanes = <1>;
+ data-lanes = <0 2>;
+ remote-endpoint = <&csi0_ep>;
+ };
+ };
+ };
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 2/7] dt-bindings: media: Add MAX2175 binding description
From: Laurent Pinchart @ 2017-04-11 11:27 UTC (permalink / raw)
To: Ramesh Shanmugasundaram
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
crope-X3B1VOXEql0@public.gmane.org, Chris Paterson,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <HK2PR06MB0545282102FBC0472D9831AEC3000-jAC1QCBx2F1Af0bSEaWBKm0DtJ1/0DrXvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Hi Ramesh,
On Tuesday 11 Apr 2017 09:57:45 Ramesh Shanmugasundaram wrote:
> > On Tuesday 07 Feb 2017 15:02:32 Ramesh Shanmugasundaram wrote:
> >> Add device tree binding documentation for MAX2175 Rf to bits tuner
> >> device.
> >>
> >> Signed-off-by: Ramesh Shanmugasundaram
> >> <ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org> ---
> >>
> >> .../devicetree/bindings/media/i2c/max2175.txt | 61 +++++++++++++++
> >> .../devicetree/bindings/property-units.txt | 1 +
> >> 2 files changed, 62 insertions(+)
> >> create mode 100644
> >>
> >> Documentation/devicetree/bindings/media/i2c/max2175.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt
> >> b/Documentation/devicetree/bindings/media/i2c/max2175.txt new file
> >> mode 100644
> >> index 0000000..f591ab4
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
[snip]
> >> +- maxim,am-hiz : empty property indicates AM Hi-Z filter path
> >> is
> >> + selected for AM antenna input. By default this
> >> + filter path is not used.
> >
> > Isn't this something that should be selected at runtime through a control
> > ? Or does the hardware design dictate whether the filter has to be used or
> > must not be used ?
>
> This is dictated by the h/w design and not selectable at run-time.
> I will update these changes in the next patchset.
In that case I'm fine with a property, but could we name it in such a way that
it describes the hardware instead of instructing the software on how to
configure the device ? For instance (and this is a made-up example as I don't
know exactly how this works), if the AM Hi-Z filter is required when dealing
with AM frequencies and forbidden when dealing with other frequency bands, and
*if* boards have to be designed specifically for one frequency band (AM, FM,
VHF, L, ...) without any way to accept different bands, then you could instead
use
maxim,frequency-band = "AM";
and enable the filter accordingly in the driver. This would be in my opinion a
better system hardware description.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 4/4] drm: zte: add VGA driver support
From: Shawn Guo @ 2017-04-11 10:56 UTC (permalink / raw)
To: Sean Paul
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Daniel Vetter,
Baoyou Xie, Xin Zhou, Jun Nie, Shawn Guo
In-Reply-To: <20170407144302.ge7afh5bq7eyy3s4@art_vandelay>
On Fri, Apr 07, 2017 at 10:43:02AM -0400, Sean Paul wrote:
> On Fri, Apr 07, 2017 at 11:02:33AM +0800, Shawn Guo wrote:
> > When you suggested to have a lock for DETECT_SEL register access, I
> > thought we are accessing it in a read-modify-write way and thus agreed
> > to add a lock. However, I just found that it's not the case actually.
> > All the accesses to the register are single direct write.
> >
> > And here is my understanding about the condition you described above.
> > Once DETECT_SEL register gets reset (both bits cleared), the hardware
> > switches DDC bus for EDID read, and hotplug detection will stop working
> > right away (this is how ZTE hardware works). That said, if we get a
> > disconnect before drm_get_edid() successfully finishes, two points:
> >
> > - The irq handler will not be triggered, so it will not get a chance to
> > update DETECT_SEL register.
>
> Ah, this was the missing piece I needed. I hadn't realized that the first
> VGA_AUTO_DETECT_SEL write in get_modes disabled the irq.
Sorry, something is not true with my point. The irq handler can still
be triggered, but the cause has to be something else than hotplug
interrupt, like EDID data transfer done or various error conditions.
So my point should be that the VGA_AUTO_DETECT_SEL reset at the
beginning of .get_modes disables hotplug detection interrupt, and irq
handler will not get any chance to write to the register in this case.
> > - The drm_get_edid() fails, and .get_modes returns with both detect bits
> > kept cleared.
> >
> > I think what we can do better in this case is that we should set the
> > device state into disconnected, before returning from .get_modes,
> > something like the code below. But still, I do not see we need a lock
> > for that.
>
> Yep, agreed. Can you also please add to your comment in the !edid case,
> something like:
>
> * Locking is not required here since the only other place to write this register
> * (and connected var) is the irq handler. The irq handler is disabled because
> * we've cleared AUTO_DETECT_SEL above.
Sure, thanks for the suggestion. I will add proper comment in the new
version.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] mmc: core: add mmc-card hardware reset enable support
From: Ulf Hansson @ 2017-04-11 10:43 UTC (permalink / raw)
To: Linus Walleij
Cc: Richard Leitner, Bart Van Assche, Luca Porzio, Rob Herring,
Mark Rutland, Shawn Lin, Adrian Hunter, Jaehoon Chung,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, Richard Leitner
In-Reply-To: <CACRpkdaBrk91hh3JGZ0vcD3aXO+OHD41xwRKn9prPSOX_SXuWg@mail.gmail.com>
On 11 April 2017 at 10:17, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Apr 11, 2017 at 9:31 AM, Richard Leitner
> <richard.leitner@skidata.com> wrote:
>
>> Some eMMCs disable their hardware reset line (RST_N) by default. To enable
>> it the host must set the corresponding bit in ECSD. An example for such
>> a device is the Micron MTFCxGACAANA-4M.
>>
>> This patch adds a new mmc-card devicetree property to let the host enable
>> this feature during card initialization.
>>
>> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
>
> Do we know *WHY* these cards disable their hardware reset lines?
Allow me to make a guess. In case the reset isn't enabled, the
internal eMMC card firmware don't monitor the pin for the reset. I
guess that could makes sense if SoC vendors has failed to properly
connect the pin, avoiding the eMMC card to be reset when it shouldn't.
>
> If it is just some random over-cautious panic thing we might consider
> just force re-enableing it, maybe with a warning in the dmesg, so we can
> always reset the card. No DT property needed.
There is actually already a DT property "cap-mmc-hw-reset"
(MMC_CAP_HW_RESET), which tells whether the eMMC reset is supported by
the host.
Perhaps we can consider to force-enabling it for the eMMC card, when
this property is set for the mmc host!? At least, inventing yet
another binding doesn't make sense to me.
>
> Putting some people who work for eMMC vendors in the To: line so they
> can say if they know about this.
Yes, let's see what they say about it.
>
> Yours,
> Linus Walleij
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v3 6/9] drivers: remove useless comment from base/arch_topology.c
From: Juri Lelli @ 2017-04-11 10:43 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: mark.rutland, devicetree, lorenzo.pieralisi, vincent.guittot,
linux-pm, peterz, catalin.marinas, broonie, will.deacon,
linux-kernel, dietmar.eggemann, robh+dt, gregkh, sudeep.holla,
morten.rasmussen, linux-arm-kernel
In-Reply-To: <20170410163325.GU17774@n2100.armlinux.org.uk>
On 10/04/17 17:33, Russell King - ARM Linux wrote:
> On Mon, Apr 10, 2017 at 03:02:14PM +0100, Juri Lelli wrote:
> > Hi,
> >
> > On 10/04/17 14:51, Russell King - ARM Linux wrote:
> > > On Mon, Mar 27, 2017 at 02:18:22PM +0100, Juri Lelli wrote:
> > > > Printing out an error message when we failed to get the cpu device is
> > > > not helping anyone. Remove it.
> > >
> > > (1) the subject line talks about removing a "comment" but you're
> > > actually removing an error printk
> > > (2) I don't think it's "not helping anyone", although the description
> > > above doesn't say _why_ - it's reporting the lack of a missing CPU
> > > device that we expect to be present. If it's not present, then
> > > we're not going to end up with the cpu capacity attribute, and the
> > > error message answers the "why is that sysfs file missing" question.
> >
> > That's the same I was thinking when I put the error message there in the
> > first place. But, then Greg didn't seem to like it.
>
> I don't think it was a case of "not liking it" - Greg asked what use it
> was. Greg also pointed out the race with userspace.
>
Right. I asked him for more information, since I wasn't able to
understand where the problem is.
> I think dropping this patch is the quickest way to move forward.
>
OK, I'm also up for dropping it.
Best,
- Juri
^ permalink raw reply
* Re: [PATCH] ARM: mxs: add support for I2SE Duckbill 2 boards
From: Shawn Guo @ 2017-04-11 10:32 UTC (permalink / raw)
To: Michael Heimpold
Cc: mark.rutland, devicetree, stefan.wahren, robh+dt,
Michael Heimpold, kernel, fabio.estevam, frowand.list,
linux-arm-kernel
In-Reply-To: <1491815335-26469-1-git-send-email-michael.heimpold@i2se.com>
On Mon, Apr 10, 2017 at 11:08:55AM +0200, Michael Heimpold wrote:
> The Duckbill devices are small, pen-drive sized boards based on
> NXP's i.MX28 SoC. While the initial variants (Duckbill series)
> were equipped with a micro SD card slot only, the latest generation
> (Duckbill 2 series) have an additional internal eMMC onboard.
>
> To distinguish between both generations, a new device tree
> compatible string was introduced. To get the MAC address fixup
> applied, we need to check for this new string here, too.
>
> Signed-off-by: Michael Heimpold <michael.heimpold@i2se.com>
Applied, thanks.
^ permalink raw reply
* [PATCH 3/3] input: touchscreen: ar1021_i2c: coding style fixes
From: Martin Kepplinger @ 2017-04-11 10:27 UTC (permalink / raw)
To: dmitry.torokhov, christian.gmeiner
Cc: linux, linux-input, linux-kernel, devicetree, Martin Kepplinger
In-Reply-To: <1491906479-17639-1-git-send-email-martin.kepplinger@ginzinger.com>
Use the common kernel coding style and corrently align parameters with
open parenthesis.
Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
---
drivers/input/touchscreen/ar1021_i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/ar1021_i2c.c b/drivers/input/touchscreen/ar1021_i2c.c
index 1767257..cac7eeb 100644
--- a/drivers/input/touchscreen/ar1021_i2c.c
+++ b/drivers/input/touchscreen/ar1021_i2c.c
@@ -38,7 +38,7 @@ static irqreturn_t ar1021_i2c_irq(int irq, void *dev_id)
int retval;
retval = i2c_master_recv(ar1021->client,
- ar1021->data, sizeof(ar1021->data));
+ ar1021->data, sizeof(ar1021->data));
if (retval != sizeof(ar1021->data))
goto out;
@@ -78,7 +78,7 @@ static void ar1021_i2c_close(struct input_dev *dev)
}
static int ar1021_i2c_probe(struct i2c_client *client,
- const struct i2c_device_id *id)
+ const struct i2c_device_id *id)
{
struct ar1021_i2c *ar1021;
struct input_dev *input;
--
2.1.4
^ permalink raw reply related
* [PATCH 2/3] Documentation: devicetree: bindings: add bindings doc for ar1021 driver
From: Martin Kepplinger @ 2017-04-11 10:27 UTC (permalink / raw)
To: dmitry.torokhov, christian.gmeiner
Cc: linux, linux-input, linux-kernel, devicetree, Martin Kepplinger
In-Reply-To: <1491906479-17639-1-git-send-email-martin.kepplinger@ginzinger.com>
Add a simple binding document highlighting the supported devices and
I2C bus address.
Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
---
.../devicetree/bindings/input/touchscreen/ar1021.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/ar1021.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ar1021.txt b/Documentation/devicetree/bindings/input/touchscreen/ar1021.txt
new file mode 100644
index 0000000..87a8c72
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/ar1021.txt
@@ -0,0 +1,16 @@
+* Microchip AR1020 and AR1021 touchscreen interface (I2C)
+
+Required properties:
+- compatible : use "microchip,ar1020-i2c" or "microchip,ar1021-i2c"
+- reg : I2C slave address
+- interrupt-parent : the phandle for the interrupt controller
+- interrupts : touch controller interrupt
+
+Example:
+
+ ar1020: ar1020@4d {
+ compatible = "microchip,ar1020-i2c";
+ reg = <0x4d>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
+ };
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox