Re: [PATCH 1/4] x86/efi: show actual ending addresses in efi_print_memmap
On Mon, 21 Dec, at 03:50:38PM, Matt Fleming wrote: > On Thu, 17 Dec, at 07:28:31PM, Robert Elliott wrote: > > Adjust efi_print_memmap to print the real end address of each > > range, not 1 byte beyond. This matches other prints like those for > > SRAT and nosave memory. > > > > Change the closing ) to ] to match the opening [. > > > > old: > > efi: mem61: [Persistent Memory | | | | | | | |WB|WT|WC|UC] > > range=[0x00088000-0x000c8000) (16384MB) > > > > new: > > efi: mem61: [Persistent Memory | | | | | | | |WB|WT|WC|UC] > > range=[0x00088000-0x000c7fff] (16384MB) > > > > Example other address range prints: > > SRAT: Node 1 PXM 1 [mem 0x48000-0x87fff] > > PM: Registered nosave memory: [mem 0x88000-0xc7fff] > > > > Signed-off-by: Robert Elliott > > --- > > arch/x86/platform/efi/efi.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > Is this change purely for aesthetic reasons? We're usually not in the > habit of changing the output of print messages without a good reason > because people downstream do rely on them being consistent. I just noticed the bracket change. My comment above only refers to printing the range addresses. Swapping ')' for ']' is a perfectly valid change. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Adding Reset resume support for CDC-EEM driver.
On Mon, 21 Dec 2015, Vikas Bansal wrote: > Pre-Condition > At the time of reset resume of a USB device, both self and bus powered > devices might go to a low power state or power off state depending on the > acceptable suspend time power of the system. > In case the device experiences a power glitch or completely powers off during > suspend-resume, the device will lose its internal state and hence it'll again > need a set interface from class driver on reset resume operation. > > Issue > So far our experiments were based on a USB gadget working on cdc_eem > protocol. > We have seen that device is unable to continue the packet transfer on bulk > endpoints after the reset resume operation. > > Solution > We have added a .reset_resume function for cdc_eem protocol which sends a set > interface command on the Control endpoint. And calls the existing > usbnet_resume thereafter You know, the USB core already issues a Set-Interface request on the control endpoint whenever a reset-resume occurs (unless the interface was using altsetting 0 beforehand). Issuing another Set-Interface shouldn't make any difference. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 1/2] watchdog: Use static struct class watchdog_class in stead of pointer
On 12/18/2015 08:22 PM, Pratyush Anand wrote: On 17/12/2015:06:56:27 AM, Guenter Roeck wrote: On 12/17/2015 04:23 AM, Pratyush Anand wrote: We need few sysfs attributes to know different status of a watchdog device. To do that, we need to associate .dev_groups with watchdog_class. So convert it from pointer to static. Putting this static struct in watchdog_dev.c, so that static device attributes defined in that file can be attached to it. Signed-off-by: Pratyush Anand Suggested-by: Guenter Roeck Reviewed-by: Guenter Roeck As things evolve, I'd by now prefer to move the call to device_create() into watchdog_dev.c, but that can wait for a follow-up patch if Wim is ok with this series. Thanks for your quick review. OK. I will wait for Wim's comment and then may be I will send another version with your comment for patch 1/1 incorporated. Thinking about it, my comment is really minor and should not hold up the series from going forward. So let's just skip another version unless Wim or someone else has any comments. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] mm/swapfile: reduce kswapd overhead by not filling up disks
On 12/11/2015 04:09 PM, Christian Borntraeger wrote:
if a user has more than one swap disk with different priorities, the
swap code will fill up the hight prio disk until the last block is
used.
The swap code will continue to scan the first disk also when its
already filling the 2nd or 3rd disk.
We have seen kswapd running at 100% CPU, with the majority of hits
in the scanning code of scan_swap_map, even for non-rotational disks
when this happens.
For example with 3 disks
disk1 99.9%
disk2 10%
disk3 0%
it will scan the bitmap of disk1 (and as the disk is full the
cluster optimization does not trigger) for every page that will
likely go to disk2 anyway.
By doing a first scan that only uses up to 98%, we force the swap
code to use the 2nd disk slightly earlier, but it reduces kswapd
cpu usage significantly. The 2nd scan will then allow to fill
the remaining 2%, again starting with the highest prio disk.
The code does not affect cases with all the same swap priorities,
unless all disks are about 98% full.
There is one issue with mythis approach: If there is a mix between
same and different priorities, the code will loop too often due
to the requeue, so and idea for a better fix is welcome.
Signed-off-by: Christian Borntraeger
IMHO you should resend with CCing the relevant people directly (e.g. via
./scripts/get_maintainers.pl) or this might simply get lost in
high-volume mailing lists.
Note that I'm not familiar with this code. But my first thought would be
to put a cache with batch-refill/free before the bitmap. During the
"first" round only consider si's with enough free to satisfy the whole
batch-refill.
---
mm/swapfile.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 5887731..d3817cf 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -640,6 +640,7 @@ swp_entry_t get_swap_page(void)
{
struct swap_info_struct *si, *next;
pgoff_t offset;
+ bool first = true;
if (atomic_long_read(_swap_pages) <= 0)
goto noswap;
@@ -653,6 +654,12 @@ start_over:
plist_requeue(>avail_list, _avail_head);
spin_unlock(_avail_lock);
spin_lock(>lock);
+ /* at 98% usage lets try the other swaps */
+ if (first && si->inuse_pages / 98 * 100 > si->pages) {
+ spin_lock(_avail_lock);
+ spin_unlock(>lock);
+ goto nextsi;
+ }
if (!si->highest_bit || !(si->flags & SWP_WRITEOK)) {
spin_lock(_avail_lock);
if (plist_node_empty(>avail_list)) {
@@ -692,6 +699,10 @@ nextsi:
if (plist_node_empty(>avail_list))
goto start_over;
}
+ if (first) {
+ first = false;
+ goto start_over;
+ }
spin_unlock(_avail_lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ALSA: usb-audio: use list_for_each_entry_continue_reverse
For better readability, use list_for_each_entry_continue_reverse()
in have_dup_chmap().
Signed-off-by: Geliang Tang
---
sound/usb/stream.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/sound/usb/stream.c b/sound/usb/stream.c
index 8ee14f2..c4dc577 100644
--- a/sound/usb/stream.c
+++ b/sound/usb/stream.c
@@ -125,11 +125,9 @@ static int usb_chmap_ctl_info(struct snd_kcontrol
*kcontrol,
static bool have_dup_chmap(struct snd_usb_substream *subs,
struct audioformat *fp)
{
- struct list_head *p;
+ struct audioformat *prev = fp;
- for (p = fp->list.prev; p != >fmt_list; p = p->prev) {
- struct audioformat *prev;
- prev = list_entry(p, struct audioformat, list);
+ list_for_each_entry_continue_reverse(prev, >fmt_list, list) {
if (prev->chmap &&
!memcmp(prev->chmap, fp->chmap, sizeof(*fp->chmap)))
return true;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V16 00/11] x86: Intel Cache Allocation Technology Support
On Thu, 17 Dec 2015 14:46:05 -0800 "Fenghua Yu" wrote: > Changes in V16: > - Port to latest upstream kernel > - Add a spin lock to handle contention when writing closid to MSR and >creating closid by a user. Fenghua, Peter, what about all the discussion v15 got about this interface being just wrong? Where's that addressed? - https://lkml.org/lkml/2015/11/18/637 - http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02375.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] efi: add NV memory attribute
(Cc'ing people that have worked in this area recently)
On Thu, 17 Dec, at 07:28:32PM, Robert Elliott wrote:
> Add the NV memory attribute introduced in UEFI 2.5 and add a column
> for it in the types and attributes string used when printing the UEFI
> memory map.
>
> old:
> efi: mem61: [type=14| | | | | | | |WB|WT|WC|UC]
> range=[0x00088000-0x000c7fff) (16384MB)
>
> new:
> efi: mem61: [type=14| | |NV| | | | | |WB|WT|WC|UC]
> range=[0x00088000-0x000c7fff) (16384MB)
>
> Signed-off-by: Robert Elliott
> ---
> drivers/firmware/efi/efi.c | 5 -
> include/linux/efi.h| 1 +
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 027ca21..4dd5464 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -611,13 +611,16 @@ char * __init efi_md_typeattr_format(char *buf, size_t
> size,
> if (attr & ~(EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT |
>EFI_MEMORY_WB | EFI_MEMORY_UCE | EFI_MEMORY_RO |
>EFI_MEMORY_WP | EFI_MEMORY_RP | EFI_MEMORY_XP |
> + EFI_MEMORY_NV |
>EFI_MEMORY_RUNTIME | EFI_MEMORY_MORE_RELIABLE))
> snprintf(pos, size, "|attr=0x%016llx]",
>(unsigned long long)attr);
> else
> - snprintf(pos, size,
> "|%3s|%2s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
> + snprintf(pos, size,
> + "|%3s|%2s|%2s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
>attr & EFI_MEMORY_RUNTIME ? "RUN" : "",
>attr & EFI_MEMORY_MORE_RELIABLE ? "MR" : "",
> + attr & EFI_MEMORY_NV ? "NV" : "",
>attr & EFI_MEMORY_XP ? "XP" : "",
>attr & EFI_MEMORY_RP ? "RP" : "",
>attr & EFI_MEMORY_WP ? "WP" : "",
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 569b5a8..9ce9e9e 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -97,6 +97,7 @@ typedef struct {
> #define EFI_MEMORY_WP((u64)0x1000ULL)/*
> write-protect */
> #define EFI_MEMORY_RP((u64)0x2000ULL)/*
> read-protect */
> #define EFI_MEMORY_XP((u64)0x4000ULL)/*
> execute-protect */
> +#define EFI_MEMORY_NV((u64)0x8000ULL)/*
> non-volatile */
> #define EFI_MEMORY_MORE_RELIABLE \
> ((u64)0x0001ULL)/* higher
> reliability */
> #define EFI_MEMORY_RO((u64)0x0002ULL)/*
> read-only */
Seems straight forward to me.
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3 v2] btrfs: use list_for_each_entry* in backref.c
Use list_for_each_entry*() to simplify the code.
Signed-off-by: Geliang Tang
---
Changes in v2:
- Use list_for_each_entry_safe_continue() in __merge_refs().
---
fs/btrfs/backref.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index d453d62..08405a3 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -520,13 +520,10 @@ static inline int ref_for_same_block(struct __prelim_ref
*ref1,
static int __add_missing_keys(struct btrfs_fs_info *fs_info,
struct list_head *head)
{
- struct list_head *pos;
+ struct __prelim_ref *ref;
struct extent_buffer *eb;
- list_for_each(pos, head) {
- struct __prelim_ref *ref;
- ref = list_entry(pos, struct __prelim_ref, list);
-
+ list_for_each_entry(ref, head, list) {
if (ref->parent)
continue;
if (ref->key_for_search.type)
@@ -563,23 +560,15 @@ static int __add_missing_keys(struct btrfs_fs_info
*fs_info,
*/
static void __merge_refs(struct list_head *head, int mode)
{
- struct list_head *pos1;
+ struct __prelim_ref *ref1;
- list_for_each(pos1, head) {
- struct list_head *n2;
- struct list_head *pos2;
- struct __prelim_ref *ref1;
+ list_for_each_entry(ref1, head, list) {
+ struct __prelim_ref *ref2 = ref1, *tmp;
- ref1 = list_entry(pos1, struct __prelim_ref, list);
-
- for (pos2 = pos1->next, n2 = pos2->next; pos2 != head;
-pos2 = n2, n2 = pos2->next) {
- struct __prelim_ref *ref2;
+ list_for_each_entry_safe_continue(ref2, tmp, head, list) {
struct __prelim_ref *xchg;
struct extent_inode_elem *eie;
- ref2 = list_entry(pos2, struct __prelim_ref, list);
-
if (!ref_for_same_block(ref1, ref2))
continue;
if (mode == 1) {
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] x86/efi: show actual ending addresses in efi_print_memmap
On Thu, 17 Dec, at 07:28:31PM, Robert Elliott wrote: > Adjust efi_print_memmap to print the real end address of each > range, not 1 byte beyond. This matches other prints like those for > SRAT and nosave memory. > > Change the closing ) to ] to match the opening [. > > old: > efi: mem61: [Persistent Memory | | | | | | | |WB|WT|WC|UC] > range=[0x00088000-0x000c8000) (16384MB) > > new: > efi: mem61: [Persistent Memory | | | | | | | |WB|WT|WC|UC] > range=[0x00088000-0x000c7fff] (16384MB) > > Example other address range prints: > SRAT: Node 1 PXM 1 [mem 0x48000-0x87fff] > PM: Registered nosave memory: [mem 0x88000-0xc7fff] > > Signed-off-by: Robert Elliott > --- > arch/x86/platform/efi/efi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Is this change purely for aesthetic reasons? We're usually not in the habit of changing the output of print messages without a good reason because people downstream do rely on them being consistent. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation
On Sat, 19 Dec 2015 22:57:30 -0200 Marcelo Tosatti wrote: > On Sat, Dec 19, 2015 at 11:42:57AM +0100, Thomas Gleixner wrote: > > On Thu, 17 Dec 2015, Fenghua Yu wrote: > > > > > From: Fenghua Yu > > > > > > From: Vikas Shivappa > > > > > > Add a new cgroup 'intel_rdt' to manage cache allocation. Each cgroup > > > directory is associated with a class of service id(closid). To map a > > > task with closid during scheduling, this patch removes the closid field > > > from task_struct and uses the already existing 'cgroups' field in > > > task_struct. > > > > > > The cgroup has a file 'l3_cbm' which represents the L3 cache capacity > > > bitmask(CBM). The CBM is global for the whole system currently. The > > > capacity bitmask needs to have only contiguous bits set and number of > > > bits that can be set is less than the max bits that can be set. The > > > tasks belonging to a cgroup get to fill in the L3 cache represented by > > > the capacity bitmask of the cgroup. For ex: if the max bits in the CBM > > > is 10 and the cache size is 10MB, each bit represents 1MB of cache > > > capacity. > > > > > > Root cgroup always has all the bits set in the l3_cbm. User can create > > > more cgroups with mkdir syscall. By default the child cgroups inherit > > > the capacity bitmask(CBM) from parent. User can change the CBM specified > > > in hex for each cgroup. Each unique bitmask is associated with a class > > > of service ID and an -ENOSPC is returned once we run out of > > > closids. > > > > This is still the original crap. No, we are not introducing this > > interface now just because we can. I explained in great length why > > this is completely useless and what we really need. > > > > Thanks, > > > > tglx > > Can you make a summary of the points, and enumerate them, please. > (what are the problems of the current interface, and why such problems > are fixed in the new interface?). Marcelo, you participated on the discussions. We discussed why this is a bad interface a *lot* in the v15 posting. There are two writeups that summarize all the problems: - https://lkml.org/lkml/2015/11/18/637 - http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02375.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/2] adding PCI support to AXS10x
This patch set has the goal to add suppport for DesignWare PCIe RC in ARC AXS10x. It includes the necessary tweaks to the ARC architecture, necessary tweaks to the PCI subsystem and a new driver (pcie-snpsdev). This new driver will be used extensively in the PCIe RC Prototyping Kit. The patches were produced against Bjorn Helgaas' repository. It was properly tested in an IP Prototyping Kit. Joao Pinto (2): PCI support added to ARC add new platform driver for PCI RC .../devicetree/bindings/pci/pcie-snpsdev.txt | 33 +++ MAINTAINERS| 7 + arch/arc/Kconfig | 23 ++ arch/arc/include/asm/dma.h | 5 + arch/arc/include/asm/io.h | 10 + arch/arc/include/asm/pci.h | 43 arch/arc/kernel/Makefile | 1 + arch/arc/kernel/pcibios.c | 55 arch/arc/mm/ioremap.c | 10 +- arch/arc/plat-axs10x/Kconfig | 1 + drivers/pci/Makefile | 1 + drivers/pci/host/Kconfig | 5 + drivers/pci/host/Makefile | 1 + drivers/pci/host/pcie-designware.c | 11 + drivers/pci/host/pcie-designware.h | 1 + drivers/pci/host/pcie-snpsdev.c| 286 + 16 files changed, 492 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/pci/pcie-snpsdev.txt create mode 100644 arch/arc/include/asm/pci.h create mode 100644 arch/arc/kernel/pcibios.c create mode 100644 drivers/pci/host/pcie-snpsdev.c -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPF in shm_lock ipc
On Thu, Nov 5, 2015 at 3:23 PM, Kirill A. Shutemov
wrote:
> What about this:
Ping. This is still happening for me on tip. Can we pull in this fix
if it looks good to everybody?
> From 06b0fc9d62592f6f3ad9f45cccf1f6a5b3113bdc Mon Sep 17 00:00:00 2001
> From: "Kirill A. Shutemov"
> Date: Thu, 5 Nov 2015 15:53:04 +0200
> Subject: [PATCH] ipc/shm: handle removed segments gracefully in shm_mmap()
>
> remap_file_pages(2) emulation can reach file which represents removed
> IPC ID as long as a memory segment is mapped. It breaks expectations
> of IPC subsystem.
>
> Test case (rewritten to be more human readable, originally autogenerated
> by syzkaller[1]):
>
> #define _GNU_SOURCE
> #include
> #include
> #include
> #include
>
> #define PAGE_SIZE 4096
>
> int main()
> {
> int id;
> void *p;
>
> id = shmget(IPC_PRIVATE, 3 * PAGE_SIZE, 0);
> p = shmat(id, NULL, 0);
> shmctl(id, IPC_RMID, NULL);
> remap_file_pages(p, 3 * PAGE_SIZE, 0, 7, 0);
>
> return 0;
> }
>
> The patch changes shm_mmap() and code around shm_lock() to propagate
> locking error back to caller of shm_mmap().
>
> [1] http://github.com/google/syzkaller
>
> Signed-off-by: Kirill A. Shutemov
> Reported-by: Dmitry Vyukov
> Cc: Davidlohr Bueso
> ---
> ipc/shm.c | 53 +++--
> 1 file changed, 43 insertions(+), 10 deletions(-)
>
> diff --git a/ipc/shm.c b/ipc/shm.c
> index 41787276e141..3174634ca4e5 100644
> --- a/ipc/shm.c
> +++ b/ipc/shm.c
> @@ -156,11 +156,12 @@ static inline struct shmid_kernel *shm_lock(struct
> ipc_namespace *ns, int id)
> struct kern_ipc_perm *ipcp = ipc_lock(_ids(ns), id);
>
> /*
> -* We raced in the idr lookup or with shm_destroy(). Either way, the
> -* ID is busted.
> +* Callers of shm_lock() must validate the status of the returned ipc
> +* object pointer (as returned by ipc_lock()), and error out as
> +* appropriate.
> */
> - WARN_ON(IS_ERR(ipcp));
> -
> + if (IS_ERR(ipcp))
> + return (void *)ipcp;
> return container_of(ipcp, struct shmid_kernel, shm_perm);
> }
>
> @@ -186,18 +187,33 @@ static inline void shm_rmid(struct ipc_namespace *ns,
> struct shmid_kernel *s)
> }
>
>
> -/* This is called by fork, once for every shm attach. */
> -static void shm_open(struct vm_area_struct *vma)
> +static int __shm_open(struct vm_area_struct *vma)
> {
> struct file *file = vma->vm_file;
> struct shm_file_data *sfd = shm_file_data(file);
> struct shmid_kernel *shp;
>
> shp = shm_lock(sfd->ns, sfd->id);
> +
> + if (IS_ERR(shp))
> + return PTR_ERR(shp);
> +
> shp->shm_atim = get_seconds();
> shp->shm_lprid = task_tgid_vnr(current);
> shp->shm_nattch++;
> shm_unlock(shp);
> + return 0;
> +}
> +
> +/* This is called by fork, once for every shm attach. */
> +static void shm_open(struct vm_area_struct *vma)
> +{
> + int err = __shm_open(vma);
> + /*
> +* We raced in the idr lookup or with shm_destroy().
> +* Either way, the ID is busted.
> +*/
> + WARN_ON_ONCE(err);
> }
>
> /*
> @@ -260,6 +276,14 @@ static void shm_close(struct vm_area_struct *vma)
> down_write(_ids(ns).rwsem);
> /* remove from the list of attaches of the shm segment */
> shp = shm_lock(ns, sfd->id);
> +
> + /*
> +* We raced in the idr lookup or with shm_destroy().
> +* Either way, the ID is busted.
> +*/
> + if (WARN_ON_ONCE(IS_ERR(shp)))
> + goto done; /* no-op */
> +
> shp->shm_lprid = task_tgid_vnr(current);
> shp->shm_dtim = get_seconds();
> shp->shm_nattch--;
> @@ -267,6 +291,7 @@ static void shm_close(struct vm_area_struct *vma)
> shm_destroy(ns, shp);
> else
> shm_unlock(shp);
> +done:
> up_write(_ids(ns).rwsem);
> }
>
> @@ -388,17 +413,25 @@ static int shm_mmap(struct file *file, struct
> vm_area_struct *vma)
> struct shm_file_data *sfd = shm_file_data(file);
> int ret;
>
> + /*
> +* In case of remap_file_pages() emulation, the file can represent
> +* removed IPC ID: propogate shm_lock() error to caller.
> +*/
> + ret =__shm_open(vma);
> + if (ret)
> + return ret;
> +
> ret = sfd->file->f_op->mmap(sfd->file, vma);
> - if (ret != 0)
> + if (ret) {
> + shm_close(vma);
> return ret;
> + }
> sfd->vm_ops = vma->vm_ops;
> #ifdef CONFIG_MMU
> WARN_ON(!sfd->vm_ops->fault);
> #endif
> vma->vm_ops = _vm_ops;
> - shm_open(vma);
> -
> - return ret;
> + return 0;
> }
>
> static int
[PATCH v3 2/2] add new platform driver for PCI RC
This patch adds a new driver that will be the reference platform driver for all
PCI RC IP Protoyping Kits based on ARC SDP. This patch is composed by:
-Changes to pcie-designware driver add a function that enables the feature of
starting the LTSSM (Link Train Status State) used by the new driver
-MAINTAINERS file was updated to include the new driver
-Documentation/devicetree/bindings/pci was updated to include the new driver
documentation
-New driver called pcie-snpsdev
Signed-off-by: Joao Pinto
---
Changes v2 -> v3:
- link init stuff was moved to a snpsdev_pcie_establish_link() function in
pcie-snpsdev (Bjorn Helgaas)
- pcie-snpsdev driver declaration was changed to be more
standard (Bjorn Helgaas)
- pcie-designware' dw_pcie_link_retrain() now use standard registers from
pci-regs.h (Bjorn Helgaas)
- pcie-snpsdev.txt was complemented with more info (Mark Rutland)
Changes v1 -> v2 (Bjorn Helgaas):
- Fixups snpsdev_pcie_fixup_bridge() and snpsdev_pcie_fixup_res() were removed
from the driver (these functions were for specific tests only and not usefull
in mainline)
- Driver' comments were reviewed (fix Typos and excessive comments removal)
- Removed unnecessary definitions in the driver source (PCIE_PHY_CTRL and
PCIE_PHY_STAT)
.../devicetree/bindings/pci/pcie-snpsdev.txt | 33 +++
MAINTAINERS| 7 +
drivers/pci/host/Kconfig | 5 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-designware.c | 11 +
drivers/pci/host/pcie-designware.h | 1 +
drivers/pci/host/pcie-snpsdev.c| 286 +
7 files changed, 344 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/pcie-snpsdev.txt
create mode 100644 drivers/pci/host/pcie-snpsdev.c
diff --git a/Documentation/devicetree/bindings/pci/pcie-snpsdev.txt
b/Documentation/devicetree/bindings/pci/pcie-snpsdev.txt
new file mode 100644
index 000..cae548b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pcie-snpsdev.txt
@@ -0,0 +1,33 @@
+Synopsys PCI RC IP Prototyping Kit
+--
+
+This is the reference platform driver to be used in the Synopsys PCI Root
+Complex IP Prototyping Kit.
+
+Required properties:
+- compatible: set to "snps,pcie-snpsdev";
+- reg: base address and length of the pcie controller registers.
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- device_type: set to "pci"
+- ranges: ranges for the PCI memory and I/O regions.
+- interrupts: one interrupt source for MSI interrupts, followed by interrupt
+ source for hardware related interrupts.
+- #interrupt-cells: set to <1>
+- num-lanes: set to <1>;
+
+Example configuration:
+
+ pcie: pcie@0xd000 {
+ compatible = "snps,pcie-snpsdev";
+ reg = <0xd000 0x1000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges = <0x0800 0 0xd000 0xd000 0 0x2000>,
+<0x8100 0 0x 0xde00 0 0x0001>,
+<0x8200 0 0xd040 0xd040 0 0x0d00>;
+ interrupts = <25>, <24>;
+ #interrupt-cells = <1>;
+ num-lanes = <1>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index e9caa4b..d2e4506 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8230,6 +8230,13 @@ S: Maintained
F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
F: drivers/pci/host/pcie-hisi.c
+PCI DRIVER FOR SYNOPSYS PROTOTYPING DEVICE
+M: Joao Pinto
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/pcie-snpsdev.txt
+F: drivers/pci/host/pcie-snpsdev.c
+
PCMCIA SUBSYSTEM
P: Linux PCMCIA Team
L: linux-pcm...@lists.infradead.org
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index f131ba9..a874b1e 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -172,4 +172,9 @@ config PCI_HISI
help
Say Y here if you want PCIe controller support on HiSilicon HIP05 SoC
+config PCIE_SNPSDEV
+ bool "Platform Driver for Synopsys Device"
+ select PCIEPORTBUS
+ select PCIE_DW
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 9d4d3c6..e422f65 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
+obj-$(CONFIG_PCIE_SNPSDEV) += pcie-snpsdev.o
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 540f077..99fad62 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -22,6 +22,8 @@
#include
#include
[PATCH v3 1/2] PCI support added to ARC
This patch adds PCI support to ARC and updates drivers/pci Makefile enabling
the ARC arch to use the generic PCI setup functions.
Signed-off-by: Joao Pinto
---
Change v2 -> v3 (Bjorn Helgaas):
- arch/arc/kernel/pcibios.c unused functions were removed and also the
arch/arc/include/asm/mach/pci.h was removed because was no longer necessary
Change v1 -> v2:
- In arch/arc/Kconfig, the new menu entry (Bus Configuration) was moved to the
slot between sourcing of drivers/Kconfig and fs/Kconfig (Vineet Gupta)
- In arch/arc/plat-axs10x/Kconfig the "select MIGHT_HAVE_PCI" option was placed
in order as suggested (Vineet Gupta)
- ioport_map() and ioport_unmap() were static inlined and included in
the io.h (Vineet Gupta)
- pcibios_min_io and pcibios_min_mem declaration moved to
pcibios.c (Vineet Gupta)
- pr_err() replaced by dev_err() in pcibios_enable_device() (Bjorn Helgaas)
- string simplified in pcibios_enable_device() (Vineet Gupta)
- pci_host_bridge_window structure was replaced by resource_entry structure, and
list_for_each_entry() for resource_list_for_each_entry() in pcibios.c
arch/arc/Kconfig | 23 ++
arch/arc/include/asm/dma.h | 5
arch/arc/include/asm/io.h| 10
arch/arc/include/asm/pci.h | 43 ++
arch/arc/kernel/Makefile | 1 +
arch/arc/kernel/pcibios.c| 55
arch/arc/mm/ioremap.c| 10 +++-
arch/arc/plat-axs10x/Kconfig | 1 +
drivers/pci/Makefile | 1 +
9 files changed, 148 insertions(+), 1 deletion(-)
create mode 100644 arch/arc/include/asm/pci.h
create mode 100644 arch/arc/kernel/pcibios.c
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 2c2ac3f..98b32c1 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -19,6 +19,7 @@ config ARC
select GENERIC_FIND_FIRST_BIT
# for now, we don't need GENERIC_IRQ_PROBE, CONFIG_GENERIC_IRQ_CHIP
select GENERIC_IRQ_SHOW
+ select GENERIC_PCI_IOMAP
select GENERIC_PENDING_IRQ if SMP
select GENERIC_SMP_IDLE_THREAD
select HAVE_ARCH_KGDB
@@ -39,6 +40,9 @@ config ARC
select PERF_USE_VMALLOC
select HAVE_DEBUG_STACKOVERFLOW
+config MIGHT_HAVE_PCI
+ bool
+
config TRACE_IRQFLAGS_SUPPORT
def_bool y
@@ -570,6 +574,25 @@ endmenu # "ARC Architecture Configuration"
source "mm/Kconfig"
source "net/Kconfig"
source "drivers/Kconfig"
+
+menu "Bus Support"
+
+config PCI
+ bool "PCI support" if MIGHT_HAVE_PCI
+ help
+ PCI is the name of a bus system, i.e. the way the CPU talks to the
other stuff inside
+ your box.Find out if your board/platform have PCI.
+ Note: PCIE support for Synopsys Device will be available only when
+ HAPS DX is configured with PCIE RC bitmap. If you have PCI, say Y,
otherwise N.
+
+config PCI_SYSCALL
+ def_bool PCI
+
+source "drivers/pci/Kconfig"
+source "drivers/pci/pcie/Kconfig"
+
+endmenu
+
source "fs/Kconfig"
source "arch/arc/Kconfig.debug"
source "security/Kconfig"
diff --git a/arch/arc/include/asm/dma.h b/arch/arc/include/asm/dma.h
index ca7c451..37942fa 100644
--- a/arch/arc/include/asm/dma.h
+++ b/arch/arc/include/asm/dma.h
@@ -10,5 +10,10 @@
#define ASM_ARC_DMA_H
#define MAX_DMA_ADDRESS 0xC000
+#ifdef CONFIG_PCI
+extern int isa_dma_bridge_buggy;
+#else
+#define isa_dma_bridge_buggy(0)
+#endif
#endif
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index 694ece8..2ec3cf4 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -16,7 +16,17 @@
extern void __iomem *ioremap(unsigned long physaddr, unsigned long size);
extern void __iomem *ioremap_prot(phys_addr_t offset, unsigned long size,
unsigned long flags);
+static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
+{
+ return (void __iomem *)port;
+}
+
+static inline void ioport_unmap(void __iomem *addr)
+{
+}
+
extern void iounmap(const void __iomem *addr);
+extern int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr);
#define ioremap_nocache(phy, sz) ioremap(phy, sz)
#define ioremap_wc(phy, sz)ioremap(phy, sz)
diff --git a/arch/arc/include/asm/pci.h b/arch/arc/include/asm/pci.h
new file mode 100644
index 000..a0a0fa5
--- /dev/null
+++ b/arch/arc/include/asm/pci.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2015-2016 Synopsys, Inc. (www.synopsys.com)
+ *
+ * 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 Software Foundation.
+ */
+
+#ifndef _ASM_ARC_PCI_H
+#define _ASM_ARC_PCI_H
+
+#ifdef __KERNEL__
+#include
+#include
+
+#include
+
+extern unsigned long pcibios_min_io;
+#define PCIBIOS_MIN_IO pcibios_min_io
+extern unsigned long pcibios_min_mem;
+#define PCIBIOS_MIN_MEM pcibios_min_mem
+
+#define pcibios_assign_all_busses()1
Re: [PATCH 1/6] perf, tools, stat: Abstract stat metrics printing
On Mon, Dec 14, 2015 at 06:04:14PM -0800, Andi Kleen wrote:
SNIP
> -double avg, int cpu, enum aggr_mode aggr)
> +void perf_stat__print_shadow_stats(struct perf_evsel *evsel,
> +double avg, int cpu,
> +struct perf_stat_output_ctx *out)
> {
> + void *ctxp = out->ctx;
> + print_metric_t print_metric = out->print_metric;
> double total, ratio = 0.0, total2;
> int ctx = evsel_context(evsel);
>
> @@ -307,119 +302,145 @@ void perf_stat__print_shadow_stats(FILE *out, struct
> perf_evsel *evsel,
> total = avg_stats(_cycles_stats[ctx][cpu]);
> if (total) {
> ratio = avg / total;
> - fprintf(out, " # %5.2f insns per cycle",
> ratio);
> + print_metric(ctxp, NULL, "%7.2f ",
> + "insn per cycle", ratio);
> } else {
> - fprintf(out, " ");
> + print_metric(ctxp, NULL, NULL, "insn per cycle", 0);
> }
> total =
> avg_stats(_stalled_cycles_front_stats[ctx][cpu]);
> total = max(total,
> avg_stats(_stalled_cycles_back_stats[ctx][cpu]));
>
> + out->new_line(ctxp);
> if (total && avg) {
> ratio = total / avg;
> - fprintf(out, "\n");
you haven't address my first comment in here
http://marc.info/?l=linux-kernel=144662610723134=2
also please rebase to latest acme/perf/core
FYI there's been some stat changes, but your branch cleanly rebased for me
thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: next-20151221 build: 2 failures 13 warnings (next-20151221)
On Mon, Dec 21, 2015 at 03:05:33PM +0100, Arnd Bergmann wrote: Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > Just looking at the remaining warnings/errors in linux-next: > > Warnings: > > :1307:2: warning: #warning syscall copy_file_range not > > implemented [-Wcpp] > Not sure how we can improve this, the same thing seems to happen every time a > new syscall gets > introduced. The actual change is trivial, but we need a better method to sync > all architectures. Now we've got the warning count down sufficiently the autobuilders may actually be just fine here. > > arm-multi_v7_defconfig : PASS, 0 errors, 8 warnings, 0 section mismatches > > Warnings: > > arch/arm/configs/multi_v7_defconfig:433:warning: symbol value 'm' > > invalid for MFD_DA9063 > I need to look into this, probably the result of a defconfig change we > merged, but it's not > clear whether the driver should be a module, or the defconfig should have it > built-in. The driver should at least support building modularly, there was a patch sent to MFD IIRC but I guess it's not applied yet (Lee is on vacation I believe which probably won't help). signature.asc Description: PGP signature
Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
> On Monday 21 December 2015, Tomasz Nowicki wrote: >> On 21.12.2015 13:10, Lorenzo Pieralisi wrote: >> > On Fri, Dec 18, 2015 at 06:56:39PM +, ok...@codeaurora.org wrote: > >> >> I have multiple root ports with the same IO port configuration in the >> >> current ACPI table. >> >> >> >> Root port 0 = IO range 0x1000-0x10FFF >> >> Root port 1 = IO range 0x1000-0x10FFF >> >> Root port 2 = IO range 0x1000-0x10FFF >> > >> > It is fine. You end up mapping for each of those a 4k window of the >> > virtual address space allocated to IO and that's what you will have in >> > the kernel PCI resources (not in the HW BARs though). If that was a >> problem >> > it would be even for the current DT host controllers eg: >> > >> > arch/arm64/boot/dts/apm/apm-storm.dtsi >> > >> > it should not be (again I will let Arnd comment on this since he may >> be >> > aware of issues encountered on other arches/platforms). >> > >> >> Root port 0 = IO range 0x1000-0x10FFF >> Root port 1 = IO range 0x1000-0x10FFF >> Root port 2 = IO range 0x1000-0x10FFF >> >> If above ranges are mapped into different CPU windows, then yes, it is >> fine. > > Ideally, they should all be the same CPU address so we only have to map > the window > once, each device gets an address below 64K, and you can have legacy port > numbers > (below 4K) on any bus, which is required to make certain GPUs work. > > I haven't actually seen anyone do that on ARM though, every implementation > so > far has a separate mapping per host bridge, and we can cope with that too, > and we can live with either overlapping bus addresses or unique bus > addresses, > any of them can be expressed by the PCI core in Linux, we just have to > make sure > that we correctly translate the firmware tables into our internal > structures. > > Arnd > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Thanks, I won't be touching the acpi tables then and I will assume the hack had a problem. It was trying to remap the io range of the second root port to the first port io address map. I was getting a warning from resource.c Btw, when I tested the io ranges before, kernel didn't accept anything below 1k like 0. That is why my range starts at 1k. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes:
> On 12/21/2015 9:24 AM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>> P.S. Anyway we have to ask Julian to try the kernel with
>> 8b3444852a2b58129 reverted.
>>
> git revert 8b3444852a2b58129
> error: could not revert 8b34448... sata_dwc_460ex: move to generic DMA
> driver
> hint: after resolving the conflicts, mark the corrected paths
> hint: with 'git add ' or 'git rm '
> hint: and commit the result with 'git commit'
Yeah, that won't work since there are numerous changes afterward. Just
revert the entire file back to 4.0 like this:
$ git checkout v4.0 drivers/ata/sata_dwc_460ex.c
>>> CC [M] drivers/ata/sata_dwc_460ex.o
>>> drivers/ata/sata_dwc_460ex.c:467:36: error: macro
>>> "dma_request_channel" requires 3 arguments, but only 1 given
>>> static int dma_request_channel(void)
>>> ^
>>> drivers/ata/sata_dwc_460ex.c:468:1: error: expected ‘=’, ‘,’,
>>> ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
>>> {
>>> ^
>>> drivers/ata/sata_dwc_460ex.c: In function ‘dma_dwc_xfer_setup’:
>>> drivers/ata/sata_dwc_460ex.c:758:31: error: macro
>>> "dma_request_channel" requires 3 arguments, but only 1 given
>>>dma_ch = dma_request_channel();
>>> ^
>>> drivers/ata/sata_dwc_460ex.c:758:11: error: ‘dma_request_channel’
>>> undeclared (first use in this function)
>>>dma_ch = dma_request_channel();
>>> ^
>>> drivers/ata/sata_dwc_460ex.c:758:11: note: each undeclared identifier
>>> is reported only once for each function it appears in
>>> drivers/ata/sata_dwc_460ex.c: In function ‘sata_dwc_dma_filter’:
>>> drivers/ata/sata_dwc_460ex.c:1282:35: error: ‘struct
>>> sata_dwc_device_port’ has no member named ‘dws’
>>>struct dw_dma_slave *dws = hsdevp->dws;
>>> ^
>>> drivers/ata/sata_dwc_460ex.c: In function ‘sata_dwc_port_start’:
>>> drivers/ata/sata_dwc_460ex.c:1325:17: warning: unused variable
>>> ‘mask’ [-Wunused-variable]
>>>dma_cap_mask_t mask;
>>> ^
>>> drivers/ata/sata_dwc_460ex.c: At top level:
>>> drivers/ata/sata_dwc_460ex.c:345:28: warning: ‘sata_dwc_dma_dws’
>>> defined but not used [-Wunused-variable]
>>> static struct dw_dma_slave sata_dwc_dma_dws = {
>>> ^
>>> drivers/ata/sata_dwc_460ex.c:1279:13: warning:
>>> ‘sata_dwc_dma_filter’ defined but not used [-Wunused-function]
>>> static bool sata_dwc_dma_filter(struct dma_chan *chan, void *param)
>>> ^
>> Those messages do not match the contents of the file from v4.0.
>> For your convenience, here's the file as it should be.
>>
>> $ sha1sum drivers/ata/sata_dwc_460ex.c
>> 0f54dfa3a91591101f5de434c3a631a5cd20ff1a drivers/ata/sata_dwc_460ex.c
>
> [ 16.119186] BUG: spinlock recursion on CPU#0, kworker/u2:1/85
> [ 16.124935] lock: 0xedd2f910, .magic: dead4ead, .owner: kworker/u2:1/85,
> .owner_cpu: 0
> [ 16.132947] CPU: 0 PID: 85 Comm: kworker/u2:1 Not tainted
> 4.4.0-rc5-Sam460ex-dirty #3
> [ 16.140793] Workqueue: events_unbound async_run_entry_fn
> [ 16.146119] Call Trace:
> [ 16.148582] [ee3cf8c0] [c0049238] do_raw_spin_lock+0x4c/0x100 (unreliable)
> [ 16.155491] [ee3cf8e0] [c068af98] _raw_spin_lock_irqsave+0x2c/0x38
> [ 16.161721] [ee3cf8f0] [f6a0fd98]
> sata_dwc_exec_command_by_tag.constprop.9+0x80/0xb4 [sata_dwc_460ex]
> [ 16.170954] [ee3cf920] [f6a108c0] sata_dwc_qc_issue+0x6a4/0x6c4
> [sata_dwc_460ex]
> [ 16.178380] [ee3cf9d0] [c043bdf8] ata_qc_issue+0x338/0x3a0
> [ 16.183883] [ee3cfa00] [c0440c84] ata_scsi_translate+0xf4/0x150
> [ 16.189813] [ee3cfa20] [c0444080] ata_scsi_queuecmd+0x1e8/0x238
> [ 16.195750] [ee3cfa40] [c042511c] scsi_dispatch_cmd+0xd4/0x110
> [ 16.201602] [ee3cfa50] [c0427a9c] scsi_request_fn+0x52c/0x55c
Oh, that one again. My patch still applies. Here it is as applied to
that revision of the file.
>From what I can tell, that bug has always been there. Probably nobody
ever tested the driver in a PREEMPT or SMP build, nor with lock
debugging enabled.
--
Måns Rullgård
>From 53f3cf096f959a58fe6339f4f8b57b6e749b283e Mon Sep 17 00:00:00 2001
From: Mans Rullgard
Date: Sat, 19 Dec 2015 15:26:23 +
Subject: [PATCH] ata: sata_dwc_460ex: remove incorrect locking
This lock is already taken in ata_scsi_queuecmd() a few levels up the
call stack so attempting to take it here is an error. Moreover, it is
pointless in the first place since it only protects a single, atomic
assignment.
Signed-off-by: Mans Rullgard
---
drivers/ata/sata_dwc_460ex.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
index fdb0f28..d404af8 100644
--- a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -1403,15 +1403,13 @@ static void sata_dwc_exec_command_by_tag(struct ata_port
Re: [PATCH v3] serial: 8250: add gpio support to exar
On Sun, Dec 20, 2015 at 05:42:08PM +, One Thousand Gnomes wrote: > > So then should I rewrite it as MFD or should it be like the way you > > suggested in the other mail to have it as bool in the Kconfig and combine > > the file with 8250_pci.c when the symbol is selected? > > Yes although I'm really not sure which is the best approach of the two. Hi Alan and Andy, I was trying like: diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig index 6412f14..ec3d287 100644 --- a/drivers/tty/serial/8250/Kconfig +++ b/drivers/tty/serial/8250/Kconfig @@ -378,3 +378,11 @@ config SERIAL_8250_MID Selecting this option will enable handling of the extra features present on the UART found on Intel Medfield SOC and various other Intel platforms. + +config SERIAL_8250_EXAR_GPIO + bool "Support for GPIO pins on XR17V352/354/358" + depends on SERIAL_8250_PCI && GPIOLIB + select GPIO_SYSFS + help + Selecting this option will enable handling of GPIO pins present + on Exar XR17V352/354/358 chips. diff --git a/drivers/tty/serial/8250/Makefile b/drivers/tty/serial/8250/Makefile index e177f86..1d0fce0 100644 --- a/drivers/tty/serial/8250/Makefile +++ b/drivers/tty/serial/8250/Makefile @@ -28,5 +28,8 @@ obj-$(CONFIG_SERIAL_8250_MT6577) += 8250_mtk.o obj-$(CONFIG_SERIAL_8250_UNIPHIER) += 8250_uniphier.o obj-$(CONFIG_SERIAL_8250_INGENIC) += 8250_ingenic.o obj-$(CONFIG_SERIAL_8250_MID) += 8250_mid.o +obj-$(CONFIG_SERIAL_8250_EXAR_GPIO)+= exar_gpio.o +exar_gpio-y:= 8250_pci.o 8250_gpio.o + CFLAGS_8250_ingenic.o += -I$(srctree)/scripts/dtc/libfdt But I am getting: ERROR: "xr17v35x_gpio_exit" [drivers/tty/serial/8250/8250_pci.ko] undefined! ERROR: "xr17v35x_gpio_init" [drivers/tty/serial/8250/8250_pci.ko] undefined! I will need little hint for the Makefile, please. Its clear that i have messed up. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Describe the shared memory usage/accounting
On 11/19/2015 07:58 PM, Rodrigo Freire wrote:
The Shared Memory accounting support is present in Kernel since
commit 4b02108ac1b3 ("mm: oom analysis: add shmem vmstat") and in userland
free(1) since 2014. This patch updates the Documentation to reflect
this change.
Signed-off-by: Rodrigo Freire
You should send to Andrew Morton and maybe CC Hugh Dickins at the very
least. Sending just to mailing list doesn't guarantee maintainers will
pick it up due to the high volume there.
Also note that your RESEND has broken whitespace.
---
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -842,6 +842,7 @@
Writeback: 0 kB
AnonPages: 861800 kB
Mapped: 280372 kB
+Shmem: 644 kB
Slab: 284364 kB
SReclaimable: 159856 kB
SUnreclaim: 124508 kB
@@ -898,6 +899,7 @@
AnonPages: Non-file backed pages mapped into userspace page tables
AnonHugePages: Non-file backed huge pages mapped into userspace page tables
Mapped: files which have been mmaped, such as libraries
+ Shmem: Total memory used by shared memory (shmem) and tmpfs
Slab: in-kernel data structures cache
SReclaimable: Part of Slab, that might be reclaimed, such as caches
SUnreclaim: Part of Slab, that cannot be reclaimed on memory pressure
--- a/Documentation/filesystems/tmpfs.txt
+++ b/Documentation/filesystems/tmpfs.txt
@@ -17,10 +17,10 @@
cannot swap and you do not have the possibility to resize them.
Since tmpfs lives completely in the page cache and on swap, all tmpfs
-pages currently in memory will show up as cached. It will not show up
-as shared or something like that. Further on you can check the actual
-RAM+swap use of a tmpfs instance with df(1) and du(1).
-
+pages will be shown in /proc/meminfo as "Shmem" and "Shared" in
It would be IMHO clearer if it said:
... will be shown as "Shmem" in /proc/meminfo and "Shared" in ...
+free(1). Notice that shared memory pages (see ipcs(1)) will be also
> +counted as shared memory.
Too much of "shared memory" here. Maybe something like:
"However, these counters also include shared memory (shmem)."
The most reliable way to get the count is
+using df(1) and du(1).
tmpfs has the following uses:
---
1.7.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] can: sja1000: add documentation for Technologic Systems version
On Sat, Dec 19, 2015 at 09:37:42PM -0600, Rob Herring wrote: > On Fri, Dec 18, 2015 at 03:17:24PM -0500, Damien Riegel wrote: > > This commit adds documentation for the Technologic Systems version of > > SJA1000. The difference with the NXP version is in the way the registers > > are accessed. > > > > Signed-off-by: Damien Riegel > > --- > > Documentation/devicetree/bindings/net/can/sja1000.txt | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/net/can/sja1000.txt > > b/Documentation/devicetree/bindings/net/can/sja1000.txt > > index b4a6d53..7a158d5 100644 > > --- a/Documentation/devicetree/bindings/net/can/sja1000.txt > > +++ b/Documentation/devicetree/bindings/net/can/sja1000.txt > > @@ -2,7 +2,7 @@ Memory mapped SJA1000 CAN controller from NXP (formerly > > Philips) > > > > Required properties: > > > > -- compatible : should be "nxp,sja1000". > > +- compatible : should be one of "nxp,sja1000", "technologic,sja1000". > > > > - reg : should specify the chip select, address offset and size required > > to map the registers of the SJA1000. The size is usually 0x80. > > @@ -14,6 +14,7 @@ Optional properties: > > > > - reg-io-width : Specify the size (in bytes) of the IO accesses that > > should be performed on the device. Valid value is 1, 2 or 4. > > + Must be set to 2 for technologic version. > > Default to 1 (8 bits). > > Really, this should default to 2 for technologic version and not be > required. Would something along the line of "This property is for technologic version." be more appropriate? Thanks, Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Indent issus in kernel module development
On 2015-12-20 07:52, chunguang qu wrote: I tried it. Not worked unfortunately,. ```bash $ ~/share/linux/scripts/checkpatch.pl --fix --types=spacing testcompletion.c total: 0 errors, 0 warnings, 0 lines checked testcompletion.c has no obvious style problems and is ready for submission. NOTE: Used message types: SPACING ``` You might try something with clang-format. It doesn't have a built-in style option for the kernel (probably because the kernel can't currently be compiled with Clang/LLVM, but Linux does qualify for the first two criteria for having a new style default added, so if someone wants to actually work on it, they could probably get it included), but something like this for the config should get you pretty close: BasedOnStyle: LLVM IndentWidth: 8 UseTab: Always BreakBeforeBraces: Linux AllowShortIfStatementOnASingleLine: false IndentCaseLabels: false I'm pretty certain that this doesn't cover everything from CodingStyle, but it should cover most things, and most of the other stuff should be relatively easily scriptable using regex based replacements. 2015-12-19 14:16 GMT+08:00 Joe Perches : On Sat, 2015-12-19 at 13:50 +0800, chunguang qu wrote: Yes, I just tried `scripts/Lindent` and it has the same problem. I had compared the source of `Lindent` with `-linux` option of `indent` long time ago, there's seems no major difference. So i used `indent -linux ` above. Thanks for your advice about `emace`, but `vi` is my only editor for dozens of years. Try: $ ./scripts/checkpatch.pl --fix --types=spacing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [media] cx231xx: fix compilation when !CONFIG_MEDIA_CONTROLLER
Commit 1590ad7b5271 ("[media] media-device: split media initialization
and registration") split the media dev initialization and registration
but introduced a build error since media_device_register() was called
unconditionally even when the MEDIA_CONTROLLER config was not enabled:
drivers/media/usb/cx231xx/cx231xx-cards.c: In function 'cx231xx_usb_probe':
drivers/media/usb/cx231xx/cx231xx-cards.c:1741:36: error: 'struct cx231xx'
has no member named 'media_dev'
retval = media_device_register(dev->media_dev);
Fixes: 1590ad7b5271 ("[media] media-device: split media initialization and
registration")
Reported-by: Fengguang Wu
Signed-off-by: Javier Martinez Canillas
---
drivers/media/usb/cx231xx/cx231xx-cards.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index 35692d19b652..220a5dba8a2d 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -1751,7 +1751,9 @@ static int cx231xx_usb_probe(struct usb_interface
*interface,
if (retval < 0)
goto done;
+#ifdef CONFIG_MEDIA_CONTROLLER
retval = media_device_register(dev->media_dev);
+#endif
done:
if (retval < 0)
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/14] batman-adv: use list_for_each_entry_safe
Hi Geliang,
> static int batadv_socket_release(struct inode *inode, struct file *file)
> {
> - struct batadv_socket_client *socket_client = file->private_data;
> - struct batadv_socket_packet *socket_packet;
> - struct list_head *list_pos, *list_pos_tmp;
> + struct batadv_socket_client *client = file->private_data;
> + struct batadv_socket_packet *packet, *tmp;
>
[...]
> + list_for_each_entry_safe(packet, tmp, >queue_list, list) {
I guess you renamed those variables to make sure that the statement
above would fit in 80 chars.. in that case the patch looks good.
Acked-by: Antonio Quartulli
--
Antonio Quartulli
signature.asc
Description: OpenPGP digital signature
[PATCH 3/3] powercap, intel_rapl, Add ignore_max_time_window_check module parameter for broken BIOSes
Some systems erroneously set the maximum time window field of
MSR_PKG_POWER_INFO register to 0. This results in a user not being able
to set the time windows for the package. In some cases, however, RAPL
will still continue to work with a small window (albeit through some
trial and error). This patch adds a ignore_max_time_window_check module
parameter to avoid the maximum time window check in set_time_window().
[v2]: change name to max_time_window_check, fix (val == 0) check
Cc: "Rafael J. Wysocki"
Cc: Prarit Bhargava
Cc: Radivoje Jovanovic
Cc: Seiichi Ikarashi
Cc: Mathias Krause
Cc: Ajay Thomas
Signed-off-by: Prarit Bhargava
---
drivers/powercap/intel_rapl.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index 14753e5..939026d 100644
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@ -505,13 +505,24 @@ static int get_max_time_window(struct powercap_zone
*power_zone, int id,
if (rapl_read_data_raw(rd, MAX_TIME_WINDOW, true, ))
ret = -EIO;
- else
+ else {
*data = val;
-
+ if (val == 0)
+ pr_warn_once(FW_BUG "intel_rapl: Maximum Time Window is
zero. This is a BIOS bug that should be reported to your hardware or BIOS
vendor. The value of zero may prevent Intel RAPL from functioning properly.
Most bugs can be avoided by setting the ignore_max_window_check module
parameter.\n");
+ }
put_online_cpus();
return ret;
}
+/* Some BIOSes incorrectly program the maximum time window in the
+ * MSR_PKG_POWER_INFO register. Some of these systems still have functional
+ * RAPL registers, etc., so give the user the option of disabling the maximum
+ * time window check.
+ */
+static int ignore_max_time_window_check;
+module_param(ignore_max_time_window_check, int, 0444);
+MODULE_PARM_DESC(ignore_max_time_window_check, "Ignore maximum time window
check. A bug should be reported to your hardware or BIOS vendor if this
parameter is used.");
+
static int set_time_window(struct powercap_zone *power_zone, int id,
u64 window)
{
@@ -532,7 +543,8 @@ static int set_time_window(struct powercap_zone
*power_zone, int id,
* The MSR_RAPL_POWER_UNIT register, read during initialization,
* does contain the smallest unit of time that can be measured.
*/
- if ((window > max_window) || (window < rp->time_unit)) {
+ if ((!ignore_max_time_window_check && (window > max_window)) ||
+ (window < rp->time_unit)) {
ret = -EINVAL;
goto out;
}
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 2/2] dt-bindings: sound: add devicetree document for rt5616
Add the description for rt5616 codec.
Signed-off-by: Caesar Wang
---
Changes in v1:
- As Heiko comments, remove the not exist option properties.
Documentation/devicetree/bindings/sound/rt5616.txt | 36 ++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/rt5616.txt
diff --git a/Documentation/devicetree/bindings/sound/rt5616.txt
b/Documentation/devicetree/bindings/sound/rt5616.txt
new file mode 100644
index 000..2030a22
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rt5616.txt
@@ -0,0 +1,36 @@
+RT5616 audio CODEC
+
+This device supports I2C only.
+
+Required properties:
+
+- compatible : "realtek,rt5616".
+
+- reg : The I2C address of the device.
+
+Pins on the device (for linking into audio routes) for RT5616:
+
+ * IN1P
+ * IN2P
+ * IN2N
+ * LOUTL
+ * LOUTR
+ * CPN2
+ * CPP2
+ * CPN1
+ * CPP1
+ * HPO_R
+ * HPO_L
+ * ADCDAT1
+ * DACDAT1
+ * LRCK1
+ * BCLK1
+ * MCLK
+ * GPIO1
+
+Example:
+
+rt5616 {
+ compatible = "realtek,rt5616";
+ reg = <0x1b>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] serial: amba-pl011: add ACPI support to AMBA probe
From: Graeme Gregory
In ACPI this device is only defined in SBSA mode so
if we are coming from ACPI use this mode.
Signed-off-by: Graeme Gregory
Signed-off-by: Aleksey Makarov
---
drivers/tty/serial/amba-pl011.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 899a771..766ce4f 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2368,18 +2368,33 @@ static int pl011_probe(struct amba_device *dev, const
struct amba_id *id)
if (!uap)
return -ENOMEM;
- uap->clk = devm_clk_get(>dev, NULL);
- if (IS_ERR(uap->clk))
- return PTR_ERR(uap->clk);
-
- uap->vendor = vendor;
- uap->lcrh_rx = vendor->lcrh_rx;
- uap->lcrh_tx = vendor->lcrh_tx;
- uap->fifosize = vendor->get_fifosize(dev);
- uap->port.irq = dev->irq[0];
- uap->port.ops = _pl011_pops;
+ /* ACPI only defines SBSA variant */
+ if (ACPI_COMPANION(>dev)) {
+ /*
+* According to ARM ARMH0011 is currently the only mapping
+* of pl011 in ACPI and it's mapped to SBSA UART mode
+*/
+ uap->vendor = _sbsa;
+ uap->fifosize = 32;
+ uap->port.ops = _uart_pops;
+ uap->fixed_baud = 115200;
- snprintf(uap->type, sizeof(uap->type), "PL011 rev%u", amba_rev(dev));
+ snprintf(uap->type, sizeof(uap->type), "SBSA");
+ } else {
+ uap->clk = devm_clk_get(>dev, NULL);
+ if (IS_ERR(uap->clk))
+ return PTR_ERR(uap->clk);
+
+ uap->vendor = vendor;
+ uap->lcrh_rx = vendor->lcrh_rx;
+ uap->lcrh_tx = vendor->lcrh_tx;
+ uap->fifosize = vendor->get_fifosize(dev);
+ uap->port.ops = _pl011_pops;
+
+ snprintf(uap->type, sizeof(uap->type), "PL011 rev%u",
+ amba_rev(dev));
+ }
+ uap->port.irq = dev->irq[0];
ret = pl011_setup_port(>dev, uap, >res, portnr);
if (ret)
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] ACPI: amba bus probing support
From: Graeme Gregory
On ARM64 some devices use the AMBA device and not the platform bus for
probing so add support for this. Uses a dummy clock for apb_pclk as ACPI
does not have a suitable clock representation and to keep the core
AMBA bus code unchanged between probing methods.
Signed-off-by: Graeme Gregory
Signed-off-by: Aleksey Makarov
---
drivers/acpi/Makefile| 1 +
drivers/acpi/acpi_amba.c | 149 +++
drivers/acpi/internal.h | 5 ++
3 files changed, 155 insertions(+)
create mode 100644 drivers/acpi/acpi_amba.c
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 675eaf3..3cf732f 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -43,6 +43,7 @@ acpi-y+= pci_root.o
pci_link.o pci_irq.o
acpi-y += acpi_lpss.o acpi_apd.o
acpi-y += acpi_platform.o
acpi-y += acpi_pnp.o
+acpi-$(CONFIG_ARM_AMBA)+= acpi_amba.o
acpi-y += int340x_thermal.o
acpi-y += power.o
acpi-y += event.o
diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
new file mode 100644
index 000..ebc8913
--- /dev/null
+++ b/drivers/acpi/acpi_amba.c
@@ -0,0 +1,149 @@
+
+/*
+ * ACPI support for platform bus type.
+ *
+ * Copyright (C) 2015, Linaro Ltd
+ * Authors: Graeme Gregory
+ *
+ * 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 Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "internal.h"
+
+static const struct acpi_device_id amba_id_list[] = {
+ {"ARMH0011", 0}, /* PL011 SBSA Uart */
+ {"ARMH0061", 0}, /* PL061 GPIO Device */
+ {"", 0},
+};
+
+static struct clk *amba_dummy_clk;
+
+static void amba_register_dummy_clk(void)
+{
+ struct clk *clk;
+
+ /* If clock already registered */
+ if (amba_dummy_clk)
+ return;
+
+ clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT, 0);
+ clk_register_clkdev(clk, "apb_pclk", NULL);
+
+ amba_dummy_clk = clk;
+}
+
+static int amba_handler_attach(struct acpi_device *adev,
+ const struct acpi_device_id *id)
+{
+ struct amba_device *dev = NULL;
+ struct acpi_device *acpi_parent;
+ struct resource_entry *rentry;
+ struct list_head resource_list;
+ struct resource *resources = NULL;
+ bool address_found = false;
+ int ret, count, irq_no = 0;
+
+ /* If the ACPI node already has a physical device attached, skip it. */
+ if (adev->physical_node_count)
+ return 0;
+
+ amba_register_dummy_clk();
+
+ dev = amba_device_alloc(NULL, 0, 0);
+ if (!dev) {
+ pr_err("%s(): amba_device_alloc() failed for %s\n",
+ __func__, dev_name(>dev));
+ return 0;
+ }
+
+ INIT_LIST_HEAD(_list);
+ count = acpi_dev_get_resources(adev, _list, NULL, NULL);
+ if (count < 0) {
+ return 0;
+ } else if (count > 0) {
+ resources = kmalloc_array(count, sizeof(struct resource),
+ GFP_KERNEL);
+ if (!resources) {
+ acpi_dev_free_resource_list(_list);
+ return 0;
+ }
+ count = 0;
+ list_for_each_entry(rentry, _list, node) {
+ switch (resource_type(rentry->res)) {
+ case IORESOURCE_MEM:
+ if (!address_found) {
+ dev->res = *rentry->res;
+ address_found = true;
+ }
+ break;
+ case IORESOURCE_IRQ:
+ if (irq_no < AMBA_NR_IRQS)
+ dev->irq[irq_no++] = rentry->res->start;
+ break;
+ default:
+ dev_warn(>dev, "Invalid resource\n");
+ }
+ }
+ acpi_dev_free_resource_list(_list);
+ }
+
+ /*
+* If the ACPI node has a parent and that parent has a physical device
+* attached to it, that physical device should be the parent of the
+* platform device we are about to create.
+*/
+ dev->dev.parent = NULL;
+ acpi_parent = adev->parent;
+ if (acpi_parent) {
+ struct acpi_device_physical_node *entry;
+ struct list_head *list;
+
+ mutex_lock(_parent->physical_node_lock);
+ list = _parent->physical_node_list;
+
[PATCH v2 0/3] Add AMBA bus probing support to ACPI
As discussed when Shannon Zhao sent a patch to add platform_device support to pl061 driver. Russel and other maintainers prefered that ACPI learned how to create AMBA devices rather than converting/adding platform_device support to AMBA drivers. http://comments.gmane.org/gmane.linux.ports.arm.kernel/431364 1) Adds basic AMBA device probing support to ACPI, it uses a whitelist of device IDs as the number of AMBA devices is limited. Currently the two ids present are those used in QEMU for arm64. 2) Adds the plumbing into ACPI probe sequence. 3) From ACPI pl011 is only defined (SBSA document) to be in SBSA mode which has reduced functionality. There may be a better method to do this that I have overlooked. v2: - A new ACPI scan handler for AMBA devices has been implemented - The order of `if` branches in amba-pl011.c has been changed - A couple of `static`s have been added - The compilation of the acpi_amba.c unit has made conditional - A comment on SBSA UART has been added v1: https://lkml.kernel.org/g/1443609530-21524-1-git-send-email-graeme.greg...@linaro.org Graeme Gregory (3): ACPI: amba bus probing support ACPI: scan add in amba probing serial: amba-pl011: add ACPI support to AMBA probe drivers/acpi/Makefile | 1 + drivers/acpi/acpi_amba.c| 149 drivers/acpi/internal.h | 5 ++ drivers/acpi/scan.c | 1 + drivers/tty/serial/amba-pl011.c | 37 +++--- 5 files changed, 182 insertions(+), 11 deletions(-) create mode 100644 drivers/acpi/acpi_amba.c -- 2.6.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] ACPI: scan add in amba probing
From: Graeme Gregory Add a new ACPI scan handler for AMBA devices. Signed-off-by: Graeme Gregory Signed-off-by: Aleksey Makarov --- drivers/acpi/scan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 78d5f02..20c8cba 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -1922,6 +1922,7 @@ int __init acpi_scan_init(void) acpi_memory_hotplug_init(); acpi_pnp_init(); acpi_int340x_thermal_init(); + acpi_amba_init(); acpi_scan_add_handler(_device_handler); -- 2.6.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)
On Mon, 21 Dec 2015, David Vrabel wrote: > On 20/12/15 09:25, Michael S. Tsirkin wrote: > > > > I noticed that drivers/xen/xenbus/xenbus_comms.c uses > > full memory barriers to communicate with the other side. > > For example: > > > > /* Must write data /after/ reading the consumer index. * */ > > mb(); > > > > memcpy(dst, data, avail); > > data += avail; > > len -= avail; > > > > /* Other side must not see new producer until data is * > > there. */ > > wmb(); > > intf->req_prod += avail; > > > > /* Implies mb(): other side will see the updated producer. > > */ > > notify_remote_via_evtchn(xen_store_evtchn); > > > > To me, it looks like for guests compiled with CONFIG_SMP, smp_wmb and smp_mb > > would be sufficient, so mb() and wmb() here are only needed if > > a non-SMP guest runs on an SMP host. > > > > Is my analysis correct? > > For x86, yes. > > For arm/arm64 I think so, but would prefer one of the Xen arm > maintainers to confirm. In particular, whether inner-shareable barriers > are sufficient for memory shared with the hypervisor. inner-shareable barriers are certainly OK. In this case there would be also a switch from dsb to dmb barriers, which I also think should be OK. What about all the mb() and wmb() in RING_PUSH_REQUESTS and RING_PUSH_RESPONSES in include/xen/interface/io/ring.h ? > > So what I'm suggesting is something like the below patch, > > except instead of using virtio directly, a new set of barriers > > that behaves identically for SMP and non-SMP guests will be introduced. > > > > And of course the weak barriers flag is not needed for Xen - > > that's a virtio only thing. > > > > For example: > > > > smp_pv_wmb() > > smp_pv_rmb() > > smp_pv_mb() > > The smp_ prefix doesn't make a lot of sense to me here since these > barriers are going to be the same whether the kernel is SMP or not. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3 v2] powercap, intel_rapl, implement time window checks
The Intel ASDM provides a maximum time window that can be specified when setting a time window in the RAPL driver. While the ASDM doesn't explicitly provide a minimum time window value, it does provide a minimum time window unit that also can be used as a minimum value. This patchset implements barrier checking for the time windows, and adds reporting of a known bug in which the maxmimum time window value may be erroneously set to 0, as well as a module parameter to avoid the maximum window checks on broken BIOSes. [v2]: update 3/3 with minor changes Prarit Bhargava (3): powercap, intel_rapl, implement get_max_time_window powercap, intel_rapl, implement check for minimum time window powercap, intel_rapl, Add ignore_max_time_window_check module parameter for broken BIOSes drivers/powercap/intel_rapl.c | 50 +++ drivers/powercap/powercap_sys.c |6 +++-- 2 files changed, 54 insertions(+), 2 deletions(-) -- 1.7.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] powercap, intel_rapl, implement get_max_time_window
The MSR_PKG_POWER_INFO register (Intel ASDM, section 14.9.3
"Package RAPL Domain") provides a maximum time window which the
system can support. This window is read-only and is currently
not examined when setting the time windows for the package.
This patch implements get_max_time_window_us() and checks the window when
a user attempts to set power capping for the package.
Before the patch it was possible to set the window to, for example, 1
micro seconds:
[root@intel-chiefriver-03 rhel7]# echo 1 >
/sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_0_time_window_us;
egrep ^
/sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_0_time_window_us
/sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_time_window_us:1:9765
but from 'turbostat -d', the package is limited to 976us:
cpu0: MSR_PKG_POWER_INFO: 0x01200168 (45 W TDP, RAPL 36 - 0 W, 0.000977 sec.)
(Note, there appears to be a rounding issue in turbostat which needs to
also be fixed. Looking at the values in the register it is clear the
value is 1/1024 = 976us.)
After the patch we are limited by the maximum time window:
[root@intel-chiefriver-03 rhel7]# echo 1 >
/sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_0_time_window_us;
egrep ^
/sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_0_time_window_us
-bash: echo: write error: Invalid argument
/sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_time_window_us:1:976
Cc: "Rafael J. Wysocki"
Cc: Prarit Bhargava
Cc: Radivoje Jovanovic
Cc: Seiichi Ikarashi
Cc: Mathias Krause
Cc: Ajay Thomas
Signed-off-by: Prarit Bhargava
---
drivers/powercap/intel_rapl.c | 31 +++
drivers/powercap/powercap_sys.c |6 --
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index cc97f08..f765b2c 100644
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@ -493,13 +493,42 @@ static int get_current_power_limit(struct powercap_zone
*power_zone, int id,
return ret;
}
+static int get_max_time_window(struct powercap_zone *power_zone, int id,
+ u64 *data)
+{
+ struct rapl_domain *rd;
+ int ret = 0;
+ u64 val;
+
+ get_online_cpus();
+ rd = power_zone_to_rapl_domain(power_zone);
+
+ if (rapl_read_data_raw(rd, MAX_TIME_WINDOW, true, ))
+ ret = -EIO;
+ else
+ *data = val;
+
+ put_online_cpus();
+ return ret;
+}
+
static int set_time_window(struct powercap_zone *power_zone, int id,
u64 window)
{
struct rapl_domain *rd;
int ret = 0;
+ u64 max_window;
get_online_cpus();
+ ret = get_max_time_window(power_zone, id, _window);
+ if (ret < 0)
+ goto out;
+
+ if (window > max_window) {
+ ret = -EINVAL;
+ goto out;
+ }
+
rd = power_zone_to_rapl_domain(power_zone);
switch (rd->rpl[id].prim_id) {
case PL1_ENABLE:
@@ -511,6 +540,7 @@ static int set_time_window(struct powercap_zone
*power_zone, int id,
default:
ret = -EINVAL;
}
+out:
put_online_cpus();
return ret;
}
@@ -590,6 +620,7 @@ static struct powercap_zone_constraint_ops constraint_ops =
{
.set_time_window_us = set_time_window,
.get_time_window_us = get_time_window,
.get_max_power_uw = get_max_power,
+ .get_max_time_window_us = get_max_time_window,
.get_name = get_constraint_name,
};
diff --git a/drivers/powercap/powercap_sys.c b/drivers/powercap/powercap_sys.c
index 84419af..7d77b83 100644
--- a/drivers/powercap/powercap_sys.c
+++ b/drivers/powercap/powercap_sys.c
@@ -101,7 +101,7 @@ static ssize_t store_constraint_##_attr(struct device *dev,\
int err; \
u64 value; \
struct powercap_zone *power_zone = to_powercap_zone(dev); \
- int id; \
+ int id, ret; \
struct powercap_zone_constraint *pconst;\
\
if (!sscanf(dev_attr->attr.name, "constraint_%d_", )) \
@@ -113,8 +113,10 @@ static ssize_t store_constraint_##_attr(struct device
*dev,\
if (err) \
return -EINVAL; \
if (pconst && pconst->ops && pconst->ops->set_##_attr) { \
- if (!pconst->ops->set_##_attr(power_zone, id, value)) \
+ ret = pconst->ops->set_##_attr(power_zone, id, value); \
+ if (!ret) \
return count; \
+ return ret; \
} \
\
return -ENODATA; \
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
[PATCH 2/3] powercap, intel_rapl, implement check for minimum time window
Using an small value for the time window results in a
bogus value for the time window. For example,
[root@intel-chiefriver-03 linux]# echo 950 >
/sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_0_time_window_us;
egrep ^
/sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_0_time_window_us
-bash: echo: write error: Invalid argument
/sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_time_window_us:1:4501502475370496
The Intel ASDM doesn't explicitly define a minimum time window.
The MSR_RAPL_POWER_UNIT register, read during initialization, does
specify a minimum time window unit so that can be used as a lower
bound for error checking.
After this change the minimum time window is properly clamped:
[root@intel-chiefriver-03 linux]# echo 950 >
/sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_0_time_window_us;
egrep ^
/sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_0_time_window_us
-bash: echo: write error: Invalid argument
/sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_time_window_us:1:976
Cc: "Rafael J. Wysocki"
Cc: Prarit Bhargava
Cc: Radivoje Jovanovic
Cc: Seiichi Ikarashi
Cc: Mathias Krause
Cc: Ajay Thomas
Signed-off-by: Prarit Bhargava
---
drivers/powercap/intel_rapl.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index f765b2c..14753e5 100644
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@ -516,6 +516,7 @@ static int set_time_window(struct powercap_zone
*power_zone, int id,
u64 window)
{
struct rapl_domain *rd;
+ struct rapl_package *rp;
int ret = 0;
u64 max_window;
@@ -524,12 +525,18 @@ static int set_time_window(struct powercap_zone
*power_zone, int id,
if (ret < 0)
goto out;
- if (window > max_window) {
+ rd = power_zone_to_rapl_domain(power_zone);
+ rp = find_package_by_id(rd->package_id);
+ /*
+* The Intel ASDM doesn't explicitly define a minimum time window.
+* The MSR_RAPL_POWER_UNIT register, read during initialization,
+* does contain the smallest unit of time that can be measured.
+*/
+ if ((window > max_window) || (window < rp->time_unit)) {
ret = -EINVAL;
goto out;
}
- rd = power_zone_to_rapl_domain(power_zone);
switch (rd->rpl[id].prim_id) {
case PL1_ENABLE:
rapl_write_data_raw(rd, TIME_WINDOW1, window);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] dt-bindings: sound: add devicetree document for rt5616
在 2015年12月21日 22:10, Heiko Stübner 写道: Am Montag, 21. Dezember 2015, 21:18:14 schrieb Caesar Wang: Add the description for rt5616 codec. Signed-off-by: Caesar Wang --- Documentation/devicetree/bindings/sound/rt5616.txt | 38 ++ 1 file changed, 38 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/rt5616.txt diff --git a/Documentation/devicetree/bindings/sound/rt5616.txt b/Documentation/devicetree/bindings/sound/rt5616.txt new file mode 100644 index 000..af96207 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rt5616.txt @@ -0,0 +1,38 @@ +RT5616 audio CODEC + +This device supports I2C only. + +Required properties: + +- compatible : "realtek,rt5616". + +- reg : The I2C address of the device. + +Optional properties: you don't have optional properties, so that headline should probably also not be here. Yep, that should remove in here. :-( Thanks！ Heiko -- caesar wang | software engineer | w...@rock-chip.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] perf: Generalize task_function_call()ers
Peter Zijlstra writes:
> -
> - /*
> - * If the context we're installing events in is not the
> - * active task_ctx, flip them.
> - */
> - if (ctx->task && task_ctx != ctx) {
> - if (task_ctx)
> - raw_spin_unlock(_ctx->lock);
> - raw_spin_lock(>lock);
> - task_ctx = ctx;
> - }
> -
> - if (task_ctx) {
> - cpuctx->task_ctx = task_ctx;
> - task = task_ctx->task;
> - }
> -
So previously, this would schedule in the tast_ctx right in
perf_install_in_context path.
The new code would only reschedule the context if it is already on:
> + if (ctx->is_active)
> + perf_resched_context(cpuctx);
> }
which means, iiuc, that an enabled event (say, attr.disabled==0) will
have to wait till the next time the ctx::task is scheduled instead of
getting scheduled right here.
Something like
if (ctx->task == current && ctx->nr_events)
perf_event_sched_in(cpuctx, ctx, ctx->task);
might make sense here.
Also the new __perf_event_enable() has the same symptom: it doesn't
schedule the new context on, only reschedule it if it's already on.
Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] [media] media-device: split media initialization and registration
Hello Mauro, On 12/15/2015 08:13 AM, Mauro Carvalho Chehab wrote: [snip] >>> >>> /** >>> - * media_device_register - register a media device >>> + * media_device_init() - initialize a media device >>> * @mdev: The media device >>> * >>> * The caller is responsible for initializing the media device before >>> @@ -534,12 +534,11 @@ static void media_device_release(struct media_devnode >>> *mdev) >>> * >>> * - dev must point to the parent device >>> * - model must be filled with the device model name >>> + * >>> + * returns zero on success or a negative error code. >>> */ >>> -int __must_check __media_device_register(struct media_device *mdev, >>> -struct module *owner) >>> +int __must_check media_device_init(struct media_device *mdev) >> >> I think I suggested making media_device_init() return void as the only >> remaining source of errors would be driver bugs. >> >> I'd simply replace the WARN_ON() below with BUG(). > > That sounds like bad idea to me, and it is against the current > Kernel policy of using BUG() only when there's no other way, e. g. on > event so severe that the Kernel has no other thing to do except to > stop running. > I agree with you, that was exactly my point and what I told Sakari [0] but he had a strong opinion about it and I didn't mind too much so I decided at the end to just change it to a BUG_ON() so I could get his ack for this set. > For sure, this is not the case here. Also, all drivers have already > a logic that checks if the device init happened. So, they should already > be doing the right thing. > > Regards, > Mauro [0]: https://lkml.org/lkml/2015/9/10/483 Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/10] perf hist: Save raw_data/size for tracepoint events
The raw_data and raw_size fields are to provide tracepoint specific
information. They will be used by dynamic sort keys later.
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 4
tools/perf/util/sort.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 039bb91d0a92..c0c92a3daa69 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -487,6 +487,8 @@ struct hist_entry *__hists__add_entry(struct hists *hists,
.branch_info = bi,
.mem_info = mi,
.transaction = sample->transaction,
+ .raw_data = sample->raw_data,
+ .raw_size = sample->raw_size,
};
return hists__findnew_entry(hists, , al, sample_self);
@@ -801,6 +803,8 @@ iter_add_next_cumulative_entry(struct hist_entry_iter *iter,
.sym = al->sym,
},
.parent = iter->parent,
+ .raw_data = sample->raw_data,
+ .raw_size = sample->raw_size,
};
int i;
struct callchain_cursor cursor;
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 86f05e7a5566..d29898708dbd 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -122,6 +122,8 @@ struct hist_entry {
struct branch_info *branch_info;
struct hists*hists;
struct mem_info *mem_info;
+ void*raw_data;
+ u32 raw_size;
struct callchain_root callchain[0]; /* must be last member */
};
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read
2015-12-11 14:55 GMT+01:00 Bartosz Golaszewski : > 2015-12-11 13:08 GMT+01:00 Wolfram Sang : >> On Wed, Dec 02, 2015 at 11:25:17AM +0100, Bartosz Golaszewski wrote: >>> Chips from the at24cs EEPROM series have an additional read-only memory area >>> containing a factory pre-programmed serial number. In order to access it, a >>> dummy write must be executed before reading the serial number bytes. >> >> Can't you instantiate a read-only EEPROM on this second address? Or a >> seperate driver attaching to this address? What is the advantage of >> having this in at24? >> > > The regular memory area and serial number read-only block share the > internal address pointer. We must ensure that there's no race > conditions between normal EEPROM reads/writes and serial number reads. > > Best regards, > Bartosz Golaszewski Hi Wolfram, any chance of getting it in for 4.5? Best regards, Bartosz Golaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/10] tools lib traceevent: Factor out and export print_event_field[s]
The print_event_field() and print_event_field() are to print basic
information of a given field or event without the print format. They'll
be used by dynamic sort keys later.
Cc: Steven Rostedt
Signed-off-by: Namhyung Kim
---
tools/lib/traceevent/event-parse.c | 125 -
tools/lib/traceevent/event-parse.h | 4 ++
2 files changed, 70 insertions(+), 59 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 68276f35e323..1b43f2b9aebe 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -4735,73 +4735,80 @@ static int is_printable_array(char *p, unsigned int len)
return 1;
}
-static void print_event_fields(struct trace_seq *s, void *data,
- int size __maybe_unused,
- struct event_format *event)
+void print_event_field(struct trace_seq *s, void *data,
+ struct format_field *field)
{
- struct format_field *field;
unsigned long long val;
unsigned int offset, len, i;
-
- field = event->format.fields;
- while (field) {
- trace_seq_printf(s, " %s=", field->name);
- if (field->flags & FIELD_IS_ARRAY) {
- offset = field->offset;
- len = field->size;
- if (field->flags & FIELD_IS_DYNAMIC) {
- val = pevent_read_number(event->pevent, data +
offset, len);
- offset = val;
- len = offset >> 16;
- offset &= 0x;
- }
- if (field->flags & FIELD_IS_STRING &&
- is_printable_array(data + offset, len)) {
- trace_seq_printf(s, "%s", (char *)data +
offset);
- } else {
- trace_seq_puts(s, "ARRAY[");
- for (i = 0; i < len; i++) {
- if (i)
- trace_seq_puts(s, ", ");
- trace_seq_printf(s, "%02x",
-*((unsigned char
*)data + offset + i));
- }
- trace_seq_putc(s, ']');
- field->flags &= ~FIELD_IS_STRING;
- }
+ struct pevent *pevent = field->event->pevent;
+
+ if (field->flags & FIELD_IS_ARRAY) {
+ offset = field->offset;
+ len = field->size;
+ if (field->flags & FIELD_IS_DYNAMIC) {
+ val = pevent_read_number(pevent, data + offset, len);
+ offset = val;
+ len = offset >> 16;
+ offset &= 0x;
+ }
+ if (field->flags & FIELD_IS_STRING &&
+ is_printable_array(data + offset, len)) {
+ trace_seq_printf(s, "%s", (char *)data + offset);
} else {
- val = pevent_read_number(event->pevent, data +
field->offset,
-field->size);
- if (field->flags & FIELD_IS_POINTER) {
- trace_seq_printf(s, "0x%llx", val);
- } else if (field->flags & FIELD_IS_SIGNED) {
- switch (field->size) {
- case 4:
- /*
-* If field is long then print it in
hex.
-* A long usually stores pointers.
-*/
- if (field->flags & FIELD_IS_LONG)
- trace_seq_printf(s, "0x%x",
(int)val);
- else
- trace_seq_printf(s, "%d",
(int)val);
- break;
- case 2:
- trace_seq_printf(s, "%2d", (short)val);
- break;
- case 1:
- trace_seq_printf(s, "%1d", (char)val);
- break;
- default:
- trace_seq_printf(s, "%lld", val);
- }
- } else {
+ trace_seq_puts(s, "ARRAY[");
+ for (i = 0; i < len; i++) {
+ if (i)
+ trace_seq_puts(s, ", ");
+
[PATCH 06/10] perf tools: Try to show pretty printed output for dynamic sort keys
Each tracepoint event has format string for print to improve
readability. Try to parse the output and match the field name. If it
finds one, use that for the result. If not, fallbacks to the original
output.
For example, sort on kmem:kmalloc.gfp_flags looks like below:
(Note: libtraceevent plugins are not installed on my system. They might
affect the output below)
Before:
# Overhead Command gfp_flags
# ... ..
#
99.89% perf 32848
0.06% sleep 208
0.03% perf 32976
0.01% perf208
After:
# Overhead Commandgfp_flags
# ... ...
#
99.89% perf GFP_NOFS|GFP_ZERO
0.06% sleep GFP_KERNEL
0.03% perf GFP_KERNEL|GFP_ZERO
0.01% perf GFP_KERNEL
Cc: Steven Rostedt
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 1 +
tools/perf/util/sort.c | 99 +++---
tools/perf/util/sort.h | 1 +
3 files changed, 96 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index c0c92a3daa69..ef1a4a5cc610 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -978,6 +978,7 @@ void hist_entry__delete(struct hist_entry *he)
if (he->srcfile && he->srcfile[0])
free(he->srcfile);
free_callchain(he->callchain);
+ free(he->trace_output);
free(he);
}
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index f2bac1c149a9..e28d26d0e73c 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -1560,6 +1560,56 @@ static int hde_width(struct hpp_dynamic_entry *hde)
return hde->hpp.len;
}
+static void update_dynamic_len(struct hpp_dynamic_entry *hde,
+ struct hist_entry *he)
+{
+ char *str, *pos;
+ struct format_field *field = hde->field;
+ struct pevent_record rec = {
+ .cpu = he->cpu,
+ .data = he->raw_data,
+ .size = he->raw_size,
+ };
+ size_t namelen;
+ bool last = false;
+
+ /* parse pretty print result and update max length */
+ if (!he->trace_output) {
+ struct trace_seq seq;
+
+ trace_seq_init();
+ pevent_event_info(, field->event, );
+ he->trace_output = seq.buffer;
+ }
+
+ namelen = strlen(field->name);
+ str = he->trace_output;
+
+ while (str) {
+ pos = strchr(str, ' ');
+ if (pos == NULL) {
+ last = true;
+ pos = str + strlen(str);
+ }
+
+ if (!strncmp(str, field->name, namelen)) {
+ size_t len;
+
+ str += namelen + 1;
+ len = pos - str;
+
+ if (len > hde->dynamic_len)
+ hde->dynamic_len = len;
+ break;
+ }
+
+ if (last)
+ str = NULL;
+ else
+ str = pos + 1;
+ }
+}
+
static int __sort__hde_header(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
struct perf_evsel *evsel __maybe_unused)
{
@@ -1594,7 +1644,10 @@ static int __sort__hde_entry(struct perf_hpp_fmt *fmt,
struct perf_hpp *hpp,
{
struct hpp_dynamic_entry *hde;
size_t len = fmt->user_len;
- struct trace_seq seq;
+ char *str, *pos;
+ struct format_field *field;
+ size_t namelen;
+ bool last = false;
int ret;
hde = container_of(fmt, struct hpp_dynamic_entry, hpp);
@@ -1605,10 +1658,43 @@ static int __sort__hde_entry(struct perf_hpp_fmt *fmt,
struct perf_hpp *hpp,
if (hists_to_evsel(he->hists) != hde->evsel)
return scnprintf(hpp->buf, hpp->size, "%*.*s", len, len, "N/A");
- trace_seq_init();
- print_event_field(, he->raw_data, hde->field);
- ret = scnprintf(hpp->buf, hpp->size, "%*.*s", len, len, seq.buffer);
- trace_seq_destroy();
+ field = hde->field;
+
+ namelen = strlen(field->name);
+ str = he->trace_output;
+
+ while (str) {
+ pos = strchr(str, ' ');
+ if (pos == NULL) {
+ last = true;
+ pos = str + strlen(str);
+ }
+
+ if (!strncmp(str, field->name, namelen)) {
+ str += namelen + 1;
+ str = strndup(str, pos - str);
+
+ if (str == NULL)
+ return scnprintf(hpp->buf, hpp->size,
+"%*.*s", len, len, "ERROR");
+ break;
+ }
+
+ if (last)
+ str = NULL;
+ else
+
[PATCH 10/10] perf tools: Support shortcuts for events in dynamic sort keys
The dynamic sort key requires event name but specifying full event name
is rather inconvenient. This patch adds more ways to identify the event
in a more compact way.
1. If session has just one event, event name can be omitted.
2. Events can be accessed by index preceded by a percent sign.
3. A part of the name can be used, if it's not ambiguous. The partial
name should not contain ':' in it.
4. Full system + event name is still used, it should contain ':'.
So in the below example all does same thing:
$ perf record -e sched:sched_switch -a sleep 1
$ perf report -s next_pid,next_comm
$ perf report -s %1.next_pid,%1.next_comm
$ perf report -s switch.next_pid,switch.next_comm
$ perf report -s sched:sched_switch.next_pid,sched:sched_switch_.next_comm
Cc: Steven Rostedt
Signed-off-by: Namhyung Kim
---
tools/perf/util/sort.c | 107 -
1 file changed, 87 insertions(+), 20 deletions(-)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 43cb9b638718..5737c830951c 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -1837,10 +1837,90 @@ __alloc_dynamic_entry(struct perf_evsel *evsel, struct
format_field *field)
return hde;
}
+static int parse_field_name(char *str, char **event, char **field, char **opt)
+{
+ char *event_name, *field_name, *opt_name;
+
+ event_name = str;
+ field_name = strchr(str, '.');
+
+ if (field_name) {
+ *field_name++ = '\0';
+ } else {
+ event_name = NULL;
+ field_name = str;
+ }
+
+ opt_name = strchr(field_name, '/');
+ if (opt_name)
+ *opt_name++ = '\0';
+
+ *event = event_name;
+ *field = field_name;
+ *opt = opt_name;
+
+ return 0;
+}
+
+/* find match evsel using a given event name. The event name can be:
+ * 1. NULL - only valid for single event session
+ * 2. '%' + event index (e.g. '%1' for first event)
+ * 3. full event name (e.g. sched:sched_switch)
+ * 4. partial event name (should not contain ':')
+ */
+static struct perf_evsel *find_evsel(struct perf_evlist *evlist, char
*event_name)
+{
+ struct perf_evsel *evsel = NULL;
+ struct perf_evsel *pos;
+ bool full_name;
+
+ /* case 1 */
+ if (event_name == NULL) {
+ if (evlist->nr_entries != 1) {
+ pr_debug("event name should be given\n");
+ return NULL;
+ }
+
+ return perf_evlist__first(evlist);
+ }
+
+ /* case 2 */
+ if (event_name[0] == '%') {
+ int nr = strtol(event_name+1, NULL, 0);
+
+ if (nr > evlist->nr_entries)
+ return NULL;
+
+ evsel = perf_evlist__first(evlist);
+ while (--nr > 0)
+ evsel = perf_evsel__next(evsel);
+
+ return evsel;
+ }
+
+ full_name = !!strchr(event_name, ':');
+ evlist__for_each(evlist, pos) {
+ /* case 3 */
+ if (full_name && !strcmp(pos->name, event_name))
+ return pos;
+ /* case 4 */
+ if (!full_name && strstr(pos->name, event_name)) {
+ if (evsel) {
+ pr_debug("'%s' event is ambiguous: it can be %s
or %s\n",
+event_name, evsel->name, pos->name);
+ return NULL;
+ }
+ evsel = pos;
+ }
+ }
+
+ return evsel;
+}
+
static int add_dynamic_entry(struct perf_evlist *evlist, const char *tok)
{
- char *str, *event_name, *field_name, *raw_opt;
- struct perf_evsel *evsel, *pos;
+ char *str, *event_name, *field_name, *opt_name;
+ struct perf_evsel *evsel;
struct event_format *format;
struct format_field *field;
struct hpp_dynamic_entry *hde;
@@ -1854,34 +1934,21 @@ static int add_dynamic_entry(struct perf_evlist
*evlist, const char *tok)
if (str == NULL)
return -ENOMEM;
- event_name = str;
- field_name = strchr(str, '.');
- if (field_name == NULL) {
+ if (parse_field_name(str, _name, _name, _name) < 0) {
ret = -EINVAL;
goto out;
}
- *field_name++ = '\0';
- raw_opt = strchr(field_name, '/');
- if (raw_opt) {
- *raw_opt++ = '\0';
-
- if (strcmp(raw_opt, "raw")) {
- pr_err("Unsupported field option %s\n", raw_opt);
+ if (opt_name) {
+ if (strcmp(opt_name, "raw")) {
+ pr_debug("unsupported field option %s\n", opt_name);
ret = -EINVAL;
goto out;
}
raw_trace = true;
}
- evsel = NULL;
-
[PATCH 07/10] perf tools: Add 'trace' sort key
The 'trace' sort key is to show tracepoint event output using either
print fmt or plugin. For example sched_switch event (using plugin) will
show output like below:
$ perf report -s trace --stdio
...
# Overhead Trace output
# ...
#
9.48% swapper/0:0 [120] R ==> transmission-gt:17773 [120]
9.48% transmission-gt:17773 [120] S ==> swapper/0:0 [120]
9.04% swapper/2:0 [120] R ==> transmission-gt:17773 [120]
8.92% transmission-gt:17773 [120] S ==> swapper/2:0 [120]
5.25% swapper/0:0 [120] R ==> kworker/0:1H:109 [100]
5.21% kworker/0:1H:109 [100] S ==> swapper/0:0 [120]
1.78% swapper/3:0 [120] R ==> transmission-gt:17773 [120]
1.78% transmission-gt:17773 [120] S ==> swapper/3:0 [120]
1.53% Xephyr:6524 [120] S ==> swapper/0:0 [120]
1.53% swapper/0:0 [120] R ==> Xephyr:6524 [120]
1.17% swapper/2:0 [120] R ==> irq/33-iwlwifi:233 [49]
1.13% irq/33-iwlwifi:233 [49] S ==> swapper/2:0 [120]
Note that the 'trace' sort key works only for tracepoint events. If
it's used to other type of events, just "N/A" will be printed.
Suggested-by: Jiri Olsa
Cc: Steven Rostedt
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.h | 1 +
tools/perf/util/sort.c | 60 ++
tools/perf/util/sort.h | 1 +
3 files changed, 62 insertions(+)
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 36439bfad059..15b22c563d30 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -52,6 +52,7 @@ enum hist_column {
HISTC_MEM_IADDR_SYMBOL,
HISTC_TRANSACTION,
HISTC_CYCLES,
+ HISTC_TRACE,
HISTC_NR_COLS, /* Last entry */
};
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index e28d26d0e73c..50a6b35a2fee 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -445,6 +445,65 @@ struct sort_entry sort_socket = {
.se_width_idx = HISTC_SOCKET,
};
+/* --sort trace */
+
+static char *get_trace_output(struct hist_entry *he)
+{
+ struct trace_seq seq;
+ struct perf_evsel *evsel;
+ struct pevent_record rec = {
+ .data = he->raw_data,
+ .size = he->raw_size,
+ };
+
+ evsel = hists_to_evsel(he->hists);
+
+ trace_seq_init();
+ pevent_event_info(, evsel->tp_format, );
+ return seq.buffer;
+}
+
+static int64_t
+sort__trace_cmp(struct hist_entry *left, struct hist_entry *right)
+{
+ struct perf_evsel *evsel;
+
+ evsel = hists_to_evsel(left->hists);
+ if (evsel->attr.type != PERF_TYPE_TRACEPOINT)
+ return 0;
+
+ if (left->trace_output == NULL)
+ left->trace_output = get_trace_output(left);
+ if (right->trace_output == NULL)
+ right->trace_output = get_trace_output(right);
+
+ hists__new_col_len(left->hists, HISTC_TRACE,
strlen(left->trace_output));
+ hists__new_col_len(right->hists, HISTC_TRACE,
strlen(right->trace_output));
+
+ return strcmp(right->trace_output, left->trace_output);
+}
+
+static int hist_entry__trace_snprintf(struct hist_entry *he, char *bf,
+ size_t size, unsigned int width)
+{
+ struct perf_evsel *evsel;
+
+ evsel = hists_to_evsel(he->hists);
+ if (evsel->attr.type != PERF_TYPE_TRACEPOINT)
+ return scnprintf(bf, size, "%-*.*s", width, width, "N/A");
+
+ if (he->trace_output == NULL)
+ he->trace_output = get_trace_output(he);
+ return repsep_snprintf(bf, size, "%-*.*s", width, width,
he->trace_output);
+}
+
+struct sort_entry sort_trace = {
+ .se_header = "Trace output",
+ .se_cmp = sort__trace_cmp,
+ .se_snprintf= hist_entry__trace_snprintf,
+ .se_width_idx = HISTC_TRACE,
+};
+
/* sort keys for branch stacks */
static int64_t
@@ -1314,6 +1373,7 @@ static struct sort_dimension common_sort_dimensions[] = {
DIM(SORT_LOCAL_WEIGHT, "local_weight", sort_local_weight),
DIM(SORT_GLOBAL_WEIGHT, "weight", sort_global_weight),
DIM(SORT_TRANSACTION, "transaction", sort_transaction),
+ DIM(SORT_TRACE, "trace", sort_trace),
};
#undef DIM
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index f6d2a7e3e7f2..6b7590ade229 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -183,6 +183,7 @@ enum sort_type {
SORT_LOCAL_WEIGHT,
SORT_GLOBAL_WEIGHT,
SORT_TRANSACTION,
+ SORT_TRACE,
/* branch stack specific sort keys */
__SORT_BRANCH_STACK,
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/10] perf tools: Add --raw-trace option
The --raw-trace option is to prevent pretty printing by event's
print_fmt or plugin. Besides that, each dynamic sort key now receives
'raw' suffix separated by '/' to apply the raw trace to a specific
field.
$ perf report -s comm,kmem:kmalloc.gfp_flags
...
# Overhead Commandgfp_flags
# ... ...
#
99.89% perf GFP_NOFS|GFP_ZERO
0.06% sleep GFP_KERNEL
0.03% perf GFP_KERNEL|GFP_ZERO
0.01% perf GFP_KERNEL
Now
$ perf report -s comm,kmem:kmalloc.gfp_flags --raw-trace
or
$ perf report -s comm,kmem:kmalloc.gfp_flags/raw
...
# Overhead Command gfp_flags
# ... ..
#
99.89% perf 32848
0.06% sleep 208
0.03% perf 32976
0.01% perf208
Suggested-by: Jiri Olsa
Cc: Steven Rostedt
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-report.txt | 3 +++
tools/perf/Documentation/perf-top.txt| 3 +++
tools/perf/builtin-report.c | 2 ++
tools/perf/builtin-top.c | 2 ++
tools/perf/util/sort.c | 31 ---
tools/perf/util/symbol.h | 3 ++-
6 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index dab99ed2b339..ae7cd91727f6 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -371,6 +371,9 @@ include::itrace.txt[]
--socket-filter::
Only report the samples on the processor socket that match with this
filter
+--raw-trace::
+ When displaying traceevent output, do not use print fmt or plugins.
+
include::callchain-overhead-calculation.txt[]
SEE ALSO
diff --git a/tools/perf/Documentation/perf-top.txt
b/tools/perf/Documentation/perf-top.txt
index 556cec09bf50..b0e60e17db38 100644
--- a/tools/perf/Documentation/perf-top.txt
+++ b/tools/perf/Documentation/perf-top.txt
@@ -230,6 +230,9 @@ Default is to monitor all CPUS.
The various filters must be specified as a comma separated list:
--branch-filter any_ret,u,k
Note that this feature may not be available on all processors.
+--raw-trace::
+ When displaying traceevent output, do not use print fmt or plugins.
+
INTERACTIVE PROMPTING KEYS
--
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index ea53c816640a..f10c663af996 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -788,6 +788,8 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
"Show callgraph from reference event"),
OPT_INTEGER(0, "socket-filter", _filter,
"only show processor socket that match with this filter"),
+ OPT_BOOLEAN(0, "raw-trace", _conf.raw_trace,
+ "Show raw trace event output (do not use print fmt or
plugins)"),
OPT_END()
};
struct perf_data_file file = {
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 005825942441..bf01cbb0ef23 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1210,6 +1210,8 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_CALLBACK('j', "branch-filter", >branch_stack,
"branch filter mask", "branch stack filter modes",
parse_branch_stack),
+ OPT_BOOLEAN(0, "raw-trace", _conf.raw_trace,
+ "Show raw trace event output (do not use print fmt or
plugins)"),
OPT_END()
};
const char * const top_usage[] = {
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 50a6b35a2fee..f38a0577967a 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -459,7 +459,11 @@ static char *get_trace_output(struct hist_entry *he)
evsel = hists_to_evsel(he->hists);
trace_seq_init();
- pevent_event_info(, evsel->tp_format, );
+ if (symbol_conf.raw_trace)
+ print_event_fields(, he->raw_data, he->raw_size,
+ evsel->tp_format);
+ else
+ pevent_event_info(, evsel->tp_format, );
return seq.buffer;
}
@@ -1596,6 +1600,7 @@ struct hpp_dynamic_entry {
struct perf_evsel *evsel;
struct format_field *field;
unsigned dynamic_len;
+ bool raw_trace;
};
static int hde_width(struct hpp_dynamic_entry *hde)
@@ -1633,6 +1638,9 @@ static void update_dynamic_len(struct hpp_dynamic_entry
*hde,
size_t namelen;
bool last = false;
+ if (hde->raw_trace)
+ return;
+
/* parse pretty print result and update max length */
if (!he->trace_output) {
struct trace_seq seq;
@@ -1718,8 +1726,10 @@ static int
[PATCHSET 00/10] perf tools: Support dynamic sort keys for tracepoints (v3)
Hello,
This is an attempt to improve perf to deal with tracepoint events
better. The perf tools can handle tracepoint events but perf report
on them is less useful since they're always sampled in a fixed
location and not provide event specific info. We can use perf script
but I always wishes there's more convenient way to see the result.
* changes in v3)
- save trace_output for dynamic entries (Jiri)
- update field length for each entry
* changes in v2)
- add 'trace' sort key and make it default (Jiri)
- add '--raw-trace' option and '/raw' field modifier (Jiri)
- support event name shortcuts (David)
I suggest dynamic sort keys created for each event.field on demand.
Consider following example:
# Overhead Command Shared Object Symbol
# ... ..
#
47.22% swapper [kernel.vmlinux] [k] __schedule
21.67% transmission-gt [kernel.vmlinux] [k] __schedule
8.23% netctl-auto [kernel.vmlinux] [k] __schedule
5.53% kworker/0:1H [kernel.vmlinux] [k] __schedule
1.98% Xephyr [kernel.vmlinux] [k] __schedule
1.33% irq/33-iwlwifi [kernel.vmlinux] [k] __schedule
1.17% wpa_cli [kernel.vmlinux] [k] __schedule
1.13% rcu_preempt [kernel.vmlinux] [k] __schedule
0.85% ksoftirqd/0 [kernel.vmlinux] [k] __schedule
0.77% Timer[kernel.vmlinux] [k] __schedule
...
Currently perf report only shows this but important info is on the
event fields, that is:
# sudo cat /sys/kernel/debug/tracing/events/sched/sched_switch/format
name: sched_switch
ID: 268
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:char prev_comm[16]; offset:8; size:16; signed:1;
field:pid_t prev_pid; offset:24; size:4; signed:1;
field:int prev_prio; offset:28; size:4; signed:1;
field:long prev_state;offset:32; size:8; signed:1;
field:char next_comm[16]; offset:40; size:16; signed:1;
field:pid_t next_pid; offset:56; size:4; signed:1;
field:int next_prio; offset:60; size:4; signed:1;
print fmt: "prev_comm=%s prev_pid=%d prev_prio=%d prev_state=%s%s ==>
next_comm=%s next_pid=%d next_prio=%d",
REC->prev_comm, REC->prev_pid, REC->prev_prio,
REC->prev_state & (2048-1) ? __print_flags(REC->prev_state & (2048-1),
"|", { 1, "S"} , { 2, "D" }, { 4, "T" }, { 8, "t" }, { 16, "Z" }, { 32, "X"
},
{ 64, "x" }, { 128, "K"}, { 256, "W" }, { 512, "P" }, { 1024, "N" }) : "R",
REC->prev_state & 2048 ? "+" : "", REC->next_comm, REC->next_pid,
REC->next_prio
With dynamic sort keys, you can use as a sort key. Those
dynamic keys are checked and created on demand. For instance, below is
to sort by next_pid field on the same data file.
$ perf report -s comm,sched:sched_switch.next_pid --stdio
...
# Overhead Commandnext_pid
# ... ..
#
21.23% transmission-gt 0
20.86% swapper 17773
6.62% netctl-auto 0
5.25% swapper 109
5.21% kworker/0:1H 0
1.98% Xephyr0
1.98% swapper6524
1.98% swapper 27478
1.37% swapper 27476
1.17% swapper 233
...
Multiple dynamic sort keys are also supported and the event name can
be simplified (or even omitted in a couple of ways (see patch 10/10):
$ perf report -s comm,switch.next_pid,next_comm --stdio
...
# Overhead Commandnext_pid next_comm
# ... ..
#
20.86% swapper 17773 transmission-gt
9.64% transmission-gt 0 swapper/0
9.16% transmission-gt 0 swapper/2
5.25% swapper 109 kworker/0:1H
5.21% kworker/0:1H 0 swapper/0
2.14% netctl-auto 0 swapper/2
1.98% netctl-auto 0 swapper/0
1.98% swapper6524Xephyr
1.98% swapper 27478 netctl-auto
1.78% transmission-gt 0 swapper/3
1.53% Xephyr0 swapper/0
1.29% netctl-auto 0 swapper/1
1.29% swapper 27476 netctl-auto
1.21% netctl-auto 0 swapper/3
1.17% swapper 233irq/33-iwlwifi
...
Note that pid 0 exists for each cpu so have comm of 'swapper/N'.
Also now it
[PATCH 04/10] perf tools: Pass evlist to setup_sorting()
This is a preparation to support dynamic sort keys for tracepoint
events. Dynamic sort keys can be created for specific fields in trace
events so it needs the event information.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-annotate.c | 2 +-
tools/perf/builtin-diff.c | 2 +-
tools/perf/builtin-report.c | 2 +-
tools/perf/builtin-top.c | 14 +++---
tools/perf/tests/hists_cumulate.c | 8
tools/perf/tests/hists_filter.c | 2 +-
tools/perf/tests/hists_link.c | 2 +-
tools/perf/tests/hists_output.c | 10 +-
tools/perf/util/sort.c| 15 +--
tools/perf/util/sort.h| 5 +++--
10 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index b5b8db0b0338..cc5c1267c738 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -370,7 +370,7 @@ int cmd_annotate(int argc, const char **argv, const char
*prefix __maybe_unused)
if (ret < 0)
goto out_delete;
- if (setup_sorting() < 0)
+ if (setup_sorting(NULL) < 0)
usage_with_options(annotate_usage, options);
if (annotate.use_stdio)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 69f5b1feff39..87063835d741 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -1279,7 +1279,7 @@ int cmd_diff(int argc, const char **argv, const char
*prefix __maybe_unused)
sort__mode = SORT_MODE__DIFF;
- if (setup_sorting() < 0)
+ if (setup_sorting(NULL) < 0)
usage_with_options(diff_usage, options);
setup_pager();
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 2a7330b99b82..ea53c816640a 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -897,7 +897,7 @@ repeat:
symbol_conf.cumulate_callchain = false;
}
- if (setup_sorting() < 0) {
+ if (setup_sorting(session->evlist) < 0) {
if (sort_order)
parse_options_usage(report_usage, options, "s", 1);
if (field_order)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 9ebd67a42ede..005825942441 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1231,11 +1231,17 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
if (argc)
usage_with_options(top_usage, options);
+ if (!top.evlist->nr_entries &&
+ perf_evlist__add_default(top.evlist) < 0) {
+ pr_err("Not enough memory for event selector list\n");
+ goto out_delete_evlist;
+ }
+
sort__mode = SORT_MODE__TOP;
/* display thread wants entries to be collapsed in a different tree */
sort__need_collapse = 1;
- if (setup_sorting() < 0) {
+ if (setup_sorting(top.evlist) < 0) {
if (sort_order)
parse_options_usage(top_usage, options, "s", 1);
if (field_order)
@@ -1277,12 +1283,6 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
goto out_delete_evlist;
}
- if (!top.evlist->nr_entries &&
- perf_evlist__add_default(top.evlist) < 0) {
- ui__error("Not enough memory for event selector list\n");
- goto out_delete_evlist;
- }
-
symbol_conf.nr_events = top.evlist->nr_entries;
if (top.delay_secs < 1)
diff --git a/tools/perf/tests/hists_cumulate.c
b/tools/perf/tests/hists_cumulate.c
index 8292948bc5f9..e36089212061 100644
--- a/tools/perf/tests/hists_cumulate.c
+++ b/tools/perf/tests/hists_cumulate.c
@@ -281,7 +281,7 @@ static int test1(struct perf_evsel *evsel, struct machine
*machine)
symbol_conf.cumulate_callchain = false;
perf_evsel__reset_sample_bit(evsel, CALLCHAIN);
- setup_sorting();
+ setup_sorting(NULL);
callchain_register_param(_param);
err = add_hist_entries(hists, machine);
@@ -428,7 +428,7 @@ static int test2(struct perf_evsel *evsel, struct machine
*machine)
symbol_conf.cumulate_callchain = false;
perf_evsel__set_sample_bit(evsel, CALLCHAIN);
- setup_sorting();
+ setup_sorting(NULL);
callchain_register_param(_param);
err = add_hist_entries(hists, machine);
@@ -486,7 +486,7 @@ static int test3(struct perf_evsel *evsel, struct machine
*machine)
symbol_conf.cumulate_callchain = true;
perf_evsel__reset_sample_bit(evsel, CALLCHAIN);
- setup_sorting();
+ setup_sorting(NULL);
callchain_register_param(_param);
err = add_hist_entries(hists, machine);
@@ -670,7 +670,7 @@ static int test4(struct perf_evsel *evsel, struct machine
*machine)
symbol_conf.cumulate_callchain = true;
[PATCH 09/10] perf tools: Make 'trace' sort key default for tracepoint events
When an evlist contains tracepoint events only, use 'trace' sort key as
default. This will make users more convenient to see trace result.
Suggested-by: Jiri Olsa
Cc: Steven Rostedt
Signed-off-by: Namhyung Kim
---
tools/perf/util/sort.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index f38a0577967a..43cb9b638718 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -2067,7 +2067,7 @@ static int sort_dimension__add(const char *tok,
return -ESRCH;
}
-static const char *get_default_sort_order(void)
+static const char *get_default_sort_order(struct perf_evlist *evlist)
{
const char *default_sort_orders[] = {
default_sort_order,
@@ -2076,13 +2076,25 @@ static const char *get_default_sort_order(void)
default_top_sort_order,
default_diff_sort_order,
};
+ bool use_trace = true;
+ struct perf_evsel *evsel;
BUG_ON(sort__mode >= ARRAY_SIZE(default_sort_orders));
+ evlist__for_each(evlist, evsel) {
+ if (evsel->attr.type != PERF_TYPE_TRACEPOINT) {
+ use_trace = false;
+ break;
+ }
+ }
+
+ if (use_trace)
+ return "trace";
+
return default_sort_orders[sort__mode];
}
-static int setup_sort_order(void)
+static int setup_sort_order(struct perf_evlist *evlist)
{
char *new_sort_order;
@@ -2103,7 +2115,7 @@ static int setup_sort_order(void)
* because it's checked over the rest of the code.
*/
if (asprintf(_sort_order, "%s,%s",
-get_default_sort_order(), sort_order + 1) < 0) {
+get_default_sort_order(evlist), sort_order + 1) < 0) {
error("Not enough memory to set up --sort");
return -ENOMEM;
}
@@ -2118,7 +2130,7 @@ static int __setup_sorting(struct perf_evlist *evlist)
const char *sort_keys;
int ret = 0;
- ret = setup_sort_order();
+ ret = setup_sort_order(evlist);
if (ret)
return ret;
@@ -2132,7 +2144,7 @@ static int __setup_sorting(struct perf_evlist *evlist)
return 0;
}
- sort_keys = get_default_sort_order();
+ sort_keys = get_default_sort_order(evlist);
}
str = strdup(sort_keys);
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/10] perf hist: Pass struct sample to __hists__add_entry()
This is a preparation to add more info into the hist_entry. Also it
already passes too many argument, so passing sample directly will reduce
the overhead of the function call.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-annotate.c | 7 +--
tools/perf/builtin-diff.c | 11 +--
tools/perf/tests/hists_link.c | 6 +++---
tools/perf/util/hist.c| 31 +--
tools/perf/util/hist.h| 4 ++--
5 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index e18f1b995ffd..b5b8db0b0338 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -47,7 +47,7 @@ struct perf_annotate {
};
static int perf_evsel__add_sample(struct perf_evsel *evsel,
- struct perf_sample *sample __maybe_unused,
+ struct perf_sample *sample,
struct addr_location *al,
struct perf_annotate *ann)
{
@@ -72,7 +72,10 @@ static int perf_evsel__add_sample(struct perf_evsel *evsel,
return 0;
}
- he = __hists__add_entry(hists, al, NULL, NULL, NULL, 1, 1, 0, true);
+ sample->period = 1;
+ sample->weight = 1;
+
+ he = __hists__add_entry(hists, al, NULL, NULL, NULL, sample, true);
if (he == NULL)
return -ENOMEM;
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 0b180a885ba3..69f5b1feff39 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -311,11 +311,11 @@ static int formula_fprintf(struct hist_entry *he, struct
hist_entry *pair,
}
static int hists__add_entry(struct hists *hists,
- struct addr_location *al, u64 period,
- u64 weight, u64 transaction)
+ struct addr_location *al,
+ struct perf_sample *sample)
{
- if (__hists__add_entry(hists, al, NULL, NULL, NULL, period, weight,
- transaction, true) != NULL)
+ if (__hists__add_entry(hists, al, NULL, NULL, NULL,
+ sample, true) != NULL)
return 0;
return -ENOMEM;
}
@@ -336,8 +336,7 @@ static int diff__process_sample_event(struct perf_tool
*tool __maybe_unused,
return -1;
}
- if (hists__add_entry(hists, , sample->period,
-sample->weight, sample->transaction)) {
+ if (hists__add_entry(hists, , sample)) {
pr_warning("problem incrementing symbol period, skipping
event\n");
goto out_put;
}
diff --git a/tools/perf/tests/hists_link.c b/tools/perf/tests/hists_link.c
index 6243e2b2a245..9eac98daecb8 100644
--- a/tools/perf/tests/hists_link.c
+++ b/tools/perf/tests/hists_link.c
@@ -64,7 +64,7 @@ static int add_hist_entries(struct perf_evlist *evlist,
struct machine *machine)
struct perf_evsel *evsel;
struct addr_location al;
struct hist_entry *he;
- struct perf_sample sample = { .period = 1, };
+ struct perf_sample sample = { .period = 1, .weight = 1, };
size_t i = 0, k;
/*
@@ -90,7 +90,7 @@ static int add_hist_entries(struct perf_evlist *evlist,
struct machine *machine)
goto out;
he = __hists__add_entry(hists, , NULL,
- NULL, NULL, 1, 1, 0, true);
+ NULL, NULL, , true);
if (he == NULL) {
addr_location__put();
goto out;
@@ -116,7 +116,7 @@ static int add_hist_entries(struct perf_evlist *evlist,
struct machine *machine)
goto out;
he = __hists__add_entry(hists, , NULL,
- NULL, NULL, 1, 1, 0, true);
+ NULL, NULL, , true);
if (he == NULL) {
addr_location__put();
goto out;
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 56e97f5af598..039bb91d0a92 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -461,7 +461,7 @@ struct hist_entry *__hists__add_entry(struct hists *hists,
struct symbol *sym_parent,
struct branch_info *bi,
struct mem_info *mi,
- u64 period, u64 weight, u64 transaction,
+ struct perf_sample *sample,
bool sample_self)
{
struct hist_entry entry = {
@@ -478,15 +478,15 @@ struct hist_entry
[PATCH 05/10] perf tools: Add dynamic sort key for tracepoint events
The existing sort keys are less useful for tracepoint events in that
they are always sampled at a same location.
For example, report on sched:sched_switch event looks like following
# Overhead Command Shared Object Symbol
# ... ..
#
47.22% swapper [kernel.vmlinux] [k] __schedule
21.67% transmission-gt [kernel.vmlinux] [k] __schedule
8.23% netctl-auto [kernel.vmlinux] [k] __schedule
5.53% kworker/0:1H [kernel.vmlinux] [k] __schedule
1.98% Xephyr [kernel.vmlinux] [k] __schedule
1.33% irq/33-iwlwifi [kernel.vmlinux] [k] __schedule
1.17% wpa_cli [kernel.vmlinux] [k] __schedule
1.13% rcu_preempt [kernel.vmlinux] [k] __schedule
0.85% ksoftirqd/0 [kernel.vmlinux] [k] __schedule
0.77% Timer[kernel.vmlinux] [k] __schedule
In fact, tracepoints have meaningful information in their fields but
there's no way to use in the perf report currently. The dynamic sort
keys are to overcome this problem.
The sched:sched_switch events have following fields:
# sudo cat /sys/kernel/debug/tracing/events/sched/sched_switch/format
name: sched_switch
ID: 268
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:char prev_comm[16]; offset:8; size:16; signed:1;
field:pid_t prev_pid; offset:24; size:4; signed:1;
field:int prev_prio; offset:28; size:4; signed:1;
field:long prev_state;offset:32; size:8; signed:1;
field:char next_comm[16]; offset:40; size:16; signed:1;
field:pid_t next_pid; offset:56; size:4; signed:1;
field:int next_prio; offset:60; size:4; signed:1;
print fmt: "prev_comm=%s prev_pid=%d prev_prio=%d prev_state=%s%s ==>
next_comm=%s next_pid=%d next_prio=%d",
REC->prev_comm, REC->prev_pid, REC->prev_prio,
REC->prev_state & (2048-1) ? __print_flags(REC->prev_state & (2048-1),
"|", { 1, "S"} , { 2, "D" }, { 4, "T" }, { 8, "t" }, { 16, "Z" }, { 32, "X"
},
{ 64, "x" }, { 128, "K"}, { 256, "W" }, { 512, "P" }, { 1024, "N" }) : "R",
REC->prev_state & 2048 ? "+" : "", REC->next_comm, REC->next_pid,
REC->next_prio
With dynamic sort keys, you can use as a sort key. Those
dynamic keys are checked and created on demand. For instance, below is
to sort by next_pid field on the same data file.
$ perf report -s comm,sched:sched_switch.next_pid --stdio
...
# Overhead Commandnext_pid
# ... ..
#
21.23% transmission-gt 0
20.86% swapper 17773
6.62% netctl-auto 0
5.25% swapper 109
5.21% kworker/0:1H 0
1.98% Xephyr0
1.98% swapper6524
1.98% swapper 27478
1.37% swapper 27476
1.17% swapper 233
Multiple dynamic sort keys are also supported:
$ perf report -s
comm,sched:sched_switch.next_pid,sched:sched_switch.next_comm --stdio
...
# Overhead Commandnext_pid next_comm
# ... ..
#
20.86% swapper 17773 transmission-gt
9.64% transmission-gt 0 swapper/0
9.16% transmission-gt 0 swapper/2
5.25% swapper 109 kworker/0:1H
5.21% kworker/0:1H 0 swapper/0
2.14% netctl-auto 0 swapper/2
1.98% netctl-auto 0 swapper/0
1.98% swapper6524Xephyr
1.98% swapper 27478 netctl-auto
1.78% transmission-gt 0 swapper/3
1.53% Xephyr0 swapper/0
1.29% netctl-auto 0 swapper/1
1.29% swapper 27476 netctl-auto
1.21% netctl-auto 0 swapper/3
1.17% swapper 233irq/33-iwlwifi
Note that pid 0 exists for each cpu so have comm of 'swapper/N'.
Cc: Steven Rostedt
Signed-off-by: Namhyung Kim
---
tools/perf/util/sort.c | 223 +
1 file changed, 223 insertions(+)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 0c038a27fe5c..f2bac1c149a9 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -1531,6 +1531,226 @@ static int __sort_dimension__add_hpp_output(struct
sort_dimension *sd)
return 0;
}
Re: [PATCH] lightnvm: unlock rq and free ppa_list after submission failed
When rrpc_write_ppalist_rq and rrpc_read_ppalist_rq succeed, we setup
rq correctly, but nvm_submit_io failed due to cannot allocate request
or nvme_nvm_command, we return error but forget to do the cleanup job
this patch mentioned.
2015-12-21 19:22 GMT+08:00 Matias Bjørling :
> On 12/21/2015 08:32 AM, Wenwei Tao wrote:
>>
>> after io submission failed, before free rq, delete rq from
>> rrpc's inflight list, leave no bad item in the list. And
>> free rq's ppa_list to avoid memory leak.
>>
>> Signed-off-by: Wenwei Tao
>> ---
>> drivers/lightnvm/rrpc.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
>> index a1e7488..c0886a8 100644
>> --- a/drivers/lightnvm/rrpc.c
>> +++ b/drivers/lightnvm/rrpc.c
>> @@ -843,6 +843,12 @@ static int rrpc_submit_io(struct rrpc *rrpc, struct
>> bio *bio,
>> if (err) {
>> pr_err("rrpc: I/O submission failed: %d\n", err);
>> bio_put(bio);
>> + if (!(flags & NVM_IOTYPE_GC)) {
>> + rrpc_unlock_rq(rrpc, rqd);
>> + if (rqd->nr_pages > 1)
>> + nvm_dev_dma_free(rrpc->dev,
>> + rqd->ppa_list, rqd->dma_ppa_list);
>> + }
>> return NVM_IO_ERR;
>> }
>>
>>
>
> I can't seem to find the bug. nvm_dev_dma_free is called when
> rrpc_write_ppalist_rq and rrpc_read_ppalist_rq fails. Where is it missing?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86/fpu: Properly align size in CHECK_MEMBER_AT_END_OF macro
The CHECK_MEMBER_AT_END_OF(TYPE, MEMBER) checks whether MEMBER
is last member of TYPE by evaluating:
offsetof(TYPE::MEMBER) + sizeof(TYPE::MEMBER) == sizeof(TYPE)
and ensuring TYPE::MEMBER is the last member of the TYPE.
This condition breaks on structs that are padded to be
aligned. This patch ensures the TYPE alignment is taken
into account.
This bug was revealed after adding cacheline alignment into
struct sched_entity, which broke task_struct::thread check:
CHECK_MEMBER_AT_END_OF(struct task_struct, thread);
Signed-off-by: Jiri Olsa
---
arch/x86/kernel/fpu/init.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index be39b5fde4b9..8e839e7f5e2f 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -143,9 +143,18 @@ static void __init fpu__init_system_generic(void)
unsigned int xstate_size;
EXPORT_SYMBOL_GPL(xstate_size);
-/* Enforce that 'MEMBER' is the last field of 'TYPE': */
+/* Get alignment of the TYPE. */
+#define TYPE_ALIGN(TYPE) offsetof(struct { char x; TYPE test; }, test)
+
+/*
+ * Enforce that 'MEMBER' is the last field of 'TYPE'.
+ *
+ * Align the computed size with alignment of the TYPE,
+ * because that's how C aligns structs.
+ */
#define CHECK_MEMBER_AT_END_OF(TYPE, MEMBER) \
- BUILD_BUG_ON(sizeof(TYPE) != offsetofend(TYPE, MEMBER))
+ BUILD_BUG_ON(sizeof(TYPE) != ALIGN(offsetofend(TYPE, MEMBER), \
+ TYPE_ALIGN(TYPE)))
/*
* We append the 'struct fpu' to the task_struct:
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input
On Thu, Nov 19, 2015 at 9:33 PM, Geert Uytterhoeven
wrote:
> On Thu, Nov 19, 2015 at 9:19 PM, Laurent Pinchart
> wrote:
>> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
>>> diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index
>>> 2c9e6b8477e92792..8efc9b6f35637fbb 100644
>>> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> @@ -43,6 +43,9 @@ Required properties:
>>>- clocks: Must contain a phandle and clock-specifier pair for each entry
>>> in clock-names.
>>>- clock-names: Must contain "fck" for the SCIx UART functional clock.
>>> +On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>>
>> Could you list the SCIFA variants that support external clocks ?
>
> The list is in the commit description of "[PATCH 19/25] serial: sh-sci: Add
> support for optional external (H)SCK input": sh7723, sh7724, and r8a7740.
>
> Note that the list is probably incomplete, so I don't know if it's that useful
> to have it in the binding docs. Especially as I haven't verified yet that it
> actually works ;-)
For the record: on r8a7740, this feature is not available on SCIFA instances
2-7. The sole pins providing access to SCIFA_SCK[01] are muxed for Ethernet use
on r8a7740/armadillo. So it's unlikely I'll be able to support and test this.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
On Monday 21 December 2015, Tomasz Nowicki wrote: > On 21.12.2015 13:10, Lorenzo Pieralisi wrote: > > On Fri, Dec 18, 2015 at 06:56:39PM +, ok...@codeaurora.org wrote: > >> I have multiple root ports with the same IO port configuration in the > >> current ACPI table. > >> > >> Root port 0 = IO range 0x1000-0x10FFF > >> Root port 1 = IO range 0x1000-0x10FFF > >> Root port 2 = IO range 0x1000-0x10FFF > > > > It is fine. You end up mapping for each of those a 4k window of the > > virtual address space allocated to IO and that's what you will have in > > the kernel PCI resources (not in the HW BARs though). If that was a problem > > it would be even for the current DT host controllers eg: > > > > arch/arm64/boot/dts/apm/apm-storm.dtsi > > > > it should not be (again I will let Arnd comment on this since he may be > > aware of issues encountered on other arches/platforms). > > > > Root port 0 = IO range 0x1000-0x10FFF > Root port 1 = IO range 0x1000-0x10FFF > Root port 2 = IO range 0x1000-0x10FFF > > If above ranges are mapped into different CPU windows, then yes, it is fine. Ideally, they should all be the same CPU address so we only have to map the window once, each device gets an address below 64K, and you can have legacy port numbers (below 4K) on any bus, which is required to make certain GPUs work. I haven't actually seen anyone do that on ARM though, every implementation so far has a separate mapping per host bridge, and we can cope with that too, and we can live with either overlapping bus addresses or unique bus addresses, any of them can be expressed by the PCI core in Linux, we just have to make sure that we correctly translate the firmware tables into our internal structures. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] irqchip/gic: Remove static irq_chip definition for eoimode1
There are only 3 differences (not including the name) in the definitions
of the gic_chip and gic_eoimode1_chip structures. Instead of statically
defining the gic_eoimode1_chip structure, remove it and populate the
eoimode1 functions dynamically for the appropriate GIC irqchips.
Signed-off-by: Jon Hunter
---
drivers/irqchip/irq-gic.c | 26 +-
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index fcbe0b90870d..94ad60c424a7 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -394,23 +394,6 @@ static struct irq_chip gic_chip = {
IRQCHIP_MASK_ON_SUSPEND,
};
-static struct irq_chip gic_eoimode1_chip = {
- .name = "GICv2",
- .irq_mask = gic_eoimode1_mask_irq,
- .irq_unmask = gic_unmask_irq,
- .irq_eoi= gic_eoimode1_eoi_irq,
- .irq_set_type = gic_set_type,
-#ifdef CONFIG_SMP
- .irq_set_affinity = gic_set_affinity,
-#endif
- .irq_get_irqchip_state = gic_irq_get_irqchip_state,
- .irq_set_irqchip_state = gic_irq_set_irqchip_state,
- .irq_set_vcpu_affinity = gic_irq_set_vcpu_affinity,
- .flags = IRQCHIP_SET_TYPE_MASKED |
- IRQCHIP_SKIP_SET_WAKE |
- IRQCHIP_MASK_ON_SUSPEND,
-};
-
void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
{
BUG_ON(gic_nr >= CONFIG_ARM_GIC_MAX_NR);
@@ -1030,13 +1013,14 @@ static void __init __gic_init_bases(unsigned int
gic_nr, int irq_start,
gic_check_cpu_features();
gic = _data[gic_nr];
+ gic->chip = gic_chip;
+ gic->chip.name = kasprintf(GFP_KERNEL, "GIC-%d", gic_nr);
/* Initialize irq_chip */
if (static_key_true(_deactivate) && gic_nr == 0) {
- gic->chip = gic_eoimode1_chip;
- } else {
- gic->chip = gic_chip;
- gic->chip.name = kasprintf(GFP_KERNEL, "GIC-%d", gic_nr);
+ gic->chip.irq_mask = gic_eoimode1_mask_irq;
+ gic->chip.irq_eoi = gic_eoimode1_eoi_irq;
+ gic->chip.irq_set_vcpu_affinity = gic_irq_set_vcpu_affinity;
}
#ifdef CONFIG_GIC_NON_BANKED
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] irqchip/gic: Only populate set_affinity for the root controller
Setting the affinity of an IRQ, it only applicable for the root
interrupt controller and so only populate this operator for the root
controller.
Signed-off-by: Jon Hunter
---
drivers/irqchip/irq-gic.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 94ad60c424a7..53b03f6038c1 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -384,9 +384,6 @@ static struct irq_chip gic_chip = {
.irq_unmask = gic_unmask_irq,
.irq_eoi= gic_eoi_irq,
.irq_set_type = gic_set_type,
-#ifdef CONFIG_SMP
- .irq_set_affinity = gic_set_affinity,
-#endif
.irq_get_irqchip_state = gic_irq_get_irqchip_state,
.irq_set_irqchip_state = gic_irq_set_irqchip_state,
.flags = IRQCHIP_SET_TYPE_MASKED |
@@ -1017,10 +1014,16 @@ static void __init __gic_init_bases(unsigned int
gic_nr, int irq_start,
gic->chip.name = kasprintf(GFP_KERNEL, "GIC-%d", gic_nr);
/* Initialize irq_chip */
- if (static_key_true(_deactivate) && gic_nr == 0) {
- gic->chip.irq_mask = gic_eoimode1_mask_irq;
- gic->chip.irq_eoi = gic_eoimode1_eoi_irq;
- gic->chip.irq_set_vcpu_affinity = gic_irq_set_vcpu_affinity;
+ if (gic_nr == 0) {
+ if (IS_ENABLED(CONFIG_SMP))
+ gic->chip.irq_set_affinity = gic_set_affinity;
+
+ if (static_key_true(_deactivate)) {
+ gic->chip.irq_mask = gic_eoimode1_mask_irq;
+ gic->chip.irq_eoi = gic_eoimode1_eoi_irq;
+ gic->chip.irq_set_vcpu_affinity =
+ gic_irq_set_vcpu_affinity;
+ }
}
#ifdef CONFIG_GIC_NON_BANKED
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86/efi-bgrt: Replace early_memremap() with memremap()
Môshe reported the following warning triggered on his machine since
commit 50a0cb565246 ("x86/efi-bgrt: Fix kernel panic when mapping BGRT
data"),
[0.026936] [ cut here ]
[0.026941] WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:137
__early_ioremap+0x102/0x1bb()
[0.026941] Modules linked in:
[0.026944] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc1 #2
[0.026945] Hardware name: Dell Inc. XPS 13 9343/09K8G1, BIOS A05
07/14/2015
[0.026946] 900f03d5a116524d 81c03e60
813a3fff
[0.026948] 81c03e98 810a0852
d7b76000
[0.026949] 0001 0001
017c
[0.026951] Call Trace:
[0.026955] [] dump_stack+0x44/0x55
[0.026958] [] warn_slowpath_common+0x82/0xc0
[0.026959] [] warn_slowpath_null+0x1a/0x20
[0.026961] [] __early_ioremap+0x102/0x1bb
[0.026962] [] early_memremap+0x13/0x15
[0.026964] [] efi_bgrt_init+0x162/0x1ad
[0.026966] [] efi_late_init+0x9/0xb
[0.026968] [] start_kernel+0x46f/0x49f
[0.026970] [] ? early_idt_handler_array+0x120/0x120
[0.026972] [] x86_64_start_reservations+0x2a/0x2c
[0.026974] [] x86_64_start_kernel+0x14a/0x16d
[0.026977] ---[ end trace f9b3812eb8e24c58 ]---
[0.026978] efi_bgrt: Ignoring BGRT: failed to map image memory
early_memremap() has an upper limit on the size of mapping it can
handle which is ~200KB. Clearly the BGRT image on Môshe's machine is
much larger than that.
There's actually no reason to restrict ourselves to using the early_*
version of memremap() - the ACPI BGRT driver is invoked late enough in
boot that we can use the standard version, with the benefit that the
late version allows mappings of arbitrary size.
Reported-by: Môshe van der Sterre
Tested-by: Môshe van der Sterre
Cc: Josh Triplett
Cc: Sai Praneeth Prakhya
Cc: Borislav Petkov
Signed-off-by: Matt Fleming
---
arch/x86/platform/efi/efi-bgrt.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
index bf51f4c02562..b0970661870a 100644
--- a/arch/x86/platform/efi/efi-bgrt.c
+++ b/arch/x86/platform/efi/efi-bgrt.c
@@ -72,14 +72,14 @@ void __init efi_bgrt_init(void)
return;
}
- image = early_memremap(bgrt_tab->image_address, sizeof(bmp_header));
+ image = memremap(bgrt_tab->image_address, sizeof(bmp_header),
MEMREMAP_WB);
if (!image) {
pr_err("Ignoring BGRT: failed to map image header memory\n");
return;
}
memcpy(_header, image, sizeof(bmp_header));
- early_memunmap(image, sizeof(bmp_header));
+ memunmap(image);
bgrt_image_size = bmp_header.size;
bgrt_image = kmalloc(bgrt_image_size, GFP_KERNEL | __GFP_NOWARN);
@@ -89,7 +89,7 @@ void __init efi_bgrt_init(void)
return;
}
- image = early_memremap(bgrt_tab->image_address, bmp_header.size);
+ image = memremap(bgrt_tab->image_address, bmp_header.size, MEMREMAP_WB);
if (!image) {
pr_err("Ignoring BGRT: failed to map image memory\n");
kfree(bgrt_image);
@@ -98,5 +98,5 @@ void __init efi_bgrt_init(void)
}
memcpy(bgrt_image, image, bgrt_image_size);
- early_memunmap(image, bmp_header.size);
+ memunmap(image);
}
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: i2c-hid: Prevent sending reports from racing with device reset
On Dec 21 2015 or thereabouts, Mika Westerberg wrote:
> When an i2c-hid device is resumed from system sleep the driver resets
> the device to be sure it is in known state. The device is expected to
> issue an interrupt when reset is complete.
>
> This reset might take few milliseconds to complete so if the HID driver
> on top (hid-rmi) starts to set up the device by sending feature reports
> etc. the device might not issue the reset complete interrupt anymore.
>
> Below is what happens to touchpad on Lenovo Yoga 900 during resume from
> system sleep:
>
> [ 24.790951] i2c_hid i2c-SYNA2B29:00: i2c_hid_hwreset
> [ 24.790973] i2c_hid i2c-SYNA2B29:00: i2c_hid_set_power
> [ 24.790982] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=22 00 00 08
> [ 24.793011] i2c_hid i2c-SYNA2B29:00: resetting...
> [ 24.793016] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=22 00 00 01
>
> Here i2c-hid sends reset command to the touchpad.
>
> [ 24.794012] i2c_hid i2c-SYNA2B29:00: input: 06 00 01 00 00 00
> [ 24.794051] i2c_hid i2c-SYNA2B29:00: i2c_hid_set_or_send_report
> [ 24.794059] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command:
> cmd=22 00 3f 03 0f 23 00 04 00 0f 01
>
> Now hid-rmi puts the touchpad to correct mode by sending it a feature
> report. This makes the touchpad not to issue reset complete interrupt.
>
> [ 24.796092] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: waiting...
>
> i2c-hid starts to wait for the reset interrupt to trigger which never
> happens.
>
> [ 24.798304] i2c_hid i2c-SYNA2B29:00: i2c_hid_set_or_send_report
> [ 24.798313] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command:
> cmd=25 00 17 00 09 01 42 00 2e 00 19 19 00 10 cc 06 74 04 0f
> 19 00 00 00 00 00
>
> Yet another output report from hid-rmi driver.
>
> [ 29.795630] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: finished.
> [ 29.795637] i2c_hid i2c-SYNA2B29:00: failed to reset device.
>
> After 5 seconds i2c-hid driver times out.
>
> [ 29.795642] i2c_hid i2c-SYNA2B29:00: i2c_hid_set_power
> [ 29.795649] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=22 00 01 08
> [ 29.797576] dpm_run_callback(): i2c_hid_resume+0x0/0xb0 returns -61
> [ 29.797584] PM: Device i2c-SYNA2B29:00 failed to resume: error -61
>
> After this the touchpad does not work anymore (and also resume itself
> gets slowed down because of the timeout).
>
> Prevent sending of feature/output reports while the device is being
> reset by adding a mutex which is held during that time.
>
> Reported-by: Nish Aravamudan
> Reported-by: Linus Torvalds
> Suggested-by: Benjamin Tissoires
> Signed-off-by: Mika Westerberg
> ---
Looks good to me.
Reviewed-by: Benjamin Tissoires
Thanks for the patch Mika!
Cheers,
Benjamin
> drivers/hid/i2c-hid/i2c-hid.c | 21 ++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index 10bd8e6e4c9c..fc5ef1c25ed4 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -151,6 +151,7 @@ struct i2c_hid {
> struct i2c_hid_platform_data pdata;
>
> boolirq_wake_enabled;
> + struct mutexreset_lock;
> };
>
> static int __i2c_hid_command(struct i2c_client *client,
> @@ -356,9 +357,16 @@ static int i2c_hid_hwreset(struct i2c_client *client)
>
> i2c_hid_dbg(ihid, "%s\n", __func__);
>
> + /*
> + * This prevents sending feature reports while the device is
> + * being reset. Otherwise we may lose the reset complete
> + * interrupt.
> + */
> + mutex_lock(>reset_lock);
> +
> ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
> if (ret)
> - return ret;
> + goto out_unlock;
>
> i2c_hid_dbg(ihid, "resetting...\n");
>
> @@ -366,10 +374,11 @@ static int i2c_hid_hwreset(struct i2c_client *client)
> if (ret) {
> dev_err(>dev, "failed to reset device.\n");
> i2c_hid_set_power(client, I2C_HID_PWR_SLEEP);
> - return ret;
> }
>
> - return 0;
> +out_unlock:
> + mutex_unlock(>reset_lock);
> + return ret;
> }
>
> static void i2c_hid_get_input(struct i2c_hid *ihid)
> @@ -587,12 +596,15 @@ static int i2c_hid_output_raw_report(struct hid_device
> *hid, __u8 *buf,
> size_t count, unsigned char report_type, bool use_data)
> {
> struct i2c_client *client = hid->driver_data;
> + struct i2c_hid *ihid = i2c_get_clientdata(client);
> int report_id = buf[0];
> int ret;
>
> if (report_type == HID_INPUT_REPORT)
> return -EINVAL;
>
> + mutex_lock(>reset_lock);
> +
> if (report_id) {
> buf++;
> count--;
> @@ -605,6 +617,8 @@ static int i2c_hid_output_raw_report(struct hid_device
> *hid, __u8 *buf,
> if (report_id && ret >= 0)
>
Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
On Monday 21 December 2015, Gabriele Paoloni wrote: > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > > ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki > > Some platforms may not be fully compliant with generic set of PCI > > config accessors. For these cases we implement the way to overwrite > > accessors set before PCI buses enumeration. Algorithm that overwrite > > accessors matches against platform ID (DMI), domain and bus number, > > hopefully enough for all cases. All quirks can be defined using: > > DECLARE_ACPI_MCFG_FIXUP() and keep self contained. > > I've got a couple of comments/questions about this patch.. > > 1) So according to this mechanism quirks would be supported only by >vendors whose BIOS are SMBIOS compliant. Now personally I am ok >with this but I don't know if this is OK in general as it would >narrow down the number of platforms that would be able to define >the quirks... >Lorenzo, Arnd what is your opinion here? I'd rather not see the quirks in mainline at all, and only support SBSA compliant machines, or require the BIOS to work around the hardware quirks differently (e.g. by trapping config space access through secure firmware, or going through an AML method to be defined). I'm certainly ok with making it depend on SMBIOS if we are going to use something like this. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] dt-bindings: sound: add devicetree document for rt5616
Am Montag, 21. Dezember 2015, 21:18:14 schrieb Caesar Wang: > Add the description for rt5616 codec. > > Signed-off-by: Caesar Wang > --- > > Documentation/devicetree/bindings/sound/rt5616.txt | 38 > ++ 1 file changed, 38 insertions(+) > create mode 100644 Documentation/devicetree/bindings/sound/rt5616.txt > > diff --git a/Documentation/devicetree/bindings/sound/rt5616.txt > b/Documentation/devicetree/bindings/sound/rt5616.txt new file mode 100644 > index 000..af96207 > --- /dev/null > +++ b/Documentation/devicetree/bindings/sound/rt5616.txt > @@ -0,0 +1,38 @@ > +RT5616 audio CODEC > + > +This device supports I2C only. > + > +Required properties: > + > +- compatible : "realtek,rt5616". > + > +- reg : The I2C address of the device. > + > +Optional properties: you don't have optional properties, so that headline should probably also not be here. Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: next-20151221 build: 2 failures 13 warnings (next-20151221)
Just looking at the remaining warnings/errors in linux-next: On Monday 21 December 2015, Build bot for Mark Brown wrote: > ../fs/orangefs/orangefs-kernel.h:773:2: error: implicit declaration of > function 'ornagefs_inode_lock' [-Werror=implicit-function-declaration] > ../fs/orangefs/orangefs-kernel.h:773:2: error: implicit declaration of > function 'ornagefs_inode_lock' [-Werror=implicit-function-declaration] > ../fs/orangefs/orangefs-kernel.h:773:2: error: implicit declaration of > function 'ornagefs_inode_lock' [-Werror=implicit-function-declaration] > ../fs/orangefs/orangefs-kernel.h:773:2: error: implicit declaration of > function 'ornagefs_inode_lock' [-Werror=implicit-function-declaration] I just sent a patch for this. > arm64-allmodconfig : PASS, 0 errors, 5 warnings, 0 section mismatches > > Warnings: > ../drivers/gpu/drm/vc4/vc4_validate.c:864:4: warning: format '%d' > expects argument of type 'int', but argument 4 has type 'size_t' [-Wformat=] I have a trivial patch, need to send it out. > ../drivers/staging/emxx_udc/emxx_udc.c:843:45: warning: cast from > pointer to integer of different size [-Wpointer-to-int-cast] > ../drivers/staging/emxx_udc/emxx_udc.c:1085:45: warning: cast from > pointer to integer of different size [-Wpointer-to-int-cast] > ../drivers/staging/emxx_udc/emxx_udc.c:2731:6: warning: cast from > pointer to integer of different size [-Wpointer-to-int-cast] Submitted this one again last week, I had sent it a month ago, but the maintainer was busy. > ../drivers/tty/serial/amba-pl011.c:190:27: warning: 'vendor_zte' > defined but not used [-Wunused-variable] rmk pointed out the problem when the patch was sent originally, no idea what we should do about it other than reverting the patch that introduced the unused code. > Warnings: > :1307:2: warning: #warning syscall copy_file_range not > implemented [-Wcpp] Not sure how we can improve this, the same thing seems to happen every time a new syscall gets introduced. The actual change is trivial, but we need a better method to sync all architectures. > ../kernel/printk/nmi.c:143:3: warning: format '%lu' expects argument > of type 'long unsigned int', but argument 3 has type 'size_t' [-Wformat] Sent a patch the other day. > ../drivers/gpio/gpiolib.c:225:31: warning: 'iterator' may be used > uninitialized in this function [-Wmaybe-uninitialized] Introduced by Bamvor, currently discussing a solution with him and Linus. We can either shut up the compiler or rewrite the function in a nicer way. > arm-multi_v7_defconfig : PASS, 0 errors, 8 warnings, 0 section mismatches > > Warnings: > arch/arm/configs/multi_v7_defconfig:433:warning: symbol value 'm' > invalid for MFD_DA9063 I need to look into this, probably the result of a defconfig change we merged, but it's not clear whether the driver should be a module, or the defconfig should have it built-in. > ../net/bluetooth/mgmt.c:5471:8: warning: 'r192' may be used > uninitialized in this function [-Wmaybe-uninitialized] > ../net/bluetooth/mgmt.c:5471:8: warning: 'h192' may be used > uninitialized in this function [-Wmaybe-uninitialized] I don't see these with gcc-5.1 > ../crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is > larger than 1024 bytes [-Wframe-larger-than=] no this one. If we want to fix it, it's probably best to change the optimization level of the file, something gets misoptimzed here and it's clear it should not use that much stack. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG REPORT]: ARM64: perf: System hung in perf test
On Mon, Dec 21, 2015 at 08:56:03PM +0800, Wangnan (F) wrote: > System hung can be reproduced on qemu and real hardware using: > > # perf test -v signal > > If qemu is started with '-smp 1', system hung. In real hardware and in > qemu with smp > 1, the result is: That sounds like a qemu issue... > # /perf test -v signal > 17: Test breakpoint overflow signal handler : > --- start --- > test child forked, pid 792 > count1 11, count2 11, overflow 11 > failed: RF EFLAG recursion issue detected > failed: wrong overflow hit > failed: wrong count for bp2 > test child finished with -1 > end > Test breakpoint overflow signal handler: FAILED! ... and this sounds like the perf tool expecting to single-step over signal handlers, whereas (on arm64) we deliberately single-step into them, so you can run into a loop for this case. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] media: i2c: ov2659: speedup probe if no device connected
The ov2659 driver performs device detection and initialization in the
following way:
- send reset command REG_SOFTWARE_RESET
- load array of predefined register's setting (~150 values)
- read device version REG_SC_CHIP_ID_H/REG_SC_CHIP_ID_L
- check version and exit if invalid.
As result, for not connected device there will be >~150 i2c transactions
executed before device version checking and exit (there are no
failures detected because ov2659 declared as I2C_CLIENT_SCCB and NACKs
are ignored in this case).
Let's fix that by checking the chip version first and start
initialization only if it's supported.
Cc: Benoit Parrot
Signed-off-by: Grygorii Strashko
---
drivers/media/i2c/ov2659.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
index 49109f4..9b7b78c 100644
--- a/drivers/media/i2c/ov2659.c
+++ b/drivers/media/i2c/ov2659.c
@@ -1321,10 +1321,6 @@ static int ov2659_detect(struct v4l2_subdev *sd)
}
usleep_range(1000, 2000);
- ret = ov2659_init(sd, 0);
- if (ret < 0)
- return ret;
-
/* Check sensor revision */
ret = ov2659_read(client, REG_SC_CHIP_ID_H, );
if (!ret)
@@ -1338,8 +1334,10 @@ static int ov2659_detect(struct v4l2_subdev *sd)
dev_err(>dev,
"Sensor detection failed (%04X, %d)\n",
id, ret);
- else
+ else {
dev_info(>dev, "Found OV%04X sensor\n", id);
+ ret = ov2659_init(sd, 0);
+ }
}
return ret;
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] orangefs: fix typo in ornagefs_inode_lock
Orangefs fails to build on 32-bit SMP configurations due to a simple
misspelling, this does the obvious fix.
Signed-off-by: Arnd Bergmann
Fixes: 575e946125f7 ("Orangefs: change pvfs2 filenames to orangefs")
---
fs/orangefs/orangefs-kernel.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/orangefs/orangefs-kernel.h b/fs/orangefs/orangefs-kernel.h
index 0b7ba0496aa3..fe8284045a40 100644
--- a/fs/orangefs/orangefs-kernel.h
+++ b/fs/orangefs/orangefs-kernel.h
@@ -770,7 +770,7 @@ do {
\
static inline void orangefs_i_size_write(struct inode *inode, loff_t i_size)
{
#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
- ornagefs_inode_lock(inode);
+ orangefs_inode_lock(inode);
#endif
i_size_write(inode, i_size);
#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
--
2.1.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: vf-colibri: split PWM pinctrl
On Sun, Dec 13, 2015 at 06:53:35PM -0800, Stefan Agner wrote:
> On 2015-12-13 18:18, Shawn Guo wrote:
> > On Wed, Dec 02, 2015 at 02:11:46PM -0800, Stefan Agner wrote:
> >> Split PWM pins into separate pinctrl nodes to allow overrides which
> >> select pins individually. This is useful for carrier boards which use
> >> only one pin for PWM and would like to use the other pin for a
> >> different purpose.
> >>
> >> Signed-off-by: Stefan Agner
> >> ---
> >> arch/arm/boot/dts/vf-colibri.dtsi | 18 ++
> >> 1 file changed, 14 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
> >> b/arch/arm/boot/dts/vf-colibri.dtsi
> >> index e5949b9..924b660 100644
> >> --- a/arch/arm/boot/dts/vf-colibri.dtsi
> >> +++ b/arch/arm/boot/dts/vf-colibri.dtsi
> >> @@ -74,12 +74,12 @@
> >>
> >> {
> >>pinctrl-names = "default";
> >> - pinctrl-0 = <_pwm0>;
> >> + pinctrl-0 = <_pwm0_a _pwm0_c>;
> >> };
> >>
> >> {
> >>pinctrl-names = "default";
> >> - pinctrl-0 = <_pwm1>;
> >> + pinctrl-0 = <_pwm1_b _pwm1_d>;
> >> };
> >
> > It may make more sense to define these pwm nodes in the final board
> > level dts with only defining the pins that are actually used on the
> > board.
>
> Well, if we follow that policy, we would have to remove almost anything
> from the -colibri.dtsi device trees...
>
> The Colibri standard defines standard functionality, which is kept
> compatible across modules with different SoC's. However, on almost all
> pins different functionality is available, and we have some customer
> which make use that
>
> So far we followed the policy that we define the pin/device
> configuration of the standard functionality in the -colibri.dtsi files
> (since this is the most used functionality). This allows us to also
> "bug-fix" standard functionality without having to touch customers
> (often out-of-tree) device trees.
>
> This change is not different from that approach, it merely splits the
> pin configuration in two individual pinctrl nodes. This makes sense for
> PWM signals since they can be used individually (compared to, lets say,
> I2C, where it is more like "all or nothing")... It turned out that
> several customers used PWM for the display back light, while using
> PWM in a different function, therefor that change.
Okay, sounds reasonable. But please be consistent on the naming. I
would expect the pin groups named in scheme
pinctrl_<0,1,2...>_. That said, in this case of pwm,
they should be something like below.
- pinctrl_pwm0_a
- pinctrl_pwm0_b
- pinctrl_pwm1_a
- pinctrl_pwm1_b
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation
On Sat, 19 Dec 2015, Marcelo Tosatti wrote: > On Sat, Dec 19, 2015 at 11:42:57AM +0100, Thomas Gleixner wrote: > > This is still the original crap. No, we are not introducing this > > interface now just because we can. I explained in great length why > > this is completely useless and what we really need. > > > > Thanks, > > > > tglx > > Can you make a summary of the points, and enumerate them, please. > (what are the problems of the current interface, and why such problems > are fixed in the new interface?). > > Then someone can write it, integrate it, and everyone is happy. LMGTFY: http://bfy.tw/3NzC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM64: Improve copy_page for 128 cache line sizes.
On Monday 21 December 2015, Will Deacon wrote: > On Sat, Dec 19, 2015 at 04:11:18PM -0800, Andrew Pinski wrote: > > Adding a check for the cache line size is not much overhead. > > Special case 128 byte cache line size. > > This improves copy_page by 85% on ThunderX compared to the > > original implementation. > > So this patch seems to: > > - Align the loop > - Increase the prefetch size > - Unroll the loop once > > Do you know where your 85% boost comes from between these? I'd really > like to avoid having multiple versions of copy_page, if possible, but > maybe we could end up with something that works well enough regardless > of cacheline size. Understanding what your bottleneck is would help to > lead us in the right direction. > > Also, how are you measuring the improvement? If you can share your > test somewhere, I can see how it affects the other systems I have access > to. A related question would be how other CPU cores are affected by the change. The test for the cache line size is going to take a few cycles, possibly a lot on certain implementations, e.g. if we ever get one where 'mrs' is microcoded or trapped by a hypervisor. Are there any possible downsides to using the ThunderX version on other microarchitectures too and skip the check? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled
On Mon, Dec 21, 2015 at 01:58:30PM +0100, Ard Biesheuvel wrote: > On 21 December 2015 at 13:51, Will Deacon wrote: > > On Mon, Dec 21, 2015 at 01:46:22PM +0100, Ard Biesheuvel wrote: > >> On 21 December 2015 at 13:38, Will Deacon wrote: > >> > On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote: > >> >> The problem here is that GCC 6 and above emits .arch now > >> >> for each function so now the global .arch_extension has > >> >> no effect. This fixes the problem by putting > >> >> .arch_extension inside ARM64_LSE_ATOMIC_INSN so > >> >> it is enabled for each place where LSE is used. > >> > > >> > Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64. > >> > .arch_extension is used for virt, mp and sec over there, and it may be > >> > tricky to isolate the actual instruction usage (at least, virt looks > >> > lost in kvm/arm.c). > >> > > >> > Why can't gas have an option to accept all instruction encodings that it > >> > knows about, inspite of any .arch directives? > >> > > >> > >> Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it > >> probably makes sense to pass that on the command line when building > >> for v7 (or +sec only for v6) if the assembler is found to support it > >> at build time. > > > > Does that override a more restrictive .arch directive emitted by the > > compiler? > > > > It seems to be additive: -march=armv7-a+mp+sec allows a .S file > containing a virt arch_extension + both hvc and smc instructions to be > assembled. The problem I'm seeing is if I have something like: .arch_extension lse before something like: .cpu cortex-a57+fp+simd+crc -or- .arch armv8-a+fp+simd+crc then I can no longer assemble lse instructions. So the .cpu/.arch directive is undoing the .arch_extension. We can fix this by following Andrew's suggestion to have .arch_extension before every point of use, but the whole thing would be much simpler if we could just tell gas to assemble harder. Maybe we just need to construct the mother of all -march options based on build-time checks in the Makefile? Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [media] uvcvideo: Only register media dev if MEDIA_CONTROLLER is defined
Commit 1590ad7b5271 ("[media] media-device: split media initialization
and registration") split the media dev initialization and registration
but introduced a build error since media_device_register() was called
unconditionally even when the MEDIA_CONTROLLER config was not enabled:
from drivers/media/usb/uvc/uvc_driver.c:14:
drivers/media/usb/uvc/uvc_driver.c: In function 'uvc_probe':
drivers/media/usb/uvc/uvc_driver.c:1960:32: error: 'struct uvc_device' has
no member named 'mdev'
if (media_device_register(>mdev) < 0)
Fixes: 1590ad7b5271 ("[media] media-device: split media initialization and
registration")
Reported-by: Fengguang Wu
Signed-off-by: Javier Martinez Canillas
---
drivers/media/usb/uvc/uvc_driver.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index ddf035a23e3a..599390325c09 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1957,10 +1957,11 @@ static int uvc_probe(struct usb_interface *intf,
if (uvc_register_chains(dev) < 0)
goto error;
+#ifdef CONFIG_MEDIA_CONTROLLER
/* Register the media device node */
if (media_device_register(>mdev) < 0)
goto error;
-
+#endif
/* Save our data pointer in the interface data. */
usb_set_intfdata(intf, dev);
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: ts-4800: Add LCD support
On Fri, Dec 18, 2015 at 12:00:32PM -0500, Damien Riegel wrote:
> This commit adds LCD support for the TS-4800. The panel is an Okaya
> RS800480T-7X0WQ and the timings have been extracted from Technologic
> Systems' tree.
>
> Signed-off-by: Damien Riegel
> ---
> arch/arm/boot/dts/imx51-ts4800.dts | 109
> +
> 1 file changed, 109 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx51-ts4800.dts
> b/arch/arm/boot/dts/imx51-ts4800.dts
> index 83352cb..4951ebd 100644
> --- a/arch/arm/boot/dts/imx51-ts4800.dts
> +++ b/arch/arm/boot/dts/imx51-ts4800.dts
> @@ -30,6 +30,60 @@
> clock-frequency = <24576000>;
> };
> };
> +
> + regulators {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + backlight_reg: regulator@0 {
> + compatible = "regulator-fixed";
> + reg = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_enable_lcd>;
> + regulator-name = "enable_lcd_reg";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 9 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> + };
DT maintainers dislike this fake simple-bus container. Let's put the
regulator directly under root like below.
backlight_reg: regulator-backlight {
compatible = "regulator-fixed";
pinctrl-names = "default";
pinctrl-0 = <_enable_lcd>;
regulator-name = "enable_lcd_reg";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
gpio = < 9 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
I fixed it up and applied both patches.
Shawn
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = < 0 78770>;
> + brightness-levels = <0 150 200 255>;
> + default-brightness-level = <1>;
> + power-supply = <_reg>;
> + };
> +
> + display0: display@di0 {
> + compatible = "fsl,imx-parallel-display";
> + interface-pix-fmt = "rgb24";
> + pinctrl-names = "default";
> + pinctrl-0 = <_lcd>;
> +
> + display-timings {
> + 800x480p60 {
> + native-mode;
> + clock-frequency = <30066000>;
> + hactive = <800>;
> + vactive = <480>;
> + hfront-porch = <50>;
> + hback-porch = <70>;
> + hsync-len = <50>;
> + vback-porch = <0>;
> + vfront-porch = <0>;
> + vsync-len = <50>;
> + };
> + };
> +
> + port@0 {
> + display0_in: endpoint {
> + remote-endpoint = <_di0_disp0>;
> + };
> + };
> + };
> };
>
> {
> @@ -60,6 +114,16 @@
> };
> };
>
> +_di0_disp0 {
> + remote-endpoint = <_in>;
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pwm_backlight>;
> + status = "okay";
> +};
> +
> {
> pinctrl-names = "default";
> pinctrl-0 = <_uart1>;
> @@ -115,6 +179,12 @@
> >;
> };
>
> + pinctrl_enable_lcd: enablelcdgrp {
> + fsl,pins = <
> + MX51_PAD_CSI2_D12__GPIO4_9 0x1c5
> + >;
> + };
> +
> pinctrl_esdhc1: esdhc1grp {
> fsl,pins = <
> MX51_PAD_SD1_CMD__SD1_CMD 0x400020d5
> @@ -159,6 +229,45 @@
> >;
> };
>
> + pinctrl_lcd: lcdgrp {
> + fsl,pins = <
> + MX51_PAD_DISP1_DAT0__DISP1_DAT0 0x5
> + MX51_PAD_DISP1_DAT1__DISP1_DAT1 0x5
> + MX51_PAD_DISP1_DAT2__DISP1_DAT2 0x5
> + MX51_PAD_DISP1_DAT3__DISP1_DAT3 0x5
> + MX51_PAD_DISP1_DAT4__DISP1_DAT4 0x5
> + MX51_PAD_DISP1_DAT5__DISP1_DAT5 0x5
> + MX51_PAD_DISP1_DAT6__DISP1_DAT6 0x5
> + MX51_PAD_DISP1_DAT7__DISP1_DAT7 0x5
> + MX51_PAD_DISP1_DAT8__DISP1_DAT8 0x5
> + MX51_PAD_DISP1_DAT9__DISP1_DAT9 0x5
> + MX51_PAD_DISP1_DAT10__DISP1_DAT10 0x5
> + MX51_PAD_DISP1_DAT11__DISP1_DAT11 0x5
> + MX51_PAD_DISP1_DAT12__DISP1_DAT12 0x5
> +
[PATCH] HID: i2c-hid: Prevent sending reports from racing with device reset
When an i2c-hid device is resumed from system sleep the driver resets
the device to be sure it is in known state. The device is expected to
issue an interrupt when reset is complete.
This reset might take few milliseconds to complete so if the HID driver
on top (hid-rmi) starts to set up the device by sending feature reports
etc. the device might not issue the reset complete interrupt anymore.
Below is what happens to touchpad on Lenovo Yoga 900 during resume from
system sleep:
[ 24.790951] i2c_hid i2c-SYNA2B29:00: i2c_hid_hwreset
[ 24.790973] i2c_hid i2c-SYNA2B29:00: i2c_hid_set_power
[ 24.790982] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=22 00 00 08
[ 24.793011] i2c_hid i2c-SYNA2B29:00: resetting...
[ 24.793016] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=22 00 00 01
Here i2c-hid sends reset command to the touchpad.
[ 24.794012] i2c_hid i2c-SYNA2B29:00: input: 06 00 01 00 00 00
[ 24.794051] i2c_hid i2c-SYNA2B29:00: i2c_hid_set_or_send_report
[ 24.794059] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command:
cmd=22 00 3f 03 0f 23 00 04 00 0f 01
Now hid-rmi puts the touchpad to correct mode by sending it a feature
report. This makes the touchpad not to issue reset complete interrupt.
[ 24.796092] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: waiting...
i2c-hid starts to wait for the reset interrupt to trigger which never
happens.
[ 24.798304] i2c_hid i2c-SYNA2B29:00: i2c_hid_set_or_send_report
[ 24.798313] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command:
cmd=25 00 17 00 09 01 42 00 2e 00 19 19 00 10 cc 06 74 04 0f
19 00 00 00 00 00
Yet another output report from hid-rmi driver.
[ 29.795630] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: finished.
[ 29.795637] i2c_hid i2c-SYNA2B29:00: failed to reset device.
After 5 seconds i2c-hid driver times out.
[ 29.795642] i2c_hid i2c-SYNA2B29:00: i2c_hid_set_power
[ 29.795649] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=22 00 01 08
[ 29.797576] dpm_run_callback(): i2c_hid_resume+0x0/0xb0 returns -61
[ 29.797584] PM: Device i2c-SYNA2B29:00 failed to resume: error -61
After this the touchpad does not work anymore (and also resume itself
gets slowed down because of the timeout).
Prevent sending of feature/output reports while the device is being
reset by adding a mutex which is held during that time.
Reported-by: Nish Aravamudan
Reported-by: Linus Torvalds
Suggested-by: Benjamin Tissoires
Signed-off-by: Mika Westerberg
---
drivers/hid/i2c-hid/i2c-hid.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 10bd8e6e4c9c..fc5ef1c25ed4 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -151,6 +151,7 @@ struct i2c_hid {
struct i2c_hid_platform_data pdata;
boolirq_wake_enabled;
+ struct mutexreset_lock;
};
static int __i2c_hid_command(struct i2c_client *client,
@@ -356,9 +357,16 @@ static int i2c_hid_hwreset(struct i2c_client *client)
i2c_hid_dbg(ihid, "%s\n", __func__);
+ /*
+* This prevents sending feature reports while the device is
+* being reset. Otherwise we may lose the reset complete
+* interrupt.
+*/
+ mutex_lock(>reset_lock);
+
ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
if (ret)
- return ret;
+ goto out_unlock;
i2c_hid_dbg(ihid, "resetting...\n");
@@ -366,10 +374,11 @@ static int i2c_hid_hwreset(struct i2c_client *client)
if (ret) {
dev_err(>dev, "failed to reset device.\n");
i2c_hid_set_power(client, I2C_HID_PWR_SLEEP);
- return ret;
}
- return 0;
+out_unlock:
+ mutex_unlock(>reset_lock);
+ return ret;
}
static void i2c_hid_get_input(struct i2c_hid *ihid)
@@ -587,12 +596,15 @@ static int i2c_hid_output_raw_report(struct hid_device
*hid, __u8 *buf,
size_t count, unsigned char report_type, bool use_data)
{
struct i2c_client *client = hid->driver_data;
+ struct i2c_hid *ihid = i2c_get_clientdata(client);
int report_id = buf[0];
int ret;
if (report_type == HID_INPUT_REPORT)
return -EINVAL;
+ mutex_lock(>reset_lock);
+
if (report_id) {
buf++;
count--;
@@ -605,6 +617,8 @@ static int i2c_hid_output_raw_report(struct hid_device
*hid, __u8 *buf,
if (report_id && ret >= 0)
ret++; /* add report_id to the number of transfered bytes */
+ mutex_unlock(>reset_lock);
+
return ret;
}
@@ -990,6 +1004,7 @@ static int i2c_hid_probe(struct i2c_client *client,
ihid->wHIDDescRegister = cpu_to_le16(hidRegister);
init_waitqueue_head(>wait);
+ mutex_init(>reset_lock);
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes:
P.S. Anyway we have to ask Julian to try the kernel with
8b3444852a2b58129 reverted.
>>> git revert 8b3444852a2b58129
>>> error: could not revert 8b34448... sata_dwc_460ex: move to generic DMA
>>> driver
>>> hint: after resolving the conflicts, mark the corrected paths
>>> hint: with 'git add ' or 'git rm '
>>> hint: and commit the result with 'git commit'
>> Yeah, that won't work since there are numerous changes afterward. Just
>> revert the entire file back to 4.0 like this:
>>
>> $ git checkout v4.0 drivers/ata/sata_dwc_460ex.c
>>
> CC [M] drivers/ata/sata_dwc_460ex.o
> drivers/ata/sata_dwc_460ex.c:467:36: error: macro
> "dma_request_channel" requires 3 arguments, but only 1 given
> static int dma_request_channel(void)
> ^
> drivers/ata/sata_dwc_460ex.c:468:1: error: expected ‘=’, ‘,’,
> ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
> {
> ^
> drivers/ata/sata_dwc_460ex.c: In function ‘dma_dwc_xfer_setup’:
> drivers/ata/sata_dwc_460ex.c:758:31: error: macro
> "dma_request_channel" requires 3 arguments, but only 1 given
> dma_ch = dma_request_channel();
>^
> drivers/ata/sata_dwc_460ex.c:758:11: error: ‘dma_request_channel’
> undeclared (first use in this function)
> dma_ch = dma_request_channel();
>^
> drivers/ata/sata_dwc_460ex.c:758:11: note: each undeclared identifier
> is reported only once for each function it appears in
> drivers/ata/sata_dwc_460ex.c: In function ‘sata_dwc_dma_filter’:
> drivers/ata/sata_dwc_460ex.c:1282:35: error: ‘struct
> sata_dwc_device_port’ has no member named ‘dws’
> struct dw_dma_slave *dws = hsdevp->dws;
>^
> drivers/ata/sata_dwc_460ex.c: In function ‘sata_dwc_port_start’:
> drivers/ata/sata_dwc_460ex.c:1325:17: warning: unused variable
> ‘mask’ [-Wunused-variable]
> dma_cap_mask_t mask;
> ^
> drivers/ata/sata_dwc_460ex.c: At top level:
> drivers/ata/sata_dwc_460ex.c:345:28: warning: ‘sata_dwc_dma_dws’
> defined but not used [-Wunused-variable]
> static struct dw_dma_slave sata_dwc_dma_dws = {
> ^
> drivers/ata/sata_dwc_460ex.c:1279:13: warning:
> ‘sata_dwc_dma_filter’ defined but not used [-Wunused-function]
> static bool sata_dwc_dma_filter(struct dma_chan *chan, void *param)
> ^
Those messages do not match the contents of the file from v4.0.
For your convenience, here's the file as it should be.
$ sha1sum drivers/ata/sata_dwc_460ex.c
0f54dfa3a91591101f5de434c3a631a5cd20ff1a drivers/ata/sata_dwc_460ex.c
--
Måns Rullgård
/*
* drivers/ata/sata_dwc_460ex.c
*
* Synopsys DesignWare Cores (DWC) SATA host driver
*
* Author: Mark Miesfeld
*
* Ported from 2.6.19.2 to 2.6.25/26 by Stefan Roese
* Copyright 2008 DENX Software Engineering
*
* Based on versions provided by AMCC and Synopsys which are:
* Copyright 2006 Applied Micro Circuits Corporation
* COPYRIGHT (C) 2005 SYNOPSYS, 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 as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
#ifdef CONFIG_SATA_DWC_DEBUG
#define DEBUG
#endif
#ifdef CONFIG_SATA_DWC_VDEBUG
#define VERBOSE_DEBUG
#define DEBUG_NCQ
#endif
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "libata.h"
#include
#include
/* These two are defined in "libata.h" */
#undef DRV_NAME
#undef DRV_VERSION
#define DRV_NAME"sata-dwc"
#define DRV_VERSION "1.3"
#ifndef out_le32
#define out_le32(a, v) __raw_writel(__cpu_to_le32(v), (void __iomem *)(a))
#endif
#ifndef in_le32
#define in_le32(a) __le32_to_cpu(__raw_readl((void __iomem *)(a)))
#endif
#ifndef NO_IRQ
#define NO_IRQ 0
#endif
/* SATA DMA driver Globals */
#define DMA_NUM_CHANS 1
#define DMA_NUM_CHAN_REGS 8
/* SATA DMA Register definitions */
#define AHB_DMA_BRST_DFLT 64 /* 16 data items burst length*/
struct dmareg {
u32 low; /* Low bits 0-31 */
u32 high; /* High bits 32-63 */
};
/* DMA Per Channel registers */
struct dma_chan_regs {
struct dmareg sar; /* Source Address */
struct dmareg dar; /* Destination address */
struct dmareg llp; /* Linked List Pointer */
struct dmareg ctl; /* Control */
struct dmareg sstat; /* Source Status not implemented in core */
struct dmareg dstat; /* Destination Status not implemented in core*/
struct dmareg sstatar; /* Source Status Address not impl in core */
struct dmareg dstatar; /* Destination Status Address not implemente */
struct dmareg cfg; /* Config */
struct dmareg sgr; /* Source Gather */
struct dmareg dsr; /* Destination Scatter */
};
/* Generic Interrupt Registers */
struct dma_interrupt_regs {
struct dmareg tfr; /* Transfer
Re: [PATCH 5/5] hwmon: (sch56xx) Drop watchdog driver data reference count callbacks
Hi Hans,
On 12/21/2015 02:37 AM, Hans de Goede wrote:
Hi,
On 20-12-15 22:05, Guenter Roeck wrote:
Reference counting is now implemented in the watchdog core and no longer
required in watchdog drivers.
Signed-off-by: Guenter Roeck
---
drivers/hwmon/sch56xx-common.c | 30 --
1 file changed, 30 deletions(-)
diff --git a/drivers/hwmon/sch56xx-common.c b/drivers/hwmon/sch56xx-common.c
index 738681983284..88dba68a9abb 100644
--- a/drivers/hwmon/sch56xx-common.c
+++ b/drivers/hwmon/sch56xx-common.c
@@ -30,7 +30,6 @@
#include
#include
#include
-#include
#include
#include "sch56xx-common.h"
@@ -67,7 +66,6 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once
started (default="
struct sch56xx_watchdog_data {
u16 addr;
struct mutex *io_lock;
-struct kref kref;
struct watchdog_info wdinfo;
struct watchdog_device wddev;
u8 watchdog_preset;
@@ -258,15 +256,6 @@ EXPORT_SYMBOL(sch56xx_read_virtual_reg12);
* Watchdog routines
*/
-/* Release our data struct when we're unregistered *and*
- all references to our watchdog device are released */
-static void watchdog_release_resources(struct kref *r)
-{
-struct sch56xx_watchdog_data *data =
-container_of(r, struct sch56xx_watchdog_data, kref);
-kfree(data);
You're not replacing this kfree() anywhere, so now the data
allocated by sch56xx_watchdog_register() never gets free-ed
after a sch56xx_watchdog_unregister(). If I read this patch
set correctly then after this patch-set it is safe to
immediately free the memory containing the struct watchdog_device
(and also the struct wdinfo ?) after calling
watchdog_unregister_device(), even if userspace still has the
watchdog cdev open, correct ?
Yes, this is correct for both struct watchdog_device and struct wdinfo.
In that case (continue reading below) ...
-}
-
static int watchdog_set_timeout(struct watchdog_device *wddev,
unsigned int timeout)
{
@@ -395,28 +384,12 @@ static int watchdog_stop(struct watchdog_device *wddev)
return 0;
}
-static void watchdog_ref(struct watchdog_device *wddev)
-{
-struct sch56xx_watchdog_data *data = watchdog_get_drvdata(wddev);
-
-kref_get(>kref);
-}
-
-static void watchdog_unref(struct watchdog_device *wddev)
-{
-struct sch56xx_watchdog_data *data = watchdog_get_drvdata(wddev);
-
-kref_put(>kref, watchdog_release_resources);
-}
-
static const struct watchdog_ops watchdog_ops = {
.owner= THIS_MODULE,
.start= watchdog_start,
.stop= watchdog_stop,
.ping= watchdog_trigger,
.set_timeout= watchdog_set_timeout,
-.ref= watchdog_ref,
-.unref= watchdog_unref,
};
struct sch56xx_watchdog_data *sch56xx_watchdog_register(struct device *parent,
@@ -448,7 +421,6 @@ struct sch56xx_watchdog_data
*sch56xx_watchdog_register(struct device *parent,
data->addr = addr;
data->io_lock = io_lock;
-kref_init(>kref);
strlcpy(data->wdinfo.identity, "sch56xx watchdog",
sizeof(data->wdinfo.identity));
@@ -494,8 +466,6 @@ EXPORT_SYMBOL(sch56xx_watchdog_register);
void sch56xx_watchdog_unregister(struct sch56xx_watchdog_data *data)
{
watchdog_unregister_device(>wddev);
-kref_put(>kref, watchdog_release_resources);
-/* Don't touch data after this it may have been free-ed! */
These 2 lines need to be replaced by a "kfree(data);" rather then being
removed.
Good catch. Fixed.
}
EXPORT_SYMBOL(sch56xx_watchdog_unregister);
Regards,
Hans
p.s.
The patches for da9052_wdt and da9055_wdt are also interesting,
their da905#_wdt_release_resources() functions are nops,
making the entire refcounting exercise a nop.
For da9052_wdt is the case since this commit:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/watchdog/da9052_wdt.c?id=0360dffedd7bad92f174b2ce5e69e960451d2b59
And for da9055 with commit ee8c94adff9b ("watchdog: da9055: Fix invalid free
of devm_ allocated data").
Which fixes the bug it tries to fix in the wrong way, the right
way would have been to change the devm_kzalloc to a regular kzalloc,
since devm_*alloc cannot be used together with refcounting to keep
memory alive after device unregister time.
What this means is that these drivers actually have a bug wrt
freeing in use memory on driver unbind while userspace has
the watchdog cdev open, and this gets fixed by this patch-set,
it would be very good to mention this in the commit messages.
Good point. I updated the commit log.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/21/2015 8:16 AM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/21/2015 4:40 AM, Andy Shevchenko wrote:
+Viresh
On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård wrote:
Andy Shevchenko writes:
On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/20/2015 1:11 PM, Måns Rullgård wrote:
Julian Margetson writes:
[ 48.769671] ata3.00: failed command: READ FPDMA QUEUED
Well, that didn't help. I still think it's part of the problem, but
something else must be wrong as well. The various Master Select fields
look like a good place to start.
Master number (which is here would be either 1 or 0) should not affect
as long as they are connected to the same AHB bus (I would be
surprised if they are not).
I think they are not. The relevant part of the block diagram for the
460EX looks something like this:
+-+
| CPU |
+-+
|
+---+
| BUS |
+---+
| |
+-+ +-+
| DMA | | RAM |
+-+ +-+
|
+--+
| SATA |
+--+
The DMA-SATA link is private and ignores the address, which is the only
reason the driver can possibly work (it's programming a CPU virtual
address there).
If you look at the original code the SMS and DMS are programmed
statically independent on DMA direction, so LLP is programmed always
to master 1. I don't think your scheme is reflecting this right. I
could imagine two AHB buses, one of them connects CPU, SATA and RAM,
and the other CPU and DMA.
In any case on all Intel SoCs and AVR32, and as far as I can tell on
Spear13xx (Viresh?) there is not a case, that's why I hardly imagine
that the problem is in master numbers by themselves.
Also, the manual says the LLP_SRC_EN
and LLP_DST_EN flags should be cleared on the last in a chain of blocks.
The old sata_dwc driver does this whereas dw_dma does not.
Easy to fix, however I can't get how it might affect.
From the Atmel doc:
In Table 17-1 on page 185, all other combinations of LLPx.LOC = 0,
CTLx.LLP_S_EN, CFGx.RELOAD_SR, CTLx.LLP_D_EN, and CFGx.RELOAD_DS are
illegal, and causes indeterminate or erroneous behavior.
I will check Synospys documentation later on.
Most likely nothing happens, but I think it ought to be fixed. In fact,
I have a patch already.
Good. Send with Fixes tag if it's upstream ready.
Come to think of it, I have an AVR32 dev somewhere. Maybe I should dust
it off.
I have ATNGW100.
P.S. Anyway we have to ask Julian to try the kernel with
8b3444852a2b58129 reverted.
git revert 8b3444852a2b58129
error: could not revert 8b34448... sata_dwc_460ex: move to generic DMA driver
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git commit'
Yeah, that won't work since there are numerous changes afterward. Just
revert the entire file back to 4.0 like this:
$ git checkout v4.0 drivers/ata/sata_dwc_460ex.c
CC [M] drivers/ata/sata_dwc_460ex.o
drivers/ata/sata_dwc_460ex.c:467:36: error: macro "dma_request_channel"
requires 3 arguments, but only 1 given
static int dma_request_channel(void)
^
drivers/ata/sata_dwc_460ex.c:468:1: error: expected ‘=’, ‘,’,
‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
{
^
drivers/ata/sata_dwc_460ex.c: In function ‘dma_dwc_xfer_setup’:
drivers/ata/sata_dwc_460ex.c:758:31: error: macro "dma_request_channel"
requires 3 arguments, but only 1 given
dma_ch = dma_request_channel();
^
drivers/ata/sata_dwc_460ex.c:758:11: error: ‘dma_request_channel’
undeclared (first use in this function)
dma_ch = dma_request_channel();
^
drivers/ata/sata_dwc_460ex.c:758:11: note: each undeclared identifier is
reported only once for each function it appears in
drivers/ata/sata_dwc_460ex.c: In function ‘sata_dwc_dma_filter’:
drivers/ata/sata_dwc_460ex.c:1282:35: error: ‘struct
sata_dwc_device_port’ has no member named ‘dws’
struct dw_dma_slave *dws = hsdevp->dws;
^
drivers/ata/sata_dwc_460ex.c: In function ‘sata_dwc_port_start’:
drivers/ata/sata_dwc_460ex.c:1325:17: warning: unused variable
‘mask’ [-Wunused-variable]
dma_cap_mask_t mask;
^
drivers/ata/sata_dwc_460ex.c: At top level:
drivers/ata/sata_dwc_460ex.c:345:28: warning: ‘sata_dwc_dma_dws’
defined but not used [-Wunused-variable]
static struct dw_dma_slave sata_dwc_dma_dws = {
^
drivers/ata/sata_dwc_460ex.c:1279:13: warning: ‘sata_dwc_dma_filter’
defined but not used [-Wunused-function]
static bool sata_dwc_dma_filter(struct dma_chan *chan, void *param)
^
make[2]: *** [drivers/ata/sata_dwc_460ex.o] Error 1
make[1]: *** [drivers/ata] Error 2
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs
--
To
[PATCH 1/2] ASoC: rt5616: add an of_match table
Add a device tree match table. This serves to make the driver's support
of device tree more explicit.
Signed-off-by: Caesar Wang
---
sound/soc/codecs/rt5616.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sound/soc/codecs/rt5616.c b/sound/soc/codecs/rt5616.c
index f4005cb..e01a32d 100644
--- a/sound/soc/codecs/rt5616.c
+++ b/sound/soc/codecs/rt5616.c
@@ -1287,6 +1287,14 @@ static const struct i2c_device_id rt5616_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, rt5616_i2c_id);
+#if defined(CONFIG_OF)
+static const struct of_device_id rt5616_of_match[] = {
+ { .compatible = "realtek,rt5616", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, rt5616_of_match);
+#endif
+
static int rt5616_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -1359,6 +1367,7 @@ static void rt5616_i2c_shutdown(struct i2c_client *client)
static struct i2c_driver rt5616_i2c_driver = {
.driver = {
.name = "rt5616",
+ .of_match_table = of_match_ptr(rt5616_of_match),
},
.probe = rt5616_i2c_probe,
.remove = rt5616_i2c_remove,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] dt-bindings: sound: add devicetree document for rt5616
Add the description for rt5616 codec.
Signed-off-by: Caesar Wang
---
Documentation/devicetree/bindings/sound/rt5616.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/rt5616.txt
diff --git a/Documentation/devicetree/bindings/sound/rt5616.txt
b/Documentation/devicetree/bindings/sound/rt5616.txt
new file mode 100644
index 000..af96207
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rt5616.txt
@@ -0,0 +1,38 @@
+RT5616 audio CODEC
+
+This device supports I2C only.
+
+Required properties:
+
+- compatible : "realtek,rt5616".
+
+- reg : The I2C address of the device.
+
+Optional properties:
+
+Pins on the device (for linking into audio routes) for RT5616:
+
+ * IN1P
+ * IN2P
+ * IN2N
+ * LOUTL
+ * LOUTR
+ * CPN2
+ * CPP2
+ * CPN1
+ * CPP1
+ * HPO_R
+ * HPO_L
+ * ADCDAT1
+ * DACDAT1
+ * LRCK1
+ * BCLK1
+ * MCLK
+ * GPIO1
+
+Example:
+
+rt5616 {
+ compatible = "realtek,rt5616";
+ reg = <0x1b>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: net, ipv6: out of bounds access in secret_stable
On 12/21/2015 03:58 AM, Hannes Frederic Sowa wrote:
> On 19.12.2015 21:50, Cong Wang wrote:
>> On Fri, Dec 18, 2015 at 5:13 PM, Sasha Levin wrote:
>>> Hi Hannes,
>>>
>>> I've hit the following out of bounds access while fuzzing on the latest
>>> -next kernel.
>>>
>>> This code was added in 3d1bec9932 ("ipv6: introduce secret_stable to
>>> ipv6_devconf").
>>>
>>> [ 459.553655] BUG: KASAN: stack-out-of-bounds in strlen+0x58/0x90 at addr
>>> 8802ab0efb0e
>>> [ 459.554953] Read of size 1 by task trinity-c91/22576
>>> [ 459.555805] page:ea000aac3bc0 count:0 mapcount:0 mapping:
>>> (null) index:0x0
>>> [ 459.556899] flags: 0x26f8000()
>>> [ 459.557521] page dumped because: kasan: bad access detected
>>> [ 459.558320] CPU: 7 PID: 22576 Comm: trinity-c91 Not tainted
>>> 4.4.0-rc5-next-20151218-sasha-00021-gaba8d84-dirty #2750
>>> [ 459.559809] 549d0aa3 8802ab0ef860
>>> a1042384
>>> [ 459.561036] 41b58ab3 ac667cdb a10422d9
>>> 8802ab0ef848
>>> [ 459.562245] 9f6a417e 549d0aa3 8802ab0efb0e
>>> 8802ab0efb0e
>>> [ 459.563429] Call Trace:
>>> [ 459.563831] dump_stack (lib/dump_stack.c:52)
>>> [ 459.564623] ? _atomic_dec_and_lock (lib/dump_stack.c:27)
>>> [ 459.565628] ? __dump_page (mm/debug.c:126)
>>> [ 459.566538] kasan_report_error (include/linux/kasan.h:28
>>> mm/kasan/report.c:170 mm/kasan/report.c:237)
>>> [ 459.570997] __asan_report_load1_noabort (mm/kasan/report.c:277)
>>> [ 459.572119] ? check_preemption_disabled (lib/smp_processor_id.c:39)
>>> [ 459.573731] ? strlen (lib/string.c:481 (discriminator 1))
>>> [ 459.574646] strlen (lib/string.c:481 (discriminator 1))
>>> [ 459.575485] proc_dostring (kernel/sysctl.c:1825 kernel/sysctl.c:1906)
>>> [ 459.576445] ? alloc_debug_processing (mm/slub.c:1054)
>>> [ 459.577523] addrconf_sysctl_stable_secret (net/ipv6/addrconf.c:5395)
>>
>> Looks like we don't initialize the array on stack for write case.
>> At least other callers always initialize the data for both read
>> and write.
>>
>> Please try the attached patch.
>
> Your patch is right. I am surprised you need to initialize the buffer
> passed down to proc_dostring so that strlen can correctly operate on it,
> but f4aacea2f5d1a5 ("sysctl: allow for strict write position handling")
> explains why. Can you submit formally?
>
> Acked-by: Hannes Frederic Sowa
And that seems to fix the issue here as well.
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] PCI: rcar: Support runtime PM link state L1 handling in pcie-rcar
Hi Phil,
(this time with full CC list)
On Mon, Dec 21, 2015 at 11:52 AM, Phil Edworthy
wrote:
> On 18 December 2015 14:04, Wolfram Sang wrote:
>> > Since the hardware doesn't support hot plug, I believe this loop will
>> > always exit very quickly. Unless someone has taken a hammer to the HW
>> > of course.
>>
>> I know what you mean. But since readl_poll_timeout() makes it easy, we
>> should better be safe than sorry.
> Hmm, I changed the code, but now it doesn't come out of suspend unless
> sleep_us passed to readl_poll_timeout is 0. Any reason you can think of?
Timers or interrupts disabled?
Does the might_sleep_if() scream if CONFIG_DEBUG_ATOMIC_SLEEP=y?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mempolicy: convert the shared_policy lock to a rwlock
On 11/17/2015 05:17 PM, Nathan Zimmer wrote: When running the SPECint_rate gcc on some very large boxes it was noticed that the system was spending lots of time in mpol_shared_policy_lookup. The gamess benchmark can also show it and is what I mostly used to chase down the issue since the setup for that I found a easier. To be clear the binaries were on tmpfs because of disk I/O reqruirements. We then used text replication to avoid icache misses and having all the copies banging on the memory where the instruction code resides. This results in us hitting a bottle neck in mpol_shared_policy_lookup since lookup is serialised by the shared_policy lock. I have only reproduced this on very large (3k+ cores) boxes. The problem starts showing up at just a few hundred ranks getting worse until it threatens to livelock once it gets large enough. For example on the gamess benchmark at 128 ranks this area consumes only ~1% of time, at 512 ranks it consumes nearly 13%, and at 2k ranks it is over 90%. To alleviate the contention on this area I converted the spinslock to a rwlock. This allows the large number of lookups to happen simultaneously. The results were quite good reducing this to consumtion at max ranks to around 2%. Acked-by: David Rientjes Acked-by: Vlastimil Babka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm, vmstat: kernel BUG at mm/vmstat.c:1408!
On Fri, 18 Dec 2015, Sasha Levin wrote:
> [ 531.164630] RIP vmstat_update (mm/vmstat.c:1408)
Hmmm.. Yes we need to fold the diffs first before disabling the timer
otherwise the shepherd task may intervene.
Does this patch fix it?
Subject: quiet_vmstat: Avoid race with shepherd by folding counters first
We need to fold the counters first otherwise the shepherd task may
remotely reactivate the vmstat worker.
This also avoids the strange loop. Nothing can really increase the
counters at that point since we are in the cpu idle loop. So
folding the counters once is enough. Cancelling work that does
not exist is fine too so just avoid the branches completely.
Signed-off-by: Christoph Lameter
Index: linux/mm/vmstat.c
===
--- linux.orig/mm/vmstat.c
+++ linux/mm/vmstat.c
@@ -1419,11 +1419,9 @@ void quiet_vmstat(void)
if (system_state != SYSTEM_RUNNING)
return;
- do {
- if (!cpumask_test_and_set_cpu(smp_processor_id(), cpu_stat_off))
- cancel_delayed_work(this_cpu_ptr(_work));
-
- } while (refresh_cpu_vm_stats(false));
+ refresh_cpu_vm_stats(false);
+ cancel_delayed_work(this_cpu_ptr(_work));
+ cpumask_set_cpu(smp_processor_id(), cpu_stat_off);
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[BUG REPORT]: ARM64: perf: System hung in perf test
System hung can be reproduced on qemu and real hardware using:
# perf test -v signal
If qemu is started with '-smp 1', system hung. In real hardware and in
qemu with smp > 1, the result is:
# /perf test -v signal
17: Test breakpoint overflow signal handler :
--- start ---
test child forked, pid 792
count1 11, count2 11, overflow 11
failed: RF EFLAG recursion issue detected
failed: wrong overflow hit
failed: wrong count for bp2
test child finished with -1
end
Test breakpoint overflow signal handler: FAILED!
Looks like something like [1] is required for ARM64.
Some analysis is done with qemu:
This testcase tests the intertaction between breakpoint, perf_event
and signal handling. It installs a breakpoint at the enter of a
function and makes the corresponding perf_event generate SIGIO when
the event raise.
When perf_event on a async perf_event is triggered:
if (*perf_event_fasync(event) && event->pending_kill) {
event->pending_wakeup = 1;
irq_work_queue(>pending);
}
it calls irq_work_queue(>pending), which is used to fire a
poll event and SIGIO. Later when perf_event is closed, in _free_event
irq_work_sync(>pending) is called to ensure all irq_work is done.
On ARM64, if we have only 1 cpu, the system hung at irq_work_sync().
Using gdb attached, I see:
1. IRQ is not disabled. Inside irq_work_sync, result of
arch_local_save_flags()
is 0x140.
2. hrtimer_interrupt() is still generated. The system is not dead.
3. In irq_work_tick, we have a chance to process irq_work. However,
llist_empty(raised) is false but arch_irq_work_has_interrupt()
is true, so kernel only process lazy_list.
4. handle_IPI() is never called, so I guess the IPI is disabled by
breakpoint
and not restored in this case.
[1]
http://lkml.kernel.org/r/1362940871-24486-1-git-send-email-jo...@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Adding Reset resume support for CDC-EEM driver.
Pre-Condition
At the time of reset resume of a USB device, both self and bus powered
devices might go to a low power state or power off state depending on
the acceptable suspend time power of the system.
In case the device experiences a power glitch or completely powers off
during suspend-resume, the device will lose its internal state and
hence it'll again need a set interface from class driver on reset resume
operation.
Issue
So far our experiments were based on a USB gadget working on cdc_eem
protocol.
We have seen that device is unable to continue the packet transfer on
bulk endpoints after the reset resume operation.
Solution
We have added a .reset_resume function for cdc_eem protocol which sends a
set interface command on the Control endpoint. And calls the existing
usbnet_resume thereafter
Signed-off-by: Vikas Bansal
Signed-off-by: Sumit Batra
diff --git a/drivers/net/usb/cdc_eem.c b/drivers/net/usb/cdc_eem.c
index f7180f8..1f6f7ea 100644
--- a/drivers/net/usb/cdc_eem.c
+++ b/drivers/net/usb/cdc_eem.c
@@ -342,6 +342,19 @@ next:
return 1;
}
+static int cdc_eem_resume(struct usb_interface *intf)
+{
+ int ret = 0;
+ struct usbnet *dev = usb_get_intfdata(intf);
+
+ ret = usbnet_get_endpoints(dev, intf);
+ if (ret < 0)
+ goto err;
+ ret = usbnet_resume(intf);
+err:
+ return ret;
+}
+
static const struct driver_info eem_info = {
.description = "CDC EEM Device",
.flags =FLAG_ETHER | FLAG_POINTTOPOINT,
@@ -371,6 +384,7 @@ static struct usb_driver eem_driver = {
.disconnect = usbnet_disconnect,
.suspend = usbnet_suspend,
.resume = usbnet_resume,
+ .reset_resume = cdc_eem_resume,
.disable_hub_initiated_lpm = 1,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] usb: xhci: use list_for_each_entry
On 18.12.2015 20:30, Julia Lawall wrote:
Geliang,
Please check whether it is acceptable that last_unlinked_td point to the
dummy entry at th beginning of the list, in the case where the
list_for_each_entry loop runs out normally.
It seems that you have sent a bunch of these patches. Please recheck them
all to see if they really follow the semantics of list_for_each_entry
properly. If particular, you should not normally use the index variable
after leaving the loop, unless it is guaranteed that the exit from the
loop was via a break.
Julia is correct, we can't use list_for_each_entry() here as cur_td would end up
pointing to list head, and we really need it to point to the last entry in the
list at that point.
old:
- list_for_each(entry, >cancelled_td_list) {
- cur_td = list_entry(entry, struct xhci_td, cancelled_td_list);
cur_td_will point to last element in list. "entry" will point to head, but is
on longer used.
new:
+ list_for_each_entry(cur_td, >cancelled_td_list, cancelled_td_list) {
cur_td will point to head of list.
This is important as newly canceled TDs can be added to the tail of the list
while
looping through and returning the canceled TDs. We want to make sure we
only return and delete the TDs up to the point we have handled them on the ring.
(code continues with: last_unlinked_td = cur_td;)
Thanks Julia for spotting this
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled
On Mon, Dec 21, 2015 at 01:46:22PM +0100, Ard Biesheuvel wrote: > On 21 December 2015 at 13:38, Will Deacon wrote: > > On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote: > >> The problem here is that GCC 6 and above emits .arch now > >> for each function so now the global .arch_extension has > >> no effect. This fixes the problem by putting > >> .arch_extension inside ARM64_LSE_ATOMIC_INSN so > >> it is enabled for each place where LSE is used. > > > > Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64. > > .arch_extension is used for virt, mp and sec over there, and it may be > > tricky to isolate the actual instruction usage (at least, virt looks > > lost in kvm/arm.c). > > > > Why can't gas have an option to accept all instruction encodings that it > > knows about, inspite of any .arch directives? > > > > Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it > probably makes sense to pass that on the command line when building > for v7 (or +sec only for v6) if the assembler is found to support it > at build time. Modern GCCs (GCC 4 at least) add .arch / .cpu pseudo-instructions in the assembly output which means using -Wa,-march= and -Wa,-mcpu= to GCC are now totally useless. (From the bug reports I've seen, I don't deem GCC 5 to be anything but a total failure, and so as far as I'm concerned, GCC 5 is not to be used for ARM, and effectively doesn't exist. I have no experience or opinions on GCC 6. Hence, "GCC 4" still counts as "modern" being the only recent compilers that produce sane results.) -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: TS-4800: drop uart rts/cts pin reservations
On Thu, Dec 17, 2015 at 04:16:52PM -0500, Damien Riegel wrote: > These pins are actually not routed for UARTs, they should not be > reserved. > > Signed-off-by: Damien Riegel Applied both, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled
On 21 December 2015 at 13:51, Will Deacon wrote: > On Mon, Dec 21, 2015 at 01:46:22PM +0100, Ard Biesheuvel wrote: >> On 21 December 2015 at 13:38, Will Deacon wrote: >> > On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote: >> >> The problem here is that GCC 6 and above emits .arch now >> >> for each function so now the global .arch_extension has >> >> no effect. This fixes the problem by putting >> >> .arch_extension inside ARM64_LSE_ATOMIC_INSN so >> >> it is enabled for each place where LSE is used. >> > >> > Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64. >> > .arch_extension is used for virt, mp and sec over there, and it may be >> > tricky to isolate the actual instruction usage (at least, virt looks >> > lost in kvm/arm.c). >> > >> > Why can't gas have an option to accept all instruction encodings that it >> > knows about, inspite of any .arch directives? >> > >> >> Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it >> probably makes sense to pass that on the command line when building >> for v7 (or +sec only for v6) if the assembler is found to support it >> at build time. > > Does that override a more restrictive .arch directive emitted by the > compiler? > It seems to be additive: -march=armv7-a+mp+sec allows a .S file containing a virt arch_extension + both hvc and smc instructions to be assembled. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] clk: tegra: Use definition for pll_u override bit
The definition, PLLU_BASE_OVERRIDE, for the pll_u OVERRIDE bit is defined
but not used and when the OVERRIDE bit is cleared in tegra210_pll_init()
the code directly uses the bit number. Therefore, use the definition,
PLLU_BASE_OVERRIDE when clearing the OVERRIDE bit.
Signed-off-by: Jon Hunter
---
drivers/clk/tegra/clk-tegra210.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
index 791215747863..6f043c5e2394 100644
--- a/drivers/clk/tegra/clk-tegra210.c
+++ b/drivers/clk/tegra/clk-tegra210.c
@@ -2520,7 +2520,7 @@ static void __init tegra210_pll_init(void __iomem
*clk_base,
/* PLLU_VCO */
val = readl(clk_base + pll_u_vco_params.base_reg);
- val &= ~BIT(24); /* disable PLLU_OVERRIDE */
+ val &= ~PLLU_BASE_OVERRIDE; /* disable PLLU_OVERRIDE */
writel(val, clk_base + pll_u_vco_params.base_reg);
clk = tegra_clk_register_pllre("pll_u_vco", "pll_ref", clk_base, pmc,
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] clk: tegra: Fix warning caused by pll_u failing to lock
If the pll_u is not configured by the bootloader, then on kernel boot the
following warning is seen:
clk_pll_wait_for_lock: Timed out waiting for pll pll_u_vco lock
tegra_init_from_table: Failed to enable pll_u_out1
[ cut here ]
WARNING: at drivers/clk/tegra/clk.c:269
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-next-20151214+ #1
Hardware name: NVIDIA Tegra210 P2371 reference board (E.1) (DT)
task: ffc0bc0a ti: ffc0bc0a8000 task.ti: ffc0bc0a8000
PC is at tegra_init_from_table+0x140/0x164
LR is at tegra_init_from_table+0x140/0x164
pc : [] lr : [] pstate: 8045
sp : ffc0bc0abd50
x29: ffc0bc0abd50 x28: ffc00090b8a8
x27: ffc000a06000 x26: ffc0bc019780
x25: ffc00086a708 x24: ffc00086a790
x23: ffc0006d7188 x22: ffc0bc01
x21: 016e x20: ffc0bc00d100
x19: ffc000944178 x18: 0007
x17: 000e x16: 0001
x15: 0007 x14: 000e
x13: 0013 x12: 001a
x11: 004d x10: 0750
x9 : ffc0bc0a8000 x8 : ffc0bc0a07b0
x7 : 0001 x6 : 02d5f0f8
x5 : x4 :
x3 : 0002 x2 : ffc000996724
x1 : x0 : 0032
---[ end trace cbd20ae519e92ced ]---
Call trace:
[] tegra_init_from_table+0x140/0x164
[] tegra210_clock_apply_init_table+0x20/0x28
[] tegra_clocks_apply_init_table+0x18/0x24
[] do_one_initcall+0x90/0x194
[] kernel_init_freeable+0x148/0x1e8
[] kernel_init+0x10/0xdc
[] ret_from_fork+0x10/0x40
clk_pll_wait_for_lock: Timed out waiting for pll pll_u_vco lock
tegra_init_from_table: Failed to enable pll_u_out2
[ cut here ]
pll_u can be either controlled by software or hardware and this is
selected via the OVERRIDE bit in the pll_u base register. In the function
tegra210_pll_init(), the OVERRIDE bit for pll_u is cleared, which selects
hardware control of the pll. However, at the same time the pll_u clocks
are populated in the init_table for tegra210 and so software will try to
configure the pll_u if it is not already configured and hence, the above
warning is seen when the pll fails to lock. Remove the pll_u clocks from
the init_table so that software does not try to configure this pll on
boot.
Signed-off-by: Jon Hunter
---
drivers/clk/tegra/clk-tegra210.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
index 849be30b52bf..791215747863 100644
--- a/drivers/clk/tegra/clk-tegra210.c
+++ b/drivers/clk/tegra/clk-tegra210.c
@@ -2739,8 +2739,6 @@ static struct tegra_clk_init_table init_table[]
__initdata = {
{ TEGRA210_CLK_DFLL_REF, TEGRA210_CLK_PLL_P, 5100, 1 },
{ TEGRA210_CLK_SBC4, TEGRA210_CLK_PLL_P, 1200, 1 },
{ TEGRA210_CLK_PLL_RE_VCO, TEGRA210_CLK_CLK_MAX, 67200, 1 },
- { TEGRA210_CLK_PLL_U_OUT1, TEGRA210_CLK_CLK_MAX, 4800, 1 },
- { TEGRA210_CLK_PLL_U_OUT2, TEGRA210_CLK_CLK_MAX, 6000, 1 },
{ TEGRA210_CLK_XUSB_GATE, TEGRA210_CLK_CLK_MAX, 0, 1 },
{ TEGRA210_CLK_XUSB_SS_SRC, TEGRA210_CLK_PLL_U_480M, 12000, 0 },
{ TEGRA210_CLK_XUSB_FS_SRC, TEGRA210_CLK_PLL_U_48M, 4800, 0 },
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V16 00/11] x86: Intel Cache Allocation Technology Support
On Fri, 18 Dec 2015, Marcelo Tosatti wrote: > > Could you also support another low level interface where a task (or > > process) can set the CLOS id itself if it has CAP_SYS_NICE. > > Hi Christoph, > > Do you have a proposal for an interface? Syscall set_closid(int closid) for an app. The CLOS id should be listed in /proc//status And then /proc/clos listing the possible configs with their current setups. Or /proc/clos//. Then have the ability to modify those for the root user. > > Plus some way > > for the supervisor to directly control the IA32_L3_MASK_n MSR? > > What you mean supervisor? Hypervisor or root user? Root user. > > > Is there a way to see these values for debugging purposes? > > Yes, from userspace, wrmsr and rdmsr. Maybe have a nicer way to interact with these configurations via /proc? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled
On Mon, Dec 21, 2015 at 01:46:22PM +0100, Ard Biesheuvel wrote: > On 21 December 2015 at 13:38, Will Deacon wrote: > > On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote: > >> The problem here is that GCC 6 and above emits .arch now > >> for each function so now the global .arch_extension has > >> no effect. This fixes the problem by putting > >> .arch_extension inside ARM64_LSE_ATOMIC_INSN so > >> it is enabled for each place where LSE is used. > > > > Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64. > > .arch_extension is used for virt, mp and sec over there, and it may be > > tricky to isolate the actual instruction usage (at least, virt looks > > lost in kvm/arm.c). > > > > Why can't gas have an option to accept all instruction encodings that it > > knows about, inspite of any .arch directives? > > > > Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it > probably makes sense to pass that on the command line when building > for v7 (or +sec only for v6) if the assembler is found to support it > at build time. Does that override a more restrictive .arch directive emitted by the compiler? Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] BugFix in XHCI controller driver for scatter gather DMA
On Mon, 2015-12-21 at 17:34 +0530, Vikas Bansal wrote: > Pre-Condition > At the time of reset resume of a USB device, both self and bus powered > devices might go to a low power state or power off state depending on the > acceptable suspend time power of the system. > In case the device experiences a power glitch or completely powers off during > suspend-resume, the device will lose its internal state and hence it'll again > need a set interface from class driver on reset resume operation. > > Issue > So far our experiments were based on a USB gadget working on cdc_eem > protocol. > We have seen that device is unable to continue the packet transfer on bulk > endpoints after the reset resume operation. > > Solution > We have added a .reset_resume function for cdc_eem protocol which sends a set > interface command on the Control endpoint. And calls the existing > usbnet_resume thereafte Hi, something is wrong with your subject line. Could you fix that and resend? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: page_alloc: Remove unnecessary parameter from __rmqueue
On 12/02/2015 04:08 PM, Mel Gorman wrote:
Commit 0aaa29a56e4f ("mm, page_alloc: reserve pageblocks for high-order
atomic allocations on demand") added an unnecessary and unused parameter
to __rmqueue. It was a parameter that was used in an earlier version of
the patch and then left behind. This patch cleans it up.
Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] BugFix in XHCI controller driver for scatter gather DMA
From: Sumit Batra
Pre-Condition
URB with Scatter Gather list is queued to bulk OUT endpoint.
Every buffer in scatter gather list is not a multiple of maximum packet
size for that endpoint(short packet).
CHAIN bit is set for all TRBs in a TD so that the DMA happens to all of
them at once.
Issue
DMA operation copies all the CHAINED TRBs at contiguous device memory.
But since the original packet was a short packet, so the actual data is
re-aligned after this DMA operation.
At device end this re-aligned data causes data integrity issue with
applications like ICMP ping.
Solution
Don't set the CHAINED bit for these TRBs, if their buffers are not a
multiple of maximum packet size.
This will reduce the benefit in throughput as required from a scatter
gather implementation, but this reduces the CPU utilization.
And solves the data integrity issue on Device End
Signed-off-by: Sumit Batra
Signed-off-by: Vikas Bansal
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 7d34cbf..7363dee 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3110,7 +3110,9 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
* TRB to indicate it's the last TRB in the chain.
*/
if (num_trbs > 1) {
- field |= TRB_CHAIN;
+ if (this_sg_len %
+ usb_endpoint_maxp(>ep->desc) == 0)
+ field |= TRB_CHAIN;
} else {
/* FIXME - add check for ZERO_PACKET flag before this */
td->last_trb = ep_ring->enqueue;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled
On 21 December 2015 at 13:38, Will Deacon wrote:
> On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote:
>> The problem here is that GCC 6 and above emits .arch now
>> for each function so now the global .arch_extension has
>> no effect. This fixes the problem by putting
>> .arch_extension inside ARM64_LSE_ATOMIC_INSN so
>> it is enabled for each place where LSE is used.
>
> Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64.
> .arch_extension is used for virt, mp and sec over there, and it may be
> tricky to isolate the actual instruction usage (at least, virt looks
> lost in kvm/arm.c).
>
> Why can't gas have an option to accept all instruction encodings that it
> knows about, inspite of any .arch directives?
>
Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it
probably makes sense to pass that on the command line when building
for v7 (or +sec only for v6) if the assembler is found to support it
at build time.
>> Signed-off-by: Andrew Pinski
>> ---
>> arch/arm64/include/asm/lse.h |4 +---
>> 1 files changed, 1 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/lse.h b/arch/arm64/include/asm/lse.h
>> index 3de42d6..625601f 100644
>> --- a/arch/arm64/include/asm/lse.h
>> +++ b/arch/arm64/include/asm/lse.h
>> @@ -17,8 +17,6 @@
>>
>> #else/* __ASSEMBLER__ */
>>
>> -__asm__(".arch_extension lse");
>> -
>> /* Move the ll/sc atomics out-of-line */
>> #define __LL_SC_INLINE
>> #define __LL_SC_PREFIX(x)__ll_sc_##x
>> @@ -29,7 +27,7 @@ __asm__(".arch_extensionlse");
>>
>> /* In-line patching at runtime */
>> #define ARM64_LSE_ATOMIC_INSN(llsc, lse) \
>> - ALTERNATIVE(llsc, lse, ARM64_HAS_LSE_ATOMICS)
>> + ALTERNATIVE(".arch_extensionlse\n" llsc, lse,
>> ARM64_HAS_LSE_ATOMICS)
>>
>> #endif /* __ASSEMBLER__ */
>> #else/* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
>> --
>> 1.7.2.5
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM64: Improve copy_page for 128 cache line sizes.
On Sat, Dec 19, 2015 at 04:11:18PM -0800, Andrew Pinski wrote: > Adding a check for the cache line size is not much overhead. > Special case 128 byte cache line size. > This improves copy_page by 85% on ThunderX compared to the > original implementation. So this patch seems to: - Align the loop - Increase the prefetch size - Unroll the loop once Do you know where your 85% boost comes from between these? I'd really like to avoid having multiple versions of copy_page, if possible, but maybe we could end up with something that works well enough regardless of cacheline size. Understanding what your bottleneck is would help to lead us in the right direction. Also, how are you measuring the improvement? If you can share your test somewhere, I can see how it affects the other systems I have access to. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WANTED new maintainer for Linux/md (and mdadm)
On 12/21/2015 01:10 AM, NeilBrown wrote: > In recent times I've been doing less of this and have been absolutely > thrilled that the gap has been more than filled by other very competent > community members. Not developers particular but a number of md users > have been providing excellent support. I'd particularly like to > high-light Phil Turmel who is very forthcoming with excellent advice, > but he is certainly not the only one who deserves a lot of thanks. > So "Thank you" to everyone who answers questions on linux-raid. You are very welcome. I may just have to polish my kernel coding skills to earn a place in a maintainership team. Phil Turmel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: mediatek: convert to arch_initcall
On Mon, Dec 21, 2015 at 8:39 PM, Yingjoe Chen wrote: > > On Mon, 2015-12-21 at 14:51 +0800, Daniel Kurtz wrote: > > On Fri, Dec 18, 2015 at 11:06 PM, Yingjoe Chen > > wrote: > > > On Fri, 2015-12-18 at 12:21 +0800, Daniel Kurtz wrote: > > >> Move pinctrl initialization earlier in boot so that real devices can find > > >> their pctldev without probe deferring. > > >> > > >> Signed-off-by: Daniel Kurtz > > >> --- > > >> drivers/pinctrl/mediatek/pinctrl-mt6397.c | 2 +- > > >> drivers/pinctrl/mediatek/pinctrl-mt8127.c | 2 +- > > >> drivers/pinctrl/mediatek/pinctrl-mt8135.c | 2 +- > > >> drivers/pinctrl/mediatek/pinctrl-mt8173.c | 2 +- > > >> 4 files changed, 4 insertions(+), 4 deletions(-) > > >> > > >> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6397.c > > >> b/drivers/pinctrl/mediatek/pinctrl-mt6397.c > > >> index f9751ae..a3780d4 100644 > > >> --- a/drivers/pinctrl/mediatek/pinctrl-mt6397.c > > >> +++ b/drivers/pinctrl/mediatek/pinctrl-mt6397.c > > >> @@ -70,7 +70,7 @@ static int __init mtk_pinctrl_init(void) > > >> return platform_driver_register(_pinctrl_driver); > > >> } > > >> > > >> -module_init(mtk_pinctrl_init); > > >> +arch_initcall(mtk_pinctrl_init); > > > > > > > > > MT6397 is PMIC, which depends on pwrap on main AP to work. Since > > > pmic-wrap itself is module_platform_driver, I think it make sense to > > > keep this one as module_init. Maybe adding a comment to explain why it > > > is different from others will help. > > > > I interpret this the other way - I think that since the PMIC wrapper > > provides a bus required for the system PMIC it should also be a > > builtin and use arch_initcall. > > We'll have to change mt8173 PMIC wrapper and mt6397 MFD core to > arch_initcall if we want to do it. > > I think regulators on PMIC is more important than pinctrl. For all > mt8173 systems, few drivers depends on PMIC pinctrl to work but many > depends on the regulators. So if we adjust pinctrl to arch_initcall, we > should change mt6397 regulator as well. ACK to changing all of mt6397 to arch_initcall, especially the regulators. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
On 21.12.2015 13:10, Lorenzo Pieralisi wrote: On Fri, Dec 18, 2015 at 06:56:39PM +, ok...@codeaurora.org wrote: [...] Here is what I have as an IO resource. QWORDIO(//Consumed-And-produced resource ResourceProducer, // bit 0 of general flags is 0 MinFixed, // Range is fixed MaxFixed, // Range is fixed PosDecode, EntireRange, 0x, // Granularity 0x1000, // Min, 0 is not accepted 0x10FFF,// Max 0x8FEF000, // Translation 0x1,// Range Length ,, PI00 ) I don't have any type specified. I agree with Lorenzo's assessment. The min and max values represent the PCI IO bus addresses. The translation offset is added to these values to figure out the CPU view of the PCI IO range. The endpoints BAR addresses are programmed with IO addresses ranging between 0x1000 and 0x10FFF for this example above. Here is another question. Chris Covington and I asked this question on a private email to you but we didn't hear back. We were referring to a Linaro IO hack patch as we were not sure whether this was a limitation of the hack or a general expectation for ARM64 PCI in general. I'll repeat it here. I have multiple root ports with the same IO port configuration in the current ACPI table. Root port 0 = IO range 0x1000-0x10FFF Root port 1 = IO range 0x1000-0x10FFF Root port 2 = IO range 0x1000-0x10FFF It is fine. You end up mapping for each of those a 4k window of the virtual address space allocated to IO and that's what you will have in the kernel PCI resources (not in the HW BARs though). If that was a problem it would be even for the current DT host controllers eg: arch/arm64/boot/dts/apm/apm-storm.dtsi it should not be (again I will let Arnd comment on this since he may be aware of issues encountered on other arches/platforms). Root port 0 = IO range 0x1000-0x10FFF Root port 1 = IO range 0x1000-0x10FFF Root port 2 = IO range 0x1000-0x10FFF If above ranges are mapped into different CPU windows, then yes, it is fine. Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trace-cmd: Print relate stacktrace at once
2015-12-21 16:54 GMT+09:00 Namhyung Kim : > From: Namhyung Kim > > Currently trace-cmd prints ring buffer events in a strict time order. > But it sometimes annoying that stacktrace from the same cpu can be > intermixed with events from other cpu. This patch looks next event when > print last record and prints it also if it's a stacktrace (from the same > cpu). > > Requested-by: Joonsoo Kim > Signed-off-by: Namhyung Kim Good Job! I tested it and it seems that it works well for me. Thanks!!! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: mediatek: convert to arch_initcall
On Mon, 2015-12-21 at 14:51 +0800, Daniel Kurtz wrote: > On Fri, Dec 18, 2015 at 11:06 PM, Yingjoe Chen > wrote: > > On Fri, 2015-12-18 at 12:21 +0800, Daniel Kurtz wrote: > >> Move pinctrl initialization earlier in boot so that real devices can find > >> their pctldev without probe deferring. > >> > >> Signed-off-by: Daniel Kurtz > >> --- > >> drivers/pinctrl/mediatek/pinctrl-mt6397.c | 2 +- > >> drivers/pinctrl/mediatek/pinctrl-mt8127.c | 2 +- > >> drivers/pinctrl/mediatek/pinctrl-mt8135.c | 2 +- > >> drivers/pinctrl/mediatek/pinctrl-mt8173.c | 2 +- > >> 4 files changed, 4 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6397.c > >> b/drivers/pinctrl/mediatek/pinctrl-mt6397.c > >> index f9751ae..a3780d4 100644 > >> --- a/drivers/pinctrl/mediatek/pinctrl-mt6397.c > >> +++ b/drivers/pinctrl/mediatek/pinctrl-mt6397.c > >> @@ -70,7 +70,7 @@ static int __init mtk_pinctrl_init(void) > >> return platform_driver_register(_pinctrl_driver); > >> } > >> > >> -module_init(mtk_pinctrl_init); > >> +arch_initcall(mtk_pinctrl_init); > > > > > > MT6397 is PMIC, which depends on pwrap on main AP to work. Since > > pmic-wrap itself is module_platform_driver, I think it make sense to > > keep this one as module_init. Maybe adding a comment to explain why it > > is different from others will help. > > I interpret this the other way - I think that since the PMIC wrapper > provides a bus required for the system PMIC it should also be a > builtin and use arch_initcall. We'll have to change mt8173 PMIC wrapper and mt6397 MFD core to arch_initcall if we want to do it. I think regulators on PMIC is more important than pinctrl. For all mt8173 systems, few drivers depends on PMIC pinctrl to work but many depends on the regulators. So if we adjust pinctrl to arch_initcall, we should change mt6397 regulator as well. Joe.C -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm: vblank: Use POSIX date for DRM_INFO output
Signed-off-by: Sedat Dilek
---
drivers/gpu/drm/drm_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 607f493ae801..682cd4b3ba10 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -361,7 +361,7 @@ int drm_vblank_init(struct drm_device *dev, unsigned int
num_crtcs)
(unsigned long)vblank);
}
- DRM_INFO("Supports vblank timestamp caching Rev 2 (21.10.2013).\n");
+ DRM_INFO("Supports vblank timestamp caching Rev 2 (20131021).\n");
/* Driver specific high-precision vblank timestamping supported? */
if (dev->driver->get_vblank_timestamp)
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
