* Re: [PATCH 1/2] ARM: dts: Add the support for display5 equipped with Mitsubishi (800x480) display
From: Lucas Stach @ 2017-11-17 15:07 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Shawn Guo, Mark Rutland, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Sascha Hauer,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171117160347.5c78be6e@jawa>
Am Freitag, den 17.11.2017, 16:03 +0100 schrieb Lukasz Majewski:
> Hi Lucas,
>
> > Am Freitag, den 17.11.2017, 15:13 +0100 schrieb Lukasz Majewski:
> > > Hi Shawn,
> > >
> > > > On Fri, Nov 17, 2017 at 11:24:03AM +0100, Lukasz Majewski wrote:
> > > > > This is the support for aa070mc01-ca1 Mitsubishi display.
> > > > >
> > > > > > > > > > Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
> > > > > ---
> > > > > arch/arm/boot/dts/Makefile | 1 +
> > > > > .../imx6q-display5-mitsubishi-aa070-800x480.dts | 51
> > > > > ++++++++++++++++++++++ 2 files changed, 52 insertions(+)
> > > > > create mode 100644
> > > > > arch/arm/boot/dts/imx6q-display5-mitsubishi-aa070-800x480.dts
> > > > >
> > > > > diff --git a/arch/arm/boot/dts/Makefile
> > > > > b/arch/arm/boot/dts/Makefile
> > > > > index d9d0c82e7d20..10b3ad078dea 100644
> > > > > --- a/arch/arm/boot/dts/Makefile
> > > > > +++ b/arch/arm/boot/dts/Makefile
> > > > > @@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > > > > > > > > > imx6q-cm-fx6.dtb \
> > > > > > > > > > imx6q-cubox-i.dtb \
> > > > > > > > > > imx6q-dfi-fs700-m60.dtb \
> > > > > > > > > > + imx6q-display5-mitsubishi-aa070-800x480.dtb \
> > > > > > > > > > imx6q-display5-tianma-tm070-1280x768.dtb \
> > > > > > > > > > imx6q-dmo-edmqmx6.dtb \
> > > > > imx6q-evi.dtb \
> > > >
> > > > <snip>
> > > >
> > > > > +#include "imx6q-display5.dtsi"
> > > > > +
> > > > > +&panel {
> > > > > > > > > > + compatible = "mitsubishi,aa070mc01-ca1";
> > > > > +};
> > > >
> > > > How many DTB files do you want to add for this display5 board?
> > >
> > > This is a single board, which can support panels which I've posted.
> > >
> > > Those dtbs I do pack to u-boot' FIT image and don't need to worry
> > > that
> > > some display is not working (after setting bootloader env variable).
> > >
> > > > It's
> > > > obvious no fun to maintain a bunch of DTB files for all the panels
> > > > this board can support.
> > >
> > > Please note that those files excessively use #include directive, and
> > > there is not so much code added (the longest part is license and
> > > comments).
> > >
> > > > Let's stop right here.
> > >
> > > If I may ask - how shall I proceed? What would be your suggestion to
> > > move on (dtb overlays) ?
> >
> > The solution we use for the ZII RDU1 and RDU2 boards is to have the
> > bootloader patch in the correct panel compatible strings.
>
> Do you mean adjusting the DTB accordingly in u-boot for each display -
> change panel/compatible to new display name ?
Exactly. Simply let the bootloader insert the correct panel compatible
string into the DTB.
Regards,
Lucas
--
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] ASoC: Correct DT binding examples IRQ usage for da7218/9
From: Adam Thomson @ 2017-11-17 15:09 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Takashi Iwai, Jaroslav Kysela,
Rob Herring, Mark Rutland
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Support Opensource
Currently in the DT bindings documents for DA7218 and DA7219, the examples for
bindings usage show ACTIVE_HIGH IRQ usage. For both devices this is incorrect
as the devices themselves only suport ACTIVE_LOW. This patch set rectifies the
inconsistency.
Adam Thomson (2):
ASoC: da7219: Correct IRQ level in DT binding example
ASoC: da7218: Correct IRQ level in DT binding example
Documentation/devicetree/bindings/sound/da7218.txt | 2 +-
Documentation/devicetree/bindings/sound/da7219.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
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
* [PATCH 1/2] ASoC: da7219: Correct IRQ level in DT binding example
From: Adam Thomson @ 2017-11-17 15:09 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Takashi Iwai, Jaroslav Kysela,
Rob Herring, Mark Rutland
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Support Opensource
In-Reply-To: <cover.1510930791.git.Adam.Thomson.Opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
Current DT binding documentation shows an example where the IRQ
for the device is chosen to be ACTIVE_HIGH. This is incorrect as
the device only supports ACTIVE_LOW, so this commit fixes that
discrepancy.
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
---
Documentation/devicetree/bindings/sound/da7219.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/da7219.txt b/Documentation/devicetree/bindings/sound/da7219.txt
index cf61681..5b54d2d 100644
--- a/Documentation/devicetree/bindings/sound/da7219.txt
+++ b/Documentation/devicetree/bindings/sound/da7219.txt
@@ -77,7 +77,7 @@ Example:
reg = <0x1a>;
interrupt-parent = <&gpio6>;
- interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
VDD-supply = <®_audio>;
VDDMIC-supply = <®_audio>;
--
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/2] ASoC: da7218: Correct IRQ level in DT binding example
From: Adam Thomson @ 2017-11-17 15:09 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Takashi Iwai, Jaroslav Kysela,
Rob Herring, Mark Rutland
Cc: devicetree, alsa-devel, linux-kernel, Support Opensource
In-Reply-To: <cover.1510930791.git.Adam.Thomson.Opensource@diasemi.com>
Current DT binding documentation shows an example where the IRQ
for the device is chosen to be ACTIVE_HIGH. This is incorrect as
the device only supports ACTIVE_LOW, so this commit fixes that
discrepancy.
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
---
Documentation/devicetree/bindings/sound/da7218.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/da7218.txt b/Documentation/devicetree/bindings/sound/da7218.txt
index 5ca5a70..3ab9dfe 100644
--- a/Documentation/devicetree/bindings/sound/da7218.txt
+++ b/Documentation/devicetree/bindings/sound/da7218.txt
@@ -73,7 +73,7 @@ Example:
compatible = "dlg,da7218";
reg = <0x1a>;
interrupt-parent = <&gpio6>;
- interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
wakeup-source;
VDD-supply = <®_audio>;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 3/5] checks: add string list check for *-names properties
From: Andre Przywara @ 2017-11-17 15:12 UTC (permalink / raw)
To: Rob Herring, devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171117144515.10870-4-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Hi,
On 17/11/17 14:45, Rob Herring wrote:
> Add a string list check for common properties ending in "-names" such as
> reg-names or interrupt-names.
>
> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> checks.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/checks.c b/checks.c
> index 4e23f29486bb..346b0256f9cb 100644
> --- a/checks.c
> +++ b/checks.c
> @@ -622,6 +622,21 @@ WARNING_IF_NOT_STRING(stdout_path_is_string, "stdout-path");
>
> WARNING_IF_NOT_STRING_LIST(compatible_is_string_list, "compatible");
>
> +static void check_names_is_string_list(struct check *c, struct dt_info *dti,
> + struct node *node)
> +{
> + struct property *prop;
> +
> + for_each_property(node, prop) {
> + if (!strstr(prop->name, "-names"))
But that would match "actually-names-dont-matter" as well, resulting in
a false positive? Should we check if the string appears at the *end* of
the property name?
Cheers,
Andre.
> + continue;
> +
> + c->data = prop->name;
> + check_is_string_list(c, dti, node);
> + }
> +}
> +WARNING(names_is_string_list, check_names_is_string_list, NULL);
> +
> static void fixup_addr_size_cells(struct check *c, struct dt_info *dti,
> struct node *node)
> {
> @@ -1273,7 +1288,7 @@ static struct check *check_table[] = {
> &device_type_is_string, &model_is_string, &status_is_string,
> &label_is_string, &bootargs_is_string, &stdout_path_is_string,
>
> - &compatible_is_string_list,
> + &compatible_is_string_list, &names_is_string_list,
>
> &property_name_chars_strict,
> &node_name_chars_strict,
>
--
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] ARM: dts: Add the support for display5 equipped with Mitsubishi (800x480) display
From: Lukasz Majewski @ 2017-11-17 15:27 UTC (permalink / raw)
To: Lucas Stach
Cc: Shawn Guo, Mark Rutland, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Sascha Hauer,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1510931238.8104.20.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3664 bytes --]
On Fri, 17 Nov 2017 16:07:18 +0100
Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> Am Freitag, den 17.11.2017, 16:03 +0100 schrieb Lukasz Majewski:
> > Hi Lucas,
> >
> > > Am Freitag, den 17.11.2017, 15:13 +0100 schrieb Lukasz Majewski:
> > > > Hi Shawn,
> > > >
> > > > > On Fri, Nov 17, 2017 at 11:24:03AM +0100, Lukasz Majewski
> > > > > wrote:
> > > > > > This is the support for aa070mc01-ca1 Mitsubishi display.
> > > > > >
> > > > > > > > > > > Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
> > > > > > ---
> > > > > > arch/arm/boot/dts/Makefile | 1 +
> > > > > > .../imx6q-display5-mitsubishi-aa070-800x480.dts | 51
> > > > > > ++++++++++++++++++++++ 2 files changed, 52 insertions(+)
> > > > > > create mode 100644
> > > > > > arch/arm/boot/dts/imx6q-display5-mitsubishi-aa070-800x480.dts
> > > > > >
> > > > > > diff --git a/arch/arm/boot/dts/Makefile
> > > > > > b/arch/arm/boot/dts/Makefile
> > > > > > index d9d0c82e7d20..10b3ad078dea 100644
> > > > > > --- a/arch/arm/boot/dts/Makefile
> > > > > > +++ b/arch/arm/boot/dts/Makefile
> > > > > > @@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > > > > > > > > > > imx6q-cm-fx6.dtb \
> > > > > > > > > > > imx6q-cubox-i.dtb \
> > > > > > > > > > > imx6q-dfi-fs700-m60.dtb \
> > > > > > > > > > > +
> > > > > > > > > > > imx6q-display5-mitsubishi-aa070-800x480.dtb \
> > > > > > > > > > > imx6q-display5-tianma-tm070-1280x768.dtb \
> > > > > > > > > > > imx6q-dmo-edmqmx6.dtb \
> > > > > > imx6q-evi.dtb \
> > > > >
> > > > > <snip>
> > > > >
> > > > > > +#include "imx6q-display5.dtsi"
> > > > > > +
> > > > > > +&panel {
> > > > > > > > > > > + compatible =
> > > > > > > > > > > "mitsubishi,aa070mc01-ca1";
> > > > > > +};
> > > > >
> > > > > How many DTB files do you want to add for this display5
> > > > > board?
> > > >
> > > > This is a single board, which can support panels which I've
> > > > posted.
> > > >
> > > > Those dtbs I do pack to u-boot' FIT image and don't need to
> > > > worry that
> > > > some display is not working (after setting bootloader env
> > > > variable).
> > > > > It's
> > > > > obvious no fun to maintain a bunch of DTB files for all the
> > > > > panels this board can support.
> > > >
> > > > Please note that those files excessively use #include
> > > > directive, and there is not so much code added (the longest
> > > > part is license and comments).
> > > >
> > > > > Let's stop right here.
> > > >
> > > > If I may ask - how shall I proceed? What would be your
> > > > suggestion to move on (dtb overlays) ?
> > >
> > > The solution we use for the ZII RDU1 and RDU2 boards is to have
> > > the bootloader patch in the correct panel compatible strings.
> >
> > Do you mean adjusting the DTB accordingly in u-boot for each
> > display - change panel/compatible to new display name ?
>
> Exactly. Simply let the bootloader insert the correct panel compatible
> string into the DTB.
This would complicate a few other things :-),
but yes, this seems to be a technically better idea (in terms of final
binary size).
Thanks for help.
>
> Regards,
> Lucas
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd-ynQEQJNshbs@public.gmane.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: media: rcar_vin: Reverse SoC part number list
From: Simon Horman @ 2017-11-17 15:35 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Mauro Carvalho Chehab, Mark Rutland, Rob Herring,
Niklas Söderlund, linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Chris Paterson, Biju Das
In-Reply-To: <1510856571-30281-2-git-send-email-fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
On Thu, Nov 16, 2017 at 06:22:48PM +0000, Fabrizio Castro wrote:
> Change the sorting of the part numbers from descending to ascending to
> match with other documentation.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
> Reviewed-by: Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Reviewed-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]
From: Simon Horman @ 2017-11-17 15:35 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Mauro Carvalho Chehab, Mark Rutland, Rob Herring,
Niklas Söderlund, linux-media, linux-renesas-soc, devicetree,
Geert Uytterhoeven, Chris Paterson, Biju Das
In-Reply-To: <1510856571-30281-3-git-send-email-fabrizio.castro@bp.renesas.com>
On Thu, Nov 16, 2017 at 06:22:49PM +0000, Fabrizio Castro wrote:
> Add compatible strings for r8a7743 and r8a7745. No driver change
> is needed as "renesas,rcar-gen2-vin" will activate the right code.
> However, it is good practice to document compatible strings for the
> specific SoC as this allows SoC specific changes to the driver if
> needed, in addition to document SoC support and therefore allow
> checkpatch.pl to validate compatible string values.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 6/7] can: rcar_can: document r8a77995 (R-Car D3) compatibility strings
From: Simon Horman @ 2017-11-17 15:39 UTC (permalink / raw)
To: Ulrich Hecht
Cc: linux-renesas-soc, linux-can, devicetree, wsa, geert, magnus.damm,
chris.paterson2, ramesh.shanmugasundaram
In-Reply-To: <1510915289-15059-7-git-send-email-ulrich.hecht+renesas@gmail.com>
On Fri, Nov 17, 2017 at 11:41:28AM +0100, Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
> ---
> Documentation/devicetree/bindings/net/can/rcar_can.txt | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> index 06bb7cc..f7d0358 100644
> --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> @@ -11,6 +11,7 @@ Required properties:
> "renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC.
> "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
> "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
> + "renesas,can-r8a77995" if CAN controller is a part of R8A77995 SoC.
> "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
> "renesas,rcar-gen2-can" for a generic R-Car Gen2 compatible device.
> "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
> @@ -25,12 +26,12 @@ Required properties:
> - pinctrl-0: pin control group to be used for this controller.
> - pinctrl-names: must be "default".
>
> -Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
> -compatible:
> -In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
> -and can be used by both CAN and CAN FD controller at the same time. It needs to
> -be scaled to maximum frequency if any of these controllers use it. This is done
> -using the below properties:
> +Required properties for "renesas,can-r8a7795", "renesas,can-r8a7796" and
> +"renesas,can-r8a77995" compatible:
Not strictly related to this patch, but aren't these requirements also
applicable to "renesas,rcar-gen3-can"?
> +In R8A7795, R8A7796 and R8A77995 SoCs, "clkp2" can be CANFD clock. This is a
> +div6 clock and can be used by both CAN and CAN FD controller at the same
> +time. It needs to be scaled to maximum frequency if any of these
> +controllers use it. This is done using the below properties:
>
> - assigned-clocks: phandle of clkp2(CANFD) clock.
> - assigned-clock-rates: maximum frequency of this clock.
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: renesas: r8a77970: add GPIO support
From: Sergei Shtylyov @ 2017-11-17 16:11 UTC (permalink / raw)
To: Simon Horman, Geert Uytterhoeven
Cc: Rob Herring, Catalin Marinas, Will Deacon, Linux-Renesas,
devicetree@vger.kernel.org, Magnus Damm, Mark Rutland,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20171117141950.r6vzq6ndapopfidr@verge.net.au>
On 11/17/2017 05:19 PM, Simon Horman wrote:
>>> Describe all 6 GPIO controllers in the R8A77970 device tree.
>>>
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Thanks, applied.
It doesn't build w/o PFC support (and I thought I mde it clearin the cover
letter), so please either merge R8A77970 PFC patch or pull this one out!
MBR, Segei
^ permalink raw reply
* Re: [PATCH 0/7] R-Car D3 (r8a77995) CAN support
From: Wolfram Sang @ 2017-11-17 16:17 UTC (permalink / raw)
To: Ulrich Hecht
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-can-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, horms-/R6kz+dDXgpPR4JQBCEnsQ,
geert-Td1EMuHUCqxL1ZNQvxDV9g, magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ,
ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ
In-Reply-To: <1510915289-15059-1-git-send-email-ulrich.hecht+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 361 bytes --]
> Here's CAN and CAN FD support for the R-Car D3. This is a by-the-datasheet
> implementation, with the datasheet missing some bits, namely the pin map.
> I filled in the gaps with frog DNA^W^W^Wby deducing the information from
> pin numbers already in the PFC driver, so careful scrutiny is advised.
Did you have a chance to test one of the configurations?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver
From: Jingoo Han @ 2017-11-17 16:30 UTC (permalink / raw)
To: 'Pavel Machek', 'Dan Murphy'
Cc: 'Jacek Anaszewski', robh+dt, mark.rutland, rpurdie,
devicetree, linux-kernel, linux-leds, 'Lee Jones',
'Daniel Thompson'
In-Reply-To: <20171117112032.GA13855@amd>
On Friday, November 17, 2017 6:21 AM, Pavel Machek wrote:
>
> Hi!
>
> > >> If that does not yet exist... you want to create glue layer to be
> able
> > >> to use LED as a display backlight. (It may already exist, no idea).
> > >>
> > >> ...
> > >>
> > >> Actually or maybe a LED trigger. Just set LED's trigger to "this is
> > >> display backlight".
> > >
> > > There is one already:
> > >
> > > drivers/leds/trigger/ledtrig-backlight.c
> > >
> > > It adds a LED class device to the fb_notifier_list
> > > (drivers/video/fbdev/core/fb_notify.c)
> > >
> > > using fb_register_client(). The same is used in
> > > backlight_device_register (drivers/video/backlight/backlight.c).
> > >
> > > Actually why do you want to have this driver in the LED subsystem,
> > > if it is advertised as "designed for LCD display backlighting"?
> >
> > Well this is also advertised as a driver for Smart phone and tablet
> devices. And having worked with the Android lighting
> > solutions this is the preferred subsystem for Android. The Android OS
> manages the led brightness based on ALS values and in
> > turn calls into the driver to control the brightness register through
> the vendor provided lighting HAL.
> >
>
> Well.. if it can control other LEDs than just backlight, I believe it
> can stay in the LED subsystem.
I also agree with your opinion.
Best regards,
Jingoo Han
>
> > I am going to look at the backlight source to figure out how to get the
> same functionality using the backlight subsystem.
> > Otherwise I will plug in this driver to the backlight subsystem through
> the notifier.
> >
>
> The backlight trigger should be ok.
>
> Best regards,
>
Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 0/8] USB: add device-tree support for interfaces
From: Johan Hovold @ 2017-11-17 16:30 UTC (permalink / raw)
To: Rob Herring
Cc: Johan Hovold, Greg Kroah-Hartman, Mark Rutland, Arnd Bergmann,
Alan Stern, Peter Chen, Linux USB List,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki, Florian Fainelli
In-Reply-To: <CAL_JsqKFpa6_0nB5ftgFRvwqMN8aBGymASZY7ZeykN0MD6UWbw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Nov 16, 2017 at 12:33:33PM -0600, Rob Herring wrote:
> On Thu, Nov 16, 2017 at 10:12 AM, Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > On Thu, Nov 16, 2017 at 08:43:21AM -0600, Rob Herring wrote:
> >> On Thu, Nov 09, 2017 at 06:07:15PM +0100, Johan Hovold wrote:
> >> > This series adds support for representing USB interfaces in device tree
> >> > by implementing support for "interface nodes" and "combined nodes" from
> >> > the OF specification.
> >> >
> >> > This is needed to be able to describe non-discoverable properties of
> >> > permanently attached USB devices and their interfaces such as any
> >> > i2c-clients connected to a USB-i2c bridge (e.g. the dln2 mfd) or,
> >> > eventually, devices connected to usb-serial converters (to be used with
> >> > serdev).
> >>
> >> In the original OF binding, the firmware dynamically generated the tree
> >> for the active configuration AIUI. That doesn't really fit for the
> >> (mostly) static FDT usage and why we stopped at the device level. So how
> >> do we handle multiple configs? Or can we assume that if say the I2C bus
> >> is used, then there's only one config and interface that can use it?
> >
> > Multiple configuration can be used to implement different sets of
> > functionality. A hypothetical device could have one i2c controller in
> > one configuration and two in another. Most devices will only have one
> > configuration though.
>
> Right, but ultimately the device has the physical interface (pins) and
> we could have multiple USB interfaces pointing to the single physical
> interface. How do we represent that without duplicating the DT data in
> both interfaces? I guess we can do a phandle to the I2C bus as we do
> sometimes.
Yeah, that could lead to some duplication. Also note that configurations
can have different properties such as maximum power consumption, and
that, again hypothetically, some of those external i2c clients may not
be available in every configuration.
> > A USB interface implements some functionality of the device (and this is
> > what Linux USB drivers bind to). So even for single-configuration
> > devices, you need to be able to say which i2c controller (bus) you are
> > describing.
>
> Are you saying the mapping of USB interface to physical interface
> cannot be implied by the specific device? Say, we had something like
> this:
>
> usb-device {
> i2c-bus@0 {};
> i2c-bus@1 {};
> };
>
> Where 0 and 1 are based on the pin out of the device. There's no way
> for the driver to figure out the mapping of USB interfaces to i2c bus?
Not without extra information, no.
> How does the user writing the DT do it?
By verifying the actual device used and encoding it in DT. Remember that
USB typically deals with classes of devices and interfaces. The same USB
(interface) driver can be used for a multitude of devices from various
vendors, who could have ended up wiring those physical connectors
differently. So either this information needs to added to the driver
(e.g. supplement the generic class matching with, say, VID/PID and match
data entries), or it is provided through DT, which seems preferred.
Take for example the generic cdc-acm driver which typically matches on
the interface class and knows nothing about any (other) physical ports.
> > [ And as a simplification, the combined nodes can be used for most cases
> > were we only have one configuration with a single interface. ]
> >
> > Note that a new set of interfaces (in the kernel device model) is
> > created when a new USB device configuration is selected. These new
> > interfaces will be associated with any matching device-tree interface
> > nodes and that these would be distinct from any nodes that matches
> > another configuration.
> >
> > So I don't think there's any problem with dealing with the rare cases of
> > multi-configuration devices.
>
> Perhaps it is rare enough that we don't worry about the above case.
>
> I'm not saying we shouldn't follow the OF spec here, but I also think
> our usecases have changed a bit in 20 years so we could want to do
> something different.
Fair enough, but it seems to me that we actually want to describe also
interfaces in DT to avoid encoding interface-node mappings and implement
lookups in every driver.
For completeness, I should also point out that there are USB interfaces
implementing various forms of MFDs. I already mentioned the dln2 driver,
where all cell components would be described as the children of an
interface (or combined node), for example:
usb-device { // combined node, since only one interface
gpio {}:
i2c {};
spi {};
};
So we do not have a one-controller-per-interface mapping here.
For USB serial, there are examples of both 1-1 and 1-many mappings and
my current plan for describing them as follows:
usb-device2 { // combined node (single interface)
serial@0 {};
serial@1 {};
};
usb-device3 {
interface@0 {
serial@0 {};
};
interface@1 {
serial@0 {};
};
};
And note that in the former case, the driver indeed also needs to be
aware of the physical port mapping (for its interface).
But perhaps I'm getting ahead of myself here.
> The other part of this is how do we make this usecase work on non-DT
> systems or DT systems where the USB topology is not fully described
> because you're just hotplugging the USB device.
Yep, that remains to be determined, but that's not directly related to
this series, which primarly extends and what we currently have (which is
a way of describing permanently attached hubs and devices).
It should be possible to generate and insert device-tree nodes when node
look-up fails during bus enumeration. If we ever get support for loading
overlays from user space, these could then be attached to leaf nodes
(whose drivers would need to be reprobed or at least notified).
But I haven't thought too much about that yet.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: renesas: r8a77970: add GPIO support
From: Simon Horman @ 2017-11-17 16:38 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Geert Uytterhoeven, Rob Herring, Catalin Marinas, Will Deacon,
Linux-Renesas, devicetree@vger.kernel.org, Magnus Damm,
Mark Rutland, linux-arm-kernel@lists.infradead.org
In-Reply-To: <e64bc97b-28b2-a8b5-cde7-804f1a3e24f7@cogentembedded.com>
On Fri, Nov 17, 2017 at 07:11:18PM +0300, Sergei Shtylyov wrote:
> On 11/17/2017 05:19 PM, Simon Horman wrote:
>
> > > > Describe all 6 GPIO controllers in the R8A77970 device tree.
> > > >
> > > > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> > >
> > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > Thanks, applied.
>
> It doesn't build w/o PFC support (and I thought I mde it clearin the
> cover letter), so please either merge R8A77970 PFC patch or pull this one
> out!
Sorry, my bad. I have dropped this series for now.
Please resubmit or otherwise ping me once the dependency hits
an RC release.
^ permalink raw reply
* [PATCHv2] of: Document exactly what of_find_node_by_name() puts
From: Stephen Boyd @ 2017-11-17 16:53 UTC (permalink / raw)
To: Rob Herring, Frank Rowand
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap
It isn't clear if this function of_node_put()s the 'from'
argument, or the node it searches. Clearly indicate which
variable is touched. Fold in some more fixes from Randy too
because we're in the area.
Cc: Randy Dunlap <rdunlap-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Signed-off-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
Changes from v1:
* Fold in Randy's fixes
drivers/of/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 63897531cd75..4368a878df88 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -863,10 +863,10 @@ EXPORT_SYMBOL(of_find_node_opts_by_path);
/**
* of_find_node_by_name - Find a node by its "name" property
- * @from: The node to start searching from or NULL, the node
+ * @from: The node to start searching from or NULL; the node
* you pass will not be searched, only the next one
- * will; typically, you pass what the previous call
- * returned. of_node_put() will be called on it
+ * will. Typically, you pass what the previous call
+ * returned. of_node_put() will be called on @from.
* @name: The name string to match against
*
* Returns a node pointer with refcount incremented, use
--
The Qualcomm Innovation Center, Inc. is a member of the 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 related
* [PATCH] ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen
From: Tony Lindgren @ 2017-11-17 16:56 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Dave Gerlach, Nishanth Menon, Marc Zyngier, Roger Quadros,
Sebastian Reichel
There's been a reproducable USB OHCI/EHCI cpuidle related hang on omap4
for a while that happens after about 20 - 40 minutes on an idle system
with some data feeding device being connected, like a USB GPS device or
a cellular modem.
This issue happens in cpuidle states C2 and C3 and does not happen if
cpuidle is limited to C1 state only. The symptoms are that the whole
system hangs and never wakes up from idle, and if a watchdog is
configured the system reboots after a while.
Turns out that OHCI/EHCI devices on omap4 are trying to use the GIC
interrupt controller directly as a parent instead of the WUGEN. We
need to pass the interrupts through WUGEN to GIC to provide the wakeup
events for the processor.
Let's fix the issue by removing the gic interrupt-parent and use the
default interrupt-parent wakeupgen instead. Note that omap5.dtsi had
this already fixes earlier by commit 7136d457f365 ("ARM: omap: convert
wakeupgen to stacked domains") but we somehow missed omap4 at that
point.
Fixes: 7136d457f365 ("ARM: omap: convert wakeupgen to stacked domains")
Cc: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
Cc: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
Cc: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
Cc: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
Cc: Sebastian Reichel <sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap4.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -1081,14 +1081,12 @@
usbhsohci: ohci@4a064800 {
compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
- interrupt-parent = <&gic>;
interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
};
usbhsehci: ehci@4a064c00 {
compatible = "ti,ehci-omap";
reg = <0x4a064c00 0x400>;
- interrupt-parent = <&gic>;
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
};
};
--
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
* Re: [PATCH] ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen
From: Tony Lindgren @ 2017-11-17 17:00 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Dave Gerlach, Nishanth Menon, Marc Zyngier, Roger Quadros,
Sebastian Reichel, Tero Kristo
In-Reply-To: <20171117165658.21003-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Adding Tero to Cc also.
* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [171117 16:59]:
> There's been a reproducable USB OHCI/EHCI cpuidle related hang on omap4
> for a while that happens after about 20 - 40 minutes on an idle system
> with some data feeding device being connected, like a USB GPS device or
> a cellular modem.
>
> This issue happens in cpuidle states C2 and C3 and does not happen if
> cpuidle is limited to C1 state only. The symptoms are that the whole
> system hangs and never wakes up from idle, and if a watchdog is
> configured the system reboots after a while.
>
> Turns out that OHCI/EHCI devices on omap4 are trying to use the GIC
> interrupt controller directly as a parent instead of the WUGEN. We
> need to pass the interrupts through WUGEN to GIC to provide the wakeup
> events for the processor.
>
> Let's fix the issue by removing the gic interrupt-parent and use the
> default interrupt-parent wakeupgen instead. Note that omap5.dtsi had
> this already fixes earlier by commit 7136d457f365 ("ARM: omap: convert
> wakeupgen to stacked domains") but we somehow missed omap4 at that
> point.
>
> Fixes: 7136d457f365 ("ARM: omap: convert wakeupgen to stacked domains")
> Cc: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
> Cc: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> Cc: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
> Cc: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> Cc: Sebastian Reichel <sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm/boot/dts/omap4.dtsi | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -1081,14 +1081,12 @@
> usbhsohci: ohci@4a064800 {
> compatible = "ti,ohci-omap3";
> reg = <0x4a064800 0x400>;
> - interrupt-parent = <&gic>;
> interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> usbhsehci: ehci@4a064c00 {
> compatible = "ti,ehci-omap";
> reg = <0x4a064c00 0x400>;
> - interrupt-parent = <&gic>;
> interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
> };
> };
> --
> 2.15.0
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 v4 4/5] DTS: gta04: add serdev node for w2sg00x4
From: Tony Lindgren @ 2017-11-17 17:08 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Rob Herring, Mark Rutland, Benoît Cousson, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, Kevin Hilman,
Andreas Färber, Thierry Reding, Jonathan Cameron,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
letux-kernel-S0jZdbWzriLCfDggNXIi3w,
kernel-Jl6IXVxNIMRxAtABVqVhTwC/G2K4zDHf,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <02dde546157359316eebe8e90f5f1de7177bbffa.1510781876.git.hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
* H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> [171115 21:41]:
> GTA04 has a W2SG0004/84 connected to UART2 of the OMAP3
> processor. A GPIO can pulse the on/off toggle switch.
>
> The VSIM regulator is used to power on/off the LNA of an external
> active GPS antenna so that a driver can turn the LNA off if GPS is
> not needed to save battery energy.
>
> Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
> ---
> arch/arm/boot/dts/omap3-gta04.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 4504908c23fe..e967d738aaaf 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -477,6 +477,12 @@
> &uart2 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart2_pins>;
> +
> + gps: gps {
> + compatible = "wi2wi,w2sg0004";
> + lna-supply = <&vsim>; /* LNA regulator */
> + enable-gpios = <&gpio5 17 GPIO_ACTIVE_HIGH>; /* GPIO_145: trigger for turning on/off w2sg0004 */
> + };
> };
How about move the comment above the node to avoid long lines?
Or just change it to gpio_145 for the comment as the property
is already enable-gpios?
Regards,
Tony
--
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: [PATCHv2] of: Document exactly what of_find_node_by_name() puts
From: Randy Dunlap @ 2017-11-17 17:19 UTC (permalink / raw)
To: Stephen Boyd, Rob Herring, Frank Rowand
Cc: linux-kernel, linux-doc, devicetree
In-Reply-To: <20171117165321.18591-1-sboyd@codeaurora.org>
On 11/17/2017 08:53 AM, Stephen Boyd wrote:
> It isn't clear if this function of_node_put()s the 'from'
> argument, or the node it searches. Clearly indicate which
> variable is touched. Fold in some more fixes from Randy too
> because we're in the area.
>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> Changes from v1:
> * Fold in Randy's fixes
>
> drivers/of/base.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 63897531cd75..4368a878df88 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -863,10 +863,10 @@ EXPORT_SYMBOL(of_find_node_opts_by_path);
>
> /**
> * of_find_node_by_name - Find a node by its "name" property
> - * @from: The node to start searching from or NULL, the node
> + * @from: The node to start searching from or NULL; the node
> * you pass will not be searched, only the next one
> - * will; typically, you pass what the previous call
> - * returned. of_node_put() will be called on it
> + * will. Typically, you pass what the previous call
> + * returned. of_node_put() will be called on @from.
> * @name: The name string to match against
> *
> * Returns a node pointer with refcount incremented, use
>
Looks good. Thanks.
Acked-by: Randy Dunlap <rdunlap@infradead.org>
--
~Randy
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: mtd: Add sst25vf016b to the list of supported chip names
From: Cyrille Pitchen @ 2017-11-17 17:36 UTC (permalink / raw)
To: Fabrizio Castro, David Woodhouse, Brian Norris, Boris Brezillon,
Marek Vasut, Richard Weinberger, Rob Herring, Mark Rutland
Cc: devicetree, Chris Paterson, linux-kernel, Biju Das, linux-mtd
In-Reply-To: <1508853032-25229-1-git-send-email-fabrizio.castro@bp.renesas.com>
Hi Fabrizio,
sorry but I won't apply this patch.
New values for the 'compatible' DT properties should only be added for
memory parts not supporting the JEDEC READ ID (0x9F) command.
SST25 memories do support this command hence should use the "jedec,spi-nor"
value alone. For historical reasons, some DT nodes set their 'compatible'
string to something like "<vendor>,<model>", "jedec,spi-nor".
It should work as expected in most case however I discourage from doing so
in new device trees because it may have some side effects especially when
the m25p80.c driver is used between the spi-nor.c driver and the SPI
controller driver.
It's all about setting the 2nd parameter of spi_nor_scan(), the 'name'
parameter, as NULL when possible. This parameter should be set to a non NULL
value only for memories not supporting the JEDEC READ ID op code (0x9F).
Best regards,
Cyrille
Le 24/10/2017 à 15:50, Fabrizio Castro a écrit :
> There are a few DT files that make use of sst25vf016b in their
> compatible strings, and the driver supports this chip already.
> This patch improves the documentation and therefore the result
> of ./scripts/checkpatch.pl.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Thank you Rob, thank you Geert, and sorry for the delay on this one.
> Here is v2.
>
> Changes in v2:
> * fixed subject prefix
> * added changelog
>
> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> index 4cab5d8..bf56d77 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> @@ -31,6 +31,7 @@ Required properties:
> s25sl12801
> s25fl008k
> s25fl064k
> + sst25vf016b
> sst25vf040b
> sst25wf040b
> m25p40
>
^ permalink raw reply
* RE: [PATCH v2] dt-bindings: mtd: Add sst25vf016b to the list of supported chip names
From: Fabrizio Castro @ 2017-11-17 17:40 UTC (permalink / raw)
To: Cyrille Pitchen, David Woodhouse, Brian Norris, Boris Brezillon,
Marek Vasut, Richard Weinberger, Rob Herring, Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Chris Paterson,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Biju Das,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <658ceb2b-5d2b-9349-f140-27858459e5a8-yU5RGvR974pGWvitb5QawA@public.gmane.org>
Hello Cyrille,
it's ok, thank you for the feedback.
Best regards,
Fab
> Hi Fabrizio,
>
> sorry but I won't apply this patch.
>
> New values for the 'compatible' DT properties should only be added for
> memory parts not supporting the JEDEC READ ID (0x9F) command.
>
> SST25 memories do support this command hence should use the "jedec,spi-nor"
> value alone. For historical reasons, some DT nodes set their 'compatible'
> string to something like "<vendor>,<model>", "jedec,spi-nor".
> It should work as expected in most case however I discourage from doing so
> in new device trees because it may have some side effects especially when
> the m25p80.c driver is used between the spi-nor.c driver and the SPI
> controller driver.
>
> It's all about setting the 2nd parameter of spi_nor_scan(), the 'name'
> parameter, as NULL when possible. This parameter should be set to a non NULL
> value only for memories not supporting the JEDEC READ ID op code (0x9F).
>
> Best regards,
>
> Cyrille
>
> Le 24/10/2017 à 15:50, Fabrizio Castro a écrit :
> > There are a few DT files that make use of sst25vf016b in their
> > compatible strings, and the driver supports this chip already.
> > This patch improves the documentation and therefore the result
> > of ./scripts/checkpatch.pl.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
> > Acked-by: Rob Herring <robh@kernel.org>
> > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > Thank you Rob, thank you Geert, and sorry for the delay on this one.
> > Here is v2.
> >
> > Changes in v2:
> > * fixed subject prefix
> > * added changelog
> >
> > Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-
> nor.txt
> > index 4cab5d8..bf56d77 100644
> > --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> > +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> > @@ -31,6 +31,7 @@ Required properties:
> > s25sl12801
> > s25fl008k
> > s25fl064k
> > + sst25vf016b
> > sst25vf040b
> > sst25wf040b
> > m25p40
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* RE: [PATCH] dt-bindings: qspi: Add r8a7743/5 to the compatible list
From: Fabrizio Castro @ 2017-11-17 18:00 UTC (permalink / raw)
To: Fabrizio Castro, Mark Brown, Rob Herring, Mark Rutland
Cc: Simon Horman, Chris Paterson, Biju Das, linux-spi@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Russell King, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1504858035-3568-1-git-send-email-fabrizio.castro@bp.renesas.com>
Dear All,
this patch has been around for some time now, it was reviewed-by Geert Uytterhoeven and acked-by Rob Herring, any news?
Thanks,
Fab
> Subject: [PATCH] dt-bindings: qspi: Add r8a7743/5 to the compatible list
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/spi/spi-rspi.txt | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-rspi.txt b/Documentation/devicetree/bindings/spi/spi-rspi.txt
> index 8f4169f..3b02b3a 100644
> --- a/Documentation/devicetree/bindings/spi/spi-rspi.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt
> @@ -5,11 +5,14 @@ Required properties:
> "renesas,rspi-<soctype>", "renesas,rspi" as fallback.
> For Renesas Serial Peripheral Interface on RZ/A1H:
> "renesas,rspi-<soctype>", "renesas,rspi-rz" as fallback.
> - For Quad Serial Peripheral Interface on R-Car Gen2:
> + For Quad Serial Peripheral Interface on R-Car Gen2 and
> + RZ/G1 devices:
> "renesas,qspi-<soctype>", "renesas,qspi" as fallback.
> Examples with soctypes are:
> - "renesas,rspi-sh7757" (SH)
> - "renesas,rspi-r7s72100" (RZ/A1H)
> +- "renesas,qspi-r8a7743" (RZ/G1M)
> +- "renesas,qspi-r8a7745" (RZ/G1E)
> - "renesas,qspi-r8a7790" (R-Car H2)
> - "renesas,qspi-r8a7791" (R-Car M2-W)
> - "renesas,qspi-r8a7792" (R-Car V2H)
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* Re: [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver
From: Dan Murphy @ 2017-11-17 18:02 UTC (permalink / raw)
To: Jingoo Han, 'Pavel Machek'
Cc: 'Jacek Anaszewski', robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, 'Lee Jones',
'Daniel Thompson'
In-Reply-To: <000b01d35fc1$57ad0500$07070f00$@gmail.com>
Pavel and Jacek
On 11/17/2017 10:30 AM, Jingoo Han wrote:
> On Friday, November 17, 2017 6:21 AM, Pavel Machek wrote:
>>
>> Hi!
>>
>>>>> If that does not yet exist... you want to create glue layer to be
>> able
>>>>> to use LED as a display backlight. (It may already exist, no idea).
>>>>>
>>>>> ...
>>>>>
>>>>> Actually or maybe a LED trigger. Just set LED's trigger to "this is
>>>>> display backlight".
>>>>
>>>> There is one already:
>>>>
>>>> drivers/leds/trigger/ledtrig-backlight.c
>>>>
>>>> It adds a LED class device to the fb_notifier_list
>>>> (drivers/video/fbdev/core/fb_notify.c)
>>>>
>>>> using fb_register_client(). The same is used in
>>>> backlight_device_register (drivers/video/backlight/backlight.c).
>>>>
>>>> Actually why do you want to have this driver in the LED subsystem,
>>>> if it is advertised as "designed for LCD display backlighting"?
>>>
>>> Well this is also advertised as a driver for Smart phone and tablet
>> devices. And having worked with the Android lighting
>>> solutions this is the preferred subsystem for Android. The Android OS
>> manages the led brightness based on ALS values and in
>>> turn calls into the driver to control the brightness register through
>> the vendor provided lighting HAL.
>>>
>>
>> Well.. if it can control other LEDs than just backlight, I believe it
>> can stay in the LED subsystem.
>
> I also agree with your opinion.
I will make the necessary changes for v4.
Just a heads up I won't be posting v4 until after the US holiday so you
don't think I abandoned everything.
Dan
>
> Best regards,
> Jingoo Han
>
>>
>>> I am going to look at the backlight source to figure out how to get the
>> same functionality using the backlight subsystem.
>>> Otherwise I will plug in this driver to the backlight subsystem through
>> the notifier.
>>>
>>
>> The backlight trigger should be ok.
>>
>> Best regards,
>>
> Pavel
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures)
>> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
--
------------------
Dan Murphy
--
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 3/5] checks: add string list check for *-names properties
From: Rob Herring @ 2017-11-17 18:07 UTC (permalink / raw)
To: Andre Przywara
Cc: Devicetree Compiler,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <8eea3f9e-5512-dc6c-f755-58cc333db732-5wv7dgnIgG8@public.gmane.org>
On Fri, Nov 17, 2017 at 9:12 AM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
> Hi,
>
> On 17/11/17 14:45, Rob Herring wrote:
>> Add a string list check for common properties ending in "-names" such as
>> reg-names or interrupt-names.
>>
>> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> ---
>> checks.c | 17 ++++++++++++++++-
>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/checks.c b/checks.c
>> index 4e23f29486bb..346b0256f9cb 100644
>> --- a/checks.c
>> +++ b/checks.c
>> @@ -622,6 +622,21 @@ WARNING_IF_NOT_STRING(stdout_path_is_string, "stdout-path");
>>
>> WARNING_IF_NOT_STRING_LIST(compatible_is_string_list, "compatible");
>>
>> +static void check_names_is_string_list(struct check *c, struct dt_info *dti,
>> + struct node *node)
>> +{
>> + struct property *prop;
>> +
>> + for_each_property(node, prop) {
>> + if (!strstr(prop->name, "-names"))
>
> But that would match "actually-names-dont-matter" as well, resulting in
> a false positive? Should we check if the string appears at the *end* of
> the property name?
Perhaps. IMO, once a word is used, it needs to be reserved for that
purpose. For example, the gpio hogs binding use of "gpios" with just
numbers and no phandle is bad because we have a mixture of types for a
given property name or suffix. So we should really enforce that
"-names" only appears as a suffix and use anywhere else is a warning.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: qspi: Add r8a7743/5 to the compatible list
From: Mark Brown @ 2017-11-17 18:08 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Rob Herring, Mark Rutland, Simon Horman, Chris Paterson, Biju Das,
linux-spi@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Russell King,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <TY1PR06MB08958546062D685532669977C02F0@TY1PR06MB0895.apcprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
On Fri, Nov 17, 2017 at 06:00:46PM +0000, Fabrizio Castro wrote:
> this patch has been around for some time now, it was reviewed-by Geert Uytterhoeven and acked-by Rob Herring, any news?
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, though there are some other maintainers who like them - if in
doubt look at how patches for the subsystem are normally handled.
Please submit patches using subject lines reflecting the style for the
subsystem. This makes it easier for people to identify relevant
patches. Look at what existing commits in the area you're changing are
doing and make sure your subject lines visually resemble what they're
doing.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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