Re: [PATCH v5 07/14] dmaengine: add dma_request_slave_channel_compat()
On Tuesday 15 January 2013, Matt Porter wrote:
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
I noticed today some drivers in linux-next that rely on this patch,
but the patch itself still missing from -next.
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1047,6 +1047,16 @@ void dma_run_dependencies(struct
dma_async_tx_descriptor *tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel((mask), x, y)
+static inline struct dma_chan
+*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ if (dev-of_node)
+ return dma_request_slave_channel(dev, name);
+ else
+ return dma_request_channel(mask, fn, fn_param);
+}
Hmm, dma_request_channel is actually a macro that passes mask by reference,
presumably because it can get modified by the filter function. Also, there
may be cases where we do have an of_node but don't use the dma binding
yet, or where dma_request_slave_channel doesn't actually use DT information
but rather one of the other methods that Vinod was talking about adding.
I think what it should look like instead is the below.
Arnd
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index bfcdecb..b6ffd7d 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -993,6 +993,19 @@ static inline void dma_release_channel(struct dma_chan
*chan)
}
#endif
+static inline struct dma_chan
*__dma_request_slave_channel_compat(dma_cap_mask_t *mask,
+ dma_filter_fn fn, void *fn_param, struct device
*dev,
+char *name)
+{
+ struct dma_chan *chan;
+
+ chan = dma_request_slave_channel(dev, name);
+ if (chan)
+ return chan;
+
+ return __dma_request_channel(mask, fn, fn_param);
+}
+
/* --- DMA device --- */
int dma_async_device_register(struct dma_device *device);
@@ -1001,6 +1014,8 @@ void dma_run_dependencies(struct dma_async_tx_descriptor
*tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel((mask), x, y)
+#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
+__dma_request_slave_channel_compat((mask), x, y, dev, name)
/* --- Helper iov-locking functions --- */
--
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 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
On Tuesday 15 January 2013, Thierry Reding wrote: Is there actually hardware that supports this? I assumed that the MSI controller would have to be tightly coupled to the PCI host bridge in order to raise an interrupt when an MSI is received via PCI. No, as long as it's guaranteed that the MSI notification won't arrive at the CPU before any inbound DMA data before it, the MSI controller can be anywhere. Typically, the MSI controller is actually closer to the CPU core than to the PCI bridge. On X86, I believe the MSI address is on normally on the the local APIC on each CPU. 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] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
On Wednesday 16 January 2013, Soeren Moch wrote: I will see what I can do here. Is there an easy way to track the buffer usage without having to wait for complete exhaustion? DMA_API_DEBUG OK, maybe I can try this. Any success with this? It should at least tell you if there is a memory leak in one of the drivers. 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: [RFC PATCH v1 25/31] ARC: [plat-arcfpga] Hooking up platform to ARC UART
On Thursday 17 January 2013, Vineet Gupta wrote: So my strategy for v2 series (based off 3.8-rcx) is to introduce devicetree, multi-platform-image support (and other key fixes such as syscall restart issues) as slap-on patches on top of old code. This is not to avoid any chop-n-dice of fixing patches (I've done that in plenty between v1 and v2). Its just that, in absence of revision history for ARC port (in upstream later on) - it helps capture the evolution of some key features and also for the community it serves as a live documentation of bad designs and how they can be fixed. Is that a reasonable approach for new port which is non-bisectable anyways ? Yes, I think that's fine. you should make that clear in the introductory email though, as well as in the description of any patches that get changed significantly by a later patch, to make sure people don't comment on the same things again when you have already fixed them. 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: [RFC Patch v1 52/55] ARC: Support for single cycle Close Coupled Mem (CCM)
On Thursday 17 January 2013, Vineet Gupta wrote: Actually in ARC Port these are used in Linker script to layout the kernel code/data at the addr where these hardware blocks are wired up. So can't be done at runtime. Ok, makes sense. 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 0/4] gpio: introduce descriptor-based interface
On Thursday 17 January 2013, Steven King wrote: I haven't been keeping up with the kernel list of late, can someone point me to what''s being discussed so I can see what were talking about here? We are discussion about changes to the GPIO API, in particular about adding a descriptor (i.e. pointer to struct) based interface to replace integers as the primary key. Any kind of change on this level is currently problematic because it is basically impossible to tell which files are implementing the current interface and would need to get changed along with changing gpiolib. If everything goes through gpiolib, it's much easier to make compatible extensions in one place. Do you have any numbers about how much of a difference for your platforms we are talking about at most? 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] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
On Thursday 17 January 2013, Soeren Moch wrote: On 17.01.2013 11:49, Arnd Bergmann wrote: On Wednesday 16 January 2013, Soeren Moch wrote: I will see what I can do here. Is there an easy way to track the buffer usage without having to wait for complete exhaustion? DMA_API_DEBUG OK, maybe I can try this. Any success with this? It should at least tell you if there is a memory leak in one of the drivers. Not yet, sorry. I have to do all the tests in my limited spare time. Can you tell me what to search for in the debug output? Actually now that I've looked closer, you can't immediately see all the mappings as I thought. But please try enabling DMA_API_DEBUG in combination with this one-line patch: diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 6b2fb87..3df74ac 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -497,6 +497,7 @@ static void *__alloc_from_pool(size_t size, struct page **ret_page) pr_err_once(ERROR: %u KiB atomic DMA coherent pool is too small!\n Please increase it with coherent_pool= kernel parameter!\n, (unsigned)pool-size / 1024); + debug_dma_dump_mappings(NULL); } spin_unlock_irqrestore(pool-lock, flags); That will show every single allocation that is currently active. This lets you see where all the memory went, and if there is a possible leak or excessive fragmentation. 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 16/76] ARC: Syscall support (no-legacy-syscall ABI)
On Friday 18 January 2013, Vineet Gupta wrote: Signed-off-by: Vineet Gupta vgu...@synopsys.com Cc: Arnd Bergmann a...@arndb.de Acked-by: Arnd Bergmann a...@arndb.de -- 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 11/76] ARC: Spinlock/rwlock/mutex primitives
On Friday 18 January 2013, Vineet Gupta wrote: Signed-off-by: Vineet Gupta vgu...@synopsys.com Acked-by: Arnd Bergmann a...@arndb.de -- 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 10/76] ARC: Fundamental ARCH data-types/defines
On Friday 18 January 2013, Vineet Gupta wrote: * L1_CACHE_SHIFT * PAGE_SIZE, PAGE_OFFSET * struct pt_regs, struct user_regs_struct * struct thread_struct, cpu_relax(), task_pt_regs(), start_thread(), ... * struct thread_info, THREAD_SIZE, INIT_THREAD_INFO(), TIF_*, ... * BUG() * ELF_* * Elf_* To disallow user-space visibility into some of the core kernel data-types such as struct pt_regs, #ifdef __KERNEL__ which also makes the UAPI header spit (further patch in the series) to NOT export it to asm/uapi/ptrace.h Signed-off-by: Vineet Gupta vgu...@synopsys.com Cc: Jonas Bonn jonas.b...@gmail.com Acked-by: Arnd Bergmann a...@arndb.de -- 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 09/76] ARC: Checksum/byteorder/swab routines
On Friday 18 January 2013, Vineet Gupta wrote: TBD: do_csum still needs to be written in asm Do you actually expect a lot of improvement in do_csum? I would hope that gcc can actually generate a pretty good version of it, unless you have some 64-bit add-with-carry instruction or something else that you could make use of. Signed-off-by: Vineet Gupta vgu...@synopsys.com Acked-by: Arnd Bergmann a...@arndb.de -- 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 07/76] ARC: [optim] uaccess __{get,put}_user() optimised
On Friday 18 January 2013, Vineet Gupta wrote:
Override asm-generic implementations. We basically gain on 2 fronts
* checks for alignment no longer needed as we are only doing unit
sized copies.
(Careful observer could argue that While the kernel buffers are aligned,
the user buffer in theory might not be - however in that case the
user space is already broken when it tries to deref a hword/word
straddling word boundary - so we are not making it any worse).
* __copy_{to,from}_user( ) returns bytes that couldn't be copied,
whereas get_user() returns 0 for success or -EFAULT (not size). Thus
the code to do leftover bytes calculation can be avoided as well.
Interesting. I had thought that the compiler would be able to simplify
the calculation of the return value inline, but of course it cannot
because it has to be done inside the asm fixup.
The savings were significant: ~17k of code.
bloat-o-meter vmlinux_uaccess_pre vmlinux_uaccess_post
add/remove: 0/4 grow/shrink: 8/118 up/down: 1262/-18758 (-17496)
^
Signed-off-by: Vineet Gupta vgu...@synopsys.com
Acked-by: Arnd Bergmann a...@arndb.de
--
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 17/76] ARC: Process-creation/scheduling/idle-loop
On Friday 18 January 2013, Vineet Gupta wrote:
+void cpu_idle(void)
+{
+ /* Since we SLEEP in idle loop, TIF_POLLING_NRFLAG can't be set */
+
+ /* endless idle loop with no priority at all */
+ while (1) {
+ tick_nohz_idle_enter();
+ rcu_idle_enter();
+
+ while (!need_resched())
+ arch_idle();
+
+ rcu_idle_exit();
+ tick_nohz_idle_exit();
+
+ schedule_preempt_disabled();
+ }
+}
Unless I'm mistaken, you have introduced the classic sleep race
here, where an interrupt can happen between the check for
need_resched() and the sleep instruction in arch_idle().
To avoid that, you need to disable interrupts around
the inner loop. The sleep instruction should return with
interrupts implicitly enabled if ARC behaves like most
other architectures doing this.
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 29/76] ARC: Boot #1: low-level, setup_arch(), /proc/cpuinfo, mem init
On Friday 18 January 2013, Vineet Gupta wrote: + /* setup bootmem allocator */ + bootmap_sz = init_bootmem_node(NODE_DATA(0), + first_free_pfn,/* bitmap start */ + min_low_pfn, /* First pg to track */ + max_low_pfn); /* Last pg to track */ + + /* +* init_bootmem above marks all tracked Page-frames as inuse allocated +* This includes pages occupied by kernel's elf segments. +* Beyond that, excluding bootmem bitmap itself, mark the rest of +* free-mem as allocatable +*/ + alloc_start = kernel_img_end + bootmap_sz; + free_bootmem(alloc_start, end_mem - alloc_start); + + memset(zones_size, 0, sizeof(zones_size)); + zones_size[ZONE_NORMAL] = num_physpages; + IIRC, the bootmem allocator is no longer recommended for new architecture. You should use the memblock interface instead, as arm64 and tile do. I just saw that this is still listed as TODO for openrisc, sorry if I put you on the wrong track there by recommending to copy from openrisc. 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 44/76] ARC: ptrace support
On Friday 18 January 2013, Vineet Gupta wrote: Signed-off-by: Vineet Gupta vgu...@synopsys.com --- arch/arc/Kconfig |1 + arch/arc/kernel/Makefile |3 + arch/arc/kernel/entry.S | 69 +++ arch/arc/kernel/ptrace.c | 136 +- 4 files changed, 207 insertions(+), 2 deletions(-) Acked-by: Arnd Bergmann a...@arndb.de -- 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 48/76] ARC: Module support
On Friday 18 January 2013, Vineet Gupta wrote:
+int module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
+ char *secstr, struct module *mod)
+{
+return 0;
+}
+
+void module_arch_cleanup(struct module *mod)
+{
+}
+
+int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr *sechdrs,
+ struct module *mod)
+{
+return 0;
+}
These three empty functions are already defined __weak in kernel/module.c
so you can simply omit them here.
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 50/76] ARC: SMP support
On Friday 18 January 2013, Vineet Gupta wrote: +# If a plat can do IPI, same core(s) can do minimal SMP +config ARC_HAS_IPI + bool + I think it would be better to turn the logic around here, otherwise you get into trouble when enabling multiple platforms, out of which some have IPI support and others don't. Instead, you can mark the platforms that lack IPI support (or multiple CPUs) as 'depends on !SMP'. 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 56/76] ARC: Unaligned access emulation
On Friday 18 January 2013, Vineet Gupta wrote: ARC700 doesn't natively support unaligned access, but can be emulated -Unaligned Access Exception -Disassembly at the Fault address to find the exact insn (long/short) Also per Arnd's comment, we runtime control it using 2 sysctl knobs: * SYSCTL_ARCH_UNALIGN_ALLOW: Runtime enable/disble * SYSCTL_ARCH_UNALIGN_NO_WARN: Warn on each emulation attempt Originally contributed by Tim Yao tim@amlogic.com Signed-off-by: Vineet Gupta vgu...@synopsys.com Cc: Tim Yao tim@amlogic.com Acked-by: Arnd Bergmann a...@arndb.de -- 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 63/76] ARC: Hostlink Pseudo-Driver for Metaware Debugger
On Friday 18 January 2013, Vineet Gupta wrote: +static int arc_hl_nr_devs = 1; This seems to be read-only and hardcoded to 1. If this is true, you could simplify the driver significantly by just using misc_register, rather than registering your own major device number. 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 67/76] ARC: [Review] Multi-platform image #1: Kconfig enablement
On Friday 18 January 2013, Vineet Gupta wrote: This mini patchseries addresses the lack of multi-platform-image support in ARC port. Older build system only supported one platform(soc) to build at a time and further only one board of that platform could be built. There was no technical reason for that - we just didn't have the need. So the first step towards multi-platform (and multi-board) builds it to allow build system to do that. So as applicable, choice .. endchoice = menu .. endmenu Signed-off-by: Vineet Gupta vgu...@synopsys.com Cc: Arnd Bergmann a...@arndb.de Acked-by: Arnd Bergmann a...@arndb.de -- 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 68/76] ARC: Fold boards sub-menu into platform/SoC menu
On Friday 18 January 2013, Vineet Gupta wrote: This is more natural and is now doable since the choice constructs are gone. Signed-off-by: Vineet Gupta vgu...@synopsys.com --- Acked-by: Arnd Bergmann a...@arndb.de -- 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 69/76] ARC: [Review] Multi-platform image #2: Board callback Infrastructure
On Friday 18 January 2013, Vineet Gupta wrote:
The orig platform code orgnaization was singleton design pattern - only
one platform (and board thereof) would build at a time.
Thus any platform/board specific code (e.g. irq init, early init ...)
expected by ARC common code was exported as well defined set of APIs,
with only ONE instance building ever.
Now with multiple-platform build requirement, that design of code no
longer holds - multiple board specific calls need to build at the same
time - so ARC common code can't use the API approach, it needs a
callback based design where each board registers it's specific set of
functions, and at runtime, depending on board detection, the callbacks
are used from the registry.
This commit adds all the infrastructure, where board specific callbacks
are specified as a machine description.
All the hooks are placed in right spots, no board callbacks registered
yet (with MACHINE_STARt/END constructs) so the hooks will not run.
Next commit will actually convert the platform to this infrastructure.
Signed-off-by: Vineet Gupta vgu...@synopsys.com
Cc: Arnd Bergmann a...@arndb.de
Acked-by: Arnd Bergmann a...@arndb.de
+struct machine_desc {
+ const char *name;
+ const char **dt_compat;
+
+ void(*init_early)(void);
+ void(*init_irq)(void);
+ void(*init_time)(void);
+ void(*init_machine)(void);
+ void(*init_late)(void);
+
+#ifdef CONFIG_SMP
+ void(*init_smp)(unsigned int);
+#endif
On ARM, it turned out helpful to list these in the order in
which they get called. I assume that at least init_smp
is currently not in that order.
Also, we are slowly making some of these obsolete on
ARM: For platforms that at DT-only, the timer and
irq code is now in drivers/irqchip and drivers/clocksource
and can get automatically initialized.
It probably makese sense for you to keep the above structure
for now, but you can also think about obsoleting some
of the calls in the future. It may be a good idea to have
a default version for each of these but still allow overriding
them for maximum flexibility in the platform.
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 70/76] ARC: [Review] Multi-platform image #3: switch to board callback
On Friday 18 January 2013, Vineet Gupta wrote: -platform API is retired and instead callbacks are used Signed-off-by: Vineet Gupta vgu...@synopsys.com Acked-by: Arnd Bergmann a...@arndb.de -- 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 71/76] ARC: [Review] Multi-platform image #4: Isolate platform headers
On Friday 18 January 2013, Vineet Gupta wrote: -Top level ARC makefile removes -I for platform headers -asm/irq.h no longer includes plat/irq.h -platform makefile adds -I for it's specfic platform headers -platform code to directly include it's plat/irq.h -Linker script needed plat/memmap.h for CCM info, already in .config Signed-off-by: Vineet Gupta vgu...@synopsys.com Cc: Arnd Bergmann a...@arndb.de Acked-by: Arnd Bergmann a...@arndb.de -- 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 73/76] ARC: [Review] Multi-platform image #6: cpu-to-dma-addr optional
On Friday 18 January 2013, Vineet Gupta wrote: All the current platforms can work with 0x8000_ based dma_addr_t since the Bus Bridges typically ignore the top bit (the only excpetion was Angel4 PCI-AHM bridge which we no longer care for). That way we don't need plat-specific cpu-addr to bus-addr conversion. Hooks still provided - just in case a platform has an obscure device which say needs 0 based bus address. That way asm/dma_mapping.h no longer needs to unconditinally include plat/dma_addr.h Also verfied that on Angel4 board, other peripherals (IDE-disk / EMAC) work fine with 0x8000_ based dma addresses. Signed-off-by: Vineet Gupta vgu...@synopsys.com Cc: Arnd Bergmann a...@arndb.de Acked-by: Arnd Bergmann a...@arndb.de -- 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 74/76] ARC: [Review] Multi-platform image #7: SMP common code to use callbacks
On Friday 18 January 2013, Vineet Gupta wrote: This again is for switch from singleton platform SMP API to multi-platform paradigm Platform code is not yet setup to populate the callbacks, that happens in next commit Signed-off-by: Vineet Gupta vgu...@synopsys.com Cc: Arnd Bergmann a...@arndb.de Acked-by: Arnd Bergmann a...@arndb.de -- 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, 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 28/76] ARC: I/O and DMA Mappings
On Friday 18 January 2013, Vineet Gupta wrote:
TBD: Do we need early ioremap support like openrisc
Signed-off-by: Vineet Gupta vgu...@synopsys.com
Can you explain why early ioremap is necessary for you?
I wasn't aware that openrisc has it. In a lot of cases,
you can use fixmap as a replacement.
+
+#ifndef _ASM_ARC_IO_H
+#define _ASM_ARC_IO_H
+
+#include asm/byteorder.h
+#include asm/page.h
+
+extern void __iomem *ioremap(unsigned long physaddr, unsigned long size);
+extern void iounmap(const void __iomem *addr);
+
+#define ioremap_nocache(phy, sz) ioremap(phy, sz)
+#define ioremap_wc(phy, sz) ioremap(phy, sz)
+
+/* Change struct page to physical address */
+#define page_to_phys(page) (page_to_pfn(page) PAGE_SHIFT)
+
+#include asm-generic/io.h
I think I commented before that asm-generic/io.h has a number of
problems and you should at least override the __raw_{read,write}{b,w,l,q}
functions with your own ones using inline assembly.
You should also define a non-NULL PCI_IOBASE.
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 28/76] ARC: I/O and DMA Mappings
On Friday 18 January 2013, Paul Mundt wrote: On Fri, Jan 18, 2013 at 03:55:43PM +, Arnd Bergmann wrote: On Friday 18 January 2013, Vineet Gupta wrote: TBD: Do we need early ioremap support like openrisc Signed-off-by: Vineet Gupta vgu...@synopsys.com Can you explain why early ioremap is necessary for you? I wasn't aware that openrisc has it. In a lot of cases, you can use fixmap as a replacement. The two don't need to be mutually exclusive, either. sh implements early ioremap transparently via fixmaps for example: arch/sh/mm/ioremap.c arch/sh/mm/ioremap_fixed.c Ah, right. It also seems that openrisc uses the same approach for its early ioremap. I usually recommend doing as few things as possible early though, that's why I was asking. If it's only one or two drivers that need an early mapping and can't be moved to a later stage of bootup, using only hardcoded fixmaps would make it harder to add more users, which one might consider a good thing. Allowing ioremap to be used before memory_init() adds flexibility but could lead to code being moved into an early stage by accident rather than by necessity. 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 31/76] ARC: Build system: Makefiles, Kconfig, Linker script
On Friday 18 January 2013, Sam Ravnborg wrote: +obj-y:= arcksyms.o setup.o irq.o time.o reset.o ptrace.o entry.o process.o \ +signal.o traps.o sys.o troubleshoot.o stacktrace.o clk.o For new stuff I usually recommend to drop line continuation using \ Just do the much prettier: obj-y := arcksyms.o setup.o irq.o time.o reset.o ptrace.o entry.o process.o obj-y += signal.o traps.o sys.o troubleshoot.o stacktrace.o clk.o Agreed, although we are moving some files to the more verbose obj-y += arcksyms.o obj-y += clk.o obj-y += entry.o obj-y += ... and use alphabetical order, both of which help avoid merge conflicts when Makefile changes come in through separate branches. This particular Makefile is likely to remain rather stable though, so it's not necessary to go this far. 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: [RFC Patch v1 00/31] Synopsys ARC Linux kernel Port
On Friday 18 January 2013, Pavel Machek wrote: Yeah, and it is best use of reviewers time to confuse them with one-letter difference to very popular architecture... and use three letter acronym that was already taken. In this state, I hope your port never gets merged. Yes, I got used to do cd atab/artab. You already lost that capability with the addition of arm64. As you may remember, that one was proposed to be called arch/aarch64 at first, which wasn't very popular ;-) A lot of people are familiar with the ARC name, it's been around for decades and has sold billions of CPUs under that name, likely more than x86 or mips (still dwarfed by ARM of course). They've just kept a low profile so far and never tried to upstream their Linux port (unlike their gcc port, which was merged in 1997). I'm sure there are a lot of bad things one can say about Synopsys, but they are doing the right thing here, and calling their CPU architecture by a different name is not going to be helpful to their users. 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] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
On Saturday 19 January 2013, Soeren Moch wrote: What I can see in the log: a lot of coherent mappings from sata_mv and orion_ehci, a few from mv643xx_eth, no other coherent mappings. All coherent mappings are page aligned, some of them (from orion_ehci) are not really small (as claimed in __alloc_from_pool). Right. Unfortunately, the output does not show which of the mappings are atomic, so we still need to look through those that can be atomic to understand what's going on. There are a few megabytes of coherent mappings in total according to the output, but it seems that a significant portion of them is atomic, which is a bit unexpected. I don't believe in a memory leak. When I restart vdr (the application utilizing the dvb sticks) then there is enough dma memory available again. I found at least one source line that incorrectly uses an atomic allocation, in ehci_mem_init(): dma_alloc_coherent (ehci_to_hcd(ehci)-self.controller, ehci-periodic_size * sizeof(__le32), ehci-periodic_dma, 0); The last argument is the GFP_ flag, which should never be zero, as that is implicit !wait. This function is called only once, so it is not the actual culprit, but there could be other instances where we accidentally allocate something as GFP_ATOMIC. The total number of allocations I found for each type are sata_mv: 66 pages (270336 bytes) mv643xx_eth: 4 pages == (16384 bytes) orion_ehci: 154 pages (630784 bytes) orion_ehci (atomic): 256 pages (1048576 bytes) from the distribution of the numbers, it seems that there is exactly 1 MB of data allocated between bus addresses 0x1f9 and 0x1f9, allocated in individual pages. This matches the size of your pool, so it's definitely something coming from USB, and no single other allocation, but it does not directly point to a specific line of code. One thing I found was that the ARM dma-mapping code seems buggy in the way that it does a bitwise and between the gfp mask and GFP_ATOMIC, which does not work because GFP_ATOMIC is defined by the absence of __GFP_WAIT. I believe we need the patch below, but it is not clear to me if that issue is related to your problem or now. diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 6b2fb87..c57975f 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -640,7 +641,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle, if (is_coherent || nommu()) addr = __alloc_simple_buffer(dev, size, gfp, page); - else if (gfp GFP_ATOMIC) + else if (!(gfp __GFP_WAIT)) addr = __alloc_from_pool(size, page); else if (!IS_ENABLED(CONFIG_CMA)) addr = __alloc_remap_buffer(dev, size, gfp, prot, page, caller); @@ -1272,7 +1273,7 @@ static void *arm_iommu_alloc_attrs(struct device *dev, size_t size, *handle = DMA_ERROR_CODE; size = PAGE_ALIGN(size); - if (gfp GFP_ATOMIC) + if (!(gfp __GFP_WAIT)) return __iommu_alloc_atomic(dev, size, handle); pages = __iommu_alloc_buffer(dev, size, gfp, attrs); 8--- There is one more code path I could find, which is usb_submit_urb() = usb_hcd_submit_urb = ehci_urb_enqueue() = submit_async() = qh_append_tds() = qh_make(GFP_ATOMIC) = ehci_qh_alloc() = dma_pool_alloc() = pool_alloc_page() = dma_alloc_coherent() So even for a GFP_KERNEL passed into usb_submit_urb, the ehci driver causes the low-level allocation to be GFP_ATOMIC, because qh_append_tds() is called under a spinlock. If we have hundreds of URBs in flight, that will exhaust the pool rather quickly. 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] driver core: add wait event for deferred probe
On Thursday 14 February 2013, anish singh wrote: Grant, Can you please explain me this problem?My understanding is below: If all the detection of devices with there respective driver is done before __init section is freed then we will not have the problem mentioned. However if the driver requests the probing to be deferred then __init section of the deferred driver will not be freed right? The kernel has no idea which drivers are deferred at the time when all the __init sections are freed. I am afraid but the patch description is bit cryptic for me specially this line kernel has to open console failure release __init section before reinvoking failure. I would put it this way: With the introduction of deferred probing, the rules for the use of __init sections have changed slightly for some corner cases. While normal device drivers can, as before, not call __init functions from their .probe() callbacks, we could do that in drivers as long as they were built-in and did not support hotplug, and that exception was used in console drivers. This exception has now become more specific, and those drivers also must not use deferred probing that depends on other loadable modules or hotpluggable devices. Grant's patch fixes the corner case where you have a device whose .probe() callback gets deferred and waits for some object that is provided by a different built-in driver for a non-hotpluggable device, by making sure that this particular deferred probe has completed before the __init section is freed. Unlike Haojian's patch, it allows other deferred device probe functions that do not need to call __init functions to be delayed until much later, when a driver module is loaded or a device is hotplugged. 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: [Linaro-mm-sig] [PATCH 2/3] mutex: add support for reservation style locks
On Thursday 07 February 2013, Maarten Lankhorst wrote:
Hi Maarten,
I cannot help a lot on this patch set, but there are a few things that
I noticed when reading it.
Functions:
--
mutex_reserve_lock, and mutex_reserve_lock_interruptible:
Lock a buffer with a reservation_id set. reservation_id must not be
set to 0, since this is a special value that means no reservation_id.
I think the entire description should go into a file in the Documentation
directory, to make it easier to find without looking up the git history.
For the purpose of documenting this, it feels a little strange to
talk about buffers here. Obviously this is what you are using the
locks for, but it sounds like that is not the only possible use
case.
These functions will return -EDEADLK instead of -EAGAIN if
reservation_id is the same as the reservation_id that's attempted to
lock the mutex with, since in that case you presumably attempted to
lock the same lock twice.
Since the user always has to check the return value, would it be
possible to provide only the interruptible kind of this function
but not the non-interruptible one? In general, interruptible locks
are obviously harder to use, but they are much user friendlier when
something goes wrong.
mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
Similar to mutex_reserve_lock, except it won't backoff with -EAGAIN.
This is useful when mutex_reserve_lock failed with -EAGAIN, and you
unreserved all buffers so no deadlock can occur.
Are these meant to be used a lot? If not, maybe prefix them with __mutex_
instead of mutex_.
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 9121595..602c247 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -62,6 +62,11 @@ struct mutex {
#endif
};
+struct ticket_mutex {
+ struct mutex base;
+ atomic_long_t reservation_id;
+};
Have you considered changing the meaning of the count member
of the mutex in the case where a ticket mutex is used? That would
let you use an unmodified structure.
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] driver core: add wait event for deferred probe
On Thursday 14 February 2013, Russell King - ARM Linux wrote: In the general case, that remains true, but it's still not true for console drivers. The console should be initialised before it is attempted to be opened before passing control to userspace, which happens before the .init section is freed. Yes, I forgot about that. This is indeed an additional requirement besides what I listed. The late_initcall in which Grant was adding the serialization however is executed just before the /dev/console gets opened, which seems like an appropriate place. What might get into the way is that other late_initcalls get executed after this one and are required for the console. In that case, we would have to move the deferred_probe_initcall from a late_initcall to the end of do_basic_setup, after all the other initcalls. 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/
[PATCH 07/11] ARM: integrator: fix build with INTEGRATOR_AP off
The conditional declaration of ap_uart_data is broken
and causes this build error:
In file included from arch/arm/mach-integrator/core.c:35:0:
arch/arm/mach-integrator/common.h:6:37: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
Turning the check into an constant-expression if(IS_ENABLED()) statement
creates more readable code and solves this problem as well.
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
---
arch/arm/mach-integrator/common.h | 5 -
arch/arm/mach-integrator/core.c | 2 +-
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/mach-integrator/common.h
b/arch/arm/mach-integrator/common.h
index 79197d8..72516658b 100644
--- a/arch/arm/mach-integrator/common.h
+++ b/arch/arm/mach-integrator/common.h
@@ -1,10 +1,5 @@
#include linux/amba/serial.h
-#ifdef CONFIG_ARCH_INTEGRATOR_AP
extern struct amba_pl010_data ap_uart_data;
-#else
-/* Not used without Integrator/AP support anyway */
-struct amba_pl010_data ap_uart_data {};
-#endif
void integrator_init_early(void);
int integrator_init(bool is_cp);
void integrator_reserve(void);
diff --git a/arch/arm/mach-integrator/core.c b/arch/arm/mach-integrator/core.c
index 39c060f..81461d2 100644
--- a/arch/arm/mach-integrator/core.c
+++ b/arch/arm/mach-integrator/core.c
@@ -71,7 +71,7 @@ int __init integrator_init(bool is_cp)
* hard-code them. The Integator/CP and forward have proper cell IDs.
* Else we leave them undefined to the bus driver can autoprobe them.
*/
- if (!is_cp) {
+ if (!is_cp IS_ENABLED(CONFIG_ARCH_INTEGRATOR_AP)) {
rtc_device.periphid = 0x00041030;
uart0_device.periphid = 0x00041010;
uart1_device.periphid = 0x00041010;
--
1.8.1.2
--
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/
[PATCH 01/11] ARM: disable virt_to_bus/virt_to_bus almost everywhere
We are getting a number of warnings about the use of the deprecated
bus_to_virt function in drivers using the ARM ISA DMA API:
drivers/parport/parport_pc.c: In function 'parport_pc_fifo_write_block_dma':
drivers/parport/parport_pc.c:622:3: warning: 'bus_to_virt' is deprecated
(declared at arch/arm/include/asm/memory.h:253) [-Wdeprecated-declarations]
This is only because that function gets used by the inline
set_dma_addr() helper. We know that any driver for the ISA DMA API
is correctly using the DMA addresses, so we can change this
to use the __bus_to_virt() function instead, which does not warn.
After this, there are no remaining drivers that are used on
any defconfigs on ARM using virt_to_bus or bus_to_virt, with
the exception of the OSS sound driver. That driver is only used
on RiscPC, NetWinder and Shark, so we can set ARCH_NO_VIRT_TO_BUS
on all other platforms and hide the deprecated functions, which
is far more effective than marking them as deprecated, in order
to avoid any new users of that code.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Russell King li...@arm.linux.org.uk
---
arch/arm/Kconfig | 4
arch/arm/configs/shark_defconfig | 1 -
arch/arm/include/asm/dma.h | 2 +-
arch/arm/include/asm/memory.h| 2 ++
4 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..91d4aea 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1450,6 +1450,10 @@ config ISA_DMA
bool
select ISA_DMA_API
+config ARCH_NO_VIRT_TO_BUS
+ def_bool y
+ depends on !ARCH_RPC !ARCH_NETWINDER !ARCH_SHARK
+
# Select ISA DMA interface
config ISA_DMA_API
bool
diff --git a/arch/arm/configs/shark_defconfig b/arch/arm/configs/shark_defconfig
index caa07db..e319b2c 100644
--- a/arch/arm/configs/shark_defconfig
+++ b/arch/arm/configs/shark_defconfig
@@ -73,7 +73,6 @@ CONFIG_PARTITION_ADVANCED=y
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_ISO8859_1=m
-# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_SCHED_DEBUG is not set
diff --git a/arch/arm/include/asm/dma.h b/arch/arm/include/asm/dma.h
index 5694a0d..58b8c6a 100644
--- a/arch/arm/include/asm/dma.h
+++ b/arch/arm/include/asm/dma.h
@@ -105,7 +105,7 @@ extern void set_dma_sg(unsigned int chan, struct
scatterlist *sg, int nr_sg);
*/
extern void __set_dma_addr(unsigned int chan, void *addr);
#define set_dma_addr(chan, addr) \
- __set_dma_addr(chan, bus_to_virt(addr))
+ __set_dma_addr(chan, (void *)__bus_to_virt(addr))
/* Set the DMA byte count for this channel
*
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 1c4df27..474e2e6 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -245,6 +245,7 @@ static inline void *phys_to_virt(phys_addr_t x)
#define __bus_to_pfn(x)__phys_to_pfn(x)
#endif
+#ifdef CONFIG_VIRT_TO_BUS
static inline __deprecated unsigned long virt_to_bus(void *x)
{
return __virt_to_bus((unsigned long)x);
@@ -254,6 +255,7 @@ static inline __deprecated void *bus_to_virt(unsigned long
x)
{
return (void *)__bus_to_virt(x);
}
+#endif
/*
* Conversion between a struct page and a physical address.
--
1.8.1.2
--
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/
[PATCH 06/11] ARM: integrator/versatile: fix NOMMU warnings
On NOMMU kernels, the io_desc variables are unused
because we don't use the MMU to remap the MMIO
areas.
Marking these variables as __maybe_unused easily
avoids the otherwise harmless warnings like
warning: 'versatile_io_desc' defined but not used
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
---
arch/arm/mach-integrator/integrator_ap.c | 2 +-
arch/arm/mach-integrator/integrator_cp.c | 2 +-
arch/arm/mach-versatile/core.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-integrator/integrator_ap.c
b/arch/arm/mach-integrator/integrator_ap.c
index 11e2a41..11b1d21 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -94,7 +94,7 @@ void __iomem *ap_syscon_base;
* f1b01b00GPIO
*/
-static struct map_desc ap_io_desc[] __initdata = {
+static struct map_desc ap_io_desc[] __initdata __maybe_unused = {
{
.virtual= IO_ADDRESS(INTEGRATOR_HDR_BASE),
.pfn= __phys_to_pfn(INTEGRATOR_HDR_BASE),
diff --git a/arch/arm/mach-integrator/integrator_cp.c
b/arch/arm/mach-integrator/integrator_cp.c
index 7322838..01a888d 100644
--- a/arch/arm/mach-integrator/integrator_cp.c
+++ b/arch/arm/mach-integrator/integrator_cp.c
@@ -78,7 +78,7 @@ static void __iomem *intcp_con_base;
* fcb0cb00CP system control
*/
-static struct map_desc intcp_io_desc[] __initdata = {
+static struct map_desc intcp_io_desc[] __initdata __maybe_unused = {
{
.virtual= IO_ADDRESS(INTEGRATOR_HDR_BASE),
.pfn= __phys_to_pfn(INTEGRATOR_HDR_BASE),
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 5d59294..60c092c 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -114,7 +114,7 @@ void __init versatile_init_irq(void)
writel(PIC_MASK, VA_SIC_BASE + SIC_INT_PIC_ENABLE);
}
-static struct map_desc versatile_io_desc[] __initdata = {
+static struct map_desc versatile_io_desc[] __initdata __maybe_unused = {
{
.virtual= IO_ADDRESS(VERSATILE_SYS_BASE),
.pfn= __phys_to_pfn(VERSATILE_SYS_BASE),
--
1.8.1.2
--
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/
[PATCH 09/11] ARM: mvebu: allow selecting mvebu without Armada XP
Selecting only CONFIG_ARCH_MVEBU but not the respective options for Armada 370 or Armada XP results in these link errors: arch/arm/mach-mvebu/built-in.o: In function `armada_xp_smp_init_cpus': arch/arm/mach-mvebu/platsmp.c:91: undefined reference to `coherency_get_cpu_count' arch/arm/mach-mvebu/platsmp.c:104: undefined reference to `armada_mpic_send_doorbell' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_smp_prepare_cpus': arch/arm/mach-mvebu/platsmp.c:111: undefined reference to `set_cpu_coherent' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_boot_secondary': arch/arm/mach-mvebu/platsmp.c:83: undefined reference to `armada_xp_boot_cpu' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_secondary_init': arch/arm/mach-mvebu/platsmp.c:75: undefined reference to `armada_xp_mpic_smp_cpu_init' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_secondary_startup': arch/arm/mach-mvebu/headsmp.S:46: undefined reference to `ll_set_cpu_coherent' We can solve this by enabling all common MVEBU files that are referenced by the SMP files. This means we enable code that is not going to be used without a machine descriptor referencing it, but only if the kernel is configured specifically for this case. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Gregory Clement gregory.clem...@free-electrons.com Cc: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- arch/arm/mach-mvebu/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile index 99df4df..da93bcb 100644 --- a/arch/arm/mach-mvebu/Makefile +++ b/arch/arm/mach-mvebu/Makefile @@ -3,7 +3,8 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \ AFLAGS_coherency_ll.o := -Wa,-march=armv7-a -obj-y += system-controller.o -obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o coherency_ll.o pmsu.o +obj-y += system-controller.o +obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o +obj-$(CONFIG_ARCH_MVEBU)+= addr-map.o coherency.o coherency_ll.o pmsu.o irq-armada-370-xp.o obj-$(CONFIG_SMP)+= platsmp.o headsmp.o obj-$(CONFIG_HOTPLUG_CPU)+= hotplug.o -- 1.8.1.2 -- 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/
[PATCH 10/11] ARM: s3c: i2c: add platform_device forward declaration
A recent cleanup to the mach-osiris.c file is causing build errors because the i2c-s3c2410.h header file is included before we see the definition for platform_device. The fix is to make the header file more robust against inclusion from other places. While this should normally go through the i2c tree, the bug only exists in arm-soc at the moment, so it's easier to fix it there before it goes upstream. Without this patch, building s3c2410_defconfig results in: arch/arm/mach-s3c24xx/mach-osiris.c:34:0: include/linux/platform_data/i2c-s3c2410.h:37:26: warning: 'struct platform_device' declared inside parameter list [enabled by default] Signed-off-by: Arnd Bergmann a...@arndb.de Cc: linux-...@vger.kernel.org Cc: Wolfram Sang w.s...@pengutronix.de Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com --- include/linux/platform_data/i2c-s3c2410.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/platform_data/i2c-s3c2410.h b/include/linux/platform_data/i2c-s3c2410.h index 51d52e7..2a50048 100644 --- a/include/linux/platform_data/i2c-s3c2410.h +++ b/include/linux/platform_data/i2c-s3c2410.h @@ -15,6 +15,8 @@ #define S3C_IICFLG_FILTER (10) /* enable s3c2440 filter */ +struct platform_device; + /** * struct s3c2410_platform_i2c - Platform data for s3c I2C. * @bus_num: The bus number to use (if possible). -- 1.8.1.2 -- 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/
[PATCH 04/11] ARM: shmobile: fix defconfig warning on CONFIG_USB
A recent update to the marzen_defconfig introduced a duplicate CONFIG_USB=y line. This removes one of the two. arch/arm/configs/marzen_defconfig:86:warning: override: reassigning to symbol USB Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Simon Horman horms+rene...@verge.net.au Cc: linux...@vger.kernel.org --- arch/arm/configs/marzen_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/configs/marzen_defconfig b/arch/arm/configs/marzen_defconfig index 728a43c..afb17d6 100644 --- a/arch/arm/configs/marzen_defconfig +++ b/arch/arm/configs/marzen_defconfig @@ -83,7 +83,6 @@ CONFIG_USB=y CONFIG_USB_RCAR_PHY=y CONFIG_MMC=y CONFIG_MMC_SDHI=y -CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_HCD_PLATFORM=y -- 1.8.1.2 -- 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/
[PATCH 05/11] ARM: sa1100: don't warn about mach/ide.h
This warning has existed since before the start of (git) history.
Apparently nobody has bothered to fix it in a long time, and
this is unlikely to change. Note that the file that the warning
refers to has moved to a different location and was subsequently
deleted in 2008.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Russell King li...@arm.linux.org.uk
---
arch/arm/mach-sa1100/lart.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-sa1100/lart.c b/arch/arm/mach-sa1100/lart.c
index f69f78f..bca7e60 100644
--- a/arch/arm/mach-sa1100/lart.c
+++ b/arch/arm/mach-sa1100/lart.c
@@ -24,9 +24,6 @@
#include generic.h
-
-#warning include/asm/arch-sa1100/ide.h needs fixing for lart
-
static struct mcp_plat_data lart_mcp_data = {
.mccr0 = MCCR0_ADM,
.sclk_rate = 11981000,
--
1.8.1.2
--
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/
[PATCH 11/11] scripts/sortextable: silence script output
The exception table sorter outputs one line every time it gets called, e.g. 'sort done marker at 66dc00', which is slightly annoying when doing 'make -s' which is otherwise completely silent. Since that output is not helpful to most people building the kernel, turn it off by default. Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: David Daney david.da...@cavium.com Cc: H. Peter Anvin h...@zytor.com --- scripts/sortextable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/sortextable.h b/scripts/sortextable.h index e4fd45b..f5eb43d 100644 --- a/scripts/sortextable.h +++ b/scripts/sortextable.h @@ -182,7 +182,7 @@ do_func(Elf_Ehdr *ehdr, char const *const fname, table_sort_t custom_sort) _r(sort_needed_sym-st_value) - _r(sort_needed_sec-sh_addr); -#if 1 +#if 0 printf(sort done marker at %lx\n, (unsigned long)((char *)sort_done_location - (char *)ehdr)); #endif -- 1.8.1.2 -- 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/
[PATCH 02/11] ARM: samsung: fix assembly syntax for new gas
Recent assembler versions complain about extraneous whitespace inside [] brackets. This fixes all of these instances for the samsung platforms. We should backport this to all kernels that might need to be built with new binutils. arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]' arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]' arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]' arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]' arch/arm/mach-s3c24xx/sleep-s3c2410.S: Assembler messages: arch/arm/mach-s3c24xx/sleep-s3c2410.S:48: Error: ARM register expected -- `ldr r7,[ r4 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:49: Error: ARM register expected -- `ldr r8,[ r5 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:50: Error: ARM register expected -- `ldr r9,[ r6 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:64: Error: ARM register expected -- `streq r7,[ r4 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:65: Error: ARM register expected -- `streq r8,[ r5 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:66: Error: ARM register expected -- `streq r9,[ r6 ]' arch/arm/kernel/debug.S: Assembler messages: arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x5600)-(0x5000))+(0xF600+(0x0100-((0)+(((0x5600)-(0x5000))+(0xF600+(0x0100]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x5600)-(0x5000))+(0xF600+(0x0100-((0)+(((0x5600)-(0x5000))+(0xF600+(0x0100]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/mach-s3c24xx/pm-h1940.S: Assembler messages: arch/arm/mach-s3c24xx/pm-h1940.S:33: Error: ARM register expected -- `ldr pc,[ r0,#((0x0B8)+(((0x5600)-(0x5000))+(0xF600+(0x0100-(((0x5600)-(0x5000))+(0xF600+(0x0100)))]' arch/arm/mach-s3c24xx/sleep-s3c2412.S: Assembler messages: arch/arm/mach-s3c24xx/sleep-s3c2412.S:60: Error: ARM register expected -- `ldrne r9,[ r1 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:61: Error: ARM register expected -- `strne r9,[ r1 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:62: Error: ARM register expected -- `ldrne r9,[ r2 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:63: Error: ARM register expected -- `strne r9,[ r2 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:64: Error: ARM register expected -- `ldrne r9,[ r3 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:65: Error: ARM register expected -- `strne r9,[ r3 ]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]' Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Kukjin Kim kgene@samsung.com Cc: Ben Dooks ben-li...@fluff.org Cc: sta...@vger.kernel.org --- arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 12 ++-- arch/arm/mach-s3c24xx/include/mach/entry-macro.S | 4 ++-- arch/arm/mach-s3c24xx/pm-h1940.S | 2 +- arch/arm/mach-s3c24xx/sleep-s3c2410.S| 12 ++-- arch/arm/mach-s3c24xx/sleep-s3c2412.S| 12 ++-- arch/arm/plat-samsung/include/plat/debug-macro.S | 18 +- 6 files changed, 30 insertions(+), 30 deletions(-) diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S index 4135de8..13ed33c 100644 --- a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S +++ b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S @@ -40,17 +40,17 @@ addeq \rd, \rx, #(S3C24XX_PA_GPIO - S3C24XX_PA_UART) addne \rd, \rx, #(S3C24XX_VA_GPIO - S3C24XX_VA_UART) bic \rd, \rd, #0xff000 - ldr \rd, [ \rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0) ] + ldr \rd, [\rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0)] and \rd, \rd, #0x00ff teq \rd, #0x0044@ is it 2440? 1004: - ldr \rd, [ \rx, # S3C2410_UFSTAT ] + ldr \rd, [\rx, # S3C2410_UFSTAT] moveq \rd, \rd, lsr #SHIFT_2440TXF tst \rd, #S3C2410_UFSTAT_TXFULL .endm .macro fifo_full_s3c2410 rd, rx - ldr \rd, [ \rx, # S3C2410_UFSTAT ] + ldr \rd, [\rx, # S3C2410_UFSTAT] tst
[PATCH 00/11] ARM warning fixes for arm-soc
This is a set of bug fixes, most of which I have posted at least one time before. I will add them to the next/fixes-non-critical branch now, unless there are any last-minute objections. Arnd Bergmann (11): ARM: disable virt_to_bus/virt_to_bus almost everywhere ARM: samsung: fix assembly syntax for new gas ARM: w90x900: fix legacy assembly syntax ARM: shmobile: fix defconfig warning on CONFIG_USB ARM: sa1100: don't warn about mach/ide.h ARM: integrator/versatile: fix NOMMU warnings ARM: integrator: fix build with INTEGRATOR_AP off ARM: pick Versatile by default for !MMU ARM: mvebu: allow selecting mvebu without Armada XP ARM: s3c: i2c: add platform_device forward declaration scripts/sortextable: silence script output arch/arm/Kconfig | 7 ++- arch/arm/configs/marzen_defconfig| 1 - arch/arm/configs/shark_defconfig | 1 - arch/arm/include/asm/dma.h | 2 +- arch/arm/include/asm/memory.h| 2 ++ arch/arm/mach-integrator/common.h| 5 - arch/arm/mach-integrator/core.c | 2 +- arch/arm/mach-integrator/integrator_ap.c | 2 +- arch/arm/mach-integrator/integrator_cp.c | 2 +- arch/arm/mach-mvebu/Makefile | 5 +++-- arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 12 ++-- arch/arm/mach-s3c24xx/include/mach/entry-macro.S | 4 ++-- arch/arm/mach-s3c24xx/pm-h1940.S | 2 +- arch/arm/mach-s3c24xx/sleep-s3c2410.S| 12 ++-- arch/arm/mach-s3c24xx/sleep-s3c2412.S| 12 ++-- arch/arm/mach-sa1100/lart.c | 3 --- arch/arm/mach-versatile/Kconfig | 5 + arch/arm/mach-versatile/core.c | 2 +- arch/arm/mach-w90x900/include/mach/entry-macro.S | 4 ++-- arch/arm/plat-samsung/include/plat/debug-macro.S | 18 +- include/linux/platform_data/i2c-s3c2410.h| 2 ++ scripts/sortextable.h| 2 +- 22 files changed, 56 insertions(+), 51 deletions(-) -- 1.8.1.2 -- 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/
[PATCH 03/11] ARM: w90x900: fix legacy assembly syntax
New ARM binutils don't allow extraneous whitespace inside of brackets, which causes this error on all mach-w90x900 defconfigs: arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]' arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]' arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]' arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]' This removes the whitespace in order to build the kernel again. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Wan ZongShun mcuos@gmail.com --- arch/arm/mach-w90x900/include/mach/entry-macro.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-w90x900/include/mach/entry-macro.S b/arch/arm/mach-w90x900/include/mach/entry-macro.S index e286dac..0ff612a 100644 --- a/arch/arm/mach-w90x900/include/mach/entry-macro.S +++ b/arch/arm/mach-w90x900/include/mach/entry-macro.S @@ -19,8 +19,8 @@ mov \base, #AIC_BA - ldr \irqnr, [ \base, #AIC_IPER] - ldr \irqnr, [ \base, #AIC_ISNR] + ldr \irqnr, [\base, #AIC_IPER] + ldr \irqnr, [\base, #AIC_ISNR] cmp \irqnr, #0 .endm -- 1.8.1.2 -- 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/
[PATCH 08/11] ARM: pick Versatile by default for !MMU
The introduction of ARCH_MULTIPLATFORM changed the default for nommu kernels from Versatile to Integrator, which is less common, and does not currently build for allnoconfig because that does not select any of the CPUs. This also ensures that at least one of the three board files in versatile are enabled, which lets us successfully build an allnoconfig kernel. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Russell King li...@arm.linux.org.uk --- arch/arm/Kconfig| 3 ++- arch/arm/mach-versatile/Kconfig | 5 + 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 91d4aea..b934d90 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -261,7 +261,8 @@ config MMU # choice prompt ARM system type - default ARCH_MULTIPLATFORM + default ARCH_VERSATILE if !MMU + default ARCH_MULTIPLATFORM if MMU config ARCH_MULTIPLATFORM bool Allow multiple platforms to be selected diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig index 63d8e9f..1dba368 100644 --- a/arch/arm/mach-versatile/Kconfig +++ b/arch/arm/mach-versatile/Kconfig @@ -25,4 +25,9 @@ config MACH_VERSATILE_DT Include support for the ARM(R) Versatile/PB platform, using the device tree for discovery +config MACH_VERSATILE_AUTO + def_bool y + depends on !ARCH_VERSATILE_PB !MACH_VERSATILE_AB + select MACH_VERSATILE_DT + endmenu -- 1.8.1.2 -- 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] driver core: add wait event for deferred probe
On Thursday 14 February 2013, Haojian Zhuang wrote: If you can change it into code in below, it could work. Otherwise, it always fails. driver_deferred_probe_enable = true; driver_deferred_probe_trigger(); + deferred_probe_work_func(NULL); return 0; Because deferred_probe_work_func() depends on that deferred_probe is added into deferred_probe_active_list. If driver_deferred_probe_trigger() isn't called first, the deferred uart probe can't be added into active list. So even you call work_func at here, it doesn't help. Would that not cause two instances of the work function to run at the same time? That sounds like a source for a lot of problems. 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] driver core: add wait event for deferred probe
On Thursday 14 February 2013, Haojian Zhuang wrote: On 14 February 2013 23:57, Arnd Bergmann a...@arndb.de wrote: On Thursday 14 February 2013, Haojian Zhuang wrote: If you can change it into code in below, it could work. Otherwise, it always fails. driver_deferred_probe_enable = true; driver_deferred_probe_trigger(); + deferred_probe_work_func(NULL); return 0; Because deferred_probe_work_func() depends on that deferred_probe is added into deferred_probe_active_list. If driver_deferred_probe_trigger() isn't called first, the deferred uart probe can't be added into active list. So even you call work_func at here, it doesn't help. Would that not cause two instances of the work function to run at the same time? That sounds like a source for a lot of problems. Arnd Two instances of the work function? I'm sorry that I don't understanding your meaning. Could you help explain your question? I mean you end up calling the work function directly, while it gets run as part of the work queue on a different CPU at the same time. I just noticed that there is actually locking in place in deferred_probe_work_func that prevents any actual bugs, but you are still adding extra overhead here. Maybe just add flush_workqueue(deferred_wq); here? 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 06/15] clk: export __clk_get_name
On Tuesday 22 January 2013, Arnd Bergmann wrote: On Tuesday 22 January 2013, Fabio Estevam wrote: Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Sascha Hauer s.ha...@pengutronix.de Cc: Mike Turquette mturque...@linaro.org A fix from Niels de Vos has already been applied into clk-next: https://patchwork.kernel.org/patch/1871981/ Ok, very good. Mike, I saw that the patch is over a month old. Any reason it hasn't made it into v3.8.rc yet? I guess we missed this one for 3.8 then, meaning we have no working allmodconfig :( 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/
[PATCH 1/9] ARM: sa1100/assabet: include platform_device.h directly
Patch 16559ae kgdb: remove #include linux/serial_8250.h from kgdb.h caused assabet_defconfig to fail, since assabet.c did not itself include linux/platform_device.h, although it needs it: In file included from include/linux/mfd/ucb1x00.h:13:0, from arch/arm/mach-sa1100/assabet.c:19: include/linux/mfd/mcp.h:22:16: error: field 'attached_device' has incomplete type include/linux/mfd/mcp.h:48:23: error: field 'drv' has incomplete type In file included from arch/arm/mach-sa1100/assabet.c:19:0: include/linux/mfd/ucb1x00.h:137:16: error: field 'dev' has incomplete type arch/arm/mach-sa1100/assabet.c: In function 'assabet_init': arch/arm/mach-sa1100/assabet.c:343:3: error: implicit declaration of function 'platform_device_register_simple' [-Wimplicit-function-declaration] Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Russell King li...@arm.linux.org.uk Cc: Greg Kroah-Hartman gre...@linuxfoundation.org --- arch/arm/mach-sa1100/assabet.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-sa1100/assabet.c b/arch/arm/mach-sa1100/assabet.c index b38d252..e838ba2 100644 --- a/arch/arm/mach-sa1100/assabet.c +++ b/arch/arm/mach-sa1100/assabet.c @@ -16,6 +16,7 @@ #include linux/ioport.h #include linux/platform_data/sa11x0-serial.h #include linux/serial_core.h +#include linux/platform_device.h #include linux/mfd/ucb1x00.h #include linux/mtd/mtd.h #include linux/mtd/partitions.h -- 1.8.1.2 -- 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/
[PATCH 3/9] clk: sunxi: remove stale Makefile entry
Patch 85a18198 clk: sunxi: Use common of_clk_init() function removed the clk-sunxi.c file but left the Makefile entry, which causes a build error in multi_v7_defconfig: make[4]: *** No rule to make target `drivers/clk/clk-sunxi.o', needed by `drivers/clk/built-in.o'. The obvious fix is to remove the extraneous line from the Makefile. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Prashant Gaikwad pgaik...@nvidia.com Cc: Maxime Ripard maxime.rip...@anandra.org Cc: Mike Turquette mturque...@linaro.org --- drivers/clk/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index ce77077..be9392e 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -25,7 +25,6 @@ endif obj-$(CONFIG_MACH_LOONGSON1) += clk-ls1x.o obj-$(CONFIG_ARCH_U8500) += ux500/ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o -obj-$(CONFIG_ARCH_SUNXI) += clk-sunxi.o obj-$(CONFIG_ARCH_ZYNQ)+= clk-zynq.o obj-$(CONFIG_X86) += x86/ obj-$(CONFIG_ARCH_TEGRA) += tegra/ -- 1.8.1.2 -- 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/
[PATCH 8/9] [media] s5p-fimc: fix s5pv210 build
56bc911 [media] s5p-fimc: Redefine platform data structure for fimc-is
changed the bus_type member of struct fimc_source_info treewide, but
got one instance wrong in mach-s5pv210, which was evidently not
even build tested.
This adds the missing change to get s5pv210_defconfig to build again.
Applies on the Mauro's media tree.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
---
arch/arm/mach-s5pv210/mach-goni.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-s5pv210/mach-goni.c
b/arch/arm/mach-s5pv210/mach-goni.c
index 3a38f7b..e373de4 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -845,7 +845,7 @@ static struct fimc_source_info goni_camera_sensors[] = {
.mux_id = 0,
.flags = V4L2_MBUS_PCLK_SAMPLE_FALLING |
V4L2_MBUS_VSYNC_ACTIVE_LOW,
- .bus_type = FIMC_BUS_TYPE_ITU_601,
+ .fimc_bus_type = FIMC_BUS_TYPE_ITU_601,
.board_info = noon010pc30_board_info,
.i2c_bus_num= 0,
.clk_frequency = 1600UL,
--
1.8.1.2
--
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/
[PATCH 0/9] linux-next ARM defconfig fixes
I have tried building all ARM default configurations in linux-next today, and found a number of obvious problems that came in from somewhere other than the arm-soc tree (I have a separate series for those). Here are the fixes I came up with. Please apply or merge into the original patch that broke them, or find a different fix that solves the problem. Arnd Bergmann (9): ARM: sa1100/assabet: include platform_device.h directly fb/exynos: include platform_device.h clk: sunxi: remove stale Makefile entry mfd: max8925: fix trivial build warning for non-dt ARM: shmobile: mark mackerel sh_mmcif_device __maybe_unused drm/pci: move drm_pcie_get_speed_cap_mask inside #ifdef CONFIG_PCI ARM defconfigs: add missing inclusions of linux/platform_device.h [media] s5p-fimc: fix s5pv210 build thermal: rcar: remove __devinitconst Cc: Dave Airlie airl...@redhat.com Cc: Florian Tobias Schandinat florianschandi...@gmx.de Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Kukjin Kim kgene@samsung.com Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Mike Turquette mturque...@linaro.org Cc: Russell King li...@arm.linux.org.uk Cc: Samuel Ortiz sa...@linux.intel.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Zhang Rui rui.zh...@intel.com arch/arm/mach-s5pv210/mach-goni.c | 2 +- arch/arm/mach-sa1100/assabet.c | 1 + arch/arm/mach-shmobile/board-mackerel.c | 2 +- arch/arm/plat-samsung/include/plat/adc.h| 1 + drivers/clk/Makefile| 1 - drivers/gpu/drm/drm_pci.c | 75 - drivers/thermal/rcar_thermal.c | 2 +- drivers/video/backlight/max8925_bl.c| 6 +- drivers/video/clps711xfb.c | 1 + drivers/video/exynos/exynos_mipi_dsi_common.c | 1 + drivers/video/exynos/exynos_mipi_dsi_lowlevel.c | 1 + drivers/video/mmp/fb/mmpfb.c| 1 + include/linux/platform_data/s3c-hsotg.h | 2 + 13 files changed, 49 insertions(+), 47 deletions(-) -- 1.8.1.2 -- 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/
[PATCH 7/9] ARM defconfigs: add missing inclusions of linux/platform_device.h
Patch 16559ae kgdb: remove #include linux/serial_8250.h from kgdb.h
removed an implicit inclusion of linux/platform_device.h
In a number of places. This adds back explicit inclusions in a few
more places I found.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
---
arch/arm/plat-samsung/include/plat/adc.h | 1 +
drivers/video/clps711xfb.c | 1 +
drivers/video/mmp/fb/mmpfb.c | 1 +
include/linux/platform_data/s3c-hsotg.h | 2 ++
4 files changed, 5 insertions(+)
diff --git a/arch/arm/plat-samsung/include/plat/adc.h
b/arch/arm/plat-samsung/include/plat/adc.h
index b258a08..2fc8931 100644
--- a/arch/arm/plat-samsung/include/plat/adc.h
+++ b/arch/arm/plat-samsung/include/plat/adc.h
@@ -15,6 +15,7 @@
#define __ASM_PLAT_ADC_H __FILE__
struct s3c_adc_client;
+struct platform_device;
extern int s3c_adc_start(struct s3c_adc_client *client,
unsigned int channel, unsigned int nr_samples);
diff --git a/drivers/video/clps711xfb.c b/drivers/video/clps711xfb.c
index 5a7af0d..f009806 100644
--- a/drivers/video/clps711xfb.c
+++ b/drivers/video/clps711xfb.c
@@ -26,6 +26,7 @@
#include linux/fb.h
#include linux/init.h
#include linux/delay.h
+#include linux/platform_device.h
#include mach/hardware.h
#include asm/mach-types.h
diff --git a/drivers/video/mmp/fb/mmpfb.c b/drivers/video/mmp/fb/mmpfb.c
index f34a3a9..6d1fa96 100644
--- a/drivers/video/mmp/fb/mmpfb.c
+++ b/drivers/video/mmp/fb/mmpfb.c
@@ -21,6 +21,7 @@
*/
#include linux/module.h
#include linux/dma-mapping.h
+#include linux/platform_device.h
#include mmpfb.h
static int var_to_pixfmt(struct fb_var_screeninfo *var)
diff --git a/include/linux/platform_data/s3c-hsotg.h
b/include/linux/platform_data/s3c-hsotg.h
index 8b79e09..3f1cbf9 100644
--- a/include/linux/platform_data/s3c-hsotg.h
+++ b/include/linux/platform_data/s3c-hsotg.h
@@ -15,6 +15,8 @@
#ifndef __LINUX_USB_S3C_HSOTG_H
#define __LINUX_USB_S3C_HSOTG_H
+struct platform_device;
+
enum s3c_hsotg_dmamode {
S3C_HSOTG_DMA_NONE, /* do not use DMA at-all */
S3C_HSOTG_DMA_ONLY, /* always use DMA */
--
1.8.1.2
--
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/
[PATCH 5/9] ARM: shmobile: mark mackerel sh_mmcif_device __maybe_unused
Patch eac036ef9e ARM: shmobile: streamline mackerel SD and MMC devices
made the use of the sh_mmcif_device variable for mackarel optional,
but the definition is always provided, causing a build warning.
arch/arm/mach-shmobile/board-mackerel.c:1120:31: warning: 'sh_mmcif_device'
defined but not used [-Wunused-variable]
Marking the variable as __maybe_unused will do the right thing here.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Simon Horman horms+rene...@verge.net.au
---
arch/arm/mach-shmobile/board-mackerel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/board-mackerel.c
b/arch/arm/mach-shmobile/board-mackerel.c
index 0c78207..1de898f 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -1117,7 +1117,7 @@ static struct sh_mmcif_plat_data sh_mmcif_plat = {
.slave_id_rx= SHDMA_SLAVE_MMCIF_RX,
};
-static struct platform_device sh_mmcif_device = {
+static struct platform_device sh_mmcif_device __maybe_unused = {
.name = sh_mmcif,
.id = 0,
.dev= {
--
1.8.1.2
--
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/
[PATCH 9/9] thermal: rcar: remove __devinitconst
commit 76cc18874 thermal: rcar: add Device Tree support
added device tree support for this driver, but also added
an instance of __devinitconst, which is no longer defined
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Kuninori Morimoto kuninori.morimoto...@renesas.com
Cc: Zhang Rui rui.zh...@intel.com
---
drivers/thermal/rcar_thermal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 909bb4b..28f0919 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -476,7 +476,7 @@ static int rcar_thermal_remove(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id rcar_thermal_dt_ids[] __devinitconst = {
+static const struct of_device_id rcar_thermal_dt_ids[] = {
{ .compatible = renesas,rcar-thermal, },
{},
};
--
1.8.1.2
--
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/
[PATCH 2/9] fb/exynos: include platform_device.h
Patch 16559ae kgdb: remove #include linux/serial_8250.h from kgdb.h removed an implicit inclusion of linux/platform_device.h from the exynos framebuffer driver. This adds back the required explicit header file inclusions. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Ajay Kumar ajaykumar...@samsung.com Cc: Florian Tobias Schandinat florianschandi...@gmx.de --- drivers/video/exynos/exynos_mipi_dsi_common.c | 1 + drivers/video/exynos/exynos_mipi_dsi_lowlevel.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/video/exynos/exynos_mipi_dsi_common.c b/drivers/video/exynos/exynos_mipi_dsi_common.c index 3cd29a4..c70cb89 100644 --- a/drivers/video/exynos/exynos_mipi_dsi_common.c +++ b/drivers/video/exynos/exynos_mipi_dsi_common.c @@ -25,6 +25,7 @@ #include linux/io.h #include linux/memory.h #include linux/delay.h +#include linux/irqreturn.h #include linux/kthread.h #include video/mipi_display.h diff --git a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c index 0ef38ce..95cb99a 100644 --- a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c +++ b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c @@ -21,6 +21,7 @@ #include linux/fs.h #include linux/mm.h #include linux/ctype.h +#include linux/platform_device.h #include linux/io.h #include video/exynos_mipi_dsim.h -- 1.8.1.2 -- 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/
[PATCH 4/9] mfd: max8925: fix trivial build warning for non-dt
Patch fe527ea5a mfd: max8925: Support dt for backlight
added a new function for DT probing but introduced a
build warning for the case where CONFIG_OF is disabled:
drivers/video/backlight/max8925_bl.c: In function 'max8925_backlight_probe':
drivers/video/backlight/max8925_bl.c:177:3: warning: statement with no effect
[-Wunused-value]
A much nicer fix is to use the IS_ENABLED keyword to
have the same effect of dropping the device tree specific
function when it's not needed.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Qing Xu qi...@marvell.com
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/video/backlight/max8925_bl.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/backlight/max8925_bl.c
b/drivers/video/backlight/max8925_bl.c
index 5ca11b0..9958fb1 100644
--- a/drivers/video/backlight/max8925_bl.c
+++ b/drivers/video/backlight/max8925_bl.c
@@ -101,14 +101,13 @@ static const struct backlight_ops max8925_backlight_ops =
{
.get_brightness = max8925_backlight_get_brightness,
};
-#ifdef CONFIG_OF
static int max8925_backlight_dt_init(struct platform_device *pdev,
struct max8925_backlight_pdata *pdata)
{
struct device_node *nproot = pdev-dev.parent-of_node, *np;
int dual_string;
- if (!nproot)
+ if (!nproot || !IS_ENABLED(CONFIG_OF))
return -ENODEV;
np = of_find_node_by_name(nproot, backlight);
if (!np) {
@@ -120,9 +119,6 @@ static int max8925_backlight_dt_init(struct platform_device
*pdev,
pdata-dual_string = dual_string;
return 0;
}
-#else
-#define max8925_backlight_dt_init(x, y)(-1)
-#endif
static int max8925_backlight_probe(struct platform_device *pdev)
{
--
1.8.1.2
--
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/
[PATCH 6/9] drm/pci: move drm_pcie_get_speed_cap_mask inside #ifdef CONFIG_PCI
commit dd66cc2e1 drm/pci: Use PCI Express Capability accessors
introduced the use of the pcie_capability_read_dword function
in the drm_pci code, which is only defined when PCI is enabled.
While most of the file is already hidden away behind an #ifdef
CONFIG_PCI, this function is not, and that now causes a link
error in the ARM imx_v6_v7_defconfig configuration.
Moving the function into the #ifdef section makes this work
again on IMX, which does not have PCI support, and should
have no impact on platforms that do.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_pci.c | 75 +++
1 file changed, 37 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 86102a0..9c408e0 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -388,6 +388,43 @@ err_g1:
}
EXPORT_SYMBOL(drm_get_pci_dev);
+int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 *mask)
+{
+ struct pci_dev *root;
+ u32 lnkcap, lnkcap2;
+
+ *mask = 0;
+ if (!dev-pdev)
+ return -EINVAL;
+
+ root = dev-pdev-bus-self;
+
+ /* we've been informed via and serverworks don't make the cut */
+ if (root-vendor == PCI_VENDOR_ID_VIA ||
+ root-vendor == PCI_VENDOR_ID_SERVERWORKS)
+ return -EINVAL;
+
+ pcie_capability_read_dword(root, PCI_EXP_LNKCAP, lnkcap);
+ pcie_capability_read_dword(root, PCI_EXP_LNKCAP2, lnkcap2);
+
+ if (lnkcap2) { /* PCIe r3.0-compliant */
+ if (lnkcap2 PCI_EXP_LNKCAP2_SLS_2_5GB)
+ *mask |= DRM_PCIE_SPEED_25;
+ if (lnkcap2 PCI_EXP_LNKCAP2_SLS_5_0GB)
+ *mask |= DRM_PCIE_SPEED_50;
+ if (lnkcap2 PCI_EXP_LNKCAP2_SLS_8_0GB)
+ *mask |= DRM_PCIE_SPEED_80;
+ } else {/* pre-r3.0 */
+ if (lnkcap PCI_EXP_LNKCAP_SLS_2_5GB)
+ *mask |= DRM_PCIE_SPEED_25;
+ if (lnkcap PCI_EXP_LNKCAP_SLS_5_0GB)
+ *mask |= (DRM_PCIE_SPEED_25 | DRM_PCIE_SPEED_50);
+ }
+
+ DRM_INFO(probing gen 2 caps for device %x:%x = %x/%x\n, root-vendor,
root-device, lnkcap, lnkcap2);
+ return 0;
+}
+EXPORT_SYMBOL(drm_pcie_get_speed_cap_mask);
/**
* PCI device initialization. Called direct from modules at load time.
*
@@ -465,41 +502,3 @@ void drm_pci_exit(struct drm_driver *driver, struct
pci_driver *pdriver)
DRM_INFO(Module unloaded\n);
}
EXPORT_SYMBOL(drm_pci_exit);
-
-int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 *mask)
-{
- struct pci_dev *root;
- u32 lnkcap, lnkcap2;
-
- *mask = 0;
- if (!dev-pdev)
- return -EINVAL;
-
- root = dev-pdev-bus-self;
-
- /* we've been informed via and serverworks don't make the cut */
- if (root-vendor == PCI_VENDOR_ID_VIA ||
- root-vendor == PCI_VENDOR_ID_SERVERWORKS)
- return -EINVAL;
-
- pcie_capability_read_dword(root, PCI_EXP_LNKCAP, lnkcap);
- pcie_capability_read_dword(root, PCI_EXP_LNKCAP2, lnkcap2);
-
- if (lnkcap2) { /* PCIe r3.0-compliant */
- if (lnkcap2 PCI_EXP_LNKCAP2_SLS_2_5GB)
- *mask |= DRM_PCIE_SPEED_25;
- if (lnkcap2 PCI_EXP_LNKCAP2_SLS_5_0GB)
- *mask |= DRM_PCIE_SPEED_50;
- if (lnkcap2 PCI_EXP_LNKCAP2_SLS_8_0GB)
- *mask |= DRM_PCIE_SPEED_80;
- } else {/* pre-r3.0 */
- if (lnkcap PCI_EXP_LNKCAP_SLS_2_5GB)
- *mask |= DRM_PCIE_SPEED_25;
- if (lnkcap PCI_EXP_LNKCAP_SLS_5_0GB)
- *mask |= (DRM_PCIE_SPEED_25 | DRM_PCIE_SPEED_50);
- }
-
- DRM_INFO(probing gen 2 caps for device %x:%x = %x/%x\n, root-vendor,
root-device, lnkcap, lnkcap2);
- return 0;
-}
-EXPORT_SYMBOL(drm_pcie_get_speed_cap_mask);
--
1.8.1.2
--
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/
[PATCH 3/9] ARM: omap2: include linux/errno.h in hwmod_reset
The newly created omap_hwmod_reset.c is missing an include of linux/errno.h in commit c02060d8 ARM: OMAP4+: AESS: enable internal auto-gating during initial setup. It still works in omap2_defconfig, but not in all other combinations. Without this patch, building allmodconfig results in: arch/arm/mach-omap2/omap_hwmod_reset.c: In function 'omap_hwmod_aess_preprogram': arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: error: 'EINVAL' undeclared (first use in this function) arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: note: each undeclared identifier is reported only once for each function it appears in Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Paul Walmsley p...@pwsan.com Cc: Sebastien Guiriec s-guir...@ti.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/omap_hwmod_reset.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c b/arch/arm/mach-omap2/omap_hwmod_reset.c index bba43fa..65e186c 100644 --- a/arch/arm/mach-omap2/omap_hwmod_reset.c +++ b/arch/arm/mach-omap2/omap_hwmod_reset.c @@ -24,6 +24,7 @@ * 02110-1301 USA */ #include linux/kernel.h +#include linux/errno.h #include sound/aess.h -- 1.8.1.2 -- 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/
[PATCH 7/9] remoteproc: omap: depend on OMAP_MBOX_FWK
Patch a62a6e98 ARM: OMAP2+: Disable code that currently does not work with multiplaform makes the OMAP_MBOX_FWK option depend on !MULTIPLATFORM, which means we cannot simply select that symbol from OMAP_REMOTEPROC. Turning the 'select' into 'depends on' ensures that all dependencies are correct until OMAP_MBOX_FWK loses its dependency. Without this patch, building allmodconfig results in: drivers/remoteproc/omap_remoteproc.c:31:26: fatal error: plat/mailbox.h: No such file or directory Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Tony Lindgren t...@atomide.com Cc: Ohad Ben-Cohen o...@wizery.com --- drivers/remoteproc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index 0b24108..cc1f7bf 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -12,8 +12,8 @@ config OMAP_REMOTEPROC depends on HAS_DMA depends on ARCH_OMAP4 depends on OMAP_IOMMU + depends on OMAP_MBOX_FWK select REMOTEPROC - select OMAP_MBOX_FWK select RPMSG help Say y here to support OMAP's remote processors (dual M3 -- 1.8.1.2 -- 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/
[PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
Patch c08e20d24 arm: Add v7_invalidate_l1 to cache-v7.S moves the v7_invalidate_l1 symbol out of imx/headsmp.S, which seems to cause a link error because it is now too far away from v7_cpu_resume when building an allyesconfig kernel. If we move the v7_cpu_resume function from the .data section to .text, that creates another link error for the reference to phys_l2x0_saved_regs, but we can move all of the above to .text. I believe that this is not a correct bug fix but just a bad workaround, so I'm open to ideas from people who understand the bigger picture. Without this patch, building allyesconfig results in: arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume': arch/arm/mach-imx/headsmp.S:55:(.data+0x87f8): relocation truncated to fit: R_ARM_CALL against symbol `v7_invalidate_l1' defined in .text section in arch/arm/mm/built-in.o Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Shawn Guo shawn@linaro.org Cc: Sascha Hauer s.ha...@pengutronix.de Cc: Dinh Nguyen dingu...@altera.com Cc: Pavel Machek pa...@denx.de Cc: Stephen Warren swar...@nvidia.com Cc: Simon Horman horms+rene...@verge.net.au --- arch/arm/mach-imx/headsmp.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S index 921fc15..0de76cc 100644 --- a/arch/arm/mach-imx/headsmp.S +++ b/arch/arm/mach-imx/headsmp.S @@ -30,7 +30,7 @@ ENDPROC(v7_secondary_startup) * allow phys_l2x0_saved_regs to be accessed with a relative load * as we are running on physical address here. */ - .data + .text .align #ifdef CONFIG_CACHE_L2X0 @@ -51,6 +51,8 @@ phys_l2x0_saved_regs: .endm #endif + .text + ENTRY(v7_cpu_resume) bl v7_invalidate_l1 pl310_resume -- 1.8.1.2 -- 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/
[PATCH 0/9] arm-soc/for-next allyesconfig build regressions
These are the patches I still need to cleanly build allyesconfig and allmodconfig on arm-soc/for-next. Please review and provide Acks where appropriate so we can add the fixes directly to the branches that introduce the problems, or apply them directly to a maintainer tree where appropriate. The bulk of these patches happen to be omap specific, which does not mean that we had a lot of regressions in omap, but that we just started including omap in the multiplatform builds, which has uncovered a number of older problems that we did not see before. Arnd Arnd Bergmann (9): ARM: arch_timer: include linux/errno.h ARM: imx: MACH_MX31ADS_WM1133_EV1 needs REGULATOR_WM8350 ARM: omap2: include linux/errno.h in hwmod_reset ARM: omap: add include guard for soc.h drm: export drm_vm_open_locked net: cwdavinci_cpdma: export symbols for cpsw remoteproc: omap: depend on OMAP_MBOX_FWK [HACK] ARM: imx: work around v7_cpu_resume link error [media] davinci: do not include mach/hardware.h Cc: Catalin Marinas catalin.mari...@arm.com Cc: Dave Airlie airl...@redhat.com Cc: Marc Zyngier marc.zyng...@arm.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Paul Walmsley p...@pwsan.com Cc: Rob Clark r...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Sascha Hauer s.ha...@pengutronix.de Cc: Shawn Guo shawn@linaro.org Cc: Tony Lindgren t...@atomide.com Cc: net...@vger.kernel.org arch/arm/kernel/arch_timer.c| 1 + arch/arm/mach-imx/Kconfig | 2 +- arch/arm/mach-imx/headsmp.S | 4 +++- arch/arm/mach-omap2/omap_hwmod_reset.c | 1 + arch/arm/mach-omap2/soc.h | 3 +++ drivers/gpu/drm/drm_vm.c| 1 + drivers/media/platform/davinci/vpss.c | 1 - drivers/net/ethernet/ti/davinci_cpdma.c | 3 +++ drivers/remoteproc/Kconfig | 2 +- 9 files changed, 14 insertions(+), 4 deletions(-) -- 1.8.1.2 -- 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/
[PATCH 5/9] drm: export drm_vm_open_locked
Since the exynos DRM driver can now be built as a module on
all multiplatform configurations, an existing bug has
become visible: The exynos driver uses the drm_vm_open_locked
function that is not exported. The obvious solution is to
export that symbol.
Without this patch, building ARM allmodconfig results in:
ERROR: drm_vm_open_locked [drivers/gpu/drm/exynos/exynosdrm.ko] undefined!
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Dave Airlie airl...@redhat.com
Cc: Shirish S s.shir...@samsung.com
Cc: Inki Dae inki@samsung.com
Cc: Rob Clark r...@ti.com
---
drivers/gpu/drm/drm_vm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index db7bd29..1d4f7c9 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -422,6 +422,7 @@ void drm_vm_open_locked(struct drm_device *dev,
list_add(vma_entry-head, dev-vmalist);
}
}
+EXPORT_SYMBOL_GPL(drm_vm_open_locked);
static void drm_vm_open(struct vm_area_struct *vma)
{
--
1.8.1.2
--
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/
[PATCH 1/9] ARM: arch_timer: include linux/errno.h
Patch 8a4da6e arm: arch_timer: move core to drivers/clocksource moved a lot of code out of arch_timer.c, but ended up deleting too much, which broke some configurations. Obviously, include linux/errno.h is required to return error values. Without this patch, building allmodconfig results in: arch/arm/kernel/arch_timer.c: In function 'arch_timer_sched_clock_init': arch/arm/kernel/arch_timer.c:55:11: error: 'ENXIO' undeclared (first use in this function) arch/arm/kernel/arch_timer.c:55:11: note: each undeclared identifier is reported only once for each function it appears in Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Mark Rutland mark.rutl...@arm.com Cc: Catalin Marinas catalin.mari...@arm.com Cc: Marc Zyngier marc.zyng...@arm.com --- arch/arm/kernel/arch_timer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c index 36ebcf4..d957a51 100644 --- a/arch/arm/kernel/arch_timer.c +++ b/arch/arm/kernel/arch_timer.c @@ -10,6 +10,7 @@ */ #include linux/init.h #include linux/types.h +#include linux/errno.h #include asm/delay.h #include asm/sched_clock.h -- 1.8.1.2 -- 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/
[PATCH 6/9] net: cwdavinci_cpdma: export symbols for cpsw
With the support for ARM AM33xx in multiplatform kernels
in 3.9, an older bug appears in ARM allmodconfig:
When the cpsw driver is built as a module with cpdma
support enabled, it uses symbols that the cpdma driver
does not export.
Without this patch, building allmodconfig results in:
ERROR: cpdma_ctlr_int_ctrl [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
ERROR: cpdma_control_set [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
ERROR: cpdma_ctlr_eoi [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Mugunthan V N mugunthan...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
Cc: Richard Cochran richardcoch...@gmail.com
Cc: net...@vger.kernel.org
---
drivers/net/ethernet/ti/davinci_cpdma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
b/drivers/net/ethernet/ti/davinci_cpdma.c
index 7d3bffd..8eeb7c9 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -492,11 +492,13 @@ int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool
enable)
spin_unlock_irqrestore(ctlr-lock, flags);
return 0;
}
+EXPORT_SYMBOL_GPL(cpdma_ctlr_int_ctrl);
void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr)
{
dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 0);
}
+EXPORT_SYMBOL_GPL(cpdma_ctlr_eoi);
struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
cpdma_handler_fn handler)
@@ -1028,3 +1030,4 @@ unlock_ret:
spin_unlock_irqrestore(ctlr-lock, flags);
return ret;
}
+EXPORT_SYMBOL_GPL(cpdma_control_set);
--
1.8.1.2
--
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/
[PATCH 9/9] [media] davinci: do not include mach/hardware.h
It is now possible to build the davinci vpss code on multiplatform kernels, which causes a problem since the driver tries to incude the davinci platform specific mach/hardware.h file. Fortunately that file is not required at all in the driver, so we can simply remove the #include statement. Without this patch, building allyesconfig results in: drivers/media/platform/davinci/vpss.c:28:27: fatal error: mach/hardware.h: No such file or directory compilation terminated. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Lad, Prabhakar prabhakar@ti.com Cc: Tony Lindgren t...@atomide.com --- drivers/media/platform/davinci/vpss.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/platform/davinci/vpss.c b/drivers/media/platform/davinci/vpss.c index 494d322..a19c552 100644 --- a/drivers/media/platform/davinci/vpss.c +++ b/drivers/media/platform/davinci/vpss.c @@ -25,7 +25,6 @@ #include linux/spinlock.h #include linux/compiler.h #include linux/io.h -#include mach/hardware.h #include media/davinci/vpss.h MODULE_LICENSE(GPL); -- 1.8.1.2 -- 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/
[PATCH 4/9] ARM: omap: add include guard for soc.h
Commit e4c060db ARM: OMAP: Split plat/cpu.h into local soc.h for mach-omap1 and mach-omap2 moved the bulk of plat/cpu.h into cpu.h but did not add an include guard for the new file that was present in the old one. There are cases where the file is indeed included multiple times, probably by accident, but adding the include guard ensures that this has no further consequences. Without this patch, building allmodconfig results in lots of warnings like: In file included from arch/arm/mach-omap2/drm.c:31:0: arch/arm/mach-omap2/soc.h:206:0: warning: cpu_is_omap24xx redefined [enabled by default] In file included from arch/arm/mach-omap2/drm.c:28:0: arch/arm/mach-omap2/soc.h:227:0: note: this is the location of the previous definition In file included from arch/arm/mach-omap2/drm.c:31:0: arch/arm/mach-omap2/soc.h:207:0: warning: cpu_is_omap242x redefined [enabled by default] Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/soc.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h index c62116b..97dd373 100644 --- a/arch/arm/mach-omap2/soc.h +++ b/arch/arm/mach-omap2/soc.h @@ -24,6 +24,8 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * */ +#ifndef OMAP2_SOC_H +#define OMAP2_SOC_H #include omap24xx.h #include omap34xx.h @@ -497,3 +499,4 @@ level(__##fn); #endif /* __ASSEMBLY__ */ +#endif -- 1.8.1.2 -- 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/
[PATCH 2/9] ARM: imx: MACH_MX31ADS_WM1133_EV1 needs REGULATOR_WM8350
MACH_MX31ADS_WM1133_EV1 already depends on REGULATOR_WM8350, but that still allows REGULATOR_WM8350 to be a loadable module. Depending on REGULATOR_WM8350 to be built-in ensures we cannot create a broken configuration. Without this patch, building allmodconfig results in: arch/arm/mach-imx/built-in.o: In function `mx31_wm8350_init': arch/arm/mach-imx/mach-mx31ads.c:461: undefined reference to `wm8350_register_regulator' arch/arm/mach-imx/mach-mx31ads.c:471: undefined reference to `wm8350_dcdc_set_slot' arch/arm/mach-imx/mach-mx31ads.c:473: undefined reference to `wm8350_isink_set_flash' arch/arm/mach-imx/mach-mx31ads.c:480: undefined reference to `wm8350_dcdc25_set_mode' arch/arm/mach-imx/mach-mx31ads.c:485: undefined reference to `wm8350_register_led' Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Shawn Guo shawn@linaro.org Cc: Sascha Hauer s.ha...@pengutronix.de Cc: Axel Lin axel@gmail.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com --- arch/arm/mach-imx/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 7b11d33..4c9c6f9 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -480,7 +480,7 @@ config MACH_MX31ADS_WM1133_EV1 bool Support Wolfson Microelectronics 1133-EV1 module depends on MACH_MX31ADS depends on MFD_WM8350_I2C - depends on REGULATOR_WM8350 + depends on REGULATOR_WM8350 = y select MFD_WM8350_CONFIG_MODE_0 select MFD_WM8352_CONFIG_MODE_0 help -- 1.8.1.2 -- 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 6/9] drm/pci: move drm_pcie_get_speed_cap_mask inside #ifdef CONFIG_PCI
On Thursday 14 February 2013, Fabio Estevam wrote: Bjorn has already sent a fix for this problem: http://www.spinics.net/lists/arm-kernel/msg224425.html Ok, excellent. The result seems to be identical, although patch is formatted differently. Acked-by: Arnd Bergmann a...@arndb.de for Bjorn's patch. -- 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 4/9] ARM: omap: add include guard for soc.h
On Thursday 14 February 2013, Tony Lindgren wrote: I left it out intentionally as these are private to mach-omap2, and I'd like to simplify the indirect includes there further. So I'd rather just remove the duplicate soc.h from drm.c. If people really think this should be applied, I have no objections to this patch naturally. Either way is fine with me. 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 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
On Thursday 14 February 2013, Stephen Warren wrote: On 02/14/2013 03:47 PM, Arnd Bergmann wrote: Patch c08e20d24 arm: Add v7_invalidate_l1 to cache-v7.S moves the v7_invalidate_l1 symbol out of imx/headsmp.S, which seems to cause a link error because it is now too far away from v7_cpu_resume when building an allyesconfig kernel. Is the problem from the following in arch/arm/mach-imx/headsmp.S: ENTRY(v7_cpu_resume) bl v7_invalidate_l1 Isn't the range of bl +/- 32MiB (or +/- 16MibB in Thumb 2). Is the kernel really that big? Sorry, I'm having trouble understanding what causes the problem. Well, it is an allyesconfig kernel, so things can get pretty big: $ size obj-tmp/vmlinux -A obj-tmp/vmlinux : section size addr .head.text504 3221258240 .text32707336 3221258752 .text.head 8 3253966088 .rodata 14028722 3253968896 __bug_table127764 3267997624 .builtin_fw 684 3268125388 __ksymtab 53424 3268126072 __ksymtab_gpl 43560 3268179496 __kcrctab 26712 3268223056 __kcrctab_gpl 21780 3268249768 __ksymtab_strings 233706 3268271548 __param 33104 3268505256 __modver 4104 3268538360 __ex_table 4112 3268542464 .ARM.unwind_idx967784 3268546576 .ARM.unwind_tab 1452168 3269514360 .notes 36 3270966528 .init.text 677840 3270967296 .exit.text 125672 3271645136 .init.arch.info 5396 3271770808 .init.tagtable 72 3271776204 .init.smpalt 928 3271776276 .init.pv_table 1704 3271777204 .init.data 678108 3271778912 .exit.data119 3272457020 .data..percpu 1460032 3272458240 .data 3370068 3273924608 .tcm_start940 3277294676 .bss 8007724 3277295616 .comment 430 .ARM.attributes500 .debug_line 157803630 .debug_info 571921430 .debug_abbrev 57473740 .debug_aranges 2996080 .debug_ranges 54145920 .debug_frame 48017480 .debug_str70032820 .debug_loc 362374760 Total 196510790 THUMB2 support is obviously enabled (allyesconfig), and from the start of the .head.text section to the end of .bss, it is 64,045,100 bytes, using yesterday's linux-next kernel with my fixes. It will get bigger as we add more stuff to multiplatform. The .text section alone is just short of 32MB. 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 3/9] clk: sunxi: remove stale Makefile entry
On Friday 15 February 2013, Mike Turquette wrote: Quoting Arnd Bergmann (2013-02-14 14:26:52) Patch 85a18198 clk: sunxi: Use common of_clk_init() function removed the clk-sunxi.c file but left the Makefile entry, which causes a build error in multi_v7_defconfig: make[4]: *** No rule to make target `drivers/clk/clk-sunxi.o', needed by `drivers/clk/built-in.o'. The obvious fix is to remove the extraneous line from the Makefile. The fix is correct. I can't rebase my branch since there is an existing dependency with the tegra tree, so I have taken this patch as-is with the addition of my SoB. Ok, thanks! 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 3/9] ARM: omap2: include linux/errno.h in hwmod_reset
On Thursday 14 February 2013, Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [130214 14:51]: The newly created omap_hwmod_reset.c is missing an include of linux/errno.h in commit c02060d8 ARM: OMAP4+: AESS: enable internal auto-gating during initial setup. It still works in omap2_defconfig, but not in all other combinations. Without this patch, building allmodconfig results in: arch/arm/mach-omap2/omap_hwmod_reset.c: In function 'omap_hwmod_aess_preprogram': arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: error: 'EINVAL' undeclared (first use in this function) arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: note: each undeclared identifier is reported only once for each function it appears in Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Paul Walmsley p...@pwsan.com Cc: Sebastien Guiriec s-guir...@ti.com Acked-by: Tony Lindgren t...@atomide.com Ok, applied on top of late/omap 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 4/9] ARM: omap: add include guard for soc.h
On Thursday 14 February 2013, Tony Lindgren wrote: I left it out intentionally as these are private to mach-omap2, and I'd like to simplify the indirect includes there further. So I'd rather just remove the duplicate soc.h from drm.c. If people really think this should be applied, I have no objections to this patch naturally. The duplicate #include was a result of an automated mismerge between v3.8-rc5 and the omap/multiplatform branch. I have merge v3.8-rc5 into next/multiplatform to resolve this correctly, and pulled in a new omap/multiplatform-fixes branch with patches 6, 7, and 9 from this series. 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 5/9] ARM: shmobile: mark mackerel sh_mmcif_device __maybe_unused
On Thursday 14 February 2013, Simon Horman wrote: On Thu, Feb 14, 2013 at 11:26:54PM +0100, Arnd Bergmann wrote: Patch eac036ef9e ARM: shmobile: streamline mackerel SD and MMC devices made the use of the sh_mmcif_device variable for mackarel optional, but the definition is always provided, causing a build warning. arch/arm/mach-shmobile/board-mackerel.c:1120:31: warning: 'sh_mmcif_device' defined but not used [-Wunused-variable] Marking the variable as __maybe_unused will do the right thing here. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Simon Horman horms+rene...@verge.net.au No objections here. Acked-by: Simon Horman horms+rene...@verge.net.au AFAICT, the change that caused this is in linux-next only through your heads/boards3 branch but not through arm-soc, so please apply my patch on your branch. 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/
fb: mmp: include linux/platform_device.h
Patch 16559ae kgdb: remove #include linux/serial_8250.h from kgdb.h changes the kgdb.h file so that drivers including it do not implicitly include linux/platform_device.h. The mmp framebuffer driver is new, so Greg did not have a chance to fix it up when introducing his change. Signed-off-by: Arnd Bergmann a...@arndb.de --- On Thursday 14 February 2013, Greg Kroah-Hartman wrote: On Thu, Feb 14, 2013 at 11:26:56PM +0100, Arnd Bergmann wrote: Patch 16559ae kgdb: remove #include linux/serial_8250.h from kgdb.h removed an implicit inclusion of linux/platform_device.h In a number of places. This adds back explicit inclusions in a few more places I found. drivers/video/mmp/fb/mmpfb.c | 1 + This file isn't my tty tree, so I can't apply that part of the patch, but I've applied the rest of the patch, and the 2 others you sent me to fix this issue. Right. It seems the driver is only in Andrew's tree. Andrew, can you add this hunk on top? diff --git a/drivers/video/mmp/fb/mmpfb.c b/drivers/video/mmp/fb/mmpfb.c index f34a3a9..6d1fa96 100644 --- a/drivers/video/mmp/fb/mmpfb.c +++ b/drivers/video/mmp/fb/mmpfb.c @@ -21,6 +21,7 @@ */ #include linux/module.h #include linux/dma-mapping.h +#include linux/platform_device.h #include mmpfb.h static int var_to_pixfmt(struct fb_var_screeninfo *var) -- 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 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
On Friday 15 February 2013, Russell King - ARM Linux wrote: The .text section alone is just short of 32MB. I suspect when it does go over that, we'll see a lot more link time failures due to the 'bl' instructions failing to encode their PC relative jumps. The only solution then will be to switch everything to use the less efficient long jumps (load address from literal pool, bx) which'll also need much of the asm changed. That also brings up the question whether we want to penalize the kernel performance just to make allyesconfig work... I guess we can make it a compile time option, which of course allyesconfig will automatically enable. I suspect we'll see a lot of people mistakenly enabling it too though. I'm not too worried about people accidentally enabling such a build option, at least if it's appropriately labeled as something that nobody should need. Changing the inline assembly however sounds like a big pain to do, which would cause performance and size overhead as well as regressions in rarely executed code when we get it wrong. I've tried rebulding the allyesconfig kernel with -O3 -funroll-all-loops to make it even bigger on purpose, and got these errors: arch/arm/kernel/built-in.o:(.fixup+0x8): relocation truncated to fit: R_ARM_JUMP24 against `.text' arch/arm/kernel/built-in.o:(.fixup+0x10): relocation truncated to fit: R_ARM_JUMP24 against `.text' arch/arm/kernel/built-in.o:(.fixup+0x18): relocation truncated to fit: R_ARM_JUMP24 against `.text' arch/arm/kernel/built-in.o:(.fixup+0x20): relocation truncated to fit: R_ARM_JUMP24 against `.text' arch/arm/kernel/built-in.o:(.fixup+0x28): relocation truncated to fit: R_ARM_JUMP24 against `.text' arch/arm/kernel/built-in.o:(.fixup+0x30): relocation truncated to fit: R_ARM_JUMP24 against `.text' arch/arm/kernel/built-in.o:(.fixup+0x38): relocation truncated to fit: R_ARM_JUMP24 against `.text' arch/arm/kernel/built-in.o:(.fixup+0x40): relocation truncated to fit: R_ARM_JUMP24 against `.text' arch/arm/kernel/built-in.o:(.fixup+0x48): relocation truncated to fit: R_ARM_JUMP24 against `.text' arch/arm/kernel/built-in.o:(.fixup+0x50): relocation truncated to fit: R_ARM_JUMP24 against `.text' arch/arm/kernel/built-in.o:(.fixup+0x58): additional relocation overflows omitted from the output so the .fixup section is completely out of reach of the start of the .text section. The size output for the partial link of vmlinux.o is section size addr .head.text 492 3221258240 .text 43889568 3221258752 .text.head 80 .rodata 11020608 4096 __bug_table 138636 11024704 .pci_fixup 0 11163340 .builtin_fw 684 11163340 .rio_ops 0 11164024 __ksymtab 53424 11164024 __ksymtab_gpl 43560 11217448 __ksymtab_unused 0 11261008 __ksymtab_unused_gpl 0 11261008 __ksymtab_gpl_future 0 11261008 __kcrctab 26712 11261008 __kcrctab_gpl 21780 11287720 __kcrctab_unused 0 11309500 __kcrctab_unused_gpl 0 11309500 __kcrctab_gpl_future 0 11309500 __ksymtab_strings 251888 11309500 __param33104 11561388 __modver1284 11594492 __ex_table 6288 11595776 .ARM.unwind_idx 907888 11602064 .ARM.unwind_tab 1362276 12509952 .notes36 13872228 .init.text685436 13873152 .exit.text124324 14558588 .init.arch.info 5396 14682912 .init.tagtable72 14688308 .init.smpalt 952 14688380 .init.pv_table 2232 14689332 .init.data649164 14691568 .exit.data 120 15340732 .data..percpu1460032 15343616 .data3370676 16809984 .tcm_start 332 20180660 .text_itcm 0 4294836224 .dtcm_start0 20180992 .data_dtcm 0 4294868992 .tcm_end 0 20180992 .bss 8007852 20180992 .comment 3144240 .ARM.attributes 500 .debug_line 191855650 .debug_info 617576490 .debug_abbrev58354570 .debug_aranges2994160 .debug_ranges 104820640 .debug_frame 46017680 .debug_str 374337320 .debug_loc 455782060 Total 257553155 I had the idea that turning off THUMB2 support in allyesconfig would help, but then I found that it's already disabled
Re: linux-next: build warning after merge of the char-misc tree
On Friday 15 February 2013, Greg KH wrote: On Fri, Feb 15, 2013 at 04:26:57PM +1100, Stephen Rothwell wrote: Hi all, After merging the char-misc tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/w1/slaves/w1_therm.c: In function 'w1_therm_read': drivers/w1/slaves/w1_therm.c:245:15: warning: 'crc' may be used uninitialized in this function [-Wuninitialized] Its a false positive, but it was introduced by commit 867ff9880d5d (w1_therm: Retries: remove old code add CRC) I don't see that here with gcc 4.7.1, perhaps you need to upgrade your version of gcc to not show these false positives? I see the same warning with gcc-4.6.3, 4.7.2 and 4.8.0-20130114 on ARM. In case of 4.8, the output is drivers/w1/slaves/w1_therm.c: In function 'w1_therm_read': drivers/w1/slaves/w1_therm.c:245:15: warning: 'crc' may be used uninitialized in this function [-Wmaybe-uninitialized] c -= snprintf(buf + PAGE_SIZE - c, c, : crc=%02x %s\n, ^ I actually see much more of these false positives with 4.7 and 4.8 than I get with 4.6, which is the main reason for me to use 4.6 for my daily builds. I agree that this particular false positive is an especially dumb one and it would be good to not just shut up gcc by initializing it, but I have no other idea what to do with the hundreds of such warnings I 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/
[PATCH 2/4] dmaengine: dw_dmac: move to generic DMA binding
The original device tree binding for this driver, from Viresh Kumar
unfortunately conflicted with the generic DMA binding, and did not allow
to completely seperate slave device configuration from the controller.
This is an attempt to replace it with an implementation of the generic
binding, but it is currently completely untested, because I do not have
any hardware with this particular controller.
The patch applies on top of linux-next, which contains both the base
support for the generic DMA binding, as well as the earlier attempt from
Viresh. Both of these are currently not merged upstream however.
There are a couple of TODO items that are left remaining and are open
for ideas from other people.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Vinod Koul vinod.k...@linux.intel.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
Documentation/devicetree/bindings/dma/snps-dma.txt | 70 ++-
drivers/dma/dw_dmac.c | 137 ++---
drivers/dma/dw_dmac_regs.h | 8 +-
include/linux/dw_dmac.h| 5 -
4 files changed, 104 insertions(+), 116 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt
b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 5bb3dfb..68783d3 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -3,59 +3,61 @@
Required properties:
- compatible: snps,dma-spear1340
- reg: Address range of the DMAC registers
-- interrupt-parent: Should be the phandle for the interrupt controller
- that services interrupts for this device
- interrupt: Should contain the DMAC interrupt number
-- nr_channels: Number of channels supported by hardware
-- is_private: The device channels should be marked as private and not for by
the
- general purpose DMA channel allocator. False if not passed.
+- dma-channels: Number of channels supported by hardware
+- dma-requests: Number of DMA request lines supported, up to 16
+- dma-masters: Number of AHB masters supported by the controller
+- #dma-cells: must be 3
- chan_allocation_order: order of allocation of channel, 0 (default):
ascending,
1: descending
- chan_priority: priority of channels. 0 (default): increase from chan 0-n, 1:
increase from chan n-0
- block_size: Maximum block size supported by the controller
-- nr_masters: Number of AHB masters supported by the controller
- data_width: Maximum data width supported by hardware per AHB master
(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
-- slave_info:
- - bus_id: name of this device channel, not just a device name since
- devices may have more than one channel e.g. foo_tx. For using the
- dw_generic_filter(), slave drivers must pass exactly this string as
- param to filter function.
- - cfg_hi: Platform-specific initializer for the CFG_HI register
- - cfg_lo: Platform-specific initializer for the CFG_LO register
- - src_master: src master for transfers on allocated channel.
- - dst_master: dest master for transfers on allocated channel.
+
+
+Optional properties:
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- is_private: The device channels should be marked as private and not for by
the
+ general purpose DMA channel allocator. False if not passed.
Example:
- dma@fc00 {
+ dmahost: dma@fc00 {
compatible = snps,dma-spear1340;
reg = 0xfc00 0x1000;
interrupt-parent = vic1;
interrupts = 12;
- nr_channels = 8;
+ dma-channels = 8;
+ dma-requests = 16;
+ dma-masters = 2;
+ #dma-cells = 3;
chan_allocation_order = 1;
chan_priority = 1;
block_size = 0xfff;
- nr_masters = 2;
data_width = 3 3 0 0;
+ };
- slave_info {
- uart0-tx {
- bus_id = uart0-tx;
- cfg_hi = 0x4000; /* 0x8 11 */
- cfg_lo = 0;
- src_master = 0;
- dst_master = 1;
- };
- spi0-tx {
- bus_id = spi0-tx;
- cfg_hi = 0x2000; /* 0x4 11 */
- cfg_lo = 0;
- src_master = 0;
- dst_master = 0;
- };
- };
+DMA clients connected to the Designware DMA controller must use the format
+described in the dma.txt file, using a five-cell specifier
[PATCH 3/4] spi: pl022: use generic DMA slave configuration if possible
With the new OF DMA binding, it is possible to completely avoid the
need for platform_data for configuring a DMA channel. In cases where the
platform has already been converted, calling dma_request_slave_channel
should get all the necessary information from the device tree.
Like the patch that converts the dw_dma controller, this is completely
untested and is looking for someone to try it out.
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Vinod Koul vinod.k...@linux.intel.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
.../devicetree/bindings/spi/spi_pl022.txt | 36 ++
drivers/spi/spi-pl022.c| 43 +-
2 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/spi_pl022.txt
b/Documentation/devicetree/bindings/spi/spi_pl022.txt
index f158fd3..22ed679 100644
--- a/Documentation/devicetree/bindings/spi/spi_pl022.txt
+++ b/Documentation/devicetree/bindings/spi/spi_pl022.txt
@@ -16,6 +16,11 @@ Optional properties:
device will be suspended immediately
- pl022,rt : indicates the controller should run the message pump with realtime
priority to minimise the transfer latency on the bus (boolean)
+- dmas : Two or more DMA channel specifiers following the convention outlined
+ in bindings/dma/dma.txt
+- dma-names: Names for the dma channels, if present. There must be at
+least one channel named tx for transmit and named rx for
+ receive.
SPI slave nodes must be children of the SPI master node and can
@@ -32,3 +37,34 @@ contain the following properties.
- pl022,wait-state : Microwire interface: Wait state
- pl022,duplex : Microwire interface: Full/Half duplex
+
+Example:
+
+ spi@e010 {
+ compatible = arm,pl022, arm,primecell;
+ reg = 0xe010 0x1000;
+ #address-cells = 1;
+ #size-cells = 0;
+ interrupts = 0 31 0x4;
+ dmas = dma-controller 23 1,
+ dma-controller 24 0;
+ dma-names = rx, tx;
+
+ m25p80@1 {
+ compatible = st,m25p80;
+ reg = 1;
+ spi-max-frequency = 1200;
+ spi-cpol;
+ spi-cpha;
+ pl022,hierarchy = 0;
+ pl022,interface = 0;
+ pl022,slave-tx-disable;
+ pl022,com-mode = 0x2;
+ pl022,rx-level-trig = 0;
+ pl022,tx-level-trig = 0;
+ pl022,ctrl-len = 0x11;
+ pl022,wait-state = 0;
+ pl022,duplex = 0;
+ };
+ };
+
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index b0fe393..371cc66f 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -1139,6 +1139,35 @@ err_no_rxchan:
return -ENODEV;
}
+static int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+ struct device *dev = pl022-adev-dev;
+
+ /* automatically configure DMA channels from platform, normally using
DT */
+ pl022-dma_rx_channel = dma_request_slave_channel(dev, rx);
+ if (!pl022-dma_rx_channel)
+ goto err_no_rxchan;
+
+ pl022-dma_tx_channel = dma_request_slave_channel(dev, tx);
+ if (!pl022-dma_tx_channel)
+ goto err_no_txchan;
+
+ pl022-dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!pl022-dummypage)
+ goto err_no_dummypage;
+
+ return 0;
+
+err_no_dummypage:
+ dma_release_channel(pl022-dma_tx_channel);
+ pl022-dma_tx_channel = NULL;
+err_no_txchan:
+ dma_release_channel(pl022-dma_rx_channel);
+ pl022-dma_rx_channel = NULL;
+err_no_rxchan:
+ return -ENODEV;
+}
+
static void terminate_dma(struct pl022 *pl022)
{
struct dma_chan *rxchan = pl022-dma_rx_channel;
@@ -1167,6 +1196,11 @@ static inline int configure_dma(struct pl022 *pl022)
return -ENODEV;
}
+static inline int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+ return 0;
+}
+
static inline int pl022_dma_probe(struct pl022 *pl022)
{
return 0;
@@ -2226,8 +2260,13 @@ static int pl022_probe(struct amba_device *adev, const
struct amba_id *id)
goto err_no_irq;
}
- /* Get DMA channels */
- if (platform_info-enable_dma) {
+ /* Get DMA channels, try autoconfiguration first */
+ status = pl022_dma_autoprobe(pl022);
+
+ /* If that failed
[PATCH 0/4] dw_dmac: introduce generic DMA binding for DT
Hi Vinod, As Andy pointed out today, we don't have a good solution for the dw_dmac DT binding in linux-next yet. I have posted my series once before and then got distracted after getting feedback from Viresh, Andy and Russell. I have now updated my earlier patch based on the feedback and rebased on your tree without any of the arm-soc patches mixed in. Unfortunately the patches have never been tested on real hardware so I don't think it's a good idea to use them in v3.9 on the spear platform. However, your dma-slave tree still contains Viresh's earlier patches, causing a few problems: * With those patches, the spear3xx platform currently does not build. (this one would be easy to fix though) * There is a conflict between those patches and my spear multiplatform series, which I have not yet queued up for 3.9 because of this, since that would have meant that Stephen Rothwell would have to discard either the arm-soc tree or the dma-slave tree from linux-next. * I really don't want the broken binding to appear in 3.9. I believe the best way out at this point is this series, which first first reverts the patch f9965aa2 ARM: SPEAr13xx: Pass DW DMAC platform data from DT from your tree and then adds my update. This will give us the right DT binding for dw-dmac but no in-tree users, which means that nothing should break if I get it slightly wrong. Please apply the first two patches from these set, and optionally the two patches that based on this convert the pl011 uart and pl022 spi controller drivers. I can then decide with Olof whether or not to take the spear multiplatform changes that no longer conflict with the dma slave tree as a late branch into 3.9 or wait until 3.10, but that is something you don't need to worry about then. Also the conversion of spear to use the new binding (patch 5 of my original series) can go through the arm-soc tree for 3.10 after the ST folks have tested that it works. Arnd Arnd Bergmann (4): Revert ARM: SPEAr13xx: Pass DW DMAC platform data from DT dmaengine: dw_dmac: move to generic DMA binding spi: pl022: use generic DMA slave configuration if possible serial: pl011: use generic DMA slave configuration if possible .../devicetree/bindings/arm/primecell.txt | 19 ++- Documentation/devicetree/bindings/dma/snps-dma.txt | 70 ++- Documentation/devicetree/bindings/serial/pl011.txt | 17 +++ .../devicetree/bindings/spi/spi_pl022.txt | 36 ++ arch/arm/boot/dts/spear1340.dtsi | 19 --- arch/arm/boot/dts/spear13xx.dtsi | 38 -- arch/arm/mach-spear13xx/include/mach/spear.h | 2 + arch/arm/mach-spear13xx/spear1310.c| 5 +- arch/arm/mach-spear13xx/spear1340.c| 33 +++-- arch/arm/mach-spear13xx/spear13xx.c| 55 - drivers/dma/dw_dmac.c | 137 ++--- drivers/dma/dw_dmac_regs.h | 8 +- drivers/spi/spi-pl022.c| 43 ++- drivers/tty/serial/amba-pl011.c| 62 ++ include/linux/dw_dmac.h| 5 - 15 files changed, 333 insertions(+), 216 deletions(-) create mode 100644 Documentation/devicetree/bindings/serial/pl011.txt -- 1.8.1.2 -- 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/
[PATCH 1/4] Revert ARM: SPEAr13xx: Pass DW DMAC platform data from DT
This reverts commit f9965aa20706860077cfa093d04a6351c0c1e940.
---
arch/arm/boot/dts/spear1340.dtsi | 19 --
arch/arm/boot/dts/spear13xx.dtsi | 38 ---
arch/arm/mach-spear13xx/include/mach/spear.h | 2 +
arch/arm/mach-spear13xx/spear1310.c | 5 ++-
arch/arm/mach-spear13xx/spear1340.c | 33 -
arch/arm/mach-spear13xx/spear13xx.c | 55 ++--
6 files changed, 80 insertions(+), 72 deletions(-)
diff --git a/arch/arm/boot/dts/spear1340.dtsi b/arch/arm/boot/dts/spear1340.dtsi
index b2d41b7..34da11a 100644
--- a/arch/arm/boot/dts/spear1340.dtsi
+++ b/arch/arm/boot/dts/spear1340.dtsi
@@ -88,25 +88,6 @@
status = disabled;
};
- dma@ea80 {
- slave_info {
- uart1_tx {
- bus_id = uart1_tx;
- cfg_hi = 0x6000; /* 0xC 11 */
- cfg_lo = 0;
- src_master = 0;
- dst_master = 1;
- };
- uart1_tx {
- bus_id = uart1_tx;
- cfg_hi = 0x680; /* 0xD 7 */
- cfg_lo = 0;
- src_master = 1;
- dst_master = 0;
- };
- };
- };
-
spi1: spi@5d40 {
compatible = arm,pl022, arm,primecell;
reg = 0x5d40 0x1000;
diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
index 585f641..b4ca60f 100644
--- a/arch/arm/boot/dts/spear13xx.dtsi
+++ b/arch/arm/boot/dts/spear13xx.dtsi
@@ -105,37 +105,6 @@
reg = 0xea80 0x1000;
interrupts = 0 19 0x4;
status = disabled;
-
- nr_channels = 8;
- chan_allocation_order = 1;
- chan_priority = 1;
- block_size = 0xfff;
- nr_masters = 2;
- data_width = 3 3 0 0;
-
- slave_info {
- ssp0_tx {
- bus_id = ssp0_tx;
- cfg_hi = 0x2000; /* 0x4 11 */
- cfg_lo = 0;
- src_master = 0;
- dst_master = 0;
- };
- ssp0_rx {
- bus_id = ssp0_rx;
- cfg_hi = 0x280; /* 0x5 7 */
- cfg_lo = 0;
- src_master = 0;
- dst_master = 0;
- };
- cf {
- bus_id = cf;
- cfg_hi = 0;
- cfg_lo = 0;
- src_master = 0;
- dst_master = 0;
- };
- };
};
dma@eb00 {
@@ -143,13 +112,6 @@
reg = 0xeb00 0x1000;
interrupts = 0 59 0x4;
status = disabled;
-
- nr_channels = 8;
- chan_allocation_order = 1;
- chan_priority = 1;
- block_size = 0xfff;
- nr_masters = 2;
- data_width = 3 3 0 0;
};
fsmc: flash@b000 {
diff --git a/arch/arm/mach-spear13xx/include/mach/spear.h
b/arch/arm/mach-spear13xx/include/mach/spear.h
index 972a151..7cfa681 100644
--- a/arch/arm/mach-spear13xx/include/mach/spear.h
+++ b/arch/arm/mach-spear13xx/include/mach/spear.h
@@ -43,6 +43,8 @@
#define VA_L2CC_BASE IOMEM(UL(0xFB00))
/* others */
+#define DMAC0_BASE UL(0xEA80)
+#define DMAC1_BASE UL(0xEB00)
#define MCIF_CF_BASE UL(0xB280)
/* Debug uart for linux, will be used for debug and uncompress messages */
diff --git a/arch/arm/mach-spear13xx/spear1310.c
b/arch/arm/mach-spear13xx/spear1310.c
index ec72c47..02f4724 100644
--- a/arch/arm/mach-spear13xx/spear1310.c
+++ b/arch/arm/mach-spear13xx/spear1310.c
@@ -36,7 +36,7 @@
static struct arasan_cf_pdata cf_pdata = {
[PATCH 4/4] serial: pl011: use generic DMA slave configuration if possible
With the new OF DMA binding, it is possible to completely avoid the
need for platform_data for configuring a DMA channel. In cases where the
platform has already been converted, calling dma_request_slave_channel
should get all the necessary information from the device tree.
This also adds a binding document specific to the pl011 controller,
and extends the generic primecell binding to mention dmas and other
common properties.
Like the patch that converts the dw_dma controller, this is completely
untested and is looking for someone to try it out.
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Jiri Slaby jsl...@suse.cz
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
.../devicetree/bindings/arm/primecell.txt | 19 ++-
Documentation/devicetree/bindings/serial/pl011.txt | 17 ++
drivers/tty/serial/amba-pl011.c| 62 +-
3 files changed, 72 insertions(+), 26 deletions(-)
create mode 100644 Documentation/devicetree/bindings/serial/pl011.txt
diff --git a/Documentation/devicetree/bindings/arm/primecell.txt
b/Documentation/devicetree/bindings/arm/primecell.txt
index 64fc82b..0df6aca 100644
--- a/Documentation/devicetree/bindings/arm/primecell.txt
+++ b/Documentation/devicetree/bindings/arm/primecell.txt
@@ -16,14 +16,31 @@ Optional properties:
- clocks : From common clock binding. First clock is phandle to clock for apb
pclk. Additional clocks are optional and specific to those peripherals.
- clock-names : From common clock binding. Shall be apb_pclk for first clock.
+- dmas : From common DMA binding. If present, refers to one or more dma
channels.
+- dma-names : From common DMA binding, needs to match the 'dmas' property.
+ Devices with exactly one receive and transmit channel shall name
+ these rx and tx, respectively.
+- pinctrl-n : Pinctrl states as described in
bindings/pinctrl/pinctrl-bindings.txt
+- pinctrl-names : Names corresponding to the numbered pinctrl states
+- interrupts : one or more interrupt specifiers
+- interrupt-names : names corresponding to the interrupts properties
Example:
serial@fff36000 {
compatible = arm,pl011, arm,primecell;
arm,primecell-periphid = 0x00341011;
+
clocks = pclk;
clock-names = apb_pclk;
-
+
+ dmas = dma-controller 4, dma-controller 5;
+ dma-names = rx, tx;
+
+ pinctrl-0 = uart0_default_mux, uart0_default_mode;
+ pinctrl-1 = uart0_sleep_mode;
+ pinctrl-names = default,sleep;
+
+ interrupts = 0 11 0x4;
};
diff --git a/Documentation/devicetree/bindings/serial/pl011.txt
b/Documentation/devicetree/bindings/serial/pl011.txt
new file mode 100644
index 000..5d2e840
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/pl011.txt
@@ -0,0 +1,17 @@
+* ARM AMBA Primecell PL011 serial UART
+
+Required properties:
+- compatible: must be arm,primecell, arm,pl011
+- reg: exactly one register range with length 0x1000
+- interrupts: exactly one interrupt specifier
+
+Optional properties:
+- pinctrl: When present, must have one state named sleep
+ and one state named default
+- clocks: When present, must refer to exactly one clock named
+ apb_pclk
+- dmas: When present, may have one or two dma channels.
+ The first one must be named rx, the second one
+ must be named tx.
+
+See also bindings/arm/primecell.txt
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7fca402..f9af04d 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -245,7 +245,7 @@ static void pl011_sgbuf_free(struct dma_chan *chan, struct
pl011_sgbuf *sg,
}
}
-static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
+static void pl011_dma_probe_initcall(struct device *dev, struct uart_amba_port
*uap)
{
/* DMA is the sole user of the platform data right now */
struct amba_pl011_data *plat = uap-port.dev-platform_data;
@@ -259,20 +259,25 @@ static void pl011_dma_probe_initcall(struct
uart_amba_port *uap)
struct dma_chan *chan;
dma_cap_mask_t mask;
- /* We need platform data */
- if (!plat || !plat-dma_filter) {
- dev_info(uap-port.dev, no DMA platform data\n);
- return;
- }
+ chan = dma_request_slave_channel(dev, tx);
- /* Try to acquire a generic DMA engine slave TX channel */
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
-
- chan = dma_request_channel(mask, plat-dma_filter, plat-dma_tx_param);
if (!chan) {
- dev_err(uap-port.dev, no TX DMA channel!\n);
- return;
+ /* We need platform data
Re: [PATCH 1/9] ARM: arch_timer: include linux/errno.h
On Friday 15 February 2013, Mark Rutland wrote: As with Stephen Warren's fix [1], this looks right to me. Stephen's has the added benefit of keeping the includes ordered. For either version: Acked-By: Mark Rutland mark.rutl...@arm.com Applied to the next/virt branch now. 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: linux-next: build warning after merge of the char-misc tree
On Friday 15 February 2013, Greg KH wrote: On Fri, Feb 15, 2013 at 04:26:57PM +1100, Stephen Rothwell wrote: After merging the char-misc tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/w1/slaves/w1_therm.c: In function 'w1_therm_read': drivers/w1/slaves/w1_therm.c:245:15: warning: 'crc' may be used uninitialized in this function [-Wuninitialized] Its a false positive, but it was introduced by commit 867ff9880d5d (w1_therm: Retries: remove old code add CRC) I don't see that here with gcc 4.7.1, perhaps you need to upgrade your version of gcc to not show these false positives? I have finally put the pieces of the puzzle together. I already knew that some of these warnings only happen when building with -Os (even in gcc-4.8), since gcc turns off the inlining at a point after it determines that the variable might be used uninitialized but before determining that it's actually isn't. I think the best way forward is to disable this particular warning when building with -Os (which is enabled in allyesconfig). A false positive seems more harmful than a false negative here, because it prompts people to add broken initializations. This patch indeed makes the majority of the allyesconfig warnings on ARM go away. For the regular defconfig builds, we are already mostly clean, and those are built with -O2. Signed-off-by: Arnd Bergmann a...@arndb.de diff --git a/Makefile b/Makefile index 0b4bf62..4d60d97 100644 --- a/Makefile +++ b/Makefile @@ -570,7 +570,7 @@ endif # $(dot-config) all: vmlinux ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE -KBUILD_CFLAGS += -Os +KBUILD_CFLAGS += -Os $(call cc-option,-Wno-maybe-uninitialized,) else KBUILD_CFLAGS += -O2 endif -- 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 v6 3/3] ARM: mm: use static_vm for managing static mapped areas
On Wednesday 06 February 2013, Joonsoo Kim wrote:
@@ -859,17 +864,12 @@ static void __init pci_reserve_io(void)
{
struct vm_struct *vm;
unsigned long addr;
+ struct static_vm *svm;
- /* we're still single threaded hence no lock needed here */
- for (vm = vmlist; vm; vm = vm-next) {
- if (!(vm-flags VM_ARM_STATIC_MAPPING))
- continue;
- addr = (unsigned long)vm-addr;
- addr = ~(SZ_2M - 1);
- if (addr == PCI_IO_VIRT_BASE)
- return;
+ svm = find_static_vm_vaddr((void *)PCI_IO_VIRT_BASE);
+ if (svm)
+ return;
- }
This is causing build warnings in a bunch of configurations now,
see patch below.
Arnd
8-
ARM: mm: remove unused variables in pci_reserve_io
Patch ARM: 7646/1: mm: use static_vm for managing static mapped areas
removed code from pci_reserve_io but left variable declarations
in place that are now unused, as gcc correctly warns.
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index c6fe15a..c6d45c8 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -901,8 +901,6 @@ static void __init fill_pmd_gaps(void)
#if defined(CONFIG_PCI) !defined(CONFIG_NEED_MACH_IO_H)
static void __init pci_reserve_io(void)
{
- struct vm_struct *vm;
- unsigned long addr;
struct static_vm *svm;
svm = find_static_vm_vaddr((void *)PCI_IO_VIRT_BASE);
--
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 v6 3/3] ARM: mm: use static_vm for managing static mapped areas
On Saturday 16 February 2013, Russell King - ARM Linux wrote: I already have such a patch in my tree - may not have pushed it out as I've been ill (and am still recovering.) Ok, thanks for the quick confirmation! Get well soon, 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 2/4] dmaengine: dw_dmac: move to generic DMA binding
On Saturday 16 February 2013, Russell King - ARM Linux wrote:
On Sat, Feb 16, 2013 at 10:07:39AM +, Arnd Bergmann wrote:
On Saturday 16 February 2013, Viresh Kumar wrote:
On 15 February 2013 23:51, Arnd Bergmann a...@arndb.de wrote:
+static bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
{
+ dws-cfg_hi = 0x;
+ dws-cfg_lo = 0x;
s/0x/-1 ?
It's an 'unsigned int'. While -1 would work here, I always find it a little
odd to rely on that feature of the C language.
However, relying on an 'int' being 32-bits is also rather odd, and
probably much more dubious too. If you want to set all bits in an
int, the portable way to do that is ~0.
Right, I can do that, too. All I really need here though is to make sure
I use the same value in this place and when comparing it in dwc_initialize,
and it needs to be something that cannot be a valid register setting.
Thanks,
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 2/4] dmaengine: dw_dmac: move to generic DMA binding
On Saturday 16 February 2013, Andy Shevchenko wrote:
On Fri, Feb 15, 2013 at 8:21 PM, Arnd Bergmann a...@arndb.de wrote:
@@ -168,7 +169,13 @@ static void dwc_initialize(struct dw_dma_chan *dwc)
if (dwc-initialized == true)
return;
- if (dws) {
+ if (dws dws-cfg_hi == 0x dws-cfg_lo == 0x) {
+ /* autoconfigure based on request line from DT */
+ if (dwc-dma_sconfig.direction == DMA_MEM_TO_DEV)
+ cfghi = DWC_CFGH_DST_PER(dwc-req);
+ else if (dwc-dma_sconfig.direction == DMA_DEV_TO_MEM)
+ cfghi = DWC_CFGH_SRC_PER(dwc-req);
Please, use dwc-direction instead of field in the slave_config. If I
remember correctly it's marked like obsoleted/deprecated.
Ok, that's easy to change. I was copying from the code you added
a few lines below, but was using an older version than the one where
you had made the change to use dwc-direction.
@@ -1179,49 +1186,61 @@ static void dwc_free_chan_resources(struct dma_chan
*chan)
dev_vdbg(chan2dev(chan), %s: done\n, __func__);
}
-bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
+struct dw_dma_filter_args {
+ struct dw_dma *dw;
+ u32 req;
Why this is u32 and not unsigned int?
+ u32 src;
+ u32 dst;
And this could be also just unsigned int.
I was using u32 since I copied the values from a 32 bit
DT property value. I'll change it to unsigned int.
+static bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
{
+ dws-cfg_hi = 0x;
+ dws-cfg_lo = 0x;
Agree with Russell about ~0.
ok.
+static struct dma_chan *dw_dma_xlate(struct of_phandle_args *dma_spec,
+struct of_dma *ofdma)
+{
+ struct dw_dma *dw = ofdma-of_dma_data;
+ struct dw_dma_filter_args fargs = {
+ .dw = dw,
+ };
+ dma_cap_mask_t cap;
+
+ if (dma_spec-args_count != 3)
+ return NULL;
+
+ fargs.req = be32_to_cpup(dma_spec-args+0);
+ fargs.src = be32_to_cpup(dma_spec-args+1);
+ fargs.dst = be32_to_cpup(dma_spec-args+2);
You could cast them to usual C types like unsigned int. I see u32 in
rare cases in the driver like for reading/writting from/to hw and when
API contains it. Here I doubt we have to leave them as u32.
Right.
+ if (WARN_ON(fargs.req = 16 || fargs.src = 2 || fargs.dst = 2))
+ return NULL;
16 here is a magic number for me. I would like to see something like
#define DW_MAX_REQUEST_LINES 16 in the dw_dmac_regs.h.
Ok.
Besides of that, what 2 does come from?
I thought that Viresh had commented that there could only be two masters.
It's probably best to compare against dw-nr_masters here.
@@ -1765,6 +1751,10 @@ static int dw_probe(struct platform_device *pdev)
dma_async_device_register(dw-dma);
+ err = of_dma_controller_register(pdev-dev.of_node, dw_dma_xlate,
dw);
+ if (err)
+ dev_err(pdev-dev, could not register
of_dma_controller\n);
It's not an error, dev_dbg. Consider case when !CONFIG_OF.
Ah right. I expected of_dma_controller_register to return 0 in that case, but
it returns -ENODEV. How about I change this to this?
if (pdev-dev.of_node)
err = of_dma_controller_register(pdev-dev.of_node,
dw_dma_xlate, dw);
if (err err != -ENODEV)
dev_err(pdev-dev, could not register of_dma_controller\n);
That would warn only when we have a dw_dmac device that was registered from
device tree but does not follow the binding or gets an -ENOMEM.
--- a/drivers/dma/dw_dmac_regs.h
+++ b/drivers/dma/dw_dmac_regs.h
@@ -213,6 +213,10 @@ struct dw_dma_chan {
/* configuration passed via DMA_SLAVE_CONFIG */
struct dma_slave_config dma_sconfig;
+ /* slave configuration from DT */
+ unsigned intreq;
Could you use here full name like request_line? And I think the
better place for it in subsection hardware configuration (consider
non-DT cases of use).
Ok
/* backlink to dw_dma */
struct dw_dma *dw;
};
We should not have this in linux-next. Are you sure you rebased it on
top of recent one?
I was basing on the earliest commit that had Viresh's changes in it.
I'll rebase on top of Vinod's branch now.
Thanks for your review!
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/
[PATCHv3 2/4] dmaengine: dw_dmac: move to generic DMA binding
The original device tree binding for this driver, from Viresh Kumar
unfortunately conflicted with the generic DMA binding, and did not allow
to completely seperate slave device configuration from the controller.
This is an attempt to replace it with an implementation of the generic
binding, but it is currently completely untested, because I do not have
any hardware with this particular controller.
The patch applies on top of the slave-dma tree, which contains both the base
support for the generic DMA binding, as well as the earlier attempt from
Viresh. Both of these are currently not merged upstream however.
This version incorporates feedback from Viresh Kumar, Andy Shevchenko
and Russell King.
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked: Viresh Kumar viresh.ku...@linaro.org
Cc: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Vinod Koul vinod.k...@linux.intel.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
Documentation/devicetree/bindings/dma/snps-dma.txt | 70 +-
drivers/dma/dw_dmac.c | 142 ++---
drivers/dma/dw_dmac_regs.h | 11 +-
include/linux/dw_dmac.h| 5 -
4 files changed, 112 insertions(+), 116 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt
b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 5bb3dfb..d58675e 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -3,59 +3,61 @@
Required properties:
- compatible: snps,dma-spear1340
- reg: Address range of the DMAC registers
-- interrupt-parent: Should be the phandle for the interrupt controller
- that services interrupts for this device
- interrupt: Should contain the DMAC interrupt number
-- nr_channels: Number of channels supported by hardware
-- is_private: The device channels should be marked as private and not for by
the
- general purpose DMA channel allocator. False if not passed.
+- dma-channels: Number of channels supported by hardware
+- dma-requests: Number of DMA request lines supported, up to 16
+- dma-masters: Number of AHB masters supported by the controller
+- #dma-cells: must be 3
- chan_allocation_order: order of allocation of channel, 0 (default):
ascending,
1: descending
- chan_priority: priority of channels. 0 (default): increase from chan 0-n, 1:
increase from chan n-0
- block_size: Maximum block size supported by the controller
-- nr_masters: Number of AHB masters supported by the controller
- data_width: Maximum data width supported by hardware per AHB master
(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
-- slave_info:
- - bus_id: name of this device channel, not just a device name since
- devices may have more than one channel e.g. foo_tx. For using the
- dw_generic_filter(), slave drivers must pass exactly this string as
- param to filter function.
- - cfg_hi: Platform-specific initializer for the CFG_HI register
- - cfg_lo: Platform-specific initializer for the CFG_LO register
- - src_master: src master for transfers on allocated channel.
- - dst_master: dest master for transfers on allocated channel.
+
+
+Optional properties:
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- is_private: The device channels should be marked as private and not for by
the
+ general purpose DMA channel allocator. False if not passed.
Example:
- dma@fc00 {
+ dmahost: dma@fc00 {
compatible = snps,dma-spear1340;
reg = 0xfc00 0x1000;
interrupt-parent = vic1;
interrupts = 12;
- nr_channels = 8;
+ dma-channels = 8;
+ dma-requests = 16;
+ dma-masters = 2;
+ #dma-cells = 3;
chan_allocation_order = 1;
chan_priority = 1;
block_size = 0xfff;
- nr_masters = 2;
data_width = 3 3 0 0;
+ };
- slave_info {
- uart0-tx {
- bus_id = uart0-tx;
- cfg_hi = 0x4000; /* 0x8 11 */
- cfg_lo = 0;
- src_master = 0;
- dst_master = 1;
- };
- spi0-tx {
- bus_id = spi0-tx;
- cfg_hi = 0x2000; /* 0x4 11 */
- cfg_lo = 0;
- src_master = 0;
- dst_master = 0;
- };
- };
+DMA clients connected to the Designware DMA controller must use the format
+described in the dma.txt file, using a four-cell specifier
Re: [PATCH 01/11] ARM: disable virt_to_bus/virt_to_bus almost everywhere
On Saturday 16 February 2013, Emilio López wrote: Small nitpick: Please have a look at the patch subject, I suppose you meant something like virt_to_bus/bus_to_virt instead of virt_to_bus/virt_to_bus. Yes, absolutely right, thanks for your attention. The patch is already applied to a stable branch now, so I would prefer not to rebase it though. If there is an important reason to change the applied patches, I will fix this one as well. 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/
[PATCHv4 2/4] dmaengine: dw_dmac: move to generic DMA binding
The original device tree binding for this driver, from Viresh Kumar
unfortunately conflicted with the generic DMA binding, and did not allow
to completely seperate slave device configuration from the controller.
This is an attempt to replace it with an implementation of the generic
binding, but it is currently completely untested, because I do not have
any hardware with this particular controller.
The patch applies on top of the slave-dma tree, which contains both the base
support for the generic DMA binding, as well as the earlier attempt from
Viresh. Both of these are currently not merged upstream however.
This version incorporates feedback from Viresh Kumar, Andy Shevchenko
and Russell King.
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Acked-by: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Vinod Koul vinod.k...@linux.intel.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
Documentation/devicetree/bindings/dma/snps-dma.txt | 70 +-
drivers/dma/dw_dmac.c | 145 ++---
drivers/dma/dw_dmac_regs.h | 7 +-
include/linux/dw_dmac.h| 5 -
4 files changed, 111 insertions(+), 116 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt
b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 5bb3dfb..d58675e 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -3,59 +3,61 @@
Required properties:
- compatible: snps,dma-spear1340
- reg: Address range of the DMAC registers
-- interrupt-parent: Should be the phandle for the interrupt controller
- that services interrupts for this device
- interrupt: Should contain the DMAC interrupt number
-- nr_channels: Number of channels supported by hardware
-- is_private: The device channels should be marked as private and not for by
the
- general purpose DMA channel allocator. False if not passed.
+- dma-channels: Number of channels supported by hardware
+- dma-requests: Number of DMA request lines supported, up to 16
+- dma-masters: Number of AHB masters supported by the controller
+- #dma-cells: must be 3
- chan_allocation_order: order of allocation of channel, 0 (default):
ascending,
1: descending
- chan_priority: priority of channels. 0 (default): increase from chan 0-n, 1:
increase from chan n-0
- block_size: Maximum block size supported by the controller
-- nr_masters: Number of AHB masters supported by the controller
- data_width: Maximum data width supported by hardware per AHB master
(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
-- slave_info:
- - bus_id: name of this device channel, not just a device name since
- devices may have more than one channel e.g. foo_tx. For using the
- dw_generic_filter(), slave drivers must pass exactly this string as
- param to filter function.
- - cfg_hi: Platform-specific initializer for the CFG_HI register
- - cfg_lo: Platform-specific initializer for the CFG_LO register
- - src_master: src master for transfers on allocated channel.
- - dst_master: dest master for transfers on allocated channel.
+
+
+Optional properties:
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- is_private: The device channels should be marked as private and not for by
the
+ general purpose DMA channel allocator. False if not passed.
Example:
- dma@fc00 {
+ dmahost: dma@fc00 {
compatible = snps,dma-spear1340;
reg = 0xfc00 0x1000;
interrupt-parent = vic1;
interrupts = 12;
- nr_channels = 8;
+ dma-channels = 8;
+ dma-requests = 16;
+ dma-masters = 2;
+ #dma-cells = 3;
chan_allocation_order = 1;
chan_priority = 1;
block_size = 0xfff;
- nr_masters = 2;
data_width = 3 3 0 0;
+ };
- slave_info {
- uart0-tx {
- bus_id = uart0-tx;
- cfg_hi = 0x4000; /* 0x8 11 */
- cfg_lo = 0;
- src_master = 0;
- dst_master = 1;
- };
- spi0-tx {
- bus_id = spi0-tx;
- cfg_hi = 0x2000; /* 0x4 11 */
- cfg_lo = 0;
- src_master = 0;
- dst_master = 0;
- };
- };
+DMA clients connected to the Designware DMA controller must use the format
+described in the dma.txt file, using a four-cell
Re: [PATCHv3 2/4] dmaengine: dw_dmac: move to generic DMA binding
On Saturday 16 February 2013, Andy Shevchenko wrote:
@@ -1836,6 +1825,12 @@ static int dw_probe(struct platform_device *pdev)
dma_async_device_register(dw-dma);
+ if (pdev-dev.of_node)
+ err = of_dma_controller_register(pdev-dev.of_node,
+dw_dma_xlate, dw);
+ if (err err != -ENODEV)
+ dev_err(pdev-dev, could not register
of_dma_controller\n);
I believe we may make it as
if (...of_node) {
err = ...register();
if (err...)
dev_err();
}
I thing the two are equivalent because we only get to the first if()
when err is 0. However, I agree that your version is a bit clearer,
so I'll change it.
--- a/drivers/dma/dw_dmac_regs.h
+++ b/drivers/dma/dw_dmac_regs.h
@@ -211,9 +212,15 @@ struct dw_dma_chan {
/* hardware configuration */
unsigned intblock_size;
boolnollp;
+ unsigned intrequest_line;
+ struct dw_dma_slave slave;
+
Do we really need an extra empty line here?
No, that was an accident.
/* configuration passed via DMA_SLAVE_CONFIG */
struct dma_slave_config dma_sconfig;
+
+ /* backlink to dw_dma */
+ struct dw_dma *dw;
Seems it's not needed and came from rebase?
Probably. It certainly was not intentional.
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 02/11] ARM: samsung: fix assembly syntax for new gas
On Saturday 16 February 2013, Russell King - ARM Linux wrote: On Thu, Feb 14, 2013 at 02:49:18PM +0100, Arnd Bergmann wrote: Recent assembler versions complain about extraneous whitespace inside [] brackets. This fixes all of these instances for the samsung platforms. We should backport this to all kernels that might need to be built with new binutils. I hope that's also been reported as a bug to the binutils people. No, I did not think of that. There were a lot of bug reports for similar issues and I assumed that there was a good reason for the change, but I agree that it sounds like a regression, especially since the code that triggers the error should not be ambiguous and there was never a warning about it. 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 02/11] ARM: samsung: fix assembly syntax for new gas
On Sunday 17 February 2013, Aaro Koskinen wrote:
Hi,
On Thu, Feb 14, 2013 at 02:49:18PM +0100, Arnd Bergmann wrote:
Recent assembler versions complain about extraneous
whitespace inside [] brackets. This fixes all of
these instances for the samsung platforms. We should
backport this to all kernels that might need to
be built with new binutils.
Which binutils version is this?
I saw it first on the ubuntu binutils-arm-linux-gnueabihf-2.23.1-
0ubuntu6cross1.89 binaries but have now successfully bisected it to
the below commit that introduced the kernel build breakage in the
upstream binutils-2_23-branch.
The changelog comment is rather unhelpful for determining whether
it was intentional or not, and I can't make any sense out of the
source code.
Arnd
8
commit 65faec7cb829c58b20a5f26ee2908ac35165fc58
Author: Roland McGrath rol...@gnu.org
Date: Tue Nov 20 17:58:28 2012 +
gas/
* config/tc-arm.c (arm_symbol_chars): New variable.
* config/tc-arm.h (tc_symbol_chars): New macro, defined to that.
gas/testsuite/
* gas/arm/macro-pld.s: New file.
* gas/arm/macro-pld.d: New file.
diff --git a/gas/ChangeLog b/gas/ChangeLog
index 8a950ec..f4f834d 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -9,6 +9,11 @@
* config/tc-aarch64.c (first_error_fmt): Add ATTRIBUTE_UNUSED to the
local variable ret.
+2012-11-20 Roland McGrath mcgra...@google.com
+
+ * config/tc-arm.c (arm_symbol_chars): New variable.
+ * config/tc-arm.h (tc_symbol_chars): New macro, defined to that.
+
2012-11-07 James Murray j...@jsm-net.demon.co.uk
* config/tc-m68hc11.c: Fix R_M68HC12_16B relocation for movb/w
diff --git a/gas/config/tc-arm.c b/gas/config/tc-arm.c
index 91b29ac..5bf7d89 100644
--- a/gas/config/tc-arm.c
+++ b/gas/config/tc-arm.c
@@ -321,6 +321,11 @@ static int implicit_it_mode = IMPLICIT_IT_MODE_ARM;
static bfd_boolean unified_syntax = FALSE;
+/* An immediate operand can start with #, and ld*, st*, pld operands
+ can contain [ and ]. We need to tell APP not to elide whitespace
+ before a [, which can appear as the first operand for pld. */
+const char arm_symbol_chars[] = #[];
+
enum neon_el_type
{
NT_invtype,
@@ -10225,7 +10230,7 @@ do_t_branch (void)
}
/* Actually do the work for Thumb state bkpt and hlt. The only difference
- between the two is the maximum immediate allowed - which is passed in
+ between the two is the maximum immediate allowed - which is passed in
RANGE. */
static void
do_t_bkpt_hlt1 (int range)
@@ -14660,7 +14665,7 @@ do_vfp_nsyn_cvtz (void)
}
static void
-do_vfp_nsyn_cvt_fpv8 (enum neon_cvt_flavour flavour,
+do_vfp_nsyn_cvt_fpv8 (enum neon_cvt_flavour flavour,
enum neon_cvt_mode mode)
{
int sz, op;
@@ -14720,9 +14725,9 @@ do_neon_cvt_1 (enum neon_cvt_mode mode)
/* PR11109: Handle round-to-zero for VCVT conversions. */
if (mode == neon_cvt_mode_z
ARM_CPU_HAS_FEATURE (cpu_variant, fpu_arch_vfp_v2)
- (flavour == neon_cvt_flavour_s32_f32
- || flavour == neon_cvt_flavour_u32_f32
- || flavour == neon_cvt_flavour_s32_f64
+ (flavour == neon_cvt_flavour_s32_f32
+ || flavour == neon_cvt_flavour_u32_f32
+ || flavour == neon_cvt_flavour_s32_f64
|| flavour == neon_cvt_flavour_u32_f64)
(rs == NS_FD || rs == NS_FF))
{
diff --git a/gas/config/tc-arm.h b/gas/config/tc-arm.h
index da6469c..3a0fab0 100644
--- a/gas/config/tc-arm.h
+++ b/gas/config/tc-arm.h
@@ -82,6 +82,9 @@ struct fix;
/* We support double slash line-comments for compatibility with the ARM
AArch64 Assembler. */
#define DOUBLESLASH_LINE_COMMENTS
+#define tc_symbol_chars arm_symbol_chars
+extern const char arm_symbol_chars[];
+
#define TC_FORCE_RELOCATION(FIX) arm_force_relocation (FIX)
extern unsigned int arm_frag_max_var (struct frag *);
diff --git a/gas/testsuite/ChangeLog b/gas/testsuite/ChangeLog
index 5bc1c32..09d654e 100644
--- a/gas/testsuite/ChangeLog
+++ b/gas/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2012-11-20 Roland McGrath mcgra...@google.com
+
+ * gas/arm/macro-pld.s: New file.
+ * gas/arm/macro-pld.d: New file.
+
2012-10-09 Nagajyothi Eggone nagajyothi.egg...@amd.com
* gas/i386/i386.exp: Run bdver3 test cases.
diff --git a/gas/testsuite/gas/arm/macro-pld.d
b/gas/testsuite/gas/arm/macro-pld.d
new file mode 100644
index 000..8f9d86c8
--- /dev/null
+++ b/gas/testsuite/gas/arm/macro-pld.d
@@ -0,0 +1,8 @@
+#objdump: -dr
+
+.*: file format .*
+
+Disassembly of section \.text:
+
+0+ .*:
+\s*0:\s+f5d0f000\s+pld\s+\[r0\]
diff --git a/gas/testsuite/gas/arm/macro-pld.s
b/gas/testsuite/gas/arm/macro-pld.s
new file mode 100644
index 000..cf4df8b
--- /dev/null
+++ b/gas/testsuite/gas/arm/macro-pld.s
@@ -0,0 +1,4 @@
+.macro foo arg, rest:vararg
+ \rest
+.endm
+ foo r0, pld [r0]
--
To unsubscribe from this list: send the line unsubscribe
Re: [PATCH 02/11] ARM: samsung: fix assembly syntax for new gas
On Sunday 17 February 2013, Mikael Pettersson wrote: Russell King - ARM Linux writes: On Thu, Feb 14, 2013 at 02:49:18PM +0100, Arnd Bergmann wrote: Recent assembler versions complain about extraneous whitespace inside [] brackets. This fixes all of these instances for the samsung platforms. We should backport this to all kernels that might need to be built with new binutils. I hope that's also been reported as a bug to the binutils people. See PR gas/14887, a post binutils-2.23.1 regression which seems to be fixed on trunk but not on 2.23 branch. Ok, thanks for the info, I just came to the same conclusion a few minutes before your reply. Since I have some binutils people listening now, maybe someone can comment on the issue I tried working around in https://patchwork.kernel.org/patch/2013211/ 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: [V2 2/8] USB: EHCI: make ehci-atmel a separate driver
On Monday 18 February 2013, Bo Shen wrote: - .name = atmel-ehci, + .name = hcd_name, This change will cause atmel ehci won't work with the none device tree kernel. it can be fixed with replace other places using atmel-ehci with hcd_name, that means replace atmel-ehci with ehci-atmel at other places. Ah, that is right. Thanks for pointing it out! Manjunath, please revert this change and ensure you are not changing the contents of the 'platform_driver-name' field in any of the drivers. 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 v3] mfd: syscon: Add non-DT support
On Monday 18 February 2013, Alexander Shiyan wrote:
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index 4a7ed5a..3c0abcb 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
Hi Alexander,
struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
{
struct device_node *syscon_np;
struct regmap *regmap;
+ struct syscon *syscon;
+ struct device *dev;
syscon_np = of_find_compatible_node(NULL, NULL, s);
- if (!syscon_np)
+ if (syscon_np) {
+ regmap = syscon_node_to_regmap(syscon_np);
+ of_node_put(syscon_np);
+
+ return regmap;
+ }
+
+ /* Fallback to search by id_entry.name string */
+ dev = driver_find_device(syscon_driver.driver, NULL, (void *)s,
+ syscon_match_id);
+ if (!dev)
return ERR_PTR(-ENODEV);
- regmap = syscon_node_to_regmap(syscon_np);
- of_node_put(syscon_np);
+ syscon = dev_get_drvdata(dev);
- return regmap;
+ return syscon-regmap;
}
EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
Since you are not actually comparing the compatible property here,
I would suggest adding another function here, something like
syscon_regmap_lookup_by_pdevname() that you can use in device
drivers that are not DT-enabled. I would also recommend enclosing
that function in #ifdef CONFIG_ATAGS.
Which code do you have in mind that would call this anyway?
The changeset description does not really explain what ATAG
boot support in syscon is good for.
+ if (IS_ENABLED(CONFIG_OF) np) {
+ syscon-base = of_iomap(np, 0);
+ if (!syscon-base)
+ return -EADDRNOTAVAIL;
+
+ res = res_of;
+ ret = of_address_to_resource(np, 0, res);
+ if (ret) {
+ iounmap(syscon-base);
+ return ret;
+ }
+ } else {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENOENT;
+
+ if (!devm_request_mem_region(dev, res-start,
+ resource_size(res),
+ dev_name(pdev-dev)))
+ return -EBUSY;
+
+ syscon-base = ioremap(res-start, resource_size(res));
+ if (!syscon-base)
+ return -EADDRNOTAVAIL;
+ }
These two code paths look equivalent. Why not always use the second
one? Also, you might want to convert this to devm_ioremap_resource()
to simplify the code in the process.
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/
