On Fri, Jan 13, 2012 at 2:23 PM, Felipe Contreras <felipe.contre...@gmail.com> wrote: > On Fri, Jan 13, 2012 at 9:53 PM, Rob Clark <r...@ti.com> wrote: >> On Fri, Jan 13, 2012 at 1:49 PM, Felipe Contreras >> <felipe.contre...@gmail.com> wrote: >>> On Fri, Jan 13, 2012 at 9:46 PM, Rob Clark <r...@ti.com> wrote: >>>> On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark <rob.cl...@linaro.org> 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.
yeah, makes sense.. I'm about to send v2 of this patch. BR, -R > Cheers. > > -- > Felipe Contreras > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
