On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark <rob.clark@xxxxxxxxxx> wrote: >> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras >> <felipe.contreras@xxxxxxxxx> wrote: >>> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark <rob.clark@xxxxxxxxxx> wrote: >>>> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile >>>> index 9a58461..b86e6cb 100644 >>>> --- a/arch/arm/plat-omap/Makefile >>>> +++ b/arch/arm/plat-omap/Makefile >>>> @@ -4,7 +4,7 @@ >>>> >>>> # Common support >>>> obj-y := common.o sram.o clock.o devices.o dma.o mux.o \ >>>> - usb.o fb.o counter_32k.o >>>> + usb.o fb.o counter_32k.o drm.o >>> >>> Should be something like this: >>> obj-$(CONFIG_DRM_OMAP) += drm.o >> >> btw, how does that work if CONFIG_DRM_OMAP=m? Do you end up w/ a >> plat-omap module? > > Yes, and platform drivers are supposed to be loaded automatically at > boot-time by udev (or similar). oh, but this won't work, because common.c has to call omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock() works).. so I think it has to stay the way it is in this patch. I guess this is the reason that omapfb (fb.c is the example I copied) device is setup in the same way. BR, -R > -- > Felipe Contreras > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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
