Re: [PATCH 1/3] ARM: tegra: add EMC clock scaling API

[Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>]

Am Dienstag, den 18.12.2012, 19:50 +0800 schrieb Mark Zhang:
[...]
> >>>>
> >>>> Get confused here. Why we add all bandwidth up? We should loop all the
> >>>> bandwidth requests in "constraints" array, find out the largest one,
> >>>> compare with emc table then finally write the registers and set the emc
> >>>> clock, isn't it?
> >>>>
> >>> No, bandwidth constraints add up. Imagine two display clients scanning
> >>> out at the same time. Both on their own may be satisfied with 83MHz DRAM
> >>> clock, but if they are running at the same time you have to account for
> >>> that and maybe bump DRAM freq to 133MHz.
> >>
> >> Ah, yes, this is correct for dc. I skimmed the downstream kernel codes
> >> and found that there are different logics for different clients. For DC,
> >> their bandwidth request should be added up. For other clients, e.g: USB,
> >> set to max bandwidth request is OK.
> >>
> >> So we may do more works on this part later, to write a more accurate
> >> algorithms to get the final emc rate. For now, it's OK.
> >>
> > I don't see how there could be any difference at the EMC level. You
> > always want the EMC to deliver enough bandwidth for all registered
> > clients. You certainly don't want to risk display corruptions just
> > because USB also demands it's share. This might be a bad example as the
> > high priority of the DC transaction may kick out USB, but still.
> > 
> > There might be different ways on how clients compute their needed
> > bandwidth, maybe USB only request bandwidth for one high speed port even
> > if three ports are connected. But that's the clients decision, not the
> > EMCs.
> 
> Make EMC to deliver enough bandwidth is right but if we don't do
> something while just adding all requests up will make EMC always running
> at the highest rate, because EMC has too many clients. That makes
> DVFS/power saving doesn't make sense.
> 
Clients should only request bandwidth from the EMC if they are going to
use it. It isn't too clear from the current patchset, but clients are
responsible to set their bandwidth req back to zero if they don't need
the bw any more to provide the EMC with opportunities to scale back down
again.

For DC we are not using this right now as we are never turning off a DC
at all. But I have some DPMS patches in the making that will show how
this is supposed to work: request bw for the current mode, clear out the
req once you stop scanout.

As explained in the comment at the function prototype you don't request
bw because you may need it to do something fast, but because you need it
and your engine will malfunction if the EMC fails to provide this much
bw. That's why it called the bandwidth floor internally.

Regards,
Lucas