[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <202208030811.22322.pisa@cmp.felk.cvut.cz>
Date: Wed, 3 Aug 2022 08:11:22 +0200
From: Pavel Pisa <pisa@....felk.cvut.cz>
To: Matej Vasilevski <matej.vasilevski@...nam.cz>,
"Marc Kleine-Budde" <mkl@...gutronix.de>
Cc: Ondrej Ille <ondrej.ille@...il.com>,
Wolfgang Grandegger <wg@...ndegger.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
linux-can@...r.kernel.org, netdev@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v2 1/3] can: ctucanfd: add HW timestamps to RX and error CAN frames
Minor remark to clocks
On Wednesday 03 of August 2022 02:09:03 Matej Vasilevski wrote:
> On Tue, Aug 02, 2022 at 11:29:07AM +0200, Marc Kleine-Budde wrote:
> > > diff --git a/drivers/net/can/ctucanfd/ctucanfd.h
> > > b/drivers/net/can/ctucanfd/ctucanfd.h index 0e9904f6a05d..43d9c73ce244
....
> > > @@ -1386,7 +1536,9 @@ int ctucan_probe_common(struct device *dev, void
> > > __iomem *addr, int irq, unsigne
> > >
> > > /* Getting the can_clk info */
> > > if (!can_clk_rate) {
> > > - priv->can_clk = devm_clk_get(dev, NULL);
> > > + priv->can_clk = devm_clk_get_optional(dev, "core-clk");
> > > + if (!priv->can_clk)
> > > + priv->can_clk = devm_clk_get(dev, NULL);
> >
> > Please add a comment here, that the NULL clock is for compatibility with
> > older DTs.
>
> Even in this patch the clock-names isn't a required property in the DT.
> But I can add a comment explaining the situation.
In the fact, actual FPGA design is intended for single clock domain
and if timestamp counter is running from other non synchronized
clocks then cross domain synchronization is necessary
which in a 64-bit parallel case is relatively complex.
Sampling of some slower clocks signal on input to CTU CAN FD
core domain would be easier...
There can appear optimization for some constrained designs
in future where clock counter is narrowed to less bits
and clock is divided from main clocks by some ratio...
So option to use separate ts-clock is reserve for future.
I personally, do not even insist on including the second
clock to the driver now because all our actual and currently
planed designs are single clock domain. But may it be Ondrej
Ille can comment even further foresee...
Thanks for the work and review,
Pavel
--
Pavel Pisa
phone: +420 603531357
e-mail: pisa@....felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal: http://cmp.felk.cvut.cz/~pisa
projects: https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
Powered by blists - more mailing lists