On Tue, May 20, 2014 at 1:25 AM, Bjorn Andersson <bj...@kryo.se> wrote: > On Mon, May 19, 2014 at 11:03 AM, Jassi Brar <jaswinder.si...@linaro.org> > wrote: >> On 19 May 2014 18:38, Arnd Bergmann <a...@arndb.de> wrote: >>> On Friday 16 May 2014 19:03:25 Jassi Brar wrote: > [...] >>> Do you have an example for a platform like that? I'd expect that normally >>> we can have a boot loader that sets up the system timer to work good >>> enough for us to get into normal driver initialization. >>> >> My platform. We choose to keep bootloader to the minimum and make >> kernel not depend upon any goodies provided. >> Second, which I don't think can be helped by a bootloader, the remote >> master has gate & rate control of clocks to peripheral IPs. The >> clk-api driver simply maps Linux requests onto mailbox commands. So >> the mailbox is needed as early as CLK_OF_DECLARE (when kernel reads >> the rate of every registered clock). Any suggestions? > > Hi Jessi > > On the newer Qualcomm platform the root clocks are controlled by a "resource > power manager" system; all clocks and regulators accesses are done over a fifo > based communication link, over shared memory, with dependencies on e.g. > hwspinlocks. > > There's nothing strange with this, you just have to bring up (probe) all those > drivers before you can initialize the clock driver so that you can > initialize any > peripheral device drivers. That's what you have EPROBE_DEFER for. > > > Even in your sparsely initialized system, you must have enough clocks to > bring up the mailbox driver, so that you can bring up your clock driver and > from that you're good to initialize the rest. > As Arnd suspected, my clocksource SP804's clk as well is owned by the remote. Another situation (again my platform) where EPROBE_DEFER won't help is when CPU reset control is with the remote because smp_init() trumps even a core_initcall.
Regards, Jassi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
