Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

[sebastian]

On 2021-08-16 14:40, Harry Wentland wrote:

On 2021-08-16 7:10 a.m., Brian Starkey wrote:

On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote:

Hello Brian,
(+Uma in cc)

Thanks for your comments, Let me try to fill-in for Harry to keep the 
design

discussion going. Please find my comments inline.



Thanks, Shashank. I'm back at work now. Had to cut my trip short
due to rising Covid cases and concern for my kids.


On 8/2/2021 10:00 PM, Brian Starkey wrote:




-- snip --



Android doesn't blend in linear space, so any API shouldn't be built
around an assumption of linear blending.



This seems incorrect but I guess ultimately the OS is in control of
this. If we want to allow blending in non-linear space with the new
API we would either need to describe the blending space or the
pre/post-blending gamma/de-gamma.

Any idea if this blending behavior in Android might get changed in
the future?


There is lots of software which blends in sRGB space and designers
adjusted to the incorrect blending in a way that the result looks right.
Blending in linear space would result in incorrectly looking images.



If I am not wrong, we still need linear buffers for accurate Gamut
transformation (SRGB -> BT2020 or other way around) isn't it ?


Yeah, you need to transform the buffer to linear for color gamut
conversions, but then back to non-linear (probably sRGB or gamma 2.2)
for actual blending.

This is why I'd like to have the per-plane "OETF/GAMMA" separate
from tone-mapping, so that the composition transfer function is
independent.





...


+
+Tonemapping in this case could be a simple nits value or `EDR`_ to 
describe

+how to scale the :ref:`SDR luminance`.
+
+Tonemapping could also include the ability to use a 3D LUT which 
might be
+accompanied by a 1D shaper LUT. The shaper LUT is required in 
order to
+ensure a 3D LUT with limited entries (e.g. 9x9x9, or 17x17x17) 
operates
+in perceptual (non-linear) space, so as to evenly spread the 
limited

+entries evenly across the perceived space.


Some terminology care may be needed here - up until this point, I
think you've been talking about "tonemapping" being luminance
adjustment, whereas I'd expect 3D LUTs to be used for gamut
adjustment.



IMO, what harry wants to say here is that, which HW block gets picked 
and
how tone mapping is achieved can be a very driver/HW specific thing, 
where
one driver can use a 1D/Fixed function block, whereas another one can 
choose

more complex HW like a 3D LUT for the same.

DRM layer needs to define only the property to hook the API with core
driver, and the driver can decide which HW to pick and configure for 
the

activity. So when we have a tonemapping property, we might not have a
separate 3D-LUT property, or the driver may fail the atomic_check() 
if both

of them are programmed for different usages.


I still think that directly exposing the HW blocks and their
capabilities is the right approach, rather than a "magic" tonemapping
property.

Yes, userspace would need to have a good understanding of how to use
that hardware, but if the pipeline model is standardised that's the
kind of thing a cross-vendor library could handle.



One problem with cross-vendor libraries is that they might struggle
to really be cross-vendor when it comes to unique HW behavior. Or
they might pick sub-optimal configurations as they're not aware of
the power impact of a configuration. What's an optimal configuration
might differ greatly between different HW.

We're seeing this problem with "universal" planes as well.


I'm repeating what has been said before but apparently it has to be said
again: if a property can't be replicated exactly in a shader the
property is useless. If your hardware is so unique that it can't give us
the exact formula we expect you cannot expose the property.

Maybe my view on power consumption is simplistic but I would expect enum
< 1d lut < 3d lut < shader. Is there more to it?

Either way if the fixed KMS pixel pipeline is not sufficient to expose
the intricacies of real hardware the right move would be to make the KMS
pixel pipeline more dynamic, expose more hardware specifics and create a
hardware specific user space like mesa. Moving the whole compositing
with all its policies and decision making into the kernel is exactly the
wrong way to go.

Laurent Pinchart put this very well:
https://lists.freedesktop.org/archives/dri-devel/2021-June/311689.html


It would definitely be good to get some compositor opinions here.



For this we'll probably have to wait for Pekka's input when he's
back from his vacation.


Cheers,
-Brian

Re: New uAPI for color management proposal and feedback request v2

[sebastian]

Greetings,

Original proposal: 
https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg62387.html


Abstract: Add "preferred color format", "active color format", "active 
bpc", and "active Broadcast RGB" drm properties,

to control color information send to the monitor.

It seems that the "preferred-" properties is not what is actually the 
most useful for the userspace devs.


Preferable (Note: with only a sample size of 2 people) would be a 
"force color format" property. If the color format is
not available for the current Monitor and GPU combo. the TEST_ONLY 
check should fail and the property should not be setable.


This however opens another problem: When a Monitor is disconnected and 
a new one is connected, the drm properties do not
get resetted. So if the old monitor did allow to set for example 
ycbcr420, but the new monitor does not support this
color format at all, it will stay permanently black until the drm 
property is set to a correct value by hand. This is

not an expected behavior imho.


User space is aware of output changes and already has to set properties 
such

that the new output will light up. So IMO what you describe is expected
behavior. What makes this still a bit hary is when you switch from user 
space
which set the property to user space which is not aware of the property 
but
this is a more general problem that already exists for all new 
properties. The

solution here is a reset mechanism for user space. More context:
https://oftc.irclog.whitequark.org/dri-devel/2021-06-16#1623837713-1623842163;

So a discussion questions: Does it make sense that connector properties 
are keep for different Monitors?


If no: On connecting a new Monitor all atomic drm properties should be 
reset to a default value.


I have an idea how this could be implemented (correct me if i'm wrong): 
When an atomic property is attached it get
assigned an inital value. But if I understood the docu correctly, this 
value is ignored because atomic properties use
the getter and setter methods when their values are read or written. My 
implementation suggestion would be to iterate
over all attached atomic properties once a new monitor is connected and 
reset them to this initial value, which should
be unchanged since initialization? This assumes that besides the 
initial value being unused it's still a sane default

for all drivers.

Kind Regards,

Werner Sembach

Re: [PATCH v2 1/1] kernel.h: Split out panic and oops helpers

[Sebastian Reichel]

Hi,

On Fri, Apr 09, 2021 at 01:02:50PM +0300, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
> 
> There are several purposes of doing this:
> - dropping dependency in bug.h
> - dropping a loop by moving out panic_notifier.h
> - unload kernel.h from something which has its own domain
> 
> At the same time convert users tree-wide to use new headers, although
> for the time being include new header back to kernel.h to avoid twisted
> indirected includes for existing users.
> 
> Signed-off-by: Andy Shevchenko 
> Reviewed-by: Bjorn Andersson 
> Acked-by: Mike Rapoport 
> Acked-by: Corey Minyard 
> Acked-by: Christian Brauner 
> Acked-by: Arnd Bergmann 
> Acked-by: Kees Cook 
> Acked-by: Wei Liu 
> Acked-by: Rasmus Villemoes 
> Signed-off-by: Andrew Morton 
> ---
> v2:
>  - fixed all errors with allmodconfig on x86_64 (Andrew)
>  - checked with allyesconfig on x86_64
>  - additionally grepped source code for panic notifier list usage
>and converted all users
>  - elaborated commit message (Luis)
>  - collected given tags (incl. Andrew's SoB, see below)
> 
> I added Andrew's SoB since part of the fixes I took from him. Andrew,
> feel free to amend or tell me how you want me to do.
> 
> [...]
>  drivers/power/reset/ltc2952-poweroff.c|  1 +
> [...]

Acked-by: Sebastian Reichel 

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv2 4/5] dt-bindings: arm: fsl: add GE B1x5pv2 boards

[Sebastian Reichel]

Document the compatible for GE B1x5pv2 boards.

Signed-off-by: Sebastian Reichel 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index e3c50f231d71..6e5b14c75325 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -400,6 +400,17 @@ properties:
   - const: armadeus,imx6dl-apf6 # APF6 (Solo) SoM
   - const: fsl,imx6dl
 
+  - description: i.MX6DL based congatec QMX6 Boards
+items:
+  - enum:
+  - ge,imx6dl-b105v2  # General Electric B105v2
+  - ge,imx6dl-b105pv2 # General Electric B105Pv2
+  - ge,imx6dl-b125v2  # General Electric B125v2
+  - ge,imx6dl-b125pv2 # General Electric B125Pv2
+  - ge,imx6dl-b155v2  # General Electric B155v2
+  - const: congatec,qmx6
+  - const: fsl,imx6dl
+
   - description: i.MX6DL based DFI FS700-M60-6DL Board
 items:
   - const: dfi,fs700-m60-6dl
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv2 3/5] dt-bindings: vendor-prefixes: add congatec

[Sebastian Reichel]

Document binding for congatec.

Signed-off-by: Sebastian Reichel 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index c88b1cfb52cb..10e3ce8a29c5 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -247,6 +247,8 @@ patternProperties:
 description: Colorful GRP, Shenzhen Xueyushi Technology Ltd.
   "^compulab,.*":
 description: CompuLab Ltd.
+  "^congatec,.*":
+description: congatec GmbH
   "^coreriver,.*":
 description: CORERIVER Semiconductor Co.,Ltd.
   "^corpro,.*":
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv2 2/5] drm/imx: Add 8 pixel alignment fix

[Sebastian Reichel]

Some standard resolutions like 1366x768 do not work properly with
i.MX6 SoCs, since the horizontal resolution needs to be aligned
to 8 pixels (so 1360x768 or 1368x768 would work).

This patch allocates framebuffers allocated to 8 pixels. The extra
time required to send the extra pixels are removed from the blank
time. In order to expose the correct display size to userspace,
the stride is increased without increasing the width.

Without this patch systems with this display resolution hang
indefinitely during boot up.

Suggested-by: Boris Brezillon 
Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 19 ++-
 drivers/gpu/drm/imx/imx-ldb.c  |  5 +
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 11 ++-
 drivers/gpu/drm/imx/ipuv3-plane.c  | 19 +++
 drivers/gpu/ipu-v3/ipu-dc.c|  5 +
 drivers/gpu/ipu-v3/ipu-di.c|  7 +++
 6 files changed, 60 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index e6a88c8cbd69..8457b9788cda 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -145,9 +145,26 @@ static const struct drm_ioctl_desc imx_drm_ioctls[] = {
/* none so far */
 };
 
+static int imx_drm_dumb_create(struct drm_file *file_priv,
+  struct drm_device *drm,
+  struct drm_mode_create_dumb *args)
+{
+   u32 width = args->width;
+   int ret;
+
+   args->width = ALIGN(width, 8);
+
+   ret = drm_gem_cma_dumb_create(file_priv, drm, args);
+   if (ret)
+   return ret;
+
+   args->width = width;
+   return ret;
+}
+
 static const struct drm_driver imx_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
-   DRM_GEM_CMA_DRIVER_OPS,
+   DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(imx_drm_dumb_create),
.ioctls = imx_drm_ioctls,
.num_ioctls = ARRAY_SIZE(imx_drm_ioctls),
.fops   = &imx_drm_driver_fops,
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index ffdc492c5bc5..53132ddf9587 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -274,6 +274,11 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder 
*encoder,
 "%s: mode exceeds 85 MHz pixel clock\n", __func__);
}
 
+   if (!IS_ALIGNED(mode->hdisplay, 8)) {
+   dev_warn(ldb->dev,
+"%s: hdisplay does not align to 8 byte\n", __func__);
+   }
+
if (dual) {
serial_clk = 3500UL * mode->clock;
imx_ldb_set_clock(ldb, mux, 0, serial_clk, di_clk);
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index e6431a227feb..9c8829f945b2 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -305,10 +305,19 @@ static void ipu_crtc_mode_set_nofb(struct drm_crtc *crtc)
sig_cfg.vsync_pin = imx_crtc_state->di_vsync_pin;
 
drm_display_mode_to_videomode(mode, &sig_cfg.mode);
+   if (!IS_ALIGNED(sig_cfg.mode.hactive, 8)) {
+   unsigned int new_hactive = ALIGN(sig_cfg.mode.hactive, 8);
+
+   dev_warn(ipu_crtc->dev, "8-pixel align hactive %d -> %d\n",
+sig_cfg.mode.hactive, new_hactive);
+
+   sig_cfg.mode.hfront_porch = new_hactive - sig_cfg.mode.hactive;
+   sig_cfg.mode.hactive = new_hactive;
+   }
 
ipu_dc_init_sync(ipu_crtc->dc, ipu_crtc->di,
 mode->flags & DRM_MODE_FLAG_INTERLACE,
-imx_crtc_state->bus_format, mode->hdisplay);
+imx_crtc_state->bus_format, sig_cfg.mode.hactive);
ipu_di_init_sync_panel(ipu_crtc->di, &sig_cfg);
 }
 
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index fa5009705365..06ad6dece61f 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -30,6 +30,11 @@ to_ipu_plane_state(struct drm_plane_state *p)
return container_of(p, struct ipu_plane_state, base);
 }
 
+static unsigned int ipu_src_rect_width(const struct drm_plane_state *state)
+{
+   return ALIGN(drm_rect_width(&state->src) >> 16, 8);
+}
+
 static inline struct ipu_plane *to_ipu_plane(struct drm_plane *p)
 {
return container_of(p, struct ipu_plane, base);
@@ -415,6 +420,12 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if (old_fb && fb->pitches[0] != old_fb->pitches[0])
crtc_state->mode_changed = true;
 
+   if (ALIGN(fb->width, 8) * fb->format->cpp[0] >
+   fb->pitches[0] + fb->offsets[0]) {
+   d

[PATCHv2 1/5] rtc: m41t80: add support for fixed clock

[Sebastian Reichel]

Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The
modules SQW clock output defaults to 32768 Hz. This behaviour is
used to provide the i.MX6 CKIL clock. Once the RTC driver is probed,
the clock is disabled and all i.MX6 functionality depending on
the 32 KHz clock has undefined behaviour. For example when using
the hardware watchdog the system will likely do arbitrary reboots.

Referencing the m41t62 directly results in a deadlock. The kernel
will see, that i.MX6 system clock needs the RTC clock and do probe
deferral. But the i.MX6 I2C module never becomes usable without the
i.MX6 CKIL clock and thus the RTC's clock will not be probed. So
from the kernel's perspective this is a chicken-and-egg problem.

Technically everything is fine by not touching anything, since
the RTC clock correctly enables the clock on reset (i.e. on
battery backup power loss) and also the bootloader enables it
in case an something (e.g. an unpatched kernel) disabled this
incorrectly.

A workaround for this issue is describing the square wave pin
as fixed-clock, which is registered early and basically how
this pin is used on the i.MX6.

Suggested-by: Saravana Kannan 
Signed-off-by: Sebastian Reichel 
---
 Documentation/devicetree/bindings/rtc/rtc-m41t80.txt |  9 +
 drivers/rtc/rtc-m41t80.c | 12 
 2 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt 
b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
index c746cb221210..cdd196b1e9bd 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
@@ -21,10 +21,19 @@ Optional properties:
   clock name
 - wakeup-source: Enables wake up of host system on alarm
 
+Optional child node:
+- clock: Provide this if the square wave pin is used as boot-enabled fixed 
clock.
+
 Example:
rtc@68 {
compatible = "st,m41t80";
reg = <0x68>;
interrupt-parent = <&UIC0>;
interrupts = <0x9 0x8>;
+
+   clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   };
};
diff --git a/drivers/rtc/rtc-m41t80.c b/drivers/rtc/rtc-m41t80.c
index 89128fc29ccc..b3ece42b6f90 100644
--- a/drivers/rtc/rtc-m41t80.c
+++ b/drivers/rtc/rtc-m41t80.c
@@ -544,10 +544,22 @@ static struct clk *m41t80_sqw_register_clk(struct 
m41t80_data *m41t80)
 {
struct i2c_client *client = m41t80->client;
struct device_node *node = client->dev.of_node;
+   struct device_node *fixed_clock;
struct clk *clk;
struct clk_init_data init;
int ret;
 
+   fixed_clock = of_get_child_by_name(node, "clock");
+   if (fixed_clock) {
+   /*
+* skip registering square wave clock when a fixed
+* clock has been registered. The fixed clock is
+* registered automatically when being referenced.
+*/
+   of_node_put(fixed_clock);
+   return 0;
+   }
+
/* First disable the clock */
ret = i2c_smbus_read_byte_data(client, M41T80_REG_ALARM_MON);
if (ret < 0)
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv2 5/5] ARM: dts: imx6: Add GE B1x5v2

[Sebastian Reichel]

This adds device tree files for the General Electric Healthcare
(GEHC) B1x5v2 series. All models make use of Congatec's QMX6 module,
which is described in its own device tree include, so that it can
also be used by other boards.

Signed-off-by: Sebastian Reichel 
---
 arch/arm/boot/dts/Makefile|   5 +
 arch/arm/boot/dts/imx6dl-b105pv2.dts  |  35 ++
 arch/arm/boot/dts/imx6dl-b105v2.dts   |  35 ++
 arch/arm/boot/dts/imx6dl-b125pv2.dts  |  33 ++
 arch/arm/boot/dts/imx6dl-b125v2.dts   |  33 ++
 arch/arm/boot/dts/imx6dl-b155v2.dts   |  36 ++
 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi | 434 ++
 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi  |  61 +++
 arch/arm/boot/dts/imx6dl-qmx6.dtsi| 624 ++
 9 files changed, 1296 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-b105pv2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b105v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b125pv2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b125v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b155v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi
 create mode 100644 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi
 create mode 100644 arch/arm/boot/dts/imx6dl-qmx6.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f8f09c5066e7..811f22ed1e37 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -515,6 +515,11 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-dms-ba16.dtb \
imx6q-emcon-avari.dtb \
imx6q-evi.dtb \
+   imx6dl-b105v2.dtb \
+   imx6dl-b105pv2.dtb \
+   imx6dl-b125v2.dtb \
+   imx6dl-b125pv2.dtb \
+   imx6dl-b155v2.dtb \
imx6q-gk802.dtb \
imx6q-gw51xx.dtb \
imx6q-gw52xx.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-b105pv2.dts 
b/arch/arm/boot/dts/imx6dl-b105pv2.dts
new file mode 100644
index ..0d5be2f9471f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b105pv2.dts
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B105Pv2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5pv2.dtsi"
+
+/ {
+   model = "General Electric B105Pv2";
+   compatible = "ge,imx6dl-b105pv2", "congatec,qmx6", "fsl,imx6dl";
+
+   panel {
+   compatible = "auo,g101evn010";
+   status = "okay";
+   };
+};
+
+&i2c3 {
+   touchscreen@41 {
+   reg = <0x41>;
+   compatible = "ilitek,ili251x";
+
+   pinctrl-names = "default";
+   pinctrl-0 =<&pinctrl_q7_gpio0>;
+   interrupt-parent = <&gpio5>;
+   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+   reset-gpios = <&tca6424a 21 GPIO_ACTIVE_LOW>;
+
+   touchscreen-size-x = <1280>;
+   touchscreen-size-y = <800>;
+   };
+};
diff --git a/arch/arm/boot/dts/imx6dl-b105v2.dts 
b/arch/arm/boot/dts/imx6dl-b105v2.dts
new file mode 100644
index ..72a085348304
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b105v2.dts
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B105v2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5v2.dtsi"
+
+/ {
+   model = "General Electric B105v2";
+   compatible = "ge,imx6dl-b105v2", "congatec,qmx6", "fsl,imx6dl";
+
+   panel {
+   compatible = "auo,g101evn010";
+   status = "okay";
+   };
+};
+
+&i2c3 {
+   touchscreen@41 {
+   reg = <0x41>;
+   compatible = "ilitek,ili251x";
+
+   pinctrl-names = "default";
+   pinctrl-0 =<&pinctrl_q7_gpio0>;
+   interrupt-parent = <&gpio5>;
+   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+   reset-gpios = <&tca6424a 21 GPIO_ACTIVE_LOW>;
+
+   touchscreen-size-x = <1280>;
+   touchscreen-size-y = <800>;
+   };
+};
diff --git a/arch/arm/boot/dts/imx6dl-b125pv2.dts 
b/arch/arm/boot/dts/imx6dl-b125pv2.dts
new file mode 100644
index ..8fd6c8ed6750
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b125pv2.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B125Pv2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5pv2.dtsi"
+
+/ {
+   model = "General Electric B125Pv2";
+   compatible = "ge,imx6dl-b125pv2", "congatec,qmx6", "fsl,imx6d

[PATCHv2 0/5] Support for GE B1x5v2 and B1x5Pv2

[Sebastian Reichel]

Hi,

This series adds support for another General Electric patient
monitor series (similar to existing Bx50v3), which is based on
i.MX6DL using Congatec's QMX6 module.

The module uses an I2C RTC to provide the i.MX6 32768 Hz clock,
so it's important to keep it enabled. Not doing so results in
incorrect timings of watchdog and i.MX6 RTC. The bootloader
enables the watchdog, so disabling the clock results in system
reboot. [0]

The second patch is required for B155v2, which uses a 1366x768
G156XTN01 panel. The 1366 width is not supported by the display
pipeline and result in boot hanging without the patch. [1]

Patches 3+4 are updating DT bindings for the new board compatible
values.

Patch 5 adds the board files.

Changes since PATCHv1:
 * 
https://lore.kernel.org/lkml/20210222171247.97609-1-sebastian.reic...@collabora.com/
 * drop patch 5 (applied)
 * instead of using 'protected-clocks' in RTC node, add fixed-clock
   node as suggested by Saravana Kannan
 * rebased to current master (68a32ba14177)

Thanks,

[0] There has been a discussion for the problem on the mailinglists
last year. The discussion died off, when I told people their ideas
don't work. I hope using protected-clocks is fine for this usecase.

https://lore.kernel.org/linux-clk/20191108170135.9053-1-sebastian.reic...@collabora.com/

[1] I've sent this before as a separate patch in September, but
nobody seemed to care. This adds full context for the problem.

https://lore.kernel.org/dri-devel/20200910162831.321556-1-sebastian.reic...@collabora.com/

-- Sebastian

Sebastian Reichel (5):
  rtc: m41t80: add support for fixed clock
  drm/imx: Add 8 pixel alignment fix
  dt-bindings: vendor-prefixes: add congatec
  dt-bindings: arm: fsl: add GE B1x5pv2 boards
  ARM: dts: imx6: Add GE B1x5v2

 .../devicetree/bindings/arm/fsl.yaml  |  11 +
 .../devicetree/bindings/rtc/rtc-m41t80.txt|   9 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm/boot/dts/Makefile|   5 +
 arch/arm/boot/dts/imx6dl-b105pv2.dts  |  35 +
 arch/arm/boot/dts/imx6dl-b105v2.dts   |  35 +
 arch/arm/boot/dts/imx6dl-b125pv2.dts  |  33 +
 arch/arm/boot/dts/imx6dl-b125v2.dts   |  33 +
 arch/arm/boot/dts/imx6dl-b155v2.dts   |  36 +
 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi | 434 
 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi  |  61 ++
 arch/arm/boot/dts/imx6dl-qmx6.dtsi| 624 ++
 drivers/gpu/drm/imx/imx-drm-core.c|  19 +-
 drivers/gpu/drm/imx/imx-ldb.c |   5 +
 drivers/gpu/drm/imx/ipuv3-crtc.c  |  11 +-
 drivers/gpu/drm/imx/ipuv3-plane.c |  19 +-
 drivers/gpu/ipu-v3/ipu-dc.c   |   5 +
 drivers/gpu/ipu-v3/ipu-di.c   |   7 +
 drivers/rtc/rtc-m41t80.c  |  12 +
 19 files changed, 1390 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6dl-b105pv2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b105v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b125pv2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b125v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b155v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi
 create mode 100644 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi
 create mode 100644 arch/arm/boot/dts/imx6dl-qmx6.dtsi

-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 1/3] drm/color: Add RGB Color encodings

[Sebastian Wick]

On 2021-04-26 20:56, Harry Wentland wrote:

On 2021-04-26 2:07 p.m., Ville Syrjälä wrote:

On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote:

From: Bhawanpreet Lakha 

Add the following color encodings
- RGB versions for BT601, BT709, BT2020
- DCI-P3: Used for digital movies

Signed-off-by: Bhawanpreet Lakha 
Signed-off-by: Harry Wentland 
---
  drivers/gpu/drm/drm_color_mgmt.c | 4 
  include/drm/drm_color_mgmt.h | 4 
  2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
b/drivers/gpu/drm/drm_color_mgmt.c

index bb14f488c8f6..a183ebae2941 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -469,6 +469,10 @@ static const char * const color_encoding_name[] 
= {

[DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
[DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
[DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
+   [DRM_COLOR_RGB_BT601] = "ITU-R BT.601 RGB",
+   [DRM_COLOR_RGB_BT709] = "ITU-R BT.709 RGB",
+   [DRM_COLOR_RGB_BT2020] = "ITU-R BT.2020 RGB",
+   [DRM_COLOR_P3] = "DCI-P3",


These are a totally different thing than the YCbCr stuff.
The YCbCr stuff just specifies the YCbCr<->RGB converison matrix,
whereas these are I guess supposed to specify the 
primaries/whitepoint?
But without specifying what we're converting *to* these mean 
absolutely

nothing. Ie. I don't think they belong in this property.



If this is the intention I don't see it documented.

I might have overlooked something but do we have a way to explicitly
specify today what *to* format the YCbCr color encodings convert into?
Would that be a combination of the output color encoding specified via
colorspace_property and the color space encoded in the primaries and
whitepoint of the hdr_output_metadata?

Fundamentally I don't see how the use of this property differs,
whether you translate from YCbCr or from RGB. In either case you're
converting from the defined input color space and pixel format to an
output color space and pixel format.


The previous proposals around this topic have suggested a new
property to specify a conversion matrix either explicitly, or
via a separate enum (which would specify both the src and dst
colorspaces). I've always argued the enum approach is needed
anyway since not all hardware has a programmable matrix for
this. But a fully programmable matrix could be nice for tone
mapping purposes/etc, so we may want to make sure both are
possible.

As for the transfer func, the proposals so far have mostly just
been to expose a programmable degamma/gamma LUTs for each plane.
But considering how poor the current gamma uapi is we've thrown
around some ideas how to allow the kernel to properly expose the
hw capabilities. This is one of those ideas:
https://lists.freedesktop.org/archives/dri-devel/2019-April/212886.html>> 
I think that basic idea could be also be extended to allow fixed

curves in case the hw doesn't have a fully programmable LUT. But
dunno if that's relevant for your hw.



The problem with exposing gamma, whether per-plane or per-crtc, is
that it is hard to define an API that works for all the HW out there.
The capabilities for different HW differ a lot, not just between
vendors but also between generations of a vendor's HW.


Introducing another API if hardware is sufficiently different doesn't
seem like the worst idea. At least it sounds a lot more tractable than
teaching the kernel about all the different use cases, opinions and
nuances that arise from color management.

In the end generic user space must always be able to fall back to
software so the worst case is that it won't be able to offload an
operation if it doesn't know about a new API.


Another reason I'm proposing to define the color space (and gamma) of
a plane is to make this explicit. Up until the color space and gamma
of a plane or framebuffer are not well defined, which leads to drivers
assuming the color space and gamma of a buffer (for blending and other
purposes) and might lead to sub-optimal outcomes.


Blending only is "correct" with linear light so that property of the
color space is important. However, why does the kernel have to be
involved here? As long as user space knows that for correct blending the
data must represent linear light and knows when in the pipeline blending
happens it can make sure that the data at that point in the pipeline
contains linear light.

What other purposes are there?

In general I agree with the others that user space only wants a pipeline
of transformations where the mechanism, the order and ideally the
precision is defined.


Harry

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv1] drm/omap: get fbdev working for manually updated display

[Sebastian Reichel]

Running a legacy application, which directly uses /dev/fb0
currently results in display not being refreshed when the
application mmaps the memory instead of calling write().

Deferred IO support will also schedule dirty_work with the
damage collected from the mmap page writes and thus gets
some more legacy applications working.

Delay frequency settings have been taken over from
drm_fb_helper_generic_probe().

Reported-by: Carl Philipp Klemm 
Tested-by: Carl Philipp Klemm 
Signed-off-by: Sebastian Reichel 
---
Hi,

I still need to fix my Droid 4, so I only compile tested this
myself.

-- Sebastian
---
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index 42eac6ad12bd..fc3897d2d7cc 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -87,6 +87,11 @@ static const struct fb_ops omap_fb_ops = {
.fb_imageblit = drm_fb_helper_sys_imageblit,
 };
 
+static struct fb_deferred_io omap_fb_defio = {
+   .delay  = HZ / 20,
+   .deferred_io= drm_fb_helper_deferred_io,
+};
+
 static int omap_fbdev_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
 {
@@ -176,6 +181,9 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
 
drm_fb_helper_fill_info(fbi, helper, sizes);
 
+   fbi->fbdefio = &omap_fb_defio;
+   fb_deferred_io_init(fbi);
+
dev->mode_config.fb_base = dma_addr;
 
fbi->screen_buffer = omap_gem_vaddr(fbdev->bo);

base-commit: 152d32aa846835987966fd20ee1143b0e05036a0
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/omap: dsi: Add missing IRQF_ONESHOT

[Sebastian Reichel]

Hi,

On Tue, Mar 23, 2021 at 05:34:53PM +0800, Yang Li wrote:
> fixed the following coccicheck:
> ./drivers/gpu/drm/omapdrm/dss/dsi.c:4329:7-27: ERROR: Threaded IRQ with
> no primary handler requested without IRQF_ONESHOT
> 
> Reported-by: Abaci Robot 
> Signed-off-by: Yang Li 
> ---

Reviewed-by: Sebastian Reichel 

Also maybe add this, so that it is properly backported. OTOH old code did
not have IRQF_ONESHOT either.

Fixes: 4c1b935fea54 ("drm/omap: dsi: move TE GPIO handling into core")

-- Sebastian

> Change in v2:
> -Modify the fourth parameter, not the first
> 
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index b31d750..5f1722b 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -4327,7 +4327,8 @@ static int omap_dsi_register_te_irq(struct dsi_data 
> *dsi,
>   irq_set_status_flags(te_irq, IRQ_NOAUTOEN);
>  
>   err = request_threaded_irq(te_irq, NULL, omap_dsi_te_irq_handler,
> -IRQF_TRIGGER_RISING, "TE", dsi);
> +IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> +"TE", dsi);
>   if (err) {
>   dev_err(dsi->dev, "request irq failed with %d\n", err);
>   gpiod_put(dsi->te_gpio);
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/omap: dsi: fix unreachable code in dsi_vc_send_short()

[Sebastian Reichel]

Hi,

On Tue, Jan 26, 2021 at 05:55:11AM -0800, menglong8.d...@gmail.com wrote:
> From: Menglong Dong 
> 
> The 'r' in dsi_vc_send_short() is of type 'unsigned int', so the
> 'r < 0' can't be true.
> 
> Fix this by introducing a 'err' insteaded.
> 
> Fixes: 1ed6253856cb
> ("drm/omap: dsi: switch dsi_vc_send_long/short to mipi_dsi_msg")

Documentation/process/submitting-patches.rst:

If your patch fixes a bug in a specific commit, e.g. you found an
issue using ``git bisect``, please use the 'Fixes:' tag with the
first 12 characters of the SHA-1 ID, and the one line summary. Do
not split the tag across multiple lines, tags are exempt from the
"wrap at 75 columns" rule in order to simplify parsing scripts.

Otherwise:

Reviewed-by: Sebastian Reichel 

-- Sebastian

> Signed-off-by: Menglong Dong 
> ---
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 8e11612f5fe1..febcc87ddfe1 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -2149,11 +2149,12 @@ static int dsi_vc_send_short(struct dsi_data *dsi, 
> int vc,
>const struct mipi_dsi_msg *msg)
>  {
>   struct mipi_dsi_packet pkt;
> + int err;
>   u32 r;
>  
> - r = mipi_dsi_create_packet(&pkt, msg);
> - if (r < 0)
> - return r;
> + err = mipi_dsi_create_packet(&pkt, msg);
> + if (err)
> + return err;
>  
>   WARN_ON(!dsi_bus_is_locked(dsi));
>  
> -- 
> 2.25.1
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] Support second Image Signal Processor on rk3399

[Sebastian Fricke]

Hey Heiko,

I have tested your patch set on my nanoPC-T4, here is a complete log
with:
- relevant kernel log entries
- system information
- media ctl output
- sysfs entry information

https://paste.debian.net/1183874/

Additionally, to your patchset I have applied the following patches:
https://github.com/initBasti/Linux_kernel_media_tree_fork/commits/dual_cam_setup

And just to not cause confusion the `media_dev` entries come from this
unmerged series:
https://patchwork.kernel.org/project/linux-media/list/?series=426269

I have actually been able to stream with both of my cameras at the same
time using the libcamera cam command.
I would like to thank you a lot for making this possible.

If you like to you can add:
Tested-by: Sebastian Fricke 

On 02.02.2021 15:56, Heiko Stuebner wrote:

The rk3399 has two ISPs and right now only the first one is usable.
The second ISP is connected to the TXRX dphy on the soc.

The phy of ISP1 is only accessible through the DSI controller's
io-memory, so this series adds support for simply using the dsi
controller is a phy if needed.

That solution is needed at least on rk3399 and rk3288 but no-one
has looked at camera support on rk3288 at all, so right now
only implement the rk3399 specifics.


Heiko Stuebner (6):
 drm/rockchip: dsi: add own additional pclk handling
 dt-bindings: display: rockchip-dsi: add optional #phy-cells property
 drm/rockchip: dsi: add ability to work as a phy instead of full dsi
 arm64: dts: rockchip: add #phy-cells to mipi-dsi1
 arm64: dts: rockchip: add cif clk-control pinctrl for rk3399
 arm64: dts: rockchip: add isp1 node on rk3399

.../display/rockchip/dw_mipi_dsi_rockchip.txt |   1 +
arch/arm64/boot/dts/rockchip/rk3399.dtsi  |  39 ++
drivers/gpu/drm/rockchip/Kconfig  |   2 +
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   | 342 ++
4 files changed, 384 insertions(+)

--
2.29.2


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] Support second Image Signal Processor on rk3399

[Sebastian Fricke]

Hey Heiko,

On 03.02.2021 20:54, Heiko Stübner wrote:

Hi Sebastian,

Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke:

Hey Heiko,

I have tested your patch set on my nanoPC-T4, here is a complete log
with:
- relevant kernel log entries
- system information
- media ctl output
- sysfs entry information

https://paste.debian.net/1183874/

Additionally, to your patchset I have applied the following patches:
https://github.com/initBasti/Linux_kernel_media_tree_fork/commits/dual_cam_setup

And just to not cause confusion the `media_dev` entries come from this
unmerged series:
https://patchwork.kernel.org/project/linux-media/list/?series=426269

I have actually been able to stream with both of my cameras at the same
time using the libcamera cam command.
I would like to thank you a lot for making this possible.


Thanks for testing a dual camera setup. On my board I could only test
the second ISP. And really glad it works for you tool :-) .

Out of curiosity, do you also see that green tint in the images the cameras
produce?


Yes, I do. Actually, I currently have two forms of a green tint, on my
OV13850 everything is quite dark and greenish, which is caused by the
missing 3A algorithms. On my OV4689, I have big patches of the image
with bright green color and flickering, I investigated if this is
connected to the 2nd ISP instance, but that doesn't seem to be the case
as I have the same results when I switch the CSI ports of the cameras.

I have found another issue, while testing I discovered following
issue:
When I start the system with an HDMI monitor connected, then the camera
on the 2nd port doesn't work. This is probably because the RX/TX is
reserved as a TX.
But it made me wonder because if the system has an RX, a TX, and
an RX/TX, why isn't the pure TX used by the monitor and the
cameras take RX and RX/TX?
Or do you think that this is maybe a malfunction of this patch?



Thanks
Heiko


Greetings,
Sebastian





If you like to you can add:
Tested-by: Sebastian Fricke 

On 02.02.2021 15:56, Heiko Stuebner wrote:
>The rk3399 has two ISPs and right now only the first one is usable.
>The second ISP is connected to the TXRX dphy on the soc.
>
>The phy of ISP1 is only accessible through the DSI controller's
>io-memory, so this series adds support for simply using the dsi
>controller is a phy if needed.
>
>That solution is needed at least on rk3399 and rk3288 but no-one
>has looked at camera support on rk3288 at all, so right now
>only implement the rk3399 specifics.
>
>
>Heiko Stuebner (6):
>  drm/rockchip: dsi: add own additional pclk handling
>  dt-bindings: display: rockchip-dsi: add optional #phy-cells property
>  drm/rockchip: dsi: add ability to work as a phy instead of full dsi
>  arm64: dts: rockchip: add #phy-cells to mipi-dsi1
>  arm64: dts: rockchip: add cif clk-control pinctrl for rk3399
>  arm64: dts: rockchip: add isp1 node on rk3399
>
> .../display/rockchip/dw_mipi_dsi_rockchip.txt |   1 +
> arch/arm64/boot/dts/rockchip/rk3399.dtsi  |  39 ++
> drivers/gpu/drm/rockchip/Kconfig  |   2 +
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   | 342 ++
> 4 files changed, 384 insertions(+)
>







___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] Support second Image Signal Processor on rk3399

[Sebastian Fricke]

Hey Heiko,

On 10.02.2021 12:15, Heiko Stübner wrote:

Hi Sebastian,

Am Freitag, 5. Februar 2021, 15:55:56 CET schrieb Heiko Stübner:

Hi Sebastian,

I did some tests myself today as well and can confirm your
hdmi related finding - at least when plugged in on boot.

I tried some combinations of camera vs. hdmi and it seems
really only when hdmi is plugged in on boot


as you can see in v2, it should work now even with hdmi
connected on boot. My patch ignored the grf-clock when
doing the grf-based init.

All clocks are on during boot and I guess the hdmi-driver
did disable it after its probe. The phy_power_on functions
did handle it correctly already, so it was only happening
with hdmi connected on boot.


Thank you very much for solving that problem, I've tested the scenarios
described below and it works like a charm. (With your V2)



Btw. do you plan on submitting your ov13850 driver
soonish?


Actually, I have posted the patch already see here:
https://patchwork.kernel.org/project/linux-media/patch/20210130182313.32903-2-sebastian.fri...@posteo.net/

I currently review the requested changes and questions and will soon
post a second version, but I expect quite some time until it is actually
merged.




Heiko


Greetings,
Sebastian






(1)
- boot
- camera
--> works

(2)
- boot
- camera
- hdmi plugged in
- hdmi works
- camera
--> works

(3)
- hdmi plugged in
- boot
- hdmi works
- camera
--> camera doesn't work

(4)
- boot
- hdmi plugged in
- hdmi works
- camera
-> camera works


With a bit of brute-force [0] it seems the camera also works again even
with hdmi connected on boot. So conclusion would be that some clock
is misbehaving.

Now we'll "only" need to find out which one that is.


Heiko


[0]
Don't disable any clock gates

diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 070dc47e95a1..8daf1fc3388c 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -61,6 +61,9 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)

set ^= enable;

+if (!enable)
+return;
+
if (gate->lock)
spin_lock_irqsave(gate->lock, flags);
else



Am Freitag, 5. Februar 2021, 09:15:47 CET schrieb Heiko Stübner:
> Hi Sebastian,
>
> Am Freitag, 5. Februar 2021, 07:43:35 CET schrieb Sebastian Fricke:
> > On 03.02.2021 20:54, Heiko Stübner wrote:
> > >Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke:
> > >> I have tested your patch set on my nanoPC-T4, here is a complete log
> > >> with:
> > >> - relevant kernel log entries
> > >> - system information
> > >> - media ctl output
> > >> - sysfs entry information
> > >>
> > >> https://paste.debian.net/1183874/
> > >>
> > >> Additionally, to your patchset I have applied the following patches:
> > >> 
https://github.com/initBasti/Linux_kernel_media_tree_fork/commits/dual_cam_setup
> > >>
> > >> And just to not cause confusion the `media_dev` entries come from this
> > >> unmerged series:
> > >> https://patchwork.kernel.org/project/linux-media/list/?series=426269
> > >>
> > >> I have actually been able to stream with both of my cameras at the same
> > >> time using the libcamera cam command.
> > >> I would like to thank you a lot for making this possible.
> > >
> > >Thanks for testing a dual camera setup. On my board I could only test
> > >the second ISP. And really glad it works for you tool :-) .
> > >
> > >Out of curiosity, do you also see that green tint in the images the cameras
> > >produce?
> >
> > Yes, I do. Actually, I currently have two forms of a green tint, on my
> > OV13850 everything is quite dark and greenish, which is caused by the
> > missing 3A algorithms. On my OV4689, I have big patches of the image
> > with bright green color and flickering, I investigated if this is
> > connected to the 2nd ISP instance, but that doesn't seem to be the case
> > as I have the same results when I switch the CSI ports of the cameras.
> >
> > I have found another issue, while testing I discovered following
> > issue:
> > When I start the system with an HDMI monitor connected, then the camera
> > on the 2nd port doesn't work. This is probably because the RX/TX is
> > reserved as a TX.
> > But it made me wonder because if the system has an RX, a TX, and
> > an RX/TX, why isn't the pure TX used by the monitor and the
> > cameras take RX and RX/TX?
> > Or do you think that this is maybe a malfunction of this patch?
>
> I don't think it is an issue with this specific series, but still puzzling.
>
> I.e. the

Re: [PATCH v4] MAINTAINERS: move Milo Kim to credits

[Sebastian Reichel]

Hi,

On Fri, Feb 12, 2021 at 05:32:29PM +0100, Krzysztof Kozlowski wrote:
> Milo Kim's email in TI bounces with permanent error (550: Invalid
> recipient).  Last email from him on LKML was in 2017.  Move Milo Kim to
> credits and remove the separate driver entries for:
>  - TI LP855x backlight driver,
>  - TI LP8727 charger driver,
>  - TI LP8788 MFD (ADC, LEDs, charger and regulator) drivers.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Cc: Mark Brown 
> Cc: Jonathan Cameron 
> Cc: Jingoo Han 
> Cc: Lee Jones 
> Cc: Pavel Machek 
> Cc: Thierry Reding 
> Cc: Sebastian Reichel 
> Cc: Daniel Thompson 
> 
> ---
>
> Dear Lee,
> 
> Could you take care about this patch?
> 
> Best regards,
> Krzysztof
> 
> Changes since v3:
> 1. Remove the entries as Dan Murphy won't be mainaining them.
> 
> Changes since v2:
> 1. Fix subject (TP -> TI).
> 
> Changes since v1:
> 1. Add Dan Murphy, do not remove the entries.
> ---

