From: Christoph Fritz [mailto:chf.fr...@googlemail.com]
This patch adds bch8 ecc software fallback which is mostly used by
omap3s because they lack hardware elm support.
Fixes: 0611c41934ab35ce84dea34ab291897ad3cbc7be (ARM: OMAP2+: gpmc:
update gpmc_hwecc_bch_capable() for new platforms and ECC
Hi Roger,
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140709 05:39]:
Hi,
The following hardware modules/registers are meant for NAND controller driver
usage:
- NAND I/O control (NAND address, data, command registers)
- Prefetch/Write-post engine
- ECC/BCH
From: Quadros, Roger
Instead of hardcoding use the pre-calculated chip-ecc.steps for
configuring number of sectors to process with the BCH algorithm.
This also avoids unnecessary access to the ECC_CONFIG register in
omap_calculate_ecc_bch().
Signed-off-by: Roger Quadros rog...@ti.com
---
Hi Roger,
From: Quadros, Roger
Even though the ECC/BCH engine is meant for exclusive use by
the OMAP NAND controller, the ECC/BCH registers belong
to the GPMC controller's register space
Add omap_gpmc_ecc_configure_enable() and omap_gpmc_ecc_disable()
to manage the ECC engine. OMAP NAND driver
Roger,
From: Quadros, Roger
Don't access the ECC/BCH engine registers directly as they belong
to the GPMC controller's register space. Use the relevant
GPMC APIs instead.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/omap2.c | 191
From: Quadros, Roger
On 07/11/2014 10:27 AM, Gupta, Pekon wrote:
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140709 05:39]:
Hi,
The following hardware modules/registers are meant for NAND controller
driver
usage:
- NAND I/O control (NAND address, data
From: Quadros, Roger
On 07/11/2014 10:43 AM, Gupta, Pekon wrote:
From: Quadros, Roger
[...]
@@ -1176,6 +1172,7 @@ static int __maybe_unused
omap_calculate_ecc_bch(struct mtd_info
*mtd,
{
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info
Hi Cristoph,
From: Pekon Gupta pe...@ti.com
From: Christoph Fritz [mailto:chf.fr...@googlemail.com]
Most dt omap3 boards configure nand-ecc-opt as bch8. Due
to lack of hardware elm support, bch8 software implementation
gets set.
Since commit 0611c41934ab35ce84dea ARM: OMAP2+: gpmc: update
Hi Guido,
From: Guido Martínez
On Thu, Jun 26, 2014 at 03:40:44AM -0700, Tony Lindgren wrote:
* Pekon Gupta pe...@ti.com [140624 05:26]:
+
+gpmc {
+ ranges = 0 0 0 0x0100;/* address range = 16MB (minimum GPMC
partition) */
+ nand@0,0 {
+ status = disabled;
+
From: Tony Lindgren [mailto:t...@atomide.com]
* Gupta, Pekon pe...@ti.com [140627 14:08]:
From: Guido Martínez [mailto:gu...@vanguardiasur.com.ar]
On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
[...]
+gpmc {
+ ranges = 0 0 0 0x0100;/* address range = 16MB (minimum
From: Guido Martínez [mailto:gu...@vanguardiasur.com.ar]
On Tue, Jul 01, 2014 at 07:01:03AM +, Gupta, Pekon wrote:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
I don't think we need above patch.
Helper macro for_each_available_child_of_node internally takes
From: Ezequiel García [mailto:ezequ...@vanguardiasur.com.ar]
On 26 Jun 12:02 PM, Guido Martínez wrote:
Currently, child nodes of the gpmc node are iterated and probed
regardless of their 'status' property. This means adding 'status =
disabled;' has no effect.
This patch changes the iteration
Hi Daren, Guido,
From: Etheridge, Darren
On 06/26/2014 10:40 AM, Guido Martínez wrote:
I had some issues with this patch. Booting linux-next on a BeagleBone
Black with this exact LCD left me with an unusable white screen. Please
see below for some details.
On Tue, Jun 24, 2014 at 05:54:26PM
From: Guido Martínez [mailto:gu...@vanguardiasur.com.ar]
On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
[...]
+gpmc {
+ranges = 0 0 0 0x0100;/* address range = 16MB (minimum GPMC
partition) */
+nand@0,0 {
+status = disabled;
+reg = 0 0
From: Ezequiel Garcia [mailto:ezequ...@vanguardiasur.com.ar]
On 24 Jun 05:54 PM, Pekon Gupta wrote:
+gpmc {
+ranges = 0 0 0 0x0100;/* address range = 16MB (minimum GPMC
partition) */
+nand@0,0 {
+status = disabled;
+reg = 0 0 4; /* device IO
From: Jason Kridner [mailto:jkrid...@gmail.com]
On Mon, Jun 23, 2014 at 1:48 AM, Tony Lindgren t...@atomide.com wrote:
* Gupta, Pekon pe...@ti.com [140622 22:42]:
From: Tony Lindgren [mailto:t...@atomide.com]
[...]
Based on the recent discussions on the capes, it seems that nobody
wants
From: Ezequiel Garcia
On 24 Jun 05:54 PM, Pekon Gupta wrote:
This patch adds support for LCD4 cape as advertised on
http://elinux.org/CircuitCo:BeagleBone_LCD4
This cape has:
* 480x272 TFT-LCD panel
- LCD panel datasheet and timing information are sourced from [1]
- LCD backlight is
From: Jason Kridner [mailto:jkrid...@gmail.com]
On Tue, Jun 24, 2014 at 8:24 AM, Pekon Gupta pe...@ti.com wrote:
This patch adds support for LCD4 cape as advertised on
http://elinux.org/CircuitCo:BeagleBone_LCD4
[...]
diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts
Hi Tony,
Just reviving this thread for some information..
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, May 19, 2014 9:56 PM
To: Gupta, Pekon
Cc: linux-omap; Ezequiel Garcia; Stefan Roese; Javier Martinez Canillas;
Quadros, Roger
Subject: Re: [PATCH v7 1/4] ARM: dts: am335x-bone
Hi,
From: Jason Kridner [mailto:jkrid...@gmail.com]
On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon pe...@ti.com wrote:
From: Jason Kridner
[...]
* The devicetree sources, including the primary boot .dts files, will
eventually be removed from the kernel source tree. I'm not too sure if
and when
Hi Jason,
From: Jason Kridner
Adding devicetree and linux-arm-kernel lists based on feedback on IRC...
On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner jkrid...@gmail.com wrote:
I'd like to discuss moving our current library of cape devicetree
overlay sources into a single tree, including the
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140613 00:40]:
On 06/13/2014 10:18 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [140611 01:58]:
Since the Interrupt Events are used only by the NAND driver,
there is no point in managing the Interrupt
Hi Roger, Yegor,
From: Quadros, Roger
On 06/04/2014 10:45 PM, Yegor Yefremov wrote:
[...]
The 0x8000 address seems to be the beginning of NAND region:
ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
I've taken this example from am335x_evm.dts. I have tried to change
the mapping
Hi Yegor,
From: Gupta, Pekon
However, I don't suspect XIP boot here because even if CPU is detecting
garbage data while reading from 0x8000 it won't find a valid image
header there, and so XIP boot should have failed, and boot sequence
should fall back to MMC. It shouldn't have hung.
I
On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
[...]
The way ROM works for XIP boot is:
1) Set chip select 0 base address to 0x0800'
2) Read memory at 0x0800'
3) If something else other than 0x0 or ~0x0 is found, jump to
0x0800' and start executing.
Can you check to
From: Christoph Fritz [mailto:chf.fr...@googlemail.com]
Most dt omap3 boards configure nand-ecc-opt as bch8. Due
to lack of hardware elm support, bch8 software implementation
gets set.
Since commit 0611c41934ab35ce84dea ARM: OMAP2+: gpmc: update
gpmc_hwecc_bch_capable() for new platforms and ECC
Hi Brian,
From: Brian Norris
On Mon, May 19, 2014 at 01:24:41PM +0530, Pekon Gupta wrote:
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1201,6 +1219,41 @@ static int __maybe_unused
omap_calculate_ecc_bch(struct mtd_info
*mtd,
*ecc_code++ = ((bch_val1
From: Tony Lindgren [mailto:t...@atomide.com]
* Gupta, Pekon pe...@ti.com [140519 21:07]:
From: Tony Lindgren [mailto:t...@atomide.com]
* Pekon Gupta pe...@ti.com [140519 02:16]:
Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND
Hi Roger,
From: Quadros, Roger
On 05/20/2014 09:24 AM, Pekon Gupta wrote:
This patch enables 'wait-pin' monitoring in NAND driver if following
properties
are present under NAND DT node
gpmc,wait-pin = wait-pin number
gpmc,wait-on-read
gpmc,wait-on-write
As NAND generic framework
Hi Tony,
From: Tony Lindgren [mailto:t...@atomide.com]
* Pekon Gupta pe...@ti.com [140519 02:16]:
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -9,6 +9,7 @@
#include am33xx.dtsi
#include am335x-bone-common.dtsi
+#include am335x-bone-memory-cape.dts
From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com]
On 19 May 05:52 PM, Gupta, Pekon wrote:
From: Tony Lindgren [mailto:t...@atomide.com]
Based on the recent discussions on the capes, it seems that nobody
wants to implement toggling of the capes in u-boot. And as there
can
Hi Javier,
From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
Hello Pekon,
On Fri, May 16, 2014 at 9:07 PM, Pekon Gupta pe...@ti.com wrote:
This patch enables 'wait-pin' monitoring in NAND driver if following
properties
are present under NAND DT node
gpmc,wait-pin =
From: Robert Nelson [mailto:robertcnel...@gmail.com]
[...]
Since the capes are always some way tied with bb.org hardware, why
don't we put them up on https://github.com/beagleboard/ ?
am335x-capes.git ?
I envision, we should just mirror the base ./arch/arm/boot/dts/
directory (as someday the dts
From: Tony Lindgren [mailto:t...@atomide.com]
* Pekon Gupta pe...@ti.com [140519 02:16]:
Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
eMMC or NAND can be
Hi Roger,
From: Quadros, Roger
[...]
+gpmc {
+status = okay;
+pinctrl-names = default;
+pinctrl-0 = nand_flash_x8;
+ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+nand@0,0 {
+reg = 0 0 0x37c; /* device IO registers */
This register
Hi Ezequiel,
From: Ezequiel Garcia [mailto:ezequ...@vanguardiasur.com.ar]
Hello Pekon,
On 16 May 04:33 PM, Pekon Gupta wrote:
[..]
+gpmc,wait-pin = 0;
+gpmc,wait-on-read;
+gpmc,wait-on-write;
Thanks for adding the wait-pin property. I think the other
Hi Tony, Roger,
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140516 05:23]:
On 05/16/2014 02:03 PM, Pekon Gupta wrote:
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0 0x0100;/* minimum GPMC
Hi Ezequiel,
Sorry for delayed replies..
From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com]
Pekon,
A few questions regarding this patch, despite the fact I'm not sure it will
ever be included.
On 20 Mar 01:04 PM, Pekon Gupta wrote:
+0x70 (MUX_MODE0 |
Hi Roger,
For now, I'll use GPMC address-space size = 0x380 as it matches with
actual hardware and is working.
How did you get 0x380?
From DRA7 TRM, GPMC address range is 0x5000 : 0x5000 02D0
So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits
wide)
I think that
From: Quadros, Roger
[...]
For now, I'll use GPMC address-space size = 0x380 as it matches with
actual hardware and is working.
How did you get 0x380?
From DRA7 TRM, GPMC address range is 0x5000 : 0x5000 02D0
So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits
Hi Roger,
On 05/09/2014 11:40 PM, Pekon Gupta wrote:
[...]
+
+elm {
+ status = disabled;
+};
+
+gpmc {
+ status = disabled;
+};
Why are you disabling the elm and gpmc modules here?
Shouldn't they be disabled by default in the soc.dtsi file?
Yes both GPMC and ELM are 'disabled'
Hello,
From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta pe...@ti.com wrote:
From: Minal Shah minalks...@gmail.com
[...]
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x16;
+ ranges
From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
[...]
Newer platforms have upgraded version of GPMC engine which supports
BCH16 ECC scheme in hardware. Thus the GPMC address space was
expanded to include some extra registers required for BCH16 ECC [2].
I see and did the GPMC
From: Tony Lindgren [mailto:t...@atomide.com]
* Pekon Gupta pe...@ti.com [140422 00:34]:
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -9,6 +9,7 @@
#include am33xx.dtsi
#include am335x-bone-common.dtsi
+#include am335x-bone-memory-cape.dts
ldo3_reg
Hi Tony,
And looks like we have a build warning in the -rc cycle with
omap2plus_defconfig:
drivers/mtd/nand/omap2.c:1250:12: warning: ‘erased_sector_bitflips’ defined
but not used [-
Wunused-function]
Can you please fix that if not already fixed?
Yes, this is already fixed and is in MTD
From: Tony Lindgren [mailto:t...@atomide.com]
* Pekon Gupta pe...@ti.com [140422 00:34]:
+gpmc {
+status = okay;
+pinctrl-names = default;
+pinctrl-0 = nand_flash_x8;
+ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
Please use the minimum size 16MB GPMC range here, NAND
Hello Tony,
From: Gupta, Pekon
*changes v2 - v3*
rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
:master
merged leftover patches (dra7-evm and am43x-epos-evm fix) from Part-1 series
Can you please see if this series can be taken in for 3.16 ? As this series
Tony,
From: Tony Lindgren
* Robert Nelson robertcnel...@gmail.com [140418 16:42]:
On Fri, Apr 18, 2014 at 5:51 PM, Tony Lindgren t...@atomide.com wrote:
* Robert Nelson robertcnel...@gmail.com [140415 08:46]:
Background: i also tried getting this having this fixed in u-boot:
Do we
HI Tony,
From: Gupta, Pekon
[...]
I see following patches in your tree/branch omap-for-v3.15/dt
But probably they were omitted in the pull request. Is there something, I need
to do for these ?
f68e355 2014-03-02 ARM: dts: am43xx: add support for parallel NAND
flash
c06c527
From: Gupta, Pekon
Subject: [PATCH v8 0/4] mtd: devices: elm: add checks ELM H/W constrains,
driver code cleanup
Sorry, sent to the wrong list.. was intended for linux-mtd list
Please ignore the whole series.
with regards, pekon
--
To unsubscribe from this list: send the line unsubscribe
Hi Tony,
From: Gupta, Pekon
*changes v1 - v2*
- AM335x (am335x-evm): already accepted, so dropping in v2
- DRA7xx (dra7-evm): resending
- AM43xx (am43X-epos-evm): fix MTD NAND.filesystem partition offset
I see following patches in your tree/branch omap-for-v3.15/dt
But probably they were
[...]
arch/arm/boot/dts/Makefile|1 +
arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 +
2 files changed, 124 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
diff --git a/arch/arm/boot/dts/Makefile
From: Menon, Nishanth
On 03/12/2014 05:49 AM, Pekon Gupta wrote:
Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
eMMC or NAND can be enabled. Selection between eMMC
Hi,
From: Menon, Nishanth
On 03/12/2014 05:49 AM, Pekon Gupta wrote:
Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with
-Original Message-
From: Menon, Nishanth
Sent: Thursday, March 13, 2014 2:21 AM
To: Tony Lindgren; Robert Nelson
Cc: Gupta, Pekon; bcous...@baylibre.com; linux-omap; linux-mtd
Subject: Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone
NAND cape
On 03/12/2014 02:28 PM
Hi Brian,
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Fri, Dec 13, 2013 at 02:42:57PM +0530, Pekon Gupta wrote:
This patch updates starting offset for free bytes in OOB which can be used by
file-systems to store their metadata (like clean-marker in case of JFFS2).
This should be
Hi Benoit, Tony,
From: Gupta, Pekon
This patch-set adds and updates parallel NAND support on following TI platforms
- AM335x (am335x-evm)
- DRA7xx (dra7-evm
- AM43xx (am43X-epos-evm)
In addition, following OMAP2+/GPMC patch is also added in this series as
it add checks DRA7xx and AM43xxx
Hi Brian,
From: Gupta, Pekon
I'm preparing a 3.14 pull request soon, and since you seem committed to
fixing and properly testing a known regression here, I'd like to see
this go in. But given the late timing and the unanswered questions, I
think it's unlikely to go in -rc1. Perhaps I can send
Hi Brian,
From: Brian Norris
Hi Pekon,
Sorry, I'm revisiting your patch series a bit late. There are a few
factors that contributed to this, though.
1. This patch series talks extensively about U-Boot. U-Boot is not my
interest, nor should it be the focus of kernel (driver) development.
Hi Brian,
From: Enric Balletbo Serra [mailto:eballe...@gmail.com]
2014/1/6 Stefan Roese s...@denx.de:
...
As there were parallel set of patches running between u-boot and kernel.
hence, some patch-sets caused regression for OMAP3x platforms when booting
using u-boot specifically for
Hello Enric, Nikita, and other OMAP3 users,
As there were parallel set of patches running between u-boot and kernel.
hence, some patch-sets caused regression for OMAP3x platforms when booting
using u-boot specifically for ecc-schemes (like BCH4_SW).
Hence this patch series fixes those
From: Matthieu CASTET [mailto:matthieu.cas...@parrot.com]
From: Pekon Gupta [mailto: pe...@ti.com]
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
[...]
Using 1-bit ECC on NAND is not a long-term solution. Given that
Hi,
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
[...]
Using 1-bit ECC on NAND is not a long-term solution. Given that fact,
I think your ROM code is what may need to change, not the entire MTD
subsystem.
As
Hi Ezequiel,
From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com]
[...]
AFAIK, there's no hardware limitation that would prevent us from setting
a per-partition ECC, keep in mind this effort is not reduced to make
devicetree accept ECC on the partitions.
I had some reservations in
Hi,
From: Enric Balletbo Serra [mailto:eballe...@gmail.com]
CCing Pekon Gupta pe...@ti.com
2013/12/2 Thomas Petazzoni thomas.petazz...@free-electrons.com:
Dear Javier Martinez Canillas,
On Sun, 1 Dec 2013 13:27:25 +0100, Javier Martinez Canillas wrote:
diff --git
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
On Mon, 2 Dec 2013 14:56:09 +, Gupta, Pekon wrote:
A query Why are you going backward from BCH8 to HAM1 ?
HAM1 is just kept for legacy reasons, it's not at all recommended for new
development. As some field results have
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote:
Although the new ECC schema breaks the compatibility between the board
files and new DT based kernel, I think we should use BCH8 scheme.
Sorry, because I had not realized
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
Dear Gupta, Pekon,
On Mon, 2 Dec 2013 16:13:56 +, Gupta, Pekon wrote:
Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'.
The infrastructure is still in place, however the command 'nandecc' is
deprecated
So coming back to the specific problem here.
I think we need 'nandecc' back in u-boot till atleast all systems have
migrated to BCH16 or whatever highest ecc-scheme which can be
supported on OMAP devices.
Forgot to mention, one more way of updating boot-loaders with
different ecc-scheme via
Hi Brian, Ezequiel,
Sorry Im bit confused on below, so few queries ..
From: Brian Norris [computersforpe...@gmail.com]
So I think the problem may need to be divided into 2 parts:
1) How do we best handle ONFI transactions, so that they are always
performed on the lower 8 bits of the bus
From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com]
On Wed, Oct 30, 2013 at 09:18:53PM +, Gupta, Pekon wrote:
I'm not sure, of course, but I don't see why not. It's more likely to
break for x16 than it is for x8.
Another question here is ..
The above patch
From: Ezequiel Garcia
[...]
But: on the other hand, I'd really like you to convince me as to
why is it so bad to require the DTB to have the proper GPMC bus width.
No its not at all bad, all I want is either of the one way (not mixture of
both).
- Either depend on DT completely (which is
Hi Tony,
From: Tony Lindgren
* Brian Norris computersforpe...@gmail.com [131029 21:00]:
Tony, you mentioned the DTS update in patch 8 going in via an ARM
tree? This patch is not urgent, and it should probably wait until we
know what release the rest of the series makes it into. This may
Hi Brian, Ezequiel Garcia,
Some replies to your queries...
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Wed, Oct 30, 2013 at 06:53:07AM -0300, Ezequiel Garcia wrote:
[...]
I do have one curiosity here: omap2.c looks like it's essentially
defaulting to the NAND_OMAP_POLLED
From: Brian Norris [mailto:computersforpe...@gmail.com]
[...]
I agree with Ezequiel's thoughts, since the excessive amount of noise
in this patch series has delayed it significantly. But at this point,
I think it has stabilized; we have reviews from the DT folks (thanks
guys; please comment
Hi Ezequiel Garcia,
Sorry I'm bit out of my place.. so not able to sync often with mails..
However plz see my replies below..
[...]
Pekon, Brian: Do you think this solution might work for 8-bit and 16-bit
devices?
I think NAND_BUSWIDTH_AUTO (without GPMC changes) would fail in
Hi,
This simplifies the error path and makes the code less error-prone.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/mtd/nand/omap2.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c
From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com]
Hm.. well the problem with that patch is that it's in the middle of an
unrelated series. As I already told you, I think you should have pushed
that as a one-patch fix. Have you seen that suggestion?
Yes, I know.. actually
Hi,
-Original Message-
From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com]
[...]
Pekon, Brian: Do you think this solution might work for 8-bit and 16-bit
devices?
I think NAND_BUSWIDTH_AUTO (without GPMC changes) would fail in
following scenarios..
Case-1:
From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com]
Subject: [PATCH v2 3/5] mtd: nand: omap2: Fix OMAP_BCH option
dependency
This option does not need to depend in MTD_NAND, for it's enclosed
under it. Also, it's wrong to make it depend in ARCH_OMAP3 only
since the controller
Hi Ezequiel,
From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com]
I won't be able to make too much progress without some help or without
squeezing my brains out :P
Care to push some git branch on some random repo with DT support for
the NAND cape in the Beaglebone?
Apologies
Hi Brian,
From: Brian Norris [mailto:computersforpe...@gmail.com]
On 10/22/2013 10:07 PM, Gupta, Pekon wrote:
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Sat, Oct 19, 2013 at 02:14:08PM +0530, Pekon Gupta wrote:
[...]
So are you saying that the driver currently doesn't
Hi,
From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com]
[...]
FWIW, I have a Beaglebone with a 16-bit bus NAND attached to it.
Coincidentally, yesterday I was doing some tests as I'm ramping up the
NAND and I found that weird double nand_scan_ident() call.
The whole thing
Hi Brian,
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Sat, Oct 19, 2013 at 02:14:08PM +0530, Pekon Gupta wrote:
[...]
Thus this patch run nand_scan_ident() with driver configured as x8 device.
So are you saying that the driver currently doesn't work if you started
in x16
Hi Brian,
From: Brian Norris [mailto:computersforpe...@gmail.com]
[PATCH 4/10]
dropped [PATCH v9 4/9] introducing NAND_BUSWIDTH_AUTO, instead
using DT 'nand-bus-width' for device bus-width
As mentioned in reply to the patch, I don't think this patch belongs in
this series now, and
Hi Brian,
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Thu, Oct 17, 2013 at 09:00:27PM +, Pekon Gupta wrote:
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Thu, Oct 17, 2013 at 04:42:23AM +, Pekon Gupta wrote:
[...]
But the real point: you need to
Hi Mark,
From: Mark Rutland
[...]
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-
omap2/gpmc.c
index 579697a..c9fb353 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1342,9 +1342,7 @@ static void __maybe_unused
gpmc_read_timings_dt(struct
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Tue, Oct 15, 2013 at 11:19:51AM +0530, Pekon Gupta wrote:
This patch updates following in omap_nand_probe() and
omap_nand_remove()
- replaces info-nand with nand_chip (struct nand_chip *nand_chip)
- replaces info-mtd with mtd
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Tue, Oct 15, 2013 at 11:19:55AM +0530, Pekon Gupta wrote:
[snip]
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index d885298..5836039 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@
Hi Brain,
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Thu, Oct 17, 2013 at 04:42:23AM +, Pekon Gupta wrote:
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Tue, Oct 15, 2013 at 11:19:52AM +0530, Pekon Gupta wrote:
[snip]
So this approach is other way
Hi Brain,
Oop sorry ..
s/Brain/Brian
synonymous though :-)
with regards, pekon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Brian,
*changes v8 - v9*
[PATCH 1/9] no update from [PATCH v8 1/6]
[PATCH 2/9] only commit log updated from [PATCH v8 2/6]
As per feedbacks from Brian Norris computersforpe...@gmail.com
previous
revision [PATCH v8 3/6] and [PATCH 4/6] are split into following sub-patches:
- [PATCH
Hi Brian,
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Tue, Oct 15, 2013 at 11:19:52AM +0530, Pekon Gupta wrote:
Autodetection of NAND device bus-width was added in generic NAND
driver as
[...]
@@ -1904,6 +1903,21 @@ static int omap_nand_probe(struct
platform_device *pdev)
Hi Brain,
Hi Pekon,
I will try to summarize the standing of your patch series.
Patches 1 and 2 look good and have addressed all of the DT maintainers'
comments, AFAICT. They are ready to go in, except that the following
patches are not ready; they should probably go in together.
You
Hi Brian,
Thanks for such detailed review, please see some replies below..
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Fri, Oct 11, 2013 at 07:06:40PM +0530, Pekon Gupta wrote:
[...]
Why do you even need the #ifdef's for the #include's? It is not harmful
to include headers
Dear MTD Maintainers,
If I have my NAND formatted with one of the existing ECC schemes (e.g.
OMAP_ECC_HAMMING_CODE_DEFAULT) will it work with the new
OMAP_ECC_HAM1_CODE_HW scheme?
Are they all compatible?
Yes, they all are 1-bit hamming code, the only difference between
xx_Default
Hi,
From: Mark Rutland [mailto:mark.rutl...@arm.com]
On Fri, Oct 04, 2013 at 08:49:43PM +0100, Pekon Gupta wrote:
OMAP NAND driver currently supports multiple flavours of 1-bit Hamming
ecc-scheme, like:
- OMAP_ECC_HAMMING_CODE_DEFAULT
1-bit hamming ecc code using software library
From: Mark Rutland [mailto:mark.rutl...@arm.com]
On Fri, Oct 04, 2013 at 08:49:47PM +0100, Pekon Gupta wrote:
DT property values for OMAP based gpmc-nand have been updated
to match changes in commit:
6faf096 ARM: OMAP2+: cleaned-up DT support of various ECC
schemes
Refer:
From: Mark Rutland [mailto:mark.rutl...@arm.com]
On Fri, Oct 04, 2013 at 08:49:44PM +0100, Pekon Gupta wrote:
[snip]
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-
omap2/gpmc.c
index 1c45b72..5a607fa 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++
Hi All,
So, based on feedbacks from everyone, I could come to following
conclusions. Please confirm, if those are acceptable ?
From: Mark Rutland [mailto:mark.rutl...@arm.com]
On Thu, Sep 26, 2013 at 11:54:39AM +0100, Gupta, Pekon wrote:
From: Rob Herring [mailto:robherri...@gmail.com
1 - 100 of 162 matches
Mail list logo
