Upcoming merge window and omap NAND patches

Upcoming merge window and omap NAND patches

[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.

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

Upcoming merge window and omap NAND patches

[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.

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

Re: Upcoming merge window and omap NAND patches

[Artem Bityutskiy]

On Wed, 2010-05-05 at 00:08 +0200, ext Tony Lindgren wrote:
> 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!

Hi,

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

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Upcoming merge window and omap NAND patches

[Artem Bityutskiy]

On Wed, 2010-05-05 at 00:08 +0200, ext Tony Lindgren wrote:
> 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!

Hi,

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

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: Upcoming merge window and omap NAND patches

[Vimal Singh]

On Wed, May 5, 2010 at 10:19 AM, Artem Bityutskiy
<Artem.Bityutskiy@nokia.com> wrote:
> On Wed, 2010-05-05 at 00:08 +0200, ext Tony Lindgren wrote:
>> 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!
>
> 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

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

Re: Upcoming merge window and omap NAND patches

[Vimal Singh]

On Wed, May 5, 2010 at 10:19 AM, Artem Bityutskiy
<Artem.Bityutskiy@nokia.com> wrote:
> On Wed, 2010-05-05 at 00:08 +0200, ext Tony Lindgren wrote:
>> 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!
>
> 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

RE: Upcoming merge window and omap NAND patches

[Ghorai, 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.

Regards,
Ghorai

> -----Original Message-----
> From: Vimal Singh [mailto:vimal.newwork@gmail.com]
> Sent: 2010-05-05 11:42
> To: Artem.Bityutskiy@nokia.com
> Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-
> mtd@lists.infradead.org; Ghorai, Sukumar; Steve Sakoman; Mike Rapoport
> Subject: Re: Upcoming merge window and omap NAND patches
> 
> On Wed, May 5, 2010 at 10:19 AM, Artem Bityutskiy
> <Artem.Bityutskiy@nokia.com> wrote:
> > On Wed, 2010-05-05 at 00:08 +0200, ext Tony Lindgren wrote:
> >> 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!
> >
> > 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

RE: Upcoming merge window and omap NAND patches

[Ghorai, 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.

Regards,
Ghorai

> -----Original Message-----
> From: Vimal Singh [mailto:vimal.newwork@gmail.com]
> Sent: 2010-05-05 11:42
> To: Artem.Bityutskiy@nokia.com
> Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-
> mtd@lists.infradead.org; Ghorai, Sukumar; Steve Sakoman; Mike Rapoport
> Subject: Re: Upcoming merge window and omap NAND patches
> 
> On Wed, May 5, 2010 at 10:19 AM, Artem Bityutskiy
> <Artem.Bityutskiy@nokia.com> wrote:
> > On Wed, 2010-05-05 at 00:08 +0200, ext Tony Lindgren wrote:
> >> 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!
> >
> > 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

Re: Upcoming merge window and omap NAND patches

[Mike Rapoport]

Ghorai,

Ghorai, Sukumar wrote:
> 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.

> Regards,
> Ghorai
> 
>> -----Original Message-----
>> From: Vimal Singh [mailto:vimal.newwork@gmail.com]
>> Sent: 2010-05-05 11:42
>> To: Artem.Bityutskiy@nokia.com
>> Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-
>> mtd@lists.infradead.org; Ghorai, Sukumar; Steve Sakoman; Mike Rapoport
>> Subject: Re: Upcoming merge window and omap NAND patches
>>
>> On Wed, May 5, 2010 at 10:19 AM, Artem Bityutskiy
>> <Artem.Bityutskiy@nokia.com> wrote:
>>> On Wed, 2010-05-05 at 00:08 +0200, ext Tony Lindgren wrote:
>>>> 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!
>>> 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


-- 
Sincerely yours,
Mike.

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

Re: Upcoming merge window and omap NAND patches

[Mike Rapoport]

Ghorai,

Ghorai, Sukumar wrote:
> 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.

> Regards,
> Ghorai
> 
>> -----Original Message-----
>> From: Vimal Singh [mailto:vimal.newwork@gmail.com]
>> Sent: 2010-05-05 11:42
>> To: Artem.Bityutskiy@nokia.com
>> Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-
>> mtd@lists.infradead.org; Ghorai, Sukumar; Steve Sakoman; Mike Rapoport
>> Subject: Re: Upcoming merge window and omap NAND patches
>>
>> On Wed, May 5, 2010 at 10:19 AM, Artem Bityutskiy
>> <Artem.Bityutskiy@nokia.com> wrote:
>>> On Wed, 2010-05-05 at 00:08 +0200, ext Tony Lindgren wrote:
>>>> 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!
>>> 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


-- 
Sincerely yours,
Mike.

Re: Upcoming merge window and omap NAND patches

[Tony Lindgren]

* Mike Rapoport <mike@compulab.co.il> [100505 05:51]:
> Ghorai,
> 
> Ghorai, Sukumar wrote:
> >Tony,
> >I understand your comment/input. And I will work on it.

Great, good to hear.

> >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

Re: Upcoming merge window and omap NAND patches

[Tony Lindgren]

* Mike Rapoport <mike@compulab.co.il> [100505 05:51]:
> Ghorai,
> 
> Ghorai, Sukumar wrote:
> >Tony,
> >I understand your comment/input. And I will work on it.

Great, good to hear.

> >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