Using a generic upstream driver with a custom NAND controller

Using a generic upstream driver with a custom NAND controller

[Mason]

Hello,

I'm porting a 3.4 kernel to a 4.4 kernel, and I'm having a hard time
with the NAND driver, because it made changes to "core" files, and
these core files have possibly changed a lot between the 20 releases.

 drivers/mtd/Kconfig                                            |    3 +-
 drivers/mtd/chips/cfi_cmdset_0002.c                            |  127 ++-
 drivers/mtd/devices/m25p80.c                                   |  100 +-
 drivers/mtd/maps/Kconfig                                       |   11 +-
 drivers/mtd/maps/physmap.c                                     |  195 ++++
 drivers/mtd/mtdchar.c                                          |   54 ++
 drivers/mtd/nand/Kconfig                                       |    8 +
 drivers/mtd/nand/Makefile                                      |    1 +
 drivers/mtd/nand/nand_base.c                                   |    6 +-
 drivers/mtd/nand/nand_ids.c                                    |   18 +
 drivers/mtd/nand/foobar_nand.c                                 | 1903 ++++++++++++++++++++

I assume a regular driver is not supposed to make changes to
(some of) these core files?

As far as I understand, the NAND controller is custom (it's not a
hardware IP block sold to SoC manufacturers) but I think there is
some kind of standard (ONFI?) that all controllers adhere to?
(Kind of like USB has generic EHCI.)

Is there some generic driver upstream that I could try to see if
it works with this controller?

Note: the SoC is using these chips:
nand: Micron NAND 512MiB 3,3V 8-bit
nand: 512MiB, SLC, page size: 2048, OOB size: 64

Regards.

Re: Using a generic upstream driver with a custom NAND controller

[Steve deRosier]

Hi Mason,



On Tue, Jan 19, 2016 at 11:30 AM, Mason <slash.tmp@free.fr> wrote:
> Hello,
>
> Is there some generic driver upstream that I could try to see if
> it works with this controller?
>
> Note: the SoC is using these chips:
> nand: Micron NAND 512MiB 3,3V 8-bit
> nand: 512MiB, SLC, page size: 2048, OOB size: 64
>

That's a common chip configuration. Calling out the chip ID
specifically might also be of some help. What you have to do is enable
the driver for your NAND controller, the NAND chip isn't that
relevant. Nearly every mainline SoC or processor would have a driver.
If it's truly custom, then in my opinion, you're going to need to
write a driver. Though it should be provided to you by your SoC
vendor. Shame on them for not building the driver right and
upstreaming it.

Odds are they didn't create one from scratch however. That would be
truly strange. Likely they took a stock one and made some custom
changes. You might be able to ask what it was based on and make
changes to the base driver.

While ONFI is a standard way for the flash chips to identify
themselves to a controller and get it to auto-configure, my
understanding is you'd still need a driver for the controller itself
and there's no such thing as a generic controller. Then again I'm
hardly an expert on flash controllers specifically, I usually only
work with the Atmel chips which have a well-supported mainline driver.

Good luck!
- Steve

Re: Using a generic upstream driver with a custom NAND controller

[Mason]

On 19/01/2016 22:15, Steve deRosier wrote:

> Mason wrote:
>
>> Is there some generic driver upstream that I could try to see if
>> it works with this controller?
>>
>> Note: the SoC is using these chips:
>> nand: Micron NAND 512MiB 3,3V 8-bit
>> nand: 512MiB, SLC, page size: 2048, OOB size: 64
> 
> That's a common chip configuration. Calling out the chip ID
> specifically might also be of some help.

<confused> IIUC, /which NAND chips/ are connected to the
controller is not really relevant. What kind of info would
the chip ID give me?

> What you have to do is enable
> the driver for your NAND controller, the NAND chip isn't that
> relevant. Nearly every mainline SoC or processor would have a driver.

Note: the SoC isn't mainline yet as I'm the one trying to
make that happen (I work for the SoC manufacturer BTW).

The problem is that all our drivers were written in the
2.6.x era, and porting them to 4.4 is really involved
because

1) the APIs have often significantly changed (this is an issue
for all out-of-tree drivers)

2) the coders in my company will often pick the quick and dirty
solution, which often means altering core files, instead of
using registration APIs, custom call-backs, or what-have-you.

