Hi Janusz,
Just realized we need Fixes tag for this.
Fixes: 1f33dc0c1189 ("drm/i915: Remove extra multi-gt pm-references")
Regards,
Nirmoy
On 5/6/2024 8:02 PM, Janusz Krzysztofik wrote:
This reverts commit 1f33dc0c1189efb9ae19c6fc22b64dd3e26261fb.
There was a patch supposed to fix an issu
Hi Douglas,
On 5/3/24 11:32 PM, Douglas Anderson wrote:
[You don't often get email from diand...@chromium.org. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() a
Hi Douglas,
On 5/3/24 11:32 PM, Douglas Anderson wrote:
[You don't often get email from diand...@chromium.org. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), w
Am 03.05.24 um 23:24 schrieb Linus Torvalds:
On Fri, 3 May 2024 at 14:11, Al Viro wrote:
What we need is
* promise that ep_item_poll() won't happen after
eventpoll_release_file().
AFAICS, we do have that.
* ->poll() not playing silly buggers.
No. That is not enough at all.
On Mon, May 06, 2024 at 07:50:57PM GMT, Laurent Pinchart wrote:
> On Mon, May 06, 2024 at 10:57:17AM -0400, Sean Anderson wrote:
> > On 5/6/24 03:35, Laurent Pinchart wrote:
> > > On Mon, May 06, 2024 at 09:29:36AM +0200, Maxime Ripard wrote:
> > >> Hi Laurent, Sean,
> > >>
> > >> On Sat, May 04,
Hey Bjorn,
so I have spent a few hours seeing how we could simplify this series.
Here are my thoughts.
On Fri, 2024-04-26 at 17:01 -0500, Bjorn Helgaas wrote:
> On Fri, Apr 26, 2024 at 10:07:02AM +0200, Philipp Stanner wrote:
> > On Wed, 2024-04-24 at 15:12 -0500, Bjorn Helgaas wrote:
> > > On M
On 06/05/2024 14:38, Arunpravin Paneer Selvam wrote:
Problem statement: During the system boot time, an application request
for the bulk volume of cleared range bias memory when the clear_avail
is zero, we dont fallback into normal allocation method as we had an
unnecessary clear_avail check whic
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
> clock and DSI data lanes are in LP-11 mode. After the reset is relased,
> the b
On 25.04.24 22:30, Adam Ford wrote:
> On Thu, Apr 25, 2024 at 4:19 AM Marek Szyprowski
> wrote:
>>
>> On 12.02.2024 00:09, Adam Ford wrote:
>>> When using video sync pulses, the HFP, HBP, and HSA are divided between
>>> the available lanes if there is more than one lane. For certain
>>> timings a
On Tuesday, 7 May 2024 09:30:15 GMT+2 Nirmoy Das wrote:
> Hi Janusz,
>
>
> Just realized we need Fixes tag for this.
>
> Fixes: 1f33dc0c1189 ("drm/i915: Remove extra multi-gt pm-references")
Whoever is going to push this patch, please feel free to add this tag.
Thanks,
Janusz
>
>
> Regards,
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) return -ETIMEDOUT;
with all kinds of permutations. Check the return val
On 07/05/2024 00:23, Matthew Brost wrote:
On Thu, May 02, 2024 at 03:33:50PM +0100, Tvrtko Ursulin wrote:
Hi all,
Continuing after the brief IRC discussion yesterday regarding work queues
being prone to deadlocks or not, I had a browse around the code base and
ended up a bit confused.
When
On Mon, May 06, 2024 at 02:52:58PM -0700, Alexey Makhalov wrote:
> +#define VMWARE_HYPERVISOR_PORT 0x5658
> +#define VMWARE_HYPERVISOR_PORT_HB(VMWARE_HYPERVISOR_PORT | \
> + VMWARE_HYPERVISOR_HB)
You can't help yourself not sneaking in any cha
From: Noralf Trønnes
The MIPI DBI 2.0 specification (2005) lists only two pixel formats for
the Type C Interface (SPI) and that is 3-bits/pixel RGB111 with
2 options for bit layout.
For Type A and B (parallel) the following formats are listed: RGB332,
RGB444, RGB565, RGB666 and RGB888 (some have
From: Noralf Trønnes
mipi_dbi_machine_little_endian() should really have been called
mipi_dbi_framebuffer_little_endian() because that's the function it
performs. When I added support for these SPI displays I thought that the
framebuffers on big endian machines were also big endian, but I have
la
From: Noralf Trønnes
Add support for these pixel format property values:
- r5g6b5, RGB565
- b6x2g6x2r6x2, BGR666
BGR666 is presented to userspace as RGB888. The 2 LSB in each color
are discarded by the controller. The pixel is sent on the wire using
8 bits per word (little endian) so the control
From: Noralf Trønnes
This prepares for supporting other pixel formats than RGB565.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_mipi_dbi.c | 14 ++
include/drm/drm_mipi_dbi.h | 5 +
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/dr
From: Noralf Trønnes
DRM_FORMAT_RGB888 is 24 bits per pixel and it would be natural to send it
on the SPI bus using a 24 bits per word transfer. The problem with this
is that not all SPI controllers support 24 bpw.
Since DRM_FORMAT_RGB888 is stored in memory as little endian and the SPI
bus is b
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 verify if it fixes your problem.
LGTM, and this is similar to get_file() in __pollwait() and fput() in
free_poll
On Mon, May 06, 2024 at 02:53:00PM -0700, Alexey Makhalov wrote:
> +#define VMWARE_HYPERCALL \
> + ALTERNATIVE_3("cmpb $" \
> + __stringify(CPUID_VMWARE_FEATURES_ECX_VMMCALL) \
> +
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.
Thanks a lot for the discussion.
[1] https://lore.kernel.org/lkml/2d631f0615918...@
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 verify if it fixes your
>
On Mon, May 06, 2024 at 04:46:54PM +0200, Christian Brauner wrote:
> On Mon, May 06, 2024 at 02:47:23PM +0200, Daniel Vetter wrote:
> > On Sun, May 05, 2024 at 01:53:48PM -0700, Linus Torvalds wrote:
> > > On Sun, 5 May 2024 at 13:30, Al Viro wrote:
> > > >
> > > > 0. special-cased ->f_count
On Mon, May 06, 2024 at 04:29:44PM +0200, Christian König wrote:
> Am 04.05.24 um 20:20 schrieb Linus Torvalds:
> > On Sat, 4 May 2024 at 08:32, Linus Torvalds
> > wrote:
> > > Lookie here, the fundamental issue is that epoll can call '->poll()'
> > > on a file descriptor that is being closed conc
On Wed, Feb 21, 2024 at 06:06:24PM -0700, Karthikeyan Ramasubramanian wrote:
> Starting BDB version 239, hdr_dpcd_refresh_timeout is introduced to
> backlight BDB data. Commit 700034566d68 ("drm/i915/bios: Define more BDB
> contents") updated the backlight BDB data accordingly. This broke the
> par
On Mon, May 06, 2024 at 04:53:47PM +0200, Arnd Bergmann wrote:
> On Mon, May 6, 2024, at 15:14, Daniel Vetter wrote:
> > On Fri, May 03, 2024 at 01:22:10PM -0700, Florian Fainelli wrote:
> >> On 5/3/24 12:45, Arnd Bergmann wrote:
> >> > On Fri, May 3, 2024, at 21:28, Florian Fainelli wrote:
> >> >
On Mon, May 06, 2024 at 04:01:42PM +0200, Hans de Goede wrote:
> Hi Sima,
>
> On 5/6/24 3:38 PM, Daniel Vetter wrote:
> > On Mon, May 06, 2024 at 02:05:12PM +0200, Maxime Ripard wrote:
> >> Hi,
> >>
> >> On Mon, May 06, 2024 at 01:49:17PM GMT, Hans de Goede wrote:
> >>> Hi dma-buf maintainers, et.
On Tue, May 7, 2024, at 13:10, Daniel Vetter wrote:
> On Mon, May 06, 2024 at 04:53:47PM +0200, Arnd Bergmann wrote:
>> On Mon, May 6, 2024, at 15:14, Daniel Vetter wrote:
>> > On Fri, May 03, 2024 at 01:22:10PM -0700, Florian Fainelli wrote:
>> >> On 5/3/24 12:45, Arnd Bergmann wrote:
>>
>> This
On Wed, Apr 24, 2024 at 03:48:24PM +, Simon Ser wrote:
> On Monday, April 22nd, 2024 at 10:58, Ville Syrjala
> wrote:
>
> > drm_color_ctm_3x4 is some undocumented amgdpu private
> > uapi and thus has no business being in drm_mode.h.
> > At least move it to some amdgpu specific header, albeit
On Mon, May 06, 2024 at 11:50:36PM +, Matthew Brost wrote:
> > I think like with the gpu vma stuff we should at least aim for the core
> > data structures, and more importantly, the locking design and how it
> > interacts with core mm services to be common code.
>
> I believe this is a reasona
On Fri, May 3, 2024 at 5:12 PM Lucas Stach wrote:
>
> This isn't used, but gives the impression of the power on and power off
> platform calls being non-symmetrical. Remove the unused callback and
> rename the power_on_start to simplay power_on.
s/simplay/simply
>
> Signed-off-by: Lucas Stach
>
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
---
drivers/gpu/drm/drm_fbdev_dma.c | 56 ++---
1 file changed, 2 inserti
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
---
drivers/gpu/drm/drm_fbdev_shmem.c | 56 ++-
1 file changed, 2 inserti
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
---
drivers/gpu/drm/drm_fbdev_ttm.c | 58 +++--
1 file changed, 5 inserti
Add default implementations for unregister, restore and hotplug of
struct drm_client_funcs. The provided helpers are compatible with the
requirements of most DRM drivers.
The helpers handle support for VGA switcheroo automatically. With
DRM drivers that don't implement VGA switcheroo, this does no
All fbdev emulation has finally been converted to use struct
drm_client. Put the common client code into shared helpers.
There are three callbacks in struct drm_client_funcs, unregister,
restore and hotplug, which have similar implementations among the
various drivers. This can all be shared. i915
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
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 58 ++-
1 file changed, 3 inserti
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
---
drivers/gpu/drm/armada/armada_fbdev.c | 58 ++-
1 file changed, 3 inserti
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
---
drivers/gpu/drm/gma500/fbdev.c | 58 ++
1 file changed, 3 inserti
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 functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 21 ++---
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
---
drivers/gpu/drm/msm/msm_fbdev.c | 58 ++---
1 file changed, 3 inserti
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
---
drivers/gpu/drm/omapdrm/omap_fbdev.c | 55 ++--
1 file changed, 3 inserti
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
---
drivers/gpu/drm/radeon/radeon_fbdev.c | 66 ++-
drivers/gpu/drm/tegra/fbd
On Fri, May 3, 2024 at 5:12 PM Lucas Stach wrote:
>
> Hook up the runtime PM suspend/resume paths to make the rockchip
> glue behave more like the exynos one. The same suspend/resume
> functions are used for system sleep via the runtime PM force
> suspend/resume.
>
> Signed-off-by: Lucas Stach
>
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 functionality.
>
> Signed-off-by: Thomas Zimme
On Fri, May 3, 2024 at 5:12 PM Lucas Stach wrote:
>
> AUX transactions require the controller to be in working state and
> take a runtime PM reference. To avoid potential races beween the
> first transactions on the bus and runtime PM being set up, move the
> AUX registration behind the runtime PM
On Fri, May 3, 2024 at 5:12 PM Lucas Stach wrote:
>
> There is no reason to enable the controller clock in driver probe, as
> there is no HW initialization done in this function. Instead rely on
> either runtime PM to handle the controller clock or statically enable
> it in the driver bind routine
On Fri, May 3, 2024 at 5:13 PM Lucas Stach wrote:
>
> Now that the clock is handled dynamically through
> analogix_dp_resume/suspend and it isn't statically enabled in the
> driver probe routine, there is no need for the remove function anymore.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu
On Fri, May 3, 2024 at 5:12 PM Lucas Stach wrote:
>
> The clock is already managed by runtime PM, which is properly invoked
> from the analogix_dp_set_bridge function, so there is no need for an
> additional reference.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/bridge/analogix/analog
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
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 o
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.
>
> Signed-off-b
On Fri, May 3, 2024 at 5:13 PM Lucas Stach wrote:
>
> Setting the link bandwidth may change the PLL parameters, which will cause
> the PLL to go out of lock, so make sure to apply the MACRO_RST, which
> according to the comment is required to be pulsed after the PLL is locked.
>
> Signed-off-by: L
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 sync_d
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 fun
On Fri, May 3, 2024 at 5:12 PM Lucas Stach wrote:
>
> Currently the AUX channel support in the Analogix DP driver is severely
> limited as the AUX block of the bridge is only initialized when the video
> link is to be enabled. This is okay for the purposes of link training,
> but does not allow to
Hi,
Here's a series that creates some extra infrastructure specifically
targeted at HDMI controllers.
The idea behind this series came from a recent discussion on IRC during
which we discussed infoframes generation of i915 vs everything else.
Infoframes generation code still requires some decent
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, which
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/drivers/gpu/drm/drm_mode_o
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(+)
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
Revie
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
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
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 ++-
drivers/gpu/drm/drm_ato
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 +-
drivers/gpu/drm/tests/dr
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 R
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 fil
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 f
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/drm_hdmi_state_helper_t
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 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
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/gp
+Thomas, +Christian, +dri-devel
On Tue, May 07, 2024 at 11:42:46AM GMT, Nirmoy Das wrote:
On 5/7/2024 11:39 AM, Nirmoy Das wrote:
On 5/7/2024 10:04 AM, Shuicheng Lin wrote:
Here is the failure stack:
[ 12.988209] [ cut here ]
[ 12.988216] UBSAN: shift-out-of-bo
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 th
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
---
drivers/gpu/drm/tests/drm_
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
---
drivers/gpu/drm/display/drm_hd
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
---
drivers/gpu/drm/t
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 gen
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(+)
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 h
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 +
drivers/gpu/
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 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 +
drivers/gpu/drm/rockchip/inno_hd
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
---
drivers/gpu/drm
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 ++
drivers/gpu/drm/sun4i/sun4i_hdmi_e
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 a/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) r
Am 07.05.24 um 15:18 schrieb Lucas De Marchi:
+Thomas, +Christian, +dri-devel
On Tue, May 07, 2024 at 11:42:46AM GMT, Nirmoy Das wrote:
On 5/7/2024 11:39 AM, Nirmoy Das wrote:
On 5/7/2024 10:04 AM, Shuicheng Lin wrote:
Here is the failure stack:
[ 12.988209] [ cut here ]
On Mon, May 06, 2024 at 01:49:17PM +0200, Hans de Goede wrote:
> Hi dma-buf maintainers, et.al.,
>
> Various people have been working on making complex/MIPI cameras work OOTB
> with mainline Linux kernels and an opensource userspace stack.
>
> The generic solution adds a software ISP (for Debayer
On Mon, May 06, 2024 at 04:01:42PM +0200, Hans de Goede wrote:
> Hi Sima,
>
> On 5/6/24 3:38 PM, Daniel Vetter wrote:
> > On Mon, May 06, 2024 at 02:05:12PM +0200, Maxime Ripard wrote:
> >> Hi,
> >>
> >> On Mon, May 06, 2024 at 01:49:17PM GMT, Hans de Goede wrote:
> >>> Hi dma-buf maintainers, et.
Am 06.05.24 um 11:46 schrieb Thomas Hellström:
Hi Christian, Others.
In order to support exhaustive eviction there are some changes that I
think needs to be made to drm_exec:
1) Trylock support
(This is for ttm_bo_vm, ttm_buffer_object_init_reserved, and also for
the eviction path where I think
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
> > cl
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 Mon, May 06, 2024 at 09:20:17PM -0700, Ashok Kumar wrote:
> Found some files in Staging Drivers for which checkpatch.pl throws a CHECK to
> +remove CamelCase.
>
> For instance in program vt6655/card.c find the usage of CamelCase as
> i) Variable names eg: &priv->apTD0Rings[0]
> ii) Function nam
Hi,
Thanks for review.
Doug Anderson 于2024年5月1日周三 03:19写道：
>
> Hi,
>
> On Tue, Apr 23, 2024 at 7:30 PM Cong Yang
> wrote:
> >
> > 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 dri
Discussion with Doug and Linus in V1, we need a
separate driver to enable the hx83102 controller.
So this series this series mainly Break out as separate driver
for Starry-himax83102-j02 panels from boe tv101wum driver.
Then add BOE nv110wum-l60 and IVO t109nw41 in himax-hx83102 driver.
Add comp
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.
F
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
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 insertion(
1 - 100 of 247 matches
Mail list logo
