Comment 213 for bug 1563110

Revision history for this message
In , andy.shevchenko (andy.shevchenko-linux-kernel-bugs) wrote :

(In reply to Pierre Bossart from comment #86)
> (In reply to Andy Shevchenko from comment #84)
> > (In reply to Pierre Bossart from comment #82)

> > I just looked to rt5670.c and noticed an ugly is_valleyview() function. Can
> > you utilize power resources instead if they are available? For example in
> > DSDT attached to this bug we see
> >
> > Name (_PR0, Package (0x01) // _PR0: Power Resources for D0
> > {
> > CLK3
> > })
> >
> > I'm pretty sure it's about the same PMC PLT clock. I think entire approach
> > with clocks might be revisited after reading ACPI DSDT tables carefully.
> >
> > Care to check?
>
> I have no idea what you're asking for, it's probably a different point
> anyways unrelated to GPIOs.

Yes, it's an offtopic here.

> There is no is_valleyview() in the codec driver,
> but there are some in the machine drivers. if you check your email, you'll
> see a question from me last week asking how I am supposed to know if the
> firmware manages the clock or not. I ended-up calling devm_clk_get()
> unconditionally, assuming that there is no harm and that if the clock is
> firmware controlled it will not be gated on clk_disable/unprepare. see
> https://github.com/plbossart/sound/commit/
> 233602172d97270dfc47222fa5805b8dabd4b1ce

That's good stuff! Thanks.