From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [PATCH v3] Axi-usb: Add support for 64-bit addressing. Date: Wed, 25 May 2016 13:53:32 -0500 Message-ID: References: <1464067268-35299-1-git-send-email-navam@xilinx.com> <20160525173419.GA7510@rob-hp-laptop> <5392766.vCAWrASuOA@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <5392766.vCAWrASuOA@wuerfel> Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann Cc: Nava kishore Manne , "pawel.moll@arm.com" , "mark.rutland@arm.com" , "ijc+devicetree@hellion.org.uk" , "galak@codeaurora.org" , Michal Simek , Soren Brinkmann , "balbi@ti.com" , "gregkh@linuxfoundation.org" , Hyun Kwon , Radhey Shyam Pandey , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" List-Id: devicetree@vger.kernel.org On Wed, May 25, 2016 at 1:29 PM, Arnd Bergmann wrote: > On Wednesday, May 25, 2016 12:34:19 PM CEST Rob Herring wrote: >> On Tue, May 24, 2016 at 11:47:31AM +0000, Nava kishore Manne wrote: >> > >> > >> > > -----Original Message----- >> > > From: Arnd Bergmann [mailto:arnd@arndb.de] >> > > Sent: Tuesday, May 24, 2016 2:21 PM >> > > To: Nava kishore Manne >> > > Cc: robh+dt@kernel.org; pawel.moll@arm.com; mark.rutland@arm.com; >> > > ijc+devicetree@hellion.org.uk; galak@codeaurora.org; Michal Simek >> > > ; Soren Brinkmann ; >> > > balbi@ti.com; gregkh@linuxfoundation.org; Hyun Kwon >> > > ; Nava kishore Manne ; Radhey >> > > Shyam Pandey ; devicetree@vger.kernel.org; linux- >> > > arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org >> > > Subject: Re: [PATCH v3] Axi-usb: Add support for 64-bit addressing. >> > > >> > > On Tuesday, May 24, 2016 10:51:08 AM CEST Nava kishore Manne wrote: >> > > > diff --git a/Documentation/devicetree/bindings/usb/udc-xilinx.txt >> > > > b/Documentation/devicetree/bindings/usb/udc-xilinx.txt >> > > > index 47b4e39..09df757 100644 >> > > > --- a/Documentation/devicetree/bindings/usb/udc-xilinx.txt >> > > > +++ b/Documentation/devicetree/bindings/usb/udc-xilinx.txt >> > > > @@ -1,18 +1,23 @@ >> > > > Xilinx USB2 device controller >> > > > >> > > > Required properties: >> > > > -- compatible : Should be "xlnx,usb2-device-4.00.a" >> > > > +- compatible : Should be "xlnx,usb2-device-4.00.a" or >> > > > + "xlnx,usb2-device-5.00" >> > > > - reg : Physical base address and size of the USB2 >> > > > device registers map. >> > > > - interrupts : Should contain single irq line of USB2 device >> > > > controller >> > > > - xlnx,has-builtin-dma : if DMA is included >> > > > +- dma-ranges : Should be as the following >> > > > + >> > > >> > > A USB host should not have any children that are DMA capable, I think, so >> > > this property doesn't make sense here. It should be part of the parent bus. >> > > >> > Will send next version (v4) by removing this property from the DT. >> > >> > > > +- xlnx,addrwidth : Should be the dma addressing size in bits(ex: 64 >> > > bits) >> > > >> > > I'm still unconvinced about the property definition here. What are the >> > > possible options for the IP block? I don't think I ever saw a reply from you to >> > > my earlier questions. >> > > >> > >> > Sorry Let me clearly explain >> > >> > From the IP version 5.0 onwards The IP support both 32-bit and 64-bit addressing. >> > But the older version of the IP's supports only 32-bit addressing. >> > >> > This addrwidth property differentiates the address width for the new IP (I mean 5.0 version on wards) >> > For older IP it will be always 32-bit. >> >> Then I think you should have a simple boolean property for 64-bit >> configuration. > > I think matching on the version number is slightly better, as we have the version > already and it identifies whether the register exists. > > Having a boolean property of course works as well, it just duplicates that > information. It doesn't because v5.0 h/w can be configured for either 32 or 64-bit mode. Normally, we would encode configuration into the compatible strings, but I view FPGA based blocks to be an exception. Of course, since they can just "fix the h/w" we could just require h/w version and feature registers. ;) Rob