The result is that I get a deluge of conflicts just rebasing
the driver, and that's even before I get to the API issues.

> If it's truly custom, then in my opinion, you're going to need to
> write a driver. Though it should be provided to you by your SoC
> vendor. Shame on them for not building the driver right and
> upstreaming it.

(Maybe you can help me find convincing arguments why upstreaming
is good. The logic around here is "the hardware is custom, no one
will benefit from having the driver, no point in sharing".)

Anyway, I may not have been clear about this, but there /is/
a driver for this custom controller (it's not an IP block from
a third-party vendor). The driver works with the 3.4 kernel.

In my original message, I provided the diff between vanilla
3.4 and our custom 3.4 (for the drivers/mtd directory).

 drivers/mtd/Kconfig                                            |    3 +-
 drivers/mtd/chips/cfi_cmdset_0002.c                            |  127 ++-
 drivers/mtd/devices/m25p80.c                                   |  100 +-
 drivers/mtd/maps/Kconfig                                       |   11 +-
 drivers/mtd/maps/physmap.c                                     |  195 ++++
 drivers/mtd/mtdchar.c                                          |   54 ++
 drivers/mtd/nand/Kconfig                                       |    8 +
 drivers/mtd/nand/Makefile                                      |    1 +
 drivers/mtd/nand/nand_base.c                                   |    6 +-
 drivers/mtd/nand/nand_ids.c                                    |   18 +
 drivers/mtd/nand/foobar_nand.c                                 | 1903 ++++++++++++++++++++

So foobar_nand.c is the NAND driver for this SoC.
The problem comes from the modifications "around" the driver,
in the "core" source files.

I guess I could make a zero-order approximation that
all these changes are unnecessary, and just port the
main driver code. But I have a feeling that won't work.

> Odds are they didn't create one from scratch however. That would be
> truly strange. Likely they took a stock one and made some custom
> changes. You might be able to ask what it was based on and make
> changes to the base driver.

That's a good idea. Although I fear it was indeed written
from scratch, since the controller is custom-made.

Anyway, I'm open to comments and suggestions about this issue.
I'm sure a lot of you have had to deal with these situations.

Regards.

Re: Using a generic upstream driver with a custom NAND controller

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

On Thu, 2016-01-21 at 15:05 +0100, Mason wrote:
> (Maybe you can help me find convincing arguments why upstreaming
> is good.

The rest of your own email is, surely, precisely such an argument?

If you attempt to submit the core changes upstream, then either we help
you find a better way to do things so that those changes *aren't*
needed, or we merge them so that all you need to do is a minor update
to the driver itself (as you hoped).

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: Using a generic upstream driver with a custom NAND controller

[Mason]

On 21/01/2016 15:12, David Woodhouse wrote:

> Mason wrote:
>
>> Maybe you can help me find convincing arguments why upstreaming
>> is good.
> 
> The rest of your own email is, surely, precisely such an argument?

Indeed :-)

Problem is: I tried that argument, and it fell on deaf ears.
"There's none so deaf as those who will not hear."

> If you attempt to submit the core changes upstream, then either we help
> you find a better way to do things so that those changes *aren't*
> needed, or we merge them so that all you need to do is a minor update
> to the driver itself (as you hoped).

Great idea. I'll send in the diff tomorrow. I hope the code
won't give the maintainers a heart attack...

Regards.

Re: Using a generic upstream driver with a custom NAND controller

[Ricard Wanderlof]

On Thu, 21 Jan 2016, Mason wrote:

> (Maybe you can help me find convincing arguments why upstreaming is 
> good. The logic around here is "the hardware is custom, no one will 
> benefit from having the driver, no point in sharing".)

One way to look at is in terms of maintenance. If you do a quick and dirty 
hack, it must be maintained when new kernel versions are released, i.e. 
someone has to spend company time to keep the quick and dirty hack 
working in the next product, and the next and the next. Since it's a hack 
to start with, it's hard to predict how much time is needed.

If the driver is upstreamed and uses well-known API:s, oftentimes it can 
be maintained in the ordinary course of kernel maintenence, and the impact 
on company time is minimal, not to mention more predictable. True, some 
changes in the framework might necessitate driver changes, but these will 
mostly be much smaller than in the first case, and there will be other 
drivers which have gone through the same change so you can get inspiration 
from others.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30