[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABb+yY2KXqRnxqHC-Hs8NsosEPtyTYO4v_b1cCGs9Lphpz_X+A@mail.gmail.com>
Date: Wed, 3 Jun 2020 13:42:18 -0500
From: Jassi Brar <jassisinghbrar@...il.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Viresh Kumar <viresh.kumar@...aro.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Arnd Bergmann <arnd@...db.de>,
Rob Herring <robh+dt@...nel.org>,
Frank Rowand <frowand.list@...il.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Devicetree List <devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
On Wed, Jun 3, 2020 at 1:31 PM Sudeep Holla <sudeep.holla@....com> wrote:
>
> > >
> > H/W is actually fine :) Its just that the driver is written to
> > _also_ support a platform (my original) that doesn't have shmem and
> > need to pass data via 32bit registers.
> > Frankly, I am not against the doorbell mode, I am against implementing
> > two modes in a driver. If it really helped (note the past tense) the
> > SCMI, we could implement the driver only in doorbell mode but
> > unfortunately SCMI would still be _broken_ for non-doorbell
> > controllers.
>
> Should be fine as the specification is designed to work with only shmem
> for any data transfer and mailbox is just a signal mechanism. I won't
> be too worried about that.
>
Please clarify how it will work on, say again, rockchip platform with shmem.
thanks.
Powered by blists - more mailing lists