* Re: [PATCH v3 3/8] PCI: brcmstb: Add Broadcom STB PCIe host controller driver
From: Jim Quinlan @ 2017-12-15 19:53 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-kernel, Bjorn Helgaas, Catalin Marinas, Will Deacon,
Rob Herring, Brian Norris, Russell King, Robin Murphy,
Christoph Hellwig, Florian Fainelli, Jonas Gorski, Mark Rutland,
devicetree, Linux-MIPS, linux-pci, Kevin Cernekee, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, linux-arm-kernel
In-Reply-To: <20171214225133.GM30595@bhelgaas-glaptop.roam.corp.google.com>
On Thu, Dec 14, 2017 at 5:51 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, Dec 13, 2017 at 06:53:53PM -0500, Jim Quinlan wrote:
>> On Tue, Dec 12, 2017 at 5:16 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > On Tue, Nov 14, 2017 at 05:12:07PM -0500, Jim Quinlan wrote:
>> >> This commit adds the basic Broadcom STB PCIe controller. Missing is
>> >> the ability to process MSI and also handle dma-ranges for inbound
>> >> memory accesses. These two functionalities are added in subsequent
>> >> commits.
>> >>
>> >> The PCIe block contains an MDIO interface. This is a local interface
>> >> only accessible by the PCIe controller. It cannot be used or shared
>> >> by any other HW. As such, the small amount of code for this
>> >> controller is included in this driver as there is little upside to put
>> >> it elsewhere.
>> ...
>
>> >> +static bool brcm_pcie_valid_device(struct brcm_pcie *pcie, struct pci_bus *bus,
>> >> + int dev)
>> >> +{
>> >> + if (pci_is_root_bus(bus)) {
>> >> + if (dev > 0)
>> >> + return false;
>> >> + } else {
>> >> + /* If there is no link, then there is no device */
>> >> + if (!brcm_pcie_link_up(pcie))
>> >> + return false;
>> >
>> > This is racy, since the link can go down after you check but before
>> > you do the config access. I assume your hardware can deal with a
>> > config access that targets a link that is down?
>>
>> Yes, that can happen but there is really nothing that can be done if
>> the link goes down in that vulnerability window. What do you suggest
>> doing?
>
> Most hardware drops writes and returns ~0 on reads if the link is
> down. I assume your hardware does something similar, and that should
> be enough. You shouldn't have to check whether the link is up.
Unfortunately our HW is quite unforgiving and effects a synchronous or
asynchronous abort when doing a config access when the link or power
has gone down on the EP. I will open a discussion with the PCIe HW
folks regarding why our controller does not behave like "most
hardware". Thanks, Jim
>
> The hardware might report errors, e.g., via AER, if the link is down.
> And we might not not handle those nicely. If we have issues there, we
> should find out and fix them.
>
> I see that dwc, altera, rockchip, and xilinx all do check for link up
> there, too. I can't remember if they had a legitimate reason, or if I
> just missed it.
>
>> >> +static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
>> >> +{
>> >> + struct list_head *pos, *q;
>> >> + struct brcm_pcie *tmp;
>> >> +
>> >> + mutex_lock(&brcm_pcie_lock);
>> >> + list_for_each_safe(pos, q, &brcm_pcie) {
>> >> + tmp = list_entry(pos, struct brcm_pcie, list);
>> >> + if (tmp == pcie) {
>> >> + list_del(pos);
>> >> + if (list_empty(&brcm_pcie))
>> >> + num_memc = 0;
>> >> + break;
>> >> + }
>> >> + }
>> >> + mutex_unlock(&brcm_pcie_lock);
>> >
>> > I'm missing something. I don't see that num_memc is ever set to
>> > anything *other* than zero.
>> The num_memc is set and used in the dma commit. I will remove its
>> declaration from this commit.
>
> Thanks, that will make the patches much easier to read.
>
>> >> + pcie->id = of_get_pci_domain_nr(dn);
>> >
>> > Why do you call of_get_pci_domain_nr() directly? No other driver
>> > does.
>>
>> We use the domain as the controller number (id). We use the id to
>> identify and fix a HW bug that only affects the 2nd controller; see
>> the clause
>> " } else if (of_machine_is_compatible("brcm,bcm7278a0")) {".
>
> pci_register_host_bridge() already sets bus->domain_nr for every host
> bridge. That path calls of_get_pci_domain_nr() eventually. But I
> guess that's too late for your use case, because you have this:
>
> brcm_pcie_probe
> brcm_pcie_setup
> brcm_pcie_bridge_sw_init_set
> if (of_machine_is_compatible("brcm,bcm7278a0")) {
> offset = pcie->id ? ... <--- use
> pci_scan_root_bus_bridge
> pci_register_host_bridge
> bus->domain_nr = pci_bus_find_domain_nr <--- available
>
> I guess you haven't added a binding for brcm,bcm7278a0 yet?
>
> I'm not really sure that using the linux,pci-domain DT property is the
> best way to distinguish the two controllers. Maybe Rob has an
> opinion?
>
>> >> + if (pcie->id < 0)
>> >> + return pcie->id;
>
> Bjorn
^ permalink raw reply
* Re: [PATCH v7 0/6] add clk controller driver for Meson-AXG SoC
From: Kevin Hilman @ 2017-12-15 20:00 UTC (permalink / raw)
To: Jerome Brunet
Cc: Yixun Lan, Neil Armstrong, Rob Herring, Mark Rutland,
Michael Turquette, Stephen Boyd, Carlo Caione, Qiufang Dai,
Jian Hu, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513245826.32163.7.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
> On Mon, 2017-12-11 at 22:13 +0800, Yixun Lan wrote:
>> Qiufang Dai (3):
>> clk: meson-axg: add clocks dt-bindings required header
>> clk: meson-axg: add clock controller drivers
>> arm64: dts: meson-axg: add clock DT info for Meson AXG SoC
>>
>> Yixun Lan (3):
>> clk: meson: make the spinlock naming more specific
>> dt-bindings: clock: add compatible variant for the Meson-AXG
>> arm64: dts: meson-axg: switch uart_ao clock to CLK81
>>
>> .../bindings/clock/amlogic,gxbb-clkc.txt | 7 +-
>> arch/arm64/Kconfig.platforms | 1 +
>> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 2 +
>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 19 +-
>> drivers/clk/meson/Kconfig | 8 +
>> drivers/clk/meson/Makefile | 1 +
>> drivers/clk/meson/axg.c | 936 +++++++++++++++++++++
>> drivers/clk/meson/axg.h | 126 +++
>> drivers/clk/meson/clkc.h | 2 +-
>> drivers/clk/meson/gxbb.c | 112 +--
>> drivers/clk/meson/meson8b.c | 24 +-
>> include/dt-bindings/clock/axg-clkc.h | 71 ++
>> 12 files changed, 1234 insertions(+), 75 deletions(-)
>> create mode 100644 drivers/clk/meson/axg.c
>> create mode 100644 drivers/clk/meson/axg.h
>> create mode 100644 include/dt-bindings/clock/axg-clkc.h
>
> Kevin,
>
> I took the first 4 patches through clk-meson. I left the last 2 for you.
>
> I have applied the DT bindings update separately.
> Let me know if you have dependency on these new bindings and need a tag.
Yes, I will need a tag on the headers since both the "switch uart_ao"
patch and a subsequent patch to add DT for SPICC are using new clock
IDs.
Thanks,
Kevin
--
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 4/6] dt-bindings: pwm: renesas-tpu: Document r8a774[35] support
From: Rob Herring @ 2017-12-15 20:13 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Thierry Reding, Mark Rutland, Simon Horman, Geert Uytterhoeven,
Chris Paterson, Biju Das, linux-pwm, devicetree,
linux-renesas-soc
In-Reply-To: <1513248976-26700-5-git-send-email-fabrizio.castro@bp.renesas.com>
On Thu, Dec 14, 2017 at 10:56:14AM +0000, Fabrizio Castro wrote:
> Document r8a774[35] specific compatible strings. No driver change is
> needed as the fallback compatible string "renesas,tpu" activates the
> right code in the driver.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 3/8] PCI: brcmstb: Add Broadcom STB PCIe host controller driver
From: Bjorn Helgaas @ 2017-12-15 20:14 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Bjorn Helgaas,
Catalin Marinas, Will Deacon, Rob Herring, Brian Norris,
Russell King, Robin Murphy, Christoph Hellwig, Florian Fainelli,
Jonas Gorski, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Linux-MIPS, linux-pci, Kevin Cernekee, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, linux-arm-kernel
In-Reply-To: <CANCKTBvFhHb57JdG01aiSypBAcUeLzY3Dhuh5xP-_F5k_NcAhA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Dec 15, 2017 at 02:53:57PM -0500, Jim Quinlan wrote:
> On Thu, Dec 14, 2017 at 5:51 PM, Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > On Wed, Dec 13, 2017 at 06:53:53PM -0500, Jim Quinlan wrote:
> >> On Tue, Dec 12, 2017 at 5:16 PM, Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >> > On Tue, Nov 14, 2017 at 05:12:07PM -0500, Jim Quinlan wrote:
> >> >> This commit adds the basic Broadcom STB PCIe controller. Missing is
> >> >> the ability to process MSI and also handle dma-ranges for inbound
> >> >> memory accesses. These two functionalities are added in subsequent
> >> >> commits.
> >> >>
> >> >> The PCIe block contains an MDIO interface. This is a local interface
> >> >> only accessible by the PCIe controller. It cannot be used or shared
> >> >> by any other HW. As such, the small amount of code for this
> >> >> controller is included in this driver as there is little upside to put
> >> >> it elsewhere.
> >> ...
> >
> >> >> +static bool brcm_pcie_valid_device(struct brcm_pcie *pcie, struct pci_bus *bus,
> >> >> + int dev)
> >> >> +{
> >> >> + if (pci_is_root_bus(bus)) {
> >> >> + if (dev > 0)
> >> >> + return false;
> >> >> + } else {
> >> >> + /* If there is no link, then there is no device */
> >> >> + if (!brcm_pcie_link_up(pcie))
> >> >> + return false;
> >> >
> >> > This is racy, since the link can go down after you check but before
> >> > you do the config access. I assume your hardware can deal with a
> >> > config access that targets a link that is down?
> >>
> >> Yes, that can happen but there is really nothing that can be done if
> >> the link goes down in that vulnerability window. What do you suggest
> >> doing?
> >
> > Most hardware drops writes and returns ~0 on reads if the link is
> > down. I assume your hardware does something similar, and that should
> > be enough. You shouldn't have to check whether the link is up.
> Unfortunately our HW is quite unforgiving and effects a synchronous or
> asynchronous abort when doing a config access when the link or power
> has gone down on the EP. I will open a discussion with the PCIe HW
> folks regarding why our controller does not behave like "most
> hardware". Thanks, Jim
I mentioned in the other thread [1] that I think the best way to
handle this is to figure out how to deal with the abort cleanly.
Using a test like *_pcie_link_up() to try to avoid it is a 99%
solution that means we'll see rare failures that are very difficult to
reproduce and debug.
> > The hardware might report errors, e.g., via AER, if the link is down.
> > And we might not not handle those nicely. If we have issues there, we
> > should find out and fix them.
[1] https://lkml.kernel.org/r/20171214225821.GN30595-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/2] ARM64: dts: meson-axg: add pinctrl DT info for Meson-AXG SoC
From: Kevin Hilman @ 2017-12-15 20:20 UTC (permalink / raw)
To: Yixun Lan
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland, Linus Walleij, Neil Armstrong, Jerome Brunet,
Carlo Caione, Xingyu Chen, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171208015418.9632-3-yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org> writes:
> From: Xingyu Chen <xingyu.chen-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>
> Add new pinctrl DT info for the Amlogic's Meson-AXG SoC.
>
> Reviewed-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Xingyu Chen <xingyu.chen-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 44 ++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index e7213eb53958..7b24f83ab4bf 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/gpio/meson-axg-gpio.h>
FYI: I dropped this line, since it's not used (yet) and it causes an
unncessary dependency on an external tree. It can be added back as soon
as there are users.
Kevin
--
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 07/13] dt-bindings: power: reset: Document ocelot-reset binding
From: Rob Herring @ 2017-12-15 20:23 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Ralf Baechle, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sebastian Reichel,
linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171208154618.20105-8-alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Fri, Dec 08, 2017 at 04:46:12PM +0100, Alexandre Belloni wrote:
> Add binding documentation for the Microsemi Ocelot reset block.
>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> .../devicetree/bindings/power/reset/ocelot-reset.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>
> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> new file mode 100644
> index 000000000000..1bcf276b04cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> @@ -0,0 +1,17 @@
> +Microsemi Ocelot reset controller
> +
> +The DEVCPU_GCB:CHIP_REGS have a SOFT_RST register that can be used to reset the
> +SoC MIPS core.
> +
> +Required Properties:
> + - compatible: "mscc,ocelot-chip-reset"
> +
> +Example:
> + syscon@71070000 {
> + compatible = "mscc,ocelot-chip-regs", "simple-mfd", "syscon";
> + reg = <0x71070000 0x1c>;
> +
> + reset {
> + compatible = "mscc,ocelot-chip-reset";
Why do you need a subnode here other than as a way to instantiate a
driver? Can you describe the SOFT_RST register in reg property here
(without having overlapping regions)?
--
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: [RESEND PATCH v2] dt: bindings: as3645a: Fix the example node
From: Rob Herring @ 2017-12-15 20:26 UTC (permalink / raw)
To: Dan Murphy
Cc: mark.rutland, rpurdie, jacek.anaszewski, pavel, devicetree,
linux-kernel, linux-leds
In-Reply-To: <50214549-63d1-f92e-d4e7-dc6533477d83@ti.com>
On Fri, Dec 08, 2017 at 09:56:18AM -0600, Dan Murphy wrote:
> Resent to include DT maintainers
>
> On 12/08/2017 09:55 AM, Dan Murphy wrote:
> > Fix the address-cells and size-cells example node
> > to reflect to the correct representation.
> >
> > Signed-off-by: Dan Murphy <dmurphy@ti.com>
> > Acked-by: Pavel Machek <pavel@ucw.cz>
> > ---
> >
> > v2 - Moved compatible to be first in the node - https://patchwork.kernel.org/patch/10092937/
> >
> > Documentation/devicetree/bindings/leds/ams,as3645a.txt | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> > index fdc40e354a64..fc7f5f9f234c 100644
> > --- a/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> > +++ b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> > @@ -59,10 +59,10 @@ Example
> > =======
> >
> > as3645a@30 {
>
> Rob
>
> Here is an example of the device name being part of the node name.
>
> Should this be changed as well to leds@30?
Yes, but I misspoke earlier and it should be "led-controller@30"
That can be a separate patch though, so for this one:
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver
From: Pavel Machek @ 2017-12-15 20:30 UTC (permalink / raw)
To: Kiran Gunda
Cc: bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Lee Jones, Daniel Thompson,
Jingoo Han, Richard Purdie, Jacek Anaszewski, Rob Herring,
Mark Rutland, Bartlomiej Zolnierkiewicz,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-owner-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1510834717-21765-2-git-send-email-kgunda-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2555 bytes --]
On Thu 2017-11-16 17:48:34, Kiran Gunda wrote:
> WLED driver provides the interface to the display driver to
> adjust the brightness of the display backlight.
>
> Signed-off-by: Kiran Gunda <kgunda-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> .../bindings/leds/backlight/qcom-spmi-wled.txt | 90 ++++
> drivers/video/backlight/Kconfig | 9 +
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/qcom-spmi-wled.c | 504 +++++++++++++++++++++
> 4 files changed, 604 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> create mode 100644 drivers/video/backlight/qcom-spmi-wled.c
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> new file mode 100644
> index 0000000..f1ea25b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> @@ -0,0 +1,90 @@
> +Binding for Qualcomm WLED driver
> +
> +WLED (White Light Emitting Diode) driver is used for controlling display
> +backlight that is part of PMIC on Qualcomm Technologies reference platforms.
> +The PMIC is connected to the host processor via SPMI bus.
> +
> +- compatible
> + Usage: required
> + Value type: <string>
> + Definition: should be "qcom,pm8998-spmi-wled".
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Base address and size of the WLED modules.
> +
> +- reg-names
> + Usage: required
> + Value type: <string>
> + Definition: Names associated with base addresses. should be
> + "qcom-wled-ctrl-base", "qcom-wled-sink-base".
> +
> +- label
> + Usage: required
> + Value type: <string>
> + Definition: The name of the backlight device.
> +
> +- default-brightness
> + Usage: optional
> + Value type: <u32>
> + Definition: brightness value on boot, value from: 0-4095
> + default: 2048
> +
> +- qcom,fs-current-limit
I'd add "-uA" suffix here.
> + Usage: optional
> + Value type: <u32>
> + Definition: per-string full scale current limit in uA. value from
> + 0 to 30000 with 5000 uA resolution. default: 25000 uA
> +
> +- qcom,current-boost-limit
And -mA suffix here. Similar for other units.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: gpu: mali-utgard: add rockchip,rk3328-mali compatible
From: Rob Herring @ 2017-12-15 20:30 UTC (permalink / raw)
To: Heiko Stuebner
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171209000738.32187-2-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
On Sat, Dec 09, 2017 at 01:07:36AM +0100, Heiko Stuebner wrote:
> The rk3328 quad-core Cortex A53 uses a Mali-450MP2 with 2 PPs, so
> add a compatible for it.
>
> Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 1 +
> 1 file changed, 1 insertion(+)
For the series,
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Though I don't think it's really necessary to enable the gpu per board
as it has no pinout. Default enabled would be better IMO.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/7] Add USB remote wakeup driver
From: Rob Herring @ 2017-12-15 20:55 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Felipe Balbi, Matthias Brugger, Mathias Nyman, Mark Rutland,
Greg Kroah-Hartman, Catalin Marinas, Will Deacon, Jean Delvare,
Sean Wang, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1512809136-2779-1-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Sat, Dec 09, 2017 at 04:45:29PM +0800, Chunfeng Yun wrote:
> These patches introduce the SSUSB and SPM glue layer driver which is
> used to support usb remote wakeup. Usually the glue layer is put into
> a system controller, such as PERICFG module.
> The old way to support usb wakeup is put into SSUSB controller drivers,
> including xhci-mtk driver and mtu3 driver, but there are some problems:
> 1. can't disdinguish the relation between glue layer and SSUSB IP
> when SoCs supports multi SSUSB IPs;
> 2. duplicated code for wakeup are put into both xhci-mtk and mtu3
> drivers;
> 3. the glue layer may vary on different SoCs with SSUSB IP, and will
> make SSUSB controller drivers complicated;
> In order to resolve these problems, it's useful to make the glue layer
> transparent by extracting a seperated driver, meanwhile to reduce the
> duplicated code and simplify SSUSB controller drivers.
Both the driver and binding look overly complicated to me when it looks
like you just have 2 versions of enable/disable functions which modify
a single register. The complexity may be justified if this was a common
binding and driver, but it is not.
You already have a phandle to the system controller. Can't you add cells
to it to handle any differences between instances? That and SoC specific
compatible strings should be enough to handle differences.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/7] soc: mediatek: Add USB wakeup driver
From: Rob Herring @ 2017-12-15 20:55 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Felipe Balbi, Matthias Brugger, Mathias Nyman, Mark Rutland,
Greg Kroah-Hartman, Catalin Marinas, Will Deacon, Jean Delvare,
Sean Wang, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1512809136-2779-2-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Sat, Dec 09, 2017 at 04:45:30PM +0800, Chunfeng Yun wrote:
> This driver is used to support usb wakeup which is controlled by
> the glue layer between SSUSB and SPM. Usually the glue layer is put
> into a system controller, such as pericfg module, which is
> represented by a syscon node in DTS.
> Due to the glue layer may vary on different SoCs, it's useful to
> extract a separated driver to simplify usb controller drivers.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> drivers/soc/mediatek/Kconfig | 8 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-usb-wakeup.c | 519 ++++++++++++++++++++++++++
> include/dt-bindings/soc/mediatek,usb-wakeup.h | 15 +
This belongs in the binding patch and that should come first.
> include/linux/soc/mediatek/usb-wakeup.h | 88 +++++
> 5 files changed, 631 insertions(+)
> create mode 100644 drivers/soc/mediatek/mtk-usb-wakeup.c
> create mode 100644 include/dt-bindings/soc/mediatek,usb-wakeup.h
> create mode 100644 include/linux/soc/mediatek/usb-wakeup.h
> +++ b/drivers/soc/mediatek/mtk-usb-wakeup.c
> @@ -0,0 +1,519 @@
> +/*
> + * Copyright (c) 2017 MediaTek Inc.
> + * Author: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> + *
> + * SPDX-License-Identifier: GPL-2.0
This should be the first line of the file and use a // style comment.
[...]
> diff --git a/include/dt-bindings/soc/mediatek,usb-wakeup.h b/include/dt-bindings/soc/mediatek,usb-wakeup.h
> new file mode 100644
> index 0000000..2461795
> --- /dev/null
> +++ b/include/dt-bindings/soc/mediatek,usb-wakeup.h
> @@ -0,0 +1,15 @@
> +/*
> + * Copyright (c) 2017 MediaTek Inc.
> + * Author: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> + *
> + * SPDX-License-Identifier: GPL-2.0
ditto. Except headers use /* */ comments...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.
From: Pavel Machek @ 2017-12-15 20:57 UTC (permalink / raw)
To: Enric Balletbo Serra
Cc: Daniel Thompson, Doug Anderson, Enric Balletbo i Serra,
Jingoo Han, Richard Purdie, Jacek Anaszewski, Rob Herring,
Brian Norris, Guenter Roeck, Lee Jones, Alexandru Stan,
linux-leds, devicetree@vger.kernel.org, LKML
In-Reply-To: <CAFqH_50qgvntzwvZ_n3qhpw+BA2SpYqiJgsxfCMt1piNWzgDmA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 784 bytes --]
Hi!
> Yes, I think that how you describe luminance and lightness is right,
> and sounds good improve the doc.
>
> To be clear the correction table for PWM values can be calculated with
> this code.
>
> OUTPUT_SIZE = 65535 # Output integer size
> INPUT_SIZE = 2047
>
> def cie1931(L):
> L = L*100.0
> if L <= 8:
> return (L/902.3)
> else:
> return ((L+16.0)/116.0)**3
>
> x = range(0,int(INPUT_SIZE+1))
> y = [int(round(cie1931(float(L)/INPUT_SIZE)*(OUTPUT_SIZE))) for L in x]
Can we just generate the table on the fly? Should not be hard to do in
fixed point, right?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v4 4/6] dt: bindings: lp8860: Add trigger binding to the lp8860
From: Pavel Machek @ 2017-12-15 21:00 UTC (permalink / raw)
To: Dan Murphy
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <76329432-f96e-93ab-ed9b-ade22c8735c9-l0cyMroinI0@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]
On Fri 2017-12-15 11:22:24, Dan Murphy wrote:
> Pavel
>
> On 12/15/2017 03:09 AM, Pavel Machek wrote:
> > Hi!
> >
> >> @@ -35,6 +37,7 @@ led-controller@2d {
> >> led@0 {
> >> reg = <0>;
> >> label = "white:display_cluster";
> >> + linux,default-trigger = "backlight";
> >> };
> >> }
> >
> > What is "display_cluster"? Is it display backlight?
> >
>
> This device can be configured to drive all 4 LED strings in display mode
> so that all 4 strings have the same brightness controlled either through PWM or
> through the brightness register
>
> or
>
> As cluster string where the brightness of individual strings or clustered strings
> can be controlled via independent brightness control registers. I am currently working
> on adding this support to the driver.
Ok; but I guess I'd like to keep this implementation detail away from
kernel, and just expose as display:white:backlight or something like that.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: chosen: Document linux,initrd-{start,end}
From: Rob Herring @ 2017-12-15 21:01 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland, AKASHI Takahiro,
Ard Biesheuvel, Kees Cook, James Morse, Frank Rowand,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171209153305.11012-1-j.neuschaefer-hi6Y0CQ0nG0@public.gmane.org>
On Sat, Dec 09, 2017 at 04:33:02PM +0100, Jonathan Neuschäfer wrote:
> These properties have been in use for a very long time (at least since
> 2005), but were never documented in chosen.txt.
>
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer-hi6Y0CQ0nG0@public.gmane.org>
> ---
> Documentation/devicetree/bindings/chosen.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
Applied.
I'm inclined to say to document these in the DT spec, but I'm assuming
there was some reason why they weren't put into the spec (ePAPR at the
time) originally.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] dt-bindings: mailbox: ti,message-manager: Fix interrupt name error
From: Rob Herring @ 2017-12-15 21:03 UTC (permalink / raw)
To: Nishanth Menon
Cc: Marco Franchi, Mark Rutland, Jassi Brar,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171209193528.29491-1-nm-l0cyMroinI0@public.gmane.org>
On Sat, Dec 09, 2017 at 01:35:28PM -0600, Nishanth Menon wrote:
> Message Manager's mailbox interrupts are queue based and not proxy
> specific. The interrupt names are wrong in the binding, however
> correctly reflected in the example provided. Remove the relation
> to proxy ID in the documentation of binding. Existing device tree
> descriptions follow the correct conventions already and documentation
> update has been missed.
>
> Signed-off-by: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mailbox/ti,message-manager.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: Add Infineon TLV493D-A1B6
From: Rob Herring @ 2017-12-15 21:42 UTC (permalink / raw)
To: Andreas Färber
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Marius Tarcatu, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20171209232507.18594-2-afaerber-l3A5Bk7waGM@public.gmane.org>
On Sun, Dec 10, 2017 at 12:25:06AM +0100, Andreas Färber wrote:
> The Infineon TLV493D-A1B6 is an I2C-based 3D Magnetic Sensor.
>
> Cc: Marius Tarcatu <marius.tarcatu-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> ---
> Documentation/devicetree/bindings/trivial-devices.txt | 1 +
> 1 file changed, 1 insertion(+)
I take trivial-devices.txt changes to avoid any conflicts, so I've
applied.
Rob
^ permalink raw reply
* Re: [PATCH net-next 1/2 v8] net: ethernet: Add DT bindings for the Gemini ethernet
From: Rob Herring @ 2017-12-15 21:43 UTC (permalink / raw)
To: Linus Walleij
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David S . Miller,
Michał Mirosław, Janos Laube, Paulius Zaleckas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Hans Ulli Kroll, Florian Fainelli,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tobias Waldvogel
In-Reply-To: <20171210224558.27122-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Sun, Dec 10, 2017 at 11:45:57PM +0100, Linus Walleij wrote:
> This adds the device tree bindings for the Gemini ethernet
> controller. It is pretty straight-forward, using standard
> bindings and modelling the two child ports as child devices
> under the parent ethernet controller device.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Tobias Waldvogel <tobias.waldvogel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Michał Mirosław <mirq-linux-CoA6ZxLDdyEEUmgCuDUIdw@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> ChangeLog v7->v8:
> - Use ethernet-port@0 and ethernet-port@1 with unit names
> and following OF graph requirements.
> ---
> .../bindings/net/cortina,gemini-ethernet.txt | 92 ++++++++++++++++++++++
> 1 file changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] arm: kirkwood: dts: Use lower case for bindings notation
From: Andrew Lunn @ 2017-12-15 21:43 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Rob Herring, Jason Cooper, Gregory Clement, Sebastian Hesselbarth,
Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215170711.8212-1-malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
On Fri, Dec 15, 2017 at 06:07:11PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files using lower case to fix the following dtc warnings:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> Suggested-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
Thanks for fixing up the commit message.
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
--
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] dt-bindings: net: wireless: Add sg parameters dts parsing
From: Rob Herring @ 2017-12-15 21:46 UTC (permalink / raw)
To: Arend van Spriel, Chi-Hsien Lin
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, brcm80211-dev-list,
brcm80211-dev-list.pdl-dY08KVG/lbpWk0Htik3J/w, Kalle Valo
In-Reply-To: <5A2E5606.8010707-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Mon, Dec 11, 2017 at 10:55:18AM +0100, Arend van Spriel wrote:
> On 12/11/2017 9:11 AM, Chi-Hsien Lin wrote:
> > broken_sg_support, sd_head_align, and sd_sgentry_align are used in
> > brcmfmac code but not configurable in dts file. Add the parsing logic.
> > Now they can be configured like below in dts:
> > brcm,broken_sg_support;
> > brcm,sd_head_align = <4>;
> > brcm,sd_sgentry_align = <4>;
> >
> > Signed-off-by: Chi-hsien Lin <chi-hsien.lin-+wT8y+m8/X5BDgjK7y7TUQ@public.gmane.org>
> > ---
> > .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > index 86602f2..4d42f0d 100644
> > --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > @@ -17,6 +17,11 @@ Optional properties:
> > When not specified the device will use in-band SDIO interrupts.
> > - interrupt-names : name of the out-of-band interrupt, which must be set
> > to "host-wake".
> > + - broken_sg_support : flag for broken sg list support of SDIO host controller.
> > + Set this to true if the SDIO host controller has higher align
> > + requirement than 32 bytes for each scatterlist item.
>
> In DT context, this does not characterize the device but as described it is
> about the SDIO host controller. I think the same applies to the properties
> below, but not entirely sure about that.
Yes. However, all of this should be implied by the host controller's
compatible property.
For future reference, don't use '_' in property names either.
Rob
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: pinctrl: Add st,stm32f769-pinctrl compatible to stm32-pinctrl
From: Rob Herring @ 2017-12-15 21:47 UTC (permalink / raw)
To: Alexandre Torgue
Cc: Maxime Coquelin, Linus Walleij, Mark Rutland, Jonathan Corbet,
Russell King, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512982475-32661-2-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
On Mon, Dec 11, 2017 at 09:54:31AM +0100, Alexandre Torgue wrote:
> Add new compatible for stm32f769 MCU.
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: bcm2836-l1-intc: add interrupt polarity support
From: Eric Anholt @ 2017-12-15 21:53 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Florian Fainelli,
Scott Branden, Rob Herring, Mark Rutland
Cc: Russell King, phil-FnsA7b+Nu9XbIbC87yuRow,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Stefan Wahren
In-Reply-To: <1513024752-11246-2-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org> writes:
> This increases the interrupt cells for the 1st level interrupt controller
> binding in order to describe the polarity like on the other ARM platforms.
>
> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
I'm happy with this. Any DT maintainer concerns?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: rtc: add bindings for i.MX53 SRTC
From: Rob Herring @ 2017-12-15 21:58 UTC (permalink / raw)
To: Patrick Brünn
Cc: linux-kernel-dev, Shawn Guo, Sascha Hauer, Alessandro Zummo,
Alexandre Belloni, Patrick Bruenn, Mark Rutland,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Fabio Estevam, Juergen Borleis, Noel Vellemans,
Russell King,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <3BB206AB2B1BD448954845CE6FF69A8E01CB53233C@NT-Mail07.beckhoff.com>
On Mon, Dec 11, 2017 at 1:08 AM, Patrick Brünn <P.Bruenn@beckhoff.com> wrote:
>>From: Rob Herring [mailto:robh@kernel.org]
>>Sent: Mittwoch, 6. Dezember 2017 22:55
>>On Tue, Dec 05, 2017 at 03:06:42PM +0100, linux-kernel-dev@beckhoff.com
>>wrote:
>>> From: Patrick Bruenn <p.bruenn@beckhoff.com>
>>>
>>> +++ b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
>>> @@ -0,0 +1,17 @@
>>> +* i.MX53 Real Time Clock controller
>>> +
>>> +Required properties:
>>> +- compatible: should be: "fsl,imx53-rtc"
>>> +- reg: physical base address of the controller and length of memory
>>mapped
>>> + region.
>>> +- clocks: should contain the phandle for the rtc clock
>>
>>Shouldn't there be more than 1 here. From what I remember, the ipg clock
>>and the 32k clock?
> Yes, you are right. But if I am reading the original Freescale driver and the
> reference manual correctly, the second clock is always active.
> Section "72.3.1.1 Clocks" from the reference manual [1] reads:
> "SRTC runs on two clock sources, high frequency peripherals clock and low frequency
> timers clock. The high frequency peripheral IP clock is used by the SRTC peripheral bus
> interface, control and status registers. The low frequency 32.768 kHz clock is the
> always-active clock used by the SRTC timers..."
>
> That's why I would only include one clock . Should I change this?
Some chips supported 32.0kHz and 32.768kHz low freq clocks, so you'd
need to be able to query what the frequency is even if you don't need
to enable the clock, but maybe that may be gone in MX53. I don't
remember.
>>> +- interrupts: rtc alarm interrupt
>>> +
>>> +Example:
>>> +
>>> +srtc@53fa4000 {
>>
>>rtc@...
>>
> The rtc for which this series adds support is embedded within a function block called
> "Secure Real Time Clock". This driver doesn't utilize all of the hardware features by
> now. But maybe someone else wants to extend the functionalities, later.
> For that possibility I wanted to name the node "srtc". Should I still change this?
>
> I believe you have a much better understanding of what should be done here. I don't
> want to argue with you, just thought you might not had that information. So if I am
> wrong just tell me and I will change it without further "complaining".
Node names should be generic for the class of h/w they are. So yes, it
should be "rtc".
Rob
^ permalink raw reply
* Re: [PATCH v2 07/13] dt-bindings: power: reset: Document ocelot-reset binding
From: Alexandre Belloni @ 2017-12-15 22:07 UTC (permalink / raw)
To: Rob Herring
Cc: Ralf Baechle, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sebastian Reichel,
linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215202332.bn47da3fpkynusno@rob-hp-laptop>
On 15/12/2017 at 14:23:32 -0600, Rob Herring wrote:
> On Fri, Dec 08, 2017 at 04:46:12PM +0100, Alexandre Belloni wrote:
> > Add binding documentation for the Microsemi Ocelot reset block.
> >
> > Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Signed-off-by: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > .../devicetree/bindings/power/reset/ocelot-reset.txt | 17 +++++++++++++++++
> > 1 file changed, 17 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> >
> > diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> > new file mode 100644
> > index 000000000000..1bcf276b04cb
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> > @@ -0,0 +1,17 @@
> > +Microsemi Ocelot reset controller
> > +
> > +The DEVCPU_GCB:CHIP_REGS have a SOFT_RST register that can be used to reset the
> > +SoC MIPS core.
> > +
> > +Required Properties:
> > + - compatible: "mscc,ocelot-chip-reset"
> > +
> > +Example:
> > + syscon@71070000 {
> > + compatible = "mscc,ocelot-chip-regs", "simple-mfd", "syscon";
> > + reg = <0x71070000 0x1c>;
> > +
> > + reset {
> > + compatible = "mscc,ocelot-chip-reset";
>
> Why do you need a subnode here other than as a way to instantiate a
> driver? Can you describe the SOFT_RST register in reg property here
> (without having overlapping regions)?
You mean like:
reset@7107001c {
compatible = "mscc,ocelot-chip-reset";
reg = <0x7107001c 0x4>;
};
I guess that could work.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 1/3] media: V3s: Add support for Allwinner CSI.
From: Maxime Ripard @ 2017-12-15 22:14 UTC (permalink / raw)
To: Yong
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Greg Kroah-Hartman, David S. Miller, Hans Verkuil, Arnd Bergmann,
Hugues Fruchet, Yannick Fertre, Philipp Zabel, Benoit Parrot,
Benjamin Gaignard, Jean-Christophe Trotin,
Ramesh Shanmugasundaram, Minghsiu Tsai, Krzysztof Kozlowski,
Robert Jarzmik, linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215190140.d4df71b202b9803baa6a1e10-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
Hi,
On Fri, Dec 15, 2017 at 07:01:40PM +0800, Yong wrote:
> Hi Maxime,
>
> On Fri, 15 Dec 2017 11:50:47 +0100
> Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > Hi Yong,
> >
> > On Mon, Dec 04, 2017 at 05:45:11PM +0800, Yong wrote:
> > > I just noticed that you are using the second iteration?
> > > Have you received my third iteration?
> >
> > Sorry for the late reply, and for not coming back to you yet about
> > that test. No, this is still in your v2. I've definitely received your
> > v3, I just didn't have time to update to it yet.
> >
> > But don't worry, my mail was mostly to know if you had tested that
> > setup on your side to try to nail down the issue on my end, not really
> > a review or comment that would prevent your patch from going in.
>
> I mean,
> The v2 exactly has a bug which may cause the CSI writing frame to
> a wrong memory address.
Ah, sorry I misunderstood you then. I'll definitely test your v3..
> BTW, should I send a new version. I have made some improve sine v3.
.. or your v4 :)
Yes, please send a new version.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH net-next v5 1/4] phylib: Add device reset delay support
From: Rob Herring @ 2017-12-15 22:17 UTC (permalink / raw)
To: Richard Leitner
Cc: mark.rutland, fugang.duan, andrew, f.fainelli, frowand.list,
davem, geert+renesas, sergei.shtylyov, baruch, david.wu, lukma,
netdev, devicetree, linux-kernel, richard.leitner
In-Reply-To: <20171211121700.10200-2-dev@g0hl1n.net>
On Mon, Dec 11, 2017 at 01:16:57PM +0100, Richard Leitner wrote:
> From: Richard Leitner <richard.leitner@skidata.com>
>
> Some PHYs need a minimum time after the reset gpio was asserted and/or
> deasserted. To ensure we meet these timing requirements add two new
> optional devicetree parameters for the phy: reset-delay-us and
> reset-post-delay-us.
>
> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Documentation/devicetree/bindings/net/phy.txt | 10 ++++++++++
> drivers/net/phy/mdio_device.c | 13 +++++++++++--
> drivers/of/of_mdio.c | 4 ++++
> include/linux/mdio.h | 2 ++
> 4 files changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
> index c05479f5ac7c..72860ce7f610 100644
> --- a/Documentation/devicetree/bindings/net/phy.txt
> +++ b/Documentation/devicetree/bindings/net/phy.txt
> @@ -55,6 +55,12 @@ Optional Properties:
>
> - reset-gpios: The GPIO phandle and specifier for the PHY reset signal.
>
> +- reset-delay-us: Delay after the reset was asserted in microseconds.
> + If this property is missing the delay will be skipped.
> +
> +- reset-post-delay-us: Delay after the reset was deasserted in microseconds.
> + If this property is missing the delay will be skipped.
I think these names could be clearer as to exactly what they mean.
Looking at existing properties with "reset-delay" there's a mixture of
definitions whether it is the assert time or the time after deassert.
So I'd call these "reset-assert-us" and "reset-deassert-us".
Rob
^ 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