* Re: [PATCH v8 1/2] media: i2c/ov5645: add the device tree binding document
From: Sakari Ailus @ 2017-04-04 9:31 UTC (permalink / raw)
To: Todor Tomov
Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491228148-28505-1-git-send-email-todor.tomov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Todor,
On Mon, Apr 03, 2017 at 05:02:28PM +0300, Todor Tomov wrote:
> 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>
> ---
> .../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>;
If the sensor does not support lane reordering, I'd use 0 for the clock lane
and lanes starting from 1 for data-lanes.
I guess it'd be good to document this but that's definitely out of scope of
the patchset.
Acked-by: Sakari Ailus <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> + remote-endpoint = <&csi0_ep>;
> + };
> + };
> + };
> + };
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
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] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Peter Rosin @ 2017-04-04 9:28 UTC (permalink / raw)
To: michael.hennerich, wsa, robh+dt, mark.rutland, linus.walleij
Cc: linux-i2c, devicetree, linux-gpio, linux-kernel
In-Reply-To: <e0027ff7-948e-60f1-a492-72ab4a67605f@analog.com>
*snip* *snip*
>>> +static int ltc4306_gpio_get(struct gpio_chip *chip, unsigned int offset)
>>> +{
>>> + struct ltc4306 *data = gpiochip_get_data(chip);
>>> + int ret = 0;
>>> +
>>> + if (gpiochip_line_is_open_drain(chip, offset) ||
>>> + (data->regs[LTC_REG_MODE] & BIT(7 - offset))) {
>>
>> I wonder about this open-coded register cache. So, gpio people, is there
>> a guarantee from gpiolib that only one gpio_chip operation is in flight
>> concurrently? Because I don't see any evidence of that. With that in
>> mind, I think some locking is needed?
>
> I thought there is a per chip mutex in the gpiolib. But I can't find
> anything like this either. Since these two gpios can be used from
> different internal or external users. The locking seem to be needed.
>
> This gets us back to the regmap option. I did a quick grep, and 9 out of
> 205 drivers using regmap i2c, also use i2c_smbus... concurrently.
>
> grep -Rl regmap_init_i2c ./drivers | xargs grep -l i2c_smbus_ | grep "\.c"
>
> Mostly to work around non uniform transfer layouts.
I see three options.
1. Go with regmap and convert to mux-locked. Then the unlocked i2c-xfer
becomes an ordinary i2c-xfer (or smbus, whatever). This will result in
the cleanest code.
2. Go with regmap and stay parent-locked. Then hook into the regmap
locking as is done in one of the drivers that have worked around similar
problems with regmap and parent-locked i2c-mux interactions:
drivers/media/dvb-frontends/rtl2830.c
drivers/media/dvb-frontends/m88ds3103.c
This will probably work, but you'd need to add a number of extra helper
functions.
3. Exclude register 3 from regmap and only use regmap for the other
registers. This will be a bit ugly and ad-hoc, will need clear comments
on what is going on and why it is safe etc. And I want to see it before
I accept it. And it might not be my call to begin with, because TBH, it
sounds a bit disgusting...
> I'll check with Mark Brown on this topic.
Ok, might be a good idea...
>>> +
>>> +add_adapter_failed:
>>> + i2c_mux_del_adapters(muxc);
>>> +gpio_default:
>>> + gpiod_direction_input(data->en_gpio);
>>
>> This was actually not what I had in mind when I asked about it in v1, and
>> this looks a bit strange. You have no way of knowing if the pin was
>> configured as input when probe was called, and I don't see code like this
>> all over the place. Maybe it's is ok to not disable the chip over
>> suspend/resume, I was just asking because it looked a bit strange to grab
>> a pin and then forget about it. Now that I think about it some more, it's
>> probably ok to do just that since it is perhaps not possible to make the
>> chip draw less power by deasserting enable, but what do I know?
>
> GPIOs are assumed by default inputs. So if you want to undo the actions
> in probe. The logical consequence is to move them back to inputs, and
> let the external PULL-UP or PULL-DOWN on the ENABLE decide what happens.
> I would also prefer to leave it enabled, so that the GPIOs can retain
My point is that I do not see any probe functions undoing gpio configs.
Why bother in this case? Or are other probe functions really doing this?
I actually didn't check, but I haven't stumbled over it previously and
at least think I would have noticed...
> it's last state. Well I think the device draws a bit less power when
> disabled. But we don't support runtime PM anyways.
It might not be safe to reset the gpio pins over a suspend/resume depending
on what they are used for, so it is probably a bad idea to go there. Sorry
for bringing the whole issue up and muddying the waters...
Cheers,
peda
^ permalink raw reply
* [PATCH v12.4 8/10] devicetree: power: bq27xxx: Add monitored-battery documentation
From: Liam Breck @ 2017-04-04 8:57 UTC (permalink / raw)
To: Andrew F. Davis, linux-pm
Cc: Rob Herring, devicetree, Matt Ranostay, Liam Breck
In-Reply-To: <20170404085706.32592-1-liam@networkimprov.net>
From: Liam Breck <kernel@networkimprov.net>
Document monitored-battery = <&battery_node>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Sebastian Reichel <sre@kernel.org>
---
.../devicetree/bindings/power/supply/bq27xxx.txt | 31 +++++++++++++++++-----
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.txt b/Documentation/devicetree/bindings/power/supply/bq27xxx.txt
index b0c95ef..a4b62b3 100644
--- a/Documentation/devicetree/bindings/power/supply/bq27xxx.txt
+++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.txt
@@ -1,7 +1,7 @@
-Binding for TI BQ27XXX fuel gauge family
+TI BQ27XXX fuel gauge family
Required properties:
-- compatible: Should contain one of the following:
+- compatible: contains one of the following:
* "ti,bq27200" - BQ27200
* "ti,bq27210" - BQ27210
* "ti,bq27500" - deprecated, use revision specific property below
@@ -26,11 +26,28 @@ Required properties:
* "ti,bq27425" - BQ27425
* "ti,bq27441" - BQ27441
* "ti,bq27621" - BQ27621
-- reg: integer, i2c address of the device.
+- reg: integer, I2C address of the fuel gauge.
+
+Optional properties:
+- monitored-battery: phandle of battery characteristics devicetree node
+ The fuel gauge uses the following battery properties:
+ + energy-full-design-microwatt-hours
+ + charge-full-design-microamp-hours
+ + voltage-min-design-microvolt
+ Both or neither of the *-full-design-*-hours properties must be set.
+ See Documentation/devicetree/bindings/power/supply/battery.txt
Example:
-bq27510g3 {
- compatible = "ti,bq27510g3";
- reg = <0x55>;
-};
+ bat: battery {
+ compatible = "simple-battery";
+ voltage-min-design-microvolt = <3200000>;
+ energy-full-design-microwatt-hours = <5290000>;
+ charge-full-design-microamp-hours = <1430000>;
+ };
+
+ bq27510g3: fuel-gauge@55 {
+ compatible = "ti,bq27510g3";
+ reg = <0x55>;
+ monitored-battery = <&bat>;
+ };
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
From: Neil Armstrong @ 2017-04-04 8:51 UTC (permalink / raw)
To: Rob Herring
Cc: Arnd Bergmann, Kevin Hilman, carlo, linux-amlogic, Linux ARM,
Linux Kernel Mailing List, devicetree
In-Reply-To: <20170403163448.e7uuhhebqlaf33bl@rob-hp-laptop>
On 04/03/2017 06:34 PM, Rob Herring wrote:
> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>> <narmstrong@baylibre.com> wrote:
>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>> ---
>>>> Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>> 1 file changed, 20 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>> index bfd5b55..b850985 100644
>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>> - "amlogic,q201" (Meson gxm s912)
>>>> - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>> - "nexbox,a1" (Meson gxm s912)
>>>> +
>>>> +Amlogic Meson GX SoCs Information
>>>> +----------------------------------
>>>> +
>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>> +package and revision information. If present, a device node for this register
>>>> +should be added.
>>>> +
>>>> +Required properties:
>>>> + - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>> + - reg: Base address and length of the register block.
>>>> +
>>>> +Examples
>>>> +--------
>>>> +
>>>> + chipid@220 {
>>>> + compatible = "amlogic,meson-gx-socinfo";
>>>> + reg = <0x0 0x00220 0x0 0x4>;
>>>> + };
>>>> +
>>>
>>> The register location would hint that this is in the middle of some block of
>>> random registers, i.e. a syscon or some unrelated device.
>>>
>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>> it only has a single 32-bit register?
>>>
>>> Arnd
>>>
>>
>> Hi Arnd,
>>
>> I'm sorry I did not find any relevant registers in the docs or source code describing
>> it in a specific block of registers, and no close enough register definitions either.
>> They may be used by the secure firmware I imagine.
>>
>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>> gives some details on the whole SoC and package, and socinfo seems better.
>
> A register at address 0x220 seems a bit strange (unless there's ranges
> you're not showing), but ROM code at this address would be fairly
> typical. And putting version information into the ROM is also common.
>
> Rob
>
Hi Rob.
Indeed it's part of a larger range :
aobus: aobus@c8100000 {
compatible = "simple-bus";
reg = <0x0 0xc8100000 0x0 0x100000>;
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
the secure firmware :
AO_SEC_REG0 0x140
AO_SEC_REG1 0x144
AO_SEC_REG2 0x148
AO_SEC_TMODE_PWD0 0x160
AO_SEC_TMODE_PWD1 0x164
AO_SEC_TMODE_PWD2 0x168
AO_SEC_TMODE_PWD3 0x16C
AO_SEC_SCRATCH 0x17C
AO_SEC_JTAG_PWD0 0x180
AO_SEC_JTAG_PWD1 0x184
AO_SEC_JTAG_PWD2 0x188
AO_SEC_JTAG_PWD3 0x18C
AO_SEC_JTAG_SEC_CNTL 0x190
AO_SEC_JTAG_PWD_ADDR0 0x194
AO_SEC_JTAG_PWD_ADDR1 0x198
AO_SEC_JTAG_PWD_ADDR2 0x19C
AO_SEC_JTAG_PWD_ADDR3 0x1A0
AO_SEC_SHARED_AHB_SRAM_REG0_0 0x1C0
AO_SEC_SHARED_AHB_SRAM_REG0_1 0x1C4
AO_SEC_SHARED_AHB_SRAM_REG0_2 0x1C8
AO_SEC_SHARED_AHB_SRAM_REG1_0 0x1CC
AO_SEC_SHARED_AHB_SRAM_REG1_1 0x1D0
AO_SEC_SHARED_AHB_SRAM_REG1_2 0x1D4
AO_SEC_SHARED_AHB_SRAM_REG2_0 0x1D8
AO_SEC_SHARED_AHB_SRAM_REG2_1 0x1DC
AO_SEC_SHARED_AHB_SRAM_REG2_2 0x1E0
AO_SEC_SHARED_AHB_SRAM_REG3_0 0x1E4
AO_SEC_SHARED_AHB_SRAM_REG3_1 0x1E8
AO_SEC_SHARED_AHB_SRAM_REG3_2 0x1EC
AO_SEC_AO_AHB_SRAM_REG0_0 0x1F0
AO_SEC_AO_AHB_SRAM_REG0_1 0x1F4
AO_SEC_AO_AHB_SRAM_REG1_0 0x1F8
AO_SEC_AO_AHB_SRAM_REG1_1 0x1FC
AO_SEC_SD_CFG8 0x220
AO_SEC_SD_CFG9 0x224
AO_SEC_SD_CFG10 0x228
AO_SEC_SD_CFG11 0x22C
AO_SEC_SD_CFG12 0x230
AO_SEC_SD_CFG13 0x234
AO_SEC_SD_CFG14 0x238
AO_SEC_SD_CFG15 0x23C
AO_SEC_GP_CFG0 0x240
AO_SEC_GP_CFG1 0x244
AO_SEC_GP_CFG2 0x248
AO_SEC_GP_CFG3 0x24C
AO_SEC_GP_CFG4 0x250
AO_SEC_GP_CFG5 0x254
AO_SEC_GP_CFG6 0x258
AO_SEC_GP_CFG7 0x25C
AO_SEC_GP_CFG8 0x260
AO_SEC_GP_CFG9 0x264
AO_SEC_GP_CFG10 0x268
AO_SEC_GP_CFG11 0x26C
AO_SEC_GP_CFG12 0x270
AO_SEC_GP_CFG13 0x274
AO_SEC_GP_CFG14 0x278
AO_SEC_GP_CFG15 0x27C
As you see, the register we use here is AO_SEC_SD_CFG8...
Should I define all this block as simple-mfd and refer to it as a regmap ?
aobus: aobus@c8100000 {
compatible = "simple-bus";
reg = <0x0 0xc8100000 0x0 0x100000>;
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
ao_secure: ao-secure@140 {
compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
reg = <0x0 0x140 0x0 0x140>;
};
};
chipid {
compatible = "amlogic,meson-gx-socinfo";
ao-secure = <&ao_secure>;
chip-info-reg = <0xe0>;
};
Neil
^ permalink raw reply
* Re: [PATCH v2 08/13] ARM64: dts: meson-gx: Add shared CMA dma memory pool
From: Neil Armstrong @ 2017-04-04 8:41 UTC (permalink / raw)
To: airlied
Cc: linux-amlogic, devicetree, linux-arm-kernel, dri-devel,
linux-kernel
In-Reply-To: <1490109950-21421-9-git-send-email-narmstrong@baylibre.com>
On 03/21/2017 04:25 PM, Neil Armstrong wrote:
> The HDMI modes needs more CMA memory to be reserved at boot-time.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> index 5d995f7..94c6f95 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -71,6 +71,14 @@
> reg = <0x0 0x10000000 0x0 0x200000>;
> no-map;
> };
> +
> + linux,cma {
> + compatible = "shared-dma-pool";
> + reusable;
> + size = <0x0 0xbc00000>;
> + alignment = <0x0 0x400000>;
> + linux,cma-default;
> + };
> };
>
> cpus {
>
Hi Kevin,
Please take this one for the amlogic arm-soc DT tree.
It may need a rebase, please tell me then I'll repost this one rebased on your 4.12/dt64 branch.
Thanks,
Neil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: clock: gxbb: expose UART clocks
From: Michael Turquette @ 2017-04-04 8:40 UTC (permalink / raw)
To: sboyd-sgV2jX0FEOL9JmXXK+q4OQ
Cc: Helmut Klein, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170331165437.26227-2-hgkr.klein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Quoting Helmut Klein (2017-03-31 18:54:34)
> Expose the clock ids of the three none AO uarts to the dt-bindings
>
> Signed-off-by: Helmut Klein <hgkr.klein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Michael Turquette <mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> drivers/clk/meson/gxbb.h | 6 +++---
> include/dt-bindings/clock/gxbb-clkc.h | 3 +++
> 2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
> index 8ee2022ce5d5..1edfaa5fe307 100644
> --- a/drivers/clk/meson/gxbb.h
> +++ b/drivers/clk/meson/gxbb.h
> @@ -194,7 +194,7 @@
> /* #define CLKID_SAR_ADC */
> #define CLKID_SMART_CARD 24
> #define CLKID_RNG0 25
> -#define CLKID_UART0 26
> +/* CLKID_UART0 */
> #define CLKID_SDHC 27
> #define CLKID_STREAM 28
> #define CLKID_ASYNC_FIFO 29
> @@ -216,7 +216,7 @@
> #define CLKID_ADC 45
> #define CLKID_BLKMV 46
> #define CLKID_AIU 47
> -#define CLKID_UART1 48
> +/* CLKID_UART1 */
> #define CLKID_G2D 49
> /* CLKID_USB0 */
> /* CLKID_USB1 */
> @@ -236,7 +236,7 @@
> /* CLKID_USB0_DDR_BRIDGE */
> #define CLKID_MMC_PCLK 66
> #define CLKID_DVIN 67
> -#define CLKID_UART2 68
> +/* CLKID_UART2 */
> /* #define CLKID_SANA */
> #define CLKID_VPU_INTR 70
> #define CLKID_SEC_AHB_AHB3_BRIDGE 71
> diff --git a/include/dt-bindings/clock/gxbb-clkc.h b/include/dt-bindings/clock/gxbb-clkc.h
> index 692846c7941b..7b329df47752 100644
> --- a/include/dt-bindings/clock/gxbb-clkc.h
> +++ b/include/dt-bindings/clock/gxbb-clkc.h
> @@ -15,13 +15,16 @@
> #define CLKID_SPI 34
> #define CLKID_I2C 22
> #define CLKID_SAR_ADC 23
> +#define CLKID_UART0 26
> #define CLKID_ETH 36
> +#define CLKID_UART1 48
> #define CLKID_USB0 50
> #define CLKID_USB1 51
> #define CLKID_USB 55
> #define CLKID_HDMI_PCLK 63
> #define CLKID_USB1_DDR_BRIDGE 64
> #define CLKID_USB0_DDR_BRIDGE 65
> +#define CLKID_UART2 68
> #define CLKID_SANA 69
> #define CLKID_GCLK_VENCI_INT0 77
> #define CLKID_AO_I2C 93
> --
> 2.11.0
>
--
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 V7 4/7] mfd: da9061: MFD core support
From: Lee Jones @ 2017-04-04 8:39 UTC (permalink / raw)
To: Steve Twiss
Cc: LINUX-KERNEL, DEVICETREE, Dmitry Torokhov, Eduardo Valentin,
Guenter Roeck, LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG,
Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <b39c8c3f42a01a00f93292c569e8d30ce69ff3ab.1491230802.git.stwiss.opensource@diasemi.com>
On Mon, 03 Apr 2017, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> MFD support for DA9061 is provided as part of the DA9062 device driver.
>
> The registers header file adds two new chip variant IDs defined in DA9061
> and DA9062 hardware. The core header file adds new software enumerations
> for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration
> for distinguishing between DA9061/62 devices in software.
>
> The core source code adds a new .compatible of_device_id entry. This is
> extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The
> .data entry now holds a reference to the enumerated device type.
>
> A new regmap_irq_chip model is added for DA9061 and this supports the new
> list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the
> new sub system components for DA9061. Support is added for a new DA9061
> regmap_config which lists the correct readable, writable and volatile
> ranges for this chip.
>
> The probe function uses the device tree compatible string to switch on the
> da9062_compatible_types and configure the correct mfd cells, irq chip and
> regmap config.
>
> Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.
>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Ah, here it is.
Applied, thanks.
> ---
> Acked-for-mfd-by: Lee Jones <lee.jones@linaro.org>
>
> Hi Lee, that Ack was from your earlier posting:
> https://lkml.org/lkml/2017/1/4/328 this was
> Regards, Steve.
>
> This patch applies against linux-next and v4.11-rc3
>
> v6 -> v7 + update
> - Removed brackets surrounding case statements for
> case COMPAT_TYPE_DA9061:
> case COMPAT_TYPE_DA9062:
>
> v6 -> v7
> - Remove compilation warning when casting a void * to an integer on
> ARCH=x86_64 using -Wpointer-to-int-cast.
> - Recommendation uintptr_t cast: https://lkml.org/lkml/2017/3/28/292
> - Compile tested ARCH=x86_64
>
> v5 -> v6
> - Rebased from v4.9 to v4.11-rc3
> - Modify Copyright to match Dialog latest legal statement
> - Fixed "braces {} should be used on all arms" checkpatch warning
>
> v4 -> v5
> - NO CODE CHANGE
> - Rebased from v4.8 to v4.9
>
> v3 -> v4
> - Patch renamed from [PATCH V3 5/9] to [PATCH V4 4/8]
> - Removed DEFINE_RES_NAMED() macros for DA9061 resources and replaced
> them with DEFINE_RES_IRQ_NAMED().
> - Removed whitespace
> - Reverted change for badly defined mfd_cell da9062_devs of_compatible
> string from "dlg,da9062-watchdog" back to "dlg,da9062-wdt"
>
> v2 -> v3
> - NO CODE CHANGE
> - Patch renamed from [PATCH V2 05/10] to [PATCH V3 5/9]
>
> v1 -> v2
> - Patch renamed from [PATCH V1 01/10] to [PATCH V2 05/10] -- these
> changes were made to fix checkpatch warnings caused by the patch
> set dependency order
> - Fixed typo in the commit message "readble" to "readable"
> - Removed the explicit cross-check to decide if there is a conflict
> between the device tree compatible string and the hardware definition.
> This patch assumes the device tree is correctly written and therefore
> removes the need for a hardware/DT sanity check.
> - Removed extra semicolon in drivers/mfd/da9062-core.c:877
> - Re-write compatible entries into numerical order
>
> Lee,
>
> Changes as described in the version history above.
>
> As previously:
> This patch adds support for the DA9061 PMIC. This is done as part of the
> existing DA9062 device driver by extending the of_device_id match table.
> This in turn allows new MFD cells, irq chip and regmap definitions to
> support DA9061.
>
> Regards,
> Steve Twiss, Dialog Semiconductor
>
>
> drivers/mfd/Kconfig | 5 +-
> drivers/mfd/da9062-core.c | 427 +++++++++++++++++++++++++++++++++--
> include/linux/mfd/da9062/core.h | 29 ++-
> include/linux/mfd/da9062/registers.h | 5 +-
> 4 files changed, 443 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 55ecdfb..29cc11a 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -263,13 +263,14 @@ config MFD_DA9055
> called "da9055"
>
> config MFD_DA9062
> - tristate "Dialog Semiconductor DA9062 PMIC Support"
> + tristate "Dialog Semiconductor DA9062/61 PMIC Support"
> select MFD_CORE
> select REGMAP_I2C
> select REGMAP_IRQ
> depends on I2C
> help
> - Say yes here for support for the Dialog Semiconductor DA9062 PMIC.
> + Say yes here for support for the Dialog Semiconductor DA9061 and
> + DA9062 PMICs.
> This includes the I2C driver and core APIs.
> Additional drivers must be enabled in order to use the functionality
> of the device.
> diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
> index 8f873866..1803f58 100644
> --- a/drivers/mfd/da9062-core.c
> +++ b/drivers/mfd/da9062-core.c
> @@ -1,6 +1,6 @@
> /*
> - * Core, IRQ and I2C device driver for DA9062 PMIC
> - * Copyright (C) 2015 Dialog Semiconductor Ltd.
> + * Core, IRQ and I2C device driver for DA9061 and DA9062 PMICs
> + * Copyright (C) 2015-2017 Dialog Semiconductor
> *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License
> @@ -30,6 +30,70 @@
> #define DA9062_REG_EVENT_B_OFFSET 1
> #define DA9062_REG_EVENT_C_OFFSET 2
>
> +static struct regmap_irq da9061_irqs[] = {
> + /* EVENT A */
> + [DA9061_IRQ_ONKEY] = {
> + .reg_offset = DA9062_REG_EVENT_A_OFFSET,
> + .mask = DA9062AA_M_NONKEY_MASK,
> + },
> + [DA9061_IRQ_WDG_WARN] = {
> + .reg_offset = DA9062_REG_EVENT_A_OFFSET,
> + .mask = DA9062AA_M_WDG_WARN_MASK,
> + },
> + [DA9061_IRQ_SEQ_RDY] = {
> + .reg_offset = DA9062_REG_EVENT_A_OFFSET,
> + .mask = DA9062AA_M_SEQ_RDY_MASK,
> + },
> + /* EVENT B */
> + [DA9061_IRQ_TEMP] = {
> + .reg_offset = DA9062_REG_EVENT_B_OFFSET,
> + .mask = DA9062AA_M_TEMP_MASK,
> + },
> + [DA9061_IRQ_LDO_LIM] = {
> + .reg_offset = DA9062_REG_EVENT_B_OFFSET,
> + .mask = DA9062AA_M_LDO_LIM_MASK,
> + },
> + [DA9061_IRQ_DVC_RDY] = {
> + .reg_offset = DA9062_REG_EVENT_B_OFFSET,
> + .mask = DA9062AA_M_DVC_RDY_MASK,
> + },
> + [DA9061_IRQ_VDD_WARN] = {
> + .reg_offset = DA9062_REG_EVENT_B_OFFSET,
> + .mask = DA9062AA_M_VDD_WARN_MASK,
> + },
> + /* EVENT C */
> + [DA9061_IRQ_GPI0] = {
> + .reg_offset = DA9062_REG_EVENT_C_OFFSET,
> + .mask = DA9062AA_M_GPI0_MASK,
> + },
> + [DA9061_IRQ_GPI1] = {
> + .reg_offset = DA9062_REG_EVENT_C_OFFSET,
> + .mask = DA9062AA_M_GPI1_MASK,
> + },
> + [DA9061_IRQ_GPI2] = {
> + .reg_offset = DA9062_REG_EVENT_C_OFFSET,
> + .mask = DA9062AA_M_GPI2_MASK,
> + },
> + [DA9061_IRQ_GPI3] = {
> + .reg_offset = DA9062_REG_EVENT_C_OFFSET,
> + .mask = DA9062AA_M_GPI3_MASK,
> + },
> + [DA9061_IRQ_GPI4] = {
> + .reg_offset = DA9062_REG_EVENT_C_OFFSET,
> + .mask = DA9062AA_M_GPI4_MASK,
> + },
> +};
> +
> +static struct regmap_irq_chip da9061_irq_chip = {
> + .name = "da9061-irq",
> + .irqs = da9061_irqs,
> + .num_irqs = DA9061_NUM_IRQ,
> + .num_regs = 3,
> + .status_base = DA9062AA_EVENT_A,
> + .mask_base = DA9062AA_IRQ_MASK_A,
> + .ack_base = DA9062AA_EVENT_A,
> +};
> +
> static struct regmap_irq da9062_irqs[] = {
> /* EVENT A */
> [DA9062_IRQ_ONKEY] = {
> @@ -102,6 +166,57 @@
> .ack_base = DA9062AA_EVENT_A,
> };
>
> +static struct resource da9061_core_resources[] = {
> + DEFINE_RES_IRQ_NAMED(DA9061_IRQ_VDD_WARN, "VDD_WARN"),
> +};
> +
> +static struct resource da9061_regulators_resources[] = {
> + DEFINE_RES_IRQ_NAMED(DA9061_IRQ_LDO_LIM, "LDO_LIM"),
> +};
> +
> +static struct resource da9061_thermal_resources[] = {
> + DEFINE_RES_IRQ_NAMED(DA9061_IRQ_TEMP, "THERMAL"),
> +};
> +
> +static struct resource da9061_wdt_resources[] = {
> + DEFINE_RES_IRQ_NAMED(DA9061_IRQ_WDG_WARN, "WD_WARN"),
> +};
> +
> +static struct resource da9061_onkey_resources[] = {
> + DEFINE_RES_IRQ_NAMED(DA9061_IRQ_ONKEY, "ONKEY"),
> +};
> +
> +static const struct mfd_cell da9061_devs[] = {
> + {
> + .name = "da9061-core",
> + .num_resources = ARRAY_SIZE(da9061_core_resources),
> + .resources = da9061_core_resources,
> + },
> + {
> + .name = "da9062-regulators",
> + .num_resources = ARRAY_SIZE(da9061_regulators_resources),
> + .resources = da9061_regulators_resources,
> + },
> + {
> + .name = "da9061-watchdog",
> + .num_resources = ARRAY_SIZE(da9061_wdt_resources),
> + .resources = da9061_wdt_resources,
> + .of_compatible = "dlg,da9061-watchdog",
> + },
> + {
> + .name = "da9061-thermal",
> + .num_resources = ARRAY_SIZE(da9061_thermal_resources),
> + .resources = da9061_thermal_resources,
> + .of_compatible = "dlg,da9061-thermal",
> + },
> + {
> + .name = "da9061-onkey",
> + .num_resources = ARRAY_SIZE(da9061_onkey_resources),
> + .resources = da9061_onkey_resources,
> + .of_compatible = "dlg,da9061-onkey",
> + },
> +};
> +
> static struct resource da9062_core_resources[] = {
> DEFINE_RES_NAMED(DA9062_IRQ_VDD_WARN, 1, "VDD_WARN", IORESOURCE_IRQ),
> };
> @@ -200,7 +315,8 @@ static int da9062_clear_fault_log(struct da9062 *chip)
>
> static int da9062_get_device_type(struct da9062 *chip)
> {
> - int device_id, variant_id, variant_mrc;
> + int device_id, variant_id, variant_mrc, variant_vrc;
> + char *type;
> int ret;
>
> ret = regmap_read(chip->regmap, DA9062AA_DEVICE_ID, &device_id);
> @@ -219,9 +335,23 @@ static int da9062_get_device_type(struct da9062 *chip)
> return -EIO;
> }
>
> + variant_vrc = (variant_id & DA9062AA_VRC_MASK) >> DA9062AA_VRC_SHIFT;
> +
> + switch (variant_vrc) {
> + case DA9062_PMIC_VARIANT_VRC_DA9061:
> + type = "DA9061";
> + break;
> + case DA9062_PMIC_VARIANT_VRC_DA9062:
> + type = "DA9062";
> + break;
> + default:
> + type = "Unknown";
> + break;
> + }
> +
> dev_info(chip->dev,
> - "Device detected (device-ID: 0x%02X, var-ID: 0x%02X)\n",
> - device_id, variant_id);
> + "Device detected (device-ID: 0x%02X, var-ID: 0x%02X, %s)\n",
> + device_id, variant_id, type);
>
> variant_mrc = (variant_id & DA9062AA_MRC_MASK) >> DA9062AA_MRC_SHIFT;
>
> @@ -234,6 +364,234 @@ static int da9062_get_device_type(struct da9062 *chip)
> return ret;
> }
>
> +static const struct regmap_range da9061_aa_readable_ranges[] = {
> + {
> + .range_min = DA9062AA_PAGE_CON,
> + .range_max = DA9062AA_STATUS_B,
> + }, {
> + .range_min = DA9062AA_STATUS_D,
> + .range_max = DA9062AA_EVENT_C,
> + }, {
> + .range_min = DA9062AA_IRQ_MASK_A,
> + .range_max = DA9062AA_IRQ_MASK_C,
> + }, {
> + .range_min = DA9062AA_CONTROL_A,
> + .range_max = DA9062AA_GPIO_4,
> + }, {
> + .range_min = DA9062AA_GPIO_WKUP_MODE,
> + .range_max = DA9062AA_GPIO_OUT3_4,
> + }, {
> + .range_min = DA9062AA_BUCK1_CONT,
> + .range_max = DA9062AA_BUCK4_CONT,
> + }, {
> + .range_min = DA9062AA_BUCK3_CONT,
> + .range_max = DA9062AA_BUCK3_CONT,
> + }, {
> + .range_min = DA9062AA_LDO1_CONT,
> + .range_max = DA9062AA_LDO4_CONT,
> + }, {
> + .range_min = DA9062AA_DVC_1,
> + .range_max = DA9062AA_DVC_1,
> + }, {
> + .range_min = DA9062AA_SEQ,
> + .range_max = DA9062AA_ID_4_3,
> + }, {
> + .range_min = DA9062AA_ID_12_11,
> + .range_max = DA9062AA_ID_16_15,
> + }, {
> + .range_min = DA9062AA_ID_22_21,
> + .range_max = DA9062AA_ID_32_31,
> + }, {
> + .range_min = DA9062AA_SEQ_A,
> + .range_max = DA9062AA_WAIT,
> + }, {
> + .range_min = DA9062AA_RESET,
> + .range_max = DA9062AA_BUCK_ILIM_C,
> + }, {
> + .range_min = DA9062AA_BUCK1_CFG,
> + .range_max = DA9062AA_BUCK3_CFG,
> + }, {
> + .range_min = DA9062AA_VBUCK1_A,
> + .range_max = DA9062AA_VBUCK4_A,
> + }, {
> + .range_min = DA9062AA_VBUCK3_A,
> + .range_max = DA9062AA_VBUCK3_A,
> + }, {
> + .range_min = DA9062AA_VLDO1_A,
> + .range_max = DA9062AA_VLDO4_A,
> + }, {
> + .range_min = DA9062AA_VBUCK1_B,
> + .range_max = DA9062AA_VBUCK4_B,
> + }, {
> + .range_min = DA9062AA_VBUCK3_B,
> + .range_max = DA9062AA_VBUCK3_B,
> + }, {
> + .range_min = DA9062AA_VLDO1_B,
> + .range_max = DA9062AA_VLDO4_B,
> + }, {
> + .range_min = DA9062AA_BBAT_CONT,
> + .range_max = DA9062AA_BBAT_CONT,
> + }, {
> + .range_min = DA9062AA_INTERFACE,
> + .range_max = DA9062AA_CONFIG_E,
> + }, {
> + .range_min = DA9062AA_CONFIG_G,
> + .range_max = DA9062AA_CONFIG_K,
> + }, {
> + .range_min = DA9062AA_CONFIG_M,
> + .range_max = DA9062AA_CONFIG_M,
> + }, {
> + .range_min = DA9062AA_GP_ID_0,
> + .range_max = DA9062AA_GP_ID_19,
> + }, {
> + .range_min = DA9062AA_DEVICE_ID,
> + .range_max = DA9062AA_CONFIG_ID,
> + },
> +};
> +
> +static const struct regmap_range da9061_aa_writeable_ranges[] = {
> + {
> + .range_min = DA9062AA_PAGE_CON,
> + .range_max = DA9062AA_PAGE_CON,
> + }, {
> + .range_min = DA9062AA_FAULT_LOG,
> + .range_max = DA9062AA_EVENT_C,
> + }, {
> + .range_min = DA9062AA_IRQ_MASK_A,
> + .range_max = DA9062AA_IRQ_MASK_C,
> + }, {
> + .range_min = DA9062AA_CONTROL_A,
> + .range_max = DA9062AA_GPIO_4,
> + }, {
> + .range_min = DA9062AA_GPIO_WKUP_MODE,
> + .range_max = DA9062AA_GPIO_OUT3_4,
> + }, {
> + .range_min = DA9062AA_BUCK1_CONT,
> + .range_max = DA9062AA_BUCK4_CONT,
> + }, {
> + .range_min = DA9062AA_BUCK3_CONT,
> + .range_max = DA9062AA_BUCK3_CONT,
> + }, {
> + .range_min = DA9062AA_LDO1_CONT,
> + .range_max = DA9062AA_LDO4_CONT,
> + }, {
> + .range_min = DA9062AA_DVC_1,
> + .range_max = DA9062AA_DVC_1,
> + }, {
> + .range_min = DA9062AA_SEQ,
> + .range_max = DA9062AA_ID_4_3,
> + }, {
> + .range_min = DA9062AA_ID_12_11,
> + .range_max = DA9062AA_ID_16_15,
> + }, {
> + .range_min = DA9062AA_ID_22_21,
> + .range_max = DA9062AA_ID_32_31,
> + }, {
> + .range_min = DA9062AA_SEQ_A,
> + .range_max = DA9062AA_WAIT,
> + }, {
> + .range_min = DA9062AA_RESET,
> + .range_max = DA9062AA_BUCK_ILIM_C,
> + }, {
> + .range_min = DA9062AA_BUCK1_CFG,
> + .range_max = DA9062AA_BUCK3_CFG,
> + }, {
> + .range_min = DA9062AA_VBUCK1_A,
> + .range_max = DA9062AA_VBUCK4_A,
> + }, {
> + .range_min = DA9062AA_VBUCK3_A,
> + .range_max = DA9062AA_VBUCK3_A,
> + }, {
> + .range_min = DA9062AA_VLDO1_A,
> + .range_max = DA9062AA_VLDO4_A,
> + }, {
> + .range_min = DA9062AA_VBUCK1_B,
> + .range_max = DA9062AA_VBUCK4_B,
> + }, {
> + .range_min = DA9062AA_VBUCK3_B,
> + .range_max = DA9062AA_VBUCK3_B,
> + }, {
> + .range_min = DA9062AA_VLDO1_B,
> + .range_max = DA9062AA_VLDO4_B,
> + }, {
> + .range_min = DA9062AA_BBAT_CONT,
> + .range_max = DA9062AA_BBAT_CONT,
> + }, {
> + .range_min = DA9062AA_GP_ID_0,
> + .range_max = DA9062AA_GP_ID_19,
> + },
> +};
> +
> +static const struct regmap_range da9061_aa_volatile_ranges[] = {
> + {
> + .range_min = DA9062AA_PAGE_CON,
> + .range_max = DA9062AA_STATUS_B,
> + }, {
> + .range_min = DA9062AA_STATUS_D,
> + .range_max = DA9062AA_EVENT_C,
> + }, {
> + .range_min = DA9062AA_CONTROL_A,
> + .range_max = DA9062AA_CONTROL_B,
> + }, {
> + .range_min = DA9062AA_CONTROL_E,
> + .range_max = DA9062AA_CONTROL_F,
> + }, {
> + .range_min = DA9062AA_BUCK1_CONT,
> + .range_max = DA9062AA_BUCK4_CONT,
> + }, {
> + .range_min = DA9062AA_BUCK3_CONT,
> + .range_max = DA9062AA_BUCK3_CONT,
> + }, {
> + .range_min = DA9062AA_LDO1_CONT,
> + .range_max = DA9062AA_LDO4_CONT,
> + }, {
> + .range_min = DA9062AA_DVC_1,
> + .range_max = DA9062AA_DVC_1,
> + }, {
> + .range_min = DA9062AA_SEQ,
> + .range_max = DA9062AA_SEQ,
> + },
> +};
> +
> +static const struct regmap_access_table da9061_aa_readable_table = {
> + .yes_ranges = da9061_aa_readable_ranges,
> + .n_yes_ranges = ARRAY_SIZE(da9061_aa_readable_ranges),
> +};
> +
> +static const struct regmap_access_table da9061_aa_writeable_table = {
> + .yes_ranges = da9061_aa_writeable_ranges,
> + .n_yes_ranges = ARRAY_SIZE(da9061_aa_writeable_ranges),
> +};
> +
> +static const struct regmap_access_table da9061_aa_volatile_table = {
> + .yes_ranges = da9061_aa_volatile_ranges,
> + .n_yes_ranges = ARRAY_SIZE(da9061_aa_volatile_ranges),
> +};
> +
> +static const struct regmap_range_cfg da9061_range_cfg[] = {
> + {
> + .range_min = DA9062AA_PAGE_CON,
> + .range_max = DA9062AA_CONFIG_ID,
> + .selector_reg = DA9062AA_PAGE_CON,
> + .selector_mask = 1 << DA9062_I2C_PAGE_SEL_SHIFT,
> + .selector_shift = DA9062_I2C_PAGE_SEL_SHIFT,
> + .window_start = 0,
> + .window_len = 256,
> + }
> +};
> +
> +static struct regmap_config da9061_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .ranges = da9061_range_cfg,
> + .num_ranges = ARRAY_SIZE(da9061_range_cfg),
> + .max_register = DA9062AA_CONFIG_ID,
> + .cache_type = REGCACHE_RBTREE,
> + .rd_table = &da9061_aa_readable_table,
> + .wr_table = &da9061_aa_writeable_table,
> + .volatile_table = &da9061_aa_volatile_table,
> +};
> +
> static const struct regmap_range da9062_aa_readable_ranges[] = {
> {
> .range_min = DA9062AA_PAGE_CON,
> @@ -456,17 +814,39 @@ static int da9062_get_device_type(struct da9062 *chip)
> .volatile_table = &da9062_aa_volatile_table,
> };
>
> +static const struct of_device_id da9062_dt_ids[] = {
> + { .compatible = "dlg,da9061", .data = (void *)COMPAT_TYPE_DA9061, },
> + { .compatible = "dlg,da9062", .data = (void *)COMPAT_TYPE_DA9062, },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, da9062_dt_ids);
> +
> static int da9062_i2c_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id)
> {
> struct da9062 *chip;
> + const struct of_device_id *match;
> unsigned int irq_base;
> + const struct mfd_cell *cell;
> + const struct regmap_irq_chip *irq_chip;
> + const struct regmap_config *config;
> + int cell_num;
> int ret;
>
> chip = devm_kzalloc(&i2c->dev, sizeof(*chip), GFP_KERNEL);
> if (!chip)
> return -ENOMEM;
>
> + if (i2c->dev.of_node) {
> + match = of_match_node(da9062_dt_ids, i2c->dev.of_node);
> + if (!match)
> + return -EINVAL;
> +
> + chip->chip_type = (uintptr_t)match->data;
> + } else {
> + chip->chip_type = id->driver_data;
> + }
> +
> i2c_set_clientdata(i2c, chip);
> chip->dev = &i2c->dev;
>
> @@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
> return -EINVAL;
> }
>
> - chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
> + switch (chip->chip_type) {
> + case COMPAT_TYPE_DA9061:
> + cell = da9061_devs;
> + cell_num = ARRAY_SIZE(da9061_devs);
> + irq_chip = &da9061_irq_chip;
> + config = &da9061_regmap_config;
> + break;
> + case COMPAT_TYPE_DA9062:
> + cell = da9062_devs;
> + cell_num = ARRAY_SIZE(da9062_devs);
> + irq_chip = &da9062_irq_chip;
> + config = &da9062_regmap_config;
> + break;
> + default:
> + dev_err(chip->dev, "Unrecognised chip type\n");
> + return -ENODEV;
> + }
> +
> + chip->regmap = devm_regmap_init_i2c(i2c, config);
> if (IS_ERR(chip->regmap)) {
> ret = PTR_ERR(chip->regmap);
> dev_err(chip->dev, "Failed to allocate register map: %d\n",
> @@ -493,7 +891,7 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
>
> ret = regmap_add_irq_chip(chip->regmap, i2c->irq,
> IRQF_TRIGGER_LOW | IRQF_ONESHOT | IRQF_SHARED,
> - -1, &da9062_irq_chip,
> + -1, irq_chip,
> &chip->regmap_irq);
> if (ret) {
> dev_err(chip->dev, "Failed to request IRQ %d: %d\n",
> @@ -503,8 +901,8 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
>
> irq_base = regmap_irq_chip_get_base(chip->regmap_irq);
>
> - ret = mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE, da9062_devs,
> - ARRAY_SIZE(da9062_devs), NULL, irq_base,
> + ret = mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE, cell,
> + cell_num, NULL, irq_base,
> NULL);
> if (ret) {
> dev_err(chip->dev, "Cannot register child devices\n");
> @@ -526,17 +924,12 @@ static int da9062_i2c_remove(struct i2c_client *i2c)
> }
>
> static const struct i2c_device_id da9062_i2c_id[] = {
> - { "da9062", 0 },
> + { "da9061", COMPAT_TYPE_DA9061 },
> + { "da9062", COMPAT_TYPE_DA9062 },
> { },
> };
> MODULE_DEVICE_TABLE(i2c, da9062_i2c_id);
>
> -static const struct of_device_id da9062_dt_ids[] = {
> - { .compatible = "dlg,da9062", },
> - { }
> -};
> -MODULE_DEVICE_TABLE(of, da9062_dt_ids);
> -
> static struct i2c_driver da9062_i2c_driver = {
> .driver = {
> .name = "da9062",
> @@ -549,6 +942,6 @@ static int da9062_i2c_remove(struct i2c_client *i2c)
>
> module_i2c_driver(da9062_i2c_driver);
>
> -MODULE_DESCRIPTION("Core device driver for Dialog DA9062");
> +MODULE_DESCRIPTION("Core device driver for Dialog DA9061 and DA9062");
> MODULE_AUTHOR("Steve Twiss <stwiss.opensource@diasemi.com>");
> MODULE_LICENSE("GPL");
> diff --git a/include/linux/mfd/da9062/core.h b/include/linux/mfd/da9062/core.h
> index 376ba84..74d33a0 100644
> --- a/include/linux/mfd/da9062/core.h
> +++ b/include/linux/mfd/da9062/core.h
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (C) 2015 Dialog Semiconductor Ltd.
> + * Copyright (C) 2015-2017 Dialog Semiconductor
> *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License
> @@ -18,7 +18,31 @@
> #include <linux/interrupt.h>
> #include <linux/mfd/da9062/registers.h>
>
> -/* Interrupts */
> +enum da9062_compatible_types {
> + COMPAT_TYPE_DA9061 = 1,
> + COMPAT_TYPE_DA9062,
> +};
> +
> +enum da9061_irqs {
> + /* IRQ A */
> + DA9061_IRQ_ONKEY,
> + DA9061_IRQ_WDG_WARN,
> + DA9061_IRQ_SEQ_RDY,
> + /* IRQ B*/
> + DA9061_IRQ_TEMP,
> + DA9061_IRQ_LDO_LIM,
> + DA9061_IRQ_DVC_RDY,
> + DA9061_IRQ_VDD_WARN,
> + /* IRQ C */
> + DA9061_IRQ_GPI0,
> + DA9061_IRQ_GPI1,
> + DA9061_IRQ_GPI2,
> + DA9061_IRQ_GPI3,
> + DA9061_IRQ_GPI4,
> +
> + DA9061_NUM_IRQ,
> +};
> +
> enum da9062_irqs {
> /* IRQ A */
> DA9062_IRQ_ONKEY,
> @@ -45,6 +69,7 @@ struct da9062 {
> struct device *dev;
> struct regmap *regmap;
> struct regmap_irq_chip_data *regmap_irq;
> + enum da9062_compatible_types chip_type;
> };
>
> #endif /* __MFD_DA9062_CORE_H__ */
> diff --git a/include/linux/mfd/da9062/registers.h b/include/linux/mfd/da9062/registers.h
> index 97790d1..18d576a 100644
> --- a/include/linux/mfd/da9062/registers.h
> +++ b/include/linux/mfd/da9062/registers.h
> @@ -1,6 +1,5 @@
> /*
> - * registers.h - REGISTERS H for DA9062
> - * Copyright (C) 2015 Dialog Semiconductor Ltd.
> + * Copyright (C) 2015-2017 Dialog Semiconductor
> *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License
> @@ -18,6 +17,8 @@
>
> #define DA9062_PMIC_DEVICE_ID 0x62
> #define DA9062_PMIC_VARIANT_MRC_AA 0x01
> +#define DA9062_PMIC_VARIANT_VRC_DA9061 0x01
> +#define DA9062_PMIC_VARIANT_VRC_DA9062 0x02
>
> #define DA9062_I2C_PAGE_SEL_SHIFT 1
>
--
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 V7 4/7] mfd: da9061: MFD core support
From: Lee Jones @ 2017-04-04 8:34 UTC (permalink / raw)
To: Steve Twiss
Cc: LINUX-KERNEL, DEVICETREE, Dmitry Torokhov, Eduardo Valentin,
Guenter Roeck, LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG,
Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <6ED8E3B22081A4459DAC7699F3695FB7018CD6B207-68WUHU125fLzLL1Oxlh9IgLouzNaz+3S@public.gmane.org>
On Mon, 03 Apr 2017, Steve Twiss wrote:
> On 03 April 2017 15:31, Lee Jones wrote:
>
> > Subject: Re: [PATCH V7 4/7] mfd: da9061: MFD core support
> >
> > On Mon, 03 Apr 2017, Steve Twiss wrote:
> > > On 03 April 2017 15:12, Lee Jones wrote:
> > >
> > > > > @@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
> > > > > return -EINVAL;
> > > > > }
> > > > >
> > > > > - chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
> > > > > + switch (chip->chip_type) {
> > > > > + case(COMPAT_TYPE_DA9061):
> > > >
> > > > Brackets around the case value?
> > > >
> > > > That's a new one on me.
> > >
> > > Hm. Do you want me to resend it without braces?
> >
> > Yes please. And a space after the 'case'.
>
> Hi Lee,
>
> I have resent PATCH V7 to change "case(X):" to be "case X:".
> - Removed brackets surrounding case statements for
> case COMPAT_TYPE_DA9061:
> case COMPAT_TYPE_DA9062:
Okay, good.
> New patch is here:
> https://lkml.org/lkml/2017/4/3/462
>
> The patch it is called by the same title "[PATCH V7 4/7] mfd: da9061: MFD core support".
> I've not updated the whole patch-set or changed the patch version number from V7.
I don't see it in my inbox?
You should always change the version, or things get confusing.
Even if it's a small change, you can differentiate by v7.1 or similar.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" 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 00/11] add thermal throttling to Allwinner A33 SoC
From: Lee Jones @ 2017-04-04 8:31 UTC (permalink / raw)
To: Quentin Schulz
Cc: dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, icenowy-ymACFijhrKM
In-Reply-To: <20170321153611.16228-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, 21 Mar 2017, Quentin Schulz wrote:
> The Allwinner SoCs all have an ADC that can also act as a touchscreen
> controller and a thermal sensor. The first four channels can be used
> either for the ADC or the touchscreen and the fifth channel is used for
> the thermal sensor. We currently have a driver for the two latter
> functions in drivers/input/touchscreen/sun4i-ts.c but we don't have
> access to the ADC feature at all. It is meant to replace the current
> driver by using MFD and subdrivers for existing bindings.
>
> The Allwinner A33 only has a thermal sensor present in the GPADC. In
> addition, there is not an existing DT binding for the GPADC. Thus, we do
> not need the sun4i-gpadc MFD driver which was made to keep DT compatibility
> and probe subdrivers without the need to add DT subnodes.
>
> This series of patch adds the thermal sensor for the A33 and GPU/CPU
> thermal throttling. It also adds the cpu-supply property to the CPU node
> needed by the Sinlinx SinA33 and Olinuxino A33 to adapt their CPU regulator
> voltage depending on the currently used OPP. The other A33 boards all have
> their cpu-supply property set.
>
> This series also fixes the missing operating-points-v2 property in cpu DT
> nodes. Finally, it also adds all remaining OPPs which can be found in
> Allwinner 3.4 linux and fex files of all A33 boards.
>
> This series of patch is based on this[1] series of patch.
>
> v3:
> - fixed compatible name in DT and in documentation,
> - fixed DT node name and label,
> - added explanations in commit logs,
> - moved frequencies that need overvolting to board DTS instead of A33 DTSI,
> - fixed a typo in if is_enabled condition,
> - removed all patches concerning Olimex Olinuxino (no HW to test on),
What is the plan for this series?
I'm guessing there are no hard dependencies on the ARM parts?
If not, I'm happy to take the changes to 'drivers/*'.
> [1] https://lkml.org/lkml/2016/12/13/298 : "[PATCH v9] add support for Allwinner
> SoCs ADC"
>
> Thanks,
> Quentin
>
> Maxime Ripard (1):
> ARM: sun8i: a33: Add devfreq-based GPU cooling
>
> Quentin Schulz (10):
> ARM: sun8i: a33: add operating-points-v2 property to all nodes
> ARM: sun8i: a33: add all operating points
> ARM: dts: sun8i: sina33: add cpu-supply
> Documentation: DT: bindings: mfd: add A33 GPADC binding
> Documentation: DT: bindings: input: touschcreen: remove sun4i
> documentation
> iio: adc: sun4i-gpadc-iio: move code used in MFD probing to new
> function
> iio: adc: sun4i-gpadc-iio: add support for A33 thermal sensor
> ARM: dtsi: sun8i: a33: add thermal sensor
> ARM: dtsi: sun8i: a33: add CPU thermal throttling
> ARM: sun8i: sina33: add highest OPP of CPUs
>
> .../touchscreen/sun4i.txt => mfd/sun4i-gpadc.txt} | 21 +++
> arch/arm/boot/dts/sun8i-a23-a33.dtsi | 1 +
> arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 18 +++
> arch/arm/boot/dts/sun8i-a33.dtsi | 141 +++++++++++++++++
> drivers/iio/adc/Kconfig | 2 +-
> drivers/iio/adc/sun4i-gpadc-iio.c | 170 +++++++++++++++++----
> include/linux/mfd/sun4i-gpadc.h | 4 +
> 7 files changed, 324 insertions(+), 33 deletions(-)
> rename Documentation/devicetree/bindings/{input/touchscreen/sun4i.txt => mfd/sun4i-gpadc.txt} (64%)
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 5/7] mfd: Add Device Tree bindings document for TI tps6105x chip
From: Lee Jones @ 2017-04-04 8:27 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, devicetree, Rob Herring, Mark Rutland
In-Reply-To: <b1118a87-9b39-bb04-d43e-f8f2b366904b@osg.samsung.com>
On Mon, 03 Apr 2017, Javier Martinez Canillas wrote:
> Hello Lee,
>
> On 04/03/2017 07:15 AM, Lee Jones wrote:
>
> [snip]
>
> >> +
> >> +The TP61050/TPS61052 is a high-power "white LED driver". This boost converter
> >> +is also used for other things than white LEDs, and also contains a GPIO pin.
> >
> > What functions does it offer?
> >
>
> Same comment than before, I'm not really familiar with this driver. But I'll
> look what are the MFD cell instantiated to better understand dev functions
> and expand this documentation accordingly.
Writing documentation for H/W you are unfamiliar with is a bad idea IMHO.
--
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 v2 09/13] ARM64: dts: meson-gx: Add support for HDMI output
From: Neil Armstrong @ 2017-04-04 8:10 UTC (permalink / raw)
To: airlied-cv59FeDIM0c
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490109950-21421-10-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 03/21/2017 04:25 PM, Neil Armstrong wrote:
> Add HDMI output and connector nodes.
>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 39 ++++++++++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 32 ++++++++++++++++++
> .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 23 +++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 23 +++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 12 +++++++
> .../dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts | 23 +++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 13 ++++++++
> .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 23 +++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 3 ++
> 9 files changed, 191 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> index 7a078be..a84e276 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> @@ -98,6 +98,27 @@
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> +
> + hdmi-connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_tx_tmds_out>;
> + };
> + };
> + };
> };
>
> /* This UART is brought out to the DB9 connector */
> @@ -188,3 +209,21 @@
> ðmac {
> status = "okay";
> };
> +
> +&cvbs_vdac_port {
> + cvbs_vdac_out: endpoint {
> + remote-endpoint = <&cvbs_connector_in>;
> + };
> +};
> +
> +&hdmi_tx {
> + status = "okay";
> + pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&hdmi_tx_tmds_port {
> + hdmi_tx_tmds_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> index 94c6f95..0dda058 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -465,6 +465,38 @@
> cvbs_vdac_port: port@0 {
> reg = <0>;
> };
> +
> + /* HDMI-TX output port */
> + hdmi_tx_port: port@1 {
> + reg = <1>;
> +
> + hdmi_tx_out: endpoint {
> + remote-endpoint = <&hdmi_tx_in>;
> + };
> + };
> + };
> +
> + hdmi_tx: hdmi-tx@c883a000 {
> + compatible = "amlogic,meson-gx-dw-hdmi";
> + reg = <0x0 0xc883a000 0x0 0x1c>;
> + interrupts = <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> +
> + /* VPU VENC Input */
> + hdmi_tx_venc_port: port@0 {
> + reg = <0>;
> +
> + hdmi_tx_in: endpoint {
> + remote-endpoint = <&hdmi_tx_out>;
> + };
> + };
> +
> + /* TMDS Output */
> + hdmi_tx_tmds_port: port@1 {
> + reg = <1>;
> + };
> };
> };
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> index 4cbd626..a2c999f 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> @@ -152,6 +152,17 @@
> };
> };
> };
> +
> + hdmi-connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_tx_tmds_out>;
> + };
> + };
> + };
> };
>
> &uart_AO {
> @@ -245,3 +256,15 @@
> remote-endpoint = <&cvbs_connector_in>;
> };
> };
> +
> +&hdmi_tx {
> + status = "okay";
> + pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&hdmi_tx_tmds_port {
> + hdmi_tx_tmds_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> index 4a96e0f..1c96fc8 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -135,6 +135,17 @@
> };
> };
> };
> +
> + hdmi-connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_tx_tmds_out>;
> + };
> + };
> + };
> };
>
> /* This UART is brought out to the DB9 connector */
> @@ -250,3 +261,15 @@
> remote-endpoint = <&cvbs_connector_in>;
> };
> };
> +
> +&hdmi_tx {
> + status = "okay";
> + pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&hdmi_tx_tmds_port {
> + hdmi_tx_tmds_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index 04b3324..9716e65 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -524,3 +524,15 @@
> &vpu {
> compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
> };
> +
> +&hdmi_tx {
> + compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
> + resets = <&reset RESET_HDMITX_CAPB3>,
> + <&reset RESET_HDMI_SYSTEM_RESET>,
> + <&reset RESET_HDMI_TX>;
> + reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
> + clocks = <&clkc CLKID_HDMI_PCLK>,
> + <&clkc CLKID_CLK81>,
> + <&clkc CLKID_GCLK_VENCI_INT0>;
> + clock-names = "isfr", "iahb", "venci";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
> index cea4a3e..8873c05 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
> @@ -127,6 +127,17 @@
> };
> };
> };
> +
> + hdmi-connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_tx_tmds_out>;
> + };
> + };
> + };
> };
>
> &uart_AO {
> @@ -219,3 +230,15 @@
> remote-endpoint = <&cvbs_connector_in>;
> };
> };
> +
> +&hdmi_tx {
> + status = "okay";
> + pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&hdmi_tx_tmds_port {
> + hdmi_tx_tmds_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> index fe11b5f..9dcac25 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -44,6 +44,7 @@
> #include "meson-gx.dtsi"
> #include <dt-bindings/clock/gxbb-clkc.h>
> #include <dt-bindings/gpio/meson-gxl-gpio.h>
> +#include <dt-bindings/reset/amlogic,meson-gxbb-reset.h>
>
> / {
> compatible = "amlogic,meson-gxl";
> @@ -381,3 +382,15 @@
> &vpu {
> compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
> };
> +
> +&hdmi_tx {
> + compatible = "amlogic,meson-gxl-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
> + resets = <&reset RESET_HDMITX_CAPB3>,
> + <&reset RESET_HDMI_SYSTEM_RESET>,
> + <&reset RESET_HDMI_TX>;
> + reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
> + clocks = <&clkc CLKID_HDMI_PCLK>,
> + <&clkc CLKID_CLK81>,
> + <&clkc CLKID_GCLK_VENCI_INT0>;
> + clock-names = "isfr", "iahb", "venci";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> index 5a337d3..0e68c62e 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -100,6 +100,17 @@
> };
> };
> };
> +
> + hdmi-connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_tx_tmds_out>;
> + };
> + };
> + };
> };
>
> /* This UART is brought out to the DB9 connector */
> @@ -183,3 +194,15 @@
> remote-endpoint = <&cvbs_connector_in>;
> };
> };
> +
> +&hdmi_tx {
> + status = "okay";
> + pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&hdmi_tx_tmds_port {
> + hdmi_tx_tmds_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> index ddea730..fe451cc 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> @@ -130,3 +130,6 @@
> compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
> };
>
> +&hdmi_tx {
> + compatible = "amlogic,meson-gxm-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
> +};
>
Hi Kevin,
Please take this one for the amlogic arm-soc DT tree.
It may need a rebase, please tell me then I'll repost this one rebased on your 4.12/dt64 branch.
Thanks,
Neil
--
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] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Michael Hennerich @ 2017-04-04 7:50 UTC (permalink / raw)
To: Peter Rosin, wsa, robh+dt, mark.rutland, linus.walleij
Cc: linux-i2c, devicetree, linux-gpio, linux-kernel
In-Reply-To: <0d4c068f-d909-64be-421d-4500da7ebd4c@axentia.se>
On 31.03.2017 17:29, Peter Rosin wrote:
> Hi!
>
> Sorry for my incremental reviewing...
>
> There's a question for the gpio people below that I would like
> to have some confirmation on. Thanks!
Hi Peter,
Please find comments in-line.
>
> On 2017-03-29 12:15, michael.hennerich@analog.com wrote:
>> 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.
>> ---
>> .../devicetree/bindings/i2c/i2c-mux-ltc4306.txt | 61 ++++
>> MAINTAINERS | 8 +
>> drivers/i2c/muxes/Kconfig | 10 +
>> drivers/i2c/muxes/Makefile | 1 +
>> drivers/i2c/muxes/i2c-mux-ltc4306.c | 367 +++++++++++++++++++++
>> 5 files changed, 447 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
>> create mode 100644 drivers/i2c/muxes/i2c-mux-ltc4306.c
>>
>> 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>;
>> + };
>> + };
>> + };
>> 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..f501b3b 100644
>> --- a/drivers/i2c/muxes/Kconfig
>> +++ b/drivers/i2c/muxes/Kconfig
>> @@ -30,6 +30,16 @@ 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
>> + help
>> + If you say yes here you get support for the LTC 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..c15a8a4
>> --- /dev/null
>> +++ b/drivers/i2c/muxes/i2c-mux-ltc4306.c
>> @@ -0,0 +1,367 @@
>> +/*
>> + * 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/device.h>
>> +#include <linux/gpio.h>
>> +#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/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)
>
> Maybe align the BIT(x) parts with a tab, like you do above...
sure
>
>> +
>> +#define LTC_GPIO_ALL_INPUT 0xC0
>> +
>> +enum ltc_type {
>> + ltc_4305,
>> + ltc_4306,
>> +};
>> +
>> +struct chip_desc {
>> + u8 nchans;
>> + u8 num_gpios;
>> +};
>> +
>> +struct ltc4306 {
>> + struct i2c_client *client;
>> + struct gpio_desc *en_gpio;
>> + struct gpio_chip gpiochip;
>> + const struct chip_desc *chip;
>> + u8 regs[LTC_REG_SWITCH + 1];
>> +};
>> +
>> +/* Provide specs for the PCA954x types we know about */
>> +static const struct chip_desc chips[] = {
>> + [ltc_4305] = {
>> + .nchans = LTC4305_MAX_NCHANS,
>> + },
>> + [ltc_4306] = {
>> + .nchans = LTC4306_MAX_NCHANS,
>> + .num_gpios = 2,
>> + },
>> +};
>> +
>> +static int ltc4306_gpio_get(struct gpio_chip *chip, unsigned int offset)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> + int ret = 0;
>
> This assignment is not needed.
right
>
>> +
>> + if (gpiochip_line_is_open_drain(chip, offset) ||
>> + (data->regs[LTC_REG_MODE] & BIT(7 - offset))) {
>
> I wonder about this open-coded register cache. So, gpio people, is there
> a guarantee from gpiolib that only one gpio_chip operation is in flight
> concurrently? Because I don't see any evidence of that. With that in
> mind, I think some locking is needed?
I thought there is a per chip mutex in the gpiolib. But I can't find
anything like this either. Since these two gpios can be used from
different internal or external users. The locking seem to be needed.
This gets us back to the regmap option. I did a quick grep, and 9 out of
205 drivers using regmap i2c, also use i2c_smbus... concurrently.
grep -Rl regmap_init_i2c ./drivers | xargs grep -l i2c_smbus_ | grep "\.c"
Mostly to work around non uniform transfer layouts.
I'll check with Mark Brown on this topic.
>
>> + /* Open Drain or Input */
>> + ret = i2c_smbus_read_byte_data(data->client, LTC_REG_CONFIG);
>> + if (ret < 0)
>> + return ret;
>> +
>> + return !!(ret & BIT(1 - offset));
>> + } else {
>> + return !!(data->regs[LTC_REG_CONFIG] & BIT(5 - offset));
>> + }
>> +}
>> +
>> +static void ltc4306_gpio_set(struct gpio_chip *chip, unsigned int offset,
>> + int value)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> +
>> + if (value)
>> + data->regs[LTC_REG_CONFIG] |= BIT(5 - offset);
>> + else
>> + data->regs[LTC_REG_CONFIG] &= ~BIT(5 - offset);
>> +
>> + i2c_smbus_write_byte_data(data->client, LTC_REG_CONFIG,
>> + data->regs[LTC_REG_CONFIG]);
>> +}
>> +
>> +static int ltc4306_gpio_direction_input(struct gpio_chip *chip,
>> + unsigned int offset)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> +
>> + data->regs[LTC_REG_MODE] |= BIT(7 - offset);
>> +
>> + return i2c_smbus_write_byte_data(data->client, LTC_REG_MODE,
>> + data->regs[LTC_REG_MODE]);
>> +}
>> +
>> +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);
>> + data->regs[LTC_REG_MODE] &= ~BIT(7 - offset);
>> +
>> + return i2c_smbus_write_byte_data(data->client, LTC_REG_MODE,
>> + data->regs[LTC_REG_MODE]);
>> +}
>> +
>> +static int ltc4306_gpio_set_config(struct gpio_chip *chip,
>> + unsigned int offset, unsigned long config)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> +
>> + switch (pinconf_to_config_param(config)) {
>> + case PIN_CONFIG_DRIVE_OPEN_DRAIN:
>> + data->regs[LTC_REG_MODE] &= ~BIT(4 - offset);
>> + break;
>> + case PIN_CONFIG_DRIVE_PUSH_PULL:
>> + data->regs[LTC_REG_MODE] |= BIT(4 - offset);
>> + break;
>> + default:
>> + return -ENOTSUPP;
>> + }
>> +
>> + return i2c_smbus_write_byte_data(data->client, LTC_REG_MODE,
>> + data->regs[LTC_REG_MODE]);
>> +}
>> +
>> +static int ltc4306_gpio_init(struct ltc4306 *data)
>> +{
>> + if (!data->chip->num_gpios)
>> + return 0;
>> +
>> + data->gpiochip.label = dev_name(&data->client->dev);
>> + data->gpiochip.base = -1;
>> + data->gpiochip.ngpio = data->chip->num_gpios;
>> + data->gpiochip.parent = &data->client->dev;
>> + data->gpiochip.can_sleep = true;
>> + 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 */
>> + data->regs[LTC_REG_MODE] |= LTC_GPIO_ALL_INPUT;
>> + i2c_smbus_write_byte_data(data->client, LTC_REG_MODE,
>> + data->regs[LTC_REG_MODE]);
>> +
>> + return devm_gpiochip_add_data(&data->client->dev,
>> + &data->gpiochip, data);
>> +}
>> +
>> +/*
>> + * Write to chip register. Don't use i2c_transfer()/i2c_smbus_xfer()
>> + * as they will try to lock the adapter a second time.
>> + */
>> +static int ltc4306_reg_write(struct i2c_adapter *adap,
>> + struct i2c_client *client, u8 reg, u8 val)
>> +{
>> + int ret;
>> +
>> + if (adap->algo->master_xfer) {
>> + struct i2c_msg msg;
>> + char buf[2];
>> +
>> + msg.addr = client->addr;
>> + msg.flags = 0;
>> + msg.len = 2;
>> + buf[0] = reg;
>> + buf[1] = val;
>> + msg.buf = buf;
>> + ret = __i2c_transfer(adap, &msg, 1);
>> + } else {
>> + union i2c_smbus_data data;
>> +
>> + data.byte = val;
>> + ret = adap->algo->smbus_xfer(adap, client->addr,
>> + client->flags,
>> + I2C_SMBUS_WRITE,
>> + reg,
>> + I2C_SMBUS_BYTE_DATA, &data);
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static int ltc4306_select_mux(struct i2c_mux_core *muxc, u32 chan)
>> +{
>> + struct ltc4306 *data = i2c_mux_priv(muxc);
>> + struct i2c_client *client = data->client;
>> + u8 regval;
>> + int ret = 0;
>> +
>> + regval = BIT(7 - chan);
>> +
>> + /* Only select the channel if its different from the last channel */
>> + if (data->regs[LTC_REG_SWITCH] != regval) {
>> + ret = ltc4306_reg_write(muxc->parent, client,
>> + LTC_REG_SWITCH, regval);
>> + data->regs[LTC_REG_SWITCH] = ret < 0 ? 0 : regval;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static int ltc4306_deselect_mux(struct i2c_mux_core *muxc, u32 chan)
>> +{
>> + struct ltc4306 *data = i2c_mux_priv(muxc);
>> + struct i2c_client *client = data->client;
>> +
>> + /* Deselect all channels */
>> + data->regs[LTC_REG_SWITCH] = 0;
>> +
>> + return ltc4306_reg_write(muxc->parent, client,
>> + LTC_REG_SWITCH, data->regs[LTC_REG_SWITCH]);
>> +}
>> +
>> +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);
>> + struct device_node *of_node = client->dev.of_node;
>> + bool idle_disconnect_dt = false;
>> + struct i2c_mux_core *muxc;
>> + struct ltc4306 *data;
>> + int num, ret;
>> +
>> + if (!i2c_check_functionality(adap, I2C_FUNC_SMBUS_BYTE_DATA))
>> + return -ENODEV;
>> +
>> + if (of_node) {
>> + idle_disconnect_dt =
>> + of_property_read_bool(of_node,
>> + "i2c-mux-idle-disconnect");
>
> If you rename the variable "disconnect" or something similar and
> shorter, you can avoid the interesting indentation.
ok
>
>> + }
>> +
>> + muxc = i2c_mux_alloc(adap, &client->dev,
>> + LTC4306_MAX_NCHANS, sizeof(*data), 0,
>> + ltc4306_select_mux, idle_disconnect_dt ?
>> + ltc4306_deselect_mux : NULL);
>> + if (!muxc)
>> + return -ENOMEM;
>> + data = i2c_mux_priv(muxc);
>> +
>> + i2c_set_clientdata(client, muxc);
>> + data->client = client;
>> +
>> + /* Enable the mux if an enable GPIO is specified. */
>> + data->en_gpio = devm_gpiod_get_optional(&client->dev, "enable",
>> + GPIOD_OUT_HIGH);
>> + if (IS_ERR(data->en_gpio))
>> + return PTR_ERR(data->en_gpio);
>> +
>> + /*
>> + * Write the mux register at addr to verify
>> + * that the mux is in fact present. This also
>> + * initializes the mux to disconnected state.
>> + */
>> + if (i2c_smbus_write_byte_data(client, LTC_REG_SWITCH, 0) < 0) {
>> + dev_warn(&client->dev, "probe failed\n");
>> + ret = -ENODEV;
>> + goto gpio_default;
>> + }
>> +
>> + if (of_node) {
>> + data->chip = of_device_get_match_data(&client->dev);
>> +
>> + if (of_property_read_bool(of_node,
>> + "ltc,downstream-accelerators-enable"))
>> + data->regs[LTC_REG_CONFIG] |= LTC_DOWNSTREAM_ACCL_EN;
>> +
>> + if (of_property_read_bool(of_node,
>> + "ltc,upstream-accelerators-enable"))
>> + data->regs[LTC_REG_CONFIG] |= LTC_UPSTREAM_ACCL_EN;
>> +
>> + if (i2c_smbus_write_byte_data(client, LTC_REG_CONFIG,
>> + data->regs[LTC_REG_CONFIG]) < 0) {
>> + dev_warn(&client->dev, "probe failed\n");
>> + ret = -ENODEV;
>> + goto gpio_default;
>> + }
>> + } else {
>> + data->chip = &chips[id->driver_data];
>> + }
>> +
>> + ret = ltc4306_gpio_init(data);
>> + if (ret < 0)
>> + goto gpio_default;
>> +
>> + /* Now create an adapter for each channel */
>> + for (num = 0; num < data->chip->nchans; num++) {
>> + ret = i2c_mux_add_adapter(muxc, 0, num, 0);
>> + if (ret) {
>> + dev_err(&client->dev,
>> + "failed to register multiplexed adapter %d\n",
>> + num);
>> + goto add_adapter_failed;
>> + }
>> + }
>> +
>> + dev_info(&client->dev,
>> + "registered %d multiplexed busses for I2C switch %s\n",
>> + num, client->name);
>> +
>> + return 0;
>> +
>> +add_adapter_failed:
>> + i2c_mux_del_adapters(muxc);
>> +gpio_default:
>> + gpiod_direction_input(data->en_gpio);
>
> This was actually not what I had in mind when I asked about it in v1, and
> this looks a bit strange. You have no way of knowing if the pin was
> configured as input when probe was called, and I don't see code like this
> all over the place. Maybe it's is ok to not disable the chip over
> suspend/resume, I was just asking because it looked a bit strange to grab
> a pin and then forget about it. Now that I think about it some more, it's
> probably ok to do just that since it is perhaps not possible to make the
> chip draw less power by deasserting enable, but what do I know?
GPIOs are assumed by default inputs. So if you want to undo the actions
in probe. The logical consequence is to move them back to inputs, and
let the external PULL-UP or PULL-DOWN on the ENABLE decide what happens.
I would also prefer to leave it enabled, so that the GPIOs can retain
it's last state. Well I think the device draws a bit less power when
disabled. But we don't support runtime PM anyways.
>
> However, it might be a good idea to toggle enable and deliberately reset
> the chip in probe?
Will do.
>
> Cheers,
> peda
>
>> + return ret;
>> +}
>> +
>> +static int ltc4306_remove(struct i2c_client *client)
>> +{
>> + struct i2c_mux_core *muxc = i2c_get_clientdata(client);
>> + struct ltc4306 *data = i2c_mux_priv(muxc);
>> +
>> + i2c_mux_del_adapters(muxc);
>> + gpiod_direction_input(data->en_gpio);
>> +
>> + 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");
>>
>
>
--
Greetings,
Michael
--
Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München
Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Peter Kolberg, Ali Raza Husain, Eileen Wynne
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: Document the STM32 QSPI bindings
From: Ludovic BARRE @ 2017-04-04 7:28 UTC (permalink / raw)
To: Rob Herring
Cc: Cyrille Pitchen, Marek Vasut, David Woodhouse, Brian Norris,
Boris Brezillon, Richard Weinberger, Alexandre Torgue,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170403165735.sopfhlxzefkzrbfh@rob-hp-laptop>
Hi Rob
thanks for review
my comments below
br
Ludo
On 04/03/2017 06:57 PM, Rob Herring wrote:
> On Fri, Mar 31, 2017 at 07:02:03PM +0200, Ludovic Barre wrote:
>> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>>
>> This patch adds documentation of device tree bindings for the STM32
>> QSPI controller.
>>
>> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>> ---
>> .../devicetree/bindings/mtd/stm32-quadspi.txt | 45 ++++++++++++++++++++++
>> 1 file changed, 45 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/stm32-quadspi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/stm32-quadspi.txt b/Documentation/devicetree/bindings/mtd/stm32-quadspi.txt
>> new file mode 100644
>> index 0000000..95a8ebd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/stm32-quadspi.txt
>> @@ -0,0 +1,45 @@
>> +* STMicroelectronics Quad Serial Peripheral Interface(QuadSPI)
>> +
>> +Required properties:
>> +- compatible: should be "st,stm32f469-qspi"
>> +- reg: contains the register location and length.
>> + (optional) the memory mapping address and length
> Why optional? Either the h/w has it or doesn't. If some chips don't,
> they should have a different compatible string.
in fact, the stm32 qspi controller can operate in any of the following
modes:
-indirect mode: all the operations are performed using the qspi registers
with read/write.
-read memory-mapped mode: the external Flash memory is mapped to the
microcontroller address space and is seen by the system as if it was
an internal memory (use memcpy_fromio). this mode improve read throughput
if qspi_mm is defined the qspi controller use read memory-mapped mode
else the controller transfers in indirect mode.
>> +- reg-names: list of the names corresponding to the previous register
>> + Should contain "qspi" to register location
>> + (optional) "qspi_mm" if read in memory map mode (improve read throughput)
>> +- interrupts: should contain the interrupt for the device
>> +- clocks: the phandle of the clock needed by the QSPI controller
>> +- A pinctrl must be defined to set pins in mode of operation for QSPI transfer
>> +
>> +Optional properties:
>> +- resets: must contain the phandle to the reset controller.
>> +
>> +A spi flash must be a child of the nor_flash node and could have some
>> +properties. Also see jedec,spi-nor.txt.
>> +
>> +Required properties:
>> +- reg: chip-Select number (QSPI controller may connect 2 nor flashes)
>> +- spi-max-frequency: max frequency of spi bus
>> +
>> +Optional property:
>> +- spi-rx-bus-width: the bus width (number of data wires)
> Just "see ../spi/spi-bus.txt" for the description
ok
>
>> +
>> +Example:
>> +
>> +qspi: qspi@a0001000 {
> spi@...
ok
>> + compatible = "st,stm32f469-qspi";
>> + reg = <0xa0001000 0x1000>, <0x90000000 0x10000000>;
>> + reg-names = "qspi", "qspi_mm";
>> + interrupts = <91>;
>> + resets = <&rcc STM32F4_AHB3_RESET(QSPI)>;
>> + clocks = <&rcc 0 STM32F4_AHB3_CLOCK(QSPI)>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_qspi0>;
>> +
>> + flash@0 {
>> + reg = <0>;
>> + spi-rx-bus-width = <4>;
>> + spi-max-frequency = <108000000>;
>> + ...
>> + };
>> +};
>> --
>> 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 1/4] input: misc: introduce Atmel PTC driver
From: Ludovic Desroches @ 2017-04-04 6:47 UTC (permalink / raw)
To: Alexandre Belloni
Cc: devicetree, dmitry.torokhov, linux-kernel, Ludovic Desroches,
Ludovic Desroches, linux-input, linux-arm-kernel
In-Reply-To: <20170403155840.vln4wg56iunrmdcw@piout.net>
On Mon, Apr 03, 2017 at 05:58:40PM +0200, Alexandre Belloni wrote:
> On 31/03/2017 at 17:22:47 +0200, Ludovic Desroches wrote:
> > From: Ludovic Desroches <ludovic.desroches@atmel.com>
>
> I think you probably want to switch to your microchip email.
>
> Also, this requires a proper commit message.
I'll fix this, I'll take the cover letter as commit message and update
the mail address.
>
> >
> > Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> > +struct atmel_ptc {
> > + void __iomem *ppp_regs;
> > + void __iomem *firmware;
> > + int irq;
> > + uint8_t imr;
> > + volatile struct atmel_qtm_mailbox __iomem *qtm_mb;
> > + struct clk *clk_per;
> > + struct clk *clk_int_osc;
> > + struct clk *clk_slow;
> > + struct device *dev;
> > + struct completion ppp_ack;
> > + unsigned int button_keycode[ATMEL_PTC_MAX_NODES];
> > + struct input_dev *buttons_input;
> > + struct input_dev *scroller_input[ATMEL_PTC_MAX_SCROLLERS];
> > + bool buttons_registered;
> > + bool scroller_registered[ATMEL_PTC_MAX_SCROLLERS];
> > + uint32_t button_event[ATMEL_PTC_MAX_NODES/32];
> > + uint32_t button_state[ATMEL_PTC_MAX_NODES/32];
> > + uint32_t scroller_event;
> > + uint32_t scroller_state;
>
> You should use u8, u16 and u32 instead of uint8_t, uint16_t and
> uint32_t.
Do you want me to also change the atmel_ptc.h header and use __u8 and co?
Since I share it with bare metal software, uintxx_t was more convenient.
>
> > diff --git a/include/uapi/linux/atmel_ptc.h b/include/uapi/linux/atmel_ptc.h
> > new file mode 100644
> > index 0000000..d15c4df
> > --- /dev/null
> > +++ b/include/uapi/linux/atmel_ptc.h
>
>
> Is there any sample application showing how to configure the PTC?
>
Tooling and examples are in development.
The tool allows you to produce the atmel_ptc.conf binary or to tweak the
configuration in real time with commands such as:
- set node_group_conf count 10
- get node_config 0
- dump_conf
- export_conf atmel_ptc.conf
The application only use input devices.
Ludovic
^ permalink raw reply
* [RESEND PATCH v4] iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
From: Quentin Schulz @ 2017-04-04 6:34 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
battery voltage, battery charge and discharge currents, AC-in and VBUS
voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
This adds support for most of AXP20X and AXP22X ADCs.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Reviewed-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Lee, could you merge this through the mfd tree please?
=> https://lkml.org/lkml/2017/3/22/47
v4:
- added missing space at the beginning of a comment,
- tidied axp20x_adc_offset_voltage and axp20x_write_raw to use switch case
instead of if conditions,
- added MODULE_DEVICE_TABLE for axp20x_adc_id_match for module autoloading,
- merged two lines in axp20x_remove,
v3:
- moved from switch to if condition in axp20x_adc_raw and
axp22x_adc_raw,
- removed DT support as DT node has been dropped,
- use of platform_device_id
- correctly defined the name of the iio device (name used to probe the
driver),
- added goto for errors in probe,
- added iio_map_array_unregister to the remove function,
v2:
- removed unused defines,
- changed BIT(x) to 1 << x when describing bits purpose for which 2 <<
x or 3 << x exists, to be consistent,
- changed ADC rate defines to macro formulas,
- reordered IIO channels, now different measures (current/voltage) of
the same part of the PMIC (e.g. battery), have the same IIO channel in
their respective IIO type. When a part of the PMIC have only one
measure, a number is jumped,
- left IIO channel mapping in DT to use iio_map structure,
- removed indexing of ADC internal temperature,
- removed unused iio_dev structure in axp20x_adc_iio,
- added a structure for data specific to AXP20X or AXP22X PMICs instead
of using an ID and an if condition when needing to separate the
behaviour of both,
- added a comment on batt_chrg_i really being on 12bits rather than
what the Chinese datasheets say (13 bits),
- corrected the offset for AXP22X PMIC temperature,
- set the ADC rate to a value (100Hz) shared by the AXP20X and AXP22X,
- created macro formulas to compute the ADC rate for each,
- added a condition on presence of ADC_EN2 reg before setting/resetting
it,
- switched from devm_iio_device_unregister to the non-devm function
because of the need for a remove function,
- removed some dead code,
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/axp20x_adc.c | 617 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 628 insertions(+)
create mode 100644 drivers/iio/adc/axp20x_adc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index d777a97..d15e1bd 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -154,6 +154,16 @@ config AT91_SAMA5D2_ADC
To compile this driver as a module, choose M here: the module will be
called at91-sama5d2_adc.
+config AXP20X_ADC
+ tristate "X-Powers AXP20X and AXP22X ADC driver"
+ depends on MFD_AXP20X
+ help
+ Say yes here to have support for X-Powers power management IC (PMIC)
+ AXP20X and AXP22X ADC devices.
+
+ To compile this driver as a module, choose M here: the module will be
+ called axp20x_adc.
+
config AXP288_ADC
tristate "X-Powers AXP288 ADC driver"
depends on MFD_AXP20X
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index b11bb57..17899b5 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
obj-$(CONFIG_AD799X) += ad799x.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
obj-$(CONFIG_AT91_SAMA5D2_ADC) += at91-sama5d2_adc.o
+obj-$(CONFIG_AXP20X_ADC) += axp20x_adc.o
obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
obj-$(CONFIG_BCM_IPROC_ADC) += bcm_iproc_adc.o
obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c
new file mode 100644
index 0000000..11e1771
--- /dev/null
+++ b/drivers/iio/adc/axp20x_adc.c
@@ -0,0 +1,617 @@
+/* ADC driver for AXP20X and AXP22X PMICs
+ *
+ * Copyright (c) 2016 Free Electrons NextThing Co.
+ * Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation.
+ */
+
+#include <linux/completion.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/thermal.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/driver.h>
+#include <linux/iio/machine.h>
+#include <linux/mfd/axp20x.h>
+
+#define AXP20X_ADC_EN1_MASK GENMASK(7, 0)
+
+#define AXP20X_ADC_EN2_MASK (GENMASK(3, 2) | BIT(7))
+#define AXP22X_ADC_EN1_MASK (GENMASK(7, 5) | BIT(0))
+
+#define AXP20X_GPIO10_IN_RANGE_GPIO0 BIT(0)
+#define AXP20X_GPIO10_IN_RANGE_GPIO1 BIT(1)
+#define AXP20X_GPIO10_IN_RANGE_GPIO0_VAL(x) ((x) & BIT(0))
+#define AXP20X_GPIO10_IN_RANGE_GPIO1_VAL(x) (((x) & BIT(0)) << 1)
+
+#define AXP20X_ADC_RATE_MASK GENMASK(7, 6)
+#define AXP20X_ADC_RATE_HZ(x) ((ilog2((x) / 25) << 6) & AXP20X_ADC_RATE_MASK)
+#define AXP22X_ADC_RATE_HZ(x) ((ilog2((x) / 100) << 6) & AXP20X_ADC_RATE_MASK)
+
+#define AXP20X_ADC_CHANNEL(_channel, _name, _type, _reg) \
+ { \
+ .type = _type, \
+ .indexed = 1, \
+ .channel = _channel, \
+ .address = _reg, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE), \
+ .datasheet_name = _name, \
+ }
+
+#define AXP20X_ADC_CHANNEL_OFFSET(_channel, _name, _type, _reg) \
+ { \
+ .type = _type, \
+ .indexed = 1, \
+ .channel = _channel, \
+ .address = _reg, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE) |\
+ BIT(IIO_CHAN_INFO_OFFSET),\
+ .datasheet_name = _name, \
+ }
+
+struct axp_data;
+
+struct axp20x_adc_iio {
+ struct regmap *regmap;
+ struct axp_data *data;
+};
+
+enum axp20x_adc_channel_v {
+ AXP20X_ACIN_V = 0,
+ AXP20X_VBUS_V,
+ AXP20X_TS_IN,
+ AXP20X_GPIO0_V,
+ AXP20X_GPIO1_V,
+ AXP20X_IPSOUT_V,
+ AXP20X_BATT_V,
+};
+
+enum axp20x_adc_channel_i {
+ AXP20X_ACIN_I = 0,
+ AXP20X_VBUS_I,
+ AXP20X_BATT_CHRG_I,
+ AXP20X_BATT_DISCHRG_I,
+};
+
+enum axp22x_adc_channel_v {
+ AXP22X_TS_IN = 0,
+ AXP22X_BATT_V,
+};
+
+enum axp22x_adc_channel_i {
+ AXP22X_BATT_CHRG_I = 1,
+ AXP22X_BATT_DISCHRG_I,
+};
+
+static struct iio_map axp20x_maps[] = {
+ {
+ .consumer_dev_name = "axp20x-usb-power-supply",
+ .consumer_channel = "vbus_v",
+ .adc_channel_label = "vbus_v",
+ }, {
+ .consumer_dev_name = "axp20x-usb-power-supply",
+ .consumer_channel = "vbus_i",
+ .adc_channel_label = "vbus_i",
+ }, {
+ .consumer_dev_name = "axp20x-ac-power-supply",
+ .consumer_channel = "acin_v",
+ .adc_channel_label = "acin_v",
+ }, {
+ .consumer_dev_name = "axp20x-ac-power-supply",
+ .consumer_channel = "acin_i",
+ .adc_channel_label = "acin_i",
+ }, {
+ .consumer_dev_name = "axp20x-battery-power-supply",
+ .consumer_channel = "batt_v",
+ .adc_channel_label = "batt_v",
+ }, {
+ .consumer_dev_name = "axp20x-battery-power-supply",
+ .consumer_channel = "batt_chrg_i",
+ .adc_channel_label = "batt_chrg_i",
+ }, {
+ .consumer_dev_name = "axp20x-battery-power-supply",
+ .consumer_channel = "batt_dischrg_i",
+ .adc_channel_label = "batt_dischrg_i",
+ }, { /* sentinel */ }
+};
+
+static struct iio_map axp22x_maps[] = {
+ {
+ .consumer_dev_name = "axp20x-battery-power-supply",
+ .consumer_channel = "batt_v",
+ .adc_channel_label = "batt_v",
+ }, {
+ .consumer_dev_name = "axp20x-battery-power-supply",
+ .consumer_channel = "batt_chrg_i",
+ .adc_channel_label = "batt_chrg_i",
+ }, {
+ .consumer_dev_name = "axp20x-battery-power-supply",
+ .consumer_channel = "batt_dischrg_i",
+ .adc_channel_label = "batt_dischrg_i",
+ }, { /* sentinel */ }
+};
+
+/*
+ * Channels are mapped by physical system. Their channels share the same index.
+ * i.e. acin_i is in_current0_raw and acin_v is in_voltage0_raw.
+ * The only exception is for the battery. batt_v will be in_voltage6_raw and
+ * charge current in_current6_raw and discharge current will be in_current7_raw.
+ */
+static const struct iio_chan_spec axp20x_adc_channels[] = {
+ AXP20X_ADC_CHANNEL(AXP20X_ACIN_V, "acin_v", IIO_VOLTAGE,
+ AXP20X_ACIN_V_ADC_H),
+ AXP20X_ADC_CHANNEL(AXP20X_ACIN_I, "acin_i", IIO_CURRENT,
+ AXP20X_ACIN_I_ADC_H),
+ AXP20X_ADC_CHANNEL(AXP20X_VBUS_V, "vbus_v", IIO_VOLTAGE,
+ AXP20X_VBUS_V_ADC_H),
+ AXP20X_ADC_CHANNEL(AXP20X_VBUS_I, "vbus_i", IIO_CURRENT,
+ AXP20X_VBUS_I_ADC_H),
+ {
+ .type = IIO_TEMP,
+ .address = AXP20X_TEMP_ADC_H,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE) |
+ BIT(IIO_CHAN_INFO_OFFSET),
+ .datasheet_name = "pmic_temp",
+ },
+ AXP20X_ADC_CHANNEL_OFFSET(AXP20X_GPIO0_V, "gpio0_v", IIO_VOLTAGE,
+ AXP20X_GPIO0_V_ADC_H),
+ AXP20X_ADC_CHANNEL_OFFSET(AXP20X_GPIO1_V, "gpio1_v", IIO_VOLTAGE,
+ AXP20X_GPIO1_V_ADC_H),
+ AXP20X_ADC_CHANNEL(AXP20X_IPSOUT_V, "ipsout_v", IIO_VOLTAGE,
+ AXP20X_IPSOUT_V_HIGH_H),
+ AXP20X_ADC_CHANNEL(AXP20X_BATT_V, "batt_v", IIO_VOLTAGE,
+ AXP20X_BATT_V_H),
+ AXP20X_ADC_CHANNEL(AXP20X_BATT_CHRG_I, "batt_chrg_i", IIO_CURRENT,
+ AXP20X_BATT_CHRG_I_H),
+ AXP20X_ADC_CHANNEL(AXP20X_BATT_DISCHRG_I, "batt_dischrg_i", IIO_CURRENT,
+ AXP20X_BATT_DISCHRG_I_H),
+};
+
+static const struct iio_chan_spec axp22x_adc_channels[] = {
+ {
+ .type = IIO_TEMP,
+ .address = AXP22X_PMIC_TEMP_H,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE) |
+ BIT(IIO_CHAN_INFO_OFFSET),
+ .datasheet_name = "pmic_temp",
+ },
+ AXP20X_ADC_CHANNEL(AXP22X_BATT_V, "batt_v", IIO_VOLTAGE,
+ AXP20X_BATT_V_H),
+ AXP20X_ADC_CHANNEL(AXP22X_BATT_CHRG_I, "batt_chrg_i", IIO_CURRENT,
+ AXP20X_BATT_CHRG_I_H),
+ AXP20X_ADC_CHANNEL(AXP22X_BATT_DISCHRG_I, "batt_dischrg_i", IIO_CURRENT,
+ AXP20X_BATT_DISCHRG_I_H),
+};
+
+static int axp20x_adc_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val)
+{
+ struct axp20x_adc_iio *info = iio_priv(indio_dev);
+ int size = 12;
+
+ /*
+ * N.B.: Unlike the Chinese datasheets tell, the charging current is
+ * stored on 12 bits, not 13 bits. Only discharging current is on 13
+ * bits.
+ */
+ if (chan->type == IIO_CURRENT && chan->channel == AXP20X_BATT_DISCHRG_I)
+ size = 13;
+ else
+ size = 12;
+
+ *val = axp20x_read_variable_width(info->regmap, chan->address, size);
+ if (*val < 0)
+ return *val;
+
+ return IIO_VAL_INT;
+}
+
+static int axp22x_adc_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val)
+{
+ struct axp20x_adc_iio *info = iio_priv(indio_dev);
+ int size;
+
+ /*
+ * N.B.: Unlike the Chinese datasheets tell, the charging current is
+ * stored on 12 bits, not 13 bits. Only discharging current is on 13
+ * bits.
+ */
+ if (chan->type == IIO_CURRENT && chan->channel == AXP22X_BATT_DISCHRG_I)
+ size = 13;
+ else
+ size = 12;
+
+ *val = axp20x_read_variable_width(info->regmap, chan->address, size);
+ if (*val < 0)
+ return *val;
+
+ return IIO_VAL_INT;
+}
+
+static int axp20x_adc_scale_voltage(int channel, int *val, int *val2)
+{
+ switch (channel) {
+ case AXP20X_ACIN_V:
+ case AXP20X_VBUS_V:
+ *val = 1;
+ *val2 = 700000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AXP20X_GPIO0_V:
+ case AXP20X_GPIO1_V:
+ *val = 0;
+ *val2 = 500000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AXP20X_BATT_V:
+ *val = 1;
+ *val2 = 100000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AXP20X_IPSOUT_V:
+ *val = 1;
+ *val2 = 400000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static int axp20x_adc_scale_current(int channel, int *val, int *val2)
+{
+ switch (channel) {
+ case AXP20X_ACIN_I:
+ *val = 0;
+ *val2 = 625000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AXP20X_VBUS_I:
+ *val = 0;
+ *val2 = 375000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AXP20X_BATT_DISCHRG_I:
+ case AXP20X_BATT_CHRG_I:
+ *val = 0;
+ *val2 = 500000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static int axp20x_adc_scale(struct iio_chan_spec const *chan, int *val,
+ int *val2)
+{
+ switch (chan->type) {
+ case IIO_VOLTAGE:
+ return axp20x_adc_scale_voltage(chan->channel, val, val2);
+
+ case IIO_CURRENT:
+ return axp20x_adc_scale_current(chan->channel, val, val2);
+
+ case IIO_TEMP:
+ *val = 100;
+ return IIO_VAL_INT;
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static int axp22x_adc_scale(struct iio_chan_spec const *chan, int *val,
+ int *val2)
+{
+ switch (chan->type) {
+ case IIO_VOLTAGE:
+ if (chan->channel != AXP22X_BATT_V)
+ return -EINVAL;
+
+ *val = 1;
+ *val2 = 100000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case IIO_CURRENT:
+ *val = 0;
+ *val2 = 500000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case IIO_TEMP:
+ *val = 100;
+ return IIO_VAL_INT;
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static int axp20x_adc_offset_voltage(struct iio_dev *indio_dev, int channel,
+ int *val)
+{
+ struct axp20x_adc_iio *info = iio_priv(indio_dev);
+ int ret;
+
+ ret = regmap_read(info->regmap, AXP20X_GPIO10_IN_RANGE, val);
+ if (ret < 0)
+ return ret;
+
+ switch (channel) {
+ case AXP20X_GPIO0_V:
+ *val &= AXP20X_GPIO10_IN_RANGE_GPIO0;
+ break;
+
+ case AXP20X_GPIO1_V:
+ *val &= AXP20X_GPIO10_IN_RANGE_GPIO1;
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ *val = !!(*val) * 700000;
+
+ return IIO_VAL_INT;
+}
+
+static int axp20x_adc_offset(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val)
+{
+ switch (chan->type) {
+ case IIO_VOLTAGE:
+ return axp20x_adc_offset_voltage(indio_dev, chan->channel, val);
+
+ case IIO_TEMP:
+ *val = -1447;
+ return IIO_VAL_INT;
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static int axp20x_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val,
+ int *val2, long mask)
+{
+ switch (mask) {
+ case IIO_CHAN_INFO_OFFSET:
+ return axp20x_adc_offset(indio_dev, chan, val);
+
+ case IIO_CHAN_INFO_SCALE:
+ return axp20x_adc_scale(chan, val, val2);
+
+ case IIO_CHAN_INFO_RAW:
+ return axp20x_adc_raw(indio_dev, chan, val);
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static int axp22x_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val,
+ int *val2, long mask)
+{
+ switch (mask) {
+ case IIO_CHAN_INFO_OFFSET:
+ *val = -2677;
+ return IIO_VAL_INT;
+
+ case IIO_CHAN_INFO_SCALE:
+ return axp22x_adc_scale(chan, val, val2);
+
+ case IIO_CHAN_INFO_RAW:
+ return axp22x_adc_raw(indio_dev, chan, val);
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static int axp20x_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int val, int val2,
+ long mask)
+{
+ struct axp20x_adc_iio *info = iio_priv(indio_dev);
+ unsigned int reg, regval;
+
+ /*
+ * The AXP20X PMIC allows the user to choose between 0V and 0.7V offsets
+ * for (independently) GPIO0 and GPIO1 when in ADC mode.
+ */
+ if (mask != IIO_CHAN_INFO_OFFSET)
+ return -EINVAL;
+
+ if (val != 0 && val != 700000)
+ return -EINVAL;
+
+ switch (chan->channel) {
+ case AXP20X_GPIO0_V:
+ reg = AXP20X_GPIO10_IN_RANGE_GPIO0;
+ regval = AXP20X_GPIO10_IN_RANGE_GPIO0_VAL(!!val);
+ break;
+
+ case AXP20X_GPIO1_V:
+ reg = AXP20X_GPIO10_IN_RANGE_GPIO1;
+ regval = AXP20X_GPIO10_IN_RANGE_GPIO1_VAL(!!val);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return regmap_update_bits(info->regmap, AXP20X_GPIO10_IN_RANGE, reg,
+ regval);
+}
+
+static const struct iio_info axp20x_adc_iio_info = {
+ .read_raw = axp20x_read_raw,
+ .write_raw = axp20x_write_raw,
+ .driver_module = THIS_MODULE,
+};
+
+static const struct iio_info axp22x_adc_iio_info = {
+ .read_raw = axp22x_read_raw,
+ .driver_module = THIS_MODULE,
+};
+
+static int axp20x_adc_rate(int rate)
+{
+ return AXP20X_ADC_RATE_HZ(rate);
+}
+
+static int axp22x_adc_rate(int rate)
+{
+ return AXP22X_ADC_RATE_HZ(rate);
+}
+
+struct axp_data {
+ const struct iio_info *iio_info;
+ int num_channels;
+ struct iio_chan_spec const *channels;
+ unsigned long adc_en1_mask;
+ int (*adc_rate)(int rate);
+ bool adc_en2;
+ struct iio_map *maps;
+};
+
+static const struct axp_data axp20x_data = {
+ .iio_info = &axp20x_adc_iio_info,
+ .num_channels = ARRAY_SIZE(axp20x_adc_channels),
+ .channels = axp20x_adc_channels,
+ .adc_en1_mask = AXP20X_ADC_EN1_MASK,
+ .adc_rate = axp20x_adc_rate,
+ .adc_en2 = true,
+ .maps = axp20x_maps,
+};
+
+static const struct axp_data axp22x_data = {
+ .iio_info = &axp22x_adc_iio_info,
+ .num_channels = ARRAY_SIZE(axp22x_adc_channels),
+ .channels = axp22x_adc_channels,
+ .adc_en1_mask = AXP22X_ADC_EN1_MASK,
+ .adc_rate = axp22x_adc_rate,
+ .adc_en2 = false,
+ .maps = axp22x_maps,
+};
+
+static const struct platform_device_id axp20x_adc_id_match[] = {
+ { .name = "axp20x-adc", .driver_data = (kernel_ulong_t)&axp20x_data, },
+ { .name = "axp22x-adc", .driver_data = (kernel_ulong_t)&axp22x_data, },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, axp20x_adc_id_match);
+
+static int axp20x_probe(struct platform_device *pdev)
+{
+ struct axp20x_adc_iio *info;
+ struct iio_dev *indio_dev;
+ struct axp20x_dev *axp20x_dev;
+ int ret;
+
+ axp20x_dev = dev_get_drvdata(pdev->dev.parent);
+
+ indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ info = iio_priv(indio_dev);
+ platform_set_drvdata(pdev, indio_dev);
+
+ info->regmap = axp20x_dev->regmap;
+ indio_dev->dev.parent = &pdev->dev;
+ indio_dev->dev.of_node = pdev->dev.of_node;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ info->data = (struct axp_data *)platform_get_device_id(pdev)->driver_data;
+
+ indio_dev->name = platform_get_device_id(pdev)->name;
+ indio_dev->info = info->data->iio_info;
+ indio_dev->num_channels = info->data->num_channels;
+ indio_dev->channels = info->data->channels;
+
+ /* Enable the ADCs on IP */
+ regmap_write(info->regmap, AXP20X_ADC_EN1, info->data->adc_en1_mask);
+
+ if (info->data->adc_en2)
+ /* Enable GPIO0/1 and internal temperature ADCs */
+ regmap_update_bits(info->regmap, AXP20X_ADC_EN2,
+ AXP20X_ADC_EN2_MASK, AXP20X_ADC_EN2_MASK);
+
+ /* Configure ADCs rate */
+ regmap_update_bits(info->regmap, AXP20X_ADC_RATE, AXP20X_ADC_RATE_MASK,
+ info->data->adc_rate(100));
+
+ ret = iio_map_array_register(indio_dev, info->data->maps);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to register IIO maps: %d\n", ret);
+ goto fail_map;
+ }
+
+ ret = iio_device_register(indio_dev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "could not register the device\n");
+ goto fail_register;
+ }
+
+ return 0;
+
+fail_register:
+ iio_map_array_unregister(indio_dev);
+
+fail_map:
+ regmap_write(info->regmap, AXP20X_ADC_EN1, 0);
+
+ if (info->data->adc_en2)
+ regmap_write(info->regmap, AXP20X_ADC_EN2, 0);
+
+ return ret;
+}
+
+static int axp20x_remove(struct platform_device *pdev)
+{
+ struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+ struct axp20x_adc_iio *info = iio_priv(indio_dev);
+
+ iio_device_unregister(indio_dev);
+ iio_map_array_unregister(indio_dev);
+
+ regmap_write(info->regmap, AXP20X_ADC_EN1, 0);
+
+ if (info->data->adc_en2)
+ regmap_write(info->regmap, AXP20X_ADC_EN2, 0);
+
+ return 0;
+}
+
+static struct platform_driver axp20x_adc_driver = {
+ .driver = {
+ .name = "axp20x-adc",
+ },
+ .id_table = axp20x_adc_id_match,
+ .probe = axp20x_probe,
+ .remove = axp20x_remove,
+};
+
+module_platform_driver(axp20x_adc_driver);
+
+MODULE_DESCRIPTION("ADC driver for AXP20X and AXP22X PMICs");
+MODULE_AUTHOR("Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>");
+MODULE_LICENSE("GPL");
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v2] clk: stm32h7: Add stm32h743 clock driver
From: Gabriel Fernandez @ 2017-04-04 6:33 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree@vger.kernel.org, Daniel Thompson,
Radosław Pietrzyk, Alexandre Torgue, Arnd Bergmann,
Nicolas Pitre, Andrea Merello, Michael Turquette, Olivier Bideau,
Stephen Boyd, Russell King, linux-kernel@vger.kernel.org,
Ludovic Barre, Maxime Coquelin, Amelie Delaunay, Lee Jones,
linux-clk, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqJYu+4puvB-WhaLVtjHASVOdY0acM2OxxMpZOvG9MAziQ@mail.gmail.com>
On 04/03/2017 06:04 PM, Rob Herring wrote:
> On Mon, Apr 3, 2017 at 9:39 AM, Rob Herring <robh@kernel.org> wrote:
>> On Wed, Mar 29, 2017 at 11:08:22AM +0200, gabriel.fernandez@st.com wrote:
>>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>>
>>> This patch enables clocks for STM32H743 boards.
>>>
>>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>>>
>>> Just for the MFD changes:
>>> Acked-by: Lee Jones <lee.jones@linaro.org>
>>>
>>> +Required properties for pll node:
>>> +- compatible: Should be:
>>> + "stm32h7-pll"
>> stm,stm32h7-pll
> Err, I meant st,stm32h7-pll.
Oops, sorry i will fix it.
Thank's
Gabriel
>> With that,
>>
>> Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Michael Hennerich @ 2017-04-04 6:32 UTC (permalink / raw)
To: Peter Rosin, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <dcc59f26-6dec-dbf1-22d9-b681daf788a2-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On 03.04.2017 16:20, Peter Rosin wrote:
> On 2017-04-03 15:36, Michael Hennerich wrote:
>> On 03.04.2017 14:03, Peter Rosin wrote:
>>> On 2017-03-31 17:29, Peter Rosin wrote:
>>>> Hi!
>>>>
>>>> Sorry for my incremental reviewing...
>>>>
>>>
>>> Another incremental...
>>>
>>>> On 2017-03-29 12:15, michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org wrote:
>>>>> +
>>>>> + /* Now create an adapter for each channel */
>>>>> + for (num = 0; num < data->chip->nchans; num++) {
>>>>> + ret = i2c_mux_add_adapter(muxc, 0, num, 0);
>>>>> + if (ret) {
>>>>> + dev_err(&client->dev,
>>>>> + "failed to register multiplexed adapter %d\n",
>>>>> + num);
>>>
>>> Just a heads up, I submitted a series to remove a bunch of dev_err calls
>>> when i2c_mux_add_adapter fails. See https://lkml.org/lkml/2017/4/3/115
>>>
>>> You can remove this one as well.
>>>
>>> And please use a subject of the form:
>>> i2c: mux: ltc4306: <message>
>> ok - no problem.
>
> You managed to drop the spaces after the new colons in the subject.
>
> And maybe there is a problem, because I don't see any reaction to any of
> the review comments I made in https://lkml.org/lkml/2017/3/31/525
>
> Was that on purpose? Sure, the gpio "jury" is still out on the bigger
> question so maybe you're waiting for that, but there were a few nitpicks
> as well. Anyway, sorry again for failing to compile all comments up front.
Hi Peter,
sorry - this was not on purpose. I simply missed your second to last
incremental review. I fix the subject now finally.
Thanks for your patience.
>
>> I sent out a new patch. Per Rob's request, I split out the dt-bindings
>> into a separate patch.
>
> Thanks. I think(?) it is customary to have the bindings first, and then
> implement that "specification" in followup patches. No big deal though...
>
> Cheers,
> peda
>
>
--
Greetings,
Michael
--
Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München
Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Peter Kolberg, Ali Raza Husain, Eileen Wynne
--
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 0/5] iommu/arm-smmu: Add runtime pm/sleep support
From: Sricharan R @ 2017-04-04 5:15 UTC (permalink / raw)
To: Will Deacon, Rob Clark
Cc: Mark Rutland, devicetree@vger.kernel.org, Mathieu Poirier,
linux-arm-msm, Stephen Boyd, iommu@lists.linux-foundation.org,
Rob Herring, linux-clk, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170403172307.GI5706@arm.com>
Hi Will,
On 4/3/2017 10:53 PM, Will Deacon wrote:
> On Fri, Mar 31, 2017 at 10:58:16PM -0400, Rob Clark wrote:
>> On Fri, Mar 31, 2017 at 1:54 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Thu, Mar 09, 2017 at 09:05:43PM +0530, Sricharan R wrote:
>>>> This series provides the support for turning on the arm-smmu's
>>>> clocks/power domains using runtime pm. This is done using the
>>>> recently introduced device links patches, which lets the symmu's
>>>> runtime to follow the master's runtime pm, so the smmu remains
>>>> powered only when the masters use it.
>>>
>>> Do you have any numbers for the power savings you achieve with this?
>>> How often do we actually manage to stop the SMMU clocks on an SoC with
>>> a handful of masters?
>>>
>>> In other words, is this too coarse-grained to be useful, or is it common
>>> that all the devices upstream of the SMMU are suspended?
>>
>> well, if you think about a phone/tablet with a command mode panel,
>> pretty much all devices will be suspended most of the time ;-)
>
> Well, that's really what I was asking about. I assumed that periodic
> modem/radio transactions would keep the SMMU clocked, so would like to get a
> rough idea of the power savings achieved with this coarse-grained approach.
>
One main reason for introducing this was to enable power for
the iommus separately in those places where the iommu gets
accessed without the context of the master, pm runtime was
done to use the device links feature and also those iommus
had their power-domains to be enabled (during the iommu probe,
faults) (downstream was modelling those power-domains as
'regulators' which was not correct) and have to be clocked
as well.
I was in the process of trying to measure the power difference
that this would achieve. One concern here is, this series depends
on the device link between master and iommu.
So essentially the masters have to be pm runtime adapted fully
to use this. For my testing i was using couple of them (mdp, gpu),
by just enabling pm runtime for them, not full pm runtime though.
But i will come-up with the numbers by instrumenting little more.
The downstream code explicitly turns on the iommu clocks/regulators
in the standalone path (called without master context and after
that, lets the master to control the iommu clocks ( the iommu
clocks are populated in master DT data as well), so ensures iommu
is clocked only when really needed by the master. So number
measured from downstream should also give the power numbers in
another way.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* RE: Device Tree Binding for Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong @ 2017-04-04 3:57 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqJa6rdk=fxHVkHdjFrkBx-E6hGUfoZt2cAzaMvq2TJkNw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob,
Apologies for the mistake. Below are the bindings
From 23a9e274bb517b8e232c5aa4cf9737de1644b708 Mon Sep 17 00:00:00 2001
From: Ong, Hean Loong <hean.loong.ong@intel.com>
Date: Thu, 30 Mar 2017 17:59:37 +0800
Subject: [PATCHv0] Intel FPGA Video and Image Processing Suite device tree binding
Device tree binding for Intel FPGA Video and Image
Processing Suite. The binding involved would be generated
from the Altera (Intel) Qsys system. The bindings would
set the max width, max height, buts per pixel and memory
port width. The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as
altr.
Signed-off-by: Ong, Hean Loong <hean.loong.ong@intel.com>
---
.../devicetree/bindings/gpu/altr,vip-fb2.txt | 24 ++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
diff --git a/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt b/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
new file mode 100644
index 0000000..9ba3209
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
@@ -0,0 +1,24 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Arria 10 and above with display port IP
+
+Required properties:
+- compatible: "altr,vip-frame-buffer-2.0"
+- reg: Physical base address and length of the framebuffer controller's
+ registers.
+- max-width: The width of the framebuffer in pixels.
+- max-height: The height of the framebuffer in pixels.
+- bits-per-symbol: only "8" is currently supported
+- mem-port-width = the bus width of the avalon master port on the frame reader
+
+Example:
+
+dp_0_frame_buf: vip@0x100000280 {
+ compatible = "altr,vip-frame-buffer-2.0";
+ reg = <0x00000001 0x00000280 0x00000040>;
+ altr,max-width = <1280>;
+ altr,max-height = <720>;
+ altr,bits-per-symbol = <8>;
+ altr,mem-port-width = <128>;
+};
+
--
1.7.1
^ permalink raw reply related
* Re: [PATCHv2] phy: cpcap-usb: Add CPCAP PMIC USB support
From: Tony Lindgren @ 2017-04-04 3:27 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marcel Partap, Michael Scott
In-Reply-To: <3661b0cc-bf79-0347-ae4c-db6bdfdf6293-l0cyMroinI0@public.gmane.org>
Hi,
* Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> [170330 04:51]:
> On Monday 27 March 2017 08:35 PM, Tony Lindgren wrote:
> > Seems this can be also done when implementing PM runtime handling.
> > If you want some of these changes done for the initial patch,
> > please let me know.
>
> I think it's better we get extcon stuff in the initial patch so that we don't
> have to maintain some piece of code for legacy dt. Others can be added later.
Sure, I'll take a look at that hopefully this week at some
point.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] ARM: dts: omap4-droid4: Fix interrupt triggering for cpcap
From: Tony Lindgren @ 2017-04-04 3:25 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Charles Keepax, Marcel Partap, Michael Scott, Sebastian Reichel
The CPCAP PMIC interrupt is level high sensitive despite it being
requested as edge high triggered in the Motorola Linux kernel.
Note that also the related driver change is needed posted as
"mfd: cpcap: Fix interrupt to use level interrupt".
Fixes: 56e1d40d3bea ("mfd: cpcap: Add minimal support")
Cc: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Cc: Marcel Partap <mpartap-hi6Y0CQ0nG0@public.gmane.org>
Cc: Michael Scott <michael.scott-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi b/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi
--- a/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi
+++ b/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi
@@ -11,7 +11,7 @@
compatible = "motorola,cpcap", "st,6556002";
reg = <0>; /* cs0 */
interrupt-parent = <&gpio1>;
- interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ interrupts = <7 IRQ_TYPE_LEVEL_HIGH>;
interrupt-controller;
#interrupt-cells = <2>;
#address-cells = <1>;
--
2.12.2
--
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 v5 5/5] ARM: keystone: Drop PM domain support for k2g
From: Dave Gerlach @ 2017-04-04 2:47 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Santosh Shilimkar,
Rob Herring, Arnd Bergmann
Cc: Nishanth Menon, devicetree, Dave Gerlach, Lokesh Vutla, Keerthy,
linux-pm, linux-kernel, Tero Kristo, Russell King, Sudeep Holla,
Olof Johansson, linux-arm-kernel
In-Reply-To: <20170404024732.32699-1-d-gerlach@ti.com>
K2G will use a different power domain driver than the rest of the
keystone family in order to make use of the TI SCI protocol so prevent
the standard keystone pm_domain code from registering itself in
preparation for a new driver.
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/mach-keystone/pm_domain.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-keystone/pm_domain.c b/arch/arm/mach-keystone/pm_domain.c
index 8cbb35765a19..fe57e2692629 100644
--- a/arch/arm/mach-keystone/pm_domain.c
+++ b/arch/arm/mach-keystone/pm_domain.c
@@ -32,7 +32,9 @@ static struct pm_clk_notifier_block platform_domain_notifier = {
};
static const struct of_device_id of_keystone_table[] = {
- {.compatible = "ti,keystone"},
+ {.compatible = "ti,k2hk"},
+ {.compatible = "ti,k2e"},
+ {.compatible = "ti,k2l"},
{ /* end of list */ },
};
--
2.11.0
^ permalink raw reply related
* [PATCH v5 4/5] soc: ti: Add ti_sci_pm_domains driver
From: Dave Gerlach @ 2017-04-04 2:47 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Santosh Shilimkar,
Rob Herring, Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, linux-pm, devicetree,
Nishanth Menon, Dave Gerlach, Keerthy, Russell King, Tero Kristo,
Sudeep Holla, Olof Johansson
In-Reply-To: <20170404024732.32699-1-d-gerlach@ti.com>
Introduce a ti_sci_pm_domains driver to act as a generic pm domain
provider to allow each device to attach and associate it's ti-sci-id so
that it can be controlled through the TI SCI protocol.
This driver implements a simple genpd where each device node has a
phandle to the power domain node and also must provide an index which
represents the ID to be passed with TI SCI representing the device using
a single phandle cell. The driver manually parses the phandle to get the
cell value. Through this interface the genpd dev_ops start and stop
hooks will use TI SCI to turn on and off each device as determined by
pm_runtime usage.
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
MAINTAINERS | 1 +
arch/arm/mach-keystone/Kconfig | 1 +
drivers/soc/ti/Kconfig | 12 +++
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti_sci_pm_domains.c | 202 +++++++++++++++++++++++++++++++++++++
5 files changed, 217 insertions(+)
create mode 100644 drivers/soc/ti/ti_sci_pm_domains.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ae43f3e95b47..ca8026c39fc8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12384,6 +12384,7 @@ F: drivers/firmware/ti_sci*
F: include/linux/soc/ti/ti_sci_protocol.h
F: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
F: include/dt-bindings/genpd/k2g.h
+F: drivers/soc/ti/ti_sci_pm_domains.c
THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
M: Hans Verkuil <hverkuil@xs4all.nl>
diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index 554357035f30..db122356b410 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -10,6 +10,7 @@ config ARCH_KEYSTONE
select ARCH_SUPPORTS_BIG_ENDIAN
select ZONE_DMA if ARM_LPAE
select PINCTRL
+ select PM_GENERIC_DOMAINS if PM
help
Support for boards based on the Texas Instruments Keystone family of
SoCs.
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 3557c5e32a93..39e152abe6b9 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -38,4 +38,16 @@ config WKUP_M3_IPC
to communicate and use the Wakeup M3 for PM features like suspend
resume and boots it using wkup_m3_rproc driver.
+config TI_SCI_PM_DOMAINS
+ tristate "TI SCI PM Domains Driver"
+ depends on TI_SCI_PROTOCOL
+ depends on PM_GENERIC_DOMAINS
+ help
+ Generic power domain implementation for TI device implementing
+ the TI SCI protocol.
+
+ To compile this as a module, choose M here. The module will be
+ called ti_sci_pm_domains. Note this is needed early in boot before
+ rootfs may be available.
+
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index 48ff3a79634f..7d572736c86e 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss.o
knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
+obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
diff --git a/drivers/soc/ti/ti_sci_pm_domains.c b/drivers/soc/ti/ti_sci_pm_domains.c
new file mode 100644
index 000000000000..b0b283810e72
--- /dev/null
+++ b/drivers/soc/ti/ti_sci_pm_domains.c
@@ -0,0 +1,202 @@
+/*
+ * TI SCI Generic Power Domain Driver
+ *
+ * Copyright (C) 2015-2017 Texas Instruments Incorporated - http://www.ti.com/
+ * J Keerthy <j-keerthy@ti.com>
+ * Dave Gerlach <d-gerlach@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/slab.h>
+#include <linux/soc/ti/ti_sci_protocol.h>
+
+/**
+ * struct ti_sci_genpd_dev_data: holds data needed for every device attached
+ * to this genpd
+ * @idx: index of the device that identifies it with the system
+ * control processor.
+ */
+struct ti_sci_genpd_dev_data {
+ int idx;
+};
+
+/**
+ * struct ti_sci_pm_domain: TI specific data needed for power domain
+ * @ti_sci: handle to TI SCI protocol driver that provides ops to
+ * communicate with system control processor.
+ * @dev: pointer to dev for the driver for devm allocs
+ * @pd: generic_pm_domain for use with the genpd framework
+ */
+struct ti_sci_pm_domain {
+ const struct ti_sci_handle *ti_sci;
+ struct device *dev;
+ struct generic_pm_domain pd;
+};
+
+#define genpd_to_ti_sci_pd(gpd) container_of(gpd, struct ti_sci_pm_domain, pd)
+
+/**
+ * ti_sci_dev_id(): get prepopulated ti_sci id from struct dev
+ * @dev: pointer to device associated with this genpd
+ *
+ * Returns device_id stored from ti,sci_id property
+ */
+static int ti_sci_dev_id(struct device *dev)
+{
+ struct generic_pm_domain_data *genpd_data = dev_gpd_data(dev);
+ struct ti_sci_genpd_dev_data *sci_dev_data = genpd_data->data;
+
+ return sci_dev_data->idx;
+}
+
+/**
+ * ti_sci_dev_to_sci_handle(): get pointer to ti_sci_handle
+ * @dev: pointer to device associated with this genpd
+ *
+ * Returns ti_sci_handle to be used to communicate with system
+ * control processor.
+ */
+static const struct ti_sci_handle *ti_sci_dev_to_sci_handle(struct device *dev)
+{
+ struct generic_pm_domain *pd = pd_to_genpd(dev->pm_domain);
+ struct ti_sci_pm_domain *ti_sci_genpd = genpd_to_ti_sci_pd(pd);
+
+ return ti_sci_genpd->ti_sci;
+}
+
+/**
+ * ti_sci_dev_start(): genpd device start hook called to turn device on
+ * @dev: pointer to device associated with this genpd to be powered on
+ */
+static int ti_sci_dev_start(struct device *dev)
+{
+ const struct ti_sci_handle *ti_sci = ti_sci_dev_to_sci_handle(dev);
+ int idx = ti_sci_dev_id(dev);
+
+ return ti_sci->ops.dev_ops.get_device(ti_sci, idx);
+}
+
+/**
+ * ti_sci_dev_stop(): genpd device stop hook called to turn device off
+ * @dev: pointer to device associated with this genpd to be powered off
+ */
+static int ti_sci_dev_stop(struct device *dev)
+{
+ const struct ti_sci_handle *ti_sci = ti_sci_dev_to_sci_handle(dev);
+ int idx = ti_sci_dev_id(dev);
+
+ return ti_sci->ops.dev_ops.put_device(ti_sci, idx);
+}
+
+static int ti_sci_pd_attach_dev(struct generic_pm_domain *domain,
+ struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct of_phandle_args pd_args;
+ struct ti_sci_pm_domain *ti_sci_genpd = genpd_to_ti_sci_pd(domain);
+ const struct ti_sci_handle *ti_sci = ti_sci_genpd->ti_sci;
+ struct ti_sci_genpd_dev_data *sci_dev_data;
+ struct generic_pm_domain_data *genpd_data;
+ int idx, ret = 0;
+
+ ret = of_parse_phandle_with_args(np, "power-domains",
+ "#power-domain-cells", 0, &pd_args);
+ if (ret < 0)
+ return ret;
+
+ if (pd_args.args_count != 1)
+ return -EINVAL;
+
+ idx = pd_args.args[0];
+
+ /*
+ * Check the validity of the requested idx, if the index is not valid
+ * the PMMC will return a NAK here and we will not allocate it.
+ */
+ ret = ti_sci->ops.dev_ops.is_valid(ti_sci, idx);
+ if (ret)
+ return -EINVAL;
+
+ sci_dev_data = kzalloc(sizeof(*sci_dev_data), GFP_KERNEL);
+ if (!sci_dev_data)
+ return -ENOMEM;
+
+ sci_dev_data->idx = idx;
+
+ genpd_data = dev_gpd_data(dev);
+ genpd_data->data = sci_dev_data;
+
+ return 0;
+}
+
+static void ti_sci_pd_detach_dev(struct generic_pm_domain *domain,
+ struct device *dev)
+{
+ struct generic_pm_domain_data *genpd_data = dev_gpd_data(dev);
+ struct ti_sci_genpd_dev_data *sci_dev_data = genpd_data->data;
+
+ kfree(sci_dev_data);
+ genpd_data->data = NULL;
+}
+
+static const struct of_device_id ti_sci_pm_domain_matches[] = {
+ { .compatible = "ti,sci-pm-domain", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, ti_sci_pm_domain_matches);
+
+static int ti_sci_pm_domain_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct ti_sci_pm_domain *ti_sci_pd;
+ int ret;
+
+ ti_sci_pd = devm_kzalloc(dev, sizeof(*ti_sci_pd), GFP_KERNEL);
+ if (!ti_sci_pd)
+ return -ENOMEM;
+
+ ti_sci_pd->ti_sci = devm_ti_sci_get_handle(dev);
+ if (IS_ERR(ti_sci_pd->ti_sci))
+ return PTR_ERR(ti_sci_pd->ti_sci);
+
+ ti_sci_pd->dev = dev;
+
+ ti_sci_pd->pd.attach_dev = ti_sci_pd_attach_dev;
+ ti_sci_pd->pd.detach_dev = ti_sci_pd_detach_dev;
+
+ ti_sci_pd->pd.dev_ops.start = ti_sci_dev_start;
+ ti_sci_pd->pd.dev_ops.stop = ti_sci_dev_stop;
+
+ pm_genpd_init(&ti_sci_pd->pd, NULL, true);
+
+ ret = of_genpd_add_provider_simple(np, &ti_sci_pd->pd);
+
+ return ret;
+}
+
+static struct platform_driver ti_sci_pm_domains_driver = {
+ .probe = ti_sci_pm_domain_probe,
+ .driver = {
+ .name = "ti_sci_pm_domains",
+ .of_match_table = ti_sci_pm_domain_matches,
+ },
+};
+module_platform_driver(ti_sci_pm_domains_driver);
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("TI System Control Interface (SCI) Power Domain driver");
+MODULE_AUTHOR("Dave Gerlach");
--
2.11.0
^ permalink raw reply related
* [PATCH v5 3/5] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2017-04-04 2:47 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Santosh Shilimkar,
Rob Herring, Arnd Bergmann
Cc: Nishanth Menon, devicetree, Dave Gerlach, Keerthy, linux-pm,
linux-kernel, Tero Kristo, Russell King, Sudeep Holla,
Olof Johansson, linux-arm-kernel
In-Reply-To: <20170404024732.32699-1-d-gerlach@ti.com>
Add a generic power domain implementation, TI SCI PM Domains, that
will hook into the genpd framework and allow the TI SCI protocol to
control device power states.
Also, provide macros representing each device index as understood
by TI SCI to be used in the device node power-domain references.
These are identifiers for the K2G devices managed by the PMMC.
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
v4->v5: Drop last sentence of first paragraph to avoid describing Linux
driver behavior in dt binding doc.
.../devicetree/bindings/soc/ti/sci-pm-domain.txt | 57 ++++++++++++++
MAINTAINERS | 2 +
include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
3 files changed, 149 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
create mode 100644 include/dt-bindings/genpd/k2g.h
diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
new file mode 100644
index 000000000000..c705db07d820
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
@@ -0,0 +1,57 @@
+Texas Instruments TI-SCI Generic Power Domain
+---------------------------------------------
+
+Some TI SoCs contain a system controller (like the PMMC, etc...) that is
+responsible for controlling the state of the IPs that are present.
+Communication between the host processor running an OS and the system
+controller happens through a protocol known as TI-SCI [1].
+
+[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+PM Domain Node
+==============
+The PM domain node represents the global PM domain managed by the PMMC, which
+in this case is the implementation as documented by the generic PM domain
+bindings in Documentation/devicetree/bindings/power/power_domain.txt. Because
+this relies on the TI SCI protocol to communicate with the PMMC it must be a
+child of the pmmc node.
+
+Required Properties:
+--------------------
+- compatible: should be "ti,sci-pm-domain"
+- #power-domain-cells: Must be 1 so that an id can be provided in each
+ device node.
+
+Example (K2G):
+-------------
+ pmmc: pmmc {
+ compatible = "ti,k2g-sci";
+ ...
+
+ k2g_pds: power-controller {
+ compatible = "ti,sci-pm-domain";
+ #power-domain-cells = <1>;
+ };
+ };
+
+PM Domain Consumers
+===================
+Hardware blocks belonging to a PM domain should contain a "power-domains"
+property that is a phandle pointing to the corresponding PM domain node
+along with an index representing the device id to be passed to the PMMC
+for device control.
+
+Required Properties:
+--------------------
+- power-domains: phandle pointing to the corresponding PM domain node
+ and an ID representing the device.
+
+See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
+
+Example (K2G):
+--------------------
+ uart0: serial@02530c00 {
+ compatible = "ns16550a";
+ ...
+ power-domains = <&k2g_pds K2G_DEV_UART0>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 1b0a87ffffab..ae43f3e95b47 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12382,6 +12382,8 @@ S: Maintained
F: Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
F: drivers/firmware/ti_sci*
F: include/linux/soc/ti/ti_sci_protocol.h
+F: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+F: include/dt-bindings/genpd/k2g.h
THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
M: Hans Verkuil <hverkuil@xs4all.nl>
diff --git a/include/dt-bindings/genpd/k2g.h b/include/dt-bindings/genpd/k2g.h
new file mode 100644
index 000000000000..1f31f17e19eb
--- /dev/null
+++ b/include/dt-bindings/genpd/k2g.h
@@ -0,0 +1,90 @@
+/*
+ * TI K2G SoC Device definitions
+ *
+ * Copyright (C) 2015-2017 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_GENPD_K2G_H
+#define _DT_BINDINGS_GENPD_K2G_H
+
+/* Documented in http://processors.wiki.ti.com/index.php/TISCI */
+
+#define K2G_DEV_PMMC0 0x0000
+#define K2G_DEV_MLB0 0x0001
+#define K2G_DEV_DSS0 0x0002
+#define K2G_DEV_MCBSP0 0x0003
+#define K2G_DEV_MCASP0 0x0004
+#define K2G_DEV_MCASP1 0x0005
+#define K2G_DEV_MCASP2 0x0006
+#define K2G_DEV_DCAN0 0x0008
+#define K2G_DEV_DCAN1 0x0009
+#define K2G_DEV_EMIF0 0x000a
+#define K2G_DEV_MMCHS0 0x000b
+#define K2G_DEV_MMCHS1 0x000c
+#define K2G_DEV_GPMC0 0x000d
+#define K2G_DEV_ELM0 0x000e
+#define K2G_DEV_SPI0 0x0010
+#define K2G_DEV_SPI1 0x0011
+#define K2G_DEV_SPI2 0x0012
+#define K2G_DEV_SPI3 0x0013
+#define K2G_DEV_ICSS0 0x0014
+#define K2G_DEV_ICSS1 0x0015
+#define K2G_DEV_USB0 0x0016
+#define K2G_DEV_USB1 0x0017
+#define K2G_DEV_NSS0 0x0018
+#define K2G_DEV_PCIE0 0x0019
+#define K2G_DEV_GPIO0 0x001b
+#define K2G_DEV_GPIO1 0x001c
+#define K2G_DEV_TIMER64_0 0x001d
+#define K2G_DEV_TIMER64_1 0x001e
+#define K2G_DEV_TIMER64_2 0x001f
+#define K2G_DEV_TIMER64_3 0x0020
+#define K2G_DEV_TIMER64_4 0x0021
+#define K2G_DEV_TIMER64_5 0x0022
+#define K2G_DEV_TIMER64_6 0x0023
+#define K2G_DEV_MSGMGR0 0x0025
+#define K2G_DEV_BOOTCFG0 0x0026
+#define K2G_DEV_ARM_BOOTROM0 0x0027
+#define K2G_DEV_DSP_BOOTROM0 0x0029
+#define K2G_DEV_DEBUGSS0 0x002b
+#define K2G_DEV_UART0 0x002c
+#define K2G_DEV_UART1 0x002d
+#define K2G_DEV_UART2 0x002e
+#define K2G_DEV_EHRPWM0 0x002f
+#define K2G_DEV_EHRPWM1 0x0030
+#define K2G_DEV_EHRPWM2 0x0031
+#define K2G_DEV_EHRPWM3 0x0032
+#define K2G_DEV_EHRPWM4 0x0033
+#define K2G_DEV_EHRPWM5 0x0034
+#define K2G_DEV_EQEP0 0x0035
+#define K2G_DEV_EQEP1 0x0036
+#define K2G_DEV_EQEP2 0x0037
+#define K2G_DEV_ECAP0 0x0038
+#define K2G_DEV_ECAP1 0x0039
+#define K2G_DEV_I2C0 0x003a
+#define K2G_DEV_I2C1 0x003b
+#define K2G_DEV_I2C2 0x003c
+#define K2G_DEV_EDMA0 0x003f
+#define K2G_DEV_SEMAPHORE0 0x0040
+#define K2G_DEV_INTC0 0x0041
+#define K2G_DEV_GIC0 0x0042
+#define K2G_DEV_QSPI0 0x0043
+#define K2G_DEV_ARM_64B_COUNTER0 0x0044
+#define K2G_DEV_TETRIS0 0x0045
+#define K2G_DEV_CGEM0 0x0046
+#define K2G_DEV_MSMC0 0x0047
+#define K2G_DEV_CBASS0 0x0049
+#define K2G_DEV_BOARD0 0x004c
+#define K2G_DEV_EDMA1 0x004f
+
+#endif
--
2.11.0
^ permalink raw reply related
* [PATCH v5 2/5] PM / Domains: Do not check if simple providers have phandle cells
From: Dave Gerlach @ 2017-04-04 2:47 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Santosh Shilimkar,
Rob Herring, Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, linux-pm, devicetree,
Nishanth Menon, Dave Gerlach, Keerthy, Russell King, Tero Kristo,
Sudeep Holla, Olof Johansson
In-Reply-To: <20170404024732.32699-1-d-gerlach@ti.com>
There is no reason that a platform genpd driver registered using
of_genpd_add_provider_simple needs to be constrained to having no cells
in the "power-domains" phandle. Currently the genpd framework will fail
if any arguments are passed with for a simple provider but the framework
does not actually care, so remove the check for phandle argument count.
This will allow greater flexibility for genpd providers to use their own
arguments that are passed in the phandle and interpret them however they
see fit.
Acked-by: Kevin Hilman <khilman@baylibre.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
drivers/base/power/domain.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e697dec9d25b..8e0550c27394 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1622,8 +1622,6 @@ static struct generic_pm_domain *genpd_xlate_simple(
struct of_phandle_args *genpdspec,
void *data)
{
- if (genpdspec->args_count != 0)
- return ERR_PTR(-EINVAL);
return data;
}
--
2.11.0
^ 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