* [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
* [PATCH v4 01/23] reset: Add renesas,rst DT bindings
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477055857-17936-2-git-send-email-geert+renesas@glider.be>
On Fri, Oct 21, 2016 at 03:17:15PM +0200, Geert Uytterhoeven wrote:
> Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
> RESET/WDT and R-Car Gen2/Gen3 and RZ/G RST).
>
> As the features provided by the hardware module differ a lot across the
> various SoC families and members, only SoC-specific compatible values
> are defined.
>
> For now we use the RST only for providing access to the state of the
> mode pins, which is needed by the clock driver.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v4:
> - Add Acked-by,
> - Fix comma and period in list,
> - Add RZ/G1M and RZ/G1E,
>
> v3:
> - Clarify current usage,
> - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
> - Drop "syscon" compatible value,
> - Add R-Car M3-W,
> - Add R-Car Gen1,
>
> v2:
> - Add Acked-by.
> ---
> .../devicetree/bindings/reset/renesas,rst.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/3] Documentation: dt: Add TI SCI clock driver
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477053961-27128-2-git-send-email-t-kristo@ti.com>
On Fri, Oct 21, 2016 at 03:45:59PM +0300, Tero Kristo wrote:
> Add a clock implementation, TI SCI clock, that will hook to the common
> clock framework, and allow each clock to be controlled via TI SCI
> protocol.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> .../devicetree/bindings/clock/ti,sci-clk.txt | 37 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
> new file mode 100644
> index 0000000..bfc3ca4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
> @@ -0,0 +1,37 @@
> +Texas Instruments TI-SCI Clocks
> +===============================
> +
> +All clocks on Texas Instruments' SoCs that contain a System Controller,
> +are only controlled by this entity. Communication between a host processor
> +running an OS and the System Controller happens through a protocol known
> +as TI-SCI[1]. This clock implementation plugs into the common clock
> +framework and makes use of the TI-SCI protocol on clock API requests.
> +
> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +Required properties:
> +-------------------
> +- compatible: Must be "ti,k2g-sci-clk"
> +- #clock-cells: Shall be 2.
> + In clock consumers, this cell represents the device ID and clock ID
> + exposed by the PM firmware. The assignments can be found in the header
> + files <dt-bindings/genpd/<soc>.h> (which covers the device IDs) and
> + <dt-bindings/clock/<soc>.h> (which covers the clock IDs), where <soc>
> + is the SoC involved, for example 'k2g'.
> +
> +Examples:
> +--------
> +
> +pmmc: pmmc {
> + compatible = "ti,k2g-sci";
> +
> + k2g_clks: k2g_clks {
Use "clocks" for node name instead.
> + compatible = "ti,k2g-sci-clk";
I'm starting to think all these child nodes for SCI are pointless. Is
there any reason why the parent node can't be the clock provider (along
with all the other providers it acks as)?
> + #clock-cells = <2>;
> + };
> +};
> +
> +uart0: serial at 2530c00 {
> + compatible = "ns16550a";
> + clocks = <&k2g_clks K2G_DEV_UART0 0>;
> +};
^ permalink raw reply
* [PATCH v2 4/9] regulator: lp873x: Add support for populating input supply
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-5-lokeshvutla@ti.com>
On Fri, Oct 21, 2016 at 04:08:36PM +0530, Lokesh Vutla wrote:
> In order to have a proper topology of regulators for a platform, each
> registering regulator needs to populate supply_name field for identifying
> its supply's name. Add supply_name field for lp873x regulators.
>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Keerthy <j-keerthy@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
> drivers/regulator/lp873x-regulator.c | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
> index 52766c2..998837a 100644
> --- a/Documentation/devicetree/bindings/mfd/lp873x.txt
> +++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
> @@ -7,6 +7,9 @@ Required properties:
> - #gpio-cells: Should be two. The first cell is the pin number and
> the second cell is used to specify flags.
> See ../gpio/gpio.txt for more information.
> + - xxx-in-supply: Phandle to parent supply node of each regulator
> + populated under regulators node. xxx should match
> + the supply_name populated in driver.
The driver is irrelevant. This should reference a list in this document.
> - regulators: List of child nodes that specify the regulator
> initialization data.
> Example:
> @@ -17,6 +20,11 @@ pmic: lp8733 at 60 {
> gpio-controller;
> #gpio-cells = <2>;
>
> + buck0-in-supply = <&vsys_3v3>;
> + buck1-in-supply = <&vsys_3v3>;
> + ldo0-in-supply = <&vsys_3v3>;
> + ldo1-in-supply = <&vsys_3v3>;
> +
> regulators {
> lp8733_buck0: buck0 {
> regulator-name = "lp8733-buck0";
^ permalink raw reply
* [PATCH] net: stmmac: Add OXNAS Glue Driver
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021084445.24989-1-narmstrong@baylibre.com>
On Fri, Oct 21, 2016 at 10:44:45AM +0200, Neil Armstrong wrote:
> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/net/oxnas-dwmac.txt | 44 +++++
It's preferred that bindings are a separate patch.
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 219 +++++++++++++++++++++
> 4 files changed, 275 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
>
> Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
> - Drop init/exit callbacks
> - Implement proper remove and PM callback
> - Call init from probe
> - Disable/Unprepare clock if stmmac probe fails
>
> diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
> new file mode 100644
> index 0000000..5d2696c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
> @@ -0,0 +1,44 @@
> +* Oxford Semiconductor OXNAS DWMAC Ethernet controller
> +
> +The device inherits all the properties of the dwmac/stmmac devices
> +described in the file stmmac.txt in the current directory with the
> +following changes.
> +
> +Required properties on all platforms:
> +
> +- compatible: Depending on the platform this should be one of:
> + - "oxsemi,ox820-dwmac"
> + Additionally "snps,dwmac" and any applicable more
> + detailed version number described in net/stmmac.txt
> + should be used.
You should be explicit what version applies to ox820. "snps,dwmac"
should probably be deprecated IMO. There are so many variations of DW
h/w.
> +
> +- reg: The first register range should be the one of the DWMAC
> + controller.
This is worded like there's a 2nd range?
> +
> +- clocks: Should contain phandles to the following clocks
> +- clock-names: Should contain the following:
> + - "stmmaceth" - see stmmac.txt
> + - "gmac" - peripheral gate clock
> +
> +- oxsemi,sys-ctrl: a phandle to the system controller syscon node
> +
> +Example :
> +
> +etha: ethernet at 40400000 {
> + compatible = "oxsemi,ox820-dwmac", "snps,dwmac";
> + reg = <0x40400000 0x2000>;
> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "macirq", "eth_wake_irq";
> + mac-address = [000000000000]; /* Filled in by U-Boot */
> + phy-mode = "rgmii";
> +
> + clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
> + clock-names = "gmac", "stmmaceth";
> + resets = <&reset RESET_MAC>;
> +
> + /* Regmap for sys registers */
> + oxsemi,sys-ctrl = <&sys>;
> +
> + status = "disabled";
> +};
^ permalink raw reply
* [PATCH v5 3/7] drm: sunxi: add DE2 HDMI support
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <36bd5454897c8ab77749e0294e4a4ecc2450dd12.1477142934.git.moinejf@free.fr>
On Fri, Oct 21, 2016 at 10:08:06AM +0200, Jean-Francois Moine wrote:
> This patch adds a HDMI driver to the DE2 based Allwinner's SoCs
> as A83T and H3.
> Audio and video are supported.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> .../devicetree/bindings/display/sunxi/hdmi.txt | 52 ++
> drivers/gpu/drm/sunxi/Kconfig | 8 +
> drivers/gpu/drm/sunxi/Makefile | 2 +
> drivers/gpu/drm/sunxi/de2_hdmi.c | 396 +++++++++
> drivers/gpu/drm/sunxi/de2_hdmi.h | 40 +
> drivers/gpu/drm/sunxi/de2_hdmi_io.c | 927 +++++++++++++++++++++
> drivers/gpu/drm/sunxi/de2_hdmi_io.h | 25 +
> 7 files changed, 1450 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.c
> create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.h
> create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_io.c
> create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_io.h
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/hdmi.txt b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> new file mode 100644
> index 0000000..0558c07
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> @@ -0,0 +1,52 @@
> +Allwinner HDMI Transmitter
> +==========================
> +
> +The Allwinner HDMI transmitters are included in the SoCs.
> +They support audio and video.
> +
> +Required properties:
> + - #address-cells : should be <1>
> + - #size-cells : should be <0>
> + - compatible : should be
> + "allwinner,sun8i-a83t-hdmi" or
> + "allwinner,sun8i-h3-hdmi"
> + - clocks : phandles to the HDMI clocks as described in
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + - clock-names : must be
> + "gate" : bus gate
> + "clock" : streaming clock
> + "ddc-clock" : DDC clock
> + - resets : One or two phandles to the HDMI resets
> + - reset-names : must be
> + "hdmi0" and "hdmi1"
> +
> +Required nodes:
> + - port: Audio and video input port nodes with endpoint definitions
> + as defined in Documentation/devicetree/bindings/graph.txt.
Please define which port number is audio and which is video.
Rob
^ permalink raw reply
* [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8afc5e020c5767face34fe3a9ab300ce9e67ba00.1477142934.git.moinejf@free.fr>
On Fri, Oct 21, 2016 at 09:26:18AM +0200, Jean-Francois Moine wrote:
> Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
> engine, DE2.
> This patch adds a DRM video driver for this device.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> .../bindings/display/sunxi/sunxi-de2.txt | 83 +++
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/sunxi/Kconfig | 21 +
> drivers/gpu/drm/sunxi/Makefile | 7 +
> drivers/gpu/drm/sunxi/de2_crtc.c | 475 +++++++++++++++++
> drivers/gpu/drm/sunxi/de2_crtc.h | 63 +++
> drivers/gpu/drm/sunxi/de2_de.c | 591 +++++++++++++++++++++
> drivers/gpu/drm/sunxi/de2_drm.h | 47 ++
> drivers/gpu/drm/sunxi/de2_drv.c | 378 +++++++++++++
> drivers/gpu/drm/sunxi/de2_plane.c | 119 +++++
> 11 files changed, 1787 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> create mode 100644 drivers/gpu/drm/sunxi/Kconfig
> create mode 100644 drivers/gpu/drm/sunxi/Makefile
> create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
> create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
> create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
> create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
> create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
> create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> new file mode 100644
> index 0000000..f9cd67a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> + hdmi: hdmi at 01ee0000 {
> + ...
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port {
> + type = "video";
This is proposed, but not an accepted property. Please drop.
> + hdmi_ep: endpoint {
> + remote-endpoint = <&lcd0_ep>;
> + };
> + };
> + };
^ 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