Mainlining support for MStar ARMv7 SoCs; Where to start?

Mainlining support for MStar ARMv7 SoCs; Where to start?

[Daniel Palmer]

Hi all,

I've been working independently on support for MStar's ARMv7 SoCs for
a few months now
and I'm at the point where it's probably good enough for general consumption.

Right now I'm sitting on a bunch of commits that adds the new machine,
adds support for the clocks, pinctrl etc all the way up to mmc host,
ethernet and usb. I'm sure I can't drop all of that in one go but I'm
unsure of what the initial set of commits should look like. For
instance does it matter if the new machine is added but it's totally
unusable because there is no support for the clocks or should I put
together a package that is the minimum needed to get to a shell?

Thanks,

Daniel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Mainlining support for MStar ARMv7 SoCs; Where to start?

[Matthias Brugger]

Hi Daniel,

On 10/09/2019 16:18, Daniel Palmer wrote:
> Hi all,
> 
> I've been working independently on support for MStar's ARMv7 SoCs for
> a few months now
> and I'm at the point where it's probably good enough for general consumption.
> 
> Right now I'm sitting on a bunch of commits that adds the new machine,
> adds support for the clocks, pinctrl etc all the way up to mmc host,
> ethernet and usb. I'm sure I can't drop all of that in one go but I'm
> unsure of what the initial set of commits should look like. For
> instance does it matter if the new machine is added but it's totally
> unusable because there is no support for the clocks or should I put
> together a package that is the minimum needed to get to a shell?
> 

I think a shell is the minimum you should get to.
So my take would be to send basic DTS (and clocks, if needed) so that you can
boot into a shell, even using a initramfs.

For the rest I'd propose to send each driver as a independent series. If you
want to add the DTS patch which adds the driver to your board, then make sure to
notice that it is based on the basic support.

Hope that helps.
Regards,
Matthias

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Mainlining support for MStar ARMv7 SoCs; Where to start?

[Chen-Yu Tsai]

On Tue, Sep 10, 2019 at 3:59 PM Matthias Brugger <matthias.bgg@gmail.com> wrote:
>
> Hi Daniel,
>
> On 10/09/2019 16:18, Daniel Palmer wrote:
> > Hi all,
> >
> > I've been working independently on support for MStar's ARMv7 SoCs for
> > a few months now
> > and I'm at the point where it's probably good enough for general consumption.
> >
> > Right now I'm sitting on a bunch of commits that adds the new machine,
> > adds support for the clocks, pinctrl etc all the way up to mmc host,
> > ethernet and usb. I'm sure I can't drop all of that in one go but I'm
> > unsure of what the initial set of commits should look like. For
> > instance does it matter if the new machine is added but it's totally
> > unusable because there is no support for the clocks or should I put
> > together a package that is the minimum needed to get to a shell?
> >
>
> I think a shell is the minimum you should get to.
> So my take would be to send basic DTS (and clocks, if needed) so that you can
> boot into a shell, even using a initramfs.

To expand on this, your basic DTS would likely include the CPU cores, an
interrupt controller (GIC?), a basic timer block (ARM arch timer?), the
UART(s), and a dummy clock for the UART(s).

If the hardware blocks are already supported in mainline, then the first
series would be extremely simple. Otherwise you would need to include
the drivers for the UART, timer, and interrupt controllers so you can
boot to a shell.

An old example would be the initial Allwinner support patches:

   https://patchwork.kernel.org/patch/2838400/

Note the watchdog node is not needed.

ChenYu

> For the rest I'd propose to send each driver as a independent series. If you
> want to add the DTS patch which adds the driver to your board, then make sure to
> notice that it is based on the basic support.
>
> Hope that helps.
> Regards,
> Matthias
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Mainlining support for MStar ARMv7 SoCs; Where to start?

[Daniel Palmer]

Thanks for the input guys.

> > I think a shell is the minimum you should get to.
> > So my take would be to send basic DTS (and clocks, if needed) so that you can
> > boot into a shell, even using a initramfs.
>
> To expand on this, your basic DTS would likely include the CPU cores, an
> interrupt controller (GIC?), a basic timer block (ARM arch timer?), the
> UART(s), and a dummy clock for the UART(s).

Fortunately the core stuff is pretty standard; arch timer, GIC and
what seems to be a dw uart with one of the registers moved.
Interrupts for the uart actually go through another interrupt
controller that is wired to the GIC so I think in the first pass it
would be polled.

Based on your input I'm thinking a patch series that looks like this
for the first pass:
- patch to add arch/arm/mach-mstar and the bits in there
- patch for just enough of a DTS to boot a buildroot initramfs up to a shell
- patch for a basic defconfig

Thanks,

Daniel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel