On 02/01/2013 03:51 PM, Tony Lindgren wrote:
> Hi Jon,
>
> * Jon Hunter <jon-hun...@ti.com> [130201 08:42]:
>> --- a/arch/arm/mach-omap2/gpmc.c
>> +++ b/arch/arm/mach-omap2/gpmc.c
>> @@ -32,6 +32,7 @@
>>
>> #include "soc.h"
>> #include "common.h"
>> +#include "control.h"
>> #include "omap_device.h"
>> #include "gpmc.h"
>>
>> @@ -778,18 +779,26 @@ static void gpmc_mem_exit(void)
>> static int gpmc_mem_init(void)
>> {
>> int cs, rc;
>> - unsigned long boot_rom_space = 0;
>>
>> - /* never allocate the first page, to facilitate bug detection;
>> - * even if we didn't boot from ROM.
>> + /*
>> + * The first 1MB of GPMC address space is mapped to the
>> + * internal ROM. OMAP2 devices are an exception to this
>> + * where the first 1MB may be mapped to the GPMC.
>> */
>> - boot_rom_space = BOOT_ROM_SPACE;
>> - /* In apollon the CS0 is mapped as 0x0000 0000 */
>> - if (machine_is_omap_apollon())
>> - boot_rom_space = 0;
>
> This part is going away anyways with the patch dropping apollon
> board support from Kyungin.
Yes just saw that today.
>> - gpmc_mem_root.start = GPMC_MEM_START + boot_rom_space;
>> + gpmc_mem_root.start = GPMC_MEM_START + BOOT_ROM_SPACE;
>> gpmc_mem_root.end = GPMC_MEM_END;
>>
>> + /*
>> + * OMAP2 devices that boot from external memory devices, will
>> + * map CS0 to the start of the GPMC address space (0x0). We can
>> + * test this by checking if SYS_BOOT3 pin is set. If not set
>> + * then CS0 is mapped to 0x0.
>> + */
>> + if (cpu_is_omap24xx())
>> + if (!(omap_ctrl_readl(OMAP24XX_CONTROL_STATUS) &
>> + OMAP2_SYSBOOT_3_MASK))
>> + gpmc_mem_root.start = GPMC_MEM_START;
>> +
>> /* Reserve all regions that has been set up by bootloader */
>> for (cs = 0; cs < GPMC_CS_NUM; cs++) {
>> u32 base, size;
>
> How about let's fix this properly to start with so we don't add
> more blockers moving this code to drivers/bus?
>
> Looks like gpmc_mem_init() gets called from gpmc_probe() so
> we can pass that information in pdev.
I wondered if you would suggest that ;-)
I definitely can and it is probably best. Things like this become
painful when we move to device-tree. We really need a generic way for
passing stuff like this to drivers for omap. Our options are auxdata or
bus notifiers. I am wondering whether we can plug pdata in the
omap_device bus notifier for device-tree. Let me know if you have any
thoughts.
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
