[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <614267d5-4cfa-94d4-3f2a-c2467b3b9cd6@seco.com>
Date: Tue, 18 Jan 2022 11:53:25 -0500
From: Sean Anderson <sean.anderson@...o.com>
To: Robert Hancock <robert.hancock@...ian.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"bjagadee@...eaurora.org" <bjagadee@...eaurora.org>,
"balbi@...nel.org" <balbi@...nel.org>,
"baruch@...s.co.il" <baruch@...s.co.il>
Subject: Re: [PATCH 2/6] usb: dwc3: Get clocks individually
Hi Rob,
On 1/14/22 8:04 PM, Robert Hancock wrote:
> On Fri, 2022-01-14 at 18:39 -0500, Sean Anderson wrote:
>> Instead of grabbing all clocks in bulk, grab them individually. This will
>> allow us to get the frequency or otherwise deal with discrete clocks. This
>> may break some platforms if they use a clock which doesn't use one of the
>> documented names.
>
> Another approach would be to keep the bulk get and prepare_enable and just
> search through the clocks in the bulk data to find the "ref" clock, i.e.
> something like:
>
> for (i = 0; i < dwc->num_clks; ++i)
> if (!strcmp("ref", dwc->clks[i].id)) {
> ref_clk_rate = clk_get_rate(dwc->clks[i].clk);
> break;
> }
>
> That's probably simpler than all the extra complexity to get each of the clocks
> individually and release them in the right order.
Hm, maybe. But in the future, we may want to access other clocks as
well. E.g. perhaps PM might be enhanced by treating the bus/suspend
clock specially for some modes. I think grabbing the clocks up front
will make later patches easier to write.
--Sean
Powered by blists - more mailing lists