Acked-by: Sebastian Reichel 

-- Sebastian

>  CREDITS |  3 +++
>  MAINTAINERS | 23 ---
>  2 files changed, 3 insertions(+), 23 deletions(-)
> 
> diff --git a/CREDITS b/CREDITS
> index be097156bd71..71552790774d 100644
> --- a/CREDITS
> +++ b/CREDITS
> @@ -1933,6 +1933,9 @@ N: Kukjin Kim
>  E: kg...@kernel.org
>  D: Samsung S3C, S5P and Exynos ARM architectures
>  
> +N: Milo Kim
> +D: TI LP855x, LP8727 and LP8788 drivers
> +
>  N: Sangbeom Kim
>  E: sbki...@samsung.com
>  D: Samsung SoC Audio (ASoC) drivers
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 00bca3e220cc..3478082debd1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17880,29 +17880,6 @@ S:   Maintained
>  F:   sound/soc/codecs/isabelle*
>  F:   sound/soc/codecs/lm49453*
>  
> -TI LP855x BACKLIGHT DRIVER
> -M:   Milo Kim 
> -S:   Maintained
> -F:   Documentation/driver-api/backlight/lp855x-driver.rst
> -F:   drivers/video/backlight/lp855x_bl.c
> -F:   include/linux/platform_data/lp855x.h
> -
> -TI LP8727 CHARGER DRIVER
> -M:   Milo Kim 
> -S:   Maintained
> -F:   drivers/power/supply/lp8727_charger.c
> -F:   include/linux/platform_data/lp8727.h
> -
> -TI LP8788 MFD DRIVER
> -M:   Milo Kim 
> -S:   Maintained
> -F:   drivers/iio/adc/lp8788_adc.c
> -F:   drivers/leds/leds-lp8788.c
> -F:   drivers/mfd/lp8788*.c
> -F:   drivers/power/supply/lp8788-charger.c
> -F:   drivers/regulator/lp8788-*.c
> -F:   include/linux/mfd/lp8788*.h
> -
>  TI NETCP ETHERNET DRIVER
>  M:   Wingman Kwok 
>  M:   Murali Karicheri 
> -- 
> 2.25.1
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] Support second Image Signal Processor on rk3399

[Sebastian Fricke]

Hey Heiko,

On 11.02.2021 15:42, Heiko Stübner wrote:

Hi Sebastian,

Am Donnerstag, 11. Februar 2021, 06:25:15 CET schrieb Sebastian Fricke:

Hey Heiko,

On 10.02.2021 12:15, Heiko Stübner wrote:
>Hi Sebastian,
>
>Am Freitag, 5. Februar 2021, 15:55:56 CET schrieb Heiko Stübner:
>> Hi Sebastian,
>>
>> I did some tests myself today as well and can confirm your
>> hdmi related finding - at least when plugged in on boot.
>>
>> I tried some combinations of camera vs. hdmi and it seems
>> really only when hdmi is plugged in on boot
>
>as you can see in v2, it should work now even with hdmi
>connected on boot. My patch ignored the grf-clock when
>doing the grf-based init.
>
>All clocks are on during boot and I guess the hdmi-driver
>did disable it after its probe. The phy_power_on functions
>did handle it correctly already, so it was only happening
>with hdmi connected on boot.

Thank you very much for solving that problem, I've tested the scenarios
described below and it works like a charm. (With your V2)
>
>
>Btw. do you plan on submitting your ov13850 driver
>soonish?

Actually, I have posted the patch already see here:
https://patchwork.kernel.org/project/linux-media/patch/20210130182313.32903-2-sebastian.fri...@posteo.net/


very cool to see


I currently review the requested changes and questions and will soon
post a second version, but I expect quite some time until it is actually
merged.


could you Cc me on future versions?


Sure will do :)




Thanks
Heiko


Sebastian


Greetings,
Sebastian

>
>
>>
>> (1)
>> - boot
>> - camera
>> --> works
>>
>> (2)
>> - boot
>> - camera
>> - hdmi plugged in
>> - hdmi works
>> - camera
>> --> works
>>
>> (3)
>> - hdmi plugged in
>> - boot
>> - hdmi works
>> - camera
>> --> camera doesn't work
>>
>> (4)
>> - boot
>> - hdmi plugged in
>> - hdmi works
>> - camera
>> -> camera works
>>
>>
>> With a bit of brute-force [0] it seems the camera also works again even
>> with hdmi connected on boot. So conclusion would be that some clock
>> is misbehaving.
>>
>> Now we'll "only" need to find out which one that is.
>>
>>
>> Heiko
>>
>>
>> [0]
>> Don't disable any clock gates
>>
>> diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
>> index 070dc47e95a1..8daf1fc3388c 100644
>> --- a/drivers/clk/clk-gate.c
>> +++ b/drivers/clk/clk-gate.c
>> @@ -61,6 +61,9 @@ static void clk_gate_endisable(struct clk_hw *hw, int 
enable)
>>
>> set ^= enable;
>>
>> +if (!enable)
>> +return;
>> +
>> if (gate->lock)
>> spin_lock_irqsave(gate->lock, flags);
>> else
>>
>>
>>
>> Am Freitag, 5. Februar 2021, 09:15:47 CET schrieb Heiko Stübner:
>> > Hi Sebastian,
>> >
>> > Am Freitag, 5. Februar 2021, 07:43:35 CET schrieb Sebastian Fricke:
>> > > On 03.02.2021 20:54, Heiko Stübner wrote:
>> > > >Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke:
>> > > >> I have tested your patch set on my nanoPC-T4, here is a complete log
>> > > >> with:
>> > > >> - relevant kernel log entries
>> > > >> - system information
>> > > >> - media ctl output
>> > > >> - sysfs entry information
>> > > >>
>> > > >> https://paste.debian.net/1183874/
>> > > >>
>> > > >> Additionally, to your patchset I have applied the following patches:
>> > > >> 
https://github.com/initBasti/Linux_kernel_media_tree_fork/commits/dual_cam_setup
>> > > >>
>> > > >> And just to not cause confusion the `media_dev` entries come from this
>> > > >> unmerged series:
>> > > >> https://patchwork.kernel.org/project/linux-media/list/?series=426269
>> > > >>
>> > > >> I have actually been able to stream with both of my cameras at the 
same
>> > > >> time using the libcamera cam command.
>> > > >> I would like to thank you a lot for making this possible.
>> > > >
>> > > >Thanks for testing a dual camera setup. On my board I could only test
>> > > >the second ISP. And really glad it works for you tool :-) .
>> > > >
>> > > >Out of curiosity, do you also see that green tint in the images the 
cameras
>> > > >produce?
>&

Re: [PATCH v2 0/6] Support second Image Signal Processor on rk3399

[Sebastian Fricke]

Hey Heiko,

I have tested your series and it successfully fixes the problem with the
2nd camera when HDMI is connected at boot. Besides that the patch looks
good and my tests have confirmed that both cameras have the same output
quality when I exchange the connected ISP instances.

Tested-by: Sebastian Fricke 

Greetings,
Sebastian

On 10.02.2021 12:10, Heiko Stuebner wrote:

The rk3399 has two ISPs and right now only the first one is usable.
The second ISP is connected to the TXRX dphy on the soc.

The phy of ISP1 is only accessible through the DSI controller's
io-memory, so this series adds support for simply using the dsi
controller is a phy if needed.

That solution is needed at least on rk3399 and rk3288 but no-one
has looked at camera support on rk3288 at all, so right now
only implement the rk3399 specifics.

changes in v2:
- enable grf-clock also for init callback
 to not break if for example hdmi is connected on boot
 and disabled the grf clock during its probe
- add Sebastian's Tested-by
- add Rob's Ack for the phy-cells property

Heiko Stuebner (6):
 drm/rockchip: dsi: add own additional pclk handling
 dt-bindings: display: rockchip-dsi: add optional #phy-cells property
 drm/rockchip: dsi: add ability to work as a phy instead of full dsi
 arm64: dts: rockchip: add #phy-cells to mipi-dsi1
 arm64: dts: rockchip: add cif clk-control pinctrl for rk3399
 arm64: dts: rockchip: add isp1 node on rk3399

.../display/rockchip/dw_mipi_dsi_rockchip.txt |   1 +
arch/arm64/boot/dts/rockchip/rk3399.dtsi  |  39 ++
drivers/gpu/drm/rockchip/Kconfig  |   2 +
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   | 349 ++
4 files changed, 391 insertions(+)

--
2.29.2


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv1 3/6] dt-bindings: vendor-prefixes: add congatec

[Sebastian Reichel]

Document binding for congatec.

Signed-off-by: Sebastian Reichel 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 041ae90b0d8f..a32db51df6c8 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -239,6 +239,8 @@ patternProperties:
 description: Colorful GRP, Shenzhen Xueyushi Technology Ltd.
   "^compulab,.*":
 description: CompuLab Ltd.
+  "^congatec,.*":
+description: congatec GmbH
   "^coreriver,.*":
 description: CORERIVER Semiconductor Co.,Ltd.
   "^corpro,.*":
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv1 1/6] rtc: m41t80: add support for protected clock

[Sebastian Reichel]

Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The
modules SQW clock output defaults to 32768 Hz. This behaviour is
used to provide the i.MX6 CKIL clock. Once the RTC driver is probed,
the clock is disabled and all i.MX6 functionality depending on
the 32 KHz clock has undefined behaviour. On systems using hardware
watchdog it seems to likely trigger a lot earlier than configured.

The proper solution would be to describe this dependency in DT,
but that will result in a deadlock. The kernel will see, that
i.MX6 system clock needs the RTC clock and do probe deferral.
But the i.MX6 I2C module never becomes usable without the i.MX6
CKIL clock and thus the RTC's clock will not be probed. So from
the kernel's perspective this is a chicken-and-egg problem.

Technically everything is fine by not touching anything, since
the RTC clock correctly enables the clock on reset (i.e. on
battery backup power loss) and also the bootloader enables it
in case a kernel without this support has been booted.

The 'protected-clocks' property is already in use for some clocks
that may not be touched because of firmware limitations and is
described in Documentation/devicetree/bindings/clock/clock-bindings.txt.

Signed-off-by: Sebastian Reichel 
---
 Documentation/devicetree/bindings/rtc/rtc-m41t80.txt | 1 +
 drivers/rtc/rtc-m41t80.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt 
b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
index c746cb221210..ea4bbf5c4282 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
@@ -19,6 +19,7 @@ Optional properties:
 - interrupts: rtc alarm interrupt.
 - clock-output-names: From common clock binding to override the default output
   clock name
+- protected-clocks: Bool, if set operating system should not handle clock.
 - wakeup-source: Enables wake up of host system on alarm
 
 Example:
diff --git a/drivers/rtc/rtc-m41t80.c b/drivers/rtc/rtc-m41t80.c
index 160dcf68e64e..3296583853a8 100644
--- a/drivers/rtc/rtc-m41t80.c
+++ b/drivers/rtc/rtc-m41t80.c
@@ -546,6 +546,9 @@ static struct clk *m41t80_sqw_register_clk(struct 
m41t80_data *m41t80)
struct clk_init_data init;
int ret;
 
+   if (of_property_read_bool(node, "protected-clocks"))
+   return 0;
+
/* First disable the clock */
ret = i2c_smbus_read_byte_data(client, M41T80_REG_ALARM_MON);
if (ret < 0)
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv1 6/6] ARM: dts: imx6: Add GE B1x5v2

[Sebastian Reichel]

This adds device tree files for the General Electric Healthcare
(GEHC) B1x5v2 series. All models make use of Congatec's QMX6 module,
which is described in its own device tree include, so that it can
also be used by other boards.

Signed-off-by: Sebastian Reichel 
---
 arch/arm/boot/dts/Makefile|   5 +
 arch/arm/boot/dts/imx6dl-b105pv2.dts  |  35 ++
 arch/arm/boot/dts/imx6dl-b105v2.dts   |  35 ++
 arch/arm/boot/dts/imx6dl-b125pv2.dts  |  33 ++
 arch/arm/boot/dts/imx6dl-b125v2.dts   |  33 ++
 arch/arm/boot/dts/imx6dl-b155v2.dts   |  36 ++
 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi | 434 ++
 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi  |  61 +++
 arch/arm/boot/dts/imx6dl-qmx6.dtsi| 623 ++
 9 files changed, 1295 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-b105pv2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b105v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b125pv2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b125v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b155v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi
 create mode 100644 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi
 create mode 100644 arch/arm/boot/dts/imx6dl-qmx6.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3d1ea0b25168..cd6bf51d27ec 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -513,6 +513,11 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-dms-ba16.dtb \
imx6q-emcon-avari.dtb \
imx6q-evi.dtb \
+   imx6dl-b105v2.dtb \
+   imx6dl-b105pv2.dtb \
+   imx6dl-b125v2.dtb \
+   imx6dl-b125pv2.dtb \
+   imx6dl-b155v2.dtb \
imx6q-gk802.dtb \
imx6q-gw51xx.dtb \
imx6q-gw52xx.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-b105pv2.dts 
b/arch/arm/boot/dts/imx6dl-b105pv2.dts
new file mode 100644
index ..0d5be2f9471f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b105pv2.dts
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B105Pv2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5pv2.dtsi"
+
+/ {
+   model = "General Electric B105Pv2";
+   compatible = "ge,imx6dl-b105pv2", "congatec,qmx6", "fsl,imx6dl";
+
+   panel {
+   compatible = "auo,g101evn010";
+   status = "okay";
+   };
+};
+
+&i2c3 {
+   touchscreen@41 {
+   reg = <0x41>;
+   compatible = "ilitek,ili251x";
+
+   pinctrl-names = "default";
+   pinctrl-0 =<&pinctrl_q7_gpio0>;
+   interrupt-parent = <&gpio5>;
+   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+   reset-gpios = <&tca6424a 21 GPIO_ACTIVE_LOW>;
+
+   touchscreen-size-x = <1280>;
+   touchscreen-size-y = <800>;
+   };
+};
diff --git a/arch/arm/boot/dts/imx6dl-b105v2.dts 
b/arch/arm/boot/dts/imx6dl-b105v2.dts
new file mode 100644
index ..72a085348304
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b105v2.dts
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B105v2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5v2.dtsi"
+
+/ {
+   model = "General Electric B105v2";
+   compatible = "ge,imx6dl-b105v2", "congatec,qmx6", "fsl,imx6dl";
+
+   panel {
+   compatible = "auo,g101evn010";
+   status = "okay";
+   };
+};
+
+&i2c3 {
+   touchscreen@41 {
+   reg = <0x41>;
+   compatible = "ilitek,ili251x";
+
+   pinctrl-names = "default";
+   pinctrl-0 =<&pinctrl_q7_gpio0>;
+   interrupt-parent = <&gpio5>;
+   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+   reset-gpios = <&tca6424a 21 GPIO_ACTIVE_LOW>;
+
+   touchscreen-size-x = <1280>;
+   touchscreen-size-y = <800>;
+   };
+};
diff --git a/arch/arm/boot/dts/imx6dl-b125pv2.dts 
b/arch/arm/boot/dts/imx6dl-b125pv2.dts
new file mode 100644
index ..8fd6c8ed6750
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b125pv2.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B125Pv2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5pv2.dtsi"
+
+/ {
+   model = "General Electric B125Pv2";
+   compatible = "ge,imx6dl-b125pv2", "congatec,qmx6", "fsl,imx6d

[PATCHv1 0/6] Support for GE B1x5v2

[Sebastian Reichel]

Hi,

This series adds support for another General Electric patient
monitor series (similar to existing Bx50v3), which is based on
i.MX6DL using Congatec's QMX6 module.

The module uses an I2C RTC to provide the i.MX6 32768 Hz clock,
so it's important to keep it enabled. Not doing so results in
incorrect timings of watchdog and i.MX6 RTC. The bootloader
enables the watchdog, so disabling the clock results in system
reboot. [0]

The second patch is required for B155v2, which uses a 1366x768
G156XTN01 panel. The 1366 width is not supported by the display
pipeline and result in boot hanging without the patch. [1]

Patches 3+4 are updating DT bindings for the new board compatible
values.

Patch 5 adds missing sst25vf032b to spi-nor bindings. Checkpatch
still complains, since the binding lists all chips without vendor
prefix. This probably should be fixed when the files is moved to
YAML, but is non-trivial since those chips are manufactured by
multiple vendors. E.g. sst25vf032b can be sourced from at least
sst and microchip.

Finally patch 6 adds the board files.

Thanks,

[0] There has been a discussion for the problem on the mailinglists
last year. The discussion died off, when I told people their ideas
don't work. I hope using protected-clocks is fine for this usecase.

https://lore.kernel.org/linux-clk/20191108170135.9053-1-sebastian.reic...@collabora.com/

[1] I've sent this before as a separate patch in September, but
nobody seemed to care. This adds full context for the problem.

https://lore.kernel.org/dri-devel/20200910162831.321556-1-sebastian.reic...@collabora.com/

-- Sebastian

Sebastian Reichel (6):
  rtc: m41t80: add support for protected clock
  drm/imx: Add 8 pixel alignment fix
  dt-bindings: vendor-prefixes: add congatec
  dt-bindings: arm: fsl: add GE B1x5pv2 boards
  dt-bindings: mtd: jedec,spi-nor: add sst25vf032b
  ARM: dts: imx6: Add GE B1x5v2

 .../devicetree/bindings/arm/fsl.yaml  |  11 +
 .../devicetree/bindings/mtd/jedec,spi-nor.txt |   1 +
 .../devicetree/bindings/rtc/rtc-m41t80.txt|   1 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm/boot/dts/Makefile|   5 +
 arch/arm/boot/dts/imx6dl-b105pv2.dts  |  35 +
 arch/arm/boot/dts/imx6dl-b105v2.dts   |  35 +
 arch/arm/boot/dts/imx6dl-b125pv2.dts  |  33 +
 arch/arm/boot/dts/imx6dl-b125v2.dts   |  33 +
 arch/arm/boot/dts/imx6dl-b155v2.dts   |  36 +
 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi | 434 
 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi  |  61 ++
 arch/arm/boot/dts/imx6dl-qmx6.dtsi| 623 ++
 drivers/gpu/drm/imx/imx-drm-core.c|  19 +-
 drivers/gpu/drm/imx/imx-ldb.c |   5 +
 drivers/gpu/drm/imx/ipuv3-crtc.c  |  11 +-
 drivers/gpu/drm/imx/ipuv3-plane.c |  19 +-
 drivers/gpu/ipu-v3/ipu-dc.c   |   5 +
 drivers/gpu/ipu-v3/ipu-di.c   |   7 +
 drivers/rtc/rtc-m41t80.c  |   3 +
 20 files changed, 1373 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6dl-b105pv2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b105v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b125pv2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b125v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b155v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi
 create mode 100644 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi
 create mode 100644 arch/arm/boot/dts/imx6dl-qmx6.dtsi

-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv1 5/6] dt-bindings: mtd: jedec,spi-nor: add sst25vf032b

[Sebastian Reichel]

The binding is already used by the driver. Update documentation
accordingly.

Signed-off-by: Sebastian Reichel 
---
 Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt 
b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
index f03be904d3c2..40e626e82ed0 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
@@ -31,6 +31,7 @@ Required properties:
  s25sl12801
  s25fl008k
  s25fl064k
+ sst25vf032b
  sst25vf040b
  m25p40
  m25p80
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv1 4/6] dt-bindings: arm: fsl: add GE B1x5pv2 boards

[Sebastian Reichel]

Document the compatible for GE B1x5pv2 boards.

Signed-off-by: Sebastian Reichel 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 34000f7fbe02..dd2b566314a0 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -393,6 +393,17 @@ properties:
   - const: armadeus,imx6dl-apf6 # APF6 (Solo) SoM
   - const: fsl,imx6dl
 
+  - description: i.MX6DL based congatec QMX6 Boards
+items:
+  - enum:
+  - ge,imx6dl-b105v2  # General Electric B105v2
+  - ge,imx6dl-b105pv2 # General Electric B105Pv2
+  - ge,imx6dl-b125v2  # General Electric B125v2
+  - ge,imx6dl-b125pv2 # General Electric B125Pv2
+  - ge,imx6dl-b155v2  # General Electric B155v2
+  - const: congatec,qmx6
+  - const: fsl,imx6dl
+
   - description: i.MX6DL based DFI FS700-M60-6DL Board
 items:
   - const: dfi,fs700-m60-6dl
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv1 2/6] drm/imx: Add 8 pixel alignment fix

[Sebastian Reichel]

Some standard resolutions like 1366x768 do not work properly with
i.MX6 SoCs, since the horizontal resolution needs to be aligned
to 8 pixels (so 1360x768 or 1368x768 would work).

This patch allocates framebuffers allocated to 8 pixels. The extra
time required to send the extra pixels are removed from the blank
time. In order to expose the correct display size to userspace,
the stride is increased without increasing the width.

Suggested-by: Boris Brezillon 
Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 19 ++-
 drivers/gpu/drm/imx/imx-ldb.c  |  5 +
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 11 ++-
 drivers/gpu/drm/imx/ipuv3-plane.c  | 19 +++
 drivers/gpu/ipu-v3/ipu-dc.c|  5 +
 drivers/gpu/ipu-v3/ipu-di.c|  7 +++
 6 files changed, 60 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index d1a9841adeed..1bcf740b7f4f 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -145,9 +145,26 @@ static const struct drm_ioctl_desc imx_drm_ioctls[] = {
/* none so far */
 };
 
+static int imx_drm_dumb_create(struct drm_file *file_priv,
+  struct drm_device *drm,
+  struct drm_mode_create_dumb *args)
+{
+   u32 width = args->width;
+   int ret;
+
+   args->width = ALIGN(width, 8);
+
+   ret = drm_gem_cma_dumb_create(file_priv, drm, args);
+   if (ret)
+   return ret;
+
+   args->width = width;
+   return ret;
+}
+
 static const struct drm_driver imx_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
-   DRM_GEM_CMA_DRIVER_OPS,
+   DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(imx_drm_dumb_create),
.ioctls = imx_drm_ioctls,
.num_ioctls = ARRAY_SIZE(imx_drm_ioctls),
.fops   = &imx_drm_driver_fops,
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 41e2978cb1eb..9c7710c719d7 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -257,6 +257,11 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder 
*encoder,
 "%s: mode exceeds 85 MHz pixel clock\n", __func__);
}
 
+   if (!IS_ALIGNED(mode->hdisplay, 8)) {
+   dev_warn(ldb->dev,
+"%s: hdisplay does not align to 8 byte\n", __func__);
+   }
+
if (dual) {
serial_clk = 3500UL * mode->clock;
imx_ldb_set_clock(ldb, mux, 0, serial_clk, di_clk);
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 7ebd99ee3240..1ab970bcd52b 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -305,10 +305,19 @@ static void ipu_crtc_mode_set_nofb(struct drm_crtc *crtc)
sig_cfg.vsync_pin = imx_crtc_state->di_vsync_pin;
 
drm_display_mode_to_videomode(mode, &sig_cfg.mode);
+   if (!IS_ALIGNED(sig_cfg.mode.hactive, 8)) {
+   unsigned int new_hactive = ALIGN(sig_cfg.mode.hactive, 8);
+
+   dev_warn(ipu_crtc->dev, "8-pixel align hactive %d -> %d\n",
+sig_cfg.mode.hactive, new_hactive);
+
+   sig_cfg.mode.hfront_porch = new_hactive - sig_cfg.mode.hactive;
+   sig_cfg.mode.hactive = new_hactive;
+   }
 
ipu_dc_init_sync(ipu_crtc->dc, ipu_crtc->di,
 mode->flags & DRM_MODE_FLAG_INTERLACE,
-imx_crtc_state->bus_format, mode->hdisplay);
+imx_crtc_state->bus_format, sig_cfg.mode.hactive);
ipu_di_init_sync_panel(ipu_crtc->di, &sig_cfg);
 }
 
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 8a4235d9d9f1..5dd43e8c4d9e 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -29,6 +29,11 @@ to_ipu_plane_state(struct drm_plane_state *p)
return container_of(p, struct ipu_plane_state, base);
 }
 
