[PATCH v15 06/29] drm/tests: Add output bpc tests

2024-05-27 Thread Maxime Ripard
Now that we're tracking the output bpc count in the connector state, let's add a few tests to make sure it works as expected. Reviewed-by: Dave Stevenson Reviewed-by: Dmitry Baryshkov Signed-off-by: Maxime Ripard --- drivers/gpu/drm/Kconfig| 1 +

[PATCH v15 02/29] drm/tests: connector: Add tests for drmm_connector_hdmi_init

2024-05-27 Thread Maxime Ripard
We just introduced a new initialization function for our connectors, so let's build a kunit test suite for it as well. Reviewed-by: Dave Stevenson Reviewed-by: Dmitry Baryshkov Signed-off-by: Maxime Ripard --- drivers/gpu/drm/tests/drm_connector_test.c | 123 + 1

[PATCH v15 05/29] drm/mode_object: Export drm_mode_obj_find_prop_id for tests

2024-05-27 Thread Maxime Ripard
We'll need to use drm_mode_obj_find_prop_id() for kunit tests to make sure a given property has been properly created. Let's export it for tests only. Reviewed-by: Dmitry Baryshkov Signed-off-by: Maxime Ripard --- drivers/gpu/drm/drm_mode_object.c | 1 + 1 file changed, 1 insertion(+) diff

[PATCH v15 03/29] drm/connector: hdmi: Create an HDMI sub-state

2024-05-27 Thread Maxime Ripard
The next features we will need to share across drivers will need to store some parameters for drivers to use, such as the selected output format. Let's create a new connector sub-state dedicated to HDMI controllers, that will eventually store everything we need. Reviewed-by: Dave Stevenson

[PATCH v15 04/29] drm/connector: hdmi: Add output BPC to the connector state

2024-05-27 Thread Maxime Ripard
We'll add automatic selection of the output BPC in a following patch, but let's add it to the HDMI connector state already. Reviewed-by: Dave Stevenson Reviewed-by: Dmitry Baryshkov Signed-off-by: Maxime Ripard --- drivers/gpu/drm/display/drm_hdmi_state_helper.c | 20

[PATCH v15 00/29] drm/connector: Create HDMI Connector infrastructure

2024-05-27 Thread Maxime Ripard
- Mention explicitly (and in the logs) that YUV420 isn't supported for now - Fix warning when running the bpc test - Change the order of the drm_mode_obj_find_prop_id export patch - Fix some sun4i changes having made their way into the rockchip patch - Drop spurious Broadcast RGB documentation - L

[PATCH v15 01/29] drm/connector: Introduce an HDMI connector initialization function

2024-05-27 Thread Maxime Ripard
A lot of the various HDMI drivers duplicate some logic that depends on the HDMI spec itself and not really a particular hardware implementation. Output BPC or format selection, infoframe generation are good examples of such areas. This creates a lot of boilerplate, with a lot of variations,

[PATCH] drm: renesas: rcar-du: Add drm_panic support for non-vsp

2024-05-27 Thread Geert Uytterhoeven
Add support for the drm_panic module for DU variants not using the VSP-compositor, to display a message on the screen when a kernel panic occurs. Signed-off-by: Geert Uytterhoeven --- Tested on Koelsch (R-Car M2-W). Support for DU variants using the VSP-compositor is more convoluted, and left

[PATCH] drm: renesas: shmobile: Add drm_panic support

2024-05-27 Thread Geert Uytterhoeven
Add support for the drm_panic module, which displays a message on the screen when a kernel panic occurs. Signed-off-by: Geert Uytterhoeven --- Tested on Armadillo-800-EVA. --- drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-)

Re: [PATCH v14 17/28] drm/connector: hdmi: Add Broadcast RGB property

2024-05-27 Thread Maxime Ripard
6:235"" }",Connector,"When this property is set to Limited > > > > 16:235 and CTM is set, the hardware will be programmed with the result > > > > of the multiplication of CTM by the limited range matrix to ensure the > > > > pixels norm

Re: [PATCH 1/2] string: add mem_is_zero() helper to check if memory area is all zeros

2024-05-27 Thread Andy Shevchenko
On Mon, May 27, 2024 at 12:43 PM Jani Nikula wrote: > > Almost two thirds of the memchr_inv() usages check if the memory area is > all zeros, with no interest in where in the buffer the first non-zero > byte is located. Checking for !memchr_inv(s, 0, n) is also not very > intuitive or

Re: [PATCH 2/2] drm: use mem_is_zero() instead of !memchr_inv(s, 0, n)

