From: Rich Felker <dalias@libc.org> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Rob Landley <rob@landley.net>, Simon Horman <horms@verge.net.au>, linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org, Yoshinori Sato <ysato@users.sourceforge.jp>, Geert Uytterhoeven <geert@linux-m68k.org>, Andrew Morton <akpm@linux-foundation.org>, Peter Zijlstra <peterz@infradead.org>, "D. Jeff Dionne" <jeff@uclinux.org> Subject: Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections Date: Fri, 08 Jan 2016 19:40:09 +0000 [thread overview] Message-ID: <20160108194009.GM238@brightrain.aerifal.cx> (raw) In-Reply-To: <7119737.DzNTr3WlaV@avalon> On Fri, Jan 08, 2016 at 08:28:51PM +0200, Laurent Pinchart wrote: > > The current list is not a Renesas list, it is a Linux list for the > > SuperH architecture port. Says so on the tin, and that was its history > > until pretty recently. Renesas moving away from the SuperH architecture > > doesn't change that this is the Linux arch/sh list. > > > > We aren't proposing to rename the arch/sh directory to "jcore", so > > "linux-sh@vger.kernel.org" remains the logical name for this list. The > > new stuff is intentionally backwards compatible with the old stuff, > > How about IP cores around the CPU, do you plan to develop cores compatible > with the Renesas implementations, or go for something else ? If we end up > sharing the same peripherals between multiple architectures we will need to > decide on how to coordinate the work. To my knowledge, aside from the cpu which is of course ISA-compatible, none of the current J-Core SOC components ("IP") are interface-compatible with Renesas ones. I'm aiming to put as much as possible in drivers/ rather than arch/sh/ because it should all be shareable with other open-hardware cpus. We're already using uartlite from drivers/ and I have some patches for it I still need to send upstream, including SMP fixes and earlycon support. > > and we are happy to maintain compatibility with the old stuff, and have > > current plans to move it to device tree. (We just need a lot more legacy > > test hardware...) > > I personally don't think that's worth it given that most of the legacy > hardware is buried under a thick layer of dust (when not used as coasters or > door stoppers). We probably need to gauge the level of interest in preserving support for legacy hardware. I don't want to gratuitously drop anything, and I think the device tree conversion will help us avoid that to some extent by moving the bulk of hardware/board support from code to data, but I will need to find a way to get my hands on some of the old hardware if we want to verify that I'm not breaking it. Another consideration is what qemu emulates, which right now is the legacy hardware. After J2 support, my first sh kernel priority is getting to the point where it can boot in qemu-system-sh4 using device tree, and where qemu can be configured based on a device tree, so that we can actually provide a reasonable amount of ram to run a modern system. I know Rob is interested in this to be able to test full system builds, native compiling, etc. Rich
WARNING: multiple messages have this Message-ID (diff)
From: Rich Felker <dalias@libc.org> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Rob Landley <rob@landley.net>, Simon Horman <horms@verge.net.au>, linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org, Yoshinori Sato <ysato@users.sourceforge.jp>, Geert Uytterhoeven <geert@linux-m68k.org>, Andrew Morton <akpm@linux-foundation.org>, Peter Zijlstra <peterz@infradead.org>, "D. Jeff Dionne" <jeff@uclinux.org> Subject: Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections Date: Fri, 8 Jan 2016 14:40:09 -0500 [thread overview] Message-ID: <20160108194009.GM238@brightrain.aerifal.cx> (raw) In-Reply-To: <7119737.DzNTr3WlaV@avalon> On Fri, Jan 08, 2016 at 08:28:51PM +0200, Laurent Pinchart wrote: > > The current list is not a Renesas list, it is a Linux list for the > > SuperH architecture port. Says so on the tin, and that was its history > > until pretty recently. Renesas moving away from the SuperH architecture > > doesn't change that this is the Linux arch/sh list. > > > > We aren't proposing to rename the arch/sh directory to "jcore", so > > "linux-sh@vger.kernel.org" remains the logical name for this list. The > > new stuff is intentionally backwards compatible with the old stuff, > > How about IP cores around the CPU, do you plan to develop cores compatible > with the Renesas implementations, or go for something else ? If we end up > sharing the same peripherals between multiple architectures we will need to > decide on how to coordinate the work. To my knowledge, aside from the cpu which is of course ISA-compatible, none of the current J-Core SOC components ("IP") are interface-compatible with Renesas ones. I'm aiming to put as much as possible in drivers/ rather than arch/sh/ because it should all be shareable with other open-hardware cpus. We're already using uartlite from drivers/ and I have some patches for it I still need to send upstream, including SMP fixes and earlycon support. > > and we are happy to maintain compatibility with the old stuff, and have > > current plans to move it to device tree. (We just need a lot more legacy > > test hardware...) > > I personally don't think that's worth it given that most of the legacy > hardware is buried under a thick layer of dust (when not used as coasters or > door stoppers). We probably need to gauge the level of interest in preserving support for legacy hardware. I don't want to gratuitously drop anything, and I think the device tree conversion will help us avoid that to some extent by moving the bulk of hardware/board support from code to data, but I will need to find a way to get my hands on some of the old hardware if we want to verify that I'm not breaking it. Another consideration is what qemu emulates, which right now is the legacy hardware. After J2 support, my first sh kernel priority is getting to the point where it can boot in qemu-system-sh4 using device tree, and where qemu can be configured based on a device tree, so that we can actually provide a reasonable amount of ram to run a modern system. I know Rob is interested in this to be able to test full system builds, native compiling, etc. Rich
next prev parent reply other threads:[~2016-01-08 19:40 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-01-08 4:39 [PATCH 0/2] Resume maintenance & development of arch/sh Rich Felker 2016-01-08 4:39 ` Rich Felker 2016-01-08 4:39 ` [PATCH 1/2] MAINTAINERS: return arch/sh to maintained state, with new maintainers Rich Felker 2016-01-08 4:39 ` Rich Felker 2016-01-11 17:53 ` Peter Zijlstra 2016-01-11 17:53 ` Peter Zijlstra 2016-01-13 1:40 ` Simon Horman 2016-01-13 1:40 ` Simon Horman 2016-01-15 0:52 ` Rich Felker 2016-01-15 0:52 ` Rich Felker 2016-01-15 9:31 ` Geert Uytterhoeven 2016-01-15 9:31 ` Geert Uytterhoeven 2016-01-17 2:32 ` Rich Felker 2016-01-17 2:32 ` Rich Felker 2016-01-17 8:48 ` Geert Uytterhoeven 2016-01-17 8:48 ` Geert Uytterhoeven 2016-01-08 4:40 ` [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections Rich Felker 2016-01-08 4:40 ` Rich Felker 2016-01-08 6:56 ` Simon Horman 2016-01-08 6:56 ` Simon Horman 2016-01-08 9:01 ` Geert Uytterhoeven 2016-01-08 9:01 ` Geert Uytterhoeven 2016-01-08 18:21 ` Rich Felker 2016-01-08 18:21 ` Rich Felker 2016-01-08 20:35 ` Geert Uytterhoeven 2016-01-08 20:35 ` Geert Uytterhoeven 2016-01-08 20:52 ` Rich Felker 2016-01-08 20:52 ` Rich Felker 2016-01-10 19:41 ` Geert Uytterhoeven 2016-01-10 19:41 ` Geert Uytterhoeven 2016-01-08 17:35 ` Rob Landley 2016-01-08 17:35 ` Rob Landley 2016-01-08 18:28 ` Laurent Pinchart 2016-01-08 18:28 ` Laurent Pinchart 2016-01-08 19:40 ` Rich Felker [this message] 2016-01-08 19:40 ` Rich Felker 2016-01-08 23:15 ` Laurent Pinchart 2016-01-08 23:15 ` Laurent Pinchart 2016-01-08 22:50 ` Rob Landley 2016-01-08 22:50 ` Rob Landley 2016-01-10 20:05 ` Geert Uytterhoeven 2016-01-10 20:05 ` Geert Uytterhoeven 2016-01-11 2:02 ` Rob Landley 2016-01-11 2:02 ` Rob Landley 2016-01-11 2:22 ` uClinux.org 2016-01-11 2:22 ` uClinux.org 2016-01-08 18:51 ` Rich Felker 2016-01-08 18:51 ` Rich Felker 2016-01-08 18:03 ` Sergei Shtylyov 2016-01-08 18:03 ` Sergei Shtylyov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160108194009.GM238@brightrain.aerifal.cx \ --to=dalias@libc.org \ --cc=akpm@linux-foundation.org \ --cc=geert@linux-m68k.org \ --cc=horms@verge.net.au \ --cc=jeff@uclinux.org \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=peterz@infradead.org \ --cc=rob@landley.net \ --cc=ysato@users.sourceforge.jp \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.