+static unsigned int ipu_src_rect_width(const struct drm_plane_state *state)
+{
+   return ALIGN(drm_rect_width(&state->src) >> 16, 8);
+}
+
 static inline struct ipu_plane *to_ipu_plane(struct drm_plane *p)
 {
return container_of(p, struct ipu_plane, base);
@@ -418,6 +423,12 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if (old_fb && fb->pitches[0] != old_fb->pitches[0])
crtc_state->mode_changed = true;
 
+   if (ALIGN(fb->width, 8) * fb->format->cpp[0] >
+   fb->pitches[0] + fb->offsets[0]) {
+   dev_warn(dev, "pitch is not big enough for 8 pixels alignment");
+   return -E

Re: [PATCHv1 1/6] rtc: m41t80: add support for protected clock

[Sebastian Reichel]

Hi,

On Mon, Feb 22, 2021 at 10:26:26PM +0100, Alexandre Belloni wrote:
> On 22/02/2021 22:20:47+0100, Alexandre Belloni wrote:
> > On 22/02/2021 18:12:42+0100, Sebastian Reichel wrote:
> > > Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The
> > > modules SQW clock output defaults to 32768 Hz. This behaviour is
> > > used to provide the i.MX6 CKIL clock. Once the RTC driver is probed,
> > > the clock is disabled and all i.MX6 functionality depending on
> > > the 32 KHz clock has undefined behaviour. On systems using hardware
> > > watchdog it seems to likely trigger a lot earlier than configured.
> > > 
> > > The proper solution would be to describe this dependency in DT,
> > > but that will result in a deadlock. The kernel will see, that
> > > i.MX6 system clock needs the RTC clock and do probe deferral.
> > > But the i.MX6 I2C module never becomes usable without the i.MX6
> > > CKIL clock and thus the RTC's clock will not be probed. So from
> > > the kernel's perspective this is a chicken-and-egg problem.
> > > 
> > 
> > Reading the previous paragraph, I was going to suggest describing the
> > dependency and wondering whether this would cause a circular dependency.
> > I guess this will keep being an issue for clocks on an I2C or SPI bus...

Yes, it is a circular dependency on this particular system on
module. It only works because the RTC enables the clock by
default. The i.MX6 CKIL is expected to be always enabled.

> > > Technically everything is fine by not touching anything, since
> > > the RTC clock correctly enables the clock on reset (i.e. on
> > > battery backup power loss) and also the bootloader enables it
> > > in case a kernel without this support has been booted.
> > > 
> > > The 'protected-clocks' property is already in use for some clocks
> > > that may not be touched because of firmware limitations and is
> > > described in Documentation/devicetree/bindings/clock/clock-bindings.txt.
> > > 
> > > Signed-off-by: Sebastian Reichel 
> > Acked-by: Alexandre Belloni 
> 
> Or maybe you expected me to apply the patch, how are the following
> patches dependent on this one?

The last patch, which introduces a new board has a runtime
dependency on this patch. Without this feature the board
goes into a reboot loop because its bootloader enables the
i.MX6 watchdog and without the CKIL its timing is messed up.

But it's a pure runtime dependency for a new board, so it should
be fine to merge this via your tree. It basically means the board
is only working once your tree and arm tree have been merged,
which seems ok from my POV.

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv1 5/6] dt-bindings: mtd: jedec,spi-nor: add sst25vf032b

[Sebastian Reichel]

Hi,

On Mon, Feb 22, 2021 at 06:15:11PM -0600, Rob Herring wrote:
> On Mon, Feb 22, 2021 at 11:13 AM Sebastian Reichel
>  wrote:
> >
> > The binding is already used by the driver. Update documentation
> > accordingly.
> >
> > Signed-off-by: Sebastian Reichel 
> > ---
> >  Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 1 +
> >  1 file changed, 1 insertion(+)
> 
> This is now DT schema format. Landed in Linus' tree today.

Indeed and it already contains sst,sst25vf032b.
This patch can be ignored.

Thanks,

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/panel: panel-dsi-cm: disable TE for now

[Sebastian Reichel]

From: Sebastian Reichel 

Disable TE for Droid 4 panel, since implementation is currently
broken. Also disable it for N950 panel, which is untested.

Reported-by: Tony Lindgren 
Reported-by: Tomi Valkeinen 
Fixes: 4c1b935fea54 ("drm/omap: dsi: move TE GPIO handling into core")
Signed-off-by: Sebastian Reichel 
---
I suggest to start by fix the regression like this and look into
proper Droid 4 TE support separatly. Assumption is, that Tomi
tested taal panel, droid4 panel is 'broken' and N950 (himalaya)
is untested [*], so choosing safe default. Patch is compile-tested
only.

[*] N950 display is not yet functional on mainline, since it needs
the omap3 FIFO workaround:
https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git/commit/?h=n950-display-tony&id=d4cbc226a30b29bf258397b052c9ec68c8a3
---
 drivers/gpu/drm/panel/panel-dsi-cm.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c 
b/drivers/gpu/drm/panel/panel-dsi-cm.c
index af381d756ac1..5fbfb71ca3d9 100644
--- a/drivers/gpu/drm/panel/panel-dsi-cm.c
+++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
@@ -37,6 +37,7 @@ struct dsic_panel_data {
u32 height_mm;
u32 max_hs_rate;
u32 max_lp_rate;
+   bool te_support;
 };
 
 struct panel_drv_data {
@@ -334,9 +335,11 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
if (r)
goto err;
 
-   r = mipi_dsi_dcs_set_tear_on(ddata->dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
-   if (r)
-   goto err;
+   if (ddata->panel_data->te_support) {
+   r = mipi_dsi_dcs_set_tear_on(ddata->dsi, 
MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+   if (r)
+   goto err;
+   }
 
/* possible panel bug */
msleep(100);
@@ -619,6 +622,7 @@ static const struct dsic_panel_data taal_data = {
.height_mm = 0,
.max_hs_rate = 3,
.max_lp_rate = 1000,
+   .te_support = true,
 };
 
 static const struct dsic_panel_data himalaya_data = {
@@ -629,6 +633,7 @@ static const struct dsic_panel_data himalaya_data = {
.height_mm = 88,
.max_hs_rate = 3,
.max_lp_rate = 1000,
+   .te_support = false,
 };
 
 static const struct dsic_panel_data droid4_data = {
@@ -639,6 +644,7 @@ static const struct dsic_panel_data droid4_data = {
.height_mm = 89,
.max_hs_rate = 3,
.max_lp_rate = 1000,
+   .te_support = false,
 };
 
 static const struct of_device_id dsicm_of_match[] = {
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv1 1/6] rtc: m41t80: add support for protected clock

[Sebastian Reichel]

Hi,

On Sat, Mar 06, 2021 at 11:56:45AM -0800, Rob Herring wrote:
> On Tue, Feb 23, 2021 at 02:26:57AM +0100, Sebastian Reichel wrote:
> > On Mon, Feb 22, 2021 at 10:26:26PM +0100, Alexandre Belloni wrote:
> > > On 22/02/2021 22:20:47+0100, Alexandre Belloni wrote:
> > > > On 22/02/2021 18:12:42+0100, Sebastian Reichel wrote:
> > > > > Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The
> > > > > modules SQW clock output defaults to 32768 Hz. This behaviour is
> > > > > used to provide the i.MX6 CKIL clock. Once the RTC driver is probed,
> > > > > the clock is disabled and all i.MX6 functionality depending on
> > > > > the 32 KHz clock has undefined behaviour. On systems using hardware
> > > > > watchdog it seems to likely trigger a lot earlier than configured.
> > > > > 
> > > > > The proper solution would be to describe this dependency in DT,
> > > > > but that will result in a deadlock. The kernel will see, that
> > > > > i.MX6 system clock needs the RTC clock and do probe deferral.
> > > > > But the i.MX6 I2C module never becomes usable without the i.MX6
> > > > > CKIL clock and thus the RTC's clock will not be probed. So from
> > > > > the kernel's perspective this is a chicken-and-egg problem.
> > > > > 
> > > > 
> > > > Reading the previous paragraph, I was going to suggest describing the
> > > > dependency and wondering whether this would cause a circular dependency.
> > > > I guess this will keep being an issue for clocks on an I2C or SPI bus...
> > 
> > Yes, it is a circular dependency on this particular system on
> > module. It only works because the RTC enables the clock by
> > default. The i.MX6 CKIL is expected to be always enabled.
> 
> I think you should describe the circular clocking and then provide a way 
> to break the dependency.

This is very much not trivial. The clock is required during early
initialization of the i.MX. At this point we are far from probing
I2C drivers and without the I2C driver the clock is not registered.
The current i.MX code expects the system clocks to be fixed clocks,
since they must be enabled before any code is executed (incl.
bootloader) and must never be disabled. From a HW design point of
view it does not make sense to have a SW controllable clock for it,
since it just adds extra cost. I believe for QMX6 it is only SW
controllable, because that avoids the need for an extra crystal.

So how is the clock framework supposed to know, that it can ignore
the clock during registration? I see the following options:

1. My solution is the simplest one. Keep i.MX clock code the same
   (it assumes a fixed-clock being used for CKIL) and avoid
   registering RTC clock. This basically means the RTC is considered
   to be a fixed-clock on this system, which is what the HW designers
   seemed to have in mind (vendor kernel for the QMX6 is old enough
   (4.9.x) to not to have CLK feature in the RTC driver. Vendor
   U-Boot also does not touch the RTC. Booting mainline kernel once
   bricks QMX6 boards until RTC battery is removed, so one could
   actually argue addition of the CLK feature in 1373e77b4f10 (4.13)
   is a regression). Currently Qualcomm device uses "protected-clocks"
   for FW controlled clocks where Linux would crash the system by
   trying to access them. IMHO the RTC is similar, since disabling
   or modifying its frequency on QMX6 results in undefined behaviour
   and possibly system crash.

2. Make i.MX clock code use the RTC as CKIL clock provider, but
   ignore it somehow. I see three sub-options:

2.1. Add a property 'boot-enabled' to the RTC node, so that the
 clock framework is aware of clock being enabled. This can
 be used to satisfy clock dependencies somehow.

2.2. The RTC device is not probed without I2C bus, but the driver
 could also register a fake clock purely based on DT
 information by adding some early init hook and take over
 the clock once the I2C part is being probed. I think this
 is a bad idea regarding maintainability of the driver.
 Also for systems not using the RTC clock, the early clock
 registration is basically wrong: If the kernel disables
 the RTC it will stay disabled across boots if the RTC has
 a backup battery. Basically we cannot imply anything from
 the RTC compatible value alone.

2.3 The i.MX core code could request CKIL with some flag, that
it's fine to have an unresolvable clock and just expect it
to be boot-enabled. The rationale would be, that CKIL must
be always-enabled.

> It's a somewhat common issue.

It is? This only works, because one can treat the RTC's clock
output like a fixed clock by not messing around with it.

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

[Sebastian Wick]

On 2021-05-17 10:57, Pekka Paalanen wrote:

On Fri, 14 May 2021 17:05:11 -0400
Harry Wentland  wrote:


On 2021-04-27 10:50 a.m., Pekka Paalanen wrote:
> On Mon, 26 Apr 2021 13:38:49 -0400
> Harry Wentland  wrote:


...


>> ## Mastering Luminances
>>
>> Now we are able to use the PQ 2084 EOTF to define the luminance of
>> pixels in absolute terms. Unfortunately we're again presented with
>> physical limitations of the display technologies on the market today.
>> Here are a few examples of luminance ranges of displays.
>>
>> | Display  | Luminance range in nits |
>> |  | --- |
>> | Typical PC display   | 0.3 - 200   |
>> | Excellent LCD HDTV   | 0.3 - 400   |
>> | HDR LCD w/ local dimming | 0.05 - 1,500|
>>
>> Since no display can currently show the full 0.0005 to 10,000 nits
>> luminance range the display will need to tonemap the HDR content, i.e
>> to fit the content within a display's capabilities. To assist with
>> tonemapping HDR content is usually accompanied with a metadata that
>> describes (among other things) the minimum and maximum mastering
>> luminance, i.e. the maximum and minimum luminance of the display that
>> was used to master the HDR content.
>>
>> The HDR metadata is currently defined on the drm_connector via the
>> hdr_output_metadata blob property.
>>
>> It might be useful to define per-plane hdr metadata, as different
>> planes might have been mastered differently.
>
> I don't think this would directly help with the dynamic range blending
> problem. You still need to establish the mapping between the optical
> values from two different EOTFs and dynamic ranges. Or can you know
> which optical values match the mastering display maximum and minimum
> luminances for not-PQ?
>

My understanding of this is probably best illustrated by this example:

Assume HDR was mastered on a display with a maximum white level of 500
nits and played back on a display that supports a max white level of 
400
nits. If you know the mastering white level of 500 you know that this 
is
the maximum value you need to compress down to 400 nits, allowing you 
to

use the full extent of the 400 nits panel.


Right, but in the kernel, where do you get these nits values from?

hdr_output_metadata blob is infoframe data to the monitor. I think this
should be independent of the metadata used for color transformations in
the display pipeline before the monitor.

EDID may tell us the monitor HDR metadata, but again what is used in
the color transformations should be independent, because EDIDs lie,
lighting environments change, and users have different preferences.

What about black levels?

Do you want to do black level adjustment?

How exactly should the compression work?

Where do you map the mid-tones?

What if the end user wants something different?


I suspect that this is not about tone mapping at all. The use cases
listed always have the display in PQ mode and just assume that no
content exceeds the PQ limitations. Then you can simply bring all
content to the color space with a matrix multiplication and then map the
linear light content somewhere into the PQ range. Tone mapping is
performed in the display only.

From a generic wayland compositor point of view this is uninteresting.

I completely agree with what you said below though. I would even argue
that all generic KMS abstract pipeline elements must have a well defined
place in the pipeline and follow an exact specified formula.




If you do not know the mastering luminance is 500 nits you would
have to compress 10,000 nits down to 400 (assuming PQ), losing quite
a bit of the full 400 nits available as you'll need room to map the 
500
to 10,000 nits range which in reality is completely unused. You might 
end

up with mapping 500 nits to 350 nits, instead of mapping it to 400.


The quality of the result depends on the compression (tone-mapping)
algorithm. I believe no-one will ever do a simple linear compression of
ranges.

Instead, you probably do something smooth in the black end, keep
mid-tones roughly as they are, and the again do a smooth saturation to
some "reasonable" level that goes well with the monitor in the current
lighting environment without introducing coloring artifacts, and just
clip the huge overshoot of the full PQ-range.

There are many big and small decisions to be made in how to map
out-of-gamut or out-of-brightness values into the displayable range,
and no algorithm fits all use cases. I believe this is why e.g. ICC
has several different "render intents", some of which are so vaguely
defined that they are practically undefined - just like what "a good
picture" means. You have essentially three dimensions: luminance, hue,
and saturation. Which one will you sacrifice, shift or emphasize and to
what degree to fit the square content peg into the round display hole?

A naive example: Let's say content has 300 nits red. Your display can

Re: [RFC PATCH v2 1/6] drm/doc: Color Management and HDR10 RFC

[Sebastian Wick]

On 2021-05-14 23:07, Harry Wentland wrote:

Use the new DRM RFC doc section to capture the RFC previously only
described in the cover letter at
https://patchwork.freedesktop.org/series/89506/

Update the RFC based on feedback received:
 * don't use color_encoding property to define color space
 * expand on reason for SDR luminance definition
 * define input/output transfer functions for luminance space 
transforms,

   rather than defining the luminance space of an input directly

Signed-off-by: Harry Wentland 
---
 Documentation/gpu/rfc/hdr-wide-gamut.rst | 416 +++
 Documentation/gpu/rfc/index.rst  |   4 +
 2 files changed, 420 insertions(+)
 create mode 100644 Documentation/gpu/rfc/hdr-wide-gamut.rst

diff --git a/Documentation/gpu/rfc/hdr-wide-gamut.rst
b/Documentation/gpu/rfc/hdr-wide-gamut.rst
new file mode 100644
index ..132898668eac
--- /dev/null
+++ b/Documentation/gpu/rfc/hdr-wide-gamut.rst
@@ -0,0 +1,416 @@
+==
+HDR & Wide Color Gamut Support
+==
+
+.. role:: wy-text-strike
+
+ToDo
+
+
+* :wy-text-strike:`Reformat as RST kerneldoc` - done
+* :wy-text-strike:`Don't use color_encoding for color_space 
definitions` - done
+* :wy-text-strike:`Update SDR luminance description and reasoning` - 
done

+* :wy-text-strike:`Clarify 3D LUT required for some color space
transformations` - done
+* :wy-text-strike:`Highlight need for named color space and EOTF
definitions` - done
+* :wy-text-strike:`Define transfer function API` - done
+* :wy-text-strike:`Draft upstream plan` - done
+* Reference to wayland and/or Chrome plans
+* Sketch view of HW pipeline for couple of HW implementations
+
+
+Upstream Plan
+=
+
+* Reach consensus on DRM/KMS API
+* Implement support in amdgpu
+* Implement IGT tests
+* Add API support to Weston, ChromiumOS, or other canonical
open-source project interested in HDR
+* Merge user-space
+* Merge kernel patches
+
+
+Introduction
+
+
+We are looking to enable HDR support for a couple of single-plane and
+multi-plane scenarios. To do this effectively we recommend new 
interfaces

+to drm_plane. Below I'll give a bit of background on HDR and why we
+propose these interfaces.
+
+
+Overview and background
+===
+
+Defining a pixel's luminance
+
+
+The luminance space of pixels in a framebuffer/plane presented to the
+display is not well defined in the DRM/KMS APIs. It is usually assumed 
to
+be in a 2.2 or 2.4 gamma space and has no mapping to an absolute 
luminance

+value; it is interpreted in relative terms.
+
+Luminance can be measured and described in absolute terms as candela
+per meter squared, or cd/m2, or nits. Even though a pixel value can be
+mapped to luminance in a linear fashion to do so without losing a lot 
of

+detail requires 16-bpc color depth. The reason for this is that human
+perception can distinguish roughly between a 0.5-1% luminance delta. A
+linear representation is suboptimal, wasting precision in the 
highlights

+and losing precision in the shadows.
+
+A gamma curve is a decent approximation to a human's perception of
+luminance, but the PQ (perceptual quantizer) function [1] improves on
+it. It also defines the luminance values in absolute terms, with the
+highest value being 10,000 nits and the lowest 0.0005 nits.
+
+Using a content that's defined in PQ space we can approximate the real
+world in a much better way.
+
+Here are some examples of real-life objects and their approximate
+luminance values:
+
+.. flat-table::
+   :header-rows: 1
+
+   * - Object
+ - Luminance in nits
+
+   *  - Fluorescent light
+  - 10,000
+
+   *  - Highlights
+  - 1,000 - sunlight
+
+   *  - White Objects
+  - 250 - 1,000
+
+   *  - Typical Objects
+  - 1 - 250
+
+   *  - Shadows
+  - 0.01 - 1
+
+   *  - Ultra Blacks
+  - 0 - 0.0005
+
+Transfer functions
+--
+
+Traditionally we used the terms gamma and de-gamma to describe the
+encoding of a pixel's luminance value and the operation to transfer 
from

+a linear luminance space to the non-linear space used to encode the
+pixels. Since some newer encodings don't use a gamma curve I suggest
+we refer to non-linear encodings using the terms EOTF, and OETF[2], or
+simply as transfer function in general.
+
+The EOTF (Electro-Optical Transfer Function) describes how to transfer
+from an electrical signal to an optical signal. This was traditionally
+done by the de-gamma function.
+
+The OETF (Opto Electronic Transfer Function) describes how to transfer
+from an optical signal to an electronic signal. This was traditionally
+done by the gamma function.
+
+More generally we can name the transfer function describing the 
transform
+between scanout and blending space as the **input transfer function**, 
and
+the transfer function describing the transform from blending space to 
the

+output space as **output transfer function

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

[Sebastian Wick]

On 2021-05-18 16:19, Harry Wentland wrote:

On 2021-05-18 3:56 a.m., Pekka Paalanen wrote:

On Mon, 17 May 2021 15:39:03 -0400
Vitaly Prosyak  wrote:


On 2021-05-17 12:48 p.m., Sebastian Wick wrote:

On 2021-05-17 10:57, Pekka Paalanen wrote:

On Fri, 14 May 2021 17:05:11 -0400
Harry Wentland  wrote:


On 2021-04-27 10:50 a.m., Pekka Paalanen wrote:

On Mon, 26 Apr 2021 13:38:49 -0400
Harry Wentland  wrote:


...


## Mastering Luminances

Now we are able to use the PQ 2084 EOTF to define the luminance 
of
pixels in absolute terms. Unfortunately we're again presented 
with

physical limitations of the display technologies on the market

today.

Here are a few examples of luminance ranges of displays.

| Display  | Luminance range in nits |
|  | --- |
| Typical PC display   | 0.3 - 200 |
| Excellent LCD HDTV   | 0.3 - 400 |
| HDR LCD w/ local dimming | 0.05 - 1,500 |

Since no display can currently show the full 0.0005 to 10,000 
nits
luminance range the display will need to tonemap the HDR 
content,

i.e
to fit the content within a display's capabilities. To assist 
with
tonemapping HDR content is usually accompanied with a metadata 
that

describes (among other things) the minimum and maximum mastering
luminance, i.e. the maximum and minimum luminance of the display

that

was used to master the HDR content.

The HDR metadata is currently defined on the drm_connector via 
the

hdr_output_metadata blob property.

It might be useful to define per-plane hdr metadata, as 
different

planes might have been mastered differently.


I don't think this would directly help with the dynamic range

blending
problem. You still need to establish the mapping between the 
optical
values from two different EOTFs and dynamic ranges. Or can you 
know
which optical values match the mastering display maximum and 
minimum

luminances for not-PQ?



My understanding of this is probably best illustrated by this 
example:


Assume HDR was mastered on a display with a maximum white level of 
500
nits and played back on a display that supports a max white level 
of

400
nits. If you know the mastering white level of 500 you know that
this is
the maximum value you need to compress down to 400 nits, allowing
you to
use the full extent of the 400 nits panel.


Right, but in the kernel, where do you get these nits values from?

hdr_output_metadata blob is infoframe data to the monitor. I think 
this
should be independent of the metadata used for color 
transformations in

the display pipeline before the monitor.

EDID may tell us the monitor HDR metadata, but again what is used 
in

the color transformations should be independent, because EDIDs lie,
lighting environments change, and users have different preferences.

What about black levels?

Do you want to do black level adjustment?

How exactly should the compression work?

Where do you map the mid-tones?

What if the end user wants something different?


I suspect that this is not about tone mapping at all. The use cases
listed always have the display in PQ mode and just assume that no
content exceeds the PQ limitations. Then you can simply bring all
content to the color space with a matrix multiplication and then map 
the

linear light content somewhere into the PQ range. Tone mapping is
performed in the display only.


The use cases do use the word "desktop" though. Harry, could you 
expand

on this, are you seeking a design that is good for generic desktop
compositors too, or one that is more tailored to "embedded" video
player systems taking the most advantage of (potentially
fixed-function) hardware?



The goal is to enable this on a generic desktop, such as generic 
Wayland
implementations or ChromeOS. We're not looking for a custom solution 
for
some embedded systems, though the solution we end up with should 
obviously

not prevent an implementation on embedded video players.


What matrix would one choose? Which render intent would it
correspond to?

If you need to adapt different dynamic ranges into the blending 
dynamic

range, would a simple linear transformation really be enough?

From a generic wayland compositor point of view this is 
uninteresting.



It a compositor's decision to provide or not the metadata property to
the kernel. The metadata can be available from one or multiple 
clients

or most likely not available at all.

Compositors may put a display in HDR10 ( when PQ 2084 INV EOTF and TM
occurs in display ) or NATIVE mode and do not attach any metadata to 
the

connector and do TM in compositor.

It is all about user preference or compositor design, or a 
combination

of both options.


Indeed. The thing here is that you cannot just add KMS UAPI, you also
need to have the FOSS userspace to go with it. So you need to have 
your

audience defined, userspace patches written and reviewed and agreed
to be a good idea. I'm afraid this particu

Re: [PATCH] drm/panel: sony-acx565akm: Fix race condition in probe

[Sebastian Reichel]

Hi Laurent,

On Sun, Nov 29, 2020 at 12:08:47AM +0200, Laurent Pinchart wrote:
> On Fri, Nov 27, 2020 at 09:04:29PM +0100, Sebastian Reichel wrote:
> > The probe routine acquires the reset GPIO using GPIOD_OUT_LOW. Directly
> > afterwards it calls acx565akm_detect(), which sets the GPIO value to
> > HIGH. If the bootloader initialized the GPIO to HIGH before the probe
> > routine was called, there is only a very short time period of a few
> > instructions where the reset signal is LOW. Exact time depends on
> > compiler optimizations, kernel configuration and alignment of the stars,
> > but I expect it to be always way less than 10us. There are no public
> > datasheets for the panel, but acx565akm_power_on() has a comment with
> > timings and reset period should be at least 10us. So this potentially
> > brings the panel into a half-reset state.
> 
> Good catch.
> 
> Looks like we got the reset polarity wrong in the driver though.
> GPIOD_OUT_LOW should mean de-asserted, but the driver expects it to mean
> low level. We can't fix that as it would require changing the device
> tree :-(

Yes, polarity is wrong unfortunately.

> > The result is, that panel may not work after boot and can get into a
> > working state by re-enabling it (e.g. by blanking + unblanking), since
> > that does a clean reset cycle. This bug has recently been hit by Ivaylo
> > Dimitrov, but there are some older reports which are probably the same
> > bug. At least Tony Lindgren, Peter Ujfalusi and Jarkko Nikula have
> > experienced it in 2017 describing the blank/unblank procedure as
> > possible workaround.
> > 
> > Note, that the bug really goes back in time. It has originally been
> > introduced in the predecessor of the omapfb driver in 3c45d05be382
> > ("OMAPDSS: acx565akm panel: handle gpios in panel driver") in 2012.
> > That driver eventually got replaced by a newer one, which had the bug
> > from the beginning in 84192742d9c2 ("OMAPDSS: Add Sony ACX565AKM panel
> > driver") and still exists in fbdev world. That driver has later been
> > copied to omapdrm and then was used as a basis for this driver. Last
> > but not least the omapdrm specific driver has been removed in
> > 45f16c82db7e ("drm/omap: displays: Remove unused panel drivers").
> > 
> > Reported-by: Jarkko Nikula 
> > Reported-by: Peter Ujfalusi 
> > Reported-by: Tony Lindgren 
> > Reported-by: Aaro Koskinen 
> > Reported-by: Ivaylo Dimitrov 
> > Cc: Merlijn Wajer 
> > Cc: Laurent Pinchart 
> > Cc: Tomi Valkeinen 
> > Fixes: 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
> > Signed-off-by: Sebastian Reichel 
> > ---
> >  drivers/gpu/drm/panel/panel-sony-acx565akm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c 
> > b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> > index e95fdfb16b6c..ba0b3ead150f 100644
> > --- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> > +++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> > @@ -629,7 +629,7 @@ static int acx565akm_probe(struct spi_device *spi)
> > lcd->spi = spi;
> > mutex_init(&lcd->mutex);
> >  
> > -   lcd->reset_gpio = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_LOW);
> > +   lcd->reset_gpio = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_HIGH);
> 
> Wouldn't it be better to instead add a delay here (or in
> acx565akm_detect()) ? If the panel is in a wrong state at
> boot time, a real reset can help.

acx565akm_detect() reads some registers to detect a previously
enabled panel and then driver handles this case properly. If we
reset the panel before the detection code, any detection code
would be useless (panel is obviously not enabled after a reset).

I think this detection code is only needed to avoid flickering
when a bootsplash is shown. So by accepting a bit of flickering
we can simplify the driver by dropping that code and make it a
bit more robust by doing a reset. It's a tradeoff and I don't
have strong feelings for either option.

But I think, that this fix should be applied to fixes branch
(and backported to stable). Removing panel enable detection
should not be applied as fix IMHO.

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/panel: sony-acx565akm: Fix race condition in probe

[Sebastian Reichel]

The probe routine acquires the reset GPIO using GPIOD_OUT_LOW. Directly
afterwards it calls acx565akm_detect(), which sets the GPIO value to
HIGH. If the bootloader initialized the GPIO to HIGH before the probe
routine was called, there is only a very short time period of a few
instructions where the reset signal is LOW. Exact time depends on
compiler optimizations, kernel configuration and alignment of the stars,
but I expect it to be always way less than 10us. There are no public
datasheets for the panel, but acx565akm_power_on() has a comment with
timings and reset period should be at least 10us. So this potentially
brings the panel into a half-reset state.

The result is, that panel may not work after boot and can get into a
working state by re-enabling it (e.g. by blanking + unblanking), since
that does a clean reset cycle. This bug has recently been hit by Ivaylo
Dimitrov, but there are some older reports which are probably the same
bug. At least Tony Lindgren, Peter Ujfalusi and Jarkko Nikula have
experienced it in 2017 describing the blank/unblank procedure as
possible workaround.

Note, that the bug really goes back in time. It has originally been
introduced in the predecessor of the omapfb driver in 3c45d05be382
("OMAPDSS: acx565akm panel: handle gpios in panel driver") in 2012.
That driver eventually got replaced by a newer one, which had the bug
from the beginning in 84192742d9c2 ("OMAPDSS: Add Sony ACX565AKM panel
driver") and still exists in fbdev world. That driver has later been
copied to omapdrm and then was used as a basis for this driver. Last
but not least the omapdrm specific driver has been removed in
45f16c82db7e ("drm/omap: displays: Remove unused panel drivers").

Reported-by: Jarkko Nikula 
Reported-by: Peter Ujfalusi 
Reported-by: Tony Lindgren 
Reported-by: Aaro Koskinen 
Reported-by: Ivaylo Dimitrov 
Cc: Merlijn Wajer 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Fixes: 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/panel/panel-sony-acx565akm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c 
b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
index e95fdfb16b6c..ba0b3ead150f 100644
--- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
+++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
@@ -629,7 +629,7 @@ static int acx565akm_probe(struct spi_device *spi)
lcd->spi = spi;
mutex_init(&lcd->mutex);
 
-   lcd->reset_gpio = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_LOW);
+   lcd->reset_gpio = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(lcd->reset_gpio)) {
dev_err(&spi->dev, "failed to get reset GPIO\n");
return PTR_ERR(lcd->reset_gpio);
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 27/56] drm/omap: dsi: do bus locking in host driver

[Sebastian Reichel]

Hi,

On Mon, Nov 09, 2020 at 12:08:33PM +0200, Tomi Valkeinen wrote:
> On 09/11/2020 11:52, Laurent Pinchart wrote:
> > Hi Tomi,
> > 
> > Thank you for the patch.
> > 
> > On Thu, Nov 05, 2020 at 02:03:04PM +0200, Tomi Valkeinen wrote:
> >> From: Sebastian Reichel 
> >>
> >> This moves the bus locking into the host driver and unexports
> >> the custom API in preparation for drm_panel support.
> >>
> >> Signed-off-by: Sebastian Reichel 
> >> Signed-off-by: Tomi Valkeinen 
> 
> 
> 
> >>  static int dsicm_update(struct omap_dss_device *dssdev,
> >> @@ -739,7 +704,6 @@ static int dsicm_update(struct omap_dss_device *dssdev,
> >>dev_dbg(&ddata->dsi->dev, "update %d, %d, %d x %d\n", x, y, w, h);
> >>  
> >>mutex_lock(&ddata->lock);
> >> -  src->ops->dsi.bus_lock(src);
> >>  
> >>r = dsicm_wake_up(ddata);
> >>if (r)
> >> @@ -761,11 +725,9 @@ static int dsicm_update(struct omap_dss_device 
> >> *dssdev,
> >>if (r)
> >>goto err;
> >>  
> >> -  /* note: no bus_unlock here. unlock is src framedone_cb */
> >> -  mutex_unlock(&ddata->lock);
> >> +  /* note: no unlock here. unlock is src framedone_cb */
> > 
> > This change isn't described in the commit message. Could you explain why
> > it's needed ? Locking a mutex in a function and unlocking it elsewhere
> > always scares me.
> 
> Good catch. I don't know why it is needed. I don't think it is, as
> the dsi driver handles the bus lock.
> 
> Sebastian, what was the reason for this lock?
> 
> Note that this goes away in the series, and there's no such lock
> in the end.

It's not really a change. What this patch basically does is to fold
src->ops->dsi.bus_lock(src) into mutex_lock(&ddata->lock), so that
there is only a single locking mechanism. This function previously
had a matching pair of mutex_lock/unlock for ddata->lock, but the
bus was not locked paired. So after conversion the lock must not be
free'd here.

My understanding is, that this is because the bus must not be used
until the update has been done.

-- Sebastian

> >>return 0;
> >>  err:
> >> -  src->ops->dsi.bus_unlock(src);
> >>mutex_unlock(&ddata->lock);
> >>return r;
> >>  }
> >> @@ -791,7 +753,6 @@ static void dsicm_ulps_work(struct work_struct *work)
> >>struct panel_drv_data *ddata = container_of(work, struct panel_drv_data,
> >>ulps_work.work);
> >>struct omap_dss_device *dssdev = &ddata->dssdev;
> >> -  struct omap_dss_device *src = ddata->src;
> >>  
> >>mutex_lock(&ddata->lock);
> >>  
> >> @@ -800,11 +761,8 @@ static void dsicm_ulps_work(struct work_struct *work)
> >>return;
> >>}
> >>  
> >> -  src->ops->dsi.bus_lock(src);
> >> -
> >>dsicm_enter_ulps(ddata);
> >>  
> >> -  src->ops->dsi.bus_unlock(src);
> >>mutex_unlock(&ddata->lock);
> >>  }
> >>  
> >> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> >> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> >> index 41431ca34568..d54b743c2b48 100644
> >> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> >> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> >> @@ -476,17 +476,13 @@ static inline u32 dsi_read_reg(struct dsi_data *dsi, 
> >> const struct dsi_reg idx)
> >>return __raw_readl(base + idx.idx);
> >>  }
> >>  
> >> -static void dsi_bus_lock(struct omap_dss_device *dssdev)
> >> +static void dsi_bus_lock(struct dsi_data *dsi)
> >>  {
> >> -  struct dsi_data *dsi = to_dsi_data(dssdev);
> >> -
> >>down(&dsi->bus_lock);
> > 
> > Nothing to be addressed in this patch, but is there a reason to use a
> > semaphore instead of a mutex ?
> 
> It's been a long time, but I think the reason was that mutex gave a warning 
> after being locked for a
> bit longer time, and semaphore didn't. The resource is reserved while a DSI 
> transfer is active, so
> it could be almost 2 frames (wait for vsync and then transfer frame). Or 
> reading the frame buffer
> back from the panel, which could take a long time (seconds).
> 
> There are better ways to implement it (after this series =).
> 
>  Tomi
> 
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 30/56] drm/omap: dsi: move panel refresh function to host

[Sebastian Reichel]

> that an incorrect split of responsibilities between the panel driver and
> the DSI host driver will result in panel drivers being compatible only
> with specific DSI hosts. It's a difficult issue, but I think we need to
> extend the DSI API to handle this cleanly.

Just some background info, since I looked into this while moving
the driver to the common drm/dsi infrastructure (I used existing
DSI drivers as reference):

IIRC most DSI host drivers do not seem support command mode at all.
Some seemed to support it from within the host driver, though. I
remember Exynos getting the TE gpio in the host driver and using
the IRQ routine to self-refresh (which would effectively always
refresh wasting lots of power compared to only refreshing on page
flip).

Also there are some command mode panel drivers (can be found by
looking for drivers _not_ setting the MIPI_DSI_MODE_VIDEO flag):

 * panel-novatek-nt35510.c
 * panel-samsung-s6d16d0.c
 * panel-samsung-s6e63j0x03.c
 * panel-samsung-s6e3ha2.c
 * panel-sharp-lq101r1sx01.c
 * panel-sony-acx424akp.c

So extending the DSI API will involve more drivers than omapdrm and
its DSI command mode panel driver and should probably be done in its
own series.

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/10] drm/fb-helper: Restore damage area upon errors

[Sebastian Reichel]

Hi,

On Mon, Nov 16, 2020 at 09:52:16PM +0100, Daniel Vetter wrote:
> On Mon, Nov 16, 2020 at 09:04:35PM +0100, Thomas Zimmermann wrote:
> > If the damage handling fails, restore the damage area. The next invocation
> > of the damage worker will then perform the update.
> > 
> > Signed-off-by: Thomas Zimmermann 
> > ---
> >  drivers/gpu/drm/drm_fb_helper.c | 23 ---
> >  1 file changed, 20 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 2e1a335bafd2..13b65dad2ca8 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -431,11 +431,28 @@ static void drm_fb_helper_damage_work(struct 
> > work_struct *work)
> > if (helper->buffer) {
> > ret = drm_fb_helper_damage_blit(helper, &clip_copy);
> > if (ret)
> > -   return;
> > +   goto err;
> > }
> >  
> > -   if (helper->fb->funcs->dirty)
> > -   helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
> > +   if (helper->fb->funcs->dirty) {
> > +   ret = helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, 
> > &clip_copy, 1);
> > +   if (ret)
> > +   goto err;
> 
> I think this is unexpected enough that we should put some drm error
> printing here I think.

Note, that the dirty framebuffer routines are used by the
framebuffer console. Printing warnings means another line
in the framebuffer console and thus another call to the
dirty routines. Assuming the problem does not get solved
magically the system will be busy printing warnings forever.
I have been through that fun while working on the OMAP DSI
command mode patches and I suggest to only do ratelimited
logging in the code related to damage tracking.

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] dt-bindings: display: panel: one file of all simple LVDS panels with dual ports

[Sebastian Reichel]

Hi,

On Tue, Nov 17, 2020 at 09:47:25AM +0800, Liu Ying wrote:
> To complement panel-simple.yaml, create panel-simple-lvds-dual-ports.yaml.
> panel-simple-lvds-dual-ports.yaml is for all simple LVDS panels that
> have dual LVDS ports and require only a single power-supply.
> The first port receives odd pixels, and the second port receives even pixels.
> Optionally, a backlight and an enable GPIO can be specified as properties.
> 
> Panels with swapped pixel order, if any, need dedicated bindings.
> 
> Migrate 'auo,g133han01', 'auo,g185han01', 'auo,g190ean01',
> 'koe,tx26d202vm0bwa' and 'nlt,nl192108ac18-02d' over to the new file.
> 
> The objectives with one file for all the simple LVDS panels with dual ports 
> are:
> - Make it simpler to add bindings for this kind of LVDS panels
> - Keep the number of bindings file lower
> - Keep the binding documentation for this kind of LVDS panels more consistent
> - Make it possible for drivers to get pixel order via
>   drm_of_lvds_get_dual_link_pixel_order(), as the optional 'ports' property is
>   allowed
> 
> Suggested-by: Sam Ravnborg 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Rob Herring 
> Cc: Lucas Stach 
> Cc: Sebastian Reichel 
> Signed-off-by: Liu Ying 
> ---

Is this part of a bigger patchset updating the fsl,imx6q-ldb
binding [0] (and driver), which has the following property?

 - fsl,dual-channel : boolean. if it exists, only LVDS channel 0 should
   be configured - one input will be distributed on both outputs in dual
   channel mode

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/imx/ldb.txt

I have an out of tree platform (HW is still in development, DT will 
be upstreamed when hardware design is final) using "auo,g190ean01"
with that panel on i.MX6 and it currently works. It don't mind
updating the DT (new binding looks cleaner :)), but this patch by
itself seems to 'break' support for dual channel panels on i.MX6?

-- Sebastian

> v3->v4:
> * Add type and descriptions for dual-lvds-{odd,even}-pixels properties.
>   Also, update descriptions for port@0 and port@1 properties accordingly. 
> (Rob)
> 
> v2->v3:
> * Do not allow 'port' property. (Rob)
> * Define port number. (Rob)
> * Specify 'dual-lvds-odd-pixels' and 'dual-lvds-even-pixels' properties. (Rob)
> 
> v1->v2:
> * Correct pixel order in example LVDS panel node.
> 
>  .../panel/panel-simple-lvds-dual-ports.yaml| 130 
> +
>  .../bindings/display/panel/panel-simple.yaml   |  10 --
>  2 files changed, 130 insertions(+), 10 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
>  
> b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> new file mode 100644
> index ..38a789b
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> @@ -0,0 +1,130 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: 
> http://devicetree.org/schemas/display/panel/panel-simple-lvds-dual-ports.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Simple LVDS panels with one power supply and dual LVDS ports
> +
> +maintainers:
> +  - Liu Ying 
> +  - Thierry Reding 
> +  - Sam Ravnborg 
> +
> +description: |
> +  This binding file is a collection of the LVDS panels that
> +  has dual LVDS ports and requires only a single power-supply.
> +  The first port receives odd pixels, and the second port receives even 
> pixels.
> +  There are optionally a backlight and an enable GPIO.
> +  The panel may use an OF graph binding for the association to the display,
> +  or it may be a direct child node of the display.
> +
> +  If the panel is more advanced a dedicated binding file is required.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +
> +  compatible:
> +enum:
> +# compatible must be listed in alphabetical order, ordered by compatible.
> +# The description in the comment is mandatory for each compatible.
> +
> +# AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
> +  - auo,g133han01
> +# AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
> +  - auo,g185han01
> +# AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
> +  

