[PATCH 2/3] perf tests: Omit end of the symbol check failure for test 1
Omitting end of the function check failure for test 1,
since there's no way to get exact symbol end via kallsyms.
Leaving the debug message.
Signed-off-by: Jiri Olsa jo...@redhat.com
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Arnaldo Carvalho de Melo a...@redhat.com
Cc: Andi Kleen a...@linux.intel.com
Cc: David Ahern dsah...@gmail.com
---
tools/perf/tests/vmlinux-kallsyms.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/perf/tests/vmlinux-kallsyms.c
b/tools/perf/tests/vmlinux-kallsyms.c
index 7b4c4d2..add1539 100644
--- a/tools/perf/tests/vmlinux-kallsyms.c
+++ b/tools/perf/tests/vmlinux-kallsyms.c
@@ -139,11 +139,18 @@ next_pair:
* _really_ have a problem.
*/
s64 skew = sym-end - pair-end;
- if (llabs(skew) page_size)
- continue;
+ if (llabs(skew) = page_size)
+ pr_debug(%# PRIx64 : diff end addr
for %s v: %# PRIx64 k: %# PRIx64 \n,
+sym-start, sym-name,
sym-end, pair-end);
+
+ /*
+* Do not count this as a failure, because we
+* could really find a case where it's not
+* possible to get proper function end from
+* kallsyms.
+*/
+ continue;
- pr_debug(%# PRIx64 : diff end addr for %s v:
%# PRIx64 k: %# PRIx64 \n,
-sym-start, sym-name, sym-end,
pair-end);
} else {
struct rb_node *nnd;
detour:
--
1.7.11.7
--
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: NULL pointer dereference when loading the gre module (3.10.0-rc4)
On Fri, 2013-06-07 at 10:54 +0200, Steinar H. Gunderson wrote: On Thu, Jun 06, 2013 at 11:06:48PM -0400, Steven Rostedt wrote: Note the faulting address is 0xa0e52001, which is around the above address, be interesting to know what was at that location. Doh, I looked at the wrong place in kallsyms: a0e52000 u ip_tunnel_init_net [ip_gre] a0e55000 t gre_err [gre] a0e5503d t gre_gso_send_check [gre] a0e55053 t gre_rcv [gre] So it's really ip_tunnel_init_net+1. /* Steinar */ u for ip_tunnel_init_net ? Looks like someone forgot taking refcounts on a module ... CC Pravin B Shelar, as this probably comes from commit c54419321455631079c7d6e60bc732dd0c5914c5 (GRE: Refactor GRE tunneling code.) -- 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] USB: serial/ftdi_sio.c Fix kernel oops
On Fri, Jun 07, 2013 at 03:14:32PM +0200, Lotfi Manseur wrote: Handle null termios in ftdi_set_termios(), introduced in commit 552f6bf1bb0eda0011c0525dd587aa9e7ba5b846 This has been corrected in the mainline by commits c515598e0f5769916c31c00392cc2bfe6af74e55 and a816e3113b63753c330ca4751ea1d208e93e3015. This is to be fixed in longterm 2.6.32.60 and 3.4.47. This bug has been found with coccinelle. Thank you Lofti, I have queued it now. Best regards, Willy -- 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 16/16] perf, persistent: Allow multiple users for an event
On 04.06.13 11:35:22, Borislav Petkov wrote:
On Tue, Jun 04, 2013 at 11:19:21AM +0200, Jiri Olsa wrote:
'cpu' did not pass ay check here..
Oh, I see.
You mean something like
if (cpu NR_CPUS cpu_online(cpu))
In perf_event_alloc() there is:
if ((unsigned)cpu = nr_cpu_ids) {
if (!task || cpu != -1)
return ERR_PTR(-EINVAL);
}
So this should be sufficient:
if ((unsigned)cpu = nr_cpu_ids)
...
-Robert
--
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: Scaling problem with a lot of AF_PACKET sockets on different interfaces
On Fri, 2013-06-07 at 14:30 +0100, David Laight wrote: Looks like the ptype_base[] should be per 'dev'? Or just put entries where ptype-dev != null_or_dev on a per-interface list and do two searches? Yes, but then we would have two searches instead of one in fast path. ptype_base[] is currently 16 slots, 256 bytes on x86_64. Presumably the per device list could be a single list, instead of a hash table, but still... If the application creating hundred or thousand of AF_PACKET sockets is a single process, I really question why using a single AF_PACKET was not chosen. We now have a FANOUT capability on AF_PACKET, so that its scalable to million of packets per second. I would rather try this way before adding yet another section in __netif_receive_skb() -- 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] USB: serial/ftdi_sio.c Fix kernel oops
Hello. On 06/07/2013 05:14 PM, Lotfi Manseur wrote: Handle null termios in ftdi_set_termios(), introduced in commit 552f6bf1bb0eda0011c0525dd587aa9e7ba5b846 This has been corrected in the mainline by commits c515598e0f5769916c31c00392cc2bfe6af74e55 and a816e3113b63753c330ca4751ea1d208e93e3015. You should also give the summary lines of all mentioned commits in parens. This is to be fixed in longterm 2.6.32.60 and 3.4.47. This bug has been found with coccinelle. Signed-off-by: Lotfi Manseur lotfi.mans...@imag.fr Signed-off-by: Nicolas Palix nicolas.pa...@imag.fr WBR, Sergei -- 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: [ 027/184] ring-buffer: Fix race between integrity check and
On Tue, 2013-06-04 at 19:21 +0200, Willy Tarreau wrote: 2.6.32-longterm review patch. If anyone has any objections, please let me know. -- readers From: Steven Rostedt srost...@redhat.com commit 9366c1ba13fbc41bdb57702e75ca4382f209c82f upstream. This isn't the right commit (thanks to Ben for bringing this to my attention). That this commit SHA1 matches the change log but not the change. According to git blame, the change below is from: 54f7be5b831254199522523ccab4c3d954bbf576 ring-buffer: Fix NULL pointer if rb_set_head_page() fails -- Steve The function rb_check_pages() was added to make sure the ring buffer's pages were sane. This check is done when the ring buffer size is modified as well as when the iterator is released (closing the trace file), as that was considered a non fast path and a good place to do a sanity check. The problem is that the check does not have any locks around it. If one process were to read the trace file, and another were to read the raw binary file, the check could happen while the reader is reading the file. The issues with this is that the check requires to clear the HEAD page before doing the full check and it restores it afterward. But readers require the HEAD page to exist before it can read the buffer, otherwise it gives a nasty warning and disables the buffer. By adding the reader lock around the check, this keeps the race from happening. Signed-off-by: Steven Rostedt rost...@goodmis.org Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Signed-off-by: Willy Tarreau w...@1wt.eu --- kernel/trace/ring_buffer.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index e749a05..6024960 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -2876,6 +2876,8 @@ rb_get_reader_page(struct ring_buffer_per_cpu *cpu_buffer) * Splice the empty reader page into the list around the head. */ reader = rb_set_head_page(cpu_buffer); + if (!reader) + goto out; cpu_buffer-reader_page-list.next = reader-list.next; cpu_buffer-reader_page-list.prev = reader-list.prev; -- 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: Scaling problem with a lot of AF_PACKET sockets on different interfaces
Looks like the ptype_base[] should be per 'dev'? Or just put entries where ptype-dev != null_or_dev on a per-interface list and do two searches? Yes, but then we would have two searches instead of one in fast path. Usually it would be empty - so the search would be very quick! David
Re: slub: slab order on multi-processor machines
On Fri, 7 Jun 2013, Roman Gushchin wrote: As I understand, the idea was to make kernel allocations cheaper by reducing the total number of page allocations (allocating 1 page with order 3 is cheaper than allocating 8 1-ordered pages). Its also affecting allocator speed. By having less page structures to manage the metadata effort is reduced. By having more objects in a page the fastpath of slub is more likely to be used (Visible in allocator benchmarks). Slub can fall back dynamically to order 0 pages if necessary. So it can take opportunistically take advantage of contiguous pages. I'm sure, it's true for recently rebooted machine with a lot of free non-fragmented memory. But is it also true for heavy-loaded machine with fragmented memory? Are we sure, that it's cheaper to run compaction and allocate order 3 page than to use small 1-pages slabs? Do I miss something? We do have defragmentation logic and defragmentation passes to address that. In general the need for larger physical contiguous memory segments will increase as RAM gets larger and larger. Maybe 2M is the next step but we will always have to face fragmentation regardless of what the next size it. -- 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/5] cpufreq:boost: Add support for software based CPU frequency boost
Hi Lukasz,
On 7 June 2013 18:57, Lukasz Majewski l.majew...@samsung.com wrote:
I hope you agreed to all the other comments I gave as I don't see an
explicit reply below each of these. I have seen people missing these
in past, so what would be better to do is:
- either reply below each one of them and say yes or no..
- Or write once below many comments and say: All above comments
are accepted.
So, that Reviewer is assured that you haven't missed anything.
I would prefer to have following fields in the cpufreq_boost structure:
struct cpufreq_boost {
unsigned intmax_boost_freq; /*boost max freq*/
unsigned intmax_normal_freq; /*max normal freq
int (*low_level_boost) (int state);
bool boost_en; /* indicate if boost is enabled */
}
The max_{boost|normal}_freq fields will be filed at
ret = cpufreq_driver-init(policy);
Thanks to them I will avoid calling many times routine, which extracts
from freq_table maximal boost and normal frequencies.
I could define those variables in the exynos-cpufreq.c driver, but I
think, that they are more suitable to be embedded at cpufreq_boost
structure.
I understand that you need these variables (I will still look how you are
using them in next version). But they are per policy and driver isn't
responsible for maintaining them. If they are required then cpufreq
core must find them out and keep in struct cpufreq_policy (as they
are policy dependent)..
So, remove this structure from cpufreq_driver and embed variables
directly.
--
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 09/10] mm: thrash detection-based file cache sizing
On 30.05.2013 22:04, Johannes Weiner wrote: +/* + * Monotonic workingset clock for non-resident pages. + * + * The refault distance of a page is the number of ticks that occurred + * between that page's eviction and subsequent refault. + * + * Every page slot that is taken away from the inactive list is one + * more slot the inactive list would have to grow again in order to + * hold the current non-resident pages in memory as well. + * + * As the refault distance needs to reflect the space missing on the + * inactive list, the workingset time is advanced every time the + * inactive list is shrunk. This means eviction, but also activation. + */ +static atomic_long_t workingset_time; It seems strange to me, that workingset_time is global. Don't you want to make it per-cgroup? Two more questions: 1) do you plan to take fadvise's into account somehow? 2) do you plan to use workingset information to enhance the readahead mechanism? Thanks! Regards, Roman -- 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/4] perf tools: Add attrnum syntax to event parser
On 03.06.13 15:54:22, Jiri Olsa wrote: On Fri, May 31, 2013 at 11:16:24AM +0200, Robert Richter wrote: From: Robert Richter robert.rich...@calxeda.com The event parser is limited to update only a subset of all fields in struct perf_event_attr (config*, period, branch_type). We are not able to set other attr fields, esp. flags. Introducing a new syntax to set any field of the event attribute by using an index to the u64 value to be used within struct perf_event_attr. The new syntax attrnum is similar to confignum, but num specifies the index to be used. E.g. attr5:23 sets bit 23 of the flag field of attr. The persistent event implementation is a use case of the above. In this case sysfs provides: /sys/bus/event_source/devices/persistent/events/mce_record:persistent,config=106 /sys/bus/event_source/devices/persistent/format/persistent:attr5:23 good idea, you probably need to update: Documentation/ABI/testing/sysfs-bus-event_source-devices-format I will add something there. also.. there's so far only mce_record event AFAICS, and this seems to be initialized at the time when sysfs's not ready so I dont get the sysfs entries for it.. and since there's no other event yet, the sysfs is not updated/populated later.. I think ;) The code adds entries dynamically. If something was added to the persistent events list, the sysfs entry is updated too. You should actually should see something in sysfs. Code that registers it is here for Intel or AMD: arch/x86/kernel/cpu/mcheck/mce.c:mcheck_init_tp() I'll probably tweak it somehow later, but if there was anything simple I could do or I missed something please let me know, that would speed up my testing CONFIG_FTRACE should be enabled (which enables tracepoints), but this is probably enabled per default. Otherwise the persistent pmu should be visible in sysfs. What does dmesg show on your system? -Robert -- 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: Scaling problem with a lot of AF_PACKET sockets on different interfaces
07.06.2013 16:05, Daniel Borkmann пишет:
On 06/07/2013 02:41 PM, Mike Galbraith wrote:
(CC's net-fu dojo)
On Fri, 2013-06-07 at 14:56 +0300, Vitaly V. Bursov wrote:
Hello,
I have a Linux router with a lot of interfaces (hundreds or
thousands of VLANs) and an application that creates AF_PACKET
socket per interface and bind()s sockets to interfaces.
Each socket has attached BPF filter too.
The problem is observed on linux-3.8.13, but as far I can see
from the source the latest version has alike behavior.
I noticed that box has strange performance problems with
most of the CPU time spent in __netif_receive_skb:
86.15% [k] __netif_receive_skb
1.41% [k] _raw_spin_lock
1.09% [k] fib_table_lookup
0.99% [k] local_bh_enable_ip
and this the assembly with the hot spot:
│ shr$0x8,%r15w
│ and$0xf,%r15d
0.00 │ shl$0x4,%r15
│ add$0x8165ec80,%r15
│ mov(%r15),%rax
0.09 │ mov%rax,0x28(%rsp)
│ mov0x28(%rsp),%rbp
0.01 │ sub$0x28,%rbp
│ jmp5c7
1.72 │5b0: mov0x28(%rbp),%rax
0.05 │ mov0x18(%rsp),%rbx
0.00 │ mov%rax,0x28(%rsp)
0.03 │ mov0x28(%rsp),%rbp
5.67 │ sub$0x28,%rbp
1.71 │5c7: lea0x28(%rbp),%rax
1.73 │ cmp%r15,%rax
│ je 640
1.74 │ cmp%r14w,0x0(%rbp)
│ jne5b0
81.36 │ mov0x8(%rbp),%rax
2.74 │ cmp%rax,%r8
│ je 5eb
1.37 │ cmp0x20(%rbx),%rax
│ je 5eb
1.39 │ cmp%r13,%rax
│ jne5b0
0.04 │5eb: test %r12,%r12
0.04 │ je 6f4
│ mov0xc0(%rbx),%eax
│ mov0xc8(%rbx),%rdx
│ testb $0x8,0x1(%rdx,%rax,1)
│ jne6d5
This corresponds to:
net/core/dev.c:
type = skb-protocol;
list_for_each_entry_rcu(ptype,
ptype_base[ntohs(type) PTYPE_HASH_MASK], list) {
if (ptype-type == type
(ptype-dev == null_or_dev || ptype-dev == skb-dev ||
ptype-dev == orig_dev)) {
if (pt_prev)
ret = deliver_skb(skb, pt_prev, orig_dev);
pt_prev = ptype;
}
}
Which works perfectly OK until there are a lot of AF_PACKET sockets, since
the socket adds a protocol to ptype list:
# cat /proc/net/ptype
Type Device Function
0800 eth2.1989 packet_rcv+0x0/0x400
0800 eth2.1987 packet_rcv+0x0/0x400
0800 eth2.1986 packet_rcv+0x0/0x400
0800 eth2.1990 packet_rcv+0x0/0x400
0800 eth2.1995 packet_rcv+0x0/0x400
0800 eth2.1997 packet_rcv+0x0/0x400
...
0800 eth2.1004 packet_rcv+0x0/0x400
0800 ip_rcv+0x0/0x310
0011 llc_rcv+0x0/0x3a0
0004 llc_rcv+0x0/0x3a0
0806 arp_rcv+0x0/0x150
And this obviously results in a huge performance penalty.
ptype_all, by the looks, should be the same.
Probably one way to fix this it to perform interface name matching in
af_packet handler, but there could be other cases, other protocols.
Ideas are welcome :)
Probably, that depends on _your scenario_ and/or BPF filter, but would it be
an alternative if you have only a few packet sockets (maybe one pinned to each
cpu) and cluster/load-balance them together via packet fanout? (Where you
bind the socket to ifindex 0, so that you get traffic from all devs...) That
would at least avoid that hot spot, and you could post-process the interface
via sockaddr_ll. But I'd agree that this will not solve the actual problem
you've
observed. ;-)
I was't aware of the ifindex 0 thing, it can help, thanks! Of course, if it'll
work for me (applications is a custom DHCP server) it'll surely
increase the overhead of BPF (I don't need to tap the traffic from all
interfaces), there are vlans, bridges and bonds - likely the server will receive
same packets multiple times and replies must be sent too...
but it still should be faster.
I just checked isc-dhcpd-V3.1.3 running on multiple interfaces
(another system with 2.6.32):
$ cat /proc/net/ptype
Type Device Function
ALL eth0 packet_rcv_spkt+0x0/0x190
ALL eth0.10 packet_rcv_spkt+0x0/0x190
ALL eth0.11 packet_rcv_spkt+0x0/0x190
As I understand, it'll hit this code:
list_for_each_entry_rcu(ptype, ptype_all, list) {
if (!ptype-dev || ptype-dev == skb-dev) {
if (pt_prev)
ret = deliver_skb(skb, pt_prev, orig_dev);
pt_prev = ptype;
}
}
which scales the same.
Thanks.
--
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
Re: [ 027/184] ring-buffer: Fix race between integrity check and
On Fri, Jun 07, 2013 at 10:07:00AM -0400, Steven Rostedt wrote: On Tue, 2013-06-04 at 19:21 +0200, Willy Tarreau wrote: 2.6.32-longterm review patch. If anyone has any objections, please let me know. -- readers From: Steven Rostedt srost...@redhat.com commit 9366c1ba13fbc41bdb57702e75ca4382f209c82f upstream. This isn't the right commit (thanks to Ben for bringing this to my attention). That this commit SHA1 matches the change log but not the change. According to git blame, the change below is from: 54f7be5b831254199522523ccab4c3d954bbf576 ring-buffer: Fix NULL pointer if rb_set_head_page() fails Ah yes indeed, thank you for bringing this up, Steve. Willy -- 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: usbutils 006 release
On Thu, 6 Jun 2013, Greg KH wrote: On Mon, Jul 09, 2012 at 11:22:22AM -0400, Alan Stern wrote: On Fri, 6 Jul 2012, Greg KH wrote: Here's the 006 release of usbutils. Some USB 3.0 updates, a new usb.ids file update, and a number of other fixes and updates for annoying problems that people had reported. Full shortlog information is below if people are curious. The package can be downladed from kernel.org: http://www.kernel.org/pub/linux/utils/usb/usbutils/ We've switched over to using git for development now, which makes things much easier than the old cvs tree. The tree can be found on both kernel.org and github.com if you want to fork it and send us changes easier: http://git.kernel.org/?p=linux/kernel/git/gregkh/usbutils.git This link doesn't work for me. Are you sure the repository is installed at git.kernel.org? It wasn't, sorry, I've pushed it there now, and should show up in a few hours. A mere eleven months late... :-) Alan Stern -- 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] arm/dt: Don't add disabled CPUs to system topology
On 06/07/2013 05:23 AM, Lorenzo Pieralisi wrote: Hi James, On Thu, Jun 06, 2013 at 06:11:25PM +0100, James King wrote: If CPUs are marked as disabled in the devicetree, make sure they do not exist in the system CPU information and CPU topology information. In this case these CPUs will not be able to be added to the system later using hot-plug. This allows a single chip with many CPUs to be easily used in a variety of hardware devices where they may have different actual processing requirements (eg for thermal/cost reasons). - Change devicetree.c to ignore any cpu nodes marked as disabled, this effectively limits the number of active cpu cores so no need for the max_cpus=x in the chosen node. - Change topology.c to ignore any cpu nodes marked as disabled, this is where the scheduler would learn about big/LITTLE cores so this effectively keeps the scheduler in sync. I have two questions: 1) Since with this approach the DT should change anyway if on different hardware devices based on the same chip you want to allow booting a different number of CPUs, why do not we remove the cpu nodes instead of disabling them ? Put it another way: cpu nodes define a cpu as possible (currently), we can simply remove the node if we do not want that cpu to be seen by the kernel. 2) If we go for the status property, why do not we use it to set present mask ? That way the cpu is possible but not present, you cannot hotplug it in. It is a bit of a stretch, granted, the cpu _is_ present, we just want to disable it, do not know how this is handled in x86 and other archs though. The meaning of disabled for cpus in ePAPR is that the cpu is offline (i.e. in a spinloop or wfi), not that the cpu is unavailable. This is a bit of a departure and inconsistency from how status for devices are used. That would imply that we should be setting status to disabled for all secondary cores and that possibly the status value should get updated to reflect the state of the cpu. Rob I am just asking, since it is something I thought about while writing code that parses the DT cpu map, basically we do not have a way to disable a cpu in the DT and that's what you are doing, I just would like to understand the best way to put it into DT bindings. Thanks, Lorenzo ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- 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] mfd: dbx500-prcmu: Correctly reorder PRCMU clock identifiers
On Fri, 07 Jun 2013, Linus Walleij wrote:
On Thu, Jun 6, 2013 at 1:21 PM, Lee Jones lee.jo...@linaro.org wrote:
... as stipulated by the Hardware Specification document.
Signed-off-by: Lee Jones lee.jo...@linaro.org
I think you need Ulf (as ux500 clock author) and Loic (as PRCMU
developer) to have a look at this.
-enum prcmu_clock {
- PRCMU_SGACLK,
(...)
+#define ARMCLK 0
+#define PRCMU_ACLK 1
(...)
It seems the enum and the defines want to do two different things?
The first is a kernel-internal representation of the clocks, whereas
the latter is a HW-centric representation for a certain PRCMU
variant (I guess?)
Does one actually exclude the other?
From what I can tell, they're non-ordered values which are used as
read-ins to the clk_mgt array. So long as they are unique I'm not sure
the order matters. The current order seems 'made up', unless I'm
mistaken.
I agree that Ulf should take a look and confirm/deny my findings.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/
[RFC PATCH 01/50] ARM: at91: move at91_pmc.h to include/linux/clk/at91.h
This patch moves at91_pmc.h header from machine specific directory (arch/arm/mach-at91/include/mach/at91_pmc.h) to clk include directory (include/linux/clk/at91.h). We need this to avoid reference to machine specific headers in clk drivers. Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com --- arch/arm/mach-at91/at91rm9200.c|2 +- arch/arm/mach-at91/at91sam9260.c |2 +- arch/arm/mach-at91/at91sam9261.c |2 +- arch/arm/mach-at91/at91sam9263.c |2 +- arch/arm/mach-at91/at91sam9g45.c |2 +- arch/arm/mach-at91/at91sam9n12.c |2 +- arch/arm/mach-at91/at91sam9rl.c|2 +- arch/arm/mach-at91/at91sam9x5.c|2 +- arch/arm/mach-at91/clock.c |2 +- arch/arm/mach-at91/pm.c|2 +- arch/arm/mach-at91/pm_slowclock.S |2 +- arch/arm/mach-at91/sama5d3.c |2 +- arch/arm/mach-at91/setup.c |2 +- drivers/usb/gadget/atmel_usba_udc.c|2 +- .../mach/at91_pmc.h = include/linux/clk/at91.h|2 +- 15 files changed, 15 insertions(+), 15 deletions(-) diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c index d193a40..6ea6de7 100644 --- a/arch/arm/mach-at91/at91rm9200.c +++ b/arch/arm/mach-at91/at91rm9200.c @@ -11,13 +11,13 @@ */ #include linux/module.h +#include linux/clk/at91.h #include asm/irq.h #include asm/mach/arch.h #include asm/mach/map.h #include asm/system_misc.h #include mach/at91rm9200.h -#include mach/at91_pmc.h #include mach/at91_st.h #include mach/cpu.h diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c index a8ce245..df32768 100644 --- a/arch/arm/mach-at91/at91sam9260.c +++ b/arch/arm/mach-at91/at91sam9260.c @@ -11,6 +11,7 @@ */ #include linux/module.h +#include linux/clk/at91.h #include asm/proc-fns.h #include asm/irq.h @@ -20,7 +21,6 @@ #include mach/cpu.h #include mach/at91_dbgu.h #include mach/at91sam9260.h -#include mach/at91_pmc.h #include at91_aic.h #include at91_rstc.h diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c index 25efb5a..8a63b81 100644 --- a/arch/arm/mach-at91/at91sam9261.c +++ b/arch/arm/mach-at91/at91sam9261.c @@ -11,6 +11,7 @@ */ #include linux/module.h +#include linux/clk/at91.h #include asm/proc-fns.h #include asm/irq.h @@ -19,7 +20,6 @@ #include asm/system_misc.h #include mach/cpu.h #include mach/at91sam9261.h -#include mach/at91_pmc.h #include at91_aic.h #include at91_rstc.h diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c index f44ffd2..77b3c24 100644 --- a/arch/arm/mach-at91/at91sam9263.c +++ b/arch/arm/mach-at91/at91sam9263.c @@ -11,6 +11,7 @@ */ #include linux/module.h +#include linux/clk/at91.h #include asm/proc-fns.h #include asm/irq.h @@ -18,7 +19,6 @@ #include asm/mach/map.h #include asm/system_misc.h #include mach/at91sam9263.h -#include mach/at91_pmc.h #include at91_aic.h #include at91_rstc.h diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c index 8b7fce0..31a1304 100644 --- a/arch/arm/mach-at91/at91sam9g45.c +++ b/arch/arm/mach-at91/at91sam9g45.c @@ -12,13 +12,13 @@ #include linux/module.h #include linux/dma-mapping.h +#include linux/clk/at91.h #include asm/irq.h #include asm/mach/arch.h #include asm/mach/map.h #include asm/system_misc.h #include mach/at91sam9g45.h -#include mach/at91_pmc.h #include mach/cpu.h #include at91_aic.h diff --git a/arch/arm/mach-at91/at91sam9n12.c b/arch/arm/mach-at91/at91sam9n12.c index 13cdbcd..f9ff4d2 100644 --- a/arch/arm/mach-at91/at91sam9n12.c +++ b/arch/arm/mach-at91/at91sam9n12.c @@ -8,12 +8,12 @@ #include linux/module.h #include linux/dma-mapping.h +#include linux/clk/at91.h #include asm/irq.h #include asm/mach/arch.h #include asm/mach/map.h #include mach/at91sam9n12.h -#include mach/at91_pmc.h #include mach/cpu.h #include board.h diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c index f77fae5..6fbda1a 100644 --- a/arch/arm/mach-at91/at91sam9rl.c +++ b/arch/arm/mach-at91/at91sam9rl.c @@ -10,6 +10,7 @@ */ #include linux/module.h +#include linux/clk/at91.h #include asm/proc-fns.h #include asm/irq.h @@ -19,7 +20,6 @@ #include mach/cpu.h #include mach/at91_dbgu.h #include mach/at91sam9rl.h -#include mach/at91_pmc.h #include at91_aic.h #include at91_rstc.h diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c index e631fec..83fc6b3 100644 --- a/arch/arm/mach-at91/at91sam9x5.c +++ b/arch/arm/mach-at91/at91sam9x5.c @@ -8,12 +8,12 @@ #include linux/module.h #include linux/dma-mapping.h +#include linux/clk/at91.h #include asm/irq.h #include asm/mach/arch.h #include asm/mach/map.h #include
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 07, 2013 at 08:52:43AM +0100, luke.leighton wrote:
coming back to what you said earlier: i'm formulating what to say to
allwinner [and need to pre-send something by monday so that they can
consider it before the meeting]. so far, it consists of:
* device-tree is what the linux kernel community has come up with, it
is equivalent to FEX.
From what I have seem looking at FEX, devicetree is vastly more powerful
and scalable than FEX. It is also a standard (IEEE1275) that has been
around for many years (given devicetree is using part of openfirmware).
* the linux kernel community would like to apologise for not
consulting with you (allwinner) on the decision to only accept device
tree
I would consider that an enourmous lie. Devicetree was around long
before their company had ever started doing the allwinner. It might
not have been used in ARM yet, but it was used in a number of other
architectures, making it the obvious choice for doing the same thing on
more architectures.
[bear in mind that if this kind of thing isn't said, they risk just
continuing to make the sunxi community's life absolute hell by
continuing to work in isolation and continuing to duplicate drivers
etc. etc. ]
That is their problem (and their customers).
* work is being done by the free software community, they are
beginning to integrate allwinner's work into the upstream kernel, and
you (allwinner) will begin to see this when you get round to doing
linux kernel 3.9
If something is popular enough, people will work on getting it supported,
where supported means done properly.
* allwinner and the linux and sunxi community therefore need to work
closer together, we propose:
* {insert proposals here}
How about allwinner simply tries to help with the activity already taking
place for getting everything working with devicetree. That probably
means doing work to their tools to generate devicetree files from their
FEX files, if they really like FEX (and think their customers like FEX).
3 days left on the clock.
Who cares what your deadline is. That's not how good choices are made.
--
Len Sorensen
--
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/
[RFC PATCH 02/50] ARM: at91: add PMC main clock
This is the at91 main oscillator clock implementation using common
clk framework.
If rate is not provided during clock registraction it is computed using
the slow clock (main clk parent in this case) rate and the MCFR register.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
drivers/clk/at91/Makefile |5 ++
drivers/clk/at91/clk-main.c | 106 +++
include/linux/clk/at91.h| 10
3 files changed, 121 insertions(+)
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
new file mode 100644
index 000..42c084e
--- /dev/null
+++ b/drivers/clk/at91/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for at91 specific clk
+#
+
+obj-y += clk-main.o
diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
new file mode 100644
index 000..738fa39
--- /dev/null
+++ b/drivers/clk/at91/clk-main.c
@@ -0,0 +1,106 @@
+/*
+ * drivers/clk/at91/clk-main.c
+ *
+ * Copyright (C) 2013 Boris BREZILLON b.brezil...@overkiz.com
+ *
+ * This mainram is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/clk/at91.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/io.h
+
+#define to_clk_main(hw) container_of(hw, struct clk_main, hw)
+struct clk_main {
+ struct clk_hw hw;
+ unsigned long rate;
+};
+
+static unsigned long clk_main_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ u32 tmp;
+ struct clk_main *clkmain = to_clk_main(hw);
+ if (clkmain-rate)
+ return clkmain-rate;
+ while ((tmp = at91_pmc_read(AT91_CKGR_MCFR)) AT91_PMC_MAINRDY)
+ ;
+ tmp = AT91_PMC_MAINF;
+ clkmain-rate = (tmp * parent_rate) / 16;
+ return clkmain-rate;
+}
+
+static const struct clk_ops main_ops = {
+ .recalc_rate = clk_main_recalc_rate,
+};
+
+struct clk * __init
+at91_clk_register_main(const char *name,
+ const char *parent_name,
+ unsigned long rate)
+{
+ struct clk_main *clkmain;
+ struct clk *clk = NULL;
+ struct clk_init_data init;
+
+ if (!rate !parent_name)
+ return ERR_PTR(-EINVAL);
+
+ clkmain = kzalloc(sizeof(*clkmain), GFP_KERNEL);
+ if (!clkmain)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.ops = main_ops;
+ init.parent_names = parent_name ? parent_name : NULL;
+ init.num_parents = parent_name ? 1 : 0;
+ init.flags = parent_name ? 0 : CLK_IS_ROOT;
+
+ clkmain-hw.init = init;
+ clkmain-rate = rate;
+
+ clk = clk_register(NULL, clkmain-hw);
+
+ if (IS_ERR(clk))
+ kfree(clkmain);
+
+ return clk;
+}
+
+
+
+#if defined(CONFIG_OF)
+static void __init
+of_at91_clk_main_setup(struct device_node *np)
+{
+ struct clk *clk;
+ const char *parent_name;
+ const char *name = np-name;
+ u32 rate = 0;
+
+ parent_name = of_clk_get_parent_name(np, 0);
+ of_property_read_string(np, clock-output-names, name);
+ of_property_read_u32(np, clock-frequency, rate);
+
+ clk = at91_clk_register_main(name, parent_name, rate);
+
+ if (!IS_ERR(clk))
+ return;
+
+ of_clk_add_provider(np, of_clk_src_simple_get, clk);
+}
+
+static void __init of_at91rm9200_clk_main_setup(struct device_node *np)
+{
+ of_at91_clk_main_setup(np);
+}
+CLK_OF_DECLARE(at91rm9200_clk_main, atmel,at91rm9200-clk-main,
+ of_at91rm9200_clk_main_setup);
+#endif
diff --git a/include/linux/clk/at91.h b/include/linux/clk/at91.h
index 58b1eba..c0801e7 100644
--- a/include/linux/clk/at91.h
+++ b/include/linux/clk/at91.h
@@ -16,6 +16,8 @@
#ifndef AT91_PMC_H
#define AT91_PMC_H
+#include linux/clk-provider.h
+
#ifndef __ASSEMBLY__
extern void __iomem *at91_pmc_base;
@@ -184,4 +186,12 @@ extern void __iomem *at91_pmc_base;
#defineAT91_PMC_PCR_DIV8 0x8
/* Peripheral clock is MCK/8 */
#defineAT91_PMC_PCR_EN (0x128) /*
Enable */
+
+
+
+struct clk * __init
+at91_clk_register_main(const char *name,
+ const char *parent_name,
+ unsigned long rate);
+
#endif
--
1.7.9.5
--
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/3] i2c: nomadik: use pinctrl PM helpers
Linus Walleij linus.wall...@linaro.org writes:
On Wed, Jun 5, 2013 at 6:34 PM, Kevin Hilman khil...@linaro.org wrote:
From: Linus Walleij linus.wall...@linaro.org
This utilize the new pinctrl core PM helpers to transition
the driver to sleep and idle states, cutting away some
boilerplate code.
Cc: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Mark Brown broo...@kernel.org
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Wolfram Sang w...@the-dreams.de
Signed-off-by: Linus Walleij linus.wall...@linaro.org
I have some questions on the interaction with runtime PM here...
OK, to get the basic infrastructure in place I have merged these
patches with the I2C maintainers ACK, since it is doing one thing,
i.e. moving the functionality out of the driver and into the pinctrl
core.
I am considering semantic changes related to runtime PM in
addition to this as a separate patch, so let's start talking about
that here.
It would be inappropriate to try to create a patch that is
changing these two things at once, but let's see where we end
up by the merge window.
@@ -645,13 +636,7 @@ static int nmk_i2c_xfer(struct i2c_adapter *i2c_adap,
}
/* Optionaly enable pins to be muxed in and configured */
- if (!IS_ERR(dev-pins_default)) {
- status = pinctrl_select_state(dev-pinctrl,
- dev-pins_default);
- if (status)
- dev_err(dev-adev-dev,
- could not set default pins\n);
- }
+ pinctrl_pm_select_default_state(dev-adev-dev);
Shouldn't this be in the -runtime_resume() callback of the driver (the
original code should've as well.)
IOW, the pinctrl changes only need to happen when the runtime PM
usecount goes from zero to 1. For any additional users, the device will
already be active and pins already in default state.
I'm not familiar with this HW, and maybe the driver already prevents
multiple users, but for correctness sake (and because others will copy
this), the (re)muxing should be in the runtime PM callback.
I2C message are serialized/marshalled by nature so it's actually
not causing a concurrency problem: this xfer function will not be
called from two places for the same driver.
What is true however is that we're hammering the pins from
active to idle for every transfer, instead of letting runtime PM
provide some nice hysteresis (autosuspend) around that.
Notice though that:
- This driver has no driver-local runtime PM callbacks, so the
runtime PM calls are intended to inform the rest of the system,
such as the bus, that the device is idle.
- The bus used is the AMBA (PrimeCell) bus,
drivers/amba/bus.c
Also, IMO, that's further evidence that the pinctrl stuff could (and
probably should) be handled by the PM core.
So I'm now thinking about how to achieve this.
What happens for this driver when the usecount goes from
1-0 is (the other way is very similar):
drivers/base/power/runtime.c
if (dev-pm_domain)
callback = dev-pm_domain-ops.runtime_suspend;
else if (dev-type dev-type-pm)
callback = dev-type-pm-runtime_suspend;
else if (dev-class dev-class-pm)
callback = dev-class-pm-runtime_suspend;
else if (dev-bus dev-bus-pm)
callback = dev-bus-pm-runtime_suspend;
else
callback = NULL;
if (!callback dev-driver dev-driver-pm)
callback = dev-driver-pm-runtime_suspend;
retval = rpm_callback(callback, dev);
This platform will currently hit dev-bus-pm-runtime_suspend
to drivers/amba/bus.c:
static int amba_pm_runtime_suspend(struct device *dev)
{
struct amba_device *pcdev = to_amba_device(dev);
int ret = pm_generic_runtime_suspend(dev);
if (ret == 0 dev-driver)
clk_disable(pcdev-pclk);
return ret;
}
The pm_generic_runtime_suspend will call the driver callbacks
(none in this case).
Then the bus core proceeds to gate off the block clock and
we're done.
I could make a patch adding runtime PM ops to the
driver itself to set the pinctrl state from there, which would
be a nice improvement in itself.
But we're discussing handling it all in the PM core, so
let's think bigger.
If we're making this all generic, were in this chain do you
suggest that I set the pins to idle?
drivers/base/power/runtime.c?
Yes, that's where I was thinking.
One thing in particular that worries me here is the ordering
of things, because that has been a severe issue for us.
In the original series from Hebbar Gururaja, Grygorii Strashko pointed
out that we may have some of the ordering issues on OMAP as well. I
hadn't thought about that (enough) yet.
For example: maybe on a certain
Re: Scaling problem with a lot of AF_PACKET sockets on different interfaces
On 06/07/2013 04:17 PM, Vitaly V. Bursov wrote: 07.06.2013 16:05, Daniel Borkmann пишет: [...] Ideas are welcome :) Probably, that depends on _your scenario_ and/or BPF filter, but would it be an alternative if you have only a few packet sockets (maybe one pinned to each cpu) and cluster/load-balance them together via packet fanout? (Where you bind the socket to ifindex 0, so that you get traffic from all devs...) That would at least avoid that hot spot, and you could post-process the interface via sockaddr_ll. But I'd agree that this will not solve the actual problem you've observed. ;-) I was't aware of the ifindex 0 thing, it can help, thanks! Of course, if it'll work for me (applications is a custom DHCP server) it'll surely increase the overhead of BPF (I don't need to tap the traffic from all interfaces), there are vlans, bridges and bonds - likely the server will receive same packets multiple times and replies must be sent too... but it still should be faster. Well, as already said, if you use a fanout socket group, then you won't receive the _exact_ same packet twice. Rather, packets are balanced by different policies among your packet sockets in that group. What you could do is to have a (e.g.) single BPF filter (jitted) for all those sockets that'll let needed packets pass and you can then access the interface they came from via sockaddr_ll, which then is further processed in your fast path (or dropped depending on the iface). There's also a BPF extension (BPF_S_ANC_IFINDEX) that lets you load the ifindex of the skb into the BPF accumulator, so you could also filter early from there for a range of ifindexes (in combination to bind the sockets to index 0). Probably that could work. -- 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/
[RFC PATCH 03/50] ARM: at91: add PMC pll clocks
This is the at91 pll clock implementation using common clk framework.
The pll clock layout describe the PLLX register layout.
There's four pll clock layouts:
- at91rm9200
- at91sam9g20
- at91sam9g45
- sama5d3
PLL clocks are given characteristics:
- min/max clock source rate
- ranges of valid clock output rates
- values to set in out and icpll fields for each supported output range
These characteristics are checked during rate change to avoid
over/underclocking.
These characteristics are described in atmel's SoC datasheet in
Electrical Characteristics paragraph.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
drivers/clk/at91/Makefile |2 +-
drivers/clk/at91/clk-pll.c| 438 +
drivers/clk/at91/clk-plldiv.c | 125
include/linux/clk/at91.h | 39
4 files changed, 603 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 42c084e..564076f 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -2,4 +2,4 @@
# Makefile for at91 specific clk
#
-obj-y += clk-main.o
+obj-y += clk-main.o clk-pll.o clk-plldiv.o
diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
new file mode 100644
index 000..d5dc0ac
--- /dev/null
+++ b/drivers/clk/at91/clk-pll.c
@@ -0,0 +1,438 @@
+/*
+ * drivers/clk/at91/clk-pll.c
+ *
+ * Copyright (C) 2013 Boris BREZILLON b.brezil...@overkiz.com
+ *
+ * This pllram is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/clk/at91.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/io.h
+
+#define to_clk_pll(hw) container_of(hw, struct clk_pll, hw)
+
+struct clk_pll {
+ struct clk_hw hw;
+ u8 id;
+ u8 div;
+ u8 range;
+ u16 mul;
+ struct clk_pll_layout *layout;
+ struct clk_pll_characteristics *characteristics;
+};
+
+static int clk_pll_prepare(struct clk_hw *hw)
+{
+ struct clk_pll *pll = to_clk_pll(hw);
+ while (!(at91_pmc_read(AT91_PMC_SR)
+(1 (AT91_PMC_LOCKA + pll-id
+ ;
+ return 0;
+}
+
+static int clk_pll_is_prepared(struct clk_hw *hw)
+{
+ struct clk_pll *pll = to_clk_pll(hw);
+ return !!(at91_pmc_read(AT91_PMC_SR)
+ (1 (AT91_PMC_LOCKA + pll-id)));
+}
+
+static int clk_pll_enable(struct clk_hw *hw)
+{
+ return 0;
+}
+
+static void clk_pll_disable(struct clk_hw *hw)
+{
+ struct clk_pll *pll = to_clk_pll(hw);
+ struct clk_pll_layout *layout = pll-layout;
+ int offset = AT91_CKGR_PLLAR + (pll-id * 4);
+ u32 tmp = at91_pmc_read(offset) ~(layout-pllr_mask);
+ at91_pmc_write(offset, tmp);
+}
+
+static int clk_pll_is_enabled(struct clk_hw *hw)
+{
+ struct clk_pll *pll = to_clk_pll(hw);
+ return !!(at91_pmc_read(AT91_PMC_SR)
+ (1 (AT91_PMC_LOCKA + pll-id)));
+}
+
+static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ struct clk_pll *pll = to_clk_pll(hw);
+ struct clk_pll_layout *layout = pll-layout;
+ int offset = AT91_CKGR_PLLAR + (pll-id * 4);
+ u32 tmp = at91_pmc_read(offset) layout-pllr_mask;
+ u8 div = tmp 0xFF;
+ u16 mul = (tmp layout-mul_shift) layout-mul_mask;
+ if (!div || !mul)
+ return 0;
+
+ return (parent_rate * (mul + 1)) / div;
+}
+
+static long clk_pll_get_best_div_mul(struct clk_pll *pll, unsigned long rate,
+unsigned long parent_rate,
+u32 *div, u32 *mul,
+u32 *index) {
+ unsigned long maxrate;
+ unsigned long minrate;
+ unsigned long divrate;
+ unsigned long bestdiv = 1;
+ unsigned long bestmul;
+ unsigned long tmpdiv;
+ unsigned long roundup;
+ unsigned long rounddown;
+ unsigned long remainder;
+ unsigned long bestremainder;
+ unsigned long maxmul;
+ unsigned long maxdiv;
+ unsigned long mindiv;
+ int i = 0;
+ struct clk_pll_layout *layout = pll-layout;
+ struct clk_pll_characteristics *characteristics = pll-characteristics;
+
+ /* Minimum divider = 1 */
+ /* Maximum multiplier = max_mul */
+ maxmul = layout-mul_mask + 1;
+ maxrate = (parent_rate * maxmul) / 1;
+
+ /* Maximum divider = max_div */
+ /* Minimum multiplier = 2 */
+ maxdiv = 0xFF;
+ minrate = (parent_rate * 2) / maxdiv;
+
+ if (parent_rate characteristics-input.min ||
+ parent_rate characteristics-input.max)
+ return -ERANGE;
+
+ if
Re: [PATCH 2/5] cpufreq:boost: Add support for software based CPU frequency boost
Hi Viresh,
Hi Lukasz,
On 7 June 2013 18:57, Lukasz Majewski l.majew...@samsung.com wrote:
I hope you agreed to all the other comments I gave as I don't see an
explicit reply below each of these. I have seen people missing these
in past, so what would be better to do is:
- either reply below each one of them and say yes or no..
- Or write once below many comments and say: All above comments
are accepted.
So, that Reviewer is assured that you haven't missed anything.
Thanks for reminding :-).
I've read through all the comments. I'm redesigning now the driver to
remove redundant code.
I would prefer to have following fields in the cpufreq_boost
structure: struct cpufreq_boost {
unsigned intmax_boost_freq; /*boost max freq*/
unsigned intmax_normal_freq; /*max normal freq
int (*low_level_boost) (int state);
bool boost_en; /* indicate if boost is enabled */
}
The max_{boost|normal}_freq fields will be filed at
ret = cpufreq_driver-init(policy);
Thanks to them I will avoid calling many times routine, which
extracts from freq_table maximal boost and normal frequencies.
I could define those variables in the exynos-cpufreq.c driver, but I
think, that they are more suitable to be embedded at cpufreq_boost
structure.
I understand that you need these variables (I will still look how you
are using them in next version). But they are per policy and driver
isn't responsible for maintaining them. If they are required then
cpufreq core must find them out and keep in struct cpufreq_policy (as
they are policy dependent)..
So, remove this structure from cpufreq_driver and embed variables
directly.
After refactoring the code. I admit, that we shall embed the struct
cpu_boost fields directly to the coufreq_driver. There is no point to
create structure with 2 fields.
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
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/
[RESEND RFC PATCH 00/50] ARM: at91: move to common clk framework
Hello, Sorry for the noise, the first submission has been filtered. This patch series is a proposal to move at91 clock implementation to common clk framework. Most of the clock provided by the PMC (Power Management Controller) are implemented : - main clock (main oscillator) - pll clocks - master clock - programmable clocks - utmi clock - peripheral clocks - system clocks This implementation is compatible with device tree: the goal is to define the whole clock tree in the device tree (all currently available dt SoCs and boards are patched to support dt clocks). Please feel free to comment the dt bindinds (I'm not sure about the name I choose or the position of clock nodes: children of pmc node). I removed the register_clocks function in SoC supporting dt boards only: - at91sam9x5 SoCs - at91sam9n12 SoC - sama5d3 SoCs This patch series also update at91 drivers calling clk_enable/disable instead of the preferred clk_prepare_enable/disable_unprepare functions. I know there are a lot of cleanup in progress for at91 arch, so please tell me if you think this transition to common clk framework should wait. This patch series has been tested on Kizbox (sam9g20 SoC) board using device tree. It compiles for other SoCs and both with and without dt support, but it has not been tested. The clocks rate/parent change has not been tested. Best Regards, Boris Boris BREZILLON (50): ARM: at91: move at91_pmc.h to include/linux/clk/at91.h ARM: at91: add PMC main clock ARM: at91: add PMC pll clocks ARM: at91: add PMC master clock ARM: at91: add PMC system clocks ARM: at91: add PMC peripheral clocks ARM: at91: add PMC programmable clocks ARM: at91: add PMC utmi clock support ARM: at91: add PMC usb clock support ARM: at91: add PMC smd clock support ARM: at91: add PMC clk device tree binding doc ARM: at91: move to common clk framework ARM: at91: move at91rm9200 SoC to new at91 clk implem ARM: at91: move at91sam9260 SoC to new at91 clk implem ARM: at91: move at91sam9263 SoC to new at91 clk implem ARM: at91: move at91sam9263 SoC to new at91 clk implem ARM: at91: move at91sam9g45 SoC to new at91 clk implem ARM: at91: move at91sam9n12 SoC to new at91 clk implem ARM: at91: move at91sam9rl SoC to new at91 clk implem ARM: at91: move at91sam9x5 SoCs to new at91 clk implem ARM: at91: move at91sam9 SoCs to new at91 clk implem ARM: at91: move sama5d3 SoCs to new at91 clk implem ARM: at91: move at91rm9200 boards to new at91 clk implem ARM: at91: move at91sam9 boards to new at91 clk implem ARM: at91: move pit timer to common clk framework ARM: at91/tc/clocksource: prepare clk before calling enable at_hdmac: prepare clk before calling enable ASoC: atmel-ssc: prepare clk before calling enable mmc: atmel-mci: prepare clk before calling enable pwm: atmel-tcb: prepare clk before calling enable tty: atmel_serial: prepare clk before calling enable usb: gadget: at91_udc: prepare clk before calling enable ehci-atmel.c: prepare clk before calling enable USB: ohci-at91: prepare clk before calling enable at91/avr32/atmel_lcdfb: prepare clk before calling enable ARM: at91/dt: move at91rm9200 SoC to new at91 clk implem ARM: at91/dt: move at91sam9260 SoC to new at91 clk implem ARM: at91/dt: move at91sam9263 SoC to new at91 clk implem ARM: at91/dt: move at91sam9g45 SoC to new at91 clk implem ARM: at91/dt: move at91sam9n12 SoC to new at91 clk implem ARM: at91/dt: move at91sam9x5 SoCs to new at91 clk implem ARM: at91/dt: move at91sam9g20 SoC to new at91 clk implem ARM: at91/dt: move sama5d3 SoCs to to new at91 clk implem ARM: at91/dt: move sam9260/sam9g20 boards to new at91 clk implem ARM: at91/dt: move rm9200 boards to new at91 clk implem ARM: at91/dt: move sam9263 boards to new at91 clk implem ARM: at91/dt: move sam9g45 boards to new at91 clk implem ARM: at91/dt: move sam9n12 boards to new at91 clk implem ARM: at91/dt: move sam9x5 boards to new at91 clk implem ARM: at91/dt: move sama5d3 boards to new at91 clk implem .../devicetree/bindings/clock/at91-clock.txt | 247 + arch/arm/boot/dts/animeo_ip.dts| 17 +- arch/arm/boot/dts/at91-ariag25.dts | 17 +- arch/arm/boot/dts/at91rm9200.dtsi | 133 +++ arch/arm/boot/dts/at91rm9200ek.dts | 17 +- arch/arm/boot/dts/at91sam9260.dtsi | 144 ++- arch/arm/boot/dts/at91sam9263.dtsi | 135 +++ arch/arm/boot/dts/at91sam9263ek.dts| 17 +- arch/arm/boot/dts/at91sam9g15.dtsi | 11 + arch/arm/boot/dts/at91sam9g20.dtsi | 37 + arch/arm/boot/dts/at91sam9g20ek_common.dtsi| 17 +- arch/arm/boot/dts/at91sam9g25.dtsi |3 + arch/arm/boot/dts/at91sam9g35.dtsi | 23 + arch/arm/boot/dts/at91sam9g45.dtsi | 157 arch/arm/boot/dts/at91sam9m10g45ek.dts | 17 +-
Re: [RFC v1] MFD: Change TWL6025 references to TWL6032
On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote: From: Graeme Gregory g...@slimlogic.co.uk The TWL6025 was never released beyond sample form and was replaced by the PhoenixLite range of chips - TWL6032. Change the references to reference the TWL6032 class and name the registers to twl6032 in line with an actual released chip name to avoid confusion. Currently there is no users of TWL6025 in the code. Given that the chip exists even if not widely distributed it seems as well to keep the twl6025 references in there at least in the device ID table - it won't do any harm to people using the twl6032 name and might help someone who happens to pick up an old board for whatever reason. signature.asc Description: Digital signature
[RFC PATCH 05/50] ARM: at91: add PMC system clocks
This is the at91 system clock implementation using common clk framework.
Some peripheral needs to enable a system clock in order to work properly.
Each system clock is given an id which is the bit offset used in SCER/SCDR
registers.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
drivers/clk/at91/Makefile |1 +
drivers/clk/at91/clk-system.c | 189 +
include/linux/clk/at91.h |3 +
3 files changed, 193 insertions(+)
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index d41f616..13e5714 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -3,3 +3,4 @@
#
obj-y += clk-main.o clk-pll.o clk-plldiv.o clk-master.o
+obj-y += clk-system.o
diff --git a/drivers/clk/at91/clk-system.c b/drivers/clk/at91/clk-system.c
new file mode 100644
index 000..21af468
--- /dev/null
+++ b/drivers/clk/at91/clk-system.c
@@ -0,0 +1,189 @@
+/*
+ * drivers/clk/at91/clk-system.c
+ *
+ * Copyright (C) 2013 Boris BREZILLON b.brezil...@overkiz.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/clk/at91.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/io.h
+
+#define SYSTEM_MAX 32
+
+#define to_clk_system(hw) container_of(hw, struct clk_system, hw)
+struct clk_system {
+ struct clk_hw hw;
+ u8 id;
+};
+
+static int clk_system_enable(struct clk_hw *hw)
+{
+ struct clk_system *sys = to_clk_system(hw);
+ at91_pmc_write(AT91_PMC_SCER, sys-id);
+ return 0;
+}
+
+static void clk_system_disable(struct clk_hw *hw)
+{
+ struct clk_system *sys = to_clk_system(hw);
+ at91_pmc_write(AT91_PMC_SCDR, 1 sys-id);
+}
+
+static int clk_system_is_enabled(struct clk_hw *hw)
+{
+ struct clk_system *sys = to_clk_system(hw);
+ return !!(at91_pmc_read(AT91_PMC_SCSR) (sys-id));
+}
+
+static const struct clk_ops system_ops = {
+ .enable = clk_system_enable,
+ .disable = clk_system_disable,
+ .is_enabled = clk_system_is_enabled,
+};
+
+struct clk * __init
+at91_clk_register_system(const char *name, const char *parent_name, u8 id)
+{
+ struct clk_system *sys;
+ struct clk *clk = NULL;
+ struct clk_init_data init;
+
+ id = 31;
+
+ sys = kzalloc(sizeof(*sys), GFP_KERNEL);
+ if (!sys)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.ops = system_ops;
+ init.parent_names = (parent_name ? parent_name : NULL);
+ init.num_parents = (parent_name ? 1 : 0);
+ init.flags = 0;
+
+ sys-id = id;
+ sys-hw.init = init;
+
+ clk = clk_register(NULL, sys-hw);
+
+ if (IS_ERR(clk))
+ kfree(sys);
+
+ return clk;
+}
+
+#if defined(CONFIG_OF)
+struct clk_system_data {
+ struct clk **clks;
+ u8 *ids;
+ unsigned int clk_num;
+};
+
+static struct clk * __init
+of_clk_src_system_get(struct of_phandle_args *clkspec, void *data)
+{
+ struct clk_system_data *clk_data = data;
+ unsigned int id = clkspec-args[0];
+ int i;
+
+ if (id = SYSTEM_MAX)
+ goto err;
+
+ for (i = 0; i clk_data-clk_num; i++) {
+ if (clk_data-ids[i] == id)
+ return clk_data-clks[i];
+ }
+
+err:
+ pr_err(%s: invalid clock id %d\n, __func__, id);
+ return ERR_PTR(-EINVAL);
+}
+
+static void __init
+of_at91_clk_sys_setup(struct device_node *np)
+{
+ int i;
+ int num;
+ u32 id;
+ struct clk *clk;
+ u8 *ids;
+ struct clk **clks;
+ struct clk_system_data *clktab;
+ const char *parent_name;
+ const char *name = np-name;
+
+ parent_name = of_clk_get_parent_name(np, 0);
+ if (!parent_name)
+ return;
+
+ if (!of_get_property(np, ids, num))
+ return;
+ num /= 4;
+ if (num SYSTEM_MAX)
+ return;
+
+ if (of_count_phandle_with_args(np, clocks, #clock-cells) != num)
+ return;
+
+ if (of_property_count_strings(np, clock-output-names) != num)
+ return;
+
+ clktab = kzalloc(sizeof(*clktab), GFP_KERNEL);
+ if (!clktab)
+ return;
+
+ ids = kzalloc(num * sizeof(*ids), GFP_KERNEL);
+ if (!ids)
+ goto out_free_clktab;
+
+ clks = kzalloc(num * sizeof(*clks), GFP_KERNEL);
+ if (!clks)
+ goto out_free_ids;
+
+ for (i = 0; i num; i++) {
+ of_property_read_u32_index(np, ids, i, id);
+ if (id = SYSTEM_MAX)
+ goto out_free_clks;
+ of_property_read_string_index(np, clock-output-names,
+
[RFC PATCH 07/50] ARM: at91: add PMC programmable clocks
This is the at91 programmable clocks implementation using common clk
framework.
A programmable clock is a clock which can be exported on a given pin to clock
external devices.
Each programmable clock is given an id (from 0 to 8).
The number of available programmable clocks depends on the SoC you're using.
Programmable clock driver only implements the clock setting (clock rate and
parent setting). It must be chained to a system clock in order to
enable/disable the generated clock.
The PCKX pins used to output the clock signals must be assigned to the
appropriate peripheral (see atmel's datasheets).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
drivers/clk/at91/Makefile |2 +
drivers/clk/at91/clk-programmable.c | 370 +++
include/linux/clk/at91.h| 18 ++
3 files changed, 390 insertions(+)
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 3e2a670..2d7c119 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -4,3 +4,5 @@
obj-y += clk-main.o clk-pll.o clk-plldiv.o clk-master.o
obj-y += clk-system.o clk-peripheral.o
+
+obj-$(CONFIG_AT91_PROGRAMMABLE_CLOCKS) += clk-programmable.o
diff --git a/drivers/clk/at91/clk-programmable.c
b/drivers/clk/at91/clk-programmable.c
new file mode 100644
index 000..e4b1fb0
--- /dev/null
+++ b/drivers/clk/at91/clk-programmable.c
@@ -0,0 +1,370 @@
+/*
+ * drivers/clk/at91/clk-programmable.c
+ *
+ * Copyright (C) 2013 Boris BREZILLON b.brezil...@overkiz.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/clk/at91.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/io.h
+
+#define PROG_SOURCE_MAX5
+#define PROG_MAX 8
+
+#define to_clk_programmable(hw) container_of(hw, struct clk_programmable, hw)
+struct clk_programmable {
+ struct clk_hw hw;
+ u8 id;
+ u8 css;
+ u8 pres;
+ u8 slckmck;
+ struct clk_programmable_layout *layout;
+};
+
+static int clk_programmable_prepare(struct clk_hw *hw)
+{
+ u32 tmp;
+ struct clk_programmable *prog = to_clk_programmable(hw);
+ struct clk_programmable_layout *layout = prog-layout;
+ tmp = prog-css | (prog-pres layout-pres_shift);
+ if (layout-have_slck_mck prog-slckmck)
+ tmp |= 1 8;
+ at91_pmc_write(AT91_PMC_PCKR(prog-id), tmp);
+ while (!(at91_pmc_read(AT91_PMC_SR) (AT91_PMC_PCK0RDY prog-id)))
+ ;
+ return 0;
+}
+
+static int clk_programmable_is_prepared(struct clk_hw *hw)
+{
+ struct clk_programmable *prog = to_clk_programmable(hw);
+ return !!(at91_pmc_read(AT91_PMC_SR) (AT91_PMC_PCK0RDY prog-id));
+}
+
+static unsigned long clk_programmable_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ u32 tmp;
+ struct clk_programmable *prog = to_clk_programmable(hw);
+ struct clk_programmable_layout *layout = prog-layout;
+ tmp = at91_pmc_read(AT91_PMC_PCKR(prog-id));
+ prog-pres = (tmp layout-pres_shift) 0x7;
+ return parent_rate prog-pres;
+}
+
+static long clk_programmable_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ unsigned long best_rate = *parent_rate;
+ unsigned long best_diff;
+ unsigned long new_diff;
+ unsigned long cur_rate;
+ int shift = shift;
+
+ if (rate *parent_rate)
+ return *parent_rate;
+ else
+ best_diff = *parent_rate - rate;
+
+ if (!best_diff)
+ return best_rate;
+
+ for (shift = 1; shift 7; shift++) {
+ cur_rate = *parent_rate shift;
+
+ if (cur_rate rate)
+ new_diff = cur_rate - rate;
+ else
+ new_diff = rate - cur_rate;
+
+ if (!new_diff)
+ return cur_rate;
+
+ if (new_diff best_diff) {
+ best_diff = new_diff;
+ best_rate = cur_rate;
+ }
+
+ if (rate cur_rate)
+ break;
+
+ }
+
+ return best_rate;
+}
+
+static int clk_programmable_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct clk_programmable *prog = to_clk_programmable(hw);
+ struct clk_programmable_layout *layout = prog-layout;
+ if (index layout-css_mask) {
+ if (index == 4 layout-have_slck_mck) {
+ prog-css = 0;
+ prog-slckmck = 1;
+ return 0;
+ } else
+
RE: Scaling problem with a lot of AF_PACKET sockets on different interfaces
On Fri, 2013-06-07 at 15:09 +0100, David Laight wrote: Looks like the ptype_base[] should be per 'dev'? Or just put entries where ptype-dev != null_or_dev on a per-interface list and do two searches? Yes, but then we would have two searches instead of one in fast path. Usually it would be empty - so the search would be very quick! quick + quick + quick + quick + quick == not so quick ;) Plus adding another code for /proc/net/packet Plus adding the xmit side (AF_PACKET captures receive and xmit) -- 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/
[RFC PATCH 06/50] ARM: at91: add PMC peripheral clocks
This is the at91 peripheral clock implementation using common clk framework.
Almost all peripherals provided by an at91 SoC need a clock to work properly.
This clock is enabled/disabled using PCER/PCDR resgisters.
Each peripheral is given an id (see atmel's datasheets) which is used as bit
position in SCER/SCDR registers.
Some new SoCs (at91sam9x5 and sama5d3) provide a new register (PCR) where you
can configure the peripheral clock as a division of the master clock.
This will help reducing the peripherals power comsumption.
This patch fixes erronous AT91_PMC_PCR_DIV values.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
drivers/clk/at91/Makefile |2 +-
drivers/clk/at91/clk-peripheral.c | 376 +
include/linux/clk/at91.h | 14 +-
3 files changed, 388 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 13e5714..3e2a670 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -3,4 +3,4 @@
#
obj-y += clk-main.o clk-pll.o clk-plldiv.o clk-master.o
-obj-y += clk-system.o
+obj-y += clk-system.o clk-peripheral.o
diff --git a/drivers/clk/at91/clk-peripheral.c
b/drivers/clk/at91/clk-peripheral.c
new file mode 100644
index 000..2fc66b9
--- /dev/null
+++ b/drivers/clk/at91/clk-peripheral.c
@@ -0,0 +1,376 @@
+/*
+ * drivers/clk/at91/clk-peripheral.c
+ *
+ * Copyright (C) 2013 Boris BREZILLON b.brezil...@overkiz.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/clk/at91.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/io.h
+
+#define PERIPHERAL_MAX 64
+
+#define PERIPHERAL_AT91RM9200 0
+#define PERIPHERAL_AT91SAM9X5 1
+
+#define to_clk_peripheral(hw) container_of(hw, struct clk_peripheral, hw)
+struct clk_peripheral {
+ struct clk_hw hw;
+ u32 id;
+};
+
+#define to_clk_sam9x5_peripheral(hw) \
+ container_of(hw, struct clk_sam9x5_peripheral, hw)
+struct clk_sam9x5_peripheral {
+ struct clk_hw hw;
+ u32 id;
+ u8 div;
+ u8 have_div_support;
+};
+
+static int clk_peripheral_enable(struct clk_hw *hw)
+{
+ struct clk_peripheral *periph = to_clk_peripheral(hw);
+ int offset = AT91_PMC_PCER;
+ if (periph-id 2)
+ return 0;
+ if (periph-id 31)
+ offset = AT91_PMC_PCER1;
+ at91_pmc_write(offset, 1 (periph-id 31));
+ return 0;
+}
+
+static void clk_peripheral_disable(struct clk_hw *hw)
+{
+ struct clk_peripheral *periph = to_clk_peripheral(hw);
+ int offset = AT91_PMC_PCDR;
+ if (periph-id 2)
+ return;
+ if (periph-id 31)
+ offset = AT91_PMC_PCDR1;
+ at91_pmc_write(offset, 1 (periph-id 31));
+}
+
+static int clk_peripheral_is_enabled(struct clk_hw *hw)
+{
+ struct clk_peripheral *periph = to_clk_peripheral(hw);
+ int offset = AT91_PMC_PCSR;
+ if (periph-id 2)
+ return 1;
+ if (periph-id 31)
+ offset = AT91_PMC_PCSR1;
+ return !!(at91_pmc_read(offset) (1 (periph-id 31)));
+}
+
+static const struct clk_ops peripheral_ops = {
+ .enable = clk_peripheral_enable,
+ .disable = clk_peripheral_disable,
+ .is_enabled = clk_peripheral_is_enabled,
+};
+
+struct clk * __init at91_clk_register_peripheral(const char *name,
+const char *parent_name,
+u32 id)
+{
+ struct clk_peripheral *periph;
+ struct clk *clk = NULL;
+ struct clk_init_data init;
+
+ id = 31;
+ periph = kzalloc(sizeof(*periph), GFP_KERNEL);
+ if (!periph)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.ops = peripheral_ops;
+ init.parent_names = (parent_name ? parent_name : NULL);
+ init.num_parents = (parent_name ? 1 : 0);
+ init.flags = 0;
+
+ periph-id = id;
+ periph-hw.init = init;
+
+ clk = clk_register(NULL, periph-hw);
+ if (IS_ERR(clk))
+ kfree(periph);
+
+ return clk;
+}
+
+static int clk_sam9x5_peripheral_enable(struct clk_hw *hw)
+{
+ struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
+ if (periph-id 2)
+ return 0;
+ at91_pmc_write(AT91_PMC_PCR,
+ (periph-id AT91_PMC_PCR_PID) |
+ AT91_PMC_PCR_CMD |
+ AT91_PMC_PCR_DIV(periph-div) |
+ AT91_PMC_PCR_EN);
+ return 0;
+}
+
+static void clk_sam9x5_peripheral_disable(struct clk_hw *hw)
+{
+ struct clk_sam9x5_peripheral *periph =
Re: [PATCH v3, part1 04/10] PCI: mark pci_scan_bus_parented() as __deprecated
On Fri, Jun 07, 2013 at 12:32:28AM +0800, Jiang Liu wrote:
On Thu 06 Jun 2013 04:04:36 AM CST, Bjorn Helgaas wrote:
[+cc Konrad, Jeremy, xen-devel (users of interface you're deprecating)]
On Sat, May 25, 2013 at 7:48 AM, Jiang Liu liu...@gmail.com wrote:
Mark pci_scan_bus_parented() as __deprecated and clean up outdated
comments.
Signed-off-by: Jiang Liu jiang@huawei.com
Cc: Chris Metcalf cmetc...@tilera.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Thierry Reding thierry.red...@avionic-design.de
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
arch/tile/kernel/pci.c | 3 ---
include/linux/pci.h| 4 ++--
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/tile/kernel/pci.c b/arch/tile/kernel/pci.c
index 67237d3..936e087 100644
--- a/arch/tile/kernel/pci.c
+++ b/arch/tile/kernel/pci.c
@@ -309,9 +309,6 @@ int __init pcibios_init(void)
*
* It reads the PCI tree for this bus into the
Linux
* data structures.
-*
-* This is inlined in linux/pci.h and calls into
-* pci_scan_bus_parented() in probe.c.
*/
pci_add_resource(resources, ioport_resource);
pci_add_resource(resources, iomem_resource);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index b0f4a82..7b23fa0 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -720,8 +720,8 @@ void pcibios_bus_to_resource(struct pci_dev *dev,
struct resource *res,
void pcibios_scan_specific_bus(int busn);
struct pci_bus *pci_find_bus(int domain, int busnr);
void pci_bus_add_devices(const struct pci_bus *bus);
-struct pci_bus *pci_scan_bus_parented(struct device *parent, int bus,
- struct pci_ops *ops, void *sysdata);
+struct pci_bus * __deprecated pci_scan_bus_parented(struct device *parent,
+ int bus, struct pci_ops *ops, void *sysdata);
struct pci_bus *pci_scan_bus(int bus, struct pci_ops *ops, void *sysdata);
struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
struct pci_ops *ops, void *sysdata,
I think this patch is a good idea, but I think we need to change the
only existing user of pci_scan_bus_parented() (pcifront_scan_root() in
drivers/pci/xen-pcifront.c) at the same time, so xen doesn't start
getting build warnings. The deprecation warnings are really intended
for out-of-tree users that we aren't able to fix ourselves.
I'm getting this series queued up in
http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/jiang-bus-lock-v3,
so if you want to send a patch just for xen, I can fold that in.
Bjorn
Hi Bjorn,
I have posted a big patch for that, but still need help from
Xen experts to review it.
Please refer to https://patchwork.kernel.org/patch/2578551/
Hm, I seem to get:
/home/konrad/linux/drivers/pci/xen-pcifront.c: In function
‘pcifront_free_roots’:
/home/konrad/linux/drivers/pci/xen-pcifront.c:559: error: implicit declaration
of function ‘for_each_pci_root_bus’
/home/konrad/linux/drivers/pci/xen-pcifront.c:559: error: expected ‘;’ before
‘{’ token
/home/konrad/linux/drivers/pci/xen-pcifront.c:554: warning: unused variable ‘sd’
with it? Is there an up-to-date patch?
I have these in my tree:
311db40 PCI, xen-pcifront: use new PCI interfaces to simplify implementation
4079fee Merge remote-tracking branch 'bjorn/pci/jiang-bus-lock-v3' into testing
ddb7c6b PCI: Hide remove and rescan sysfs interfaces for SR-IOV virtual
functions
f5cfa3a PCI: Simplify IOV implementation and fix reference count races
28b4f07 PCI: Drop redundant setting of bus-is_added in virtfn_add_bus()
442655a unicore32/PCI: Remove redundant call of pci_bus_add_devices()
defd601 m68k/PCI: Remove redundant call of pci_bus_add_devices()
340e3fb PCI: Make PCI host bridge/bus creating and destroying logic symmetric
c7025f7 ia64/PCI: Clean up pci_scan_root_bus() usage
c1f41ce PCI: Mark pci_scan_bus_parented() as __deprecated
13e5057 PCI: Convert alloc_pci_dev(void) to pci_alloc_dev(bus)
007042a PCI: Introduce pci_alloc_dev(struct pci_bus*) to replace alloc_pci_dev()
fe830ef PCI: Introduce pci_bus_{get|put}() to manage PCI bus reference count
Also oddly enough your SoB does not match your Author. Here is
what git shows:
=== Author: Jiang Liu liu...@gmail.com 2013-05-25 09:48:38
=== Signed-off-by: Jiang Liu jiang@huawei.com
You can add in the gmail an new 'email alias' so that the emails will
look as they come from your huawei address.
--
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
[RFC PATCH 08/50] ARM: at91: add PMC utmi clock
This is the at91 utmi clock implementation using common clk framework.
This clock is a pll with a fixed factor (x40).
It is used as a source for usb clock.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
arch/arm/mach-at91/Kconfig |7 +++
drivers/clk/at91/Makefile |1 +
drivers/clk/at91/clk-utmi.c | 114 +++
include/linux/clk/at91.h|4 ++
4 files changed, 126 insertions(+)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 0280238..a4d442d 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -1,5 +1,8 @@
if ARCH_AT91
+config HAVE_AT91_UTMI
+ bool
+
config HAVE_AT91_DBGU0
bool
@@ -65,6 +68,7 @@ config SOC_SAMA5D3
select SOC_SAMA5
select HAVE_FB_ATMEL
select HAVE_AT91_DBGU1
+ select HAVE_AT91_UTMI
help
Select this if you are using one of Atmel's SAMA5D3 family SoC.
This support covers SAMA5D31, SAMA5D33, SAMA5D34, SAMA5D35.
@@ -106,12 +110,14 @@ config SOC_AT91SAM9RL
select HAVE_AT91_DBGU0
select HAVE_FB_ATMEL
select SOC_AT91SAM9
+ select HAVE_AT91_UTMI
config SOC_AT91SAM9G45
bool AT91SAM9G45 or AT91SAM9M10 families
select HAVE_AT91_DBGU1
select HAVE_FB_ATMEL
select SOC_AT91SAM9
+ select HAVE_AT91_UTMI
help
Select this if you are using one of Atmel's AT91SAM9G45 family SoC.
This support covers AT91SAM9G45, AT91SAM9G46, AT91SAM9M10 and
AT91SAM9M11.
@@ -121,6 +127,7 @@ config SOC_AT91SAM9X5
select HAVE_AT91_DBGU0
select HAVE_FB_ATMEL
select SOC_AT91SAM9
+ select HAVE_AT91_UTMI
help
Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
This means that your SAM9 name finishes with a '5' (except if it is
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 2d7c119..76d09f0 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -6,3 +6,4 @@ obj-y += clk-main.o clk-pll.o clk-plldiv.o clk-master.o
obj-y += clk-system.o clk-peripheral.o
obj-$(CONFIG_AT91_PROGRAMMABLE_CLOCKS) += clk-programmable.o
+obj-$(CONFIG_HAVE_AT91_UTMI) += clk-utmi.o
diff --git a/drivers/clk/at91/clk-utmi.c b/drivers/clk/at91/clk-utmi.c
new file mode 100644
index 000..c0dd596
--- /dev/null
+++ b/drivers/clk/at91/clk-utmi.c
@@ -0,0 +1,114 @@
+/*
+ * drivers/clk/at91/clk-utmi.c
+ *
+ * Copyright (C) 2013 Boris BREZILLON b.brezil...@overkiz.com
+ *
+ * This utmiram is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/clk/at91.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/io.h
+
+#define to_clk_utmi(hw) container_of(hw, struct clk_utmi, hw)
+
+struct clk_utmi {
+ struct clk_hw hw;
+};
+
+static int clk_utmi_prepare(struct clk_hw *hw)
+{
+ u32 tmp = at91_pmc_read(AT91_CKGR_UCKR) | AT91_PMC_UPLLEN |
+ AT91_PMC_UPLLCOUNT;
+ at91_pmc_write(AT91_CKGR_UCKR, tmp);
+ while (!(at91_pmc_read(AT91_PMC_SR) AT91_PMC_LOCKU))
+ ;
+ return 0;
+}
+
+static int clk_utmi_is_prepared(struct clk_hw *hw)
+{
+ return !!(at91_pmc_read(AT91_PMC_SR) AT91_PMC_LOCKU);
+}
+
+static void clk_utmi_disable(struct clk_hw *hw)
+{
+ u32 tmp = at91_pmc_read(AT91_CKGR_UCKR) ~AT91_PMC_UPLLEN;
+ at91_pmc_write(AT91_CKGR_UCKR, tmp);
+}
+
+static unsigned long clk_utmi_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ return parent_rate * 40;
+}
+
+static const struct clk_ops utmi_ops = {
+ .prepare = clk_utmi_prepare,
+ .is_prepared = clk_utmi_is_prepared,
+ .disable = clk_utmi_disable,
+ .recalc_rate = clk_utmi_recalc_rate,
+};
+
+struct clk * __init
+at91_clk_register_utmi(const char *name, const char *parent_name)
+{
+ struct clk_utmi *utmi;
+ struct clk *clk = NULL;
+ struct clk_init_data init;
+
+ utmi = kzalloc(sizeof(*utmi), GFP_KERNEL);
+ if (!utmi)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.ops = utmi_ops;
+ init.parent_names = parent_name ? parent_name : NULL;
+ init.num_parents = parent_name ? 1 : 0;
+ init.flags = CLK_SET_RATE_GATE;
+
+ utmi-hw.init = init;
+
+ clk = clk_register(NULL, utmi-hw);
+
+ if (IS_ERR(clk))
+ kfree(utmi);
+
+ return clk;
+}
+
+#if defined(CONFIG_OF)
+static void __init
+of_at91_clk_utmi_setup(struct device_node *np)
+{
+ struct clk *clk;
+ const char *parent_name;
+ const char *name = np-name;
+
+ parent_name =
[RFC PATCH 09/50] ARM: at91: add PMC usb clock
This is the at91 usb clock implementation using common clk framework.
This clock is used to clock usb ports (ohci, ehci and udc).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
arch/arm/mach-at91/Kconfig | 11 ++
drivers/clk/at91/Makefile |1 +
drivers/clk/at91/clk-usb.c | 303
include/linux/clk/at91.h |9 ++
4 files changed, 324 insertions(+)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index a4d442d..ce4851d 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -3,6 +3,9 @@ if ARCH_AT91
config HAVE_AT91_UTMI
bool
+config HAVE_AT91_USB_CLK
+ bool
+
config HAVE_AT91_DBGU0
bool
@@ -69,6 +72,7 @@ config SOC_SAMA5D3
select HAVE_FB_ATMEL
select HAVE_AT91_DBGU1
select HAVE_AT91_UTMI
+ select HAVE_AT91_USB_CLK
help
Select this if you are using one of Atmel's SAMA5D3 family SoC.
This support covers SAMA5D31, SAMA5D33, SAMA5D34, SAMA5D35.
@@ -82,11 +86,13 @@ config SOC_AT91RM9200
select HAVE_AT91_DBGU0
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
+ select HAVE_AT91_USB_CLK
config SOC_AT91SAM9260
bool AT91SAM9260, AT91SAM9XE or AT91SAM9G20
select HAVE_AT91_DBGU0
select SOC_AT91SAM9
+ select HAVE_AT91_USB_CLK
help
Select this if you are using one of Atmel's AT91SAM9260, AT91SAM9XE
or AT91SAM9G20 SoC.
@@ -96,6 +102,7 @@ config SOC_AT91SAM9261
select HAVE_AT91_DBGU0
select HAVE_FB_ATMEL
select SOC_AT91SAM9
+ select HAVE_AT91_USB_CLK
help
Select this if you are using one of Atmel's AT91SAM9261 or
AT91SAM9G10 SoC.
@@ -104,6 +111,7 @@ config SOC_AT91SAM9263
select HAVE_AT91_DBGU1
select HAVE_FB_ATMEL
select SOC_AT91SAM9
+ select HAVE_AT91_USB_CLK
config SOC_AT91SAM9RL
bool AT91SAM9RL
@@ -118,6 +126,7 @@ config SOC_AT91SAM9G45
select HAVE_FB_ATMEL
select SOC_AT91SAM9
select HAVE_AT91_UTMI
+ select HAVE_AT91_USB_CLK
help
Select this if you are using one of Atmel's AT91SAM9G45 family SoC.
This support covers AT91SAM9G45, AT91SAM9G46, AT91SAM9M10 and
AT91SAM9M11.
@@ -128,6 +137,7 @@ config SOC_AT91SAM9X5
select HAVE_FB_ATMEL
select SOC_AT91SAM9
select HAVE_AT91_UTMI
+ select HAVE_AT91_USB_CLK
help
Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
This means that your SAM9 name finishes with a '5' (except if it is
@@ -140,6 +150,7 @@ config SOC_AT91SAM9N12
select HAVE_AT91_DBGU0
select HAVE_FB_ATMEL
select SOC_AT91SAM9
+ select HAVE_AT91_USB_CLK
help
Select this if you are using Atmel's AT91SAM9N12 SoC.
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 76d09f0..bbfd245 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -7,3 +7,4 @@ obj-y += clk-system.o clk-peripheral.o
obj-$(CONFIG_AT91_PROGRAMMABLE_CLOCKS) += clk-programmable.o
obj-$(CONFIG_HAVE_AT91_UTMI) += clk-utmi.o
+obj-$(CONFIG_HAVE_AT91_USB_CLK)+= clk-usb.o
diff --git a/drivers/clk/at91/clk-usb.c b/drivers/clk/at91/clk-usb.c
new file mode 100644
index 000..008372e
--- /dev/null
+++ b/drivers/clk/at91/clk-usb.c
@@ -0,0 +1,303 @@
+/*
+ * drivers/clk/at91/clk-usb.c
+ *
+ * Copyright (C) 2013 Boris BREZILLON b.brezil...@overkiz.com
+ *
+ * This usbram is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/clk/at91.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/io.h
+
+#define USB_SOURCE_MAX 2
+
+#define to_at91sam9x5_clk_usb(hw) \
+ container_of(hw, struct at91sam9x5_clk_usb, hw)
+struct at91sam9x5_clk_usb {
+ struct clk_hw hw;
+ u8 usbs0_unused; /* sam9n12 uses usbs0 to disable usb clock */
+};
+
+#define to_at91rm9200_clk_usb(hw) \
+ container_of(hw, struct at91rm9200_clk_usb, hw)
+struct at91rm9200_clk_usb {
+ struct clk_hw hw;
+ u32 divisors[4];
+};
+
+static unsigned long at91sam9x5_clk_usb_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ u32 tmp;
+ u8 usbdiv;
+ tmp = at91_pmc_read(AT91_PMC_USB);
+ usbdiv = (tmp AT91_PMC_OHCIUSBDIV) 8;
+ return parent_rate / (usbdiv + 1);
+}
+
+static long at91sam9x5_clk_usb_round_rate(struct clk_hw *hw, unsigned long
rate,
+ unsigned long *parent_rate)
+{
+ unsigned long div;
+ unsigned long bestrate;
+ unsigned
Re: [PATCH 2/5] cpufreq:boost: Add support for software based CPU frequency boost
Hi Viresh,
On 6 June 2013 17:19, Lukasz Majewski l.majew...@samsung.com wrote:
On 6 June 2013 12:37, Lukasz Majewski l.majew...@samsung.com
wrote:
cpufreq_driver-boost-attr))
Why is this required? Why do we want platforms to add some files
in sysfs?
There are two kinds of attributes, which are exported by boost:
1. global boost (/sys/devices/system/cpu/cpufreq/boost)
2. attributes describing cpufreq abilities when boost is available
(/sys/devices/syste/cpu/cpu0/cpufreq/):
- scaling_boost_frequencies - which will show over clocked
frequencies
- the scaling_available_frequencies will also display
boosted frequency (when boost enabled)
Information from 2. is cpufreq_driver dependent. And that
information shouldn't been displayed when boost is not available
This is not how I wanted this to be coded. Lets keep things simple:
- Implement it in the way cpufreq_freq_attr_scaling_available_freqs
is implemented. And then drivers which need to see boost freqs
can add it in their attr.
I've added scaling_boost_frequencies to cpufreq_driver attr.
However, I would keep the boost attributes definition in the freq_table
file (as I've proposed in my patch).
+ policy-boost = cpufreq_boost = cpufreq_driver-boost;
Why are we copying same pointer to policy-boost? Driver is
passing pointer to a single memory location, just save it globally.
This needs some explanation.
The sysfs entry presented at [1] doesn't bring any useful
information to reuse (like *policy). For this reason the global
cpufreq_boost pointer is needed.
However to efficiently manage the boost, it is necessary to keep per
policy pointer to the only struct cpufreq_boost instance (defined at
cpufreq_driver code).
No we don't need to screw struct cpufreq_policy with it.
Just need two variables here:
- cpufreq_driver-boost: If driver supports boost or not.
This will be done as above.
- If above is true then a global bool variable that will say boost is
enabled from sysfs or not.
One global flag will be defined at cpufreq.c to indicate if global
boost sysfs attr has been created.
+ /* disable boost for newly created policy - as we e.g.
change
+ governor */
+ policy-boost-status = CPUFREQ_BOOST_DIS;
Drivers supporting boost may want boost to be enabled by default,
maybe without any sysfs calls.
This can be done by setting the struct cpufreq_boost status field to
CPUFREQ_BOOST_EN at cpufreq driver code (when boost structure is
defined)
This really isn't driver dependent.. But user dependent. Maybe lets
keep it disabled and people can enable it from sysfs.
The cpufreq_driver struct will have boost_en field. This will allow
keep boost state (it is similar to global boost_enable at
acpi-cpufreq.c).
Why do we need to maintain a list of boost here? notifiers?
complex :(
Notifier is needed to disable boost when policy is changed (for
example when we change from ondemand/lab to performance governor).
I wanted to avoid the situation when boost stays enabled across
different governors.
The list of in system available policies is defined to allow boost
enable/disable for all policies available (by changing for example
policy-max field).
If we decide, that we will support only one policy (as it is now at
e.g. Exynos), the list is unnecessary here.
What we discussed last in your earlier patchset was:
- Keep boost feature separate from governors.
Ok.
- If it is enabled, then any governor can use it (if they want).
Ok, lets do it in this way
- Lets not disable it if governor is changed. user must do it
explicitly.
Ok, agree (notifier removed).
+static int cpufreq_frequency_table_skip_boost(struct
cpufreq_policy *policy,
+ unsigned int index)
+{
+ if (index == CPUFREQ_BOOST)
+ if (!policy-boost ||
This shouldn't be true. If index has got CPUFREQ_BOOST, then driver
has to support boost.
Correct me if I'm wrong here, but in my understanding the boost
shall be only supported when both CPUFREQ_BOOST index is defined in
a freq_table and boost.state = CPUFREQ_BOOST_EN is set.
Setting of CPUFREQ_BOOST shouldn't by default allow to use over
clocking frequency.
For cpufreq core boost is enabled as soon as cpufreq_driver-boost is
true. We can have additional checks to see if there is atleast one
boost frequency but can skip this too.
Checks are needed to read max_normal frequency and max boost frequency
from frequency table.
In exynos cpufreq_driver-init() I will disable boost.
why do we need this?
To evaluate the maximal boost frequency from the frequency table.
It is then used as a delimiter (when LAB cooperates with thermal
framework).
Introduce this with LAB then.. Lets keep it as simple as possible for
now. One step at a time.
[RFC PATCH 11/50] ARM: at91: add PMC clk device tree binding doc.
This is the documentation of the dt bindings used by at91 clks.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
.../devicetree/bindings/clock/at91-clock.txt | 247
1 file changed, 247 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt
b/Documentation/devicetree/bindings/clock/at91-clock.txt
new file mode 100644
index 000..63c5d16
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
@@ -0,0 +1,247 @@
+Device Tree Clock bindings for arch-at91
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of the following:
+ atmel,at91rm9200-clk-main:
+ at91 main oscillator
+
+ atmel,at91rm9200-clk-master or
+ atmel,at91sam9x5-clk-master:
+ at91 master clock
+
+ atmel,at91sam9x5-clk-peripheral or
+ atmel,at91rm9200-clk-peripheral:
+ at91 peripheral clocks
+
+ atmel,at91rm9200-clk-pll or
+ atmel,at91sam9g45-clk-pll or
+ atmel,at91sam9g20-clk-pllb or
+ atmel,sama5d3-clk-pll:
+ at91 pll clocks
+
+ atmel,at91sam9x5-clk-plldiv:
+ at91 plla divisor
+
+ atmel,at91rm9200-clk-programmable or
+ atmel,at91sam9g45-clk-programmable or
+ atmel,at91sam9x5-clk-programmable:
+ at91 programmable clocks
+
+ atmel,at91sam9x5-clk-smd:
+ at91 SMD (Soft Modem) clock
+
+ atmel,at91rm9200-clk-system:
+ at91 system clocks
+
+ atmel,at91rm9200-clk-usb or
+ atmel,at91sam9x5-clk-usb:
+ at91 usb clock
+
+ atmel,at91sam9x5-clk-utmi:
+ at91 utmi clock
+
+
+Required properties for main clock:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks (optional if clock-frequency is provided) : shall be the slow clock
+ phandle. This clock is used to compute the main clock rate if
+ clock-frequency is not provided.
+- clock-frequency: the main oscillator frequency.Prefer the use of
+ clock-frequency over automatic clock rate computation.
+
+For example:
+ main: mainck {
+ compatible = atmel,at91rm9200-clk-main;
+ #clock-cells = 0;
+ clocks = ck32k;
+ clock-frequency = 18432000;
+ };
+
+Required properties for master clock:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the master clock sources (see atmel datasheet) phandles.
+ e.g. ck32k, main, plla, pllb.
+- characteristics : device tree node describing master clock characteristics.
+ You can find these characteristics in atmel's SoC datasheets.
+ * output : minimum and maximum clock frequency (two u32 fields).
+ e.g. output = 0 13300; = 0 to 133MHz.
+ * divisors : master clock divisors table (four u32 fields).
+ 0 = reserved value.
+ e.g. divisors = 1 2 4 6;
+ * have-div3-pres : some SoC use the reserved value 7 in the PRES field
+ as CLOCK_DIV3 (e.g sam9x5).
+
+For example:
+ mck: mck {
+ compatible = atmel,at91rm9200-clk-master;
+ #clock-cells = 0;
+ characteristics = {
+ output = 0 13300;
+ divisors = 1 2 4 0;
+ };
+ };
+
+Required properties for peripheral clocks:
+- #clock-cells : from common clock binding; shall be set to 1. The second cell
+ is used to encode the peripheral id. Peripheral ids are defined in
+ atmel's SoC datasheets.
+- clocks : shall be the master clock phandle.
+ e.g. clocks = mck;
+- ids : peripheral ids (u32 array).
+- clock-output-names : name of clocks. These are the name used during clock
+ registration.
+- default-divisors (optional, only available for
+ atmel,at91sam9x5-clk-peripheral) : sam9x5 and sama5d3 SoC provides
+ configurable peripheral clock divisors. If you define this property
+ (u32 array), the default divisor will be applied when enabling
+ peripheral clock. If not provided the peripheral clock is not divided.
+
+For example:
+ periph: periphck {
+ compatible = atmel,at91sam9x5-clk-peripheral;
+ #clock-cells = 1;
+ clocks = mck;
+ ids = 2 6 7;
+ clock-output-names = pioA_clk, pioB_clk, pioB_clk;
+ default-divisors = 1 2 2;
+ };
+
+
+Required properties for pll clocks:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the main clock phandle.
+- id : pll id
+ * 0 = plla
+ * 1 = pllb
+- characteristics : device tree node describing pll clock characteristics.
+ You can find these characteristics in atmel's SoC datasheets.
+ * input : minimum and maximum source clock
Re: [PATCH 2/5] cpufreq:boost: Add support for software based CPU frequency boost
On 7 June 2013 20:04, Lukasz Majewski l.majew...@samsung.com wrote: After refactoring the code. I admit, that we shall embed the struct cpu_boost fields directly to the coufreq_driver. There is no point to create structure with 2 fields. Great!! I will wait for your next version. -- 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 v1] MFD: Change TWL6025 references to TWL6032
On 2013-06-07 15:36, Mark Brown wrote: On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote: From: Graeme Gregory g...@slimlogic.co.uk The TWL6025 was never released beyond sample form and was replaced by the PhoenixLite range of chips - TWL6032. Change the references to reference the TWL6032 class and name the registers to twl6032 in line with an actual released chip name to avoid confusion. Currently there is no users of TWL6025 in the code. Given that the chip exists even if not widely distributed it seems as well to keep the twl6025 references in there at least in the device ID table - it won't do any harm to people using the twl6032 name and might help someone who happens to pick up an old board for whatever reason. I do not think any old boards exist, it really was a limited run! Graeme -- 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/53] Input: atmel_mxt_ts - Add memory access interface via sysfs
Greg KH wrote: On Wed, Jun 05, 2013 at 06:37:03PM +0100, Nick Dyer wrote: Atmel maXTouch chips can be addressed via an Object Based Protocol which defines how i2c registers are mapped to different functions within the chips. This interface exposes the register map and allows user-space utilities to inspect and alter object configuration, and to view diagnostic data, while the device is running. Signed-off-by: Nick Dyer nick.d...@itdev.co.uk Acked-by: Benson Leung ble...@chromium.org --- drivers/input/touchscreen/atmel_mxt_ts.c | 82 ++ 1 file changed, 82 insertions(+) Whenever you add/remove/modify sysfs files, you also need a Documentation/ABI/ update as well. Please include that. Will do. I think I should also document the existing sysfs files which are missing docs. -- 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: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
SoC vendors are free to join the discussion, and many SoC vendors are part of the kernel community, so calling this unilateral is plain wrong. you're free to believe that, vladimir. i've explained why that hasn't happened, in prior messages. can we move forward, please? I prefer it if the vladimir troll (and fellow trolls) make requests for one of us to make or do something instead of constantly whining and wasting time. After all we are attached to funds and resources ready to deploy if something sounds a good idea and gets a vote. To vladimir - please put your thoughts in a blog where it belongs. If its important, I'm sure others would offer comment and take you up on your thoughts.
[RFC PATCH 10/50] ARM: at91: add PMC smd clock
This is the at91 smd (Soft Modem) clock implementation using common clk
framework.
Not used by any driver right now.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
arch/arm/mach-at91/Kconfig |5 ++
drivers/clk/at91/Makefile |1 +
drivers/clk/at91/clk-smd.c | 157
3 files changed, 163 insertions(+)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index ce4851d..8032871 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -27,6 +27,9 @@ config AT91_SAM9G45_RESET
config AT91_SAM9_TIME
bool
+config HAVE_AT91_SMD
+ bool
+
config SOC_AT91SAM9
bool
select AT91_SAM9_TIME
@@ -72,6 +75,7 @@ config SOC_SAMA5D3
select HAVE_FB_ATMEL
select HAVE_AT91_DBGU1
select HAVE_AT91_UTMI
+ select HAVE_AT91_SMD
select HAVE_AT91_USB_CLK
help
Select this if you are using one of Atmel's SAMA5D3 family SoC.
@@ -137,6 +141,7 @@ config SOC_AT91SAM9X5
select HAVE_FB_ATMEL
select SOC_AT91SAM9
select HAVE_AT91_UTMI
+ select HAVE_AT91_SMD
select HAVE_AT91_USB_CLK
help
Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index bbfd245..7206f4c 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -8,3 +8,4 @@ obj-y += clk-system.o clk-peripheral.o
obj-$(CONFIG_AT91_PROGRAMMABLE_CLOCKS) += clk-programmable.o
obj-$(CONFIG_HAVE_AT91_UTMI) += clk-utmi.o
obj-$(CONFIG_HAVE_AT91_USB_CLK)+= clk-usb.o
+obj-$(CONFIG_HAVE_AT91_SMD)+= clk-smd.o
diff --git a/drivers/clk/at91/clk-smd.c b/drivers/clk/at91/clk-smd.c
new file mode 100644
index 000..61bd8a5
--- /dev/null
+++ b/drivers/clk/at91/clk-smd.c
@@ -0,0 +1,157 @@
+/*
+ * drivers/clk/at91/clk-smd.c
+ *
+ * Copyright (C) 2013 Boris BREZILLON b.brezil...@overkiz.com
+ *
+ * This smdram is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/clk/at91.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/io.h
+
+#define SMD_SOURCE_MAX 2
+
+#define to_at91sam9x5_clk_smd(hw) \
+ container_of(hw, struct at91sam9x5_clk_smd, hw)
+struct at91sam9x5_clk_smd {
+ struct clk_hw hw;
+};
+
+static unsigned long at91sam9x5_clk_smd_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ u32 tmp;
+ u8 smddiv;
+ tmp = at91_pmc_read(AT91_PMC_SMD);
+ smddiv = (tmp AT91_PMC_SMD_DIV) 8;
+ return parent_rate / (smddiv + 1);
+}
+
+static long at91sam9x5_clk_smd_round_rate(struct clk_hw *hw, unsigned long
rate,
+ unsigned long *parent_rate)
+{
+ unsigned long div;
+ unsigned long bestrate;
+ unsigned long tmp;
+
+ if (rate = *parent_rate)
+ return *parent_rate;
+
+ div = *parent_rate / rate;
+ if (div 15)
+ return *parent_rate / 16;
+
+ bestrate = *parent_rate / div;
+ tmp = *parent_rate / (div + 1);
+ if (bestrate - rate rate - tmp)
+ bestrate = tmp;
+
+ return bestrate;
+}
+
+static int at91sam9x5_clk_smd_set_parent(struct clk_hw *hw, u8 index)
+{
+ u32 tmp;
+ if (index 1)
+ return -EINVAL;
+ tmp = at91_pmc_read(AT91_PMC_SMD) ~AT91_PMC_SMDS;
+ if (index)
+ tmp |= AT91_PMC_SMDS;
+ at91_pmc_write(AT91_PMC_SMD, tmp);
+ return 0;
+}
+
+static u8 at91sam9x5_clk_smd_get_parent(struct clk_hw *hw)
+{
+ return at91_pmc_read(AT91_PMC_SMD) AT91_PMC_SMDS;
+}
+
+static int at91sam9x5_clk_smd_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ u32 tmp;
+ unsigned long div = parent_rate / rate;
+ if (parent_rate % rate || div 1 || div 16)
+ return -EINVAL;
+ tmp = at91_pmc_read(AT91_PMC_SMD) ~AT91_PMC_SMD_DIV;
+ tmp |= (div - 1) 8;
+ at91_pmc_write(AT91_PMC_SMD, tmp);
+
+ return 0;
+}
+
+static const struct clk_ops at91sam9x5_smd_ops = {
+ .recalc_rate = at91sam9x5_clk_smd_recalc_rate,
+ .round_rate = at91sam9x5_clk_smd_round_rate,
+ .get_parent = at91sam9x5_clk_smd_get_parent,
+ .set_parent = at91sam9x5_clk_smd_set_parent,
+ .set_rate = at91sam9x5_clk_smd_set_rate,
+};
+
+struct clk * __init
+at91sam9x5_clk_register_smd(const char *name, const char **parent_names,
+ u8 num_parents)
+{
+ struct at91sam9x5_clk_smd *smd;
+ struct clk *clk = NULL;
+
Re: [RFC PATCH v2, part3 07/11] PCI, xen-pcifront: use new PCI interfaces to simplify implementation
On Thu, May 16, 2013 at 11:50:55PM +0800, Jiang Liu wrote:
Use new PCI interfaces to simplify xen-pcifront implementation:
1) Use pci_create_root_bus() instead of pci_scan_bus_parented()
because pci_scan_bus_parented() is marked as __deprecated.This
also gets rid of a duplicated call of pci_bus_start_devices().
2) Use pci_stop_root_bus() and pci_remove_root_bus() instead of
open-coded private implementation.
3) Use pci_set_host_bridge_release() to release data structures
associated with PCI root buses.
4) Use pci_bus_get()/pci_bus_put() to manage PCI root bus reference
count.
This is also a preparation for coming PCI bus lock enhancement.
Signed-off-by: Jiang Liu jiang@huawei.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Jeremy Fitzhardinge jer...@goop.org
Cc: xen-de...@lists.xensource.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pci/xen-pcifront.c | 81
++
1 file changed, 39 insertions(+), 42 deletions(-)
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 816cf94..6aa2c0f 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -25,11 +25,6 @@
#define INVALID_GRANT_REF (0)
#define INVALID_EVTCHN(-1)
-struct pci_bus_entry {
- struct list_head list;
- struct pci_bus *bus;
-};
-
#define _PDEVB_op_active (0)
#define PDEVB_op_active (1 (_PDEVB_op_active))
@@ -47,12 +42,12 @@ struct pcifront_device {
struct xen_pci_sharedinfo *sh_info;
struct work_struct op_work;
unsigned long flags;
-
};
struct pcifront_sd {
int domain;
struct pcifront_device *pdev;
+ struct resource busn_res;
};
static inline struct pcifront_device *
@@ -67,6 +62,12 @@ static inline void pcifront_init_sd(struct pcifront_sd *sd,
{
sd-domain = domain;
sd-pdev = pdev;
+
+ /* Xen pci-backend doesn't export P2P bridges */
+ sd-busn_res.start = bus;
+ sd-busn_res.end = bus;
+ sd-busn_res.flags = IORESOURCE_BUS;
+ sd-busn_res.name = PCI busn;
}
static DEFINE_SPINLOCK(pcifront_dev_lock);
@@ -441,12 +442,19 @@ static int pcifront_scan_bus(struct pcifront_device
*pdev,
return 0;
}
+static void pcifront_release_sd(struct pci_host_bridge *bridge)
+{
+ struct pcifront_sd *sd = bridge-release_data;
+
+ kfree(sd);
+}
+
static int pcifront_scan_root(struct pcifront_device *pdev,
unsigned int domain, unsigned int bus)
{
struct pci_bus *b;
struct pcifront_sd *sd = NULL;
- struct pci_bus_entry *bus_entry = NULL;
+ LIST_HEAD(resources);
int err = 0;
#ifndef CONFIG_PCI_DOMAINS
@@ -463,16 +471,18 @@ static int pcifront_scan_root(struct pcifront_device
*pdev,
dev_info(pdev-xdev-dev, Creating PCI Frontend Bus %04x:%02x\n,
domain, bus);
- bus_entry = kmalloc(sizeof(*bus_entry), GFP_KERNEL);
- sd = kmalloc(sizeof(*sd), GFP_KERNEL);
- if (!bus_entry || !sd) {
+ sd = kzalloc(sizeof(*sd), GFP_KERNEL);
+ if (!sd) {
err = -ENOMEM;
goto err_out;
}
pcifront_init_sd(sd, domain, bus, pdev);
- b = pci_scan_bus_parented(pdev-xdev-dev, bus,
- pcifront_bus_ops, sd);
+ pci_add_resource(resources, ioport_resource);
+ pci_add_resource(resources, iomem_resource);
+ pci_add_resource(resources, sd-busn_res);
+ b = pci_create_root_bus(pdev-xdev-dev, bus, pcifront_bus_ops,
+ sd, resources);
if (!b) {
dev_err(pdev-xdev-dev,
Error creating PCI Frontend Bus!\n);
@@ -480,12 +490,14 @@ static int pcifront_scan_root(struct pcifront_device
*pdev,
goto err_out;
}
- bus_entry-bus = b;
+ pci_set_host_bridge_release(to_pci_host_bridge(b-bridge),
+ pcifront_release_sd, sd);
- list_add(bus_entry-list, pdev-root_buses);
-
- /* pci_scan_bus_parented skips devices which do not have a have
- * devfn==0. The pcifront_scan_bus enumerates all devfn. */
+ /*
+ * Every PCI physical device should have function 0, but that's not
+ * true for xen.
That is incorrect. There are two types of backends - one of them will
start at zero, but the other might not.
+ * So use pcifront_scan_bus() instead of pci_scan_child_bus().
+ */
err = pcifront_scan_bus(pdev, domain, bus, b);
/* Claim resources before going live with our devices */
@@ -497,7 +509,6 @@ static int pcifront_scan_root(struct pcifront_device
*pdev,
return err;
err_out:
- kfree(bus_entry);
kfree(sd);
return err;
@@ -539,35 +550,19 @@ static int
Re: power-efficient scheduling design
Hi Preeti, On 7 June 2013 07:03, Preeti U Murthy pre...@linux.vnet.ibm.com wrote: On 05/31/2013 04:22 PM, Ingo Molnar wrote: PeterZ and me tried to point out the design requirements previously, but it still does not appear to be clear enough to people, so let me spell it out again, in a hopefully clearer fashion. The scheduler has valuable power saving information available: - when a CPU is busy: about how long the current task expects to run - when a CPU is idle: how long the current CPU expects _not_ to run - topology: it knows how the CPUs and caches interrelate and already optimizes based on that - various high level and low level load averages and other metrics about the recent past that show how busy a particular CPU is, how busy the whole system is, and what the runtime properties of individual tasks is (how often it sleeps, etc.) so the scheduler is in an _ideal_ position to do a judgement call about the near future and estimate how deep an idle state a CPU core should enter into and what frequency it should run at. I don't think the problem lies in the fact that scheduler is not making these decisions about which idle state the CPU should enter or which frequency the CPU should run at. IIUC, I think the problem lies in the part where although the *cpuidle and cpufrequency governors are co-operating with the scheduler, the scheduler is not doing the same.* I think you are missing Ingo's point. It's not about the scheduler complying with decisions made by various governors in the kernel (which may or may not have enough information) but rather the scheduler being in a better position for making such decisions. Take the cpuidle example, it uses the load average of the CPUs, however this load average is currently controlled by the scheduler (load balance). Rather than using a load average that degrades over time and gradually putting the CPU into deeper sleep states, the scheduler could predict more accurately that a run-queue won't have any work over the next x ms and ask for a deeper sleep state from the beginning. Of course, you could export more scheduler information to cpuidle, various hooks (task wakeup etc.) but then we have another framework, cpufreq. It also decides the CPU parameters (frequency) based on the load controlled by the scheduler. Can cpufreq decide whether it's better to keep the CPU at higher frequency so that it gets to idle quicker and therefore deeper sleep states? I don't think it has enough information because there are at least three deciding factors (cpufreq, cpuidle and scheduler's load balancing) which are not unified. Some tasks could be known to the scheduler to require significant CPU cycles when waken up. The scheduler can make the decision to either boost the frequency of the non-idle CPU and place the task there or simply wake up the idle CPU. There are all sorts of power implications here like whether it's better to keep two CPUs at half speed or one at full speed and the other idle. Such parameters could be provided by per-platform hooks. I would repeat here that today we interface cpuidle/cpufrequency policies with scheduler but not the other way around. They do their bit when a cpu is busy/idle. However scheduler does not see that somebody else is taking instructions from it and comes back to give different instructions! The key here is that cpuidle/cpufreq make their primary decision based on something controlled by the scheduler: the CPU load (via run-queue balancing). You would then like the scheduler take such decision back into account. It just looks like a closed loop, possibly 'unstable' . So I think we either (a) come up with 'clearer' separation of responsibilities between scheduler and cpufreq/cpuidle or (b) come up with a unified load-balancing/cpufreq/cpuidle implementation as per Ingo's request. The latter is harder but, with a good design, has potentially a lot more benefits. A possible implementation for (a) is to let the scheduler focus on performance load-balancing but control the balance ratio from a cpufreq governor (via things like arch_scale_freq_power() or something new). CPUfreq would not be concerned just with individual CPU load/frequency but also making a decision on how tasks are balanced between CPUs based on the overall load (e.g. four CPUs are enough for the current load, I can shut the other four off by telling the scheduler not to use them). As for Ingo's preferred solution (b), a proposal forward could be to factor the load balancing out of kernel/sched/fair.c and provide an abstract interface (like load_class?) for easier extending or different policies (e.g. small task packing). You may for example implement a power saving load policy where idle_balance() does not pull tasks from other CPUs but rather invoke cpuidle with a prediction about how long it's going to be idle for. A load class could also give hints to the cpufreq about the actual load needed using
Re: [PATCH] mm: Revert pinned_vm braindamage
On Fri, 7 Jun 2013, Peter Zijlstra wrote: However you twist this; your patch leaves an inconsistent mess. If you really think they're two different things then you should have introduced a second RLIMIT_MEMPIN to go along with your counter. Well continuing to repeat myself: I worked based on agreed upon characteristics of mlocked pages. The patch was there to address a brokenness in the mlock accounting because someone naively assumed that pinning = mlock. I'll argue against such a thing; for I think that limiting the total amount of pages a user can exempt from paging is the far more userful/natural thing to measure/limit. Pinned pages are exempted by the kernel. A device driver or some other kernel process (reclaim, page migration, io etc) increase the page count. There is currently no consistent accounting for pinned pages. The vm_pinned counter was introduced to allow the largest pinners to track what they did. I said that the use of a PIN page flag would allow correct accounting if one wanted to interpret the limit the way you do. You failed to explain how that would help any. With a pin page flag you still need to find the mm to unaccount crap from. Also, all user controlled address space ops operate on vmas. Pinning is kernel controlled... Page migration is not a page fault? It introduces faults; what happens when a process hits the migration pte? It gets a random delay and eventually services a minor fault to the new page. Ok but this is similar to reclaim and other such things that are unmapping pages. At which point the saw will have cut your finger off (going with the most popular RT application ever -- that of a bandsaw and a laser beam). I am pretty confused by your newer notion of RT. RT was about high latency deterministic behavior I thought. RT was basically an abused marketing term and was referring to the bloating of the kernel with all sorts of fair stuff that slows us down. What happened to make you work on low latency stuff? There is some shift that you still need to go through to make that transition. Yes, you would want to avoid reclaim and all sorts of other stuff for low latency. So you disable auto NUMA, defrag etc to avoid these things. This leaves the RT people unhappy -- therefore _if_ we continue with this Linux specific interpretation of mlock() we must introduce new syscalls that implement the intended mlock() semantics. Intended means Peter's semantics? No, I don't actually write RT applications. But I've had plenty of arguments with RT people when I explained to them what our mlock() actually does vs what they expected it to do. Ok Guess this is all new to you at this point. I am happy to see that you are willing to abandon your evil ways (although under pressure from your users) and are willing to put the low latency people now in the RT camp. They're not happy. Aside from that; you HPC/HFT minimal latency lot should very well appreciate the minimal interference stuff they do actually expect. Sure we do and we know how to do things to work around the fair scheduler and other stuff. But you are breaking the basics of how we do things with your conflation of pinning and mlocking. We do not migrate, do not allow defragmentation or reclaim when running low latency applications. These are non issues. This might well be; and I'm not arguing we remove this. I'm merely stating that it doesn't make everybody happy. Also what purpose do HPC type applications have for mlock()? HPC wants to keep them in memory to avoid eviction. HPC apps are not as sensitive to faults as low latency apps are. Minor faults have traditionally be tolerated there. The lower you get in terms of the latencies required the more difficult the OS control becomes. Here we must disagree I fear; given that mlock() is of RT origin and RT people very much want/expect mlock() to do what our proposed mpin() will do. RT is a dirty word for me given the fairness and bloat issue. Not sure what you mean with that. mlock is a means to keep data in memory and not a magical wand that avoids all OS handling of the page. That cannot be so since mlocked pages need to be migratable. I'm talking about the proposed mpin() stuff. Could you write that up in detail? I am not sure how this could work at this point. So I proposed most of the machinery that would be required to actually implement the syscalls. Except that the IB code stumped me. In particular I cannot easily find the userspace address to unpin for ipath/qib release paths. Once we have that we can trivially implement the syscalls. Why would you need syscalls? Pinning is driver/kernel subsystem initiated and therefore the driver can do the pin/unpin calls. Pinning is not initiated by user space but by the kernel. Either temporarily (page count increases are used all over the kernel for this) or for longer time frame (IB and Perf and likely more drivers that we have not found yet).
[PATCH V2] sysfs_notify is only possible on file attributes
If sysfs_notify is called on a binary attribute, bad things can
happen, so prevent it.
Note, no in-kernel usage of this is currently present, but in the
future, it's good to be safe.
Changes in V2:
- Also ignore sysfs_notify on dirs, links
- Use WARN_ON rather than silently failing
- Compiled and tested (huge apologies about first submission)
Signed-off-by: Nick Dyer nick.d...@itdev.co.uk
---
fs/sysfs/file.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 602f56d..d2bb7ed 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -449,10 +449,12 @@ void sysfs_notify_dirent(struct sysfs_dirent *sd)
spin_lock_irqsave(sysfs_open_dirent_lock, flags);
- od = sd-s_attr.open;
- if (od) {
- atomic_inc(od-event);
- wake_up_interruptible(od-poll);
+ if (!WARN_ON(sysfs_type(sd) != SYSFS_KOBJ_ATTR)) {
+ od = sd-s_attr.open;
+ if (od) {
+ atomic_inc(od-event);
+ wake_up_interruptible(od-poll);
+ }
}
spin_unlock_irqrestore(sysfs_open_dirent_lock, flags);
--
1.7.10.4
--
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 4/4] firmware loader: don't allow to request firmware via relative path
On Fri, Jun 7, 2013 at 2:04 PM, Takashi Iwai ti...@suse.de wrote: At Fri, 7 Jun 2013 09:30:09 +0800, Ming Lei wrote: On Fri, Jun 7, 2013 at 3:48 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Thu, Jun 06, 2013 at 08:01:50PM +0800, Ming Lei wrote: It isn't a good pratice to request firmware via relative path, also might have security issue, so don't do it. What would the security issue be? You are letting the person who build the kernel specify this, so they can put whatever they want in here, a '..' isn't going to keep them from being able to do bad things if they really want to. In VM case, guest kernel might access host filesystem files via this trick, but not sure if it is possible. Takashi, could you explain the security issue of relative path? Well, I don't know, too. My original question was what happens if you pass a relative path to firmware_class.fw_path_para module option (or the new kconfig)... OK, so please ignore the patch. Thanks -- Ming Lei -- 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 v2 0/2] dmaengine: at_hdmac: dt dma bindings update
Vinod, This is the patch series that has already been sent by Ludovic. It is the part of the series that is dedicated to dmaengine. It is based on slave-dma/next. I plan to submit an additional patch through arm-soc as the .dtsi updates are dependent on a cleanup branch that is already stacked there. This set of patches update the dt dma binding for at_hdmac since we need one more parameter. In order to keep backward compatibility, an existing cell will be used to add this parameter. Since the content of that cell will become a magic value due to the concatenation of the two parameters, it is time to use macros. Thanks, best regards, Ludovic Desroches (2): ARM: at91: dt: add header to define at_hdmac configuration at_hdmac: add FIFO configuration parameter to DMA DT binding .../devicetree/bindings/dma/atmel-dma.txt | 7 -- drivers/dma/at_hdmac.c | 25 include/dt-bindings/dma/at91.h | 27 ++ 3 files changed, 53 insertions(+), 6 deletions(-) create mode 100644 include/dt-bindings/dma/at91.h -- 1.8.2.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 v2 1/2] ARM: at91: dt: add header to define at_hdmac configuration
From: Ludovic Desroches ludovic.desroc...@atmel.com DMA-cell content is a concatenation of several values. In order to keep this stuff human readable, macros are introduced. The values for the FIFO configuration are not the same as the ones used in the configuration register in order to keep backward compatibility. Most devices use the half FIFO configuration but USART ones have to use the ASAP configuration. This parameter was not initially planed to be into the at91 dma dt binding. The third cell will be used to store this parameter, it will become a concatenation of the FIFO configuration and of the peripheral ID. In order to keep backward compatibility i.e. FIFO configuration is equal to 0, we have to perform a translation since the value to put in the register to set half FIFO is 1. Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com --- include/dt-bindings/dma/at91.h | 27 +++ 1 file changed, 27 insertions(+) create mode 100644 include/dt-bindings/dma/at91.h diff --git a/include/dt-bindings/dma/at91.h b/include/dt-bindings/dma/at91.h new file mode 100644 index 000..e835037 --- /dev/null +++ b/include/dt-bindings/dma/at91.h @@ -0,0 +1,27 @@ +/* + * This header provides macros for at91 dma bindings. + * + * Copyright (C) 2013 Ludovic Desroches ludovic.desroc...@atmel.com + * + * GPLv2 only + */ + +#ifndef __DT_BINDINGS_AT91_DMA_H__ +#define __DT_BINDINGS_AT91_DMA_H__ + +/* + * Source and/or destination peripheral ID + */ +#define AT91_DMA_CFG_PER_ID_MASK (0xff) +#define AT91_DMA_CFG_PER_ID(id)(id AT91_DMA_CFG_PER_ID_MASK) + +/* + * FIFO configuration: it defines when a request is serviced. + */ +#define AT91_DMA_CFG_FIFOCFG_OFFSET(8) +#define AT91_DMA_CFG_FIFOCFG_MASK (0xf AT91_DMA_CFG_FIFOCFG_OFFSET) +#define AT91_DMA_CFG_FIFOCFG_HALF (0x0 AT91_DMA_CFG_FIFOCFG_OFFSET) /* half FIFO (default behavior) */ +#define AT91_DMA_CFG_FIFOCFG_ALAP (0x1 AT91_DMA_CFG_FIFOCFG_OFFSET) /* largest defined AHB burst */ +#define AT91_DMA_CFG_FIFOCFG_ASAP (0x2 AT91_DMA_CFG_FIFOCFG_OFFSET) /* single AHB access */ + +#endif /* __DT_BINDINGS_AT91_DMA_H__ */ -- 1.8.2.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 1/2] pinmux: Add TB10x pinmux driver
On 7 June 2013 19:32, Christian Ruppert christian.rupp...@abilis.com wrote:
On Fri, Jun 07, 2013 at 08:00:57AM +0800, Haojian Zhuang wrote:
On 6 June 2013 23:30, Christian Ruppert christian.rupp...@abilis.com wrote:
On Thu, Jun 06, 2013 at 10:32:21PM +0800, Haojian Zhuang wrote:
On 6 June 2013 22:11, Christian Ruppert christian.rupp...@abilis.com
wrote:
On Wed, Jun 05, 2013 at 09:44:27AM +0800, Haojian Zhuang wrote:
On 3 June 2013 20:30, Christian Ruppert christian.rupp...@abilis.com
wrote:
OK, here's a simplified example of what we would like to do (this
seems
pretty common so I suppose there is a way I haven't understood). Our
situation is slightly more complex but for the purpose of discussion
let's assume a chip with 8 pins which can be configured for the
following functions:
Pin GPIO-AI2CSPI0 SPI1
1GPIOA0SDA MISO1
2GPIOA1SCL MOSI1
3GPIOA2SS1_B
4GPIOA3SCLK1
5GPIOA4 MISO0
6GPIOA5 MOSI0
7GPIOA6 SS0_B
8GPIOA7 SCLK0
We can now define the following pinctrl-single:
pinmux: pinmux@0xFFEE {
compatible = pinctrl-single;
reg = 0xFFEE 0x8;
#address-cells = 1;
#size-cells = 0;
#gpio-range-cells = 3;
pinctrl-single,register-width = 32;
pinctrl-single,function-mask = 0x;
pinctrl-single,gpio-range = range 1 8 0;
gpioa_pins: pinmux_gpioa_pins {
pinctrl-single,pins = 0x0 0 0x4 0
};
i2c_pins: pinmux_i2c_pins {
pinctrl-single,pins = 0x0 1
};
spi0_pins: pinmux_spi0_pins {
pinctrl-single,pins = 0x1 1
0x1 1?
If each pinmux register is only for one pin in your SoC.
I think that your definitions are wrong above. We use
register offset as the first argument, not pin number.
And the second argument should be pin function number.
In our case each pinmux register (bit field) actually controls an entire
group of pins.
If multiple pins are sharing one register with different bits,
you need to enable pinctrl-single,bit-per-mux.
Multiple pins are sharing the same bits in the same register. Do you
think this prevents us from using pinctrl-single?
Could you give me your register definition? Then I can understand you
better.
In our example, the register map would look a bit like the following.
Note that every register configures four pins at a time.
Register 0x0:
Mode GPIO-AI2CSPI1
Value 0x0 0x10x2
---
Pin1 GPIOA0SDAMISO1
Pin2 GPIOA1SCLMOSI1
Pin3 GPIOA2 SS1_B
Pin4 GPIOA3 SCLK1
Register 0x4:
Mode GPIO-ASPI0
Value 0x0 0x1
-
Pin5 GPIOA4MISO0
Pin6 GPIOA5MOSI0
Pin7 GPIOA6SS0_B
Pin8 GPIOA7SCLK0
You said Multiple pins are sharing the same bits in the same register..
I need to understand which bits you're talking about in your register.
In the above example, bits 0 and 1 of register 0x0 control pins 1
through 4 and bit 0 of register 0x4 controls pins 5 through 8. The
moment you write a new value in either of those registers, all four pins
will change functionality simultaneously. There is no way to control the
functionality of each pin individually.
Oh. So some bits in the same register control multiple pins.
Yeah, I also meet this in Hisilicon SoC. My solution is to only define the
pinmux register for one pin, and skip other pins.
1. You're using GPIOA0 GPIOA1 in two different driver.
You only need to define GPIOA0 or GPIOA1 in one of driver. Don't define
them at the same time.
2. You're using GPIOA0 GPIOA1 in the same driver.
You only need to define GPIOA0 or GPIOA1.
3. If you're using SPI or any other function, it's same as GPIO function.
4. There's no #4. Since you won't use GPIOA0 with SCL pin together.
Regards
Haojian
--
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 v2 2/2] at_hdmac: add FIFO configuration parameter to DMA DT binding
From: Ludovic Desroches ludovic.desroc...@atmel.com
For most devices the FIFO configuration is the same i.e. when half FIFO size is
available/filled, a source/destination request is serviced. But USART devices
have to do it when there is enough space/data available to perform a single
AHB access so the ASAP configuration.
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
---
.../devicetree/bindings/dma/atmel-dma.txt | 7 --
drivers/dma/at_hdmac.c | 25 ++
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt
b/Documentation/devicetree/bindings/dma/atmel-dma.txt
index c80e8a3..c280a0e 100644
--- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
+++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
@@ -24,8 +24,11 @@ The three cells in order are:
1. A phandle pointing to the DMA controller.
2. The memory interface (16 most significant bits), the peripheral interface
(16 less significant bits).
-3. The peripheral identifier for the hardware handshaking interface. The
-identifier can be different for tx and rx.
+3. Parameters for the at91 DMA configuration register which are device
+dependant:
+ - bit 7-0: peripheral identifier for the hardware handshaking interface. The
+ identifier can be different for tx and rx.
+ - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 1 for ASAP.
Example:
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 6db5228..4499dcf 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -14,6 +14,7 @@
* found on AT91SAM9263.
*/
+#include dt-bindings/dma/at91.h
#include linux/clk.h
#include linux/dmaengine.h
#include linux/dma-mapping.h
@@ -1320,15 +1321,31 @@ static struct dma_chan *at_dma_xlate(struct
of_phandle_args *dma_spec,
atslave = devm_kzalloc(dmac_pdev-dev, sizeof(*atslave), GFP_KERNEL);
if (!atslave)
return NULL;
+
+ atslave-cfg = ATC_DST_H2SEL_HW | ATC_SRC_H2SEL_HW;
/*
* We can fill both SRC_PER and DST_PER, one of these fields will be
* ignored depending on DMA transfer direction.
*/
- per_id = dma_spec-args[1];
- atslave-cfg = ATC_FIFOCFG_HALFFIFO
-| ATC_DST_H2SEL_HW | ATC_SRC_H2SEL_HW
-| ATC_DST_PER_MSB(per_id) | ATC_DST_PER(per_id)
+ per_id = dma_spec-args[1] AT91_DMA_CFG_PER_ID_MASK;
+ atslave-cfg |= ATC_DST_PER_MSB(per_id) | ATC_DST_PER(per_id)
| ATC_SRC_PER_MSB(per_id) | ATC_SRC_PER(per_id);
+ /*
+* We have to translate the value we get from the device tree since
+* the half FIFO configuration value had to be 0 to keep backward
+* compatibility.
+*/
+ switch(dma_spec-args[1] AT91_DMA_CFG_FIFOCFG_MASK) {
+ case AT91_DMA_CFG_FIFOCFG_ALAP:
+ atslave-cfg |= ATC_FIFOCFG_LARGESTBURST;
+ break;
+ case AT91_DMA_CFG_FIFOCFG_ASAP:
+ atslave-cfg |= ATC_FIFOCFG_ENOUGHSPACE;
+ break;
+ case AT91_DMA_CFG_FIFOCFG_HALF:
+ default:
+ atslave-cfg |= ATC_FIFOCFG_HALFFIFO;
+ }
atslave-dma_dev = dmac_pdev-dev;
chan = dma_request_channel(mask, at_dma_filter, atslave);
--
1.8.2.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: [ 150/184] ipv4: check rt_genid in dst_check
On Fri, Jun 07, 2013 at 07:07:33AM +0100, Ben Hutchings wrote:
This commit is based on the above, with the addition of verifying blackhole
routes in the same manner.
That addition doesn't seem to correspond to anything in mainline. Why
should 2.6.32 differ?
Fixing the issue with blackhole routes as it was accomplished in mainline
would require pulling in a lot more code, and people were not interested
in pulling in all of the dependencies given the much higher risk of trying
to select the right subset of changes to include. The addition of the
single line of dst-obsolete = -1; in ipv4_dst_blackhole() was much
easier to verify, and is in the spirit of the patch in question. This is
the minimal set of changes to fix the bug in question.
-ben
Ben.
Signed-off-by: Benjamin LaHaise b...@kvack.org
Signed-off-by: Willy Tarreau w...@1wt.eu
---
net/ipv4/route.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 58f141b..f16d19b 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1412,7 +1412,7 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr,
__be32 new_gw,
dev_hold(rt-u.dst.dev);
if (rt-idev)
in_dev_hold(rt-idev);
- rt-u.dst.obsolete = 0;
+ rt-u.dst.obsolete = -1;
rt-u.dst.lastuse = jiffies;
rt-u.dst.path = rt-u.dst;
rt-u.dst.neighbour = NULL;
@@ -1477,7 +1477,7 @@ static struct dst_entry *ipv4_negative_advice(struct
dst_entry *dst)
struct dst_entry *ret = dst;
if (rt) {
- if (dst-obsolete) {
+ if (dst-obsolete 0) {
ip_rt_put(rt);
ret = NULL;
} else if ((rt-rt_flags RTCF_REDIRECTED) ||
@@ -1700,7 +1700,9 @@ static void ip_rt_update_pmtu(struct dst_entry *dst,
u32 mtu)
static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie)
{
- return NULL;
+ if (rt_is_expired((struct rtable *)dst))
+ return NULL;
+ return dst;
}
static void ipv4_dst_destroy(struct dst_entry *dst)
@@ -1862,7 +1864,8 @@ static int ip_route_input_mc(struct sk_buff *skb,
__be32 daddr, __be32 saddr,
if (!rth)
goto e_nobufs;
- rth-u.dst.output= ip_rt_bug;
+ rth-u.dst.output = ip_rt_bug;
+ rth-u.dst.obsolete = -1;
atomic_set(rth-u.dst.__refcnt, 1);
rth-u.dst.flags= DST_HOST;
@@ -2023,6 +2026,7 @@ static int __mkroute_input(struct sk_buff *skb,
rth-fl.oif = 0;
rth-rt_spec_dst= spec_dst;
+ rth-u.dst.obsolete = -1;
rth-u.dst.input = ip_forward;
rth-u.dst.output = ip_output;
rth-rt_genid = rt_genid(dev_net(rth-u.dst.dev));
@@ -2187,6 +2191,7 @@ local_input:
goto e_nobufs;
rth-u.dst.output= ip_rt_bug;
+ rth-u.dst.obsolete = -1;
rth-rt_genid = rt_genid(net);
atomic_set(rth-u.dst.__refcnt, 1);
@@ -2411,7 +2416,8 @@ static int __mkroute_output(struct rtable **result,
rth-rt_gateway = fl-fl4_dst;
rth-rt_spec_dst= fl-fl4_src;
- rth-u.dst.output=ip_output;
+ rth-u.dst.output = ip_output;
+ rth-u.dst.obsolete = -1;
rth-rt_genid = rt_genid(dev_net(dev_out));
RT_CACHE_STAT_INC(out_slow_tot);
@@ -2741,6 +2747,7 @@ static int ipv4_dst_blackhole(struct net *net, struct
rtable **rp, struct flowi
if (rt) {
struct dst_entry *new = rt-u.dst;
+ new-obsolete = -1;
atomic_set(new-__refcnt, 1);
new-__use = 1;
new-input = dst_discard;
--
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers
--
Thought is the essence of where you are now.
--
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/
[RFC PATCH 04/50] ARM: at91: add PMC master clock
This is the at91 master clock implementation using common clk framework.
The pll clock layout describe the MCKR register layout.
There's four pll clock layouts:
- at91rm9200
- at91sam9x5
Master clocks are given characteristics:
- min/max clock output rate
These characteristics are checked during rate change to avoid
over/underclocking.
These characteristics are described in atmel's SoC datasheet in
Electrical Characteristics paragraph.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
drivers/clk/at91/Makefile |2 +-
drivers/clk/at91/clk-master.c | 317 +
include/linux/clk/at91.h | 23 +++
3 files changed, 341 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 564076f..d41f616 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -2,4 +2,4 @@
# Makefile for at91 specific clk
#
-obj-y += clk-main.o clk-pll.o clk-plldiv.o
+obj-y += clk-main.o clk-pll.o clk-plldiv.o clk-master.o
diff --git a/drivers/clk/at91/clk-master.c b/drivers/clk/at91/clk-master.c
new file mode 100644
index 000..71ade7d
--- /dev/null
+++ b/drivers/clk/at91/clk-master.c
@@ -0,0 +1,317 @@
+/*
+ * drivers/clk/at91/clk-master.c
+ *
+ * Copyright (C) 2013 Boris BREZILLON b.brezil...@overkiz.com
+ *
+ * This masterram is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/clk/at91.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/io.h
+
+#define MASTER_SOURCE_MAX 4
+
+#define to_clk_master(hw) container_of(hw, struct clk_master, hw)
+
+struct clk_master {
+ struct clk_hw hw;
+ struct clk_master_layout *layout;
+ struct clk_master_characteristics *characteristics;
+};
+
+static unsigned long clk_master_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ u8 pres;
+ u8 div;
+ unsigned long rate = parent_rate;
+ struct clk_master *master = to_clk_master(hw);
+ struct clk_master_layout *layout = master-layout;
+ struct clk_master_characteristics *characteristics =
+ master-characteristics;
+ u32 tmp = at91_pmc_read(AT91_PMC_MCKR) layout-mask;
+
+ pres = (tmp layout-pres_shift) 0x7;
+ div = (tmp 8) 0x3;
+
+ if (characteristics-have_div3_pres pres == 7)
+ rate /= 3;
+ else
+ rate = pres;
+
+ rate /= characteristics-divisors[div];
+
+ /* print overclocking or underclocking error */
+ /*
+ if (rate characteristics-output.min ||
+ rate characteristics-output.max) {
+ }
+ */
+ return rate;
+}
+
+static long clk_master_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ int mdiv;
+ int pres;
+ u32 div;
+ long best_rate = -EINVAL;
+ unsigned long best_diff = 0;
+ unsigned long cur_diff;
+ unsigned long pres_rate;
+ unsigned long cur_rate;
+ struct clk_master *master = to_clk_master(hw);
+ struct clk_master_characteristics *characteristics =
+ master-characteristics;
+
+ if (rate characteristics-output.min ||
+ rate characteristics-output.max)
+ return -EINVAL;
+
+ for (pres = 0; pres 7; pres++) {
+ if (pres 7)
+ pres_rate = *parent_rate pres;
+ else {
+ if (!characteristics-have_div3_pres)
+ break;
+ pres_rate = *parent_rate / 3;
+ }
+ for (mdiv = 0; mdiv 4; mdiv++) {
+ div = characteristics-divisors[mdiv];
+ if (!div)
+ continue;
+ cur_rate = pres_rate / div;
+ if (rate cur_rate)
+ cur_diff = cur_rate - rate;
+ else
+ cur_diff = rate - cur_rate;
+
+ if (best_rate 0 || cur_diff best_diff) {
+ best_rate = cur_rate;
+ best_diff = cur_diff;
+ if (!best_diff)
+ return best_rate;
+ }
+ }
+ }
+
+ return best_rate;
+}
+
+static int clk_master_set_parent(struct clk_hw *hw, u8 index)
+{
+ u32 tmp;
+ if (index AT91_PMC_CSS)
+ return -EINVAL;
+ tmp = at91_pmc_read(AT91_PMC_MCKR)
Re: [ 150/184] ipv4: check rt_genid in dst_check
On Fri, Jun 07, 2013 at 10:58:06AM -0400, Benjamin LaHaise wrote: On Fri, Jun 07, 2013 at 07:07:33AM +0100, Ben Hutchings wrote: This commit is based on the above, with the addition of verifying blackhole routes in the same manner. That addition doesn't seem to correspond to anything in mainline. Why should 2.6.32 differ? Fixing the issue with blackhole routes as it was accomplished in mainline would require pulling in a lot more code, and people were not interested in pulling in all of the dependencies given the much higher risk of trying to select the right subset of changes to include. The addition of the single line of dst-obsolete = -1; in ipv4_dst_blackhole() was much easier to verify, and is in the spirit of the patch in question. This is the minimal set of changes to fix the bug in question. Thank you Ben, I'll add this description to the existing commit message. Best regards, Willy -- 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 1/2] mmc: dw_mmc: Handle late vmmc regulator with EPROBE_DEFER
Tomasz / Mark, On Fri, Jun 7, 2013 at 3:30 AM, Tomasz Figa tomasz.f...@gmail.com wrote: On Friday 07 of June 2013 11:24:04 Mark Brown wrote: On Fri, Jun 07, 2013 at 12:19:58PM +0200, Tomasz Figa wrote: This interesting case makes me think that regulator core should differentiate between regulator lookup failure due to no lookup specified and due to the regulator specified in lookup being unavailable, returning appropriate (different) error codes. It does exactly that in so far as it can - you get -ENODEV if there's definitely no supply and -EPROBE_DEFER otherwise. Oh, right, thanks. I somehow felt that it should be doing this already, but I was looking at 3.9 on Free Electron's LXR. It does so since commit 1e4b545cdd regulator: core: return err value for regulator_get if there is no DT binding Thanks, this is much cleaner. That's what I get for doing the majority of my work on 3.8 at the moment. :-P I will rework the patch and send it out again. -Doug -- 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 v1 3/4] firmware loader: allow distribution to choose default search paths
On Fri, Jun 7, 2013 at 12:20 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Fri, Jun 07, 2013 at 09:24:25AM +0800, Ming Lei wrote:
On Fri, Jun 7, 2013 at 3:47 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Thu, Jun 06, 2013 at 08:01:49PM +0800, Ming Lei wrote:
For some distributions(e.g. android), firmware images aren't put
under kernel built-in search paths, so introduce one Kconfig
option to allow distributions or users to choose its specific default
search paths, which are always tried before searching from kernel
built-in paths in direct loading.
Also this patch introduces fw_get_fw_file_from_paths to cover all
search paths, and fw_get_filesystem_firmware is simpified a bit.
Cc: Takashi Iwai ti...@suse.de
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/base/Kconfig | 14 ++
drivers/base/firmware_class.c | 61
++---
2 files changed, 65 insertions(+), 10 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 07abd9d..2be10e4 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -156,6 +156,20 @@ config FW_LOADER_USER_HELPER
no longer required unless you have a special firmware file that
resides in a non-standard path.
+config FW_CUSTOMIZED_PATH
+ string default firmware search paths for direct loading
+ help
+ On some distribution(e.g. android), firmware images aren't
+ put under kernel built-in search paths, so provide this option
+ for distributions to choose a distribution specific firmware
+ search path. The option allows to choose more than one path,
+ and paths are seperated with colon like $PATH(e.g. on android,
+ the option might look as /etc/firmware:/vendor/firmware).
+ Each path should be a absolute path, and relative path will be
+ ignored.
+
+ If you are unsure about this, don't choose here.
+
config DEBUG_DRIVER
bool Driver Core verbose debug messages
depends on DEBUG_KERNEL
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 6ede229..051db83 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -265,8 +265,13 @@ static void fw_free_buf(struct firmware_buf *buf)
/* direct firmware loading support */
static char fw_path_para[256];
+
+/* search runtime paths first, then static pre-defined paths */
static const char * const fw_path[] = {
fw_path_para,
+#ifdef CONFIG_FW_CUSTOMIZED_PATH
+ CONFIG_FW_CUSTOMIZED_PATH,
+#endif
/lib/firmware/updates/ UTS_RELEASE,
/lib/firmware/updates,
/lib/firmware/ UTS_RELEASE,
@@ -314,6 +319,50 @@ static bool fw_read_file_contents(struct file *file,
struct firmware_buf *fw_buf
return true;
}
+static bool fw_get_file_firmware(const char *path,
+ struct firmware_buf *buf)
+{
+ struct file *file;
+ bool success;
+
+ file = filp_open(path, O_RDONLY, 0);
+ if (IS_ERR(file))
+ return false;
+ success = fw_read_file_contents(file, buf);
+ fput(file);
+
+ return success;
+}
+
+/* The path in @paths is seperated by ';' */
No it isn't.
Will fix it.
+static bool fw_get_file_fw_from_paths(const char *paths, char *path,
+ struct firmware_buf *buf)
+{
+ int len, start, end = -1;
+ char *pos;
+
+ do {
+ start = end + 1;
+ pos = strchr(paths[start], ':');
As you have an array of paths now, why are you doing the ':' check
still? Don't do that, just allow the person building the kernel to add
one path to the loader, that should be all that we need, right?
The distribution may have put firmware under more than one places,
for example, android put firmwares under /etc/firmware and
/vendor/firmware, so I am afraid that only allowing one path or two
paths isn't flexible enough.
How about we wait until someone complains about this? Don't add
features that aren't needed, especially complex ones like this.
That is fine with me.
But I believe soon or later people will ask for the option because
basically it will make direct loading to replace user space loader.
And now with the option, people can choose to disable
CONFIG_FW_LOADER_USER_HELPER to save code size if
their firmwares aren't under built-in paths.
Thanks,
--
Ming Lei
--
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: [ 130/184] CVE-2012-4508 kernel: ext4: AIO vs fallocate stale
Hi James, On Fri, Jun 07, 2013 at 09:02:39AM +0100, Jamie Iles wrote: Sure, I'd be happy to add my s-o-b. Signed-off-by: Jamie Iles ja...@jamieiles.com Added, thanks. willy -- 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: [ 150/184] ipv4: check rt_genid in dst_check
Hi Willy, On Fri, Jun 07, 2013 at 05:00:57PM +0200, Willy Tarreau wrote: On Fri, Jun 07, 2013 at 10:58:06AM -0400, Benjamin LaHaise wrote: On Fri, Jun 07, 2013 at 07:07:33AM +0100, Ben Hutchings wrote: This commit is based on the above, with the addition of verifying blackhole routes in the same manner. That addition doesn't seem to correspond to anything in mainline. Why should 2.6.32 differ? Fixing the issue with blackhole routes as it was accomplished in mainline would require pulling in a lot more code, and people were not interested in pulling in all of the dependencies given the much higher risk of trying to select the right subset of changes to include. The addition of the single line of dst-obsolete = -1; in ipv4_dst_blackhole() was much easier to verify, and is in the spirit of the patch in question. This is the minimal set of changes to fix the bug in question. Thank you Ben, I'll add this description to the existing commit message. A link to the test case for this issue might be helpful to include as well. It is at http://marc.info/?l=linux-netdevm=135015076708950w=2 . Cheers, -ben Best regards, Willy -- Thought is the essence of where you are now. -- 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/3] thinkpad_acpi: add LED quirks of models which don't have EC controllable LEDs
On Fri, Jun 07, 2013 at 01:22:39PM +, Matthew Garrett wrote: On Fri, 2013-06-07 at 16:20 +0800, Adam Lee wrote: Some new Lenovo or ThinkPad laptops don't have EC controllable LEDs. This patch adds their quirks. Can you detect this case? If this is a new way of doing things then you're going to have to add new entries to the quirk list every time Lenovo release a new machine, which isn't really going to work. Thanks. The difference is their LED handle expects only one argument, not two. Does kernel have a method detecting acpi_handle's arguments number? (checking...) About the new way: Lenovo is going to assign a ACPI method to each operation. Like the volume_toggle button and LED, hardware toggle is SHDA, getting state is GSMS, setting state is SSMS. About the problem: Some models only support the new way but containing internal EC LED interfaces which makes our detecting failed at the same time. The new interfaces accept only one argument(on, off, or blink), we couldn't control LEDs by them because can't specify the LED number. If you give them two arguments, it returns ACPI warning, so I wanna add these 0 quirks. -- Regards, Adam Lee Hardware Enablement -- 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] irq: add a new function irq_in_progress to check pending IRQ handlers
On Fri, Jun 07, 2013 at 12:54:55PM +0800, Yanmin Zhang wrote: On Thu, 2013-06-06 at 21:19 -0700, Greg KH wrote: On Fri, Jun 07, 2013 at 11:18:06AM +0800, Yanmin Zhang wrote: On Thu, 2013-06-06 at 20:08 -0700, Greg KH wrote: On Fri, Jun 07, 2013 at 10:37:52AM +0800, Yanmin Zhang wrote: On Thu, 2013-06-06 at 18:02 -0700, Greg KH wrote: On Fri, Jun 07, 2013 at 08:53:29AM +0800, Yanmin Zhang wrote: On Thu, 2013-06-06 at 15:18 +0200, Thomas Gleixner wrote: On Thu, 6 Jun 2013, shuox@intel.com wrote: From: Zhang Yanmin yanmin.zh...@intel.com synchronize_irq waits pending IRQ handlers to be finished. If using this function while holding a resource, the IRQ handler may cause deadlock. Here we add a new function irq_in_progress which doesn't wait for the handlers to be finished. A typical use case at suspend-to-ram: device driver's irq handler is complicated and might hold a mutex at rare cases. Its suspend function is called and a suspended flag is set. In case its IRQ handler is running, suspend function calls irq_in_progress. if handler is running, abort suspend. The irq handler checks the suspended flag. If the device is suspended, irq handler either ignores the interrupt, or wakes up the whole system, and the driver's resume function could deal with the delayed interrupt handling. This is as wrong as it can be. Fix the driver instead of hacking racy functions into the core code. So your problem looks like this: CPU 0 CPU 1 irq_handler_thread()suspend() .mutex_lock(m); mutex_lock(m); synchronize_irq(); So why needs the mutex to be taken before synchronize_irq()? Why not doing the obvious? suspend() disable_irq(); (Implies synchronize_irq) mutex_lock(m); mutex_unlock(m); enable_irq(); Thanks for the kind comment. We do consider your solution before and it works well indeed with some specific simple drivers. For example, some drives use GPIO pin as interrupt source. On one specific platform, disable_irq would really disable the irq at RTE entry, which means we lose the wakeup capability of this device. synchronize_irq can be another solution. But we did hit 'DPM device timeout' issue reported by dpm_wd_handler at suspend-to-ram. The driver is complicated. We couldn't change too many functions to optimize it. In addition, we have to use the driver instead of throwing it away. What is preventing you from rewriting it to work properly? It's complicated. That sounds like your issue, not ours, so please don't push the problem onto someone else. Take ownership of the driver, fix it up, and all will be good. With irq_in_progress, we can resolve this issue and it does work, although it looks like ugly. Don't paper over driver bugs in the core kernel, fix the driver. It's hard to say it's a driver bug. Could generic kernel provide some flexibility for such complicated drivers? Please post the code for the driver, and then we will be glad to continue the dicussion. Greg, Thanks for your enthusiasm. It's a private driver for products. What do you mean private driver? All drivers need to be merged into the mainline kernel, it saves you time and money, and we will fix your bugs for you. You know that, your bosses know that, your management knows that, so why are you trying to hide things? totally confused, They are embedded device drivers, highly depending on specific devices which runs its own firmware in devices. Here the kernel drivers run at AP side. That's no different from loads of drivers that we have in the kernel today, no need to keep them from being merged, please submit them. One example is Graphics driver, which is very big and coding is not friendly. Kernel experts can raise tons of questions against the driver, but we have to make the driver work well on real products. So you are saying that kernel experts don't ask questions that actually make drivers work well on real products? If that's how you feel about the community, then why are you asking the community for help in the first place? And do you somehow think that we don't know how to review/write/fix graphics drivers? Who do you think made Linux in the first place? Another reason is drivers need workaround many hardware
Re: [PATCHv4 14/39] thp, mm: rewrite delete_from_page_cache() to support huge pages
Kirill A. Shutemov wrote:
Dave Hansen wrote:
Which reminds me... Why do we handle their reference counts differently? :)
It seems like we could easily put a for loop in delete_from_page_cache()
that will release their reference counts along with the head page.
Wouldn't that make the code less special-cased for tail pages?
delete_from_page_cache() is not the only user of
__delete_from_page_cache()...
It seems I did it wrong in add_to_page_cache_locked(). We shouldn't take
references on tail pages there, only one on head. On split it will be
distributed properly.
This way:
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index b267859..c2c0df2 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1556,6 +1556,7 @@ static void __split_huge_page_refcount(struct page *page,
struct zone *zone = page_zone(page);
struct lruvec *lruvec;
int tail_count = 0;
+ int init_tail_refcount;
/* prevent PageLRU to go away from under us, and freeze lru stats */
spin_lock_irq(zone-lru_lock);
@@ -1565,6 +1566,13 @@ static void __split_huge_page_refcount(struct page *page,
/* complete memcg works before add pages to LRU */
mem_cgroup_split_huge_fixup(page);
+ /*
+* When we add a huge page to page cache we take only reference to head
+* page, but on split we need to take addition reference to all tail
+* pages since they are still in page cache after splitting.
+*/
+ init_tail_refcount = PageAnon(page) ? 0 : 1;
+
for (i = HPAGE_PMD_NR - 1; i = 1; i--) {
struct page *page_tail = page + i;
@@ -1587,8 +1595,9 @@ static void __split_huge_page_refcount(struct page *page,
* atomic_set() here would be safe on all archs (and
* not only on x86), it's safer to use atomic_add().
*/
- atomic_add(page_mapcount(page) + page_mapcount(page_tail) + 1,
- page_tail-_count);
+ atomic_add(init_tail_refcount + page_mapcount(page) +
+ page_mapcount(page_tail) + 1,
+ page_tail-_count);
/* after clearing PageTail the gup refcount can be released */
smp_mb();
--
Kirill A. Shutemov
--
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/
[RFC PATCH 12/50] ARM: at91: move to common clk framework
This patch removes the old at91 clk implementation, and keep the PMC initialization and sam9idle functions in pmc.c. The at91_initialize function no longer initiliaze at91 clks: the new clk registration process requires kzalloc which is not available when early_init is called. The clk registration is moved to at91_clk_init function which should be called before timer_init (pit timer request at91 master clock). Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com --- arch/arm/mach-at91/Makefile |2 +- arch/arm/mach-at91/clock.c | 961 -- arch/arm/mach-at91/clock.h | 49 --- arch/arm/mach-at91/generic.h | 10 +- arch/arm/mach-at91/pmc.c | 58 +++ arch/arm/mach-at91/setup.c | 36 +- drivers/clk/Makefile |1 + 7 files changed, 86 insertions(+), 1031 deletions(-) diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile index d07bcfa..c9813f8 100644 --- a/arch/arm/mach-at91/Makefile +++ b/arch/arm/mach-at91/Makefile @@ -7,7 +7,7 @@ obj-m := obj-n := obj- := -obj-$(CONFIG_AT91_PMC_UNIT)+= clock.o +obj-$(CONFIG_AT91_PMC_UNIT)+= pmc.o obj-$(CONFIG_AT91_SAM9_ALT_RESET) += at91sam9_alt_reset.o obj-$(CONFIG_AT91_SAM9G45_RESET) += at91sam9g45_reset.o obj-$(CONFIG_AT91_SAM9_TIME) += at91sam926x_time.o diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c deleted file mode 100644 index 191e9e4..000 --- a/arch/arm/mach-at91/clock.c +++ /dev/null @@ -1,961 +0,0 @@ -/* - * linux/arch/arm/mach-at91/clock.c - * - * Copyright (C) 2005 David Brownell - * Copyright (C) 2005 Ivan Kokshaysky - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - */ - -#include linux/module.h -#include linux/kernel.h -#include linux/init.h -#include linux/fs.h -#include linux/debugfs.h -#include linux/seq_file.h -#include linux/list.h -#include linux/errno.h -#include linux/err.h -#include linux/spinlock.h -#include linux/delay.h -#include linux/clk.h -#include linux/io.h -#include linux/of_address.h -#include linux/clk/at91.h - -#include mach/hardware.h -#include mach/cpu.h - -#include asm/proc-fns.h - -#include clock.h -#include generic.h - -void __iomem *at91_pmc_base; -EXPORT_SYMBOL_GPL(at91_pmc_base); - -/* - * There's a lot more which can be done with clocks, including cpufreq - * integration, slow clock mode support (for system suspend), letting - * PLLB be used at other rates (on boards that don't need USB), etc. - */ - -#define clk_is_primary(x) ((x)-type CLK_TYPE_PRIMARY) -#define clk_is_programmable(x) ((x)-type CLK_TYPE_PROGRAMMABLE) -#define clk_is_peripheral(x) ((x)-type CLK_TYPE_PERIPHERAL) -#define clk_is_sys(x) ((x)-type CLK_TYPE_SYSTEM) - - -/* - * Chips have some kind of clocks : group them by functionality - */ -#define cpu_has_utmi() ( cpu_is_at91sam9rl() \ - || cpu_is_at91sam9g45() \ - || cpu_is_at91sam9x5() \ - || cpu_is_sama5d3()) - -#define cpu_has_1056M_plla() (cpu_is_sama5d3()) - -#define cpu_has_800M_plla()( cpu_is_at91sam9g20() \ - || cpu_is_at91sam9g45() \ - || cpu_is_at91sam9x5() \ - || cpu_is_at91sam9n12()) - -#define cpu_has_300M_plla()(cpu_is_at91sam9g10()) - -#define cpu_has_240M_plla()(cpu_is_at91sam9261() \ - || cpu_is_at91sam9263() \ - || cpu_is_at91sam9rl()) - -#define cpu_has_210M_plla()(cpu_is_at91sam9260()) - -#define cpu_has_pllb() (!(cpu_is_at91sam9rl() \ - || cpu_is_at91sam9g45() \ - || cpu_is_at91sam9x5() \ - || cpu_is_at91sam9n12())) - -#define cpu_has_upll() (cpu_is_at91sam9g45() \ - || cpu_is_at91sam9x5() \ - || cpu_is_sama5d3()) - -/* USB host HS FS */ -#define cpu_has_uhp() (!cpu_is_at91sam9rl()) - -/* USB device FS only */ -#define cpu_has_udpfs()(!(cpu_is_at91sam9rl() \ - || cpu_is_at91sam9g45() \ - || cpu_is_at91sam9x5() \ - || cpu_is_sama5d3())) - -#define cpu_has_plladiv2() (cpu_is_at91sam9g45() \ - || cpu_is_at91sam9x5() \ - || cpu_is_at91sam9n12() \ - || cpu_is_sama5d3()) - -#define cpu_has_mdiv3()(cpu_is_at91sam9g45() \ - || cpu_is_at91sam9x5() \ - || cpu_is_at91sam9n12() \ -
[PATCH v2] ethernet/arc/arc_emac - Add new driver
Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
instantiated in some legacy ARC (Synopsys) FPGA Boards such as
ARCAngel4/ML50x.
This is based off of current Linus tree, build tested for x86.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Reviewed-by: Vineet Gupta vgu...@synopsys.com
Reviewed-by: Mischa Jonker mjon...@synopsys.com
Cc: Vineet Gupta vgu...@synopsys.com
Cc: Mischa Jonker mjon...@synopsys.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Paul Gortmaker paul.gortma...@windriver.com
Cc: David S. Miller da...@davemloft.net
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
---
Hi all,
this is v2 respin of arc_emac driver.
Please find summary of changes below.
* Cosmetics as suggested by David Miller - mostly identation fixes in
accordance to the CodingStyle
* Get rid of extra header arc_emac_main.h. Its contents moved right
into arc_emac_main.c
* Merge PHY description in Ethernet entry in DT so it could be
accessed by of_mdiobus_register.
* Add dependences from OF_NET and OF_IRQ in Kconfig to make sure all
needed functions are avaialable.
* Add DT binding description.
* Use void __iomem * pointers for MMIO mappings instead of simple
void *
* Use devm_ioremap_resource instead of pair:
devm_request_mem_region devm_ioremap_nocache
---
Documentation/devicetree/bindings/net/arc_emac.txt | 32 +
drivers/net/ethernet/Kconfig |1 +
drivers/net/ethernet/Makefile |1 +
drivers/net/ethernet/arc/Kconfig | 31 +
drivers/net/ethernet/arc/Makefile |6 +
drivers/net/ethernet/arc/arc_emac_main.c | 956
drivers/net/ethernet/arc/arc_emac_mdio.c | 170
drivers/net/ethernet/arc/arc_emac_mdio.h | 22 +
drivers/net/ethernet/arc/arc_emac_regs.h | 72 ++
9 files changed, 1291 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/arc_emac.txt
create mode 100644 drivers/net/ethernet/arc/Kconfig
create mode 100644 drivers/net/ethernet/arc/Makefile
create mode 100644 drivers/net/ethernet/arc/arc_emac_main.c
create mode 100644 drivers/net/ethernet/arc/arc_emac_mdio.c
create mode 100644 drivers/net/ethernet/arc/arc_emac_mdio.h
create mode 100644 drivers/net/ethernet/arc/arc_emac_regs.h
diff --git a/Documentation/devicetree/bindings/net/arc_emac.txt
b/Documentation/devicetree/bindings/net/arc_emac.txt
new file mode 100644
index 000..4205581
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/arc_emac.txt
@@ -0,0 +1,32 @@
+* Synopsys ARC EMAC 10/100 Ethernet driver (EMAC)
+
+Required properties:
+- compatible: Should be snps,arc-emac
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the EMAC interrupts
+- clock-frequency: CPU frequency. It is needed to calculate and set polling
+period of EMAC.
+- phy: PHY device attached to the EMAC via MDIO bus
+
+Child nodes of the driver are the individual PHY devices connected to the
+MDIO bus. They must have a reg property given the PHY address on the MDIO
bus.
+
+Optional properties:
+- mac-address: 6 bytes, mac address
+
+Examples:
+
+ ethernet@c0fc2000 {
+ compatible = snps,arc-emac;
+ reg = 0xc0fc2000 0x3c;
+ interrupts = 6;
+ mac-address = [ 00 11 22 33 44 55 ];
+ clock-frequency = 8000;
+ phy = phy0;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ phy0: ethernet-phy@0 {
+ reg = 1;
+ };
+ };
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 4bedae2..98eec48 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -23,6 +23,7 @@ source drivers/net/ethernet/aeroflex/Kconfig
source drivers/net/ethernet/alteon/Kconfig
source drivers/net/ethernet/amd/Kconfig
source drivers/net/ethernet/apple/Kconfig
+source drivers/net/ethernet/arc/Kconfig
source drivers/net/ethernet/atheros/Kconfig
source drivers/net/ethernet/cadence/Kconfig
source drivers/net/ethernet/adi/Kconfig
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 183e3f4..b764c73 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_GRETH) += aeroflex/
obj-$(CONFIG_NET_VENDOR_ALTEON) += alteon/
obj-$(CONFIG_NET_VENDOR_AMD) += amd/
obj-$(CONFIG_NET_VENDOR_APPLE) += apple/
+obj-$(CONFIG_NET_VENDOR_ARC) += arc/
obj-$(CONFIG_NET_VENDOR_ATHEROS) += atheros/
obj-$(CONFIG_NET_CADENCE) += cadence/
obj-$(CONFIG_NET_BFIN) += adi/
diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig
new file mode 100644
index 000..514c57f
--- /dev/null
+++ b/drivers/net/ethernet/arc/Kconfig
@@ -0,0 +1,31 @@
+#
+# ARC EMAC network device
Re: Linux 3.0.80
On Fri, Jun 07, 2013 at 05:09:16PM +0800, Li Zefan wrote: On 2013/5/25 2:23, Greg KH wrote: I'm announcing the release of the 3.0.80 kernel. All users of the 3.0 kernel series must upgrade. The updated 3.0.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.0.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 +- drivers/hwmon/abituguru.c | 16 ++-- drivers/media/dvb/mantis/mantis_dvb.c |6 -- fs/btrfs/ioctl.c | 10 +- 4 files changed, 20 insertions(+), 14 deletions(-) 3.0.80 failed to boot, and looks like the culprit is blkcg, so I disabled CONFIG_CGROUP and it boot successfully. Did 3.0.79 boot properly with this same hardware / kernel configuration? If so, can you bisect it down to the problem commit please? I haven't tried 3.0.81, as it's not released yet. Give me a few hours, but odds are, it's not fixed, as I have not heard of this problem before. thanks, greg k-h -- 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, part1 04/10] PCI: mark pci_scan_bus_parented() as __deprecated
On 06/07/2013 10:37 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Jun 07, 2013 at 12:32:28AM +0800, Jiang Liu wrote:
On Thu 06 Jun 2013 04:04:36 AM CST, Bjorn Helgaas wrote:
[+cc Konrad, Jeremy, xen-devel (users of interface you're deprecating)]
On Sat, May 25, 2013 at 7:48 AM, Jiang Liu liu...@gmail.com wrote:
Mark pci_scan_bus_parented() as __deprecated and clean up outdated
comments.
Signed-off-by: Jiang Liu jiang@huawei.com
Cc: Chris Metcalf cmetc...@tilera.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Thierry Reding thierry.red...@avionic-design.de
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
arch/tile/kernel/pci.c | 3 ---
include/linux/pci.h| 4 ++--
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/tile/kernel/pci.c b/arch/tile/kernel/pci.c
index 67237d3..936e087 100644
--- a/arch/tile/kernel/pci.c
+++ b/arch/tile/kernel/pci.c
@@ -309,9 +309,6 @@ int __init pcibios_init(void)
*
* It reads the PCI tree for this bus into the
Linux
* data structures.
-*
-* This is inlined in linux/pci.h and calls into
-* pci_scan_bus_parented() in probe.c.
*/
pci_add_resource(resources, ioport_resource);
pci_add_resource(resources, iomem_resource);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index b0f4a82..7b23fa0 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -720,8 +720,8 @@ void pcibios_bus_to_resource(struct pci_dev *dev,
struct resource *res,
void pcibios_scan_specific_bus(int busn);
struct pci_bus *pci_find_bus(int domain, int busnr);
void pci_bus_add_devices(const struct pci_bus *bus);
-struct pci_bus *pci_scan_bus_parented(struct device *parent, int bus,
- struct pci_ops *ops, void *sysdata);
+struct pci_bus * __deprecated pci_scan_bus_parented(struct device *parent,
+ int bus, struct pci_ops *ops, void *sysdata);
struct pci_bus *pci_scan_bus(int bus, struct pci_ops *ops, void *sysdata);
struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
struct pci_ops *ops, void *sysdata,
I think this patch is a good idea, but I think we need to change the
only existing user of pci_scan_bus_parented() (pcifront_scan_root() in
drivers/pci/xen-pcifront.c) at the same time, so xen doesn't start
getting build warnings. The deprecation warnings are really intended
for out-of-tree users that we aren't able to fix ourselves.
I'm getting this series queued up in
http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/jiang-bus-lock-v3,
so if you want to send a patch just for xen, I can fold that in.
Bjorn
Hi Bjorn,
I have posted a big patch for that, but still need help from
Xen experts to review it.
Please refer to https://patchwork.kernel.org/patch/2578551/
Hm, I seem to get:
/home/konrad/linux/drivers/pci/xen-pcifront.c: In function
‘pcifront_free_roots’:
/home/konrad/linux/drivers/pci/xen-pcifront.c:559: error: implicit
declaration of function ‘for_each_pci_root_bus’
/home/konrad/linux/drivers/pci/xen-pcifront.c:559: error: expected ‘;’ before
‘{’ token
/home/konrad/linux/drivers/pci/xen-pcifront.c:554: warning: unused variable
‘sd’
with it? Is there an up-to-date patch?
I have these in my tree:
311db40 PCI, xen-pcifront: use new PCI interfaces to simplify implementation
4079fee Merge remote-tracking branch 'bjorn/pci/jiang-bus-lock-v3' into
testing
ddb7c6b PCI: Hide remove and rescan sysfs interfaces for SR-IOV virtual
functions
f5cfa3a PCI: Simplify IOV implementation and fix reference count races
28b4f07 PCI: Drop redundant setting of bus-is_added in virtfn_add_bus()
442655a unicore32/PCI: Remove redundant call of pci_bus_add_devices()
defd601 m68k/PCI: Remove redundant call of pci_bus_add_devices()
340e3fb PCI: Make PCI host bridge/bus creating and destroying logic symmetric
c7025f7 ia64/PCI: Clean up pci_scan_root_bus() usage
c1f41ce PCI: Mark pci_scan_bus_parented() as __deprecated
13e5057 PCI: Convert alloc_pci_dev(void) to pci_alloc_dev(bus)
007042a PCI: Introduce pci_alloc_dev(struct pci_bus*) to replace
alloc_pci_dev()
fe830ef PCI: Introduce pci_bus_{get|put}() to manage PCI bus reference count
Hi Konrad,
Thanks for review!
The patch PCI, xen-pcifront: use new PCI interfaces to simplify
implementation has dependency on part2 of the patch series, which
introduces for_each_pci_root_bus(). I have prepared a git tree for
you at:
git://github.com/jiangliu/linux.git pci_lock_v3
And I will try to split PCI, xen-pcifront: use new PCI interfaces
to simplify implementation into two patches, one is to kill
pci_scan_bus_parented(), the other is to use new
[RFC PATCH 14/50] ARM: at91: move at91sam9260 SoC to new at91 clk implem
This patch removes all references to the old at91 clks implementation and
make use of the new at91 clk implem for at91sam9260 SoC.
All dt specific lookups are removed (handled in clk device tree binding).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
arch/arm/mach-at91/at91sam9260.c | 692 +-
1 file changed, 457 insertions(+), 235 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index df32768..45a8169c 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -26,7 +26,6 @@
#include at91_rstc.h
#include soc.h
#include generic.h
-#include clock.h
#include sam9_smc.h
/*
@@ -36,255 +35,478 @@
/*
* The peripheral clocks.
*/
-static struct clk pioA_clk = {
- .name = pioA_clk,
- .pmc_mask = 1 AT91SAM9260_ID_PIOA,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
- .name = pioB_clk,
- .pmc_mask = 1 AT91SAM9260_ID_PIOB,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioC_clk = {
- .name = pioC_clk,
- .pmc_mask = 1 AT91SAM9260_ID_PIOC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk adc_clk = {
- .name = adc_clk,
- .pmc_mask = 1 AT91SAM9260_ID_ADC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk adc_op_clk = {
- .name = adc_op_clk,
- .type = CLK_TYPE_PERIPHERAL,
- .rate_hz= 500,
-};
-
-static struct clk usart0_clk = {
- .name = usart0_clk,
- .pmc_mask = 1 AT91SAM9260_ID_US0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
- .name = usart1_clk,
- .pmc_mask = 1 AT91SAM9260_ID_US1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
- .name = usart2_clk,
- .pmc_mask = 1 AT91SAM9260_ID_US2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc_clk = {
- .name = mci_clk,
- .pmc_mask = 1 AT91SAM9260_ID_MCI,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk udc_clk = {
- .name = udc_clk,
- .pmc_mask = 1 AT91SAM9260_ID_UDP,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi_clk = {
- .name = twi_clk,
- .pmc_mask = 1 AT91SAM9260_ID_TWI,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
- .name = spi0_clk,
- .pmc_mask = 1 AT91SAM9260_ID_SPI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
- .name = spi1_clk,
- .pmc_mask = 1 AT91SAM9260_ID_SPI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc_clk = {
- .name = ssc_clk,
- .pmc_mask = 1 AT91SAM9260_ID_SSC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc0_clk = {
- .name = tc0_clk,
- .pmc_mask = 1 AT91SAM9260_ID_TC0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc1_clk = {
- .name = tc1_clk,
- .pmc_mask = 1 AT91SAM9260_ID_TC1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc2_clk = {
- .name = tc2_clk,
- .pmc_mask = 1 AT91SAM9260_ID_TC2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ohci_clk = {
- .name = ohci_clk,
- .pmc_mask = 1 AT91SAM9260_ID_UHP,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk macb_clk = {
- .name = pclk,
- .pmc_mask = 1 AT91SAM9260_ID_EMAC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk isi_clk = {
- .name = isi_clk,
- .pmc_mask = 1 AT91SAM9260_ID_ISI,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart3_clk = {
- .name = usart3_clk,
- .pmc_mask = 1 AT91SAM9260_ID_US3,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart4_clk = {
- .name = usart4_clk,
- .pmc_mask = 1 AT91SAM9260_ID_US4,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart5_clk = {
- .name = usart5_clk,
- .pmc_mask = 1 AT91SAM9260_ID_US5,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc3_clk = {
- .name = tc3_clk,
- .pmc_mask = 1 AT91SAM9260_ID_TC3,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc4_clk = {
- .name = tc4_clk,
- .pmc_mask = 1 AT91SAM9260_ID_TC4,
-
Re: [PATCHv4 20/39] thp, mm: naive support of thp in generic read/write routines
Dave Hansen wrote:
On 05/11/2013 06:23 PM, Kirill A. Shutemov wrote:
+ if (PageTransHuge(page))
+ offset = pos ~HPAGE_PMD_MASK;
+
pagefault_disable();
- copied = iov_iter_copy_from_user_atomic(page, i, offset, bytes);
+ copied = iov_iter_copy_from_user_atomic(
+ page + (offset PAGE_CACHE_SHIFT),
+ i, offset ~PAGE_CACHE_MASK, bytes);
pagefault_enable();
flush_dcache_page(page);
I think there's enough voodoo in there to warrant a comment or adding
some temporary variables. There are three things going on that you wan
to convey:
1. Offset is normally PAGE_SIZE, but you make it HPAGE_PMD_SIZE if
you are dealing with a huge page
2. (offset PAGE_CACHE_SHIFT) is always 0 for small pages since
offset PAGE_SIZE
3. offset ~PAGE_CACHE_MASK does nothing for small-page offsets, but
it turns a large-page offset back in to a small-page-offset.
I think you can do it with something like this:
int subpage_nr = 0;
off_t smallpage_offset = offset;
if (PageTransHuge(page)) {
// we transform 'offset' to be offset in to the huge
// page instead of inside the PAGE_SIZE page
offset = pos ~HPAGE_PMD_MASK;
subpage_nr = (offset PAGE_CACHE_SHIFT);
}
+ copied = iov_iter_copy_from_user_atomic(
+ page + subpage_nr,
+ i, smallpage_offset, bytes);
@@ -2437,6 +2453,7 @@ again:
* because not all segments in the iov can be copied at
* once without a pagefault.
*/
+ offset = pos ~PAGE_CACHE_MASK;
Urg, and now it's *BACK* in to a small-page offset?
This means that 'offset' has two _different_ meanings and it morphs
between them during the function a couple of times. That seems very
error-prone to me.
I guess this way is better, right?
@@ -2382,6 +2393,7 @@ static ssize_t generic_perform_write(struct file *file,
unsigned long bytes;/* Bytes to write to page */
size_t copied; /* Bytes copied from user */
void *fsdata;
+ int subpage_nr = 0;
offset = (pos (PAGE_CACHE_SIZE - 1));
bytes = min_t(unsigned long, PAGE_CACHE_SIZE - offset,
@@ -2411,8 +2423,14 @@ again:
if (mapping_writably_mapped(mapping))
flush_dcache_page(page);
+ if (PageTransHuge(page)) {
+ off_t huge_offset = pos ~HPAGE_PMD_MASK;
+ subpage_nr = huge_offset PAGE_CACHE_SHIFT;
+ }
+
pagefault_disable();
- copied = iov_iter_copy_from_user_atomic(page, i, offset, bytes);
+ copied = iov_iter_copy_from_user_atomic(page + subpage_nr, i,
+ offset, bytes);
pagefault_enable();
flush_dcache_page(page);
--
Kirill A. Shutemov
--
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: NULL pointer dereference when loading the gre module (3.10.0-rc4)
On Fri, 2013-06-07 at 06:40 -0700, Eric Dumazet wrote:
On Fri, 2013-06-07 at 10:54 +0200, Steinar H. Gunderson wrote:
On Thu, Jun 06, 2013 at 11:06:48PM -0400, Steven Rostedt wrote:
Note the faulting address is 0xa0e52001, which is around the
above address, be interesting to know what was at that location.
Doh, I looked at the wrong place in kallsyms:
a0e52000 u ip_tunnel_init_net [ip_gre]
a0e55000 t gre_err [gre]
a0e5503d t gre_gso_send_check [gre]
a0e55053 t gre_rcv [gre]
So it's really ip_tunnel_init_net+1.
/* Steinar */
u for ip_tunnel_init_net ?
Looks like someone forgot taking refcounts on a module ...
CC Pravin B Shelar, as this probably comes from commit
c54419321455631079c7d6e60bc732dd0c5914c5
(GRE: Refactor GRE tunneling code.)
int __net_init ip_tunnel_init_net(struct net *net, int ip_tnl_net_id,
struct rtnl_link_ops *ops, char *devname)
{
[...]
}
EXPORT_SYMBOL_GPL(ip_tunnel_init_net);
Really, you exported a symbol that can go away if CONFIG_NET_NS is not
set?
net: Remove __net_init/exit from exported functions
If CONFIG_NET_NS is not set then __net_init is the same as __init and
__net_exit is the same as __exit. These functions will be removed from
memory after the module loads or is removed. Functions that are exported
for use by other functions should never be labeled for removal.
Signed-off-by: Steven Rostedt rost...@goodmis.org
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index e4147ec..850b5b5 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -853,8 +853,8 @@ void ip_tunnel_dellink(struct net_device *dev, struct
list_head *head)
}
EXPORT_SYMBOL_GPL(ip_tunnel_dellink);
-int __net_init ip_tunnel_init_net(struct net *net, int ip_tnl_net_id,
- struct rtnl_link_ops *ops, char *devname)
+int ip_tunnel_init_net(struct net *net, int ip_tnl_net_id,
+ struct rtnl_link_ops *ops, char *devname)
{
struct ip_tunnel_net *itn = net_generic(net, ip_tnl_net_id);
struct ip_tunnel_parm parms;
@@ -899,7 +899,7 @@ static void ip_tunnel_destroy(struct ip_tunnel_net *itn,
struct list_head *head)
unregister_netdevice_queue(itn-fb_tunnel_dev, head);
}
-void __net_exit ip_tunnel_delete_net(struct ip_tunnel_net *itn)
+void ip_tunnel_delete_net(struct ip_tunnel_net *itn)
{
LIST_HEAD(list);
--
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] dmaengine: at_hdmac: remove unsuded atc_cleanup_descriptors()
Since patch 7c407d3e54dcc0c79119553c8d5ef176c1d5bc3a (DMA: AT91:
Get residual bytes in dma buffer), the function
atc_cleanup_descriptors() is not used anymore. We remove it to prevent
warnings.
Reported-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
drivers/dma/at_hdmac.c | 31 ---
1 file changed, 31 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 4499dcf..50953a7 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -417,37 +417,6 @@ static void atc_complete_all(struct at_dma_chan *atchan)
}
/**
- * atc_cleanup_descriptors - cleanup up finished descriptors in active_list
- * @atchan: channel to be cleaned up
- *
- * Called with atchan-lock held and bh disabled
- */
-static void atc_cleanup_descriptors(struct at_dma_chan *atchan)
-{
- struct at_desc *desc, *_desc;
- struct at_desc *child;
-
- dev_vdbg(chan2dev(atchan-chan_common), cleanup descriptors\n);
-
- list_for_each_entry_safe(desc, _desc, atchan-active_list, desc_node) {
- if (!(desc-lli.ctrla ATC_DONE))
- /* This one is currently in progress */
- return;
-
- list_for_each_entry(child, desc-tx_list, desc_node)
- if (!(child-lli.ctrla ATC_DONE))
- /* Currently in progress */
- return;
-
- /*
-* No descriptors so far seem to be in progress, i.e.
-* this chain must be done.
-*/
- atc_chain_complete(atchan, desc);
- }
-}
-
-/**
* atc_advance_work - at the end of a transaction, move forward
* @atchan: channel where the transaction ended
*
--
1.8.2.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: [RFC PATCH v2, part3 07/11] PCI, xen-pcifront: use new PCI interfaces to simplify implementation
On Fri 07 Jun 2013 10:50:24 PM CST, Konrad Rzeszutek Wilk wrote: On Thu, May 16, 2013 at 11:50:55PM +0800, Jiang Liu wrote: Use new PCI interfaces to simplify xen-pcifront implementation: 1) Use pci_create_root_bus() instead of pci_scan_bus_parented() because pci_scan_bus_parented() is marked as __deprecated.This also gets rid of a duplicated call of pci_bus_start_devices(). 2) Use pci_stop_root_bus() and pci_remove_root_bus() instead of open-coded private implementation. 3) Use pci_set_host_bridge_release() to release data structures associated with PCI root buses. 4) Use pci_bus_get()/pci_bus_put() to manage PCI root bus reference count. This is also a preparation for coming PCI bus lock enhancement. Signed-off-by: Jiang Liu jiang@huawei.com Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: Jeremy Fitzhardinge jer...@goop.org Cc: xen-de...@lists.xensource.com Cc: virtualizat...@lists.linux-foundation.org Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/pci/xen-pcifront.c | 81 ++ 1 file changed, 39 insertions(+), 42 deletions(-) diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c index 816cf94..6aa2c0f 100644 --- a/drivers/pci/xen-pcifront.c +++ b/drivers/pci/xen-pcifront.c .. @@ -480,12 +490,14 @@ static int pcifront_scan_root(struct pcifront_device *pdev, goto err_out; } -bus_entry-bus = b; +pci_set_host_bridge_release(to_pci_host_bridge(b-bridge), +pcifront_release_sd, sd); -list_add(bus_entry-list, pdev-root_buses); - -/* pci_scan_bus_parented skips devices which do not have a have -* devfn==0. The pcifront_scan_bus enumerates all devfn. */ +/* + * Every PCI physical device should have function 0, but that's not + * true for xen. That is incorrect. There are two types of backends - one of them will start at zero, but the other might not. Hi Konrad, Forgive my poor knowledge about Xen:(, so I will skip this change. Regards! Gerry -- 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/53] Input: atmel_mxt_ts - Add memory access interface via sysfs
Mark Brown wrote: On Thu, Jun 06, 2013 at 05:13:32PM +0100, Nick Dyer wrote: I am not a legal expert, but I have described what you suggest to people who are more expert in the NDA terms and they say I cannot implement a solution which exposes the names of all the parameters. In any case, Who said anything about names? I'd assume the userspace stuff is eventually talking to the device based on numbers of some kind and I'd expect that this would be what ends up in the API. OK. But if user-space is talking to the device based on register numbers, a binary attribute seems like the correct way to present that - isn't that what they're designed for? And we wouldn't have won anything, because the user could still write to the register that turns off reporting (for example) by mistake with both methods. You'd not have access to the entire device register map which seems like a win Not really. The chip itself will enforce which registers are read-only (by ignoring writes) or write-only (by returning zeros if read). Encoding all this information in the driver would just make it more brittle in the face of touch controller firmware updates. It would be possible for the driver to intermediate for some of the registers that it cares about. For example, if we change the screen width then the driver could reinitialise the input device. But I can't see that it makes sense if you are changing several settings in a row for the input device to be reinitialised several times. It is far less buggy to provide a single way of tearing down everything and reinitialising (which could be simply triggered from user space) than to encode all of the dependencies (which is bound to introduce bugs). It's not laziness, it's trying to push policy into user space. Touch controllers are inherently complex system with a lot of configurable parameters. The fact that it's complex and changes quickly doesn't make it badly designed per se. Having lots of configuration and having the parameters change regularly doesn't immediately mean that it has to be complex - the requirement is very common, touchscreens aren't too remarkable here. The usual thing is for the kernel to understand how to transfer data back and forth but not the content of the data. Sure, that's what I'm trying to accomplish. It's just that as far as I can see it makes more sense to use the established protocol that these chips have implemented rather than trying to bodge something else over the top or crowbar it into a different model that will cause abstraction problems. We have thought about this problem at great length, and discussed it on these lists, and with other kernel engineers at customers, etc. -- 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/
[RFC PATCH 15/50] ARM: at91: move at91sam9261 SoC to new at91 clk implem
This patch removes all references to the old at91 clks implementation and
make use of the new at91 clk implem for at91sam9261 SoC.
All dt specific lookups are removed (handled in clk device tree binding).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
arch/arm/mach-at91/at91sam9261.c | 579 +-
1 file changed, 383 insertions(+), 196 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
index 8a63b81..ccc2bcc 100644
--- a/arch/arm/mach-at91/at91sam9261.c
+++ b/arch/arm/mach-at91/at91sam9261.c
@@ -25,7 +25,6 @@
#include at91_rstc.h
#include soc.h
#include generic.h
-#include clock.h
#include sam9_smc.h
/*
@@ -35,216 +34,404 @@
/*
* The peripheral clocks.
*/
-static struct clk pioA_clk = {
- .name = pioA_clk,
- .pmc_mask = 1 AT91SAM9261_ID_PIOA,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
- .name = pioB_clk,
- .pmc_mask = 1 AT91SAM9261_ID_PIOB,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioC_clk = {
- .name = pioC_clk,
- .pmc_mask = 1 AT91SAM9261_ID_PIOC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
- .name = usart0_clk,
- .pmc_mask = 1 AT91SAM9261_ID_US0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
- .name = usart1_clk,
- .pmc_mask = 1 AT91SAM9261_ID_US1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
- .name = usart2_clk,
- .pmc_mask = 1 AT91SAM9261_ID_US2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc_clk = {
- .name = mci_clk,
- .pmc_mask = 1 AT91SAM9261_ID_MCI,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk udc_clk = {
- .name = udc_clk,
- .pmc_mask = 1 AT91SAM9261_ID_UDP,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi_clk = {
- .name = twi_clk,
- .pmc_mask = 1 AT91SAM9261_ID_TWI,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
- .name = spi0_clk,
- .pmc_mask = 1 AT91SAM9261_ID_SPI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
- .name = spi1_clk,
- .pmc_mask = 1 AT91SAM9261_ID_SPI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc0_clk = {
- .name = ssc0_clk,
- .pmc_mask = 1 AT91SAM9261_ID_SSC0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc1_clk = {
- .name = ssc1_clk,
- .pmc_mask = 1 AT91SAM9261_ID_SSC1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc2_clk = {
- .name = ssc2_clk,
- .pmc_mask = 1 AT91SAM9261_ID_SSC2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc0_clk = {
- .name = tc0_clk,
- .pmc_mask = 1 AT91SAM9261_ID_TC0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc1_clk = {
- .name = tc1_clk,
- .pmc_mask = 1 AT91SAM9261_ID_TC1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc2_clk = {
- .name = tc2_clk,
- .pmc_mask = 1 AT91SAM9261_ID_TC2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ohci_clk = {
- .name = ohci_clk,
- .pmc_mask = 1 AT91SAM9261_ID_UHP,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk lcdc_clk = {
- .name = lcdc_clk,
- .pmc_mask = 1 AT91SAM9261_ID_LCDC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-
-/* HClocks */
-static struct clk hck0 = {
- .name = hck0,
- .pmc_mask = AT91_PMC_HCK0,
- .type = CLK_TYPE_SYSTEM,
- .id = 0,
-};
-static struct clk hck1 = {
- .name = hck1,
- .pmc_mask = AT91_PMC_HCK1,
- .type = CLK_TYPE_SYSTEM,
- .id = 1,
-};
-
-static struct clk *periph_clocks[] __initdata = {
- pioA_clk,
- pioB_clk,
- pioC_clk,
- usart0_clk,
- usart1_clk,
- usart2_clk,
- mmc_clk,
- udc_clk,
- twi_clk,
- spi0_clk,
- spi1_clk,
- ssc0_clk,
- ssc1_clk,
- ssc2_clk,
- tc0_clk,
- tc1_clk,
- tc2_clk,
- ohci_clk,
- lcdc_clk,
- // irq0 .. irq2
-};
-
-static struct clk_lookup periph_clocks_lookups[] = {
- CLKDEV_CON_DEV_ID(hclk, at91sam9261-lcdfb.0, hck1),
- CLKDEV_CON_DEV_ID(hclk,
Re: [PATCH v2 1/8] clk: flag to use upper half of the register as change indicator
On 7 June 2013 20:27, Heiko Stübner he...@sntech.de wrote:
Am Freitag, 7. Juni 2013, 13:46:32 schrieb Linus Walleij:
On Thu, Jun 6, 2013 at 9:08 PM, Heiko Stübner he...@sntech.de wrote:
There exist platforms, namely at least all Rockchip Cortex-A9 based ones,
that don't use the paradigm of reading-changing-writing the register
contents, but instead only write the changes to the register with a mask
that indicates the changed bits.
This patch adds flags and code to support the case where the lower 16 bit
of hold the information and the upper 16 bit are used as mask to
indicate the written changes.
As hardware-specific flags should not be added to the common clk flags,
the flags are added to gate, mux and divider clocks individually.
Signed-off-by: Heiko Stuebner he...@sntech.de
(...)
+ if ((clk_gate_flags CLK_GATE_MASK_UPPER_HALF) bit_idx 15)
{ + pr_err(%s: bit_idx %d invalid\n, __func__, bit_idx);
+ return ERR_PTR(-EINVAL);
+ }
Now this looks *EXTREMELY* familiar to a patch just sent by Haojian
for HiSilicon.
[PATCH v2 3/6] clk: divider: add CLK_DIVIDER_HIWORD_MASK flag
http://marc.info/?l=linux-arm-kernelm=137035873916777w=2
What kind of coincidence is this? Are Rockchip and HiSilicon using
the same silicon IP or are they of a common origin? (It is a small
world after all.)
Now this is really interesting :-) and the handling really seems to follow the
same pattern.
I think you two guys need to read each others patch sets closely
here. I'd like Haojian to look at Heiko's patches and Heiko to look
at Haojian's patches, just to make sure you're not actually writing
two drivers for the same hardware in the end.
I'll take a look
Heiko
Me too :)
Regards
Haojian
--
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: power-efficient scheduling design
On 6/6/2013 11:03 PM, Preeti U Murthy wrote: Hi, On 05/31/2013 04:22 PM, Ingo Molnar wrote: PeterZ and me tried to point out the design requirements previously, but it still does not appear to be clear enough to people, so let me spell it out again, in a hopefully clearer fashion. The scheduler has valuable power saving information available: - when a CPU is busy: about how long the current task expects to run - when a CPU is idle: how long the current CPU expects _not_ to run - topology: it knows how the CPUs and caches interrelate and already optimizes based on that and I will argue we do too much of this already; various caches (and tlbs) get flushed (on x86 at least) much much more than you'd think. so the scheduler is in an _ideal_ position to do a judgement call about the near future this part I will buy and estimate how deep an idle state a CPU core should enter into and what frequency it should run at. this part I cannot buy. First of all, we really need to stop thinking about choosing frequency (at least for x86). that concept basically died for x86 6 years ago. Second, the interactions between these two, and the what does it mean if I chose something is highly hardware specific and complex nowadays, and going forward is going to be increasingly so. If anything, we've been moving AWAY from centralized infrastructure there, going towards CPU specific drivers/policies. And hardware rules are very different between platforms here. On Intel, asking for different performance is just an MSR write, and going idle is usually just one instruction. On some ARM, this might involve a long complex interaction calculations, or even *blocking* operation manipulating VRs and PLLs directly... depending on the platform and the states you want to pick. (Hence the CPUFREQ design of requiring changes to be done in a kernel thread) Now, I would like the scheduler to give some notifications at certain events (like migrations, starting realtime tasks)...but a few atomic notifier chains will do for that. The policies will be very hardware specific, and thus will live outside the scheduler, no matter which way you put it. Now, the scheduler can and should participate more in terms of sharing information in both directions... that I think we can all agree on. -- 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/
©2013 WEBMASTER VERIFICATION
This message is from WEBMASTER HELP DESK messaging center to all WEBMAIL ACCOUNT OWNERS.As you have refused not to update your Email Account, it will be closed within 24hours if not verified because your E-mail account has exceeded its limit and needs to be verified.Click and fill the link below for verification to avoid loosing your E-mail account. Click Here: http://edoskynnmike.formmule.com/form.php?id=3yfEXEmjD0l6Ohhv ®Email Help Desk, Monday – Friday from 6:00AM to 1:00AM Saturday and Sunday 7:00AM Webmaster Help Desk. System Administrator -- 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] dmaengine: at_hdmac: remove unsuded atc_cleanup_descriptors()
On Friday 07 June 2013 17:15:29 Nicolas Ferre wrote: Since patch 7c407d3e54dcc0c79119553c8d5ef176c1d5bc3a (DMA: AT91: Get residual bytes in dma buffer), the function atc_cleanup_descriptors() is not used anymore. We remove it to prevent warnings. Reported-by: Arnd Bergmann a...@arndb.de Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.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: [BUG] non-swapcache page in end_swap_bio_read()
Hello Artem, On Fri, Jun 07, 2013 at 04:59:09PM +0400, Artem Savkov wrote: Hello all, I'm hitting the following BUG_ON during boot when CONFIG_PM_STD_PARTITION or resume kernel boot option are set. Looks like this issue was introduced in (or brought up to light by) mm: remove compressed copy from zram in-memory (84e5bb4f06e6d6f0c4dfc033b4700702ed8aaccc in linux-next.git) What happens is that during swsusp_check() bio is created with bio_end_io set to end_swap_bio_read(), but the page is not in swap cache. True. I totally missed it. Not sure how to handle this the right way, but proceeding with the optimization in end_swap_bio_read() only after checking PageSwapCache flag does help. I'd like to go with your way. We already have SetPageUptodate so PageSwapCache's cost would be really cheap from hitting from cacheline. Even, we can optimize it with unlikely hint. The credit should be yours so could you send a patch with your SOB? Please write a comment in code about that why we need such check. If you have any problem about sending a patch, I will send it for you on Monday if others don't suggest another solution. Thanks for the report! [2.065206] kernel BUG at mm/swapfile.c:2361! [2.065469] invalid opcode: [#1] SMP [2.065469] Modules linked in: [2.065469] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.10.0-rc4-next-20130607+ #61 [2.065469] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 [2.065469] task: 88001e5ccfc0 ti: 88001e5ea000 task.ti: 88001e5ea000 [2.065469] RIP: 0010:[811462eb] [811462eb] page_swap_info+0xab/0xb0 [2.065469] RSP: :88001ec03c78 EFLAGS: 00010246 [2.065469] RAX: 0109 RBX: ea794780 RCX: 0c0b [2.065469] RDX: 0046 RSI: RDI: [2.065469] RBP: 88001ec03c88 R08: R09: [2.065469] R10: R11: R12: [2.065469] R13: 0001 R14: 88001e7f6200 R15: 1000 [2.065469] FS: () GS:88001ec0() knlGS: [2.065469] CS: 0010 DS: ES: CR0: 8005003b [2.065469] CR2: CR3: 0240b000 CR4: 06e0 [2.065469] DR0: DR1: DR2: [2.065469] DR3: DR6: 0ff0 DR7: 0400 [2.065469] Stack: [2.065469] ea794780 88001e7f6200 88001ec03cb8 81145486 [2.065469] 88001e5cd5c0 88001c02cd20 1000 [2.065469] 88001ec03cc8 81199518 88001ec03d28 81518ec3 [2.065469] Call Trace: [2.065469] IRQ [2.065469] [81145486] end_swap_bio_read+0x96/0x130 [2.065469] [81199518] bio_endio+0x18/0x40 [2.065469] [81518ec3] blk_update_request+0x213/0x540 [2.065469] [81518fa0] ? blk_update_request+0x2f0/0x540 [2.065469] [817986a6] ? ata_hsm_qc_complete+0x46/0x130 [2.065469] [81519212] blk_update_bidi_request+0x22/0x90 [2.065469] [8151b9ea] blk_end_bidi_request+0x2a/0x80 [2.065469] [8151ba8b] blk_end_request+0xb/0x10 [2.065469] [817693aa] scsi_io_completion+0xaa/0x6b0 [2.065469] [817608d8] scsi_finish_command+0xc8/0x130 [2.065469] [81769aff] scsi_softirq_done+0x13f/0x160 [2.065469] [81521ebc] blk_done_softirq+0x7c/0x90 [2.065469] [81049030] __do_softirq+0x130/0x3f0 [2.065469] [810d454e] ? handle_irq_event+0x4e/0x70 [2.065469] [81049405] irq_exit+0xa5/0xb0 [2.065469] [81003cb1] do_IRQ+0x61/0xe0 [2.065469] [81c2832f] common_interrupt+0x6f/0x6f [2.065469] EOI [2.065469] [8107ebff] ? local_clock+0x4f/0x60 [2.065469] [81c27f85] ? _raw_spin_unlock_irq+0x35/0x50 [2.065469] [81c27f7b] ? _raw_spin_unlock_irq+0x2b/0x50 [2.065469] [81078bd0] finish_task_switch+0x80/0x110 [2.065469] [81078b93] ? finish_task_switch+0x43/0x110 [2.065469] [81c2525c] __schedule+0x32c/0x8c0 [2.065469] [81c2c010] ? notifier_call_chain+0x150/0x150 [2.065469] [81c259d4] schedule+0x24/0x70 [2.065469] [81c25d42] schedule_preempt_disabled+0x22/0x30 [2.065469] [81093645] cpu_startup_entry+0x335/0x380 [2.065469] [81c1ed7e] start_secondary+0x217/0x219 [2.065469] Code: 69 bc 16 82 48 c7 c7 77 bc 16 82 31 c0 49 c1 ec 39 49 c1 e9 10 41 83 e1 01 e8 6c d2 ad 00 5b 4a 8b 04 e5 e0 bf 14 83 41 5c c9 c3 0f 0b eb fe 90 48 8b 07 55 48 89 e5 a9 00 00 01 00 74 12 e8 3d [2.065469] RIP [811462eb] page_swap_info+0xab/0xb0 [2.065469
[PATCH] dmaengine/trivial: at_hdmac: add curly brackets to if/else expressions
Correct coding style following the patch:
7c407d3e54dcc0c79119553c8d5ef176c1d5bc3a (DMA: AT91:
Get residual bytes in dma buffer).
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
drivers/dma/at_hdmac.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 50953a7..b321562 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -299,8 +299,9 @@ static int atc_get_bytes_left(struct dma_chan *chan)
if (atchan-remain_desc 0) {
ret = -EINVAL;
goto out;
- } else
+ } else {
ret = atchan-remain_desc;
+ }
} else {
/*
* Get residual bytes when current
@@ -1120,8 +1121,9 @@ atc_tx_status(struct dma_chan *chan,
if (unlikely(bytes 0)) {
dev_vdbg(chan2dev(chan), get residual bytes error\n);
return DMA_ERROR;
- } else
+ } else {
dma_set_residue(txstate, bytes);
+ }
dev_vdbg(chan2dev(chan), tx_status %d: cookie = %d residue = %d\n,
ret, cookie, bytes);
--
1.8.2.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/
[RFC PATCH 19/50] ARM: at91: move at91sam9rl SoC to new at91 clk implem
This patch removes all references to the old at91 clks implementation and
make use of the new at91 clk implem for at91sam9rl SoC.
All dt specific lookups are removed (handled in clk device tree binding).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
arch/arm/mach-at91/at91sam9rl.c | 512 ---
1 file changed, 323 insertions(+), 189 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c
index 6fbda1a..a066685 100644
--- a/arch/arm/mach-at91/at91sam9rl.c
+++ b/arch/arm/mach-at91/at91sam9rl.c
@@ -25,7 +25,6 @@
#include at91_rstc.h
#include soc.h
#include generic.h
-#include clock.h
#include sam9_smc.h
/*
@@ -35,207 +34,342 @@
/*
* The peripheral clocks.
*/
-static struct clk pioA_clk = {
- .name = pioA_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_PIOA,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
- .name = pioB_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_PIOB,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioC_clk = {
- .name = pioC_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_PIOC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioD_clk = {
- .name = pioD_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_PIOD,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
- .name = usart0_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_US0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
- .name = usart1_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_US1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
- .name = usart2_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_US2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart3_clk = {
- .name = usart3_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_US3,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc_clk = {
- .name = mci_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_MCI,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi0_clk = {
- .name = twi0_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_TWI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi1_clk = {
- .name = twi1_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_TWI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi_clk = {
- .name = spi_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_SPI,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc0_clk = {
- .name = ssc0_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_SSC0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc1_clk = {
- .name = ssc1_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_SSC1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc0_clk = {
- .name = tc0_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_TC0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc1_clk = {
- .name = tc1_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_TC1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc2_clk = {
- .name = tc2_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_TC2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pwm_clk = {
- .name = pwm_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_PWMC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tsc_clk = {
- .name = tsc_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_TSC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk dma_clk = {
- .name = dma_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_DMA,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk udphs_clk = {
- .name = udphs_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_UDPHS,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk lcdc_clk = {
- .name = lcdc_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_LCDC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ac97_clk = {
- .name = ac97_clk,
- .pmc_mask = 1 AT91SAM9RL_ID_AC97C,
- .type = CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk *periph_clocks[] __initdata = {
- pioA_clk,
- pioB_clk,
- pioC_clk,
- pioD_clk,
- usart0_clk,
- usart1_clk,
- usart2_clk,
- usart3_clk,
- mmc_clk,
- twi0_clk,
- twi1_clk,
- spi_clk,
- ssc0_clk,
-
Re: [PATCHv4 20/39] thp, mm: naive support of thp in generic read/write routines
On 06/07/2013 08:17 AM, Kirill A. Shutemov wrote:
snip
I guess this way is better, right?
@@ -2382,6 +2393,7 @@ static ssize_t generic_perform_write(struct file *file,
unsigned long bytes;/* Bytes to write to page */
size_t copied; /* Bytes copied from user */
void *fsdata;
+ int subpage_nr = 0;
offset = (pos (PAGE_CACHE_SIZE - 1));
bytes = min_t(unsigned long, PAGE_CACHE_SIZE - offset,
@@ -2411,8 +2423,14 @@ again:
if (mapping_writably_mapped(mapping))
flush_dcache_page(page);
+ if (PageTransHuge(page)) {
+ off_t huge_offset = pos ~HPAGE_PMD_MASK;
+ subpage_nr = huge_offset PAGE_CACHE_SHIFT;
+ }
+
pagefault_disable();
- copied = iov_iter_copy_from_user_atomic(page, i, offset,
bytes);
+ copied = iov_iter_copy_from_user_atomic(page + subpage_nr, i,
+ offset, bytes);
pagefault_enable();
flush_dcache_page(page);
That looks substantially easier to understand to me. Nice.
--
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 00/50] ARM: at91: move to common clk framework
On 07/06/2013 11:22, Nicolas Ferre wrote: On 07/06/2013 10:34, Boris BREZILLON : Hello, This patch series is a proposal to move at91 clock implementation to common clk framework. Before discussion begins I would like to give my kudos to you Boris! This is huge work and I thank you for it: It is so great! I am sure that Jean-Christophe will have his idea on that because he told me that he thought a little bit about that, but I am sure that we will come to a quick and seamlessly integration soon. (Hey, I know it is not technical email, but I am so exited to see this happen that the noise worth it! ;-)) I received several notifications about filtered mails. Could you tell me if you received the whole series ? And do you know why this could have been filtered ? Most of the clock provided by the PMC (Power Management Controller) are implemented : - main clock (main oscillator) - pll clocks - master clock - programmable clocks - utmi clock - peripheral clocks - system clocks This implementation is compatible with device tree: the goal is to define the whole clock tree in the device tree (all currently available dt SoCs and boards are patched to support dt clocks). Please feel free to comment the dt bindinds (I'm not sure about the name I choose or the position of clock nodes: children of pmc node). I removed the register_clocks function in SoC supporting dt boards only: - at91sam9x5 SoCs - at91sam9n12 SoC - sama5d3 SoCs This patch series also update at91 drivers calling clk_enable/disable instead of the preferred clk_prepare_enable/disable_unprepare functions. I know there are a lot of cleanup in progress for at91 arch, so please tell me if you think this transition to common clk framework should wait. This patch series has been tested on Kizbox (sam9g20 SoC) board using device tree. It compiles for other SoCs and both with and without dt support, but it has not been tested. The clocks rate/parent change has not been tested. Best Regards, Boris Boris BREZILLON (50): ARM: at91: move arch/arm/mach-at91/include/mach/at91_pmc.h to include/linux/clk/at91.h ARM: at91: add PMC main clock using common clk framework. ARM: at91: add PMC pll clocks support using common clk framework. ARM: at91: add PMC master clock support using common clk framework. ARM: at91: add PMC system clocks support using common clk framework. ARM: at91: add PMC peripheral clocks support using common clk framework. ARM: at91: add PMC programmable clocks support using common clk framework. ARM: at91: add PMC utmi clock support using common clk framework. ARM: at91: add PMC usb clock support using common clk framework. ARM: at91: add PMC smd clock support using common clk framework. ARM: at91: add PMC clk device tree binding doc. ARM: at91: move to common clk framework. ARM: at91: move at91rm9200 SoC to common clk framework. ARM: at91: move at91sam9260 SoC to common clk framework. ARM: at91: move at91sam9263 SoC to common clk framework. ARM: at91: move at91sam9263 SoC to common clk framework. ARM: at91: move at91sam9g45 SoC to common clk framework. ARM: at91: move at91sam9n12 SoC to common clk framework. ARM: at91: move at91sam9rl SoC to common clk framework. ARM: at91: move at91sam9x5 SoCs to common clk framework. ARM: at91: move at91sam9 SoCs to common clk framework. ARM: at91: move sama5d3 SoCs to common clk framework. ARM: at91: move at91rm9200 non dt boards to common clk framework. ARM: at91: move at91sam9 non dt boards to common clk framework. ARM: at91: move pit timer to common clk framework. ARM: at91/tc/clocksource: replace clk_enable/disable with clk_prepare_enable/disable_unprepare. at_hdmac: replace clk_enable/disable with clk_prepare_enable/disable_unprepare. ASoC: atmel-ssc: replace clk_enable/disable with clk_prepare_enable/disable_unprepare. mmc: atmel-mci: replace clk_enable/disable with clk_prepare_enable/disable_unprepare. pwm: atmel-tcb: replace clk_enable/disable with clk_prepare_enable/disable_unprepare. tty: atmel_serial: replace clk_enable/disable with clk_prepare_enable/disable_unprepare. usb: gadget: at91_udc: replace clk_enable/disable with clk_prepare_enable/disable_unprepare. drivers/usb/host/ehci-atmel.c: replace clk_enable/disable with clk_prepare_enable/disable_unprepare. USB: ohci-at91: replace clk_enable/disable with clk_prepare_enable/disable_unprepare. ARM: at91/avr32/atmel_lcdfb: replace clk_enable/disable with clk_prepare_enable/disable_unprepare. ARM: at91/dt: move at91rm9200 SoC to clk framework. ARM: at91/dt: move at91sam9260 SoC to common clk framework. ARM: at91/dt: move at91sam9263 SoC to common clk framework. ARM: at91/dt: move at91sam9g45 SoC to common clk framework. ARM: at91/dt: move at91sam9n12 SoC to common clk framework. ARM: at91/dt: move at91sam9x5 SoCs to common clk framework.
Re: [RFC PATCH 02/50] ARM: at91: add PMC main clock
Dear Boris BREZILLON, On Fri, 7 Jun 2013 16:24:10 +0200, Boris BREZILLON wrote: + * This mainram is free software; you can redistribute it and/or modify Looks like you did some funky 'sed' over your source files. In every clk driver, instead of program you have name of clockram :-) Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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/
[RFC PATCH 16/50] ARM: at91: move at91sam9263 SoC to new at91 clk implem
This patch removes all references to the old at91 clks implementation and
make use of the new at91 clk implem for at91sam9263 SoC.
All dt specific lookups are removed (handled in clk device tree binding).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
arch/arm/mach-at91/at91sam9263.c | 597 +++---
1 file changed, 368 insertions(+), 229 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
index 77b3c24..b22ec26 100644
--- a/arch/arm/mach-at91/at91sam9263.c
+++ b/arch/arm/mach-at91/at91sam9263.c
@@ -24,7 +24,6 @@
#include at91_rstc.h
#include soc.h
#include generic.h
-#include clock.h
#include sam9_smc.h
/*
@@ -34,248 +33,388 @@
/*
* The peripheral clocks.
*/
-static struct clk pioA_clk = {
- .name = pioA_clk,
- .pmc_mask = 1 AT91SAM9263_ID_PIOA,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
- .name = pioB_clk,
- .pmc_mask = 1 AT91SAM9263_ID_PIOB,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioCDE_clk = {
- .name = pioCDE_clk,
- .pmc_mask = 1 AT91SAM9263_ID_PIOCDE,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
- .name = usart0_clk,
- .pmc_mask = 1 AT91SAM9263_ID_US0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
- .name = usart1_clk,
- .pmc_mask = 1 AT91SAM9263_ID_US1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
- .name = usart2_clk,
- .pmc_mask = 1 AT91SAM9263_ID_US2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc0_clk = {
- .name = mci0_clk,
- .pmc_mask = 1 AT91SAM9263_ID_MCI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc1_clk = {
- .name = mci1_clk,
- .pmc_mask = 1 AT91SAM9263_ID_MCI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk can_clk = {
- .name = can_clk,
- .pmc_mask = 1 AT91SAM9263_ID_CAN,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi_clk = {
- .name = twi_clk,
- .pmc_mask = 1 AT91SAM9263_ID_TWI,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
- .name = spi0_clk,
- .pmc_mask = 1 AT91SAM9263_ID_SPI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
- .name = spi1_clk,
- .pmc_mask = 1 AT91SAM9263_ID_SPI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc0_clk = {
- .name = ssc0_clk,
- .pmc_mask = 1 AT91SAM9263_ID_SSC0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc1_clk = {
- .name = ssc1_clk,
- .pmc_mask = 1 AT91SAM9263_ID_SSC1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ac97_clk = {
- .name = ac97_clk,
- .pmc_mask = 1 AT91SAM9263_ID_AC97C,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tcb_clk = {
- .name = tcb_clk,
- .pmc_mask = 1 AT91SAM9263_ID_TCB,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pwm_clk = {
- .name = pwm_clk,
- .pmc_mask = 1 AT91SAM9263_ID_PWMC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk macb_clk = {
- .name = pclk,
- .pmc_mask = 1 AT91SAM9263_ID_EMAC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk dma_clk = {
- .name = dma_clk,
- .pmc_mask = 1 AT91SAM9263_ID_DMA,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk twodge_clk = {
- .name = 2dge_clk,
- .pmc_mask = 1 AT91SAM9263_ID_2DGE,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk udc_clk = {
- .name = udc_clk,
- .pmc_mask = 1 AT91SAM9263_ID_UDP,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk isi_clk = {
- .name = isi_clk,
- .pmc_mask = 1 AT91SAM9263_ID_ISI,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk lcdc_clk = {
- .name = lcdc_clk,
- .pmc_mask = 1 AT91SAM9263_ID_LCDC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ohci_clk = {
- .name = ohci_clk,
- .pmc_mask = 1 AT91SAM9263_ID_UHP,
- .type = CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk *periph_clocks[] __initdata = {
- pioA_clk,
- pioB_clk,
- pioCDE_clk,
Re: [PATCH v3, part1 04/10] PCI: mark pci_scan_bus_parented() as __deprecated
On 06/07/2013 10:37 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Jun 07, 2013 at 12:32:28AM +0800, Jiang Liu wrote:
On Thu 06 Jun 2013 04:04:36 AM CST, Bjorn Helgaas wrote:
[+cc Konrad, Jeremy, xen-devel (users of interface you're deprecating)]
On Sat, May 25, 2013 at 7:48 AM, Jiang Liu liu...@gmail.com wrote:
Mark pci_scan_bus_parented() as __deprecated and clean up outdated
comments.
Signed-off-by: Jiang Liu jiang@huawei.com
Cc: Chris Metcalf cmetc...@tilera.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Thierry Reding thierry.red...@avionic-design.de
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
arch/tile/kernel/pci.c | 3 ---
include/linux/pci.h| 4 ++--
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/tile/kernel/pci.c b/arch/tile/kernel/pci.c
index 67237d3..936e087 100644
--- a/arch/tile/kernel/pci.c
+++ b/arch/tile/kernel/pci.c
@@ -309,9 +309,6 @@ int __init pcibios_init(void)
*
* It reads the PCI tree for this bus into the
Linux
* data structures.
-*
-* This is inlined in linux/pci.h and calls into
-* pci_scan_bus_parented() in probe.c.
*/
pci_add_resource(resources, ioport_resource);
pci_add_resource(resources, iomem_resource);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index b0f4a82..7b23fa0 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -720,8 +720,8 @@ void pcibios_bus_to_resource(struct pci_dev *dev,
struct resource *res,
void pcibios_scan_specific_bus(int busn);
struct pci_bus *pci_find_bus(int domain, int busnr);
void pci_bus_add_devices(const struct pci_bus *bus);
-struct pci_bus *pci_scan_bus_parented(struct device *parent, int bus,
- struct pci_ops *ops, void *sysdata);
+struct pci_bus * __deprecated pci_scan_bus_parented(struct device *parent,
+ int bus, struct pci_ops *ops, void *sysdata);
struct pci_bus *pci_scan_bus(int bus, struct pci_ops *ops, void *sysdata);
struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
struct pci_ops *ops, void *sysdata,
I think this patch is a good idea, but I think we need to change the
only existing user of pci_scan_bus_parented() (pcifront_scan_root() in
drivers/pci/xen-pcifront.c) at the same time, so xen doesn't start
getting build warnings. The deprecation warnings are really intended
for out-of-tree users that we aren't able to fix ourselves.
I'm getting this series queued up in
http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/jiang-bus-lock-v3,
so if you want to send a patch just for xen, I can fold that in.
Bjorn
Hi Bjorn,
I have posted a big patch for that, but still need help from
Xen experts to review it.
Please refer to https://patchwork.kernel.org/patch/2578551/
Hm, I seem to get:
/home/konrad/linux/drivers/pci/xen-pcifront.c: In function
‘pcifront_free_roots’:
/home/konrad/linux/drivers/pci/xen-pcifront.c:559: error: implicit
declaration of function ‘for_each_pci_root_bus’
/home/konrad/linux/drivers/pci/xen-pcifront.c:559: error: expected ‘;’ before
‘{’ token
/home/konrad/linux/drivers/pci/xen-pcifront.c:554: warning: unused variable
‘sd’
with it? Is there an up-to-date patch?
I have these in my tree:
311db40 PCI, xen-pcifront: use new PCI interfaces to simplify implementation
4079fee Merge remote-tracking branch 'bjorn/pci/jiang-bus-lock-v3' into
testing
ddb7c6b PCI: Hide remove and rescan sysfs interfaces for SR-IOV virtual
functions
f5cfa3a PCI: Simplify IOV implementation and fix reference count races
28b4f07 PCI: Drop redundant setting of bus-is_added in virtfn_add_bus()
442655a unicore32/PCI: Remove redundant call of pci_bus_add_devices()
defd601 m68k/PCI: Remove redundant call of pci_bus_add_devices()
340e3fb PCI: Make PCI host bridge/bus creating and destroying logic symmetric
c7025f7 ia64/PCI: Clean up pci_scan_root_bus() usage
c1f41ce PCI: Mark pci_scan_bus_parented() as __deprecated
13e5057 PCI: Convert alloc_pci_dev(void) to pci_alloc_dev(bus)
007042a PCI: Introduce pci_alloc_dev(struct pci_bus*) to replace
alloc_pci_dev()
fe830ef PCI: Introduce pci_bus_{get|put}() to manage PCI bus reference count
Hi Konrad,
Could you please help to apply this simple patch onto to your tree?
It should fix the build failure issue.
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 79ad229..b5e0e66 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -556,7 +556,7 @@ static void pcifront_free_roots(struct
pcifront_device *pdev)
dev_dbg(pdev-xdev-dev, cleaning up root buses\n);
- for_each_pci_root_bus(bus) {
+
[RFC PATCH 17/50] ARM: at91: move at91sam9g45 SoC to new at91 clk implem
This patch removes all references to the old at91 clks implementation and
make use of the new at91 clk implem for at91sam9g45 SoC.
All dt specific lookups are removed (handled in clk device tree binding).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
arch/arm/mach-at91/at91sam9g45.c | 703 ++
arch/arm/mach-at91/at91sam9g45_devices.c |1 -
2 files changed, 427 insertions(+), 277 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index 31a1304..c68c2fb 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -24,7 +24,6 @@
#include at91_aic.h
#include soc.h
#include generic.h
-#include clock.h
#include sam9_smc.h
/*
@@ -34,297 +33,449 @@
/*
* The peripheral clocks.
*/
-static struct clk pioA_clk = {
- .name = pioA_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_PIOA,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
- .name = pioB_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_PIOB,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioC_clk = {
- .name = pioC_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_PIOC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioDE_clk = {
- .name = pioDE_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_PIODE,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk trng_clk = {
- .name = trng_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_TRNG,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
- .name = usart0_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_US0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
- .name = usart1_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_US1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
- .name = usart2_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_US2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart3_clk = {
- .name = usart3_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_US3,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc0_clk = {
- .name = mci0_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_MCI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi0_clk = {
- .name = twi0_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_TWI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi1_clk = {
- .name = twi1_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_TWI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
- .name = spi0_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_SPI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
- .name = spi1_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_SPI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc0_clk = {
- .name = ssc0_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_SSC0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc1_clk = {
- .name = ssc1_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_SSC1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tcb0_clk = {
- .name = tcb0_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_TCB,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pwm_clk = {
- .name = pwm_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_PWMC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tsc_clk = {
- .name = tsc_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_TSC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk dma_clk = {
- .name = dma_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_DMA,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk uhphs_clk = {
- .name = uhphs_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_UHPHS,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk lcdc_clk = {
- .name = lcdc_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_LCDC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ac97_clk = {
- .name = ac97_clk,
- .pmc_mask = 1 AT91SAM9G45_ID_AC97C,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk macb_clk = {
- .name = pclk,
- .pmc_mask = 1 AT91SAM9G45_ID_EMAC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk isi_clk = {
- .name
[RFC PATCH 18/50] ARM: at91: move at91sam9n12 SoC to new at91 clk implem
This patch removes all references to the old at91 clks for at91sam9n12 SoC.
This SoC only supports dt boards: we can remove register_clocks
(all clocks are defined in dt).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
arch/arm/mach-at91/at91sam9n12.c | 194 --
1 file changed, 194 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9n12.c b/arch/arm/mach-at91/at91sam9n12.c
index f9ff4d2..a6eed93 100644
--- a/arch/arm/mach-at91/at91sam9n12.c
+++ b/arch/arm/mach-at91/at91sam9n12.c
@@ -19,202 +19,9 @@
#include board.h
#include soc.h
#include generic.h
-#include clock.h
#include sam9_smc.h
/*
- * Clocks
- * */
-
-/*
- * The peripheral clocks.
- */
-static struct clk pioAB_clk = {
- .name = pioAB_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_PIOAB,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioCD_clk = {
- .name = pioCD_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_PIOCD,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
- .name = usart0_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_USART0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
- .name = usart1_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_USART1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
- .name = usart2_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_USART2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart3_clk = {
- .name = usart3_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_USART3,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi0_clk = {
- .name = twi0_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_TWI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi1_clk = {
- .name = twi1_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_TWI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc_clk = {
- .name = mci_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_MCI,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
- .name = spi0_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_SPI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
- .name = spi1_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_SPI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk uart0_clk = {
- .name = uart0_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_UART0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk uart1_clk = {
- .name = uart1_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_UART1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tcb_clk = {
- .name = tcb_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_TCB,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pwm_clk = {
- .name = pwm_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_PWM,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk adc_clk = {
- .name = adc_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_ADC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk dma_clk = {
- .name = dma_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_DMA,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk uhp_clk = {
- .name = uhp,
- .pmc_mask = 1 AT91SAM9N12_ID_UHP,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk udp_clk = {
- .name = udp_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_UDP,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk lcdc_clk = {
- .name = lcdc_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_LCDC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc_clk = {
- .name = ssc_clk,
- .pmc_mask = 1 AT91SAM9N12_ID_SSC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk *periph_clocks[] __initdata = {
- pioAB_clk,
- pioCD_clk,
- usart0_clk,
- usart1_clk,
- usart2_clk,
- usart3_clk,
- twi0_clk,
- twi1_clk,
- mmc_clk,
- spi0_clk,
- spi1_clk,
- lcdc_clk,
- uart0_clk,
- uart1_clk,
- tcb_clk,
- pwm_clk,
- adc_clk,
- dma_clk,
- uhp_clk,
- udp_clk,
- ssc_clk,
-};
-
-static struct clk_lookup periph_clocks_lookups[] = {
- /* lookup table for DT entries */
- CLKDEV_CON_DEV_ID(usart, f200.serial, mck),
-
Re: OOM Killer and add_to_page_cache_locked
On Fri 07-06-13 17:13:55, Piotr Nowojski wrote: W dniu 06.06.2013 17:57, Michal Hocko pisze: In our system we have hit some very annoying situation (bug?) with cgroups. I'm writing to you, because I have found your posts on mailing lists with similar topic. Maybe you could help us or point some direction where to look for/ask. We have system with ~15GB RAM (+2GB SWAP), and we are running ~10 heavy IO processes. Each process is using constantly 200-210MB RAM (RSS) and a lot of page cache. All processes are in cgroup with following limits: /sys/fs/cgroup/taskell2 $ cat memory.limit_in_bytes memory.memsw.limit_in_bytes 14183038976 15601344512 I assume that memory.use_hierarchy is 1, right? System has been rebooted since last test, so I can not guarantee that it was set for 100%, but it should have been. Currently I'm rerunning this scenario that lead to the described problem with: /sys/fs/cgroup/taskell2# cat memory.use_hierarchy ../memory.use_hierarchy 1 0 OK, good. Your numbers suggeste that the hierachy _is_ in use. I just wanted to be 100% sure. [...] The core thing to find out is why the hard limit reclaim is not able to free anything. Unfortunatelly we do not have memcg reclaim statistics so it would be a bit harder. I would start with the above patch first and then I can prepare some debugging patches for you. I will try 3.6 (probably 3.7) kernel after weekend - unfortunately I would simply try 3.9 (stable) and skip those two. repeating whole scenario is taking 10-30 hours because of very slowly growing page cache. OK, this is good to know. Also does 3.4 vanila (or the stable kernel) behave the same way? Is the current vanilla behaving the same way? I don't know, we are using standard kernel that comes from Ubuntu. yes, but I guess ubuntu, like any other distro puts some pathces on top of vanilla kernel. Finally, have you seen the issue for a longer time or it started showing up only now? This system is very new. We have started testing scenario which triggered OOM something like one week ago and we have immediately hit this issue. Previously, with different scenarios and different memory usage by processes we didn't have this issue. OK -- Michal Hocko SUSE Labs -- 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 02/50] ARM: at91: add PMC main clock
On 07/06/2013 17:30, Thomas Petazzoni wrote: Dear Boris BREZILLON, On Fri, 7 Jun 2013 16:24:10 +0200, Boris BREZILLON wrote: + * This mainram is free software; you can redistribute it and/or modify Looks like you did some funky 'sed' over your source files. In every clk driver, instead of program you have name of clockram :-) Oups. I based all my implementations on programmable clocks and replaced every instance of the prog pattern by the clock name. That's why program is replaced by name of clockram. I'll fix it. Thanks Thomas -- 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/
[RFC PATCH 21/50] ARM: at91: move at91sam9 SoCs to new at91 clk implem
Make use of common clk framework for all at91sam9 SoCs Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com --- arch/arm/mach-at91/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig index 7256b81..add1719 100644 --- a/arch/arm/mach-at91/Kconfig +++ b/arch/arm/mach-at91/Kconfig @@ -32,6 +32,7 @@ config HAVE_AT91_SMD config SOC_AT91SAM9 bool + select COMMON_CLK select AT91_SAM9_TIME select CPU_ARM926T select GENERIC_CLOCKEVENTS -- 1.7.9.5 -- 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] dmaengine/trivial: at_hdmac: add curly brackets to if/else expressions
On Friday 07 June 2013, Nicolas Ferre wrote:
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 50953a7..b321562 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -299,8 +299,9 @@ static int atc_get_bytes_left(struct dma_chan *chan)
if (atchan-remain_desc 0) {
ret = -EINVAL;
goto out;
- } else
+ } else {
ret = atchan-remain_desc;
+ }
} else {
Actually the original code is what a lot of people prefer, though I don't
have a reference to back that up.
If one side of the 'else' uses curly braces, the other one should too.
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: Strange intermittent EIO error when writing to stdout since v3.8.0
On 06/06/2013 10:37 AM, Markus Trippelsdorf wrote: On 2013.06.06 at 10:18 -0400, Peter Hurley wrote: On 06/06/2013 07:54 AM, Markus Trippelsdorf wrote: Since v3.8.0 several people reported intermittent IO errors that happen during high system load while using emerge under Gentoo: ... File /usr/lib64/portage/pym/portage/util/_eventloop/EventLoop.py, line 260, in iteration if not x.callback(f, event, *x.args): File /usr/lib64/portage/pym/portage/util/_async/PipeLogger.py, line 99, in _output_handler stdout_buf[os.write(stdout_fd, stdout_buf):] File /usr/lib64/portage/pym/portage/__init__.py, line 246, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) OSError: [Errno 5] Input/output error Looks to me like a user-space bug: EIO is returned when the other end of the pipe has been closed. FWIW, I didn't see where the OP tried to revert 'SpawnProcess: stdout_fd FD_CLOEXEC' The only non-emerge related comment (#21 in the link provided) refers to 'a similar issue sometimes happened when I built Firefox by hand [..snip..] And it would randomly crash during the build. Since I've recompiled Python with gcc-4.6 this issue also never occurred again.' That comment doesn't really corroborate the reported bug. That comment was from me (I use 'octoploid' for blog trolling, etc.) and is wrong. The Firefox build issue happend again today. See also the rest of my mail: (A similar issue also happens when building Firefox since v3.8.0. But because Firefox's build process doesn't raise an exception it just dies at random points without giving a clue.) Please note that both the Firefox build process and Portage (emerge) are implemented in Python. Based on the other reports from Mikael and David, I suspect this problem may have to do with my commit 699390354da6c258b65bf8fa79cfd5feaede50b6: pty: Ignore slave pty close() if never successfully opened This commit poisons the pty under certain error conditions that may occur from parallel open()s (or parallel close() with pending write()). It's unclear to me which error condition is triggered and how user-space got an open file descriptor but that seems the most likely. Is the problem reproducible enough that a debug patch would likely trigger? Regards, Peter Hurley -- 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] ethernet/arc/arc_emac - Add new driver
On Friday 07 June 2013, Alexey Brodkin wrote: Driver for non-standard on-chip ethernet device ARC EMAC 10/100, instantiated in some legacy ARC (Synopsys) FPGA Boards such as ARCAngel4/ML50x. This is based off of current Linus tree, build tested for x86. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Reviewed-by: Vineet Gupta vgu...@synopsys.com Reviewed-by: Mischa Jonker mjon...@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/
[RFC PATCH 20/50] ARM: at91: move at91sam9x5 SoCs to new at91 clk implem
This patch removes all references to the old at91 clks for at91sam9x5 SoCs.
These SoCs only supports dt boards: we can remove register_clocks
(all clocks are defined in dt).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
arch/arm/mach-at91/at91sam9x5.c | 289 ---
1 file changed, 289 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
index 83fc6b3..583a3d5 100644
--- a/arch/arm/mach-at91/at91sam9x5.c
+++ b/arch/arm/mach-at91/at91sam9x5.c
@@ -19,297 +19,9 @@
#include board.h
#include soc.h
#include generic.h
-#include clock.h
#include sam9_smc.h
/*
- * Clocks
- * */
-
-/*
- * The peripheral clocks.
- */
-static struct clk pioAB_clk = {
- .name = pioAB_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_PIOAB,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioCD_clk = {
- .name = pioCD_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_PIOCD,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk smd_clk = {
- .name = smd_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_SMD,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
- .name = usart0_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_USART0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
- .name = usart1_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_USART1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
- .name = usart2_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_USART2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-/* USART3 clock - Only for sam9g25/sam9x25 */
-static struct clk usart3_clk = {
- .name = usart3_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_USART3,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi0_clk = {
- .name = twi0_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_TWI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi1_clk = {
- .name = twi1_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_TWI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi2_clk = {
- .name = twi2_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_TWI2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc0_clk = {
- .name = mci0_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_MCI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
- .name = spi0_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_SPI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
- .name = spi1_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_SPI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk uart0_clk = {
- .name = uart0_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_UART0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk uart1_clk = {
- .name = uart1_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_UART1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tcb0_clk = {
- .name = tcb0_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_TCB,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pwm_clk = {
- .name = pwm_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_PWM,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk adc_clk = {
- .name = adc_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_ADC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk adc_op_clk = {
- .name = adc_op_clk,
- .type = CLK_TYPE_PERIPHERAL,
- .rate_hz= 500,
-};
-static struct clk dma0_clk = {
- .name = dma0_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_DMA0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk dma1_clk = {
- .name = dma1_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_DMA1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk uhphs_clk = {
- .name = uhphs,
- .pmc_mask = 1 AT91SAM9X5_ID_UHPHS,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk udphs_clk = {
- .name = udphs_clk,
- .pmc_mask = 1 AT91SAM9X5_ID_UDPHS,
- .type = CLK_TYPE_PERIPHERAL,
-};
-/* emac0 clock - Only for sam9g25/sam9x25/sam9g35/sam9x35 */
-static struct clk macb0_clk = {
- .name = pclk,
- .pmc_mask = 1 AT91SAM9X5_ID_EMAC0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-/* lcd
Re: [PATCH] xen/blkback: Check for insane amounts of request on the ring.
On Thu, Jun 06, 2013 at 12:47:35PM +0100, Jan Beulich wrote:
On 05.06.13 at 19:35, Konrad Rzeszutek Wilk konrad.w...@oracle.com
wrote:
@@ -230,6 +231,7 @@ static int xen_blkif_map(struct xen_blkif *blkif,
unsigned long shared_page,
static void xen_blkif_disconnect(struct xen_blkif *blkif)
{
if (blkif-xenblkd) {
+ wake_up(blkif-shutdown_wq);
kthread_stop(blkif-xenblkd);
blkif-xenblkd = NULL;
}
Btw., wouldn't the wake_up() better be done after the kthread_stop(),
so that when the corresponding wait_event_interruptible() checks
whether to exit the terminating kthread_should_stop() is guaranteed
to evaluate to true (otherwise I think there's potential for it to never
exit)?
I think you are right. I did the change and the tests were OK.
Jan
--
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/2] ARM: dts: mvebu: Add the i2c-bridge capability to the mv64xxx-i2c
The mv64xxx-i2c embedded in the Armada XP have a new feature called
i2c-bridge. This commit split the i2c information into armada-370.dtsi
and armada-xp.dtsi. Most of the data remains the same and stay in the
common file Armada-370-xp.dtsi. With this new feature the size of the
registers are bigger for Armada XP and for this SoCs we add a new flag
for the i2c-bridge capability.
The Device Tree binding documentation is updated accordingly.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | 6 ++
arch/arm/boot/dts/armada-370-xp.dtsi | 2 --
arch/arm/boot/dts/armada-370.dtsi | 8
arch/arm/boot/dts/armada-xp.dtsi | 10 ++
4 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
index f46d928..8ede3e7 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
@@ -8,6 +8,12 @@ Required properties :
- interrupts : The interrupt number
- clock-frequency : Desired I2C bus clock frequency in Hz.
+Optional properties :
+
+- i2c,i2c-bridge : This flag indicate that the i2c controller have the
+ Transaction Generator support and we want to use it. Not all the
+ mv64xxx controller have this feature.
+
Examples:
i2c@11000 {
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 550eb77..b6f475c 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -112,7 +112,6 @@
i2c0: i2c@11000 {
compatible = marvell,mv64xxx-i2c;
- reg = 0x11000 0x20;
#address-cells = 1;
#size-cells = 0;
interrupts = 31;
@@ -123,7 +122,6 @@
i2c1: i2c@11100 {
compatible = marvell,mv64xxx-i2c;
- reg = 0x11100 0x20;
#address-cells = 1;
#size-cells = 0;
interrupts = 32;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index aee2b18..39b26d6 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -155,6 +155,14 @@
};
};
+ i2c0: i2c@11000 {
+ reg = 0x11000 0x20;
+ };
+
+ i2c1: i2c@11100 {
+ reg = 0x11100 0x20;
+ };
+
usb@5 {
clocks = coreclk 0;
};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 5b902f9..db36bfb 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -134,6 +134,16 @@
};
};
+ i2c0: i2c@11000 {
+ reg = 0x11000 0x100;
+ i2c,i2c-bridge;
+ };
+
+ i2c1: i2c@11100 {
+ reg = 0x11100 0x100;
+ i2c,i2c-bridge;
+ };
+
usb@5 {
clocks = gateclk 18;
};
--
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/2] i2c-mv64xxx: Add I2C Transaction Generator support
From: Zbigniew Bodek z...@semihalf.com
The I2C Transaction Generator offloads CPU from managing I2C
transfer step by step.
This feature is currently only available on Armada XP, so usage of
this mechanism is activated through device tree.
[gregory.clem...@free-electrons.com: Rewrite some part to be applied
on the the code modified by Russell King's fixes]
[gregory.clem...@free-electrons.com: Merge and split the commits to
push them to the accurate maintainer i2c and of]]
[gregory.clem...@free-electrons.com: Reword the commit log]
Signed-off-by: Piotr Ziecik ko...@semihalf.com
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/i2c/busses/i2c-mv64xxx.c | 143 +--
1 file changed, 139 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 6356439..5376dc3 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -24,7 +24,7 @@
#include linux/clk.h
#include linux/err.h
-/* Register defines */
+/* Register defines (I2C port) */
#defineMV64XXX_I2C_REG_SLAVE_ADDR 0x00
#defineMV64XXX_I2C_REG_DATA0x04
#defineMV64XXX_I2C_REG_CONTROL 0x08
@@ -59,6 +59,29 @@
#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK0xe8
#defineMV64XXX_I2C_STATUS_NO_STATUS0xf8
+/* Register defines (I2C bridge) */
+#defineMV64XXX_I2C_REG_TX_DATA_LO 0xC0
+#defineMV64XXX_I2C_REG_TX_DATA_HI 0xC4
+#defineMV64XXX_I2C_REG_RX_DATA_LO 0xC8
+#defineMV64XXX_I2C_REG_RX_DATA_HI 0xCC
+#defineMV64XXX_I2C_REG_BRIDGE_CONTROL 0xD0
+#defineMV64XXX_I2C_REG_BRIDGE_STATUS 0xD4
+#defineMV64XXX_I2C_REG_BRIDGE_INTR_CAUSE 0xD8
+#defineMV64XXX_I2C_REG_BRIDGE_INTR_MASK0xDC
+#defineMV64XXX_I2C_REG_BRIDGE_TIMING 0xE0
+
+/* Bridge Control values */
+#defineMV64XXX_I2C_BRIDGE_CONTROL_WR 0x0001
+#defineMV64XXX_I2C_BRIDGE_CONTROL_RD 0x0002
+#defineMV64XXX_I2C_BRIDGE_CONTROL_ADDR_SHIFT 2
+#defineMV64XXX_I2C_BRIDGE_CONTROL_ADDR_EXT 0x1000
+#defineMV64XXX_I2C_BRIDGE_CONTROL_TX_SIZE_SHIFT13
+#defineMV64XXX_I2C_BRIDGE_CONTROL_RX_SIZE_SHIFT16
+#defineMV64XXX_I2C_BRIDGE_CONTROL_ENABLE 0x0008
+
+/* Bridge Status values */
+#defineMV64XXX_I2C_BRIDGE_STATUS_ERROR 0x0001
+
/* Driver states */
enum {
MV64XXX_I2C_STATE_INVALID,
@@ -110,6 +133,7 @@ struct mv64xxx_i2c_data {
spinlock_t lock;
struct i2c_msg *msg;
struct i2c_adapter adapter;
+ int bridge_enabled;
};
static void
@@ -157,6 +181,16 @@ mv64xxx_i2c_hw_init(struct mv64xxx_i2c_data *drv_data)
writel(0, drv_data-reg_base + MV64XXX_I2C_REG_EXT_SLAVE_ADDR);
writel(MV64XXX_I2C_REG_CONTROL_TWSIEN | MV64XXX_I2C_REG_CONTROL_STOP,
drv_data-reg_base + MV64XXX_I2C_REG_CONTROL);
+
+ if (drv_data-bridge_enabled) {
+ writel(0, drv_data-reg_base + MV64XXX_I2C_REG_BRIDGE_CONTROL);
+ writel(0, drv_data-reg_base + MV64XXX_I2C_REG_BRIDGE_TIMING);
+ writel(0, drv_data-reg_base +
+ MV64XXX_I2C_REG_BRIDGE_INTR_CAUSE);
+ writel(0, drv_data-reg_base +
+ MV64XXX_I2C_REG_BRIDGE_INTR_MASK);
+ }
+
drv_data-state = MV64XXX_I2C_STATE_IDLE;
}
@@ -368,6 +402,19 @@ mv64xxx_i2c_intr(int irq, void *dev_id)
irqreturn_t rc = IRQ_NONE;
spin_lock_irqsave(drv_data-lock, flags);
+
+ if (drv_data-bridge_enabled) {
+ if (readl(drv_data-reg_base +
+ MV64XXX_I2C_REG_BRIDGE_INTR_CAUSE)) {
+ writel(0, drv_data-reg_base +
+ MV64XXX_I2C_REG_BRIDGE_CONTROL);
+ writel(0, drv_data-reg_base +
+ MV64XXX_I2C_REG_BRIDGE_INTR_CAUSE);
+ drv_data-block = 0;
+ wake_up(drv_data-waitq);
+ rc = IRQ_HANDLED;
+ }
+ }
while (readl(drv_data-reg_base + MV64XXX_I2C_REG_CONTROL)
MV64XXX_I2C_REG_CONTROL_IFLG) {
status = readl(drv_data-reg_base + MV64XXX_I2C_REG_STATUS);
@@ -446,6 +493,81 @@ mv64xxx_i2c_execute_msg(struct mv64xxx_i2c_data *drv_data,
struct i2c_msg *msg,
return drv_data-rc;
}
+static int
+mv64xxx_i2c_offload_msg(struct mv64xxx_i2c_data *drv_data, struct i2c_msg *msg)
+{
+
[RFC PATCH 23/50] ARM: at91: move at91rm9200 boards to new at91 clk implem
Move at91 clk init from early_init to timer_init for all at91rm9200 non dt
boards.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
arch/arm/mach-at91/board-1arm.c | 12 ++--
arch/arm/mach-at91/board-carmeva.c| 13 -
arch/arm/mach-at91/board-cpuat91.c| 12 ++--
arch/arm/mach-at91/board-csb337.c | 11 +++
arch/arm/mach-at91/board-csb637.c | 11 +++
arch/arm/mach-at91/board-dt-rm9200.c |9 -
arch/arm/mach-at91/board-eb9200.c | 11 +++
arch/arm/mach-at91/board-ecbat91.c| 12 ++--
arch/arm/mach-at91/board-eco920.c | 13 +++--
arch/arm/mach-at91/board-kafa.c | 12 ++--
arch/arm/mach-at91/board-kb9202.c | 12 ++--
arch/arm/mach-at91/board-picotux200.c | 11 +++
arch/arm/mach-at91/board-rm9200dk.c | 11 +++
arch/arm/mach-at91/board-rm9200ek.c | 11 +++
arch/arm/mach-at91/board-rsi-ews.c| 12
arch/arm/mach-at91/board-yl-9200.c| 12 ++--
16 files changed, 137 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-at91/board-1arm.c b/arch/arm/mach-at91/board-1arm.c
index 35ab632..1ccfa2d 100644
--- a/arch/arm/mach-at91/board-1arm.c
+++ b/arch/arm/mach-at91/board-1arm.c
@@ -46,8 +46,16 @@ static void __init onearm_init_early(void)
/* Set cpu type: PQFP */
at91rm9200_set_type(ARCH_REVISON_9200_PQFP);
+ at91_initialize();
+}
+
+static void __init onearm_timer_init(void)
+{
/* Initialize processor: 18.432 MHz crystal */
- at91_initialize(18432000);
+ at91_clk_init(18432000);
+
+ /* Init rm9200 timer */
+ at91rm9200_timer_init();
}
static struct macb_platform_data __initdata onearm_eth_data = {
@@ -90,7 +98,7 @@ static void __init onearm_board_init(void)
MACHINE_START(ONEARM, Ajeco 1ARM single board computer)
/* Maintainer: Lennert Buytenhek buyt...@wantstofly.org */
- .init_time = at91rm9200_timer_init,
+ .init_time = onearm_timer_init,
.map_io = at91_map_io,
.handle_irq = at91_aic_handle_irq,
.init_early = onearm_init_early,
diff --git a/arch/arm/mach-at91/board-carmeva.c
b/arch/arm/mach-at91/board-carmeva.c
index 9298305..591ff4c 100644
--- a/arch/arm/mach-at91/board-carmeva.c
+++ b/arch/arm/mach-at91/board-carmeva.c
@@ -41,10 +41,13 @@
#include generic.h
-static void __init carmeva_init_early(void)
+static void __init carmeva_timer_init(void)
{
- /* Initialize processor: 20.000 MHz crystal */
- at91_initialize(2000);
+ /* Initialize processor: 18.432 MHz crystal */
+ at91_clk_init(2000);
+
+ /* Init rm9200 timer */
+ at91rm9200_timer_init();
}
static struct macb_platform_data __initdata carmeva_eth_data = {
@@ -157,10 +160,10 @@ static void __init carmeva_board_init(void)
MACHINE_START(CARMEVA, Carmeva)
/* Maintainer: Conitec Datasystems */
- .init_time = at91rm9200_timer_init,
+ .init_time = carmeva_timer_init,
.map_io = at91_map_io,
.handle_irq = at91_aic_handle_irq,
- .init_early = carmeva_init_early,
+ .init_early = at91_initialize,
.init_irq = at91_init_irq_default,
.init_machine = carmeva_board_init,
MACHINE_END
diff --git a/arch/arm/mach-at91/board-cpuat91.c
b/arch/arm/mach-at91/board-cpuat91.c
index 42f1353..42b51d9 100644
--- a/arch/arm/mach-at91/board-cpuat91.c
+++ b/arch/arm/mach-at91/board-cpuat91.c
@@ -58,8 +58,16 @@ static void __init cpuat91_init_early(void)
/* Set cpu type: PQFP */
at91rm9200_set_type(ARCH_REVISON_9200_PQFP);
+ at91_initialize();
+}
+
+static void __init cpuat91_timer_init(void)
+{
/* Initialize processor: 18.432 MHz crystal */
- at91_initialize(18432000);
+ at91_clk_init(18432000);
+
+ /* Init rm9200 timer */
+ at91rm9200_timer_init();
}
static struct macb_platform_data __initdata cpuat91_eth_data = {
@@ -178,7 +186,7 @@ static void __init cpuat91_board_init(void)
MACHINE_START(CPUAT91, Eukrea)
/* Maintainer: Eric Benard - EUKREA Electromatique */
- .init_time = at91rm9200_timer_init,
+ .init_time = cpuat91_timer_init,
.map_io = at91_map_io,
.handle_irq = at91_aic_handle_irq,
.init_early = cpuat91_init_early,
diff --git a/arch/arm/mach-at91/board-csb337.c
b/arch/arm/mach-at91/board-csb337.c
index e5fde215..b772ec2 100644
--- a/arch/arm/mach-at91/board-csb337.c
+++ b/arch/arm/mach-at91/board-csb337.c
@@ -44,10 +44,13 @@
#include generic.h
-static void __init csb337_init_early(void)
+static void __init csb337_timer_init(void)
{
/* Initialize processor: 3.6864 MHz crystal */
- at91_initialize(3686400);
+ at91_clk_init(3686400);
+
+ /* Init rm9200 timer */
+ at91rm9200_timer_init();
}
Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interface via sysfs
On Fri, Jun 07, 2013 at 04:12:25PM +0100, Nick Dyer wrote: Mark Brown wrote: Who said anything about names? I'd assume the userspace stuff is eventually talking to the device based on numbers of some kind and I'd expect that this would be what ends up in the API. OK. But if user-space is talking to the device based on register numbers, a binary attribute seems like the correct way to present that - isn't that what they're designed for? I thought there was this protocol you're concerned aboout, not raw registers? Presenting the actual data in binary form seems sane, how one gets to the data is the issue. And we wouldn't have won anything, because the user could still write to the register that turns off reporting (for example) by mistake with both methods. You'd not have access to the entire device register map which seems like a win Not really. The chip itself will enforce which registers are read-only (by ignoring writes) or write-only (by returning zeros if read). Encoding all this information in the driver would just make it more brittle in the face of touch controller firmware updates. So not only do you interact with the firmware via this protocol but the actual hardware register map is unstable and there's nothing in the device that the driver itself actually interacts with, all it does is ferry these messages from the application layer to the device? Given the number of other patches here that doesn't seem to be the case... It would be possible for the driver to intermediate for some of the registers that it cares about. For example, if we change the screen width then the driver could reinitialise the input device. But I can't see that it makes sense if you are changing several settings in a row for the input device to be reinitialised several times. It is far less buggy to provide a single way of tearing down everything and reinitialising (which could be simply triggered from user space) than to encode all of the dependencies (which is bound to introduce bugs). I am having an extremely hard time connecting anything you're talking about here with the discussion at hand I'm afraid... Having lots of configuration and having the parameters change regularly doesn't immediately mean that it has to be complex - the requirement is very common, touchscreens aren't too remarkable here. The usual thing is for the kernel to understand how to transfer data back and forth but not the content of the data. Sure, that's what I'm trying to accomplish. It's just that as far as I can see it makes more sense to use the established protocol that these chips have implemented rather than trying to bodge something else over the top or crowbar it into a different model that will cause abstraction problems. We have thought about this problem at great length, and discussed it on these lists, and with other kernel engineers at customers, etc. Nobody is talking about changing the protocol for interacting with the device. The discussion here is about the ABI the driver offers to the application layer. signature.asc Description: Digital signature
[PATCH 0/2] i2c-mv64xxx: Add I2C Transaction Generator support
Hello, this patch set adds support for the I2C Transaction Generator which offloads CPU from managing I2C transfer step by step. This feature is currently only available on the I2C controller IP embedded in the Armada XP SoC. That's why usage of this mechanism is optional and activated through device tree. The first patch modifies the driver itself and should go through i2c subsystem. Due to the recent changes in i2c-mv64xxx.c file caused by Russell King's fixes, I based this patch on the for-next branch of the i2c git repository. The second patch updates the device tree to be able to use this new feature and should go through mvebu subsystem. The 2 patches are independents for building or even at runtime, but of course we need both of them to be able to use the I2C Transaction Generator on the Armada XP SoC. Thanks Gregory CLEMENT (1): ARM: dts: mvebu: Add the i2c-bridge capability to the mv64xxx-i2c Zbigniew Bodek (1): i2c-mv64xxx: Add I2C Transaction Generator support .../devicetree/bindings/i2c/i2c-mv64xxx.txt| 6 + arch/arm/boot/dts/armada-370-xp.dtsi | 2 - arch/arm/boot/dts/armada-370.dtsi | 8 ++ arch/arm/boot/dts/armada-xp.dtsi | 10 ++ drivers/i2c/busses/i2c-mv64xxx.c | 143 - 5 files changed, 163 insertions(+), 6 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/
[RFC PATCH 22/50] ARM: at91: move sama5d3 SoCs to new at91 clk implem
This patch removes all references to the old at91 clks for sama5d3 SoCs.
These SoCs only supports dt boards: we can remove register_clocks
(all clocks are defined in dt).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
arch/arm/mach-at91/Kconfig |1 +
arch/arm/mach-at91/sama5d3.c | 342 --
2 files changed, 1 insertion(+), 342 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index add1719..a2f57d2 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -41,6 +41,7 @@ config SOC_AT91SAM9
config SOC_SAMA5
bool
+ select COMMON_CLK
select AT91_SAM9_TIME
select CPU_V7
select GENERIC_CLOCKEVENTS
diff --git a/arch/arm/mach-at91/sama5d3.c b/arch/arm/mach-at91/sama5d3.c
index 32e0522..5e53be8 100644
--- a/arch/arm/mach-at91/sama5d3.c
+++ b/arch/arm/mach-at91/sama5d3.c
@@ -19,350 +19,9 @@
#include soc.h
#include generic.h
-#include clock.h
#include sam9_smc.h
/*
- * Clocks
- * */
-
-/*
- * The peripheral clocks.
- */
-
-static struct clk pioA_clk = {
- .name = pioA_clk,
- .pid= SAMA5D3_ID_PIOA,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
- .name = pioB_clk,
- .pid= SAMA5D3_ID_PIOB,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioC_clk = {
- .name = pioC_clk,
- .pid= SAMA5D3_ID_PIOC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioD_clk = {
- .name = pioD_clk,
- .pid= SAMA5D3_ID_PIOD,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioE_clk = {
- .name = pioE_clk,
- .pid= SAMA5D3_ID_PIOE,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
- .name = usart0_clk,
- .pid= SAMA5D3_ID_USART0,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk usart1_clk = {
- .name = usart1_clk,
- .pid= SAMA5D3_ID_USART1,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk usart2_clk = {
- .name = usart2_clk,
- .pid= SAMA5D3_ID_USART2,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk usart3_clk = {
- .name = usart3_clk,
- .pid= SAMA5D3_ID_USART3,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk uart0_clk = {
- .name = uart0_clk,
- .pid= SAMA5D3_ID_UART0,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk uart1_clk = {
- .name = uart1_clk,
- .pid= SAMA5D3_ID_UART1,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk twi0_clk = {
- .name = twi0_clk,
- .pid= SAMA5D3_ID_TWI0,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk twi1_clk = {
- .name = twi1_clk,
- .pid= SAMA5D3_ID_TWI1,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk twi2_clk = {
- .name = twi2_clk,
- .pid= SAMA5D3_ID_TWI2,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk mmc0_clk = {
- .name = mci0_clk,
- .pid= SAMA5D3_ID_HSMCI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc1_clk = {
- .name = mci1_clk,
- .pid= SAMA5D3_ID_HSMCI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc2_clk = {
- .name = mci2_clk,
- .pid= SAMA5D3_ID_HSMCI2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
- .name = spi0_clk,
- .pid= SAMA5D3_ID_SPI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
- .name = spi1_clk,
- .pid= SAMA5D3_ID_SPI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk tcb0_clk = {
- .name = tcb0_clk,
- .pid= SAMA5D3_ID_TC0,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk tcb1_clk = {
- .name
[PATCH 0/2] i2c-mv64xxx: Various fixes
Hello, This series contains a real fix for the I2C controller of the Armada XP SoC and a patch closer to a improvement than a fix. They are independent and are only in the same series because they are kind of fixes. They are based on 3.10-rc4, and they will be small conflicts if they are applied on top of i2c/for-next branch and on top of the series I have just sent to add I2C Transaction Generator support. You can have a look on the branch i2c-mv64xxx-fixes-bridge to get an idea on how to resolve it. This branch is located at https://github.com/MISL-EBU-System-SW/mainline-public.git Thanks, Zbigniew Bodek (2): i2c-mv64xxx: Fix timing issue on Armada XP (errata FE-8471889) i2c-mv64xxx: Abort the mv64xxx_of_config if clock-frequency is not provided drivers/i2c/busses/i2c-mv64xxx.c | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) -- 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: [ 185/184] [SCSI] mpt2sas: Send default descriptor for RAID pass through in mpt2ctl
On Fri, Jun 07, 2013 at 07:38:23AM +0100, Ben Hutchings wrote: On Wed, 2013-06-05 at 11:42 +0200, Willy Tarreau wrote: 2.6.32-longterm review patch. If anyone has any objections, please let me know. Thanks to Moritz for spotting this missing patch from the series. -- From: Kashyap, Desai kashyap.de...@lsi.com commit ebda4d38df542e1ff4747c4daadfc7da250b4fa6 upstream. Added, thank you Ben. Willy -- 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/
