lwn.git/drivers/gpu/drm/mgag200/mgag200_drv.c, branch standardize-docs

drm/mgag200: Added support for the new device G200eH3

2017-01-23T01:57:08+00:00

- Added the new device ID - Added new pll algorithm Signed-off-by: Mathieu Larouche Signed-off-by: Dave Airlie

drm: define drm_compat_ioctl NULL on CONFIG_COMPAT=n and reduce #ifdefs

2016-11-02T15:33:47+00:00

If we define drm_compat_ioctl NULL on CONFIG_COMPAT=n, we don't have to check for the config everywhere. Reviewed-by: Patrik Jakobsson Signed-off-by: Jani Nikula Signed-off-by: Sean Paul Link: http://patchwork.freedesktop.org/patch/msgid/1478014844-27454-1-git-send-email-jani.nikula@intel.com

drm/fb-helper: Add a dummy remove_conflicting_framebuffers

2016-08-12T08:41:18+00:00

Lots of drivers don't properly compile without this when CONFIG_FB=n. It's kinda a hack, but since CONFIG_FB doesn't stub any fucntions when it's disabled I think it makes sense to add it to drm_fb_helper.h. Long term we probably need to rethink all the logic to unload firmware framebuffer drivers, at least if we want to be able to move away from CONFIG_FB and fbcon. v2: Unfortunately just stubbing out remove_conflicting_framebuffers in drm_fb_helper.h upset gcc about static vs. non-static declarations, so a new wrapper it needs to be. Means more churn :( Cc: Tobias Jakobi Cc: Noralf Trønnes Cc: tomi.valkeinen@ti.com Cc: dh.herrmann@gmail.com Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1470847958-28465-2-git-send-email-daniel.vetter@ffwll.ch

drm/mga200g: Use lockless gem BO free callback

2016-06-01T07:40:30+00:00

No dev->struct_mutex anywhere to be seen. Cc: Dave Airlie Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1464630800-30786-8-git-send-email-daniel.vetter@ffwll.ch

vgacon: dummy implementation for vgacon_text_force

2016-03-30T15:37:57+00:00

This allows us to ditch a ton of ugly #ifdefs from a bunch of drm modeset drivers. v2: Make the dummy function actually return a sane value, spotted by Ville. v3: Because the patch is still in limbo there's no more drivers to convert, noticed by Emil. v4: Rebase once more, because hooray. I'll just go ahead an apply this one later on to drm-misc. Cc: Emil Velikov Cc: Ville Syrjälä Cc: Andrew Morton Cc: Greg Kroah-Hartman Reviewed-by: Emil Velikov Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter

drm/mgag200: Add support for a new G200eW3 chipset

2015-08-24T03:46:52+00:00

- Added support for the new deviceID for G200eW3 - Added PLL algorithm for the G200eW3 - Added some initialization code for G200eW3 Signed-off-by: Mathieu Larouche Signed-off-by: Dave Airlie

drm: add driver->set_busid() callback

2014-09-10T07:43:04+00:00

One step closer to dropping all the drm_bus_* code: Add a driver->set_busid() callback and make all drivers use the generic helpers. Nouveau is the only driver that uses two different bus-types with the same drm_driver. This is totally broken if both buses are available on the same machine (unlikely, but lets be safe). Therefore, we create two different drivers for each platform during module_init() and set the set_busid() callback respectively. Signed-off-by: David Herrmann Reviewed-by: Thierry Reding Signed-off-by: Dave Airlie

PCI: Remove DEFINE_PCI_DEVICE_TABLE macro use

2014-08-12T18:15:14+00:00

We should prefer `struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines. This issue was reported by checkpatch. A simplified version of the semantic patch that makes this change is as follows (http://coccinelle.lip6.fr/): // @@ identifier i; declarer name DEFINE_PCI_DEVICE_TABLE; initializer z; @@ - DEFINE_PCI_DEVICE_TABLE(i) + const struct pci_device_id i[] = z; // [bhelgaas: add semantic patch] Signed-off-by: Benoit Taine Signed-off-by: Bjorn Helgaas

drm: kill ->gem_init_object() and friends

2013-10-09T04:38:02+00:00

All drivers embed gem-objects into their own buffer objects. There is no reason to keep drm_gem_object_alloc(), gem->driver_private and ->gem_init_object() anymore. New drivers are highly encouraged to do the same. There is no benefit in allocating gem-objects separately. Cc: Dave Airlie Cc: Alex Deucher Cc: Daniel Vetter Cc: Jerome Glisse Cc: Rob Clark Cc: Inki Dae Cc: Ben Skeggs Cc: Patrik Jakobsson Signed-off-by: David Herrmann Acked-by: Alex Deucher Signed-off-by: Dave Airlie

drm: rip out drm_core_has_MTRR checks

2013-08-19T04:11:44+00:00

The new arch_phys_wc_add/del functions do the right thing both with and without MTRR support in the kernel. So we can drop these additional checks. David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since it's now unused, which spurred me to do a bit a better audit of the affected drivers. David helped a lot in that. Quoting our mail discussion: On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann wrote: > On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter wrote: >> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann wrote: >>>> -#if __OS_HAS_MTRR >>>> -static inline int drm_core_has_MTRR(struct drm_device *dev) >>>> -{ >>>> - return drm_core_check_feature(dev, DRIVER_USE_MTRR); >>>> -} >>>> -#else >>>> -#define drm_core_has_MTRR(dev) (0) >>>> -#endif >>>> - >>> >>> That was the last user of DRIVER_USE_MTRR (apart from drivers setting >>> it in .driver_features). Any reason to keep it around? >> >> Yeah, I guess we could rip things out. Which will also force me to >> properly audit drivers for the eventual behaviour change this could >> entail (in case there's an x86 driver which did not ask for an mtrr, >> but iirc there isn't). > > david@david-mb ~/dev/kernel/linux $ for i in drivers/gpu/drm/* ; do if > test -d "$i" ; then if ! grep -q USE_MTRR -r $i ; then echo $i ; fi ; > fi ; done > drivers/gpu/drm/exynos > drivers/gpu/drm/gma500 > drivers/gpu/drm/i2c > drivers/gpu/drm/nouveau > drivers/gpu/drm/omapdrm > drivers/gpu/drm/qxl > drivers/gpu/drm/rcar-du > drivers/gpu/drm/shmobile > drivers/gpu/drm/tilcdc > drivers/gpu/drm/ttm > drivers/gpu/drm/udl > drivers/gpu/drm/vmwgfx > david@david-mb ~/dev/kernel/linux $ > > So for x86 gma500,nouveau,qxl,udl,vmwgfx don't set DRIVER_USE_MTRR. > But I cannot tell whether they break if we call arch_phys_wc_add/del, > anyway. At least nouveau seemed to work here, but it doesn't use AGP > or drm_bufs, I guess. Cool, thanks a lot for stitching together the list of drivers to look at. So for real KMS drivers it's the drives responsibility to add an mtrr if it needs one. nouvea, radeon, mgag200, i915 and vmwgfx do that already. Somehow the savage driver also ends up doing that, I have no idea why. Note that gma500 as a pure KMS driver doesn't need MTRR setup since the platforms that it supports all support PAT. So no MTRRs needed to get wc iomappings. The mtrr support in the drm core is all for legacy mappings of garts, framebuffers and registers. All legacy drivers set the USE_MTRR flag, so we're good there. All in all I think we can really just ditch this /endquote v2: Also kill DRIVER_USE_MTRR as suggested by David Herrmann v3: Rebase on top of David Herrmann's agp setup/cleanup changes. Cc: David Herrmann Cc: Andy Lutomirski Signed-off-by: Daniel Vetter Acked-by: Andy Lutomirski Reviewed-by: David Herrmann Signed-off-by: Dave Airlie