Re: Handling DRM master transitions cooperatively

[Sebastian Wick]

On Tue, 07 Sep 2021 10:19:03 +
Simon Ser  wrote:

> FWIW, I've just hit a case where a compositor leaves a "rotation" KMS
> prop set behind, then Xorg tries to startup and fails because it doesn't
> reset this prop. So none of this is theoretical.
>
> I still think a "reset all KMS props to an arbitrary default value" flag
> in drmModeAtomicCommit is the best way forward. I'm not sure a user-space
> protocol would help too much.

Hi Simon,

for the "reset KMS state" problem, sure. Thanks for confirming the
problem, too.

The hand-off problem does need userspace protocol though, so that the
two parties can negotiate what part of KMS state can be inherited by
the receiver and who will do the animation from the first to the second
state in case you want to avoid abrupt changes. It would also be useful
for a cross-fade as a perhaps more flexible way than the current "leak
an FB, let the next KMS client scrape it via ioctls and copy it so it
can be textured from".


The state reset already is an implicit protocol. Another IPC mechanism
however could extend it to work the other way around: instead of
inheriting all the state and trying to transition from that to the
second client's desired state the second client would send its own
desired state back to the first (instead of applying it immediately)
which would then try to transition from its own state to the second
state (and if it can't you fall back to the implicit inherited state
protocol). However, this is only an improvement if the first client
knows how to do the transition and the second does not. All in all I
doubt that you can convince most people to add this kind of complexity
just for slightly higher chances of a good transition.

The reset state protocol on the other hand solves real problems and
gives you a good transition as long as the second client knows about the
same properties as the previous one which usually is the case for the
typical bootsplash->login manager->compositor chain.

Maybe I'm completely missing how such a protocol would work though.


Userspace protocol is also useful for starting the next KMS client
first and handing off only later once it's actually running. I'm not
sure if that is already possible with the session switching stuff, but
I have a feeling it might be fragile or miss pieces like the next KMS
client signalling ready before actually switching to it.


Thanks,
pq

Re: [PATCH v2 28/34] power: supply: ab8500: Migrate to aggregate driver

[Sebastian Reichel]

Hi,

[+cc Linus Walleij (I guess we should add a MAINTAINERS entry for
the ab8500* power-supply drivers)]

On Wed, Oct 06, 2021 at 12:38:13PM -0700, Stephen Boyd wrote:
> Use an aggregate driver instead of component ops so that we can get
> proper driver probe ordering of the aggregate device with respect to all
> the component devices that make up the aggregate device.
> 
> Cc: Sebastian Reichel 
> Cc: 
> Cc: Daniel Vetter 
> Cc: "Rafael J. Wysocki" 
> Cc: Rob Clark 
> Cc: Russell King 
> Cc: Saravana Kannan 
> Signed-off-by: Stephen Boyd 
> ---

Acked-by: Sebastian Reichel 

-- Sebastian

