From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
To: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
Antoine Tenart <antoine.tenart@free-electrons.com>,
dwmw2@infradead.org, computersforpeace@gmail.com
Cc: zmxu@marvell.com, boris.brezillon@free-electrons.com,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
jszhang@marvell.com, Robert Jarzmik <robert.jarzmik@free.fr>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 04/10] mtd: pxa3xx_nand: rework flash detection and timing setup
Date: Thu, 16 Apr 2015 15:41:34 +0200 [thread overview]
Message-ID: <552FBC0E.20004@gmail.com> (raw)
In-Reply-To: <552FB4DF.1030403@free-electrons.com>
On 04/16/2015 03:10 PM, Ezequiel Garcia wrote:
> On 04/15/2015 04:11 PM, Sebastian Hesselbarth wrote:
>> On 15.04.2015 19:24, Antoine Tenart wrote:
>>> Rework the pxa3xx_nand driver to allow using functions exported by the
>>> nand framework to detect the flash and to configure the timings.
>>>
>>> Because this driver supports some non-ONFI devices, we also keep the
>>> custom timing setup of this driver so these devices won't break.
>>>
>>> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
>>> ---
>> [...]
>> How about we get rid of the driver specific timings completely
>> and pick up the best onfi timing match instead? The nand_ids table
>> allows for a default_onfi_timing parameter even if onfi itself is
>> not supported.
>>
>> For generic flash, i.e. no specific entry in the nand_ids table,
>> we either choose onfi mode 0 (most conservative) or an even slower
>> one.
>>
>
> I think Robert mentioned [1] that using "ONFI default timings" on
> non-ONFI devices didn't work for him.
>
> [1] https://lkml.org/lkml/2015/3/8/124
Ok, I see. But there is still the option to pass board specific
timings with driver's platform_data. We could use
(a) pdata timings if passed
(b) onfi timings if available
(c) equivalent onfi timings if set
(d) conservative equivalent onfi timings otherwise
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.
Also, as soon as Robert moves pxa3xx boards fully to DT, we'll loose
the pdata timings option above. *sigh*
Thoughts?
Sebastian
WARNING: multiple messages have this Message-ID (diff)
From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 04/10] mtd: pxa3xx_nand: rework flash detection and timing setup
Date: Thu, 16 Apr 2015 15:41:34 +0200 [thread overview]
Message-ID: <552FBC0E.20004@gmail.com> (raw)
In-Reply-To: <552FB4DF.1030403@free-electrons.com>
On 04/16/2015 03:10 PM, Ezequiel Garcia wrote:
> On 04/15/2015 04:11 PM, Sebastian Hesselbarth wrote:
>> On 15.04.2015 19:24, Antoine Tenart wrote:
>>> Rework the pxa3xx_nand driver to allow using functions exported by the
>>> nand framework to detect the flash and to configure the timings.
>>>
>>> Because this driver supports some non-ONFI devices, we also keep the
>>> custom timing setup of this driver so these devices won't break.
>>>
>>> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
>>> ---
>> [...]
>> How about we get rid of the driver specific timings completely
>> and pick up the best onfi timing match instead? The nand_ids table
>> allows for a default_onfi_timing parameter even if onfi itself is
>> not supported.
>>
>> For generic flash, i.e. no specific entry in the nand_ids table,
>> we either choose onfi mode 0 (most conservative) or an even slower
>> one.
>>
>
> I think Robert mentioned [1] that using "ONFI default timings" on
> non-ONFI devices didn't work for him.
>
> [1] https://lkml.org/lkml/2015/3/8/124
Ok, I see. But there is still the option to pass board specific
timings with driver's platform_data. We could use
(a) pdata timings if passed
(b) onfi timings if available
(c) equivalent onfi timings if set
(d) conservative equivalent onfi timings otherwise
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.
Also, as soon as Robert moves pxa3xx boards fully to DT, we'll loose
the pdata timings option above. *sigh*
Thoughts?
Sebastian
WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
To: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
Antoine Tenart <antoine.tenart@free-electrons.com>,
dwmw2@infradead.org, computersforpeace@gmail.com
Cc: boris.brezillon@free-electrons.com, zmxu@marvell.com,
jszhang@marvell.com, linux-arm-kernel@lists.infradead.org,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Robert Jarzmik <robert.jarzmik@free.fr>
Subject: Re: [PATCH v4 04/10] mtd: pxa3xx_nand: rework flash detection and timing setup
Date: Thu, 16 Apr 2015 15:41:34 +0200 [thread overview]
Message-ID: <552FBC0E.20004@gmail.com> (raw)
In-Reply-To: <552FB4DF.1030403@free-electrons.com>
On 04/16/2015 03:10 PM, Ezequiel Garcia wrote:
> On 04/15/2015 04:11 PM, Sebastian Hesselbarth wrote:
>> On 15.04.2015 19:24, Antoine Tenart wrote:
>>> Rework the pxa3xx_nand driver to allow using functions exported by the
>>> nand framework to detect the flash and to configure the timings.
>>>
>>> Because this driver supports some non-ONFI devices, we also keep the
>>> custom timing setup of this driver so these devices won't break.
>>>
>>> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
>>> ---
>> [...]
>> How about we get rid of the driver specific timings completely
>> and pick up the best onfi timing match instead? The nand_ids table
>> allows for a default_onfi_timing parameter even if onfi itself is
>> not supported.
>>
>> For generic flash, i.e. no specific entry in the nand_ids table,
>> we either choose onfi mode 0 (most conservative) or an even slower
>> one.
>>
>
> I think Robert mentioned [1] that using "ONFI default timings" on
> non-ONFI devices didn't work for him.
>
> [1] https://lkml.org/lkml/2015/3/8/124
Ok, I see. But there is still the option to pass board specific
timings with driver's platform_data. We could use
(a) pdata timings if passed
(b) onfi timings if available
(c) equivalent onfi timings if set
(d) conservative equivalent onfi timings otherwise
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.
Also, as soon as Robert moves pxa3xx boards fully to DT, we'll loose
the pdata timings option above. *sigh*
Thoughts?
Sebastian
next prev parent reply other threads:[~2015-04-16 13:41 UTC|newest]
Thread overview: 57+ 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 ` Antoine Tenart
2015-04-15 17:23 ` 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:23 ` Antoine Tenart
2015-04-15 17:23 ` 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 ` Antoine Tenart
2015-04-15 17:24 ` 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 ` Antoine Tenart
2015-04-15 17:24 ` 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 17:24 ` Antoine Tenart
2015-04-15 17:24 ` Antoine Tenart
2015-04-15 19:11 ` Sebastian Hesselbarth
2015-04-15 19:11 ` Sebastian Hesselbarth
2015-04-15 19:11 ` Sebastian Hesselbarth
2015-04-16 13:10 ` Ezequiel Garcia
2015-04-16 13:10 ` Ezequiel Garcia
2015-04-16 13:10 ` Ezequiel Garcia
2015-04-16 13:41 ` Sebastian Hesselbarth [this message]
2015-04-16 13:41 ` Sebastian Hesselbarth
2015-04-16 13:41 ` Sebastian Hesselbarth
2015-04-16 16:59 ` Ezequiel Garcia
2015-04-16 16:59 ` Ezequiel Garcia
2015-04-16 16:59 ` Ezequiel Garcia
2015-04-17 19:52 ` Robert Jarzmik
2015-04-17 19:52 ` Robert Jarzmik
2015-04-17 19:52 ` Robert Jarzmik
2015-04-30 14:31 ` Antoine Tenart
2015-04-30 14:31 ` Antoine Tenart
2015-04-30 14:31 ` Antoine Tenart
2015-04-30 17:52 ` Sebastian Hesselbarth
2015-04-30 17:52 ` Sebastian Hesselbarth
2015-04-30 17:52 ` Sebastian Hesselbarth
2015-04-15 17:24 ` [PATCH v4 05/10] mtd: nand: add Samsung K9GBG08U0A-M to nand_ids table Antoine Tenart
2015-04-15 17:24 ` Antoine Tenart
2015-04-15 17:24 ` Antoine Tenart
2015-04-15 21:38 ` Sebastian Hesselbarth
2015-04-15 21:38 ` Sebastian Hesselbarth
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 ` Antoine Tenart
2015-04-15 17:24 ` 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 ` Antoine Tenart
2015-04-15 17:24 ` 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 ` Antoine Tenart
2015-04-15 17:24 ` 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 ` Antoine Tenart
2015-04-15 17:24 ` Antoine Tenart
2015-04-15 17:24 ` [PATCH v4 10/10] ARM: berlin: enable flash on the BG2Q DMP Antoine Tenart
2015-04-15 17:24 ` Antoine Tenart
2015-04-15 17:24 ` 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=552FBC0E.20004@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.