* Re: [PATCH v7 1/5] irqchip/aspeed-i2c-ic: binding docs for Aspeed I2C Interrupt Controller
From: Rob Herring @ 2017-04-28 18:19 UTC (permalink / raw)
To: Brendan Higgins
Cc: wsa-z923LK4zBo2bacvFa/9K2g, mark.rutland-5wv7dgnIgG8,
tglx-hfZtesqFncYOwBW4kG4KsQ, jason-NLaQJdtUoK4Be96aLqz0jA,
marc.zyngier-5wv7dgnIgG8, joel-U3u1mxZcP9KHXe+LvDLADg,
vz-ChpfBGZJDbMAvxtiuMwx3w, mouse-Pma6HLj0uuo, clg-Bxea+6Xhats,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
openbmc-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <20170424181818.2754-2-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Mon, Apr 24, 2017 at 11:18:14AM -0700, Brendan Higgins wrote:
> Added device tree binding documentation for Aspeed I2C Interrupt
> Controller.
>
> Signed-off-by: Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> ---
> Added in v6:
> - Pulled "aspeed_i2c_controller" out into a interrupt controller since that is
> what it actually does.
> Changes for v7:
> - None
> ---
> .../interrupt-controller/aspeed,ast2400-i2c-ic.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.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 13/18] dt-bindings: gpio: Add bindings for GPIO on Cirrus Logic Madera codecs
From: Rob Herring @ 2017-04-28 18:17 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: lee.jones, broonie, linus.walleij, gnurou, tglx, jason,
alsa-devel, patches, linux-gpio, devicetree, linux-kernel
In-Reply-To: <1493050124-5970-14-git-send-email-rf@opensource.wolfsonmicro.com>
On Mon, Apr 24, 2017 at 05:08:39PM +0100, Richard Fitzgerald wrote:
> The Cirrus Logic Madera codecs have a range of GPIO pins that can be
> used as single-bit logic input or output. These are presented as a
> standard GPIO binding.
>
> The second cell in a GPIO binding is currently reserved for future use
> as chip-specific flags.
>
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> ---
> Changes from V1:
> - moved out of main gpio patch into a separate patch
> - added gpio-line-names as an optional property
>
> .../devicetree/bindings/gpio/gpio-madera.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-madera.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 11/18] dt-bindings: pinctrl: Add bindings for Cirrus Logic Madera codecs
From: Rob Herring @ 2017-04-28 18:16 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, broonie-DgEjT+Ai2ygdnm+yROfE0A,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, tglx-hfZtesqFncYOwBW4kG4KsQ,
jason-NLaQJdtUoK4Be96aLqz0jA, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493050124-5970-12-git-send-email-rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
On Mon, Apr 24, 2017 at 05:08:37PM +0100, Richard Fitzgerald wrote:
> This is the binding description of the pinctrl driver for Cirru Logic
> Madera codecs. The binding uses the generic pinctrl binding so the main
> purpose here is to describe the device-specific names for groups and
> functions.
>
> Signed-off-by: Richard Fitzgerald <rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> ---
> Changes since V1:
> - split out from main pinctrl patch into a separate patch
> - fixed typo in pinctrl-names property description
>
> .../bindings/pinctrl/cirrus,madera-pinctrl.txt | 102 +++++++++++++++++++++
> 1 file changed, 102 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.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 07/18] regulator: arizona-micsupp: Add support for Cirrus Logic Madera codecs
From: Rob Herring @ 2017-04-28 18:07 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, broonie-DgEjT+Ai2ygdnm+yROfE0A,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, tglx-hfZtesqFncYOwBW4kG4KsQ,
jason-NLaQJdtUoK4Be96aLqz0jA, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493050124-5970-8-git-send-email-rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
On Mon, Apr 24, 2017 at 05:08:33PM +0100, Richard Fitzgerald wrote:
> This adds a new driver identity "madera-micsupp" and probe function
> so that this driver can be used to control the micsupp regulator on
> Cirrus Logic Madera codecs.
>
> Signed-off-by: Richard Fitzgerald <rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> ---
> Replaces the madera-specific driver from V1 patchset
>
> .../bindings/regulator/arizona-regulator.txt | 3 +-
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/regulator/Kconfig | 7 ++-
> drivers/regulator/arizona-micsupp.c | 71 +++++++++++++++++++++-
> 3 files changed, 76 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 v2 03/18] dt-bindings: mfd: Add bindings for Cirrus Logic Madera codecs
From: Rob Herring @ 2017-04-28 18:07 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: lee.jones, broonie, linus.walleij, gnurou, tglx, jason,
alsa-devel, patches, linux-gpio, devicetree, linux-kernel
In-Reply-To: <1493050124-5970-4-git-send-email-rf@opensource.wolfsonmicro.com>
On Mon, Apr 24, 2017 at 05:08:29PM +0100, Richard Fitzgerald wrote:
> Specification of the bindings for the parent MFD driver component
> of the Cirrus Logic Madera codec drivers.
>
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> ---
> Changes since V1:
> - split out from main MFD patch
> - moved interrupt control binding descriptions into here
> - added description of the regulator child nodes
> - fixed the node name of the example
> - removed the MICBIAS from the example, these have been removed from the code
>
> Documentation/devicetree/bindings/mfd/madera.txt | 96 ++++++++++++++++++++++++
> 1 file changed, 96 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/madera.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 15/18] dt-bindings: sound: Add bindings for Cirrus Logic Madera codecs
From: Rob Herring @ 2017-04-28 18:06 UTC (permalink / raw)
To: Mark Brown
Cc: Richard Fitzgerald, lee.jones, linus.walleij, gnurou, tglx, jason,
alsa-devel, patches, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20170425155257.s6m4wgrzxxsxcggo@sirena.org.uk>
On Tue, Apr 25, 2017 at 04:52:57PM +0100, Mark Brown wrote:
> On Mon, Apr 24, 2017 at 05:08:41PM +0100, Richard Fitzgerald wrote:
> > The Cirrus Logic Madera codecs are a family of related codecs with
> > extensive digital and analogue I/O, digital mixing and routing,
> > signal processing and programmable DSPs.
>
> Please submit patches using subject lines reflecting the style for the
> subsystem. This makes it easier for people to identify relevant
> patches. Look at what existing commits in the area you're changing are
> doing and make sure your subject lines visually resemble what they're
> doing.
>
> > +Required properties:
> > + - compatible : One of the following chip-specific strings:
> > + "cirrus,cs47l35-codec"
> > + "cirrus,cs47l85-codec"
> > + "cirrus,cs47l90-codec"
>
> You shouldn't have compatible strings for subfunctions of a MFD unless
> these represent meaningful reusable IPs that can exist separately from
> the parent chip, that's clearly not the case here. All you're doing
> here is encoding Linux internal abstractions which aren't OS neutral and
> might change in future (for example clocking might move more into the
> clock API).
s/compatible strings/child nodes/ and I agree. If you have child nodes,
then they need to have compatible strings so we can tell what child is
which. Node name can be used, but there's no way to version node names.
A compatible implies what properties are valid.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/3] ARM: BCM: Enable thermal support for iProc SoCs
From: Jon Mason @ 2017-04-28 18:05 UTC (permalink / raw)
To: Scott Branden
Cc: Florian Fainelli, Zhang Rui, Eduardo Valentin, Rob Herring,
Mark Rutland, BCM Kernel Feedback, linux-arm-kernel, open list,
linux-pm,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <bceb9b66-c769-faf3-9288-26581b5d5dc6@broadcom.com>
On Thu, Apr 27, 2017 at 7:10 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
>
>
> On 17-04-27 02:23 PM, Jon Mason wrote:
>>
>> Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows
>> the ns-thermal driver to be selected via menuconfig.
>>
>> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>> ---
>> arch/arm/mach-bcm/Kconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> index a0e66d8..da2bfeb 100644
>> --- a/arch/arm/mach-bcm/Kconfig
>> +++ b/arch/arm/mach-bcm/Kconfig
>> @@ -19,6 +19,8 @@ config ARCH_BCM_IPROC
>> select GPIOLIB
>> select ARM_AMBA
>> select PINCTRL
>> + select THERMAL
>> + select THERMAL_OF
>
> This is NSP specific at this point. Also, If it increases code size in any
> way it shouldn't be selected for all IPROC SoCS. I'd rather this was just
> selected via defconfig
This isn't selectable via menuconfig without being in the kconfig.
I'll move it to the NSP portion of the kconfig, as to not increase the
size of other's kernels.
Thanks,
Jon
>
>> help
>> This enables support for systems based on Broadcom IPROC
>> architected SoCs.
>> The IPROC complex contains one or more ARM CPUs along with
>> common
>>
>
^ permalink raw reply
* Re: [PATCH 1/2] thermal: broadcom: Allow for NSP to use ns-thermal driver
From: Jon Mason @ 2017-04-28 18:04 UTC (permalink / raw)
To: Eduardo Valentin
Cc: Florian Fainelli, Zhang Rui, Rob Herring, Mark Rutland,
BCM Kernel Feedback, linux-arm-kernel, open list, linux-pm,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20170428130659.GA28546@localhost.localdomain>
On Fri, Apr 28, 2017 at 9:07 AM, Eduardo Valentin <edubezval@gmail.com> wrote:
> On Thu, Apr 27, 2017 at 01:42:25PM -0400, Jon Mason wrote:
>> On Thu, Apr 27, 2017 at 12:37 PM, Eduardo Valentin <edubezval@gmail.com> wrote:
>> > Hey Jason,
>>
>> It's Jon :)
>
> Apologies. I think I either read too fast, or my fingers were faster
> than my brain. Sorry.
NP, That exact error happens more frequently that you would think :)
>>
>> >
>> > On Tue, Apr 25, 2017 at 04:49:10PM -0400, Jon Mason wrote:
>> >> Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows
>> >> the ns-thermal driver to be selected via menuconfig. Also, change the
>> >> ns-thermal driver to work on any iProc based SoC. Finally, tweak the
>> >> Kconfig description to mention support for NSP and make the default on
>> >> for iProc based platforms.
>> >
>> >
>> > Thanks for the patch, but..
>> >>
>> >> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>> >> ---
>> >> arch/arm/mach-bcm/Kconfig | 2 ++
>> >> drivers/thermal/broadcom/Kconfig | 9 +++++----
>> >> 2 files changed, 7 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> >> index a0e66d8..da2bfeb 100644
>> >> --- a/arch/arm/mach-bcm/Kconfig
>> >> +++ b/arch/arm/mach-bcm/Kconfig
>> >> @@ -19,6 +19,8 @@ config ARCH_BCM_IPROC
>> >> select GPIOLIB
>> >> select ARM_AMBA
>> >> select PINCTRL
>> >> + select THERMAL
>> >> + select THERMAL_OF
>> >> help
>> >> This enables support for systems based on Broadcom IPROC architected SoCs.
>> >> The IPROC complex contains one or more ARM CPUs along with common
>> >
>> > It would be better if this is split and sent through your arch tree, to
>> > avoid conflicts. I could also pick it if you get an ack from one of your
>> > maintainers. Still, first option is preferable.
>>
>> Sure, I'll be happy to split this off. I should've thought to split
>> it up before sending. Thanks for the suggestion.
>
> Cool!
>
>>
>> >
>> >> diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
>> >> index f0dea8a..26d706c 100644
>> >> --- a/drivers/thermal/broadcom/Kconfig
>> >> +++ b/drivers/thermal/broadcom/Kconfig
>> >> @@ -1,8 +1,9 @@
>> >> config BCM_NS_THERMAL
>> >> tristate "Northstar thermal driver"
>> >> depends on ARCH_BCM_IPROC || COMPILE_TEST
>> >> + default ARCH_BCM_IPROC
>> >
>> > Not sure if this is really what you wanted. Based on your commit log
>> > message, you meant the following, perhaps?
>> >
>> > + default y if ARCH_BCM_IPROC
>>
>> IIUC, my original default works, as we have used it frequently in
>> other places in the kernel.
>> grep -rI "default ARCH_BCM_IPROC" * | wc -l
>> 15
>
> Yeah... Are you sure they are all correct?
>
>>
>> However, if the above is preferred (or the other 15 massively broken),
>> I'll be happy to do it that way.
>
> Your construction is syntactically correct. Maybe might still work (did
> not check myself) for the purpose you describe, but the construction
> mentioned in Documentation/kbuild/kconfig-language.txt is:
> + default y if BAR
>
> So, please fix it.
Oh, thanks for the info. I was unaware of this, and we should
definitely follow the documentation.. I'll make the relevant changes
and do follow-on patches to correct the other places.
>
>>
>>
>> >> help
>> >> - Northstar is a family of SoCs that includes e.g. BCM4708, BCM47081,
>> >> - BCM4709 and BCM47094. It contains DMU (Device Management Unit) block
>> >> - with a thermal sensor that allows checking CPU temperature. This
>> >> - driver provides support for it.
>> >> + Support for the Northstar and Northstar Plus family of SoCs (e.g.
>> >> + BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU (Device
>> >
>> > Did we look BCM47094 somehow on this patch?
>>
>> Naa, just trying to be more concise, while adding the NSP products to
>> the list.. BCM47094 is a type of BCM4709. So, it is still there :)
>>
>> >
>> >> + Management Unit) block with a thermal sensor that allows checking CPU
>> >> + temperature.
>> >> --
>> >> 2.7.4
>> >>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: add bindings doc for ZTE pinctrl
From: Rob Herring @ 2017-04-28 17:58 UTC (permalink / raw)
To: Shawn Guo
Cc: devicetree, Xin Zhou, Linus Walleij, Baoyou Xie, linux-gpio,
Jun Nie, Shawn Guo, linux-arm-kernel
In-Reply-To: <1493038873-18354-2-git-send-email-shawnguo@kernel.org>
On Mon, Apr 24, 2017 at 09:01:12PM +0800, Shawn Guo wrote:
> From: Shawn Guo <shawn.guo@linaro.org>
>
> It adds device tree bindings for ZTE pin controller found on ZX2967xx
> family SoCs.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> .../devicetree/bindings/pinctrl/pinctrl-zx.txt | 85 ++++++++++++++++++++++
> 1 file changed, 85 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-zx.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] dt: bindings: fpga: add lattice machxo2 slave spi binding description
From: Rob Herring @ 2017-04-28 17:54 UTC (permalink / raw)
To: Paolo Pisati
Cc: Mark Rutland, Alan Tull, Moritz Fischer, devicetree, linux-fpga,
linux-kernel
In-Reply-To: <1492960845-342-2-git-send-email-p.pisati@gmail.com>
On Sun, Apr 23, 2017 at 05:20:44PM +0200, Paolo Pisati wrote:
> Add dt binding documentation details for Lattice MachXO2 FPGA configuration
> over Slave SPI interface.
>
> Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
> ---
> .../bindings/fpga/lattice-machxo2-spi.txt | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/lattice-machxo2-spi.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 01/11] dt-bindings: add binding for the Allwinner DE2 CCU
From: Rob Herring @ 2017-04-28 17:52 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170423103754.50012-2-icenowy-h8G6r0blFSE@public.gmane.org>
On Sun, Apr 23, 2017 at 06:37:44PM +0800, Icenowy Zheng wrote:
> Allwinner "Display Engine 2.0" contains some clock controls in it.
>
> In order to add them as clock drivers, we need a device tree binding.
> Add the binding here.
>
> Also add the device tree binding headers.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> Changes in v5:
> - Moved dt-binding headers here.
> - Changed dt-binding headers' license header to SPDX license.
> Changes in v4:
> - Dropped the leading 0 in clock at 1000000 .
> Changes in v3:
> - Fill the address space length of DE2 CCU to 0x100000, just reach the start of mixer0.
>
> .../devicetree/bindings/clock/sun8i-de2.txt | 31 ++++++++++++++++++++++
> include/dt-bindings/clock/sun8i-de2.h | 18 +++++++++++++
> include/dt-bindings/reset/sun8i-de2.h | 14 ++++++++++
> 3 files changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt
> create mode 100644 include/dt-bindings/clock/sun8i-de2.h
> create mode 100644 include/dt-bindings/reset/sun8i-de2.h
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: phy: Add documentation for Mediatek PCIe PHY
From: Rob Herring @ 2017-04-28 17:52 UTC (permalink / raw)
To: Ryder Lee
Cc: devicetree, linux-kernel, Kishon Vijay Abraham I, linux-mediatek,
Matthias Brugger, linux-arm-kernel
In-Reply-To: <1492935453-17373-3-git-send-email-ryder.lee@mediatek.com>
On Sun, Apr 23, 2017 at 04:17:33PM +0800, Ryder Lee wrote:
> Add documentation for PCIe PHY available in MT7623 series SoCs.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> .../devicetree/bindings/phy/phy-mt7623-pcie.txt | 67 ++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-mt7623-pcie.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-mt7623-pcie.txt b/Documentation/devicetree/bindings/phy/phy-mt7623-pcie.txt
> new file mode 100644
> index 0000000..27a9253
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-mt7623-pcie.txt
> @@ -0,0 +1,67 @@
> +Mediatek MT7623 PCIe PHY
> +-----------------------
> +
> +Required properties:
> + - compatible: Should contain "mediatek,mt7623-pcie-phy"
> + - #phy-cells: must be 0
> + - clocks: Must contain an entry in clock-names.
> + See ../clocks/clock-bindings.txt for details.
> + - clock-names: Must be "refclk"
> + - resets: Must contain an entry in reset-names.
> + See ../reset/reset.txt for details.
> + - reset-names: Must be "phy"
> +
> +Optional properties:
> + - phy-switch: The PHY on PCIe port2 is shared with USB u3phy2. If you
> + want to enable port2, you should contain it.
Need to state what the value is (i.e. a phandle to ?). Also needs a
vendor prefix.
> +
> +Example:
> +
> + pcie0_phy: pciephy@1a149000 {
pcie-phy@...
> + compatible = "mediatek,mt7623-pcie-phy";
> + reg = <0 0x1a149000 0 0x1000>;
> + clocks = <&clk26m>;
> + clock-names = "pciephya_ref";
> + #phy-cells = <0>;
> + status = "disabled";
Don't show status in examples.
> + };
> +
> + pcie1_phy: pciephy@1a14a000 {
> + compatible = "mediatek,mt7623-pcie-phy";
> + reg = <0 0x1a14a000 0 0x1000>;
> + clocks = <&clk26m>;
> + clock-names = "pciephya_ref";
> + #phy-cells = <0>;
> + status = "disabled";
> + };
> +
> + pcie2_phy: pciephy@1a244000 {
> + compatible = "mediatek,mt7623-pcie-phy";
> + reg = <0 0x1a244000 0 0x1000>;
> + clocks = <&clk26m>;
> + clock-names = "pciephya_ref";
> + #phy-cells = <0>;
> +
> + phy-switch = <&hifsys>;
> + status = "disabled";
> + };
> +
> +Specifying phy control of devices
> +---------------------------------
> +
> +Device nodes should specify the configuration required in their "phys"
> +property, containing a phandle to the phy node and phy-names.
> +
> +Example:
> +
> +#include <dt-bindings/phy/phy.h>
> +
> +pcie: pcie@1a140000 {
> + ...
> + pcie@1,0 {
> + ...
> + phys = <&pcie0_phy>;
> + phy-names = "pcie-phy0";
> + }
> + ...
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [RFC 1/3] dt-binding: soc: qcom: Add binding for RFSA
From: Rob Herring @ 2017-04-28 17:42 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, David Brown, Frank Rowand, Mark Rutland,
linux-arm-msm, linux-soc, devicetree, linux-kernel
In-Reply-To: <20170422173519.5782-1-bjorn.andersson@linaro.org>
On Sat, Apr 22, 2017 at 10:35:17AM -0700, Bjorn Andersson wrote:
> This adds the binding for describing shared memory buffers for
> implementing the remote filesystem protocol.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> My initial attempt was to mimic the ramoops of just adding the compatible to
> the reserved-memory node, but I have not been able to figure out a sane way of
> getting hold of the base address in the case that the memory region is
> described my a "size" only (done on some platforms).
I prefer the ramoops way.
> The problem is that we create the reserved_mem objects (and remove the
> memblocks) while we're still operating on the flattened representation, so
> without a phandle it doesn't seem like we have anything to perform the
> comparison with later on.
I'm not sure I follow.
>
> .../devicetree/bindings/soc/qcom/qcom,rfsa.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,rfsa.txt
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rfsa.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,rfsa.txt
> new file mode 100644
> index 000000000000..b4de0de74e46
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rfsa.txt
> @@ -0,0 +1,43 @@
> +Qualcomm Remote File System Access binding
> +
> +This binding describes the Qualcomm RFSA, which serves the purpose of managing
> +the shared memory region used for remote processors to access block device data
> +using the Remote Filesystem protocol.
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be:
> + "qcom,rfsa"
No versioning?
> +
> +- memory-region:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: handle to memory reservation the associated rfsa region.
> +
> +- qcom,client-id:
> + Usage: required
> + Value type: <u32>
> + Definition: identifier of the client to use this region for buffers.
What determines these numbers?
> +
> += EXAMPLE
> +The following example shows the RFSA setup for APQ8016, with the RFSA region
> +for the Hexagon DSP (id #1) located at 0x86700000.
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + rmtfs: rmtfs@86700000 {
I think you should have a compatible here even with the 2 node approach.
> + reg = <0x0 0x86700000 0x0 0xe0000>;
> + no-map;
> + };
> + };
> +
> + hexagon-rfsa {
> + compatible = "qcom,rfsa";
> + memory-region = <&rmtfs>;
> +
> + qcom,client-id = <1>;
> + };
> --
> 2.12.0
>
^ permalink raw reply
* Re: [PATCH v2 3/5] mtd: gpmi: document current clock requirements
From: Rob Herring @ 2017-04-28 17:13 UTC (permalink / raw)
To: Stefan Agner
Cc: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w, richard-/L3Ra7n9ekc,
cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
han.xu-3arQi8VN3Tc, fabio.estevam-KZfg59tc24xl57MIdRCFDg,
LW-bxm8fMRDkQLDiMYJYoSAnRvVK+yQ3ZXh,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170422012338.4635-4-stefan-XLVq0VzYD2Y@public.gmane.org>
On Fri, Apr 21, 2017 at 06:23:36PM -0700, Stefan Agner wrote:
> The clock requirements are completely missing, add the clocks
> currently required by the driver.
>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mtd/gpmi-nand.txt | 14 +++++++++++++-
> 1 file changed, 13 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] streamline TLV320AIC23 drivers
From: Rob Herring @ 2017-04-28 17:11 UTC (permalink / raw)
To: Jens Rottmann
Cc: Mark Rutland, Jaroslav Kysela, Takashi Iwai,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Liam Girdwood, Mark Brown
In-Reply-To: <b4127646-565b-ab16-0a8f-1fd6c263389e-AbX7Xxim+f4qDJ6do+/SaQ@public.gmane.org>
On Fri, Apr 21, 2017 at 09:22:02PM +0200, Jens Rottmann wrote:
> The iMX-TLV320AIC23 driver isn't from Freescale, but from a company named
> Eukrea Electromatique, originally for their own boards. From the code I get
> the impression it is a bit older, its DT options use a differing naming
> scheme. Patch it up a bit:
Needs a subject following the format of the subsystem.
>
> - Remove Eukrea naming, i.MX is from Freescale, TLV320AIC23 is from TI,
> driver was written by Eukrea, but it's DT capable, so it's not exclusive:
> - Kconfig option title
> - 'model' option
> - driver 'compatible' string
> - Other options just have changed over time, this driver remaining (one of)
> the last with the old semantics:
> - 'audio-codec' option (also moved from ssi node)
> - 'mux-int/ext-port' options
> - All options stay backwards compatible, the DT binding documents new and
> old names.
>
> CONFIG variable and files have not been renamed, though, so no need to
> change old defconfigs.
>
> Signed-off-by: Jens Rottmann <Jens.Rottmann-AbX7Xxim+f4qDJ6do+/SaQ@public.gmane.org>
> ---
>
> --- a/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt
> +++ b/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt
Perhaps change the filename. The compatible string is a good choice.
> @@ -1,16 +1,23 @@
> -Audio complex for Eukrea boards with tlv320aic23 codec.
> +Audio complex for Freescale i.MX boards with TI TLV320AIC23 I2S codecs,
> +like those from Eukrea Electromatique.
>
> Required properties:
>
> - - compatible : "eukrea,asoc-tlv320"
> + - compatible : "fsl,imx-audio-tlv320aic23" or
> + "eukrea,asoc-tlv320" (deprecated)
>
> - - eukrea,model : The user-visible name of this sound complex.
> + - model : The user-visible name of this sound complex.
> + - eukrea,model : Dito, deprecated.
>
> - ssi-controller : The phandle of the SSI controller.
>
> - - fsl,mux-int-port : The internal port of the i.MX audio muxer (AUDMUX).
> + - mux-int-port : The internal port of the i.MX audio muxer (AUDMUX).
> + - fsl,mux-int-port : Dito, deprecated.
>
> - - fsl,mux-ext-port : The external port of the i.MX audio muxer.
> + - mux-ext-port : The external port of the i.MX audio muxer.
> + - fsl,mux-ext-port : Dito, deprecated.
Is this used elsewhere? This is FSL specific, so you should keep the
prefix.
> +
> + - audio-codec : The phandle of the audio codec.
>
> Note: The AUDMUX port numbering should start at 1, which is consistent with
> hardware manual.
> @@ -18,9 +25,10 @@ hardware manual.
> Example:
>
> sound {
> - compatible = "eukrea,asoc-tlv320";
> - eukrea,model = "imx51-eukrea-tlv320aic23";
> + compatible = "fsl,imx-audio-tlv320aic23";
> + model = "imx51-eukrea-tlv320aic23";
> ssi-controller = <&ssi2>;
> - fsl,mux-int-port = <2>;
> - fsl,mux-ext-port = <3>;
> + mux-int-port = <2>;
> + mux-ext-port = <3>;
> + audio-codec = <&codec>;
> };
--
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 5/7] ASoC: Add Odroid sound DT bindings documentation
From: Rob Herring @ 2017-04-28 17:03 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: linux-samsung-soc, linux-clk, dri-devel, alsa-devel, devicetree,
inki.dae, sw0312.kim, cw00.choi, javier, krzk, jy0922.shim,
broonie, b.zolnierkie
In-Reply-To: <1492795191-31298-6-git-send-email-s.nawrocki@samsung.com>
On Fri, Apr 21, 2017 at 07:19:49PM +0200, Sylwester Nawrocki wrote:
> This patch adds DT binding documentation for Odroid XU3/4
> sound subsystem.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> .../devicetree/bindings/sound/samsung,odroid.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/samsung,odroid.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.txt b/Documentation/devicetree/bindings/sound/samsung,odroid.txt
> new file mode 100644
> index 0000000..c1ac70c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.txt
> @@ -0,0 +1,57 @@
> +Samsung Exynos Odroid XU3/XU4 audio complex with MAX98090 codec
> +
> +Required properties:
> +
> + - compatible - "samsung,odroidxu3-audio" - for Odroid XU3 board,
> + "samsung,odroidxu4-audio" - for Odroid XU4 board
> + - model - the user-visible name of this sound complex
ASoC will support "label" soon (see graph support). Use that instead.
> + - 'cpu' subnode with a 'sound-dai' property containing the phandle of the I2S
> + controller
> + - 'codec' subnode with a 'sound-dai' property containing list of phandles
> + to the CODEC nodes, first entry must be corresponding to the MAX98090
> + CODEC and the second entry must be the phandle of the HDMI IP block node
These are not properties, so move them to a sub-node section.
> + - clocks - should contain entries matching clock names in the clock-names
> + property
> + - clock-names - should contain following entries:
> + - "epll" - indicating the EPLL output clock
> + - "i2s_rclk" - indicating the RCLK (root) clock of the I2S0 controller
At least the 2nd one should be in the i2s node. This node isn't really a
h/w block, so it shouldn't have clocks IMO.
> + - samsung,audio-widgets - this property specifies off-codec audio elements
> + like headphones or speakers, for details see widgets.txt
> + - samsung,audio-routing - a list of the connections between audio
> + components; each entry is a pair of strings, the first being the
> + connection's sink, the second being the connection's source;
> + valid names for sources and sinks are the MAX98090's pins (as
> + documented in its binding), and the jacks on the board
> +
> + For Odroid X2:
> + "Headphone Jack", "Mic Jack", "DMIC"
> +
> + For Odroid U3, XU3:
> + "Headphone Jack", "Speakers"
> +
> + For Odroid XU4:
> + no entries
> +
> +Example:
> +
> +sound {
> + compatible = "samsung,odroidxu3-audio";
> + samsung,cpu-dai = <&i2s0>;
> + samsung,codec-dai = <&max98090>;
Not documented. Nor needed?
> + model = "Odroid-XU3";
> + samsung,audio-routing =
> + "Headphone Jack", "HPL",
> + "Headphone Jack", "HPR",
> + "IN1", "Mic Jack",
> + "Mic Jack", "MICBIAS";
> +
> + clocks = <&clock CLK_FOUT_EPLL>, <&i2s0 CLK_I2S_RCLK_SRC>;
> + clock-names = "epll", "sclk_i2s";
> +
> + cpu {
> + sound-dai = <&i2s0 0>;
> + };
> + codec {
> + sound-dai = <&hdmi>, <&max98090>;
> + };
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v2] power: tps65217_charger: Add properties like voltage and current charge
From: Rob Herring @ 2017-04-28 16:49 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Sebastian Reichel, Mark Rutland, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170421155032.22784-1-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On Fri, Apr 21, 2017 at 05:50:32PM +0200, Enric Balletbo i Serra wrote:
> Allow the possibility to configure the charge and the current voltage of
> the charger and also the NTC type for battery temperature measurement.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> ---
> Changes since v1:
> - Requested by Rob Herring
> - Rename ti,charge-* to charge-* to be standard properties.
> - Use unit suffixes as per bindings/property-units.txt
> ---
> .../bindings/power/supply/tps65217_charger.txt | 15 ++
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/power/supply/tps65217_charger.c | 187 +++++++++++++++++++--
> include/linux/mfd/tps65217.h | 2 +
> 3 files changed, 192 insertions(+), 12 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 v5 01/10] pinctrl: generic: Add bi-directional and output-enable
From: Chris Brandt @ 2017-04-28 16:46 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Linus Walleij, Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart,
Rob Herring, Mark Rutland, Russell King - ARM Linux,
Linux-Renesas, linux-gpio@vger.kernel.org, devicetree,
linux-kernel@vger.kernel.org
In-Reply-To: <CAHp75VfYPfm_GKPzvX7Go010fRi99t12ub7VUPubB6z3HnsFLg@mail.gmail.com>
On Friday, April 28, 2017, Andy Shevchenko wrote:
> > We were using "input-enable" to signal when the pin function that we set
> also needs to be forcible set to input by the software (once again,
> because the HW is not smart enough to do it on its own), but is different
> than the bi-directional functionality (ie, a different register setting).
>
> You are trying to introduce an abstraction, called BiDi, which is
> *not* a separate thing from a set of pin properties.
Note, I'm talking about 2 different issues we had:
1) Pins that need input and output buffers enabled during normal use. We created "bi-directional" for that.
2) For whatever reason, the HW manual points out that the PFC hardware can't really automatically set buffers enables correctly for some pin instances, and we have to manually assign the pin as input or output using another register. For that, we were using "input-enable" and "output-enable".
For #2:
> > Note that we added a enable-output for the same reason.
> > See RZ/A1H HW Manual section "Table 54.7 Alternative Functions that
> PIPCn.PIPCnm Bit Should be Set to 0"
>
> Perhaps needs to be revisited as well.
Sorry, we didn't 'add' anything new. The property "output-enable", (ie, PIN_CONFIG_OUTPUT) already existed and describes what we are doing in the case for output.
But, we still have the issue that we have 2 cases that need the input enabled, but they are not the same situation, so we can't just use "input-enable" for both.
My only suggestion is (and I'm not sure this is possible in the driver):
"input-enable" : case #2 where you need the pin to be forced as an input
"output-enable" : case #2 where you need the pin to be forced as an output
"input-enable" + "output-enable" : case #1 (replaces "bi-directional").
For example:
i2c2_pins: i2c2 {
pinmux = <RZA1_PINMUX(1, 4, 1)>, <RZA1_PINMUX(1, 5, 1)>;
input-enable;
output-enable;
};
So in the SW driver, if we see both, that will signal to us what is going on and what to do about it (as in, set the bi-directional register and not the input direction register).
Thoughts?
Chris
^ permalink raw reply
* Re: linux-next: Tree for Apr 28 (of/unittest)
From: Randy Dunlap @ 2017-04-28 16:44 UTC (permalink / raw)
To: Stephen Rothwell, Linux-Next Mailing List
Cc: Linux Kernel Mailing List, devicetree@vger.kernel.org
In-Reply-To: <20170428171121.4a21b861@canb.auug.org.au>
On 04/28/17 00:11, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20170427:
>
on i386:
when CONFIG_OF_OVERLAY is not enabled:
drivers/built-in.o: In function `unflatten_device_tree':
(.init.text+0x1209f): undefined reference to `unittest_unflatten_overlay_base'
--
~Randy
^ permalink raw reply
* Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties
From: Andy Shevchenko @ 2017-04-28 16:23 UTC (permalink / raw)
To: Linus Walleij
Cc: Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart, Chris Brandt,
Rob Herring, Mark Rutland, Russell King, Linux-Renesas,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdbkBtJGJ_5MVy2QSAa0zcKVm=_H+vC_kH4AUcX58TiaLg@mail.gmail.com>
On Fri, Apr 28, 2017 at 11:16 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:
> But why.
>
> I have these two static inlines just below your new macros:
+1.
> We generally prefer static inlines over macros because they are easier
> to read.
Not only. It adds type checking as well AFAIUC.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 2/2] of: Add unit tests for applying overlays
From: Geert Uytterhoeven @ 2017-04-28 16:13 UTC (permalink / raw)
To: Frank Rowand
Cc: Rob Herring, stephen.boyd, Michal Marek,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kbuild
In-Reply-To: <59035E93.2060106@gmail.com>
Hi Frank,
On Fri, Apr 28, 2017 at 5:24 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> On 04/28/17 04:25, Geert Uytterhoeven wrote:
>> On Wed, Apr 26, 2017 at 2:09 AM, <frowand.list@gmail.com> wrote:
>>> create mode 100644 drivers/of/unittest-data/overlay.dts
>>> create mode 100644 drivers/of/unittest-data/overlay_bad_phandle.dts
>>> create mode 100644 drivers/of/unittest-data/overlay_base.dts
>>
>> Shouldn't these be called .dtso instead of .dts?
>
> That is a good question. I'm not worried about solving it this week for
> this patch, because this could turn into a bikeshed and I can always
> fix it with a patch if we decide to change. But if we do want to change
> the naming, I would like to make the decision in the next couple of
> months. I would like to see more progress on overlays in general
> this summer, and plan to be working on them myself.
>
> I _think_ there has been some discussion about source file naming on the
> devicetree-compiler or devicetree list in the far distant past. Or I
> may just be mis-remembering.
>
> As far as I know, the current dtc does not know any suffixes other than
> .dts for source files. Not that the compiler has to know, we can always
> specify '-I dts'.
That's not an obstacle, though. I've been compiling .dtso files into .dtbo
files for several years, cfr.
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/renesas-overlays
According to "make V=1", the kernel build system basically uses
./scripts/dtc/dtc -O dtb -o <file>.dtbo <file>.dtbo.dts.tmp
with <file>.dtbo.dts.tmp the preprocessed .dtso files.
And dtc copes fine with that.
>>> --- a/drivers/of/unittest-data/Makefile
>>> +++ b/drivers/of/unittest-data/Makefile
>>
>>> +# enable creation of __symbols__ node
>>> +DTC_FLAGS_overlay := -@
>>> +DTC_FLAGS_overlay_bad_phandle := -@
>>> +DTC_FLAGS_overlay_base := -@
>>
>> This flag is needed for all DTs that will be involved with overlays.
>>
>> Hence what about enabling this globally instead, cfr. "Enable DT symbols when"
>> CONFIG_OF_OVERLAY is used
>> ("http://www.spinics.net/lists/devicetree/msg103363.html")?
>
> And another really good question.
>
> There are some issues. I have thought about it enough to know there are issues,
> but do not have a solution and do not think I know all the issues. Some
> possible issues (or perceived issues) are:
>
> - The size of __symbols__ in an FDT (akd compile .dtb image) in either a kernel
> image or a bootloader if overlays are not actually needed on a given system
> (even if the system is physically capable of using overlays).
What do you mean with "physically capable of using overlays"?
The presence of expansion connectors, like Raspberry Pi and BeagleBone Black?
Even lacking such connectors, an overlay could add hardware description that
was just missing (forgotten, or lack of DT bindings) when the main DTB was
built.
I agree about the size, but you never know in advance if an overlay will
be used or needed later.
> - The size of __symbols__ in kernel memory if overlays are not actually needed
> on a given system (even if the system is physically capable of using overlays.)
> This could be possibly be enabled/disabled by a boot command, even if
> __symbols__ is in the FDT.
Agreed. Not allowing overlays is akin to not allowing to load (more) kernel
modules, and may increase security.
> - A base FDT might want to have __symbols__ included with the expectation that
> overlays will be used in the future. (The FDT might be built for the boot
> loader, then be stable for many kernel releases.)
>
> - Should the creation of __symbols__ be a global switch, or should it be
> controlled on a per dtb basis? Or a combination of both?
So you want to decouple OF overlay support in the Linux kernel from
__symbols__ present in the DTBs built?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] of: fix uninitialized variable warning for overlay test
From: Frank Rowand @ 2017-04-28 15:46 UTC (permalink / raw)
To: Arnd Bergmann, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170428094429.2396195-1-arnd-r2nGTMty4D4@public.gmane.org>
On 04/28/17 02:44, Arnd Bergmann wrote:
> gcc warns that an empty device tree would cause undefined behavior:
>
> drivers/of/unittest.c: In function 'of_unittest':
> drivers/of/unittest.c:2199:25: warning: 'last_sibling' may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> This adds an initialization of the variable to zero, which we handle
> correctly.
>
> Fixes: 81d0848fc8d2 ("of: Add unit tests for applying overlays")
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> ---
> drivers/of/unittest.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 12597ff8cfb0..6b8f3e6aa43c 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -2192,7 +2192,7 @@ static __init void of_unittest_overlay_high_level(void)
>
> mutex_lock(&of_mutex);
>
> - for (np = of_root->child; np; np = np->sibling)
> + for (last_sibling = np = of_root->child; np; np = np->sibling)
> last_sibling = np;
>
> if (last_sibling)
>
Thanks Arnd! Linux-next also reported this and I sent Rob a different
patch for it yesterday.
Rob, I am fine with either Arnd's patch or mine, they both fix the
problem.
-Frank
--
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 2/2] of: fix unittest build without CONFIG_OF_OVERLAY
From: Frank Rowand @ 2017-04-28 15:40 UTC (permalink / raw)
To: Arnd Bergmann, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170428094429.2396195-2-arnd-r2nGTMty4D4@public.gmane.org>
On 04/28/17 02:44, Arnd Bergmann wrote:
> We get a link error when the new tests are used by overlays
> are not:
>
> drivers/of/built-in.o: In function `unflatten_device_tree':
> (.init.text+0x967): undefined reference to `unittest_unflatten_overlay_base'
>
> This makes the #ifdef check match the symbols that lead to building
> the unittest_unflatten_overlay_base function.
>
> Fixes: 81d0848fc8d2 ("of: Add unit tests for applying overlays")
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> ---
> drivers/of/of_private.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
> index de5c604f5cc4..4ebb0149d118 100644
> --- a/drivers/of/of_private.h
> +++ b/drivers/of/of_private.h
> @@ -55,7 +55,7 @@ static inline int of_property_notify(int action, struct device_node *np,
> }
> #endif /* CONFIG_OF_DYNAMIC */
>
> -#ifdef CONFIG_OF_UNITTEST
> +#if defined(CONFIG_OF_UNITTEST) && defined(CONFIG_OF_OVERLAY)
> extern void __init unittest_unflatten_overlay_base(void);
> #else
> static inline void unittest_unflatten_overlay_base(void) {};
>
I thought I had tested that OF_UNITTEST forced OF_OVERLAY. But
going back and trying again, I can confirm your results that it
does not. Thanks for catching this!
Reviewed-by: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
Tested-by: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: r7s72100: add usb clocks to device tree
From: Simon Horman @ 2017-04-28 15:39 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Chris Brandt, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <CAMuHMdXp75yepEMh-S0YNYqKRESb4m3DtcfG09x=uj1Fm51b_A@mail.gmail.com>
On Fri, Apr 28, 2017 at 04:27:45PM +0200, Geert Uytterhoeven wrote:
> Hi Chris,
>
> On Fri, Apr 28, 2017 at 2:47 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> > On Friday, April 28, 2017, Simon Horman wrote:
> >> On Fri, Apr 28, 2017 at 09:34:54AM +0200, Geert Uytterhoeven wrote:
> >> > On Thu, Apr 27, 2017 at 9:10 PM, Chris Brandt <chris.brandt@renesas.com>
> >> wrote:
> >> > > This adds the USB0 and USB1 clocks to the device tree.
>
> >> > Simon: see Section 29.3.2 (BUSWAIT) for the reference to the P1 clock.
> >>
> >> Thanks, I see that now.
> >
> > I was going to say that I simply look at sections:
> > 6.10.6 Internal Clock Signals (1)
> > 6.10.7 Internal Clock Signals (2)
> >
> > Because it lists all the IP blocks and their corresponding clock sources in one place.
>
> Cool, I grew up with rev. 0.60 of the user manual, so I wasn't aware of
> that secton.
Thanks, now I'm not looking at 0.60 any more I see the sections Chris
mentions too.
^ permalink raw reply
* Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
From: Andy Shevchenko @ 2017-04-28 15:37 UTC (permalink / raw)
To: Chris Brandt
Cc: Linus Walleij, Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart,
Rob Herring, Mark Rutland, Russell King - ARM Linux,
Linux-Renesas, linux-gpio@vger.kernel.org, devicetree,
linux-kernel@vger.kernel.org
In-Reply-To: <SG2PR06MB11658E6434EB343246ADC9F58A130@SG2PR06MB1165.apcprd06.prod.outlook.com>
On Fri, Apr 28, 2017 at 6:16 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Friday, April 28, 2017, Andy Shevchenko wrote:
>> Had you read the following, esp. Note there?
>>
>> * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input. Note that this does
>> not
>> * affect the pin's ability to drive output. 1 enables input, 0
>> disables
>> * input.
>>
>> For me manual is clearly tells about this settings:
>> "This register enables or disables the input buffer while the output
>> buffer is enabled."
>
>
> But, then if we use "input-enable" to get bi-directional functionality,
It seems you are missing the point from electrical prospective.
Standard pin buffers (electrically) means input buffer and output
buffer that are driven independently in most cases.
Here is one example:
https://electronics.stackexchange.com/questions/96932/internal-circuitry-of-io-ports-in-mcu/96953#96953
(That's what I asked before as a schematic)
> now we need something to replace what we were using "input-enable" for.
No.
> We were using "input-enable" to signal when the pin function that we set also needs to be forcible set to input by the software (once again, because the HW is not smart enough to do it on its own), but is different than the bi-directional functionality (ie, a different register setting).
You are trying to introduce an abstraction, called BiDi, which is
*not* a separate thing from a set of pin properties.
> So, if we replace "bi-directional" with "input-enable" (since logically internally that is what is going on), what do we use for the special pins that the HW manual says "hey, you need to manually set these pins to input with SW because the pin selection HW can't do it correctly)".
Yes.
BiDi is an alias to output + input enable + other pin configuration
parameters (a set depends on real HW needs).
> Note that we added a enable-output for the same reason.
> See RZ/A1H HW Manual section "Table 54.7 Alternative Functions that PIPCn.PIPCnm Bit Should be Set to 0"
Perhaps needs to be revisited as well.
P.S. It looks like more and more software engineers are going far from
real hardware when developing drivers...
--
With Best Regards,
Andy Shevchenko
^ 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