* [PATCH 0/3] ARM: dts: Add PCIEC support
From: Biju Das @ 2017-11-13 17:43 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Simon Horman, Magnus Damm, Chris Paterson, Fabrizio Castro,
devicetree, linux-renesas-soc, Biju Das
Hello,
This series aims to add PCIEC support for iWave RZ/G1M (R8A7743) board.
This patch has documentation dependency on below patch
* dt-bindings: PCI: rcar: Add device tree support for r8a7743
https://patchwork.kernel.org/patch/10056407/
This patch series has dependency on below patches
* ARM: dts: r8a7743: Add CAN[01] SoC support
https://patchwork.kernel.org/patch/10046875/
* ARM: dts: iwg20d-q7-common: Add can0 support to carrier board
https://patchwork.kernel.org/patch/10046879/
Biju Das (3):
ARM: dts: r8a7743: Add default PCIe bus clock
ARM: dts: r8a7743: Add PCIe Controller device node
ARM: dts: iwg20d-q7: Enable PCIe Controller
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 8 ++++++++
arch/arm/boot/dts/r8a7743.dtsi | 35 +++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH 1/3] ARM: dts: r8a7743: Add default PCIe bus clock
From: Biju Das @ 2017-11-13 17:43 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Simon Horman, Magnus Damm, Chris Paterson, Fabrizio Castro,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Biju Das
In-Reply-To: <1510594992-63806-1-git-send-email-biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
This patch adds a default PCIe bus clock node.
Signed-off-by: Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Reviewed-by: Fabrizio Castro <fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
---
This patch has dependency on below patch
* ARM: dts: r8a7743: Add CAN[01] SoC support
https://patchwork.kernel.org/patch/10046875/
arch/arm/boot/dts/r8a7743.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 12c7b92..de4b8c6 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -1189,6 +1189,13 @@
clock-frequency = <0>;
};
+ /* External PCIe clock - can be overridden by the board */
+ pcie_bus_clk: pcie_bus {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: r8a7743: Add PCIe Controller device node
From: Biju Das @ 2017-11-13 17:43 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Simon Horman, Magnus Damm, Chris Paterson, Fabrizio Castro,
devicetree, linux-renesas-soc, Biju Das
In-Reply-To: <1510594992-63806-1-git-send-email-biju.das@bp.renesas.com>
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index de4b8c6..9e26c40 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -1164,6 +1164,34 @@
phy-names = "usb";
};
};
+
+ pciec: pcie@fe000000 {
+ compatible = "renesas,pcie-r8a7743",
+ "renesas,pcie-rcar-gen2";
+ reg = <0 0xfe000000 0 0x80000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000
+ 0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000
+ 0x02000000 0 0x30000000 0 0x30000000 0 0x08000000
+ 0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
+ /* Map all possible DDR as inbound ranges */
+ dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000
+ 0x43000000 2 0x00000000 2 0x00000000 1 0x00000000>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 319>, <&pcie_bus_clk>;
+ clock-names = "pcie", "pcie_bus";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 319>;
+ status = "disabled";
+ };
};
/* External root clock */
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: iwg20d-q7: Enable PCIe Controller
From: Biju Das @ 2017-11-13 17:43 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Simon Horman, Magnus Damm, Chris Paterson, Fabrizio Castro,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Biju Das
In-Reply-To: <1510594992-63806-1-git-send-email-biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Enable PCIe Controller & set PCIe bus clock frequency.
Signed-off-by: Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Reviewed-by: Fabrizio Castro <fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
---
This patch has dependency on below patch
* ARM: dts: iwg20d-q7-common: Add can0 support to carrier board
https://patchwork.kernel.org/patch/10046879/
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index 3e4bc4d..54470c6 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -96,6 +96,14 @@
pinctrl-names = "default";
};
+&pcie_bus_clk {
+ clock-frequency = <100000000>;
+};
+
+&pciec {
+ status = "okay";
+};
+
&pfc {
can0_pins: can0 {
groups = "can0_data_d";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 1/3] dt-bindings: phy: Add Cygnus usb phy binding
From: Rob Herring @ 2017-11-13 17:53 UTC (permalink / raw)
To: Raveendra Padasalagi
Cc: Mark Rutland, Kishon Vijay Abraham I, Russell King, Scott Branden,
Ray Jui, Srinath Mannam, Vikram Prakash, Jon Mason,
Florian Fainelli, Yoshihiro Shimoda, Raviteja Garimella,
Rafal Milecki, Arnd Bergmann, Viresh Kumar, Jaehoon Chung,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-ke
In-Reply-To: <CAAFb_vqKLOixSROUvkRFR=hwOqQvnVyV4mu37=MrEBo-pZaF5w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Nov 12, 2017 at 10:23 PM, Raveendra Padasalagi
<raveendra.padasalagi-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> Hi,
>
> On Sat, Nov 11, 2017 at 3:14 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Wed, Nov 08, 2017 at 01:16:41PM +0530, Raveendra Padasalagi wrote:
>>> Add devicetree binding document for broadcom's
>>> Cygnus SoC specific usb phy controller driver.
>>>
>>> Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>> ---
>>> .../bindings/phy/brcm,cygnus-usb-phy.txt | 106 +++++++++++++++++++++
>>> 1 file changed, 106 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt b/Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
>>> new file mode 100644
>>> index 0000000..bbc4b94
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
>>> @@ -0,0 +1,106 @@
>>> +BROADCOM CYGNUS USB PHY
>>> +
>>> +Required Properties:
>>> +- compatible: brcm,cygnus-usb-phy
>>> +- reg : the register start address and length for
>>> + crmu_usbphy_aon_ctrl,
>>> + cdru usb phy control,
>>> + usb host idm registers,
>>> + usb device idm registers.
>>> +- reg-names: a list of the names corresponding to the previous register ranges
>>> + Should contain
>>> + "crmu-usbphy-aon-ctrl",
>>> + "cdru-usbphy",
>>> + "usb2h-idm",
>>> + "usb2d-idm".
>>> +- address-cells: should be 1
>>> +- size-cells: should be 0
>>> +
>>> +Sub-nodes:
>>> + Each port's PHY should be represented as a sub-node.
>>> +
>>> +Sub-nodes required properties:
>>> +- reg: the PHY number
>>> +- #phy-cells must be 1
>>> + The node that uses the phy must provide 1 integer argument specifying
>>> + port number.
>>> +
>>> +Optional Properties:
>>> +- vbus-p#-supply : The regulator for vbus out control for the host
>>
>> Is this a literal # or something else?
>
> Yes, this is a literal. It's assumed # will replace numeric 0-2 for
> each of the ports.
I'm still confused. Which is valid? "vbus-p#-supply" or "vbus-p0-supply"
If the latter, you need to enumerate all valid options. But these are
in sub nodes for each port, so just "vbus-supply" should be
sufficient.
One more question, does Vbus actually supply power to the phy or you
are just associating the Vbus supply to a connector with a port? The
latter needs a connector node instead and Vbus should be part of that.
There's been some attempts at USB connectors, but we don't really have
one yet (the extcon binding is not it).
> In the example it's not shown as the regulators specified in vbus-p#-supply
> are board specific.
Please show in the example. Examples should be complete.
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 1/2] arm64: dts: orange-pi-zero-plus2: fix sdcard detect
From: Sergey Matyukevich @ 2017-11-13 19:24 UTC (permalink / raw)
To: Maxime Ripard
Cc: Jagan Teki, Chen-Yu Tsai, Rob Herring, Mark Rutland, devicetree,
linux-arm-kernel
In-Reply-To: <CAMty3ZB3aXCsd9VkibjxPdA=BXvXr3nMbGJJvtZN_z2SGVUAXA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello Maxime,
On Wed, Nov 08, 2017 at 04:55:32PM +0530, Jagan Teki wrote:
> On Wed, Nov 8, 2017 at 1:42 AM, Sergey Matyukevich <geomatsi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Hi,
> >
> >> >>> > Did you try to boot from sdcard ? I am not able to boot my board from
> >> >>> > sd-card without this change. As I mentioned earlier in my email
> >> >>> > to buildroot mailing list, with mmc debug enabled I see that mmc
> >> >>> > tries to init sd-card when I remove it from the slot.
> >> >>> >
> >> >>> > Maybe there is a minor differences between h/w versions or batches ?
> >> >>> > What is you board version ? I tested on board v1.0.
> >> >>>
> >> >>> Looking at the schematics, it definitely looks like it's active low.
> >> >>
> >> >> Is it ok to merge it then ? Or using 'cd-inverted' property
> >> >> is the preferable option ?
> >> >
> >> > W/o any change mainline works unstable for me, it wasn't booting
> >> > at-all[1] did you find the same?
> >> >
> >> > Even tried with active LOW and cd-inverted.
> >> >
> >> > [1] https://paste.ubuntu.com/25909064/
> >>
> >> Look like something broken for H5 and A64 between v4.14-rc8 to latest
> >
> > Both 4.13.7 and 4.14-rc8 (synched today) kernels worked fine for me.
> > DTS behavior is all the same:
>
> I've tried fresh sync [2] but still see the issue, can you check the
> Image size of log(suspecting on that area)
Do you plan to accept this patch as well ? Or you would prefer to wait
for the confirmation from Jagan as well ?
Regards,
Sergey
--
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: Problem with commit to add overlay symbols to live device tree
From: Frank Rowand @ 2017-11-13 19:48 UTC (permalink / raw)
To: Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w,
frank.rowand-7U/KSKJipcs, robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5a3447ded9eb407989b5af4cc2ad4aab-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org>
On 11/13/17 04:11, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote:
>> On 11/09/17 09:09, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote:
>>>> On 10/20/17 05:11, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote:
>>>>>> Hi Alexander,
>>>>>>
>>>>>> On 10/19/17 10:06, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote:
>>>>>>> Hi Frank, Rob,
>>>>>>>
>>>>>>> I ran some tests with kernel v4.14-rc2, where I came across an issue
>>>>>>> with your commit "of: overlay: add overlay symbols to live device
>>>>>>> tree" (d1651b03c2df75db8eda3fbcd3a07adb337ee8b0,
>>>>>>>
>>>>>>
>>>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/d
>>>>>> rivers/of?h=v4.14-
>>>> rc5&id=d1651b03c2df75db8eda3fbcd3a07adb337ee8b0).
>>>>>>> I am not sure whether this is a problem with your change or whether I
>>>>>>> made a mistake somewhere.
>>>>>>>
>>>>>>> Without this commit, the following device tree overlay works fine on
>>>>>>> a Raspberry Pi:
>>>>>>>
>>>>>>> /dts-v1/;
>>>>>>> /plugin/;
>>>>>>>
>>>>>>> / {
>>>>>>> fragment@0 {
>>>>>>> target-path = "/soc/spi@7e204000";
>>>>>>> __overlay__ {
>>>>>>> #address-cells = <1>;
>>>>>>> #size-cells = <0>;
>>>>>>> status = "okay";
>>>>>>>
>>>>>>> spidev1: spi@1 {
>>>>>>> compatible = "spidev";
>>>>>>> reg = <1>;
>>>>>>> spi-max-frequency = <5000000>;
>>>>>>> };
>>>>>>> };
>>>>>>> };
>>>>>>> };
>>>>>>>
>>>>>>> But with the commit, it is rejected:
>>>>>>>
>>>>>>> OF: overlay: no symbols in root of device tree.
>>>>>>> OF: overlay: of_build_overlay_info() failed for tree@/
>>>>>>> create_overlay: Failed to create overlay (err=-22)
>>>>>>>
>>>>>>> Only if I remove the spidev1 label, it continues to work with the
>>>>>>> commit (but this is not always possible in more complex overlays).
>>>>>>>
>>>>>>> I hope this does not make a difference, but I use the configfs
>>>>>>> interface to load the overlay, that is not part of mainline, but
>>>>>>> shipped by several distributions nonetheless (for example in the
>>>>>>> Raspberry Pi kernel,
>>>>>>>
>>>>>>
>>>>
>> https://github.com/raspberrypi/linux/commit/cccc24635da69799335566eb46
>>>>>> 4a4c9e1fb4a8ad).
>>>>>>>
>>>>>>>
>>>>>>> Could you tell me whether this change in behavior is intentional and
>>>>>>> whether I have to fix something in my usage?
>>>>>>
>>>>>> Yes, the change is intentional.
>>>>>>
>>>>>> If you are using overlays, the expectation is that the device tree
>>>>>> that was used to boot contains symbols (the paths of nodes that
>>>>>> have phandles) so that phandle references in the overlay can be
>>>>>> fixed up to match the values in the base devicetree. Symbols
>>>>>> will be added to the device tree if if is compiled with the
>>>>>> "@" option. This is the first method to avoid the overlay
>>>>>> load error.
>>>>>
>>>>> Ah, thanks, this does solve the problem. I use nothing special to
>>>>> generate the base devicetree, just "make dtbs". Would it make sense
>>>>> to add the "@" option to the kernel Makefile, so that symbols are
>>>>> added by default? Or does this have any downside? I'd suspect that
>>>>
>>>> Yes, there is a large downside. Compiling with the "@" option will
>>>> increase the size of the DTB. Most boards will not use overlays,
>>>> and in those cases this overhead has no value. So "@" should be
>>>> opt-in, not default.
>>>
>>> I see. Is there a way (a config option maybe?) that I can use to get this
>> behavior without patching the Makefile?
>>
>> To compile a DTB with -@, you can specify the value of DTC_FLAGS
>> on the make command line. For example:
>>
>> DTC_FLAGS="-@" make qcom-apq8074-dragonboard.dtb
>>
>> This will work for arm.
>
> I tried that for my Raspberry Pi 2, with the mainline kernel (so no Raspberry Pi specific patches, still v4.14-rc2). Unfortunately, with that DTB the machine does not boot anymore, there is no output at all from the kernel:
>
> ---
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found U-Boot script /boot.scr
> reading /boot.scr
> 696 bytes read in 11 ms (61.5 KiB/s)
> ## Executing script at 02000000
> reading /zImage
> 6017520 bytes read in 791 ms (7.3 MiB/s)
> reading /dtbs/bcm2836-rpi-2-b.dtb
> 18795 bytes read in 188 ms (96.7 KiB/s)
> reading /initramfs-linux.img
> 4173703 bytes read in 546 ms (7.3 MiB/s)
> Kernel image @ 0x1000000 [ 0x000000 - 0x5bd1f0 ]
> ## Flattened Device Tree blob at 00000100
> Booting using the fdt blob at 0x000100
> reserving fdt memory region: addr=0 size=1000
> Using Device Tree in place at 00000100, end 00007a6a
>
> Starting kernel ...
> ---
>
> Using an older DTB for the same kernel build works though.
I could interpret that sentence a couple of different ways, so I
want to clarify. I'm not sure if by "older DTB" you mean a DTB
created from an older version of the kernel source.
If you build the DTB in v4.14-rc2, without the -@ flag, does that
boot successfully? If so, how do the U-boot messages differ?
Later in this email, you say the DTB compiled with -@ is 18KB.
18 * 1024 = 18432 or 0x4800, which is a quite a bit smaller
than the U-boot message would imply ("in place at 00000100, end 00007a6a").
That may be a red-herring, or it might be a clue. I don't know
how much data U-boot adds to the device tree, and I don't know
if that message means what I'm reading it to say.
> I've used the dtc to get back the source for both DTBs and compared
> those. They are identical, except for several (linux,)phandle
> properties that appeared in various nodes and the large __symbols__
> section.
If the new phandles are for nodes that have labels, where the labels
are not referenced elsewhere in the device tree source, then that
is an expected difference. If compiled without the -@ flag then
dtc can discard unused phandles, but with the -@ flag dtc does not
know if an overlay might use the label, so it has to create a
__symbols__ node property for the label and create the phandle
in the labeled node.
One side effect of this is that the phandle values for other
nodes can change. This should not matter because phandle values
used in other properties should be specified as phandle references,
not as integer values. For example, < &my_label >.
It is legal syntax to specify an integer value as a phandle reference,
but doing so means the reference will break if the value of the
referenced phandle changes, for example if a new label is added
then the phandle numbers can change. It is _not_ likely that
this is your problem, but it is one thing to check for.
> Also, the dtc generates two more warnings when parsing the
> new DTB, but I'm not sure whether those are significant:
>
> Warning (clocks_property): property 'clocks' size (21) is invalid, expected multiple of 4 in node /__symbols__
> Warning (gpios_property): property 'gpio' size (19) is invalid, expected multiple of 4 in node /__symbols__
The two warnings can be ignored. Those two properties have string
values in the __symbols__ node. The checks are for the clocks and
gpio properties in normal device nodes, which would not have string
values.
> Can something else be broken in the DTB, that is not visible within
> the DTS?
Something else could be broken in the DTB, but that is not what I
would expect in this case (gut feel).
> Or could this be a size issue? The new DTB is ~6KB larger
> than the old one (18KB vs. 12KB).
It could definitely be a size issue. In theory, there could be a limit in
the bootloader or the kernel. In current implementation, I do not know if
this is actually a possible problem or not, without looking at the source.
The U-boot message "reserving fdt memory region: addr=0 size=1000" might
be a clue. What units is size in?
> Any idea how to debug this further?
I don't know if there are any U-boot features that might help, but it's
worth checking.
For the kernel, look into CONFIG_DEBUG_LL and adding earlyprintk info to
the kernel command line.
>> For some other architectures, you may want to
>> add additional flags to DTC_FLAGS, and for microblaze this will not work
>> with the current makefile (the arch makefiles should probably be changed
>> to be: DTC_FLAGS += ... or to remove the "-p 1024" if no longer needed):
>>
>> $ git grep DTC_FLAGS | grep Makefile: | grep arch
>> arch/c6x/boot/dts/Makefile:DTC_FLAGS ?= -p 1024
>> arch/microblaze/boot/dts/Makefile:DTC_FLAGS := -p 1024
>> arch/openrisc/boot/dts/Makefile:#DTC_FLAGS ?= -p 1024
>> arch/powerpc/boot/Makefile:DTC_FLAGS ?= -p 1024
>>
>>
>>>>> many more people will be hit by this change, since most tutorials for
>>>>> overlays that I have seen include the "@" option for the dtc calls.>
>>>>>> If you compile the overlay with the "@" option then symbols
>>>>>> will be added to the overlay DTB. Previous to commit
>>>>>> d1651b03c2df, these symbols would be ignored when an overlay
>>>>>> was loaded. If you remove the "@" from the compile of
>>>>>> overlays, then everything should work the same way it did
>>>>>> before the commit. This is the second way to avoid the
>>>>>> load overlay error.
>>>
>>> Do I understand that correctly, that when I remove the "@" option
>>> from the dtc calls, the same call should work both with an old
>>> (pre-d1651b03c2df) and a new kernel? If the old kernel just ignored
>>> the symbols, they were not used for anything, so it should not matter
>>> whether they were contained in the overlay DTB or not, right?
>>
>> I just mentioned that workaround as another temporary way to work
>> around your specific case. You should probably just forget I even
>> mentioned it.
>>
>>
>>>>>>
>>>>>>
>>>>>>> Thanks
>>>>>>> Alexander
>>>>>>> --
>>>>>>> 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
>>>>>
>>>>
>>>
>>>
>>
>
--
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] pinctrl: sh-pfc: add R8A77970 PFC support
From: Geert Uytterhoeven @ 2017-11-13 20:32 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Linus Walleij, Rob Herring, Laurent Pinchart, Geert Uytterhoeven,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
Linux-Renesas, Mark Rutland, Vladimir Barinov
In-Reply-To: <20171110181552.227541251@cogentembedded.com>
Hi Sergei,
On Fri, Nov 10, 2017 at 6:59 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add the PFC support for the R8A77970 SoC including pin groups for some
> on-chip devices such as CAN-FD, EtherAVB, [H]SCIF, I2C, INTC-EX, MMC,
> MSIOF, PWM, VIN...
>
> Based on the original (and large) patch by Daisuke Matsushita
> <daisuke.matsushita.ns@hitachi.com>.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Thanks for your patch!
For CPU_ALL_PORT(), pins, groups, and functions:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in sh-pfc-for-v4.16, with the two nits below fixed.
> --- /dev/null
> +++ renesas-drivers/drivers/pinctrl/sh-pfc/pfc-r8a77970.c
[...]
> +/* - VIN0 ------------------------------------------------------------------- */
[...]
> +static const unsigned int vin0_sync_pins[] = {
> + /* VSYNC#, HSYNC# */
> + RCAR_GP_PIN(2, 3), RCAR_GP_PIN(2, 2),
The order of the above doesn't match the order below (will fix while applying).
> +};
> +static const unsigned int vin0_sync_mux[] = {
> + VI0_HSYNC_N_MARK, VI0_VSYNC_N_MARK,
> +};
> +/* - VIN1 ------------------------------------------------------------------- */
[...]
> +static const unsigned int vin1_sync_pins[] = {
> + /* VSYNC#, HSYNC# */
> + RCAR_GP_PIN(3, 3), RCAR_GP_PIN(3, 2),
Likewise.
> +};
> +static const unsigned int vin1_sync_mux[] = {
> + VI1_HSYNC_N_MARK, VI1_VSYNC_N_MARK,
> +};
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver
From: Dan Murphy @ 2017-11-13 20:50 UTC (permalink / raw)
To: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, pavel
Cc: devicetree, linux-kernel, linux-leds, Dan Murphy
This adds the devicetree bindings for the LM3692x
I2C LED string driver.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../devicetree/bindings/leds/leds-lm3692x.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3692x.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
new file mode 100644
index 000000000000..cfef67bd4100
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
@@ -0,0 +1,28 @@
+* Texas Instruments - LM3692x Highly Efficient Dual-String White LED Driver
+
+The LM36922 is an ultra-compact, highly efficient,
+two string white-LED driver designed for LCD display
+backlighting.
+
+Required properties:
+ - compatible:
+ "ti,lm3692x"
+ - reg - I2C slave address
+
+Optional properties:
+ - label - Used for naming LEDs
+ - enable-gpio - gpio pin to enable/disable the device.
+ - supply - "vled" - LED supply
+
+Example:
+
+leds: leds@6 {
+ compatible = "ti,lm3692x";
+ reg = <0x36>;
+ label = "backlight_cluster";
+ enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+ vled-supply = <&vbatt>;
+}
+
+For more product information please see the link below:
+http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
--
2.15.0.124.g7668cbc60
^ permalink raw reply related
* [PATCH 2/2] leds: lm3692x: Introduce LM3692x dual string driver
From: Dan Murphy @ 2017-11-13 20:50 UTC (permalink / raw)
To: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, pavel
Cc: devicetree, linux-kernel, linux-leds, Dan Murphy
In-Reply-To: <20171113205052.25884-1-dmurphy@ti.com>
Introducing the LM3692x Dual-String white LED driver.
Data sheet is located
http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/leds/leds-lm3692x.c | 380 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 380 insertions(+)
create mode 100644 drivers/leds/leds-lm3692x.c
diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
new file mode 100644
index 000000000000..beb753abc7b0
--- /dev/null
+++ b/drivers/leds/leds-lm3692x.c
@@ -0,0 +1,380 @@
+/*
+ * TI lm3692x LED Driver
+ *
+ * Copyright (C) 2017 Texas Instruments
+ *
+ * Author: Dan Murphy <dmurphy@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/leds.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/slab.h>
+
+#define LM3692X_LED_NAME "lm3692x_led"
+
+#define LM3692X_REV 0x0
+#define LM3692X_RESET 0x1
+#define LM3692X_EN 0x10
+#define LM3692X_BRT_CTRL 0x11
+#define LM3692X_PWM_CTRL 0x12
+#define LM3692X_BOOST_CTRL 0x13
+#define LM3692X_AUTO_FREQ_HI 0x15
+#define LM3692X_AUTO_FREQ_LO 0x16
+#define LM3692X_BL_ADJ_THRESH 0x17
+#define LM3692X_BRT_LSB 0x18
+#define LM3692X_BRT_MSB 0x19
+#define LM3692X_FAULT_CTRL 0x1e
+#define LM3692X_FAULT_FLAGS 0x1f
+
+#define LM3692X_SW_RESET BIT(0)
+#define LM3692X_DEVICE_EN BIT(0)
+#define LM3692X_LED1_EN BIT(1)
+#define LM3692X_LED2_EN BIT(2)
+
+/* Brightness Control Bits */
+#define LM3692X_BL_ADJ_POL BIT(0)
+#define LM3692X_RAMP_RATE_125us 0x00
+#define LM3692X_RAMP_RATE_250us BIT(1)
+#define LM3692X_RAMP_RATE_500us BIT(2)
+#define LM3692X_RAMP_RATE_1ms (BIT(1) | BIT(2))
+#define LM3692X_RAMP_RATE_2ms BIT(3)
+#define LM3692X_RAMP_RATE_4ms (BIT(3) | BIT(1))
+#define LM3692X_RAMP_RATE_8ms (BIT(2) | BIT(3))
+#define LM3692X_RAMP_RATE_16ms (BIT(1) | BIT(2) | BIT(3))
+#define LM3692X_RAMP_EN BIT(4)
+#define LM3692X_BRHT_MODE_REG 0x00
+#define LM3692X_BRHT_MODE_PWM BIT(5)
+#define LM3692X_BRHT_MODE_MULTI_RAMP BIT(6)
+#define LM3692X_BRHT_MODE_RAMP_MULTI (BIT(5) | BIT(6))
+#define LM3692X_MAP_MODE_EXP BIT(7)
+
+/* PWM Register Bits */
+#define LM3692X_PWM_FILTER_100 BIT(0)
+#define LM3692X_PWM_FILTER_150 BIT(1)
+#define LM3692X_PWM_FILTER_200 (BIT(0) | BIT(1))
+#define LM3692X_PWM_HYSTER_1LSB BIT(2)
+#define LM3692X_PWM_HYSTER_2LSB BIT(3)
+#define LM3692X_PWM_HYSTER_3LSB (BIT(3) | BIT(2))
+#define LM3692X_PWM_HYSTER_4LSB BIT(4)
+#define LM3692X_PWM_HYSTER_5LSB (BIT(4) | BIT(2))
+#define LM3692X_PWM_HYSTER_6LSB (BIT(4) | BIT(3))
+#define LM3692X_PWM_POLARITY BIT(5)
+#define LM3692X_PWM_SAMP_4MHZ BIT(6)
+#define LM3692X_PWM_SAMP_24MHZ BIT(7)
+
+/* Boost Control Bits */
+#define LM3692X_OCP_PROT_1A BIT(0)
+#define LM3692X_OCP_PROT_1_25A BIT(1)
+#define LM3692X_OCP_PROT_1_5A (BIT(0) | BIT(1))
+#define LM3692X_OVP_21V BIT(2)
+#define LM3692X_OVP_25V BIT(3)
+#define LM3692X_OVP_29V (BIT(2) | BIT(3))
+#define LM3692X_MIN_IND_22UH BIT(4)
+#define LM3692X_BOOST_SW_1MHZ BIT(5)
+#define LM3692X_BOOST_SW_NO_SHIFT BIT(6)
+
+/* Fault Control Bits */
+#define LM3692X_FAULT_CTRL_OVP BIT(0)
+#define LM3692X_FAULT_CTRL_OCP BIT(1)
+#define LM3692X_FAULT_CTRL_TSD BIT(2)
+#define LM3692X_FAULT_CTRL_OPEN BIT(3)
+
+/* Fault Flag Bits */
+#define LM3692X_FAULT_FLAG_OVP BIT(0)
+#define LM3692X_FAULT_FLAG_OCP BIT(1)
+#define LM3692X_FAULT_FLAG_TSD BIT(2)
+#define LM3692X_FAULT_FLAG_SHRT BIT(3)
+#define LM3692X_FAULT_FLAG_OPEN BIT(4)
+
+/**
+ * struct lm3692x_led -
+ * @lock - Lock for reading/writing the device
+ * @client - Pointer to the I2C client
+ * @led_dev - led class device pointer
+ * @regmap - Devices register map
+ * @enable_gpio - VDDIO/EN gpio to enable communication interface
+ * @regulator - LED supply regulator pointer
+ * @label - LED label
+ **/
+struct lm3692x_led {
+ struct mutex lock;
+ struct i2c_client *client;
+ struct led_classdev led_dev;
+ struct regmap *regmap;
+ struct gpio_desc *enable_gpio;
+ struct regulator *regulator;
+ const char *label;
+};
+
+static const struct reg_default lm3692x_reg_defs[] = {
+ {LM3692X_EN, 0xf},
+ {LM3692X_BRT_CTRL, 0x61},
+ {LM3692X_PWM_CTRL, 0x73},
+ {LM3692X_BOOST_CTRL, 0x6f},
+ {LM3692X_AUTO_FREQ_HI, 0x0},
+ {LM3692X_AUTO_FREQ_LO, 0x0},
+ {LM3692X_BL_ADJ_THRESH, 0x0},
+ {LM3692X_BRT_LSB, 0x7},
+ {LM3692X_BRT_MSB, 0xff},
+ {LM3692X_FAULT_CTRL, 0x7},
+};
+
+static const struct regmap_config lm3692x_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = LM3692X_FAULT_FLAGS,
+ .reg_defaults = lm3692x_reg_defs,
+ .num_reg_defaults = ARRAY_SIZE(lm3692x_reg_defs),
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int lm3692x_fault_check(struct lm3692x_led *led)
+{
+ int ret, fault;
+ unsigned int read_buf;
+
+ ret = regmap_read(led->regmap, LM3692X_FAULT_FLAGS, &read_buf);
+ if (ret)
+ goto out;
+
+ fault = read_buf;
+
+ if (fault)
+ dev_err(&led->client->dev, "Detected a fault 0x%X\n",
+ fault);
+out:
+ return ret;
+}
+
+static int lm3692x_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness brt_val)
+{
+ struct lm3692x_led *led =
+ container_of(led_cdev, struct lm3692x_led, led_dev);
+ int led_brightness = (brt_val << 4) + 7;
+ int ret;
+
+ if (brt_val == LED_OFF)
+ led_brightness = 0;
+
+ mutex_lock(&led->lock);
+
+ ret = lm3692x_fault_check(led);
+ if (ret) {
+ dev_err(&led->client->dev, "Cannot read/clear faults\n");
+ goto out;
+ }
+
+ ret = regmap_write(led->regmap, LM3692X_BRT_MSB,
+ (led_brightness & 0xff0) >> 4);
+ if (ret) {
+ dev_err(&led->client->dev, "Cannot write MSB\n");
+ goto out;
+ }
+
+ ret = regmap_write(led->regmap, LM3692X_BRT_LSB,
+ led_brightness & 0x07);
+ if (ret) {
+ dev_err(&led->client->dev, "Cannot write LSB\n");
+ goto out;
+ }
+out:
+ mutex_unlock(&led->lock);
+ return ret;
+}
+
+static int lm3692x_init(struct lm3692x_led *led)
+{
+ int ret;
+
+ if (led->regulator) {
+ ret = regulator_enable(led->regulator);
+ if (ret)
+ dev_err(&led->client->dev,
+ "Failed to enable regulator\n");
+ }
+
+ if (led->enable_gpio)
+ gpiod_direction_output(led->enable_gpio, 1);
+
+ ret = lm3692x_fault_check(led);
+ if (ret) {
+ dev_err(&led->client->dev, "Cannot read/clear faults\n");
+ goto out;
+ }
+
+ ret = regmap_write(led->regmap, LM3692X_BRT_CTRL, 0x00);
+ if (ret)
+ dev_err(&led->client->dev, "Fail writing BRT CTRL\n");
+ /*
+ * For glitch free operation, the following data should
+ * only be written while device enable bit is 0
+ * Per Section 7.5.14 of the data sheet
+ */
+ ret = regmap_write(led->regmap, LM3692X_PWM_CTRL,
+ LM3692X_PWM_FILTER_100 | LM3692X_PWM_SAMP_24MHZ);
+ if (ret)
+ dev_err(&led->client->dev, "Failed programming PWM CTRL\n");
+
+ ret = regmap_write(led->regmap, LM3692X_BOOST_CTRL,
+ LM3692X_BRHT_MODE_RAMP_MULTI |
+ LM3692X_BL_ADJ_POL |
+ LM3692X_RAMP_RATE_250us);
+ if (ret)
+ dev_err(&led->client->dev, "Failed programming BOOST CTRL\n");
+
+ ret = regmap_write(led->regmap, LM3692X_AUTO_FREQ_HI, 0x00);
+ if (ret)
+ dev_err(&led->client->dev, "Failed programming AUTO HI FREQ\n");
+
+ ret = regmap_write(led->regmap, LM3692X_AUTO_FREQ_LO, 0x00);
+ if (ret)
+ dev_err(&led->client->dev, "Failed programming AUTO LO FREQ\n");
+
+
+ ret = regmap_write(led->regmap, LM3692X_BL_ADJ_THRESH, 0x00);
+ if (ret)
+ dev_err(&led->client->dev, "Failed programming BL Threshold\n");
+
+ ret = regmap_write(led->regmap, LM3692X_BRT_CTRL,
+ LM3692X_BL_ADJ_POL | LM3692X_PWM_HYSTER_4LSB);
+ if (ret)
+ dev_err(&led->client->dev, "Failed programming BRT CTRL\n");
+
+ return ret;
+out:
+
+ if (led->enable_gpio)
+ gpiod_direction_output(led->enable_gpio, 0);
+
+ if (led->regulator) {
+ ret = regulator_disable(led->regulator);
+ if (ret)
+ dev_err(&led->client->dev,
+ "Failed to disable regulator\n");
+ }
+
+ return ret;
+}
+
+static int lm3692x_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ int ret;
+ struct lm3692x_led *led;
+ struct device_node *np = client->dev.of_node;
+
+ led = devm_kzalloc(&client->dev, sizeof(*led), GFP_KERNEL);
+ if (!led)
+ return -ENOMEM;
+
+ if (client->dev.of_node) {
+ ret = of_property_read_string(np, "label", &led->label);
+ if (ret)
+ led->label = LM3692X_LED_NAME;
+ }
+
+ led->enable_gpio = devm_gpiod_get_optional(&client->dev,
+ "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(led->enable_gpio)) {
+ ret = PTR_ERR(led->enable_gpio);
+ dev_err(&client->dev, "Failed to get enable gpio: %d\n", ret);
+ return ret;
+ }
+
+ led->regulator = devm_regulator_get(&client->dev, "vled");
+ if (IS_ERR(led->regulator))
+ led->regulator = NULL;
+
+ led->client = client;
+ led->led_dev.name = led->label;
+ led->led_dev.max_brightness = LED_FULL;
+ led->led_dev.brightness_set_blocking = lm3692x_brightness_set;
+
+ mutex_init(&led->lock);
+
+ i2c_set_clientdata(client, led);
+
+ led->regmap = devm_regmap_init_i2c(client, &lm3692x_regmap_config);
+ if (IS_ERR(led->regmap)) {
+ ret = PTR_ERR(led->regmap);
+ dev_err(&client->dev, "Failed to allocate register map: %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = lm3692x_init(led);
+ if (ret)
+ return ret;
+
+ ret = led_classdev_register(&client->dev, &led->led_dev);
+ if (ret) {
+ dev_err(&client->dev, "led register err: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int lm3692x_remove(struct i2c_client *client)
+{
+ struct lm3692x_led *led = i2c_get_clientdata(client);
+ int ret;
+
+ led_classdev_unregister(&led->led_dev);
+
+ if (led->enable_gpio)
+ gpiod_direction_output(led->enable_gpio, 0);
+
+ if (led->regulator) {
+ ret = regulator_disable(led->regulator);
+ if (ret)
+ dev_err(&led->client->dev,
+ "Failed to disable regulator\n");
+ }
+
+ return 0;
+}
+
+static const struct i2c_device_id lm3692x_id[] = {
+ { "lm3692x", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, lm3692x_id);
+
+#ifdef CONFIG_OF
+static const struct of_device_id of_lm3692x_leds_match[] = {
+ { .compatible = "ti,lm3692x", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_lm3692x_leds_match);
+#endif
+
+static struct i2c_driver lm3692x_driver = {
+ .driver = {
+ .name = "lm3692x",
+ .of_match_table = of_match_ptr(of_lm3692x_leds_match),
+ },
+ .probe = lm3692x_probe,
+ .remove = lm3692x_remove,
+ .id_table = lm3692x_id,
+};
+module_i2c_driver(lm3692x_driver);
+
+MODULE_DESCRIPTION("Texas Instruments LM3692X LED driver");
+MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>");
+MODULE_LICENSE("GPL");
--
2.15.0.124.g7668cbc60
^ permalink raw reply related
* Re: [PATCH 3/9] ASoC: cs42l56: bindings: sound: Fix reset GPIO name in example DT binding
From: Rob Herring @ 2017-11-13 21:20 UTC (permalink / raw)
To: Andrew F. Davis
Cc: Liam Girdwood, Mark Brown, Mark Rutland, Benoît Cousson,
Tony Lindgren, Shawn Guo, Sascha Hauer,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171108212505.28320-4-afd-l0cyMroinI0@public.gmane.org>
On Wed, Nov 08, 2017 at 03:24:59PM -0600, Andrew F. Davis wrote:
> The binding states the reset GPIO property shall be named
> "cirrus,gpio-nreset" and this is what the driver looks for,
> but the example uses "gpio-reset". Fix this here.
>
> Fixes: 3bb40619aca8 ("ASoC: cs42l56: bindings: sound: Add bindings for CS42L56 CODEC")
>
> Signed-off-by: Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>
> ---
> Documentation/devicetree/bindings/sound/cs42l56.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/cs42l56.txt b/Documentation/devicetree/bindings/sound/cs42l56.txt
> index 4feb0eb27ea4..4ba520a28ae8 100644
> --- a/Documentation/devicetree/bindings/sound/cs42l56.txt
> +++ b/Documentation/devicetree/bindings/sound/cs42l56.txt
> @@ -55,7 +55,7 @@ Example:
> codec: codec@4b {
> compatible = "cirrus,cs42l56";
> reg = <0x4b>;
> - gpio-reset = <&gpio 10 0>;
> + cirrus,gpio-nreset = <&gpio 10 0>;
Can we deprecate this and use reset-gpios instead?
> cirrus,chgfreq-divisor = <0x05>;
> cirrus.ain1_ref_cfg;
> cirrus,micbias-lvl = <5>;
> --
> 2.15.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/2] Add R8A77970/Eagle GPIO support
From: Sergei Shtylyov @ 2017-11-13 21:23 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Magnus Damm, Mark Rutland, linux-arm-kernel
Hello!
Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20171113-v4.14' tag. We're adding the R8A77970 GPIO nodes
and then describing the PHY IRQ for EtherAVB device declared earlier.
These patches depend on the R8A77970/Eagle PFC suport patchset in order
to apply/compile.
[1/2] arm64: dts: renesas: r8a77970: add GPIO support
[2/2] arm64: dts: renesas: eagle: specify EtherAVB PHY IRQ
WBR, Sergei
^ permalink raw reply
* [PATCH 0/2] Add R8A77970/Eagle GPIO support
From: Sergei Shtylyov @ 2017-11-13 21:23 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Magnus Damm, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hello!
Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20171113-v4.14' tag. We're adding the R8A77970 GPIO nodes
and then describing the PHY IRQ for EtherAVB device declared earlier.
These patches depend on the R8A77970/Eagle PFC suport patchset in order
to apply/compile.
[1/2] arm64: dts: renesas: r8a77970: add GPIO support
[2/2] arm64: dts: renesas: eagle: specify EtherAVB PHY IRQ
WBR, Sergei
--
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 0/2] Add R8A77970/Eagle GPIO support
From: Sergei Shtylyov @ 2017-11-13 21:23 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Mark Rutland, Magnus Damm, linux-arm-kernel
Hello!
Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20171113-v4.14' tag. We're adding the R8A77970 GPIO nodes
and then describing the PHY IRQ for EtherAVB device declared earlier.
These patches depend on the R8A77970/Eagle PFC suport patchset in order
to apply/compile.
[1/2] arm64: dts: renesas: r8a77970: add GPIO support
[2/2] arm64: dts: renesas: eagle: specify EtherAVB PHY IRQ
WBR, Sergei
^ permalink raw reply
* [PATCH 1/2] arm64: dts: renesas: r8a77970: add GPIO support
From: Sergei Shtylyov @ 2017-11-13 21:23 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Magnus Damm, Mark Rutland, linux-arm-kernel, Sergei Shtylyov
[-- Attachment #1: arm64-dts-renesas-r8a77970-add-GPIO-support.patch --]
[-- Type: text/plain, Size: 3187 bytes --]
Describe all 6 GPIO controllers in the R8A77970 device tree.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 90 ++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -139,6 +139,96 @@
reg = <0 0xe6060000 0 0x504>;
};
+ gpio0: gpio@e6050000 {
+ compatible = "renesas,gpio-r8a77970",
+ "renesas,rcar-gen3-gpio";
+ reg = <0 0xe6050000 0 0x50>;
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 0 22>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ clocks = <&cpg CPG_MOD 912>;
+ power-domains = <&sysc 32>;
+ resets = <&cpg 912>;
+ };
+
+ gpio1: gpio@e6051000 {
+ compatible = "renesas,gpio-r8a77970",
+ "renesas,rcar-gen3-gpio";
+ reg = <0 0xe6051000 0 0x50>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 32 28>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ clocks = <&cpg CPG_MOD 911>;
+ power-domains = <&sysc 32>;
+ resets = <&cpg 911>;
+ };
+
+ gpio2: gpio@e6052000 {
+ compatible = "renesas,gpio-r8a77970",
+ "renesas,rcar-gen3-gpio";
+ reg = <0 0xe6052000 0 0x50>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 64 17>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ clocks = <&cpg CPG_MOD 910>;
+ power-domains = <&sysc 32>;
+ resets = <&cpg 910>;
+ };
+
+ gpio3: gpio@e6053000 {
+ compatible = "renesas,gpio-r8a77970",
+ "renesas,rcar-gen3-gpio";
+ reg = <0 0xe6053000 0 0x50>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 96 17>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ clocks = <&cpg CPG_MOD 909>;
+ power-domains = <&sysc 32>;
+ resets = <&cpg 909>;
+ };
+
+ gpio4: gpio@e6054000 {
+ compatible = "renesas,gpio-r8a77970",
+ "renesas,rcar-gen3-gpio";
+ reg = <0 0xe6054000 0 0x50>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 128 6>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ clocks = <&cpg CPG_MOD 908>;
+ power-domains = <&sysc 32>;
+ resets = <&cpg 908>;
+ };
+
+ gpio5: gpio@e6055000 {
+ compatible = "renesas,gpio-r8a77970",
+ "renesas,rcar-gen3-gpio";
+ reg = <0 0xe6055000 0 0x50>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 160 15>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ clocks = <&cpg CPG_MOD 907>;
+ power-domains = <&sysc 32>;
+ resets = <&cpg 907>;
+ };
+
intc_ex: interrupt-controller@e61c0000 {
compatible = "renesas,intc-ex-r8a77970", "renesas,irqc";
#interrupt-cells = <2>;
^ permalink raw reply
* [PATCH 2/2] arm64: dts: renesas: eagle: specify EtherAVB PHY IRQ
From: Sergei Shtylyov @ 2017-11-13 21:23 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Magnus Damm, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sergei Shtylyov
[-- Attachment #1: arm64-dts-renesas-eagle-specify-EtherAVB-PHY-IRQ.patch --]
[-- Type: text/plain, Size: 976 bytes --]
Specify EtherAVB PHY IRQ in the Eagle board's device tree, now that we
have the GPIO support (previously phylib had to resort to polling).
Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 2 ++
1 file changed, 2 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -44,6 +44,8 @@
phy0: ethernet-phy@0 {
rxc-skew-ps = <1500>;
reg = <0>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
};
};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] Input: twl4030-vibra: fix sibling-node lookup
From: Dmitry Torokhov @ 2017-11-13 21:54 UTC (permalink / raw)
To: Johan Hovold
Cc: Lee Jones, linux-input, linux-kernel, stable, Peter Ujfalusi,
Marek Belisko, Rob Herring, devicetree
In-Reply-To: <20171113115102.GU11226@localhost>
On Mon, Nov 13, 2017 at 12:51:02PM +0100, Johan Hovold wrote:
> On Mon, Nov 13, 2017 at 10:20:28AM +0000, Lee Jones wrote:
> > On Mon, 13 Nov 2017, Johan Hovold wrote:
> >
> > > On Mon, Nov 13, 2017 at 09:11:44AM +0000, Lee Jones wrote:
> > > > On Sun, 12 Nov 2017, Johan Hovold wrote:
> > > >
> > > > > [ +CC: Lee, Rob and device-tree list ]
> > > > >
> > > > > On Sat, Nov 11, 2017 at 09:50:59AM -0800, Dmitry Torokhov wrote:
> > > > > > On Sat, Nov 11, 2017 at 04:43:37PM +0100, Johan Hovold wrote:
> > > > > > > A helper purported to look up a child node based on its name was using
> > > > > > > the wrong of-helper and ended up prematurely freeing the parent of-node
> > > > > > > while searching the whole device tree depth-first starting at the parent
> > > > > > > node.
> > > > > >
> > > > > > Ugh, this all is pretty ugly business. Can we teach MFD to allow
> > > > > > specifying firmware node to be attached to the platform devices it
> > > > > > creates in mfd_add_device() so that the leaf drivers simply call
> > > > > > device_property_read_XXX() on their own device and not be bothered with
> > > > > > weird OF refcount issues or what node they need to locate and parse?
> > > >
> > > > If a child compatible is provided, we already set the child's
> > > > of_node. It's then up to the driver (set) author(s) to use it in the
> > > > correct manner.
> > > >
> > > > > Yeah, that may have helped. You can actually specify a compatible string
> > > > > in struct mfd_cell today which does make mfd_add_device() associate a
> > > > > matching child node.
> > > > >
> > > > > Some best practice regarding how to deal with MFD and device tree would
> > > > > be good to determine and document too. For example, when should
> > > > > of_platform_populate() be used in favour of mfd_add_device()?
> > > >
> > > > When the device supports DT and its entire hierarchical layout, along
> > > > with all of its attributes can be expressed in DT.
> > >
> > > Ok, a follow up: When there are different variants of an MFD and that
> > > affects the child drivers, then that should be expressed in in the child
> > > node compatibles rather than having the child match on the parent node?
> > >
> > > I'm asking because this came up recently during review and their seems
> > > to be no precedent for matching on the parent compatible in child
> > > drivers:
> > >
> > > https://lkml.kernel.org/r/20171105154725.GA11226@localhost
> >
> > Accessing the parent's of_device_id .data directly doesn't sit well
> > with me. The parent driver should pass this type of configuration
> > though pdata IMHO.
>
> The child driver is only matching on the parent-node compatible string
> IIRC, and therefore keeps its own table of all parent compatibles with
> its own set of (child) private match data (i.e. the parent compatible
> property is matched first by the parent driver, and then again by the
> child).
>
> Passing through pdata here is not possible since mfd_add_device() isn't
> used, right? It could of course be described using properties of the
> child node (e.g. by using different child compatible strings).
>
> > > > > And how best to deal with sibling nodes, which is part of the problem
> > > > > here (I think the mfd should have provided a flag rather than having
> > > > > subdrivers deal with sibling nodes, for example).
> > > >
> > > > I disagree. The only properties the MFD (parent) driver is interested
> > > > in is ones which are shared across multiple child devices.
> > > > *Everything* which pertains to only a single child device should be
> > > > handled by its accompanying driver.
> > >
> > > Even if that means leaking details of one child driver into a sibling?
> >
> > Not sure what you mean here. Could you please elaborate or provide an
> > example?
>
> I mean that the sibling node needs to be aware of the name, compatible
> string, or other node properties of its sibling node to be able to parse
> sibling nodes itself (rather than the sibling or parent doing so on its
> behalf). But it seems you answer this below.
>
> > > Isn't it then cleaner to use the parent MFD to coordinate between the
> > > cells, just as we do for IO?
> > >
> > > In this case a child driver looked up a sibling node based on name, but
> >
> > This should not be allowed. If >1 sibling requires access to a
> > particular property, this is normally evidence enough that this
> > property should be shared and handled by the parent.
> >
> > > that doesn't mean the node is active, that there's a driver bound, or
> > > that the sibling node has some other random property for example. The
> > > parent could be used for such coordination, if only to pass information
> > > from one sibling to another.
> >
> > Right.
>
> Ok, it seems we're in agreement here.
>
> Given that MFD has evolved over time and device-tree support has been
> added retroactively to some drivers, we've ended up with a multitude of
> different ways of dealing with such issues. I think it may still be a
> good idea to jot down some best practices for future driver developers.
FWIW here is the patch allowing attaching fwnode to an MFD cell that is
not using of_compatible (because if historical reasons). Completely
untested as I do not have this hardware.
If this is somewhat acceptable I can untangle core from twl6040
changes.
Thanks.
>
> Thanks,
> Johan
--
Dmitry
Attach fwnode to MFD cells
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/misc/twl6040-vibra.c | 32 ++++++++++----------------------
drivers/mfd/mfd-core.c | 2 ++
drivers/mfd/twl6040.c | 14 +++++++-------
include/linux/mfd/core.h | 6 ++++++
include/linux/mfd/twl6040.h | 2 ++
5 files changed, 27 insertions(+), 29 deletions(-)
diff --git a/drivers/input/misc/twl6040-vibra.c b/drivers/input/misc/twl6040-vibra.c
index 5690eb7ff954..bd9507cf5608 100644
--- a/drivers/input/misc/twl6040-vibra.c
+++ b/drivers/input/misc/twl6040-vibra.c
@@ -242,23 +242,13 @@ static SIMPLE_DEV_PM_OPS(twl6040_vibra_pm_ops, twl6040_vibra_suspend, NULL);
static int twl6040_vibra_probe(struct platform_device *pdev)
{
struct device *twl6040_core_dev = pdev->dev.parent;
- struct device_node *twl6040_core_node;
struct vibra_info *info;
int vddvibl_uV = 0;
int vddvibr_uV = 0;
int error;
- of_node_get(twl6040_core_dev->of_node);
- twl6040_core_node = of_find_node_by_name(twl6040_core_dev->of_node,
- "vibra");
- if (!twl6040_core_node) {
- dev_err(&pdev->dev, "parent of node is missing?\n");
- return -EINVAL;
- }
-
info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
if (!info) {
- of_node_put(twl6040_core_node);
dev_err(&pdev->dev, "couldn't allocate memory\n");
return -ENOMEM;
}
@@ -267,18 +257,16 @@ static int twl6040_vibra_probe(struct platform_device *pdev)
info->twl6040 = dev_get_drvdata(pdev->dev.parent);
- of_property_read_u32(twl6040_core_node, "ti,vibldrv-res",
- &info->vibldrv_res);
- of_property_read_u32(twl6040_core_node, "ti,vibrdrv-res",
- &info->vibrdrv_res);
- of_property_read_u32(twl6040_core_node, "ti,viblmotor-res",
- &info->viblmotor_res);
- of_property_read_u32(twl6040_core_node, "ti,vibrmotor-res",
- &info->vibrmotor_res);
- of_property_read_u32(twl6040_core_node, "ti,vddvibl-uV", &vddvibl_uV);
- of_property_read_u32(twl6040_core_node, "ti,vddvibr-uV", &vddvibr_uV);
-
- of_node_put(twl6040_core_node);
+ device_property_read_u32(&pdev->dev, "ti,vibldrv-res",
+ &info->vibldrv_res);
+ device_property_read_u32(&pdev->dev, "ti,vibrdrv-res",
+ &info->vibrdrv_res);
+ device_property_read_u32(&pdev->dev, "ti,viblmotor-res",
+ &info->viblmotor_res);
+ device_property_read_u32(&pdev->dev, "ti,vibrmotor-res",
+ &info->vibrmotor_res);
+ device_property_read_u32(&pdev->dev, "ti,vddvibl-uV", &vddvibl_uV);
+ device_property_read_u32(&pdev->dev, "ti,vddvibr-uV", &vddvibr_uV);
if ((!info->vibldrv_res && !info->viblmotor_res) ||
(!info->vibrdrv_res && !info->vibrmotor_res)) {
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index c57e407020f1..2792fe40e2e4 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -186,6 +186,8 @@ static int mfd_add_device(struct device *parent, int id,
mfd_acpi_add_device(cell, pdev);
+ set_secondary_fwnode(&pdev->dev, cell->fwnode);
+
if (cell->pdata_size) {
ret = platform_device_add_data(pdev,
cell->platform_data, cell->pdata_size);
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index d66502d36ba0..2994a8885c7e 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -97,13 +97,9 @@ static struct reg_sequence twl6040_patch[] = {
};
-static bool twl6040_has_vibra(struct device_node *node)
+static struct device_node *twl6040_get_vibra(struct device_node *node)
{
-#ifdef CONFIG_OF
- if (of_find_node_by_name(node, "vibra"))
- return true;
-#endif
- return false;
+ return node ? of_get_child_by_name(node, "vibra") : NULL;
}
int twl6040_reg_read(struct twl6040 *twl6040, unsigned int reg)
@@ -766,11 +762,13 @@ static int twl6040_probe(struct i2c_client *client,
children++;
/* Vibra input driver support */
- if (twl6040_has_vibra(node)) {
+ twl6040->vibra_node = twl6040_get_vibra(node);
+ if (twl6040->vibra_node) {
irq = regmap_irq_get_virq(twl6040->irq_data, TWL6040_IRQ_VIB);
cell = &twl6040->cells[children];
cell->name = "twl6040-vibra";
+ cell->fwnode = &twl6040->vibra_node->fwnode;
twl6040_vibra_rsrc[0].start = irq;
twl6040_vibra_rsrc[0].end = irq;
cell->resources = twl6040_vibra_rsrc;
@@ -817,6 +815,8 @@ static int twl6040_remove(struct i2c_client *client)
mfd_remove_devices(&client->dev);
+ of_node_put(twl6040->vibra_node);
+
regulator_bulk_disable(TWL6040_NUM_SUPPLIES, twl6040->supplies);
return 0;
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index 99c0395fe1f9..452f9d4de98a 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -58,6 +58,12 @@ struct mfd_cell {
/* Matches ACPI */
const struct mfd_cell_acpi_match *acpi_match;
+ /*
+ * Secondary firmware node that should be associated with the
+ * platform device corresponding to the cell.
+ */
+ struct fwnode_handle *fwnode;
+
/*
* These resources can be specified relative to the parent device.
* For accessing hardware you should use resources from the platform dev
diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
index a2e88761c09f..9eee44c4fc1f 100644
--- a/include/linux/mfd/twl6040.h
+++ b/include/linux/mfd/twl6040.h
@@ -232,6 +232,8 @@ struct twl6040 {
struct mfd_cell cells[TWL6040_CELLS];
struct completion ready;
+ struct device_node *vibra_node;
+
int audpwron;
int power_count;
int rev;
^ permalink raw reply related
* Re: [PATCH] drm/tilcdc: Remove obsolete "ti, tilcdc, slave" dts binding support
From: Rob Herring @ 2017-11-13 22:40 UTC (permalink / raw)
To: Jyri Sarha
Cc: devicetree@vger.kernel.org, Tony Lindgren, Mark Brown,
Stephen Boyd, dri-devel, David Airlie, Tomi Valkeinen,
Laurent Pinchart, Benoit Cousson, Frank Rowand
In-Reply-To: <1510576927-4023-1-git-send-email-jsarha@ti.com>
On Mon, Nov 13, 2017 at 6:42 AM, Jyri Sarha <jsarha@ti.com> wrote:
> This patch removes DRM_TILCDC_SLAVE_COMPAT option for supporting the
> obsolete "ti,tilcdc,slave" device tree binding. The new of_graph based
> binding - that is widely used in other drm driver too - has been
> supported since Linux v4.2. Maintaining the the backwards dts
> conversion code in 0the DRM_TILCDC_SLAVE_COMPAT has become a nuisance
> for the device/of development so the we decided to drop it after Linux
> v4.14, the 2017 LTS.
>
> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> ---
> drivers/gpu/drm/tilcdc/Kconfig | 11 -
> drivers/gpu/drm/tilcdc/Makefile | 3 -
> drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 269 -------------------------
> drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts | 72 -------
> drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h | 25 ---
> 5 files changed, 380 deletions(-)
> delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
> delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts
> delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v2 0/8] arm64: Add initial Actions Semi S700 and CubieBoard7 support
From: Andreas Färber @ 2017-11-13 23:34 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Thomas Liau, Jeff Chen, 张东风,
刘炜, 张天益, 梅利,
support, linux-kernel, Andreas Färber, Ahha Lee, devicetree,
Daniel Lezcano, Thomas Gleixner
Hello,
This series prepares the Actions Semi S700 SoC and Cubietech CubieBoard7.
It boots equally far as the S900 based Bubblegum-96 these patches are based on,
i.e. into an initrd with serial and all four cores up.
v2 modifies the clocksource driver patches and adds SPS patches.
Not having succeeded to replace the bootloader on eMMC or to try
booting from SD, the only working way I've found to boot mainline kernels
appears to be booting into Android, then issuing "reboot bootloader". U-Boot
is lacking the saveenv command, so it wasn't possible to change the bootdelay
to facilitate this.
Cf. https://en.opensuse.org/HCL:CubieBoard7
Work branch:
https://github.com/afaerber/linux/commits/bg96-next
Have a lot of fun!
Cheers,
Andreas
v1 -> v2:
* Prepended patch converting CLOCKSOURCE_OF_DECLARE() to TIMER_OF_DECLARE() (Daniel)
* Added patches for SPS
Cc: Ahha Lee <lee@cubietech.com>
Cc: support@cubietech.com
Cc: Jeff Chen <jeff.chen@actions-semi.com>
Cc: devicetree@vger.kernel.org
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Andreas Färber (8):
dt-bindings: arm: actions: Add S700 and CubieBoard7
dt-bindings: timer: Add Actions Semi S700
clocksource: owl: Adopt TIMER_OF_DECLARE()
clocksource: owl: Prepare S700
arm64: dts: actions: Add S700 and CubieBoard7
dt-bindings: power: Add Actions Semi S700 SPS
soc: actions: sps: Add S700
arm64: dts: actions: Add S700 SPS node
Documentation/devicetree/bindings/arm/actions.txt | 15 ++
.../devicetree/bindings/power/actions,owl-sps.txt | 2 +
.../bindings/timer/actions,owl-timer.txt | 1 +
arch/arm64/boot/dts/actions/Makefile | 2 +
arch/arm64/boot/dts/actions/s700-cubieboard7.dts | 47 ++++++
arch/arm64/boot/dts/actions/s700.dtsi | 170 +++++++++++++++++++++
drivers/clocksource/owl-timer.c | 5 +-
drivers/soc/actions/owl-sps.c | 42 +++++
include/dt-bindings/power/owl-s700-powergate.h | 20 +++
9 files changed, 302 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/actions/s700-cubieboard7.dts
create mode 100644 arch/arm64/boot/dts/actions/s700.dtsi
create mode 100644 include/dt-bindings/power/owl-s700-powergate.h
--
2.13.6
^ permalink raw reply
* [PATCH v2 1/8] dt-bindings: arm: actions: Add S700 and CubieBoard7
From: Andreas Färber @ 2017-11-13 23:34 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Thomas Liau, Jeff Chen, 张东风,
刘炜, 张天益, 梅利,
support, linux-kernel, Andreas Färber, Rob Herring,
Mark Rutland, devicetree
In-Reply-To: <20171113233427.5386-1-afaerber@suse.de>
Document the Actions Semi S700 SoC and the Cubietech CubieBoard7.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
v1 -> v2: Unchanged
Documentation/devicetree/bindings/arm/actions.txt | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/actions.txt b/Documentation/devicetree/bindings/arm/actions.txt
index ced764a8549e..544a8855fad5 100644
--- a/Documentation/devicetree/bindings/arm/actions.txt
+++ b/Documentation/devicetree/bindings/arm/actions.txt
@@ -25,6 +25,21 @@ Root node property compatible must contain, depending on board:
- LeMaker Guitar Base Board rev. B: "lemaker,guitar-bb-rev-b", "lemaker,guitar"
+S700 SoC
+========
+
+Required root node properties:
+
+- compatible : must contain "actions,s700"
+
+
+Boards:
+
+Root node property compatible must contain, depending on board:
+
+ - Cubietech CubieBoard7: "cubietech,cubieboard7"
+
+
S900 SoC
========
--
2.13.6
^ permalink raw reply related
* [PATCH v2 2/8] dt-bindings: timer: Add Actions Semi S700
From: Andreas Färber @ 2017-11-13 23:34 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Thomas Liau, Jeff Chen, 张东风,
刘炜, 张天益, 梅利,
support, linux-kernel, Andreas Färber, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Mark Rutland, devicetree
In-Reply-To: <20171113233427.5386-1-afaerber@suse.de>
Define a compatible string for the Actions Semi S700 SoC timer.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
v1 -> v2: Unchanged
Documentation/devicetree/bindings/timer/actions,owl-timer.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/timer/actions,owl-timer.txt b/Documentation/devicetree/bindings/timer/actions,owl-timer.txt
index e3c28da80cb2..977054f87563 100644
--- a/Documentation/devicetree/bindings/timer/actions,owl-timer.txt
+++ b/Documentation/devicetree/bindings/timer/actions,owl-timer.txt
@@ -2,6 +2,7 @@ Actions Semi Owl Timer
Required properties:
- compatible : "actions,s500-timer" for S500
+ "actions,s700-timer" for S700
"actions,s900-timer" for S900
- reg : Offset and length of the register set for the device.
- interrupts : Should contain the interrupts.
--
2.13.6
^ permalink raw reply related
* [PATCH v2 5/8] arm64: dts: actions: Add S700 and CubieBoard7
From: Andreas Färber @ 2017-11-13 23:34 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Thomas Liau, Jeff Chen, 张东风,
刘炜, 张天益, 梅利,
support, linux-kernel, Andreas Färber, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, devicetree
In-Reply-To: <20171113233427.5386-1-afaerber@suse.de>
Add Device Trees for S700 SoC and Cubietech CubieBoard7.
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
v1 -> v2: Unchanged
arch/arm64/boot/dts/actions/Makefile | 2 +
arch/arm64/boot/dts/actions/s700-cubieboard7.dts | 47 +++++++
arch/arm64/boot/dts/actions/s700.dtsi | 164 +++++++++++++++++++++++
3 files changed, 213 insertions(+)
create mode 100644 arch/arm64/boot/dts/actions/s700-cubieboard7.dts
create mode 100644 arch/arm64/boot/dts/actions/s700.dtsi
diff --git a/arch/arm64/boot/dts/actions/Makefile b/arch/arm64/boot/dts/actions/Makefile
index cc4661256356..d8b923480f5a 100644
--- a/arch/arm64/boot/dts/actions/Makefile
+++ b/arch/arm64/boot/dts/actions/Makefile
@@ -1 +1,3 @@
+dtb-$(CONFIG_ARCH_ACTIONS) += s700-cubieboard7.dtb
+
dtb-$(CONFIG_ARCH_ACTIONS) += s900-bubblegum-96.dtb
diff --git a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
new file mode 100644
index 000000000000..e562f04c2490
--- /dev/null
+++ b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
@@ -0,0 +1,47 @@
+/*
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "s700.dtsi"
+
+/ {
+ compatible = "cubietech,cubieboard7", "actions,s700";
+ model = "CubieBoard7";
+
+ aliases {
+ serial3 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x80000000>;
+ };
+
+ memory@1,e0000000 {
+ device_type = "memory";
+ reg = <0x1 0xe0000000 0x0 0x0>;
+ };
+
+ uart3_clk: uart3-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <921600>;
+ #clock-cells = <0>;
+ };
+};
+
+&timer {
+ clocks = <&hosc>;
+};
+
+&uart3 {
+ status = "okay";
+ clocks = <&uart3_clk>;
+};
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
new file mode 100644
index 000000000000..b54df405aaeb
--- /dev/null
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -0,0 +1,164 @@
+/*
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ compatible = "actions,s700";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secmon@1f000000 {
+ reg = <0x0 0x1f000000 0x0 0x1000000>;
+ no-map;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ arm-pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ hosc: hosc {
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ #clock-cells = <0>;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gic: interrupt-controller@e00f1000 {
+ compatible = "arm,gic-400";
+ reg = <0x0 0xe00f1000 0x0 0x1000>,
+ <0x0 0xe00f2000 0x0 0x2000>,
+ <0x0 0xe00f4000 0x0 0x2000>,
+ <0x0 0xe00f6000 0x0 0x2000>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
+
+ uart0: serial@e0120000 {
+ compatible = "actions,s900-uart", "actions,owl-uart";
+ reg = <0x0 0xe0120000 0x0 0x2000>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart1: serial@e0122000 {
+ compatible = "actions,s900-uart", "actions,owl-uart";
+ reg = <0x0 0xe0122000 0x0 0x2000>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart2: serial@e0124000 {
+ compatible = "actions,s900-uart", "actions,owl-uart";
+ reg = <0x0 0xe0124000 0x0 0x2000>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart3: serial@e0126000 {
+ compatible = "actions,s900-uart", "actions,owl-uart";
+ reg = <0x0 0xe0126000 0x0 0x2000>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart4: serial@e0128000 {
+ compatible = "actions,s900-uart", "actions,owl-uart";
+ reg = <0x0 0xe0128000 0x0 0x2000>;
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart5: serial@e012a000 {
+ compatible = "actions,s900-uart", "actions,owl-uart";
+ reg = <0x0 0xe012a000 0x0 0x2000>;
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart6: serial@e012c000 {
+ compatible = "actions,s900-uart", "actions,owl-uart";
+ reg = <0x0 0xe012c000 0x0 0x2000>;
+ interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ timer: timer@e024c000 {
+ compatible = "actions,s700-timer";
+ reg = <0x0 0xe024c000 0x0 0x4000>;
+ interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "timer1";
+ };
+ };
+};
--
2.13.6
^ permalink raw reply related
* [PATCH v2 6/8] dt-bindings: power: Add Actions Semi S700 SPS
From: Andreas Färber @ 2017-11-13 23:34 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Thomas Liau, Jeff Chen, 张东风,
刘炜, 张天益, 梅利,
support, linux-kernel, Andreas Färber, Rob Herring,
Mark Rutland, devicetree
In-Reply-To: <20171113233427.5386-1-afaerber@suse.de>
Define power domains for Actions Semi S700 SoC Smart Power System (SPS).
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
v2: New
.../devicetree/bindings/power/actions,owl-sps.txt | 2 ++
include/dt-bindings/power/owl-s700-powergate.h | 20 ++++++++++++++++++++
2 files changed, 22 insertions(+)
create mode 100644 include/dt-bindings/power/owl-s700-powergate.h
diff --git a/Documentation/devicetree/bindings/power/actions,owl-sps.txt b/Documentation/devicetree/bindings/power/actions,owl-sps.txt
index 007b9a7ae723..78edd63641e8 100644
--- a/Documentation/devicetree/bindings/power/actions,owl-sps.txt
+++ b/Documentation/devicetree/bindings/power/actions,owl-sps.txt
@@ -2,10 +2,12 @@ Actions Semi Owl Smart Power System (SPS)
Required properties:
- compatible : "actions,s500-sps" for S500
+ "actions,s700-sps" for S700
- reg : Offset and length of the register set for the device.
- #power-domain-cells : Must be 1.
See macros in:
include/dt-bindings/power/owl-s500-powergate.h for S500
+ include/dt-bindings/power/owl-s700-powergate.h for S700
Example:
diff --git a/include/dt-bindings/power/owl-s700-powergate.h b/include/dt-bindings/power/owl-s700-powergate.h
new file mode 100644
index 000000000000..4ded16bc074f
--- /dev/null
+++ b/include/dt-bindings/power/owl-s700-powergate.h
@@ -0,0 +1,20 @@
+/*
+ * Actions Semi S700 SPS
+ *
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+#ifndef DT_BINDINGS_POWER_OWL_S700_POWERGATE_H
+#define DT_BINDINGS_POWER_OWL_S700_POWERGATE_H
+
+#define S700_PD_VDE 0
+#define S700_PD_VCE_SI 1
+#define S700_PD_USB2_1 2
+#define S700_PD_HDE 3
+#define S700_PD_DMA 4
+#define S700_PD_DS 5
+#define S700_PD_USB3 6
+#define S700_PD_USB2_0 7
+
+#endif
--
2.13.6
^ permalink raw reply related
* [PATCH v2 8/8] arm64: dts: actions: Add S700 SPS node
From: Andreas Färber @ 2017-11-13 23:34 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Thomas Liau, Jeff Chen, 张东风,
刘炜, 张天益, 梅利,
support, linux-kernel, Andreas Färber, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, devicetree
In-Reply-To: <20171113233427.5386-1-afaerber@suse.de>
Add a node to the S700 Device Tree for the Smart Power System (SPS).
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
v2: New
To be squashed into 5/8 if binding gets acked.
arch/arm64/boot/dts/actions/s700.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index b54df405aaeb..6a39968b209f 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -154,6 +154,12 @@
status = "disabled";
};
+ sps: power-controller@e01b0100 {
+ compatible = "actions,s700-sps";
+ reg = <0x0 0xe01b0100 0x0 0x100>;
+ #power-domain-cells = <1>;
+ };
+
timer: timer@e024c000 {
compatible = "actions,s700-timer";
reg = <0x0 0xe024c000 0x0 0x4000>;
--
2.13.6
^ permalink raw reply related
* Re: [PATCH v9 3/7] mailbox: qcom: Move the apcs struct into a separate header
From: Stephen Boyd @ 2017-11-14 2:12 UTC (permalink / raw)
To: Georgi Djakov
Cc: Bjorn Andersson, jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mturquette-rdvid1DuHRBWk0Htik3J/w,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5bad4c4b-362b-ba9f-3072-1cced7a004dd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 10/27, Georgi Djakov wrote:
> Hi Bjorn,
>
> Thanks for reviewing!
>
> On 10/26/2017 07:28 AM, Bjorn Andersson wrote:
> > On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote:
> >
> >> Move the structure shared by the APCS IPC device and its subdevices
> >> into a separate header file.
> >>
> >
> > As you're creating the apcs regmap with devm_regmap_init_mmio() you can
> > just call dev_get_regmap(dev->parent) in your child to get the handle.
>
> Ok, thanks!
>
> >
> > But I would prefer that you just add the clock code to the existing
> > driver.
>
> This will require an ack from Stephen, and i got the impression that he
> prefers a separate clk driver [1].
>
> Stephen, are you ok with registering the clocks from the apcs mailbox
> driver?
>
> [1] https://lkml.org/lkml/2017/6/26/750
The parent regmap "trick" was the plan. Is something wrong with
that?
Not having random clk drivers scattered throughout the tree is
sort of nice because it makes for an easier time finding things
that are similar. Maybe that's an abuse of the driver model
though? Just to get things into some same directory. I'm fine
either way.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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
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