* [PATCH 6/8] ARM: dts: r8a7794: Add PMU device node
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A7
CPU cores on R-Car E2 by adding a device node for the PMU.
New Linux output:
hw perfevents: enabled with armv7_cortex_a7 PMU driver, 5 counters available
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7794.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 76aadcdf9d37b39c..736196903d22f0e0 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -103,6 +103,13 @@
clock-frequency = <0>;
};
+ pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts-extended = <&gic GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
+ };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 5/8] ARM: dts: r8a7793: Add PMU device node
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A15
CPU cores on R-Car M2-N by adding a device node for the PMU.
New Linux output:
hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7793.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 2fa052200495caef..4abecfc0ca98c483 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -110,6 +110,13 @@
clock-frequency = <0>;
};
+ pmu {
+ compatible = "arm,cortex-a15-pmu";
+ interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
+ };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 4/8] ARM: dts: r8a7792: Add PMU device node
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A15
CPU cores on R-Car V2H by adding a device node for the PMU.
New Linux output:
hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7792.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index d2cf8dd2d9b03624..f44257dd86f66289 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -85,6 +85,13 @@
clock-frequency = <0>;
};
+ pmu {
+ compatible = "arm,cortex-a15-pmu";
+ interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
+ };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 3/8] ARM: dts: r8a7791: Add PMU device node
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A15
CPU cores on R-Car M2-W by adding a device node for the PMU.
New Linux output:
hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7791.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 58f694eb411b0e3d..6e1dd7ad7bd647e7 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -126,6 +126,13 @@
clock-frequency = <0>;
};
+ pmu {
+ compatible = "arm,cortex-a15-pmu";
+ interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
+ };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 2/8] ARM: dts: r8a7790: Add PMU device nodes
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A15
and Cortex-A7 CPU cores on R-Car H2 by adding device nodes for the two
PMUs.
New Linux output:
hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
hw perfevents: /pmu-1: failed to probe PMU!
hw perfevents: /pmu-1: failed to register PMU devices!
The last two lines are due to the Cortex-A7 CPU cores being described in
DT, but not enabled by the firmware.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7790.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 47a51cd71434e7d2..4d06b154bd7ebd9e 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -202,6 +202,24 @@
clock-frequency = <0>;
};
+ pmu-0 {
+ compatible = "arm,cortex-a15-pmu";
+ interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+ };
+
+ pmu-1 {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts-extended = <&gic GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
+ };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 1/8] ARM: dts: r7s72100: Add PMU device node
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A9
CPU core on RZ/A1H by adding a device node for the PMU.
New Linux output:
hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r7s72100.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index eb2e6f95a2e85862..a54822e97bac42ed 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -77,6 +77,11 @@
clock-div = <6>;
};
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupts-extended = <&gic GIC_PPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
rtc_x1_clk: rtc_x1 {
#clock-cells = <0>;
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 0/8] ARM: dts: renesas: Add PMU device nodes
From: Geert Uytterhoeven @ 2018-05-07 13:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon, Magnus,
This patch series enables support for the ARM Performance Monitor Units
in Cortex-A7, Cortex-A9, and Cortex-A15 CPU cores on Renesas RZ/A1,
R-Car Gen2, and RZ/G1 SoCs. This allows for better performance analysis
using the "perf" tool.
Sample output of "perf stat echo" on r8a7791/koelsch:
- Before:
Performance counter stats for 'echo':
2,636300 task-clock (msec) # 0,265 CPUs utilized
8 context-switches # 0,003 M/sec
0 cpu-migrations # 0,000 K/sec
43 page-faults # 0,016 M/sec
<not supported> cycles
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
<not supported> instructions
<not supported> branches
<not supported> branch-misses
0,009960300 seconds time elapsed
- After:
Performance counter stats for 'echo':
2,455400 task-clock (msec) # 0,273 CPUs utilized
3 context-switches # 0,001 M/sec
0 cpu-migrations # 0,000 K/sec
45 page-faults # 0,018 M/sec
3.556.784 cycles # 1,449 GHz
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
1.350.480 instructions # 0,38 insns per cycle
335.542 branches # 136,655 M/sec
18.075 branch-misses # 5,39% of all branches
0,008987900 seconds time elapsed
Still missing:
- R-Mobile APE6 (no PMU interrupt documented),
- R-Car M1A and H1 (the PMU interrupt seems to be routed to the legacy
SH INTC only?),
- RZ/G1C (SMP support not yet upstream).
This has been tested on r8a7791/koelsch, and boot-tested on
r7s72100/genmai, r8a7790/lager, r8a7792/blanche, and r8a7794/silk.
Thanks!
Geert Uytterhoeven (8):
ARM: dts: r7s72100: Add PMU device node
ARM: dts: r8a7790: Add PMU device nodes
ARM: dts: r8a7791: Add PMU device node
ARM: dts: r8a7792: Add PMU device node
ARM: dts: r8a7793: Add PMU device node
ARM: dts: r8a7794: Add PMU device node
ARM: dts: r8a7743: Add PMU device node
ARM: dts: r8a7745: Add PMU device node
arch/arm/boot/dts/r7s72100.dtsi | 5 +++++
arch/arm/boot/dts/r8a7743.dtsi | 7 +++++++
arch/arm/boot/dts/r8a7745.dtsi | 7 +++++++
arch/arm/boot/dts/r8a7790.dtsi | 18 ++++++++++++++++++
arch/arm/boot/dts/r8a7791.dtsi | 7 +++++++
arch/arm/boot/dts/r8a7792.dtsi | 7 +++++++
arch/arm/boot/dts/r8a7793.dtsi | 7 +++++++
arch/arm/boot/dts/r8a7794.dtsi | 7 +++++++
8 files changed, 65 insertions(+)
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 00/26] device link, bridge supplier <-> drm device
From: Daniel Vetter @ 2018-05-07 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504135212.26977-1-peda@axentia.se>
On Fri, May 04, 2018 at 03:51:46PM +0200, Peter Rosin wrote:
> Hi!
>
> It was noted by Russel King [1] that bridges (not using components)
> might disappear unexpectedly if the owner of the bridge was unbound.
> Jyri Sarha had previously noted the same thing with panels [2]. Jyri
> came up with using device links to resolve the panel issue, which
> was also my (independent) reaction to the note from Russel.
>
> This series builds up to the addition of that link in the last
> patch, but in my opinion the other 25 patches do have merit on their
> own.
>
> The last patch needs testing, while the others look trivial. Jyri, are
> you able to test? That said, I might have missed some subtlety.
>
> Oh and the reason I'm pushing this is of course so that the issue
> noted by Russel in [1] is addressed which in turn means that the
> tda998x bridge driver can be patched according to that series without
> objection (hopefully) and then used from the atmel-hlcdc driver (and
> other drivers that are not componentized).
>
> Changes since v1 https://lkml.org/lkml/2018/4/26/1018
>
> - rename .owner to .odev to not get mixed up with the module owner.
> - added patches for new recent drivers thc63lvd1024 and cdns-dsi
> - fix for problem in the rockchip_lvds driver reported by 0day
> - added a WARN in drm_bridge_add if there is no .odev owner device
>
> I did *not*:
> - add any ack from Daniel since he suggested "pdev", and I ended up
> with "odev" in the rename since I disliked "pdev" about as much
> as "owner".
As long as it's not owner, I'm fine :-) Ack on the idea still holds.
> - add any port id. The current .of_node (that this series removes)
> does not identify the port, so that problem seems orthogonal
> to me.
Hm, from my cursory DT/of code reading last week I thought the port is
used to lookup the right node, but there's no port thing on the target for
a phandle? At least that's how current drm_of_find_panel_or_bridge seems
to work ...
-Daniel
>
> Cheers,
> Peter
>
> [1] https://lkml.org/lkml/2018/4/23/769
> [2] https://www.spinics.net/lists/dri-devel/msg174275.html
>
> Peter Rosin (26):
> drm/bridge: allow optionally specifying an owner .odev device
> drm/bridge: adv7511: provide an owner .odev device
> drm/bridge/analogix: core: specify the owner .odev of the bridge
> drm/bridge: analogix-anx78xx: provide an owner .odev device
> drm/bridge: cdns-dsi: provide an owner .odev device
> drm/bridge: vga-dac: provide an owner .odev device
> drm/bridge: lvds-encoder: provide an owner .odev device
> drm/bridge: megachips-stdpxxxx-ge-b850v3-fw: provide an owner .odev
> device
> drm/bridge: nxp-ptn3460: provide an owner .odev device
> drm/bridge: panel: provide an owner .odev device
> drm/bridge: ps8622: provide an owner .odev device
> drm/bridge: sii902x: provide an owner .odev device
> drm/bridge: sii9234: provide an owner .odev device
> drm/bridge: sii8620: provide an owner .odev device
> drm/bridge: synopsys: provide an owner .odev device for the bridges
> drm/bridge: tc358767: provide an owner .odev device
> drm/bridge: thc63lvd1024: provide an owner .odev device
> drm/bridge: ti-tfp410: provide an owner .odev device
> drm/exynos: mic: provide an owner .odev device for the bridge
> drm/mediatek: hdmi: provide an owner .odev device for the bridge
> drm/msm: specify the owner .odev of the bridges
> drm/rcar-du: lvds: provide an owner .odev device for the bridge
> drm/sti: provide an owner .odev device for the bridges
> drm/bridge: remove the .of_node member
> drm/bridge: require the owner .odev to be filled in on
> drm_bridge_add/attach
> drm/bridge: establish a link between the bridge supplier and consumer
>
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 +----
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
> drivers/gpu/drm/bridge/cdns-dsi.c | 2 +-
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +-
> drivers/gpu/drm/bridge/lvds-encoder.c | 2 +-
> .../drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c | 2 +-
> drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
> drivers/gpu/drm/bridge/panel.c | 4 +---
> drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/bridge/sii9234.c | 2 +-
> drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +---
> drivers/gpu/drm/bridge/tc358767.c | 2 +-
> drivers/gpu/drm/bridge/thc63lvd1024.c | 2 +-
> drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
> drivers/gpu/drm/drm_bridge.c | 26 +++++++++++++++++++++-
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> drivers/gpu/drm/msm/dsi/dsi_manager.c | 1 +
> drivers/gpu/drm/msm/edp/edp_bridge.c | 1 +
> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 +
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +-
> drivers/gpu/drm/sti/sti_dvo.c | 2 +-
> drivers/gpu/drm/sti/sti_hda.c | 1 +
> drivers/gpu/drm/sti/sti_hdmi.c | 1 +
> include/drm/drm_bridge.h | 8 +++----
> 30 files changed, 57 insertions(+), 36 deletions(-)
>
> --
> 2.11.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Daniel Vetter @ 2018-05-07 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4cdcd215-8caf-e045-a478-f438f128c9f2@samsung.com>
On Mon, May 07, 2018 at 02:59:45PM +0200, Andrzej Hajda wrote:
> On 04.05.2018 15:52, Peter Rosin wrote:
> > If the bridge supplier is unbound, this will bring the bridge consumer
> > down along with the bridge. Thus, there will no longer linger any
> > dangling pointers from the bridge consumer (the drm_device) to some
> > non-existent bridge supplier.
>
> I understand rationales behind this patch, but it is another step into
> making drm_dev one big driver with subcomponents, where drm will work
> only if every subcomponent is working/loaded. Do we need to go this way?
> In case of many platforms such approach results in display turned on
> very late on boot for example due to late initialization of some
> regulator exposed by some i2c device, which is used by hdmi bridge. And
> this hdmi bridge is just to provide alternative(rarely used) display
> path, the main display path would work anyway.
>
> So the main question to drm maintainers is about evolution of bridges,
> if drm_bridges should become mandatory components of drm device or they
> could be added/removed dynamically?
This is already the case. You currently cannot hotplug a drm_bridge,
everything must be present. I don't think it makes sense to change that
until we have physically hotpluggable drm_bridges in real hardware. I
definitely don't want to refcount stuff to work around driver load
bonghits on DT platforms, because refcounting is way too hard to get right
:-)
Afaik there's out-of-tree patches to solve 99% of the driver load fun on
DT platforms, but because it's not a 100% solution it's blocked since
forever.
-Daniel
>
> Regards
> Andrzej
>
>
> >
> > Signed-off-by: Peter Rosin <peda@axentia.se>
> > ---
> > drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
> > include/drm/drm_bridge.h | 2 ++
> > 2 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index 78d186b6831b..0259f0a3ff27 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -26,6 +26,7 @@
> > #include <linux/mutex.h>
> >
> > #include <drm/drm_bridge.h>
> > +#include <drm/drm_device.h>
> > #include <drm/drm_encoder.h>
> >
> > #include "drm_crtc_internal.h"
> > @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
> > if (bridge->dev)
> > return -EBUSY;
> >
> > + if (encoder->dev->dev != bridge->odev) {
> > + bridge->link = device_link_add(encoder->dev->dev,
> > + bridge->odev, 0);
> > + if (!bridge->link) {
> > + dev_err(bridge->odev, "failed to link bridge to %s\n",
> > + dev_name(encoder->dev->dev));
> > + return -EINVAL;
> > + }
> > + }
> > +
> > bridge->dev = encoder->dev;
> > bridge->encoder = encoder;
> >
> > if (bridge->funcs->attach) {
> > ret = bridge->funcs->attach(bridge);
> > if (ret < 0) {
> > + if (bridge->link)
> > + device_link_del(bridge->link);
> > + bridge->link = NULL;
> > bridge->dev = NULL;
> > bridge->encoder = NULL;
> > return ret;
> > @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> > if (bridge->funcs->detach)
> > bridge->funcs->detach(bridge);
> >
> > + if (bridge->link)
> > + device_link_del(bridge->link);
> > + bridge->link = NULL;
> > +
> > bridge->dev = NULL;
> > }
> >
> > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > index b656e505d11e..804189c63a4c 100644
> > --- a/include/drm/drm_bridge.h
> > +++ b/include/drm/drm_bridge.h
> > @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> > * @list: to keep track of all added bridges
> > * @timings: the timing specification for the bridge, if any (may
> > * be NULL)
> > + * @link: drm consumer <-> bridge supplier
> > * @funcs: control functions
> > * @driver_private: pointer to the bridge driver's internal context
> > */
> > @@ -271,6 +272,7 @@ struct drm_bridge {
> > struct drm_bridge *next;
> > struct list_head list;
> > const struct drm_bridge_timings *timings;
> > + struct device_link *link;
> >
> > const struct drm_bridge_funcs *funcs;
> > void *driver_private;
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH] ARM: dts: imx51-zii-rdu1: fix touchscreen bindings
From: Nikita Yushchenko @ 2018-05-07 13:53 UTC (permalink / raw)
To: linux-arm-kernel
This fixes errors in RDU1 device tree that cause touch screens not
working.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index 0c99ac04ad08..6464f2560e06 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -523,7 +523,7 @@
};
touchscreen at 20 {
- compatible = "syna,rmi4_i2c";
+ compatible = "syna,rmi4-i2c";
reg = <0x20>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ts>;
@@ -541,8 +541,8 @@
rmi4-f11 at 11 {
reg = <0x11>;
- touch-inverted-y;
- touch-swapped-x-y;
+ touchscreen-inverted-y;
+ touchscreen-swapped-x-y;
syna,sensor-type = <1>;
};
};
--
2.11.0
^ permalink raw reply related
* [PATCH v3 08/14] media: v4l: Add definitions for MPEG2 frame format and header metadata
From: Paul Kocialkowski @ 2018-05-07 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1bd7af5a-c8d5-220c-8471-545eb1835882@xs4all.nl>
Hi Hans,
On Mon, 2018-05-07 at 15:49 +0200, Hans Verkuil wrote:
> On 07/05/18 14:44, Paul Kocialkowski wrote:
> > From: Florent Revest <florent.revest@free-electrons.com>
> >
> > Stateless video decoding engines require both the MPEG slices and
> > associated metadata from the video stream in order to decode frames.
> >
> > This introduces definitions for a new pixel format, describing
> > buffers
> > with MPEG2 slice data, as well as a control structure for passing
> > the
> > frame header (metadata) to drivers.
Thanks for the review!
I should have made it clear that this patch has not seen any improvement
between v2 and v3. Cleaning up and documenting the MPEG2 headers is
still in the tasks list (presented in the cover letter), as well as the
MB32 NV12 format.
> > Signed-off-by: Florent Revest <florent.revest@free-electrons.com>
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > ---
> > drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++++++++++
> > drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> > include/uapi/linux/v4l2-controls.h | 26
> > ++++++++++++++++++++++++++
> > include/uapi/linux/videodev2.h | 3 +++
> > 4 files changed, 40 insertions(+)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index df58a23eb731..cdf860c8e3d8 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -826,6 +826,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
> > return "Vertical MV Search Range";
> > case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER:
> > return "Repeat Sequence Header";
> > case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME: re
> > turn "Force Key Frame";
> > + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR: re
> > turn "MPEG2 Frame Header";
>
> This compound control needs to be documented in the V4l2 spec.
>
> >
> > /* VPX controls */
> > case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS:
> > return "VPX Number of Partitions";
> > @@ -1271,6 +1272,9 @@ void v4l2_ctrl_fill(u32 id, const char **name,
> > enum v4l2_ctrl_type *type,
> > case V4L2_CID_RDS_TX_ALT_FREQS:
> > *type = V4L2_CTRL_TYPE_U32;
> > break;
> > + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
> > + *type = V4L2_CTRL_TYPE_MPEG2_FRAME_HDR;
> > + break;
> > default:
> > *type = V4L2_CTRL_TYPE_INTEGER;
> > break;
> > @@ -1591,6 +1595,9 @@ static int std_validate(const struct v4l2_ctrl
> > *ctrl, u32 idx,
> > return -ERANGE;
> > return 0;
> >
> > + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> > + return 0;
> > +
> > default:
> > return -EINVAL;
> > }
> > @@ -2165,6 +2172,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> > v4l2_ctrl_handler *hdl,
> > case V4L2_CTRL_TYPE_U32:
> > elem_size = sizeof(u32);
> > break;
> > + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> > + elem_size = sizeof(struct
> > v4l2_ctrl_mpeg2_frame_hdr);
> > + break;
> > default:
> > if (type < V4L2_CTRL_COMPOUND_TYPES)
> > elem_size = sizeof(s32);
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 561a1fe3160b..38d318c47c55 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1274,6 +1274,7 @@ static void v4l_fill_fmtdesc(struct
> > v4l2_fmtdesc *fmt)
> > case V4L2_PIX_FMT_VP8: descr =
> > "VP8"; break;
> > case V4L2_PIX_FMT_VP9: descr =
> > "VP9"; break;
> > case V4L2_PIX_FMT_HEVC: descr =
> > "HEVC"; break; /* aka H.265 */
> > + case V4L2_PIX_FMT_MPEG2_FRAME: descr =
> > "MPEG2 Frame"; break;
>
> Needs to be documented in the spec.
>
> > case V4L2_PIX_FMT_CPIA1: descr = "GSPCA CPiA
> > YUV"; break;
> > case V4L2_PIX_FMT_WNVA: descr =
> > "WNVA"; break;
> > case V4L2_PIX_FMT_SN9C10X: descr = "GSPCA
> > SN9C10X"; break;
> > diff --git a/include/uapi/linux/v4l2-controls.h
> > b/include/uapi/linux/v4l2-controls.h
> > index 8d473c979b61..23da8bfa7e6f 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -557,6 +557,8 @@ enum v4l2_mpeg_video_mpeg4_profile {
> > };
> > #define V4L2_CID_MPEG_VIDEO_MPEG4_QPEL (V4L2_CID_MPE
> > G_BASE+407)
> >
> > +#define
> > V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR (V4L2_CID_MPEG_BASE+450)
> > +
> > /* Control IDs for VP8 streams
> > * Although VP8 is not part of MPEG we add these controls to the
> > MPEG class
> > * as that class is already handling other video compression
> > standards
> > @@ -1076,4 +1078,28 @@ enum v4l2_detect_md_mode {
> > #define V4L2_CID_DETECT_MD_THRESHOLD_GRID (V4L2_CID_DETECT_C
> > LASS_BASE + 3)
> > #define V4L2_CID_DETECT_MD_REGION_GRID (V4L2_CID_DET
> > ECT_CLASS_BASE + 4)
> >
> > +struct v4l2_ctrl_mpeg2_frame_hdr {
> > + __u32 slice_len;
> > + __u32 slice_pos;
> > + enum { MPEG1, MPEG2 } type;
>
> Still an enum?
>
> > +
> > + __u16 width;
> > + __u16 height;
> > +
> > + enum { PCT_I = 1, PCT_P, PCT_B, PCT_D }
> > picture_coding_type;
> > + __u8 f_code[2][2];
> > +
> > + __u8 intra_dc_precision;
> > + __u8 picture_structure;
> > + __u8 top_field_first;
> > + __u8 frame_pred_frame_dct;
> > + __u8 concealment_motion_vectors;
> > + __u8 q_scale_type;
> > + __u8 intra_vlc_format;
> > + __u8 alternate_scan;
> > +
> > + __u8 backward_ref_index;
> > + __u8 forward_ref_index;
> > +};
> > +
> > #endif
> > diff --git a/include/uapi/linux/videodev2.h
> > b/include/uapi/linux/videodev2.h
> > index 1f6c4b52baae..d8f9b59d90d7 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -636,6 +636,7 @@ struct v4l2_pix_format {
> > #define V4L2_PIX_FMT_VP8 v4l2_fourcc('V', 'P', '8', '0') /*
> > VP8 */
> > #define V4L2_PIX_FMT_VP9 v4l2_fourcc('V', 'P', '9', '0') /*
> > VP9 */
> > #define V4L2_PIX_FMT_HEVC v4l2_fourcc('H', 'E', 'V', 'C') /*
> > HEVC aka H.265 */
> > +#define V4L2_PIX_FMT_MPEG2_FRAME v4l2_fourcc('M', 'G', '2', 'F') /*
> > MPEG2 frame */
> >
> > /* Vendor-specific formats */
> > #define V4L2_PIX_FMT_CPIA1 v4l2_fourcc('C', 'P', 'I', 'A') /*
> > cpia1 YUV */
> > @@ -1587,6 +1588,7 @@ struct v4l2_ext_control {
> > __u8 __user *p_u8;
> > __u16 __user *p_u16;
> > __u32 __user *p_u32;
> > + struct v4l2_ctrl_mpeg2_frame_hdr __user
> > *p_mpeg2_frame_hdr;
> > void __user *ptr;
> > };
> > } __attribute__ ((packed));
> > @@ -1632,6 +1634,7 @@ enum v4l2_ctrl_type {
> > V4L2_CTRL_TYPE_U8 = 0x0100,
> > V4L2_CTRL_TYPE_U16 = 0x0101,
> > V4L2_CTRL_TYPE_U32 = 0x0102,
> > + V4L2_CTRL_TYPE_MPEG2_FRAME_HDR = 0x0109,
> > };
> >
> > /* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
> >
>
> Regards,
>
> Hans
--
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180507/c9681c49/attachment.sig>
^ permalink raw reply
* [PATCH v3 09/14] media: v4l: Add definition for Allwinner's MB32-tiled NV12 format
From: Hans Verkuil @ 2018-05-07 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507124500.20434-10-paul.kocialkowski@bootlin.com>
On 07/05/18 14:44, Paul Kocialkowski wrote:
> This introduces support for Allwinner's MB32-tiled NV12 format, where
> each plane is divided into macroblocks of 32x32 pixels. Hence, the size
> of each plane has to be aligned to 32 bytes. The pixels inside each
> macroblock are coded as they would be if the macroblock was a single
> plane, line after line.
>
> The MB32-tiled NV12 format is used by the video engine on Allwinner
> platforms: it is the default format for decoded frames (and the only one
> available in the oldest supported platforms).
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
> include/uapi/linux/videodev2.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index d8f9b59d90d7..242a6bfa1440 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -670,6 +670,7 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_Z16 v4l2_fourcc('Z', '1', '6', ' ') /* Depth data 16-bit */
> #define V4L2_PIX_FMT_MT21C v4l2_fourcc('M', 'T', '2', '1') /* Mediatek compressed block mode */
> #define V4L2_PIX_FMT_INZI v4l2_fourcc('I', 'N', 'Z', 'I') /* Intel Planar Greyscale 10-bit and Depth 16-bit */
> +#define V4L2_PIX_FMT_MB32_NV12 v4l2_fourcc('M', 'N', '1', '2') /* Allwinner NV12 in 32x32 macroblocks */
Must be documented in the spec as well.
Regards,
Hans
>
> /* 10bit raw bayer packed, 32 bytes for every 25 pixels, last LSB 6 bits unused */
> #define V4L2_PIX_FMT_IPU3_SBGGR10 v4l2_fourcc('i', 'p', '3', 'b') /* IPU3 packed 10-bit BGGR bayer */
>
^ permalink raw reply
* [PATCH v3 08/14] media: v4l: Add definitions for MPEG2 frame format and header metadata
From: Hans Verkuil @ 2018-05-07 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507124500.20434-9-paul.kocialkowski@bootlin.com>
On 07/05/18 14:44, Paul Kocialkowski wrote:
> From: Florent Revest <florent.revest@free-electrons.com>
>
> Stateless video decoding engines require both the MPEG slices and
> associated metadata from the video stream in order to decode frames.
>
> This introduces definitions for a new pixel format, describing buffers
> with MPEG2 slice data, as well as a control structure for passing the
> frame header (metadata) to drivers.
>
> Signed-off-by: Florent Revest <florent.revest@free-electrons.com>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++++++++++
> drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> include/uapi/linux/v4l2-controls.h | 26 ++++++++++++++++++++++++++
> include/uapi/linux/videodev2.h | 3 +++
> 4 files changed, 40 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> index df58a23eb731..cdf860c8e3d8 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -826,6 +826,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: return "Vertical MV Search Range";
> case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: return "Repeat Sequence Header";
> case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME: return "Force Key Frame";
> + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR: return "MPEG2 Frame Header";
This compound control needs to be documented in the V4l2 spec.
>
> /* VPX controls */
> case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS: return "VPX Number of Partitions";
> @@ -1271,6 +1272,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> case V4L2_CID_RDS_TX_ALT_FREQS:
> *type = V4L2_CTRL_TYPE_U32;
> break;
> + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
> + *type = V4L2_CTRL_TYPE_MPEG2_FRAME_HDR;
> + break;
> default:
> *type = V4L2_CTRL_TYPE_INTEGER;
> break;
> @@ -1591,6 +1595,9 @@ static int std_validate(const struct v4l2_ctrl *ctrl, u32 idx,
> return -ERANGE;
> return 0;
>
> + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> + return 0;
> +
> default:
> return -EINVAL;
> }
> @@ -2165,6 +2172,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl,
> case V4L2_CTRL_TYPE_U32:
> elem_size = sizeof(u32);
> break;
> + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> + elem_size = sizeof(struct v4l2_ctrl_mpeg2_frame_hdr);
> + break;
> default:
> if (type < V4L2_CTRL_COMPOUND_TYPES)
> elem_size = sizeof(s32);
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 561a1fe3160b..38d318c47c55 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1274,6 +1274,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> case V4L2_PIX_FMT_VP8: descr = "VP8"; break;
> case V4L2_PIX_FMT_VP9: descr = "VP9"; break;
> case V4L2_PIX_FMT_HEVC: descr = "HEVC"; break; /* aka H.265 */
> + case V4L2_PIX_FMT_MPEG2_FRAME: descr = "MPEG2 Frame"; break;
Needs to be documented in the spec.
> case V4L2_PIX_FMT_CPIA1: descr = "GSPCA CPiA YUV"; break;
> case V4L2_PIX_FMT_WNVA: descr = "WNVA"; break;
> case V4L2_PIX_FMT_SN9C10X: descr = "GSPCA SN9C10X"; break;
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index 8d473c979b61..23da8bfa7e6f 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -557,6 +557,8 @@ enum v4l2_mpeg_video_mpeg4_profile {
> };
> #define V4L2_CID_MPEG_VIDEO_MPEG4_QPEL (V4L2_CID_MPEG_BASE+407)
>
> +#define V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR (V4L2_CID_MPEG_BASE+450)
> +
> /* Control IDs for VP8 streams
> * Although VP8 is not part of MPEG we add these controls to the MPEG class
> * as that class is already handling other video compression standards
> @@ -1076,4 +1078,28 @@ enum v4l2_detect_md_mode {
> #define V4L2_CID_DETECT_MD_THRESHOLD_GRID (V4L2_CID_DETECT_CLASS_BASE + 3)
> #define V4L2_CID_DETECT_MD_REGION_GRID (V4L2_CID_DETECT_CLASS_BASE + 4)
>
> +struct v4l2_ctrl_mpeg2_frame_hdr {
> + __u32 slice_len;
> + __u32 slice_pos;
> + enum { MPEG1, MPEG2 } type;
Still an enum?
> +
> + __u16 width;
> + __u16 height;
> +
> + enum { PCT_I = 1, PCT_P, PCT_B, PCT_D } picture_coding_type;
> + __u8 f_code[2][2];
> +
> + __u8 intra_dc_precision;
> + __u8 picture_structure;
> + __u8 top_field_first;
> + __u8 frame_pred_frame_dct;
> + __u8 concealment_motion_vectors;
> + __u8 q_scale_type;
> + __u8 intra_vlc_format;
> + __u8 alternate_scan;
> +
> + __u8 backward_ref_index;
> + __u8 forward_ref_index;
> +};
> +
> #endif
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 1f6c4b52baae..d8f9b59d90d7 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -636,6 +636,7 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_VP8 v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
> #define V4L2_PIX_FMT_VP9 v4l2_fourcc('V', 'P', '9', '0') /* VP9 */
> #define V4L2_PIX_FMT_HEVC v4l2_fourcc('H', 'E', 'V', 'C') /* HEVC aka H.265 */
> +#define V4L2_PIX_FMT_MPEG2_FRAME v4l2_fourcc('M', 'G', '2', 'F') /* MPEG2 frame */
>
> /* Vendor-specific formats */
> #define V4L2_PIX_FMT_CPIA1 v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
> @@ -1587,6 +1588,7 @@ struct v4l2_ext_control {
> __u8 __user *p_u8;
> __u16 __user *p_u16;
> __u32 __user *p_u32;
> + struct v4l2_ctrl_mpeg2_frame_hdr __user *p_mpeg2_frame_hdr;
> void __user *ptr;
> };
> } __attribute__ ((packed));
> @@ -1632,6 +1634,7 @@ enum v4l2_ctrl_type {
> V4L2_CTRL_TYPE_U8 = 0x0100,
> V4L2_CTRL_TYPE_U16 = 0x0101,
> V4L2_CTRL_TYPE_U32 = 0x0102,
> + V4L2_CTRL_TYPE_MPEG2_FRAME_HDR = 0x0109,
> };
>
> /* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
>
Regards,
Hans
^ permalink raw reply
* [PATCH 00/13] drm/kms/mode: using helper func drm_display_mode_to/from_videomode for calculating timing parameters
From: Daniel Vetter @ 2018-05-07 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1525087679.git.satendra.t@samsung.com>
On Thu, May 03, 2018 at 01:53:55PM +0530, Satendra Singh Thakur wrote:
> 1.There is a function in drm-core to calculate display timing parameters:
> horizontal front porch, back porch, sync length,
> vertical front porch, back porch, sync length and
> clock in Hz.
> However, some drivers are still calculating these parameters themselves.
> Therefore, there is a duplication of the code.
> This patch series replaces this redundant code with the function
> drm_display_mode_to_videomode.
> This removes nearly 100 redundant lines from the related drivers.
> 2.For some drivers (sun4i) the reverse helper
> drm_display_mode_from_videomode is used.
> 3.For some drivers it replaces arithmatic operators (*, /) with shifting
> operators (>>, <<).
> 4.For some drivers DRM_MODE_FLAG_* are replaced with DISPLAY_FLAGS_* flags.
> 5.These changes apply to following crtc and encoder drivers:
> atmel-hlcdc
> bridge-tc358767
> exynos-dsi
> fsl-dcu
> gma500-mdfld_dsi_dpi
> hisilicon-kirin_dsi, ade
> meson-encoder
> pl111-display
> sun4i-tv
> ti lcdc
> tegra dc
> mediatek dpi dsi
> bridge-adv7533
The drm_mode_to_videomode helper is meant for interop between drm and v4l,
which have different internal structures to represent modes.
For drivers that only use drm I think the better option would be to add
these fields to struct drm_display_mode as another set of crtc_* values
(the computed values are stored in crtc_ prefixed members). And compute
front/back porch in drm_mode_set_crtcinfo.
Then we can use these new drm_display_mode->crtc_h|vfront|back_porch
fields in all the drivers you're changing. This way you avoid having to
change all the drm drivers to use v4l #defines.
Thanks,
Daniel
>
> Satendra Singh Thakur (13):
> drm/kms/mode/atmel-hlcdc: using helper func
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/bridge-tc358767: using helper func
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/exynos-dsi: using helper func
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/fsl-dcu: using helper func drm_display_mode_to_videomode
> for calculating timing parameters
> drm/kms/mode/gma500-mdfld_dsi_dpi: using helper function
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/hisilicon-kirin-dsi-ade: using helper function
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/meson-encoder: using helper function
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/pl111-display: using helper function
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/sun4i-tv: using helper func
> drm_display_mode_from_videomode for calculating timing
> parameters
> drm/kms/mode/ti-lcdc: using helper func drm_display_mode_to_videomode
> for calculating timing parameters
> drm/kms/mode/tegra: using helper func drm_display_mode_to_videomode
> for calculating timing parameters
> drm/kms/mode/mtk_dpi_dsi: using helper func
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/bridge-adv7533: using helper func
> drm_display_mode_to_videomode for calculating timing parameters
>
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 28 +++--
> drivers/gpu/drm/bridge/adv7511/adv7533.c | 35 +++---
> drivers/gpu/drm/bridge/tc358767.c | 42 +++----
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 29 ++---
> drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 28 ++---
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 42 ++++---
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 52 +++------
> drivers/gpu/drm/mediatek/mtk_dpi.c | 60 +++++-----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +--
> drivers/gpu/drm/meson/meson_venc.c | 149 +++++++++++-------------
> drivers/gpu/drm/pl111/pl111_display.c | 40 +++----
> drivers/gpu/drm/sun4i/sun4i_tv.c | 67 ++++-------
> drivers/gpu/drm/tegra/dc.c | 15 ++-
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 60 +++++-----
> 15 files changed, 280 insertions(+), 390 deletions(-)
>
> --
> 2.7.4
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Peter Rosin @ 2018-05-07 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4cdcd215-8caf-e045-a478-f438f128c9f2@samsung.com>
On 2018-05-07 14:59, Andrzej Hajda wrote:
> On 04.05.2018 15:52, Peter Rosin wrote:
>> If the bridge supplier is unbound, this will bring the bridge consumer
>> down along with the bridge. Thus, there will no longer linger any
>> dangling pointers from the bridge consumer (the drm_device) to some
>> non-existent bridge supplier.
>
> I understand rationales behind this patch, but it is another step into
> making drm_dev one big driver with subcomponents, where drm will work
> only if every subcomponent is working/loaded.
The step is very small IMHO. Just a device-link, which is very easy to
remove once whatever other solution is ready.
> Do we need to go this way?
If the drivers expect the parts to be there, and there is no other safety
net in place if they are not, what is the (short-term) alternative?
> In case of many platforms such approach results in display turned on
> very late on boot for example due to late initialization of some
> regulator exposed by some i2c device, which is used by hdmi bridge. And
> this hdmi bridge is just to provide alternative(rarely used) display
> path, the main display path would work anyway.
This patch does not contribute to any late init and any such delay is not
affected by this. At all.
> So the main question to drm maintainers is about evolution of bridges,
> if drm_bridges should become mandatory components of drm device or they
> could be added/removed dynamically?
That is a much bigger question than this patch/series. Conflating the
two is not fair IMHO. You could run this very same argument for every
driver that gets added, since any additional driver will just make it
harder to make everything dynamic. Should we stop development right
away?
Besides, as long as the drm devices are in fact acting as big static
drivers (built from smaller parts), this should be considered a bug-fix
that will prevent dereference of stale pointers.
Or will some other solution appear and magically make all bridges and
drm drivers capable of dynamic reconfiguration in the next few weeks?
Yeah, right...
Cheers,
Peter
> Regards
> Andrzej
>
>
>>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
>> ---
>> drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
>> include/drm/drm_bridge.h | 2 ++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>> index 78d186b6831b..0259f0a3ff27 100644
>> --- a/drivers/gpu/drm/drm_bridge.c
>> +++ b/drivers/gpu/drm/drm_bridge.c
>> @@ -26,6 +26,7 @@
>> #include <linux/mutex.h>
>>
>> #include <drm/drm_bridge.h>
>> +#include <drm/drm_device.h>
>> #include <drm/drm_encoder.h>
>>
>> #include "drm_crtc_internal.h"
>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
>> if (bridge->dev)
>> return -EBUSY;
>>
>> + if (encoder->dev->dev != bridge->odev) {
>> + bridge->link = device_link_add(encoder->dev->dev,
>> + bridge->odev, 0);
>> + if (!bridge->link) {
>> + dev_err(bridge->odev, "failed to link bridge to %s\n",
>> + dev_name(encoder->dev->dev));
>> + return -EINVAL;
>> + }
>> + }
>> +
>> bridge->dev = encoder->dev;
>> bridge->encoder = encoder;
>>
>> if (bridge->funcs->attach) {
>> ret = bridge->funcs->attach(bridge);
>> if (ret < 0) {
>> + if (bridge->link)
>> + device_link_del(bridge->link);
>> + bridge->link = NULL;
>> bridge->dev = NULL;
>> bridge->encoder = NULL;
>> return ret;
>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>> if (bridge->funcs->detach)
>> bridge->funcs->detach(bridge);
>>
>> + if (bridge->link)
>> + device_link_del(bridge->link);
>> + bridge->link = NULL;
>> +
>> bridge->dev = NULL;
>> }
>>
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index b656e505d11e..804189c63a4c 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
>> * @list: to keep track of all added bridges
>> * @timings: the timing specification for the bridge, if any (may
>> * be NULL)
>> + * @link: drm consumer <-> bridge supplier
>> * @funcs: control functions
>> * @driver_private: pointer to the bridge driver's internal context
>> */
>> @@ -271,6 +272,7 @@ struct drm_bridge {
>> struct drm_bridge *next;
>> struct list_head list;
>> const struct drm_bridge_timings *timings;
>> + struct device_link *link;
>>
>> const struct drm_bridge_funcs *funcs;
>> void *driver_private;
>
>
^ permalink raw reply
* [PATCH 1/3] drm/sti: do not remove the drm_bridge that was never added
From: Daniel Vetter @ 2018-05-07 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd8d12f7-0c71-c96b-80fa-54de7de39511@axentia.se>
On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> On 2018-05-03 11:06, Daniel Vetter wrote:
> > On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
> >> The more natural approach would perhaps be to add an drm_bridge_add,
> >> but there are several other bridges that never call drm_bridge_add.
> >> Just removing the drm_bridge_remove is the easier fix.
> >>
> >> Signed-off-by: Peter Rosin <peda@axentia.se>
> >
> > This mess is much bigger. There's 2 pairs of bridge functions:
> >
> > - drm_bridge_attach/detach. Those are meant to be called by the overall
> > drm driver to connect/disconnect a drm_bridge.
> >
> > - drm_bridge_add/remove. These are supposed to be called by the bridge
> > driver itself to register/unregister itself. Maybe we should rename
> > them, since the same issue happens with drm_panel, with the same
> > confusion.
> >
> > I thought someone was working on a cleanup series to fix this mess, but I
> > didn't find anything.
>
> Ok, I just spotted the imbalance and didn't really dig into what
> actually happens in these error paths. Now that I have done so I
> believe that the removed drm_bridge_remove calls causes NULL
> dereferences if/when the error paths are triggered.
>
> So, I don't think this can wait for some bigger cleanup.
>
> drm_bridge_remove calls list_del_init calls __list_del_entry calls
> __list_del with NULL in both prev and next since the list member
> is never initialized. prev and next are dereferenced by __list_del
> and you have *boom*
>
> I recommend adding the tag
>
> Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
>
> so that stable picks this one up.
I just wanted to correct your commit message text - the correct solution
is definitely _not_ for sti here to call drm_bridge_add. It should call
drm_bridge_attach/detach only, as a pair.
I didn't check whether you instead have a _detach call missing or what's
going on here.
-Daniel
>
> Cheers,
> Peter
>
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/sti/sti_hda.c | 1 -
> >> drivers/gpu/drm/sti/sti_hdmi.c | 1 -
> >> 2 files changed, 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> >> index 67bbdb49fffc..199db13f565c 100644
> >> --- a/drivers/gpu/drm/sti/sti_hda.c
> >> +++ b/drivers/gpu/drm/sti/sti_hda.c
> >> @@ -721,7 +721,6 @@ static int sti_hda_bind(struct device *dev, struct device *master, void *data)
> >> return 0;
> >>
> >> err_sysfs:
> >> - drm_bridge_remove(bridge);
> >> return -EINVAL;
> >> }
> >>
> >> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> >> index 58f431102512..932724784942 100644
> >> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> >> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> >> @@ -1315,7 +1315,6 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data)
> >> return 0;
> >>
> >> err_sysfs:
> >> - drm_bridge_remove(bridge);
> >> hdmi->drm_connector = NULL;
> >> return -EINVAL;
> >> }
> >> --
> >> 2.11.0
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [RFC PATCH] driver core: make deferring probe forever optional
From: Rob Herring @ 2018-05-07 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180505012513.GJ13402@sirena.org.uk>
On Fri, May 4, 2018 at 8:25 PM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 02, 2018 at 07:49:57PM +0100, Robin Murphy wrote:
>
>> I guess there's also the possibility that a single driver may want multiple
>> behaviours, if e.g. if SoC variants A and B have some identical peripherals
>> but slightly different pinctrl/IOMMU/etc. hardware such that A has workable
>> default behaviour and can be treated as optional, whereas B absolutely must
>> be controlled by the kernel for the consumers to function properly, and they
>> *should* defer forever otherwise. I think that would pretty much demand some
>> sort of explicitly-curated white/blacklist setup at the subsystem or driver
>> level.
>
> Different board variants, and possibly even different bootloaders might
> also be an issue here - a vendor bootloader might do pinmuxing that an
> upstream bootloader doesn't for example. In some cases the pinmuxing
> even depends on the boot method with things only getting configured if
> the bootloader wanted to use them.
I think this is going to be too big of a hammer for pinctrl at least.
My current thought is to define a pinctrl DT property to indicate pins
are configured already which the OS can use to decide if pinctrl is
optional or not. I'd prefer to keep it simple and be a per pin
controller flag even though this is quite possibly a per client or pin
group state (as you say, the bootloader may only configure what it
uses). Making this per pin group could be a lot of nodes and difficult
to really get right without testing. Making it per pin controller
could make drivers fail in less predictable ways if their pins are not
configured.
Rob
^ permalink raw reply
* [PATCH v2] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs
From: Boqun Feng @ 2018-05-07 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <tip-0476a632cb3aa88c03cefc294050a9a86760e88d@git.kernel.org>
Move PowerPC's __op_{acqurie,release}() from atomic.h to
cmpxchg.h (in arch/powerpc/include/asm), plus use them to
define these two methods:
#define cmpxchg_release __op_release(cmpxchg, __VA_ARGS__);
#define cmpxchg64_release __op_release(cmpxchg64, __VA_ARGS__);
... the idea is to generate all these methods in cmpxchg.h and to define the full
array of atomic primitives, including the cmpxchg_release() methods which were
defined by the generic code before.
Also define the atomic[64]_() variants explicitly.
This ensures that all these low level cmpxchg APIs are defined in
PowerPC headers, with no generic header fallbacks.
Also remove the duplicate definitions of atomic_xchg() and
atomic64_xchg() in asm/atomic.h: they could be generated via the generic
atomic.h header using _relaxed() primitives. This helps ppc adopt the
upcoming change of generic atomic.h header.
No change in functionality or code generation.
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: aryabinin at virtuozzo.com
Cc: catalin.marinas at arm.com
Cc: dvyukov at google.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: will.deacon at arm.com
---
v1 --> v2:
remove duplicate definitions for atomic*_xchg() for future
change
Ingo,
I also remove the link and your SoB because I think your bot
could add them automatically.
arch/powerpc/include/asm/atomic.h | 24 ++++--------------------
arch/powerpc/include/asm/cmpxchg.h | 24 ++++++++++++++++++++++++
2 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/include/asm/atomic.h b/arch/powerpc/include/asm/atomic.h
index 682b3e6a1e21..583837a41bcc 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -13,24 +13,6 @@
#define ATOMIC_INIT(i) { (i) }
-/*
- * Since *_return_relaxed and {cmp}xchg_relaxed are implemented with
- * a "bne-" instruction at the end, so an isync is enough as a acquire barrier
- * on the platform without lwsync.
- */
-#define __atomic_op_acquire(op, args...) \
-({ \
- typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
- __asm__ __volatile__(PPC_ACQUIRE_BARRIER "" : : : "memory"); \
- __ret; \
-})
-
-#define __atomic_op_release(op, args...) \
-({ \
- __asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory"); \
- op##_relaxed(args); \
-})
-
static __inline__ int atomic_read(const atomic_t *v)
{
int t;
@@ -213,8 +195,9 @@ static __inline__ int atomic_dec_return_relaxed(atomic_t *v)
cmpxchg_relaxed(&((v)->counter), (o), (n))
#define atomic_cmpxchg_acquire(v, o, n) \
cmpxchg_acquire(&((v)->counter), (o), (n))
+#define atomic_cmpxchg_release(v, o, n) \
+ cmpxchg_release(&((v)->counter), (o), (n))
-#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
#define atomic_xchg_relaxed(v, new) xchg_relaxed(&((v)->counter), (new))
/**
@@ -519,8 +502,9 @@ static __inline__ long atomic64_dec_if_positive(atomic64_t *v)
cmpxchg_relaxed(&((v)->counter), (o), (n))
#define atomic64_cmpxchg_acquire(v, o, n) \
cmpxchg_acquire(&((v)->counter), (o), (n))
+#define atomic64_cmpxchg_release(v, o, n) \
+ cmpxchg_release(&((v)->counter), (o), (n))
-#define atomic64_xchg(v, new) (xchg(&((v)->counter), new))
#define atomic64_xchg_relaxed(v, new) xchg_relaxed(&((v)->counter), (new))
/**
diff --git a/arch/powerpc/include/asm/cmpxchg.h b/arch/powerpc/include/asm/cmpxchg.h
index 9b001f1f6b32..e27a612b957f 100644
--- a/arch/powerpc/include/asm/cmpxchg.h
+++ b/arch/powerpc/include/asm/cmpxchg.h
@@ -8,6 +8,24 @@
#include <asm/asm-compat.h>
#include <linux/bug.h>
+/*
+ * Since *_return_relaxed and {cmp}xchg_relaxed are implemented with
+ * a "bne-" instruction at the end, so an isync is enough as a acquire barrier
+ * on the platform without lwsync.
+ */
+#define __atomic_op_acquire(op, args...) \
+({ \
+ typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
+ __asm__ __volatile__(PPC_ACQUIRE_BARRIER "" : : : "memory"); \
+ __ret; \
+})
+
+#define __atomic_op_release(op, args...) \
+({ \
+ __asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory"); \
+ op##_relaxed(args); \
+})
+
#ifdef __BIG_ENDIAN
#define BITOFF_CAL(size, off) ((sizeof(u32) - size - off) * BITS_PER_BYTE)
#else
@@ -512,6 +530,9 @@ __cmpxchg_acquire(void *ptr, unsigned long old, unsigned long new,
(unsigned long)_o_, (unsigned long)_n_, \
sizeof(*(ptr))); \
})
+
+#define cmpxchg_release(...) __atomic_op_release(cmpxchg, __VA_ARGS__)
+
#ifdef CONFIG_PPC64
#define cmpxchg64(ptr, o, n) \
({ \
@@ -533,6 +554,9 @@ __cmpxchg_acquire(void *ptr, unsigned long old, unsigned long new,
BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
cmpxchg_acquire((ptr), (o), (n)); \
})
+
+#define cmpxchg64_release(...) __atomic_op_release(cmpxchg64, __VA_ARGS__)
+
#else
#include <asm-generic/cmpxchg-local.h>
#define cmpxchg64_local(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))
--
2.16.2
^ permalink raw reply related
* [PATCH v3 2/2] ARM: dts: r8a73a4: Correct mask for GIC PPI interrupts
From: Geert Uytterhoeven @ 2018-05-07 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525699193-5589-1-git-send-email-geert+renesas@glider.be>
R-Mobile APE6 (r8a73a4) contains four Cortex-A15 and four Cortex-A7
cores, hence the second interrupt specifier cell for Private Peripheral
Interrupts should use "GIC_CPU_MASK_SIMPLE(8)", so GIC interrupts are
delivered to all 8 processor cores.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v3:
- Change one-line summary prefix to match current arm-soc practices,
- Rebased,
v2:
- Drop RFC status after receiving confirmation from Liviu Dudau.
---
arch/arm/boot/dts/r8a73a4.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 8e48090e4fdc1412..080d037f5733a8c3 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -57,10 +57,10 @@
timer {
compatible = "arm,armv7-timer";
- interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
};
dbsc1: memory-controller at e6790000 {
@@ -464,7 +464,7 @@
<0 0xf1002000 0 0x2000>,
<0 0xf1004000 0 0x2000>,
<0 0xf1006000 0 0x2000>;
- interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
clocks = <&mstp4_clks R8A73A4_CLK_INTC_SYS>;
clock-names = "clk";
power-domains = <&pd_c4>;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/2] ARM: dts: r8a7790: Correct mask for GIC PPI interrupts
From: Geert Uytterhoeven @ 2018-05-07 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525699193-5589-1-git-send-email-geert+renesas@glider.be>
R-Car H2 (r8a7790) contains four Cortex-A15 and four Cortex-A7 cores,
hence the second interrupt specifier cell for Private Peripheral
Interrupts should use "GIC_CPU_MASK_SIMPLE(8)", to make sure interrupts
can be delivered to all 8 processor cores.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v3:
- Change one-line summary prefix to match current arm-soc practices,
- Rebase,
v2:
- Drop RFC status after receiving confirmation from Liviu Dudau.
---
arch/arm/boot/dts/r8a7790.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index b66a18af28f1659a..47a51cd71434e7d2 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1554,7 +1554,7 @@
interrupt-controller;
reg = <0 0xf1001000 0 0x1000>, <0 0xf1002000 0 0x2000>,
<0 0xf1004000 0 0x2000>, <0 0xf1006000 0 0x2000>;
- interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
clocks = <&cpg CPG_MOD 408>;
clock-names = "clk";
power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
@@ -1810,10 +1810,10 @@
timer {
compatible = "arm,armv7-timer";
- interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
};
/* External USB clock - can be overridden by the board */
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/2] ARM: dts: renesas: Correct mask for GIC PPI interrupts
From: Geert Uytterhoeven @ 2018-05-07 13:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon, Magnus,
R-Car H2 and R-Mobile APE6 contain four Cortex-A15 and four Cortex-A7
cores, hence the second interrupt specifier cell for Private Peripheral
Interrupts should use "GIC_CPU_MASK_SIMPLE(8)", to make sure interrupts
can be delivered to all 8 processor cores.
This brings the predecessors of R-Car Gen3 in line with what we're doing
on other big.LITTLE SoCs, like R-Car H3 and M3-W.
Changes compared to v2:
- Change one-line summary prefix to match current arm-soc practices,
- Fast-forward by 3 years,
- Rebase.
Changes compared to v1:
- Drop RFC status after receiving confirmation from Liviu Dudau.
Thanks for applying!
P.S. Feel free to take a ride on your unicorn, to test on a legendary
system that boots all 8 cores.
Geert Uytterhoeven (2):
ARM: dts: r8a7790: Correct mask for GIC PPI interrupts
ARM: dts: r8a73a4: Correct mask for GIC PPI interrupts
arch/arm/boot/dts/r8a73a4.dtsi | 10 +++++-----
arch/arm/boot/dts/r8a7790.dtsi | 10 +++++-----
2 files changed, 10 insertions(+), 10 deletions(-)
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Andrzej Hajda @ 2018-05-07 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504135212.26977-27-peda@axentia.se>
On 04.05.2018 15:52, Peter Rosin wrote:
> If the bridge supplier is unbound, this will bring the bridge consumer
> down along with the bridge. Thus, there will no longer linger any
> dangling pointers from the bridge consumer (the drm_device) to some
> non-existent bridge supplier.
I understand rationales behind this patch, but it is another step into
making drm_dev one big driver with subcomponents, where drm will work
only if every subcomponent is working/loaded. Do we need to go this way?
In case of many platforms such approach results in display turned on
very late on boot for example due to late initialization of some
regulator exposed by some i2c device, which is used by hdmi bridge. And
this hdmi bridge is just to provide alternative(rarely used) display
path, the main display path would work anyway.
So the main question to drm maintainers is about evolution of bridges,
if drm_bridges should become mandatory components of drm device or they
could be added/removed dynamically?
Regards
Andrzej
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
> include/drm/drm_bridge.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 78d186b6831b..0259f0a3ff27 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -26,6 +26,7 @@
> #include <linux/mutex.h>
>
> #include <drm/drm_bridge.h>
> +#include <drm/drm_device.h>
> #include <drm/drm_encoder.h>
>
> #include "drm_crtc_internal.h"
> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
> if (bridge->dev)
> return -EBUSY;
>
> + if (encoder->dev->dev != bridge->odev) {
> + bridge->link = device_link_add(encoder->dev->dev,
> + bridge->odev, 0);
> + if (!bridge->link) {
> + dev_err(bridge->odev, "failed to link bridge to %s\n",
> + dev_name(encoder->dev->dev));
> + return -EINVAL;
> + }
> + }
> +
> bridge->dev = encoder->dev;
> bridge->encoder = encoder;
>
> if (bridge->funcs->attach) {
> ret = bridge->funcs->attach(bridge);
> if (ret < 0) {
> + if (bridge->link)
> + device_link_del(bridge->link);
> + bridge->link = NULL;
> bridge->dev = NULL;
> bridge->encoder = NULL;
> return ret;
> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> if (bridge->funcs->detach)
> bridge->funcs->detach(bridge);
>
> + if (bridge->link)
> + device_link_del(bridge->link);
> + bridge->link = NULL;
> +
> bridge->dev = NULL;
> }
>
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index b656e505d11e..804189c63a4c 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> * @list: to keep track of all added bridges
> * @timings: the timing specification for the bridge, if any (may
> * be NULL)
> + * @link: drm consumer <-> bridge supplier
> * @funcs: control functions
> * @driver_private: pointer to the bridge driver's internal context
> */
> @@ -271,6 +272,7 @@ struct drm_bridge {
> struct drm_bridge *next;
> struct list_head list;
> const struct drm_bridge_timings *timings;
> + struct device_link *link;
>
> const struct drm_bridge_funcs *funcs;
> void *driver_private;
^ permalink raw reply
* [PATCH] clk: imx6ull: use OSC clock during AXI rate change
From: Stefan Agner @ 2018-05-07 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502073807.GE3443@dragon>
Hi Jacky,
On 02.05.2018 09:38, Shawn Guo wrote:
> Hi Jacky,
>
> Do you see this problem on i.MX6 ULL? What's your take on Stefan's fix?
Any comment to this?
It is 4.17.0-rc4 is out and i.MX 6ULL is still broken :-(
--
Stefan
>
> Shawn
>
> On Wed, Apr 18, 2018 at 02:49:08PM +0200, Stefan Agner wrote:
>> On i.MX6 ULL using PLL3 seems to cause a freeze when setting
>> the parent to IMX6UL_CLK_PLL3_USB_OTG. This only seems to appear
>> since commit 6f9575e55632 ("clk: imx: Add CLK_IS_CRITICAL flag
>> for busy divider and busy mux"), probably because the clock is
>> now forced to be on.
>>
>> Fixes: 6f9575e55632("clk: imx: Add CLK_IS_CRITICAL flag for busy divider and busy mux")
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> ---
>> This addresses a regression ssen on v4.17-rc1 where the kernel
>> boots during clock initialization, see also:
>> https://patchwork.kernel.org/patch/10295927/
>>
>> drivers/clk/imx/clk-imx6ul.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
>> index 114ecbb94ec5..12320118f8de 100644
>> --- a/drivers/clk/imx/clk-imx6ul.c
>> +++ b/drivers/clk/imx/clk-imx6ul.c
>> @@ -464,7 +464,7 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
>> clk_set_rate(clks[IMX6UL_CLK_AHB], 99000000);
>>
>> /* Change periph_pre clock to pll2_bus to adjust AXI rate to 264MHz */
>> - clk_set_parent(clks[IMX6UL_CLK_PERIPH_CLK2_SEL], clks[IMX6UL_CLK_PLL3_USB_OTG]);
>> + clk_set_parent(clks[IMX6UL_CLK_PERIPH_CLK2_SEL], clks[IMX6UL_CLK_OSC]);
>> clk_set_parent(clks[IMX6UL_CLK_PERIPH], clks[IMX6UL_CLK_PERIPH_CLK2]);
>> clk_set_parent(clks[IMX6UL_CLK_PERIPH_PRE], clks[IMX6UL_CLK_PLL2_BUS]);
>> clk_set_parent(clks[IMX6UL_CLK_PERIPH], clks[IMX6UL_CLK_PERIPH_PRE]);
>> --
>> 2.17.0
>>
^ permalink raw reply
* [GIT PULL] tee driver fixes for v4.17
From: Jens Wiklander @ 2018-05-07 12:47 UTC (permalink / raw)
To: linux-arm-kernel
Hello arm-soc maintainers,
Please pull these tee driver fixes. Of particular interest is a fix for a
use-after-free issue. There's also a fix making sure that memory references
are kept within the used shm object.
Thanks,
Jens
The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb:
Linux 4.17-rc4 (2018-05-06 16:57:38 -1000)
are available in the Git repository at:
git://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/tee-drv-fixes-for-4.17
for you to fetch changes up to ab9d3db5b320a052452b9cd035599ee3c84bbee9:
tee: check shm references are consistent in offset/size (2018-05-07 11:51:03 +0200)
----------------------------------------------------------------
Small fixes for tee subsystem
* Fixes for use-after-free via temporarily dropped reference
* Checks that passed shm references are consistent in offset/size
with regards to the shm object
----------------------------------------------------------------
Etienne Carriere (1):
tee: check shm references are consistent in offset/size
Jann Horn (1):
tee: shm: fix use-after-free via temporarily dropped reference
drivers/tee/tee_core.c | 11 +++++++++++
drivers/tee/tee_shm.c | 5 +++--
2 files changed, 14 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH v3 14/14] ARM: dts: sun8i-a33: Add Video Engine and reserved memory nodes
From: Paul Kocialkowski @ 2018-05-07 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507124500.20434-1-paul.kocialkowski@bootlin.com>
This adds nodes for the Video Engine and the associated reserved memory
for the A33. Up to 96 MiB of memory are dedicated to the CMA pool.
The VPU can only map the first 256 MiB of DRAM, so the reserved memory
pool has to be located in that area. Following Allwinner's decision in
downstream software, the last 96 MiB of the first 256 MiB of RAM are
reserved for this purpose.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
arch/arm/boot/dts/sun8i-a33.dtsi | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 97a976b3b1ef..5308a49601f6 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -181,6 +181,21 @@
reg = <0x40000000 0x80000000>;
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
+ cma_pool: cma at 4a000000 {
+ compatible = "shared-dma-pool";
+ size = <0x6000000>;
+ alloc-ranges = <0x4a000000 0x6000000>;
+ reusable;
+ linux,cma-default;
+ };
+ };
+
sound: sound {
compatible = "simple-audio-card";
simple-audio-card,name = "sun8i-a33-audio";
@@ -262,6 +277,23 @@
};
};
+ vpu: video-codec at 01c0e000 {
+ compatible = "allwinner,sun8i-a33-video-engine";
+ reg = <0x01c0e000 0x1000>;
+
+ clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
+ <&ccu CLK_DRAM_VE>;
+ clock-names = "ahb", "mod", "ram";
+
+ assigned-clocks = <&ccu CLK_VE>;
+ assigned-clock-rates = <320000000>;
+
+ resets = <&ccu RST_BUS_VE>;
+
+ interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
+ allwinner,sram = <&ve_sram 1>;
+ };
+
crypto: crypto-engine at 1c15000 {
compatible = "allwinner,sun4i-a10-crypto";
reg = <0x01c15000 0x1000>;
--
2.16.3
^ permalink raw reply related
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