similar to: [PATCH] drm/nouveau/dma: use rb_entry()

To make the code clearer, use rb_entry() instead of container_of() to deal with rbtree. Signed-off-by: Geliang Tang <geliangtang at gmail.com> --- drivers/gpu/drm/nouveau/nvkm/core/client.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/core/client.c b/drivers/gpu/drm/nouveau/nvkm/core/client.c index e194391..ab2ee14 100644 ---

CHK kernel/config_data.h CC [M] drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.o drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.c: In function ‘nvd0_dmaobj_bind’: drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.c:54:8: error: ‘GM204_DISP_CORE_CHANNEL_DMA’ undeclared (first use in this function) case GM204_DISP_CORE_CHANNEL_DMA: ^

Hi Michael, here are two virtio/s390 patches (one cleanup, one bugfix), prepared against your vhost branch of mst/vhost.git. Please apply. Cornelia Huck (1): virtio/s390: size of SET_IND payload Geliang Tang (1): virtio/s390: use dev_to_virtio drivers/s390/virtio/virtio_ccw.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) -- 2.3.9

Hi Michael, here are two virtio/s390 patches (one cleanup, one bugfix), prepared against your vhost branch of mst/vhost.git. Please apply. Cornelia Huck (1): virtio/s390: size of SET_IND payload Geliang Tang (1): virtio/s390: use dev_to_virtio drivers/s390/virtio/virtio_ccw.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) -- 2.3.9

On Mon, 2014-12-22 at 14:37 +0100, Paul Bolle wrote: > On Mon, 2014-12-22 at 13:01 +0000, Sid Boyce wrote: > > CHK kernel/config_data.h > > CC [M] drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.o > > drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.c: In function > > ‘nvd0_dmaobj_bind’: > > drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.c:54:8: error:

Use dev_to_virtio() instead of open-coding it. Signed-off-by: Geliang Tang <geliangtang at 163.com> --- drivers/s390/virtio/virtio_ccw.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index 1b83159..97231e1 100644 --- a/drivers/s390/virtio/virtio_ccw.c +++ b/drivers/s390/virtio/virtio_ccw.c @@ -945,8

Use dev_to_virtio() instead of open-coding it. Signed-off-by: Geliang Tang <geliangtang at 163.com> --- drivers/s390/virtio/virtio_ccw.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index 1b83159..97231e1 100644 --- a/drivers/s390/virtio/virtio_ccw.c +++ b/drivers/s390/virtio/virtio_ccw.c @@ -945,8

So... I was wondering what the impact of splitting up the card compilation by e.g. generation would be. Depending on the split things would get fairly intertwined, so I thought I'd start small. This just splits NVC0 from everything else. I figure that for the people this matters the most to, NVC0 is the least relevant card -- people with sub-1GB of RAM, older hardware. With my config options

Hi Sid, On Mon, 2014-12-22 at 13:01 +0000, Sid Boyce wrote: > CHK kernel/config_data.h > CC [M] drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.o > drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.c: In function > ‘nvd0_dmaobj_bind’: > drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.c:54:8: error: > ‘GM204_DISP_CORE_CHANNEL_DMA’ undeclared (first use in this

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch aims to suppress 29 missing-break-in-switch false positives. Addresses-Coverity-ID: 1456891 ("Missing break in switch") Addresses-Coverity-ID: 1324063 ("Missing break in switch") Addresses-Coverity-ID: 1324063 ("Missing break in switch")

On 22/12/14 13:54, Paul Bolle wrote: > On Mon, 2014-12-22 at 14:37 +0100, Paul Bolle wrote: >> On Mon, 2014-12-22 at 13:01 +0000, Sid Boyce wrote: >>> CHK kernel/config_data.h >>> CC [M] drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.o >>> drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.c: In function >>> ‘nvd0_dmaobj_bind’:

> On Tue, Apr 01, 2014 at 02:53:02PM -0400, Ilia Mirkin wrote: >I believe that ch7006 is the only external encoder that's supposed to >work, so you're in luck. It sounds like it passes the nv04_tv_identify >stage of nv04_tv_create -- perhaps it fails later? Although based on >the prints, it's even doing dpms stuff (but it hits _detect a second >time... odd). Try

After analyzing verbose nouveau & drm dmesg, I have found seemingly no more useful details pertaining to having no TV-1 device. The TV-1 device might be getting lost within DRM, by setting the TV-1 (SVIDEO, Composite) device into DPMS mode or Full Power Down mode, and the ch7006 datasheet does say in this mode, all but the i2c circuits are disabled! Looking at

From: Geliang Tang <geliangtang at 163.com> Use dev_to_virtio() instead of open-coding it. Signed-off-by: Geliang Tang <geliangtang at 163.com> Message-Id: <912bf59bd3a48f2d4d4994681e898dc084fe29d3.1451484163.git.geliangtang at 163.com> Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- drivers/s390/virtio/virtio_ccw.c | 3 +-- 1 file changed, 1 insertion(+),

In https://nouveau.freedesktop.org/KernelModuleParameters.html, there is: Here is a list of engines: DEVICE DMAOBJ PBSP PCE0 PCE1 PCE2 PCRYPT PDISP PFIFO PGRAPH PMPEG PPM PPPP PVP SW Also, in debug: CLIENT I have tried to find a description of those. https://envytools.readthedocs.io/en/latest/ help a bit, but I don't find a

On Mon, 4 Dec 2023 at 05:04, Paul Dufresne <dufresnep at zoho.com> wrote: > > In https://nouveau.freedesktop.org/KernelModuleParameters.html, there is: > Here is a list of engines: > DEVICE > DMAOBJ > PBSP > PCE0 > PCE1 > PCE2 > PCRYPT > PDISP > PFIFO > PGRAPH > PMPEG > PPM > PPPP > PVP

Hello there, drivers/gpu/drm/nouveau/nvkm/engine/dma/usernv04.c:124:18: warning: this statement may fall through [-Wimplicit-fallthrough=] Source code is switch (dmaobj->base.access) { case NV_MEM_ACCESS_RO: dmaobj->flags0 |= 0x00004000; break; case NV_MEM_ACCESS_WO: dmaobj->flags0 |= 0x00008000; case NV_MEM_ACCESS_RW: dmaobj->flags2

On Fri, Feb 14, 2014 at 7:38 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > So... I was wondering what the impact of splitting up the card compilation by > e.g. generation would be. Depending on the split things would get fairly > intertwined, so I thought I'd start small. This just splits NVC0 from > everything else. I figure that for the people this matters the most to,

Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org> ---

This will allow the nouveau module to only include support for nv04-nv50, nv50-nvc0, nvc0+ cards individually (or in any combination). Only compiling one of the card types at a time reduces the size of the nouveau module, from 1.3M to 700-800K, depending on the type (including symbols/etc). It should also yield a reduction in compile time as a lot fewer files are compiled. Here are the sizes