2024-05-27 Thread Andy Shevchenko
On Mon, May 27, 2024 at 12:43 PM Jani Nikula wrote: > > Use the mem_is_zero() helper where possible. ... > - if (memchr_inv(guid, 0, 16) == NULL) { > + if (mem_is_zero(guid, 16)) { > tmp64 = get_jiffies_64(); > memcpy([0], , sizeof(u64)); >

[PATCH] drm/dp_mst: Fix all mstb marked as not probed after suspend/resume

2024-05-27 Thread Wayne Lin
[Why] After supend/resume, with topology unchanged, observe that link_address_sent of all mstb are marked as false even the topology probing is done without any error. It is caused by wrongly also include "ret == 0" case as a probing failure case. [How] Remove inappropriate checking conditions.

[PATCH 6/8] accel/habanalabs: separate nonce from max_size in cpucp_packet struct

2024-05-27 Thread Ofir Bitton
From: Dani Liberman In struct cpucp_packet both nonce and data_max_size members are in an union overlapping each other. This is a problem as they both are used in attestation and info_signed packets. The solution here is to move the nonce member to a different union under the same structure.

[PATCH 3/8] accel/habanalabs/gaudi2: align interrupt names to table

2024-05-27 Thread Ofir Bitton
From: Ariel Suller when reporting tpc events, the dcore and tpc in dcore should be reported and propagated, and not the generatl tpc number Signed-off-by: Ariel Suller Reviewed-by: Ofir Bitton --- .../gaudi2/gaudi2_async_ids_map_extended.h| 150 +- 1 file changed, 75

[PATCH 2/8] accel/habanalabs: check for errors after preboot is ready

2024-05-27 Thread Ofir Bitton
From: Farah Kassabri Driver should check and report any fatal errors detected by preboot, before it attempts to load the boot fit. Some errors may cause the driver to stop the boot process and mark the device as unusable. This check will allow the driver to fail and print the error reported by

[PATCH 1/8] accel/habanalabs: use msg_header instead of desc_header

2024-05-27 Thread Ofir Bitton
From: Igal Zeltser Struct comms_desc_header is deprecated and replaced by struct comms_msg_header. As a preparation for removing comms_desc_header from FW, all it's usage in code is replaced by comms_msg_header. Signed-off-by: Igal Zeltser Reviewed-by: Ofir Bitton ---

[PATCH 8/8] accel/habanalabs: move hl_eq_heartbeat_event_handle() to common code

2024-05-27 Thread Ofir Bitton
From: Tomer Tayar hl_eq_heartbeat_event_handle() doesn't have ASIC specific code, and therefore can be moved from Gaudi2-only code to common code, and possibly used for other ASICs. Signed-off-by: Tomer Tayar Reviewed-by: Ofir Bitton --- drivers/accel/habanalabs/common/device.c | 6

[PATCH 4/8] accel/habanalabs/gaudi2: revise return value handling in gaudi2_hbm_sei_handle_read_err()

2024-05-27 Thread Ofir Bitton
From: Tomer Tayar The return value in gaudi2_hbm_sei_handle_read_err() is boolean and not a bitmask, so there is need for "|= true". In addition, rename the 'rc' variable, as no "return code" is returned here but an indication if a hard reset is required. Signed-off-by: Tomer Tayar

[PATCH 5/8] accel/habanalabs/gaudi2: assume hard-reset by FW upon MC SEI severe error

2024-05-27 Thread Ofir Bitton
From: Tomer Tayar FW initiates a hard reset upon an MC SEI severe error. Align the driver to expect this reset and avoid accessing the device until the reset is done. Signed-off-by: Tomer Tayar Reviewed-by: Ofir Bitton --- drivers/accel/habanalabs/gaudi2/gaudi2.c | 4 ++-- 1 file changed, 2

[PATCH 7/8] accel/habanalabs: add an EQ size ASIC property

2024-05-27 Thread Ofir Bitton
From: Tomer Tayar Future supported ASICs might use the dynamic EQ mechanism with the firmware, and in that case the EQ size won't be equal to the default HL_EQ_SIZE_IN_BYTES value. Add an ASIC property to enable overriding this value. Signed-off-by: Tomer Tayar Reviewed-by: Ofir Bitton ---

[PATCH] accel/habanalabs/gaudi2: use single function to compare FW versions

2024-05-27 Thread Ofir Bitton
From: Ohad Sharabi Currently, the code contains 2 types of FW version comparison functions: - hl_is_fw_sw_ver_[below/equal_or_greater]() - gaudi2 specific function of the type gaudi2_is_fw_ver_[below/above]x_y_z() Moreover, some functions use the inner FW version which shuold be only stage

[PATCH 3/9] accel/habanalabs: restructure function that checks heartbeat received

2024-05-27 Thread Ofir Bitton
From: Ohad Sharabi The function returned an error code which isn't propagated up the stack (nor is it printed). The return value is only checked for =0 or !=0 which implies bool return value. The function signature is updated accordingly, renamed, and slightly refactored. Signed-off-by: Ohad

[PATCH 5/9] accel/habanalabs: no CPUCP prints on heartbeat failure

2024-05-27 Thread Ofir Bitton
From: Ohad Sharabi If we detected heartbet event while some daemon in the background send (via driver interface) CPUCP messages the dmesg will be flooded. Instead, a slight refactor in hl_fw_send_cpu_message() returns -EAGAIN when CPU is disabled (i.e. heartbeat failure) and only then. Later,

[PATCH 9/9] accel/habanalabs: add heartbeat debug info

2024-05-27 Thread Ofir Bitton
From: Farah Kassabri It is hard to debug the reason for heartbeat check failures. As an attempt to ease this task, this patch will provide more information when this failure happens. Heartbeat checks the communication with FW, so printing the CPU queue pi/ci and the counter of how many times

[PATCH 7/9] accel/habanalabs: expose server type in debugfs

2024-05-27 Thread Ofir Bitton
From: Tal Risin Exposing server type through debugfs to enable easier access via scripts. Signed-off-by: Tal Risin Reviewed-by: Ofir Bitton --- Documentation/ABI/testing/debugfs-driver-habanalabs | 6 ++ drivers/accel/habanalabs/common/debugfs.c | 5 + 2 files changed, 11

[PATCH 2/9] accel/habanalabs/gaudi2: update interrupts related headers

2024-05-27 Thread Ofir Bitton
From: Farah Kassabri Align the interrupts related headers to latest release. Signed-off-by: Farah Kassabri Signed-off-by: Ofir Bitton Reviewed-by: Ofir Bitton --- .../gaudi2/gaudi2_async_ids_map_extended.h| 94 +-- 1 file changed, 47 insertions(+), 47 deletions(-) diff

[PATCH 6/9] accel/habanalabs: use parent device for trace events

2024-05-27 Thread Ofir Bitton
From: Tomer Tayar Trace events might still be recorded after the accel device is released, while the device name is no longer available. Modify the trace functions to use the parent device instead, which is available at that point and still informative as the device name. Signed-off-by: Tomer

[PATCH 4/9] accel/habanalabs/gaudi2: align embedded specs headers

2024-05-27 Thread Ofir Bitton
Align embedded headers to latest release. Signed-off-by: Ofir Bitton --- .../habanalabs/include/gaudi2/gaudi2_fw_if.h | 27 + .../include/gaudi2/gaudi2_reg_map.h | 8 + include/linux/habanalabs/cpucp_if.h | 10 +--

[PATCH 1/9] accel/habanalabs: add device name to error print

2024-05-27 Thread Ofir Bitton
From: Dani Liberman The extra info will help in better traceability and debug. Signed-off-by: Dani Liberman Signed-off-by: Ofir Bitton Reviewed-by: Ofir Bitton --- drivers/accel/habanalabs/common/device.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git

[PATCH 8/9] accel/habanalabs: add device name to invalidation failure msg

2024-05-27 Thread Ofir Bitton
From: Ohad Sharabi This addition helps log parsers better define the error without the need to go back and search the device name on former log lines. Signed-off-by: Ohad Sharabi Reviewed-by: Ofir Bitton --- drivers/accel/habanalabs/common/mmu/mmu.c | 8 +--- 1 file changed, 5

Re: [PATCH v3] drm/nouveau/nvif: Avoid build error due to potential integer overflows

2024-05-27 Thread Danilo Krummrich
On 5/24/24 15:48, Guenter Roeck wrote: Trying to build parisc:allmodconfig with gcc 12.x or later results in the following build error. drivers/gpu/drm/nouveau/nvif/object.c: In function 'nvif_object_mthd': drivers/gpu/drm/nouveau/nvif/object.c:161:9: error: 'memcpy' accessing

Re: [PATCH v2] drm/i915: Increase FLR timeout from 3s to 9s

2024-05-27 Thread Andi Shyti
On Fri, May 24, 2024 at 10:07:44AM -0400, Rodrigo Vivi wrote: > On Fri, May 24, 2024 at 01:58:53AM +0200, Andi Shyti wrote: > > Following the guidelines it takes 3 seconds to perform an FLR > > reset. Let's give it a bit more slack because this time can > > change depending on the platform and on

Re: [PATCH] MAINTAINERS: remove myself as a VKMS maintainer

2024-05-27 Thread Maíra Canal
On 5/25/24 11:26, Melissa Wen wrote: I haven't been able to follow or review the work on the driver for some time now and I don't see the situation improving anytime soon. I'd like to continue being listed as a reviewer. Signed-off-by: Melissa Wen Acked-by: Maíra Canal Thanks for all the

Re: [PATCH v6 0/6] Link off between frames for edp

2024-05-27 Thread Hogander, Jouni
d to be enabled adaptive sync fixed refresh mode > where vmin = vmax = flipline, which will arise after cmmr feature > enablement. Currently existing code refactored and make compute- > config() > and enabling function ready. Will add enabling sequence in a separate > patch. For the

[PATCH 2/2] drm/panel-edp: Add more panels with conservative timings

2024-05-27 Thread Pin-yen Lin
Same as commit 7c8690d8fc80 ("drm/panel-edp: Add some panels with conservative timings"), the 3 panels added in this patch are used by Mediatek MT8173 Chromebooks and they used to work with the downstream v4.19 kernel without any specified delay. These panel IDs were found from in-fie

[PATCH 1/2] drm/panel-edp: Add support for several panels

2024-05-27 Thread Pin-yen Lin
Add support for the following models: AUO B140HTN02.0 BOE NT116WHM-N21 V4.1 BOE NT116WHM-N21 Signed-off-by: Pin-yen Lin --- drivers/gpu/drm/panel/panel-edp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c index

[PATCH 0/2] Support more panels used by MT8173 Chromebooks in edp-panel

2024-05-27 Thread Pin-yen Lin
This series contains 2 patches. The first patch adds more panel entries with the delays from the datasheets. The second patch adds 3 panel entries whose datasheets are not available. For more backgrounds of the rationale behind these conservative timings, please refer to the commit message

Re: [PATCH v2 4/5] drm/udl: Untangle .get_modes() and .detect_ctx()

2024-05-27 Thread Jani Nikula
On Fri, 10 May 2024, Thomas Zimmermann wrote: > Am 10.05.24 um 14:17 schrieb Jani Nikula: >>> + /* >>> +* The adapter sends all-zeros if no monitor has been >>> +* connected. We consider anything else a connection. >>> +*/ >>> + return memcmp(no_edid, hdr, 8) != 0; >> Nitpick,

Re: [PATCH v2 3/3] drm/loongson: Add dummy gpu driver as a subcomponent

2024-05-27 Thread Markus Elfring
… > loose coupling, but still be able to works togather to provide a unified use loose? should? work together?an? … > Add a dummy driver for the GPU, it functional as a subcomponent as well. is? Please improve your change

[PATCH 2/2] drm: use mem_is_zero() instead of !memchr_inv(s, 0, n)

2024-05-27 Thread Jani Nikula
Use the mem_is_zero() helper where possible. Conversion done using cocci: | @@ | expression PTR; | expression SIZE; | @@ | | <... | ( | - memchr_inv(PTR, 0, SIZE) == NULL | + mem_is_zero(PTR, SIZE) | | | - !memchr_inv(PTR, 0, SIZE) | + mem_is_zero(PTR, SIZE) | | | - memchr_inv(PTR, 0, SIZE) |

[PATCH 1/2] string: add mem_is_zero() helper to check if memory area is all zeros

2024-05-27 Thread Jani Nikula
Almost two thirds of the memchr_inv() usages check if the memory area is all zeros, with no interest in where in the buffer the first non-zero byte is located. Checking for !memchr_inv(s, 0, n) is also not very intuitive or discoverable. Add an explicit mem_is_zero() helper for this use case.

Re: [PATCH v14 17/28] drm/connector: hdmi: Add Broadcast RGB property

2024-05-27 Thread Dmitry Baryshkov
On Mon, May 27, 2024 at 11:02:13AM +0200, Maxime Ripard wrote: > Hi, > > Thanks again for that thorough review :) > > On Thu, May 23, 2024 at 01:22:56PM GMT, Dmitry Baryshkov wrote: > > On Tue, May 21, 2024 at 12:13:50PM +0200, Maxime Ripard wrote: > > > The i915 driver has a property to force

Re: [PATCH 1/2] dt-bindings: gpu: mali-bifrost: Add compatible for MT8188 SoC

2024-05-27 Thread Chen-Yu Tsai
On Mon, May 27, 2024 at 5:25 PM AngeloGioacchino Del Regno wrote: > > Add a compatible for the MediaTek MT8188 SoC, with an integrated > ARM Mali G57 MC3 (Valhall-JM) GPU. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 1 +

[PATCH 2/2] drm/panfrost: Add support for Mali on the MT8188 SoC

2024-05-27 Thread AngeloGioacchino Del Regno
MediaTek MT8188 has a Mali-G57 MC3 (Valhall-JM): add a new compatible and platform data using the same supplies and the same power domain lists as MT8183 (one regulator, three power domains). Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/panfrost/panfrost_drv.c | 9 + 1

[PATCH 1/2] dt-bindings: gpu: mali-bifrost: Add compatible for MT8188 SoC

2024-05-27 Thread AngeloGioacchino Del Regno
Add a compatible for the MediaTek MT8188 SoC, with an integrated ARM Mali G57 MC3 (Valhall-JM) GPU. Signed-off-by: AngeloGioacchino Del Regno --- Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 0/2] drm/panfrost: Add MT8188 support

2024-05-27 Thread AngeloGioacchino Del Regno
This series adds support for MT8188's Mali-G57 MC3. AngeloGioacchino Del Regno (2): dt-bindings: gpu: mali-bifrost: Add compatible for MT8188 SoC drm/panfrost: Add support for Mali on the MT8188 SoC .../devicetree/bindings/gpu/arm,mali-bifrost.yaml| 1 +

Re: [PATCH v2 2/3] drm/loongson: Introduce component framework support

2024-05-27 Thread Markus Elfring
… > However, the driver needs all of the subcompoments ready to use before subcomponents? … > goes with the PCIe master, sinch they has no dependency on exterinal since they have no dependencies on external? > modules. > >

Re: [PATCH v2 1/3] drm/loongson: Add a helper for creating child devices

2024-05-27 Thread Markus Elfring
> In some display subsystems, the functionality of a PCIe device may too might be? … > into child devices can helpful to … be? > Another benefit is that we could migrate the dependency on exterinal

Re: [PATCH v14 17/28] drm/connector: hdmi: Add Broadcast RGB property

2024-05-27 Thread Maxime Ripard
Hi, Thanks again for that thorough review :) On Thu, May 23, 2024 at 01:22:56PM GMT, Dmitry Baryshkov wrote: > On Tue, May 21, 2024 at 12:13:50PM +0200, Maxime Ripard wrote: > > The i915 driver has a property to force the RGB range of an HDMI output. > > The vc4 driver then implemented the same

