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
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
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
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: 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 [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
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
[...]
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
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
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
[...]
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
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
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
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
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]:
--- 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
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
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'
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 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
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 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: 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
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
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
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 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
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 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
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
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
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
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 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 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
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
101 - 162 of 162 matches
Mail list logo
