From: mike@compulab•co.il (Mike Rapoport)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 01/20] mtd: pxa3xx_nand: refuse the flash definition get from platform
Date: Tue, 25 May 2010 13:21:46 +0300 [thread overview]
Message-ID: <4BFBA4BA.9020502@compulab.co.il> (raw)
In-Reply-To: <AANLkTil1mq5FBePSexz80DyT80DGqshqyJEi6Pfp0kV7@mail.gmail.com>
Lei Wen wrote:
> On Mon, May 24, 2010 at 9:21 PM, Mike Rapoport <mike@compulab•co.il> wrote:
>> Lei Wen wrote:
>>> Hi Mike,
>>>
>>> On Mon, May 24, 2010 at 7:00 PM, Mike Rapoport <mike@compulab•co.il>
>>> wrote:
>>>> Hi Lei,
>>>>
>>>> Lei Wen wrote:
>>>>> Hi Mike,
>>>>>
>>>> 2) I don't like hadrcoding of NAND parameters into the driver. You remove
>>>> *deprecetad* CONFIG_MTD_NAND_PXA3xx_BUILTIN configuration option and
>>>> instead
>>>> you enforce use of built-in definitions. The driver in its current state
>>>> is
>>>> robust enough to allow platforms to define optimized NAND timings either
>>>> in
>>>> the bootloader or in the kernel. If you don't like that multiple
>>>> platforms
>>>> define the same flash chip create an enumeration of built-in types and
>>>> let
>>>> platforms to use this enumeration to select the NAND chip. But, anyway,
>>>> there should be a fallback mode that will support NAND chips that are not
>>>> defined in the driver, probably with suboptimal timings.
>>> Original driver also use hardcoding. And in bootloader, this timing
>>> parameter is also hard coding.
>>> We cannot deduce a parameter set only from the nand id, that is why we
>>> need a table to preset it.
>>> If one nand chip is not listed in that table, the chip id would still
>>> be printed out, so that we can do something for that.
>>> If we encourage people to continue on this, we would not able to
>>> really "driver" that nand.
>> Currently pxa3xx-nand has three operational modes:
>> - use NAND parameters supplied by the platform
>> - use presets configured by the bootloader chain
>> - use built-in NAND parameters, marked as deprecated in favor of the first
>> two
>> You remove the first two modes completely and require that each and every
>> NAND chip used on pxa3xx based platform will be added to the driver. This
>> way you make the driver less robust and harder to use for platform
>> developers, not mentioning you're breaking the existing platforms.
>> In my opinion, the driver *may* support built-in definitions for certain
>> NAND flashes and *must* support configuration of the NAND parameters by the
>> platform code and bootloader.
>>
>
> Hi Mike,
>
> Well... I would submit another patch set which would reserve a way
> that platform could pass its parameter setting.
> Like specify the certain type of nand chip parameter for each chip
> select. Is that ok for you?
>
> For bootloader pass parameter method, I think this way should be
> dropped... For there is attributed which we could not tell from
> registers...
> What do you think of this?
Can you please elaborate what are the attributes that cannot be detected?
> Thanks,
> Lei
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2010-05-25 10:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-14 6:11 [PATCH 01/20] mtd: pxa3xx_nand: refuse the flash definition get from platform Haojian Zhuang
2010-05-14 11:09 ` Marc Kleine-Budde
2010-05-24 7:31 ` Mike Rapoport
2010-05-24 8:27 ` Lei Wen
2010-05-24 11:00 ` Mike Rapoport
2010-05-24 11:53 ` Lei Wen
2010-05-24 12:11 ` Marek Vasut
2010-05-24 12:31 ` Lei Wen
2010-05-24 13:05 ` Marek Vasut
2010-05-24 13:18 ` Lei Wen
2010-05-24 13:21 ` Mike Rapoport
2010-05-24 13:40 ` Lei Wen
2010-05-24 15:44 ` Daniel Mack
2010-05-25 10:21 ` Mike Rapoport [this message]
2010-05-25 12:18 ` Marek Vasut
2010-05-25 13:01 ` Lei Wen
2010-05-25 13:21 ` Eric Miao
2010-05-26 13:35 ` Lei Wen
2010-05-26 9:57 ` Mike Rapoport
2010-05-26 13:42 ` Lei Wen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BFBA4BA.9020502@compulab.co.il \
--to=mike@compulab$(echo .)co.il \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox