[PATCH v2 00/76] Synopsys ARC Linux kernel Port
This patchset based off-of 3.8-rc4, adds the Linux kernel port to ARC700 processor family (750D and 770D) from Synopsys. I would be greatful for further review and feedback. Salient points about v2 patchset --- * All of the feedback from v1 RFC patchseries has been addressed. * Some of the major fixes for v1 review comments such as Device Tree support, multi-platform-image and syscall-restart issues, have not been squashed into relevent patches, but instead have been applied as slap-on patches on orig ones. This is merely to build up some revision history into the final-upstream-merged version. If people think it's too ugly, I can do the chop-n-dice-n-squash, but my preference would be the style we have now. * Unlike RFC v1 series (split into 2 part) this one includes the complete port (still the minimal kernel at halfway checkpoint, builds/runs fine). This combined with prev point, make the full patchset a touch large, for which I appologize in advance. * The entire series however is also available at git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git arc-3.8-lkml-v2 About ARC Cores ARC700 is highly configurable and power efficient 32-bit RISC core with MMU. It is embedded in SoCs deployed in TV Set Top boxes, Digital Media Players, all the way to Network-on-Chips. More information is available @ http://www.synopsys.com/IP/ProcessorIP/ARCProcessors/Pages/default.aspx The GNU tool-chain, based off of gcc 4.4 + uClibc 0.9.30.3 is also available from github. Please refer to Readme.md in "toolchain" repository also in same hierarchy as kernel above. --- v2: Changes for RFC v1 review: * Reworked arc_local_irq_enable() with WARN_ONCE for buggy drivers (tglx) * struct pt_regs wrapped under #ifdef __KERNEL__ (Jonas) * returning to user mode (Al Viro) * re-enable interrupts before handling TIF_SIGPENDING/TIF_NOTIFY_RESUME * Don't discard callee-regs after handling signal * After TIF_NOTIFY_RESUME processing, loop back to start of TIF_* checks * Reworked init_IRQ() to not use irq_modify_status() at all (tglx) * Removed legacy syscalls (Arnd) * cpu_idle to use schedule_preempt_disabled API (tglx) * clocksource/clockevent code renamed/reworked (tglx) * Removed possible live-lock in sched_clock() (tglx) * Ensured that syscalls are not restarted multiple times (Al Viro) * Support for DeviceTree based dynamic platform device registration (Arnd) * clock-speed / mem-size extracted from Device Tree (Arnd) * multi-platform-image - Non-exclusive platform selection in build (Arnd) * multi-platform-image - Non-exclusive boards selection in build (Arnd) * Fix the issue in switch to generic_execve (Al Viro) * defconfigs need to be created using savedefconfig (Arnd) * Remove support for legacy ptrace POKEUSR/PEEKUSR ABI (Arnd) * module stubs need not be defined in Arch code (Arnd) * Low Level Event Capture completely taken out (Arnd) * Unaligned access runtime controlled using 2 sysctl knobs (Arnd) * using io accessors for programming BVCI Latency Unit (Arnd) Other fixes: * 3.7 -> 3.8 upstream changes * Rebased off of 3.8-rc4 * UAPI Disintegration using scripts provided David Howells * Generic clone/fork/vfork * switch to saner kernel_execve semantics (GENERIC_KERNEL_EXECVE) * Altstack consolidation tracking changes * trace_clock.h introduction, cacheflush.h inclusion removal from io.h * bitops * test_and_clear_bit() was SETing the bit instead of CLEARing * test_and_*_bit() workaround a gas bug where a bitpos > 31 is not reported by doing __builtin_constant_p() check early * uaccess * Added support for non-inline copy_{to,from}_user() for -Os * Optimised {get,put}_user() by overriding asm-generic versions * Timers * split Process scheduling/Timers patch into two. * Add support for 64bit timestamp counter using RTSC instruction. * Others * Move the incore intc chip handler out of platform code into common code * cpu_ide() to use the rcu_idle_* calls Gilad Ben-Yossef (1): ARC: Add support for ioremap_prot API Mischa Jonker (1): ARC: kgdb support Vineet Gupta (74): ARC: Generic Headers ARC: irqflags - Interrupt enabling/disabling at in-core intc ARC: Atomic/bitops/cmpxchg/barriers asm-generic headers: uaccess.h to conditionally define segment_eq() ARC: uaccess friends asm-generic: uaccess: Allow arches to over-ride __{get,put}_user_fn() ARC: [optim] uaccess __{get,put}_user() optimised asm-generic headers: Allow yet more arch overrides in checksum.h ARC: Checksum/byteorder/swab routines ARC: Fundamental ARCH data-types/defines ARC: Spinlock/rwlock/mutex primitives ARC: String library ARC: Low level IRQ/Trap/Exception Handling ARC: Interrupt Handling ARC: Non-MMU Exception Handling ARC: Syscall support (no-legacy-syscall ABI) ARC: Process-creation/scheduling/idle-loop ARC: Timers/counters/delay management ARC: Signal handling ARC: [Review] Preparing to fix inco
Re: [PATCH v2 00/76] Synopsys ARC Linux kernel Port
On Friday 18 January 2013, Vineet Gupta wrote: > This patchset based off-of 3.8-rc4, adds the Linux kernel port to ARC700 > processor family (750D and 770D) from Synopsys. I would be greatful for > further review and feedback. > > Salient points about v2 patchset > --- > * All of the feedback from v1 RFC patchseries has been addressed. > > * Some of the major fixes for v1 review comments such as Device Tree support, > multi-platform-image and syscall-restart issues, have not been squashed > into relevent patches, but instead have been applied as slap-on patches > on orig ones. This is merely to build up some revision history into the > final-upstream-merged version. If people think it's too ugly, I can do > the chop-n-dice-n-squash, but my preference would be the style we have now. > > * Unlike RFC v1 series (split into 2 part) this one includes the complete port > (still the minimal kernel at halfway checkpoint, builds/runs fine). > This combined with prev point, make the full patchset a touch large, for > which I appologize in advance. > > * The entire series however is also available at > git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git > arc-3.8-lkml-v2 > Hi Vineet, I've looked at the entire series again now, and it looks very good overall, I only had comments for tiny issues. With 76 patches in the series, I doubt that anybody is going to look through all of them again though. Are the patches already part of Linux-next? If not, I would recommend getting them in there as a preparation for merging in 3.9. I would also recommend to only send incremental patches after that, as well as new versions of some of the patches if you decide to replace them based on comments you get. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/76] Synopsys ARC Linux kernel Port
On 01/18/2013 04:24 AM, Vineet Gupta wrote: This patchset based off-of 3.8-rc4, adds the Linux kernel port to ARC700 processor family (750D and 770D) from Synopsys. I would be greatful for further review and feedback. One thing: ARC, as I understand it, is a whole family of architectures, which mostly have in common their origin at Synopsys. Can we make this arch/arc700 since that is what it is? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/76] Synopsys ARC Linux kernel Port
On Sunday 20 January 2013 11:45 AM, H. Peter Anvin wrote: > On 01/18/2013 04:24 AM, Vineet Gupta wrote: >> This patchset based off-of 3.8-rc4, adds the Linux kernel port to ARC700 >> processor family (750D and 770D) from Synopsys. I would be greatful for >> further review and feedback. > > One thing: ARC, as I understand it, is a whole family of architectures, which > mostly have in common their origin at Synopsys. ARC has had a long history - as a startup in 90's. There used to be ARCTanget Instruction set (and cores A4,A5... based on that) which 10 years ago got deprecated by current ARCompact ISA (600 / 700 cores). So yes it is a family of architectures - but all we care about is the ARCompact and 600/700 at Synopsys. However, I don't think there were sub-architectures or forks which floated around. The MIPS "ARC" seems to be some sort of firmware standard, but not related to ARC: Ralf would you care to shed some light ? I don't know of any ARC arch other than these. > Can we make this arch/arc700 > since that is what it is? > > -hpa > As of now yes, but in near future we may have a new Instruction Set and cores based on that - so it will be better if we keep a non specific name. Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/76] Synopsys ARC Linux kernel Port
On Friday 18 January 2013 08:42 PM, Arnd Bergmann wrote: > On Friday 18 January 2013, Vineet Gupta wrote: >> > > Hi Vineet, > > I've looked at the entire series again now, and it looks very good > overall, I only had comments for tiny issues. With 76 patches in the > series, I doubt that anybody is going to look through all of them > again though. v3 series addressing all comments is cooked and am about to send it out. I've made 2 bins of the patches to separate out the ones which have NOT changed since v2. I'll send them under separate cover letters to make it easier for reviewers - BTW addition of your ACKs is not being counted as changed - although it's a big change for the patches :-) > Are the patches already part of Linux-next? If not, > I would recommend getting them in there as a preparation for merging > in 3.9. I have a few questions/clarifications in that regards. (1) What are the logistics involved. Does it have to be a tag or a branch (typically I see people have branches in next). (2) Can Stephan pull my branch from github or do I need to be setup apriori on kernel.org. If latter, whom do I need to contact. (3) That branch will be ARC patches on top of Linus's 3.8 rc4. Actually for my development, I'd also cherry picked a few patches from linux-next (soft and hard dependencies from several different *next trees) - hard ones being f13a366 CONFIG_GENERIC_SIGALTSTACK build breakage with asm-generic/syscalls.h [Al] b6fca sysctl: Enable IA64 "ignore-unaligned-usertrap" to be used cross-arch [ia64] Now when I put up a branch for Stephan I guess these should be taken out of ARC branch otherwise merge into linux-next will fail ? (4) Above series (pure ARC patches) merges fine in today's linux-next, except for a patch touching init/Kconfig (already acked by parisc maintainer) which is slightly different if based off 3.8-rc4 vs. linux-next (because of interim merge) so I'm hoping my tree doesn't get "dropped" from linux-next because of that. But then how will it get fixed. > I would also recommend to only send incremental patches after that, > as well as new versions of some of the patches if you decide to > replace them based on comments you get. Absolutely - I'm tired of rebasing and chopping/merging as well - so anything new will be on top of these (no rebasing). Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/76] Synopsys ARC Linux kernel Port
Hi Vineet, On 24/01/13 08:54, Vineet Gupta wrote: > (3) That branch will be ARC patches on top of Linus's 3.8 rc4. Actually for my > development, I'd also cherry picked a few patches from linux-next (soft and > hard > dependencies from several different *next trees) - hard ones being > > f13a366 CONFIG_GENERIC_SIGALTSTACK build breakage with asm-generic/syscalls.h > [Al] FYI this one has now been merged into Linus' master. Cheers James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/76] Synopsys ARC Linux kernel Port
On Thursday 24 January 2013 03:22 PM, James Hogan wrote: > Hi Vineet, > > On 24/01/13 08:54, Vineet Gupta wrote: >> (3) That branch will be ARC patches on top of Linus's 3.8 rc4. Actually for >> my >> development, I'd also cherry picked a few patches from linux-next (soft and >> hard >> dependencies from several different *next trees) - hard ones being >> >> f13a366 CONFIG_GENERIC_SIGALTSTACK build breakage with >> asm-generic/syscalls.h [Al] > FYI this one has now been merged into Linus' master. > > Cheers > James > OK thanks - but I'd rather have the patches based on a well known checkpoint - so maybe wait for next rc. Any ideas about other questions on the thread - given that several next trees are still involved. metag doesn't seem to be on linux-next yet ? -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/76] Synopsys ARC Linux kernel Port
On 24/01/13 10:11, Vineet Gupta wrote: > On Thursday 24 January 2013 03:22 PM, James Hogan wrote: >> Hi Vineet, >> >> On 24/01/13 08:54, Vineet Gupta wrote: >>> (3) That branch will be ARC patches on top of Linus's 3.8 rc4. Actually for >>> my >>> development, I'd also cherry picked a few patches from linux-next (soft and >>> hard >>> dependencies from several different *next trees) - hard ones being >>> >>> f13a366 CONFIG_GENERIC_SIGALTSTACK build breakage with >>> asm-generic/syscalls.h [Al] >> FYI this one has now been merged into Linus' master. >> >> Cheers >> James >> > > OK thanks - but I'd rather have the patches based on a well known checkpoint > - so > maybe wait for next rc. In that case you may like to merge Al's for-linus branch in the mean time, or the commit you want directly, since it's definitely gone into the master without being rebased. > Any ideas about other questions on the thread - given that several next trees > are > still involved. Stephen said it's fine to merge other trees as long as you let them know so they don't rebase, or ask them which branch is best to use that won't rebase. See the following thread: https://lkml.org/lkml/2013/1/11/187 > metag doesn't seem to be on linux-next yet ? Not yet, although I think it's almost ready. I need to solicit some acks. Cheers James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/