On Fri, Jan 13, 2012 at 9:53 PM, Rob Clark <rob@xxxxxx> wrote: > On Fri, Jan 13, 2012 at 1:49 PM, Felipe Contreras > <felipe.contreras@xxxxxxxxx> wrote: >> On Fri, Jan 13, 2012 at 9:46 PM, Rob Clark <rob@xxxxxx> wrote: >>> On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark <rob.clark@xxxxxxxxxx> wrote: >>>> +/* files from staging that contain platform data structure definitions */ >>>> +#include "../../../drivers/staging/omapdrm/omap_priv.h" >>>> +#include "../../../drivers/staging/omapdrm/omap_dmm_tiler.h" >>> >>> btw, I'm not a huge fan of doing #includes this way, so if someone has >>> a better suggestion (given that staging drivers should not have >>> headers outside of drivers/staging) please let me know >> >> Move those structs to /arch/arm/plat-omap/drm.h? > > Can I do that? Maybe it depends of if you consider those structs as > part of the driver, or part of the platform? Why not? The platform is using them in arch/arm/plat-omap/drm.c. > I guess that looks like how it was handled for dspbridge, so maybe > that means it is a suitable precedent.. Indeed, the way I see it is this: imagine there's another driver in staging (or maybe even out of tree), that requires this data. It would simply include plat-omap/drm.h to fill this. OK, this is pretty far-fetched, but demonstrates the point: platform data should be completely independent of the drivers. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
