* Re: usb:xhci: support disable usb2 LPM Remote Wakeup
From: Rob Herring @ 2016-12-09 21:36 UTC (permalink / raw)
To: Thang Q. Nguyen
Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Mathias Nyman,
Greg Kroah-Hartman, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Phong Vo, Loc Ho, Vu Nguyen,
patches-qTEPVZfXA3Y
In-Reply-To: <1480855321-5047-1-git-send-email-tqnguyen-qTEPVZfXA3Y@public.gmane.org>
On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote:
> From: Thang Nguyen <tqnguyen-qTEPVZfXA3Y@public.gmane.org>
>
> As per USB 2.0 link power management addendum ECN, table 1-2, page 4,
> device or host initiated via resume signaling; device-initiated resumes
> can be optionally enabled/disabled by software. This patch adds support
> to control enabling the USB2 RWE feature via DT/ACPI attribute.
>
> Signed-off-by: Vu Nguyen <vnguyen-qTEPVZfXA3Y@public.gmane.org>
> Signed-off-by: Thang Nguyen <tqnguyen-qTEPVZfXA3Y@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
> drivers/usb/host/xhci-plat.c | 3 +++
> drivers/usb/host/xhci.c | 5 ++++-
> drivers/usb/host/xhci.h | 1 +
> 4 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> index 966885c..9b4cd14 100644
> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> @@ -25,6 +25,7 @@ Required properties:
>
> Optional properties:
> - clocks: reference to a clock
> + - usb2-rwe-disable: disable USB2 LPM Remote Wakeup capable
Remote wakeup has been around since USB 1.0 days. Does this need to be
USB2 or XHCI specific?
> - usb3-lpm-capable: determines if platform is USB3 LPM capable
>
> Example:
--
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 net-next v3 1/2] net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
From: Rob Herring @ 2016-12-09 21:31 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
mark.rutland-5wv7dgnIgG8, carlo-KA+7E9HrN00dnm+yROfE0A,
khilman-rdvid1DuHRBWk0Htik3J/w, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161202233238.17561-2-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On Sat, Dec 03, 2016 at 12:32:37AM +0100, Martin Blumenstingl wrote:
> This allows configuring the RGMII TX clock delay. The RGMII clock is
> generated by underlying hardware of the the Meson 8b / GXBB DWMAC glue.
> The configuration depends on the actual hardware (no delay may be
> needed due to the design of the actual circuit, the PHY might add this
> delay, etc.).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Tested-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/meson-dwmac.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Michael Turquette @ 2016-12-09 21:28 UTC (permalink / raw)
To: Tony Lindgren
Cc: devicetree, Stephen Boyd, Tero Kristo, Rob Herring, linux-omap,
linux-clk, linux-arm-kernel
In-Reply-To: <20161209204015.GL4920@atomide.com>
Quoting Tony Lindgren (2016-12-09 12:40:16)
> * Michael Turquette <mturquette@baylibre.com> [161209 12:02]:
> > Quoting Tony Lindgren (2016-12-05 07:25:34)
> > > * Tero Kristo <t-kristo@ti.com> [161205 02:09]:
> ...
> <snip>
>
> > I had a recent conversation with Kevin Hilman about a related issue
> > (we were not discussing this thread or this series) and we both agreed
> > that most drivers don't even need to managed their clocks directly, so
> > much as they need to manage their on/off resources. Clocks are just one
> > part of that, and if we can hide that stuff inside of an attached genpd
> > then it would be better than having the driver manage clocks explicitly.
> >
> > Obviously some devices such as audio codec or uart will need to manage
> > clocks directly, but this is mostly the exception, not the rule.
>
> Yes. And we do that already for clkctrl clocks via PM runtime where
> hwmod manages them. Tero's series still has hwmod manage the clocks,
> but the clock register handling is moved to live under drivers/clock.
>
> > > > > > There is certainly no API for that in the clock framework, but for genpd
> > > > > > your runtime_pm_get() callback for clkdm_A could call runtime_pm_get
> > > > > > against clkdm_B, which would satisfy the requirement. See section
> > > > > > 3.1.1.1.7 Clock Domain Dependency in the OMAP4 TRM, version AB.
> > > >
> > > > For static dependencies the apis genpd_add/remove_subdomain could probably
> > > > be used.
> > > >
> > > > > To me it seems the API is just clk_get() :) Do you have some
> > > > > specific example we can use to check? My guess is that the
> > > > > TRM "Clock Domain Dependency" is just the usual parent child
> > > > > relationship between clocks that are the clockdomains..
> >
> > clk_get() only fetches a pointer to the clk. I guess you mean
> > clk_prepare_enable() to actually increment the use count?
>
> Right, with clocks that's all we should need to do :)
>
> > If we used the clk framework here is that it would look something like
> > this:
> >
> > clk_enable(clk_a)
> > -> .enable(clk_a_hw)
> > -> clk_enable(clk_b)
> >
> > However, clk_a and clk_b do not have a parent-child relationship in the
> > clock tree. This is purely a functional relationship between IP blocks.
> > Modeling this sort of thing in the clk framework would be wrong, and
> > genpd is a much better place to establish these arbitrary relationships.
>
> Hmm yes, and I don't mean the clock framework should do anything more
> complex beyond what it already does.
>
> We just want to represent the clocks as clocks, then have the
> interconnect code manage those clocks. That's currently hwmod, eventually
> it will be genpd.
>
> > > > > If there is something more magical there certainly that should
> > > > > be considered though.
> > > >
> > > > The hwmods could be transformed to individual genpds also I guess. On DT
> > > > level though, we would still need a clock pointer to the main clock and a
> > > > genpd pointer in addition to that.
> > >
> > > Hmm a genpd pointer to where exactly? AFAIK each interconnect
> > > instance should be a genpd provider, and the individual interconnect
> > > target modules should be consumers for that genpd.
> >
> > I was thinking that the clock domains would be modeled as genpd objects
> > with the interconnect target modules attached as struct devices.
>
> I think clock domains should be just clocks, then we let the interconnect
> code and eventually genpd manage them.
>
> > > > Tony, any thoughts on that? Would this break up the plans for the
> > > > interconnect completely?
> > >
> > > Does using genpd for clockdomains cause issues for using genpd for
> > > interconnect instances and the target modules?
> >
> > Can they be the same object in Linux? If there is a one-to-one mapping
> > between clock domains and the interconnect port then maybe you can just
> > model them together.
>
> I'm thinking that it should be the interconnect code implementing
> genpd, and use clk_request_enable().
>
> > > The thing I'd be worried about there is that the clockdomains and
> > > their child clocks are just devices sitting on the interconnect,
> > > so we could easily end up with genpd modeling something that does
> > > not represent the hardware.
> > >
> > > For example, on 4430 we have:
> > >
> > > l4_cfg interconnect
> > > ...
> > > segment@0
> > > ...
> > > target_module@4000
> > > cm1: cm1@0
> >
> > How about:
> >
> > l4_cfg interconnect
> > ...
> > segment@0
> > ...
> > cm1@4000
> > module: foo_module@0
>
> That's the wrong way around from hardware point of view. There's
> a generic interconnect wrapper module with it's own registers,
> then cm1 (and possibly other devices) are children of that target
> module.
>
> > I don't know much about the segments. Do they map one-to-one with the
> > clock domains?
>
> I need to check, it's been a while, but I recall some interconnects
> are partioned to segments based on voltages or clocks.
>
> > If my quick-and-dirty DT above makes sense, then the target modules
> > (e.g. io controller) would not get clocks anymore, but just
> > pm_runtime_get(). The genpd backing object would call clk_enable/disable
> > as needed.
>
> Yeah that's what we already have with hwmod and PM runtime for the
> clockctrl register. But hwmod currently directly manages the clkctrl
> register, we just want to move that part to be a clock driver.
>
> The children of the interconnect target modules just need to use
> PM runtime, but the interconnect target module driver needs to know
> it's clkctrl clock.
OK, that sounds good to me but I'm not quite sure about the difference
between "children of interconnect target modules" versus just the
"interconnect target module".
Can you give an example on each? I just want to understand for my own
curiosity.
>
> > If fine grained control of a clock is needed (e.g. for clk_set_rate)
> > then the driver can still clk_get it. Whether or not the clockdomain
> > provides that clock or if it comes from the clock generator (e.g. cm1,
> > cm2, prm, etc) isn't as important to me, but I prefer for the
> > clockdomain to not be a clock provider if possible.
>
> Yeah I totally agree with that, and that's already what we mostly
> have.
>
> > > I don't at least yet
> > > follow what we need to do with the clockdomains with genpd :)
> >
> > Use the clockdomain genpd to call clk_enable/disable under the hood.
> > Don't use them as clock providers to the target modules. Clockdomain
> > genpds would be the clock consumers.
>
> I don't think the clockdomain should be a genpd provider because
> that creates a genpd network of dependencies instead of a tree
> structure. If we end up setting the clockdomains with genpd, then
> only the other clockdomains should use them, but I don't know how
> we ever keep drivers from directly tinkering with them..
Genpd is set up as an arbitrary graph, not strictly a tree, so these
types of dependencies should be OK.
>
> IMO, the clockdomain clock driver should just provides clocks, then
> we can have the interconnect target module driver deal with the
> clockdomain dependencies.
>
> > > Wouldn't just doing clk_get() from one clockdomain clock to
> > > another clockdomain clock (or it's output) be enough to
> > > represent the clockdomain dependencies?
> >
> > s/clk_get/clk_prepare_enable/
> >
> > Yes, but you're stuffing functional dependencies into the clock tree,
> > which sucks. genpd was created to model these arbitrary dependencies.
>
> Well let's not stuff anything beyond clock framework to the
> clockdomain clock drivers. We already have the clockdomain
> dependencies handled by the interconnect code (hwmod), and there
> should be no problem moving those to be handled by genpd and the
> interconnect target driver instances.
>
> Care to take another look at Tero's patches with the assumption
> that the clockdomain clocks stay just as a clocks?
Sure.
Regards,
Mike
>
> Regards,
>
> Tony
^ permalink raw reply
* Re: [PATCH v2 1/3] crypto: brcm: DT documentation for Broadcom SPU driver
From: Rob Herring @ 2016-12-09 21:26 UTC (permalink / raw)
To: Rob Rice
Cc: Herbert Xu, David S. Miller, Mark Rutland,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ray Jui, Scott Branden,
Jon Mason, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
Catalin Marinas, Will Deacon,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Steve Lin
In-Reply-To: <1480714499-1476-2-git-send-email-rob.rice-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Fri, Dec 02, 2016 at 04:34:57PM -0500, Rob Rice wrote:
> Device tree documentation for Broadcom Secure Processing Unit
> (SPU) crypto driver.
>
> Signed-off-by: Steve Lin <steven.lin1-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Rob Rice <rob.rice-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/crypto/brcm,spu-crypto.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
>
> diff --git a/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
> new file mode 100644
> index 0000000..e5fe942
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
> @@ -0,0 +1,25 @@
> +The Broadcom Secure Processing Unit (SPU) driver supports symmetric
Bindings describe h/w, not drivers.
> +cryptographic offload for Broadcom SoCs with SPU hardware. A SoC may have
> +multiple SPU hardware blocks.
> +
> +Required properties:
> +- compatible : Should be "brcm,spum-crypto" for devices with SPU-M hardware
Additionally, you should have SoC specific compatible here.
> + (e.g., Northstar2) or "brcm,spum-nsp-crypto" for the Northstar Plus variant
> + of the SPU-M hardware.
> +
> +- reg: Should contain SPU registers location and length.
> +- mboxes: A list of mailbox channels to be used by the kernel driver. Mailbox
> +channels correspond to DMA rings on the device.
What determines the mbox assignment?
Needs to specify how many.
> +
> +Example:
> + spu-crypto@612d0000 {
Just crypto@...
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] MIPS: NI 169445 board support
From: Rob Herring @ 2016-12-09 21:18 UTC (permalink / raw)
To: Nathan Sullivan
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, mark.rutland-5wv7dgnIgG8,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480693329-22265-1-git-send-email-nathan.sullivan-acOepvfBmUk@public.gmane.org>
On Fri, Dec 02, 2016 at 09:42:09AM -0600, Nathan Sullivan wrote:
> Support the National Instruments 169445 board.
>
> Signed-off-by: Nathan Sullivan <nathan.sullivan-acOepvfBmUk@public.gmane.org>
> ---
> "gpio: mmio: add support for NI 169445 NAND GPIO" and
> "devicetree: add vendor prefix for National Instruments" are required for the
> NAND on this board to work.
These should have been a series, but I already applied the first one.
>
> Documentation/devicetree/bindings/mips/ni.txt | 7 ++
> arch/mips/Kbuild.platforms | 1 +
> arch/mips/Kconfig | 26 ++++++
> arch/mips/boot/dts/Makefile | 1 +
> arch/mips/boot/dts/ni/169445.dts | 99 +++++++++++++++++++++
> arch/mips/boot/dts/ni/Makefile | 9 ++
> arch/mips/configs/ni169445_defconfig | 120 ++++++++++++++++++++++++++
> arch/mips/ni169445/169445-console.c | 38 ++++++++
> arch/mips/ni169445/169445-init.c | 39 +++++++++
> arch/mips/ni169445/169445-int.c | 34 ++++++++
> arch/mips/ni169445/169445-setup.c | 58 +++++++++++++
> arch/mips/ni169445/169445-time.c | 35 ++++++++
> arch/mips/ni169445/Makefile | 9 ++
> arch/mips/ni169445/Platform | 6 ++
> 14 files changed, 482 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mips/ni.txt
> create mode 100644 arch/mips/boot/dts/ni/169445.dts
> create mode 100644 arch/mips/boot/dts/ni/Makefile
> create mode 100644 arch/mips/configs/ni169445_defconfig
> create mode 100644 arch/mips/ni169445/169445-console.c
> create mode 100644 arch/mips/ni169445/169445-init.c
> create mode 100644 arch/mips/ni169445/169445-int.c
> create mode 100644 arch/mips/ni169445/169445-setup.c
> create mode 100644 arch/mips/ni169445/169445-time.c
> create mode 100644 arch/mips/ni169445/Makefile
> create mode 100644 arch/mips/ni169445/Platform
>
> diff --git a/Documentation/devicetree/bindings/mips/ni.txt b/Documentation/devicetree/bindings/mips/ni.txt
> new file mode 100644
> index 0000000..722bf2d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mips/ni.txt
> @@ -0,0 +1,7 @@
> +National Instruments MIPS platforms
> +
> +required root node properties:
> + - compatible: must be "ni,169445"
> +
> +CPU Nodes
> + - compatible: must be "mti,mips14KEc"
> diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
> index f5f1bdb..f2d7b5c 100644
> --- a/arch/mips/Kbuild.platforms
> +++ b/arch/mips/Kbuild.platforms
> @@ -20,6 +20,7 @@ platforms += loongson32
> platforms += loongson64
> platforms += mti-malta
> platforms += netlogic
> +platforms += ni169445
> platforms += paravirt
> platforms += pic32
> platforms += pistachio
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index b3c5bde..d24d11f 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -574,6 +574,32 @@ config NXP_STB225
> help
> Support for NXP Semiconductors STB225 Development Board.
>
> +config NI_169445
> + bool "NI 169445 board"
> + select ARCH_WANT_OPTIONAL_GPIOLIB
> + select BOOT_ELF32
> + select BOOT_RAW
> + select BUILTIN_DTB
> + select CEVT_R4K
> + select CSRC_R4K
> + select CPU_MIPSR2_IRQ_VI
> + select CPU_MIPSR2_IRQ_EI
> + select DMA_NONCOHERENT
> + select IRQ_MIPS_CPU
> + select LIBFDT
> + select MIPS_MSC
> + select SYS_HAS_CPU_MIPS32_R1
> + select SYS_HAS_CPU_MIPS32_R2
> + select SYS_HAS_EARLY_PRINTK
> + select SYS_SUPPORTS_32BIT_KERNEL
> + select SYS_SUPPORTS_LITTLE_ENDIAN
> + select USE_OF
> + select COMMON_CLK
> + help
> + This enables support for the National Instruments 169445A
> + board.
> +
> +
> config PMC_MSP
> bool "PMC-Sierra MSP chipsets"
> select CEVT_R4K
> diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
> index fc7a0a9..65a0ad8 100644
> --- a/arch/mips/boot/dts/Makefile
> +++ b/arch/mips/boot/dts/Makefile
> @@ -3,6 +3,7 @@ dts-dirs += cavium-octeon
> dts-dirs += ingenic
> dts-dirs += lantiq
> dts-dirs += mti
> +dts-dirs += ni
> dts-dirs += netlogic
> dts-dirs += pic32
> dts-dirs += qca
> diff --git a/arch/mips/boot/dts/ni/169445.dts b/arch/mips/boot/dts/ni/169445.dts
> new file mode 100644
> index 0000000..a2b49f9
> --- /dev/null
> +++ b/arch/mips/boot/dts/ni/169445.dts
> @@ -0,0 +1,99 @@
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "ni,169445";
> +
> + cpus {
> + mips-hpt-frequency = <25000000>;
> +
> + cpu@0 {
> + compatible = "mti,mips14KEc";
> + };
> + };
> +
> + memory {
memory@0
> + device_type = "memory";
> + reg = <0x0 0x08000000>;
> + };
> +
> + clocks {
> + baseclk: baseclock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <50000000>;
> + };
> + };
> +
> + cpu_intc: cpu_intc {
> + #address-cells = <0>;
> + compatible = "mti,cpu-interrupt-controller";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> +
> + ahb@0 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
If everything is under 0x1f3xxxxx, then add in the ranges here (and the
unit address).
> +
> + gpio1: nand-gpio-out@1f300010 {
As in the binding example: gpio-controller@...
> + compatible = "ni,169445-nand-gpio";
> + reg = <0x1f300010 0x4>;
> + reg-names = "dat";
> + gpio-controller;
> + #gpio-cells = <2>;
> + ngpios = <5>;
> + };
> +
> + gpio2: nand-gpio-in@1f300014 {
ditto
> + compatible = "ni,169445-nand-gpio";
> + reg = <0x1f300014 0x4>;
> + reg-names = "dat";
> + gpio-controller;
> + #gpio-cells = <2>;
> + ngpios = <1>;
> + };
> +
> + nand@1f300000 {
> + compatible = "gpio-control-nand";
> + nand-on-flash-bbt;
> + nand-ecc-mode = "soft_bch";
> + nand-ecc-step-size = <512>;
> + nand-ecc-strength = <4>;
> + reg = <0x1f300000 4>;
> + gpios = <&gpio2 0 0>, /* rdy */
> + <&gpio1 1 0>, /* nce */
> + <&gpio1 2 0>, /* ale */
> + <&gpio1 3 0>, /* cle */
> + <&gpio1 4 0>; /* nwp */
> + };
> +
> + serial@1f380000 {
> + compatible = "ns16550a";
> + reg = <0x1f380000 0x1000>;
> + interrupt-parent = <&cpu_intc>;
> + interrupts = <6>;
> + clocks = <&baseclk>;
> + reg-shift = <0>;
> + };
> +
> + ethernet@1f340000 {
> + compatible = "snps,dwc-qos-ethernet-4.10";
> + interrupt-parent = <&cpu_intc>;
> + interrupts = <5>;
> + reg = <0x1f340000 0x2000>;
> + clock-names = "apb_pclk", "phy_ref_clk";
> + clocks = <&baseclk>, <&baseclk>;
> +
> + phy-mode = "rgmii";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> +};
[...]
> diff --git a/arch/mips/ni169445/169445-setup.c b/arch/mips/ni169445/169445-setup.c
> new file mode 100644
> index 0000000..80a5c91
> --- /dev/null
> +++ b/arch/mips/ni169445/169445-setup.c
> @@ -0,0 +1,58 @@
> +/* Copyright 2016 National Instruments Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option)
> + * any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + */
> +#include <linux/init.h>
> +#include <linux/clk-provider.h>
> +#include <linux/libfdt.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_fdt.h>
> +
> +#include <asm/prom.h>
> +#include <asm/fw/fw.h>
> +
> +#include <asm/mips-boards/generic.h>
> +
> +const char *get_system_type(void)
> +{
> + return "NI 169445 FPGA";
Perhaps this should come from model property. There's a patch in flight
to add a function to get machine name.
> +}
> +
> +void __init plat_mem_setup(void)
> +{
> + /*
> + * Load the builtin devicetree. This causes the chosen node to be
> + * parsed resulting in our memory appearing
> + */
> + __dt_setup_arch(__dtb_start);
> +}
> +
> +void __init device_tree_init(void)
> +{
> + if (!initial_boot_params)
> + return;
> +
> + unflatten_and_copy_device_tree();
> +}
> +
> +static int __init customize_machine(void)
> +{
> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
This should happen by default now.
> + return 0;
> +}
> +arch_initcall(customize_machine);
--
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] gpio: mmio: add support for NI 169445 NAND GPIO
From: Rob Herring @ 2016-12-09 21:06 UTC (permalink / raw)
To: Nathan Sullivan
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480693022-22110-1-git-send-email-nathan.sullivan-acOepvfBmUk@public.gmane.org>
On Fri, Dec 02, 2016 at 09:37:02AM -0600, Nathan Sullivan wrote:
> The GPIO-based NAND controller on National Instruments 169445 hardware
> exposes a set of simple lines for the control signals.
>
> Signed-off-by: Nathan Sullivan <nathan.sullivan-acOepvfBmUk@public.gmane.org>
> ---
> "devicetree: add vendor prefix for National Instruments" added the ni vendor prefix.
>
> This patch is needed for "MIPS: NI 169445 board support", so that GPIO NAND can work.
>
> .../bindings/gpio/ni,169445-nand-gpio.txt | 36 ++++++++++++++++++++++
> drivers/gpio/gpio-mmio.c | 1 +
> 2 files changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt b/Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
> new file mode 100644
> index 0000000..ca2c14f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
> @@ -0,0 +1,36 @@
> +Bindings for the National Instruments 169445 GPIO NAND controller
> +
> +The 169445 GPIO NAND controller has two memory mapped GPIO registers, one
> +for input (the ready signal) and one for output (control signals). It is
> +intended to be used with the GPIO NAND driver.
> +
> +Required properties:
> + - compatible: should be "ni,169445-nand-gpio"
> + - reg-names: must contain
> + "dat" - data register
-names with a single entry is pointless.
> + - reg: address + size pairs describing the GPIO register sets;
> + order must correspond with the order of entries in reg-names
> + - #gpio-cells: must be set to 2. The first cell is the pin number and
> + the second cell is used to specify the gpio polarity:
> + 0 = active high
> + 1 = active low
> + - gpio-controller: Marks the device node as a gpio controller.
> +
> +Examples:
> + gpio1: nand-gpio-out@1f300010 {
gpio-controller@...
> + compatible = "ni,169445-nand-gpio";
> + reg = <0x1f300010 0x4>;
> + reg-names = "dat";
> + gpio-controller;
> + #gpio-cells = <2>;
> + ngpios = <5>;
> + };
> +
> + gpio2: nand-gpio-in@1f300014 {
ditto
> + compatible = "ni,169445-nand-gpio";
> + reg = <0x1f300014 0x4>;
> + reg-names = "dat";
> + gpio-controller;
> + #gpio-cells = <2>;
> + ngpios = <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
* Re: [PATCH] devicetree: add vendor prefix for National Instruments
From: Rob Herring @ 2016-12-09 21:04 UTC (permalink / raw)
To: Nathan Sullivan
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480692708-22009-1-git-send-email-nathan.sullivan-acOepvfBmUk@public.gmane.org>
On Fri, Dec 02, 2016 at 09:31:48AM -0600, Nathan Sullivan wrote:
> Signed-off-by: Nathan Sullivan <nathan.sullivan-acOepvfBmUk@public.gmane.org>
> ---
> This is required by "gpio: mmio: add support for NI 169445 NAND GPIO"
>
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
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/3] nvmem: imx-ocotp: Add support for i.MX6UL
From: Rob Herring @ 2016-12-09 21:02 UTC (permalink / raw)
To: Daniel Schultz
Cc: srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1480689949-17957-1-git-send-email-d.schultz-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
On Fri, Dec 02, 2016 at 03:45:47PM +0100, Daniel Schultz wrote:
> This patch adds OCOTP support for the i.MX6UL SoC.
>
> Signed-off-by: Daniel Schultz <d.schultz-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 5 +++--
> drivers/nvmem/imx-ocotp.c | 1 +
> 2 files changed, 4 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH v2 5/7] drm/vc4: Document VEC DT binding
From: Rob Herring @ 2016-12-09 21:00 UTC (permalink / raw)
To: Boris Brezillon
Cc: David Airlie, Daniel Vetter,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Florian Fainelli,
Ray Jui, Scott Branden,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Stephen Warren,
Lee Jones, Eric Anholt,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1480686493-4813-6-git-send-email-boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Fri, Dec 02, 2016 at 02:48:11PM +0100, Boris Brezillon wrote:
> Document the DT binding for the VEC (Video EnCoder) IP.
>
> Signed-off-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Tony Lindgren @ 2016-12-09 20:40 UTC (permalink / raw)
To: Michael Turquette
Cc: Tero Kristo, Stephen Boyd, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring
In-Reply-To: <148131376868.16621.16082839810419290638@resonance>
* Michael Turquette <mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> [161209 12:02]:
> Quoting Tony Lindgren (2016-12-05 07:25:34)
> > * Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org> [161205 02:09]:
...
<snip>
> I had a recent conversation with Kevin Hilman about a related issue
> (we were not discussing this thread or this series) and we both agreed
> that most drivers don't even need to managed their clocks directly, so
> much as they need to manage their on/off resources. Clocks are just one
> part of that, and if we can hide that stuff inside of an attached genpd
> then it would be better than having the driver manage clocks explicitly.
>
> Obviously some devices such as audio codec or uart will need to manage
> clocks directly, but this is mostly the exception, not the rule.
Yes. And we do that already for clkctrl clocks via PM runtime where
hwmod manages them. Tero's series still has hwmod manage the clocks,
but the clock register handling is moved to live under drivers/clock.
> > > > > There is certainly no API for that in the clock framework, but for genpd
> > > > > your runtime_pm_get() callback for clkdm_A could call runtime_pm_get
> > > > > against clkdm_B, which would satisfy the requirement. See section
> > > > > 3.1.1.1.7 Clock Domain Dependency in the OMAP4 TRM, version AB.
> > >
> > > For static dependencies the apis genpd_add/remove_subdomain could probably
> > > be used.
> > >
> > > > To me it seems the API is just clk_get() :) Do you have some
> > > > specific example we can use to check? My guess is that the
> > > > TRM "Clock Domain Dependency" is just the usual parent child
> > > > relationship between clocks that are the clockdomains..
>
> clk_get() only fetches a pointer to the clk. I guess you mean
> clk_prepare_enable() to actually increment the use count?
Right, with clocks that's all we should need to do :)
> If we used the clk framework here is that it would look something like
> this:
>
> clk_enable(clk_a)
> -> .enable(clk_a_hw)
> -> clk_enable(clk_b)
>
> However, clk_a and clk_b do not have a parent-child relationship in the
> clock tree. This is purely a functional relationship between IP blocks.
> Modeling this sort of thing in the clk framework would be wrong, and
> genpd is a much better place to establish these arbitrary relationships.
Hmm yes, and I don't mean the clock framework should do anything more
complex beyond what it already does.
We just want to represent the clocks as clocks, then have the
interconnect code manage those clocks. That's currently hwmod, eventually
it will be genpd.
> > > > If there is something more magical there certainly that should
> > > > be considered though.
> > >
> > > The hwmods could be transformed to individual genpds also I guess. On DT
> > > level though, we would still need a clock pointer to the main clock and a
> > > genpd pointer in addition to that.
> >
> > Hmm a genpd pointer to where exactly? AFAIK each interconnect
> > instance should be a genpd provider, and the individual interconnect
> > target modules should be consumers for that genpd.
>
> I was thinking that the clock domains would be modeled as genpd objects
> with the interconnect target modules attached as struct devices.
I think clock domains should be just clocks, then we let the interconnect
code and eventually genpd manage them.
> > > Tony, any thoughts on that? Would this break up the plans for the
> > > interconnect completely?
> >
> > Does using genpd for clockdomains cause issues for using genpd for
> > interconnect instances and the target modules?
>
> Can they be the same object in Linux? If there is a one-to-one mapping
> between clock domains and the interconnect port then maybe you can just
> model them together.
I'm thinking that it should be the interconnect code implementing
genpd, and use clk_request_enable().
> > The thing I'd be worried about there is that the clockdomains and
> > their child clocks are just devices sitting on the interconnect,
> > so we could easily end up with genpd modeling something that does
> > not represent the hardware.
> >
> > For example, on 4430 we have:
> >
> > l4_cfg interconnect
> > ...
> > segment@0
> > ...
> > target_module@4000
> > cm1: cm1@0
>
> How about:
>
> l4_cfg interconnect
> ...
> segment@0
> ...
> cm1@4000
> module: foo_module@0
That's the wrong way around from hardware point of view. There's
a generic interconnect wrapper module with it's own registers,
then cm1 (and possibly other devices) are children of that target
module.
> I don't know much about the segments. Do they map one-to-one with the
> clock domains?
I need to check, it's been a while, but I recall some interconnects
are partioned to segments based on voltages or clocks.
> If my quick-and-dirty DT above makes sense, then the target modules
> (e.g. io controller) would not get clocks anymore, but just
> pm_runtime_get(). The genpd backing object would call clk_enable/disable
> as needed.
Yeah that's what we already have with hwmod and PM runtime for the
clockctrl register. But hwmod currently directly manages the clkctrl
register, we just want to move that part to be a clock driver.
The children of the interconnect target modules just need to use
PM runtime, but the interconnect target module driver needs to know
it's clkctrl clock.
> If fine grained control of a clock is needed (e.g. for clk_set_rate)
> then the driver can still clk_get it. Whether or not the clockdomain
> provides that clock or if it comes from the clock generator (e.g. cm1,
> cm2, prm, etc) isn't as important to me, but I prefer for the
> clockdomain to not be a clock provider if possible.
Yeah I totally agree with that, and that's already what we mostly
have.
> > I don't at least yet
> > follow what we need to do with the clockdomains with genpd :)
>
> Use the clockdomain genpd to call clk_enable/disable under the hood.
> Don't use them as clock providers to the target modules. Clockdomain
> genpds would be the clock consumers.
I don't think the clockdomain should be a genpd provider because
that creates a genpd network of dependencies instead of a tree
structure. If we end up setting the clockdomains with genpd, then
only the other clockdomains should use them, but I don't know how
we ever keep drivers from directly tinkering with them..
IMO, the clockdomain clock driver should just provides clocks, then
we can have the interconnect target module driver deal with the
clockdomain dependencies.
> > Wouldn't just doing clk_get() from one clockdomain clock to
> > another clockdomain clock (or it's output) be enough to
> > represent the clockdomain dependencies?
>
> s/clk_get/clk_prepare_enable/
>
> Yes, but you're stuffing functional dependencies into the clock tree,
> which sucks. genpd was created to model these arbitrary dependencies.
Well let's not stuff anything beyond clock framework to the
clockdomain clock drivers. We already have the clockdomain
dependencies handled by the interconnect code (hwmod), and there
should be no problem moving those to be handled by genpd and the
interconnect target driver instances.
Care to take another look at Tero's patches with the assumption
that the clockdomain clocks stay just as a clocks?
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: [PATCH 1/3] clkdev: add devm_get_clk_from_child()
From: Russell King - ARM Linux @ 2016-12-09 20:31 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Stephen Boyd, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Linux-Kernel, Mark Brown, linux-clk, Linux-ARM
In-Reply-To: <8737i3vtl7.wl%kuninori.morimoto.gx@renesas.com>
On Mon, Dec 05, 2016 at 05:23:20AM +0000, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> Some driver is using this type of DT bindings for clock (more detail,
> see ${LINUX}/Documentation/devicetree/bindings/sound/simple-card.txt).
>
> sound_soc {
> ...
> cpu {
> clocks = <&xxx>;
> ...
> };
> codec {
> clocks = <&xxx>;
> ...
> };
> };
>
> Current driver in this case uses of_clk_get() for each node, but there
> is no devm_of_clk_get() today.
> OTOH, the problem of having devm_of_clk_get() is that it encourages the
> use of of_clk_get() when clk_get() is more desirable.
>
> Thus, this patch adds new devm_get_clk_from_chile() which explicitly
> reads as get a clock from a child node of this device.
> By this function, we can also use this type of DT bindings
>
> sound_soc {
> clocks = <&xxx>, <&xxx>;
> clock-names = "cpu", "codec";
> ...
> cpu {
> ...
> };
> codec {
> ...
> };
> };
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
This looks lots better, thanks.
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Michael Turquette @ 2016-12-09 20:02 UTC (permalink / raw)
To: Tony Lindgren, Tero Kristo
Cc: Stephen Boyd, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring
In-Reply-To: <20161205152534.GJ4705-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Quoting Tony Lindgren (2016-12-05 07:25:34)
> * Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org> [161205 02:09]:
> > On 03/12/16 02:18, Tony Lindgren wrote:
> > > * Michael Turquette <mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> [161202 15:52]:
> > > > Quoting Tony Lindgren (2016-12-02 15:12:40)
> > > > > * Michael Turquette <mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> [161202 14:34]:
> > > > > > Quoting Tony Lindgren (2016-10-28 16:54:48)
> > > > > > > * Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> [161028 16:37]:
> > > > > > > > On 10/28, Tony Lindgren wrote:
> > > > > > > > > * Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org> [161028 00:43]:
> > > > > > > > > > On 28/10/16 03:50, Stephen Boyd wrote:
> > > > > > > > > > > I suppose a PRCM is
> > > > > > > > > > > like an MFD that has clocks and resets under it? On other
> > > > > > > > > > > platforms we've combined that all into one node and just had
> > > > > > > > > > > #clock-cells and #reset-cells in that node. Is there any reason
> > > > > > > > > > > we can't do that here?
> > > > > > > > > >
> > > > > > > > > > For OMAPs, there are typically multiple instances of the PRCM around; OMAP4
> > > > > > > > > > for example has:
> > > > > > > > > >
> > > > > > > > > > cm1 @ 0x4a004000 (clocks + clockdomains)
> > > > > > > > > > cm2 @ 0x4a008000 (clocks + clockdomains)
> > > > > > > > > > prm @ 0x4a306000 (few clocks + resets + power state handling)
> > > > > > > > > > scrm @ 0x4a30a000 (few external clocks + plenty of misc stuff)
> > > > > > > > > >
> > > > > > > > > > These instances are also under different power/voltage domains which means
> > > > > > > > > > their PM behavior is different.
> > > > > > > > > >
> > > > > > > > > > The idea behind having a clockdomain as a provider was mostly to have the
> > > > > > > > > > topology visible : prcm-instance -> clockdomain -> clocks
> > > > > > > > >
> > > > > > > > > Yeah that's needed to get the interconnect hierarchy right for
> > > > > > > > > genpd :)
> > > > > > > > >
> > > > > > > > > > ... but basically I think it would be possible to drop the clockdomain
> > > > > > > > > > representation and just mark the prcm-instance as a clock provider. Tony,
> > > > > > > > > > any thoughts on that?
> > > > > > > > >
> > > > > > > > > No let's not drop the clockdomains as those will be needed when we
> > > > > > > > > move things into proper hierarchy within the interconnect instances.
> > > > > > > > > This will then help with getting things right with genpd.
> > > > > > > > >
> > > > > > > > > In the long run we just want to specify clockdomain and the offset of
> > > > > > > > > the clock instance within the clockdomain in the dts files.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Sorry, I have very little idea how OMAP hardware works. Do you
> > > > > > > > mean that you will have different nodes for each clockdomain so
> > > > > > > > that genpd can map 1:1 to the node in dts? But in hardware
> > > > > > > > there's a prcm that allows us to control many clock domains
> > > > > > > > through register read/writes? How is the interconnect involved?
> > > > > > >
> > > > > > > There are multiple clockdomains, at least one for each interconnect
> > > > > > > instance. Once a clockdomain is idle, the related interconnect can
> > > > > > > idle too. So yeah genpd pretty much maps 1:1 with the clockdomains.
> > > > > > >
> > > > > > > There's more info in for example omap4 TRM section "3.4.1 Device
> > > > > > > Power-Management Layout" that shows the voltage/power/clock domains.
> > > > > > > The interconnect instances are mostly named there too looking at
> > > > > > > the L4/L3 naming.
> > > > > >
> > > > > > I'm confused on two points:
> > > > > >
> > > > > > 1) why are the clkdm's acting as clock providers? I've always hated the
> > > > > > name "clock domain" since those bits are for managing module state, not
> > > > > > clock state. The PRM, CM1 and CM2 provide the clocks, not the
> > > > > > clockdomains.
> > > > >
> > > > > The clock domains have multiple clock inputs that are routed to multiple
> > > > > child clocks. So it is a clock :)
> > > > >
> > > > > See for example omap4430 TRM "3.6.4 CD_WKUP Clock Domain" on page
> > > > > 393 in my revision here.
> > > > >
> > > > > On that page "Figure 3-48" shows CD_WKUP with the four input clocks.
> > > > > And then "Table 3-84. CD_WKUP Control and Status Parameters" shows
> > > > > the CD_WKUP clock domain specific registers. These registers show
> > > > > the status, I think they are all read-only registers. Then CD_WKUP
> > > > > has multiple child clocks with configurable registers.
> > > > >
> > > > > From hardware register point of view, each clock domain has:
> > > > >
> > > > > - Read-only clockdomain status registers in the beginning of
> > > > > the address space
> > > > >
> > > > > - Multiple similar clock instances register instances each
> > > > > mapping to a specific interconnect target module
> > > > >
> > > > > These are documented in "3.11.16.1 WKUP_CM Register Summary".
> > > >
> > > > Oh, this is because you are treating the MODULEMODE bits like gate
> > > > clocks. I never really figured out if this was the best way to model
> > > > those bits since they do more than control a line toggling at a rate.
> > > > For instance this bit will affect the master/slave IDLE protocol between
> > > > the module and the PRCM.
> > >
> > > Yes seems like there is some negotiation going on there with the
> > > target module. But from practical point of view the CLKCTRL
> > > register is the gate for a module functional clock.
> >
> > There's some confusion on this, clockdomain is effectively a collection of
> > clocks, and can be used to force control that collection if needed. Chapter
> > "3.1.1.1.3 Clock Domain" in some OMAP4 TRM shows the relationship neatly.
>
> Yeah that's my understanding too.
There is no clk api for this type of behavior. We keep clocks enabled so
long as consumers have a positive prepare_count or enable_count. The
concept of force-idle doesn't work very well here, unless any calls to
force the clkdm to idle also use a usecount.
>
> > > > > From hardware point of view, we ideally want to map interconnect
> > > > > target modules to the clock instance offset from the clock domain
> > > > > for that interconnect segment. For example gptimer1 clocks would
> > > > > be just:
> > > > >
> > > > > clocks = <&cd_wkup 0x40>;
> > > > >
> > > > > > 2) why aren't the clock domains modeled as genpds with their associated
> > > > > > devices attached to them? Note that it is possible to "nest" genpd
> > > > > > objects. This would also allow for the "Clockdomain Dependency"
> > > > > > relationships to be properly modeled (see section 3.1.1.1.7 Clock Domain
> > > > > > Dependency in the OMAP4 TRM).
> > > > >
> > > > > Clock domains only route clocks to child clocks. Power domains
> > > > > are different registers. The power domains map roughly to
> > > > > interconnect instances, there we have registers to disable the
> > > > > whole interconnect when idle.
> > > >
> > > > I'm not talking about power islands at all, but the genpd object in
> > > > Linux. For instance, if we treat each clock domain like a clock
> > > > provider, how could the functional dependency between clkdm_A and
> > > > clkdm_B be asserted?
> > >
> > > To me it seems that some output of a clockdomain is just a input
> > > of another clockdomain? So it's just the usual parent child
> > > relationship once we treat a clockdomain just as a clock. Tero
> > > probably has some input here.
> >
> > A clockdomain should be modelled as a genpd, that I agree. However, it
> > doesn't prevent it from being a clock provider also, or does it?
It does not prevent it, but I don't understand why you would want both.
I had a recent conversation with Kevin Hilman about a related issue
(we were not discussing this thread or this series) and we both agreed
that most drivers don't even need to managed their clocks directly, so
much as they need to manage their on/off resources. Clocks are just one
part of that, and if we can hide that stuff inside of an attached genpd
then it would be better than having the driver manage clocks explicitly.
Obviously some devices such as audio codec or uart will need to manage
clocks directly, but this is mostly the exception, not the rule.
> >
> > > > There is certainly no API for that in the clock framework, but for genpd
> > > > your runtime_pm_get() callback for clkdm_A could call runtime_pm_get
> > > > against clkdm_B, which would satisfy the requirement. See section
> > > > 3.1.1.1.7 Clock Domain Dependency in the OMAP4 TRM, version AB.
> >
> > For static dependencies the apis genpd_add/remove_subdomain could probably
> > be used.
> >
> > > To me it seems the API is just clk_get() :) Do you have some
> > > specific example we can use to check? My guess is that the
> > > TRM "Clock Domain Dependency" is just the usual parent child
> > > relationship between clocks that are the clockdomains..
clk_get() only fetches a pointer to the clk. I guess you mean
clk_prepare_enable() to actually increment the use count?
If we used the clk framework here is that it would look something like
this:
clk_enable(clk_a)
-> .enable(clk_a_hw)
-> clk_enable(clk_b)
However, clk_a and clk_b do not have a parent-child relationship in the
clock tree. This is purely a functional relationship between IP blocks.
Modeling this sort of thing in the clk framework would be wrong, and
genpd is a much better place to establish these arbitrary relationships.
> > >
> > > If there is something more magical there certainly that should
> > > be considered though.
> >
> > The hwmods could be transformed to individual genpds also I guess. On DT
> > level though, we would still need a clock pointer to the main clock and a
> > genpd pointer in addition to that.
>
> Hmm a genpd pointer to where exactly? AFAIK each interconnect
> instance should be a genpd provider, and the individual interconnect
> target modules should be consumers for that genpd.
I was thinking that the clock domains would be modeled as genpd objects
with the interconnect target modules attached as struct devices.
>
> > Tony, any thoughts on that? Would this break up the plans for the
> > interconnect completely?
>
> Does using genpd for clockdomains cause issues for using genpd for
> interconnect instances and the target modules?
Can they be the same object in Linux? If there is a one-to-one mapping
between clock domains and the interconnect port then maybe you can just
model them together.
>
> The thing I'd be worried about there is that the clockdomains and
> their child clocks are just devices sitting on the interconnect,
> so we could easily end up with genpd modeling something that does
> not represent the hardware.
>
> For example, on 4430 we have:
>
> l4_cfg interconnect
> ...
> segment@0
> ...
> target_module@4000
> cm1: cm1@0
How about:
l4_cfg interconnect
...
segment@0
...
cm1@4000
module: foo_module@0
I don't know much about the segments. Do they map one-to-one with the
clock domains?
> ...
> ...
> target_module@8000
> cm2: cm2@0
> ...
>
>
> l4_wkup interonnect
> ...
> segment@0
> ...
> target_module@6000
> prm: prm@0
> ...
> target_module@a000
> scrm: scrm@0
> ...
>
> So what do you guys have in mind for using genpd in the above
> example for the clockdomains?
If my quick-and-dirty DT above makes sense, then the target modules
(e.g. io controller) would not get clocks anymore, but just
pm_runtime_get(). The genpd backing object would call clk_enable/disable
as needed.
If fine grained control of a clock is needed (e.g. for clk_set_rate)
then the driver can still clk_get it. Whether or not the clockdomain
provides that clock or if it comes from the clock generator (e.g. cm1,
cm2, prm, etc) isn't as important to me, but I prefer for the
clockdomain to not be a clock provider if possible.
>
> To me it seems that the interconnect instances like l4_cfg and
> l4_wkup above should be genpd providers.
Agreed.
> I don't at least yet
> follow what we need to do with the clockdomains with genpd :)
Use the clockdomain genpd to call clk_enable/disable under the hood.
Don't use them as clock providers to the target modules. Clockdomain
genpds would be the clock consumers.
>
> Wouldn't just doing clk_get() from one clockdomain clock to
> another clockdomain clock (or it's output) be enough to
> represent the clockdomain dependencies?
s/clk_get/clk_prepare_enable/
Yes, but you're stuffing functional dependencies into the clock tree,
which sucks. genpd was created to model these arbitrary dependencies.
Regards,
Mike
>
> 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
* [PATCH 2/2] usb: gadget: s3c2410: allow probing from device tree
From: Sergio Prado @ 2016-12-09 19:06 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
balbi-DgEjT+Ai2ygdnm+yROfE0A, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Sergio Prado
In-Reply-To: <1481310400-28676-1-git-send-email-sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>
Allows configuring Samsung's s3c2410 and compatible USB device
controller using a devicetree.
Signed-off-by: Sergio Prado <sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>
---
drivers/usb/gadget/udc/s3c2410_udc.c | 142 +++++++++++++++++++++++++++++------
drivers/usb/gadget/udc/s3c2410_udc.h | 4 +
2 files changed, 123 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/gadget/udc/s3c2410_udc.c b/drivers/usb/gadget/udc/s3c2410_udc.c
index 4643a01262b4..e3b5a0e6646e 100644
--- a/drivers/usb/gadget/udc/s3c2410_udc.c
+++ b/drivers/usb/gadget/udc/s3c2410_udc.c
@@ -30,6 +30,9 @@
#include <linux/gpio.h>
#include <linux/prefetch.h>
#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
#include <linux/debugfs.h>
#include <linux/seq_file.h>
@@ -55,6 +58,18 @@
#define DRIVER_AUTHOR "Herbert Pötzl <herbert-dBHVzrDq9nF4Lj/PQRBjDg@public.gmane.org>, " \
"Arnaud Patard <arnaud.patard-dQbF7i+pzddAfugRpC6u6w@public.gmane.org>"
+struct s3c2410_udc_drv_data {
+ int ep_fifo_size;
+};
+
+static const struct s3c2410_udc_drv_data s3c2410_udc_2410_drv_data = {
+ .ep_fifo_size = EP_FIFO_SIZE,
+};
+
+static const struct s3c2410_udc_drv_data s3c2410_udc_2440_drv_data = {
+ .ep_fifo_size = S3C2440_EP_FIFO_SIZE,
+};
+
static const char gadget_name[] = "s3c2410_udc";
static const char driver_desc[] = DRIVER_DESC;
@@ -62,8 +77,6 @@
static struct clk *udc_clock;
static struct clk *usb_bus_clock;
static void __iomem *base_addr;
-static u64 rsrc_start;
-static u64 rsrc_len;
static struct dentry *s3c2410_udc_debugfs_root;
static inline u32 udc_read(u32 reg)
@@ -997,7 +1010,7 @@ static irqreturn_t s3c2410_udc_irq(int dummy, void *_dev)
}
}
- dprintk(DEBUG_VERBOSE, "irq: %d s3c2410_udc_done.\n", IRQ_USBD);
+ dprintk(DEBUG_VERBOSE, "irq: %d s3c2410_udc_done.\n", dev->irq);
/* Restore old index */
udc_write(idx, S3C2410_UDC_INDEX_REG);
@@ -1757,6 +1770,49 @@ static int s3c2410_udc_stop(struct usb_gadget *g)
};
+static int s3c2410_udc_probe_dt(struct s3c2410_udc *udc)
+{
+ const struct s3c2410_udc_drv_data *drvdata;
+ struct platform_device *pdev = udc->pdev;
+ struct s3c2410_udc_mach_info *pdata;
+ int gpio;
+
+ drvdata = of_device_get_match_data(&pdev->dev);
+
+ if (drvdata)
+ udc->ep_fifo_size = drvdata->ep_fifo_size;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ gpio = of_get_named_gpio(pdev->dev.of_node, "samsung,vbus-gpio", 0);
+ if (gpio_is_valid(gpio))
+ pdata->vbus_pin = gpio;
+
+ gpio = of_get_named_gpio(pdev->dev.of_node, "samsung,pullup-gpio", 0);
+ if (gpio_is_valid(gpio))
+ pdata->pullup_pin = gpio;
+
+ pdev->dev.platform_data = pdata;
+
+ return 0;
+}
+
+static int s3c2410_udc_probe_pdata(struct s3c2410_udc *udc)
+{
+ const struct s3c2410_udc_drv_data *drvdata;
+ struct platform_device *pdev = udc->pdev;
+
+ drvdata = (struct s3c2410_udc_drv_data *)
+ platform_get_device_id(pdev)->driver_data;
+
+ if (drvdata)
+ udc->ep_fifo_size = drvdata->ep_fifo_size;
+
+ return 0;
+}
+
/*
* probe - binds to the platform device
*/
@@ -1769,6 +1825,16 @@ static int s3c2410_udc_probe(struct platform_device *pdev)
dev_dbg(dev, "%s()\n", __func__);
+ udc->pdev = pdev;
+
+ if (pdev->dev.of_node)
+ retval = s3c2410_udc_probe_dt(udc);
+ else
+ retval = s3c2410_udc_probe_pdata(udc);
+
+ if (retval)
+ return retval;
+
usb_bus_clock = clk_get(NULL, "usb-bus-gadget");
if (IS_ERR(usb_bus_clock)) {
dev_err(dev, "failed to get usb bus clock source\n");
@@ -1789,24 +1855,27 @@ static int s3c2410_udc_probe(struct platform_device *pdev)
dev_dbg(dev, "got and enabled clocks\n");
- if (strncmp(pdev->name, "s3c2440", 7) == 0) {
- dev_info(dev, "S3C2440: increasing FIFO to 128 bytes\n");
- memory.ep[1].fifo_size = S3C2440_EP_FIFO_SIZE;
- memory.ep[2].fifo_size = S3C2440_EP_FIFO_SIZE;
- memory.ep[3].fifo_size = S3C2440_EP_FIFO_SIZE;
- memory.ep[4].fifo_size = S3C2440_EP_FIFO_SIZE;
+ if (udc->ep_fifo_size) {
+ dev_info(dev, "setting FIFO to %d bytes\n", udc->ep_fifo_size);
+ memory.ep[1].fifo_size = udc->ep_fifo_size;
+ memory.ep[2].fifo_size = udc->ep_fifo_size;
+ memory.ep[3].fifo_size = udc->ep_fifo_size;
+ memory.ep[4].fifo_size = udc->ep_fifo_size;
}
spin_lock_init(&udc->lock);
udc_info = dev_get_platdata(&pdev->dev);
- rsrc_start = S3C2410_PA_USBDEV;
- rsrc_len = S3C24XX_SZ_USBDEV;
+ udc->mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!udc->mem) {
+ dev_err(dev, "failed to get I/O memory region\n");
+ return -ENOENT;
+ }
- if (!request_mem_region(rsrc_start, rsrc_len, gadget_name))
+ if (!request_mem_region(udc->mem->start, resource_size(udc->mem), gadget_name))
return -EBUSY;
- base_addr = ioremap(rsrc_start, rsrc_len);
+ base_addr = ioremap(udc->mem->start, resource_size(udc->mem));
if (!base_addr) {
retval = -ENOMEM;
goto err_mem;
@@ -1818,17 +1887,24 @@ static int s3c2410_udc_probe(struct platform_device *pdev)
s3c2410_udc_disable(udc);
s3c2410_udc_reinit(udc);
+ udc->irq = platform_get_irq(pdev, 0);
+ if (udc->irq == 0) {
+ dev_err(dev, "failed to get interrupt\n");
+ retval = -EINVAL;
+ goto err_map;
+ }
+
/* irq setup after old hardware state is cleaned up */
- retval = request_irq(IRQ_USBD, s3c2410_udc_irq,
+ retval = request_irq(udc->irq, s3c2410_udc_irq,
0, gadget_name, udc);
if (retval != 0) {
- dev_err(dev, "cannot get irq %i, err %d\n", IRQ_USBD, retval);
+ dev_err(dev, "cannot get irq %i, err %d\n", udc->irq, retval);
retval = -EBUSY;
goto err_map;
}
- dev_dbg(dev, "got irq %i\n", IRQ_USBD);
+ dev_dbg(dev, "got irq %i\n", udc->irq);
if (udc_info && udc_info->vbus_pin > 0) {
retval = gpio_request(udc_info->vbus_pin, "udc vbus");
@@ -1899,11 +1975,11 @@ static int s3c2410_udc_probe(struct platform_device *pdev)
if (udc_info && udc_info->vbus_pin > 0)
gpio_free(udc_info->vbus_pin);
err_int:
- free_irq(IRQ_USBD, udc);
+ free_irq(udc->irq, udc);
err_map:
iounmap(base_addr);
err_mem:
- release_mem_region(rsrc_start, rsrc_len);
+ release_mem_region(udc->mem->start, resource_size(udc->mem));
return retval;
}
@@ -1933,10 +2009,10 @@ static int s3c2410_udc_remove(struct platform_device *pdev)
free_irq(irq, udc);
}
- free_irq(IRQ_USBD, udc);
+ free_irq(udc->irq, udc);
iounmap(base_addr);
- release_mem_region(rsrc_start, rsrc_len);
+ release_mem_region(udc->mem->start, resource_size(udc->mem));
if (!IS_ERR(udc_clock) && udc_clock != NULL) {
clk_disable_unprepare(udc_clock);
@@ -1974,16 +2050,36 @@ static int s3c2410_udc_resume(struct platform_device *pdev)
#define s3c2410_udc_resume NULL
#endif
+static const struct of_device_id s3c_udc_dt_ids[] = {
+ {
+ .compatible = "samsung,s3c2410-udc",
+ .data = &s3c2410_udc_2410_drv_data,
+ },
+ {
+ .compatible = "samsung,s3c2440-udc",
+ .data = &s3c2410_udc_2440_drv_data,
+ },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, s3c_udc_dt_ids);
+
static const struct platform_device_id s3c_udc_ids[] = {
- { "s3c2410-usbgadget", },
- { "s3c2440-usbgadget", },
- { }
+ {
+ .name = "s3c2410-usbgadget",
+ .driver_data = (kernel_ulong_t) &s3c2410_udc_2410_drv_data,
+ },
+ {
+ .name = "s3c2440-usbgadget",
+ .driver_data = (kernel_ulong_t) &s3c2410_udc_2440_drv_data,
+ },
+ { /* sentinel */},
};
MODULE_DEVICE_TABLE(platform, s3c_udc_ids);
static struct platform_driver udc_driver_24x0 = {
.driver = {
.name = "s3c24x0-usbgadget",
+ .of_match_table = s3c_udc_dt_ids,
},
.probe = s3c2410_udc_probe,
.remove = s3c2410_udc_remove,
diff --git a/drivers/usb/gadget/udc/s3c2410_udc.h b/drivers/usb/gadget/udc/s3c2410_udc.h
index 93bf225f1969..8fdbe77a804d 100644
--- a/drivers/usb/gadget/udc/s3c2410_udc.h
+++ b/drivers/usb/gadget/udc/s3c2410_udc.h
@@ -94,6 +94,10 @@ struct s3c2410_udc {
unsigned req_pending : 1;
u8 vbus;
struct dentry *regs_info;
+ struct platform_device *pdev;
+ struct resource *mem;
+ int irq;
+ unsigned int ep_fifo_size;
};
#define to_s3c2410(g) (container_of((g), struct s3c2410_udc, gadget))
--
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 1/2] dt-bindings: usb: add DT binding for s3c2410 USB device controller
From: Sergio Prado @ 2016-12-09 19:06 UTC (permalink / raw)
To: gregkh, robh+dt, mark.rutland, balbi, linux-usb, devicetree,
linux-kernel
Cc: Sergio Prado
In-Reply-To: <1481310400-28676-1-git-send-email-sergio.prado@e-labworks.com>
Adds the device tree bindings description for Samsung S3C2410 and
compatible USB device controller.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
---
.../devicetree/bindings/usb/s3c2410-usb.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
index e45b38ce2986..4d3f9894c2d4 100644
--- a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
+++ b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
@@ -20,3 +20,31 @@ usb0: ohci@49000000 {
clocks = <&clocks UCLK>, <&clocks HCLK_USBH>;
clock-names = "usb-bus-host", "usb-host";
};
+
+Samsung S3C2410 and compatible USB device controller
+
+Required properties:
+ - compatible: Should be one of the following
+ "samsung,s3c2410-udc"
+ "samsung,s3c2440-udc"
+ - reg: address and length of the controller memory mapped region
+ - interrupts: interrupt number for the USB device controller
+ - clocks: Should reference the bus and host clocks
+ - clock-names: Should contain two strings
+ "usb-bus-gadget" for the USB bus clock
+ "usb-device" for the USB device clock
+
+Optional properties:
+ - samsung,vbus-gpio: If present, specifies a gpio that needs to be
+ activated for the bus to be powered.
+ - samsung,pullup-gpio: If present, specifies a gpio to control the
+ USB D+ pullup.
+
+usb1: udc@52000000 {
+ compatible = "samsung,s3c2440-udc";
+ reg = <0x52000000 0x100000>;
+ interrupts = <0 0 25 3>;
+ clocks = <&clocks UCLK>, <&clocks HCLK_USBD>;
+ clock-names = "usb-bus-gadget", "usb-device";
+ samsung,pullup-gpio = <&gpc 5 GPIO_ACTIVE_HIGH>;
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] usb: gadget: s3c2410: add device tree support
From: Sergio Prado @ 2016-12-09 19:06 UTC (permalink / raw)
To: gregkh, robh+dt, mark.rutland, balbi, linux-usb, devicetree,
linux-kernel
Cc: Sergio Prado
This series adds support for configuring Samsung's s3c2410 and
compatible USB device controller via devicetree.
Tested on FriendlyARM mini2440, based on s3c2440 SoC.
Sergio Prado (2):
dt-bindings: usb: add DT binding for s3c2410 USB device controller
usb: gadget: s3c2410: allow probing from device tree
.../devicetree/bindings/usb/s3c2410-usb.txt | 28 ++++
drivers/usb/gadget/udc/s3c2410_udc.c | 142 +++++++++++++++++----
drivers/usb/gadget/udc/s3c2410_udc.h | 4 +
3 files changed, 151 insertions(+), 23 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH 6/9] dt-bindings: Document rk3399 Gru/Kevin
From: Heiko Stuebner @ 2016-12-09 18:28 UTC (permalink / raw)
To: Rob Herring
Cc: Brian Norris, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Caesar Wang, Doug Anderson,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Barber,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chris Zhong
In-Reply-To: <20161209175402.gy4mqjaf2rsib7qf@rob-hp-laptop>
Am Freitag, 9. Dezember 2016, 11:54:02 CET schrieb Rob Herring:
> On Thu, Dec 01, 2016 at 06:27:30PM -0800, Brian Norris wrote:
> > Gru is a base dev board for a family of devices, including Kevin. Both
> > utilize Rockchip RK3399, and they share much of their design.
> >
> > Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > ---
> >
> > Documentation/devicetree/bindings/arm/rockchip.txt | 20
> > ++++++++++++++++++++ 1 file changed, 20 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> > b/Documentation/devicetree/bindings/arm/rockchip.txt index
> > cc4ace6397ab..830e13f5890c 100644
> > --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> > +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> > @@ -99,6 +99,26 @@ Rockchip platforms device tree bindings
> >
> > "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> > "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> >
> > +- Google Gru (dev-board):
> > + Required root node properties:
> > + - compatible = "google,gru-rev15", "google,gru-rev14",
> > + "google,gru-rev13", "google,gru-rev12",
> > + "google,gru-rev11", "google,gru-rev10",
> > + "google,gru-rev9", "google,gru-rev8",
> > + "google,gru-rev7", "google,gru-rev6",
> > + "google,gru-rev5", "google,gru-rev4",
> > + "google,gru-rev3", "google,gru-rev2",
> > + "google,gru", "rockchip,rk3399";
>
> All of these are supposed to be specified or just one rev at a time?
All of them. I.e. the devicetree is supposed to be compatible with all of
those, while the bootloader determines the actual board revision and sets the
choosen compatible - at least that was the way with the previous series of
devices based around the rk3288 (veyron) and I think it will be the same way
still.
I.e. as you can see below, Kevin starts being compatible at -rev6, as
(engineering) revisions before that probably had some differences on the
board.
>
> > +
> > +- Google Kevin:
> > + Required root node properties:
> > + - compatible = "google,kevin-rev15", "google,kevin-rev14",
> > + "google,kevin-rev13", "google,kevin-rev12",
> > + "google,kevin-rev11", "google,kevin-rev10",
> > + "google,kevin-rev9", "google,kevin-rev8",
> > + "google,kevin-rev7", "google,kevin-rev6",
> > + "google,kevin", "google,gru", "rockchip,rk3399";
> > +
> >
> > - mqmaker MiQi:
> > Required root node properties:
> > - compatible = "mqmaker,miqi", "rockchip,rk3288";
--
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] of/irq: improve error report on irq discovery process failure
From: Guilherme G. Piccoli @ 2016-12-09 18:19 UTC (permalink / raw)
To: Rob Herring
Cc: linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev, Mark Rutland, Benjamin Herrenschmidt, Frank Rowand,
Marc Zyngier
In-Reply-To: <CAL_JsqJQEYmxbUaL5qhym1MHRvUbo=PvUWDMKRDqLnBhuJAYzQ@mail.gmail.com>
On 12/09/2016 02:25 PM, Rob Herring wrote:
> On Mon, Dec 5, 2016 at 1:01 PM, Guilherme G. Piccoli
> <gpiccoli@linux.vnet.ibm.com> wrote:
>> On 12/05/2016 12:28 PM, Rob Herring wrote:
>>> On Mon, Dec 5, 2016 at 7:59 AM, Guilherme G. Piccoli
>>> <gpiccoli@linux.vnet.ibm.com> wrote:
>>>> On PowerPC machines some PCI slots might not have level triggered
>>>> interrupts capability (also know as level signaled interrupts),
>>>> leading of_irq_parse_pci() to complain by presenting error messages
>>>> on the kernel log - in this case, the properties "interrupt-map" and
>>>> "interrupt-map-mask" are not present on device's node in the device
>>>> tree.
>>>>
>>>> This patch introduces a different message for this specific case,
>>>> and also reduces its level from error to warning. Besides, we warn
>>>> (once) that possibly some PCI slots on the system have no level
>>>> triggered interrupts available.
>>>> We changed some error return codes too on function of_irq_parse_raw()
>>>> in order other failure's cases can be presented in a more precise way.
>>>>
>>>> Before this patch, when an adapter was plugged in a slot without level
>>>> interrupts capabilitiy on PowerPC, we saw a generic error message
>>>> like this:
>>>>
>>>> [54.239] pci 002d:70:00.0: of_irq_parse_pci() failed with rc=-22
>>>>
>>>> Now, with this applied, we see the following specific message:
>>>>
>>>> [16.154] pci 0014:60:00.1: of_irq_parse_pci: no interrupt-map found,
>>>> INTx interrupts not available
>>>>
>>>> Finally, we standardize the error path in of_irq_parse_raw() by always
>>>> taking the fail path instead of returning directly from the loop.
>>>>
>>>> Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
>>>> ---
>>>>
>>>> v2:
>>>> * Changed function return code to always return negative values;
>>>
>>> Are you sure this is safe? This is tricky because of differing values
>>> of NO_IRQ (0 or -1).
>>
>> Thanks Rob, but this is purely bad wording from myself. I'm sorry - I
>> meant to say that I changed only my positive return code (that was
>> suggested to be removed in the prior revision) to negative return code!
>>
>> So, I changed only code I added myself in v1 =)
>>
>>
>>>
>>>> * Improved/simplified warning outputs;
>>>> * Changed some return codes and some error paths in of_irq_parse_raw()
>>>> in order to be more precise/consistent;
>>>
>>> This too could have some side effects on callers.
>>>
>>> Not saying don't do these changes, just need some assurances this has
>>> been considered.
>>
>> Thanks for your attention. I performed a quick investigation before
>> changing this, all the places that use the return values are just
>> getting "true/false" information from that, meaning they just are
>> comparing to 0 basically. So change -EINVAL to -ENOENT wouldn't hurt any
>> user of these return values, it'll only become more informative IMHO.
>>
>> Now, regarding the only error path that was changed: for some reason,
>> this was the only place in which we didn't goto fail label in case of
>> failure - it was added by a legacy commit from Ben, dated from 2006:
>> 006b64de60 ("[POWERPC] Make OF irq map code detect more error cases").
>> Then it was carried by Grant Likely's commit 7dc2e1134a ("of/irq: merge
>> irq mapping code"), 6-year old commit.
>> I wasn't able to imagine a scenario in which changing this would break
>> something; I believe the change improve consistency, but I'd remove it
>> if you or somebody else thinks it worth be removed.
>
> Okay. It's a bit late for 4.10 now and want this to be in -next for a
> while, so I'll queue it after the merge window.
>
OK, perfect! Thanks Rob
Cheers,
Guilherme
> Rob
>
^ permalink raw reply
* Re: [PATCH 2/2] drm/panel: simple: Add support for Tianma TM070JDHG30
From: Rob Herring @ 2016-12-09 18:14 UTC (permalink / raw)
To: Gary Bisson; +Cc: devicetree, linux-kernel, dri-devel
In-Reply-To: <20161202085208.19459-3-gary.bisson@boundarydevices.com>
On Fri, Dec 02, 2016 at 09:52:08AM +0100, Gary Bisson wrote:
> The Tianma TM070JDHG30 is a 7" LVDS display with a resolution of
> 1280x800.
> http://usa.tianma.com/products-technology/product/tm070jdhg30-00
>
> You can also find this product along with a FT5x06 touch controller
> from Boundary Devices:
> https://boundarydevices.com/product/bd070lic2/
>
> Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
> ---
> .../bindings/display/panel/tianma,tm070jdhg30.txt | 7 ++++++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/2] of: Add vendor prefix for Tianma Micro-electronics
From: Rob Herring @ 2016-12-09 18:12 UTC (permalink / raw)
To: Gary Bisson; +Cc: devicetree, linux-kernel, dri-devel
In-Reply-To: <20161202085208.19459-2-gary.bisson@boundarydevices.com>
On Fri, Dec 02, 2016 at 09:52:07AM +0100, Gary Bisson wrote:
> Tianma Micro-electronics Co., Ltd. (Tianma) specializes in providing
> display solutions and efficient support services worldwide.
>
> More info:
> http://en.tianma.com/about.shtml
>
> Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
From: Rob Herring @ 2016-12-09 18:12 UTC (permalink / raw)
To: Bai Ping
Cc: shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
mark.rutland-5wv7dgnIgG8, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
linux-gpio-u79uwXL29TY76Z2rM5mHXA, p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
fabio.estevam-3arQi8VN3Tc, tglx-hfZtesqFncYOwBW4kG4KsQ,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1480660774-25055-11-git-send-email-ping.bai-3arQi8VN3Tc@public.gmane.org>
On Fri, Dec 02, 2016 at 02:39:33PM +0800, Bai Ping wrote:
> Add necessary document update for i.MX6SLL support.
>
> Signed-off-by: Bai Ping <ping.bai-3arQi8VN3Tc@public.gmane.org>
> ---
> .../devicetree/bindings/clock/imx6sll-clock.txt | 13 ++++++++
> .../bindings/pinctrl/fsl,imx6sll-pinctrl.txt | 37 ++++++++++++++++++++++
> 2 files changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> new file mode 100644
> index 0000000..4f52efa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> @@ -0,0 +1,13 @@
> +* Clock bindings for Freescale i.MX6 UltraLite
I thought UltraLite was MX6UL?
> +
> +Required properties:
> +- compatible: Should be "fsl,imx6sll-ccm"
> +- reg: Address and length of the register set
> +- #clock-cells: Should be <1>
> +- clocks: list of clock specifiers, must contain an entry for each required
> + entry in clock-names
> +- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
> +
> +The clock consumer should specify the desired clock by having the clock
> +ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6sll-clock.h
> +for the full list of i.MX6 SLL clock IDs.
> diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> new file mode 100644
> index 0000000..096e471
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> @@ -0,0 +1,37 @@
> +* Freescale i.MX6 UltraLite IOMUX Controller
ditto
> +
> +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
> +and usage.
> +
> +Required properties:
> +- compatible: "fsl,imx6sll-iomuxc"
> +- fsl,pins: each entry consists of 6 integers and represents the mux and config
> + setting for one pin. The first 5 integers <mux_reg conf_reg input_reg mux_val
> + input_val> are specified using a PIN_FUNC_ID macro, which can be found in
> + imx6ul-pinfunc.h under device tree source folder. The last integer CONFIG is
> + the pad setting value like pull-up on this pin. Please refer to i.MX6SLL
> + Reference Manual for detailed CONFIG settings.
> +
> +CONFIG bits definition:
> +PAD_CTL_LVE (1 << 22)
> +PAD_CTL_HYS (1 << 16)
> +PAD_CTL_PUS_100K_DOWN (0 << 14)
> +PAD_CTL_PUS_47K_UP (1 << 14)
> +PAD_CTL_PUS_100K_UP (2 << 14)
> +PAD_CTL_PUS_22K_UP (3 << 14)
> +PAD_CTL_PUE (1 << 13)
> +PAD_CTL_PKE (1 << 12)
> +PAD_CTL_ODE (1 << 11)
> +PAD_CTL_SPEED_LOW (0 << 6)
> +PAD_CTL_SPEED_MED (1 << 6)
> +PAD_CTL_SPEED_HIGH (3 << 6)
> +PAD_CTL_DSE_DISABLE (0 << 3)
> +PAD_CTL_DSE_260ohm (1 << 3)
> +PAD_CTL_DSE_130ohm (2 << 3)
> +PAD_CTL_DSE_87ohm (3 << 3)
> +PAD_CTL_DSE_65ohm (4 << 3)
> +PAD_CTL_DSE_52ohm (5 << 3)
> +PAD_CTL_DSE_43ohm (6 << 3)
> +PAD_CTL_DSE_37ohm (7 << 3)
> +PAD_CTL_SRE_FAST (1 << 0)
> +PAD_CTL_SRE_SLOW (0 << 0)
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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/4] mmc: pwrseq-simple: add disable-post-power-on option
From: Rob Herring @ 2016-12-09 18:09 UTC (permalink / raw)
To: Matt Ranostay
Cc: Ulf Hansson, devicetree, linux-mmc, Tony Lindgren, Liam Breck
In-Reply-To: <CAJ_EiSQWN0KF1rJDwzOeoi--g1Z0XNYevYzCLG=NngcdgF6VUw@mail.gmail.com>
On Fri, Dec 02, 2016 at 01:06:47AM -0800, Matt Ranostay wrote:
> On Fri, Dec 2, 2016 at 12:28 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > On 2 December 2016 at 08:22, Matt Ranostay <matt@ranostay.consulting> wrote:
> >>
> >>
> >>> On Dec 1, 2016, at 23:13, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >>>
> >>>> On 2 December 2016 at 07:17, Matt Ranostay <matt@ranostay.consulting> wrote:
> >>>> Add optional device-post-power-on parameters to disable post_power_on
> >>>> function from being called since this breaks some device.
> >>>>
> >>>> Cc: Tony Lindgren <tony@atomide.com>
> >>>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> >>>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
> >>>> ---
> >>>> Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 2 ++
> >>>> drivers/mmc/core/pwrseq_simple.c | 7 +++++++
> >>>> 2 files changed, 9 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> >>>> index bea306d772d1..09fa153f743e 100644
> >>>> --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> >>>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> >>>> @@ -24,6 +24,8 @@ Optional properties:
> >>>> de-asserting the reset-gpios (if any)
> >>>> - invert-off-state: Invert the power down state for the reset-gpios (if any)
> >>>> and pwrdn-gpios (if any)
> >>>> +- disable-post-power-on : Avoid post_power_on function from being called since
> >>>> + this breaks some devices
> >>>
> >>> This is a bit weird. I would like to avoid this, if possible.
> >>>
> >>> Perhaps if you simply describe the sequence in detail for your device
> >>> we can figure out the best option together.
> >>
> >> Yeah I know it is a bit weird but we need to keep that reset pin high for at least some time after pre power on. So any case it would be another property
> >
> > This went offlist, please resend.
> >
> > Moreover, please try to describe the sequence you need in detail
> > according to your HW spec.
> >
>
> Yeah oops....
>
> So basically we need to drive the reset and powerdown lines high with
> a 300 milliseconds delay between both...
> can't have the reset line low with post power on (pretty sure but
> would need a delay anyway), and we need both reset + powerdown line
> set low on powerdown.
>
> So the power down sequence would need to be reversed for this
> application in pwrseq-simple.
This sounds like you need a device specific sequence to me. Otherwise,
write a language to describe any power control waveforms rather than
trying to bolt on more and more properties. (Don't really go write a
language.)
Rob
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: Add DT bindings info for FlexRM ring manager
From: Rob Herring @ 2016-12-09 18:01 UTC (permalink / raw)
To: Anup Patel
Cc: Jassi Brar, Mark Rutland, Ray Jui, Scott Branden, Pramod KUMAR,
Rob Rice, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w
In-Reply-To: <1480653536-5551-3-git-send-email-anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Fri, Dec 02, 2016 at 10:08:56AM +0530, Anup Patel wrote:
> This patch adds device tree bindings document for the FlexRM
> ring manager found on Broadcom iProc SoCs.
>
> Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> .../bindings/mailbox/brcm,iproc-flexrm-mbox.txt | 60 ++++++++++++++++++++++
> 1 file changed, 60 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
>
> diff --git a/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
> new file mode 100644
> index 0000000..e81f116
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
> @@ -0,0 +1,60 @@
[...]
> +Example:
> +--------
> +crypto_mbox: mbox@67000000 {
> + compatible = "brcm,flexrm-mbox";
> + reg = <0x67000000 0x200000>;
> + msi-parent = <&gic_its 0x7f00>;
> + #mbox-cells = <3>;
> +};
> +
> +crypto_client {
> + ...
> + mboxes = <&crypto_mbox 0 0x1 0xffff>,
> + <&crypto_mbox 1 0x1 0xffff>,
> + <&crypto_mbox 16 0x1 0xffff>,
> + <&crypto_mbox 17 0x1 0xffff>,
> + <&crypto_mbox 30 0x1 0xffff>,
> + <&crypto_mbox 31 0x1 0xffff>;
The FlexRM part looks fine. I still don't understand what this node is.
Is this a h/w block or just a list of mailboxes? What determines the
mailbox channel numbers here? I need to see what the complete node looks
like.
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 net-next v2] dsa:mv88e6xxx: dispose irq mapping for chip->irq
From: Andrew Lunn @ 2016-12-09 18:00 UTC (permalink / raw)
To: Volodymyr Bendiuga
Cc: vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
volodymyr.bendiuga-Re5JQEeQqe8AvxtiuMwx3w, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4388a669-b425-97e0-346b-6b20f7f47f86-qeDNsGSBLoYwFerOooGFRg@public.gmane.org>
On Wed, Dec 07, 2016 at 05:40:12PM +0100, Volodymyr Bendiuga wrote:
> Yes, most of the users of of_irq_get() do not use irq_dispose_mapping().
>
> But some of them do (some irq chips), and I believe the correct way
> of doing this is to
>
> dispose irq mapping, as the description for this function says that
> it unmaps
>
> the irq, which is mapped by of_irq_parse_and_map(). Not disposing
> irq might not make
>
> any affect on most drivers, but some, that get EPROBE_DEFER error do
> need to dispose.
>
> This is what I get when I run the code.
>
> of_irq_put() could be implemented, and it would be a wrapper for
> irq_dispose_mapping()
>
> as I can see it. Should I do it this way?
Hi Volodymyr
Yes, i think having of_irq_put() would be good. It gives some symmetry
to the API.
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 6/9] dt-bindings: Document rk3399 Gru/Kevin
From: Rob Herring @ 2016-12-09 17:54 UTC (permalink / raw)
To: Brian Norris
Cc: Heiko Stuebner, linux-rockchip, linux-kernel, Caesar Wang,
Doug Anderson, devicetree, Stephen Barber, linux-arm-kernel,
Chris Zhong
In-Reply-To: <1480645653-36943-7-git-send-email-briannorris@chromium.org>
On Thu, Dec 01, 2016 at 06:27:30PM -0800, Brian Norris wrote:
> Gru is a base dev board for a family of devices, including Kevin. Both
> utilize Rockchip RK3399, and they share much of their design.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> Documentation/devicetree/bindings/arm/rockchip.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
> index cc4ace6397ab..830e13f5890c 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -99,6 +99,26 @@ Rockchip platforms device tree bindings
> "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
>
> +- Google Gru (dev-board):
> + Required root node properties:
> + - compatible = "google,gru-rev15", "google,gru-rev14",
> + "google,gru-rev13", "google,gru-rev12",
> + "google,gru-rev11", "google,gru-rev10",
> + "google,gru-rev9", "google,gru-rev8",
> + "google,gru-rev7", "google,gru-rev6",
> + "google,gru-rev5", "google,gru-rev4",
> + "google,gru-rev3", "google,gru-rev2",
> + "google,gru", "rockchip,rk3399";
All of these are supposed to be specified or just one rev at a time?
> +
> +- Google Kevin:
> + Required root node properties:
> + - compatible = "google,kevin-rev15", "google,kevin-rev14",
> + "google,kevin-rev13", "google,kevin-rev12",
> + "google,kevin-rev11", "google,kevin-rev10",
> + "google,kevin-rev9", "google,kevin-rev8",
> + "google,kevin-rev7", "google,kevin-rev6",
> + "google,kevin", "google,gru", "rockchip,rk3399";
> +
> - mqmaker MiQi:
> Required root node properties:
> - compatible = "mqmaker,miqi", "rockchip,rk3288";
> --
> 2.8.0.rc3.226.g39d4020
>
^ permalink raw reply
* 2??????????;
From: ??? @ 2016-12-09 17:46 UTC (permalink / raw)
To: devicetest.apk; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="l8", Size: 72 bytes --]
2¿Í»§ËµµÃÓë×öµÄ²»Ò»ÖÂ;Ëï³½³ïdevicetest.apk
2¿Í»§ËµµÃÓë×öµÄ²»Ò»ÖÂ;
33
[-- Attachment #2: ?c[3]n.xls --]
[-- Type: application/x-msexcel, Size: 28672 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