(Sorry for re-sending; used a web mail client which send html)
On Mon, Sep 15, 2025, at 2:31 PM, Daniel Stone wrote:
> Hi Nícolas,
>
> On Wed, 3 Sept 2025 at 19:43, Nícolas F. R. A. Prado
> wrote:
> > On Tue, 2025-08-26 at 13:25 +0100, Daniel Stone wrote:
> > Based on this discussion, this is my
On Mon, Sep 15, 2025, at 2:31 PM, Daniel Stone wrote:
> Hi Nícolas,
>
> On Wed, 3 Sept 2025 at 19:43, Nícolas F. R. A. Prado
> wrote:
> > On Tue, 2025-08-26 at 13:25 +0100, Daniel Stone wrote:
> > Based on this discussion, this is my understanding for the changes
> > desired on the series and t
Hello Marek,
On Thu, Sep 25, 2025 at 02:15:41AM +0200, Marek Vasut wrote:
> On 9/24/25 11:46 PM, Sebastian Reichel wrote:
> > From: Sebastian Reichel
> >
> > I planned to set the polarity of horizontal and vertical sync, but
> > accidentally described vertical sync tw
From: Sebastian Reichel
I planned to set the polarity of horizontal and vertical sync, but
accidentally described vertical sync twice with different polarity
instead.
Note, that there is no functional change, because the driver only
makes use of DRM_MODE_FLAG_P[HV]SYNC to divert from the
and P
> flags (drivers/gpu/drm/panel/panel-sitronix-st7789v.c, see
> t28cp45tn89_mode, which I assume is a bug - Sebastian, could you check
> that ?).
Yeah, it was supposed to be
static const struct drm_display_mode t28cp45tn89_mode = {
...
.flags = DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLA
On Wed Aug 27, 2025 at 1:08 PM CEST, Sebastian Wick wrote:
> On Wed Aug 27, 2025 at 12:39 PM CEST, Daniel Stone wrote:
>> Hey,
>>
>> On Wed, 27 Aug 2025 at 10:41, Maxime Ripard wrote:
>>> On Wed, Aug 27, 2025 at 12:26:56AM +0800, Shengyu Qu wrote:
>>> >
ith extra checks.
>
> In addtion, DRM_DEV_ERROR() is replaced by dev_err_probe().
>
> Signed-off-by: Damon Ding
>
> --
Reviewed-by: Sebastian Reichel
-- Sebastian
>
> Changes in v2:
> - Replace DRM_DEV_ERROR() with dev_err_probe().
> ---
> drivers/gpu/
On Fri Aug 22, 2025 at 8:36 PM CEST, Nícolas F. R. A. Prado wrote:
> Introduce support for a post-blend color pipeline API analogous to the
> pre-blend color pipeline API. While the pre-blend color pipeline was
> configured through a COLOR_PIPELINE property attached to a drm_plane,
> the post-blend
On Wed Aug 27, 2025 at 12:39 PM CEST, Daniel Stone wrote:
> Hey,
>
> On Wed, 27 Aug 2025 at 10:41, Maxime Ripard wrote:
>> On Wed, Aug 27, 2025 at 12:26:56AM +0800, Shengyu Qu wrote:
>> > 1.Can you send patch with only i915/amdgpu first? It's a long-needed
>> > feature
>> > to deal with some moni
With the small improvements, the core drm parts are
Reviewed-by: Sebastian Wick
On Fri Aug 15, 2025 at 5:49 AM CEST, Alex Hung wrote:
> This is an RFC set for a color pipeline API, along with implementations
> in VKMS and amdgpu. It is tested with a set of IGT tests that can be
> fo
On Wed Aug 20, 2025 at 8:16 PM CEST, Alex Hung wrote:
>
>
> On 8/19/25 09:31, Sebastian Wick wrote:
>>> +/**
>>> + * drm_plane_colorop_curve_1d_lut_init - Initialize a DRM_COLOROP_1D_LUT
>>> + *
>>> + * @dev: DRM device
>>> + * @colorop: Th
On Fri Aug 15, 2025 at 5:50 AM CEST, Alex Hung wrote:
> We've previously introduced DRM_COLOROP_1D_CURVE for
> pre-defined 1D curves. But we also have HW that supports
> custom curves and userspace needs the ability to pass
> custom curves, aka LUTs.
>
> This patch introduces a new colorop type, ca
On Fri Aug 15, 2025 at 5:49 AM CEST, Alex Hung wrote:
> From: Harry Wentland
>
> We want to be able to bypass each colorop at all times.
> Introduce a new BYPASS boolean property for this.
>
> Reviewed-by: Simon Ser
> Reviewed-by: Louis Chauvet
> Signed-off-by: Alex Hung
> Signed-off-by: Harry
On Fri Aug 15, 2025 at 5:49 AM CEST, Alex Hung wrote:
> From: Harry Wentland
>
> Add a new drm_colorop with DRM_COLOROP_1D_CURVE with two subtypes:
> DRM_COLOROP_1D_CURVE_SRGB_EOTF and DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF.
>
> Reviewed-by: Simon Ser
> Reviewed-by: Louis Chauvet
> Signed-off-by: Ha
Hi,
On Thu, Jul 31, 2025 at 10:52:49AM +0800, Andy Yan wrote:
>
> Hello Sebastian，
>
> 在 2025-07-30 20:15:44，"Andy Yan" 写道：
> >
> >
> >Hello Sebastian，
> >
> >At 2025-07-30 01:09:41, "Sebastian Reichel"
> > wrote:
>
o work (I'm still fighting with getting
that part stable, but that issue is on the USB-PD side).
Tested-by: Sebastian Reichel
-- Sebastian
> ---
>
> Changes in v6:
> - Use drm_dp_vsc_sdp_supported
> - Store bpc/bpp/color format in dw_dp_bridge_state
>
> Changes in v5:
o have
the USBDP PHY described in the graph as a transparent bridge?
Note, that the USBDP PHY DT binding is currently not ready for
this (this also affects the next patch, but should be enough to
discuss this once :)).
Greetings,
-- Sebastian
>
> (no changes since v2)
>
&g
cription matches the TRM:
Reviewed-by: Sebastian Reichel
Greetings,
-- Sebastian
>
> (no changes since v1)
>
> .../arm64/boot/dts/rockchip/rk3588-extra.dtsi | 30 +++
> 1 file changed, 30 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-extra.
cription matches the TRM:
Reviewed-by: Sebastian Reichel
Greetings,
-- Sebastian
>
> (no changes since v1)
>
> arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 30 +++
> 1 file changed, 30 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.
Hi,
On Tue, Jul 15, 2025 at 02:24:39PM +0200, Thomas Zimmermann wrote:
> Include to declare device_property_read_u32(). Avoids
> dependency on backlight header to include it.
device_property_*() is from , which is already
included in the following line...
Greetings,
-- Sebastian
>
the reset. This
> is the way it is done on our numerous development boards (such as
> RK3568/RK3576 EVB).
>
> So make the reset-gpio optional.
>
> Signed-off-by: Andy Yan
> ---
Reviewed-by: Sebastian Reichel
Greetings,
-- Sebastian
>
> drivers/gpu/drm/panel/panel-ra
the reset. This
> is the way it is done on our numerous development boards (such as RK3568,
> RK3576 EVB).
> So make the reset-gpio optional.
>
> Signed-off-by: Andy Yan
> ---
Reviewed-by: Sebastian Reichel
Greetings,
-- Sebastian
>
> .../devicetree/bindings/display/pane
2 IOCTL, another reference to the
> timeline is got, and only that last one is put on successful completion.
> As a consequence, the legacy timeline, with its underlying engine status
> page's VMA object, is still held and not released on driver unbind.
>
> Get the legacy timeline only after successful allocation of the context
> engine's VMA.
>
> Fixes: 75d0a7f31eec ("drm/i915: Lift timeline into intel_context")
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12061
> Cc: Chris Wilson
> Cc: Matthew Auld
> Signed-off-by: Janusz Krzysztofik
Everything looks good to me overall.
Reviewed-by: Sebastian Brzezinka
--
Best regards,
Sebastian
{
"emoji": "👍",
"version": 1
}
ction is replaced by hpd0_ack and hpd1_ack, the
required constants are also added.
The changes were not tested on actual hardware. I am only able
to verify that the changes keep the code compileable and do my
best to look repeatedly if I am not actually changing any code.
Signed-off-by: Seba
ction is replaced by hpd0_ack and hpd1_ack, the
required constants are also added.
The changes were not tested on actual hardware. I am only able
to verify that the changes keep the code compileable and do my
best to look repeatedly if I am not actually changing any code.
Signed-off-by: Seba
f[intf_id].irq < 0)
> return;
>
> - ret = generic_handle_irq(gt->gsc.intf[intf_id].irq);
> + ret = generic_handle_irq_safe(gt->gsc.intf[intf_id].irq);
> +
that extra line looks odd, other than that
Acked-by: Sebastian Andrzej Siewior
> if (ret)
>
1e3dc1d8622b ("drm/i915/gsc: add gsc as a mei auxiliary device")
> Tested-by: Furong Zhou
> Suggested-by: Sebastian Andrzej Siewior
> Signed-off-by: Junxiao Chang
> ---
> drivers/gpu/drm/i915/gt/intel_gsc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
&g
as other parts of the
kernel.
Sebastian
!irq_disabled_flag)
> + local_irq_disable();
> +#endif
> ret = generic_handle_irq(gt->gsc.intf[intf_id].irq);
What about generic_handle_irq_safe() instead the whole ifdef show?
> +#ifdef CONFIG_PREEMPT_RT
> + if (!irq_disabled_flag)
> + local_irq_enable();
> +#endif
> +
> if (ret)
> gt_err_ratelimited(gt, "error handling GSC irq: %d\n", ret);
> }
Sebastian
all/Z+pFou7KOQZJ1iy4@vaman/
[1]
https://web.git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git/commit/?h=next&id=f08d1c08563846f9be79a4859e912c8795d690fd
Greetings,
-- Sebastian
588_GRF_VO1_CON9, val);
> + cfg = of_device_get_match_data(dev);
> + cfg->ctrl_ops->io_init(hdmi);
I think it would be better to store the ctrl_ops (or io_init)
callback in struct rockchip_hdmi_qp during driver probe and avoid
another lookup of the match_data, which involves string comparisons.
Otherwise:
Reviewed-by: Sebastian Reichel
Greetings,
-- Sebastian
signature.asc
Description: PGP signature
.org/all/Z8z236h4B5A6Ki3D@gallifrey/
>
> Remove it.
>
> [...]
Applied, thanks!
[6/9] power: supply: pcf50633: Remove charger
commit: aae075a93f7705e29c599d101abc7e467125d871
Best regards,
--
Sebastian Reichel
e used
> FIELD_PREP macro. Add this missing include.
>
> Fixes: 328e6885996c ("drm/rockchip: vop2: Add platform specific callback")
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202503040135.fgoywdlb-...@intel.com/
> Signed-off
ably should at least get
a MAINTAINERS entry to have you CC'd considering all the PWM bits in
it). See the following discussion (I point you to my message in the
middle of a thread, which has a summary and probably is a good
starting point):
https://lore.kernel.org/all/vc7irlp7nuy5yvkxwb5m7wy7
The Rockchip W552793DBA-V10 display/touchscreen board contains a
Wanchanglong W552793BAA panel, which in turn is using a Raydium
RM67200 MIPI-DSI controller. Add a DT binding for the DSI panel.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel
---
.../bindings/display/panel
-by: Jessica Zhang
Reviewed-by: Andy Yan
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm67200.c | 499 ++
3 files changed, 510
.
Greetings,
-- Sebastian
---
Sebastian Reichel (2):
dt-bindings: display: panel: Add Raydium RM67200
drm/panel: add Raydium RM67200 panel driver
.../bindings/display/panel/raydium,rm67200.yaml| 72 +++
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel
Hi,
On Fri, Feb 07, 2025 at 05:21:46PM +0100, Sebastian Reichel wrote:
> This has been tested in combination with the series from Heiko Stübner
> enabling DSI support for the RK3588 [0] (DSI controller support has been
> merged already, only the PHY support is missing) on the RK3588 EVB1
> - intel_pxp_fini(dev_priv);
> -
> for_each_gt(gt, dev_priv, i)
> intel_gt_driver_unregister(gt);
>
> i915_hwmon_unregister(dev_priv);
>
> i915_perf_unregister(dev_priv);
> - i915_pmu_unregister(dev_priv);
>
> i915_teardown_sysfs(dev_priv);
> +
> +not_registered:
> + intel_pxp_fini(dev_priv);
> + i915_pmu_unregister(dev_priv);
> +
> drm_dev_unplug(&dev_priv->drm);
>
> i915_gem_driver_unregister(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ffc346379cc2c..27a23b1eb9de0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -347,6 +347,8 @@ struct drm_i915_private {
> /* The TTM device structure. */
> struct ttm_device bdev;
>
> + bool registered;
Isn't `struct·drm_device` already has a registered field that could
be used, instead of introducing new variable. It's set in
`int·drm_dev_register(struct·drm_device·*dev,·unsigned·long·flags)`
--
Best regards,
Sebastian
Hi,
On Tue, Feb 18, 2025 at 03:53:06PM +0100, Heiko Stübner wrote:
> Am Dienstag, 18. Februar 2025, 15:13:07 MEZ schrieb Sebastian Reichel:
> > On Tue, Feb 18, 2025 at 08:17:46PM +0800, Jianfeng Liu wrote:
> > > On Tue, 18 Feb 2025 11:00:57 +0100, Heiko Stübnerwrote:
>
t;
> Signed-off-by: Arun R Murthy
> Reviewed-by: Chaitanya Kumar Borah
> Tested-by: Naveen Kumar
LGTM
Reviewed-by: Sebastian Brzezinka
--
Best regards,
Sebastian
uilt-in and the HDMI PHY is build as a
module.
But I also think it would be better to have the clocks defined in the
SoC level DT. I suppose that means vop2_bind would have to check if
the HDMI controller is enabled and only requests pll_hdmiphy
based on that. Considering there is the OF graph
s relevant, but while HDMI0 got enabled for quite a
> few devices in 6.13, it did NOT get enabled for Rock 5 ITX.
> I made a local patch (which does the same thing as was done for Rock 5B)
> but I have no idea if it actually works (I don't have the board).
I don't have the board either, but the schematics suggests that your
patch is not correct. On the Rock 5 ITX the RK3588's first HDMI/eDP
port should be enabled in eDP mode to be used with an eDP panel via
connector J11. This series is needed for that.
Greetings,
-- Sebastian
signature.asc
Description: PGP signature
is not yet supported upstream and there is no pending patchset. As far
as I know Rockchip plans to work on preparing upstream support for that
soon.
Note, that the two DisplayPort controllers are completely different.
The HDMI/eDP controller is a design from Analogix and the TypeC/DP
controller is a design from Synopsys.
P.S.: Heiko merged support for HDMI1 (RK3588 SoC level) recently. So you
should be able to get that running by some DT additions to the Rock 5
ITX board DT with the latest linux-next code :)
Greetings,
-- Sebastian
signature.asc
Description: PGP signature
From: Sebastian Reichel
The Lenovo Thinkpad T14s Gen6 Snapdragon is currently sold with three
different panel versions: OLED, Low Power IPS or IPS with Touchscreen.
My Low Power IPS version had this panel and the kernel complained
about not knowing any details. I don't have any
having a look.
Greetings,
-- Sebastian
---
Sebastian Reichel (2):
dt-bindings: display: panel: Add Raydium RM67200
drm/panel: add Raydium RM67200 panel driver
.../bindings/display/panel/raydium,rm67200.yaml| 72 +++
drivers/gpu/drm/panel/Kconfig | 10
-by: Jessica Zhang
Reviewed-by: Andy Yan
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm67200.c | 503 ++
3 files changed, 514
The Rockchip W552793DBA-V10 display/touchscreen board contains a
Wanchanglong W552793BAA panel, which in turn is using a Raydium
RM67200 MIPI-DSI controller. Add a DT binding for the DSI panel.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel
---
.../bindings/display/panel
goto err_ppgtt_cleanup;
+ if (!ppgtt->vm.allocate_va_range) {
+ i915_vm_put(&ppgtt->vm);
+ return 0;
+ }
--
Best regards,
Sebastian
6872a2c ("drm/i915/pxp: Implement PXP irq handler")
> Fixes: 3e7abf814193 ("drm/i915: Extract GT render power state management")
>
> Signed-off-by: Zhanjun Dong
>
Reviewed-by: Sebastian Brzezinka
--
Best regards,
Sebastian
ndy Yan
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 2 +-
> drivers/gpu/drm/rockchip/cdn-dp
to the W552793BAA. I put the regulators into the panel
specific section, because the datasheet for the RM67200 specifies
slightly different ones than the w552793baa datasheet. Thus I expect
that other displays might have slight differences.
Greetings,
-- Sebastian
signature.asc
Description: PGP signature
...@sntech.de/
Thanks for having a look.
Greetings,
-- Sebastian
Sebastian Reichel (2):
dt-bindings: display: panel: Add Raydium RM67200
drm/panel: add Raydium RM67200 panel driver
.../display/panel/raydium,rm67200.yaml| 72 +++
drivers/gpu/drm/panel/Kconfig | 8
-by: Sebastian Reichel
---
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm67200.c | 503 ++
3 files changed, 512 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel
The Rockchip W552793DBA-V10 display/touchscreen board contains a
Wanchanglong W552793BAA panel, which in turn is using a Raydium
RM67200 MIPI-DSI controller. Add a DT binding for the DSI panel.
Signed-off-by: Sebastian Reichel
---
.../display/panel/raydium,rm67200.yaml| 72
plugging in and unplugging an HDMI or DP cable.
I suppose you could fetch the PHY in power_on() and release it in
power_off(). But using phy_set_mode() might indeed be better here.
-- Sebastian
signature.asc
Description: PGP signature
Hi,
On Mon, Dec 02, 2024 at 11:28:13AM +0800, Damon Ding wrote:
> Hi,
>
> On 2024/12/2 6:59, Sebastian Reichel wrote:
> > Hi,
> >
> > On Sat, Nov 30, 2024 at 09:25:12PM +0100, Heiko Stübner wrote:
> > > Am Freitag, 29. November 2024, 03:43:57 CET schrieb Dam
lly handled by the device core based on
DT information, except for some drivers which have special needs.
> > And other phys may want to support dynamic switching too, like the
> > Rockchip USBDP combo phy.
>
> I guess USBDP is special in that in also does both modes dynamical
> depending on its use (like type-c with option DP altmode)
The USBDP PHY is indeed quite different from the PHYs in your list
above, but for a different reason: All the combined PHYs you listed
above only support one mode at the same time. E.g. you need to
decide between PCIe, SATA and USB3 mode for the Naneng combophy.
For the USBDP PHY the modes are not mutually exclusive. The USB
controller can request the USBDP PHY in USB mode at the same time
as the DP controller requests it in DP mode. Some additional
registers configure how the lanes are being muxed. A typcial setup
would be 2 lanes for USB3 and 2 lanes for DP.
Greetings,
-- Sebastian
signature.asc
Description: PGP signature
too.
>
> Fixes: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
> Signed-off-by: Heiko Stuebner
> Reviewed-by: Quentin Schulz
> Acked-by: Andy Yan
> ---
Reviewed-by: Sebastian Reichel
Tested-by: Sebastian Reichel
-- Sebastian
> changes in v2:
> - drop
,
Sebastian
Memory Definitions:
secure memory - Memory allocated in the TEE (Trusted Execution
Environment) which is inaccessible in the REE (Rich Execution
Environment, i.e. linux kernel/user space).
secure handle - Integer value which acts as reference to 'secure
memory'. Used in communicati
dev_err().
The recommended way to do this nowadays looks like this:
return dev_err_probe(dev, PTR_ERR(dsi->phy), "Failed to get mipi dphy");
That will not print anything for -EPROBE_DEFER, but capture
the reason and make it available through
/sys/kernel/debug/devices_deferred if th
class-power and
drivers/power/supply/power_supply_sysfs.c
(POWER_SUPPLY_HEALTH_TEXT).
Greetings,
-- Sebastian
> include/linux/power_supply.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 910d407ebe6
Hi,
On Tue, Aug 06, 2024 at 04:50:26PM GMT, Tomi Valkeinen wrote:
> A few minor fixes to omapdrm, mostly to remove sparse or other checker
> warnings.
>
> Tomi
>
> Signed-off-by: Tomi Valkeinen
For the series:
Reviewed-by: Sebastian Reichel
Greetings,
-- Sebastian
>
From: Sebastian Wick
This reverts commit 63d0b87213a0ba241b3fcfba3fe7b0aed0cd1cc5.
The panel_power_savings sysfs entry can be used to change the displayed
colorimetry which breaks color managed setups.
The "do not break userspace" rule which was violated here is enough
reason to r
From: Sebastian Wick
This reverts commit 76cb763e6ea62e838ccc8f7a1ea4246d690fccc9.
Reverting the panel_power_savings sysfs. See next commit.
Signed-off-by: Sebastian Wick
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++
1 file changed, 4 insertions(+), 25 deletions
On Fri, Aug 2, 2024 at 4:37 PM Harry Wentland wrote:
>
> On 2024-08-02 09:28, Sebastian Wick wrote:
> > I'm very unhappy about how this has played out.
> >
> > We have a new sysfs property that controls a feature of the display
> > path that has been set to a
I'm very unhappy about how this has played out.
We have a new sysfs property that controls a feature of the display
path that has been set to a default(!) which changes the color
behavior! This broke color management for everyone who is on a device
which supports this feature.
What should have be
rt
* Make it clear that drivers can choose between RGB and YCbCr on their
own
Signed-off-by: Sebastian Wick
Reviewed-by: Pekka Paalanen
---
drivers/gpu/drm/drm_connector.c | 79 +
include/drm/drm_connector.h | 8
2 files changed, 61 insertions(+), 26
nts to the correct function for
PREEMPT_RT and non-PREEMPT_RT builds.
Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions")
Signed-off-by: Sebastian Andrzej Siewior
---
I posted this path
https://lore.kernel.org/r/20240404102534.qta80...@linutronix.de
Then
Tomeu Vizoso
> ---
Looking at the TRM I noticed, that this register is not mapped:
RKNN_global_operation_enable
Address: Operational Base + offset (0xF008)
-- Sebastian
> arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 53
> +++
> 1 file changed, 53
in the
DT file (so &rknn should not be added before &i2c).
Greetings,
-- Sebastian
signature.asc
Description: PGP signature
Hi,
On Thu, Jun 13, 2024 at 11:34:02AM GMT, Tomeu Vizoso wrote:
> On Thu, Jun 13, 2024 at 11:24 AM Tomeu Vizoso wrote:
> > On Thu, Jun 13, 2024 at 2:05 AM Sebastian Reichel
> > wrote:
> > > On Wed, Jun 12, 2024 at 03:52:55PM GMT, Tomeu Vizoso wrote:
> > > >
rt_mutex
…
| #endif
this is all in-tree.
> So I don't feel well reviewing this.
>
> Regards,
> Christian.
Sebastian
nts to the correct function for
PREEMPT_RT and non-PREEMPT_RT builds.
Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions")
Signed-off-by: Sebastian Andrzej Siewior
---
Repost of https://lore.kernel.org/r/20240404102534.qta80...@linutronix.de
drivers/gpu/drm/ttm/tests/
; pm_domain_count; i++) {
> + err =
> of_property_read_string_index(iommu->dev->of_node, "power-domain-names", i,
> &pm_domains[i]);
> + if (err) {
> + kfree(pm_domains);
> +
ust bind to the fallback compatible. Iff differences are found
in the future, the kernel can start to make use of the more
specific compatible.
-- Sebastian
> drivers/iommu/rockchip-iommu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/iommu/rockchip-iommu.c b/driv
el.org/doc/Documentation/userspace-api/media/v4l/vidioc-g-selection.rst
[1]
Signed-off-by: Devarsh Thakkar
Acked-by: Sebastian Fricke
Can, whoever picks up the math changes, pick up this change as well?
I will send 1-6 via the media subsystem.
Regards,
Sebastian
---
V12: No change
V11: No change
V10:
function for
> > PREEMPT_RT and non-PREEMPT_RT builds.
> >
> > Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions")
> > Signed-off-by: Sebastian Andrzej Siewior
> > ---
> >
> > For the record, testing led to
> > | WARN
he test program since
> their usefulness is limited outside of well known selftests.
>
> Provide ww_mutex_base_lock() which points to the correct function for
> PREEMPT_RT and non-PREEMPT_RT builds.
>
> Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions&q
When extending support for a driver-specific KMS property to additional
drivers, we should apply all the requirements for new properties and
make sure the semantics are the same and documented.
v2: devs of the driver which introduced property shall help and ack
Signed-off-by: Sebastian Wick
nst' variables in header files
> instead of using macros or enums.
>
> [...]
Applied, thanks!
[09/34] power: rt9455: hide unused rt9455_boost_voltage_values
commit: 452d8950db3e839aba1bb13bc5378f4bac11fa04
Best regards,
--
Sebastian Reichel
nts to the correct function for
PREEMPT_RT and non-PREEMPT_RT builds.
Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions")
Signed-off-by: Sebastian Andrzej Siewior
---
For the record, testing led to
| WARNING: CPU: 5 PID: 2089 at include/drm/ttm/ttm_bo.h:247
ttm_bo_re
On Thu, Mar 07, 2024 at 10:29:22AM +0200, Pekka Paalanen wrote:
> On Wed, 6 Mar 2024 17:42:09 +0100
> Sebastian Wick wrote:
>
> > On Wed, Mar 06, 2024 at 10:27:21AM +0200, Pekka Paalanen wrote:
> > > On Tue, 5 Mar 2024 14:51:49 +0100
> > > Sebastian Wick wr
When extending support for a driver-specific KMS property to additional
drivers, we should apply all the requirements for new properties and
make sure the semantics are the same and documented.
v2: devs of the driver which introduced property shall help and ack
Signed-off-by: Sebastian Wick
ither from the edge, like
shown here:
https://en.wikipedia.org/wiki/File:IPod_Touch_2G_Backlight.JPG
or like this:
https://de.wikipedia.org/wiki/Datei:DiodyTV.jpg
Greetings,
-- Sebastian
On Wed, Mar 06, 2024 at 03:14:15PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Thu, Feb 29, 2024 at 09:28:31PM +0100, Sebastian Wick wrote:
> > When extending support for a driver-specific KMS property to additional
> > drivers, we should apply all the requirements for new pr
On Wed, Mar 06, 2024 at 10:27:21AM +0200, Pekka Paalanen wrote:
> On Tue, 5 Mar 2024 14:51:49 +0100
> Sebastian Wick wrote:
>
> > The initial idea of the Colorspace prop was that this maps 1:1 to
> > InfoFrames/SDP but KMS does not give user space enough information nor
rt
* Make it clear that drivers can choose between RGB and YCbCr on their
own
Signed-off-by: Sebastian Wick
---
drivers/gpu/drm/drm_connector.c | 79 +
include/drm/drm_connector.h | 8
2 files changed, 61 insertions(+), 26 deletions(-)
diff --git a/d
usable from user space and consistent with other
KMS properties for those variants is left as an exercise for whoever
wants to use them.
Signed-off-by: Sebastian Wick
---
drivers/gpu/drm/drm_connector.c | 67 -
include/drm/drm_connector.h | 8
2 files changed
On Fri, Mar 01, 2024 at 01:12:02PM +0100, Maxime Ripard wrote:
> On Fri, Mar 01, 2024 at 12:29:41PM +0100, Sebastian Wick wrote:
> > On Fri, Mar 01, 2024 at 11:30:56AM +0100, Maxime Ripard wrote:
> > > On Thu, Feb 29, 2024 at 08:47:26PM +0100, Sebastian Wick wrote:
> > &
On Fri, Mar 01, 2024 at 11:30:56AM +0100, Maxime Ripard wrote:
> On Thu, Feb 29, 2024 at 08:47:26PM +0100, Sebastian Wick wrote:
> > > @@ -1708,6 +1731,39 @@
> > > EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
> > > /**
> >
On Fri, Mar 01, 2024 at 09:29:17AM +0100, Hans Verkuil wrote:
> On 29/02/2024 20:47, Sebastian Wick wrote:
> > On Thu, Feb 22, 2024 at 07:14:07PM +0100, Maxime Ripard wrote:
> >> The i915 driver has a property to force the RGB range of an HDMI output.
> >> The vc4 drive
property variant, but because the
"defaultRGB" colorimetry is not supported at all right now, making
"Default" undefined means we can't get predictable colors on almost all
displays.
Cheers,
Sebastian
When extending support for a driver-specific KMS property to additional
drivers, we should apply all the requirements for new properties and
make sure the semantics are the same and documented.
Signed-off-by: Sebastian Wick
---
Documentation/gpu/drm-kms.rst | 5 +
1 file changed, 5
NULL;
> +
> + return broadcast_rgb_names[broadcast_rgb].name;
> +}
> +EXPORT_SYMBOL(drm_hdmi_connector_get_broadcast_rgb_name);
> +
> static const char * const output_format_str[] = {
> [HDMI_COLORSPACE_RGB] = "RGB",
> [HD
On Wed, Feb 28, 2024 at 08:42:41PM -0300, Arthur Grillo wrote:
>
>
> On 15/01/24 12:06, Sebastian Wick wrote:
> > On Wed, Jan 10, 2024 at 02:44:00PM -0300, Arthur Grillo wrote:
> >> This patchset aims to add support for additional buffer YUV formats.
> >> More
he list is "in order of preference"
> Add a a link to the mutter MR
>
> Cc: Simon Ser
> Cc: Jonas Ådahl
> Cc: Daniel Stone
> Cc: Sameer Lattannavar
> Cc: Sebastian Wick
> Acked-by: Harry Wentland
> Acked-by: Pekka Paalanen
> Signed-of
On Thu, Feb 22, 2024 at 02:58:45PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 22, 2024 at 11:54:04AM +0100, Maxime Ripard wrote:
> > On Mon, Feb 19, 2024 at 03:01:44PM +0100, Sebastian Wick wrote:
> > > On Thu, Feb 15, 2024 at 12:00:01PM +0100, Maxime Ripard wrote:
> > >
On Thu, Feb 15, 2024 at 12:00:01PM +0100, Maxime Ripard wrote:
> On Mon, Feb 12, 2024 at 06:06:18PM +0100, Sebastian Wick wrote:
> > On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote:
> > > On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote:
> > >
1 - 100 of 1063 matches
Mail list logo
