* [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
* [PATCH v9 3/4] soc: mediatek: Add MT2701 power dt-bindings
From: Matthias Brugger @ 2016-10-30 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476953798-23263-4-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 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
^ permalink raw reply
* [PATCH v9 1/4] soc: mediatek: Refine scpsys to support multiple platform
From: Matthias Brugger @ 2016-10-30 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477647408.24014.6.camel@mtksdaap41>
On 10/28/2016 11:36 AM, James Liao wrote:
> Hi Matthias,
>
> Sorry for late reply due to our email service.
>
> On Tue, 2016-10-25 at 16:04 +0200, Matthias Brugger wrote:
>> Hi James,
>>
>> On 10/20/2016 10:56 AM, James Liao wrote:
>>> -static int scpsys_probe(struct platform_device *pdev)
>>> +static void init_clks(struct platform_device *pdev, struct clk *clk[CLK_MAX])
>>
>> I prefer struct clk **clk.
>
> Okay.
>
>>> +{
>>> + int i;
>>> +
>>> + for (i = CLK_NONE + 1; i < CLK_MAX; i++)
>>> + clk[i] = devm_clk_get(&pdev->dev, clk_names[i]);
>>> +}
>>> +
>>> +static struct scp *init_scp(struct platform_device *pdev,
>>> + const struct scp_domain_data *scp_domain_data, int num)
>>> {
>>> struct genpd_onecell_data *pd_data;
>>> struct resource *res;
>>> - int i, j, ret;
>>> + int i, j;
>>> struct scp *scp;
>>> - struct clk *clk[MT8173_CLK_MAX];
>>> + struct clk *clk[CLK_MAX];
>>
>> should be *[CLK_MAX - 1] but I would prefer to define in the enum:
>> CLK_MAX = CLK_VENC_LT,
>
> After init_clks() the clk[] will have valid contents between
> clk[1]..clk[CLK_MAX-1], so it's necessary to declare clk[] with CLK_MAX
> elements.
>
>> If you are ok with it, I can fix both of my comments when applying.
>
> Yes. struct clk **clk can be applied directly. But I think clk[CLK_MAX]
> should be kept in current implementation.
>
Ok, we won't never use clk[0] but it's ok for now.
Applied to v4.9-next/soc
>
> Best regards,
>
> James
>
>
^ permalink raw reply
* [PATCH v7 REPOST 8/9] arm: add sysfs cpu_capacity attribute
From: Russell King - ARM Linux @ 2016-10-30 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017154650.18779-9-juri.lelli@arm.com>
On Mon, Oct 17, 2016 at 04:46:49PM +0100, Juri Lelli wrote:
> +#ifdef CONFIG_PROC_SYSCTL
> +#include <asm/cpu.h>
> +#include <linux/string.h>
Include files at the top of the file please. No need to ifdef them.
They're sorted alphabetically, so new additions should be alphabetical.
(That's a general rule - if something is already alphabetical, do not
make it non-alphabetical.)
> +static ssize_t show_cpu_capacity(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct cpu *cpu = container_of(dev, struct cpu, dev);
> + ssize_t rc;
> + int cpunum = cpu->dev.id;
> + unsigned long capacity = arch_scale_cpu_capacity(NULL, cpunum);
> +
> + rc = sprintf(buf, "%lu\n", capacity);
> +
> + return rc;
Way too many lines for such a simple function. This can be simplified
to just:
struct cpu *cpu = container_of(dev, struct cpu, dev);
return sprintf(buf, "%lu\n", arch_scale_cpu_capacity(NULL, cpu->dev.id);
If you don't like the last line ending on column 79, then feel free to
break it across two lines after the format string.
> +}
> +
> +static ssize_t store_cpu_capacity(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t count)
> +{
> + struct cpu *cpu = container_of(dev, struct cpu, dev);
> + int this_cpu = cpu->dev.id, i;
> + unsigned long new_capacity;
> + ssize_t ret;
> +
> + if (count) {
> + char *p = (char *) buf;
> +
> + ret = kstrtoul(p, 0, &new_capacity);
Unnecessary cast - kstrtoul takes a const char pointer, and in any case
it's really bad form to cast away the "const-ness" of any pointer. So,
just:
if (count) {
ret = kstrtoul(buf, 0, &new_capacity);
should work just fine.
> + if (ret)
> + return ret;
> + if (new_capacity > SCHED_CAPACITY_SCALE)
> + return -EINVAL;
> +
> + mutex_lock(&cpu_scale_mutex);
> + for_each_cpu(i, &cpu_topology[this_cpu].core_sibling)
> + set_capacity_scale(i, new_capacity);
> + mutex_unlock(&cpu_scale_mutex);
> + }
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR(cpu_capacity,
> + 0644,
> + show_cpu_capacity,
> + store_cpu_capacity);
There's a move to use the named DEVICE_ATTR_RW() for this kind of thing,
it'll want the functions named xxx_show() and xxx_store(). I see
there's some recent patches to do this conversion across the kernel, so
this should probably be done before submission.
> +
> +static int register_cpu_capacity_sysctl(void)
> +{
> + int i;
> + struct device *cpu;
> +
> + for_each_possible_cpu(i) {
> + cpu = get_cpu_device(i);
> + if (!cpu) {
> + pr_err("%s: too early to get CPU%d device!\n",
> + __func__, i);
> + continue;
> + }
> + device_create_file(cpu, &dev_attr_cpu_capacity);
> + }
> +
> + return 0;
> +}
> +late_initcall(register_cpu_capacity_sysctl);
Hmm, this is really weird. topology_init() in arch/arm/kernel/setup.c
is where these devices get created, and they're created at
subsys_initcall() time. By that point, the list of possible CPUs has
to be static, it's not going to change. I don't see why this has to be
done at late_initcall() - and since topology.c will be linked after
setup.c, I don't see why it shouldn't be at subsys_initcall() level to
follow on after topology_init().
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH/RFT v2 09/17] regulator: fixed: Add over current event
From: Rob Herring @ 2016-10-30 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024164634.4330-10-ahaslam@baylibre.com>
On Mon, Oct 24, 2016 at 06:46:26PM +0200, ahaslam at baylibre.com wrote:
> From: Axel Haslam <ahaslam@baylibre.com>
>
> Some regulator supplies have an over-current pin that is
> activated when the hw detects an over current condition.
> When this happens, the hardware enters a current limited
> mode.
>
> Extend the fixed regulator driver with the ability
> to handle irq's from the over-current pin and report
> an over current event to the consumers via a regulator
> notifier. Also, add device tree bindings to allow to
> pass a gpio for over current monitoring.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
> .../bindings/regulator/fixed-regulator.txt | 4 ++
> drivers/regulator/fixed.c | 64 ++++++++++++++++++++++
> include/linux/regulator/consumer.h | 5 ++
> include/linux/regulator/fixed.h | 3 +
> 4 files changed, 76 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
> index 4fae41d..d20bf67 100644
> --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
> @@ -11,6 +11,8 @@ If this property is missing, the default assumed is Active low.
> - gpio-open-drain: GPIO is open drain type.
> If this property is missing then default assumption is false.
> -vin-supply: Input supply name.
> +- oc-gpio: Input gpio that signals an over current condition
"-gpios" is the preferred form. So "oc-gpios".
> +- oc-active-high: The polarity of the over current pin is high
This should be specified in the gpio flags cell.
Rob
^ permalink raw reply
* [PATCH 5/5] irqchip: st: Remove obsolete platforms from dt binding doc
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477065443-10668-6-git-send-email-patrice.chotard@st.com>
On Fri, Oct 21, 2016 at 05:57:23PM +0200, patrice.chotard at st.com wrote:
> From: Patrice Chotard <patrice.chotard@st.com>
>
> STiH415/6 SoC support is being removed from the kernel.
> This patch updates the sti irchip and removes
> references to these obsolete platforms.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> Cc: <tglx@linutronix.de>
> Cc: <jason@lakedaemon.net>
> Cc: <marc.zyngier@arm.com>
> ---
> .../devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477060838-14164-2-git-send-email-narmstrong@baylibre.com>
On Fri, Oct 21, 2016 at 04:40:26PM +0200, Neil Armstrong wrote:
> Add support for the Amlogic Meson GXL SoC, this is a partially complete
> definition only based on the Amlogic Vendor tree.
>
> This definition differs a lot from the GXBB and needs a separate entry.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/pinctrl/meson,pinctrl.txt | 2 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/pinctrl/meson/Makefile | 3 +-
> drivers/pinctrl/meson/pinctrl-meson-gxl.c | 589 +++++++++++++++++++++
> drivers/pinctrl/meson/pinctrl-meson.c | 8 +
> drivers/pinctrl/meson/pinctrl-meson.h | 2 +
> include/dt-bindings/gpio/meson-gxl-gpio.h | 131 +++++
> 6 files changed, 734 insertions(+), 1 deletion(-)
> create mode 100644 drivers/pinctrl/meson/pinctrl-meson-gxl.c
> create mode 100644 include/dt-bindings/gpio/meson-gxl-gpio.h
^ permalink raw reply
* [PATCH] dt-bindings: video: exynos7-decon: Remove obsolete samsung,power-domain property
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477058754-13866-1-git-send-email-krzk@kernel.org>
On Fri, Oct 21, 2016 at 05:05:54PM +0300, Krzysztof Kozlowski wrote:
> The samsung,power-domain property is obsolete since commit 0da658704136
> ("ARM: dts: convert to generic power domain bindings for exynos DT").
> Replace it with generic one.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
You didn't send this To me, so I assume someone else is applying it.
Acked-by: Rob Herring <robh@kernel.org>
^ 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