Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox

From: Jassi Brar
Date: Tue May 20 2014 - 14:12:05 EST


On Tue, May 20, 2014 at 1:25 AM, Bjorn Andersson <bjorn@xxxxxxx> wrote:
> On Mon, May 19, 2014 at 11:03 AM, Jassi Brar <jaswinder.singh@xxxxxxxxxx> wrote:
>> On 19 May 2014 18:38, Arnd Bergmann <arnd@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/