dri-devel June 2022

dri-devel@lists.freedesktop.org

332 participants
697 discussions

[PATCH v3] dt-bindings: display: bridge: sil, sii9022: Convert to json-schema
by Geert Uytterhoeven 06 Jun '22

06 Jun '22

Convert the Silicon Image sii902x HDMI bridge Device Tree binding documentation to json-schema. Add missing sil,sii9022-cpi and sil,sii9022-tpi compatible values. Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> --- v3: - Add comments clarifying CPI/TPI, - Improve wording, - Drop port@2, - Add port descriptions, - Add schema references to individual ports. v2: - Rework sil,i2s-data-lanes, - Add schema reference to ports. --- .../bindings/display/bridge/sii902x.txt | 78 ----------- .../bindings/display/bridge/sil,sii9022.yaml | 131 ++++++++++++++++++ 2 files changed, 131 insertions(+), 78 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/bridge/sii902x.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt b/Documentation/devicetree/bindings/display/bridge/sii902x.txt deleted file mode 100644 index 3bc760cc31cbbeee..0000000000000000 --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt +++ /dev/null @@ -1,78 +0,0 @@ -sii902x HDMI bridge bindings - -Required properties: - - compatible: "sil,sii9022" - - reg: i2c address of the bridge - -Optional properties: - - interrupts: describe the interrupt line used to inform the host - about hotplug events. - - reset-gpios: OF device-tree gpio specification for RST_N pin. - - iovcc-supply: I/O Supply Voltage (1.8V or 3.3V) - - cvcc12-supply: Digital Core Supply Voltage (1.2V) - - HDMI audio properties: - - #sound-dai-cells: <0> or <1>. <0> if only i2s or spdif pin - is wired, <1> if the both are wired. HDMI audio is - configured only if this property is found. - - sil,i2s-data-lanes: Array of up to 4 integers with values of 0-3 - Each integer indicates which i2s pin is connected to which - audio fifo. The first integer selects i2s audio pin for the - first audio fifo#0 (HDMI channels 1&2), second for fifo#1 - (HDMI channels 3&4), and so on. There is 4 fifos and 4 i2s - pins (SD0 - SD3). Any i2s pin can be connected to any fifo, - but there can be no gaps. E.g. an i2s pin must be mapped to - fifo#0 and fifo#1 before mapping a channel to fifo#2. Default - value is <0>, describing SD0 pin beiging routed to hdmi audio - fifo #0. - - clocks: phandle and clock specifier for each clock listed in - the clock-names property - - clock-names: "mclk" - Describes SII902x MCLK input. MCLK can be used to produce - HDMI audio CTS values. This property follows - Documentation/devicetree/bindings/clock/clock-bindings.txt - consumer binding. - - If HDMI audio is configured the sii902x device becomes an I2S - and/or spdif audio codec component (e.g a digital audio sink), - that can be used in configuring a full audio devices with - simple-card or audio-graph-card binding. See their binding - documents on how to describe the way the sii902x device is - connected to the rest of the audio system: - Documentation/devicetree/bindings/sound/simple-card.yaml - Documentation/devicetree/bindings/sound/audio-graph-card.yaml - Note: In case of the audio-graph-card binding the used port - index should be 3. - -Optional subnodes: - - video input: this subnode can contain a video input port node - to connect the bridge to a display controller output (See this - documentation [1]). - -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - hdmi-bridge@39 { - compatible = "sil,sii9022"; - reg = <0x39>; - reset-gpios = <&pioA 1 0>; - iovcc-supply = <&v3v3_hdmi>; - cvcc12-supply = <&v1v2_hdmi>; - - #sound-dai-cells = <0>; - sil,i2s-data-lanes = < 0 1 2 >; - clocks = <&mclk>; - clock-names = "mclk"; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - bridge_in: endpoint { - remote-endpoint = <&dc_out>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml b/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml new file mode 100644 index 0000000000000000..5a69547ad3d79667 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml @@ -0,0 +1,131 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/sil,sii9022.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silicon Image sii902x HDMI bridge + +maintainers: + - Boris Brezillon <bbrezillon(a)kernel.org> + +properties: + compatible: + oneOf: + - items: + - enum: + - sil,sii9022-cpi # CEC Programming Interface + - sil,sii9022-tpi # Transmitter Programming Interface + - const: sil,sii9022 + - const: sil,sii9022 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + description: Interrupt line used to inform the host about hotplug events. + + reset-gpios: + maxItems: 1 + + iovcc-supply: + description: I/O Supply Voltage (1.8V or 3.3V) + + cvcc12-supply: + description: Digital Core Supply Voltage (1.2V) + + '#sound-dai-cells': + enum: [ 0, 1 ] + description: | + <0> if only I2S or S/PDIF pin is wired, + <1> if both are wired. + HDMI audio is configured only if this property is found. + If HDMI audio is configured, the sii902x device becomes an I2S and/or + S/PDIF audio codec component (e.g. a digital audio sink), that can be + used in configuring full audio devices with simple-card or + audio-graph-card bindings. See their binding documents on how to describe + the way the + sii902x device is connected to the rest of the audio system: + Documentation/devicetree/bindings/sound/simple-card.yaml + Documentation/devicetree/bindings/sound/audio-graph-card.yaml + Note: In case of the audio-graph-card binding the used port index should + be 3. + + sil,i2s-data-lanes: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 4 + uniqueItems: true + items: + enum: [ 0, 1, 2, 3 ] + description: + Each integer indicates which I2S pin is connected to which audio FIFO. + The first integer selects the I2S audio pin for the first audio FIFO#0 + (HDMI channels 1&2), the second for FIFO#1 (HDMI channels 3&4), and so + on. There are 4 FIFOs and 4 I2S pins (SD0 - SD3). Any I2S pin can be + connected to any FIFO, but there can be no gaps. E.g. an I2S pin must be + mapped to FIFO#0 and FIFO#1 before mapping a channel to FIFO#2. The + default value is <0>, describing SD0 pin being routed to HDMI audio + FIFO#0. + + clocks: + maxItems: 1 + description: MCLK input. MCLK can be used to produce HDMI audio CTS values. + + clock-names: + const: mclk + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Parallel RGB input port + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: HDMI output port + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: Sound input port + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + hdmi-bridge@39 { + compatible = "sil,sii9022"; + reg = <0x39>; + reset-gpios = <&pioA 1 0>; + iovcc-supply = <&v3v3_hdmi>; + cvcc12-supply = <&v1v2_hdmi>; + + #sound-dai-cells = <0>; + sil,i2s-data-lanes = < 0 1 2 >; + clocks = <&mclk>; + clock-names = "mclk"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + bridge_in: endpoint { + remote-endpoint = <&dc_out>; + }; + }; + }; + }; + }; -- 2.25.1

