* [PATCH 03/11] ARM: shmobile: r8a7745: basic SoC support
From: Rob Herring @ 2016-10-31 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1638480.5pJxF7pUnz@wasted.cogentembedded.com>
On Sat, Oct 29, 2016 at 01:16:54AM +0300, Sergei Shtylyov wrote:
> Add minimal support for the RZ/G1E (R8A7745) SoC.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
Acked-by: Rob Herring <robh@kernel.org>
> arch/arm/mach-shmobile/Kconfig | 4 ++++
> arch/arm/mach-shmobile/setup-rcar-gen2.c | 1 +
> 3 files changed, 7 insertions(+)
^ permalink raw reply
* [PATCH v2 3/6] Documentation: devicetree: net: add NS2 bindings to amac
From: Rob Herring @ 2016-10-31 6:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477688219-3871-4-git-send-email-jon.mason@broadcom.com>
On Fri, Oct 28, 2016 at 04:56:56PM -0400, Jon Mason wrote:
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> Documentation/devicetree/bindings/net/brcm,amac.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
> index ba5ecc1..f2b194e 100644
> --- a/Documentation/devicetree/bindings/net/brcm,amac.txt
> +++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
> @@ -2,11 +2,12 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
> -------------------------------------------------------------
>
> Required properties:
> - - compatible: "brcm,amac" or "brcm,nsp-amac"
> + - compatible: "brcm,amac", "brcm,nsp-amac", or "brcm,ns2-amac"
One per line is preferred.
> - reg: Address and length of the GMAC registers,
> Address and length of the GMAC IDM registers
> + Address and length of the NIC Port Manager registers (optional)
> - reg-names: Names of the registers. Must have both "amac_base" and
> - "idm_base"
> + "idm_base". "nicpm_base" is optional (required for NS2)
Is nicpm_base optional on some SoCs? If not just say which ones it
applies to. A separate line will make that clearer.
_base is kind of redundant too, but it's already done.
> - interrupts: Interrupt number
>
> Optional properties:
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 2/5] doc: dt: add cyclone-spi binding document
From: Rob Herring @ 2016-10-31 6:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2de74f6d2f2689b8ef090a9017db2ffb3bd319cb.1477669745.git.stillcompiling@gmail.com>
On Fri, Oct 28, 2016 at 09:56:39AM -0700, Joshua Clayton wrote:
> Describe a cyclonei-ps-spi devicetree entry, required features
>
> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
> ---
> .../bindings/fpga/cyclone-ps-spi-fpga-mgr.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
>
> diff --git a/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
> new file mode 100644
> index 0000000..c942281
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
> @@ -0,0 +1,23 @@
> +Altera Cyclone Passive Serial SPI FPGA Manager
> +
> +Altera Cyclone FPGAs support a method of loading the bitstream over what is
> +referred to as "passive serial".
> +The passive serial link is not technically spi, and might require extra
> +circuits in order to play nicely with other spi slaves on the same bus.
> +
> +See https://www.altera.com/literature/hb/cyc/cyc_c51013.pdf
> +
> +Required properties:
> +- compatible : should contain "altr,cyclone-ps-spi-fpga-mgr"
> +- reg : spi slave id of the fpga
> +- config-gpio : config pin (referred to as nCONFIG in the cyclone manual)
> +- status-gpio : status pin (referred to as nSTATUS in the cyclone manual)
'-gpios' is the preferred form.
Looks like active low to me with nXXXX, but the example says active
high. Please be specific here.
> +
> +Example:
> + fpga_spi: evi-fpga-spi at 0 {
> + compatible = "altr,cyclone-ps-spi-fpga-mgr";
> + spi-max-frequency = <20000000>;
> + reg = <0>;
> + config-gpio = <&gpio4 9 GPIO_ACTIVE_HIGH>;
> + status-gpio = <&gpio4 11 GPIO_ACTIVE_HIGH>;
> + };
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 3/4] spi: sun6i: Add binding for Allwinner H3 SPI controller
From: Rob Herring @ 2016-10-31 6:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028065412.23008-4-woogyom.kim@gmail.com>
On Fri, Oct 28, 2016 at 03:54:11PM +0900, Milo Kim wrote:
> H3 SPI has same architecture as A31 except FIFO capacity.
> To configure the buffer size separately, compatible property should be
> different. Optional DMA specifiers and example are added.
>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
> ---
> .../devicetree/bindings/spi/spi-sun6i.txt | 25 ++++++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 2/3] dt-bindings: reset: Add K2G reset definitions
From: Rob Herring @ 2016-10-31 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027214941.24641-3-afd@ti.com>
On Thu, Oct 27, 2016 at 04:49:40PM -0500, Andrew F. Davis wrote:
> Add identifiers for the K2G resets managed by the PMMC.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> ---
> MAINTAINERS | 1 +
> include/dt-bindings/reset/k2g.h | 22 ++++++++++++++++++++++
> 2 files changed, 23 insertions(+)
> create mode 100644 include/dt-bindings/reset/k2g.h
This belongs with the previous patch. It is part of the binding
definition.
Rob
^ permalink raw reply
* [PATCHv2 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor
From: Rob Herring @ 2016-10-31 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477598426-28125-2-git-send-email-tthayer@opensource.altera.com>
On Thu, Oct 27, 2016 at 03:00:23PM -0500, tthayer at opensource.altera.com wrote:
> From: Thor Thayer <tthayer@opensource.altera.com>
>
> Add the Arria10 DevKit System Resource Chip register and state
> monitoring module to the MFD.
>
> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
> ---
> Note: This needs to be applied to the bindings document that
> was Acked & Applied but didn't reach the for-next branch.
> See https://patchwork.ozlabs.org/patch/629397/
> ---
> v2 Change compatible string -mon to -monitor for clarity
> ---
> Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
> index ea151f2..c47be28 100644
> --- a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
> +++ b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
> @@ -18,6 +18,7 @@ The A10SR consists of these sub-devices:
> Device Description
> ------ ----------
> a10sr_gpio GPIO Controller
This should be just "gpio" BTW.
> +a10sr_monitor Register and State Monitoring
s/_/-/ or maybe just "monitor". Not really a generic node name to use
for this.
Rob
^ permalink raw reply
* [PATCH V3 3/6] dt/bindings: Add bindings for Tegra GMI controller
From: Rob Herring @ 2016-10-31 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477576872-2665-4-git-send-email-mirza.krak@gmail.com>
On Thu, Oct 27, 2016 at 04:01:09PM +0200, Mirza Krak wrote:
> From: Mirza Krak <mirza.krak@gmail.com>
>
> Document the devicetree bindings for the Generic Memory Interface (GMI)
> bus driver found on Tegra SOCs.
>
> Signed-off-by: Mirza Krak <mirza.krak@gmail.com>
> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
> ---
>
> Changes in v2:
> - Updated examples and some information based on comments from Jon Hunter.
>
> Changes in v3:
> - Updates ranges description based on comments from Rob Herring
>
> .../devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 132 +++++++++++++++++++++
> 1 file changed, 132 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
> new file mode 100644
> index 0000000..49bda2f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
> @@ -0,0 +1,132 @@
> +Device tree bindings for NVIDIA Tegra Generic Memory Interface bus
> +
> +The Generic Memory Interface bus enables memory transfers between internal and
> +external memory. Can be used to attach various high speed devices such as
> +synchronous/asynchronous NOR, FPGA, UARTS and more.
> +
> +The actual devices are instantiated from the child nodes of a GMI node.
> +
> +Required properties:
> + - compatible : Should contain one of the following:
> + For Tegra20 must contain "nvidia,tegra20-gmi".
> + For Tegra30 must contain "nvidia,tegra30-gmi".
> + - reg: Should contain GMI controller registers location and length.
> + - clocks: Must contain an entry for each entry in clock-names.
> + - clock-names: Must include the following entries: "gmi"
> + - resets : Must contain an entry for each entry in reset-names.
> + - reset-names : Must include the following entries: "gmi"
> + - #address-cells: The number of cells used to represent physical base
> + addresses in the GMI address space. Should be 2.
> + - #size-cells: The number of cells used to represent the size of an address
> + range in the GMI address space. Should be 1.
> + - ranges: Must be set up to reflect the memory layout with three integer values
> + for each chip-select line in use (only one entry is supported, see below
> + comments):
> + <cs-number> <offset> <physical address of mapping> <size>
> +
> +Note that the GMI controller does not have any internal chip-select address
> +decoding, because of that chip-selects either need to be managed via software
> +or by employing external chip-select decoding logic.
> +
> +If external chip-select logic is used to support multiple devices it is assumed
> +that the devices use the same timing and so are probably the same type. It also
> +assumes that they can fit in the 256MB address range. In this case only one
> +child device is supported which represents the active chip-select line, see
> +examples for more insight.
> +
> +The chip-select number is decoded from the child nodes second address cell of
> +'ranges' property, if 'ranges' property is not present or empty chip-select will
> +then be decoded from the first cell of the 'reg' property.
> +
> +Optional child cs node properties:
> +
> + - nvidia,snor-data-width-32bit: Use 32bit data-bus, default is 16bit.
> + - nvidia,snor-mux-mode: Enable address/data MUX mode.
> + - nvidia,snor-rdy-active-before-data: Assert RDY signal one cycle before data.
> + If omitted it will be asserted with data.
> + - nvidia,snor-rdy-inv: RDY signal is active high
> + - nvidia,snor-adv-inv: ADV signal is active high
> + - nvidia,snor-oe-inv: WE/OE signal is active high
> + - nvidia,snor-cs-inv: CS signal is active high
Inverted is meaningless unless I know what not inverted state is. Name
the properties using "active high".
With that,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 1/4] dt/bindings: Add binding for the DA8xx MUSB driver
From: Rob Herring @ 2016-10-31 5:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477560847-8929-2-git-send-email-abailon@baylibre.com>
On Thu, Oct 27, 2016 at 11:34:04AM +0200, Alexandre Bailon wrote:
> From: Petr Kulhavy <petr@barix.com>
>
> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
>
> Signed-off-by: Petr Kulhavy <petr@barix.com>
> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
> ---
> .../devicetree/bindings/usb/da8xx-usb.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 1/4] arm64: arch_timer: Add device tree binding for hisilicon-161601 erratum
From: Rob Herring @ 2016-10-31 5:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477553651-13428-1-git-send-email-dingtianhong@huawei.com>
On Thu, Oct 27, 2016 at 03:34:08PM +0800, Ding Tianhong wrote:
> This erratum describes a bug in logic outside the core, so MIDR can't be
> used to identify its presence, and reading an SoC-specific revision
> register from common arch timer code would be awkward. So, describe it
> in the device tree.
>
> v2: Use the new erratum name and update the description.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/2] DT: binding: bcm2835-mbox: fix address typo in example
From: Rob Herring @ 2016-10-31 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477505640-26658-1-git-send-email-stefan.wahren@i2se.com>
On Wed, Oct 26, 2016 at 06:13:59PM +0000, Stefan Wahren wrote:
> The address of the mailbox node in the example has a typo.
> So fix it accordingly.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> Fixes: d4b5c782b9f4 ("dt/bindings: Add binding for the BCM2835 mailbox driver")
> ---
> .../bindings/mailbox/brcm,bcm2835-mbox.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver
From: Rob Herring @ 2016-10-31 4:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477503355-2600-3-git-send-email-bgolaszewski@baylibre.com>
On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
> Create the driver for the da8xx master peripheral priority
> configuration and implement support for writing to the three
> Master Priority registers on da850 SoCs.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
> drivers/bus/Kconfig | 9 +
> drivers/bus/Makefile | 2 +
> drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
> 4 files changed, 297 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
> create mode 100644 drivers/bus/da8xx-mstpri.c
>
> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
> new file mode 100644
> index 0000000..225af09
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
> @@ -0,0 +1,20 @@
> +* Device tree bindings for Texas Instruments da8xx master peripheral
> + priority driver
> +
> +DA8XX SoCs feature a set of registers allowing to change the priority of all
> +peripherals classified as masters.
> +
> +Documentation:
> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
> +
> +Required properties:
> +
> +- compatible: "ti,da850-mstpri", "syscon" - for da850 based boards
Drop syscon. Doesn't look like it is needed and the example doesn't
match.
> +- reg: offset and length of the mstpri registers
> +
> +Example for da850-lcdk is shown below.
> +
> +mstpri {
> + compatible = "ti,da850-mstpri";
> + reg = <0x14110 0x0c>;
> +};
^ permalink raw reply
* [PATCH 1/2] ARM: memory: da8xx-ddrctl: new driver
From: Rob Herring @ 2016-10-31 4:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477503355-2600-2-git-send-email-bgolaszewski@baylibre.com>
On Wed, Oct 26, 2016 at 07:35:54PM +0200, Bartosz Golaszewski wrote:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> .../memory-controllers/ti-da8xx-ddrctl.txt | 20 +++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/memory/Kconfig | 8 +
> drivers/memory/Makefile | 1 +
> drivers/memory/da8xx-ddrctl.c | 175 +++++++++++++++++++++
> 4 files changed, 204 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> create mode 100644 drivers/memory/da8xx-ddrctl.c
^ permalink raw reply
* [PATCH v7, 0/8] Add MediaTek USB3 DRD Driver
From: Chunfeng Yun @ 2016-10-31 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28f6db69-88ca-4715-1e46-6d5e5efb949c@gmail.com>
On Fri, 2016-10-28 at 12:37 +0200, Matthias Brugger wrote:
> Hi Chunfeng,
>
> On 10/19/2016 04:28 AM, Chunfeng Yun wrote:
> > These patches introduce the MediaTek USB3 dual-role controller
> > driver.
> >
> > The driver can be configured as Dual-Role Device (DRD),
> > Peripheral Only and Host Only (xHCI) modes. It works well
> > with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is
> > tested on MT8173 platform which only contains USB2.0 device IP,
> > and on MT6290 platform which contains USB3.0 device IP.
[...]
> >
> > Change in v2:
> > 1. modify binding docs according to suggestions
> > 2. modify some comments and remove some dummy blank lines
> > 3. fix memory leakage
> >
> >
> > Chunfeng Yun (8):
> > dt-bindings: mt8173-xhci: support host side of dual-role mode
> > dt-bindings: mt8173-mtu3: add devicetree bindings
> > usb: xhci-mtk: make IPPC register optional
> > usb: Add MediaTek USB3 DRD driver
> > usb: mtu3: Super-Speed Peripheral mode support
> > usb: mtu3: host only mode support
> > usb: mtu3: dual-role mode support
> > arm64: dts: mediatek: add USB3 DRD driver
> >
>
> I tried the driver with my mt8173-evb, but wasn't able to get USB
> working (no usb stick detected when adding to the usb port).
>
Can you test it again by USB3.0 type-A port? If it works, then
regulators of vusb33 and vbus are got after PROBE_DEFER of
mt6397-regulator driver;
For OTG port, need cherry pick a patch:
https://patchwork.kernel.org/patch/9055261/
which is abandoned because GPIO driver owner wants to fix all pins with
the same problem.
Then device will be recognized well when connected to PC with OTG cable.
But it is a trouble for OTG host mode, due to vbus 5.5V of OTG port is
originally provided by charger driver which is not upstreamed on EVB
board, we need rework the board to control vbus by gpio.
There is a simple way, you can plug in a self-powered hub to test OTG
host mode.
> # dmesg |grep mtu
> [ 0.428420] mtu3 11271000.usb: failed to get vusb33
> [ 0.510570] mtu3 11271000.usb: failed to get vbus
> [ 0.592103] mtu3 11271000.usb: failed to get vbus
>
>
> Relevant config options:
> CONFIG_USB_MTU3=y
> CONFIG_USB_MTU3_HOST=y
> CONFIG_USB_MTU3_DEBUG=y
> CONFIG_PHY_MT65XX_USB3=y
>
>
> Looks like an error in the device tree. I can see that the mt6397
> regulater get's initialized *after* the mtu3 driver:
> [ 0.505166] mt6397-regulator mt6397-regulator: Chip ID = 0x4097
>
> Not sure if this is related.
> Any idea whats going wrong here?
>
as above.
Sorry for inconvenience
> Cheers,
> Matthias
^ permalink raw reply
* [PATCH 01/10] Documentation: dt-bindings: Document STM32 ADC DT bindings
From: Rob Herring @ 2016-10-31 3:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477412722-24061-2-git-send-email-fabrice.gasnier@st.com>
On Tue, Oct 25, 2016 at 06:25:13PM +0200, Fabrice Gasnier wrote:
> This patch adds documentation of device tree bindings for the STM32 ADC.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> .../devicetree/bindings/iio/adc/st,stm32-adc.txt | 78 ++++++++++++++++++++++
> 1 file changed, 78 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> new file mode 100644
> index 0000000..a9a8b3c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> @@ -0,0 +1,78 @@
> +STMicroelectronics STM32 ADC device driver
> +
> +STM32 ADC is a successive approximation analog-to-digital converter.
> +It has several multiplexed input channels. Conversions can be performed
> +in single, continuous, scan or discontinuous mode. Result of the ADC is
> +stored in a left-aligned or right-aligned 32-bit data register.
> +Conversions can be launched in software or using hardware triggers.
> +
> +The analog watchdog feature allows the application to detect if the input
> +voltage goes beyond the user-defined, higher or lower thresholds.
> +
> +Each STM32 ADC block can have up to 3 ADC instances.
> +
> +Each instance supports two contexts to manage conversions, each one has its
> +own configurable sequence and trigger:
> +- regular conversion can be done in sequence, running in background
> +- injected conversions have higher priority, and so have the ability to
> + interrupt regular conversion sequence (either triggered in SW or HW).
> + Regular sequence is resumed, in case it has been interrupted.
> +
> +Required properties:
> +- compatible: Should be "st,stm32f4-adc".
> +- reg: Offset and length of the ADC block register set.
> +- interrupts: Must contain the interrupt for ADC.
> +- clocks: Clock for the analog circuitry (common to all ADCs).
> +- clock-names: Must be "adc".
> +- vref-supply: Phandle to the vref input analog reference voltage.
> +- #address-cells = <1>;
> +- #size-cells = <0>;
> +
> +Optional properties:
> +- A pinctrl state named "default" for each ADC channel may be defined to set
> + inX ADC pins in mode of operation for analog input on external pin.
> +- gpios: Array of gpios that may be configured as EXTi trigger sources.
> +
> +Example:
This should be last.
> + adc: adc at 40012000 {
> + compatible = "st,stm32f4-adc";
> + reg = <0x40012000 0x400>;
> + interrupts = <18>;
> + clocks = <&rcc 0 168>;
> + clock-names = "adc";
> + vref-supply = <®_vref>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&adc3_in8_pin>;
> + gpios = <&gpioa 11 0>,
> + <&gpioa 15 0>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adc1: adc1-master at 0 {
adc at 0 sufficient?
> + #io-channel-cells = <1>;
> + reg = <0x0>;
> + clocks = <&rcc 0 168>;
> + st,adc-channels = <8>;
> + };
> + ...
> + other adc child nodes follow...
> + };
> +
> +Contents of a stm32 adc child node:
> +-----------------------------------
> +An ADC block node should contain at least one subnode, representing an
> +ADC instance available on the machine.
> +
> +Required properties:
> +- reg: Offset of ADC instance in ADC block (e.g. may be 0x0, 0x100, 0x200).
> +- st,adc-channels: List of single-ended channels muxed for this ADC.
How many? What are valid values?
> +- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers" in
> + Documentation/devicetree/bindings/iio/iio-bindings.txt
> +
> +Optional properties:
> +- clocks: Input clock private to this ADC instance.
> +- st,injected: Use injected conversion sequence on an ADC, rather than regular.
Not sure about this one. Seems like this would either be a user choice
or depend on what's connected to the ADC.
> +- dmas: Phandle to dma channel for this ADC instance, only for regular
> + conversions. See ../../dma/dma.txt for details.
> +- dma-names: Must be "rx" when dmas property is being used.
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx6ul-14x14-evk: update TX D_CAL for USBPHY
From: Peter Chen @ 2016-10-31 2:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477882709-2518-1-git-send-email-peter.chen@nxp.com>
We need to change trimming value (as a percentage) of the 17.78mA TX
reference current for better signal quality. With this change, we
can patch the eye-diagram test on this board.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
arch/arm/boot/dts/imx6ul-14x14-evk.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dts b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
index 53f0cf8..1867c69 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dts
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
@@ -233,6 +233,14 @@
status = "okay";
};
+&usbphy1 {
+ fsl,tx-d-cal = <106>;
+};
+
+&usbphy2 {
+ fsl,tx-d-cal = <106>;
+};
+
&usdhc1 {
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <&pinctrl_usdhc1>;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6sx-sdb: update TX D_CAL for USBPHY
From: Peter Chen @ 2016-10-31 2:58 UTC (permalink / raw)
To: linux-arm-kernel
We need to change trimming value (as a percentage) of the 17.78mA TX
reference current for better signal quality. With this change, we
can patch the eye-diagram test on this board.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
arch/arm/boot/dts/imx6sx-sdb.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dtsi b/arch/arm/boot/dts/imx6sx-sdb.dtsi
index 85f56a5..4933c56 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dtsi
+++ b/arch/arm/boot/dts/imx6sx-sdb.dtsi
@@ -317,6 +317,14 @@
status = "okay";
};
+&usbphy1 {
+ fsl,tx-d-cal = <106>;
+};
+
+&usbphy2 {
+ fsl,tx-d-cal = <106>;
+};
+
&usdhc2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc2>;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] dt-bindings: Update domain-idle-state binding to use correct compatibles
From: Rob Herring @ 2016-10-31 2:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <68dc67d1-b443-f7b1-6229-0ac54e403d61@arm.com>
On Wed, Oct 26, 2016 at 09:57:35AM +0100, Sudeep Holla wrote:
>
>
> On 25/10/16 21:49, Kevin Hilman wrote:
> > Lina Iyer <lina.iyer@linaro.org> writes:
> >
> > > Update domain-idle-state binding to use "domain-idle-state" compatible
> > > from Documentation/devicetree/bindings/arm/idle-states.txt.
> > >
> > > Cc: <devicetree@vger.kernel.org>
> > > Cc: Rob Herring <robh@kernel.org>
> > > Suggested-by: Sudeep Holla <sudeep.holla@arm.com>
> > > Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> > > ---
> > > Documentation/devicetree/bindings/power/power_domain.txt | 9 +++++----
> > > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > With no current users for this, I don't see the point of adding a
> > compatible now.
> >
> > IMO, this should wait and be added with the identified user we can
> > discuss it then.
> >
>
> No, IMO it needs to be used for the proposed SoC idle/genpd solution.
>
> I understand the nodes that are "arm,idle-state" compatible can be used
> for this new SoC hierarchical idle management, but it was never defined
> for that use originally. So this new feature must be advertised by the
> firmware with the presence of "domain-idle-state".
>
> Yes we might have other ways to detect that but I have already seen that
> broken on the reference platform, so we need alternate/DT way to specify
> that.
>
> Not all existing "arm,idle-state" compatible nodes will be capable of
> supporting this new SoC idle feature. It's just better and safer for a
> new feature getting added that relies on DT to have a new compatible.
Or perhaps you should describe something new rather than trying to
graft in what's there. This combination of compatible strings looks a
bit odd to me. Though, I've not really spent much time thinking about
this.
Rob
^ permalink raw reply
* [PATCH 2/6] arm: dts: ls1021a: update MSI node
From: Rob Herring @ 2016-10-31 2:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477398945-22774-2-git-send-email-Minghuan.Lian@nxp.com>
On Tue, Oct 25, 2016 at 08:35:41PM +0800, Minghuan Lian wrote:
> 1. Change compatible to "fsl,ls-scfg-msi"
That is obvious from the diff. Write your commit message to answer the
question Why?
This also breaks compatibility with old DTBs.
> 2. Move two MSI dts node into the parent node "msi-controller".
> So a PCIe device can request the MSI from the two MSI controllers.
>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
> ---
> arch/arm/boot/dts/ls1021a.dtsi | 28 ++++++++++++++++------------
> 1 file changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 368e219..7a3b510 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -119,18 +119,22 @@
>
> };
>
> - msi1: msi-controller at 1570e00 {
> - compatible = "fsl,1s1021a-msi";
> - reg = <0x0 0x1570e00 0x0 0x8>;
> + msi: msi-controller {
> + compatible = "fsl,ls-scfg-msi";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> msi-controller;
> - interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
> - };
>
> - msi2: msi-controller at 1570e08 {
> - compatible = "fsl,1s1021a-msi";
> - reg = <0x0 0x1570e08 0x0 0x8>;
> - msi-controller;
> - interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
> + msi0 at 1570e00 {
> + reg = <0x0 0x1570e00 0x0 0x8>;
> + interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + msi1 at 1570e08 {
> + reg = <0x0 0x1570e08 0x0 0x8>;
> + interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
> + };
> };
>
> ifc: ifc at 1530000 {
> @@ -643,7 +647,7 @@
> bus-range = <0x0 0xff>;
> ranges = <0x81000000 0x0 0x00000000 0x40 0x00010000 0x0 0x00010000 /* downstream I/O */
> 0x82000000 0x0 0x40000000 0x40 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
> - msi-parent = <&msi1>;
> + msi-parent = <&msi>;
> #interrupt-cells = <1>;
> interrupt-map-mask = <0 0 0 7>;
> interrupt-map = <0000 0 0 1 &gic GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
> @@ -666,7 +670,7 @@
> bus-range = <0x0 0xff>;
> ranges = <0x81000000 0x0 0x00000000 0x48 0x00010000 0x0 0x00010000 /* downstream I/O */
> 0x82000000 0x0 0x40000000 0x48 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
> - msi-parent = <&msi2>;
> + msi-parent = <&msi>;
> #interrupt-cells = <1>;
> interrupt-map-mask = <0 0 0 7>;
> interrupt-map = <0000 0 0 1 &gic GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v9 2/4] soc: mediatek: Init MT8173 scpsys driver earlier
From: James Liao @ 2016-10-31 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14a1ebb2-fda2-278b-b2f0-8f9c6ff6a83d@gmail.com>
On Mon, 2016-10-31 at 01:08 +0100, Matthias Brugger wrote:
> Hi James,
>
> On 10/20/2016 10:56 AM, James Liao wrote:
> > Some power domain comsumers may init before module_init.
> > So the power domain provider (scpsys) need to be initialized
> > earlier too.
> >
> > Take an example for our IOMMU (M4U) and SMI. SMI is a bridge
> > between IOMMU and multimedia HW. SMI is responsible to
> > enable/disable iommu and help transfer data for each multimedia
> > HW. Both of them have to wait until the power and clocks are
> > enabled.
> >
> > So scpsys driver should be initialized before SMI, and SMI should
> > be initialized before IOMMU, and then init IOMMU consumers
> > (display/vdec/venc/camera etc.).
> >
> > IOMMU is subsys_init by default. So we need to init scpsys driver
> > before subsys_init.
> >
> > Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
> > Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> > ---
>
> I didn't applied this patch for now.
> I answered you in v7 of this series [1]. I would prefer to see if we can
> fix that otherwise.
>
> Would be great if you or Yong could provide some feedback.
>
> Thanks,
> Matthias
>
> [1] https://patchwork.kernel.org/patch/9397405/
>
> > drivers/soc/mediatek/mtk-scpsys.c | 19 ++++++++++++++++++-
> > 1 file changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> > index fa9ee69..dd7a07d 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -613,4 +613,21 @@ static int scpsys_probe(struct platform_device *pdev)
> > .of_match_table = of_match_ptr(of_scpsys_match_tbl),
> > },
> > };
> > -builtin_platform_driver(scpsys_drv);
> > +
> > +static int __init scpsys_drv_init(void)
> > +{
> > + return platform_driver_register(&scpsys_drv);
> > +}
> > +
> > +/*
> > + * There are some Mediatek drivers which depend on the power domain driver need
> > + * to probe in earlier initcall levels. So scpsys driver also need to probe
> > + * earlier.
> > + *
> > + * IOMMU(M4U) and SMI drivers for example. SMI is a bridge between IOMMU and
> > + * multimedia HW. IOMMU depends on SMI, and SMI is a power domain consumer,
> > + * so the proper probe sequence should be scpsys -> SMI -> IOMMU driver.
> > + * IOMMU drivers are initialized during subsys_init by default, so we need to
> > + * move SMI and scpsys drivers to subsys_init or earlier init levels.
> > + */
> > +subsys_initcall(scpsys_drv_init);
> >
Hi Matthias,
I got it, thanks.
Hi Yong,
Is this patch still needed on latest kernel for IOMMU driver? Or we have
other solutions for IOMMU driver init?
Best regards,
James
^ permalink raw reply
* [PATCH RESEND] tty: amba-pl011: Add earlycon support for SBSA UART
From: Kefeng Wang @ 2016-10-31 2:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161030133139.GA1595@kroah.com>
Declare an OF early console for SBSA UART so that the early console device
can be specified via the "stdout-path" property in device-tree.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
drivers/tty/serial/amba-pl011.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index e2c33b9..a4a0b3d 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2357,6 +2357,7 @@ static int __init pl011_early_console_setup(struct earlycon_device *device,
return 0;
}
OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
+OF_EARLYCON_DECLARE(pl011, "arm,sbsa-uart", pl011_early_console_setup);
#else
#define AMBA_CONSOLE NULL
--
1.7.12.4
^ permalink raw reply related
* [PATCH v1 1/3] dt-bindings: Document Broadcom OTP controller driver
From: Rob Herring @ 2016-10-31 1:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477336324-10543-2-git-send-email-jonathan.richardson@broadcom.com>
On Mon, Oct 24, 2016 at 12:12:02PM -0700, Jonathan Richardson wrote:
> From: Jonathan Richardson <jonathar@broadcom.com>
>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Oza Pawandeep <oza@broadcom.com>
> Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> ---
> Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
>
> diff --git a/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
> new file mode 100644
> index 0000000..6462e12
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
> @@ -0,0 +1,17 @@
> +Broadcom OTP memory controller
> +
> +Required Properties:
> +- compatible: "brcm,ocotp" for the first generation Broadcom OTPC which is used
> + in Cygnus and supports 32 bit read/write. Use "brcm,ocotp-v2" for the second
> + generation Broadcom OTPC which is used in SoC's such as Stingray and supports
> + 64-bit read/write.
These should be SoC specific. While I'd guess this block is simple
enough, having the SoC can define what all the bits are. Yes, there is a
binding to define those, but you may not use that.
> +- reg: Base address of the OTP controller.
> +- brcm,ocotp-size: Amount of memory available, in 32 bit words
> +
> +Example:
> +
> +otp: otp at 0301c800 {
> + compatible = "brcm,ocotp";
> + reg = <0x0301c800 0x2c>;
> + brcm,ocotp-size = <2048>;
> +};
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] arm64: dts: mt8173: Fix auxadc node
From: Matthias Brugger @ 2016-10-31 0:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026141500.27105-1-matthias.bgg@gmail.com>
On 10/26/2016 04:15 PM, Matthias Brugger wrote:
> The devicetree node for mt8173-auxadc lacks the clock and
> io-channel-cells property. This leads to a non-working driver.
>
> mt6577-auxadc 11001000.auxadc: failed to get auxadc clock
> mt6577-auxadc: probe of 11001000.auxadc failed with error -2
>
> Fix these fields to get the device up and running.
>
> Fixes: 748c7d4de46a ("ARM64: dts: mt8173: Add thermal/auxadc device
> nodes")
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
Applied.
^ permalink raw reply
* [PATCH v9 2/4] soc: mediatek: Init MT8173 scpsys driver earlier
From: Matthias Brugger @ 2016-10-31 0:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476953798-23263-3-git-send-email-jamesjj.liao@mediatek.com>
Hi James,
On 10/20/2016 10:56 AM, James Liao wrote:
> Some power domain comsumers may init before module_init.
> So the power domain provider (scpsys) need to be initialized
> earlier too.
>
> Take an example for our IOMMU (M4U) and SMI. SMI is a bridge
> between IOMMU and multimedia HW. SMI is responsible to
> enable/disable iommu and help transfer data for each multimedia
> HW. Both of them have to wait until the power and clocks are
> enabled.
>
> So scpsys driver should be initialized before SMI, and SMI should
> be initialized before IOMMU, and then init IOMMU consumers
> (display/vdec/venc/camera etc.).
>
> IOMMU is subsys_init by default. So we need to init scpsys driver
> before subsys_init.
>
> Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> ---
I didn't applied this patch for now.
I answered you in v7 of this series [1]. I would prefer to see if we can
fix that otherwise.
Would be great if you or Yong could provide some feedback.
Thanks,
Matthias
[1] https://patchwork.kernel.org/patch/9397405/
> drivers/soc/mediatek/mtk-scpsys.c | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> index fa9ee69..dd7a07d 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -613,4 +613,21 @@ static int scpsys_probe(struct platform_device *pdev)
> .of_match_table = of_match_ptr(of_scpsys_match_tbl),
> },
> };
> -builtin_platform_driver(scpsys_drv);
> +
> +static int __init scpsys_drv_init(void)
> +{
> + return platform_driver_register(&scpsys_drv);
> +}
> +
> +/*
> + * There are some Mediatek drivers which depend on the power domain driver need
> + * to probe in earlier initcall levels. So scpsys driver also need to probe
> + * earlier.
> + *
> + * IOMMU(M4U) and SMI drivers for example. SMI is a bridge between IOMMU and
> + * multimedia HW. IOMMU depends on SMI, and SMI is a power domain consumer,
> + * so the proper probe sequence should be scpsys -> SMI -> IOMMU driver.
> + * IOMMU drivers are initialized during subsys_init by default, so we need to
> + * move SMI and scpsys drivers to subsys_init or earlier init levels.
> + */
> +subsys_initcall(scpsys_drv_init);
>
^ permalink raw reply
* [PATCH v9 3/4] soc: mediatek: Add MT2701 power dt-bindings
From: Matthias Brugger @ 2016-10-31 0:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19220b7f-84c3-eefe-333c-bd1ddfa988a3@gmail.com>
On 10/31/2016 12:57 AM, Matthias Brugger wrote:
>
>
> On 10/20/2016 10:56 AM, James Liao wrote:
>> From: Shunli Wang <shunli.wang@mediatek.com>
>>
>> Add power dt-bindings for MT2701.
>>
>> Signed-off-by: Shunli Wang <shunli.wang@mediatek.com>
>> Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
>
> Applied to v4.9-next/soc
Of course this has to be applied to v4.9-next/dts, fixed now.
Thanks,
Matthias
^ permalink raw reply
* [PATCH v9 4/4] soc: mediatek: Add MT2701 scpsys driver
From: Matthias Brugger @ 2016-10-30 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476953798-23263-5-git-send-email-jamesjj.liao@mediatek.com>
On 10/20/2016 10:56 AM, James Liao wrote:
> From: Shunli Wang <shunli.wang@mediatek.com>
>
> Add scpsys driver for MT2701.
>
> mtk-scpsys now supports MT8173 (arm64) and MT2701 (arm). So it should
> be enabled on both arm64 and arm platforms.
>
> Signed-off-by: Shunli Wang <shunli.wang@mediatek.com>
> Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> ---
Applied to v4.9-next/soc
^ 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