From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
To: Antoine Tenart <antoine.tenart@free-electrons.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: zmxu@marvell.com, boris.brezillon@free-electrons.com,
Robert Jarzmik <robert.jarzmik@free.fr>,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
jszhang@marvell.com, computersforpeace@gmail.com,
dwmw2@infradead.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 04/10] mtd: pxa3xx_nand: rework flash detection and timing setup
Date: Thu, 30 Apr 2015 19:52:12 +0200 [thread overview]
Message-ID: <55426BCC.1050507@gmail.com> (raw)
In-Reply-To: <20150430143106.GE4433@kwain>
On 30.04.2015 16:31, Antoine Tenart wrote:
> On Thu, Apr 16, 2015 at 01:59:32PM -0300, Ezequiel Garcia wrote:
>> On 04/16/2015 10:41 AM, Sebastian Hesselbarth wrote:
>>
>>> All we need is a function to convert sdr_timings to sane driver
>>> timings. And we really need to split this patch into tiny pieces
>>> otherwise it is not reviewable - or at least I need a full overview
>>> about the driver first.
>>>
>>
>> I think that's a bit of a different issue. This patch seems to be doing
>> two things: it removes the in-driver flash detection *and* reworks
>> timing setup.
>>
>> How about we split this in two or even three patches? Along these lines:
>> 1) introduce timing helpers, 2) rework timing setup, 3) remove in-driver
>> flash detection. Not sure how feasible it is.
>
> That's quite difficult, as you cannot have 1) without having the changes
> made in 2). Flash detection and timing reworks are linked and I'm not
> sure we can have this split into 2 or 3 patches without having a state
> where the driver does not work.
Antoine,
functionally you are right. But splitting the patch into the three
pieces above will heavily reduce the diff-per-patch significantly.
For example, if you introduce 1) without using it, we can only look at
the helper. Then in 2) you actually use that helper and 3) will clean
the mess up.
BTW, I am fine with running the flash on mach-berlin boards with some
default timing for now until we worked out how mtd will deal with
protocol and array timings.
Sebastian
next prev parent reply other threads:[~2015-04-30 17:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-15 17:23 [PATCH v4 00/10] ARM: berlin: add nand support Antoine Tenart
2015-04-15 17:23 ` [PATCH v4 01/10] mtd: pxa3xx_nand: add a non mandatory ECC clock Antoine Tenart
2015-04-15 17:24 ` [PATCH v4 02/10] Documentation: bindings: document the clocks for pxa3xx-nand Antoine Tenart
2015-04-15 17:24 ` [PATCH v4 03/10] mtd: pxa3xx_nand: add a default chunk size Antoine Tenart
2015-04-15 17:24 ` [PATCH v4 04/10] mtd: pxa3xx_nand: rework flash detection and timing setup Antoine Tenart
2015-04-15 19:11 ` Sebastian Hesselbarth
2015-04-16 13:10 ` Ezequiel Garcia
2015-04-16 13:41 ` Sebastian Hesselbarth
2015-04-16 16:59 ` Ezequiel Garcia
2015-04-17 19:52 ` Robert Jarzmik
2015-04-30 14:31 ` Antoine Tenart
2015-04-30 17:52 ` Sebastian Hesselbarth [this message]
2015-04-15 17:24 ` [PATCH v4 05/10] mtd: nand: add Samsung K9GBG08U0A-M to nand_ids table Antoine Tenart
2015-04-15 21:38 ` Sebastian Hesselbarth
2015-04-15 17:24 ` [PATCH v4 06/10] mtd: pxa3xx_nand: add support for the Marvell Berlin nand controller Antoine Tenart
2015-04-15 17:24 ` [PATCH v4 07/10] Documentation: bindings: add the Berlin nand controller compatible Antoine Tenart
2015-04-15 17:24 ` [PATCH v4 08/10] mtd: nand: let Marvell Berlin SoCs select the pxa3xx driver Antoine Tenart
2015-04-15 17:24 ` [PATCH v4 09/10] ARM: berlin: add BG2Q node for the nand Antoine Tenart
2015-04-15 17:24 ` [PATCH v4 10/10] ARM: berlin: enable flash on the BG2Q DMP Antoine Tenart
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=55426BCC.1050507@gmail.com \
--to=sebastian.hesselbarth@gmail.com \
--cc=antoine.tenart@free-electrons.com \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ezequiel.garcia@free-electrons.com \
--cc=jszhang@marvell.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=robert.jarzmik@free.fr \
--cc=zmxu@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).