2 2

[PATCH] drm/i2c: tda9950: Lower severity of log message about missing interrupts
by Mark Brown 06 Jun '22

06 Jun '22

The tda9950 driver prints an error message if it is instantiated without an interrupt being available since the device is non-functional in that case. Unfortunately due to packaging of tda9950 with tda998x series devices the tda998x driver unconditionally instantiates a tda9950 so systems with a tda998x configured without an interrupt will trigger this error message during boot if tda9950 support is available. Reduce the severity to debug level so this is less likely to be presented to end users, the information is still there for system integrators who run into problems. We could add a check for an interrupt to the tda998x driver instead but this feels better from an encapsulation point of view, there's still a log message to help anyone doing system integration. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- drivers/gpu/drm/i2c/tda9950.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c index 5b03fdd1eaa4..781d5665cd04 100644 --- a/drivers/gpu/drm/i2c/tda9950.c +++ b/drivers/gpu/drm/i2c/tda9950.c @@ -397,7 +397,7 @@ static int tda9950_probe(struct i2c_client *client, /* We must have an interrupt to be functional. */ if (client->irq <= 0) { - dev_err(&client->dev, "driver requires an interrupt\n"); + dev_dbg(&client->dev, "driver requires an interrupt\n"); return -ENXIO; } -- 2.30.2

2 1

[PATCH v1 0/2] Fix NOC fatal error if msm_drm_init() failed
by Kuogee Hsieh 06 Jun '22

06 Jun '22

