On Tue, Jan 14, 2025 at 01:54:56PM +0100, Herve Codina wrote:
> Hi Maxime,
>
> On Tue, 14 Jan 2025 08:40:51 +0100
> Maxime Ripard wrote:
>
> ...
>
> > >
> > > +static int sn65dsi83_reset_pipe(struct sn65dsi83 *sn65dsi83)
> > > +{
> > > + struct drm_atomic_state *state = ERR_PTR(-EINVAL);
> >
Hi,
On Thu, Jan 16, 2025 at 03:04:19AM +0200, Dmitry Baryshkov wrote:
> On Wed, Jan 15, 2025 at 10:05:32PM +0100, Maxime Ripard wrote:
> > Now that connectors are no longer necessarily created by the bridges
> > drivers themselves but might be created by drm_bridge_connector, it's
> > pretty hard
On Wed, Jan 15, 2025 at 02:34:26PM +, Daniel Stone wrote:
> On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
> > No disagreement there, we need CREATE_DUMB2.
> >
> > My point is that we have the current UAPI, and we have userspace using
> > it, but we don't have clear rules what the ioctl do
Hi,
Here's this week drm-misc-next-fixes PR.
Thanks!
Maxime
drm-misc-next-fixes-2025-01-16:
Several fixes for the new dmem cgroup controller and the HDMI framework
audio support
The following changes since commit 24c61d553302ee49e9c21dd251275ba8c36dcfe4:
Merge tag 'drm-msm-next-2025-01-07' of
Currently, only one pair of mixers is supported, so a non-zero counter
value is sufficient to identify the correct mixer within that pair.
However, future implementations may involve multiple mixer pairs. With
the current implementation, all mixers within the second pair would be
incorrectly select
On 16.01.2025 11:40, Krzysztof Karas wrote:
spin_lock/unlock() functions used in interrupt contexts could
result in a deadlock, as seen in GitLab issue #13399:
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13399,
which occurs when interrupt comes in while holding a lock.
Try to remedy
For the cases we have DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set,
the connector structure is not initialised in the bridge. That's done
by encoder. So in case of some failure in cdns_mhdp_atomic_enable,
when we schedule work for modeset_retry_work, we will use the mutex
of connector which will result
On Thu, Jan 16, 2025 at 03:36:12AM +0200, Dmitry Baryshkov wrote:
> On Wed, Jan 15, 2025 at 10:05:08PM +0100, Maxime Ripard wrote:
> > Even though the commit_tail () drm_atomic_state parameter is called
> > old_state, it's actually the state being committed which is confusing.
> >
> > It's even mo
On Tue, 14 Jan 2025 15:05:49 +0100, Louis Chauvet wrote:
> To allows driver to only use drmm objects, add helper to create
> drm_writeback_connectors with automated lifetime management.
>
> Acked-by: Thomas Zimmermann
> Signed-off-by: Louis Chauvet
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
On Tue, 14 Jan 2025 15:05:50 +0100, Louis Chauvet wrote:
> The current VKMS driver uses non-managed function to create
> writeback connectors. It is not an issue yet, but in order
> to support multiple devices easily, convert this code to
> use drm and device managed helpers.
>
>
> [ ... ]
Acked
On Tue, 14 Jan 2025 15:05:46 +0100, Louis Chauvet wrote:
> The current VKMS driver uses managed function to create crtc, but
> don't use it to properly clean the crtc workqueue. It is not an
> issue yet, but in order to support multiple devices easily,
> convert this code to use drm and device mana
On Thu, Jan 16, 2025 at 03:25:59PM +0800, Jun Nie wrote:
> Store pipes in array with removing dedicated r_pipe. There are
> 2 pipes in a drm plane at most currently, while 4 pipes are
> required for quad-pipe case. Generalize the handling to pipe pair
> and ease handling to another pipe pair later.
On Thu, Jan 16, 2025 at 03:25:58PM +0800, Jun Nie wrote:
> Add pipe as trace argument in trace_dpu_crtc_setup_mixer() to ease
> converting pipe into pipe array later.
>
> Signed-off-by: Jun Nie
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
On Thu, 19 Dec 2024 21:33:37 -0700
Alex Hung wrote:
> From: Harry Wentland
>
> The BT.709 and BT.2020 OETFs are the same, the only difference
> being that the BT.2020 variant is defined with more precision
> for 10 and 12-bit per color encodings.
>
> Both are used as encoding functions for vid
On Mon, 2025-01-13 at 10:33 +, Tvrtko Ursulin wrote:
> Instead of manually peeking into the DRM scheduler implementation
> details
> lets use the previously added helper.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanne
When adding the Device memory controller (DMEM), "select PAGE_COUNTER"
was added to CGROUP_RDMA, presumably instead of CGROUP_DMEM.
While commit e33b51499a0a6bca ("cgroup/dmem: Select PAGE_COUNTER") added
the missing select to CGROUP_DMEM, the bogus select is still there.
Remove it.
Fixes: b168ed4
Hi,
On 16/01/2025 11:38, Laurent Pinchart wrote:
On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote:
On Wed, Jan 15, 2025 at 02:34:26PM +, Daniel Stone wrote:
On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
No disagreement there, we need CREATE_DUMB2.
My point is that w
On Thu, Jan 16, 2025 at 05:49:43PM +0800, Jun Nie wrote:
> Dmitry Baryshkov 于2025年1月16日周四 16:00写道：
> >
> > On Thu, Jan 16, 2025 at 03:25:59PM +0800, Jun Nie wrote:
> > > Store pipes in array with removing dedicated r_pipe. There are
> > > 2 pipes in a drm plane at most currently, while 4 pipes are
> > > > -Original Message-
> > > > From: dri-devel On
> > > > Behalf Of Arun R Murthy
> > > > Sent: Wednesday, January 8, 2025 11:09 AM
> > > > To: dri-devel@lists.freedesktop.org;
> > > > intel-...@lists.freedesktop.org;
> > > > intel- x...@lists.freedesktop.org
> > > > Cc: Murthy, Arun R
> > > > 68b31c0563a4c0 100644
> > > > --- a/drivers/gpu/drm/drm_plane.c
> > > > +++ b/drivers/gpu/drm/drm_plane.c
> > > > @@ -191,7 +191,10 @@ modifiers_ptr(struct drm_format_modifier_blob
> > > > *blob)
> > > > return (struct drm_format_modifier *)(((char *)blob) + blob-
> > > > >modifiers
Hi,
On 16/01/2025 10:09, Thomas Zimmermann wrote:
Hi
Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
[...]
My point is that we have the current UAPI, and we have userspace using
it, but we don't have clear rules what the ioctl does with specific
parameters, and we don't document how it has to
On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen
wrote:
> On 16/01/2025 10:09, Thomas Zimmermann wrote:
> > Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
> > [...]
> >>
> >> My point is that we have the current UAPI, and we have userspace using
> >> it, but we don't have clear rules what the ioctl d
Dmitry Baryshkov 于2025年1月16日周四 16:14写道：
>
> On Thu, Jan 16, 2025 at 03:26:02PM +0800, Jun Nie wrote:
> > The content of every half of screen is sent out via one interface in
> > dual-DSI case. The content for every interface is blended by a LM
> > pair in quad-pipe case, thus a LM pair should not
On Tue, 2025-01-14 at 10:59 +, Tvrtko Ursulin wrote:
> There is no need to check the boolean in the work item's prologues
> since
> the boolean can be set at any later time anyway.
>
> The helper which pauses submission sets it and synchronously cancels
> the
> work and helpers which queue the
Hi,
On 16/01/2025 12:17, Geert Uytterhoeven wrote:
On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen
wrote:
On 16/01/2025 10:09, Thomas Zimmermann wrote:
Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
[...]
My point is that we have the current UAPI, and we have userspace using
it, but we don't
Hello Dmitry, Maxime, All,
On Fri, 10 Jan 2025 11:58:19 +0100
Luca Ceresoli wrote:
> Hi Dmitry,
>
> On Thu, 2 Jan 2025 13:01:49 +0100
> Luca Ceresoli wrote:
>
> > > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > b/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > index
> > > > f8b
On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote:
> On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen
> wrote:
> > On 16/01/2025 10:09, Thomas Zimmermann wrote:
> > > Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
> > > [...]
> > >>
> > >> My point is that we have the current UAPI, a
Hi drm maintainers,
On 14/01/2025 07:41, Stephen Rothwell wrote:
Hi all,
On Fri, 20 Dec 2024 15:42:08 +1100 Stephen Rothwell
wrote:
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced these warnings:
drivers/gpu/drm/xlnx/zynqmp_dpsub.h:86: warning: Function parame
On Thu, Jan 16, 2025 at 06:20:48PM +0800, Jun Nie wrote:
> Dmitry Baryshkov 于2025年1月16日周四 16:14写道：
> >
> > On Thu, Jan 16, 2025 at 03:26:02PM +0800, Jun Nie wrote:
> > > The content of every half of screen is sent out via one interface in
> > > dual-DSI case. The content for every interface is ble
spin_lock/unlock() functions used in interrupt contexts could
result in a deadlock, as seen in GitLab issue #13399:
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13399,
which occurs when interrupt comes in while holding a lock.
Try to remedy the problem by saving irq state before spin lo
On Thu, Jan 16, 2025 at 11:32:36AM +0100, Luca Ceresoli wrote:
> Hello Dmitry, Maxime, All,
>
> On Fri, 10 Jan 2025 11:58:19 +0100
> Luca Ceresoli wrote:
>
> > Hi Dmitry,
> >
> > On Thu, 2 Jan 2025 13:01:49 +0100
> > Luca Ceresoli wrote:
> >
> > > > > diff --git a/drivers/gpu/drm/bridge/samsu
On Wed, Jan 15, 2025 at 10:05:31PM +0100, Maxime Ripard wrote:
> We have access to the global drm_atomic_state from a drm_bridge_state,
> but since it's fairly indirect it's not as obvious as it can be for
> other KMS entities.
>
> Provide a helper to make it easier to figure out.
>
> Signed-off-
On Wed, Jan 15, 2025 at 10:05:29PM +0100, Maxime Ripard wrote:
> All the bridge atomic hooks were using the old_bridge_state name for
> their drm_bridge_state parameter. However, this state is the current
> state being committed for all of them, which ends up being confusing.
>
> Let's rename it t
On Thu, Jan 16, 2025 at 02:43:37AM +0200, Dmitry Baryshkov wrote:
> On Wed, Jan 15, 2025 at 10:05:30PM +0100, Maxime Ripard wrote:
> > The current bridge state is accessible from the drm_bridge structure,
> > but since it's fairly indirect it's not easy to figure out.
> >
> > Provide a helper to r
On Thu, Jan 16, 2025 at 12:34:39PM +0200, Tomi Valkeinen wrote:
> Hi drm maintainers,
>
> On 14/01/2025 07:41, Stephen Rothwell wrote:
> > Hi all,
> >
> > On Fri, 20 Dec 2024 15:42:08 +1100 Stephen Rothwell
> > wrote:
> > >
> > > After merging the drm-misc tree, today's linux-next build (htmld
Hi John,
> From: John Harrison
>
> To aid debug of sporadic issues, include the requested frequency in
> the debug message as well as the actual frequency. That way we know
> for certain that the clamping is not because the driver forgot to ask.
>
...
> } else if (delta_ms > 200) {
>
On Thu, 16 Jan 2025 at 10:35, Dmitry Baryshkov
wrote:
> On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote:
> > On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen
> > wrote:
> > > On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb
> > > buffers are the only buffe
Hi Luca,
On Thu, Jan 16, 2025 at 11:32:36AM +0100, Luca Ceresoli wrote:
> Hello Dmitry, Maxime, All,
>
> On Fri, 10 Jan 2025 11:58:19 +0100
> Luca Ceresoli wrote:
>
> > Hi Dmitry,
> >
> > On Thu, 2 Jan 2025 13:01:49 +0100
> > Luca Ceresoli wrote:
> >
> > > > > diff --git a/drivers/gpu/drm/br
> > > On Fri, Jan 10, 2025 at 01:15:30AM +0530, Arun R Murthy wrote:
> > > > ImageEnhancemenT(IET) hardware interpolates the LUT value to
> > > > generate the enhanced output image. LUT takes an input value,
> > > > outputs a new value based on the data within the LUT. 1D LUT can
> > > > remap indi
> > > On Fri, Jan 10, 2025 at 01:15:29AM +0530, Arun R Murthy wrote:
> > > > Display Histogram is an array of bins and can be generated in many
> > > > ways referred to as modes.
> > > > Ex: HSV max(RGB), Wighted RGB etc.
> > > >
> > > > Understanding the histogram data format(Ex: HSV max(RGB))
> >
The kingdisplay-kd110n11-51ie is a 10.95" TFT panel.
which fits in nicely with the existing panel-boe-tv101wum-nl6 driver.
>From the datasheet, MIPI needs to keep the LP11 state before the
lcm_reset pin is pulled high, so increase lp11_before_reset flag.
Signed-off-by: Langyan Ye
---
.../gpu/drm
The starry-2082109qfh040022-50e is a 10.95" TFT panel.
which fits in nicely with the existing panel-boe-tv101wum-nl6 driver.
>From the datasheet, MIPI needs to keep the LP11 state before the
lcm_reset pin is pulled high, so increase lp11_before_reset flag.
Signed-off-by: Langyan Ye
---
.../gpu/d
The kingdisplay-kd110n11-51ie and starry-2082109qfh040022-50e are both 10.95"
TFT panels.
which fits in nicely with the existing panel-boe-tv101wum-nl6 driver.From the
datasheet,
MIPI needs to keep the LP11 state before the lcm_reset pin is pulled high, so
increase lp11_before_reset flag.
Langy
Currently the job free work item will lock sched->job_list_lock first time
to see if there are any jobs, free a single job, and then lock again to
decide whether to re-queue itself if there are more finished jobs.
Since drm_sched_get_finished_job() already looks at the second job in the
queue we c
On 16/01/2025 10:02, Philipp Stanner wrote:
> On Mon, 2025-01-13 at 10:33 +, Tvrtko Ursulin wrote:
>> Instead of manually peeking into the DRM scheduler implementation
>> details
>> lets use the previously added helper.
>>
>> Signed-off-by: Tvrtko Ursulin
>> Cc: Christian König
>> Cc: Danilo
On Thu, Jan 16, 2025 at 06:33:48AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 15, 2025 at 09:34:19AM -0400, Jason Gunthorpe wrote:
> > > Or do you mean some that don't have pages associated with them, and
> > > thus have pfn_valid fail on them? They still have a PFN, just not
> > > one that is
> On Thu, Jan 16, 2025 at 12:33:30PM +, Murthy, Arun R wrote:
> > > > > On Fri, Jan 10, 2025 at 01:15:30AM +0530, Arun R Murthy wrote:
> > > > > > ImageEnhancemenT(IET) hardware interpolates the LUT value to
> > > > > > generate the enhanced output image. LUT takes an input value,
> > > > > > o
> On Thu, Jan 16, 2025 at 12:33:20PM +, Murthy, Arun R wrote:
> > > > > On Fri, Jan 10, 2025 at 01:15:29AM +0530, Arun R Murthy wrote:
> > > > > > Display Histogram is an array of bins and can be generated in
> > > > > > many ways referred to as modes.
> > > > > > Ex: HSV max(RGB), Wighted RGB
On Thu, Jan 16, 2025 at 01:33:43PM +, Murthy, Arun R wrote:
> > On Thu, Jan 16, 2025 at 12:33:20PM +, Murthy, Arun R wrote:
> > > > > > On Fri, Jan 10, 2025 at 01:15:29AM +0530, Arun R Murthy wrote:
> > > > > > > Display Histogram is an array of bins and can be generated in
> > > > > > > ma
On Thu, Jan 16, 2025 at 09:05:30PM +0800, Langyan Ye wrote:
> The kingdisplay-kd110n11-51ie and starry-2082109qfh040022-50e are both 10.95"
> TFT panels.
> which fits in nicely with the existing panel-boe-tv101wum-nl6 driver.From the
> datasheet,
> MIPI needs to keep the LP11 state before the lcm
On Tue, Nov 5, 2024 at 9:14 PM Hamza Mahfooz wrote:
>
> Video Format Data Blocks (VFDBs) contain the necessary information that
> needs to be fed to the Optimized Video Timings (OVT) Algorithm.
> Also, we require OVT support to cover modes that aren't supported by
> earlier standards (e.g. CVT). S
Dmitry Baryshkov 于2025年1月16日周四 16:18写道：
>
> On Thu, Jan 16, 2025 at 03:26:03PM +0800, Jun Nie wrote:
> > Support SSPP assignment for quad-pipe case with unified method.
> > The first 2 pipes can share a set of mixer config and enable
> > multi-rect mode if condition is met. It is also the case for
Hi Javier,
Thanks for the review.
On Tue, Jan 14, 2025 at 11:21:25PM +0100, Javier Martinez Canillas wrote:
> John Keeping writes:
> Thanks for your patches!
>
> > The ssd132x family of chips require the result pulse to be at least
> > 100us in length. Increase the reset time to meet this requ
The ssd132x buffer is encoded one pixel per nibble, with two pixels in
each byte. When encoding an 8-bit greyscale input, take the top 4-bits
as the value and ensure the two pixels are distinct and do not overwrite
each other.
Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED co
On Thu, Jan 16, 2025 at 03:26:01PM +0800, Jun Nie wrote:
> Currently, only 2 pipes are used at most for a plane. A stage structure
> describes the configuration for a mixer pair. So only one stage is needed
> for current usage cases. The quad-pipe case will be added in future and 2
> stages are use
Alexander,
- Ursprüngliche Mail -
> Von: "Alexander Usyskin"
> Create master device without partition when
> CONFIG_MTD_PARTITIONED_MASTER flag is unset.
>
> This streamlines device tree and allows to anchor
> runtime power management on master device in all cases.
Please explain in mor
When merging 2 drivers common object files were not deduplicated.
Fixes: dcec16efd677 ("drm/sti: Build monolithic driver")
Cc: sta...@kernel.org
Signed-off-by: Rolf Eike Beer
---
drivers/gpu/drm/sti/Makefile | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/sti/Makefile b/driv
On Wed, Jan 15, 2025 at 7:49 PM Christian König
wrote:
>
> Am 15.01.25 um 07:18 schrieb zhaoyang.huang:
> > From: Zhaoyang Huang
> >
> > When using dma-buf as memory pool for VMM. The vmf_insert_pfn will
> > apply PTE_SPECIAL on pte which have vm_normal_page report bad_pte and
> > return NULL. Th
Two small fixes for ssd132x family chips in the ssd130x driver.
Since v1:
- One patch is dropped as it turns out not to be needed
- Both remaining patches have typo fixes in the commit messages and
added trailers
John Keeping (2):
drm/ssd130x: fix ssd132x encoding
drm/ssd130x: ensure ssd132
On Thu, Jan 16, 2025 at 03:26:00PM +0800, Jun Nie wrote:
> Split the PIPES_PER_STAGE definition per plane and mixer pair.
Why are you trying to repeat commit subject? I noticed this pattern in
other patches too.
> Currently, 2 pipes are supported for a plane at most. A stage struct
> contains con
Hi
Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
[...]
My point is that we have the current UAPI, and we have userspace using
it, but we don't have clear rules what the ioctl does with specific
parameters, and we don't document how it has to be used.
Perhaps the situation is bad, and all we
On Thu, Jan 16, 2025 at 03:26:02PM +0800, Jun Nie wrote:
> The content of every half of screen is sent out via one interface in
> dual-DSI case. The content for every interface is blended by a LM
> pair in quad-pipe case, thus a LM pair should not blend any content
> that cross the half of screen i
On Thu, Jan 16, 2025 at 03:26:03PM +0800, Jun Nie wrote:
> Support SSPP assignment for quad-pipe case with unified method.
> The first 2 pipes can share a set of mixer config and enable
> multi-rect mode if condition is met. It is also the case for
> the later 2 pipes.
Missing problem description.
Hi,
On 14.01.25 16:58, Michal Koutný wrote:
On Tue, Jan 14, 2025 at 04:39:12PM +0100, Friedrich Vock
wrote:
If the current css doesn't contain any pool that is a descendant of
the "pool" (i.e. when found_descendant == false), then "pool" will
point to some unrelated pool. If the current css h
On Thu, Jan 16, 2025 at 03:26:04PM +0800, Jun Nie wrote:
> Currently, 2 pipes are supported at most. It is enough to check id to
> know which pipe is in multi-rect mode and disable it. Multiple pairs
> are used and need to check multirect_index to decide what pipes are in
> multi-rect mode to disab
Hi Krzysztof,
At 2025-01-12 18:46:28, "Andy Yan" wrote:
>
>Hi Krzysztof,
>
>At 2025-01-12 17:27:18, "Krzysztof Kozlowski" wrote:
>>On Sat, Jan 11, 2025 at 07:26:08PM +0800, Andy Yan wrote:
>>># See compatible-specific constraints below.
>>>clocks:
>>> @@ -120,43 +133,98 @@ allOf:
>>>
The bounding rectangle is adjusted to ensure it aligns to
SSD132X_SEGMENT_WIDTH, which may adjust the pitch. Calculate the pitch
after aligning the left and right edge.
Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller
family")
Signed-off-by: John Keeping
Reviewed-b
Hi,
On Thu, Jan 16, 2025 at 02:43:37AM +0200, Dmitry Baryshkov wrote:
> On Wed, Jan 15, 2025 at 10:05:30PM +0100, Maxime Ripard wrote:
> > The current bridge state is accessible from the drm_bridge structure,
> > but since it's fairly indirect it's not easy to figure out.
> >
> > Provide a helper
On Thu, Jan 16, 2025 at 03:26:05PM +0800, Jun Nie wrote:
> Request 4 mixers and 4 DSC for the case that both dual-DSI and DSC are
> enabled.
Why? What is the issue that you are solving?
> 4 pipes are preferred for dual DSI case for it is power optimal
> for DSC.
>
> Signed-off-by: Jun Nie
> ---
On Thu, Jan 16, 2025 at 06:33:48AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 15, 2025 at 09:34:19AM -0400, Jason Gunthorpe wrote:
> > > Or do you mean some that don't have pages associated with them, and
> > > thus have pfn_valid fail on them? They still have a PFN, just not
> > > one that is
On Wed, Jan 15, 2025 at 09:58:59AM +0100, Rolf Eike Beer wrote:
> When merging 2 drivers common object files were not deduplicated.
>
> Fixes: dcec16efd677 ("drm/sti: Build monolithic driver")
> Cc: sta...@kernel.org
> Signed-off-by: Rolf Eike Beer
> ---
> drivers/gpu/drm/sti/Makefile | 2 --
>
On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote:
> On Wed, Jan 15, 2025 at 02:34:26PM +, Daniel Stone wrote:
> > On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
> > > No disagreement there, we need CREATE_DUMB2.
> > >
> > > My point is that we have the current UAPI, and we
On Wed, Jan 15, 2025 at 08:02:01PM +0100, Simona Vetter wrote:
> On Wed, Jan 15, 2025 at 12:18:13PM -0500, Sasha Levin wrote:
> > On Wed, Jan 15, 2025 at 12:15:46PM +0100, Simona Vetter wrote:
> > > On Wed, Jan 15, 2025 at 10:38:34AM +0100, Greg KH wrote:
> > > So my understanding is that you got c
Dmitry Baryshkov 于2025年1月16日周四 16:00写道：
>
> On Thu, Jan 16, 2025 at 03:25:59PM +0800, Jun Nie wrote:
> > Store pipes in array with removing dedicated r_pipe. There are
> > 2 pipes in a drm plane at most currently, while 4 pipes are
> > required for quad-pipe case. Generalize the handling to pipe p
John Keeping writes:
Hello John,
> Two small fixes for ssd132x family chips in the ssd130x driver.
>
> Since v1:
> - One patch is dropped as it turns out not to be needed
> - Both remaining patches have typo fixes in the commit messages and
> added trailers
>
> John Keeping (2):
> drm/ssd130
Jun Nie 于2025年1月16日周四 17:49写道：
>
> Dmitry Baryshkov 于2025年1月16日周四 16:00写道：
> >
> > On Thu, Jan 16, 2025 at 03:25:59PM +0800, Jun Nie wrote:
> > > Store pipes in array with removing dedicated r_pipe. There are
> > > 2 pipes in a drm plane at most currently, while 4 pipes are
> > > required for qua
On Thu, Jan 16, 2025 at 09:42:54AM +0100, Maxime Ripard wrote:
> Hi,
>
> On Thu, Jan 16, 2025 at 03:04:19AM +0200, Dmitry Baryshkov wrote:
> > On Wed, Jan 15, 2025 at 10:05:32PM +0100, Maxime Ripard wrote:
> > > Now that connectors are no longer necessarily created by the bridges
> > > drivers the
When converting to folios the cleanup path of shmem_get_pages() was
missed. When a DMA remap fails and the max segment size is greater than
PAGE_SIZE it will attempt to retry the remap with a PAGE_SIZEd segment
size. The cleanup code isn't properly using the folio apis and as a
result isn't handlin
> The current VKMS driver uses non-managed function to create encoders. It
> is not an issue yet, but in order to support multiple devices easily,
> convert this code to use drm and device managed helpers.
>
> Reviewed-by: Maxime Ripard
> Reviewed-by: Maíra Canal
> Reviewed-by: Thomas Zimmermann
On Mon, Jan 13, 2025 at 06:12:03PM +0100, Louis Chauvet wrote:
> On 13/01/25 - 18:09, Louis Chauvet wrote:
> > The current VKMS driver uses non-managed function to create
> > writeback connectors. It is not an issue yet, but in order
> > to support multiple devices easily, convert this code to
> >
> The current VKMS driver uses managed function to create crtc, but
> don't use it to properly clean the crtc workqueue. It is not an
> issue yet, but in order to support multiple devices easily,
> convert this code to use drm and device managed helpers.
>
> Signed-off-by: Louis Chauvet
> Acked-b
> The current VKMS driver uses non-managed function to create
> writeback connectors. It is not an issue yet, but in order
> to support multiple devices easily, convert this code to
> use drm and device managed helpers.
>
> Acked-by: Thomas Zimmermann
> Signed-off-by: Louis Chauvet
> Acked-by: M
On Thu, 16 Jan 2025, Alex Deucher wrote:
> On Tue, Nov 5, 2024 at 9:14 PM Hamza Mahfooz wrote:
>>
>> Video Format Data Blocks (VFDBs) contain the necessary information that
>> needs to be fed to the Optimized Video Timings (OVT) Algorithm.
>> Also, we require OVT support to cover modes that aren'
On Thu, Jan 16, 2025 at 04:13:13PM +0100, Christian König wrote:
>> But this, fundamentally, is importers creating attachments and then
>> *ignoring the lifetime rules of DMABUF*. If you created an attachment,
>> got a move and *ignored the move* because you put the PFN in your own
>> VMA, then you
On 10/01/2025 11:14, Tvrtko Ursulin wrote:
After commit f7fe64ad0f22 ("drm/sched: Split free_job into own work item")
and with drivers who use the unordered workqueue sched_jobs can be freed
in parallel as soon as the complete_all(&entity->entity_idle) is called.
This makes all dereferencing in
Hi Dmitry,
On Wed, Jan 15, 2025 at 12:21:39PM +0200, Dmitry Baryshkov wrote:
> On Tue, Jan 14, 2025 at 10:38:53PM +0100, Sasha Finkelstein via B4 Relay
> wrote:
> > +static int adp_dsi_host_attach(struct mipi_dsi_host *host,
> > + struct mipi_dsi_device *dev)
> > +{
> > +
> The current VKMS driver uses non-managed function to create connectors. It
> is not an issue yet, but in order to support multiple devices easily,
> convert this code to use drm and device managed helpers.
>
> Reviewed-by: Maxime Ripard
> Reviewed-by: Maíra Canal
> Reviewed-by: Thomas Zimmerma
It's not obvious off-hand which CRTCs will get a page-flip event
when using this flag in an atomic commit, because it's all
implicitly implied based on the contents of the atomic commit.
Document requirements for using this flag and
Note, because prepare_signaling() runs right after
drm_atomic_set
The function mtk_dp_wait_hpd_asserted() may be called before the
`mtk_dp->drm_dev` pointer is assigned in mtk_dp_bridge_attach().
Specifically it can be called via this callpath:
- mtk_edp_wait_hpd_asserted
- [panel probe]
- dp_aux_ep_probe
Using "drm" level prints anywhere in this callpath cau
The current VKMS driver uses non-managed function to create connectors. It
is not an issue yet, but in order to support multiple devices easily,
convert this code to use drm and device managed helpers.
Reviewed-by: Maxime Ripard
Reviewed-by: Maíra Canal
Reviewed-by: Thomas Zimmermann
Reviewed-b
The current VKMS driver uses non-managed function to create encoders. It
is not an issue yet, but in order to support multiple devices easily,
convert this code to use drm and device managed helpers.
Reviewed-by: Maxime Ripard
Reviewed-by: Maíra Canal
Reviewed-by: Thomas Zimmermann
Reviewed-by:
The current VKMS driver uses non-managed function to create
writeback connectors. It is not an issue yet, but in order
to support multiple devices easily, convert this code to
use drm and device managed helpers.
Acked-by: Thomas Zimmermann
Acked-by: Maxime Ripard
Reviewed-by: José Expósito
Sign
To allows driver to only use drmm objects, add helper to create
drm_writeback_connectors with automated lifetime management.
Acked-by: Thomas Zimmermann
Acked-by: Maxime Ripard
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/drm_writeback.c | 74 +
incl
Add drmm_alloc_ordered_workqueue(), a helper that provides managed ordered
workqueue cleanup. The workqueue will be destroyed with the final
reference of the DRM device.
Reviewed-by: Thomas Zimmermann
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/drm_managed.c | 8
include/drm/drm_
As the old drm and the new drmm variants of drm_writeback_connector
requires almost the same initialization, create an internal helper to do
most of the initialization work.
Currently there is no cleanup function for writeback connectors. To allows
implementation of drmm variant of writeback conne
The current VKMS driver uses managed function to create crtc, but
don't use it to properly clean the crtc workqueue. It is not an
issue yet, but in order to support multiple devices easily,
convert this code to use drm and device managed helpers.
Acked-by: Maxime Ripard
Reviewed-by: José Expósito
The current implementation of drm_writeback_connector initialization does
not properly clean up all resources in case of failure (allocated
properties and possible_encoders). Add this cleaning in case of failure.
Acked-by: Thomas Zimmermann
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/drm_w
To simplify the memory managment, this series replace all manual drm
object managment by drm-managed one. This way the VKMS code don't have to
manage it directly and the DRM core will handle the object destruction.
No functional changes are intended in this series.
PATCH 1/8: Migrate connector ma
This commit adds a compatible for the MediaTek MT8370 SoC, with an
integrated ARM Mali G57 MC2 GPU (Valhall-JM, dual core).
Signed-off-by: Louis-Alexis Eyraud
---
Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/D
On Thu, Jan 16, 2025 at 08:56:36AM -0500, Brian Geffon wrote:
> When converting to folios the cleanup path of shmem_get_pages() was
> missed. When a DMA remap fails and the max segment size is greater than
> PAGE_SIZE it will attempt to retry the remap with a PAGE_SIZEd segment
> size. The cleanup
1 - 100 of 159 matches
Mail list logo
