Re: RE: RE: [PATCH v4 12/12] video: da8xx-fb: CCF clock divider handling

[Mike Turquette <mturquette@linaro.org>]

Quoting Mohammed, Afzal (2013-01-25 04:05:44)
> Hi Mike,
> 
> On Thu, Jan 24, 2013 at 22:30:44, Mike Turquette wrote:
> > Quoting Mohammed, Afzal (2013-01-24 03:36:02)
> 
> > > So there are 3 - LIDD is actually not for present use case, CORE could
> > > be clubbed with the divider to have a composite clock. And CORE is
> > > in functional clock path and logically it's perfectly alright to have
> > > the composite clock.
> 
> > Some of the clock names are a bit generic, so a question that I'm going
> > to repeat throughout my response: "is this clock only inside of your
> > video IP ?"
> 
> Yes these three clocks are inside LCDC IP.
> 
> > Regarding the CORE clock, is this only inside of your IP or are you
> > referring to the SoC CORE clock which is driven by a DPLL and clocks
> > DDR and many other peripherals (often MMC, UART, etc)?
> 
> Sorry for the confusion, here CORE refers to clock inside LCDC IP. This
> CORE should not be confused with CORE PLL. Actually I used CORE so that
> it corresponds to the nomenclature in LCDC section of TRM.
> 
> > Note that this is from my past experience with OMAP, and I'm making an
> > assumption that the clock scheme between OMAP and Da Vinci/AM335x parts
> > isn't very different.
> 
> Additional detail: DaVinci doesn't have these 3 clocks controls available,
> so these three are required only on AM335x (which has IP version 2 )
> 
> > Is there a public TRM I can look at?  It would help me understand this
> > without having to ask you so many annoying questions ;)
> 
> No problem, http://www.ti.com/product/am3359
> 
> 
> > > And now we are left with DMA, this is actually in the interface clock
> > > path which driver in unaware. An option would be to have DMA clock
> > > as child of CORE plus divider composite clock, even though logically
> > > DMA can't be considered in the same path.
> 
> > Why is the driver unaware of the interface clk?  For instance OMAP3 had
> > separate fclk and iclk for IPs and drivers would call clk_enable on
> > both.  Or am I misunderstanding something?
> 
> HWMOD handles enabling those upon pm_runtime calls, HWMOD makes an alias
> for main clock with "fck", but not for "ick", so currently "ick" is
> unavailable for the driver, continued below ..
> 
> > In general I don't think the clock subtree should be modeled in a way
> > that is convenient for software, but instead model the actual hardware.
> > Trust me, if you don't model the actual hardware then you will be very
> > confused when you come back and revisit this code in 6 months and can't
> > remember why things are so weird looking.
> 
> Ok, then it seems an omap clock entry for con-id "ick" should be created
> as follows (dpll_core_m4_ck supplies interface clock),
> 
> CLK("4830e000.lcdc",    "ick",          &dpll_core_m4_ck,       CK_AM33XX)
> 
> And then in the driver, DMA gate clock should be made a child of this clock
> (obtained with con-id "ick").
> 
> Let me know your opinion on this.
> 

I think Paul W. or someone on the TI side should weigh in on your clkdev
entries.  My main point is that the actual tree should be modeled and
clocks shouldn't be globbed together unnecessarily.  As mentioned in the
other mail thread you might be better off making a divider for your LCDC
IP block and modeling each node individually.

Regards,
Mike

> Regards
> Afzal