* Re: [PATCH v2] soc: qcom: smp2p: Access APCS as mailbox client
From: Bjorn Andersson @ 2017-12-04 20:18 UTC (permalink / raw)
To: Rob Herring
Cc: Andy Gross, David Brown, Mark Rutland,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Arun Kumar Neelakantam
In-Reply-To: <20171201222545.hkp73cuou6aildky@rob-hp-laptop>
On Fri 01 Dec 14:25 PST 2017, Rob Herring wrote:
> On Wed, Nov 29, 2017 at 04:00:40PM -0800, Bjorn Andersson wrote:
> > Attempt to acquire the APCS IPC through the mailbox framework and fall
> > back to the old syscon based approach, to allow us to move away from
> > using the syscon.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
> >
> > Changes since v1:
> > - Added dt binding update
> > - Specifies knows_txdone on the mailbox client
> >
> > .../devicetree/bindings/soc/qcom/qcom,smp2p.txt | 8 ++++-
> > drivers/soc/qcom/Kconfig | 1 +
> > drivers/soc/qcom/smp2p.c | 39 ++++++++++++++++++----
> > 3 files changed, 41 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt
> > index af9ca37221ce..a35af2dafdad 100644
> > --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt
> > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt
> > @@ -17,9 +17,15 @@ processor ID) and a string identifier.
> > Value type: <prop-encoded-array>
> > Definition: one entry specifying the smp2p notification interrupt
> >
> > -- qcom,ipc:
> > +- mboxes:
> > Usage: required
> > Value type: <prop-encoded-array>
> > + Definition: reference to the associated doorbell in APCS, as described
> > + in mailbox/mailbox.txt
> > +
> > +- qcom,ipc:
> > + Usage: required, unless mboxes is specified
>
> Is this deprecated as mboxes is required, so it's never present?
>
Right, this required property "mboxes" replaces the previously required
property "qcom,ipc". This comes from migrating the description of APCS
as a syscon to a mailbox/doorbell.
Regards,
Bjorn
> > + Value type: <prop-encoded-array>
> > Definition: three entries specifying the outgoing ipc bit used for
> > signaling the remote end of the smp2p edge:
> > - phandle to a syscon node representing the apcs registers
--
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 v6 1/2] media: ov7740: Document device tree bindings
From: Rob Herring @ 2017-12-04 20:24 UTC (permalink / raw)
To: Wenyou Yang
Cc: Mauro Carvalho Chehab, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Nicolas Ferre,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sakari Ailus, Jonathan Corbet,
Hans Verkuil, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Linux Media Mailing List
In-Reply-To: <20171204065858.3138-2-wenyou.yang-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
On Mon, Dec 04, 2017 at 02:58:57PM +0800, Wenyou Yang wrote:
> Add the device tree binding documentation for the ov7740 sensor driver.
>
> Signed-off-by: Wenyou Yang <wenyou.yang-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Explicitly document the "remote-endpoint" property.
>
> Changes in v2: None
>
> .../devicetree/bindings/media/i2c/ov7740.txt | 47 ++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt
Please add acks when posting new versions.
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 1/3] dt-bindings: hwrng: Add Samsung Exynos 5250+ True RNG bindings
From: Rob Herring @ 2017-12-04 20:27 UTC (permalink / raw)
To: Łukasz Stelmach
Cc: Andrew F . Davis, PrasannaKumar Muralidharan, Matt Mackall,
Herbert Xu, Krzysztof Kozlowski, Kukjin Kim, devicetree,
linux-crypto, linux-samsung-soc, linux-kernel, Marek Szyprowski,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20171204125351.26805-2-l.stelmach@samsung.com>
On Mon, Dec 04, 2017 at 01:53:49PM +0100, Łukasz Stelmach wrote:
> Add binding documentation for the True Random Number Generator
> found on Samsung Exynos 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
> ---
> .../devicetree/bindings/rng/samsung,exynos5250-trng.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt
I acked v1 (and so did Krzysztof). You added them in v2, but
dropped here?
^ permalink raw reply
* Re: [PATCH V7 2/2] dt-bindings: Add qcom spmi_pmic clock divider bindings
From: Rob Herring @ 2017-12-04 20:29 UTC (permalink / raw)
To: Tirupathi Reddy
Cc: sboyd, mturquette, mark.rutland, andy.gross, david.brown,
linux-clk, devicetree, linux-kernel, linux-arm-msm, linux-soc
In-Reply-To: <1511255465-3984-3-git-send-email-tirupath@codeaurora.org>
On Tue, Nov 21, 2017 at 02:41:05PM +0530, Tirupathi Reddy wrote:
> This patch adds device tree bindings for Qualcomm SPMI PMIC
> clock divider module.
>
> Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
> ---
> .../bindings/clock/qcom,spmi-pmic-div.txt | 59 ++++++++++++++++++++++
Didn't Stephen say to move this somewhere else?
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,spmi-pmic-div.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,spmi-pmic-div.txt b/Documentation/devicetree/bindings/clock/qcom,spmi-pmic-div.txt
> new file mode 100644
> index 0000000..2cf2aba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/qcom,spmi-pmic-div.txt
> @@ -0,0 +1,59 @@
> +Qualcomm Technologies, Inc. SPMI PMIC clock divider (clkdiv)
> +
> +clkdiv configures the clock frequency of a set of outputs on the PMIC.
> +These clocks are typically wired through alternate functions on
> +gpio pins.
> +
> +=======================
> +Properties
> +=======================
> +
> +- compatible
> + Usage: required
> + Value type: <string>
> + Definition: must be "qcom,spmi-clkdiv".
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: base address of CLKDIV peripherals.
> +
> +- qcom,num-clkdivs
> + Usage: required
> + Value type: <u32>
> + Definition: number of CLKDIV peripherals.
> +
> +- clocks:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: reference to the xo clock.
> +
> +- clock-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be "xo".
> +
> +- clock-cells:
#clock-cells
> + Usage: required
> + Value type: <u32>
> + Definition: shall contain 1.
> +
> +=======
> +Example
> +=======
> +
> +pm8998_clk_divs: clock-controller@5b00 {
> + compatible = "qcom,spmi-clkdiv";
> + reg = <0x5b00>;
> + #clock-cells = <1>;
> + qcom,num-clkdivs = <3>;
> + clocks = <&xo_board>;
> + clock-names = "xo";
> +
> + assigned-clocks = <&pm8998_clk_divs 1>,
> + <&pm8998_clk_divs 2>,
> + <&pm8998_clk_divs 3>;
> + assigned-clock-rates = <9600000>,
> + <9600000>,
> + <9600000>;
> +};
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>
^ permalink raw reply
* Re: [PATCH][v3] dt-bindings: ifc: Update endianness usage
From: Rob Herring @ 2017-12-04 20:47 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1512029196-7158-1-git-send-email-prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
On Thu, Nov 30, 2017 at 01:36:36PM +0530, Prabhakar Kushwaha wrote:
> IFC controller version < 2.0 support IFC register access as
> big endian. These controller version also require IFC NOR signals to
> be connected in reverse order with NOR flash.
>
> IFC >= 2.0 is other way around.
>
> So updating IFC binding to take care of both using endianness field.
>
> Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> ---
> Changes for v2: updated subject
> Changes for v3: fixed typo for "big-endian"
>
> Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> index 89427b0..824a2ca 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> @@ -18,8 +18,10 @@ Properties:
> interrupt (NAND_EVTER_STAT). If there is only one,
> that interrupt reports both types of event.
>
> -- little-endian : If this property is absent, the big-endian mode will
> - be in use as default for registers.
> +- little-endian or big-endian : It represents how IFC registers to be accessed.
> + It also represents connection between controller and
> + NOR flash. If this property is absent, the big-endian
> + mode will be in use as default.
My question on the prior version remains. I think if you need to handle
more than just register endianness, that should be done with the
compatible string.
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] eeprom: at25: Add DT support for EEPROMs with odd address bits
From: Rob Herring @ 2017-12-04 21:17 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ivo Sieben, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Chris Wright, Wolfram Sang, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdWczQ0KiH7soGLKxX8CQEwxA=kVDc_saYqgytE2U_3WKw@mail.gmail.com>
On Mon, Dec 04, 2017 at 10:17:47AM +0100, Geert Uytterhoeven wrote:
> On Thu, Nov 30, 2017 at 2:29 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > Certain EEPROMS have a size that is larger than the number of address
> > bytes would allow, and store the MSB of the address in bit 3 of the
> > instruction byte.
> >
> > This can be described in platform data using EE_INSTR_BIT3_IS_ADDR, or
> > in DT using the obsolete legacy "at25,addr-mode" property.
> > But currently there exists no non-deprecated way to describe this in DT.
> >
> > Hence extend the existing "address-width" DT property to allow
> > specifying 9, 17, or 25 address bits, and enable support for that in the
> > driver.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > EEPROMs using 9 address bits are common (e.g. M95040, 25AA040/25LC040).
> > Do EEPROMs using 17 or 25 address bits, as mentioned in
> > include/linux/spi/eeprom.h, really exist?
> > Or should we just limit it to a single odd value (9 bits)?
>
> At least for the real Atmel parts, only the AT25040 part uses odd (8 +
> 1 bit) addressing.
Seems like we should have a specific compatible for it.
> AT25M01 uses 3-byte addressing (it needs 17 bits).
Do you need to know it is 17-bit vs. 24-bits? I'm guessing not as the
unused bits are probably don't care.
Rob
^ permalink raw reply
* [PATCH 1/5] dt: bindings: lp8860: Update DT label binding
From: Dan Murphy @ 2017-12-04 21:20 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, pavel-+ZI9xUNit7I
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Dan Murphy,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171204212026.14214-1-dmurphy-l0cyMroinI0@public.gmane.org>
Update the lp8860 label binding to the LED
standard as documented in
Documentation/devicetree/bindings/leds/common.txt
Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
Documentation/devicetree/bindings/leds/leds-lp8860.txt | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
index aad38dd94d4b..e3a5e91f965b 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
@@ -9,9 +9,9 @@ Required properties:
- compatible:
"ti,lp8860"
- reg - I2C slave address
- - label - Used for naming LEDs
Optional properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
- enable-gpio - gpio pin to enable/disable the device.
- supply - "vled" - LED supply
@@ -20,9 +20,12 @@ Example:
leds: leds@6 {
compatible = "ti,lp8860";
reg = <0x2d>;
- label = "display_cluster";
enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
vled-supply = <&vbatt>;
+
+ display_cluster: display_cluster@0 {
+ label = "display_cluster";
+ };
}
For more product information please see the link below:
--
2.15.0.124.g7668cbc60
--
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 3/5] dt: bindings: lp8860: Add trigger binding to the lp8860
From: Dan Murphy @ 2017-12-04 21:20 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, pavel-+ZI9xUNit7I
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Dan Murphy,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171204212026.14214-1-dmurphy-l0cyMroinI0@public.gmane.org>
Add a default trigger optional node to the child node.
This will allow the driver to set the trigger for a backlight.
Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
Documentation/devicetree/bindings/leds/leds-lp8860.txt | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
index e3a5e91f965b..40543e62da48 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
@@ -6,25 +6,28 @@ current sinks that can be controlled by a PWM input
signal, a SPI/I2C master, or both.
Required properties:
- - compatible:
+ - compatible :
"ti,lp8860"
- - reg - I2C slave address
+ - reg : I2C slave address
Optional properties:
- label : see Documentation/devicetree/bindings/leds/common.txt
- - enable-gpio - gpio pin to enable/disable the device.
- - supply - "vled" - LED supply
+ - enable-gpios : gpio pin to enable/disable the device.
+ - supply : "vled" - LED supply
+ - linux,default-trigger : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
Example:
leds: leds@6 {
compatible = "ti,lp8860";
reg = <0x2d>;
- enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+ enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
vled-supply = <&vbatt>;
display_cluster: display_cluster@0 {
label = "display_cluster";
+ linux,default-trigger = "backlight";
};
}
--
2.15.0.124.g7668cbc60
--
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
* Re: [PATCH 0/3] eeprom: at25: Add DT support for 25lc040
From: Rob Herring @ 2017-12-04 21:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland, Ivo Sieben,
Chris Wright, Wolfram Sang, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512048586-17534-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
On Thu, Nov 30, 2017 at 02:29:43PM +0100, Geert Uytterhoeven wrote:
> Hi all,
>
> Some "atmel,at25" compatible SPI EEPROMs (e.g. Microchip 25lc040) use an
> odd number of address bits. This patch series adds support for
> instantiating such devices from DT.
>
> Do EEPROMs using 17 or 25 address bits, as mentioned in
> include/linux/spi/eeprom.h, really exist?
> Or should we just limit it to a single odd value (9 bits)?
>
> This has been tested with a bunch of 25lc040 EEPROMs.
>
> Thanks!
>
> Geert Uytterhoeven (3):
> eeprom: at25: Add DT support for EEPROMs with odd address bits
> dt-bindings: eeprom: at25: Grammar s/are can/can/
> dt-bindings: eeprom: at25: Document device-specific compatible values
2 and 3 are fixes and I'll apply for 4.15 if you don't mind.
Rob
>
> Documentation/devicetree/bindings/eeprom/at25.txt | 17 ++++++++++++-----
> drivers/misc/eeprom/at25.c | 4 ++++
> 2 files changed, 16 insertions(+), 5 deletions(-)
--
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 v8 10/13] dt-bindings: Add qcom slimbus controller bindings
From: Rob Herring @ 2017-12-04 21:28 UTC (permalink / raw)
To: srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
broonie-DgEjT+Ai2ygdnm+yROfE0A, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
sdharia-sgV2jX0FEOL9JmXXK+q4OQ, bp-l3A5Bk7waGM,
poeschel-Xtl8qvBWbHwb1SvskN2V4Q, treding-DDmLM1+adcrQT0dZR+AlfA,
andreas.noever-Re5JQEeQqe8AvxtiuMwx3w,
alan-VuQAYsv1563Yd54FQh9/CA,
mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A, daniel-/w4YWyX8dFk,
jkosina-AlSwsSmVLrQ, sharon.dvir1-MQgwKvJRKlGYZoqfULhbRA,
joe-6d6DIl74uiNBDgjK7y7TUQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
james.hogan-1AXoQHu6uovQT0dZR+AlfA,
michael.opdenacker-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w, arnd-r2nGTMty4D4
In-Reply-To: <20171130174200.6684-11-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Nov 30, 2017 at 05:41:57PM +0000, srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org wrote:
> From: Sagar Dharia <sdharia-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>
> This patch add device tree bindings for Qualcomm slimbus controller.
>
> Signed-off-by: Sagar Dharia <sdharia-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/slimbus/slim-qcom-ctrl.txt | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt b/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
> new file mode 100644
> index 000000000000..93a6fdaf09b3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
> @@ -0,0 +1,39 @@
> +Qualcomm SLIMbus controller
> +This controller is used if applications processor driver controls SLIMbus
> +master component.
> +
> +Required properties:
> +
> + - #address-cells - refer to Documentation/devicetree/bindings/slimbus/bus.txt
> + - #size-cells - refer to Documentation/devicetree/bindings/slimbus/bus.txt
> +
> + - reg : Offset and length of the register region(s) for the device
> + - reg-names : Register region name(s) referenced in reg above
> + Required register resource entries are:
> + "ctrl": Physical address of controller register blocks
> + "slew": required for "qcom,apq8064-slim" SOC.
> + - compatible : should be "qcom,<SOC-NAME>-slim" for SOC specific compatible
> + followed by "qcom,slim" for fallback.
> + - interrupts : Interrupt number used by this controller
> + - clocks : Interface and core clocks used by this SLIMbus controller
> + - clock-names : Required clock-name entries are:
> + "iface_clk" : Interface clock for this controller
> + "core_clk" : Interrupt for controller core's BAM
Doesn't match the example. You should drop the '_clk'. With that,
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> +
> +Example:
> +
> + slim@28080000 {
> + compatible = "qcom,apq8064-slim", "qcom,slim";
> + reg = <0x28080000 0x2000>, <0x80207C 4>;
> + reg-names = "ctrl", "slew";
> + interrupts = <0 33 0>;
> + clocks = <&lcc SLIMBUS_SRC>, <&lcc AUDIO_SLIMBUS_CLK>;
> + clock-names = "iface", "core";
> + #address-cells = <2>;
> + #size-cell = <0>;
> +
> + wcd9310: audio-codec@1,0{
> + compatible = "slim217,60";
> + reg = <1 0>;
> + };
> + };
> --
> 2.15.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFC 2/2] arm64: allwinner: a64: Add Brava Keller initial support
From: Rob Herring @ 2017-12-04 21:35 UTC (permalink / raw)
To: Philippe Ombredanne
Cc: Jagan Teki, Maxime Ripard, Chen-Yu Tsai, Icenowy Zheng,
Mark Rutland, Catalin Marinas, Will Deacon, Michael Trimarchi,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
Mark Janoff, Stuart Westerman, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
Jagan Teki
In-Reply-To: <CAOFm3uEdsj=qxUf3O0S0vDqgXgosvBYG6BGbf6cYn3aNreTPaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Nov 30, 2017 at 10:36:55PM +0100, Philippe Ombredanne wrote:
> Jagan,
>
> On Thu, Nov 30, 2017 at 7:42 PM, Jagan Teki <jagannadh.teki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> []
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> > new file mode 100644
> > index 0000000..f5303a3
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> > @@ -0,0 +1,244 @@
> > +/*
> > + * Copyright (C) 2017 Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPL or the X11 license, at your option. Note that this dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + * a) This library 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 library 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.
> > + *
> > + * Or, alternatively,
> > + *
> > + * b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated documentation
> > + * files (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use,
> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following
> > + * conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > + * included in all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
>
> Rather than this long boilerplate, you might want to use the SPDX ids,
> as started by Greg and documented by Thomas.
> Noe that Linus wants the // comment style for the license line, and
> since there is only two line left here I suggest using it for both
> lines.
> You can check also the recent doc patch posted by Thomas (tglx) and
> comments from Linus and Greg.
>
> So I guess you could use this:
>
> > +// Copyright (C) 2017 Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > +// SPDX-License-Indentifier: (GPL-2.0+ OR MIT)
Other way around. Make SPDX-License-Indentifier the first line.
> NB: what you call X11 is has the MIT license id in the SPDX license list.
Right. That was a common mistake or abiguity in the dts files.
> So you could replace 32 lines by only two lines :) it'[s neat right?
>
> And this would also help as we have tagged already ~15K files, so it
> would help to use this for new files so the amount of cleanup work
> still left does not increase. Thank you for your kind consideration!
I've been nuging folks to do that for a while now. Of course, now we
need to go move the ids to the first line at some point.
Rob
^ permalink raw reply
* Re: [PATCH RFC 1/2] dt-bindings: Add vendor prefix for Brava Home
From: Rob Herring @ 2017-12-04 21:36 UTC (permalink / raw)
To: Jagan Teki
Cc: Maxime Ripard, Chen-Yu Tsai, Icenowy Zheng, Mark Rutland,
Catalin Marinas, Will Deacon, Michael Trimarchi,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Janoff,
Stuart Westerman, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Jagan Teki
In-Reply-To: <1512067334-12761-1-git-send-email-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
On Fri, Dec 01, 2017 at 12:12:13AM +0530, Jagan Teki wrote:
> Added 'brava' as a vendor prefix for Brava Home, Inc.
> which is consumer electronics and IoT company.
>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v4 2/4] clk: meson-axg: add clocks dt-bindings required header
From: Rob Herring @ 2017-12-04 21:37 UTC (permalink / raw)
To: Yixun Lan
Cc: Neil Armstrong, Jerome Brunet, Kevin Hilman, Mark Rutland,
Michael Turquette, Stephen Boyd, Carlo Caione, Qiufang Dai,
linux-amlogic, devicetree, linux-clk, linux-arm-kernel,
linux-kernel
In-Reply-To: <20171201012452.27086-3-yixun.lan@amlogic.com>
On Fri, Dec 01, 2017 at 09:24:50AM +0800, Yixun Lan wrote:
> From: Qiufang Dai <qiufang.dai@amlogic.com>
>
> Add the required header for the clocks ID dt-bindings
> exported from various subsystem in the Meson-AXG SoC.
>
> Signed-off-by: Qiufang Dai <qiufang.dai@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> include/dt-bindings/clock/axg-clkc.h | 71 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
> create mode 100644 include/dt-bindings/clock/axg-clkc.h
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: PCI: dra7xx: Add bindings for unaligned access in host mode
From: Rob Herring @ 2017-12-04 21:40 UTC (permalink / raw)
To: Vignesh R
Cc: Bjorn Helgaas, Tony Lindgren, Chris Welch, Kishon Vijay Abraham I,
Lorenzo Pieralisi, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171201061311.16691-3-vigneshr-l0cyMroinI0@public.gmane.org>
On Fri, Dec 01, 2017 at 11:43:09AM +0530, Vignesh R wrote:
> Update device tree binding documentation of TI's dra7xx PCI controller
> for enabling unaligned mem access as applicable not just in EP mode but
> in host mode as well.
>
> Signed-off-by: Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>
> ---
> Documentation/devicetree/bindings/pci/ti-pci.txt | 5 +++++
> 1 file changed, 5 insertions(+)
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/1] at24: support eeproms that do not auto-rollover reads.
From: Sakari Ailus @ 2017-12-04 21:40 UTC (permalink / raw)
To: Sven Van Asbroeck
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wsa-z923LK4zBo2bacvFa/9K2g, brgl-ARrdPY/1zhM, nsekhar-l0cyMroinI0,
david-nq/r/kbU++upp/zk7JDF2g, javier-0uQlZySMnqxg9hUCZPvPmw,
divagar.mohandass-ral2JQCrhuEAvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Sven Van Asbroeck
In-Reply-To: <1512401778-20366-2-git-send-email-svendev-fuHqz3Nb1YI@public.gmane.org>
Hi Sven,
On Mon, Dec 04, 2017 at 10:36:18AM -0500, Sven Van Asbroeck wrote:
> From: Sven Van Asbroeck <svenv-fuHqz3Nb1YI@public.gmane.org>
>
> Some multi-address eeproms in the at24 family may not automatically
> roll-over reads to the next slave address. On those eeproms, reads
> that straddle slave boundaries will not work correctly.
>
> Solution:
> Mark such eeproms with a flag that prevents reads straddling
> slave boundaries. Add the AT24_FLAG_NO_RDROL flag to the eeprom
> entry in the device_id table, or add 'no-read-rollover' to the
> eeprom devicetree entry.
>
> Note that I have not personally enountered an at24 chip that
> does not support read rollovers. They may or may not exist.
> However, my hardware requires this functionality because of
> a quirk.
>
> It's up to the Linux community to decide if this patch is useful/
> general enough to warrant merging.
>
> Signed-off-by: Sven Van Asbroeck <svendev-fuHqz3Nb1YI@public.gmane.org>
> ---
> .../devicetree/bindings/eeprom/eeprom.txt | 5 +++
> drivers/misc/eeprom/at24.c | 37 +++++++++++++++-------
> include/linux/platform_data/at24.h | 2 ++
> 3 files changed, 32 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> index 27f2bc1..a1764f8 100644
> --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> @@ -38,6 +38,11 @@ Optional properties:
>
> - size: total eeprom size in bytes
>
> + - no-read-rollover: supported on the at24 eeprom family only.
If this is truly specific to at24, then vendor prefix would be appropriate,
plus it'd go to an at24 specific binding file. However if it isn't I'd just
remove the above sentence. I guess the latter?
Binding changes would be nicer in a separate patch, too.
> + This parameterless property indicates that the multi-address
> + eeprom does not automatically roll over reads to the next
> + slave address. Please consult the manual of your device.
> +
> Example:
>
> eeprom@52 {
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index 625b001..33bca28 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -251,15 +251,6 @@ struct at24_data {
> * Slave address and byte offset derive from the offset. Always
> * set the byte address; on a multi-master board, another master
> * may have changed the chip's "current" address pointer.
> - *
> - * REVISIT some multi-address chips don't rollover page reads to
> - * the next slave address, so we may need to truncate the count.
> - * Those chips might need another quirk flag.
> - *
> - * If the real hardware used four adjacent 24c02 chips and that
> - * were misconfigured as one 24c08, that would be a similar effect:
> - * one "eeprom" file not four, but larger reads would fail when
> - * they crossed certain pages.
> */
> static struct at24_client *at24_translate_offset(struct at24_data *at24,
> unsigned int *offset)
> @@ -277,6 +268,28 @@ static struct at24_client *at24_translate_offset(struct at24_data *at24,
> return &at24->client[i];
> }
>
> +static size_t at24_adjust_read_count(struct at24_data *at24,
> + unsigned int offset, size_t count)
> +{
> + unsigned int bits;
> + size_t remainder;
> + /*
> + * In case of multi-address chips that don't rollover reads to
> + * the next slave address: truncate the count to the slave boundary,
> + * so that the read never straddles slaves.
> + */
> + if (at24->chip.flags & AT24_FLAG_NO_RDROL) {
> + bits = (at24->chip.flags & AT24_FLAG_ADDR16) ? 16 : 8;
> + remainder = BIT(bits) - offset;
> + if (count > remainder)
> + count = remainder;
> + }
> + if (count > io_limit)
> + count = io_limit;
> +
> + return count;
> +}
> +
> static ssize_t at24_regmap_read(struct at24_data *at24, char *buf,
> unsigned int offset, size_t count)
> {
> @@ -289,9 +302,7 @@ static ssize_t at24_regmap_read(struct at24_data *at24, char *buf,
> at24_client = at24_translate_offset(at24, &offset);
> regmap = at24_client->regmap;
> client = at24_client->client;
> -
> - if (count > io_limit)
> - count = io_limit;
> + count = at24_adjust_read_count(at24, offset, count);
>
> /* adjust offset for mac and serial read ops */
> offset += at24->offset_adj;
> @@ -457,6 +468,8 @@ static void at24_get_pdata(struct device *dev, struct at24_platform_data *chip)
>
> if (device_property_present(dev, "read-only"))
> chip->flags |= AT24_FLAG_READONLY;
> + if (device_property_present(dev, "no-read-rollover"))
> + chip->flags |= AT24_FLAG_NO_RDROL;
>
> err = device_property_read_u32(dev, "size", &val);
> if (!err)
> diff --git a/include/linux/platform_data/at24.h b/include/linux/platform_data/at24.h
> index 271a4e2..841bb28 100644
> --- a/include/linux/platform_data/at24.h
> +++ b/include/linux/platform_data/at24.h
> @@ -50,6 +50,8 @@ struct at24_platform_data {
> #define AT24_FLAG_TAKE8ADDR BIT(4) /* take always 8 addresses (24c00) */
> #define AT24_FLAG_SERIAL BIT(3) /* factory-programmed serial number */
> #define AT24_FLAG_MAC BIT(2) /* factory-programmed mac address */
> +#define AT24_FLAG_NO_RDROL BIT(1) /* does not auto-rollover reads to */
> + /* the next slave address */
>
> void (*setup)(struct nvmem_device *nvmem, void *context);
> void *context;
> --
> 1.9.1
>
--
Sakari Ailus
sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: marvell: Add documentation for the North Bridge PM on Armada 37xx
From: Rob Herring @ 2017-12-04 21:47 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Rafael J. Wysocki, Viresh Kumar, linux-pm, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, devicetree, Thomas Petazzoni,
linux-arm-kernel, Antoine Tenart, Miquèl Raynal,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits, Evan Wang
In-Reply-To: <20171201112508.14121-2-gregory.clement@free-electrons.com>
On Fri, Dec 01, 2017 at 12:25:03PM +0100, Gregory CLEMENT wrote:
> Extend the documentation of the Armada 37xx SoC with the the North
> Bridge Power Management component.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> .../devicetree/bindings/arm/marvell/armada-37xx.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> index 51336e5fc761..7ad9830d9177 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> @@ -14,3 +14,22 @@ following property before the previous one:
> Example:
>
> compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
> +
> +
> +Power management
> +----------------
> +
> +For power management (particularly DVFS and AVS), the North Bridge
> +Power Management component is needed:
> +
> +Required properties:
> +- compatible : should contain "marvell,armada-3700-nb-pm", "syscon";
> +- reg : the register start and length for the North Bridge
> + Power Management
> +
> +Example:
> +
> +nb_pm: nb_pm@14000 {
Don't use underscore in node or property names. "syscon" is a better
choice here.
> + compatible = "marvell,armada-3700-nb-pm", "syscon";
> + reg = <0x14000 0x60>;
> +}
> --
> 2.15.0
>
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation
From: Rob Herring @ 2017-12-04 21:48 UTC (permalink / raw)
To: Matthias Brugger
Cc: mark.rutland, linux, sboyd, sean.wang, chen.zhong, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20171201120708.30129-1-matthias.bgg@gmail.com>
On Fri, Dec 01, 2017 at 01:07:06PM +0100, Matthias Brugger wrote:
> The ethsys registers a reset controller, so we need to specify a
> reset cell. This patch fixes the documentation.
>
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
> 1 file changed, 1 insertion(+)
For all 3,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v10 5/6] dt-bindings: mailbox: qcom: Document the APCS clock binding
From: Rob Herring @ 2017-12-04 21:49 UTC (permalink / raw)
To: Georgi Djakov
Cc: sboyd, jassisinghbrar, bjorn.andersson, mturquette, linux-clk,
linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <20171201170224.25053-6-georgi.djakov@linaro.org>
On Fri, Dec 01, 2017 at 07:02:23PM +0200, Georgi Djakov wrote:
> Update the binding documentation for APCS to mention that the APCS
> hardware block also expose a clock controller functionality.
>
> The APCS clock controller is a mux and half-integer divider. It has the
> main CPU PLL as an input and provides the clock for the application CPU.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> .../bindings/mailbox/qcom,apcs-kpss-global.txt | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v6 12/13] ASoC: add bindings for stm32 DFSDM filter
From: Rob Herring @ 2017-12-04 21:51 UTC (permalink / raw)
To: Arnaud Pouliquen
Cc: Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Jaroslav Kysela,
Takashi Iwai, Liam Girdwood, Mark Brown,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Maxime Coquelin,
Alexandre Torgue
In-Reply-To: <1512150020-20335-13-git-send-email-arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
On Fri, Dec 01, 2017 at 06:40:19PM +0100, Arnaud Pouliquen wrote:
> Add bindings that describes audio settings to support
> Digital Filter for pulse density modulation(PDM) microphone.
>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
> ---
> .../devicetree/bindings/sound/st,stm32-adfsdm.txt | 62 ++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-adfsdm.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: mc13xxx: Add the unit address to sysled
From: Rob Herring @ 2017-12-04 21:53 UTC (permalink / raw)
To: Fabio Estevam
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, Fabio Estevam
In-Reply-To: <1512165086-25512-1-git-send-email-festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Dec 01, 2017 at 07:51:26PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>
> As the 'reg' property is mandatory in the subnodes, improve the
> example by adding the unit address to the sysled node.
>
> This prevents the following build warning with W=1:
>
> Node /soc/aips@70000000/spba@70000000/ecspi@70010000/pmic@0/leds/sysled0 has a reg or ranges property, but no unit name
Even if the doc file could compile, looks like the name was sysled not
sysled0.
>
> Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mfd/mc13xxx.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
In any case,
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/4] Move DP phy switch to PHY driver
From: Heiko Stübner @ 2017-12-04 21:53 UTC (permalink / raw)
To: Doug Anderson
Cc: Mark Rutland, David Airlie, Catalin Marinas, Shawn Lin,
Will Deacon, Kever Yang, dri-devel, Guenter Roeck, Chris Zhong,
Brian Norris, Kishon Vijay Abraham I,
open list:ARM/Rockchip SoC..., Jianqun Xu, Caesar Wang,
devicetree, Elaine Zhang, Rob Herring, William wu, Linux ARM,
LKML, Tomasz Figa, David Wu,
Enric Balletbo i Serra <enric.balletb>
In-Reply-To: <CAD=FV=XVCCbh6P-WweccyKiNy2RJRhqY-6gpf7BVkY4oqdDZbg@mail.gmail.com>
Hi,
Am Montag, 4. Dezember 2017, 08:08:31 CET schrieb Doug Anderson:
> On Sun, Dec 3, 2017 at 11:46 PM, Heiko Stübner <heiko@sntech.de> wrote:
> > Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
> >> On 2017年12月02日 05:58, Heiko Stuebner wrote:
> >> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
> >> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong <zyw@rock-chips.com>
wrote:
> >> >>> Thank you for mentioning this patch.
> >> >>>
> >> >>> I think the focus of the discussion is: can we put the grf control
> >> >>> bit
> >> >>> to
> >> >>> dts.
> >> >>>
> >> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
> >> >>> "uphy_dp_sel"
> >> >>>
> >> >>> can help to switch these 2 phy. So I think this bit can be considered
> >> >>> as
> >> >>> a
> >> >>> part of
> >> >>>
> >> >>> Type-C phy, these 2 phy have different bits, just similar to other
> >> >>> bits
> >> >>> (such as "pipe-status").
> >> >>>
> >> >>> Put them to DTS file might be a accepted practice.
> >> >>
> >> >> I guess the first step would be finding the person to make a decision.
> >> >> Is that Heiko? Olof? Kishon? Rob?. As I see it there are a few
> >> >> options:
> >> >>
> >> >> 1. Land this series as-is. This makes the new bit work just like all
> >> >> the other ones next to it. If anyone happens to try to use an old
> >> >> device tree on a new kernel they'll break. Seems rather unlikely
> >> >> given that the whole type C PHY is not really fully functional
> >> >> upstream, but technically this is a no-no from a device tree
> >> >> perspective.
> >> >>
> >> >> 2. Change the series to make this property optional. If it's not
> >> >> there then the code behaves like it always did. This would address
> >> >> the "compatibility" problem but likely wouldn't actually help any real
> >> >> people, and it would be extra work.
> >> >>
> >> >> 3. Redo the driver to deprecate all the old offsets / bits and just
> >> >> put the table in the driver, keyed off the compatible string and base
> >> >> address if the IO memory.
> >> >>
> >> >>
> >> >> I can't make this decision. It's up to those folks who would be
> >> >> landing the patch and I'd be happy with any of them. What I'm less
> >> >> happy with, however, is the indecision preventing forward progress.
> >> >> We should pick one of the above things and land it. My own personal
> >> >> bias is #1: just land the series. No real people will be hurt and
> >> >> it's just adding another property that matches the ones next to it.
> >> >
> >> > I'd second that #1 . That whole type-c phy thingy never fully worked in
> >> > the past (some for the never used dp output), so personally I don't
> >> > have
> >> > issues with going that route.
> >> >
> >> >> From a long term perspective (AKA how I'd write the next driver like
> >> >>
> >> >> this) I personally lean towards to "tables in the driver, not in the
> >> >> device tree" but quite honestly I'm happy to take whatever direction
> >> >> the maintainers give.
> >> >
> >> > It looks like we're in agreement here :-) . GRF stuff should not leak
> >> > into
> >> > the devicetree, as it causes endless headaches later. But I guess we'll
> >> > need to live with the ones that happened so far.
> >>
> >> So, the first step is: move all the private property of tcphy to
> >> drivers/phy/rockchip/phy-rockchip-typec.c.
> >> Second step: new a member: uphy-dp-sel.
> >> In my mind, we should have discussed these properties before, and then I
> >> moved them all into DTS.
> >
> > Actually, I was agreeing with Doug, that we probably don't need to rework
> > the type-c phy driver. As most properties for it are in the devicetree
> > right now we'll need to support them for backwards-compatiblity anyway.
> >
> > And yes, there probably was discussion over dts vs. driver-table when the
> > type-c driver was introduced, but I either missed it or wasn't firm enough
> > back then ;-) .
> >
> > Hence the "we'll need to live with it" for the type-c phy, but should not
> > do similar things in future drivers.
>
> So I guess now we're just waiting for some agreement from Kishon that
> he's willing to land the PHY change? Heiko: presumably you could
> apply the DP change to drm-misc? ...or is there some other process
> needed there?
I was lagging behind a bit with the drm-misc account request but have
done so now. So once I got the hang of how drm-misc works and Kishon
has picked the phy-part I can most likely push the drm part (or Sandy,
depending on who is faster).
As for process, I don't think there is special care necessary. When
you get the intermediate case of phy-change but no drm-change
everything will just revert to how it works now anyway.
Heiko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: mc13xxx: Add the unit address to sysled
From: Fabio Estevam @ 2017-12-04 21:57 UTC (permalink / raw)
To: Rob Herring
Cc: Lee Jones, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Fabio Estevam
In-Reply-To: <20171204215302.3zhepg2sz6ycmmt6@rob-hp-laptop>
Hi Rob,
On Mon, Dec 4, 2017 at 7:53 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Dec 01, 2017 at 07:51:26PM -0200, Fabio Estevam wrote:
>> From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>>
>> As the 'reg' property is mandatory in the subnodes, improve the
>> example by adding the unit address to the sysled node.
>>
>> This prevents the following build warning with W=1:
>>
>> Node /soc/aips@70000000/spba@70000000/ecspi@70010000/pmic@0/leds/sysled0 has a reg or ranges property, but no unit name
>
> Even if the doc file could compile, looks like the name was sysled not
> sysled0.
The sysled0 name I got from arch/arm/boot/dts/imx51-zii-rdu1.dts,
where I fixed the real warning:
https://www.spinics.net/lists/arm-kernel/msg620322.html
>>
>> Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/mfd/mc13xxx.txt | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> In any case,
>
> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks
--
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 V5 2/7] ACPI / bus: Introduce acpi_get_match_data() function
From: Rafael J. Wysocki @ 2017-12-04 21:59 UTC (permalink / raw)
To: Sinan Kaya
Cc: dmaengine, Timur Tabi, devicetree@vger.kernel.org, linux-arm-msm,
linux-arm-kernel@lists.infradead.org, Rafael J. Wysocki,
Len Brown, open list:ACPI, open list
In-Reply-To: <1512188864-773-3-git-send-email-okaya@codeaurora.org>
On Sat, Dec 2, 2017 at 5:27 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> OF has of_device_get_match_data() function to extract driver specific data
> structure. Add a similar function for ACPI.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Haven't I ACKed this already?
Anyway, please resend the whole series with a CC to linux-acpi.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH 1/3] eeprom: at25: Add DT support for EEPROMs with odd address bits
From: Ivo Sieben @ 2017-12-04 22:00 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Greg Kroah-Hartman, Rob Herring, Mark Rutland,
Chris Wright, Wolfram Sang,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdWczQ0KiH7soGLKxX8CQEwxA=kVDc_saYqgytE2U_3WKw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geert,
My 2 cents:
2017-12-04 10:17 GMT+01:00 Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>:
>> EEPROMs using 9 address bits are common (e.g. M95040, 25AA040/25LC040).
>> Do EEPROMs using 17 or 25 address bits, as mentioned in
>> include/linux/spi/eeprom.h, really exist?
>> Or should we just limit it to a single odd value (9 bits)?
>
> At least for the real Atmel parts, only the AT25040 part uses odd (8 +
> 1 bit) addressing.
> AT25M01 uses 3-byte addressing (it needs 17 bits).
>
> So I tend to believe EEPROMs using 16 + 1 or 24 + 1 address bits (with the
> extra bit in the instruction byte) do not exist?
>
I think you are right. Most likely this extra address bit option is
only used for 9 bit addressable chips.
I'm not an expert, but I know only the M95040 chip for which I
originally wrote the patch.
By then I decided to make it a bit broader (so also to be used as
address 17 & 25 bit addressing) but that might
not make any sense indeed.
>> @@ -6,7 +6,9 @@ Required properties:
>> - spi-max-frequency : max spi frequency to use
>> - pagesize : size of the eeprom page
>> - size : total eeprom size in bytes
>> -- address-width : number of address bits (one of 8, 16, or 24)
>> +- address-width : number of address bits (one of 8, 9, 16, 17, 24, or 25).
>> + For odd values, the MSB of the address is sent as bit 3 of the instruction
>> + byte, before the address byte(s).
>
> Alternatively, we can drop the binding change, i.e. keep on using
> address-width = <8> for 512-byte '040...
>
As you also stated before: maybe it is more clear to leave only the
"9" value option documented
here, that looks to me the only valid use case for it.
>> + if (val & 1) {
>> + chip->flags |= EE_INSTR_BIT3_IS_ADDR;
>> + val -= 1;
>> + }
>
> ... and handle it here like:
>
> if (chip->byte_len == 2U << val)
> chip->flags |= EE_INSTR_BIT3_IS_ADDR;
>
> However, that would IMHO be a bit confusing, as the "address-width"
> property is no longer the real address width, but indicates how many bits
> are specified in address bytes sent after the read/write command.
> So "address-bytes" = 1, 2, or 3 would be more correct ;-)
>
> Or deprecate this whole "specify parameters using DT properties" business,
> and derive them from the compatible value. But that would mean adding a
> large and ever growing table to an old driver...
>
> Thoughts?
I'm not a DT expert but to me your first proposal makes the most sense
to me and feels the most intuitive:
I would go for the address-with value 9 option here.
Since we only expect value 9 to be a valid option, maybe you could
rewrite it a bit to explicitly check for value 9:
if (val == 9) {
chip->flags |= EE_INSTR_BIT3_IS_ADDR;
val -= 1;
}
I think this is slightly more readable.
Hope this helps,
Regards,
Ivo Sieben
--
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 V5 2/7] ACPI / bus: Introduce acpi_get_match_data() function
From: Sinan Kaya @ 2017-12-04 22:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: dmaengine, Timur Tabi, devicetree@vger.kernel.org, linux-arm-msm,
linux-arm-kernel@lists.infradead.org, Rafael J. Wysocki,
Len Brown, open list:ACPI, open list
In-Reply-To: <CAJZ5v0gCkY80+A=cZKzhKhxKObSgqN3k1JGgGQgW5cwRSvqt_Q@mail.gmail.com>
On 12/4/2017 4:59 PM, Rafael J. Wysocki wrote:
> On Sat, Dec 2, 2017 at 5:27 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
>> OF has of_device_get_match_data() function to extract driver specific data
>> structure. Add a similar function for ACPI.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>
> Haven't I ACKed this already?
>
> Anyway, please resend the whole series with a CC to linux-acpi.
Yeah, you acked the previous one. Then, I changed the calling parameter from
struct device to struct acpi_device and removed your ACK.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ 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