Skip to contentSkip to conversation

Upcoming merge window and omap NAND patches

DISCUSSION Tony Lindgren 5 participants 6 messages May 4, 2010 – May 5, 2010 Memory technology devices (MTD)

lore
Share & tools
lore

Tony Lindgren

author
#0 lore raw

Hi all,

There are several omap NAND patches pending, but some basic things should be fixed first.

1. The NAND driver needs to stop tinkering with the GPMC registers

The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC.

To find out what needs to disappear fomr the NAND driver, just do:

$ grep baseaddr drivers/mtd/nand/omap2.c

Any GPMC register tinkering needs to happen in arch/arm/mach-omap2/gpmc.c. If there are not currently GPMC functions to do something in gpmc.c, then let's add the necessary support there.

2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files

Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly.

So, as a result, I'm not planning on pushing any omap NAND related patches until these basic issues are fixed. I'll mark these patches as "Changes requested" in patchwork.kernel.org even if these patches don't have anything else wrong with them.

Let's fix the basic things for good, and put the other patches on hold for a while. Sorry if this causes problems!

Cheers,

Tony

#1 lore raw
Quoted 25 lines · ext Tony Lindgren

Hi all,

There are several omap NAND patches pending, but some basic things should be fixed first.

1. The NAND driver needs to stop tinkering with the GPMC registers

The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC.

To find out what needs to disappear fomr the NAND driver, just do:

$ grep baseaddr drivers/mtd/nand/omap2.c

Any GPMC register tinkering needs to happen in arch/arm/mach-omap2/gpmc.c. If there are not currently GPMC functions to do something in gpmc.c, then let's add the necessary support there.

2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files

Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly.

Quoted 7 lines

So, as a result, I'm not planning on pushing any omap NAND related patches until these basic issues are fixed. I'll mark these patches as "Changes requested" in patchwork.kernel.org even if these patches don't have anything else wrong with them.

Let's fix the basic things for good, and put the other patches on hold for a while. Sorry if this causes problems!

Hi,

fair enough. I guess Vimal should address this, as he seems to be the TI mr. NAND, right? :-)

Signature · 2 lines
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
#2 lore raw
Quoted 31 lines · Artem Bityutskiy
Quoted 30 lines · ext Tony Lindgren

Hi all,

There are several omap NAND patches pending, but some basic things should be fixed first.

1. The NAND driver needs to stop tinkering with the GPMC registers

The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC.

To find out what needs to disappear fomr the NAND driver, just do:

$ grep baseaddr drivers/mtd/nand/omap2.c

Any GPMC register tinkering needs to happen in arch/arm/mach-omap2/gpmc.c. If there are not currently GPMC functions to do something in gpmc.c, then let's add the necessary support there.

2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files

Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly.

So, as a result, I'm not planning on pushing any omap NAND related patches until these basic issues are fixed. I'll mark these patches as "Changes requested" in patchwork.kernel.org even if these patches don't have anything else wrong with them.

Quoted 7 lines
Quoted 2 lines

Let's fix the basic things for good, and put the other patches on hold for a while. Sorry if this causes problems!

Hi,

fair enough. I guess Vimal should address this, as he seems to be the TI mr. NAND, right? :-)

Hi All,

Sorry again. I am no more with TI and I don't have any board with me too. So, I'm unable to fix these. :(
I hope someone else from TI can take care of it.

Signature · 6 lines
Regards,
Vimal Singh

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
#3 lore raw

Tony,
I understand your comment/input. And I will work on it.

All existing omap3 boards are using same old fashion. So let me see how many board I can test before post the patch. I will update this next week.

Regards,
Ghorai

Quoted 60 lines

-----Original Message-----
From: Vimal Singh [mailto:[email protected]]
Sent: 2010-05-05 11:42
To: [email protected]
Cc: Tony Lindgren; [email protected]; linux- [email protected]; Ghorai, Sukumar; Steve Sakoman; Mike Rapoport
Subject: Re: Upcoming merge window and omap NAND patches

Quoted 12 lines · Artem Bityutskiy
Quoted 11 lines · ext Tony Lindgren

Hi all,

There are several omap NAND patches pending, but some basic things should be fixed first.

1. The NAND driver needs to stop tinkering with the GPMC registers

The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC.

Quoted 5 lines
Quoted 5 lines

To find out what needs to disappear fomr the NAND driver, just do:

$ grep baseaddr drivers/mtd/nand/omap2.c

Any GPMC register tinkering needs to happen in arch/arm/mach-

omap2/gpmc.c.

Quoted 1 line
Quoted 1 line

If there are not currently GPMC functions to do something in gpmc.c,

then

Quoted 13 lines
Quoted 13 lines

let's add the necessary support there.

2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files

Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly.

So, as a result, I'm not planning on pushing any omap NAND related patches until these basic issues are fixed. I'll mark these patches as "Changes requested" in patchwork.kernel.org even if these patches don't have anything else wrong with them.

Quoted 7 lines
Quoted 2 lines

Let's fix the basic things for good, and put the other patches on hold for a while. Sorry if this causes problems!

Hi,

fair enough. I guess Vimal should address this, as he seems to be the TI mr. NAND, right? :-)

