* Mainlining support for MStar ARMv7 SoCs; Where to start? @ 2019-09-10 14:18 Daniel Palmer 2019-09-10 14:59 ` Matthias Brugger 0 siblings, 1 reply; 4+ messages in thread From: Daniel Palmer @ 2019-09-10 14:18 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Mainlining support for MStar ARMv7 SoCs; Where to start? 2019-09-10 14:18 Mainlining support for MStar ARMv7 SoCs; Where to start? Daniel Palmer @ 2019-09-10 14:59 ` Matthias Brugger 2019-09-10 15:10 ` Chen-Yu Tsai 0 siblings, 1 reply; 4+ messages in thread From: Matthias Brugger @ 2019-09-10 14:59 UTC (permalink / raw) To: Daniel Palmer, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Mainlining support for MStar ARMv7 SoCs; Where to start? 2019-09-10 14:59 ` Matthias Brugger @ 2019-09-10 15:10 ` Chen-Yu Tsai 2019-09-10 16:59 ` Daniel Palmer 0 siblings, 1 reply; 4+ messages in thread From: Chen-Yu Tsai @ 2019-09-10 15:10 UTC (permalink / raw) To: Daniel Palmer; +Cc: Matthias Brugger, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Mainlining support for MStar ARMv7 SoCs; Where to start? 2019-09-10 15:10 ` Chen-Yu Tsai @ 2019-09-10 16:59 ` Daniel Palmer 0 siblings, 0 replies; 4+ messages in thread From: Daniel Palmer @ 2019-09-10 16:59 UTC (permalink / raw) To: Chen-Yu Tsai; +Cc: Matthias Brugger, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-09-10 16:59 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-10 14:18 Mainlining support for MStar ARMv7 SoCs; Where to start? Daniel Palmer 2019-09-10 14:59 ` Matthias Brugger 2019-09-10 15:10 ` Chen-Yu Tsai 2019-09-10 16:59 ` Daniel Palmer
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).