All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 11/19] drm: restrict the device list for shadow attached drivers
Date: Mon, 4 Nov 2013 10:20:42 +0100	[thread overview]
Message-ID: <20131104092041.GG27445@ulmo.nvidia.com> (raw)
In-Reply-To: <CAKMK7uHUPrip3NB+n6jxD4xkPeBnCYMWnhv7O2GKj7fr=Yxz+w@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1845 bytes --]

On Sun, Nov 03, 2013 at 03:14:16PM +0100, Daniel Vetter wrote:
> On Sun, Nov 3, 2013 at 3:05 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> > On Sun, Nov 3, 2013 at 2:31 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >> There's really no need for the drm core to keep a list of all
> >> devices of a given driver - the linux device model keeps perfect
> >> track of this already for us.
> >>
> >> The exception is old legacy ums drivers using pci shadow attaching.
> >> So rename the lists to make the use case clearer and rip out everything
> >> else.
> >>
> >> v2: Rebase on top of David Herrmann's drm device register changes.
> >> Also drop the bogus dev_set_drvdata for platform drivers that somehow
> >> crept into the original version - drivers really should be in full
> >> control of that field.
> >
> > You didn't really change any dev_set_drvdata, did you? And I guess you
> > mean pci_set_drvdata()? I had to keep it in place in drm_pci.c as it
> > has been there before my device-registration changes. However, with
> > your series you added the pci_set_drvdata() everywhere yourself, so
> > yes, please remove it.
> 
> That was a bogus hunk in v1 of this patch, which iirc I've never
> posted onto the list anywhere. I added a platfrom_set_drvdata call,
> but with the previous series to make sure that each driver has that
> it's a bit redundant.
> 
> Long term, when we split up the drm init code I think the drvdata
> assignment should be the driver's job.

I remember submitting a patch for that a while ago. It was applied about
a year ago, see commit a16d4f86019a ('drm: platform: Don't initialize
driver-private data'). The issue at the time was that I needed the
drvdata for other purposes and drm_platform_init() kept overwriting it,
which had me confused for days.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2013-11-04  9:20 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-03 13:31 [PATCH 00/19] drm de-midlayer, part 1: device list and agp bus stuff Daniel Vetter
2013-11-03 13:31 ` [PATCH 01/19] drm/rcar: call drm_put_dev directly in the ->remove hook Daniel Vetter
2013-11-03 13:47   ` Laurent Pinchart
2013-11-03 13:31 ` [PATCH 02/19] drm/exynos: call drm_put_dev directly from ->remove Daniel Vetter
2013-11-03 13:31 ` [PATCH 03/19] drm/imx: directly call drm_put_dev in ->remove Daniel Vetter
2013-11-04  8:19   ` Sascha Hauer
2013-11-03 13:31 ` [PATCH 04/19] drm/tilcdc: call drm_put_dev directly from ->remove Daniel Vetter
2013-11-03 13:31 ` [PATCH 05/19] drm/omap: call drm_put_dev directly in ->remove Daniel Vetter
2013-11-03 13:31 ` [PATCH 06/19] drm/shmob: call drm_put_dev directly from ->remove hook Daniel Vetter
2013-11-03 13:31 ` [PATCH 07/19] drm/host1x: Call drm_put_dev directly instead of drm_platform_exit Daniel Vetter
2013-11-04  9:10   ` Thierry Reding
2013-11-04  9:13     ` Thierry Reding
2013-11-04 10:14     ` Daniel Vetter
2013-11-04 10:51       ` Thierry Reding
2013-11-03 13:31 ` [PATCH 08/19] drm/armada: directly call drm_put_dev in ->remove Daniel Vetter
2013-11-03 13:31 ` [PATCH 09/19] drm/msm: call drm_put_dev directly " Daniel Vetter
2013-11-03 13:31 ` [PATCH 10/19] drm: rip out drm_platform_exit Daniel Vetter
2013-11-03 13:31 ` [PATCH 11/19] drm: restrict the device list for shadow attached drivers Daniel Vetter
2013-11-03 14:05   ` David Herrmann
2013-11-03 14:14     ` Daniel Vetter
2013-11-03 18:51       ` [PATCH] " Daniel Vetter
2013-11-04  9:20       ` Thierry Reding [this message]
2013-11-03 13:31 ` [PATCH 12/19] drm/bufs: remove handling of _DRM_GEM mappings Daniel Vetter
2013-11-03 14:06   ` David Herrmann
2013-11-03 13:31 ` [PATCH 13/19] drm: kill DRIVER_REQUIRE_AGP Daniel Vetter
2013-11-03 13:31 ` [PATCH 14/19] drm: ->agp_init can't fail Daniel Vetter
2013-11-03 14:12   ` David Herrmann
2013-11-03 13:31 ` [PATCH 15/19] drm: rip out drm_core_has_AGP Daniel Vetter
2013-11-03 13:31 ` [PATCH 16/19] drm: remove agp_init() bus callback Daniel Vetter
2013-11-03 14:14   ` David Herrmann
2013-11-03 14:20     ` Daniel Vetter
2013-11-03 14:42       ` [PATCH] " Daniel Vetter
2013-11-03 13:31 ` [PATCH 17/19] drm: inline drm_agp_destroy Daniel Vetter
2013-11-03 13:43   ` David Herrmann
2013-11-03 14:36     ` Daniel Vetter
2013-11-03 13:31 ` [PATCH 18/19] drm: kill the ->agp_destroy callback Daniel Vetter
2013-11-03 13:49   ` David Herrmann
2013-11-03 14:24     ` [PATCH] " Daniel Vetter
2013-11-03 14:34       ` David Herrmann
2013-11-03 17:32         ` Daniel Vetter
2013-11-03 13:31 ` [PATCH 19/19] drm: remove global_mutex locking around agp_init Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131104092041.GG27445@ulmo.nvidia.com \
    --to=thierry.reding@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.