Hi All,

Sorry again. I am no more with TI and I don't have any board with me too. So, I'm unable to fix these. :(
I hope someone else from TI can take care of it.

--
Regards,
Vimal Singh

#4 lore raw

Ghorai,

Quoted 4 lines · Sukumar

Tony,
I understand your comment/input. And I will work on it.

All existing omap3 boards are using same old fashion. So let me see how many board I can test before post the patch. I will update this next week.

I'd be glad to test the patches on CM-T35 if you'd like to.

Quoted 61 lines

Regards,
Ghorai

Quoted 58 lines

-----Original Message-----
From: Vimal Singh [mailto:[email protected]]
Sent: 2010-05-05 11:42
To: [email protected]
Cc: Tony Lindgren; [email protected]; linux- [email protected]; Ghorai, Sukumar; Steve Sakoman; Mike Rapoport
Subject: Re: Upcoming merge window and omap NAND patches

Quoted 12 lines · Artem Bityutskiy
Quoted 11 lines · ext Tony Lindgren

Hi all,

There are several omap NAND patches pending, but some basic things should be fixed first.

1. The NAND driver needs to stop tinkering with the GPMC registers

The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC.

Quoted 5 lines
Quoted 5 lines

To find out what needs to disappear fomr the NAND driver, just do:

$ grep baseaddr drivers/mtd/nand/omap2.c

Any GPMC register tinkering needs to happen in arch/arm/mach-

omap2/gpmc.c.

Quoted 1 line
Quoted 1 line

If there are not currently GPMC functions to do something in gpmc.c,

then

Quoted 13 lines
Quoted 13 lines

let's add the necessary support there.

2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files

Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly.

So, as a result, I'm not planning on pushing any omap NAND related patches until these basic issues are fixed. I'll mark these patches as "Changes requested" in patchwork.kernel.org even if these patches don't have anything else wrong with them.

Quoted 6 lines
Quoted 2 lines

Let's fix the basic things for good, and put the other patches on hold for a while. Sorry if this causes problems!

Hi,

fair enough. I guess Vimal should address this, as he seems to be the TI mr. NAND, right? :-)

Hi All,

Sorry again. I am no more with TI and I don't have any board with me too. So, I'm unable to fix these. :(
I hope someone else from TI can take care of it.

--
Regards,
Vimal Singh

Signature · 6 lines
Sincerely yours,
Mike.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
author
#5 lore raw
Quoted 5 lines · Mike Rapoport

Ghorai,

Quoted 2 lines · Sukumar

Tony,
I understand your comment/input. And I will work on it.

Great, good to hear.

Quoted 3 lines
Quoted 1 line

All existing omap3 boards are using same old fashion. So let me see how many board I can test before post the patch. I will update this next week.

I'd be glad to test the patches on CM-T35 if you'd like to.

For this merge window how about just getting rid of OMAP34XX_GPMC_VIRT in the board-*.c files and move that to gpmc-nand.c?

This may allow adding more board-*.c NAND files without having to patch all of them later on again.

However, if there are more changes needed to all the board-*.c files for the NAND platform data, then let's just fix the existing ones first before adding new ones.

After that, looks like most of the work is to move some of the GPMC functions from omap2.c to gpmc.c.

Or should they rather be in gpmc-nand.c if they are only used with NAND connected to GPMC?

Regards,

Tony