* Re: [PATCH v3 3/6] mtd: rawnand: tegra: add devicetree binding
From: Boris Brezillon @ 2018-06-06 10:45 UTC (permalink / raw)
To: Thierry Reding
Cc: Dmitry Osipenko, Stefan Agner, dwmw2, computersforpeace,
marek.vasut, robh+dt, mark.rutland, benjamin.lindqvist, pgaikwad,
dev, mirza.krak, richard, pdeschrijver, linux-kernel, krzk,
jonathanh, devicetree, linux-mtd, marcel, miquel.raynal,
linux-tegra
In-Reply-To: <20180606103903.GJ11810@ulmo>
Hi Thierry,
On Wed, 6 Jun 2018 12:39:03 +0200
Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Jun 05, 2018 at 11:19:14PM +0300, Dmitry Osipenko wrote:
> > On 01.06.2018 10:30, Boris Brezillon wrote:
> > > On Fri, 1 Jun 2018 00:16:34 +0200
> > > Stefan Agner <stefan@agner.ch> wrote:
> > >
> > >> This adds the devicetree binding for the Tegra 2 NAND flash
> > >> controller.
> > >>
> > >> Signed-off-by: Lucas Stach <dev@lynxeye.de>
> > >> Signed-off-by: Stefan Agner <stefan@agner.ch>
> > >> ---
> > >> .../bindings/mtd/nvidia-tegra20-nand.txt | 64 +++++++++++++++++++
> > >> 1 file changed, 64 insertions(+)
> > >> create mode 100644 Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> > >> new file mode 100644
> > >> index 000000000000..5cd984ef046b
> > >> --- /dev/null
> > >> +++ b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> > >> @@ -0,0 +1,64 @@
> > >> +NVIDIA Tegra NAND Flash controller
> > >> +
> > >> +Required properties:
> > >> +- compatible: Must be one of:
> > >> + - "nvidia,tegra20-nand"
> > >
> > > As discussed previously, I prefer "nvidia,tegra20-nand-controller" or
> > > "nvidia,tegra20-nfc".
> > >
> > >> +- reg: MMIO address range
> > >> +- interrupts: interrupt output of the NFC controller
> > >> +- clocks: Must contain an entry for each entry in clock-names.
> > >> + See ../clocks/clock-bindings.txt for details.
> > >> +- clock-names: Must include the following entries:
> > >> + - nand
> > >> +- resets: Must contain an entry for each entry in reset-names.
> > >> + See ../reset/reset.txt for details.
> > >> +- reset-names: Must include the following entries:
> > >> + - nand
> > >> +
> > >> +Optional children nodes:
> > >> +Individual NAND chips are children of the NAND controller node. Currently
> > >> +only one NAND chip supported.
> > >> +
> > >> +Required children node properties:
> > >> +- reg: An integer ranging from 1 to 6 representing the CS line to use.
> > >> +
> > >> +Optional children node properties:
> > >> +- nand-ecc-mode: String, operation mode of the NAND ecc mode. Currently only
> > >> + "hw" is supported.
> > >> +- nand-ecc-algo: string, algorithm of NAND ECC.
> > >> + Supported values with "hw" ECC mode are: "rs", "bch".
> > >> +- nand-bus-width : See nand.txt
> > >> +- nand-on-flash-bbt: See nand.txt
> > >> +- nand-ecc-strength: integer representing the number of bits to correct
> > >> + per ECC step (always 512). Supported strength using HW ECC
> > >> + modes are:
> > >> + - RS: 4, 6, 8
> > >> + - BCH: 4, 8, 14, 16
> > >> +- nand-ecc-maximize: See nand.txt
> > >> +- nand-is-boot-medium: Makes sure only ECC strengths supported by the boot ROM
> > >> + are choosen.
> > >> +- wp-gpios: GPIO specifier for the write protect pin.
> > >> +
> > >> +Optional child node of NAND chip nodes:
> > >> +Partitions: see partition.txt
> > >> +
> > >> + Example:
> > >> + nand@70008000 {
> > >
> > > nand-controller@70008000 {
> > >
> > >> + compatible = "nvidia,tegra20-nand";
> > >
> > > compatible = "nvidia,tegra20-nand-controller";
> > >
> > > or
> > >
> > > compatible = "nvidia,tegra20-nfc";
> > >
> >
> > Maybe it's just me, but when I'm reading "nfc", my first association is the
> > "Near Field Communication". Probably an explicit
> > "nvidia,tegra20-nand-controller" variant is more preferable.
I also prefer nvidia,tegra20-nand-controller.
>
> We don't really use a -controller suffix for any of the other
> controllers because it is kind of implied. "nfc" is also not something
> that is ever referred to in the technical documentation.
>
> "nvidia,tegra20-nand" would be most consistent with all the rest of
> Tegra (c.f. "nvidia,tegra*-ahci", "nvidia,tegra*-pci",
> "nvidia,tegra*-hda", "nvidia,tegra*-gmi", ...).
People get confused about what this node represents when you just have
"nvidia,tegra20-nand", and then you start seeing NAND related props or
partition nodes being defined under the NAND controller node.
I really prefer to have the "-controller" prefix here to avoid such
confusions.
Regards,
Boris
^ permalink raw reply
* Re: [PATCH v3 3/6] mtd: rawnand: tegra: add devicetree binding
From: Thierry Reding @ 2018-06-06 10:39 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Boris Brezillon, Stefan Agner, dwmw2, computersforpeace,
marek.vasut, robh+dt, mark.rutland, benjamin.lindqvist, pgaikwad,
dev, mirza.krak, richard, pdeschrijver, linux-kernel, krzk,
jonathanh, devicetree, linux-mtd, marcel, miquel.raynal,
linux-tegra
In-Reply-To: <faa40dac-ab2a-2d43-3a43-2d46cebcd539@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3732 bytes --]
On Tue, Jun 05, 2018 at 11:19:14PM +0300, Dmitry Osipenko wrote:
> On 01.06.2018 10:30, Boris Brezillon wrote:
> > On Fri, 1 Jun 2018 00:16:34 +0200
> > Stefan Agner <stefan@agner.ch> wrote:
> >
> >> This adds the devicetree binding for the Tegra 2 NAND flash
> >> controller.
> >>
> >> Signed-off-by: Lucas Stach <dev@lynxeye.de>
> >> Signed-off-by: Stefan Agner <stefan@agner.ch>
> >> ---
> >> .../bindings/mtd/nvidia-tegra20-nand.txt | 64 +++++++++++++++++++
> >> 1 file changed, 64 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> >> new file mode 100644
> >> index 000000000000..5cd984ef046b
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> >> @@ -0,0 +1,64 @@
> >> +NVIDIA Tegra NAND Flash controller
> >> +
> >> +Required properties:
> >> +- compatible: Must be one of:
> >> + - "nvidia,tegra20-nand"
> >
> > As discussed previously, I prefer "nvidia,tegra20-nand-controller" or
> > "nvidia,tegra20-nfc".
> >
> >> +- reg: MMIO address range
> >> +- interrupts: interrupt output of the NFC controller
> >> +- clocks: Must contain an entry for each entry in clock-names.
> >> + See ../clocks/clock-bindings.txt for details.
> >> +- clock-names: Must include the following entries:
> >> + - nand
> >> +- resets: Must contain an entry for each entry in reset-names.
> >> + See ../reset/reset.txt for details.
> >> +- reset-names: Must include the following entries:
> >> + - nand
> >> +
> >> +Optional children nodes:
> >> +Individual NAND chips are children of the NAND controller node. Currently
> >> +only one NAND chip supported.
> >> +
> >> +Required children node properties:
> >> +- reg: An integer ranging from 1 to 6 representing the CS line to use.
> >> +
> >> +Optional children node properties:
> >> +- nand-ecc-mode: String, operation mode of the NAND ecc mode. Currently only
> >> + "hw" is supported.
> >> +- nand-ecc-algo: string, algorithm of NAND ECC.
> >> + Supported values with "hw" ECC mode are: "rs", "bch".
> >> +- nand-bus-width : See nand.txt
> >> +- nand-on-flash-bbt: See nand.txt
> >> +- nand-ecc-strength: integer representing the number of bits to correct
> >> + per ECC step (always 512). Supported strength using HW ECC
> >> + modes are:
> >> + - RS: 4, 6, 8
> >> + - BCH: 4, 8, 14, 16
> >> +- nand-ecc-maximize: See nand.txt
> >> +- nand-is-boot-medium: Makes sure only ECC strengths supported by the boot ROM
> >> + are choosen.
> >> +- wp-gpios: GPIO specifier for the write protect pin.
> >> +
> >> +Optional child node of NAND chip nodes:
> >> +Partitions: see partition.txt
> >> +
> >> + Example:
> >> + nand@70008000 {
> >
> > nand-controller@70008000 {
> >
> >> + compatible = "nvidia,tegra20-nand";
> >
> > compatible = "nvidia,tegra20-nand-controller";
> >
> > or
> >
> > compatible = "nvidia,tegra20-nfc";
> >
>
> Maybe it's just me, but when I'm reading "nfc", my first association is the
> "Near Field Communication". Probably an explicit
> "nvidia,tegra20-nand-controller" variant is more preferable.
We don't really use a -controller suffix for any of the other
controllers because it is kind of implied. "nfc" is also not something
that is ever referred to in the technical documentation.
"nvidia,tegra20-nand" would be most consistent with all the rest of
Tegra (c.f. "nvidia,tegra*-ahci", "nvidia,tegra*-pci",
"nvidia,tegra*-hda", "nvidia,tegra*-gmi", ...).
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
From: Archit Taneja @ 2018-06-06 10:21 UTC (permalink / raw)
To: Heiko Stübner
Cc: devicetree, boris.brezillon, linux-arm-msm, tomi.valkeinen,
briannorris, philippe.cornu, dri-devel, nickey.yang, robh+dt,
thierry.reding, laurent.pinchart, maxime.ripard
In-Reply-To: <1719302.7h5mBFHA8i@diego>
On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote:
> Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:
>> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:
>>> Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:
>>>> Add binding info for peripherals that support dual-channel DSI. Add
>>>> corresponding optional bindings for DSI host controllers that may
>>>> be configured in this mode. Add an example of an I2C controlled
>>>> device operating in dual-channel DSI mode.
>>>>
>>>> Signed-off-by: Archit Taneja <architt@codeaurora.org>
>>>
>>> Looks like a great solution for that problem, so
>>> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
>>>
>>> As I'm looking into that for my rk3399-scarlet device right now and
>>> couldn't find this patchset in the kernel yet, is it planned to
>>> merge or refresh these binding changes or were problems encountered.
>>>
>>> At least an Ack/Review from Rob seems to be missing.
>>
>> I forgot about these patches. Rob had reviewed the first one in
>> the set the second one still needed an Ack. I'll post a v3
>> that adds the Reviewed-bys and fixes a small typo.
>
> very nice ... because it looks like yesterday I managed to make the Rockchip
> dsi work in dual mode following this.
>
> But one question came up, do you really want two input ports on the panel
> side? I.e. hardware-wise, I guess the panel will have one 8-lane or so input
> thatonly gets split up on the soc side onto 2 dsi controllers?
I think all dual DSI panels actually have 2 DSI controllers/parsers
within them, one on each port. The MIPI DSI spec doesn't support 8
lanes. Also, the pixels coming out of the host are distributed among
the lanes differently than what would have been the case with a
'theoretical' 8 lane receiver.
Other than that, some dual DSI panels only accept DSI commands on the
'master' port, where as others expect the same command to be sent across
both the ports.
Therefore, I think it's better to represent dual DSI panels having 2
DSI input ports.
Your DT looks good to me.
Thanks,
Archit
>
> So right now I'm operating with a devicetree like
>
> &mipi_dsi {
> status = "okay";
> clock-master;
>
> ports {
> mipi_out: port@1 {
> reg = <1>;
>
> mipi_out_panel: endpoint {
> remote-endpoint = <&mipi_in_panel>;
> };
> };
> };
>
> mipi_panel: panel@0 {
> compatible = "innolux,p097pfg";
> reg = <0>;
> backlight = <&backlight>;
> enable-gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>;
> pinctrl-names = "default";
> pinctrl-0 = <&display_rst_l>;
>
> port {
> #address-cells = <1>;
> #size-cells = <0>;
>
> mipi_in_panel: endpoint@0 {
> reg = <0>;
> remote-endpoint = <&mipi_out_panel>;
> };
>
> mipi1_in_panel: endpoint@1 {
> reg = <1>;
> remote-endpoint = <&mipi1_out_panel>;
> };
> };
> };
> };
>
> &mipi_dsi1 {
> status = "okay";
>
> ports {
> mipi1_out: port@1 {
> reg = <1>;
>
> mipi1_out_panel: endpoint {
> remote-endpoint = <&mipi1_in_panel>;
> };
> };
> };
> };
>
>
> I guess it is a matter of preference on what reflects the hardware
> best, so maybe that's Robs call?
>
>
> Heiko
>
>>>> ---
>>>> v2:
>>>> - Specify that clock-master is a boolean property.
>>>> - Drop/add unit-address and #*-cells where applicable.
>>>>
>>>> .../devicetree/bindings/display/mipi-dsi-bus.txt | 80
>>>> ++++++++++++++++++++++ 1 file changed, 80 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
>>>> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt index
>>>> 94fb72cb916f..7a3abbedb3fa 100644
>>>> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
>>>> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
>>>>
>>>> @@ -29,6 +29,13 @@ Required properties:
>>>> - #size-cells: Should be 0. There are cases where it makes sense to use
>>>> a
>>>>
>>>> different value here. See below.
>>>>
>>>> +Optional properties:
>>>> +- clock-master: boolean. Should be enabled if the host is being used in
>>>> + conjunction with another DSI host to drive the same peripheral.
>>>> Hardware
>>>> + supporting such a configuration generally requires the data on both
>>>> the busses + to be driven by the same clock. Only the DSI host instance
>>>> controlling this + clock should contain this property.
>>>> +
>>>>
>>>> DSI peripheral
>>>> ==============
>>>>
>>>> @@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI
>>>> bus (mostly for the data>>
>>>> path). Connections between such peripherals and a DSI host can be
>>>> represented using the graph bindings [1], [2].
>>>>
>>>> +Peripherals that support dual channel DSI
>>>> +-----------------------------------------
>>>> +
>>>> +Peripherals with higher bandwidth requirements can be connected to 2 DSI
>>>> +busses. Each DSI bus/channel drives some portion of the pixel data
>>>> (generally +left/right half of each line of the display, or even/odd
>>>> lines of the display). +The graph bindings should be used to represent
>>>> the multiple DSI busses that are +connected to this peripheral. Each DSI
>>>> host's output endpoint can be linked to +an input endpoint of the DSI
>>>> peripheral.
>>>> +
>>>>
>>>> [1] Documentation/devicetree/bindings/graph.txt
>>>> [2] Documentation/devicetree/bindings/media/video-interfaces.txt
>>>>
>>>> @@ -71,6 +88,8 @@ Examples
>>>>
>>>> with different virtual channel configurations.
>>>>
>>>> - (4) is an example of a peripheral on a I2C control bus connected with
>>>> to
>>>>
>>>> a DSI host using of-graph bindings.
>>>>
>>>> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI
>>>> peripheral,
>>>> + which uses I2C as its primary control bus.
>>>>
>>>> 1)
>>>>
>>>> dsi-host {
>>>>
>>>> @@ -153,3 +172,64 @@ Examples
>>>>
>>>> };
>>>>
>>>> };
>>>>
>>>> };
>>>>
>>>> +
>>>> +5)
>>>> + i2c-host {
>>>> + dsi-bridge@35 {
>>>> + compatible = "...";
>>>> + reg = <0x35>;
>>>> +
>>>> + ports {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + port@0 {
>>>> + reg = <0>;
>>>> + dsi0_in: endpoint {
>>>> + remote-endpoint = <&dsi0_out>;
>>>> + };
>>>> + };
>>>> +
>>>> + port@1 {
>>>> + reg = <1>;
>>>> + dsi1_in: endpoint {
>>>> + remote-endpoint = <&dsi1_out>;
>>>> + };
>>>> + };
>>>> + };
>>>> + };
>>>> + };
>>>> +
>>>> + dsi0-host {
>>>> + ...
>>>> +
>>>> + /*
>>>> + * this DSI instance drives the clock for both the host
>>>> + * controllers
>>>> + */
>>>> + clock-master;
>>>> +
>>>> + ports {
>>>> + ...
>>>> +
>>>> + port {
>>>> + dsi0_out: endpoint {
>>>> + remote-endpoint = <&dsi0_in>;
>>>> + };
>>>> + };
>>>> + };
>>>> + };
>>>> +
>>>> + dsi1-host {
>>>> + ...
>>>> +
>>>> + ports {
>>>> + ...
>>>> +
>>>> + port {
>>>> + dsi1_out: endpoint {
>>>> + remote-endpoint = <&dsi1_in>;
>>>> + };
>>>> + };
>>>> + };
>>>> + };
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 01/20] coresight: Fix memory leak in coresight_register
From: Suzuki K Poulose @ 2018-06-06 10:16 UTC (permalink / raw)
To: Arvind Yadav, linux-arm-kernel
Cc: mathieu.poirier, robh, frowand.list, mark.rutland, sudeep.holla,
arm, linux-kernel, matt.sealey, john.horley, charles.garcia-tobin,
coresight, devicetree, mike.leach
In-Reply-To: <b0100f00-c706-3a41-ca55-3c1329c53aa3@gmail.com>
On 06/06/2018 07:44 AM, Arvind Yadav wrote:
> Hi Suzuki,
>
>
> On Wednesday 06 June 2018 03:13 AM, Suzuki K Poulose wrote:
>> commit 6403587a930c ("coresight: use put_device() instead of kfree()")
>> introduced a memory leak where, if we fail to register the device
>> for coresight_device, we don't free the "coresight_device" object,
>> which was allocated via kzalloc(). Fix this by jumping to the
>> appropriate error path.
> put_device() will decrement the last reference and then
> free the memory by calling dev->release. Internally
> put_device() -> kobject_put() -> kobject_cleanup() which is
> responsible to call 'dev -> release' and also free other kobject
> resources. If you will see the coresight_device_release. There
> we are releasing all allocated memory. Still if you call kfree() again
> then it'll be redundancy.
You're right. I think it would be good to have a comment explaining this
to prevent this fix popping up in the future :-). I will add it
Thanks
Suzuki
^ permalink raw reply
* Re: [PATCH v3 0/6] Add MCAN Support for dra76x
From: Faiz Abbas @ 2018-06-06 10:13 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk,
robh+dt, bcousson, paul, t-kristo, mark.rutland
In-Reply-To: <20180606100937.GF5738@atomide.com>
Hi,
On Wednesday 06 June 2018 03:39 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:09]:
>> The following patches add dts and sysconfig support
>> for MCAN on TI's dra76 SOCs
>>
>> The patches depend on the following series:
>> https://patchwork.kernel.org/patch/10221105/
>>
>> Changes in v3:
>> 1. Added reset functionality to the ti-sysc
>> driver. This enables me to drop the hwmod
>> data patch as everything is being done in dt.
>>
>> 2. Dropped ti,hwmods from the dts nodes
>
> Cool good to hear that works :)
>
>> 4. Removed the status="disabled" in dtsi
>> followed by status="okay" in dts.
>
> Hmm okay is the default and is not needed. I did not notice
> okay in this set based on a quick glance so maybe you already
> dropped it?
I guess that wasn't clear. I meant to say I have dropped both
status=disabled and status=okay because okay is default.
Thanks,
Faiz
^ permalink raw reply
* Re: [PATCH v3 0/6] Add MCAN Support for dra76x
From: Tony Lindgren @ 2018-06-06 10:09 UTC (permalink / raw)
To: Faiz Abbas
Cc: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk,
robh+dt, bcousson, paul, t-kristo, mark.rutland
In-Reply-To: <20180606060826.14671-1-faiz_abbas@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180606 06:09]:
> The following patches add dts and sysconfig support
> for MCAN on TI's dra76 SOCs
>
> The patches depend on the following series:
> https://patchwork.kernel.org/patch/10221105/
>
> Changes in v3:
> 1. Added reset functionality to the ti-sysc
> driver. This enables me to drop the hwmod
> data patch as everything is being done in dt.
>
> 2. Dropped ti,hwmods from the dts nodes
Cool good to hear that works :)
> 4. Removed the status="disabled" in dtsi
> followed by status="okay" in dts.
Hmm okay is the default and is not needed. I did not notice
okay in this set based on a quick glance so maybe you already
dropped it?
Regards,
Tony
^ permalink raw reply
* [PATCH v2] arm64: dts: renesas: r8a77990: Enable USB2.0 Host for Ebisu board
From: Yoshihiro Shimoda @ 2018-06-06 9:52 UTC (permalink / raw)
To: horms, magnus.damm, robh+dt, mark.rutland
Cc: devicetree, linux-renesas-soc, Yoshihiro Shimoda
This patch adds USB2.0 PHY and Host(EHCI/OHCI) nodes and
enables them for R-Car E3 Ebisu board.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
This patch set is based on renesas-drivers.git /
renesas-drivers-2018-06-05-v4.17 tag.
Changes from v1:
- Squash 4 patches into a single patch.
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 20 ++++++++++++++
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 37 ++++++++++++++++++++++++++
2 files changed, 57 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 7a09d05..76fa244 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -47,10 +47,18 @@
};
};
+&ehci0 {
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <48000000>;
};
+&ohci0 {
+ status = "okay";
+};
+
&pfc {
avb_pins: avb {
mux {
@@ -58,8 +66,20 @@
function = "avb";
};
};
+
+ usb0_pins: usb {
+ groups = "usb0_b";
+ function = "usb0";
+ };
};
&scif2 {
status = "okay";
};
+
+&usb2_phy0 {
+ pinctrl-0 = <&usb0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index be4f519..0b2bec3 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -248,6 +248,43 @@
status = "disabled";
};
+ ohci0: usb@ee080000 {
+ compatible = "generic-ohci";
+ reg = <0 0xee080000 0 0x100>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 703>;
+ phys = <&usb2_phy0>;
+ phy-names = "usb";
+ power-domains = <&sysc 32>;
+ resets = <&cpg 703>;
+ status = "disabled";
+ };
+
+ ehci0: usb@ee080100 {
+ compatible = "generic-ehci";
+ reg = <0 0xee080100 0 0x100>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 703>;
+ phys = <&usb2_phy0>;
+ phy-names = "usb";
+ companion = <&ohci0>;
+ power-domains = <&sysc 32>;
+ resets = <&cpg 703>;
+ status = "disabled";
+ };
+
+ usb2_phy0: usb-phy@ee080200 {
+ compatible = "renesas,usb2-phy-r8a77990",
+ "renesas,rcar-gen3-usb2-phy";
+ reg = <0 0xee080200 0 0x700>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 703>;
+ power-domains = <&sysc 32>;
+ resets = <&cpg 703>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@f1010000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver
From: Sricharan R @ 2018-06-06 9:51 UTC (permalink / raw)
To: Vinod
Cc: bjorn.andersson, ohad, robh+dt, mark.rutland, andy.gross,
david.brown, linux-remoteproc, devicetree, linux-kernel,
linux-arm-msm, linux-soc, sibis
In-Reply-To: <20180606064909.GC16230@vkoul-mobl>
Hi Vinod,
On 6/6/2018 12:19 PM, Vinod wrote:
> Hi Sricharan,
>
> On 06-06-18, 12:09, Sricharan R wrote:
>
>>>>>> +config QCOM_Q6V5_WCSS
>>>>>> + tristate "Qualcomm Hexagon based WCSS Peripheral Image Loader"
>>>>>> + depends on OF && ARCH_QCOM
>>>>>> + depends on QCOM_SMEM
>>>>>> + depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)
>>>>>> + depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
>>>>>
>>>>> Is there a reason why it depends on RPMSG_QCOM_GLINK_SMEM=n? What would
>>>>> happen if distro wants both this and RPMSG_QCOM_GLINK_SMEM
>>>>>
>>>> RPMSG_QCOM_GLINK_SMEM=n should be for the COMPILE_TEST. Probably that
>>>
>>> why would that be a limitation? I am more worried about
>>> RPMSG_QCOM_GLINK_SMEM=n being the condition here. In new drivers we
>>> should not typically have dependency on some symbol being not there
>>
>> Without that, if RPMSG_QCOM_GLINK_SMEM=m is compiled as a module, then
>> it would break the build.
>
> Okay I do not know the details, but that doesn't sound correct to me.
> Breaking build sounds a bit extreme to me. Can you give details on this
> part..
>
Having, just, depends on RPMSG_QCOM_GLINK_SMEM || COMPILE_TEST,
is going to break when RPMSG_QCOM_GLINK_SMEM=m and COMPILE_TEST=y.
Hence the COMPILE_TEST && RPMSG_QCOM_GLINK_SMEM=n.
Having said that, COMPILE_TEST is getting tested for RPMSG_QCOM_SMD=n in
the previous line. So that's the reason for not having it in below line for
RPMSG_QCOM_GLINK_SMEM.
>>>> means that it should be corrected here and for ADSP, Q6V5_PIL as well.
>>>> Bjorn, is that correct ?, should it be, below ?
>>>>
>>>> depends on (RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)) || (RPMSG_QCOM_GLINK_SMEM || (COMPILE_TEST && RPMSG_QCOM_GLINK_SMEM=n))
>>>
>>> that doesnt really sound good :(
>>
>> Hmm, but i was thinking it should functionally depend on either SMD or GLINK and not both.
>
> If you are depedent upon a symbol provided by a module you should say
> depends on. If a machine is not supposed to have both SMD or GLINK then
> the driver will not get probed.
>
This is where, i was thinking, it should be functional if either of SMD or GLINK
is there, but should not require both.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls
From: Takashi Iwai @ 2018-06-06 9:47 UTC (permalink / raw)
To: Arnaud Pouliquen
Cc: mark.rutland@arm.com, robh@kernel.org,
alsa-devel@alsa-project.org, Olivier MOYSAN, Alexandre TORGUE,
devicetree@vger.kernel.org, lgirdwood@gmail.com, jsarha@ti.com,
linux-kernel@vger.kernel.org, Mark Brown, kernel@stlinux.com,
linux-arm-kernel@lists.infradead.org, mcoquelin.stm32@gmail.com,
rmk@arm.linux.org.uk, Benjamin GAIGNARD
In-Reply-To: <c4b2d22f-320d-a415-6328-b33f9c03aafe@st.com>
On Wed, 06 Jun 2018 11:31:45 +0200,
Arnaud Pouliquen wrote:
>
>
>
> On 06/05/2018 08:29 PM, Takashi Iwai wrote:
> > On Tue, 05 Jun 2018 17:50:57 +0200,
> > Arnaud Pouliquen wrote:
> >>
> >> Hi Takashi,
> >>
> >> On 04/17/2018 01:17 PM, Mark Brown wrote:
> >> > On Tue, Apr 17, 2018 at 08:29:17AM +0000, Olivier MOYSAN wrote:
> >> >
> >> >> I guess the blocking patch in this patchset is the patch "add IEC958
> >> >> channel status control helper". This patch has been reviewed several
> >> >> times, but did not get a ack so far.
> >> >> If you think these helpers will not be merged, I will reintegrate the
> >> >> corresponding code in stm driver.
> >> >> Please let me know, if I need to prepare a v2 without helpers, or if we
> >> >> can go further in the review of iec helpers patch ?
> >> >
> >> > I don't mind either way but you're right here, I'm waiting for Takashi
> >> > to review the first patch. I'd probably be OK with it just integrated
> >> > into the driver if we have to go that way though.
> >>
> >> Gentlemen reminder for this patch set. We would appreciate to have your
> >> feedback on iec helper.
> >> From our point of view it could be useful to have a generic management
> >> of the iec controls based on helpers instead of redefining them in DAIs.
> >> Having the same behavior for these controls could be useful to ensure
> >> coherence of the control management used by application (for instance
> >> Gstreamer uses it to determine iec raw mode capability for iec61937 streams)
> >
> > Oh sorry for the late reply, I've totally overlooked the thread.
> >
> > And, another sorry: the patchset doesn't look convincing enough to
> > me.
> >
> > First off, the provided API definition appears somewhat
> > unconventional, the mixture of the ops, the static data and the
> > dynamic data.
> Sorry i can't figure out your point. I suppose that you speak about the
> snd_pcm_iec958_params.
> what would be a more conventional API?
Imagine you'd want to put a const to the data passed to the API for
hardening. The current struct is a mixture of static and dynamic
data.
> > Moreover, this is only for your driver, ATM.
> It is also compatible with the sound/sti driver, even if we does not
> propose patch yet. We also plan to propose an implementation, for the
> HDMI_codec that would need to export a control to allow none-audio mode.
>
> >If it were an API that
> > does clean up the already existing usages, I'd happily apply it. There
> > are lots of drivers creating and controlling the IEC958 ctls even
> > now.
> >
> > Also, the patchset requires more fine-tuning, in anyways. The changes
> > in create_iec958_consumre() are basically irrelevant, should be split
> > off as an individual fix. it is linked to the control, as not possible in existing implementation
> (rate and width are get from hwparam or runtime). But no problem we can
> split it in a separate patch.
>
> Also, the new function doesn't create the
> > "XXX Mask" controls. And the byte comparison should be replaced with
> > memcmp(), etc, etc.
> Yes mask are missing, can be added. For the rest could you comment
> directly in code? i suppose that you want to replace the for loops by
> memcmp, memcpy...
Right.
> > So, please proceed rather with the open codes for now. If you can
> > provide a patch that cleans up the *multiple* driver codes, again,
> > I'll happily take it. But it can be done anytime later, too.
> Not simple to clean up the other drivers as this control is a PCM
> control, that is mainly implemented as a mixer or card control.
> This means that it should be registered on the pcm_new in CPU DAI or in
> the DAI codec, to be able to bind it to the PCM device.
> Inpact is not straigthforward as this could generate regression on driver.
Yes, and that's my point. The application of API is relatively
limited -- although the API itself has nothing to do with ASoC at
all.
> For now We can add the clean up on the sti driver based on this helper,
> and we are working on the HDMI_codec, we could also use this helper to
> export the control....
>
> So if you estimate that it is interesting to purchase on this helper we
> can try to come back with a patch set that implements the helper for
> the 3 drivers.
Right. Basically there are two cases we add a new API:
1. It's absolutely new and nothing else can do it
2. API simplifies the whole tree, not only one you're trying to add.
And in this case, let's prove 2 at first, that the API *is* actually
useful in multiple situations we already have. Then I'll happily ack
for that. More drivers cleanup, better. At best, think of more
range above ASoC, as you're proposing ALSA core API, not the ASoC
one.
> The other option, is that we drop the helpers, and implement the control
> directly in our drivers.
This is of course another, maybe easier option.
> Please just tell us if we should continue to propose the helpers or not.
I have no preference over two ways, but am only interested in the
resulting patches :)
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Clément Péron @ 2018-06-06 9:34 UTC (permalink / raw)
To: devicetree
Cc: Rob Herring, Mark Rutland, Russell King, Ray Jui, Scott Branden,
Jon Mason, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel, Clément Peron
From: Clément Peron <clement.peron@devialet.com>
There is a HWRNG in Broadcom Cygnus SoC, so enable it.
Signed-off-by: Clément Peron <clement.peron@devialet.com>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 1cee40ac4613..b7178e84d56d 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -452,6 +452,11 @@
status = "disabled";
};
+ hwrng: hwrng@18032000 {
+ compatible = "brcm,iproc-rng200";
+ reg = <0x18032000 0x28>;
+ };
+
sdhci0: sdhci@18041000 {
compatible = "brcm,sdhci-iproc-cygnus";
reg = <0x18041000 0x100>;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls
From: Arnaud Pouliquen @ 2018-06-06 9:31 UTC (permalink / raw)
To: Takashi Iwai
Cc: mark.rutland@arm.com, robh@kernel.org,
alsa-devel@alsa-project.org, Olivier MOYSAN, Alexandre TORGUE,
devicetree@vger.kernel.org, lgirdwood@gmail.com, jsarha@ti.com,
linux-kernel@vger.kernel.org, Mark Brown, kernel@stlinux.com,
linux-arm-kernel@lists.infradead.org, mcoquelin.stm32@gmail.com,
rmk@arm.linux.org.uk, Benjamin GAIGNARD
In-Reply-To: <s5hpo15xf1q.wl-tiwai@suse.de>
On 06/05/2018 08:29 PM, Takashi Iwai wrote:
> On Tue, 05 Jun 2018 17:50:57 +0200,
> Arnaud Pouliquen wrote:
>>
>> Hi Takashi,
>>
>> On 04/17/2018 01:17 PM, Mark Brown wrote:
>> > On Tue, Apr 17, 2018 at 08:29:17AM +0000, Olivier MOYSAN wrote:
>> >
>> >> I guess the blocking patch in this patchset is the patch "add IEC958
>> >> channel status control helper". This patch has been reviewed several
>> >> times, but did not get a ack so far.
>> >> If you think these helpers will not be merged, I will reintegrate the
>> >> corresponding code in stm driver.
>> >> Please let me know, if I need to prepare a v2 without helpers, or if we
>> >> can go further in the review of iec helpers patch ?
>> >
>> > I don't mind either way but you're right here, I'm waiting for Takashi
>> > to review the first patch. I'd probably be OK with it just integrated
>> > into the driver if we have to go that way though.
>>
>> Gentlemen reminder for this patch set. We would appreciate to have your
>> feedback on iec helper.
>> From our point of view it could be useful to have a generic management
>> of the iec controls based on helpers instead of redefining them in DAIs.
>> Having the same behavior for these controls could be useful to ensure
>> coherence of the control management used by application (for instance
>> Gstreamer uses it to determine iec raw mode capability for iec61937 streams)
>
> Oh sorry for the late reply, I've totally overlooked the thread.
>
> And, another sorry: the patchset doesn't look convincing enough to
> me.
>
> First off, the provided API definition appears somewhat
> unconventional, the mixture of the ops, the static data and the
> dynamic data.
Sorry i can't figure out your point. I suppose that you speak about the
snd_pcm_iec958_params.
what would be a more conventional API?
>
> Moreover, this is only for your driver, ATM.
It is also compatible with the sound/sti driver, even if we does not
propose patch yet. We also plan to propose an implementation, for the
HDMI_codec that would need to export a control to allow none-audio mode.
>If it were an API that
> does clean up the already existing usages, I'd happily apply it. There
> are lots of drivers creating and controlling the IEC958 ctls even
> now.
>
> Also, the patchset requires more fine-tuning, in anyways. The changes
> in create_iec958_consumre() are basically irrelevant, should be split
> off as an individual fix. it is linked to the control, as not possible in existing implementation
(rate and width are get from hwparam or runtime). But no problem we can
split it in a separate patch.
Also, the new function doesn't create the
> "XXX Mask" controls. And the byte comparison should be replaced with
> memcmp(), etc, etc.
Yes mask are missing, can be added. For the rest could you comment
directly in code? i suppose that you want to replace the for loops by
memcmp, memcpy...
>
> So, please proceed rather with the open codes for now. If you can
> provide a patch that cleans up the *multiple* driver codes, again,
> I'll happily take it. But it can be done anytime later, too.
Not simple to clean up the other drivers as this control is a PCM
control, that is mainly implemented as a mixer or card control.
This means that it should be registered on the pcm_new in CPU DAI or in
the DAI codec, to be able to bind it to the PCM device.
Inpact is not straigthforward as this could generate regression on driver.
For now We can add the clean up on the sti driver based on this helper,
and we are working on the HDMI_codec, we could also use this helper to
export the control....
So if you estimate that it is interesting to purchase on this helper we
can try to come back with a patch set that implements the helper for
the 3 drivers.
The other option, is that we drop the helpers, and implement the control
directly in our drivers.
Please just tell us if we should continue to propose the helpers or not.
Thanks,
Arnaud
>
>
> thanks,
>
> Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* RE: [PATCH 0/4] arm64: dts: renesas: r8a77990 and ebisu: Enable USB2.0 host
From: Yoshihiro Shimoda @ 2018-06-06 9:31 UTC (permalink / raw)
To: Simon Horman
Cc: magnus.damm@gmail.com, robh+dt@kernel.org, mark.rutland@arm.com,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <20180606091606.ac5lqgknevfrcq57@verge.net.au>
Hi Simon-san,
> From: Simon Horman, Sent: Wednesday, June 6, 2018 6:16 PM
>
> On Wed, Jun 06, 2018 at 03:56:07PM +0900, Yoshihiro Shimoda wrote:
> > This patch set is based on renesas-drivers.git /
> > renesas-drivers-2018-06-05-v4.17 tag.
> >
> > About dt-bindings of "renesas,usb2-phy-r8a77990", I submitted a patch:
> > https://patchwork.kernel.org/patch/10449723/
> >
> > But, the phy-rcar-gen3-usb2 driver works on the board without the bindings
> > because "renesas,rcar-gen3-usb2-phy" can bind the driver.
> >
> > Also, for now, I don't try to add/enable USB2.0 peripheral on the board
> > because the phy driver needs some modifications.
> >
> > Yoshihiro Shimoda (4):
> > arm64: dts: renesas: r8a77990: add usb2_phy device node
> > arm64: dts: renesas: r8a77990: add USB2.0 host device nodes
> > arm64: dts: renesas: r8a77990: ebisu: enable usb2_phy0
> > arm64: dts: renesas: r8a77990: ebisu: enable USB2.0 host
> >
> > arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 20 ++++++++++++++
> > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 37 ++++++++++++++++++++++++++
> > 2 files changed, 57 insertions(+)
>
> Hi Shomoda-san,
>
> the contents of this series looks good to me. However, given Olof
> Johansson's recent comments in ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
> Updates for v4.18") please consider squashing this series into a single
> patch and reposting.
Sure. I'll resubmit v2 patch as a single patch.
Best regards,
Yoshihiro Shimoda
> Thanks!
^ permalink raw reply
* Re: [PATCH 0/4] arm64: dts: renesas: r8a77990 and ebisu: Enable USB2.0 host
From: Simon Horman @ 2018-06-06 9:16 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: magnus.damm, robh+dt, mark.rutland, devicetree, linux-renesas-soc
In-Reply-To: <1528268171-19276-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
On Wed, Jun 06, 2018 at 03:56:07PM +0900, Yoshihiro Shimoda wrote:
> This patch set is based on renesas-drivers.git /
> renesas-drivers-2018-06-05-v4.17 tag.
>
> About dt-bindings of "renesas,usb2-phy-r8a77990", I submitted a patch:
> https://patchwork.kernel.org/patch/10449723/
>
> But, the phy-rcar-gen3-usb2 driver works on the board without the bindings
> because "renesas,rcar-gen3-usb2-phy" can bind the driver.
>
> Also, for now, I don't try to add/enable USB2.0 peripheral on the board
> because the phy driver needs some modifications.
>
> Yoshihiro Shimoda (4):
> arm64: dts: renesas: r8a77990: add usb2_phy device node
> arm64: dts: renesas: r8a77990: add USB2.0 host device nodes
> arm64: dts: renesas: r8a77990: ebisu: enable usb2_phy0
> arm64: dts: renesas: r8a77990: ebisu: enable USB2.0 host
>
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 20 ++++++++++++++
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 37 ++++++++++++++++++++++++++
> 2 files changed, 57 insertions(+)
Hi Shomoda-san,
the contents of this series looks good to me. However, given Olof
Johansson's recent comments in ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
Updates for v4.18") please consider squashing this series into a single
patch and reposting.
Thanks!
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: renesas: r8a77980: add GPIO support
From: Geert Uytterhoeven @ 2018-06-06 9:07 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Magnus Damm, Catalin Marinas, Will Deacon, Rob Herring,
Linux-Renesas, Simon Horman, Linux ARM
In-Reply-To: <3c195d53-be0f-ad15-92e6-8ba43b14f076@cogentembedded.com>
On Fri, Jun 1, 2018 at 10:44 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Describe all 6 GPIO controllers in the R8A77980 device tree.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
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
* Re: [PATCH] arm64: dts: renesas: r8a77990: ebisu: Enable watchdog timer
From: Simon Horman @ 2018-06-06 9:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-renesas-soc, devicetree, Takeshi Kihara, Magnus Damm,
linux-arm-kernel
In-Reply-To: <1528219234-29348-1-git-send-email-geert+renesas@glider.be>
On Tue, Jun 05, 2018 at 07:20:34PM +0200, Geert Uytterhoeven wrote:
> From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>
> Add a device node for the Watchdog Timer (WDT) controller on the
> R8A77990 SoC, and enable the watchdog on the Ebisu board.
>
> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> [geert: Squashed 2 commits]
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Hi,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH] gpio-rcar: document R8A77980 bindings
From: Geert Uytterhoeven @ 2018-06-06 9:02 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Linus Walleij, Rob Herring, open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Mark Rutland
In-Reply-To: <529bc49b-e258-20ae-fe97-6d0abcec39ec@cogentembedded.com>
On Fri, Jun 1, 2018 at 10:13 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Renesas R-Car V3H (R8A77980) SoC also has the R-Car gen3 compatible GPIO
> controllers, so document the SoC specific bindings.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
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
* Re: [PATCH v4 1/3] dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
From: Simon Horman @ 2018-06-06 8:47 UTC (permalink / raw)
To: Michel Pollet
Cc: linux-renesas-soc, phil.edworthy, Michel Pollet, Rob Herring,
Mark Rutland, Magnus Damm, Russell King, Carlo Caione,
Maxime Ripard, Douglas Anderson, Kevin Hilman, Frank Rowand,
Florian Fainelli, Rajendra Nayak, Chen-Yu Tsai, Stefan Wahren,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1528198148-23308-2-git-send-email-michel.pollet@bp.renesas.com>
On Tue, Jun 05, 2018 at 12:28:46PM +0100, Michel Pollet wrote:
> Add a special enable method for second CA7 of the R9A06G032
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v8 4/5] ARM: dts: Renesas RZN1D-DB Board base file
From: Simon Horman @ 2018-06-06 8:45 UTC (permalink / raw)
To: Michel Pollet
Cc: linux-renesas-soc, phil.edworthy, Michel Pollet,
Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Geert Uytterhoeven, linux-clk, devicetree, linux-kernel
In-Reply-To: <1528187462-47093-5-git-send-email-michel.pollet@bp.renesas.com>
On Tue, Jun 05, 2018 at 09:30:00AM +0100, Michel Pollet wrote:
> This adds a base device tree file for the RZN1-DB board, with only the
> basic support allowing the system to boot to a prompt. Only one UART is
> used, with only a single CPU running.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Hi,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v8 3/5] ARM: dts: Renesas R9A06G032 base device tree file
From: Simon Horman @ 2018-06-06 8:44 UTC (permalink / raw)
To: Michel Pollet
Cc: linux-renesas-soc, phil.edworthy, Michel Pollet,
Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Geert Uytterhoeven, linux-clk, devicetree, linux-kernel
In-Reply-To: <1528187462-47093-4-git-send-email-michel.pollet@bp.renesas.com>
On Tue, Jun 05, 2018 at 09:29:59AM +0100, Michel Pollet wrote:
> This adds the Renesas R9A06G032 bare bone support.
>
> This currently only handles the SYSCTRL block node,
> generic parts (gic, architected timer) and a UART.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Hi,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH] iommu/ipmmu-vmsa: Document R-Car V3H and E3 IPMMU DT bindings
From: Geert Uytterhoeven @ 2018-06-06 8:38 UTC (permalink / raw)
To: Magnus Damm
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Laurent Pinchart, Geert Uytterhoeven, Linux-Renesas, Linux IOMMU,
Rob Herring, Simon Horman
In-Reply-To: <152691369384.29456.13581918319106400529.sendpatchset@little-apple>
On Mon, May 21, 2018 at 4:41 PM, Magnus Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
>
> Update the IPMMU DT binding documentation to include the compat strings
> for the IPMMU devices included in the R-Car V3H and E3 SoCs.
>
> Signed-off-by: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
* Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
From: Heiko Stübner @ 2018-06-06 8:30 UTC (permalink / raw)
To: Archit Taneja
Cc: devicetree, boris.brezillon, linux-arm-msm, tomi.valkeinen,
briannorris, philippe.cornu, dri-devel, nickey.yang, robh+dt,
thierry.reding, laurent.pinchart, maxime.ripard
In-Reply-To: <4df7aa3e-e693-a94a-e9bb-7323e6d62cd2@codeaurora.org>
Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:
> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:
> > Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:
> >> Add binding info for peripherals that support dual-channel DSI. Add
> >> corresponding optional bindings for DSI host controllers that may
> >> be configured in this mode. Add an example of an I2C controlled
> >> device operating in dual-channel DSI mode.
> >>
> >> Signed-off-by: Archit Taneja <architt@codeaurora.org>
> >
> > Looks like a great solution for that problem, so
> > Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> >
> > As I'm looking into that for my rk3399-scarlet device right now and
> > couldn't find this patchset in the kernel yet, is it planned to
> > merge or refresh these binding changes or were problems encountered.
> >
> > At least an Ack/Review from Rob seems to be missing.
>
> I forgot about these patches. Rob had reviewed the first one in
> the set the second one still needed an Ack. I'll post a v3
> that adds the Reviewed-bys and fixes a small typo.
very nice ... because it looks like yesterday I managed to make the Rockchip
dsi work in dual mode following this.
But one question came up, do you really want two input ports on the panel
side? I.e. hardware-wise, I guess the panel will have one 8-lane or so input
thatonly gets split up on the soc side onto 2 dsi controllers?
So right now I'm operating with a devicetree like
&mipi_dsi {
status = "okay";
clock-master;
ports {
mipi_out: port@1 {
reg = <1>;
mipi_out_panel: endpoint {
remote-endpoint = <&mipi_in_panel>;
};
};
};
mipi_panel: panel@0 {
compatible = "innolux,p097pfg";
reg = <0>;
backlight = <&backlight>;
enable-gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&display_rst_l>;
port {
#address-cells = <1>;
#size-cells = <0>;
mipi_in_panel: endpoint@0 {
reg = <0>;
remote-endpoint = <&mipi_out_panel>;
};
mipi1_in_panel: endpoint@1 {
reg = <1>;
remote-endpoint = <&mipi1_out_panel>;
};
};
};
};
&mipi_dsi1 {
status = "okay";
ports {
mipi1_out: port@1 {
reg = <1>;
mipi1_out_panel: endpoint {
remote-endpoint = <&mipi1_in_panel>;
};
};
};
};
I guess it is a matter of preference on what reflects the hardware
best, so maybe that's Robs call?
Heiko
> >> ---
> >> v2:
> >> - Specify that clock-master is a boolean property.
> >> - Drop/add unit-address and #*-cells where applicable.
> >>
> >> .../devicetree/bindings/display/mipi-dsi-bus.txt | 80
> >> ++++++++++++++++++++++ 1 file changed, 80 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> >> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt index
> >> 94fb72cb916f..7a3abbedb3fa 100644
> >> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> >> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> >>
> >> @@ -29,6 +29,13 @@ Required properties:
> >> - #size-cells: Should be 0. There are cases where it makes sense to use
> >> a
> >>
> >> different value here. See below.
> >>
> >> +Optional properties:
> >> +- clock-master: boolean. Should be enabled if the host is being used in
> >> + conjunction with another DSI host to drive the same peripheral.
> >> Hardware
> >> + supporting such a configuration generally requires the data on both
> >> the busses + to be driven by the same clock. Only the DSI host instance
> >> controlling this + clock should contain this property.
> >> +
> >>
> >> DSI peripheral
> >> ==============
> >>
> >> @@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI
> >> bus (mostly for the data>>
> >> path). Connections between such peripherals and a DSI host can be
> >> represented using the graph bindings [1], [2].
> >>
> >> +Peripherals that support dual channel DSI
> >> +-----------------------------------------
> >> +
> >> +Peripherals with higher bandwidth requirements can be connected to 2 DSI
> >> +busses. Each DSI bus/channel drives some portion of the pixel data
> >> (generally +left/right half of each line of the display, or even/odd
> >> lines of the display). +The graph bindings should be used to represent
> >> the multiple DSI busses that are +connected to this peripheral. Each DSI
> >> host's output endpoint can be linked to +an input endpoint of the DSI
> >> peripheral.
> >> +
> >>
> >> [1] Documentation/devicetree/bindings/graph.txt
> >> [2] Documentation/devicetree/bindings/media/video-interfaces.txt
> >>
> >> @@ -71,6 +88,8 @@ Examples
> >>
> >> with different virtual channel configurations.
> >>
> >> - (4) is an example of a peripheral on a I2C control bus connected with
> >> to
> >>
> >> a DSI host using of-graph bindings.
> >>
> >> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI
> >> peripheral,
> >> + which uses I2C as its primary control bus.
> >>
> >> 1)
> >>
> >> dsi-host {
> >>
> >> @@ -153,3 +172,64 @@ Examples
> >>
> >> };
> >>
> >> };
> >>
> >> };
> >>
> >> +
> >> +5)
> >> + i2c-host {
> >> + dsi-bridge@35 {
> >> + compatible = "...";
> >> + reg = <0x35>;
> >> +
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + port@0 {
> >> + reg = <0>;
> >> + dsi0_in: endpoint {
> >> + remote-endpoint = <&dsi0_out>;
> >> + };
> >> + };
> >> +
> >> + port@1 {
> >> + reg = <1>;
> >> + dsi1_in: endpoint {
> >> + remote-endpoint = <&dsi1_out>;
> >> + };
> >> + };
> >> + };
> >> + };
> >> + };
> >> +
> >> + dsi0-host {
> >> + ...
> >> +
> >> + /*
> >> + * this DSI instance drives the clock for both the host
> >> + * controllers
> >> + */
> >> + clock-master;
> >> +
> >> + ports {
> >> + ...
> >> +
> >> + port {
> >> + dsi0_out: endpoint {
> >> + remote-endpoint = <&dsi0_in>;
> >> + };
> >> + };
> >> + };
> >> + };
> >> +
> >> + dsi1-host {
> >> + ...
> >> +
> >> + ports {
> >> + ...
> >> +
> >> + port {
> >> + dsi1_out: endpoint {
> >> + remote-endpoint = <&dsi1_in>;
> >> + };
> >> + };
> >> + };
> >> + };
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm"
> > in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: renesas: v3hsk: specify GEther PHY IRQ
From: Geert Uytterhoeven @ 2018-06-06 8:18 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Magnus Damm, Catalin Marinas, Will Deacon, Rob Herring,
Linux-Renesas, Simon Horman, Linux ARM
In-Reply-To: <9e6c40eb-71d0-d35b-1cf7-9179e093ed10@cogentembedded.com>
On Fri, Jun 1, 2018 at 10:47 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Specify GEther PHY IRQ in the V3H Starter Kit board's device tree, now
> that we have the GPIO support (previously phylib had to resort to polling).
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
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
* Re: [PATCH v5 2/4] dt-bindings: timer: add i.MX EPIT timer binding
From: Clément Péron @ 2018-06-06 8:12 UTC (permalink / raw)
To: Rob Herring
Cc: Colin Didier, linux-arm-kernel, devicetree, linux-kernel,
Daniel Lezcano, Thomas Gleixner, Fabio Estevam,
Vladimir Zapolskiy, Sascha Hauer, NXP Linux Team,
Pengutronix Kernel Team, Clément Peron
In-Reply-To: <20180605152323.GA25218@rob-hp-laptop>
Hi Rob,
On Tue, 5 Jun 2018 at 17:23, Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Jun 04, 2018 at 12:00:33PM +0200, Clément Péron wrote:
> > From: Clément Peron <clement.peron@devialet.com>
> >
> > Add devicetree binding document for NXP's i.MX SoC specific
> > EPIT timer driver.
> >
> > Signed-off-by: Clément Peron <clement.peron@devialet.com>
> > ---
> > .../devicetree/bindings/timer/fsl,imxepit.txt | 21 +++++++++++++++++++
> > 1 file changed, 21 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxepit.txt
> >
> > diff --git a/Documentation/devicetree/bindings/timer/fsl,imxepit.txt b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
> > new file mode 100644
> > index 000000000000..de2e6ef68d24
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
> > @@ -0,0 +1,21 @@
> > +Binding for the i.MX Enhanced Periodic Interrupt Timer (EPIT)
> > +
> > +The Enhanced Periodic Interrupt Timer (EPIT) is a 32-bit set-and-forget timer
> > +that is capable of providing precise interrupts at regular intervals with
> > +minimal processor intervention.
> > +
> > +Required properties:
> > +- compatible: should be "fsl,<chip>-epit", "fsl,imx31-epit" where <chip> is
> > + imx25, imx6qdl, imx6sl, imx6sul or imx6sx.
> > +- reg: physical base address of the controller and length of memory mapped
> > + region.
> > +- interrupts: Should contain EPIT controller interrupt
> > +- clocks : The clock provided by the SoC to drive the timer.
> > +
> > +Example for i.MX6QDL:
> > + epit1: epit@20d0000 {
>
> I think I already mentioned this, but:
My bad, will update it
>
> timer@...
>
> > + compatible = "fsl,imx6qdl-epit", "fsl,imx31-epit";
> > + reg = <0x020d0000 0x4000>;
> > + interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6QDL_CLK_EPIT1>;
> > + };
> > --
> > 2.17.0
> >
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: renesas: initial V3HSK board device tree
From: Geert Uytterhoeven @ 2018-06-06 7:52 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Magnus Damm, Catalin Marinas, Will Deacon, Rob Herring,
Linux-Renesas, Simon Horman, Linux ARM
In-Reply-To: <50de037c-7560-c261-f96a-f86065674c9b@cogentembedded.com>
On Thu, May 10, 2018 at 8:12 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add the initial device tree for the V3H Starter Kit board.
> The board has 1 debug serial port (SCIF0); include support for it,
> so that the serial console can work.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
FTR:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- /dev/null
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> +&pfc {
> + scif0_pins: scif0 {
> + groups = "scif0_data";
> + function = "scif0";
> + };
JFYI, hscif0 can be routed to the same pins, if higher performance is needed.
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
* Re: [PATCH 2/2] arm64: dts: renesas: condor: add I2C0 support
From: Geert Uytterhoeven @ 2018-06-06 7:46 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Magnus Damm, Catalin Marinas, Will Deacon, Rob Herring,
Linux-Renesas, Simon Horman, linux-arm-kernel@lists.infradead.org
In-Reply-To: <61f6f4a4-e55c-06e0-cba1-7d90a556950a@cogentembedded.com>
Hi Sergei,
On Mon, May 28, 2018 at 10:14 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Define the Condor board dependent part of the I2C0 device node.
>
> The I2C0 bus is populated by 2 ON Semiconductor PCA9654 I/O expanders
> and Analog Devices ADV7511W HDMI transmitter (but we're only describing
> the former chips now).
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Suggestion for future improvement below.
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> @@ -80,6 +80,28 @@
> clock-frequency = <32768>;
> };
>
> +&i2c0 {
> + pinctrl-0 = <&i2c0_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> + clock-frequency = <400000>;
> +
> + io_expander0: gpio@20 {
> + compatible = "onnn,pca9654";
> + reg = <0x20>;
> + gpio-controller;
> + #gpio-cells = <2>;
The bindings don't mention this (the example does have it) the optional
interrupts prototype. As this is wired to INTC-EX IRQ4, you may want to
add that. Perhaps later, as r8a77980.dtsi doesn't have INTC-EX yet.
> + };
> +
> + io_expander1: gpio@21 {
> + compatible = "onnn,pca9654";
> + reg = <0x21>;
> + gpio-controller;
> + #gpio-cells = <2>;
Same for IRQ5.
> + };
> +};
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
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