[PATCH v6 3/6] drm/display: Add missing aux less alpm wake related bits

2024-05-27 Thread Animesh Manna
From: Jouni Högander eDP1.5 adds some more bits into DP_RECEIVER_ALPM_CAP and DP_RECEIVER_ALPM_CONFIG registers. Add definitions for these. Signed-off-by: Jouni Högander --- include/drm/display/drm_dp.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH v6 6/6] drm/i915/alpm: Add debugfs for LOBF

2024-05-27 Thread Animesh Manna
For validation purpose add debugfs for LOBF. v1: Initial version. v2: Add aux-wake/less info along with lobf status. [Jouni] Signed-off-by: Animesh Manna --- drivers/gpu/drm/i915/display/intel_alpm.c | 49 +++ drivers/gpu/drm/i915/display/intel_alpm.h | 2 +

[PATCH v6 5/6] drm/i915/alpm: Enable lobf from source in ALPM_CTL

2024-05-27 Thread Animesh Manna
Set the Link Off Between Frames Enable bit in ALPM_CTL register. Note: Lobf need to be enabled adaptive sync fixed refresh mode where vmin = vmax = flipline, which will arise after cmmr feature enablement. Will add enabling sequence in a separate patch. v1: Initial version. v2: Condition check

[PATCH v6 2/6] drm/i915/alpm: Move alpm related code to a new file

