Hi Tomi, On Fri, Jul 1, 2011 at 5:14 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > On Fri, 2011-07-01 at 14:52 +0530, K, Mythri P wrote: > >> > I don't see a need for a separate file right now. We have the >> > hdmi_ti_4xxx_ip.c file which contains code for the HDMI block as a >> > whole, and could well contain the code that implements the API. >> > >> if the hdmi_ti_4xxx_ip.c is handling the configuration then how are >> we going to handle a scenario where netra uses a different PHY block , > > I wasn't aware that Netra has different HDMI blocks. I understood it's > the same as on OMAP4. > > So they have a different PHY driver, but want to use PLL and core parts > of OMAP4 HDMI driver? > That was precisely what i was trying to explain for last few threads :-). >> you suggest to have a #if in the programming sequence within >> hdmi_ti_4xxx_ip.c function ? > > No, we can't use #ifdefs as the same kernel has to work for both SoCs. > >> Also in future OMAP's when are using the PHY and PLL block from >> hdmi_ti_4xxx_ip.c , but a different core/video block from >> hdmi_ti_5xxx_ip.c then how would hdmi_ti_5xxx_ip.c hdmi_enable be >> able to call the PHY and PLL configuration functions from >> hdmi_ti_4xxx_ip.c ?? > > If the different HDMI blocks will be mixed like that, then we need to > split the blocks to separate files. Otherwise it will get strange if > OMAP5 HDMI code is calling PLL functions from OMAP4 HDMI code. > > And on top of those drivers/libs we would have a higher level driver/lib > for the whole HDMI entity, and this higher level driver would implement > the API being discussed. It would then use the lower level drivers/libs, > and be used by OMAP/Netra DSS. > Splitting that to multiple would be a file overhead , ie creating a file to just host 2/3 functions. Also note it is not OMAP5 HDMI code calling OMAP4 HDMI code , It it no way in relation to OMAP's as such , so these IP drivers be provisioning for API's , which the intermediate Arbitration lib / file which can provide the clean handle to user and can handle the sequence as to what IP functions should be called. > Tomi > > > -- Thanks and regards, Mythri. -- 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