system crash due to NOC fatal error if any module initialization faield during msm_drm_init() Kuogee Hsieh (2): drm/msm: enable msm irq after all initializations are done successfully at msm_drm_init() drm/msm/dp: check core_initialized before disable interrupts at dp_display_unbind() drivers/gpu/drm/msm/dp/dp_display.c | 3 ++- drivers/gpu/drm/msm/msm_drv.c | 29 ++++++----------------------- 2 files changed, 8 insertions(+), 24 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

1 3

[PATCH] MAINTAINERS: rectify entries for ARM DRM DRIVERS after dt conversion
by Lukas Bulwahn 06 Jun '22

06 Jun '22

The three commits: 36fd2a65bcaf ("dt-bindings: display: convert Arm HDLCD to DT schema") 0f6983509ea1 ("dt-bindings: display: convert Arm Komeda to DT schema") 2c8b082a3ab1 ("dt-bindings: display: convert Arm Mali-DP to DT schema") convert the arm display dt-bindings, arm,*.txt to arm,*.yaml, but miss to adjust its reference in MAINTAINERS. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about broken references. Repair these file references in ARM HDLCD DRM DRIVER, ARM KOMEDA DRM-KMS DRIVER and ARM MALI-DP DRM DRIVER. Signed-off-by: Lukas Bulwahn <lukas.bulwahn(a)gmail.com> --- Andre, please ack. Rob, Krzysztof, please pick this minor non-urgent clean-up patch in your -next dt tree. MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index ae685aaf8850..58e751b9346e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1510,7 +1510,7 @@ F: drivers/clocksource/arm_arch_timer.c ARM HDLCD DRM DRIVER M: Liviu Dudau <liviu.dudau(a)arm.com> S: Supported -F: Documentation/devicetree/bindings/display/arm,hdlcd.txt +F: Documentation/devicetree/bindings/display/arm,hdlcd.yaml F: drivers/gpu/drm/arm/hdlcd_* ARM INTEGRATOR, VERSATILE AND REALVIEW SUPPORT @@ -1545,7 +1545,7 @@ M: Mihail Atanassov <mihail.atanassov(a)arm.com> L: Mali DP Maintainers <malidp(a)foss.arm.com> S: Supported T: git git://anongit.freedesktop.org/drm/drm-misc -F: Documentation/devicetree/bindings/display/arm,komeda.txt +F: Documentation/devicetree/bindings/display/arm,komeda.yaml F: Documentation/gpu/komeda-kms.rst F: drivers/gpu/drm/arm/display/include/ F: drivers/gpu/drm/arm/display/komeda/ @@ -1567,7 +1567,7 @@ M: Brian Starkey <brian.starkey(a)arm.com> L: Mali DP Maintainers <malidp(a)foss.arm.com> S: Supported T: git git://anongit.freedesktop.org/drm/drm-misc -F: Documentation/devicetree/bindings/display/arm,malidp.txt +F: Documentation/devicetree/bindings/display/arm,malidp.yaml F: Documentation/gpu/afbc.rst F: drivers/gpu/drm/arm/ -- 2.17.1

3 2

[PATCH v3 0/8] Add a panel API to return panel orientation
by Hsin-Yi Wang 06 Jun '22

06 Jun '22

Panels usually call drm_connector_set_panel_orientation(), which is later than drm/kms driver calling drm_dev_register(). This leads to a WARN()[1]. The orientation property is known earlier. For example, some panels parse the property through device tree during probe. The series add a panel API drm_panel_get_orientation() for drm/kms drivers. The drivers can use the API to get panel's orientation, so they can call drm_connector_set_panel_orientation() before drm_dev_register(). Panel needs to implement .get_orientation callback to return the property. [1] https://patchwork.kernel.org/project/linux-mediatek/patch/20220530081910.39… Hsin-Yi Wang (8): drm/panel: Add an API drm_panel_get_orientation() to return panel orientation drm/panel: boe-tv101wum-nl6: Implement .get_orientation callback drm/panel: panel-edp: Implement .get_orientation callback drm/panel: lvds: Implement .get_orientation callback drm/panel: panel-simple: Implement .get_orientation callback drm/panel: ili9881c: Implement .get_orientation callback drm/panel: elida-kd35t133: Implement .get_orientation callback drm/mediatek: Config orientation property if panel provides it drivers/gpu/drm/drm_panel.c | 8 ++++++++ drivers/gpu/drm/mediatek/mtk_dsi.c | 10 ++++++++++ drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 14 ++++++++++++++ drivers/gpu/drm/panel/panel-edp.c | 15 ++++++++++++++- drivers/gpu/drm/panel/panel-elida-kd35t133.c | 14 ++++++++++++++ drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 14 ++++++++++++++ drivers/gpu/drm/panel/panel-lvds.c | 14 ++++++++++++++ drivers/gpu/drm/panel/panel-simple.c | 16 +++++++++++++++- include/drm/drm_panel.h | 10 ++++++++++ 9 files changed, 113 insertions(+), 2 deletions(-) -- 2.36.1.255.ge46751e96f-goog