2024-05-27 Thread Animesh Manna
Move ALPM feature related code as it will be used for non-psr panel also thorugh LOBF feature. v1: Initial version. v2: Correct ordering in makefile. [Jani] Signed-off-by: Animesh Manna --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_alpm.c | 295

[PATCH v6 4/6] drm/i915/alpm: Add compute config for lobf

2024-05-27 Thread Animesh Manna
Link Off Between Active Frames, is a new feature for eDP that allows the panel to go to lower power state after transmission of data. This is a feature on top of ALPM, AS SDP. Add compute config during atomic-check phase. v1: RFC version. v2: Add separate flag for auxless-alpm. [Jani] v3: -

[PATCH v6 1/6] drm/i915/alpm: Move alpm parameters from intel_psr

2024-05-27 Thread Animesh Manna
ALPM can be enabled for non psr panel and currenly aplm-params are encapsulated under intel_psr struct, so moving out to intel_dp struct. Signed-off-by: Animesh Manna --- .../drm/i915/display/intel_display_types.h| 21 + drivers/gpu/drm/i915/display/intel_psr.c | 44

[PATCH v6 0/6] Link off between frames for edp

2024-05-27 Thread Animesh Manna
after cmmr feature enablement. Currently existing code refactored and make compute-config() and enabling function ready. Will add enabling sequence in a separate patch. Signed-off-by: Animesh Manna Animesh Manna (5): drm/i915/alpm: Move alpm parameters from intel_psr drm/i915/alpm: Move alpm