>  drivers/power/supply/ab8500_charger.c | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/power/supply/ab8500_charger.c 
> b/drivers/power/supply/ab8500_charger.c
> index 15eadaf46f14..52d4105e28f2 100644
> --- a/drivers/power/supply/ab8500_charger.c
> +++ b/drivers/power/supply/ab8500_charger.c
> @@ -3312,8 +3312,9 @@ static const struct power_supply_desc 
> ab8500_usb_chg_desc = {
>   .get_property   = ab8500_charger_usb_get_property,
>  };
>  
> -static int ab8500_charger_bind(struct device *dev)
> +static int ab8500_charger_bind(struct aggregate_device *adev)
>  {
> + struct device *dev = adev->parent;
>   struct ab8500_charger *di = dev_get_drvdata(dev);
>   int ch_stat;
>   int ret;
> @@ -3354,8 +3355,9 @@ static int ab8500_charger_bind(struct device *dev)
>   return 0;
>  }
>  
> -static void ab8500_charger_unbind(struct device *dev)
> +static void ab8500_charger_unbind(struct aggregate_device *adev)
>  {
> + struct device *dev = adev->parent;
>   struct ab8500_charger *di = dev_get_drvdata(dev);
>   int ret;
>  
> @@ -3380,9 +3382,13 @@ static void ab8500_charger_unbind(struct device *dev)
>   component_unbind_all(dev, di);
>  }
>  
> -static const struct component_master_ops ab8500_charger_comp_ops = {
> - .bind = ab8500_charger_bind,
> - .unbind = ab8500_charger_unbind,
> +static struct aggregate_driver ab8500_charger_aggregate_driver = {
> + .probe = ab8500_charger_bind,
> + .remove = ab8500_charger_unbind,
> + .driver = {
> + .name = "ab8500_charger_agg",
> + .owner = THIS_MODULE,
> + },
>  };
>  
>  static struct platform_driver *const ab8500_charger_component_drivers[] = {
> @@ -3663,9 +3669,7 @@ static int ab8500_charger_probe(struct platform_device 
> *pdev)
>   }
>  
>  
> - ret = component_master_add_with_match(&pdev->dev,
> -   &ab8500_charger_comp_ops,
> -   match);
> + ret = component_aggregate_register(&pdev->dev, 
> &ab8500_charger_aggregate_driver, match);
>   if (ret) {
>   dev_err(dev, "failed to add component master\n");
>   goto free_notifier;
> @@ -3688,7 +3692,7 @@ static int ab8500_charger_remove(struct platform_device 
> *pdev)
>  {
>   struct ab8500_charger *di = platform_get_drvdata(pdev);
>  
> - component_master_del(&pdev->dev, &ab8500_charger_comp_ops);
> + component_aggregate_unregister(&pdev->dev, 
> &ab8500_charger_aggregate_driver);
>  
>   usb_unregister_notifier(di->usb_phy, &di->nb);
>   usb_put_phy(di->usb_phy);
> -- 
> https://chromeos.dev
> 


signature.asc
Description: PGP signature

Re: [PATCH] drm: panel: replace snprintf in show functions with sysfs_emit

[Sebastian Reichel]

Hi,

On Thu, Oct 14, 2021 at 11:48:10PM -0700, Qing Wang wrote:
> show() must not use snprintf() when formatting the value to be
> returned to user space.
> 
> Fix the following coccicheck warning:
> drivers/gpu/drm/panel/panel-dsi-cm.c:251: WARNING: use scnprintf or sprintf.
> drivers/gpu/drm/panel/panel-dsi-cm.c:271: WARNING: use scnprintf or sprintf.
> 
> Use sysfs_emit instead of scnprintf or sprintf makes more sense.
> 
> Signed-off-by: Qing Wang 
> ---

The patch subject could be more specific (this updates just one panel driver).
Otherwise:

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/panel/panel-dsi-cm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c 
> b/drivers/gpu/drm/panel/panel-dsi-cm.c
> index 5fbfb71..a8efb06 100644
> --- a/drivers/gpu/drm/panel/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
> @@ -248,7 +248,7 @@ static ssize_t num_dsi_errors_show(struct device *dev,
>   if (r)
>   return r;
>  
> - return snprintf(buf, PAGE_SIZE, "%d\n", errors);
> + return sysfs_emit(buf, "%d\n", errors);
>  }
>  
>  static ssize_t hw_revision_show(struct device *dev,
> @@ -268,7 +268,7 @@ static ssize_t hw_revision_show(struct device *dev,
>   if (r)
>   return r;
>  
> - return snprintf(buf, PAGE_SIZE, "%02x.%02x.%02x\n", id1, id2, id3);
> + return sysfs_emit(buf, "%02x.%02x.%02x\n", id1, id2, id3);
>  }
>  
>  static DEVICE_ATTR_RO(num_dsi_errors);
> -- 
> 2.7.4
> 


signature.asc
Description: PGP signature

Re: [PATCH v4 50/80] drm/omap: squash omapdrm sub-modules into one

[Sebastian Reichel]

Hi,

On Tue, Nov 24, 2020 at 02:45:08PM +0200, Tomi Valkeinen wrote:
> At the moment we have three different modules: omapdss-base, omapdss,
> omapdrm. This setup is finally obsolete, as the last omapdrm specific
> panel has been converted to DRM panel.
> 
> We can thus remove omapdss-base and omapdss, and just compile everything
> into omapdrm.ko.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/Kconfig   | 119 ++-
>  drivers/gpu/drm/omapdrm/Makefile  |  17 +++-
>  drivers/gpu/drm/omapdrm/dss/Kconfig   | 132 --
>  drivers/gpu/drm/omapdrm/dss/Makefile  |  18 
>  drivers/gpu/drm/omapdrm/dss/base.c|  24 +
>  drivers/gpu/drm/omapdrm/dss/display.c |   2 -
>  drivers/gpu/drm/omapdrm/dss/dss.c |  11 +--
>  drivers/gpu/drm/omapdrm/dss/omapdss.h |   3 +
>  drivers/gpu/drm/omapdrm/dss/output.c  |  11 ---
>  drivers/gpu/drm/omapdrm/omap_drv.c|  20 +++-
>  10 files changed, 155 insertions(+), 202 deletions(-)
>  delete mode 100644 drivers/gpu/drm/omapdrm/dss/Kconfig
>  delete mode 100644 drivers/gpu/drm/omapdrm/dss/Makefile
> 
> diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig
> index cea3f44ea6d4..e7281da5bc6a 100644
> --- a/drivers/gpu/drm/omapdrm/Kconfig
> +++ b/drivers/gpu/drm/omapdrm/Kconfig
> @@ -5,12 +5,129 @@ config DRM_OMAP
>   depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
>   select OMAP2_DSS
>   select DRM_KMS_HELPER
> + select VIDEOMODE_HELPERS
> + select HDMI
>   default n
>   help
> DRM display driver for OMAP2/3/4 based boards.
>  
>  if DRM_OMAP
>  
> -source "drivers/gpu/drm/omapdrm/dss/Kconfig"
> +config OMAP2_DSS_DEBUG
> + bool "Debug support"
> + default n
> + help
> +   This enables printing of debug messages. Alternatively, debug messages
> +   can also be enabled by setting CONFIG_DYNAMIC_DEBUG and then setting
> +   appropriate flags in /dynamic_debug/control.
> +
> +config OMAP2_DSS_DEBUGFS
> + bool "Debugfs filesystem support"
> + depends on DEBUG_FS
> + default n
> + help
> +   This enables debugfs for OMAPDSS at /omapdss. This enables
> +   querying about clock configuration and register configuration of dss,
> +   dispc, dsi, hdmi and rfbi.
> +
> +config OMAP2_DSS_COLLECT_IRQ_STATS
> + bool "Collect DSS IRQ statistics"
> + depends on OMAP2_DSS_DEBUGFS
> + default n
> + help
> +   Collect DSS IRQ statistics, printable via debugfs.
> +
> +   The statistics can be found from
> +   /omapdss/dispc_irq for DISPC interrupts, and
> +   /omapdss/dsi_irq for DSI interrupts.
> +
> +config OMAP2_DSS_DPI
> + bool "DPI support"
> + default y
> + help
> +   DPI Interface. This is the Parallel Display Interface.
> +
> +config OMAP2_DSS_VENC
> + bool "VENC support"
> + default y
> + help
> +   OMAP Video Encoder support for S-Video and composite TV-out.
> +
> +config OMAP2_DSS_HDMI_COMMON
> + bool
> +
> +config OMAP4_DSS_HDMI
> + bool "HDMI support for OMAP4"
> + default y
> + select OMAP2_DSS_HDMI_COMMON
> + help
> +   HDMI support for OMAP4 based SoCs.
> +
> +config OMAP4_DSS_HDMI_CEC
> + bool "Enable HDMI CEC support for OMAP4"
> + depends on OMAP4_DSS_HDMI
> + select CEC_CORE
> + default y
> + help
> +   When selected the HDMI transmitter will support the CEC feature.
> +
> +config OMAP5_DSS_HDMI
> + bool "HDMI support for OMAP5"
> + default n
> + select OMAP2_DSS_HDMI_COMMON
> + help
> +   HDMI Interface for OMAP5 and similar cores. This adds the High
> +   Definition Multimedia Interface. See http://www.hdmi.org/ for HDMI
> +   specification.
> +
> +config OMAP2_DSS_SDI
> + bool "SDI support"
> + default n
> + help
> +   SDI (Serial Display Interface) support.
> +
> +   SDI is a high speed one-way display serial bus between the host
> +   processor and a display.
> +
> +config OMAP2_DSS_DSI
> + bool "DSI support"
> + default n
> + select DRM_MIPI_DSI
> + help
> +   MIPI DSI (Display Serial Interface) support.
> +
> +   DSI is a high speed half-duplex serial interface between the host
> +   processor and a peripheral, such as a display or a framebuffer chip.
> +
> +   See http://www.mipi.org/ for DSI specifications.
> +
> +con

Re: [PATCH v4 51/80] drm/omap: remove unused display.c

[Sebastian Reichel]

Hi,

On Tue, Nov 24, 2020 at 02:45:09PM +0200, Tomi Valkeinen wrote:
> The functions in display.c are not used, so drop the file.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/Makefile  |  2 +-
>  drivers/gpu/drm/omapdrm/dss/display.c | 58 ---
>  drivers/gpu/drm/omapdrm/dss/omapdss.h |  4 --
>  3 files changed, 1 insertion(+), 63 deletions(-)
>  delete mode 100644 drivers/gpu/drm/omapdrm/dss/display.c
> 
> diff --git a/drivers/gpu/drm/omapdrm/Makefile 
> b/drivers/gpu/drm/omapdrm/Makefile
> index 33fe7e937680..21e8277ff88f 100644
> --- a/drivers/gpu/drm/omapdrm/Makefile
> +++ b/drivers/gpu/drm/omapdrm/Makefile
> @@ -18,7 +18,7 @@ omapdrm-y := omap_drv.o \
>  
>  omapdrm-$(CONFIG_DRM_FBDEV_EMULATION) += omap_fbdev.o
>  
> -omapdrm-y += dss/base.o dss/display.o dss/output.o dss/dss.o dss/dispc.o \
> +omapdrm-y += dss/base.o dss/output.o dss/dss.o dss/dispc.o \
>   dss/dispc_coefs.o dss/pll.o dss/video-pll.o
>  omapdrm-$(CONFIG_OMAP2_DSS_DPI) += dss/dpi.o
>  omapdrm-$(CONFIG_OMAP2_DSS_VENC) += dss/venc.o
> diff --git a/drivers/gpu/drm/omapdrm/dss/display.c 
> b/drivers/gpu/drm/omapdrm/dss/display.c
> deleted file mode 100644
> index 7b7ee2019eae..
> --- a/drivers/gpu/drm/omapdrm/dss/display.c
> +++ /dev/null
> @@ -1,58 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-only
> -/*
> - * Copyright (C) 2009 Nokia Corporation
> - * Author: Tomi Valkeinen 
> - *
> - * Some code and ideas taken from drivers/video/omap/ driver
> - * by Imre Deak.
> - */
> -
> -#define DSS_SUBSYS_NAME "DISPLAY"
> -
> -#include 
> -#include 
> -
> -#include 
> -#include 
> -
> -#include "omapdss.h"
> -
> -static int disp_num_counter;
> -
> -void omapdss_display_init(struct omap_dss_device *dssdev)
> -{
> - int id;
> -
> - /*
> -  * Note: this presumes that all displays either have an DT alias, or
> -  * none has.
> -  */
> - id = of_alias_get_id(dssdev->dev->of_node, "display");
> - if (id < 0)
> - id = disp_num_counter++;
> -
> - /* Use 'label' property for name, if it exists */
> - of_property_read_string(dssdev->dev->of_node, "label", &dssdev->name);
> -
> - if (dssdev->name == NULL)
> - dssdev->name = devm_kasprintf(dssdev->dev, GFP_KERNEL,
> -   "display%u", id);
> -}
> -
> -int omapdss_display_get_modes(struct drm_connector *connector,
> -   const struct videomode *vm)
> -{
> - struct drm_display_mode *mode;
> -
> - mode = drm_mode_create(connector->dev);
> - if (!mode)
> - return 0;
> -
> - drm_display_mode_from_videomode(vm, mode);
> -
> - mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> - drm_mode_set_name(mode);
> - drm_mode_probed_add(connector, mode);
> -
> - return 1;
> -}
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index 4e7ae164de4f..90e41c635e45 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -300,10 +300,6 @@ struct dss_pdata {
>   struct dss_device *dss;
>  };
>  
> -void omapdss_display_init(struct omap_dss_device *dssdev);
> -int omapdss_display_get_modes(struct drm_connector *connector,
> -   const struct videomode *vm);
> -
>  void omapdss_device_register(struct omap_dss_device *dssdev);
>  void omapdss_device_unregister(struct omap_dss_device *dssdev);
>  struct omap_dss_device *omapdss_device_get(struct omap_dss_device *dssdev);
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 52/80] drm/omap: drop unused owner field

[Sebastian Reichel]

Hi,

On Tue, Nov 24, 2020 at 02:45:10PM +0200, Tomi Valkeinen wrote:
> dssdev->owner is set, but never used. We can drop the field.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dpi.c | 1 -
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 1 -
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c   | 1 -
>  drivers/gpu/drm/omapdrm/dss/hdmi5.c   | 1 -
>  drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 --
>  drivers/gpu/drm/omapdrm/dss/sdi.c | 1 -
>  drivers/gpu/drm/omapdrm/dss/venc.c| 1 -
>  7 files changed, 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
> b/drivers/gpu/drm/omapdrm/dss/dpi.c
> index 1d2992daef40..030f997eccd0 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -641,7 +641,6 @@ static int dpi_init_output_port(struct dpi_data *dpi, 
> struct device_node *port)
>   out->type = OMAP_DISPLAY_TYPE_DPI;
>   out->dispc_channel = dpi_get_channel(dpi);
>   out->of_port = port_num;
> - out->owner = THIS_MODULE;
>  
>   r = omapdss_device_init_output(out, &dpi->bridge);
>   if (r < 0) {
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 1ea490e4fc9d..c3592c6db977 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -5442,7 +5442,6 @@ static int dsi_init_output(struct dsi_data *dsi)
>   out->name = dsi->module_id == 0 ? "dsi.0" : "dsi.1";
>   out->dispc_channel = dsi_get_channel(dsi);
>   out->dsi_ops = &dsi_ops;
> - out->owner = THIS_MODULE;
>   out->of_port = 0;
>   out->bus_flags = DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE
>  | DRM_BUS_FLAG_DE_HIGH
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> index a14fbf06cb30..13701571d59b 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> @@ -707,7 +707,6 @@ static int hdmi4_init_output(struct omap_hdmi *hdmi)
>   out->type = OMAP_DISPLAY_TYPE_HDMI;
>   out->name = "hdmi.0";
>   out->dispc_channel = OMAP_DSS_CHANNEL_DIGIT;
> - out->owner = THIS_MODULE;
>   out->of_port = 0;
>  
>   r = omapdss_device_init_output(out, &hdmi->bridge);
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c 
> b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> index b738d9750686..5d627caf90f2 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> @@ -681,7 +681,6 @@ static int hdmi5_init_output(struct omap_hdmi *hdmi)
>   out->type = OMAP_DISPLAY_TYPE_HDMI;
>   out->name = "hdmi.0";
>   out->dispc_channel = OMAP_DSS_CHANNEL_DIGIT;
> - out->owner = THIS_MODULE;
>   out->of_port = 0;
>  
>   r = omapdss_device_init_output(out, &hdmi->bridge);
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index 90e41c635e45..4442e49ffc5c 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -263,8 +263,6 @@ struct omapdss_dsi_ops {
>  struct omap_dss_device {
>   struct device *dev;
>  
> - struct module *owner;
> -
>   struct dss_device *dss;
>   struct drm_bridge *bridge;
>   struct drm_bridge *next_bridge;
> diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c 
> b/drivers/gpu/drm/omapdrm/dss/sdi.c
> index 033fd30074b0..35827b4487bd 100644
> --- a/drivers/gpu/drm/omapdrm/dss/sdi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/sdi.c
> @@ -314,7 +314,6 @@ static int sdi_init_output(struct sdi_device *sdi)
>   out->dispc_channel = OMAP_DSS_CHANNEL_LCD;
>   /* We have SDI only on OMAP3, where it's on port 1 */
>   out->of_port = 1;
> - out->owner = THIS_MODULE;
>   out->bus_flags = DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE /* 15.5.9.1.2 */
>  | DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE;
>  
> diff --git a/drivers/gpu/drm/omapdrm/dss/venc.c 
> b/drivers/gpu/drm/omapdrm/dss/venc.c
> index 6e418a0f7572..8ecffe5bbd29 100644
> --- a/drivers/gpu/drm/omapdrm/dss/venc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/venc.c
> @@ -730,7 +730,6 @@ static int venc_init_output(struct venc_device *venc)
>   out->type = OMAP_DISPLAY_TYPE_VENC;
>   out->name = "venc.0";
>   out->dispc_channel = OMAP_DSS_CHANNEL_DIGIT;
> - out->owner = THIS_MODULE;
>   out->of_port = 0;
>  
>   r = omapdss_device_init_output(out, &venc->bridge);
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 53/80] drm/omap: remove dispc_ops

[Sebastian Reichel]

Hi,

On Tue, Nov 24, 2020 at 02:45:11PM +0200, Tomi Valkeinen wrote:
> dispc_ops was created to help with the multi-module architecture and
> giving us the possibility of multiple dispc implementations. Neither of
> these is valid anymore, and we can remove dispc_ops and use direct
> calls to dispc.
> 
> Signed-off-by: Tomi Valkeinen 
> Acked-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/base.c|   5 --
>  drivers/gpu/drm/omapdrm/dss/dispc.c   | 101 +++---
>  drivers/gpu/drm/omapdrm/dss/dss.h |  71 +-
>  drivers/gpu/drm/omapdrm/dss/omapdss.h |  71 --
>  drivers/gpu/drm/omapdrm/omap_crtc.c   |  30 
>  drivers/gpu/drm/omapdrm/omap_drv.c|  15 ++--
>  drivers/gpu/drm/omapdrm/omap_drv.h|   2 +-
>  drivers/gpu/drm/omapdrm/omap_irq.c|  34 -
>  drivers/gpu/drm/omapdrm/omap_plane.c  |  12 +--
>  9 files changed, 143 insertions(+), 198 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/base.c 
> b/drivers/gpu/drm/omapdrm/dss/base.c
> index 6c57d9292415..ee71b05ef567 100644
> --- a/drivers/gpu/drm/omapdrm/dss/base.c
> +++ b/drivers/gpu/drm/omapdrm/dss/base.c
> @@ -21,11 +21,6 @@ struct dispc_device *dispc_get_dispc(struct dss_device 
> *dss)
>   return dss->dispc;
>  }
>  
> -const struct dispc_ops *dispc_get_ops(struct dss_device *dss)
> -{
> - return dss->dispc_ops;
> -}
> -
>  /* 
> -
>   * OMAP DSS Devices Handling
>   */
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index 48593932bddf..509bac99cb57 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -351,8 +351,6 @@ static unsigned long dispc_plane_pclk_rate(struct 
> dispc_device *dispc,
>  static unsigned long dispc_plane_lclk_rate(struct dispc_device *dispc,
>  enum omap_plane_id plane);
>  
> -static void dispc_clear_irqstatus(struct dispc_device *dispc, u32 mask);
> -
>  static inline void dispc_write_reg(struct dispc_device *dispc, u16 idx, u32 
> val)
>  {
>   __raw_writel(val, dispc->base + idx);
> @@ -379,12 +377,12 @@ static void mgr_fld_write(struct dispc_device *dispc, 
> enum omap_channel channel,
>   REG_FLD_MOD(dispc, rfld->reg, val, rfld->high, rfld->low);
>  }
>  
> -static int dispc_get_num_ovls(struct dispc_device *dispc)
> +int dispc_get_num_ovls(struct dispc_device *dispc)
>  {
>   return dispc->feat->num_ovls;
>  }
>  
> -static int dispc_get_num_mgrs(struct dispc_device *dispc)
> +int dispc_get_num_mgrs(struct dispc_device *dispc)
>  {
>   return dispc->feat->num_mgrs;
>  }
> @@ -667,13 +665,13 @@ void dispc_runtime_put(struct dispc_device *dispc)
>   WARN_ON(r < 0 && r != -ENOSYS);
>  }
>  
> -static u32 dispc_mgr_get_vsync_irq(struct dispc_device *dispc,
> +u32 dispc_mgr_get_vsync_irq(struct dispc_device *dispc,
>  enum omap_channel channel)
>  {
>   return mgr_desc[channel].vsync_irq;
>  }
>  
> -static u32 dispc_mgr_get_framedone_irq(struct dispc_device *dispc,
> +u32 dispc_mgr_get_framedone_irq(struct dispc_device *dispc,
>  enum omap_channel channel)
>  {
>   if (channel == OMAP_DSS_CHANNEL_DIGIT && dispc->feat->no_framedone_tv)
> @@ -682,18 +680,18 @@ static u32 dispc_mgr_get_framedone_irq(struct 
> dispc_device *dispc,
>   return mgr_desc[channel].framedone_irq;
>  }
>  
> -static u32 dispc_mgr_get_sync_lost_irq(struct dispc_device *dispc,
> +u32 dispc_mgr_get_sync_lost_irq(struct dispc_device *dispc,
>  enum omap_channel channel)
>  {
>   return mgr_desc[channel].sync_lost_irq;
>  }
>  
> -static u32 dispc_wb_get_framedone_irq(struct dispc_device *dispc)
> +u32 dispc_wb_get_framedone_irq(struct dispc_device *dispc)
>  {
>   return DISPC_IRQ_FRAMEDONEWB;
>  }
>  
> -static void dispc_mgr_enable(struct dispc_device *dispc,
> +void dispc_mgr_enable(struct dispc_device *dispc,
>enum omap_channel channel, bool enable)
>  {
>   mgr_fld_write(dispc, channel, DISPC_MGR_FLD_ENABLE, enable);
> @@ -707,13 +705,13 @@ static bool dispc_mgr_is_enabled(struct dispc_device 
> *dispc,
>   return !!mgr_fld_read(dispc, channel, DISPC_MGR_FLD_ENABLE);
>  }
>  
> -static bool dispc_mgr_go_busy(struct dispc_device *dispc,
> +bool dispc_mgr_go_busy(struct dispc_device *dispc,
>   

Re: [PATCH v4 54/80] drm/omap: remove dss_mgr_ops

[Sebastian Reichel]

Hi,

On Tue, Nov 24, 2020 at 02:45:12PM +0200, Tomi Valkeinen wrote:
> dss_mgr_ops was needed with the multi-module architecture, but is no
> longer needed. We can thus remove it and use direct calls.
> 
> Signed-off-by: Tomi Valkeinen 
> Acked-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dss.h |  1 -
>  drivers/gpu/drm/omapdrm/dss/omapdss.h | 42 +++
>  drivers/gpu/drm/omapdrm/dss/output.c  | 33 +
>  drivers/gpu/drm/omapdrm/omap_crtc.c   | 38 +---
>  drivers/gpu/drm/omapdrm/omap_crtc.h   |  2 --
>  drivers/gpu/drm/omapdrm/omap_drv.c|  4 +--
>  6 files changed, 33 insertions(+), 87 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
> b/drivers/gpu/drm/omapdrm/dss/dss.h
> index 96f702314c8c..a547527bb2f3 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/dss.h
> @@ -257,7 +257,6 @@ struct dss_device {
>   struct dss_pll  *video2_pll;
>  
>   struct dispc_device *dispc;
> - const struct dss_mgr_ops *mgr_ops;
>   struct omap_drm_private *mgr_ops_priv;
>  };
>  
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index fba5f05e5e48..9df322ca467d 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -338,31 +338,23 @@ enum dss_writeback_channel {
>   DSS_WB_LCD3_MGR =   7,
>  };
>  
> -struct dss_mgr_ops {
> - void (*start_update)(struct omap_drm_private *priv,
> -  enum omap_channel channel);
> - int (*enable)(struct omap_drm_private *priv,
> -   enum omap_channel channel);
> - void (*disable)(struct omap_drm_private *priv,
> - enum omap_channel channel);
> - void (*set_timings)(struct omap_drm_private *priv,
> - enum omap_channel channel,
> - const struct videomode *vm);
> - void (*set_lcd_config)(struct omap_drm_private *priv,
> -enum omap_channel channel,
> -const struct dss_lcd_mgr_config *config);
> - int (*register_framedone_handler)(struct omap_drm_private *priv,
> - enum omap_channel channel,
> - void (*handler)(void *), void *data);
> - void (*unregister_framedone_handler)(struct omap_drm_private *priv,
> - enum omap_channel channel,
> - void (*handler)(void *), void *data);
> -};
> -
> -int dss_install_mgr_ops(struct dss_device *dss,
> - const struct dss_mgr_ops *mgr_ops,
> - struct omap_drm_private *priv);
> -void dss_uninstall_mgr_ops(struct dss_device *dss);
> +void omap_crtc_dss_start_update(struct omap_drm_private *priv,
> +enum omap_channel channel);
> +void omap_crtc_set_enabled(struct drm_crtc *crtc, bool enable);
> +int omap_crtc_dss_enable(struct omap_drm_private *priv, enum omap_channel 
> channel);
> +void omap_crtc_dss_disable(struct omap_drm_private *priv, enum omap_channel 
> channel);
> +void omap_crtc_dss_set_timings(struct omap_drm_private *priv,
> + enum omap_channel channel,
> + const struct videomode *vm);
> +void omap_crtc_dss_set_lcd_config(struct omap_drm_private *priv,
> + enum omap_channel channel,
> + const struct dss_lcd_mgr_config *config);
> +int omap_crtc_dss_register_framedone(
> + struct omap_drm_private *priv, enum omap_channel channel,
> + void (*handler)(void *), void *data);
> +void omap_crtc_dss_unregister_framedone(
> + struct omap_drm_private *priv, enum omap_channel channel,
> + void (*handler)(void *), void *data);
>  
>  void dss_mgr_set_timings(struct omap_dss_device *dssdev,
>   const struct videomode *vm);
> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c 
> b/drivers/gpu/drm/omapdrm/dss/output.c
> index 7a14d2b5b2f7..2121c947947b 100644
> --- a/drivers/gpu/drm/omapdrm/dss/output.c
> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> @@ -81,54 +81,35 @@ void omapdss_device_cleanup_output(struct omap_dss_device 
> *out)
>   out->next_bridge : out->bridge);
>  }
>  
> -int dss_install_mgr_ops(struct dss_device *dss,
> - const struct dss_mgr_ops *mgr_ops,
> - struct omap_drm_private *priv)
> -{
> - if (dss->mgr_ops)
> - return -EBUSY;
> -
> - dss->mgr_ops = mgr_ops;
> - dss->mgr_ops_priv = priv;
> -

Re: [PATCH v4 55/80] drm/panel: panel-dsi-cm: use MIPI_DCS_GET_ERROR_COUNT_ON_DSI

[Sebastian Reichel]

Hi,

On Tue, Nov 24, 2020 at 02:45:13PM +0200, Tomi Valkeinen wrote:
> Use the common MIPI_DCS_GET_ERROR_COUNT_ON_DSI define instead of
> driver's own.
> 
> Signed-off-by: Tomi Valkeinen 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/panel/panel-dsi-cm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c 
> b/drivers/gpu/drm/panel/panel-dsi-cm.c
> index 35a0c7da1974..cb0d27a38555 100644
> --- a/drivers/gpu/drm/panel/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
> @@ -27,7 +27,6 @@
>  #include 
>  #include 
>  
> -#define DCS_READ_NUM_ERRORS  0x05
>  #define DCS_GET_ID1  0xda
>  #define DCS_GET_ID2  0xdb
>  #define DCS_GET_ID3  0xdc
> @@ -225,7 +224,7 @@ static ssize_t num_dsi_errors_show(struct device *dev,
>   mutex_lock(&ddata->lock);
>  
>   if (ddata->enabled)
> - r = dsicm_dcs_read_1(ddata, DCS_READ_NUM_ERRORS, &errors);
> + r = dsicm_dcs_read_1(ddata, MIPI_DCS_GET_ERROR_COUNT_ON_DSI, 
> &errors);
>  
>   mutex_unlock(&ddata->lock);
>  
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 56/80] drm/panel: panel-dsi-cm: cleanup tear enable

[Sebastian Reichel]

Hi,

On Tue, Nov 24, 2020 at 02:45:14PM +0200, Tomi Valkeinen wrote:
> Simplify the code by moving code from _dsicm_enable_te() into
> dsicm_power_on().
> 
> Signed-off-by: Tomi Valkeinen 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/panel/panel-dsi-cm.c | 23 ---
>  1 file changed, 4 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c 
> b/drivers/gpu/drm/panel/panel-dsi-cm.c
> index cb0d27a38555..59e8e6b18e97 100644
> --- a/drivers/gpu/drm/panel/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
> @@ -69,8 +69,6 @@ static inline struct panel_drv_data *panel_to_ddata(struct 
> drm_panel *panel)
>   return container_of(panel, struct panel_drv_data, panel);
>  }
>  
> -static int _dsicm_enable_te(struct panel_drv_data *ddata, bool enable);
> -
>  static void dsicm_bl_power(struct panel_drv_data *ddata, bool enable)
>  {
>   struct backlight_device *backlight;
> @@ -314,10 +312,13 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
>   if (r)
>   goto err;
>  
> - r = _dsicm_enable_te(ddata, true);
> + r = mipi_dsi_dcs_set_tear_on(ddata->dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
>   if (r)
>   goto err;
>  
> + /* possible panel bug */
> + msleep(100);
> +
>   ddata->enabled = true;
>  
>   if (!ddata->intro_printed) {
> @@ -418,22 +419,6 @@ static int dsicm_disable(struct drm_panel *panel)
>   return r;
>  }
>  
> -static int _dsicm_enable_te(struct panel_drv_data *ddata, bool enable)
> -{
> - struct mipi_dsi_device *dsi = ddata->dsi;
> - int r;
> -
> - if (enable)
> - r = mipi_dsi_dcs_set_tear_on(dsi, 
> MIPI_DSI_DCS_TEAR_MODE_VBLANK);
> - else
> - r = mipi_dsi_dcs_set_tear_off(dsi);
> -
> - /* possible panel bug */
> - msleep(100);
> -
> - return r;
> -}
> -
>  static int dsicm_get_modes(struct drm_panel *panel,
>  struct drm_connector *connector)
>  {
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 57/80] ARM: dts: omap5: add address-cells & size-cells to dsi

[Sebastian Reichel]

Hi,

On Tue, Nov 24, 2020 at 02:45:15PM +0200, Tomi Valkeinen wrote:
> Add address-cells & size-cells to DSI nodes so that board files do not
> need to define them.
> 
> Signed-off-by: Tomi Valkeinen 
> Cc: Tony Lindgren 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  arch/arm/boot/dts/omap5.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 2bf2e5839a7f..e6f6947965ef 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -517,6 +517,9 @@ dsi1: encoder@0 {
>   clocks = <&dss_clkctrl 
> OMAP5_DSS_CORE_CLKCTRL 8>,
><&dss_clkctrl 
> OMAP5_DSS_CORE_CLKCTRL 10>;
>   clock-names = "fck", "sys_clk";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
>   };
>   };
>  
> @@ -549,6 +552,9 @@ dsi2: encoder@0 {
>   clocks = <&dss_clkctrl 
> OMAP5_DSS_CORE_CLKCTRL 8>,
><&dss_clkctrl 
> OMAP5_DSS_CORE_CLKCTRL 10>;
>   clock-names = "fck", "sys_clk";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
>   };
>   };
>  
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 58/80] drm/omap: pll: fix iteration loop check

[Sebastian Reichel]

Hi,

On Tue, Nov 24, 2020 at 02:45:16PM +0200, Tomi Valkeinen wrote:
> If the PLL calc function is given bad parameters, n_start/m_start may be
> higher than n_stop/m_stop, which leads to the loops iterating through
> the whole u32 number space.
> 
> Fix this by failing early on such cases.
> 
> Signed-off-by: Tomi Valkeinen 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/pll.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/pll.c 
> b/drivers/gpu/drm/omapdrm/dss/pll.c
> index 1212f3cc52d1..12926218c436 100644
> --- a/drivers/gpu/drm/omapdrm/dss/pll.c
> +++ b/drivers/gpu/drm/omapdrm/dss/pll.c
> @@ -222,6 +222,9 @@ bool dss_pll_calc_a(const struct dss_pll *pll, unsigned 
> long clkin,
>   n_stop = min((unsigned)(clkin / fint_hw_min), hw->n_max);
>   n_inc = 1;
>  
> + if (n_start > n_stop)
> + return false;
> +
>   if (hw->errata_i886) {
>   swap(n_start, n_stop);
>   n_inc = -1;
> @@ -239,6 +242,9 @@ bool dss_pll_calc_a(const struct dss_pll *pll, unsigned 
> long clkin,
>   hw->m_max);
>   m_inc = 1;
>  
> + if (m_start > m_stop)
> + continue;
> +
>   if (hw->errata_i886) {
>   swap(m_start, m_stop);
>   m_inc = -1;
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 59/80] drm/omap: dsi: set trans_mode according to client mode_flags

[Sebastian Reichel]

Hi,

On Tue, Nov 24, 2020 at 02:45:17PM +0200, Tomi Valkeinen wrote:
> The DSI host driver currently ignores the video mode flags in
> client->mode_flags. Add the code to take the transfer mode from client's
> mode_flags.
> 
> Signed-off-by: Tomi Valkeinen 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index c3592c6db977..7fee9cf8782d 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -5140,6 +5140,13 @@ static int omap_dsi_host_attach(struct mipi_dsi_host 
> *host,
>   dsi->config.lp_clk_min = 700; // TODO: get from client?
>   dsi->config.lp_clk_max = client->lp_rate;
>  
> + if (client->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> + dsi->config.trans_mode = OMAP_DSS_DSI_BURST_MODE;
> + else if (client->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + dsi->config.trans_mode = OMAP_DSS_DSI_PULSE_MODE;
> + else
> + dsi->config.trans_mode = OMAP_DSS_DSI_EVENT_MODE;
> +
>   dsi->ulps_auto_idle = false;
>  
>   return 0;
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 60/80] drm/panel: panel-dsi-cm: set column & page at setup

[Sebastian Reichel]

Hi,

On Tue, Nov 24, 2020 at 02:45:18PM +0200, Tomi Valkeinen wrote:
> Set the column & page address once during setup, instead of relying the
> DSI host driver to set those.
> 
> Signed-off-by: Tomi Valkeinen 
> ---

I'm fine with or without removal of the variables:

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/panel/panel-dsi-cm.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c 
> b/drivers/gpu/drm/panel/panel-dsi-cm.c
> index 59e8e6b18e97..1e7f73340736 100644
> --- a/drivers/gpu/drm/panel/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
> @@ -171,6 +171,26 @@ static int dsicm_get_id(struct panel_drv_data *ddata, u8 
> *id1, u8 *id2, u8 *id3)
>   return 0;
>  }
>  
> +static int dsicm_set_update_window(struct panel_drv_data *ddata)
> +{
> + struct mipi_dsi_device *dsi = ddata->dsi;
> + int r;
> + u16 x1 = 0;
> + u16 x2 = ddata->mode.hdisplay - 1;
> + u16 y1 = 0;
> + u16 y2 = ddata->mode.vdisplay - 1;
> +
> + r = mipi_dsi_dcs_set_column_address(dsi, x1, x2);
> + if (r < 0)
> + return r;
> +
> + r = mipi_dsi_dcs_set_page_address(dsi, y1, y2);
> + if (r < 0)
> + return r;
> +
> + return 0;
> +}
> +
>  static int dsicm_bl_update_status(struct backlight_device *dev)
>  {
>   struct panel_drv_data *ddata = dev_get_drvdata(&dev->dev);
> @@ -308,6 +328,10 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
>   if (r)
>   goto err;
>  
> + r = dsicm_set_update_window(ddata);
> + if (r)
> + goto err;
> +
>   r = mipi_dsi_dcs_set_display_on(ddata->dsi);
>   if (r)
>   goto err;
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 01/29] drm/panel: panel-dsi-cm: cleanup tear enable

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:27PM +0200, Tomi Valkeinen wrote:
> Simplify the code by moving code from _dsicm_enable_te() into
> dsicm_power_on().
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Sam Ravnborg 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/panel/panel-dsi-cm.c | 23 ---
>  1 file changed, 4 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c 
> b/drivers/gpu/drm/panel/panel-dsi-cm.c
> index 729b42b4dabd..38f79dca1fd0 100644
> --- a/drivers/gpu/drm/panel/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
> @@ -68,8 +68,6 @@ static inline struct panel_drv_data *panel_to_ddata(struct 
> drm_panel *panel)
>   return container_of(panel, struct panel_drv_data, panel);
>  }
>  
> -static int _dsicm_enable_te(struct panel_drv_data *ddata, bool enable);
> -
>  static void dsicm_bl_power(struct panel_drv_data *ddata, bool enable)
>  {
>   struct backlight_device *backlight;
> @@ -313,10 +311,13 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
>   if (r)
>   goto err;
>  
> - r = _dsicm_enable_te(ddata, true);
> + r = mipi_dsi_dcs_set_tear_on(ddata->dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
>   if (r)
>   goto err;
>  
> + /* possible panel bug */
> + msleep(100);
> +
>   ddata->enabled = true;
>  
>   if (!ddata->intro_printed) {
> @@ -417,22 +418,6 @@ static int dsicm_disable(struct drm_panel *panel)
>   return r;
>  }
>  
> -static int _dsicm_enable_te(struct panel_drv_data *ddata, bool enable)
> -{
> - struct mipi_dsi_device *dsi = ddata->dsi;
> - int r;
> -
> - if (enable)
> - r = mipi_dsi_dcs_set_tear_on(dsi, 
> MIPI_DSI_DCS_TEAR_MODE_VBLANK);
> - else
> - r = mipi_dsi_dcs_set_tear_off(dsi);
> -
> - /* possible panel bug */
> - msleep(100);
> -
> - return r;
> -}
> -
>  static int dsicm_get_modes(struct drm_panel *panel,
>  struct drm_connector *connector)
>  {
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 02/29] ARM: dts: omap5: add address-cells & size-cells to dsi

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:28PM +0200, Tomi Valkeinen wrote:
> Add address-cells & size-cells to DSI nodes so that board files do not
> need to define them.
> 
> Signed-off-by: Tomi Valkeinen 
> Cc: Tony Lindgren 
> Acked-by: Tony Lindgren 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  arch/arm/boot/dts/omap5.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 2bf2e5839a7f..e6f6947965ef 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -517,6 +517,9 @@ dsi1: encoder@0 {
>   clocks = <&dss_clkctrl 
> OMAP5_DSS_CORE_CLKCTRL 8>,
><&dss_clkctrl 
> OMAP5_DSS_CORE_CLKCTRL 10>;
>   clock-names = "fck", "sys_clk";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
>   };
>   };
>  
> @@ -549,6 +552,9 @@ dsi2: encoder@0 {
>   clocks = <&dss_clkctrl 
> OMAP5_DSS_CORE_CLKCTRL 8>,
><&dss_clkctrl 
> OMAP5_DSS_CORE_CLKCTRL 10>;
>   clock-names = "fck", "sys_clk";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
>   };
>   };
>  
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 04/29] drm/omap: dsi: set trans_mode according to client mode_flags

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:30PM +0200, Tomi Valkeinen wrote:
> The DSI host driver currently ignores the video mode flags in
> client->mode_flags. Add the code to take the transfer mode from client's
> mode_flags.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index c3592c6db977..7fee9cf8782d 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -5140,6 +5140,13 @@ static int omap_dsi_host_attach(struct mipi_dsi_host 
> *host,
>   dsi->config.lp_clk_min = 700; // TODO: get from client?
>   dsi->config.lp_clk_max = client->lp_rate;
>  
> + if (client->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> + dsi->config.trans_mode = OMAP_DSS_DSI_BURST_MODE;
> + else if (client->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + dsi->config.trans_mode = OMAP_DSS_DSI_PULSE_MODE;
> + else
> + dsi->config.trans_mode = OMAP_DSS_DSI_EVENT_MODE;
> +
>   dsi->ulps_auto_idle = false;
>  
>   return 0;
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 03/29] drm/omap: pll: fix iteration loop check

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:29PM +0200, Tomi Valkeinen wrote:
> If the PLL calc function is given bad parameters, n_start/m_start may be
> higher than n_stop/m_stop, which leads to the loops iterating through
> the whole u32 number space.
> 
> Fix this by failing early on such cases.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/pll.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/pll.c 
> b/drivers/gpu/drm/omapdrm/dss/pll.c
> index 1212f3cc52d1..12926218c436 100644
> --- a/drivers/gpu/drm/omapdrm/dss/pll.c
> +++ b/drivers/gpu/drm/omapdrm/dss/pll.c
> @@ -222,6 +222,9 @@ bool dss_pll_calc_a(const struct dss_pll *pll, unsigned 
> long clkin,
>   n_stop = min((unsigned)(clkin / fint_hw_min), hw->n_max);
>   n_inc = 1;
>  
> + if (n_start > n_stop)
> + return false;
> +
>   if (hw->errata_i886) {
>   swap(n_start, n_stop);
>   n_inc = -1;
> @@ -239,6 +242,9 @@ bool dss_pll_calc_a(const struct dss_pll *pll, unsigned 
> long clkin,
>   hw->m_max);
>   m_inc = 1;
>  
> + if (m_start > m_stop)
> + continue;
> +
>   if (hw->errata_i886) {
>   swap(m_start, m_stop);
>   m_inc = -1;
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 05/29] drm/panel: panel-dsi-cm: set column & page at setup

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:31PM +0200, Tomi Valkeinen wrote:
> Set the column & page address once during setup, instead of relying the
> DSI host driver to set those.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Sam Ravnborg 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/panel/panel-dsi-cm.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c 
> b/drivers/gpu/drm/panel/panel-dsi-cm.c
> index 38f79dca1fd0..556f9a2c5c0c 100644
> --- a/drivers/gpu/drm/panel/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
> @@ -170,6 +170,22 @@ static int dsicm_get_id(struct panel_drv_data *ddata, u8 
> *id1, u8 *id2, u8 *id3)
>   return 0;
>  }
>  
> +static int dsicm_set_update_window(struct panel_drv_data *ddata)
> +{
> + struct mipi_dsi_device *dsi = ddata->dsi;
> + int r;
> +
> + r = mipi_dsi_dcs_set_column_address(dsi, 0, ddata->mode.hdisplay - 1);
> + if (r < 0)
> + return r;
> +
> + r = mipi_dsi_dcs_set_page_address(dsi, 0, ddata->mode.vdisplay - 1);
> + if (r < 0)
> + return r;
> +
> + return 0;
> +}
> +
>  static int dsicm_bl_update_status(struct backlight_device *dev)
>  {
>   struct panel_drv_data *ddata = dev_get_drvdata(&dev->dev);
> @@ -307,6 +323,10 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
>   if (r)
>   goto err;
>  
> + r = dsicm_set_update_window(ddata);
> + if (r)
> + goto err;
> +
>   r = mipi_dsi_dcs_set_display_on(ddata->dsi);
>   if (r)
>   goto err;
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 06/29] drm/omap: dsi: send nop instead of page & column

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:32PM +0200, Tomi Valkeinen wrote:
> The OMAP DSI command mode panel driver used to send page & column
> address before each frame update, and this code was moved into the DSI
> host driver when converting it to the DRM bridge model.
> 
> However, it's not really required to send the page & column address
> before each frame. It's also something that doesn't really belong to the
> DSI host driver, so we should drop the code.
> 
> That said, frame updates break if we don't send _something_ between the
> frames. A NOP command does the trick.
> 
> It is not clear if this behavior is as expected from a DSI command mode
> frame transfer, or is it a feature/issue with OMAP DSI driver, or a
> feature/issue in the command mode panel used.
> 
> Most likely this is related to the following from the DSI spec:
> 
> "To enable PHY synchronization the host processor should periodically
> end HS transmission and drive the Data Lanes to the LP state. This
> transition should take place at least once per frame."
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 46 ---
>  1 file changed, 17 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 7fee9cf8782d..c6e044f8bece 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -3884,35 +3884,19 @@ static int _dsi_update(struct dsi_data *dsi)
>   return 0;
>  }
>  
> -static int _dsi_update_window(struct dsi_data *dsi, int channel,
> -   int x, int y, int w, int h)
> -{
> - int x1 = x, x2 = (x + w - 1);
> - int y1 = y, y2 = (y + h - 1);
> - u8 payloadX[5] = { MIPI_DCS_SET_COLUMN_ADDRESS,
> -x1 >> 8, x1 & 0xff, x2 >> 8, x2 & 0xff };
> - u8 payloadY[5] = { MIPI_DCS_SET_PAGE_ADDRESS,
> -y1 >> 8, y1 & 0xff, y2 >> 8, y2 & 0xff };
> - struct mipi_dsi_msg msgX = { 0 }, msgY = { 0 };
> - int ret;
> +static int _dsi_send_nop(struct dsi_data *dsi, int channel)
> +{
> + const u8 payload[] = { MIPI_DCS_NOP };
> + const struct mipi_dsi_msg msg = {
> + .channel = channel,
> + .type = MIPI_DSI_DCS_SHORT_WRITE,
> + .tx_len = 1,
> + .tx_buf = payload,
> + };
>  
>   WARN_ON(!dsi_bus_is_locked(dsi));
>  
> - msgX.type = MIPI_DSI_DCS_LONG_WRITE;
> - msgX.channel = channel;
> - msgX.tx_buf = payloadX;
> - msgX.tx_len = sizeof(payloadX);
> -
> - msgY.type = MIPI_DSI_DCS_LONG_WRITE;
> - msgY.channel = channel;
> - msgY.tx_buf = payloadY;
> - msgY.tx_len = sizeof(payloadY);
> -
> - ret = _omap_dsi_host_transfer(dsi, &msgX);
> - if (ret != 0)
> - return ret;
> -
> - return _omap_dsi_host_transfer(dsi, &msgY);
> + return _omap_dsi_host_transfer(dsi, &msg);
>  }
>  
>  static int dsi_update_channel(struct omap_dss_device *dssdev, int channel)
> @@ -3944,10 +3928,14 @@ static int dsi_update_channel(struct omap_dss_device 
> *dssdev, int channel)
>  
>   dsi_set_ulps_auto(dsi, false);
>  
> - r = _dsi_update_window(dsi, channel, 0, 0, dsi->vm.hactive,
> -dsi->vm.vactive);
> + /*
> +  * Send NOP between the frames. If we don't send something here, the
> +  * updates stop working. This is probably related to DSI spec stating
> +  * that the DSI host should transition to LP at least once per frame.
> +  */
> + r = _dsi_send_nop(dsi, channel);
>   if (r < 0) {
> - DSSWARN("window update error: %d\n", r);
> + DSSWARN("failed to send nop between frames: %d\n", r);
>   goto err;
>   }
>  
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 07/29] drm/omap: dsi: simplify VC handling

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:33PM +0200, Tomi Valkeinen wrote:
> The VC handling has gotten quite tangled up. As the first step to clean
> it up, lets define that we only support a single DSI peripheral (which
> was really already the case), and we always use VC0 (define VC_DEFAULT
> 0) register block to send data to the peripheral.
> 
> We can thus have a single mipi_dsi_device pointer and remove the
> for-loops which made passes over all the four VCs (just the first one
> was ever used).
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 49 ---
>  1 file changed, 13 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index c6e044f8bece..5e13478010db 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -360,9 +360,10 @@ struct dsi_data {
>   bool vdds_dsi_enabled;
>   struct regulator *vdds_dsi_reg;
>  
> + struct mipi_dsi_device *dsidev;
> +
>   struct {
>   enum dsi_vc_source source;
> - struct mipi_dsi_device *dest;
>   enum fifo_size tx_fifo_size;
>   enum fifo_size rx_fifo_size;
>   } vc[4];
> @@ -452,6 +453,8 @@ static bool dsi_perf;
>  module_param(dsi_perf, bool, 0644);
>  #endif
>  
> +#define VC_DEFAULT 0
> +
>  #define drm_bridge_to_dsi(bridge) \
>   container_of(bridge, struct dsi_data, bridge)
>  
> @@ -3716,16 +3719,11 @@ static void dsi_disable_video_output(struct 
> omap_dss_device *dssdev, int channel
>  static void dsi_disable_video_outputs(struct omap_dss_device *dssdev)
>  {
>   struct dsi_data *dsi = to_dsi_data(dssdev);
> - unsigned int i;
>  
>   dsi_bus_lock(dsi);
>   dsi->video_enabled = false;
>  
> - for (i = 0; i < 4; i++) {
> - if (!dsi->vc[i].dest)
> - continue;
> - dsi_disable_video_output(dssdev, i);
> - }
> + dsi_disable_video_output(dssdev, VC_DEFAULT);
>  
>   dsi_display_disable(dssdev);
>  
> @@ -3914,11 +3912,6 @@ static int dsi_update_channel(struct omap_dss_device 
> *dssdev, int channel)
>   goto err;
>   }
>  
> - if (!dsi->vc[channel].dest) {
> - r = -ENODEV;
> - goto err;
> - }
> -
>   if (dsi->vm.hactive == 0 || dsi->vm.vactive == 0) {
>   r = -EINVAL;
>   goto err;
> @@ -3959,16 +3952,7 @@ static int dsi_update_channel(struct omap_dss_device 
> *dssdev, int channel)
>  
>  static int dsi_update_all(struct omap_dss_device *dssdev)
>  {
> - unsigned int i;
> - int r;
> -
> - for (i = 0; i < 4; i++) {
> - r = dsi_update_channel(dssdev, i);
> - if (r && r != -ENODEV)
> - return r;
> - }
> -
> - return r;
> + return dsi_update_channel(dssdev, VC_DEFAULT);
>  }
>  
>  /* Display funcs */
> @@ -4196,17 +4180,12 @@ static void dsi_display_enable(struct omap_dss_device 
> *dssdev)
>  static void dsi_enable_video_outputs(struct omap_dss_device *dssdev)
>  {
>   struct dsi_data *dsi = to_dsi_data(dssdev);
> - unsigned int i;
>  
>   dsi_bus_lock(dsi);
>  
>   dsi_display_enable(dssdev);
>  
> - for (i = 0; i < 4; i++) {
> - if (!dsi->vc[i].dest)
> - continue;
> - dsi_enable_video_output(dssdev, i);
> - }
> + dsi_enable_video_output(dssdev, VC_DEFAULT);
>  
>   dsi->video_enabled = true;
>  
> @@ -5095,8 +5074,8 @@ static int omap_dsi_host_attach(struct mipi_dsi_host 
> *host,
>   if (channel > 3)
>   return -EINVAL;
>  
> - if (dsi->vc[channel].dest) {
> - DSSERR("cannot get VC for display %s", dev_name(&client->dev));
> + if (dsi->dsidev) {
> + DSSERR("dsi client already attached\n");
>   return -EBUSY;
>   }
>  
> @@ -5117,7 +5096,7 @@ static int omap_dsi_host_attach(struct mipi_dsi_host 
> *host,
>   dsi->mode = OMAP_DSS_DSI_CMD_MODE;
>   }
>  
> - dsi->vc[channel].dest = client;
> + dsi->dsidev = client;
>   dsi->pix_fmt = client->format;
>  
>   INIT_DEFERRABLE_WORK(&dsi->ulps_work,
> @@ -5149,11 +5128,11 @@ static int omap_dsi_host_detach(struct mipi_dsi_host 
> *host,
>   if (channel > 3)
>   return -EINVAL;
>  
> 

Re: [PATCH v5 08/29] drm/omap: dsi: drop useless channel checks

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:34PM +0200, Tomi Valkeinen wrote:
> A DSI peripheral can have virtual channel ID of 0-3. This should be
> always the case, and there's no need in the driver to validate the
> channel.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 11 ---
>  1 file changed, 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 5e13478010db..c78ae99c8742 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -3902,9 +3902,6 @@ static int dsi_update_channel(struct omap_dss_device 
> *dssdev, int channel)
>   struct dsi_data *dsi = to_dsi_data(dssdev);
>   int r;
>  
> - if (channel > 3)
> - return -EINVAL;
> -
>   dsi_bus_lock(dsi);
>  
>   if (!dsi->video_enabled) {
> @@ -5068,12 +5065,8 @@ static int omap_dsi_host_attach(struct mipi_dsi_host 
> *host,
>   struct mipi_dsi_device *client)
>  {
>   struct dsi_data *dsi = host_to_omap(host);
> - unsigned int channel = client->channel;
>   int r;
>  
> - if (channel > 3)
> - return -EINVAL;
> -
>   if (dsi->dsidev) {
>   DSSERR("dsi client already attached\n");
>   return -EBUSY;
> @@ -5123,10 +5116,6 @@ static int omap_dsi_host_detach(struct mipi_dsi_host 
> *host,
>   struct mipi_dsi_device *client)
>  {
>   struct dsi_data *dsi = host_to_omap(host);
> - unsigned int channel = client->channel;
> -
> - if (channel > 3)
> - return -EINVAL;
>  
>   if (WARN_ON(dsi->dsidev != client))
>   return -EINVAL;
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 09/29] drm/omap: dsi: cleanup dispc channel usage

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:35PM +0200, Tomi Valkeinen wrote:
> The "channel" usage in omap dsi driver is confusing. As the first step,
> change "channel" to "dispc_channel" when dealing with the dispc channel.
> 
> Signed-off-by: Tomi Valkeinen 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index c78ae99c8742..cf0dc4872d14 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -3978,10 +3978,10 @@ static int dsi_configure_dispc_clocks(struct dsi_data 
> *dsi)
>  
>  static int dsi_display_init_dispc(struct dsi_data *dsi)
>  {
> - enum omap_channel channel = dsi->output.dispc_channel;
> + enum omap_channel dispc_channel = dsi->output.dispc_channel;
>   int r;
>  
> - dss_select_lcd_clk_source(dsi->dss, channel, dsi->module_id == 0 ?
> + dss_select_lcd_clk_source(dsi->dss, dispc_channel, dsi->module_id == 0 ?
>   DSS_CLK_SRC_PLL1_1 :
>   DSS_CLK_SRC_PLL2_1);
>  
> @@ -4017,19 +4017,19 @@ static int dsi_display_init_dispc(struct dsi_data 
> *dsi)
>   dss_mgr_unregister_framedone_handler(&dsi->output,
>   dsi_framedone_irq_callback, dsi);
>  err:
> - dss_select_lcd_clk_source(dsi->dss, channel, DSS_CLK_SRC_FCK);
> + dss_select_lcd_clk_source(dsi->dss, dispc_channel, DSS_CLK_SRC_FCK);
>   return r;
>  }
>  
>  static void dsi_display_uninit_dispc(struct dsi_data *dsi)
>  {
> - enum omap_channel channel = dsi->output.dispc_channel;
> + enum omap_channel dispc_channel = dsi->output.dispc_channel;
>  
>   if (dsi->mode == OMAP_DSS_DSI_CMD_MODE)
>   dss_mgr_unregister_framedone_handler(&dsi->output,
>   dsi_framedone_irq_callback, dsi);
>  
> - dss_select_lcd_clk_source(dsi->dss, channel, DSS_CLK_SRC_FCK);
> + dss_select_lcd_clk_source(dsi->dss, dispc_channel, DSS_CLK_SRC_FCK);
>  }
>  
>  static int dsi_configure_dsi_clocks(struct dsi_data *dsi)
> @@ -4846,12 +4846,12 @@ static int dsi_set_config(struct omap_dss_device 
> *dssdev,
>  }
>  
>  /*
> - * Return a hardcoded channel for the DSI output. This should work for
> + * Return a hardcoded dispc channel for the DSI output. This should work for
>   * current use cases, but this can be later expanded to either resolve
>   * the channel in some more dynamic manner, or get the channel as a user
>   * parameter.
>   */
> -static enum omap_channel dsi_get_channel(struct dsi_data *dsi)
> +static enum omap_channel dsi_get_dispc_channel(struct dsi_data *dsi)
>  {
>   switch (dsi->data->model) {
>   case DSI_MODEL_OMAP3:
> @@ -5403,7 +5403,7 @@ static int dsi_init_output(struct dsi_data *dsi)
>  
>   out->type = OMAP_DISPLAY_TYPE_DSI;
>   out->name = dsi->module_id == 0 ? "dsi.0" : "dsi.1";
> - out->dispc_channel = dsi_get_channel(dsi);
> + out->dispc_channel = dsi_get_dispc_channel(dsi);
>   out->dsi_ops = &dsi_ops;
>   out->of_port = 0;
>   out->bus_flags = DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 10/29] drm/omap: dsi: rename 'channel' to 'vc'

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:36PM +0200, Tomi Valkeinen wrote:
> The "channel" usage in omap dsi driver is confusing. We have three
> different "channels":
> 
> 1) DSI virtual channel ID. This is a number from 0 to 3, included in the
> packet payload.
> 
> 2) VC. This is a register block in the DSI IP. There are four of those
> blocks. A VC is a DSI "pipeline", with defined fifo settings, data
> source (cpu or dispc), and some other settings. It has no relation to
> the 1).
> 
> 3) dispc channel. It's the "pipeline" number dispc uses to send pixel
> data.
> 
> The previous patch handled the third case.
> 
>  To start fixing 1) and 2), we first rename all uses of 'channel' to
> 'vc', as in most of the cases that is the correct thing to use.
> 
> However, in some places 1) and 2) have gotten mixed up (i.e. the code
> uses msg->channel when it should use vc), which will be fixed in the
> following patch.
> 
> Note that mixing 1) and 2) currently is "fine", as at the moment we only
> support DSI peripherals with DSI virtual channel 0, and we always use
> VC0 to send data. So both 1) and 2) are always 0.
> 
> Signed-off-by: Tomi Valkeinen 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 220 +++---
>  1 file changed, 110 insertions(+), 110 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index cf0dc4872d14..273159e8f992 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -214,7 +214,7 @@ static void dsi_set_ulps_auto(struct dsi_data *dsi, bool 
> enable);
>  static int dsi_display_init_dispc(struct dsi_data *dsi);
>  static void dsi_display_uninit_dispc(struct dsi_data *dsi);
>  
> -static int dsi_vc_send_null(struct dsi_data *dsi, int channel);
> +static int dsi_vc_send_null(struct dsi_data *dsi, int vc);
>  
>  static ssize_t _omap_dsi_host_transfer(struct dsi_data *dsi,
>  const struct mipi_dsi_msg *msg);
> @@ -376,7 +376,7 @@ struct dsi_data {
>   /* space for a copy used by the interrupt handler */
>   struct dsi_isr_tables isr_tables_copy;
>  
> - int update_channel;
> + int update_vc;
>  #ifdef DSI_PERF_MEASURE
>   unsigned int update_bytes;
>  #endif
> @@ -639,7 +639,7 @@ static void print_irq_status(u32 status)
>  #undef PIS
>  }
>  
> -static void print_irq_status_vc(int channel, u32 status)
> +static void print_irq_status_vc(int vc, u32 status)
>  {
>   if (status == 0)
>   return;
> @@ -650,7 +650,7 @@ static void print_irq_status_vc(int channel, u32 status)
>  #define PIS(x) (status & DSI_VC_IRQ_##x) ? (#x " ") : ""
>  
>   pr_debug("DSI VC(%d) IRQ 0x%x: %s%s%s%s%s%s%s%s%s\n",
> - channel,
> + vc,
>   status,
>   PIS(CS),
>   PIS(ECC_CORR),
> @@ -1031,7 +1031,7 @@ static int dsi_unregister_isr(struct dsi_data *dsi, 
> omap_dsi_isr_t isr,
>   return r;
>  }
>  
> -static int dsi_register_isr_vc(struct dsi_data *dsi, int channel,
> +static int dsi_register_isr_vc(struct dsi_data *dsi, int vc,
>  omap_dsi_isr_t isr, void *arg, u32 mask)
>  {
>   unsigned long flags;
> @@ -1040,18 +1040,18 @@ static int dsi_register_isr_vc(struct dsi_data *dsi, 
> int channel,
>   spin_lock_irqsave(&dsi->irq_lock, flags);
>  
>   r = _dsi_register_isr(isr, arg, mask,
> - dsi->isr_tables.isr_table_vc[channel],
> - ARRAY_SIZE(dsi->isr_tables.isr_table_vc[channel]));
> + dsi->isr_tables.isr_table_vc[vc],
> + ARRAY_SIZE(dsi->isr_tables.isr_table_vc[vc]));
>  
>   if (r == 0)
> - _omap_dsi_set_irqs_vc(dsi, channel);
> + _omap_dsi_set_irqs_vc(dsi, vc);
>  
>   spin_unlock_irqrestore(&dsi->irq_lock, flags);
>  
>   return r;
>  }
>  
> -static int dsi_unregister_isr_vc(struct dsi_data *dsi, int channel,
> +static int dsi_unregister_isr_vc(struct dsi_data *dsi, int vc,
>omap_dsi_isr_t isr, void *arg, u32 mask)
>  {
>   unsigned long flags;
> @@ -1060,11 +1060,11 @@ static int dsi_unregister_isr_vc(struct dsi_data 
> *dsi, int channel,
>   spin_lock_irqsave(&dsi->irq_lock, flags);
>  
>   r = _dsi_unregister_isr(isr, arg, mask,
> - dsi->isr_tables.isr_table_vc[channel],
> - ARRAY_SIZE(dsi->is

Re: [PATCH v5 11/29] drm/omap: dsi: pass vc to various functions

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:37PM +0200, Tomi Valkeinen wrote:
> To start fixing the issues related to channels and vcs described in the
> previous commit, pass vc to various functions which will need it do
> properly handle different DSI channels and VCs.
> 
> No functional changes.
> 
> Signed-off-by: Tomi Valkeinen 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 54 ---
>  1 file changed, 28 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 273159e8f992..8d8412199693 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -214,9 +214,9 @@ static void dsi_set_ulps_auto(struct dsi_data *dsi, bool 
> enable);
>  static int dsi_display_init_dispc(struct dsi_data *dsi);
>  static void dsi_display_uninit_dispc(struct dsi_data *dsi);
>  
> -static int dsi_vc_send_null(struct dsi_data *dsi, int vc);
> +static int dsi_vc_send_null(struct dsi_data *dsi, int vc, int channel);
>  
> -static ssize_t _omap_dsi_host_transfer(struct dsi_data *dsi,
> +static ssize_t _omap_dsi_host_transfer(struct dsi_data *dsi, int vc,
>  const struct mipi_dsi_msg *msg);
>  
>  static void dsi_display_disable(struct omap_dss_device *dssdev);
> @@ -2455,7 +2455,7 @@ static void dsi_vc_enable_hs(struct omap_dss_device 
> *dssdev, int vc,
>  
>   /* start the DDR clock by sending a NULL packet */
>   if (dsi->vm_timings.ddr_clk_always_on && enable)
> - dsi_vc_send_null(dsi, vc);
> + dsi_vc_send_null(dsi, vc, dsi->dsidev->channel);
>  
>   dsi->in_lp_mode = !enable;
>  }
> @@ -2605,7 +2605,8 @@ static int dsi_vc_send_bta_sync(struct omap_dss_device 
> *dssdev, int vc)
>  }
>  
>  static inline void dsi_vc_write_long_header(struct dsi_data *dsi, int vc,
> - u8 data_type, u16 len, u8 ecc)
> + int channel, u8 data_type, u16 len,
> + u8 ecc)
>  {
>   u32 val;
>   u8 data_id;
> @@ -2633,7 +2634,7 @@ static inline void dsi_vc_write_long_payload(struct 
> dsi_data *dsi, int vc,
>   dsi_write_reg(dsi, DSI_VC_LONG_PACKET_PAYLOAD(vc), val);
>  }
>  
> -static int dsi_vc_send_long(struct dsi_data *dsi,
> +static int dsi_vc_send_long(struct dsi_data *dsi, int vc,
>   const struct mipi_dsi_msg *msg)
>  {
>   /*u32 val; */
> @@ -2653,7 +2654,7 @@ static int dsi_vc_send_long(struct dsi_data *dsi,
>  
>   dsi_vc_config_source(dsi, msg->channel, DSI_VC_SOURCE_L4);
>  
> - dsi_vc_write_long_header(dsi, msg->channel, msg->type, msg->tx_len, 0);
> + dsi_vc_write_long_header(dsi, vc, msg->channel, msg->type, msg->tx_len, 
> 0);
>  
>   p = msg->tx_buf;
>   for (i = 0; i < msg->tx_len >> 2; i++) {
> @@ -2696,7 +2697,7 @@ static int dsi_vc_send_long(struct dsi_data *dsi,
>   return r;
>  }
>  
> -static int dsi_vc_send_short(struct dsi_data *dsi,
> +static int dsi_vc_send_short(struct dsi_data *dsi, int vc,
>const struct mipi_dsi_msg *msg)
>  {
>   struct mipi_dsi_packet pkt;
> @@ -2727,26 +2728,26 @@ static int dsi_vc_send_short(struct dsi_data *dsi,
>   return 0;
>  }
>  
> -static int dsi_vc_send_null(struct dsi_data *dsi, int vc)
> +static int dsi_vc_send_null(struct dsi_data *dsi, int vc, int channel)
>  {
>   const struct mipi_dsi_msg msg = {
>   .channel = vc,
>   .type = MIPI_DSI_NULL_PACKET,
>   };
>  
> - return dsi_vc_send_long(dsi, &msg);
> + return dsi_vc_send_long(dsi, vc, &msg);
>  }
>  
> -static int dsi_vc_write_common(struct omap_dss_device *dssdev,
> +static int dsi_vc_write_common(struct omap_dss_device *dssdev, int vc,
>  const struct mipi_dsi_msg *msg)
>  {
>   struct dsi_data *dsi = to_dsi_data(dssdev);
>   int r;
>  
>   if (mipi_dsi_packet_format_is_short(msg->type))
> - r = dsi_vc_send_short(dsi, msg);
> + r = dsi_vc_send_short(dsi, vc, msg);
>   else
> - r = dsi_vc_send_long(dsi, msg);
> + r = dsi_vc_send_long(dsi, vc, msg);
>  
>   if (r < 0)
>   return r;
> @@ -2882,7 +2883,7 @@ static int dsi_vc_read_rx_fifo(struct dsi_data *dsi, 
> int vc, u8 *buf,
>   return r;
>  }
>  
> -static int dsi_vc_dcs_read(struct omap_dss_device *dssdev,
> +static int dsi_vc_dcs_read(struct omap_dss_devic

Re: [PATCH v5 12/29] drm/omap: dsi: untangle vc & channel

[Sebastian Reichel]

On Tue, Dec 08, 2020 at 05:41:23PM +0200, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Tue, Dec 08, 2020 at 02:28:38PM +0200, Tomi Valkeinen wrote:
> > DSI virtual channel and hardware VC blocks have gotten tangled as
> > described in the previous commits. This has not caused any issues, as
> > the value for both is 0, so it happens to work.
> > 
> > To fix the issue, change the code to use the correct one of the two.
> > 
> > Signed-off-by: Tomi Valkeinen 
> > ---
> >  drivers/gpu/drm/omapdrm/dss/dsi.c | 43 +++
> >  1 file changed, 21 insertions(+), 22 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> > b/drivers/gpu/drm/omapdrm/dss/dsi.c
> > index 8d8412199693..a1f3623f45b1 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> > +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> > @@ -2613,7 +2613,7 @@ static inline void dsi_vc_write_long_header(struct 
> > dsi_data *dsi, int vc,
> >  
> > WARN_ON(!dsi_bus_is_locked(dsi));
> >  
> > -   data_id = data_type | vc << 6;
> > +   data_id = data_type | channel << 6;
> >  
> > val = FLD_VAL(data_id, 7, 0) | FLD_VAL(len, 23, 8) |
> > FLD_VAL(ecc, 31, 24);
> > @@ -2647,12 +2647,12 @@ static int dsi_vc_send_long(struct dsi_data *dsi, 
> > int vc,
> > DSSDBG("dsi_vc_send_long, %d bytes\n", msg->tx_len);
> >  
> > /* len + header */
> > -   if (dsi->vc[msg->channel].tx_fifo_size * 32 * 4 < msg->tx_len + 4) {
> > +   if (dsi->vc[vc].tx_fifo_size * 32 * 4 < msg->tx_len + 4) {
> > DSSERR("unable to send long packet: packet too long.\n");
> > return -EINVAL;
> > }
> >  
> > -   dsi_vc_config_source(dsi, msg->channel, DSI_VC_SOURCE_L4);
> > +   dsi_vc_config_source(dsi, vc, DSI_VC_SOURCE_L4);
> >  
> > dsi_vc_write_long_header(dsi, vc, msg->channel, msg->type, msg->tx_len, 
> > 0);
> >  
> > @@ -2666,7 +2666,7 @@ static int dsi_vc_send_long(struct dsi_data *dsi, int 
> > vc,
> > b3 = *p++;
> > b4 = *p++;
> >  
> > -   dsi_vc_write_long_payload(dsi, msg->channel, b1, b2, b3, b4);
> > +   dsi_vc_write_long_payload(dsi, vc, b1, b2, b3, b4);
> > }
> >  
> > i = msg->tx_len % 4;
> > @@ -2691,7 +2691,7 @@ static int dsi_vc_send_long(struct dsi_data *dsi, int 
> > vc,
> > break;
> > }
> >  
> > -   dsi_vc_write_long_payload(dsi, msg->channel, b1, b2, b3, 0);
> > +   dsi_vc_write_long_payload(dsi, vc, b1, b2, b3, 0);
> > }
> >  
> > return r;
> > @@ -2711,11 +2711,11 @@ static int dsi_vc_send_short(struct dsi_data *dsi, 
> > int vc,
> >  
> > if (dsi->debug_write)
> > DSSDBG("dsi_vc_send_short(ch%d, dt %#x, b1 %#x, b2 %#x)\n",
> > -  msg->channel, msg->type, pkt.header[1], pkt.header[2]);
> > +  vc, msg->type, pkt.header[1], pkt.header[2]);

There is another "ch%d" filled with vc. With this and Laurent
findings fixed:

Reviewed-by: Sebastian Reichel 

-- Sebastian

> >  
> > -   dsi_vc_config_source(dsi, msg->channel, DSI_VC_SOURCE_L4);
> > +   dsi_vc_config_source(dsi, vc, DSI_VC_SOURCE_L4);
> >  
> > -   if (FLD_GET(dsi_read_reg(dsi, DSI_VC_CTRL(msg->channel)), 16, 16)) {
> > +   if (FLD_GET(dsi_read_reg(dsi, DSI_VC_CTRL(vc)), 16, 16)) {
> > DSSERR("ERROR FIFO FULL, aborting transfer\n");
> > return -EINVAL;
> > }
> > @@ -2723,7 +2723,7 @@ static int dsi_vc_send_short(struct dsi_data *dsi, 
> > int vc,
> > r = pkt.header[3] << 24 | pkt.header[2] << 16 | pkt.header[1] << 8 |
> > pkt.header[0];
> >  
> > -   dsi_write_reg(dsi, DSI_VC_SHORT_PACKET_HEADER(msg->channel), r);
> > +   dsi_write_reg(dsi, DSI_VC_SHORT_PACKET_HEADER(vc), r);
> >  
> > return 0;
> >  }
> > @@ -2731,7 +2731,7 @@ static int dsi_vc_send_short(struct dsi_data *dsi, 
> > int vc,
> >  static int dsi_vc_send_null(struct dsi_data *dsi, int vc, int channel)
> >  {
> > const struct mipi_dsi_msg msg = {
> > -   .channel = vc,
> > +   .channel = channel,
> > .type = MIPI_DSI_NULL_PACKET,
> > };
> >  
> > @@ -2759,16 +2759,16 @@ static int dsi_vc_write_common(struct 
> > omap_dss_devic

Re: [PATCH v5 13/29] drm/omap: dsi: skip dsi_vc_enable_hs when already in correct mode

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:39PM +0200, Tomi Valkeinen wrote:
> Simplify and optimize dsi_vc_enable_hs() so that it can be called
> without checking the current HS/LP mode. Make dsi_vc_enable_hs() return
> if the VC is already in the correct mode.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index a1f3623f45b1..544f5f1eed91 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -341,7 +341,6 @@ struct dsi_data {
>   int irq;
>  
>   bool is_enabled;
> - bool in_lp_mode;
>  
>   struct clk *dss_clk;
>   struct regmap *syscon;
> @@ -2441,6 +2440,9 @@ static void dsi_vc_enable_hs(struct omap_dss_device 
> *dssdev, int vc,
>  
>   DSSDBG("dsi_vc_enable_hs(%d, %d)\n", vc, enable);
>  
> + if (REG_GET(dsi, DSI_VC_CTRL(vc), 9, 9) == enable)
> + return;
> +
>   WARN_ON(!dsi_bus_is_locked(dsi));
>  
>   dsi_vc_enable(dsi, vc, 0);
> @@ -2456,8 +2458,6 @@ static void dsi_vc_enable_hs(struct omap_dss_device 
> *dssdev, int vc,
>   /* start the DDR clock by sending a NULL packet */
>   if (dsi->vm_timings.ddr_clk_always_on && enable)
>   dsi_vc_send_null(dsi, vc, dsi->dsidev->channel);
> -
> - dsi->in_lp_mode = !enable;
>  }
>  
>  static void dsi_vc_flush_long_data(struct dsi_data *dsi, int vc)
> @@ -4891,9 +4891,7 @@ static ssize_t _omap_dsi_host_transfer(struct dsi_data 
> *dsi, int vc,
>   struct omap_dss_device *dssdev = &dsi->output;
>   int r;
>  
> - if (!!(msg->flags & MIPI_DSI_MSG_USE_LPM) != dsi->in_lp_mode)
> - dsi_vc_enable_hs(dssdev, vc,
> -  !(msg->flags & MIPI_DSI_MSG_USE_LPM));
> + dsi_vc_enable_hs(dssdev, vc, !(msg->flags & MIPI_DSI_MSG_USE_LPM));
>  
>   switch (msg->type) {
>   case MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM:
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 14/29] drm/omap: dsi: enable HS before sending the frame

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:40PM +0200, Tomi Valkeinen wrote:
> We currently use a single VC for sending commands and pixel data. The
> LP/HS mode for pixel data is correctly set to HS by accident, as we have
> set the VC to HS already earlier.
> 
> However, if we use a different VC for video data, the VC is in LP mode.
> Fix this by always enabling HS mode before starting a frame update.
> 
> Signed-off-by: Tomi Valkeinen 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 544f5f1eed91..9d210a020916 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -3918,6 +3918,8 @@ static int dsi_update_channel(struct omap_dss_device 
> *dssdev, int vc)
>  
>   dsi_set_ulps_auto(dsi, false);
>  
> + dsi_vc_enable_hs(dssdev, vc, true);
> +
>   /*
>* Send NOP between the frames. If we don't send something here, the
>* updates stop working. This is probably related to DSI spec stating
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 15/29] drm/omap: dsi: use separate VCs for cmd and video

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:41PM +0200, Tomi Valkeinen wrote:
> For command mode panels we can use a single VC for sending command and
> video data, even if we have to change the data source for that VC when
> going from command to video or vice versa.
> 
> However, with video mode panels we want to keep the pixel data VC
> enabled, and use another VC for command data, and the commands will get
> interleaved into the pixel data.
> 
> This patch makes the driver use VC0 for commands and VC1 for video.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 9d210a020916..0795efdd8902 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -452,7 +452,9 @@ static bool dsi_perf;
>  module_param(dsi_perf, bool, 0644);
>  #endif
>  
> -#define VC_DEFAULT 0
> +/* Note: for some reason video mode seems to work only if VC_VIDEO is 0 */
> +#define VC_VIDEO 0
> +#define VC_CMD   1
>  
>  #define drm_bridge_to_dsi(bridge) \
>   container_of(bridge, struct dsi_data, bridge)
> @@ -3723,7 +3725,7 @@ static void dsi_disable_video_outputs(struct 
> omap_dss_device *dssdev)
>   dsi_bus_lock(dsi);
>   dsi->video_enabled = false;
>  
> - dsi_disable_video_output(dssdev, VC_DEFAULT);
> + dsi_disable_video_output(dssdev, VC_VIDEO);
>  
>   dsi_display_disable(dssdev);
>  
> @@ -3951,7 +3953,7 @@ static int dsi_update_channel(struct omap_dss_device 
> *dssdev, int vc)
>  
>  static int dsi_update_all(struct omap_dss_device *dssdev)
>  {
> - return dsi_update_channel(dssdev, VC_DEFAULT);
> + return dsi_update_channel(dssdev, VC_VIDEO);
>  }
>  
>  /* Display funcs */
> @@ -4184,7 +4186,7 @@ static void dsi_enable_video_outputs(struct 
> omap_dss_device *dssdev)
>  
>   dsi_display_enable(dssdev);
>  
> - dsi_enable_video_output(dssdev, VC_DEFAULT);
> + dsi_enable_video_output(dssdev, VC_VIDEO);
>  
>   dsi->video_enabled = true;
>  
> @@ -4941,7 +4943,7 @@ static ssize_t omap_dsi_host_transfer(struct 
> mipi_dsi_host *host,
>  {
>   struct dsi_data *dsi = host_to_omap(host);
>   int r;
> - int vc = VC_DEFAULT;
> + int vc = VC_CMD;
>  
>   dsi_bus_lock(dsi);
>  
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 16/29] drm/panel: panel-dsi-cm: remove extra 'if'

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:42PM +0200, Tomi Valkeinen wrote:
> We have a useless 'if' in the dsicm_bl_update_status(), a left over from
> the conversion to DRM model. Drop the if.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Sam Ravnborg 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/panel/panel-dsi-cm.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c 
> b/drivers/gpu/drm/panel/panel-dsi-cm.c
> index 556f9a2c5c0c..fa564aad7f25 100644
> --- a/drivers/gpu/drm/panel/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
> @@ -202,11 +202,9 @@ static int dsicm_bl_update_status(struct 
> backlight_device *dev)
>  
>   mutex_lock(&ddata->lock);
>  
> - if (ddata->enabled) {
> - if (!r)
> - r = dsicm_dcs_write_1(
> - ddata, MIPI_DCS_SET_DISPLAY_BRIGHTNESS, level);
> - }
> + if (ddata->enabled)
> + r = dsicm_dcs_write_1(ddata, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
> +   level);
>  
>   mutex_unlock(&ddata->lock);
>  
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 17/29] drm/panel: panel-dsi-cm: add panel database to driver

[Sebastian Reichel]

ies[0].supply = "vpnl";
>   ddata->supplies[1].supply = "vddi";
> @@ -531,6 +523,7 @@ static int dsicm_probe(struct mipi_dsi_device *dsi)
>   struct panel_drv_data *ddata;
>   struct backlight_device *bldev = NULL;
>   struct device *dev = &dsi->dev;
> + const struct of_device_id *id;
>   int r;
>  
>   dev_dbg(dev, "probe\n");
> @@ -542,6 +535,12 @@ static int dsicm_probe(struct mipi_dsi_device *dsi)
>   mipi_dsi_set_drvdata(dsi, ddata);
>   ddata->dsi = dsi;
>  
> + id = of_match_node(dsicm_of_match, dev->of_node);
> + if (!id)
> + return -ENODEV;
> +
> + ddata->panel_data = id->data;

ddata->panel_data = of_device_get_match_data(dev);
if (!ddata->panel_data)
return -ENODEV;

Otherwise looks good to me:

Reviewed-by: Sebastian Reichel 

-- Sebastian

>   r = dsicm_probe_of(dsi);
>   if (r)
>   return r;
> @@ -578,8 +577,8 @@ static int dsicm_probe(struct mipi_dsi_device *dsi)
>   dsi->format = MIPI_DSI_FMT_RGB888;
>   dsi->mode_flags = MIPI_DSI_CLOCK_NON_CONTINUOUS |
> MIPI_DSI_MODE_EOT_PACKET;
> - dsi->hs_rate = 3;
> - dsi->lp_rate = 1000;
> + dsi->hs_rate = ddata->panel_data->max_hs_rate;
> + dsi->lp_rate = ddata->panel_data->max_lp_rate;
>  
>   drm_panel_add(&ddata->panel);
>  
> @@ -617,8 +616,40 @@ static int dsicm_remove(struct mipi_dsi_device *dsi)
>   return 0;
>  }
>  
> +static const struct dsic_panel_data taal_data = {
> + .xres = 864,
> + .yres = 480,
> + .refresh = 60,
> + .width_mm = 0,
> + .height_mm = 0,
> + .max_hs_rate = 3,
> + .max_lp_rate = 1000,
> +};
> +
> +static const struct dsic_panel_data himalaya_data = {
> + .xres = 480,
> + .yres = 864,
> + .refresh = 60,
> + .width_mm = 49,
> + .height_mm = 88,
> + .max_hs_rate = 3,
> + .max_lp_rate = 1000,
> +};
> +
> +static const struct dsic_panel_data droid4_data = {
> + .xres = 540,
> + .yres = 960,
> + .refresh = 60,
> + .width_mm = 50,
> + .height_mm = 89,
> + .max_hs_rate = 3,
> + .max_lp_rate = 1000,
> +};
> +
>  static const struct of_device_id dsicm_of_match[] = {
> - { .compatible = "panel-dsi-cm", },
> + { .compatible = "tpo,taal", .data = &taal_data },
> + { .compatible = "nokia,himalaya", &himalaya_data },
> + { .compatible = "motorola,droid4-panel", &droid4_data },
>   {},
>  };
>  
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 18/29] drm/panel: panel-dsi-cm: drop unneeded includes

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:44PM +0200, Tomi Valkeinen wrote:
> Drop unneeded includes.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Sam Ravnborg 
> Reviewed-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/panel/panel-dsi-cm.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c 
> b/drivers/gpu/drm/panel/panel-dsi-cm.c
> index 3fb5b2856283..3fe73c4bef6e 100644
> --- a/drivers/gpu/drm/panel/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
> @@ -11,9 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> -#include 

Note, that 'of_device_get_match_data', which I suggested in
previous patch is defined in . Otherwise

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  #include 
>  
>  #include 
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 19/29] drm/omap: dsi: move structs & defines to dsi.h

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:45PM +0200, Tomi Valkeinen wrote:
> Move structs and defines to a private dsi.h header file to make dsi.c a
> bit easier to navigate. Also move the (now) private structs and defines
> from omapdss.h to dsi.h.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 384 +
>  drivers/gpu/drm/omapdrm/dss/dsi.h | 459 ++
>  drivers/gpu/drm/omapdrm/dss/omapdss.h |  64 
>  3 files changed, 460 insertions(+), 447 deletions(-)
>  create mode 100644 drivers/gpu/drm/omapdrm/dss/dsi.h
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 0795efdd8902..da3ff9e236bd 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -45,73 +45,7 @@
>  
>  #define DSI_CATCH_MISSING_TE
>  
> -struct dsi_reg { u16 module; u16 idx; };
> -
> -#define DSI_REG(mod, idx)((const struct dsi_reg) { mod, idx })
> -
> -/* DSI Protocol Engine */
> -
> -#define DSI_PROTO0
> -#define DSI_PROTO_SZ 0x200
> -
> -#define DSI_REVISION DSI_REG(DSI_PROTO, 0x)
> -#define DSI_SYSCONFIGDSI_REG(DSI_PROTO, 0x0010)
> -#define DSI_SYSSTATUSDSI_REG(DSI_PROTO, 0x0014)
> -#define DSI_IRQSTATUSDSI_REG(DSI_PROTO, 0x0018)
> -#define DSI_IRQENABLEDSI_REG(DSI_PROTO, 0x001C)
> -#define DSI_CTRL DSI_REG(DSI_PROTO, 0x0040)
> -#define DSI_GNQ  DSI_REG(DSI_PROTO, 0x0044)
> -#define DSI_COMPLEXIO_CFG1   DSI_REG(DSI_PROTO, 0x0048)
> -#define DSI_COMPLEXIO_IRQ_STATUS DSI_REG(DSI_PROTO, 0x004C)
> -#define DSI_COMPLEXIO_IRQ_ENABLE DSI_REG(DSI_PROTO, 0x0050)
> -#define DSI_CLK_CTRL DSI_REG(DSI_PROTO, 0x0054)
> -#define DSI_TIMING1  DSI_REG(DSI_PROTO, 0x0058)
> -#define DSI_TIMING2  DSI_REG(DSI_PROTO, 0x005C)
> -#define DSI_VM_TIMING1   DSI_REG(DSI_PROTO, 0x0060)
> -#define DSI_VM_TIMING2   DSI_REG(DSI_PROTO, 0x0064)
> -#define DSI_VM_TIMING3   DSI_REG(DSI_PROTO, 0x0068)
> -#define DSI_CLK_TIMING   DSI_REG(DSI_PROTO, 0x006C)
> -#define DSI_TX_FIFO_VC_SIZE  DSI_REG(DSI_PROTO, 0x0070)
> -#define DSI_RX_FIFO_VC_SIZE  DSI_REG(DSI_PROTO, 0x0074)
> -#define DSI_COMPLEXIO_CFG2   DSI_REG(DSI_PROTO, 0x0078)
> -#define DSI_RX_FIFO_VC_FULLNESS  DSI_REG(DSI_PROTO, 0x007C)
> -#define DSI_VM_TIMING4   DSI_REG(DSI_PROTO, 0x0080)
> -#define DSI_TX_FIFO_VC_EMPTINESS DSI_REG(DSI_PROTO, 0x0084)
> -#define DSI_VM_TIMING5   DSI_REG(DSI_PROTO, 0x0088)
> -#define DSI_VM_TIMING6   DSI_REG(DSI_PROTO, 0x008C)
> -#define DSI_VM_TIMING7   DSI_REG(DSI_PROTO, 0x0090)
> -#define DSI_STOPCLK_TIMING   DSI_REG(DSI_PROTO, 0x0094)
> -#define DSI_VC_CTRL(n)   DSI_REG(DSI_PROTO, 0x0100 + (n 
> * 0x20))
> -#define DSI_VC_TE(n) DSI_REG(DSI_PROTO, 0x0104 + (n * 0x20))
> -#define DSI_VC_LONG_PACKET_HEADER(n) DSI_REG(DSI_PROTO, 0x0108 + (n * 0x20))
> -#define DSI_VC_LONG_PACKET_PAYLOAD(n)DSI_REG(DSI_PROTO, 0x010C + (n 
> * 0x20))
> -#define DSI_VC_SHORT_PACKET_HEADER(n)DSI_REG(DSI_PROTO, 0x0110 + (n 
> * 0x20))
> -#define DSI_VC_IRQSTATUS(n)  DSI_REG(DSI_PROTO, 0x0118 + (n * 0x20))
> -#define DSI_VC_IRQENABLE(n)  DSI_REG(DSI_PROTO, 0x011C + (n * 0x20))
> -
> -/* DSIPHY_SCP */
> -
> -#define DSI_PHY  1
> -#define DSI_PHY_OFFSET   0x200
> -#define DSI_PHY_SZ   0x40
> -
> -#define DSI_DSIPHY_CFG0  DSI_REG(DSI_PHY, 0x)
> -#define DSI_DSIPHY_CFG1  DSI_REG(DSI_PHY, 0x0004)
> -#define DSI_DSIPHY_CFG2  DSI_REG(DSI_PHY, 0x0008)
> -#define DSI_DSIPHY_CFG5  DSI_REG(DSI_PHY, 0x0014)
> -#define DSI_DSIPHY_CFG10 DSI_REG(DSI_PHY, 0x0028)
> -
> -/* DSI_PLL_CTRL_SCP */
> -
> -#define DSI_PLL  2
> -#define DSI_PLL_OFFSET   0x300
> -#define DSI_PLL_SZ   0x20
> -
> -#define DSI_PLL_CONTROL  DSI_REG(DSI_PLL, 0x)
> -#define DSI_PLL_STATUS   DSI_REG(DSI_PLL, 0x0004)
> -#define DSI_PLL_GO   DSI_REG(DSI_PLL, 0x0008)
> -#define DSI_PLL_CONFIGURATION1   DSI_REG(DSI_PLL, 

Re: [PATCH v5 20/29] drm/omap: dsi: move enable/disable to bridge enable/disable

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:46PM +0200, Tomi Valkeinen wrote:
> Clean up the code by inlining dsi_enable_video_outputs and
> dsi_disable_video_outputs functions.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 55 +--
>  1 file changed, 22 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index da3ff9e236bd..44b8e42b52ec 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -3336,20 +3336,6 @@ static void dsi_disable_video_output(struct 
> omap_dss_device *dssdev, int vc)
>   dsi_display_uninit_dispc(dsi);
>  }
>  
> -static void dsi_disable_video_outputs(struct omap_dss_device *dssdev)
> -{
> - struct dsi_data *dsi = to_dsi_data(dssdev);
> -
> - dsi_bus_lock(dsi);
> - dsi->video_enabled = false;
> -
> - dsi_disable_video_output(dssdev, VC_VIDEO);
> -
> - dsi_display_disable(dssdev);
> -
> - dsi_bus_unlock(dsi);
> -}
> -
>  static void dsi_update_screen_dispc(struct dsi_data *dsi)
>  {
>   unsigned int bytespp;
> @@ -3796,23 +3782,6 @@ static void dsi_display_enable(struct omap_dss_device 
> *dssdev)
>   _dsi_display_enable(dsi);
>  }
>  
> -static void dsi_enable_video_outputs(struct omap_dss_device *dssdev)
> -{
> - struct dsi_data *dsi = to_dsi_data(dssdev);
> -
> - dsi_bus_lock(dsi);
> -
> - dsi_display_enable(dssdev);
> -
> - dsi_enable_video_output(dssdev, VC_VIDEO);
> -
> - dsi->video_enabled = true;
> -
> - dsi_set_ulps_auto(dsi, true);
> -
> - dsi_bus_unlock(dsi);
> -}
> -
>  static void _dsi_display_disable(struct dsi_data *dsi,
>   bool disconnect_lanes, bool enter_ulps)
>  {
> @@ -4974,15 +4943,35 @@ static void dsi_bridge_mode_set(struct drm_bridge 
> *bridge,
>  static void dsi_bridge_enable(struct drm_bridge *bridge)
>  {
>   struct dsi_data *dsi = drm_bridge_to_dsi(bridge);
> + struct omap_dss_device *dssdev = &dsi->output;
>  
> - dsi_enable_video_outputs(&dsi->output);
> + dsi_bus_lock(dsi);
> +
> + dsi_display_enable(dssdev);
> +
> + dsi_enable_video_output(dssdev, VC_VIDEO);
> +
> + dsi->video_enabled = true;
> +
> + dsi_set_ulps_auto(dsi, true);
> +
> + dsi_bus_unlock(dsi);
>  }
>  
>  static void dsi_bridge_disable(struct drm_bridge *bridge)
>  {
>   struct dsi_data *dsi = drm_bridge_to_dsi(bridge);
> + struct omap_dss_device *dssdev = &dsi->output;
> +
> + dsi_bus_lock(dsi);
> +
> + dsi->video_enabled = false;
> +
> + dsi_disable_video_output(dssdev, VC_VIDEO);
>  
> - dsi_disable_video_outputs(&dsi->output);
> + dsi_display_disable(dssdev);
> +
> + dsi_bus_unlock(dsi);
>  }
>  
>  static const struct drm_bridge_funcs dsi_bridge_funcs = {
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 21/29] drm/omap: dsi: display_enable cleanup

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:47PM +0200, Tomi Valkeinen wrote:
> We can drop dsi_display_enable(), which just calls
> _dsi_display_enable(), and rename _dsi_display_enable() to
> dsi_display_enable().
> 
> The WARN_ON(!dsi_bus_is_locked(dsi)) in dsi_display_enable is extra and
> can be dropped, as _dsi_display_enable() has the same WARN_ON().
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 16 +++-
>  1 file changed, 3 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 44b8e42b52ec..961b991f6498 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -3743,7 +3743,7 @@ static void dsi_display_uninit_dsi(struct dsi_data 
> *dsi, bool disconnect_lanes,
>   }
>  }
>  
> -static void _dsi_display_enable(struct dsi_data *dsi)
> +static void dsi_display_enable(struct dsi_data *dsi)
>  {
>   int r;
>  
> @@ -3772,16 +3772,6 @@ static void _dsi_display_enable(struct dsi_data *dsi)
>   DSSDBG("dsi_display_ulps_enable FAILED\n");
>  }
>  
> -static void dsi_display_enable(struct omap_dss_device *dssdev)
> -{
> - struct dsi_data *dsi = to_dsi_data(dssdev);
> - DSSDBG("dsi_display_enable\n");
> -
> - WARN_ON(!dsi_bus_is_locked(dsi));
> -
> - _dsi_display_enable(dsi);
> -}
> -
>  static void _dsi_display_disable(struct dsi_data *dsi,
>   bool disconnect_lanes, bool enter_ulps)
>  {
> @@ -3856,7 +3846,7 @@ static void dsi_set_ulps_auto(struct dsi_data *dsi, 
> bool enable)
>   return;
>  
>   dsi_bus_lock(dsi);
> - _dsi_display_enable(dsi);
> + dsi_display_enable(dsi);
>   dsi_enable_te(dsi, true);
>   dsi_bus_unlock(dsi);
>   }
> @@ -4947,7 +4937,7 @@ static void dsi_bridge_enable(struct drm_bridge *bridge)
>  
>   dsi_bus_lock(dsi);
>  
> - dsi_display_enable(dssdev);
> + dsi_display_enable(dsi);
>  
>   dsi_enable_video_output(dssdev, VC_VIDEO);
>  
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 22/29] drm/omap: dsi: display_disable cleanup

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:48PM +0200, Tomi Valkeinen wrote:
> We can drop dsi_display_disable() which just calls
> _dsi_display_disable(), and rename _dsi_display_disable() to
> dsi_display_disable().
> 
> The WARN_ON(!dsi_bus_is_locked(dsi)) in dsi_display_disable is extra and
> can be dropped, as _dsi_display_disable() has the same WARN_ON().
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 19 +++
>  1 file changed, 3 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 961b991f6498..d83346812810 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -63,8 +63,6 @@ static int dsi_vc_send_null(struct dsi_data *dsi, int vc, 
> int channel);
>  static ssize_t _omap_dsi_host_transfer(struct dsi_data *dsi, int vc,
>  const struct mipi_dsi_msg *msg);
>  
> -static void dsi_display_disable(struct omap_dss_device *dssdev);
> -
>  #ifdef DSI_PERF_MEASURE
>  static bool dsi_perf;
>  module_param(dsi_perf, bool, 0644);
> @@ -3772,7 +3770,7 @@ static void dsi_display_enable(struct dsi_data *dsi)
>   DSSDBG("dsi_display_ulps_enable FAILED\n");
>  }
>  
> -static void _dsi_display_disable(struct dsi_data *dsi,
> +static void dsi_display_disable(struct dsi_data *dsi,
>   bool disconnect_lanes, bool enter_ulps)
>  {
>   WARN_ON(!dsi_bus_is_locked(dsi));
> @@ -3791,17 +3789,6 @@ static void _dsi_display_disable(struct dsi_data *dsi,
>   mutex_unlock(&dsi->lock);
>  }
>  
> -static void dsi_display_disable(struct omap_dss_device *dssdev)
> -{
> - struct dsi_data *dsi = to_dsi_data(dssdev);
> -
> - WARN_ON(!dsi_bus_is_locked(dsi));
> -
> - DSSDBG("dsi_display_disable\n");
> -
> - _dsi_display_disable(dsi, true, false);
> -}
> -
>  static int dsi_enable_te(struct dsi_data *dsi, bool enable)
>  {
>   dsi->te_enabled = enable;
> @@ -3825,7 +3812,7 @@ static void omap_dsi_ulps_work_callback(struct 
> work_struct *work)
>  
>   dsi_enable_te(dsi, false);
>  
> - _dsi_display_disable(dsi, false, true);
> + dsi_display_disable(dsi, false, true);
>  
>   dsi_bus_unlock(dsi);
>  }
> @@ -4959,7 +4946,7 @@ static void dsi_bridge_disable(struct drm_bridge 
> *bridge)
>  
>   dsi_disable_video_output(dssdev, VC_VIDEO);
>  
> - dsi_display_disable(dssdev);
> + dsi_display_disable(dsi, true, false);
>  
>   dsi_bus_unlock(dsi);
>  }
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 23/29] drm/omap: dsi: rename dsi_display_* functions

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:49PM +0200, Tomi Valkeinen wrote:
> The function names have evolved to be very confusing, and bunch of them
> have "display" in them even if the function doesn't deal with display as
> such (e.g. dsi_display_enable which just enables the DSI interface).
> Rename them by dropping the "display".
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 36 +++
>  1 file changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index d83346812810..d9c2cd849328 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -55,8 +55,8 @@
>  
>  static void dsi_set_ulps_auto(struct dsi_data *dsi, bool enable);
>  
> -static int dsi_display_init_dispc(struct dsi_data *dsi);
> -static void dsi_display_uninit_dispc(struct dsi_data *dsi);
> +static int dsi_init_dispc(struct dsi_data *dsi);
> +static void dsi_uninit_dispc(struct dsi_data *dsi);
>  
>  static int dsi_vc_send_null(struct dsi_data *dsi, int vc, int channel);
>  
> @@ -3257,7 +3257,7 @@ static void dsi_enable_video_output(struct 
> omap_dss_device *dssdev, int vc)
>   u16 word_count;
>   int r;
>  
> - r = dsi_display_init_dispc(dsi);
> + r = dsi_init_dispc(dsi);
>   if (r) {
>   dev_err(dsi->dev, "failed to init dispc!\n");
>   return;
> @@ -3309,7 +3309,7 @@ static void dsi_enable_video_output(struct 
> omap_dss_device *dssdev, int vc)
>   dsi_vc_enable(dsi, vc, false);
>   }
>  err_pix_fmt:
> - dsi_display_uninit_dispc(dsi);
> + dsi_uninit_dispc(dsi);
>   dev_err(dsi->dev, "failed to enable DSI encoder!\n");
>   return;
>  }
> @@ -3331,7 +3331,7 @@ static void dsi_disable_video_output(struct 
> omap_dss_device *dssdev, int vc)
>  
>   dss_mgr_disable(&dsi->output);
>  
> - dsi_display_uninit_dispc(dsi);
> + dsi_uninit_dispc(dsi);
>  }
>  
>  static void dsi_update_screen_dispc(struct dsi_data *dsi)
> @@ -3582,7 +3582,7 @@ static int dsi_configure_dispc_clocks(struct dsi_data 
> *dsi)
>   return 0;
>  }
>  
> -static int dsi_display_init_dispc(struct dsi_data *dsi)
> +static int dsi_init_dispc(struct dsi_data *dsi)
>  {
>   enum omap_channel dispc_channel = dsi->output.dispc_channel;
>   int r;
> @@ -3627,7 +3627,7 @@ static int dsi_display_init_dispc(struct dsi_data *dsi)
>   return r;
>  }
>  
> -static void dsi_display_uninit_dispc(struct dsi_data *dsi)
> +static void dsi_uninit_dispc(struct dsi_data *dsi)
>  {
>   enum omap_channel dispc_channel = dsi->output.dispc_channel;
>  
> @@ -3654,7 +3654,7 @@ static int dsi_configure_dsi_clocks(struct dsi_data 
> *dsi)
>   return 0;
>  }
>  
> -static int dsi_display_init_dsi(struct dsi_data *dsi)
> +static int dsi_init_dsi(struct dsi_data *dsi)
>  {
>   int r;
>  
> @@ -3718,7 +3718,7 @@ static int dsi_display_init_dsi(struct dsi_data *dsi)
>   return r;
>  }
>  
> -static void dsi_display_uninit_dsi(struct dsi_data *dsi, bool 
> disconnect_lanes,
> +static void dsi_uninit_dsi(struct dsi_data *dsi, bool disconnect_lanes,
>  bool enter_ulps)
>  {
>   if (enter_ulps && !dsi->ulps_enabled)
> @@ -3741,7 +3741,7 @@ static void dsi_display_uninit_dsi(struct dsi_data 
> *dsi, bool disconnect_lanes,
>   }
>  }
>  
> -static void dsi_display_enable(struct dsi_data *dsi)
> +static void dsi_enable(struct dsi_data *dsi)
>  {
>   int r;
>  
> @@ -3755,7 +3755,7 @@ static void dsi_display_enable(struct dsi_data *dsi)
>  
>   _dsi_initialize_irq(dsi);
>  
> - r = dsi_display_init_dsi(dsi);
> + r = dsi_init_dsi(dsi);
>   if (r)
>   goto err_init_dsi;
>  
> @@ -3767,10 +3767,10 @@ static void dsi_display_enable(struct dsi_data *dsi)
>   dsi_runtime_put(dsi);
>  err_get_dsi:
>   mutex_unlock(&dsi->lock);
> - DSSDBG("dsi_display_ulps_enable FAILED\n");
> + DSSDBG("dsi_enable FAILED\n");
>  }
>  
> -static void dsi_display_disable(struct dsi_data *dsi,
> +static void dsi_disable(struct dsi_data *dsi,
>   bool disconnect_lanes, bool enter_ulps)
>  {
>   WARN_ON(!dsi_bus_is_locked(dsi));
> @@ -3782,7 +3782,7 @@ static void dsi_display_disable(struct dsi_data *dsi,
>   dsi_sync_vc(dsi, 2);
>   dsi_sync_vc(dsi, 3);
>  
> - dsi_d

Re: [PATCH v5 24/29] drm/omap: dsi: cleanup initial vc setup

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:50PM +0200, Tomi Valkeinen wrote:
> As we now have a fixed setup for VCs (VC0 for video stream, VC1 for
> commands), we can simplify the VC setup.
> 
> Signed-off-by: Tomi Valkeinen 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 85 +++
>  1 file changed, 31 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index d9c2cd849328..c32884f167b8 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -2017,40 +2017,6 @@ static void dsi_vc_initial_config(struct dsi_data 
> *dsi, int vc)
>   dsi->vc[vc].source = DSI_VC_SOURCE_L4;
>  }
>  
> -static int dsi_vc_config_source(struct dsi_data *dsi, int vc,
> - enum dsi_vc_source source)
> -{
> - if (dsi->vc[vc].source == source)
> - return 0;
> -
> - DSSDBG("Source config of VC %d", vc);
> -
> - dsi_sync_vc(dsi, vc);
> -
> - dsi_vc_enable(dsi, vc, 0);
> -
> - /* VC_BUSY */
> - if (!wait_for_bit_change(dsi, DSI_VC_CTRL(vc), 15, 0)) {
> - DSSERR("vc(%d) busy when trying to config for VP\n", vc);
> - return -EIO;
> - }
> -
> - /* SOURCE, 0 = L4, 1 = video port */
> - REG_FLD_MOD(dsi, DSI_VC_CTRL(vc), source, 1, 1);
> -
> - /* DCS_CMD_ENABLE */
> - if (dsi->data->quirks & DSI_QUIRK_DCS_CMD_CONFIG_VC) {
> - bool enable = source == DSI_VC_SOURCE_VP;
> - REG_FLD_MOD(dsi, DSI_VC_CTRL(vc), enable, 30, 30);
> - }
> -
> - dsi_vc_enable(dsi, vc, 1);
> -
> - dsi->vc[vc].source = source;
> -
> - return 0;
> -}
> -
>  static void dsi_vc_enable_hs(struct omap_dss_device *dssdev, int vc,
>   bool enable)
>  {
> @@ -2072,10 +2038,6 @@ static void dsi_vc_enable_hs(struct omap_dss_device 
> *dssdev, int vc,
>   dsi_if_enable(dsi, 1);
>  
>   dsi_force_tx_stop_mode_io(dsi);
> -
> - /* start the DDR clock by sending a NULL packet */
> - if (dsi->vm_timings.ddr_clk_always_on && enable)
> - dsi_vc_send_null(dsi, vc, dsi->dsidev->channel);
>  }
>  
>  static void dsi_vc_flush_long_data(struct dsi_data *dsi, int vc)
> @@ -2270,8 +2232,6 @@ static int dsi_vc_send_long(struct dsi_data *dsi, int 
> vc,
>   return -EINVAL;
>   }
>  
> - dsi_vc_config_source(dsi, vc, DSI_VC_SOURCE_L4);
> -
>   dsi_vc_write_long_header(dsi, vc, msg->channel, msg->type, msg->tx_len, 
> 0);
>  
>   p = msg->tx_buf;
> @@ -2331,8 +2291,6 @@ static int dsi_vc_send_short(struct dsi_data *dsi, int 
> vc,
>   DSSDBG("dsi_vc_send_short(ch%d, dt %#x, b1 %#x, b2 %#x)\n",
>  vc, msg->type, pkt.header[1], pkt.header[2]);
>  
> - dsi_vc_config_source(dsi, vc, DSI_VC_SOURCE_L4);
> -
>   if (FLD_GET(dsi_read_reg(dsi, DSI_VC_CTRL(vc)), 16, 16)) {
>   DSSERR("ERROR FIFO FULL, aborting transfer\n");
>   return -EINVAL;
> @@ -3351,8 +3309,6 @@ static void dsi_update_screen_dispc(struct dsi_data 
> *dsi)
>  
>   DSSDBG("dsi_update_screen_dispc(%dx%d)\n", w, h);
>  
> - dsi_vc_config_source(dsi, vc, DSI_VC_SOURCE_VP);
> -
>   bytespp = mipi_dsi_pixel_format_to_bpp(dsi->pix_fmt) / 8;
>   bytespl = w * bytespp;
>   bytespf = bytespl * h;
> @@ -3522,14 +3478,12 @@ static int dsi_update_channel(struct omap_dss_device 
> *dssdev, int vc)
>  
>   dsi_set_ulps_auto(dsi, false);
>  
> - dsi_vc_enable_hs(dssdev, vc, true);
> -
>   /*
>* Send NOP between the frames. If we don't send something here, the
>* updates stop working. This is probably related to DSI spec stating
>* that the DSI host should transition to LP at least once per frame.
>*/
> - r = _dsi_send_nop(dsi, vc, dsi->dsidev->channel);
> + r = _dsi_send_nop(dsi, VC_CMD, dsi->dsidev->channel);
>   if (r < 0) {
>   DSSWARN("failed to send nop between frames: %d\n", r);
>   goto err;
> @@ -3654,6 +3608,35 @@ static int dsi_configure_dsi_clocks(struct dsi_data 
> *dsi)
>   return 0;
>  }
>  
> +static void dsi_setup_dsi_vcs(struct dsi_data *dsi)
> +{
> + /* Setup VC_CMD for LP and cpu transfers */
> + REG_FLD_MOD(dsi, DSI_VC_CTRL(VC_CMD), 0, 9, 9); /* LP */
> +
> + REG_FLD_MOD(dsi, DSI_VC_CTRL(VC_CMD), 0, 1, 1); /* SOURCE_L4 */
> + dsi->vc[VC_CMD].sourc

Re: [PATCH v5 25/29] drm/omap: dsi: split video mode enable/disable into separate func

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:51PM +0200, Tomi Valkeinen wrote:
> Clean up the code by separating video-mode enable/disable code into
> functions of their own.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 101 +-
>  1 file changed, 57 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index c32884f167b8..71de6119d2de 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -3207,12 +3207,61 @@ static int dsi_configure_pins(struct dsi_data *dsi,
>   return 0;
>  }
>  
> -static void dsi_enable_video_output(struct omap_dss_device *dssdev, int vc)
> +static int dsi_enable_video_mode(struct dsi_data *dsi, int vc)
>  {
> - struct dsi_data *dsi = to_dsi_data(dssdev);
>   int bpp = mipi_dsi_pixel_format_to_bpp(dsi->pix_fmt);
>   u8 data_type;
>   u16 word_count;
> +
> + switch (dsi->pix_fmt) {
> + case MIPI_DSI_FMT_RGB888:
> + data_type = MIPI_DSI_PACKED_PIXEL_STREAM_24;
> + break;
> + case MIPI_DSI_FMT_RGB666:
> + data_type = MIPI_DSI_PIXEL_STREAM_3BYTE_18;
> + break;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + data_type = MIPI_DSI_PACKED_PIXEL_STREAM_18;
> + break;
> + case MIPI_DSI_FMT_RGB565:
> + data_type = MIPI_DSI_PACKED_PIXEL_STREAM_16;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + dsi_if_enable(dsi, false);
> + dsi_vc_enable(dsi, vc, false);
> +
> + /* MODE, 1 = video mode */
> + REG_FLD_MOD(dsi, DSI_VC_CTRL(vc), 1, 4, 4);
> +
> + word_count = DIV_ROUND_UP(dsi->vm.hactive * bpp, 8);
> +
> + dsi_vc_write_long_header(dsi, vc, dsi->dsidev->channel, data_type,
> + word_count, 0);
> +
> + dsi_vc_enable(dsi, vc, true);
> + dsi_if_enable(dsi, true);
> +
> + return 0;
> +}
> +
> +static void dsi_disable_video_mode(struct dsi_data *dsi, int vc)
> +{
> + dsi_if_enable(dsi, false);
> + dsi_vc_enable(dsi, vc, false);
> +
> + /* MODE, 0 = command mode */
> + REG_FLD_MOD(dsi, DSI_VC_CTRL(vc), 0, 4, 4);
> +
> + dsi_vc_enable(dsi, vc, true);
> + dsi_if_enable(dsi, true);
> +}
> +
> +static void dsi_enable_video_output(struct omap_dss_device *dssdev, int vc)
> +{
> + struct dsi_data *dsi = to_dsi_data(dssdev);
>   int r;
>  
>   r = dsi_init_dispc(dsi);
> @@ -3222,37 +3271,9 @@ static void dsi_enable_video_output(struct 
> omap_dss_device *dssdev, int vc)
>   }
>  
>   if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
> - switch (dsi->pix_fmt) {
> - case MIPI_DSI_FMT_RGB888:
> - data_type = MIPI_DSI_PACKED_PIXEL_STREAM_24;
> - break;
> - case MIPI_DSI_FMT_RGB666:
> - data_type = MIPI_DSI_PIXEL_STREAM_3BYTE_18;
> - break;
> - case MIPI_DSI_FMT_RGB666_PACKED:
> - data_type = MIPI_DSI_PACKED_PIXEL_STREAM_18;
> - break;
> - case MIPI_DSI_FMT_RGB565:
> - data_type = MIPI_DSI_PACKED_PIXEL_STREAM_16;
> - break;
> - default:
> - r = -EINVAL;
> - goto err_pix_fmt;
> - }
> -
> - dsi_if_enable(dsi, false);
> - dsi_vc_enable(dsi, vc, false);
> -
> - /* MODE, 1 = video mode */
> - REG_FLD_MOD(dsi, DSI_VC_CTRL(vc), 1, 4, 4);
> -
> - word_count = DIV_ROUND_UP(dsi->vm.hactive * bpp, 8);
> -
> - dsi_vc_write_long_header(dsi, vc, dsi->dsidev->channel, 
> data_type,
> - word_count, 0);
> -
> - dsi_vc_enable(dsi, vc, true);
> - dsi_if_enable(dsi, true);
> + r = dsi_enable_video_mode(dsi, vc);
> + if (r)
> + goto err_video_mode;
>   }
>  
>   r = dss_mgr_enable(&dsi->output);
> @@ -3266,7 +3287,7 @@ static void dsi_enable_video_output(struct 
> omap_dss_device *dssdev, int vc)
>   dsi_if_enable(dsi, false);
>   dsi_vc_enable(dsi, vc, false);
>   }
> -err_pix_fmt:
> +err_video_mode:
>   dsi_uninit_dispc(dsi);
>   dev_err(dsi->dev, "failed to enable DSI encoder!\n");
>   return;
> @@ -3276,16 +329

Re: [PATCH v5 26/29] drm/omap: dsi: fix and cleanup ddr_clk_always_on

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:52PM +0200, Tomi Valkeinen wrote:
> The driver ignores MIPI_DSI_CLOCK_NON_CONTINUOUS, and always uses
> non-continuous clock.
> 
> Fix this by using MIPI_DSI_CLOCK_NON_CONTINUOUS and at the same time,
> drop ddr_clk_always_on field which seems pretty useless.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 12 +---
>  drivers/gpu/drm/omapdrm/dss/dsi.h |  2 --
>  2 files changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 71de6119d2de..cc8b169b2223 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -1734,11 +1734,10 @@ static int dsi_cio_init(struct dsi_data *dsi)
>  
>   dsi_cio_timings(dsi);
>  
> - if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
> - /* DDR_CLK_ALWAYS_ON */
> - REG_FLD_MOD(dsi, DSI_CLK_CTRL,
> - dsi->vm_timings.ddr_clk_always_on, 13, 13);
> - }
> + /* DDR_CLK_ALWAYS_ON */
> + REG_FLD_MOD(dsi, DSI_CLK_CTRL,
> + !(dsi->dsidev->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS),
> + 13, 13);
>  
>   dsi->ulps_enabled = false;
>  
> @@ -3646,7 +3645,7 @@ static void dsi_setup_dsi_vcs(struct dsi_data *dsi)
>   dsi_force_tx_stop_mode_io(dsi);
>  
>   /* start the DDR clock by sending a NULL packet */
> - if (dsi->vm_timings.ddr_clk_always_on)
> + if (!(dsi->dsidev->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS))
>   dsi_vc_send_null(dsi, VC_CMD, dsi->dsidev->channel);
>  }
>  
> @@ -4155,7 +4154,6 @@ static bool dsi_vm_calc_blanking(struct 
> dsi_clk_calc_ctx *ctx)
>   dsi_vm->hfp_blanking_mode = 1;
>   dsi_vm->hbp_blanking_mode = 1;
>  
> - dsi_vm->ddr_clk_always_on = cfg->ddr_clk_always_on;
>   dsi_vm->window_sync = 4;
>  
>   /* setup DISPC videomode */
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.h 
> b/drivers/gpu/drm/omapdrm/dss/dsi.h
> index 478fc10bd18d..476069fda082 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.h
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.h
> @@ -212,7 +212,6 @@ struct omap_dss_dsi_videomode_timings {
>  
>   enum omap_dss_dsi_trans_mode trans_mode;
>  
> - bool ddr_clk_always_on;
>   int window_sync;
>  };
>  
> @@ -224,7 +223,6 @@ struct omap_dss_dsi_config {
>   unsigned long hs_clk_min, hs_clk_max;
>   unsigned long lp_clk_min, lp_clk_max;
>  
> - bool ddr_clk_always_on;
>   enum omap_dss_dsi_trans_mode trans_mode;
>  };
>  
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 28/29] drm/omap: dsi: fix DCS_CMD_ENABLE

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:54PM +0200, Tomi Valkeinen wrote:
> We only need to set VC_CTRL:DCS_CMD_ENABLE for command mode panels when
> the HW has DSI_QUIRK_DCS_CMD_CONFIG_VC quirk. The old code did this
> right by accident, but now we set DCS_CMD_ENABLE for video mode panels
> too.
> 
> Fix this by skipping the set for video mode.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index b2aa07a09dcd..53a64bc91867 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -3406,7 +3406,8 @@ static void dsi_setup_dsi_vcs(struct dsi_data *dsi)
>   REG_FLD_MOD(dsi, DSI_VC_CTRL(VC_VIDEO), 1, 1, 1); /* SOURCE_VP */
>   dsi->vc[VC_VIDEO].source = DSI_VC_SOURCE_VP;
>  
> - if (dsi->data->quirks & DSI_QUIRK_DCS_CMD_CONFIG_VC)
> + if ((dsi->data->quirks & DSI_QUIRK_DCS_CMD_CONFIG_VC) &&
> + !(dsi->dsidev->mode_flags & MIPI_DSI_MODE_VIDEO))
>   REG_FLD_MOD(dsi, DSI_VC_CTRL(VC_VIDEO), 1, 30, 30); /* 
> DCS_CMD_ENABLE */
>  
>   dsi_vc_enable(dsi, VC_CMD, 1);
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 29/29] drm/omap: dsi: allow DSI commands to be sent early

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:55PM +0200, Tomi Valkeinen wrote:
> Panel drivers can send DSI commands in panel's prepare(), which happens
> before the bridge's enable() is called. The OMAP DSI driver currently
> only sets up the DSI interface at bridge's enable(), so prepare() cannot
> be used to send DSI commands.
> 
> This patch fixes the issue by making it possible to enable the DSI
> interface any time a command is about to be sent. Disabling the
> interface is be done via delayed work.
> 
> Signed-off-by: Tomi Valkeinen 
> ---

Reviewed-by: Sebastian Reichel 

Would be nice to include the information why locking is ok from your
reply mails to the patch description. It was helpful for reviewing
the patch :)

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 49 +++
>  drivers/gpu/drm/omapdrm/dss/dsi.h |  3 ++
>  2 files changed, 47 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 53a64bc91867..34f665aa9a59 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -3503,6 +3503,9 @@ static void dsi_enable(struct dsi_data *dsi)
>  
>   WARN_ON(!dsi_bus_is_locked(dsi));
>  
> + if (WARN_ON(dsi->iface_enabled))
> + return;
> +
>   mutex_lock(&dsi->lock);
>  
>   r = dsi_runtime_get(dsi);
> @@ -3515,6 +3518,8 @@ static void dsi_enable(struct dsi_data *dsi)
>   if (r)
>   goto err_init_dsi;
>  
> + dsi->iface_enabled = true;
> +
>   mutex_unlock(&dsi->lock);
>  
>   return;
> @@ -3530,6 +3535,9 @@ static void dsi_disable(struct dsi_data *dsi)
>  {
>   WARN_ON(!dsi_bus_is_locked(dsi));
>  
> + if (WARN_ON(!dsi->iface_enabled))
> + return;
> +
>   mutex_lock(&dsi->lock);
>  
>   dsi_sync_vc(dsi, 0);
> @@ -3541,6 +3549,8 @@ static void dsi_disable(struct dsi_data *dsi)
>  
>   dsi_runtime_put(dsi);
>  
> + dsi->iface_enabled = false;
> +
>   mutex_unlock(&dsi->lock);
>  }
>  
> @@ -4229,10 +4239,12 @@ static ssize_t omap_dsi_host_transfer(struct 
> mipi_dsi_host *host,
>  
>   dsi_bus_lock(dsi);
>  
> - if (dsi->video_enabled)
> - r = _omap_dsi_host_transfer(dsi, vc, msg);
> - else
> - r = -EIO;
> + if (!dsi->iface_enabled) {
> + dsi_enable(dsi);
> + schedule_delayed_work(&dsi->dsi_disable_work, 
> msecs_to_jiffies(2000));
> + }
> +
> + r = _omap_dsi_host_transfer(dsi, vc, msg);
>  
>   dsi_bus_unlock(dsi);
>  
> @@ -4397,6 +4409,14 @@ static int omap_dsi_host_detach(struct mipi_dsi_host 
> *host,
>   if (WARN_ON(dsi->dsidev != client))
>   return -EINVAL;
>  
> + cancel_delayed_work_sync(&dsi->dsi_disable_work);
> +
> + if (dsi->iface_enabled) {
> + dsi_bus_lock(dsi);
> + dsi_disable(dsi);
> + dsi_bus_unlock(dsi);
> + }
> +
>   omap_dsi_unregister_te_irq(dsi);
>   dsi->dsidev = NULL;
>   return 0;
> @@ -4632,9 +4652,12 @@ static void dsi_bridge_enable(struct drm_bridge 
> *bridge)
>   struct dsi_data *dsi = drm_bridge_to_dsi(bridge);
>   struct omap_dss_device *dssdev = &dsi->output;
>  
> + cancel_delayed_work_sync(&dsi->dsi_disable_work);
> +
>   dsi_bus_lock(dsi);
>  
> - dsi_enable(dsi);
> + if (!dsi->iface_enabled)
> + dsi_enable(dsi);
>  
>   dsi_enable_video_output(dssdev, VC_VIDEO);
>  
> @@ -4648,6 +4671,8 @@ static void dsi_bridge_disable(struct drm_bridge 
> *bridge)
>   struct dsi_data *dsi = drm_bridge_to_dsi(bridge);
>   struct omap_dss_device *dssdev = &dsi->output;
>  
> + cancel_delayed_work_sync(&dsi->dsi_disable_work);
> +
>   dsi_bus_lock(dsi);
>  
>   dsi->video_enabled = false;
> @@ -4840,6 +4865,18 @@ static const struct soc_device_attribute 
> dsi_soc_devices[] = {
>   { /* sentinel */ }
>  };
>  
> +static void omap_dsi_disable_work_callback(struct work_struct *work)
> +{
> + struct dsi_data *dsi = container_of(work, struct dsi_data, 
> dsi_disable_work.work);
> +
> + dsi_bus_lock(dsi);
> +
> + if (dsi->iface_enabled && !dsi->video_enabled)
> + dsi_disable(dsi);
> +
> + dsi_bus_unlock(dsi);
> +}
> +
>  static int dsi_probe(struct platform_device *pdev)
>  {
>   const struct soc_device_attribute *soc;
> @@ -4873,6 +4910,8 @@ static int dsi_probe(struct plat

Re: [PATCH v5 27/29] drm/omap: dsi: remove ulps support

[Sebastian Reichel]

Hi,

On Tue, Dec 08, 2020 at 02:28:53PM +0200, Tomi Valkeinen wrote:
> ULPS doesn't work, and I have been unable to get it to work. As ULPS
> is a minor power-saving feature which requires substantial amount of
> non-trivial code, and we have trouble just getting and
> keeping DSI working at all, remove ULPS support.
>
> When the DSI driver works reliably for command and video mode displays,
> someone interested can add it back.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Laurent Pinchart 
> ---

Is it really 'minor power-saving'? If I search for DSI and ULPS among
the first results is a TI datasheet for SN65DSI84, which claims device
active current in the more than 100mA range and ULPS current in the
less than 10mA range.

Considering all known omapdrm DSI users are battery powered devices
caring for saving as much power as possible, it might be good to just
keep this until it is being fixed considering this is very close to
the end of the series anyways?

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 297 +-
>  drivers/gpu/drm/omapdrm/dss/dsi.h |   4 -
>  2 files changed, 8 insertions(+), 293 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index cc8b169b2223..b2aa07a09dcd 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -53,8 +53,6 @@
>  #define REG_FLD_MOD(dsi, idx, val, start, end) \
>   dsi_write_reg(dsi, idx, FLD_MOD(dsi_read_reg(dsi, idx), val, start, 
> end))
>  
> -static void dsi_set_ulps_auto(struct dsi_data *dsi, bool enable);
> -
>  static int dsi_init_dispc(struct dsi_data *dsi);
>  static void dsi_uninit_dispc(struct dsi_data *dsi);
>  
> @@ -688,44 +686,6 @@ static int dsi_unregister_isr_vc(struct dsi_data *dsi, 
> int vc,
>   return r;
>  }
>  
> -static int dsi_register_isr_cio(struct dsi_data *dsi, omap_dsi_isr_t isr,
> - void *arg, u32 mask)
> -{
> - unsigned long flags;
> - int r;
> -
> - spin_lock_irqsave(&dsi->irq_lock, flags);
> -
> - r = _dsi_register_isr(isr, arg, mask, dsi->isr_tables.isr_table_cio,
> - ARRAY_SIZE(dsi->isr_tables.isr_table_cio));
> -
> - if (r == 0)
> - _omap_dsi_set_irqs_cio(dsi);
> -
> - spin_unlock_irqrestore(&dsi->irq_lock, flags);
> -
> - return r;
> -}
> -
> -static int dsi_unregister_isr_cio(struct dsi_data *dsi, omap_dsi_isr_t isr,
> -   void *arg, u32 mask)
> -{
> - unsigned long flags;
> - int r;
> -
> - spin_lock_irqsave(&dsi->irq_lock, flags);
> -
> - r = _dsi_unregister_isr(isr, arg, mask, dsi->isr_tables.isr_table_cio,
> - ARRAY_SIZE(dsi->isr_tables.isr_table_cio));
> -
> - if (r == 0)
> - _omap_dsi_set_irqs_cio(dsi);
> -
> - spin_unlock_irqrestore(&dsi->irq_lock, flags);
> -
> - return r;
> -}
> -
>  static u32 dsi_get_errors(struct dsi_data *dsi)
>  {
>   unsigned long flags;
> @@ -1450,56 +1410,6 @@ static void dsi_cio_timings(struct dsi_data *dsi)
>   dsi_write_reg(dsi, DSI_DSIPHY_CFG2, r);
>  }
>  
> -/* lane masks have lane 0 at lsb. mask_p for positive lines, n for negative 
> */
> -static void dsi_cio_enable_lane_override(struct dsi_data *dsi,
> -  unsigned int mask_p,
> -  unsigned int mask_n)
> -{
> - int i;
> - u32 l;
> - u8 lptxscp_start = dsi->num_lanes_supported == 3 ? 22 : 26;
> -
> - l = 0;
> -
> - for (i = 0; i < dsi->num_lanes_supported; ++i) {
> - unsigned int p = dsi->lanes[i].polarity;
> -
> - if (mask_p & (1 << i))
> - l |= 1 << (i * 2 + (p ? 0 : 1));
> -
> - if (mask_n & (1 << i))
> - l |= 1 << (i * 2 + (p ? 1 : 0));
> - }
> -
> - /*
> -  * Bits in REGLPTXSCPDAT4TO0DXDY:
> -  * 17: DY0 18: DX0
> -  * 19: DY1 20: DX1
> -  * 21: DY2 22: DX2
> -  * 23: DY3 24: DX3
> -  * 25: DY4 26: DX4
> -  */
> -
> - /* Set the lane override configuration */
> -
> - /* REGLPTXSCPDAT4TO0DXDY */
> - REG_FLD_MOD(dsi, DSI_DSIPHY_CFG10, l, lptxscp_start, 17);
> -
> - /* Enable lane override */
> -
> - /* ENLPTXSCPDAT */
> - REG_FLD_MOD(dsi, DSI_DSIPHY_CFG10, 1, 27, 27);
> -}
> -
> -static void dsi_cio_disable_lane_override(struct dsi_data *dsi)
> -{
> - /* Disable lane override */
> - REG_FLD_MOD(dsi, DSI_DSIPHY_CFG1

Re: [PATCH v5 27/29] drm/omap: dsi: remove ulps support

[Sebastian Reichel]

Hi,

On Mon, Dec 14, 2020 at 08:55:36PM +0200, Tomi Valkeinen wrote:
> On 14/12/2020 19:39, Sebastian Reichel wrote:
> > Hi,
> > 
> > On Tue, Dec 08, 2020 at 02:28:53PM +0200, Tomi Valkeinen wrote:
> >> ULPS doesn't work, and I have been unable to get it to work. As ULPS
> >> is a minor power-saving feature which requires substantial amount of
> >> non-trivial code, and we have trouble just getting and
> >> keeping DSI working at all, remove ULPS support.
> >>
> >> When the DSI driver works reliably for command and video mode displays,
> >> someone interested can add it back.
> >>
> >> Signed-off-by: Tomi Valkeinen 
> >> Reviewed-by: Laurent Pinchart 
> >> ---
> > 
> > Is it really 'minor power-saving'? If I search for DSI and ULPS among
> > the first results is a TI datasheet for SN65DSI84, which claims device
> > active current in the more than 100mA range and ULPS current in the
> > less than 10mA range.
> 
> I don't have any numbers, just my guesses. For videomode displays
> or command mode displays in active use, I don't think ULPS matters
> much. The link is mostly not in ULPS. And if the display is
> blanked, things are off, so again not in ULPS.
> 
> It's only for command mode displays, when updated rarely, where I
> think ULPS matters. Which, of course, is probably not unusual use
> case if you have a cmdmode display. But whether OMAP DSI power
> savings matches SN65DSI84, I have no clue.

Right. FWIW I don't expect savings to be as big as this. The
comparision is not "active current", but "idle current" since
we do disable the clocks among other things. Considering the
amount of power-saving is pure guess-work I suggest to rephrase
the commit message to something like this:

ULPS is a niche power-saving optimization feature only
affecting enabled command mode panels showing a static
picture. It never worked with the omapdrm driver and I have
been unable to get it working. Keeping DSI command mode panels
working is hard enough without this, so remove ULPS support.

FWIW I'm fine with this being removed:

Reviewed-by: Sebastian Reichel 

> > Considering all known omapdrm DSI users are battery powered devices
> > caring for saving as much power as possible, it might be good to just
> > keep this until it is being fixed considering this is very close to
> > the end of the series anyways?
> 
> I don't like to leave known to be broken code around, unless
> someone has plans to work on it. I wouldn't be surprised to see
> ULPS still broken two years from now =). It should be trivial to
> add the relevant bits back later.

Ack.

> But I can leave it here if you think it's better, presuming it
> doesn't have bigger conflicts with the 29/29 or break anything.
> However, I have only a few days left in TI, which is why I'm
> rushing here a bit (*). If I hit problems, I either have to drop
> the whole series, or push it in its current form.
> 
>  Tomi
> 
> (*) But I will fix possible issues caused by my push, of course.

Best of luck on whatever you do next!

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dt-bindings: Add missing array size constraints

[Sebastian Reichel]

Hi Rob,

On Mon, Jan 04, 2021 at 04:02:53PM -0700, Rob Herring wrote:
> DT properties which can have multiple entries need to specify what the
> entries are and define how many entries there can be. In the case of
> only a single entry, just 'maxItems: 1' is sufficient.
> 
> Add the missing entry constraints. These were found with a modified
> meta-schema. Unfortunately, there are a few cases where the size
> constraints are not defined such as common bindings, so the meta-schema
> can't be part of the normal checks.
> 
> [...]
>  .../bindings/power/supply/bq25980.yaml|  1 +
> [...]

Acked-by: Sebastian Reichel 

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 39/80] drm/panel: Move OMAP's DSI command mode panel driver

[Sebastian Reichel]

Hi,

On Fri, Jan 08, 2021 at 01:23:54PM -0800, Dixit, Ashutosh wrote:
> On Tue, 24 Nov 2020 04:44:57 -0800, Tomi Valkeinen wrote:
> >
> > From: Sebastian Reichel 
> >
> > The panel driver is no longer using any OMAP specific APIs, so
> > let's move it into the generic panel directory.
> >
> > Signed-off-by: Sebastian Reichel 
> > Signed-off-by: Tomi Valkeinen 
> > Cc: Thierry Reding 
> > Cc: Sam Ravnborg 
> > Acked-by: Sam Ravnborg 
> > Acked-by: Laurent Pinchart 
> > ---
> >  drivers/gpu/drm/omapdrm/Kconfig|  1 -
> >  drivers/gpu/drm/omapdrm/Makefile   |  1 -
> >  drivers/gpu/drm/omapdrm/displays/Kconfig   | 10 --
> >  drivers/gpu/drm/omapdrm/displays/Makefile  |  2 --
> >  drivers/gpu/drm/panel/Kconfig  |  9 +
> >  drivers/gpu/drm/panel/Makefile |  1 +
> >  .../gpu/drm/{omapdrm/displays => panel}/panel-dsi-cm.c |  0
> 
> Not sure if it's a result of this commit but on drm-tip we see:
> 
> $ make allmodconfig
> $ make modules_check
>   DESCEND  objtool
>   CALLscripts/atomic/check-atomics.sh
>   CALLscripts/checksyscalls.sh
>   CHK include/generated/compile.h
> error: the following would cause module name conflict:
>   drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
>   drivers/gpu/drm/panel/panel-dsi-cm.ko
> make: *** [Makefile:1400: modules_check] Error 1

It is a result of this commit and it has already been reported by
Stephen Rothwell. The thread also contains a patch to fixup the
problem:

https://lore.kernel.org/linux-next/20210108195839.ga1429...@ravnborg.org/T/#m0eee5e806cc93cf9982620b7b8b9f77df2c37498

Sorry for the inconvenience,

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive

[Sebastian Reichel]

Standard DRM panel driver for DSI command mode panel used by omapfb2 is also
available now. Just like the other panels its module name clashes with the
module from drivers/video/fbdev/omap2/omapfb/displays, part of the deprecated
omapfb2 fbdev driver. As omapfb2 can only be compiled when the omapdrm driver
is disabled, and the DRM panel drivers are useless in that case, make the
omapfb2 panel depend on the standard DRM panels being disabled to fix
the name clash.

Fixes: cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
Reported-by: Stephen Rothwell 
Signed-off-by: Sebastian Reichel 
---
Laurent introduced and fixed the same issue for the other panels and
this simply replicates the same solution for DSI command mode panel.
---
 drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig 
b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
index 744416dc530e..384d74a126dc 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
+++ b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
@@ -43,6 +43,7 @@ config FB_OMAP2_PANEL_DPI
 config FB_OMAP2_PANEL_DSI_CM
tristate "Generic DSI Command Mode Panel"
depends on BACKLIGHT_CLASS_DEVICE
+   depends on DRM_PANEL_DSI_CM = n
help
  Driver for generic DSI command mode panels.
 
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive

[Sebastian Reichel]

[replace Tomi's TI mail address with something working]

Hi,

On Fri, Jan 08, 2021 at 08:58:39PM +0100, Sam Ravnborg wrote:
> Hi Sebastian,
> 
> On Fri, Jan 08, 2021 at 12:24:41PM +0100, Sebastian Reichel wrote:
> > Standard DRM panel driver for DSI command mode panel used by omapfb2 is also
> > available now. Just like the other panels its module name clashes with the
> > module from drivers/video/fbdev/omap2/omapfb/displays, part of the 
> > deprecated
> > omapfb2 fbdev driver. As omapfb2 can only be compiled when the omapdrm 
> > driver
> > is disabled, and the DRM panel drivers are useless in that case, make the
> > omapfb2 panel depend on the standard DRM panels being disabled to fix
> > the name clash.
> > 
> > Fixes: cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
> > Reported-by: Stephen Rothwell 
> > Signed-off-by: Sebastian Reichel 
> 
> For a backport this looks good:
> Acked-by: Sam Ravnborg 

Thanks.

> But why is it it we need omapfb at all when we have omapdrm?

I think there are two reasons omapfb has not been killed yet. One
reason was missing support for manually updated DSI panels, which
have been working since 1 or 2 kernel releases now. The other reason
is some people using it in combination with an out-of-tree PowerVR
kernel driver. There is currently work going on to use a more recent
PowerVR driver based on omapdrm driven by Maemo Leste people.

> Can we sunset all or some parts of omap support in video/?
> If not, what is missing to do so.

IDK the exact status of the PowerVR work and have not been using
omapfb myself for years. I don't think there is a reason to rush
this, so my suggestion is removing it in 3 steps giving people
the chance to complain:

1. Add 'depends on EXPERT' to 'FB_OMAP2' and add deprecation notice
   referencing omapdrm in help text in 5.12
2. Add 'depends on BROKEN' in 5.13
3. Drop drivers/video/fbdev/omap2 afterwards

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

omapfb removal (was: Re: [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive)

[Sebastian Reichel]

[dropped linux-next from Cc]

Hi,

On Tue, Jan 12, 2021 at 03:10:56PM +0200, Tomi Valkeinen wrote:
> >> But why is it it we need omapfb at all when we have omapdrm?
> > 
> > I think there are two reasons omapfb has not been killed yet. One
> > reason was missing support for manually updated DSI panels, which
> > have been working since 1 or 2 kernel releases now. The other reason
> > is some people using it in combination with an out-of-tree PowerVR
> > kernel driver. There is currently work going on to use a more recent
> > PowerVR driver based on omapdrm driven by Maemo Leste people.
> 
> omapfb also has a custom sysfs API, so applications that depend on it
> would not work anymore. I don't know if there are such applications, though.
> 
> >> Can we sunset all or some parts of omap support in video/?
> >> If not, what is missing to do so.
> > 
> > IDK the exact status of the PowerVR work and have not been using
> > omapfb myself for years. I don't think there is a reason to rush
> > this, so my suggestion is removing it in 3 steps giving people
> > the chance to complain:
> > 
> > 1. Add 'depends on EXPERT' to 'FB_OMAP2' and add deprecation notice
> >referencing omapdrm in help text in 5.12
> > 2. Add 'depends on BROKEN' in 5.13
> > 3. Drop drivers/video/fbdev/omap2 afterwards
> 
> I'd love to remove omapfb, but I also fear that there are still people
> using it. We can try the above sequence, but it's probably better to go
> slower, as people may not be using the latest kernels.

I thought about this again and I think the best option is to rename
CONFIG_FB_OMAP2 to something like CONFIG_FB_OMAP2_DEPRECATED and
update the help text. That way anyone with CONFIG_FB_OMAP2 in
their .config will definitely notice the change when upgrading to
a newer kernel, but can easily fix it temporarily. Help text could
be

"This driver will be removed in 2022, please switch to omapdrm."

and no other intermediate steps are required that way :)

But while looking through CONFIG_FB_OMAP2 references I noticed there
is also a V4L2 driver (CONFIG_VIDEO_OMAP2_VOUT), which seems to
only work with omapfb. IIUIC that driver provides display overlays
to V4L. I guess on omapdrm V4L can use DRM planes instead and no
driver is needed (i.e. this driver could just go away with omapfb)?

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv6 1/4] drm/omap: use DRM_DEBUG_DRIVER instead of CORE

[Sebastian Reichel]

This macro is only used by omapdrm, which should print
debug messages using the DRIVER category instead of the
default CORE category.

Acked-by: Pavel Machek 
Tested-by: Tony Lindgren 
Tested-by: Pavel Machek 
Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_drv.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 3cca45cb25f3..896aa12f09b2 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -37,8 +37,8 @@
 #include "omap_irq.h"
 #include "omap_plane.h"
 
-#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
-#define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose debug */
+#define DBG(fmt, ...) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__)
+#define VERB(fmt, ...) if (0) DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) /* verbose 
debug */
 
 #define MODULE_NAME "omapdrm"
 
-- 
2.20.1

[PATCHv6 3/4] drm/omap: add framedone interrupt support

[Sebastian Reichel]

This prepares framedone interrupt handling for
manual display update support.

Acked-by: Pavel Machek 
Tested-by: Tony Lindgren 
Tested-by: Pavel Machek 
Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 50 +
 drivers/gpu/drm/omapdrm/omap_crtc.h |  1 +
 drivers/gpu/drm/omapdrm/omap_irq.c  | 25 +++
 drivers/gpu/drm/omapdrm/omap_irq.h  |  1 +
 4 files changed, 77 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 86827a061b0b..68697820d189 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -51,6 +51,9 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+
+   void (*framedone_handler)(void *);
+   void *framedone_handler_data;
 };
 
 /* 
-
@@ -230,6 +233,18 @@ static int omap_crtc_dss_register_framedone(
struct omap_drm_private *priv, enum omap_channel channel,
void (*handler)(void *), void *data)
 {
+   struct drm_crtc *crtc = priv->channels[channel]->crtc;
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+   struct drm_device *dev = omap_crtc->base.dev;
+
+   if (omap_crtc->framedone_handler)
+   return -EBUSY;
+
+   dev_dbg(dev->dev, "register framedone %s", omap_crtc->name);
+
+   omap_crtc->framedone_handler = handler;
+   omap_crtc->framedone_handler_data = data;
+
return 0;
 }
 
@@ -237,6 +252,17 @@ static void omap_crtc_dss_unregister_framedone(
struct omap_drm_private *priv, enum omap_channel channel,
void (*handler)(void *), void *data)
 {
+   struct drm_crtc *crtc = priv->channels[channel]->crtc;
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+   struct drm_device *dev = omap_crtc->base.dev;
+
+   dev_dbg(dev->dev, "unregister framedone %s", omap_crtc->name);
+
+   WARN_ON(omap_crtc->framedone_handler != handler);
+   WARN_ON(omap_crtc->framedone_handler_data != data);
+
+   omap_crtc->framedone_handler = NULL;
+   omap_crtc->framedone_handler_data = NULL;
 }
 
 static const struct dss_mgr_ops mgr_ops = {
@@ -302,6 +328,30 @@ void omap_crtc_vblank_irq(struct drm_crtc *crtc)
DBG("%s: apply done", omap_crtc->name);
 }
 
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus)
+{
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+
+   if (!omap_crtc->framedone_handler) {
+   dev_warn(omap_crtc->base.dev->dev, "no framedone handler?");
+   return;
+   }
+
+   omap_crtc->framedone_handler(omap_crtc->framedone_handler_data);
+
+   spin_lock(&crtc->dev->event_lock);
+   /* Send the vblank event if one has been requested. */
+   if (omap_crtc->event) {
+   drm_crtc_send_vblank_event(crtc, omap_crtc->event);
+   omap_crtc->event = NULL;
+   }
+   omap_crtc->pending = false;
+   spin_unlock(&crtc->dev->event_lock);
+
+   /* Wake up omap_atomic_complete. */
+   wake_up(&omap_crtc->pending_wait);
+}
+
 static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
 {
struct omap_drm_private *priv = crtc->dev->dev_private;
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.h 
b/drivers/gpu/drm/omapdrm/omap_crtc.h
index d9de437ba9dd..d33bbb7a4f90 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.h
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.h
@@ -41,5 +41,6 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
 int omap_crtc_wait_pending(struct drm_crtc *crtc);
 void omap_crtc_error_irq(struct drm_crtc *crtc, u32 irqstatus);
 void omap_crtc_vblank_irq(struct drm_crtc *crtc);
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus);
 
 #endif /* __OMAPDRM_CRTC_H__ */
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 329ad26d6d50..01dda84ca2ee 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -85,6 +85,28 @@ int omap_irq_wait(struct drm_device *dev, struct 
omap_irq_wait *wait,
return ret == 0 ? -1 : 0;
 }
 
+int omap_irq_enable_framedone(struct drm_crtc *crtc, bool enable)
+{
+   struct drm_device *dev = crtc->dev;
+   struct omap_drm_private *priv = dev->dev_private;
+   unsigned long flags;
+   enum omap_channel channel = omap_crtc_channel(crtc);
+   int framedone_irq =
+   priv->dispc_ops->mgr_get_framedone_irq(priv->dispc, channel);
+
+   DBG("dev=%p, crtc=%u, enable=%d", dev, channel, enable);
+
+   spin_lock_irqsave(&priv->wait_lock, flags);
+   if (enable)
+ 

[PATCHv6 4/4] drm/omap: add support for manually updated displays

[Sebastian Reichel]

This adds the required infrastructure for manually updated displays,
such as DSI command mode panels. While those panels often support
partial updates we currently always do a full refresh.

The display will be refreshed when something calls the dirty callback,
such as libdrm's drmModeDirtyFB(). This is currently being done at least
by the kernel console and Xorg (with modesetting driver) in their
default configuration. Weston does not implement this and the fbdev
backend does not work (display will not update). Weston's DRM backend
uses double buffering and the page flip will also trigger a display
refresh.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 114 ++--
 drivers/gpu/drm/omapdrm/omap_crtc.h |   1 +
 drivers/gpu/drm/omapdrm/omap_fb.c   |  19 +
 3 files changed, 129 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 68697820d189..b59065365c9e 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -32,6 +32,7 @@ struct omap_crtc_state {
/* Shadow values for legacy userspace support. */
unsigned int rotation;
unsigned int zpos;
+   bool manually_updated;
 };
 
 #define to_omap_crtc(x) container_of(x, struct omap_crtc, base)
@@ -51,6 +52,7 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+   struct delayed_work update_work;
 
void (*framedone_handler)(void *);
void *framedone_handler_data;
@@ -105,21 +107,18 @@ int omap_crtc_wait_pending(struct drm_crtc *crtc)
 /*
  * Manager-ops, callbacks from output when they need to configure
  * the upstream part of the video pipe.
- *
- * Most of these we can ignore until we add support for command-mode
- * panels.. for video-mode the crtc-helpers already do an adequate
- * job of sequencing the setup of the video pipe in the proper order
  */
 
-/* we can probably ignore these until we support command-mode panels: */
 static void omap_crtc_dss_start_update(struct omap_drm_private *priv,
   enum omap_channel channel)
 {
+   priv->dispc_ops->mgr_enable(priv->dispc, channel, true);
 }
 
 /* Called only from the encoder enable/disable and suspend/resume handlers. */
 static void omap_crtc_set_enabled(struct drm_crtc *crtc, bool enable)
 {
+   struct omap_crtc_state *omap_state = to_omap_crtc_state(crtc->state);
struct drm_device *dev = crtc->dev;
struct omap_drm_private *priv = dev->dev_private;
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
@@ -131,6 +130,12 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
bool enable)
if (WARN_ON(omap_crtc->enabled == enable))
return;
 
+   if (omap_state->manually_updated) {
+   omap_irq_enable_framedone(crtc, enable);
+   omap_crtc->enabled = enable;
+   return;
+   }
+
if (omap_crtc->pipe->output->type == OMAP_DISPLAY_TYPE_HDMI) {
priv->dispc_ops->mgr_enable(priv->dispc, channel, enable);
omap_crtc->enabled = enable;
@@ -352,6 +357,51 @@ void omap_crtc_framedone_irq(struct drm_crtc *crtc, 
uint32_t irqstatus)
wake_up(&omap_crtc->pending_wait);
 }
 
+void omap_crtc_flush(struct drm_crtc *crtc)
+{
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+   struct omap_crtc_state *omap_state = to_omap_crtc_state(crtc->state);
+
+   if (!omap_state->manually_updated)
+   return;
+
+   if (!delayed_work_pending(&omap_crtc->update_work))
+   schedule_delayed_work(&omap_crtc->update_work, 0);
+}
+
+static void omap_crtc_manual_display_update(struct work_struct *data)
+{
+   struct omap_crtc *omap_crtc =
+   container_of(data, struct omap_crtc, update_work.work);
+   struct drm_display_mode *mode = &omap_crtc->pipe->crtc->mode;
+   struct omap_dss_device *dssdev = omap_crtc->pipe->output->next;
+   struct drm_device *dev = omap_crtc->base.dev;
+   const struct omap_dss_driver *dssdrv;
+   int ret;
+
+   if (!dssdev) {
+   dev_err_once(dev->dev, "missing display dssdev!");
+   return;
+   }
+
+   dssdrv = dssdev->driver;
+   if (!dssdrv || !dssdrv->update) {
+   dev_err_once(dev->dev, "missing or incorrect dssdrv!");
+   return;
+   }
+
+   if (dssdrv->sync)
+   dssdrv->sync(dssdev);
+
+   ret = dssdrv->update(dssdev, 0, 0, mode->hdisplay, mode->vdisplay);
+   if (ret < 0) {
+   spin_lock_irq(&dev->event_lock);
+   omap_crtc->pending = false;
+   spin_unlock_irq(

[PATCHv6 0/4] omapdrm: DSI command mode panel support

[Sebastian Reichel]

Hi,

Here is another round of the DSI command mode panel patchset
integrating the feedback from PATCHv5. The patches are based
on v5.2-rc1 tag. It does not contain the patches required for
OMAP3 support (it needs a workaround for a hardware bug) and
for automatic display rotation. They should get their own series,
once after everything has been moved to DRM panel API. I think
DRM panel conversion should happen _after_ this series, since
otherwise there is a high risk of bricking DSI support completely.
I already started a WIP branch for converting DSI to the DRM panel
API on top of this patchset.

Tested on Droid 4:
 * Display blanking
  - automatic backlight blanking is missing (not handled by DSI)
 * Framebuffer Console, updated at 1Hz due to blinking cursor
 * Xorg 1.19 with modesetting driver
 * Weston 5.0 with DRM backend
 * kmstest (static image)
 * No updates send when nothing needs to be sent

Known issues:
 * OMAP3 is untested and most likely broken due to missing
   workaround(s) for hardware bugs.
 * Weston 5.0 with fbdev backend does not work, since it
   uses neither page flip nor dirty ioctl. You need to use
   the drm backend.

Changes since PATCHv5:
 * Rebased to v5.2-rc1
 * Simplified omap_framebuffer_dirty() by using
   drm_for_each_crtc()

Changes since PATCHv4:
 * Apply Acked-/Tested-by received from Tony and Pavel
 * Fix spelling/optimize commit messages
 * Use proper multi-line comments
 * Restructure patch 4: move the whole HDMI block into a
   static subfunction, that is only called when output
   type is HDMI. Also drop the incorrect check for DVI.

Changes since PATCHv3:
 * Drop all Tested/Acked-by tags
 * Drop the rotation patches for now
 * Rebase to 4.20-rc1 + fixes from Laurent and Tony
 * Add fixes for DSI regressions introduced in 4.20-rc1
 * Store info update manual update mode in omap_crtc_state
 * Lock modesetting in omap_framebuffer_dirty
 * Directly loop through CRTCs instead of connectors in dirty function
 * Properly refresh display during page flips and get Weston working
 * Add more comments about implementation details

Changes since PATCHv2:
 * Drop omap3 quirk patch (OMAP3 should get its own mini-series)
 * Rebase to current linux-next
 * Use existing 'rotation' DT property to set DRM orientation hint
 * Add Tested-by from Tony

Changes since PATCHv1:
 * Drop patches, that were queued by Tomi
 * Rebase to current master
 * Rework the omap3 workaround patch to only affect omap3
 * Add orientation DRM property support

-- Sebastian

Sebastian Reichel (4):
  drm/omap: use DRM_DEBUG_DRIVER instead of CORE
  drm/omap: don't check dispc timings for DSI
  drm/omap: add framedone interrupt support
  drm/omap: add support for manually updated displays

 drivers/gpu/drm/omapdrm/omap_crtc.c | 182 ++--
 drivers/gpu/drm/omapdrm/omap_crtc.h |   2 +
 drivers/gpu/drm/omapdrm/omap_drv.h  |   4 +-
 drivers/gpu/drm/omapdrm/omap_fb.c   |  19 +++
 drivers/gpu/drm/omapdrm/omap_irq.c  |  25 
 drivers/gpu/drm/omapdrm/omap_irq.h  |   1 +
 6 files changed, 222 insertions(+), 11 deletions(-)

-- 
2.20.1

[PATCHv6 2/4] drm/omap: don't check dispc timings for DSI

[Sebastian Reichel]

While most display types only forward their VM to the DISPC, this
is not true for DSI. DSI calculates the VM for DISPC based on its
own, but it's not identical. Actually the DSI VM is not even a valid
DISPC VM making this check fail. Let's restore the old behaviour
and avoid checking the DISPC VM for DSI here.

Fixes: 7c27fa57ef31 ("drm/omap: Call dispc timings check operation directly")
Acked-by: Pavel Machek 
Tested-by: Tony Lindgren 
Tested-by: Pavel Machek 
Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 5a29bf01c0e8..86827a061b0b 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -395,10 +395,20 @@ static enum drm_mode_status omap_crtc_mode_valid(struct 
drm_crtc *crtc,
int r;
 
drm_display_mode_to_videomode(mode, &vm);
-   r = priv->dispc_ops->mgr_check_timings(priv->dispc, omap_crtc->channel,
-  &vm);
-   if (r)
-   return r;
+
+   /*
+* DSI might not call this, since the supplied mode is not a
+* valid DISPC mode. DSI will calculate and configure the
+* proper DISPC mode later.
+*/
+   if (omap_crtc->pipe->output->next == NULL ||
+   omap_crtc->pipe->output->next->type != OMAP_DISPLAY_TYPE_DSI) {
+   r = priv->dispc_ops->mgr_check_timings(priv->dispc,
+  omap_crtc->channel,
+  &vm);
+   if (r)
+   return r;
+   }
 
/* Check for bandwidth limit */
if (priv->max_bandwidth) {
-- 
2.20.1

Re: [PATCH v2 01/49] drm/atomic: Constify mode argument to mode_valid_path()

[Sebastian Reichel]

Hi,

On Fri, Jan 11, 2019 at 05:50:32AM +0200, Laurent Pinchart wrote:
> The mode_valid_path() function validates the mode it receives without
> ever modifying it. Constify the mode pointer argument to make that
> explicit.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Ville Syrjälä 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 54e2ae614dcc..d4ebec2c9f15 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -489,7 +489,7 @@ mode_fixup(struct drm_atomic_state *state)
>  static enum drm_mode_status mode_valid_path(struct drm_connector *connector,
>   struct drm_encoder *encoder,
>   struct drm_crtc *crtc,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode *mode)
>  {
>   enum drm_mode_status ret;
>  
> @@ -528,7 +528,7 @@ mode_valid(struct drm_atomic_state *state)
>   struct drm_crtc *crtc = conn_state->crtc;
>   struct drm_crtc_state *crtc_state;
>   enum drm_mode_status mode_status;
> - struct drm_display_mode *mode;
> + const struct drm_display_mode *mode;
>  
>   if (!crtc || !encoder)
>   continue;
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 46/49] drm/omap: Add support for drm_panel

[Sebastian Reichel]

Hi,

On Fri, Jan 11, 2019 at 05:51:17AM +0200, Laurent Pinchart wrote:
> Hook up drm_panel support in the omapdrm driver. The change is
> relatively simply as the way has been paved by drm_bridge support
> already. In addition to looking up, attaching to and detaching from the
> panel, we only need to add panel support in the connector .get_modes()
> handler, take connector bus flags (set by the panel) into account, and
> enable/disable the panel in the encoder enable/disable operations
> handlers.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Sebastian Reichel 
> ---

Tested-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/base.c   | 12 ---
>  drivers/gpu/drm/omapdrm/dss/omapdss.h|  1 +
>  drivers/gpu/drm/omapdrm/dss/output.c |  7 +++-
>  drivers/gpu/drm/omapdrm/omap_connector.c |  9 ++
>  drivers/gpu/drm/omapdrm/omap_drv.c   | 15 -
>  drivers/gpu/drm/omapdrm/omap_encoder.c   | 41 
>  6 files changed, 65 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/base.c 
> b/drivers/gpu/drm/omapdrm/dss/base.c
> index 09c9f2971aa2..3c088cd2ceab 100644
> --- a/drivers/gpu/drm/omapdrm/dss/base.c
> +++ b/drivers/gpu/drm/omapdrm/dss/base.c
> @@ -157,7 +157,8 @@ struct omap_dss_device *omapdss_device_next_output(struct 
> omap_dss_device *from)
>   goto done;
>   }
>  
> - if (dssdev->id && (dssdev->next || dssdev->bridge))
> + if (dssdev->id &&
> + (dssdev->next || dssdev->bridge || dssdev->panel))
>   goto done;
>   }
>  
> @@ -192,10 +193,11 @@ int omapdss_device_connect(struct dss_device *dss,
>   if (!dst) {
>   /*
>* The destination is NULL when the source is connected to a
> -  * bridge instead of a DSS device. Stop here, we will attach the
> -  * bridge later when we will have a DRM encoder.
> +  * bridge or panel instead of a DSS device. Stop here, we will
> +  * attach the bridge or panel later when we will have a DRM
> +  * encoder.
>*/
> - return src && src->bridge ? 0 : -EINVAL;
> + return src && (src->bridge || src->panel) ? 0 : -EINVAL;
>   }
>  
>   if (omapdss_device_is_connected(dst))
> @@ -223,7 +225,7 @@ void omapdss_device_disconnect(struct omap_dss_device 
> *src,
>   dst ? dev_name(dst->dev) : "NULL");
>  
>   if (!dst) {
> - WARN_ON(!src->bridge);
> + WARN_ON(!src->bridge && !src->panel);
>   return;
>   }
>  
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index f47e9b94288f..0c734d1f89e1 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -411,6 +411,7 @@ struct omap_dss_device {
>   struct dss_device *dss;
>   struct omap_dss_device *next;
>   struct drm_bridge *bridge;
> + struct drm_panel *panel;
>  
>   struct list_head list;
>  
> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c 
> b/drivers/gpu/drm/omapdrm/dss/output.c
> index 2a53025c2fde..10a9ee5cdc61 100644
> --- a/drivers/gpu/drm/omapdrm/dss/output.c
> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> @@ -22,6 +22,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #include "dss.h"
>  #include "omapdss.h"
>  
> @@ -37,6 +39,9 @@ int omapdss_device_init_output(struct omap_dss_device *out)
>  
>   out->next = omapdss_find_device_by_node(remote_node);
>   out->bridge = of_drm_find_bridge(remote_node);
> + out->panel = of_drm_find_panel(remote_node);
> + if (IS_ERR(out->panel))
> + out->panel = NULL;
>  
>   of_node_put(remote_node);
>  
> @@ -47,7 +52,7 @@ int omapdss_device_init_output(struct omap_dss_device *out)
>   return -EINVAL;
>   }
>  
> - return out->next || out->bridge ? 0 : -EPROBE_DEFER;
> + return out->next || out->bridge || out->panel ? 0 : -EPROBE_DEFER;
>  }
>  EXPORT_SYMBOL(omapdss_device_init_output);
>  
> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
> b/drivers/gpu/drm/omapdrm/omap_connector.c
> index f528baa80114..2da16f00cfae 100644
> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "omap_drv.h"
>

Re: [PATCH v2 29/49] drm/omap: Pass drm_display_mode to .check_timings() and .set_timings()

[Sebastian Reichel]

Hi,

On Fri, Jan 11, 2019 at 05:51:00AM +0200, Laurent Pinchart wrote:
> The omap_dss_device .check_timings() and .set_timings() operations
> operate on struct videomode, while the DRM API operates on struct
> drm_display_mode. This forces conversion from to videomode in the
> callers. While that's not a problem per se, it creates a difference with
> the drm_bridge API.
> 
> Replace the videomode parameter to the .check_timings() and
> .set_timings() operations with a drm_display_mode. This pushed the
> conversion to videomode down to the DSS devices in some cases. If needed
> they will be converted to operate on drm_display_mode natively.
> 
> Signed-off-by: Laurent Pinchart 
> Tested-by: Sebastian Reichel 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  .../gpu/drm/omapdrm/displays/panel-dsi-cm.c   |  8 +++---
>  drivers/gpu/drm/omapdrm/dss/dpi.c | 16 +--
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c   |  6 ++--
>  drivers/gpu/drm/omapdrm/dss/hdmi5.c   |  6 ++--
>  drivers/gpu/drm/omapdrm/dss/omapdss.h |  4 +--
>  drivers/gpu/drm/omapdrm/dss/sdi.c | 17 +--
>  drivers/gpu/drm/omapdrm/dss/venc.c| 28 +--
>  drivers/gpu/drm/omapdrm/omap_connector.c  |  7 ++---
>  drivers/gpu/drm/omapdrm/omap_encoder.c|  2 +-
>  9 files changed, 46 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> index ce812094177c..d9f10f41ddfb 100644
> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> @@ -1127,20 +1127,20 @@ static int dsicm_get_modes(struct omap_dss_device 
> *dssdev,
>  }
>  
>  static int dsicm_check_timings(struct omap_dss_device *dssdev,
> -struct videomode *vm)
> +struct drm_display_mode *mode)
>  {
>   struct panel_drv_data *ddata = to_panel_data(dssdev);
>   int ret = 0;
>  
> - if (vm->hactive != ddata->vm.hactive)
> + if (mode->hdisplay != ddata->vm.hactive)
>   ret = -EINVAL;
>  
> - if (vm->vactive != ddata->vm.vactive)
> + if (mode->vdisplay != ddata->vm.vactive)
>   ret = -EINVAL;
>  
>   if (ret) {
>   dev_warn(dssdev->dev, "wrong resolution: %d x %d",
> -  vm->hactive, vm->vactive);
> +  mode->hdisplay, mode->vdisplay);
>   dev_warn(dssdev->dev, "panel resolution: %d x %d",
>ddata->vm.hactive, ddata->vm.vactive);
>   }
> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
> b/drivers/gpu/drm/omapdrm/dss/dpi.c
> index 0db01cadf09f..0cb3cb72f15f 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -459,7 +459,7 @@ static void dpi_display_disable(struct omap_dss_device 
> *dssdev)
>  }
>  
>  static void dpi_set_timings(struct omap_dss_device *dssdev,
> - const struct videomode *vm)
> + const struct drm_display_mode *mode)
>  {
>   struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
>  
> @@ -467,13 +467,13 @@ static void dpi_set_timings(struct omap_dss_device 
> *dssdev,
>  
>   mutex_lock(&dpi->lock);
>  
> - dpi->vm = *vm;
> + drm_display_mode_to_videomode(mode, &dpi->vm);
>  
>   mutex_unlock(&dpi->lock);
>  }
>  
>  static int dpi_check_timings(struct omap_dss_device *dssdev,
> -  struct videomode *vm)
> +  struct drm_display_mode *mode)
>  {
>   struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
>   int lck_div, pck_div;
> @@ -482,20 +482,20 @@ static int dpi_check_timings(struct omap_dss_device 
> *dssdev,
>   struct dpi_clk_calc_ctx ctx;
>   bool ok;
>  
> - if (vm->hactive % 8 != 0)
> + if (mode->hdisplay % 8 != 0)
>   return -EINVAL;
>  
> - if (vm->pixelclock == 0)
> + if (mode->clock == 0)
>   return -EINVAL;
>  
>   if (dpi->pll) {
> - ok = dpi_pll_clk_calc(dpi, vm->pixelclock, &ctx);
> + ok = dpi_pll_clk_calc(dpi, mode->clock * 1000, &ctx);
>   if (!ok)
>   return -EINVAL;
>  
>   fck = ctx.pll_cinfo.clkout[ctx.clkout_idx];
>   } else {
> - ok = dpi_dss_clk_calc(dpi, vm->pixelclock, &ctx);
> + ok = dpi_dss_clk_calc(dpi, mode->clock * 1000, &ctx);
> 

Re: [PATCH v2 48/49] drm/omap: Remove TFP410 and DVI connector drivers

[Sebastian Reichel]

Hi,

On Fri, Jan 11, 2019 at 05:51:19AM +0200, Laurent Pinchart wrote:
> Those components are supported by the drm_bridge infrastructure, remove
> the omapdrm-specific driver.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Sebastian Reichel 
> ---

Tested-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/displays/Kconfig  |  11 -
>  drivers/gpu/drm/omapdrm/displays/Makefile |   2 -
>  .../gpu/drm/omapdrm/displays/connector-dvi.c  | 293 --
>  .../gpu/drm/omapdrm/displays/encoder-tfp410.c | 140 -
>  .../gpu/drm/omapdrm/dss/omapdss-boot-init.c   |   2 -
>  5 files changed, 448 deletions(-)
>  delete mode 100644 drivers/gpu/drm/omapdrm/displays/connector-dvi.c
>  delete mode 100644 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
> 
> diff --git a/drivers/gpu/drm/omapdrm/displays/Kconfig 
> b/drivers/gpu/drm/omapdrm/displays/Kconfig
> index a349cb61961e..38d066ac966e 100644
> --- a/drivers/gpu/drm/omapdrm/displays/Kconfig
> +++ b/drivers/gpu/drm/omapdrm/displays/Kconfig
> @@ -6,23 +6,12 @@ config DRM_OMAP_ENCODER_OPA362
> Driver for OPA362 external analog TV amplifier controlled
> through a GPIO.
>  
> -config DRM_OMAP_ENCODER_TFP410
> -tristate "TFP410 DPI to DVI Encoder"
> - help
> -   Driver for TFP410 DPI to DVI encoder.
> -
>  config DRM_OMAP_ENCODER_TPD12S015
>  tristate "TPD12S015 HDMI ESD protection and level shifter"
>   help
> Driver for TPD12S015, which offers HDMI ESD protection and level
> shifting.
>  
> -config DRM_OMAP_CONNECTOR_DVI
> -tristate "DVI Connector"
> - depends on I2C
> - help
> -   Driver for a generic DVI connector.
> -
>  config DRM_OMAP_CONNECTOR_HDMI
>  tristate "HDMI Connector"
>   help
> diff --git a/drivers/gpu/drm/omapdrm/displays/Makefile 
> b/drivers/gpu/drm/omapdrm/displays/Makefile
> index d99659e1381b..da1d5321ef50 100644
> --- a/drivers/gpu/drm/omapdrm/displays/Makefile
> +++ b/drivers/gpu/drm/omapdrm/displays/Makefile
> @@ -1,8 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  obj-$(CONFIG_DRM_OMAP_ENCODER_OPA362) += encoder-opa362.o
> -obj-$(CONFIG_DRM_OMAP_ENCODER_TFP410) += encoder-tfp410.o
>  obj-$(CONFIG_DRM_OMAP_ENCODER_TPD12S015) += encoder-tpd12s015.o
> -obj-$(CONFIG_DRM_OMAP_CONNECTOR_DVI) += connector-dvi.o
>  obj-$(CONFIG_DRM_OMAP_CONNECTOR_HDMI) += connector-hdmi.o
>  obj-$(CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV) += connector-analog-tv.o
>  obj-$(CONFIG_DRM_OMAP_PANEL_DPI) += panel-dpi.o
> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c 
> b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> deleted file mode 100644
> index fa3a69bf8a04..
> --- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> +++ /dev/null
> @@ -1,293 +0,0 @@
> -/*
> - * Generic DVI Connector driver
> - *
> - * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> - * Author: Tomi Valkeinen 
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License version 2 as published 
> by
> - * the Free Software Foundation.
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include 
> -
> -#include "../dss/omapdss.h"
> -
> -struct panel_drv_data {
> - struct omap_dss_device dssdev;
> -
> - struct i2c_adapter *i2c_adapter;
> -
> - struct gpio_desc *hpd_gpio;
> -
> - void (*hpd_cb)(void *cb_data, enum drm_connector_status status);
> - void *hpd_cb_data;
> - bool hpd_enabled;
> - /* mutex for hpd fields above */
> - struct mutex hpd_lock;
> -};
> -
> -#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
> -
> -static int dvic_connect(struct omap_dss_device *src,
> - struct omap_dss_device *dst)
> -{
> - return 0;
> -}
> -
> -static void dvic_disconnect(struct omap_dss_device *src,
> - struct omap_dss_device *dst)
> -{
> -}
> -
> -static int dvic_ddc_read(struct i2c_adapter *adapter,
> - unsigned char *buf, u16 count, u8 offset)
> -{
> - int r, retries;
> -
> - for (retries = 3; retries > 0; retries--) {
> - struct i2c_msg msgs[] = {
> - {
> - .addr   = DDC_ADDR,
> - .flags  = 0,
> - .len= 1,
> - .buf= &offset,
> - }, {
> - .addr   = DDC_ADDR,
> -  

Re: [PATCH v2 45/49] drm/omap: Add support for drm_bridge

[Sebastian Reichel]

Hi,

On Fri, Jan 11, 2019 at 05:51:16AM +0200, Laurent Pinchart wrote:
> Hook up drm_bridge support in the omapdrm driver. Despite the recent
> extensive preparation work, this is a rather intrusive change, as the
> management of outputs needs to be adapted through the driver to handle
> both omap_dss_device and drm_bridge.
> 
> Connector creation is skipped when using a drm_bridge, as the bridge
> creates the connector internally. This creates issues with systems that
> split connector operations (such as modes retrieval and hot-plug
> detection) across different bridges. These systems can't be supported
> using drm_bridge for now (their support through the omap_dss_device
> infrastructure is not affected), this will be fixed in subsequent
> changes.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Sebastian Reichel 
> ---
> Changes since v1:
> 
> - Fix typo in function name (updata -> update)
> ---

This patch drops all usage of pipe->display. It should probably also
remove the struct entry to simplify things and avoid stupid mistakes
when somebody rebases patches (*cough*).

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/49] omapdrm: drm_bridge and drm_panel support

[Sebastian Reichel]

Hi,

On Fri, Jan 11, 2019 at 05:50:31AM +0200, Laurent Pinchart wrote:
> Hello,
> 
> This patch series consolidates the three pending series for the omapdrm and
> tfp410 drivers that all together implement drm_bridge and drm_panel support
> for omapdrm.
> 
> The series starts with four patches not posted before as part of this work.
> The first patch (01/49) has been sitting in my tree as a base for the omapdrm
> rework for such a long time that I have included it here. The next three
> patches (02/49 to 04/49) have been written by Tomi to fix DSI regression
> introduced by previous omapdrm rework, and are included here to start with a
> cleaner base.
> 
> The following 30 patches (05/49 to 34/49) have previously been posted as part
> of "[PATCH 00/29] omapdrm: Last large refactoring for drm_bridge transition"
> [1]. They complete the extensive rework of the omapdrm and omapdss drivers to
> prepare for the transition to drm_bridge.
> 
> The next 7 patches (35/49 to 41/49) have been previously posted as part of
> "[PATCH v2 0/2] Clarify display info PIXDATA bus flags" [2] and
> "[PATCH 0/5] drm: ti-tfp410 improvements" [3]. They improve the ti-tfp410
> driver with new features required by omapdrm and currently implemented in the
> omapdrm custom tfp410 driver.
> 
> The next 2 patches (42/49 and 43/49) are new and add missing DT bindings for
> the panel used by the TI AM57xx EVM.
> 
> The last 6 patches (44/49 to 49/49) have previously been posted as part of
> "[PATCH 0/6] omapdrm: drm_bridge and drm_panel support" [4]. They hook up
> support for drm_bridge and drm_panel in the omapdrm driver, and remove the
> omapdrm-specific tfp410 and panel-dpi drivers.
> 
> All patches have been rebased on top of v5.0-rc1 and review comments have been
> incorporated. Please see individual patches for changelogs. The whole series
> is available from
> 
>   git://linuxtv.org/pinchartl/media.git omapdrm/bridge/next
> 
> [1] https://www.spinics.net/lists/dri-devel/msg198993.html
> [2] https://lists.freedesktop.org/archives/dri-devel/2018-December/199204.html
> [3] https://www.spinics.net/lists/dri-devel/msg199245.html
> [4] https://www.spinics.net/lists/dri-devel/msg199524.html

I rebased the series to 5.0-rc5, (which contains some DSI fixes).
This worked without any manual merge conflicts :). I also rebased
rebased the DSI command mode patchset on top of it. Everything seems
to work fine on Droid 4, so the series is

Tested-by: Sebastian Reichel 

I pushed out the rebased branch with DSI support here:

git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git 
omapdrm/bridge/next-with-dsi

-- Sebastian


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 47/49] drm/omap: Whitelist DT nodes to fixup with omapdss, prefix

[Sebastian Reichel]

Hi,

On Fri, Jan 11, 2019 at 05:51:18AM +0200, Laurent Pinchart wrote:
> The omapdss driver patches DT at runtime to prepend an "omapdss," prefix
> to the compatible string of all encoders, panels and connectors. This
> mechanism ensures they get bound to the omapdss-specific drivers instead
> of generic drivers.
> 
> Now that we have drm_bridge support in omapdrm, we need to selectively
> disable this mechanism. Add a whitelist of compatible strings to patch,
> and fill it with all the devices we support. They will be removed one by
> one once corresponding drm_bridge drivers become available and get
> successfully tested with omapdrm.
> 
> The omapdss components load check code is updated accordingly to ignore
> devices managed by external bridge drivers.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Sebastian Reichel 
> ---

Tested-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/base.c| 20 +++---
>  .../gpu/drm/omapdrm/dss/omapdss-boot-init.c   | 21 ++-
>  2 files changed, 33 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/base.c 
> b/drivers/gpu/drm/omapdrm/dss/base.c
> index 3c088cd2ceab..f8dad99013e8 100644
> --- a/drivers/gpu/drm/omapdrm/dss/base.c
> +++ b/drivers/gpu/drm/omapdrm/dss/base.c
> @@ -303,6 +303,7 @@ struct omapdss_comp_node {
>   struct list_head list;
>   struct device_node *node;
>   bool dss_core_component;
> + const char *compat;
>  };
>  
>  static bool omapdss_list_contains(const struct device_node *node)
> @@ -320,13 +321,20 @@ static bool omapdss_list_contains(const struct 
> device_node *node)
>  static void omapdss_walk_device(struct device *dev, struct device_node *node,
>   bool dss_core)
>  {
> + struct omapdss_comp_node *comp;
>   struct device_node *n;
> - struct omapdss_comp_node *comp = devm_kzalloc(dev, sizeof(*comp),
> -   GFP_KERNEL);
> + const char *compat;
> + int ret;
> +
> + ret = of_property_read_string(node, "compatible", &compat);
> + if (ret < 0)
> + return;
>  
> + comp = devm_kzalloc(dev, sizeof(*comp), GFP_KERNEL);
>   if (comp) {
>   comp->node = node;
>   comp->dss_core_component = dss_core;
> + comp->compat = compat;
>   list_add(&comp->list, &omapdss_comp_list);
>   }
>  
> @@ -366,12 +374,8 @@ void omapdss_gather_components(struct device *dev)
>  
>   omapdss_walk_device(dev, dev->of_node, true);
>  
> - for_each_available_child_of_node(dev->of_node, child) {
> - if (!of_find_property(child, "compatible", NULL))
> - continue;
> -
> + for_each_available_child_of_node(dev->of_node, child)
>   omapdss_walk_device(dev, child, true);
> - }
>  }
>  EXPORT_SYMBOL(omapdss_gather_components);
>  
> @@ -379,6 +383,8 @@ static bool omapdss_component_is_loaded(struct 
> omapdss_comp_node *comp)
>  {
>   if (comp->dss_core_component)
>   return true;
> + if (!strstarts(comp->compat, "omapdss,"))
> + return true;
>   if (omapdss_device_is_registered(comp->node))
>   return true;
>  
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c 
> b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
> index 3bfb95d230e0..309b7b453e98 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
> @@ -184,6 +184,25 @@ static const struct of_device_id omapdss_of_match[] 
> __initconst = {
>   {},
>  };
>  
> +static const struct of_device_id omapdss_of_fixups_whitelist[] __initconst = 
> {
> + { .compatible = "composite-video-connector" },
> + { .compatible = "dvi-connector" },
> + { .compatible = "hdmi-connector" },
> + { .compatible = "lgphilips,lb035q02" },
> + { .compatible = "nec,nl8048hl11" },
> + { .compatible = "panel-dpi" },
> + { .compatible = "panel-dsi-cm" },
> + { .compatible = "sharp,ls037v7dw01" },
> + { .compatible = "sony,acx565akm" },
> + { .compatible = "svideo-connector" },
> + { .compatible = "ti,opa362" },
> + { .compatible = "ti,tfp410" },
> + { .compatible = "ti,tpd12s015" },
> + { .compatible = "toppoly,td028ttec1" },
> + { .compatible = "tpo,td028ttec1&qu