[PATCH] platform: support non-pci platform devices

[Hans de Goede]

Hi,

On 06/16/2014 01:46 PM, Thierry Reding wrote:
> 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
> /usr/share/X11/xorg.conf.d.
> 
> Also see here:
> 
> 	http://lists.x.org/archives/xorg-devel/2014-February/040671.html
> 
> 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.

Ah right, I thought this was just a repost and thought I would review
it since no-one else has bothered with reviewing it so far. I was already
pleasantly surprised it was so small, since older versions were bigger
in my memory :)

I'm not sure which approach is better, Rob's approach certainly seems
simpler, and as long as the driver is named the same as the platform
device it will just work for new platform devices, including leaving
a hint in the log what driver the user should search for if he lacks
a driver.

Regards,

Hans