On Tue, 7 May 2024 at 11:04, Daniel Vetter wrote:
>
> On Tue, May 07, 2024 at 09:46:31AM -0700, Linus Torvalds wrote:
>
> > I'd be perfectly ok with adding a generic "FISAME" VFS level ioctl
> > too, if this is possibly a more common thing. and not just DRM wants
> > it.
> >
> > Would something
On 5/3/2024 11:13 AM, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT bitbanging
On Tue, May 07, 2024 at 09:46:31AM -0700, Linus Torvalds wrote:
> On Tue, 7 May 2024 at 04:03, Daniel Vetter wrote:
> >
> > It's really annoying that on some distros/builds we don't have that, and
> > for gpu driver stack reasons we _really_ need to know whether a fd is the
> > same as another,
Having conditional around the of_node pointer of the drm_bridge structure
is not necessary, since drm_bridge structure always has the of_node as its
member.
Let's drop the conditional to get a better looks, please also note that
this is following the already accepted commitments. see commit
On Tue, May 7, 2024 at 7:04 AM Christian König wrote:
>
> Am 07.05.24 um 15:39 schrieb Daniel Vetter:
> > On Tue, May 07, 2024 at 12:10:07PM +0200, Christian König wrote:
> >> Am 06.05.24 um 21:04 schrieb T.J. Mercier:
> >>> On Mon, May 6, 2024 at 2:30 AM Charan Teja Kalla
> >>> wrote:
> Hi
On Tue, May 07, 2024 at 06:25:52PM +0100, Pavel Begunkov wrote:
> On 5/7/24 17:48, Jason Gunthorpe wrote:
> > On Tue, May 07, 2024 at 09:42:05AM -0700, Mina Almasry wrote:
> >
> > > 1. Align with devmem TCP to use udmabuf for your io_uring memory. I
> > > think in the past you said it's a uapi
Am 07.05.24 um 18:46 schrieb Linus Torvalds:
On Tue, 7 May 2024 at 04:03, Daniel Vetter wrote:
It's really annoying that on some distros/builds we don't have that, and
for gpu driver stack reasons we _really_ need to know whether a fd is the
same as another, due to some messy uniqueness
On 5/7/24 18:15, Mina Almasry wrote:
On Tue, May 7, 2024 at 9:55 AM Pavel Begunkov wrote:
On 5/7/24 17:23, Christoph Hellwig wrote:
On Tue, May 07, 2024 at 01:18:57PM -0300, Jason Gunthorpe wrote:
On Tue, May 07, 2024 at 05:05:12PM +0100, Pavel Begunkov wrote:
even in tree if you give them
On 5/7/24 17:48, Jason Gunthorpe wrote:
On Tue, May 07, 2024 at 09:42:05AM -0700, Mina Almasry wrote:
1. Align with devmem TCP to use udmabuf for your io_uring memory. I
think in the past you said it's a uapi you don't link but in the face
of this pushback you may want to reconsider.
dmabuf
On Tue, May 07, 2024 at 01:48:38PM -0300, Jason Gunthorpe wrote:
> On Tue, May 07, 2024 at 09:42:05AM -0700, Mina Almasry wrote:
>
> > 1. Align with devmem TCP to use udmabuf for your io_uring memory. I
> > think in the past you said it's a uapi you don't link but in the face
> > of this pushback
On 5/7/24 17:42, Mina Almasry wrote:
On Tue, May 7, 2024 at 9:24 AM Christoph Hellwig wrote:
On Tue, May 07, 2024 at 01:18:57PM -0300, Jason Gunthorpe wrote:
On Tue, May 07, 2024 at 05:05:12PM +0100, Pavel Begunkov wrote:
even in tree if you give them enough rope, and they should not have
On Tue, May 7, 2024 at 9:55 AM Pavel Begunkov wrote:
>
> On 5/7/24 17:23, Christoph Hellwig wrote:
> > On Tue, May 07, 2024 at 01:18:57PM -0300, Jason Gunthorpe wrote:
> >> On Tue, May 07, 2024 at 05:05:12PM +0100, Pavel Begunkov wrote:
> even in tree if you give them enough rope, and they
lti-gt pm-references")
>
> Whoever is going to push this patch, please feel free to add this tag.
dim b4-shazam gets that automagically, now it was sent in reply ;)
I just pushed the patch. thanks for the patch and reviews.
>
> Thanks,
> Janusz
>
> >
> >
On 5/7/24 17:23, Christoph Hellwig wrote:
On Tue, May 07, 2024 at 01:18:57PM -0300, Jason Gunthorpe wrote:
On Tue, May 07, 2024 at 05:05:12PM +0100, Pavel Begunkov wrote:
even in tree if you give them enough rope, and they should not have
that rope when the only sensible options are page/folio
On Tue, 7 May 2024 at 04:03, Daniel Vetter wrote:
>
> It's really annoying that on some distros/builds we don't have that, and
> for gpu driver stack reasons we _really_ need to know whether a fd is the
> same as another, due to some messy uniqueness requirements on buffer
> objects various
On Mon, May 06, 2024 at 09:43:36PM +0200, Alex Bee wrote:
> Document the MIPI DSI controller for Rockchip RK3128. The integration is
> similar to PX30 so it's bindings-constraints can be re-used.
>
> Signed-off-by: Alex Bee
Acked-by: Conor Dooley
Cheers,
Conor.
signature.asc
Description:
On Mon, May 06, 2024 at 09:43:37PM +0200, Alex Bee wrote:
> The DPHY's APB clock is required to be exposed in order to be able to
> enable it and access the phy's registers.
>
> Signed-off-by: Alex Bee
Acked-by: Conor Dooley
signature.asc
Description: PGP signature
On Tue, May 07, 2024 at 09:42:05AM -0700, Mina Almasry wrote:
> 1. Align with devmem TCP to use udmabuf for your io_uring memory. I
> think in the past you said it's a uapi you don't link but in the face
> of this pushback you may want to reconsider.
dmabuf does not force a uapi, you can acquire
On Tue, May 7, 2024 at 9:24 AM Christoph Hellwig wrote:
>
> On Tue, May 07, 2024 at 01:18:57PM -0300, Jason Gunthorpe wrote:
> > On Tue, May 07, 2024 at 05:05:12PM +0100, Pavel Begunkov wrote:
> > > > even in tree if you give them enough rope, and they should not have
> > > > that rope when the
On Tue, May 07, 2024 at 09:52:28PM +0800, Cong Yang wrote:
> In V1, discussed with Doug and Linus [1], we need break out as separate
> driver for the himax83102-j02 controller. Beacuse "starry,himax83102-j02"
> and in this series "BOE nv110wum-l60" "IVO t109nw41" panels use same
> controller, they
On Tue, May 07, 2024 at 09:52:33PM +0800, Cong Yang wrote:
> The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
> controller. Hence, we add a new compatible with panel specific config.
>
> Signed-off-by: Cong Yang
Acked-by: Conor Dooley
Cheers,
Conor.
> ---
> Chage since V4:
On Tue, May 07, 2024 at 09:52:31PM +0800, Cong Yang wrote:
> The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
> controller. Hence, we add a new compatible with panel specific config.
>
> Signed-off-by: Cong Yang
Acked-by: Conor Dooley
Cheers,
Conor.
> ---
> Chage since
.corp-partner.google.com
> >
> > ---
> > .../display/panel/boe,tv101wum-nl6.yaml | 2 -
> > .../bindings/display/panel/himax,hx83102.yaml | 73 +++
> > 2 files changed, 73 insertions(+), 2 deletions(-)
> > create mode 100644
> > Do
Hi,
On Tue, May 7, 2024 at 6:44 AM cong yang
wrote:
>
> > Speaking of which, some of the panels that you add to this driver seem
> > to disable extended commands at the end of their init sequence, but
> > this one doesn't. Should it?
>
> I have confirmed with himax that disable extended
On Thu, 02 May 2024 13:56:21 +0200, AngeloGioacchino Del Regno wrote:
> Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
> per HW instance (so potentially up to six displays for multi-vdo SoCs).
>
> The MMSYS or VDOSYS is always the first component in the DDP pipeline,
>
On Thu, 02 May 2024 13:56:20 +0200, AngeloGioacchino Del Regno wrote:
> The display IPs in MediaTek SoCs support being interconnected with
> different instances of DDP IPs (for example, merge0 or merge1) and/or
> with different DDP IPs (for example, rdma can be connected with either
> color,
Hi,
On Thu, May 2, 2024 at 3:33 PM Douglas Anderson wrote:
>
> The debug print clearly lacks a \n at the end. Add it.
>
> Fixes: 8f86c82aba8b ("drm/connector: demote connector force-probes for
> non-master clients")
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/gpu/drm/drm_connector.c |
On Tue, May 07, 2024 at 05:05:12PM +0100, Pavel Begunkov wrote:
> > even in tree if you give them enough rope, and they should not have
> > that rope when the only sensible options are page/folio based kernel
> > memory (incuding large/huge folios) and dmabuf.
>
> I believe there is at least one
not now banning all virtual function tables because there is
a chance someone might probably conceivably do perhaps something
proprietary, aren't we? Let's just patch up all ways they might
use it if there is any left.
even in tree if you give them enough rope, and they should not have
that rope when
Reviewed-by: Simon Ser
Add device nodes for the video system present on the Chameleon v3.
It consists of six video interfaces and two Intel DisplayPort receivers.
Signed-off-by: Paweł Anikiel
---
.../socfpga/socfpga_arria10_chameleonv3.dts | 194 ++
1 file changed, 194 insertions(+)
diff --git
Add a DisplayPort bus type and a multi-stream-support property
indicating whether the interface supports MST.
Signed-off-by: Paweł Anikiel
---
.../devicetree/bindings/media/video-interfaces.yaml| 7 +++
include/dt-bindings/media/video-interfaces.h | 2 ++
2 files
Add dt binding for the Intel Displayport receiver FPGA IP.
It is a part of the DisplayPort Intel FPGA IP Core, and supports
DisplayPort 1.4, HBR3 video capture and Multi-Stream Transport.
The user guide can be found here:
https://www.intel.com/programmable/technical-pdfs/683273.pdf
Add v4l2 subdev driver for the Intel Displayport receiver FPGA IP.
It is a part of the DisplayPort Intel FPGA IP Core, and supports
DisplayPort 1.4, HBR3 video capture and Multi-Stream Transport.
Signed-off-by: Paweł Anikiel
---
drivers/media/platform/intel/Kconfig | 12 +
Add dt binding for the video interface present on the Google
Chameleon v3. The Chameleon v3 uses the video interface to capture
a single video source from a given HDMI or DP connector and write
the resulting frames to memory.
Signed-off-by: Paweł Anikiel
---
Add new definitions, a config struct, and a parser for the DisplayPort
media bus.
Signed-off-by: Paweł Anikiel
---
drivers/media/v4l2-core/v4l2-fwnode.c | 38 +++
include/media/v4l2-fwnode.h | 5
include/media/v4l2-mediabus.h | 17
3
Move structures describing MST sideband messages into a separate header
so that non-DRM code can use them.
Signed-off-by: Paweł Anikiel
---
include/drm/display/drm_dp_mst.h| 238
include/drm/display/drm_dp_mst_helper.h | 232 +--
2 files
Each of these registers contains a single value, but not the entire
8 bits:
DP_PAYLOAD_ALLOCATE_SET - Bit 7 Reserved
DP_PAYLOAD_ALLOCATE_START_TIME_SLOT - Bits 7:6 Reserved
DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT - Bits 7:6 Reserved
Add definitions to properly mask off values read from these
The CRC functions found in drivers/gpu/drm/display/drm_dp_mst_topology.c
may be useful for other non-DRM code that deals with DisplayPort, e.g.
v4l2 drivers for DP receivers. Move these functions to /lib.
Signed-off-by: Paweł Anikiel
---
drivers/gpu/drm/display/Kconfig | 1 +
Add v4l2 driver for the video interface present on the Google
Chameleon v3. The Chameleon v3 uses the video interface to capture
a single video source from a given HDMI or DP connector and write
the resulting frames to memory.
Signed-off-by: Paweł Anikiel
---
drivers/media/platform/Kconfig
Google Chameleon v3 is a testing device capable of emulating multiple
DisplayPort monitors, used for testing purposes. It is based on an Arria
10 SoCFPGA. This patchset adds V4L2 drivers for two IP blocks used in the
device's FPGA: the Chameleon v3 video interface, and the Intel DisplayPort
RX
> I will change the subject line to s/comeda/komeda/ when merging it.
Oh, thank you!
signature.asc
Description: PGP signature
Hi
Am 16.04.24 um 15:22 schrieb Jani Nikula:
I've these laying in a branch for a while, maybe let's try to make some
forward progress in this front.
Could you take another look at the udl patches at [1]? The second
iteration of the patches is self-contained within the driver. So the
Call fb_deferred_io_cleanup() upon destroying the framebuffer
device. Releases the internal memory.
Signed-off-by: Thomas Zimmermann
Fixes: 150f431a0831 ("drm/fbdev: Add fbdev-shmem")
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
ed, 73 insertions(+), 2 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/li
Am 07.05.24 um 12:40 schrieb Daniel Vetter:
On Tue, May 07, 2024 at 11:58:33AM +0200, Christian König wrote:
Am 06.05.24 um 08:52 schrieb Fedor Pchelkin:
On Fri, 03. May 14:08, Dmitry Antipov wrote:
On 5/3/24 11:18 AM, Christian König wrote:
Attached is a compile only tested patch, please
Call fb_deferred_io_cleanup() upon destroying the framebuffer
device. Releases the internal memory.
Signed-off-by: Thomas Zimmermann
Fixes: 808a40b69468 ("drm/fbdev-dma: Implement damage handling and deferred
I/O")
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Maarten Lankhorst
Cc:
On Tue, May 07, 2024 at 01:58:30PM +0200, Thomas Zimmermann wrote:
> Implement struct drm_client_funcs with the respective helpers and
> remove the custom code from the emulation. The generic helpers are
> equivalent in functionality.
>
> Signed-off-by: Thomas Zimmermann
> ---
>
Il 07/05/24 08:59, CK Hu (胡俊光) ha scritto:
On Thu, 2024-05-02 at 10:50 +0200, AngeloGioacchino Del Regno wrote:
Il 25/04/24 04:23, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Tue, 2024-04-09 at 14:02 +0200, AngeloGioacchino Del Regno
wrote:
Document OF graph on MMSYS/VDOSYS: this supports up to
Am 07.05.24 um 15:39 schrieb Daniel Vetter:
On Tue, May 07, 2024 at 12:10:07PM +0200, Christian König wrote:
Am 06.05.24 um 21:04 schrieb T.J. Mercier:
On Mon, May 6, 2024 at 2:30 AM Charan Teja Kalla
wrote:
Hi TJ,
Seems I have got answers from [1], where it is agreed upon epoll() is
the
The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
---
Chage since V4:
- inital cmds use lowercasehex.
V3:
The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
controller. Hence, we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
---
Chage since V4:
- No change.
V3:
https://lore.kernel.org/all/20240424023010.2099949-7-yangco...@huaqin.corp-partner.google.com
The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
---
Chage since V4:
- Depend Dous'series [1].
[1]:
The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
controller. Hence, we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
---
Chage since V4:
- No change.
V3:
DRM_PANEL_HIMAX_HX83102 is being split out from DRM_PANEL_BOE_TV101WUM_NL6.
Since the arm64 defconfig had the BOE panel driver enabled, let's also
enable the himax driver.
Signed-off-by: Cong Yang
Reviewed-by: Douglas Anderson
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1
The Starry HX83102 based mipi panel should never have been part of the boe
tv101wum driver. Discussion with Doug and Linus in V1 [1], we need a
separate driver to enable the hx83102 controller.
In hx83102 driver, add DSI commands as macros. So it can add some panels
with same control model in the
In V1, discussed with Doug and Linus [1], we need break out as separate
driver for the himax83102-j02 controller. Beacuse "starry,himax83102-j02"
and in this series "BOE nv110wum-l60" "IVO t109nw41" panels use same
controller, they have some common CMDS. So add new documentation for
this panels.
compatible for BOE nv110wum-l60 and IVO t109nw41
in dt-bindings
Note:this series depend Dous'series [1]
[1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org/
Changes in v4:
- PATCH 1/7: Update commit message and add fallback compatible.
- PATCH 2/7: Add
s part of prepare. With the new driver it does it as part
> of "enable". IMO even if the new code based on `panel-himax-hx8394.c`
> is more correct, I'd rather see you change that in a separate change.
> In this change, which is supposed to be more about code refactoring, I
> thi
On Tue, May 07, 2024 at 12:10:07PM +0200, Christian König wrote:
> Am 06.05.24 um 21:04 schrieb T.J. Mercier:
> > On Mon, May 6, 2024 at 2:30 AM Charan Teja Kalla
> > wrote:
> > > Hi TJ,
> > >
> > > Seems I have got answers from [1], where it is agreed upon epoll() is
> > > the source of issue.
On Tue, May 07, 2024 at 10:37:54AM +0200, Alexander Stein wrote:
> Hi Michael,
>
> Am Montag, 6. Mai 2024, 15:34:30 CEST schrieb Michael Walle:
> > Some bridges have very strict power-up reqirements. In this case, the
> > Toshiba TC358775. The reset has to be deasserted while *both* the DSI
> >
rm_exec_prepare_obj() by checking
num_fences and not calling dma_resv_reserve_fences()
or just call drm_exec_lock_obj() here. ref:
https://patchwork.freedesktop.org/patch/577487/
we are hit again by this. Couldn't we change drm_exec_prepare_obj() to
check num_fences and if is 0 just fallback to just d
On Tue, May 07, 2024 at 11:02:01AM +0200, Wolfram Sang wrote:
> There is a confusing pattern in the kernel to use a variable named 'timeout'
> to
> store the result of wait_for_completion_timeout() causing patterns like:
>
> timeout = wait_for_completion_timeout(...)
> if (!timeout)
Now that we have a plane create helper for kunit mocked drivers, let's
convert to it in vc4.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 34 +++---
1 file changed, 8 insertions(+), 26 deletions(-)
diff --git
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Jernej Skrabec
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 3 ++
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Heiko Stuebner
Acked-by: Heiko Stuebner
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/Kconfig | 3 +
Now that we have all the infrastructure needed, we can add some code
that will, for a given connector state and mode, compute the best output
format and bpc.
The algorithm is equivalent to the one already found in i915 and vc4.
Cc: Ville Syrjälä
Signed-off-by: Maxime Ripard
---
The vc4_dummy_plane structure was introduced as a mean to add
mock-specific fields.
However, we never really used it and it's still strictly equivalent to
vc4_plane (which is in the same situation vs drm_plane), so we can
simply remove the vc4_dummy_plane structure and make the mock code
cleaner.
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/Kconfig| 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c | 644 +
There has been some discussions recently about the infoframes sent by
drivers and if they were properly generated.
In parallel, there's been some interest in creating an infoframe-decode
tool similar to edid-decode.
Both would be much easier if we were to expose the infoframes programmed
in the
The previous patch added the generation of the infoframes matching an
HDMI connector state. Let's add a few tests to make sure it works as
expected.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 219 +
1 file changed, 219 insertions
Infoframes in KMS is usually handled by a bunch of low-level helpers
that require quite some boilerplate for drivers. This leads to
discrepancies with how drivers generate them, and which are actually
sent.
Now that we have everything needed to generate them in the HDMI
connector state, we can
The previous commit added the infrastructure to the connector state to
track what RGB Quantization should be used in a given state for an HDMI
connector.
Let's add some kunit tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
HDMI controller drivers will need to figure out the RGB range they need
to configure based on a mode and property values. Let's expose that in
the HDMI connector state so drivers can just use that value.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
This had a bunch of kunit tests to make sure our code to handle the
Broadcast RGB property behaves properly.
This requires bringing a bit of infrastructure to create mock HDMI
connectors, with custom EDIDs.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
The i915 driver has a property to force the RGB range of an HDMI output.
The vc4 driver then implemented the same property with the same
semantics. KWin has support for it, and a PR for mutter is also there to
support it.
Both drivers implementing the same property with the same semantics,
plus
hecking
num_fences and not calling dma_resv_reserve_fences()
or just call drm_exec_lock_obj() here. ref:
https://patchwork.freedesktop.org/patch/577487/
we are hit again by this. Couldn't we change drm_exec_prepare_obj() to
check num_fences and if is 0 just fallback to just do
drm_exec_lock_o
The previous patch added the bpc and format an HDMI connector needs to
be set up with for a given connector state.
Let's add a few tests to make sure it works as expected.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 509 +
drivers
The previous patch adds a new hook for HDMI connectors to filter out
configurations based on the TMDS character rate. Let's add some tests to
make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 65
Most of the HDMI controllers have an upper TMDS character rate limit
they can't exceed. On "embedded"-grade display controllers, it will
typically be lower than what high-grade monitors can provide these days,
so drivers will filter the TMDS character rate based on the controller
capabilities.
To
The previous patch stores in the connector state the expected TMDS
character rate matching the configuration of the HDMI connector. Let's
add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests
Most HDMI drivers have some code to calculate the TMDS character rate,
usually to adjust an internal clock to match what the mode requires.
Since the TMDS character rates mostly depends on the resolution, whether
we need to repeat pixels or not, the bpc count and the format, we can
now derive it
The previous patch added an helper to compute the TMDS character rate on
an HDMI connector. Let's add a few tests to make sure it works as
expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 296 +
1
A lot of HDMI drivers have some variation of the formula to calculate
the TMDS character rate from a mode, but few of them actually take all
parameters into account.
Let's create a helper to provide that rate taking all parameters into
account.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime
Now that we track the HDMI output format as part of the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 99 +-
Just like BPC, we'll add support for automatic selection of the output
format for HDMI connectors.
Let's add the needed defaults and fields for now.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c| 3 ++-
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
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/Kconfig| 1 +
drivers/gpu/drm/tests/Makefile
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
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 20
drivers/gpu/drm/drm_atomic.c
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
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
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 123 +
1 file changed, 123 insertions(+)
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_mode_object.c | 1 +
1 file changed, 1 insertion(+)
diff --git
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,
g checking patch, and the related kunit
tests
- Dropped HDMI Vendor infoframes in rockchip inno_hdmi
- Fixed the build warnings
- Link to v4:
https://lore.kernel.org/r/20231128-kms-hdmi-connector-state-v4-0-c76021583...@kernel.org
Changes in v4:
- Create unit tests for everything but infofr
gix_dp-rockchip.c | 26 +--
> include/drm/bridge/analogix_dp.h | 4 +-
> 7 files changed, 120 insertions(+), 165 deletions(-)
>
> --
> 2.39.2
>
There are some checkpatch --strict warnings, and the patch 10/14 does
not apply. Other than that the series looks very goo
Hi
Am 07.05.24 um 14:25 schrieb Rodrigo Vivi:
On Tue, May 07, 2024 at 01:58:29PM +0200, Thomas Zimmermann wrote:
Implement struct drm_client_funcs.unregister with the helpers
drm_fbdev_helper_client_unregister() and remove the custom code
from the driver. The generic helper is equivalent in
Am 05.05.24 um 16:08 schrieb Tetsuo Handa:
Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from
known context") by error replaced spin_unlock_irqrestore() with
spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite
sync_print_obj() is called from
* the DP inter pair skew issue for at least 10 us
> +*/
> + analogix_dp_reset_macro(dp);
> analogix_dp_set_lane_count(dp, dp->link_train.lane_count);
> analogix_dp_set_lane_link_training(dp);
>
> --
> 2.39.2
>
This patch does not apply on drm-misc/drm-misc-next as far as I can tell.
On Fri, May 3, 2024 at 5:13 PM Lucas Stach wrote:
>
> This check is way too late in the DP enable flow. The PLL must be locked
> much earlier, before any link training can happen. If the PLL is unlocked
> at that point in time there is something seriously wrong in the enable flow.
>
>
On Fri, May 3, 2024 at 5:12 PM Lucas Stach wrote:
>
> Make sure the controller is in a basic working state after runtime
> resume. Keep the analog function enable in the mode set path as this
> enables parts of the PHY that are only required to be powered when
> there is a data stream being sent
On Fri, May 3, 2024 at 5:12 PM Lucas Stach wrote:
>
> Platform and PHY power isn't only required when the actual display data
> stream is active, but may be required earlier to support AUX channel
> transactions. Move them into the runtime PM calls, so they are properly
> managed whenever various
1 - 100 of 351595 matches
Mail list logo
