[PATCH v4 04/39] ARM: OMAP2+: gpmc: Acquire NAND CS value

[Thomas Weber]

Hello Afzal,

On 05/14/12 12:33, Mohammed, Afzal wrote:
> Hi All,
>
> On Thu, May 03, 2012 at 14:12:11, Mohammed, Afzal wrote:
>
>>>> Some boards depend on bootloader to update chip select value for NAND.
>>>> It is felt that Kernel should not depend on bootloader to get CS, as
>>>> for a particular board CS is hardwired and is fixed, hence this can
>>>> directly be updated in Kernel. But as CS value for boards that depend
>>>> on this behaviour is not available, educate gpmc driver to acquire
>>>> chip select value for NAND. this ideally should be removed once CS
>>>> for those boards are available.
>>> Do you know how many boards require this? If so which are those boards?
>> devkit8000, beagle board, omap3touchbook, overo.
>>
>> Beagle board, found out to be zero.
> I need a help.
>
> Can someone familiar with boards - devkit8000, omap3touchbook, overo boards,
> let me know GPMC CS on which NAND is connected.
On Devkit8000 the NAND is connected to CS0.
I thought that all NAND devices for booting are connected to CS0, 
because of ROM code?

According to spruf98w.pdf:

25.4.7.4 NAND
...
  * The device is connected to CS0.
...

Regards,
Thomas

> Hi Tony,
>
> I am planning to provide actual CS # used for NAND on above boards instead of
> finding the value at runtime. Is there any reason that NAND CS# is found out
> at runtime ? (hence remove necessity of omap_nand_flash_init()).
>
> Presence of this also causes an additional dependency of bootloader.
>
> As CS # depends on wiring on the board, my understanding is that it will be
> fixed for a given board. Are you ok if acquiring NAND CS # is removed ?
>
> Removal of this helps in simplifying gpmc driver (undergoing conversion).
>
> Regards
> Afzal
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html