Laurent Pinchart wrote: > Hi Murali, > > On Tuesday 23 March 2010 18:52:44 Karicheri, Muralidharan wrote: >> Laurent, >> >>>> I'm not too sure to like the ti-media name. It will soon get quite >>>> crowded, and name collisions might occur (look at the linux-omap-camera >>>> tree and the ISP driver in there for instance). Isn't there an internal >>>> name to refer to both the DM6446 and AM3517 that could be used ? >>> [Hiremath, Vaibhav] Laurent, >>> >>> ti-media directory is top level directory where we are putting all TI >>> devices drivers. So having said that, we should worrying about what goes >>> inside this directory. >>> For me ISP is more generic, if you compare davinci and OMAP. >>> >>> Frankly, there are various naming convention we do have from device to >>> device, even if the IP's are being reused. For example, the internal name >>> for OMAP is ISP but Davinci refers it as a VPSS. >> Could you explain what name space issue you are referring to in >> linux-omap-camera since I am not quite familiar with that tree? > > The linux-omap-camera tree contains a driver for the OMAP3 ISP. Basically, > most source files start with the "isp" prefix and are stored in > drivers/media/video/isp/. > > ISP is quite a generic name, and other vendors will probably develop an ISP at > some point (if not already done), so there's already a potential name conflict > today. > > Using a dedicated directory in drivers/media/video for TI-specific cores is > definitely a good idea (assuming the same IP cores won't be used by other > vendors in the future). > > My concern is that, if we move the ISP driver in drivers/media/video/ti-media, > the directory will soon get quite crowded. If a new TI processor comes up with > a totally incompatible ISP, we will get a name conflict in > drivers/media/video/ti-media. I was thinking about either replacing the "isp" > prefix with "omap3isp" (or similar), or moving the driver to > drivers/media/video/ti-media/omap3isp, but that will impede code sharing code > between the Davinci and OMAP processor families. That's where my uncertainty > comes from. There are two separate points here. The first one is re-using a driver or some symbols. Whatever directory structure is used, this won't prevent to share the code. Just create the header files under include/media and be sure that the Kbuild system will properly handle the dependencies, with "depends on". > >> Myself and Vaibhav had discussed this in the past and ti-media is the >> generic name that we could agree on. On DM SoCs (DM6446, DM355, DM365) I >> expect ti-media to be the home for all vpfe and vpbe driver files. Since >> we had a case of common IP across OMAP and DMxxx SoCs, we want to place >> all OMAP and DMxxx video driver files in a common directory so that >> sharing the drivers across the SoCs will be easy. We could discuss and >> agree on another name if need be. Any suggestions? > > It's not the name ti-media that I don't agree on, it's just that this will > move the problem one step further in the directory hierarchy without actually > solving it :-) > > Is it guaranteed today that no TI processors with new generation video blocks > will reuse the names ISP, VPFE and VPBE ? The OMAP3 datasheet refers to VPFE > and VPBE, but luckily those blocks are further divided into subblocks, and the > driver doesn't refer to the VPFE and VPBE directly. I agree that a name like ti-media would be too generic. Also, if we take a look on how the drivers are currently organized, the trees aren't vendor-based, but chipset-design based. There are even some cases where there's just one or two C files that are directly stored under drivers/media/video (like tvp5150, for example). IMO, simpler drivers where just one or a couple of files are needed should be stored into drivers/media/video. Bigger drivers should be organized by family, and not by vendor. Otherwise, we would need to re-organize the tree to be coherent. One interesting example of the a per-family directory is cx25840. The same driver is used by several different chipsets. The driver supports a separate IC chip (cx25836, cx2584x), and two designs where the decoder logic is inside an IC chip with the bridge and other functional blocks (cx23885 and cx231xx). -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
