* Re: [PATCH v3 2/7] mfd: retu: Add OF device ID table
From: Javier Martinez Canillas @ 2017-04-03 15:45 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-kernel, devicetree, Rob Herring
In-Reply-To: <20170403111502.lotjpd746vkhekkg@dell>
Hello Lee,
On 04/03/2017 07:15 AM, Lee Jones wrote:
[snip]
>>
>> +static const struct of_device_id retu_of_match[] = {
>> + { .compatible = "nokia,retu-mfd" },
>> + { .compatible = "nokia,tahvo-mfd" },
>
> Please drop the "-mfd".
>
Yes, I also didn't like it but I didn't want to change it since that would
mean that backward compatiblity and bisect-ability will be broken by this
change.
In other words, just adding a vendor prefix won't cause an issue if patches
are merged independently since if DTS patches are merged before, the driver
will still lookup using the I2C device ID table. And if the drivers patches
are picked before, the DTS will match using the OF device ID table.
But changing to "nokia,retu" and "nokia,tahvo" means that you will need to
pick all patches and also that the DTS and drivers changes will have to be
done in the same patch. If you are OK with that, then I can change in the
next version.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v3 0/4] tty/serial: meson_uart: add support for core clock handling
From: Kevin Hilman @ 2017-04-03 15:44 UTC (permalink / raw)
To: Helmut Klein
Cc: devicetree, linux-kernel, linux-serial, linux-amlogic, linux-clk,
linux-arm-kernel
In-Reply-To: <20170331165437.26227-1-hgkr.klein@gmail.com>
Helmut Klein <hgkr.klein@gmail.com> writes:
> To be able to use the three none AO uarts of the meson gx SoCs (uart_A,
s/none/non/
> uart_B & uart_C), the core clock has to be enabled (see chapter 22.3 of
> the public s905 data sheet).
> At least the u-boot of my s905 based media player (netxeon minimx-g)
> doesn't do this. so the driver must enable the clock.
FYI: even if a booloader enablesq clocks, it's important that the kernel
enable clocks that it uses so the kernel can be independent of any
bootloader.
> This patch set does:
> - exposes the UART clock ids to the dtb
> - adds documentation for the dt-bindings of meson_uart
> - adds the core clock handling to the driver
> - adds the core clock handling to meson-gxbb.dtsi and meson-gxl.dtsi
>
> The patchset is based on the branch "master" of the repository in [1]
The master branch in my tree just tracks mainline master branch.
To avoid conflicts with other on-going DT changes, the DT patches should
probably be based on top of my v4.12/dt64 branch.
Kevin
^ permalink raw reply
* Re: [RFC PATCH 4/5] dt-bindings: soc/fsl: Update reserved memory binding for QBMan
From: Rob Herring @ 2017-04-03 15:42 UTC (permalink / raw)
To: Roy Pledge
Cc: devicetree, madalin.bucur, robin.murphy, oss, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1490822037-6752-5-git-send-email-roy.pledge@nxp.com>
On Wed, Mar 29, 2017 at 05:13:56PM -0400, Roy Pledge wrote:
> Updates the QMan and BMan device tree bindings for reserved memory
> nodes. This makes the reserved memory allocation compatiable with
s/compatiable/compatible/
> the shared-dma-pool usage.
This change is not backwards compatible. Please state that and explain
why that is okay. If PPC needs to not change, then the old strings and
properties should remain, but deprecated.
>
> Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
> ---
> Documentation/devicetree/bindings/soc/fsl/bman.txt | 10 +++++-----
> Documentation/devicetree/bindings/soc/fsl/qman.txt | 16 +++++++++-------
> 2 files changed, 14 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 1/7] mfd: Add Device Tree bindings document for retu/tahvo ASIC chips
From: Javier Martinez Canillas @ 2017-04-03 15:40 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-kernel, devicetree, Rob Herring, Mark Rutland
In-Reply-To: <20170403111301.52hm4wsplimviqso@dell>
Hello Lee,
Thanks a lot for your feedback.
On 04/03/2017 07:13 AM, Lee Jones wrote:
> On Sat, 01 Apr 2017, Javier Martinez Canillas wrote:
>
>> There are Device Tree source files defining a device node for the
>> retu/tahvo I2C chip, but there isn't a DT binding document for it.
>>
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>> Documentation/devicetree/bindings/mfd/retu.txt | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/retu.txt b/Documentation/devicetree/bindings/mfd/retu.txt
>> new file mode 100644
>> index 000000000000..2309e599a731
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/retu.txt
>> @@ -0,0 +1,19 @@
>> +* Device tree bindings for Nokia Retu and Tahvo multi-function device
>> +
>> +Retu and Tahvo are a multi-function devices found on Nokia Internet
>> +Tablets (770, N800 and N810).
>
> More information please. What functions to they serve?
>
I'm not really familiar with these drivers, I'm just doing this as a part
of the bigger work to fix the I2C core to report a proper OF modaliases.
So I took the information I could find in the driver Kconfig and headers,
but I'll see if I can find more information in the driver or if there is
documentation about these online.
>> +Required properties:
>> +- compatible: "nokia,retu-mfd" or "nokia,tahvo-mfd"
>> +- reg: Specifies the I2C slave address of the ASIC chip
>> +
>> +Example:
>> +
>> +i2c0 {
>> + retu_mfd: retu@1 {
>
> Please avoid the term MFD at all times when using Device Tree. DT is
> meant to be OS agnostic and MFD is a Linuxisum.
>
Yes, sorry. I just copied the DT snippet from a DTS that used this, I'll
remove it on the next version.
>> + compatible = "nokia,retu-mfd";
>> + interrupt-parent = <&gpio4>;
>> + interrupts = <12 IRQ_TYPE_EDGE_RISING>;
>> + reg = <0x1>;
>> + };
>> +};
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v3 01/11] dt-bindings: add binding for the Allwinner DE2 CCU
From: Rob Herring @ 2017-04-03 15:33 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170329194613.55548-2-icenowy-h8G6r0blFSE@public.gmane.org>
On Thu, Mar 30, 2017 at 03:46:03AM +0800, Icenowy Zheng wrote:
> From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>
> Allwinner "Display Engine 2.0" contains some clock controls in it.
>
> In order to add them as clock drivers, we need a device tree binding.
> Add the binding here.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
> Changes in v3:
> - Fill the address space length of DE2 CCU to 0x100000, just reach the start of mixer0.
Why? You waste virtual memory space making this bigger than it needs to
be. Not an issue so much for 64-bit.
>
> .../devicetree/bindings/clock/sun8i-de2.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/sun8i-de2.txt b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
> new file mode 100644
> index 000000000000..34cf79c05f13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
> @@ -0,0 +1,31 @@
> +Allwinner Display Engine 2.0 Clock Control Binding
> +--------------------------------------------------
> +
> +Required properties :
> +- compatible: must contain one of the following compatibles:
> + - "allwinner,sun8i-a83t-de2-clk"
> + - "allwinner,sun50i-a64-de2-clk"
> + - "allwinner,sun50i-h5-de2-clk"
> +
> +- reg: Must contain the registers base address and length
> +- clocks: phandle to the clocks feeding the display engine subsystem.
> + Three are needed:
> + - "mod": the display engine module clock
> + - "bus": the bus clock for the whole display engine subsystem
> +- clock-names: Must contain the clock names described just above
> +- resets: phandle to the reset control for the display engine subsystem.
> +- #clock-cells : must contain 1
> +- #reset-cells : must contain 1
> +
> +Example:
> +de2_clocks: clock@01000000 {
Drop the leading 0s. dtc in linux-next will now warn on this with W=1
compile. Looks like sunxi has a lot of them. Please fix so we don't keep
repeating this same copy-n-paste.
> + compatible = "allwinner,sun50i-a64-de2-clk";
> + reg = <0x01000000 0x100000>;
> + clocks = <&ccu CLK_DE>,
> + <&ccu CLK_BUS_DE>;
> + clock-names = "mod",
> + "bus";
> + resets = <&ccu RST_BUS_DE>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> +};
> --
> 2.12.0
>
^ permalink raw reply
* Re: [PATCH] Input: silead - list all supported compatible strings in binding document
From: Rob Herring @ 2017-04-03 15:25 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Dolca, Hans de Goede,
Dmitry Torokhov, linux-input-u79uwXL29TY76Z2rM5mHXA, Mark Rutland
In-Reply-To: <20170329182531.17349-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Wed, Mar 29, 2017 at 02:25:31PM -0400, Javier Martinez Canillas wrote:
> The driver contains compatible strings for different models, but the DT
> binding doc only lists one of them. Add the remaining to the document.
>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> ---
>
> .../devicetree/bindings/input/touchscreen/silead_gsl1680.txt | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
"dt-bindings: input: ..." is preferred for the subject, but no need to
respin just for that.
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 v4 12/23] drivers/fsi: Add documentation for GPIO bindings
From: Rob Herring @ 2017-04-03 15:24 UTC (permalink / raw)
To: Christopher Bostic
Cc: mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
joel-U3u1mxZcP9KHXe+LvDLADg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andrew-zrmu5oMJ5Fs, alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
In-Reply-To: <20170329174340.89109-13-cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Wed, Mar 29, 2017 at 12:43:29PM -0500, Christopher Bostic wrote:
> From: Chris Bostic <cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>
> Add fsi master gpio device tree binding documentation
>
> Signed-off-by: Chris Bostic <cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
> ---
> .../devicetree/bindings/fsi/fsi-master-gpio.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
But what happened to the bus description? There's never a need to
describe slave devices (even discoverable buses like USB and PCI still
need them sometimes)? As it stands now, I have no idea what FSI is from
reading bindings/fsi/*.
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
* Re: [PATCH v3 2/7] dt-bindings: rtc: document the rtc-sh bindings
From: Rob Herring @ 2017-04-03 15:16 UTC (permalink / raw)
To: Chris Brandt
Cc: Alessandro Zummo, Alexandre Belloni, Mark Rutland, Simon Horman,
Geert Uytterhoeven, rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170329173035.67477-3-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Wed, Mar 29, 2017 at 10:30:30AM -0700, Chris Brandt wrote:
> Add the binding documentation for rtc-sh which is an RTC for
> SuperH and RZ/A SoCs.
>
> Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> ---
> v3:
> * remove 'power-domains' from example
> * update commit message subject and body
> v2:
> * added interrupt-names and clock-names
> * clocks now include counting sources
> * changed 'is a RTC' to 'is an RTC' in commit message
> ---
> Documentation/devicetree/bindings/rtc/rtc-sh.txt | 28 ++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-sh.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v4 1/2] power: supply: ltc2941-battery-gauge: Add vendor to compatibles in binding
From: Rob Herring @ 2017-04-03 15:15 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Sebastian Reichel
In-Reply-To: <20170329160057.8298-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Wed, Mar 29, 2017 at 12:00:56PM -0400, Javier Martinez Canillas wrote:
> The DT binding document for LTC2941 and LTC2943 battery gauges did not use
> a vendor prefix in the listed compatible strings. The driver says that the
> manufacturer is Linear Technology which is "lltc" in vendor-prefixes.txt.
>
> There isn't an upstream Device Tree source file that has nodes defined for
> these devices, so there's no need to keep the old compatible strings.
>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/power/supply/ltc2941.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 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 v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver
From: Russell King - ARM Linux @ 2017-04-03 15:15 UTC (permalink / raw)
To: Rob Herring
Cc: Steve Longerbeam, Steve Longerbeam, Mark Rutland, Shawn Guo,
kernel@pengutronix.de, Fabio Estevam, Mauro Carvalho Chehab,
Hans Verkuil, Nick Dyer, markus.heiser, Philipp Zabel,
Laurent Pinchart, Benoit Parrot, Geert Uytterhoeven,
Arnd Bergmann, Sudip Mukherjee, Minghsiu Tsai, tiffany lin,
Jean-Christophe Trotin <jean-christo>
In-Reply-To: <20170403140743.trxep36s4z4piyl3@rob-hp-laptop>
On Mon, Apr 03, 2017 at 09:07:43AM -0500, Rob Herring wrote:
> On Tue, Mar 28, 2017 at 05:35:52PM -0700, Steve Longerbeam wrote:
> > I assume if there's another binding doc in progress, it means
> > someone is working on another Synopsys DW CSI-2 subdevice driver.
>
> Yes. see http://patchwork.ozlabs.org/patch/736177/
>
> > Unfortunately I don't have the time to contribute and switch to
> > this other subdevice, and do test/debug.
>
> >From a DT perspective, I'm not asking that you share the subdevice
> driver, only the binding. Simply put, there's 1 h/w block here, so there
> should only be 1 binding. The binding is an ABI, so you can't just merge
> it and change it later.
I think it would be nice to have some kind of standard base binding
for CSI2 interfaces, but beyond the standard compatible/reg/interrupts
and graph properties, I'm not sure what it would look like.
As far as those properties go, the iMX6 version does better than the
DW version, because we specify the full graph, whereas the DW version
only specifies the downstream link. Once that's done, there's some
properties (like those specifying the output configuration) which
probably ought to be moved to the graph links instead, once they exist.
So, if anything, I think it's the DW version needs to be augmented with
fuller information, and some of the properties moved.
Also, as I've mentioned in my other reply, while they may both appear
to be called "Synopsys DW CSI-2" devices, they appear to be quite
different from the hardware perspective.
The rest
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver
From: Russell King - ARM Linux @ 2017-04-03 15:03 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Andrew-CT Chen (陳智迪),
Minghsiu Tsai, Sakari Ailus, Nick Dyer, Songjun Wu, Hans Verkuil,
Pavel Machek, Robert Jarzmik, devel, markus.heiser,
Laurent Pinchart, shuah, Geert Uytterhoeven, Steve Longerbeam,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
kernel@pengutronix.de, Arnd Bergmann, Mauro Carvalho Chehab,
Benoit Parrot
In-Reply-To: <20170403141135.6rwwftkiqqicmn6a@rob-hp-laptop>
On Mon, Apr 03, 2017 at 09:11:35AM -0500, Rob Herring wrote:
> On Wed, Mar 29, 2017 at 09:39:05AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Mar 28, 2017 at 07:21:34PM -0500, Rob Herring wrote:
> > > On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> > > > Add bindings documentation for the i.MX media driver.
> > > >
> > > > Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> > > > ---
> > > > Documentation/devicetree/bindings/media/imx.txt | 74 +++++++++++++++++++++++++
> > > > 1 file changed, 74 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/media/imx.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/media/imx.txt b/Documentation/devicetree/bindings/media/imx.txt
> > > > new file mode 100644
> > > > index 0000000..3059c06
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/media/imx.txt
> > > > @@ -0,0 +1,74 @@
> > > > +Freescale i.MX Media Video Device
> > > > +=================================
> > > > +
> > > > +Video Media Controller node
> > > > +---------------------------
> > > > +
> > > > +This is the media controller node for video capture support. It is a
> > > > +virtual device that lists the camera serial interface nodes that the
> > > > +media device will control.
> > > > +
> > > > +Required properties:
> > > > +- compatible : "fsl,imx-capture-subsystem";
> > > > +- ports : Should contain a list of phandles pointing to camera
> > > > + sensor interface ports of IPU devices
> > > > +
> > > > +example:
> > > > +
> > > > +capture-subsystem {
> > > > + compatible = "fsl,imx-capture-subsystem";
> > > > + ports = <&ipu1_csi0>, <&ipu1_csi1>;
> > > > +};
> > > > +
> > > > +fim child node
> > > > +--------------
> > > > +
> > > > +This is an optional child node of the ipu_csi port nodes. If present and
> > > > +available, it enables the Frame Interval Monitor. Its properties can be
> > > > +used to modify the method in which the FIM measures frame intervals.
> > > > +Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
> > > > +Frame Interval Monitor.
> > > > +
> > > > +Optional properties:
> > > > +- fsl,input-capture-channel: an input capture channel and channel flags,
> > > > + specified as <chan flags>. The channel number
> > > > + must be 0 or 1. The flags can be
> > > > + IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
> > > > + IRQ_TYPE_EDGE_BOTH, and specify which input
> > > > + capture signal edge will trigger the input
> > > > + capture event. If an input capture channel is
> > > > + specified, the FIM will use this method to
> > > > + measure frame intervals instead of via the EOF
> > > > + interrupt. The input capture method is much
> > > > + preferred over EOF as it is not subject to
> > > > + interrupt latency errors. However it requires
> > > > + routing the VSYNC or FIELD output signals of
> > > > + the camera sensor to one of the i.MX input
> > > > + capture pads (SD1_DAT0, SD1_DAT1), which also
> > > > + gives up support for SD1.
> > > > +
> > > > +
> > > > +mipi_csi2 node
> > > > +--------------
> > > > +
> > > > +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
> > > > +CSI-2 sensors.
> > > > +
> > > > +Required properties:
> > > > +- compatible : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
> > >
> > > As I mentioned in v5, there's a DW CSI2 binding in progress. This
> > > needs to be based on that.
> >
> > Maybe someone can provide some kind of reference to it, and it's
> > associated driver?
>
> Let me Google that for you (TM). The reference is in my comments on v5.
> Here's a reference to it [1].
Looking at the actual driver, it seems to at least have a different
register layout:
register imx6 dw
version 0x000 0x000
n_lanes 0x004 0x004
phy_shutdownz 0x008 -
dphy_resetz 0x00c -
resetn 0x010 0x008
phy_state 0x014 -
data_ids_1 0x018 0x010
data_ids_2 0x01c 0x014
err1 0x020 -
err2 0x024 -
msk1 0x028 -
msk2 0x02c -
phy_tst_ctrl0 0x030 -
phy_tst_ctrl1 0x034 -
sft_reset 0xf00 - (not part of CSI2, but a IMX6 specific
CSI2 to IPU gasket layer, but lives in
CSI2's register region)
The DW version has many more registers than are documented by the iMX6
version. Only the first two registers appear to be common between these
two devices, and maybe five registers exist (I haven't checked whether
their bit layouts are the same though.)
So, I would say that these are two different devices.
As for the bindings, the differences are:
compatible: dw uses "snps,dw-mipi-csi"
imx6 uses "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2"
reg: dw and imx6 both use a single base address
interrupts: dw requires one interrupt, imx6 has up to two interrupts
output-type: relevant for DW, meaningless on imx6 (not documented)
phys: DW seems to specify a separate PHY, on imx6 the PHY
control/status is tightly integrated into the CSI2
register set, and the PHY itself is undocumented except
for some specific programming documented in source code.
resets: DW lists this under "required", but suffixes it with
(optional), so is it optional or is it not?
Meaningless on imx6.
port: imx6 requires this, and must specify all (5) connectivity -
one node to connect to the camera, and four nodes connecting
to the rest of the capture system.
dw specifies only one port node to be connected to the
camera.
dw document is unclear whether this is an optional or
required property. imx6 requires all five nodes.
clocks, imx6 requires the clocks and clock names to be specified,
clock-names: dw requires no clocks. DW binding would need these to be
optional.
So, the only common properties are "reg" and maybe "interrupts".
The DW binding also looks specific to the SoC implementation - the lack
of any specification in it as to how the module relates to other parts
of the capture system _appears_ to mean that its relationship with those
other parts can't be established from DT. That's a problem when it comes
to iMX6, because the CSI2 relationship to the one or two IPU units depends
on the SoC (whether it's a single/dual-lite or dual/quad version.)
Therefore, it does not make sense to (a) use the same compatible, or
(b) use the same binding.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH RFC] serial: imx: support an enable-gpio
From: Fabio Estevam @ 2017-04-03 15:01 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer
In-Reply-To: <1468400495-10471-1-git-send-email-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hi Uwe,
On Wed, Jul 13, 2016 at 6:01 AM, Uwe Kleine-König
<u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 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>
Since this is not imx serial specific it could be made more generic.
What about extending
Documentation/devicetree/bindings/serial/slave-device.txt to handle
this GPIO, or maybe a regulator?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4 1/2] dt-bindings: thermal: add support for Broadcom's Northstar thermal
From: Rafał Miłecki @ 2017-04-03 14:57 UTC (permalink / raw)
To: Jon Mason, 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, Zhang Rui,
linux-arm-kernel
In-Reply-To: <CAC3K-4q4Cfo5Nzpxf3v_MHBJgPFxny5PCEEiBZM-9TBStGS-GQ@mail.gmail.com>
On 04/03/2017 04:54 PM, Jon Mason wrote:
> 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 a lot for this valuable info! I'll send next version today.
_______________________________________________
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 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
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