Re: [PATCH v6,08/24] media: mediatek: vcodec: add tee client interface to communiate with optee-os

2024-05-27 Thread Chen-Yu Tsai
Hi, On Thu, May 16, 2024 at 8:21 PM Yunfei Dong wrote: > > Open tee context to initialize the environment in order to communication > with optee-os, then open tee session as the communication pipeline for > lat and core to send data for hardware decode. > > Signed-off-by: Yunfei Dong > --- >

Re: [PATCH v2 0/3] drm/loongson: Introduce component framework support

2024-05-27 Thread Markus Elfring
> Introduce component framework to bind child and sibling devices, for better > modularity and offload the deferral probe issue to submodule if it need to needs? > attach exterinal module someday. Also for better reflect the

Re: [PATCH] drm/radeon/r100: enhance error handling in r100_cp_init_microcode

2024-05-27 Thread Christian König
Am 27.05.24 um 03:20 schrieb Zhouyi Zhou: In r100_cp_init_microcode, if rdev->family don't match any of if statement, fw_name will be NULL, which will cause gcc (11.4.0 powerpc64le-linux-gnu) complain: In function ‘r100_cp_init_microcode’, inlined from ‘r100_cp_init’ at

Re: [PATCH v6, 24/24] media: mediatek: vcodec: support vp9 svp decoder for mt8188

2024-05-27 Thread Chen-Yu Tsai
On Thu, May 16, 2024 at 8:21 PM Yunfei Dong wrote: > > From: Yilong Zhou > > Change vp9 driver to support secure video playback(svp) for > mt8188. Need to map shared memory with optee interface and > wait interrupt in optee-os. > > Signed-off-by: Yilong Zhou > Signed-off-by: Yunfei Dong > ---

Re: [PATCH] drm: bridge: cdns-mhdp8546: Add mode_valid hook for the drm_bridge_funcs

2024-05-27 Thread Jayesh Choudhary
On 24/05/24 15:13, Dmitry Baryshkov wrote: On Fri, May 24, 2024 at 12:43:48PM +0530, Jayesh Choudhary wrote: With the support for the 'DRM_BRIDGE_ATTACH_NO_CONNECTOR' case, the connector_helper funcs are not initialized if the encoder has this flag in its bridge_attach call. Till now we had

