Hi Vinod,
On 7/6/22 12:57 PM, Vinod Koul wrote:
> On 05-07-22, 11:29, Sean Anderson wrote:
>
>> >> + /* TODO: wait for the PLL to lock */
>> >
>> > when will this be added?
>>
>> I'm not sure. I haven't had any issues with this, and waiting on the lock bit is
>> only mentioned in some datasheets for this SerDes. On the LS1046A for example,
>> there is no mention of waiting for lock.
>
> okay maybe remove the comment then?
Well, as it happens, on the write before this (where we request the reset), we must
wait for the request to clear before making this write. Since that needed a
read_poll_timeout anyway, I added one for this line as well.
>> >> +static const struct clk_ops lynx_pll_clk_ops = {
>> >> + .enable = lynx_pll_enable,
>> >> + .disable = lynx_pll_disable,
>> >> + .is_enabled = lynx_pll_is_enabled,
>> >> + .recalc_rate = lynx_pll_recalc_rate,
>> >> + .round_rate = lynx_pll_round_rate,
>> >> + .set_rate = lynx_pll_set_rate,
>> >> +};
>> >
>> > right, this should be a clk driver
>>
>> Well, it is a clock driver, effectively internal to the SerDes. There are a few
>> examples of this already (e.g. the qualcomm and cadence phys). It could of course
>> be split off, but I would prefer that they remained together.
>
> I would prefer clk driver is split and we maintain clean split b/w phy
> and clk
>
OK. I will split this into drivers/phy/freescale/phy-fsl-lynx-10g-clk.c
--Sean
