Re: [PATCH] dt-bindings: net: renesas,ethertsn: Add bindings for Ethernet TSN

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Niklas,

On Tue, Nov 21, 2023 at 1:44 PM Niklas Söderlund
<niklas.soderlund+renesas@xxxxxxxxxxxx> wrote:
> On 2023-11-21 13:20:54 +0100, Krzysztof Kozlowski wrote:
> > On 21/11/2023 13:10, Niklas Söderlund wrote:
> > >>> +
> > >>> +  renesas,rx-internal-delay:
> > >>> +    type: boolean
> > >>> +    description:
> > >>> +      Enable internal Rx clock delay, typically 1.8ns.
> > >>
> > >> Why this is bool, not delay in ns?
> > >
> > > The TSN is only capable of enabling or disable internal delays, not set
> > > how long the delay is. The documentation states that the delay depends
> > > on the electronic characteristics of the particular board, but states
> > > that they typically are 1.8ns for Rx and 2.0ns for Tx.
> >
> > I don't understand that part. If you cannot configure the internal
> > delay, how could it depend on the board characteristics?
>
> Each of these two properties reflect a single bit in the device
> configuration space. If the bit is set the {Rx,Tx} delay mode is active
> or disabled. The documentation for the bit simply states,
>
>     Tx clock internal Delay Mode
>
>     This bit can add internal Tx clock delay typ 2.0ns*.
>
>     *Refer to Electrical Characteristics for details.
>
> Same paragraph for Rx but a typical 1.8ns delay.
>
> > > I looked at the generic properties {rx,tx}-internal-delay-ps but they
> > > are of int type. So I opted for a vendor specific bool property. Do you
> > > think a better route is to use the generic property and force the value
> > > to be either 0 or the typical delay?

This is not dissimilar from EtherAVB, where the hardware also supports
only a single bit, and whose DT bindings have:

  rx-internal-delay-ps:
    enum: [0, 1800]

  tx-internal-delay-ps:
    enum: [0, 2000]

(with additional restrictions depending on the SoC, as on some SoCs
 the bits cannot be changed).

> > >> Why this is property of a board (not SoC)?
> > >
> > > I'm sorry I don't understand this question.
> >
> > Why setting internal delay is specific to a board, not to a SoC? Why
> > each board would need to configure it? On which parts of hardware on the
> > board does this depend?
>
> Ahh, I think I understand. It is per board as I understand the
> documentation. It depends on the electrical characteristics of the
> board.

Exactly. These bits (and also similar bits in the PHY) are used to
adapt signaling to the board trace lengths between MAC (on-SoC) and PHY.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds





[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux