Antwort: Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Roger Quadros]

On 01/09/15 16:31, Hannes Schmelzer wrote:
>> Hi Hannes,
> Hi Roger,
> 
>>
>> On 27/08/15 08:52, Hannes Schmelzer wrote:
>>> Hi Tony,
>>>
>>> Did anyone test this changeset on some AM335x board?
>>>
>>> Today I ran into trouble with that because:
>>>
>>> The GPMC controller gets reseted on kernel boot due to the 
> missing/removed 
>> HWMOD_INIT_NO_RESET flag.
>>>
>>> Primary this should not be a big problem, but on my board (maybe on 
> all 
>> AM335x) the GPMC doesn't behave as described in TRM.
>>> Especially the GPMC_CONFIG register is not reset to 0h after reset, 
> instead 
>> it holds the value 0xa00 which is very strange because bit 10-31 are 
> reserved.
>>>
>>> Further this 0xa00 means that Bit9 (WAIT1PINPOLARITY) is set, exactly 
> this 
>> causes my system to stall on first access the connected NAND flash 
> because it 
>> never becomes ready due to the wrong wait pin polarity. Maybe others 
> dont't 
>> run into trouble because they may use WAIT0PIN, which one has it's old 
> polarity.
>>
>> So nand ready/busy pin is connected to waitpin1 through an inverter on 
> your board?
>>
>> On am335x-evm we use waitpin0. Nand ready/busy is directly connected to 
> waitpin0.
> 
> No there is no inverter between flash and AM335x, the READY_nBUSY line is 
> directly connected to waitpin1.
> But your sentence brings some good idea to me, i will try to solder some 
> inverter into the READY_nBUSY line on my board and see if the problem 
> appears again.

Please don't do that. We want to maintain the NAND ready/busy# logic as it is.

> If i'm right in my theory that the value 0xa00 in GPMC_CONFIG register is 
> the problem, the inverter would solve it.

You really need to disable read/write monitoring in gpmc-settings.

> 
> You're right am335x-evm uses waitpin0, which one is not affected from this 
> "bug".

Why is it not affected by this bug? The polarities are same for am335x-evm and
your board. Only the wait pin is different.

> I have to use waitpin1, because i also have a 2nd ethernet interface 
> connected, and there is waitpin0 uses for collission detect signal from 
> the phy (other pinmux).
> 
>> For NAND operation read/write wait monitoring must be disabled.
>> The nand driver uses the WAIT pin purely for Read/Busy signalling.
>> Unfortunately the existing driver cannot handle anything other than 
> waitpin 0 
>> for nand for DT boot.
> for sure ? have a look to omap-gpmc.c at line #90.
> Here i can see that either can be used.

Which tree are you referring to?

> 
>>
>> I've tried to address this issue here
>> http://thread.gmane.org/gmane.linux.drivers.devicetree/131076
> This is useful if the READY_nBUSY line cannot be connected to the GPMC 
> itself, instead it maybe connected to some other gpio.
> But it doesn't solve the problem.

It does. We are adding gpiolib and interrupt controller support for all
the wait pins.

cheers,
-roger