| Message ID | tencent_BC64B7B1876F5D10479BD19112F73F262505@qq.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | riscv: add initial support for SpacemiT K1 | expand |
On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote: > .../sifive,plic-1.0.0.yaml | 5 +- > .../devicetree/bindings/riscv/cpus.yaml | 1 + > .../devicetree/bindings/riscv/spacemit.yaml | 24 ++ > .../bindings/timer/sifive,clint.yaml | 4 +- > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > arch/riscv/Kconfig.socs | 5 + > arch/riscv/boot/dts/Makefile | 1 + > arch/riscv/boot/dts/spacemit/Makefile | 2 + > arch/riscv/boot/dts/spacemit/bananapi-f3.dts | 19 ++ > arch/riscv/boot/dts/spacemit/k1.dtsi | 281 ++++++++++++++++++ > arch/riscv/configs/defconfig | 1 + No MAINTAINERS update, so I figure that means you don't want to maintain it going forwards? If there's someone out that that does care about the spacemit k1 (Jesse maybe?), then I'd be more than happy to have them look after it. Thanks, Conor.
Hi Conor Thanks for bringing this up On 19:35 Sun 16 Jun , Conor Dooley wrote: > On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote: > > No MAINTAINERS update, so I figure that means you don't want to maintain > it going forwards? If there's someone out that that does care about the > spacemit k1 (Jesse maybe?), then I'd be more than happy to have them > look after it. Yangyu kind of has limited time, too many stuff for him.. I'd volunteered to help on this if it can fill the gap Also I'd be more than happy if anyone willing step forward to co-maintain..
> On Jun 17, 2024, at 06:48, Yixun Lan <dlan@gentoo.org> wrote: > > Hi Conor > Thanks for bringing this up > > On 19:35 Sun 16 Jun , Conor Dooley wrote: >> On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote: >> >> No MAINTAINERS update, so I figure that means you don't want to maintain >> it going forwards? If there's someone out that that does care about the >> spacemit k1 (Jesse maybe?), then I'd be more than happy to have them >> look after it. Actually, I don’t know how to be a maintainer. Should I have to provide a new git tree and all the new patches merged to my tree and then submit a git pull? Or reuse the RISC-V mailing list and just give a review, and the patches come to soc misc tree? I would like the latter one. > Yangyu kind of has limited time, too many stuff for him.. > True. Maybe I can have a review and test the patch in one week. However, providing a review and test in 2-3 days is sometimes hard for me. > I'd volunteered to help on this if it can fill the gap > Also I'd be more than happy if anyone willing step forward to co-maintain.. > Thanks. Really appreciate it. Should I provide a diff like this: diff --git a/MAINTAINERS b/MAINTAINERS index d6c90161c7bf..718d30996f12 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -19306,6 +19306,7 @@ F: arch/riscv/boot/dts/ X: arch/riscv/boot/dts/allwinner/ X: arch/riscv/boot/dts/renesas/ X: arch/riscv/boot/dts/sophgo/ +X: arch/riscv/boot/dts/spacemit/ RISC-V PMU DRIVERS M: Atish Patra <atishp@atishpatra.org> @@ -21004,6 +21005,13 @@ W: https://linuxtv.org Q: http://patchwork.linuxtv.org/project/linux-media/list/ F: drivers/media/dvb-frontends/sp2* +SPACEMIT DEVICETREES and DRIVERS +M: Yangyu Chen <cyy@cyyself.name> +M: Yixun Lan <dlan@gentoo.org> +S: Maintained +F: Documentation/devicetree/bindings/riscv/spacemit.yaml +F: arch/riscv/boot/dts/spacemit/ + SPANISH DOCUMENTATION M: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> R: Avadhut Naik <avadhut.naik@amd.com> Thanks, Yangyu Chen > -- > Yixun Lan (dlan) > Gentoo Linux Developer > GPG Key ID AABEFD55
On Mon, Jun 17, 2024 at 10:00:32AM +0800, Yangyu Chen wrote: > > > On Jun 17, 2024, at 06:48, Yixun Lan <dlan@gentoo.org> wrote: > > > > Hi Conor > > Thanks for bringing this up > > > > On 19:35 Sun 16 Jun , Conor Dooley wrote: > >> On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote: > >> > >> No MAINTAINERS update, so I figure that means you don't want to maintain > >> it going forwards? If there's someone out that that does care about the > >> spacemit k1 (Jesse maybe?), then I'd be more than happy to have them > >> look after it. > > Actually, I don’t know how to be a maintainer. Should I have to > provide a new git tree and all the new patches merged to my tree > and then submit a git pull? Yeah, in the ideal case :) I wrote a document with information as to how this all works for new platform maintainers: https://docs.kernel.org/process/maintainer-soc.html#information-for-new-submaintainers > Or reuse the RISC-V mailing list and > just give a review, and the patches come to soc misc tree? I would > like the latter one. If you don't have the time/interest/whatever in having a tree, then sure, I can apply the patches for it. I'd rather have someone look after a tree themselves, but this option is better than me growing another platform to look after. > > Yangyu kind of has limited time, too many stuff for him.. > > > > True. Maybe I can have a review and test the patch in one week. > However, providing a review and test in 2-3 days is sometimes hard > for me. It would be unreasonable to expect a 2-3 day turnaround :) > > I'd volunteered to help on this if it can fill the gap > > Also I'd be more than happy if anyone willing step forward to co-maintain.. > > > > Thanks. Really appreciate it. > > Should I provide a diff like this: > > diff --git a/MAINTAINERS b/MAINTAINERS > index d6c90161c7bf..718d30996f12 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -19306,6 +19306,7 @@ F: arch/riscv/boot/dts/ > X: arch/riscv/boot/dts/allwinner/ > X: arch/riscv/boot/dts/renesas/ > X: arch/riscv/boot/dts/sophgo/ > +X: arch/riscv/boot/dts/spacemit/ If you don't want to apply patches, drop this hunk. > RISC-V PMU DRIVERS > M: Atish Patra <atishp@atishpatra.org> > @@ -21004,6 +21005,13 @@ W: https://linuxtv.org > Q: http://patchwork.linuxtv.org/project/linux-media/list/ > F: drivers/media/dvb-frontends/sp2* > > +SPACEMIT DEVICETREES and DRIVERS > +M: Yangyu Chen <cyy@cyyself.name> > +M: Yixun Lan <dlan@gentoo.org> Jesse mentioned on IRC she was interested in the platform, so maybe she would like to be involved too. Thanks, Conor.
在 2024-06-17星期一的 10:00 +0800，Yangyu Chen写道： > > > On Jun 17, 2024, at 06:48, Yixun Lan <dlan@gentoo.org> wrote: > > > > Hi Conor > > Thanks for bringing this up > > > > On 19:35 Sun 16 Jun , Conor Dooley wrote: > > > On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote: > > > > > > No MAINTAINERS update, so I figure that means you don't want to > > > maintain > > > it going forwards? If there's someone out that that does care > > > about the > > > spacemit k1 (Jesse maybe?), then I'd be more than happy to have > > > them > > > look after it. > > Actually, I don’t know how to be a maintainer. Should I have to > provide a new git tree and all the new patches merged to my tree > and then submit a git pull? Or reuse the RISC-V mailing list and > just give a review, and the patches come to soc misc tree? I would > like the latter one. Well I think for these SoCs the latter is the case. BTW I could volunteer as a maintainer, or at least a reviewer here. > > > Yangyu kind of has limited time, too many stuff for him.. > > > > True. Maybe I can have a review and test the patch in one week. > However, providing a review and test in 2-3 days is sometimes hard > for me. > > > I'd volunteered to help on this if it can fill the gap > > Also I'd be more than happy if anyone willing step forward to co- > > maintain.. > > > > Thanks. Really appreciate it. > > Should I provide a diff like this: > > diff --git a/MAINTAINERS b/MAINTAINERS > index d6c90161c7bf..718d30996f12 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -19306,6 +19306,7 @@ F: arch/riscv/boot/dts/ > X: arch/riscv/boot/dts/allwinner/ > X: arch/riscv/boot/dts/renesas/ > X: arch/riscv/boot/dts/sophgo/ > +X: arch/riscv/boot/dts/spacemit/ > > RISC-V PMU DRIVERS > M: Atish Patra <atishp@atishpatra.org> > @@ -21004,6 +21005,13 @@ W: https://linuxtv.org > Q: http://patchwork.linuxtv.org/project/linux-media/list/ > F: drivers/media/dvb-frontends/sp2* > > +SPACEMIT DEVICETREES and DRIVERS > +M: Yangyu Chen <cyy@cyyself.name> > +M: Yixun Lan <dlan@gentoo.org> > +S: Maintained > +F: Documentation/devicetree/bindings/riscv/spacemit.yaml > +F: arch/riscv/boot/dts/spacemit/ > + > SPANISH DOCUMENTATION > M: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> > R: Avadhut Naik <avadhut.naik@amd.com> > > Thanks, > Yangyu Chen > > > -- > > Yixun Lan (dlan) > > Gentoo Linux Developer > > GPG Key ID AABEFD55 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote: > Hi Conor > Thanks for bringing this up > > On 19:35 Sun 16 Jun , Conor Dooley wrote: > > On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote: > > > > No MAINTAINERS update, so I figure that means you don't want to maintain > > it going forwards? If there's someone out that that does care about the > > spacemit k1 (Jesse maybe?), then I'd be more than happy to have them > > look after it. > Yangyu kind of has limited time, too many stuff for him.. > > I'd volunteered to help on this if it can fill the gap > Also I'd be more than happy if anyone willing step forward to co-maintain.. Does maintainership work like this? Is willing to do enough? FWICT, maintainership involves active patch contributing, reviewing and maintaining the whole SoC. It is better to take over the maintainership after showing enough patch contributions and understanding of the SoC. > > -- > Yixun Lan (dlan) > Gentoo Linux Developer > GPG Key ID AABEFD55 > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Mon, Jun 17, 2024 at 10:11:17PM +0800, Jisheng Zhang wrote: > On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote: > > Hi Conor > > Thanks for bringing this up > > > > On 19:35 Sun 16 Jun , Conor Dooley wrote: > > > On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote: > > > > > > No MAINTAINERS update, so I figure that means you don't want to maintain > > > it going forwards? If there's someone out that that does care about the > > > spacemit k1 (Jesse maybe?), then I'd be more than happy to have them > > > look after it. > > Yangyu kind of has limited time, too many stuff for him.. > > > > I'd volunteered to help on this if it can fill the gap > > Also I'd be more than happy if anyone willing step forward to co-maintain.. > > Does maintainership work like this? Is willing to do enough? > FWICT, maintainership involves active patch contributing, reviewing and > maintaining the whole SoC. It is better to take over the maintainership > after showing enough patch contributions and understanding of the SoC. I was going to reply to your other patch about providing more complete "basic" support for the SoC, but I guess I'll reply here and address both points. After the k230 and th1520, which were both merged with very basic support and have made very little progress towards being a useful platform, I'm pretty reluctant to merge another platform in a super basic state. I was going to make this point before you brought it up, but it's good to know I am not the only one with that view. To be clear, I'm not pointing blame for those platforms, I'd just like to avoid a repeat. If Yangyu doesn't have time to do any development work on the platform, I'd like to see someone else (and as I mentioned Jesse is interested) take on getting some of the basic driver patches written and merge only when those are accepted. Having no in-tree clock and pinctrl drivers is definitely a hindrance to other people doing parallel development of drivers and I'd like to avoid that. Getting back to your point in this mail, whoever gets the platform to that state is well suited to looking after it going forwards. Some other interested parties could also join as reviewers. I don't want to see people joining as maintainers that are not going to have an interest in the platform going forward, as that'll just end up with me as the defacto maintainer. Thanks, Conor.
> On Jun 17, 2024, at 23:32, Conor Dooley <conor@kernel.org> wrote: > > On Mon, Jun 17, 2024 at 10:11:17PM +0800, Jisheng Zhang wrote: >> On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote: >>> Hi Conor >>> Thanks for bringing this up >>> >>> On 19:35 Sun 16 Jun , Conor Dooley wrote: >>>> On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote: >>>> >>>> No MAINTAINERS update, so I figure that means you don't want to maintain >>>> it going forwards? If there's someone out that that does care about the >>>> spacemit k1 (Jesse maybe?), then I'd be more than happy to have them >>>> look after it. >>> Yangyu kind of has limited time, too many stuff for him.. >>> >>> I'd volunteered to help on this if it can fill the gap >>> Also I'd be more than happy if anyone willing step forward to co-maintain.. >> >> Does maintainership work like this? Is willing to do enough? >> FWICT, maintainership involves active patch contributing, reviewing and >> maintaining the whole SoC. It is better to take over the maintainership >> after showing enough patch contributions and understanding of the SoC. > > I was going to reply to your other patch about providing more complete > "basic" support for the SoC, but I guess I'll reply here and address > both points. After the k230 and th1520, which were both merged with very > basic support and have made very little progress towards being a useful > platform, I'm pretty reluctant to merge another platform in a super > basic state. I was going to make this point before you brought it up, > but it's good to know I am not the only one with that view. To be clear, > I'm not pointing blame for those platforms, I'd just like to avoid a > repeat. If Yangyu doesn't have time to do any development work on the > platform, I'd like to see someone else (and as I mentioned Jesse is > interested) take on getting some of the basic driver patches written and > merge only when those are accepted. Having no in-tree clock and pinctrl > drivers is definitely a hindrance to other people doing parallel > development of drivers and I'd like to avoid that. > That's also my concern for the first time when I submitted initial support for K230. However, for SpacemiT K1, things went differently for its UART, and the vendor patched OpenSBI with their NOC-based HSM. They didn't use CLINT-MSWI as SBI HSM driver. The vendor uses a special intel pxa uart driver, marked deprecated in the kernel and incompatible with ns16550. If we use ns16550 in the dt, the behavior of uart is like the uart has no interrupt and stops working permanently when fifo overruns, making many developers not know how to start unless they use the SBI HVC console, which needs to turn on CONFIG_NONPORTABLE. For the OpenSBI, the vendor does not provide enough ISA string, which their chip might support, such as Zicboz. Thus, the OpenSBI does not correctly set up the corresponding M-Mode CSR, making the kernel panic when the ISA string contains this extension. These two things takes me about one week to get the initial mainline kernel with full ISA extension and UART to work. Providing this information in the commit message helps attract more developers to start developing quickly. I don't mind whether this series patch will be merged or not. The meaning of this series is just providing these informations. However, I think some details about bringing up a very basic kernel are essential to attract more developers. If a platform has already attracted some developer's attention. Providing initial support with the commit message to show how to bring it up is not bad. The point is that if a developer like me has already done this but does not have much time to do further development, should the developer become the maintainer? If not, should a developer submit patches like this to the mailing list to provide this information in the commit message and make it easier for other developers to do further development? > Getting back to your point in this mail, whoever gets the platform to > that state is well suited to looking after it going forwards. Some other > interested parties could also join as reviewers. I don't want to see > people joining as maintainers that are not going to have an interest > in the platform going forward, as that'll just end up with me as the > defacto maintainer. > I agree. I also have no confidence in joining as a maintainer. That's why I didn't change the MAINTAINERS for the first time. Thanks, Yangyu Chen
On Tue, Jun 18, 2024 at 12:39:30AM +0800, Yangyu Chen wrote: > > > > On Jun 17, 2024, at 23:32, Conor Dooley <conor@kernel.org> wrote: > > > > On Mon, Jun 17, 2024 at 10:11:17PM +0800, Jisheng Zhang wrote: > >> On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote: > >>> Hi Conor > >>> Thanks for bringing this up > >>> > >>> On 19:35 Sun 16 Jun , Conor Dooley wrote: > >>>> On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote: > >>>> > >>>> No MAINTAINERS update, so I figure that means you don't want to maintain > >>>> it going forwards? If there's someone out that that does care about the > >>>> spacemit k1 (Jesse maybe?), then I'd be more than happy to have them > >>>> look after it. > >>> Yangyu kind of has limited time, too many stuff for him.. > >>> > >>> I'd volunteered to help on this if it can fill the gap > >>> Also I'd be more than happy if anyone willing step forward to co-maintain.. > >> > >> Does maintainership work like this? Is willing to do enough? > >> FWICT, maintainership involves active patch contributing, reviewing and > >> maintaining the whole SoC. It is better to take over the maintainership > >> after showing enough patch contributions and understanding of the SoC. > > > > I was going to reply to your other patch about providing more complete > > "basic" support for the SoC, but I guess I'll reply here and address > > both points. After the k230 and th1520, which were both merged with very > > basic support and have made very little progress towards being a useful > > platform, I'm pretty reluctant to merge another platform in a super > > basic state. I was going to make this point before you brought it up, > > but it's good to know I am not the only one with that view. To be clear, > > I'm not pointing blame for those platforms, I'd just like to avoid a > > repeat. If Yangyu doesn't have time to do any development work on the > > platform, I'd like to see someone else (and as I mentioned Jesse is > > interested) take on getting some of the basic driver patches written and > > merge only when those are accepted. Having no in-tree clock and pinctrl > > drivers is definitely a hindrance to other people doing parallel > > development of drivers and I'd like to avoid that. > > > > That's also my concern for the first time when I submitted initial > support for K230. However, for SpacemiT K1, things went differently > for its UART, and the vendor patched OpenSBI with their NOC-based > HSM. They didn't use CLINT-MSWI as SBI HSM driver. > > The vendor uses a special intel pxa uart driver, marked deprecated > in the kernel and incompatible with ns16550. If we use ns16550 in > the dt, the behavior of uart is like the uart has no interrupt and > stops working permanently when fifo overruns, making many developers > not know how to start unless they use the SBI HVC console, which > needs to turn on CONFIG_NONPORTABLE. This I just do not understand. Why did they use this IP? Is it free? Did they use it before for something else? It's a rather strange design choice to me. > For the OpenSBI, the vendor does not provide enough ISA string, > which their chip might support, such as Zicboz. Thus, the OpenSBI > does not correctly set up the corresponding M-Mode CSR, making the > kernel panic when the ISA string contains this extension. > > These two things takes me about one week to get the initial mainline > kernel with full ISA extension and UART to work. Providing this > information in the commit message helps attract more developers to > start developing quickly. > > I don't mind whether this series patch will be merged or not. The > meaning of this series is just providing these informations. However, > I think some details about bringing up a very basic kernel are > essential to attract more developers. If a platform has already > attracted some developer's attention. Providing initial support > with the commit message to show how to bring it up is not bad. > > The point is that if a developer like me has already done this but > does not have much time to do further development, should the > developer become the maintainer? If not, should a developer submit > patches like this to the mailing list to provide this information > in the commit message and make it easier for other developers to > do further development? I think, as you did, sending patches for this state is very valuable. I'd just like to see someone expand on it before it gets applied, so that the initial platform support in the kernel is in a better state. > > Getting back to your point in this mail, whoever gets the platform to > > that state is well suited to looking after it going forwards. Some other > > interested parties could also join as reviewers. I don't want to see > > people joining as maintainers that are not going to have an interest > > in the platform going forward, as that'll just end up with me as the > > defacto maintainer. > > > > I agree. I also have no confidence in joining as a maintainer. > That's why I didn't change the MAINTAINERS for the first time. Yeah, that's fine. Consider this part of the thread my attempt to solicit people to maintain the platform, rather than bashing you. I appreciate the work you've done :) Thanks, Conor.
> On Jun 18, 2024, at 01:14, Conor Dooley <conor@kernel.org> wrote: > > On Tue, Jun 18, 2024 at 12:39:30AM +0800, Yangyu Chen wrote: >> >> The vendor uses a special intel pxa uart driver, marked deprecated >> in the kernel and incompatible with ns16550. If we use ns16550 in >> the dt, the behavior of uart is like the uart has no interrupt and >> stops working permanently when fifo overruns, making many developers >> not know how to start unless they use the SBI HVC console, which >> needs to turn on CONFIG_NONPORTABLE. > > This I just do not understand. Why did they use this IP? Is it free? > Did they use it before for something else? It's a rather strange design > choice to me. I don't know either. However, PXA is a subfamily of XScale. The kernel also probed the UART as an XScale. So, using XScale compatible string is OK.
On Mon, Jun 17, 2024 at 04:32:59PM +0100, Conor Dooley wrote: > On Mon, Jun 17, 2024 at 10:11:17PM +0800, Jisheng Zhang wrote: > > On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote: > > > Hi Conor > > > Thanks for bringing this up > > > > > > On 19:35 Sun 16 Jun , Conor Dooley wrote: > > > > On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote: > > > > > > > > No MAINTAINERS update, so I figure that means you don't want to maintain > > > > it going forwards? If there's someone out that that does care about the > > > > spacemit k1 (Jesse maybe?), then I'd be more than happy to have them > > > > look after it. > > > Yangyu kind of has limited time, too many stuff for him.. > > > > > > I'd volunteered to help on this if it can fill the gap > > > Also I'd be more than happy if anyone willing step forward to co-maintain.. > > > > Does maintainership work like this? Is willing to do enough? > > FWICT, maintainership involves active patch contributing, reviewing and > > maintaining the whole SoC. It is better to take over the maintainership > > after showing enough patch contributions and understanding of the SoC. > > I was going to reply to your other patch about providing more complete > "basic" support for the SoC, but I guess I'll reply here and address > both points. After the k230 and th1520, which were both merged with very When I saw k230 a few minutes ago, I assumed you mean k210 since I didn't found k230 support in linus tree now. After searching the maillist, I found oh there is a k230 series which is similar to this series, no pinctrl, no clk, no reset. Since the incomplete K230 initial series hasn't been merged into Linus tree now, is it possible to drop it so that we can avoid the same mistake for k230. > basic support and have made very little progress towards being a useful > platform, I'm pretty reluctant to merge another platform in a super > basic state. I was going to make this point before you brought it up, > but it's good to know I am not the only one with that view. To be clear, > I'm not pointing blame for those platforms, I'd just like to avoid a Yep previously I thought it was fine to use a fixed clock or dummy clock during the initial patches, but I changed my mind now, especially after Samuel complained the cv1800b reset dt changes. > repeat. If Yangyu doesn't have time to do any development work on the > platform, I'd like to see someone else (and as I mentioned Jesse is > interested) take on getting some of the basic driver patches written and > merge only when those are accepted. Having no in-tree clock and pinctrl > drivers is definitely a hindrance to other people doing parallel > development of drivers and I'd like to avoid that. > > Getting back to your point in this mail, whoever gets the platform to > that state is well suited to looking after it going forwards. Some other The person who can bring the platfrom support to a well-moduled state, IE, proper clk, pinctrl, reset drivers shows the passion, the code contribution and solid understanding of the SoC, sure he/she is definitely suited to maintain the SoC. I just don't think it's a good practice a person can became maintainer even w/o one LoC contrubition to the SoC, because IMHO code contribution matters for maintainership. > interested parties could also join as reviewers. I don't want to see > people joining as maintainers that are not going to have an interest > in the platform going forward, as that'll just end up with me as the > defacto maintainer. > > Thanks, > Conor.
On Tue, Jun 18, 2024 at 12:39:30AM +0800, Yangyu Chen wrote: > > > > On Jun 17, 2024, at 23:32, Conor Dooley <conor@kernel.org> wrote: > > > > On Mon, Jun 17, 2024 at 10:11:17PM +0800, Jisheng Zhang wrote: > >> On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote: > >>> Hi Conor > >>> Thanks for bringing this up > >>> > >>> On 19:35 Sun 16 Jun , Conor Dooley wrote: > >>>> On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote: > >>>> > >>>> No MAINTAINERS update, so I figure that means you don't want to maintain > >>>> it going forwards? If there's someone out that that does care about the > >>>> spacemit k1 (Jesse maybe?), then I'd be more than happy to have them > >>>> look after it. > >>> Yangyu kind of has limited time, too many stuff for him.. > >>> > >>> I'd volunteered to help on this if it can fill the gap > >>> Also I'd be more than happy if anyone willing step forward to co-maintain.. > >> > >> Does maintainership work like this? Is willing to do enough? > >> FWICT, maintainership involves active patch contributing, reviewing and > >> maintaining the whole SoC. It is better to take over the maintainership > >> after showing enough patch contributions and understanding of the SoC. > > > > I was going to reply to your other patch about providing more complete > > "basic" support for the SoC, but I guess I'll reply here and address > > both points. After the k230 and th1520, which were both merged with very > > basic support and have made very little progress towards being a useful > > platform, I'm pretty reluctant to merge another platform in a super > > basic state. I was going to make this point before you brought it up, > > but it's good to know I am not the only one with that view. To be clear, > > I'm not pointing blame for those platforms, I'd just like to avoid a > > repeat. If Yangyu doesn't have time to do any development work on the > > platform, I'd like to see someone else (and as I mentioned Jesse is > > interested) take on getting some of the basic driver patches written and > > merge only when those are accepted. Having no in-tree clock and pinctrl > > drivers is definitely a hindrance to other people doing parallel > > development of drivers and I'd like to avoid that. > > > > That's also my concern for the first time when I submitted initial > support for K230. However, for SpacemiT K1, things went differently > for its UART, and the vendor patched OpenSBI with their NOC-based > HSM. They didn't use CLINT-MSWI as SBI HSM driver. > > The vendor uses a special intel pxa uart driver, marked deprecated > in the kernel and incompatible with ns16550. If we use ns16550 in > the dt, the behavior of uart is like the uart has no interrupt and > stops working permanently when fifo overruns, making many developers > not know how to start unless they use the SBI HVC console, which > needs to turn on CONFIG_NONPORTABLE. > > For the OpenSBI, the vendor does not provide enough ISA string, > which their chip might support, such as Zicboz. Thus, the OpenSBI > does not correctly set up the corresponding M-Mode CSR, making the > kernel panic when the ISA string contains this extension. > > These two things takes me about one week to get the initial mainline > kernel with full ISA extension and UART to work. Providing this > information in the commit message helps attract more developers to > start developing quickly. > > I don't mind whether this series patch will be merged or not. The > meaning of this series is just providing these informations. However, > I think some details about bringing up a very basic kernel are > essential to attract more developers. If a platform has already > attracted some developer's attention. Providing initial support > with the commit message to show how to bring it up is not bad. > > The point is that if a developer like me has already done this but > does not have much time to do further development, should the > developer become the maintainer? If not, should a developer submit > patches like this to the mailing list to provide this information > in the commit message and make it easier for other developers to > do further development? This patch series is valueable, especially for the person who has passion, time to expand the series to get pinctrl, reset and clk ready so that the SoC is properly modeled even in the initial stage. > > > Getting back to your point in this mail, whoever gets the platform to > > that state is well suited to looking after it going forwards. Some other > > interested parties could also join as reviewers. I don't want to see > > people joining as maintainers that are not going to have an interest > > in the platform going forward, as that'll just end up with me as the > > defacto maintainer. > > > > I agree. I also have no confidence in joining as a maintainer. > That's why I didn't change the MAINTAINERS for the first time. > > Thanks, > Yangyu Chen >
On Tue, Jun 18, 2024 at 01:42:34AM +0800, Yangyu Chen wrote: > > > > On Jun 18, 2024, at 01:14, Conor Dooley <conor@kernel.org> wrote: > > > > On Tue, Jun 18, 2024 at 12:39:30AM +0800, Yangyu Chen wrote: > >> > >> The vendor uses a special intel pxa uart driver, marked deprecated > >> in the kernel and incompatible with ns16550. If we use ns16550 in > >> the dt, the behavior of uart is like the uart has no interrupt and > >> stops working permanently when fifo overruns, making many developers > >> not know how to start unless they use the SBI HVC console, which > >> needs to turn on CONFIG_NONPORTABLE. > > > > This I just do not understand. Why did they use this IP? Is it free? > > Did they use it before for something else? It's a rather strange design > > choice to me. > > I don't know either. However, PXA is a subfamily of XScale. The > kernel also probed the UART as an XScale. So, using XScale compatible > string is OK. Using a fallback to an Xscale compatible is okay, FTFY ;)
On Tue, Jun 18, 2024 at 12:34:27PM +0800, Jisheng Zhang wrote: > On Mon, Jun 17, 2024 at 04:32:59PM +0100, Conor Dooley wrote: > > On Mon, Jun 17, 2024 at 10:11:17PM +0800, Jisheng Zhang wrote: > > > On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote: > > > > Hi Conor > > > > Thanks for bringing this up > > > > > > > > On 19:35 Sun 16 Jun , Conor Dooley wrote: > > > > > On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote: > > > > > > > > > > No MAINTAINERS update, so I figure that means you don't want to maintain > > > > > it going forwards? If there's someone out that that does care about the > > > > > spacemit k1 (Jesse maybe?), then I'd be more than happy to have them > > > > > look after it. > > > > Yangyu kind of has limited time, too many stuff for him.. > > > > > > > > I'd volunteered to help on this if it can fill the gap > > > > Also I'd be more than happy if anyone willing step forward to co-maintain.. > > > > > > Does maintainership work like this? Is willing to do enough? > > > FWICT, maintainership involves active patch contributing, reviewing and > > > maintaining the whole SoC. It is better to take over the maintainership > > > after showing enough patch contributions and understanding of the SoC. > > > > I was going to reply to your other patch about providing more complete > > "basic" support for the SoC, but I guess I'll reply here and address > > both points. After the k230 and th1520, which were both merged with very > > When I saw k230 a few minutes ago, I assumed you mean k210 since I > didn't found k230 support in linus tree now. After searching the > maillist, I found oh there is a k230 series which is similar to this > series, no pinctrl, no clk, no reset. Since the incomplete K230 initial > series hasn't been merged into Linus tree now, is it possible to drop > it so that we can avoid the same mistake for k230. Yeah, I think you're right there and I should drop the k230 stuff from for-next. I forgot that it was not already in, because I had sent it for 6.10 and Arnd didn't like some of the inter-branch dependencies that my PR had and told me to drop it. If nobody really cares for getting the platform to a reasonably usable state, then I guess we will just not support it. And it seems like there's little interest in it, despite being the first system you could buy with ratified vector. It's not a great platform to work with documentation wise, at least as a non-Chinese speaker like myself nor is the U-Boot M-Mode -> OpenSBI -> Linux vendor boot flow good for iterating on kernels. > > basic support and have made very little progress towards being a useful > > platform, I'm pretty reluctant to merge another platform in a super > > basic state. I was going to make this point before you brought it up, > > but it's good to know I am not the only one with that view. To be clear, > > I'm not pointing blame for those platforms, I'd just like to avoid a > > Yep previously I thought it was fine to use a fixed clock or dummy clock > during the initial patches, but I changed my mind now, especially after > Samuel complained the cv1800b reset dt changes. > > > repeat. If Yangyu doesn't have time to do any development work on the > > platform, I'd like to see someone else (and as I mentioned Jesse is > > interested) take on getting some of the basic driver patches written and > > merge only when those are accepted. Having no in-tree clock and pinctrl > > drivers is definitely a hindrance to other people doing parallel > > development of drivers and I'd like to avoid that. > > > > Getting back to your point in this mail, whoever gets the platform to > > that state is well suited to looking after it going forwards. Some other > > The person who can bring the platfrom support to a well-moduled state, > IE, proper clk, pinctrl, reset drivers shows the passion, the code > contribution and solid understanding of the SoC, sure he/she is > definitely suited to maintain the SoC. I just don't think it's > a good practice a person can became maintainer even w/o one LoC > contrubition to the SoC, because IMHO code contribution matters > for maintainership. Right, and the th1520 is suffering a bit from that at the moment, the maintainers other than yourself haven't sent a single LoC for it, and have not gotten involved after you have become unable to spend time on it. I do know that things are likely to change there soon, which is good. Thanks, Conor.