If we switch display and update cursor together, it could lead to
modeset failed because of concurrent access to IO registers.
Add lock protection in DP's edid access to avoid this problem.
Signed-off-by: Jammy Huang
---
drivers/gpu/drm/ast/ast_mode.c | 11 +++
1 file changed, 11 insert
On 2023-04-24 16:23:17, Abhinav Kumar wrote:
>
>
> On 4/24/2023 3:54 PM, Dmitry Baryshkov wrote:
> > On Tue, 25 Apr 2023 at 01:03, Marijn Suijten
> > wrote:
> >>
> >> On 2023-04-21 16:25:15, Abhinav Kumar wrote:
> >>>
> >>>
> >>> On 4/21/2023 1:53 PM, Marijn Suijten wrote:
> The Resource Ma
Hi
Am 25.04.23 um 09:03 schrieb Jammy Huang:
If we switch display and update cursor together, it could lead to
modeset failed because of concurrent access to IO registers.
Add lock protection in DP's edid access to avoid this problem.
Thanks for the patch. I thought I fixed this issue already
With multiple pipe available we can perform management of outputs at
a more granular level, such that we're able to turn off or on several
outputs at a time, or combinations that arise from doing that.
The Weston project use VKMS when running its test suite in CI, and we
have now uses cases which
This adds support for creating multiple virtual pipes, in case one would
need to display multiple independent things on different outputs.
We use a module parameter to specify how many to create, defaulting to
just one with the possibility of specifying a maximum of 4 possible pipes.
This is of
In preparation of having multiple pipelines we need to able to choose the
correct encoder/connectors/crtc combination so pass also the index as a
bitmask as possible CRTCs for the encoder.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/vkms/vkms_output.c | 2 +-
1 file changed, 1 insertion(+), 1
And remove the run-time configuration comment regarding needing first
more than 1 pipe.
Signed-off-by: Marius Vlad
---
Documentation/gpu/vkms.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 49db221c0f52..c
On Mon, 06 Mar 2023 11:46:41 +0100, Maxime Ripard wrote:
> Here's a collection of patches that have been in the downstream tree for a
> while to add a bunch of new features to the HDMI controller.
>
> Let me know what you think,
> Maxime
>
>
> [...]
Applied to drm/drm-misc (drm-misc-next).
Tha
Hi Javier,
On Sat, Apr 22, 2023 at 07:26:13AM +0200, Javier Martinez Canillas wrote:
> Maxime Ripard writes:
> > container_of_const() allows to preserve the pointer constness and is
> > thus more flexible than inline functions.
> >
> > Let's switch all our instances of container_of() to
> > conta
Hi Thomas,
I think DP501 is OK. It doesn't use ioregs in ast_dp501_read_edid().
On 2023/4/25 下午 03:27, Thomas Zimmermann wrote:
Hi
Am 25.04.23 um 09:03 schrieb Jammy Huang:
If we switch display and update cursor together, it could lead to
modeset failed because of concurrent access to IO regi
Hello,
On 4/21/23 15:53, Maíra Canal wrote:
On 4/21/23 04:05, Marius Vlad wrote:
Hi Maíra,
Thanks a lot for taking a look!
On Thu, Apr 20, 2023 at 01:47:59PM -0300, Maíra Canal wrote:
Hi Marius,
Thanks for the changing the commit message! Just a few nits:
On 4/20/23 05:41, Marius Vlad wrot
On Mon, Apr 24, 2023 at 6:10 PM Biju Das wrote:
> Document DU found in RZ/V2L SoC. The DU block is identical to RZ/G2L
> SoC and therefore use RZ/G2L fallback to avoid any driver changes.
>
> Signed-off-by: Biju Das
> Reviewed-by: Rob Herring
> ---
> v7->v8:
> * Fixed the typo vsp2->du
> * Add
The intent here is to clear the 'available_slices' buffer before setting
some values in it.
This is an array of int, so in order to fully initialize it, we must clear
MIN_AVAILABLE_SLICES_SIZE * sizeof(int) bytes.
Compute the right length of the buffer when calling memset().
Fixes: 97bda0322b8a
On 25/04/2023 10:16, Marijn Suijten wrote:
On 2023-04-24 16:23:17, Abhinav Kumar wrote:
On 4/24/2023 3:54 PM, Dmitry Baryshkov wrote:
On Tue, 25 Apr 2023 at 01:03, Marijn Suijten
wrote:
On 2023-04-21 16:25:15, Abhinav Kumar wrote:
On 4/21/2023 1:53 PM, Marijn Suijten wrote:
The Resourc
Hi Biju,
On Mon, Apr 24, 2023 at 6:10 PM Biju Das wrote:
> Add my self as maintainer for RZ DU drivers.
> While at it, update the entries for rcar-du and shmobile.
>
> Signed-off-by: Biju Das
Thanks for your patch!
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6948,7 +6948,7 @@ F:drive
added documentation to drm_dev_unregister clarifying that devres managed
devices allocated with devm_drm_dev_alloc do not require calls to
drm_dev_put.
Signed-off-by: Brandon Pollack
---
This is my first patch to any tree. I've tried my best to read as many
kernel docs etc as possible (wip). T
Hi Philipp,
Thanks for the feedback.
> -Original Message-
> From: Philipp Zabel
> Sent: Monday, April 24, 2023 7:38 PM
> To: Biju Das
> Cc: David Airlie ; Daniel Vetter ; dri-
> de...@lists.freedesktop.org; linux-renesas-...@vger.kernel.org; Geert
> Uytterhoeven ; Fabrizio Castro
> ; Pr
Maxime Ripard writes:
> Hi Javier,
>
> On Sat, Apr 22, 2023 at 07:26:13AM +0200, Javier Martinez Canillas wrote:
>> Maxime Ripard writes:
>> > container_of_const() allows to preserve the pointer constness and is
>> > thus more flexible than inline functions.
>> >
>> > Let's switch all our instan
Hi Laurent,
Thanks for the feedback.
> -Original Message-
> From: Laurent Pinchart
> Sent: Tuesday, April 25, 2023 3:58 AM
> To: Biju Das
> Cc: David Airlie ; Daniel Vetter ; Rob
> Herring ; Krzysztof Kozlowski
> ; dri-devel@lists.freedesktop.org; linux-
> renesas-...@vger.kernel.org; d
Hi Geert,
Thanks for the feedback.
> Subject: Re: [PATCH v8 5/5] MAINTAINERS: Add maintainer for RZ DU drivers
>
> Hi Biju,
>
> On Mon, Apr 24, 2023 at 6:10 PM Biju Das wrote:
> > Add my self as maintainer for RZ DU drivers.
> > While at it, update the entries for rcar-du and shmobile.
> >
> >
On 2023-04-25 10:54:47, Dmitry Baryshkov wrote:
> On 25/04/2023 10:16, Marijn Suijten wrote:
> > On 2023-04-24 16:23:17, Abhinav Kumar wrote:
> >>
> >>
> >> On 4/24/2023 3:54 PM, Dmitry Baryshkov wrote:
> >>> On Tue, 25 Apr 2023 at 01:03, Marijn Suijten
> >>> wrote:
>
> On 2023-04-21 16:
On 06.04.2023 14:52, Himal Prasad Ghimiray wrote:
From: Aravind Iddamsetty
Count the CORRECTABLE and FATAL GT hardware errors as
signaled by relevant interrupt and respective registers.
For non relevant interrupts count them as driver interrupt error.
For platform supporting error vector regi
Hi Biju,
On Tue, Apr 25, 2023 at 10:55 AM Biju Das wrote:
> > On Mon, Apr 24, 2023 at 6:10 PM Biju Das wrote:
> > > Add my self as maintainer for RZ DU drivers.
> > > While at it, update the entries for rcar-du and shmobile.
> > >
> > > Signed-off-by: Biju Das
> >
> > Thanks for your patch!
> >
Hi Yang,
On 4/21/23 10:34, Yang Li wrote:
> Convert platform_get_resource(),devm_ioremap_resource() to a single call
> to devm_platform_ioremap_resource(), as this is exactly what this function
> does.
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 4 +---
> 1 file ch
On 4/24/2023 8:29 PM, fei.y...@intel.com wrote:
From: Fei Yang
Extract PTE patch from https://patchwork.freedesktop.org/series/116868/
to fix MTL boot issue caused by MOCS/PAT update.
v2: address comment from Matt.
Fei Yang (2):
drm/i915/mtl: Add PTE encode function
drm/i915/mtl: work
Hi Geert,
Thanks for the feedback.
> -Original Message-
> From: Geert Uytterhoeven
> Sent: Tuesday, April 25, 2023 10:39 AM
> To: Biju Das
> Cc: David Airlie ; Daniel Vetter ;
> Laurent Pinchart ; Krzysztof
> Kozlowski ; Fabrizio Castro
> ; Prabhakar Mahadev Lad lad...@bp.renesas.com>;
On 4/24/23 18:45, Marek Olšák wrote:
> Soft resets are fatal just as hard resets, but no reset is "always fatal".
> There are cases when apps keep working depending on which features are being
> used. It's still unsafe.
Agreed, in theory.
In practice, from a user PoV, right now there's pretty m
That supposedly depends on the compositor. There may be compositors for
very specific cases (e.g. Steam Deck) that handle resets very well, and
those would like to be properly notified of all resets because that's how
they get the best outcome, e.g. no corruption. A soft reset that is
unhandled by
On 4/25/23 04:44, Marius Vlad wrote:
Hello,
On 4/21/23 15:53, Maíra Canal wrote:
On 4/21/23 04:05, Marius Vlad wrote:
Hi Maíra,
Thanks a lot for taking a look!
On Thu, Apr 20, 2023 at 01:47:59PM -0300, Maíra Canal wrote:
Hi Marius,
Thanks for the changing the commit message! Just a few nit
Well signaling that something happened is not the question. We do this
for both soft as well as hard resets.
The question is if errors result in blocking further submissions with
the same context or not.
In case of a hard reset and potential loss of state we have to kill the
context, otherwi
On 4/25/23 14:08, Christian König wrote:
> Well signaling that something happened is not the question. We do this for
> both soft as well as hard resets.
>
> The question is if errors result in blocking further submissions with the
> same context or not.
>
> In case of a hard reset and potentia
On Tue, Apr 25, 2023 at 12:06 AM Andrzej Hajda wrote:
>
> In case the library is tracking busy subsystem, simply
> printing stack for every active reference will spam log
> with long, hard to read, redundant stack traces. To improve
> readabilty following changes have been made:
> - reports are pr
On Tue, Apr 25, 2023 at 12:06 AM Andrzej Hajda wrote:
>
> Similar to stack_(depot|trace)_snprint the patch
> adds helper to printing stats to memory buffer.
> It will be helpful in case of debugfs.
>
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
Am 25.04.23 um 14:14 schrieb Michel Dänzer:
On 4/25/23 14:08, Christian König wrote:
Well signaling that something happened is not the question. We do this for both
soft as well as hard resets.
The question is if errors result in blocking further submissions with the same
context or not.
In
On Thu, Apr 20, 2023 at 3:32 PM Mikhail Gavrilov
wrote:
>
> Important don't give up.
> https://youtu.be/25zhHBGIHJ8 [40 min]
> https://youtu.be/utnDR26eYBY [50 min]
> https://youtu.be/DJQ_tiimW6g [12 min]
> https://youtu.be/Y6AH1oJKivA [6 min]
> Yes the issue is everything reproducible, but time t
Hey Markus,
This patch seems to be a part of a series without being marked as
such, this causes issues when importing this patch with maintainer
tools like b4 which automatically pull in the entire series and not
just the specific patch. Either label the patch as being part of a
series ( [PATCH 1/
(+ Faith and Daniel as they have been involved in previous discussions)
Quoting Jordan Justen (2023-04-24 20:13:00)
> On 2023-04-24 02:08:43, Tvrtko Ursulin wrote:
> >
> > Being able to "list" supported extensions sounds like a reasonable
> > principle, albeit a departure from the design directio
> This patch seems to be a part of a series without being marked as such,
The mentioned patch affects only a single function implementation.
> this causes issues when importing this patch with maintainer tools
> like b4 which automatically pull in the entire series and not
> just the specific pa
On Tue, 25 Apr 2023 at 11:55, Marijn Suijten
wrote:
>
> On 2023-04-25 10:54:47, Dmitry Baryshkov wrote:
> > On 25/04/2023 10:16, Marijn Suijten wrote:
> > > On 2023-04-24 16:23:17, Abhinav Kumar wrote:
> > >>
> > >>
> > >> On 4/24/2023 3:54 PM, Dmitry Baryshkov wrote:
> > >>> On Tue, 25 Apr 2023 a
Move the existing CFB read and write code for I/O memory into
the new helpers fb_cfb_read() and fb_cfb_write(). Make them the
default fp_ops. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/Makefile | 2 +-
drivers/video/fbdev/core/fb_cfb_fops.c | 126
Always return the number of bytes read or written within the
framebuffer. Only return an errno code if framebuffer memory
was not touched. This is the semantics required by POSIX and
makes fb_read() and fb_write() compatible with IGT tests. [1]
This bug has been fixed for fb_write() long ago by
co
Use info->screen_buffer when reading and writing framebuffers in
system memory. It's the correct pointer for this address space.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fb_sys_fops.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev
Implement DRM fbdev helpers for reading and writing framebuffer
memory with the respective fbdev functions. Removes duplicate
code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 174 +---
1 file changed, 4 insertions(+), 170 deletions(-)
diff
The file-op entry points fb_read() and fb_write() verify that
info->state has been set to FBINFO_STATE_RUNNING. Remove the same
test from the implementations of struct fb_ops.{fb_read,fb_write}.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fb_sys_fops.c | 6 --
drivers/video
Push the test for info->screen_base from fb_read() and fb_write() into
the implementations of struct fb_ops.{fb_read,fb_write}. In cases where
the driver operates on info->screen_buffer, test this field instead.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/cobalt_lcdfb.c | 6 +++
Make fbdev's built-in helpers for reading and writing I/O and system
memory available to DRM. Replace DRM's internal helpers.
The first patch resolves a bug that's been in the fbdev code for
more than 15 years. Makes the read/write helpers work successfully
with the IGT tests.
Patches 2 to 4 stre
On Thu, Apr 13, 2023 at 02:44:51PM -0700, Stephen Boyd wrote:
> Quoting Maxime Ripard (2023-04-04 03:10:50)
> > Hi,
> >
> > This is a follow-up to a previous series that was printing a warning
> > when a mux has a set_parent implementation but is missing
> > determine_rate().
> >
> > The rational
Hi Dinh,
On Mon, Apr 24, 2023 at 01:32:28PM -0500, Dinh Nguyen wrote:
> On 4/4/23 05:11, Maxime Ripard wrote:
> > The SoCFGPA gate clock implements a mux with a set_parent hook, but
> > doesn't provide a determine_rate implementation.
> >
> > This is a bit odd, since set_parent() is there to, as
(cc'ing dri-devel, Jocelyn and Sam)
Hi Phil,
I've put dri-devel into cc, which is the developer's mailing list. It's
the first time I hear about this bug.
Am 25.04.23 um 16:25 schrieb ker...@linuxace.com:
Hi Thomas,
I have been trying to track down why we lost console on our Dell servers si
Perform the correct casting of the intermediate coefficients of the
RGB565 pixel conversion. Currently, the pixel conversion is using s64
for the intermediate coefficients, which is causing the IGT pixel-format
tests to fail. So, cast the operands to s32 in order to improve the
vkms' test coverage.
On 25/04/2023 17:03, Thomas Zimmermann wrote:
(cc'ing dri-devel, Jocelyn and Sam)
Hi Phil,
I've put dri-devel into cc, which is the developer's mailing list. It's
the first time I hear about this bug.
Thanks for pointing this to me, I will take a look at it.
--
Jocelyn
Am 25.04.23 um 16:
Hi,
On Tue, Apr 18, 2023 at 09:40:02AM +0200, Roman Beranek wrote:
> Propagating rate change from tcon0 all the way to pll-video0 allows for
> greater precision in matching requested display timing.
>
> Signed-off-by: Roman Beranek
> ---
> drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 3 ++-
> 1 file
On Tue, Apr 18, 2023 at 09:40:05AM +0200, Roman Beranek wrote:
> Assign pll-mipi parent to tcon0's source clock via 'assigned-clocks'.
>
> Signed-off-by: Roman Beranek
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boo
On 4/25/2023 7:26 AM, Dmitry Baryshkov wrote:
On Tue, 25 Apr 2023 at 11:55, Marijn Suijten
wrote:
On 2023-04-25 10:54:47, Dmitry Baryshkov wrote:
On 25/04/2023 10:16, Marijn Suijten wrote:
On 2023-04-24 16:23:17, Abhinav Kumar wrote:
On 4/24/2023 3:54 PM, Dmitry Baryshkov wrote:
On Tu
Thomas Zimmermann writes:
Hello Thomas,
> Always return the number of bytes read or written within the
> framebuffer. Only return an errno code if framebuffer memory
> was not touched. This is the semantics required by POSIX and
> makes fb_read() and fb_write() compatible with IGT tests. [1]
>
>
On 4/24/2023 11:54 PM, Marijn Suijten wrote:
On 2023-04-24 16:09:45, Abhinav Kumar wrote:
dither block should be present on many other chipsets too but looks like
on sm8550 was enabling it. Not sure how it was validated there. But we
are enabling dither, even other chipsets have this block.
On 2023-04-25 09:18:58, Abhinav Kumar wrote:
>
>
> On 4/24/2023 11:54 PM, Marijn Suijten wrote:
> > On 2023-04-24 16:09:45, Abhinav Kumar wrote:
> >
> dither block should be present on many other chipsets too but looks like
> on sm8550 was enabling it. Not sure how it was validated the
Thomas Zimmermann writes:
> Use info->screen_buffer when reading and writing framebuffers in
> system memory. It's the correct pointer for this address space.
>
Maybe can expand the explanation a little bit with something like this?
"The struct fb_info has a union to store the framebuffer memor
Thomas Zimmermann writes:
> The file-op entry points fb_read() and fb_write() verify that
> info->state has been set to FBINFO_STATE_RUNNING. Remove the same
> test from the implementations of struct fb_ops.{fb_read,fb_write}.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Marti
Thomas Zimmermann writes:
> Push the test for info->screen_base from fb_read() and fb_write() into
> the implementations of struct fb_ops.{fb_read,fb_write}. In cases where
> the driver operates on info->screen_buffer, test this field instead.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed
Thomas Zimmermann writes:
> Move the existing CFB read and write code for I/O memory into
> the new helpers fb_cfb_read() and fb_cfb_write(). Make them the
> default fp_ops. No functional changes.
>
It would be nice to get an explanation here about why moving these
make sense. I guess you are do
On 4/25/2023 9:33 AM, Marijn Suijten wrote:
On 2023-04-25 09:18:58, Abhinav Kumar wrote:
On 4/24/2023 11:54 PM, Marijn Suijten wrote:
On 2023-04-24 16:09:45, Abhinav Kumar wrote:
dither block should be present on many other chipsets too but looks like
on sm8550 was enabling it. Not sure
Thomas Zimmermann writes:
> Implement DRM fbdev helpers for reading and writing framebuffer
> memory with the respective fbdev functions. Removes duplicate
> code.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_fb_helper.c | 174 +---
> 1 file chang
On Fri, Apr 21, 2023 at 12:31:12AM +0200, Konrad Dybcio wrote:
> Document the SM6350 DPU.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6350-dpu.yaml | 94
> ++
> 1 file changed, 94 insertions(+)
>
> diff --git
> a/Documentation/devicetree/b
Hi Arnd,
On Mon, Apr 17, 2023 at 11:04:11PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The empty stub functions are defined as global functions, which
> causes a warning because of missing prototypes:
>
> drivers/gpu/drm/exynos/exynos_drm_g2d.h:37:5: error: no previous prototype
> f
On Fri, Apr 21, 2023 at 12:31:12AM +0200, Konrad Dybcio wrote:
> Document the SM6350 DPU.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6350-dpu.yaml | 94
> ++
> 1 file changed, 94 insertions(+)
>
> diff --git
> a/Documentation/devicetree/b
On Tue, 2023-04-25 at 16:41 +0300, Joonas Lahtinen wrote:
> (+ Faith and Daniel as they have been involved in previous discussions)
An orthogonal (but losely related) question: Is PXP the only subsystem that has
the unique problem of: Uses a delayed worker to complete all dependencies for
init..
b
On Thu, 2023-04-06 at 15:26 -0700, Harrison, John C wrote:
> From: John Harrison
>
> A pair of pre-Xe registers were being included in the Xe capture list.
> GuC was rejecting those as being invalid and logging errors about
> them. So, stop doing it.
>
alan:snip
> #define COMMON_GEN9BASE_GLOBAL
On Fri, Apr 21, 2023 at 05:43:02PM +0200, Dario Binacchi wrote:
> From: Michael Trimarchi
>
> Add documentation for "synaptics,r63353" panel.
>
> Signed-off-by: Michael Trimarchi
> Signed-off-by: Dario Binacchi
> ---
>
> .../display/panel/synaptics,r63353.yaml | 58 +++
On Fri, Apr 21, 2023 at 05:43:05PM +0200, Dario Binacchi wrote:
> From: Michael Trimarchi
>
> Add documentation for "ilitek,ili9805" panel.
>
> Signed-off-by: Michael Trimarchi
> Signed-off-by: Dario Binacchi
> ---
>
> .../display/panel/ilitek,ili9805.yaml | 60 +++
>
On 2023-04-25 06:41:54, Joonas Lahtinen wrote:
> (+ Faith and Daniel as they have been involved in previous discussions)
>
> Quoting Jordan Justen (2023-04-24 20:13:00)
> > On 2023-04-24 02:08:43, Tvrtko Ursulin wrote:
> > >
> > > Being able to "list" supported extensions sounds like a reasonable
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Remove 99% duplicated steered register list code. Also, include the
> pre-Xe steered registers in the pre-Xe list generation.
>
> Signed-off-by: John Harrison
alan: Nice work - good cleanup. Thanks so
On Sat, 22 Apr 2023 22:50:01 +0200, Sebastian Reichel wrote:
> Add compatible value for Inanbo t28cp45tn89 and make reset GPIO non
> mandatory, since it might not be connected to the CPU.
>
> Signed-off-by: Sebastian Reichel
> ---
> .../devicetree/bindings/display/panel/sitronix,st7789v.yaml
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Don't use 'xe_lp*' prefixes for register lists that are common with
> Gen8.
alan:snip
> @@ -177,32 +177,32 @@ static const struct __guc_mmio_reg_descr
> empty_regs_list[] = {
> static const struct _
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Fix Xe_LP name.
>
> Signed-off-by: John Harrison
alan:snip
> -/* GEN9/XE_LPD - Render / Compute Per-Engine-Instance */
> +/* GEN8+ Render / Compute Per-Engine-Instance */
alan: two comments on this:
The last 3 comments in this thread contain arguments that are false and
were specifically pointed out as false 6 comments ago: Soft resets are just
as fatal as hard resets. There is nothing better about soft resets. If the
VRAM is lost completely, that's a different story, and if the hard reset is
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Don't use GEN9 as a prefix for register lists that contain all GEN8
> registers.
alan:snip
alan: This patch as a stand-along looks good, so I'll provide the RB but take
note of the comment below
that s
On 4/25/23 16:28, Thomas Zimmermann wrote:
Make fbdev's built-in helpers for reading and writing I/O and system
memory available to DRM. Replace DRM's internal helpers.
The first patch resolves a bug that's been in the fbdev code for
more than 15 years. Makes the read/write helpers work successf
Hi Andrzej,
On Tue, Apr 25, 2023 at 12:05:43AM +0200, Andrzej Hajda wrote:
> Beside reusing existing code, the main advantage of ref_tracker is
> tracking per instance of wakeref. It allows also to catch double
> put.
> On the other side we lose information about the first acquire and
> the last r
Hi John,
> Dan Carpenter pointed out that 'err' was not being set in the case
> where the GuC firmware version range check fails. Fix that.
>
> Note that while this is bug fix for a previous patch (see Fixes tag
is _a_ bug fix.
> below). It is an exceedingly low risk bug. The range check is
> a
Hi,
> Andrzej Hajda (7):
> lib/ref_tracker: add unlocked leak print helper
> lib/ref_tracker: improve printing stats
> lib/ref_tracker: add printing to memory buffer
> lib/ref_tracker: remove warnings in case of allocation failure
> drm/i915: Correct type of wakeref v
On 2023-04-25 09:47:30, Abhinav Kumar wrote:
>
>
> On 4/25/2023 9:33 AM, Marijn Suijten wrote:
> > On 2023-04-25 09:18:58, Abhinav Kumar wrote:
> >>
> >>
> >> On 4/24/2023 11:54 PM, Marijn Suijten wrote:
> >>> On 2023-04-24 16:09:45, Abhinav Kumar wrote:
> >>>
> >> dither block should be pre
On Tue, 25 Apr 2023 at 19:11, Abhinav Kumar wrote:
>
>
>
> On 4/25/2023 7:26 AM, Dmitry Baryshkov wrote:
> > On Tue, 25 Apr 2023 at 11:55, Marijn Suijten
> > wrote:
> >>
> >> On 2023-04-25 10:54:47, Dmitry Baryshkov wrote:
> >>> On 25/04/2023 10:16, Marijn Suijten wrote:
> On 2023-04-24 16:2
On 4/25/2023 2:09 PM, Dmitry Baryshkov wrote:
On Tue, 25 Apr 2023 at 19:11, Abhinav Kumar wrote:
On 4/25/2023 7:26 AM, Dmitry Baryshkov wrote:
On Tue, 25 Apr 2023 at 11:55, Marijn Suijten
wrote:
On 2023-04-25 10:54:47, Dmitry Baryshkov wrote:
On 25/04/2023 10:16, Marijn Suijten wrote
On 4/19/2023 7:41 AM, Arnaud Vrac wrote:
Match the values found in the downstream msm-4.4 kernel sde driver.
Signed-off-by: Arnaud Vrac
---
Reviewed-by: Abhinav Kumar
On 4/25/2023 1:43 PM, Marijn Suijten wrote:
On 2023-04-25 09:47:30, Abhinav Kumar wrote:
On 4/25/2023 9:33 AM, Marijn Suijten wrote:
On 2023-04-25 09:18:58, Abhinav Kumar wrote:
On 4/24/2023 11:54 PM, Marijn Suijten wrote:
On 2023-04-24 16:09:45, Abhinav Kumar wrote:
dither block sho
On 2023-04-25 14:37:21, Abhinav Kumar wrote:
>
>
> On 4/25/2023 1:43 PM, Marijn Suijten wrote:
> > On 2023-04-25 09:47:30, Abhinav Kumar wrote:
> >>
> >>
> >> On 4/25/2023 9:33 AM, Marijn Suijten wrote:
> >>> On 2023-04-25 09:18:58, Abhinav Kumar wrote:
>
>
> On 4/24/2023 11:54 PM,
On 4/25/2023 2:53 PM, Marijn Suijten wrote:
On 2023-04-25 14:37:21, Abhinav Kumar wrote:
On 4/25/2023 1:43 PM, Marijn Suijten wrote:
On 2023-04-25 09:47:30, Abhinav Kumar wrote:
On 4/25/2023 9:33 AM, Marijn Suijten wrote:
On 2023-04-25 09:18:58, Abhinav Kumar wrote:
On 4/24/2023 11:
On 2023-04-25 14:55:56, Abhinav Kumar wrote:
> > I'll see whether I can include these fixes before sending v3 (got all
> > the other changes in and am all-ready to send it): is there any other
> > SoC you're seeing this issue on?
> >
>
> Thats alright, you can have it in a separate series not v3
On 2023-04-25 14:32:51, Abhinav Kumar wrote:
> > We can return NULL from dpu_hw_foo_init(), which would mean that the
> > block was skipped or is not present.
>
> An then replace the `if INTF_NONE continue` logic in dpu_rm_init with a
> check for NULL that skips, and a check
On 4/25/2023 3:15 PM, Marijn Suijten wrote:
On 2023-04-25 14:55:56, Abhinav Kumar wrote:
I'll see whether I can include these fixes before sending v3 (got all
the other changes in and am all-ready to send it): is there any other
SoC you're seeing this issue on?
Thats alright, you can have
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts. Additionally, disable previous register writes and remove
unused interrupt
The INTF_FRAME_LINE_COUNT_EN, INTF_FRAME_COUNT and INTF_LINE_COUNT
registers are already defined higher up, in the right place when sorted
numerically.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
A bunch of registers are indented with two extra spaces, looking as if
these are values corresponding to the previous register which is not the
case, rather these are simply also register offsets and should only have
a single space separating them and the #define keyword.
Signed-off-by: Marijn Sui
Neither of these SoCs has INTF0, they only have a DSI interface on index
1. Stop enabling an interrupt that can't fire.
Fixes: 3581b7062cec ("drm/msm/disp/dpu1: add support for display on SM6115")
Fixes: 5334087ee743 ("drm/msm: add support for QCM2290 MDSS")
Signed-off-by: Marijn Suijten
Reviewe
These offsets do not fall under the MDP TOP block and do not fit the
comment right above. Move them to dpu_hw_interrupts.c next to the
repsective MDP_INTF_x_OFF interrupt block offsets.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad Dybc
SM8550 exclusively has a DITHER sub-block inside the PINGPONG block and
no other registers, hence the DITHER name of the macro and a
corresponding PINGPONG block length of zero. However, the PP_BLK_ macro
name was typo'd to DIPHER rather than DITHER.
Fixes: efcd0107727c ("drm/msm/dpu: add support
Use tabs for consistency with the other interrupt register definitions,
rather than spaces.
Fixes: ed6154a136e4 ("drm/msm/disp/dpu1: add intf offsets for SC7280 target")
Fixes: 89688e2119b2 ("drm/msm/dpu: Add more of the INTF interrupt regions")
Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280X
This autorefresh disable logic in the physical command-mode encoder
consumes three callbacks to the pingpong block, and will explode in
unnecessary complexity when the same callbacks need to be called on the
interface block instead to accommodate INTF TE support. To clean this
up, move the logic i
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block. Writing these registers has no
effect, and is omitted downstream via the DPU/SDE_PINGPONG_TE feature
flag. This flag is only added to PINGPONG blocks used by hardware prior
to 5.0.0.
The exist
1 - 100 of 161 matches
Mail list logo