3 18

[PATCH] drm/ttm: fix missing NULL check in ttm_device_swapout
by Christian König 06 Jun '22

06 Jun '22

Resources about to be destructed are not tied to BOs any more. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/ttm/ttm_device.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c index a0562ab386f5..e7147e304637 100644 --- a/drivers/gpu/drm/ttm/ttm_device.c +++ b/drivers/gpu/drm/ttm/ttm_device.c @@ -156,8 +156,12 @@ int ttm_device_swapout(struct ttm_device *bdev, struct ttm_operation_ctx *ctx, ttm_resource_manager_for_each_res(man, &cursor, res) { struct ttm_buffer_object *bo = res->bo; - uint32_t num_pages = PFN_UP(bo->base.size); + uint32_t num_pages; + if (!bo) + continue; + + num_pages = PFN_UP(bo->base.size); ret = ttm_bo_swapout(bo, ctx, gfp_flags); /* ttm_bo_swapout has dropped the lru_lock */ if (!ret) -- 2.25.1

2 4

[PATCH 1/3] drm/komeda - Add legacy FB support so VT's work as expected
by carsten.haitzler＠foss.arm.com 06 Jun '22

06 Jun '22

From: Carsten Haitzler <carsten.haitzler(a)arm.com> The komeda driver doesn't come up with a visible text (FB) mode VT by default as it was missing legacy FB support. It's useful to have a working text VT on a system for debug and general usability, so enable it. You can always toggle CONFIG_FRAMEBUFFER_CONSOLE. Signed-off-by: Carsten Haitzler <carsten.haitzler(a)arm.com> --- drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c index e7933930a657..c0c7933a9631 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c @@ -9,6 +9,7 @@ #include <linux/platform_device.h> #include <linux/component.h> #include <linux/pm_runtime.h> +#include <drm/drm_fb_helper.h> #include <drm/drm_of.h> #include "komeda_dev.h" #include "komeda_kms.h" @@ -71,6 +72,7 @@ static int komeda_bind(struct device *dev) } dev_set_drvdata(dev, mdrv); + drm_fbdev_generic_setup(&mdrv->kms->base, 32); return 0; -- 2.32.0

1 2

Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID block count and size helpers")
by Jani Nikula 06 Jun '22

06 Jun '22

On Mon, 30 May 2022, Arnd Bergmann <arnd(a)arndb.de> wrote: > On Mon, May 30, 2022 at 3:10 PM Jani Nikula <jani.nikula(a)intel.com> wrote: >> > >> > I think in general, most __packed annotations we have in the kernel are >> > completely pointless because they do not change the structure layout on >> > any architecture but instead just make member access slower on >> >> Please explain. >> >> They are used quite a bit for parsing blob data, or >> serialization/deserialization, like in the EDID case at hand. Try >> removing __attribute__((packed)) from include/drm/drm_edid.h and see the >> sizeof(struct edid) on any architecture. > > The annotations for edid are completely correct and necessary. However > other driver authors just slap __packed annotations on any structure > even if the layout is not fixed at all like: Right. Thanks for the examples. > struct my_driver_priv { > struct device dev; > u8 causes_misalignment; > spinlock_t lock; > atomic_t counter; > } __packed; /* this annotation is harmful because it breaks the atomics */ I wonder if this is something that could be caught with coccinelle. Or sparse. Are there any cases where this combo is necessary? (I can't think of any, but it's a low bar. ;) Cc: Julia. > or if the annotation does not change the layout like > > struct my_dma_descriptor { > __le64 address; > __le64 length; > } __packed; /* does not change layout but makes access slow on some > architectures */ Why is this the case, though? I'd imagine the compiler could figure this out. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center

7 11

[RFC PATCH 0/1] KUnit tests for drm_format_helper
by José Expósito 06 Jun '22

06 Jun '22

Hello everyone, Recently Javier added a new task in the ToDo list [1] to create KUnit tests for the functions present in "drm_format_helper". This patch, marked as RFC to start the conversation, includes tests for "drm_fb_xrgb8888_to_rgb332". Since the conversion functions present in "drm_format_helper" convert from XRGB8888 to another format, my plan is to create a set of XRGB8888 data to test all the available conversions. To illustrate it with an example, the code present in this patch: { .name = "Single pixel source", .pitch = 1 * 4, .dst_pitch = 0, .clip = CLIP(0, 0, 1, 1), .xrgb8888 = { 0x01FF0000 }, .expected = { 0xE0 }, } In a follow up patch, should look like: { .name = "Single pixel source", .pitch = 1 * 4, .clip = CLIP(0, 0, 1, 1), .xrgb8888 = { 0x01FF0000 }, .expected = { { .dst_format = DRM_FORMAT_RGB332, .dst_pitch = 0, .conv_func = drm_fb_xrgb8888_to_rgb332, .result = { 0xE0 }, }, { ... }, }, } What is tested? - Different values for the X in XRGB8888 to make sure it is ignored - Different clip values: Single pixel and full and partial buffer - Well know colors: White, black, red, green, blue, magenta, yellow and cyan - Other colors: Randomly picked - Destination pitch What is NOT tested? - NULL destination buffer: Because there is not validation in place - Out of bounds destination buffer: The size of the buffer is not checked. The conversion function could cause out of bound errors - Out of bounds source buffer: Similary to the destination buffer, the source buffer is read without checking its size - Invalid clip values: Because there is no clip validation. Example: clip out of or bigger than the source buffer - Invalid destination pitch: A dst_pitch < (clip->width * dst_pixsize) could cause issues. - "Big" source buffers. I don't know if this kind of tests could be of interest How to run the tests? My .kunitconfig: CONFIG_KUNIT=y CONFIG_DRM=y CONFIG_DRM_FORMAR_HELPER_TEST=y $ ./tools/testing/kunit/kunit.py run --arch=x86_64 Feedback? It'd be great to know your ideas about what else we could test, if you think that we should make the functions safer by checking the buffers and clip sizes or anything else. Thanks a lot, José Expósito [1] https://cgit.freedesktop.org/drm/drm-misc/commit/?id=596c35b1440e José Expósito (1): drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb332() drivers/gpu/drm/Kconfig | 12 ++ drivers/gpu/drm/Makefile | 3 + drivers/gpu/drm/drm_format_helper_test.c | 166 +++++++++++++++++++++++ 3 files changed, 181 insertions(+) create mode 100644 drivers/gpu/drm/drm_format_helper_test.c -- 2.25.1

5 14

[PATCH 1/3] dt-bindings: display: simple: add support for Samsung LTL101AL01
by Martin Jücker 06 Jun '22

06 Jun '22

Add the Samsung LTL101AL01 WXGA LCD panel to the list. Signed-off-by: Martin Jücker <martin.juecker(a)gmail.com> --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 1eb9dd4f8f58..9501b5a3c011 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -270,6 +270,8 @@ properties: - samsung,atna33xc20 # Samsung 12.2" (2560x1600 pixels) TFT LCD panel - samsung,lsn122dl01-c01 + # Samsung Electronics 10.1" WXGA (1280x800) TFT LCD panel + - samsung,ltl101al01 # Samsung Electronics 10.1" WSVGA TFT LCD panel - samsung,ltn101nt05 # Samsung Electronics 14" WXGA (1366x768) TFT LCD panel -- 2.25.1

2 4

← Newer
1
...
57
58
59
60
61
62
63
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2022