[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABb+yY3sR_uxqb68n2z0VNBe_MRMaym-16npq+D20cGvcqbHhQ@mail.gmail.com>
Date: Tue, 20 May 2014 23:41:58 +0530
From: Jassi Brar <jassisinghbrar@...il.com>
To: Bjorn Andersson <bjorn@...o.se>
Cc: Jassi Brar <jaswinder.singh@...aro.org>,
Arnd Bergmann <arnd@...db.de>,
lkml <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Anna, Suman" <s-anna@...com>,
Loic Pallardy <loic.pallardy@...com>,
LeyFoon Tan <lftan.linux@...il.com>,
Craig McGeachie <slapdau@...oo.com.au>,
Courtney Cavin <courtney.cavin@...ymobile.com>,
Rob Herring <robherring2@...il.com>,
Josh Cartwright <joshc@...eaurora.org>,
Linus Walleij <linus.walleij@...aro.org>,
Kumar Gala <galak@...eaurora.org>,
"ks.giri@...sung.com" <ks.giri@...sung.com>
Subject: Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox
On Tue, May 20, 2014 at 1:25 AM, Bjorn Andersson <bjorn@...o.se> wrote:
> On Mon, May 19, 2014 at 11:03 AM, Jassi Brar <jaswinder.singh@...aro.org> wrote:
>> On 19 May 2014 18:38, Arnd Bergmann <arnd@...db.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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists