Hi Detlev,
On 2/6/25 9:40 PM, Detlev Casanova wrote:
Hi Quentin,
On Tuesday, 4 February 2025 04:59:12 EST Quentin Schulz wrote:
Hi Detlev,
Just some drive-by comment inline.
On 2/3/25 6:16 PM, Detlev Casanova wrote:
[...]
+static void dw_hdmi_qp_set_audio_interface(struct dw_hdmi_qp *hdmi
ther address/bus-less devices, which for Rockchip SoCs is at the
top of the DT? c.f.
https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html
**I** would put it between the firmware and the pmu-a55 nodes.
Tested-by: Quentin Schulz # RK3588 Tiger Haikou
Thanks!
Quentin
functions.
The driver uses the generic HDMI Codec framework in order to implement
the HDMI audio support.
Signed-off-by: Sugar Zhang
Reviewed-by: Dmitry Baryshkov
Tested-by: Quentin Schulz
Signed-off-by: Detlev Casanova
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 497
Hi Detlev,
On 2/3/25 6:16 PM, Detlev Casanova wrote:
HDMI audio is available on the Rock 5B HDMI TX port.
Enable it.
Signed-off-by: Detlev Casanova
Reviewed-by: Quentin Schulz
Will try to remember to send patches for RK3588 Tiger Haikou and RK3588
Jaguar once those patches get merged
Hi Detlev,
On 1/31/25 6:18 PM, Detlev Casanova wrote:
Hi Quentin,
On Friday, 31 January 2025 11:38:34 EST Quentin Schulz wrote:
Hi Detlev,
On 1/30/25 5:45 PM, Detlev Casanova wrote:
[...]
The only hesitation I have is that HDMI0 can use either I2S or SPDIF for
audio, both audio controllers
ht is right, therefore:
Tested-by: Quentin Schulz
Thanks!
Quentin
Hi Detlev,
On 1/30/25 5:45 PM, Detlev Casanova wrote:
Use the simple-audio-card driver with the hdmi0 QP node as CODEC and
the i2s5 device as CPU.
The simple-audio-card,mclk-fs value is set to 128 as it is done in
the downstream driver.
The #sound-dai-cells value is set to 0 in the hdmi0 node
Hi Andy,
On 11/14/24 1:50 AM, Andy Yan wrote:
Hi,
At 2024-05-06 15:44:36, "Quentin Schulz" wrote:
Hi Heiko,
On 4/25/24 9:55 PM, Heiko Stuebner wrote:
From: Heiko Stuebner
The clock is in Hz while the value checked against is in kHz, so
actual frequencies will never be able t
drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Cc: "Heiko Stübner"
Cc: Q
[1] https://lore.kernel.org/r/20230901234015.566018-1-diand...@chromium.org
[2] https://lore.kernel.org/r/20230901234202.566951-1-diand...@chromium.org
[3] https://lore.kernel.org/r/20230921192749.1542462-1-diand...@chromium.org
Cc: "Heiko Stübner"
Cc: Quentin Schulz
Signed-off-by: Dougl
(vop2->drm, "MIPI dclk out of range, dclk_out_rate:
%ld KHZ\n",
Ditto.
Otherwise,
Reviewed-by: Quentin Schulz
Thanks!
Quentin
op2_video_port vps[ROCKCHIP_MAX_CRTC]; so we don't
necessarily need it in this specific location and can group it with the
others. Cosmetic suggestion though.
Otherwise, the change itself makes sense to me, so:
Reviewed-by: Quentin Schulz
Thanks!
Quentin
duplicates.
Fixes: e5f9d543419c ("drm/panel: ltk050h3146w: add support for Leadtek
LTK050H3148W-CTA6 variant")
Signed-off-by: Heiko Stuebner
Reviewed-by: Quentin Schulz
Thanks!
Quentin
set.
Other DSI drivers might handle this differently, so add the flag.
Fixes: e5f9d543419c ("drm/panel: ltk050h3146w: add support for Leadtek
LTK050H3148W-CTA6 variant")
Signed-off-by: Heiko Stuebner
Reviewed-by: Quentin Schulz
Thanks!
Quentin
drm/panel: ltk500hd1829: add panel type for ltk101b4029w
For the whole series:
Reviewed-by: Quentin Schulz
Thanks,
Quentin
From: Quentin Schulz
This is only a cosmetic change.
This replaces a hand-crafted EPROBE_DEFER handling for deciding to print
an error message with dev_err_probe.
A side-effect is that dev_err_probe also adds a debug message when it's
not EPROBE_DEFER, but this is seen as an improvement
From: Quentin Schulz
devm_gpiod_get_optional may return EPROBE_DEFER in case the GPIO
controller isn't yet probed when the panel driver is being probed.
In that case, a spurious and confusing error message about not being
able to get the reset GPIO is printed even though later on the d
This hides an error message if EPROBE_DEFER was returned when trying to
get the reset GPIO.
This also makes use of dev_err_probe in lieu of hand-crafted logic
inside the driver.
Thanks,
Quentin
Signed-off-by: Quentin Schulz
---
Quentin Schulz (2):
drm/panel: ltk050h3146w: only print
Hi Fabio,
On 11/17/23 20:27, Fabio Estevam wrote:
Hi Quentin,
On Fri, Nov 17, 2023 at 3:31 PM Quentin Schulz wrote:
From: Quentin Schulz
This scary message may happen if the panel or bridge is not probed
before the LVDS controller is, resulting in some head scratching because
the LVDS
From: Quentin Schulz
This scary message can misled the user into thinking something bad has
happened and needs to be fixed, however it could simply be part of a
normal boot process where EPROBE_DEFER is taken into account. Therefore,
let's use dev_err_probe so that this message doesn't
From: Quentin Schulz
ret variable stores the return value of drm_of_find_panel_or_bridge
which can return error codes different from EPROBE_DEFER. Therefore,
let's just return that error code instead of forcing it to EPROBE_DEFER.
Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Ro
users.
Signed-off-by: Quentin Schulz
---
Changes in v2:
- add a patch for not overwriting return code with EPROBE_DEFER
- use dev_err_probe instead of DRM_DEV_DEBUG
- Link to v1:
https://lore.kernel.org/r/20231117-rk-lvds-defer-msg-v1-1-1e6894cf9...@theobroma-systems.com
---
Quentin Schulz
From: Quentin Schulz
This scary message may happen if the panel or bridge is not probed
before the LVDS controller is, resulting in some head scratching because
the LVDS panel is actually working, since a later try will eventually
find the panel or bridge.
Therefore let's demote this
Hi all,
Seems I'm not the only one who forgot about this patch series, so,
kindly pinging :)
Thanks!
Quentin
On 1/31/22 17:47, quentin.sch...@theobroma-systems.com wrote:
From: Quentin Schulz
To prepare for a new display to be supported by this driver which has a
slightly different s
From: Quentin Schulz
The LTK050H3148W-CTA6 is a 5.0" 720x1280 DSI display, whose driving
controller is a Himax HX8394-F, slightly different from LTK050H3146W by
its init sequence, mode details and mode flags.
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
---
.../devicetree/bin
From: Klaus Goger
The LTK050H3148W-CTA6 is a 5.0" 720x1280 DSI display, whose driving
controller is a Himax HX8394-F, slightly different from LTK050H3146W by
its init sequence, mode details and mode flags.
Cc: Quentin Schulz
Signed-off-by: Klaus Goger
Signed-off-by: Quentin S
From: Quentin Schulz
Heiko does not work at Theobroma Systems anymore and the boards using
those panels are downstream, maintained internally by the company, so
let's relieve Heiko of maintainership duties.
Cc: Heiko Stuebner
Cc: Quentin Schulz
Signed-off-by: Quentin S
From: Quentin Schulz
To prepare for a new display to be supported by this driver which has a
slightly different set of DSI mode related flags, let's move the
currently hardcoded mode flags to the .data field of of_device_id
structure.
Cc: Quentin Schulz
Signed-off-by: Quentin S
rg/patch/249400/
>
If I'm not mistaken, you could get rid of the patch in the Intel driver
when we have this one merged. Is there any reason not to, have I missed
something?
Thanks,
Quentin
> Reviewed-by: Manasi Navare
>
> Manasi
>
>
> On Thu, Sep 20, 2018 at 03:54:37PM +
29 matches
Mail list logo
