* [PATCH v3 0/2] gpu: drm/panel: Add DLC DLC0700YZG-1 support
From: Marco Felsch @ 2018-05-23 9:25 UTC (permalink / raw)
To: thierry.reding, robh+dt, mark.rutland; +Cc: devicetree, kernel, dri-devel
This serie adds support for the DLC Display Co. DLC0700YZG-1 7.0" WSVGA
TFT LCD panel. The customer isn't listed as vendor so we have to add the
vendor prefix too.
Philipp Zabel (2):
dt-bindings: Add vendor prefix for DLC Display Co., Ltd.
gpu: drm/panel: Add DLC DLC0700YZG-1 panel
.../display/panel/dlc,dlc0700yzg-1.txt | 7 ++++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/gpu/drm/panel/panel-simple.c | 32 +++++++++++++++++++
3 files changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt
--
2.17.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: Add vendor prefix for DLC Display Co., Ltd.
From: Marco Felsch @ 2018-05-23 9:25 UTC (permalink / raw)
To: thierry.reding, robh+dt, mark.rutland; +Cc: devicetree, kernel, dri-devel
In-Reply-To: <20180523092504.5142-1-m.felsch@pengutronix.de>
From: Philipp Zabel <p.zabel@pengutronix.de>
DLC provides a wide range of display solutions.
Website: http://www.dlcdisplay.com/
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index b5f978a4cac6..52de5eed11bf 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -89,6 +89,7 @@ dh DH electronics GmbH
digi Digi International Inc.
digilent Diglent, Inc.
dioo Dioo Microcircuit Co., Ltd
+dlc DLC Display Co., Ltd.
dlg Dialog Semiconductor
dlink D-Link Corporation
dmo Data Modul AG
--
2.17.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v3 2/2] gpu: drm/panel: Add DLC DLC0700YZG-1 panel
From: Marco Felsch @ 2018-05-23 9:25 UTC (permalink / raw)
To: thierry.reding, robh+dt, mark.rutland; +Cc: devicetree, kernel, dri-devel
In-Reply-To: <20180523092504.5142-1-m.felsch@pengutronix.de>
From: Philipp Zabel <p.zabel@pengutronix.de>
This patch adds support for DLC DLC0700YZG-1 1024x600 LVDS panels
to the simple-panel driver.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
[m.felsch@pengutronix.de: fix typo in compatible dt-binding]
[m.felsch@pengutronix.de: add property bindings]
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
.../display/panel/dlc,dlc0700yzg-1.txt | 13 ++++++++
drivers/gpu/drm/panel/panel-simple.c | 32 +++++++++++++++++++
2 files changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt
diff --git a/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt
new file mode 100644
index 000000000000..bf06bb025b08
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt
@@ -0,0 +1,13 @@
+DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "dlc,dlc0700yzg-1"
+- power-supply: See simple-panel.txt
+
+Optional properties:
+- reset-gpios: See panel-common.txt
+- enable-gpios: See simple-panel.txt
+- backlight: See simple-panel.txt
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..a916754b2afa 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -857,6 +857,35 @@ static const struct panel_desc chunghwa_claa101wb01 = {
},
};
+static const struct display_timing dlc_dlc0700yzg_1_timing = {
+ .pixelclock = { 45000000, 51200000, 57000000 },
+ .hactive = { 1024, 1024, 1024 },
+ .hfront_porch = { 100, 106, 113 },
+ .hback_porch = { 100, 106, 113 },
+ .hsync_len = { 100, 108, 114 },
+ .vactive = { 600, 600, 600 },
+ .vfront_porch = { 8, 11, 15 },
+ .vback_porch = { 8, 11, 15 },
+ .vsync_len = { 9, 13, 15 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc dlc_dlc0700yzg_1 = {
+ .timings = &dlc_dlc0700yzg_1_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .delay = {
+ .prepare = 30,
+ .enable = 200,
+ .disable = 200,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
static const struct drm_display_mode edt_et057090dhu_mode = {
.clock = 25175,
.hdisplay = 640,
@@ -2124,6 +2153,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "chunghwa,claa101wb01",
.data = &chunghwa_claa101wb01
+ }, {
+ .compatible = "dlc,dlc0700yzg-1",
+ .data = &dlc_dlc0700yzg_1,
}, {
.compatible = "edt,et057090dhu",
.data = &edt_et057090dhu,
--
2.17.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH RFC 00/24] Lima DRM driver
From: Christian König @ 2018-05-23 9:29 UTC (permalink / raw)
To: Qiang Yu, dri-devel, devicetree
Cc: Simon Shields, Marek Vasut, Connor Abbott, Neil Armstrong,
Andrei Paulau, Vasily Khoruzhick, Erico Nunes
In-Reply-To: <20180518092815.25280-1-yuq825@gmail.com>
Am 18.05.2018 um 11:27 schrieb Qiang Yu:
> Kernel DRM driver for ARM Mali 400/450 GPUs.
>
> This implementation mainly take amdgpu DRM driver as reference.
>
> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
> OpenGL vertex shader processing and PP is for fragment shader
> processing. Each processor has its own MMU so prcessors work in
> virtual address space.
> - There's only one GP but multiple PP (max 4 for mali 400 and 8
> for mali 450) in the same mali 4xx GPU. All PPs are grouped
> togather to handle a single fragment shader task divided by
> FB output tiled pixels. Mali 400 user space driver is
> responsible for assign target tiled pixels to each PP, but mali
> 450 has a HW module called DLBU to dynamically balance each
> PP's load.
> - User space driver allocate buffer object and map into GPU
> virtual address space, upload command stream and draw data with
> CPU mmap of the buffer object, then submit task to GP/PP with
> a register frame indicating where is the command stream and misc
> settings.
> - There's no command stream validation/relocation due to each user
> process has its own GPU virtual address space. GP/PP's MMU switch
> virtual address space before running two tasks from different
> user process. Error or evil user space code just get MMU fault
> or GP/PP error IRQ, then the HW/SW will be recovered.
> - Use TTM as MM. TTM_PL_TT type memory is used as the content of
> lima buffer object which is allocated from TTM page pool. all
> lima buffer object gets pinned with TTM_PL_FLAG_NO_EVICT when
> allocation, so there's no buffer eviction and swap for now. We
> need reverse engineering to see if and how GP/PP support MMU
> fault recovery (continue execution). Otherwise we have to
> pin/unpin each envolved buffer when task creation/deletion.
Well pinning all memory is usually a no-go for upstreaming. But since
you are already using the drm_sched for GPU task scheduling why are you
actually needing this?
The scheduler should take care of signaling all fences when the hardware
is done with it's magic and that is enough for TTM to note that a buffer
object is movable again (e.g. unpin them).
Christian.
> - Use drm_sched for GPU task schedule. Each OpenGL context should
> have a lima context object in the kernel to distinguish tasks
> from different user. drm_sched gets task from each lima context
> in a fair way.
>
> Not implemented:
> - Dump buffer support
> - Power management
> - Performance counter
>
> This patch serial just pack a pair of .c/.h files in each patch.
> For whole history of this driver's development, see:
> https://github.com/yuq/linux-lima/commits/lima-4.17-rc4
>
> Mesa driver is still in development and not ready for daily usage,
> but can run some simple tests like kmscube and glamrk2, see:
> https://github.com/yuq/mesa-lima
>
> Andrei Paulau (1):
> arm64/dts: add switch-delay for meson mali
>
> Lima Project Developers (10):
> drm/lima: add mali 4xx GPU hardware regs
> drm/lima: add lima core driver
> drm/lima: add GPU device functions
> drm/lima: add PMU related functions
> drm/lima: add PP related functions
> drm/lima: add MMU related functions
> drm/lima: add GPU virtual memory space handing
> drm/lima: add GEM related functions
> drm/lima: add GEM Prime related functions
> drm/lima: add makefile and kconfig
>
> Qiang Yu (12):
> dt-bindings: add switch-delay property for mali-utgard
> arm64/dts: add switch-delay for meson mali
> Revert "drm: Nerf the preclose callback for modern drivers"
> drm/lima: add lima uapi header
> drm/lima: add L2 cache functions
> drm/lima: add GP related functions
> drm/lima: add BCAST related function
> drm/lima: add DLBU related functions
> drm/lima: add TTM subsystem functions
> drm/lima: add buffer object functions
> drm/lima: add GPU schedule using DRM_SCHED
> drm/lima: add context related functions
>
> Simon Shields (1):
> ARM: dts: add gpu node to exynos4
>
> .../bindings/gpu/arm,mali-utgard.txt | 4 +
> arch/arm/boot/dts/exynos4.dtsi | 33 ++
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 1 +
> .../boot/dts/amlogic/meson-gxl-mali.dtsi | 1 +
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_file.c | 8 +-
> drivers/gpu/drm/lima/Kconfig | 9 +
> drivers/gpu/drm/lima/Makefile | 19 +
> drivers/gpu/drm/lima/lima_bcast.c | 65 +++
> drivers/gpu/drm/lima/lima_bcast.h | 34 ++
> drivers/gpu/drm/lima/lima_ctx.c | 143 +++++
> drivers/gpu/drm/lima/lima_ctx.h | 51 ++
> drivers/gpu/drm/lima/lima_device.c | 407 ++++++++++++++
> drivers/gpu/drm/lima/lima_device.h | 136 +++++
> drivers/gpu/drm/lima/lima_dlbu.c | 75 +++
> drivers/gpu/drm/lima/lima_dlbu.h | 37 ++
> drivers/gpu/drm/lima/lima_drv.c | 466 ++++++++++++++++
> drivers/gpu/drm/lima/lima_drv.h | 77 +++
> drivers/gpu/drm/lima/lima_gem.c | 459 ++++++++++++++++
> drivers/gpu/drm/lima/lima_gem.h | 41 ++
> drivers/gpu/drm/lima/lima_gem_prime.c | 66 +++
> drivers/gpu/drm/lima/lima_gem_prime.h | 31 ++
> drivers/gpu/drm/lima/lima_gp.c | 293 +++++++++++
> drivers/gpu/drm/lima/lima_gp.h | 34 ++
> drivers/gpu/drm/lima/lima_l2_cache.c | 98 ++++
> drivers/gpu/drm/lima/lima_l2_cache.h | 32 ++
> drivers/gpu/drm/lima/lima_mmu.c | 154 ++++++
> drivers/gpu/drm/lima/lima_mmu.h | 34 ++
> drivers/gpu/drm/lima/lima_object.c | 120 +++++
> drivers/gpu/drm/lima/lima_object.h | 87 +++
> drivers/gpu/drm/lima/lima_pmu.c | 85 +++
> drivers/gpu/drm/lima/lima_pmu.h | 30 ++
> drivers/gpu/drm/lima/lima_pp.c | 418 +++++++++++++++
> drivers/gpu/drm/lima/lima_pp.h | 37 ++
> drivers/gpu/drm/lima/lima_regs.h | 304 +++++++++++
> drivers/gpu/drm/lima/lima_sched.c | 497 ++++++++++++++++++
> drivers/gpu/drm/lima/lima_sched.h | 126 +++++
> drivers/gpu/drm/lima/lima_ttm.c | 409 ++++++++++++++
> drivers/gpu/drm/lima/lima_ttm.h | 44 ++
> drivers/gpu/drm/lima/lima_vm.c | 312 +++++++++++
> drivers/gpu/drm/lima/lima_vm.h | 73 +++
> include/drm/drm_drv.h | 23 +-
> include/uapi/drm/lima_drm.h | 195 +++++++
> 44 files changed, 5565 insertions(+), 6 deletions(-)
> create mode 100644 drivers/gpu/drm/lima/Kconfig
> create mode 100644 drivers/gpu/drm/lima/Makefile
> create mode 100644 drivers/gpu/drm/lima/lima_bcast.c
> create mode 100644 drivers/gpu/drm/lima/lima_bcast.h
> create mode 100644 drivers/gpu/drm/lima/lima_ctx.c
> create mode 100644 drivers/gpu/drm/lima/lima_ctx.h
> create mode 100644 drivers/gpu/drm/lima/lima_device.c
> create mode 100644 drivers/gpu/drm/lima/lima_device.h
> create mode 100644 drivers/gpu/drm/lima/lima_dlbu.c
> create mode 100644 drivers/gpu/drm/lima/lima_dlbu.h
> create mode 100644 drivers/gpu/drm/lima/lima_drv.c
> create mode 100644 drivers/gpu/drm/lima/lima_drv.h
> create mode 100644 drivers/gpu/drm/lima/lima_gem.c
> create mode 100644 drivers/gpu/drm/lima/lima_gem.h
> create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.c
> create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.h
> create mode 100644 drivers/gpu/drm/lima/lima_gp.c
> create mode 100644 drivers/gpu/drm/lima/lima_gp.h
> create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.c
> create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.h
> create mode 100644 drivers/gpu/drm/lima/lima_mmu.c
> create mode 100644 drivers/gpu/drm/lima/lima_mmu.h
> create mode 100644 drivers/gpu/drm/lima/lima_object.c
> create mode 100644 drivers/gpu/drm/lima/lima_object.h
> create mode 100644 drivers/gpu/drm/lima/lima_pmu.c
> create mode 100644 drivers/gpu/drm/lima/lima_pmu.h
> create mode 100644 drivers/gpu/drm/lima/lima_pp.c
> create mode 100644 drivers/gpu/drm/lima/lima_pp.h
> create mode 100644 drivers/gpu/drm/lima/lima_regs.h
> create mode 100644 drivers/gpu/drm/lima/lima_sched.c
> create mode 100644 drivers/gpu/drm/lima/lima_sched.h
> create mode 100644 drivers/gpu/drm/lima/lima_ttm.c
> create mode 100644 drivers/gpu/drm/lima/lima_ttm.h
> create mode 100644 drivers/gpu/drm/lima/lima_vm.c
> create mode 100644 drivers/gpu/drm/lima/lima_vm.h
> create mode 100644 include/uapi/drm/lima_drm.h
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH] ARM: dts: stm32: Add DFSDM support to stm32mp157c
From: Fabrice Gasnier @ 2018-05-23 9:30 UTC (permalink / raw)
To: alexandre.torgue
Cc: mark.rutland, devicetree, arnaud.pouliquen, linux-kernel, robh+dt,
mcoquelin.stm32, fabrice.gasnier, linux-arm-kernel
stm32mp157c has DFSDM (Digital Filter For Sigma Delta Modulators) hardware
with 6 filter instances.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
---
arch/arm/boot/dts/stm32mp157c.dtsi | 70 ++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
index 66d7496..3d2f4e7 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -556,6 +556,76 @@
};
};
+ dfsdm: dfsdm@4400d000 {
+ compatible = "st,stm32mp1-dfsdm";
+ reg = <0x4400d000 0x800>;
+ clocks = <&rcc DFSDM_K>;
+ clock-names = "dfsdm";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ dfsdm0: filter@0 {
+ compatible = "st,stm32-dfsdm-adc";
+ #io-channel-cells = <1>;
+ reg = <0>;
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmamux1 101 0x400 0x01>;
+ dma-names = "rx";
+ status = "disabled";
+ };
+
+ dfsdm1: filter@1 {
+ compatible = "st,stm32-dfsdm-adc";
+ #io-channel-cells = <1>;
+ reg = <1>;
+ interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmamux1 102 0x400 0x01>;
+ dma-names = "rx";
+ status = "disabled";
+ };
+
+ dfsdm2: filter@2 {
+ compatible = "st,stm32-dfsdm-adc";
+ #io-channel-cells = <1>;
+ reg = <2>;
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmamux1 103 0x400 0x01>;
+ dma-names = "rx";
+ status = "disabled";
+ };
+
+ dfsdm3: filter@3 {
+ compatible = "st,stm32-dfsdm-adc";
+ #io-channel-cells = <1>;
+ reg = <3>;
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmamux1 104 0x400 0x01>;
+ dma-names = "rx";
+ status = "disabled";
+ };
+
+ dfsdm4: filter@4 {
+ compatible = "st,stm32-dfsdm-adc";
+ #io-channel-cells = <1>;
+ reg = <4>;
+ interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmamux1 91 0x400 0x01>;
+ dma-names = "rx";
+ status = "disabled";
+ };
+
+ dfsdm5: filter@5 {
+ compatible = "st,stm32-dfsdm-adc";
+ #io-channel-cells = <1>;
+ reg = <5>;
+ interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmamux1 92 0x400 0x01>;
+ dma-names = "rx";
+ status = "disabled";
+ };
+ };
+
dma1: dma@48000000 {
compatible = "st,stm32-dma";
reg = <0x48000000 0x400>;
--
1.9.1
^ permalink raw reply related
* [PATCH v5 0/7] Add tda998x (HDMI) support to atmel-hlcdc
From: Peter Rosin @ 2018-05-23 9:31 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, David Airlie, Rob Herring, Mark Rutland,
Nicolas Ferre, Alexandre Belloni, Boris Brezillon, Russell King,
Laurent Pinchart, dri-devel, devicetree, linux-arm-kernel,
Jyri Sarha, Daniel Vetter, Andrzej Hajda, Jacopo Mondi
Hi!
I naively thought that since there was support for both nxp,tda19988 (in
the tda998x driver) and the atmel-hlcdc, things would be a smooth ride.
But it wasn't, so I started looking around and realized I had to fix
things.
In v1 and v2 I fixed things by making the atmel-hlcdc driver a master
component, but now I fix things by making the tda998x driver a bridge
instead. This was after a suggestion from Boris Brezillon the
atmel-hlcdc maintainer), so there was some risk of bias ... but after
comparing what was needed, I too find the bridge approach more direct.
In v4, an issue was noted by Russell King in that the tda998x device
might be unbound with shattering results for the main drm device.
This is of course a real problem and it needs to be fixed. I have
submitted a series [1] that tries to do that. However, since there are
currently *10* other bridges (analogix-anx78xx, adv7511, megachips_stdp*,
nxp-ptn3460, parade-ps8622, sii902x, sii9234, sil-sii8620, tc358767 and
ti-tfp410) with exactly the same problem (they are all I2C devices that
might be unexpectedly unbound without safety-net, at least that is how I
read it), I think it should be ok to add one more and then fix them all
instead of holding this series hostage. Apparently people don't go around
and unbind I2C devices all that often...
In addition to the above, our PCB interface between the SAMA5D3 and the
HDMI encoder is only using 16 bits, and this has to be described
somewhere, or the atmel-hlcdc driver have no chance of selecting the
correct output mode. Since I have similar problems with a ds90c185 lvds
encoder I added patches to override the atmel-hlcdc output format via
DT properties compatible with the media video-interface binding and
things start to play together.
Anyway, this series solves some real issues for my HW.
Also, is it perhaps possible that patches 1-3 can be taken independently
from 4-7? There is no hard dependency between the two parts of this series.
Patches 1-3 have the relevant tags and should be uncontroversial...
Cheers,
Peter
Changes since v4 https://lkml.org/lkml/2018/4/23/92
- added reviewed-by from Rob to patch 2/7
- dropped patch 8, since the issue noted by Russell King is not present
when working with components as tilcdc currently do when handling tda998x
Changes since v3 https://lkml.org/lkml/2018/4/19/736
- moved the meat of the drm_of_media_bus_fmt function from patch 3/7
to a driver-local atmel_hlcdc_of_bus_fmt function, and squashed with
patch 4/7 (this is now patch 3/8).
- patch 3/8 now parses and stores the DT bus format together with the
encoder in a reintroduced struct atmel_hlcdc_rgb_output instead of
allocating a separate encoder-indexed array for the bus formats.
- patch 5/8 is new and splits tda988x_encoder_dpms into a pair of
functions to enable/disable separately. This fits better with both
the current code and for the followup drm_bridge patch (7/8).
- adjust patch 6/8 and 7/8 to the above simplification.
- added patch 8/8 that removes component master code from tilcdc.
Changes since v2 https://lkml.org/lkml/2018/4/17/385
- patch 2/7 fixed spelling and added an example
- patch 4/7 parse the DT up front and store the result indexed by encoder
- old patch 5/6 and 6/6 dropped
- patch 5-7/7 are new and makes the tda998x driver a drm_bridge
Changes since v1 https://lkml.org/lkml/2018/4/9/294
- added reviewed-by from Rob to patch 1/6
- patch 2/6 changed so that the bus format override is in the endpoint
DT node, and follows the binding of media video-interfaces.
- patch 3/6 is new, it adds drm_of_media_bus_fmt which parses above
media video-interface binding (partially).
- patch 4/6 now makes use of the above helper (and also fixes problems
with the 3/5 patch from v1 when no override was specified).
- do not mention unrelated connector display_info details in the cover
letter and commit messages.
[1] https://lkml.org/lkml/2018/5/16/380
Peter Rosin (7):
dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185
dt-bindings: display: atmel: optional video-interface of endpoints
drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes
drm/i2c: tda998x: find the drm_device via the drm_connector
drm/i2c: tda998x: split tda998x_encoder_dpms into enable/disable
drm/i2c: tda998x: split encoder and component functions from the work
drm/i2c: tda998x: register as a drm bridge
.../devicetree/bindings/display/atmel/hlcdc-dc.txt | 26 ++
.../bindings/display/bridge/lvds-transmitter.txt | 8 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 70 ++++--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 1 +
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 67 +++++-
drivers/gpu/drm/i2c/tda998x_drv.c | 268 ++++++++++++++++-----
6 files changed, 351 insertions(+), 89 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH v5 1/7] dt-bindings: display: bridge: lvds-transmitter: add ti, ds90c185
From: Peter Rosin @ 2018-05-23 9:31 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Alexandre Belloni, Andrzej Hajda,
David Airlie, Jyri Sarha, dri-devel, Russell King,
Boris Brezillon, Rob Herring, Jacopo Mondi, Laurent Pinchart,
Daniel Vetter, Peter Rosin, linux-arm-kernel
In-Reply-To: <20180523093122.27859-1-peda@axentia.se>
Start list of actual chips compatible with "lvds-encoder".
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../devicetree/bindings/display/bridge/lvds-transmitter.txt | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index fd39ad34c383..50220190c203 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -22,7 +22,13 @@ among others.
Required properties:
-- compatible: Must be "lvds-encoder"
+- compatible: Must be one or more of the following
+ - "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer
+ - "lvds-encoder" for a generic LVDS encoder device
+
+ When compatible with the generic version, nodes must list the
+ device-specific version corresponding to the device first
+ followed by the generic version.
Required nodes:
--
2.11.0
^ permalink raw reply related
* [PATCH v5 2/7] dt-bindings: display: atmel: optional video-interface of endpoints
From: Peter Rosin @ 2018-05-23 9:31 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, David Airlie, Rob Herring, Mark Rutland,
Nicolas Ferre, Alexandre Belloni, Boris Brezillon, Russell King,
Laurent Pinchart, dri-devel, devicetree, linux-arm-kernel,
Jyri Sarha, Daniel Vetter, Andrzej Hajda, Jacopo Mondi
In-Reply-To: <20180523093122.27859-1-peda@axentia.se>
With bus-type/bus-width properties in the endpoint nodes, the video-
interface of the connection can be specified for cases where the
heuristic fails to select the correct output mode. This can happen
e.g. if not all RGB pins are routed on the PCB; the driver has no
way of knowing this, and needs to be told explicitly.
This is critical for the devices that have the "conflicting output
formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
RGB bits move around depending on the selected output mode. For
devices that do not have the "conflicting output formats" issue
(SAMA5D2, SAMA5D4), this is completely irrelevant.
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../devicetree/bindings/display/atmel/hlcdc-dc.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
index 82f2acb3d374..9de434a8f523 100644
--- a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
+++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
@@ -15,6 +15,14 @@ Required children nodes:
to external devices using the OF graph reprensentation (see ../graph.txt).
At least one port node is required.
+Optional properties in grandchild nodes:
+ Any endpoint grandchild node may specify a desired video interface
+ according to ../../media/video-interfaces.txt, specifically
+ - bus-type: must be <0>.
+ - bus-width: recognized values are <12>, <16>, <18> and <24>, and
+ override any output mode selection heuristic, forcing "rgb444",
+ "rgb565", "rgb666" and "rgb888" respectively.
+
Example:
hlcdc: hlcdc@f0030000 {
@@ -50,3 +58,21 @@ Example:
#pwm-cells = <3>;
};
};
+
+
+Example 2: With a video interface override to force rgb565; as above
+but with these changes/additions:
+
+ &hlcdc {
+ hlcdc-display-controller {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb565>;
+
+ port@0 {
+ hlcdc_panel_output: endpoint@0 {
+ bus-type = <0>;
+ bus-width = <16>;
+ };
+ };
+ };
+ };
--
2.11.0
^ permalink raw reply related
* [PATCH v5 3/7] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes
From: Peter Rosin @ 2018-05-23 9:31 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, David Airlie, Rob Herring, Mark Rutland,
Nicolas Ferre, Alexandre Belloni, Boris Brezillon, Russell King,
Laurent Pinchart, dri-devel, devicetree, linux-arm-kernel,
Jyri Sarha, Daniel Vetter, Andrzej Hajda, Jacopo Mondi
In-Reply-To: <20180523093122.27859-1-peda@axentia.se>
This beats the heuristic that the connector is involved in what format
should be output for cases where this fails.
E.g. if there is a bridge that changes format between the encoder and the
connector, or if some of the RGB pins between the lcd controller and the
encoder are not routed on the PCB.
This is critical for the devices that have the "conflicting output
formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
RGB bits move around depending on the selected output mode. For
devices that do not have the "conflicting output formats" issue
(SAMA5D2, SAMA5D4), this is completely irrelevant.
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 70 +++++++++++++++++-------
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 1 +
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 67 ++++++++++++++++++++---
3 files changed, 111 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index d73281095fac..c38a479ada98 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -226,6 +226,55 @@ static void atmel_hlcdc_crtc_atomic_enable(struct drm_crtc *c,
#define ATMEL_HLCDC_RGB888_OUTPUT BIT(3)
#define ATMEL_HLCDC_OUTPUT_MODE_MASK GENMASK(3, 0)
+static int atmel_hlcdc_connector_output_mode(struct drm_connector_state *state)
+{
+ struct drm_connector *connector = state->connector;
+ struct drm_display_info *info = &connector->display_info;
+ struct drm_encoder *encoder;
+ unsigned int supported_fmts = 0;
+ int j;
+
+ encoder = state->best_encoder;
+ if (!encoder)
+ encoder = connector->encoder;
+
+ switch (atmel_hlcdc_encoder_get_bus_fmt(encoder)) {
+ case 0:
+ break;
+ case MEDIA_BUS_FMT_RGB444_1X12:
+ return ATMEL_HLCDC_RGB444_OUTPUT;
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ return ATMEL_HLCDC_RGB565_OUTPUT;
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ return ATMEL_HLCDC_RGB666_OUTPUT;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ return ATMEL_HLCDC_RGB888_OUTPUT;
+ default:
+ return -EINVAL;
+ }
+
+ for (j = 0; j < info->num_bus_formats; j++) {
+ switch (info->bus_formats[j]) {
+ case MEDIA_BUS_FMT_RGB444_1X12:
+ supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
+ break;
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
+ break;
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
+ break;
+ default:
+ break;
+ }
+ }
+
+ return supported_fmts;
+}
+
static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
{
unsigned int output_fmts = ATMEL_HLCDC_OUTPUT_MODE_MASK;
@@ -238,31 +287,12 @@ static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
for_each_new_connector_in_state(state->state, connector, cstate, i) {
- struct drm_display_info *info = &connector->display_info;
unsigned int supported_fmts = 0;
- int j;
if (!cstate->crtc)
continue;
- for (j = 0; j < info->num_bus_formats; j++) {
- switch (info->bus_formats[j]) {
- case MEDIA_BUS_FMT_RGB444_1X12:
- supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
- break;
- case MEDIA_BUS_FMT_RGB565_1X16:
- supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
- break;
- case MEDIA_BUS_FMT_RGB666_1X18:
- supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
- break;
- case MEDIA_BUS_FMT_RGB888_1X24:
- supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
- break;
- default:
- break;
- }
- }
+ supported_fmts = atmel_hlcdc_connector_output_mode(cstate);
if (crtc->dc->desc->conflicting_output_formats)
output_fmts &= supported_fmts;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 60c937f42114..4cc1e03f0aee 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -441,5 +441,6 @@ void atmel_hlcdc_crtc_irq(struct drm_crtc *c);
int atmel_hlcdc_crtc_create(struct drm_device *dev);
int atmel_hlcdc_create_outputs(struct drm_device *dev);
+int atmel_hlcdc_encoder_get_bus_fmt(struct drm_encoder *encoder);
#endif /* DRM_ATMEL_HLCDC_H */
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 8db51fb131db..db4d6aaaef93 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -27,33 +27,86 @@
#include "atmel_hlcdc_dc.h"
+struct atmel_hlcdc_rgb_output {
+ struct drm_encoder encoder;
+ int bus_fmt;
+};
+
static const struct drm_encoder_funcs atmel_hlcdc_panel_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
+static struct atmel_hlcdc_rgb_output *
+atmel_hlcdc_encoder_to_rgb_output(struct drm_encoder *encoder)
+{
+ return container_of(encoder, struct atmel_hlcdc_rgb_output, encoder);
+}
+
+int atmel_hlcdc_encoder_get_bus_fmt(struct drm_encoder *encoder)
+{
+ struct atmel_hlcdc_rgb_output *output;
+
+ output = atmel_hlcdc_encoder_to_rgb_output(encoder);
+
+ return output->bus_fmt;
+}
+
+static int atmel_hlcdc_of_bus_fmt(struct device_node *ep)
+{
+ u32 bus_width = 0;
+
+ of_property_read_u32(ep, "bus-width", &bus_width);
+
+ switch (bus_width) {
+ case 0:
+ return 0;
+ case 12:
+ return MEDIA_BUS_FMT_RGB444_1X12;
+ case 16:
+ return MEDIA_BUS_FMT_RGB565_1X16;
+ case 18:
+ return MEDIA_BUS_FMT_RGB666_1X18;
+ case 24:
+ return MEDIA_BUS_FMT_RGB888_1X24;
+ default:
+ return -EINVAL;
+ }
+}
+
static int atmel_hlcdc_attach_endpoint(struct drm_device *dev, int endpoint)
{
- struct drm_encoder *encoder;
+ struct atmel_hlcdc_rgb_output *output;
+ struct device_node *ep;
struct drm_panel *panel;
struct drm_bridge *bridge;
int ret;
+ ep = of_graph_get_endpoint_by_regs(dev->dev->of_node, 0, endpoint);
+ if (!ep)
+ return -ENODEV;
+
ret = drm_of_find_panel_or_bridge(dev->dev->of_node, 0, endpoint,
&panel, &bridge);
if (ret)
return ret;
- encoder = devm_kzalloc(dev->dev, sizeof(*encoder), GFP_KERNEL);
- if (!encoder)
+ output = devm_kzalloc(dev->dev, sizeof(*output), GFP_KERNEL);
+ if (!output)
return -EINVAL;
- ret = drm_encoder_init(dev, encoder,
+ output->bus_fmt = atmel_hlcdc_of_bus_fmt(ep);
+ if (output->bus_fmt < 0) {
+ dev_err(dev->dev, "invalid bus width\n");
+ return -EINVAL;
+ }
+
+ ret = drm_encoder_init(dev, &output->encoder,
&atmel_hlcdc_panel_encoder_funcs,
DRM_MODE_ENCODER_NONE, NULL);
if (ret)
return ret;
- encoder->possible_crtcs = 0x1;
+ output->encoder.possible_crtcs = 0x1;
if (panel) {
bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_Unknown);
@@ -62,7 +115,7 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device *dev, int endpoint)
}
if (bridge) {
- ret = drm_bridge_attach(encoder, bridge, NULL);
+ ret = drm_bridge_attach(&output->encoder, bridge, NULL);
if (!ret)
return 0;
@@ -70,7 +123,7 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device *dev, int endpoint)
drm_panel_bridge_remove(bridge);
}
- drm_encoder_cleanup(encoder);
+ drm_encoder_cleanup(&output->encoder);
return ret;
}
--
2.11.0
^ permalink raw reply related
* [PATCH v5 4/7] drm/i2c: tda998x: find the drm_device via the drm_connector
From: Peter Rosin @ 2018-05-23 9:31 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, David Airlie, Rob Herring, Mark Rutland,
Nicolas Ferre, Alexandre Belloni, Boris Brezillon, Russell King,
Laurent Pinchart, dri-devel, devicetree, linux-arm-kernel,
Jyri Sarha, Daniel Vetter, Andrzej Hajda, Jacopo Mondi
In-Reply-To: <20180523093122.27859-1-peda@axentia.se>
This prepares for being a drm_bridge which will not register the
encoder. That makes the connector the better choice.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index 421c8a72369e..933d309d2e0f 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -630,7 +630,7 @@ static void tda998x_detect_work(struct work_struct *work)
{
struct tda998x_priv *priv =
container_of(work, struct tda998x_priv, detect_work);
- struct drm_device *dev = priv->encoder.dev;
+ struct drm_device *dev = priv->connector.dev;
if (dev)
drm_kms_helper_hotplug_event(dev);
--
2.11.0
^ permalink raw reply related
* [PATCH v5 5/7] drm/i2c: tda998x: split tda998x_encoder_dpms into enable/disable
From: Peter Rosin @ 2018-05-23 9:31 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, David Airlie, Rob Herring, Mark Rutland,
Nicolas Ferre, Alexandre Belloni, Boris Brezillon, Russell King,
Laurent Pinchart, dri-devel, devicetree, linux-arm-kernel,
Jyri Sarha, Daniel Vetter, Andrzej Hajda, Jacopo Mondi
In-Reply-To: <20180523093122.27859-1-peda@axentia.se>
This fits better with the drm_bridge callbacks for when this
driver becomes a drm_bridge.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 64 ++++++++++++++++++++++-----------------
1 file changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index 933d309d2e0f..3dda07a2fd2f 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1163,36 +1163,42 @@ static int tda998x_connector_init(struct tda998x_priv *priv,
/* DRM encoder functions */
-static void tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
+static void tda998x_enable(struct tda998x_priv *priv)
{
- struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
- bool on;
+ if (priv->is_on)
+ return;
- /* we only care about on or off: */
- on = mode == DRM_MODE_DPMS_ON;
+ /* enable video ports, audio will be enabled later */
+ reg_write(priv, REG_ENA_VP_0, 0xff);
+ reg_write(priv, REG_ENA_VP_1, 0xff);
+ reg_write(priv, REG_ENA_VP_2, 0xff);
+ /* set muxing after enabling ports: */
+ reg_write(priv, REG_VIP_CNTRL_0, priv->vip_cntrl_0);
+ reg_write(priv, REG_VIP_CNTRL_1, priv->vip_cntrl_1);
+ reg_write(priv, REG_VIP_CNTRL_2, priv->vip_cntrl_2);
- if (on == priv->is_on)
- return;
+ priv->is_on = true;
+}
- if (on) {
- /* enable video ports, audio will be enabled later */
- reg_write(priv, REG_ENA_VP_0, 0xff);
- reg_write(priv, REG_ENA_VP_1, 0xff);
- reg_write(priv, REG_ENA_VP_2, 0xff);
- /* set muxing after enabling ports: */
- reg_write(priv, REG_VIP_CNTRL_0, priv->vip_cntrl_0);
- reg_write(priv, REG_VIP_CNTRL_1, priv->vip_cntrl_1);
- reg_write(priv, REG_VIP_CNTRL_2, priv->vip_cntrl_2);
-
- priv->is_on = true;
- } else {
- /* disable video ports */
- reg_write(priv, REG_ENA_VP_0, 0x00);
- reg_write(priv, REG_ENA_VP_1, 0x00);
- reg_write(priv, REG_ENA_VP_2, 0x00);
+static void tda998x_disable(struct tda998x_priv *priv)
+{
+ /* disable video ports */
+ reg_write(priv, REG_ENA_VP_0, 0x00);
+ reg_write(priv, REG_ENA_VP_1, 0x00);
+ reg_write(priv, REG_ENA_VP_2, 0x00);
- priv->is_on = false;
- }
+ priv->is_on = false;
+}
+
+static void tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
+{
+ struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
+
+ /* we only care about on or off: */
+ if (mode == DRM_MODE_DPMS_ON)
+ tda998x_enable(priv);
+ else
+ tda998x_disable(priv);
}
static void
@@ -1606,12 +1612,16 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
static void tda998x_encoder_prepare(struct drm_encoder *encoder)
{
- tda998x_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
+ struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
+
+ tda998x_disable(priv);
}
static void tda998x_encoder_commit(struct drm_encoder *encoder)
{
- tda998x_encoder_dpms(encoder, DRM_MODE_DPMS_ON);
+ struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
+
+ tda998x_enable(priv);
}
static const struct drm_encoder_helper_funcs tda998x_encoder_helper_funcs = {
--
2.11.0
^ permalink raw reply related
* [PATCH v5 6/7] drm/i2c: tda998x: split encoder and component functions from the work
From: Peter Rosin @ 2018-05-23 9:31 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, David Airlie, Rob Herring, Mark Rutland,
Nicolas Ferre, Alexandre Belloni, Boris Brezillon, Russell King,
Laurent Pinchart, dri-devel, devicetree, linux-arm-kernel,
Jyri Sarha, Daniel Vetter, Andrzej Hajda, Jacopo Mondi
In-Reply-To: <20180523093122.27859-1-peda@axentia.se>
This enables reuse of the machinery for the case where a drm_bridge
needs to do the same work via different interfaces.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 36 ++++++++++++++++++++++++++++--------
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index 3dda07a2fd2f..d401b3d0095c 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1202,11 +1202,10 @@ static void tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
}
static void
-tda998x_encoder_mode_set(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+tda998x_mode_set(struct tda998x_priv *priv,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
{
- struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
u16 ref_pix, ref_line, n_pix, n_line;
u16 hs_pix_s, hs_pix_e;
u16 vs1_pix_s, vs1_pix_e, vs1_line_s, vs1_line_e;
@@ -1413,6 +1412,16 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
mutex_unlock(&priv->audio_mutex);
}
+static void
+tda998x_encoder_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
+
+ tda998x_mode_set(priv, mode, adjusted_mode);
+}
+
static void tda998x_destroy(struct tda998x_priv *priv)
{
/* disable all IRQs and free the IRQ handler */
@@ -1662,11 +1671,10 @@ static void tda998x_set_config(struct tda998x_priv *priv,
priv->audio_params = p->audio_params;
}
-static int tda998x_bind(struct device *dev, struct device *master, void *data)
+static int tda998x_init(struct device *dev, struct drm_device *drm)
{
struct tda998x_encoder_params *params = dev->platform_data;
struct i2c_client *client = to_i2c_client(dev);
- struct drm_device *drm = data;
struct tda998x_priv *priv;
u32 crtcs = 0;
int ret;
@@ -1714,8 +1722,7 @@ static int tda998x_bind(struct device *dev, struct device *master, void *data)
return ret;
}
-static void tda998x_unbind(struct device *dev, struct device *master,
- void *data)
+static void tda998x_fini(struct device *dev)
{
struct tda998x_priv *priv = dev_get_drvdata(dev);
@@ -1724,6 +1731,19 @@ static void tda998x_unbind(struct device *dev, struct device *master,
tda998x_destroy(priv);
}
+static int tda998x_bind(struct device *dev, struct device *master, void *data)
+{
+ struct drm_device *drm = data;
+
+ return tda998x_init(dev, drm);
+}
+
+static void tda998x_unbind(struct device *dev, struct device *master,
+ void *data)
+{
+ tda998x_fini(dev);
+}
+
static const struct component_ops tda998x_ops = {
.bind = tda998x_bind,
.unbind = tda998x_unbind,
--
2.11.0
^ permalink raw reply related
* [PATCH v5 7/7] drm/i2c: tda998x: register as a drm bridge
From: Peter Rosin @ 2018-05-23 9:31 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, David Airlie, Rob Herring, Mark Rutland,
Nicolas Ferre, Alexandre Belloni, Boris Brezillon, Russell King,
Laurent Pinchart, dri-devel, devicetree, linux-arm-kernel,
Jyri Sarha, Daniel Vetter, Andrzej Hajda, Jacopo Mondi
In-Reply-To: <20180523093122.27859-1-peda@axentia.se>
This makes this driver work with all(?) drivers that are not
componentized and instead expect to connect to a panel/bridge. That
said, the only one tested is atmel-hlcdc.
This hooks the relevant work function previously called by the encoder
and the component also to the bridge, since the encoder goes away when
connecting to the bridge interface of the driver and the equivalent of
bind/unbind of the component is handled by bridge attach/detach.
The lifetime requirements of a bridge and a component are slightly
different, which is the reason for struct tda998x_bridge.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 170 ++++++++++++++++++++++++++++++++------
1 file changed, 143 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index d401b3d0095c..d47e49c2991a 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -36,6 +36,14 @@ struct tda998x_audio_port {
u8 config; /* AP value */
};
+struct tda998x_priv;
+
+struct tda998x_bridge {
+ struct tda998x_priv *priv;
+ struct device *dev;
+ struct drm_bridge bridge;
+};
+
struct tda998x_priv {
struct i2c_client *cec;
struct i2c_client *hdmi;
@@ -63,6 +71,8 @@ struct tda998x_priv {
wait_queue_head_t edid_delay_waitq;
bool edid_delay_active;
+ struct tda998x_bridge *bridge;
+ bool local_encoder;
struct drm_encoder encoder;
struct drm_connector connector;
@@ -75,6 +85,9 @@ struct tda998x_priv {
#define enc_to_tda998x_priv(x) \
container_of(x, struct tda998x_priv, encoder)
+#define bridge_to_tda998x_bridge(x) \
+ container_of(x, struct tda998x_bridge, bridge)
+
/* The TDA9988 series of devices use a paged register scheme.. to simplify
* things we encode the page # in upper bits of the register #. To read/
* write a given register, we need to make sure CURPAGE register is set
@@ -842,7 +855,8 @@ static int tda998x_audio_hw_params(struct device *dev, void *data,
struct hdmi_codec_daifmt *daifmt,
struct hdmi_codec_params *params)
{
- struct tda998x_priv *priv = dev_get_drvdata(dev);
+ struct tda998x_bridge *bridge = dev_get_drvdata(dev);
+ struct tda998x_priv *priv = bridge->priv;
int i, ret;
struct tda998x_audio_params audio = {
.sample_width = params->sample_width,
@@ -899,7 +913,8 @@ static int tda998x_audio_hw_params(struct device *dev, void *data,
static void tda998x_audio_shutdown(struct device *dev, void *data)
{
- struct tda998x_priv *priv = dev_get_drvdata(dev);
+ struct tda998x_bridge *bridge = dev_get_drvdata(dev);
+ struct tda998x_priv *priv = bridge->priv;
mutex_lock(&priv->audio_mutex);
@@ -912,7 +927,8 @@ static void tda998x_audio_shutdown(struct device *dev, void *data)
int tda998x_audio_digital_mute(struct device *dev, void *data, bool enable)
{
- struct tda998x_priv *priv = dev_get_drvdata(dev);
+ struct tda998x_bridge *bridge = dev_get_drvdata(dev);
+ struct tda998x_priv *priv = bridge->priv;
mutex_lock(&priv->audio_mutex);
@@ -925,7 +941,8 @@ int tda998x_audio_digital_mute(struct device *dev, void *data, bool enable)
static int tda998x_audio_get_eld(struct device *dev, void *data,
uint8_t *buf, size_t len)
{
- struct tda998x_priv *priv = dev_get_drvdata(dev);
+ struct tda998x_bridge *bridge = dev_get_drvdata(dev);
+ struct tda998x_priv *priv = bridge->priv;
mutex_lock(&priv->audio_mutex);
memcpy(buf, priv->connector.eld,
@@ -1126,7 +1143,10 @@ tda998x_connector_best_encoder(struct drm_connector *connector)
{
struct tda998x_priv *priv = conn_to_tda998x_priv(connector);
- return &priv->encoder;
+ if (priv->local_encoder)
+ return &priv->encoder;
+ else
+ return priv->bridge->bridge.encoder;
}
static
@@ -1140,6 +1160,7 @@ static int tda998x_connector_init(struct tda998x_priv *priv,
struct drm_device *drm)
{
struct drm_connector *connector = &priv->connector;
+ struct drm_encoder *encoder;
int ret;
connector->interlace_allowed = 1;
@@ -1156,7 +1177,8 @@ static int tda998x_connector_init(struct tda998x_priv *priv,
if (ret)
return ret;
- drm_mode_connector_attach_encoder(&priv->connector, &priv->encoder);
+ encoder = tda998x_connector_best_encoder(&priv->connector);
+ drm_mode_connector_attach_encoder(&priv->connector, encoder);
return 0;
}
@@ -1671,8 +1693,10 @@ static void tda998x_set_config(struct tda998x_priv *priv,
priv->audio_params = p->audio_params;
}
-static int tda998x_init(struct device *dev, struct drm_device *drm)
+static int tda998x_init(struct device *dev, struct drm_device *drm,
+ bool local_encoder)
{
+ struct tda998x_bridge *bridge = dev_get_drvdata(dev);
struct tda998x_encoder_params *params = dev->platform_data;
struct i2c_client *client = to_i2c_client(dev);
struct tda998x_priv *priv;
@@ -1683,18 +1707,22 @@ static int tda998x_init(struct device *dev, struct drm_device *drm)
if (!priv)
return -ENOMEM;
- dev_set_drvdata(dev, priv);
+ bridge->priv = priv;
+ priv->bridge = bridge;
+ priv->local_encoder = local_encoder;
- if (dev->of_node)
- crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
+ if (local_encoder) {
+ if (dev->of_node)
+ crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
- /* If no CRTCs were found, fall back to our old behaviour */
- if (crtcs == 0) {
- dev_warn(dev, "Falling back to first CRTC\n");
- crtcs = 1 << 0;
- }
+ /* If no CRTCs were found, fall back to our old behaviour */
+ if (crtcs == 0) {
+ dev_warn(dev, "Falling back to first CRTC\n");
+ crtcs = 1 << 0;
+ }
- priv->encoder.possible_crtcs = crtcs;
+ priv->encoder.possible_crtcs = crtcs;
+ }
ret = tda998x_create(client, priv);
if (ret)
@@ -1703,11 +1731,15 @@ static int tda998x_init(struct device *dev, struct drm_device *drm)
if (!dev->of_node && params)
tda998x_set_config(priv, params);
- drm_encoder_helper_add(&priv->encoder, &tda998x_encoder_helper_funcs);
- ret = drm_encoder_init(drm, &priv->encoder, &tda998x_encoder_funcs,
- DRM_MODE_ENCODER_TMDS, NULL);
- if (ret)
- goto err_encoder;
+ if (local_encoder) {
+ drm_encoder_helper_add(&priv->encoder,
+ &tda998x_encoder_helper_funcs);
+ ret = drm_encoder_init(drm, &priv->encoder,
+ &tda998x_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
+ if (ret)
+ goto err_encoder;
+ }
ret = tda998x_connector_init(priv, drm);
if (ret)
@@ -1716,7 +1748,8 @@ static int tda998x_init(struct device *dev, struct drm_device *drm)
return 0;
err_connector:
- drm_encoder_cleanup(&priv->encoder);
+ if (local_encoder)
+ drm_encoder_cleanup(&priv->encoder);
err_encoder:
tda998x_destroy(priv);
return ret;
@@ -1724,10 +1757,12 @@ static int tda998x_init(struct device *dev, struct drm_device *drm)
static void tda998x_fini(struct device *dev)
{
- struct tda998x_priv *priv = dev_get_drvdata(dev);
+ struct tda998x_bridge *bridge = dev_get_drvdata(dev);
+ struct tda998x_priv *priv = bridge->priv;
drm_connector_cleanup(&priv->connector);
- drm_encoder_cleanup(&priv->encoder);
+ if (priv->local_encoder)
+ drm_encoder_cleanup(&priv->encoder);
tda998x_destroy(priv);
}
@@ -1735,7 +1770,7 @@ static int tda998x_bind(struct device *dev, struct device *master, void *data)
{
struct drm_device *drm = data;
- return tda998x_init(dev, drm);
+ return tda998x_init(dev, drm, true);
}
static void tda998x_unbind(struct device *dev, struct device *master,
@@ -1749,19 +1784,100 @@ static const struct component_ops tda998x_ops = {
.unbind = tda998x_unbind,
};
+/* DRM bridge functions */
+
+static int tda998x_bridge_attach(struct drm_bridge *dbridge)
+{
+ struct tda998x_bridge *bridge = bridge_to_tda998x_bridge(dbridge);
+ struct device *dev = bridge->dev;
+ struct drm_device *drm = bridge->bridge.dev;
+
+ return tda998x_init(dev, drm, false);
+}
+
+static void tda998x_bridge_detach(struct drm_bridge *dbridge)
+{
+ struct tda998x_bridge *bridge = bridge_to_tda998x_bridge(dbridge);
+ struct device *dev = bridge->dev;
+
+ tda998x_fini(dev);
+}
+
+static void tda998x_bridge_enable(struct drm_bridge *dbridge)
+{
+ struct tda998x_bridge *bridge = bridge_to_tda998x_bridge(dbridge);
+ struct tda998x_priv *priv = bridge->priv;
+
+ tda998x_enable(priv);
+}
+
+static void tda998x_bridge_disable(struct drm_bridge *dbridge)
+{
+ struct tda998x_bridge *bridge = bridge_to_tda998x_bridge(dbridge);
+ struct tda998x_priv *priv = bridge->priv;
+
+ tda998x_disable(priv);
+}
+
+static void tda998x_bridge_mode_set(struct drm_bridge *dbridge,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct tda998x_bridge *bridge = bridge_to_tda998x_bridge(dbridge);
+ struct tda998x_priv *priv = bridge->priv;
+
+ tda998x_mode_set(priv, mode, adjusted_mode);
+}
+
+static const struct drm_bridge_funcs tda998x_bridge_funcs = {
+ .attach = tda998x_bridge_attach,
+ .detach = tda998x_bridge_detach,
+ .enable = tda998x_bridge_enable,
+ .disable = tda998x_bridge_disable,
+ .mode_set = tda998x_bridge_mode_set,
+};
+
static int
tda998x_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
+ struct device *dev = &client->dev;
+ struct tda998x_bridge *bridge;
+ int ret;
+
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
dev_warn(&client->dev, "adapter does not support I2C\n");
return -EIO;
}
- return component_add(&client->dev, &tda998x_ops);
+
+ bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL);
+ if (!bridge)
+ return -ENOMEM;
+
+ bridge->dev = dev;
+ dev_set_drvdata(dev, bridge);
+
+ bridge->bridge.funcs = &tda998x_bridge_funcs;
+#ifdef CONFIG_OF
+ bridge->bridge.of_node = dev->of_node;
+#endif
+ drm_bridge_add(&bridge->bridge);
+
+ ret = component_add(dev, &tda998x_ops);
+
+ if (ret)
+ drm_bridge_remove(&bridge->bridge);
+
+ return ret;
}
static int tda998x_remove(struct i2c_client *client)
{
- component_del(&client->dev, &tda998x_ops);
+ struct device *dev = &client->dev;
+ struct tda998x_bridge *bridge = dev_get_drvdata(dev);
+
+ drm_bridge_remove(&bridge->bridge);
+ component_del(dev, &tda998x_ops);
+
return 0;
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH V3 8/8] dt-bindings: stm32: add compatible for syscon
From: Christophe ROULLIER @ 2018-05-23 9:32 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland@arm.com, mcoquelin.stm32@gmail.com, Alexandre TORGUE,
Peppe CAVALLARO, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
andrew@lunn.ch
In-Reply-To: <20180522172238.GA26145@rob-hp-laptop>
On 05/22/2018 07:22 PM, Rob Herring wrote:
> On Mon, May 21, 2018 at 10:07:26AM +0200, Christophe Roullier wrote:
>> This patch describes syscon DT bindings.
>>
>> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
>> ---
>> Documentation/devicetree/bindings/arm/stm32.txt | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/stm32.txt b/Documentation/devicetree/bindings/arm/stm32.txt
>> index 6808ed9..e46ebad 100644
>> --- a/Documentation/devicetree/bindings/arm/stm32.txt
>> +++ b/Documentation/devicetree/bindings/arm/stm32.txt
>> @@ -8,3 +8,8 @@ using one of the following compatible strings:
>> st,stm32f746
>> st,stm32h743
>> st,stm32mp157
>> +
>> +Required nodes:
>> +- syscon: the soc bus node must have a system controller node pointing to the
>> + global control registers, with the compatible string
>> + "st,stm32mp157-syscfg", "syscon";
>
> Please don't mix soc/board bindings with other nodes. So perhaps
> stm32-syscon.txt.
>
> Rob
>
Hi Rob,
Is it ok for you with this tree file:
Documentation/devicetree/bindings/arm/stm32/stm32.txt
Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt
With stm32-syscon.txt:
---------------------------------------------------
STMicroelectronics STM32 Platforms System Controller
Properties:
- compatible : should contain two values. First value must be :
- " st,stm32mp157-syscfg " - for stm32mp157 based SoCs,
second value must be always "syscon".
- reg : offset and length of the register set.
Example:
syscfg: system-config@50020000 {
compatible = "st,stm32mp157-syscfg", "syscon";
reg = <0x50020000 0x400>;
};
---------------------------------------------------
Do we need to update also all MCU family (stm32f4, stm32h7, stm32f7)
property to be coherent ?
Thanks for your feedback.
Christophe.
^ permalink raw reply
* Re: [PATCH] cpufreq: Add Kryo CPU scaling driver
From: Viresh Kumar @ 2018-05-23 9:32 UTC (permalink / raw)
To: Ilia Lin
Cc: rjw, sudeep.holla, linux, linux-clk, devicetree, linux-kernel,
linux-pm, linux-arm-msm, linux-soc, linux-arm-kernel
In-Reply-To: <1527066324-24726-1-git-send-email-ilialin@codeaurora.org>
On 23-05-18, 12:05, Ilia Lin wrote:
> In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
> the CPU frequency subset and voltage value of each OPP varies
> based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
> defines the voltage and frequency value based on the msm-id in SMEM
> and speedbin blown in the efuse combination.
> The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
> to provide the OPP framework with required information.
> This is used to determine the voltage and frequency value for each OPP of
> operating-points-v2 table when it is parsed by the OPP framework.
>
> Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
> ---
> drivers/cpufreq/Kconfig.arm | 10 +++
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
> drivers/cpufreq/qcom-cpufreq-kryo.c | 163 +++++++++++++++++++++++++++++++++++
> 4 files changed, 177 insertions(+)
> create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
Hi Ilia,
So the patch looks good now. But I don't see how this series is going
to get merged. You are touching all parts of the kernel and no single
maintainer would be able to get these merged easily.
What I would suggest is that you divided the series in at least 3
parts.
- Patch 10 and 11, just the cpufreq stuff. So that Rafael can apply
those independently. Also mention the dependency on my OPP patches
in the cover letter for those two patches.
- All clk patches in another series, so that Stephen can apply them.
- And finally everything else to go via ARM-Soc.
Maybe things wouldn't be that simple, but that's what you would need
to do to get things merged. And please add all Acked by tags you got
to the patches.
For this patch:
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"
From: Christian König @ 2018-05-23 9:35 UTC (permalink / raw)
To: Qiang Yu, dri-devel, devicetree
Cc: Simon Shields, Marek Vasut, Connor Abbott, Neil Armstrong,
Andrei Paulau, Vasily Khoruzhick, Erico Nunes
In-Reply-To: <20180518092815.25280-6-yuq825@gmail.com>
Well NAK, that brings back a callback we worked quite hard on getting
rid of.
It looks like the problem isn't that you need the preclose callback, but
you rather seem to misunderstood how TTM works.
All you need to do is to cleanup your command submission path so that
the caller of lima_sched_context_queue_task() adds the resulting
scheduler fence to TTMs buffer objects.
Regards,
Christian.
Am 18.05.2018 um 11:27 schrieb Qiang Yu:
> This reverts commit 45c3d213a400c952ab7119f394c5293bb6877e6b.
>
> lima driver need preclose to wait all task in the context
> created within closing file to finish before free all the
> buffer object. Otherwise pending tesk may fail and get
> noisy MMU fault message.
>
> Move this wait to each buffer object free function can
> achieve the same result but some buffer object is shared
> with other file context, but we only want to wait the
> closing file context's tasks. So the implementation is
> not that straight forword compared to the preclose one.
>
> Signed-off-by: Qiang Yu <yuq825@gmail.com>
> ---
> drivers/gpu/drm/drm_file.c | 8 ++++----
> include/drm/drm_drv.h | 23 +++++++++++++++++++++--
> 2 files changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index e394799979a6..0a43107396b9 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -361,8 +361,9 @@ void drm_lastclose(struct drm_device * dev)
> *
> * This function must be used by drivers as their &file_operations.release
> * method. It frees any resources associated with the open file, and calls the
> - * &drm_driver.postclose driver callback. If this is the last open file for the
> - * DRM device also proceeds to call the &drm_driver.lastclose driver callback.
> + * &drm_driver.preclose and &drm_driver.lastclose driver callbacks. If this is
> + * the last open file for the DRM device also proceeds to call the
> + * &drm_driver.lastclose driver callback.
> *
> * RETURNS:
> *
> @@ -382,8 +383,7 @@ int drm_release(struct inode *inode, struct file *filp)
> list_del(&file_priv->lhead);
> mutex_unlock(&dev->filelist_mutex);
>
> - if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
> - dev->driver->preclose)
> + if (dev->driver->preclose)
> dev->driver->preclose(dev, file_priv);
>
> /* ========================================================
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index d23dcdd1bd95..8d6080f97ed4 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -107,6 +107,23 @@ struct drm_driver {
> */
> int (*open) (struct drm_device *, struct drm_file *);
>
> + /**
> + * @preclose:
> + *
> + * One of the driver callbacks when a new &struct drm_file is closed.
> + * Useful for tearing down driver-private data structures allocated in
> + * @open like buffer allocators, execution contexts or similar things.
> + *
> + * Since the display/modeset side of DRM can only be owned by exactly
> + * one &struct drm_file (see &drm_file.is_master and &drm_device.master)
> + * there should never be a need to tear down any modeset related
> + * resources in this callback. Doing so would be a driver design bug.
> + *
> + * FIXME: It is not really clear why there's both @preclose and
> + * @postclose. Without a really good reason, use @postclose only.
> + */
> + void (*preclose) (struct drm_device *, struct drm_file *file_priv);
> +
> /**
> * @postclose:
> *
> @@ -118,6 +135,9 @@ struct drm_driver {
> * one &struct drm_file (see &drm_file.is_master and &drm_device.master)
> * there should never be a need to tear down any modeset related
> * resources in this callback. Doing so would be a driver design bug.
> + *
> + * FIXME: It is not really clear why there's both @preclose and
> + * @postclose. Without a really good reason, use @postclose only.
> */
> void (*postclose) (struct drm_device *, struct drm_file *);
>
> @@ -134,7 +154,7 @@ struct drm_driver {
> * state changes, e.g. in conjunction with the :ref:`vga_switcheroo`
> * infrastructure.
> *
> - * This is called after @postclose hook has been called.
> + * This is called after @preclose and @postclose have been called.
> *
> * NOTE:
> *
> @@ -601,7 +621,6 @@ struct drm_driver {
> /* List of devices hanging off this driver with stealth attach. */
> struct list_head legacy_dev_list;
> int (*firstopen) (struct drm_device *);
> - void (*preclose) (struct drm_device *, struct drm_file *file_priv);
> int (*dma_ioctl) (struct drm_device *dev, void *data, struct drm_file *file_priv);
> int (*dma_quiescent) (struct drm_device *);
> int (*context_dtor) (struct drm_device *dev, int context);
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 13/40] vfio: Add support for Shared Virtual Addressing
From: Xu Zaibo @ 2018-05-23 9:38 UTC (permalink / raw)
To: Jean-Philippe Brucker,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
kvm-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg
Cc: will.deacon-5wv7dgnIgG8, okaya-sgV2jX0FEOL9JmXXK+q4OQ, liguozhu,
ashok.raj-ral2JQCrhuEAvxtiuMwx3w, bharatku-gjFFaj9aHVfQT0dZR+AlfA,
rfranz-YGCgFSpz5w/QT0dZR+AlfA, rgummal-gjFFaj9aHVfQT0dZR+AlfA,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ilias.apalodimas-QSEj5FYQhm4dnm+yROfE0A,
christian.koenig-5C7GfCeVMHo
In-Reply-To: <20180511190641.23008-14-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
Hi,
On 2018/5/12 3:06, Jean-Philippe Brucker wrote:
> Add two new ioctls for VFIO containers. VFIO_IOMMU_BIND_PROCESS creates a
> bond between a container and a process address space, identified by a
> Process Address Space ID (PASID). Devices in the container append this
> PASID to DMA transactions in order to access the process' address space.
> The process page tables are shared with the IOMMU, and mechanisms such as
> PCI ATS/PRI are used to handle faults. VFIO_IOMMU_UNBIND_PROCESS removes a
> bond created with VFIO_IOMMU_BIND_PROCESS.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
>
>
>
>
>
>
> +static int vfio_iommu_bind_group(struct vfio_iommu *iommu,
> + struct vfio_group *group,
> + struct vfio_mm *vfio_mm)
> +{
> + int ret;
> + bool enabled_sva = false;
> + struct vfio_iommu_sva_bind_data data = {
> + .vfio_mm = vfio_mm,
> + .iommu = iommu,
> + .count = 0,
> + };
> +
> + if (!group->sva_enabled) {
> + ret = iommu_group_for_each_dev(group->iommu_group, NULL,
> + vfio_iommu_sva_init);
Do we need to do *sva_init here or do anything to avoid repeated initiation?
while another process already did initiation at this device, I think
that current process will get an EEXIST.
Thanks.
> + if (ret)
> + return ret;
> +
> + group->sva_enabled = enabled_sva = true;
> + }
> +
> + ret = iommu_group_for_each_dev(group->iommu_group, &data,
> + vfio_iommu_sva_bind_dev);
> + if (ret && data.count > 1)
> + iommu_group_for_each_dev(group->iommu_group, vfio_mm,
> + vfio_iommu_sva_unbind_dev);
> + if (ret && enabled_sva) {
> + iommu_group_for_each_dev(group->iommu_group, NULL,
> + vfio_iommu_sva_shutdown);
> + group->sva_enabled = false;
> + }
> +
> + return ret;
> +}
>
>
>
> @@ -1442,6 +1636,10 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
> if (ret)
> goto out_detach;
>
> + ret = vfio_iommu_replay_bind(iommu, group);
> + if (ret)
> + goto out_detach;
> +
> if (resv_msi) {
> ret = iommu_get_msi_cookie(domain->domain, resv_msi_base);
> if (ret)
> @@ -1547,6 +1745,11 @@ static void vfio_iommu_type1_detach_group(void *iommu_data,
> continue;
>
> iommu_detach_group(domain->domain, iommu_group);
> + if (group->sva_enabled) {
> + iommu_group_for_each_dev(iommu_group, NULL,
> + vfio_iommu_sva_shutdown);
> + group->sva_enabled = false;
> + }
Here, why shut down here? If another process is working on the device,
there may be a crash?
Thanks.
> list_del(&group->next);
> kfree(group);
> /*
> @@ -1562,6 +1765,7 @@ static void vfio_iommu_type1_detach_group(void *iommu_data,
>
^ permalink raw reply
* Re: [PATCH 2/2] media: platform: add driver for TI SCAN921226H video deserializer
From: Philipp Zabel @ 2018-05-23 9:39 UTC (permalink / raw)
To: Jan Luebbe, linux-media; +Cc: kernel, devicetree, Hans Verkuil
In-Reply-To: <20180504124903.6276-3-jlu@pengutronix.de>
Hi Jan,
Hans just pointed out a few issues in my video-mux compliance patch [1]
that also apply to this driver, see below.
[1] v1: https://patchwork.linuxtv.org/patch/49827/
v2: https://patchwork.linuxtv.org/patch/49839/
On Fri, 2018-05-04 at 14:49 +0200, Jan Luebbe wrote:
[...]
> diff --git a/drivers/media/platform/scan921226h.c b/drivers/media/platform/scan921226h.c
> new file mode 100644
> index 000000000000..59fcd55ceaa2
> --- /dev/null
> +++ b/drivers/media/platform/scan921226h.c
[...]
> +static int video_des_set_format(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_format *sdformat)
> +{
> + struct video_des *vdes = v4l2_subdev_to_video_des(sd);
> + struct v4l2_mbus_framefmt *mbusformat;
> + struct media_pad *pad = &vdes->pads[sdformat->pad];
> +
> + mbusformat = __video_des_get_pad_format(sd, cfg, sdformat->pad,
> + sdformat->which);
> + if (!mbusformat)
> + return -EINVAL;
> +
> + mutex_lock(&vdes->lock);
> +
> + /* Source pad mirrors sink pad, no limitations on sink pads */
> + if ((pad->flags & MEDIA_PAD_FL_SOURCE)) {
> + sdformat->format = vdes->format_mbus;
> + } else {
> + /* any sizes are allowed */
> + v4l_bound_align_image(
> + &sdformat->format.width, 1, UINT_MAX-1, 0,
> + &sdformat->format.height, 1, UINT_MAX-1, 0,
Reduce from UINT_MAX-1 to 65536 to avoid potential overflow issues.
> + 0);
> + if (sdformat->format.field == V4L2_FIELD_ANY)
> + sdformat->format.field = V4L2_FIELD_NONE;
> + switch (sdformat->format.code) {
> + /* only 8 bit formats are supported */
> + case MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE:
> + case MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE:
[...]
> + case MEDIA_BUS_FMT_JPEG_1X8:
> + case MEDIA_BUS_FMT_S5C_UYVY_JPEG_1X8:
> + break;
> + default:
> + sdformat->format.code = MEDIA_BUS_FMT_Y8_1X8;
A
break;
should be added here.
> + }
> + }
> +
> + *mbusformat = sdformat->format;
> +
> + mutex_unlock(&vdes->lock);
> +
> + return 0;
> +}
> +
> +static const struct v4l2_subdev_pad_ops video_des_pad_ops = {
> + .get_fmt = video_des_get_format,
> + .set_fmt = video_des_set_format,
> +};
> +
> +static int video_des_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> +{
> + struct video_des *vdes = v4l2_subdev_to_video_des(sd);
> + struct v4l2_mbus_framefmt *format;
> +
> + mutex_lock(&vdes->lock);
> +
> + format = v4l2_subdev_get_try_format(sd, fh->pad, 0);
> + *format = vdes->format_mbus;
> + format = v4l2_subdev_get_try_format(sd, fh->pad, 1);
> + *format = vdes->format_mbus;
> +
> + mutex_unlock(&vdes->lock);
> +
> + return 0;
> +}
This should be done in the .init_cfg pad op.
> +
> +static const struct v4l2_subdev_internal_ops video_des_subdev_internal_ops = {
> + .open = video_des_open,
> +};
Internal ops can then be dropped.
regards
Philipp
^ permalink raw reply
* Re: [PATCH] cpufreq: Add Kryo CPU scaling driver
From: Russell King - ARM Linux @ 2018-05-23 9:40 UTC (permalink / raw)
To: Ilia Lin
Cc: viresh.kumar, rjw, sudeep.holla, linux-clk, devicetree,
linux-kernel, linux-pm, linux-arm-msm, linux-soc,
linux-arm-kernel
In-Reply-To: <1527066324-24726-1-git-send-email-ilialin@codeaurora.org>
On Wed, May 23, 2018 at 12:05:24PM +0300, Ilia Lin wrote:
> + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
> + if (IS_ERR(np))
> + return PTR_ERR(np);
...
> +
> + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> + if (!IS_ERR(pdev))
Do you need to hold a reference to `np' here?
> + return 0;
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v10 0/2] Kryo CPU scaling driver
From: Ilia Lin @ 2018-05-23 9:40 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm, devicetree,
linux-kernel
[v10]
* Split the series into domains
* Addressed comments from Viresh and Sudeep about logical CPU numbering.
The qcom-cpufreq-kryo driver is aimed to support different SOC versions.
The driver reads eFuse information and chooses the required OPP subset
by passing the OPP supported-hw parameter.
The series depends on the series from Viresh:
https://patchwork.kernel.org/patch/10418139/
The previous spin was here:
https://patchwork.kernel.org/patch/10420751/
https://patchwork.kernel.org/patch/10414761/
Ilia Lin (2):
cpufreq: Add Kryo CPU scaling driver
dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu
.../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +++++++++++++++++++++
drivers/cpufreq/Kconfig.arm | 10 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 163 +++++
5 files changed, 857 insertions(+)
create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
--
1.9.1
^ permalink raw reply
* [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
From: Ilia Lin @ 2018-05-23 9:40 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm, devicetree,
linux-kernel
In-Reply-To: <1527068454-28921-1-git-send-email-ilialin@codeaurora.org>
In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
the CPU frequency subset and voltage value of each OPP varies
based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
defines the voltage and frequency value based on the msm-id in SMEM
and speedbin blown in the efuse combination.
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
---
drivers/cpufreq/Kconfig.arm | 10 +++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 163 +++++++++++++++++++++++++++++++++++
4 files changed, 177 insertions(+)
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index de55c7d..0bfd40e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
+config ARM_QCOM_CPUFREQ_KRYO
+ bool "Qualcomm Kryo based CPUFreq"
+ depends on QCOM_QFPROM
+ depends on QCOM_SMEM
+ select PM_OPP
+ help
+ This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
+
+ If in doubt, say N.
+
config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade..fb4a2ec 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3b585e4..77d6ab8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,6 +118,9 @@
{ .compatible = "nvidia,tegra124", },
+ { .compatible = "qcom,apq8096", },
+ { .compatible = "qcom,msm8996", },
+
{ .compatible = "st,stih407", },
{ .compatible = "st,stih410", },
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c b/drivers/cpufreq/qcom-cpufreq-kryo.c
new file mode 100644
index 0000000..885051e
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -0,0 +1,163 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+/*
+ * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
+ * the CPU frequency subset and voltage value of each OPP varies
+ * based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
+ * defines the voltage and frequency value based on the msm-id in SMEM
+ * and speedbin blown in the efuse combination.
+ * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+ * to provide the OPP framework with required information.
+ * This is used to determine the voltage and frequency value for each OPP of
+ * operating-points-v2 table when it is parsed by the OPP framework.
+ */
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+#include <linux/soc/qcom/smem.h>
+
+#define MSM_ID_SMEM 137
+
+enum _msm_id {
+ MSM8996V3 = 0xF6ul,
+ APQ8096V3 = 0x123ul,
+ MSM8996SG = 0x131ul,
+ APQ8096SG = 0x138ul,
+};
+
+enum _msm8996_version {
+ MSM8996_V3,
+ MSM8996_SG,
+ NUM_OF_MSM8996_VERSIONS,
+};
+
+static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
+{
+ size_t len;
+ u32 *msm_id;
+ enum _msm8996_version version;
+
+ msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
+ /* The first 4 bytes are format, next to them is the actual msm-id */
+ msm_id++;
+
+ switch ((enum _msm_id)*msm_id) {
+ case MSM8996V3:
+ case APQ8096V3:
+ version = MSM8996_V3;
+ break;
+ case MSM8996SG:
+ case APQ8096SG:
+ version = MSM8996_SG;
+ break;
+ default:
+ version = NUM_OF_MSM8996_VERSIONS;
+ }
+
+ return version;
+}
+
+static int __init qcom_cpufreq_kryo_driver_init(void)
+{
+ struct opp_table *opp_tables[NR_CPUS] = {0};
+ enum _msm8996_version msm8996_version;
+ struct nvmem_cell *speedbin_nvmem;
+ struct platform_device *pdev;
+ struct device_node *np;
+ struct device *cpu_dev;
+ unsigned cpu;
+ u8 *speedbin;
+ u32 versions;
+ size_t len;
+ int ret;
+
+ cpu_dev = get_cpu_device(0);
+ if (NULL == cpu_dev)
+ return -ENODEV;
+
+ msm8996_version = qcom_cpufreq_kryo_get_msm_id();
+ if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
+ dev_err(cpu_dev, "Not Snapdragon 820/821!");
+ return -ENODEV;
+ }
+
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
+ if (IS_ERR(np))
+ return PTR_ERR(np);
+
+ if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
+ ret = -ENOENT;
+ goto free_np;
+ }
+
+ speedbin_nvmem = of_nvmem_cell_get(np, NULL);
+ if (IS_ERR(speedbin_nvmem)) {
+ ret = PTR_ERR(speedbin_nvmem);
+ dev_err(cpu_dev, "Could not get nvmem cell: %d\n", ret);
+ goto free_np;
+ }
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ nvmem_cell_put(speedbin_nvmem);
+
+ switch (msm8996_version) {
+ case MSM8996_V3:
+ versions = 1 << (unsigned int)(*speedbin);
+ break;
+ case MSM8996_SG:
+ versions = 1 << ((unsigned int)(*speedbin) + 4);
+ break;
+ default:
+ BUG();
+ break;
+ }
+
+ for_each_possible_cpu(cpu) {
+ cpu_dev = get_cpu_device(cpu);
+ if (NULL == cpu_dev) {
+ ret = -ENODEV;
+ goto free_opp;
+ }
+
+ opp_tables[cpu] = dev_pm_opp_set_supported_hw(cpu_dev,
+ &versions, 1);
+ if (IS_ERR(opp_tables[cpu])) {
+ ret = PTR_ERR(opp_tables[cpu]);
+ dev_err(cpu_dev, "Failed to set supported hardware\n");
+ goto free_opp;
+ }
+ }
+
+ pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+ if (!IS_ERR(pdev))
+ return 0;
+
+ ret = PTR_ERR(pdev);
+ dev_err(cpu_dev, "Failed to register platform device\n");
+
+free_opp:
+ for_each_possible_cpu(cpu) {
+ if (IS_ERR_OR_NULL(opp_tables[cpu]))
+ break;
+ dev_pm_opp_put_supported_hw(opp_tables[cpu]);
+ }
+free_np:
+ of_node_put(np);
+
+ return ret;
+}
+late_initcall(qcom_cpufreq_kryo_driver_init);
+
+MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v10 2/2] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu
From: Ilia Lin @ 2018-05-23 9:40 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm, devicetree,
linux-kernel
In-Reply-To: <1527068454-28921-1-git-send-email-ilialin@codeaurora.org>
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
This change adds documentation for the DT bindings.
The "operating-points-v2-kryo-cpu" DT extends the "operating-points-v2"
with following parameters:
- nvmem-cells (NVMEM area containig the speedbin information)
- opp-supported-hw: A single 32 bit bitmap value,
representing compatible HW:
0: MSM8996 V3, speedbin 0
1: MSM8996 V3, speedbin 1
2: MSM8996 V3, speedbin 2
3: unused
4: MSM8996 SG, speedbin 0
5: MSM8996 SG, speedbin 1
6: MSM8996 SG, speedbin 2
7-31: unused
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
.../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +++++++++++++++++++++
1 file changed, 680 insertions(+)
create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
diff --git a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
new file mode 100644
index 0000000..c2127b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
@@ -0,0 +1,680 @@
+Qualcomm Technologies, Inc. KRYO CPUFreq and OPP bindings
+===================================
+
+In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996
+that have KRYO processors, the CPU ferequencies subset and voltage value
+of each OPP varies based on the silicon variant in use.
+Qualcomm Technologies, Inc. Process Voltage Scaling Tables
+defines the voltage and frequency value based on the msm-id in SMEM
+and speedbin blown in the efuse combination.
+The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+to provide the OPP framework with required information (existing HW bitmap).
+This is used to determine the voltage and frequency value for each OPP of
+operating-points-v2 table when it is parsed by the OPP framework.
+
+Required properties:
+--------------------
+In 'cpus' nodes:
+- operating-points-v2: Phandle to the operating-points-v2 table to use.
+
+In 'operating-points-v2' table:
+- compatible: Should be
+ - 'operating-points-v2-kryo-cpu' for apq8096 and msm8996.
+- nvmem-cells: A phandle pointing to a nvmem-cells node representing the
+ efuse registers that has information about the
+ speedbin that is used to select the right frequency/voltage
+ value pair.
+ Please refer the for nvmem-cells
+ bindings Documentation/devicetree/bindings/nvmem/nvmem.txt
+ and also examples below.
+
+In every OPP node:
+- opp-supported-hw: A single 32 bit bitmap value, representing compatible HW.
+ Bitmap:
+ 0: MSM8996 V3, speedbin 0
+ 1: MSM8996 V3, speedbin 1
+ 2: MSM8996 V3, speedbin 2
+ 3: unused
+ 4: MSM8996 SG, speedbin 0
+ 5: MSM8996 SG, speedbin 1
+ 6: MSM8996 SG, speedbin 2
+ 7-31: unused
+
+Example 1:
+---------
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ clocks = <&kryocc 0>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_0>;
+ L2_0: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ };
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ clocks = <&kryocc 0>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_0>;
+ };
+
+ CPU2: cpu@100 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ clocks = <&kryocc 1>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster1_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_1>;
+ L2_1: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ };
+ };
+
+ CPU3: cpu@101 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x101>;
+ enable-method = "psci";
+ clocks = <&kryocc 1>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster1_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_1>;
+ };
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&CPU0>;
+ };
+
+ core1 {
+ cpu = <&CPU1>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&CPU2>;
+ };
+
+ core1 {
+ cpu = <&CPU3>;
+ };
+ };
+ };
+ };
+
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2-kryo-cpu";
+ nvmem-cells = <&speedbin_efuse>;
+ opp-shared;
+
+ opp-307200000 {
+ opp-hz = /bits/ 64 <307200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-422400000 {
+ opp-hz = /bits/ 64 <422400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-460800000 {
+ opp-hz = /bits/ 64 <460800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-537600000 {
+ opp-hz = /bits/ 64 <537600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-556800000 {
+ opp-hz = /bits/ 64 <556800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-652800000 {
+ opp-hz = /bits/ 64 <652800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-691200000 {
+ opp-hz = /bits/ 64 <691200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-729600000 {
+ opp-hz = /bits/ 64 <729600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-768000000 {
+ opp-hz = /bits/ 64 <768000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-844800000 {
+ opp-hz = /bits/ 64 <844800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-902400000 {
+ opp-hz = /bits/ 64 <902400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-960000000 {
+ opp-hz = /bits/ 64 <960000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-979200000 {
+ opp-hz = /bits/ 64 <979200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1036800000 {
+ opp-hz = /bits/ 64 <1036800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1056000000 {
+ opp-hz = /bits/ 64 <1056000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1113600000 {
+ opp-hz = /bits/ 64 <1113600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1132800000 {
+ opp-hz = /bits/ 64 <1132800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1190400000 {
+ opp-hz = /bits/ 64 <1190400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1209600000 {
+ opp-hz = /bits/ 64 <1209600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1228800000 {
+ opp-hz = /bits/ 64 <1228800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1286400000 {
+ opp-hz = /bits/ 64 <1286400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1324800000 {
+ opp-hz = /bits/ 64 <1324800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x5>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x72>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1401600000 {
+ opp-hz = /bits/ 64 <1401600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x5>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1440000000 {
+ opp-hz = /bits/ 64 <1440000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1478400000 {
+ opp-hz = /bits/ 64 <1478400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1497600000 {
+ opp-hz = /bits/ 64 <1497600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x4>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1516800000 {
+ opp-hz = /bits/ 64 <1516800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1593600000 {
+ opp-hz = /bits/ 64 <1593600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x71>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1996800000 {
+ opp-hz = /bits/ 64 <1996800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x20>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2188800000 {
+ opp-hz = /bits/ 64 <2188800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ };
+
+ cluster1_opp: opp_table1 {
+ compatible = "operating-points-v2-kryo-cpu";
+ nvmem-cells = <&speedbin_efuse>;
+ opp-shared;
+
+ opp-307200000 {
+ opp-hz = /bits/ 64 <307200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-403200000 {
+ opp-hz = /bits/ 64 <403200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-460800000 {
+ opp-hz = /bits/ 64 <460800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-537600000 {
+ opp-hz = /bits/ 64 <537600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-556800000 {
+ opp-hz = /bits/ 64 <556800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-652800000 {
+ opp-hz = /bits/ 64 <652800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-691200000 {
+ opp-hz = /bits/ 64 <691200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-729600000 {
+ opp-hz = /bits/ 64 <729600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-748800000 {
+ opp-hz = /bits/ 64 <748800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-806400000 {
+ opp-hz = /bits/ 64 <806400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-825600000 {
+ opp-hz = /bits/ 64 <825600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-883200000 {
+ opp-hz = /bits/ 64 <883200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-902400000 {
+ opp-hz = /bits/ 64 <902400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-940800000 {
+ opp-hz = /bits/ 64 <940800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-979200000 {
+ opp-hz = /bits/ 64 <979200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1036800000 {
+ opp-hz = /bits/ 64 <1036800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1056000000 {
+ opp-hz = /bits/ 64 <1056000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1113600000 {
+ opp-hz = /bits/ 64 <1113600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1132800000 {
+ opp-hz = /bits/ 64 <1132800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1190400000 {
+ opp-hz = /bits/ 64 <1190400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1209600000 {
+ opp-hz = /bits/ 64 <1209600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1248000000 {
+ opp-hz = /bits/ 64 <1248000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1286400000 {
+ opp-hz = /bits/ 64 <1286400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1324800000 {
+ opp-hz = /bits/ 64 <1324800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1401600000 {
+ opp-hz = /bits/ 64 <1401600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1440000000 {
+ opp-hz = /bits/ 64 <1440000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1478400000 {
+ opp-hz = /bits/ 64 <1478400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1516800000 {
+ opp-hz = /bits/ 64 <1516800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1555200000 {
+ opp-hz = /bits/ 64 <1555200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1593600000 {
+ opp-hz = /bits/ 64 <1593600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1632000000 {
+ opp-hz = /bits/ 64 <1632000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1670400000 {
+ opp-hz = /bits/ 64 <1670400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1708800000 {
+ opp-hz = /bits/ 64 <1708800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1747200000 {
+ opp-hz = /bits/ 64 <1747200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1785600000 {
+ opp-hz = /bits/ 64 <1785600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1804800000 {
+ opp-hz = /bits/ 64 <1804800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x6>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1824000000 {
+ opp-hz = /bits/ 64 <1824000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x71>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1900800000 {
+ opp-hz = /bits/ 64 <1900800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x74>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1920000000 {
+ opp-hz = /bits/ 64 <1920000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1977600000 {
+ opp-hz = /bits/ 64 <1977600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x30>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1996800000 {
+ opp-hz = /bits/ 64 <1996800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2054400000 {
+ opp-hz = /bits/ 64 <2054400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x30>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2073600000 {
+ opp-hz = /bits/ 64 <2073600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2150400000 {
+ opp-hz = /bits/ 64 <2150400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x31>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2246400000 {
+ opp-hz = /bits/ 64 <2246400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2342400000 {
+ opp-hz = /bits/ 64 <2342400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ };
+
+....
+
+reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+....
+ smem_mem: smem-mem@86000000 {
+ reg = <0x0 0x86000000 0x0 0x200000>;
+ no-map;
+ };
+....
+};
+
+smem {
+ compatible = "qcom,smem";
+ memory-region = <&smem_mem>;
+ hwlocks = <&tcsr_mutex 3>;
+};
+
+soc {
+....
+ qfprom: qfprom@74000 {
+ compatible = "qcom,qfprom";
+ reg = <0x00074000 0x8ff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ....
+ speedbin_efuse: speedbin@133 {
+ reg = <0x133 0x1>;
+ bits = <5 3>;
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 2/3] dt-bindings: arm: omap: dmm: Document new compatible for DRA7xx family
From: Tomi Valkeinen @ 2018-05-23 9:56 UTC (permalink / raw)
To: Peter Ujfalusi, laurent.pinchart; +Cc: devicetree, jsarha, dri-devel
In-Reply-To: <20180410113301.18984-3-peter.ujfalusi@ti.com>
On 10/04/18 14:33, Peter Ujfalusi wrote:
> From: Tomi Valkeinen <tomi.valkeinen@ti.com>
>
> Define unique compatible string for the DMM in DRA7xx family.
>
> The new compatible can be used to apply DRA7xx specific workarounds for
> ERRATAs, like i878 (MPU Lockup with concurrent DMM and EMIF accesses)
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> Documentation/devicetree/bindings/arm/omap/dmm.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt b/Documentation/devicetree/bindings/arm/omap/dmm.txt
> index 8bd6d0a238a8..bbbe7cdba30c 100644
> --- a/Documentation/devicetree/bindings/arm/omap/dmm.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
> @@ -8,7 +8,8 @@ translation for initiators which need contiguous dma bus addresses.
>
> Required properties:
> - compatible: Should contain "ti,omap4-dmm" for OMAP4 family
> - Should contain "ti,omap5-dmm" for OMAP5 and DRA7x family
> + Should contain "ti,omap5-dmm" for OMAP5 family
> + Should contain "ti,dra7-dmm" for DRA7xx family
> - reg: Contains DMM register address range (base address and length)
> - interrupts: Should contain an interrupt-specifier for DMM_IRQ.
> - ti,hwmods: Name of the hwmod associated to DMM, which is typically "dmm"
>
Thinking about this now, wouldn't it be better to add a DT property to
enable the work-around? Or we could use soc_device_match() to figure out
that this is a DRA7 SoC.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 4/4] arm: dts: ls1021a: Enable I2C DMA support
From: Esben Haabendal @ 2018-05-23 9:56 UTC (permalink / raw)
To: linux-i2c
Cc: Esben Haabendal, Rob Herring, Mark Rutland, devicetree,
linux-kernel
In-Reply-To: <20180523095623.3347-1-esben.haabendal@gmail.com>
From: Esben Haabendal <eha@deif.com>
Gives substantial performance improvement for transfers larger than 16
bytes (DMA_THRESHOLD). Smaller transfers are unaffected.
Signed-off-by: Esben Haabendal <eha@deif.com>
---
arch/arm/boot/dts/ls1021a.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index c55d479971cc..1e5640701c65 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -363,6 +363,8 @@
interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
clocks = <&clockgen 4 1>;
+ dma-names = "tx", "rx";
+ dmas = <&edma0 1 39>, <&edma0 1 38>;
status = "disabled";
};
@@ -374,6 +376,8 @@
interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
clocks = <&clockgen 4 1>;
+ dma-names = "tx", "rx";
+ dmas = <&edma0 1 37>, <&edma0 1 36>;
status = "disabled";
};
@@ -385,6 +389,8 @@
interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
clocks = <&clockgen 4 1>;
+ dma-names = "tx", "rx";
+ dmas = <&edma0 1 35>, <&edma0 1 34>;
status = "disabled";
};
--
2.17.0
^ permalink raw reply related
* [PATCH 0/4] i2c: imx: Fix and enable DMA support for LS1021A
From: Esben Haabendal @ 2018-05-23 9:56 UTC (permalink / raw)
To: linux-i2c, devicetree; +Cc: Esben Haabendal
From: Esben Haabendal <eha@deif.com>
This patch series fixes two race conditions and minor issues with tracking
the stopped state when something goes wrong.
With that in place, DMA support works with NXP LS1021A, so it is enabled in
the last patch.
Esben Haabendal (4):
i2c: imx: Fix reinit_completion() use
i2c: imx: Fix race condition in dma read
i2c: imx: Simplify stopped state tracking
arm: dts: ls1021a: Enable I2C DMA support
arch/arm/boot/dts/ls1021a.dtsi | 6 ++++++
drivers/i2c/busses/i2c-imx.c | 23 ++++++++++++-----------
2 files changed, 18 insertions(+), 11 deletions(-)
--
2.17.0
^ 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