Re: [PATCH] drm: Allow platform devices to register as DRM devices

[Dave Airlie]

>
> I guess technically we could also drop the AGP requirement, but since it
> worked
> on my box with AGP=n it seemed to me like a NOP.

Its not a NOP, otherwise we'd remove it, AGP || AGP=n means if
AGP is enabled DRM must be enabled similiarly, it stops AGP=m + DRM=y
basically.

>>>  EXPORT_SYMBOL(drm_init);
>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> index ab6c973..48a14a0 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -1220,6 +1220,9 @@ struct edid *drm_get_edid(struct drm_connector
>>> *connector,
>>>       int ret;
>>>       struct edid *edid;
>>>
>>> +       if (drm_core_check_feature(connector->dev,
>>> DRIVER_USE_PLATFORM_DEVICE))
>>> +               return NULL;
>>> +
>>
>>
>> This makes no sense, having the ability to probe EDID or not is most
>> definitely not a platform vs PCI problem.
>
> Yeah, that was my poor man's "Don't probe EDID" hack.  I'm not sure if there
> is a smart way to implicitly check to see if EDID should be probed, but I'm
> worried about abusing the features flag too badly, though if a
> DRIVER_USE_EDID
> is needed then we shouldn't be shy about using it.

The generic code never calls this only the driver, so there should be no
need for flags at all.

>> Not 100% sure about this, but if you only intend on KMS and don't need to
>> inform userspace of irq support this should be okay.
>
> Again, a "don't do this" hack.  I'll look at this more carefully and see if
> there
> is a good way to evaluate this based on the hooks that the platform has
> defined.

Its mostly used in UMS to inform userspace for some strange reason
its pretty legacy at this point, new driver should probably not hit it.

>>> @@ -60,7 +60,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct

>>
>> This also doesn't address noueau/vmwgfx entry points.
>
> Yep, thats my bad.  I'll refresh and push better patches without whitespace
> stupidity.

Thanks,
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/