* [PATCH v2 1/4] drm: Add support for Amlogic Meson Graphic Controller
From: Laurent Pinchart @ 2016-11-30 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-2-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Thank you for the patch.
I'm afraid I don't have time for a complete review, but could you please get
rid of the of_machine_is_compatible() calls and match on the VPU compatible
string instead ?
On Wednesday 30 Nov 2016 16:43:42 Neil Armstrong wrote:
> The Amlogic Meson Display controller is composed of several components :
>
> DMC|---------------VPU (Video Processing
> Unit)----------------|------HHI------| |
> vd1 _______ _____________ _________________ | |
> D |-------| |----| | | | | HDMI
> PLL | D | vd2 | VIU | | Video Post | | Video Encoders
> |<---|-----VCLK | R |-------| |----| Processing
> | | | | | |
> osd2 | | | |---| Enci ----------|----|-----VDAC------|
> R |-------| CSC |----| Scalers | | Encp
> ----------|----|----HDMI-TX----| A | osd1 | | | Blenders | |
> Encl ----------|----|---------------|
> M |-------|______|----|____________| |________________| |
> |
> ___|__________________________________________________________|____________
> ___|
>
> VIU: Video Input Unit
> ---------------------
>
> The Video Input Unit is in charge of the pixel scanout from the DDR memory.
> It fetches the frames addresses, stride and parameters from the "Canvas"
> memory. This part is also in charge of the CSC (Colorspace Conversion).
> It can handle 2 OSD Planes and 2 Video Planes.
>
> VPP: Video Post Processing
> --------------------------
>
> The Video Post Processing is in charge of the scaling and blending of the
> various planes into a single pixel stream.
> There is a special "pre-blending" used by the video planes with a dedicated
> scaler and a "post-blending" to merge with the OSD Planes.
> The OSD planes also have a dedicated scaler for one of the OSD.
>
> VENC: Video Encoders
> --------------------
>
> The VENC is composed of the multiple pixel encoders :
> - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
> - ENCP : Progressive Video Encoder for HDMI
> - ENCL : LCD LVDS Encoder
> The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
> tree and provides the scanout clock to the VPP and VIU.
> The ENCI is connected to a single VDAC for Composite Output.
> The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
>
> This driver is a DRM/KMS driver using the following DRM components :
> - GEM-CMA
> - PRIME-CMA
> - Atomic Modesetting
> - FBDev-CMA
>
> For the following SoCs :
> - GXBB Family (S905)
> - GXL Family (S905X, S905D)
> - GXM Family (S912)
>
> The current driver only supports the CVBS PAL/NTSC output modes, but the
> CRTC/Planes management should support bigger modes.
> But Advanced Colorspace Conversion, Scaling and HDMI Modes will be added in
> a second time.
>
> The Device Tree bindings makes use of the endpoints video interface
> definitions to connect to the optional CVBS and in the future the HDMI
> Connector nodes.
>
> HDMI Support is planned for a next release.
>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/meson/Kconfig | 9 +
> drivers/gpu/drm/meson/Makefile | 4 +
> drivers/gpu/drm/meson/meson_canvas.c | 68 ++
> drivers/gpu/drm/meson/meson_canvas.h | 42 +
> drivers/gpu/drm/meson/meson_crtc.c | 208 +++++
> drivers/gpu/drm/meson/meson_crtc.h | 32 +
> drivers/gpu/drm/meson/meson_drv.c | 343 ++++++++
> drivers/gpu/drm/meson/meson_drv.h | 60 ++
> drivers/gpu/drm/meson/meson_plane.c | 230 +++++
> drivers/gpu/drm/meson/meson_plane.h | 30 +
> drivers/gpu/drm/meson/meson_registers.h | 1395 ++++++++++++++++++++++++++++
> drivers/gpu/drm/meson/meson_vclk.c | 167 ++++
> drivers/gpu/drm/meson/meson_vclk.h | 34 +
> drivers/gpu/drm/meson/meson_venc.c | 254 ++++++
> drivers/gpu/drm/meson/meson_venc.h | 72 ++
> drivers/gpu/drm/meson/meson_venc_cvbs.c | 293 +++++++
> drivers/gpu/drm/meson/meson_venc_cvbs.h | 41 +
> drivers/gpu/drm/meson/meson_viu.c | 331 ++++++++
> drivers/gpu/drm/meson/meson_viu.h | 64 ++
> drivers/gpu/drm/meson/meson_vpp.c | 162 ++++
> drivers/gpu/drm/meson/meson_vpp.h | 35 +
> 23 files changed, 3877 insertions(+)
> create mode 100644 drivers/gpu/drm/meson/Kconfig
> create mode 100644 drivers/gpu/drm/meson/Makefile
> create mode 100644 drivers/gpu/drm/meson/meson_canvas.c
> create mode 100644 drivers/gpu/drm/meson/meson_canvas.h
> create mode 100644 drivers/gpu/drm/meson/meson_crtc.c
> create mode 100644 drivers/gpu/drm/meson/meson_crtc.h
> create mode 100644 drivers/gpu/drm/meson/meson_drv.c
> create mode 100644 drivers/gpu/drm/meson/meson_drv.h
> create mode 100644 drivers/gpu/drm/meson/meson_plane.c
> create mode 100644 drivers/gpu/drm/meson/meson_plane.h
> create mode 100644 drivers/gpu/drm/meson/meson_registers.h
> create mode 100644 drivers/gpu/drm/meson/meson_vclk.c
> create mode 100644 drivers/gpu/drm/meson/meson_vclk.h
> create mode 100644 drivers/gpu/drm/meson/meson_venc.c
> create mode 100644 drivers/gpu/drm/meson/meson_venc.h
> create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.c
> create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.h
> create mode 100644 drivers/gpu/drm/meson/meson_viu.c
> create mode 100644 drivers/gpu/drm/meson/meson_viu.h
> create mode 100644 drivers/gpu/drm/meson/meson_vpp.c
> create mode 100644 drivers/gpu/drm/meson/meson_vpp.h
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13104644.f9boR54smD@avalon>
Hi Laurent,
On 11/30/2016 04:56 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>> 1 file changed, 101 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>
>> diff --git a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new file
>> mode 100644
>> index 0000000..e52869a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>> @@ -0,0 +1,101 @@
[...]
>> +
>> +Device Tree Bindings:
>> +---------------------
>> +
>> +VPU: Video Processing Unit
>> +--------------------------
>> +
>> +Required properties:
>> +- compatible: value should be different for each SoC family as :
>> + - GXBB (S905) : "amlogic,meson-gxbb-vpu"
>> + - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
>> + - GXM (S912) : "amlogic,meson-gxm-vpu"
>> + followed by the common "amlogic,meson-gx-vpu"
>> +- reg: base address and size of he following memory-mapped regions :
>> + - vpu
>> + - hhi
>> + - dmc
>> +- reg-names: should contain the names of the previous memory regions
>> +- interrupts: should contain the VENC Vsync interrupt number
>> +
>> +- ports: A ports node with endpoint definitions as defined in
>> + Documentation/devicetree/bindings/media/video-interfaces.txt.
>> + The first port should be connected to a CVBS connector endpoint if
>> available.
>
> This is a bit vague, I propose clarifying it with a description similar to the
> one in the renesas,du.txt bindings.
>
> Required nodes:
>
> The connections to the VPU output video ports are modeled using the OF graph
> bindings specified in Documentation/devicetree/bindings/graph.txt.
>
> The following table lists for each supported model the port number
> corresponding to each DU output.
>
> Port 0 Port1 Port2 Port3
> -----------------------------------------------------------------------------
> R8A7779 (H1) DPAD 0 DPAD 1 - -
> R8A7790 (H2) DPAD LVDS 0 LVDS 1 -
> R8A7791 (M2-W) DPAD LVDS 0 - -
> R8A7792 (V2H) DPAD 0 DPAD 1 - -
> R8A7793 (M2-N) DPAD LVDS 0 - -
> R8A7794 (E2) DPAD 0 DPAD 1 - -
> R8A7795 (H3) DPAD HDMI 0 HDMI 1 LVDS
> R8A7796 (M3-W) DPAD HDMI LVDS -
>
> (You should obviously replace the table with Amlogic data)
>
> It doesn't matter if the current driver implementation only supports CVBS, the
> DT bindings can already document the other ports.
>
Ok, it's a pretty table ! Will integrate this.
>> +
>> +Example:
>> +
>> +tv: connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>
> I'd remove the label here, as it doesn't bring any additional information.
> Unless the board you're using has a label for the connector, in case that
> label should be used.
Indeed, I already removed it in the dts.
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
[...]
Thanks for the review,
Neil
^ permalink raw reply
* [PATCH v2 1/4] drm: Add support for Amlogic Meson Graphic Controller
From: Neil Armstrong @ 2016-11-30 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3713265.h5djxipShb@avalon>
On 11/30/2016 05:03 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> I'm afraid I don't have time for a complete review, but could you please get
> rid of the of_machine_is_compatible() calls and match on the VPU compatible
> string instead ?
Oops, I knew I forgot to change this one...
I will get rid of these for the v3.
Thanks,
Neil
^ permalink raw reply
* [PATCH v2 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Neil Armstrong @ 2016-11-30 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10006210.eA8q2ZWXP0@avalon>
On 11/30/2016 05:02 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Wednesday 30 Nov 2016 16:43:43 Neil Armstrong wrote:
>> Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
>> boards.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 ++++++++++++++++
>> .../arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
>> arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++++
>> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 ++++
>> 8 files changed, 91 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi index fc033c0..a27f881 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> @@ -356,5 +356,24 @@
>> status = "disabled";
>> };
>> };
>> +
>> + vpu: vpu at d0100000 {
>> + compatible = "amlogic,meson-gx-vpu";
>> + reg = <0x0 0xd0100000 0x0 0x100000>,
>> + <0x0 0xc883c000 0x0 0x1000>,
>> + <0x0 0xc8838000 0x0 0x1000>;
>> + reg-names = "vpu", "hhi", "dmc";
>> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + /* CVBS VDAC output port */
>> + port at 0 {
>> + reg = <0>;
>> +
>> + cvbs_vdac_out: endpoint {
>> + };
>
> Endpoints require a remote-endpoint property. You should move the endpoint to
> board DT files.
OK, I was wondering, it looked dirty to me.
>
>> + };
>> + };
>> };
>> };
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts index
>> 9696820..390f7db 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> @@ -142,6 +142,17 @@
>> clocks = <&wifi32k>;
>> clock-names = "ext_clock";
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>
> Unless the board has a label for the connector (either on the board, on the
> casing or in the user manual) I'd leave this out. Same comment for the other
> boards.
OK,
Thanks,
Neil
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> &uart_AO {
>> @@ -229,3 +240,7 @@
>> clocks = <&clkc CLKID_FCLK_DIV4>;
>> clock-names = "clkin0";
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi index 203be28..44bdebf
>> 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> @@ -125,6 +125,17 @@
>> clocks = <&wifi32k>;
>> clock-names = "ext_clock";
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> /* This UART is brought out to the DB9 connector */
>> @@ -234,3 +245,7 @@
>> clocks = <&clkc CLKID_FCLK_DIV4>;
>> clock-names = "clkin0";
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi index ac5ad3b..5353a20 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> @@ -506,3 +506,7 @@
>> <&clkc CLKID_FCLK_DIV2>;
>> clock-names = "core", "clkin0", "clkin1";
>> };
>> +
>> +&vpu {
>> + compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts index
>> e99101a..7bd0538 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> @@ -117,6 +117,17 @@
>> clocks = <&wifi32k>;
>> clock-names = "ext_clock";
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> &uart_AO {
>> @@ -203,3 +214,7 @@
>> clocks = <&clkc CLKID_FCLK_DIV4>;
>> clock-names = "clkin0";
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi index 9f89b99..5c7a8fa 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> @@ -299,3 +299,7 @@
>> <&clkc CLKID_FCLK_DIV2>;
>> clock-names = "core", "clkin0", "clkin1";
>> };
>> +
>> +&vpu {
>> + compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts index
>> d320727..5b99749 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> @@ -90,6 +90,17 @@
>> compatible = "mmc-pwrseq-emmc";
>> reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> /* This UART is brought out to the DB9 connector */
>> @@ -167,3 +178,7 @@
>> max-speed = <1000>;
>> };
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi index c1974bb..eb2f0c3 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> @@ -112,3 +112,7 @@
>> };
>> };
>> };
>> +
>> +&vpu {
>> + compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
>> +};
>
^ permalink raw reply
* [GIT PULL v2 9/10] arm64: tegra: Device tree changes for v4.10-rc1
From: Arnd Bergmann @ 2016-11-30 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121102312.19968-1-thierry.reding@gmail.com>
On Monday, November 21, 2016 11:23:12 AM CET Thierry Reding wrote:
> arm64: tegra: Device tree changes for v4.10-rc1
>
> This adds initial support for Tegra186, the P3310 processor module as
> well as the P2771 development board. Not much is functional, but there
> is enough to boot to an initial ramdisk with debug serial output.
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [PATCH] soc: ti: qmss: fix the case when !SMP
From: Grygorii Strashko @ 2016-11-30 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5501170.dgvo5UdPBX@wuerfel>
On 11/30/2016 05:37 AM, Arnd Bergmann wrote:
> On Tuesday, November 29, 2016 4:15:08 PM CET Grygorii Strashko wrote:
>> range->num_irqs++;
>>
>> - if (oirq.args_count == 3)
>> + if (IS_ENABLED(SMP) && oirq.args_count == 3)
>> range->irqs[i].cpu_map =
>> (oirq.args[2] & 0x0000ff00) >> 8;
>>
>
> I think you mean CONFIG_SMP, not SMP. With the change above, the
> code will never be executed.
>
Thanks. I'll resend.
--
regards,
-grygorii
^ permalink raw reply
* [GIT PULL 10/10] arm64: tegra: Default configuration updates for v4.10-rc1
From: Arnd Bergmann @ 2016-11-30 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-10-thierry.reding@gmail.com>
On Friday, November 18, 2016 5:17:19 PM CET Thierry Reding wrote:
> arm64: tegra: Default configuration updates for v4.10-rc1
>
> Enable Tegra186 support.
>
This was already in next/arm64 (but I didn't see a notification),
and with the arm64-dt branch now merged as well, we should have
everything you sent.
Arnd
^ permalink raw reply
* [GIT PULL v2] firmware: SCPI updates for v4.10
From: Arnd Bergmann @ 2016-11-30 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118115615.GB14913@e107155-lin>
On Friday, November 18, 2016 11:56:15 AM CET Sudeep Holla wrote:
> Hi ARM-SoC Team,
>
> I have decoupled the platform specific binding from generic SCPI. Also
> I have renamed "arm,legacy-scpi" to "arm,scpi-pre-1.0". Since I haven't
> heard back any objections from Olof/Rob for my response, I am sending
> the pull request now.
>
Pulled into next/drivers now, sorry for the delay.
Arnd
^ permalink raw reply
* [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration
From: Lorenzo Pieralisi @ 2016-11-30 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480465344-11862-3-git-send-email-sricharan@codeaurora.org>
Sricharan, Robin,
I gave this series a go on ACPI and apart from an SMMU v3 fix-up
it seems to work, more thorough testing required though.
A key question below.
On Wed, Nov 30, 2016 at 05:52:16AM +0530, Sricharan R wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> IOMMU configuration represents unchanging properties of the hardware,
> and as such should only need happen once in a device's lifetime, but
> the necessary interaction with the IOMMU device and driver complicates
> exactly when that point should be.
>
> Since the only reasonable tool available for handling the inter-device
> dependency is probe deferral, we need to prepare of_iommu_configure()
> to run later than it is currently called (i.e. at driver probe rather
> than device creation), to handle being retried, and to tell whether a
> not-yet present IOMMU should be waited for or skipped (by virtue of
> having declared a built-in driver or not).
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/of_iommu.c | 30 +++++++++++++++++++++++++++++-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index ee49081..349bd1d 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -104,12 +104,20 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> int err;
>
> ops = iommu_get_instance(fwnode);
> - if (!ops || !ops->of_xlate)
> + if ((ops && !ops->of_xlate) ||
> + (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
IIUC of_match_node() here is there to check there is a driver compiled
in for this device_node (aka compatible string in OF world), correct ?
If that's the case (and I think that's what Sricharan was referring to
in his ACPI query) I need to cook-up something on the ACPI side to
emulate the OF linker table behaviour (or anyway to detect a driver is
actually in the kernel), it is not that difficult but it is key to know,
I will give it some thought to make it as clean as possible.
Thanks,
Lorenzo
> return NULL;
>
> err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
> if (err)
> return ERR_PTR(err);
> + /*
> + * The otherwise-empty fwspec handily serves to indicate the specific
> + * IOMMU device we're waiting for, which will be useful if we ever get
> + * a proper probe-ordering dependency mechanism in future.
> + */
> + if (!ops)
> + return ERR_PTR(-EPROBE_DEFER);
>
> err = ops->of_xlate(dev, iommu_spec);
> if (err)
> @@ -186,14 +194,34 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
> struct device_node *master_np)
> {
> const struct iommu_ops *ops;
> + struct iommu_fwspec *fwspec = dev->iommu_fwspec;
>
> if (!master_np)
> return NULL;
>
> + if (fwspec) {
> + if (fwspec->ops)
> + return fwspec->ops;
> +
> + /* In the deferred case, start again from scratch */
> + iommu_fwspec_free(dev);
> + }
> +
> if (dev_is_pci(dev))
> ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
> else
> ops = of_platform_iommu_init(dev, master_np);
> + /*
> + * If we have reason to believe the IOMMU driver missed the initial
> + * add_device callback for dev, replay it to get things in order.
> + */
> + if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
> + dev->bus && !dev->iommu_group) {
> + int err = ops->add_device(dev);
> +
> + if (err)
> + ops = ERR_PTR(err);
> + }
>
> return IS_ERR(ops) ? NULL : ops;
> }
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>
^ permalink raw reply
* [PATCH v2] PCI: Add information about describing PCI in ACPI
From: Bjorn Helgaas @ 2016-11-30 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAADWXX_ipJ+pVmV5s2oLCKBrC5qUDASOZf=tpBfJWELExam+hQ@mail.gmail.com>
On Tue, Nov 29, 2016 at 03:39:11PM -0800, Linus Torvalds wrote:
> Bjorn, this email was marked as spam, because:
>
> It has a from address in google.com but has failed google.com's
> required tests for authentication
>
> in particular, it looks like you used a non-google smtp server
> (kernel.org) to send the email, so there is no DKIM hash (or perhaps
> google just uses some other non-standard marker for "this actually
> came from google"). So gmail marks it as spam because dmarc fails:
>
> dmarc=fail (p=REJECT dis=NONE) header.from=google.com
>
> Just to let you know. If you use your google.com email, you do need to
> go through the google smtp server.
>
> This may or may not be new - I didn't go and look at old messages of
> yours, but it is possible that google.com enabled dmarc/dkim recently.
Argh, thanks for letting me know. Looks like I've had this broken for a
long time, but I didn't notice. I think I have it fixed so git will record
the author as bhelgaas at google.com, but git/stgit will send email from
helgaas at kernel.org via the kernel.org smtp server.
^ permalink raw reply
* [PATCH v5 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Wolfram Sang @ 2016-11-30 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e5c36597-d917-0555-89cd-35f68087c1c5@free-electrons.com>
> What do you prefer everything in one commit or two seperated commit ? (one
> including the new fields for fm_mask and another one to add support for
> a3700-i2c).
One commit is fine!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/0fcbc15f/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Kevin Hilman @ 2016-11-30 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2e1b16c6-eec5-8cf3-5795-d6de02f36570@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Hi Laurent,
> On 11/30/2016 04:58 PM, Laurent Pinchart wrote:
>> Hi Neil,
>>
>> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>> ---
>>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>>
>> I forgot to mention that the file should not be named meson-drm.txt as DRM is
>> a Linux-specific concept. You can name it meson.txt, but a better option would
>> be amlogic,meson.txt. By the way does it really need a subdirectory ?
>
> I took example of the sun4i layout the naming, and no it does not need a subdirector..
>
> I will move it to amlogic,meson.txt, seems far better.
>
To me, amlogic,meson is redundant. Probably should be amlogic,vpu.txt?
Kevin
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m21sxtkkg1.fsf@baylibre.com>
On 11/30/2016 05:21 PM, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>
>> Hi Laurent,
>> On 11/30/2016 04:58 PM, Laurent Pinchart wrote:
>>> Hi Neil,
>>>
>>> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>> ---
>>>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>>>
>>> I forgot to mention that the file should not be named meson-drm.txt as DRM is
>>> a Linux-specific concept. You can name it meson.txt, but a better option would
>>> be amlogic,meson.txt. By the way does it really need a subdirectory ?
>>
>> I took example of the sun4i layout the naming, and no it does not need a subdirector..
>>
>> I will move it to amlogic,meson.txt, seems far better.
>>
>
> To me, amlogic,meson is redundant. Probably should be amlogic,vpu.txt?
>
> Kevin
>
Yes, seems more coherent.
Thanks,
Neil
^ permalink raw reply
* [PATCH v3 2/5] i2c: Add STM32F4 I2C driver
From: Wolfram Sang @ 2016-11-30 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOAejn0BZNH82kY_7UR1EjV7M1G+9jGihGb4-uCs9=XiPHUYxQ@mail.gmail.com>
Hi,
> I was too busy in another project but now I am ready to complete the
> upstream of the STM32F4 I2C driver.
Nice.
> >> +static void stm32f4_i2c_set_periph_clk_freq(struct stm32f4_i2c_dev *i2c_dev)
> >> +{
> >> + u32 clk_rate, cr2, freq;
> >> +
> >> + cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
> >> + cr2 &= ~STM32F4_I2C_CR2_FREQ_MASK;
> >> +
> >> + clk_rate = clk_get_rate(i2c_dev->clk);
> >> + freq = clk_rate / MHZ_TO_HZ;
> >> +
> >> + if (freq > STM32F4_I2C_MAX_FREQ)
> >> + freq = STM32F4_I2C_MAX_FREQ;
> >> + if (freq < STM32F4_I2C_MIN_FREQ)
> >> + freq = STM32F4_I2C_MIN_FREQ;
> >
> > clamp() to enforce the range?
> Sorry but what do you mean by "clamp()" ?
The kernel has a clamp() function which would fit this purpose, I think.
Regards,
Wolfram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/e13dca49/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] ACPI: Ignore Consumer/Producer for QWord/DWord/Word Address Space
From: Lorenzo Pieralisi @ 2016-11-30 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130155616.GA9693@bhelgaas-glaptop.roam.corp.google.com>
On Wed, Nov 30, 2016 at 09:56:17AM -0600, Bjorn Helgaas wrote:
> On Wed, Nov 30, 2016 at 12:04:25PM +0000, Lorenzo Pieralisi wrote:
> > On Tue, Nov 29, 2016 at 12:43:34PM -0600, Bjorn Helgaas wrote:
> > > Per ACPI spec r6.0, sec 6.4.3.5.1, 2, 3, Bit [0] of General Flags (the
> > > Consumer/Producer bit) should be ignored for QWord/DWord/Word Address Space
> > > descriptors. The Consumer/Producer bit is defined only for the Extended
> > > Address Space descriptor.
> > >
> > > Ignore Consumer/Producer except for Extended Address Space descriptors.
> > >
> > > Note that for QWord/DWord/Word descriptors, we previously applied the
> > > translation offset (_TRA) only when the Consumer/Producer bit was set.
> >
> > "..Consumer/Producer bit was clear" ? If that bit was set:
> >
> > struct acpi_resource_address->producer_consumer == ACPI_CONSUMER
> >
> > and we are not applying the _TRA offset in that case, right ?
>
> Right, of course. How about this instead?
>
> Note that for QWord/DWord/Word descriptors, we previously applied the
> translation offset (_TRA) only for Producers, i.e., when the Consumer/
> Producer bit was clear. This patch changes that: for those descriptors,
> we ignore Consumer/Producer and always apply the translation offset.
Yes that's a perfect description, thanks a lot !
Lorenzo
> > > This patch changes that: for those descriptors, we ignore Consumer/Producer
> > > and always apply the translation offset.
> > >
> > > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> > > ---
> > > drivers/acpi/resource.c | 16 +++++++++++-----
> > > 1 file changed, 11 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> > > index 2732d39e..b45cd8f 100644
> > > --- a/drivers/acpi/resource.c
> > > +++ b/drivers/acpi/resource.c
> > > @@ -261,11 +261,16 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> > > * primary side. Non-bridge devices must list 0 for all Address
> > > * Translation offset bits.
> > > */
> > > - if (addr->producer_consumer == ACPI_PRODUCER)
> > > + if (ares->type == ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64) {
> > > + if (addr->producer_consumer == ACPI_PRODUCER)
> > > + offset = attr->translation_offset;
> > > + else if (attr->translation_offset)
> > > + pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
> > > + attr->translation_offset);
> > > + } else {
> > > offset = attr->translation_offset;
> > > - else if (attr->translation_offset)
> > > - pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
> > > - attr->translation_offset);
> > > + }
> > > +
> > > start = attr->minimum + offset;
> > > end = attr->maximum + offset;
> > >
> > > @@ -294,7 +299,8 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> > > return false;
> > > }
> > >
> > > - if (addr->producer_consumer == ACPI_PRODUCER)
> > > + if (ares->type == ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64 &&
> > > + addr->producer_consumer == ACPI_PRODUCER)
> > > res->flags |= IORESOURCE_WINDOW;
> > >
> > > if (addr->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > > the body of a message to majordomo at vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [sample] A sample program for MRS emulation
From: Dave Martin @ 2016-11-30 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480518901-18544-11-git-send-email-suzuki.poulose@arm.com>
On Wed, Nov 30, 2016 at 03:15:01PM +0000, Suzuki K Poulose wrote:
> Here is a sample program which demonstrates how to use mrs
> emulation to fetch the ID registers.
Are we planning to add this in Documentation/? If so, we might want
some tweaks (noted below).
>
> ----8>----
> /*
> * Sample program to demonstrate the MRS emulation
> * ABI.
overwrapped?
> * Copyright (C) 2015-2016, ARM Ltd
> *
> * Author: Suzuki K Poulose <suzuki.poulose@arm.com>
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> *
> * This program is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> *
> * This program is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> */
>
> #include <stdio.h>
>
> #define get_cpu_ftr(id) ({ \
> unsigned long long __val; \
> asm("mrs %0, "#id : "=r" (__val)); \
> printf("%-20s: 0x%016lx\n", #id, __val); \
> })
>
> int main()
(void)
> {
We don't wan't people using the MRS emulation without checking for its
availability first.
Something like this may work (untested), with the caveat that getauxval()
is a GNU libc extension, and other environments may require a different
mechanism to obtain the hwcaps.
--8<--
#include <sys/auxv.h>
#include <asm/hwcap.h>
/* ... */
if (!getauxval(AT_HWCAP) & HWCAP_CPUID) {
fputs("CPUID registers unavailable\n", stderr);
return 1;
}
-->8--
Cheers
---Dave
>
> get_cpu_ftr(ID_AA64ISAR0_EL1);
> get_cpu_ftr(ID_AA64ISAR1_EL1);
> get_cpu_ftr(ID_AA64MMFR0_EL1);
> get_cpu_ftr(ID_AA64MMFR1_EL1);
> get_cpu_ftr(ID_AA64PFR0_EL1);
> get_cpu_ftr(ID_AA64PFR1_EL1);
> get_cpu_ftr(ID_AA64DFR0_EL1);
> get_cpu_ftr(ID_AA64DFR1_EL1);
>
> get_cpu_ftr(MIDR_EL1);
> get_cpu_ftr(MPIDR_EL1);
> get_cpu_ftr(REVIDR_EL1);
> return 0;
> }
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: juno: Correct PCI IO window
From: Sudeep Holla @ 2016-11-30 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480452310-29286-1-git-send-email-jeremy.linton@arm.com>
Hi Jeremy,
On 29/11/16 20:45, Jeremy Linton wrote:
> The PCIe root complex on Juno translates the MMIO mapped
> at 0x5f800000 to the PIO address range starting at 0
> (which is common because PIO addresses are generally < 64k).
> Correct the DT to reflect this.
>
I have another DT fix that I have asked ARM-SoC guys to pick up directly
from the list. If that doesn't happen, I will send PR including both.
If that happens then we need to send this to them to be picked directly.
At this point I want to wait for couple of days to avoid confusion.
--
Regards,
Sudeep
^ permalink raw reply
* [GIT PULL 10/10] arm64: tegra: Default configuration updates for v4.10-rc1
From: Thierry Reding @ 2016-11-30 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6706502.us21ohNYZA@wuerfel>
On Wed, Nov 30, 2016 at 05:10:43PM +0100, Arnd Bergmann wrote:
> On Friday, November 18, 2016 5:17:19 PM CET Thierry Reding wrote:
> > arm64: tegra: Default configuration updates for v4.10-rc1
> >
> > Enable Tegra186 support.
> >
>
> This was already in next/arm64 (but I didn't see a notification),
> and with the arm64-dt branch now merged as well, we should have
> everything you sent.
I had also sent a couple of individual patches that seemed to not have
it made into v4.9 and v4.8 for some reason (they were part of the pull
requests, as far as I can tell). Do you think you could pull those in
as well?
Thanks,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/b14ea724/attachment.sig>
^ permalink raw reply
* [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration
From: Robin Murphy @ 2016-11-30 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130161723.GA9042@red-moon>
On 30/11/16 16:17, Lorenzo Pieralisi wrote:
> Sricharan, Robin,
>
> I gave this series a go on ACPI and apart from an SMMU v3 fix-up
> it seems to work, more thorough testing required though.
>
> A key question below.
>
> On Wed, Nov 30, 2016 at 05:52:16AM +0530, Sricharan R wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> IOMMU configuration represents unchanging properties of the hardware,
>> and as such should only need happen once in a device's lifetime, but
>> the necessary interaction with the IOMMU device and driver complicates
>> exactly when that point should be.
>>
>> Since the only reasonable tool available for handling the inter-device
>> dependency is probe deferral, we need to prepare of_iommu_configure()
>> to run later than it is currently called (i.e. at driver probe rather
>> than device creation), to handle being retried, and to tell whether a
>> not-yet present IOMMU should be waited for or skipped (by virtue of
>> having declared a built-in driver or not).
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/of_iommu.c | 30 +++++++++++++++++++++++++++++-
>> 1 file changed, 29 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index ee49081..349bd1d 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -104,12 +104,20 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
>> int err;
>>
>> ops = iommu_get_instance(fwnode);
>> - if (!ops || !ops->of_xlate)
>> + if ((ops && !ops->of_xlate) ||
>> + (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
>
> IIUC of_match_node() here is there to check there is a driver compiled
> in for this device_node (aka compatible string in OF world), correct ?
Yes - specifically, it's checking the magic table for a matching
IOMMU_OF_DECLARE entry.
> If that's the case (and I think that's what Sricharan was referring to
> in his ACPI query) I need to cook-up something on the ACPI side to
> emulate the OF linker table behaviour (or anyway to detect a driver is
> actually in the kernel), it is not that difficult but it is key to know,
> I will give it some thought to make it as clean as possible.
I didn't think this would be a concern for ACPI, since IORT works much
the same way the current of_iommu_init_fn/of_platform_device_create()
bodges in drivers so for DT. If you can only discover SMMUs from IORT,
then iort_init_platform_devices() will have already created every SMMU
that's going to exist before discovering other devices from wherever
they come from, thus you could never get into the situation of probing a
device without its SMMU being ready (if it's ever going to be). Is that
not right?
Robin.
>
> Thanks,
> Lorenzo
>
>> return NULL;
>>
>> err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
>> if (err)
>> return ERR_PTR(err);
>> + /*
>> + * The otherwise-empty fwspec handily serves to indicate the specific
>> + * IOMMU device we're waiting for, which will be useful if we ever get
>> + * a proper probe-ordering dependency mechanism in future.
>> + */
>> + if (!ops)
>> + return ERR_PTR(-EPROBE_DEFER);
>>
>> err = ops->of_xlate(dev, iommu_spec);
>> if (err)
>> @@ -186,14 +194,34 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
>> struct device_node *master_np)
>> {
>> const struct iommu_ops *ops;
>> + struct iommu_fwspec *fwspec = dev->iommu_fwspec;
>>
>> if (!master_np)
>> return NULL;
>>
>> + if (fwspec) {
>> + if (fwspec->ops)
>> + return fwspec->ops;
>> +
>> + /* In the deferred case, start again from scratch */
>> + iommu_fwspec_free(dev);
>> + }
>> +
>> if (dev_is_pci(dev))
>> ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>> else
>> ops = of_platform_iommu_init(dev, master_np);
>> + /*
>> + * If we have reason to believe the IOMMU driver missed the initial
>> + * add_device callback for dev, replay it to get things in order.
>> + */
>> + if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
>> + dev->bus && !dev->iommu_group) {
>> + int err = ops->add_device(dev);
>> +
>> + if (err)
>> + ops = ERR_PTR(err);
>> + }
>>
>> return IS_ERR(ops) ? NULL : ops;
>> }
>> --
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>>
^ permalink raw reply
* [GIT PULL] ARM: keystone: add TI SCI protocol support for v4.10
From: Arnd Bergmann @ 2016-11-30 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d685444b-4275-e6e6-aae6-214a41776a28@ti.com>
On Monday, November 28, 2016 6:42:41 PM CET Tero Kristo wrote:
> Gentle ping on this, is anybody going to pull this one?
>
> -Tero
>
> On 27/10/16 12:30, Tero Kristo wrote:
> > Hi Arnd, Olof, Kevin,
> >
> > This pull introduces the TI SCI protocol support for keystone family of
> > devices, targeted for v4.10 merge window. We discussed with Santosh
> > (keystone maintainer) that it would probably be better that I'll be
> > sending the pull requests for this directly, avoiding one extra step of
> > merges.
>
Sorry for the delay. I just saw this pull request in the backlog
and had to take a closer look first. I probably would have commented
on a few details in a proper review, but overall this seems harmless
enough, so I've merged it into next/drivers in the end.
There was no branch description in
https://github.com/t-kristo/linux-pm.git for-4.10-ti-sci-base
and I ended up taking something from the wiki. This is now the
commit I ended up with:
commit ba9cb7b9ffa4a4056158bc8570f1a851e4a6a8ae
Merge: e7541f9 912cffb
Author: Arnd Bergmann <arnd@arndb.de>
Date: Wed Nov 30 17:13:13 2016 +0100
Merge branch 'for-4.10-ti-sci-base' of https://github.com/t-kristo/linux-pm into next/drivers
Merge "ARM: keystone: add TI SCI protocol support for v4.10" from
Tero Kristo:
[description taken from http://processors.wiki.ti.com/index.php/TISCI
Texas Instruments' Keystone generation System on Chips (SoC) starting
with 66AK2G02, now include a dedicated SoC System Control entity called
PMMC(Power Management Micro Controller) in line with ARM architecture
recommendations. The function of this module is to integrate all system
operations in a centralized location. Communication with the SoC System
Control entity from various processing units like ARM/DSP occurs over
Message Manager hardware block.
...
Texas Instruments' System Control Interface defines the communication
protocol between various processing entities to the System Control Entity
on TI SoCs. This is a set of message formats and sequence of operations
required to communicate and get system services processed from System
Control entity in the SoC.]
* 'for-4.10-ti-sci-base' of https://github.com/t-kristo/linux-pm:
firmware: ti_sci: Add support for reboot core service
firmware: ti_sci: Add support for Clock control
firmware: ti_sci: Add support for Device control
firmware: Add basic support for TI System Control Interface (TI-SCI) protocol
Documentation: Add support for TI System Control Interface (TI-SCI) protocol
Arnd
^ permalink raw reply
* [GIT PULL 1/6] Broadcom soc changes for 4.10
From: Arnd Bergmann @ 2016-11-30 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122054824.16974-1-f.fainelli@gmail.com>
On Monday, November 21, 2016 9:48:19 PM CET Florian Fainelli wrote:
> This pull request contains Broadcom ARM-based SoC changes for 4.10, please pull
> the following:
>
> - Rafal adds back the abort handler hook on BCM5301x which is required to silence
> errors forwared from the PCIe controller that cannot be silenced at the PCIe RC level
>
Pulled into next/soc.
It's unclear to me whether we want this to be backported to stable kernels,
can you clarify?
Thanks,
Arnd
^ permalink raw reply
* [PATCH v2] soc: ti: qmss: fix the case when !SMP
From: Grygorii Strashko @ 2016-11-30 16:53 UTC (permalink / raw)
To: linux-arm-kernel
The irq_set_affinity_hint() will always fail when !SMP and
Networking will fail on Keystone 2 devices in this case.
Hence, fix by ignoring IRQ affinity settings when !SMP.
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/soc/ti/knav_qmss_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index b73e353..eacad57 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1228,7 +1228,7 @@ static int knav_setup_queue_range(struct knav_device *kdev,
range->num_irqs++;
- if (oirq.args_count == 3)
+ if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3)
range->irqs[i].cpu_map =
(oirq.args[2] & 0x0000ff00) >> 8;
}
--
2.10.1
^ permalink raw reply related
* [GIT PULL 2/6] Broadcom devicetree changes for 4.10
From: Arnd Bergmann @ 2016-11-30 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122054824.16974-2-f.fainelli@gmail.com>
On Monday, November 21, 2016 9:48:20 PM CET Florian Fainelli wrote:
> This pull request contains Broadcom ARM-based SoC Device Tree changes for 4.10,
> please pull the following:
>
> - Rafal adds support for the Netgear R8500 routers, adds basic support
> for the Tenda AC9 router which uses the new BCM53573 SoC (single core Cortex
> A7). He also enables the UART on the Netgear R8000 and restructures the
> include files a bit for the BCM47094 SoC, finally he adds USB 3.0 PHY nodes
> which enables USB 3.0 on BCM5301X devices that support it. Finally he adds
> support for the TP-LINK Archer C9 V1 router.
>
> - Kamal adds support for the QSPI controller on the Northstar Plus SoCs and updates
> the bcm958625k reference board to have it enabled
>
> - Dan adds support for the Luxul XAP-1510 (using a BCM4708) and XWR-3100 (using
> a BCM47094)
>
> - Scott fixes the pinctrl names in the Cygnus DTS files
>
> - Jonathan enables the Broadcom iProc mailbox controller for Broadcom Cygnus/iProc
> SoCs, he adds interrupt support for the GPIO CRMU hardware block and finally adds
> the node for the OTP controller found on Cygnus SoCs
>
> - Dhananjay enables the GPIO B controller on Norstarh Plus SoCs
>
> - Eric defines standard pinctrl groups in the BCM2835 GPIO node
>
> - Gerd adds definitions for the pinctrl groups and updates the PWM, I2C and SDHCI nodes
> to use their appropriate pinctrl functions
>
> - Linus adds names for the Raspberry Pi GPIO lines based on the datasheet
>
> - Martin adds the DT binding and nodes for the Raspberry Pi firmware thermal block
>
> - Stefan fixes a few typos with respect to the BCM2835 mailbox binding example and
> Device Tree nodes he also fixes the Raspberry Pi GPIO lines names and finally
> adds names for the Raspberry Zero GPIO lines
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 3/6] Broadcom devicetree-arm64 changes for 4.10
From: Arnd Bergmann @ 2016-11-30 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122054824.16974-3-f.fainelli@gmail.com>
On Monday, November 21, 2016 9:48:21 PM CET Florian Fainelli wrote:
> This pull request contains Broadcom ARM64 based SoC Device Tree changes for
> 4.10, please pull the following:
>
> - Robin updates the Northstart 2 DTS to use the generic IOMMU binding
>
> - Scott renames the Broadcom Northstar 2 binding document to use a standard name
> including the brcm vendor prefix
>
> - Kamal adds the QSPI Device Tree node to the Northstar 2 SoC and updates the
> Northstar 2 SVK reference board DTS file with it enabled.
>
> - Rob adds the Device Tree node for the Broadcom PDC (mailbox) hardware to the
> Northstar 2 SoC
>
> - Jon enables the SDIO1 block and adds proper PCIe PHYs Device Tree nodes to the
> Northstar 2 SoC
>
> - Ray adds required properties NAND controller properties to make NAND work on
> the Northstar 2 SVK board, this was submitted as a 4.9 fixes and is included
> here to resolve DTS file merges
>
> - Andrea removes an incorrect power LED from the Raspberry Pi 3 DTS
>
> - Andreas fixes the compatible string for the BCM2837 (Raspberry Pi 3)
>
> - Eric defines standard pinctrl groups in the BCM2835 GPIO node
>
> - Gerd adds definitions for the pinctrl groups and updates the PWM, I2C and SDHCI nodes
> to use their appropriate pinctrl functions
>
> - Linus adds names for the Raspberry Pi GPIO lines based on the datasheet
>
> - Martin adds the DT binding and nodes for the Raspberry Pi firmware thermal block
>
> - Stefan fixes a few typos with respect to the BCM2835 mailbox binding example and
> Device Tree nodes he also uses the proper DTSI file to define the USB host mode
> for the USB Device Tree nodes
>
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [PATCH] soc: ti: qmss: fix the case when !SMP
From: Santosh Shilimkar @ 2016-11-30 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5501170.dgvo5UdPBX@wuerfel>
Hi Grygorii,
On 11/30/2016 3:37 AM, Arnd Bergmann wrote:
> On Tuesday, November 29, 2016 4:15:08 PM CET Grygorii Strashko wrote:
>> range->num_irqs++;
>>
>> - if (oirq.args_count == 3)
>> + if (IS_ENABLED(SMP) && oirq.args_count == 3)
>> range->irqs[i].cpu_map =
>> (oirq.args[2] & 0x0000ff00) >> 8;
>>
>
> I think you mean CONFIG_SMP, not SMP. With the change above, the
> code will never be executed.
>
Is that the full patch ? Can you post updated patch wit above fixed
and copy me. I will pick it up.
Regards,
Santosh
^ 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