linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peng Fan <peng.fan@nxp.com>
To: Arnd Bergmann <arnd@arndb.de>, Viresh Kumar <viresh.kumar@linaro.org>
Cc: Jassi Brar <jassisinghbrar@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"cristian.marussi@arm.com" <cristian.marussi@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH V2] firmware: arm_scmi: Make scmi core independent of transport type
Date: Wed, 15 Jan 2020 08:20:26 +0000	[thread overview]
Message-ID: <AM0PR04MB448109C21B4C6A2C923FF4D988370@AM0PR04MB4481.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CAK8P3a1cByQrhKV=8gRASNy74p8=WKfi1ZU13S2OpFQRjohUsg@mail.gmail.com>

> Subject: Re: [PATCH V2] firmware: arm_scmi: Make scmi core independent of
> transport type
> 
> On Tue, Jan 14, 2020 at 12:11 PM Viresh Kumar <viresh.kumar@linaro.org>
> wrote:
> >
> > On 14-01-20, 10:56, Arnd Bergmann wrote:
> > > My point was that you cannot mix __iomem accesses with pointer
> > > accesses. As I understood it, the current version uses a pointer to
> > > a
> >
> > The current version is stupid as I misunderstood the whole __iomem
> > thing and just dropped it :)
> >
> > > hardware mailbox with structured data, so you have to use ioremap()
> > > to get a token you can pass into ioread(), but (some of) the new
> > > transport types would just be backed by regular RAM, on which this
> > > is not a well-defined operation and you have to use memremap() and
> > > memcpy() instead.
> >
> > Okay, I think I understand that a bit now. So here are the things
> > which I may need to do now:
> >
> > - Maybe move payload to struct scmi_mailbox structure, as that is the
> >   transport dependent structure..
> >
> > - Do ioremap, etc in mailbox.c only instead of driver.c
> >
> > - Provide more ops in struct scmi_transport_ops to provide read/write
> >   helpers to the payload and implement the ones based on
> >   ioread/iowrite in mailbox.c ..
> >
> > Am I thinking in the right direction now ?
> 
> That sounds about right. What I'm still not sure about is whether the current
> kernel code is actually correct and should use iomeap() in the first place. Can
> you confirm that all current hardware implementations actually use MMIO
> type registers here rather than just rely on a buffer in RAM?

i.MX8(alought not use SCMI) use MU(message unit) to transfer data between
Acore and Mcore firmware, not using shared memory.

Thanks,
Peng.

> 
>       Arnd
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr
> adead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&amp;data=02%7C01
> %7Cpeng.fan%40nxp.com%7C1b3e0ec89bde469abfd008d798e36c89%7C686
> ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637145974848395212&a
> mp;sdata=PKDDHvz0M45%2B31vSfWCxwxiDEEY8tQxkmL9AzfzRoSM%3D&a
> mp;reserved=0

  parent reply	other threads:[~2020-01-15  8:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10  9:43 [PATCH V2] firmware: arm_scmi: Make scmi core independent of transport type Viresh Kumar
2020-01-10 11:15 ` Arnd Bergmann
2020-01-13  6:41   ` Viresh Kumar
2020-01-13 11:36     ` Arnd Bergmann
2020-01-14  9:26       ` Viresh Kumar
2020-01-14  9:56         ` Arnd Bergmann
2020-01-14 11:11           ` Viresh Kumar
2020-01-14 11:17             ` Arnd Bergmann
2020-01-14 17:41               ` Sudeep Holla
2020-01-15  8:20               ` Peng Fan [this message]
2020-01-15 19:37             ` peter.hilber
2020-01-14 11:03         ` Sudeep Holla
2020-01-15  8:53 ` Peng Fan
2020-01-15 14:33   ` Sudeep Holla
2020-01-17  2:26     ` Peng Fan
2020-01-16 15:21 ` kbuild test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM0PR04MB448109C21B4C6A2C923FF4D988370@AM0PR04MB4481.eurprd04.prod.outlook.com \
    --to=peng.fan@nxp.com \
    --cc=arnd@arndb.de \
    --cc=cristian.marussi@arm.com \
    --cc=jassisinghbrar@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).