Re: [PATCH v2 00/14] drm/format-helper: Move to struct iosys_map
Hi Thomas, On Mon, Aug 08, 2022 at 02:53:52PM +0200, Thomas Zimmermann wrote: > Change format-conversion helpers to use struct iosys_map for source > and destination buffers. Update all users. Also prepare interface for > multi-plane color formats. > > The format-conversion helpers mostly used to convert to I/O memory > or system memory. To actual memory type depended on the usecase. We > now have drivers upcomming that do the conversion entirely in system > memory. It's a good opportunity to stream-line the interface of the > conversion helpers to use struct iosys_map. Source and destination > buffers can now be either in system or in I/O memory. Note that the > implementation still only supports source buffers in system memory. > > This patchset also changes the interface to support multi-plane > color formats, where the values for each component are stored in > distinct memory locations. Converting from RGBRGBRGB to RRRGGGBBB > would require a single source buffer with RGB values and 3 destination > buffers for the R, G and B values. Conversion-helper interfaces now > support this. > > v2: > * add IOSYS_MAP_INIT_VADDR_IOMEM (Sam) > * use drm_format_info_bpp() (Sam) > * update documentation (Sam) > * rename 'vmap' to 'src' (Sam) > * many smaller cleanups and fixes (Sam, Jose) Thanks for the quick respin - I reviewed the remaining patches and looks good. Nice cleanup of the API and it makes is easier to add more conversions. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 14/14] drm/format-helper: Rename parameter vmap to src
Hi Thomas, On Mon, Aug 08, 2022 at 02:54:06PM +0200, Thomas Zimmermann wrote: > The name the parameter vmap to src in all functions. The parameter > contains the locations of the source data and the new name says that. > > Signed-off-by: Thomas Zimmermann Thanks, this helped in readability! Reviewed-by: Sam Ravnborg ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 13/14] drm/format-helper: Move destination-buffer handling into internal helper
Hi Thomas, On Mon, Aug 08, 2022 at 02:54:05PM +0200, Thomas Zimmermann wrote: > The format-convertion helpers handle several cases for different > values of destination buffer and pitch. Move that code into the > internal helper drm_fb_xfrm() and avoid quite a bit of duplication. > > v2: > * remove a duplicated blank line (Jose) > * use drm_format_info_bpp() (Sam) > * fix vaddr_cached_hint bug (Sam) > * add TODO on vaddr location (Sam) > > Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 04/14] drm/format-helper: Convert drm_fb_swab() to struct iosys_map
Hi Thomas, On Mon, Aug 08, 2022 at 02:53:56PM +0200, Thomas Zimmermann wrote: > Convert drm_fb_swab() to use struct iosys_map() and convert users. The > new interface supports multi-plane color formats, but implementation > only supports a single plane for now. > > v2: > * use drm_format_info_bpp() (Sam) > * update documentation (Sam) > * add TODO on vaddr location (Sam) > > Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 03/14] drm/format-helper: Merge drm_fb_memcpy() and drm_fb_memcpy_toio()
Hi Thomas, On Mon, Aug 08, 2022 at 02:53:55PM +0200, Thomas Zimmermann wrote: > Merge drm_fb_memcpy() and drm_fb_memcpy_toio() into a drm_fb_memcpy() > that uses struct iosys_map for buffers. The new function also supports > multi-plane color formats. Convert all users of the original helpers. > > v2: > * rebase onto refactored mgag200 > * use drm_formap_info_bpp() (Sam) > * do static init in hyperv and mgag200 (Sam) > * update documentation (Sam) > * add TODO on vaddr location (Sam) > > Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 01/14] iosys-map: Add IOSYS_MAP_INIT_VADDR_IOMEM()
On Mon, Aug 08, 2022 at 02:53:53PM +0200, Thomas Zimmermann wrote:
> Add IOSYS_MAP_INIT_VADDR_IOMEM() for static init of variables of type
> struct iosys_map.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> include/linux/iosys-map.h | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
> index a533cae189d7..cb71aa616bd3 100644
> --- a/include/linux/iosys-map.h
> +++ b/include/linux/iosys-map.h
> @@ -46,10 +46,13 @@
> *
> * iosys_map_set_vaddr(, 0xdeadbeaf);
> *
> - * To set an address in I/O memory, use iosys_map_set_vaddr_iomem().
> + * To set an address in I/O memory, use IOSYS_MAP_INIT_VADDR_IOMEM() or
> + * iosys_map_set_vaddr_iomem().
> *
> * .. code-block:: c
> *
> + * struct iosys_map map = IOSYS_MAP_INIT_VADDR_IOMEM(0xdeadbeaf);
> + *
> * iosys_map_set_vaddr_iomem(, 0xdeadbeaf);
> *
> * Instances of struct iosys_map do not have to be cleaned up, but
> @@ -121,6 +124,16 @@ struct iosys_map {
> .is_iomem = false, \
> }
>
> +/**
> + * IOSYS_MAP_INIT_VADDR_IOMEM - Initializes struct iosys_map to an address
> in I/O memory
> + * @vaddr_iomem_:An I/O-memory address
> + */
> +#define IOSYS_MAP_INIT_VADDR_IOMEM(vaddr_iomem_) \
> + { \
> + .vaddr_iomem = (vaddr_iomem_), \
> + .is_iomem = true, \
> + }
> +
> /**
> * IOSYS_MAP_INIT_OFFSET - Initializes struct iosys_map from another
> iosys_map
> * @map_:The dma-buf mapping structure to copy from
> --
> 2.37.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 12/12] drm/format-helper: Move destination-buffer handling into internal helper
Hi Thomas,
> > > - static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> > > - 0, 0, 0, 0
> > > - };
> > > const struct drm_format_info *format = fb->format;
> > > - u8 cpp = format->cpp[0];
> > > void (*swab_line)(void *dbuf, const void *sbuf, unsigned int
> > > npixels);
> > > - switch (cpp) {
> > > + switch (format->cpp[0]) {
> > > case 4:
> > > swab_line = drm_fb_swab32_line;
> > > break;
> > > @@ -230,21 +249,10 @@ void drm_fb_swab(struct iosys_map *dst, const
> > > unsigned int *dst_pitch,
> > > default:
> > > drm_warn_once(fb->dev, "Format %p4cc has unsupported
> > > pixel size.\n",
> > > >format);
> > > - swab_line = NULL;
> > > - break;
> > > - }
> > > - if (!swab_line)
> > > return;
> > > + }
> > > - if (!dst_pitch)
> > > - dst_pitch = default_dst_pitch;
> > > -
> > > - if (dst->is_iomem)
> > > - drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], cpp,
> > > - vmap[0].vaddr, fb, clip, cached, swab_line);
> > > - else
> > > - drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], cpp, vmap[0].vaddr, fb,
> > > - clip, cached, swab_line);
> > > + drm_fb_xfrm(dst, dst_pitch, format->cpp, vmap, fb, clip, cached,
> > > swab_line);
> >
> > In this case we pass fb->format-cpp as dst_pitch - so we could retreive
> > is via the fb pointer.
>
> I don't understand this comment. We're passing format->cpp as dst_pixsize.
> I've meanwhile updated the code to compute the value from
> drm_format_info_bpp().
I wanted to ask if we could drop the format->cpp argument and in
drm_fb_xfrm() use fb->format to retrieve the char per pixel.
So we move this part down in drm_fb_xfrm(), rather than finding
the char per pixel in all callers.
Maybe some of the other callers do not allow this and then this comment
can be ignored.
I have not yet looked at the updated patch-set.
Sam
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 00/12] drm/format-helper: Move to struct iosys_map
Hi Thomas, On Wed, Jul 27, 2022 at 01:33:00PM +0200, Thomas Zimmermann wrote: > Change format-conversion helpers to use struct iosys_map for source > and destination buffers. Update all users. Also prepare interface for > multi-plane color formats. > > The format-conversion helpers mostly used to convert to I/O memory > or system memory. To actual memory type depended on the usecase. We > now have drivers upcomming that do the conversion entirely in system > memory. It's a good opportunity to stream-line the interface of the > conversion helpers to use struct iosys_map. Source and destination > buffers can now be either in system or in I/O memory. Thanks for looking into this - I like how we hide the memory details in the helpers (system vs io). And unifying the system and io variants makes the API simpler - also good. > Note that the > implementation still only supports source buffers in system memory. Yeah, I noted this in my feedback but realized only now that it is written here. I left a few comments (details only) in some of the patches, most are reviewed without comments. There is a few general things - mostly bikeshedding about naming and such. As usual ignore what you think is irrelevant. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 12/12] drm/format-helper: Move destination-buffer handling into internal helper
Hi Thomas,
On Wed, Jul 27, 2022 at 01:33:12PM +0200, Thomas Zimmermann wrote:
> The format-convertion helpers handle several cases for different
> values of destination buffer and pitch. Move that code into the
> internal helper drm_fb_xfrm() and avoid quite a bit of duplucation.
This is very nice patch that should come before all the conversion
patches - but then you have had to come up with another name.
So I think this is fine.
A few comments below, mostly in the same area as the comments from José.
Sam
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_format_helper.c | 169 +++-
> 1 file changed, 64 insertions(+), 105 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index d296d181659d..35aebdb90165 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -41,11 +41,11 @@ unsigned int drm_fb_clip_offset(unsigned int pitch, const
> struct drm_format_info
> }
> EXPORT_SYMBOL(drm_fb_clip_offset);
>
> -/* TODO: Make this functon work with multi-plane formats. */
> -static int drm_fb_xfrm(void *dst, unsigned long dst_pitch, unsigned long
> dst_pixsize,
> -const void *vaddr, const struct drm_framebuffer *fb,
> -const struct drm_rect *clip, bool vaddr_cached_hint,
> -void (*xfrm_line)(void *dbuf, const void *sbuf, unsigned
> int npixels))
> +/* TODO: Make this function work with multi-plane formats. */
> +static int __drm_fb_xfrm(void *dst, unsigned long dst_pitch, unsigned long
> dst_pixsize,
> + const void *vaddr, const struct drm_framebuffer *fb,
> + const struct drm_rect *clip, bool vaddr_cached_hint,
> + void (*xfrm_line)(void *dbuf, const void *sbuf,
> unsigned int npixels))
> {
> unsigned long linepixels = drm_rect_width(clip);
> unsigned long lines = drm_rect_height(clip);
> @@ -84,11 +84,11 @@ static int drm_fb_xfrm(void *dst, unsigned long
> dst_pitch, unsigned long dst_pix
> return 0;
> }
>
> -/* TODO: Make this functon work with multi-plane formats. */
> -static int drm_fb_xfrm_toio(void __iomem *dst, unsigned long dst_pitch,
> unsigned long dst_pixsize,
> - const void *vaddr, const struct drm_framebuffer *fb,
> - const struct drm_rect *clip, bool vaddr_cached_hint,
> - void (*xfrm_line)(void *dbuf, const void *sbuf,
> unsigned int npixels))
> +/* TODO: Make this function work with multi-plane formats. */
> +static int __drm_fb_xfrm_toio(void __iomem *dst, unsigned long dst_pitch,
> unsigned long dst_pixsize,
> + const void *vaddr, const struct drm_framebuffer
> *fb,
> + const struct drm_rect *clip, bool
> vaddr_cached_hint,
> + void (*xfrm_line)(void *dbuf, const void *sbuf,
> unsigned int npixels))
> {
> unsigned long linepixels = drm_rect_width(clip);
> unsigned long lines = drm_rect_height(clip);
> @@ -129,6 +129,29 @@ static int drm_fb_xfrm_toio(void __iomem *dst, unsigned
> long dst_pitch, unsigned
> return 0;
> }
>
> +/* TODO: Make this function work with multi-plane formats. */
> +static int drm_fb_xfrm(struct iosys_map *dst,
> +const unsigned int *dst_pitch, const u8 *dst_pixsize,
> +const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> +const struct drm_rect *clip, bool vaddr_cached_hint,
> +void (*xfrm_line)(void *dbuf, const void *sbuf, unsigned
> int npixels))
> +{
Just to repeat myself a little, this assumes src (vmap) is always system
memory (not io).
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + return __drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0],
> dst_pixsize[0],
> + vmap[0].vaddr, fb, clip, false,
> xfrm_line);
> + else
> + return __drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], dst_pixsize[0],
> + vmap[0].vaddr, fb, clip, false, xfrm_line);
It looks like vaddr_cached_hint is always false, so can we remove it?
> +}
> +
> +
> /**
> * drm_fb_memcpy - Copy clip buffer
> * @dst: Array of destination buffers
> @@ -213,14 +236,10 @@ void drm_fb_swab(struct iosys_map *dst, const unsigned
> int *dst_pitch,
>const struct iosys_map *vmap, const struct drm_framebuffer *fb,
>const struct drm_rect *clip, bool cached)
> {
> - static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> - 0, 0, 0, 0
> - };
> const struct drm_format_info *format = fb->format;
Re: [PATCH 11/12] drm/format-helper: Rework XRGB8888-to-MONO conversion
On Wed, Jul 27, 2022 at 01:33:11PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-MONO conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 28 +++-
> drivers/gpu/drm/solomon/ssd130x.c | 7 ---
> drivers/gpu/drm/tiny/repaper.c | 6 +-
> include/drm/drm_format_helper.h | 5 +++--
> 4 files changed, 31 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 521932fac491..d296d181659d 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -680,9 +680,9 @@ static void drm_fb_gray8_to_mono_line(void *dbuf, const
> void *sbuf, unsigned int
>
> /**
> * drm_fb_xrgb_to_mono - Convert XRGB to monochrome
It should be documented that this only supports system memory (no io
memory support).
Sam
> - * @dst: monochrome destination buffer (0=black, 1=white)
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> + * @dst: Array of monochrome destination buffers (0=black, 1=white)
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
> + * @vmap: Array of XRGB source buffers
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> *
> @@ -700,26 +700,36 @@ static void drm_fb_gray8_to_mono_line(void *dbuf, const
> void *sbuf, unsigned int
> * 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)
> +void drm_fb_xrgb_to_mono(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> + const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> + const struct drm_rect *clip)
> {
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> unsigned int linepixels = drm_rect_width(clip);
> 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;
> + void *vaddr = vmap[0].vaddr;
> + unsigned int dst_pitch_0;
> unsigned int y;
> - u8 *mono = dst, *gray8;
> + u8 *mono = dst[0].vaddr, *gray8;
> u32 *src32;
>
> if (drm_WARN_ON(dev, fb->format->format != DRM_FORMAT_XRGB))
> return;
>
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> + dst_pitch_0 = dst_pitch[0];
> +
> /*
>* The mono destination buffer contains 1 bit per pixel
>*/
> - if (!dst_pitch)
> - dst_pitch = DIV_ROUND_UP(linepixels, 8);
> + if (!dst_pitch_0)
> + dst_pitch_0 = DIV_ROUND_UP(linepixels, 8);
>
> /*
>* The cma memory is write-combined so reads are uncached.
> @@ -744,7 +754,7 @@ void drm_fb_xrgb_to_mono(void *dst, unsigned int
> dst_pitch, const void *vadd
> drm_fb_xrgb_to_gray8_line(gray8, src32, linepixels);
> drm_fb_gray8_to_mono_line(mono, gray8, linepixels);
> vaddr += fb->pitches[0];
> - mono += dst_pitch;
> + mono += dst_pitch_0;
> }
>
> kfree(src32);
> diff --git a/drivers/gpu/drm/solomon/ssd130x.c
> b/drivers/gpu/drm/solomon/ssd130x.c
> index 5a3e3b78cd9e..aa7329a65c98 100644
> --- a/drivers/gpu/drm/solomon/ssd130x.c
> +++ b/drivers/gpu/drm/solomon/ssd130x.c
> @@ -537,11 +537,11 @@ static void ssd130x_clear_screen(struct ssd130x_device
> *ssd130x)
> kfree(buf);
> }
>
> -static int ssd130x_fb_blit_rect(struct drm_framebuffer *fb, const struct
> iosys_map *map,
> +static int ssd130x_fb_blit_rect(struct drm_framebuffer *fb, const struct
> iosys_map *vmap,
> struct drm_rect *rect)
> {
> struct ssd130x_device *ssd130x = drm_to_ssd130x(fb->dev);
> - void *vmap = map->vaddr; /* TODO: Use mapping abstraction properly */
> + struct iosys_map dst;
> unsigned int dst_pitch;
> int ret = 0;
> u8 *buf = NULL;
> @@
Re: [PATCH 10/12] drm/format-helper: Rework XRGB8888-to-GRAY8 conversion
On Wed, Jul 27, 2022 at 01:33:10PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-GRAY8 conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 25 +++--
> drivers/gpu/drm/gud/gud_pipe.c | 7 +--
> drivers/gpu/drm/tiny/st7586.c | 5 -
> include/drm/drm_format_helper.h | 5 +++--
> 4 files changed, 31 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 209f63b66c5f..521932fac491 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -552,9 +552,9 @@ static void drm_fb_xrgb_to_gray8_line(void *dbuf,
> const void *sbuf, unsigned
>
> /**
> * drm_fb_xrgb_to_gray8 - Convert XRGB to grayscale
> - * @dst: 8-bit grayscale destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> + * @dst: Array of 8-bit grayscale destination buffers
> + * @dst_pitch: Array of number of bytes between two consecutive scanlines
> within dst
> + * @vmap: Array of XRGB source buffers
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> *
> @@ -567,10 +567,23 @@ static void drm_fb_xrgb_to_gray8_line(void *dbuf,
> const void *sbuf, unsigned
> *
> * ITU BT.601 is used for the RGB -> luma (brightness) conversion.
> */
> -void drm_fb_xrgb_to_gray8(void *dst, unsigned int dst_pitch, const void
> *vaddr,
> - const struct drm_framebuffer *fb, const struct
> drm_rect *clip)
> +void drm_fb_xrgb_to_gray8(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> + const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> + const struct drm_rect *clip)
> {
> - drm_fb_xfrm(dst, dst_pitch, 1, vaddr, fb, clip, false,
> drm_fb_xrgb_to_gray8_line);
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 1,
> vmap[0].vaddr, fb,
> + clip, false, drm_fb_xrgb_to_gray8_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 1, vmap[0].vaddr, fb,
> + clip, false, drm_fb_xrgb_to_gray8_line);
> }
> EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
>
> diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
> index 0caa228f736d..7c6dc2bcd14a 100644
> --- a/drivers/gpu/drm/gud/gud_pipe.c
> +++ b/drivers/gpu/drm/gud/gud_pipe.c
> @@ -59,6 +59,7 @@ static size_t gud_xrgb_to_r124(u8 *dst, const struct
> drm_format_info *format
> unsigned int bits_per_pixel = 8 / block_width;
> unsigned int x, y, width, height;
> u8 pix, *pix8, *block = dst; /* Assign to silence compiler warning */
> + struct iosys_map dst_map, vmap;
> size_t len;
> void *buf;
>
> @@ -74,7 +75,9 @@ static size_t gud_xrgb_to_r124(u8 *dst, const struct
> drm_format_info *format
> if (!buf)
> return 0;
>
> - drm_fb_xrgb_to_gray8(buf, 0, src, fb, rect);
> + iosys_map_set_vaddr(_map, buf);
> + iosys_map_set_vaddr(, src);
> + drm_fb_xrgb_to_gray8(_map, NULL, , fb, rect);
> pix8 = buf;
>
> for (y = 0; y < height; y++) {
> @@ -194,7 +197,7 @@ static int gud_prep_flush(struct gud_device *gdrm, struct
> drm_framebuffer *fb,
> goto end_cpu_access;
> }
> } else if (format->format == DRM_FORMAT_R8) {
> - drm_fb_xrgb_to_gray8(buf, 0, vaddr, fb, rect);
> + drm_fb_xrgb_to_gray8(, NULL, map_data, fb,
> rect);
> } else if (format->format == DRM_FORMAT_RGB332) {
> drm_fb_xrgb_to_rgb332(, NULL, map_data, fb,
> rect);
> } else if (format->format == DRM_FORMAT_RGB565) {
> diff --git a/drivers/gpu/drm/tiny/st7586.c b/drivers/gpu/drm/tiny/st7586.c
> index 8eddb020c43e..702350d0f8bc 100644
> --- a/drivers/gpu/drm/tiny/st7586.c
> +++ b/drivers/gpu/drm/tiny/st7586.c
> @@ -69,12 +69,15 @@ static void st7586_xrgb_to_
Re: [PATCH 09/12] drm/format-helper: Rework XRGB8888-to-XRGB2101010 conversion
On Wed, Jul 27, 2022 at 01:33:09PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-XRGB2101010 conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Sam Ravnborg
> drivers/gpu/drm/drm_format_helper.c | 35 +
> include/drm/drm_format_helper.h | 6 ++---
> 2 files changed, 24 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 155827eebe99..209f63b66c5f 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -504,26 +504,34 @@ static void drm_fb_xrgb_to_xrgb2101010_line(void
> *dbuf, const void *sbuf, un
> }
>
> /**
> - * drm_fb_xrgb_to_xrgb2101010_toio - Convert XRGB to XRGB2101010 clip
> - * buffer
> - * @dst: XRGB2101010 destination buffer (iomem)
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> + * drm_fb_xrgb_to_xrgb2101010 - Convert XRGB to XRGB2101010 clip
> buffer
> + * @dst: Array of XRGB2101010 destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
> + * @vmap: Array of XRGB source buffers
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> *
> * Drivers can use this function for XRGB2101010 devices that don't natively
> * support XRGB.
> */
> -void drm_fb_xrgb_to_xrgb2101010_toio(void __iomem *dst,
> - unsigned int dst_pitch, const void
> *vaddr,
> - const struct drm_framebuffer *fb,
> - const struct drm_rect *clip)
> +void drm_fb_xrgb_to_xrgb2101010(struct iosys_map *dst, const unsigned
> int *dst_pitch,
> + const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> + const struct drm_rect *clip)
> {
> - drm_fb_xfrm_toio(dst, dst_pitch, 4, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_xrgb2101010_line);
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 4,
> vmap[0].vaddr, fb,
> + clip, false,
> drm_fb_xrgb_to_xrgb2101010_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 4, vmap[0].vaddr, fb,
> + clip, false, drm_fb_xrgb_to_xrgb2101010_line);
> }
> -EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb2101010_toio);
>
> static void drm_fb_xrgb_to_gray8_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> {
> @@ -628,8 +636,7 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
> }
> } else if (dst_format == DRM_FORMAT_XRGB2101010) {
> if (fb_format == DRM_FORMAT_XRGB) {
> - drm_fb_xrgb_to_xrgb2101010_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> - vmap[0].vaddr, fb,
> clip);
> + drm_fb_xrgb_to_xrgb2101010(dst, dst_pitch, vmap,
> fb, clip);
> return 0;
> }
> }
> diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
> index 8c633dbab5d6..6807440ce29c 100644
> --- a/include/drm/drm_format_helper.h
> +++ b/include/drm/drm_format_helper.h
> @@ -29,9 +29,9 @@ void drm_fb_xrgb_to_rgb565(struct iosys_map *dst, const
> unsigned int *dst_pi
> void drm_fb_xrgb_to_rgb888(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> const struct drm_rect *clip);
> -void drm_fb_xrgb_to_xrgb2101010_toio(void __iomem *dst, unsigned int
> dst_pitch,
> - const void *vaddr, const struct
> drm_framebuffer *fb,
> - const struct drm_rect *clip);
> +void drm_fb_xrgb_to_xrgb2101010(struct iosys_map *dst, const unsigned
> int *dst_pitch,
> + const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> +
Re: [PATCH 08/12] drm/format-helper: Rework RGB888-to-XRGB8888 conversion
On Wed, Jul 27, 2022 at 01:33:08PM +0200, Thomas Zimmermann wrote:
> Update RGB888-to-XRGB conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 5ef06f696657..155827eebe99 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -465,12 +465,24 @@ static void drm_fb_rgb888_to_xrgb_line(void *dbuf,
> const void *sbuf, unsigne
> }
> }
>
> -static void drm_fb_rgb888_to_xrgb_toio(void __iomem *dst, unsigned int
> dst_pitch,
> -const void *vaddr, const struct
> drm_framebuffer *fb,
> -const struct drm_rect *clip)
> +static void drm_fb_rgb888_to_xrgb(struct iosys_map *dst, const unsigned
> int *dst_pitch,
> + const struct iosys_map *vmap,
> + const struct drm_framebuffer *fb,
> + const struct drm_rect *clip)
> {
> - drm_fb_xfrm_toio(dst, dst_pitch, 4, vaddr, fb, clip, false,
> - drm_fb_rgb888_to_xrgb_line);
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 4,
> vmap[0].vaddr, fb,
> + clip, false, drm_fb_rgb888_to_xrgb_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 4, vmap[0].vaddr, fb,
> + clip, false, drm_fb_rgb888_to_xrgb_line);
> }
>
> static void drm_fb_xrgb_to_xrgb2101010_line(void *dbuf, const void
> *sbuf, unsigned int pixels)
> @@ -608,8 +620,7 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
> }
> } else if (dst_format == DRM_FORMAT_XRGB) {
> if (fb_format == DRM_FORMAT_RGB888) {
> - drm_fb_rgb888_to_xrgb_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> -vmap[0].vaddr, fb, clip);
> + drm_fb_rgb888_to_xrgb(dst, dst_pitch, vmap, fb,
> clip);
> return 0;
> } else if (fb_format == DRM_FORMAT_RGB565) {
> drm_fb_rgb565_to_xrgb(dst, dst_pitch, vmap, fb,
> clip);
> --
> 2.37.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 07/12] drm/format-helper: Rework RGB565-to-XRGB8888 conversion
On Wed, Jul 27, 2022 at 01:33:07PM +0200, Thomas Zimmermann wrote:
> Update RGB565-to-XRGB conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 4edab44336d8..5ef06f696657 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -430,12 +430,24 @@ static void drm_fb_rgb565_to_xrgb_line(void *dbuf,
> const void *sbuf, unsigne
> }
> }
>
> -static void drm_fb_rgb565_to_xrgb_toio(void __iomem *dst, unsigned int
> dst_pitch,
> -const void *vaddr, const struct
> drm_framebuffer *fb,
> -const struct drm_rect *clip)
> +static void drm_fb_rgb565_to_xrgb(struct iosys_map *dst, const unsigned
> int *dst_pitch,
> + const struct iosys_map *vmap,
> + const struct drm_framebuffer *fb,
> + const struct drm_rect *clip)
> {
> - drm_fb_xfrm_toio(dst, dst_pitch, 4, vaddr, fb, clip, false,
> - drm_fb_rgb565_to_xrgb_line);
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 4,
> vmap[0].vaddr, fb,
> + clip, false, drm_fb_rgb565_to_xrgb_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 4, vmap[0].vaddr, fb,
> + clip, false, drm_fb_rgb565_to_xrgb_line);
> }
>
> static void drm_fb_rgb888_to_xrgb_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> @@ -600,8 +612,7 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
> vmap[0].vaddr, fb, clip);
> return 0;
> } else if (fb_format == DRM_FORMAT_RGB565) {
> - drm_fb_rgb565_to_xrgb_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> -vmap[0].vaddr, fb, clip);
> + drm_fb_rgb565_to_xrgb(dst, dst_pitch, vmap, fb,
> clip);
> return 0;
> }
> } else if (dst_format == DRM_FORMAT_XRGB2101010) {
> --
> 2.37.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 06/12] drm/format-helper: Rework XRGB8888-to-RGB888 conversion
On Wed, Jul 27, 2022 at 01:33:06PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-RGB888 conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 48 -
> drivers/gpu/drm/gud/gud_pipe.c | 2 +-
> drivers/gpu/drm/tiny/cirrus.c | 3 +-
> include/drm/drm_format_helper.h | 8 ++---
> 4 files changed, 25 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 8bf5655f5ce0..4edab44336d8 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -383,41 +383,34 @@ static void drm_fb_xrgb_to_rgb888_line(void *dbuf,
> const void *sbuf, unsigne
>
> /**
> * drm_fb_xrgb_to_rgb888 - Convert XRGB to RGB888 clip buffer
> - * @dst: RGB888 destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @src: XRGB source buffer
> + * @dst: Array of RGB888 destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
> + * @vmap: Array of XRGB source buffers
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> *
> * Drivers can use this function for RGB888 devices that don't natively
> * support XRGB.
> */
> -void drm_fb_xrgb_to_rgb888(void *dst, unsigned int dst_pitch, const void
> *src,
> -const struct drm_framebuffer *fb, const struct
> drm_rect *clip)
> +void drm_fb_xrgb_to_rgb888(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> +const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> +const struct drm_rect *clip)
> {
> - drm_fb_xfrm(dst, dst_pitch, 3, src, fb, clip, false,
> drm_fb_xrgb_to_rgb888_line);
> -}
> -EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888);
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
>
> -/**
> - * drm_fb_xrgb_to_rgb888_toio - Convert XRGB to RGB888 clip buffer
> - * @dst: RGB565 destination buffer (iomem)
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> - * @fb: DRM framebuffer
> - * @clip: Clip rectangle area to copy
> - *
> - * Drivers can use this function for RGB888 devices that don't natively
> - * support XRGB.
> - */
> -void drm_fb_xrgb_to_rgb888_toio(void __iomem *dst, unsigned int
> dst_pitch,
> - const void *vaddr, const struct
> drm_framebuffer *fb,
> - const struct drm_rect *clip)
> -{
> - drm_fb_xfrm_toio(dst, dst_pitch, 3, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_rgb888_line);
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 3,
> vmap[0].vaddr, fb,
> + clip, false, drm_fb_xrgb_to_rgb888_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 3, vmap[0].vaddr, fb,
> + clip, false, drm_fb_xrgb_to_rgb888_line);
> }
> -EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_toio);
> +EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888);
>
> static void drm_fb_rgb565_to_xrgb_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> {
> @@ -598,8 +591,7 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
> }
> } else if (dst_format == DRM_FORMAT_RGB888) {
> if (fb_format == DRM_FORMAT_XRGB) {
> - drm_fb_xrgb_to_rgb888_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> -vmap[0].vaddr, fb, clip);
> + drm_fb_xrgb_to_rgb888(dst, dst_pitch, vmap, fb,
> clip);
> return 0;
> }
> } else if (dst_format == DRM_FORMAT_XRGB) {
> diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
> index a43eb6645352..0caa228f736d 100644
> --- a/drivers/gpu/drm/gud/gud_pipe.c
> +++ b/drivers/gpu/drm/gud/gud_pipe.c
> @@ -201,7 +201,7 @@ static int gud_prep_flush(struct gud_device *gdrm, struct
> drm_framebuffer *fb,
> drm_fb_xrgb
Re: [PATCH 05/12] drm/format-helper: Rework XRGB8888-to-RGBG565 conversion
On Wed, Jul 27, 2022 at 01:33:05PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-RGB565 conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 59 +++--
> drivers/gpu/drm/drm_mipi_dbi.c | 4 +-
> drivers/gpu/drm/gud/gud_pipe.c | 3 +-
> drivers/gpu/drm/tiny/cirrus.c | 3 +-
> include/drm/drm_format_helper.h | 9 ++---
> 5 files changed, 30 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 2b5c3746ff4a..8bf5655f5ce0 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -330,9 +330,9 @@ static void drm_fb_xrgb_to_rgb565_swab_line(void
> *dbuf, const void *sbuf,
>
> /**
> * drm_fb_xrgb_to_rgb565 - Convert XRGB to RGB565 clip buffer
> - * @dst: RGB565 destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> + * @dst: Array of RGB565 destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
> + * @vmap: Array of XRGB source buffer
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> * @swab: Swap bytes
> @@ -340,43 +340,31 @@ static void drm_fb_xrgb_to_rgb565_swab_line(void
> *dbuf, const void *sbuf,
> * Drivers can use this function for RGB565 devices that don't natively
> * support XRGB.
> */
> -void drm_fb_xrgb_to_rgb565(void *dst, unsigned int dst_pitch, const void
> *vaddr,
> -const struct drm_framebuffer *fb, const struct
> drm_rect *clip,
> -bool swab)
> +void drm_fb_xrgb_to_rgb565(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> +const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> +const struct drm_rect *clip, bool swab)
> {
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> + void (*xfrm_line)(void *dbuf, const void *sbuf, unsigned int npixels);
> +
> if (swab)
> - drm_fb_xfrm(dst, dst_pitch, 2, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_rgb565_swab_line);
> + xfrm_line = drm_fb_xrgb_to_rgb565_swab_line;
> else
> - drm_fb_xfrm(dst, dst_pitch, 2, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_rgb565_line);
> -}
> -EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
> + xfrm_line = drm_fb_xrgb_to_rgb565_line;
>
> -/**
> - * drm_fb_xrgb_to_rgb565_toio - Convert XRGB to RGB565 clip buffer
> - * @dst: RGB565 destination buffer (iomem)
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> - * @fb: DRM framebuffer
> - * @clip: Clip rectangle area to copy
> - * @swab: Swap bytes
> - *
> - * Drivers can use this function for RGB565 devices that don't natively
> - * support XRGB.
> - */
> -void drm_fb_xrgb_to_rgb565_toio(void __iomem *dst, unsigned int
> dst_pitch,
> - const void *vaddr, const struct
> drm_framebuffer *fb,
> - const struct drm_rect *clip, bool swab)
> -{
> - if (swab)
> - drm_fb_xfrm_toio(dst, dst_pitch, 2, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_rgb565_swab_line);
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 2,
> vmap[0].vaddr, fb, clip,
> + false, xfrm_line);
> else
> - drm_fb_xfrm_toio(dst, dst_pitch, 2, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_rgb565_line);
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 2, vmap[0].vaddr, fb,
> clip,
> + false, xfrm_line);
> }
> -EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565_toio);
> +EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
>
> static void drm_fb_xrgb_to_rgb888_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> {
> @@ -605,8 +593,7 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
>
> } els
Re: [PATCH 04/12] drm/format-helper: Rework XRGB8888-to-RGBG332 conversion
Hi Thomas,
On Wed, Jul 27, 2022 at 01:33:04PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-RGB332 conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
I am not going to repeat my naming rant here, so
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 25 ++-
> drivers/gpu/drm/gud/gud_pipe.c| 2 +-
> .../gpu/drm/tests/drm_format_helper_test.c| 14 ++-
> include/drm/drm_format_helper.h | 5 ++--
> 4 files changed, 31 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index fa22d3cb11e8..2b5c3746ff4a 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -265,18 +265,31 @@ static void drm_fb_xrgb_to_rgb332_line(void *dbuf,
> const void *sbuf, unsigne
>
> /**
> * drm_fb_xrgb_to_rgb332 - Convert XRGB to RGB332 clip buffer
> - * @dst: RGB332 destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @src: XRGB source buffer
> + * @dst: Array of RGB332 destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
> + * @vmap: Array of XRGB source buffers
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> *
> * Drivers can use this function for RGB332 devices that don't natively
> support XRGB.
> */
> -void drm_fb_xrgb_to_rgb332(void *dst, unsigned int dst_pitch, const void
> *src,
> -const struct drm_framebuffer *fb, const struct
> drm_rect *clip)
> +void drm_fb_xrgb_to_rgb332(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> +const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> +const struct drm_rect *clip)
> {
> - drm_fb_xfrm(dst, dst_pitch, 1, src, fb, clip, false,
> drm_fb_xrgb_to_rgb332_line);
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 1,
> vmap[0].vaddr, fb, clip,
> + false, drm_fb_xrgb_to_rgb332_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 1, vmap[0].vaddr, fb,
> clip,
> + false, drm_fb_xrgb_to_rgb332_line);
> }
> EXPORT_SYMBOL(drm_fb_xrgb_to_rgb332);
>
> diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
> index a15cda9ba058..426a3ae6cc50 100644
> --- a/drivers/gpu/drm/gud/gud_pipe.c
> +++ b/drivers/gpu/drm/gud/gud_pipe.c
> @@ -196,7 +196,7 @@ static int gud_prep_flush(struct gud_device *gdrm, struct
> drm_framebuffer *fb,
> } else if (format->format == DRM_FORMAT_R8) {
> drm_fb_xrgb_to_gray8(buf, 0, vaddr, fb, rect);
> } else if (format->format == DRM_FORMAT_RGB332) {
> - drm_fb_xrgb_to_rgb332(buf, 0, vaddr, fb, rect);
> + drm_fb_xrgb_to_rgb332(, NULL, map_data, fb,
> rect);
> } else if (format->format == DRM_FORMAT_RGB565) {
> drm_fb_xrgb_to_rgb565(buf, 0, vaddr, fb, rect,
> gud_is_big_endian());
> } else if (format->format == DRM_FORMAT_RGB888) {
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
> b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index 98583bf56044..b74dba06f704 100644
> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> @@ -124,7 +124,8 @@ static void xrgb_to_rgb332_test(struct kunit *test)
> {
> const struct xrgb_to_rgb332_case *params = test->param_value;
> size_t dst_size;
> - __u8 *dst = NULL;
> + struct iosys_map dst, xrgb;
> + __u8 *buf = NULL;
>
> struct drm_framebuffer fb = {
> .format = drm_format_info(DRM_FORMAT_XRGB),
> @@ -135,12 +136,13 @@ static void xrgb_to_rgb332_test(struct kunit *test)
> >clip);
> KUNIT_ASSERT_GT(test, dst_size, 0);
>
> - dst = kunit_kzalloc(test, dst_size, GFP_KERNEL);
> - KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dst);
> +
Re: [PATCH 03/12] drm/format-helper: Convert drm_fb_swab() to struct iosys_map
Hi Thomas,
On Wed, Jul 27, 2022 at 01:33:03PM +0200, Thomas Zimmermann wrote:
> Convert drm_fb_swab() to use struct iosys_map() and convert users. The
> new interface supports multi-plane color formats.
It swabs only plane[0], sbut this is maybe enough to say so.
A few comments in the following.
Sam
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_format_helper.c | 38 +
> drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
> drivers/gpu/drm/gud/gud_pipe.c | 2 +-
> include/drm/drm_format_helper.h | 6 ++---
> 4 files changed, 33 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 49589b442f18..fa22d3cb11e8 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -196,9 +196,9 @@ static void drm_fb_swab32_line(void *dbuf, const void
> *sbuf, unsigned int pixels
>
> /**
> * drm_fb_swab - Swap bytes into clip buffer
> - * @dst: Destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @src: Source buffer
> + * @dst: Array of destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
Document that it may be NULL?
> + * @vmap: Array of source buffers
Prefer that the source is named src, and vmap smells like system
(virtual) memory to me.
Also vmap must be system memory - but this is maybe fixed later.
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> * @cached: Source buffer is mapped cached (eg. not write-combined)
> @@ -209,24 +209,42 @@ static void drm_fb_swab32_line(void *dbuf, const void
> *sbuf, unsigned int pixels
> * This function does not apply clipping on dst, i.e. the destination
> * is at the top-left corner.
> */
> -void drm_fb_swab(void *dst, unsigned int dst_pitch, const void *src,
> - const struct drm_framebuffer *fb, const struct drm_rect *clip,
> - bool cached)
> +void drm_fb_swab(struct iosys_map *dst, const unsigned int *dst_pitch,
> + const struct iosys_map *vmap, const struct drm_framebuffer *fb,
> + const struct drm_rect *clip, bool cached)
> {
> - u8 cpp = fb->format->cpp[0];
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> + const struct drm_format_info *format = fb->format;
> + u8 cpp = format->cpp[0];
u8 cpp = drm_format_info_bpp(format, 0) / 8;
> + void (*swab_line)(void *dbuf, const void *sbuf, unsigned int npixels);
>
> switch (cpp) {
> case 4:
> - drm_fb_xfrm(dst, dst_pitch, cpp, src, fb, clip, cached,
> drm_fb_swab32_line);
> + swab_line = drm_fb_swab32_line;
> break;
> case 2:
> - drm_fb_xfrm(dst, dst_pitch, cpp, src, fb, clip, cached,
> drm_fb_swab16_line);
> + swab_line = drm_fb_swab16_line;
> break;
> default:
> drm_warn_once(fb->dev, "Format %p4cc has unsupported pixel
> size.\n",
> - >format->format);
> + >format);
> + swab_line = NULL;
> break;
> }
> + if (!swab_line)
> + return;
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst->is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], cpp,
> + vmap[0].vaddr, fb, clip, cached, swab_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], cpp, vmap[0].vaddr, fb,
> + clip, cached, swab_line);
Here vmap is assumes system memory, not IO. I assume this is fixed
later.
> }
> EXPORT_SYMBOL(drm_fb_swab);
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 22451806fb5c..973a75585cad 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -221,7 +221,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer
> *fb,
> switch (fb->format->format) {
> case DRM_FORMAT_RGB565:
> if (swap)
> - drm_fb_swab(dst, 0, src, fb, clip, !gem->import_attach);
> + drm_fb_swab(_map, NULL, data, fb, clip,
> !gem->import_attach);
> else
> drm_fb_memcpy(_map, NULL, data, fb, clip);
> break;
> diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
> index 449c95a4aee0..a15cda9ba058 100644
> --- a/drivers/gpu/drm/gud/gud_pipe.c
> +++ b/drivers/gpu/drm/gud/gud_pipe.c
> @@ -205,7 +205,7 @@ static int gud_prep_flush(struct gud_device *gdrm, struct
> drm_framebuffer *fb,
> len = gud_xrgb_to_color(buf, format, vaddr, fb,
> rect);
> }
> } else if (gud_is_big_endian() && format->cpp[0]
Re: [PATCH 02/12] drm/format-helper: Merge drm_fb_memcpy() and drm_fb_memcpy_toio()
Hi Thomas,
On Wed, Jul 27, 2022 at 01:33:02PM +0200, Thomas Zimmermann wrote:
> Merge drm_fb_memcpy() and drm_fb_memcpy() into drm_fb_memcpy() that
One of these is drm_fb_memcpy_toio()
> uses struct iosys_map for buffers. The new function also supports
> multi-plane color formats. Convert all users of the original helpers.
A few comments in the patch below.
Sam
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_format_helper.c | 77 +
> drivers/gpu/drm/drm_mipi_dbi.c | 3 +-
> drivers/gpu/drm/gud/gud_pipe.c | 4 +-
> drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 11 +--
> drivers/gpu/drm/mgag200/mgag200_mode.c | 11 +--
> drivers/gpu/drm/tiny/cirrus.c | 21 +++---
> include/drm/drm_format_helper.h | 7 +-
> 7 files changed, 63 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 4d74d46ab155..49589b442f18 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -131,63 +131,48 @@ static int drm_fb_xfrm_toio(void __iomem *dst, unsigned
> long dst_pitch, unsigned
>
> /**
> * drm_fb_memcpy - Copy clip buffer
> - * @dst: Destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: Source buffer
> + * @dst: Array of destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
Document that this may be NULL, in which case the distance is considered
0.
> + * @vmap: Array of source buffers
It would have helped my understanding if this argument was named src,
so it is a little more obvious that we copy from src to dst.
Maybe document that data is copied from src based on the pitch info in
the framebuffer, and likewise the format_info in the framebuffer.
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> *
> * This function does not apply clipping on dst, i.e. the destination
> * is at the top-left corner.
> */
> -void drm_fb_memcpy(void *dst, unsigned int dst_pitch, const void *vaddr,
> -const struct drm_framebuffer *fb, const struct drm_rect
> *clip)
> +void drm_fb_memcpy(struct iosys_map *dst, const unsigned int *dst_pitch,
> +const struct iosys_map *vmap, const struct drm_framebuffer
> *fb,
> +const struct drm_rect *clip)
> {
> - unsigned int cpp = fb->format->cpp[0];
> - size_t len = (clip->x2 - clip->x1) * cpp;
> - unsigned int y, lines = clip->y2 - clip->y1;
> -
> - if (!dst_pitch)
> - dst_pitch = len;
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
This is used in several places in this series. What I read is that a static
variable is declared where the first element in the array is set to all zeroes.
But the other elements in the array are ignored - but since it is static
they are also set to 0 so we are good here.
In some cases I see it removed again, I did not check the end result if
we end up dropping them all again.
>
> - vaddr += clip_offset(clip, fb->pitches[0], cpp);
> - for (y = 0; y < lines; y++) {
> - memcpy(dst, vaddr, len);
> - vaddr += fb->pitches[0];
> - dst += dst_pitch;
> - }
> -}
> -EXPORT_SYMBOL(drm_fb_memcpy);
> -
> -/**
> - * drm_fb_memcpy_toio - Copy clip buffer
> - * @dst: Destination buffer (iomem)
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: Source buffer
> - * @fb: DRM framebuffer
> - * @clip: Clip rectangle area to copy
> - *
> - * This function does not apply clipping on dst, i.e. the destination
> - * is at the top-left corner.
> - */
> -void drm_fb_memcpy_toio(void __iomem *dst, unsigned int dst_pitch, const
> void *vaddr,
> - const struct drm_framebuffer *fb, const struct drm_rect
> *clip)
> -{
> - unsigned int cpp = fb->format->cpp[0];
> - size_t len = (clip->x2 - clip->x1) * cpp;
> - unsigned int y, lines = clip->y2 - clip->y1;
> + const struct drm_format_info *format = fb->format;
> + unsigned int i, y, lines = drm_rect_height(clip);
>
> if (!dst_pitch)
> - dst_pitch = len;
> -
> - vaddr += clip_offset(clip, fb->pitches[0], cpp);
> - for (y = 0; y < lines; y++) {
> - memcpy_toio(dst, vaddr, len);
> - vaddr += fb->pitches[0];
> - dst += dst_pitch;
> + dst_pitch = default_dst_pitch;
> +
> + for (i = 0; i < format->num_planes; ++i) {
> + unsigned int cpp_i = format->cpp[i];
unsigned int cpp_i = drm_format_info_bpp(format, i) / 8;
This avoid adding more uses of the deprecated cpp[] array.
> + size_t len_i = drm_rect_width(clip) * cpp_i;
> + unsigned int dst_pitch_i = dst_pitch[i];
> +
Re: [PATCH 01/12] drm/format-helper: Provide drm_fb_blit()
Hi Thomas,
On Wed, Jul 27, 2022 at 01:33:01PM +0200, Thomas Zimmermann wrote:
> Provide drm_fb_blit() that works with struct iosys_map. Update all
> users of drm_fb_blit_toio(), which required a destination buffer in
> I/O memory. The new function's interface works with multi-plane
> color formats, although the implementation only supports a single
> plane for now.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_format_helper.c | 39 ++---
> drivers/gpu/drm/tiny/simpledrm.c| 18 +++--
> include/drm/drm_format_helper.h | 7 +++---
> 3 files changed, 38 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index c6182b5de78b..4d74d46ab155 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -8,9 +8,10 @@
> * (at your option) any later version.
> */
>
> +#include
> +#include
> #include
> #include
> -#include
>
> #include
> #include
> @@ -545,9 +546,9 @@ void drm_fb_xrgb_to_gray8(void *dst, unsigned int
> dst_pitch, const void *vad
> EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
>
> /**
> - * drm_fb_blit_toio - Copy parts of a framebuffer to display memory
> - * @dst: The display memory to copy to
> - * @dst_pitch: Number of bytes between two consecutive scanlines
> within dst
> + * drm_fb_blit - Copy parts of a framebuffer to display memory
> + * @dst: Array of display-memory addresses to copy to
> + * @dst_pitch: Array of numbers of bytes between two consecutive
> scanlines within dst
The rename confused me since this function continue to operate only on
io memory, but I see that this is all fixed up in later patches.
It would be nice to have this mentioned in the changelog, just in case
someone else takes a deeper look at it.
With the changelog updated:
Reviewed-by: Sam Ravnborg
See also comments below.
> * @dst_format: FOURCC code of the display's color format
> * @vmap:The framebuffer memory to copy from
> * @fb: The framebuffer to copy from
> @@ -557,14 +558,18 @@ EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
> * formats of the display and the framebuffer mismatch, the blit function
> * will attempt to convert between them.
> *
> + * The parameters @dst, @dst_pitch and @vmap refer to arrays. Each array must
> + * have at least as many entries as there are planes in @dst_format's
> format. Each
> + * entry stores the value for the format's respective color plane at the
> same index.
> + *
> * Returns:
> * 0 on success, or
> * -EINVAL if the color-format conversion failed, or
> * a negative error code otherwise.
> */
> -int drm_fb_blit_toio(void __iomem *dst, unsigned int dst_pitch, uint32_t
> dst_format,
> - const void *vmap, const struct drm_framebuffer *fb,
> - const struct drm_rect *clip)
> +int drm_fb_blit(struct iosys_map *dst, const unsigned int *dst_pitch,
> uint32_t dst_format,
> + const struct iosys_map *vmap, const struct drm_framebuffer *fb,
> + const struct drm_rect *clip)
> {
> uint32_t fb_format = fb->format->format;
>
> @@ -579,30 +584,35 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int
> dst_pitch, uint32_t dst_for
> dst_format = DRM_FORMAT_XRGB2101010;
>
> if (dst_format == fb_format) {
> - drm_fb_memcpy_toio(dst, dst_pitch, vmap, fb, clip);
> + drm_fb_memcpy_toio(dst[0].vaddr_iomem, dst_pitch[0],
> vmap[0].vaddr, fb, clip);
> return 0;
>
> } else if (dst_format == DRM_FORMAT_RGB565) {
> if (fb_format == DRM_FORMAT_XRGB) {
> - drm_fb_xrgb_to_rgb565_toio(dst, dst_pitch, vmap,
> fb, clip, false);
> + drm_fb_xrgb_to_rgb565_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> +vmap[0].vaddr, fb, clip,
> false);
> return 0;
> }
> } else if (dst_format == DRM_FORMAT_RGB888) {
> if (fb_format == DRM_FORMAT_XRGB) {
> - drm_fb_xrgb_to_rgb888_toio(dst, dst_pitch, vmap,
> fb, clip);
> + drm_fb_xrgb_to_rgb888_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> +vmap[0].vaddr, fb, clip);
> return 0;
> }
> } else if (dst_format == DRM_FORMAT_XRGB) {
> if (fb_format == DRM_FORMAT_RGB888) {
> - drm_fb_rgb888
Re: [PATCH v2 1/2] drm: Add a drm_drv_enabled() to check if drivers should be enabled
Hi Javier,
>
> >>>
> >>> - if (vgacon_text_force() && i915_modparams.modeset == -1)
> >>> + ret = drm_drv_enabled();
> >>
> >> You pass the local driver variable here - which looks wrong as this is
> >> not the same as the driver variable declared in another file.
> >
>
> Yes, Jani mentioned it already. I got confused and thought that the driver
> variable was also defined in the same compilation unit...
>
> Maybe I could squash the following change?
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index b18a250e5d2e..b8f399b76363 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -89,7 +89,7 @@
> #include "intel_region_ttm.h"
> #include "vlv_suspend.h"
>
> -static const struct drm_driver driver;
> +const struct drm_driver driver;
No, variables with such a generic name will clash.
Just add a
const drm_driver * i915_drm_driver(void)
{
return
}
And then use this function to access the drm_driver variable.
Sam
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 1/2] drm: Add a drm_drv_enabled() to check if drivers should be enabled
Hi Javier,
On Thu, Nov 04, 2021 at 05:07:06PM +0100, Javier Martinez Canillas wrote:
> Some DRM drivers check the vgacon_text_force() function return value as an
> indication on whether they should be allowed to be enabled or not.
>
> This function returns true if the nomodeset kernel command line parameter
> was set. But there may be other conditions besides this to determine if a
> driver should be enabled.
>
> Let's add a drm_drv_enabled() helper function to encapsulate that logic so
> can be later extended if needed, without having to modify all the drivers.
>
> Also, while being there do some cleanup. The vgacon_text_force() function
> is guarded by CONFIG_VGA_CONSOLE and there's no need for callers to do it.
>
> Suggested-by: Thomas Zimmermann
> Signed-off-by: Javier Martinez Canillas
> ---
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 8214a0b1ab7f..3fb567d62881 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -975,6 +975,26 @@ int drm_dev_set_unique(struct drm_device *dev, const
> char *name)
> }
> EXPORT_SYMBOL(drm_dev_set_unique);
>
> +/**
> + * drm_drv_enabled - Checks if a DRM driver can be enabled
> + * @driver: DRM driver to check
> + *
> + * Checks whether a DRM driver can be enabled or not. This may be the case
> + * if the "nomodeset" kernel command line parameter is used.
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int drm_drv_enabled(const struct drm_driver *driver)
> +{
> + if (vgacon_text_force()) {
> + DRM_INFO("%s driver is disabled\n", driver->name);
DRM_INFO is deprecated, please do not use it in new code.
Also other users had an error message and not just info - is info
enough?
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_drv_enabled);
> +
> /*
> * DRM Core
> * The DRM core module initializes all global DRM objects and makes them
> diff --git a/drivers/gpu/drm/i915/i915_module.c
> b/drivers/gpu/drm/i915/i915_module.c
> index ab2295dd4500..45cb3e540eff 100644
> --- a/drivers/gpu/drm/i915/i915_module.c
> +++ b/drivers/gpu/drm/i915/i915_module.c
> @@ -18,9 +18,12 @@
> #include "i915_selftest.h"
> #include "i915_vma.h"
>
> +static const struct drm_driver driver;
Hmmm...
> +
> static int i915_check_nomodeset(void)
> {
> bool use_kms = true;
> + int ret;
>
> /*
>* Enable KMS by default, unless explicitly overriden by
> @@ -31,7 +34,8 @@ static int i915_check_nomodeset(void)
> if (i915_modparams.modeset == 0)
> use_kms = false;
>
> - if (vgacon_text_force() && i915_modparams.modeset == -1)
> + ret = drm_drv_enabled();
You pass the local driver variable here - which looks wrong as this is
not the same as the driver variable declared in another file.
Maybe move the check to new function you can add to init_funcs,
and locate the new function in i915_drv - so it has access to driver?
Sam
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 1/9] drm/format-helper: Export drm_fb_clip_offset()
Hi Thomas,
On Fri, Oct 22, 2021 at 03:28:21PM +0200, Thomas Zimmermann wrote:
> Provide a function that computes the offset into a blit destination
> buffer. This will allow to move destination-buffer clipping into the
> format-helper callers.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_format_helper.c | 10 --
> include/drm/drm_format_helper.h | 4
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 69fde60e36b3..28e9d0d89270 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -17,12 +17,18 @@
> #include
> #include
>
> -static unsigned int clip_offset(struct drm_rect *clip,
> - unsigned int pitch, unsigned int cpp)
> +static unsigned int clip_offset(const struct drm_rect *clip, unsigned int
> pitch, unsigned int cpp)
> {
> return clip->y1 * pitch + clip->x1 * cpp;
> }
>
> +unsigned long drm_fb_clip_offset(unsigned int pitch, const struct
> drm_format_info *format,
> + const struct drm_rect *clip)
> +{
> + return clip_offset(clip, pitch, format->cpp[0]);
> +}
> +EXPORT_SYMBOL(drm_fb_clip_offset);
Exported functions are expected to have kernel-doc documentation.
Just copy more or less from the changelog I think.
Anywhere else (I looked in struct drm_framebuffer) we only need unsigned
int for offsets and width/length - so I cannot see why we do an unsigned
int => unsigned long conversion here.
Sam
> +
> /**
> * drm_fb_memcpy - Copy clip buffer
> * @dst: Destination buffer
> diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
> index e86925cf07b9..90b9bd9ecb83 100644
> --- a/include/drm/drm_format_helper.h
> +++ b/include/drm/drm_format_helper.h
> @@ -6,9 +6,13 @@
> #ifndef __LINUX_DRM_FORMAT_HELPER_H
> #define __LINUX_DRM_FORMAT_HELPER_H
>
> +struct drm_format_info;
> struct drm_framebuffer;
> struct drm_rect;
>
> +unsigned long drm_fb_clip_offset(unsigned int pitch, const struct
> drm_format_info *format,
> + const struct drm_rect *clip);
> +
> void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
> struct drm_rect *clip);
> void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch, void
> *vaddr,
> --
> 2.33.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/9] drm/simpledrm: Enable damage clips and virtual screens
Hi Thomas,
On Fri, Oct 22, 2021 at 03:28:20PM +0200, Thomas Zimmermann wrote:
> Enable FB_DAMAGE_CLIPS with simpledrm for improved performance and/or
> less overhead. With this in place, add support for virtual screens
> (i.e., framebuffers that are larger than the display resolution). This
> also enables fbdev panning and page flipping.
>
> After the discussion and bug fixing wrt to fbdev overallocation, I
> decided to add full support for this to simpledrm. Patches #1 to #5
> change the format-helper functions accordingly. Destination buffers
> are now clipped by the caller and all functions support a similar
> feature set. This has some fallout in various drivers.
>
> Patch #6 change fbdev emulation to support overallocation with
> shadow buffers, even if the hardware buffer would be too small.
This change is very welcome - I hope it will solve the problem
Alistair experience - see:
https://lore.kernel.org/all/cakmqykpcp45o5_gjcfwus8ju4nrdnjaels7oyae4j-leuw+...@mail.gmail.com/
Sam
>
> Patch #7 and #8 update simpledrm to enable damage clipping and virtual
> screen sizes. Both feature go hand in hand, sort of. For shadow-
> buffered planes, the DRM framebuffer lives in system memory. So the
> maximum size of the virtual screen is somewhat arbitrary. We add two
> constants for resonable maximum width and height of 4096 each.
>
> Patch #9 adds documentation and a TODO item.
>
> Tested with simpledrm. I also ran the recently posted fbdev panning
> tests to make sure that the fbdev overallocation works correctly. [1]
>
> [1] https://lists.freedesktop.org/archives/igt-dev/2021-October/036642.html
>
> Thomas Zimmermann (9):
> drm/format-helper: Export drm_fb_clip_offset()
> drm/format-helper: Rework format-helper memcpy functions
> drm/format-helper: Add destination-buffer pitch to drm_fb_swab()
> drm/format-helper: Rework format-helper conversion functions
> drm/format-helper: Streamline blit-helper interface
> drm/fb-helper: Allocate shadow buffer of surface height
> drm/simpledrm: Enable FB_DAMAGE_CLIPS property
> drm/simpledrm: Support virtual screen sizes
> drm: Clarify semantics of struct
> drm_mode_config.{min,max}_{width,height}
>
> Documentation/gpu/todo.rst | 15 ++
> drivers/gpu/drm/drm_fb_helper.c | 2 +-
> drivers/gpu/drm/drm_format_helper.c | 236 ++--
> drivers/gpu/drm/drm_mipi_dbi.c | 6 +-
> drivers/gpu/drm/gud/gud_pipe.c | 14 +-
> drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 5 +-
> drivers/gpu/drm/mgag200/mgag200_mode.c | 4 +-
> drivers/gpu/drm/tiny/cirrus.c | 24 +-
> drivers/gpu/drm/tiny/repaper.c | 2 +-
> drivers/gpu/drm/tiny/simpledrm.c| 41 +++-
> drivers/gpu/drm/tiny/st7586.c | 2 +-
> include/drm/drm_format_helper.h | 58 ++---
> include/drm/drm_gem_atomic_helper.h | 18 ++
> include/drm/drm_mode_config.h | 13 ++
> 14 files changed, 254 insertions(+), 186 deletions(-)
>
> --
> 2.33.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 00/11] Provide offset-adjusted framebuffer mappings
Hi Thomas, On Tue, Aug 03, 2021 at 02:59:17PM +0200, Thomas Zimmermann wrote: > A framebuffer's offsets field might be non-zero to make the BO data > start at the specified offset within the BO's memory. Handle this > case in drm_gem_fb_vmap() and update all callers. So far, many drivers > ignore the offsets, which can lead to visual artifacts. > > Patch 1 adds an optional argument to drm_gem_fb_vmap() to return the > offset-adjusted data address for use with shadow-buffered planes. > > Patches 3 and 11 convert gud and vkms, which are the other callers of > drm_gem_fb_vmap(). For gud, it's just a cleanup. Vkms will handle the > framebuffer offsets correctly for its input and output framebuffers. > > The other patches convert users of shadow-buffered planes to use the > data address. After conversion, each driver will use the correct data > for non-zero offsets. > > drm/ast: Use offset-adjusted shadow-plane mappings > drm/gud: Get offset-adjusted mapping from drm_gem_fb_vmap() > drm/hyperv: Use offset-adjusted shadow-plane mappings > drm/mgag200: Use offset-adjusted shadow-plane mappings > drm/cirrus: Use offset-adjusted shadow-plane mappings > drm/gm12u320: Use offset-adjusted shadow-plane mappings > drm/simpledrm: Use offset-adjusted shadow-plane mapping > drm/udl: Use offset-adjusted shadow-plane mapping > drm/vbox: Use offset-adjusted shadow-plane mappings > drm/vkms: Use offset-adjusted shadow-plane mappings and output Everything looked good while reading through the patches. I cannot say if everything was properly converted but the patches looked good. So they are all: Acked-by: Sam Ravnborg There was a few TODO comments visible aboput using the mapping api properly. I assume this is coming in a later patch set.. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 01/11] drm/gem: Provide offset-adjusted framebuffer BO mappings
Hi Thomas,
On Tue, Aug 03, 2021 at 02:59:18PM +0200, Thomas Zimmermann wrote:
> Add an additional argument to drm_gem_fb_vmap() to return each BO's
> mapping adjusted by the rsp offset. Update all callers.
rsp? respective?
>
> The newly returned values point to the first by of the data stored
by => byte
> in the framebuffer BOs. Drivers that access the BO data should use
> it.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_gem_atomic_helper.c | 2 +-
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 17 -
> drivers/gpu/drm/gud/gud_pipe.c | 2 +-
> drivers/gpu/drm/vkms/vkms_writeback.c| 2 +-
> include/drm/drm_gem_atomic_helper.h | 8
> include/drm/drm_gem_framebuffer_helper.h | 3 ++-
> 6 files changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c
> b/drivers/gpu/drm/drm_gem_atomic_helper.c
> index b1cc19e47165..8410ec3c5db0 100644
> --- a/drivers/gpu/drm/drm_gem_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
> @@ -339,7 +339,7 @@ int drm_gem_prepare_shadow_fb(struct drm_plane *plane,
> struct drm_plane_state *p
> if (ret)
> return ret;
>
> - return drm_gem_fb_vmap(fb, shadow_plane_state->map);
> + return drm_gem_fb_vmap(fb, shadow_plane_state->map,
> shadow_plane_state->data);
> }
> EXPORT_SYMBOL(drm_gem_prepare_shadow_fb);
>
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index 02928607a716..7f2bbe4f0053 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -316,19 +316,25 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_create_with_dirty);
> * drm_gem_fb_vmap - maps all framebuffer BOs into kernel address space
> * @fb: the framebuffer
> * @map: returns the mapping's address for each BO
> + * @data: returns the data address for each BO, can be NULL
> *
> * This function maps all buffer objects of the given framebuffer into
> * kernel address space and stores them in struct dma_buf_map. If the
> * mapping operation fails for one of the BOs, the function unmaps the
> * already established mappings automatically.
> *
> + * Callers that want to access a BO's stored data should pass @data.
> + * The argument returns the addresses of the data stored in each BO. This
> + * is different from @map if the framebuffer's offsets field is non-zero.
> + *
> * See drm_gem_fb_vunmap() for unmapping.
> *
> * Returns:
> * 0 on success, or a negative errno code otherwise.
> */
> int drm_gem_fb_vmap(struct drm_framebuffer *fb,
> - struct dma_buf_map map[static DRM_FORMAT_MAX_PLANES])
> + struct dma_buf_map map[static DRM_FORMAT_MAX_PLANES],
> + struct dma_buf_map data[DRM_FORMAT_MAX_PLANES])
> {
> struct drm_gem_object *obj;
> unsigned int i;
> @@ -345,6 +351,15 @@ int drm_gem_fb_vmap(struct drm_framebuffer *fb,
> goto err_drm_gem_vunmap;
> }
>
> + if (data) {
> + for (i = 0; i < DRM_FORMAT_MAX_PLANES; ++i) {
> + memcpy([i], [i], sizeof(data[i]));
> + if (dma_buf_map_is_null([i]))
> + continue;
> + dma_buf_map_incr([i], fb->offsets[i]);
> + }
> + }
> +
> return 0;
>
> err_drm_gem_vunmap:
> diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
> index 7e009f562b30..6270a1a32a65 100644
> --- a/drivers/gpu/drm/gud/gud_pipe.c
> +++ b/drivers/gpu/drm/gud/gud_pipe.c
> @@ -162,7 +162,7 @@ static int gud_prep_flush(struct gud_device *gdrm, struct
> drm_framebuffer *fb,
> if (len > gdrm->bulk_len)
> return -E2BIG;
>
> - ret = drm_gem_fb_vmap(fb, map);
> + ret = drm_gem_fb_vmap(fb, map, NULL);
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
> b/drivers/gpu/drm/vkms/vkms_writeback.c
> index 425b6c6b8cad..3a8e2ed93e7c 100644
> --- a/drivers/gpu/drm/vkms/vkms_writeback.c
> +++ b/drivers/gpu/drm/vkms/vkms_writeback.c
> @@ -75,7 +75,7 @@ static int vkms_wb_prepare_job(struct
> drm_writeback_connector *wb_connector,
> if (!vkmsjob)
> return -ENOMEM;
>
> - ret = drm_gem_fb_vmap(job->fb, vkmsjob->map);
> + ret = drm_gem_fb_vmap(job->fb, vkmsjob->map, NULL);
> if (ret) {
> DRM_ERROR("vmap failed: %d\n", ret);
> goto err_kfr
Re: [PATCH] drm/qxl: Convert to Linux IRQ interfaces
On Tue, Jul 06, 2021 at 09:47:35AM +0200, Thomas Zimmermann wrote: > Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's > IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers > don't benefit from using it. > > Signed-off-by: Thomas Zimmermann Looks correct, Acked-by: Sam Ravnborg Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 00/15] drm: Move struct drm_device.pdev to legacy
Hi Thomas. Nice clean-up series - quite an effort to move one member to deprecated! I have read through most of the patches. I left a few notes in my replies but nothing buggy. Just nitpicks. On Tue, Nov 24, 2020 at 12:38:09PM +0100, Thomas Zimmermann wrote: > The pdev field in struct drm_device points to a PCI device structure and > goes back to UMS-only days when all DRM drivers where for PCI devices. > Meanwhile we also support USB, SPI and platform devices. Each of those > uses the generic device stored in struct drm_device.dev. > > To reduce duplications and remove the special case of PCI, this patchset > converts all modesetting drivers from pdev to dev and makes pdev a field > for legacy UMS drivers. > > For PCI devices, the pointer in struct drm_device.dev can be upcasted to > struct pci_device; or tested for PCI with dev_is_pci(). In several places > the code can use the dev field directly. > > After converting all drivers and the DRM core, the pdev fields becomes > only relevant for legacy drivers. In a later patchset, we may want to > convert these as well and remove pdev entirely. > > The patchset touches many files, but the individual changes are mostly > trivial. I suggest to merge each driver's patch through the respective > tree and later the rest through drm-misc-next. > > Thomas Zimmermann (15): > drm/amdgpu: Remove references to struct drm_device.pdev > drm/ast: Remove references to struct drm_device.pdev > drm/bochs: Remove references to struct drm_device.pdev > drm/cirrus: Remove references to struct drm_device.pdev > drm/gma500: Remove references to struct drm_device.pdev > drm/hibmc: Remove references to struct drm_device.pdev > drm/mgag200: Remove references to struct drm_device.pdev > drm/qxl: Remove references to struct drm_device.pdev > drm/vboxvideo: Remove references to struct drm_device.pdev > drm/virtgpu: Remove references to struct drm_device.pdev > drm/vmwgfx: Remove references to struct drm_device.pdev > drm: Upcast struct drm_device.dev to struct pci_device; replace pdev All above are: Acked-by: Sam Ravnborg > drm/nouveau: Remove references to struct drm_device.pdev I lost my confidence in my reading of this code. > drm/i915: Remove references to struct drm_device.pdev > drm/radeon: Remove references to struct drm_device.pdev I did not look at these at all. I hope someone else find time to do so. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 15/15] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev
Hi Thomas,
On Tue, Nov 24, 2020 at 12:38:24PM +0100, Thomas Zimmermann wrote:
> We have DRM drivers based on USB, SPI and platform devices. All of them
> are fine with storing their device reference in struct drm_device.dev.
> PCI devices should be no exception. Therefore struct drm_device.pdev is
> deprecated.
>
> Instead upcast from struct drm_device.dev with to_pci_dev(). PCI-specific
> code can use dev_is_pci() to test for a PCI device. This patch changes
> the DRM core code and documentation accordingly. Struct drm_device.pdev
> is being moved to legacy status.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_agpsupport.c | 9 ++---
> drivers/gpu/drm/drm_bufs.c | 4 ++--
> drivers/gpu/drm/drm_edid.c | 7 ++-
> drivers/gpu/drm/drm_irq.c| 12 +++-
> drivers/gpu/drm/drm_pci.c| 26 +++---
> drivers/gpu/drm/drm_vm.c | 2 +-
> include/drm/drm_device.h | 12 +---
> 7 files changed, 46 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_agpsupport.c
> b/drivers/gpu/drm/drm_agpsupport.c
> index 4c7ad46fdd21..a4040fe4f4ba 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -103,11 +103,13 @@ int drm_agp_info_ioctl(struct drm_device *dev, void
> *data,
> */
> int drm_agp_acquire(struct drm_device *dev)
> {
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> +
> if (!dev->agp)
> return -ENODEV;
> if (dev->agp->acquired)
> return -EBUSY;
> - dev->agp->bridge = agp_backend_acquire(dev->pdev);
> + dev->agp->bridge = agp_backend_acquire(pdev);
> if (!dev->agp->bridge)
> return -ENODEV;
> dev->agp->acquired = 1;
> @@ -402,14 +404,15 @@ int drm_agp_free_ioctl(struct drm_device *dev, void
> *data,
> */
> struct drm_agp_head *drm_agp_init(struct drm_device *dev)
> {
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> struct drm_agp_head *head = NULL;
>
> head = kzalloc(sizeof(*head), GFP_KERNEL);
> if (!head)
> return NULL;
> - head->bridge = agp_find_bridge(dev->pdev);
> + head->bridge = agp_find_bridge(pdev);
> if (!head->bridge) {
> - head->bridge = agp_backend_acquire(dev->pdev);
> + head->bridge = agp_backend_acquire(pdev);
> if (!head->bridge) {
> kfree(head);
> return NULL;
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index 7a01d0918861..1da8b360b60a 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -325,7 +325,7 @@ static int drm_addmap_core(struct drm_device *dev,
> resource_size_t offset,
>* As we're limiting the address to 2^32-1 (or less),
>* casting it down to 32 bits is no problem, but we
>* need to point to a 64bit variable first. */
> - map->handle = dma_alloc_coherent(>pdev->dev,
> + map->handle = dma_alloc_coherent(dev->dev,
>map->size,
>>offset,
>GFP_KERNEL);
> @@ -555,7 +555,7 @@ int drm_legacy_rmmap_locked(struct drm_device *dev,
> struct drm_local_map *map)
> case _DRM_SCATTER_GATHER:
> break;
> case _DRM_CONSISTENT:
> - dma_free_coherent(>pdev->dev,
> + dma_free_coherent(dev->dev,
> map->size,
> map->handle,
> map->offset);
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 74f5a3197214..555a04ce2179 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -2075,9 +2076,13 @@ EXPORT_SYMBOL(drm_get_edid);
> struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
>struct i2c_adapter *adapter)
> {
> - struct pci_dev *pdev = connector->dev->pdev;
> + struct drm_device *dev = connector->dev;
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> struct edid *edid;
Maybe add a comment that explain why this can trigger - so people are
helped it they are catched by this.
As it is now it is not even mentioned in the changelog.
> + if (drm_WARN_ON_ONCE(dev, !dev_is_pci(dev->dev)))
> + return NULL;
> +
> vga_switcheroo_lock_ddc(pdev);
> edid = drm_get_edid(connector, adapter);
> vga_switcheroo_unlock_ddc(pdev);
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 09d6e9e2e075..22986a9a593b 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -122,7 +122,7 @@ int drm_irq_install(struct drm_device *dev, int
Re: [PATCH 09/15] drm/nouveau: Remove references to struct drm_device.pdev
Hi Thomas.
On Tue, Nov 24, 2020 at 12:38:18PM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert nouveau to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Ben Skeggs
Suggestion to an alternative implmentation below.
> ---
> drivers/gpu/drm/nouveau/dispnv04/arb.c | 12 +++-
> drivers/gpu/drm/nouveau/dispnv04/disp.h | 14 --
> drivers/gpu/drm/nouveau/dispnv04/hw.c | 10 ++
> drivers/gpu/drm/nouveau/nouveau_abi16.c | 7 ---
> drivers/gpu/drm/nouveau/nouveau_acpi.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_bios.c | 11 ---
> drivers/gpu/drm/nouveau/nouveau_connector.c | 10 ++
> drivers/gpu/drm/nouveau/nouveau_drm.c | 5 ++---
> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 6 --
> drivers/gpu/drm/nouveau/nouveau_vga.c | 20
> 10 files changed, 58 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
> b/drivers/gpu/drm/nouveau/nouveau_bios.c
> index d204ea8a5618..7cc683b8dc7a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bios.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
> @@ -110,6 +110,9 @@ static int call_lvds_manufacturer_script(struct
> drm_device *dev, struct dcb_outp
> struct nvbios *bios = >vbios;
> uint8_t sub = bios->data[bios->fp.xlated_entry + script] +
> (bios->fp.link_c_increment && dcbent->or & DCB_OUTPUT_C ? 1 : 0);
> uint16_t scriptofs = ROM16(bios->data[bios->init_script_tbls_ptr + sub
> * 2]);
> +#ifdef __powerpc__
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> +#endif
Or
int device = 0;
>
> if (!bios->fp.xlated_entry || !sub || !scriptofs)
> return -EINVAL;
> @@ -123,8 +126,8 @@ static int call_lvds_manufacturer_script(struct
> drm_device *dev, struct dcb_outp
> #ifdef __powerpc__
> /* Powerbook specific quirks */
device = to_pci_dev(dev->dev)->device;
if (script == LVDS_RESET && (device == 0x0179 || device == 0x0189 ||
device == 0x0329))
> if (script == LVDS_RESET &&
> - (dev->pdev->device == 0x0179 || dev->pdev->device == 0x0189 ||
> - dev->pdev->device == 0x0329))
> + (pdev->device == 0x0179 || pdev->device == 0x0189 ||
> + pdev->device == 0x0329))
> nv_write_tmds(dev, dcbent->or, 0, 0x02, 0x72);
> #endif
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index 24ec5339efb4..4fc0fa696461 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -396,7 +396,9 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
> NV_INFO(drm, "allocated %dx%d fb: 0x%llx, bo %p\n",
> fb->width, fb->height, nvbo->offset, nvbo);
>
> - vga_switcheroo_client_fb_set(dev->pdev, info);
> + if (dev_is_pci(dev->dev))
> + vga_switcheroo_client_fb_set(to_pci_dev(dev->dev), info);
> +
I cannot see why dev_is_pci() is needed here.
So I am obviously missing something :-(
> return 0;
>
> out_unlock:
> @@ -548,7 +550,7 @@ nouveau_fbcon_init(struct drm_device *dev)
> int ret;
>
> if (!dev->mode_config.num_crtc ||
> - (dev->pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> + (to_pci_dev(dev->dev)->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> return 0;
>
> fbcon = kzalloc(sizeof(struct nouveau_fbdev), GFP_KERNEL);
> diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
> b/drivers/gpu/drm/nouveau/nouveau_vga.c
> index c85dd8afa3c3..7c4b374b3eca 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_vga.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
> @@ -87,18 +87,20 @@ nouveau_vga_init(struct nouveau_drm *drm)
> {
> struct drm_device *dev = drm->dev;
> bool runtime = nouveau_pmops_runtime();
> + struct pci_dev *pdev;
>
> /* only relevant for PCI devices */
> - if (!dev->pdev)
> + if (!dev_is_pci(dev->dev))
> return;
> + pdev = to_pci_dev(dev->dev);
>
> - vga_client_register(dev->pdev, dev, NULL, nouveau_vga_set_decode);
> + vga_client_register(pdev, dev, NULL, nouveau_vga_set_decode);
>
> /* don't register Thunderbolt eGPU with vga_switcheroo */
> - if (pci_is_thunderbolt_attached(dev->pdev))
> + if (pci_is_thunderbolt_attached(pdev))
> return;
>
> - vga_switcheroo_register_client(dev->pdev, _switcheroo_ops,
> runtime);
> + vga_switcheroo_register_client(pdev, _switcheroo_ops, runtime);
>
> if (runtime && nouveau_is_v1_dsm() && !nouveau_is_optimus())
> vga_switcheroo_init_domain_pm_ops(drm->dev->dev,
> >vga_pm_domain);
> @@ -109,17 +111,19 @@ nouveau_vga_fini(struct nouveau_drm *drm)
> {
> struct drm_device *dev = drm->dev;
> bool runtime = nouveau_pmops_runtime();
> + struct pci_dev *pdev;
>
> /* only
Re: [PATCH 05/15] drm/gma500: Remove references to struct drm_device.pdev
Hi Thomas.
On Tue, Nov 24, 2020 at 12:38:14PM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert gma500 to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Patrik Jakobsson
This patch includes several whitespace changes too.
It would be nice to avoid these as the patch is already large enough.
Browsing the patch it was not so many, it looked like more in the start
of the patch.
Sam
> ---
> drivers/gpu/drm/gma500/cdv_device.c| 30 +++---
> drivers/gpu/drm/gma500/cdv_intel_crt.c | 3 +-
> drivers/gpu/drm/gma500/cdv_intel_lvds.c| 4 +--
> drivers/gpu/drm/gma500/framebuffer.c | 9 +++---
> drivers/gpu/drm/gma500/gma_device.c| 3 +-
> drivers/gpu/drm/gma500/gma_display.c | 4 +--
> drivers/gpu/drm/gma500/gtt.c | 20 ++--
> drivers/gpu/drm/gma500/intel_bios.c| 6 ++--
> drivers/gpu/drm/gma500/intel_gmbus.c | 4 +--
> drivers/gpu/drm/gma500/intel_i2c.c | 2 +-
> drivers/gpu/drm/gma500/mdfld_device.c | 4 ++-
> drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 8 ++---
> drivers/gpu/drm/gma500/mid_bios.c | 9 --
> drivers/gpu/drm/gma500/oaktrail_device.c | 5 +--
> drivers/gpu/drm/gma500/oaktrail_lvds.c | 2 +-
> drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c | 2 +-
> drivers/gpu/drm/gma500/opregion.c | 3 +-
> drivers/gpu/drm/gma500/power.c | 13
> drivers/gpu/drm/gma500/psb_drv.c | 16 +-
> drivers/gpu/drm/gma500/psb_drv.h | 8 ++---
> drivers/gpu/drm/gma500/psb_intel_lvds.c| 6 ++--
> drivers/gpu/drm/gma500/psb_intel_sdvo.c| 2 +-
> drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 36 +++---
> 23 files changed, 109 insertions(+), 90 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_device.c
> b/drivers/gpu/drm/gma500/cdv_device.c
> index e75293e4a52f..19e055dbd4c2 100644
> --- a/drivers/gpu/drm/gma500/cdv_device.c
> +++ b/drivers/gpu/drm/gma500/cdv_device.c
> @@ -95,13 +95,14 @@ static u32 cdv_get_max_backlight(struct drm_device *dev)
> static int cdv_get_brightness(struct backlight_device *bd)
> {
> struct drm_device *dev = bl_get_data(bd);
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> u32 val = REG_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
>
> if (cdv_backlight_combination_mode(dev)) {
> u8 lbpc;
>
> val &= ~1;
> - pci_read_config_byte(dev->pdev, 0xF4, );
> + pci_read_config_byte(pdev, 0xF4, );
> val *= lbpc;
> }
> return (val * 100)/cdv_get_max_backlight(dev);
> @@ -111,6 +112,7 @@ static int cdv_get_brightness(struct backlight_device *bd)
> static int cdv_set_brightness(struct backlight_device *bd)
> {
> struct drm_device *dev = bl_get_data(bd);
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> int level = bd->props.brightness;
> u32 blc_pwm_ctl;
>
> @@ -128,7 +130,7 @@ static int cdv_set_brightness(struct backlight_device *bd)
> lbpc = level * 0xfe / max + 1;
> level /= lbpc;
>
> - pci_write_config_byte(dev->pdev, 0xF4, lbpc);
> + pci_write_config_byte(pdev, 0xF4, lbpc);
> }
>
> blc_pwm_ctl = REG_READ(BLC_PWM_CTL) & ~BACKLIGHT_DUTY_CYCLE_MASK;
> @@ -205,8 +207,9 @@ static inline void CDV_MSG_WRITE32(int domain, uint port,
> uint offset,
> static void cdv_init_pm(struct drm_device *dev)
> {
> struct drm_psb_private *dev_priv = dev->dev_private;
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> u32 pwr_cnt;
> - int domain = pci_domain_nr(dev->pdev->bus);
> + int domain = pci_domain_nr(pdev->bus);
> int i;
>
> dev_priv->apm_base = CDV_MSG_READ32(domain, PSB_PUNIT_PORT,
> @@ -234,6 +237,8 @@ static void cdv_init_pm(struct drm_device *dev)
>
> static void cdv_errata(struct drm_device *dev)
> {
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> +
> /* Disable bonus launch.
>* CPU and GPU competes for memory and display misses updates and
>* flickers. Worst with dual core, dual displays.
> @@ -242,7 +247,7 @@ static void cdv_errata(struct drm_device *dev)
>* Bonus Launch to work around the issue, by degrading
>* performance.
>*/
> - CDV_MSG_WRITE32(pci_domain_nr(dev->pdev->bus), 3, 0x30, 0x08027108);
> + CDV_MSG_WRITE32(pci_domain_nr(pdev->bus), 3, 0x30, 0x08027108);
> }
>
> /**
> @@ -255,12 +260,13 @@ static void cdv_errata(struct drm_device *dev)
> static int cdv_save_display_registers(struct drm_device *dev)
> {
> struct drm_psb_private *dev_priv = dev->dev_private;
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> struct psb_save_area *regs = _priv->regs;
> struct drm_connector *connector;
>
> dev_dbg(dev->dev, "Saving GPU registers.\n");
>
Re: [PATCH v2 01/10] drm/fb-helper: Call dirty helper after writing to fbdev
On Fri, Nov 20, 2020 at 11:25:36AM +0100, Thomas Zimmermann wrote:
> If fbdev uses a shadow framebuffer, call the damage handler. Otherwise
> the update might not make it to the screen.
>
> v2:
> * mark virtual screen as dirty (Ville)
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 222ec45f4c69 ("drm/fb_helper: Support framebuffers in I/O memory")
> Cc: Thomas Zimmermann
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Gerd Hoffmann
> Cc: dri-de...@lists.freedesktop.org
> Cc: virtualization@lists.linux-foundation.org
Acked-by: Sam Ravnborg
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 000/141] Fix fall-through warnings for Clang
Hi James. > > > If none of the 140 patches here fix a real bug, and there is no > > > change to machine code then it sounds to me like a W=2 kind of a > > > warning. > > > > FWIW, this series has found at least one bug so far: > > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=kr...@mail.gmail.com/ > > > Well, it's a problem in an error leg, sure, but it's not a really > compelling reason for a 141 patch series, is it? All that fixing this > error will do is get the driver to print "oh dear there's a problem" > under four more conditions than it previously did. You are asking the wrong question here. Yuo should ask how many hours could have been saved by all the bugs people have been fighting with and then fixed *before* the code hit the kernel at all. My personal experience is that I, more than once, have had errors related to a missing break in my code. So this warnings is IMO a win. And if we are only ~100 patches to have it globally enabled then it is a no-brainer in my book. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm: remove unneeded break
Hi Tom On Mon, Oct 19, 2020 at 07:06:41PM +0200, Sam Ravnborg wrote: > Hi Tom > On Mon, Oct 19, 2020 at 09:31:15AM -0700, t...@redhat.com wrote: > > From: Tom Rix > > > > A break is not needed if it is preceded by a return or break > > > > Signed-off-by: Tom Rix > > Looks good and builds with no warnings. > > One of the diffs made me - "oh this looks wrong". But after I looked again > it was right and the resulting code is more readable - so good. > > Acked-by: Sam Ravnborg > > Was tempted to just apply to drm-misc-next but will give others the > opportunity to chime in. Thanks. Now applied to drm-misc-next - will show up in -next in a week or so. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/: Constify struct drm_driver
Hi Daniel. On Fri, Oct 23, 2020 at 06:04:44PM +0200, Daniel Vetter wrote: > Only the following drivers aren't converted: > - amdgpu, because of the driver_feature mangling due to virt support > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the > platforms where it's supported (i.e. again driver_feature mangling) > - vc4, again because of driver_feature mangling > - qxl, because the ioctl table is somewhere else and moving that is > maybe a bit too much, hence the num_ioctls assignment prevents a > const driver structure. My grepping turned up the following: - The example in drm_drv needs to be updated - legacy drivers, that are obviously not converted - but worth to mention above - arc is not converted and it is not legacy Maybe you have it covered in your big arc conversion patch? With the above fixed: Acked-by: Sam Ravnborg > > Note that for armada I also went ahead and made the ioctl array const. > > Only cc'ing the driver people who've not been converted (everyone else > is way too much). > > v2: Fix one misplaced const static, should be static const (0day) > > Cc: kernel test robot > Acked-by: Maxime Ripard > Signed-off-by: Daniel Vetter > Cc: Dave Airlie > Cc: Gerd Hoffmann > Cc: virtualization@lists.linux-foundation.org > Cc: Harry Wentland > Cc: Leo Li > Cc: Alex Deucher > Cc: Christian König > Cc: Eric Anholt > Cc: Maxime Ripard > Cc: Ben Skeggs > Cc: nouv...@lists.freedesktop.org > Signed-off-by: Daniel Vetter Hmm, so we have more than one Daniel in play here. Both the Intel guy and the ffwll guy - looks funny. Sam > --- > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +- > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > drivers/gpu/drm/armada/armada_drv.c | 7 +++ > drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +- > drivers/gpu/drm/ast/ast_drv.c| 2 +- > drivers/gpu/drm/ast/ast_drv.h| 2 +- > drivers/gpu/drm/ast/ast_main.c | 2 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- > drivers/gpu/drm/bochs/bochs_drv.c| 2 +- > drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++--- > drivers/gpu/drm/gma500/psb_drv.c | 4 ++-- > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- > drivers/gpu/drm/i915/i915_drv.c | 4 ++-- > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- > drivers/gpu/drm/imx/dcss/dcss-kms.c | 2 +- > drivers/gpu/drm/imx/imx-drm-core.c | 2 +- > drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +- > drivers/gpu/drm/lima/lima_drv.c | 2 +- > drivers/gpu/drm/mcde/mcde_drv.c | 2 +- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- > drivers/gpu/drm/meson/meson_drv.c| 2 +- > drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +- > drivers/gpu/drm/msm/msm_drv.c| 4 ++-- > drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +- > drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- > drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- > drivers/gpu/drm/pl111/pl111_drv.c| 2 +- > drivers/gpu/drm/radeon/radeon_drv.c | 4 ++-- > drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +- > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++-- > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- > drivers/gpu/drm/sti/sti_drv.c| 2 +- > drivers/gpu/drm/stm/drv.c| 2 +- > drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +- > drivers/gpu/drm/tegra/drm.c | 5 ++--- > drivers/gpu/drm/tidss/tidss_drv.c| 2 +- > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++-- > drivers/gpu/drm/tiny/cirrus.c| 2 +- > drivers/gpu/drm/tiny/gm12u320.c | 2 +- > drivers/gpu/drm/tiny/hx8357d.c | 2 +- > drivers/gpu/drm/tiny/ili9225.c | 2 +- > drivers/gpu/drm/tiny/ili9341.c | 2 +- > drivers/gpu/drm/tiny/ili9486.c | 2 +- > drivers/gpu/drm/tiny/mi0283qt.c | 2 +- > drivers/gpu/drm/tiny/repaper.c | 2 +- > drivers/gpu/drm/tiny/st7586.c| 2 +- > drivers/gpu/drm/tiny/st7735r.c | 2 +- > drivers/gpu/dr
Re: [PATCH v5 10/10] drm/fb_helper: Support framebuffers in I/O memory
Hi Thomas.
On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_ops test for the type of memory and call the rsp
> fb_sys_ of fb_cfb_ functions. Read and write operations are implemented
> internally by DRM's fbdev helper.
>
> For drivers that employ a shadow buffer, fbdev's blit function retrieves
> the framebuffer address as struct dma_buf_map, and uses dma_buf_map
> interfaces to access the buffer.
>
> The bochs driver on sparc64 uses a workaround to flag the framebuffer as
> I/O memory and avoid a HW exception. With the introduction of struct
> dma_buf_map, this is not required any longer. The patch removes the rsp
> code from both, bochs and fbdev.
>
> v5:
> * implement fb_read/fb_write internally (Daniel, Sam)
> v4:
> * move dma_buf_map changes into separate patch (Daniel)
> * TODO list: comment on fbdev updates (Daniel)
>
> Signed-off-by: Thomas Zimmermann
> Tested-by: Sam Ravnborg
Reviewed-by: Sam Ravnborg
But see a few comments below on naming for you to consider.
Sam
> ---
> Documentation/gpu/todo.rst| 19 ++-
> drivers/gpu/drm/bochs/bochs_kms.c | 1 -
> drivers/gpu/drm/drm_fb_helper.c | 227 --
> include/drm/drm_mode_config.h | 12 --
> 4 files changed, 230 insertions(+), 29 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 7e6fc3c04add..638b7f704339 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup()
>
>
> Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
> -atomic modesetting and GEM vmap support. Current generic fbdev emulation
> -expects the framebuffer in system memory (or system-like memory).
> +atomic modesetting and GEM vmap support. Historically, generic fbdev
> emulation
> +expected the framebuffer in system memory or system-like memory. By employing
> +struct dma_buf_map, drivers with frambuffers in I/O memory can be supported
> +as well.
>
> Contact: Maintainer of the driver you plan to convert
>
> Level: Intermediate
>
> +Reimplement functions in drm_fbdev_fb_ops without fbdev
> +---
> +
> +A number of callback functions in drm_fbdev_fb_ops could benefit from
> +being rewritten without dependencies on the fbdev module. Some of the
> +helpers could further benefit from using struct dma_buf_map instead of
> +raw pointers.
> +
> +Contact: Thomas Zimmermann , Daniel Vetter
> +
> +Level: Advanced
> +
> +
> drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
> -
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 13d0d04c4457..853081d186d5 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs)
> bochs->dev->mode_config.preferred_depth = 24;
> bochs->dev->mode_config.prefer_shadow = 0;
> bochs->dev->mode_config.prefer_shadow_fbdev = 1;
> - bochs->dev->mode_config.fbdev_use_iomem = true;
> bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
>
> bochs->dev->mode_config.funcs = _mode_funcs;
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 6212cd7cde1d..1d3180841778 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct
> work_struct *work)
> }
>
> static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
> - struct drm_clip_rect *clip)
> + struct drm_clip_rect *clip,
> + struct dma_buf_map *dst)
> {
> struct drm_framebuffer *fb = fb_helper->fb;
> unsigned int cpp = fb->format->cpp[0];
> size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
> void *src = fb_helper->fbdev->screen_buffer + offset;
> - void *dst = fb_helper->buffer->map.vaddr + offset;
> size_t len = (clip->x2 - clip->x1) * cpp;
> unsigned int y;
>
Re: [PATCH] drm: remove unneeded break
Hi Tom On Mon, Oct 19, 2020 at 09:31:15AM -0700, t...@redhat.com wrote: > From: Tom Rix > > A break is not needed if it is preceded by a return or break > > Signed-off-by: Tom Rix Looks good and builds with no warnings. One of the diffs made me - "oh this looks wrong". But after I looked again it was right and the resulting code is more readable - so good. Acked-by: Sam Ravnborg Was tempted to just apply to drm-misc-next but will give others the opportunity to chime in. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 10/10] drm/fb_helper: Support framebuffers in I/O memory
On Fri, Oct 16, 2020 at 02:19:42PM +0200, Thomas Zimmermann wrote: > Hi > > On Fri, 16 Oct 2020 14:03:47 +0200 Sam Ravnborg wrote: > > > Hi Thomas. > > > > On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote: > > > At least sparc64 requires I/O-specific access to framebuffers. This > > > patch updates the fbdev console accordingly. > > > > > > For drivers with direct access to the framebuffer memory, the callback > > > functions in struct fb_ops test for the type of memory and call the rsp > > > fb_sys_ of fb_cfb_ functions. > > > > > > For drivers that employ a shadow buffer, fbdev's blit function retrieves > > > the framebuffer address as struct dma_buf_map, and uses dma_buf_map > > > interfaces to access the buffer. > > > > > > The bochs driver on sparc64 uses a workaround to flag the framebuffer as > > > I/O memory and avoid a HW exception. With the introduction of struct > > > dma_buf_map, this is not required any longer. The patch removes the rsp > > > code from both, bochs and fbdev. > > > > > > v4: > > > * move dma_buf_map changes into separate patch (Daniel) > > > * TODO list: comment on fbdev updates (Daniel) > > > > > > Signed-off-by: Thomas Zimmermann > > > > The original workaround fixed it so we could run qemu with the > > -nographic option. > > > > So I went ahead and tried to run quemu version: > > v5.0.0-1970-g0b100c8e72-dirty. > > And with the BOCHS driver built-in. > > > > With the following command line: > > qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -nographic > > > > Behaviour was the same before and after applying this patch. > > (panic due to VFS: Unable to mount root fs on unknown-block(0,0)) > > So I consider it fixed for real now and not just a workaround. > > > > I also tested with: > > qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -serial > > stdio > > > > and it worked in both cases too. > > FTR, you booted a kernel and got graphics output. The error is simply that > there was no disk to mount? The short version "Yes". The longer version: With "qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -serial stdio" I got graphical output - one penguin. With "qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -nographic" I got no graphical output, as implied by the -nographic option. But the boot continued - where it would panic before when we accessed IO memory as system memory. In both cases I got an error because I had not specified any rootfs, so qemu failed to mount any rootfs. So expected. Sam > > Best regards > Thomas > > > > > All the comments above so future-me have an easier time finding how to > > reproduce. > > > > Tested-by: Sam Ravnborg > > > > Sam > > > > > --- > > > Documentation/gpu/todo.rst| 19 ++- > > > drivers/gpu/drm/bochs/bochs_kms.c | 1 - > > > drivers/gpu/drm/drm_fb_helper.c | 217 -- > > > include/drm/drm_mode_config.h | 12 -- > > > 4 files changed, 220 insertions(+), 29 deletions(-) > > > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > > index 7e6fc3c04add..638b7f704339 100644 > > > --- a/Documentation/gpu/todo.rst > > > +++ b/Documentation/gpu/todo.rst > > > @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup() > > > > > > > > > Most drivers can use drm_fbdev_generic_setup(). Driver have to implement > > > -atomic modesetting and GEM vmap support. Current generic fbdev emulation > > > -expects the framebuffer in system memory (or system-like memory). > > > +atomic modesetting and GEM vmap support. Historically, generic fbdev > > > emulation +expected the framebuffer in system memory or system-like > > > memory. By employing +struct dma_buf_map, drivers with frambuffers in I/O > > > memory can be supported +as well. > > > > > > Contact: Maintainer of the driver you plan to convert > > > > > > Level: Intermediate > > > > > > +Reimplement functions in drm_fbdev_fb_ops without fbdev > > > +--- > > > + > > > +A number of callback functions in drm_fbdev_fb_ops could benefit from > > > +being rewritten without depen
Re: [PATCH v4 10/10] drm/fb_helper: Support framebuffers in I/O memory
Hi Thomas. On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote: > At least sparc64 requires I/O-specific access to framebuffers. This > patch updates the fbdev console accordingly. > > For drivers with direct access to the framebuffer memory, the callback > functions in struct fb_ops test for the type of memory and call the rsp > fb_sys_ of fb_cfb_ functions. > > For drivers that employ a shadow buffer, fbdev's blit function retrieves > the framebuffer address as struct dma_buf_map, and uses dma_buf_map > interfaces to access the buffer. > > The bochs driver on sparc64 uses a workaround to flag the framebuffer as > I/O memory and avoid a HW exception. With the introduction of struct > dma_buf_map, this is not required any longer. The patch removes the rsp > code from both, bochs and fbdev. > > v4: > * move dma_buf_map changes into separate patch (Daniel) > * TODO list: comment on fbdev updates (Daniel) > > Signed-off-by: Thomas Zimmermann The original workaround fixed it so we could run qemu with the -nographic option. So I went ahead and tried to run quemu version: v5.0.0-1970-g0b100c8e72-dirty. And with the BOCHS driver built-in. With the following command line: qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -nographic Behaviour was the same before and after applying this patch. (panic due to VFS: Unable to mount root fs on unknown-block(0,0)) So I consider it fixed for real now and not just a workaround. I also tested with: qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -serial stdio and it worked in both cases too. All the comments above so future-me have an easier time finding how to reproduce. Tested-by: Sam Ravnborg Sam > --- > Documentation/gpu/todo.rst| 19 ++- > drivers/gpu/drm/bochs/bochs_kms.c | 1 - > drivers/gpu/drm/drm_fb_helper.c | 217 -- > include/drm/drm_mode_config.h | 12 -- > 4 files changed, 220 insertions(+), 29 deletions(-) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 7e6fc3c04add..638b7f704339 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup() > > > Most drivers can use drm_fbdev_generic_setup(). Driver have to implement > -atomic modesetting and GEM vmap support. Current generic fbdev emulation > -expects the framebuffer in system memory (or system-like memory). > +atomic modesetting and GEM vmap support. Historically, generic fbdev > emulation > +expected the framebuffer in system memory or system-like memory. By employing > +struct dma_buf_map, drivers with frambuffers in I/O memory can be supported > +as well. > > Contact: Maintainer of the driver you plan to convert > > Level: Intermediate > > +Reimplement functions in drm_fbdev_fb_ops without fbdev > +--- > + > +A number of callback functions in drm_fbdev_fb_ops could benefit from > +being rewritten without dependencies on the fbdev module. Some of the > +helpers could further benefit from using struct dma_buf_map instead of > +raw pointers. > + > +Contact: Thomas Zimmermann , Daniel Vetter > + > +Level: Advanced > + > + > drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup > - > > diff --git a/drivers/gpu/drm/bochs/bochs_kms.c > b/drivers/gpu/drm/bochs/bochs_kms.c > index 13d0d04c4457..853081d186d5 100644 > --- a/drivers/gpu/drm/bochs/bochs_kms.c > +++ b/drivers/gpu/drm/bochs/bochs_kms.c > @@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs) > bochs->dev->mode_config.preferred_depth = 24; > bochs->dev->mode_config.prefer_shadow = 0; > bochs->dev->mode_config.prefer_shadow_fbdev = 1; > - bochs->dev->mode_config.fbdev_use_iomem = true; > bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true; > > bochs->dev->mode_config.funcs = _mode_funcs; > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 6212cd7cde1d..462b0c130ebb 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct > work_struct *work) > } > > static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper, > - struct drm_clip_rect *clip) > + struct drm_clip_rect *clip, > + struct dma_bu
Re: [PATCH v4 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
>
> Signed-off-by: Thomas Zimmermann
> ---
> include/linux/dma-buf-map.h | 72 +++--
> 1 file changed, 62 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
> index 2e8bbecb5091..6ca0f304dda2 100644
> --- a/include/linux/dma-buf-map.h
> +++ b/include/linux/dma-buf-map.h
> @@ -32,6 +32,14 @@
> * accessing the buffer. Use the returned instance and the helper functions
> * to access the buffer's memory in the correct way.
> *
> + * The type :c:type:`struct dma_buf_map ` and its helpers are
> + * actually independent from the dma-buf infrastructure. When sharing buffers
> + * among devices, drivers have to know the location of the memory to access
> + * the buffers in a safe way. :c:type:`struct dma_buf_map `
> + * solves this problem for dma-buf and its users. If other drivers or
> + * sub-systems require similar functionality, the type could be generalized
> + * and moved to a more prominent header file.
> + *
> * Open-coding access to :c:type:`struct dma_buf_map ` is
> * considered bad style. Rather then accessing its fields directly, use one
> * of the provided helper functions, or implement your own. For example,
> @@ -51,6 +59,14 @@
> *
> * dma_buf_map_set_vaddr_iomem( 0xdeadbeaf);
> *
> + * Instances of struct dma_buf_map do not have to be cleaned up, but
> + * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
> + * always refer to system memory.
> + *
> + * .. code-block:: c
> + *
> + * dma_buf_map_clear();
> + *
> * Test if a mapping is valid with either dma_buf_map_is_set() or
> * dma_buf_map_is_null().
> *
> @@ -73,17 +89,19 @@
> * if (dma_buf_map_is_equal(_map, _map))
> * // always false
> *
> - * Instances of struct dma_buf_map do not have to be cleaned up, but
> - * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
> - * always refer to system memory.
> + * A set up instance of struct dma_buf_map can be used to access or
> manipulate
> + * the buffer memory. Depending on the location of the memory, the provided
> + * helpers will pick the correct operations. Data can be copied into the
> memory
> + * with dma_buf_map_memcpy_to(). The address can be manipulated with
> + * dma_buf_map_incr().
> *
> - * The type :c:type:`struct dma_buf_map ` and its helpers are
> - * actually independent from the dma-buf infrastructure. When sharing buffers
> - * among devices, drivers have to know the location of the memory to access
> - * the buffers in a safe way. :c:type:`struct dma_buf_map `
> - * solves this problem for dma-buf and its users. If other drivers or
> - * sub-systems require similar functionality, the type could be generalized
> - * and moved to a more prominent header file.
> + * .. code-block:: c
> + *
> + * const void *src = ...; // source buffer
> + * size_t len = ...; // length of src
> + *
> + * dma_buf_map_memcpy_to(, src, len);
> + * dma_buf_map_incr(, len); // go to first byte after the memcpy
> */
>
> /**
> @@ -210,4 +228,38 @@ static inline void dma_buf_map_clear(struct dma_buf_map
> *map)
> }
> }
>
> +/**
> + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
> + * @dst: The dma-buf mapping structure
> + * @src: The source buffer
> + * @len: The number of byte in src
> + *
> + * Copies data into a dma-buf mapping. The source buffer is in system
> + * memory. Depending on the buffer's location, the helper picks the correct
> + * method of accessing the memory.
> + */
> +static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const void
> *src, size_t len)
> +{
> + if (dst->is_iomem)
> + memcpy_toio(dst->vaddr_iomem, src, len);
> + else
> + memcpy(dst->vaddr, src, len);
sparc64 needs "#include " to build as is does not get
this via io.h
Sam
> +}
> +
> +/**
> + * dma_buf_map_incr - Increments the address stored in a dma-buf mapping
> + * @map: The dma-buf mapping structure
> + * @incr:The number of bytes to increment
> + *
> + * Increments the address stored in a dma-buf mapping. Depending on the
> + * buffer's location, the correct value will be updated.
> + */
> +static inline void dma_buf_map_incr(struct dma_buf_map *map, size_t incr)
> +{
> + if (map->is_iomem)
> + map->vaddr_iomem += incr;
> + else
> + map->vaddr += incr;
> +}
> +
> #endif /* __DMA_BUF_MAP_H__ */
> --
> 2.28.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 10/10] drm/fb_helper: Support framebuffers in I/O memory
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_ops test for the type of memory and call the rsp
> fb_sys_ of fb_cfb_ functions.
>
> For drivers that employ a shadow buffer, fbdev's blit function retrieves
> the framebuffer address as struct dma_buf_map, and uses dma_buf_map
> interfaces to access the buffer.
>
> The bochs driver on sparc64 uses a workaround to flag the framebuffer as
> I/O memory and avoid a HW exception. With the introduction of struct
> dma_buf_map, this is not required any longer. The patch removes the rsp
> code from both, bochs and fbdev.
>
> v4:
> * move dma_buf_map changes into separate patch (Daniel)
> * TODO list: comment on fbdev updates (Daniel)
I have been offline for a while so have not followed all the threads on
this. So may comments below may well be addressed but I failed to see
it.
If the point about fb_sync is already addressed/considered then:
Reviewed-by: Sam Ravnborg
> Signed-off-by: Thomas Zimmermann
> ---
> Documentation/gpu/todo.rst| 19 ++-
> drivers/gpu/drm/bochs/bochs_kms.c | 1 -
> drivers/gpu/drm/drm_fb_helper.c | 217 --
> include/drm/drm_mode_config.h | 12 --
> 4 files changed, 220 insertions(+), 29 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 7e6fc3c04add..638b7f704339 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup()
>
>
> Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
> -atomic modesetting and GEM vmap support. Current generic fbdev emulation
> -expects the framebuffer in system memory (or system-like memory).
> +atomic modesetting and GEM vmap support. Historically, generic fbdev
> emulation
> +expected the framebuffer in system memory or system-like memory. By employing
> +struct dma_buf_map, drivers with frambuffers in I/O memory can be supported
> +as well.
>
> Contact: Maintainer of the driver you plan to convert
>
> Level: Intermediate
>
> +Reimplement functions in drm_fbdev_fb_ops without fbdev
> +---
> +
> +A number of callback functions in drm_fbdev_fb_ops could benefit from
> +being rewritten without dependencies on the fbdev module. Some of the
> +helpers could further benefit from using struct dma_buf_map instead of
> +raw pointers.
> +
> +Contact: Thomas Zimmermann , Daniel Vetter
> +
> +Level: Advanced
> +
> +
> drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
> -
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 13d0d04c4457..853081d186d5 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs)
> bochs->dev->mode_config.preferred_depth = 24;
> bochs->dev->mode_config.prefer_shadow = 0;
> bochs->dev->mode_config.prefer_shadow_fbdev = 1;
> - bochs->dev->mode_config.fbdev_use_iomem = true;
> bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
>
> bochs->dev->mode_config.funcs = _mode_funcs;
Good to see this workaround gone again!
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 6212cd7cde1d..462b0c130ebb 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct
> work_struct *work)
> }
>
> static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
> - struct drm_clip_rect *clip)
> + struct drm_clip_rect *clip,
> + struct dma_buf_map *dst)
> {
> struct drm_framebuffer *fb = fb_helper->fb;
> unsigned int cpp = fb->format->cpp[0];
> size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
> void *src = fb_helper->fbdev->screen_buffer + offset;
> - void *dst = fb_helper->buffer->map.vaddr + offset;
> size_t len = (clip->x2 - clip->x1) * cpp;
> unsigned int y;
>
> - fo
Re: [PATCH v4 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
>
> Signed-off-by: Thomas Zimmermann
Looks good.
Reviewed-by: Sam Ravnborg
> ---
> include/linux/dma-buf-map.h | 72 +++--
> 1 file changed, 62 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
> index 2e8bbecb5091..6ca0f304dda2 100644
> --- a/include/linux/dma-buf-map.h
> +++ b/include/linux/dma-buf-map.h
> @@ -32,6 +32,14 @@
> * accessing the buffer. Use the returned instance and the helper functions
> * to access the buffer's memory in the correct way.
> *
> + * The type :c:type:`struct dma_buf_map ` and its helpers are
> + * actually independent from the dma-buf infrastructure. When sharing buffers
> + * among devices, drivers have to know the location of the memory to access
> + * the buffers in a safe way. :c:type:`struct dma_buf_map `
> + * solves this problem for dma-buf and its users. If other drivers or
> + * sub-systems require similar functionality, the type could be generalized
> + * and moved to a more prominent header file.
> + *
> * Open-coding access to :c:type:`struct dma_buf_map ` is
> * considered bad style. Rather then accessing its fields directly, use one
> * of the provided helper functions, or implement your own. For example,
> @@ -51,6 +59,14 @@
> *
> * dma_buf_map_set_vaddr_iomem( 0xdeadbeaf);
> *
> + * Instances of struct dma_buf_map do not have to be cleaned up, but
> + * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
> + * always refer to system memory.
> + *
> + * .. code-block:: c
> + *
> + * dma_buf_map_clear();
> + *
> * Test if a mapping is valid with either dma_buf_map_is_set() or
> * dma_buf_map_is_null().
> *
> @@ -73,17 +89,19 @@
> * if (dma_buf_map_is_equal(_map, _map))
> * // always false
> *
> - * Instances of struct dma_buf_map do not have to be cleaned up, but
> - * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
> - * always refer to system memory.
> + * A set up instance of struct dma_buf_map can be used to access or
> manipulate
> + * the buffer memory. Depending on the location of the memory, the provided
> + * helpers will pick the correct operations. Data can be copied into the
> memory
> + * with dma_buf_map_memcpy_to(). The address can be manipulated with
> + * dma_buf_map_incr().
> *
> - * The type :c:type:`struct dma_buf_map ` and its helpers are
> - * actually independent from the dma-buf infrastructure. When sharing buffers
> - * among devices, drivers have to know the location of the memory to access
> - * the buffers in a safe way. :c:type:`struct dma_buf_map `
> - * solves this problem for dma-buf and its users. If other drivers or
> - * sub-systems require similar functionality, the type could be generalized
> - * and moved to a more prominent header file.
> + * .. code-block:: c
> + *
> + * const void *src = ...; // source buffer
> + * size_t len = ...; // length of src
> + *
> + * dma_buf_map_memcpy_to(, src, len);
> + * dma_buf_map_incr(, len); // go to first byte after the memcpy
> */
>
> /**
> @@ -210,4 +228,38 @@ static inline void dma_buf_map_clear(struct dma_buf_map
> *map)
> }
> }
>
> +/**
> + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
> + * @dst: The dma-buf mapping structure
> + * @src: The source buffer
> + * @len: The number of byte in src
> + *
> + * Copies data into a dma-buf mapping. The source buffer is in system
> + * memory. Depending on the buffer's location, the helper picks the correct
> + * method of accessing the memory.
> + */
> +static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const void
> *src, size_t len)
> +{
> + if (dst->is_iomem)
> + memcpy_toio(dst->vaddr_iomem, src, len);
> + else
> + memcpy(dst->vaddr, src, len);
> +}
> +
> +/**
> + * dma_buf_map_incr - Increments the address stored in a dma-buf mapping
> + * @map: The dma-buf mapping structure
> + * @incr:The number of bytes to increment
> + *
> + * Increments the address stored in a dma-buf mapping. Depending on the
> + * buffer's location, the correct value will be updated.
> + */
> +static inline void dma_buf_map_incr(struct dma_buf_map *map, size_t incr)
> +{
> + if (map->is_iomem)
> + map->vaddr_iomem += incr;
> + else
> + map->vaddr += incr;
> +}
> +
> #endif /* __DMA_BUF_MAP_H__ */
> --
> 2.28.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/qxl: Fix build errors
Hi Sean.
On Mon, Aug 17, 2020 at 03:58:38PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Introduced in the patch below, the END macro was missing 'dev' and BEGIN
> macro needs drm_drv_uses_atomic_modeset() from drm_drv.h
>
> Fixes: bbaac1354cc9 ("drm/qxl: Replace deprecated function in qxl_display")
We should not use Fixes for local fixes like this, as we do not want the
robots to pick this commit.
With the Fixes: dropped (maybe just reference the commit in the
changelog):
Acked-by: Sam Ravnborg
> Cc: Sidong Yang
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Cc: virtualization@lists.linux-foundation.org
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index fa79688013b7..5b4fd6952b53 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -28,6 +28,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -186,7 +187,7 @@ void qxl_display_read_client_monitors_config(struct
> qxl_device *qdev)
>
> DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE,
> ret);
> qxl_update_offset_props(qdev);
> - DRM_MODESET_LOCK_ALL_END(ctx, ret);
> + DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
> if (!drm_helper_hpd_irq_event(dev)) {
> /* notify that the monitor configuration changed, to
> adjust at the arbitrary resolution */
> @@ -431,7 +432,7 @@ static int qxl_framebuffer_surface_dirty(struct
> drm_framebuffer *fb,
> clips, num_clips, inc, 0);
>
> out_lock_end:
> - DRM_MODESET_LOCK_ALL_END(ctx, ret);
> + DRM_MODESET_LOCK_ALL_END(fb->dev, ctx, ret);
>
> return 0;
> }
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 2/2] drm/virtio: Remove open-coded commit-tail function
On Thu, Jul 09, 2020 at 02:33:39PM +0200, Daniel Vetter wrote:
> Exactly matches the one in the helpers.
>
> This avoids me having to roll out dma-fence critical section
> annotations to this copy.
>
> Signed-off-by: Daniel Vetter
> Cc: David Airlie
> Cc: Gerd Hoffmann
> Cc: virtualization@lists.linux-foundation.org
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 20
> 1 file changed, 20 deletions(-)
Very nice catch:
Reviewed-by: Sam Ravnborg
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index f3ce49c5a34c..af55b334be2f 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -314,25 +314,6 @@ virtio_gpu_user_framebuffer_create(struct drm_device
> *dev,
> return _gpu_fb->base;
> }
>
> -static void vgdev_atomic_commit_tail(struct drm_atomic_state *state)
> -{
> - struct drm_device *dev = state->dev;
> -
> - drm_atomic_helper_commit_modeset_disables(dev, state);
> - drm_atomic_helper_commit_modeset_enables(dev, state);
> - drm_atomic_helper_commit_planes(dev, state, 0);
> -
> - drm_atomic_helper_fake_vblank(state);
> - drm_atomic_helper_commit_hw_done(state);
> -
> - drm_atomic_helper_wait_for_vblanks(dev, state);
> - drm_atomic_helper_cleanup_planes(dev, state);
> -}
> -
> -static const struct drm_mode_config_helper_funcs virtio_mode_config_helpers
> = {
> - .atomic_commit_tail = vgdev_atomic_commit_tail,
> -};
> -
> static const struct drm_mode_config_funcs virtio_gpu_mode_funcs = {
> .fb_create = virtio_gpu_user_framebuffer_create,
> .atomic_check = drm_atomic_helper_check,
> @@ -346,7 +327,6 @@ void virtio_gpu_modeset_init(struct virtio_gpu_device
> *vgdev)
> drm_mode_config_init(vgdev->ddev);
> vgdev->ddev->mode_config.quirk_addfb_prefer_host_byte_order = true;
> vgdev->ddev->mode_config.funcs = _gpu_mode_funcs;
> - vgdev->ddev->mode_config.helper_private = _mode_config_helpers;
>
> /* modes will be validated against the framebuffer size */
> vgdev->ddev->mode_config.min_width = XRES_MIN;
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 26/59] drm/qxl: Use devm_drm_dev_alloc
On Tue, Apr 28, 2020 at 04:00:11PM +0200, Daniel Vetter wrote:
> On Fri, Apr 24, 2020 at 05:09:11PM +0200, Sam Ravnborg wrote:
> > Hi Daniel
> >
> > On Wed, Apr 15, 2020 at 09:40:01AM +0200, Daniel Vetter wrote:
> > > Also need to remove the drm_dev_put from the remove hook.
> > >
> > > Acked-by: Gerd Hoffmann
> > > Signed-off-by: Daniel Vetter
> > > Cc: Dave Airlie
> > > Cc: Gerd Hoffmann
> > > Cc: virtualization@lists.linux-foundation.org
> > > Cc: spice-de...@lists.freedesktop.org
> > > ---
> > > drivers/gpu/drm/qxl/qxl_drv.c | 15 ---
> > > drivers/gpu/drm/qxl/qxl_drv.h | 3 +--
> > > drivers/gpu/drm/qxl/qxl_kms.c | 12 +---
> > > 3 files changed, 10 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> > > index 09102e2efabc..6b4ae4c5fb76 100644
> > > --- a/drivers/gpu/drm/qxl/qxl_drv.c
> > > +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> > > @@ -81,13 +81,16 @@ qxl_pci_probe(struct pci_dev *pdev, const struct
> > > pci_device_id *ent)
> > > return -EINVAL; /* TODO: ENODEV ? */
> > > }
> > >
> > > - qdev = kzalloc(sizeof(struct qxl_device), GFP_KERNEL);
> > > - if (!qdev)
> > > + qdev = devm_drm_dev_alloc(>dev, _driver,
> > > + struct qxl_device, ddev);
> > > + if (IS_ERR(qdev)) {
> > > + pr_err("Unable to init drm dev");
> > > return -ENOMEM;
> > > + }
> >
> > The other patches do not add any error message when devm_drm_dev_alloc()
> > fails and driver core will log that driver init failed.
> >
> > So the pr_err() above should be dropped.
> > I know it comes from qxl_device_init() but that does not make it a good
> > idea.
>
> Hm I know we're inconsistent here, but some drivers have error logging on
> all branches, some dont. I'm just trying to go with the prevailing style.
>
> > With this fixed:
>
> Insisting on this or ok as-is?
OK as-is.
Sam
> -Daniel
>
> > Acked-by: Sam Ravnborg
> >
> > >
> > > ret = pci_enable_device(pdev);
> > > if (ret)
> > > - goto free_dev;
> > > + return ret;
> > >
> > > ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, "qxl");
> > > if (ret)
> > > @@ -101,7 +104,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct
> > > pci_device_id *ent)
> > > }
> > > }
> > >
> > > - ret = qxl_device_init(qdev, _driver, pdev);
> > > + ret = qxl_device_init(qdev, pdev);
> > > if (ret)
> > > goto put_vga;
> > >
> > > @@ -128,8 +131,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct
> > > pci_device_id *ent)
> > > vga_put(pdev, VGA_RSRC_LEGACY_IO);
> > > disable_pci:
> > > pci_disable_device(pdev);
> > > -free_dev:
> > > - kfree(qdev);
> > > +
> > > return ret;
> > > }
> > >
> > > @@ -155,7 +157,6 @@ qxl_pci_remove(struct pci_dev *pdev)
> > > drm_atomic_helper_shutdown(dev);
> > > if (is_vga(pdev))
> > > vga_put(pdev, VGA_RSRC_LEGACY_IO);
> > > - drm_dev_put(dev);
> > > }
> > >
> > > DEFINE_DRM_GEM_FOPS(qxl_fops);
> > > diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
> > > index 435126facc9b..86ac191d9205 100644
> > > --- a/drivers/gpu/drm/qxl/qxl_drv.h
> > > +++ b/drivers/gpu/drm/qxl/qxl_drv.h
> > > @@ -276,8 +276,7 @@ struct qxl_device {
> > > extern const struct drm_ioctl_desc qxl_ioctls[];
> > > extern int qxl_max_ioctl;
> > >
> > > -int qxl_device_init(struct qxl_device *qdev, struct drm_driver *drv,
> > > - struct pci_dev *pdev);
> > > +int qxl_device_init(struct qxl_device *qdev, struct pci_dev *pdev);
> > > void qxl_device_fini(struct qxl_device *qdev);
> > >
> > > int qxl_modeset_init(struct qxl_device *qdev);
> > > diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
> > > index 9eed1a375f24..91a34dd835d7 100644
> > > --- a/drivers/gpu/drm/qxl/qxl_kms.c
> > > +++ b/drivers/gpu/drm/qxl/qxl_kms.c
> > > @@ -108,21 +108,13 @@ static void qxl_gc_work(struct work_struct *work)
> > > }
> > >
> > > int qxl_device_init(struct
Re: [PATCH 59/59] drm/bochs: Remove explicit drm_connector_register
On Wed, Apr 15, 2020 at 09:40:34AM +0200, Daniel Vetter wrote:
> This is leftovers from the old drm_driver->load callback
> upside-down issues. It doesn't do anything for not-hotplugged
> connectors since drm_dev_register takes care of that.
>
> Signed-off-by: Daniel Vetter
> Cc: Gerd Hoffmann
> Cc: virtualization@lists.linux-foundation.org
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/bochs/bochs_kms.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 7f4bcfad87e9..05d8373888e8 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -104,7 +104,6 @@ static void bochs_connector_init(struct drm_device *dev)
> DRM_MODE_CONNECTOR_VIRTUAL);
> drm_connector_helper_add(connector,
>_connector_connector_helper_funcs);
> - drm_connector_register(connector);
>
> bochs_hw_load_edid(bochs);
> if (bochs->edid) {
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 37/59] drm/cirrus: Move to drm/tiny
On Wed, Apr 15, 2020 at 09:40:12AM +0200, Daniel Vetter wrote:
> Because it is. Huge congrats to everyone who made this kind of
> refactoring happen!
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualization@lists.linux-foundation.org
Acked-by: Sam Ravnborg
> ---
> MAINTAINERS | 2 +-
> drivers/gpu/drm/Kconfig | 2 --
> drivers/gpu/drm/Makefile | 1 -
> drivers/gpu/drm/cirrus/Kconfig| 19 ---
> drivers/gpu/drm/cirrus/Makefile | 2 --
> drivers/gpu/drm/tiny/Kconfig | 19 +++
> drivers/gpu/drm/tiny/Makefile | 1 +
> drivers/gpu/drm/{cirrus => tiny}/cirrus.c | 0
> 8 files changed, 21 insertions(+), 25 deletions(-)
> delete mode 100644 drivers/gpu/drm/cirrus/Kconfig
> delete mode 100644 drivers/gpu/drm/cirrus/Makefile
> rename drivers/gpu/drm/{cirrus => tiny}/cirrus.c (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7b3255d96d1d..0a5cf105ee37 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5397,7 +5397,7 @@ L: virtualization@lists.linux-foundation.org
> S: Obsolete
> W:
> https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
> T: git git://anongit.freedesktop.org/drm/drm-misc
> -F: drivers/gpu/drm/cirrus/
> +F: drivers/gpu/drm/tiny/cirrus.c
>
> DRM DRIVER FOR QXL VIRTUAL GPU
> M: Dave Airlie
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 43594978958e..4f4e7fa001c1 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -310,8 +310,6 @@ source "drivers/gpu/drm/ast/Kconfig"
>
> source "drivers/gpu/drm/mgag200/Kconfig"
>
> -source "drivers/gpu/drm/cirrus/Kconfig"
> -
> source "drivers/gpu/drm/armada/Kconfig"
>
> source "drivers/gpu/drm/atmel-hlcdc/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index f34d08c83485..2c0e5a7e5953 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -74,7 +74,6 @@ obj-$(CONFIG_DRM_I915) += i915/
> obj-$(CONFIG_DRM_MGAG200) += mgag200/
> obj-$(CONFIG_DRM_V3D) += v3d/
> obj-$(CONFIG_DRM_VC4) += vc4/
> -obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
> obj-$(CONFIG_DRM_SIS) += sis/
> obj-$(CONFIG_DRM_SAVAGE)+= savage/
> obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
> diff --git a/drivers/gpu/drm/cirrus/Kconfig b/drivers/gpu/drm/cirrus/Kconfig
> deleted file mode 100644
> index c6bbd988b0e5..
> --- a/drivers/gpu/drm/cirrus/Kconfig
> +++ /dev/null
> @@ -1,19 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0-only
> -config DRM_CIRRUS_QEMU
> - tristate "Cirrus driver for QEMU emulated device"
> - depends on DRM && PCI && MMU
> - select DRM_KMS_HELPER
> - select DRM_GEM_SHMEM_HELPER
> - help
> - This is a KMS driver for emulated cirrus device in qemu.
> - It is *NOT* intended for real cirrus devices. This requires
> - the modesetting userspace X.org driver.
> -
> - Cirrus is obsolete, the hardware was designed in the 90ies
> - and can't keep up with todays needs. More background:
> -
> https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
> -
> - Better alternatives are:
> -- stdvga (DRM_BOCHS, qemu -vga std, default in qemu 2.2+)
> -- qxl (DRM_QXL, qemu -vga qxl, works best with spice)
> -- virtio (DRM_VIRTIO_GPU), qemu -vga virtio)
> diff --git a/drivers/gpu/drm/cirrus/Makefile b/drivers/gpu/drm/cirrus/Makefile
> deleted file mode 100644
> index 0c1ed3f99725..
> --- a/drivers/gpu/drm/cirrus/Makefile
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0-only
> -obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
> diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
> index 4160e74e4751..2b6414f0fa75 100644
> --- a/drivers/gpu/drm/tiny/Kconfig
> +++ b/drivers/gpu/drm/tiny/Kconfig
> @@ -1,5 +1,24 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> +config DRM_CIRRUS_QEMU
> + tristate "Cirrus driver for QEMU emulated device"
> + depends on DRM && PCI && MMU
> + select DRM_KMS_HELPER
> + select DRM_GEM_SHMEM_HELPER
> + help
> + This is a KMS driver for emulated cirrus device in qemu.
> + It is *NOT* intended for real cirrus devices. This requires
> + the modesetting userspace X.org driver.
> +
> + Cirrus is obsolete, the hardware was designed in the 90ies
> + and can't keep up with todays needs. More ba
Re: [PATCH 27/59] drm/qxl: Don't use drm_device->dev_private
On Wed, Apr 15, 2020 at 09:40:02AM +0200, Daniel Vetter wrote:
> Upcasting using a container_of macro is more typesafe, faster and
> easier for the compiler to optimize.
>
> Acked-by: Gerd Hoffmann
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualization@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/qxl/qxl_debugfs.c | 7 +++
> drivers/gpu/drm/qxl/qxl_display.c | 32 +++
> drivers/gpu/drm/qxl/qxl_drv.c | 8
> drivers/gpu/drm/qxl/qxl_drv.h | 4 ++--
> drivers/gpu/drm/qxl/qxl_dumb.c| 2 +-
> drivers/gpu/drm/qxl/qxl_gem.c | 2 +-
> drivers/gpu/drm/qxl/qxl_ioctl.c | 14 +++---
> drivers/gpu/drm/qxl/qxl_irq.c | 2 +-
> drivers/gpu/drm/qxl/qxl_kms.c | 1 -
> drivers/gpu/drm/qxl/qxl_object.c | 2 +-
> drivers/gpu/drm/qxl/qxl_release.c | 2 +-
> drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
> 12 files changed, 38 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c
> b/drivers/gpu/drm/qxl/qxl_debugfs.c
> index 88123047fdd4..524d35b648d8 100644
> --- a/drivers/gpu/drm/qxl/qxl_debugfs.c
> +++ b/drivers/gpu/drm/qxl/qxl_debugfs.c
> @@ -39,7 +39,7 @@ static int
> qxl_debugfs_irq_received(struct seq_file *m, void *data)
> {
> struct drm_info_node *node = (struct drm_info_node *) m->private;
> - struct qxl_device *qdev = node->minor->dev->dev_private;
> + struct qxl_device *qdev = to_qxl(node->minor->dev);
>
> seq_printf(m, "%d\n", atomic_read(>irq_received));
> seq_printf(m, "%d\n", atomic_read(>irq_received_display));
> @@ -53,7 +53,7 @@ static int
> qxl_debugfs_buffers_info(struct seq_file *m, void *data)
> {
> struct drm_info_node *node = (struct drm_info_node *) m->private;
> - struct qxl_device *qdev = node->minor->dev->dev_private;
> + struct qxl_device *qdev = to_qxl(node->minor->dev);
> struct qxl_bo *bo;
>
> list_for_each_entry(bo, >gem.objects, list) {
> @@ -83,8 +83,7 @@ void
> qxl_debugfs_init(struct drm_minor *minor)
> {
> #if defined(CONFIG_DEBUG_FS)
> - struct qxl_device *dev =
> - (struct qxl_device *) minor->dev->dev_private;
> + struct qxl_device *dev = to_qxl(minor->dev);
>
> drm_debugfs_create_files(qxl_debugfs_list, QXL_DEBUGFS_ENTRIES,
>minor->debugfs_root, minor);
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index 09583a08e141..1082cd5d2fd4 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -221,7 +221,7 @@ static int qxl_add_mode(struct drm_connector *connector,
> bool preferred)
> {
> struct drm_device *dev = connector->dev;
> - struct qxl_device *qdev = dev->dev_private;
> + struct qxl_device *qdev = to_qxl(dev);
> struct drm_display_mode *mode = NULL;
> int rc;
>
> @@ -242,7 +242,7 @@ static int qxl_add_mode(struct drm_connector *connector,
> static int qxl_add_monitors_config_modes(struct drm_connector *connector)
> {
> struct drm_device *dev = connector->dev;
> - struct qxl_device *qdev = dev->dev_private;
> + struct qxl_device *qdev = to_qxl(dev);
> struct qxl_output *output = drm_connector_to_qxl_output(connector);
> int h = output->index;
> struct qxl_head *head;
> @@ -310,7 +310,7 @@ static void qxl_crtc_update_monitors_config(struct
> drm_crtc *crtc,
> const char *reason)
> {
> struct drm_device *dev = crtc->dev;
> - struct qxl_device *qdev = dev->dev_private;
> + struct qxl_device *qdev = to_qxl(dev);
> struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
> struct qxl_head head;
> int oldcount, i = qcrtc->index;
> @@ -400,7 +400,7 @@ static int qxl_framebuffer_surface_dirty(struct
> drm_framebuffer *fb,
>unsigned int num_clips)
> {
> /* TODO: vmwgfx where this was cribbed from had locking. Why? */
> - struct qxl_device *qdev = fb->dev->dev_private;
> + struct qxl_device *qdev = to_qxl(fb->dev);
> struct drm_clip_rect norect;
> struct qxl_bo *qobj;
> bool is_primary;
> @@ -462,7 +462,7 @@ static const struct drm_crtc_helper_funcs
> qxl_crtc_helper_funcs = {
> static int qxl_primary_atomic_check(struct drm_plane *plane,
> struct drm_plane_state *state)
> {
> - struct qxl_dev
Re: [PATCH 26/59] drm/qxl: Use devm_drm_dev_alloc
Hi Daniel
On Wed, Apr 15, 2020 at 09:40:01AM +0200, Daniel Vetter wrote:
> Also need to remove the drm_dev_put from the remove hook.
>
> Acked-by: Gerd Hoffmann
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualization@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/qxl/qxl_drv.c | 15 ---
> drivers/gpu/drm/qxl/qxl_drv.h | 3 +--
> drivers/gpu/drm/qxl/qxl_kms.c | 12 +---
> 3 files changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index 09102e2efabc..6b4ae4c5fb76 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -81,13 +81,16 @@ qxl_pci_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> return -EINVAL; /* TODO: ENODEV ? */
> }
>
> - qdev = kzalloc(sizeof(struct qxl_device), GFP_KERNEL);
> - if (!qdev)
> + qdev = devm_drm_dev_alloc(>dev, _driver,
> + struct qxl_device, ddev);
> + if (IS_ERR(qdev)) {
> + pr_err("Unable to init drm dev");
> return -ENOMEM;
> + }
The other patches do not add any error message when devm_drm_dev_alloc()
fails and driver core will log that driver init failed.
So the pr_err() above should be dropped.
I know it comes from qxl_device_init() but that does not make it a good
idea.
With this fixed:
Acked-by: Sam Ravnborg
>
> ret = pci_enable_device(pdev);
> if (ret)
> - goto free_dev;
> + return ret;
>
> ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, "qxl");
> if (ret)
> @@ -101,7 +104,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> }
> }
>
> - ret = qxl_device_init(qdev, _driver, pdev);
> + ret = qxl_device_init(qdev, pdev);
> if (ret)
> goto put_vga;
>
> @@ -128,8 +131,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> vga_put(pdev, VGA_RSRC_LEGACY_IO);
> disable_pci:
> pci_disable_device(pdev);
> -free_dev:
> - kfree(qdev);
> +
> return ret;
> }
>
> @@ -155,7 +157,6 @@ qxl_pci_remove(struct pci_dev *pdev)
> drm_atomic_helper_shutdown(dev);
> if (is_vga(pdev))
> vga_put(pdev, VGA_RSRC_LEGACY_IO);
> - drm_dev_put(dev);
> }
>
> DEFINE_DRM_GEM_FOPS(qxl_fops);
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
> index 435126facc9b..86ac191d9205 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.h
> +++ b/drivers/gpu/drm/qxl/qxl_drv.h
> @@ -276,8 +276,7 @@ struct qxl_device {
> extern const struct drm_ioctl_desc qxl_ioctls[];
> extern int qxl_max_ioctl;
>
> -int qxl_device_init(struct qxl_device *qdev, struct drm_driver *drv,
> - struct pci_dev *pdev);
> +int qxl_device_init(struct qxl_device *qdev, struct pci_dev *pdev);
> void qxl_device_fini(struct qxl_device *qdev);
>
> int qxl_modeset_init(struct qxl_device *qdev);
> diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
> index 9eed1a375f24..91a34dd835d7 100644
> --- a/drivers/gpu/drm/qxl/qxl_kms.c
> +++ b/drivers/gpu/drm/qxl/qxl_kms.c
> @@ -108,21 +108,13 @@ static void qxl_gc_work(struct work_struct *work)
> }
>
> int qxl_device_init(struct qxl_device *qdev,
> - struct drm_driver *drv,
> struct pci_dev *pdev)
> {
> int r, sb;
>
> - r = drm_dev_init(>ddev, drv, >dev);
> - if (r) {
> - pr_err("Unable to init drm dev");
> - goto error;
> - }
> -
> qdev->ddev.pdev = pdev;
> pci_set_drvdata(pdev, >ddev);
> qdev->ddev.dev_private = qdev;
> - drmm_add_final_kfree(>ddev, qdev);
>
> mutex_init(>gem.mutex);
> mutex_init(>update_area_mutex);
> @@ -138,8 +130,7 @@ int qxl_device_init(struct qxl_device *qdev,
> qdev->vram_mapping = io_mapping_create_wc(qdev->vram_base,
> pci_resource_len(pdev, 0));
> if (!qdev->vram_mapping) {
> pr_err("Unable to create vram_mapping");
> - r = -ENOMEM;
> - goto error;
> + return -ENOMEM;
> }
>
> if (pci_resource_len(pdev, 4) > 0) {
> @@ -293,7 +284,6 @@ int qxl_device_init(struct qxl_device *qdev,
> io_mapping_free(qdev->surface_mapping);
> vram_mapping_free:
> io_mapping_free(qdev->vram_mapping);
> -error:
> return r;
> }
>
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 40/44] drm/cirrus: Don't use drm_device->dev_private
Hi Thomas.
On Mon, Apr 06, 2020 at 01:58:54PM +0200, Thomas Zimmermann wrote:
>
>
> Am 03.04.20 um 15:58 schrieb Daniel Vetter:
> > Upcasting using a container_of macro is more typesafe, faster and
> > easier for the compiler to optimize.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Dave Airlie
> > Cc: Gerd Hoffmann
> > Cc: Daniel Vetter
> > Cc: "Noralf Trønnes"
> > Cc: Sam Ravnborg
> > Cc: Eric Anholt
> > Cc: Thomas Zimmermann
> > Cc: virtualization@lists.linux-foundation.org
> > ---
> > drivers/gpu/drm/cirrus/cirrus.c | 9 +
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/cirrus/cirrus.c
> > b/drivers/gpu/drm/cirrus/cirrus.c
> > index 4b65637147ba..744a8e337e41 100644
> > --- a/drivers/gpu/drm/cirrus/cirrus.c
> > +++ b/drivers/gpu/drm/cirrus/cirrus.c
> > @@ -59,6 +59,8 @@ struct cirrus_device {
> > void __iomem *mmio;
> > };
> >
> > +#define to_cirrus(_dev) container_of(_dev, struct cirrus_device, dev)
> > +
>
> Maybe to_cirrus_device() ? I had the same comment for vbox and I think
> it applies to all patches.
The variable name is consistently using the name "cirrus" - so my
personal preference is to_cirrus().
Also IMO struct cirrus_device is misnamed. It is more than a device.
Sam
>
> Best regards
> Thomas
>
> > /* -- */
> > /*
> > * The meat of this driver. The core passes us a mode and we have to
> > program
> > @@ -311,7 +313,7 @@ static int cirrus_mode_set(struct cirrus_device *cirrus,
> > static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
> >struct drm_rect *rect)
> > {
> > - struct cirrus_device *cirrus = fb->dev->dev_private;
> > + struct cirrus_device *cirrus = to_cirrus(fb->dev);
> > void *vmap;
> > int idx, ret;
> >
> > @@ -436,7 +438,7 @@ static void cirrus_pipe_enable(struct
> > drm_simple_display_pipe *pipe,
> >struct drm_crtc_state *crtc_state,
> >struct drm_plane_state *plane_state)
> > {
> > - struct cirrus_device *cirrus = pipe->crtc.dev->dev_private;
> > + struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
> >
> > cirrus_mode_set(cirrus, _state->mode, plane_state->fb);
> > cirrus_fb_blit_fullscreen(plane_state->fb);
> > @@ -445,7 +447,7 @@ static void cirrus_pipe_enable(struct
> > drm_simple_display_pipe *pipe,
> > static void cirrus_pipe_update(struct drm_simple_display_pipe *pipe,
> >struct drm_plane_state *old_state)
> > {
> > - struct cirrus_device *cirrus = pipe->crtc.dev->dev_private;
> > + struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
> > struct drm_plane_state *state = pipe->plane.state;
> > struct drm_crtc *crtc = >crtc;
> > struct drm_rect rect;
> > @@ -573,7 +575,6 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
> > return PTR_ERR(cirrus);
> >
> > dev = >dev;
> > - dev->dev_private = cirrus;
> >
> > cirrus->vram = devm_ioremap(>dev, pci_resource_start(pdev, 0),
> > pci_resource_len(pdev, 0));
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 40/44] drm/cirrus: Don't use drm_device->dev_private
On Fri, Apr 03, 2020 at 03:58:24PM +0200, Daniel Vetter wrote:
> Upcasting using a container_of macro is more typesafe, faster and
> easier for the compiler to optimize.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc: Eric Anholt
> Cc: Thomas Zimmermann
> Cc: virtualization@lists.linux-foundation.org
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/cirrus/cirrus.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
> index 4b65637147ba..744a8e337e41 100644
> --- a/drivers/gpu/drm/cirrus/cirrus.c
> +++ b/drivers/gpu/drm/cirrus/cirrus.c
> @@ -59,6 +59,8 @@ struct cirrus_device {
> void __iomem *mmio;
> };
>
> +#define to_cirrus(_dev) container_of(_dev, struct cirrus_device, dev)
> +
> /* -- */
> /*
> * The meat of this driver. The core passes us a mode and we have to program
> @@ -311,7 +313,7 @@ static int cirrus_mode_set(struct cirrus_device *cirrus,
> static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
> struct drm_rect *rect)
> {
> - struct cirrus_device *cirrus = fb->dev->dev_private;
> + struct cirrus_device *cirrus = to_cirrus(fb->dev);
> void *vmap;
> int idx, ret;
>
> @@ -436,7 +438,7 @@ static void cirrus_pipe_enable(struct
> drm_simple_display_pipe *pipe,
> struct drm_crtc_state *crtc_state,
> struct drm_plane_state *plane_state)
> {
> - struct cirrus_device *cirrus = pipe->crtc.dev->dev_private;
> + struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
>
> cirrus_mode_set(cirrus, _state->mode, plane_state->fb);
> cirrus_fb_blit_fullscreen(plane_state->fb);
> @@ -445,7 +447,7 @@ static void cirrus_pipe_enable(struct
> drm_simple_display_pipe *pipe,
> static void cirrus_pipe_update(struct drm_simple_display_pipe *pipe,
> struct drm_plane_state *old_state)
> {
> - struct cirrus_device *cirrus = pipe->crtc.dev->dev_private;
> + struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
> struct drm_plane_state *state = pipe->plane.state;
> struct drm_crtc *crtc = >crtc;
> struct drm_rect rect;
> @@ -573,7 +575,6 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
> return PTR_ERR(cirrus);
>
> dev = >dev;
> - dev->dev_private = cirrus;
>
> cirrus->vram = devm_ioremap(>dev, pci_resource_start(pdev, 0),
> pci_resource_len(pdev, 0));
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 39/44] drm/cirrus: Use devm_drm_dev_alloc
On Fri, Apr 03, 2020 at 03:58:23PM +0200, Daniel Vetter wrote:
> Already using devm_drm_dev_init, so very simple replacment.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: "Noralf Trønnes"
> Cc: Rob Herring
> Cc: Thomas Zimmermann
> Cc: virtualization@lists.linux-foundation.org
> Cc: Emil Velikov
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/cirrus/cirrus.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
> index a36269717c3b..4b65637147ba 100644
> --- a/drivers/gpu/drm/cirrus/cirrus.c
> +++ b/drivers/gpu/drm/cirrus/cirrus.c
> @@ -567,18 +567,13 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
> return ret;
>
> ret = -ENOMEM;
> - cirrus = kzalloc(sizeof(*cirrus), GFP_KERNEL);
> - if (cirrus == NULL)
> - return ret;
> + cirrus = devm_drm_dev_alloc(>dev, _driver,
> + struct cirrus_device, dev);
> + if (IS_ERR(cirrus))
> + return PTR_ERR(cirrus);
>
> dev = >dev;
> - ret = devm_drm_dev_init(>dev, dev, _driver);
> - if (ret) {
> - kfree(cirrus);
> - return ret;
> - }
> dev->dev_private = cirrus;
> - drmm_add_final_kfree(dev, cirrus);
>
> cirrus->vram = devm_ioremap(>dev, pci_resource_start(pdev, 0),
> pci_resource_len(pdev, 0));
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs()
On Thu, Mar 19, 2020 at 03:19:54PM +0100, Sam Ravnborg wrote: > On Fri, Mar 13, 2020 at 09:17:41PM +0100, Sam Ravnborg wrote: > > Thomas Zimmermann had made a nice patch-set that introduced > > drm_simple_encoder_init() which is already present in drm-misc-next. > > > > While looking at this it was suddenly obvious to me that > > this was functionalty that really should be included in drm_encoder.c > > The case where the core could handle the callback is pretty > > common and not part of the simple pipe line. > > > > So after some dialog on dri-devel the conclusion was to go for > > a change like this: > > > > drm_encoder_init_funcs() for all users that specified a > > drm_encoder_funcs to extend the functionality. > > > > drm_encoder_init() for all users that did not > > need to extend the basic functionality with > > drm_encoder_funcs. > > > > A similar approach with a _funcs() prefix is used elsewhere in drm/ > > > > This required a rename of the existing users, and > > a follow-up patch that moves drm_simple_encoder_init() > > to drm_encoder.c > > > > Patches 3 in this set demonstrate the use of drm_encoder_init(). > > There are many more drivers that can be converted as Thomas > > has already demonstrated. > > > > This is all based on work done by Thomas Zimmermann, > > I just wanted to implement my suggestion so > > we could select the best way forward. > > > > Note: Daniel Vetter has hinted the approach implemented > > here smelled like middle-layer. > > IMO this is not so, it is just a way to handle cleanup > > for the simple cases. > > We discussed this patch-set briefly on irc. Just to clarify, we in this context was Daniel Vetter & me. Sam > With the upcoming drmm_ changes and such this is bad timing.. > And in the end this may be pointless code-chrunch. > > Patch-set shelfed for now - may re-visit it later. > > Sam > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs()
On Fri, Mar 13, 2020 at 09:17:41PM +0100, Sam Ravnborg wrote: > Thomas Zimmermann had made a nice patch-set that introduced > drm_simple_encoder_init() which is already present in drm-misc-next. > > While looking at this it was suddenly obvious to me that > this was functionalty that really should be included in drm_encoder.c > The case where the core could handle the callback is pretty > common and not part of the simple pipe line. > > So after some dialog on dri-devel the conclusion was to go for > a change like this: > > drm_encoder_init_funcs() for all users that specified a > drm_encoder_funcs to extend the functionality. > > drm_encoder_init() for all users that did not > need to extend the basic functionality with > drm_encoder_funcs. > > A similar approach with a _funcs() prefix is used elsewhere in drm/ > > This required a rename of the existing users, and > a follow-up patch that moves drm_simple_encoder_init() > to drm_encoder.c > > Patches 3 in this set demonstrate the use of drm_encoder_init(). > There are many more drivers that can be converted as Thomas > has already demonstrated. > > This is all based on work done by Thomas Zimmermann, > I just wanted to implement my suggestion so > we could select the best way forward. > > Note: Daniel Vetter has hinted the approach implemented > here smelled like middle-layer. > IMO this is not so, it is just a way to handle cleanup > for the simple cases. We discussed this patch-set briefly on irc. With the upcoming drmm_ changes and such this is bad timing.. And in the end this may be pointless code-chrunch. Patch-set shelfed for now - may re-visit it later. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v1 2/3] drm: drm_simple_encoder_init() => drm_encoder_init()
A lot of drivers requires only a basic encoder with no need
to extend the functionality.
This was previously implemented in drm_simple_kms_helper.c
but encoders are not necessarily simple despite no
need for a drm_encoder_funcs for adding functionality.
Move the init function to drm_encoder.c to reflect this.
And adjust the name to drm_encoder_init().
Drop include of drm_simple_kms_helper.h in the touched
drivers as it is no logner required.
Signed-off-by: Sam Ravnborg
Cc: Dave Airlie
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Laurent Pinchart
Cc: David Airlie
Cc: Daniel Vetter
Cc: Gerd Hoffmann
Cc: Sam Ravnborg
Cc: Emil Velikov
Cc: Andrzej Pietrasiewicz
Cc: "José Roberto de Souza"
---
drivers/gpu/drm/ast/ast_mode.c | 3 +-
drivers/gpu/drm/drm_encoder.c | 37
drivers/gpu/drm/drm_simple_kms_helper.c | 45 +
drivers/gpu/drm/mgag200/mgag200_mode.c | 7 ++--
drivers/gpu/drm/qxl/qxl_display.c | 7 ++--
include/drm/drm_encoder.h | 3 ++
include/drm/drm_simple_kms_helper.h | 4 ---
7 files changed, 46 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index cdd6c46d6557..4f6ace1afaf0 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -40,7 +40,6 @@
#include
#include
#include
-#include
#include "ast_drv.h"
#include "ast_tables.h"
@@ -964,7 +963,7 @@ static int ast_encoder_init(struct drm_device *dev)
struct drm_encoder *encoder = >encoder;
int ret;
- ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_DAC);
+ ret = drm_encoder_init(dev, encoder, DRM_MODE_ENCODER_DAC);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index a76a5f04ab39..e1e90652094c 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -152,6 +152,43 @@ int drm_encoder_init_funcs(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_encoder_init_funcs);
+static const struct drm_encoder_funcs drm_simple_encoder_funcs_cleanup = {
+ .destroy = drm_encoder_cleanup,
+};
+
+/**
+ * drm_simple_init - Initialize a preallocated encoder with basic
functionality.
+ * @dev: drm device
+ * @encoder: the encoder to initialize
+ * @encoder_type: user visible type of the encoder
+ *
+ * Initialises a preallocated encoder that has no further functionality.
+ * Settings for possible CRTC and clones are left to their initial values.
+ * The encoder will be cleaned up automatically as part of the mode-setting
+ * cleanup.
+ *
+ * The caller of drm_encoder_init() is responsible for freeing
+ * the encoder's memory after the encoder has been cleaned up. At the
+ * moment this only works reliably if the encoder data structure is
+ * stored in the device structure. Free the encoder's memory as part of
+ * the device release function.
+ *
+ * FIXME: Later improvements to DRM's resource management may allow for
+ *an automated kfree() of the encoder's memory.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_simple_init(struct drm_device *dev,
+ struct drm_encoder *encoder,
+ int encoder_type)
+{
+ return drm_encoder_init_funcs(dev, encoder,
+ _simple_encoder_funcs_cleanup,
+ encoder_type, NULL);
+}
+EXPORT_SYMBOL(drm_encoder_init);
+
/**
* drm_encoder_cleanup - cleans up an initialised encoder
* @encoder: encoder to cleanup
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 24d4433c347b..d70170980839 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -26,51 +26,8 @@
* entity. Some flexibility for code reuse is provided through a separately
* allocated _connector object and supporting optional _bridge
* encoder drivers.
- *
- * Many drivers require only a very simple encoder that fulfills the minimum
- * requirements of the display pipeline and does not add additional
- * functionality. The function drm_simple_encoder_init() provides an
- * implementation of such an encoder.
*/
-static const struct drm_encoder_funcs drm_simple_encoder_funcs_cleanup = {
- .destroy = drm_encoder_cleanup,
-};
-
-/**
- * drm_simple_encoder_init - Initialize a preallocated encoder with
- * basic functionality.
- * @dev: drm device
- * @encoder: the encoder to initialize
- * @encoder_type: user visible type of the encoder
- *
- * Initialises a preallocated encoder that has no further functionality.
- * Settings for possible CRTC and clones are left to their initial values.
- * The encoder will be cleaned up automatically as part of the mode-setting
- * cleanup.
- *
- * The caller of drm_simple_encoder_
[PATCH v1 3/3] drm/atmel-hlcdc: Use drm_encoder_init()
atmel-hlcdc has no need to extend the functionality of the
encoder, so use drm_encoder_init().
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: Thomas Zimmermann
Cc: Laurent Pinchart
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index a845d587c315..96e0d85748d2 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -22,10 +22,6 @@ struct atmel_hlcdc_rgb_output {
int bus_fmt;
};
-static const struct drm_encoder_funcs atmel_hlcdc_panel_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static struct atmel_hlcdc_rgb_output *
atmel_hlcdc_encoder_to_rgb_output(struct drm_encoder *encoder)
{
@@ -98,9 +94,7 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device
*dev, int endpoint)
return -EINVAL;
}
- ret = drm_encoder_init_funcs(dev, >encoder,
-_hlcdc_panel_encoder_funcs,
-DRM_MODE_ENCODER_NONE, NULL);
+ ret = drm_encoder_init(dev, >encoder, DRM_MODE_ENCODER_NONE);
if (ret)
return ret;
--
2.20.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v1 1/3] drm: drm_encoder_init() => drm_encoder_init_funcs()
Many callers of drm_encoder_init use a drm_encoder_funcs that contains only a drm_encoder_cleanup() callback. drm_simple_encoder_init() was introduced to cover the common case where an encoder with only basic functionality was needed. But it really do not belong in drm_simple_* Rename drm_encoder_init() to drm_encoder_funcs(), so we can then in a subsequent patch rename drm_simple_encoder_init() to drm_encoder_init(). And then move the functionality to drm_encoder where it bleongs. checkpatch complains about long lines in amd and radeon. Surrounding lines are too long too, so warnings were ignored. Signed-off-by: Sam Ravnborg Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: NXP Linux Team Cc: Laurent Pinchart Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-media...@lists.infradead.org Cc: linux-amlo...@lists.infradead.org Cc: amd-...@lists.freedesktop.org Cc: linux-renesas-...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-te...@vger.kernel.org Cc: virtualization@lists.linux-foundation.org --- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 28 ++--- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 28 ++--- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 28 ++--- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 28 ++--- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 4 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++--- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 10 ++--- drivers/gpu/drm/arc/arcpgu_hdmi.c | 4 +- drivers/gpu/drm/arc/arcpgu_sim.c | 4 +- .../gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 6 +-- drivers/gpu/drm/drm_encoder.c | 14 +++ drivers/gpu/drm/drm_encoder_slave.c | 2 +- drivers/gpu/drm/drm_simple_kms_helper.c | 6 +-- drivers/gpu/drm/drm_writeback.c | 6 +-- drivers/gpu/drm/exynos/exynos_dp.c| 4 +- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 4 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_crt.c| 5 ++- drivers/gpu/drm/gma500/cdv_intel_dp.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 6 +-- drivers/gpu/drm/gma500/mdfld_dsi_dpi.c| 7 ++-- drivers/gpu/drm/gma500/oaktrail_hdmi.c| 6 +-- drivers/gpu/drm/gma500/oaktrail_lvds.c| 4 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 6 +-- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 4 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 4 +- drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 4 +- drivers/gpu/drm/i2c/tda998x_drv.c | 5 ++- drivers/gpu/drm/i915/display/icl_dsi.c| 4 +- drivers/gpu/drm/i915/display/intel_crt.c | 5 ++- drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++- drivers/gpu/drm/i915/display/intel_dp.c | 6 +-- drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 ++- drivers/gpu/drm/i915/display/intel_dvo.c | 6 +-- drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +-- drivers/gpu/drm/i915/display/intel_lvds.c | 4 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 6 +-- drivers/gpu/drm/i915/display/intel_tv.c | 4 +- drivers/gpu/drm/i915/display/vlv_dsi.c| 5 ++- drivers/gpu/drm/imx/dw_hdmi-imx.c | 4 +- drivers/gpu/drm/imx/imx-ldb.c | 4 +- drivers/gpu/drm/imx/imx-tve.c | 4 +- drivers/gpu/drm/imx/parallel-display.c| 4 +- drivers/gpu/drm/ingenic/ingenic-drm.c | 5 ++- drivers/gpu/drm/mediatek/mtk_dpi.c| 5 ++- drivers/gpu/drm/mediatek/mtk_dsi.c| 4 +- drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 ++- drivers/gpu/drm/meson/meson_venc_cvbs.c | 5 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 +- .../gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c | 4 +- .../gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c | 4 +- .../gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 4 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 3 +- drivers/gpu/drm/nouveau/dispnv04/dac.c| 4 +- drivers/gpu/drm/nouveau/dispnv04/dfp.c| 3 +- drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 4 +- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 16 drivers/gpu/drm/omapdrm/omap_encoder.c| 4 +- drivers/gpu/drm/radeon/atombios_encoders.c| 40 +-- drivers/gpu/drm/radeon/radeon_dp_mst.c| 4 +- .../gpu/drm/radeon/radeon_legacy_encoders.c | 20 +- drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 4 +- .../gpu/drm/rockchip
[PATCH v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs()
Thomas Zimmermann had made a nice patch-set that introduced drm_simple_encoder_init() which is already present in drm-misc-next. While looking at this it was suddenly obvious to me that this was functionalty that really should be included in drm_encoder.c The case where the core could handle the callback is pretty common and not part of the simple pipe line. So after some dialog on dri-devel the conclusion was to go for a change like this: drm_encoder_init_funcs() for all users that specified a drm_encoder_funcs to extend the functionality. drm_encoder_init() for all users that did not need to extend the basic functionality with drm_encoder_funcs. A similar approach with a _funcs() prefix is used elsewhere in drm/ This required a rename of the existing users, and a follow-up patch that moves drm_simple_encoder_init() to drm_encoder.c Patches 3 in this set demonstrate the use of drm_encoder_init(). There are many more drivers that can be converted as Thomas has already demonstrated. This is all based on work done by Thomas Zimmermann, I just wanted to implement my suggestion so we could select the best way forward. Note: Daniel Vetter has hinted the approach implemented here smelled like middle-layer. IMO this is not so, it is just a way to handle cleanup for the simple cases. Sam Sam Ravnborg (3): drm: drm_encoder_init() => drm_encoder_init_funcs() drm: drm_simple_encoder_init() => drm_encoder_init() drm/atmel-hlcdc: Use drm_encoder_init() drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 28 ++--- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 28 ++--- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 28 ++--- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 28 ++--- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 4 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++--- .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 10 ++--- drivers/gpu/drm/arc/arcpgu_hdmi.c | 4 +- drivers/gpu/drm/arc/arcpgu_sim.c | 4 +- drivers/gpu/drm/ast/ast_mode.c | 3 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 8 +--- drivers/gpu/drm/drm_encoder.c | 49 +++--- drivers/gpu/drm/drm_encoder_slave.c| 2 +- drivers/gpu/drm/drm_simple_kms_helper.c| 45 +--- drivers/gpu/drm/drm_writeback.c| 6 +-- drivers/gpu/drm/exynos/exynos_dp.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_dpi.c| 4 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c| 4 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 4 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_crt.c | 5 ++- drivers/gpu/drm/gma500/cdv_intel_dp.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c| 4 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c| 6 +-- drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 7 ++-- drivers/gpu/drm/gma500/oaktrail_hdmi.c | 6 +-- drivers/gpu/drm/gma500/oaktrail_lvds.c | 4 +- drivers/gpu/drm/gma500/psb_intel_lvds.c| 6 +-- drivers/gpu/drm/gma500/psb_intel_sdvo.c| 4 +- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 4 +- drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 4 +- drivers/gpu/drm/i2c/tda998x_drv.c | 5 ++- drivers/gpu/drm/i915/display/icl_dsi.c | 4 +- drivers/gpu/drm/i915/display/intel_crt.c | 5 ++- drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++- drivers/gpu/drm/i915/display/intel_dp.c| 6 +-- drivers/gpu/drm/i915/display/intel_dp_mst.c| 6 ++- drivers/gpu/drm/i915/display/intel_dvo.c | 6 +-- drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +-- drivers/gpu/drm/i915/display/intel_lvds.c | 4 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 6 +-- drivers/gpu/drm/i915/display/intel_tv.c| 4 +- drivers/gpu/drm/i915/display/vlv_dsi.c | 5 ++- drivers/gpu/drm/imx/dw_hdmi-imx.c | 4 +- drivers/gpu/drm/imx/imx-ldb.c | 4 +- drivers/gpu/drm/imx/imx-tve.c | 4 +- drivers/gpu/drm/imx/parallel-display.c | 4 +- drivers/gpu/drm/ingenic/ingenic-drm.c | 5 ++- drivers/gpu/drm/mediatek/mtk_dpi.c | 5 ++- drivers/gpu/drm/mediatek/mtk_dsi.c | 4 +- drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 ++- drivers/gpu/drm/meson/meson_venc_cvbs.c| 5 ++- drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +--- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 4 +- drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
Re: [PATCH v3] drm/bochs: downgrade pci_request_region failure from error to warning
On Fri, Mar 13, 2020 at 03:35:30PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > + if (pci_request_region(pdev, 0, "bochs-drm") != 0)
> > > + DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
> > So you could use drm_WARN() which is what is preferred these days.
>
> Nope, this isn't yet in -fixes.
Ups, did not see this was for -fixes.
My ack stands without ths change then.
Sam
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3] drm/bochs: downgrade pci_request_region failure from error to warning
Hi Gred.
On Fri, Mar 13, 2020 at 09:41:52AM +0100, Gerd Hoffmann wrote:
> Shutdown of firmware framebuffer has a bunch of problems. Because
> of this the framebuffer region might still be reserved even after
> drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
>
> Don't consider pci_request_region() failure for the framebuffer
> region as fatal error to workaround this issue.
>
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/bochs/bochs_hw.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_hw.c
> b/drivers/gpu/drm/bochs/bochs_hw.c
> index 952199cc0462..dce4672e3fc8 100644
> --- a/drivers/gpu/drm/bochs/bochs_hw.c
> +++ b/drivers/gpu/drm/bochs/bochs_hw.c
> @@ -157,10 +157,8 @@ int bochs_hw_init(struct drm_device *dev)
There is a drm_device avilable.
> size = min(size, mem);
> }
>
> - if (pci_request_region(pdev, 0, "bochs-drm") != 0) {
> - DRM_ERROR("Cannot request framebuffer\n");
> - return -EBUSY;
> - }
> + if (pci_request_region(pdev, 0, "bochs-drm") != 0)
> + DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
So you could use drm_WARN() which is what is preferred these days.
With this fixed:
Acked-by: Sam Ravnborg
Sam
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()
Hi Laurent. On Sat, Mar 07, 2020 at 10:34:45PM +0200, Laurent Pinchart wrote: > Hi Sam, > > On Sat, Mar 07, 2020 at 09:08:13PM +0100, Sam Ravnborg wrote: > > On Fri, Mar 06, 2020 at 04:18:52PM +0100, Thomas Zimmermann wrote: > > > Am 06.03.20 um 15:22 schrieb Laurent Pinchart: > > > > On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote: > > > >> A call to drm_simple_encoder_init() initializes an encoder without > > > >> further functionality. It only provides the destroy callback to > > > >> cleanup the encoder's state. Only few drivers implement more > > > >> sophisticated encoders than that. Most drivers implement such a > > > >> simple encoder and can use drm_simple_encoder_init() instead. > > > >> > > > >> The patchset converts drivers where the encoder's instance is > > > >> embedded in a larger data structure. The driver releases the > > > >> memory during cleanup. Each patch replaces drm_encoder_init() with > > > >> drm_simple_encoder_init() and removes the (now unused) driver's > > > >> encoder functions. > > > >> > > > >> While the patchset is fairly large, the indiviual patches are self- > > > >> contained and can be merged independently from each other. The > > > >> simple-encoder functionality is currently in drm-misc-next, where > > > >> these patches could go as well. > > > > > > > > I've reviewed the whole series, including verifying that the few > > > > instances of struct drm_encoder_funcs that were not declared const were > > > > not modified somewhere to add more function pointers. > > > > > > > > Reviewed-by: Laurent Pinchart > > > > > > Thanks for the detailed review. > > > > > > > for all the patches. > > > > > > > > However, I'd like to note that drm_simple_encoder_init() is a bit of a > > > > misnommer here. Several of the encoders in those drivers to implement > > > > additional functionality. They just expose them through > > > > drm_encoder_helper_funcs, not drm_encoder_funcs. > > > > > > True. It's called 'simple encoder' for the lack of a better name. It's > > > part of the simple KMS helpers, so the name's at least consistent. OTOH > > > I always find drm_simple_display_pipe a bad name. > > > > > > We can still rename the simple-encoder function without much effort. I'm > > > open for suggestions. > > > > IMO this does not belong in drm_simple_kms - but in drm_encoder. > > This only occurs to me after looking a bit more on the patches, > > you would have loved to get this feedback earlier. > > > > Most users do not need their owm drm_encoder_funcs definition, > > and would be happy with the default as provided by drm_simple_* > > > > As the cleanup is handled automatically when the drm device > > is teared down (in mode_config_rest()) I considered if we could here > > use the drmm_ namespace - but that felt wrong. > > > > My proposal is the following: > > - Move the implementation to drm_encoder.c > > - Name it drm_encoder_init_nofuncs() > > Or better, rename the existing drm_encoder_init() to > drm_encoder_init_funcs(), and rename drm_simple_encoder_init() to > drm_encoder_init() ? It's the common case. Agreed. It is a bit more involved which is the only reason I did not suggest it. But if we bite the bullet, then maybe do it properly. Cocinelle for the rescue... Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()
Hi Thomas. On Fri, Mar 06, 2020 at 04:18:52PM +0100, Thomas Zimmermann wrote: > Hi Laurent > > Am 06.03.20 um 15:22 schrieb Laurent Pinchart: > > Hi Thomas, > > > > Thank you for the patch. > > > > On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote: > >> A call to drm_simple_encoder_init() initializes an encoder without > >> further functionality. It only provides the destroy callback to > >> cleanup the encoder's state. Only few drivers implement more > >> sophisticated encoders than that. Most drivers implement such a > >> simple encoder and can use drm_simple_encoder_init() instead. > >> > >> The patchset converts drivers where the encoder's instance is > >> embedded in a larger data structure. The driver releases the > >> memory during cleanup. Each patch replaces drm_encoder_init() with > >> drm_simple_encoder_init() and removes the (now unused) driver's > >> encoder functions. > >> > >> While the patchset is fairly large, the indiviual patches are self- > >> contained and can be merged independently from each other. The > >> simple-encoder functionality is currently in drm-misc-next, where > >> these patches could go as well. > > > > I've reviewed the whole series, including verifying that the few > > instances of struct drm_encoder_funcs that were not declared const were > > not modified somewhere to add more function pointers. > > > > Reviewed-by: Laurent Pinchart > > Thanks for the detailed review. > > > > > for all the patches. > > > > However, I'd like to note that drm_simple_encoder_init() is a bit of a > > misnommer here. Several of the encoders in those drivers to implement > > additional functionality. They just expose them through > > drm_encoder_helper_funcs, not drm_encoder_funcs. > > True. It's called 'simple encoder' for the lack of a better name. It's > part of the simple KMS helpers, so the name's at least consistent. OTOH > I always find drm_simple_display_pipe a bad name. > > We can still rename the simple-encoder function without much effort. I'm > open for suggestions. IMO this does not belong in drm_simple_kms - but in drm_encoder. This only occurs to me after looking a bit more on the patches, you would have loved to get this feedback earlier. Most users do not need their owm drm_encoder_funcs definition, and would be happy with the default as provided by drm_simple_* As the cleanup is handled automatically when the drm device is teared down (in mode_config_rest()) I considered if we could here use the drmm_ namespace - but that felt wrong. My proposal is the following: - Move the implementation to drm_encoder.c - Name it drm_encoder_init_nofuncs() The patches posted in this thread would be a little simpler as they would loose the added include file. And the three drivers using the current infrastructure would need a small update. I you decide to keep the current approach where the functions are in drm_simple_* then the full series is: Acked-by: Sam Ravnborg But I think moving it to drm_encoder.c would be the approach that would make it simpler to understand/follow. So that get my (biased) vote. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 05/22] drm/gma500: Use simple encoder
Hi Thomas.
On Thu, Mar 05, 2020 at 04:59:33PM +0100, Thomas Zimmermann wrote:
> The gma500 driver uses empty implementations for some of its encoders.
> Replace the code with the generic simple encoder.
This parts looks good.
> As a side effect, the
> patch also removes an indirection in the encoder setup for Medfield.
I failed to see where this was done. Maybe too late for me to review
patches, so I will stop now.
No matter - patch is:
Acked-by: Sam Ravnborg
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/gma500/cdv_intel_crt.c | 14 +++---
> drivers/gpu/drm/gma500/cdv_intel_dp.c | 16 +++-
> drivers/gpu/drm/gma500/cdv_intel_hdmi.c| 4 ++--
> drivers/gpu/drm/gma500/cdv_intel_lvds.c| 17 +++--
> drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 7 +++
> drivers/gpu/drm/gma500/mdfld_output.h | 1 -
> drivers/gpu/drm/gma500/mdfld_tmd_vid.c | 6 --
> drivers/gpu/drm/gma500/mdfld_tpo_vid.c | 6 --
> drivers/gpu/drm/gma500/oaktrail_hdmi.c | 14 ++
> drivers/gpu/drm/gma500/oaktrail_lvds.c | 5 +++--
> drivers/gpu/drm/gma500/psb_intel_drv.h | 1 -
> drivers/gpu/drm/gma500/psb_intel_lvds.c| 18 +++---
> drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 5 -
> 13 files changed, 22 insertions(+), 92 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c
> b/drivers/gpu/drm/gma500/cdv_intel_crt.c
> index 29c36d63b20e..88535f5aacc5 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
> @@ -28,6 +28,8 @@
> #include
> #include
>
> +#include
> +
> #include "cdv_device.h"
> #include "intel_bios.h"
> #include "power.h"
> @@ -237,15 +239,6 @@ static const struct drm_connector_helper_funcs
> .best_encoder = gma_best_encoder,
> };
>
> -static void cdv_intel_crt_enc_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs cdv_intel_crt_enc_funcs = {
> - .destroy = cdv_intel_crt_enc_destroy,
> -};
> -
> void cdv_intel_crt_init(struct drm_device *dev,
> struct psb_intel_mode_device *mode_dev)
> {
> @@ -271,8 +264,7 @@ void cdv_intel_crt_init(struct drm_device *dev,
> _intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
>
> encoder = _encoder->base;
> - drm_encoder_init(dev, encoder,
> - _intel_crt_enc_funcs, DRM_MODE_ENCODER_DAC, NULL);
> + drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_DAC);
>
> gma_connector_attach_encoder(gma_connector, gma_encoder);
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
> b/drivers/gpu/drm/gma500/cdv_intel_dp.c
> index 5772b2dce0d6..13947ec06dbb 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #include "gma_display.h"
> #include "psb_drv.h"
> @@ -1908,11 +1909,6 @@ cdv_intel_dp_destroy(struct drm_connector *connector)
> kfree(connector);
> }
>
> -static void cdv_intel_dp_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> static const struct drm_encoder_helper_funcs cdv_intel_dp_helper_funcs = {
> .dpms = cdv_intel_dp_dpms,
> .mode_fixup = cdv_intel_dp_mode_fixup,
> @@ -1935,11 +1931,6 @@ static const struct drm_connector_helper_funcs
> cdv_intel_dp_connector_helper_fun
> .best_encoder = gma_best_encoder,
> };
>
> -static const struct drm_encoder_funcs cdv_intel_dp_enc_funcs = {
> - .destroy = cdv_intel_dp_encoder_destroy,
> -};
> -
> -
> static void cdv_intel_dp_add_properties(struct drm_connector *connector)
> {
> cdv_intel_attach_force_audio_property(connector);
> @@ -2016,8 +2007,7 @@ cdv_intel_dp_init(struct drm_device *dev, struct
> psb_intel_mode_device *mode_dev
> encoder = _encoder->base;
>
> drm_connector_init(dev, connector, _intel_dp_connector_funcs, type);
> - drm_encoder_init(dev, encoder, _intel_dp_enc_funcs,
> - DRM_MODE_ENCODER_TMDS, NULL);
> + drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_TMDS);
>
> gma_connector_attach_encoder(gma_connector, gma_encoder);
>
> @@ -2120,7 +2110,7 @@ cdv_intel_dp_init(struct drm_device *dev, struct
> psb_intel_mode_device *mode_dev
> if (ret == 0) {
> /* if this fails, presume the device is a ghost */
> DRM_INFO("f
Re: [PATCH 03/22] drm/exynos: Use simple encoder
On Thu, Mar 05, 2020 at 04:59:31PM +0100, Thomas Zimmermann wrote:
> The exynos driver uses empty implementations for its encoders. Replace
> the code with the generic simple encoder.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/exynos/exynos_dp.c | 8 ++--
> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 ++--
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++--
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8 ++--
> drivers/gpu/drm/exynos/exynos_hdmi.c | 8 ++--
> 5 files changed, 10 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index d23d3502ca91..a61482af2998 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "exynos_drm_crtc.h"
> @@ -135,10 +136,6 @@ static const struct drm_encoder_helper_funcs
> exynos_dp_encoder_helper_funcs = {
> .disable = exynos_dp_nop,
> };
>
> -static const struct drm_encoder_funcs exynos_dp_encoder_funcs = {
> - .destroy = drm_encoder_cleanup,
> -};
> -
> static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
> {
> int ret;
> @@ -174,8 +171,7 @@ static int exynos_dp_bind(struct device *dev, struct
> device *master, void *data)
> return ret;
> }
>
> - drm_encoder_init(drm_dev, encoder, _dp_encoder_funcs,
> - DRM_MODE_ENCODER_TMDS, NULL);
> + drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
>
> drm_encoder_helper_add(encoder, _dp_encoder_helper_funcs);
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> index 43fa0f26c052..7ba5354e7d94 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -149,10 +150,6 @@ static const struct drm_encoder_helper_funcs
> exynos_dpi_encoder_helper_funcs = {
> .disable = exynos_dpi_disable,
> };
>
> -static const struct drm_encoder_funcs exynos_dpi_encoder_funcs = {
> - .destroy = drm_encoder_cleanup,
> -};
> -
> enum {
> FIMD_PORT_IN0,
> FIMD_PORT_IN1,
> @@ -201,8 +198,7 @@ int exynos_dpi_bind(struct drm_device *dev, struct
> drm_encoder *encoder)
> {
> int ret;
>
> - drm_encoder_init(dev, encoder, _dpi_encoder_funcs,
> - DRM_MODE_ENCODER_TMDS, NULL);
> + drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_TMDS);
>
> drm_encoder_helper_add(encoder, _dpi_encoder_helper_funcs);
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 669d3857502a..2986c93382e0 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
>
> #include "exynos_drm_crtc.h"
> #include "exynos_drm_drv.h"
> @@ -1524,10 +1525,6 @@ static const struct drm_encoder_helper_funcs
> exynos_dsi_encoder_helper_funcs = {
> .disable = exynos_dsi_disable,
> };
>
> -static const struct drm_encoder_funcs exynos_dsi_encoder_funcs = {
> - .destroy = drm_encoder_cleanup,
> -};
> -
> MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
>
> static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> @@ -1705,8 +1702,7 @@ static int exynos_dsi_bind(struct device *dev, struct
> device *master,
> struct drm_bridge *in_bridge;
> int ret;
>
> - drm_encoder_init(drm_dev, encoder, _dsi_encoder_funcs,
> - DRM_MODE_ENCODER_TMDS, NULL);
> + drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
>
> drm_encoder_helper_add(encoder, _dsi_encoder_helper_funcs);
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index b320b3a21ad4..282467121699 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -369,10 +370,6 @@ static const struct drm_encoder_helper_funcs
> exynos_vidi_encoder_helper_funcs =
> .disable = exynos_vidi_disable,
> };
>
> -static const struct drm_encoder_
Re: [PATCH 02/22] drm/atmel-hlcdc: Use simple encoder
On Thu, Mar 05, 2020 at 04:59:30PM +0100, Thomas Zimmermann wrote:
> The atmel-hlcdc driver uses an empty implementation for its encoder.
> Replace the code with the generic simple encoder.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> index e2019fe97fff..43bc709e3523 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> @@ -11,9 +11,10 @@
> #include
> #include
>
> +#include
> #include
> #include
> -#include
> +#include
>
> #include "atmel_hlcdc_dc.h"
>
> @@ -22,10 +23,6 @@ struct atmel_hlcdc_rgb_output {
> int bus_fmt;
> };
>
> -static const struct drm_encoder_funcs atmel_hlcdc_panel_encoder_funcs = {
> - .destroy = drm_encoder_cleanup,
> -};
> -
> static struct atmel_hlcdc_rgb_output *
> atmel_hlcdc_encoder_to_rgb_output(struct drm_encoder *encoder)
> {
> @@ -98,9 +95,8 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device
> *dev, int endpoint)
> return -EINVAL;
> }
>
> - ret = drm_encoder_init(dev, >encoder,
> -_hlcdc_panel_encoder_funcs,
> -DRM_MODE_ENCODER_NONE, NULL);
> + ret = drm_simple_encoder_init(dev, >encoder,
> + DRM_MODE_ENCODER_NONE);
> if (ret)
> return ret;
>
> --
> 2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 01/22] drm/arc: Use simple encoder
On Thu, Mar 05, 2020 at 04:59:29PM +0100, Thomas Zimmermann wrote:
> The arc driver uses empty implementations for its encoders. Replace
> the code with the generic simple encoder.
We should , as a follow-up patch, embed the encoder in
arcgpu_drm_private.
Then we drop the kzalloc() and avoid that life-time challenge.
This patch looks good for what it does.
Acked-by: Sam Ravnborg
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/arc/arcpgu_hdmi.c | 10 +++---
> drivers/gpu/drm/arc/arcpgu_sim.c | 8 ++--
> 2 files changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c
> b/drivers/gpu/drm/arc/arcpgu_hdmi.c
> index 52839934f2fb..780911765e2e 100644
> --- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
> +++ b/drivers/gpu/drm/arc/arcpgu_hdmi.c
> @@ -7,15 +7,12 @@
>
> #include
> #include
> -#include
> #include
> +#include
> +#include
>
> #include "arcpgu.h"
>
> -static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
> - .destroy = drm_encoder_cleanup,
> -};
> -
> int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np)
> {
> struct drm_encoder *encoder;
> @@ -34,8 +31,7 @@ int arcpgu_drm_hdmi_init(struct drm_device *drm, struct
> device_node *np)
>
> encoder->possible_crtcs = 1;
> encoder->possible_clones = 0;
> - ret = drm_encoder_init(drm, encoder, _drm_encoder_funcs,
> -DRM_MODE_ENCODER_TMDS, NULL);
> + ret = drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c
> b/drivers/gpu/drm/arc/arcpgu_sim.c
> index 37d961668dfe..66ca2c26e339 100644
> --- a/drivers/gpu/drm/arc/arcpgu_sim.c
> +++ b/drivers/gpu/drm/arc/arcpgu_sim.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
>
> #include "arcpgu.h"
>
> @@ -50,10 +51,6 @@ static const struct drm_connector_funcs
> arcpgu_drm_connector_funcs = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> -static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
> - .destroy = drm_encoder_cleanup,
> -};
> -
> int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np)
> {
> struct arcpgu_drm_connector *arcpgu_connector;
> @@ -68,8 +65,7 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct
> device_node *np)
> encoder->possible_crtcs = 1;
> encoder->possible_clones = 0;
>
> - ret = drm_encoder_init(drm, encoder, _drm_encoder_funcs,
> -DRM_MODE_ENCODER_VIRTUAL, NULL);
> + ret = drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_VIRTUAL);
> if (ret)
> return ret;
>
> --
> 2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 28/51] drm/bochs: Drop explicit drm_mode_config_cleanup
On Mon, Mar 02, 2020 at 11:26:08PM +0100, Daniel Vetter wrote:
> Instead rely on the automatic clean, for which we just need to check
> that drm_mode_config_init succeeded. To avoid an inversion in the
> cleanup we also have to move the dev_private allocation over to
> drmm_kzalloc.
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final drm_device
> cleanup is check the new error code for _init().
>
> v2: Explain why this cleanup is possible (Laurent).
>
> v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas)
>
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> Cc: Gerd Hoffmann
> Cc: virtualization@lists.linux-foundation.org
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/bochs/bochs.h | 1 -
> drivers/gpu/drm/bochs/bochs_drv.c | 6 ++
> drivers/gpu/drm/bochs/bochs_kms.c | 14 +-
> 3 files changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
> index 917767173ee6..e5bd1d517a18 100644
> --- a/drivers/gpu/drm/bochs/bochs.h
> +++ b/drivers/gpu/drm/bochs/bochs.h
> @@ -92,7 +92,6 @@ void bochs_mm_fini(struct bochs_device *bochs);
>
> /* bochs_kms.c */
> int bochs_kms_init(struct bochs_device *bochs);
> -void bochs_kms_fini(struct bochs_device *bochs);
>
> /* bochs_fbdev.c */
> extern const struct drm_mode_config_funcs bochs_mode_funcs;
> diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
> b/drivers/gpu/drm/bochs/bochs_drv.c
> index addb0568c1af..e18c51de1196 100644
> --- a/drivers/gpu/drm/bochs/bochs_drv.c
> +++ b/drivers/gpu/drm/bochs/bochs_drv.c
> @@ -7,6 +7,7 @@
>
> #include
> #include
> +#include
>
> #include "bochs.h"
>
> @@ -21,10 +22,7 @@ static void bochs_unload(struct drm_device *dev)
> {
> struct bochs_device *bochs = dev->dev_private;
>
> - bochs_kms_fini(bochs);
> bochs_mm_fini(bochs);
> - kfree(bochs);
> - dev->dev_private = NULL;
> }
>
> static int bochs_load(struct drm_device *dev)
> @@ -32,7 +30,7 @@ static int bochs_load(struct drm_device *dev)
> struct bochs_device *bochs;
> int ret;
>
> - bochs = kzalloc(sizeof(*bochs), GFP_KERNEL);
> + bochs = drmm_kzalloc(dev, sizeof(*bochs), GFP_KERNEL);
> if (bochs == NULL)
> return -ENOMEM;
> dev->dev_private = bochs;
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index e8cc8156d773..7f4bcfad87e9 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -134,7 +134,11 @@ const struct drm_mode_config_funcs bochs_mode_funcs = {
>
> int bochs_kms_init(struct bochs_device *bochs)
> {
> - drm_mode_config_init(bochs->dev);
> + int ret;
> +
> + ret = drmm_mode_config_init(bochs->dev);
> + if (ret)
> + return ret;
>
> bochs->dev->mode_config.max_width = 8192;
> bochs->dev->mode_config.max_height = 8192;
> @@ -160,11 +164,3 @@ int bochs_kms_init(struct bochs_device *bochs)
>
> return 0;
> }
> -
> -void bochs_kms_fini(struct bochs_device *bochs)
> -{
> - if (!bochs->dev->mode_config.num_connector)
> - return;
> -
> - drm_mode_config_cleanup(bochs->dev);
> -}
> --
> 2.24.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 29/51] drm/cirrus: Drop explicit drm_mode_config_cleanup call
On Thu, Feb 27, 2020 at 07:15:00PM +0100, Daniel Vetter wrote:
> We can even delete the drm_driver.release hook now!
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final drm_device
> cleanup is check the new error code for _init().
>
> v2: Explain why this cleanup is possible (Laurent).
>
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Cc: virtualization@lists.linux-foundation.org
Acked-by: Sam Ravnborg
But as stated in other post - using drmm_mode_config_init()
would make this more readable.
Sam
> ---
> drivers/gpu/drm/cirrus/cirrus.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
> index a9d789a56536..6ac0286810ec 100644
> --- a/drivers/gpu/drm/cirrus/cirrus.c
> +++ b/drivers/gpu/drm/cirrus/cirrus.c
> @@ -510,11 +510,15 @@ static const struct drm_mode_config_funcs
> cirrus_mode_config_funcs = {
> .atomic_commit = drm_atomic_helper_commit,
> };
>
> -static void cirrus_mode_config_init(struct cirrus_device *cirrus)
> +static int cirrus_mode_config_init(struct cirrus_device *cirrus)
> {
> struct drm_device *dev = >dev;
> + int ret;
> +
> + ret = drm_mode_config_init(dev);
> + if (ret)
> + return ret;
>
> - drm_mode_config_init(dev);
> dev->mode_config.min_width = 0;
> dev->mode_config.min_height = 0;
> dev->mode_config.max_width = CIRRUS_MAX_PITCH / 2;
> @@ -522,15 +526,12 @@ static void cirrus_mode_config_init(struct
> cirrus_device *cirrus)
> dev->mode_config.preferred_depth = 16;
> dev->mode_config.prefer_shadow = 0;
> dev->mode_config.funcs = _mode_config_funcs;
> +
> + return 0;
> }
>
> /* -- */
>
> -static void cirrus_release(struct drm_device *dev)
> -{
> - drm_mode_config_cleanup(dev);
> -}
> -
> DEFINE_DRM_GEM_FOPS(cirrus_fops);
>
> static struct drm_driver cirrus_driver = {
> @@ -544,7 +545,6 @@ static struct drm_driver cirrus_driver = {
>
> .fops= _fops,
> DRM_GEM_SHMEM_DRIVER_OPS,
> - .release = cirrus_release,
> };
>
> static int cirrus_pci_probe(struct pci_dev *pdev,
> @@ -591,7 +591,9 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
> if (cirrus->mmio == NULL)
> goto err_unmap_vram;
>
> - cirrus_mode_config_init(cirrus);
> + ret = cirrus_mode_config_init(cirrus);
> + if (ret)
> + goto err_cleanup;
>
> ret = cirrus_conn_init(cirrus);
> if (ret < 0)
> @@ -613,7 +615,6 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
> return 0;
>
> err_cleanup:
> - drm_mode_config_cleanup(dev);
> iounmap(cirrus->mmio);
> err_unmap_vram:
> iounmap(cirrus->vram);
> --
> 2.24.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 0/4] drm: Provide a simple encoder
Hi Thomas. On Fri, Feb 28, 2020 at 09:18:24AM +0100, Thomas Zimmermann wrote: > Many DRM drivers implement an encoder with an empty implementation. This > patchset adds drm_simple_encoder_init(), which drivers can use instead. > Except for the destroy callback, the simple encoder's implementation is > empty. > > The patchset also converts 4 encoder instances to use the simple-encoder > helpers. But there are at least 11 other drivers which can use the helper > and I think I did not examine all drivers yet. > > The patchset was smoke-tested on mgag200 by running the fbdev console > and Gnome on X11. > > v4: > * print error messages with drm_err() (Sam) > * qxl: handle errors of drm_simple_encoder_init() (Sam) Looked through the patches - all looked good. IMO ready to apply. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 09/51] drm/cirrus: Use drmm_add_final_kfree
On Thu, Feb 27, 2020 at 07:14:40PM +0100, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> I also noticed that cirrus forgot to call drm_dev_fini().
>
> v2: Don't call kfree(cirrus) after we've handed overship of that to
> drm_device and the drmm_ stuff.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Linus Walleij
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Cc: virtualization@lists.linux-foundation.org
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/cirrus/cirrus.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
> index d2ff63ce8eaf..2232556ce34c 100644
> --- a/drivers/gpu/drm/cirrus/cirrus.c
> +++ b/drivers/gpu/drm/cirrus/cirrus.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -527,10 +528,8 @@ static void cirrus_mode_config_init(struct cirrus_device
> *cirrus)
>
> static void cirrus_release(struct drm_device *dev)
> {
> - struct cirrus_device *cirrus = dev->dev_private;
> -
> drm_mode_config_cleanup(dev);
> - kfree(cirrus);
> + drm_dev_fini(dev);
> }
>
> DEFINE_DRM_GEM_FOPS(cirrus_fops);
> @@ -575,9 +574,12 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
>
> dev = >dev;
> ret = drm_dev_init(dev, _driver, >dev);
> - if (ret)
> - goto err_free_cirrus;
> + if (ret) {
> + kfree(cirrus);
> + goto err_pci_release;
> + }
> dev->dev_private = cirrus;
> + drmm_add_final_kfree(dev, cirrus);
>
> ret = -ENOMEM;
> cirrus->vram = ioremap(pci_resource_start(pdev, 0),
> @@ -618,8 +620,6 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
> iounmap(cirrus->vram);
> err_dev_put:
> drm_dev_put(dev);
> -err_free_cirrus:
> - kfree(cirrus);
> err_pci_release:
> pci_release_regions(pdev);
> return ret;
> --
> 2.24.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 4/4] drm/qxl: Use simple encoder
Hi Thomas.
On Tue, Feb 25, 2020 at 02:10:55PM +0100, Thomas Zimmermann wrote:
> The qxl driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Acked-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 18 +++---
> 1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index ab4f8dd00400..9c0e1add59fb 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> #include "qxl_drv.h"
> #include "qxl_object.h"
> @@ -1007,9 +1008,6 @@ static struct drm_encoder *qxl_best_encoder(struct
> drm_connector *connector)
> return _output->enc;
> }
>
> -static const struct drm_encoder_helper_funcs qxl_enc_helper_funcs = {
> -};
> -
> static const struct drm_connector_helper_funcs qxl_connector_helper_funcs = {
> .get_modes = qxl_conn_get_modes,
> .mode_valid = qxl_conn_mode_valid,
> @@ -1059,15 +1057,6 @@ static const struct drm_connector_funcs
> qxl_connector_funcs = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> -static void qxl_enc_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs qxl_enc_funcs = {
> - .destroy = qxl_enc_destroy,
> -};
> -
> static int qxl_mode_create_hotplug_mode_update_property(struct qxl_device
> *qdev)
> {
> if (qdev->hotplug_mode_update_property)
> @@ -1098,15 +1087,14 @@ static int qdev_output_init(struct drm_device *dev,
> int num_output)
> drm_connector_init(dev, _output->base,
> _connector_funcs, DRM_MODE_CONNECTOR_VIRTUAL);
>
> - drm_encoder_init(dev, _output->enc, _enc_funcs,
> - DRM_MODE_ENCODER_VIRTUAL, NULL);
> + drm_simple_encoder_init(dev, _output->enc,
> + DRM_MODE_ENCODER_VIRTUAL);
return value is ignored - as it was before.
A quick grep told that it is 50/50 if return value is checked.
So OK.
Reviewed-by: Sam Ravnborg
>
> /* we get HPD via client monitors config */
> connector->polled = DRM_CONNECTOR_POLL_HPD;
> encoder->possible_crtcs = 1 << num_output;
> drm_connector_attach_encoder(_output->base,
> _output->enc);
> - drm_encoder_helper_add(encoder, _enc_helper_funcs);
> drm_connector_helper_add(connector, _connector_helper_funcs);
>
> drm_object_attach_property(>base,
> --
> 2.25.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 3/4] drm/mgag200: Use simple encoder
m_encoder *encoder = >encoder;
> struct drm_connector *connector;
> + int ret;
>
> mdev->mode_info.mode_config_initialized = true;
>
> @@ -1698,11 +1630,14 @@ int mgag200_modeset_init(struct mga_device *mdev)
>
> mga_crtc_init(mdev);
>
> - encoder = mga_encoder_init(mdev->dev);
> - if (!encoder) {
> - DRM_ERROR("mga_encoder_init failed\n");
> - return -1;
> + ret = drm_simple_encoder_init(mdev->dev, encoder,
> + DRM_MODE_ENCODER_DAC);
> + if (ret) {
> + DRM_ERROR("drm_simple_encoder_init() failed, error %d\n",
> + -ret);
DRM_ERROR is deprecated if you have a drm_device.
Consider to use:
drm_err(mdev->dev, "drm_simple_encoder_init() failed, error
%d\n",
ret);
Note - "-ret" looked strange. We usually do not modify return values
like this when printing.
> + return ret;
> }
> + encoder->possible_crtcs = 0x1;
>
> connector = mga_vga_init(mdev->dev);
> if (!connector) {
With the above addressed:
Reviewed-by: Sam Ravnborg
Sam
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 1/4] drm/simple-kms: Add drm_simple_encoder_{init, create}()
On Tue, Feb 25, 2020 at 02:10:52PM +0100, Thomas Zimmermann wrote:
> This patch makes the internal encoder implementation of the simple
> KMS helpers available to drivers.
>
> These simple-encoder helpers initialize an encoder with an empty
> implementation. This covers the requirements of most of the existing
> DRM drivers. A call to drm_simple_encoder_create() allocates and
> initializes an encoder instance, a call to drm_simple_encoder_init()
> initializes a pre-allocated instance.
>
> v3:
> * remove drm_simple_encoder_create(); not required yet
> * provide more precise documentation
> v2:
> * move simple encoder to KMS helpers
> * remove name argument; simplifies implementation
> * don't allocate with devm_ interfaces; unsafe with DRM
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_simple_kms_helper.c | 34 ++---
> include/drm/drm_simple_kms_helper.h | 4 +++
> 2 files changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 15fb516ae2d8..04309e4660de 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -26,12 +26,41 @@
> * entity. Some flexibility for code reuse is provided through a separately
> * allocated _connector object and supporting optional _bridge
> * encoder drivers.
> + *
> + * Many drivers require only a very simple encoder that fulfills the minimum
> + * requirements of the display pipeline and does not add additional
> + * functionality. The function drm_simple_encoder_init() provides an
> + * implementation of such an encoder.
> */
>
> -static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
> +static const struct drm_encoder_funcs drm_simple_encoder_funcs_cleanup = {
> .destroy = drm_encoder_cleanup,
> };
>
> +/**
> + * drm_simple_encoder_init - Initialize a preallocated encoder
> + * @dev: drm device
> + * @funcs: callbacks for this encoder
> + * @encoder_type: user visible type of the encoder
> + *
> + * Initialises a preallocated encoder that has no further functionality.
> + * Settings for possible CRTC and clones are left to their initial values.
> + * The encoder will be cleaned up automatically as part of the mode-setting
> + * cleanup.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_simple_encoder_init(struct drm_device *dev,
> + struct drm_encoder *encoder,
> + int encoder_type)
> +{
> + return drm_encoder_init(dev, encoder,
> + _simple_encoder_funcs_cleanup,
> + encoder_type, NULL);
> +}
> +EXPORT_SYMBOL(drm_simple_encoder_init);
> +
> static enum drm_mode_status
> drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
> const struct drm_display_mode *mode)
> @@ -288,8 +317,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev,
> return ret;
>
> encoder->possible_crtcs = drm_crtc_mask(crtc);
> - ret = drm_encoder_init(dev, encoder, _simple_kms_encoder_funcs,
> -DRM_MODE_ENCODER_NONE, NULL);
> + ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_NONE);
> if (ret || !connector)
> return ret;
>
> diff --git a/include/drm/drm_simple_kms_helper.h
> b/include/drm/drm_simple_kms_helper.h
> index e253ba7bea9d..a026375464ff 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -181,4 +181,8 @@ int drm_simple_display_pipe_init(struct drm_device *dev,
> const uint64_t *format_modifiers,
> struct drm_connector *connector);
>
> +int drm_simple_encoder_init(struct drm_device *dev,
> + struct drm_encoder *encoder,
> + int encoder_type);
> +
> #endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */
> --
> 2.25.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 3/4] drm/mgag200: Use simple encoder
Hi Thomas.
On Fri, Feb 21, 2020 at 08:48:48AM +0100, Thomas Zimmermann wrote:
> Hi Sam
>
> thanks for reviewing the patch set.
>
> Am 20.02.20 um 19:56 schrieb Sam Ravnborg:
> > Hi Thomas.
> >
> > On Tue, Feb 18, 2020 at 09:48:14AM +0100, Thomas Zimmermann wrote:
> >> The mgag200 driver uses an empty implementation for its encoder. Replace
> >> the code with the generic simple encoder.
> >>
> >> v2:
> >>* rebase onto new simple-encoder interface
> >>
> >> Signed-off-by: Thomas Zimmermann
> >> ---
> >> drivers/gpu/drm/mgag200/mgag200_drv.h | 7 ---
> >> drivers/gpu/drm/mgag200/mgag200_mode.c | 61 ++
> >> 2 files changed, 3 insertions(+), 65 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
> >> b/drivers/gpu/drm/mgag200/mgag200_drv.h
> >> index aa32aad222c2..9bb9e8e14539 100644
> >> --- a/drivers/gpu/drm/mgag200/mgag200_drv.h
> >> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
> >> @@ -95,7 +95,6 @@
> >> #define MATROX_DPMS_CLEARED (-1)
> >>
> >> #define to_mga_crtc(x) container_of(x, struct mga_crtc, base)
> >> -#define to_mga_encoder(x) container_of(x, struct mga_encoder, base)
> >> #define to_mga_connector(x) container_of(x, struct mga_connector, base)
> >>
> >> struct mga_crtc {
> >> @@ -110,12 +109,6 @@ struct mga_mode_info {
> >>struct mga_crtc *crtc;
> >> };
> >>
> >> -struct mga_encoder {
> >> - struct drm_encoder base;
> >> - int last_dpms;
> >> -};
> >> -
> >> -
> >> struct mga_i2c_chan {
> >>struct i2c_adapter adapter;
> >>struct drm_device *dev;
> >
> > Any particular reason why the drm_encoder is not embedded in struct
> > mga_device?
> >
> > I found it more elegant - like you did it for ast in the previous patch.
>
> I think I wanted something that uses drm_simple_encoder_create(). But I
> can change that. The embedded variant is indeed better.
You should consider to drop drm_simple_encoder_create() until there
is a driver that really needs it.
Sam
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 4/4] drm/qxl: Use simple encoder
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:15AM +0100, Thomas Zimmermann wrote:
> The qxl driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann
I looked at best_encoder - but could not see we could do anything.
So from browsing the code:
Acked-by: Sam Ravnborg
Sam
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 18 +++---
> 1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index ab4f8dd00400..9c0e1add59fb 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> #include "qxl_drv.h"
> #include "qxl_object.h"
> @@ -1007,9 +1008,6 @@ static struct drm_encoder *qxl_best_encoder(struct
> drm_connector *connector)
> return _output->enc;
> }
>
> -static const struct drm_encoder_helper_funcs qxl_enc_helper_funcs = {
> -};
> -
> static const struct drm_connector_helper_funcs qxl_connector_helper_funcs = {
> .get_modes = qxl_conn_get_modes,
> .mode_valid = qxl_conn_mode_valid,
> @@ -1059,15 +1057,6 @@ static const struct drm_connector_funcs
> qxl_connector_funcs = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> -static void qxl_enc_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs qxl_enc_funcs = {
> - .destroy = qxl_enc_destroy,
> -};
> -
> static int qxl_mode_create_hotplug_mode_update_property(struct qxl_device
> *qdev)
> {
> if (qdev->hotplug_mode_update_property)
> @@ -1098,15 +1087,14 @@ static int qdev_output_init(struct drm_device *dev,
> int num_output)
> drm_connector_init(dev, _output->base,
> _connector_funcs, DRM_MODE_CONNECTOR_VIRTUAL);
>
> - drm_encoder_init(dev, _output->enc, _enc_funcs,
> - DRM_MODE_ENCODER_VIRTUAL, NULL);
> + drm_simple_encoder_init(dev, _output->enc,
> + DRM_MODE_ENCODER_VIRTUAL);
>
> /* we get HPD via client monitors config */
> connector->polled = DRM_CONNECTOR_POLL_HPD;
> encoder->possible_crtcs = 1 << num_output;
> drm_connector_attach_encoder(_output->base,
> _output->enc);
> - drm_encoder_helper_add(encoder, _enc_helper_funcs);
> drm_connector_helper_add(connector, _connector_helper_funcs);
>
> drm_object_attach_property(>base,
> --
> 2.25.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 2/4] drm/ast: Use simple encoder
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:13AM +0100, Thomas Zimmermann wrote:
> The ast driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann
>From browsign the code - looks good:
Acked-by: Sam Ravnborg
Sam
> ---
> drivers/gpu/drm/ast/ast_drv.h | 6 +-
> drivers/gpu/drm/ast/ast_mode.c | 25 -
> 2 files changed, 9 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index f5d8780776ae..656d591b154b 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -121,6 +121,7 @@ struct ast_private {
> unsigned int next_index;
> } cursor;
>
> + struct drm_encoder encoder;
> struct drm_plane primary_plane;
> struct drm_plane cursor_plane;
>
> @@ -238,13 +239,8 @@ struct ast_crtc {
> u8 offset_x, offset_y;
> };
>
> -struct ast_encoder {
> - struct drm_encoder base;
> -};
> -
> #define to_ast_crtc(x) container_of(x, struct ast_crtc, base)
> #define to_ast_connector(x) container_of(x, struct ast_connector, base)
> -#define to_ast_encoder(x) container_of(x, struct ast_encoder, base)
>
> struct ast_vbios_stdtable {
> u8 misc;
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 562ea6d9df13..7a9f20a2fd30 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ast_drv.h"
> #include "ast_tables.h"
> @@ -968,28 +969,18 @@ static int ast_crtc_init(struct drm_device *dev)
> * Encoder
> */
>
> -static void ast_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> - kfree(encoder);
> -}
> -
> -static const struct drm_encoder_funcs ast_enc_funcs = {
> - .destroy = ast_encoder_destroy,
> -};
> -
> static int ast_encoder_init(struct drm_device *dev)
> {
> - struct ast_encoder *ast_encoder;
> + struct ast_private *ast = dev->dev_private;
> + struct drm_encoder *encoder = >encoder;
> + int ret;
>
> - ast_encoder = kzalloc(sizeof(struct ast_encoder), GFP_KERNEL);
> - if (!ast_encoder)
> - return -ENOMEM;
> + ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_DAC);
> + if (ret)
> + return ret;
>
> - drm_encoder_init(dev, _encoder->base, _enc_funcs,
> - DRM_MODE_ENCODER_DAC, NULL);
> + encoder->possible_crtcs = 1;
>
> - ast_encoder->base.possible_crtcs = 1;
> return 0;
> }
>
> --
> 2.25.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 3/4] drm/mgag200: Use simple encoder
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:14AM +0100, Thomas Zimmermann wrote:
> The mgag200 driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/mgag200/mgag200_drv.h | 7 ---
> drivers/gpu/drm/mgag200/mgag200_mode.c | 61 ++
> 2 files changed, 3 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
> b/drivers/gpu/drm/mgag200/mgag200_drv.h
> index aa32aad222c2..9bb9e8e14539 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_drv.h
> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
> @@ -95,7 +95,6 @@
> #define MATROX_DPMS_CLEARED (-1)
>
> #define to_mga_crtc(x) container_of(x, struct mga_crtc, base)
> -#define to_mga_encoder(x) container_of(x, struct mga_encoder, base)
> #define to_mga_connector(x) container_of(x, struct mga_connector, base)
>
> struct mga_crtc {
> @@ -110,12 +109,6 @@ struct mga_mode_info {
> struct mga_crtc *crtc;
> };
>
> -struct mga_encoder {
> - struct drm_encoder base;
> - int last_dpms;
> -};
> -
> -
> struct mga_i2c_chan {
> struct i2c_adapter adapter;
> struct drm_device *dev;
Any particular reason why the drm_encoder is not embedded in struct
mga_device?
I found it more elegant - like you did it for ast in the previous patch.
I also noted there is one more unused "last_dpms" - but it is outside
the scope of this patch to remove it.
Sam
> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
> b/drivers/gpu/drm/mgag200/mgag200_mode.c
> index 62a8e9ccb16d..957ea1057b6c 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mgag200_drv.h"
>
> @@ -1449,72 +1450,16 @@ static void mga_crtc_init(struct mga_device *mdev)
> drm_crtc_helper_add(_crtc->base, _helper_funcs);
> }
>
> -/*
> - * The encoder comes after the CRTC in the output pipeline, but before
> - * the connector. It's responsible for ensuring that the digital
> - * stream is appropriately converted into the output format. Setup is
> - * very simple in this case - all we have to do is inform qemu of the
> - * colour depth in order to ensure that it displays appropriately
> - */
> -
> -/*
> - * These functions are analagous to those in the CRTC code, but are intended
> - * to handle any encoder-specific limitations
> - */
> -static void mga_encoder_mode_set(struct drm_encoder *encoder,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> -{
> -
> -}
> -
> -static void mga_encoder_dpms(struct drm_encoder *encoder, int state)
> -{
> - return;
> -}
> -
> -static void mga_encoder_prepare(struct drm_encoder *encoder)
> -{
> -}
> -
> -static void mga_encoder_commit(struct drm_encoder *encoder)
> -{
> -}
> -
> -static void mga_encoder_destroy(struct drm_encoder *encoder)
> -{
> - struct mga_encoder *mga_encoder = to_mga_encoder(encoder);
> - drm_encoder_cleanup(encoder);
> - kfree(mga_encoder);
> -}
> -
> -static const struct drm_encoder_helper_funcs mga_encoder_helper_funcs = {
> - .dpms = mga_encoder_dpms,
> - .mode_set = mga_encoder_mode_set,
> - .prepare = mga_encoder_prepare,
> - .commit = mga_encoder_commit,
> -};
> -
> -static const struct drm_encoder_funcs mga_encoder_encoder_funcs = {
> - .destroy = mga_encoder_destroy,
> -};
> -
> static struct drm_encoder *mga_encoder_init(struct drm_device *dev)
> {
> struct drm_encoder *encoder;
> - struct mga_encoder *mga_encoder;
>
> - mga_encoder = kzalloc(sizeof(struct mga_encoder), GFP_KERNEL);
> - if (!mga_encoder)
> + encoder = drm_simple_encoder_create(dev, DRM_MODE_ENCODER_DAC);
> + if (IS_ERR(encoder))
> return NULL;
>
> - encoder = _encoder->base;
> encoder->possible_crtcs = 0x1;
>
> - drm_encoder_init(dev, encoder, _encoder_encoder_funcs,
> - DRM_MODE_ENCODER_DAC, NULL);
> - drm_encoder_helper_add(encoder, _encoder_helper_funcs);
> -
> return encoder;
> }
>
> --
> 2.25.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 1/4] drm/simple-kms: Add drm_simple_encoder_{init, create}()
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:12AM +0100, Thomas Zimmermann wrote:
> This patch makes the internal encoder implementation of the simple
> KMS helpers available to drivers.
>
> These simple-encoder helpers initialize an encoder with an empty
> implementation. This covers the requirements of most of the existing
> DRM drivers. A call to drm_simple_encoder_create() allocates and
> initializes an encoder instance, a call to drm_simple_encoder_init()
> initializes a pre-allocated instance.
>
> v2:
> * move simple encoder to KMS helpers
> * remove name argument; simplifies implementation
> * don't allocate with devm_ interfaces; unsafe with DRM
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_simple_kms_helper.c | 83 -
> include/drm/drm_simple_kms_helper.h | 7 +++
> 2 files changed, 87 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 15fb516ae2d8..745c2f34c42b 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -26,12 +26,90 @@
> * entity. Some flexibility for code reuse is provided through a separately
> * allocated _connector object and supporting optional _bridge
> * encoder drivers.
> + *
> + * Many drivers use an encoder with an empty implementation. Such encoders
> + * fulfill the minimum requirements of the display pipeline, but don't add
> + * additional functionality. The simple-encoder functions
> + * drm_simple_encoder_init() and drm_simple_encoder_create() provide an
> + * appropriate implementation.
> */
>
> -static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
> +static const struct drm_encoder_funcs drm_simple_encoder_funcs_cleanup = {
> .destroy = drm_encoder_cleanup,
> };
>
> +/**
> + * drm_simple_encoder_init - Initialize a preallocated encoder
> + * @dev: drm device
> + * @funcs: callbacks for this encoder
> + * @encoder_type: user visible type of the encoder
> + *
> + * Initialises a preallocated encoder that has no further functionality. The
> + * encoder will be released automatically.
I got confused here. The comment says the encoder is automatically
released. But in this case we have a preallocated encoder (maybe
embedded in ast_private or something.
So the encoder is - as I understnad it - not released. But it is cleaned
up as it is also documented in the next sentences.
Sorry if I am dense, just returned from some travelling...
Sam
Settings for possible CRTC and
> + * clones are left to their initial values. The encoder will be cleaned up
> + * automatically as part of the mode-setting cleanup.
> + *
> + * Also see drm_simple_encoder_create().
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_simple_encoder_init(struct drm_device *dev,
> + struct drm_encoder *encoder,
> + int encoder_type)
> +{
> + return drm_encoder_init(dev, encoder,
> + _simple_encoder_funcs_cleanup,
> + encoder_type, NULL);
> +}
> +EXPORT_SYMBOL(drm_simple_encoder_init);
> +
> +static void drm_encoder_destroy(struct drm_encoder *encoder)
> +{
> + drm_encoder_cleanup(encoder);
> + kfree(encoder);
> +}
> +
> +static const struct drm_encoder_funcs drm_simple_encoder_funcs_destroy = {
> + .destroy = drm_encoder_destroy,
> +};
> +
> +/**
> + * drm_simple_encoder_create - Allocate and initialize an encoder
> + * @dev: drm device
> + * @encoder_type: user visible type of the encoder
> + *
> + * Allocates and initialises an encoder that has no further functionality.
> The
> + * encoder will be destroyed automatically as part of the mode-setting
> cleanup.
> + *
> + * See drm_simple_encoder_init() for more information.
> + *
> + * Returns:
> + * The encoder on success, a pointer-encoder error code on failure.
> + */
> +struct drm_encoder *drm_simple_encoder_create(struct drm_device *dev,
> + int encoder_type)
> +{
> + struct drm_encoder *encoder;
> + int ret;
> +
> + encoder = kzalloc(sizeof(*encoder), GFP_KERNEL);
> + if (!encoder)
> + return ERR_PTR(-ENOMEM);
> + ret = drm_encoder_init(dev, encoder,
> +_simple_encoder_funcs_destroy,
> +encoder_type, NULL);
> + if (ret)
> + goto err_kfree;
> +
> + return encoder;
> +
> +err_kfree:
> + kfree(encoder);
> + return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL(drm_simple_encoder_create);
> +
> static enum drm_mode_status
> drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
> const struct drm_display_mode *mode)
> @@ -288,8 +366,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev,
> return ret;
>
> encoder->possible_crtcs =
Re: [PATCH v2 1/4] drm/simple-kms: Add drm_simple_encoder_{init, create}()
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:12AM +0100, Thomas Zimmermann wrote:
> This patch makes the internal encoder implementation of the simple
> KMS helpers available to drivers.
>
> These simple-encoder helpers initialize an encoder with an empty
> implementation. This covers the requirements of most of the existing
> DRM drivers. A call to drm_simple_encoder_create() allocates and
> initializes an encoder instance, a call to drm_simple_encoder_init()
> initializes a pre-allocated instance.
>
> v2:
> * move simple encoder to KMS helpers
> * remove name argument; simplifies implementation
> * don't allocate with devm_ interfaces; unsafe with DRM
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_simple_kms_helper.c | 83 -
> include/drm/drm_simple_kms_helper.h | 7 +++
> 2 files changed, 87 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 15fb516ae2d8..745c2f34c42b 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -26,12 +26,90 @@
> * entity. Some flexibility for code reuse is provided through a separately
> * allocated _connector object and supporting optional _bridge
> * encoder drivers.
> + *
> + * Many drivers use an encoder with an empty implementation. Such encoders
> + * fulfill the minimum requirements of the display pipeline, but don't add
> + * additional functionality. The simple-encoder functions
> + * drm_simple_encoder_init() and drm_simple_encoder_create() provide an
> + * appropriate implementation.
This paragraph reads a bit strange to me - I read this as a
justification for addding a generic encoded that can be used by exisitg
drivers.
How about something like this:
Many drivers requires a very simple encoder that only fullfill
the minimum requirements of the display pipeline and do not add
any extra functionslity.
The simple-encoder functions drm_simple_encoder_init() and
drm_simple_encoder_create() provides an impålmentation of such
a simple encoder.
The simple encoder includes automatically release of resources.
And then leave it to the changelog to tell what should be done in
existing drivers.
> */
>
> -static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
> +static const struct drm_encoder_funcs drm_simple_encoder_funcs_cleanup = {
> .destroy = drm_encoder_cleanup,
> };
>
> +/**
> + * drm_simple_encoder_init - Initialize a preallocated encoder
> + * @dev: drm device
> + * @funcs: callbacks for this encoder
> + * @encoder_type: user visible type of the encoder
> + *
> + * Initialises a preallocated encoder that has no further functionality. The
> + * encoder will be released automatically. Settings for possible CRTC and
> + * clones are left to their initial values. The encoder will be cleaned up
> + * automatically as part of the mode-setting cleanup.
> + *
> + * Also see drm_simple_encoder_create().
s/Also see/See also/??
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_simple_encoder_init(struct drm_device *dev,
> + struct drm_encoder *encoder,
> + int encoder_type)
> +{
> + return drm_encoder_init(dev, encoder,
> + _simple_encoder_funcs_cleanup,
> + encoder_type, NULL);
> +}
> +EXPORT_SYMBOL(drm_simple_encoder_init);
> +
> +static void drm_encoder_destroy(struct drm_encoder *encoder)
> +{
> + drm_encoder_cleanup(encoder);
> + kfree(encoder);
> +}
> +
> +static const struct drm_encoder_funcs drm_simple_encoder_funcs_destroy = {
> + .destroy = drm_encoder_destroy,
> +};
> +
> +/**
> + * drm_simple_encoder_create - Allocate and initialize an encoder
> + * @dev: drm device
> + * @encoder_type: user visible type of the encoder
> + *
> + * Allocates and initialises an encoder that has no further functionality.
> The
> + * encoder will be destroyed automatically as part of the mode-setting
> cleanup.
> + *
> + * See drm_simple_encoder_init() for more information.
> + *
> + * Returns:
> + * The encoder on success, a pointer-encoder error code on failure.
pointer-encoded?
> + */
> +struct drm_encoder *drm_simple_encoder_create(struct drm_device *dev,
> + int encoder_type)
> +{
> + struct drm_encoder *encoder;
> + int ret;
> +
> + encoder = kzalloc(sizeof(*encoder), GFP_KERNEL);
> + if (!encoder)
> + return ERR_PTR(-ENOMEM);
> + ret = drm_encoder_init(dev, encoder,
> +_simple_encoder_funcs_destroy,
> +encoder_type, NULL);
> + if (ret)
> + goto err_kfree;
> +
> + return encoder;
> +
> +err_kfree:
> + kfree(encoder);
> + return ERR_PTR(ret);
> +}
>
Re: [PATCH v1 31/33] drm/bochs: drop use of drmP.h
On Mon, Jul 01, 2019 at 08:39:08AM +0200, Gerd Hoffmann wrote: > On Sun, Jun 30, 2019 at 08:19:20AM +0200, Sam Ravnborg wrote: > > Drop use of the deprecated drmP.h header file. > > Made bochs.h self-contained and then fixed > > fallout in remaining files. > > Several unused includes was dropped in the process. > > > > Signed-off-by: Sam Ravnborg > > Cc: Gerd Hoffmann > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: virtualization@lists.linux-foundation.org > > Acked-by: Gerd Hoffmann Thanks again, applied. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v1 27/33] drm/virtgpu: drop use of drmP.h
On Mon, Jul 01, 2019 at 08:38:56AM +0200, Gerd Hoffmann wrote: > On Sun, Jun 30, 2019 at 08:19:16AM +0200, Sam Ravnborg wrote: > > Drop use of the deprecated drmP.h header file. > > Fix fallout by adding missing include files. > > > > Signed-off-by: Sam Ravnborg > > Cc: David Airlie > > Cc: Gerd Hoffmann > > Cc: Daniel Vetter > > Cc: virtualization@lists.linux-foundation.org > > Acked-by: Gerd Hoffmann Thanks, applied. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v1 09/33] drm/qxl: drop use of drmP.h
On Mon, Jul 01, 2019 at 08:38:43AM +0200, Gerd Hoffmann wrote: > On Sun, Jun 30, 2019 at 08:18:58AM +0200, Sam Ravnborg wrote: > > Drop use of the deprecated drmP.h header file. > > While touching the files divided includes in blocks, > > and when needed sort the blocks. > > Fix fallout. > > > > Signed-off-by: Sam Ravnborg > > Cc: Dave Airlie > > Cc: Gerd Hoffmann > > Cc: virtualization@lists.linux-foundation.org > > Cc: spice-de...@lists.freedesktop.org > > Acked-by: Gerd Hoffmann Thanks, applied. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v1 31/33] drm/bochs: drop use of drmP.h
Drop use of the deprecated drmP.h header file. Made bochs.h self-contained and then fixed fallout in remaining files. Several unused includes was dropped in the process. Signed-off-by: Sam Ravnborg Cc: Gerd Hoffmann Cc: David Airlie Cc: Daniel Vetter Cc: virtualization@lists.linux-foundation.org --- The list of cc: was too large to add all recipients to the cover letter. Please find cover letter here: https://lists.freedesktop.org/archives/dri-devel/2019-June/thread.html Search for "drm: drop use of drmp.h in drm-misc" Sam drivers/gpu/drm/bochs/bochs.h | 6 ++ drivers/gpu/drm/bochs/bochs_drv.c | 7 +++ drivers/gpu/drm/bochs/bochs_hw.c | 4 drivers/gpu/drm/bochs/bochs_kms.c | 8 +--- 4 files changed, 14 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h index cc35d492142c..498e96fb61b6 100644 --- a/drivers/gpu/drm/bochs/bochs.h +++ b/drivers/gpu/drm/bochs/bochs.h @@ -1,17 +1,15 @@ /* SPDX-License-Identifier: GPL-2.0 */ + #include #include -#include #include #include #include #include -#include - #include #include - +#include #include /* -- */ diff --git a/drivers/gpu/drm/bochs/bochs_drv.c b/drivers/gpu/drm/bochs/bochs_drv.c index 78ad6c98861d..5d0a0060c22b 100644 --- a/drivers/gpu/drm/bochs/bochs_drv.c +++ b/drivers/gpu/drm/bochs/bochs_drv.c @@ -2,11 +2,10 @@ /* */ -#include #include -#include -#include -#include +#include + +#include #include #include "bochs.h" diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c index 791ab2f79947..29217e696549 100644 --- a/drivers/gpu/drm/bochs/bochs_hw.c +++ b/drivers/gpu/drm/bochs/bochs_hw.c @@ -2,6 +2,10 @@ /* */ +#include + +#include + #include "bochs.h" /* -- */ diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index 5904eddc83a5..f6ae34bb2209 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -2,12 +2,14 @@ /* */ -#include "bochs.h" +#include + #include -#include -#include #include #include +#include + +#include "bochs.h" static int defx = 1024; static int defy = 768; -- 2.20.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v1 09/33] drm/qxl: drop use of drmP.h
Drop use of the deprecated drmP.h header file.
While touching the files divided includes in blocks,
and when needed sort the blocks.
Fix fallout.
Signed-off-by: Sam Ravnborg
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
The list of cc: was too large to add all recipients to the cover letter.
Please find cover letter here:
https://lists.freedesktop.org/archives/dri-devel/2019-June/thread.html
Search for "drm: drop use of drmp.h in drm-misc"
Sam
drivers/gpu/drm/qxl/qxl_cmd.c | 2 ++
drivers/gpu/drm/qxl/qxl_debugfs.c | 4 ++--
drivers/gpu/drm/qxl/qxl_display.c | 3 +++
drivers/gpu/drm/qxl/qxl_draw.c| 2 ++
drivers/gpu/drm/qxl/qxl_drv.c | 10 +++---
drivers/gpu/drm/qxl/qxl_drv.h | 7 +++
drivers/gpu/drm/qxl/qxl_gem.c | 1 -
drivers/gpu/drm/qxl/qxl_ioctl.c | 3 +++
drivers/gpu/drm/qxl/qxl_irq.c | 4
drivers/gpu/drm/qxl/qxl_kms.c | 9 ++---
drivers/gpu/drm/qxl/qxl_release.c | 6 +-
drivers/gpu/drm/qxl/qxl_ttm.c | 16 +---
12 files changed, 46 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index 0a2e51af1230..ac1081f55b51 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -25,6 +25,8 @@
/* QXL cmd/ring handling */
+#include
+
#include
#include "qxl_drv.h"
diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c
b/drivers/gpu/drm/qxl/qxl_debugfs.c
index 118422549828..a85ec100b0cc 100644
--- a/drivers/gpu/drm/qxl/qxl_debugfs.c
+++ b/drivers/gpu/drm/qxl/qxl_debugfs.c
@@ -28,9 +28,9 @@
* Alon Levy
*/
-#include
+#include
+#include
-#include
#include "qxl_drv.h"
#include "qxl_object.h"
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 8b319ebbb0fb..023fb5a69af1 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -24,11 +24,14 @@
*/
#include
+#include
+
#include
#include
#include
#include
#include
+#include
#include "qxl_drv.h"
#include "qxl_object.h"
diff --git a/drivers/gpu/drm/qxl/qxl_draw.c b/drivers/gpu/drm/qxl/qxl_draw.c
index 97c3f1a95a32..5bebf1ea1c5d 100644
--- a/drivers/gpu/drm/qxl/qxl_draw.c
+++ b/drivers/gpu/drm/qxl/qxl_draw.c
@@ -20,6 +20,8 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
+
#include "qxl_drv.h"
#include "qxl_object.h"
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index d8f64886474b..b57a37543613 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -28,14 +28,18 @@
*Alon Levy
*/
-#include
+#include "qxl_drv.h"
#include
+#include
+#include
-#include
#include
+#include
+#include
#include
+#include
#include
-#include "qxl_drv.h"
+
#include "qxl_object.h"
static const struct pci_device_id pciidlist[] = {
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 2896bb6fdbf4..ae82e5fab09c 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -31,22 +31,21 @@
*/
#include
-#include
#include
#include
+#include
#include
#include
#include
+#include
#include
-#include
+#include
#include
#include
-/* just for ttm_validate_buffer */
#include
#include
#include
-#include
#include "qxl_dev.h"
diff --git a/drivers/gpu/drm/qxl/qxl_gem.c b/drivers/gpu/drm/qxl/qxl_gem.c
index 89606c819d82..89e4f9a7249c 100644
--- a/drivers/gpu/drm/qxl/qxl_gem.c
+++ b/drivers/gpu/drm/qxl/qxl_gem.c
@@ -23,7 +23,6 @@
* Alon Levy
*/
-#include
#include
#include "qxl_drv.h"
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index d410e2925162..8117a45b3610 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -23,6 +23,9 @@
* Alon Levy
*/
+#include
+#include
+
#include "qxl_drv.h"
#include "qxl_object.h"
diff --git a/drivers/gpu/drm/qxl/qxl_irq.c b/drivers/gpu/drm/qxl/qxl_irq.c
index 3bb31add6350..8435af108632 100644
--- a/drivers/gpu/drm/qxl/qxl_irq.c
+++ b/drivers/gpu/drm/qxl/qxl_irq.c
@@ -23,6 +23,10 @@
* Alon Levy
*/
+#include
+
+#include
+
#include "qxl_drv.h"
irqreturn_t qxl_irq_handler(int irq, void *arg)
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index bee61fa2c9bc..611cbe7aee69 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -23,11 +23,14 @@
* Alon Levy
*/
-#include "qxl_drv.h"
-#include "qxl_object.h"
+#include
+#include
+#include
#include
-#include
+
+#include "qxl_drv.h"
+#include "qxl_object.h"
int qxl_lo
[PATCH v1 27/33] drm/virtgpu: drop use of drmP.h
Drop use of the deprecated drmP.h header file. Fix fallout by adding missing include files. Signed-off-by: Sam Ravnborg Cc: David Airlie Cc: Gerd Hoffmann Cc: Daniel Vetter Cc: virtualization@lists.linux-foundation.org --- The list of cc: was too large to add all recipients to the cover letter. Please find cover letter here: https://lists.freedesktop.org/archives/dri-devel/2019-June/thread.html Search for "drm: drop use of drmp.h in drm-misc" Sam drivers/gpu/drm/virtio/virtgpu_debugfs.c | 4 ++-- drivers/gpu/drm/virtio/virtgpu_display.c | 7 +-- drivers/gpu/drm/virtio/virtgpu_drv.c | 5 - drivers/gpu/drm/virtio/virtgpu_drv.h | 6 +++--- drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +- drivers/gpu/drm/virtio/virtgpu_gem.c | 4 +++- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 8 +--- drivers/gpu/drm/virtio/virtgpu_kms.c | 4 +++- drivers/gpu/drm/virtio/virtgpu_plane.c | 6 -- drivers/gpu/drm/virtio/virtgpu_prime.c | 2 ++ drivers/gpu/drm/virtio/virtgpu_ttm.c | 13 +++-- drivers/gpu/drm/virtio/virtgpu_vq.c | 7 --- 12 files changed, 43 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_debugfs.c b/drivers/gpu/drm/virtio/virtgpu_debugfs.c index ed0fcda713c3..5156e6b279db 100644 --- a/drivers/gpu/drm/virtio/virtgpu_debugfs.c +++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c @@ -23,8 +23,8 @@ * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */ -#include -#include +#include +#include #include "virtgpu_drv.h" diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c index ba16e8cb7124..e622485ae826 100644 --- a/drivers/gpu/drm/virtio/virtgpu_display.c +++ b/drivers/gpu/drm/virtio/virtgpu_display.c @@ -25,11 +25,14 @@ * OTHER DEALINGS IN THE SOFTWARE. */ -#include "virtgpu_drv.h" #include +#include +#include #include #include -#include +#include + +#include "virtgpu_drv.h" #define XRES_MIN32 #define YRES_MIN32 diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index 99bcd290f1fb..0fc32fa0b3c0 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.c +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c @@ -29,10 +29,13 @@ #include #include #include -#include + #include +#include +#include #include "virtgpu_drv.h" + static struct drm_driver driver; static int virtio_gpu_modeset = -1; diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index 9e2d3062b01d..f4ecea6054ba 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -31,16 +31,16 @@ #include #include -#include -#include #include #include #include +#include +#include #include #include #include -#include #include +#include #define DRIVER_NAME "virtio_gpu" #define DRIVER_DESC "virtio GPU" diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c b/drivers/gpu/drm/virtio/virtgpu_fence.c index 70d6c4329778..a0514f5bd006 100644 --- a/drivers/gpu/drm/virtio/virtgpu_fence.c +++ b/drivers/gpu/drm/virtio/virtgpu_fence.c @@ -23,8 +23,8 @@ * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */ -#include #include + #include "virtgpu_drv.h" static const char *virtio_get_driver_name(struct dma_fence *f) diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c index 1e49e08dd545..292566146814 100644 --- a/drivers/gpu/drm/virtio/virtgpu_gem.c +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c @@ -23,7 +23,9 @@ * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */ -#include +#include +#include + #include "virtgpu_drv.h" void virtio_gpu_gem_free_object(struct drm_gem_object *gem_obj) diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c index 1b50c34a29dc..d379d2e7e3ef 100644 --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c @@ -25,11 +25,13 @@ * OTHER DEALINGS IN THE SOFTWARE. */ -#include -#include -#include +#include #include +#include +#include +#include + #include "virtgpu_drv.h" static void convert_to_hw_box(struct virtio_gpu_box *dst, diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 84b6a6bf00c6..c190702fab72 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -25,7 +25,9 @@ #include #include -#include + +#include + #include "virtgpu_drv.h" static void virtio_gpu_config_changed_work_func(struct work_struct *work) diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c index 024c2aa0c929..f96c8296307e 100644 --- a/drivers/gpu/drm/virtio/virtgpu_plane.c +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c @@ -23,9
Re: [PATCH 06/59] drm/prime: Actually remove DRIVER_PRIME everywhere
Hi Daniel.
Minor nitpick..
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 65d599065709..4fd09a9ad67a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -3193,7 +3193,7 @@ static struct drm_driver driver = {
>* deal with them for Intel hardware.
>*/
> .driver_features =
> - DRIVER_GEM | DRIVER_PRIME |
> + DRIVER_GEM |
> DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_SYNCOBJ,
Adds a whitespace.
Sam
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/cirrus: remove leftover files
On Wed, May 22, 2019 at 12:33:07PM +0200, Gerd Hoffmann wrote:
> cirrus_drv.h and cirrus_ttm.c are unused since commit ab3e023b1b4c
> ("drm/cirrus: rewrite and modernize driver"), apparently I ran "rm"
> instead of "git rm" on them so they are still in present the tree.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Sam Ravnborg
Always nice with the code removal patches.
Will you apply yourself?
Sam
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 01/19] drm: Add |struct drm_gem_vram_object| and helpers
Hi Thomas.
> >> +
> >> +/**
> >> + * Returns the container of type drm_gem_vram_object
> >> + * for field bo.
> >> + * @bo: the VRAM buffer object
> >> + * Returns: The containing GEM VRAM object
> >> + */
> >> +static inline struct drm_gem_vram_object* drm_gem_vram_of_bo(
> >> + struct ttm_buffer_object *bo)
> >> +{
> >> + return container_of(bo, struct drm_gem_vram_object, bo);
> >> +}
> > Indent funny. USe same indent as used in other parts of file for
> > function arguments.
>
> If I put the argument next to the function's name, it will exceed the
> 80-character limit. From the coding-style document, I could not see what
> to do in this case. One solution would move the return type to a
> separate line before the function name. I've not seen that anywhere in
> the source code, so moving the argument onto a separate line and
> indenting by one tab appears to be the next best solution. Please let me
> know if there's if there's a preferred style for cases like this one.
Readability has IMO higher priority than some limit of 80 chars.
And it hurts readability (at least my OCD) when style changes
as you do with indent here. So my personal preference is to fix
indent and accect longer lines.
But you ask for a preferred style - which I do not think we have in this
case. So it boils down to what you prefer.
Enough bikeshedding, thanks for the quick response.
Sam
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 01/19] drm: Add |struct drm_gem_vram_object| and helpers
Hi Thomas.
Some minor things and some bikeshedding too.
One general^Wbikeshedding thing - unint32_t is used in many places.
And then s64 in one place.
Seems like two concepts are mixed.
Maybe be consistent and use u32, s32 everywhere?
I did not read the code carefully enough to understand it.
I cannot give a r-b or a-b - as I feel I need to understand it to do
so.
Sam
On Mon, Apr 29, 2019 at 04:43:23PM +0200, Thomas Zimmermann wrote:
> The type |struct drm_gem_vram_object| implements a GEM object for simple
> framebuffer devices with dedicated video memory. The BO is either located
> in VRAM or system memory.
>
> The implementation has been created from the respective code in ast,
> bochs and mgag200. These drivers copy their implementation from each
> other; except for the names of several data types. The helpers are
> currently build with TTM, but this is considered an implementation
> detail and may change in future updates.
>
> v2:
> * rename to |struct drm_gem_vram_object|
> * move drm_is_gem_ttm() to a later patch in the series
> * add drm_gem_vram_kmap_at()
> * return is_iomem from kmap functions
> * redefine TTM placement flags for public interface
> * documentation fixes
>
> Signed-off-by: Thomas Zimmermann
> ---
> Documentation/gpu/drm-mm.rst | 12 +
> drivers/gpu/drm/Kconfig | 13 +
> drivers/gpu/drm/Makefile | 4 +
> drivers/gpu/drm/drm_gem_vram_helper.c| 410 +++
> drivers/gpu/drm/drm_vram_helper_common.c | 6 +
> include/drm/drm_gem_vram_helper.h| 92 +
> 6 files changed, 537 insertions(+)
> create mode 100644 drivers/gpu/drm/drm_gem_vram_helper.c
> create mode 100644 drivers/gpu/drm/drm_vram_helper_common.c
> create mode 100644 include/drm/drm_gem_vram_helper.h
>
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index 54a696d961a7..d5327ed608d7 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -380,6 +380,18 @@ GEM CMA Helper Functions Reference
> .. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
> :export:
>
> +GEM VRAM Helper Functions Reference
> +--
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c
> + :doc: overview
> +
> +.. kernel-doc:: include/drm/drm_gem_vram_helper.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c
> + :export:
> +
> VMA Offset Manager
> ==
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 2267e84d5cb4..c0d49a6c09d2 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -160,6 +160,12 @@ config DRM_TTM
> GPU memory types. Will be enabled automatically if a device driver
> uses it.
>
> +config DRM_VRAM_HELPER
> + tristate
> + depends on DRM && DRM_TTM
> + help
> + Helpers for VRAM memory management
> +
> config DRM_GEM_CMA_HELPER
> bool
> depends on DRM
> @@ -179,6 +185,13 @@ config DRM_GEM_SHMEM_HELPER
> help
> Choose this if you need the GEM shmem helper functions
>
> +config DRM_GEM_VRAM_HELPER
> + bool
> + depends on DRM
> + select DRM_VRAM_HELPER
> + help
> + Choose this if you need the GEM VRAM helper functions
> +
I cannot remember how select will deal with symbols whos has
a "depends on".
But if I recall correct then the "depends on" will be ignored
or in best case trigger a warning.
In other words - when we have symbols we select they should not
have a depends on.
What can be done is something like:
symbol foo
bool
symbol bar
depends on foo
symbol foobar
bool "This is what you need - select me"
select foo
So when one chooses "foobar" then we will select "foo" and this will
satisfy bar.
But maybe this rambling is irrelevant - maybe check what we do with
other selectable symbols in DRM.
> +/**
> + * DOC: overview
> + *
> + * This library provides a GEM object that is backed by VRAM. It
> + * can be used for simple framebuffer devices with dedicated memory.
> + */
It is likely only me, but...
I could use a short explanation what is GEM and maybe also VRAM.
VRAM as video RAM, but maybe there is more constraints?
(When I first looked at DRM I wondered what you used Virtual RAM for.
But thats a long time ago so it counts only as a funny story.
> + * Buffer-objects helpers
> + */
> +
> +static void drm_gem_vram_cleanup(struct drm_gem_vram_object *gbo)
> +{
> + /* We got here via ttm_bo_put(), which means that the
> + * TTM buffer object in 'bo' has already been cleaned
> + * up; only release the GEM object. */
> + drm_gem_object_release(>gem);
> +}
> +
> +static void drm_gem_vram_destroy(struct drm_gem_vram_object *gbo)
> +{
> + drm_gem_vram_cleanup(gbo);
> + kfree(gbo);
> +}
> +
> +static void ttm_buffer_object_destroy(struct ttm_buffer_object *bo)
> +{
Re: [PATCH] drm/bochs: use simple display pipe
Hi Gerd.
>
> #include
>
> @@ -69,9 +70,8 @@ struct bochs_device {
> struct edid *edid;
>
> /* drm */
> - struct drm_device *dev;
> - struct drm_crtc crtc;
> - struct drm_encoder encoder;
> + struct drm_device *dev;
> + struct drm_simple_display_pipe pipe;
> struct drm_connector connector;
Have you considered to embed drm_device in the bochs_device struct?
This is the new way to do it.
This should likely be a follow-up patch...
Rest of the patch looked good.
Did not do a proper review but you can add my:
Acked-by: Sam Ravnborg
Sam
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 6/6] drm/cirrus: rewrite and modernize driver.
Hi Gerd.
Very nice diffstat - good work indeed!
> I think it'll still be alot easier to review than a
> longish baby-step patch series.
Agreed.
Some random nits below.
With the relevant parts addressed you can add my:
Reviewed-by: Sam Ravnborg
> new file mode 100644
> index ..5060e3d854d3
> --- /dev/null
> +++ b/drivers/gpu/drm/cirrus/cirrus.c
> @@ -0,0 +1,621 @@
> +/*
> + * Copyright 2012-2019 Red Hat
> + *
> + * This file is subject to the terms and conditions of the GNU General
> + * Public License version 2. See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * Authors: Matthew Garrett
> + * Dave Airlie
> + * Gerd Hoffmann
> + *
> + * Portions of this code derived from cirrusfb.c:
> + * drivers/video/cirrusfb.c - driver for Cirrus Logic chipsets
> + *
> + * Copyright 1999-2001 Jeff Garzik
> + */
Can we introduce an SPDX identifier?
(I am not good at the license stuff, so I cannot tell)
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Please sort again, you added a few new includes since last time
> +struct cirrus_device {
> + struct drm_device dev;
> + struct drm_simple_display_pipe pipe;
> + struct drm_connector conn;
> + unsigned int cpp;
> + unsigned int pitch;
> + void __iomem *vram;
> + void __iomem *mmio;
> +};
> +
> +/* -- */
> +/*
> + * The meat of this driver. The core passes us a mode and we have to program
> + * it. The modesetting here is the bare minimum required to satisfy the qemu
> + * emulation of this hardware, and running this against a real device is
> + * likely to result in an inadequately programmed mode. We've already had
> + * the opportunity to modify the mode, so whatever we receive here should
> + * be something that can be correctly programmed and displayed
> + */
> +
> +#define RREG8(reg) ioread8(((void __iomem *)cirrus->mmio) + (reg))
> +#define WREG8(reg, v) iowrite8(v, ((void __iomem *)cirrus->mmio) + (reg))
> +#define RREG32(reg) ioread32(((void __iomem *)cirrus->mmio) + (reg))
> +#define WREG32(reg, v) iowrite32(v, ((void __iomem *)cirrus->mmio) + (reg))
The cast of cirrus->mmio to (void __iomem *) should not be necessary as
this is the type is has in struct cirrus_device
There is not reason to use a define, use can use a static inline function
> +
> +#define SEQ_INDEX 4
> +#define SEQ_DATA 5
> +
> +#define WREG_SEQ(reg, v) \
> + do {\
> + WREG8(SEQ_INDEX, reg); \
> + WREG8(SEQ_DATA, v); \
> + } while (0) \
This is only used once, drop the define?
> +#define CRT_INDEX 0x14
> +#define CRT_DATA 0x15
> +
> +#define WREG_CRT(reg, v) \
> + do {\
> + WREG8(CRT_INDEX, reg); \
> + WREG8(CRT_DATA, v); \
> + } while (0) \
static inline?
> +#define GFX_INDEX 0xe
> +#define GFX_DATA 0xf
> +
> +#define WREG_GFX(reg, v) \
> + do {\
> + WREG8(GFX_INDEX, reg); \
> + WREG8(GFX_DATA, v); \
> + } while (0) \
Used twice - drop?
> +
> +#define VGA_DAC_MASK 0x6
> +
> +#define WREG_HDR(v) \
> + do {\
> + RREG8(VGA_DAC_MASK);\
> + RREG8(VGA_DAC_MASK);\
> + RREG8(VGA_DAC_MASK);\
> + RREG8(VGA_DAC_MASK);\
> + WREG8(VGA_DAC_MASK, v); \
> + } while (0) \
Used once, drop?
> +static int cirrus_convert_to(struct drm_framebuffer *fb)
> +{
> + if (fb->format->cpp[0] == 4 && fb-&g
Re: [PATCH 01/26] drm/irq: Don't check for DRIVER_HAVE_IRQ in drm_irq_(un)install
Hi Daniel. On Thu, Jan 24, 2019 at 05:58:06PM +0100, Daniel Vetter wrote: > If a non-legacy driver calls these it's valid to assume there is > interrupt support. The flag is really only needed for legacy drivers. > > Also remove all the flag usage from non-legacy drivers. > > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: intel-...@lists.freedesktop.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: virtualization@lists.linux-foundation.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org The actual code changes looks good. But if this is the right thing to do I cannot tell. On this (limited) basis I provide an: Reviewed-by: Sam Ravnborg ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 18/23] drm/qxl: remove dead qxl fbdev emulation code
Hi Noralf. > > Lovely diffstat, thanks to the new generic fbdev emulation. > > > > drm/qxl/Makefile |2 > > drm/qxl/qxl_draw.c | 232 > > drm/qxl/qxl_drv.h | 21 --- > > drm/qxl/qxl_fb.c | 300 > > - > > > > Signed-off-by: Gerd Hoffmann > > --- > > drivers/gpu/drm/qxl/qxl_drv.h | 21 --- > > drivers/gpu/drm/qxl/qxl_draw.c | 232 --- > > drivers/gpu/drm/qxl/qxl_fb.c | 300 > > - > > drivers/gpu/drm/qxl/Makefile | 2 +- > > 4 files changed, 1 insertion(+), 554 deletions(-) > > delete mode 100644 drivers/gpu/drm/qxl/qxl_fb.c > > > > Nice! > > Acked-by: Noralf Trønnes It must be a very satisfying experience to see such benefits of the many hours of works you have put into the genric fbdev emulation code. Well done, and indeed a nice patch from Gerd. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm: Split out drm_probe_helper.h
Hi Daniel. On Thu, Jan 17, 2019 at 10:03:34PM +0100, Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. How are the plans to get this patchset merged? There were dependencies on onging drmP.h removal in i915 IIRC? I guess my "Minimize drmP.h dependencies" patch-set also have a role in this. This does not hold up any work of mine, mainly wanted to make sure this was not lost between all the other patches. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm: Split out drm_probe_helper.h
Hi Daniel et al. > > > > Yeah the drm_crtc_helper.h header is a bit the miniature drmP.h for legacy > > kms drivers. Just removing it from all the atomic drivers caused lots of > > fallout, I expect even more if you entirely remove the includes it has. > > Maybe a todo, care to pls create that patch since it's your idea? > > The main reason I bailed out initially was that this would create > small changes to several otherwise seldomly touched files. > And then we would later come and remove drmP.h - so lots of > small but incremental changes to the same otherwise seldomly > edited files. > And the job was only partially done. > > I will try to experiment with an approach where I clean up the > include/drm/*.h files a little (like suggested above, +delete drmP.h > and maybe a bit more). > > Then to try on a driver by driver basis to make it build with a > cleaned set of include files. > I hope that the cleaned up driver can still build without the > cleaned header files so the changes can be submitted piecemal. > > Will do so with an eye on the lesser maintained drivers to try it > out to avoid creating too much chrunch for others. I have now a few patches queued, but the result is not too pretty. I did the following: - For all files in include/drm/*.h the set of include files were adjusted to the minimum number of files required to make them build without any other files included first. Created one .c file for each .h file. Then included the .h file and adjusted to the minimal set of include files. In the process a lot of forwards were added. - Deleted drmP.h - Fixed build of a few drivers: sti, tilcdc, gma500, tve200, via Some observations: - Killing all the includes not needed in the headers files results in a a lot of extra changes. Examples: drm_modseset_helper_vtables.h is no longer included by anyone, so needs to be added in many files drm_atomic_state_helper.h is no longer included by anyone so likewise needs to be added in many files - It is very tedious to do this properly. The process I followed was: - delete / comment out all include files - add back the obvious from a quick scan of the code - build - fix - build - fix - build - fix ... - next file... - The result is errorprone as only the allyesconfig + allmodconfig variants are tested. But reallife configurations are more diverse. Current diffstat: 111 files changed, 771 insertions(+), 401 deletions(-) This is for the 5 drivers alone and not the header cleanup. So long story short - this is not good and not the way forward. I will try to come up with a few improvements to make the headers files selfcontained, but restricted to the changes that add forwards/include to avoid the chrunch in all the drivers. And then post for review a few patches to clean up some headers. If the cleanup gets a go I will try to persuade the introduction of these. This will include, but will not be limited to, the above mentioned drm_crtc_helper.h header file. For now too much time was already spent on this, so it is at the moment pushed back on my TODO list. This mail serve also as a kind of "where had I left", when/if I pick this up again. If there are anyone that knows some tooling that can help in the process of adjusting the header files I am all ears. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm: Split out drm_probe_helper.h
On Thu, Jan 17, 2019 at 05:45:41PM +0100, Daniel Vetter wrote: > On Wed, Jan 16, 2019 at 07:10:18PM +0100, Sam Ravnborg wrote: > > Hi Daniel. > > > > > v5: Actually try to sort them, and while at it, sort all the ones I > > > touch. > > > > Applied this variant on top of drm-misc and did a build test. > > Looked good for ia64, x86 and alpha. > > > > Took a closer look at the changes to atmel_hlcd - and they looked OK. > > > > But I noticed that atmel_hlcdc uses only drm_kms_helper_poll_init() and > > drm_kms_helper_poll_fini(). > > But there are no hits on DRM_CONNECTOR_POLL - so I think we maybe > > have a driver here where we have plugged the drm_poll infrastructure, > > but it is not in use. > > > > > include/drm/drm_crtc_helper.h | 16 --- > > > > The list of include files in this file could be dropped and replaced by: > > struct drm_connector; > > struct drm_device; > > struct drm_display_mode; > > struct drm_encoder; > > struct drm_framebuffer; > > struct drm_mode_set; > > struct drm_modeset_acquire_ctx; > > > > I tried to do so on top of your patch. > > But there were too many build errros and I somehow lost the motivation. > > Yeah the drm_crtc_helper.h header is a bit the miniature drmP.h for legacy > kms drivers. Just removing it from all the atomic drivers caused lots of > fallout, I expect even more if you entirely remove the includes it has. > Maybe a todo, care to pls create that patch since it's your idea? The main reason I bailed out initially was that this would create small changes to several otherwise seldomly touched files. And then we would later come and remove drmP.h - so lots of small but incremental changes to the same otherwise seldomly edited files. And the job was only partially done. I will try to experiment with an approach where I clean up the include/drm/*.h files a little (like suggested above, +delete drmP.h and maybe a bit more). Then to try on a driver by driver basis to make it build with a cleaned set of include files. I hope that the cleaned up driver can still build without the cleaned header files so the changes can be submitted piecemal. Will do so with an eye on the lesser maintained drivers to try it out to avoid creating too much chrunch for others. And if it works out I expect the active drivers to follow the example. todo.rst item will wait until I run out of energy. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm: Split out drm_probe_helper.h
Hi Daniel. > v5: Actually try to sort them, and while at it, sort all the ones I > touch. Applied this variant on top of drm-misc and did a build test. Looked good for ia64, x86 and alpha. Took a closer look at the changes to atmel_hlcd - and they looked OK. But I noticed that atmel_hlcdc uses only drm_kms_helper_poll_init() and drm_kms_helper_poll_fini(). But there are no hits on DRM_CONNECTOR_POLL - so I think we maybe have a driver here where we have plugged the drm_poll infrastructure, but it is not in use. > include/drm/drm_crtc_helper.h | 16 --- The list of include files in this file could be dropped and replaced by: struct drm_connector; struct drm_device; struct drm_display_mode; struct drm_encoder; struct drm_framebuffer; struct drm_mode_set; struct drm_modeset_acquire_ctx; I tried to do so on top of your patch. But there were too many build errros and I somehow lost the motivation. > include/drm/drm_probe_helper.h| 27 +++ This on the other hand is fine - as expected as this is a new file. But the above is just some random comments so: Acked-by: Sam Ravnborg ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v6 1/2] sparc: fix a building error reported by kbuild
Hi Gonglei. On Thu, Dec 08, 2016 at 12:37:08PM +0800, Gonglei wrote: > >> arch/sparc/include/asm/topology_64.h:44:44: > error: implicit declaration of function 'cpu_data' > [-Werror=implicit-function-declaration] > > #define topology_physical_package_id(cpu) (cpu_data(cpu).proc_id) >^ > Let's include cpudata.h in topology_64.h. > > Cc: Sam Ravnborg <s...@ravnborg.org> > Cc: David S. Miller <da...@davemloft.net> > Cc: sparcli...@vger.kernel.org > Suggested-by: Sam Ravnborg <s...@ravnborg.org> > Signed-off-by: Gonglei <arei.gong...@huawei.com> Acked-by: Sam Ravnborg <s...@ravnborg.org> > --- > arch/sparc/include/asm/topology_64.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/sparc/include/asm/topology_64.h > b/arch/sparc/include/asm/topology_64.h > index 7b4898a..2255430 100644 > --- a/arch/sparc/include/asm/topology_64.h > +++ b/arch/sparc/include/asm/topology_64.h > @@ -4,6 +4,7 @@ > #ifdef CONFIG_NUMA > > #include > +#include Nitpick - if you are going to resend this patch, then please order the two includes in alphabetic order. For two includes this looks like bikeshedding, but when we add more having them in a defined arder prevents merge conflicts. And makes it readable too. We also sometimes order the includes with the longest lines topmost, and lines with the ame length are ordered alphabetically. But this is not seen so often. Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v5 1/1] crypto: add virtio-crypto driver
On Mon, Dec 05, 2016 at 03:12:52AM +, Gonglei (Arei) wrote: > I don't think the root cause of those warnings are introduced by > virtio-crypto driver. > > What's your opinion? Sam and David? Root cause here is that arch/sparc/include/asm/topology_64.h references cpu_data without including arch/sparc/include/asm/cpudata.h I think other architectures pull in the dependency from either smp.h or they have it topology.h. The easy fix would be to include cpudata.h in arch/sparc/include/asm/topology_64.h. And that should also be a correct fix. Could you include this in your patch-set and build test it? Sam ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [RFC PATCH v1 01/33] mm: introduce common help functions to deal with reserved/managed pages
On Tue, Mar 05, 2013 at 10:54:44PM +0800, Jiang Liu wrote:
Code to deal with reserved/managed pages are duplicated by many
architectures, so introduce common help functions to reduce duplicated
code. These common help functions will also be used to concentrate code
to modify totalram_pages and zone-managed_pages, which makes the code
much more clear.
Signed-off-by: Jiang Liu jiang@huawei.com
---
include/linux/mm.h | 37 +
mm/page_alloc.c| 20
2 files changed, 57 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 7acc9dc..881461c 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1295,6 +1295,43 @@ extern void free_area_init_node(int nid, unsigned long
* zones_size,
unsigned long zone_start_pfn, unsigned long *zholes_size);
extern void free_initmem(void);
+/* Help functions to deal with reserved/managed pages. */
+extern unsigned long free_reserved_area(unsigned long start, unsigned long
end,
+ int poison, char *s);
+
+static inline void adjust_managed_page_count(struct page *page, long count)
+{
+ totalram_pages += count;
+}
What is the purpose of the unused page argument?
+
+static inline void __free_reserved_page(struct page *page)
+{
+ ClearPageReserved(page);
+ init_page_count(page);
+ __free_page(page);
+}
This method is useful for architectures which implment HIGHMEM,
like 32 bit x86 and 32 bit sparc.
This calls for a name without underscores.
+
+static inline void free_reserved_page(struct page *page)
+{
+ __free_reserved_page(page);
+ adjust_managed_page_count(page, 1);
+}
+
+static inline void mark_page_reserved(struct page *page)
+{
+ SetPageReserved(page);
+ adjust_managed_page_count(page, -1);
+}
+
+static inline void free_initmem_default(int poison)
+{
Why request user to supply the poison argumet. If this is the default
implmentation then use the default poison value too (POISON_FREE_INITMEM)
+ extern char __init_begin[], __init_end[];
+
+ free_reserved_area(PAGE_ALIGN((unsigned long)__init_begin) ,
+((unsigned long)__init_end) PAGE_MASK,
+poison, unused kernel);
+}
Maybe it is just me how is not used to this area of the kernel.
But a few comments that describe what the purpose is of each
function would have helped me.
Sam
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
