> > 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. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
