[PATCH] platform: support non-pci platform devices

Thierry Reding thierry.reding at gmail.com
Mon Jun 16 04:46:46 PDT 2014

On Sat, Jun 14, 2014 at 03:58:53PM -0400, Rob Clark wrote:
> This makes things not completely fail if DDX implements platformProbe()
> but the device is not actually a PCI device.  Also, the platform device
> name does not always match the DDX name, so deal with that.  I'm sure
> there are more cases that find_non_pci_driver() needs to handle for
> that, but this is a start.
> Signed-off-by: Rob Clark <robdclark at gmail.com>
> ---
> NOTE: I still need to figure out a sane way to workaround the existing
> bug with non-pci platform devices.  Currently, if DDX implements the
> platformProbe() hook, then in xf86platformProbeDev() it will get claimed
> in the autoAddGPU loop, resulting that the old-school Probe() fallback
> (if you have .conf file) fails too because the device is already claimed.
> We kind of need a way that the DDX can detect that the xserver does not
> have this fix, so that it can work around the bug by failing
> platformProbe().
>  hw/xfree86/common/xf86platformBus.c | 65 ++++++++++++++++++++++++++++++++++---
>  1 file changed, 61 insertions(+), 4 deletions(-)

What ever happened to the series I sent a while ago to make this kind of
setup work with an xorg.conf snippet? The idea at the time was to add an
OutputClass section that allows matching by kernel driver, so that a DDX
module could simply provide a corresponding xorg.conf snippet in

Also see here:


I did originally propose something like you did, but that was shot down
by Dave (I think). Generally the OutputClass series seemed like an
accepted approach (and had potential users even for PCI devices). Keith
said on IRC that he had some comments but never got around to posting
them it seems.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140616/944fe584/attachment.sig>

More information about the xorg-devel mailing list