| Message ID | 1480183585-592-40-git-send-email-yamada.masahiro@socionext.com |
|---|---|
| State | New |
| Headers | show |
On Sun, Nov 27, 2016 at 03:06:25AM +0900, Masahiro Yamada wrote: > Add two compatible strings for UniPhier SoCs. The revision register > on both shows revision 5.0, but they are different hardware. > > Features: > - DMA engine with 64 bit physical address support > - 1024 byte ECC step size > - 8 / 16 / 24 bit ECC strength > - The n_banks format depends on SoC > > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> > --- > > .../devicetree/bindings/mtd/denali-nand.txt | 10 +++++-- > drivers/mtd/nand/denali_dt.c | 33 ++++++++++++++++++++-- > 2 files changed, 38 insertions(+), 5 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt > index 51fe195..cea46e2 100644 > --- a/Documentation/devicetree/bindings/mtd/denali-nand.txt > +++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt > @@ -1,13 +1,19 @@ > * Denali NAND controller > > Required properties: > - - compatible : should be "denali,denali-nand-dt" > + - compatible : should be one of the following: > + "denali,denali-nand-dt" There are multiple things wrong with this string. denali,denali is redundant is one. It's also fairly useless as this IP has several versions and numerous configuration options IIRC. This should be deprecated IMO. > + "denali,denali-nand-uniphier-v5a" > + "denali,denali-nand-uniphier-v5b" Use your vendor prefix, not denali. The 2nd denali can probably be dropped because it is not likely you have another kind of nand controller in the SoC. > - reg : should contain registers location and length for data and reg. > - reg-names: Should contain the reg names "nand_data" and "denali_reg" > - interrupts : The interrupt number. > > Optional properties: > - - nand-ecc-step-size: must be 512 or 1024. If not specified, default to 512. > + - nand-ecc-step-size: must be 512 or 1024. If not specified, default to: > + 512 for "denali,denali-nand-dt" > + 1024 for "denali,denali-nand-uniphier-v5a" > + 1024 for "denali,denali-nand-uniphier-v5b" > see nand.txt for details. > - nand-ecc-strength: see nand.txt for details > - nand-ecc-maximize: see nand.txt for details -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rob, (+CC Dinh) 2016-12-02 1:05 GMT+09:00 Rob Herring <robh@kernel.org>: > On Sun, Nov 27, 2016 at 03:06:25AM +0900, Masahiro Yamada wrote: >> Add two compatible strings for UniPhier SoCs. The revision register >> on both shows revision 5.0, but they are different hardware. >> >> Features: >> - DMA engine with 64 bit physical address support >> - 1024 byte ECC step size >> - 8 / 16 / 24 bit ECC strength >> - The n_banks format depends on SoC >> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> >> --- >> >> .../devicetree/bindings/mtd/denali-nand.txt | 10 +++++-- >> drivers/mtd/nand/denali_dt.c | 33 ++++++++++++++++++++-- >> 2 files changed, 38 insertions(+), 5 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt >> index 51fe195..cea46e2 100644 >> --- a/Documentation/devicetree/bindings/mtd/denali-nand.txt >> +++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt >> @@ -1,13 +1,19 @@ >> * Denali NAND controller >> >> Required properties: >> - - compatible : should be "denali,denali-nand-dt" >> + - compatible : should be one of the following: >> + "denali,denali-nand-dt" > > There are multiple things wrong with this string. denali,denali is > redundant is one. One more redundancy; "-dt" is weird because DT compatible should be a name of hardware. > It's also fairly useless as this IP has several > versions and numerous configuration options IIRC. This should be > deprecated IMO. Right. There are several customizable parameters for this IP, so a generic compatible string like this is probably useless. This DT binding was added by commit 30f9f2f for Altera SOCFPGA, A funny thing is that they upstreamed DT binding, but they did not upstream needed changes for the Denali driver core. So, the mainline driver has never worked on SOCFPGA (or any of DT-based SoCs). >> + "denali,denali-nand-uniphier-v5a" >> + "denali,denali-nand-uniphier-v5b" > > Use your vendor prefix, not denali. The 2nd denali can probably be > dropped because it is not likely you have another kind of nand > controller in the SoC. Hmm, your statement implies that a vendor prefix belongs to an SoC vendor, not an IP vendor. (I was not quite sure about this.) It is unlikely to happen to have two different NAND controllers on one SoC. But, we used a different NAND controller for our SoC family before introducing the Denali IP. It also implies that Socionext may use a different NAND IP in the future. I'd like to include "denali" somewhere because it is clearly associated with the driver name. Also, this will give an idea what kind of _basic_ hardware is used, even though we know various parameters are customizable. (Plan A) "denali,socfpga-nand" (for Altera SOCFPGA variant) "denali,uniphier-nand-v1" (for old Socionext UniPhier family variant) "denali,uniphier-nand-v2" (for new Socionext UniPhier family variant) (Plan B) "altera,denali-nand" (for Altera SOCFPGA variant) "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant) "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant) I think Plan B is nearer to your suggestion, and I think it is OK for Socionext (hopefully for Altera too). -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/03/2016 03:41 AM, Masahiro Yamada wrote: > Hi Rob, Hi! > 2016-12-03 1:26 GMT+09:00 Rob Herring <robh@kernel.org>: > >>> >>> >>> (Plan A) >>> "denali,socfpga-nand" (for Altera SOCFPGA variant) >>> "denali,uniphier-nand-v1" (for old Socionext UniPhier family variant) >>> "denali,uniphier-nand-v2" (for new Socionext UniPhier family variant) >>> >>> (Plan B) >>> "altera,denali-nand" (for Altera SOCFPGA variant) >>> "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant) >>> "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant) > >> Let the Altera folks worry about their stuff. At least for soft IP in >> FPGA, it's a bit of a special case. The old string can remain as bad >> as it is. > > > Hmm, I am not sure if this IP would fit in FPGA > (to use it along with NIOS-II?) > > (even if it happened, nothing of this IP would be customizable on users' side. > When buying the IP, SoC vendors submit a list of desired features. > Denali (now Cadence) generates the RTL according to the configuration sheet. > The function is fixed at this point. So, generic compatible would be > useless anyway.) > > > If we are talking about SOCFPGA, > SOCFPGA is not only FPGA. Rather "SOC" + "FPGA". > It consists of two parts: > [1] SOC part (Cortex-A9 + various hard-wired peripherals such UART, > USB, SD, NAND, ...) > [2] FPGA part (User design logic) > > The Denali NAND controller is included in [1]. > So, as far as we talk about the Denali on SOCFPGA, > it is as hard-wired as Intel, Socionext's ones. That's correct, the Denali NAND IP in altera socfpga is a hardware block. You can make it available to the fabric too, but by default it's used by the ARM part of the chip, so for this discussion, you can forget that the FPGA part exists altogether. I would be in favor of plan B, since it seems to be the more often taken approach. A nice example is ci-hdrc: $ git grep compatible drivers/usb/chipidea/ >> I simply would do "socionext,uniphier-v5b-nand" (and v5a). >> The fact that it is denali is part of the documentation. >> > > Let me think about this. > > Socionext bought two version of Denali IP, > and we are now re-using the newer one (v5b) for several SoCs. > Socionext has some more product lines other than Uniphier SoC family, > perhaps wider re-use might happen in the future. > > At first, I included "uniphier" in compatible, but I am still wondering > if such a specific string is good or not. > > Also, comments from Altera engineers are appreciated. Adding a few more on Cc -- Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > On 12/03/2016 03:41 AM, Masahiro Yamada wrote: >> Hi Rob, > > Hi! > >> 2016-12-03 1:26 GMT+09:00 Rob Herring <robh@kernel.org>: >> >>>> >>>> >>>> (Plan A) >>>> "denali,socfpga-nand" (for Altera SOCFPGA variant) >>>> "denali,uniphier-nand-v1" (for old Socionext UniPhier family variant) >>>> "denali,uniphier-nand-v2" (for new Socionext UniPhier family variant) >>>> >>>> (Plan B) >>>> "altera,denali-nand" (for Altera SOCFPGA variant) >>>> "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant) >>>> "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant) >> >>> Let the Altera folks worry about their stuff. At least for soft IP in >>> FPGA, it's a bit of a special case. The old string can remain as bad >>> as it is. >> >> >> Hmm, I am not sure if this IP would fit in FPGA >> (to use it along with NIOS-II?) >> >> (even if it happened, nothing of this IP would be customizable on users' side. >> When buying the IP, SoC vendors submit a list of desired features. >> Denali (now Cadence) generates the RTL according to the configuration sheet. >> The function is fixed at this point. So, generic compatible would be >> useless anyway.) >> >> >> If we are talking about SOCFPGA, >> SOCFPGA is not only FPGA. Rather "SOC" + "FPGA". >> It consists of two parts: >> [1] SOC part (Cortex-A9 + various hard-wired peripherals such UART, >> USB, SD, NAND, ...) >> [2] FPGA part (User design logic) >> >> The Denali NAND controller is included in [1]. >> So, as far as we talk about the Denali on SOCFPGA, >> it is as hard-wired as Intel, Socionext's ones. > > That's correct, the Denali NAND IP in altera socfpga is a hardware > block. You can make it available to the fabric too, but by default > it's used by the ARM part of the chip, so for this discussion, you > can forget that the FPGA part exists altogether. > > I would be in favor of plan B, since it seems to be the more often > taken approach. A nice example is ci-hdrc: > > $ git grep compatible drivers/usb/chipidea/ > >>> I simply would do "socionext,uniphier-v5b-nand" (and v5a). >>> The fact that it is denali is part of the documentation. >>> >> >> Let me think about this. >> >> Socionext bought two version of Denali IP, >> and we are now re-using the newer one (v5b) for several SoCs. >> Socionext has some more product lines other than Uniphier SoC family, >> perhaps wider re-use might happen in the future. >> >> At first, I included "uniphier" in compatible, but I am still wondering >> if such a specific string is good or not. >> >> Also, comments from Altera engineers are appreciated. Sorry, it's taken me a while to add comments. My altera email is very spotty now that the Intel merge is completed. Please use dinguyen@kernel.org for any future communications. Yes, everything that is said so far for the NAND controller on the SoCFPGA is correct. I added the binding for the controller a while back, but unfortunately, we never added the NAND interface to the devkit, so we did not do much in terms of enabling it. I think the only SoCFPGA board I know that has the NAND interface active is the TRCom board, but I have never seen that board. I don't have any strong opinions on this matter, just as long as the original binding "denali,denali-nand-dt" is kept, and I think Rob was ok with keeping that binding. Dinh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Dinh, 2016-12-04 7:08 GMT+09:00 Dinh Nguyen <dinh.linux@gmail.com>: > Hi, > > On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >> On 12/03/2016 03:41 AM, Masahiro Yamada wrote: >>> Hi Rob, >> >> Hi! >> >>> 2016-12-03 1:26 GMT+09:00 Rob Herring <robh@kernel.org>: >>> >>>>> >>>>> >>>>> (Plan A) >>>>> "denali,socfpga-nand" (for Altera SOCFPGA variant) >>>>> "denali,uniphier-nand-v1" (for old Socionext UniPhier family variant) >>>>> "denali,uniphier-nand-v2" (for new Socionext UniPhier family variant) >>>>> >>>>> (Plan B) >>>>> "altera,denali-nand" (for Altera SOCFPGA variant) >>>>> "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant) >>>>> "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant) >>> >>>> Let the Altera folks worry about their stuff. At least for soft IP in >>>> FPGA, it's a bit of a special case. The old string can remain as bad >>>> as it is. >>> >>> >>> Hmm, I am not sure if this IP would fit in FPGA >>> (to use it along with NIOS-II?) >>> >>> (even if it happened, nothing of this IP would be customizable on users' side. >>> When buying the IP, SoC vendors submit a list of desired features. >>> Denali (now Cadence) generates the RTL according to the configuration sheet. >>> The function is fixed at this point. So, generic compatible would be >>> useless anyway.) >>> >>> >>> If we are talking about SOCFPGA, >>> SOCFPGA is not only FPGA. Rather "SOC" + "FPGA". >>> It consists of two parts: >>> [1] SOC part (Cortex-A9 + various hard-wired peripherals such UART, >>> USB, SD, NAND, ...) >>> [2] FPGA part (User design logic) >>> >>> The Denali NAND controller is included in [1]. >>> So, as far as we talk about the Denali on SOCFPGA, >>> it is as hard-wired as Intel, Socionext's ones. >> >> That's correct, the Denali NAND IP in altera socfpga is a hardware >> block. You can make it available to the fabric too, but by default >> it's used by the ARM part of the chip, so for this discussion, you >> can forget that the FPGA part exists altogether. >> >> I would be in favor of plan B, since it seems to be the more often >> taken approach. A nice example is ci-hdrc: >> >> $ git grep compatible drivers/usb/chipidea/ >> >>>> I simply would do "socionext,uniphier-v5b-nand" (and v5a). >>>> The fact that it is denali is part of the documentation. >>>> >>> >>> Let me think about this. >>> >>> Socionext bought two version of Denali IP, >>> and we are now re-using the newer one (v5b) for several SoCs. >>> Socionext has some more product lines other than Uniphier SoC family, >>> perhaps wider re-use might happen in the future. >>> >>> At first, I included "uniphier" in compatible, but I am still wondering >>> if such a specific string is good or not. >>> >>> Also, comments from Altera engineers are appreciated. > > Sorry, it's taken me a while to add comments. My altera email is very spotty now > that the Intel merge is completed. Please use dinguyen@kernel.org for any future > communications. > > Yes, everything that is said so far for the NAND controller on the > SoCFPGA is correct. I added the binding for the controller a while > back, but unfortunately, we never added the NAND interface to the > devkit, so we did not do much in terms of enabling it. > > I think the only SoCFPGA board I know that has the NAND interface active is > the TRCom board, but I have never seen that board. > > I don't have any strong opinions on this matter, just as long as the > original binding > "denali,denali-nand-dt" is kept, and I think Rob was ok with keeping > that binding. > I am proposing to add "altera,denali-nand" for Altera. For what, do you need the generic compatible? This IP has no default for it to fallback to. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Marek, 2016-12-05 12:44 GMT+09:00 Marek Vasut <marek.vasut@gmail.com>: > On 12/05/2016 04:30 AM, Masahiro Yamada wrote: >> Hi Dinh, >> >> >> 2016-12-04 7:08 GMT+09:00 Dinh Nguyen <dinh.linux@gmail.com>: >>> Hi, >>> >>> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>> On 12/03/2016 03:41 AM, Masahiro Yamada wrote: >>>>> Hi Rob, >>>> >>>> Hi! >>>> >>>>> 2016-12-03 1:26 GMT+09:00 Rob Herring <robh@kernel.org>: >>>>> >>>>>>> >>>>>>> >>>>>>> (Plan A) >>>>>>> "denali,socfpga-nand" (for Altera SOCFPGA variant) >>>>>>> "denali,uniphier-nand-v1" (for old Socionext UniPhier family variant) >>>>>>> "denali,uniphier-nand-v2" (for new Socionext UniPhier family variant) >>>>>>> >>>>>>> (Plan B) >>>>>>> "altera,denali-nand" (for Altera SOCFPGA variant) >>>>>>> "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant) >>>>>>> "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant) >>>>> >>>>>> Let the Altera folks worry about their stuff. At least for soft IP in >>>>>> FPGA, it's a bit of a special case. The old string can remain as bad >>>>>> as it is. >>>>> >>>>> >>>>> Hmm, I am not sure if this IP would fit in FPGA >>>>> (to use it along with NIOS-II?) >>>>> >>>>> (even if it happened, nothing of this IP would be customizable on users' side. >>>>> When buying the IP, SoC vendors submit a list of desired features. >>>>> Denali (now Cadence) generates the RTL according to the configuration sheet. >>>>> The function is fixed at this point. So, generic compatible would be >>>>> useless anyway.) >>>>> >>>>> >>>>> If we are talking about SOCFPGA, >>>>> SOCFPGA is not only FPGA. Rather "SOC" + "FPGA". >>>>> It consists of two parts: >>>>> [1] SOC part (Cortex-A9 + various hard-wired peripherals such UART, >>>>> USB, SD, NAND, ...) >>>>> [2] FPGA part (User design logic) >>>>> >>>>> The Denali NAND controller is included in [1]. >>>>> So, as far as we talk about the Denali on SOCFPGA, >>>>> it is as hard-wired as Intel, Socionext's ones. >>>> >>>> That's correct, the Denali NAND IP in altera socfpga is a hardware >>>> block. You can make it available to the fabric too, but by default >>>> it's used by the ARM part of the chip, so for this discussion, you >>>> can forget that the FPGA part exists altogether. >>>> >>>> I would be in favor of plan B, since it seems to be the more often >>>> taken approach. A nice example is ci-hdrc: >>>> >>>> $ git grep compatible drivers/usb/chipidea/ >>>> >>>>>> I simply would do "socionext,uniphier-v5b-nand" (and v5a). >>>>>> The fact that it is denali is part of the documentation. >>>>>> >>>>> >>>>> Let me think about this. >>>>> >>>>> Socionext bought two version of Denali IP, >>>>> and we are now re-using the newer one (v5b) for several SoCs. >>>>> Socionext has some more product lines other than Uniphier SoC family, >>>>> perhaps wider re-use might happen in the future. >>>>> >>>>> At first, I included "uniphier" in compatible, but I am still wondering >>>>> if such a specific string is good or not. >>>>> >>>>> Also, comments from Altera engineers are appreciated. >>> >>> Sorry, it's taken me a while to add comments. My altera email is very spotty now >>> that the Intel merge is completed. Please use dinguyen@kernel.org for any future >>> communications. >>> >>> Yes, everything that is said so far for the NAND controller on the >>> SoCFPGA is correct. I added the binding for the controller a while >>> back, but unfortunately, we never added the NAND interface to the >>> devkit, so we did not do much in terms of enabling it. >>> >>> I think the only SoCFPGA board I know that has the NAND interface active is >>> the TRCom board, but I have never seen that board. >>> >>> I don't have any strong opinions on this matter, just as long as the >>> original binding >>> "denali,denali-nand-dt" is kept, and I think Rob was ok with keeping >>> that binding. >>> >> >> I am proposing to add "altera,denali-nand" for Altera. >> For what, do you need the generic compatible? >> This IP has no default for it to fallback to. > > IMO just for compatibility reasons with old DTs . We generally contribute for a "working driver" (at least, should be functional to some extent) and "DT binding" bundled together. However, Altera upstreamed the DT binding first (then some parts of the DT binding turned out wrong), but they did not upstream needed driver changes in the end. So, the mainline driver has never worked on SOCFPGA, right? Removing "denali,denali-nand-dt" is not breakage at all, so I do not owe anything to them, right? -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/05/2016 05:10 AM, Masahiro Yamada wrote: > Hi Marek, > > > 2016-12-05 12:44 GMT+09:00 Marek Vasut <marek.vasut@gmail.com>: >> On 12/05/2016 04:30 AM, Masahiro Yamada wrote: >>> Hi Dinh, >>> >>> >>> 2016-12-04 7:08 GMT+09:00 Dinh Nguyen <dinh.linux@gmail.com>: >>>> Hi, >>>> >>>> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>> On 12/03/2016 03:41 AM, Masahiro Yamada wrote: >>>>>> Hi Rob, >>>>> >>>>> Hi! >>>>> >>>>>> 2016-12-03 1:26 GMT+09:00 Rob Herring <robh@kernel.org>: >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (Plan A) >>>>>>>> "denali,socfpga-nand" (for Altera SOCFPGA variant) >>>>>>>> "denali,uniphier-nand-v1" (for old Socionext UniPhier family variant) >>>>>>>> "denali,uniphier-nand-v2" (for new Socionext UniPhier family variant) >>>>>>>> >>>>>>>> (Plan B) >>>>>>>> "altera,denali-nand" (for Altera SOCFPGA variant) >>>>>>>> "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant) >>>>>>>> "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant) >>>>>> >>>>>>> Let the Altera folks worry about their stuff. At least for soft IP in >>>>>>> FPGA, it's a bit of a special case. The old string can remain as bad >>>>>>> as it is. >>>>>> >>>>>> >>>>>> Hmm, I am not sure if this IP would fit in FPGA >>>>>> (to use it along with NIOS-II?) >>>>>> >>>>>> (even if it happened, nothing of this IP would be customizable on users' side. >>>>>> When buying the IP, SoC vendors submit a list of desired features. >>>>>> Denali (now Cadence) generates the RTL according to the configuration sheet. >>>>>> The function is fixed at this point. So, generic compatible would be >>>>>> useless anyway.) >>>>>> >>>>>> >>>>>> If we are talking about SOCFPGA, >>>>>> SOCFPGA is not only FPGA. Rather "SOC" + "FPGA". >>>>>> It consists of two parts: >>>>>> [1] SOC part (Cortex-A9 + various hard-wired peripherals such UART, >>>>>> USB, SD, NAND, ...) >>>>>> [2] FPGA part (User design logic) >>>>>> >>>>>> The Denali NAND controller is included in [1]. >>>>>> So, as far as we talk about the Denali on SOCFPGA, >>>>>> it is as hard-wired as Intel, Socionext's ones. >>>>> >>>>> That's correct, the Denali NAND IP in altera socfpga is a hardware >>>>> block. You can make it available to the fabric too, but by default >>>>> it's used by the ARM part of the chip, so for this discussion, you >>>>> can forget that the FPGA part exists altogether. >>>>> >>>>> I would be in favor of plan B, since it seems to be the more often >>>>> taken approach. A nice example is ci-hdrc: >>>>> >>>>> $ git grep compatible drivers/usb/chipidea/ >>>>> >>>>>>> I simply would do "socionext,uniphier-v5b-nand" (and v5a). >>>>>>> The fact that it is denali is part of the documentation. >>>>>>> >>>>>> >>>>>> Let me think about this. >>>>>> >>>>>> Socionext bought two version of Denali IP, >>>>>> and we are now re-using the newer one (v5b) for several SoCs. >>>>>> Socionext has some more product lines other than Uniphier SoC family, >>>>>> perhaps wider re-use might happen in the future. >>>>>> >>>>>> At first, I included "uniphier" in compatible, but I am still wondering >>>>>> if such a specific string is good or not. >>>>>> >>>>>> Also, comments from Altera engineers are appreciated. >>>> >>>> Sorry, it's taken me a while to add comments. My altera email is very spotty now >>>> that the Intel merge is completed. Please use dinguyen@kernel.org for any future >>>> communications. >>>> >>>> Yes, everything that is said so far for the NAND controller on the >>>> SoCFPGA is correct. I added the binding for the controller a while >>>> back, but unfortunately, we never added the NAND interface to the >>>> devkit, so we did not do much in terms of enabling it. >>>> >>>> I think the only SoCFPGA board I know that has the NAND interface active is >>>> the TRCom board, but I have never seen that board. >>>> >>>> I don't have any strong opinions on this matter, just as long as the >>>> original binding >>>> "denali,denali-nand-dt" is kept, and I think Rob was ok with keeping >>>> that binding. >>>> >>> >>> I am proposing to add "altera,denali-nand" for Altera. >>> For what, do you need the generic compatible? >>> This IP has no default for it to fallback to. >> >> IMO just for compatibility reasons with old DTs . > > We generally contribute for > a "working driver" (at least, should be functional to some extent) > and "DT binding" bundled together. > > However, Altera upstreamed the DT binding first > (then some parts of the DT binding turned out wrong), > but they did not upstream needed driver changes in the end. > > So, the mainline driver has never worked on SOCFPGA, right? Most likely it never worked, yes. > Removing "denali,denali-nand-dt" is not breakage at all, > so I do not owe anything to them, right? I don't think I'm really qualified to answer this one. But, there is drivers/mtd/nand/denali_dt.c , which handles this compatible string and it's documented in Documentation/devicetree/bindings/mtd/denali-nand.txt, so doesn't that make it part of the ABI ? I think we should at least keep it as a fallback, that should be pretty harmless. -- Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Dec 4, 2016 at 10:22 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > On 12/05/2016 05:10 AM, Masahiro Yamada wrote: >> Hi Marek, >> >> >> 2016-12-05 12:44 GMT+09:00 Marek Vasut <marek.vasut@gmail.com>: >>> On 12/05/2016 04:30 AM, Masahiro Yamada wrote: >>>> Hi Dinh, >>>> >>>> >>>> 2016-12-04 7:08 GMT+09:00 Dinh Nguyen <dinh.linux@gmail.com>: >>>>> Hi, >>>>> >>>>> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>>> On 12/03/2016 03:41 AM, Masahiro Yamada wrote: >>>>>>> Hi Rob, >>>>>> >>>>>> Hi! >>>>>> >>>>>>> 2016-12-03 1:26 GMT+09:00 Rob Herring <robh@kernel.org>: >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> (Plan A) >>>>>>>>> "denali,socfpga-nand" (for Altera SOCFPGA variant) >>>>>>>>> "denali,uniphier-nand-v1" (for old Socionext UniPhier family variant) >>>>>>>>> "denali,uniphier-nand-v2" (for new Socionext UniPhier family variant) >>>>>>>>> >>>>>>>>> (Plan B) >>>>>>>>> "altera,denali-nand" (for Altera SOCFPGA variant) >>>>>>>>> "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant) >>>>>>>>> "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant) >>>>>>> >>>>>>>> Let the Altera folks worry about their stuff. At least for soft IP in >>>>>>>> FPGA, it's a bit of a special case. The old string can remain as bad >>>>>>>> as it is. >>>>>>> >>>>>>> >>>>>>> Hmm, I am not sure if this IP would fit in FPGA >>>>>>> (to use it along with NIOS-II?) >>>>>>> >>>>>>> (even if it happened, nothing of this IP would be customizable on users' side. >>>>>>> When buying the IP, SoC vendors submit a list of desired features. >>>>>>> Denali (now Cadence) generates the RTL according to the configuration sheet. >>>>>>> The function is fixed at this point. So, generic compatible would be >>>>>>> useless anyway.) >>>>>>> >>>>>>> >>>>>>> If we are talking about SOCFPGA, >>>>>>> SOCFPGA is not only FPGA. Rather "SOC" + "FPGA". >>>>>>> It consists of two parts: >>>>>>> [1] SOC part (Cortex-A9 + various hard-wired peripherals such UART, >>>>>>> USB, SD, NAND, ...) >>>>>>> [2] FPGA part (User design logic) >>>>>>> >>>>>>> The Denali NAND controller is included in [1]. >>>>>>> So, as far as we talk about the Denali on SOCFPGA, >>>>>>> it is as hard-wired as Intel, Socionext's ones. >>>>>> >>>>>> That's correct, the Denali NAND IP in altera socfpga is a hardware >>>>>> block. You can make it available to the fabric too, but by default >>>>>> it's used by the ARM part of the chip, so for this discussion, you >>>>>> can forget that the FPGA part exists altogether. >>>>>> >>>>>> I would be in favor of plan B, since it seems to be the more often >>>>>> taken approach. A nice example is ci-hdrc: >>>>>> >>>>>> $ git grep compatible drivers/usb/chipidea/ >>>>>> >>>>>>>> I simply would do "socionext,uniphier-v5b-nand" (and v5a). >>>>>>>> The fact that it is denali is part of the documentation. >>>>>>>> >>>>>>> >>>>>>> Let me think about this. >>>>>>> >>>>>>> Socionext bought two version of Denali IP, >>>>>>> and we are now re-using the newer one (v5b) for several SoCs. >>>>>>> Socionext has some more product lines other than Uniphier SoC family, >>>>>>> perhaps wider re-use might happen in the future. >>>>>>> >>>>>>> At first, I included "uniphier" in compatible, but I am still wondering >>>>>>> if such a specific string is good or not. >>>>>>> >>>>>>> Also, comments from Altera engineers are appreciated. >>>>> >>>>> Sorry, it's taken me a while to add comments. My altera email is very spotty now >>>>> that the Intel merge is completed. Please use dinguyen@kernel.org for any future >>>>> communications. >>>>> >>>>> Yes, everything that is said so far for the NAND controller on the >>>>> SoCFPGA is correct. I added the binding for the controller a while >>>>> back, but unfortunately, we never added the NAND interface to the >>>>> devkit, so we did not do much in terms of enabling it. >>>>> >>>>> I think the only SoCFPGA board I know that has the NAND interface active is >>>>> the TRCom board, but I have never seen that board. >>>>> >>>>> I don't have any strong opinions on this matter, just as long as the >>>>> original binding >>>>> "denali,denali-nand-dt" is kept, and I think Rob was ok with keeping >>>>> that binding. >>>>> >>>> >>>> I am proposing to add "altera,denali-nand" for Altera. >>>> For what, do you need the generic compatible? >>>> This IP has no default for it to fallback to. >>> >>> IMO just for compatibility reasons with old DTs . >> >> We generally contribute for >> a "working driver" (at least, should be functional to some extent) >> and "DT binding" bundled together. >> >> However, Altera upstreamed the DT binding first >> (then some parts of the DT binding turned out wrong), >> but they did not upstream needed driver changes in the end. >> >> So, the mainline driver has never worked on SOCFPGA, right? > > Most likely it never worked, yes. > Right, looking through our downstream support, we may need to upstream a few changes to make upstream driver work on SoCFPGA. >> Removing "denali,denali-nand-dt" is not breakage at all, >> so I do not owe anything to them, right? > > I don't think I'm really qualified to answer this one. But, there is > drivers/mtd/nand/denali_dt.c , which handles this compatible string > and it's documented in > Documentation/devicetree/bindings/mtd/denali-nand.txt, so doesn't that > make it part of the ABI ? I think we should > at least keep it as a fallback, that should be pretty harmless. > I would like to propose "altr,denali-nand" as the binding we use to support the driver going forward on SoCFPGA hardware. It's pretty much the same as "altera,denali-nand", just with the correct vendor prefix. If we can please keep, "denali,denali-nand-dt" only because SoCFPGA is using this binding downstream, but I know that is a weak argument. Dinh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/05/2016 03:29 PM, Marek Vasut wrote: > On 12/05/2016 09:51 PM, Dinh Nguyen wrote: >> On Sun, Dec 4, 2016 at 10:22 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>> On 12/05/2016 05:10 AM, Masahiro Yamada wrote: >>>> Hi Marek, >>>> >>>> >>>> 2016-12-05 12:44 GMT+09:00 Marek Vasut <marek.vasut@gmail.com>: >>>>> On 12/05/2016 04:30 AM, Masahiro Yamada wrote: >>>>>> Hi Dinh, >>>>>> >>>>>> >>>>>> 2016-12-04 7:08 GMT+09:00 Dinh Nguyen <dinh.linux@gmail.com>: >>>>>>> Hi, >>>>>>> >>>>>>> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>>>>> On 12/03/2016 03:41 AM, Masahiro Yamada wrote: >>>>>>>>> Hi Rob, >>>>>>>> >>>>>>>> Hi! >>>>>>>> >>>>>>>>> 2016-12-03 1:26 GMT+09:00 Rob Herring <robh@kernel.org>: >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> (Plan A) >>>>>>>>>>> "denali,socfpga-nand" (for Altera SOCFPGA variant) >>>>>>>>>>> "denali,uniphier-nand-v1" (for old Socionext UniPhier family variant) >>>>>>>>>>> "denali,uniphier-nand-v2" (for new Socionext UniPhier family variant) >>>>>>>>>>> >>>>>>>>>>> (Plan B) >>>>>>>>>>> "altera,denali-nand" (for Altera SOCFPGA variant) >>>>>>>>>>> "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant) >>>>>>>>>>> "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant) >>>>>>>>> >>>>>>>>>> Let the Altera folks worry about their stuff. At least for soft IP in >>>>>>>>>> FPGA, it's a bit of a special case. The old string can remain as bad >>>>>>>>>> as it is. >>>>>>>>> >>>>>>>>> >>>>>>>>> Hmm, I am not sure if this IP would fit in FPGA >>>>>>>>> (to use it along with NIOS-II?) >>>>>>>>> >>>>>>>>> (even if it happened, nothing of this IP would be customizable on users' side. >>>>>>>>> When buying the IP, SoC vendors submit a list of desired features. >>>>>>>>> Denali (now Cadence) generates the RTL according to the configuration sheet. >>>>>>>>> The function is fixed at this point. So, generic compatible would be >>>>>>>>> useless anyway.) >>>>>>>>> >>>>>>>>> >>>>>>>>> If we are talking about SOCFPGA, >>>>>>>>> SOCFPGA is not only FPGA. Rather "SOC" + "FPGA". >>>>>>>>> It consists of two parts: >>>>>>>>> [1] SOC part (Cortex-A9 + various hard-wired peripherals such UART, >>>>>>>>> USB, SD, NAND, ...) >>>>>>>>> [2] FPGA part (User design logic) >>>>>>>>> >>>>>>>>> The Denali NAND controller is included in [1]. >>>>>>>>> So, as far as we talk about the Denali on SOCFPGA, >>>>>>>>> it is as hard-wired as Intel, Socionext's ones. >>>>>>>> >>>>>>>> That's correct, the Denali NAND IP in altera socfpga is a hardware >>>>>>>> block. You can make it available to the fabric too, but by default >>>>>>>> it's used by the ARM part of the chip, so for this discussion, you >>>>>>>> can forget that the FPGA part exists altogether. >>>>>>>> >>>>>>>> I would be in favor of plan B, since it seems to be the more often >>>>>>>> taken approach. A nice example is ci-hdrc: >>>>>>>> >>>>>>>> $ git grep compatible drivers/usb/chipidea/ >>>>>>>> >>>>>>>>>> I simply would do "socionext,uniphier-v5b-nand" (and v5a). >>>>>>>>>> The fact that it is denali is part of the documentation. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Let me think about this. >>>>>>>>> >>>>>>>>> Socionext bought two version of Denali IP, >>>>>>>>> and we are now re-using the newer one (v5b) for several SoCs. >>>>>>>>> Socionext has some more product lines other than Uniphier SoC family, >>>>>>>>> perhaps wider re-use might happen in the future. >>>>>>>>> >>>>>>>>> At first, I included "uniphier" in compatible, but I am still wondering >>>>>>>>> if such a specific string is good or not. >>>>>>>>> >>>>>>>>> Also, comments from Altera engineers are appreciated. >>>>>>> >>>>>>> Sorry, it's taken me a while to add comments. My altera email is very spotty now >>>>>>> that the Intel merge is completed. Please use dinguyen@kernel.org for any future >>>>>>> communications. >>>>>>> >>>>>>> Yes, everything that is said so far for the NAND controller on the >>>>>>> SoCFPGA is correct. I added the binding for the controller a while >>>>>>> back, but unfortunately, we never added the NAND interface to the >>>>>>> devkit, so we did not do much in terms of enabling it. >>>>>>> >>>>>>> I think the only SoCFPGA board I know that has the NAND interface active is >>>>>>> the TRCom board, but I have never seen that board. >>>>>>> >>>>>>> I don't have any strong opinions on this matter, just as long as the >>>>>>> original binding >>>>>>> "denali,denali-nand-dt" is kept, and I think Rob was ok with keeping >>>>>>> that binding. >>>>>>> >>>>>> >>>>>> I am proposing to add "altera,denali-nand" for Altera. >>>>>> For what, do you need the generic compatible? >>>>>> This IP has no default for it to fallback to. >>>>> >>>>> IMO just for compatibility reasons with old DTs . >>>> >>>> We generally contribute for >>>> a "working driver" (at least, should be functional to some extent) >>>> and "DT binding" bundled together. >>>> >>>> However, Altera upstreamed the DT binding first >>>> (then some parts of the DT binding turned out wrong), >>>> but they did not upstream needed driver changes in the end. >>>> >>>> So, the mainline driver has never worked on SOCFPGA, right? >>> >>> Most likely it never worked, yes. >>> >> >> Right, looking through our downstream support, we may need to upstream a >> few changes to make upstream driver work on SoCFPGA. >> >>>> Removing "denali,denali-nand-dt" is not breakage at all, >>>> so I do not owe anything to them, right? >>> >>> I don't think I'm really qualified to answer this one. But, there is >>> drivers/mtd/nand/denali_dt.c , which handles this compatible string >>> and it's documented in >>> Documentation/devicetree/bindings/mtd/denali-nand.txt, so doesn't that >>> make it part of the ABI ? I think we should >>> at least keep it as a fallback, that should be pretty harmless. >>> >> >> I would like to propose "altr,denali-nand" as the binding we use to support the >> driver going forward on SoCFPGA hardware. It's pretty much the same as >> "altera,denali-nand", just with the correct vendor prefix. > > Ah right, altr is the right prefix, thanks for pointing that out. > Still, wouldn't altr,socfpga-denali-nand be better ? I know it's > long, but it encodes the chip type , like ie. fsl,imx6q-usb . > Yes, that's fine. Dinh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt index 51fe195..cea46e2 100644 --- a/Documentation/devicetree/bindings/mtd/denali-nand.txt +++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt @@ -1,13 +1,19 @@ * Denali NAND controller Required properties: - - compatible : should be "denali,denali-nand-dt" + - compatible : should be one of the following: + "denali,denali-nand-dt" + "denali,denali-nand-uniphier-v5a" + "denali,denali-nand-uniphier-v5b" - reg : should contain registers location and length for data and reg. - reg-names: Should contain the reg names "nand_data" and "denali_reg" - interrupts : The interrupt number. Optional properties: - - nand-ecc-step-size: must be 512 or 1024. If not specified, default to 512. + - nand-ecc-step-size: must be 512 or 1024. If not specified, default to: + 512 for "denali,denali-nand-dt" + 1024 for "denali,denali-nand-uniphier-v5a" + 1024 for "denali,denali-nand-uniphier-v5b" see nand.txt for details. - nand-ecc-strength: see nand.txt for details - nand-ecc-maximize: see nand.txt for details diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c index aa1e032..b411889 100644 --- a/drivers/mtd/nand/denali_dt.c +++ b/drivers/mtd/nand/denali_dt.c @@ -34,10 +34,37 @@ struct denali_dt_data { unsigned int caps; }; +static const int denali_uniphier_ecc_strength[] = { + 24, 16, 8, 0, +}; + +static const struct denali_dt_data denali_uniphier_v5a_data = { + .ecc_strength_avail = denali_uniphier_ecc_strength, + .caps = DENALI_CAPS_DMA_64BIT | + DENALI_CAPS_ECC_SIZE_1024, +}; + +static const struct denali_dt_data denali_uniphier_v5b_data = { + .ecc_strength_avail = denali_uniphier_ecc_strength, + .caps = DENALI_CAPS_DMA_64BIT | + DENALI_CAPS_NEW_N_BANKS_FORMAT | + DENALI_CAPS_ECC_SIZE_1024, +}; + static const struct of_device_id denali_nand_dt_ids[] = { - { .compatible = "denali,denali-nand-dt" }, - { /* sentinel */ } - }; + { + .compatible = "denali,denali-nand-dt", + }, + { + .compatible = "denali,denali-nand-uniphier-v5a", + .data = &denali_uniphier_v5a_data, + }, + { + .compatible = "denali,denali-nand-uniphier-v5b", + .data = &denali_uniphier_v5b_data, + }, + { /* sentinel */ } +}; MODULE_DEVICE_TABLE(of, denali_nand_dt_ids);
Add two compatible strings for UniPhier SoCs. The revision register on both shows revision 5.0, but they are different hardware. Features: - DMA engine with 64 bit physical address support - 1024 byte ECC step size - 8 / 16 / 24 bit ECC strength - The n_banks format depends on SoC Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> --- .../devicetree/bindings/mtd/denali-nand.txt | 10 +++++-- drivers/mtd/nand/denali_dt.c | 33 ++++++++++++++++++++-- 2 files changed, 38 insertions(+), 5 deletions(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html