* [PATCH] PCI:MSI Return -ENOSPC when requested vectors is not enough
From: Christoph Hellwig @ 2016-12-01 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480558504-18691-1-git-send-email-dennis.chen@arm.com>
Hi Dennis,
I've fixed ahci to treat all errors the same in the meantime, please
try latest Linux tree. That being said I don't like the different
error returns from __pci_enable_msi_range (and __pci_enable_msix_range),
but they have been there for a while.
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Maxime Ripard @ 2016-12-01 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1971681480527210@web5g.yandex.ru>
On Thu, Dec 01, 2016 at 01:33:30AM +0800, Icenowy Zheng wrote:
> >> ?????????hdmi-out {
> >> ?????????????????compatible = "hdmi-connector";
> >> ?????????????????type = "a";
> >> ?????????????????/* I2C bus and GPIO references are made up for the example */
> >> ?????????????????ddc-i2c-bus = <&i2c4>;
> >> ?????????????????hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>
> >
> > the "hdmi-connector" is a big piece of software. It must handle a lot
> > of more and more exotic connectors.
> > So, I hope that you have written a "simple-hdmi-connector" which does
> > nothing but setting the connector type.
> > Where is it?
>
> I suddenly thought about something...
>
> If a DVI connector instead of a HDMI connector is soldered, how
> should such a device tree be written?
Use a dvi-connector instead :)
> How about solder a HDMI-to-VGA bridge on the board? (Maybe there
> should be "dumb-hdmi-dvi-bridge" and "dumb-hdmi-vga-bridge"
> drivers?)
It probably wouldn't be dumb, but yeah, it would definitely be a
bridge instead of the connector.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20161201/1f559ca4/attachment.sig>
^ permalink raw reply
* [PATCH v2 4/9] clk: stm32f4: Add lcd-tft clock
From: Gabriel Fernandez @ 2016-12-01 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130205333.tiukcjbspuqmedgw@rob-hp-laptop>
Hi Rob,
Thanks for reviewing
On 11/30/2016 09:53 PM, Rob Herring wrote:
> On Thu, Nov 24, 2016 at 03:45:44PM +0100, gabriel.fernandez at st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> This patch introduces lcd-tft clock for stm32f4 soc.
>>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>> ---
>> .../devicetree/bindings/clock/st,stm32-rcc.txt | 1 +
>> drivers/clk/clk-stm32f4.c | 118 +++++++++++++++++++++
>> include/dt-bindings/clock/stm32f4-clock.h | 3 +-
>> 3 files changed, 121 insertions(+), 1 deletion(-)
>
>> diff --git a/include/dt-bindings/clock/stm32f4-clock.h b/include/dt-bindings/clock/stm32f4-clock.h
>> index 56b8e10..1be4a3a 100644
>> --- a/include/dt-bindings/clock/stm32f4-clock.h
>> +++ b/include/dt-bindings/clock/stm32f4-clock.h
>> @@ -27,7 +27,8 @@
>> #define CLK_RTC 5
>> #define PLL_VCO_I2S 6
>> #define PLL_VCO_SAI 7
>> +#define CLK_LCD 8
>>
>> -#define END_PRIMARY_CLK 8
>> +#define END_PRIMARY_CLK 9
> Do you really need this? Having this change could cause compatibility
> problems between dtb and kernel versions.
>
> Please restructure the patch series and put all of the binding changes
> including this header into a single patch. Incrementally add s/w
> features, not h/w.
>
> Rob
Okay
Best Regards
Gabriel
^ permalink raw reply
* [PATCH v3 0/4] drm: Add support for the Amlogic Video Processing Unit
From: Neil Armstrong @ 2016-12-01 9:05 UTC (permalink / raw)
To: linux-arm-kernel
This a repost of the previous version at [3] with fixes, the following patches will
be sent via a PULL Request once the DT maintainers acks the DT bindings.
The Amlogic maintainer will take the arm64 DT patches to avoid merges conflicts.
The Amlogic Meson SoCs embeds a Video Processing Unit able to output at least
a Composite/CVBS Video with embedded VDAC and an HDMI Link with Embedded HDMI
Transceiver.
Thus, the current driver does not support HDMI yet.
The Video Processig Unit is composed of multiple modules like the Video
Input Unit and the Video Post Processing that can be associated to a
CRTC with Planes management.
The last Unit is the Venc that embeds at least 3 Encoders, ENCI for Interlace
Video used by CVBS or HDMI, ENCP for Progressive Video used by the HDMI
Transceiver and ENCL for LCD Display.
The LCD Display is not planned to be supported on the Meson GX Family.
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.
The driver has been tested with Xorg modesetting driver and Weston DRM backend.
Changes since v1 at [3] :
- Rename and move dt-bindings file
- Clarified VPU node graph outputs
- Removed all of_machine_is_compatible
- Cleaned DTS endpoint and board connectors nodes
- Added Laurent Pinchard's ack and reviewed-bys
Changes since v1 at [2] :
- Simplify bindings to have a "composite-video-connector" to represent the on-board composite connector
- Remove the component_match binding since it's unused for now
- Moved all DRM connector code back in the venc_cvbs file
- Check for port endpoints validity to detech connector existence
- Added Daniel Vetter's ack on non-dt patches commit messages
Changes since RFC at [1] :
- Add maintainers entry
- Move all Plane and CRTC code from backend to corresponding DRM code
- Keep only init and common code in backend source files
- Move the CVBS encoder out of the CVBS DT node, only keep the connector
- Various cleanups using DRM helpers
- Cleanup of copyright headers
- Fixup of bindings documentation
[1] http://lkml.kernel.org/r/1480089791-12517-1-git-send-email-narmstrong at baylibre.com
[2] http://lkml.kernel.org/r/1480416469-9655-1-git-send-email-narmstrong at baylibre.com
[3] http://lkml.kernel.org/r/1480520625-13269-1-git-send-email-narmstrong at baylibre.com
Neil Armstrong (4):
drm: Add support for Amlogic Meson Graphic Controller
ARM64: dts: meson-gx: Add Graphic Controller nodes
dt-bindings: display: add Amlogic Meson DRM Bindings
MAINTAINERS: add entry for Amlogic DRM drivers
.../bindings/display/amlogic,meson-vpu.txt | 112 ++
MAINTAINERS | 9 +
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 16 +
.../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 16 +
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 16 +
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 +
.../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 16 +
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 +
.../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 16 +
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 +
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 | 59 +
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 +
33 files changed, 4089 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
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
--
1.9.1
^ permalink raw reply
* [PATCH v3 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Neil Armstrong @ 2016-12-01 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480583160-31806-1-git-send-email-narmstrong@baylibre.com>
Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
boards.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 16 ++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 16 ++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++++
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 ++++
8 files changed, 92 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index fc033c0..eada0b5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -356,5 +356,21 @@
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 */
+ cvbs_vdac_port: port at 0 {
+ reg = <0>;
+ };
+ };
};
};
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..4cbd626 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,16 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
&uart_AO {
@@ -229,3 +239,9 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_port {
+ cvbs_vdac_out: endpoint {
+ 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..4a96e0f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -125,6 +125,16 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
/* This UART is brought out to the DB9 connector */
@@ -234,3 +244,9 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_port {
+ cvbs_vdac_out: endpoint {
+ 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..cea4a3e 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,16 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
&uart_AO {
@@ -203,3 +213,9 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_port {
+ cvbs_vdac_out: endpoint {
+ 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..f2d0861 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,16 @@
compatible = "mmc-pwrseq-emmc";
reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
/* This UART is brought out to the DB9 connector */
@@ -167,3 +177,9 @@
max-speed = <1000>;
};
};
+
+&cvbs_vdac_port {
+ cvbs_vdac_out: endpoint {
+ 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";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v3 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-12-01 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480583160-31806-1-git-send-email-narmstrong@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/display/amlogic,meson-vpu.txt | 112 +++++++++++++++++++++
1 file changed, 112 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
new file mode 100644
index 0000000..00f74ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
@@ -0,0 +1,112 @@
+Amlogic Meson Display Controller
+================================
+
+The Amlogic Meson Display controller is composed of several components
+that are going to be documented below:
+
+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.
+
+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
+
+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 VPU output.
+
+ Port 0 Port 1
+-----------------------------------------
+ S905 (GXBB) CVBS VDAC HDMI-TX
+ S905X (GXL) CVBS VDAC HDMI-TX
+ S905D (GXL) CVBS VDAC HDMI-TX
+ S912 (GXM) CVBS VDAC HDMI-TX
+
+Example:
+
+tv-connector {
+ compatible = "composite-video-connector";
+
+ port {
+ tv_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+};
+
+vpu: vpu at d0100000 {
+ compatible = "amlogic,meson-gxbb-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 {
+ remote-endpoint = <&tv_connector_in>;
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v3 4/4] MAINTAINERS: add entry for Amlogic DRM drivers
From: Neil Armstrong @ 2016-12-01 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480583160-31806-1-git-send-email-narmstrong@baylibre.com>
Add myself as maintainer for Amlogic DRM drivers.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7..b1ad45b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4078,6 +4078,15 @@ S: Supported
F: drivers/gpu/drm/sun4i/
F: Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+DRM DRIVERS FOR AMLOGIC SOCS
+M: Neil Armstrong <narmstrong@baylibre.com>
+L: dri-devel at lists.freedesktop.org
+L: linux-amlogic at lists.infradead.org
+W: http://linux-meson.com/
+S: Supported
+F: drivers/gpu/drm/meson/
+F: Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
+
DRM DRIVERS FOR EXYNOS
M: Inki Dae <inki.dae@samsung.com>
M: Joonyoung Shim <jy0922.shim@samsung.com>
--
1.9.1
^ permalink raw reply related
* [PATCH] arm64: dts: h3ulcb: Provide sd0_uhs node
From: Simon Horman @ 2016-12-01 9:07 UTC (permalink / raw)
To: linux-arm-kernel
Provide separaate sd0 and sd0_uhs nodes rather than duplicate sd0 nodes.
Cc: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Fixes: 93373c309a70 ("arm64: dts: h3ulcb: rename SDHI0 pins")
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 6ffb0517421a..dbea2c3d8f0c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -169,7 +169,7 @@
power-source = <3300>;
};
- sdhi0_pins_uhs: sd0 {
+ sdhi0_pins_uhs: sd0_uhs {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
power-source = <1800>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [GIT PULL] Renesas ARM Based SoC Match Updates for v4.10
From: Arnd Bergmann @ 2016-12-01 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201084758.GC18042@verge.net.au>
On Thursday, December 1, 2016 9:47:58 AM CET Simon Horman wrote:
> Thanks for pulling this and other outstanding pull requests from Geert and
> myself. I don't think we have anything more outstanding at this time.
Ok, thanks for the confirmation!
Arnd
^ permalink raw reply
* [PATCH 2/2] dt-bindings: Add DT bindings info for FlexRM mailbox driver
From: Anup Patel @ 2016-12-01 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130213854.jmjwcis2zid6busv@rob-hp-laptop>
On Thu, Dec 1, 2016 at 3:08 AM, Rob Herring <robh@kernel.org> wrote:
> On Fri, Nov 25, 2016 at 10:05:51AM +0530, Anup Patel wrote:
>> This patch adds device tree bindings document for the FlexRM
>> mailbox driver.
>
> Bindings document h/w, not drivers.
OK, I will rephrase this.
>
>>
>> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
>> ---
>> .../bindings/mailbox/brcm,flexrm-mbox.txt | 60 ++++++++++++++++++++++
>> 1 file changed, 60 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
>> new file mode 100644
>> index 0000000..7969b1c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
>> @@ -0,0 +1,60 @@
>> +Broadcom FlexRM Mailbox Driver
>
> h/w
OK, I will rephrase this.
>
>> +===============================
>> +The Broadcom FlexRM ring manager provides a set of rings which can be
>> +used to submit work to offload engines. An SoC may have multiple FlexRM
>> +hardware blocks. There is one device tree entry per block. The FlexRM
>> +mailbox drivers creates a mailbox instance using FlexRM rings where
>> +each mailbox channel is a separate FlexRM ring.
>> +
>> +Required properties:
>> +--------------------
>> +- compatible: Should be "brcm,flexrm-mbox"
>
> Sounds generic. Add SoC specific compatible strings please.
OK, will do.
>
>> +- reg: Specifies base physical address and size of the FlexRM
>> + ring registers
>> +- msi-parent: Phandles (and potential Device IDs) to MSI controllers
>> + The FlexRM engine will send MSIs (instead of wired
>> + interrupts) to CPU. There is one MSI for each FlexRM ring.
>
> One ring is one h/w block, right? How many instances is not really
> relevant.
No, FlexRM is the HW block. One instance of FlexRM provides a set of
rings (typically 32 or more).
There are lot other registers in FlexRM apart from ring registers. Out of
these, only ring registers are accessible to non-secured world (i.e. Linux)
whereas all other registers are only accessible to secure-world firmware
(typically ATF).
>
>> + Refer devicetree/bindings/interrupt-controller/msi.txt
>> +- #mbox-cells: Specifies the number of cells needed to encode a mailbox
>> + channel. This should be 3.
>> +
>> + The 1st cell is the mailbox channel number.
>> +
>> + The 2nd cell contains MSI completion threshold. This is the
>> + number of completion messages for which FlexRM will inject
>> + one MSI interrupt to CPU.
>> +
>> + The 3nd cell contains MSI timer value representing time for
>> + which FlexRM will wait to accumulate N completion messages
>> + where N is the value specified by 2nd cell above. If FlexRM
>> + does not get required number of completion messages in time
>> + specified by this cell then it will inject one MSI interrupt
>> + to CPU provided atleast one completion message is available.
>> +
>> +Optional properties:
>> +--------------------
>> +- dma-coherent: Present if DMA operations made by the FlexRM engine (such
>> + as DMA descriptor access, access to buffers pointed by DMA
>> + descriptors and read/write pointer updates to DDR) are
>> + cache coherent with the CPU.
>> +
>> +Example:
>> +--------
>> +crypto_mbox: mbox at 67000000 {
>> + compatible = "brcm,flexrm-mbox";
>> + reg = <0x67000000 0x200000>;
>> + msi-parent = <&gic_its 0x7f00>;
>> + #mbox-cells = <3>;
>> +};
>> +
>> +crypto_client {
>
> Is this a h/w block or purely a driver on top of the mailbox? The latter
> doesn't belong in DT.
The FlexRM is one HW block. It provides ring-based programming
interface to various offload engines which are separate HW blocks.
The driver for FlexRM is implemented as mailbox controller driver
while the offload engine drivers will be mailbox clients.
>
>> + ...
>> + mboxes = <&crypto_mbox 0 0x1 0xffff>,
>> + <&crypto_mbox 1 0x1 0xffff>,
>> + <&crypto_mbox 16 0x1 0xffff>,
>> + <&crypto_mbox 17 0x1 0xffff>,
>> + <&crypto_mbox 30 0x1 0xffff>,
>> + <&crypto_mbox 31 0x1 0xffff>;
>> + };
>> + ...
>> +};
Regards,
Anup
^ permalink raw reply
* [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support
From: Maxime Ripard @ 2016-12-01 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2039137.LtCOH6bs2I@avalon>
Hi Laurent,
On Wed, Nov 30, 2016 at 12:12:55PM +0200, Laurent Pinchart wrote:
> > More, it is not sure that the bridge/DW code would work with Allwinner's
> > SoCs.
>
> If it doesn't work and can't be made to work in a non-invasive way they it
> should certainly not be used :-)
Even if the register layout is completely scrambled, as long as the
bits themselves aren't (and by comparing the two drivers it looks like
they haven't changed), you can easily deal with that using the
regmap_fields, with the two implementations (the original one and the
scrambled one) providing their register map that way, and the driver
code using whatever has been provided.
> > Eventually, I went the same way as omap/hdmi5: different driver.
>
> I might try to fix that for OMAP5 at some point, we'll see.
For complex drivers that have already a driver written and a lot of
testing that already happened, I don't think duplication is a smart
move.
> > > - And finally the fact that we can't have several display engine in
> > > parallel, if needs be. This has happened in the past already on
> > > Allwinner SoCs, so it's definitely something we should consider in
> > > the DT bindings, since we can't break them.
> >
> > IIRC, I proposed my driver before yours, and the DE2 is completely
> > different from the other display engines.
> > What you are telling is "add more code to already complex code and have
> > a big driver for all SoCs in each kernels".
> > I think it should be better to have small modules, each one treating
> > specific hardware, and to let only the needed code in the kernel memory
> > at startup time.
> >
> > > Until those are fixed, I cannot see how this driver can be merged,
> > > unfortunately.
> >
> > No problem. I just wanted to help people by giving the job I did on the
> > boards I have. My boards are working for almost one year, fine enough
> > for I use them as daily desktop computers. I don't want to spend one
> > more year for having my code in the Linux kernel: there are so much
> > other exciting things to do...
>
> And you're certainly welcome to contribute drivers to the kernel, that's
> always appreciated. Of course, to ensure a reasonable level of quality and
> consistency between drivers, the review process often requires changes to be
> made to the code being submitted. When it comes to drivers I mostly pay
> attention to DT bindings, userspace APIs and modification to common code.
> Driver code itself, as long as it's reasonably clean and doesn't impede
> development of other drivers or impact system security in an adverse way, is
> still important but maybe slightly less so. I'll defer to Maxime to come to an
> agreement on the multiple display engines in parallel problem as I'm not
> familiar with it for the Allwinner platforms.
The earlier Allwinner SoCs (with the old display engine), we had some
SoCs with multiple instances of the display engine and TCON (the
display engine roughly implementing the planes, the TCON the
CRTC. Roughly.). However, those were sharing some encoders (HDMI,
DSI) after that.
So we need to have a single DRM device taking care of the multiple
display engines, which essentialy means that we have to decouple the
DRM device from the display engine. This was done in the earlier
designs using an additional node with a list of phandles to the
display engines in the system, and obviously, I'd prefer to have some
consistency and reuse the same thing.
But the current approach doesn't work and will require some DT
modifications if that case happens again, which we can't do because of
the DT ABI.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20161201/edd95cf1/attachment.sig>
^ permalink raw reply
* Unable to use perf in VM
From: Marc Zyngier @ 2016-12-01 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56fd35f8-76ba-3d5d-f1e0-7df5ff8d396a@redhat.com>
On 30/11/16 19:17, Wei Huang wrote:
>
>
> On 11/30/2016 07:37 AM, Marc Zyngier wrote:
>> On 30/11/16 11:48, Marc Zyngier wrote:
>>> + Shannon
>>>
>>> On 29/11/16 22:04, Itaru Kitayama wrote:
>>>> Hi,
>>>>
>>>> In a VM (virsh controlled, KVM acceleration enabled) on a recent
>>>> kvmarm kernel host, I find I am unable to use perf to obtain
>>>> performance statistics for a complex task like kernel build.
>>>> (I've verified this is seen with a Fedora 25 VM and host combination
>>>> as well)
>>>> APM folks CC'ed think this might be caused by a bug in the core PMU
>>>> framework code, thus I'd like to have experts opinion on this issue.
>>>>
>>>> [root at localhost linux]# perf stat -B make
>>>> CHK include/config/kernel.release
>>>> [ 119.617684] git[1144]: undefined instruction: pc=fffffc000808ff30
>>>> [ 119.623040] Code: 51000442 92401042 d51b9ca2 d5033fdf (d53b9d40)
>>>> [ 119.627607] Internal error: undefined instruction: 0 [#1] SMP
>>>
>>> [...]
>>>
>>> In a VM running mainline hosted on an AMD Seattle box:
>>>
>>> Performance counter stats for 'make':
>>>
>>> 1526089.499304 task-clock:u (msec) # 0.932 CPUs utilized
>>> 0 context-switches:u # 0.000 K/sec
>>> 0 cpu-migrations:u # 0.000 K/sec
>>> 29527793 page-faults:u # 0.019 M/sec
>>> 2913174122673 cycles:u # 1.909 GHz
>>> 2365040892322 instructions:u # 0.81 insn per cycle
>>> <not supported> branches:u
>>> 32049215378 branch-misses:u # 0.00% of all branches
>>>
>>> 1637.531444837 seconds time elapsed
>>>
>>> Running the same host kernel on a Mustang system, the guest explodes
>>> in the way you reported. The failing instruction always seems to be
>>> an access to pmxevcntr_el0 (I've seen both reads and writes).
>>>
>>> Funnily enough, it dies if you try any HW event other than cycles
>>> ("perf stat -e cycles ls" works, and "perf stat -e instructions ls"
>>> explodes). Which would tend to indicate that we're screwing up
>>> the counter selection, but I have no proof of that (specially that
>>> the Seattle guest is working just as expected).
>>
>> It turns out that we *don't* inject an undef. It seems to be generated
>> locally at EL1.
>>
>> Still digging.
>
> Just FYI: I saw it on Mustang before. My initial thought was HW related,
> but without proof. I am interested to see your findings...
It would have been good to report it earlier. Anyway, I've identified
the root issue, which seems to boil down to how you interpret a small
corner of the PMU architecture. I've raised it with the architecture
team here, and I should have a workaround/fix shortly.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support
From: Laurent Pinchart @ 2016-12-01 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201091313.th7nucjmvtuolqza@lukather>
Hi Maxime,
On Thursday 01 Dec 2016 10:13:13 Maxime Ripard wrote:
> On Wed, Nov 30, 2016 at 12:12:55PM +0200, Laurent Pinchart wrote:
> >> More, it is not sure that the bridge/DW code would work with Allwinner's
> >> SoCs.
> >
> > If it doesn't work and can't be made to work in a non-invasive way they it
> > should certainly not be used :-)
>
> Even if the register layout is completely scrambled, as long as the
> bits themselves aren't (and by comparing the two drivers it looks like
> they haven't changed), you can easily deal with that using the
> regmap_fields, with the two implementations (the original one and the
> scrambled one) providing their register map that way, and the driver
> code using whatever has been provided.
Looking at https://linux-sunxi.org/DWC_HDMI_Controller#DWC_HDMI_Controller it
seems that an address remapping function could be used.
> >> Eventually, I went the same way as omap/hdmi5: different driver.
> >
> > I might try to fix that for OMAP5 at some point, we'll see.
>
> For complex drivers that have already a driver written and a lot of
> testing that already happened, I don't think duplication is a smart
> move.
>
> >>> - And finally the fact that we can't have several display engine in
> >>> parallel, if needs be. This has happened in the past already on
> >>> Allwinner SoCs, so it's definitely something we should consider in
> >>> the DT bindings, since we can't break them.
> >>
> >> IIRC, I proposed my driver before yours, and the DE2 is completely
> >> different from the other display engines.
> >> What you are telling is "add more code to already complex code and have
> >> a big driver for all SoCs in each kernels".
> >> I think it should be better to have small modules, each one treating
> >> specific hardware, and to let only the needed code in the kernel memory
> >> at startup time.
> >>
> >>> Until those are fixed, I cannot see how this driver can be merged,
> >>> unfortunately.
> >>
> >> No problem. I just wanted to help people by giving the job I did on the
> >> boards I have. My boards are working for almost one year, fine enough
> >> for I use them as daily desktop computers. I don't want to spend one
> >> more year for having my code in the Linux kernel: there are so much
> >> other exciting things to do...
> >
> > And you're certainly welcome to contribute drivers to the kernel, that's
> > always appreciated. Of course, to ensure a reasonable level of quality and
> > consistency between drivers, the review process often requires changes to
> > be made to the code being submitted. When it comes to drivers I mostly
> > pay attention to DT bindings, userspace APIs and modification to common
> > code. Driver code itself, as long as it's reasonably clean and doesn't
> > impede development of other drivers or impact system security in an
> > adverse way, is still important but maybe slightly less so. I'll defer to
> > Maxime to come to an agreement on the multiple display engines in
> > parallel problem as I'm not familiar with it for the Allwinner platforms.
>
> The earlier Allwinner SoCs (with the old display engine), we had some
> SoCs with multiple instances of the display engine and TCON (the
> display engine roughly implementing the planes, the TCON the
> CRTC. Roughly.). However, those were sharing some encoders (HDMI,
> DSI) after that.
>
> So we need to have a single DRM device taking care of the multiple
> display engines, which essentialy means that we have to decouple the
> DRM device from the display engine. This was done in the earlier
> designs using an additional node with a list of phandles to the
> display engines in the system, and obviously, I'd prefer to have some
> consistency and reuse the same thing.
>
> But the current approach doesn't work and will require some DT
> modifications if that case happens again, which we can't do because of
> the DT ABI.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Florian Weimer @ 2016-12-01 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130135631.GK1574@e103592.cambridge.arm.com>
On 11/30/2016 02:56 PM, Dave Martin wrote:
> If we do have distinct "set process VL" and "set thread VL" interfaces,
> then my view is that the former should fail if there are already
> multiple threads, rather than just setting the VL of a single thread or
> (worse) asynchronously changing the VL of threads other than the
> caller...
Yes, looks feasible to me.
>>> I'm not familiar with resumable functions/executors -- are these in
>>> the C++ standards yet (not that that would cause me to be familiar
>>> with them... ;) Any implementation of coroutines (i.e.,
>>> cooperative switching) is likely to fall under the "setcontext"
>>> argument above.
>>
>> There are different ways to implement coroutines. Stack switching (like
>> setcontext) is obviously impacted by non-uniform register sizes. But even
>> the most conservative variant, rather similar to switch-based emulation you
>> sometimes see in C coroutine implementations, might have trouble restoring
>> the state if it just cannot restore the saved state due to register size
>> reductions.
>
> Which is not a problem if the variably-sized state is not part of the
> switched context?
The VL value is implicitly thread-local data, and the encoded state may
have an implicit dependency on it, although it does not contain vector
registers as such.
> Because the SVE procedure call standard determines that the SVE
> registers are caller-save,
By the way, how is this implemented? Some of them overlap existing
callee-saved registers.
> they are not live at any external function
> boundary -- so in cooperative switching it is useless to save/restore
> this state unless the coroutine framework is defined to have a special
> procedure call standard.
It can use the standard calling convention, but it may have selected a
particular implementation based on the VL value before suspension.
Florian
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Maxime Ripard @ 2016-12-01 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125220752.c989c85e01ed202be0485c78@bidouilliste.com>
Hi Emmanuel,
On Fri, Nov 25, 2016 at 10:07:52PM +0100, Emmanuel Vadot wrote:
> On Fri, 25 Nov 2016 16:20:47 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > On Thu, Nov 24, 2016 at 09:05:09PM +0100, Emmanuel Vadot wrote:
> > > On Thu, 24 Nov 2016 20:55:17 +0100
> > > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> > >
> > > > On Tue, Nov 22, 2016 at 06:06:16PM +0100, Emmanuel Vadot wrote:
> > > > > The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
> > > > > others three only have 1.
> > > > > Add the num-cs property to each node.
> > > > >
> > > > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > > >
> > > > I don't think we have any code that uses it at the moment. What is the
> > > > rationale behind this patch?
> > > >
> > > > Thanks!
> > > > Maxime
> > > >
> > > > --
> > > > Maxime Ripard, Free Electrons
> > > > Embedded Linux and Kernel engineering
> > > > http://free-electrons.com
> > >
> > > Hi Maxime,
> > >
> > > If num-cs isn't present nothing prevent to start a transfer with a
> > > non-valid CS pin, resulting in an error.
> > > num-cs are default property especially made for this and a SPI driver
> > > should try to get the property at probe/attach time.
> >
> > Yes, but as far as I know, our driver doesn't. I'm all in for having
> > support for that in our driver, but without it, that patch is kind of
> > useless.
>
> Yes the Linux driver doesn't use it but my upcoming one for FreeBSD
> uses it. So it is not useless for downstream user of DTS.
Ah, I didn't know this was for FreeBSD. So you started to use our DTs,
or do you have some modifications to it? How does that work?
Anyway, the fact that it isn't used by our driver at the moment and
that it's meant for other OSes should be mentionned in the commit log.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20161201/b66af5d5/attachment-0001.sig>
^ permalink raw reply
* [PULL] KVM/ARM updates for 4.9-rc7
From: Marc Zyngier @ 2016-12-01 9:25 UTC (permalink / raw)
To: linux-arm-kernel
Paolo, Radim,
Hopefully, this is the last update for 4.9. This time, a single patch
that prevents bogus acknoledgement of interrupts.
It'd be great if this could make it into v4.9-final
Thanks,
M.
The following changes since commit b112c84a6ff035271d41d548c10215f18443d6a6:
KVM: arm64: Fix the issues when guest PMCCFILTR is configured (2016-11-18 09:06:58 +0000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-for-4.9-rc7
for you to fetch changes up to 8ca18eec2b2276b449c1dc86b98bf083c5fe4e09:
KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs (2016-11-24 13:12:07 +0000)
----------------------------------------------------------------
KVM/ARM updates for v4.9-rc7
- Do not call kvm_notify_acked for PPIs
----------------------------------------------------------------
Marc Zyngier (1):
KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
virt/kvm/arm/vgic/vgic-v2.c | 6 ++++--
virt/kvm/arm/vgic/vgic-v3.c | 6 ++++--
2 files changed, 8 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
From: Marc Zyngier @ 2016-12-01 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480584341-32340-1-git-send-email-marc.zyngier@arm.com>
When we inject a level triggerered interrupt (and unless it
is backed by the physical distributor - timer style), we request
a maintenance interrupt. Part of the processing for that interrupt
is to feed to the rest of KVM (and to the eventfd subsystem) the
information that the interrupt has been EOIed.
But that notification only makes sense for SPIs, and not PPIs
(such as the PMU interrupt). Skip over the notification if
the interrupt is not an SPI.
Cc: stable at vger.kernel.org # 4.7+
Fixes: 140b086dd197 ("KVM: arm/arm64: vgic-new: Add GICv2 world switch backend")
Fixes: 59529f69f504 ("KVM: arm/arm64: vgic-new: Add GICv3 world switch backend")
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic-v2.c | 6 ++++--
virt/kvm/arm/vgic/vgic-v3.c | 6 ++++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
index 0a063af..9bab867 100644
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@ -50,8 +50,10 @@ void vgic_v2_process_maintenance(struct kvm_vcpu *vcpu)
WARN_ON(cpuif->vgic_lr[lr] & GICH_LR_STATE);
- kvm_notify_acked_irq(vcpu->kvm, 0,
- intid - VGIC_NR_PRIVATE_IRQS);
+ /* Only SPIs require notification */
+ if (vgic_valid_spi(vcpu->kvm, intid))
+ kvm_notify_acked_irq(vcpu->kvm, 0,
+ intid - VGIC_NR_PRIVATE_IRQS);
}
}
diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index 9f0dae3..5c9f974 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -41,8 +41,10 @@ void vgic_v3_process_maintenance(struct kvm_vcpu *vcpu)
WARN_ON(cpuif->vgic_lr[lr] & ICH_LR_STATE);
- kvm_notify_acked_irq(vcpu->kvm, 0,
- intid - VGIC_NR_PRIVATE_IRQS);
+ /* Only SPIs require notification */
+ if (vgic_valid_spi(vcpu->kvm, intid))
+ kvm_notify_acked_irq(vcpu->kvm, 0,
+ intid - VGIC_NR_PRIVATE_IRQS);
}
/*
--
2.1.4
^ permalink raw reply related
* How should we group related devices in DT ? (was Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support)
From: Laurent Pinchart @ 2016-12-01 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201091313.th7nucjmvtuolqza@lukather>
Hello,
On Thursday 01 Dec 2016 10:13:13 Maxime Ripard wrote:
[snip]
> The earlier Allwinner SoCs (with the old display engine), we had some
> SoCs with multiple instances of the display engine and TCON (the
> display engine roughly implementing the planes, the TCON the
> CRTC. Roughly.). However, those were sharing some encoders (HDMI,
> DSI) after that.
>
> So we need to have a single DRM device taking care of the multiple
> display engines, which essentialy means that we have to decouple the
> DRM device from the display engine. This was done in the earlier
> designs using an additional node with a list of phandles to the
> display engines in the system, and obviously, I'd prefer to have some
> consistency and reuse the same thing.
I believe this problem isn't limited to sunxi and should be addressed in a
more generic way. How should we describe in the device tree that multiple
instances of a device unrelated from a control point of view are related at
the hardware level ? There are multiple reasons why we need this, and here are
a few.
- As described above, unrelated display controller instances that share
encoders at their output need to be exposed to userspace as a single DRM
device. This is also the case on Renesas platforms (where the display engines
are independent except for the "small" detail that output routing is
controlled through the first display engine).
- On Renesas platforms again a radio-related SPI receiver has multiple
independent channels that each have their own registers, clocks and
interrupts, but share the same physical clock and sync pins. They are used to
receive multiple channels of the same data stream and must be exposed as a
single V4L2 device to userspace. A generic DT binding RFC is available at
http://www.spinics.net/lists/devicetree/msg152414.html.
> But the current approach doesn't work and will require some DT
> modifications if that case happens again, which we can't do because of
> the DT ABI.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-12-01 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cdfd3c65-d473-badb-ea6a-035f7ab79217@arm.com>
On Mon, Nov 28, 2016 at 12:29:07AM +0000, Andr? Przywara wrote:
> > Something more interesting happened.
> >
> > Xunlong made a add-on board for Orange Pi Zero, which exposes the
> > two USB Controllers exported at expansion bus as USB Type-A
> > connectors.
> >
> > Also it exposes a analog A/V jack and a microphone.
> >
> > Should I enable {e,o}hci{2.3} in the device tree?
>
> Actually we should do this regardless of this extension board. The USB
> pins are not multiplexed and are exposed on user accessible pins (just
> not soldered, but that's a detail), so I think they qualify for DT
> enablement. And even if a user can't use them, it doesn't hurt to have
> them (since they are not multiplexed).
My main concern about this is that we'll leave regulators enabled by
default, for a minority of users. And that minority will prevent to do
a proper power management when the times come since we'll have to keep
that behaviour forever.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20161201/6200cc6b/attachment.sig>
^ permalink raw reply
* [PATCH v3 2/3] powerpc/reloc64: add support for 32-bit CRC pseudo-symbols
From: Michael Ellerman @ 2016-12-01 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8g=qgOg0Q5J7tFu0uBUFTUXdVQ+84N45oZseG3vTm0Bg@mail.gmail.com>
Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> On 25 November 2016 at 11:29, Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>>
>> [ 7.607687] kvm: disagrees about version of symbol module_layout
>> [ 7.846799] virtio: disagrees about version of symbol module_layout
>> [ 22.012615] crc32c_vpmsum: disagrees about version of symbol module_layout
>> [ 22.012959] libcrc32c: disagrees about version of symbol module_layout
>>
>
> Sigh. I suppose your modversions fixes are queued for v4.10? It's
> probably best to revisit this after the v4.10 merge window closes
> then, just to make sure I'm not aiming for a moving target.
Actually they were merged into 4.9-rc7 ish.
But I'm still seeing the same as above with this series rebased on top
of that, and I'm a bit short on time to debug it ATM.
So during the 4.10 cycle is probably the best we can hope for, sorry.
cheers
^ permalink raw reply
* [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support
From: Maxime Ripard @ 2016-12-01 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2084988.kISO4Quil7@avalon>
On Thu, Dec 01, 2016 at 11:19:56AM +0200, Laurent Pinchart wrote:
> Hi Maxime,
>
> On Thursday 01 Dec 2016 10:13:13 Maxime Ripard wrote:
> > On Wed, Nov 30, 2016 at 12:12:55PM +0200, Laurent Pinchart wrote:
> > >> More, it is not sure that the bridge/DW code would work with Allwinner's
> > >> SoCs.
> > >
> > > If it doesn't work and can't be made to work in a non-invasive way they it
> > > should certainly not be used :-)
> >
> > Even if the register layout is completely scrambled, as long as the
> > bits themselves aren't (and by comparing the two drivers it looks like
> > they haven't changed), you can easily deal with that using the
> > regmap_fields, with the two implementations (the original one and the
> > scrambled one) providing their register map that way, and the driver
> > code using whatever has been provided.
>
> Looking at https://linux-sunxi.org/DWC_HDMI_Controller#DWC_HDMI_Controller it
> seems that an address remapping function could be used.
Even better.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20161201/79cf80f8/attachment.sig>
^ permalink raw reply
* [PATCH v3 2/3] powerpc/reloc64: add support for 32-bit CRC pseudo-symbols
From: Ard Biesheuvel @ 2016-12-01 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874m2ooumq.fsf@concordia.ellerman.id.au>
On 1 December 2016 at 09:39, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>> On 25 November 2016 at 11:29, Michael Ellerman <mpe@ellerman.id.au> wrote:
>>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>>>
>>> [ 7.607687] kvm: disagrees about version of symbol module_layout
>>> [ 7.846799] virtio: disagrees about version of symbol module_layout
>>> [ 22.012615] crc32c_vpmsum: disagrees about version of symbol module_layout
>>> [ 22.012959] libcrc32c: disagrees about version of symbol module_layout
>>>
>>
>> Sigh. I suppose your modversions fixes are queued for v4.10? It's
>> probably best to revisit this after the v4.10 merge window closes
>> then, just to make sure I'm not aiming for a moving target.
>
> Actually they were merged into 4.9-rc7 ish.
>
> But I'm still seeing the same as above with this series rebased on top
> of that, and I'm a bit short on time to debug it ATM.
>
> So during the 4.10 cycle is probably the best we can hope for, sorry.
>
Not a problem. The only question is whether 1/3 of this series fixes
an actual bug or not, given that the CONFIG_RELOCATABLE workaround has
been made ppc64 only.
But for the remaining patches, I'm happy to respin after the v4.10
merge window closes, and get something queued for v4.11
--
Ard.
^ permalink raw reply
* [PATCH 1/4] mmc: mediatek: Fix CMD6 timeout issue
From: Ulf Hansson @ 2016-12-01 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478585341-6749-2-git-send-email-yong.mao@mediatek.com>
On 8 November 2016 at 07:08, Yong Mao <yong.mao@mediatek.com> wrote:
> From: yong mao <yong.mao@mediatek.com>
>
> When initializing EMMC, after switch to HS400,
> it will issue CMD6 to change ext_csd, if first CMD6 got CRC
> error, the repeat CMD6 may get timeout, that's
> because SDCBSY was cleared by msdc_reset_hw()
Sorry for the delay!
We have recently been re-working the sequence for how to deal more
properly with CMD6 in the mmc core.
The changes done so far should mostly concern switches to HS and HS
DDR, but I think you should run a re-test to make sure you still hit
the same problems.
>
> Signed-off-by: Yong Mao <yong.mao@mediatek.com>
> Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
> ---
> drivers/mmc/host/mtk-sd.c | 77 ++++++++++++++++++++++++++++++---------------
> 1 file changed, 51 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> index 84e9afc..b29683b 100644
> --- a/drivers/mmc/host/mtk-sd.c
> +++ b/drivers/mmc/host/mtk-sd.c
> @@ -826,6 +826,15 @@ static bool msdc_cmd_done(struct msdc_host *host, int events,
> return true;
> }
>
> +static int msdc_card_busy(struct mmc_host *mmc)
> +{
> + struct msdc_host *host = mmc_priv(mmc);
> + u32 status = readl(host->base + MSDC_PS);
> +
> + /* check if data0 is low */
> + return !(status & BIT(16));
> +}
> +
> /* It is the core layer's responsibility to ensure card status
> * is correct before issue a request. but host design do below
> * checks recommended.
Hmm. Why?
I think you should rely on the mmc core to invoke the ->card_busy()
ops instead. The core knows better when it's needed.
Perhaps that may also resolve some of these issues for you!?
> @@ -835,10 +844,20 @@ static inline bool msdc_cmd_is_ready(struct msdc_host *host,
> {
> /* The max busy time we can endure is 20ms */
> unsigned long tmo = jiffies + msecs_to_jiffies(20);
> + u32 count = 0;
> +
> + if (in_interrupt()) {
> + while ((readl(host->base + SDC_STS) & SDC_STS_CMDBUSY) &&
> + (count < 1000)) {
> + udelay(1);
> + count++;
This seems like a bad idea, "busy-wait" in irq context is never a good idea.
> + }
> + } else {
> + while ((readl(host->base + SDC_STS) & SDC_STS_CMDBUSY) &&
> + time_before(jiffies, tmo))
> + cpu_relax();
> + }
>
> - while ((readl(host->base + SDC_STS) & SDC_STS_CMDBUSY) &&
> - time_before(jiffies, tmo))
> - cpu_relax();
> if (readl(host->base + SDC_STS) & SDC_STS_CMDBUSY) {
> dev_err(host->dev, "CMD bus busy detected\n");
> host->error |= REQ_CMD_BUSY;
> @@ -846,17 +865,35 @@ static inline bool msdc_cmd_is_ready(struct msdc_host *host,
> return false;
> }
>
> - if (mmc_resp_type(cmd) == MMC_RSP_R1B || cmd->data) {
> - tmo = jiffies + msecs_to_jiffies(20);
> - /* R1B or with data, should check SDCBUSY */
> - while ((readl(host->base + SDC_STS) & SDC_STS_SDCBUSY) &&
> - time_before(jiffies, tmo))
> - cpu_relax();
> - if (readl(host->base + SDC_STS) & SDC_STS_SDCBUSY) {
> - dev_err(host->dev, "Controller busy detected\n");
> - host->error |= REQ_CMD_BUSY;
> - msdc_cmd_done(host, MSDC_INT_CMDTMO, mrq, cmd);
> - return false;
> + if (cmd->opcode != MMC_SEND_STATUS) {
> + count = 0;
> + /* Consider that CMD6 crc error before card was init done,
> + * mmc_retune() will return directly as host->card is null.
> + * and CMD6 will retry 3 times, must ensure card is in transfer
> + * state when retry.
> + */
> + tmo = jiffies + msecs_to_jiffies(60 * 1000);
> + while (1) {
> + if (msdc_card_busy(host->mmc)) {
> + if (in_interrupt()) {
> + udelay(1);
> + count++;
> + } else {
> + msleep_interruptible(10);
> + }
> + } else {
> + break;
> + }
> + /* Timeout if the device never
> + * leaves the program state.
> + */
> + if (count > 1000 || time_after(jiffies, tmo)) {
> + pr_err("%s: Card stuck in programming state! %s\n",
> + mmc_hostname(host->mmc), __func__);
> + host->error |= REQ_CMD_BUSY;
> + msdc_cmd_done(host, MSDC_INT_CMDTMO, mrq, cmd);
> + return false;
> + }
This hole new code is a hack, that shouldn't be needed in the host driver.
I think we need to investigate and fix the issue in the mmc core
layer, to make this work for your host driver. That instead of doing a
work around in the host.
> }
> }
> return true;
> @@ -1070,18 +1107,6 @@ static int msdc_ops_switch_volt(struct mmc_host *mmc, struct mmc_ios *ios)
> return ret;
> }
>
> -static int msdc_card_busy(struct mmc_host *mmc)
> -{
> - struct msdc_host *host = mmc_priv(mmc);
> - u32 status = readl(host->base + MSDC_PS);
> -
> - /* check if any pin between dat[0:3] is low */
> - if (((status >> 16) & 0xf) != 0xf)
> - return 1;
> -
> - return 0;
> -}
> -
> static void msdc_request_timeout(struct work_struct *work)
> {
> struct msdc_host *host = container_of(work, struct msdc_host,
> --
> 1.7.9.5
>
Kind regards
Uffe
^ permalink raw reply
* [PATCH] arm64: dts: juno: Correct PCI IO window
From: Sudeep Holla @ 2016-12-01 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7823573.FNB8ayVOnQ@wuerfel>
On 30/11/16 22:51, Arnd Bergmann wrote:
> On Wednesday, November 30, 2016 4:29:35 PM CET Sudeep Holla wrote:
>> 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.
>
> I ended up taking the other one for v4.10, but this one seems more
> important so I applied it for v4.9.
>
> Let me know if you disagree with the priorities, as I plan to send out
> the last 4.9 fixes pull request to Linus tomorrow.
>
No that's fine.
--
Regards,
Sudeep
^ permalink raw reply
* No subject
From: Ramana Radhakrishnan @ 2016-12-01 10:00 UTC (permalink / raw)
To: linux-arm-kernel
>
> By the way, how is this implemented? Some of them overlap existing
> callee-saved registers.
The AArch64 PCS requires that only the bottom 64 bits of SIMD
registers (v8-v15) are callee-saved. The top 64 bits of the current
Advanced SIMD registers are the responsibility of the caller. This
naturally extends to SVE.
Ramana
^ 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