[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3bdbf164-f28a-5954-408b-99be3ecaa6c1@novek.ru>
Date: Thu, 30 Jun 2022 00:37:25 +0100
From: Vadim Fedorenko <vfedorenko@...ek.ru>
To: Stephen Boyd <sboyd@...nel.org>,
Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>,
Jakub Kicinski <kuba@...nel.org>,
Jonathan Lemon <jonathan.lemon@...il.com>
Cc: Vadim Fedorenko <vadfed@...com>, Aya Levin <ayal@...dia.com>,
netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-clk@...r.kernel.org
Subject: Re: [RFC PATCH v2 1/3] dpll: Add DPLL framework base functions
Hi Stephen!
On 29.06.2022 09:34, Stephen Boyd wrote:
> Quoting Vadim Fedorenko (2022-06-26 12:24:42)
>> From: Vadim Fedorenko <vadfed@...com>
>>
>> DPLL framework is used to represent and configure DPLL devices
>> in systems. Each device that has DPLL and can configure sources
>> and outputs can use this framework.
>
> Please add more details to the commit text, and possibly introduce some
> Documentation/ about this driver subsystem. I'm curious what is
> different from drivers/clk/, is it super large frequencies that don't
> fit into 32-bits when represented in Hz? Or PLL focused? Or is sub-Hz
> required?
Sure, I'm working on adding Documentation/ patch in the next iteration. For now
I would it's mostly focused on PLL configuration rather then clocking thing. And
the main reason is to provide flexible netlink API.
>
> Details please!
>
> Does DPLL stand for digital phase locked loop? Again, I have no idea! I
> think you get my point.
Yes, you are right, DPLL stands for digital phase locked loop.
Powered by blists - more mailing lists