Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
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 wrote: >>> On 12/05/2016 05:10 AM, Masahiro Yamada wrote: Hi Marek, 2016-12-05 12:44 GMT+09:00 Marek Vasut : > On 12/05/2016 04:30 AM, Masahiro Yamada wrote: >> Hi Dinh, >> >> >> 2016-12-04 7:08 GMT+09:00 Dinh Nguyen : >>> Hi, >>> >>> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut >>> wrote: On 12/03/2016 03:41 AM, Masahiro Yamada wrote: > Hi Rob, Hi! > 2016-12-03 1:26 GMT+09:00 Rob Herring : > >>> >>> >>> (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 dingu...@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, A
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
On 12/05/2016 09:51 PM, Dinh Nguyen wrote: > On Sun, Dec 4, 2016 at 10:22 PM, Marek Vasut wrote: >> On 12/05/2016 05:10 AM, Masahiro Yamada wrote: >>> Hi Marek, >>> >>> >>> 2016-12-05 12:44 GMT+09:00 Marek Vasut : On 12/05/2016 04:30 AM, Masahiro Yamada wrote: > Hi Dinh, > > > 2016-12-04 7:08 GMT+09:00 Dinh Nguyen : >> Hi, >> >> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut >> wrote: >>> On 12/03/2016 03:41 AM, Masahiro Yamada wrote: Hi Rob, >>> >>> Hi! >>> 2016-12-03 1:26 GMT+09:00 Rob Herring : >> >> >> (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 dingu...@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 mainli
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
On Sun, Dec 4, 2016 at 10:22 PM, Marek Vasut wrote: > On 12/05/2016 05:10 AM, Masahiro Yamada wrote: >> Hi Marek, >> >> >> 2016-12-05 12:44 GMT+09:00 Marek Vasut : >>> On 12/05/2016 04:30 AM, Masahiro Yamada wrote: Hi Dinh, 2016-12-04 7:08 GMT+09:00 Dinh Nguyen : > Hi, > > On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut wrote: >> On 12/03/2016 03:41 AM, Masahiro Yamada wrote: >>> Hi Rob, >> >> Hi! >> >>> 2016-12-03 1:26 GMT+09:00 Rob Herring : >>> > > > (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 dingu...@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
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
On 12/05/2016 05:10 AM, Masahiro Yamada wrote: > Hi Marek, > > > 2016-12-05 12:44 GMT+09:00 Marek Vasut : >> On 12/05/2016 04:30 AM, Masahiro Yamada wrote: >>> Hi Dinh, >>> >>> >>> 2016-12-04 7:08 GMT+09:00 Dinh Nguyen : Hi, On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut wrote: > On 12/03/2016 03:41 AM, Masahiro Yamada wrote: >> Hi Rob, > > Hi! > >> 2016-12-03 1:26 GMT+09:00 Rob Herring : >> (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 dingu...@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/d
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
Hi Marek, 2016-12-05 12:44 GMT+09:00 Marek Vasut : > On 12/05/2016 04:30 AM, Masahiro Yamada wrote: >> Hi Dinh, >> >> >> 2016-12-04 7:08 GMT+09:00 Dinh Nguyen : >>> Hi, >>> >>> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut wrote: On 12/03/2016 03:41 AM, Masahiro Yamada wrote: > Hi Rob, Hi! > 2016-12-03 1:26 GMT+09:00 Rob Herring : > >>> >>> >>> (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 dingu...@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
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
On 12/05/2016 04:30 AM, Masahiro Yamada wrote: > Hi Dinh, > > > 2016-12-04 7:08 GMT+09:00 Dinh Nguyen : >> Hi, >> >> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut wrote: >>> On 12/03/2016 03:41 AM, Masahiro Yamada wrote: Hi Rob, >>> >>> Hi! >>> 2016-12-03 1:26 GMT+09:00 Rob Herring : >> >> >> (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 dingu...@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 . I'm also for "altera,denali-nand" or maybe "altera,socfpga-denali-nand" to be more precise ? -- Best regards, Marek Vasut
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
Hi Dinh, 2016-12-04 7:08 GMT+09:00 Dinh Nguyen : > Hi, > > On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut wrote: >> On 12/03/2016 03:41 AM, Masahiro Yamada wrote: >>> Hi Rob, >> >> Hi! >> >>> 2016-12-03 1:26 GMT+09:00 Rob Herring : >>> > > > (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 dingu...@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
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
Hi, On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut wrote: > On 12/03/2016 03:41 AM, Masahiro Yamada wrote: >> Hi Rob, > > Hi! > >> 2016-12-03 1:26 GMT+09:00 Rob Herring : >> (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 dingu...@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
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
On 12/03/2016 03:41 AM, Masahiro Yamada wrote: > Hi Rob, Hi! > 2016-12-03 1:26 GMT+09:00 Rob Herring : > >>> >>> >>> (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
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
Hi Rob, 2016-12-03 1:26 GMT+09:00 Rob Herring : >> >> >> (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. > 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. -- Best Regards Masahiro Yamada
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
On Thu, Dec 1, 2016 at 8:54 PM, Masahiro Yamada wrote: > Hi Rob, > (+CC Dinh) > > 2016-12-02 1:05 GMT+09:00 Rob Herring : >> 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 >>> --- >>> >>> .../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.) Right. We do have some IP vendor strings, but they are usually fallbacks. Sometimes, I guess they are useful, but IMO over time they prove to not be useful. > 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) 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. I simply would do "socionext,uniphier-v5b-nand" (and v5a). The fact that it is denali is part of the documentation. Rob
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
Hi Rob, (+CC Dinh) 2016-12-02 1:05 GMT+09:00 Rob Herring : > 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 >> --- >> >> .../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
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
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 > --- > > .../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
