[RESEND PATCH v2] remoteproc/mediatek: read IPI buffer offset from FW

[Tzung-Bi Shih]

On Sat, Nov 28, 2020 at 2:25 AM Mathieu Poirier
<mathieu.poirier at linaro.org> wrote:
>
> On Fri, 27 Nov 2020 at 10:25, Tzung-Bi Shih <tzungbi at google.com> wrote:
> >
> > On Sat, Nov 28, 2020 at 12:11 AM Mathieu Poirier
> > <mathieu.poirier at linaro.org> wrote:
> > > On Fri, 27 Nov 2020 at 02:30, Tzung-Bi Shih <tzungbi at google.com> wrote:
> > > > The patch breaks MTK SCP when working with legacy SCP firmware.  We're
> > > > aware of it and will upgrade the devices' kernel and SCP firmware
> > > > carefully.  Other than that, AFAICT, no other devices in the wild are
> > > > using this driver.
> > > >
> > I agree the patch is aggressive which would break machines with old
> > SCP firmware.  But AFAICT, no other devices are using this driver; and
> > we'll take care of our devices to upgrade SCP firmware first and then
> > kernel drivers.  Thus, ideally, no real device breakage is expected.
> >
>
> How do you know about all the systems out there that use this SoC?
> Moreover why would the original author have implemented the driver the
> way they did if it didn't work for them?

I am trying not to repeat my statements.
- AFAIK, MT8183-based chromebooks are the only user of the driver.
We're happy to provide fixups if any other devices break due to the
aggressive patch.
- The original author Erin Lo <erin.lo at mediatek.com> adds the driver
for MT8183-based chromebooks.
- The IPI buffer address was hard-coded because we didn't foresee new
feature changes in the next generation MTK SCP.

If it still makes no sense, here is v3 which is backward compatible
with legacy firmwares.
(https://patchwork.kernel.org/project/linux-remoteproc/patch/20201130034025.3232229-1-tzungbi@google.com/)