Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Tue, 15 Mar 2022 at 00:23, Alex Deucher wrote: > > On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen wrote: > > > > On Thu, 10 Mar 2022 11:56:41 -0800 > > Rob Clark wrote: > > > > > For something like just notifying a compositor that a gpu crash > > > happened, perhaps drm_event is more suitable. See > > > virtio_gpu_fence_event_create() for an example of adding new event > > > types. Although maybe you want it to be an event which is not device > > > specific. This isn't so much of a debugging use-case as simply > > > notification. > > > > Hi, > > > > for this particular use case, are we now talking about the display > > device (KMS) crashing or the rendering device (OpenGL/Vulkan) crashing? > > > > If the former, I wasn't aware that display device crashes are a thing. > > How should a userspace display server react to those? > > > > If the latter, don't we have EGL extensions or Vulkan API already to > > deliver that? > > > > The above would be about device crashes that directly affect the > > display server. Is that the use case in mind here, or is it instead > > about notifying the display server that some application has caused a > > driver/hardware crash? If the latter, how should a display server react > > to that? Disconnect the application? > > > > Shashank, what is the actual use case you are developing this for? > > > > I've read all the emails here so far, and I don't recall seeing it > > explained. > > > > The idea is that a support daemon or compositor would listen for GPU > reset notifications and do something useful with them (kill the guilty > app, restart the desktop environment, etc.). Today when the GPU > resets, most applications just continue assuming nothing is wrong, > meanwhile the GPU has stopped accepting work until the apps re-init > their context so all of their command submissions just get rejected. Just one thing comes to mind reading this, racy PID reuse. process 1234 does something bad to GPU. process 1234 dies in parallel to sysfs notification being sent. other process 1234 reuses the pid new process 1234 gets destroyed by receiver of sysfs notification. Dave.
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Tuesday, March 15th, 2022 at 08:13, Dave Airlie wrote: > Just one thing comes to mind reading this, racy PID reuse. > > process 1234 does something bad to GPU. > process 1234 dies in parallel to sysfs notification being sent. > other process 1234 reuses the pid > new process 1234 gets destroyed by receiver of sysfs notification. This is a more general problem with PIDs. One solution is pidfd.
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
Am 15.03.22 um 08:13 schrieb Dave Airlie: On Tue, 15 Mar 2022 at 00:23, Alex Deucher wrote: On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen wrote: On Thu, 10 Mar 2022 11:56:41 -0800 Rob Clark wrote: For something like just notifying a compositor that a gpu crash happened, perhaps drm_event is more suitable. See virtio_gpu_fence_event_create() for an example of adding new event types. Although maybe you want it to be an event which is not device specific. This isn't so much of a debugging use-case as simply notification. Hi, for this particular use case, are we now talking about the display device (KMS) crashing or the rendering device (OpenGL/Vulkan) crashing? If the former, I wasn't aware that display device crashes are a thing. How should a userspace display server react to those? If the latter, don't we have EGL extensions or Vulkan API already to deliver that? The above would be about device crashes that directly affect the display server. Is that the use case in mind here, or is it instead about notifying the display server that some application has caused a driver/hardware crash? If the latter, how should a display server react to that? Disconnect the application? Shashank, what is the actual use case you are developing this for? I've read all the emails here so far, and I don't recall seeing it explained. The idea is that a support daemon or compositor would listen for GPU reset notifications and do something useful with them (kill the guilty app, restart the desktop environment, etc.). Today when the GPU resets, most applications just continue assuming nothing is wrong, meanwhile the GPU has stopped accepting work until the apps re-init their context so all of their command submissions just get rejected. Just one thing comes to mind reading this, racy PID reuse. process 1234 does something bad to GPU. process 1234 dies in parallel to sysfs notification being sent. other process 1234 reuses the pid new process 1234 gets destroyed by receiver of sysfs notification. That's a well known problem inherit to the uses of PIDs. IIRC because of this the kernel only reuses PIDs when /proc/sys/kernel/pid_max is reached and then wraps around. Regards, Christian. Dave.
RE: [Intel-gfx] [PATCH v6 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v9)
Hi Tvrtko, Daniel,
>
> On 11/03/2022 09:39, Daniel Vetter wrote:
> > On Mon, 7 Mar 2022 at 21:38, Vivek Kasireddy
> > wrote:
> >>
> >> On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
> >> more framebuffers/scanout buffers results in only one that is mappable/
> >> fenceable. Therefore, pageflipping between these 2 FBs where only one
> >> is mappable/fenceable creates latencies large enough to miss alternate
> >> vblanks thereby producing less optimal framerate.
> >>
> >> This mainly happens because when i915_gem_object_pin_to_display_plane()
> >> is called to pin one of the FB objs, the associated vma is identified
> >> as misplaced and therefore i915_vma_unbind() is called which unbinds and
> >> evicts it. This misplaced vma gets subseqently pinned only when
> >> i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
> >> results in a latency of ~10ms and happens every other vblank/repaint cycle.
> >> Therefore, to fix this issue, we try to see if there is space to map
> >> at-least two objects of a given size and return early if there isn't. This
> >> would ensure that we do not try with PIN_MAPPABLE for any objects that
> >> are too big to map thereby preventing unncessary unbind.
> >>
> >> Testcase:
> >> Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
> >> with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
> >> a frame ~7ms before the next vblank, the latencies seen between atomic
> >> commit and flip event are 7, 24 (7 + 16.66), 7, 24. suggesting that
> >> it misses the vblank every other frame.
> >>
> >> Here is the ftrace snippet that shows the source of the ~10ms latency:
> >>i915_gem_object_pin_to_display_plane() {
> >> 0.102 us |i915_gem_object_set_cache_level();
> >> i915_gem_object_ggtt_pin_ww() {
> >> 0.390 us | i915_vma_instance();
> >> 0.178 us | i915_vma_misplaced();
> >>i915_vma_unbind() {
> >>__i915_active_wait() {
> >> 0.082 us |i915_active_acquire_if_busy();
> >> 0.475 us | }
> >>intel_runtime_pm_get() {
> >> 0.087 us |intel_runtime_pm_acquire();
> >> 0.259 us | }
> >>__i915_active_wait() {
> >> 0.085 us |i915_active_acquire_if_busy();
> >> 0.240 us | }
> >>__i915_vma_evict() {
> >> ggtt_unbind_vma() {
> >>gen8_ggtt_clear_range() {
> >> 10507.255 us |}
> >> 10507.689 us | }
> >> 10508.516 us | }
> >>
> >> v2: Instead of using bigjoiner checks, determine whether a scanout
> >> buffer is too big by checking to see if it is possible to map
> >> two of them into the ggtt.
> >>
> >> v3 (Ville):
> >> - Count how many fb objects can be fit into the available holes
> >>instead of checking for a hole twice the object size.
> >> - Take alignment constraints into account.
> >> - Limit this large scanout buffer check to >= Gen 11 platforms.
> >>
> >> v4:
> >> - Remove existing heuristic that checks just for size. (Ville)
> >> - Return early if we find space to map at-least two objects. (Tvrtko)
> >> - Slightly update the commit message.
> >>
> >> v5: (Tvrtko)
> >> - Rename the function to indicate that the object may be too big to
> >>map into the aperture.
> >> - Account for guard pages while calculating the total size required
> >>for the object.
> >> - Do not subject all objects to the heuristic check and instead
> >>consider objects only of a certain size.
> >> - Do the hole walk using the rbtree.
> >> - Preserve the existing PIN_NONBLOCK logic.
> >> - Drop the PIN_MAPPABLE check while pinning the VMA.
> >>
> >> v6: (Tvrtko)
> >> - Return 0 on success and the specific error code on failure to
> >>preserve the existing behavior.
> >>
> >> v7: (Ville)
> >> - Drop the HAS_GMCH(i915), DISPLAY_VER(i915) < 11 and
> >>size < ggtt->mappable_end / 4 checks.
> >> - Drop the redundant check that is based on previous heuristic.
> >>
> >> v8:
> >> - Make sure that we are holding the mutex associated with ggtt vm
> >>as we traverse the hole nodes.
> >>
> >> v9: (Tvrtko)
> >> - Use mutex_lock_interruptible_nested() instead of mutex_lock().
> >>
> >> Cc: Ville Syrjälä
> >> Cc: Maarten Lankhorst
> >> Cc: Tvrtko Ursulin
> >> Cc: Manasi Navare
> >> Reviewed-by: Tvrtko Ursulin
> >> Signed-off-by: Vivek Kasireddy
> >> ---
> >> drivers/gpu/drm/i915/i915_gem.c | 128 +++-
> >> 1 file changed, 94 insertions(+), 34 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >> b/drivers/gpu/drm/i915/i915_gem.c
> >> index 9747924cc57b..e0d731b3f215 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem.c
> >> +++ b/drivers/gpu/drm/i915/i915_gem.c
> >> @@ -49,6 +49,7 @@
> >> #include "gem/i915_gem_pm.h"
> >> #include "gem/i915_gem_region.h"
> >> #include "gem/i915_gem_userptr.h"
> >> +#include
Re: [PATCH v2 05/10] drm/fourcc: Add DRM_FORMAT_C[124]
On Tue, 15 Mar 2022 09:15:08 +1100 (AEDT)
Finn Thain wrote:
> Hi Geert,
>
> On Mon, 14 Mar 2022, Geert Uytterhoeven wrote:
>
> > On Mon, Mar 14, 2022 at 4:05 PM Pekka Paalanen wrote:
> >
> > > On Mon, 14 Mar 2022 14:30:18 +0100
> > > Geert Uytterhoeven wrote:
> > > > On Mon, Mar 7, 2022 at 9:53 PM Geert Uytterhoeven
> > > > wrote:
> > > > > Introduce fourcc codes for color-indexed frame buffer formats with
> > > > > two, four, and sixteen colors, and provide a mapping from bit per
> > > > > pixel and depth to fourcc codes.
> > > > >
> > > > > As the number of bits per pixel is less than eight, these rely on
> > > > > proper block handling for the calculation of bits per pixel and
> > > > > pitch.
> > > > >
> > > > > Signed-off-by: Geert Uytterhoeven
> > > >
> > > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > > @@ -99,7 +99,10 @@ extern "C" {
> > > > > #define DRM_FORMAT_INVALID 0
> > > > >
> > > > > /* color index */
> > > > > -#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /*
> > > > > [7:0] C */
> > > > > +#define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ') /*
> > > > > [7:0] C0:C1:C2:C3:C4:C5:C6:C7 1:1:1:1:1:1:1:1 eight pixels/byte */
> > > > > +#define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ') /*
> > > > > [7:0] C0:C1:C2:C3 2:2:2:2 four pixels/byte */
> > > > > +#define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ') /*
> > > > > [7:0] C0:C1 4:4 two pixels/byte */
> > > > > +#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /*
> > > > > [7:0] C 8 one pixel/byte */
> > > > >
> > > > > /* 8 bpp Red */
> > > > > #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /*
> > > > > [7:0] R */
> > > >
> > > > After replying to Ilia's comment[1], I realized the CFB drawing
> > > > operations use native byte and bit ordering, unless
> > > > FBINFO_FOREIGN_ENDIAN is set.
> > > > While Amiga, Atari, and Sun-3 use big-endian bit ordering,
> > > > e.g. Acorn VIDC[2] uses little endian, and SH7760[3] is configurable
> > > > (sh7760fb configures ordering to match host order).
> > > > BTW, ssd130{7fb,x}_update_rect() both assume little-endian, so I
> > > > guess they are broken on big-endian.
> > > > Fbtest uses big-endian bit ordering, so < 8 bpp is probably broken
> > > > on little-endian.
> > > >
> > > > Hence the above should become:
> > > >
> > > > #define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ') /*
> > > > [7:0] C7:C6:C5:C4:C3:C2:C1:C0 1:1:1:1:1:1:1:1 eight pixels/byte */
> > > > #define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ') /*
> > > > [7:0] C3:C2:C1:C0 2:2:2:2 four pixels/byte */
> > > > #define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ') /*
> > > > [7:0] C1:C0 4:4 two pixels/byte */
> > > >
> > > > The same changes should be made for DRM_FORMAT_[RD][124].
> > > >
> > > > The fbdev emulation code should gain support for these with and without
> > > > DRM_FORMAT_BIG_ENDIAN, the latter perhaps only on big-endian platforms?
> > > >
> > > > [1]
> > > > https://lore.kernel.org/r/CAKb7UvgEdm9U=+ryrwl0tgrfa_qc7nbhcwozoft2dkdxggt...@mail.gmail.com/
> > > > [2] See p.30 of the VIDC datasheet
> > > >
> > > > http://chrisacorns.computinghistory.org.uk/docs/Acorn/Misc/Acorn_VIDC_Datasheet.pdf
> > > > [3] See p.1178 of the SH7660 datasheet
> > > >
> > > > https://datasheet.octopart.com/HD6417760BL200AV-Renesas-datasheet-14105759.pdf
> > > >
> > >
> > > why would CPU endianess affect the order of bits in a byte?
> >
> > It doesn't, but see below.
> >
> > > Do you mean that bit 0 one machine is (1 << 0), and on another machine
> > > bit 0 is (1 << 7)?
> >
> > No, I mean that in case of multiple pixels per byte, the display
> > hardware pumps out pixels to the CRTC starting from either the MSB
> > or the LSB of the first display byte. Which order depends on the
> > display hardware, not on the CPU.
> >
> > > In C, we have only one way to address bits of a byte and that is with
> > > arithmetic. You cannot take the address of a bit any other way, can you?
> > >
> > > Can we standardise on "bit n of a byte is addressed as (1 << n)"?
> >
> > BIT(n) in Linux works the same for little- and big-endian CPUs.
> > But display hardware may use a different bit order.
> >
>
> Perhaps some of this confusion could be avoided if you describe the
> problem in terms of the sequence of scan-out of pixels, rather than in
> terms of the serialization of bits. The significance of bits within each
> pixel and the ordering of pixels within each memory word are independent,
> right?
Yes, that might help.
Also, when drm_fourcc.h is describing pixel formats, it needs to
consider only how a little-endian CPU accesses them. That's how pixel
data in memory is described. Display hardware plays no part in that.
It is the driver's job to expose the pixel formats that match display
hardware behaviour.
Thanks,
pq
Re: [PATCH v2 05/10] drm/fourcc: Add DRM_FORMAT_C[124]
Hi Geert,
On Mon, 14 Mar 2022, Geert Uytterhoeven wrote:
> On Mon, Mar 14, 2022 at 4:05 PM Pekka Paalanen wrote:
> > On Mon, 14 Mar 2022 14:30:18 +0100
> > Geert Uytterhoeven wrote:
> > > On Mon, Mar 7, 2022 at 9:53 PM Geert Uytterhoeven
> > > wrote:
> > > > Introduce fourcc codes for color-indexed frame buffer formats with
> > > > two, four, and sixteen colors, and provide a mapping from bit per
> > > > pixel and depth to fourcc codes.
> > > >
> > > > As the number of bits per pixel is less than eight, these rely on
> > > > proper block handling for the calculation of bits per pixel and
> > > > pitch.
> > > >
> > > > Signed-off-by: Geert Uytterhoeven
> > >
> > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > @@ -99,7 +99,10 @@ extern "C" {
> > > > #define DRM_FORMAT_INVALID 0
> > > >
> > > > /* color index */
> > > > -#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /*
> > > > [7:0] C */
> > > > +#define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ') /*
> > > > [7:0] C0:C1:C2:C3:C4:C5:C6:C7 1:1:1:1:1:1:1:1 eight pixels/byte */
> > > > +#define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ') /*
> > > > [7:0] C0:C1:C2:C3 2:2:2:2 four pixels/byte */
> > > > +#define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ') /*
> > > > [7:0] C0:C1 4:4 two pixels/byte */
> > > > +#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /*
> > > > [7:0] C 8 one pixel/byte */
> > > >
> > > > /* 8 bpp Red */
> > > > #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /*
> > > > [7:0] R */
> > >
> > > After replying to Ilia's comment[1], I realized the CFB drawing
> > > operations use native byte and bit ordering, unless
> > > FBINFO_FOREIGN_ENDIAN is set.
> > > While Amiga, Atari, and Sun-3 use big-endian bit ordering,
> > > e.g. Acorn VIDC[2] uses little endian, and SH7760[3] is configurable
> > > (sh7760fb configures ordering to match host order).
> > > BTW, ssd130{7fb,x}_update_rect() both assume little-endian, so I
> > > guess they are broken on big-endian.
> > > Fbtest uses big-endian bit ordering, so < 8 bpp is probably broken
> > > on little-endian.
> > >
> > > Hence the above should become:
> > >
> > > #define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ') /*
> > > [7:0] C7:C6:C5:C4:C3:C2:C1:C0 1:1:1:1:1:1:1:1 eight pixels/byte */
> > > #define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ') /*
> > > [7:0] C3:C2:C1:C0 2:2:2:2 four pixels/byte */
> > > #define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ') /*
> > > [7:0] C1:C0 4:4 two pixels/byte */
> > >
> > > The same changes should be made for DRM_FORMAT_[RD][124].
> > >
> > > The fbdev emulation code should gain support for these with and without
> > > DRM_FORMAT_BIG_ENDIAN, the latter perhaps only on big-endian platforms?
> > >
> > > [1]
> > > https://lore.kernel.org/r/CAKb7UvgEdm9U=+ryrwl0tgrfa_qc7nbhcwozoft2dkdxggt...@mail.gmail.com/
> > > [2] See p.30 of the VIDC datasheet
> > >
> > > http://chrisacorns.computinghistory.org.uk/docs/Acorn/Misc/Acorn_VIDC_Datasheet.pdf
> > > [3] See p.1178 of the SH7660 datasheet
> > >
> > > https://datasheet.octopart.com/HD6417760BL200AV-Renesas-datasheet-14105759.pdf
> >
> > why would CPU endianess affect the order of bits in a byte?
>
> It doesn't, but see below.
>
> > Do you mean that bit 0 one machine is (1 << 0), and on another machine
> > bit 0 is (1 << 7)?
>
> No, I mean that in case of multiple pixels per byte, the display
> hardware pumps out pixels to the CRTC starting from either the MSB
> or the LSB of the first display byte. Which order depends on the
> display hardware, not on the CPU.
>
> > In C, we have only one way to address bits of a byte and that is with
> > arithmetic. You cannot take the address of a bit any other way, can you?
> >
> > Can we standardise on "bit n of a byte is addressed as (1 << n)"?
>
> BIT(n) in Linux works the same for little- and big-endian CPUs.
> But display hardware may use a different bit order.
>
Perhaps some of this confusion could be avoided if you describe the
problem in terms of the sequence of scan-out of pixels, rather than in
terms of the serialization of bits. The significance of bits within each
pixel and the ordering of pixels within each memory word are independent,
right?
Re: [PATCH v2 05/10] drm/fourcc: Add DRM_FORMAT_C[124]
Hi Pekka,
On Tue, Mar 15, 2022 at 8:33 AM Pekka Paalanen wrote:
> On Tue, 15 Mar 2022 09:15:08 +1100 (AEDT)
> Finn Thain wrote:
> > On Mon, 14 Mar 2022, Geert Uytterhoeven wrote:
> > > On Mon, Mar 14, 2022 at 4:05 PM Pekka Paalanen
> > > wrote:
> > > > On Mon, 14 Mar 2022 14:30:18 +0100
> > > > Geert Uytterhoeven wrote:
> > > > > On Mon, Mar 7, 2022 at 9:53 PM Geert Uytterhoeven
> > > > > wrote:
> > > > > > Introduce fourcc codes for color-indexed frame buffer formats with
> > > > > > two, four, and sixteen colors, and provide a mapping from bit per
> > > > > > pixel and depth to fourcc codes.
> > > > > >
> > > > > > As the number of bits per pixel is less than eight, these rely on
> > > > > > proper block handling for the calculation of bits per pixel and
> > > > > > pitch.
> > > > > >
> > > > > > Signed-off-by: Geert Uytterhoeven
> > > > >
> > > > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > > > @@ -99,7 +99,10 @@ extern "C" {
> > > > > > #define DRM_FORMAT_INVALID 0
> > > > > >
> > > > > > /* color index */
> > > > > > -#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /*
> > > > > > [7:0] C */
> > > > > > +#define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ') /*
> > > > > > [7:0] C0:C1:C2:C3:C4:C5:C6:C7 1:1:1:1:1:1:1:1 eight pixels/byte */
> > > > > > +#define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ') /*
> > > > > > [7:0] C0:C1:C2:C3 2:2:2:2 four pixels/byte */
> > > > > > +#define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ') /*
> > > > > > [7:0] C0:C1 4:4 two pixels/byte */
> > > > > > +#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /*
> > > > > > [7:0] C 8 one pixel/byte */
> > > > > >
> > > > > > /* 8 bpp Red */
> > > > > > #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /*
> > > > > > [7:0] R */
> > > > >
> > > > > After replying to Ilia's comment[1], I realized the CFB drawing
> > > > > operations use native byte and bit ordering, unless
> > > > > FBINFO_FOREIGN_ENDIAN is set.
> > > > > While Amiga, Atari, and Sun-3 use big-endian bit ordering,
> > > > > e.g. Acorn VIDC[2] uses little endian, and SH7760[3] is configurable
> > > > > (sh7760fb configures ordering to match host order).
> > > > > BTW, ssd130{7fb,x}_update_rect() both assume little-endian, so I
> > > > > guess they are broken on big-endian.
> > > > > Fbtest uses big-endian bit ordering, so < 8 bpp is probably broken
> > > > > on little-endian.
> > > > >
> > > > > Hence the above should become:
> > > > >
> > > > > #define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ') /*
> > > > > [7:0] C7:C6:C5:C4:C3:C2:C1:C0 1:1:1:1:1:1:1:1 eight pixels/byte */
> > > > > #define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ') /*
> > > > > [7:0] C3:C2:C1:C0 2:2:2:2 four pixels/byte */
> > > > > #define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ') /*
> > > > > [7:0] C1:C0 4:4 two pixels/byte */
> > > > >
> > > > > The same changes should be made for DRM_FORMAT_[RD][124].
> > > > >
> > > > > The fbdev emulation code should gain support for these with and
> > > > > without
> > > > > DRM_FORMAT_BIG_ENDIAN, the latter perhaps only on big-endian
> > > > > platforms?
> > > > >
> > > > > [1]
> > > > > https://lore.kernel.org/r/CAKb7UvgEdm9U=+ryrwl0tgrfa_qc7nbhcwozoft2dkdxggt...@mail.gmail.com/
> > > > > [2] See p.30 of the VIDC datasheet
> > > > >
> > > > > http://chrisacorns.computinghistory.org.uk/docs/Acorn/Misc/Acorn_VIDC_Datasheet.pdf
> > > > > [3] See p.1178 of the SH7660 datasheet
> > > > >
> > > > > https://datasheet.octopart.com/HD6417760BL200AV-Renesas-datasheet-14105759.pdf
> > > >
> > > > why would CPU endianess affect the order of bits in a byte?
> > >
> > > It doesn't, but see below.
> > >
> > > > Do you mean that bit 0 one machine is (1 << 0), and on another machine
> > > > bit 0 is (1 << 7)?
> > >
> > > No, I mean that in case of multiple pixels per byte, the display
> > > hardware pumps out pixels to the CRTC starting from either the MSB
> > > or the LSB of the first display byte. Which order depends on the
> > > display hardware, not on the CPU.
> > >
> > > > In C, we have only one way to address bits of a byte and that is with
> > > > arithmetic. You cannot take the address of a bit any other way, can you?
> > > >
> > > > Can we standardise on "bit n of a byte is addressed as (1 << n)"?
> > >
> > > BIT(n) in Linux works the same for little- and big-endian CPUs.
> > > But display hardware may use a different bit order.
> >
> > Perhaps some of this confusion could be avoided if you describe the
> > problem in terms of the sequence of scan-out of pixels, rather than in
> > terms of the serialization of bits. The significance of bits within each
> > pixel and the ordering of pixels within each memory word are independent,
> > right?
>
> Yes, that might help.
Display:
P0 P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15
P15 P14
Re: [PATCH v2 05/10] drm/fourcc: Add DRM_FORMAT_C[124]
On Tue, Mar 15, 2022 at 8:51 AM Geert Uytterhoeven wrote:
> > Also, when drm_fourcc.h is describing pixel formats, it needs to
> > consider only how a little-endian CPU accesses them. That's how pixel
> > data in memory is described. Display hardware plays no part in that.
> > It is the driver's job to expose the pixel formats that match display
> > hardware behaviour.
>
> But if the "CPU format" does not match the "display support",
s/support/format/
> all pixel data must be converted?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: [RFC v3 7/8] binder: use __kernel_pid_t and __kernel_uid_t for userspace
From: T.J. Mercier
> Sent: 14 March 2022 23:45
>
> On Thu, Mar 10, 2022 at 11:33 AM Todd Kjos wrote:
> >
> > On Wed, Mar 9, 2022 at 8:52 AM T.J. Mercier wrote:
> > >
> > > The kernel interface should use types that the kernel defines instead of
> > > pid_t and uid_t, whose definiton is owned by libc. This fixes the header
> > > so that it can be included without first including sys/types.h.
> > >
> > > Signed-off-by: T.J. Mercier
> > > ---
> > > include/uapi/linux/android/binder.h | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/uapi/linux/android/binder.h
> > > b/include/uapi/linux/android/binder.h
> > > index 169fd5069a1a..aa28454dbca3 100644
> > > --- a/include/uapi/linux/android/binder.h
> > > +++ b/include/uapi/linux/android/binder.h
> > > @@ -289,8 +289,8 @@ struct binder_transaction_data {
> > >
> > > /* General information about the transaction. */
> > > __u32 flags;
> > > - pid_t sender_pid;
> > > - uid_t sender_euid;
> > > + __kernel_pid_t sender_pid;
> > > + __kernel_uid_t sender_euid;
> >
> > Are we guaranteed that this does not affect the UAPI at all? Userspace
> > code using this definition will have to run with kernels using the old
> > definition and visa-versa.
>
> A standards compliant userspace should be expecting a signed integer
> type here. So the only way I can think userspace would be affected is
> if:
> 1) pid_t is a long AND
> 2) sizeof(long) > sizeof(int) AND
> 3) Consumers of the pid_t definition actually attempt to mutate the
> result to make use of extra bits in the variable (which are not there)
Or the userspace headers have a 16bit pid_t.
I can't help feeling that uapi headers should only use explicit
fixed sized types.
There is no point indirecting the type names - the sizes still
can't be changes.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
Dear Arunpravin,
Am 14.03.22 um 20:40 schrieb Arunpravin:
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC
Signed-off-by: Arunpravin
Please use your full name.
---
drivers/gpu/drm/drm_buddy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
In what tree is that file?
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
- if (order-- == min_order) {
+ if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
Kind regards,
Paul
Re: [PATCH v2 05/10] drm/fourcc: Add DRM_FORMAT_C[124]
On Tue, 15 Mar 2022 08:51:31 +0100
Geert Uytterhoeven wrote:
> Hi Pekka,
>
> On Tue, Mar 15, 2022 at 8:33 AM Pekka Paalanen wrote:
> > On Tue, 15 Mar 2022 09:15:08 +1100 (AEDT)
> > Finn Thain wrote:
> > > On Mon, 14 Mar 2022, Geert Uytterhoeven wrote:
> > > > On Mon, Mar 14, 2022 at 4:05 PM Pekka Paalanen
> > > > wrote:
> > > > > On Mon, 14 Mar 2022 14:30:18 +0100
> > > > > Geert Uytterhoeven wrote:
> > > > > > On Mon, Mar 7, 2022 at 9:53 PM Geert Uytterhoeven
> > > > > > wrote:
> > > > > > > Introduce fourcc codes for color-indexed frame buffer formats with
> > > > > > > two, four, and sixteen colors, and provide a mapping from bit per
> > > > > > > pixel and depth to fourcc codes.
> > > > > > >
> > > > > > > As the number of bits per pixel is less than eight, these rely on
> > > > > > > proper block handling for the calculation of bits per pixel and
> > > > > > > pitch.
> > > > > > >
> > > > > > > Signed-off-by: Geert Uytterhoeven
> > > > > >
> > > > > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > > > > @@ -99,7 +99,10 @@ extern "C" {
> > > > > > > #define DRM_FORMAT_INVALID 0
> > > > > > >
> > > > > > > /* color index */
> > > > > > > -#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ')
> > > > > > > /* [7:0] C */
> > > > > > > +#define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ')
> > > > > > > /* [7:0] C0:C1:C2:C3:C4:C5:C6:C7 1:1:1:1:1:1:1:1 eight
> > > > > > > pixels/byte */
> > > > > > > +#define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ')
> > > > > > > /* [7:0] C0:C1:C2:C3 2:2:2:2 four pixels/byte */
> > > > > > > +#define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ')
> > > > > > > /* [7:0] C0:C1 4:4 two pixels/byte */
> > > > > > > +#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ')
> > > > > > > /* [7:0] C 8 one pixel/byte */
> > > > > > >
> > > > > > > /* 8 bpp Red */
> > > > > > > #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ')
> > > > > > > /* [7:0] R */
> > > > > >
> > > > > > After replying to Ilia's comment[1], I realized the CFB drawing
> > > > > > operations use native byte and bit ordering, unless
> > > > > > FBINFO_FOREIGN_ENDIAN is set.
> > > > > > While Amiga, Atari, and Sun-3 use big-endian bit ordering,
> > > > > > e.g. Acorn VIDC[2] uses little endian, and SH7760[3] is configurable
> > > > > > (sh7760fb configures ordering to match host order).
> > > > > > BTW, ssd130{7fb,x}_update_rect() both assume little-endian, so I
> > > > > > guess they are broken on big-endian.
> > > > > > Fbtest uses big-endian bit ordering, so < 8 bpp is probably broken
> > > > > > on little-endian.
> > > > > >
> > > > > > Hence the above should become:
> > > > > >
> > > > > > #define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ')
> > > > > > /*
> > > > > > [7:0] C7:C6:C5:C4:C3:C2:C1:C0 1:1:1:1:1:1:1:1 eight pixels/byte */
> > > > > > #define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ')
> > > > > > /*
> > > > > > [7:0] C3:C2:C1:C0 2:2:2:2 four pixels/byte */
> > > > > > #define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ')
> > > > > > /*
> > > > > > [7:0] C1:C0 4:4 two pixels/byte */
> > > > > >
> > > > > > The same changes should be made for DRM_FORMAT_[RD][124].
> > > > > >
> > > > > > The fbdev emulation code should gain support for these with and
> > > > > > without
> > > > > > DRM_FORMAT_BIG_ENDIAN, the latter perhaps only on big-endian
> > > > > > platforms?
> > > > > >
> > > > > > [1]
> > > > > > https://lore.kernel.org/r/CAKb7UvgEdm9U=+ryrwl0tgrfa_qc7nbhcwozoft2dkdxggt...@mail.gmail.com/
> > > > > > [2] See p.30 of the VIDC datasheet
> > > > > >
> > > > > > http://chrisacorns.computinghistory.org.uk/docs/Acorn/Misc/Acorn_VIDC_Datasheet.pdf
> > > > > > [3] See p.1178 of the SH7660 datasheet
> > > > > >
> > > > > > https://datasheet.octopart.com/HD6417760BL200AV-Renesas-datasheet-14105759.pdf
> > > > > >
> > > > >
> > > > > why would CPU endianess affect the order of bits in a byte?
> > > >
> > > > It doesn't, but see below.
> > > >
> > > > > Do you mean that bit 0 one machine is (1 << 0), and on another machine
> > > > > bit 0 is (1 << 7)?
> > > >
> > > > No, I mean that in case of multiple pixels per byte, the display
> > > > hardware pumps out pixels to the CRTC starting from either the MSB
> > > > or the LSB of the first display byte. Which order depends on the
> > > > display hardware, not on the CPU.
> > > >
> > > > > In C, we have only one way to address bits of a byte and that is with
> > > > > arithmetic. You cannot take the address of a bit any other way, can
> > > > > you?
> > > > >
> > > > > Can we standardise on "bit n of a byte is addressed as (1 << n)"?
> > > >
> > > > BIT(n) in Linux works the same for little- and big-endian CPUs.
> > > > But display hardware may use a different bit order.
> > >
> > > Perhaps some of this confusion could be avoided if you
[PATCH] drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERS
Fix a number of undefined references to drm_kms_helper.ko in
drm_dp_helper.ko:
arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
function `drm_dp_mst_duplicate_state':
drm_dp_mst_topology.c:(.text+0x2df0): undefined reference to
`__drm_atomic_helper_private_obj_duplicate_state'
arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
function `drm_dp_delayed_destroy_work':
drm_dp_mst_topology.c:(.text+0x370c): undefined reference to
`drm_kms_helper_hotplug_event'
arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
function `drm_dp_mst_up_req_work':
drm_dp_mst_topology.c:(.text+0x7938): undefined reference to
`drm_kms_helper_hotplug_event'
arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
function `drm_dp_mst_link_probe_work':
drm_dp_mst_topology.c:(.text+0x82e0): undefined reference to
`drm_kms_helper_hotplug_event'
This happens if panel-edp.ko has been configured with
DRM_PANEL_EDP=y
DRM_DP_HELPER=y
DRM_KMS_HELPER=m
which builds DP helpers into the kernel and KMS helpers sa a module.
Making DRM_PANEL_EDP select DRM_KMS_HELPER resolves this problem.
To avoid a resulting cyclic dependency with DRM_PANEL_BRIDGE, don't
make the latter depend on DRM_KMS_HELPER and fix the one DRM bridge
drivers that doesn't already select DRM_KMS_HELPER. As KMS helpers
cannot be selected directly by the user, config symbols should avoid
depending on it anyway.
Signed-off-by: Thomas Zimmermann
Fixes: 3755d35ee1d2 ("drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP")
Reported-by: kernel test robot
Cc: Thomas Zimmermann
Cc: Naresh Kamboju
Cc: Linux Kernel Functional Testing
Cc: Lyude Paul
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: dri-devel@lists.freedesktop.org
Cc: Dave Airlie
Cc: Thierry Reding
---
drivers/gpu/drm/bridge/Kconfig | 3 +--
drivers/gpu/drm/panel/Kconfig | 1 +
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index c86f5be4dfe0..007e5a282f67 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -8,7 +8,6 @@ config DRM_BRIDGE
config DRM_PANEL_BRIDGE
def_bool y
depends on DRM_BRIDGE
- depends on DRM_KMS_HELPER
select DRM_PANEL
help
DRM bridge wrapper of DRM panels
@@ -30,7 +29,7 @@ config DRM_CDNS_DSI
config DRM_CHIPONE_ICN6211
tristate "Chipone ICN6211 MIPI-DSI/RGB Converter bridge"
depends on OF
- depends on DRM_KMS_HELPER
+ select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
help
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index bb2e47229c68..ddf5f38e8731 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -107,6 +107,7 @@ config DRM_PANEL_EDP
select VIDEOMODE_HELPERS
select DRM_DP_AUX_BUS
select DRM_DP_HELPER
+ select DRM_KMS_HELPER
help
DRM panel driver for dumb eDP panels that need at most a regulator and
a GPIO to be powered up. Optionally a backlight can be attached so
--
2.35.1
Re: [PATCH v6 1/3] i915/gvt: Introduce the mmio table to support VFIO new mdev API
On Tue, 15 Mar 2022, Christoph Hellwig wrote: > Just curious, what is the state of this seris? It would be good to > have it ready early on for the next merge window as there is quite > a backlog that depends on it. Can't speak for the status of the series, but for drm the deadline for changes headed for the merge window is around -rc5/-rc6 timeframe i.e. this has already missed the upcoming merge window. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
On 15/03/22 1:49 pm, Paul Menzel wrote:
> Dear Arunpravin,
>
>
> Am 14.03.22 um 20:40 schrieb Arunpravin:
>> handle a situation in the condition order-- == min_order,
>> when order = 0, leading to order = -1, it now won't exit
>> the loop. To avoid this problem, added a order check in
>> the same condition, (i.e) when order is 0, we return
>> -ENOSPC
>>
>> Signed-off-by: Arunpravin
>
> Please use your full name.
okay
>
>> ---
>> drivers/gpu/drm/drm_buddy.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>> index 72f52f293249..5ab66aaf2bbd 100644
>> --- a/drivers/gpu/drm/drm_buddy.c
>> +++ b/drivers/gpu/drm/drm_buddy.c
>
> In what tree is that file?
>
drm-tip - https://cgit.freedesktop.org/drm-tip/tree/
drm-misc-next - https://cgit.freedesktop.org/drm/drm-misc/tree/
>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>> if (!IS_ERR(block))
>> break;
>>
>> -if (order-- == min_order) {
>> +if (!order || order-- == min_order) {
>> err = -ENOSPC;
>> goto err_free;
>> }
>
> Kind regards,
>
> Paul
>
Re: [PATCH v2 05/10] drm/fourcc: Add DRM_FORMAT_C[124]
Hi Pekka,
On Tue, Mar 15, 2022 at 9:46 AM Pekka Paalanen wrote:
> On Tue, 15 Mar 2022 08:51:31 +0100
> Geert Uytterhoeven wrote:
> > On Tue, Mar 15, 2022 at 8:33 AM Pekka Paalanen wrote:
> > > On Tue, 15 Mar 2022 09:15:08 +1100 (AEDT)
> > > Finn Thain wrote:
> > > > On Mon, 14 Mar 2022, Geert Uytterhoeven wrote:
> > > > > On Mon, Mar 14, 2022 at 4:05 PM Pekka Paalanen
> > > > > wrote:
> > > > > > On Mon, 14 Mar 2022 14:30:18 +0100
> > > > > > Geert Uytterhoeven wrote:
> > > > > > > On Mon, Mar 7, 2022 at 9:53 PM Geert Uytterhoeven
> > > > > > > wrote:
> > > > > > > > Introduce fourcc codes for color-indexed frame buffer formats
> > > > > > > > with
> > > > > > > > two, four, and sixteen colors, and provide a mapping from bit
> > > > > > > > per
> > > > > > > > pixel and depth to fourcc codes.
> > > > > > > >
> > > > > > > > As the number of bits per pixel is less than eight, these rely
> > > > > > > > on
> > > > > > > > proper block handling for the calculation of bits per pixel and
> > > > > > > > pitch.
> > > > > > > >
> > > > > > > > Signed-off-by: Geert Uytterhoeven
> > > > > > >
> > > > > > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > > > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > > > > > @@ -99,7 +99,10 @@ extern "C" {
> > > > > > > > #define DRM_FORMAT_INVALID 0
> > > > > > > >
> > > > > > > > /* color index */
> > > > > > > > -#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ')
> > > > > > > > /* [7:0] C */
> > > > > > > > +#define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ')
> > > > > > > > /* [7:0] C0:C1:C2:C3:C4:C5:C6:C7 1:1:1:1:1:1:1:1 eight
> > > > > > > > pixels/byte */
> > > > > > > > +#define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ')
> > > > > > > > /* [7:0] C0:C1:C2:C3 2:2:2:2 four pixels/byte */
> > > > > > > > +#define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ')
> > > > > > > > /* [7:0] C0:C1 4:4 two pixels/byte */
> > > > > > > > +#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ')
> > > > > > > > /* [7:0] C 8 one pixel/byte */
> > > > > > > >
> > > > > > > > /* 8 bpp Red */
> > > > > > > > #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ')
> > > > > > > > /* [7:0] R */
> > > > > > >
> > > > > > > After replying to Ilia's comment[1], I realized the CFB drawing
> > > > > > > operations use native byte and bit ordering, unless
> > > > > > > FBINFO_FOREIGN_ENDIAN is set.
> > > > > > > While Amiga, Atari, and Sun-3 use big-endian bit ordering,
> > > > > > > e.g. Acorn VIDC[2] uses little endian, and SH7760[3] is
> > > > > > > configurable
> > > > > > > (sh7760fb configures ordering to match host order).
> > > > > > > BTW, ssd130{7fb,x}_update_rect() both assume little-endian, so I
> > > > > > > guess they are broken on big-endian.
> > > > > > > Fbtest uses big-endian bit ordering, so < 8 bpp is probably broken
> > > > > > > on little-endian.
> > > > > > >
> > > > > > > Hence the above should become:
> > > > > > >
> > > > > > > #define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', '
> > > > > > > ') /*
> > > > > > > [7:0] C7:C6:C5:C4:C3:C2:C1:C0 1:1:1:1:1:1:1:1 eight pixels/byte */
> > > > > > > #define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', '
> > > > > > > ') /*
> > > > > > > [7:0] C3:C2:C1:C0 2:2:2:2 four pixels/byte */
> > > > > > > #define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', '
> > > > > > > ') /*
> > > > > > > [7:0] C1:C0 4:4 two pixels/byte */
> > > > > > >
> > > > > > > The same changes should be made for DRM_FORMAT_[RD][124].
> > > > > > >
> > > > > > > The fbdev emulation code should gain support for these with and
> > > > > > > without
> > > > > > > DRM_FORMAT_BIG_ENDIAN, the latter perhaps only on big-endian
> > > > > > > platforms?
> > > > > > >
> > > > > > > [1]
> > > > > > > https://lore.kernel.org/r/CAKb7UvgEdm9U=+ryrwl0tgrfa_qc7nbhcwozoft2dkdxggt...@mail.gmail.com/
> > > > > > > [2] See p.30 of the VIDC datasheet
> > > > > > >
> > > > > > > http://chrisacorns.computinghistory.org.uk/docs/Acorn/Misc/Acorn_VIDC_Datasheet.pdf
> > > > > > > [3] See p.1178 of the SH7660 datasheet
> > > > > > >
> > > > > > > https://datasheet.octopart.com/HD6417760BL200AV-Renesas-datasheet-14105759.pdf
> > > > > >
> > > > > > why would CPU endianess affect the order of bits in a byte?
> > > > >
> > > > > It doesn't, but see below.
> > > > >
> > > > > > Do you mean that bit 0 one machine is (1 << 0), and on another
> > > > > > machine
> > > > > > bit 0 is (1 << 7)?
> > > > >
> > > > > No, I mean that in case of multiple pixels per byte, the display
> > > > > hardware pumps out pixels to the CRTC starting from either the MSB
> > > > > or the LSB of the first display byte. Which order depends on the
> > > > > display hardware, not on the CPU.
> > > > >
> > > > > > In C, we have only one way to address bits of a byte and that is
> > > > > > with
> > > > > > arithmetic. You cannot take the address of a bit any other way, can
> > > > > > you
Re: [PATCH v6 1/3] i915/gvt: Introduce the mmio table to support VFIO new mdev API
I was actually testing it for almost two weeks, but still I met some hang and I was trying to figure where the problem is as this is quite a big change. Let's see if I can figure it out this week. Thanks, Zhi. On 3/15/22 8:48 AM, Christoph Hellwig wrote: > On Tue, Mar 15, 2022 at 10:46:53AM +0200, Jani Nikula wrote: >> On Tue, 15 Mar 2022, Christoph Hellwig wrote: >>> Just curious, what is the state of this seris? It would be good to >>> have it ready early on for the next merge window as there is quite >>> a backlog that depends on it. >> >> Can't speak for the status of the series, but for drm the deadline for >> changes headed for the merge window is around -rc5/-rc6 timeframe >> i.e. this has already missed the upcoming merge window. > > I know. I meant the next one, not the one ending now. And I don't > want to miss another one. >
Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
Dear Arunpravin,
Am 15.03.22 um 10:01 schrieb Arunpravin:
On 15/03/22 1:49 pm, Paul Menzel wrote:
Am 14.03.22 um 20:40 schrieb Arunpravin:
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC
Signed-off-by: Arunpravin
Please use your full name.
okay
You might also configure that in your email program.
---
drivers/gpu/drm/drm_buddy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
In what tree is that file?
drm-tip - https://cgit.freedesktop.org/drm-tip/tree/
drm-misc-next - https://cgit.freedesktop.org/drm/drm-misc/tree/
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
- if (order-- == min_order) {
+ if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
Thank you for the hint. So the whole function is:
do {
order = min(order, (unsigned int)fls(pages) - 1);
BUG_ON(order > mm->max_order);
BUG_ON(order < min_order);
do {
if (flags & DRM_BUDDY_RANGE_ALLOCATION)
/* Allocate traversing within the range */
block = alloc_range_bias(mm, start, end, order);
else
/* Allocate from freelist */
block = alloc_from_freelist(mm, order, flags);
if (!IS_ERR(block))
break;
if (order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
} while (1);
mark_allocated(block);
mm->avail -= drm_buddy_block_size(mm, block);
kmemleak_update_trace(block);
list_add_tail(&block->link, &allocated);
pages -= BIT(order);
if (!pages)
break;
} while (1);
Was the BUG_ON triggered for your case?
BUG_ON(order < min_order);
Please give more details.
Kind regards,
Paul
Re: [PATCH v4] drm/msm/disp/dpu1: add inline rotation support for sc7280 target
Hi Vinod,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next next-20220310]
[cannot apply to tegra-drm/drm/tegra/for-next airlied/drm-next v5.17-rc8]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Vinod-Polimera/drm-msm-disp-dpu1-add-inline-rotation-support-for-sc7280-target/20220315-124423
base: git://anongit.freedesktop.org/drm/drm drm-next
config: arm64-buildonly-randconfig-r002-20220313
(https://download.01.org/0day-ci/archive/20220315/202203151751.ov7gcuzi-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
a6b2f50fb47da3baeee10b1906da6e30ac5d26ec)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://github.com/0day-ci/linux/commit/1582b1f4a0b79f64b61b217ea6c3bb0591da0fab
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Vinod-Polimera/drm-msm-disp-dpu1-add-inline-rotation-support-for-sc7280-target/20220315-124423
git checkout 1582b1f4a0b79f64b61b217ea6c3bb0591da0fab
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=arm64 SHELL=/bin/bash drivers/gpu/drm/msm/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:686:39: warning: unused
>> variable 'msm8998_vig_sblk_0' [-Wunused-const-variable]
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_0 =
^
>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:688:39: warning: unused
>> variable 'msm8998_vig_sblk_1' [-Wunused-const-variable]
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_1 =
^
>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:690:39: warning: unused
>> variable 'msm8998_vig_sblk_2' [-Wunused-const-variable]
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_2 =
^
>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:692:39: warning: unused
>> variable 'msm8998_vig_sblk_3' [-Wunused-const-variable]
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_3 =
^
4 warnings generated.
vim +/msm8998_vig_sblk_0 +686 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
5334087ee7438fa Loic Poulain 2022-02-14 647
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 648
/*
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 649 * SSPP sub blocks
config
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 650
*/
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 651
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 652 /* SSPP common
configuration */
1582b1f4a0b79f6 Vinod Polimera 2022-03-15 653 #define
_VIG_SBLK(num, sdma_pri, qseed_ver, rot_cfg) \
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 654 { \
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 655 .maxdwnscale =
MAX_DOWNSCALE_RATIO, \
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 656 .maxupscale =
MAX_UPSCALE_RATIO, \
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 657
.smart_dma_priority = sdma_pri, \
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 658 .src_blk =
{.name = STRCAT("sspp_src_", num), \
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 659 .id =
DPU_SSPP_SRC, .base = 0x00, .len = 0x150,}, \
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 660 .scaler_blk =
{.name = STRCAT("sspp_scaler", num), \
b75ab05a34792fc Shubhashree Dhar 2019-11-27 661 .id =
qseed_ver, \
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 662 .base =
0xa00, .len = 0xa0,}, \
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 663 .csc_blk =
{.name = STRCAT("sspp_csc", num), \
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 664 .id =
DPU_SSPP_CSC_10BIT, \
25fdd5933e4c0f5 Jeykumar Sankaran 2018-0
Re: [PATCH v6 1/3] i915/gvt: Introduce the mmio table to support VFIO new mdev API
On Tue, 15 Mar 2022, Christoph Hellwig wrote: > I know. I meant the next one, not the one ending now. And I don't > want to miss another one. Ok, good, thanks. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH -next] drm/solomon: Make DRM_SSD130X depends on MMU
Hello YueHaibing,
Thanks for the patch.
On 3/12/22 07:34, YueHaibing wrote:
> WARNING: unmet direct dependencies detected for DRM_GEM_SHMEM_HELPER
> Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && MMU [=n]
> Selected by [m]:
> - DRM_SSD130X [=m] && HAS_IOMEM [=y] && DRM [=m]
>
> DRM_GEM_SHMEM_HELPER depends on MMU, DRM_SSD130X should also depends on MMU.
>
> Fixes: a61732e80867 ("drm: Add driver for Solomon SSD130x OLED displays")
> Signed-off-by: YueHaibing
> ---
Indeed. All the DRM drivers that select DRM_GEM_SHMEM_HELPER depend on MMU.
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
[PATCH] drm/amdgpu: Use ternary operator in `vcn_v1_0_start()`
Remove the boilerplate of declaring a variable and using an if else
statement by using the ternary operator.
Signed-off-by: Paul Menzel
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index 3799226defc0..78ad85fdc769 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -1095,13 +1095,8 @@ static int vcn_v1_0_start_dpg_mode(struct amdgpu_device
*adev)
static int vcn_v1_0_start(struct amdgpu_device *adev)
{
- int r;
-
- if (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG)
- r = vcn_v1_0_start_dpg_mode(adev);
- else
- r = vcn_v1_0_start_spg_mode(adev);
- return r;
+ return (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG) ?
+ vcn_v1_0_start_dpg_mode(adev) : vcn_v1_0_start_spg_mode(adev);
}
/**
--
2.35.1
Re: [PATCH v4] drm/msm/disp/dpu1: add inline rotation support for sc7280 target
On 15/03/2022 07:43, Vinod Polimera wrote:
- Some DPU versions support inline rot90. It is supported only for
limited amount of UBWC formats.
- There are two versions of inline rotators, v1 (present on sm8250 and
sm7250) and v2 (sc7280). These versions differ in the list of supported
formats and in the scaler possibilities.
Changes in RFC:
- Rebase changes to the latest code base.
- Append rotation config variables with v2 and
remove unused variables.(Dmitry)
- Move pixel_ext setup separately from scaler3 config.(Dmitry)
- Add 270 degree rotation to supported rotation list.(Dmitry)
Changes in V2:
- Remove unused macros and fix indentation.
- Add check if 90 rotation is supported and
add supported rotations to rot_cfg.
Changes in V3:
- Fix indentation.
- Move rot_supported to sspp capabilities. (Dmitry)
- Config pixel_ext based on src_h/src_w directly. (Dmitry)
- Misc changes.
Changes in V4:
- Pass boolean value to sspp blk based on supported rotations for each hw.
Co-developed-by: Kalyan Thota
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 187 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 18 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 113 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 +
4 files changed, 215 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index a4fe77c..060bf53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -35,6 +35,9 @@
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
+#define VIG_SC7280_MASK \
+ (VIG_SC7180_MASK | BIT(DPU_SSPP_INLINE_ROTATION))
+
#define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
@@ -203,6 +206,11 @@ static const uint32_t plane_formats_yuv[] = {
DRM_FORMAT_YVU420,
};
+static const u32 rotation_v2_formats[] = {
+ DRM_FORMAT_NV12,
+ /* TODO add formats after validation */
+};
+
/*
* DPU sub blocks config
*/
@@ -642,8 +650,7 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
*/
/* SSPP common configuration */
-
-#define _VIG_SBLK(num, sdma_pri, qseed_ver) \
+#define _VIG_SBLK(num, sdma_pri, qseed_ver, rot_cfg) \
{ \
.maxdwnscale = MAX_DOWNSCALE_RATIO, \
.maxupscale = MAX_UPSCALE_RATIO, \
@@ -660,6 +667,7 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
.num_formats = ARRAY_SIZE(plane_formats_yuv), \
.virt_format_list = plane_formats, \
.virt_num_formats = ARRAY_SIZE(plane_formats), \
+ .rotation_cfg = rot_cfg, \
}
#define _DMA_SBLK(num, sdma_pri) \
@@ -676,22 +684,28 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
}
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_0 =
- _VIG_SBLK("0", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("0", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_1 =
- _VIG_SBLK("1", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("1", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_2 =
- _VIG_SBLK("2", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("2", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_3 =
- _VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3, NULL);
+
+static const struct dpu_rotation_cfg dpu_rot_sc7280_cfg_v2 = {
+ .rot_maxheight = 1088,
+ .rot_num_formats = ARRAY_SIZE(rotation_v2_formats),
+ .rot_format_list = rotation_v2_formats,
+};
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_0 =
- _VIG_SBLK("0", 5, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("0", 5, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_1 =
- _VIG_SBLK("1", 6, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("1", 6, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_2 =
- _VIG_SBLK("2", 7, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("2", 7, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks sdm845_vig_sbl
Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v9)
On 15/03/2022 07:28, Kasireddy, Vivek wrote:
Hi Tvrtko, Daniel,
On 11/03/2022 09:39, Daniel Vetter wrote:
On Mon, 7 Mar 2022 at 21:38, Vivek Kasireddy wrote:
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies large enough to miss alternate
vblanks thereby producing less optimal framerate.
This mainly happens because when i915_gem_object_pin_to_display_plane()
is called to pin one of the FB objs, the associated vma is identified
as misplaced and therefore i915_vma_unbind() is called which unbinds and
evicts it. This misplaced vma gets subseqently pinned only when
i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
results in a latency of ~10ms and happens every other vblank/repaint cycle.
Therefore, to fix this issue, we try to see if there is space to map
at-least two objects of a given size and return early if there isn't. This
would ensure that we do not try with PIN_MAPPABLE for any objects that
are too big to map thereby preventing unncessary unbind.
Testcase:
Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
a frame ~7ms before the next vblank, the latencies seen between atomic
commit and flip event are 7, 24 (7 + 16.66), 7, 24. suggesting that
it misses the vblank every other frame.
Here is the ftrace snippet that shows the source of the ~10ms latency:
i915_gem_object_pin_to_display_plane() {
0.102 us |i915_gem_object_set_cache_level();
i915_gem_object_ggtt_pin_ww() {
0.390 us | i915_vma_instance();
0.178 us | i915_vma_misplaced();
i915_vma_unbind() {
__i915_active_wait() {
0.082 us |i915_active_acquire_if_busy();
0.475 us | }
intel_runtime_pm_get() {
0.087 us |intel_runtime_pm_acquire();
0.259 us | }
__i915_active_wait() {
0.085 us |i915_active_acquire_if_busy();
0.240 us | }
__i915_vma_evict() {
ggtt_unbind_vma() {
gen8_ggtt_clear_range() {
10507.255 us |}
10507.689 us | }
10508.516 us | }
v2: Instead of using bigjoiner checks, determine whether a scanout
buffer is too big by checking to see if it is possible to map
two of them into the ggtt.
v3 (Ville):
- Count how many fb objects can be fit into the available holes
instead of checking for a hole twice the object size.
- Take alignment constraints into account.
- Limit this large scanout buffer check to >= Gen 11 platforms.
v4:
- Remove existing heuristic that checks just for size. (Ville)
- Return early if we find space to map at-least two objects. (Tvrtko)
- Slightly update the commit message.
v5: (Tvrtko)
- Rename the function to indicate that the object may be too big to
map into the aperture.
- Account for guard pages while calculating the total size required
for the object.
- Do not subject all objects to the heuristic check and instead
consider objects only of a certain size.
- Do the hole walk using the rbtree.
- Preserve the existing PIN_NONBLOCK logic.
- Drop the PIN_MAPPABLE check while pinning the VMA.
v6: (Tvrtko)
- Return 0 on success and the specific error code on failure to
preserve the existing behavior.
v7: (Ville)
- Drop the HAS_GMCH(i915), DISPLAY_VER(i915) < 11 and
size < ggtt->mappable_end / 4 checks.
- Drop the redundant check that is based on previous heuristic.
v8:
- Make sure that we are holding the mutex associated with ggtt vm
as we traverse the hole nodes.
v9: (Tvrtko)
- Use mutex_lock_interruptible_nested() instead of mutex_lock().
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Cc: Manasi Navare
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/i915/i915_gem.c | 128 +++-
1 file changed, 94 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9747924cc57b..e0d731b3f215 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -49,6 +49,7 @@
#include "gem/i915_gem_pm.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_userptr.h"
+#include "gem/i915_gem_tiling.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
@@ -882,6 +883,96 @@ static void discard_ggtt_vma(struct i915_vma *vma)
spin_unlock(&obj->vma.lock);
}
+static int
+i915_gem_object_fits_in_aperture(struct drm_i915_gem_object *obj,
+u64 alignment, u64 flags)
Tvrtko asked me to ack the first patch, but then I looked at this and
started wondering.
Concept
[PATCH v5] drm/msm/disp/dpu1: add inline rotation support for sc7280 target
- Some DPU versions support inline rot90. It is supported only for
limited amount of UBWC formats.
- There are two versions of inline rotators, v1 (present on sm8250 and
sm7250) and v2 (sc7280). These versions differ in the list of supported
formats and in the scaler possibilities.
Changes in RFC:
- Rebase changes to the latest code base.
- Append rotation config variables with v2 and
remove unused variables.(Dmitry)
- Move pixel_ext setup separately from scaler3 config.(Dmitry)
- Add 270 degree rotation to supported rotation list.(Dmitry)
Changes in V2:
- Remove unused macros and fix indentation.
- Add check if 90 rotation is supported and
add supported rotations to rot_cfg.
Changes in V3:
- Fix indentation.
- Move rot_supported to sspp capabilities. (Dmitry)
- Config pixel_ext based on src_h/src_w directly. (Dmitry)
- Misc changes.
Changes in V4:
- Pass boolean value to sspp blk based on supported rotations for each hw.
Changes in V5:
- update boolean value to true/false and add it for qcm2290.
Co-developed-by: Kalyan Thota
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 187 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 18 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 113 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 +
4 files changed, 215 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index a4fe77c..060bf53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -35,6 +35,9 @@
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
+#define VIG_SC7280_MASK \
+ (VIG_SC7180_MASK | BIT(DPU_SSPP_INLINE_ROTATION))
+
#define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
@@ -203,6 +206,11 @@ static const uint32_t plane_formats_yuv[] = {
DRM_FORMAT_YVU420,
};
+static const u32 rotation_v2_formats[] = {
+ DRM_FORMAT_NV12,
+ /* TODO add formats after validation */
+};
+
/*
* DPU sub blocks config
*/
@@ -642,8 +650,7 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
*/
/* SSPP common configuration */
-
-#define _VIG_SBLK(num, sdma_pri, qseed_ver) \
+#define _VIG_SBLK(num, sdma_pri, qseed_ver, rot_cfg) \
{ \
.maxdwnscale = MAX_DOWNSCALE_RATIO, \
.maxupscale = MAX_UPSCALE_RATIO, \
@@ -660,6 +667,7 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
.num_formats = ARRAY_SIZE(plane_formats_yuv), \
.virt_format_list = plane_formats, \
.virt_num_formats = ARRAY_SIZE(plane_formats), \
+ .rotation_cfg = rot_cfg, \
}
#define _DMA_SBLK(num, sdma_pri) \
@@ -676,22 +684,28 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
}
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_0 =
- _VIG_SBLK("0", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("0", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_1 =
- _VIG_SBLK("1", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("1", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_2 =
- _VIG_SBLK("2", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("2", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_3 =
- _VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3, NULL);
+
+static const struct dpu_rotation_cfg dpu_rot_sc7280_cfg_v2 = {
+ .rot_maxheight = 1088,
+ .rot_num_formats = ARRAY_SIZE(rotation_v2_formats),
+ .rot_format_list = rotation_v2_formats,
+};
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_0 =
- _VIG_SBLK("0", 5, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("0", 5, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_1 =
- _VIG_SBLK("1", 6, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("1", 6, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_2 =
- _VIG_SBLK("2", 7, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("2", 7, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks sdm845_vig_sblk
Re: [PATCH v2 05/10] drm/fourcc: Add DRM_FORMAT_C[124]
On Tue, 15 Mar 2022 09:57:23 +0100
Geert Uytterhoeven wrote:
> Hi Pekka,
>
> On Tue, Mar 15, 2022 at 9:46 AM Pekka Paalanen wrote:
> > On Tue, 15 Mar 2022 08:51:31 +0100
> > Geert Uytterhoeven wrote:
> > > On Tue, Mar 15, 2022 at 8:33 AM Pekka Paalanen
> > > wrote:
> > > > On Tue, 15 Mar 2022 09:15:08 +1100 (AEDT)
> > > > Finn Thain wrote:
> > > > > On Mon, 14 Mar 2022, Geert Uytterhoeven wrote:
> > > > > > On Mon, Mar 14, 2022 at 4:05 PM Pekka Paalanen
> > > > > > wrote:
> > > > > > > On Mon, 14 Mar 2022 14:30:18 +0100
> > > > > > > Geert Uytterhoeven wrote:
> > > > > > > > On Mon, Mar 7, 2022 at 9:53 PM Geert Uytterhoeven
> > > > > > > > wrote:
> > > > > > > > > Introduce fourcc codes for color-indexed frame buffer formats
> > > > > > > > > with
> > > > > > > > > two, four, and sixteen colors, and provide a mapping from bit
> > > > > > > > > per
> > > > > > > > > pixel and depth to fourcc codes.
> > > > > > > > >
> > > > > > > > > As the number of bits per pixel is less than eight, these
> > > > > > > > > rely on
> > > > > > > > > proper block handling for the calculation of bits per pixel
> > > > > > > > > and
> > > > > > > > > pitch.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Geert Uytterhoeven
> > > > > > > >
> > > > > > > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > > > > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > > > > > > @@ -99,7 +99,10 @@ extern "C" {
> > > > > > > > > #define DRM_FORMAT_INVALID 0
> > > > > > > > >
> > > > > > > > > /* color index */
> > > > > > > > > -#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', '
> > > > > > > > > ') /* [7:0] C */
> > > > > > > > > +#define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', '
> > > > > > > > > ') /* [7:0] C0:C1:C2:C3:C4:C5:C6:C7 1:1:1:1:1:1:1:1 eight
> > > > > > > > > pixels/byte */
> > > > > > > > > +#define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', '
> > > > > > > > > ') /* [7:0] C0:C1:C2:C3 2:2:2:2 four pixels/byte */
> > > > > > > > > +#define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', '
> > > > > > > > > ') /* [7:0] C0:C1 4:4 two pixels/byte */
> > > > > > > > > +#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', '
> > > > > > > > > ') /* [7:0] C 8 one pixel/byte */
> > > > > > > > >
> > > > > > > > > /* 8 bpp Red */
> > > > > > > > > #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', '
> > > > > > > > > ') /* [7:0] R */
> > > > > > > >
> > > > > > > > After replying to Ilia's comment[1], I realized the CFB drawing
> > > > > > > > operations use native byte and bit ordering, unless
> > > > > > > > FBINFO_FOREIGN_ENDIAN is set.
> > > > > > > > While Amiga, Atari, and Sun-3 use big-endian bit ordering,
> > > > > > > > e.g. Acorn VIDC[2] uses little endian, and SH7760[3] is
> > > > > > > > configurable
> > > > > > > > (sh7760fb configures ordering to match host order).
> > > > > > > > BTW, ssd130{7fb,x}_update_rect() both assume little-endian, so I
> > > > > > > > guess they are broken on big-endian.
> > > > > > > > Fbtest uses big-endian bit ordering, so < 8 bpp is probably
> > > > > > > > broken
> > > > > > > > on little-endian.
> > > > > > > >
> > > > > > > > Hence the above should become:
> > > > > > > >
> > > > > > > > #define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', '
> > > > > > > > ') /*
> > > > > > > > [7:0] C7:C6:C5:C4:C3:C2:C1:C0 1:1:1:1:1:1:1:1 eight pixels/byte
> > > > > > > > */
> > > > > > > > #define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', '
> > > > > > > > ') /*
> > > > > > > > [7:0] C3:C2:C1:C0 2:2:2:2 four pixels/byte */
> > > > > > > > #define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', '
> > > > > > > > ') /*
> > > > > > > > [7:0] C1:C0 4:4 two pixels/byte */
> > > > > > > >
> > > > > > > > The same changes should be made for DRM_FORMAT_[RD][124].
> > > > > > > >
> > > > > > > > The fbdev emulation code should gain support for these with and
> > > > > > > > without
> > > > > > > > DRM_FORMAT_BIG_ENDIAN, the latter perhaps only on big-endian
> > > > > > > > platforms?
> > > > > > > >
> > > > > > > > [1]
> > > > > > > > https://lore.kernel.org/r/CAKb7UvgEdm9U=+ryrwl0tgrfa_qc7nbhcwozoft2dkdxggt...@mail.gmail.com/
> > > > > > > > [2] See p.30 of the VIDC datasheet
> > > > > > > >
> > > > > > > > http://chrisacorns.computinghistory.org.uk/docs/Acorn/Misc/Acorn_VIDC_Datasheet.pdf
> > > > > > > > [3] See p.1178 of the SH7660 datasheet
> > > > > > > >
> > > > > > > > https://datasheet.octopart.com/HD6417760BL200AV-Renesas-datasheet-14105759.pdf
> > > > > > > >
> > > > > > >
> > > > > > > why would CPU endianess affect the order of bits in a byte?
> > > > > >
> > > > > > It doesn't, but see below.
> > > > > >
> > > > > > > Do you mean that bit 0 one machine is (1 << 0), and on another
> > > > > > > machine
> > > > > > > bit 0 is (1 << 7)?
> > > > > >
> > > > > > No, I mean that in case of multiple pixels per byte, the display
> > > > > > hardware pumps out p
Re: [PATCH V7 1/5] dt-bindings: display: mediatek: add aal binding for MT8183
On 14/03/2022 10:00, Rex-BC Chen wrote: > Add aal binding for MT8183. > > Signed-off-by: Rex-BC Chen > Acked-by: Rob Herring > --- > .../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > index 61f0ed1e388f..6c8c83988a24 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > @@ -23,6 +23,8 @@ properties: > oneOf: >- items: >- const: mediatek,mt8173-disp-aal > + - items: > + - const: mediatek,mt8183-disp-aal Use enum in previous entry. This is weird setup to have items with one element and then duplicate it for another oneOf entry. >- items: >- enum: >- mediatek,mt2712-disp-aal Best regards, Krzysztof
Re: [v7 3/5] drm/edid: read HF-EEODB ext block
On Sun, 13 Mar 2022, Lee Shawn C wrote:
> According to HDMI 2.1 spec.
>
> "The HDMI Forum EDID Extension Override Data Block (HF-EEODB)
> is utilized by Sink Devices to provide an alternate method to
> indicate an EDID Extension Block count larger than 1, while
> avoiding the need to present a VESA Block Map in the first
> E-EDID Extension Block."
>
> It is a mandatory for HDMI 2.1 protocol compliance as well.
> This patch help to know how many HF_EEODB blocks report by sink
> and read allo HF_EEODB blocks back.
>
> v2: support to find CEA block, check EEODB block format, and return
> available block number in drm_edid_read_hf_eeodb_blk_count().
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Ankit Nautiyal
> Cc: Drew Davenport
> Cc: intel-gfx
> Signed-off-by: Lee Shawn C
> ---
> drivers/gpu/drm/drm_connector.c | 8 +++-
> drivers/gpu/drm/drm_edid.c | 71 +++--
> include/drm/drm_edid.h | 1 +
> 3 files changed, 74 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index a50c82bc2b2f..16011023c12e 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -2129,7 +2129,7 @@ int drm_connector_update_edid_property(struct
> drm_connector *connector,
> const struct edid *edid)
> {
> struct drm_device *dev = connector->dev;
> - size_t size = 0;
> + size_t size = 0, hf_eeodb_blk_count;
> int ret;
> const struct edid *old_edid;
>
> @@ -2137,8 +2137,12 @@ int drm_connector_update_edid_property(struct
> drm_connector *connector,
> if (connector->override_edid)
> return 0;
>
> - if (edid)
> + if (edid) {
> size = EDID_LENGTH * (1 + edid->extensions);
> + hf_eeodb_blk_count = drm_edid_read_hf_eeodb_blk_count(edid);
> + if (hf_eeodb_blk_count)
> + size = EDID_LENGTH * (1 + hf_eeodb_blk_count);
This approach does not scale. If the number of extensions and thus the
total EDID size depend on HF-EEODB, this *must* be abstracted.
Consider, for example, drm_edid_duplicate(), which only looks at
edid->extensions. A subsequent HF-EEODB aware access on an EDID
duplicated using drm_edid_duplicate() will access beyond the allocated
buffer.
Yes, it's a lot of work to introduce drm_edid_size() and
drm_edid_extension_count() or similar, and use them everywhere, but this
is what we must do. It's a lot more work to try to take HF-EEODB into
account everywhere. The latter is going to be riddled with bugs with
everyone doing it a little different.
> + }
>
> /* Set the display info, using edid if available, otherwise
>* resetting the values to defaults. This duplicates the work
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9fa84881fbba..5ae4e83fa5e3 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1992,6 +1992,7 @@ struct edid *drm_do_get_edid(struct drm_connector
> *connector,
> {
> int i, j = 0, valid_extensions = 0;
> u8 *edid, *new;
> + size_t hf_eeodb_blk_count;
> struct edid *override;
>
> override = drm_get_override_edid(connector);
> @@ -2051,7 +2052,35 @@ struct edid *drm_do_get_edid(struct drm_connector
> *connector,
> }
>
> kfree(edid);
> + return (struct edid *)new;
> + }
> +
> + hf_eeodb_blk_count = drm_edid_read_hf_eeodb_blk_count((struct edid
> *)edid);
> + if (hf_eeodb_blk_count >= 2) {
> + new = krealloc(edid, (hf_eeodb_blk_count + 1) * EDID_LENGTH,
> GFP_KERNEL);
> + if (!new)
> + goto out;
> edid = new;
> +
> + valid_extensions = hf_eeodb_blk_count - 1;
> + for (j = 2; j <= hf_eeodb_blk_count; j++) {
> + u8 *block = edid + j * EDID_LENGTH;
> +
> + for (i = 0; i < 4; i++) {
> + if (get_edid_block(data, block, j, EDID_LENGTH))
> + goto out;
> + if (drm_edid_block_valid(block, j, false, NULL))
> + break;
> + }
> +
> + if (i == 4)
> + valid_extensions--;
> + }
> +
> + if (valid_extensions != hf_eeodb_blk_count - 1) {
> + DRM_ERROR("Not able to retrieve proper EDID contain
> HF-EEODB data.\n");
> + goto out;
> + }
> }
>
> return (struct edid *)edid;
> @@ -3315,15 +3344,17 @@ add_detailed_modes(struct drm_connector *connector,
> struct edid *edid,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK0x04
> -#define HDR_STATIC_METADATA_BLOCK0x6
> -#define USE_EXTENDED_TAG 0x07
> -#define EXT_VIDEO_CA
[PATCH 5/5] drm/repaper: Reduce temporary buffer size in repaper_fb_dirty()
As the temporary buffer is no longer used to store 8-bit grayscale data,
its size can be reduced to the size needed to store the monochrome
bitmap data.
Fixes: 24c6bedefbe71de9 ("drm/repaper: Use format helper for xrgb to
monochrome conversion")
Signed-off-by: Geert Uytterhoeven
---
Untested due to lack of hardware.
I replaced kmalloc_array() by kmalloc() to match size calculations in
other locations in this driver. There is no point in handling a
possible multiplication overflow only here.
---
drivers/gpu/drm/tiny/repaper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c
index a096fb8b83e99dc8..7738b87f370ad147 100644
--- a/drivers/gpu/drm/tiny/repaper.c
+++ b/drivers/gpu/drm/tiny/repaper.c
@@ -530,7 +530,7 @@ static int repaper_fb_dirty(struct drm_framebuffer *fb)
DRM_DEBUG("Flushing [FB:%d] st=%ums\n", fb->base.id,
epd->factored_stage_time);
- buf = kmalloc_array(fb->width, fb->height, GFP_KERNEL);
+ buf = kmalloc(fb->width * fb->height / 8, GFP_KERNEL);
if (!buf) {
ret = -ENOMEM;
goto out_exit;
--
2.25.1
[PATCH 3/5] drm: ssd130x: Fix rectangle updates
The rectangle update functions ssd130x_fb_blit_rect() and
ssd130x_update_rect() do not behave correctly when x1 != 0 or y1 !=
0, or when y1 or y2 are not aligned to display page boundaries.
E.g. when used as a text console, only the first line of text is shown
on the display.
1. The buffer passed by ssd130x_fb_blit_rect() points to the first
byte of monochrome bitmap data, and thus has its origin at (x1,
y1), while ssd130x_update_rect() assumes it is at (0, 0).
Fix ssd130x_update_rect() by changing the vertical and horizontal
loop ranges, and adding the offsets only when needed.
2. In ssd130x_fb_blit_rect(), align y1 and y2 to the display page
boundaries before doing the color conversion, so the full page
is converted and updated.
Remove the correction for an unaligned y1 from
ssd130x_update_rect(), and add a check to make sure y1 is aligned.
Fixes: a61732e808672cfa ("drm: Add driver for Solomon SSD130x OLED displays")
Signed-off-by: Geert Uytterhoeven
---
Note that instead of calling drm_fb_xrgb_to_mono() and transposing
the bitmap, the image data could be converted to the transposed format
directly. However, that would preclude exposing a monochrome format to
userspace when a fourcc for such a monochrome format is introduced.
---
drivers/gpu/drm/solomon/ssd130x.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon/ssd130x.c
index caee851efd5726e7..7c99af4ce9dd4e5c 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -355,11 +355,14 @@ static int ssd130x_update_rect(struct ssd130x_device
*ssd130x, u8 *buf,
unsigned int width = drm_rect_width(rect);
unsigned int height = drm_rect_height(rect);
unsigned int line_length = DIV_ROUND_UP(width, 8);
- unsigned int pages = DIV_ROUND_UP(y % 8 + height, 8);
+ unsigned int pages = DIV_ROUND_UP(height, 8);
+ struct drm_device *drm = &ssd130x->drm;
u32 array_idx = 0;
int ret, i, j, k;
u8 *data_array = NULL;
+ drm_WARN_ONCE(drm, y % 8 != 0, "y must be aligned to screen page\n");
+
data_array = kcalloc(width, pages, GFP_KERNEL);
if (!data_array)
return -ENOMEM;
@@ -401,13 +404,13 @@ static int ssd130x_update_rect(struct ssd130x_device
*ssd130x, u8 *buf,
if (ret < 0)
goto out_free;
- for (i = y / 8; i < y / 8 + pages; i++) {
+ for (i = 0; i < pages; i++) {
int m = 8;
/* Last page may be partial */
- if (8 * (i + 1) > ssd130x->height)
+ if (8 * (y / 8 + i + 1) > ssd130x->height)
m = ssd130x->height % 8;
- for (j = x; j < x + width; j++) {
+ for (j = 0; j < width; j++) {
u8 data = 0;
for (k = 0; k < m; k++) {
@@ -454,6 +457,10 @@ static int ssd130x_fb_blit_rect(struct drm_framebuffer
*fb, const struct iosys_m
int ret = 0;
u8 *buf = NULL;
+ /* Align y to display page boundaries */
+ rect->y1 = round_down(rect->y1, 8);
+ rect->y2 = min_t(unsigned int, round_up(rect->y2, 8), ssd130x->height);
+
buf = kcalloc(fb->width, fb->height, GFP_KERNEL);
if (!buf)
return -ENOMEM;
--
2.25.1
[PATCH 2/5] drm/format-helper: Fix XRGB888 to monochrome conversion
The conversion functions drm_fb_xrgb_to_mono() and
drm_fb_gray8_to_mono_line() do not behave correctly when the
horizontal boundaries of the clip rectangle are not multiples of 8:
a. When x1 % 8 != 0, the calculated pitch is not correct,
b. When x2 % 8 != 0, the pixel data for the last byte is wrong.
Simplify the code and fix (a) by:
1. Removing start_offset, and always storing the first pixel in the
first bit of the monochrome destination buffer.
Drivers that require the first pixel in a byte to be located at an
x-coordinate that is a multiple of 8 can always align the clip
rectangle before calling drm_fb_xrgb_to_mono().
Note that:
- The ssd130x driver does not need the alignment, as the
monochrome buffer is a temporary format,
- The repaper driver always updates the full screen, so the clip
rectangle is always aligned.
2. Passing the number of pixels to drm_fb_gray8_to_mono_line(),
instead of the number of bytes, and the number of pixels in the
last byte.
Fix (b) by explicitly setting the target bit, instead of always setting
bit 7 and shifting the value in each loop iteration.
Remove the bogus pitch check, which operates on bytes instead of pixels,
and triggers when e.g. flashing the cursor on a text console with a font
that is 8 pixels wide.
Drop the confusing comment about scanlines, as a pitch in bytes always
contains a multiple of 8 pixels.
While at it, use the drm_rect_height() helper instead of open-coding the
same operation.
Update the comments accordingly.
Fixes: bcf8b616deb87941 ("drm/format-helper: Add
drm_fb_xrgb_to_mono_reversed()")
Signed-off-by: Geert Uytterhoeven
---
I tried hard to fix this in small steps, but everything was no
intertangled that this turned out to be unfeasible.
Note that making these changes does not introduce regressions in the
ssd130x driver, as the latter is broken for x1 != 0 or y1 != 0 anyway.
---
drivers/gpu/drm/drm_format_helper.c | 56 ++---
1 file changed, 18 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index b68aa857c6514529..0d7cae921ed1134f 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -594,27 +594,16 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int
dst_pitch, uint32_t dst_for
}
EXPORT_SYMBOL(drm_fb_blit_toio);
-static void drm_fb_gray8_to_mono_line(u8 *dst, const u8 *src, unsigned int
pixels,
- unsigned int start_offset, unsigned int
end_len)
-{
- unsigned int xb, i;
-
- for (xb = 0; xb < pixels; xb++) {
- unsigned int start = 0, end = 8;
- u8 byte = 0x00;
-
- if (xb == 0 && start_offset)
- start = start_offset;
- if (xb == pixels - 1 && end_len)
- end = end_len;
-
- for (i = start; i < end; i++) {
- unsigned int x = xb * 8 + i;
+static void drm_fb_gray8_to_mono_line(u8 *dst, const u8 *src, unsigned int
pixels)
+{
+ while (pixels) {
+ unsigned int i, bits = min(pixels, 8U);
+ u8 byte = 0;
- byte >>= 1;
- if (src[x] >> 7)
- byte |= BIT(7);
+ for (i = 0; i < bits; i++, pixels--) {
+ if (*src++ & BIT(7))
+ byte |= BIT(i);
}
*dst++ = byte;
}
@@ -634,16 +623,22 @@ static void drm_fb_gray8_to_mono_line(u8 *dst, const u8
*src, unsigned int pixel
*
* This function uses drm_fb_xrgb_to_gray8() to convert to grayscale and
* then the result is converted from grayscale to monochrome.
+ *
+ * The first pixel (upper left corner of the clip rectangle) will be converted
+ * and copied to the first bit (LSB) in the first byte of the monochrome
+ * destination buffer.
+ * If the caller requires that the first pixel in a byte must be located at an
+ * x-coordinate that is a multiple of 8, then the caller must take care itself
+ * of supplying a suitable clip rectangle.
*/
void drm_fb_xrgb_to_mono(void *dst, unsigned int dst_pitch, const void
*vaddr,
const struct drm_framebuffer *fb, const struct
drm_rect *clip)
{
unsigned int linepixels = drm_rect_width(clip);
- unsigned int lines = clip->y2 - clip->y1;
+ unsigned int lines = drm_rect_height(clip);
unsigned int cpp = fb->format->cpp[0];
unsigned int len_src32 = linepixels * cpp;
struct drm_device *dev = fb->dev;
- unsigned int start_offset, end_len;
unsigned int y;
u8 *mono = dst, *gray8;
u32 *src32;
@@ -652,14 +647,11 @@ void drm_fb_xrgb_to_mono(void *dst, unsigned int
dst_pitch, const void *vadd
return;
/*
-* The mo
[PATCH 0/5] drm: Fix monochrome conversion for sdd130x
Hi all,
This patch series contains fixes and improvements for the XRGB888 to
monochrome conversion in the DRM core, and for its users.
This has been tested on an Adafruit FeatherWing 128x32 OLED, connected
to an OrangeCrab ECP5 FPGA board running a 64 MHz VexRiscv RISC-V
softcore, using a text console with 7x14 and 8x8 fonts.
Thanks for your comments!
Geert Uytterhoeven (5):
drm/format-helper: Rename drm_fb_xrgb_to_mono_reversed()
drm/format-helper: Fix XRGB888 to monochrome conversion
drm: ssd130x: Fix rectangle updates
drm: ssd130x: Reduce temporary buffer sizes
drm/repaper: Reduce temporary buffer size in repaper_fb_dirty()
drivers/gpu/drm/drm_format_helper.c | 74 +++--
drivers/gpu/drm/solomon/ssd130x.c | 24 +++---
drivers/gpu/drm/tiny/repaper.c | 4 +-
include/drm/drm_format_helper.h | 5 +-
4 files changed, 48 insertions(+), 59 deletions(-)
--
2.25.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 4/5] drm: ssd130x: Reduce temporary buffer sizes
ssd130x_clear_screen() allocates a temporary buffer sized to hold one
byte per pixel, while it only needs to hold one bit per pixel.
ssd130x_fb_blit_rect() allocates a temporary buffer sized to hold one
byte per pixel for the whole frame buffer, while it only needs to hold
one bit per pixel for the part that is to be updated.
Pass dst_pitch to drm_fb_xrgb_to_mono_reversed(), as we have already
calculated it anyway.
Fixes: a61732e808672cfa ("drm: Add driver for Solomon SSD130x OLED displays")
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/solomon/ssd130x.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon/ssd130x.c
index 7c99af4ce9dd4e5c..38b6c2c14f53644b 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -440,7 +440,8 @@ static void ssd130x_clear_screen(struct ssd130x_device
*ssd130x)
.y2 = ssd130x->height,
};
- buf = kcalloc(ssd130x->width, ssd130x->height, GFP_KERNEL);
+ buf = kcalloc(DIV_ROUND_UP(ssd130x->width, 8), ssd130x->height,
+ GFP_KERNEL);
if (!buf)
return;
@@ -454,6 +455,7 @@ static int ssd130x_fb_blit_rect(struct drm_framebuffer *fb,
const struct iosys_m
{
struct ssd130x_device *ssd130x = drm_to_ssd130x(fb->dev);
void *vmap = map->vaddr; /* TODO: Use mapping abstraction properly */
+ unsigned int dst_pitch;
int ret = 0;
u8 *buf = NULL;
@@ -461,11 +463,12 @@ static int ssd130x_fb_blit_rect(struct drm_framebuffer
*fb, const struct iosys_m
rect->y1 = round_down(rect->y1, 8);
rect->y2 = min_t(unsigned int, round_up(rect->y2, 8), ssd130x->height);
- buf = kcalloc(fb->width, fb->height, GFP_KERNEL);
+ dst_pitch = DIV_ROUND_UP(drm_rect_width(rect), 8);
+ buf = kcalloc(dst_pitch, drm_rect_height(rect), GFP_KERNEL);
if (!buf)
return -ENOMEM;
- drm_fb_xrgb_to_mono(buf, 0, vmap, fb, rect);
+ drm_fb_xrgb_to_mono(buf, dst_pitch, vmap, fb, rect);
ssd130x_update_rect(ssd130x, buf, rect);
--
2.25.1
[PATCH 1/5] drm/format-helper: Rename drm_fb_xrgb8888_to_mono_reversed()
There is no "reversed" handling in drm_fb_xrgb_to_mono_reversed():
the function just converts from color to grayscale, and reduces the
number of grayscale levels from 256 to 2 (i.e. brightness 0-127 is
mapped to 0, 128-255 to 1). All "reversed" handling is done in the
repaper driver, where this function originated.
Hence make this clear by renaming drm_fb_xrgb_to_mono_reversed() to
drm_fb_xrgb_to_mono(), and documenting the black/white pixel
mapping.
Fixes: bcf8b616deb87941 ("drm/format-helper: Add
drm_fb_xrgb_to_mono_reversed()")
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/drm_format_helper.c | 32 ++---
drivers/gpu/drm/solomon/ssd130x.c | 2 +-
drivers/gpu/drm/tiny/repaper.c | 2 +-
include/drm/drm_format_helper.h | 5 ++---
4 files changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index bc0f49773868a9b0..b68aa857c6514529 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -594,8 +594,8 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int
dst_pitch, uint32_t dst_for
}
EXPORT_SYMBOL(drm_fb_blit_toio);
-static void drm_fb_gray8_to_mono_reversed_line(u8 *dst, const u8 *src,
unsigned int pixels,
- unsigned int start_offset,
unsigned int end_len)
+static void drm_fb_gray8_to_mono_line(u8 *dst, const u8 *src, unsigned int
pixels,
+ unsigned int start_offset, unsigned int
end_len)
{
unsigned int xb, i;
@@ -621,8 +621,8 @@ static void drm_fb_gray8_to_mono_reversed_line(u8 *dst,
const u8 *src, unsigned
}
/**
- * drm_fb_xrgb_to_mono_reversed - Convert XRGB to reversed monochrome
- * @dst: reversed monochrome destination buffer
+ * drm_fb_xrgb_to_mono - Convert XRGB to monochrome
+ * @dst: monochrome destination buffer (0=black, 1=white)
* @dst_pitch: Number of bytes between two consecutive scanlines within dst
* @src: XRGB source buffer
* @fb: DRM framebuffer
@@ -633,10 +633,10 @@ static void drm_fb_gray8_to_mono_reversed_line(u8 *dst,
const u8 *src, unsigned
* and use this function to convert to the native format.
*
* This function uses drm_fb_xrgb_to_gray8() to convert to grayscale and
- * then the result is converted from grayscale to reversed monohrome.
+ * then the result is converted from grayscale to monochrome.
*/
-void drm_fb_xrgb_to_mono_reversed(void *dst, unsigned int dst_pitch, const
void *vaddr,
- const struct drm_framebuffer *fb, const
struct drm_rect *clip)
+void drm_fb_xrgb_to_mono(void *dst, unsigned int dst_pitch, const void
*vaddr,
+const struct drm_framebuffer *fb, const struct
drm_rect *clip)
{
unsigned int linepixels = drm_rect_width(clip);
unsigned int lines = clip->y2 - clip->y1;
@@ -652,8 +652,8 @@ void drm_fb_xrgb_to_mono_reversed(void *dst, unsigned
int dst_pitch, const v
return;
/*
-* The reversed mono destination buffer contains 1 bit per pixel
-* and destination scanlines have to be in multiple of 8 pixels.
+* The mono destination buffer contains 1 bit per pixel and
+* destination scanlines have to be in multiple of 8 pixels.
*/
if (!dst_pitch)
dst_pitch = DIV_ROUND_UP(linepixels, 8);
@@ -664,9 +664,9 @@ void drm_fb_xrgb_to_mono_reversed(void *dst, unsigned
int dst_pitch, const v
* The cma memory is write-combined so reads are uncached.
* Speed up by fetching one line at a time.
*
-* Also, format conversion from XR24 to reversed monochrome
-* are done line-by-line but are converted to 8-bit grayscale
-* as an intermediate step.
+* Also, format conversion from XR24 to monochrome are done
+* line-by-line but are converted to 8-bit grayscale as an
+* intermediate step.
*
* Allocate a buffer to be used for both copying from the cma
* memory and to store the intermediate grayscale line pixels.
@@ -683,7 +683,7 @@ void drm_fb_xrgb_to_mono_reversed(void *dst, unsigned
int dst_pitch, const v
* are not aligned to multiple of 8.
*
* Calculate if the start and end pixels are not aligned and set the
-* offsets for the reversed mono line conversion function to adjust.
+* offsets for the mono line conversion function to adjust.
*/
start_offset = clip->x1 % 8;
end_len = clip->x2 % 8;
@@ -692,12 +692,12 @@ void drm_fb_xrgb_to_mono_reversed(void *dst, unsigned
int dst_pitch, const v
for (y = 0; y < lines; y++) {
src32 = memcpy(src32, vaddr, len_src32);
drm_fb_xrgb_to_gray8_line(gray8, src32, linepixels);
- drm_fb_gray8_to_mono_reversed_line(
Re: [PATCH v3 7/7] drm/i915: fixup the initial fb base on DGFX
|This seems more natural to me than the previous version. Acked-by:
Nirmoy Das |
Nirmoy
On 14/03/2022 12:28, Matthew Auld wrote:
On integrated it looks like the GGTT base should always 1:1 maps to
somewhere within DSM. On discrete the base seems to be pre-programmed with
a normal lmem address, and is not 1:1 mapped with the base address. On
such devices probe the lmem address directly from the PTE.
v2(Ville):
- The base is actually the pre-programmed GGTT address, which is then
meant to 1:1 map to somewhere inside dsm. In the case of dgpu the
base looks to just be some offset within lmem, but this also happens
to be the exact dsm start, on dg1. Therefore we should only need to
fudge the physical address, before allocating from stolen.
- Bail if it's not located in dsm.
v3:
- Scratch that. There doesn't seem to be any relationship with the
base and PTE address, on at least DG1. Let's instead just grab the
lmem address from the PTE itself.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ville Syrjälä
Cc: Nirmoy Das
---
.../drm/i915/display/intel_plane_initial.c| 50 ---
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index f797fcef18fc..7979929bb632 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -47,17 +47,55 @@ static struct i915_vma *
initial_plane_vma(struct drm_i915_private *i915,
struct intel_initial_plane_config *plane_config)
{
- struct intel_memory_region *mem = i915->mm.stolen_region;
+ struct intel_memory_region *mem;
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
+ resource_size_t phys_base;
u32 base, size;
u64 pinctl;
- if (!mem || plane_config->size == 0)
+ if (plane_config->size == 0)
+ return NULL;
+
+ base = round_down(plane_config->base, I915_GTT_MIN_ALIGNMENT);
+ if (IS_DGFX(i915)) {
+ gen8_pte_t __iomem *gte = to_gt(i915)->ggtt->gsm;
+ gen8_pte_t pte;
+
+ gte += base / I915_GTT_PAGE_SIZE;
+
+ pte = ioread64(gte);
+ if (!(pte & GEN12_GGTT_PTE_LM)) {
+ drm_err(&i915->drm,
+ "Initial plane programming missing PTE_LM
bit\n");
+ return NULL;
+ }
+
+ phys_base = pte & I915_GTT_PAGE_MASK;
+ mem = i915->mm.regions[INTEL_REGION_LMEM];
+
+ /*
+* We don't currently expect this to ever be placed in the
+* stolen portion.
+*/
+ if (phys_base >= resource_size(&mem->region)) {
+ drm_err(&i915->drm,
+ "Initial plane programming using invalid range,
phys_base=%pa\n",
+ &phys_base);
+ return NULL;
+ }
+
+ drm_dbg(&i915->drm,
+ "Using phys_base=%pa, based on initial plane
programming\n",
+ &phys_base);
+ } else {
+ phys_base = base;
+ mem = i915->mm.stolen_region;
+ }
+
+ if (!mem)
return NULL;
- base = round_down(plane_config->base,
- I915_GTT_MIN_ALIGNMENT);
size = round_up(plane_config->base + plane_config->size,
mem->min_page_size);
size -= base;
@@ -68,11 +106,11 @@ initial_plane_vma(struct drm_i915_private *i915,
* features.
*/
if (IS_ENABLED(CONFIG_FRAMEBUFFER_CONSOLE) &&
+ mem == i915->mm.stolen_region &&
size * 2 > i915->stolen_usable_size)
return NULL;
- obj = i915_gem_object_create_region_at(i915->mm.stolen_region,
- base, size, 0);
+ obj = i915_gem_object_create_region_at(mem, phys_base, size, 0);
if (IS_ERR(obj))
return NULL;
Re: [Intel-gfx] [PATCH] drm/i915: round_up the size to the alignment value
On Mon, 14 Mar 2022 at 19:32, Arunpravin
wrote:
>
> handle instances when size is not aligned with the min_page_size.
> Unigine Heaven has allocation requests for example required pages
> are 161 and alignment request is 128. To allocate the left over
> 33 pages, continues the iteration to find the order value which
> is 5 and 0 and when it compares with min_order = 7, triggers the
> BUG_ON((order < min_order). To avoid this problem, round_up the
> size to the alignment and enable the is_contiguous variable and
> the block trimmed to the original size.
>
> Signed-off-by: Arunpravin
> ---
> drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> index 129f668f21ff..318aa731de5b 100644
> --- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> +++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> @@ -40,6 +40,7 @@ static int i915_ttm_buddy_man_alloc(struct
> ttm_resource_manager *man,
> struct i915_ttm_buddy_resource *bman_res;
> struct drm_buddy *mm = &bman->mm;
> unsigned long n_pages, lpfn;
> + bool is_contiguous = 0;
> u64 min_page_size;
> u64 size;
> int err;
> @@ -48,6 +49,9 @@ static int i915_ttm_buddy_man_alloc(struct
> ttm_resource_manager *man,
> if (!lpfn)
> lpfn = man->size;
>
> + if (place->flags & TTM_PL_FLAG_CONTIGUOUS)
> + is_contiguous = 1;
> +
> bman_res = kzalloc(sizeof(*bman_res), GFP_KERNEL);
> if (!bman_res)
> return -ENOMEM;
> @@ -71,7 +75,12 @@ static int i915_ttm_buddy_man_alloc(struct
> ttm_resource_manager *man,
>
> GEM_BUG_ON(min_page_size < mm->chunk_size);
>
> - if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
> + if (!is_contiguous && !IS_ALIGNED(size, min_page_size)) {
> + size = round_up(size, min_page_size);
> + is_contiguous = 1;
> + }
> +
> + if (is_contiguous) {
This looks like it will also do roundup_power_of_two()? I assume we
instead just want to feed the list_last_entry() block for trimming?
Anway, we should be able to just make this:
if (WARN_ON(!IS_ALIGNED(size, min_page_size))
return -EINVAL;
That's at least the currently expected behaviour in i915, just that we
were previously not verifying it here.
> unsigned long pages;
>
> size = roundup_pow_of_two(size);
> @@ -106,7 +115,7 @@ static int i915_ttm_buddy_man_alloc(struct
> ttm_resource_manager *man,
> if (unlikely(err))
> goto err_free_blocks;
>
> - if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
> + if (is_contiguous) {
> u64 original_size = (u64)bman_res->base.num_pages <<
> PAGE_SHIFT;
>
> mutex_lock(&bman->lock);
>
> base-commit: b37605de46fef48555bf0cf463cccf355c51fac0
> --
> 2.25.1
>
Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
On 14/03/2022 19:40, Arunpravin wrote:
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC
Signed-off-by: Arunpravin
Hmm, it sounded like we were instead going to go with the round_up(size,
min_page_size), or check and bail if the size is misaligned, in which
case we don't need this, AFAICT.
---
drivers/gpu/drm/drm_buddy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
- if (order-- == min_order) {
+ if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
Re: [PATCH 1/5] drm/format-helper: Rename drm_fb_xrgb8888_to_mono_reversed()
Hello Geert,
Thanks for your patch.
On 3/15/22 12:07, Geert Uytterhoeven wrote:
> There is no "reversed" handling in drm_fb_xrgb_to_mono_reversed():
> the function just converts from color to grayscale, and reduces the
> number of grayscale levels from 256 to 2 (i.e. brightness 0-127 is
> mapped to 0, 128-255 to 1). All "reversed" handling is done in the
> repaper driver, where this function originated.
>
> Hence make this clear by renaming drm_fb_xrgb_to_mono_reversed() to
> drm_fb_xrgb_to_mono(), and documenting the black/white pixel
> mapping.
>
> Fixes: bcf8b616deb87941 ("drm/format-helper: Add
> drm_fb_xrgb_to_mono_reversed()")
> Signed-off-by: Geert Uytterhoeven
> ---
As you mentioned the function originally came from the repaper driver
(that uses white-on-black) and I wrongly assumed that the destination
buffer for the OLED panels were also monochrome reversed.
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [PATCH v4 00/24] DEPT(Dependency Tracker)
On Mon, Mar 14, 2022 at 03:59:06PM +0900, Byungchul Park wrote: > On Sat, Mar 12, 2022 at 01:53:26AM +, Hyeonggon Yoo wrote: > > On Fri, Mar 04, 2022 at 04:06:19PM +0900, Byungchul Park wrote: > > > Hi Linus and folks, > > > > > > I've been developing a tool for detecting deadlock possibilities by > > > tracking wait/event rather than lock(?) acquisition order to try to > > > cover all synchonization machanisms. It's done on v5.17-rc1 tag. > > > > > > https://github.com/lgebyungchulpark/linux-dept/commits/dept1.14_on_v5.17-rc1 > > > > > > > Small feedback unrelated to thread: > > I'm not sure "Need to expand the ring buffer" is something to call > > WARN(). Is this stack trace useful for something? > > Yeah. It seems to happen too often. I won't warn it. Thanks. Thanks! > > > > > > Hello Byungchul. These are two warnings of DEPT on system. > > Both cases look similar. > > > > In what case DEPT says (unknown)? > > I'm not sure we can properly debug this. > > > > === > > DEPT: Circular dependency has been detected. > > 5.17.0-rc1+ #3 Tainted: GW > > --- > > summary > > --- > > *** AA DEADLOCK *** > > > > context A > > [S] (unknown)(&vfork:0) > > [W] wait_for_completion_killable(&vfork:0) > > [E] complete(&vfork:0) > > All the reports look like having to do with kernel_clone(). I need to > check it more. Thank you very much. > > You are awesome, Hyeonggon. > Thank you. Let me know if there is something I can help! > Thank you, > Byungchul > > > [S]: start of the event context > > [W]: the wait blocked > > [E]: the event not reachable > > --- > > context A's detail > > --- > > context A > > [S] (unknown)(&vfork:0) > > [W] wait_for_completion_killable(&vfork:0) > > [E] complete(&vfork:0) > > > > [S] (unknown)(&vfork:0): > > (N/A) > > > > [W] wait_for_completion_killable(&vfork:0): > > [] kernel_clone+0x25c/0x2b8 > > stacktrace: > > dept_wait+0x74/0x88 > > wait_for_completion_killable+0x60/0xa0 > > kernel_clone+0x25c/0x2b8 > > __do_sys_clone+0x5c/0x74 > > __arm64_sys_clone+0x18/0x20 > > invoke_syscall.constprop.0+0x78/0xc4 > > do_el0_svc+0x98/0xd0 > > el0_svc+0x44/0xe4 > > el0t_64_sync_handler+0xb0/0x12c > > el0t_64_sync+0x158/0x15c > > > > [E] complete(&vfork:0): > > [] mm_release+0x7c/0x90 > > stacktrace: > > dept_event+0xe0/0x100 > > complete+0x48/0x98 > > mm_release+0x7c/0x90 > > exit_mm_release+0xc/0x14 > > do_exit+0x1b4/0x81c > > do_group_exit+0x30/0x9c > > __wake_up_parent+0x0/0x24 > > invoke_syscall.constprop.0+0x78/0xc4 > > do_el0_svc+0x98/0xd0 > > el0_svc+0x44/0xe4 > > el0t_64_sync_handler+0xb0/0x12c > > el0t_64_sync+0x158/0x15c > > --- > > information that might be helpful > > --- > > CPU: 6 PID: 229 Comm: start-stop-daem Tainted: GW > > 5.17.0-rc1+ #3 > > Hardware name: linux,dummy-virt (DT) > > Call trace: > > dump_backtrace.part.0+0x9c/0xc4 > > show_stack+0x14/0x28 > > dump_stack_lvl+0x9c/0xcc > > dump_stack+0x14/0x2c > > print_circle+0x2d4/0x438 > > cb_check_dl+0x44/0x70 > > bfs+0x60/0x168 > > add_dep+0x88/0x11c > > do_event.constprop.0+0x19c/0x2c0 > > dept_event+0xe0/0x100 > > complete+0x48/0x98 > > mm_release+0x7c/0x90 > > exit_mm_release+0xc/0x14 > > do_exit+0x1b4/0x81c > > do_group_exit+0x30/0x9c > > __wake_up_parent+0x0/0x24 > > invoke_syscall.constprop.0+0x78/0xc4 > > do_el0_svc+0x98/0xd0 > > el0_svc+0x44/0xe4 > > el0t_64_sync_handler+0xb0/0x12c > > el0t_64_sync+0x158/0x15c > > > > > > > > > > === > > DEPT: Circular dependency has been detected. > > 5.17.0-rc1+ #3 Tainted: GW > > --- > > summary > > --- > > *** AA DEADLOCK *** > > > > context A > > [S] (unknown)(&try_completion:0) > > [W] wait_for_completion_timeout(&try_completion:0) > > [E] complete(&try_completion:0) > > > > [S]: start of the event context > > [W]: the wait blocked > > [E]: the event not reachable > > --- > > context A's detail > > --- > > context A > > [S] (unknown)(&try_completion:0) > > [W] wait_for_completion_timeout(&try_completion:0) > > [E] complete(&try_completion:0) > > > > [S] (unknown)(&try_completion:0): > > (N/A) > > > > [W] wait_for_completion_timeout(&try_completion:0): > > [] kunit_try_catch_run+0xb4/0x160 > > stacktrace: > > dept_wait+0x74/0x88 > >
Re: [PATCH 2/5] drm/format-helper: Fix XRGB888 to monochrome conversion
On 3/15/22 12:07, Geert Uytterhoeven wrote:
> The conversion functions drm_fb_xrgb_to_mono() and
> drm_fb_gray8_to_mono_line() do not behave correctly when the
> horizontal boundaries of the clip rectangle are not multiples of 8:
> a. When x1 % 8 != 0, the calculated pitch is not correct,
> b. When x2 % 8 != 0, the pixel data for the last byte is wrong.
>
Thanks a lot for tracking down and fixing these issues.
> Simplify the code and fix (a) by:
> 1. Removing start_offset, and always storing the first pixel in the
> first bit of the monochrome destination buffer.
> Drivers that require the first pixel in a byte to be located at an
> x-coordinate that is a multiple of 8 can always align the clip
> rectangle before calling drm_fb_xrgb_to_mono().
> Note that:
>- The ssd130x driver does not need the alignment, as the
>monochrome buffer is a temporary format,
>- The repaper driver always updates the full screen, so the clip
>rectangle is always aligned.
> 2. Passing the number of pixels to drm_fb_gray8_to_mono_line(),
> instead of the number of bytes, and the number of pixels in the
> last byte.
>
> Fix (b) by explicitly setting the target bit, instead of always setting
> bit 7 and shifting the value in each loop iteration.
>
> Remove the bogus pitch check, which operates on bytes instead of pixels,
> and triggers when e.g. flashing the cursor on a text console with a font
> that is 8 pixels wide.
>
> Drop the confusing comment about scanlines, as a pitch in bytes always
> contains a multiple of 8 pixels.
>
> While at it, use the drm_rect_height() helper instead of open-coding the
> same operation.
>
> Update the comments accordingly.
>
> Fixes: bcf8b616deb87941 ("drm/format-helper: Add
> drm_fb_xrgb_to_mono_reversed()")
> Signed-off-by: Geert Uytterhoeven
> ---
Acked-by: Javier Martinez Canillas
I just have a small comment below.
[snip]
> +static void drm_fb_gray8_to_mono_line(u8 *dst, const u8 *src, unsigned int
> pixels)
> +{
> + while (pixels) {
> + unsigned int i, bits = min(pixels, 8U);
> + u8 byte = 0;
>
> - byte >>= 1;
> - if (src[x] >> 7)
> - byte |= BIT(7);
> + for (i = 0; i < bits; i++, pixels--) {
I think is worth to add a comment here explaining that the pixel is set to
1 for brightness > 127 and to 0 for brightness < 128. Or as kernel-doc for
this helper function.
> + if (*src++ & BIT(7))
Pekka also mentioned that if (*src++ > 127) would make this easier to read.
> + byte |= BIT(i);
> }
> *dst++ = byte;
> }
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [PATCH 3/5] drm: ssd130x: Fix rectangle updates
On 3/15/22 12:07, Geert Uytterhoeven wrote:
> The rectangle update functions ssd130x_fb_blit_rect() and
> ssd130x_update_rect() do not behave correctly when x1 != 0 or y1 !=
> 0, or when y1 or y2 are not aligned to display page boundaries.
> E.g. when used as a text console, only the first line of text is shown
> on the display.
>
> 1. The buffer passed by ssd130x_fb_blit_rect() points to the first
> byte of monochrome bitmap data, and thus has its origin at (x1,
> y1), while ssd130x_update_rect() assumes it is at (0, 0).
> Fix ssd130x_update_rect() by changing the vertical and horizontal
> loop ranges, and adding the offsets only when needed.
>
> 2. In ssd130x_fb_blit_rect(), align y1 and y2 to the display page
> boundaries before doing the color conversion, so the full page
> is converted and updated.
> Remove the correction for an unaligned y1 from
> ssd130x_update_rect(), and add a check to make sure y1 is aligned.
>
> Fixes: a61732e808672cfa ("drm: Add driver for Solomon SSD130x OLED displays")
> Signed-off-by: Geert Uytterhoeven
> ---
Thanks for fixing this too.
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [PATCH 4/5] drm: ssd130x: Reduce temporary buffer sizes
On 3/15/22 12:07, Geert Uytterhoeven wrote:
> ssd130x_clear_screen() allocates a temporary buffer sized to hold one
> byte per pixel, while it only needs to hold one bit per pixel.
>
> ssd130x_fb_blit_rect() allocates a temporary buffer sized to hold one
> byte per pixel for the whole frame buffer, while it only needs to hold
> one bit per pixel for the part that is to be updated.
> Pass dst_pitch to drm_fb_xrgb_to_mono_reversed(), as we have already
Just drm_fb_xrgb_to_mono() since you already fixed the name in patch 1/5.
> calculated it anyway.
>
> Fixes: a61732e808672cfa ("drm: Add driver for Solomon SSD130x OLED displays")
> Signed-off-by: Geert Uytterhoeven
> ---
Indeed. I haven't noticed that got the calculation wrong until you pointed out.
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [v7 1/5] drm/edid: seek for available CEA and DisplayID block from specific EDID block index
On Mon, 14 Mar 2022, Drew Davenport wrote:
> On Mon, Mar 14, 2022 at 10:40:47AM +0200, Jani Nikula wrote:
>> On Sun, 13 Mar 2022, Lee Shawn C wrote:
>> > drm_find_cea_extension() always look for a top level CEA block. Pass
>> > ext_index from caller then this function to search next available
>> > CEA ext block from a specific EDID block pointer.
>> >
>> > v2: save proper extension block index if CTA data information
>> > was found in DispalyID block.
>> > v3: using different parameters to store CEA and DisplayID block index.
>> > configure DisplayID extansion block index before search available
>> > DisplayID block.
>> >
>> > Cc: Jani Nikula
>> > Cc: Ville Syrjala
>> > Cc: Ankit Nautiyal
>> > Cc: Drew Davenport
>> > Cc: intel-gfx
>> > Signed-off-by: Lee Shawn C
>> > ---
>> > drivers/gpu/drm/drm_displayid.c | 10 +--
>> > drivers/gpu/drm/drm_edid.c | 53 ++---
>> > include/drm/drm_displayid.h | 4 +--
>> > 3 files changed, 39 insertions(+), 28 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_displayid.c
>> > b/drivers/gpu/drm/drm_displayid.c
>> > index 32da557b960f..31c3e6d7d549 100644
>> > --- a/drivers/gpu/drm/drm_displayid.c
>> > +++ b/drivers/gpu/drm/drm_displayid.c
>> > @@ -59,11 +59,14 @@ static const u8 *drm_find_displayid_extension(const
>> > struct edid *edid,
>> > }
>> >
>> > void displayid_iter_edid_begin(const struct edid *edid,
>> > - struct displayid_iter *iter)
>> > + struct displayid_iter *iter, int *ext_index)
>>
>> Please don't do this. This just ruins the clean approach displayid
>> iterator added.
>>
>> Instead of making the displayid iterator ugly, and leaking its
>> abstractions, I'll repeat what I said should be done in reply to the
>> very first version of this patch series [1]:
>>
>> "I think we're going to need abstracted EDID iteration similar to what
>> I've done for DisplayID iteration. We can't have all places
>> reimplementing the iteration like we have now."
>>
>> This isn't a problem that should be solved by having all the callers
>> hold a bunch of local variables and pass them around to all the
>> functions. Nobody's going to be able to keep track of this anymore. And
>> this series, as it is, makes it harder to fix this properly later on.
>
> I missed your original review comment, so apologies for repeating what you
> said there already.
>
> I'd agree that passing a starting index to the displayid_iter_*
> functions is probably not the right direction here. More thoughts below.
>
>>
>>
>> BR,
>> Jani.
>>
>>
>> [1] https://lore.kernel.org/r/87czjf8dik@intel.com
>>
>>
>>
>> > {
>> >memset(iter, 0, sizeof(*iter));
>> >
>> >iter->edid = edid;
>> > +
>> > + if (ext_index)
>> > + iter->ext_index = *ext_index;
>> > }
>> >
>> > static const struct displayid_block *
>> > @@ -126,7 +129,10 @@ __displayid_iter_next(struct displayid_iter *iter)
>> >}
>> > }
>> >
>> > -void displayid_iter_end(struct displayid_iter *iter)
>> > +void displayid_iter_end(struct displayid_iter *iter, int *ext_index)
>> > {
>> > + if (ext_index)
>> > + *ext_index = iter->ext_index;
>> > +
>> >memset(iter, 0, sizeof(*iter));
>> > }
>> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> > index 561f53831e29..78c415aa6889 100644
>> > --- a/drivers/gpu/drm/drm_edid.c
>> > +++ b/drivers/gpu/drm/drm_edid.c
>> > @@ -3353,28 +3353,27 @@ const u8 *drm_find_edid_extension(const struct
>> > edid *edid,
>> >return edid_ext;
>> > }
>> >
>> > -static const u8 *drm_find_cea_extension(const struct edid *edid)
>> > +static const u8 *drm_find_cea_extension(const struct edid *edid,
>> > + int *cea_ext_index, int
>> > *displayid_ext_index)
>
> As discussed above, passing both indices into this function may not be
> the best approach here. But I think we need to keep track of some kind
> of state in order to know which was the last CEA block that was
> returned, and thus this function can return the next one after that,
> whether it's in the CEA extension block or DisplayID block.
Per DisplayID v1.3 Appendix B: DisplayID as an EDID Extension, it's
recommended that DisplayID extensions are exposed after all of the CEA
extensions.
I think it should be fine to first iterate over all CEA extensions
across the EDID, followed by iterating over all the DisplayID
extensions. No need to keep track of the order between CEA and
DisplayID, as the former should precede the latter.
> What do you think of using the pointer returned from this function as
> that state? The caller could pass in a u8* that was returned from a
> previous call. This function would iterate through the extension blocks
> and skip the CEA blocks it finds until it finds the passed in pointer,
> and then return the next one after (or NULL).
>
> An alternative might be to create a linked list of ptrs to the edid
> extens
Re: [PATCH 5/5] drm/repaper: Reduce temporary buffer size in repaper_fb_dirty()
On 3/15/22 12:07, Geert Uytterhoeven wrote:
> As the temporary buffer is no longer used to store 8-bit grayscale data,
> its size can be reduced to the size needed to store the monochrome
> bitmap data.
>
> Fixes: 24c6bedefbe71de9 ("drm/repaper: Use format helper for xrgb to
> monochrome conversion")
> Signed-off-by: Geert Uytterhoeven
> ---
> Untested due to lack of hardware.
>
Patch looks good to me but I also don't have this hardware.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [PATCH v8 22/24] drm: rockchip: Add VOP2 driver
Hi Andy, On Tue, 15 Mar 2022 at 06:46, Andy Yan wrote: > On 3/11/22 16:33, Sascha Hauer wrote: > > The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB > > board. Overlay support is tested with the modetest utility. AFBC support > > on the cluster windows is tested with weston-simple-dmabuf-egl on > > weston using the (yet to be upstreamed) panfrost driver support. > > Do we need some modification to test AFBC by weston-simple-dma-egl ? > > I have a buildroot system with weston-10.0.9 and mesa 21.3.5. > > After launch weston, I run weston-simple-dmabuf-egl, but from the output > > of sys/kernel/debug/dri/0/state, the weston is still use Smart0-win0, > which is > > a non-AFBC window. > > Do i need to modify the vop2 driver to set one Cluster window as primary > plane? Are you using the open-source Panfrost driver, or the proprietary Arm DDK? The DDK was previously using some non-standard modifier tokens which have since been corrected upstream. You can see from running `weston-debug drm-backend` (if you start Weston with `--debug`) the output as it tries to put client surfaces on to overlay planes, and why it can or cannot. For Weston's own composited output (used when it cannot place client surfaces on to planes), it will just use whatever the KMS driver declares as the primary plane. Weston does not have any logic to say 'oh, this plane is AFBC and AFBC is better, so I will use this as my primary plane': we just follow what the kernel tells us. Cheers, Daniel
Re: [PATCH v2 7/8] drm/virtio: Support memory shrinking
Greetings everyone,
Food for thought: Would it make sense to have the madvise ioctl as
generic DRM one?
Looking around - i915, msm & panfrost already have one and the virtio
implementation [below] seems as generic as it gets.
On Mon, 14 Mar 2022 at 22:44, Dmitry Osipenko
wrote:
> +#define VIRTGPU_MADV_WILLNEED 0
> +#define VIRTGPU_MADV_DONTNEED 1
> +struct drm_virtgpu_madvise {
> + __u32 bo_handle;
> + __u32 retained; /* out, non-zero if BO can be used */
> + __u32 madv;
> + __u32 pad;
This seems to be based on panfrost/msm yet names (bo_handle vs
handle), layout and documentation varies.
Why is that - copy/paste is cheap :-P
HTH
-Emil
Re: [PATCH v2 0/8] Add memory shrinker to VirtIO-GPU DRM driver
On Mon, 14 Mar 2022 at 22:44, Dmitry Osipenko wrote: > Dmitry Osipenko (8): > drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling > drm/virtio: Check whether transferred 2D BO is shmem > drm/virtio: Unlock GEM reservations in error code path These three are legitimate fixes that we want regardless of the shrinker. Please add the respective "Fixes" tag, so they find their way in the stable trees. With that, them 3 are: Reviewed-by: Emil Velikov HTH Emil
Re: [PATCH 2/5] drm/format-helper: Fix XRGB888 to monochrome conversion
Hi Javier,
On Tue, Mar 15, 2022 at 1:18 PM Javier Martinez Canillas
wrote:
> On 3/15/22 12:07, Geert Uytterhoeven wrote:
> > The conversion functions drm_fb_xrgb_to_mono() and
> > drm_fb_gray8_to_mono_line() do not behave correctly when the
> > horizontal boundaries of the clip rectangle are not multiples of 8:
> > a. When x1 % 8 != 0, the calculated pitch is not correct,
> > b. When x2 % 8 != 0, the pixel data for the last byte is wrong.
> >
>
> Thanks a lot for tracking down and fixing these issues.
>
> > Simplify the code and fix (a) by:
> > 1. Removing start_offset, and always storing the first pixel in the
> > first bit of the monochrome destination buffer.
> > Drivers that require the first pixel in a byte to be located at an
> > x-coordinate that is a multiple of 8 can always align the clip
> > rectangle before calling drm_fb_xrgb_to_mono().
> > Note that:
> >- The ssd130x driver does not need the alignment, as the
> >monochrome buffer is a temporary format,
> >- The repaper driver always updates the full screen, so the clip
> >rectangle is always aligned.
> > 2. Passing the number of pixels to drm_fb_gray8_to_mono_line(),
> > instead of the number of bytes, and the number of pixels in the
> > last byte.
> >
> > Fix (b) by explicitly setting the target bit, instead of always setting
> > bit 7 and shifting the value in each loop iteration.
> >
> > Remove the bogus pitch check, which operates on bytes instead of pixels,
> > and triggers when e.g. flashing the cursor on a text console with a font
> > that is 8 pixels wide.
> >
> > Drop the confusing comment about scanlines, as a pitch in bytes always
> > contains a multiple of 8 pixels.
> >
> > While at it, use the drm_rect_height() helper instead of open-coding the
> > same operation.
> >
> > Update the comments accordingly.
> >
> > Fixes: bcf8b616deb87941 ("drm/format-helper: Add
> > drm_fb_xrgb_to_mono_reversed()")
> > Signed-off-by: Geert Uytterhoeven
> > ---
>
> Acked-by: Javier Martinez Canillas
Thanks!
> I just have a small comment below.
>
> [snip]
>
> > +static void drm_fb_gray8_to_mono_line(u8 *dst, const u8 *src, unsigned int
> > pixels)
> > +{
> > + while (pixels) {
> > + unsigned int i, bits = min(pixels, 8U);
> > + u8 byte = 0;
> >
> > - byte >>= 1;
> > - if (src[x] >> 7)
> > - byte |= BIT(7);
> > + for (i = 0; i < bits; i++, pixels--) {
>
> I think is worth to add a comment here explaining that the pixel is set to
> 1 for brightness > 127 and to 0 for brightness < 128. Or as kernel-doc for
> this helper function.
>
> > + if (*src++ & BIT(7))
>
> Pekka also mentioned that if (*src++ > 127) would make this easier to read.
Sure, will update. Nicely removes the need for a comment.
> > + byte |= BIT(i);
> > }
> > *dst++ = byte;
> > }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 4/5] drm: ssd130x: Reduce temporary buffer sizes
Hi Javier,
On Tue, Mar 15, 2022 at 1:32 PM Javier Martinez Canillas
wrote:
> On 3/15/22 12:07, Geert Uytterhoeven wrote:
> > ssd130x_clear_screen() allocates a temporary buffer sized to hold one
> > byte per pixel, while it only needs to hold one bit per pixel.
> >
> > ssd130x_fb_blit_rect() allocates a temporary buffer sized to hold one
> > byte per pixel for the whole frame buffer, while it only needs to hold
> > one bit per pixel for the part that is to be updated.
> > Pass dst_pitch to drm_fb_xrgb_to_mono_reversed(), as we have already
>
> Just drm_fb_xrgb_to_mono() since you already fixed the name in patch 1/5.
Bummer, that happens when reshuffling patches :-(
Fixed for v2.
> > calculated it anyway.
> >
> > Fixes: a61732e808672cfa ("drm: Add driver for Solomon SSD130x OLED
> > displays")
> > Signed-off-by: Geert Uytterhoeven
> > ---
>
> Indeed. I haven't noticed that got the calculation wrong until you pointed
> out.
>
> Acked-by: Javier Martinez Canillas
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/8] drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling
On 3/15/22 01:42, Dmitry Osipenko wrote:
> drm_gem_shmem_get_sg_table() never ever returned NULL on error. Correct
> the error handling to avoid crash on OOM.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/virtio/virtgpu_object.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> b/drivers/gpu/drm/virtio/virtgpu_object.c
> index f293e6ad52da..bea7806a3ae3 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -168,9 +168,11 @@ static int virtio_gpu_object_shmem_init(struct
> virtio_gpu_device *vgdev,
>* since virtio_gpu doesn't support dma-buf import from other devices.
>*/
> shmem->pages = drm_gem_shmem_get_sg_table(&bo->base);
> - if (!shmem->pages) {
> + ret = PTR_ERR(shmem->pages);
This actually needs to be PTR_ERR_OR_ZERO. This code is changed to use
drm_gem_shmem_get_pages_sgt()+IS_ERR() by the further patch, so I just
missed the typo previously. I'll correct it in v3.
Re: [PATCH v2 0/8] Add memory shrinker to VirtIO-GPU DRM driver
On 3/15/22 15:47, Emil Velikov wrote: > On Mon, 14 Mar 2022 at 22:44, Dmitry Osipenko > wrote: > >> Dmitry Osipenko (8): >> drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling >> drm/virtio: Check whether transferred 2D BO is shmem >> drm/virtio: Unlock GEM reservations in error code path > > These three are legitimate fixes that we want regardless of the shrinker. > > Please add the respective "Fixes" tag, so they find their way in the > stable trees. With that, them 3 are: > Reviewed-by: Emil Velikov Thank you, I already added stable tag to the first patch. The other patches aren't critical for the stable kernels, IMO, but we can tag them too for completeness. I'll do in v3.
Re: [PATCH 1/5] drm/format-helper: Rename drm_fb_xrgb8888_to_mono_reversed()
On Tue, Mar 15, 2022 at 12:07:03PM +0100, Geert Uytterhoeven wrote:
> There is no "reversed" handling in drm_fb_xrgb_to_mono_reversed():
> the function just converts from color to grayscale, and reduces the
> number of grayscale levels from 256 to 2 (i.e. brightness 0-127 is
> mapped to 0, 128-255 to 1). All "reversed" handling is done in the
> repaper driver, where this function originated.
>
> Hence make this clear by renaming drm_fb_xrgb_to_mono_reversed() to
> drm_fb_xrgb_to_mono(), and documenting the black/white pixel
> mapping.
W/ or w/o the below remark being addressed
Reviewed-by: Andy Shevchenko
> Fixes: bcf8b616deb87941 ("drm/format-helper: Add
> drm_fb_xrgb_to_mono_reversed()")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/gpu/drm/drm_format_helper.c | 32 ++---
> drivers/gpu/drm/solomon/ssd130x.c | 2 +-
> drivers/gpu/drm/tiny/repaper.c | 2 +-
> include/drm/drm_format_helper.h | 5 ++---
> 4 files changed, 20 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index bc0f49773868a9b0..b68aa857c6514529 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -594,8 +594,8 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int
> dst_pitch, uint32_t dst_for
> }
> EXPORT_SYMBOL(drm_fb_blit_toio);
>
> -static void drm_fb_gray8_to_mono_reversed_line(u8 *dst, const u8 *src,
> unsigned int pixels,
> -unsigned int start_offset,
> unsigned int end_len)
> +static void drm_fb_gray8_to_mono_line(u8 *dst, const u8 *src, unsigned int
> pixels,
> + unsigned int start_offset, unsigned int
> end_len)
> {
> unsigned int xb, i;
>
> @@ -621,8 +621,8 @@ static void drm_fb_gray8_to_mono_reversed_line(u8 *dst,
> const u8 *src, unsigned
> }
>
> /**
> - * drm_fb_xrgb_to_mono_reversed - Convert XRGB to reversed monochrome
> - * @dst: reversed monochrome destination buffer
> + * drm_fb_xrgb_to_mono - Convert XRGB to monochrome
> + * @dst: monochrome destination buffer (0=black, 1=white)
> * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> * @src: XRGB source buffer
> * @fb: DRM framebuffer
> @@ -633,10 +633,10 @@ static void drm_fb_gray8_to_mono_reversed_line(u8 *dst,
> const u8 *src, unsigned
> * and use this function to convert to the native format.
> *
> * This function uses drm_fb_xrgb_to_gray8() to convert to grayscale and
> - * then the result is converted from grayscale to reversed monohrome.
> + * then the result is converted from grayscale to monochrome.
> */
> -void drm_fb_xrgb_to_mono_reversed(void *dst, unsigned int dst_pitch,
> const void *vaddr,
> - const struct drm_framebuffer *fb, const
> struct drm_rect *clip)
> +void drm_fb_xrgb_to_mono(void *dst, unsigned int dst_pitch, const void
> *vaddr,
> + const struct drm_framebuffer *fb, const struct
> drm_rect *clip)
> {
> unsigned int linepixels = drm_rect_width(clip);
> unsigned int lines = clip->y2 - clip->y1;
> @@ -652,8 +652,8 @@ void drm_fb_xrgb_to_mono_reversed(void *dst, unsigned
> int dst_pitch, const v
> return;
>
> /*
> - * The reversed mono destination buffer contains 1 bit per pixel
> - * and destination scanlines have to be in multiple of 8 pixels.
> + * The mono destination buffer contains 1 bit per pixel and
> + * destination scanlines have to be in multiple of 8 pixels.
>*/
> if (!dst_pitch)
> dst_pitch = DIV_ROUND_UP(linepixels, 8);
> @@ -664,9 +664,9 @@ void drm_fb_xrgb_to_mono_reversed(void *dst, unsigned
> int dst_pitch, const v
>* The cma memory is write-combined so reads are uncached.
>* Speed up by fetching one line at a time.
>*
> - * Also, format conversion from XR24 to reversed monochrome
> - * are done line-by-line but are converted to 8-bit grayscale
> - * as an intermediate step.
> + * Also, format conversion from XR24 to monochrome are done
> + * line-by-line but are converted to 8-bit grayscale as an
> + * intermediate step.
>*
>* Allocate a buffer to be used for both copying from the cma
>* memory and to store the intermediate grayscale line pixels.
> @@ -683,7 +683,7 @@ void drm_fb_xrgb_to_mono_reversed(void *dst, unsigned
> int dst_pitch, const v
>* are not aligned to multiple of 8.
>*
>* Calculate if the start and end pixels are not aligned and set the
> - * offsets for the reversed mono line conversion function to adjust.
> + * offsets for the mono line conversion function to adjust.
>*/
> start_offset = clip->x1 % 8;
> end_len = clip->x2 % 8;
> @@ -692,12 +692,12 @@ void drm_fb_xrg
Re: [PATCH 1/5] drm/format-helper: Rename drm_fb_xrgb8888_to_mono_reversed()
Hi Andy,
On Tue, Mar 15, 2022 at 2:33 PM Andy Shevchenko
wrote:
> On Tue, Mar 15, 2022 at 12:07:03PM +0100, Geert Uytterhoeven wrote:
> > There is no "reversed" handling in drm_fb_xrgb_to_mono_reversed():
> > the function just converts from color to grayscale, and reduces the
> > number of grayscale levels from 256 to 2 (i.e. brightness 0-127 is
> > mapped to 0, 128-255 to 1). All "reversed" handling is done in the
> > repaper driver, where this function originated.
> >
> > Hence make this clear by renaming drm_fb_xrgb_to_mono_reversed() to
> > drm_fb_xrgb_to_mono(), and documenting the black/white pixel
> > mapping.
>
> W/ or w/o the below remark being addressed
> Reviewed-by: Andy Shevchenko
Thanks!
> > --- a/drivers/gpu/drm/drm_format_helper.c
> > +++ b/drivers/gpu/drm/drm_format_helper.c
> > @@ -692,12 +692,12 @@ void drm_fb_xrgb_to_mono_reversed(void *dst,
> > unsigned int dst_pitch, const v
> > for (y = 0; y < lines; y++) {
> > src32 = memcpy(src32, vaddr, len_src32);
> > drm_fb_xrgb_to_gray8_line(gray8, src32, linepixels);
> > - drm_fb_gray8_to_mono_reversed_line(mono, gray8, dst_pitch,
> > -start_offset, end_len);
>
> > + drm_fb_gray8_to_mono_line(mono, gray8, dst_pitch,
> > start_offset,
> > + end_len);
>
> Can be one line now (definition is already quite behind 80 limit).
Yeah, but the code isn't.
Nevertheless, this will be shortened in a later patch.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/5] drm/format-helper: Fix XRGB888 to monochrome conversion
On Tue, Mar 15, 2022 at 12:07:04PM +0100, Geert Uytterhoeven wrote:
> The conversion functions drm_fb_xrgb_to_mono() and
> drm_fb_gray8_to_mono_line() do not behave correctly when the
> horizontal boundaries of the clip rectangle are not multiples of 8:
> a. When x1 % 8 != 0, the calculated pitch is not correct,
> b. When x2 % 8 != 0, the pixel data for the last byte is wrong.
>
> Simplify the code and fix (a) by:
> 1. Removing start_offset, and always storing the first pixel in the
> first bit of the monochrome destination buffer.
> Drivers that require the first pixel in a byte to be located at an
> x-coordinate that is a multiple of 8 can always align the clip
> rectangle before calling drm_fb_xrgb_to_mono().
> Note that:
>- The ssd130x driver does not need the alignment, as the
>monochrome buffer is a temporary format,
>- The repaper driver always updates the full screen, so the clip
>rectangle is always aligned.
> 2. Passing the number of pixels to drm_fb_gray8_to_mono_line(),
> instead of the number of bytes, and the number of pixels in the
> last byte.
>
> Fix (b) by explicitly setting the target bit, instead of always setting
> bit 7 and shifting the value in each loop iteration.
>
> Remove the bogus pitch check, which operates on bytes instead of pixels,
> and triggers when e.g. flashing the cursor on a text console with a font
> that is 8 pixels wide.
>
> Drop the confusing comment about scanlines, as a pitch in bytes always
> contains a multiple of 8 pixels.
>
> While at it, use the drm_rect_height() helper instead of open-coding the
> same operation.
>
> Update the comments accordingly.
Reviewed-by: Andy Shevchenko
See comment below.
> Fixes: bcf8b616deb87941 ("drm/format-helper: Add
> drm_fb_xrgb_to_mono_reversed()")
> Signed-off-by: Geert Uytterhoeven
> ---
> I tried hard to fix this in small steps, but everything was no
> intertangled that this turned out to be unfeasible.
>
> Note that making these changes does not introduce regressions in the
> ssd130x driver, as the latter is broken for x1 != 0 or y1 != 0 anyway.
> ---
> drivers/gpu/drm/drm_format_helper.c | 56 ++---
> 1 file changed, 18 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index b68aa857c6514529..0d7cae921ed1134f 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -594,27 +594,16 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int
> dst_pitch, uint32_t dst_for
> }
> EXPORT_SYMBOL(drm_fb_blit_toio);
>
> -static void drm_fb_gray8_to_mono_line(u8 *dst, const u8 *src, unsigned int
> pixels,
> - unsigned int start_offset, unsigned int
> end_len)
> -{
> - unsigned int xb, i;
> -
> - for (xb = 0; xb < pixels; xb++) {
> - unsigned int start = 0, end = 8;
> - u8 byte = 0x00;
> -
> - if (xb == 0 && start_offset)
> - start = start_offset;
>
> - if (xb == pixels - 1 && end_len)
> - end = end_len;
> -
> - for (i = start; i < end; i++) {
> - unsigned int x = xb * 8 + i;
> +static void drm_fb_gray8_to_mono_line(u8 *dst, const u8 *src, unsigned int
> pixels)
> +{
> + while (pixels) {
> + unsigned int i, bits = min(pixels, 8U);
> + u8 byte = 0;
>
> - byte >>= 1;
> - if (src[x] >> 7)
> - byte |= BIT(7);
> + for (i = 0; i < bits; i++, pixels--) {
> + if (*src++ & BIT(7))
> + byte |= BIT(i);
> }
> *dst++ = byte;
> }
> @@ -634,16 +623,22 @@ static void drm_fb_gray8_to_mono_line(u8 *dst, const u8
> *src, unsigned int pixel
> *
> * This function uses drm_fb_xrgb_to_gray8() to convert to grayscale and
> * then the result is converted from grayscale to monochrome.
> + *
> + * The first pixel (upper left corner of the clip rectangle) will be
> converted
> + * and copied to the first bit (LSB) in the first byte of the monochrome
> + * destination buffer.
> + * If the caller requires that the first pixel in a byte must be located at
> an
> + * x-coordinate that is a multiple of 8, then the caller must take care
> itself
> + * of supplying a suitable clip rectangle.
> */
> void drm_fb_xrgb_to_mono(void *dst, unsigned int dst_pitch, const void
> *vaddr,
>const struct drm_framebuffer *fb, const struct
> drm_rect *clip)
> {
> unsigned int linepixels = drm_rect_width(clip);
> - unsigned int lines = clip->y2 - clip->y1;
> + unsigned int lines = drm_rect_height(clip);
> unsigned int cpp = fb->format->cpp[0];
> unsigned int len_src32 = linepixels * cpp;
> struct drm_dev
Re: [PATCH 2/5] drm/format-helper: Fix XRGB888 to monochrome conversion
On Tue, Mar 15, 2022 at 01:18:00PM +0100, Javier Martinez Canillas wrote:
> On 3/15/22 12:07, Geert Uytterhoeven wrote:
> > + for (i = 0; i < bits; i++, pixels--) {
>
> I think is worth to add a comment here explaining that the pixel is set to
> 1 for brightness > 127 and to 0 for brightness < 128. Or as kernel-doc for
> this helper function.
>
> > + if (*src++ & BIT(7))
>
> Pekka also mentioned that if (*src++ > 127) would make this easier to read.
>= 128 ?
> > + byte |= BIT(i);
> > }
> > *dst++ = byte;
> > }
--
With Best Regards,
Andy Shevchenko
Re: (subset) [PATCH 00/30] fix typos in comments
On Mon, 14 Mar 2022 12:53:24 +0100, Julia Lawall wrote: > Various spelling mistakes in comments. > Detected with the help of Coccinelle. > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [21/30] spi: sun4i: fix typos in comments commit: 2002c13243d595e211c0dad6b8e2e87f906f474b All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
RE: [v7 3/5] drm/edid: read HF-EEODB ext block
On Tuesday, March 15, 2022 7:03 PM, Nikula, Jani wrote:
>On Sun, 13 Mar 2022, Lee Shawn C wrote:
>> According to HDMI 2.1 spec.
>>
>> "The HDMI Forum EDID Extension Override Data Block (HF-EEODB) is
>> utilized by Sink Devices to provide an alternate method to indicate an
>> EDID Extension Block count larger than 1, while avoiding the need to
>> present a VESA Block Map in the first E-EDID Extension Block."
>>
>> It is a mandatory for HDMI 2.1 protocol compliance as well.
>> This patch help to know how many HF_EEODB blocks report by sink and
>> read allo HF_EEODB blocks back.
>>
>> v2: support to find CEA block, check EEODB block format, and return
>> available block number in drm_edid_read_hf_eeodb_blk_count().
>>
>> Cc: Jani Nikula
>> Cc: Ville Syrjala
>> Cc: Ankit Nautiyal
>> Cc: Drew Davenport
>> Cc: intel-gfx
>> Signed-off-by: Lee Shawn C
>> ---
>> drivers/gpu/drm/drm_connector.c | 8 +++-
>> drivers/gpu/drm/drm_edid.c | 71 +++--
>> include/drm/drm_edid.h | 1 +
>> 3 files changed, 74 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index a50c82bc2b2f..16011023c12e
>> 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -2129,7 +2129,7 @@ int drm_connector_update_edid_property(struct
>> drm_connector *connector,
>> const struct edid *edid)
>> {
>> struct drm_device *dev = connector->dev;
>> -size_t size = 0;
>> +size_t size = 0, hf_eeodb_blk_count;
>> int ret;
>> const struct edid *old_edid;
>>
>> @@ -2137,8 +2137,12 @@ int drm_connector_update_edid_property(struct
>> drm_connector *connector,
>> if (connector->override_edid)
>> return 0;
>>
>> -if (edid)
>> +if (edid) {
>> size = EDID_LENGTH * (1 + edid->extensions);
>> +hf_eeodb_blk_count = drm_edid_read_hf_eeodb_blk_count(edid);
>> +if (hf_eeodb_blk_count)
>> +size = EDID_LENGTH * (1 + hf_eeodb_blk_count);
>
>This approach does not scale. If the number of extensions and thus the total
>EDID size depend on HF-EEODB, this *must* be abstracted.
>
>Consider, for example, drm_edid_duplicate(), which only looks at
>edid->extensions. A subsequent HF-EEODB aware access on an EDID
>duplicated using drm_edid_duplicate() will access beyond the allocated buffer.
>
>Yes, it's a lot of work to introduce drm_edid_size() and
>drm_edid_extension_count() or similar, and use them everywhere, but this is
>what we must do. It's a lot more work to try to take HF-EEODB into account
>everywhere. The latter is going to be riddled with bugs with everyone doing it
>a little different.
>
As you mentioned, we should have new functions to provide proper EDID byte size
or extension counter.
And reuse them to handle/retrieve EDID more accurately in drm driver. Thanks
for your comment!
>> +}
>>
>> /* Set the display info, using edid if available, otherwise
>> * resetting the values to defaults. This duplicates the work diff
>> --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
>> 9fa84881fbba..5ae4e83fa5e3 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -1992,6 +1992,7 @@ struct edid *drm_do_get_edid(struct
>> drm_connector *connector, {
>> int i, j = 0, valid_extensions = 0;
>> u8 *edid, *new;
>> +size_t hf_eeodb_blk_count;
>> struct edid *override;
>>
>> override = drm_get_override_edid(connector); @@ -2051,7 +2052,35 @@
>> struct edid *drm_do_get_edid(struct drm_connector *connector,
>> }
>>
>> kfree(edid);
>> +return (struct edid *)new;
>> +}
>> +
>> +hf_eeodb_blk_count = drm_edid_read_hf_eeodb_blk_count((struct edid
>> *)edid);
>> +if (hf_eeodb_blk_count >= 2) {
>> +new = krealloc(edid, (hf_eeodb_blk_count + 1) * EDID_LENGTH,
>> GFP_KERNEL);
>> +if (!new)
>> +goto out;
>> edid = new;
>> +
>> +valid_extensions = hf_eeodb_blk_count - 1;
>> +for (j = 2; j <= hf_eeodb_blk_count; j++) {
>> +u8 *block = edid + j * EDID_LENGTH;
>> +
>> +for (i = 0; i < 4; i++) {
>> +if (get_edid_block(data, block, j, EDID_LENGTH))
>> +goto out;
>> +if (drm_edid_block_valid(block, j, false, NULL))
>> +break;
>> +}
>> +
>> +if (i == 4)
>> +valid_extensions--;
>> +}
>> +
>> +if (valid_extensions != hf_eeodb_blk_count - 1) {
>> +DRM_ERROR("Not able to retrieve proper EDID contain
>> HF-EEODB data.\n");
>> +goto out;
>> +}
>> }
>>
Re: [PATCH 4/5] drm: ssd130x: Reduce temporary buffer sizes
On Tue, Mar 15, 2022 at 12:07:06PM +0100, Geert Uytterhoeven wrote: > ssd130x_clear_screen() allocates a temporary buffer sized to hold one > byte per pixel, while it only needs to hold one bit per pixel. > > ssd130x_fb_blit_rect() allocates a temporary buffer sized to hold one > byte per pixel for the whole frame buffer, while it only needs to hold > one bit per pixel for the part that is to be updated. > Pass dst_pitch to drm_fb_xrgb_to_mono_reversed(), as we have already > calculated it anyway. Can we use bitmap API? bitmap_zalloc() / etc ? -- With Best Regards, Andy Shevchenko
Re: [PATCH 5/5] drm/repaper: Reduce temporary buffer size in repaper_fb_dirty()
On Tue, Mar 15, 2022 at 12:07:07PM +0100, Geert Uytterhoeven wrote: > As the temporary buffer is no longer used to store 8-bit grayscale data, > its size can be reduced to the size needed to store the monochrome > bitmap data. bitmap API? -- With Best Regards, Andy Shevchenko
Re: [PATCH 4/5] drm: ssd130x: Reduce temporary buffer sizes
Hi Andy,
On Tue, Mar 15, 2022 at 2:50 PM Andy Shevchenko
wrote:
> On Tue, Mar 15, 2022 at 12:07:06PM +0100, Geert Uytterhoeven wrote:
> > ssd130x_clear_screen() allocates a temporary buffer sized to hold one
> > byte per pixel, while it only needs to hold one bit per pixel.
> >
> > ssd130x_fb_blit_rect() allocates a temporary buffer sized to hold one
> > byte per pixel for the whole frame buffer, while it only needs to hold
> > one bit per pixel for the part that is to be updated.
> > Pass dst_pitch to drm_fb_xrgb_to_mono_reversed(), as we have already
> > calculated it anyway.
>
> Can we use bitmap API? bitmap_zalloc() / etc ?
Why? There is no need to operate on an array of longs, only on an
array of bytes. Going to longs would expose us to endianness.
There's also no need to use any of the bitmap operations to modify the data.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Mon, Mar 14, 2022 at 11:26 AM Pekka Paalanen wrote: > > On Mon, 14 Mar 2022 10:23:27 -0400 > Alex Deucher wrote: > > > On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen wrote: > > > > > > On Thu, 10 Mar 2022 11:56:41 -0800 > > > Rob Clark wrote: > > > > > > > For something like just notifying a compositor that a gpu crash > > > > happened, perhaps drm_event is more suitable. See > > > > virtio_gpu_fence_event_create() for an example of adding new event > > > > types. Although maybe you want it to be an event which is not device > > > > specific. This isn't so much of a debugging use-case as simply > > > > notification. > > > > > > Hi, > > > > > > for this particular use case, are we now talking about the display > > > device (KMS) crashing or the rendering device (OpenGL/Vulkan) crashing? > > > > > > If the former, I wasn't aware that display device crashes are a thing. > > > How should a userspace display server react to those? > > > > > > If the latter, don't we have EGL extensions or Vulkan API already to > > > deliver that? > > > > > > The above would be about device crashes that directly affect the > > > display server. Is that the use case in mind here, or is it instead > > > about notifying the display server that some application has caused a > > > driver/hardware crash? If the latter, how should a display server react > > > to that? Disconnect the application? > > > > > > Shashank, what is the actual use case you are developing this for? > > > > > > I've read all the emails here so far, and I don't recall seeing it > > > explained. > > > > > > > The idea is that a support daemon or compositor would listen for GPU > > reset notifications and do something useful with them (kill the guilty > > app, restart the desktop environment, etc.). Today when the GPU > > resets, most applications just continue assuming nothing is wrong, > > meanwhile the GPU has stopped accepting work until the apps re-init > > their context so all of their command submissions just get rejected. > > > > > Btw. somewhat relatedly, there has been work aiming to allow > > > graceful hot-unplug of DRM devices. There is a kernel doc outlining how > > > the various APIs should react towards userspace when a DRM device > > > suddenly disappears. That seems to have some overlap here IMO. > > > > > > See > > > https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#device-hot-unplug > > > which also has a couple pointers to EGL and Vulkan APIs. > > > > The problem is most applications don't use the GL or VK robustness > > APIs. > > Hi, > > how would this new event help with that? This event would provide notification that a GPU reset occurred. > > I mean, yeah, there could be a daemon that kills those GPU users, but > then what? You still lose any unsaved work, and may need to manually > restart them. > > Is the idea that it is better to have the app crash and disappear than > to look like it froze while it otherwise still runs? Yes. The daemon could also send the user some sort of notification that a GPU reset occurred. > > If some daemon or compositor goes killing apps that trigger GPU resets, > then how do we stop that for an app that actually does use the > appropriate EGL or Vulkan APIs to detect and remedy that situation > itself? I guess the daemon could keep some sort of whitelist. OTOH, very few if any applications, especially games actually support these extensions. > > > You could use something like that in the compositor, but those > > APIs tend to be focused more on the application itself rather than the > > GPU in general. E.g., Is my context lost. Which is fine for > > restarting your context, but doesn't really help if you want to try > > and do something with another application (i.e., the likely guilty > > app). Also, on dGPU at least, when you reset the GPU, vram is usually > > lost (either due to the memory controller being reset, or vram being > > zero'd on init due to ECC support), so even if you are not the guilty > > process, in that case you'd need to re-init your context anyway. > > Why should something like a compositor listen for this and kill apps > that triggered GPU resets, instead of e.g. Mesa noticing that in the app > and killing itself? Mesa in the app would know if robustness API is > being used. That's another possibility, but it doesn't handle the case where the compositor doesn't support any sort of robustness extension so if the GPU was reset, you'd lose your desktop anyway even if the app kept running. > > Would be really nice to have the answers to all these questions to be > collected and reiterated in the next version of this proposal. The idea is to provide the notification of a GPU reset. What the various desktop environments or daemons do with it is up to them. I still think there is value in a notification even if you don't kill apps or anything like that. E.g., you can have a daemon running that gets notified and logs the error, collects debug info, sends an em
Re: [Intel-gfx] [PATCH] drm/i915: round_up the size to the alignment value
On 15/03/22 4:56 pm, Matthew Auld wrote:
> On Mon, 14 Mar 2022 at 19:32, Arunpravin
> wrote:
>>
>> handle instances when size is not aligned with the min_page_size.
>> Unigine Heaven has allocation requests for example required pages
>> are 161 and alignment request is 128. To allocate the left over
>> 33 pages, continues the iteration to find the order value which
>> is 5 and 0 and when it compares with min_order = 7, triggers the
>> BUG_ON((order < min_order). To avoid this problem, round_up the
>> size to the alignment and enable the is_contiguous variable and
>> the block trimmed to the original size.
>>
>> Signed-off-by: Arunpravin
>> ---
>> drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 13 +++--
>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
>> b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
>> index 129f668f21ff..318aa731de5b 100644
>> --- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
>> +++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
>> @@ -40,6 +40,7 @@ static int i915_ttm_buddy_man_alloc(struct
>> ttm_resource_manager *man,
>> struct i915_ttm_buddy_resource *bman_res;
>> struct drm_buddy *mm = &bman->mm;
>> unsigned long n_pages, lpfn;
>> + bool is_contiguous = 0;
>> u64 min_page_size;
>> u64 size;
>> int err;
>> @@ -48,6 +49,9 @@ static int i915_ttm_buddy_man_alloc(struct
>> ttm_resource_manager *man,
>> if (!lpfn)
>> lpfn = man->size;
>>
>> + if (place->flags & TTM_PL_FLAG_CONTIGUOUS)
>> + is_contiguous = 1;
>> +
>> bman_res = kzalloc(sizeof(*bman_res), GFP_KERNEL);
>> if (!bman_res)
>> return -ENOMEM;
>> @@ -71,7 +75,12 @@ static int i915_ttm_buddy_man_alloc(struct
>> ttm_resource_manager *man,
>>
>> GEM_BUG_ON(min_page_size < mm->chunk_size);
>>
>> - if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
>> + if (!is_contiguous && !IS_ALIGNED(size, min_page_size)) {
>> + size = round_up(size, min_page_size);
>> + is_contiguous = 1;
>> + }
>> +
>> + if (is_contiguous) {
>
> This looks like it will also do roundup_power_of_two()? I assume we
> instead just want to feed the list_last_entry() block for trimming?
>
> Anway, we should be able to just make this:
>
> if (WARN_ON(!IS_ALIGNED(size, min_page_size))
> return -EINVAL;
>
> That's at least the currently expected behaviour in i915, just that we
> were previously not verifying it here.
ok sure, then I make changes in amdgpu
>
>> unsigned long pages;
>>
>> size = roundup_pow_of_two(size);
>> @@ -106,7 +115,7 @@ static int i915_ttm_buddy_man_alloc(struct
>> ttm_resource_manager *man,
>> if (unlikely(err))
>> goto err_free_blocks;
>>
>> - if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
>> + if (is_contiguous) {
>> u64 original_size = (u64)bman_res->base.num_pages <<
>> PAGE_SHIFT;
>>
>> mutex_lock(&bman->lock);
>>
>> base-commit: b37605de46fef48555bf0cf463cccf355c51fac0
>> --
>> 2.25.1
>>
RE: [v7 1/5] drm/edid: seek for available CEA and DisplayID block from specific EDID block index
On Tuesday, March 15, 2022 8:33 PM, Nikula, Jani wrote:
>On Mon, 14 Mar 2022, Drew Davenport wrote:
>> On Mon, Mar 14, 2022 at 10:40:47AM +0200, Jani Nikula wrote:
>>> On Sun, 13 Mar 2022, Lee Shawn C wrote:
>>> > drm_find_cea_extension() always look for a top level CEA block.
>>> > Pass ext_index from caller then this function to search next
>>> > available CEA ext block from a specific EDID block pointer.
>>> >
>>> > v2: save proper extension block index if CTA data information
>>> > was found in DispalyID block.
>>> > v3: using different parameters to store CEA and DisplayID block index.
>>> > configure DisplayID extansion block index before search available
>>> > DisplayID block.
>>> >
>>> > Cc: Jani Nikula
>>> > Cc: Ville Syrjala
>>> > Cc: Ankit Nautiyal
>>> > Cc: Drew Davenport
>>> > Cc: intel-gfx
>>> > Signed-off-by: Lee Shawn C
>>> > ---
>>> > drivers/gpu/drm/drm_displayid.c | 10 +--
>>> > drivers/gpu/drm/drm_edid.c | 53 ++---
>>> > include/drm/drm_displayid.h | 4 +--
>>> > 3 files changed, 39 insertions(+), 28 deletions(-)
>>> >
>>> > diff --git a/drivers/gpu/drm/drm_displayid.c
>>> > b/drivers/gpu/drm/drm_displayid.c index 32da557b960f..31c3e6d7d549
>>> > 100644
>>> > --- a/drivers/gpu/drm/drm_displayid.c
>>> > +++ b/drivers/gpu/drm/drm_displayid.c
>>> > @@ -59,11 +59,14 @@ static const u8
>>> > *drm_find_displayid_extension(const struct edid *edid, }
>>> >
>>> > void displayid_iter_edid_begin(const struct edid *edid,
>>> > -struct displayid_iter *iter)
>>> > +struct displayid_iter *iter, int *ext_index)
>>>
>>> Please don't do this. This just ruins the clean approach displayid
>>> iterator added.
>>>
>>> Instead of making the displayid iterator ugly, and leaking its
>>> abstractions, I'll repeat what I said should be done in reply to the
>>> very first version of this patch series [1]:
>>>
>>> "I think we're going to need abstracted EDID iteration similar to
>>> what I've done for DisplayID iteration. We can't have all places
>>> reimplementing the iteration like we have now."
>>>
>>> This isn't a problem that should be solved by having all the callers
>>> hold a bunch of local variables and pass them around to all the
>>> functions. Nobody's going to be able to keep track of this anymore.
>>> And this series, as it is, makes it harder to fix this properly later on.
>>
>> I missed your original review comment, so apologies for repeating what
>> you said there already.
>>
>> I'd agree that passing a starting index to the displayid_iter_*
>> functions is probably not the right direction here. More thoughts below.
>>
>>>
>>>
>>> BR,
>>> Jani.
>>>
>>>
>>> [1] https://lore.kernel.org/r/87czjf8dik@intel.com
>>>
>>>
>>>
>>> > {
>>> > memset(iter, 0, sizeof(*iter));
>>> >
>>> > iter->edid = edid;
>>> > +
>>> > + if (ext_index)
>>> > + iter->ext_index = *ext_index;
>>> > }
>>> >
>>> > static const struct displayid_block * @@ -126,7 +129,10 @@
>>> > __displayid_iter_next(struct displayid_iter *iter)
>>> > }
>>> > }
>>> >
>>> > -void displayid_iter_end(struct displayid_iter *iter)
>>> > +void displayid_iter_end(struct displayid_iter *iter, int
>>> > +*ext_index)
>>> > {
>>> > + if (ext_index)
>>> > + *ext_index = iter->ext_index;
>>> > +
>>> > memset(iter, 0, sizeof(*iter));
>>> > }
>>> > diff --git a/drivers/gpu/drm/drm_edid.c
>>> > b/drivers/gpu/drm/drm_edid.c index 561f53831e29..78c415aa6889
>>> > 100644
>>> > --- a/drivers/gpu/drm/drm_edid.c
>>> > +++ b/drivers/gpu/drm/drm_edid.c
>>> > @@ -3353,28 +3353,27 @@ const u8 *drm_find_edid_extension(const struct
>>> > edid *edid,
>>> > return edid_ext;
>>> > }
>>> >
>>> > -static const u8 *drm_find_cea_extension(const struct edid *edid)
>>> > +static const u8 *drm_find_cea_extension(const struct edid *edid,
>>> > + int *cea_ext_index, int
>>> > *displayid_ext_index)
>>
>> As discussed above, passing both indices into this function may not be
>> the best approach here. But I think we need to keep track of some kind
>> of state in order to know which was the last CEA block that was
>> returned, and thus this function can return the next one after that,
>> whether it's in the CEA extension block or DisplayID block.
>
>Per DisplayID v1.3 Appendix B: DisplayID as an EDID Extension, it's
>recommended that DisplayID extensions are exposed after all of the CEA
>extensions.
>
>I think it should be fine to first iterate over all CEA extensions across the
>EDID, followed by iterating over all the DisplayID extensions. No need to keep
>track of the order between CEA and DisplayID, as the former should precede the
>latter.
>
Refer to "DisplayID extensions are exposed after all of the CEA extensions". It
looks to me patch v5 is able to support this. And did not touch DisplayID
iterator.
https://patchwork.freedesktop.org/series/100690/#re
Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
On 15/03/22 2:35 pm, Paul Menzel wrote:
> Dear Arunpravin,
>
>
> Am 15.03.22 um 10:01 schrieb Arunpravin:
>
>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>
>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC
Signed-off-by: Arunpravin
>>>
>>> Please use your full name.
>> okay
>
> You might also configure that in your email program.
yes
>
---
drivers/gpu/drm/drm_buddy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
>>>
>>> In what tree is that file?
>>>
>> drm-tip -
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5Bspe5QGjQ0KHfVI8%2F%2BXqxR45q6tOL4FE2fVD3uwL%2FM%3D&reserved=0
>> drm-misc-next -
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g2S14TfsHF5ORo9jTZ3uA0l1BH8mnAxk2OWYJeF5i8k%3D&reserved=0
>>
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
- if (order-- == min_order) {
+ if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
>
> Thank you for the hint. So the whole function is:
>
> do {
> order = min(order, (unsigned int)fls(pages) - 1);
> BUG_ON(order > mm->max_order);
> BUG_ON(order < min_order);
>
> do {
> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
> /* Allocate traversing within the range */
> block = alloc_range_bias(mm, start, end, order);
> else
> /* Allocate from freelist */
> block = alloc_from_freelist(mm, order, flags);
>
> if (!IS_ERR(block))
> break;
>
> if (order-- == min_order) {
> err = -ENOSPC;
> goto err_free;
> }
> } while (1);
>
> mark_allocated(block);
> mm->avail -= drm_buddy_block_size(mm, block);
> kmemleak_update_trace(block);
> list_add_tail(&block->link, &allocated);
>
> pages -= BIT(order);
>
> if (!pages)
> break;
> } while (1);
>
> Was the BUG_ON triggered for your case?
>
> BUG_ON(order < min_order);
no, this BUG_ON is not triggered for this bug
>
> Please give more details.
there is a chance when there is no space to allocate, order value
decrements and reaches to 0 at one point, here we should exit the loop,
otherwise, further order value decrements to -1 and do..while loop
doesn't exit. Hence added a check to exit the loop if order value becomes 0.
Thanks,
Arun
>
>
> Kind regards,
>
> Paul
>
Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
Dear Arunpravin,
Am 15.03.22 um 16:42 schrieb Arunpravin:
On 15/03/22 2:35 pm, Paul Menzel wrote:
Am 15.03.22 um 10:01 schrieb Arunpravin:
On 15/03/22 1:49 pm, Paul Menzel wrote:
Am 14.03.22 um 20:40 schrieb Arunpravin:
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC
Signed-off-by: Arunpravin
Please use your full name.
okay
You might also configure that in your email program.
yes
Not done yet though. ;-)
---
drivers/gpu/drm/drm_buddy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
In what tree is that file?
drm-tip -
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5Bspe5QGjQ0KHfVI8%2F%2BXqxR45q6tOL4FE2fVD3uwL%2FM%3D&reserved=0
drm-misc-next -
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g2S14TfsHF5ORo9jTZ3uA0l1BH8mnAxk2OWYJeF5i8k%3D&reserved=0
Thank Outlook. Now everybody feels safe.
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
- if (order-- == min_order) {
+ if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
Thank you for the hint. So the whole function is:
do {
order = min(order, (unsigned int)fls(pages) - 1);
BUG_ON(order > mm->max_order);
BUG_ON(order < min_order);
do {
if (flags & DRM_BUDDY_RANGE_ALLOCATION)
/* Allocate traversing within the range */
block = alloc_range_bias(mm, start, end, order);
else
/* Allocate from freelist */
block = alloc_from_freelist(mm, order, flags);
if (!IS_ERR(block))
break;
if (order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
} while (1);
mark_allocated(block);
mm->avail -= drm_buddy_block_size(mm, block);
kmemleak_update_trace(block);
list_add_tail(&block->link, &allocated);
pages -= BIT(order);
if (!pages)
break;
} while (1);
Was the BUG_ON triggered for your case?
BUG_ON(order < min_order);
no, this BUG_ON is not triggered for this bug
Please give more details.
there is a chance when there is no space to allocate, order value
decrements and reaches to 0 at one point, here we should exit the loop,
otherwise, further order value decrements to -1 and do..while loop
doesn't exit. Hence added a check to exit the loop if order value becomes 0.
Sorry, I do not see it. How can that be with order ≥ min_order and the
check `order-- == min_order`? Is min_order 0? Please explain that in the
next commit message.
Kind regards,
Paul
Re: [PATCH 01/30] drm/amd/pm: fix typos in comments
Applied. Thanks! On Mon, Mar 14, 2022 at 8:01 AM Julia Lawall wrote: > > Various spelling mistakes in comments. > Detected with the help of Coccinelle. > > Signed-off-by: Julia Lawall > > --- > drivers/gpu/drm/amd/pm/amdgpu_pm.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c > b/drivers/gpu/drm/amd/pm/amdgpu_pm.c > index cbbbd4079249..5cd67ddf8495 100644 > --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c > +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c > @@ -1870,7 +1870,7 @@ static ssize_t amdgpu_set_smartshift_bias(struct device > *dev, > amdgpu_smartshift_bias = bias; > r = count; > > - /* TODO: upadte bias level with SMU message */ > + /* TODO: update bias level with SMU message */ > > out: > pm_runtime_mark_last_busy(ddev->dev); >
Re: [PATCH 29/30] drm/amdgpu: fix typos in comments
Applied. Thanks!
Alex
On Mon, Mar 14, 2022 at 8:01 AM Julia Lawall wrote:
>
> Various spelling mistakes in comments.
> Detected with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index fe660a8e150f..970b065e9a6b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -340,7 +340,7 @@ static void amdgpu_cs_get_threshold_for_moves(struct
> amdgpu_device *adev,
> if (free_vram >= 128 * 1024 * 1024 || free_vram >= total_vram / 8) {
> s64 min_us;
>
> - /* Be more aggresive on dGPUs. Try to fill a portion of free
> + /* Be more aggressive on dGPUs. Try to fill a portion of free
> * VRAM now.
> */
> if (!(adev->flags & AMD_IS_APU))
> @@ -1280,7 +1280,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
> continue;
>
> /*
> -* Work around dma_resv shortcommings by wrapping up the
> +* Work around dma_resv shortcomings by wrapping up the
> * submission in a dma_fence_chain and add it as exclusive
> * fence.
> */
>
Re: [PATCH 23/30] drm/amdgpu/dc: fix typos in comments
Applied. Thanks!
On Mon, Mar 14, 2022 at 8:01 AM Julia Lawall wrote:
>
> Various spelling mistakes in comments.
> Detected with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/gpu/drm/amd/display/dc/bios/command_table.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
> b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
> index ad13e4e36d77..0e36cd800fc9 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
> @@ -456,7 +456,7 @@ static enum bp_result transmitter_control_v2(
> if ((CONNECTOR_ID_DUAL_LINK_DVII == connector_id) ||
> (CONNECTOR_ID_DUAL_LINK_DVID == connector_id))
> /* on INIT this bit should be set according to the
> -* phisycal connector
> +* physical connector
> * Bit0: dual link connector flag
> * =0 connector is single link connector
> * =1 connector is dual link connector
> @@ -468,7 +468,7 @@ static enum bp_result transmitter_control_v2(
>
> cpu_to_le16((uint8_t)cntl->connector_obj_id.id);
> break;
> case TRANSMITTER_CONTROL_SET_VOLTAGE_AND_PREEMPASIS:
> - /* votage swing and pre-emphsis */
> + /* voltage swing and pre-emphsis */
> params.asMode.ucLaneSel = (uint8_t)cntl->lane_select;
> params.asMode.ucLaneSet = (uint8_t)cntl->lane_settings;
> break;
> @@ -2120,7 +2120,7 @@ static enum bp_result program_clock_v5(
> memset(¶ms, 0, sizeof(params));
> if (!bp->cmd_helper->clock_source_id_to_atom(
> bp_params->pll_id, &atom_pll_id)) {
> - BREAK_TO_DEBUGGER(); /* Invalid Inpute!! */
> + BREAK_TO_DEBUGGER(); /* Invalid Input!! */
> return BP_RESULT_BADINPUT;
> }
>
>
Re: [PATCH 02/22] drm/amdgpu: Remove pointless on stack mode copies
Applied. Thanks!
Alex
On Fri, Feb 18, 2022 at 11:28 AM Harry Wentland wrote:
>
>
>
> On 2022-02-18 05:03, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > These on stack copies of the modes appear to be pointless.
> > Just look at the originals directly.
> >
> > Cc: Harry Wentland
> > Cc: Leo Li
> > Cc: Rodrigo Siqueira
> > Cc: Alex Deucher
> > Cc: amd-...@lists.freedesktop.org
> > Cc: Nikola Cornij
> > Cc: Aurabindo Pillai
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> > ---
> > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +--
> > 1 file changed, 16 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 21dba337dab0..65aab0d086b6 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -10139,27 +10139,27 @@ static bool
> > is_timing_unchanged_for_freesync(struct drm_crtc_state *old_crtc_state,
> >struct drm_crtc_state *new_crtc_state)
> > {
> > - struct drm_display_mode old_mode, new_mode;
> > + const struct drm_display_mode *old_mode, *new_mode;
> >
> > if (!old_crtc_state || !new_crtc_state)
> > return false;
> >
> > - old_mode = old_crtc_state->mode;
> > - new_mode = new_crtc_state->mode;
> > + old_mode = &old_crtc_state->mode;
> > + new_mode = &new_crtc_state->mode;
> >
> > - if (old_mode.clock == new_mode.clock &&
> > - old_mode.hdisplay== new_mode.hdisplay &&
> > - old_mode.vdisplay== new_mode.vdisplay &&
> > - old_mode.htotal == new_mode.htotal &&
> > - old_mode.vtotal != new_mode.vtotal &&
> > - old_mode.hsync_start == new_mode.hsync_start &&
> > - old_mode.vsync_start != new_mode.vsync_start &&
> > - old_mode.hsync_end == new_mode.hsync_end &&
> > - old_mode.vsync_end != new_mode.vsync_end &&
> > - old_mode.hskew == new_mode.hskew &&
> > - old_mode.vscan == new_mode.vscan &&
> > - (old_mode.vsync_end - old_mode.vsync_start) ==
> > - (new_mode.vsync_end - new_mode.vsync_start))
> > + if (old_mode->clock == new_mode->clock &&
> > + old_mode->hdisplay== new_mode->hdisplay &&
> > + old_mode->vdisplay== new_mode->vdisplay &&
> > + old_mode->htotal == new_mode->htotal &&
> > + old_mode->vtotal != new_mode->vtotal &&
> > + old_mode->hsync_start == new_mode->hsync_start &&
> > + old_mode->vsync_start != new_mode->vsync_start &&
> > + old_mode->hsync_end == new_mode->hsync_end &&
> > + old_mode->vsync_end != new_mode->vsync_end &&
> > + old_mode->hskew == new_mode->hskew &&
> > + old_mode->vscan == new_mode->vscan &&
> > + (old_mode->vsync_end - old_mode->vsync_start) ==
> > + (new_mode->vsync_end - new_mode->vsync_start))
> > return true;
> >
> > return false;
>
Re: [Intel-gfx] [PATCH] drm/i915: Reduce stack usage in debugfs due to SSEU
On Mon, 2022-03-14 at 19:08 -0700, Matt Roper wrote:
> From: John Harrison
>
> sseu_dev_info is already a pretty large structure which will likely
> continue to grow when future platforms increase potential DSS and EU
> counts. Let's switch the stack placement of this structure in debugfs
> with a dynamic allocation.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: John Harrison
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 22 +---
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
> index 6b944de48666..2d5d011e01db 100644
> --- a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
> @@ -248,7 +248,7 @@ int intel_sseu_status(struct seq_file *m, struct intel_gt
> *gt)
> {
> struct drm_i915_private *i915 = gt->i915;
> const struct intel_gt_info *info = >->info;
> - struct sseu_dev_info sseu;
> + struct sseu_dev_info *sseu;
> intel_wakeref_t wakeref;
>
> if (GRAPHICS_VER(i915) < 8)
> @@ -258,23 +258,29 @@ int intel_sseu_status(struct seq_file *m, struct
> intel_gt *gt)
> i915_print_sseu_info(m, true, HAS_POOLED_EU(i915), &info->sseu);
>
> seq_puts(m, "SSEU Device Status\n");
> - memset(&sseu, 0, sizeof(sseu));
> - intel_sseu_set_info(&sseu, info->sseu.max_slices,
> +
> + sseu = kzalloc(sizeof(*sseu), GFP_KERNEL);
> + if (!sseu)
> + return -ENOMEM;
> +
> + intel_sseu_set_info(sseu, info->sseu.max_slices,
> info->sseu.max_subslices,
> info->sseu.max_eus_per_subslice);
>
> with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> if (IS_CHERRYVIEW(i915))
> - cherryview_sseu_device_status(gt, &sseu);
> + cherryview_sseu_device_status(gt, sseu);
> else if (IS_BROADWELL(i915))
> - bdw_sseu_device_status(gt, &sseu);
> + bdw_sseu_device_status(gt, sseu);
> else if (GRAPHICS_VER(i915) == 9)
> - gen9_sseu_device_status(gt, &sseu);
> + gen9_sseu_device_status(gt, sseu);
> else if (GRAPHICS_VER(i915) >= 11)
> - gen11_sseu_device_status(gt, &sseu);
> + gen11_sseu_device_status(gt, sseu);
> }
>
> - i915_print_sseu_info(m, false, HAS_POOLED_EU(i915), &sseu);
> + i915_print_sseu_info(m, false, HAS_POOLED_EU(i915), sseu);
> +
> + kfree(sseu);
>
> return 0;
> }
Re: [PATCH 1/3] drm/i915: Report steering details in debugfs
On Mon, 2022-03-14 at 16:42 -0700, Matt Roper wrote:
> Add a new 'steering' node in each gt's debugfs directory that tells
> whether we're using explicit steering for various types of MCR ranges
> and, if so, what MMIO ranges it applies to.
>
> We're going to be transitioning away from implicit steering, even for
> slice/dss steering soon, so the information reported here will become
> increasingly valuable once that happens.
>
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c | 46 +
> drivers/gpu/drm/i915/gt/intel_gt.h | 2 +
> drivers/gpu/drm/i915/gt/intel_gt_debugfs.c | 13 ++
> drivers/gpu/drm/i915/gt/intel_gt_types.h| 5 +++
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +++-
> 5 files changed, 73 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 8a2483ccbfb9..041add4019fc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -96,6 +96,12 @@ int intel_gt_assign_ggtt(struct intel_gt *gt)
> return gt->ggtt ? 0 : -ENOMEM;
> }
>
> +const char *intel_steering_types[] = {
missing static as kernel test bot reported.
with that fixed: Reviewed-by: José Roberto de Souza
> + "L3BANK",
> + "MSLICE",
> + "LNCF",
> +};
> +
> static const struct intel_mmio_range icl_l3bank_steering_table[] = {
> { 0x00B100, 0x00B3FF },
> {},
> @@ -932,6 +938,46 @@ u32 intel_gt_read_register(struct intel_gt *gt,
> i915_reg_t reg)
> return intel_uncore_read(gt->uncore, reg);
> }
>
> +static void report_steering_type(struct drm_printer *p,
> + struct intel_gt *gt,
> + enum intel_steering_type type,
> + bool dump_table)
> +{
> + const struct intel_mmio_range *entry;
> + u8 slice, subslice;
> +
> + BUILD_BUG_ON(ARRAY_SIZE(intel_steering_types) != NUM_STEERING_TYPES);
> +
> + if (!gt->steering_table[type]) {
> + drm_printf(p, "%s steering: uses default steering\n",
> +intel_steering_types[type]);
> + return;
> + }
> +
> + intel_gt_get_valid_steering(gt, type, &slice, &subslice);
> + drm_printf(p, "%s steering: sliceid=0x%x, subsliceid=0x%x\n",
> +intel_steering_types[type], slice, subslice);
> +
> + if (!dump_table)
> + return;
> +
> + for (entry = gt->steering_table[type]; entry->end; entry++)
> + drm_printf(p, "\t0x%06x - 0x%06x\n", entry->start, entry->end);
> +}
> +
> +void intel_gt_report_steering(struct drm_printer *p, struct intel_gt *gt,
> + bool dump_table)
> +{
> + drm_printf(p, "Default steering: sliceid=0x%x, subsliceid=0x%x\n",
> +gt->default_steering.groupid,
> +gt->default_steering.instanceid);
> +
> + if (HAS_MSLICES(gt->i915)) {
> + report_steering_type(p, gt, MSLICE, dump_table);
> + report_steering_type(p, gt, LNCF, dump_table);
> + }
> +}
> +
> void intel_gt_info_print(const struct intel_gt_info *info,
>struct drm_printer *p)
> {
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> b/drivers/gpu/drm/i915/gt/intel_gt.h
> index 0f571c8ee22b..3edece1865e4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> @@ -87,6 +87,8 @@ static inline bool intel_gt_needs_read_steering(struct
> intel_gt *gt,
> u32 intel_gt_read_register_fw(struct intel_gt *gt, i915_reg_t reg);
> u32 intel_gt_read_register(struct intel_gt *gt, i915_reg_t reg);
>
> +void intel_gt_report_steering(struct drm_printer *p, struct intel_gt *gt,
> + bool dump_table);
> void intel_gt_info_print(const struct intel_gt_info *info,
>struct drm_printer *p);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> index f103664b71d4..6f45b131a001 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> @@ -6,6 +6,7 @@
> #include
>
> #include "i915_drv.h"
> +#include "intel_gt.h"
> #include "intel_gt_debugfs.h"
> #include "intel_gt_engines_debugfs.h"
> #include "intel_gt_pm_debugfs.h"
> @@ -57,10 +58,22 @@ static int __intel_gt_debugfs_reset_store(void *data, u64
> val)
> DEFINE_SIMPLE_ATTRIBUTE(reset_fops, __intel_gt_debugfs_reset_show,
> __intel_gt_debugfs_reset_store, "%llu\n");
>
> +static int steering_show(struct seq_file *m, void *data)
> +{
> + struct drm_printer p = drm_seq_file_printer(m);
> + struct intel_gt *gt = m->private;
> +
> + intel_gt_report_steering(&p, gt, true);
> +
> + return 0;
> +}
> +DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(steering);
> +
> static void gt_debugfs_register(struct intel_gt *gt, struc
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/gem: Remove logic for wbinvd_on_all_cpus
+Daniel for additional feedback!
On 2022-03-14 4:06 p.m., Michael Cheng wrote:
On 2022-03-08 10:58 a.m., Lucas De Marchi wrote:
On Tue, Feb 22, 2022 at 08:24:31PM +0100, Thomas Hellström (Intel)
wrote:
Hi, Michael,
On 2/22/22 18:26, Michael Cheng wrote:
This patch removes logic for wbinvd_on_all_cpus and brings in
drm_cache.h. This header has the logic that outputs a warning
when wbinvd_on_all_cpus when its being used on a non-x86 platform.
Signed-off-by: Michael Cheng
Linus has been pretty clear that he won't accept patches that add
macros that works on one arch and warns on others anymore in i915
and I figure even less so in drm code.
So we shouldn't try to move this out to drm. Instead we should
restrict the wbinvd() inside our driver to integrated and X86 only.
For discrete on all architectures we should be coherent and hence
not be needing wbinvd().
the warn is there to guarantee we don't forget a code path. However
simply adding the warning is the real issue: we should rather guarantee
we can't take that code path. I.e., as you said refactor the code to
guarantee it works on discrete without that logic.
$ git grep wbinvd_on_all_cpus -- drivers/gpu/drm/
drivers/gpu/drm/drm_cache.c: if (wbinvd_on_all_cpus())
drivers/gpu/drm/drm_cache.c: if (wbinvd_on_all_cpus())
drivers/gpu/drm/drm_cache.c: if (wbinvd_on_all_cpus())
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c: * Currently we
just do a heavy handed wbinvd_on_all_cpus() here since
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c: wbinvd_on_all_cpus();
It looks like we actually go through this on other discrete graphics. Is
this missing an update like s/IS_DG1/IS_DGFX/? Or should we be doing
something else?
drivers/gpu/drm/i915/gem/i915_gem_pm.c:#define
wbinvd_on_all_cpus() \
drivers/gpu/drm/i915/gem/i915_gem_pm.c: wbinvd_on_all_cpus();
Those are for suspend. Revert ac05a22cd07a ("drm/i915/gem: Almagamate
clflushes on suspend")
or extract that part to a helper function and implement it differently
for arches != x86?
drivers/gpu/drm/i915/gem/i915_gem_pm.c: wbinvd_on_all_cpus();
Probably take a similar approach to the suspend case?
drivers/gpu/drm/i915/gt/intel_ggtt.c: wbinvd_on_all_cpus();
For a helper function, I have a #define for all non x86 architecture
that gives a warn on [1] within drm_cache.h Or would it be better to
implement a helper function instead?
[1]. https://patchwork.freedesktop.org/patch/475750/?series=1&rev=5
This one comes from 64b95df91f44 ("drm/i915: Assume exclusive access
to objects inside resume")
Shouldn't that be doing the invalidate if the write domain is
I915_GEM_DOMAIN_CPU
In the end I think the warning would be ok if it was the cherry on top,
to guarantee we don't take those paths. We should probably have a
warn_once() to avoid spamming the console. But we also have to rework
the code to guarantee we are the only ones who may eventually get that
warning, and not the end user.
Could we first add the helper function/#define for now, and rework the
code in a different patch series?
Lucas De Marchi
Thanks,
/Thomas
[PATCH v2 1/3] drm/i915: Report steering details in debugfs
Add a new 'steering' node in each gt's debugfs directory that tells
whether we're using explicit steering for various types of MCR ranges
and, if so, what MMIO ranges it applies to.
We're going to be transitioning away from implicit steering, even for
slice/dss steering soon, so the information reported here will become
increasingly valuable once that happens.
v2:
- Adding missing 'static' on intel_steering_types[] (Jose, sparse)
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
Reviewed-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_gt.c | 46 +
drivers/gpu/drm/i915/gt/intel_gt.h | 2 +
drivers/gpu/drm/i915/gt/intel_gt_debugfs.c | 13 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h| 5 +++
drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +++-
5 files changed, 73 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 8a2483ccbfb9..4c7ad9d14f4f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -96,6 +96,12 @@ int intel_gt_assign_ggtt(struct intel_gt *gt)
return gt->ggtt ? 0 : -ENOMEM;
}
+static const char *intel_steering_types[] = {
+ "L3BANK",
+ "MSLICE",
+ "LNCF",
+};
+
static const struct intel_mmio_range icl_l3bank_steering_table[] = {
{ 0x00B100, 0x00B3FF },
{},
@@ -932,6 +938,46 @@ u32 intel_gt_read_register(struct intel_gt *gt, i915_reg_t
reg)
return intel_uncore_read(gt->uncore, reg);
}
+static void report_steering_type(struct drm_printer *p,
+struct intel_gt *gt,
+enum intel_steering_type type,
+bool dump_table)
+{
+ const struct intel_mmio_range *entry;
+ u8 slice, subslice;
+
+ BUILD_BUG_ON(ARRAY_SIZE(intel_steering_types) != NUM_STEERING_TYPES);
+
+ if (!gt->steering_table[type]) {
+ drm_printf(p, "%s steering: uses default steering\n",
+ intel_steering_types[type]);
+ return;
+ }
+
+ intel_gt_get_valid_steering(gt, type, &slice, &subslice);
+ drm_printf(p, "%s steering: sliceid=0x%x, subsliceid=0x%x\n",
+ intel_steering_types[type], slice, subslice);
+
+ if (!dump_table)
+ return;
+
+ for (entry = gt->steering_table[type]; entry->end; entry++)
+ drm_printf(p, "\t0x%06x - 0x%06x\n", entry->start, entry->end);
+}
+
+void intel_gt_report_steering(struct drm_printer *p, struct intel_gt *gt,
+ bool dump_table)
+{
+ drm_printf(p, "Default steering: sliceid=0x%x, subsliceid=0x%x\n",
+ gt->default_steering.groupid,
+ gt->default_steering.instanceid);
+
+ if (HAS_MSLICES(gt->i915)) {
+ report_steering_type(p, gt, MSLICE, dump_table);
+ report_steering_type(p, gt, LNCF, dump_table);
+ }
+}
+
void intel_gt_info_print(const struct intel_gt_info *info,
struct drm_printer *p)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 0f571c8ee22b..3edece1865e4 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -87,6 +87,8 @@ static inline bool intel_gt_needs_read_steering(struct
intel_gt *gt,
u32 intel_gt_read_register_fw(struct intel_gt *gt, i915_reg_t reg);
u32 intel_gt_read_register(struct intel_gt *gt, i915_reg_t reg);
+void intel_gt_report_steering(struct drm_printer *p, struct intel_gt *gt,
+ bool dump_table);
void intel_gt_info_print(const struct intel_gt_info *info,
struct drm_printer *p);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
index f103664b71d4..6f45b131a001 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
@@ -6,6 +6,7 @@
#include
#include "i915_drv.h"
+#include "intel_gt.h"
#include "intel_gt_debugfs.h"
#include "intel_gt_engines_debugfs.h"
#include "intel_gt_pm_debugfs.h"
@@ -57,10 +58,22 @@ static int __intel_gt_debugfs_reset_store(void *data, u64
val)
DEFINE_SIMPLE_ATTRIBUTE(reset_fops, __intel_gt_debugfs_reset_show,
__intel_gt_debugfs_reset_store, "%llu\n");
+static int steering_show(struct seq_file *m, void *data)
+{
+ struct drm_printer p = drm_seq_file_printer(m);
+ struct intel_gt *gt = m->private;
+
+ intel_gt_report_steering(&p, gt, true);
+
+ return 0;
+}
+DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(steering);
+
static void gt_debugfs_register(struct intel_gt *gt, struct dentry *root)
{
static const struct intel_gt_debugfs_file files[] = {
{ "reset", &reset_fops, NULL },
+ { "steering", &steering_fops },
};
intel_gt_debu
Re: [v7 1/5] drm/edid: seek for available CEA and DisplayID block from specific EDID block index
On Tue, Mar 15, 2022 at 03:21:05PM +, Lee, Shawn C wrote:
> On Tuesday, March 15, 2022 8:33 PM, Nikula, Jani
> wrote:
> >On Mon, 14 Mar 2022, Drew Davenport wrote:
> >> On Mon, Mar 14, 2022 at 10:40:47AM +0200, Jani Nikula wrote:
> >>> On Sun, 13 Mar 2022, Lee Shawn C wrote:
> >>> > drm_find_cea_extension() always look for a top level CEA block.
> >>> > Pass ext_index from caller then this function to search next
> >>> > available CEA ext block from a specific EDID block pointer.
> >>> >
> >>> > v2: save proper extension block index if CTA data information
> >>> > was found in DispalyID block.
> >>> > v3: using different parameters to store CEA and DisplayID block index.
> >>> > configure DisplayID extansion block index before search available
> >>> > DisplayID block.
> >>> >
> >>> > Cc: Jani Nikula
> >>> > Cc: Ville Syrjala
> >>> > Cc: Ankit Nautiyal
> >>> > Cc: Drew Davenport
> >>> > Cc: intel-gfx
> >>> > Signed-off-by: Lee Shawn C
> >>> > ---
> >>> > drivers/gpu/drm/drm_displayid.c | 10 +--
> >>> > drivers/gpu/drm/drm_edid.c | 53 ++---
> >>> > include/drm/drm_displayid.h | 4 +--
> >>> > 3 files changed, 39 insertions(+), 28 deletions(-)
> >>> >
> >>> > diff --git a/drivers/gpu/drm/drm_displayid.c
> >>> > b/drivers/gpu/drm/drm_displayid.c index 32da557b960f..31c3e6d7d549
> >>> > 100644
> >>> > --- a/drivers/gpu/drm/drm_displayid.c
> >>> > +++ b/drivers/gpu/drm/drm_displayid.c
> >>> > @@ -59,11 +59,14 @@ static const u8
> >>> > *drm_find_displayid_extension(const struct edid *edid, }
> >>> >
> >>> > void displayid_iter_edid_begin(const struct edid *edid,
> >>> > - struct displayid_iter *iter)
> >>> > + struct displayid_iter *iter, int
> >>> > *ext_index)
> >>>
> >>> Please don't do this. This just ruins the clean approach displayid
> >>> iterator added.
> >>>
> >>> Instead of making the displayid iterator ugly, and leaking its
> >>> abstractions, I'll repeat what I said should be done in reply to the
> >>> very first version of this patch series [1]:
> >>>
> >>> "I think we're going to need abstracted EDID iteration similar to
> >>> what I've done for DisplayID iteration. We can't have all places
> >>> reimplementing the iteration like we have now."
> >>>
> >>> This isn't a problem that should be solved by having all the callers
> >>> hold a bunch of local variables and pass them around to all the
> >>> functions. Nobody's going to be able to keep track of this anymore.
> >>> And this series, as it is, makes it harder to fix this properly later on.
> >>
> >> I missed your original review comment, so apologies for repeating what
> >> you said there already.
> >>
> >> I'd agree that passing a starting index to the displayid_iter_*
> >> functions is probably not the right direction here. More thoughts below.
> >>
> >>>
> >>>
> >>> BR,
> >>> Jani.
> >>>
> >>>
> >>> [1] https://lore.kernel.org/r/87czjf8dik@intel.com
> >>>
> >>>
> >>>
> >>> > {
> >>> > memset(iter, 0, sizeof(*iter));
> >>> >
> >>> > iter->edid = edid;
> >>> > +
> >>> > + if (ext_index)
> >>> > + iter->ext_index = *ext_index;
> >>> > }
> >>> >
> >>> > static const struct displayid_block * @@ -126,7 +129,10 @@
> >>> > __displayid_iter_next(struct displayid_iter *iter)
> >>> > }
> >>> > }
> >>> >
> >>> > -void displayid_iter_end(struct displayid_iter *iter)
> >>> > +void displayid_iter_end(struct displayid_iter *iter, int
> >>> > +*ext_index)
> >>> > {
> >>> > + if (ext_index)
> >>> > + *ext_index = iter->ext_index;
> >>> > +
> >>> > memset(iter, 0, sizeof(*iter));
> >>> > }
> >>> > diff --git a/drivers/gpu/drm/drm_edid.c
> >>> > b/drivers/gpu/drm/drm_edid.c index 561f53831e29..78c415aa6889
> >>> > 100644
> >>> > --- a/drivers/gpu/drm/drm_edid.c
> >>> > +++ b/drivers/gpu/drm/drm_edid.c
> >>> > @@ -3353,28 +3353,27 @@ const u8 *drm_find_edid_extension(const struct
> >>> > edid *edid,
> >>> > return edid_ext;
> >>> > }
> >>> >
> >>> > -static const u8 *drm_find_cea_extension(const struct edid *edid)
> >>> > +static const u8 *drm_find_cea_extension(const struct edid *edid,
> >>> > + int *cea_ext_index, int
> >>> > *displayid_ext_index)
> >>
> >> As discussed above, passing both indices into this function may not be
> >> the best approach here. But I think we need to keep track of some kind
> >> of state in order to know which was the last CEA block that was
> >> returned, and thus this function can return the next one after that,
> >> whether it's in the CEA extension block or DisplayID block.
> >
> >Per DisplayID v1.3 Appendix B: DisplayID as an EDID Extension, it's
> >recommended that DisplayID extensions are exposed after all of the CEA
> >extensions.
> >
> >I think it should be fine to first iterate over all CEA extensions across
> >the EDID
Re: [PATCH v8 00/16] clk: provide new devm helpers for prepared and enabled clocks
On Mon, Mar 14, 2022 at 5:14 PM Uwe Kleine-König wrote: > > Hello, > > this is another try to convince the relevant people that > devm_clk_get_enabled() is a nice idea. Compared to v7 (back in May 2021) this > series is rebased to v5.17-rc8 and converts quite some drivers that open code > devm_clk_get_enabled() up to now (patches #3 - #11). > > A concern about devm_clk_get_enabled() in v7 was that it helps people to be > lazy and I agree that in some situations when devm_clk_get_enabled() is used > it > would be more efficient and sensible to care to only enable the clk when > really > needed. > > On the other hand, the function is right for some users, e.g. the watchdog > drivers. For the others it's not so simple to judge. Given that there are a > lot of drivers that are lazy even if doing so is some effort (i.e. calling > clk_prepare_enable() and devm_add_action()) convinces me, that introducing the > function family is sensible. (And if you want to work on these drivers, > grepping for devm_clk_get_enabled gives you a few candidates once the > series is in :-) FWIW, Reviewed-by: Andy Shevchenko for drivers/iio Thanks for doing this! > Otherwise looking at the diffstat of this series: > > 48 files changed, 257 insertions(+), 851 deletions(-) > > is quite convincing. Just the first two patches (which introduce the new > functions) account for > > 2 files changed, 169 insertions(+), 17 deletions(-) > > . A rough third of the added lines is documentation. The rest is driver > updates which then has: > > 46 files changed, 88 insertions(+), 834 deletions(-) > > which makes a really nice cleanup. > > The series is build-tested on arm64, m68k, powerpc, riscv, s390, sparc64 > and x86_64 using an allmodconfig. > > Best regards > Uwe > > Uwe Kleine-König (16): > clk: generalize devm_clk_get() a bit > clk: Provide new devm_clk helpers for prepared and enabled clocks > hwmon: Make use of devm_clk_get_enabled() > iio: Make use of devm_clk_get_enabled() > hwrng: meson - Don't open-code devm_clk_get_optional_enabled() > bus: bt1: Don't open code devm_clk_get_enabled() > gpio: vf610: Simplify error handling in probe > drm/meson: dw-hdmi: Don't open code devm_clk_get_enabled() > rtc: ingenic: Simplify using devm_clk_get_enabled() > clk: meson: axg-audio: Don't duplicate devm_clk_get_enabled() > watchdog: Make use of devm_clk_get_enabled() > pwm: atmel: Simplify using devm_clk_get_prepared() > rtc: at91sam9: Simplify using devm_clk_get_enabled() > i2c: imx: Simplify using devm_clk_get_enabled() > spi: davinci: Simplify using devm_clk_get_enabled() > dmaengine: lgm: Fix error handling > > drivers/bus/bt1-apb.c | 23 +-- > drivers/bus/bt1-axi.c | 23 +-- > drivers/char/hw_random/meson-rng.c| 20 +- > drivers/clk/clk-devres.c | 96 ++- > drivers/clk/meson/axg-audio.c | 36 ++ > drivers/dma/lgm/lgm-dma.c | 8 +-- > drivers/gpio/gpio-vf610.c | 45 +++-- > drivers/gpu/drm/meson/meson_dw_hdmi.c | 48 +- > drivers/hwmon/axi-fan-control.c | 15 + > drivers/hwmon/ltc2947-core.c | 17 + > drivers/hwmon/mr75203.c | 26 +--- > drivers/hwmon/sparx5-temp.c | 19 +- > drivers/i2c/busses/i2c-imx.c | 12 +--- > drivers/iio/adc/ad7124.c | 15 + > drivers/iio/adc/ad7768-1.c| 17 + > drivers/iio/adc/ad9467.c | 17 + > drivers/iio/adc/ingenic-adc.c | 15 + > drivers/iio/adc/lpc18xx_adc.c | 18 + > drivers/iio/adc/rockchip_saradc.c | 44 +--- > drivers/iio/adc/ti-ads131e08.c| 19 +- > drivers/iio/adc/xilinx-ams.c | 15 + > drivers/iio/adc/xilinx-xadc-core.c| 18 + > drivers/iio/frequency/adf4371.c | 17 + > drivers/iio/frequency/admv1013.c | 15 + > drivers/iio/frequency/adrf6780.c | 16 + > drivers/iio/imu/adis16475.c | 15 + > drivers/pwm/pwm-atmel.c | 16 + > drivers/rtc/rtc-at91sam9.c| 22 ++ > drivers/rtc/rtc-jz4740.c | 21 +- > drivers/spi/spi-davinci.c | 11 +-- > drivers/watchdog/cadence_wdt.c| 17 + > drivers/watchdog/davinci_wdt.c| 18 + > drivers/watchdog/imgpdc_wdt.c | 31 + > drivers/watchdog/imx2_wdt.c | 15 + > drivers/watchdog/imx7ulp_wdt.c| 15 + > drivers/watchdog/loongson1_wdt.c | 17 + > drivers/watchdog/lpc18xx_wdt.c| 30 + > drivers/watchdog/meson_gxbb_wdt.c | 16 + > drivers/watchdog/of_xilinx_wdt.c | 16 + > drivers/watchdog/pic32-dmt.c | 15 + > drivers/watchdog/pic32-wdt.c | 17 + > drivers/watchdog/pnx4008_wdt.c| 15 + > drivers/watchdog/qcom-wdt.c | 16 + > drivers/watchdog/rtd119x_wdt.c
[RFC PATCH 1/7] drm/i915: instantiate ttm ranger manager for stolen memory
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_region_ttm.c | 29 +++--
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 737ef3f4ab54..bb564b830c96 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -57,11 +57,17 @@ int intel_region_to_ttm_type(const struct
intel_memory_region *mem)
GEM_BUG_ON(mem->type != INTEL_MEMORY_LOCAL &&
mem->type != INTEL_MEMORY_MOCK &&
- mem->type != INTEL_MEMORY_SYSTEM);
+ mem->type != INTEL_MEMORY_SYSTEM &&
+ mem->type != INTEL_MEMORY_STOLEN_SYSTEM &&
+ mem->type != INTEL_MEMORY_STOLEN_LOCAL);
if (mem->type == INTEL_MEMORY_SYSTEM)
return TTM_PL_SYSTEM;
+ if (mem->type == INTEL_MEMORY_STOLEN_SYSTEM ||
+ mem->type == INTEL_MEMORY_STOLEN_LOCAL)
+ return TTM_PL_VRAM;
+
type = mem->instance + TTM_PL_PRIV;
GEM_BUG_ON(type >= TTM_NUM_MEM_TYPES);
@@ -85,10 +91,16 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
int mem_type = intel_region_to_ttm_type(mem);
int ret;
- ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
- resource_size(&mem->region),
- mem->io_size,
- mem->min_page_size, PAGE_SIZE);
+ if (mem_type == TTM_PL_VRAM) {
+ ret = ttm_range_man_init(bdev, mem_type, false,
+resource_size(&mem->region) >>
PAGE_SHIFT);
+ mem->is_range_manager = true;
+ } else {
+ ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
+ resource_size(&mem->region),
+ mem->io_size,
+ mem->min_page_size, PAGE_SIZE);
+ }
if (ret)
return ret;
@@ -108,6 +120,7 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
int intel_region_ttm_fini(struct intel_memory_region *mem)
{
struct ttm_resource_manager *man = mem->region_private;
+ int mem_type = intel_region_to_ttm_type(mem);
int ret = -EBUSY;
int count;
@@ -138,8 +151,10 @@ int intel_region_ttm_fini(struct intel_memory_region *mem)
if (ret || !man)
return ret;
- ret = i915_ttm_buddy_man_fini(&mem->i915->bdev,
- intel_region_to_ttm_type(mem));
+ if (mem_type == TTM_PL_VRAM)
+ ret = ttm_range_man_fini(&mem->i915->bdev, mem_type);
+ else
+ ret = i915_ttm_buddy_man_fini(&mem->i915->bdev, mem_type);
GEM_WARN_ON(ret);
mem->region_private = NULL;
--
2.25.1
[RFC PATCH 3/7] drm/i915: use gem objects to track stolen nodes
Construct gem objects around stolen nodes.
This stops the abuse of interfaces and aids future patches that done use
drm nodes for stolen areas.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 72 --
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 60 ++
drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 7 +++
3 files changed, 106 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 142280b6ce6d..9df64ecab70e 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -92,8 +92,8 @@ struct intel_fbc {
unsigned int possible_framebuffer_bits;
unsigned int busy_bits;
- struct drm_mm_node compressed_fb;
- struct drm_mm_node compressed_llb;
+ struct drm_i915_gem_object *compressed_fb;
+ struct drm_i915_gem_object *compressed_llb;
enum intel_fbc_id id;
@@ -331,16 +331,18 @@ static void i8xx_fbc_nuke(struct intel_fbc *fbc)
static void i8xx_fbc_program_cfb(struct intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
+ u64 fb_offset = i915_gem_object_stolen_offset(fbc->compressed_fb);
+ u64 llb_offset = i915_gem_object_stolen_offset(fbc->compressed_llb);
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_fb.start, U32_MAX));
+fb_offset, U32_MAX));
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_llb.start, U32_MAX));
+llb_offset, U32_MAX));
intel_de_write(i915, FBC_CFB_BASE,
- i915->dsm.start + fbc->compressed_fb.start);
+ i915->dsm.start + fb_offset);
intel_de_write(i915, FBC_LL_BASE,
- i915->dsm.start + fbc->compressed_llb.start);
+ i915->dsm.start + llb_offset);
}
static const struct intel_fbc_funcs i8xx_fbc_funcs = {
@@ -449,7 +451,8 @@ static void g4x_fbc_program_cfb(struct intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
- intel_de_write(i915, DPFC_CB_BASE, fbc->compressed_fb.start);
+ intel_de_write(i915, DPFC_CB_BASE,
+ i915_gem_object_stolen_offset(fbc->compressed_fb));
}
static const struct intel_fbc_funcs g4x_fbc_funcs = {
@@ -500,7 +503,8 @@ static void ilk_fbc_program_cfb(struct intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
- intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id),
fbc->compressed_fb.start);
+ intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id),
+ i915_gem_object_stolen_offset(fbc->compressed_fb));
}
static const struct intel_fbc_funcs ilk_fbc_funcs = {
@@ -740,21 +744,24 @@ static int find_compression_limit(struct intel_fbc *fbc,
{
struct drm_i915_private *i915 = fbc->i915;
u64 end = intel_fbc_stolen_end(i915);
- int ret, limit = min_limit;
+ int limit = min_limit;
+ struct drm_i915_gem_object *obj;
size /= limit;
/* Try to over-allocate to reduce reallocations and fragmentation. */
- ret = i915_gem_stolen_insert_node_in_range(i915, &fbc->compressed_fb,
- size <<= 1, 4096, 0, end);
- if (ret == 0)
+ obj = i915_gem_object_create_stolen_in_range(i915, size <<= 1, 4096, 0,
end);
+ if (!IS_ERR(obj)) {
+ fbc->compressed_fb = obj;
return limit;
+ }
for (; limit <= intel_fbc_max_limit(i915); limit <<= 1) {
- ret = i915_gem_stolen_insert_node_in_range(i915,
&fbc->compressed_fb,
- size >>= 1, 4096, 0,
end);
- if (ret == 0)
+ obj = i915_gem_object_create_stolen_in_range(i915, size >>= 1,
4096, 0, end);
+ if (!IS_ERR(obj)) {
+ fbc->compressed_fb = obj;
return limit;
+ }
}
return 0;
@@ -765,17 +772,19 @@ static int intel_fbc_alloc_cfb(struct intel_fbc *fbc,
{
struct drm_i915_private *i915 = fbc->i915;
int ret;
+ struct drm_i915_gem_object *obj;
- drm_WARN_ON(&i915->drm,
- drm_mm_node_allocated(&fbc->compressed_fb));
- drm_WARN_ON(&i915->drm,
- drm_mm_node_allocated(&fbc->compressed_llb));
+ drm_WARN_ON(&i915->drm, fbc->compressed_fb);
+ drm_WARN_ON(&i915->drm, fbc->compressed_llb);
if (DISPLAY_VER(i915) < 5 && !IS_G4X(i915)) {
- ret = i915_gem_stolen_insert_node(i915, &fbc->compressed_llb,
- 4096, 4096);
- if (ret)
+ obj = i915_gem_object_create_stolen_in_
[RFC PATCH 4/7] drm/i915: stolen memory use ttm backend
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 385 ++---
drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 9 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 14 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.h| 7 +
4 files changed, 40 insertions(+), 375 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 265133cb2a47..e58f9902ef47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -4,19 +4,22 @@
* Copyright © 2008-2012 Intel Corporation
*/
+#include "drm/ttm/ttm_placement.h"
+#include "gem/i915_gem_object_types.h"
#include
#include
-#include
#include
#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_region.h"
+#include "gem/i915_gem_ttm.h"
#include "i915_drv.h"
#include "i915_gem_stolen.h"
#include "i915_reg.h"
#include "i915_vgpu.h"
#include "intel_mchbar_regs.h"
+#include "intel_region_ttm.h"
/*
* The BIOS typically reserves some of the system's memory for the exclusive
@@ -30,46 +33,6 @@
* for is a boon.
*/
-int i915_gem_stolen_insert_node_in_range(struct drm_i915_private *i915,
-struct drm_mm_node *node, u64 size,
-unsigned alignment, u64 start, u64 end)
-{
- int ret;
-
- if (!drm_mm_initialized(&i915->mm.stolen))
- return -ENODEV;
-
- /* WaSkipStolenMemoryFirstPage:bdw+ */
- if (GRAPHICS_VER(i915) >= 8 && start < 4096)
- start = 4096;
-
- mutex_lock(&i915->mm.stolen_lock);
- ret = drm_mm_insert_node_in_range(&i915->mm.stolen, node,
- size, alignment, 0,
- start, end, DRM_MM_INSERT_BEST);
- mutex_unlock(&i915->mm.stolen_lock);
-
- return ret;
-}
-
-int i915_gem_stolen_insert_node(struct drm_i915_private *i915,
- struct drm_mm_node *node, u64 size,
- unsigned alignment)
-{
- return i915_gem_stolen_insert_node_in_range(i915, node,
- size, alignment,
- I915_GEM_STOLEN_BIAS,
- U64_MAX);
-}
-
-void i915_gem_stolen_remove_node(struct drm_i915_private *i915,
-struct drm_mm_node *node)
-{
- mutex_lock(&i915->mm.stolen_lock);
- drm_mm_remove_node(node);
- mutex_unlock(&i915->mm.stolen_lock);
-}
-
static int i915_adjust_stolen(struct drm_i915_private *i915,
struct resource *dsm)
{
@@ -170,14 +133,6 @@ static int i915_adjust_stolen(struct drm_i915_private
*i915,
return 0;
}
-static void i915_gem_cleanup_stolen(struct drm_i915_private *i915)
-{
- if (!drm_mm_initialized(&i915->mm.stolen))
- return;
-
- drm_mm_takedown(&i915->mm.stolen);
-}
-
static void g4x_get_stolen_reserved(struct drm_i915_private *i915,
struct intel_uncore *uncore,
resource_size_t *base,
@@ -510,216 +465,15 @@ static int i915_gem_init_stolen(struct
intel_memory_region *mem)
return 0;
/* Basic memrange allocator for stolen space. */
- drm_mm_init(&i915->mm.stolen, 0, i915->stolen_usable_size);
-
- return 0;
-}
-
-static void dbg_poison(struct i915_ggtt *ggtt,
- dma_addr_t addr, resource_size_t size,
- u8 x)
-{
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
- if (!drm_mm_node_allocated(&ggtt->error_capture))
- return;
-
- if (ggtt->vm.bind_async_flags & I915_VMA_GLOBAL_BIND)
- return; /* beware stop_machine() inversion */
-
- GEM_BUG_ON(!IS_ALIGNED(size, PAGE_SIZE));
-
- mutex_lock(&ggtt->error_mutex);
- while (size) {
- void __iomem *s;
-
- ggtt->vm.insert_page(&ggtt->vm, addr,
-ggtt->error_capture.start,
-I915_CACHE_NONE, 0);
- mb();
-
- s = io_mapping_map_wc(&ggtt->iomap,
- ggtt->error_capture.start,
- PAGE_SIZE);
- memset_io(s, x, PAGE_SIZE);
- io_mapping_unmap(s);
-
- addr += PAGE_SIZE;
- size -= PAGE_SIZE;
- }
- mb();
- ggtt->vm.clear_range(&ggtt->vm, ggtt->error_capture.start, PAGE_SIZE);
- mutex_unlock(&ggtt->error_mutex);
-#endif
-}
-
-static struct sg_table *
-i915_pages_create_for_stolen(struct drm_device *dev,
-resource_size_t offset, resource_size_t size)
-{
- struct drm_i915_private *i915 = to_i915(dev);
- struct sg_table *st;
- struct
[RFC PATCH 2/7] drm/i915: add ability to create memory region object in place
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_region.c | 55 ++
drivers/gpu/drm/i915/gem/i915_gem_region.h | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 84 ++
drivers/gpu/drm/i915/intel_memory_region.h | 6 ++
4 files changed, 136 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index c9b2e8b91053..e25ad0b9b636 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -98,6 +98,61 @@ i915_gem_object_create_region(struct intel_memory_region
*mem,
return ERR_PTR(err);
}
+struct drm_i915_gem_object *
+i915_gem_object_create_region_in_place(struct intel_memory_region *mem,
+ resource_size_t size,
+ resource_size_t page_size,
+ unsigned int flags,
+ u64 start, u64 end)
+{
+ struct drm_i915_gem_object *obj;
+ resource_size_t default_page_size;
+ int err;
+
+ /*
+* NB: Our use of resource_size_t for the size stems from using struct
+* resource for the mem->region. We might need to revisit this in the
+* future.
+*/
+
+ GEM_BUG_ON(flags & ~I915_BO_ALLOC_FLAGS);
+
+ if (!mem)
+ return ERR_PTR(-ENODEV);
+ if (!mem->ops->init_object_in_place)
+ return ERR_PTR(-EINVAL);
+
+ default_page_size = mem->min_page_size;
+ if (page_size)
+ default_page_size = page_size;
+
+ GEM_BUG_ON(!is_power_of_2_u64(default_page_size));
+ GEM_BUG_ON(default_page_size < PAGE_SIZE);
+
+ size = round_up(size, default_page_size);
+
+ GEM_BUG_ON(!size);
+ GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_MIN_ALIGNMENT));
+
+ if (i915_gem_object_size_2big(size))
+ return ERR_PTR(-E2BIG);
+
+ obj = i915_gem_object_alloc();
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ err = mem->ops->init_object_in_place(mem, obj, size, page_size, flags,
start, end);
+ if (err)
+ goto err_object_free;
+
+ trace_i915_gem_object_create(obj);
+ return obj;
+
+err_object_free:
+ i915_gem_object_free(obj);
+ return ERR_PTR(err);
+}
+
/**
* i915_gem_process_region - Iterate over all objects of a region using ops
* to process and optionally skip objects
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.h
b/drivers/gpu/drm/i915/gem/i915_gem_region.h
index fcaa12d657d4..0cad90ac4a92 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.h
@@ -56,6 +56,12 @@ i915_gem_object_create_region(struct intel_memory_region
*mem,
resource_size_t size,
resource_size_t page_size,
unsigned int flags);
+struct drm_i915_gem_object *
+i915_gem_object_create_region_in_place(struct intel_memory_region *mem,
+ resource_size_t size,
+ resource_size_t page_size,
+ unsigned int flags,
+ u64 start, u64 end);
int i915_gem_process_region(struct intel_memory_region *mr,
struct i915_gem_apply_to_region *apply);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 45cc5837ce00..35d1bde19267 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1131,20 +1131,12 @@ void i915_ttm_bo_destroy(struct ttm_buffer_object *bo)
}
}
-/**
- * __i915_gem_ttm_object_init - Initialize a ttm-backed i915 gem object
- * @mem: The initial memory region for the object.
- * @obj: The gem object.
- * @size: Object size in bytes.
- * @flags: gem object flags.
- *
- * Return: 0 on success, negative error code on failure.
- */
-int __i915_gem_ttm_object_init(struct intel_memory_region *mem,
- struct drm_i915_gem_object *obj,
- resource_size_t size,
- resource_size_t page_size,
- unsigned int flags)
+static int __i915_gem_ttm_object_init_with_placement(struct
intel_memory_region *mem,
+struct drm_i915_gem_object
*obj,
+resource_size_t size,
+resource_size_t page_size,
+unsigned int flags,
+struct ttm_placement
*placement)
{
static struct lock_class_key lock_class;
struct drm_i915_private *i915 = mem->i915;
@@ -1188,7 +1
[RFC PATCH 5/7] drm/ttm: add range busy check for range manager
RFC: do we want this to become a generic interface in
ttm_resource_manager_func?
RFC: would we prefer a different interface? e.g.
for_each_resource_in_range or for_each_bo_in_range
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 21 +
include/drm/ttm/ttm_range_manager.h | 3 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index 8cd4f3fb9f79..5662627bb933 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -206,3 +206,24 @@ int ttm_range_man_fini_nocheck(struct ttm_device *bdev,
return 0;
}
EXPORT_SYMBOL(ttm_range_man_fini_nocheck);
+
+/**
+ * ttm_range_man_range_busy - Check whether anything is allocated with a range
+ *
+ * @man: memory manager to check
+ * @fpfn: first page number to check
+ * @lpfn: last page number to check
+ *
+ * Return: true if anything allocated within the range, false otherwise.
+ */
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn)
+{
+ struct ttm_range_manager *rman = to_range_manager(man);
+ struct drm_mm *mm = &rman->mm;
+
+ if (__drm_mm_interval_first(mm, PFN_PHYS(fpfn), PFN_PHYS(lpfn + 1) - 1))
+ return true;
+ return false;
+}
+EXPORT_SYMBOL(ttm_range_man_range_busy);
diff --git a/include/drm/ttm/ttm_range_manager.h
b/include/drm/ttm/ttm_range_manager.h
index 7963b957e9ef..86794a3f9101 100644
--- a/include/drm/ttm/ttm_range_manager.h
+++ b/include/drm/ttm/ttm_range_manager.h
@@ -53,4 +53,7 @@ static __always_inline int ttm_range_man_fini(struct
ttm_device *bdev,
BUILD_BUG_ON(__builtin_constant_p(type) && type >= TTM_NUM_MEM_TYPES);
return ttm_range_man_fini_nocheck(bdev, type);
}
+
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn);
#endif
--
2.25.1
[RFC PATCH 7/7] drm/i915: cleanup old stolen state
remove i915->mm.stolen
remove i915->mm.stolen_lock
they are no longer needed.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 --
drivers/gpu/drm/i915/gt/selftest_reset.c | 16 +---
drivers/gpu/drm/i915/i915_drv.h| 5 -
4 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 9df64ecab70e..644bb599eee6 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -805,7 +805,7 @@ static int intel_fbc_alloc_cfb(struct intel_fbc *fbc,
err_llb:
i915_gem_object_put(fetch_and_zero(&fbc->compressed_llb));
err:
- if (drm_mm_initialized(&i915->mm.stolen))
+ if (IS_ERR(obj) && (PTR_ERR(obj) == -ENOMEM || PTR_ERR(obj) == -ENXIO))
drm_info_once(&i915->drm, "not enough stolen space for
compressed buffer (need %d more bytes), disabling. Hint: you may be able to
increase stolen memory size in the BIOS to avoid this.\n", size);
return -ENOSPC;
}
@@ -1708,7 +1708,7 @@ void intel_fbc_init(struct drm_i915_private *i915)
{
enum intel_fbc_id fbc_id;
- if (!drm_mm_initialized(&i915->mm.stolen))
+ if (!i915->mm.stolen_region)
mkwrite_device_info(i915)->display.fbc_mask = 0;
if (need_fbc_vtd_wa(i915))
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index e58f9902ef47..930521a84607 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -347,8 +347,6 @@ static int i915_gem_init_stolen(struct intel_memory_region
*mem)
resource_size_t reserved_base, stolen_top;
resource_size_t reserved_total, reserved_size;
- mutex_init(&i915->mm.stolen_lock);
-
if (intel_vgpu_active(i915)) {
drm_notice(&i915->drm,
"%s, disabling use of stolen memory\n",
diff --git a/drivers/gpu/drm/i915/gt/selftest_reset.c
b/drivers/gpu/drm/i915/gt/selftest_reset.c
index 37c38bdd5f47..ad2ecc582be2 100644
--- a/drivers/gpu/drm/i915/gt/selftest_reset.c
+++ b/drivers/gpu/drm/i915/gt/selftest_reset.c
@@ -6,6 +6,7 @@
#include
#include "gem/i915_gem_stolen.h"
+#include "intel_region_ttm.h"
#include "i915_memcpy.h"
#include "i915_selftest.h"
@@ -83,6 +84,7 @@ __igt_reset_stolen(struct intel_gt *gt,
dma_addr_t dma = (dma_addr_t)dsm->start + (page << PAGE_SHIFT);
void __iomem *s;
void *in;
+ bool busy;
ggtt->vm.insert_page(&ggtt->vm, dma,
ggtt->error_capture.start,
@@ -93,9 +95,9 @@ __igt_reset_stolen(struct intel_gt *gt,
ggtt->error_capture.start,
PAGE_SIZE);
- if (!__drm_mm_interval_first(>->i915->mm.stolen,
-page << PAGE_SHIFT,
-((page + 1) << PAGE_SHIFT) - 1))
+ busy = intel_region_ttm_range_busy(gt->i915->mm.stolen_region,
+ PFN_PHYS(page),
PFN_PHYS(page + 1) - 1);
+ if (!busy)
memset_io(s, STACK_MAGIC, PAGE_SIZE);
in = (void __force *)s;
@@ -124,6 +126,7 @@ __igt_reset_stolen(struct intel_gt *gt,
void __iomem *s;
void *in;
u32 x;
+ bool busy;
ggtt->vm.insert_page(&ggtt->vm, dma,
ggtt->error_capture.start,
@@ -139,10 +142,9 @@ __igt_reset_stolen(struct intel_gt *gt,
in = tmp;
x = crc32_le(0, in, PAGE_SIZE);
- if (x != crc[page] &&
- !__drm_mm_interval_first(>->i915->mm.stolen,
-page << PAGE_SHIFT,
-((page + 1) << PAGE_SHIFT) - 1)) {
+ busy = intel_region_ttm_range_busy(gt->i915->mm.stolen_region,
+ PFN_PHYS(page),
PFN_PHYS(page + 1) - 1);
+ if (x != crc[page] && !busy) {
pr_debug("unused stolen page %pa modified by GPU
reset\n",
&page);
if (count++ == 0)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d622d1afe93..1f9fa2d6d198 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -247,11 +247,6 @@ struct i915_gem_mm {
* support stolen.
*/
struct intel_memory_region *stolen_region;
- /** Memory allocator for GTT stolen memory */
- struct drm_mm stolen;
- /** Protects the usa
[RFC PATCH 6/7] drm/i915: add range busy check for ttm region
RFC: should this become a generic interface in intel_memory_region_ops?
RFC: would we prefer an different interface? e.g. for_each_obj_in_range
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_region_ttm.c | 19 +++
drivers/gpu/drm/i915/intel_region_ttm.h | 3 +++
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index bb564b830c96..2ccefa76348f 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -256,3 +256,22 @@ void intel_region_ttm_resource_free(struct
intel_memory_region *mem,
man->func->free(man, res);
}
+
+/**
+ * intel_region_ttm_range_busy - check whether range has any allocations
+ * @mem: The region to check
+ * @start: the start of the range to check
+ * @end: the end of the range to check
+ *
+ * Return: true if something is alloceted within the region, false otherwise.
+ */
+bool intel_region_ttm_range_busy(struct intel_memory_region *mem,
+u64 start, u64 end)
+{
+ struct ttm_resource_manager *man = mem->region_private;
+
+ /* currently only supported for range allocator */
+ GEM_BUG_ON(!mem->is_range_manager);
+
+ return ttm_range_man_range_busy(man, PFN_DOWN(start), PFN_UP(end));
+}
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.h
b/drivers/gpu/drm/i915/intel_region_ttm.h
index fdee5e7bd46c..670ba9b618f7 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.h
+++ b/drivers/gpu/drm/i915/intel_region_ttm.h
@@ -29,6 +29,9 @@ intel_region_ttm_resource_to_rsgt(struct intel_memory_region
*mem,
void intel_region_ttm_resource_free(struct intel_memory_region *mem,
struct ttm_resource *res);
+bool intel_region_ttm_range_busy(struct intel_memory_region *mem,
+u64 start, u64 end);
+
int intel_region_to_ttm_type(const struct intel_memory_region *mem);
struct ttm_device_funcs *i915_ttm_driver(void);
--
2.25.1
Re: [PATCH 05/22] drm/radeon: Use drm_mode_copy()
Applied. Thanks!
Alex
On Fri, Feb 18, 2022 at 5:04 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> struct drm_display_mode embeds a list head, so overwriting
> the full struct with another one will corrupt the list
> (if the destination mode is on a list). Use drm_mode_copy()
> instead which explicitly preserves the list head of
> the destination mode.
>
> Even if we know the destination mode is not on any list
> using drm_mode_copy() seems decent as it sets a good
> example. Bad examples of not using it might eventually
> get copied into code where preserving the list head
> actually matters.
>
> Obviously one case not covered here is when the mode
> itself is embedded in a larger structure and the whole
> structure is copied. But if we are careful when copying
> into modes embedded in structures I think we can be a
> little more reassured that bogus list heads haven't been
> propagated in.
>
> @is_mode_copy@
> @@
> drm_mode_copy(...)
> {
> ...
> }
>
> @depends on !is_mode_copy@
> struct drm_display_mode *mode;
> expression E, S;
> @@
> (
> - *mode = E
> + drm_mode_copy(mode, &E)
> |
> - memcpy(mode, E, S)
> + drm_mode_copy(mode, E)
> )
>
> @depends on !is_mode_copy@
> struct drm_display_mode mode;
> expression E;
> @@
> (
> - mode = E
> + drm_mode_copy(&mode, &E)
> |
> - memcpy(&mode, E, S)
> + drm_mode_copy(&mode, E)
> )
>
> @@
> struct drm_display_mode *mode;
> @@
> - &*mode
> + mode
>
> Cc: Alex Deucher
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index a7925a8290b2..0cb1345c6ba4 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -777,7 +777,7 @@ static void radeon_fixup_lvds_native_mode(struct
> drm_encoder *encoder,
> if (mode->type & DRM_MODE_TYPE_PREFERRED) {
> if (mode->hdisplay != native_mode->hdisplay ||
> mode->vdisplay != native_mode->vdisplay)
> - memcpy(native_mode, mode, sizeof(*mode));
> + drm_mode_copy(native_mode, mode);
> }
> }
>
> @@ -786,7 +786,7 @@ static void radeon_fixup_lvds_native_mode(struct
> drm_encoder *encoder,
> list_for_each_entry_safe(mode, t, &connector->probed_modes,
> head) {
> if (mode->hdisplay == native_mode->hdisplay &&
> mode->vdisplay == native_mode->vdisplay) {
> - *native_mode = *mode;
> + drm_mode_copy(native_mode, mode);
> drm_mode_set_crtcinfo(native_mode,
> CRTC_INTERLACE_HALVE_V);
> DRM_DEBUG_KMS("Determined LVDS native mode
> details from EDID\n");
> break;
> --
> 2.34.1
>
Re: [PATCH 04/22] drm/amdgpu: Use drm_mode_copy()
Applied. Thanks!
Alex
On Fri, Feb 18, 2022 at 11:32 AM Harry Wentland wrote:
>
>
>
> On 2022-02-18 05:03, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > struct drm_display_mode embeds a list head, so overwriting
> > the full struct with another one will corrupt the list
> > (if the destination mode is on a list). Use drm_mode_copy()
> > instead which explicitly preserves the list head of
> > the destination mode.
> >
> > Even if we know the destination mode is not on any list
> > using drm_mode_copy() seems decent as it sets a good
> > example. Bad examples of not using it might eventually
> > get copied into code where preserving the list head
> > actually matters.
> >
> > Obviously one case not covered here is when the mode
> > itself is embedded in a larger structure and the whole
> > structure is copied. But if we are careful when copying
> > into modes embedded in structures I think we can be a
> > little more reassured that bogus list heads haven't been
> > propagated in.
> >
> > @is_mode_copy@
> > @@
> > drm_mode_copy(...)
> > {
> > ...
> > }
> >
> > @depends on !is_mode_copy@
> > struct drm_display_mode *mode;
> > expression E, S;
> > @@
> > (
> > - *mode = E
> > + drm_mode_copy(mode, &E)
> > |
> > - memcpy(mode, E, S)
> > + drm_mode_copy(mode, E)
> > )
> >
> > @depends on !is_mode_copy@
> > struct drm_display_mode mode;
> > expression E;
> > @@
> > (
> > - mode = E
> > + drm_mode_copy(&mode, &E)
> > |
> > - memcpy(&mode, E, S)
> > + drm_mode_copy(&mode, E)
> > )
> >
> > @@
> > struct drm_display_mode *mode;
> > @@
> > - &*mode
> > + mode
> >
> > Cc: Alex Deucher
> > Cc: Harry Wentland
> > Cc: Leo Li
> > Cc: Rodrigo Siqueira
> > Cc: amd-...@lists.freedesktop.org
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c| 4 ++--
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++---
> > 2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > index fa20261aa928..673078faa27a 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > @@ -626,7 +626,7 @@ amdgpu_connector_fixup_lcd_native_mode(struct
> > drm_encoder *encoder,
> > if (mode->type & DRM_MODE_TYPE_PREFERRED) {
> > if (mode->hdisplay != native_mode->hdisplay ||
> > mode->vdisplay != native_mode->vdisplay)
> > - memcpy(native_mode, mode, sizeof(*mode));
> > + drm_mode_copy(native_mode, mode);
> > }
> > }
> >
> > @@ -635,7 +635,7 @@ amdgpu_connector_fixup_lcd_native_mode(struct
> > drm_encoder *encoder,
> > list_for_each_entry_safe(mode, t, &connector->probed_modes,
> > head) {
> > if (mode->hdisplay == native_mode->hdisplay &&
> > mode->vdisplay == native_mode->vdisplay) {
> > - *native_mode = *mode;
> > + drm_mode_copy(native_mode, mode);
> > drm_mode_set_crtcinfo(native_mode,
> > CRTC_INTERLACE_HALVE_V);
> > DRM_DEBUG_KMS("Determined LVDS native mode
> > details from EDID\n");
> > break;
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index bd23c9e481eb..514280699ad5 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -6318,7 +6318,7 @@ get_highest_refresh_rate_mode(struct
> > amdgpu_dm_connector *aconnector,
> > }
> > }
> >
> > - aconnector->freesync_vid_base = *m_pref;
> > + drm_mode_copy(&aconnector->freesync_vid_base, m_pref);
> > return m_pref;
> > }
> >
> > @@ -6432,8 +6432,8 @@ create_stream_for_sink(struct amdgpu_dm_connector
> > *aconnector,
> > recalculate_timing = is_freesync_video_mode(&mode,
> > aconnector);
> > if (recalculate_timing) {
> > freesync_mode =
> > get_highest_refresh_rate_mode(aconnector, false);
> > - saved_mode = mode;
> > - mode = *freesync_mode;
> > + drm_mode_copy(&saved_mode, &mode);
> > + drm_mode_copy(&mode, freesync_mode);
> > } else {
> > decide_crtc_timing_for_drm_display_mode(
> > &mode, preferred_mode, scale);
>
Re: [PATCH 00/22] drm: Review of mode copies
On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä wrote: > > On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville Syrjala wrote: > > drm: Add drm_mode_init() > > drm/bridge: Use drm_mode_copy() > > drm/imx: Use drm_mode_duplicate() > > drm/panel: Use drm_mode_duplicate() > > drm/vc4: Use drm_mode_copy() > These have been pushed to drm-misc-next. > > > drm/amdgpu: Remove pointless on stack mode copies > > drm/amdgpu: Use drm_mode_init() for on-stack modes > > drm/amdgpu: Use drm_mode_copy() > amdgpu ones are reviewed, but I'll leave them for the > AMD folks to push to whichever tree they prefer. I pulled patches 2, 4, 5 into my tree. For 3, I'm happy to have it land via drm-misc with the rest of the mode_init changes if you'd prefer. Alex Alex > > > The rest are still in need of review: > > drm/radeon: Use drm_mode_copy() > > drm/gma500: Use drm_mode_copy() > > drm/hisilicon: Use drm_mode_init() for on-stack modes > > drm/msm: Nuke weird on stack mode copy > > drm/msm: Use drm_mode_init() for on-stack modes > > drm/msm: Use drm_mode_copy() > > drm/mtk: Use drm_mode_init() for on-stack modes > > drm/rockchip: Use drm_mode_copy() > > drm/sti: Use drm_mode_copy() > > drm/tilcdc: Use drm_mode_copy() > > drm/i915: Use drm_mode_init() for on-stack modes > > drm/i915: Use drm_mode_copy() > > drm: Use drm_mode_init() for on-stack modes > > drm: Use drm_mode_copy() > > -- > Ville Syrjälä > Intel
Re: [PATCH 6/9] drm/fb-helper: Provide callback to create fbdev dumb buffers
Hi Javier
Am 08.03.22 um 18:51 schrieb Javier Martinez Canillas:
[...]
static struct drm_client_buffer *
-drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 height,
u32 format)
+drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 height,
u32 format,
+bool fbdev)
{
const struct drm_format_info *info = drm_format_info(format);
struct drm_mode_create_dumb dumb_args = { };
@@ -265,7 +266,10 @@ drm_client_buffer_create(struct drm_client_dev *client,
u32 width, u32 height, u
dumb_args.width = width;
dumb_args.height = height;
dumb_args.bpp = info->cpp[0] * 8;
- ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
+ if (fbdev)
Maybe if (defined(CONFIG_DRM_FBDEV_EMULATION) && fbdev) ?
+ ret = drm_mode_create_dumb_fbdev(dev, &dumb_args, client->file);
And drm_mode_create_dumb_fbdev() could just be made a stub if
CONFIG_DRM_FBDEV_EMULATION isn't enabled.
While going through these commits again, I decided to change the logic
to use a function pointer for the allocation. The fbdev emulation will
provide an implementation that allocates the buffer object. The logic
for picking the correct create-dumb function will be placed there.
Although it probably won't ever be needed, other clients could allocate
buffers with other constraints, or even support acceleration instead of
dumb buffers.
You may want to take another look at this patch in the patchset's next
iteration.
Best regards
Thomas
I believe the only usage of the DRM client API currently is the fbdev
emulation layer anyways? But still makes sense I think to condtionally
compile that since drm_client.o is built in the drm.ko module and the
drm_fb_helper.o only included if fbdev emulation has been enabled.
+ else
+ ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
if (ret)
goto err_delete;
@@ -402,6 +406,7 @@ static int drm_client_buffer_addfb(struct drm_client_buffer *buffer,
* @width: Framebuffer width
* @height: Framebuffer height
* @format: Buffer format
+ * @fbdev: True if the client provides an fbdev device, or false otherwise
*
An emulated fbdev device ?
Other than those small nit,
Reviewed-by: Javier Martinez Canillas
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
[PATCH] drm/amdgpu: Fix spelling mistake "regiser" -> "register"
There is a spelling mistake in a dev_error error message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index a025f080aa6a..9aa355a5ac3c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -919,7 +919,7 @@ static u32 amdgpu_virt_rlcg_reg_rw(struct amdgpu_device
*adev, u32 offset, u32 v
"wrong operation type, rlcg
failed to program reg: 0x%05x\n", offset);
} else if (tmp & AMDGPU_RLCG_REG_NOT_IN_RANGE) {
dev_err(adev->dev,
- "regiser is not in range, rlcg
failed to program reg: 0x%05x\n", offset);
+ "register is not in range, rlcg
failed to program reg: 0x%05x\n", offset);
} else {
dev_err(adev->dev,
"unknown error type, rlcg
failed to program reg: 0x%05x\n", offset);
--
2.35.1
Re: [PATCH v4 2/4] drm/panel: Add panel driver for NewVision NV3052C based LCDs
Hi Christophe,
On Fri, Mar 11, 2022 at 06:02:38PM +0100, Christophe Branchereau wrote:
> This driver supports the NewVision NV3052C based LCDs. Right now, it
> only supports the LeadTek LTK035C5444T 2.4" 640x480 TFT LCD panel, which
> can be found in the Anbernic RG-350M handheld console.
I had to get away from my day-time job and you were the lucky winner.
A couple of comments in the following that you can address now or later.
>
> Signed-off-by: Christophe Branchereau
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/panel/Kconfig | 9 +
> drivers/gpu/drm/panel/Makefile| 1 +
> .../gpu/drm/panel/panel-newvision-nv3052c.c | 497 ++
> 3 files changed, 507 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-newvision-nv3052c.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index bb2e47229c68..40084f709789 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -283,6 +283,15 @@ config DRM_PANEL_NEC_NL8048HL11
> panel (found on the Zoom2/3/3630 SDP boards). To compile this driver
> as a module, choose M here.
>
> +config DRM_PANEL_NEWVISION_NV3052C
> + tristate "NewVision NV3052C RGB/SPI panel"
> + depends on OF && SPI
> + depends on BACKLIGHT_CLASS_DEVICE
> + select DRM_MIPI_DBI
> + help
> + Say Y here if you want to enable support for the panels built
> + around the NewVision NV3052C display controller.
> +
> config DRM_PANEL_NOVATEK_NT35510
> tristate "Novatek NT35510 RGB panel driver"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 5740911f637c..42a7ab54234b 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) +=
> panel-leadtek-ltk500hd1829.o
> obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
> obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
> +obj-$(CONFIG_DRM_PANEL_NEWVISION_NV3052C) += panel-newvision-nv3052c.o
> obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
> obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35560) += panel-novatek-nt35560.o
> obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35950) += panel-novatek-nt35950.o
> diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
> b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
> new file mode 100644
> index ..fc31df0dee12
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
> @@ -0,0 +1,497 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * NevVision NV3052C IPS LCD panel driver
> + *
> + * Copyright (C) 2020, Paul Cercueil
> + * Copyright (C) 2022, Christophe Branchereau
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +struct nv3052c_panel_info {
> + const struct drm_display_mode *display_modes;
> + unsigned int num_modes;
> + u16 width_mm, height_mm;
> + u32 bus_format, bus_flags;
> +};
> +
> +struct nv3052c {
> + struct device *dev;
> + struct drm_panel panel;
> + struct mipi_dbi dbi;
> +
> + const struct nv3052c_panel_info *panel_info;
> +
> + struct regulator *supply;
> + struct gpio_desc *reset_gpio;
> +};
> +
> +struct nv3052c_reg {
> + u8 cmd;
> + u8 val;
> +};
> +
> +static const struct nv3052c_reg nv3052c_panel_regs[] = {
> + { 0xff, 0x30 },
> + { 0xff, 0x52 },
> + { 0xff, 0x01 },
> + { 0xe3, 0x00 },
> + { 0x40, 0x00 },
> + { 0x03, 0x40 },
> + { 0x04, 0x00 },
> + { 0x05, 0x03 },
> + { 0x08, 0x00 },
> + { 0x09, 0x07 },
> + { 0x0a, 0x01 },
> + { 0x0b, 0x32 },
> + { 0x0c, 0x32 },
> + { 0x0d, 0x0b },
> + { 0x0e, 0x00 },
> + { 0x23, 0xa0 },
> +
> + { 0x24, 0x0c },
> + { 0x25, 0x06 },
> + { 0x26, 0x14 },
> + { 0x27, 0x14 },
> +
> + { 0x38, 0xcc },
> + { 0x39, 0xd7 },
> + { 0x3a, 0x4a },
> +
> + { 0x28, 0x40 },
> + { 0x29, 0x01 },
> + { 0x2a, 0xdf },
> + { 0x49, 0x3c },
> + { 0x91, 0x77 },
> + { 0x92, 0x77 },
> + { 0xa0, 0x55 },
> + { 0xa1, 0x50 },
> + { 0xa4, 0x9c },
> + { 0xa7, 0x02 },
> + { 0xa8, 0x01 },
> + { 0xa9, 0x01 },
> + { 0xaa, 0xfc },
> + { 0xab, 0x28 },
> + { 0xac, 0x06 },
> + { 0xad, 0x06 },
> + { 0xae, 0x06 },
> + { 0xaf, 0x03 },
> + { 0xb0, 0x08 },
> + { 0xb1, 0x26 },
> + { 0xb2, 0x28 },
> + { 0xb3, 0x28 },
> + { 0xb4, 0x33 },
> + { 0xb5, 0x08 },
> + { 0xb6, 0x26 },
> + { 0xb7, 0x08 },
> + { 0xb8, 0x26 },
> + { 0xf0, 0x00 },
> + { 0xf6, 0xc0 },
> +
> + { 0xff, 0x30 },
> + { 0xff, 0x52 },
> + { 0xff, 0x02 },
> + { 0xb0, 0x0b },
> + { 0xb1, 0x16 },
> + { 0
Re: [PATCH] drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERS
On Tue, Mar 15, 2022 at 09:45:59AM +0100, Thomas Zimmermann wrote:
> Fix a number of undefined references to drm_kms_helper.ko in
> drm_dp_helper.ko:
>
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_mst_duplicate_state':
> drm_dp_mst_topology.c:(.text+0x2df0): undefined reference to
> `__drm_atomic_helper_private_obj_duplicate_state'
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_delayed_destroy_work':
> drm_dp_mst_topology.c:(.text+0x370c): undefined reference to
> `drm_kms_helper_hotplug_event'
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_mst_up_req_work':
> drm_dp_mst_topology.c:(.text+0x7938): undefined reference to
> `drm_kms_helper_hotplug_event'
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_mst_link_probe_work':
> drm_dp_mst_topology.c:(.text+0x82e0): undefined reference to
> `drm_kms_helper_hotplug_event'
>
> This happens if panel-edp.ko has been configured with
>
> DRM_PANEL_EDP=y
> DRM_DP_HELPER=y
> DRM_KMS_HELPER=m
>
> which builds DP helpers into the kernel and KMS helpers sa a module.
> Making DRM_PANEL_EDP select DRM_KMS_HELPER resolves this problem.
>
> To avoid a resulting cyclic dependency with DRM_PANEL_BRIDGE, don't
> make the latter depend on DRM_KMS_HELPER and fix the one DRM bridge
> drivers that doesn't already select DRM_KMS_HELPER. As KMS helpers
> cannot be selected directly by the user, config symbols should avoid
> depending on it anyway.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 3755d35ee1d2 ("drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP")
> Reported-by: kernel test robot
> Cc: Thomas Zimmermann
> Cc: Naresh Kamboju
> Cc: Linux Kernel Functional Testing
> Cc: Lyude Paul
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: dri-devel@lists.freedesktop.org
> Cc: Dave Airlie
> Cc: Thierry Reding
Acked-by: Sam Ravnborg
[PATCH] drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"
There is a spelling mistake in a gvt_vgpu_err error message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 520a7e1942f3..a01e3a893e24 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -914,7 +914,7 @@ static int update_fdi_rx_iir_status(struct intel_vgpu *vgpu,
else if (FDI_RX_IMR_TO_PIPE(offset) != INVALID_INDEX)
index = FDI_RX_IMR_TO_PIPE(offset);
else {
- gvt_vgpu_err("Unsupport registers %x\n", offset);
+ gvt_vgpu_err("Unsupported registers %x\n", offset);
return -EINVAL;
}
--
2.35.1
[PATCH] drm/nouveau: Fix spelling mistake "endianess" -> "endianness"
There is a spelling mistake in a nvdev_error error message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 88d262ba648c..62efbd0f3846 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -2935,7 +2935,7 @@ nvkm_device_ctor(const struct nvkm_device_func *func,
/* switch mmio to cpu's native endianness */
if (!nvkm_device_endianness(device)) {
nvdev_error(device,
- "Couldn't switch GPU to CPUs endianess\n");
+ "Couldn't switch GPU to CPUs endianness\n");
ret = -ENOSYS;
goto done;
}
--
2.35.1
[PATCH v2 0/6] Allow drm_writeback_connector to accept pointer to drm_encoder
There are some vendor drivers for which the writeback encoder shares hardware resources such as clocks and interrupts with the rest of the display pipeline. In addition, there can be use-cases where the writeback encoder could be a shared encoder between the physical display path and the writeback path. To accommodate for such cases, change the drm_writeback_connector to accept a pointer to drm_encoder. For existing users of drm_writeback_connector there will not be any change in functionality due to this change. This approach was first posted by Suraj Kandpal here [1] for both encoder and connector. But after discussions [2], the consensus was reached to split this change for the drm_encoder first and the drm_connector part can be reworked in a subsequent change later. Validation of this change was done using igt_writeback tests on MSM based RB5 board using the changes posted here [3]. For all other chipsets, these changes were compile-tested. [1] https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/ [2] https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/ [3] https://patchwork.freedesktop.org/series/99724/ changes in v2: - introduce a new API drm_writeback_connector_init_with_encoder() - allow passing possible_crtcs for existing users of drm_writeback_connector_init() Abhinav Kumar (6): drm: allow real encoder to be passed for drm_writeback_connector drm/komeda: pass possible_crtcs as parameter for drm_writeback_connector drm/vkms: pass possible_crtcs as parameter for drm_writeback_connector drm/vc4: change vc4 driver to use drm_writeback_connector_init_with_encoder() drm/rcar_du: pass possible_crtcs as parameter for drm_writeback_connector drm/malidp: pass possible_crtcs as parameter for drm_writeback_connector .../drm/arm/display/komeda/komeda_wb_connector.c | 3 +- drivers/gpu/drm/arm/malidp_mw.c| 5 +- drivers/gpu/drm/drm_writeback.c| 144 +++-- drivers/gpu/drm/rcar-du/rcar_du_writeback.c| 5 +- drivers/gpu/drm/vc4/vc4_txp.c | 30 - drivers/gpu/drm/vkms/vkms_writeback.c | 3 +- include/drm/drm_writeback.h| 27 +++- 7 files changed, 161 insertions(+), 56 deletions(-) -- 2.7.4
[PATCH v2 2/6] drm/komeda: pass possible_crtcs as parameter for drm_writeback_connector
As part of this series, drm_writeback_connector_init() allows
passing possible_crtcs as a parameter so that the API can
internally create and setup the encoder.
Pass possible_crtcs parameter for drm_writeback_connector_init()
for komeda driver.
changes in v2:
- pass possible_crtcs parameter for drm_writeback_connector_init()
Co-developed-by: Kandpal Suraj
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index e465cc4..40774e6 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -155,7 +155,6 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
*kms,
kwb_conn->wb_layer = kcrtc->master->wb_layer;
wb_conn = &kwb_conn->base;
- wb_conn->encoder.possible_crtcs = BIT(drm_crtc_index(&kcrtc->base));
formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl,
kwb_conn->wb_layer->layer_type,
@@ -164,7 +163,7 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
*kms,
err = drm_writeback_connector_init(&kms->base, wb_conn,
&komeda_wb_connector_funcs,
&komeda_wb_encoder_helper_funcs,
- formats, n_formats);
+ formats, n_formats,
BIT(drm_crtc_index(&kcrtc->base)));
komeda_put_fourcc_list(formats);
if (err) {
kfree(kwb_conn);
--
2.7.4
[PATCH v2 1/6] drm: allow real encoder to be passed for drm_writeback_connector
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware, allow
real encoder to be passed for drm_writeback_connector using a new
drm_writeback_connector_init_with_encoder() API.
In addition, to preserve the same call flows for the existing
users of drm_writeback_connector_init(), also allow passing
possible_crtcs as a parameter so that encoder can be initialized
with it.
changes in v2:
- introduce a new API drm_writeback_connector_init_with_encoder()
- allow passing possible_crtcs for existing users of
drm_writeback_connector_init()
Co-developed-by: Kandpal Suraj
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/drm_writeback.c | 144 +---
include/drm/drm_writeback.h | 27 +++-
2 files changed, 129 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504..9277dcb 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -149,36 +149,15 @@ static const struct drm_encoder_funcs
drm_writeback_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
-/**
- * drm_writeback_connector_init - Initialize a writeback connector and its
properties
- * @dev: DRM device
- * @wb_connector: Writeback connector to initialize
- * @con_funcs: Connector funcs vtable
- * @enc_helper_funcs: Encoder helper funcs vtable to be used by the internal
encoder
- * @formats: Array of supported pixel formats for the writeback engine
- * @n_formats: Length of the formats array
- *
- * This function creates the writeback-connector-specific properties if they
- * have not been already created, initializes the connector as
- * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the property
- * values. It will also create an internal encoder associated with the
- * drm_writeback_connector and set it to use the @enc_helper_funcs vtable for
- * the encoder helper.
- *
- * Drivers should always use this function instead of drm_connector_init() to
- * set up writeback connectors.
- *
- * Returns: 0 on success, or a negative error code
- */
-int drm_writeback_connector_init(struct drm_device *dev,
-struct drm_writeback_connector *wb_connector,
-const struct drm_connector_funcs *con_funcs,
-const struct drm_encoder_helper_funcs
*enc_helper_funcs,
-const u32 *formats, int n_formats)
+static int drm_writeback_connector_setup(struct drm_device *dev,
+ struct drm_writeback_connector *wb_connector,
+ const struct drm_connector_funcs *con_funcs, const u32 *formats,
+ int n_formats)
{
struct drm_property_blob *blob;
- struct drm_connector *connector = &wb_connector->base;
struct drm_mode_config *config = &dev->mode_config;
+ struct drm_connector *connector = &wb_connector->base;
+
int ret = create_writeback_properties(dev);
if (ret != 0)
@@ -186,15 +165,10 @@ int drm_writeback_connector_init(struct drm_device *dev,
blob = drm_property_create_blob(dev, n_formats * sizeof(*formats),
formats);
- if (IS_ERR(blob))
- return PTR_ERR(blob);
-
- drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
- ret = drm_encoder_init(dev, &wb_connector->encoder,
- &drm_writeback_encoder_funcs,
- DRM_MODE_ENCODER_VIRTUAL, NULL);
- if (ret)
- goto fail;
+ if (IS_ERR(blob)) {
+ ret = PTR_ERR(blob);
+ return ret;
+ }
connector->interlace_allowed = 0;
@@ -204,7 +178,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
goto connector_fail;
ret = drm_connector_attach_encoder(connector,
- &wb_connector->encoder);
+ wb_connector->encoder);
if (ret)
goto attach_fail;
@@ -233,13 +207,105 @@ int drm_writeback_connector_init(struct drm_device *dev,
attach_fail:
drm_connector_cleanup(connector);
connector_fail:
- drm_encoder_cleanup(&wb_connector->encoder);
-fail:
drm_property_blob_put(blob);
return ret;
}
+
+/**
+ * drm_writeback_connector_init - Initialize a writeback connector and its
properties
+ * using an internal encoder
+ *
+ * @dev: DRM device
+ * @wb_connector: Writeback connector to initialize
+ * @con_funcs: Connector funcs vtable
+ * @enc_helper_funcs: Encoder helper funcs vtable to be used by the internal
encoder
+ * @formats: Array o
[PATCH v2 3/6] drm/vkms: pass possible_crtcs as parameter for drm_writeback_connector
As part of this series, drm_writeback_connector_init() allows
passing possible_crtcs as a parameter so that the API can
internally create and setup the encoder.
Pass possible_crtcs parameter for drm_writeback_connector_init()
for vkms driver.
changes in v2:
- pass possible_crtcs parameter for drm_writeback_connector_init()
Co-developed-by: Kandpal Suraj
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/vkms/vkms_writeback.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
b/drivers/gpu/drm/vkms/vkms_writeback.c
index 8694227..381e7b7 100644
--- a/drivers/gpu/drm/vkms/vkms_writeback.c
+++ b/drivers/gpu/drm/vkms/vkms_writeback.c
@@ -140,12 +140,11 @@ int vkms_enable_writeback_connector(struct vkms_device
*vkmsdev)
{
struct drm_writeback_connector *wb = &vkmsdev->output.wb_connector;
- vkmsdev->output.wb_connector.encoder.possible_crtcs = 1;
drm_connector_helper_add(&wb->base, &vkms_wb_conn_helper_funcs);
return drm_writeback_connector_init(&vkmsdev->drm, wb,
&vkms_wb_connector_funcs,
&vkms_wb_encoder_helper_funcs,
vkms_wb_formats,
- ARRAY_SIZE(vkms_wb_formats));
+ ARRAY_SIZE(vkms_wb_formats), 1);
}
--
2.7.4
[PATCH v2 6/6] drm/malidp: pass possible_crtcs as parameter for drm_writeback_connector
As part of this series, drm_writeback_connector_init() allows passing possible_crtcs as a parameter so that the API can internally create and setup the encoder. Pass possible_crtcs parameter for drm_writeback_connector_init() for malidp writeback driver. changes in v2: - pass possible_crtcs parameter for drm_writeback_connector_init() Co-developed-by: Kandpal Suraj Signed-off-by: Abhinav Kumar --- drivers/gpu/drm/arm/malidp_mw.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c index f5847a7..b882066 100644 --- a/drivers/gpu/drm/arm/malidp_mw.c +++ b/drivers/gpu/drm/arm/malidp_mw.c @@ -208,11 +208,12 @@ int malidp_mw_connector_init(struct drm_device *drm) struct malidp_drm *malidp = drm->dev_private; u32 *formats; int ret, n_formats; + uint32_t possible_crtcs; if (!malidp->dev->hw->enable_memwrite) return 0; - malidp->mw_connector.encoder.possible_crtcs = 1 << drm_crtc_index(&malidp->crtc); + possible_crtcs = 1 << drm_crtc_index(&malidp->crtc); drm_connector_helper_add(&malidp->mw_connector.base, &malidp_mw_connector_helper_funcs); @@ -223,7 +224,7 @@ int malidp_mw_connector_init(struct drm_device *drm) ret = drm_writeback_connector_init(drm, &malidp->mw_connector, &malidp_mw_connector_funcs, &malidp_mw_encoder_helper_funcs, - formats, n_formats); + formats, n_formats, possible_crtcs); kfree(formats); if (ret) return ret; -- 2.7.4
[PATCH v2 5/6] drm/rcar_du: pass possible_crtcs as parameter for drm_writeback_connector
As part of this series, drm_writeback_connector_init() allows
passing possible_crtcs as a parameter so that the API can
internally create and setup the encoder.
Pass possible_crtcs parameter for drm_writeback_connector_init()
for rcar-du writeback driver.
changes in v2:
- pass possible_crtcs parameter for drm_writeback_connector_init()
Co-developed-by: Kandpal Suraj
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
index c79d125..1a610c0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
@@ -199,8 +199,9 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
struct rcar_du_crtc *rcrtc)
{
struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
+ uint32_t possible_crtcs;
- wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
+ possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
drm_connector_helper_add(&wb_conn->base,
&rcar_du_wb_conn_helper_funcs);
@@ -208,7 +209,7 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
&rcar_du_wb_conn_funcs,
&rcar_du_wb_enc_helper_funcs,
writeback_formats,
- ARRAY_SIZE(writeback_formats));
+ ARRAY_SIZE(writeback_formats),
possible_crtcs);
}
void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
--
2.7.4
[PATCH v2 4/6] drm/vc4: change vc4 driver to use drm_writeback_connector_init_with_encoder()
vc4 driver currently embeds the drm_encoder into struct vc4_txp
and later on uses container_of to retrieve the vc4_txp from
the drm_encoder.
Since drm_encoder has now been made a pointer inside
drm_writeback_connector, make vc4 driver use the new API
so that the embedded encoder model can be retained in the
driver and there is no change in functionality.
changes in v2:
- make vc4 driver use drm_writeback_connector_init_with_encoder()
Co-developed-by: Kandpal Suraj
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/vc4/vc4_txp.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index 9809ca3..b09440d 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -151,6 +151,8 @@ struct vc4_txp {
struct platform_device *pdev;
+ struct drm_encoder drm_enc;
+
struct drm_writeback_connector connector;
void __iomem *regs;
@@ -159,7 +161,7 @@ struct vc4_txp {
static inline struct vc4_txp *encoder_to_vc4_txp(struct drm_encoder *encoder)
{
- return container_of(encoder, struct vc4_txp, connector.encoder);
+ return container_of(encoder, struct vc4_txp, drm_enc);
}
static inline struct vc4_txp *connector_to_vc4_txp(struct drm_connector *conn)
@@ -368,6 +370,10 @@ static const struct drm_encoder_helper_funcs
vc4_txp_encoder_helper_funcs = {
.disable = vc4_txp_encoder_disable,
};
+static const struct drm_encoder_funcs vc4_txp_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static int vc4_txp_enable_vblank(struct drm_crtc *crtc)
{
return 0;
@@ -467,6 +473,7 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
struct vc4_txp *txp;
struct drm_crtc *crtc;
struct drm_encoder *encoder;
+ struct drm_writeback_connector *wb_conn;
int ret, irq;
irq = platform_get_irq(pdev, 0);
@@ -492,21 +499,32 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
txp->regset.regs = txp_regs;
txp->regset.nregs = ARRAY_SIZE(txp_regs);
- drm_connector_helper_add(&txp->connector.base,
+ wb_conn = &txp->connector;
+ wb_conn->encoder = &txp->drm_enc;
+ drm_encoder_helper_add(wb_conn->encoder, &vc4_txp_encoder_helper_funcs);
+
+ ret = drm_encoder_init(drm, wb_conn->encoder,
+ &vc4_txp_encoder_funcs,
+ DRM_MODE_ENCODER_VIRTUAL, NULL);
+ if (ret)
+ return ret;
+
+ drm_connector_helper_add(&wb_conn->base,
&vc4_txp_connector_helper_funcs);
- ret = drm_writeback_connector_init(drm, &txp->connector,
+ ret = drm_writeback_connector_init_with_encoder(drm, wb_conn,
&vc4_txp_connector_funcs,
- &vc4_txp_encoder_helper_funcs,
drm_fmts, ARRAY_SIZE(drm_fmts));
- if (ret)
+ if (ret) {
+ drm_encoder_cleanup(wb_conn->encoder);
return ret;
+ }
ret = vc4_crtc_init(drm, vc4_crtc,
&vc4_txp_crtc_funcs, &vc4_txp_crtc_helper_funcs);
if (ret)
return ret;
- encoder = &txp->connector.encoder;
+ encoder = txp->connector.encoder;
encoder->possible_crtcs = drm_crtc_mask(crtc);
ret = devm_request_irq(dev, irq, vc4_txp_interrupt, 0,
--
2.7.4
Re: [PATCH 5/6] drm/rcar_du: use drm_encoder pointer for drm_writeback_connector
Hi Laurent
Thank you for your inputs.
I liked all the suggestions, hence I have incorporated those and pushed
a v2.
Thanks
Abhinav
On 3/13/2022 7:50 AM, Laurent Pinchart wrote:
Hi Abhinav
On Fri, Mar 11, 2022 at 09:47:17AM -0800, Abhinav Kumar wrote:
On 3/10/2022 11:28 PM, Laurent Pinchart wrote:
On Thu, Mar 10, 2022 at 05:49:59PM -0800, Abhinav Kumar wrote:
Make changes to rcar_du driver to start using drm_encoder pointer
for drm_writeback_connector.
Co-developed-by: Kandpal Suraj
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
index c79d125..03930ad 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
@@ -200,7 +200,8 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
{
struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
- wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
+ wb_conn->encoder = kzalloc(sizeof(struct drm_encoder), GFP_KERNEL);
Where is this freed ?
You are right, this isnt. Looking more into this, it seems like moving
the allocation of encoder to drm_writeback.c for cases which dont pass a
real encoder is much better so that I will not have to add alloc() /
free() code for all the vendor driver changes which is what I originally
thought in my RFC but changed my mind because of below.
Yes, I think that would be better indeed. You could even skip the
dynamic allocation, you could have
struct drm_encoder *encoder;
struct drm_encoder internal_encoder;
in drm_writeback_connector, and set
wb->encoder = &wb->internal_encoder;
when the user doesn't pass an encoder.
+ wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
Do you think we can just move usage of wb_conn->encoder->possible_crtcs
just right after drm_writeback_connector_init() so that it wont crash?
How about adding a possible_crtcs argument to
drm_writeback_connector_init() (to cover existing use cases), and adding
a new drm_writeback_connector_init_with_encoder() that would get an
encoder pointer (and expect possible_crtcs, as well as all the other
appropriate encoder fields, having been initialized) ?
198 int rcar_du_writeback_init(struct rcar_du_device *rcdu,
199struct rcar_du_crtc *rcrtc)
200 {
201 struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
202
203 wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
204 drm_connector_helper_add(&wb_conn->base,
205 &rcar_du_wb_conn_helper_funcs);
206
207 return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
208 &rcar_du_wb_conn_funcs,
209 &rcar_du_wb_enc_helper_funcs,
210 writeback_formats,
211 ARRAY_SIZE(writeback_formats));
212 }
drm_connector_helper_add(&wb_conn->base,
&rcar_du_wb_conn_helper_funcs);
Re: [PATCH 2/3] drm/i915/guc: add steering info to GuC register save/restore list
On Mon, Mar 14, 2022 at 04:42:02PM -0700, Matt Roper wrote: From: Daniele Ceraolo Spurio GuC has its own steering mechanism and can't use the default set by i915, so we need to provide the steering information that the FW will need to save/restore registers while processing an engine reset. The GUC interface allows us to do so as part of the register save/restore list and it requires us to specify the steering for all multicast register, even those that would be covered by the default setting for cpu access. Given that we do not distinguish between registers that do not need steering and registers that are guaranteed to work the default steering, we set the steering for all entries in the guc list that do not require a special steering (e.g. mslice) to the default settings; this will cost us a few extra writes during engine reset but allows us to keep the steering logic simple. Cc: John Harrison Cc: Matt Roper Signed-off-by: Daniele Ceraolo Spurio Signed-off-by: Matt Roper Reviewed-by: Lucas De Marchi Lucas De Marchi
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add support for steered register writes
On Mon, Mar 14, 2022 at 04:42:03PM -0700, Matt Roper wrote: Upcoming patches will need to steer writes to multicast registers as well as reading them. Although the setting of the 'multicast' bit should only really matter for write operations (reads always operate in a unicast manner and give us the result from one specific instance), Wa_22013088509 suggests that we leave the multicast bit enabled when performing read operations, so we follow suit here. Cc: Harish Chegondi Signed-off-by: Matt Roper Reviewed-by: Lucas De Marchi Lucas De Marchi