Re: [PATCH v3 1/2] drm/bridge: sii902x: Fix mode_valid hook

2024-05-27 Thread Jayesh Choudhary
On 25/05/24 01:16, Dmitry Baryshkov wrote: On Fri, May 24, 2024 at 05:54:02PM +0530, Jayesh Choudhary wrote: Hello Dmitry, On 24/05/24 15:11, Dmitry Baryshkov wrote: On Fri, May 24, 2024 at 03:05:08PM +0530, Jayesh Choudhary wrote: Currently, mode_valid hook returns all mode as valid and

[PATCH v2 2/2] drm/rockchip: vop: enable VOP_FEATURE_INTERNAL_RGB on RK3066

2024-05-27 Thread Val Packett
The RK3066 does have RGB display output, so it should be marked as such. Fixes: f4a6de8 ("drm: rockchip: vop: add rk3066 vop definitions") Cc: sta...@vger.kernel.org Signed-off-by: Val Packett --- v2: expanded commit message --- drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 + 1 file changed,

[PATCH v2 1/2] drm/rockchip: vop: clear DMA stop bit upon vblank on RK3066

2024-05-27 Thread Val Packett
On the RK3066, there is a bit that must be cleared, otherwise the picture does not show up on the display (at least for RGB). Fixes: f4a6de8 ("drm: rockchip: vop: add rk3066 vop definitions") Cc: sta...@vger.kernel.org Signed-off-by: Val Packett --- v2: doing this on vblank makes more sense;

Re: [PATCH v6,14/24] media: mediatek: vcodec: Add capture format to support one plane memory

2024-05-27 Thread Chen-Yu Tsai
Hi, On Thu, May 16, 2024 at 8:21 PM Yunfei Dong wrote: > > Define one uncompressed capture format V4L2_PIX_FMT_MS21 in order to > support one plane memory. The buffer size is luma + chroma, luma is > stored at the start and chrome is stored at the end. > > Signed-off-by: Yunfei Dong > --- >

Re: [Linaro-mm-sig] [PATCH] dma-buf/sw-sync: don't enable IRQ from sync_print_obj()

2024-05-27 Thread Christian König
by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=a225ee3df7e7f9372dbe Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") Signed-off-by: Tetsuo Handa Reviewed-by: Christian König Thank you. Who can take this patch? I pushed it to drm

Re: [PATCH v6,17/24] media: mediatek: vcodec: re-construct h264 driver to support svp mode

2024-05-26 Thread Chen-Yu Tsai
On Thu, May 16, 2024 at 8:21 PM Yunfei Dong wrote: > > Need secure buffer size to convert secure handle to secure > pa in optee-os, re-construct the vsi struct to store each > secure buffer size. > > Separate svp and normal wait interrupt condition for svp mode > waiting hardware interrupt in

Re: [PATCH v7 05/18] drm/mediatek: Set DRM mode configs accordingly

2024-05-26 Thread Chen-Yu Tsai
lane size. > > > As you mentioned in the commit message, IGT tests the cursor sizes > > > from 1x1 to 512x512, so just setting them to 512 (with a macro) should > > > be enough. > > > > > > Currently this tells the userspace "the supported cursor pla

Re: [PATCH RESEND, v6 2/8] dt-bindings: mailbox: Add property for CMDQ secure driver

2024-05-26 Thread 林睿祥

Re: [PATCH RESEND, v6 6/8] mailbox: mediatek: Add CMDQ secure mailbox driver

2024-05-26 Thread 林睿祥

Re: [PATCH v7 05/18] drm/mediatek: Set DRM mode configs accordingly

2024-05-26 Thread Fei Shao
On Mon, May 27, 2024 at 12:38 PM Chen-Yu Tsai wrote: > > On Mon, May 27, 2024 at 12:34 PM Fei Shao wrote: > > > > Hi Shawn, > > > > On Thu, May 2, 2024 at 6:39 PM Shawn Sung wrote: > > > > > > From: Hsiao Chien Sung > > > > > > Set DRM mode configs limitation according to the hardware

Re: [PATCH v7 05/18] drm/mediatek: Set DRM mode configs accordingly

2024-05-26 Thread Chen-Yu Tsai
On Mon, May 27, 2024 at 12:34 PM Fei Shao wrote: > > Hi Shawn, > > On Thu, May 2, 2024 at 6:39 PM Shawn Sung wrote: > > > > From: Hsiao Chien Sung > > > > Set DRM mode configs limitation according to the hardware capabilities > > and pass the IGT checks as below: > > > > - The test

Re: [PATCH v7 05/18] drm/mediatek: Set DRM mode configs accordingly

2024-05-26 Thread Fei Shao
Hi Shawn, On Thu, May 2, 2024 at 6:39 PM Shawn Sung wrote: > > From: Hsiao Chien Sung > > Set DRM mode configs limitation according to the hardware capabilities > and pass the IGT checks as below: > > - The test "graphics.IgtKms.kms_plane" requires a frame buffer with > width of 4512 pixels

Re: [PATCH RESEND, v6 6/8] mailbox: mediatek: Add CMDQ secure mailbox driver

2024-05-26 Thread 胡俊光

