similar to: [PATCH 0/3] Add separate non-KMS state; constify struct drm_driver

On Tue, Feb 25, 2020 at 10:59 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Non-KMS drivers store state in struct drm_driver. This bloats the > structure for KMS drivers and prevents it from being declared with > 'static const' qualifiers. Moving the non-KMS state into a separate > data structure resolves this. > > Signed-off-by: Thomas Zimmermann

Hi Am 25.02.20 um 18:44 schrieb Daniel Vetter: > On Tue, Feb 25, 2020 at 04:58:59PM +0100, Thomas Zimmermann wrote: >> This patchset moves legacy, non-KMS driver state from struct drm_driver >> into struct drm_legacy_state. Only non-KMS drivers provide an instance >> of the latter structure. One special case is nouveau, which supports >> legacy interfaces. It also

All non-kms driver fields are now located in struct drm_legacy_state. A driver-wide instance is available via struct drm_driver.legacy. The call sites test if the driver is marked with DRIVER_LEGACY before accessing the fields. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/drm_bufs.c | 10 +++++----- drivers/gpu/drm/drm_context.c | 9

Non-KMS drivers store state in struct drm_driver. This bloats the structure for KMS drivers and prevents it from being declared with 'static const' qualifiers. Moving the non-KMS state into a separate data structure resolves this. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/drm_drv.c | 4 ++++ drivers/gpu/drm/i810/i810_drv.c | 4

On Tue, Feb 25, 2020 at 04:58:59PM +0100, Thomas Zimmermann wrote: > This patchset moves legacy, non-KMS driver state from struct drm_driver > into struct drm_legacy_state. Only non-KMS drivers provide an instance > of the latter structure. One special case is nouveau, which supports > legacy interfaces. It also provides an instance of the legacy state if > the legacy interfaces

Nouveau, in normal circumstances, does not need device lock for every ioctl, but incoming "gpu reset" code needs exclusive access to the device. This commit adds drm_driver flag which turns on read lock ioctl encapsulation. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/drm_drv.c | 6 ++++++ drivers/gpu/drm/drm_stub.c | 2 ++

Hi everyone, Using ARRAY_SIZE improves the code readability. I used coccinelle (I made a change to the array_size.cocci file [1]) to find several places where ARRAY_SIZE could be used instead of other macros or sizeof division. I tried to divide the changes into a patch per subsystem (excepted for staging). If one of the patch should be split into several patches, let me know. In order to reduce

On Tue, Nov 06, 2018 at 06:41:22PM +0200, Ville Syrjälä wrote: > On Tue, Nov 06, 2018 at 05:24:15PM +0100, Thierry Reding wrote: > > From: Thierry Reding <treding at nvidia.com> > > > > Irrespective of whether or not the device has any usable outputs, the > > modesetting helpers will try to register all the resources such as CRTCs > > and planes.

On Fri, Jan 10, 2020 at 10:21:27AM +0100, Thomas Zimmermann wrote: > All non-legacy users of VBLANK functions in struct drm_driver have been > converted to use the respective interfaces in struct drm_crtc_funcs. The > remaining users of VBLANK callbacks in struct drm_driver are legacy drivers > with userspace modesetting. > > There are no users left of get_vblank_timestamp(), so

These 4 patches fix two issues that existed on Tegra regarding DMA: 1) The bit indicating whether to use an IOMMU or not was hardcoded ; make this a platform property and use it in instmem 2) The DMA mask was not set for platform devices. Fix this by converting more pci_dma* to the DMA API, and use that more generic code to set the DMA mask properly for all platforms. Tested on both x86

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

From: Thierry Reding <treding at nvidia.com> struct device is forward-declared twice. Remove the second instance. Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk> Signed-off-by: Thierry Reding <treding at nvidia.com> --- include/drm/drm_prime.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h index

K I finally got HL to start correctly by not using my installed win98 as base. Now when I try to join a game in Counterstrike I get an "selected opengl mode not supported by your hardware" error from HL. This is only the case when I select the 3DfxMiniGL Driver (as I got a voodoo3). With Default opengl driver it works, but i get 4 fps. With Softwaremode I get 15fps but thats both

I'm using wine 20010326 to play Half Life. Works fine in software graphics mode, but not quite fast enough to be playable. In OpenGL mode, it runs at about 5 fps, and I get no textures. I have a Voodoo 3 3000 AGP. OpenGL works fine in native Linux (I get about 120 fps in the 'gears' program). Does anyone have any suggestions as to what I can do to get to the bottom of this? -- Steve

I have and new motherboard and trying to get X going. it starts at 800x600 and vesa driver... I have tried via (I get not driver found) I have tried S3 I have tried savage None of these work. I tried them all as I was getting conflicting information on the net about which driver it is. below is lspci -v Any suggestions on what to try? THanks, jerry 01:00.0 VGA compatible controller: VIA

Hi [..snip..] > Finally, support for probing GK20A is added in the last 2 patches. It should be > noted that contrary to what Nouveau currently expects, GK20A does not embed any > display hardware (that part being handled by tegradrm). So this driver should > really be only used through DRM render-nodes and collaborate with the display > driver using PRIME. I have not yet figured

Greetings, I'm a Fedora user likely going to switch to CentOS in the next few days. I'm wondering if anyone has some heads up advice for me? I am very familiar with FC6 and before so I anticipate few problems I haven't already seen (and know were fixed). The main reason for the move is so I don't have to re-install so frequently and hopefully not have to deal with so many

All non-legacy users of VBLANK functions in struct drm_driver have been converted to use the respective interfaces in struct drm_crtc_funcs. The remaining users of VBLANK callbacks in struct drm_driver are legacy drivers with userspace modesetting. There are no users left of get_vblank_timestamp(), so the callback is being removed. The other VBLANK callbacks are being moved to the legacy section

Using the ARRAY_SIZE macro improves the readability of the code. Also, it is not always useful to use a variable to store this constant calculated at compile time nor to re-invent the ARRAY_SIZE macro. Found with Coccinelle with the following semantic patch: @r depends on (org || report)@ type T; T[] E; position p; @@ ( (sizeof(E)@p /sizeof(*E)) | (sizeof(E)@p /sizeof(E[...])) | (sizeof(E)@p