similar to: [PATCH] drm/nouveau/kms/nv50-: remove overlay alpha formats

This was all kicked off by me figuring out how the PPC byteswap thing worked. In the end, we're keeping the implicit byteswap based on architecture, but also expose the correctly supported formats, and fix some overlay details. Overlay framebuffers have various funky requirements that should be enforced at framebuffer creation time (these are set apart by their YUV formats). Further, I

cpp[BytePerPlane] can't describe the 10bit data format correctly, So we use bpp[BitPerPlane] to instead cpp. Signed-off-by: Sandy Huang <hjc at rock-chips.com> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 ++++--- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 4 ++-- drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git

On Mon, Sep 23, 2019 at 8:56 AM Sandy Huang <hjc at rock-chips.com> wrote: > > cpp[BytePerPlane] can't describe the 10bit data format correctly, > So we use bpp[BitPerPlane] to instead cpp. > > Signed-off-by: Sandy Huang <hjc at rock-chips.com> > --- > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 ++++--- > drivers/gpu/drm/nouveau/dispnv50/base507c.c | 4

This came out of some debugging I was doing to figure out how BE mode works on this hardware. Among other things, it came out that we're not exposing 16-bpp mode support and that the ARGB8888 mode that we do expose is broken. Also the overlay logic was pretty broken, I must have only tested with very "normal" overlay buffer sizes with modetest before. That said, this code has only

This came out of some debugging I was doing to figure out how BE mode works on this hardware. Among other things, it came out that we're not exposing 16-bpp mode support and that the ARGB8888 mode that we do expose is broken. Also the overlay logic was pretty broken, I must have only tested with very "normal" overlay buffer sizes with modetest before. That said, this code has only

Otherwise none of the format checks pass, since the width was still in 16.16 encoding. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- This must have been some sort of last-second cleanup I made and forgot to test, because with this code, there's no way it could ever have worked... drivers/gpu/drm/nouveau/dispnv04/overlay.c | 17 +++++++++-------- 1 file changed, 9

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- include/drm/drm_drv.h | 1 - include/drm/drm_mode_config.h | 1 + drivers/gpu/drm/drm_framebuffer.c | 4 ++-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h index 46a8009784..23b9678137 100644

The following patchset remove use of the deprecated drmP.h header file in the nouveau driver(s). As preparation a dependency on drm_os_linux.h is dropped. The list of include files are sorted and are in some cases divided up in blocks of linux/* drm/* etc. The removal is divided up in a few patches that was the logical steps to remove the use of drmP.h. Build tested with allmodconfig and

Hi folks, Currently, when the device is removed (or the driver is unbound) the nouveau_drm structure de-allocated. However, it's still accessible from and used by some DRM layer callbacks. For example, file handles can be closed after the device has been removed (physically or otherwise). This series converts the Nouveau device structure to be allocated and de-allocated with the

From: Ville Syrjälä <ville.syrjala at linux.intel.com> Replace the ad-hoc iturbt_709 property with the new standard COLOR_ENCODING property. Compiles, but not tested. Cc: Daniel Vetter <daniel at ffwll.ch> Cc: nouveau at lists.freedesktop.org Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Ilia Mirkin <imirkin at alum.mit.edu> Signed-off-by: Ville Syrjälä <ville.syrjala at

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- This has received light testing on NV18 and NV34 cards, using the modetest tool. Userspace support to use this for xv is not yet ready. I decided against creating a new "pvideo" engine -- that just seems way too heavy-handed compared to the ~10 lines of code in disp/nv04.c to deal with the PVIDEO interrupts. Even though

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 1e339ab2ac3c769c1b06b9fb7d532f8495ebc56d ] On Turing, an input LUT is required to transform inputs in fixed-point formats to FP16 for the internal display pipe. We provide an identity mapping whenever a window is enabled for this reason. HW has error checks to ensure when the input is already FP16, that the input LUT is also

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 1e339ab2ac3c769c1b06b9fb7d532f8495ebc56d ] On Turing, an input LUT is required to transform inputs in fixed-point formats to FP16 for the internal display pipe. We provide an identity mapping whenever a window is enabled for this reason. HW has error checks to ensure when the input is already FP16, that the input LUT is also

Add support for ABGR2101010, used by the nouveau driver. Signed-off-by: Jocelyn Falempe <jfalempe at redhat.com> --- drivers/gpu/drm/drm_panic.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c index 74412b7bf936..0a9ecc1380d2 100644 --- a/drivers/gpu/drm/drm_panic.c +++ b/drivers/gpu/drm/drm_panic.c @@ -209,6 +209,14

Jocelyn Falempe <jfalempe at redhat.com> writes: Hello Jocelyn, > Add support for ABGR2101010, used by the nouveau driver. > > Signed-off-by: Jocelyn Falempe <jfalempe at redhat.com> > --- > drivers/gpu/drm/drm_panic.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c > index

On 13/09/2024 09:22, Javier Martinez Canillas wrote: > Jocelyn Falempe <jfalempe at redhat.com> writes: > > Hello Jocelyn, > >> Add support for ABGR2101010, used by the nouveau driver. >> >> Signed-off-by: Jocelyn Falempe <jfalempe at redhat.com> >> --- >> drivers/gpu/drm/drm_panic.c | 10 ++++++++++ >> 1 file changed, 10