Re: [PATCH v2] drm/mediatek/dp: fix mtk_dp_aux_transfer return value

2024-05-26 Thread patchwork-bot+chrome-platform
Hello: This patch was applied to chrome-platform/linux.git (for-next) by Chun-Kuang Hu : On Wed, 17 Apr 2024 10:38:19 + you wrote: > In case there is no DP device attached to the port the > transfer function should return IO error, similar to what > other drivers do. > In

Re: [PATCH v2] drm/mediatek/dp: fix mtk_dp_aux_transfer return value

2024-05-26 Thread patchwork-bot+chrome-platform
Hello: This patch was applied to chrome-platform/linux.git (for-kernelci) by Chun-Kuang Hu : On Wed, 17 Apr 2024 10:38:19 + you wrote: > In case there is no DP device attached to the port the > transfer function should return IO error, similar to what > other drivers do. > In

Re: [PATCH v6 02/10] drm/bridge: Set firmware node of drm_bridge instances automatically

2024-05-26 Thread Sui Jingfeng
Hi, On 5/27/24 07:33, kernel test robot wrote: Hi Sui, kernel test robot noticed the following build errors: [auto build test ERROR on drm-exynos/exynos-drm-next] [also build test ERROR on linus/master v6.10-rc1 next-20240523] [cannot apply to shawnguo/for-next] [If your patch is applied

Re: [PATCH v6 02/10] drm/bridge: Set firmware node of drm_bridge instances automatically

2024-05-26 Thread Sui Jingfeng
Hi, On 5/27/24 05:19, Dmitry Baryshkov wrote: On Mon, May 27, 2024 at 04:21:07AM +0800, Sui Jingfeng wrote: Normally, the drm_bridge::of_node won't be used by bridge driver instances themselves. Rather, it is mainly used by other modules to find associated drm bridge drvier. Therefore, adding

[PATCH] drm/radeon/r100: enhance error handling in r100_cp_init_microcode

2024-05-26 Thread Zhouyi Zhou
In r100_cp_init_microcode, if rdev->family don't match any of if statement, fw_name will be NULL, which will cause gcc (11.4.0 powerpc64le-linux-gnu) complain: In function ‘r100_cp_init_microcode’, inlined from ‘r100_cp_init’ at drivers/gpu/drm/radeon/r100.c:1136:7:

Re: [PATCH v6 02/10] drm/bridge: Set firmware node of drm_bridge instances automatically

2024-05-26 Thread kernel test robot
Hi Sui, kernel test robot noticed the following build errors: [auto build test ERROR on drm-exynos/exynos-drm-next] [also build test ERROR on linus/master v6.10-rc1 next-20240523] [cannot apply to shawnguo/for-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when

Re: [PATCH v6 02/10] drm/bridge: Set firmware node of drm_bridge instances automatically

2024-05-26 Thread Dmitry Baryshkov
On Mon, May 27, 2024 at 04:21:07AM +0800, Sui Jingfeng wrote: > Normally, the drm_bridge::of_node won't be used by bridge driver instances > themselves. Rather, it is mainly used by other modules to find associated > drm bridge drvier. Therefore, adding a drm bridge to the global bridge list > and

Re: [PATCH v2 1/3] drm/loongson: Add a helper for creating child devices

2024-05-26 Thread Dmitry Baryshkov
On Mon, May 27, 2024 at 03:58:24AM +0800, Sui Jingfeng wrote: > In some display subsystems, the functionality of a PCIe device may too > complex to be managed by a single driver. A split of the functionality > into child devices can helpful to achieve better modularity. > > Another benefit is

[PATCH v6 10/10] drm/bridge: ch7033: Switch to use fwnode based APIs

2024-05-26 Thread Sui Jingfeng
Use the freshly created helper to replace the use of DT-dependent APIs, also print error log if the fwnode graph is not complete which is benefit to debug. Signed-off-by: Sui Jingfeng --- drivers/gpu/drm/bridge/chrontel-ch7033.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-)

[PATCH v6 08/10] drm/bridge: tfp410: Use fwnode APIs to acquire device properties

2024-05-26 Thread Sui Jingfeng
Make this driver less DT-dependent by calling the newly created helpers, also switch to use fwnode APIs to acquire additional device properties. No functional changes for DT-based systems. Signed-off-by: Sui Jingfeng --- drivers/gpu/drm/bridge/ti-tfp410.c | 39 +++--- 1

[PATCH v6 09/10] drm/bridge: sii9234: Use fwnode APIs to abstract DT dependent API away

2024-05-26 Thread Sui Jingfeng
Switch to use the freshly created drm_bridge_set_node() helper, no functional changes. The reason behind of this introduction is that the name 'of_node' itself has a smell of DT dependent, and it is a internal memeber, when there has helper function, we should use the revelant helper and avoid

[PATCH v6 07/10] drm-bridge: it66121: Use fwnode APIs to acquire device properties

2024-05-26 Thread Sui Jingfeng
Make this driver less DT-dependent by calling the newly created helpers, also switch to use fwnode APIs to acquire additional device properties. A side benifit is that boilerplates get reduced, no functional changes for DT-based systems. Signed-off-by: Sui Jingfeng ---

[PATCH v6 06/10] drm/bridge: sii902x: Switch to use fwnode APIs to acquire device properties

2024-05-26 Thread Sui Jingfeng
Make this driver less DT-dependent by calling the freshly created helpers, also switch to use fwnode APIs to acquire additional device properties. One side benifit is that boilerplates get reduced, no functional changes for DT-based systems. Signed-off-by: Sui Jingfeng ---

[PATCH v6 05/10] drm/bridge: display-connector: Use fwnode APIs to acquire device properties

2024-05-26 Thread Sui Jingfeng
Switch to use the fwnode APIs, which is a fundamental step to make this driver OF-independent possible. No functional changes for DT-based systems. Signed-off-by: Sui Jingfeng --- drivers/gpu/drm/bridge/display-connector.c | 23 +++--- 1 file changed, 11 insertions(+), 12

[PATCH v6 02/10] drm/bridge: Set firmware node of drm_bridge instances automatically

2024-05-26 Thread Sui Jingfeng
Normally, the drm_bridge::of_node won't be used by bridge driver instances themselves. Rather, it is mainly used by other modules to find associated drm bridge drvier. Therefore, adding a drm bridge to the global bridge list and setting 'of_node' field of a drm bridge share the same goal. Both are

[PATCH v6 04/10] drm/bridge: simple-bridge: Use fwnode APIs to acquire device properties

2024-05-26 Thread Sui Jingfeng
Make this driver less DT-dependent by calling the newly created helpers, also switch to use fwnode APIs to acquire additional device properties. A side benifit is that boilerplates get reduced, no functional changes for DT-based systems. Signed-off-by: Sui Jingfeng ---

[PATCH v6 03/10] drm/bridge: Implement of_drm_find_bridge() on the top of drm_bridge_find_by_fwnode()

2024-05-26 Thread Sui Jingfeng
Before applying this patch, people may worry about the OF and non-OF API will have a risk to diverge. Eliminate the risk by reimplement the of_drm_find_bridge() on the top of drm_bridge_find_by_fwnode(). As for now the fundamental searching method is unique. Signed-off-by: Sui Jingfeng

[PATCH v6 01/10] drm/bridge: Allow using fwnode APIs to get the next bridge

2024-05-26 Thread Sui Jingfeng
The various display bridge drivers rely on 'OF' infrastructures to works very well, yet there are some platforms and/or devices lack of 'OF' support. Such as virtual display drivers, USB display apapters and ACPI based systems etc. Add fwnode based helpers to fill the niche, this allows part of

[PATCH v6 00/10] drm/bridge: Allow using fwnode API to get the next bridge

2024-05-26 Thread Sui Jingfeng
Currently, the various display bridge drivers rely on OF infrastructures to works very well, yet there are platforms and/or devices absence of 'OF' support. Such as virtual display drivers, USB display apapters and ACPI based systems etc. Add fwnode based helpers to fill the niche, this allows

[PATCH v2 3/3] drm/loongson: Add dummy gpu driver as a subcomponent

2024-05-26 Thread Sui Jingfeng
Loongson Graphics are PCIe multi-functional devices, the GPU device and the display controller are two distinct devices. Drivers of them should loose coupling, but still be able to works togather to provide a unified service to userspace. Add a dummy driver for the GPU, it functional as a

[PATCH v2 2/3] drm/loongson: Introduce component framework support

2024-05-26 Thread Sui Jingfeng
Hardware units come with PCIe are actually all ready to be driven, but there has some board specific modules could return '-EPROBE_DEFER'. However, the driver needs all of the subcompoments ready to use before it can register the drm service to userspace. Introduce the component framework to

[PATCH v2 1/3] drm/loongson: Add a helper for creating child devices

2024-05-26 Thread Sui Jingfeng
In some display subsystems, the functionality of a PCIe device may too complex to be managed by a single driver. A split of the functionality into child devices can helpful to achieve better modularity. Another benefit is that we could migrate the dependency on exterinal modules to a submodule

[PATCH v2 0/3] drm/loongson: Introduce component framework support

2024-05-26 Thread Sui Jingfeng
. This allows the master don't have to tear down everything, thereore majority setups work can be preserved. The potential cyclic dependency problem can be solved then. v1 -> v2: * Squash patch 0002 and patch 0003 into one * Fill type and improve commit message Sui Jingfeng

[PATCH v9 10/10] gpu: ipu-v3: Use generic macro for rounding closest to specified value

2024-05-26 Thread Devarsh Thakkar
Thakkar --- V9: No change V8: Update commit message V1->V7 : (No change, patch introduced in V7) --- drivers/gpu/ipu-v3/ipu-image-convert.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c b/drivers/gpu/ipu-v3/ipu-image-convert.c in

[PATCH v9 09/10] media: imagination: Round to closest multiple for cropping region

2024-05-26 Thread Devarsh Thakkar
ection.rst Signed-off-by: Devarsh Thakkar --- V9: No change V8: Update commit message with specification reference V1->V7 (No change, patch introduced in V7) --- drivers/media/platform/imagination/e5010-jpeg-enc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/

<    4   5   6   7   8   9   10   11   12   13   >