similar to: [PATCH 13/36] drm/nouveau: use bpp instead of cpp for drm_format_info

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

Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nv04_crtc.c | 37 +++++++++++++++++++++------------- 1 files changed, 23 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv04_crtc.c b/drivers/gpu/drm/nouveau/nv04_crtc.c index 2ab9f30..0a5cfc1 100644 --- a/drivers/gpu/drm/nouveau/nv04_crtc.c +++ b/drivers/gpu/drm/nouveau/nv04_crtc.c

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

All fields in struct nouveau_framebuffer appear to be obsolete. The data structure can be replaced by struct drm_framebuffer entirely. Patch 1 removes several unused fields from struct nouveau_framebuffer. Patch 2 moves the field vma to struct nouveau_fbdev. The information in vma is only relevant for fbdev emulation, and as such he field is only used there. Patch 3 removes nvbo from struct

The buffer object stored in nvbo is also available GEM object in obj[0] of struct drm_framebuffer. Therefore remove nvbo in favor obj[0] and replace all references accordingly. This may require an additional cast. With this change we can already replace nouveau_user_framebuffer_destroy() and nouveau_user_framebuffer_create_handle() with generic GEM helpers. Calls to nouveau_framebuffer_new()

Subject: [PATCH] drm/nv04: fix null pointer dereferences of native_mode nv_connector->native_mode is not set when no modes were found for the connector, so its existence can't be assumed. In nv04_dfp_mode_fixup, reject the mode if GPU scaling is enabled but native mode is not known. In nv04_dfp_mode_set, use clock value from nv_encoder->mode instead of nv_connector->native_mode. If

These are dead code since 3.10. If there is no plan to use it further, these can be removed forever. Signed-off-by: Souptick Joarder <jrdr.linux at gmail.com> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 28 ---------------------------- 1 file changed, 28 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c index 1f08de4..ad0ef7d

Hi, all I'm trying to implement kms for pre-nv50 in last cuples of days. My current work[1] is based on the code of nv50 kms & ddx. Basicly, I just blindly port the code to kernel land :). I think I'm getting very close to working state, but it still doesn't work. Current state: 1) vbios parser is synced with ddx 2) i2c works 3) Something shows on internel LVDS panel and

The overlay logic can only do colorkey-based selection, not alpha-blending. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- This applies on top of the FP16 patch I sent earlier. drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 -- drivers/gpu/drm/nouveau/dispnv50/ovly827e.c | 3 --- drivers/gpu/drm/nouveau/dispnv50/ovly907e.c | 4 ---- drivers/gpu/drm/nouveau/dispnv50/ovly917e.c

This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode setting blobs. Corresponding modifications to Mesa/userspace are available on the Mesa-dev mailing list as the series: nouveau: Improved format modifier support I've tested this on Tesla, Kepler, Pascal, and Turing-class hardware using various formats

Hi! I've written a small amount of code that gets the randr 1.2 branch much closer to working for me on a laptop. Most of the changes are fairly obvious, but a couple of comments: 1) The changes to nv_crtc.c are clearly bogus, but I'm not sure what on earth these registers do. I need to set them to get a moderately sane-looking picture 2) The fp registers poked in nv_output.c

This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode setting blobs. Corresponding modifications to Mesa/userspace are available on the Mesa-dev gitlab merge request 3724: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3724 I've tested this on Tesla, Kepler, Pascal, and Turing-class hardware using

This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode setting blobs. Corresponding modifications to Mesa/userspace are available on the Mesa-dev gitlab merge request 3724: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3724 I've tested this on Tesla, Kepler, Pascal, and Turing-class hardware using

This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode setting blobs. Corresponding modifications to Mesa/userspace are available here: https://gitlab.freedesktop.org/cubanismo/mesa/tree/nouveau_work But those need a bit of cleanup before they're ready to submit. I've tested this on Tesla, Kepler, Pascal,

It seems it was only locking up in the context of nouveau_hw_save_vga_fonts, when it actually did something (because the console wasn't already in graphics mode). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_hw.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_hw.c

On 1/5/20 5:30 PM, Ben Skeggs wrote: > On Tue, 17 Dec 2019 at 10:44, James Jones <jajones at nvidia.com> wrote: >> >> This series modifies the NV5x+ nouveau display backends to advertise >> appropriate format modifiers on their display planes in atomic mode >> setting blobs. >> >> Corresponding modifications to Mesa/userspace are available here:

This patch series adds TV-out modesetting support to the KMS implementation. I've tried to test it on all the hardware I've got at hand (that is nv11, nv17, nv34, nv35, nv40, nv4b) with every possible output combination; I believe it has reached a mergeable state, however it depends on some commits from drm-next that haven't got into Linus' tree yet, if you agree to merge this

Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me,

Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me,