* Re: [PATCH v5 0/5] usb: dwc2: Add support for USB OTG on STM32F4x9
From: Alexandre Torgue @ 2017-04-03 14:55 UTC (permalink / raw)
To: Bruno Herrera, robh+dt, mark.rutland, mcoquelin.stm32, johnyoun,
felipe.balbi
Cc: devicetree, linux-usb, linux-arm-kernel
In-Reply-To: <20170201012547.76158-1-bruherrera@gmail.com>
Hi
On 02/01/2017 02:25 AM, Bruno Herrera wrote:
> The STM32F4x9 MCU family has two DWC2 USB OTG cores on it. One core is
> USB OTG FS and other core is USB OTG HS. The USB FS core only works with
> its internal phy whilst the USF HS core can work in HS with external ulpi
> phy or in FS/LS speed with the embedded FS PHY.
>
...
>
> Documentation/devicetree/bindings/usb/dwc2.txt | 4 ++++
> arch/arm/boot/dts/stm32f429-disco.dts | 16 +++++++++++++
> arch/arm/boot/dts/stm32f429.dtsi | 31 ++++++++++++++++++++++++++
> arch/arm/boot/dts/stm32f469-disco.dts | 16 +++++++++++++
> drivers/usb/dwc2/core.h | 5 +++++
> drivers/usb/dwc2/hcd.c | 15 ++++++++++++-
> drivers/usb/dwc2/hw.h | 2 ++
> drivers/usb/dwc2/params.c | 19 ++++++++++++++++
> 8 files changed, 107 insertions(+), 1 deletion(-)
>
Patches 2, 3, 4 & 5 (DT + bindings) applied on stm32-dt-for-v4.12
regards
Alex
^ permalink raw reply
* Re: [PATCH] i2c: add sc18is600 driver
From: Rob Herring @ 2017-04-03 14:54 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Wolfram Sang, Mark Rutland, linux-i2c, devicetree, linux-kernel
In-Reply-To: <20170329140339.22501-1-sre@kernel.org>
On Wed, Mar 29, 2017 at 04:03:39PM +0200, Sebastian Reichel wrote:
> This adds an I²C master driver for SPI -> I²C bus bridge chips.
> It currently supports NXP's SC18IS600 and SC18IS601, as well as
> Silicon Labs' CP2120. The driver was only tested on SC18IS600.
>
> Signed-off-By: Sebastian Reichel <sre@kernel.org>
> ---
> .../devicetree/bindings/i2c/i2c-cp2120.txt | 1 +
> .../devicetree/bindings/i2c/i2c-sc18is600.txt | 62 +++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile | 1 +
> drivers/i2c/busses/i2c-sc18is600.c | 572 +++++++++++++++++++++
> 5 files changed, 646 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cp2120.txt
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sc18is600.txt
> create mode 100644 drivers/i2c/busses/i2c-sc18is600.c
^ permalink raw reply
* Re: [PATCH V4 1/2] dt-bindings: thermal: add support for Broadcom's Northstar thermal
From: Jon Mason @ 2017-04-03 14:54 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Scott Branden, Stephen Warren, Ray Jui,
linux-pm, Lee Jones, Eduardo Valentin, Eric Anholt, Rob Herring,
BCM Kernel Feedback, linux-rpi-kernel, Rafał Miłecki,
Zhang Rui, linux-arm-kernel
In-Reply-To: <CAC3K-4r7xGoSSBwHKZjrS27jMFr_RYp1n4nRo2aAHzVAVbVi_A@mail.gmail.com>
On Sun, Apr 2, 2017 at 11:07 PM, Jon Mason <jon.mason@broadcom.com> wrote:
> On Sat, Apr 1, 2017 at 5:50 PM, Rafał Miłecki <zajec5@gmail.com> wrote:
>> On 04/01/2017 09:51 PM, Eduardo Valentin wrote:
>>>
>>> On Fri, Mar 31, 2017 at 10:11:23PM +0200, Rafał Miłecki wrote:
>>>>
>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>
>>>> This commit documents binding for thermal used in Northstar family SoCs.
>>>>
>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>>> ---
>>>> V3: Add thermal-zones to the example
>>>> Rob: Because of this update, I didn't include Acked-by I got for V2
>>>> ---
>>>> .../devicetree/bindings/thermal/brcm,ns-thermal | 26
>>>> ++++++++++++++++++++++
>>>> 1 file changed, 26 insertions(+)
>>>> create mode 100644
>>>> Documentation/devicetree/bindings/thermal/brcm,ns-thermal
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
>>>> b/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
>>>> new file mode 100644
>>>> index 000000000000..c561c7349f17
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
>>>> @@ -0,0 +1,26 @@
>>>> +* Broadcom Northstar Thermal
>>>> +
>>>> +This binding describes thermal sensor that is part of Northstar's DMU
>>>> (Device
>>>> +Management Unit).
>>>> +
>>>> +Required properties:
>>>> +- compatible : Must be "brcm,ns-thermal"
>>>> +- reg : iomem address range of PVTMON registers
>>>> +- #thermal-sensor-cells : Should be <0>
>>>> +
>>>> +Example:
>>>> +
>>>> +thermal: thermal@1800c2c0 {
>>>> + compatible = "brcm,ns-thermal";
>>>> + reg = <0x1800c2c0 0x10>;
>>>> + #thermal-sensor-cells = <0>;
>>>> +};
>>>> +
>>>> +thermal-zones {
>>>> + cpu_thermal: cpu-thermal {
>>>> + polling-delay-passive = <0>;
>>>> + polling-delay = <1000>;
>>>> + coefficients = <(-556) 418000>;
>>>> + thermal-sensors = <&thermal>;
>>>
>>>
>>> You need to define trips and cooling devices here. Otherwise, makes
>>> little sense to have this device in thermal subsystem. Here is an
>>> example of minimal set:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=linus&id=1e2ac9821de6a85d3e8358f238436708d1d46869
>>>
>>> The above has no passive action. It is just gonna shutdown the system if
>>> temperature crosses a threshold.
>>>
>>> But, a typical cooling device would be CPU frequency throttling. Do you
>>> have
>>> that up and running in your routers?
>>
>>
>> I don't have CPU freq throttling, so shutdown will be the only solution for
>> critical temp right now.
>>
>> I know I should have at least a trip for critical temperature, but the
>> problem
>> is I don't know what value to use. There isn't any info about this in public
>> datasheets. Broadcom's SDK doesn't mention it. Vendors share only the max
>> environment temp, not the max CPU temp.
>>
>> So for now I only meant to provide user space access to reading current CPU
>> temperature. I could do some stress tests and ask other users to do it as
>> well.
>>
>> Or maybe I could just put in Documentation some round value that makes more
>> or
>> less sense and then work on a proper content of real DTS files?
>>
>> Unless we can get some hint from Broadcom people. Jon? Florian? Anyone?
>
> I'll poke around and see if I can find a datasheet for NS/NSP. Worst
> case, I can ask one of the HW engineers for NSP, and we can use the
> same value for NS.
In the NS documentation, under "Absolute Maximum Ratings":
The "Maximum Junction Temperature" is 125 C
The "Commercial Ambient Temperature (Operating)" range is 0 to 75 C
The "Industrial Ambient Temperature (Operating)" range is -40 to 85 C
The "Storage Temperature" range is -40 to 125 C
In the NSP documentation, under "Absolute Maximum Ratings":
The "Maximum Junction Temperature" is 110 C
The "Commercial Ambient Temperature (Operating)" range is 0 to 75 C
The "Industrial Ambient Temperature (Operating)" range is -40 to 85 C
The "Storage Temperature" range is -40 to 125 C
I believe the first one is the number you are looking for.
Thanks,
Jon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/7] Add support for triggered buffer mode to STM32 ADC
From: Alexandre Torgue @ 2017-04-03 14:53 UTC (permalink / raw)
To: Fabrice Gasnier, jic23, linux, robh+dt, linux-arm-kernel,
devicetree, linux-kernel
Cc: mark.rutland, benjamin.gaignard, lars, mcoquelin.stm32, linux-iio,
pmeerw, knaack.h, benjamin.gaignard
In-Reply-To: <1485440915-30119-1-git-send-email-fabrice.gasnier@st.com>
Hi
On 01/26/2017 03:28 PM, Fabrice Gasnier wrote:
> The following patches add support for triggered buffer mode.
> These are based on top of "Add PWM and IIO timer drivers for STM32"
> series. Reference:
> https://lkml.org/lkml/2017/1/20/116
>
> STM32 ADC, can use either interrupts or DMA to collect data.
> Either timer trigger output (TRGO) or PWM can be used as trigger source.
> This patchset has been tested on STM32F429 eval board.
>
...
> Fabrice Gasnier (7):
> iio: adc: stm32: add support for triggered buffer mode
> iio: adc: stm32: Enable use of stm32 timer triggers
> iio: adc: stm32: add trigger polarity extended attribute
> Documentation: dt: iio: stm32-adc: optional dma support
> iio: adc: stm32: add optional dma support
> ARM: dts: stm32: Enable dma by default on stm32f4 adc
> ARM: dts: stm32: Enable pwm1 and pwm3 on stm32f429i-eval
Patches 6 & 7 (DT) applied on stm32-dt-for-v4.12
Regards
Alex
>
> Documentation/ABI/testing/sysfs-bus-iio-adc-stm32 | 18 +
> .../devicetree/bindings/iio/adc/st,stm32-adc.txt | 7 +
> arch/arm/boot/dts/stm32429i-eval.dts | 28 +
> arch/arm/boot/dts/stm32f429.dtsi | 6 +
> drivers/iio/adc/Kconfig | 5 +
> drivers/iio/adc/stm32-adc-core.c | 1 +
> drivers/iio/adc/stm32-adc-core.h | 2 +
> drivers/iio/adc/stm32-adc.c | 633 ++++++++++++++++++++-
> 8 files changed, 676 insertions(+), 24 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-stm32
>
^ permalink raw reply
* Re: [RFC PATCH 2/5] soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations
From: Robin Murphy @ 2017-04-03 14:52 UTC (permalink / raw)
To: Scott Wood, Michael Ellerman, roy.pledge, linuxppc-dev,
linux-arm-kernel, devicetree
Cc: Mark Rutland, madalin.bucur
In-Reply-To: <1491031518.2944.62.camel@buserror.net>
On 01/04/17 08:25, Scott Wood wrote:
> On Fri, 2017-03-31 at 18:55 +0100, Robin Murphy wrote:
>> On 31/03/17 04:27, Michael Ellerman wrote:
>>>
>>> Robin Murphy <robin.murphy@arm.com> writes:
>>>
>>>>
>>>> Hi Roy,
>>>>
>>>> On 29/03/17 22:13, Roy Pledge wrote:
>>>>>
>>>>> Use the shared-memory-pool mechanism for frame queue descriptor and
>>>>> packed frame descriptor record area allocations.
>>>> Thanks for persevering with this - in my opinion it's now looking like
>>>> it was worth the effort :)
>>>>
>>>> AFAICS the ioremap_wc() that this leads to does appear to give back
>>>> something non-cacheable on PPC (assuming "pgprot_noncached_wc" isn't
>>>> horrendously misnamed), and "no-map" should rule out any cacheable
>>>> linear map alias existing, so it would seem that this approach should
>>>> avert Scott's concerns about attribute mismatches.
>>> How does 'no-map' translate into something being excluded from the
>>> linear mapping?
>> Reserved regions marked with "no-map" get memblock_remove()d by
>> early_init_dt_alloc_reserved_memory_arch(). As I understand things, the
>> linear map should only cover memblock areas, and it would be explicitly
>> violating the semantics of "no-map" to still cover such a region.
>
> Discontiguous memory isn't supported on these PPC chips. Everything up to
> memblock_end_of_DRAM() gets mapped -- and if that were to change, the
> fragmentation would waste TLB1 entries.
Ah, so the "PPC-specific angles I'm not aware of" category is indeed
non-empty - I guess the lack of HAVE_GENERIC_DMA_COHERENT might be
related, then.
That said, though, AFAICS only certain x86 and s390 configurations ever
call memblock_set_bottom_up(true), so we should be able to assume that
the reserved region allocations always fall through to
__memblock_find_range_top_down(). Thus if your DRAM is contiguous, then
"no-map"-ing the reserved regions will simply end up pushing
memblock_end_of_DRAM() down in a manner that would appear to still avoid
overlaps. I can only see that going wrong if the end of DRAM wasn't at
least 32MB aligned to begin with - is that ever likely to happen in
practice?
Robin.
> This also breaks compatibility with existing device trees. I suggest putting
> an ifdef in the qbman driver to add the new scheme for non-PPC arches only.
>
> -Scott
>
^ permalink raw reply
* Re: [PATCH RFC] serial: imx: support an enable-gpio
From: Uwe Kleine-König @ 2017-04-03 14:51 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-serial-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1468400495-10471-1-git-send-email-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Wed, Jul 13, 2016 at 11:01:35AM +0200, Uwe Kleine-König wrote:
> A part of my machine looks as follows (simplified):
>
> ,------------------------.
> | ,---------. |
> | | imx25 o--RX----◁---o---
> | | o--GPIO--' |
> | `---------' |
> `------------------------'
>
> that is, there is a driver on the RX line that must be enabled before
> the UART can be used. (That is necessary because the default mux of the
> RX pad after reset is an output.)
>
> To represent this in the device tree I do:
>
> pinctrl_uart5: uart5 {
> fsl,pins = <
> ...
> MX25_PAD_LBA__UART5_RXD 0x00000000
> MX25_PAD_CS5__GPIO_3_21 0x00002001
> ...
> };
>
> &uart5 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_uart5>;
>
> enable-gpio = <&gpio3 21 GPIO_ACTIVE_LOW>;
> ...
> };
>
> This way it's ensured that the gpio is only enabled when the LBA pad is
> muxed as RX (together with the bootloader that sets the GPIO high).
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> Hello,
>
> I'm not sure about the naming. Do you have a better suggestion how to handle
> this situation?
>
> Best regards
> Uwe
>
> drivers/tty/serial/imx.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 0df2b1c091ae..56eaa18aa5be 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -39,6 +39,7 @@
> #include <linux/of_device.h>
> #include <linux/io.h>
> #include <linux/dma-mapping.h>
> +#include <linux/gpio/consumer.h>
>
> #include <asm/irq.h>
> #include <linux/platform_data/serial-imx.h>
> @@ -1987,7 +1988,9 @@ static int serial_imx_probe_dt(struct imx_port *sport,
> if (of_get_property(np, "fsl,dte-mode", NULL))
> sport->dte_mode = 1;
>
> - return 0;
> + ret = PTR_ERR_OR_ZERO(devm_gpiod_get_optional(&pdev->dev, "enable", GPIOD_OUT_HIGH));
> + dev_info(&pdev->dev, "Tralala: ret = %d\n", ret);
That line is a debug left over and obviously should be removed. Other
than taht I still wonder if this patch is good enough for mainline as it
solves a real problem.
Best regards
Uwe
> + return ret;
> }
> #else
> static inline int serial_imx_probe_dt(struct imx_port *sport,
> --
> 2.8.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/2] PCI: Add tango PCIe host bridge support
From: Rob Herring @ 2017-04-03 14:51 UTC (permalink / raw)
To: Marc Gonzalez
Cc: Bjorn Helgaas, Marc Zyngier, Thomas Gleixner, DT,
Lorenzo Pieralisi, Mason, linux-pci, Thibaud Cornic, Liviu Dudau,
LKML, David Laight, Phuong Nguyen, Robin Murphy, Linux ARM
In-Reply-To: <65114e62-7458-b6f7-327c-f07a5096a452@sigmadesigns.com>
On Wed, Mar 29, 2017 at 01:34:45PM +0200, Marc Gonzalez wrote:
> This driver is used to work around HW bugs in the controller.
>
> Note: the controller does NOT support the following features.
>
> Legacy PCI interrupts
> IO space
>
> Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
> ---
> Documentation/devicetree/bindings/pci/tango-pcie.txt | 33 +++++++++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/pci/host/Kconfig | 7 ++
> drivers/pci/host/Makefile | 1 +
> drivers/pci/host/pcie-tango.c | 150 +++++++++++++++++++++++++++++++++++++++
> 4 files changed, 191 insertions(+)
^ permalink raw reply
* Re: [PATCH 0/3] Add RTC support on STM32F746
From: Alexandre Torgue @ 2017-04-03 14:51 UTC (permalink / raw)
To: Amelie Delaunay, Rob Herring, Mark Rutland, Russell King,
Maxime Coquelin
Cc: devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1484833519-9298-1-git-send-email-amelie.delaunay@st.com>
Hi
On 01/19/2017 02:45 PM, Amelie Delaunay wrote:
> This patchset enables STM32 RTC on STM32F746 MCU.
>
> Amelie Delaunay (3):
> ARM: dts: stm32: set HSE_RTC clock frequency to 1 MHz on stm32f746
> ARM: dts: stm32: Add RTC support for STM32F746 MCU
> ARM: dts: stm32: enable RTC on stm32746g-eval
>
> arch/arm/boot/dts/stm32746g-eval.dts | 4 ++++
> arch/arm/boot/dts/stm32f746.dtsi | 16 ++++++++++++++++
> 2 files changed, 20 insertions(+)
>
Series applied on stm32-dt-for-v4.12
regards
Alex
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: update device tree binding for Allwinner PRCM CCUs
From: Rob Herring @ 2017-04-03 14:49 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Michael Turquette, Maxime Ripard, Chen-Yu Tsai,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170329104246.34204-2-icenowy-h8G6r0blFSE@public.gmane.org>
On Wed, Mar 29, 2017 at 06:42:42PM +0800, Icenowy Zheng wrote:
> From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>
> Many Allwinner SoCs after A31 have a CCU in PRCM block.
>
> Give the ones on H3 and A64 compatible strings.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
> Changes in v3:
> - Removed frequency info of iosc in this device tree binding document.
> Changes in v2:
> - Add iosc for R_CCU's on H3/A64.
>
> Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [RFC PATCH 1/2] dt-bindings: mtd: Add Cavium SOCs NAND bindings
From: Rob Herring @ 2017-04-03 14:47 UTC (permalink / raw)
To: Jan Glauber
Cc: Boris Brezillon, Richard Weinberger, David Woodhouse,
Brian Norris, Marek Vasut, Cyrille Pitchen,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170403143840.GA23698@hardcore>
On Mon, Apr 3, 2017 at 9:38 AM, Jan Glauber
<jan.glauber-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org> wrote:
> On Mon, Apr 03, 2017 at 08:29:37AM -0500, Rob Herring wrote:
>> On Mon, Mar 27, 2017 at 06:05:23PM +0200, Jan Glauber wrote:
>> > Add device tree binding description for Cavium SOC nand flash controller.
>> >
>> > CC: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> > CC: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> > CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> >
>> > Signed-off-by: Jan Glauber <jglauber-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>> > ---
>> > .../devicetree/bindings/mtd/cavium_nand.txt | 32 ++++++++++++++++++++++
>> > 1 file changed, 32 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/mtd/cavium_nand.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/mtd/cavium_nand.txt b/Documentation/devicetree/bindings/mtd/cavium_nand.txt
>> > new file mode 100644
>> > index 0000000..4698d1f
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/mtd/cavium_nand.txt
>> > @@ -0,0 +1,32 @@
>> > +* Cavium NAND controller
>> > +
>> > +Required properties:
>> > +
>> > +- compatible: should be "cavium,cn8xxx-nand"
>>
>> Don't use wildcards in compatible strings. For PCI devices, this should
>> be based on the PCI vendor and device IDs.
>>
>
> Is there a syntax for compatible PCI devices? I'm afraid I've not seen
> this yet, can you give an example?
www.o3one.org/hwdocs/openfirmware/pci_supplement_2_1.pdf
> Most of Cavium's devices are PCI devices, we just added the compatible
> as convenience and usually it is not parsed.
Linux doesn't parse it, but it's still required in the binding.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V7 4/7] mfd: da9061: MFD core support
From: Steve Twiss @ 2017-04-03 14:46 UTC (permalink / raw)
To: LINUX-KERNEL, Lee Jones
Cc: 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: <cover.1491230802.git.stwiss.opensource@diasemi.com>
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>
---
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
--
end-of-patch for PATCH V7
^ permalink raw reply related
* Re: [PATCH 0/4] Introduce STM32F7 Clocks
From: Alexandre Torgue @ 2017-04-03 14:42 UTC (permalink / raw)
To: gabriel.fernandez, Rob Herring, Mark Rutland, Russell King,
Maxime Coquelin, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, daniel.thompson, andrea.merello, radoslaw.pietrzyk
Cc: devicetree, amelie.delaunay, kernel, olivier.bideau, linux-kernel,
linux-arm-kernel, linux-clk, ludovic.barre
In-Reply-To: <1483711165-17149-1-git-send-email-gabriel.fernandez@st.com>
hi
On 01/06/2017 02:59 PM, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch-set introduces STM32F7 clocks.
> F7 Clocks are very similar as F4.
>
> We have some new clocks:
> - hdmi-cec
> - spdif-rx
> - lptim1
> - sai2
>
> Uarts & I2cs can have different clock sources.
>
>
>
> Gabriel Fernandez (4):
> clk: stm32f7: Add stm32f7 clock DT bindings for STM32F746 boards
> clk: stm32f7: Introduce stm32f7 clocks for STM32F746 boards
> ARM: dts: stm32: stm32f7: Enable clocks for STM32F746 boards
> dt-bindings: mfd: Add STM32F7 RCC numeric constants into DT include
> file
>
> .../devicetree/bindings/clock/st,stm32-rcc.txt | 20 ++
> arch/arm/boot/dts/stm32f746.dtsi | 80 ++++--
> drivers/clk/clk-stm32f4.c | 277 ++++++++++++++++++++-
> include/dt-bindings/clock/stm32fx-clock.h | 20 ++
> include/dt-bindings/mfd/stm32f7-rcc.h | 112 +++++++++
> 5 files changed, 476 insertions(+), 33 deletions(-)
> create mode 100644 include/dt-bindings/mfd/stm32f7-rcc.h
>
Patchs 3 & 4 applied on stm32-dt-for-v4.12
^ permalink raw reply
* Re: [PATCH v2] clk: stm32h7: Add stm32h743 clock driver
From: Rob Herring @ 2017-04-03 14:39 UTC (permalink / raw)
To: gabriel.fernandez-qxv4g6HH51o
Cc: Mark Rutland, Russell King, Maxime Coquelin, Alexandre Torgue,
Michael Turquette, Stephen Boyd, Nicolas Pitre, Arnd Bergmann,
daniel.thompson-QSEj5FYQhm4dnm+yROfE0A,
andrea.merello-Re5JQEeQqe8AvxtiuMwx3w,
radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w, Lee Jones,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, ludovic.barre-qxv4g6HH51o,
olivier.bideau-qxv4g6HH51o, amelie.delaunay-qxv4g6HH51o
In-Reply-To: <1490778502-23651-1-git-send-email-gabriel.fernandez-qxv4g6HH51o@public.gmane.org>
On Wed, Mar 29, 2017 at 11:08:22AM +0200, gabriel.fernandez-qxv4g6HH51o@public.gmane.org wrote:
> From: Gabriel Fernandez <gabriel.fernandez-qxv4g6HH51o@public.gmane.org>
>
> This patch enables clocks for STM32H743 boards.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez-qxv4g6HH51o@public.gmane.org>
>
> Just for the MFD changes:
> Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> v2:
> - rename compatible string "stm32,pll" into "stm32h7-pll"
> - suppress "st,pllrge" property
> - suppress "st, frac-status" property
> - change management of "st,frac" property
> 0 : enable 0 pll integer mode
> other values : enable pll in fractional mode (value is
> the fractional factor)
> ---
> .../devicetree/bindings/clock/st,stm32h7-rcc.txt | 151 ++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-stm32h7.c | 1610 ++++++++++++++++++++
> include/dt-bindings/clock/stm32h7-clks.h | 165 ++
> include/dt-bindings/mfd/stm32h7-rcc.h | 137 ++
> 5 files changed, 2064 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
> create mode 100644 drivers/clk/clk-stm32h7.c
> create mode 100644 include/dt-bindings/clock/stm32h7-clks.h
> create mode 100644 include/dt-bindings/mfd/stm32h7-rcc.h
>
> diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
> new file mode 100644
> index 0000000..5f54f64
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
> @@ -0,0 +1,151 @@
> +STMicroelectronics STM32H7 Reset and Clock Controller
> +=====================================================
> +
> +The RCC IP is both a reset and a clock controller.
> +
> +Please refer to clock-bindings.txt for common clock controller binding usage.
> +Please also refer to reset.txt for common reset controller binding usage.
> +
> +Required properties:
> +- compatible: Should be:
> + "st,stm32h743-rcc"
> +
> +- reg: should be register base and length as documented in the
> + datasheet
> +
> +- #reset-cells: 1, see below
> +
> +- #clock-cells : from common clock binding; shall be set to 1
> +
> +- clocks: External oscillator clock phandle
> + - high speed external clock signal (HSE)
> + - low speed external clock signal (LSE)
> + - external I2S clock (I2S_CKIN)
> +
> +- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain
> + write protection (RTC clock).
> +
> +- pll x node: Allow to register a pll with specific parameters.
> + Please see PLL section below.
> +
> +Example:
> +
> + rcc: rcc@58024400 {
> + #reset-cells = <1>;
> + #clock-cells = <2>
> + compatible = "st,stm32h743-rcc", "st,stm32-rcc";
> + reg = <0x58024400 0x400>;
> + clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>;
> +
> + st,syscfg = <&pwrcfg>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vco1@0 {
> + #clock-cells = <0>;
> + compatible = "stm32h7-pll";
> + reg = <0>;
> + };
> +
> + vco2@1 {
> + #clock-cells = <0>;
> + compatible = "stm32h7-pll";
> + reg = <1>;
> + st,clock-div = <2>;
> + st,clock-mult = <40>;
> + st,frac = <0>;
> + st,vcosel = <1>;
> + };
> + vco3@2 {
> + #clock-cells = <0>;
> + compatible = "stm32h7-pll";
> + reg = <2>;
> + st,clock-div = <2>;
> + st,clock-mult = <40>;
> + st,frac = <1024>;
> + st,vcosel = <1>;
> + };
> + };
> +
> +
> +STM32H7 PLL
> +-----------
> +
> +The VCO of STM32 PLL could be reprensented like this:
> +
> + Vref --------- --------
> + ---->| / DIVM |---->| x DIVN | ------> VCO
> + --------- --------
> + ^
> + |
> + -------
> + | FRACN |
> + -------
> +
> +When the PLL is configured in integer mode:
> +- VCO = ( Vref / DIVM ) * DIVN
> +
> +When the PLL is configured in fractional mode:
> +- VCO = ( Vref / DIVM ) * ( DIVN + FRACN / 2^13)
> +
> +
> +Required properties for pll node:
> +- compatible: Should be:
> + "stm32h7-pll"
stm,stm32h7-pll
With that,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> +
> +- #clock-cells: from common clock binding; shall be set to 0
> +- reg: Should be the pll number.
> +
> +Optional properties:
> +- st,clock-div: DIVM division factor : <1..63>
> +- st,clock-mult: DIVN multiplication factor : <4..512>
> +
> +- st,frac:
> + - 0 Pll is configured in integer mode
> + - <1..8191> Pll is configure in fractional mode and the value is
> + the part of the multiplication factor.
> +
> +- st,vcosel: VCO selection
> + - 0: Wide VCO range:192 to 836 MHz
> + - 1: Medium VCO range:150 to 420 MHz
> +
> +The peripheral clock consumer should specify the desired clock by
> +having the clock ID in its "clocks" phandle cell.
> +
> +All available clocks are defined as preprocessor macros in
> +dt-bindings/clock/stm32h7-clks.h header and can be used in device
> +tree sources.
> +
> +Example:
> +
> + timer5: timer@40000c00 {
> + compatible = "st,stm32-timer";
> + reg = <0x40000c00 0x400>;
> + interrupts = <50>;
> + clocks = <&rcc TIM5_CK>;
> +
> + };
> +
> +Specifying softreset control of devices
> +=======================================
> +
> +Device nodes should specify the reset channel required in their "resets"
> +property, containing a phandle to the reset device node and an index specifying
> +which channel to use.
> +The index is the bit number within the RCC registers bank, starting from RCC
> +base address.
> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
> +Where bit_offset is the bit offset within the register.
> +
> +For example, for CRC reset:
> + crc = AHB4RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x88 / 4 * 32 + 19 = 1107
> +
> +All available preprocessor macros for reset are defined dt-bindings//mfd/stm32h7-rcc.h
> +header and can be used in device tree sources.
> +
> +example:
> +
> + timer2 {
> + resets = <&rcc STM32H7_APB1L_RESET(TIM2)>;
> + };
--
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: [RFC PATCH 1/2] dt-bindings: mtd: Add Cavium SOCs NAND bindings
From: Jan Glauber @ 2017-04-03 14:38 UTC (permalink / raw)
To: Rob Herring
Cc: Boris Brezillon, Richard Weinberger, David Woodhouse,
Brian Norris, Marek Vasut, Cyrille Pitchen,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170403132937.z5mxksabo6kmo4jy@rob-hp-laptop>
On Mon, Apr 03, 2017 at 08:29:37AM -0500, Rob Herring wrote:
> On Mon, Mar 27, 2017 at 06:05:23PM +0200, Jan Glauber wrote:
> > Add device tree binding description for Cavium SOC nand flash controller.
> >
> > CC: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > CC: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >
> > Signed-off-by: Jan Glauber <jglauber-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> > ---
> > .../devicetree/bindings/mtd/cavium_nand.txt | 32 ++++++++++++++++++++++
> > 1 file changed, 32 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mtd/cavium_nand.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/cavium_nand.txt b/Documentation/devicetree/bindings/mtd/cavium_nand.txt
> > new file mode 100644
> > index 0000000..4698d1f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/cavium_nand.txt
> > @@ -0,0 +1,32 @@
> > +* Cavium NAND controller
> > +
> > +Required properties:
> > +
> > +- compatible: should be "cavium,cn8xxx-nand"
>
> Don't use wildcards in compatible strings. For PCI devices, this should
> be based on the PCI vendor and device IDs.
>
Is there a syntax for compatible PCI devices? I'm afraid I've not seen
this yet, can you give an example?
Most of Cavium's devices are PCI devices, we just added the compatible
as convenience and usually it is not parsed.
thanks,
Jan
> > +- reg: PCI devfn
> > +- clocks: must contain system clock
> > +- #address-cells: <1>
> > +- #size-cells: <0>
> > +
> > +The nand flash controller may contain up to 8 subnodes representing
> > +NAND flash chips. Their properties are as follows.
> > +
> > +Required properties:
> > +- compatible: should be "cavium,nandcs"
> > +- reg: a single integer representing the chip-select number
> > +- nand-ecc-mode: see nand.txt
> > +
> > +Example:
> > +
> > +nfc: nand@b,0 {
> > + compatible = "cavium,cn8xxx-nand";
> > + reg = <0x5800 0 0 0 0>;
> > + clocks = <&sclk>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + nand@1 {
> > + compatible = "cavium,nandcs";
> > + reg = <1>;
> > + nand-ecc-mode = "on-die";
> > +};
> > --
> > 2.9.0.rc0.21.g7777322
> >
--
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 v10 5/5] ARM: configs: stm32: Add I2C support for STM32 defconfig
From: Alexandre Torgue @ 2017-04-03 14:36 UTC (permalink / raw)
To: M'boumba Cedric Madianga, wsa, robh+dt, mcoquelin.stm32,
linus.walleij, patrice.chotard, linux, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, u.kleine-koenig
In-Reply-To: <1484832316-5594-6-git-send-email-cedric.madianga@gmail.com>
Hi,
On 01/19/2017 02:25 PM, M'boumba Cedric Madianga wrote:
> This patch adds I2C support for STM32 default configuration
>
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
> ---
Applied on stm32-defconfig-for-v4.12
Regards
Alex
> arch/arm/configs/stm32_defconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
> index 5a72d69..323d2a3 100644
> --- a/arch/arm/configs/stm32_defconfig
> +++ b/arch/arm/configs/stm32_defconfig
> @@ -47,6 +47,9 @@ CONFIG_SERIAL_NONSTANDARD=y
> CONFIG_SERIAL_STM32=y
> CONFIG_SERIAL_STM32_CONSOLE=y
> # CONFIG_HW_RANDOM is not set
> +CONFIG_I2C=y
> +CONFIG_I2C_CHARDEV=y
> +CONFIG_I2C_STM32F4=y
> # CONFIG_HWMON is not set
> # CONFIG_USB_SUPPORT is not set
> CONFIG_NEW_LEDS=y
>
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: dt: Update ti,emif bindings
From: Rob Herring @ 2017-04-03 14:34 UTC (permalink / raw)
To: Dave Gerlach
Cc: Tony Lindgren, Santosh Shilimkar, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Keerthy J
In-Reply-To: <20170328205511.21166-2-d-gerlach-l0cyMroinI0@public.gmane.org>
On Tue, Mar 28, 2017 at 03:55:10PM -0500, Dave Gerlach wrote:
> Update the Texas Instruments EMIF binding document to include the device
> tree bindings for ti,emif-am3352 and ti,emif-am4372 which are used by
> the ti-emif-sram driver to provide low-level PM functionality.
>
> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
> ---
> .../devicetree/bindings/memory-controllers/ti/emif.txt | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 4/5] firmware: Add coreboot device tree binding documentation
From: Rob Herring @ 2017-04-03 14:32 UTC (permalink / raw)
To: Thierry Escande
Cc: Greg Kroah-Hartman, Olof Johansson, Stephen Warren,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Julius Werner, Brian Norris
In-Reply-To: <1490717489-19218-5-git-send-email-thierry.escande-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On Tue, Mar 28, 2017 at 06:11:28PM +0200, Thierry Escande wrote:
> From: Julius Werner <jwerner-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>
> This patch adds documentation describing a device tree binding for the
> coreboot firmware. It is meant to be dynamically added during boot and
> contains address definitions for the coreboot table (a list of
> variable-sized descriptors providing information about various compile-
> and run-time generated firmware parameters) and the CBMEM area (the
> structure containing most run-time resident memory regions set up by
> coreboot).
>
> These definitions allow kernel drivers to easily access data contained
> in and pointed to by these regions (such as coreboot's in-memory log).
> (An example implementation can be seen in the following patch)
>
> Signed-off-by: Julius Werner <jwerner-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Thierry Escande <thierry.escande-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> ---
> .../devicetree/bindings/firmware/coreboot.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/firmware/coreboot.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 V7 4/7] mfd: da9061: MFD core support
From: Lee Jones @ 2017-04-03 14:30 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: <6ED8E3B22081A4459DAC7699F3695FB7018CD6B183@SW-EX-MBX02.diasemi.com>
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'.
--
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 V3 4/6] dt-bindings: tegra: Update compatible strings for Tegra flowctrl
From: Rob Herring @ 2017-04-03 14:29 UTC (permalink / raw)
To: Jon Hunter
Cc: Thierry Reding, Mark Rutland, Russell King, Stephen Warren,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490704978-22906-5-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Tue, Mar 28, 2017 at 01:42:56PM +0100, Jon Hunter wrote:
> Update the compatible strings for Tegra Flow Control driver to match
> the device-tree source files for Tegra.
>
> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [RFC PATCH v2 2/4] iio: adc: sun4i-gpadc-iio: rename A23/A33-specified registers to contain A23
From: Lee Jones @ 2017-04-03 14:28 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, Chen-Yu Tsai, Jonathan Cameron, Quentin Schulz,
Zhang Rui, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170402133304.56824-3-icenowy-h8G6r0blFSE@public.gmane.org>
On Sun, 02 Apr 2017, Icenowy Zheng wrote:
> As the H3 SoC, which is also in sun8i line, has totally different
> register map for the thermal sensor (a cut down version of GPADC), we
> should rename A23/A33-specified registers to contain A23, in order to
> prevent obfuscation with H3 registers. Currently these registers are
> only prefixed "SUN8I", not "SUN8I_A23".
>
> Add "_A23" after "SUN8I" on the register names.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> Splited from RFC v1's 2/3.
>
> drivers/iio/adc/sun4i-gpadc-iio.c | 2 +-
> include/linux/mfd/sun4i-gpadc.h | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c
> index 74705aa37982..01cf806f47f8 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -88,7 +88,7 @@ static const struct gpadc_data sun6i_gpadc_data = {
> static const struct gpadc_data sun8i_a33_gpadc_data = {
> .temp_offset = -1662,
> .temp_scale = 162,
> - .tp_mode_en = SUN8I_GPADC_CTRL1_CHOP_TEMP_EN,
> + .tp_mode_en = SUN8I_A23_GPADC_CTRL1_CHOP_TEMP_EN,
> };
>
> struct sun4i_gpadc_iio {
> diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> index 139872c2e0fe..d31d962bb7d8 100644
> --- a/include/linux/mfd/sun4i-gpadc.h
> +++ b/include/linux/mfd/sun4i-gpadc.h
> @@ -38,9 +38,9 @@
> #define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(3, 0) & BIT(x))
> #define SUN6I_GPADC_CTRL1_ADC_CHAN_MASK GENMASK(3, 0)
>
> -/* TP_CTRL1 bits for sun8i SoCs */
> -#define SUN8I_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> -#define SUN8I_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
> +/* TP_CTRL1 bits for sun8i A23/A33 SoCs */
> +#define SUN8I_A23_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> +#define SUN8I_A23_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
>
> #define SUN4I_GPADC_CTRL2 0x08
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv6 06/14] atmel-isi: update device tree bindings documentation
From: Rob Herring @ 2017-04-03 14:28 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA, Guennadi Liakhovetski,
Songjun Wu, Sakari Ailus, devicetree-u79uwXL29TY76Z2rM5mHXA,
Hans Verkuil
In-Reply-To: <20170328082347.11159-7-hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
On Tue, Mar 28, 2017 at 10:23:39AM +0200, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
>
> The original bindings documentation was incomplete (missing pinctrl-names,
> missing endpoint node properties) and the example was out of date.
>
> Add the missing information and tidy up the text.
>
> Signed-off-by: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
> Acked-by: Sakari Ailus <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> ---
> .../devicetree/bindings/media/atmel-isi.txt | 91 +++++++++++++---------
> 1 file changed, 53 insertions(+), 38 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 2/2] drivers/serial: Add driver for Aspeed virtual UART
From: Rob Herring @ 2017-04-03 14:25 UTC (permalink / raw)
To: Joel Stanley
Cc: Greg Kroah-Hartman, Jiri Slaby, Mark Rutland, Jeremy Kerr,
linux-serial, linux-kernel, openbmc, devicetree,
Benjamin Herrenschmidt
In-Reply-To: <20170328054458.29341-3-joel@jms.id.au>
On Tue, Mar 28, 2017 at 04:14:58PM +1030, Joel Stanley wrote:
> From: Jeremy Kerr <jk@ozlabs.org>
>
> This change adds a driver for the 16550-based Aspeed virtual UART
> device. We use a similar process to the of_serial driver for device
> probe, but expose some VUART-specific functions through sysfs too.
>
> OpenPOWER host firmware doesn't like it when the host-side of the
> VUART's FIFO is not drained. This driver only disables host TX discard
> mode when the port is in use. We set the VUART enabled bit when we bind
> to the device, and clear it on unbind.
>
> We don't want to do this on open/release, as the host may be using this
> bit to configure serial output modes, which is independent of whether
> the devices has been opened by BMC userspace.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> Documentation/devicetree/bindings/serial/8250.txt | 2 +
For the binding:
Acked-by: Rob Herring <robh@kernel.org>
> drivers/tty/serial/Kconfig | 10 +
> drivers/tty/serial/Makefile | 1 +
> drivers/tty/serial/aspeed-vuart.c | 335 ++++++++++++++++++++++
> 4 files changed, 348 insertions(+)
> create mode 100644 drivers/tty/serial/aspeed-vuart.c
^ permalink raw reply
* Re: [PATCH v6 3/5] i2c: aspeed: added documentation for Aspeed I2C driver
From: Rob Herring @ 2017-04-03 14:24 UTC (permalink / raw)
To: Brendan Higgins
Cc: wsa, mark.rutland, tglx, jason, marc.zyngier, joel, vz, mouse,
clg, linux-i2c, devicetree, linux-kernel, openbmc, benh
In-Reply-To: <20170328051226.21677-4-brendanhiggins@google.com>
On Mon, Mar 27, 2017 at 10:12:24PM -0700, Brendan Higgins wrote:
> Added device tree binding documentation for Aspeed I2C busses.
>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> ---
> Changes for v2:
> - None
> Changes for v3:
> - Removed reference to "bus" device tree param
> Changes for v4:
> - None
> Changes for v5:
> - None
> Changes for v6:
> - Replaced the controller property with and interrupt controller, leaving only
> the busses in the I2C documentation.
> ---
> .../devicetree/bindings/i2c/i2c-aspeed.txt | 49 ++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> new file mode 100644
> index 000000000000..fbcc501706b1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> @@ -0,0 +1,49 @@
> +Device tree configuration for the I2C busses on the AST24XX and AST25XX SoCs.
> +
> +Required Properties:
> +- #address-cells : should be 1
> +- #size-cells : should be 0
> +- reg : address offset and range of bus
> +- compatible : should be "aspeed,ast2400-i2c-bus"
> + or "aspeed,ast2500-i2c-bus"
> +- clocks : root clock of bus, should reference the APB
> + clock
> +- interrupts : interrupt number
> +- interrupt-parent : interrupt controller for bus, should reference a
> + aspeed,ast2400-i2c-ic or aspeed,ast2500-i2c-ic
> + interrupt controller
> +
> +Optional Properties:
> +- clock-frequency : frequency of the bus clock in Hz
> + defaults to 100 kHz when not specified
> +
> +Example:
> +
> +i2c {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x1e78a000 0x1000>;
> +
> + i2c_ic: interrupt-controller@0 {
> + #interrupt-cells = <1>;
> + compatible = "aspeed,ast2400-i2c-ic";
> + reg = <0x0 0x40>;
> + interrupts = <12>;
> + interrupt-controller;
> + };
> +
> + i2c0: i2c-bus@40 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #interrupt-cells = <1>;
> + reg = <0x40 0x40>;
> + compatible = "aspeed,ast2400-i2c-bus";
> + bus = <0>;
Not documented and what's it for?
> + clocks = <&clk_apb>;
> + clock-frequency = <100000>;
> + status = "disabled";
Drop status from examples.
> + interrupts = <0>;
> + interrupt-parent = <&i2c_ic>;
> + };
> +};
> --
> 2.12.2.564.g063fe858b8-goog
>
^ permalink raw reply
* Re: [PATCH v6 3/5] i2c: aspeed: added documentation for Aspeed I2C driver
From: Rob Herring @ 2017-04-03 14:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Brendan Higgins, wsa, mark.rutland, tglx, jason, marc.zyngier,
joel, vz, mouse, clg, linux-i2c, devicetree, linux-kernel,
openbmc
In-Reply-To: <1490691283.3177.112.camel@kernel.crashing.org>
On Tue, Mar 28, 2017 at 07:54:43PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote:
> > Added device tree binding documentation for Aspeed I2C busses.
> >
> > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
>
> > + i2c0: i2c-bus@40 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + #interrupt-cells = <1>;
> > + reg = <0x40 0x40>;
> > + compatible = "aspeed,ast2400-i2c-bus";
> > + bus = <0>;
> > + clocks = <&clk_apb>;
> > + clock-frequency = <100000>;
>
> For busses it's more traditional to make this "bus-frequency" but
> that's a nit and Linux/fdt has not respected that tradition terribly
> well. If you respin, it might be work changing.
Makes sense, but that's news to me. I'm still new to this DT stuff.
> The clock-frequency tends to be the frequency of the controller itself.
The clock binding has largely replaced that.
Rob
^ permalink raw reply
* Re: [PATCH v2] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Peter Rosin @ 2017-04-03 14:20 UTC (permalink / raw)
To: michael.hennerich, wsa, robh+dt, mark.rutland, linus.walleij
Cc: linux-i2c, devicetree, linux-gpio, linux-kernel
In-Reply-To: <f871f082-3acd-7a28-25c7-dd77d8286ae6@analog.com>
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@analog.com 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.
> 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
^ permalink raw reply
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