linux-kernel - Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJe_Zhcp_TODswcsGRBPqfuC8s-LkM8iGBSAQEnzveKi6QJdqg@mail.gmail.com>
Date:	Fri, 20 Jun 2014 18:48:12 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	Bjorn Andersson <bjorn@...o.se>
Cc:	Kevin Hilman <khilman@...aro.org>,
	Kumar Gala <galak@...eaurora.org>,
	Lee Jones <lee.jones@...aro.org>,
	Bjorn Andersson <bjorn.andersson@...ymobile.com>,
	Rob Herring <robh+dt@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,
	Josh Cartwright <joshc@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	Paul Walmsley <paul@...an.com>
Subject: Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver

On 20 June 2014 10:47, Bjorn Andersson <bjorn@...o.se> wrote:
> On Wed, Jun 18, 2014 at 9:44 AM, Kevin Hilman <khilman@...aro.org> wrote:
> [...]
>> Thinking more about what this RPM driver actually does, and since you
>> mentioned patterns across SoCs, it seems to me the RPM driver bascially
>> just doing the IPC.
>>
>
> Yes, technically this is IPC. But it's all exposed in memory as if it
> was hardware, so there's no messages or packets to be interpreted by
> the other side.
>
>> So, rather than MFD or drivers/soc, it seems to me that it should be
>> implmented as a controller in the new common mailbox framwork[1] being
>> worked on by Jassi Brar (added to Cc.)
>>
>> IIUC, RPM is actually only doing one-way IPC (it only exposes a write()
>> interface to clients) so it seems like a rather simple implementation of
>> a mailbox controller.
>>
>
> What I think you miss here is the detail of that what the regulator
> writes is not what is passed over the IPC, but rather is just an
> interface to abstract away how things are spread our in the register
> space.
>
> So the only place where we do have a "mailbox" here is the actual
> function call between the regulator and the rpm drivers; not between
> the rpm driver and the rpm.
>
Is the RPM a firmware running on a separate processor outside the
scope of Linux ?

Is an irq raised to the RPM when you do  writel(RPM_SIGNAL, rpm->ipc_rpm_reg) ?

Do you get the qcom_rpm_ack_interrupt() only when the RPM firmware has
taken action on Linux's request (i.e, values filled in 80ish
registers)?

I maybe wrong but I think the answer to all above is Yes, and that is
the reason I think its no different than other mailbox controllers.
For example, look at pl320_ipc_transmit()


>> I believe Bjorn is already on the list of folks Cc'd on the common
>> mailbox framework, so it would be good to hear from him why RPM wouldn't
>> fit under that framework.
>>
>
> In a separate group of Qualcomm platforms the communication with the
> RPM is done by passing messages over a shared memory channel; as this
> requires a completely different implementation of the rpm driver, I
> have started to look at Jassi's patch series.
>
> Unfortunately at this point it does not look like the proposed mailbox
> framework would reduce the complexity of the implementation nor
> provide any additional benefits when it comes to being able to
> exchange the underlaying communication methods.
>
For your simple one-way communication, using mailbox api isn't going
to change lives.

Cheers,
-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/