* Re: [PATCH v9 2/3] clk: qcom: Add support for RPM Clocks
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Georgi Djakov
Cc: sboyd, mturquette, linux-clk, devicetree, mark.rutland,
linux-kernel, linux-arm-msm
In-Reply-To: <20161102155658.32203-3-georgi.djakov@linaro.org>
On Wed, Nov 02, 2016 at 05:56:57PM +0200, Georgi Djakov wrote:
> This adds initial support for clocks controlled by the Resource
> Power Manager (RPM) processor on some Qualcomm SoCs, which use
> the qcom_rpm driver to communicate with RPM.
> Such platforms are apq8064 and msm8960.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> .../devicetree/bindings/clock/qcom,rpmcc.txt | 1 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/clk/qcom/Kconfig | 13 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/clk-rpm.c | 489 +++++++++++++++++++++
> include/dt-bindings/clock/qcom,rpmcc.h | 24 +
> 5 files changed, 528 insertions(+)
> create mode 100644 drivers/clk/qcom/clk-rpm.c
^ permalink raw reply
* Re: [PATCH v2 4/6] pinctrl: aspeed: Read and write bits in LPCHC and GFX controllers
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Lee Jones, Linus Walleij, Joel Stanley, Mark Rutland, linux-gpio,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <1478097481-14895-5-git-send-email-andrew@aj.id.au>
On Thu, Nov 03, 2016 at 01:07:59AM +1030, Andrew Jeffery wrote:
> The System Control Unit IP block in the Aspeed SoCs is typically where
> the pinmux configuration is found, but not always. A number of pins
> depend on state in one of LPC Host Control (LPCHC) or SoC Display
> Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
> means to adjust these as necessary.
>
> We use syscon to cast a regmap over the GFX and LPCHCR blocks, which is
> used as an arbitration layer between the relevant driver and the pinctrl
> subsystem. The regmaps are then exposed to the SoC-specific pinctrl
> drivers by phandles in the devicetree, and are selected during a mux
> request by querying a new 'ip' member in struct aspeed_sig_desc.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Since v1:
>
> The change is now proactive: instead of reporting that we need to flip bits in
> controllers we can't access, the patch provides access via regmaps for the
> relevant controllers. The implementation also splits out the IP block ID into
> its own variable rather than packing the value into the upper bits of the reg
> member of struct aspeed_sig_desc. This drives some churn in the diff, but I've
> tried to minimise it.
>
> .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 50 +++++++++++++---
> drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 18 +++---
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 39 ++++++++++---
> drivers/pinctrl/aspeed/pinctrl-aspeed.c | 66 +++++++++++++---------
> drivers/pinctrl/aspeed/pinctrl-aspeed.h | 32 ++++++++---
> 5 files changed, 144 insertions(+), 61 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> index 2ad18c4ea55c..115b0cce6c1c 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> @@ -4,12 +4,19 @@ Aspeed Pin Controllers
> The Aspeed SoCs vary in functionality inside a generation but have a common mux
> device register layout.
>
> -Required properties:
> -- compatible : Should be any one of the following:
> - "aspeed,ast2400-pinctrl"
> - "aspeed,g4-pinctrl"
> - "aspeed,ast2500-pinctrl"
> - "aspeed,g5-pinctrl"
> +Required properties for g4:
> +- compatible : Should be any one of the following:
> + "aspeed,ast2400-pinctrl"
> + "aspeed,g4-pinctrl"
> +
> +Required properties for g5:
> +- compatible : Should be any one of the following:
> + "aspeed,ast2500-pinctrl"
> + "aspeed,g5-pinctrl"
> +
> +- aspeed,external-nodes: A cell of phandles to external controller nodes:
> + 0: compatible with "aspeed,ast2500-gfx", "syscon"
> + 1: compatible with "aspeed,ast2500-lpchc", "syscon"
>
> The pin controller node should be a child of a syscon node with the required
> property:
> @@ -47,7 +54,7 @@ RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU TIMER4 TIMER5 TIMER6
> TIMER7 TIMER8 VGABIOSROM
>
>
> -Examples:
> +g4 Example:
>
> syscon: scu@1e6e2000 {
> compatible = "syscon", "simple-mfd";
> @@ -63,5 +70,34 @@ syscon: scu@1e6e2000 {
> };
> };
>
> +g5 Example:
> +
> +apb {
> + gfx: display@1e6e6000 {
> + compatible = "aspeed,ast2500-gfx", "syscon";
> + reg = <0x1e6e6000 0x1000>;
> + };
> +
> + lpchc: lpchc@1e7890a0 {
> + compatible = "aspeed,ast2500-lpchc", "syscon";
> + reg = <0x1e7890a0 0xc4>;
> + };
> +
> + syscon: scu@1e6e2000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x1e6e2000 0x1a8>;
> +
> + pinctrl: pinctrl {
Why the single child node here? Doesn't look like any reason for it in
the example.
> + compatible = "aspeed,g5-pinctrl";
> + aspeed,external-nodes = <&gfx, &lpchc>;
> +
> + pinctrl_i2c3_default: i2c3_default {
> + function = "I2C3";
> + groups = "I2C3";
> + };
> + };
> + };
> +};
> +
> Please refer to pinctrl-bindings.txt in this directory for details of the
> common pinctrl bindings used by client devices.
^ permalink raw reply
* Re: [PATCH v2 2/6] mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Lee Jones, Linus Walleij, Joel Stanley, Mark Rutland, linux-gpio,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <1478097481-14895-3-git-send-email-andrew@aj.id.au>
On Thu, Nov 03, 2016 at 01:07:57AM +1030, Andrew Jeffery wrote:
> The Aspeed SoC Display Controller is presented as a syscon device to
> arbitrate access by display and pinmux drivers. Video pinmux
> configuration on fifth generation SoCs depends on bits in both the
> System Control Unit and the Display Controller.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++++++++++++++++
The register space can't be split to 2 nodes?
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> new file mode 100644
> index 000000000000..aea5370efd97
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> @@ -0,0 +1,17 @@
> +* Device tree bindings for Aspeed SoC Display Controller (GFX)
> +
> +The Aspeed SoC Display Controller primarily does as its name suggests, but also
> +participates in pinmux requests on the g5 SoCs. It is therefore considered a
> +syscon device.
> +
> +Required properties:
> +- compatible: "aspeed,ast2500-gfx", "syscon"
I think perhaps we should drop the syscon here and the driver should
just register as a syscon.
Rob
^ permalink raw reply
* Re: [PATCHv3 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, arnd-r2nGTMty4D4,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, geert-Td1EMuHUCqxL1ZNQvxDV9g,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478097178-24341-2-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
On Wed, Nov 02, 2016 at 09:32:55AM -0500, tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org wrote:
> From: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>
> Add the Arria10 DevKit System Resource Chip register and state
> monitoring module to the MFD.
>
> Signed-off-by: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
> ---
> Note: This needs to be applied to the bindings document that
> was Acked & Applied but didn't reach the for-next branch.
> See https://patchwork.ozlabs.org/patch/629397/
> ---
> v2 Change compatible string -mon to -monitor for clarity
> v3 Replace node name a10sr_monitor with just monitor.
> Replace node name a10sr_gpio with just gpio.
> ---
> Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
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: [PATCH v3 2/2] dt-bindings: net: Add OXNAS DWMAC Bindings
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Neil Armstrong
Cc: peppe.cavallaro, alexandre.torgue, netdev, linux-oxnas,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20161102140237.6955-3-narmstrong@baylibre.com>
On Wed, Nov 02, 2016 at 03:02:37PM +0100, Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/net/oxnas-dwmac.txt | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Andi Shyti, Mauro Carvalho Chehab, Sean Young, Mark Rutland,
Richard Purdie, linux-media, devicetree, linux-leds, linux-kernel
In-Reply-To: <70e31ed5-e1ec-cac3-3c3d-02c75f1418bd@samsung.com>
On Thu, Nov 03, 2016 at 11:39:21AM +0100, Jacek Anaszewski wrote:
> On 11/03/2016 11:10 AM, Andi Shyti wrote:
> > Hi Jacek,
> >
> > > Only DT bindings of LED class drivers should be placed in
> > > Documentation/devicetree/bindings/leds. Please move it to the
> > > media bindings.
> >
> > that's where I placed it first, but Rob asked me to put it in the
> > LED directory and Cc the LED mailining list.
> >
> > That's the discussion of the version 2:
> >
> > https://lkml.org/lkml/2016/9/12/380
> >
> > Rob, Jacek, could you please agree where I can put the binding?
>
> I'm not sure if this is a good approach. I've noticed also that
> backlight bindings have been moved to leds, whereas they don't look
> similarly.
>
> We have common.txt LED bindings, that all LED class drivers' bindings
> have to follow. Neither backlight bindings nor these ones do that,
> which introduces some mess.
And there are probably LED bindings that don't follow common.txt either.
> Eventually adding a sub-directory, e.g. remote_control could make it
> somehow logically justified, but still - shouldn't bindings be
> placed in the documentation directory related to the subsystem of the
> driver they are predestined to?
No. While binding directories often mirror the driver directories, they
are not the same. Bindings are grouped by types of h/w and IR LEDs are a
type of LED.
If you prefer a sub-dir, that is fine with me.
Rob
^ permalink raw reply
* Re: [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed, ast2400-ibt-bmc'
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Cédric Le Goater
Cc: devicetree, Corey Minyard, Arnd Bergmann, Joel Stanley,
openipmi-developer, linux-arm-kernel
In-Reply-To: <1478073426-3714-2-git-send-email-clg@kaod.org>
On Wed, Nov 02, 2016 at 08:57:04AM +0100, Cédric Le Goater wrote:
> The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
> other is H8S/2168 compliant.
>
> The current ipmi/bt-bmc driver implements the IPMI version and we
> should reflect its nature in the compatible node name using
> 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
> latter should be used for a H8S interface driver if it is implemented
> one day.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> .../ipmi/{aspeed,ast2400-bt-bmc.txt => aspeed,ast2400-ibt-bmc.txt} | 4 ++--
Acked-by: Rob Herring <robh@kernel.org>
> drivers/char/ipmi/bt-bmc.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
> rename Documentation/devicetree/bindings/ipmi/{aspeed,ast2400-bt-bmc.txt => aspeed,ast2400-ibt-bmc.txt} (85%)
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
^ permalink raw reply
* Re: [PATCH v2 4/9] regulator: lp873x: Add support for populating input supply
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Lokesh Vutla
Cc: Tony Lindgren, Linux OMAP Mailing List, Tero Kristo, Sekhar Nori,
Nishanth Menon, Device Tree Mailing List, Linux ARM Mailing List,
Lee Jones, Keerthy
In-Reply-To: <e5619d78-5752-c8fb-8a11-6629c4b7c3f6-l0cyMroinI0@public.gmane.org>
On Wed, Nov 02, 2016 at 10:58:40AM +0530, Lokesh Vutla wrote:
>
>
> On Monday 31 October 2016 02:11 AM, Rob Herring wrote:
> > On Fri, Oct 21, 2016 at 04:08:36PM +0530, Lokesh Vutla wrote:
> >> In order to have a proper topology of regulators for a platform, each
> >> registering regulator needs to populate supply_name field for identifying
> >> its supply's name. Add supply_name field for lp873x regulators.
> >>
> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> Cc: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
> >> Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
> >> ---
> >> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
> >> drivers/regulator/lp873x-regulator.c | 1 +
> >> 2 files changed, 9 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
> >> index 52766c2..998837a 100644
> >> --- a/Documentation/devicetree/bindings/mfd/lp873x.txt
> >> +++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
> >> @@ -7,6 +7,9 @@ Required properties:
> >> - #gpio-cells: Should be two. The first cell is the pin number and
> >> the second cell is used to specify flags.
> >> See ../gpio/gpio.txt for more information.
> >> + - xxx-in-supply: Phandle to parent supply node of each regulator
> >> + populated under regulators node. xxx should match
> >> + the supply_name populated in driver.
> >
> > The driver is irrelevant. This should reference a list in this document.
>
> okay. See if the below updated patch is fine.
>
> -----------------------------8<----------------------------8<----------------------------
> From 666f925423fa35c7bfcc77fa3c883cbea5d8ef8e Mon Sep 17 00:00:00 2001
> From: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
> Date: Wed, 21 Sep 2016 11:50:49 +0530
> Subject: [PATCH v3] regulator: lp873x: Add support for populating input
> supply
>
> In order to have a proper topology of regulators for a platform, each
> registering regulator needs to populate supply_name field for identifying
> its supply's name. Add supply_name field for lp873x regulators.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
> drivers/regulator/lp873x-regulator.c | 1 +
> 2 files changed, 9 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: [PATCH v4] Documentation: dtb: lm87: Add hwmon binding documentation.
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Mahoda Ratnayaka
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-hwmon-u79uwXL29TY76Z2rM5mHXA, Chris Packham
In-Reply-To: <20161102025804.9215-1-mahoda.ratnayaka-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
On Wed, Nov 02, 2016 at 03:58:04PM +1300, Mahoda Ratnayaka wrote:
> This patch adds lm87 hwmon device tree node documentation.
>
> Signed-off-by: Mahoda Ratnayaka <mahoda.ratnayaka-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
> ---
>
> Notes:
> Changes since v1:
> As suggested include all the changes are moved in
> to the same patch and the all the optional properties
> are now defined instead of using a single variable to
> indicate those properties.
>
> Changes since v2:
> Changed has-vcc-5v to use regulator binding and fixed
> a minor copy paste mistake.
>
> Changes since v3:
> Update the vcc-supply description.
>
> Documentation/devicetree/bindings/hwmon/lm87.txt | 30 ++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/lm87.txt
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: [PATCH v2 1/2] mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings document
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Scott Branden
Cc: Mark Rutland, devicetree, Ulf Hansson, Anup Patel, Scott Branden,
Ray Jui, linux-mmc, Adrian Hunter, linux-kernel,
BCM Kernel Feedback, linux-arm-kernel
In-Reply-To: <1478018277-10097-2-git-send-email-scott.branden@broadcom.com>
On Tue, Nov 01, 2016 at 09:37:56AM -0700, Scott Branden wrote:
> Adds brcm,sdhci-iproc compat string to DT bindings document for
> the iProc SDHCI driver.
>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> ---
> Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/3] binding: irqchip: mtk-cirq: Add binding document
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Youlin Pei
Cc: Marc Zyngier, Matthias Brugger, Thomas Gleixner, Jason Cooper,
Mark Rutland, Russell King, linux-kernel, devicetree,
linux-arm-kernel, linux-mediatek, srv_heupstream, hongkun.cao,
yong.wu, erin.lo, chieh-jay.liu
In-Reply-To: <1478001122-8664-2-git-send-email-youlin.pei@mediatek.com>
On Tue, Nov 01, 2016 at 07:52:00PM +0800, Youlin Pei wrote:
> This commit adds the device tree binding document for
> the mediatek cirq.
>
> Signed-off-by: Youlin Pei <youlin.pei@mediatek.com>
> ---
> .../interrupt-controller/mediatek,cirq.txt | 30 ++++++++++++++++++++
> 1 file changed, 30 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
> new file mode 100644
> index 0000000..84e8123
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
> @@ -0,0 +1,30 @@
> +* Mediatek 27xx cirq
> +
> +In Mediatek SOCs, the CIRQ is a low power interrupt controller designed to
> +works outside MCUSYS which comprises with Cortex-Ax cores,CCI and GIC.
s/works/work/
> +The external interrupts (outside MCUSYS) will feed through CIRQ and connect
> +to GIC in MCUSYS. When CIRQ is enabled, it will record the edge-sensitive
> +interrupts and generated a pulse signal to parent interrupt controller when
s/generated/generate/
> +flush command is executed. With CIRQ, MCUSYS can be completely turned off
> +to improve the system power consumption without losing interrupts.
> +
> +Required properties:
> +- compatible: should be: "mediatek,mtk-cirq".
This should be SoC specific. This is fine as a fallback if the same
block is in many SoCs, but mediatek and mtk is a bit redundant.
> +- interrupt-controller : Identifies the node as an interrupt controller.
> +- #interrupt-cells : Use the same format as specified by GIC in arm,gic.txt.
> +- interrupt-parent: phandle of irq parent for cirq. The parent must
> + use the same interrupt-cells format as GIC.
> +- reg: Physical base address of the cirq registers and length of memory
> + mapped region.
> +- mediatek,ext-irq-start: Identifies external irq start number in different
> + SOCs.
Wouldn't this always be 32 if the GIC is the parent? If 32 is the common
case, then use the SoC compatible to determine this value.
> +
> +Example:
> + cirq: interrupt-controller@10204000 {
> + compatible = "mediatek,mtk-cirq";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + interrupt-parent = <&sysirq>;
> + reg = <0 0x10204000 0 0x4000>;
> + mediatek,ext-irq-start = <32>;
> + };
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: devicetree: Add bindings info for rfkill-regulator
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Paul Cercueil
Cc: Johannes Berg, David S . Miller, Mark Rutland, netdev, devicetree,
linux-kernel, linux-wireless, Maarten ter Huurne
In-Reply-To: <20161101105840.24313-1-paul@crapouillou.net>
On Tue, Nov 01, 2016 at 11:58:39AM +0100, Paul Cercueil wrote:
> This document gives information about how to write a devicetree
> node that corresponds to the rfkill-regulator driver.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
> .../devicetree/bindings/net/rfkill-regulator.txt | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/rfkill-regulator.txt
>
> diff --git a/Documentation/devicetree/bindings/net/rfkill-regulator.txt b/Documentation/devicetree/bindings/net/rfkill-regulator.txt
> new file mode 100644
> index 0000000..aac2fe1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/rfkill-regulator.txt
> @@ -0,0 +1,18 @@
> +Device tree bindings for the rfkill-regulator driver
> +
> +Required properties:
> + - compatible: should be "rfkill-regulator"
> + - rfkill-name: the name of this rfkill device
> + - rfkill-type: the type of this rfkill device;
> + must correspond to a valid rfkill_type from <uapi/linux/rfkill.h>
> + - vrfkill-supply: phandle to a regulator
My understanding is it is generally felt that using the regulator enable
GPIO commonly found on WiFi chips for rfkill is an abuse of rfkill as it
is more that just an RF disable. From a DT standpoint, this seems like
creating a binding for what a Linux driver wants. Instead, I think this
should be either a GPIO or GPIO regulator and the driver for the WiFi
chip should decide whether or not to register that as an rfkill driver.
Rob
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Neil Armstrong
Cc: f.fainelli, khilman, carlo, andrew, netdev, linux-amlogic,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <1477932987-27871-2-git-send-email-narmstrong@baylibre.com>
On Mon, Oct 31, 2016 at 05:56:23PM +0100, Neil Armstrong wrote:
> In order to support PHY switching on Amlogic GXL SoCs, add support for
> 16bit and 32bit registers sizes.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/net/mdio-mux-mmioreg.txt | 4 +-
> drivers/net/phy/mdio-mux-mmioreg.c | 60 +++++++++++++++++-----
> 2 files changed, 49 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
> index 8516929..065e8bd 100644
> --- a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
> +++ b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
> @@ -3,7 +3,7 @@ Properties for an MDIO bus multiplexer controlled by a memory-mapped device
> This is a special case of a MDIO bus multiplexer. A memory-mapped device,
> like an FPGA, is used to control which child bus is connected. The mdio-mux
> node must be a child of the memory-mapped device. The driver currently only
As you're touching this sentence, this describes the binding, not a
driver. With that,
Acked-by: Rob Herring <robh@kernel.org>
> -supports devices with eight-bit registers.
> +supports devices with 8, 16 or 32-bit registers.
>
> Required properties in addition to the generic multiplexer properties:
>
> @@ -11,7 +11,7 @@ Required properties in addition to the generic multiplexer properties:
>
> - reg : integer, contains the offset of the register that controls the bus
> multiplexer. The size field in the 'reg' property is the size of
> - register, and must therefore be 1.
> + register, and must therefore be 1, 2, or 4.
>
> - mux-mask : integer, contains an eight-bit mask that specifies which
> bits in the register control the actual bus multiplexer. The
^ permalink raw reply
* Re: [PATCH V3 3/9] Documentation: devicetree: thermal: da9062/61 TJUNC temperature binding
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, Eduardo Valentin, LINUX-KERNEL, LINUX-PM,
Mark Rutland, Zhang Rui, Dmitry Torokhov, Guenter Roeck,
LINUX-INPUT, LINUX-WATCHDOG, Lee Jones, Liam Girdwood, Mark Brown,
Support Opensource, Wim Van Sebroeck
In-Reply-To: <318faafc8021e6adc683e62d57b8c031b9212e0f.1477929725.git.stwiss.opensource@diasemi.com>
On Mon, Oct 31, 2016 at 04:02:03PM +0000, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> Device tree binding information for DA9062 and DA9061 thermal junction
> temperature monitor.
>
> Binding descriptions for the DA9061 and DA9062 thermal TJUNC supervisor
> device driver, using a single THERMAL_TRIP_HOT trip-wire and allowing for
> a configurable polling period for over-temperature polling.
>
> This patch also adds two examples, one for DA9062 and one for DA9061. The
> DA9061 example uses a fall-back compatible string for the DA9062.
>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH V3 4/9] Documentation: devicetree: mfd: da9062/61 MFD binding
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, LINUX-INPUT, LINUX-KERNEL, Mark Rutland,
Dmitry Torokhov, Eduardo Valentin, Guenter Roeck, LINUX-PM,
LINUX-WATCHDOG, Lee Jones, Liam Girdwood, Mark Brown,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <502d13b97c67023f2193abfa235e8884eb0ea02f.1477929725.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
On Mon, Oct 31, 2016 at 04:02:03PM +0000, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
>
> Extend existing DA9062 binding information to include the DA9061 PMIC for
> MFD core and regulators.
>
> Add a da9062-onkey link to the existing onkey binding file.
>
> Add a da9062-thermal link to the new temperature monitoring binding file.
>
> Delete the da9062-watchdog section and replace it with a link to the new
> DA9061/62 binding information file.
>
> Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" 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 V3 2/9] Documentation: devicetree: watchdog: da9062/61 watchdog timer binding
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, Guenter Roeck, LINUX-KERNEL, LINUX-WATCHDOG,
Mark Rutland, Wim Van Sebroeck, Dmitry Torokhov, Eduardo Valentin,
LINUX-INPUT, LINUX-PM, Lee Jones, Liam Girdwood, Mark Brown,
Support Opensource, Zhang Rui
In-Reply-To: <35578f27515c2abc1780823829ebab467543548c.1477929725.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
On Mon, Oct 31, 2016 at 04:02:03PM +0000, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
>
> Add binding information for DA9062 and DA9061 watchdog.
>
> Example bindings for both DA9062 and DA9061 devices are added. For
> the DA9061 device, a fallback compatible line is added as a valid
> combination of compatible strings.
>
> The original binding for DA9062 (only) used to reside inside the
> Documentation/devicetree/bindings/mfd/da9062.txt MFD document.
> The da9062-watchdog section was deleted in that file and replaced
> with a link to the new DA9061/62 binding information stored in this
> patch.
>
> Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" 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 V3 1/9] Documentation: devicetree: input: additions for da9061 onkey driver
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, Dmitry Torokhov, LINUX-INPUT, LINUX-KERNEL,
Mark Rutland, Eduardo Valentin, Guenter Roeck, LINUX-PM,
LINUX-WATCHDOG, Lee Jones, Liam Girdwood, Mark Brown,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <48abf6ce51f8ef02421ea2dd4f4e309b440efc85.1477929725.git.stwiss.opensource@diasemi.com>
On Mon, Oct 31, 2016 at 04:02:02PM +0000, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> Add binding information for DA9061 onkey.
>
> This patch updates the compatible string "dlg,da9061-onkey" to support
> DA9061, removes the reference to KEY_SLEEP (which the driver no longer
> supports) and fixes a typo in the example for DA9063.
>
> Supporting KEY_SLEEP was not the general convention and the typical
> solution should have been for KEY_POWER to support both cases of suspend
> and S/W power off. This change was sent to the DA9063 ONKEY device
> driver in a separate patch, but the documentation was not updated at
> that time.
> - f889bea Report KEY_POWER instead of KEY_SLEEP during power key-press
>
> This patch also adds two new examples, one for DA9062 and one for DA9061.
> The DA9061 examples uses a fall-back compatible string for the DA9062
> onkey driver.
>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
>
> ---
> This patch applies against linux-next and v4.8
>
> v2 -> v3
> - Patch renamed from [PATCH V2 01/10] to [PATCH V3 1/9]
> - Each compatible line should be a valid combination of compatible
> strings, alter DA9061 line to include the fall back compatible string
> - Update the commit message to include KEY_SLEEP removal explanation and
> a link back to the original device driver commit. This will allow full
> traceability back to the original patch change
> - Link in information about associated patches from this set without
> describing them as being explicitly dependent on this binding
>
> v1 -> v2
> - Patch renamed from [PATCH V1 06/10] to [PATCH V2 01/10] -- these
> changes were made to fix checkpatch warnings caused by the patch
> set dependency order
> - Typo s/ther/the/ in commit message
> - Explanation about why KEY_SLEEP was removed (see below)
> - Addition of DA9062 example
> - Addition of a DA9061 example to follow the driver fall-back compatible
> convention being applied for this device driver
>
> Hi,
>
> There is also new binding examples for DA9062 and DA9061. Importantly,
> the Linux device driver changes for DA9061 were rejected because the
> DA9062 device driver can be reused. For this reason, the DA9061 example
> uses a fall-back compatible string.
>
> Other information:
> The device driver from this patch set (associated with this binding) was
> applied by Dmitry Torokhov on 26-Oct-2016. See:
> - [PATCH V2 07/10] Input: da9061: onkey driver.
> - https://lkml.org/lkml/2016/10/26/1169
>
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
>
>
> .../devicetree/bindings/input/da9062-onkey.txt | 45 ++++++++++++++--------
> 1 file changed, 30 insertions(+), 15 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v7 3/3] clk: qcom: Add A53 clock driver
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Georgi Djakov
Cc: sboyd-sgV2jX0FEOL9JmXXK+q4OQ, mturquette-rdvid1DuHRBWk0Htik3J/w,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161031145526.5023-4-georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, Oct 31, 2016 at 04:55:26PM +0200, Georgi Djakov wrote:
> Add a driver for the A53 Clock Controller. It is a hardware block that
> implements a combined mux and half integer divider functionality. It can
> choose between a fixed-rate clock or the dedicated A53 PLL. The source
> and the divider can be set both at the same time.
>
> This is required for enabling CPU frequency scaling on platforms like
> MSM8916.
>
> Signed-off-by: Georgi Djakov <georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/clock/qcom,a53cc.txt | 23 ++++
> drivers/clk/qcom/Kconfig | 8 ++
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/a53cc.c | 152 +++++++++++++++++++++
> 4 files changed, 184 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> create mode 100644 drivers/clk/qcom/a53cc.c
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,a53cc.txt b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> new file mode 100644
> index 000000000000..82d1634a2713
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> @@ -0,0 +1,23 @@
> +Qualcomm A53 CPU Clock Controller Binding
> +------------------------------------------------
> +The A53 CPU Clock Controller is hardware, which provides a combined
> +mux and divider functionality for the CPU clocks. It can choose between
> +a fixed rate clock and the dedicated A53 PLL. This hardware block is used
> +on platforms such as msm8916.
> +
> +Required properties :
> +- compatible : shall contain:
> +
> + "qcom,a53cc-msm8916"
Same comment on the ordering. With that, for the binding:
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> +
> +- reg : shall contain base register location and length
> + of the APCS region
> +- #clock-cells : shall contain 1
> +
> +Example:
> +
> + apcs: syscon@b011000 {
> + compatible = "qcom,a53cc-msm8916";
> + reg = <0x0b011000 0x1000>;
> + #clock-cells = <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 v7 1/3] clk: qcom: Add A53 PLL support
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Georgi Djakov
Cc: sboyd, mturquette, linux-clk, devicetree, mark.rutland,
linux-kernel, linux-arm-msm
In-Reply-To: <20161031145526.5023-2-georgi.djakov@linaro.org>
On Mon, Oct 31, 2016 at 04:55:24PM +0200, Georgi Djakov wrote:
> Add support for the PLL, which generates the higher range of CPU
> frequencies on MSM8916 platforms.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> .../devicetree/bindings/clock/qcom,a53pll.txt | 20 +++++
> drivers/clk/qcom/Kconfig | 9 +++
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/a53-pll.c | 94 ++++++++++++++++++++++
> 4 files changed, 124 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53pll.txt
> create mode 100644 drivers/clk/qcom/a53-pll.c
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.txt b/Documentation/devicetree/bindings/clock/qcom,a53pll.txt
> new file mode 100644
> index 000000000000..6a8c03bfbcb5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.txt
> @@ -0,0 +1,20 @@
> +MSM8916 A53 PLL Binding
> +---------------
> +The A53 PLL on MSM8916 platforms is the main CPU PLL used for frequencies
> +above 1GHz.
> +
> +Required properties :
> +- compatible : Shall contain only one of the following:
> +
> + "qcom,a53pll-msm8916"
Generally, the ordering is <vendor>,<soc>-<block>.
> +
> +- reg : shall contain base register location and length
> +- #clock-cells : must be set to <0>
> +
> +Example:
> +
> + a53pll: a53pll@b016000 {
clock@...
> + compatible = "qcom,a53pll-msm8916";
> + reg = <0x0b016000 0x40>;
> + #clock-cells = <0>;
> + };
^ permalink raw reply
* Re: [PATCH v2 2/5] ARM: bus: da8xx-mstpri: new driver
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Mark Rutland, linux-devicetree, Kevin Hilman, Michael Turquette,
Sekhar Nori, Russell King, linux-drm, LKML, Peter Ujfalusi,
Tomi Valkeinen, Jyri Sarha, Frank Rowand, arm-soc,
Laurent Pinchart
In-Reply-To: <1477925138-23457-3-git-send-email-bgolaszewski@baylibre.com>
On Mon, Oct 31, 2016 at 03:45:35PM +0100, Bartosz Golaszewski wrote:
> Create the driver for the da8xx master peripheral priority
> configuration and implement support for writing to the three
> Master Priority registers on da850 SoCs.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/bus/Kconfig | 9 +
> drivers/bus/Makefile | 2 +
> drivers/bus/da8xx-mstpri.c | 269 +++++++++++++++++++++
> 4 files changed, 300 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
> create mode 100644 drivers/bus/da8xx-mstpri.c
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Mark Rutland, linux-devicetree, Kevin Hilman, Michael Turquette,
Sekhar Nori, Russell King, linux-drm, LKML, Peter Ujfalusi,
Tomi Valkeinen, Jyri Sarha, Frank Rowand, arm-soc,
Laurent Pinchart
In-Reply-To: <1477925138-23457-2-git-send-email-bgolaszewski@baylibre.com>
On Mon, Oct 31, 2016 at 03:45:34PM +0100, Bartosz Golaszewski wrote:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> .../memory-controllers/ti-da8xx-ddrctl.txt | 20 +++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/memory/Kconfig | 8 +
> drivers/memory/Makefile | 1 +
> drivers/memory/da8xx-ddrctl.c | 175 +++++++++++++++++++++
> 4 files changed, 204 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> create mode 100644 drivers/memory/da8xx-ddrctl.c
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 5/7] ARM: shmobile: Document DT bindings for CCCR and PRR
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Rutland, devicetree, Dirk Behme, Arnd Bergmann,
Greg Kroah-Hartman, Magnus Damm, linux-kernel, linux-renesas-soc,
Simon Horman, Yangbo Lu, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1477913455-5314-6-git-send-email-geert+renesas@glider.be>
On Mon, Oct 31, 2016 at 12:30:53PM +0100, Geert Uytterhoeven wrote:
> Add device tree binding documentation for the Common Chip Code Register
> and Product Register, which provide SoC product and revision
> information.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2:
> - New.
> ---
> Documentation/devicetree/bindings/arm/shmobile.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Ulf Hansson, Adrian Hunter, linux-mmc, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, devicetree, Thomas Petazzoni,
linux-arm-kernel, Ziji Hu, Jack(SH) Zhu, Jimmy Xu, Jisheng Zhang,
Nadav Haklai, Ryan Gao, Doug Jones, Shiwu Zhang, Victor Gu,
Wei(SOCP) Liu, Wilson Ding, Xueping Liu, Hilbert
In-Reply-To: <ee296deafdcbeb431a592b591ae38a758ba4cce7.1477911954.git-series.gregory.clement@free-electrons.com>
On Mon, Oct 31, 2016 at 12:09:54PM +0100, Gregory CLEMENT wrote:
> From: Ziji Hu <huziji@marvell.com>
>
> Marvell Xenon SDHC can support eMMC/SD/SDIO.
> Add Xenon-specific properties.
> Also add properties for Xenon PHY setting.
>
> Signed-off-by: Hu Ziji <huziji@marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 161 +++++++-
> MAINTAINERS | 1 +-
> 2 files changed, 162 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> new file mode 100644
> index 000000000000..0d2d139494d3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> @@ -0,0 +1,161 @@
> +Marvell's Xenon SDHCI Controller device tree bindings
> +This file documents differences between the core mmc properties
> +described by mmc.txt and the properties used by the Xenon implementation.
> +
> +A single Xenon IP can support multiple slots.
> +Each slot acts as an independent SDHC. It owns independent resources, such
> +as register sets clock and PHY.
> +Each slot should have an independent device tree node.
> +
> +Required Properties:
> +- compatible: should be one of the following
> + - "marvell,armada-3700-sdhci": For controllers on Armada-3700 SOC.
> + Must provide a second register area and marvell,pad-type.
> + - "marvell,xenon-sdhci": For controllers on all the SOCs, other than
> + Armada-3700.
Need SoC specific compatible strings.
> +
> +- clocks:
> + Array of clocks required for SDHCI.
> + Requires at least one for Xenon IP core.
> + Some SOCs require additional clock for AXI bus.
> +
> +- clock-names:
> + Array of names corresponding to clocks property.
> + The input clock for Xenon IP core should be named as "core".
> + The optional AXI clock should be named as "axi".
When is AXI clock optional? This should be required for ?? compatible
strings.
> +
> +- reg:
> + * For "marvell,xenon-sdhci", one register area for Xenon IP.
> +
> + * For "marvell,armada-3700-sdhci", two register areas.
> + The first one for Xenon IP register. The second one for the Armada 3700 SOC
> + PHY PAD Voltage Control register.
> + Please follow the examples with compatible "marvell,armada-3700-sdhci"
> + in below.
> + Please also check property marvell,pad-type in below.
> +
> +Optional Properties:
> +- marvell,xenon-slotno:
Multiple slots should be represented as child nodes IMO. I think some
other bindings already do this.
> + Indicate the corresponding bit index of current Xenon SDHC slot in
> + SDHC System Operation Control Register Bit[7:0].
> + Set/clear the corresponding bit to enable/disable current Xenon SDHC
> + slot.
> + If this property is not provided, Xenon IP should contain only one
> + slot.
> +
> +- marvell,xenon-phy-type:
> + Xenon support mutilple types of PHYs.
> + To select eMMC 5.1 PHY, set:
> + marvell,xenon-phy-type = "emmc 5.1 phy"
> + eMMC 5.1 PHY is the default choice if this property is not provided.
> + To select eMMC 5.0 PHY, set:
> + marvell,xenon-phy-type = "emmc 5.0 phy"
> + To select SDH PHY, set:
> + marvell,xenon-phy-type = "sdh phy"
> + Please note that eMMC PHY is a general PHY for eMMC/SD/SDIO, other than for
> + eMMC only.
Does this vary per instance on a single SoC? If not, then an SoC
specific compatible should determine this.
Also, the " phy" part is redundant.
> +
> +- marvell,xenon-phy-znr:
> + Set PHY ZNR value.
> + Only available for eMMC PHY 5.1 and eMMC PHY 5.0.
> + valid range = [0:0x1F].
> + ZNR is set as 0xF by default if this property is not provided.
> +
> +- marvell,xenon-phy-zpr:
> + Set PHY ZPR value.
> + Only available for eMMC PHY 5.1 and eMMC PHY 5.0.
> + valid range = [0:0x1F].
> + ZPR is set as 0xF by default if this property is not provided.
> +
> +- marvell,xenon-phy-nr-success-tun:
> + Set the number of required consecutive successful sampling points used to
> + identify a valid sampling window, in tuning process.
> + Valid range = [1:7]. Set as 0x4 by default if this property is not provided.
> +
> +- marvell,xenon-phy-tun-step-divider:
> + Set the divider for calculating TUN_STEP.
> + Set as 64 by default if this property is not provided.
> +
> +- marvell,xenon-phy-slow-mode:
> + Force PHY into slow mode.
> + Only available when bus frequency lower than 50MHz in SDR mde.
> + Disabled by default. Please do not enable it unless it is necessary.
> +
> +- marvell,xenon-mask-conflict-err:
> + Mask Conflict Error alert on some SOC. Disabled by default.
> +
> +- marvell,xenon-tun-count:
> + Xenon SDHC SOC usually doesn't provide re-tuning counter in
> + Capabilities Register 3 Bit[11:8].
> + This property provides the re-tuning counter.
> + If this property is not set, default re-tuning counter will
> + be set as 0x9 in driver.
> +
> +- marvell,pad-type:
> + Type of Armada 3700 SOC PHY PAD Voltiage Controller register.
> + Only valid when "marvell,armada-3700-sdhci" is selected.
> + Two types: "sd" and "fixed-1-8v".
> + If "sd" is slected, SOC PHY PAD is set as 3.3V at the beginning and is
> + switched to 1.8V when SD in UHS-I.
> + If "fixed-1-8v" is slected, SOC PHY PAD is fixed 1.8V, such as for eMMC.
> + Please follow the examples with compatible "marvell,armada-3700-sdhci"
> + in below.
> +
> +Example:
> +- For eMMC slot:
> +
> + sdhci@aa0000 {
> + compatible = "marvell,xenon-sdhci";
> + reg = <0xaa0000 0x1000>;
> + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>
> + clocks = <&emmc_clk>, <&axi_clock>;
> + clock-names = "core", "axi";
> + bus-width = <8>;
> + marvell,xenon-emmc;
Not documented. If we need to specify the type of slot/card, then we
need to come up with a standard property. This was either already done
or attempted IIRC.
> + marvell,xenon-slotno = <0>;
> + marvell,xenon-phy-type = "emmc 5.1 phy";
> + marvell,xenon-tun-count = <11>;
> + };
> +
> +- For SD/SDIO slot:
> +
> + sdhci@ab0000 {
> + compatible = "marvell,xenon-sdhci";
> + reg = <0xab0000 0x1000>;
> + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>
> + vqmmc-supply = <&sd_regulator>;
> + clocks = <&sdclk>;
> + clock-names = "core";
> + bus-width = <4>;
> + marvell,xenon-tun-count = <9>;
> + };
> +
> +- For eMMC slot with compatible "marvell,armada-3700-sdhci":
> +
> + sdhci@aa0000 {
> + compatible = "marvell,armada-3700-sdhci";
> + reg = <0xaa0000 0x1000>,
> + <phy_addr 0x4>;
> + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>
> + clocks = <&emmcclk>;
> + clock-names = "core";
> + bus-width = <8>;
> + marvell,xenon-emmc;
> +
> + marvell,pad-type = "fixed-1-8v";
> + };
> +
> +- For SD/SDIO slot with compatible "marvell,armada-3700-sdhci":
> +
> + sdhci@ab0000 {
> + compatible = "marvell,armada-3700-sdhci";
> + reg = <0xab0000 0x1000>,
> + <phy_addr 0x4>;
> + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>
> + vqmmc-supply = <&sd_regulator>;
> + clocks = <&sdclk>;
> + clock-names = "core";
> + bus-width = <4>;
> +
> + marvell,pad-type = "sd";
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1a5c4c30ea24..850a0afb0c8d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7608,6 +7608,7 @@ MARVELL XENON MMC/SD/SDIO HOST CONTROLLER DRIVER
> M: Ziji Hu <huziji@marvell.com>
> L: linux-mmc@vger.kernel.org
> S: Supported
> +F: Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
>
> MATROX FRAMEBUFFER DRIVER
> L: linux-fbdev@vger.kernel.org
> --
> git-series 0.8.10
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: synopsys-dw-mshc: add binding for reset-names
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
john.stultz-QSEj5FYQhm4dnm+yROfE0A,
guodong.xu-QSEj5FYQhm4dnm+yROfE0A, leo.yan-QSEj5FYQhm4dnm+yROfE0A,
vincent.guittot-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <20161031024942.4415-2-jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Mon, Oct 31, 2016 at 11:49:41AM +0900, Jaehoon Chung wrote:
> Add reset-names property for binding dw-mmc controller.
> It might be used together with "reset" property.
> - Note: It must be "reset" as name.
>
> Fixes: d6786fefe816 ("mmc: dw_mmc: add reset support to dwmmc host controller")
>
> Signed-off-by: Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> index 4e00e85..bfa461a 100644
> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> @@ -43,6 +43,9 @@ Optional properties:
> reset signal present internally in some host controller IC designs.
> See Documentation/devicetree/bindings/reset/reset.txt for details.
>
> +* reset-names: request name for using "resets" property. Must be "reset".
> + (It will be used together with "resets" property.)
There is no point in having names for a single reset. This should be
fixed in the kernel only if this causes a problem.
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 V3 8/9] thermal: da9062/61: Thermal junction temperature monitoring driver
From: Steve Twiss @ 2016-11-09 18:20 UTC (permalink / raw)
To: Lukasz Luba, Eduardo Valentin, LINUX-KERNEL, LINUX-PM, Zhang Rui
Cc: DEVICETREE, Dmitry Torokhov, Guenter Roeck, LINUX-INPUT,
LINUX-WATCHDOG, Lee Jones, Liam Girdwood, Mark Brown,
Mark Rutland, Rob Herring, Support Opensource, Wim Van Sebroeck
In-Reply-To: <b5789f09-0053-f0fc-ee35-c8c32969852b@arm.com>
On 02 November 2016 13:29, Lukasz Luba wrote:
[...]
> Apart from these 2 comments, 10sec is not to long
> (waiting for the temperature change)?
Hi Lukasz,
Are you saying the maximum polling time is too long or too short if it
is fixed in the driver at 10 seconds?
Certainly 10 seconds can be seen as either too long or too short a time
when waiting for the temperature to fall-back below a threshold.
But, this maximum polling time will be application dependent I think.
However, this is a repeated polling event notifying of a warning
over-temperature condition, so, it is already known that the
temperature is above the threshold and action should already be
in progress to reduce the temperature.
#define DA9062_DEFAULT_POLLING_MS_PERIOD 3000
#define DA9062_MAX_POLLING_MS_PERIOD 10000
#define DA9062_MIN_POLLING_MS_PERIOD 1000
The TEMP_WARN first level temperature supervision is intended for
non-invasive temperature controlling measures for cooling the system
and are left to the host software. This first level temperature
TEMP_WARN (125 degC) is only +15degC off the next TEMP_CRIT
(140 degC) temperature threshold. And this TEMP_CRIT is where
the hardware will automatically shutdown.
I suppose it all depends on how fast the temperature is expected to
rise and fall.
In any case, this 10 second polling maximum value was provided as part
of guidance from a specific solution with this hardware. It would be expected
that any final implementation will also include a notify() function and any
of these settings could be altered to match the application where
appropriate.
I've added a comment above these defined variables for the next code
patch.
> On 31/10/16 16:02, Steve Twiss wrote:
> > From: Steve Twiss <stwiss.opensource@diasemi.com>
> >
> > +static int da9062_thermal_probe(struct platform_device *pdev)
> > +{
> > + struct da9062 *chip = dev_get_drvdata(pdev->dev.parent);
> > + struct da9062_thermal *thermal;
> > + unsigned int pp_tmp = DA9062_DEFAULT_POLLING_MS_PERIOD;
> > + const struct of_device_id *match;
> > + int ret = 0;
> > +
> > + match = of_match_node(da9062_compatible_reg_id_table,
> > + pdev->dev.of_node);
> > + if (!match)
> > + return -ENXIO;
> > +
> > + if (pdev->dev.of_node) {
> > + if (!of_property_read_u32(pdev->dev.of_node,
> > + "dlg,tjunc-temp-polling-period-ms",
> > + &pp_tmp)) {
> > + if (pp_tmp < DA9062_MIN_POLLING_MS_PERIOD ||
> > + pp_tmp > DA9062_MAX_POLLING_MS_PERIOD)
> > + pp_tmp = DA9062_DEFAULT_POLLING_MS_PERIOD;
>
> Maybe it's worth to add some print here just to mention about
> the DT value out of range. When you saw a dmesg with
> this print on some bug report, you would know about wrong DT entry
> (even if debug was not set).
I can add a dev_warn() here explaining the invalid configuration.
[...]
> > +static int da9062_thermal_remove(struct platform_device *pdev)
> > +{
> > + struct da9062_thermal *thermal = platform_get_drvdata(pdev);
> > +
> > + free_irq(thermal->irq, thermal);
> > + thermal_zone_device_unregister(thermal->zone);
> > + cancel_delayed_work_sync(&thermal->work);
>
> You should change the order for these two functions
> and cancel the work before unregistering thermal zone device.
ok
Regards,
Steve
^ 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