RE: [RFC][DRAFT] TODO list for TI DSP BRIDGE

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

 



Hi Hiroshi,

> -----Original Message-----
> From: Hiroshi DOYU [mailto:Hiroshi.DOYU@xxxxxxxxx]

<snip>

> I think that, in this virtual clock, frequency changing will be done
> in the totally different path(just in a normal clock tree). This
> virtual clock resides in an independent clock tree and supposed to be
> used aggressively just to turn on/off clocks(enable/disable), which
> drivers use, for saving power consumption. So the relationship between
> "clk" and "vclk" may be similar to "struct device" and "struct class"
> in the linux driver-model, which means that, the former is based on
> H/W connection and the latter is based on functionality. Of course
> there is a possibility that other clk methods can be overwritten, but
> it's has to be used for different purpose than a normal clock does,
> not to break the H/W clock tree consistency.

Ok. I 'think' I better understand your idea.  Thanks for the description.

To me it seems like it could be slightly confusing to maintain 2 clock structures.  One for v and one for p.  In the end it is probably not very hard to lean.

It would reduce some amount of code in the more complex subsystems/drivers resulting in a cleaner driver.

The interface used in drivers with the clock frame work is pretty simple so it might seem more about clean up then reducing complexity in the driver.

Do you feel a lot of drivers will benefit or it will expand to auto handle resources better?  If it is just 1 or 2 drivers then it might be the new code in clock framework and platform will add some complexity which is higher than what was removed from the driver.  If lots of drivers use it then it would be positive.

<snip>

> Probably original "virt_prcm_set" might have a wider solution,
> though....

No not really.  It just provided a way to group dependent clocks.  These clocks were so tightly coupled it was better to treat them as one.

It does have some nice properties for OMAP2 which can be exploited.  For instance the underlying pclock speeds in a vclock set are fixed by ratio.  So doing a clock set on the vclock will allow switching between one of the supported ratio sets.  Doing a clock set on the pclock(dpll) will allow you to change the base speed which the ratio is applied.

Regards,
Richard W.

--
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