Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux