From: Jocelyn Falempe <jfalempe@redhat.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Christian Koenig <christian.koenig@amd.com>,
Huang Rui <ray.huang@amd.com>,
Matthew Auld <matthew.auld@intel.com>,
Matthew Brost <matthew.brost@intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 03/10] drm/i915/display/i9xx: Add a disable_tiling() for i9xx planes
Date: Mon, 28 Jul 2025 13:19:19 +0200 [thread overview]
Message-ID: <a7ada116-5613-4518-a151-7c8db9874ede@redhat.com> (raw)
In-Reply-To: <aHviiKb0EnQbNksL@intel.com>
On 19/07/2025 20:23, Ville Syrjälä wrote:
> On Wed, Jun 18, 2025 at 11:31:21AM +0200, Jocelyn Falempe wrote:
>> drm_panic draws in linear framebuffer, so it's easier to re-use the
>> current framebuffer, and disable tiling in the panic handler, to show
>> the panic screen.
>> This assumes that the alignment restriction is always smaller in
>> linear than in tiled.
>> It also assumes that the linear framebuffer size is always smaller
>> than the tiled.
>>
>> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
>> ---
>>
>> v7:
>> * Reword commit message about alignment/size when disabling tiling (Ville Syrjälä)
>>
>> drivers/gpu/drm/i915/display/i9xx_plane.c | 23 +++++++++++++++++++
>> .../drm/i915/display/intel_display_types.h | 2 ++
>> 2 files changed, 25 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c b/drivers/gpu/drm/i915/display/i9xx_plane.c
>> index 8f15333a4b07..0807fae12450 100644
>> --- a/drivers/gpu/drm/i915/display/i9xx_plane.c
>> +++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
>> @@ -905,6 +905,27 @@ static const struct drm_plane_funcs i8xx_plane_funcs = {
>> .format_mod_supported_async = intel_plane_format_mod_supported_async,
>> };
>>
>> +static void i9xx_disable_tiling(struct intel_plane *plane)
>> +{
>> + struct intel_display *display = to_intel_display(plane);
>> + enum i9xx_plane_id i9xx_plane = plane->i9xx_plane;
>> + u32 dspcntr;
>> + u32 reg;
>> +
>> + dspcntr = intel_de_read_fw(display, DSPCNTR(display, i9xx_plane));
>> + dspcntr &= ~DISP_TILED;
>> + intel_de_write_fw(display, DSPCNTR(display, i9xx_plane), dspcntr);
>> +
>> + if (DISPLAY_VER(display) >= 4) {
>> + reg = intel_de_read_fw(display, DSPSURF(display, i9xx_plane));
>> + intel_de_write_fw(display, DSPSURF(display, i9xx_plane), reg);
>> +
>> + } else {
>> + reg = intel_de_read_fw(display, DSPADDR(display, i9xx_plane));
>> + intel_de_write_fw(display, DSPADDR(display, i9xx_plane), reg);
>> + }
>> +}
>
> I thought I already shot this down before, but apparently this
> got merged now :(
Sorry for that. I replied to that thread, but I didn't get answer [1]
>
> Just to reiterate why we don't want these 'disable tiling' hacks:
> - different tiling formats have different stride/alignment/watermark
> requirements so one can't safely change from one tiling to another
I agree that going from one tiling format to another is not safe. But
from my understanding, going from tiling to linear should be possible.
Do you have an example, where the stride/alignment/watermark requirement
in tiled would be incompatible in Linear (for the same resolution)?
> - this completely fails to account for the TILEOFF vs. LINOFF stuff
Pardon my ignorance, can you explain what it is, and how it can break or
make the output unreadable?
> - etc.
>
> So IMO these hacks must be removed and instead the code must learn how
> to propetly write the tiled data. igt has all the code for that btw
> (twice over IIRC) so shouldn't be that hard.
Regarding the tiling format, I usually test on hardware to check that
the image is correct. But I have only a few of them, and as the format
is platform dependent, and sometime also depends on the memory
configuration. For me it looks very hard to get it right.
I've done it only for Y-tile and 4-tile, but only when DPT is enabled
(which means it's only the few latest generations).
>
> I suppose the only hack we need to keep is to disable compression,
> mainly because (IIRC) on flat CCS systems the CPU doesn't have access
> to the AUX data to clear it manually.
>
> I also wonder if there are actual igts for this? I think what is needed
> is a test that sets random things (different panning, rotation, pixel
> foramts, etc.) and triggers the dumper. Not quite sure how the test
> could validate that the output is correct though. CRCs might be a bit
> tricky since you need an identical reference image.
No, I didn't write igts for this yet. I test by triggering a kernel
panic, as it's the only way to make sure it works.
Also I didn't consider rotation yet, I think if the panic screen is not
rotated, it's still useful.
>
> /me off to summer vacation. Good luck
>
Sorry for that, my goal is just to have drm panic working on intel GPU.
Enjoy your vacation, and let's find a solution when you're back.
[1]
https://lore.kernel.org/intel-gfx/72fa1da6-caaa-41c9-aef1-4e780bde6acf@redhat.com/
Best regards,
--
Jocelyn
next prev parent reply other threads:[~2025-07-28 11:19 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-18 9:31 [PATCH v10 00/10] drm/i915: Add drm_panic support Jocelyn Falempe
2025-06-18 9:31 ` [PATCH v10 01/10] drm/panic: Add a private field to struct drm_scanout_buffer Jocelyn Falempe
2025-06-18 9:31 ` [PATCH v10 02/10] drm/i915/fbdev: Add intel_fbdev_get_map() Jocelyn Falempe
2025-06-18 9:31 ` [PATCH v10 03/10] drm/i915/display/i9xx: Add a disable_tiling() for i9xx planes Jocelyn Falempe
2025-07-19 18:23 ` Ville Syrjälä
2025-07-19 18:30 ` Ville Syrjälä
2025-07-28 11:19 ` Jocelyn Falempe [this message]
2025-06-18 9:31 ` [PATCH v10 04/10] drm/i915/display: Add a disable_tiling() for skl planes Jocelyn Falempe
2025-06-18 9:31 ` [PATCH v10 05/10] drm/ttm: Add ttm_bo_kmap_try_from_panic() Jocelyn Falempe
2025-06-18 13:55 ` Christian König
2025-06-18 15:38 ` Jocelyn Falempe
2025-06-27 10:05 ` Maarten Lankhorst
2025-06-18 9:31 ` [PATCH v10 06/10] drm/i915: Add intel_bo_panic_setup and intel_bo_panic_finish Jocelyn Falempe
2025-06-18 9:31 ` [PATCH v10 07/10] drm/i915/display: Add drm_panic support Jocelyn Falempe
2025-06-18 9:31 ` [PATCH v10 08/10] drm/i915/display: Add drm_panic support for Y-tiling with DPT Jocelyn Falempe
2025-06-18 9:31 ` [PATCH v10 09/10] drm/i915/display: Add drm_panic support for 4-tiling " Jocelyn Falempe
2025-06-18 9:31 ` [PATCH v10 10/10] drm/i915/psr: Add intel_psr2_panic_force_full_update Jocelyn Falempe
2025-06-18 11:11 ` ✗ i915.CI.BAT: failure for drm/i915: Add drm_panic support (rev10) Patchwork
2025-06-23 7:40 ` [PATCH v10 00/10] drm/i915: Add drm_panic support Maarten Lankhorst
2025-06-23 10:10 ` Jocelyn Falempe
2025-06-23 12:02 ` Maarten Lankhorst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a7ada116-5613-4518-a151-7c8db9874ede@redhat.com \
--to=jfalempe@redhat.com \
--cc=airlied@gmail.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=ray.huang@amd.com \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=tursulin@ursulin.net \
--cc=tzimmermann@suse.de \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox