Re: linux-next: manual merge of the akpm-current tree with the parisc-hd tree
Hi Helge, On Tue, 5 Sep 2017 08:09:01 +0200 Helge Deller wrote: > > >> diff --cc arch/parisc/include/uapi/asm/mman.h > >> index 9a9c2fe4be50,f6eec376e5fa.. > >> --- a/arch/parisc/include/uapi/asm/mman.h > >> +++ b/arch/parisc/include/uapi/asm/mman.h > >> @@@ -57,9 -60,9 +57,12 @@@ > >> overrides the coredump filter bits */ > >> #define MADV_DODUMP 70 /* Clear the MADV_NODUMP flag */ > >> > >> + #define MADV_WIPEONFORK 71 /* Zero memory on fork, child > >> only */ > >> + #define MADV_KEEPONFORK 72 /* Undo MADV_WIPEONFORK */ > >> + > >> +#define MADV_HWPOISON 100/* poison a page for testing */ > >> +#define MADV_SOFT_OFFLINE 101/* soft offline page for > >> testing */ > >> + > >> /* compatibility flags */ > >> #define MAP_FILE 0 > >> #define MAP_VARIABLE 0 > > > > Just a reminder that the above conflict still exists. > > Thanks Stephen! > > @Andrew, I can push the addition of those two MADV_ constants to > arch/parisc/include/uapi/asm/mman.h through the parisc git tree, > if you drop this part from your patchset. > Otherwise, just let me know how you prefer to solve this merge conflict. These simple conflicts are not really a problem (Linus is happy to cope with them). I just send these messages out for consistency and openness. -- Cheers, Stephen Rothwell
Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock
On Tue, Sep 05, 2017 at 08:28:10AM +0200, Juergen Gross wrote: > On 05/09/17 00:21, Davidlohr Bueso wrote: > > On Mon, 04 Sep 2017, Peter Zijlstra wrote: > > > >> For testing its trivial to hack your kernel and I don't feel this is > >> something an Admin can make reasonable decisions about. > >> > >> So why? In general less knobs is better. > > > > +1. > > > > Also, note how b8fa70b51aa (xen, pvticketlocks: Add xen_nopvspin parameter > > to disable xen pv ticketlocks) has no justification as to why its wanted > > in the first place. The only thing I could find was from 15a3eac0784 > > (xen/spinlock: Document the xen_nopvspin parameter): > > > > "Useful for diagnosing issues and comparing benchmarks in over-commit > > CPU scenarios." > > Hmm, I think I should clarify the Xen knob, as I was the one requesting > it: > > In my previous employment we had a configuration where dom0 ran > exclusively on a dedicated set of physical cpus. We experienced > scalability problems when doing I/O performance tests: with a decent > number of dom0 cpus we achieved throughput of 700 MB/s with only 20% > cpu load in dom0. A higher dom0 cpu count let the throughput drop to > about 150 MB/s and cpu load was up to 100%. Reason was the additional > load due to hypervisor interactions on a high frequency lock. > > So in special configurations at least for Xen the knob is useful for > production environment. So the problem with qspinlock is that it will revert to a classic test-and-set spinlock if you don't do paravirt but are running a HV. And test-and-set is unfair and has all kinds of ugly starvation cases, esp on slightly bigger hardware. So if we'd want to cater to the 1:1 virt case, we'll need to come up with something else. _IF_ it is an issue of course.
Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock
On 09/05/2017 08:28 AM, Juergen Gross wrote: On 05/09/17 00:21, Davidlohr Bueso wrote: On Mon, 04 Sep 2017, Peter Zijlstra wrote: For testing its trivial to hack your kernel and I don't feel this is something an Admin can make reasonable decisions about. So why? In general less knobs is better. +1. Also, note how b8fa70b51aa (xen, pvticketlocks: Add xen_nopvspin parameter to disable xen pv ticketlocks) has no justification as to why its wanted in the first place. The only thing I could find was from 15a3eac0784 (xen/spinlock: Document the xen_nopvspin parameter): "Useful for diagnosing issues and comparing benchmarks in over-commit CPU scenarios." Hmm, I think I should clarify the Xen knob, as I was the one requesting it: In my previous employment we had a configuration where dom0 ran exclusively on a dedicated set of physical cpus. We experienced scalability problems when doing I/O performance tests: with a decent number of dom0 cpus we achieved throughput of 700 MB/s with only 20% cpu load in dom0. A higher dom0 cpu count let the throughput drop to about 150 MB/s and cpu load was up to 100%. Reason was the additional load due to hypervisor interactions on a high frequency lock. So in special configurations at least for Xen the knob is useful for production environment. It may be that the original patch was just to keep consistency between Xen and KVM, and also only for testing purposes. But we find a case when a customer of ours is running some workloads with 1<->1 mapping between physical cores and virtual cores, and we realized that with the pv spinlocks disabled there is a 4-5% of performance gain. A perf analysis showed that the application was very lock intensive with a lot of time spent in __raw_callee_save___pv_queued_spin_unlock.
Re: [PATCH] hwmon: (k10temp) Add support for family 17h
Guenter Roeck wrote: > Add support for temperature sensors on Family 17h (Ryzen) processors. > > Signed-off-by: Guenter Roeck > --- > Some of this is guesswork, but afaics it is working. No idea if there > is a better way to determine the temperature offset. The reported value is not an absolute temperature on any CPU. As far as I know, the offset is not guaranteed to be fixed for any model, i.e., it would be pointless to apply the offset observed on one specific chip. > @@ -25,6 +25,10 @@ > #include > #include > > +#ifndef PCI_DEVICE_ID_AMD_17H_DF_F3 > +#define PCI_DEVICE_ID_AMD_17H_DF_F3 0x1463 > +#endif > + Please move this down to the other symbols. Regards, Clemens
[GIT PULL] s390 update for 4.14 merge window #1
Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: The first part of the s390 updates for 4.14: - Add machine type 0x3906 for IBM z14 - Add IBM z14 TLB flushing improvements for KVM guests - Exploit the TOD clock epoch extension to provide a continuous TOD clock afer 2042/09/17 - Add NIAI spinlock hints for IBM z14 - Rework the vmcp driver and use CMA for the respone buffer of z/VM CP commands - Drop some s390 specific asm headers and use the generic version - Add block discard for DASD-FBA devices under z/VM - Add average request times to DASD statistics - A few of those constify patches which seem to be in vogue right now - Cleanup and bug fixes My test merge revealed a small conflict, easy to resolve: -- diff --cc arch/s390/include/asm/mmu_context.h index 24bc41622a98,31eea6261488.. --- a/arch/s390/include/asm/mmu_context.h +++ b/arch/s390/include/asm/mmu_context.h @@@ -44,12 -45,7 +45,12 @@@ static inline int init_new_context(stru mm->context.asce = __pa(mm->pgd) | _ASCE_TABLE_LENGTH | _ASCE_USER_BITS | _ASCE_TYPE_REGION3; break; + case -PAGE_SIZE: + /* forked 5-level task, set new asce with new_mm->pgd */ + mm->context.asce = __pa(mm->pgd) | _ASCE_TABLE_LENGTH | + _ASCE_USER_BITS | _ASCE_TYPE_REGION1; + break; - case 1UL << 53: + case _REGION1_SIZE: /* forked 4-level task, set new asce with new mm->pgd */ mm->context.asce = __pa(mm->pgd) | _ASCE_TABLE_LENGTH | _ASCE_USER_BITS | _ASCE_TYPE_REGION2; -- The shortlog: Arvind Yadav (8): s390/zcrypt_queue: constify attribute_group structures. s390/zcrypt_card: constify attribute_group structures. s390/dasd: constify attribute_group structures. s390/cio: constify attribute_group structures. s390/qeth: constify attribute_group structures. s390/raw3270: constify attribute_group structures. s390/tape: constify attribute_group structures. s390/sclp_ocf: constify attribute_group structures. Bhumika Goyal (3): s390/sclp: add const to bin_attribute structure s390/cio: add const to bin_attribute structures s390/zcrypt: make CPRBX const Christian Borntraeger (1): s390/mm: avoid empty zero pages for KVM guests to avoid postcopy hangs Dou Liyang (1): s390/topology: Remove the unused parent_node() macro Heiko Carstens (22): s390/mm: remove and correct comments within pgtable.h s390/mm: get rid of __ASSEMBLY__ guards within pgtable.h s390/mm: introduce defines to reflect the hardware mmu s390/mm: use new mm defines instead of magic values KVM: s390: use new mm defines instead of magic values s390/mm,vmem: simplify region and segment table allocation code s390/nmi: keep comments consistent s390: remove asm/mman.h and asm/types.h s390: use generic uapi/asm/swab.h s390: use generic asm/unaligned.h s390/mm: add missing virt_to_pfn() etc. helper functions s390/mm: prevent memory offline for memory blocks with cma areas s390/vmcp: fix uaccess check and avoid undefined behavior s390/cpcmd,vmcp: avoid GFP_DMA allocations s390/vmcp: make use of contiguous memory allocator s390/vmcp: split vmcp header file and move to uapi s390/vmcp: return -ENOTTY for unknown ioctl commands s390/vmcp: simplify vmcp_ioctl() s390: fix 'novx' early parameter handling s390/smp: convert cpuhp_setup_state() return code to zero on success s390/vmcp: simplify vmcp_response_free() s390/facilities: fix typo Jan Höppner (2): s390/dasd: Change unsigned long long to unsigned long s390/dasd: Add discard support for FBA devices Jason J. Herne (1): vfio: ccw: fix bad ptr math for TIC cda translation Martin Schwidefsky (10): s390/mm: tag normal pages vs pages used in page tables s390/mm: add no-dat TLB flush optimization s390/mm: add guest ASCE TLB flush optimization s390/mm,kvm: use nodat PGSTE tag to optimize TLB flushing s390/sclp: single increment assignment control s390/time: add support for the TOD clock epoch extension s390: add support for IBM z14 machines s390/spinlock: add niai spinlock hints s390/mm: use generic mm_hooks s390/uaccess: avoid mvcos jump label Sebastian Ott (2): s390/pci: log changes to uid checking s390/scm: use common completion path Stefan Haberland (1): s390/dasd: add average request times to dasd statistics Documentation/admin-guide/kernel-parameters.txt| 4 + arch/s390/Kconfig | 18 ++ arch/s390/Makefile | 6 +- arch/s390/includ
Re: [PATCH 2/2] tracing: Add support for critical section events
On Mon, Sep 04, 2017 at 08:26:13PM -0700, Joel Fernandes wrote: > Apologies, I meant (without the "off"): > > subsystem: atomic_section > events: > irqs_disable > irqs_enable > preempt_disable > preempt_enable > > and additionally (similar to what my patch does): > preemptirq_enable > preemptirq_disable > What do you need the last for?
Re: [PATCH] geneve: Fix setting ttl value in collect metadata mode
On Sun, Sep 3, 2017 at 5:49 AM, Haishuang Yan
wrote:
> If key->tos is zero in collect metadata mode, tos should fallback to
> ip{4,6}_dst_hoplimit, same as normal mode.
>
> Signed-off-by: Haishuang Yan
> ---
> drivers/net/geneve.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> index f640407..d52a65f 100644
> --- a/drivers/net/geneve.c
> +++ b/drivers/net/geneve.c
> @@ -834,11 +834,10 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct
> net_device *dev,
> sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
> if (geneve->collect_md) {
> tos = ip_tunnel_ecn_encap(key->tos, ip_hdr(skb), skb);
> - ttl = key->ttl;
> } else {
> tos = ip_tunnel_ecn_encap(fl4.flowi4_tos, ip_hdr(skb), skb);
> - ttl = key->ttl ? : ip4_dst_hoplimit(&rt->dst);
> }
> + ttl = key->ttl ? : ip4_dst_hoplimit(&rt->dst);
In collect md mode, geneve has to set TTL value from tunnel metadata.
That is the API exposed to userspace. is there reason for this change?
> df = key->tun_flags & TUNNEL_DONT_FRAGMENT ? htons(IP_DF) : 0;
>
> err = geneve_build_skb(&rt->dst, skb, info, xnet, sizeof(struct
> iphdr));
> @@ -873,12 +872,11 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct
> net_device *dev,
> sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
> if (geneve->collect_md) {
> prio = ip_tunnel_ecn_encap(key->tos, ip_hdr(skb), skb);
> - ttl = key->ttl;
> } else {
> prio = ip_tunnel_ecn_encap(ip6_tclass(fl6.flowlabel),
>ip_hdr(skb), skb);
> - ttl = key->ttl ? : ip6_dst_hoplimit(dst);
> }
> + ttl = key->ttl ? : ip6_dst_hoplimit(dst);
> err = geneve_build_skb(dst, skb, info, xnet, sizeof(struct ipv6hdr));
> if (unlikely(err))
> return err;
> --
> 1.8.3.1
>
>
>
Re: [RFC PATCH 02/11] refcount: Implement inc/decrement-and-return functions
On Mon, Sep 04, 2017 at 05:08:29PM +0100, David Howells wrote: > Which bit are you objecting to? Wanting to use a refcount_t with 1 to > represent an otherwise-unreferenced object sat in a cache? Or wanting to > display accurate usage counts when tracing gets and puts of objects? Primarily the first, but also any feature creap of the refcount_t in general.
Re: [PATCH] swapon: fix vfree() badness
On 09/05/2017 07:10 AM, Dave Chinner wrote: > From: Dave Chinner > > The cluster_info structure is allocated with kvzalloc(), which can > return kmalloc'd or vmalloc'd memory. It must be paired with > kvfree(), but sys_swapon uses vfree(), resultin in this warning > from xfstests generic/357: > > [ 1985.294915] swapon: swapfile has holes > [ 1985.296012] Trying to vfree() bad address (88011569ac00) > [ 1985.297769] [ cut here ] > [ 1985.299017] WARNING: CPU: 4 PID: 980 at mm/vmalloc.c:1521 > __vunmap+0x97/0xb0 > [ 1985.300868] CPU: 4 PID: 980 Comm: swapon Tainted: GW > 4.13.0-dgc #55 > [ 1985.303086] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.10.2-1 04/01/2014 > [ 1985.305421] task: 88083599c800 task.stack: c90006d68000 > [ 1985.306896] RIP: 0010:__vunmap+0x97/0xb0 > [ 1985.307866] RSP: 0018:c90006d6be68 EFLAGS: 00010296 > [ 1985.309300] RAX: 0030 RBX: 88011569ac00 RCX: > > [ 1985.311066] RDX: 88013fc949d8 RSI: 88013fc8cb98 RDI: > 88013fc8cb98 > [ 1985.312803] RBP: c90006d6be80 R08: 0004844c R09: > 1578 > [ 1985.314672] R10: 82271b20 R11: 8256e16d R12: > 000a > [ 1985.316444] R13: 0001 R14: ffea R15: > 880139a96000 > [ 1985.318230] FS: 7fb23ac0e880() GS:88013fc8() > knlGS: > [ 1985.320081] CS: 0010 DS: ES: CR0: 80050033 > [ 1985.321503] CR2: 564cdb0c7000 CR3: 000137448000 CR4: > 000406e0 > [ 1985.323140] Call Trace: > [ 1985.323727] vfree+0x2e/0x70 > [ 1985.324403] SyS_swapon+0x433/0x1080 > [ 1985.325365] entry_SYSCALL_64_fastpath+0x1a/0xa5 > > Fix this as well as the memory leak caused by a missing kvfree(frontswap_map) > in > the error handling code. > > cc: > Signed-Off-By: Dave Chinner Reviewed-by: Anshuman Khandual > --- > mm/swapfile.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/mm/swapfile.c b/mm/swapfile.c > index 6ba4aab2db0b..a8952b6563c6 100644 > --- a/mm/swapfile.c > +++ b/mm/swapfile.c > @@ -3052,7 +3052,8 @@ SYSCALL_DEFINE2(swapon, const char __user *, > specialfile, int, swap_flags) > p->flags = 0; > spin_unlock(&swap_lock); > vfree(swap_map); > - vfree(cluster_info); > + kvfree(cluster_info); > + kvfree(frontswap_map); Its correct in swapoff() system call but got missed here.
Re: [PATCH] drm/vblank: Fix delta_ns to an absolute value
On 09/04/2017 04:36 PM, Daniel Vetter wrote:
On Fri, Sep 01, 2017 at 04:36:25PM +0300, Ville Syrjälä wrote:
On Fri, Sep 01, 2017 at 04:07:16PM +0900, Hoegeun Kwon wrote:
If scanout started, we should reduce etime by delta_ns. But delta_ns
is negative if scanout has not started. If delta_ns is negative,
subtraction of delta_ns from etime increases etime. This is wrong, the
etime should not be increased, so you have to make delta_ns an
absolute value.
Signed-off-by: Hoegeun Kwon
---
Hello all,
I think that the etime should not be increased.
In cases where delta_ns is negative, if you get time again after an
interrupt call, there is a problem that the time obtained from the
interrupt becomes the future time instead of the past time.
Please let me know if this patch is wrong.
It is wrong. The timestamp corresponds to the first active pixel of the
frame/field. So while between vblank start and active start we expect
to get a timestamp that is in the future.
A bit more strict, it's up to drivers when exactly the vblank interrupt
fires. Some fire at vblank start, some at the end, some somewhen around
that. The only rule is that the vblank must not fire before the point of
no return for another page_flip call, i.e. after the vblank event goes
out, the next page_flip (or atomic ioctl) must go to the next vblank.
So yeah both positive and negative deltas make perfect sense.
-Daniel
Thanks Ville and Daniel,
Your response has been really helpful.
Thanks so much.
Best regards,
Hoegeun
Best regards,
Hoegeun
drivers/gpu/drm/drm_vblank.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 70f2b95..a3e0176 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -684,7 +684,7 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct
drm_device *dev,
/* Subtract time delta from raw timestamp to get final
* vblank_time timestamp for end of vblank.
*/
- etime = ktime_sub_ns(etime, delta_ns);
+ etime = ktime_sub_ns(etime, abs(delta_ns));
*vblank_time = ktime_to_timeval(etime);
DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d rep]\n",
--
1.9.1
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early
On 09/04/2017 01:51 PM, Michal Hocko wrote:
> From: Michal Hocko
>
> Memory offlining can fail just too eagerly under a heavy memory pressure.
>
> [ 5410.336792] page:ea22a646bd00 count:255 mapcount:252
> mapping:88ff926c9f38 index:0x3
> [ 5410.336809] flags: 0x9855fe40010048(uptodate|active|mappedtodisk)
> [ 5410.336811] page dumped because: isolation failed
> [ 5410.336813] page->mem_cgroup:8801cd662000
> [ 5420.655030] memory offlining [mem 0x18b58000-0x18b5] failed
>
> Isolation has failed here because the page is not on LRU. Most probably
> because it was on the pcp LRU cache or it has been removed from the LRU
> already but it hasn't been freed yet. In both cases the page doesn't look
> non-migrable so retrying more makes sense.
>
> __offline_pages seems rather cluttered when it comes to the retry
> logic. We have 5 retries at maximum and a timeout. We could argue
> whether the timeout makes sense but failing just because of a race when
> somebody isoltes a page from LRU or puts it on a pcp LRU lists is just
> wrong. It only takes it to race with a process which unmaps some pages
> and remove them from the LRU list and we can fail the whole offline
> because of something that is a temporary condition and actually not
> harmful for the offline. Please note that unmovable pages should be
> already excluded during start_isolate_page_range.
>
> Fix this by removing the max retry count and only rely on the timeout
> resp. interruption by a signal from the userspace. Also retry rather
> than fail when check_pages_isolated sees some !free pages because those
> could be a result of the race as well.
>
> Signed-off-by: Michal Hocko
> ---
> mm/memory_hotplug.c | 40 ++--
> 1 file changed, 10 insertions(+), 30 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 459bbc182d10..c9dcbe6d2ac6 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1597,7 +1597,7 @@ static int __ref __offline_pages(unsigned long
> start_pfn,
> {
> unsigned long pfn, nr_pages, expire;
> long offlined_pages;
> - int ret, drain, retry_max, node;
> + int ret, node;
> unsigned long flags;
> unsigned long valid_start, valid_end;
> struct zone *zone;
> @@ -1634,43 +1634,25 @@ static int __ref __offline_pages(unsigned long
> start_pfn,
>
> pfn = start_pfn;
> expire = jiffies + timeout;
> - drain = 0;
> - retry_max = 5;
> repeat:
> /* start memory hot removal */
> - ret = -EAGAIN;
> + ret = -EBUSY;
> if (time_after(jiffies, expire))
> goto failed_removal;
> ret = -EINTR;
> if (signal_pending(current))
> goto failed_removal;
> - ret = 0;
> - if (drain) {
> - lru_add_drain_all_cpuslocked();
> - cond_resched();
> - drain_all_pages(zone);
> - }
Why we had this condition before that only when we fail in migration
later in do_migrate_range function, drain the lru lists in the next
attempt. Why not from the first attempt itself ? Just being curious.
Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock
On 05/09/17 00:21, Davidlohr Bueso wrote: > On Mon, 04 Sep 2017, Peter Zijlstra wrote: > >> For testing its trivial to hack your kernel and I don't feel this is >> something an Admin can make reasonable decisions about. >> >> So why? In general less knobs is better. > > +1. > > Also, note how b8fa70b51aa (xen, pvticketlocks: Add xen_nopvspin parameter > to disable xen pv ticketlocks) has no justification as to why its wanted > in the first place. The only thing I could find was from 15a3eac0784 > (xen/spinlock: Document the xen_nopvspin parameter): > > "Useful for diagnosing issues and comparing benchmarks in over-commit > CPU scenarios." Hmm, I think I should clarify the Xen knob, as I was the one requesting it: In my previous employment we had a configuration where dom0 ran exclusively on a dedicated set of physical cpus. We experienced scalability problems when doing I/O performance tests: with a decent number of dom0 cpus we achieved throughput of 700 MB/s with only 20% cpu load in dom0. A higher dom0 cpu count let the throughput drop to about 150 MB/s and cpu load was up to 100%. Reason was the additional load due to hypervisor interactions on a high frequency lock. So in special configurations at least for Xen the knob is useful for production environment. Juergen
[GIT PULL] EFI changes for v4.14
Linus,
Please pull the latest efi-core-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-core-for-linus
# HEAD: 6de47a5e371f75f80544986e6c9636211a2ae8af efi/bgrt: Use efi_mem_type()
The main changes in this cycle were:
- Transparently fall back to other poweroff method(s) if EFI poweroff fails
(and
returns)
- Use separate PE/COFF section headers for the RX and RW parts of the ARM
stub loader so that the firmware can use strict mapping permissions
- Add support for requesting the firmware to wipe RAM at warm reboot
- Increase the size of the random seed obtained from UEFI so CRNG
fast init can complete earlier
- Update the EFI framebuffer address if it points to a BAR that gets moved
by the PCI resource allocation code
- Enable "reset attack mitigation" of TPM environments: this is enabled if
the kernel is configured with CONFIG_RESET_ATTACK_MITIGATION=y.
- Clang related fixes
- Misc cleanups, constification, refactoring, etc.
Thanks,
Ingo
-->
Ard Biesheuvel (11):
efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP
efi/libstub/arm64: Use hidden attribute for struct screen_info reference
efi/libstub/arm64: Force 'hidden' visibility for section markers
efi/libstub/arm64: Set -fpie when building the EFI stub
efi/arm/arm64: Add missing assignment of efi.config_table
drivers/fbdev/efifb: Allow BAR to be moved instead of claiming it
arm/efi: Remove forbidden values from the PE/COFF header
arm/efi: Remove pointless dummy .reloc section
arm/efi: Replace open coded constants with symbolic ones
arm/efi: Split zImage code and data into separate PE/COFF sections
efi/random: Increase size of firmware supplied randomness
Arvind Yadav (3):
firmware/dcdbas: Constify attribute_group structures
firmware/efi: Constify attribute_group structures
firmware/efi/esrt: Constify attribute_group structures
Colin Ian King (1):
efi/reboot: Make function pointer orig_pm_power_off static
Hans de Goede (1):
efi/reboot: Fall back to original power-off method if EFI_RESET_SHUTDOWN
returns
Jan Beulich (2):
efi: Move efi_mem_type() to common code
efi/bgrt: Use efi_mem_type()
Matthew Garrett (1):
efi/libstub: Enable reset attack mitigation
arch/arm/boot/compressed/efi-header.S | 160 +++---
arch/arm/boot/compressed/vmlinux.lds.S| 30 --
arch/arm64/include/asm/efi.h | 3 +
arch/x86/boot/compressed/eboot.c | 3 +
arch/x86/platform/efi/efi.c | 19
drivers/firmware/dcdbas.c | 2 +-
drivers/firmware/efi/Kconfig | 10 ++
drivers/firmware/efi/arm-init.c | 8 ++
drivers/firmware/efi/efi-bgrt.c | 22 +---
drivers/firmware/efi/efi.c| 42 ++--
drivers/firmware/efi/esrt.c | 2 +-
drivers/firmware/efi/libstub/Makefile | 3 +-
drivers/firmware/efi/libstub/arm-stub.c | 3 +
drivers/firmware/efi/libstub/arm64-stub.c | 10 +-
drivers/firmware/efi/libstub/random.c | 10 +-
drivers/firmware/efi/libstub/tpm.c| 58 +++
drivers/firmware/efi/reboot.c | 12 ++-
drivers/video/fbdev/efifb.c | 31 +++---
include/linux/efi.h | 9 ++
19 files changed, 280 insertions(+), 157 deletions(-)
create mode 100644 drivers/firmware/efi/libstub/tpm.c
diff --git a/arch/arm/boot/compressed/efi-header.S
b/arch/arm/boot/compressed/efi-header.S
index a17ca8d78656..c94a88ae834d 100644
--- a/arch/arm/boot/compressed/efi-header.S
+++ b/arch/arm/boot/compressed/efi-header.S
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2013-2015 Linaro Ltd
+ * Copyright (C) 2013-2017 Linaro Ltd
* Authors: Roy Franz
* Ard Biesheuvel
*
@@ -8,6 +8,9 @@
* published by the Free Software Foundation.
*/
+#include
+#include
+
.macro __nop
#ifdef CONFIG_EFI_STUB
@ This is almost but not quite a NOP, since it does clobber the
@@ -15,7 +18,7 @@
@ PE/COFF expects the magic string "MZ" at offset 0, while the
@ ARM/Linux boot protocol expects an executable instruction
@ there.
- .inst 'M' | ('Z' << 8) | (0x1310 << 16) @ tstne r0, #0x4d000
+ .inst MZ_MAGIC | (0x1310 << 16) @ tstne r0, #0x4d000
#else
AR_CLASS( mov r0, r0 )
M_CLASS( nop.w )
@@ -34,96 +37,97 @@
@ The only 2 fields of the MSDOS header that are used are this
@ PE/COFF offset, and the "MZ" bytes at offset 0x0.
@
- .long pe_header - start @ Offset to the PE header.
+ .long pe_header - start @ Offset to the PE
header.
pe_header:
- .ascii "PE\0\0"
+ .long PE_MA
Re: [PATCH v2] drivers/mailbox: Add Aspeed mailbox driver
On Tue, Sep 05, 2017 at 09:37:19AM +1000, Cyril Bur wrote: > On Mon, 2017-09-04 at 20:13 +0530, Jassi Brar wrote: > > On Mon, Sep 4, 2017 at 12:47 PM, Cyril Bur wrote: > > > Hi, > > > > > > I haven't heard anything about this driver. I'm trying to interpret if > > > the silence is because there is something fundamentally wrong with the > > > driver or is it because it doesn't use any of the mailbox > > > infrastructure it is being ignored. > > > > > > > Its the latter. > > Great! Thanks for your response, I'll resend it under char/misc. Wait, no, please use the mailbox infrastructure for this, making a one-off char/misc driver isn't ok when there is a framework for you to use. thanks, greg k-h
linux-next: Tree for Sep 5
Hi all, Please do not add any v4.15 related material to your linux-next included branches until after v4.14-rc1 has been released. Changes since 20170904: The nvdimm tree lost its build failure. The akpm-current tree gained a conflict against the net-next tree and still had its build failure for which I disabled a CONFIG option. Non-merge commits (relative to Linus' tree): 9125 8834 files changed, 479301 insertions(+), 131409 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu. Below is a summary of the state of the merge. I am currently merging 268 trees (counting Linus' and 41 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (b1b6f83ac938 Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig entry) Merging kbuild-current/fixes (64236e315955 kbuild: update comments of Makefile.asm-generic) Merging arc-current/for-curr (1ee55a8f7f6b ARC: Re-enable MMU upon Machine Check exception) Merging arm-current/fixes (746a272e4414 ARM: 8692/1: mm: abort uaccess retries upon fatal signal) Merging m68k-current/for-linus (558d5ad276c9 m68k/mac: Avoid soft-lockup warning after mach_power_off) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (1a92a80ad386 powerpc/mm: Ensure cpumask update is ordered) Merging sparc/master (6470812e2226 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (6d9c153a0b84 net: dsa: loop: Do not unregister invalid fixed PHY) Merging ipsec/master (f581a0dd744f wl1251: add a missing spin_lock_init()) Merging netfilter/master (6d9c153a0b84 net: dsa: loop: Do not unregister invalid fixed PHY) Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook mask only if set) Merging wireless-drivers/master (10a54d8196d1 iwlwifi: pcie: move rx workqueue initialization to iwl_trans_pcie_alloc()) Merging mac80211/master (6d9c153a0b84 net: dsa: loop: Do not unregister invalid fixed PHY) Merging sound-current/for-linus (ee5f38a4459a Merge tag 'asoc-v4.14-cs43130' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (8e1101d25164 PCI/MSI: Don't warn when irq_create_affinity_masks() returns NULL) Merging driver-core.current/driver-core-linus (ef954844c7ac Linux 4.13-rc5) Merging tty.current/tty-linus (ef954844c7ac Linux 4.13-rc5) Merging usb.current/usb-linus (ef954844c7ac Linux 4.13-rc5) Merging usb-gadget-fixes/fixes (b7d44c36a6f6 usb: renesas_usbhs: gadget: fix unused-but-set-variable warning) Merging usb-serial-fixes/usb-linus (fd1b8668af59 USB: serial: option: add D-Link DWM-222 device ID) Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: check before accessing ci_role in ci_role_show) Merging phy/fixes (5771a8c08880 Linux v4.13-rc1) Merging staging.current/staging-linus (cc4a41fe5541 Linux 4.13-rc7) Merging char-misc.current/char-misc-linus (cc4a41fe5541 Linux 4.13-rc7) Merging input-current/for-linus (a6cbfa1e6d38 Merge branch 'next' into for-linus) Merging crypto-current/master (2d45a7e898
[GIT PULL] x86/platform changes for v4.14
Linus, Please pull the latest x86-platform-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-platform-for-linus # HEAD: 773b79f7a7c7839fb9d09c0e206734173a8b0a6b tracing/hyper-v: Trace hyperv_mmu_flush_tlb_others() The main changes include various Hyper-V optimizations such as faster hypercalls and faster/better TLB flushes - and there's also some Intel-MID cleanups. out-of-topic modifications in x86-platform-for-linus: --- MAINTAINERS# 773b79f7a7c7: tracing/hyper-v: Trace hyper # db46e14f8a3c: MAINTAINERS: Add missed file drivers/hv/Kconfig # 2ffd9e33ce4a: x86/hyper-v: Use hypercall f drivers/hv/channel_mgmt.c # 7415aea6072b: hyper-v: Globalize vp_index # 057841713cff: hyper-v: Use fast hypercall drivers/hv/connection.c# 7415aea6072b: hyper-v: Globalize vp_index # 057841713cff: hyper-v: Use fast hypercall # fc53662f13b8: x86/hyper-v: Make hv_do_hype drivers/hv/hv.c# 7415aea6072b: hyper-v: Globalize vp_index drivers/hv/hyperv_vmbus.h # 7415aea6072b: hyper-v: Globalize vp_index drivers/hv/vmbus_drv.c # 7415aea6072b: hyper-v: Globalize vp_index drivers/pci/host/pci-hyperv.c # 7415aea6072b: hyper-v: Globalize vp_index include/linux/hyperv.h # 7415aea6072b: hyper-v: Globalize vp_index # 057841713cff: hyper-v: Use fast hypercall # fc53662f13b8: x86/hyper-v: Make hv_do_hype Thanks, Ingo --> Andy Shevchenko (3): x86/platform/intel-mid: Group timers callbacks together x86/platform/intel-mid: Make IRQ allocation a bit more flexible MAINTAINERS: Add missed file for Hyper-V Bhumika Goyal (1): x86/platform/intel-mid: Make 'bt_sfi_data' const Colin Ian King (1): x86/platform/intel-mid: Make several arrays static, to make code smaller Vitaly Kuznetsov (9): x86/hyper-v: Include hyperv/ only when CONFIG_HYPERV is set x86/hyper-v: Make hv_do_hypercall() inline x86/hyper-v: Introduce fast hypercall implementation hyper-v: Use fast hypercall for HVCALL_SIGNAL_EVENT x86/hyper-v: Implement rep hypercalls hyper-v: Globalize vp_index x86/hyper-v: Use hypercall for remote TLB flush x86/hyper-v: Support extended CPU ranges for TLB flush hypercalls tracing/hyper-v: Trace hyperv_mmu_flush_tlb_others() MAINTAINERS| 2 + arch/x86/Kbuild| 2 +- arch/x86/hyperv/Makefile | 2 +- arch/x86/hyperv/hv_init.c | 90 +++ arch/x86/hyperv/mmu.c | 272 + arch/x86/include/asm/mshyperv.h| 147 ++- arch/x86/include/asm/trace/hyperv.h| 40 +++ arch/x86/include/uapi/asm/hyperv.h | 17 ++ arch/x86/kernel/cpu/mshyperv.c | 1 + arch/x86/pci/intel_mid_pci.c | 12 +- .../platform/intel-mid/device_libs/platform_bt.c | 2 +- .../intel-mid/device_libs/platform_mrfld_wdt.c | 6 +- arch/x86/platform/intel-mid/intel-mid.c| 2 +- arch/x86/platform/intel-mid/pwr.c | 4 +- drivers/hv/Kconfig | 1 + drivers/hv/channel_mgmt.c | 20 +- drivers/hv/connection.c| 7 +- drivers/hv/hv.c| 9 - drivers/hv/hyperv_vmbus.h | 11 - drivers/hv/vmbus_drv.c | 17 -- drivers/pci/host/pci-hyperv.c | 54 +--- include/linux/hyperv.h | 17 +- 22 files changed, 552 insertions(+), 183 deletions(-) create mode 100644 arch/x86/hyperv/mmu.c create mode 100644 arch/x86/include/asm/trace/hyperv.h diff --git a/MAINTAINERS b/MAINTAINERS index 1c3feffb1c1c..9fcffdfcb09d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6258,6 +6258,7 @@ M:Stephen Hemminger L: de...@linuxdriverproject.org S: Maintained F: arch/x86/include/asm/mshyperv.h +F: arch/x86/include/asm/trace/hyperv.h F: arch/x86/include/uapi/asm/hyperv.h F: arch/x86/kernel/cpu/mshyperv.c F: arch/x86/hyperv @@ -6270,6 +6271,7 @@ F:drivers/scsi/storvsc_drv.c F: drivers/uio/uio_hv_generic.c F: drivers/video/fbdev/hyperv_fb.c F: include/linux/hyperv.h +F: include/uapi/linux/hyperv.h F: tools/hv/ F: Documentation/ABI/stable/sysfs-bus-vmbus diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild index 586b786b3edf..3e6f64073005 100644 --- a/arch/x
Re: [PATCH v2] clk: at91: utmi: set the mainck rate
On Mon, Sep 04, 2017 at 07:53:57PM +0200, Ingo van Lil wrote:
> On 09/04/2017 11:52 AM, Ludovic Desroches wrote:
>
> > + /* SFR node missing is not necessarily an issue. */
> > + regmap_sfr = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
> > + if (IS_ERR(regmap_sfr))
> > + regmap_sfr = NULL;
>
> What about SAMA5D3? That chip has an UTMICKTRIM register, too (SAMA5D4
> doesn't, though).
Oh Yes. I'll look for atmel,sama5d3-sfr too. Maybe there is a smarter
solution but I don't have it in mind.
>
> Otherwise the patch looks good and works fine on both my boards (SAMA5D2
> 16MHz and SAMA5D3 12MHz).
Thanks for testing.
Regards
Ludovic
Re: [PATCH V5 0/4] Add Broadcom STB USB phy driver
Florian, On Saturday 02 September 2017 07:46 AM, Florian Fainelli wrote: > > > On 08/25/2017 10:51 AM, Al Cooper wrote: >> Add a new USB Phy driver for Broadcom STB SoCs. This driver >> supports Broadcom STB ARM SoCs. This driver in >> combination with the Broadcom STB ohci, ehci and xhci >> drivers will enable USB1.1, USB2.0 and USB3.0 support. >> This Phy driver also supports the Broadcom BDC gadget >> driver. > > Thanks Al! Kishon, feel free to merge everything through your tree there > should not be any conflicts with drivers/soc/bcm/brcmstb/common.c and > include/linux/soc/brcmstb/brcmstb.h. I'll start merging once 4.14 -rc1 is tagged. Thanks Kishon
Re: linux-next: manual merge of the akpm-current tree with the parisc-hd tree
On 05.09.2017 02:34, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 22 Aug 2017 16:53:18 +1000 Stephen Rothwell
> wrote:
>>
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>> arch/parisc/include/uapi/asm/mman.h
>>
>> between commit:
>>
>> 1c190151447d ("parisc: Add MADV_HWPOISON and MADV_SOFT_OFFLINE")
>>
>> from the parisc-hd tree and commit:
>>
>> 115d20ededaf ("mm,fork: introduce MADV_WIPEONFORK")
>>
>> from the akpm-current tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging. You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>>
>> diff --cc arch/parisc/include/uapi/asm/mman.h
>> index 9a9c2fe4be50,f6eec376e5fa..
>> --- a/arch/parisc/include/uapi/asm/mman.h
>> +++ b/arch/parisc/include/uapi/asm/mman.h
>> @@@ -57,9 -60,9 +57,12 @@@
>> overrides the coredump filter bits */
>> #define MADV_DODUMP70 /* Clear the MADV_NODUMP flag */
>>
>> + #define MADV_WIPEONFORK 71 /* Zero memory on fork, child only */
>> + #define MADV_KEEPONFORK 72 /* Undo MADV_WIPEONFORK */
>> +
>> +#define MADV_HWPOISON 100 /* poison a page for testing */
>> +#define MADV_SOFT_OFFLINE 101 /* soft offline page for
>> testing */
>> +
>> /* compatibility flags */
>> #define MAP_FILE 0
>> #define MAP_VARIABLE 0
>
> Just a reminder that the above conflict still exists.
Thanks Stephen!
@Andrew, I can push the addition of those two MADV_ constants to
arch/parisc/include/uapi/asm/mman.h through the parisc git tree,
if you drop this part from your patchset.
Otherwise, just let me know how you prefer to solve this merge conflict.
Helge
Re: [PATCH 2/2] mm, memory_hotplug: remove timeout from __offline_memory
On 09/04/2017 02:45 PM, Michal Hocko wrote: > On Mon 04-09-17 17:05:15, Xishi Qiu wrote: >> On 2017/9/4 17:01, Michal Hocko wrote: >> >>> On Mon 04-09-17 16:58:30, Xishi Qiu wrote: On 2017/9/4 16:21, Michal Hocko wrote: > From: Michal Hocko > > We have a hardcoded 120s timeout after which the memory offline fails > basically since the hot remove has been introduced. This is essentially > a policy implemented in the kernel. Moreover there is no way to adjust > the timeout and so we are sometimes facing memory offline failures if > the system is under a heavy memory pressure or very intensive CPU > workload on large machines. > > It is not very clear what purpose the timeout actually serves. The > offline operation is interruptible by a signal so if userspace wants Hi Michal, If the user know what he should do if migration for a long time, it is OK, but I don't think all the users know this operation (e.g. ctrl + c) and the affect. >>> How is this operation any different from other potentially long >>> interruptible syscalls? >>> >> Hi Michal, >> >> I means the user should stop it by himself if migration always retry in >> endless. > If the memory is migrateable then the migration should finish > eventually. It can take some time but it shouldn't be an endless loop. But what if some how the temporary condition (page removed from the PCP LRU list and has not been freed yet to the buddy) happens again and again. I understand we have schedule() and yield() to make sure that the context does not hold the CPU for ever but it can take theoretically very long time if not endless to finish. In that case sending signal to the user space process who initiated the offline request is the only way to stop this retry loop. I think this is still a better approach than the 120 second timeout which was kind of arbitrary.
[RFC v3 3/7] platform/x86: intel_pmc_ipc: Use regmap calls for GCR updates
From: Kuppuswamy Sathyanarayanan
Currently, update_no_reboot_bit() function implemented in this driver
uses mutex_lock to protect its register updates. But this function is
called with in atomic context in iTCO_wdt_start() and iTCO_wdt_stop()
functions in iTCO_wdt.c driver, which in turn causes "sleeping into
atomic context" issue. This patch fixes this issue by refactoring the
current GCR read/write/update functions with regmap APIs.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/intel_pmc_ipc.c | 115 ---
2 files changed, 40 insertions(+), 76 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 80b8795..45f4e79 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1054,6 +1054,7 @@ config PVPANIC
config INTEL_PMC_IPC
tristate "Intel PMC IPC Driver"
depends on ACPI
+ select REGMAP_MMIO
---help---
This driver provides support for PMC control on some Intel platforms.
The PMC is an ARC processor which defines IPC commands for communication
diff --git a/drivers/platform/x86/intel_pmc_ipc.c
b/drivers/platform/x86/intel_pmc_ipc.c
index 021dcf6..40a25f8 100644
--- a/drivers/platform/x86/intel_pmc_ipc.c
+++ b/drivers/platform/x86/intel_pmc_ipc.c
@@ -31,9 +31,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
@@ -125,7 +127,7 @@ static struct intel_pmc_ipc_dev {
/* gcr */
void __iomem *gcr_mem_base;
- bool has_gcr_regs;
+ struct regmap *gcr_regs;
/* Telemetry */
u8 telem_res_inval;
@@ -150,6 +152,14 @@ static char *ipc_err_sources[] = {
"Unsigned kernel",
};
+static struct regmap_config gcr_regmap_config = {
+.reg_bits = 32,
+.reg_stride = 4,
+.val_bits = 32,
+ .fast_io = true,
+ .max_register = PLAT_RESOURCE_GCR_SIZE,
+};
+
/* Prevent concurrent calls to the PMC */
static DEFINE_MUTEX(ipclock);
@@ -183,21 +193,6 @@ static inline u32 ipc_data_readl(u32 offset)
return readl(ipcdev.ipc_base + IPC_READ_BUFFER + offset);
}
-static inline u64 gcr_data_readq(u32 offset)
-{
- return readq(ipcdev.gcr_mem_base + offset);
-}
-
-static inline int is_gcr_valid(u32 offset)
-{
- if (!ipcdev.has_gcr_regs)
- return -EACCES;
-
- if (offset > PLAT_RESOURCE_GCR_SIZE)
- return -EINVAL;
-
- return 0;
-}
/**
* intel_pmc_gcr_read() - Read PMC GCR register
@@ -210,21 +205,10 @@ static inline int is_gcr_valid(u32 offset)
*/
int intel_pmc_gcr_read(u32 offset, u32 *data)
{
- int ret;
-
- mutex_lock(&ipclock);
-
- ret = is_gcr_valid(offset);
- if (ret < 0) {
- mutex_unlock(&ipclock);
- return ret;
- }
-
- *data = readl(ipcdev.gcr_mem_base + offset);
-
- mutex_unlock(&ipclock);
+ if (!ipcdev.gcr_regs)
+ return -EACCES;
- return 0;
+ return regmap_read(ipcdev.gcr_regs, offset, data);
}
EXPORT_SYMBOL_GPL(intel_pmc_gcr_read);
@@ -240,21 +224,10 @@ EXPORT_SYMBOL_GPL(intel_pmc_gcr_read);
*/
int intel_pmc_gcr_write(u32 offset, u32 data)
{
- int ret;
-
- mutex_lock(&ipclock);
-
- ret = is_gcr_valid(offset);
- if (ret < 0) {
- mutex_unlock(&ipclock);
- return ret;
- }
-
- writel(data, ipcdev.gcr_mem_base + offset);
-
- mutex_unlock(&ipclock);
+ if (!ipcdev.gcr_regs)
+ return -EACCES;
- return 0;
+ return regmap_write(ipcdev.gcr_regs, offset, data);
}
EXPORT_SYMBOL_GPL(intel_pmc_gcr_write);
@@ -271,33 +244,10 @@ EXPORT_SYMBOL_GPL(intel_pmc_gcr_write);
*/
int intel_pmc_gcr_update(u32 offset, u32 mask, u32 val)
{
- u32 new_val;
- int ret = 0;
-
- mutex_lock(&ipclock);
-
- ret = is_gcr_valid(offset);
- if (ret < 0)
- goto gcr_ipc_unlock;
-
- new_val = readl(ipcdev.gcr_mem_base + offset);
-
- new_val &= ~mask;
- new_val |= val & mask;
-
- writel(new_val, ipcdev.gcr_mem_base + offset);
-
- new_val = readl(ipcdev.gcr_mem_base + offset);
-
- /* check whether the bit update is successful */
- if ((new_val & mask) != (val & mask)) {
- ret = -EIO;
- goto gcr_ipc_unlock;
- }
+ if (!ipcdev.gcr_regs)
+ return -EACCES;
-gcr_ipc_unlock:
- mutex_unlock(&ipclock);
- return ret;
+ return regmap_update_bits(ipcdev.gcr_regs, offset, mask, val);
}
EXPORT_SYMBOL_GPL(intel_pmc_gcr_update);
@@ -776,16 +726,24 @@ static int ipc_plat_get_res(struct platform_device *pdev)
int intel_pmc_s0ix_counter_read(u64 *data)
{
u64 deep, shlw;
+ int ret;
- if (!ipcdev.has_gcr_regs)
+ if (!ipcdev.gcr_regs)
return -EAC
[RFC v3 5/7] platform/x86: intel_punit_ipc: Use generic intel ipc device calls
From: Kuppuswamy Sathyanarayanan
Removed redundant IPC helper functions and refactored the driver to use
APIs provided by generic IPC driver. This patch also cleans-up PUNIT IPC
user drivers to use APIs provided by generic IPC driver.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
arch/x86/include/asm/intel_punit_ipc.h| 125 +--
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/intel_punit_ipc.c| 297 +-
drivers/platform/x86/intel_telemetry_pltdrv.c | 96 +
4 files changed, 216 insertions(+), 303 deletions(-)
Changes since v1:
* Removed custom APIs.
* Cleaned up PUNIT IPC user drivers to use APIs provided by generic
IPC driver.
diff --git a/arch/x86/include/asm/intel_punit_ipc.h
b/arch/x86/include/asm/intel_punit_ipc.h
index 201eb9d..cf1630c 100644
--- a/arch/x86/include/asm/intel_punit_ipc.h
+++ b/arch/x86/include/asm/intel_punit_ipc.h
@@ -1,10 +1,8 @@
#ifndef _ASM_X86_INTEL_PUNIT_IPC_H_
#define _ASM_X86_INTEL_PUNIT_IPC_H_
-/*
- * Three types of 8bit P-Unit IPC commands are supported,
- * bit[7:6]: [00]: BIOS; [01]: GTD; [10]: ISPD.
- */
+#include
+
typedef enum {
BIOS_IPC = 0,
GTDRIVER_IPC,
@@ -12,61 +10,60 @@ typedef enum {
RESERVED_IPC,
} IPC_TYPE;
-#define IPC_TYPE_OFFSET6
-#define IPC_PUNIT_BIOS_CMD_BASE(BIOS_IPC << IPC_TYPE_OFFSET)
-#define IPC_PUNIT_GTD_CMD_BASE (GTDDRIVER_IPC << IPC_TYPE_OFFSET)
-#define IPC_PUNIT_ISPD_CMD_BASE(ISPDRIVER_IPC <<
IPC_TYPE_OFFSET)
-#define IPC_PUNIT_CMD_TYPE_MASK(RESERVED_IPC <<
IPC_TYPE_OFFSET)
+#define PUNIT_BIOS_IPC_DEV "punit_bios_ipc"
+#define PUNIT_GTD_IPC_DEV "punit_gtd_ipc"
+#define PUNIT_ISP_IPC_DEV "punit_isp_ipc"
+#define PUNIT_PARAM_LEN3
/* BIOS => Pcode commands */
-#define IPC_PUNIT_BIOS_ZERO(IPC_PUNIT_BIOS_CMD_BASE | 0x00)
-#define IPC_PUNIT_BIOS_VR_INTERFACE(IPC_PUNIT_BIOS_CMD_BASE | 0x01)
-#define IPC_PUNIT_BIOS_READ_PCS
(IPC_PUNIT_BIOS_CMD_BASE | 0x02)
-#define IPC_PUNIT_BIOS_WRITE_PCS (IPC_PUNIT_BIOS_CMD_BASE | 0x03)
-#define IPC_PUNIT_BIOS_READ_PCU_CONFIG (IPC_PUNIT_BIOS_CMD_BASE | 0x04)
-#define IPC_PUNIT_BIOS_WRITE_PCU_CONFIG
(IPC_PUNIT_BIOS_CMD_BASE | 0x05)
-#define IPC_PUNIT_BIOS_READ_PL1_SETTING
(IPC_PUNIT_BIOS_CMD_BASE | 0x06)
-#define IPC_PUNIT_BIOS_WRITE_PL1_SETTING (IPC_PUNIT_BIOS_CMD_BASE | 0x07)
-#define IPC_PUNIT_BIOS_TRIGGER_VDD_RAM (IPC_PUNIT_BIOS_CMD_BASE | 0x08)
-#define IPC_PUNIT_BIOS_READ_TELE_INFO (IPC_PUNIT_BIOS_CMD_BASE | 0x09)
-#define IPC_PUNIT_BIOS_READ_TELE_TRACE_CTRL(IPC_PUNIT_BIOS_CMD_BASE | 0x0a)
-#define IPC_PUNIT_BIOS_WRITE_TELE_TRACE_CTRL (IPC_PUNIT_BIOS_CMD_BASE | 0x0b)
-#define IPC_PUNIT_BIOS_READ_TELE_EVENT_CTRL(IPC_PUNIT_BIOS_CMD_BASE | 0x0c)
-#define IPC_PUNIT_BIOS_WRITE_TELE_EVENT_CTRL (IPC_PUNIT_BIOS_CMD_BASE | 0x0d)
-#define IPC_PUNIT_BIOS_READ_TELE_TRACE (IPC_PUNIT_BIOS_CMD_BASE | 0x0e)
-#define IPC_PUNIT_BIOS_WRITE_TELE_TRACE
(IPC_PUNIT_BIOS_CMD_BASE | 0x0f)
-#define IPC_PUNIT_BIOS_READ_TELE_EVENT (IPC_PUNIT_BIOS_CMD_BASE | 0x10)
-#define IPC_PUNIT_BIOS_WRITE_TELE_EVENT
(IPC_PUNIT_BIOS_CMD_BASE | 0x11)
-#define IPC_PUNIT_BIOS_READ_MODULE_TEMP
(IPC_PUNIT_BIOS_CMD_BASE | 0x12)
-#define IPC_PUNIT_BIOS_RESERVED
(IPC_PUNIT_BIOS_CMD_BASE | 0x13)
-#define IPC_PUNIT_BIOS_READ_VOLTAGE_OVER (IPC_PUNIT_BIOS_CMD_BASE | 0x14)
-#define IPC_PUNIT_BIOS_WRITE_VOLTAGE_OVER (IPC_PUNIT_BIOS_CMD_BASE | 0x15)
-#define IPC_PUNIT_BIOS_READ_RATIO_OVER (IPC_PUNIT_BIOS_CMD_BASE | 0x16)
-#define IPC_PUNIT_BIOS_WRITE_RATIO_OVER
(IPC_PUNIT_BIOS_CMD_BASE | 0x17)
-#define IPC_PUNIT_BIOS_READ_VF_GL_CTRL (IPC_PUNIT_BIOS_CMD_BASE | 0x18)
-#define IPC_PUNIT_BIOS_WRITE_VF_GL_CTRL
(IPC_PUNIT_BIOS_CMD_BASE | 0x19)
-#define IPC_PUNIT_BIOS_READ_FM_SOC_TEMP_THRESH (IPC_PUNIT_BIOS_CMD_BASE | 0x1a)
-#define IPC_PUNIT_BIOS_WRITE_FM_SOC_TEMP_THRESH
(IPC_PUNIT_BIOS_CMD_BASE | 0x1b)
+#define IPC_PUNIT_BIOS_ZERO(0x00)
+#define IPC_PUNIT_BIOS_VR_INTERFACE(0x01)
+#define IPC_PUNIT_BIOS_READ_PCS(0x02)
+#define IPC_PUNIT_BIOS_WRITE_PCS (0x03)
+#define IPC_PUNIT_BIOS_READ_PCU_CONFIG (0x04)
+#define IPC_PUNIT_BIOS_WRITE_PCU_CONFIG(0x05)
+#define IPC_PUNIT_BIOS_READ_PL1_SETTING(0x06)
+#define IPC_PUNIT_BIOS_WRITE_PL1_SETTING (0x07)
+#define IPC_PUNIT_BIOS_TRIGGER_VDD_RAM (0x08)
+#define IPC_PUNIT_BIOS_READ_TELE_INFO (0x09)
+#define IPC_PUNIT_BIOS_READ_TELE_TRACE_CTRL(0x0a)
+#define IPC_PUNIT_BIOS_WRITE_TELE_TRACE_CTRL (0x0b)
+#d
[RFC v3 2/7] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices
From: Kuppuswamy Sathyanarayanan
Currently, we have lot of repetitive code in dependent device resource
allocation and device creation handling code. This logic can be improved if
we use MFD framework for dependent device creation. This patch adds this
support.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/platform/x86/intel_pmc_ipc.c | 397 +--
1 file changed, 142 insertions(+), 255 deletions(-)
diff --git a/drivers/platform/x86/intel_pmc_ipc.c
b/drivers/platform/x86/intel_pmc_ipc.c
index 5eef649..021dcf6 100644
--- a/drivers/platform/x86/intel_pmc_ipc.c
+++ b/drivers/platform/x86/intel_pmc_ipc.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
@@ -87,6 +88,7 @@
#define PLAT_RESOURCE_ISP_IFACE_INDEX 5
#define PLAT_RESOURCE_GTD_DATA_INDEX 6
#define PLAT_RESOURCE_GTD_IFACE_INDEX 7
+#define PLAT_RESOURCE_MEM_MAX_INDEX8
#define PLAT_RESOURCE_ACPI_IO_INDEX0
/*
@@ -105,8 +107,6 @@
#define TELEM_SSRAM_SIZE 240
#define TELEM_PMC_SSRAM_OFFSET 0x1B00
#define TELEM_PUNIT_SSRAM_OFFSET 0x1A00
-#define TCO_PMC_OFFSET 0x8
-#define TCO_PMC_SIZE 0x4
/* PMC register bit definitions */
@@ -123,25 +123,12 @@ static struct intel_pmc_ipc_dev {
int cmd;
struct completion cmd_complete;
- /* The following PMC BARs share the same ACPI device with the IPC */
- resource_size_t acpi_io_base;
- int acpi_io_size;
- struct platform_device *tco_dev;
-
/* gcr */
void __iomem *gcr_mem_base;
bool has_gcr_regs;
- /* punit */
- struct platform_device *punit_dev;
-
/* Telemetry */
- resource_size_t telem_pmc_ssram_base;
- resource_size_t telem_punit_ssram_base;
- int telem_pmc_ssram_size;
- int telem_punit_ssram_size;
u8 telem_res_inval;
- struct platform_device *telemetry_dev;
} ipcdev;
static char *ipc_err_sources[] = {
@@ -589,44 +576,6 @@ static const struct attribute_group intel_ipc_group = {
.attrs = intel_ipc_attrs,
};
-static struct resource punit_res_array[] = {
- /* Punit BIOS */
- {
- .flags = IORESOURCE_MEM,
- },
- {
- .flags = IORESOURCE_MEM,
- },
- /* Punit ISP */
- {
- .flags = IORESOURCE_MEM,
- },
- {
- .flags = IORESOURCE_MEM,
- },
- /* Punit GTD */
- {
- .flags = IORESOURCE_MEM,
- },
- {
- .flags = IORESOURCE_MEM,
- },
-};
-
-#define TCO_RESOURCE_ACPI_IO 0
-#define TCO_RESOURCE_SMI_EN_IO 1
-#define TCO_RESOURCE_GCR_MEM 2
-static struct resource tco_res[] = {
- /* ACPI - TCO */
- {
- .flags = IORESOURCE_IO,
- },
- /* ACPI - SMI */
- {
- .flags = IORESOURCE_IO,
- },
-};
-
static struct itco_wdt_platform_data tco_info = {
.name = "Apollo Lake SoC",
.version = 5,
@@ -634,237 +583,186 @@ static struct itco_wdt_platform_data tco_info = {
.update_no_reboot_bit = update_no_reboot_bit,
};
-#define TELEMETRY_RESOURCE_PUNIT_SSRAM 0
-#define TELEMETRY_RESOURCE_PMC_SSRAM 1
-static struct resource telemetry_res[] = {
- /*Telemetry*/
- {
- .flags = IORESOURCE_MEM,
- },
- {
- .flags = IORESOURCE_MEM,
- },
-};
-
-static int ipc_create_punit_device(void)
+static int ipc_create_punit_device(struct platform_device *pdev)
{
- struct platform_device *pdev;
- const struct platform_device_info pdevinfo = {
- .parent = ipcdev.dev,
- .name = PUNIT_DEVICE_NAME,
- .id = -1,
- .res = punit_res_array,
- .num_res = ARRAY_SIZE(punit_res_array),
+ struct resource *res;
+ static struct resource punit_res[PLAT_RESOURCE_MEM_MAX_INDEX];
+ static struct mfd_cell punit_cell;
+ int mindex, pindex = 0;
+
+ for (mindex = 0; mindex <= PLAT_RESOURCE_MEM_MAX_INDEX; mindex++) {
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, mindex);
+
+ switch (mindex) {
+ /* Get PUNIT resources */
+ case PLAT_RESOURCE_BIOS_DATA_INDEX:
+ case PLAT_RESOURCE_BIOS_IFACE_INDEX:
+ /* BIOS resources are required, so return error if not
+* available */
+ if (!res) {
+ dev_err(&pdev->dev,
+ "Failed to get punit mem resource %d\n",
+ pindex);
+ return -ENXIO;
+ }
+ case PLAT_RESOURCE_ISP_DATA_INDEX:
+ case PLAT_RESOURCE_ISP_IFACE_INDEX:
+ case PLAT_RESOURCE_GTD_DATA_INDEX:
+ case PLAT_R
[RFC v3 4/7] platform: x86: Add generic Intel IPC driver
From: Kuppuswamy Sathyanarayanan
Currently intel_scu_ipc.c, intel_pmc_ipc.c and intel_punit_ipc.c
redundantly implements the same IPC features and has lot of code
duplication between them. This driver addresses this issue by grouping
the common IPC functionalities under the same driver.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/platform/x86/Kconfig| 8 +
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/intel_ipc_dev.c| 539
include/linux/platform_data/x86/intel_ipc_dev.h | 187
4 files changed, 735 insertions(+)
create mode 100644 drivers/platform/x86/intel_ipc_dev.c
create mode 100644 include/linux/platform_data/x86/intel_ipc_dev.h
Changes since v2:
* Added ipc_dev_cmd API support.
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 45f4e79..9df7cda 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1140,6 +1140,14 @@ config SILEAD_DMI
with the OS-image for the device. This option supplies the missing
information. Enable this for x86 tablets with Silead touchscreens.
+config INTEL_IPC_DEV
+ bool "Intel IPC Device Driver"
+ depends on X86_64
+ ---help---
+ This driver implements core features of Intel IPC device. Devices
+ like PMC, SCU, PUNIT, etc can use interfaces provided by this
+ driver to implement IPC protocol of their respective device.
+
endif # X86_PLATFORM_DEVICES
config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 91cec17..04e11ce 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -83,3 +83,4 @@ obj-$(CONFIG_PMC_ATOM)+= pmc_atom.o
obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
obj-$(CONFIG_MLX_CPLD_PLATFORM)+= mlxcpld-hotplug.o
obj-$(CONFIG_INTEL_TURBO_MAX_3) += intel_turbo_max_3.o
+obj-$(CONFIG_INTEL_IPC_DEV)+= intel_ipc_dev.o
diff --git a/drivers/platform/x86/intel_ipc_dev.c
b/drivers/platform/x86/intel_ipc_dev.c
new file mode 100644
index 000..65db8bb
--- /dev/null
+++ b/drivers/platform/x86/intel_ipc_dev.c
@@ -0,0 +1,539 @@
+/*
+ * intel_ipc_dev.c: Intel IPC device class driver
+ *
+ * (C) Copyright 2017 Intel Corporation
+ *
+ * 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; version 2
+ * of the License.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* mutex to sync different ipc devices in same channel */
+static struct mutex channel_lock[IPC_CHANNEL_MAX];
+
+static void ipc_channel_lock_init(void)
+{
+ int i;
+
+ for (i = 0; i < IPC_CHANNEL_MAX; i++)
+ mutex_init(&channel_lock[i]);
+}
+
+static struct class intel_ipc_class = {
+ .name = "intel_ipc",
+ .owner = THIS_MODULE,
+};
+
+static int ipc_dev_lock(struct intel_ipc_dev *ipc_dev)
+{
+ int chan_type;
+
+ if (!ipc_dev || !ipc_dev->cfg)
+ return -ENODEV;
+
+ chan_type = ipc_dev->cfg->chan_type;
+ if (chan_type > IPC_CHANNEL_MAX)
+ return -EINVAL;
+
+ /* acquire channel lock */
+ mutex_lock(&channel_lock[chan_type]);
+
+ /* acquire IPC device lock */
+ mutex_lock(&ipc_dev->lock);
+
+ return 0;
+}
+
+static int ipc_dev_unlock(struct intel_ipc_dev *ipc_dev)
+{
+ int chan_type;
+
+ if (!ipc_dev || !ipc_dev->cfg)
+ return -ENODEV;
+
+ chan_type = ipc_dev->cfg->chan_type;
+ if (chan_type > IPC_CHANNEL_MAX)
+ return -EINVAL;
+
+ /* release IPC device lock */
+ mutex_unlock(&ipc_dev->lock);
+
+ /* release channel lock */
+ mutex_unlock(&channel_lock[chan_type]);
+
+ return 0;
+}
+
+static const char *ipc_dev_err_string(struct intel_ipc_dev *ipc_dev,
+ int error)
+{
+ switch (error) {
+ case IPC_DEV_ERR_NONE:
+ return "No error";
+ case IPC_DEV_ERR_CMD_NOT_SUPPORTED:
+ return "Command not-supported/Invalid";
+ case IPC_DEV_ERR_CMD_NOT_SERVICED:
+ return "Command not-serviced/Invalid param";
+ case IPC_DEV_ERR_UNABLE_TO_SERVICE:
+ return "Unable-to-service/Cmd-timeout";
+ case IPC_DEV_ERR_CMD_INVALID:
+ return "Command-invalid/Cmd-locked";
+ case IPC_DEV_ERR_CMD_FAILED:
+ return "Command-failed/Invalid-VR-id";
+ case IPC_DEV_ERR_EMSECURITY:
+ return "Invalid Battery/VR-Error";
+ case IPC_DEV_ERR_UNSIGNEDKERNEL:
+ return "Unsigned kernel";
+ default:
+ return "Unknown Command";
+ };
+}
+
+/* Helper function to send given command to IPC device */
+static inline void ipc_dev_send_cmd(struct
[RFC v3 0/7] PMC/PUNIT IPC driver cleanup
From: Kuppuswamy Sathyanarayanan Hi All, Currently intel_pmc_ipc.c, intel_punit_ipc.c, intel_scu_ipc.c drivers implements the same IPC features. This code duplication could be avoided if we implement the IPC driver as a generic library and let custom device drivers use API provided by generic driver. This patchset mainly addresses this issue. Along with above code duplication issue, This patchset also addresses following issues in intel_pmc_ipc and intel_punit_ipc drivers. 1. Intel_pmc_ipc.c driver does not use any resource managed (devm_*) calls. 2. In Intel_pmc_ipc.c driver, dependent devices like PUNIT, Telemetry and iTCO are created manually and uses lot of redundant buffer code. 3. Global variable is used to store the IPC device structure and it is used across all functions in intel_pmc_ipc.c and intel_punit_ipc.c. More info on Intel IPC device library: - A generic Intel IPC class driver has been implemented and all common IPC helper functions has been moved to this driver. It exposes APIs to create IPC device channel, send raw IPC command and simple IPC commands. It also creates device attribute to send IPC command from user space. API for creating a new IPC channel device is, struct intel_ipc_dev *devm_intel_ipc_dev_create(struct device *dev, const char *devname, struct intel_ipc_dev_cfg *cfg, struct intel_ipc_dev_ops *ops) The IPC channel drivers (PUNIT/PMC/SCU) when creating a new device can configure their device params like register mapping, irq, irq-mode, channel type,etc using intel_ipc_dev_cfg and intel_ipc_dev_ops arguments. After a new IPC channel device is created, IPC users can use the generic APIs to make IPC calls. For example, after using this new model, IPC call to PMC device will look like, pmc_ipc_dev = intel_ipc_dev_get(INTEL_PMC_IPC_DEV); ipc_dev_raw_cmd(pmc_ipc_dev, cmd, PMC_PARAM_LEN, (u32 *)ipc_in, 1, NULL, 0, 0, 0); I am still testing the driver in different products. But posted it to get some early comments. I also welcome any PMC/PUNIT driver users to check these patches in their product. Changes since v2: * Refactored intel_scu_ipc.c to use generic IPC device APIs. * Fixed intel_pmc_ipc.c to use pcim_* device managed functions. Changes since v1: * Merged devm_* changes in pmc_plat_probe and pmc_pci_probe functions into a single patch. * Addressed Andy's comment about keeping the library generic by not implementing the low level reg access calls in intel_ipc_dev.c. This version will start using the regmap pointer provided by channel drivers instead of fixed memory map. * Removed custom IPC APIs in intel_pmc_ipc.c and intel_punit_ipc.c. * Cleaned up IPC driver users to use APIs provided by generic library (intel_ipc_dev.c). Kuppuswamy Sathyanarayanan (7): platform/x86: intel_pmc_ipc: Use devm_* calls in driver probe function platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices platform/x86: intel_pmc_ipc: Use regmap calls for GCR updates platform: x86: Add generic Intel IPC driver platform/x86: intel_punit_ipc: Use generic intel ipc device calls platform/x86: intel_pmc_ipc: Use generic Intel IPC device calls platform/x86: intel_scu_ipc: Use generic Intel IPC device calls arch/x86/include/asm/intel_pmc_ipc.h| 37 +- arch/x86/include/asm/intel_punit_ipc.h | 125 ++-- arch/x86/include/asm/intel_scu_ipc.h| 23 +- arch/x86/platform/intel-mid/intel-mid.c | 12 +- drivers/mfd/intel_soc_pmic_bxtwc.c | 18 +- drivers/platform/x86/Kconfig| 11 + drivers/platform/x86/Makefile | 1 + drivers/platform/x86/intel_ipc_dev.c| 539 ++ drivers/platform/x86/intel_pmc_ipc.c| 948 +--- drivers/platform/x86/intel_punit_ipc.c | 297 +++- drivers/platform/x86/intel_scu_ipc.c| 483 +--- drivers/platform/x86/intel_telemetry_pltdrv.c | 210 +++--- drivers/rtc/rtc-mrst.c | 15 +- drivers/watchdog/intel-mid_wdt.c| 12 +- drivers/watchdog/intel_scu_watchdog.c | 17 +- include/linux/mfd/intel_soc_pmic.h | 2 + include/linux/platform_data/x86/intel_ipc_dev.h | 187 + 17 files changed, 1617 insertions(+), 1320 deletions(-) create mode 100644 drivers/platform/x86/intel_ipc_dev.c create mode 100644 include/linux/platform_data/x86/intel_ipc_dev.h -- 2.7.4
[RFC v3 1/7] platform/x86: intel_pmc_ipc: Use devm_* calls in driver probe function
From: Kuppuswamy Sathyanarayanan
This patch cleans up unnecessary free/alloc calls in ipc_plat_probe(),
ipc_pci_probe() and ipc_plat_get_res() functions by using devm_*
calls.
This patch also adds proper error handling for failure cases in
ipc_pci_probe() function.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/platform/x86/intel_pmc_ipc.c | 104 ---
1 file changed, 34 insertions(+), 70 deletions(-)
Changes since v2:
* Used pcim_* device managed functions.
Changes since v1:
* Merged devm_* related changes into a single function.
* Instead of removing free_irq, use devm_free_irq function.
diff --git a/drivers/platform/x86/intel_pmc_ipc.c
b/drivers/platform/x86/intel_pmc_ipc.c
index bb792a5..5eef649 100644
--- a/drivers/platform/x86/intel_pmc_ipc.c
+++ b/drivers/platform/x86/intel_pmc_ipc.c
@@ -480,52 +480,39 @@ static irqreturn_t ioc(int irq, void *dev_id)
static int ipc_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
- resource_size_t pci_resource;
int ret;
- int len;
+ struct intel_pmc_ipc_dev *pmc = &ipcdev;
- ipcdev.dev = &pci_dev_get(pdev)->dev;
- ipcdev.irq_mode = IPC_TRIGGER_MODE_IRQ;
+ /* Only one PMC is supported */
+ if (pmc->dev)
+ return -EBUSY;
- ret = pci_enable_device(pdev);
+ pmc->irq_mode = IPC_TRIGGER_MODE_IRQ;
+
+ ret = pcim_enable_device(pdev);
if (ret)
return ret;
- ret = pci_request_regions(pdev, "intel_pmc_ipc");
+ ret = pcim_iomap_regions(pdev, 1 << 0, pci_name(pdev));
if (ret)
return ret;
- pci_resource = pci_resource_start(pdev, 0);
- len = pci_resource_len(pdev, 0);
- if (!pci_resource || !len) {
- dev_err(&pdev->dev, "Failed to get resource\n");
- return -ENOMEM;
- }
+ init_completion(&pmc->cmd_complete);
- init_completion(&ipcdev.cmd_complete);
+ pmc->ipc_base = pcim_iomap_table(pdev)[0];
- if (request_irq(pdev->irq, ioc, 0, "intel_pmc_ipc", &ipcdev)) {
+ ret = devm_request_irq(&pdev->dev, pdev->irq, ioc, 0, "intel_pmc_ipc",
+ pmc);
+ if (ret) {
dev_err(&pdev->dev, "Failed to request irq\n");
- return -EBUSY;
+ return ret;
}
- ipcdev.ipc_base = ioremap_nocache(pci_resource, len);
- if (!ipcdev.ipc_base) {
- dev_err(&pdev->dev, "Failed to ioremap ipc base\n");
- free_irq(pdev->irq, &ipcdev);
- ret = -ENOMEM;
- }
+ pmc->dev = &pdev->dev;
- return ret;
-}
+ pci_set_drvdata(pdev, pmc);
-static void ipc_pci_remove(struct pci_dev *pdev)
-{
- free_irq(pdev->irq, &ipcdev);
- pci_release_regions(pdev);
- pci_dev_put(pdev);
- iounmap(ipcdev.ipc_base);
- ipcdev.dev = NULL;
+ return 0;
}
static const struct pci_device_id ipc_pci_ids[] = {
@@ -540,7 +527,6 @@ static struct pci_driver ipc_pci_driver = {
.name = "intel_pmc_ipc",
.id_table = ipc_pci_ids,
.probe = ipc_pci_probe,
- .remove = ipc_pci_remove,
};
static ssize_t intel_pmc_ipc_simple_cmd_store(struct device *dev,
@@ -849,18 +835,16 @@ static int ipc_plat_get_res(struct platform_device *pdev)
dev_err(&pdev->dev, "Failed to get ipc resource\n");
return -ENXIO;
}
- size = PLAT_RESOURCE_IPC_SIZE + PLAT_RESOURCE_GCR_SIZE;
+ res->end = (res->start + PLAT_RESOURCE_IPC_SIZE +
+ PLAT_RESOURCE_GCR_SIZE - 1);
- if (!request_mem_region(res->start, size, pdev->name)) {
- dev_err(&pdev->dev, "Failed to request ipc resource\n");
- return -EBUSY;
- }
- addr = ioremap_nocache(res->start, size);
- if (!addr) {
- dev_err(&pdev->dev, "I/O memory remapping failed\n");
- release_mem_region(res->start, size);
- return -ENOMEM;
+ addr = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(addr)) {
+ dev_err(&pdev->dev,
+ "PMC I/O memory remapping failed\n");
+ return PTR_ERR(addr);
}
+
ipcdev.ipc_base = addr;
ipcdev.gcr_mem_base = addr + PLAT_RESOURCE_GCR_OFFSET;
@@ -917,7 +901,6 @@ MODULE_DEVICE_TABLE(acpi, ipc_acpi_ids);
static int ipc_plat_probe(struct platform_device *pdev)
{
- struct resource *res;
int ret;
ipcdev.dev = &pdev->dev;
@@ -939,61 +922,42 @@ static int ipc_plat_probe(struct platform_device *pdev)
ret = ipc_create_pmc_devices();
if (ret) {
dev_err(&pdev->dev, "Failed to create pmc devices\n");
- goto err_device;
+ return ret;
}
- if (request_irq(ipcdev.irq, ioc, IRQF_NO_SUSPEND,
- "intel_pmc_ipc", &ipcdev)) {
+ if (d
[RFC v3 6/7] platform/x86: intel_pmc_ipc: Use generic Intel IPC device calls
From: Kuppuswamy Sathyanarayanan
Removed redundant IPC helper functions and refactored the driver to use
generic IPC device driver APIs. Also, cleaned up the driver to minimize
the usage of global variable ipcdev by propogating the struct
intel_pmc_ipc_dev pointer or by getting it from device private data.
This patch also cleans-up PMC IPC user drivers to use APIs provided
by generic IPC driver.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
arch/x86/include/asm/intel_pmc_ipc.h | 37 +--
drivers/mfd/intel_soc_pmic_bxtwc.c| 18 +-
drivers/platform/x86/intel_pmc_ipc.c | 406 ++
drivers/platform/x86/intel_telemetry_pltdrv.c | 118
include/linux/mfd/intel_soc_pmic.h| 2 +
5 files changed, 238 insertions(+), 343 deletions(-)
Changes since v1:
* Removed custom APIs.
* Cleaned up PMC IPC user drivers to use APIs provided by generic
IPC driver.
diff --git a/arch/x86/include/asm/intel_pmc_ipc.h
b/arch/x86/include/asm/intel_pmc_ipc.h
index fac89eb..9fc7c3c 100644
--- a/arch/x86/include/asm/intel_pmc_ipc.h
+++ b/arch/x86/include/asm/intel_pmc_ipc.h
@@ -1,10 +1,15 @@
#ifndef _ASM_X86_INTEL_PMC_IPC_H_
#define _ASM_X86_INTEL_PMC_IPC_H_
+#include
+
+#define INTEL_PMC_IPC_DEV "intel_pmc_ipc"
+#define PMC_PARAM_LEN 2
+
/* Commands */
#define PMC_IPC_PMIC_ACCESS0xFF
-#definePMC_IPC_PMIC_ACCESS_READ0x0
-#definePMC_IPC_PMIC_ACCESS_WRITE 0x1
+#definePMC_IPC_PMIC_ACCESS_READ0x0
+#definePMC_IPC_PMIC_ACCESS_WRITE 0x1
#define PMC_IPC_USB_PWR_CTRL 0xF0
#define PMC_IPC_PMIC_BLACKLIST_SEL 0xEF
#define PMC_IPC_PHY_CONFIG 0xEE
@@ -28,13 +33,14 @@
#define PMC_GCR_TELEM_DEEP_S0IX_REG0x78
#define PMC_GCR_TELEM_SHLW_S0IX_REG0x80
+static inline void pmc_cmd_init(u32 *cmd, u32 param1, u32 param2)
+{
+ cmd[0] = param1;
+ cmd[1] = param2;
+}
+
#if IS_ENABLED(CONFIG_INTEL_PMC_IPC)
-int intel_pmc_ipc_simple_command(int cmd, int sub);
-int intel_pmc_ipc_raw_cmd(u32 cmd, u32 sub, u8 *in, u32 inlen,
- u32 *out, u32 outlen, u32 dptr, u32 sptr);
-int intel_pmc_ipc_command(u32 cmd, u32 sub, u8 *in, u32 inlen,
- u32 *out, u32 outlen);
int intel_pmc_s0ix_counter_read(u64 *data);
int intel_pmc_gcr_read(u32 offset, u32 *data);
int intel_pmc_gcr_write(u32 offset, u32 data);
@@ -42,23 +48,6 @@ int intel_pmc_gcr_update(u32 offset, u32 mask, u32 val);
#else
-static inline int intel_pmc_ipc_simple_command(int cmd, int sub)
-{
- return -EINVAL;
-}
-
-static inline int intel_pmc_ipc_raw_cmd(u32 cmd, u32 sub, u8 *in, u32 inlen,
- u32 *out, u32 outlen, u32 dptr, u32 sptr)
-{
- return -EINVAL;
-}
-
-static inline int intel_pmc_ipc_command(u32 cmd, u32 sub, u8 *in, u32 inlen,
- u32 *out, u32 outlen)
-{
- return -EINVAL;
-}
-
static inline int intel_pmc_s0ix_counter_read(u64 *data)
{
return -EINVAL;
diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c
b/drivers/mfd/intel_soc_pmic_bxtwc.c
index 15bc052..ea60049 100644
--- a/drivers/mfd/intel_soc_pmic_bxtwc.c
+++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
@@ -271,6 +271,8 @@ static int regmap_ipc_byte_reg_read(void *context, unsigned
int reg,
u8 ipc_in[2];
u8 ipc_out[4];
struct intel_soc_pmic *pmic = context;
+ u32 cmd[PMC_PARAM_LEN] = {PMC_IPC_PMIC_ACCESS,
+ PMC_IPC_PMIC_ACCESS_READ};
if (!pmic)
return -EINVAL;
@@ -284,9 +286,8 @@ static int regmap_ipc_byte_reg_read(void *context, unsigned
int reg,
ipc_in[0] = reg;
ipc_in[1] = i2c_addr;
- ret = intel_pmc_ipc_command(PMC_IPC_PMIC_ACCESS,
- PMC_IPC_PMIC_ACCESS_READ,
- ipc_in, sizeof(ipc_in), (u32 *)ipc_out, 1);
+ ret = ipc_dev_raw_cmd(pmic->ipc_dev, cmd, PMC_PARAM_LEN, ipc_in,
+ sizeof(ipc_in), (u32 *)ipc_out, 1, 0, 0);
if (ret) {
dev_err(pmic->dev, "Failed to read from PMIC\n");
return ret;
@@ -303,6 +304,8 @@ static int regmap_ipc_byte_reg_write(void *context,
unsigned int reg,
int i2c_addr;
u8 ipc_in[3];
struct intel_soc_pmic *pmic = context;
+ u32 cmd[PMC_PARAM_LEN] = {PMC_IPC_PMIC_ACCESS,
+ PMC_IPC_PMIC_ACCESS_WRITE};
if (!pmic)
return -EINVAL;
@@ -317,9 +320,8 @@ static int regmap_ipc_byte_reg_write(void *context,
unsigned int reg,
ipc_in[0] = reg;
ipc_in[1] = i2c_addr;
ipc_in[2] = val;
- ret = intel_pmc_ipc_command(PMC_IPC_PMIC_ACCESS,
- PMC_IPC_PMIC_ACCESS_WRITE,
- ipc_in, sizeof(ipc_in), NULL, 0);
+ ret = ipc_dev_raw_cmd(pmic->ipc_dev, cmd, PMC_PARAM_LEN, ipc_in,
+ sizeof(ipc_in), NULL, 0, 0, 0);
if (ret) {
dev_e
[RFC v3 7/7] platform/x86: intel_scu_ipc: Use generic Intel IPC device calls
From: Kuppuswamy Sathyanarayanan
Removed redundant IPC helper functions and refactored the driver to use
generic IPC device driver APIs.
This patch also cleans-up SCU IPC user drivers to use APIs provided
by generic IPC driver.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
arch/x86/include/asm/intel_scu_ipc.h| 23 +-
arch/x86/platform/intel-mid/intel-mid.c | 12 +-
drivers/platform/x86/Kconfig| 1 +
drivers/platform/x86/intel_scu_ipc.c| 483 +---
drivers/rtc/rtc-mrst.c | 15 +-
drivers/watchdog/intel-mid_wdt.c| 12 +-
drivers/watchdog/intel_scu_watchdog.c | 17 +-
7 files changed, 251 insertions(+), 312 deletions(-)
diff --git a/arch/x86/include/asm/intel_scu_ipc.h
b/arch/x86/include/asm/intel_scu_ipc.h
index 81d3d87..5842534 100644
--- a/arch/x86/include/asm/intel_scu_ipc.h
+++ b/arch/x86/include/asm/intel_scu_ipc.h
@@ -14,9 +14,19 @@
#define IPCMSG_COLD_BOOT 0xF3
#define IPCMSG_VRTC0xFA /* Set vRTC device */
- /* Command id associated with message IPCMSG_VRTC */
- #define IPC_CMD_VRTC_SETTIME 1 /* Set time */
- #define IPC_CMD_VRTC_SETALARM 2 /* Set alarm */
+
+/* Command id associated with message IPCMSG_VRTC */
+#define IPC_CMD_VRTC_SETTIME 1 /* Set time */
+#define IPC_CMD_VRTC_SETALARM 2 /* Set alarm */
+
+#define INTEL_SCU_IPC_DEV "intel_scu_ipc"
+#define SCU_PARAM_LEN 2
+
+static inline void scu_cmd_init(u32 *cmd, u32 param1, u32 param2)
+{
+ cmd[0] = param1;
+ cmd[1] = param2;
+}
/* Read single register */
int intel_scu_ipc_ioread8(u16 addr, u8 *data);
@@ -45,13 +55,6 @@ int intel_scu_ipc_writev(u16 *addr, u8 *data, int len);
/* Update single register based on the mask */
int intel_scu_ipc_update_register(u16 addr, u8 data, u8 mask);
-/* Issue commands to the SCU with or without data */
-int intel_scu_ipc_simple_command(int cmd, int sub);
-int intel_scu_ipc_command(int cmd, int sub, u32 *in, int inlen,
- u32 *out, int outlen);
-int intel_scu_ipc_raw_command(int cmd, int sub, u8 *in, int inlen,
- u32 *out, int outlen, u32 dptr, u32 sptr);
-
/* I2C control api */
int intel_scu_ipc_i2c_cntrl(u32 addr, u32 *data);
diff --git a/arch/x86/platform/intel-mid/intel-mid.c
b/arch/x86/platform/intel-mid/intel-mid.c
index 12a2725..27541e9 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -68,18 +69,23 @@ static void *(*get_intel_mid_ops[])(void) =
INTEL_MID_OPS_INIT;
enum intel_mid_cpu_type __intel_mid_cpu_chip;
EXPORT_SYMBOL_GPL(__intel_mid_cpu_chip);
+static struct intel_ipc_dev *ipc_dev;
+
static void intel_mid_power_off(void)
{
+ u32 cmds[SCU_PARAM_LEN] = {IPCMSG_COLD_OFF, 1};
/* Shut down South Complex via PWRMU */
intel_mid_pwr_power_off();
/* Only for Tangier, the rest will ignore this command */
- intel_scu_ipc_simple_command(IPCMSG_COLD_OFF, 1);
+ ipc_dev_simple_cmd(ipc_dev, cmds, SCU_PARAM_LEN);
};
static void intel_mid_reboot(void)
{
- intel_scu_ipc_simple_command(IPCMSG_COLD_BOOT, 0);
+ u32 cmds[SCU_PARAM_LEN] = {IPCMSG_COLD_BOOT, 0};
+
+ ipc_dev_simple_cmd(ipc_dev, cmds, SCU_PARAM_LEN);
}
static unsigned long __init intel_mid_calibrate_tsc(void)
@@ -206,6 +212,8 @@ void __init x86_intel_mid_early_setup(void)
x86_init.mpparse.find_smp_config = x86_init_noop;
x86_init.mpparse.get_smp_config = x86_init_uint_noop;
set_bit(MP_BUS_ISA, mp_bus_not_pci);
+
+ ipc_dev = intel_ipc_dev_get(INTEL_SCU_IPC_DEV);
}
/*
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 82479ca..e4e5822 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -850,6 +850,7 @@ config INTEL_VBTN
config INTEL_SCU_IPC
bool "Intel SCU IPC Support"
depends on X86_INTEL_MID
+ select REGMAP_MMIO
default y
---help---
IPC is used to bridge the communications between kernel and SCU on
diff --git a/drivers/platform/x86/intel_scu_ipc.c
b/drivers/platform/x86/intel_scu_ipc.c
index f7cf981..78013e4 100644
--- a/drivers/platform/x86/intel_scu_ipc.c
+++ b/drivers/platform/x86/intel_scu_ipc.c
@@ -24,6 +24,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -39,6 +41,25 @@
#define IPC_CMD_PCNTRL_R 1 /* Register read */
#define IPC_CMD_PCNTRL_M 2 /* Register read-modify-write */
+/* IPC dev register offsets */
+/*
+ * IPC Read Buffer (Read Only):
+ * 16 byte buffer for receiving data from SCU, if IPC command
+ * processing results in response data
+ */
+#define IPC_DEV_SCU_RBUF_OFFSET0x90
+#define IPC_DEV_SCU_WRBUF_OFFSET 0x80
+#define IPC_DEV_SCU_SPTR_OFFSET
[PATCH] tracing: Fix clear of RECORDED_TGID flag when disabling trace event
When disabling one trace event, the RECORDED_TGID flag in the event
file is not correctly cleared. It's clearing RECORDED_CMD flag when
it should clear RECORDED_TGID flag. Fix d914ba37("tracing: Add support
for recording tgid of tasks")
Signed-off-by: Chunyu Hu
---
kernel/trace/trace_events.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index c93540c..8746839 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -406,7 +406,7 @@ static int __ftrace_event_enable_disable(struct
trace_event_file *file,
if (file->flags & EVENT_FILE_FL_RECORDED_TGID) {
tracing_stop_tgid_record();
- clear_bit(EVENT_FILE_FL_RECORDED_CMD_BIT,
&file->flags);
+ clear_bit(EVENT_FILE_FL_RECORDED_TGID_BIT,
&file->flags);
}
call->class->reg(call, TRACE_REG_UNREGISTER, file);
--
1.8.3.1
[tip:perf/urgent] perf intel-pt: Fix syntax in documentation of config option
Commit-ID: 4fb205392022ba99a45dd01a62c6e2df046e400a Gitweb: http://git.kernel.org/tip/4fb205392022ba99a45dd01a62c6e2df046e400a Author: Jack Henschel AuthorDate: Thu, 31 Aug 2017 10:05:35 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Fri, 1 Sep 2017 14:45:59 -0300 perf intel-pt: Fix syntax in documentation of config option As specified in tools/perf/Documentation/perf-config.txt, perf configuration items must be in 'key = value' format, otherwise the following error message occurs: $ perf record -e intel_pt//u -- ls bad config file line 2 in ~/.perfconfig $ cat .perfconfig [intel-pt] mispred-all Changing to assigning a value to the key 'mispred-all' fixes the issue: $ perf record -e intel_pt//u -- ls [ perf record: Woken up 1 times to write data ] [ perf record: Capured and wrote 0.031 MB perf.data] $ cat .perfconfig [intel-pt] mispred-all = true Signed-off-by: Jack Henschel Cc: Alexander Shishkin Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20170831080535.2157-1-jack...@mailbox.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Documentation/intel-pt.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Documentation/intel-pt.txt b/tools/perf/Documentation/intel-pt.txt index ab1b082..76971d2 100644 --- a/tools/perf/Documentation/intel-pt.txt +++ b/tools/perf/Documentation/intel-pt.txt @@ -873,7 +873,7 @@ amended to take the number of elements as a parameter. $ cat ~/.perfconfig [intel-pt] - mispred-all + mispred-all = on $ perf record -e intel_pt//u ./sort 3000 Bubble sorting array of 3000 elements
linux-next: manual merge of the akpm-current tree with the net-next tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/sh/configs/se7751_defconfig
between commit:
9efdb14f76f4 ("net: Remove CONFIG_NETFILTER_DEBUG and _ASSERT() macros.")
from the net-next tree and commit:
a83883ff2285 ("sh: defconfig: cleanup from old Kconfig options")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/sh/configs/se7751_defconfig
index 56b5e4ce8d4a,153e1d3c8be5..
--- a/arch/sh/configs/se7751_defconfig
+++ b/arch/sh/configs/se7751_defconfig
@@@ -25,12 -24,10 +24,9 @@@ CONFIG_IP_PNP=
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
- # CONFIG_INET_LRO is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
- CONFIG_IP_NF_QUEUE=y
-CONFIG_NETFILTER_DEBUG=y
CONFIG_MTD=y
- CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_AMDSTD=y
[tip:perf/urgent] perf stat: Only auto-merge events that are PMU aliases
Commit-ID: 63ce8449bc1081711eef1add68909e9bd758de62
Gitweb: http://git.kernel.org/tip/63ce8449bc1081711eef1add68909e9bd758de62
Author: Arnaldo Carvalho de Melo
AuthorDate: Thu, 31 Aug 2017 15:32:18 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 Sep 2017 14:48:59 -0300
perf stat: Only auto-merge events that are PMU aliases
Peter reported that when he explicitely asked for multiple events with
the same name on the command line it got coalesced into just one line,
i.e.:
# perf stat -e cycles -e cycles -e cycles usleep 1
Performance counter stats for 'usleep 1':
3,269,652 cycles
0.000884123 seconds time elapsed
#
And while there is the --no-merges option to disable that auto-merging,
this is a blunt change in behaviour for such explicit request, so change
the code so that this auto merging is done only when handling the multi
PMU aliases with the same name that introduced this coalescing,
restoring the previous behaviour for the explicit case:
# perf stat -e cycles -e cycles -e cycles usleep 1
Performance counter stats for 'usleep 1':
1,472,837 cycles
1,472,837 cycles
1,472,837 cycles
0.001764870 seconds time elapsed
#
Reported-by: Peter Zijlstra
Acked-by: Andi Kleen
Acked-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Wang Nan
Fixes: 430daf2dc7af ("perf stat: Collapse identically named events")
Link: http://lkml.kernel.org/r/20170831184122.gk4...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 2 +-
tools/perf/util/evsel.h| 1 +
tools/perf/util/parse-events.c | 24
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 866da7a..85e992d 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1257,7 +1257,7 @@ static bool collect_data(struct perf_evsel *counter,
if (counter->merged_stat)
return false;
cb(counter, data, true);
- if (!no_merge)
+ if (!no_merge && counter->auto_merge_stats)
collect_all_aliases(counter, cb, data);
return true;
}
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 351d3b2..dd2c4b5 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -131,6 +131,7 @@ struct perf_evsel {
boolcmdline_group_boundary;
struct list_headconfig_terms;
int bpf_fd;
+ boolauto_merge_stats;
boolmerged_stat;
const char *metric_expr;
const char *metric_name;
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index f44aeba..f6257fb 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -310,7 +310,7 @@ static struct perf_evsel *
__add_event(struct list_head *list, int *idx,
struct perf_event_attr *attr,
char *name, struct cpu_map *cpus,
- struct list_head *config_terms)
+ struct list_head *config_terms, bool auto_merge_stats)
{
struct perf_evsel *evsel;
@@ -324,6 +324,7 @@ __add_event(struct list_head *list, int *idx,
evsel->cpus= cpu_map__get(cpus);
evsel->own_cpus= cpu_map__get(cpus);
evsel->system_wide = !!cpus;
+ evsel->auto_merge_stats = auto_merge_stats;
if (name)
evsel->name = strdup(name);
@@ -339,7 +340,7 @@ static int add_event(struct list_head *list, int *idx,
struct perf_event_attr *attr, char *name,
struct list_head *config_terms)
{
- return __add_event(list, idx, attr, name, NULL, config_terms) ? 0 :
-ENOMEM;
+ return __add_event(list, idx, attr, name, NULL, config_terms, false) ?
0 : -ENOMEM;
}
static int parse_aliases(char *str, const char
*names[][PERF_EVSEL__MAX_ALIASES], int size)
@@ -1209,9 +1210,9 @@ int parse_events_add_numeric(struct parse_events_state
*parse_state,
get_config_name(head_config), &config_terms);
}
-int parse_events_add_pmu(struct parse_events_state *parse_state,
+static int __parse_events_add_pmu(struct parse_events_state *parse_state,
struct list_head *list, char *name,
-struct list_head *head_config)
+struct list_head *head_config, bool auto_merge_stats)
{
struct perf_event_attr attr;
struct perf_pmu_info info;
@@ -1232,7 +1233,7 @@ int parse_events_add_pmu(struct parse_events_state
*parse_state,
if (!head_config) {
attr.type = pmu->type;
- evsel = __add_event(list, &parse_state->idx, &attr, NULL,
pmu->cpus, NULL);
+ evsel = __add_event(list, &parse_state->idx, &attr, NULL,
pmu->cpus, NUL
[tip:perf/urgent] perf script: Support physical address
Commit-ID: 49d58f04eb6cdc18b3747fc4243a7114364f5420
Gitweb: http://git.kernel.org/tip/49d58f04eb6cdc18b3747fc4243a7114364f5420
Author: Kan Liang
AuthorDate: Tue, 29 Aug 2017 13:11:11 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 Sep 2017 14:46:29 -0300
perf script: Support physical address
Display the physical address at the tail if it is available.
Signed-off-by: Kan Liang
Tested-by: Jiri Olsa
Acked-by: Stephane Eranian
Cc: Andi Kleen
Cc: Madhavan Srinivasan
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1504026672-7304-5-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-script.txt | 2 +-
tools/perf/builtin-script.c | 15 +--
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/tools/perf/Documentation/perf-script.txt
b/tools/perf/Documentation/perf-script.txt
index 5ee8796..18dfcfa 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -117,7 +117,7 @@ OPTIONS
Comma separated list of fields to print. Options are:
comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff,
srcline, period, iregs, brstack, brstacksym, flags, bpf-output,
brstackinsn, brstackoff,
-callindent, insn, insnlen, synth.
+callindent, insn, insnlen, synth, phys_addr.
Field list can be prepended with the type, trace, sw or hw,
to indicate to which event type the field list applies.
e.g., -F sw:comm,tid,time,ip,sym and -F trace:time,cpu,trace
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 378f76c..3d4c3b5 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -87,6 +87,7 @@ enum perf_output_field {
PERF_OUTPUT_BRSTACKINSN = 1U << 23,
PERF_OUTPUT_BRSTACKOFF = 1U << 24,
PERF_OUTPUT_SYNTH = 1U << 25,
+ PERF_OUTPUT_PHYS_ADDR = 1U << 26,
};
struct output_option {
@@ -119,6 +120,7 @@ struct output_option {
{.str = "brstackinsn", .field = PERF_OUTPUT_BRSTACKINSN},
{.str = "brstackoff", .field = PERF_OUTPUT_BRSTACKOFF},
{.str = "synth", .field = PERF_OUTPUT_SYNTH},
+ {.str = "phys_addr", .field = PERF_OUTPUT_PHYS_ADDR},
};
enum {
@@ -175,7 +177,8 @@ static struct {
PERF_OUTPUT_EVNAME | PERF_OUTPUT_IP |
PERF_OUTPUT_SYM | PERF_OUTPUT_DSO |
PERF_OUTPUT_PERIOD | PERF_OUTPUT_ADDR |
- PERF_OUTPUT_DATA_SRC | PERF_OUTPUT_WEIGHT,
+ PERF_OUTPUT_DATA_SRC | PERF_OUTPUT_WEIGHT |
+ PERF_OUTPUT_PHYS_ADDR,
.invalid_fields = PERF_OUTPUT_TRACE | PERF_OUTPUT_BPF_OUTPUT,
},
@@ -382,6 +385,11 @@ static int perf_evsel__check_attr(struct perf_evsel *evsel,
PERF_OUTPUT_IREGS))
return -EINVAL;
+ if (PRINT_FIELD(PHYS_ADDR) &&
+ perf_evsel__check_stype(evsel, PERF_SAMPLE_PHYS_ADDR,
"PHYS_ADDR",
+ PERF_OUTPUT_PHYS_ADDR))
+ return -EINVAL;
+
return 0;
}
@@ -1446,6 +1454,9 @@ static void process_event(struct perf_script *script,
if (perf_evsel__is_bpf_output(evsel) && PRINT_FIELD(BPF_OUTPUT))
print_sample_bpf_output(sample);
print_insn(sample, attr, thread, machine);
+
+ if (PRINT_FIELD(PHYS_ADDR))
+ printf("%16" PRIx64, sample->phys_addr);
printf("\n");
}
@@ -2729,7 +2740,7 @@ int cmd_script(int argc, const char **argv)
"Valid types: hw,sw,trace,raw,synth. "
"Fields: comm,tid,pid,time,cpu,event,trace,ip,sym,dso,"
"addr,symoff,period,iregs,brstack,brstacksym,flags,"
-"bpf-output,callindent,insn,insnlen,brstackinsn,synth",
+
"bpf-output,callindent,insn,insnlen,brstackinsn,synth,phys_addr",
parse_output_fields),
OPT_BOOLEAN('a', "all-cpus", &system_wide,
"system-wide collection from all CPUs"),
[tip:perf/urgent] perf test: Add test case for PERF_SAMPLE_PHYS_ADDR
Commit-ID: fc33dccba39584e403436b9cda3edc9c34b62bce
Gitweb: http://git.kernel.org/tip/fc33dccba39584e403436b9cda3edc9c34b62bce
Author: Kan Liang
AuthorDate: Tue, 29 Aug 2017 13:11:12 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 Sep 2017 14:46:34 -0300
perf test: Add test case for PERF_SAMPLE_PHYS_ADDR
Extend sample-parsing test cases to support new sample type
PERF_SAMPLE_PHYS_ADDR.
Signed-off-by: Kan Liang
Tested-by: Jiri Olsa
Acked-by: Stephane Eranian
Cc: Andi Kleen
Cc: Madhavan Srinivasan
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1504026672-7304-6-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/sample-parsing.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/perf/tests/sample-parsing.c
b/tools/perf/tests/sample-parsing.c
index 6d028f4..c385848 100644
--- a/tools/perf/tests/sample-parsing.c
+++ b/tools/perf/tests/sample-parsing.c
@@ -141,6 +141,9 @@ static bool samples_same(const struct perf_sample *s1,
}
}
+ if (type & PERF_SAMPLE_PHYS_ADDR)
+ COMP(phys_addr);
+
return true;
}
@@ -206,6 +209,7 @@ static int do_test(u64 sample_type, u64 sample_regs, u64
read_format)
.mask = sample_regs,
.regs = regs,
},
+ .phys_addr = 113,
};
struct sample_read_value values[] = {{1, 5}, {9, 3}, {2, 7}, {6, 4},};
struct perf_sample sample_out;
@@ -305,7 +309,7 @@ int test__sample_parsing(struct test *test __maybe_unused,
int subtest __maybe_u
* were added. Please actually update the test rather than just change
* the condition below.
*/
- if (PERF_SAMPLE_MAX > PERF_SAMPLE_REGS_INTR << 1) {
+ if (PERF_SAMPLE_MAX > PERF_SAMPLE_PHYS_ADDR << 1) {
pr_debug("sample format has changed, some new PERF_SAMPLE_ bit
was introduced - test needs updating\n");
return -1;
}
[tip:perf/urgent] perf annotate browser: Help for cycling thru hottest instructions with TAB/shift+TAB
Commit-ID: eba9fac017617e685d648339e29a1453a30cb065 Gitweb: http://git.kernel.org/tip/eba9fac017617e685d648339e29a1453a30cb065 Author: Arnaldo Carvalho de Melo AuthorDate: Fri, 1 Sep 2017 14:55:40 -0300 Committer: Arnaldo Carvalho de Melo CommitDate: Fri, 1 Sep 2017 14:55:40 -0300 perf annotate browser: Help for cycling thru hottest instructions with TAB/shift+TAB The popup help accessed via 'h' wasn't mentioning about TAB and shift-TAB, just about 'H', which goes to the hottest line, while the former two are the hotkeys for actually cycling thru the hottest lines. Reported-by: Flavio Bruno Leitner Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Cc: Taeung Song Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-5ppym6odizfj1ifa4t7ne...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/ui/browsers/annotate.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/perf/ui/browsers/annotate.c b/tools/perf/ui/browsers/annotate.c index ba0aee5..786feca 100644 --- a/tools/perf/ui/browsers/annotate.c +++ b/tools/perf/ui/browsers/annotate.c @@ -829,7 +829,8 @@ static int annotate_browser__run(struct annotate_browser *browser, "q/ESC/CTRL+C Exit\n\n" "ENTER Go to target\n" "ESC Exit\n" - "H Cycle thru hottest instructions\n" + "H Go to hottest instruction\n" + "TAB/shift+TAB Cycle thru hottest instructions\n" "j Toggle showing jump to target arrows\n" "J Toggle showing number of jump sources on targets\n" "n Search next string\n"
[tip:perf/urgent] perf mem: Support physical address
Commit-ID: c35aeb9dfe512422ca9ea28aae692c8f1d052b2d
Gitweb: http://git.kernel.org/tip/c35aeb9dfe512422ca9ea28aae692c8f1d052b2d
Author: Kan Liang
AuthorDate: Tue, 29 Aug 2017 13:11:10 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 Sep 2017 14:46:23 -0300
perf mem: Support physical address
Add option phys-data in "perf mem" to record/report physical address.
The default mem sort order for physical address is changed accordingly.
Signed-off-by: Kan Liang
Tested-by: Jiri Olsa
Acked-by: Stephane Eranian
Cc: Andi Kleen
Cc: Madhavan Srinivasan
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1504026672-7304-4-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-mem.txt | 4 ++
tools/perf/builtin-mem.c | 97 +--
2 files changed, 75 insertions(+), 26 deletions(-)
diff --git a/tools/perf/Documentation/perf-mem.txt
b/tools/perf/Documentation/perf-mem.txt
index 7349632..4be08a1 100644
--- a/tools/perf/Documentation/perf-mem.txt
+++ b/tools/perf/Documentation/perf-mem.txt
@@ -59,6 +59,10 @@ OPTIONS
--ldload::
Specify desired latency for loads event.
+-p::
+--phys-data::
+ Record/Report sample physical addresses
+
SEE ALSO
linkperf:perf-record[1], linkperf:perf-report[1]
diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index e001c02..0f15634 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -23,6 +23,7 @@ struct perf_mem {
boolhide_unresolved;
booldump_raw;
boolforce;
+ boolphys_addr;
int operation;
const char *cpu_list;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
@@ -101,6 +102,9 @@ static int __cmd_record(int argc, const char **argv, struct
perf_mem *mem)
rec_argv[i++] = "-d";
+ if (mem->phys_addr)
+ rec_argv[i++] = "--phys-data";
+
for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
if (!perf_mem_events[j].record)
continue;
@@ -161,30 +165,60 @@ dump_raw_samples(struct perf_tool *tool,
if (al.map != NULL)
al.map->dso->hit = 1;
- if (symbol_conf.field_sep) {
- fmt = "%d%s%d%s0x%"PRIx64"%s0x%"PRIx64"%s%"PRIu64
- "%s0x%"PRIx64"%s%s:%s\n";
+ if (mem->phys_addr) {
+ if (symbol_conf.field_sep) {
+ fmt = "%d%s%d%s0x%"PRIx64"%s0x%"PRIx64"%s0x%016"PRIx64
+ "%s%"PRIu64"%s0x%"PRIx64"%s%s:%s\n";
+ } else {
+ fmt = "%5d%s%5d%s0x%016"PRIx64"%s0x016%"PRIx64
+ "%s0x%016"PRIx64"%s%5"PRIu64"%s0x%06"PRIx64
+ "%s%s:%s\n";
+ symbol_conf.field_sep = " ";
+ }
+
+ printf(fmt,
+ sample->pid,
+ symbol_conf.field_sep,
+ sample->tid,
+ symbol_conf.field_sep,
+ sample->ip,
+ symbol_conf.field_sep,
+ sample->addr,
+ symbol_conf.field_sep,
+ sample->phys_addr,
+ symbol_conf.field_sep,
+ sample->weight,
+ symbol_conf.field_sep,
+ sample->data_src,
+ symbol_conf.field_sep,
+ al.map ? (al.map->dso ? al.map->dso->long_name : "???")
: "???",
+ al.sym ? al.sym->name : "???");
} else {
- fmt = "%5d%s%5d%s0x%016"PRIx64"%s0x016%"PRIx64
- "%s%5"PRIu64"%s0x%06"PRIx64"%s%s:%s\n";
- symbol_conf.field_sep = " ";
- }
+ if (symbol_conf.field_sep) {
+ fmt = "%d%s%d%s0x%"PRIx64"%s0x%"PRIx64"%s%"PRIu64
+ "%s0x%"PRIx64"%s%s:%s\n";
+ } else {
+ fmt = "%5d%s%5d%s0x%016"PRIx64"%s0x016%"PRIx64
+ "%s%5"PRIu64"%s0x%06"PRIx64"%s%s:%s\n";
+ symbol_conf.field_sep = " ";
+ }
- printf(fmt,
- sample->pid,
- symbol_conf.field_sep,
- sample->tid,
- symbol_conf.field_sep,
- sample->ip,
- symbol_conf.field_sep,
- sample->addr,
- symbol_conf.field_sep,
- sample->weight,
- symbol_conf.field_sep,
- sample->data_src,
- symbol_conf.field_sep,
- al.map ? (al.map->dso ? al.map->dso->long_name : "???") : "???",
- al.sym ? al.sym->name : "???");
+ printf(fmt,
+
[tip:perf/urgent] perf sort: Add sort option for physical address
Commit-ID: 8780fb25ab060bafa5a8149e79b703e0fc7ee847
Gitweb: http://git.kernel.org/tip/8780fb25ab060bafa5a8149e79b703e0fc7ee847
Author: Kan Liang
AuthorDate: Tue, 29 Aug 2017 13:11:09 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 Sep 2017 14:46:11 -0300
perf sort: Add sort option for physical address
Add a new sort option "phys_daddr" for --mem-mode sort. With this
option applied, perf can sort and report by sample's physical address.
Signed-off-by: Kan Liang
Tested-by: Jiri Olsa
Acked-by: Stephane Eranian
Cc: Andi Kleen
Cc: Madhavan Srinivasan
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1504026672-7304-3-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-report.txt | 1 +
tools/perf/util/hist.c | 4 +++
tools/perf/util/hist.h | 1 +
tools/perf/util/machine.c| 8 --
tools/perf/util/session.c| 3 +++
tools/perf/util/sort.c | 42
tools/perf/util/sort.h | 1 +
tools/perf/util/symbol.h | 1 +
8 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 9fa8461..383a98d 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -137,6 +137,7 @@ OPTIONS
- mem: type of memory access for the data at the time of the sample
- snoop: type of snoop (if any) for the data at the time of the sample
- dcacheline: the cacheline the data address is on at the time of the
sample
+ - phys_daddr: physical address of data being executed on at the time of
sample
And the default sort keys are changed to local_weight, mem, sym, dso,
symbol_daddr, dso_daddr, snoop, tlb, locked, see '--mem-mode'.
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 9453b2e..e60d8d8 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -167,6 +167,10 @@ void hists__calc_col_len(struct hists *hists, struct
hist_entry *h)
symlen = unresolved_col_width + 4 + 2;
hists__set_unres_dso_col_len(hists,
HISTC_MEM_DADDR_DSO);
}
+
+ hists__new_col_len(hists, HISTC_MEM_PHYS_DADDR,
+ unresolved_col_width + 4 + 2);
+
} else {
symlen = unresolved_col_width + 4 + 2;
hists__new_col_len(hists, HISTC_MEM_DADDR_SYMBOL, symlen);
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index ee3670a..e60dda2 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -47,6 +47,7 @@ enum hist_column {
HISTC_GLOBAL_WEIGHT,
HISTC_MEM_DADDR_SYMBOL,
HISTC_MEM_DADDR_DSO,
+ HISTC_MEM_PHYS_DADDR,
HISTC_MEM_LOCKED,
HISTC_MEM_TLB,
HISTC_MEM_LVL,
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 9eaa953..df70936 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1635,10 +1635,12 @@ static void ip__resolve_ams(struct thread *thread,
ams->al_addr = al.addr;
ams->sym = al.sym;
ams->map = al.map;
+ ams->phys_addr = 0;
}
static void ip__resolve_data(struct thread *thread,
-u8 m, struct addr_map_symbol *ams, u64 addr)
+u8 m, struct addr_map_symbol *ams,
+u64 addr, u64 phys_addr)
{
struct addr_location al;
@@ -1658,6 +1660,7 @@ static void ip__resolve_data(struct thread *thread,
ams->al_addr = al.addr;
ams->sym = al.sym;
ams->map = al.map;
+ ams->phys_addr = phys_addr;
}
struct mem_info *sample__resolve_mem(struct perf_sample *sample,
@@ -1669,7 +1672,8 @@ struct mem_info *sample__resolve_mem(struct perf_sample
*sample,
return NULL;
ip__resolve_ams(al->thread, &mi->iaddr, sample->ip);
- ip__resolve_data(al->thread, al->cpumode, &mi->daddr, sample->addr);
+ ip__resolve_data(al->thread, al->cpumode, &mi->daddr,
+sample->addr, sample->phys_addr);
mi->data_src.val = sample->data_src;
return mi;
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index ac86369..a7ebd9f 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1120,6 +1120,9 @@ static void dump_sample(struct perf_evsel *evsel, union
perf_event *event,
if (sample_type & PERF_SAMPLE_DATA_SRC)
printf(" . data_src: 0x%"PRIx64"\n", sample->data_src);
+ if (sample_type & PERF_SAMPLE_PHYS_ADDR)
+ printf(" .. phys_addr: 0x%"PRIx64"\n", sample->phys_addr);
+
if (sample_type & PERF_SAMPLE_TRANSACTION)
printf("... transaction: %" PRIx64 "\n", sa
[tip:perf/urgent] perf tools: Support new sample type for physical address
Commit-ID: 3b0a5daa061076b2b75ffc294e74483ad9bf241a
Gitweb: http://git.kernel.org/tip/3b0a5daa061076b2b75ffc294e74483ad9bf241a
Author: Kan Liang
AuthorDate: Tue, 29 Aug 2017 13:11:08 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 Sep 2017 14:46:00 -0300
perf tools: Support new sample type for physical address
Support new sample type PERF_SAMPLE_PHYS_ADDR for physical address.
Add new option --phys-data to record sample physical address.
Signed-off-by: Kan Liang
Tested-by: Jiri Olsa
Acked-by: Stephane Eranian
Cc: Andi Kleen
Cc: Madhavan Srinivasan
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1504026672-7304-2-git-send-email-kan.li...@intel.com
[ Added missing printing in evsel.c patch sent by Jiri Olsa ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/include/uapi/linux/perf_event.h| 4 +++-
tools/perf/Documentation/perf-record.txt | 5 -
tools/perf/builtin-record.c | 2 ++
tools/perf/perf.h| 1 +
tools/perf/util/event.h | 1 +
tools/perf/util/evsel.c | 19 ++-
6 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/tools/include/uapi/linux/perf_event.h
b/tools/include/uapi/linux/perf_event.h
index 2a37ae9..140ae63 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -139,8 +139,9 @@ enum perf_event_sample_format {
PERF_SAMPLE_IDENTIFIER = 1U << 16,
PERF_SAMPLE_TRANSACTION = 1U << 17,
PERF_SAMPLE_REGS_INTR = 1U << 18,
+ PERF_SAMPLE_PHYS_ADDR = 1U << 19,
- PERF_SAMPLE_MAX = 1U << 19, /* non-ABI */
+ PERF_SAMPLE_MAX = 1U << 20, /* non-ABI */
};
/*
@@ -814,6 +815,7 @@ enum perf_event_type {
* { u64 transaction; } &&
PERF_SAMPLE_TRANSACTION
* { u64 abi; # enum perf_sample_regs_abi
*u64 regs[weight(mask)]; } &&
PERF_SAMPLE_REGS_INTR
+* { u64 phys_addr;} && PERF_SAMPLE_PHYS_ADDR
* };
*/
PERF_RECORD_SAMPLE = 9,
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 9bdea04..e397453 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -249,7 +249,10 @@ OPTIONS
-d::
--data::
- Record the sample addresses.
+ Record the sample virtual addresses.
+
+--phys-data::
+ Record the sample physical addresses.
-T::
--timestamp::
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 36d7117..56f8142 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1604,6 +1604,8 @@ static struct option __record_options[] = {
OPT_BOOLEAN('s', "stat", &record.opts.inherit_stat,
"per thread counts"),
OPT_BOOLEAN('d', "data", &record.opts.sample_address, "Record the
sample addresses"),
+ OPT_BOOLEAN(0, "phys-data", &record.opts.sample_phys_addr,
+ "Record the sample physical addresses"),
OPT_BOOLEAN(0, "sample-cpu", &record.opts.sample_cpu, "Record the
sample cpu"),
OPT_BOOLEAN_SET('T', "timestamp", &record.opts.sample_time,
&record.opts.sample_time_set,
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 2c010dd..dc442ba 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -43,6 +43,7 @@ struct record_opts {
bool no_samples;
bool raw_samples;
bool sample_address;
+ bool sample_phys_addr;
bool sample_weight;
bool sample_time;
bool sample_time_set;
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 423ac82..ee7bcc8 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -200,6 +200,7 @@ struct perf_sample {
u32 cpu;
u32 raw_size;
u64 data_src;
+ u64 phys_addr;
u32 flags;
u16 insn_len;
u8 cpumode;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index d9bd632..4bb8937 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -955,6 +955,9 @@ void perf_evsel__config(struct perf_evsel *evsel, struct
record_opts *opts,
if (opts->sample_address)
perf_evsel__set_sample_bit(evsel, DATA_SRC);
+ if (opts->sample_phys_addr)
+ perf_evsel__set_sample_bit(evsel, PHYS_ADDR);
+
if (opts->no_buffering) {
attr->watermark = 0;
attr->wakeup_events = 1;
@@ -1464,7 +1467,7 @@ static void __p_sample_type(char *buf, size_t size, u64
value)
bit_name(PERIOD), bit_name(STREAM_ID), bit_name(RAW),
bit_name(BRANCH_STACK), bit
[tip:perf/urgent] perf vendor events powerpc: Remove duplicate events
Commit-ID: 2a118e1bd22cad57318520d37e3a184b8846c6a2
Gitweb: http://git.kernel.org/tip/2a118e1bd22cad57318520d37e3a184b8846c6a2
Author: Sukadev Bhattiprolu
AuthorDate: Wed, 30 Aug 2017 21:42:23 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 Sep 2017 14:46:00 -0300
perf vendor events powerpc: Remove duplicate events
Some POWER PMU event names have multiple/alternate event codes. These
alternate event codes were listed in the POWER9 JSON files for
reference.
But the perf tool does not seem to handle duplicates cleanly. 'perf
list' shows such duplicate events only once, but 'perf stat' ends up
counting the first event code twice, multiplexing if necessary and we
end up with double the event counts.
Remove the duplicate event codes from the JSON files for now.
Reported-by: Michael Petlan
Signed-off-by: Sukadev Bhattiprolu
Cc: Andi Kleen
Cc: Anton Blanchard
Cc: Jiri Olsa
Cc: Michael Ellerman
Link: http://lkml.kernel.org/r/20170830231506.gb20...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
.../pmu-events/arch/powerpc/power9/frontend.json | 7 +-
.../perf/pmu-events/arch/powerpc/power9/other.json | 120 -
.../pmu-events/arch/powerpc/power9/pipeline.json | 7 +-
tools/perf/pmu-events/arch/powerpc/power9/pmc.json | 7 +-
4 files changed, 3 insertions(+), 138 deletions(-)
diff --git a/tools/perf/pmu-events/arch/powerpc/power9/frontend.json
b/tools/perf/pmu-events/arch/powerpc/power9/frontend.json
index 7e62c46..c63a919 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/frontend.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/frontend.json
@@ -80,11 +80,6 @@
"BriefDescription": "Load Missed L1, counted at execution time (can be
greater than loads finished). LMQ merges are not included in this count. i.e.
if a load instruction misses on an address that is already allocated on the
LMQ, this event will not increment for that load). Note that this count is per
slice, so if a load spans multiple slices this event will increment multiple
times for a single load."
},
{,
-"EventCode": "0x400F0",
-"EventName": "PM_LD_MISS_L1",
-"BriefDescription": "Load Missed L1, counted at execution time (can be
greater than loads finished). LMQ merges are not included in this count. i.e.
if a load instruction misses on an address that is already allocated on the
LMQ, this event will not increment for that load). Note that this count is per
slice, so if a load spans multiple slices this event will increment multiple
times for a single load."
- },
- {,
"EventCode": "0x2E01A",
"EventName": "PM_CMPLU_STALL_LSU_FLUSH_NEXT",
"BriefDescription": "Completion stall of one cycle because the LSU
requested to flush the next iop in the sequence. It takes 1 cycle for the ISU
to process this request before the LSU instruction is allowed to complete"
@@ -374,4 +369,4 @@
"EventName": "PM_IPTEG_FROM_L31_ECO_MOD",
"BriefDescription": "A Page Table Entry was loaded into the TLB with
Modified (M) data from another core's ECO L3 on the same chip due to a
instruction side request"
}
-]
\ No newline at end of file
+]
diff --git a/tools/perf/pmu-events/arch/powerpc/power9/other.json
b/tools/perf/pmu-events/arch/powerpc/power9/other.json
index 00f3d2a..54cc3be 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/other.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/other.json
@@ -605,11 +605,6 @@
"BriefDescription": "RC retries on PB for any load from core (excludes
DCBFs)"
},
{,
-"EventCode": "0x3689E",
-"EventName": "PM_L2_RTY_LD",
-"BriefDescription": "RC retries on PB for any load from core (excludes
DCBFs)"
- },
- {,
"EventCode": "0xE08C",
"EventName": "PM_LSU0_ERAT_HIT",
"BriefDescription": "Primary ERAT hit. There is no secondary ERAT"
@@ -715,11 +710,6 @@
"BriefDescription": "Lifetime, sample of RD machine 0 valid"
},
{,
-"EventCode": "0x468B4",
-"EventName": "PM_L3_RD0_BUSY",
-"BriefDescription": "Lifetime, sample of RD machine 0 valid"
- },
- {,
"EventCode": "0x46080",
"EventName": "PM_L2_DISP_ALL_L2MISS",
"BriefDescription": "All successful Ld/St dispatches for this thread that
were an L2 miss (excludes i_l2mru_tch_reqs)"
@@ -850,21 +840,11 @@
"BriefDescription": "RC mach 0 Busy. Used by PMU to sample ave RC lifetime
(mach0 used as sample point)"
},
{,
-"EventCode": "0x2608C",
-"EventName": "PM_RC0_BUSY",
-"BriefDescription": "RC mach 0 Busy. Used by PMU to sample ave RC lifetime
(mach0 used as sample point)"
- },
- {,
"EventCode": "0x36082",
"EventName": "PM_L2_LD_DISP",
"BriefDescription": "All successful I-or-D side load dispatches for this
thread (excludes i_l2mru_tch_reqs)."
},
{,
-"EventCode": "0x1609E",
-"EventName": "PM_L2_LD_DISP",
-"BriefDescription": "All successful D side load dispatches for this thread
(L2 miss + L2 hits)"
- },
- {,
[tip:perf/urgent] perf test powerpc: Fix 'Object code reading' test
Commit-ID: 9a805d8648ee09c136130fe4114a09574bc0b1ef
Gitweb: http://git.kernel.org/tip/9a805d8648ee09c136130fe4114a09574bc0b1ef
Author: Ravi Bangoria
AuthorDate: Thu, 31 Aug 2017 14:44:56 +0530
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 Sep 2017 14:45:59 -0300
perf test powerpc: Fix 'Object code reading' test
'Object code reading' test always fails on powerpc guest. Two reasons
for the failure are:
1. When elf section is too big (size beyond 'unsigned int' max value).
objdump fails to disassemble from such section. This was fixed with
commit 0f6329bd7fc ("binutils/objdump: Fix disassemble for huge elf
sections") in binutils.
2. When the sample is from hypervisor. Hypervisor symbols can not be
resolved within guest and thus thread__find_addr_map() fails for such
symbols. Fix this by ignoring hypervisor symbols in the test.
Signed-off-by: Ravi Bangoria
Acked-by: Adrian Hunter
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Michael Ellerman
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: linuxppc-...@lists.ozlabs.org
Link:
http://lkml.kernel.org/r/1504170896-7876-1-git-send-email-ravi.bango...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/code-reading.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index 761c5a4..466a462 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -237,6 +237,11 @@ static int read_object_code(u64 addr, size_t len, u8
cpumode,
thread__find_addr_map(thread, cpumode, MAP__FUNCTION, addr, &al);
if (!al.map || !al.map->dso) {
+ if (cpumode == PERF_RECORD_MISC_HYPERVISOR) {
+ pr_debug("Hypervisor address can not be resolved -
skipping\n");
+ return 0;
+ }
+
pr_debug("thread__find_addr_map failed\n");
return -1;
}
[tip:perf/urgent] perf report: Calculate the average cycles of iterations
Commit-ID: c4ee06251d4212a0d55e2371f2db464f6a1e0901
Gitweb: http://git.kernel.org/tip/c4ee06251d4212a0d55e2371f2db464f6a1e0901
Author: Jin Yao
AuthorDate: Mon, 7 Aug 2017 21:05:15 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 30 Aug 2017 10:03:27 -0300
perf report: Calculate the average cycles of iterations
The branch history code has a loop detection function. With this, we can
get the number of iterations by calculating the removed loops.
While it would be nice for knowing the average cycles of iterations.
This patch adds up the cycles in branch entries of removed loops and
save the result to the next branch entry (e.g. branch entry A).
Finally it will display the iteration number and average cycles at the
"from" of branch entry A.
For example:
perf record -g -j any,save_type ./div
perf report --branch-history --no-children --stdio
--22.63%--main div.c:42 (RET CROSS_2M)
compute_flag div.c:28 (cycles:2 iter:173115 avg_cycles:2)
|
--10.73%--compute_flag div.c:27 (RET CROSS_2M)
rand rand.c:28 (cycles:1)
rand rand.c:28 (RET CROSS_2M)
__random random.c:298 (cycles:1)
__random random.c:297 (COND_BWD CROSS_2M)
__random random.c:295 (cycles:1)
__random random.c:295 (COND_BWD CROSS_2M)
__random random.c:295 (cycles:1)
__random random.c:295 (RET CROSS_2M)
Signed-off-by: Yao Jin
Reviewed-by: Andi Kleen
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Kan Liang
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/150215-18305-1-git-send-email-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 8 +---
tools/perf/ui/stdio/hist.c | 10 ++---
tools/perf/util/callchain.c| 49 +++
tools/perf/util/callchain.h| 9 ++---
tools/perf/util/machine.c | 88 +-
5 files changed, 85 insertions(+), 79 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index f4bc246..13dfb0a 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -931,12 +931,8 @@ static int hist_browser__show_callchain_list(struct
hist_browser *browser,
browser->show_dso);
if (symbol_conf.show_branchflag_count) {
- if (need_percent)
- callchain_list_counts__printf_value(node, chain, NULL,
- buf, sizeof(buf));
- else
- callchain_list_counts__printf_value(NULL, chain, NULL,
- buf, sizeof(buf));
+ callchain_list_counts__printf_value(chain, NULL,
+ buf, sizeof(buf));
if (asprintf(&alloc_str2, "%s%s", str, buf) < 0)
str = "Not enough memory!";
diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index 5c95b83..8bdb7a5 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -124,12 +124,8 @@ static size_t ipchain__fprintf_graph(FILE *fp, struct
callchain_node *node,
str = callchain_list__sym_name(chain, bf, sizeof(bf), false);
if (symbol_conf.show_branchflag_count) {
- if (!period)
- callchain_list_counts__printf_value(node, chain, NULL,
- buf, sizeof(buf));
- else
- callchain_list_counts__printf_value(NULL, chain, NULL,
- buf, sizeof(buf));
+ callchain_list_counts__printf_value(chain, NULL,
+ buf, sizeof(buf));
if (asprintf(&alloc_str, "%s%s", str, buf) < 0)
str = "Not enough memory!";
@@ -313,7 +309,7 @@ static size_t callchain__fprintf_graph(FILE *fp, struct
rb_root *root,
if (symbol_conf.show_branchflag_count)
ret += callchain_list_counts__printf_value(
- NULL, chain, fp, NULL, 0);
+ chain, fp, NULL, 0);
ret += fprintf(fp, "\n");
if (++entries_printed == callchain_param.print_limit)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index f320b07..510b513 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -588,7 +588,7 @@ fill_node(struct callchain_node *node, struct
callchain_cursor *cursor)
call->cycles_count =
cursor_node->branch_flags.cycles;
[tip:perf/urgent] perf trace: Support syscall name globbing
Commit-ID: 27702bcfe8a125a1feeeb5f07526d63b20cac47f
Gitweb: http://git.kernel.org/tip/27702bcfe8a125a1feeeb5f07526d63b20cac47f
Author: Arnaldo Carvalho de Melo
AuthorDate: Thu, 31 Aug 2017 11:50:04 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 Sep 2017 14:45:58 -0300
perf trace: Support syscall name globbing
So now we can use:
# perf trace -e pkey_*
532.784 ( 0.006 ms): pkey/16018 pkey_alloc(init_val: DISABLE_WRITE) = -1
EINVAL Invalid argument
532.795 ( 0.004 ms): pkey/16018 pkey_mprotect(start: 0x7f380d0a6000, len:
4096, prot: READ|WRITE, pkey: -1) = 0
532.801 ( 0.002 ms): pkey/16018 pkey_free(pkey: -1) = -1
EINVAL Invalid argument
^C[root@jouet ~]#
Or '-e epoll*', '-e *msg*', etc.
Combining syscall names with perf events, tracepoints, etc, continues to
be valid, i.e. this is possible:
# perf probe -L sys_nanosleep
0 SYSCALL_DEFINE2(nanosleep, struct timespec __user *, rqtp,
struct timespec __user *, rmtp)
{
struct timespec64 tu;
5 if (get_timespec64(&tu, rqtp))
6 return -EFAULT;
if (!timespec64_valid(&tu))
9 return -EINVAL;
11 current->restart_block.nanosleep.type = rmtp ? TT_NATIVE :
TT_NONE;
12 current->restart_block.nanosleep.rmtp = rmtp;
13 return hrtimer_nanosleep(&tu, HRTIMER_MODE_REL,
CLOCK_MONOTONIC);
}
# perf probe my_probe="sys_nanosleep:12 rmtp"
Added new event:
probe:my_probe (on sys_nanosleep:12 with rmtp)
You can now use it in all perf tools, such as:
perf record -e probe:my_probe -aR sleep 1
#
# perf trace -e probe:my_probe/max-stack=5/,*sleep sleep 1
0.427 ( 0.003 ms): sleep/16690 nanosleep(rqtp: 0x7ffefc245090) ...
0.430 ( ): probe:my_probe:(bd112923) rmtp=0)
sys_nanosleep ([kernel.kallsyms])
do_syscall_64 ([kernel.kallsyms])
return_from_SYSCALL_64
([kernel.kallsyms])
__nanosleep_nocancel
(/usr/lib64/libc-2.25.so)
0.427 (1000.208 ms): sleep/16690 ... [continued]: nanosleep()) = 0
#
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-elycoi8wy6y0w9dkj7ox1...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-trace.txt | 2 +-
tools/perf/builtin-trace.c | 39 +
2 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/tools/perf/Documentation/perf-trace.txt
b/tools/perf/Documentation/perf-trace.txt
index c1e3288..d53bea6 100644
--- a/tools/perf/Documentation/perf-trace.txt
+++ b/tools/perf/Documentation/perf-trace.txt
@@ -37,7 +37,7 @@ OPTIONS
--expr::
--event::
List of syscalls and other perf events (tracepoints, HW cache events,
- etc) to show.
+ etc) to show. Globbing is supported, e.g.: "epoll_*", "*msg*", etc.
See 'perf list' for a complete list of events.
Prefixing with ! shows all syscalls but the ones specified. You may
need to escape it.
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index d59cdad..771ddab 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1261,6 +1261,7 @@ static int trace__read_syscall_info(struct trace *trace,
int id)
static int trace__validate_ev_qualifier(struct trace *trace)
{
int err = 0, i;
+ size_t nr_allocated;
struct str_node *pos;
trace->ev_qualifier_ids.nr = strlist__nr_entries(trace->ev_qualifier);
@@ -1274,13 +1275,18 @@ static int trace__validate_ev_qualifier(struct trace
*trace)
goto out;
}
+ nr_allocated = trace->ev_qualifier_ids.nr;
i = 0;
strlist__for_each_entry(pos, trace->ev_qualifier) {
const char *sc = pos->s;
- int id = syscalltbl__id(trace->sctbl, sc);
+ int id = syscalltbl__id(trace->sctbl, sc), match_next = -1;
if (id < 0) {
+ id = syscalltbl__strglobmatch_first(trace->sctbl, sc,
&match_next);
+ if (id >= 0)
+ goto matches;
+
if (err == 0) {
fputs("Error:\tInvalid syscall ",
trace->output);
err = -EINVAL;
@@ -1290,13 +1296,37 @@ static int trace__validate_ev_qualifier(struct trace
*trace)
fputs(sc, trace->output);
}
-
+matches:
trace->ev_qualifier_ids.entries[i++] = id;
+ if (match_next == -1)
+ continue;
+
+ while (1) {
+ id = syscalltbl__strglobmatch_next(trace->sctbl, sc,
&match_next);
+
[tip:perf/urgent] perf syscalltbl: Support glob matching on syscall names
Commit-ID: 89be3f8ab701180fc0329eff1b076528d64ac56b
Gitweb: http://git.kernel.org/tip/89be3f8ab701180fc0329eff1b076528d64ac56b
Author: Arnaldo Carvalho de Melo
AuthorDate: Thu, 31 Aug 2017 11:46:49 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 Sep 2017 14:45:48 -0300
perf syscalltbl: Support glob matching on syscall names
With two new methods, one to find the first match, returning its syscall
id and its index in whatever internal database it keeps the syscall
into, then one to find the next match, if any.
Implemented only on arches where we actually read the syscall table from
the kernel sources, i.e. x86-64 for now, all the others use the libaudit
method for which this returns -1, i.e. just stubs were added, with the
actual implementation using whatever libaudit functions for matching
that may be available.
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-i0sj4rxk1a63pfe9gl8z8...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/syscalltbl.c | 33 +
tools/perf/util/syscalltbl.h | 3 +++
2 files changed, 36 insertions(+)
diff --git a/tools/perf/util/syscalltbl.c b/tools/perf/util/syscalltbl.c
index bbb4c19..19e5db9 100644
--- a/tools/perf/util/syscalltbl.c
+++ b/tools/perf/util/syscalltbl.c
@@ -19,6 +19,7 @@
#ifdef HAVE_SYSCALL_TABLE
#include
#include
+#include "string2.h"
#include "util.h"
#if defined(__x86_64__)
@@ -105,6 +106,27 @@ int syscalltbl__id(struct syscalltbl *tbl, const char
*name)
return sc ? sc->id : -1;
}
+int syscalltbl__strglobmatch_next(struct syscalltbl *tbl, const char
*syscall_glob, int *idx)
+{
+ int i;
+ struct syscall *syscalls = tbl->syscalls.entries;
+
+ for (i = *idx + 1; i < tbl->syscalls.nr_entries; ++i) {
+ if (strglobmatch(syscalls[i].name, syscall_glob)) {
+ *idx = i;
+ return syscalls[i].id;
+ }
+ }
+
+ return -1;
+}
+
+int syscalltbl__strglobmatch_first(struct syscalltbl *tbl, const char
*syscall_glob, int *idx)
+{
+ *idx = -1;
+ return syscalltbl__strglobmatch_next(tbl, syscall_glob, idx);
+}
+
#else /* HAVE_SYSCALL_TABLE */
#include
@@ -131,4 +153,15 @@ int syscalltbl__id(struct syscalltbl *tbl, const char
*name)
{
return audit_name_to_syscall(name, tbl->audit_machine);
}
+
+int syscalltbl__strglobmatch_next(struct syscalltbl *tbl __maybe_unused,
+ const char *syscall_glob __maybe_unused, int
*idx __maybe_unused)
+{
+ return -1;
+}
+
+int syscalltbl__strglobmatch_first(struct syscalltbl *tbl, const char
*syscall_glob, int *idx)
+{
+ return syscalltbl__strglobmatch_next(tbl, syscall_glob, idx);
+}
#endif /* HAVE_SYSCALL_TABLE */
diff --git a/tools/perf/util/syscalltbl.h b/tools/perf/util/syscalltbl.h
index e295151..e9fb878 100644
--- a/tools/perf/util/syscalltbl.h
+++ b/tools/perf/util/syscalltbl.h
@@ -17,4 +17,7 @@ void syscalltbl__delete(struct syscalltbl *tbl);
const char *syscalltbl__name(const struct syscalltbl *tbl, int id);
int syscalltbl__id(struct syscalltbl *tbl, const char *name);
+int syscalltbl__strglobmatch_first(struct syscalltbl *tbl, const char
*syscall_glob, int *idx);
+int syscalltbl__strglobmatch_next(struct syscalltbl *tbl, const char
*syscall_glob, int *idx);
+
#endif /* __PERF_SYSCALLTBL_H */
Re: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to system freq
On Sun, Sep 03, 2017 at 04:40:21PM +0200, Łukasz Majewski wrote:
> >/*
> >* Hardware limitation: The bclk rate must be
> >* never greater than 1/5 IPG clock rate
> >*/
> >if (freq * 5 > clk_get_rate(ssi_private->clk)) {
> >dev_err(cpu_dai->dev, "bitclk > ipgclk/5\n");
> >return -EINVAL;
> >}
> >
>
> Unfortunately not.
>
> This is the part of fsl_ssi_set_bclk() function which is called after
> fsl_ssi_set_dai_sysclk() (which sets ssi_private->bitclk_freq = freq;).
>
> Before the aforementioned check we do have:
>
> if (ssi_private->bitclk_freq)
> freq = ssi_private->bitclk_freq;
> else
> freq = params_channels(hw_params) * 32 *
> params_rate(hw_params);
>
>
> Which assigns freq = bitclk_freq (66 MHz)
>
[...]
> And then we break on this particular check:
> 66MHz * 5 > 66 MHz.
[...]
Does the check fail and return an error here, or not?
> The culprit IMHO is the ssi_private->bitclk_freq = freq; in the
> fsl_ssi_set_dai_sysclk(), since we _should_ set SSI's IP block clock
> (ssi_private->clk), not the bit clock (BCLK).
No. We should not set the IP block clock. That's from IPG bus
on certain IMX SoCs. Setting it might change IPG bus clocks
which might break the system.
And apparently, we shouldn't set bitclk to 66MHz either. Can
you help to find where this 66MHz comes from?
> This patch just quits early if it detects change, which don't need to be
> done.
I kinda see your point is to error out before hw_params(). So
I feel it would be better to have a similar 5-times-check in
the set_sysclk() too, if it's really necessary.
Btw, I don't see simple card calling set_sysclk() function in
any earlier stage than hw_params(). I am wondering how did you
encounter the problem?
Thanks
Nicolin
Re: [GIT PULL 00/13] perf/core improvements and fixes
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit 1b2f76d77a277bb70d38ad0991ed7f16bbc115a9: > > Merge tag 'perf-core-for-mingo-4.14-20170829' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > (2017-08-29 23:13:56 +0200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo-4.14-20170901 > > for you to fetch changes up to eba9fac017617e685d648339e29a1453a30cb065: > > perf annotate browser: Help for cycling thru hottest instructions with > TAB/shift+TAB (2017-09-01 14:55:40 -0300) > > > perf/core improvements and fixes: > > - Support syscall name glob matching in 'perf trace' (Arnaldo Carvalho de > Melo) > > e.g.: > ># perf trace -e pkey_* >32.784 (0.006 ms): pkey/16018 pkey_alloc(init_val: DISABLE_WRITE) = -1 > EINVAL Invalid argument >32.795 (0.004 ms): pkey/16018 pkey_mprotect(start: 0x7f380d0a6000, len: > 4096, prot: READ|WRITE, pkey: -1) = 0 >32.801 (0.002 ms): pkey/16018 pkey_free(pkey: -1) = -1 > EINVAL Invalid argument >^C# > > - Do not auto merge counts for explicitely specified events in > 'perf stat' (Arnaldo Carvalho de Melo) > > - Fix syntax in documentation of .perfconfig intel-pt option (Jack Henschel) > > - Calculate the average cycles of iterations for loops detected by the > branch history support in 'perf report' (Jin Yao) > > - Support PERF_SAMPLE_PHYS_ADDR as a sort key "phys_daddr" in the 'script', > 'mem', > 'top' and 'report'. Also add a test entry for it in 'perf test' (Kan Liang) > > - Fix 'Object code reading' 'perf test' entry in PowerPC (Ravi Bangoria) > > - Remove some duplicate Power9 duplicate vendor events (described in JSON > files) (Sukadev Bhattiprolu) > > - Add help entry in the TUI annotate browser about cycling thru hottest > instructions with TAB/shift+TAB (Arnaldo Carvalho de Melo) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (4): > perf syscalltbl: Support glob matching on syscall names > perf trace: Support syscall name globbing > perf stat: Only auto-merge events that are PMU aliases > perf annotate browser: Help for cycling thru hottest instructions with > TAB/shift+TAB > > Jack Henschel (1): > perf intel-pt: Fix syntax in documentation of config option > > Jin Yao (1): > perf report: Calculate the average cycles of iterations > > Kan Liang (5): > perf tools: Support new sample type for physical address > perf sort: Add sort option for physical address > perf mem: Support physical address > perf script: Support physical address > perf test: Add test case for PERF_SAMPLE_PHYS_ADDR > > Ravi Bangoria (1): > perf test powerpc: Fix 'Object code reading' test > > Sukadev Bhattiprolu (1): > perf vendor events powerpc: Remove duplicate events > > tools/include/uapi/linux/perf_event.h | 4 +- > tools/perf/Documentation/intel-pt.txt | 2 +- > tools/perf/Documentation/perf-mem.txt | 4 + > tools/perf/Documentation/perf-record.txt | 5 +- > tools/perf/Documentation/perf-report.txt | 1 + > tools/perf/Documentation/perf-script.txt | 2 +- > tools/perf/Documentation/perf-trace.txt| 2 +- > tools/perf/builtin-mem.c | 97 - > tools/perf/builtin-record.c| 2 + > tools/perf/builtin-script.c| 15 ++- > tools/perf/builtin-stat.c | 2 +- > tools/perf/builtin-trace.c | 39 ++- > tools/perf/perf.h | 1 + > .../pmu-events/arch/powerpc/power9/frontend.json | 7 +- > .../perf/pmu-events/arch/powerpc/power9/other.json | 120 > - > .../pmu-events/arch/powerpc/power9/pipeline.json | 7 +- > tools/perf/pmu-events/arch/powerpc/power9/pmc.json | 7 +- > tools/perf/tests/code-reading.c| 5 + > tools/perf/tests/sample-parsing.c | 6 +- > tools/perf/ui/browsers/annotate.c | 3 +- > tools/perf/ui/browsers/hists.c | 8 +- > tools/perf/ui/stdio/hist.c | 10 +- > tools/perf/util/callchain.c| 49 - > tools/perf/util/callchain.h| 9 +- > tools/perf/util/event.h| 1 + > tools/perf/util/evsel.c| 19 +++- > tools/perf/util/evsel.h| 1 + > tools/perf/util/hist.c
[PATCH linux-next v6 1/1] spi: imx: Add support for SPI Slave mode
Previously i.MX SPI controller only works in Master mode.
This patch adds support to i.MX51, i.MX53 and i.MX6 ECSPI
controller to work also in Slave mode.
Currently SPI Slave mode support patch has the following limitations:
1. The stale data in RXFIFO will be dropped when the Slave does any new
transfer.
2. One transfer can be finished only after all transfer->len data been
transferred to master device
3. Slave device only accepts transfer->len data. Any data longer than this
from master device will be dropped. Any data shorter than this from
master will cause SPI to stuck due to mentioned HW limitation 2.
4. Only PIO transfer is supported in Slave mode.
5. Dynamic burst size adjust isn't supported in Slave mode.
Following HW limitation applies:
1. ECSPI has a HW issue when works in Slave mode, after 64
words written to TXFIFO, even TXFIFO becomes empty,
ECSPI_TXDATA keeps shift out the last word data,
so we have to disable ECSPI when in slave mode after the
transfer completes
2. Due to Freescale errata ERR003775 "eCSPI: Burst completion by Chip
Select (SS) signal in Slave mode is not functional" burst size must
be set exactly to the size of the transfer. This limit SPI transaction
with maximum 2^12 bits. This errata affects i.MX53 and i.MX6 ECSPI
controllers.
Signed-off-by: Jiada Wang
---
Changes in v6:
* rebased to HEAD of linux-next tree
* avoid to enable dynamic burst adjust when in slave mode.
Changes in v5:
* rebased to HEAD of linux-next tree
Changes in v4:
* rebased to head of linux-next to resolve conflict
* optimized mx53_ecspi_rx_slave()
Changes in v3:
* renamed several variables for for better readability
* created spi_imx_pio_transfer_slave() for slave pio transfer
* added fifo_size, has_dmamode and has_slavemode in spi_imx_devtype_data
Changes in v2:
* re-workd i.MX ECSPI controller slave mode support based on Geert's work
drivers/spi/spi-imx.c | 227 +++---
1 file changed, 196 insertions(+), 31 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 6fcb6ad..401951c 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -53,10 +53,13 @@
/* generic defines to abstract from the different register layouts */
#define MXC_INT_RR (1 << 0) /* Receive data ready interrupt */
#define MXC_INT_TE (1 << 1) /* Transmit FIFO empty interrupt */
+#define MXC_INT_RDRBIT(4) /* Receive date threshold interrupt */
/* The maximum bytes that a sdma BD can transfer.*/
#define MAX_SDMA_BD_BYTES (1 << 15)
#define MX51_ECSPI_CTRL_MAX_BURST 512
+/* The maximum bytes that IMX53_ECSPI can transfer in slave mode.*/
+#define MX53_MAX_TRANSFER_BYTES512
enum spi_imx_devtype {
IMX1_CSPI,
@@ -76,7 +79,9 @@ struct spi_imx_devtype_data {
void (*trigger)(struct spi_imx_data *);
int (*rx_available)(struct spi_imx_data *);
void (*reset)(struct spi_imx_data *);
+ void (*disable)(struct spi_imx_data *);
bool has_dmamode;
+ bool has_slavemode;
unsigned int fifo_size;
bool dynamic_burst;
enum spi_imx_devtype devtype;
@@ -108,6 +113,11 @@ struct spi_imx_data {
unsigned int dynamic_burst, read_u32;
unsigned int word_mask;
+ /* Slave mode */
+ bool slave_mode;
+ bool slave_aborted;
+ unsigned int slave_burst;
+
/* DMA */
bool usedma;
u32 wml;
@@ -221,6 +231,9 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
if (!master->dma_rx)
return false;
+ if (spi_imx->slave_mode)
+ return false;
+
bytes_per_word = spi_imx_bytes_per_word(transfer->bits_per_word);
if (bytes_per_word != 1 && bytes_per_word != 2 && bytes_per_word != 4)
@@ -262,6 +275,7 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
#define MX51_ECSPI_INT 0x10
#define MX51_ECSPI_INT_TEEN(1 << 0)
#define MX51_ECSPI_INT_RREN(1 << 3)
+#define MX51_ECSPI_INT_RDREN (1 << 4)
#define MX51_ECSPI_DMA 0x14
#define MX51_ECSPI_DMA_TX_WML(wml) ((wml) & 0x3f)
@@ -378,6 +392,44 @@ static void spi_imx_buf_tx_swap(struct spi_imx_data
*spi_imx)
spi_imx_buf_tx_u16(spi_imx);
}
+static void mx53_ecspi_rx_slave(struct spi_imx_data *spi_imx)
+{
+ u32 val = be32_to_cpu(readl(spi_imx->base + MXC_CSPIRXDATA));
+
+ if (spi_imx->rx_buf) {
+ int n_bytes = spi_imx->slave_burst % sizeof(val);
+
+ if (!n_bytes)
+ n_bytes = sizeof(val);
+
+ memcpy(spi_imx->rx_buf,
+ ((u8 *)&val) + sizeof(val) - n_bytes, n_bytes);
+
+ spi_imx->rx_buf += n_bytes;
+ spi_imx->slave_burst -= n_bytes;
+ }
+}
+
+static void mx53_ecspi_tx_slave(struct spi_imx_data *spi_imx)
+{
+ u32
Re: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to system freq
On Sun, Sep 03, 2017 at 01:05:01PM +0200, Lukasz Majewski wrote:
> The problem is visible in the following setup (on the imx6q):
> "simple-audio-card" -> ssi2 -> I2S + I2C -> codec
>
> The function call log (simple-card probe -> CONFIG_SND_SIMPLE_CARD):
>
> asoc_simple_card_init_dai() @ sound/soc/generic/simple-card-utils.c
> snd_soc_dai_set_sysclk()
> fsl_ssi_set_dai_sysclk() @ sound/soc/fsl/fsl_ssi.c
>
> The last call is changing the bit clock (BCLK) frequency to SSI's IP
> block clock (ipg = 66 MHz) [1].
I think a bigger question here is why the routine sets BCLK to 66MHz.
> This is wrong, since IMX SSI block requires the I2S BCLK to be less
> than 1/5 of [1].
>
> As a result the driver initialization passes without any errors, but the
> speaker-test test case breaks.
>
> This commit checks if the fsl_ssi_set_dai_sysclk() frequency passed is
> not equal to [1].
I don't feel it's quite comprehensive...what if it's being set to 67MHz.
Thanks
Nicolin
> Signed-off-by: Lukasz Majewski
> ---
> sound/soc/fsl/fsl_ssi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index 173cb84..1186fa9 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -809,6 +809,8 @@ static int fsl_ssi_set_dai_sysclk(struct snd_soc_dai
> *cpu_dai,
> int clk_id, unsigned int freq, int dir)
> {
> struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
> + if (clk_get_rate(ssi_private->clk) == freq)
> + return 0;
>
> ssi_private->bitclk_freq = freq;
>
> --
> 2.1.4
>
Re: [RESENT PATCH v7 3/7] arm64: dts: rockchip: Update rt5514 devices' compatible for Gru
Hi Heiko, On 09/05/2017 06:33 AM, Heiko Stübner wrote: Am Donnerstag, 31. August 2017, 01:00:44 CEST schrieb jeffy: On 08/30/2017 09:30 PM, Heiko Stübner wrote: - compatible = "realtek,rt5514"; + compatible = "realtek,rt5514", "realtek,rt5514-i2c"; the rt5514-i2c and -spi compatibles should be documented in the binding-txt of the chip, but I haven't found any mention of this. Heiko these compatibles are only used for our snd driver to detect rt5514 i2c driver and rt5514 spi driver, suggested by Matthias at https://patchwork.kernel.org/patch/9904731/ should i add it in the rockchip,rk3399-gru-sound.txt or rt5514 binding document? You're introducing new bindings for the codec, so they should of course part of the rt5514 binding. ok, will do that. and it looks like there's no binding for rt5514-spi, will add it too :) Heiko
[PATCH v8 2/2] arm64: dts: rockchip: Update rt5514 devices' compatible for Gru
Currently the rt5514 i2c driver and rt5514 spi driver are using the same
compatible string.
Add additional unused compatible strings to identify them for Gru
boards.
Signed-off-by: Jeffy Chen
---
Changes in v8:
Add new compatible to rt5514 dt doc.
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 199a5118b20d..a86afbf09333 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -610,7 +610,7 @@ ap_i2c_mic: &i2c1 {
i2c-scl-rising-time-ns = <300>;
headsetcodec: rt5514@57 {
- compatible = "realtek,rt5514";
+ compatible = "realtek,rt5514", "realtek,rt5514-i2c";
reg = <0x57>;
realtek,dmic-init-delay-ms = <20>;
};
@@ -819,7 +819,7 @@ ap_i2c_audio: &i2c8 {
status = "okay";
wacky_spi_audio: spi2@0 {
- compatible = "realtek,rt5514";
+ compatible = "realtek,rt5514", "realtek,rt5514-spi";
reg = <0>;
interrupt-parent = <&gpio1>;
interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
--
2.11.0
[PATCH v8 1/2] ASoC: rt5514: Add devicetree bindings for rt5514-spi
Add devicetree bindings documentation file for rt5514 spi dsp codec.
Also update rt5514 i2c dt-binding's compatible.
Signed-off-by: Jeffy Chen
---
Changes in v8: None
.../devicetree/bindings/sound/rt5514-spi.txt | 32 ++
Documentation/devicetree/bindings/sound/rt5514.txt | 2 +-
2 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/sound/rt5514-spi.txt
diff --git a/Documentation/devicetree/bindings/sound/rt5514-spi.txt
b/Documentation/devicetree/bindings/sound/rt5514-spi.txt
new file mode 100644
index ..8a63d9423dd9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rt5514-spi.txt
@@ -0,0 +1,32 @@
+RT5514 SPI audio CODEC
+
+This device supports SPI only.
+
+Required properties:
+
+- compatible : "realtek,rt5514".
+
+- reg : The SPI address of the device.
+
+Optional properties:
+
+- interrupt-parent: Should be the phandle for the interrupt controller
+- interrupts: The interrupt number to the cpu. The interrupt specifier format
+ depends on the interrupt controller.
+
+Example:
+
+codec: rt5514-spi@0 {
+ compatible = "realtek,rt5514", "realtek,rt5514-spi";
+ reg = <0>;
+
+/* May run faster once verified. */
+spi-max-frequency = <1000>;
+
+pinctrl-names = "default";
+pinctrl-0 = <&mic_int>;
+
+interrupt-parent = <&gpio1>;
+interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
+wakeup-source;
+};
diff --git a/Documentation/devicetree/bindings/sound/rt5514.txt
b/Documentation/devicetree/bindings/sound/rt5514.txt
index 929ca6756b02..12a8c93a67cc 100644
--- a/Documentation/devicetree/bindings/sound/rt5514.txt
+++ b/Documentation/devicetree/bindings/sound/rt5514.txt
@@ -28,6 +28,6 @@ Pins on the device (for linking into audio routes) for RT5514:
Example:
codec: rt5514@57 {
- compatible = "realtek,rt5514";
+ compatible = "realtek,rt5514", "realtek,rt5514-i2c";
reg = <0x57>;
};
--
2.11.0
Re: [PATCH v2 2/2] dma: sprd: Add Spreadtrum DMA driver
On Tue, Aug 29, 2017 at 04:47:17PM +0800, Baolin Wang wrote:
> +config SPRD_DMA
> + bool "Spreadtrum DMA support"
> + depends on ARCH_SPRD
can you also add compile test to this, it helps in getting good coverage and
easy to compile changes
> +/* DMA global registers definition */
> +#define DMA_GLB_PAUSE0x0
> +#define DMA_GLB_FRAG_WAIT0x4
> +#define DMA_GLB_REQ_PEND0_EN 0x8
> +#define DMA_GLB_REQ_PEND1_EN 0xc
> +#define DMA_GLB_INT_RAW_STS 0x10
> +#define DMA_GLB_INT_MSK_STS 0x14
> +#define DMA_GLB_REQ_STS 0x18
> +#define DMA_GLB_CHN_EN_STS 0x1c
> +#define DMA_GLB_DEBUG_STS0x20
> +#define DMA_GLB_ARB_SEL_STS 0x24
> +#define DMA_GLB_CHN_START_CHN_CFG1 0x28
> +#define DMA_GLB_CHN_START_CHN_CFG2 0x2c
> +#define DMA_CHN_LLIST_OFFSET 0x10
> +#define DMA_GLB_REQ_CID_OFFSET 0x2000
> +#define DMA_GLB_REQ_CID(uid) (0x4 * ((uid) - 1))
namespaced properly please, here and rest..
> +static int sprd_dma_enable(struct sprd_dma_dev *sdev)
> +{
> + int ret;
> +
> + ret = clk_prepare_enable(sdev->clk);
> + if (ret)
> + return ret;
> +
> + if (!IS_ERR(sdev->ashb_clk))
that looks odd, can you explain this?
> +static void sprd_dma_set_uid(struct sprd_dma_chn *schan)
> +{
> + struct sprd_dma_dev *sdev = to_sprd_dma_dev(&schan->vc.chan);
> + u32 dev_id = schan->dev_id;
> +
> + if (dev_id != DMA_SOFTWARE_UID) {
> + unsigned long uid_offset = DMA_GLB_REQ_CID_OFFSET +
> + DMA_GLB_REQ_CID(dev_id);
right justified pls
> +static void sprd_dma_enable_chn(struct sprd_dma_chn *schan)
> +{
> + u32 cfg = readl(schan->chn_base + DMA_CHN_CFG);
> +
> + cfg |= DMA_CHN_EN;
> + writel(cfg, schan->chn_base + DMA_CHN_CFG);
how about add a sprd_updatel() helper which does read modify and update for
you. This way you can save quite a bit of code above...
> +static enum dma_int_type sprd_dma_get_int_type(struct sprd_dma_chn *schan)
> +{
> + u32 intc_sts = readl(schan->chn_base + DMA_CHN_INTC) & DMA_CHN_INT_STS;
> +
> + switch (intc_sts) {
> + case CFGERR_INT_STS:
> + return CONFIG_ERR;
empty line after each return pls
> +static void sprd_dma_free_chan_resources(struct dma_chan *chan)
> +{
> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&schan->vc.lock, flags);
> + sprd_dma_stop(schan);
> + spin_unlock_irqrestore(&schan->vc.lock, flags);
> +
> + vchan_free_chan_resources(&schan->vc);
> + pm_runtime_put_sync(chan->device->dev);
why put_sync()
> +static enum dma_status sprd_dma_tx_status(struct dma_chan *chan,
> + dma_cookie_t cookie,
> + struct dma_tx_state *txstate)
> +{
> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
> + unsigned long flags;
> + enum dma_status ret;
> +
> + ret = dma_cookie_status(chan, cookie, txstate);
> +
> + spin_lock_irqsave(&schan->vc.lock, flags);
> + txstate->residue = sprd_dma_get_dst_addr(schan);
I dont think this is correct, the residue needs to be read only for current
cookie and the query might be for one which is not even submitted
> + hw->intc = CFG_ERROR_INT_EN;
> + switch (irq_mode) {
> + case NO_INT:
> + break;
> + case FRAG_DONE:
> + hw->intc |= FRAG_INT_EN;
> + break;
> + case BLK_DONE:
> + hw->intc |= BLK_INT_EN;
> + break;
> + case BLOCK_FRAG_DONE:
> + hw->intc |= BLK_INT_EN | FRAG_INT_EN;
> + break;
> + case TRANS_DONE:
> + hw->intc |= TRANS_INT_EN;
> + break;
> + case TRANS_FRAG_DONE:
> + hw->intc |= TRANS_INT_EN | FRAG_INT_EN;
> + break;
> + case TRANS_BLOCK_DONE:
> + hw->intc |= TRANS_INT_EN | BLK_INT_EN;
> + break;
> + case LIST_DONE:
> + hw->intc |= LIST_INT_EN;
> + break;
> + case CONFIG_ERR:
> + hw->intc |= CFG_ERROR_INT_EN;
> + break;
> + default:
> + dev_err(sdev->dma_dev.dev, "set irq mode failed\n");
that seems a wrong log to me, you got invalid irq_mode...
> +struct dma_async_tx_descriptor *sprd_dma_prep_dma_memcpy(struct dma_chan
> *chan,
> + dma_addr_t dest,
> + dma_addr_t src,
> + size_t len,
> + unsigned long flags)
> +{
> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
> + struct sprd_dma_desc *sdesc;
> + int ret;
> +
> + sdesc = kzalloc(sizeof(struct sprd_dma_desc), GFP_ATOMIC);
GFP_NOWAIT pls
> +static int sprd_dma_probe
[PATCH] Asoc: rockchip: Init dapm routes dynamically
Currently we are using a fixed list of dapm routes.
Init dapm routes dynamically when parsing dailinks, since we are
supporting optional codecs.
Signed-off-by: Jeffy Chen
---
sound/soc/rockchip/rk3399_gru_sound.c | 88 +--
1 file changed, 74 insertions(+), 14 deletions(-)
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c
b/sound/soc/rockchip/rk3399_gru_sound.c
index 0513fe480353..c537781f8054 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -47,18 +47,7 @@ static const struct snd_soc_dapm_widget
rockchip_dapm_widgets[] = {
SND_SOC_DAPM_SPK("Speakers", NULL),
SND_SOC_DAPM_MIC("Headset Mic", NULL),
SND_SOC_DAPM_MIC("Int Mic", NULL),
-};
-
-static const struct snd_soc_dapm_route rockchip_dapm_routes[] = {
- /* Input Lines */
- {"MIC", NULL, "Headset Mic"},
- {"DMIC1L", NULL, "Int Mic"},
- {"DMIC1R", NULL, "Int Mic"},
-
- /* Output Lines */
- {"Headphones", NULL, "HPL"},
- {"Headphones", NULL, "HPR"},
- {"Speakers", NULL, "Speaker"},
+ SND_SOC_DAPM_LINE("HDMI", NULL),
};
static const struct snd_kcontrol_new rockchip_controls[] = {
@@ -66,6 +55,7 @@ static const struct snd_kcontrol_new rockchip_controls[] = {
SOC_DAPM_PIN_SWITCH("Speakers"),
SOC_DAPM_PIN_SWITCH("Headset Mic"),
SOC_DAPM_PIN_SWITCH("Int Mic"),
+ SOC_DAPM_PIN_SWITCH("HDMI"),
};
static int rockchip_sound_max98357a_hw_params(struct snd_pcm_substream
*substream,
@@ -314,8 +304,6 @@ static struct snd_soc_card rockchip_sound_card = {
.owner = THIS_MODULE,
.dapm_widgets = rockchip_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(rockchip_dapm_widgets),
- .dapm_routes = rockchip_dapm_routes,
- .num_dapm_routes = ARRAY_SIZE(rockchip_dapm_routes),
.controls = rockchip_controls,
.num_controls = ARRAY_SIZE(rockchip_controls),
};
@@ -391,6 +379,65 @@ static const struct snd_soc_dai_link rockchip_dais[] = {
},
};
+static const struct snd_soc_dapm_route rockchip_sound_cdndp_routes[] = {
+ /* Output */
+ {"HDMI", NULL, "TX"},
+};
+
+static const struct snd_soc_dapm_route rockchip_sound_da7219_routes[] = {
+ /* Output */
+ {"Headphones", NULL, "HPL"},
+ {"Headphones", NULL, "HPR"},
+
+ /* Input */
+ {"MIC", NULL, "Headset Mic"},
+};
+
+static const struct snd_soc_dapm_route rockchip_sound_dmic_routes[] = {
+ /* Input */
+ {"Dmic", NULL, "Int Mic"},
+};
+
+static const struct snd_soc_dapm_route rockchip_sound_max98357a_routes[] = {
+ /* Output */
+ {"Speakers", NULL, "Speaker"},
+};
+
+static const struct snd_soc_dapm_route rockchip_sound_rt5514_routes[] = {
+ /* Input */
+ {"DMIC1L", NULL, "Int Mic"},
+ {"DMIC1R", NULL, "Int Mic"},
+};
+
+struct rockchip_sound_route {
+ const struct snd_soc_dapm_route *routes;
+ int num_routes;
+};
+
+static const struct rockchip_sound_route rockchip_routes[] = {
+ [DAILINK_CDNDP] = {
+ .routes = rockchip_sound_cdndp_routes,
+ .num_routes = ARRAY_SIZE(rockchip_sound_cdndp_routes),
+ },
+ [DAILINK_DA7219] = {
+ .routes = rockchip_sound_da7219_routes,
+ .num_routes = ARRAY_SIZE(rockchip_sound_da7219_routes),
+ },
+ [DAILINK_DMIC] = {
+ .routes = rockchip_sound_dmic_routes,
+ .num_routes = ARRAY_SIZE(rockchip_sound_dmic_routes),
+ },
+ [DAILINK_MAX98357A] = {
+ .routes = rockchip_sound_max98357a_routes,
+ .num_routes = ARRAY_SIZE(rockchip_sound_max98357a_routes),
+ },
+ [DAILINK_RT5514] = {
+ .routes = rockchip_sound_rt5514_routes,
+ .num_routes = ARRAY_SIZE(rockchip_sound_rt5514_routes),
+ },
+ [DAILINK_RT5514_DSP] = {},
+};
+
static int rockchip_sound_codec_node_match(struct device_node *np_codec)
{
int i;
@@ -408,6 +455,7 @@ static int rockchip_sound_of_parse_dais(struct device *dev,
struct device_node *np_cpu, *np_cpu0, *np_cpu1;
struct device_node *np_codec;
struct snd_soc_dai_link *dai;
+ struct snd_soc_dapm_route *routes;
int i, index;
card->dai_link = devm_kzalloc(dev, sizeof(rockchip_dais),
@@ -415,9 +463,16 @@ static int rockchip_sound_of_parse_dais(struct device *dev,
if (!card->dai_link)
return -ENOMEM;
+ routes = devm_kzalloc(dev, sizeof(rockchip_routes),
+ GFP_KERNEL);
+ if (!routes)
+ return -ENOMEM;
+ card->dapm_routes = routes;
+
np_cpu0 = of_parse_phandle(dev->of_node, "rockchip,cpu", 0);
np_cpu1 = of_parse_phandle(dev->of_node, "rockchip,cpu", 1);
+ card->num_dapm_routes = 0;
card->num_links = 0;
for (i = 0; i < ARRAY_SIZE(rockchip_dais); i++) {
np_codec = of_
Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3
On 2017/9/5 10:38, Jerome Glisse wrote: > On Tue, Sep 05, 2017 at 09:13:24AM +0800, Bob Liu wrote: >> On 2017/9/4 23:51, Jerome Glisse wrote: >>> On Mon, Sep 04, 2017 at 11:09:14AM +0800, Bob Liu wrote: On 2017/8/17 8:05, Jérôme Glisse wrote: > Unlike unaddressable memory, coherent device memory has a real > resource associated with it on the system (as CPU can address > it). Add a new helper to hotplug such memory within the HMM > framework. > Got an new question, coherent device( e.g CCIX) memory are likely reported to OS through ACPI and recognized as NUMA memory node. Then how can their memory be captured and managed by HMM framework? >>> >>> Only platform that has such memory today is powerpc and it is not reported >>> as regular memory by the firmware hence why they need this helper. >>> >>> I don't think anyone has defined anything yet for x86 and acpi. As this is >> >> Not yet, but now the ACPI spec has Heterogeneous Memory Attribute >> Table (HMAT) table defined in ACPI 6.2. >> The HMAT can cover CPU-addressable memory types(though not non-cache >> coherent on-device memory). >> >> Ross from Intel already done some work on this, see: >> https://lwn.net/Articles/724562/ >> >> arm64 supports APCI also, there is likely more this kind of device when CCIX >> is out (should be very soon if on schedule). > > HMAT is not for the same thing, AFAIK HMAT is for deep "hierarchy" memory ie > when you have several kind of memory each with different characteristics: > - HBM very fast (latency) and high bandwidth, non persistent, somewhat > small (ie few giga bytes) > - Persistent memory, slower (both latency and bandwidth) big (tera bytes) > - DDR (good old memory) well characteristics are between HBM and persistent > Okay, then how the kernel handle the situation of "kind of memory each with different characteristics"? Does someone have any suggestion? I thought HMM can do this. Numa policy/node distance is good but perhaps require a few extending, e.g a HBM node can't be swap, can't accept DDR fallback allocation. > So AFAICT this has nothing to do with what HMM is for, ie device memory. Note > that device memory can have a hierarchy of memory themself (HBM, GDDR and in > maybe even persistent memory). > This looks like a subset of HMAT when CPU can address device memory directly in cache-coherent way. >>> memory on PCIE like interface then i don't expect it to be reported as NUMA >>> memory node but as io range like any regular PCIE resources. Device driver >>> through capabilities flags would then figure out if the link between the >>> device and CPU is CCIX capable if so it can use this helper to hotplug it >>> as device memory. >>> >> >> From my point of view, Cache coherent device memory will popular soon and >> reported through ACPI/UEFI. Extending NUMA policy still sounds more >> reasonable >> to me. > > Cache coherent device will be reported through standard mecanisms defined by > the bus standard they are using. To my knowledge all the standard are either > on top of PCIE or are similar to PCIE. > > It is true that on many platform PCIE resource is manage/initialize by the > bios (UEFI) but it is platform specific. In some case we reprogram what the > bios pick. > > So like i was saying i don't expect the BIOS/UEFI to report device memory as But it's happening. In my understanding, that's why HMAT was introduced. For reporting device memory as regular memory(with different characteristics). -- Regards, Bob Liu > regular memory. It will be reported as a regular PCIE resources and then the > device driver will be able to determine through some flags if the link between > the CPU(s) and the device is cache coherent or not. At that point the device > driver can use register it with HMM helper. > > > The whole NUMA discussion happen several time in the past i suggest looking > on mm list archive for them. But it was rule out for several reasons. Top of > my head: > - people hate CPU less node and device memory is inherently CPU less > - device driver want total control over memory and thus to be isolated from > mm mecanism and doing all those special cases was not welcome > - existing NUMA migration mecanism are ill suited for this memory as > access by the device to the memory is unknown to core mm and there > is no easy way to report it or track it (this kind of depends on the > platform and hardware) > > I am likely missing other big points. > > Cheers, > Jérôme > > . >
Re: broken cycle counts from perf record in frequency mode [Was: Re: deducing CPU clock rate over time from cycle samples]
> The cycle value gets associated with a sample via it's period value, which is > used by `perf report` in the analysis. If I get a single "broken" sample with I always thought it just used the number of samples? > a cycle count of, say 1E14 and then a million other samples, each with "sane" > cycle counts of let's say 1E5, then the one broken sample will hold 50% of > the > total amount of measured cycles. So perf report will show that the function > where the broken sample points to will have a cost of 50%. I don't think I've seen such a situation. Did you? BTW I'm not arguing against fixing it, but typically I just recommend to avoid frequency mode. The fast sampling at the beginning has caused a range of low level PMU bugs and it is hard to reason about because of its complex behavior. Also it has no protection against synchronizing with repeated patterns in the execution, which can cause bad shadowing effects. If you use the Intel event aliases they have all sensible periods set by default. -Andi
Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3
On Tue, Sep 5, 2017 at 1:51 AM, Jerome Glisse wrote: > On Mon, Sep 04, 2017 at 11:09:14AM +0800, Bob Liu wrote: >> On 2017/8/17 8:05, Jérôme Glisse wrote: >> > Unlike unaddressable memory, coherent device memory has a real >> > resource associated with it on the system (as CPU can address >> > it). Add a new helper to hotplug such memory within the HMM >> > framework. >> > >> >> Got an new question, coherent device( e.g CCIX) memory are likely reported >> to OS >> through ACPI and recognized as NUMA memory node. >> Then how can their memory be captured and managed by HMM framework? >> > > Only platform that has such memory today is powerpc and it is not reported > as regular memory by the firmware hence why they need this helper. > > I don't think anyone has defined anything yet for x86 and acpi. As this is > memory on PCIE like interface then i don't expect it to be reported as NUMA > memory node but as io range like any regular PCIE resources. Device driver > through capabilities flags would then figure out if the link between the > device and CPU is CCIX capable if so it can use this helper to hotplug it > as device memory. Yep, the arch needs to do the right thing at hotplug time, which is 1. Don't online the memory as a NUMA node 2. Use the HMM-CDM API's to map the memory to ZONE DEVICE via the driver Like Jerome said and we tried as well, the NUMA approach needs more agreement and discussion and probable extensions Balbir Singh
Re: [PATCH RESEND 0/2] Allwinner V3s DMA support
On Tue, Aug 29, 2017 at 12:51:25PM +0800, Icenowy Zheng wrote: > This is a dedicated patchset of Allwinner V3s DMA support, which used > to be part of the audio codec support patchset. > > It's a derivation of the DMA part of v3 of the codec patchset. Applied, thanks -- ~Vinod
Re: [PATCH 2/2] tracing: Add support for critical section events
On Mon, Sep 4, 2017 at 5:54 PM, Joel Fernandes wrote: > On Mon, Sep 4, 2017 at 4:34 PM, Steven Rostedt wrote: >> On Mon, 4 Sep 2017 21:44:26 +0200 >> Peter Zijlstra wrote: >> >>> > I can change the name to something else, but at the moment I can't >>> > think of anything better. Could you suggest a better name? Also btw, >>> > 'critical timings' is the terminology used within the irqsoff tracer >>> > so this is in line with that. >>> >>> So 'critical section' is what some mis-guided people call the locked >>> region of a lock :-) Using it for something else is prone to cause more >>> confusion... >>> >>> I would simply call them what they are: irq_disable,irq_enable >>> preempt_disable,preempt_enable. >> >> Yes please. The "critical section" naming came from the code that was >> from the latency tracer days of the real time patch (pre-ftrace). The >> irqsoff tracer has the least modification from the original code, and >> probably should be rewritten one of these days. > > Sounds good to me. For the subsystem, could you guys suggest a name? I > was thinking "atomic_section"? > > Something like: > > subsystem: atomic_section > events: > irqsoff_disable > irqsoff_enable > preemptoff_disable > preemptoff_enable > > and additionally (to do what my patch does): > preemptirqsoff_enable > preemptirqsoff_disable Apologies, I meant (without the "off"): subsystem: atomic_section events: irqs_disable irqs_enable preempt_disable preempt_enable and additionally (similar to what my patch does): preemptirq_enable preemptirq_disable Could you let me know if we are in agreement about this naming? thanks, -Joel
[PATCH v3 2/2] ACPI / CPPC: Make cppc acpi driver aware of pcc subspace ids
Based on ACPI 6.2 Section 8.4.7.1.9 If the PCC register space is used,
all PCC registers, for all processors in the same performance
domain (as defined by _PSD), must be defined to be in the same subspace.
Based on Section 14.1 of ACPI specification, it is possible to have a
maximum of 256 PCC subspace ids. Add support of multiple PCC subspace id
instead of using a single global pcc_data structure.
While at that fix the time_delta check in send_pcc_cmd() so that last_mpar_reset
and mpar_count is initialized properly.
Signed-off-by: George Cherian
---
drivers/acpi/cppc_acpi.c | 241 +--
1 file changed, 151 insertions(+), 90 deletions(-)
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index e5b47f0..8f9e835 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -75,13 +75,16 @@ struct cppc_pcc_data {
/* Wait queue for CPUs whose requests were batched */
wait_queue_head_t pcc_write_wait_q;
+ ktime_t last_cmd_cmpl_time;
+ ktime_t last_mpar_reset;
+ int mpar_count;
+ int refcount;
};
-/* Structure to represent the single PCC channel */
-static struct cppc_pcc_data pcc_data = {
- .pcc_subspace_idx = -1,
- .platform_owns_pcc = true,
-};
+/* Array to represent the PCC channel per subspace id */
+static struct cppc_pcc_data *pcc_data[MAX_PCC_SUBSPACES];
+/* The cpu_pcc_subspace_idx containsper CPU subspace id */
+static DEFINE_PER_CPU(int, cpu_pcc_subspace_idx);
/*
* The cpc_desc structure contains the ACPI register details
@@ -93,7 +96,8 @@ static struct cppc_pcc_data pcc_data = {
static DEFINE_PER_CPU(struct cpc_desc *, cpc_desc_ptr);
/* pcc mapped address + header size + offset within PCC subspace */
-#define GET_PCC_VADDR(offs) (pcc_data.pcc_comm_addr + 0x8 + (offs))
+#define GET_PCC_VADDR(offs, pcc_ss_id) (pcc_data[pcc_ss_id]->pcc_comm_addr + \
+ 0x8 + (offs))
/* Check if a CPC register is in PCC */
#define CPC_IN_PCC(cpc) ((cpc)->type == ACPI_TYPE_BUFFER &&\
@@ -188,13 +192,16 @@ static struct kobj_type cppc_ktype = {
.default_attrs = cppc_attrs,
};
-static int check_pcc_chan(bool chk_err_bit)
+static int check_pcc_chan(int pcc_ss_id, bool chk_err_bit)
{
int ret = -EIO, status = 0;
- struct acpi_pcct_shared_memory __iomem *generic_comm_base =
pcc_data.pcc_comm_addr;
- ktime_t next_deadline = ktime_add(ktime_get(), pcc_data.deadline);
+ struct cppc_pcc_data *pcc_ss_data = pcc_data[pcc_ss_id];
+ struct acpi_pcct_shared_memory __iomem *generic_comm_base =
+ pcc_ss_data->pcc_comm_addr;
+ ktime_t next_deadline = ktime_add(ktime_get(),
+ pcc_ss_data->deadline);
- if (!pcc_data.platform_owns_pcc)
+ if (!pcc_ss_data->platform_owns_pcc)
return 0;
/* Retry in case the remote processor was too slow to catch up. */
@@ -219,7 +226,7 @@ static int check_pcc_chan(bool chk_err_bit)
}
if (likely(!ret))
- pcc_data.platform_owns_pcc = false;
+ pcc_ss_data->platform_owns_pcc = false;
else
pr_err("PCC check channel failed. Status=%x\n", status);
@@ -230,13 +237,12 @@ static int check_pcc_chan(bool chk_err_bit)
* This function transfers the ownership of the PCC to the platform
* So it must be called while holding write_lock(pcc_lock)
*/
-static int send_pcc_cmd(u16 cmd)
+static int send_pcc_cmd(int pcc_ss_id, u16 cmd)
{
int ret = -EIO, i;
+ struct cppc_pcc_data *pcc_ss_data = pcc_data[pcc_ss_id];
struct acpi_pcct_shared_memory *generic_comm_base =
- (struct acpi_pcct_shared_memory *) pcc_data.pcc_comm_addr;
- static ktime_t last_cmd_cmpl_time, last_mpar_reset;
- static int mpar_count;
+ (struct acpi_pcct_shared_memory *)pcc_ss_data->pcc_comm_addr;
unsigned int time_delta;
/*
@@ -249,24 +255,25 @@ static int send_pcc_cmd(u16 cmd)
* before write completion, so first send a WRITE command to
* platform
*/
- if (pcc_data.pending_pcc_write_cmd)
- send_pcc_cmd(CMD_WRITE);
+ if (pcc_ss_data->pending_pcc_write_cmd)
+ send_pcc_cmd(pcc_ss_id, CMD_WRITE);
- ret = check_pcc_chan(false);
+ ret = check_pcc_chan(pcc_ss_id, false);
if (ret)
goto end;
} else /* CMD_WRITE */
- pcc_data.pending_pcc_write_cmd = FALSE;
+ pcc_ss_data->pending_pcc_write_cmd = FALSE;
/*
* Handle the Minimum Request Turnaround Time(MRTT)
* "The minimum amount of time that OSPM must wait after the completion
* of a command before issuing the next command, in microseconds"
*/
- if (pcc_data.pc
[PATCH v3 0/2] Make cppc acpi driver aware of pcc subspace ids
The current cppc acpi driver works with only one pcc subspace id. It maintains and registers only one pcc channel even if the acpi table has different pcc subspace ids. As per ACPI 6.2 spec all PCC registers, for all processors in the same performance domain (as defined by _PSD), must be defined to be in the same subspace. The series tries to address the same by making cppc acpi driver aware of multiple possible pcc subspace ids. Patch 1 : In preparation to share the MAX_PCC_SUBSPACE definition with cppc acpi driver Patch 2 : Make the cppc acpi driver aware of multiple pcc subspace ids. Changes from v2: - Addressed Prashanth's comments on * Not to use local variables to update mpar_count, last_mpar_reset and last_cmd_cmpl_time * Add check for kzalloc failure in pcc_data_alloc() * Initialize pcc_subspace_id to -1 in acpi_cppc_processor_probe() * Check for pcc_subspace_id validity before registering pcc_channel Changes from v1: - Add last_cmd_cmpl_time, last_mpar_reset, mpar_count to the cppc_pcc_data to make it per subspace. - PCC per subspace dynamic allocation support added instead of static allocation - Added a new function pcc_data_alloc, In instances where CPU's with SMT support same PCC subspace would be used for all CPU's belonging to same physical core. This function adds the pcc_subspace refcounting and allocates the cppc_pcc_data per unique subspace idx. - Added cleanup in acpi_cppc_processor_exit. Free the mbox channel and free the cppc_pcc_data in case refcount is zero. George Cherian (2): mailbox: PCC: Move the MAX_PCC_SUBSPACES definition to header file ACPI / CPPC: Make cppc acpi driver aware of pcc subspace ids drivers/acpi/cppc_acpi.c | 241 +-- drivers/mailbox/pcc.c| 1 - include/acpi/pcc.h | 1 + 3 files changed, 152 insertions(+), 91 deletions(-) -- 2.1.4
[PATCH v3 1/2] mailbox: PCC: Move the MAX_PCC_SUBSPACES definition to header file
Move the MAX_PCC_SUBSPACES definition to acpi/pcc.h file. In preparation to add subspace id support for cppc_acpi driver. Signed-off-by: George Cherian --- drivers/mailbox/pcc.c | 1 - include/acpi/pcc.h| 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c index cbca5e5..df1a50a 100644 --- a/drivers/mailbox/pcc.c +++ b/drivers/mailbox/pcc.c @@ -69,7 +69,6 @@ #include "mailbox.h" -#define MAX_PCC_SUBSPACES 256 #define MBOX_IRQ_NAME "pcc-mbox" static struct mbox_chan *pcc_mbox_channels; diff --git a/include/acpi/pcc.h b/include/acpi/pcc.h index 8caa79c..cd6ef45 100644 --- a/include/acpi/pcc.h +++ b/include/acpi/pcc.h @@ -13,6 +13,7 @@ #include #include +#define MAX_PCC_SUBSPACES 256 #ifdef CONFIG_PCC extern struct mbox_chan *pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id); -- 2.1.4
Re: [PATCH v5] iio: accel: mma8452: improvements to handle multiple events
> I agree with your understanding. It's a rising threshold, just that the input > will only reflect high frequency changes in the signal. Thank you for the clarification. I am hoping this gets merged in the next window if no other issues. Thanks, Hari On Sun, Sep 3, 2017 at 12:24 PM, Jonathan Cameron wrote: > On Tue, 29 Aug 2017 23:01:16 -0400 > harinath Nampally wrote: > >> > We should never say "transient is for rising >> > direction" or "ff_mt is for falling direction". any combination is fine. >> >> Ok I agree that there is no hard and fast rule that "transient is for rising >> direction" or "ff_mt is for falling direction". >> But in our case, datasheet for these chips define these events based on >> acceleration magnitude rising or falling below a set threshold value. >> >> For quick reference, below excerpts are from fxls8471 datasheet: >> Motion Event: "When the acceleration exceeds a set threshold for a set >> amount of time, >> the motion interrupt is asserted." >> >> Freefall event: "The detection of “Freefall” involves the monitoring >> of the X, Y, and Z axes >> for the condition where the acceleration magnitude is below a >> user-specified threshold >> for a user-definable amount of time" >> >> Transient event: "When the high-pass filter is bypassed, the >> functionality becomes >> similar to the motion-detection function; in this mode, acceleration >> greater than >> a programmable threshold is detected (along an axis)." >> >> Therefore I think in this driver freefall event is defined as >> 'falling' event type and >> motion event is defined as 'rising' event type and Transient is also defined >> as >> 'rising' event type. >> As you might already know that mma8562 and mma8563 doesn't have >> transient event support >> but they do have freefall and motion event support which are defined >> as 'fall' and 'rise' >> event types respectively. Please note in this driver, motion event is >> enabled/configured only >> for mma8652 and mma8653. >> Therefore if I read/write sysfs node for 'rise' it should use the >> FF_MT registers for mma8652 and mma853, but for all others like >> mma8451, mma8452 and >> mma8453 which has transient event support it picks the Transient >> registers if enabled. Also please >> note transient event is enabled(but not motion event) for mma8451, >> mma8452 and mma8453. >> The problem seems like we have two different events(motion and >> transient) that are defined >> as same event type 'rising' but in fact both motion and transient are >> pretty much similar as they >> both raise interrupt flag when the acceleration magnitude rises above >> the threshold. >> Only difference is transient event has its own event config registers >> with High pass filter. >> If HPF bypassed using config register transient event acts like motion >> detection event. > >> >> That was my understanding but please correct me if I am wrong. > > I agree with your understanding. It's a rising threshold, just that the input > will only reflect high frequency changes in the signal. > >> >> > Only freefall mode needs one fix: remembering to which set of registers to >> > fall back when >> > disabling it. >> >> I don't quite understand what you mean by 'to fall back when disabling >> it'. Please elaborate. I would >> appreciate if you could suggest your logic in the form of pseudo-code. >> Thanks for your time >> > ...
Re: [PATCH v4] bcache: Don't reinvent the wheel but use existing llist API
On 2017/9/5 上午10:37, Byungchul Park wrote:
> On Fri, Aug 18, 2017 at 02:04:20PM +0800, Coly Li wrote:
>> On 2017/8/18 上午9:24, Byungchul Park wrote:
>>> On Fri, Aug 11, 2017 at 01:42:23PM +0900, Byungchul Park wrote:
Although llist provides proper APIs, they are not used. Make them used.
>>>
>>> Any opinions about this?
>>>
>>
>> The patch is good. If Eric has no time, I will take care of it later.
>
> I would be appriciated if you take this at this window :)
Sure, I am preparing a patch list to block maintainers which we are
missed in last merge window, your patch is in the list.
It will be in one or two days from my side.
Coly
Signed-off-by: Byungchul Park
Acked-by: Coly Li
---
drivers/md/bcache/closure.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/md/bcache/closure.c b/drivers/md/bcache/closure.c
index 864e673..7d5286b 100644
--- a/drivers/md/bcache/closure.c
+++ b/drivers/md/bcache/closure.c
@@ -70,21 +70,10 @@ void __closure_wake_up(struct closure_waitlist
*wait_list)
list = llist_del_all(&wait_list->list);
/* We first reverse the list to preserve FIFO ordering and fairness */
-
- while (list) {
- struct llist_node *t = list;
- list = llist_next(list);
-
- t->next = reverse;
- reverse = t;
- }
+ reverse = llist_reverse_order(list);
/* Then do the wakeups */
-
- while (reverse) {
- cl = container_of(reverse, struct closure, list);
- reverse = llist_next(reverse);
-
+ llist_for_each_entry(cl, reverse, list) {
closure_set_waiting(cl, 0);
closure_sub(cl, CLOSURE_WAITING + 1);
}
--
1.9.1
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [PATCH v2 1/3] arm: npcm: add basic support for Nuvoton BMCs
Le 08/31/17 à 15:53, Brendan Higgins a écrit : > Adds basic support for the Nuvoton NPCM750 BMC. > > Signed-off-by: Brendan Higgins > --- > arch/arm/Kconfig | 2 + > arch/arm/Makefile| 1 + > arch/arm/mach-npcm/Kconfig | 58 +++ > arch/arm/mach-npcm/Makefile | 3 + > arch/arm/mach-npcm/headsmp.S | 120 +++ > arch/arm/mach-npcm/npcm7xx.c | 34 + > arch/arm/mach-npcm/platsmp.c | 168 > +++ > 7 files changed, 386 insertions(+) > create mode 100644 arch/arm/mach-npcm/Kconfig > create mode 100644 arch/arm/mach-npcm/Makefile > create mode 100644 arch/arm/mach-npcm/headsmp.S > create mode 100644 arch/arm/mach-npcm/npcm7xx.c > create mode 100644 arch/arm/mach-npcm/platsmp.c > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 61a0cb15067e..05543f1cfbde 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -782,6 +782,8 @@ source "arch/arm/mach-netx/Kconfig" > > source "arch/arm/mach-nomadik/Kconfig" > > +source "arch/arm/mach-npcm/Kconfig" > + > source "arch/arm/mach-nspire/Kconfig" > > source "arch/arm/plat-omap/Kconfig" > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index 47d3a1ab08d2..60ca50c7d762 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -191,6 +191,7 @@ machine-$(CONFIG_ARCH_MEDIATEK) += mediatek > machine-$(CONFIG_ARCH_MXS) += mxs > machine-$(CONFIG_ARCH_NETX) += netx > machine-$(CONFIG_ARCH_NOMADIK) += nomadik > +machine-$(CONFIG_ARCH_NPCM) += npcm > machine-$(CONFIG_ARCH_NSPIRE)+= nspire > machine-$(CONFIG_ARCH_OXNAS) += oxnas > machine-$(CONFIG_ARCH_OMAP1) += omap1 > diff --git a/arch/arm/mach-npcm/Kconfig b/arch/arm/mach-npcm/Kconfig > new file mode 100644 > index ..a45670e516b4 > --- /dev/null > +++ b/arch/arm/mach-npcm/Kconfig > @@ -0,0 +1,58 @@ > +menuconfig ARCH_NPCM > + bool "Nuvoton NPCM Architecture" > + select ARCH_REQUIRE_GPIOLIB > + select USE_OF > + select PINCTRL > + select PINCTRL_NPCM7XX > + > +if ARCH_NPCM > + > +comment "NPCMX50 CPU type" > + > +config CPU_NPCM750 > + depends on ARCH_NPCM && ARCH_MULTI_V7 && !CPU_V6 && !CPU_V6K Why the !CPU_V6 and !CPU_V6K, you indicate in your cover letter that this is because headsmp.S requires ARMv7 instructions, so just tell the assembler that with: AFLAGS_headsmp.o+= -march=armv7-a > + bool "Support for NPCM750 BMC CPU (Poleg)" > + select CACHE_L2X0 > + select CPU_V7 > + select ARM_GIC > + select ARM_ERRATA_754322 > + select ARM_ERRATA_764369 > + select USB_EHCI_ROOT_HUB_TT > + select USB_ARCH_HAS_HCD > + select USB_ARCH_HAS_EHCI > + select USB_EHCI_HCD > + select USB_ARCH_HAS_OHCI > + select USB_OHCI_HCD > + select USB > + select FIQ > + select CPU_USE_DOMAINS > + select COMMON_CLK if OF > + select NPCM750_TIMER > + select MFD_SYSCON > + help > + Support for single core NPCM750 BMC CPU (Poleg). > + > + Single core variant of the Nuvoton NPCM750 BMC based on the Cortex A9. > + > +config CPU_NPCM750_SMP > + depends on CPU_NPCM750 > + bool "Support for NPCM750 BMC CPU SMP (Poleg)" > + select HAVE_SMP > + select HAVE_ARM_SCU > + select ARM_ERRATA_794072 > + select PL310_ERRATA_588369 > + select PL310_ERRATA_727915 > + select ARM_ERRATA_720789 > + select DEBUG_SPINLOCK > + select GENERIC_CLOCKEVENTS > + select SMP > + select HAVE_ARM_TWD if SMP > + select HAVE_ARM_SCU if SMP > + select CLKDEV_LOOKUP > + select COMMON_CLK if OF > + help > + Support for dual core NPCM750 BMC CPU (Poleg). > + > + Dual core variant of the Nuvoton NPCM750 BMC based on the Cortex A9. This is something that you could determine entirely from Device Tree and just have this code unconditionally be built into the kernel and have your SMP operations do nothing if only one CPU is enabled/declared in DT. The runtime overhead of running SMP_ON_UP is largely negligible that it is worth having fewer configuration options to support. > diff --git a/arch/arm/mach-npcm/headsmp.S b/arch/arm/mach-npcm/headsmp.S > new file mode 100644 > index ..d22d2fc1a35c > --- /dev/null > +++ b/arch/arm/mach-npcm/headsmp.S > @@ -0,0 +1,120 @@ > +/* > + * linux/arch/arm/mach-realview/headsmp.S The filename no longer matches but this also indicates that this was largely based on the realview board's SMP bring-up code which Russell King repeatedly tells people to move away from since it is made for a board with a ton of limitations. > + * > + * Copyright (c) 2003 ARM Limited > + * Copyright 2017 Google, Inc. > + * All Rights Reserved > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free S
[PATCH] block: fix bio.c kernel-doc notation warning
From: Randy Dunlap Sphinx treats symbols that end with '_' as some kind of special documentation indicator, so fix that by adding an ending '*' to it. ../block/bio.c:404: ERROR: Unknown target name: "gfp". Signed-off-by: Randy Dunlap --- block/bio.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-413.orig/block/bio.c +++ lnx-413/block/bio.c @@ -400,7 +400,7 @@ static void punt_bios_to_rescuer(struct /** * bio_alloc_bioset - allocate a bio for I/O - * @gfp_mask: the GFP_ mask given to the slab allocator + * @gfp_mask: the GFP_* mask given to the slab allocator * @nr_iovecs: number of iovecs to pre-allocate * @bs:the bio_set to allocate from. *
Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3
On Tue, Sep 05, 2017 at 09:13:24AM +0800, Bob Liu wrote: > On 2017/9/4 23:51, Jerome Glisse wrote: > > On Mon, Sep 04, 2017 at 11:09:14AM +0800, Bob Liu wrote: > >> On 2017/8/17 8:05, Jérôme Glisse wrote: > >>> Unlike unaddressable memory, coherent device memory has a real > >>> resource associated with it on the system (as CPU can address > >>> it). Add a new helper to hotplug such memory within the HMM > >>> framework. > >>> > >> > >> Got an new question, coherent device( e.g CCIX) memory are likely reported > >> to OS > >> through ACPI and recognized as NUMA memory node. > >> Then how can their memory be captured and managed by HMM framework? > >> > > > > Only platform that has such memory today is powerpc and it is not reported > > as regular memory by the firmware hence why they need this helper. > > > > I don't think anyone has defined anything yet for x86 and acpi. As this is > > Not yet, but now the ACPI spec has Heterogeneous Memory Attribute > Table (HMAT) table defined in ACPI 6.2. > The HMAT can cover CPU-addressable memory types(though not non-cache > coherent on-device memory). > > Ross from Intel already done some work on this, see: > https://lwn.net/Articles/724562/ > > arm64 supports APCI also, there is likely more this kind of device when CCIX > is out (should be very soon if on schedule). HMAT is not for the same thing, AFAIK HMAT is for deep "hierarchy" memory ie when you have several kind of memory each with different characteristics: - HBM very fast (latency) and high bandwidth, non persistent, somewhat small (ie few giga bytes) - Persistent memory, slower (both latency and bandwidth) big (tera bytes) - DDR (good old memory) well characteristics are between HBM and persistent So AFAICT this has nothing to do with what HMM is for, ie device memory. Note that device memory can have a hierarchy of memory themself (HBM, GDDR and in maybe even persistent memory). > > memory on PCIE like interface then i don't expect it to be reported as NUMA > > memory node but as io range like any regular PCIE resources. Device driver > > through capabilities flags would then figure out if the link between the > > device and CPU is CCIX capable if so it can use this helper to hotplug it > > as device memory. > > > > From my point of view, Cache coherent device memory will popular soon and > reported through ACPI/UEFI. Extending NUMA policy still sounds more reasonable > to me. Cache coherent device will be reported through standard mecanisms defined by the bus standard they are using. To my knowledge all the standard are either on top of PCIE or are similar to PCIE. It is true that on many platform PCIE resource is manage/initialize by the bios (UEFI) but it is platform specific. In some case we reprogram what the bios pick. So like i was saying i don't expect the BIOS/UEFI to report device memory as regular memory. It will be reported as a regular PCIE resources and then the device driver will be able to determine through some flags if the link between the CPU(s) and the device is cache coherent or not. At that point the device driver can use register it with HMM helper. The whole NUMA discussion happen several time in the past i suggest looking on mm list archive for them. But it was rule out for several reasons. Top of my head: - people hate CPU less node and device memory is inherently CPU less - device driver want total control over memory and thus to be isolated from mm mecanism and doing all those special cases was not welcome - existing NUMA migration mecanism are ill suited for this memory as access by the device to the memory is unknown to core mm and there is no easy way to report it or track it (this kind of depends on the platform and hardware) I am likely missing other big points. Cheers, Jérôme
Re: [RESEND PATCH] irq_work: Don't reinvent the wheel but use existing llist API
On Wed, May 31, 2017 at 04:04:17PM +0200, Frederic Weisbecker wrote: > On Tue, May 30, 2017 at 02:29:20PM +0900, Byungchul Park wrote: > > On Fri, May 12, 2017 at 09:45:35AM +0900, Byungchul Park wrote: > > > Although llist provides proper APIs, they are not used. Make them used. > > > > +to pet...@infradead.org > > +to mi...@kernel.org > > +to rost...@goodmis.org > > > > I am not sure whom should I send this patch to.. > > Could you check this if you are right person? > > I'll take it. I would be appriciated if you take this at this window :) > > Thanks!
Re: [PATCH v4] bcache: Don't reinvent the wheel but use existing llist API
On Fri, Aug 18, 2017 at 02:04:20PM +0800, Coly Li wrote:
> On 2017/8/18 上午9:24, Byungchul Park wrote:
> > On Fri, Aug 11, 2017 at 01:42:23PM +0900, Byungchul Park wrote:
> >> Although llist provides proper APIs, they are not used. Make them used.
> >
> > Any opinions about this?
> >
>
> The patch is good. If Eric has no time, I will take care of it later.
I would be appriciated if you take this at this window :)
> Thanks.
>
> Coly
>
> >>
> >> Signed-off-by: Byungchul Park
> >> Acked-by: Coly Li
> >> ---
> >> drivers/md/bcache/closure.c | 15 ++-
> >> 1 file changed, 2 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/md/bcache/closure.c b/drivers/md/bcache/closure.c
> >> index 864e673..7d5286b 100644
> >> --- a/drivers/md/bcache/closure.c
> >> +++ b/drivers/md/bcache/closure.c
> >> @@ -70,21 +70,10 @@ void __closure_wake_up(struct closure_waitlist
> >> *wait_list)
> >>list = llist_del_all(&wait_list->list);
> >>
> >>/* We first reverse the list to preserve FIFO ordering and fairness */
> >> -
> >> - while (list) {
> >> - struct llist_node *t = list;
> >> - list = llist_next(list);
> >> -
> >> - t->next = reverse;
> >> - reverse = t;
> >> - }
> >> + reverse = llist_reverse_order(list);
> >>
> >>/* Then do the wakeups */
> >> -
> >> - while (reverse) {
> >> - cl = container_of(reverse, struct closure, list);
> >> - reverse = llist_next(reverse);
> >> -
> >> + llist_for_each_entry(cl, reverse, list) {
> >>closure_set_waiting(cl, 0);
> >>closure_sub(cl, CLOSURE_WAITING + 1);
> >>}
> >> --
> >> 1.9.1
[PATCH 0/3] Fix the workqueue and lockdep annotation issue
We introduced the following commit to detect deadlocks caused by
wait_for_completion() in flush_{workqueue, work}() and other locks. But
now LOCKDEP_COMPLETIONS is introduced, such works are automatically done
by LOCKDEP_COMPLETIONS.
commit 4e6045f134784f4b158b3c0f7a282b04bd816887
workqueue: debug flushing deadlocks with lockdep
However, LOCKDEP_COMPLETIONS has limitation that it cannot report
deadlocks at the real time. So we have to leave some annotations for now,
but some redundant acquisitions can be removed. And we need to make
workqueue code co-work with LOCKDEP_COMPLETIONS.
Byungchul Park (3):
lockdep: Use enum type on hlock->read instead of magic number
lockdep: Introduce lock_acquire_might()
lockdep: Remove unnecessary acquisitions wrt workqueue flush
include/linux/lockdep.h | 2 ++
kernel/locking/lockdep.c | 56 ++--
kernel/workqueue.c | 18 +++-
3 files changed, 50 insertions(+), 26 deletions(-)
--
1.9.1
[PATCH 2/3] lockdep: Introduce lock_acquire_might()
>From the point of view of crossrelease, we can never be aware of the
release context in advance, until we get to the lock_release().
However, this way we cannot report deadlocks occured at the time.
Sometimes, we want to report that kind of problems, taking a risk
generating false dependencies e.g. lock_acquire()s in workqueue code,
which inevitably generate false ones with all acquisitions in works.
It would be better to provide another primitive, lock_acquire_might()
for that purpose so that lockdep internal can be aware of what users
expect and get chances to enhance to avoid false ones.
The primitive should:
1. work as if it's trylock, since links between lock_acquire_might()
and later ones are only meaningful. Remind this should be used to
do what crossrelease commit does, in advance.
2. make acquisitions by lock_acquire_might() ignored on the commit.
TODO: Although it's worth reporting potential problems, we have to do
our best to avoid adding false dependencies into graph, while current
lockdep code(not only crossrelease code) does nothing to care it.
Signed-off-by: Byungchul Park
---
include/linux/lockdep.h | 2 ++
kernel/locking/lockdep.c | 20 ++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index bfa8e0b..68c806a 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -679,6 +679,7 @@ static inline void print_irqtrace_events(struct task_struct
*curr)
#define lock_acquire_exclusive(l, s, t, n, i) lock_acquire(l, s, t,
0, 1, n, i)
#define lock_acquire_shared(l, s, t, n, i) lock_acquire(l, s, t,
1, 1, n, i)
#define lock_acquire_shared_recursive(l, s, t, n, i) lock_acquire(l, s, t,
2, 1, n, i)
+#define lock_acquire_might(l, s, t, n, i) lock_acquire(l, s, t,
3, 1, n, i)
#define spin_acquire(l, s, t, i) lock_acquire_exclusive(l, s, t,
NULL, i)
#define spin_acquire_nest(l, s, t, n, i) lock_acquire_exclusive(l, s, t,
n, i)
@@ -704,6 +705,7 @@ static inline void print_irqtrace_events(struct task_struct
*curr)
#define lock_map_acquire(l)lock_acquire_exclusive(l, 0, 0,
NULL, _THIS_IP_)
#define lock_map_acquire_read(l)
lock_acquire_shared_recursive(l, 0, 0, NULL, _THIS_IP_)
#define lock_map_acquire_tryread(l)
lock_acquire_shared_recursive(l, 0, 1, NULL, _THIS_IP_)
+#define lock_map_acquire_might(l) lock_acquire_might(l, 0, 1,
NULL, _THIS_IP_)
#define lock_map_release(l)lock_release(l, 1, _THIS_IP_)
#ifdef CONFIG_PROVE_LOCKING
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 0ac2f70..963c176 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -80,9 +80,25 @@
#define LT_READ_N 1 /* 1: read non-recursion type */
#define LT_READ_R 2 /* 2: read recursion type */
+/*
+ * This is used to detect deadlocks at the real time for
+ * crosslocks. For example, workqueue code uses acquisitions
+ * manually for that purpose taking a risk creating false
+ * dependencies. It would be better for lockdep to be aware
+ * what users such as workqueue code want in that case and
+ * get chances to enhance lockdep internal code to avoid
+ * false dependencies as far as possible.
+ *
+ * TODO: For now, this flag is only used to skip this kind
+ * of acquisitions on commit. But, adding these false ones
+ * into graph itself should be avoided if possible.
+ */
+#define LT_MIGHT 3 /* 3: might acquire */
+
#define is_write(a) ((a) == LT_WRITE)
#define is_read(a) ((a) == LT_READ_N || (a) == LT_READ_R)
#define is_read_r(a) ((a) == LT_READ_R)
+#define is_might(a) ((a) == LT_MIGHT)
/*
* lockdep_lock: protects the lockdep graph, the hashes and the
@@ -4827,7 +4843,7 @@ static inline struct lock_class *xlock_class(struct
cross_lock *xlock)
*/
static inline int depend_before(struct held_lock *hlock)
{
- return !is_read_r(hlock->read) && hlock->check && !hlock->trylock;
+ return !is_read_r(hlock->read) && !is_might(hlock->read) &&
hlock->check && !hlock->trylock;
}
/*
@@ -4835,7 +4851,7 @@ static inline int depend_before(struct held_lock *hlock)
*/
static inline int depend_after(struct held_lock *hlock)
{
- return !is_read_r(hlock->read) && hlock->check;
+ return !is_read_r(hlock->read) && !is_might(hlock->read) &&
hlock->check;
}
/*
--
1.9.1
[PATCH 1/3] lockdep: Use enum type on hlock->read instead of magic number
Currently hlock->read can have the following values:
0: write type
1: read type
2: read recursion type
It would be better to use human readable type than magic numbers.
Furthermore, this way it's easier to extend it so that hlock->read
has another value.
Signed-off-by: Byungchul Park
---
kernel/locking/lockdep.c | 40
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 44c8d0d..0ac2f70 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -76,6 +76,14 @@
#define lock_stat 0
#endif
+#define LT_WRITE 0 /* 0: write type */
+#define LT_READ_N 1 /* 1: read non-recursion type */
+#define LT_READ_R 2 /* 2: read recursion type */
+
+#define is_write(a) ((a) == LT_WRITE)
+#define is_read(a) ((a) == LT_READ_N || (a) == LT_READ_R)
+#define is_read_r(a) ((a) == LT_READ_R)
+
/*
* lockdep_lock: protects the lockdep graph, the hashes and the
* class/list/hash allocators.
@@ -271,9 +279,9 @@ static void lock_release_holdtime(struct held_lock *hlock)
holdtime = lockstat_clock() - hlock->holdtime_stamp;
stats = get_lock_stats(hlock_class(hlock));
- if (hlock->read)
+ if (is_read(hlock->read))
lock_time_inc(&stats->read_holdtime, holdtime);
- else
+ else if (is_write(hlock->read))
lock_time_inc(&stats->write_holdtime, holdtime);
put_lock_stats(stats);
}
@@ -1828,7 +1836,7 @@ static inline void inc_chains(void)
* Allow read-after-read recursion of the same
* lock class (i.e. read_lock(lock)+read_lock(lock)):
*/
- if ((read == 2) && prev->read)
+ if (is_read_r(read) && is_read(prev->read))
return 2;
/*
@@ -1906,7 +1914,7 @@ static inline void inc_chains(void)
* write-lock never takes any other locks, then the reads are
* equivalent to a NOP.
*/
- if (next->read == 2 || prev->read == 2)
+ if (is_read_r(next->read) || is_read_r(prev->read))
return 1;
/*
* Is the -> dependency already present?
@@ -2016,7 +2024,7 @@ static inline void inc_chains(void)
* Only non-recursive-read entries get new dependencies
* added:
*/
- if (hlock->read != 2 && hlock->check) {
+ if (!is_read_r(hlock->read) && hlock->check) {
int ret = check_prev_add(curr, hlock, next,
distance, &trace,
save);
if (!ret)
@@ -2460,7 +2468,7 @@ static int validate_chain(struct task_struct *curr,
struct lockdep_map *lock,
* trylock entries):
*/
if (ret == 2)
- hlock->read = 2;
+ hlock->read = LT_READ_R;
/*
* Add dependency only if this lock is not the head
* of the chain, and if it's not a secondary read-lock:
@@ -2848,7 +2856,7 @@ enum mark_type {
hlock = curr->held_locks + i;
usage_bit = 2 + (mark << 2); /* ENABLED */
- if (hlock->read)
+ if (is_read(hlock->read))
usage_bit += 1; /* READ */
BUG_ON(usage_bit >= LOCK_USAGE_STATES);
@@ -3060,7 +3068,7 @@ static int mark_irqflags(struct task_struct *curr, struct
held_lock *hlock)
* mark the lock as used in these contexts:
*/
if (!hlock->trylock) {
- if (hlock->read) {
+ if (is_read(hlock->read)) {
if (curr->hardirq_context)
if (!mark_lock(curr, hlock,
LOCK_USED_IN_HARDIRQ_READ))
@@ -3079,7 +3087,7 @@ static int mark_irqflags(struct task_struct *curr, struct
held_lock *hlock)
}
}
if (!hlock->hardirqs_off) {
- if (hlock->read) {
+ if (is_read(hlock->read)) {
if (!mark_lock(curr, hlock,
LOCK_ENABLED_HARDIRQ_READ))
return 0;
@@ -3715,7 +3723,7 @@ static int __lock_downgrade(struct lockdep_map *lock,
unsigned long ip)
curr->curr_chain_key = hlock->prev_chain_key;
WARN(hlock->read, "downgrading a read lock");
- hlock->read = 1;
+ hlock->read = LT_READ_N;
hlock->acquire_ip = ip;
if (reacquire_held_locks(curr, depth, i))
@@ -4167,7 +4175,7 @@ void lock_unpin_lock(struct lockdep_map *lock, struct
pin_cookie cookie)
if (contending_point < LOCKSTAT_POINTS)
stats->contending_point[contending_point]++;
if (lock->cpu != smp_pr
[PATCH 3/3] lockdep: Remove unnecessary acquisitions wrt workqueue flush
Workqueue added manual acquisitions to catch deadlock cases. Now
crossrelease was introduced, some of those are redundant because
crossrelease-enabled wait_for_completeion() also does it. Removed it.
Also, lock_map_acquire() in process_one_work() is too strong for
that purpose. lock_map_acquire_might() is enough. Replaced it.
Signed-off-by: Byungchul Park
---
kernel/workqueue.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index ab3c0dc..8b728d1 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2091,8 +2091,8 @@ static void process_one_work(struct worker *worker,
struct work_struct *work)
spin_unlock_irq(&pool->lock);
- lock_map_acquire(&pwq->wq->lockdep_map);
- lock_map_acquire(&lockdep_map);
+ lock_map_acquire_might(&pwq->wq->lockdep_map);
+ lock_map_acquire_might(&lockdep_map);
/*
* Strictly speaking we should mark the invariant state without holding
* any locks, that is, before these two lock_map_acquire()'s.
@@ -2504,7 +2504,7 @@ static void insert_wq_barrier(struct pool_workqueue *pwq,
*/
lockdep_init_map_crosslock((struct lockdep_map *)&barr->done.map,
"(complete)wq_barr::done",
- target->lockdep_map.key, 1);
+ target->lockdep_map.key, 0);
__init_completion(&barr->done);
barr->task = current;
@@ -2611,16 +2611,17 @@ void flush_workqueue(struct workqueue_struct *wq)
struct wq_flusher this_flusher = {
.list = LIST_HEAD_INIT(this_flusher.list),
.flush_color = -1,
- .done = COMPLETION_INITIALIZER_ONSTACK(this_flusher.done),
};
int next_color;
+ lockdep_init_map_crosslock((struct lockdep_map *)&this_flusher.done.map,
+ "(complete)wq_flusher::done",
+ wq->lockdep_map.key, 0);
+ __init_completion(&this_flusher.done);
+
if (WARN_ON(!wq_online))
return;
- lock_map_acquire(&wq->lockdep_map);
- lock_map_release(&wq->lockdep_map);
-
mutex_lock(&wq->mutex);
/*
@@ -2883,9 +2884,6 @@ bool flush_work(struct work_struct *work)
if (WARN_ON(!wq_online))
return false;
- lock_map_acquire(&work->lockdep_map);
- lock_map_release(&work->lockdep_map);
-
if (start_flush_work(work, &barr)) {
wait_for_completion(&barr.done);
destroy_work_on_stack(&barr.work);
--
1.9.1
[PATCH] arm64: Convert pr_warning to standard pr_warn
Convert pr_warning to standard pr_warn in arch/arm64/kernel/smp.c
Signed-off-by: Cheng Jian
---
arch/arm64/kernel/smp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 9f7195a..efcaa05 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -972,7 +972,7 @@ void smp_send_stop(void)
udelay(1);
if (num_online_cpus() > 1)
- pr_warning("SMP: failed to stop secondary CPUs %*pbl\n",
+ pr_warn("SMP: failed to stop secondary CPUs %*pbl\n",
cpumask_pr_args(cpu_online_mask));
}
@@ -1009,7 +1009,7 @@ void crash_smp_send_stop(void)
udelay(1);
if (atomic_read(&waiting_for_crash_ipi) > 0)
- pr_warning("SMP: failed to stop secondary CPUs %*pbl\n",
+ pr_warn("SMP: failed to stop secondary CPUs %*pbl\n",
cpumask_pr_args(&mask));
}
--
1.8.3.1
答复: [PATCH v4] mfd: Add support for RTS5250S power saving
Dear Jones,
> +static void rts5250_set_l1off_cfg_sub_d0(struct rtsx_pcr *pcr, int
> +active) {
> + struct rtsx_cr_option *option = &(pcr->option);
> +
> + u32 interrupt = rtsx_pci_readl(pcr, RTSX_BIPR);
> + int card_exist = (interrupt & SD_EXIST) | (interrupt & MS_EXIST);
> + int aspm_L1_1, aspm_L1_2;
> + u8 val = 0;
No need to pre-allocate.
If val is not pre-allocated, what will the val be if it is not assigned before
using?
> + aspm_L1_1 = rtsx_check_dev_flag(pcr, ASPM_L1_1_EN);
> + aspm_L1_2 = rtsx_check_dev_flag(pcr, ASPM_L1_2_EN);
> +
> + if (active) {
> + /* run, latency: 60us */
> + if (aspm_L1_1)
> + val = option->ltr_l1off_snooze_sspwrgate;
> + } else {
> + /* l1off, latency: 300us */
> + if (aspm_L1_2)
> + val = option->ltr_l1off_sspwrgate;
> + }
> +
> + if (aspm_L1_1 || aspm_L1_2) {
> + if (rtsx_check_dev_flag(pcr,
> + LTR_L1SS_PWR_GATE_CHECK_CARD_EN)) {
> + if (card_exist)
> + val &= ~L1OFF_MBIAS2_EN_5250;
> + else
> + val |= L1OFF_MBIAS2_EN_5250;
> + }
> + }
> + rtsx_set_l1off_sub(pcr, val);
> +}
> +
> static const struct pcr_ops rts524a_pcr_ops = {
> .write_phy = rts524a_write_phy,
> .read_phy = rts524a_read_phy,
> @@ -473,11 +617,16 @@ static int rts524a_extra_init_hw(struct rtsx_pcr *pcr)
> .card_power_off = rtsx_base_card_power_off,
> .switch_output_voltage = rtsx_base_switch_output_voltage,
> .force_power_down = rtsx_base_force_power_down,
> + .set_l1off_cfg_sub_d0 = rts5250_set_l1off_cfg_sub_d0,
> + .set_aspm = rts5249_set_aspm,
> };
>
> void rts524a_init_params(struct rtsx_pcr *pcr) {
> rts5249_init_params(pcr);
> + pcr->option.ltr_l1off_sspwrgate = LTR_L1OFF_SSPWRGATE_5250_DEFAULT;
> + pcr->option.ltr_l1off_snooze_sspwrgate =
> + LTR_L1OFF_SNOOZE_SSPWRGATE_5250_DEFAULT;
>
> pcr->reg_pm_ctrl3 = RTS524A_PM_CTRL3;
> pcr->ops = &rts524a_pcr_ops;
> @@ -576,11 +725,16 @@ static int rts525a_extra_init_hw(struct rtsx_pcr *pcr)
> .card_power_off = rtsx_base_card_power_off,
> .switch_output_voltage = rts525a_switch_output_voltage,
> .force_power_down = rtsx_base_force_power_down,
> + .set_l1off_cfg_sub_d0 = rts5250_set_l1off_cfg_sub_d0,
> + .set_aspm = rts5249_set_aspm,
> };
>
> void rts525a_init_params(struct rtsx_pcr *pcr) {
> rts5249_init_params(pcr);
> + pcr->option.ltr_l1off_sspwrgate = LTR_L1OFF_SSPWRGATE_5250_DEFAULT;
> + pcr->option.ltr_l1off_snooze_sspwrgate =
> + LTR_L1OFF_SNOOZE_SSPWRGATE_5250_DEFAULT;
>
> pcr->reg_pm_ctrl3 = RTS524A_PM_CTRL3;
> pcr->ops = &rts525a_pcr_ops;
> diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c index
> a0ac89d..50a6e67 100644
> --- a/drivers/mfd/rtsx_pcr.c
> +++ b/drivers/mfd/rtsx_pcr.c
> @@ -79,6 +79,131 @@ static inline void rtsx_pci_disable_aspm(struct rtsx_pcr
> *pcr)
> 0xFC, 0);
> }
>
> +int rtsx_comm_set_ltr_latency(struct rtsx_pcr *pcr, u32 latency) {
> + rtsx_pci_write_register(pcr, MSGTXDATA0, 0xFF, (u8) (latency &
> +0xFF));
What is (the first) 0xFF?
0xFF is just 8 bit mask.
> + rtsx_pci_write_register(pcr, MSGTXDATA1,
> + 0xFF, (u8)((latency >> 8) & 0xFF));
> + rtsx_pci_write_register(pcr, MSGTXDATA2,
> + 0xFF, (u8)((latency >> 16) & 0xFF));
> + rtsx_pci_write_register(pcr, MSGTXDATA3,
> + 0xFF, (u8)((latency >> 24) & 0xFF));
> + rtsx_pci_write_register(pcr, LTR_CTL, LTR_TX_EN_MASK |
> + LTR_LATENCY_MODE_MASK, LTR_TX_EN_1 | LTR_LATENCY_MODE_SW);
> +
> + return 0;
> +}
> +
> +int rtsx_set_ltr_latency(struct rtsx_pcr *pcr, u32 latency) {
> + if (pcr->ops->set_ltr_latency)
> + return pcr->ops->set_ltr_latency(pcr, latency);
> + else
> + return rtsx_comm_set_ltr_latency(pcr, latency); }
> +
> +static void rtsx_comm_set_aspm(struct rtsx_pcr *pcr, bool enable) {
> + struct rtsx_cr_option *option = &pcr->option;
> +
> + if (pcr->aspm_enabled == enable)
> + return;
> +
> + if (option->dev_aspm_mode == DEV_ASPM_DYNAMIC) {
> + if (enable)
> + rtsx_pci_enable_aspm(pcr);
> + else
> + rtsx_pci_disable_aspm(pcr);
> + } else if (option->dev_aspm_mode == DEV_ASPM_BACKDOOR) {
> + u8 mask = FORCE_ASPM_VAL_MASK;
> + u8 val = 0;
> +
> + if (enable)
> + val = pcr->aspm_en;
> + rtsx_pci_write_register(pcr, ASPM_FORCE_CTL, mask, val);
> + }
> +
> + pcr->aspm_enabled = enable;
> +}
> +
> +static void rtsx_disable_aspm(struct rtsx_pcr *pcr) {
> + if (pcr->ops->set_asp
Re: [PATCH v2 1/2] ASoC: codec: use enable pin to control dmic start and stop
On Monday, September 04, 2017 06:03 PM, Arnaud Pouliquen wrote:
Hello Lin,
Sorry for this late answer.
I'm not maintainer, just a contributor... but as some update seems
strange for me, so i prefer to highlight it to clarify them.
On 08/17/2017 04:24 AM, Lin Huang wrote:
From: huang lin
on some board use enable pin to control dmic start and stop,
so add this feature in dmic driver.
Please, Could you give data-sheet reference of your DMIC, to help me
to understand your use-case?
Signed-off-by: Lin Huang
---
sound/soc/codecs/Kconfig | 2 +-
sound/soc/codecs/dmic.c | 46 ++
2 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 010811e..d98233b 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -71,7 +71,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_DA732X if I2C
select SND_SOC_DA9055 if I2C
select SND_SOC_DIO2125
- select SND_SOC_DMIC
+ select SND_SOC_DMIC if GPIOLIB
Dependency also for DMIC without GPIO to handle gating?
select SND_SOC_ES8316 if I2C
select SND_SOC_ES8328_SPI if SPI_MASTER
select SND_SOC_ES8328_I2C if I2C
diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
index 12e07f9..b88a1ee 100644
--- a/sound/soc/codecs/dmic.c
+++ b/sound/soc/codecs/dmic.c
@@ -19,6 +19,8 @@
*
*/
+#include
+#include
#include
#include
#include
@@ -27,6 +29,34 @@
#include
#include
+static int dmic_daiops_trigger(struct snd_pcm_substream *substream,
+ int cmd, struct snd_soc_dai *dai)
+{
+ struct gpio_desc *dmic_en = snd_soc_dai_get_drvdata(dai);
+
+ if (!dmic_en)
+ return 0;
+
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_START:
+ case SNDRV_PCM_TRIGGER_RESUME:
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ gpiod_set_value(dmic_en, 1);
+ break;
+ case SNDRV_PCM_TRIGGER_STOP:
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ gpiod_set_value(dmic_en, 0);
+ break;
+ }
+
+ return 0;
+}
+
+static const struct snd_soc_dai_ops dmic_dai_ops = {
+ .trigger= dmic_daiops_trigger,
+};
+
should it be handle by trigger or DAPM?
static struct snd_soc_dai_driver dmic_dai = {
.name = "dmic-hifi",
.capture = {
@@ -38,8 +68,23 @@ static struct snd_soc_dai_driver dmic_dai = {
| SNDRV_PCM_FMTBIT_S24_LE
| SNDRV_PCM_FMTBIT_S16_LE,
},
+ .ops= &dmic_dai_ops,
};
+static int dmic_codec_probe(struct snd_soc_codec *codec)
+{
+ struct gpio_desc *dmic_en;
+
+ dmic_en = devm_gpiod_get_optional(codec->dev,
+ "dmicen", GPIOD_OUT_LOW);
Hypothesis here is that GPIO is always set to low? seems too limiting.
Yes, you are right, maybe i can set it to
devm_gpiod_get_optional(codec->dev, "dmicen", GPIOD_ASIS);
Regards
Arnaud
+ if (IS_ERR(dmic_en))
+ return PTR_ERR(dmic_en);
+
+ snd_soc_codec_set_drvdata(codec, dmic_en);
+
+ return 0;
+}
+
static const struct snd_soc_dapm_widget dmic_dapm_widgets[] = {
SND_SOC_DAPM_AIF_OUT("DMIC AIF", "Capture", 0,
SND_SOC_NOPM, 0, 0),
@@ -51,6 +96,7 @@ static const struct snd_soc_dapm_route intercon[] = {
};
static const struct snd_soc_codec_driver soc_dmic = {
+ .probe = dmic_codec_probe,
.component_driver = {
.dapm_widgets = dmic_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(dmic_dapm_widgets),
Re: [RFC PATCH v1 2/3] apei: add ghes param for arch_apei_report_mem_error
Hi Borislav,
On 2017/9/1 19:15, Borislav Petkov wrote:
> n Fri, Sep 01, 2017 at 06:32:00PM +0800, Xie XiuQi wrote:
>> Add ghes param for arch_apei_report_mem_error, with which
>> we could do more arch-specific processing.
>>
>> Signed-off-by: Xie XiuQi
>> ---
>> arch/x86/kernel/acpi/apei.c | 2 +-
>> drivers/acpi/apei/apei-base.c | 4 +++-
>> drivers/acpi/apei/ghes.c | 2 +-
>> include/acpi/apei.h | 4 +++-
>> include/acpi/ghes.h | 3 ++-
>> 5 files changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/x86/kernel/acpi/apei.c b/arch/x86/kernel/acpi/apei.c
>> index ea3046e..1bf1c9b 100644
>> --- a/arch/x86/kernel/acpi/apei.c
>> +++ b/arch/x86/kernel/acpi/apei.c
>> @@ -46,7 +46,7 @@ int arch_apei_enable_cmcff(struct acpi_hest_header
>> *hest_hdr, void *data)
>> return 1;
>> }
>>
>> -void arch_apei_report_mem_error(int sev, struct cper_sec_mem_err *mem_err)
>> +void arch_apei_report_mem_error(struct ghes *ghes, int sev, struct
>> cper_sec_mem_err *mem_err)
>> {
>> #ifdef CONFIG_X86_MCE
>> apei_mce_report_mem_error(sev, mem_err);
>> diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
>> index da370e1..317169b 100644
>> --- a/drivers/acpi/apei/apei-base.c
>> +++ b/drivers/acpi/apei/apei-base.c
>> @@ -38,6 +38,8 @@
>> #include
>> #include
>>
>> +#include
>> +
>> #include "apei-internal.h"
>>
>> #define APEI_PFX "APEI: "
>> @@ -770,7 +772,7 @@ int __weak arch_apei_enable_cmcff(struct
>> acpi_hest_header *hest_hdr,
>> }
>> EXPORT_SYMBOL_GPL(arch_apei_enable_cmcff);
>>
>> -void __weak arch_apei_report_mem_error(int sev,
>> +void __weak arch_apei_report_mem_error(struct ghes *ghes, int sev,
>> struct cper_sec_mem_err *mem_err)
>> {
>> }
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index fa9400d..996d16c4 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -483,7 +483,7 @@ static void ghes_do_proc(struct ghes *ghes,
>>
>> ghes_edac_report_mem_error(ghes, sev, mem_err);
>>
>> -arch_apei_report_mem_error(sev, mem_err);
>> +arch_apei_report_mem_error(ghes, sev, mem_err);
>
> And next time you want to pass something else, you'll have to touch all
> those files again...
>
> Instead, make that a notifier to which consumers register and define
> a separate struct mem_err or ghes_err or whatnot and populate it with
> cper_sec_mem_err data and whatever else is needed by the consumers.
> Instead of passing that struct ghes * which consumers don't need to
> know.
OK, I'll add a notify chain here, thanks.
>
> Thx.
>
--
Thanks,
Xie XiuQi
[PATCH -v2] IRQ, cpu-hotplug: Fix a race between CPU hotplug and IRQ desc alloc/free
From: Huang Ying
When developing code to bootup some APs (Application CPUs)
asynchronously, the following kernel panic is encountered. After
checking the code, it is found that the irq_to_desc() may return NULL
during CPU hotplug. So the NULL pointer checking is added to fix
this.
"
BUG: unable to handle kernel NULL pointer dereference at 00a4
IP: _raw_spin_lock_irq+0x1e/0x40
PGD 0
P4D 0
Oops: 0002 [#1] SMP
Modules linked in:
CPU: 93 PID: 713 Comm: cpuhp/93 Not tainted 4.13.0-rc7-00261-g3760d3d #1
Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
BRBDXSD1.86B.0335.R00.1601291644 01/29/2016
task: 883f930e2680 task.stack: c9000ef0
RIP: 0010:_raw_spin_lock_irq+0x1e/0x40
RSP: :c9000ef03de0 EFLAGS: 00010046
RAX: RBX: 0010 RCX: 0010
RDX: 0001 RSI: 0010 RDI: 00a4
RBP: c9000ef03de0 R08: 881036801240 R09:
R10: 0040 R11: 881036801268 R12: 00a4
R13: R14: 005d R15:
FS: () GS:88404454() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 00a4 CR3: 00407ee09000 CR4: 003406e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
irq_affinity_online_cpu+0x46/0xe0
? irq_migrate_all_off_this_cpu+0x2a0/0x2a0
cpuhp_invoke_callback+0x80/0x400
cpuhp_up_callbacks+0x36/0xc0
? smpboot_thread_fn+0x34/0x1f0
? smpboot_thread_fn+0x12d/0x1f0
cpuhp_thread_fun+0xd5/0xe0
smpboot_thread_fn+0x128/0x1f0
kthread+0x114/0x150
? sort_range+0x30/0x30
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x25/0x30
Code: 89 e5 e8 26 8b 6f ff 5d c3 0f 1f 40 00 0f 1f 44 00 00 55 48 89 e5 fa 66
0f 1f 44 00 00 65 ff 05 49 4a 63 7e 31 c0 ba 01 00 00 00 0f b1 17 85 c0 75
02 5d c3 89 c6 e8 21 71 6f ff 66 90 5d c3
RIP: _raw_spin_lock_irq+0x1e/0x40 RSP: c9000ef03de0
CR2: 00a4
---[ end trace a9eacc0758f1f81e ]---
Kernel panic - not syncing: Fatal exception
"
Signed-off-by: "Huang, Ying"
---
kernel/irq/cpuhotplug.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/irq/cpuhotplug.c b/kernel/irq/cpuhotplug.c
index 638eb9c83d9f..3c61c84efe59 100644
--- a/kernel/irq/cpuhotplug.c
+++ b/kernel/irq/cpuhotplug.c
@@ -133,6 +133,8 @@ void irq_migrate_all_off_this_cpu(void)
bool affinity_broken;
desc = irq_to_desc(irq);
+ if (!desc)
+ continue;
raw_spin_lock(&desc->lock);
affinity_broken = migrate_one_irq(desc);
raw_spin_unlock(&desc->lock);
@@ -179,6 +181,8 @@ int irq_affinity_online_cpu(unsigned int cpu)
irq_lock_sparse();
for_each_active_irq(irq) {
desc = irq_to_desc(irq);
+ if (!desc)
+ continue;
raw_spin_lock_irq(&desc->lock);
irq_restore_affinity_of_irq(desc, cpu);
raw_spin_unlock_irq(&desc->lock);
--
2.11.0
[lkp-robot] [pids] dd1c1f2f20: will-it-scale.per_process_ops -5% regression
Greeting,
We noticed a -5% regression of will-it-scale.per_process_ops due to commit:
commit: dd1c1f2f2028a7b851f701fc6a8ebe39dcb95e7c ("pids: make task_tgid_nr_ns()
safe")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: will-it-scale
on test machine: 256 threads Phi with 96G memory
with following parameters:
nr_task: 100%
mode: process
test: getppid1
cpufreq_governor: performance
test-description: Will It Scale takes a testcase and runs it from 1 through to
n parallel copies to see if the testcase will scale. It builds both a process
and threads based test in order to see any differences between the two.
test-url: https://github.com/antonblanchard/will-it-scale
Details are as below:
-->
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
testcase/path_params/tbox_group/run:
will-it-scale/100%-process-getppid1-performance/lkp-knl-f1
v4.13-rc6 dd1c1f2f2028a7b851f701fc6a
--
1435181 -5%1366220will-it-scale.per_process_ops
1.203e+13 11% 1.333e+13perf-stat.iTLB-loads
0.11 11% 0.12perf-stat.ipc
1.194e+13 11% 1.328e+13perf-stat.instructions
2.342e+12 8% 2.538e+12perf-stat.branch-instructions
26241 ± 4%-4% 25272perf-stat.cpu-migrations
2.236e+11 -5% 2.123e+11perf-stat.branch-misses
8.95 -10% 8.04perf-stat.cpi
9.55 -12% 8.36perf-stat.branch-miss-rate%
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.13.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_
LOAN ANGEBOT
Brauchen Sie ein dringendes Darlehen zu starten Unternehmen, Schulden Darlehen? Ein Auto oder ein Haus kaufen? Wenn ja Sorgen nicht mehr, denn wir bieten alle Arten von Darlehen zu einem niedrigen und erschwinglichen Zinssatz von 3%, ohne Sicherheiten und ohne Bonitätsprüfung. Kommen Sie zurück zu uns, wenn Sie ein Darlehen mit den folgenden Informationen benötigen. Kontaktieren Sie uns jetzt auf: creditfinancierh...@gmail.com
[PATCH v3 3/3] usb: doc: Update document for USB3 debug port usage
Update Documentation/driver-api/usb/usb3-debug-port.rst. This update includes the guide for using xHCI debug capability based TTY serial link. Signed-off-by: Lu Baolu --- Documentation/driver-api/usb/usb3-debug-port.rst | 68 1 file changed, 68 insertions(+) diff --git a/Documentation/driver-api/usb/usb3-debug-port.rst b/Documentation/driver-api/usb/usb3-debug-port.rst index feb1a36..4ad4787 100644 --- a/Documentation/driver-api/usb/usb3-debug-port.rst +++ b/Documentation/driver-api/usb/usb3-debug-port.rst @@ -98,3 +98,71 @@ you to check the sanity of the setup. cat /dev/ttyUSB0 done = end of bash scripts === + +Serial TTY +== + +DbC has also been designed for a serial TTY device at runtime. +One use of this is running a login service on the debug target. +Hence it can be remote accessed by the debug host. Another use +can probably be found in servers. It provides a peer-to-peer USB +link between two host-only machines. This provides a reasonable +out-of-band communication method between two servers. + +In order to use this, you need to make sure your kernel has been +configured to support USB_XHCI_DBGCAP. A sysfs attribute under +the xHCI device node is used to enable or disable DbC. By default, +DbC is disabled:: + + root@target:/sys/bus/pci/devices/:00:14.0# cat dbc + disabled + +Enable DbC with the following command:: + + root@target:/sys/bus/pci/devices/:00:14.0# echo enable > dbc + +You can check the DbC state at anytime:: + + root@target:/sys/bus/pci/devices/:00:14.0# cat dbc + enabled + +Connect the debug target to the debug host with a USB 3.0 super- +speed A-to-A debugging cable. You can see the /dev/ttyDBC0 created +on the debug target. You will see below kernel message lines:: + + root@target: tail -f /var/log/kern.log + [ 182.730103] xhci_hcd :00:14.0: DbC connected + [ 191.169420] xhci_hcd :00:14.0: DbC configured + [ 191.169597] xhci_hcd :00:14.0: DbC now attached to /dev/ttyDBC0 + +Accordingly, the DbC state has been brought up to:: + + root@host:/sys/bus/pci/devices/:00:14.0# cat dbc + configured + +On the debug host, you will see the debug device has been enumerated. +You will see below kernel message lines:: + + root@host: tail -f /var/log/kern.log + [ 79.454780] usb 2-2.1: new SuperSpeed USB device number 3 using xhci_hcd + [ 79.475003] usb 2-2.1: LPM exit latency is zeroed, disabling LPM. + [ 79.475389] usb 2-2.1: New USB device found, idVendor=1d6b, idProduct=0004 + [ 79.475390] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 + [ 79.475391] usb 2-2.1: Product: Remote GDB + [ 79.475392] usb 2-2.1: Manufacturer: Linux + [ 79.475393] usb 2-2.1: SerialNumber: 0001 + [ 79.660368] usb_debug 2-2.1:1.0: xhci_dbc converter detected + [ 79.660439] usb 2-2.1: xhci_dbc converter now attached to ttyUSB0 + +You can simply verify whether it works by:: + + # On target side + root@target: echo "Hello world" > /dev/ttyDBC0 + + # On host side + root@host: cat /dev/ttyUSB0 + Hello world + + # vice versa + +You have a workable serial link over USB now. -- 2.7.4
[PATCH v3 1/3] usb: xhci: Make some static functions global
This patch makes some static functions global to avoid duplications
in different files. These functions can be used in the implementation
of xHCI debug capability. There is no functional change.
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-mem.c | 94 ++--
drivers/usb/host/xhci-ring.c | 4 +-
drivers/usb/host/xhci.h | 16 +++-
3 files changed, 72 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 2a82c92..1ccb1c5 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -368,7 +368,7 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd
*xhci,
* Set the end flag and the cycle toggle bit on the last segment.
* See section 4.9.1 and figures 15 and 16.
*/
-static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
+struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
unsigned int num_segs, unsigned int cycle_state,
enum xhci_ring_type type, unsigned int max_packet, gfp_t flags)
{
@@ -467,7 +467,7 @@ int xhci_ring_expansion(struct xhci_hcd *xhci, struct
xhci_ring *ring,
#define CTX_SIZE(_hcc) (HCC_64BYTE_CONTEXT(_hcc) ? 64 : 32)
-static struct xhci_container_ctx *xhci_alloc_container_ctx(struct xhci_hcd
*xhci,
+struct xhci_container_ctx *xhci_alloc_container_ctx(struct xhci_hcd *xhci,
int type, gfp_t flags)
{
struct xhci_container_ctx *ctx;
@@ -492,7 +492,7 @@ static struct xhci_container_ctx
*xhci_alloc_container_ctx(struct xhci_hcd *xhci
return ctx;
}
-static void xhci_free_container_ctx(struct xhci_hcd *xhci,
+void xhci_free_container_ctx(struct xhci_hcd *xhci,
struct xhci_container_ctx *ctx)
{
if (!ctx)
@@ -1762,21 +1762,61 @@ void xhci_free_command(struct xhci_hcd *xhci,
kfree(command);
}
+int xhci_alloc_erst(struct xhci_hcd *xhci,
+ struct xhci_ring *evt_ring,
+ struct xhci_erst *erst,
+ gfp_t flags)
+{
+ size_t size;
+ unsigned int val;
+ struct xhci_segment *seg;
+ struct xhci_erst_entry *entry;
+
+ size = sizeof(struct xhci_erst_entry) * evt_ring->num_segs;
+ erst->entries = dma_alloc_coherent(xhci_to_hcd(xhci)->self.sysdev,
+ size,
+ &erst->erst_dma_addr,
+ flags);
+ if (!erst->entries)
+ return -ENOMEM;
+
+ memset(erst->entries, 0, size);
+ erst->num_entries = evt_ring->num_segs;
+
+ seg = evt_ring->first_seg;
+ for (val = 0; val < evt_ring->num_segs; val++) {
+ entry = &erst->entries[val];
+ entry->seg_addr = cpu_to_le64(seg->dma);
+ entry->seg_size = cpu_to_le32(TRBS_PER_SEGMENT);
+ entry->rsvd = 0;
+ seg = seg->next;
+ }
+
+ return 0;
+}
+
+void xhci_free_erst(struct xhci_hcd *xhci, struct xhci_erst *erst)
+{
+ size_t size;
+ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
+
+ size = sizeof(struct xhci_erst_entry) * (erst->num_entries);
+ if (erst->entries)
+ dma_free_coherent(dev, size,
+ erst->entries,
+ erst->erst_dma_addr);
+ erst->entries = NULL;
+}
+
void xhci_mem_cleanup(struct xhci_hcd *xhci)
{
struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
- int size;
int i, j, num_ports;
cancel_delayed_work_sync(&xhci->cmd_timer);
- /* Free the Event Ring Segment Table and the actual Event Ring */
- size = sizeof(struct xhci_erst_entry)*(xhci->erst.num_entries);
- if (xhci->erst.entries)
- dma_free_coherent(dev, size,
- xhci->erst.entries, xhci->erst.erst_dma_addr);
- xhci->erst.entries = NULL;
- xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed ERST");
+ xhci_free_erst(xhci, &xhci->erst);
+
if (xhci->event_ring)
xhci_ring_free(xhci, xhci->event_ring);
xhci->event_ring = NULL;
@@ -2313,9 +2353,8 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
unsigned intval, val2;
u64 val_64;
- struct xhci_segment *seg;
- u32 page_size, temp;
- int i;
+ u32 page_size, temp;
+ int i, ret;
INIT_LIST_HEAD(&xhci->cmd_list);
@@ -2454,32 +2493,9 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
if (xhci_check_trb_in_td_math(xhci) < 0)
goto fail;
- xhci->erst.entries = dma_alloc_coherent(dev,
- sizeof(struct xhci_erst_entry) * ERST_NUM_SEGS, &dma,
- flags);
- if
[PATCH v3 2/3] usb: xhci: Add DbC support in xHCI driver
xHCI compatible USB host controllers(i.e. super-speed USB3 controllers) can be implemented with the Debug Capability(DbC). It presents a debug device which is fully compliant with the USB framework and provides the equivalent of a very high performance full-duplex serial link. The debug capability operation model and registers interface are defined in 7.6.8 of the xHCI specification, revision 1.1. The DbC debug device shares a root port with the xHCI host. By default, the debug capability is disabled and the root port is assigned to xHCI. When the DbC is enabled, the root port will be assigned to the DbC debug device, and the xHCI sees nothing on this port. This implementation uses a sysfs node named under the xHCI device to manage the enabling and disabling of the debug capability. When the debug capability is enabled, it will present a debug device through the debug port. This debug device is fully compliant with the USB3 framework, and it can be enumerated by a debug host on the other end of the USB link. As soon as the debug device is configured, a TTY serial device named /dev/ttyDBC0 will be created. One use of this link is running a login service on the debug target. Hence it can be remote accessed by a debug host. Another use case can probably be found in servers. It provides a peer-to-peer USB link between two host-only machines. This provides a reasonable out-of-band communication method between two servers. Signed-off-by: Lu Baolu --- .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 25 + drivers/usb/host/Kconfig |9 + drivers/usb/host/Makefile |5 + drivers/usb/host/xhci-dbgcap.c | 1016 drivers/usb/host/xhci-dbgcap.h | 247 + drivers/usb/host/xhci-dbgtty.c | 586 +++ drivers/usb/host/xhci-trace.h | 60 ++ drivers/usb/host/xhci.c| 10 + drivers/usb/host/xhci.h|1 + 9 files changed, 1959 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd create mode 100644 drivers/usb/host/xhci-dbgcap.c create mode 100644 drivers/usb/host/xhci-dbgcap.h create mode 100644 drivers/usb/host/xhci-dbgtty.c diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd new file mode 100644 index 000..0088aba --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd @@ -0,0 +1,25 @@ +What: /sys/bus/pci/drivers/xhci_hcd/.../dbc +Date: June 2017 +Contact: Lu Baolu +Description: + xHCI compatible USB host controllers (i.e. super-speed + USB3 controllers) are often implemented with the Debug + Capability (DbC). It can present a debug device which + is fully compliant with the USB framework and provides + the equivalent of a very high performance full-duplex + serial link for debug purpose. + + The DbC debug device shares a root port with xHCI host. + When the DbC is enabled, the root port will be assigned + to the Debug Capability. Otherwise, it will be assigned + to xHCI. + + Writing "enable" to this attribute will enable the DbC + functionality and the shared root port will be assigned + to the DbC device. Writing "disable" to this attribute + will disable the DbC functionality and the shared root + port will roll back to the xHCI. + + Reading this attribute gives the state of the DbC. It + can be one of the following states: disabled, enabled, + initialized, connected, configured and stalled. diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index fa5692d..968a196 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -27,6 +27,15 @@ config USB_XHCI_HCD module will be called xhci-hcd. if USB_XHCI_HCD +config USB_XHCI_DBGCAP + bool "xHCI support for debug capability" + depends on TTY + select USB_U_SERIAL + ---help--- + Say 'Y' to enable the support for the xHCI debug capability. Make + sure that your xHCI host supports the extended debug capability and + you want a TTY serial device based on the xHCI debug capability + before enabling this option. If unsure, say 'N'. config USB_XHCI_PCI tristate diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index cf2691f..175c80a 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -13,6 +13,11 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o xhci-hcd-y := xhci.o xhci-mem.o xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o xhci-hcd-y += xhci-trace.o + +ifneq ($(CONFIG_USB_XHCI_DBGCAP), ) +
[PATCH v3 0/3] usb: xhci: Add debug capability support in xhci
Hi, This series is for xHCI debug capability (spec section 7.6.8) support in the xHCI driver. xHCI compatible USB host controllers(i.e. super-speed USB3 controllers) can be implemented with the Debug Capability(DbC). It presents a debug device which is fully compliant with the USB framework and provides the equivalent of a very high performance full-duplex serial link. The debug capability operation model and registers interface are defined in 7.6.8 of the xHCI specification, revision 1.1. The DbC debug device shares a root port with the xHCI host. By default, the debug capability is disabled and the root port is assigned to xHCI. When the DbC is enabled, the root port will be assigned to the DbC debug device, and the xHCI sees nothing on this port. This implementation uses a sysfs node named under the xHCI device to manage the enabling and disabling of the debug capability. When the debug capability is enabled, it will present a debug device through the debug port. This debug device is fully compliant with the USB3 framework, and it can be enumerated by a debug host on the other end of the USB link. As soon as the debug device is configured, a TTY serial device named /dev/ttyGSn will be created. One use of this link is running a login service on the debug target. Hence it can be remote accessed by a debug host. Another use case can probably be found in servers. It provides a peer-to-peer USB link between two host-only machines. This provides a reasonable out-of-band communication method between two servers. Best regards, Lu Baolu --- Change log: v1->v2: - Add a new patch to move u_serial.c from drivers/usb/gadget/function to drivers/usb/common/ and move u_serial.h to include/linux/usb/. v2->v3: - Remove the use of u_serial and add a new tty glue for debug capability. Lu Baolu (3): usb: xhci: Make some static functions global usb: xhci: Add DbC support in xHCI driver usb: doc: Update document for USB3 debug port usage .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 25 + Documentation/driver-api/usb/usb3-debug-port.rst | 68 ++ drivers/usb/host/Kconfig |9 + drivers/usb/host/Makefile |5 + drivers/usb/host/xhci-dbgcap.c | 1016 drivers/usb/host/xhci-dbgcap.h | 247 + drivers/usb/host/xhci-dbgtty.c | 586 +++ drivers/usb/host/xhci-mem.c| 94 +- drivers/usb/host/xhci-ring.c |4 +- drivers/usb/host/xhci-trace.h | 60 ++ drivers/usb/host/xhci.c| 10 + drivers/usb/host/xhci.h| 17 +- 12 files changed, 2099 insertions(+), 42 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd create mode 100644 drivers/usb/host/xhci-dbgcap.c create mode 100644 drivers/usb/host/xhci-dbgcap.h create mode 100644 drivers/usb/host/xhci-dbgtty.c -- 2.7.4
Re: linux-next: Signed-off-by missing for commit in the cifs tree
Fixed and repushed
On Mon, Sep 4, 2017 at 5:44 PM, Steve French wrote:
> Ok. Will check what happened and repush
>
> On Sep 4, 2017 16:56, "Stephen Rothwell" wrote:
>>
>> Hi all,
>>
>> Commit
>>
>> 84c9d65efa37 ("cifs: Check for timeout on Negotiate stage")
>>
>> is missing a Signed-off-by from its committer.
>>
>> --
>> Cheers,
>> Stephen Rothwell
--
Thanks,
Steve
a competition when some threads acquire futex
A competition happend when some thread use pthread_mutex(futex in
kernel). I make a demo about this : two thread get a lock and then sleep
for a few time, finally unlock when waked up.
```cpp
pthread_mutex_lock(&mutex);
//printf("tid = %lu, count = %d\n", pthread_self( ), i);
printf("tid = %lu, count = %d\n", gettid( ), i);
i++;
//sleep(6);
usleep(600);
pthread_mutex_unlock(&mutex);
```
What we expect is that these processes are fairly executing and
acquiring locks.
The actual phenomenon, however, is that the process which get the lock
first (assume A) will acquire the lock immediately after release it. It
leads to that another thread B can't access the lock for a long tim,
especially when the two thread run on the same CPU.
code follows :
```c
// muext_bug.c
pid_t gettid(void)
{
return syscall(SYS_gettid);
}
pthread_mutex_t mutex ;
void *print_msg(void *arg){
int i = 0;
cpu_set_t mask;
printf("tid = %lu(%lu) START\n", gettid( ), pthread_self( ), i);
CPU_ZERO(&mask);
CPU_SET(0, &mask);
if (pthread_setaffinity_np(pthread_self( ), sizeof(mask),
&mask) < 0)
{
fprintf(stderr, "set thread affinity failed\n");
}
else
{
printf("tid = %lu affinity to CPU%d\n", gettid( ), 0);
}
while( 1 )
{
pthread_mutex_lock(&mutex);
//printf("tid = %lu, count = %d\n", pthread_self( ), i);
printf("tid = %lu, count = %d\n", gettid( ), i);
i++;
//sleep(6);
usleep(600);
pthread_mutex_unlock(&mutex);
}
}
int main(int argc, char** argv)
{
pthread_t id1;
pthread_t id2;
printf("main pid = %d\n", getpid( ));
pthread_mutex_init(&mutex, NULL);
pthread_create(&id1, NULL, print_msg, NULL);
pthread_create(&id2, NULL, print_msg, NULL);
pthread_join(id1, NULL);
pthread_join(id2, NULL);
pthread_mutex_destroy(&mutex);
return EXIT_SUCCESS;
}
```
result :
```cpp
./mutex_bug
main pid = 17326
tid = 17327(140113713104640) START
tid = 17328(140113704711936) START
tid = 17327 affinity to CPU0
tid = 17327, count = 0
tid = 17328 affinity to CPU0
tid = 17327, count = 1
tid = 17327, count = 2
tid = 17327, count = 3
tid = 17327, count = 4
tid = 17327, count = 5
tid = 17327, count = 6
tid = 17327, count = 7
tid = 17327, count = 8
tid = 17327, count = 9
tid = 17327, count = 10
..
tid = 17327, count = 838
^C
```
use perf ftrace to shows the graph of the function calls. We found that
the process 17327 auquire the lock quickly after call futex_wake( ), so
the process 17328 futex_wait( ) all the time.
We can solve this problem by scheduling once after release the lock. But
what i don't understand is, when the process return to the user space
from kernel, the scheduler is used to select a new process to run, but
it doesn'tt work, what's happended.
Signed-off-by: Cheng Jian
Signed-off-by: Li Bin
---
kernel/futex.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/futex.c b/kernel/futex.c
index 3d38eaf..0b2d17a 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1545,6 +1545,7 @@ static int wake_futex_pi(u32 __user *uaddr, u32
uval, struct futex_pi_state *pi_
spin_unlock(&hb->lock);
wake_up_q(&wake_q);
+_cond_resched( );
out_put_key:
put_futex_key(&key);
out:
--
1.8.3.1
.
[PATCH] hwmon: (k10temp) Add support for family 17h
Add support for temperature sensors on Family 17h (Ryzen) processors.
Signed-off-by: Guenter Roeck
---
Some of this is guesswork, but afaics it is working. No idea if there
is a better way to determine the temperature offset.
drivers/hwmon/k10temp.c | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index ce3b91f22e30..da8fec89020e 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -25,6 +25,10 @@
#include
#include
+#ifndef PCI_DEVICE_ID_AMD_17H_DF_F3
+#define PCI_DEVICE_ID_AMD_17H_DF_F30x1463
+#endif
+
MODULE_DESCRIPTION("AMD Family 10h+ CPU core temperature monitor");
MODULE_AUTHOR("Clemens Ladisch ");
MODULE_LICENSE("GPL");
@@ -61,31 +65,46 @@ static DEFINE_MUTEX(nb_smu_ind_mutex);
*/
#define F15H_M60H_REPORTED_TEMP_CTRL_OFFSET0xd8200ca4
-static void amd_nb_smu_index_read(struct pci_dev *pdev, unsigned int devfn,
- int offset, u32 *val)
+/* F17h M01h Access througn SMN */
+#define F17H_M01H_REPORTED_TEMP_CTRL_OFFSET0x00059800
+
+static void amd_nb_index_read(struct pci_dev *pdev, unsigned int devfn,
+ unsigned int base, int offset, u32 *val)
{
mutex_lock(&nb_smu_ind_mutex);
pci_bus_write_config_dword(pdev->bus, devfn,
- 0xb8, offset);
+ base, offset);
pci_bus_read_config_dword(pdev->bus, devfn,
- 0xbc, val);
+ base + 4, val);
mutex_unlock(&nb_smu_ind_mutex);
}
static ssize_t temp1_input_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- u32 regval;
struct pci_dev *pdev = dev_get_drvdata(dev);
-
- if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
- amd_nb_smu_index_read(pdev, PCI_DEVFN(0, 0),
- F15H_M60H_REPORTED_TEMP_CTRL_OFFSET,
- ®val);
+ u32 regval;
+ u32 temp;
+
+ if (boot_cpu_data.x86 == 0x15 && (boot_cpu_data.x86_model == 0x60 ||
+ boot_cpu_data.x86_model == 0x70)) {
+ amd_nb_index_read(pdev, PCI_DEVFN(0, 0), 0xb8,
+ F15H_M60H_REPORTED_TEMP_CTRL_OFFSET, ®val);
+ } else if (boot_cpu_data.x86 == 0x17) {
+ amd_nb_index_read(pdev, PCI_DEVFN(0, 0), 0x60,
+ F17H_M01H_REPORTED_TEMP_CTRL_OFFSET, ®val);
} else {
pci_read_config_dword(pdev, REG_REPORTED_TEMPERATURE, ®val);
}
- return sprintf(buf, "%u\n", (regval >> 21) * 125);
+
+ temp = (regval >> 21) * 125;
+ /* Ryzen 1700X and 1800X require manually applied temperature offset */
+ if (boot_cpu_data.x86_model_id &&
+ (strstr(boot_cpu_data.x86_model_id, "AMD Ryzen 7 1700X") ||
+strstr(boot_cpu_data.x86_model_id, "AMD Ryzen 7 1800X")))
+ temp -= 2;
+
+ return sprintf(buf, "%u\n", temp);
}
static ssize_t temp1_max_show(struct device *dev,
@@ -214,6 +233,7 @@ static const struct pci_device_id k10temp_id_table[] = {
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M60H_NB_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
+ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) },
{}
};
MODULE_DEVICE_TABLE(pci, k10temp_id_table);
--
2.7.4
[PATCH] swapon: fix vfree() badness
From: Dave Chinner
The cluster_info structure is allocated with kvzalloc(), which can
return kmalloc'd or vmalloc'd memory. It must be paired with
kvfree(), but sys_swapon uses vfree(), resultin in this warning
from xfstests generic/357:
[ 1985.294915] swapon: swapfile has holes
[ 1985.296012] Trying to vfree() bad address (88011569ac00)
[ 1985.297769] [ cut here ]
[ 1985.299017] WARNING: CPU: 4 PID: 980 at mm/vmalloc.c:1521 __vunmap+0x97/0xb0
[ 1985.300868] CPU: 4 PID: 980 Comm: swapon Tainted: GW
4.13.0-dgc #55
[ 1985.303086] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 1985.305421] task: 88083599c800 task.stack: c90006d68000
[ 1985.306896] RIP: 0010:__vunmap+0x97/0xb0
[ 1985.307866] RSP: 0018:c90006d6be68 EFLAGS: 00010296
[ 1985.309300] RAX: 0030 RBX: 88011569ac00 RCX:
[ 1985.311066] RDX: 88013fc949d8 RSI: 88013fc8cb98 RDI: 88013fc8cb98
[ 1985.312803] RBP: c90006d6be80 R08: 0004844c R09: 1578
[ 1985.314672] R10: 82271b20 R11: 8256e16d R12: 000a
[ 1985.316444] R13: 0001 R14: ffea R15: 880139a96000
[ 1985.318230] FS: 7fb23ac0e880() GS:88013fc8()
knlGS:
[ 1985.320081] CS: 0010 DS: ES: CR0: 80050033
[ 1985.321503] CR2: 564cdb0c7000 CR3: 000137448000 CR4: 000406e0
[ 1985.323140] Call Trace:
[ 1985.323727] vfree+0x2e/0x70
[ 1985.324403] SyS_swapon+0x433/0x1080
[ 1985.325365] entry_SYSCALL_64_fastpath+0x1a/0xa5
Fix this as well as the memory leak caused by a missing kvfree(frontswap_map) in
the error handling code.
cc:
Signed-Off-By: Dave Chinner
---
mm/swapfile.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 6ba4aab2db0b..a8952b6563c6 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -3052,7 +3052,8 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile,
int, swap_flags)
p->flags = 0;
spin_unlock(&swap_lock);
vfree(swap_map);
- vfree(cluster_info);
+ kvfree(cluster_info);
+ kvfree(frontswap_map);
if (swap_file) {
if (inode && S_ISREG(inode->i_mode)) {
inode_unlock(inode);
--
2.13.3
[PATCH net V2] vhost_net: correctly check tx avail during rx busy polling
We check tx avail through vhost_enable_notify() in the past which is
wrong since it only checks whether or not guest has filled more
available buffer since last avail idx synchronization which was just
done by vhost_vq_avail_empty() before. What we really want is checking
pending buffers in the avail ring. Fix this by calling
vhost_vq_avail_empty() instead.
This issue could be noticed by doing netperf TCP_RR benchmark as
client from guest (but not host). With this fix, TCP_RR from guest to
localhost restores from 1375.91 trans per sec to 55235.28 trans per
sec on my laptop (Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz).
Fixes: 030881372460 ("vhost_net: basic polling support")
Signed-off-by: Jason Wang
---
- The patch is needed for -stable
- Changes from V1: enable vq notification when needed
---
drivers/vhost/net.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 06d0448..1c75572 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -634,8 +634,13 @@ static int vhost_net_rx_peek_head_len(struct vhost_net
*net, struct sock *sk)
preempt_enable();
- if (vhost_enable_notify(&net->dev, vq))
+ if (!vhost_vq_avail_empty(&net->dev, vq))
vhost_poll_queue(&vq->poll);
+ else if (unlikely(vhost_enable_notify(&net->dev, vq))) {
+ vhost_disable_notify(&net->dev, vq);
+ vhost_poll_queue(&vq->poll);
+ }
+
mutex_unlock(&vq->mutex);
len = peek_head_len(rvq, sk);
--
2.7.4
Re: linux-next: Signed-off-bys missing for commits in the thermal tree
On Tue, 2017-09-05 at 10:57 +1000, Stephen Rothwell wrote:
> Hi Zhang,
>
> Commits
>
> 1f0d851d9359 ("Debug patch")
> 083d998842a2 ("debug")
>
> are missing a Signed-off-bys.
>
> These are not really appropriate for linux-next inclusion -
> especially
> during the merge window.
>
oops, sorry, wrong branch merged.
thanks,
rui
Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3
On 2017/9/4 23:51, Jerome Glisse wrote: > On Mon, Sep 04, 2017 at 11:09:14AM +0800, Bob Liu wrote: >> On 2017/8/17 8:05, Jérôme Glisse wrote: >>> Unlike unaddressable memory, coherent device memory has a real >>> resource associated with it on the system (as CPU can address >>> it). Add a new helper to hotplug such memory within the HMM >>> framework. >>> >> >> Got an new question, coherent device( e.g CCIX) memory are likely reported >> to OS >> through ACPI and recognized as NUMA memory node. >> Then how can their memory be captured and managed by HMM framework? >> > > Only platform that has such memory today is powerpc and it is not reported > as regular memory by the firmware hence why they need this helper. > > I don't think anyone has defined anything yet for x86 and acpi. As this is Not yet, but now the ACPI spec has Heterogeneous Memory Attribute Table (HMAT) table defined in ACPI 6.2. The HMAT can cover CPU-addressable memory types(though not non-cache coherent on-device memory). Ross from Intel already done some work on this, see: https://lwn.net/Articles/724562/ arm64 supports APCI also, there is likely more this kind of device when CCIX is out (should be very soon if on schedule). > memory on PCIE like interface then i don't expect it to be reported as NUMA > memory node but as io range like any regular PCIE resources. Device driver > through capabilities flags would then figure out if the link between the > device and CPU is CCIX capable if so it can use this helper to hotplug it > as device memory. > >From my point of view, Cache coherent device memory will popular soon and >reported through ACPI/UEFI. Extending NUMA policy still sounds more reasonable to me. -- Thanks, Bob Liu
Re: [PATCH v8 11/14] lockdep: Apply crossrelease to PG_locked locks
On Mon, Aug 07, 2017 at 04:12:58PM +0900, Byungchul Park wrote:
> Although lock_page() and its family can cause deadlock, the lock
> correctness validator could not be applied to them until now, becasue
> things like unlock_page() might be called in a different context from
> the acquisition context, which violates lockdep's assumption.
>
> Thanks to CONFIG_LOCKDEP_CROSSRELEASE, we can now apply the lockdep
> detector to page locks. Applied it.
I expect applying this into lock_page() is more useful than
wait_for_completion(). Could you consider this as the next?
> Signed-off-by: Byungchul Park
> ---
> include/linux/mm_types.h | 8
> include/linux/pagemap.h | 101
> ---
> lib/Kconfig.debug| 8
> mm/filemap.c | 4 +-
> mm/page_alloc.c | 3 ++
> 5 files changed, 116 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index ff15181..f1e3dba 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -16,6 +16,10 @@
>
> #include
>
> +#ifdef CONFIG_LOCKDEP_PAGELOCK
> +#include
> +#endif
> +
> #ifndef AT_VECTOR_SIZE_ARCH
> #define AT_VECTOR_SIZE_ARCH 0
> #endif
> @@ -216,6 +220,10 @@ struct page {
> #ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS
> int _last_cpupid;
> #endif
> +
> +#ifdef CONFIG_LOCKDEP_PAGELOCK
> + struct lockdep_map_cross map;
> +#endif
> }
> /*
> * The struct page can be forced to be double word aligned so that atomic ops
> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
> index 9717ca8..9f448c6 100644
> --- a/include/linux/pagemap.h
> +++ b/include/linux/pagemap.h
> @@ -14,6 +14,9 @@
> #include
> #include /* for in_interrupt() */
> #include
> +#ifdef CONFIG_LOCKDEP_PAGELOCK
> +#include
> +#endif
>
> /*
> * Bits in mapping->flags.
> @@ -450,26 +453,91 @@ static inline pgoff_t linear_page_index(struct
> vm_area_struct *vma,
> return pgoff;
> }
>
> +#ifdef CONFIG_LOCKDEP_PAGELOCK
> +#define lock_page_init(p)\
> +do { \
> + static struct lock_class_key __key; \
> + lockdep_init_map_crosslock((struct lockdep_map *)&(p)->map, \
> + "(PG_locked)" #p, &__key, 0); \
> +} while (0)
> +
> +static inline void lock_page_acquire(struct page *page, int try)
> +{
> + page = compound_head(page);
> + lock_acquire_exclusive((struct lockdep_map *)&page->map, 0,
> +try, NULL, _RET_IP_);
> +}
> +
> +static inline void lock_page_release(struct page *page)
> +{
> + page = compound_head(page);
> + /*
> + * lock_commit_crosslock() is necessary for crosslocks.
> + */
> + lock_commit_crosslock((struct lockdep_map *)&page->map);
> + lock_release((struct lockdep_map *)&page->map, 0, _RET_IP_);
> +}
> +#else
> +static inline void lock_page_init(struct page *page) {}
> +static inline void lock_page_free(struct page *page) {}
> +static inline void lock_page_acquire(struct page *page, int try) {}
> +static inline void lock_page_release(struct page *page) {}
> +#endif
> +
> extern void __lock_page(struct page *page);
> extern int __lock_page_killable(struct page *page);
> extern int __lock_page_or_retry(struct page *page, struct mm_struct *mm,
> unsigned int flags);
> -extern void unlock_page(struct page *page);
> +extern void do_raw_unlock_page(struct page *page);
>
> -static inline int trylock_page(struct page *page)
> +static inline void unlock_page(struct page *page)
> +{
> + lock_page_release(page);
> + do_raw_unlock_page(page);
> +}
> +
> +static inline int do_raw_trylock_page(struct page *page)
> {
> page = compound_head(page);
> return (likely(!test_and_set_bit_lock(PG_locked, &page->flags)));
> }
>
> +static inline int trylock_page(struct page *page)
> +{
> + if (do_raw_trylock_page(page)) {
> + lock_page_acquire(page, 1);
> + return 1;
> + }
> + return 0;
> +}
> +
> /*
> * lock_page may only be called if we have the page's inode pinned.
> */
> static inline void lock_page(struct page *page)
> {
> might_sleep();
> - if (!trylock_page(page))
> +
> + if (!do_raw_trylock_page(page))
> __lock_page(page);
> + /*
> + * acquire() must be after actual lock operation for crosslocks.
> + * This way a crosslock and current lock can be ordered like:
> + *
> + * CONTEXT 1 CONTEXT 2
> + * - -
> + * lock A (cross)
> + * acquire A
> + *X = atomic_inc_return(&cross_gen_id)
> + * ~
> + * acquire B
> + *Y = atomic_read_acquire(
linux-next: no new material during the merge window
Hi all, Please do not add any v4.15 related material to your linux-next included branches until after v4.14-rc1 has been released. -- Cheers, Stephen Rothwell
linux-next: Signed-off-bys missing for commits in the thermal tree
Hi Zhang,
Commits
1f0d851d9359 ("Debug patch")
083d998842a2 ("debug")
are missing a Signed-off-bys.
These are not really appropriate for linux-next inclusion - especially
during the merge window.
--
Cheers,
Stephen Rothwell
Re: [PATCH 2/2] tracing: Add support for critical section events
On Mon, Sep 4, 2017 at 4:34 PM, Steven Rostedt wrote: > On Mon, 4 Sep 2017 21:44:26 +0200 > Peter Zijlstra wrote: > >> > I can change the name to something else, but at the moment I can't >> > think of anything better. Could you suggest a better name? Also btw, >> > 'critical timings' is the terminology used within the irqsoff tracer >> > so this is in line with that. >> >> So 'critical section' is what some mis-guided people call the locked >> region of a lock :-) Using it for something else is prone to cause more >> confusion... >> >> I would simply call them what they are: irq_disable,irq_enable >> preempt_disable,preempt_enable. > > Yes please. The "critical section" naming came from the code that was > from the latency tracer days of the real time patch (pre-ftrace). The > irqsoff tracer has the least modification from the original code, and > probably should be rewritten one of these days. Sounds good to me. For the subsystem, could you guys suggest a name? I was thinking "atomic_section"? Something like: subsystem: atomic_section events: irqsoff_disable irqsoff_enable preemptoff_disable preemptoff_enable and additionally (to do what my patch does): preemptirqsoff_enable preemptirqsoff_disable Does this sound good to you? I did bulk of the work today for moving code from the irqsoff tracer into a common area that's irqsoff tracer specific, and now I'm getting close to the point of creating the above tracepoints and posting another series, but I wanted to get your thoughts on the above. I like this new approach better because the next logically step ontop of this work can be to rewrite irqsoff tracer by using probes on the above tracepoints (which I'll do once we can get these in). thanks, - Joel
Re: [PATCH v11 0/2] Make find_later_rq() choose a closer cpu in topology
On Fri, Aug 25, 2017 at 03:40:49PM +0900, Byungchul Park wrote: > Change from v10 >-. modify a comment a bit as Steven suggested > > Change from v9 >-. modify a comment a bit so to be more clear as Juri suggested > > Change from v8 >-. add suggested-by Peterz >-. add several comments > > Change from v7 >-. fix a trivial typo >-. modify commit messages to explain what it does more clearly >-. simplify code with an existing macro > > Change from v6 >-. add a comment about selection of fallback_cpu incase more than one exist >-. modify a comment explaining what we do wrt PREFER_SIBLING > > Change from v5 >-. exclude two patches already picked up by peterz > (sched/deadline: Make find_later_rq() choose a closer cpu in topology) > (sched/deadline: Change return value of cpudl_find()) >-. apply what peterz fixed for 'prefer sibling', into deadline and rt > > Change from v4 >-. remove a patch that might cause huge lock contention > (by spin lock(&cpudl.lock) in a hot path of scheduler) > > Change from v3 >-. rename closest_cpu to best_cpu so that it align with rt >-. protect referring cpudl.elements with cpudl.lock >-. change return value of cpudl_find() to bool > > Change from v2 >-. add support for SD_PREFER_SIBLING > > Change from v1 >-. clean up the patch Could you let me know your opinion about this?
Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
On Mon, Sep 04, 2017 at 01:42:48PM +0200, Peter Zijlstra wrote: > On Mon, Sep 04, 2017 at 10:30:32AM +0900, Byungchul Park wrote: > > On Fri, Sep 01, 2017 at 06:38:52PM +0200, Peter Zijlstra wrote: > > > And get tangled up with the workqueue annotation again, no thanks. > > > Having the first few works see the thread setup isn't worth it. > > > > > > And your work_id annotation had the same problem. > > > > I keep asking you for an example because I really understand you. > > > >Fix my problematic example with your patches, > > > >or, > > > >Show me a problematic scenario with my original code, you expect. > > > > Whatever, it would be helpful to understand you. > > I _really_ don't understand what you're worried about. Is it the kthread > create and workqueue init or the pool->lock that is released/acquired in > process_one_work()? s/in process_one_work()/in all worker code including setup code/ Original code was already designed to handle real dependencies well. But you invalidated it _w/o_ any reason, that's why I don't agree with your patches. Your patches only do avoiding the wq issue now we focus on. Look at: worker thread another context - --- wait_for_completion() | | (1) v +-+ | Work A | (2) +-+ | | (3) v +-+ | Work B | (4) +-+ | | (5) v +-+ | Work C | (6) +-+ | v We have to consider whole context of the worker to build dependencies with a crosslock e.g. wait_for_commplete(). Only thing we have to care here is to make all works e.g. (2), (4) and (6) independent, because workqueue does _concurrency control_. As I said last year at the very beginning, for works not applied the control e.g. max_active == 1, we don't need that isolation. I said, it's a future work. It would have been much easier to communicate with each other if you *tried* to understand my examples like now or you *tried* to give me one example at least. You didn't even *try*. Only thing I want to ask you for is to *try* to understand my opinions on conflicts. Now, understand what I intended? Still unsufficient?
Re: linux-next: manual merge of the akpm-current tree with the parisc-hd tree
Hi all,
On Tue, 22 Aug 2017 16:53:18 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/parisc/include/uapi/asm/mman.h
>
> between commit:
>
> 1c190151447d ("parisc: Add MADV_HWPOISON and MADV_SOFT_OFFLINE")
>
> from the parisc-hd tree and commit:
>
> 115d20ededaf ("mm,fork: introduce MADV_WIPEONFORK")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc arch/parisc/include/uapi/asm/mman.h
> index 9a9c2fe4be50,f6eec376e5fa..
> --- a/arch/parisc/include/uapi/asm/mman.h
> +++ b/arch/parisc/include/uapi/asm/mman.h
> @@@ -57,9 -60,9 +57,12 @@@
> overrides the coredump filter bits */
> #define MADV_DODUMP 70 /* Clear the MADV_NODUMP flag */
>
> + #define MADV_WIPEONFORK 71 /* Zero memory on fork, child only */
> + #define MADV_KEEPONFORK 72 /* Undo MADV_WIPEONFORK */
> +
> +#define MADV_HWPOISON 100 /* poison a page for testing */
> +#define MADV_SOFT_OFFLINE 101 /* soft offline page for
> testing */
> +
> /* compatibility flags */
> #define MAP_FILE0
> #define MAP_VARIABLE0
Just a reminder that the above conflict still exists.
--
Cheers,
Stephen Rothwell
Re: linux-next: manual merge of the rpmsg tree with the qcom tree
Hi all,
On Wed, 9 Aug 2017 14:57:27 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the rpmsg tree got a conflict in:
>
> drivers/soc/qcom/Kconfig
>
> between commit:
>
> 2a464815d326 ("soc: qcom: bring all qcom drivers into a submenu")
>
> from the qcom tree and commit:
>
> c4d77d5fcd8b ("soc: qcom: GLINK SSR notifier")
>
> from the rpmsg tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/soc/qcom/Kconfig
> index 5f12657fc552,d0fc331972d2..
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@@ -1,8 -1,15 +1,17 @@@
> #
> # QCOM Soc drivers
> #
> +menu "Qualcomm SoC drivers"
> +
> + config QCOM_GLINK_SSR
> + tristate "Qualcomm Glink SSR driver"
> + depends on RPMSG
> + depends on QCOM_RPROC_COMMON
> + help
> + Say y here to enable GLINK SSR support. The GLINK SSR driver
> + implements the SSR protocol for notifying the remote processor about
> + neighboring subsystems going up or down.
> +
> config QCOM_GSBI
> tristate "QCOM General Serial Bus Interface"
> depends on ARCH_QCOM
Just a reminder that the above conflict still exists (but between the
rpmsg tree and the arm-soc tree, now).
--
Cheers,
Stephen Rothwell
Re: linux-next: manual merge of the userns tree with the mips tree
Hi all,
On Tue, 8 Aug 2017 15:10:04 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the userns tree got a conflict in:
>
> arch/mips/kernel/traps.c
>
> between commit:
>
> 260a789828aa ("MIPS: signal: Remove unreachable code from
> force_fcr31_sig().")
>
> from the mips tree and commit:
>
> ea1b75cf9138 ("signal/mips: Document a conflict with SI_USER with SIGFPE")
>
> from the userns tree.
>
> I fixed it up (the former removed the code updated by the latter) and
> can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
Just a reminder that the above conflict still exists.
--
Cheers,
Stephen Rothwell
Re: linux-next: manual merge of the scsi tree with the staging tree
Hi all,
On Mon, 28 Aug 2017 16:41:27 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the scsi tree got a conflict in:
>
> drivers/staging/unisys/visorhba/visorhba_main.c
>
> between commits:
>
> 781facd05eb9 ("staging: unisys: visorhba: visorhba_main.c: fixed comment
> formatting issues")
>
> from the staging tree and commit:
>
> 7bc4e528d9f6 ("scsi: visorhba: sanitze private device data allocation")
>
> from the scsi tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/staging/unisys/visorhba/visorhba_main.c
> index 8567e447891e,ddce92552ff5..
> --- a/drivers/staging/unisys/visorhba/visorhba_main.c
> +++ b/drivers/staging/unisys/visorhba/visorhba_main.c
> @@@ -44,12 -44,11 +44,11 @@@ static struct visor_channeltype_descrip
> };
>
> MODULE_DEVICE_TABLE(visorbus, visorhba_channel_types);
> -MODULE_ALIAS("visorbus:" VISOR_VHBA_CHANNEL_UUID_STR);
> +MODULE_ALIAS("visorbus:" VISOR_VHBA_CHANNEL_GUID_STR);
>
> struct visordisk_info {
> + struct scsi_device *sdev;
> u32 valid;
> - /* Disk Path */
> - u32 channel, id, lun;
> atomic_t ios_threshold;
> atomic_t error_count;
> struct visordisk_info *next;
> @@@ -105,25 -101,19 +104,19 @@@ struct visorhba_devices_open
> struct visorhba_devdata *devdata;
> };
>
> - #define for_each_vdisk_match(iter, list, match) \
> - for (iter = &list->head; iter->next; iter = iter->next) \
> - if ((iter->channel == match->channel) && \
> - (iter->id == match->id) && \
> - (iter->lun == match->lun))
> -
> /*
> - * visor_thread_start - starts a thread for the device
> - * @threadfn: Function the thread starts
> - * @thrcontext: Context to pass to the thread, i.e. devdata
> - * @name: string describing name of thread
> + * visor_thread_start - Starts a thread for the device
> + * @threadfn: Function the thread starts
> + * @thrcontext: Context to pass to the thread, i.e. devdata
> + * @name: String describing name of thread
>*
> - * Starts a thread for the device.
> + * Starts a thread for the device.
>*
> - * Return the task_struct * denoting the thread on success,
> - * or NULL on failure
> + * Return: The task_struct * denoting the thread on success,
> + * or NULL on failure
>*/
> -static struct task_struct *visor_thread_start
> -(int (*threadfn)(void *), void *thrcontext, char *name)
> +static struct task_struct *visor_thread_start(int (*threadfn)(void *),
> + void *thrcontext, char *name)
> {
> struct task_struct *task;
>
> @@@ -302,21 -280,19 +295,20 @@@ static void cleanup_scsitaskmgmt_handle
> }
>
> /*
> - * forward_taskmgmt_command - send taskmegmt command to the Service
> - * Partition
> - * @tasktype: Type of taskmgmt command
> - * @scsidev: Scsidev that issued command
> + * forward_taskmgmt_command - Send taskmegmt command to the Service
> + *Partition
> + * @tasktype: Type of taskmgmt command
> + * @scsidev: Scsidev that issued command
>*
> - * Create a cmdrsp packet and send it to the Serivce Partition
> - * that will service this request.
> - * Returns whether the command was queued successfully or not.
> + * Create a cmdrsp packet and send it to the Serivce Partition
> + * that will service this request.
> + *
> + * Return: Int representing whether command was queued successfully or not
>*/
> static int forward_taskmgmt_command(enum task_mgmt_types tasktype,
> - struct scsi_cmnd *scsicmd)
> + struct scsi_device *scsidev)
> {
> struct uiscmdrsp *cmdrsp;
> - struct scsi_device *scsidev = scsicmd->device;
> struct visorhba_devdata *devdata =
> (struct visorhba_devdata *)scsidev->host->hostdata;
> int notifyresult = 0x;
> @@@ -607,24 -570,19 +604,21 @@@ static int visorhba_slave_alloc(struct
> struct visorhba_devdata *devdata;
> struct Scsi_Host *scsihost = (struct Scsi_Host *)scsidev->host;
>
> ++/* already allocated return success */
> + if (scsidev->hostdata)
> -return 0; /* already allocated return success */
> ++return 0;
> +
> +/* even though we errored, treat as success */
> devdata = (struct visorhba_devdata *)scsihost->hostdata;
> if (!devdata)
> -return 0; /* even though we errored, treat as success */
> +return 0;
>
> - /* a
Re: Donation
Greetings To You, My Name is Mavis wanczyk , the winner of the Power ball jackpot of $ $758.7 million in the AUGUST 24, 2017, My jackpot was a gift from God to me hence my Entire family/foundation has AGREED to do this. My foundation is donating $500,000.00USD to you. please contac maviswanczyk...@gmail.com for full details and please accept this token as a gift from me and my family. Read more: http://money.cnn.com/2017/08/23/news/powerball-700-million-jackpot/index.html Best Regards, Mavis Wanczyk
