On Thursday 28 August 2014 13:39:55 Rafał Miłecki wrote: > On 28 August 2014 13:02, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Thursday 28 August 2014 12:47:29 Rafał Miłecki wrote: > >> On 28 August 2014 12:13, Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> > My impression is that all the information that you need in these early > >> > three steps is stuff that is already meant to be part of DT. > >> > This isn't surprising, because the bcm47xx serves a similar purpose > >> > to DT, it's just more specialized. > >> > > >> > This duplication is a bit unfortunate, but it seems that just using > >> > the respective information from DT would be easier here. > >> > > >> > Is any of the information you need early dynamic? It sounds that > >> > for a given SoC, it should never change and can just be statically > >> > encoded in DT. > >> > >> I'm not sure which info you exactly are talking about. I believe one > >> SoC model always use the same CPU, ChipCommon, embedded wireless and > >> PCIe + USB controllers. However amount of RAM, type of flash (serial > >> vs. NAND), size of flash, booting method, NVRAM location, etc. all > >> depend on vendor's choice. I think CPU speed could also depend on > >> vendor choice. > > > > But those would also be present in DT on ARM, right? > > Well, that depends. Hauke was planning to put info about flash in DT. > Me on the other hand suggested reading info about flash from the > board. See my reply: > https://www.mail-archive.com/devicetree@xxxxxxxxxxxxxxx/msg39365.html > > My plan was to use patch like > [PATCH] bcma: get & store info about flash type SoC booted from > http://www.spinics.net/lists/linux-wireless/msg126163.html > (it would work on both: MIPS and ARM) > and then: > > switch (boot_device) { > case BCMA_BOOT_DEV_NAND: > nvram_address = 0x1000dead; > break; > case BCMA_BOOT_DEV_SERIAL: > nvram_address = 0x1000c0de; > break; > } > I don't understand. Why does the nvram address depend on the boot device? > >> Can you see any solution for making NVRAM support a standard platform > >> driver on MIPS and ARM? As I said, on MIPS we need access to the NVRAM > >> really early, before platform devices/drivers can operate. > > > > I think it would make sense to have a common driver that has both > > an 'early' init part used by MIPS and a regular init part used by > > ARM and potentially also on MIPS if we want. Most of the code can > > still be shared. > > OK, now it's clear what you meant. > The thing is that we may want to call probe function from > drivers/bcma/main.c. I think we never meant to call it directly from > arch code. This code in drivers/bcma/main.c is used on both: MIPS and > ARM. So I wonder if there is much sense in doing it like > #ifdev MIPS > bcm47xx_nvram_init(nvram_address); > #endif > #ifdef ARM > nvram_device.resource[0].start = nvram_address; > platform_device_register(nvram_device); > #endif > > What do you think about this? I definitely don't want to see any manual platform_device_register() calls on ARM, any device should be either a platform_device probed from DT, or a bcma_device that comes from the bcma bus. I suspect I'm still missing part of the story here. How is the nvram chip actually connected? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
