| Message ID | 1434647946.861922@landley.net (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
On Thu, Jun 18, 2015 at 10:19:19AM -0700, Rob Landley wrote: > Changes to existing files to add 0pf j2 board support. > That's the second worse commit message and subject: line I've read today. And there's no signed off by line. And there was no 1/2 patch sent. And, most importantly: > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig I don't care about arch/sh/ stuff, why are you sending this to me? You have a bit of work to do here... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 18 Jun 2015 10:59:31 -0700 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Thu, Jun 18, 2015 at 10:19:19AM -0700, Rob Landley wrote: > > Changes to existing files to add 0pf j2 board support. > > > > That's the second worse commit message and subject: line I've read > today. Only the second worse today? Damn, you must get a lot of crappy change logs. > > And there's no signed off by line. > > And there was no 1/2 patch sent. > > And, most importantly: > > > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > > I don't care about arch/sh/ stuff, why are you sending this to me? Because even when you don't care, you still give back constructive feedback ;-) -- Steve > > You have a bit of work to do here... > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rob, On Thu, Jun 18, 2015 at 7:19 PM, Rob Landley <rob@landley.net> wrote: > Changes to existing files to add 0pf j2 board support. Thanks for your patch! Like Greg already said, splitting it up in logical parts and providing useful patch descriptions would be highly appreciated. > diff --git a/arch/sh/Makefile b/arch/sh/Makefile > index bf5b3f5..e609157 100644 > --- a/arch/sh/Makefile > +++ b/arch/sh/Makefile > @@ -31,6 +33,7 @@ isa-y := $(isa-y)-up > endif > > cflags-$(CONFIG_CPU_SH2) := $(call cc-option,-m2,) > +cflags-$(CONFIG_CPU_SH2J) := $(call cc-option,-m2,) This is superfluous, as CPU_SH2J selects CPU_SH2. > diff --git a/arch/sh/kernel/irq.c b/arch/sh/kernel/irq.c > index eb10ff8..7de9bcb 100644 > --- a/arch/sh/kernel/irq.c > +++ b/arch/sh/kernel/irq.c > @@ -20,6 +20,8 @@ > #include <asm/thread_info.h> > #include <cpu/mmu_context.h> > > +#include <asm/board-0pf.h> Board-specific inclusion in generic sh source file? > + > atomic_t irq_err_count; > > /* > @@ -175,11 +177,24 @@ void do_softirq_own_stack(void) > ); > } > #else > +#define noinline __attribute__((noinline)) > +static noinline void handle_irq_UART0(unsigned int irq) { generic_handle_irq(irq); } > +static noinline void handle_irq_UART1(unsigned int irq) { generic_handle_irq(irq); } > +static noinline void handle_irq_GPS(unsigned int irq) { generic_handle_irq(irq); } > +static noinline void handle_irq_EMAC(unsigned int irq) { generic_handle_irq(irq); } > static inline void handle_one_irq(unsigned int irq) > { > - generic_handle_irq(irq); > + switch(irq) { > + case Irq_UART0: handle_irq_UART0(irq); break; > + case Irq_UART1: handle_irq_UART1(irq); break; > + case Irq_GPS: handle_irq_GPS(irq); break; > + case Irq_EMAC: handle_irq_EMAC(irq); break; > + default: > + generic_handle_irq(irq); > + break; > + } What's the purpose of this change? > } > -#endif > +#endif // CONFIG_IRQSTACKS Please no C++-style comments (scripts/checkpatch.pl?) > diff --git a/arch/sh/mm/cache-sh2.c b/arch/sh/mm/cache-sh2.c > index a74259f..438eadb 100644 > --- a/arch/sh/mm/cache-sh2.c > +++ b/arch/sh/mm/cache-sh2.c > @@ -16,6 +17,30 @@ > #include <asm/cacheflush.h> > #include <asm/io.h> > > +#if defined(CONFIG_CPU_SUBTYPE_0PF) > + > +// Just flush the whole thing each time Likewise > +static void j2_flush_icache_range(void *fwoosh) > +{ > + __raw_writel(CCR_CACHE_RESET, CCR); > +} > + > +// This should never happen, but... Likewise. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/18/2015 12:59 PM, Greg Kroah-Hartman wrote: > On Thu, Jun 18, 2015 at 10:19:19AM -0700, Rob Landley wrote: >> Changes to existing files to add 0pf j2 board support. >> > > That's the second worse commit message and subject: line I've read > today. > > And there's no signed off by line. My bad. I've always sucked at filling out paperwork, and I didn't expect this to go in as is. But for the sake of following the official procedures (well, step 11 of of SubmittingPatches, it's not mentioned in any of the 26 steps of SubmitChecklist), here's the requested certification: Signed-off-by: Rob Landley <rob@landley.net> Reviewed-by: D. Jeff Dionne <jeff@uclinux.org> > And there was no 1/2 patch sent. I sent one, which made it to the archive... http://lkml.iu.edu/hypermail/linux/kernel/1506.2/02539.html > And, most importantly: > >> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > > I don't care about arch/sh/ stuff, why are you sending this to me? $ scripts/get_maintainer.pl j2-oldfiles.patch | grep Greg Greg Kroah-Hartman <gregkh@linuxfoundation.org> (maintainer:SERIAL DRIVERS) Sorry, my bad, I was trying to follow the documented procedure. Personally I'd have trimmed the cc: list but filling things out in triplicate seems to be all the rage these days. > You have a bit of work to do here... As I mentioned in 0/2, yes. But "release early, release often" and all that. (Or did we stop doing that now the Linux Foundation's in charge? I'm still stuck in the hobbyist era from back before we had a foundation with committees and a hierarchy where you need to go through proper channels and three dozen patch submission steps in two different files and all that. I'm trying to keep up, but I've always been really bad at bureaucracy...) > greg k-h > . Rob -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in
[Trimmed greg at what I'm interpreting as his request.] On 06/18/2015 02:36 PM, Geert Uytterhoeven wrote: > Hi Rob, > > On Thu, Jun 18, 2015 at 7:19 PM, Rob Landley <rob@landley.net> wrote: >> Changes to existing files to add 0pf j2 board support. > > Thanks for your patch! > > Like Greg already said, splitting it up in logical parts and providing useful > patch descriptions would be highly appreciated. I actually don't know how to split it up further. The initial port was done by a series of contractors (in Russia, I think), and then I inherited it to try to get something releasable. This is the smallest chunk I could get to actually boot. I suppose I could send you the serial driver by itself, and _then_ the board, but it wouldn't compile if nothing uses it. (Similarly you can't boot the board without a serial console...) >> diff --git a/arch/sh/Makefile b/arch/sh/Makefile >> index bf5b3f5..e609157 100644 >> --- a/arch/sh/Makefile >> +++ b/arch/sh/Makefile > >> @@ -31,6 +33,7 @@ isa-y := $(isa-y)-up >> endif >> >> cflags-$(CONFIG_CPU_SH2) := $(call cc-option,-m2,) >> +cflags-$(CONFIG_CPU_SH2J) := $(call cc-option,-m2,) > > This is superfluous, as CPU_SH2J selects CPU_SH2. Ooh, thanks. >> diff --git a/arch/sh/kernel/irq.c b/arch/sh/kernel/irq.c >> index eb10ff8..7de9bcb 100644 >> --- a/arch/sh/kernel/irq.c >> +++ b/arch/sh/kernel/irq.c >> @@ -20,6 +20,8 @@ >> #include <asm/thread_info.h> >> #include <cpu/mmu_context.h> >> >> +#include <asm/board-0pf.h> > > Board-specific inclusion in generic sh source file? Gah, I thought I'd whacked all of those. (Staring at it too long to see some of this stuff anymore...) >> + >> atomic_t irq_err_count; >> >> /* >> @@ -175,11 +177,24 @@ void do_softirq_own_stack(void) >> ); >> } >> #else >> +#define noinline __attribute__((noinline)) >> +static noinline void handle_irq_UART0(unsigned int irq) { generic_handle_irq(irq); } >> +static noinline void handle_irq_UART1(unsigned int irq) { generic_handle_irq(irq); } >> +static noinline void handle_irq_GPS(unsigned int irq) { generic_handle_irq(irq); } >> +static noinline void handle_irq_EMAC(unsigned int irq) { generic_handle_irq(irq); } >> static inline void handle_one_irq(unsigned int irq) >> { >> - generic_handle_irq(irq); >> + switch(irq) { >> + case Irq_UART0: handle_irq_UART0(irq); break; >> + case Irq_UART1: handle_irq_UART1(irq); break; >> + case Irq_GPS: handle_irq_GPS(irq); break; >> + case Irq_EMAC: handle_irq_EMAC(irq); break; >> + default: >> + generic_handle_irq(irq); >> + break; >> + } > > What's the purpose of this change? Honestly, your guess is as good as mine. (Sorry, I'll move it to a board-specific file. I mentioned needing to redo the interrupt logic _entirely_, it should totally be using SPARSE_IRQ. And in fact most of the above is for drivers I trimmed out of this submission anyway.) >> } >> -#endif >> +#endif // CONFIG_IRQSTACKS > > Please no C++-style comments (scripts/checkpatch.pl?) I expect it to try to reach through the screen and throttle me, but sure... (Now the reason _I_ thought you'd reject it had more to do with not having converted it to device tree yet, and things on that level. But I wanted to get it out there so people outside $DAYJOB can test the hardware. We did a linuxcon japan presentation which lwn.net covered, and we're getting pokes about "where can I download this", so...) Rob -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in
On Fri, Jun 19, 2015 at 04:57:00PM -0500, Rob Landley wrote: > On 06/18/2015 12:59 PM, Greg Kroah-Hartman wrote: > > On Thu, Jun 18, 2015 at 10:19:19AM -0700, Rob Landley wrote: > >> Changes to existing files to add 0pf j2 board support. > >> > > > > That's the second worse commit message and subject: line I've read > > today. > > > > And there's no signed off by line. > > My bad. I've always sucked at filling out paperwork, and I didn't expect > this to go in as is. But for the sake of following the official > procedures (well, step 11 of of SubmittingPatches, it's not mentioned in > any of the 26 steps of SubmitChecklist), here's the requested certification: > > Signed-off-by: Rob Landley <rob@landley.net> > Reviewed-by: D. Jeff Dionne <jeff@uclinux.org> You didn't do the 26 steps of SubmitChecklist, as step 5 would have caught almost all of these issues. > > And there was no 1/2 patch sent. > > I sent one, which made it to the archive... > > http://lkml.iu.edu/hypermail/linux/kernel/1506.2/02539.html But you didn't cc: me on that, how am I supposed to know? > > And, most importantly: > > > >> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > > > > I don't care about arch/sh/ stuff, why are you sending this to me? > > $ scripts/get_maintainer.pl j2-oldfiles.patch | grep Greg > Greg Kroah-Hartman <gregkh@linuxfoundation.org> (maintainer:SERIAL DRIVERS) > > Sorry, my bad, I was trying to follow the documented procedure. > Personally I'd have trimmed the cc: list but filling things out in > triplicate seems to be all the rage these days. No, you need to break your patch up properly, a single patch hitting all of these files has never been ok. > > You have a bit of work to do here... > > As I mentioned in 0/2, yes. But "release early, release often" and all that. > > (Or did we stop doing that now the Linux Foundation's in charge? Seriously? It's one thing to cc: a ton of people with a patch that for 90% of it, isn't relevant to them, and isn't even something they can do anything with. It's another thing to rant against those who try to point out how to solve your issues. > I'm still stuck in the hobbyist era from back before we had a > foundation with committees and a hierarchy where you need to go > through proper channels and three dozen patch submission steps in two > different files and all that. I'm trying to keep up, but I've always > been really bad at bureaucracy...) There is no such thing here, you know better than that, stop trying to troll, it's not very becoming. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rob, On Sat, Jun 20, 2015 at 12:11 AM, Rob Landley <rob@landley.net> wrote: > On 06/18/2015 02:36 PM, Geert Uytterhoeven wrote: >> On Thu, Jun 18, 2015 at 7:19 PM, Rob Landley <rob@landley.net> wrote: >>> Changes to existing files to add 0pf j2 board support. >> >> Thanks for your patch! >> >> Like Greg already said, splitting it up in logical parts and providing useful >> patch descriptions would be highly appreciated. > > I actually don't know how to split it up further. The initial port was > done by a series of contractors (in Russia, I think), and then I > inherited it to try to get something releasable. This is the smallest > chunk I could get to actually boot. > > I suppose I could send you the serial driver by itself, and _then_ the > board, but it wouldn't compile if nothing uses it. (Similarly you can't > boot the board without a serial console...) You don't have to send in a big initial patch that actually boots. For new architecture/SoC/board support, just split it in logical hunks, and submit it in some logical order that always builds. E.g.: - SoC core support (arch/sh/), - Board support (arch/sh/), - Drivers. The first two should go in through akpm (sh is orphaned), the rest through the individual subsystem maintainers. > (Now the reason _I_ thought you'd reject it had more to do with not > having converted it to device tree yet, and things on that level. But I Sh is an existing supported architecture, so DT is not a hard requirement. If you would have waited until after the removal of sh, it would be much harder :-) (cfr. h8300, but Sato-san did a great job there, with DT, CCF, ...) > wanted to get it out there so people outside $DAYJOB can test the > hardware. We did a linuxcon japan presentation which lwn.net covered, > and we're getting pokes about "where can I download this", so...) It's great to hear there's so much interest in this! Let's hope this will attract more actual contributors... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in
On 06/20/2015 03:00 AM, Geert Uytterhoeven wrote: > Hi Rob, > > On Sat, Jun 20, 2015 at 12:11 AM, Rob Landley <rob@landley.net> wrote: >> On 06/18/2015 02:36 PM, Geert Uytterhoeven wrote: >>> On Thu, Jun 18, 2015 at 7:19 PM, Rob Landley <rob@landley.net> wrote: >>>> Changes to existing files to add 0pf j2 board support. >>> >>> Thanks for your patch! >>> >>> Like Greg already said, splitting it up in logical parts and providing useful >>> patch descriptions would be highly appreciated. >> >> I actually don't know how to split it up further. The initial port was >> done by a series of contractors (in Russia, I think), and then I >> inherited it to try to get something releasable. This is the smallest >> chunk I could get to actually boot. >> >> I suppose I could send you the serial driver by itself, and _then_ the >> board, but it wouldn't compile if nothing uses it. (Similarly you can't >> boot the board without a serial console...) > > You don't have to send in a big initial patch that actually boots. > For new architecture/SoC/board support, just split it in logical hunks, > and submit it in some logical order that always builds. > > E.g.: > - SoC core support (arch/sh/), > - Board support (arch/sh/), > - Drivers. > > The first two should go in through akpm (sh is orphaned), > the rest through the individual subsystem maintainers. I'm aware sh is orphaned (http://www.openwall.com/lists/musl/2014/02/17/3). I'm trying to do something about that. I'm not up to maintaining an architecture myself (after the kernel.org/doc thing I walked away from kernel stuff for most of a year, as you can see I'm a bit out of practice), but I spoke to Yoshinori Sato (who used to maintain sh2, and only dropped it when renesas discontinued the hardware) and he said he might be interested in returning as a co-maintainer. (I note that I've been regression testing and fixing sh4 in my aboriginal linux project for several years now, although it's been quiescent enough on the kernel side the majority of my posts about it seem to be qemu issues, from https://lists.gnu.org/archive/html/qemu-devel/2010-03/msg00976.html to http://comments.gmane.org/gmane.comp.emulators.qemu/294066 . Dealing with sh2 is new to me, but it's also my day job these days. :) >> (Now the reason _I_ thought you'd reject it had more to do with not >> having converted it to device tree yet, and things on that level. But I > > Sh is an existing supported architecture, so DT is not a hard requirement. Yeah, but new board... And it's the right thing to do. > If you would have waited until after the removal of sh, it would be much > harder :-) (cfr. h8300, but Sato-san did a great job there, with DT, CCF, ...) Indeed he did. We had lunch with him when I was in Japan a couple weeks ago. I've got the references I need to do this, just... lots of shoveling on a lot of fronts to do right now. (And I mentioned like 3 other things I already know I need to fix in the 0/2 message.) >> wanted to get it out there so people outside $DAYJOB can test the >> hardware. We did a linuxcon japan presentation which lwn.net covered, >> and we're getting pokes about "where can I download this", so...) > > It's great to hear there's so much interest in this! Let's hope this will > attract more actual contributors... The "where can I download this" is now the developer tab of 0pf.org by the way. And the mailing lists are on lists.nommu.org. I'll try to submit an updated patch set in the next couple days. Thanks, Rob -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in
Hi Rob, On Sat, Jun 20, 2015 at 10:13 PM, Rob Landley <rob@landley.net> wrote: >>> (Now the reason _I_ thought you'd reject it had more to do with not >>> having converted it to device tree yet, and things on that level. But I >> >> Sh is an existing supported architecture, so DT is not a hard requirement. > > Yeah, but new board... And it's the right thing to do. Still, people wouldn't be unhappy if you added DT support ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in
On Sun, 21 Jun 2015 05:13:06 +0900, Rob Landley wrote: > > On 06/20/2015 03:00 AM, Geert Uytterhoeven wrote: > > Hi Rob, > > > > On Sat, Jun 20, 2015 at 12:11 AM, Rob Landley <rob@landley.net> wrote: > >> On 06/18/2015 02:36 PM, Geert Uytterhoeven wrote: > >>> On Thu, Jun 18, 2015 at 7:19 PM, Rob Landley <rob@landley.net> wrote: > >>>> Changes to existing files to add 0pf j2 board support. > >>> > >>> Thanks for your patch! > >>> > >>> Like Greg already said, splitting it up in logical parts and providing useful > >>> patch descriptions would be highly appreciated. > >> > >> I actually don't know how to split it up further. The initial port was > >> done by a series of contractors (in Russia, I think), and then I > >> inherited it to try to get something releasable. This is the smallest > >> chunk I could get to actually boot. > >> > >> I suppose I could send you the serial driver by itself, and _then_ the > >> board, but it wouldn't compile if nothing uses it. (Similarly you can't > >> boot the board without a serial console...) > > > > You don't have to send in a big initial patch that actually boots. > > For new architecture/SoC/board support, just split it in logical hunks, > > and submit it in some logical order that always builds. > > > > E.g.: > > - SoC core support (arch/sh/), > > - Board support (arch/sh/), > > - Drivers. > > > > The first two should go in through akpm (sh is orphaned), > > the rest through the individual subsystem maintainers. > > I'm aware sh is orphaned > (http://www.openwall.com/lists/musl/2014/02/17/3). I'm trying to do > something about that. > > I'm not up to maintaining an architecture myself (after the > kernel.org/doc thing I walked away from kernel stuff for most of a year, > as you can see I'm a bit out of practice), but I spoke to Yoshinori Sato > (who used to maintain sh2, and only dropped it when renesas discontinued > the hardware) and he said he might be interested in returning as a > co-maintainer. > > (I note that I've been regression testing and fixing sh4 in my > aboriginal linux project for several years now, although it's been > quiescent enough on the kernel side the majority of my posts about it > seem to be qemu issues, from > https://lists.gnu.org/archive/html/qemu-devel/2010-03/msg00976.html to > http://comments.gmane.org/gmane.comp.emulators.qemu/294066 . Dealing > with sh2 is new to me, but it's also my day job these days. :) > > >> (Now the reason _I_ thought you'd reject it had more to do with not > >> having converted it to device tree yet, and things on that level. But I > > > > Sh is an existing supported architecture, so DT is not a hard requirement. > > Yeah, but new board... And it's the right thing to do. I think convert DT is best way. It looks don't use SH compatible peripherals. I think if it's a SH compatible, it's better to maintain the platform_device structure. But use incompatible peripherals (So need new platform_device), It's difficult to maintain it. I trying SE7619 target convert to DT. It works fine. So no problem in 0PF platform DT support. > > If you would have waited until after the removal of sh, it would be much > > harder :-) (cfr. h8300, but Sato-san did a great job there, with DT, CCF, ...) > > Indeed he did. We had lunch with him when I was in Japan a couple weeks ago. > > I've got the references I need to do this, just... lots of shoveling on > a lot of fronts to do right now. (And I mentioned like 3 other things I > already know I need to fix in the 0/2 message.) > > >> wanted to get it out there so people outside $DAYJOB can test the > >> hardware. We did a linuxcon japan presentation which lwn.net covered, > >> and we're getting pokes about "where can I download this", so...) > > > > It's great to hear there's so much interest in this! Let's hope this will > > attract more actual contributors... > > The "where can I download this" is now the developer tab of 0pf.org by > the way. And the mailing lists are on lists.nommu.org. > > I'll try to submit an updated patch set in the next couple days. > > Thanks, > > Rob
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 50057fe..c121a92 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -66,7 +66,7 @@ config SUPERH32 select HAVE_MIXED_BREAKPOINTS_REGS select PERF_EVENTS select ARCH_HIBERNATION_POSSIBLE if MMU - select SPARSE_IRQ + select SPARSE_IRQ if !CPU_SUBTYPE_0PF select HAVE_CC_STACKPROTECTOR config SUPERH64 @@ -108,6 +108,9 @@ config ARCH_SUSPEND_POSSIBLE config ARCH_HIBERNATION_POSSIBLE def_bool n +config ARCH_USES_GETTIMEOFFSET + def_bool n + config SYS_SUPPORTS_APM_EMULATION bool select ARCH_SUSPEND_POSSIBLE @@ -184,6 +187,11 @@ config CPU_SH2A select CPU_SH2 select UNCACHED_MAPPING +config CPU_SH2J + bool + select CPU_SH2 + select ARCH_USES_GETTIMEOFFSET + config CPU_SH3 bool select CPU_HAS_INTEVT @@ -303,6 +311,12 @@ config CPU_SUBTYPE_MXG help Select MX-G if running on an R8A03022BG part. +# SH-2J Processor Support + +config CPU_SUBTYPE_0PF + bool "Support 0PF J2 SoftCore" + select CPU_SH2J + # SH-3 Processor Support config CPU_SUBTYPE_SH7705 @@ -753,6 +767,7 @@ config ZERO_PAGE_OFFSET SH_7751_SOLUTION_ENGINE default "0x00004000" if PAGE_SIZE_16KB || SH_SH03 default "0x00002000" if PAGE_SIZE_8KB + default "0x0003F000" if CPU_SUBTYPE_0PF default "0x00001000" help This sets the default offset of zero page. diff --git a/arch/sh/Makefile b/arch/sh/Makefile index bf5b3f5..e609157 100644 --- a/arch/sh/Makefile +++ b/arch/sh/Makefile @@ -4,6 +4,7 @@ # Copyright (C) 1999 Kaz Kojima # Copyright (C) 2002 - 2008 Paul Mundt # Copyright (C) 2002 M. R. Brown +# Copyright (C) 2012 SEI, Inc. (sh2j) # # This file is subject to the terms and conditions of the GNU General Public # License. See the file "COPYING" in the main directory of this archive @@ -19,6 +20,7 @@ isa-y := any isa-$(CONFIG_SH_DSP) := sh isa-$(CONFIG_CPU_SH2) := sh2 isa-$(CONFIG_CPU_SH2A) := sh2a +isa-$(CONFIG_CPU_SH2J) := sh2j isa-$(CONFIG_CPU_SH3) := sh3 isa-$(CONFIG_CPU_SH4) := sh4 isa-$(CONFIG_CPU_SH4A) := sh4a @@ -31,6 +33,7 @@ isa-y := $(isa-y)-up endif cflags-$(CONFIG_CPU_SH2) := $(call cc-option,-m2,) +cflags-$(CONFIG_CPU_SH2J) := $(call cc-option,-m2,) cflags-$(CONFIG_CPU_SH2A) += $(call cc-option,-m2a,) \ $(call cc-option,-m2a-nofpu,) \ $(call cc-option,-m4-nofpu,) @@ -91,6 +94,7 @@ defaultimage-$(CONFIG_SH_SH7757LCR) := uImage defaultimage-$(CONFIG_SH_7724_SOLUTION_ENGINE) := uImage defaultimage-$(CONFIG_SH_7206_SOLUTION_ENGINE) := vmlinux defaultimage-$(CONFIG_SH_7619_SOLUTION_ENGINE) := vmlinux +defaultimage-$(CONFIG_SH_0PF) := vmlinux # Set some sensible Kbuild defaults KBUILD_IMAGE := $(defaultimage-y) @@ -173,6 +177,7 @@ core-$(CONFIG_HD6446X_SERIES) += arch/sh/cchips/hd6446x/ # As an example, in order of preference, SH-2A > SH-2 > common definitions. # cpuincdir-$(CONFIG_CPU_SH2A) += cpu-sh2a +cpuincdir-$(CONFIG_CPU_SH2J) += cpu-sh2j cpuincdir-$(CONFIG_CPU_SH2) += cpu-sh2 cpuincdir-$(CONFIG_CPU_SH3) += cpu-sh3 cpuincdir-$(CONFIG_CPU_SH4A) += cpu-sh4a diff --git a/arch/sh/boards/Kconfig b/arch/sh/boards/Kconfig index 89963d13..c6721d2 100644 --- a/arch/sh/boards/Kconfig +++ b/arch/sh/boards/Kconfig @@ -90,6 +90,13 @@ config SH_7343_SOLUTION_ENGINE Select 7343 SolutionEngine if configuring for a Hitachi SH7343 (SH-Mobile 3AS) evaluation board. +config 0PF_FPGA + bool "0PF FPGA" + depends on CPU_SUBTYPE_0PF + help + Select 0PF_FPGA if you are configuring for an FPGA with + the SH2j-workalike SoftCore from http://0pf.org + config SH_HP6XX bool "HP6XX" select SYS_SUPPORTS_APM_EMULATION diff --git a/arch/sh/boards/Makefile b/arch/sh/boards/Makefile index 975a0f6..51a7eb3 100644 --- a/arch/sh/boards/Makefile +++ b/arch/sh/boards/Makefile @@ -15,3 +15,4 @@ obj-$(CONFIG_SH_TITAN) += board-titan.o obj-$(CONFIG_SH_SH7757LCR) += board-sh7757lcr.o obj-$(CONFIG_SH_APSH4A3A) += board-apsh4a3a.o obj-$(CONFIG_SH_APSH4AD0A) += board-apsh4ad0a.o +obj-$(CONFIG_0PF_FPGA) += board-0pf.o diff --git a/arch/sh/include/asm/processor.h b/arch/sh/include/asm/processor.h index 1506897..aedabf2 100644 --- a/arch/sh/include/asm/processor.h +++ b/arch/sh/include/asm/processor.h @@ -15,7 +15,7 @@ */ enum cpu_type { /* SH-2 types */ - CPU_SH7619, + CPU_SH7619, CPU_0PF, /* SH-2A types */ CPU_SH7201, CPU_SH7203, CPU_SH7206, CPU_SH7263, CPU_SH7264, CPU_SH7269, diff --git a/arch/sh/include/cpu-sh2/cpu/cache.h b/arch/sh/include/cpu-sh2/cpu/cache.h index aa1b2b9..1da5abb 100644 --- a/arch/sh/include/cpu-sh2/cpu/cache.h +++ b/arch/sh/include/cpu-sh2/cpu/cache.h @@ -38,6 +38,10 @@ #define CCR_CACHE_INVALIDATE CCR_CACHE_CF #define CACHE_PHYSADDR_MASK 0x1ffffc00 +#elif defined(CONFIG_CPU_SUBTYPE_0PF) +#define CCR 0xabcd00c0 +#define CCR_CACHE_ENABLE 0x80000000 +#define CCR_CACHE_RESET 0x101 #endif #endif /* __ASM_CPU_SH2_CACHE_H */ diff --git a/arch/sh/kernel/cpu/init.c b/arch/sh/kernel/cpu/init.c index 0d7360d..cda35ce 100644 --- a/arch/sh/kernel/cpu/init.c +++ b/arch/sh/kernel/cpu/init.c @@ -106,7 +106,7 @@ void __attribute__ ((weak)) l2_cache_init(void) /* * Generic first-level cache init */ -#ifdef CONFIG_SUPERH32 +#if defined(CONFIG_SUPERH32) && !defined(CONFIG_CPU_SUBTYPE_0PF) static void cache_init(void) { unsigned long ccr, flags; diff --git a/arch/sh/kernel/cpu/proc.c b/arch/sh/kernel/cpu/proc.c index 9e6624c..4381fc2 100644 --- a/arch/sh/kernel/cpu/proc.c +++ b/arch/sh/kernel/cpu/proc.c @@ -26,6 +26,7 @@ static const char *cpu_name[] = { [CPU_SH5_101] = "SH5-101", [CPU_SH5_103] = "SH5-103", [CPU_MXG] = "MX-G", [CPU_SH7723] = "SH7723", [CPU_SH7366] = "SH7366", [CPU_SH7724] = "SH7724", + [CPU_0PF] = "SH2J-0PF", [CPU_SH7372] = "SH7372", [CPU_SH7734] = "SH7734", [CPU_SH_NONE] = "Unknown" }; diff --git a/arch/sh/kernel/cpu/sh2/Makefile b/arch/sh/kernel/cpu/sh2/Makefile index f0f059a..7502611 100644 --- a/arch/sh/kernel/cpu/sh2/Makefile +++ b/arch/sh/kernel/cpu/sh2/Makefile @@ -5,3 +5,4 @@ obj-y := ex.o probe.o entry.o obj-$(CONFIG_CPU_SUBTYPE_SH7619) += setup-sh7619.o clock-sh7619.o +obj-$(CONFIG_CPU_SUBTYPE_0PF) += setup-0pf.o clock-0pf.o diff --git a/arch/sh/kernel/cpu/sh2/entry.S b/arch/sh/kernel/cpu/sh2/entry.S index c8a4331..3c997c9 100644 --- a/arch/sh/kernel/cpu/sh2/entry.S +++ b/arch/sh/kernel/cpu/sh2/entry.S @@ -3,6 +3,7 @@ * * The SH-2 exception entry * + * Copyright (C) 2012 SEI,Inc. * Copyright (C) 2005-2008 Yoshinori Sato * Copyright (C) 2005 AXE,Inc. * @@ -147,7 +148,11 @@ ENTRY(exception_handler) mov #32,r8 cmp/hs r8,r9 bt trap_entry ! 64 > vec >= 32 is trap - +#if defined(CONFIG_CPU_SUBTYPE_0PF) + mov #16,r8 + cmp/hs r8,r9 + bt interrupt_entry ! 32 > vec >= 16 is interrupt +#endif mov.l 4f,r8 mov r9,r4 shll2 r9 @@ -245,6 +250,19 @@ ENTRY(address_error_trap_handler) .align 2 1: .long do_address_error +#if defined(CONFIG_CPU_SUBTYPE_0PF) +ENTRY(pc_address_error_trap_handler) + mov r15,r4 ! regs + mov #OFF_PC,r0 + mov.l @(r0,r15),r6 ! pc + mov.l 1f,r0 + jmp @r0 + mov #0,r5 ! writeaccess is unknown + + .align 2 +1: .long do_pc_address_error +#endif // CONFIG_CPU_SUBTYPE_0PF + restore_all: stc sr,r0 or #0xf0,r0 diff --git a/arch/sh/kernel/cpu/sh2/probe.c b/arch/sh/kernel/cpu/sh2/probe.c index 6c687ae..9c9e401 100644 --- a/arch/sh/kernel/cpu/sh2/probe.c +++ b/arch/sh/kernel/cpu/sh2/probe.c @@ -24,6 +24,12 @@ void cpu_probe(void) boot_cpu_data.dcache.linesz = L1_CACHE_BYTES; boot_cpu_data.dcache.flags = 0; #endif + +#if defined(CONFIG_CPU_SUBTYPE_0PF) + boot_cpu_data.type = CPU_0PF; + boot_cpu_data.dcache.flags = 0; +#endif + /* * SH-2 doesn't have separate caches */ diff --git a/arch/sh/kernel/irq.c b/arch/sh/kernel/irq.c index eb10ff8..7de9bcb 100644 --- a/arch/sh/kernel/irq.c +++ b/arch/sh/kernel/irq.c @@ -20,6 +20,8 @@ #include <asm/thread_info.h> #include <cpu/mmu_context.h> +#include <asm/board-0pf.h> + atomic_t irq_err_count; /* @@ -175,11 +177,24 @@ void do_softirq_own_stack(void) ); } #else +#define noinline __attribute__((noinline)) +static noinline void handle_irq_UART0(unsigned int irq) { generic_handle_irq(irq); } +static noinline void handle_irq_UART1(unsigned int irq) { generic_handle_irq(irq); } +static noinline void handle_irq_GPS(unsigned int irq) { generic_handle_irq(irq); } +static noinline void handle_irq_EMAC(unsigned int irq) { generic_handle_irq(irq); } static inline void handle_one_irq(unsigned int irq) { - generic_handle_irq(irq); + switch(irq) { + case Irq_UART0: handle_irq_UART0(irq); break; + case Irq_UART1: handle_irq_UART1(irq); break; + case Irq_GPS: handle_irq_GPS(irq); break; + case Irq_EMAC: handle_irq_EMAC(irq); break; + default: + generic_handle_irq(irq); + break; + } } -#endif +#endif // CONFIG_IRQSTACKS asmlinkage __irq_entry int do_IRQ(unsigned int irq, struct pt_regs *regs) { diff --git a/arch/sh/kernel/traps_32.c b/arch/sh/kernel/traps_32.c index ff63934..cd09376 100644 --- a/arch/sh/kernel/traps_32.c +++ b/arch/sh/kernel/traps_32.c @@ -34,6 +34,7 @@ #ifdef CONFIG_CPU_SH2 # define TRAP_RESERVED_INST 4 # define TRAP_ILLEGAL_SLOT_INST 6 +# define TRAP_PC_ADDRESS_ERROR 8 // Aug 20, 2012 ulianov - SEI extension - PC governor # define TRAP_ADDRESS_ERROR 9 # ifdef CONFIG_CPU_SH2A # define TRAP_UBC 12 @@ -458,6 +459,14 @@ int handle_unaligned_access(insn_size_t instruction, struct pt_regs *regs, return ret; } +#if defined(CONFIG_CPU_SUBTYPE_0PF) +asmlinkage void do_pc_address_error(struct pt_regs *regs, + unsigned long writeaccess, + unsigned long address) +{ +} +#endif // CONFIG_CPU_SUBTYPE_0PF + /* * Handle various address error exceptions: * - instruction address error: @@ -779,6 +788,9 @@ void __init trap_init(void) #endif #ifdef CONFIG_CPU_SH2 + #if defined(CONFIG_CPU_SUBTYPE_0PF) + set_exception_table_vec(TRAP_PC_ADDRESS_ERROR, address_error_trap_handler); + #endif set_exception_table_vec(TRAP_ADDRESS_ERROR, address_error_trap_handler); #endif #ifdef CONFIG_CPU_SH2A diff --git a/arch/sh/mm/cache-sh2.c b/arch/sh/mm/cache-sh2.c index a74259f..438eadb 100644 --- a/arch/sh/mm/cache-sh2.c +++ b/arch/sh/mm/cache-sh2.c @@ -3,6 +3,7 @@ * * Copyright (C) 2002 Paul Mundt * Copyright (C) 2008 Yoshinori Sato + * Copyright (C) 2012 SEI, Inc. * * Released under the terms of the GNU GPL v2.0. */ @@ -16,6 +17,30 @@ #include <asm/cacheflush.h> #include <asm/io.h> +#if defined(CONFIG_CPU_SUBTYPE_0PF) + +// Just flush the whole thing each time +static void j2_flush_icache_range(void *fwoosh) +{ + __raw_writel(CCR_CACHE_RESET, CCR); +} + +// This should never happen, but... +static void j2_flush_icache_page(void *fwoosh) +{ + __raw_writel(CCR_CACHE_RESET, CCR); +} + +void __init sh2_cache_init(void) +{ + local_flush_icache_range = j2_flush_icache_range; + local_flush_icache_page = j2_flush_icache_page; + boot_cpu_data.dcache.n_aliases = 0; + + __raw_writel(CCR_CACHE_RESET, CCR); +} + +#else static void sh2__flush_wback_region(void *start, int size) { unsigned long v; @@ -89,3 +114,4 @@ void __init sh2_cache_init(void) __flush_purge_region = sh2__flush_purge_region; __flush_invalidate_region = sh2__flush_invalidate_region; } +#endif diff --git a/arch/sh/mm/cache.c b/arch/sh/mm/cache.c index f770e39..17908f7 100644 --- a/arch/sh/mm/cache.c +++ b/arch/sh/mm/cache.c @@ -258,14 +258,16 @@ static void __init emit_cache_params(void) boot_cpu_data.icache.entry_mask, boot_cpu_data.icache.alias_mask, boot_cpu_data.icache.n_aliases); - printk(KERN_NOTICE "D-cache : n_ways=%d n_sets=%d way_incr=%d\n", - boot_cpu_data.dcache.ways, - boot_cpu_data.dcache.sets, - boot_cpu_data.dcache.way_incr); - printk(KERN_NOTICE "D-cache : entry_mask=0x%08x alias_mask=0x%08x n_aliases=%d\n", - boot_cpu_data.dcache.entry_mask, - boot_cpu_data.dcache.alias_mask, - boot_cpu_data.dcache.n_aliases); + if (boot_cpu_data.dcache.n_aliases) { + printk(KERN_NOTICE "D-cache : n_ways=%d n_sets=%d way_incr=%d\n", + boot_cpu_data.dcache.ways, + boot_cpu_data.dcache.sets, + boot_cpu_data.dcache.way_incr); + printk(KERN_NOTICE "D-cache : entry_mask=0x%08x alias_mask=0x%08x n_aliases=%d\n", + boot_cpu_data.dcache.entry_mask, + boot_cpu_data.dcache.alias_mask, + boot_cpu_data.dcache.n_aliases); + } /* * Emit Secondary Cache parameters if the CPU has a probed L2. diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index f8120c1b..aae8d72 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -594,7 +594,7 @@ config SERIAL_IMX_CONSOLE config SERIAL_UARTLITE tristate "Xilinx uartlite serial port support" - depends on PPC32 || MICROBLAZE || MFD_TIMBERDALE || ARCH_ZYNQ + depends on PPC32 || MICROBLAZE || MFD_TIMBERDALE || ARCH_ZYNQ || CPU_SUBTYPE_0PF select SERIAL_CORE help Say Y here if you want to use the Xilinx uartlite serial controller. @@ -611,6 +611,12 @@ config SERIAL_UARTLITE_CONSOLE console (the system console is the device which receives all kernel messages and warnings and which allows logins in single user mode). +config SERIAL_UARTLITE_0PF + tristate "Support 0PF UARTLITEs" + depends on SERIAL_UARTLITE = y && CPU_SUBTYPE_0PF + help + Say Y here to set up 0PF's UARTLITEs. + config SERIAL_SUNCORE bool depends on SPARC