Date:   Mon, 27 Jan 2020 09:28:04 +0000
From:   Radhey Shyam Pandey <radheys@...inx.com>
To:     Andre Przywara <andre.przywara@....com>,
        Rob Herring <robh@...nel.org>
CC:     "David S . Miller" <davem@...emloft.net>,
        Michal Simek <michals@...inx.com>,
        Robert Hancock <hancock@...systems.ca>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: RE: [PATCH 14/14] net: axienet: Update devicetree binding
 documentation

> -----Original Message-----
> From: Andre Przywara <andre.przywara@....com>
> Sent: Friday, January 24, 2020 9:59 PM
> To: Rob Herring <robh@...nel.org>
> Cc: David S . Miller <davem@...emloft.net>; Radhey Shyam Pandey
> <radheys@...inx.com>; Michal Simek <michals@...inx.com>; Robert Hancock
> <hancock@...systems.ca>; netdev@...r.kernel.org; linux-arm-
> kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; Mark Rutland
> <mark.rutland@....com>; devicetree@...r.kernel.org
> Subject: Re: [PATCH 14/14] net: axienet: Update devicetree binding
> documentation
> 
> On Tue, 21 Jan 2020 15:51:09 -0600
> Rob Herring <robh@...nel.org> wrote:
> 
> Hi Rob,
> 
> thanks for having a look!
> 
> > On Fri, Jan 10, 2020 at 11:54:15AM +0000, Andre Przywara wrote:
> > > This adds documentation about the newly introduced, optional
> > > "xlnx,addrwidth" property to the binding documentation.
> > >
> > > While at it, clarify the wording on some properties, replace obsolete
> > > .txt file references with their new .yaml counterparts, and add a more
> > > modern example, using the axistream-connected property.
> > >
> > > Cc: Rob Herring <robh+dt@...nel.org>
> > > Cc: Mark Rutland <mark.rutland@....com>
> > > Cc: devicetree@...r.kernel.org
> > > Signed-off-by: Andre Przywara <andre.przywara@....com>
> > > ---
> > >  .../bindings/net/xilinx_axienet.txt           | 57 ++++++++++++++++---
> > >  1 file changed, 50 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt
> b/Documentation/devicetree/bindings/net/xilinx_axienet.txt
> > > index 7360617cdedb..78c278c5200f 100644
> > > --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt
> > > +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt
> > > @@ -12,7 +12,8 @@ sent and received through means of an AXI DMA
> controller. This driver
> > >  includes the DMA driver code, so this driver is incompatible with AXI DMA
> > >  driver.
> > >
> > > -For more details about mdio please refer phy.txt file in the same directory.
> > > +For more details about mdio please refer to the ethernet-phy.yaml file in
> > > +the same directory.
> > >
> > >  Required properties:
> > >  - compatible	: Must be one of "xlnx,axi-ethernet-1.00.a",
> > > @@ -27,14 +28,14 @@ Required properties:
> > >  		  instead, and only the Ethernet core interrupt is optionally
> > >  		  specified here.
> > >  - phy-handle	: Should point to the external phy device.
> > > -		  See ethernet.txt file in the same directory.
> > > -- xlnx,rxmem	: Set to allocated memory buffer for Rx/Tx in the
> hardware
> > > +		  See the ethernet-controller.yaml file in the same directory.
> > > +- xlnx,rxmem	: Size of the RXMEM buffer in the hardware, in bytes.
> > >
> > >  Optional properties:
> > > -- phy-mode	: See ethernet.txt
> > > +- phy-mode	: See ethernet-controller.yaml.
> > >  - xlnx,phy-type	: Deprecated, do not use, but still accepted in
> preference
> > >  		  to phy-mode.
> > > -- xlnx,txcsum	: 0 or empty for disabling TX checksum offload,
> > > +- xlnx,txcsum	: 0 for disabling TX checksum offload (default if
> omitted),
> > >  		  1 to enable partial TX checksum offload,
> > >  		  2 to enable full TX checksum offload
> > >  - xlnx,rxcsum	: Same values as xlnx,txcsum but for RX checksum
> offload
> > > @@ -48,10 +49,20 @@ Optional properties:
> > >  		       If this is specified, the DMA-related resources from that
> > >  		       device (DMA registers and DMA TX/RX interrupts) rather
> > >  		       than this one will be used.
> > > - - mdio		: Child node for MDIO bus. Must be defined if PHY
> access is
> > > +- mdio		: Child node for MDIO bus. Must be defined if PHY
> access is
> > >  		  required through the core's MDIO interface (i.e. always,
> > >  		  unless the PHY is accessed through a different bus).
> > >
> > > +Required properties for axistream-connected subnode:
> > > +- reg		: Address and length of the AXI DMA controller MMIO
> space.
> > > +- interrupts	: A list of 2 interrupts: TX DMA and RX DMA, in that order.
> > > +
> > > +Optional properties for axistream-connected subnode:
> > > +- xlnx,addrwidth: Specifies the configured address width of the DMA. Newer
> > > +		  versions of the IP allow setting this to a value between
> > > +		  32 and 64. Defaults to 32 bits if not specified.
> >
> > I think this should be expressed using dma-ranges. This is exactly the
> > purpose of dma-ranges and we shouldn't need a device specific property
> > for this sort of thing.

dma-ranges define the relationship between the physical address spaces of the
parent and child nodes. In this case, ethernet and dma (parent-child) have
the same view of physical address space.   Do we mean to use the child-size
dma-range field and determine the address width?

> 
> OK, after talking to Robin about it, I think I will indeed drop the whole usage of
> xlnx,addrwidth altogether.
> Some thoughts:
> - An integrator would choose the addrwidth value in the IP to be big enough for
> the whole bus. In our case it's actually 40 bits, because this is the max address
> size the interconnect supports. So any possible physical address the kernel could
> come up with would be valid for the DMA IP.
> - Because of this we set the DMA mask to either 64-bit or 32-bit, depending on
> the auto detection of the MSB registers.
> - If some integrator screws this up anyway, they can always set dma-ranges in
> the parent to limit the address range. IIUC, no further code would be needed in
> the Ethernet driver, as this would be handled by some (DMA?) framework?

I think the current driver design will be simplified once we switch to the
dmaengine framework and use the xilinx dma(drivers/dma/xilinx_dma.c) driver.
The address width parsing is already handled by the dma driver. I am working
on an RFC to remove dma code from axiethernet and planning to post patchset.
Hopefully, that should address all concerns.

> 
> Does that make sense?
> 
> Cheers,
> Andre

Powered by blists - more mailing lists