Displaying 4 results from an estimated 4 matches for "hda2hdmi".
2015 Jan 08
2
[PATCH 1/11] ARM: tegra: add function to control the GPU rail clamp
...;s according to 5.6.6 "Programming Guide for Power Gating and
> Ungating" of the Tegra K1 TRM. It also seems like a bunch of modules are
> part of seemingly unrelated domains. Especially SOR seems to cover a
> large range of modules (MIPI-CAL, DPAUX, SOR, HDMI, DSI, DSIB and
> HDA2HDMI).
>
> Given that we may want to more fine-grainedly control clocks to save
> power, don't we need to control clocks and resets within the drivers? I
> think the runtime PM framework makes sure to call this in the right
> order, so for suspend, the sequence would be:
>
>...
2015 Jan 07
4
[PATCH 1/11] ARM: tegra: add function to control the GPU rail clamp
On 04:12:54PM Jan 07, Peter De Schrijver wrote:
> On Wed, Jan 07, 2015 at 06:49:27PM +0800, Vince Hsu wrote:
> >
> > On 01/07/2015 06:19 PM, Peter De Schrijver wrote:
> > >On Mon, Jan 05, 2015 at 04:09:33PM +0100, Thierry Reding wrote:
> > >>* PGP Signed by an unknown key
> > >>
> > >>On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu
2015 Jan 08
0
[PATCH 1/11] ARM: tegra: add function to control the GPU rail clamp
...6 "Programming Guide for Power Gating and
> > Ungating" of the Tegra K1 TRM. It also seems like a bunch of modules are
> > part of seemingly unrelated domains. Especially SOR seems to cover a
> > large range of modules (MIPI-CAL, DPAUX, SOR, HDMI, DSI, DSIB and
> > HDA2HDMI).
> >
> > Given that we may want to more fine-grainedly control clocks to save
> > power, don't we need to control clocks and resets within the drivers? I
> > think the runtime PM framework makes sure to call this in the right
> > order, so for suspend, the sequen...
2015 Jan 07
0
[PATCH 1/11] ARM: tegra: add function to control the GPU rail clamp
...nds on DIS
That's according to 5.6.6 "Programming Guide for Power Gating and
Ungating" of the Tegra K1 TRM. It also seems like a bunch of modules are
part of seemingly unrelated domains. Especially SOR seems to cover a
large range of modules (MIPI-CAL, DPAUX, SOR, HDMI, DSI, DSIB and
HDA2HDMI).
Given that we may want to more fine-grainedly control clocks to save
power, don't we need to control clocks and resets within the drivers? I
think the runtime PM framework makes sure to call this in the right
order, so for suspend, the sequence would be:
1) device->suspend
2) domain-&g...