[PATCH 13/17] Documentation/serial-console.txt: convert it to ReST markup

2016-09-22 Thread Mauro Carvalho Chehab
- Fix identation for the document title;
- use monotonic fonts for paths;
- use quote blocks where needed;
- adjust spaces to properly format paragraphs;
- use :menuselection: for the menu item;
- add it to the user book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/serial-console.txt  | 66 +++
 Documentation/user/index.rst  |  1 +
 Documentation/user/serial-console.rst |  1 +
 3 files changed, 37 insertions(+), 31 deletions(-)
 create mode 12 Documentation/user/serial-console.rst

diff --git a/Documentation/serial-console.txt b/Documentation/serial-console.txt
index 9a7bc8b3f479..1d9a3e48e929 100644
--- a/Documentation/serial-console.txt
+++ b/Documentation/serial-console.txt
@@ -1,15 +1,19 @@
-   Linux Serial Console
+Linux Serial Console
+
 
 To use a serial port as console you need to compile the support into your
 kernel - by default it is not compiled in. For PC style serial ports
-it's the config option next to "Standard/generic (dumb) serial support".
+it's the config option next to menu option:
+
+:menuselection:`Character devices --> Serial drivers --> 8250/16550 and 
compatible serial support --> Console on 8250/16550 and compatible serial port`
+
 You must compile serial support into the kernel and not as a module.
 
 It is possible to specify multiple devices for console output. You can
 define a new kernel command line option to select which device(s) to
 use for console output.
 
-The format of this option is:
+The format of this option is::
 
console=device,options
 
@@ -28,11 +32,11 @@ The format of this option is:
 
 You can specify multiple console= options on the kernel command line.
 Output will appear on all of them. The last device will be used when
-you open /dev/console. So, for example:
+you open ``/dev/console``. So, for example::
 
console=ttyS1,9600 console=tty0
 
-defines that opening /dev/console will get you the current foreground
+defines that opening ``/dev/console`` will get you the current foreground
 virtual console, and kernel messages will appear on both the VGA
 console and the 2nd serial port (ttyS1 or COM2) at 9600 baud.
 
@@ -44,61 +48,61 @@ first looks for a VGA card and then for a serial port. So 
if you don't
 have a VGA card in your system the first serial port will automatically
 become the console.
 
-You will need to create a new device to use /dev/console. The official
-/dev/console is now character device 5,1.
+You will need to create a new device to use ``/dev/console``. The official
+``/dev/console`` is now character device 5,1.
 
 (You can also use a network device as a console.  See
-Documentation/networking/netconsole.txt for information on that.)
+``Documentation/networking/netconsole.txt`` for information on that.)
 
-Here's an example that will use /dev/ttyS1 (COM2) as the console.
+Here's an example that will use ``/dev/ttyS1`` (COM2) as the console.
 Replace the sample values as needed.
 
-1. Create /dev/console (real console) and /dev/tty0 (master virtual
-   console):
+1. Create ``/dev/console`` (real console) and ``/dev/tty0`` (master virtual
+   console)::
 
-   cd /dev
-   rm -f console tty0
-   mknod -m 622 console c 5 1
-   mknod -m 622 tty0 c 4 0
+ cd /dev
+ rm -f console tty0
+ mknod -m 622 console c 5 1
+ mknod -m 622 tty0 c 4 0
 
 2. LILO can also take input from a serial device. This is a very
useful option. To tell LILO to use the serial port:
-   In lilo.conf (global section): 
+   In lilo.conf (global section)::
 
-   serial  = 1,9600n8 (ttyS1, 9600 bd, no parity, 8 bits)
+ serial  = 1,9600n8 (ttyS1, 9600 bd, no parity, 8 bits)
 
 3. Adjust to kernel flags for the new kernel,
-   again in lilo.conf (kernel section)
+   again in lilo.conf (kernel section)::
 
-   append = "console=ttyS1,9600" 
+ append = "console=ttyS1,9600"
 
 4. Make sure a getty runs on the serial port so that you can login to
it once the system is done booting. This is done by adding a line
-   like this to /etc/inittab (exact syntax depends on your getty):
+   like this to ``/etc/inittab`` (exact syntax depends on your getty)::
 
-   S1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
+ S1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
 
-5. Init and /etc/ioctl.save
+5. Init and ``/etc/ioctl.save``
 
-   Sysvinit remembers its stty settings in a file in /etc, called
-   `/etc/ioctl.save'. REMOVE THIS FILE before using the serial
+   Sysvinit remembers its stty settings in a file in ``/etc``, called
+   ``/etc/ioctl.save``. REMOVE THIS FILE before using the serial
console for the first time, because otherwise init will probably
set the baudrate to 38400 (baudrate of the virtual console).
 
-6. /dev/console and X
+6. ``/dev/console`` and X
Programs that want to do something with the virtual console usually
-   open /dev/console. If you have created the new /dev/console device,
+   

[PATCH 09/17] Documentation/adding-syscalls.txt: convert it to ReST markup

2016-09-22 Thread Mauro Carvalho Chehab
Convert adding-syscalls.txt to ReST markup and add it to the
development-process book:

- add extra lines to make Sphinx to correctly parse paragraphs;
- use quote blocks for examples;
- use monotonic font for dirs, function calls, etc;
- mark manpage pages using the right markup;
- add cross-reference to SubmittingPatches.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/adding-syscalls.txt  | 263 +++--
 .../development-process/adding-syscalls.rst|   1 +
 Documentation/development-process/index.rst|   1 +
 3 files changed, 141 insertions(+), 124 deletions(-)
 create mode 12 Documentation/development-process/adding-syscalls.rst

diff --git a/Documentation/adding-syscalls.txt 
b/Documentation/adding-syscalls.txt
index bbb31e091b28..f5b5b1aa51b3 100644
--- a/Documentation/adding-syscalls.txt
+++ b/Documentation/adding-syscalls.txt
@@ -3,7 +3,7 @@ Adding a New System Call
 
 This document describes what's involved in adding a new system call to the
 Linux kernel, over and above the normal submission advice in
-Documentation/SubmittingPatches.
+:ref:`Documentation/SubmittingPatches `.
 
 
 System Call Alternatives
@@ -19,30 +19,33 @@ interface.
object, it may make more sense to create a new filesystem or device.  This
also makes it easier to encapsulate the new functionality in a kernel module
rather than requiring it to be built into the main kernel.
+
  - If the new functionality involves operations where the kernel notifies
userspace that something has happened, then returning a new file
descriptor for the relevant object allows userspace to use
-   poll/select/epoll to receive that notification.
- - However, operations that don't map to read(2)/write(2)-like operations
-   have to be implemented as ioctl(2) requests, which can lead to a
-   somewhat opaque API.
+   ``poll``/``select``/``epoll`` to receive that notification.
+ - However, operations that don't map to
+   :manpage:`read(2)`/:manpage:`write(2)`-like operations
+   have to be implemented as :manpage:`ioctl(2)` requests, which can lead
+   to a somewhat opaque API.
+
  - If you're just exposing runtime system information, a new node in sysfs
-   (see Documentation/filesystems/sysfs.txt) or the /proc filesystem may be
-   more appropriate.  However, access to these mechanisms requires that the
+   (see ``Documentation/filesystems/sysfs.txt``) or the ``/proc`` filesystem 
may
+   be more appropriate.  However, access to these mechanisms requires that the
relevant filesystem is mounted, which might not always be the case (e.g.
in a namespaced/sandboxed/chrooted environment).  Avoid adding any API to
debugfs, as this is not considered a 'production' interface to userspace.
  - If the operation is specific to a particular file or file descriptor, then
-   an additional fcntl(2) command option may be more appropriate.  However,
-   fcntl(2) is a multiplexing system call that hides a lot of complexity, so
+   an additional :manpage:`fcntl(2)` command option may be more appropriate.  
However,
+   :manpage:`fcntl(2)` is a multiplexing system call that hides a lot of 
complexity, so
this option is best for when the new function is closely analogous to
-   existing fcntl(2) functionality, or the new functionality is very simple
+   existing :manpage:`fcntl(2)` functionality, or the new functionality is 
very simple
(for example, getting/setting a simple flag related to a file descriptor).
  - If the operation is specific to a particular task or process, then an
-   additional prctl(2) command option may be more appropriate.  As with
-   fcntl(2), this system call is a complicated multiplexor so is best reserved
-   for near-analogs of existing prctl() commands or getting/setting a simple
-   flag related to a process.
+   additional :manpage:`prctl(2)` command option may be more appropriate.  As
+   with :manpage:`fcntl(2)`, this system call is a complicated multiplexor so
+   is best reserved for near-analogs of existing ``prctl()`` commands or
+   getting/setting a simple flag related to a process.
 
 
 Designing the API: Planning for Extension
@@ -54,15 +57,16 @@ interface on the kernel mailing list, and it's important to 
plan for future
 extensions of the interface.
 
 (The syscall table is littered with historical examples where this wasn't done,
-together with the corresponding follow-up system calls -- eventfd/eventfd2,
-dup2/dup3, inotify_init/inotify_init1,  pipe/pipe2, renameat/renameat2 -- so
+together with the corresponding follow-up system calls --
+``eventfd``/``eventfd2``, ``dup2``/``dup3``, 
``inotify_init``/``inotify_init1``,
+``pipe``/``pipe2``, ``renameat``/``renameat2`` -- so
 learn from the history of the kernel and plan for extensions from the start.)
 
 For simpler system calls that only take a couple of arguments, the preferred
 way to allow for future 

[PATCH 16/17] CodeOfConflict: add it to the development-process book

2016-09-22 Thread Mauro Carvalho Chehab
Add an extra blank line to improve its output and add it to
the development-process bookset.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/CodeOfConflict | 1 +
 Documentation/development-process/CodeOfConflict.rst | 1 +
 Documentation/development-process/index.rst  | 1 +
 3 files changed, 3 insertions(+)
 create mode 12 Documentation/development-process/CodeOfConflict.rst

diff --git a/Documentation/CodeOfConflict b/Documentation/CodeOfConflict
index 1684d0b4efa6..c498ca80fce2 100644
--- a/Documentation/CodeOfConflict
+++ b/Documentation/CodeOfConflict
@@ -19,6 +19,7 @@ please contact the Linux Foundation's Technical Advisory 
Board at
 will work to resolve the issue to the best of their ability.  For more
 information on who is on the Technical Advisory Board and what their
 role is, please see:
+
http://www.linuxfoundation.org/programs/advisory-councils/tab
 
 As a reviewer of code, please strive to keep things civil and focused on
diff --git a/Documentation/development-process/CodeOfConflict.rst 
b/Documentation/development-process/CodeOfConflict.rst
new file mode 12
index ..555f8a5d3424
--- /dev/null
+++ b/Documentation/development-process/CodeOfConflict.rst
@@ -0,0 +1 @@
+../CodeOfConflict
\ No newline at end of file
diff --git a/Documentation/development-process/index.rst 
b/Documentation/development-process/index.rst
index acb2c00fa5c1..fe765ec5b52d 100644
--- a/Documentation/development-process/index.rst
+++ b/Documentation/development-process/index.rst
@@ -24,6 +24,7 @@ Contents:
applying-patches
email-clients
SubmitChecklist
+   CodeOfConflict
adding-syscalls
 
development-process
-- 
2.7.4




[PATCH 01/17] Documentation/applying-patches.txt: fix a bad external link

2016-09-22 Thread Mauro Carvalho Chehab
We can't use :ref: for external links.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/applying-patches.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/applying-patches.txt 
b/Documentation/applying-patches.txt
index 02ce4924468e..3395da13d415 100644
--- a/Documentation/applying-patches.txt
+++ b/Documentation/applying-patches.txt
@@ -427,7 +427,7 @@ The -mm patches are experimental patches released by Andrew 
Morton.
 
 In the past, -mm tree were used to also test subsystem patches, but this
 function is now done via the
-:ref:`linux-next `
+`linux-next `
 tree. The Subsystem maintainers push their patches first to linux-next,
 and, during the merge window, sends them directly to Linus.
 
-- 
2.7.4




[PATCH 00/17] More files converted to ReST format

2016-09-22 Thread Mauro Carvalho Chehab
This series contain conversion of other files that, IMHO, belong to the
development-process book or to an user manual book.

Patch 1 is actually just a fixup;

Patch 2 is actually patch 28/29 from my past series that weren' t
applied because it was merging file renames on it;

Patch 3 add ReST cross references for the already converted
patches;

patches 4, 5 and 6 convert README, REPORTING-BUGS and kernel-parameter.txt
to be the basis of a Linux Kernel User' s manual;

patch 7 add the already converted text files that are meant to be
read by Linux developers at the development-process book;

patch 8 creates the Linux Kernel User' s manual.

The remaining patches convert generic documentation that, IMHO,
belongs to either the "user"  or "develoment"  book.

I'll keep working on converting those files, but we have already enough
patches to be flushed to linux-doc and LKML :)



Mauro Carvalho Chehab (17):
  Documentation/applying-patches.txt: fix a bad external link
  Documentation/email-clients.txt: convert it to ReST markup
  docs-rst: add inter-document cross references
  REPORTING-BUGS: convert to ReST markup
  README: convert it to ReST markup
  Documentation/kernel-parameters.txt: convert to ReST markup
  docs-rst: add documents to development-process
  docs-rst: create an user's manual book
  Documentation/adding-syscalls.txt: convert it to ReST markup
  Documentation/bad_memory.txt: convert it to ReST markup
  Documentation/basic_profiling.rst: convert to ReST markup
  Documentation/binfmt_misc.txt: convert it to ReST markup
  Documentation/serial-console.txt: convert it to ReST markup
  Documentation/braille-console: convert it to ReST markup
  Documentation/BUG-HUNTING: convert to ReST markup
  CodeOfConflict: add it to the development-process book
  Documentation/devices.rst: convert it to ReST markup

 Documentation/BUG-HUNTING  |  162 +--
 Documentation/CodeOfConflict   |1 +
 Documentation/SecurityBugs |   12 +-
 Documentation/SubmitChecklist  |   10 +-
 Documentation/SubmittingDrivers|7 +-
 Documentation/SubmittingPatches|   24 +-
 Documentation/adding-syscalls.txt  |  263 ++---
 Documentation/applying-patches.txt |2 +-
 Documentation/bad_memory.txt   |   26 +-
 Documentation/basic_profiling.txt  |   59 +-
 Documentation/binfmt_misc.txt  |  134 ++-
 Documentation/braille-console.txt  |   30 +-
 Documentation/development-process/Changes.rst  |1 +
 .../development-process/CodeOfConflict.rst |1 +
 Documentation/development-process/CodingStyle.rst  |1 +
 Documentation/development-process/HOWTO.rst|1 +
 .../development-process/ManagementStyle.rst|1 +
 .../development-process/SubmitChecklist.rst|1 +
 .../development-process/SubmittingDrivers.rst  |1 +
 .../development-process/SubmittingPatches.rst  |1 +
 .../development-process/adding-syscalls.rst|1 +
 .../development-process/applying-patches.rst   |1 +
 .../development-process/development-process.rst|2 +
 .../development-process/email-clients.rst  |1 +
 Documentation/development-process/index.rst|   21 +
 Documentation/development-process/kernel-docs.rst  |1 +
 .../development-process/stable_api_nonsense.rst|1 +
 .../development-process/stable_kernel_rules.rst|1 +
 Documentation/devices.txt  | 1090 ++--
 Documentation/email-clients.txt|  208 ++--
 Documentation/index.rst|1 +
 Documentation/kernel-parameters.txt|   33 +-
 Documentation/serial-console.txt   |   68 +-
 Documentation/stable_kernel_rules.txt  |7 +-
 Documentation/user/BUG-HUNTING.rst |1 +
 Documentation/user/README.rst  |1 +
 Documentation/user/REPORTING-BUGS.rst  |1 +
 Documentation/user/SecurityBugs.rst|1 +
 Documentation/user/bad_memory.rst  |1 +
 Documentation/user/basic_profiling.rst |1 +
 Documentation/user/binfmt_misc.rst |1 +
 Documentation/user/braile-console.rst  |1 +
 Documentation/user/devices.rst |1 +
 Documentation/user/index.rst   |   20 +
 Documentation/user/kernel-parameters.rst   |1 +
 Documentation/user/serial-console.rst  |1 +
 README |  105 +-
 REPORTING-BUGS |   66 +-
 48 files changed, 1297 insertions(+), 1079 deletions(-)
 create mode 12 Documentation/development-process/Changes.rst
 create mode 12 

Re: [PATCH 1/3] virtio: Basic implementation of virtio pstore driver

2016-09-22 Thread Stefan Hajnoczi
On Sun, Sep 04, 2016 at 11:38:58PM +0900, Namhyung Kim wrote:
> The virtio pstore driver provides interface to the pstore subsystem so
> that the guest kernel's log/dump message can be saved on the host
> machine.  Users can access the log file directly on the host, or on the
> guest at the next boot using pstore filesystem.  It currently deals with
> kernel log (printk) buffer only, but we can extend it to have other
> information (like ftrace dump) later.
> 
> It supports legacy PCI device using a 16K buffer by default and it's
> configurable.  It uses two virtqueues - one for (sync) read and another
> for (async) write.  Since it cannot wait for write finished, it supports
> up to 128 concurrent IO.

Please document the locks that this code relies on.  It is generally not
safe to call virtqueue_*() from multiple threads.  I also wonder about
locking for virtio_pstore->req_id and other fields.  Are locks missing
or is something in pstore ensuring safety?

> +static int virt_pstore_open(struct pstore_info *psi)
> +{
> + struct virtio_pstore *vps = psi->data;
> + struct virtio_pstore_req *req;
> + struct virtio_pstore_res *res;
> + struct scatterlist sgo[1], sgi[1];
> + struct scatterlist *sgs[2] = { sgo, sgi };
> + unsigned int len;
> +
> + virt_pstore_get_reqs(vps, , );
> +
> + req->cmd = cpu_to_le16(VIRTIO_PSTORE_CMD_OPEN);
> +
> + sg_init_one(sgo, req, sizeof(*req));
> + sg_init_one(sgi, res, sizeof(*res));
> + virtqueue_add_sgs(vps->vq[0], sgs, 1, 1, vps, GFP_KERNEL);
> + virtqueue_kick(vps->vq[0]);
> +
> + wait_event(vps->acked, virtqueue_get_buf(vps->vq[0], ));
> + return le32_to_cpu(res->ret);

This assumes the device puts compatible Linux errno values in res->ret.
The function doesn't need to return -errno if I'm reading fs/pstore/
code correctly.  You could return -1 on error to avoid making this
assumption.  The same applies to other res->ret usage below.

> +}
> +
> +static int virt_pstore_close(struct pstore_info *psi)
> +{
> + struct virtio_pstore *vps = psi->data;
> + struct virtio_pstore_req *req = >req[vps->req_id];
> + struct virtio_pstore_res *res = >res[vps->req_id];

Assigning >req[vps->req_id]/>res[vps->req_id] is unnecessary,
virt_pstore_get_reqs() handles that below.

> + struct scatterlist sgo[1], sgi[1];
> + struct scatterlist *sgs[2] = { sgo, sgi };
> + unsigned int len;
> +
> + virt_pstore_get_reqs(vps, , );
> +
> + req->cmd = cpu_to_le16(VIRTIO_PSTORE_CMD_CLOSE);
> +
> + sg_init_one(sgo, req, sizeof(*req));
> + sg_init_one(sgi, res, sizeof(*res));
> + virtqueue_add_sgs(vps->vq[0], sgs, 1, 1, vps, GFP_KERNEL);
> + virtqueue_kick(vps->vq[0]);
> +
> + wait_event(vps->acked, virtqueue_get_buf(vps->vq[0], ));
> + return le32_to_cpu(res->ret);
> +}
> +
> +static ssize_t virt_pstore_read(u64 *id, enum pstore_type_id *type,
> + int *count, struct timespec *time,
> + char **buf, bool *compressed,
> + ssize_t *ecc_notice_size,
> + struct pstore_info *psi)
> +{
> + struct virtio_pstore *vps = psi->data;
> + struct virtio_pstore_req *req;
> + struct virtio_pstore_res *res;
> + struct virtio_pstore_fileinfo info;
> + struct scatterlist sgo[1], sgi[3];
> + struct scatterlist *sgs[2] = { sgo, sgi };
> + unsigned int len;
> + unsigned int flags;
> + int ret;
> + void *bf;
> +
> + virt_pstore_get_reqs(vps, , );
> +
> + req->cmd = cpu_to_le16(VIRTIO_PSTORE_CMD_READ);
> +
> + sg_init_one(sgo, req, sizeof(*req));
> + sg_init_table(sgi, 3);
> + sg_set_buf([0], res, sizeof(*res));
> + sg_set_buf([1], , sizeof(info));
> + sg_set_buf([2], psi->buf, psi->bufsize);
> + virtqueue_add_sgs(vps->vq[0], sgs, 1, 1, vps, GFP_KERNEL);
> + virtqueue_kick(vps->vq[0]);
> +
> + wait_event(vps->acked, virtqueue_get_buf(vps->vq[0], ));
> + if (len < sizeof(*res) + sizeof(info))
> + return -1;
> +
> + ret = le32_to_cpu(res->ret);
> + if (ret < 0)
> + return ret;
> +
> + len = le32_to_cpu(info.len);

We trust the device but a length check would be nice here to be clear
that the memcpy() below is always safe:

if (len > psi->bufsize)
return -1;

> +
> + bf = kmalloc(len, GFP_KERNEL);
> + if (bf == NULL)
> + return -ENOMEM;

There's no point in returning -ENOMEM if we return -1 and res->ret
above.  The caller has no way of knowing the true meaning of the return
value.  I would return -1 to be clear that there are no error constants.

> +
> + *id= le64_to_cpu(info.id);
> + *type  = from_virtio_type(info.type);
> + *count = le32_to_cpu(info.count);
> +
> + flags = le32_to_cpu(info.flags);
> + *compressed = flags & VIRTIO_PSTORE_FL_COMPRESSED;
> +
> + time->tv_sec  = le64_to_cpu(info.time_sec);
> + time->tv_nsec = 

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

2016-09-22 Thread Jean Delvare
On Thu, 22 Sep 2016 03:42:10 -0700, Joe Perches wrote:
> On Thu, 2016-09-22 at 11:24 +0200, Jean Delvare wrote:
> > I would rather suggest:
> > 
> > ERROR -> MUST_FIX
> > WARNING -> SHOULD_FIX
> > CHECK -> MAY_FIX
> 
> MUST is much stronger language than I would prefer.

That's what error means, really. When your compiler fails with an
error, you have no choice but to fix your code. Warnings on the other
hand may be ignored sometimes.

> There are still about a quarter million ERRORs just for
> spacing issues in the kernel tree.
> 
> Here are the top 10 ERROR checkpatch messages treewide as of
> a few days ago,
> 
> $ grep ERROR checkpatch.short_sorted_20160917
>  268308  ERROR:SPACING
>   37340  ERROR:CODE_INDENT
>   27678  ERROR:TRAILING_WHITESPACE
>   21024  ERROR:COMPLEX_MACRO
>   14048  ERROR:POINTER_LOCATION
>   12207  ERROR:TRAILING_STATEMENTS
>   11079  ERROR:OPEN_BRACE
>6802  ERROR:ASSIGN_IN_IF
>3940  ERROR:RETURN_PARENTHESES
>2322  ERROR:NON_OCTAL_PERMISSIONS
> 
> Maybe there could be some better classifications of the various
> messages.
> 
> But there are about two million checkpatch messages overall in
> the kernel tree.
> 
> That's a lot.

Sure. But I'm afraid you keep changing topics and I have no idea where
you are going. We started with "should there be a space before jump
labels", then out of nowhere we were discussing the wording of the
output of checkpatch (how is that related?) and now you pull statistics
out of your hat, like these numbers imply anything.

checkpatch was called checkPATCH for a reason. It's main intent was to
prevent NEW (coding-style mostly) errors from creeping into the kernel.
The fact that old code does now always follow these recommendations is
unfortunate but that doesn't make checkpatch wrong or bad.

ERROR means that the new code isn't allowed to do that. Period.

-- 
Jean Delvare
SUSE L3 Support


RE: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

2016-09-22 Thread Gabriele Paoloni
Hi Arnd

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: 21 September 2016 21:18
> To: Gabriele Paoloni
> Cc: zhichang; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; lorenzo.pieral...@arm.com; miny...@acm.org;
> linux-...@vger.kernel.org; gre...@linuxfoundation.org; John Garry;
> will.dea...@arm.com; linux-kernel@vger.kernel.org; Yuanzhichang;
> Linuxarm; xuwei (O); linux-ser...@vger.kernel.org;
> b...@kernel.crashing.org; zourongr...@gmail.com; liviu.du...@arm.com;
> kant...@163.com
> Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on
> Hip06
> 
> On Wednesday, September 21, 2016 4:20:55 PM CEST Gabriele Paoloni
> wrote:
> > > -Original Message-
> > > From: zhichang [mailto:zhichang.yua...@gmail.com]
> > > On 2016年09月15日 20:24, Arnd Bergmann wrote:
> > > > On Thursday, September 15, 2016 12:05:51 PM CEST Gabriele Paoloni
> > > wrote:
> > > >>> -Original Message-
> > > >>> On Thursday, September 15, 2016 8:02:27 AM CEST Gabriele
> Paoloni
> > > wrote:
> > > >> I think that maybe having the 1:1 range mapping doesn't
> > > >> reflect well the reality but it is the less painful
> > > >> solution...
> > > >>
> > > >> What's your view?
> > > >
> > > > We can check the 'i' bit for I/O space in of_bus_isa_get_flags,
> > > > and that should be enough to translate the I/O port number.
> > > >
> > > > The only part we need to change here is to not go through
> > > > the crazy conversion all the way from PCI I/O space to a
> > > > physical address and back to a (logical) port number
> > > > that we do today with of_translate_address/pci_address_to_pio.
> > > >
> > > Sorry for the late response! Several days' leave
> > > Do you want to bypass of_translate_address and pci_address_to_pio
> for
> > > the registered specific PIO?
> > > I think the bypass for of_translate_address is ok, but worry some
> new
> > > issues will emerge without the
> > > conversion between physical address and logical/linux port number.
> 
> The same function that handles the non-translated region would
> do that conversion.
> 
> > > When PCI host bridge which support IO operations is configured and
> > > enabled, the pci_address_to_pio will
> > > populate the logical IO range from ZERO for the first host bridge.
> Our
> > > LPC will also use part of the IO range
> > > started from ZERO. It will make in/out enter the wrong branch
> possibly.
> > >
> > > In V2, the 0 - 0x1000 logical IO range is reserved for LPC use
> only.
> > > But it seems not so good. In this way,
> > > PCI has no chance to use low 4K IO range(logical).
> > >
> > > So, in V3, applying the conversion from physical/cpu address to
> > > logical/linux IO port for any IO ranges,
> > > including the LPC, but recorded the logical IO range for LPC. When
> > > calling in/out with a logical port address,
> > > we can check this port fall into LPC logical IO range and get back
> the
> > > real IO.
> 
> Right, and the same translation can be used in
> __of_address_to_resource()
> going the opposite way.
> 
> > > Do you have further comments about this??
> >
> > I think there are two separate issues to be discussed:
> >
> > The first issue is about having of_translate_address failing due to
> > "range" missing. About this Arnd suggested that it is not appropriate
> > to have a range describing a bridge 1:1 mapping and this was
> discussed
> > before in this thread. Arnd had a suggestion about this (see below)
> > however (looking twice at the code) it seems to me that such solution
> > would lead to quite some duplication from __of_translate_address()
> > in order to retrieve the actual addr from dt...
> 
> I don't think we need to duplicate much, we can probably safely
> assume that there are no nontrivial ranges in devices below the LPC
> node, so we just walk up the bus to see if the node is a child
> (or possibly grandchild etc) of the LPC bus, and treat any IO port
> number under there as a physical port number, which has a known
> offset from the Linux I/O port number.
> 
> > I think extending of_empty_ranges_quirk() may be a reasonable
> solution.
> > What do you think Arnd?
> 
> I don't really like that idea, that quirk is meant to work around
> broken DTs, but we can just make the DT valid and implement the
> code properly.

Ok  I understand your point where it is not right to use of_empty_ranges_quirk()
As a quirk is used to work around broken HW or broken FW (as in this case)
rather than to fix code

What about the following? I think adding the check you suggested next to
of_empty_ranges_quirk() is adding the case we need in the right point (thus
avoiding any duplication)
 
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -457,6 +457,15 @@ static struct of_bus *of_match_bus(struct device_node *np)
return NULL;
 }
 
+static inline int of_isa_indirect_io(struct device_node *np)
+{
+   /*
+* check if the current node is an isa bus and if indirectio operation
+ 

Re: [PATCH] drm/i2c: tda998x: don't register the connector

2016-09-22 Thread Russell King - ARM Linux
On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote:
> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
>  wrote:
> > On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
> >> Actually, could you please hold off picking this up? We need to make
> >> changes in mali-dp and hdlcd or this will mess up their registration.
> >> I will send those patches later today, but better if this all goes in
> >> together (whenever that ends up being).
> >
> > Sorry, but I'm annoyed with this - the impression being given was that
> > I was holding up this patch by not testing it on Armada, and I brought
> > up the issue about registration at the beginning of this.
> >
> > Now we're _just_ finding out that there are drivers where removing the
> > connector registration in tda998x causes them to break?  It's a bit
> > late to be checking your own drivers when you've been chasing me...
> >
> > Sorry, but it sounds like we're not ready to make this change - and as
> > it's the very last day that changes will appear in linux-next prior to
> > the merge window (assuming Linus releases 4.8 on Sunday), I'd suggest
> > holding off until after the merge window is over, so we can get some
> > testing with these other two drivers with this change in place.
> >
> 
> sigh. I just pushed my queue to drm-misc, which included this patch.
> Sounds like I should revert?

Why did you do push it _without_ an ack from the maintainer of the
driver when the comments on the list were clearly indicating that it
was waiting for testing and such an ack?

There's something horribly wrong with the process here.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

2016-09-22 Thread Borislav Petkov
On Thu, Sep 22, 2016 at 07:59:08AM -0400, Prarit Bhargava wrote:
> System boots with (usually) with 2 threads/core.  Some performance users want
> one thread per core.  Since there is no "noht" option anymore, users use /sys 
> to
> disable a thread on each core.

I see.

> core_siblings and thread_siblings are the online thread's sibling cores and
> threads that are available to the scheduler

Hmm, I see something else:

:
7) /sys/devices/system/cpu/cpuX/topology/core_siblings:

internal kernel map of cpuX's hardware threads within the same
physical_package_id.

> and should be 0 when the thread is offline. That comes directly from
> reading the code.

But then code which reads those will have to *know* that those cores are
offline - otherwise it would be confused by what it is reading there.

For example, the core siblings of an offlined core are still the same,
they don't change. It is just the core that is offline.

> See commit 20102ac5bee3 ("cpupower: cpupower monitor reports uninitialized
> values for offline cpus").  That patch papers over the bug of not being able 
> to
> find core_id and physical_package_id for an offline thread.

Right, and this is *exactly* the *right* thing to do - tools should
handle the case gracefully when cores are offline.

And we already state that explicitly in /sys/devices/system/cpu/online.

And for offlined cores they should show exactly that - cores
are offlined and either say that the measurement is going to be
wrong/innacurate or if they're showing per-core info, they don't show it
for the offlined cores or show special symbols like stars and whatnot.

So far I still see no need for changing anything in the kernel.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 


Re: [PATCH v2 2/6] MIPS: tlb-r4k: If there are wired entries, don't use TLBINVF

2016-09-22 Thread Ralf Baechle
On Tue, Sep 20, 2016 at 09:47:25AM +0100, Matt Redfearn wrote:

> When adding a wired entry to the TLB via add_wired_entry, the tlb is
> flushed with local_flush_tlb_all, which on CPUs with TLBINV results in
> the new wired entry being flushed again.
> 
> Behavior of the TLBINV instruction applies to all applicable TLB entries
> and is unaffected by the setting of the Wired register. Therefore if
> the TLB has any wired entries, fall back to iterating over the entries
> rather than blasting them all using TLBINVF.
> 
> Signed-off-by: Matt Redfearn 

Queued for 4.9..

  Ralf


Re: [PATCH v2] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Baolin Wang
On 22 September 2016 at 20:23, Greg KH  wrote:
> On Thu, Sep 22, 2016 at 07:43:59PM +0800, Baolin Wang wrote:
>> From: Badhri Jagan Sridharan 
>>
>> Some USB managament on userspace (like Android system) rely on the uevents
>> generated by the composition driver to generate user notifications. Thus this
>> patch adds uevents to be generated whenever USB changes its state: connected,
>> disconnected, configured.
>>
>> The original code was created by Badhri Jagan Sridharan, and I did some
>> optimization.
>>
>> Signed-off-by: Badhri Jagan Sridharan 
>
> You can't just add someone's signed-off-by to a patch, go read what the
> legal agreement you just made for someone else at a different company
> (hint, you might get a nasty-gram from a google lawyer...)

OK. I will talk with Badhri if I can upstream these.

>
>> Signed-off-by: Baolin Wang 
>> ---
>> Changes since v1:
>>  - Add Badhri's Signed-off-by.
>> ---
>>  drivers/usb/gadget/Kconfig|8 +++
>>  drivers/usb/gadget/configfs.c |  107 
>> +
>>  2 files changed, 115 insertions(+)
>>
>> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
>> index 2ea3fc3..9f5d0c6 100644
>> --- a/drivers/usb/gadget/Kconfig
>> +++ b/drivers/usb/gadget/Kconfig
>> @@ -223,6 +223,14 @@ config USB_CONFIGFS
>> appropriate symbolic links.
>> For more information see Documentation/usb/gadget_configfs.txt.
>>
>> +config USB_CONFIGFS_UEVENT
>> + boolean "Uevent notification of Gadget state"
>> + depends on USB_CONFIGFS
>
>
>
>> + help
>> +   Enable uevent notifications to userspace when the gadget
>> +   state changes. The gadget can be in any of the following
>> +   three states: "CONNECTED/DISCONNECTED/CONFIGURED"
>> +
>>  config USB_CONFIGFS_SERIAL
>>   bool "Generic serial bulk in/out"
>>   depends on USB_CONFIGFS
>> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
>> index 3984787..4c2bc27 100644
>> --- a/drivers/usb/gadget/configfs.c
>> +++ b/drivers/usb/gadget/configfs.c
>> @@ -60,6 +60,11 @@ struct gadget_info {
>>   bool use_os_desc;
>>   char b_vendor_code;
>>   char qw_sign[OS_STRING_QW_SIGN_LEN];
>> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
>> + bool connected;
>> + bool sw_connected;
>> + struct work_struct work;
>> +#endif
>>  };
>>
>>  static inline struct gadget_info *to_gadget_info(struct config_item *item)
>> @@ -1197,6 +1202,57 @@ int composite_dev_prepare(struct usb_composite_driver 
>> *composite,
>>  int composite_os_desc_req_prepare(struct usb_composite_dev *cdev,
>> struct usb_ep *ep0);
>>
>> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
>> +static void configfs_work(struct work_struct *data)
>> +{
>> + struct gadget_info *gi = container_of(data, struct gadget_info, work);
>> + struct usb_composite_dev *cdev = >cdev;
>> + char *disconnected[2] = { "USB_STATE=DISCONNECTED", NULL };
>> + char *connected[2] = { "USB_STATE=CONNECTED", NULL };
>> + char *configured[2] = { "USB_STATE=CONFIGURED", NULL };
>> + /* 0-connected 1-configured 2-disconnected */
>> + bool status[3] = { false, false, false };
>> + unsigned long flags;
>> + bool uevent_sent = false;
>> +
>> + spin_lock_irqsave(>lock, flags);
>> + if (cdev->config && gi->connected)
>> + status[1] = true;
>> +
>> + if (gi->connected != gi->sw_connected) {
>> + if (gi->connected)
>> + status[0] = true;
>> + else
>> + status[2] = true;
>> + gi->sw_connected = gi->connected;
>> + }
>> + spin_unlock_irqrestore(>lock, flags);
>> +
>> + if (status[0]) {
>> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, connected);
>> + pr_info("%s: sent uevent %s\n", __func__, connected[0]);
>
> You are kidding, right?
>
>> + uevent_sent = true;
>> + }
>> +
>> + if (status[1]) {
>> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, configured);
>> + pr_info("%s: sent uevent %s\n", __func__, configured[0]);
>
> Come on, please...
>
>> + uevent_sent = true;
>> + }
>> +
>> + if (status[2]) {
>> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, disconnected);
>> + pr_info("%s: sent uevent %s\n", __func__, disconnected[0]);
>
> This is getting funny...
>
>> + uevent_sent = true;
>> + }
>> +
>> + if (!uevent_sent) {
>> + pr_info("%s: did not send uevent (%d %d %p)\n", __func__,
>> + gi->connected, gi->sw_connected, cdev->config);
>
> Nope, not funny anymore.
>
>> + }
>> +}
>> +#endif
>> +
>>  static void purge_configs_funcs(struct gadget_info *gi)
>>  {
>>   struct usb_configuration*c;
>> @@ -1386,13 +1442,60 @@ static void configfs_composite_unbind(struct 
>> 

Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case

2016-09-22 Thread Lorenzo Pieralisi
On Thu, Sep 22, 2016 at 11:10:13AM +, Gabriele Paoloni wrote:
> Hi Lorenzo, Bjorn
> 
> > -Original Message-
> > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> > Sent: 22 September 2016 10:50
> > To: Bjorn Helgaas
> > Cc: Ard Biesheuvel; Tomasz Nowicki; David Daney; Will Deacon; Catalin
> > Marinas; Rafael Wysocki; Arnd Bergmann; Hanjun Guo; Sinan Kaya;
> > Jayachandran C; Christopher Covington; Duc Dang; Robert Richter; Marcin
> > Wojtas; Liviu Dudau; Wangyijing; Mark Salter; linux-
> > p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Linaro ACPI
> > Mailman List; Jon Masters; Andrea Gallo; Jeremy Linton; liudongdong
> > (C); Gabriele Paoloni; Jeff Hugo; linux-a...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; Rafael J. Wysocki
> > Subject: Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-
> > specific register range for ACPI case
> > 
> > On Wed, Sep 21, 2016 at 01:04:57PM -0500, Bjorn Helgaas wrote:
> > > On Wed, Sep 21, 2016 at 03:05:49PM +0100, Lorenzo Pieralisi wrote:
> > > > On Tue, Sep 20, 2016 at 02:17:44PM -0500, Bjorn Helgaas wrote:
> > > > > On Tue, Sep 20, 2016 at 04:09:25PM +0100, Ard Biesheuvel wrote:
> > > >
> > > > [...]
> > > >
> > > > > > None of these platforms can be fixed entirely in software, and
> > given
> > > > > > that we will not be adding quirks for new broken hardware, we
> > should
> > > > > > ask ourselves whether having two versions of a quirk, i.e., one
> > for
> > > > > > broken hardware + currently shipping firmware, and one for the
> > same
> > > > > > broken hardware with fixed firmware is really an improvement
> > over what
> > > > > > has been proposed here.
> > > > >
> > > > > We're talking about two completely different types of quirks:
> > > > >
> > > > >   1) MCFG quirks to use memory-mapped config space that doesn't
> > quite
> > > > >  conform to the ECAM model in the PCIe spec, and
> > > > >
> > > > >   2) Some yet-to-be-determined method to describe address space
> > > > >  consumed by a bridge.
> > > > >
> > > > > The first two patches of this series are a nice implementation
> > for 1).
> > > > > The third patch (ThunderX-specific) is one possibility for 2),
> > but I
> > > > > don't like it because there's no way for generic software like
> > the
> > > > > ACPI core to discover these resources.
> > > >
> > > > Ok, so basically this means that to implement (2) we need to assign
> > > > some sort of _HID to these quirky PCI bridges (so that we know what
> > > > device they represent and we can retrieve their _CRS). I take from
> > > > this discussion that the goal is to make sure that all non-config
> > > > resources have to be declared through _CRS device objects, which is
> > > > fine but that requires a FW update (unless we can fabricate ACPI
> > > > devices and corresponding _CRS in the kernel whenever we match a
> > > > given MCFG table signature).
> > >
> > > All resources consumed by ACPI devices should be declared through
> > > _CRS.  If you want to fabricate ACPI devices or _CRS via kernel
> > > quirks, that's fine with me.  This could be triggered via MCFG
> > > signature, DMI info, host bridge _HID, etc.
> > 
> > I think the PNP quirk approach + PNP0c02 resource put forward by Gab
> > is enough.
> 
> Great thanks as we take a final decision I will ask Dogndgong to submit
> another RFC based on this approach
> 
> > 
> > > > We discussed this already and I think we should make a decision:
> > > >
> > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-
> > March/414722.html
> > > >
> > > > > > > I'd like to step back and come up with some understanding of
> > how
> > > > > > > non-broken firmware *should* deal with this issue.  Then, if
> > we *do*
> > > > > > > work around this particular broken firmware in the kernel, it
> > would be
> > > > > > > nice to do it in a way that fits in with that understanding.
> > > > > > >
> > > > > > > For example, if a companion ACPI device is the preferred
> > solution, an
> > > > > > > ACPI quirk could fabricate a device with the required
> > resources.  That
> > > > > > > would address the problem closer to the source and make it
> > more likely
> > > > > > > that the rest of the system will work correctly: /proc/iomem
> > could
> > > > > > > make sense, things that look at _CRS generically would work
> > (e.g,
> > > > > > > /sys/, an admittedly hypothetical "lsacpi", etc.)
> > > > > > >
> > > > > > > Hard-coding stuff in drivers is a point solution that doesn't
> > provide
> > > > > > > any guidance for future platforms and makes it likely that
> > the hack
> > > > > > > will get copied into even more drivers.
> > > > > > >
> > > > > >
> > > > > > OK, I see. But the guidance for future platforms should be 'do
> > not
> > > > > > rely on quirks', and what I am arguing here is that the more we
> > polish
> > > > > > up this code and make it clean and reusable, the more likely it
> > is
> > > > > > that will end up getting abused by new broken 

[PATCH v2 15/23] drm/omap: omap_display_timings: Use display_flags for pixel data edge

2016-09-22 Thread Peter Ujfalusi
In preparation to move the stack to use the generic videmode struct for
display timing information use display_flags for pixel data edge.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c |  3 +--
 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c|  3 +--
 .../gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c  |  3 +--
 drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c  |  3 +--
 .../gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c   |  3 +--
 drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c  |  3 +--
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c  |  3 +--
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c  |  3 +--
 drivers/gpu/drm/omapdrm/dss/dispc.c  | 16 +---
 drivers/gpu/drm/omapdrm/dss/display.c|  9 +
 drivers/gpu/drm/omapdrm/dss/dsi.c|  3 ++-
 drivers/gpu/drm/omapdrm/dss/omapdss.h|  2 --
 drivers/gpu/drm/omapdrm/dss/rfbi.c   |  3 ++-
 drivers/gpu/drm/omapdrm/dss/sdi.c|  2 +-
 drivers/gpu/drm/omapdrm/dss/venc.c   |  8 
 drivers/gpu/drm/omapdrm/omap_connector.c |  3 +--
 16 files changed, 24 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index b94bfca0ecae..6f130862db8a 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -33,11 +33,10 @@ static const struct omap_video_timings dvic_default_timings 
= {
.vsync_len  = 4,
.vback_porch= 7,
 
-   .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
 
.flags  = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_HIGH |
- DISPLAY_FLAGS_DE_HIGH,
+ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
 };
 
 struct panel_drv_data {
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
index e3b8dddc90bd..eec079e017f0 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
@@ -115,9 +115,8 @@ static void tfp410_disable(struct omap_dss_device *dssdev)
 
 static void tfp410_fix_timings(struct omap_video_timings *timings)
 {
-   timings->data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
timings->sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
-   timings->flags |= DISPLAY_FLAGS_DE_HIGH;
+   timings->flags |= DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE;
 }
 
 static void tfp410_set_timings(struct omap_dss_device *dssdev,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c 
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 7d4c59bf1950..33cdc107ed21 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -33,11 +33,10 @@ static struct omap_video_timings lb035q02_timings = {
.vfront_porch   = 4,
.vback_porch= 18,
 
-   .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
 
.flags  = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
- DISPLAY_FLAGS_DE_HIGH,
+ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
 };
 
 struct panel_drv_data {
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c 
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index f0edb4ece16d..475420239b40 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -77,11 +77,10 @@ static const struct omap_video_timings 
nec_8048_panel_timings = {
.vsync_len  = 1,
.vback_porch= 4,
 
-   .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
 
.flags  = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
- DISPLAY_FLAGS_DE_HIGH,
+ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
 };
 
 #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c 
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index a18dd7160df0..fb7e032209bd 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -49,11 +49,10 @@ static const struct omap_video_timings sharp_ls_timings = {
.vfront_porch   = 1,
.vback_porch= 1,
 
-   .data_pclk_edge = 

[PATCH v2 19/23] drm/omap: Use consistent name for struct videomode

2016-09-22 Thread Peter Ujfalusi
Use 'vm' to refer to a struct videomode instead of 'p', 't', 'timings' or
something else.

The code will be easier to follow if we use consistent names.

Signed-off-by: Peter Ujfalusi 
---
 .../gpu/drm/omapdrm/displays/connector-analog-tv.c |  26 ++---
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c   |  26 ++---
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c  |  26 ++---
 drivers/gpu/drm/omapdrm/displays/encoder-opa362.c  |  20 ++--
 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c  |  31 +++---
 .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c   |  20 ++--
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c   |  26 ++---
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c|  23 ++---
 .../omapdrm/displays/panel-lgphilips-lb035q02.c|  26 ++---
 .../drm/omapdrm/displays/panel-nec-nl8048hl11.c|  26 ++---
 .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c |  26 ++---
 .../drm/omapdrm/displays/panel-sony-acx565akm.c|  26 ++---
 .../drm/omapdrm/displays/panel-tpo-td028ttec1.c|  26 ++---
 .../drm/omapdrm/displays/panel-tpo-td043mtea1.c|  26 ++---
 drivers/gpu/drm/omapdrm/dss/dispc.c| 114 ++---
 drivers/gpu/drm/omapdrm/dss/display.c  |   8 +-
 drivers/gpu/drm/omapdrm/dss/dpi.c  |  38 +++
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 108 +--
 drivers/gpu/drm/omapdrm/dss/dss.h  |   5 +-
 drivers/gpu/drm/omapdrm/dss/hdmi.h |   8 +-
 drivers/gpu/drm/omapdrm/dss/hdmi4.c|  32 +++---
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.c   |   8 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c|  32 +++---
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c   |  68 ++--
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c  |  58 +--
 drivers/gpu/drm/omapdrm/dss/omapdss.h  |  57 +--
 drivers/gpu/drm/omapdrm/dss/output.c   |   5 +-
 drivers/gpu/drm/omapdrm/dss/rfbi.c |  52 +-
 drivers/gpu/drm/omapdrm/dss/sdi.c  |  30 +++---
 drivers/gpu/drm/omapdrm/dss/venc.c |  39 ---
 drivers/gpu/drm/omapdrm/omap_connector.c   |  20 ++--
 drivers/gpu/drm/omapdrm/omap_crtc.c|  18 ++--
 drivers/gpu/drm/omapdrm/omap_encoder.c |   8 +-
 33 files changed, 527 insertions(+), 535 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c 
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 53a4e6942616..aaa8a58390f1 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -24,12 +24,12 @@ struct panel_drv_data {
 
struct device *dev;
 
-   struct videomode timings;
+   struct videomode vm;
 
bool invert_polarity;
 };
 
-static const struct videomode tvc_pal_timings = {
+static const struct videomode tvc_pal_vm = {
.hactive= 720,
.vactive= 574,
.pixelclock = 1350,
@@ -93,7 +93,7 @@ static int tvc_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
 
-   in->ops.atv->set_timings(in, >timings);
+   in->ops.atv->set_timings(in, >vm);
 
if (!ddata->dev->of_node) {
in->ops.atv->set_type(in, OMAP_DSS_VENC_TYPE_COMPOSITE);
@@ -127,32 +127,32 @@ static void tvc_disable(struct omap_dss_device *dssdev)
 }
 
 static void tvc_set_timings(struct omap_dss_device *dssdev,
-   struct videomode *timings)
+   struct videomode *vm)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata->in;
 
-   ddata->timings = *timings;
-   dssdev->panel.timings = *timings;
+   ddata->vm = *vm;
+   dssdev->panel.vm = *vm;
 
-   in->ops.atv->set_timings(in, timings);
+   in->ops.atv->set_timings(in, vm);
 }
 
 static void tvc_get_timings(struct omap_dss_device *dssdev,
-   struct videomode *timings)
+   struct videomode *vm)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
 
-   *timings = ddata->timings;
+   *vm = ddata->vm;
 }
 
 static int tvc_check_timings(struct omap_dss_device *dssdev,
-   struct videomode *timings)
+struct videomode *vm)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata->in;
 
-   return in->ops.atv->check_timings(in, timings);
+   return in->ops.atv->check_timings(in, vm);
 }
 
 static u32 tvc_get_wss(struct omap_dss_device *dssdev)
@@ -254,14 +254,14 @@ static int tvc_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   ddata->timings = tvc_pal_timings;
+   ddata->vm = tvc_pal_vm;
 
dssdev = >dssdev;
dssdev->driver = _driver;

[PATCH v2 04/23] drm/omap: omap_display_timings: rename hfp to hfront_porch

2016-09-22 Thread Peter Ujfalusi
In preparation to move the stack to use the generic videmode struct for
display timing information rename the hfp member to hfront_porch.

Signed-off-by: Peter Ujfalusi 
---
 .../gpu/drm/omapdrm/displays/connector-analog-tv.c |  2 +-
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c   |  2 +-
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c  |  2 +-
 .../omapdrm/displays/panel-lgphilips-lb035q02.c|  2 +-
 .../drm/omapdrm/displays/panel-nec-nl8048hl11.c|  2 +-
 .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c |  2 +-
 .../drm/omapdrm/displays/panel-sony-acx565akm.c|  2 +-
 .../drm/omapdrm/displays/panel-tpo-td028ttec1.c|  2 +-
 .../drm/omapdrm/displays/panel-tpo-td043mtea1.c|  2 +-
 drivers/gpu/drm/omapdrm/dss/dispc.c| 22 --
 drivers/gpu/drm/omapdrm/dss/display.c  |  4 ++--
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 22 +++---
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c   |  8 
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c  |  6 +++---
 drivers/gpu/drm/omapdrm/dss/omapdss.h  |  2 +-
 drivers/gpu/drm/omapdrm/dss/rfbi.c |  2 +-
 drivers/gpu/drm/omapdrm/dss/venc.c |  4 ++--
 drivers/gpu/drm/omapdrm/omap_connector.c   |  4 ++--
 18 files changed, 47 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c 
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 5205a8ef6038..6d089b337bcb 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -34,7 +34,7 @@ static const struct omap_video_timings tvc_pal_timings = {
.vactive= 574,
.pixelclock = 1350,
.hsync_len  = 64,
-   .hfp= 12,
+   .hfront_porch   = 12,
.hbp= 68,
.vsw= 5,
.vfp= 5,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index e9a8ea5043e6..cf893866aca0 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -25,7 +25,7 @@ static const struct omap_video_timings dvic_default_timings = 
{
 
.pixelclock = 2350,
 
-   .hfp= 48,
+   .hfront_porch   = 48,
.hsync_len  = 32,
.hbp= 80,
 
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index 707fd62cb99c..fd1178b57f79 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -26,7 +26,7 @@ static const struct omap_video_timings hdmic_default_timings 
= {
.vactive= 480,
.pixelclock = 25175000,
.hsync_len  = 96,
-   .hfp= 16,
+   .hfront_porch   = 16,
.hbp= 48,
.vsw= 2,
.vfp= 11,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c 
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 6fbf07048df0..677db7b22a02 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -26,7 +26,7 @@ static struct omap_video_timings lb035q02_timings = {
.pixelclock = 650,
 
.hsync_len  = 2,
-   .hfp= 20,
+   .hfront_porch   = 20,
.hbp= 68,
 
.vsw= 2,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c 
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index 734ca68f56e4..8b2601010671 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -70,7 +70,7 @@ static const struct omap_video_timings nec_8048_panel_timings 
= {
.hactive= LCD_XRES,
.vactive= LCD_YRES,
.pixelclock = LCD_PIXEL_CLOCK,
-   .hfp= 6,
+   .hfront_porch   = 6,
.hsync_len  = 1,
.hbp= 4,
.vfp= 3,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c 
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index 5e96edebdd5c..c8348090e745 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -42,7 +42,7 @@ static const struct omap_video_timings sharp_ls_timings = {
.pixelclock = 1920,
 
.hsync_len  = 2,
-   .hfp= 1,
+   .hfront_porch   = 1,
.hbp= 28,
 
.vsw= 1,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c 

RE: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case

2016-09-22 Thread Gabriele Paoloni
Hi Bjorn

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: 21 September 2016 19:59
> To: Gabriele Paoloni
> Cc: Ard Biesheuvel; Tomasz Nowicki; David Daney; Will Deacon; Catalin
> Marinas; Rafael Wysocki; Lorenzo Pieralisi; Arnd Bergmann; Hanjun Guo;
> Sinan Kaya; Jayachandran C; Christopher Covington; Duc Dang; Robert
> Richter; Marcin Wojtas; Liviu Dudau; Wangyijing; Mark Salter; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Linaro ACPI
> Mailman List; Jon Masters; Andrea Gallo; Jeremy Linton; liudongdong
> (C); Jeff Hugo; linux-a...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Rafael J. Wysocki
> Subject: Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-
> specific register range for ACPI case
> 
> On Wed, Sep 21, 2016 at 02:10:55PM +, Gabriele Paoloni wrote:
> > Hi Bjorn
> >
> > [...]
> >
> >
> > >
> > > If future hardware is completely ECAM-compliant and we don't need
> any
> > > more MCFG quirks, that would be great.
> > >
> > > But we'll still need to describe that memory-mapped config space
> > > somewhere.  If that's done with PNP0C02 or similar devices (as is
> done
> > > on my x86 laptop), we'd be all set.
> > >
> > > If we need to work around firmware in the field that doesn't do
> that,
> > > one possibility is a PNP quirk along the lines of
> > > quirk_amd_mmconfig_area().
> >
> > So, if my understanding is correct, for platforms that have not been
> > shipped yet you propose to use PNP0C02 in the ACPI table in order to
> > declare a motherboard reserved resource whereas for shipped platforms
> > you propose to have a quirk along pnp_fixups in order to track the
> > resource usage even if values are hardcoded...correct?
> 
> Yes.  I'm open to alternate proposals, but x86 uses PNP0C02, and
> following existing practice seems reasonable.
> 
> > Before Tomasz came up with this patchset we had a call between the
> vendors
> > involved in this PCI quirks saga and other guys from Linaro and ARM.
> >
> > Lorenzo summarized the outcome as in the following link
> > http://lkml.iu.edu/hypermail/linux/kernel/1606.2/03344.html
> >
> > Since this quirks mechanism has been discussed for quite a long time
> now
> > IMHO it would be good to have a last call including also you (Bjorn)
> so
> > that we can all agree on what to do and we avoid changing our drivers
> again
> > and again...
> 
> I think we're converging pretty fast.  As far as I'm concerned, the
> v6 ECAM quirks implementation is perfect.  The only remaining issue is
> reporting the ECAM resources, and I haven't seen objections to using
> PNP0C02 + PNP quirks for broken firmware.
> 
> There is the question of how or whether to associate a PNP0A03 PCI
> bridge with resources from a different PNP0C02 device, but that's not
> super important.  If the hard-coded resources appear both in a quirk
> and in the PCI bridge driver, it's ugly but not the end of the world.
> We've still achieved the objective of avoiding landmines in the
> address space.

Ok got it many thanks

Gab

> 
> Bjorn


[PATCH v2 00/23] drm/omap: Convert to use videomode from omap_video_timings

2016-09-22 Thread Peter Ujfalusi
Hi,

Changes since v1:
- separated the patches from the sync drive edge selection series [1]
- commit messages updated as per Tomi's comments
- other comments from Tomi for patch 10 (was 13) and 11 (was 14) addressed also

The following series will convert the omapdrm stack to use the generic videmode
instead of the private omap_video_timings struct for the panel information.
It depends on the 'video: of: Drive edge selection for sync' series [1] as it is
using the flags introduced by the sync drive edge selection support.

The patches are most mechanical ones. I have decided to split it up to small
chunks and did one change at the time to finally remove the omap_video_timings
from omapdrm.

generated on top of 4.8-rc7 + [1]

Regards,
Peter

[1] http://marc.info/?l=linux-fbdev=147454058512738=2

---
Peter Ujfalusi (23):
  drm/omap: omap_display_timings: rename x_res to hactive
  drm/omap: omap_display_timings: rename y_res to vactive
  drm/omap: omap_display_timings: rename hsw to hsync_len
  drm/omap: omap_display_timings: rename hfp to hfront_porch
  drm/omap: omap_display_timings: rename hbp to hback_porch
  drm/omap: omap_display_timings: rename vsw to vsync_len
  drm/omap: omap_display_timings: rename vfp to vfront_porch
  drm/omap: omap_display_timings: rename vbp to vback_porch
  drm/omap: HDMI5: Use pointer to cfg->v_fc_config.timings in
hdmi_core_video_config
  drm/omap: omap_display_timings: Use display_flags for interlace mode
  drm/omap: dispc: Simplify _dispc_mgr_set_lcd_timings() parameters
  drm/omap: omap_display_timings: Use display_flags for h/vsync level
  drm/omap: omap_display_timings: Use display_flags for DE level
  drm/omap: omap_display_timings: Use display_flags for double_pixel
mode
  drm/omap: omap_display_timings: Use display_flags for pixel data edge
  drm/omap: omap_display_timings: Use display_flags for sync edge
  drm/omap: Change the types of struct omap_video_timings members
  drm/omap: Replace struct omap_video_timings with videomode
  drm/omap: Use consistent name for struct videomode
  drm/omap: panel-tpo-td043mtea1: Add note for incorrect sync drive edge
  drm/omap: panel-tpo-td028ttec1: Add note for incorrect sync drive edge
  drm/omap: panel-sharp-ls037v7dw01: Add note for incorrect data drive
edge
  drm/omap: panel-lgphilips-lb035q02: Add note for incorrect data drive
edge and DE level

 .../gpu/drm/omapdrm/displays/connector-analog-tv.c |  47 ++---
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c   |  50 +++--
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c  |  49 +++--
 drivers/gpu/drm/omapdrm/displays/encoder-opa362.c  |  20 +-
 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c  |  31 ++-
 .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c   |  20 +-
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c   |  30 ++-
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c|  25 ++-
 .../omapdrm/displays/panel-lgphilips-lb035q02.c|  59 +++---
 .../drm/omapdrm/displays/panel-nec-nl8048hl11.c|  52 +++--
 .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c |  58 +++---
 .../drm/omapdrm/displays/panel-sony-acx565akm.c|  53 +++--
 .../drm/omapdrm/displays/panel-tpo-td028ttec1.c|  57 +++---
 .../drm/omapdrm/displays/panel-tpo-td043mtea1.c|  54 ++---
 drivers/gpu/drm/omapdrm/dss/dispc.c| 222 +
 drivers/gpu/drm/omapdrm/dss/display.c  |  78 +---
 drivers/gpu/drm/omapdrm/dss/dpi.c  |  40 ++--
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 156 ---
 drivers/gpu/drm/omapdrm/dss/dss.h  |   5 +-
 drivers/gpu/drm/omapdrm/dss/hdmi.h |   8 +-
 drivers/gpu/drm/omapdrm/dss/hdmi4.c|  31 +--
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.c   |   8 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c|  31 +--
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c   |  85 
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c  |  73 ---
 drivers/gpu/drm/omapdrm/dss/omapdss.h  |  98 +++--
 drivers/gpu/drm/omapdrm/dss/output.c   |   5 +-
 drivers/gpu/drm/omapdrm/dss/rfbi.c |  49 +++--
 drivers/gpu/drm/omapdrm/dss/sdi.c  |  33 ++-
 drivers/gpu/drm/omapdrm/dss/venc.c |  97 +
 drivers/gpu/drm/omapdrm/omap_connector.c   |  87 +---
 drivers/gpu/drm/omapdrm/omap_crtc.c|  17 +-
 drivers/gpu/drm/omapdrm/omap_drv.h |   7 +-
 drivers/gpu/drm/omapdrm/omap_encoder.c |  10 +-
 34 files changed, 759 insertions(+), 986 deletions(-)

--
2.10.0



Re: [PATCH net-next v2 3/3] net: ethernet: mediatek: add the dts property to set if TRGMII supported on GMAC0

2016-09-22 Thread Sergei Shtylyov

Hello.

On 9/22/2016 5:33 AM, sean.w...@mediatek.com wrote:


From: Sean Wang 

Add the dts property for the capability if TRGMII supported on GAMC0

Signed-off-by: Sean Wang 
---
 Documentation/devicetree/bindings/net/mediatek-net.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 6103e55..7111278 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -31,7 +31,10 @@ Optional properties:
 Required properties:
 - compatible: Should be "mediatek,eth-mac"
 - reg: The number of the MAC
-- phy-handle: see ethernet.txt file in the same directory.
+- phy-handle: see ethernet.txt file in the same directory and
+   the phy-mode "trgmii" required being provided when reg


  Since you've modified the generic parser of the "phy-mode" to add your 
"trgmii", you also need to update ethernet.txt...



+   is equal to 0 and the MAC uses fixed-link to connect
+   with inernal switch such as MT7530.


  Internal.

[...]

MBR, Sergei



Re: [PATCH] drm/i2c: tda998x: don't register the connector

2016-09-22 Thread Daniel Vetter
On Thu, Sep 22, 2016 at 1:22 PM, Sean Paul  wrote:
> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
>  wrote:
>> On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
>>> Actually, could you please hold off picking this up? We need to make
>>> changes in mali-dp and hdlcd or this will mess up their registration.
>>> I will send those patches later today, but better if this all goes in
>>> together (whenever that ends up being).
>>
>> Sorry, but I'm annoyed with this - the impression being given was that
>> I was holding up this patch by not testing it on Armada, and I brought
>> up the issue about registration at the beginning of this.
>>
>> Now we're _just_ finding out that there are drivers where removing the
>> connector registration in tda998x causes them to break?  It's a bit
>> late to be checking your own drivers when you've been chasing me...
>>
>> Sorry, but it sounds like we're not ready to make this change - and as
>> it's the very last day that changes will appear in linux-next prior to
>> the merge window (assuming Linus releases 4.8 on Sunday), I'd suggest
>> holding off until after the merge window is over, so we can get some
>> testing with these other two drivers with this change in place.
>>
>
> sigh. I just pushed my queue to drm-misc, which included this patch.
> Sounds like I should revert?

I thought I looked at the entire situation and since we register
(since recently) all connectors in drm_dev_register() there shouldn't
be an issue for any other driver. Imo no need to revert anything here
- until someone complains with a bug report and proves me wrong ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[PATCH 10/17] Documentation/bad_memory.txt: convert it to ReST markup

2016-09-22 Thread Mauro Carvalho Chehab
- promote the section level of the document name;
- add/remove spaces/new lines where needed to format the output;
- use quote blocks.
- add it to the user book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/bad_memory.txt  | 26 --
 Documentation/user/bad_memory.rst |  1 +
 Documentation/user/index.rst  |  1 +
 3 files changed, 18 insertions(+), 10 deletions(-)
 create mode 12 Documentation/user/bad_memory.rst

diff --git a/Documentation/bad_memory.txt b/Documentation/bad_memory.txt
index df8416213202..5cac93e27a97 100644
--- a/Documentation/bad_memory.txt
+++ b/Documentation/bad_memory.txt
@@ -1,9 +1,10 @@
+How to deal with bad memory e.g. reported by memtest86+ ?
+=
+
 March 2008
 Jan-Simon Moeller, dl...@gmx.de
 
 
-How to deal with bad memory e.g. reported by memtest86+ ?
-#
 
 There are three possibilities I know of:
 
@@ -19,6 +20,7 @@ This Howto is about number 3) .
 
 BadRAM
 ##
+
 BadRAM is the actively developed and available as kernel-patch
 here:  http://rick.vanrein.org/linux/badram/
 
@@ -31,15 +33,19 @@ memmap is already in the kernel and usable as 
kernel-parameter at
 boot-time.  Its syntax is slightly strange and you may need to
 calculate the values by yourself!
 
-Syntax to exclude a memory area (see kernel-parameters.txt for details):
-memmap=$
+Syntax to exclude a memory area (see kernel-parameters.txt for details)::
+
+   memmap=$
 
 Example: memtest86+ reported here errors at address 0x18691458, 0x18698424 and
- some others. All had 0x1869 in common, so I chose a pattern of
- 0x1869,0x.
+some others. All had 0x1869 in common, so I chose a pattern of
+0x1869,0x.
 
-With the numbers of the example above:
-memmap=64K$0x1869
- or
-memmap=0x1$0x1869
+With the numbers of the example above::
+
+   memmap=64K$0x1869
+
+or::
+
+   memmap=0x1$0x1869
 
diff --git a/Documentation/user/bad_memory.rst 
b/Documentation/user/bad_memory.rst
new file mode 12
index ..c5ffc33348f2
--- /dev/null
+++ b/Documentation/user/bad_memory.rst
@@ -0,0 +1 @@
+../bad_memory.txt
\ No newline at end of file
diff --git a/Documentation/user/index.rst b/Documentation/user/index.rst
index 280e62f21efa..d4886e366b5a 100644
--- a/Documentation/user/index.rst
+++ b/Documentation/user/index.rst
@@ -11,3 +11,4 @@ Contents:
REPORTING-BUGS
SecurityBugs
kernel-parameters
+   bad_memory
-- 
2.7.4




[PATCH 15/17] Documentation/BUG-HUNTING: convert to ReST markup

2016-09-22 Thread Mauro Carvalho Chehab
- Add a document title and remove its own index;
- use monotonic fonts for paths;
- use quote blocks where needed;
- adjust/use spaces to properly format paragraphs;
- add it to the user book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/BUG-HUNTING  | 162 +++--
 Documentation/user/BUG-HUNTING.rst |   1 +
 Documentation/user/index.rst   |   1 +
 3 files changed, 84 insertions(+), 80 deletions(-)
 create mode 12 Documentation/user/BUG-HUNTING.rst

diff --git a/Documentation/BUG-HUNTING b/Documentation/BUG-HUNTING
index 65022a87bf17..a8ef794aadae 100644
--- a/Documentation/BUG-HUNTING
+++ b/Documentation/BUG-HUNTING
@@ -1,18 +1,8 @@
-Table of contents
-=
+Bug hunting

 
 Last updated: 20 December 2005
 
-Contents
-
-
-- Introduction
-- Devices not appearing
-- Finding patch that caused a bug
--- Finding using git-bisect
--- Finding it the old way
-- Fixing the bug
-
 Introduction
 
 
@@ -24,7 +14,8 @@ Finding bugs is not always easy. Have a go though. If you 
can't find it don't
 give up. Report as much as you have found to the relevant maintainer. See
 MAINTAINERS for who that is for the subsystem you have worked on.
 
-Before you submit a bug report read REPORTING-BUGS.
+Before you submit a bug report read
+:ref:`Documentation/REPORTING-BUGS `.
 
 Devices not appearing
 =
@@ -37,15 +28,16 @@ Finding patch that caused a bug
 
 
 
-Finding using git-bisect
-
+Finding using ``git-bisect``
+
 
-Using the provided tools with git makes finding bugs easy provided the bug is
-reproducible.
+Using the provided tools with ``git`` makes finding bugs easy provided the bug
+is reproducible.
 
 Steps to do it:
+
 - start using git for the kernel source
-- read the man page for git-bisect
+- read the man page for ``git-bisect``
 - have fun
 
 Finding it the old way
@@ -58,22 +50,22 @@ It's a brute force approach but it works pretty well.
 
 You need:
 
-. A reproducible bug - it has to happen predictably (sorry)
-. All the kernel tar files from a revision that worked to the
+- A reproducible bug - it has to happen predictably (sorry)
+- All the kernel tar files from a revision that worked to the
   revision that doesn't
 
 You will then do:
 
-. Rebuild a revision that you believe works, install, and verify that.
-. Do a binary search over the kernels to figure out which one
+- Rebuild a revision that you believe works, install, and verify that.
+- Do a binary search over the kernels to figure out which one
   introduced the bug.  I.e., suppose 1.3.28 didn't have the bug, but
   you know that 1.3.69 does.  Pick a kernel in the middle and build
   that, like 1.3.50.  Build & test; if it works, pick the mid point
   between .50 and .69, else the mid point between .28 and .50.
-. You'll narrow it down to the kernel that introduced the bug.  You
+- You'll narrow it down to the kernel that introduced the bug.  You
   can probably do better than this but it gets tricky.
 
-. Narrow it down to a subdirectory
+- Narrow it down to a subdirectory
 
   - Copy kernel that works into "test".  Let's say that 3.62 works,
 but 3.63 doesn't.  So you diff -r those two kernels and come
@@ -83,7 +75,7 @@ You will then do:
 Copy the non-working directory next to the working directory
 as "dir.63".
 One directory at time, try moving the working directory to
-"dir.62" and mv dir.63 dir"time, try
+"dir.62" and mv dir.63 dir"time, try::
 
 mv dir dir.62
 mv dir.63 dir
@@ -97,15 +89,15 @@ You will then do:
 found in my case that they were self explanatory - you may
 or may not want to give up when that happens.
 
-. Narrow it down to a file
+- Narrow it down to a file
 
   - You can apply the same technique to each file in the directory,
 hoping that the changes in that file are self contained.
 
-. Narrow it down to a routine
+- Narrow it down to a routine
 
   - You can take the old file and the new file and manually create
-a merged file that has
+a merged file that has::
 
 #ifdef VER62
 routine()
@@ -120,7 +112,7 @@ You will then do:
 #endif
 
 And then walk through that file, one routine at a time and
-prefix it with
+prefix it with::
 
 #define VER62
 /* both routines here */
@@ -153,94 +145,104 @@ To debug a kernel, use objdump and look for the hex 
offset from the crash
 output to find the valid line of code/assembler. 

[PATCH 0/2] NFS: Use complete() instead complete_all()

2016-09-22 Thread Daniel Wagner
From: Daniel Wagner 

Hi,

Using complete_all() is not wrong per se but it suggest that there
might be more than one waiter. For -rt I am reviewing all
complete_all() users and would like to leave only the real ones in the
tree. The main problem for -rt about complete_all() is that it can be
uses inside IRQ context and that can lead to unbounded amount work
inside the interrupt handler. That is a no no for -rt.

Besides trying to analys all the code paths to the wait_for_completion()
call and convince myself that there is only one waiter, I also run
a few tests:

 - some fio benchmarks
 - pynfs
  -cthon04

Non of them exposed any blocking threads etc. pynfs did showed some
failures but I am guessing that is just missing implementation:

pynfs/nfs4.1/testserver.py random:/home/nfs-test --force -v all
 
EID50st_exchange_id.testSSV   : FAILURE
   NFS4Error: OP_EXCHANGE_ID should return NFS4_OK,
   instead got NFS4ERR_ENCR_ALG_UNSUPP
LKPP1a   st_lookupp.testLink  : RUNNING
LKPP1a   st_lookupp.testLink  : FAILURE
   LOOKUPP with non-dir  should return
   NFS4ERR_SYMLINK, instead got NFS4ERR_NOENT
LKPP1b   st_lookupp.testBlock : RUNNING
LKPP1b   st_lookupp.testBlock : FAILURE
   LOOKUPP with non-dir  should return
   NFS4ERR_NOTDIR, instead got NFS4ERR_NOENT
LKPP1c   st_lookupp.testChar  : RUNNING
LKPP1c   st_lookupp.testChar  : FAILURE
   LOOKUPP with non-dir  should return
   NFS4ERR_NOTDIR, instead got NFS4ERR_NOENT
LKPP1d   st_lookupp.testLookupp   : RUNNING
LKPP1d   st_lookupp.testLookupp   : PASS
LKPP1f   st_lookupp.testFifo  : RUNNING
LKPP1f   st_lookupp.testFifo  : FAILURE
   LOOKUPP with non-dir  should return
   NFS4ERR_NOTDIR, instead got NFS4ERR_NOENT
LKPP1r   st_lookupp.testFile  : RUNNING
LKPP1r   st_lookupp.testFile  : FAILURE
   LOOKUPP with non-dir  should return
   NFS4ERR_NOTDIR, instead got NFS4ERR_NOENT
LKPP1s   st_lookupp.testSock  : RUNNING
LKPP1s   st_lookupp.testSock  : FAILURE
   LOOKUPP with non-dir  should return
   NFS4ERR_NOTDIR, instead got NFS4ERR_NOENT


PUTFH1a  st_putfh.testLink: RUNNING
PUTFH1a  st_putfh.testLink: FAILURE
   OP_LOOKUP should return NFS4_OK, instead got
   NFS4ERR_NOENT
PUTFH1b  st_putfh.testBlock   : RUNNING
PUTFH1b  st_putfh.testBlock   : FAILURE
   OP_LOOKUP should return NFS4_OK, instead got
   NFS4ERR_NOENT
PUTFH1c  st_putfh.testChar: RUNNING
PUTFH1c  st_putfh.testChar: FAILURE
   OP_LOOKUP should return NFS4_OK, instead got
   NFS4ERR_NOENT
PUTFH1d  st_putfh.testDir : RUNNING
PUTFH1d  st_putfh.testDir : FAILURE
   OP_LOOKUP should return NFS4_OK, instead got
   NFS4ERR_NOENT
PUTFH1f  st_putfh.testFifo: RUNNING
PUTFH1f  st_putfh.testFifo: FAILURE
   OP_LOOKUP should return NFS4_OK, instead got
   NFS4ERR_NOENT
PUTFH1r  st_putfh.testFile: RUNNING
PUTFH1r  st_putfh.testFile: FAILURE
   OP_LOOKUP should return NFS4_OK, instead got
   NFS4ERR_NOENT
PUTFH1s  st_putfh.testSocket  : RUNNING
PUTFH1s  st_putfh.testSocket  : FAILURE
   OP_LOOKUP should return NFS4_OK, instead got
   NFS4ERR_NOENT


RNM1bst_rename.testValidBlock : RUNNING
RNM1bst_rename.testValidBlock : FAILURE
   OP_CREATE should return NFS4_OK, instead got
   NFS4ERR_PERM
RNM1cst_rename.testValidChar  : RUNNING
RNM1cst_rename.testValidChar  : FAILURE
   OP_CREATE should return NFS4_OK, instead got
   NFS4ERR_PERM

RNM2ast_rename.testSfhLink: RUNNING
RNM2ast_rename.testSfhLink: FAILURE
   OP_LOOKUP should return NFS4_OK, instead got
 

[PATCH 2/2] NFS: cache_lib: use complete() instead of complete_all()

2016-09-22 Thread Daniel Wagner
From: Daniel Wagner 

There is only one waiter for the completion, therefore there
is no need to use complete_all(). Let's make that clear by
using complete() instead of complete_all().

The generic caching code from sunrpc is calling revisit() only once.

The usage pattern of the completion is:

waiter context  waker context

do_cache_lookup_wait()
  nfs_cache_defer_req_alloc()
init_completion()
  do_cache_lookup()
  nfs_cache_wait_for_upcall()
wait_for_completion_timeout()

nfs_dns_cache_revisit()
  complete()

  nfs_cache_defer_req_put()

Signed-off-by: Daniel Wagner 
---
 fs/nfs/cache_lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/cache_lib.c b/fs/nfs/cache_lib.c
index 5f7b053..6de1570 100644
--- a/fs/nfs/cache_lib.c
+++ b/fs/nfs/cache_lib.c
@@ -76,7 +76,7 @@ static void nfs_dns_cache_revisit(struct cache_deferred_req 
*d, int toomany)
 
dreq = container_of(d, struct nfs_cache_defer_req, deferred_req);
 
-   complete_all(>completion);
+   complete(>completion);
nfs_cache_defer_req_put(dreq);
 }
 
-- 
2.7.4


[PATCH v3] devicetree: bindings: uart: Add new compatible string for ZynqMP

2016-09-22 Thread Nava kishore Manne
From: Nava kishore Manne 

This patch Adds the new compatiable string for ZynqMP.

Signed-off-by: Nava kishore Manne 
---
Changes for v3:
-Added changeLog comment.
Changes for v2:
-None

 Documentation/devicetree/bindings/serial/cdns,uart.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.txt 
b/Documentation/devicetree/bindings/serial/cdns,uart.txt
index a3eb154..4fe7aae 100644
--- a/Documentation/devicetree/bindings/serial/cdns,uart.txt
+++ b/Documentation/devicetree/bindings/serial/cdns,uart.txt
@@ -1,7 +1,8 @@
 Binding for Cadence UART Controller
 
 Required properties:
-- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps"
+- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps" for Zynq and
+   "cdns,uart-r1p12" for Zynq Ultrascale+ MPSoC uart controller.
 - reg: Should contain UART controller registers location and length.
 - interrupts: Should contain UART controller interrupts.
 - clocks: Must contain phandles to the UART clocks
-- 
2.1.2



[PATCH 1/2] NFS: direct: use complete() instead of complete_all()

2016-09-22 Thread Daniel Wagner
From: Daniel Wagner 

There is only one waiter for the completion, therefore there
is no need to use complete_all(). Let's make that clear by
using complete() instead of complete_all().

nfs_file_direct_write() or nfs_file_direct_read() allocated a request
object via nfs_direct_req_alloc(), which initializes the
completion. The request object then is freed later in the exit path.
Between the initialization and the release either
nfs_direct_write_schedule_iovec() resp
nfs_direct_read_schedule_iovec() are called which will asynchronously
process the request. The calling function waits via nfs_direct_wait()
till the async work has been done. Thus there is only one waiter on
the completion.

nfs_direct_pgio_init() and nfs_direct_read_completion() are passed via
function pointers to nfs pageio. The first function does a ref
counting (get_dreq() and put_dreq()) which ensures that
nfs_direct_read_completion() and nfs_direct_read_schedule_iovec() only
call the completion path once.

The usage pattern of the completion is:

waiter context  waker context

nfs_file_direct_write()
  dreq = nfs_direct_req_alloc()
init_completion()
  nfs_direct_write_schedule_iovec()
  nfs_direct_wait()
wait_for_completion_killable()

nfs_direct_write_schedule_work()
  nfs_direct_complete()
complete()

nfs_file_direct_read()
  dreq = nfs_direct_req_all()
init_completion()
  nfs_direct_read_schedule_iovec()
  nfs_direct_wait()
wait_for_completion_killable()
nfs_direct_read_schedule_iovec()
  nfs_direct_complete()
complete()

nfs_direct_read_completion()
  nfs_direct_complete()
complete()

Signed-off-by: Daniel Wagner 
---
 fs/nfs/direct.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index 72b7d13..bd81bcf 100644
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -387,7 +387,7 @@ static void nfs_direct_complete(struct nfs_direct_req *dreq)
dreq->iocb->ki_complete(dreq->iocb, res, 0);
}
 
-   complete_all(>completion);
+   complete(>completion);
 
nfs_direct_req_release(dreq);
 }
-- 
2.7.4


Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

2016-09-22 Thread Prarit Bhargava


On 09/21/2016 10:01 AM, Borislav Petkov wrote:
> On Wed, Sep 21, 2016 at 09:32:47AM -0400, Prarit Bhargava wrote:
>> This is not the right thing to do [1].  The topology directory should exist 
>> as
>> long as the thread is present in the system.  The thread (and its core) are
>> still physically there, it's just that the thread is not available to the
>> scheduler.  The topology of the thread hasn't changed due to it being soft
>> offlined this way.
> 
> So far so good.
> 
>> turbostat was modified to deal with the missing topology directory, and in 
>> tree
>> utility cpupower prints out significantly less information when a thread is
>> offline.
> 
> Why does it do that? Why does an offlined core change that info?
> 
> Concrete details please.
> 
>> ISTR a powertop bug due to hotplug too.  This makes these monitoring
>> utilities a problem for users who want only one thread per core.
> 
> one thread per core? What does that mean?

System boots with (usually) with 2 threads/core.  Some performance users want
one thread per core.  Since there is no "noht" option anymore, users use /sys to
disable a thread on each core.

> 
>> This now means that
>>
>> echo 0 > /sys/devices/system/cpu/cpu29/online
>>
>> will result in the thread's topology directory staying around until the 
>> struct
>> device associated with it is destroyed upon a physical socket hotplug event.
> 
> So your 2/2 says that on an offlined CPU, you have
> 
> /sys/devices/system/cpu/cpu10/topology/core_id:3
> /sys/devices/system/cpu/cpu10/topology/core_siblings:
> /sys/devices/system/cpu/cpu10/topology/core_siblings_list:
> /sys/devices/system/cpu/cpu10/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu10/topology/thread_siblings:
> /sys/devices/system/cpu/cpu10/topology/thread_siblings_list:
> 
> and this information is bollocks. core_siblings is 0, thread_siblings
> is 0. You can just as well not have them there at all.

core_siblings and thread_siblings are the online thread's sibling cores and
threads that are available to the scheduler, and should be 0 when the thread is
offline.  That comes directly from reading the code.

> 
> So is this whole jumping around just so that you can have a
> /sys/devices/system/cpu/cpu10/topology directory and so that tools don't
> get confused by it missing?

Yes.

> 
> So again, what exactly are those tools accessing and how does the
> offlined cores puzzle them?
> 
> A concrete example please:
> 

See commit 20102ac5bee3 ("cpupower: cpupower monitor reports uninitialized
values for offline cpus").  That patch papers over the bug of not being able to
find core_id and physical_package_id for an offline thread.

P.


[tip:sched/core] sched/core: Do not use smp_processor_id() with preempt enabled in smpboot_thread_fn()

2016-09-22 Thread tip-bot for Con Kolivas
Commit-ID:  4fa5cd5245b627db88c9ca08ae442373b02596b4
Gitweb: http://git.kernel.org/tip/4fa5cd5245b627db88c9ca08ae442373b02596b4
Author: Con Kolivas 
AuthorDate: Tue, 13 Sep 2016 16:27:05 +1000
Committer:  Ingo Molnar 
CommitDate: Thu, 22 Sep 2016 12:28:00 +0200

sched/core: Do not use smp_processor_id() with preempt enabled in 
smpboot_thread_fn()

We should not be using smp_processor_id() with preempt enabled.

Bug identified and fix provided by Alfred Chen.

Reported-by: Alfred Chen 
Signed-off-by: Con Kolivas 
Cc: Alfred Chen 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/2042051.3vvUWIM0vs@hex
Signed-off-by: Ingo Molnar 
---
 kernel/smpboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index 13bc43d..fc0d8270 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -122,12 +122,12 @@ static int smpboot_thread_fn(void *data)
 
if (kthread_should_park()) {
__set_current_state(TASK_RUNNING);
-   preempt_enable();
if (ht->park && td->status == HP_THREAD_ACTIVE) {
BUG_ON(td->cpu != smp_processor_id());
ht->park(td->cpu);
td->status = HP_THREAD_PARKED;
}
+   preempt_enable();
kthread_parkme();
/* We might have been woken for stop */
continue;


ext4, f2fs: fscrypt_has_permitted_context() check in file open

2016-09-22 Thread Richard Weinberger
Hi!

Both ext4 and f2fs check in the file open code the context of the parent 
directory too:

ext4:
if (ext4_encrypted_inode(d_inode(dir)) &&
!fscrypt_has_permitted_context(d_inode(dir), inode)) {
ext4_warning(inode->i_sb,
 "Inconsistent encryption contexts: %lu/%lu",
 (unsigned long) d_inode(dir)->i_ino,
 (unsigned long) inode->i_ino);
dput(dir);
return -EPERM;
}

f2fs:
if (f2fs_encrypted_inode(d_inode(dir)) &&
!fscrypt_has_permitted_context(d_inode(dir), inode)) {
dput(dir);
return -EPERM;
}

Why do we need this check? AFAIK this situation can never happen unless due to
a bug in the filesystem code.

Thanks,
//richard


Re: [PATCH 0/2] BQL support and fix for a regression issue

2016-09-22 Thread David Miller
From: sunil.kovv...@gmail.com
Date: Thu, 22 Sep 2016 14:35:19 +0530

> From: Sunil Goutham 
> 
> These patches add byte queue limit support and also fixes a regression
> issue introduced by commit
> 'net: thunderx: Use netdev's name for naming VF's interrupts'

The correct way to refer to commits when you fix a bug is
to use the "Fixes: " tag right before the signoffs and ACKs.

The correct form is:

Fixes: $SHA1_ID ("Commit header line.")

You'll see this in many other netdev commits.



Re: [PATCH 7/7 v3] sched: fix wrong utilization accounting when switching to fair class

2016-09-22 Thread Peter Zijlstra
On Tue, Sep 20, 2016 at 03:06:04PM +0200, Vincent Guittot wrote:
> > Also, even it things magically worked out, its still very icky to mix
> > the normalized vruntime into things.
> 
> I agree

In any case, I pushed out a bunch of patches to:

  git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/tmp

they appear to be able to build a kernel, but that's not much testing.



Re: [PATCH resend 2] xen-netback: switch to threaded irq for control ring

2016-09-22 Thread David Miller
From: Juergen Gross 
Date: Thu, 22 Sep 2016 11:06:25 +0200

> Instead of open coding it use the threaded irq mechanism in
> xen-netback.
> 
> Signed-off-by: Juergen Gross 

Applied to net-next, thanks.


Re: [patch v1] drivers/platform/x86: introduce support for Mellanox hotplug driver

2016-09-22 Thread Greg KH
On Thu, Sep 22, 2016 at 01:14:27PM +, vad...@mellanox.com wrote:
> From: Vadim Pasternak 
> 
> Enable system support for the Mellanox Technologies hotplug platform
> driver, which provides support for the next Mellanox basic systems:
> "msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410",
> "msb7800", "msn2740", "msn2100" and also various number of derivative
> systems from the above basic types.
> This driver handles hot-plug events for the power suppliers, power
> cables and fans for the above systems.
> 
> The Kconfig currently controlling compilation of this code is:
> driver/platform/x86:config MLX_CPLD_PLATFORM
>tristate "Mellanox platform hotplug driver support"
> 
> Signed-off-by: Vadim Pasternak 
> ---
>  MAINTAINERS   |   7 +
>  drivers/platform/x86/Kconfig  |  10 +
>  drivers/platform/x86/Makefile |   1 +
>  drivers/platform/x86/mlxcpld-hotplug.c| 543 
> ++
>  include/linux/platform_data/mlxcpld-hotplug.h |  90 +

Why do you need a platform_data .h file for a stand-alone driver?

thanks,

greg k-h


Re: linux-next: build failure after merge of the kbuild tree

2016-09-22 Thread Michal Marek
On 2016-09-15 08:08, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the dax-misc tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
> 
> arch/powerpc/kernel/built-in.o: In function `__ksymtab_clear_pages':
> (___ksymtab+clear_pages+0x0): undefined reference to `clear_pages'
> 
> Caused by commit
> 
>   9445aa1a3062 ("ppc: move exports to definitions")
> 
> I applied the following fix patch:
> 
> From: Stephen Rothwell 
> Date: Thu, 15 Sep 2016 16:04:12 +1000
> Subject: [PATCH] ppc: there is no clear_pages to export
> 
> Fixes: 9445aa1a3062 ("ppc: move exports to definitions")
> Signed-off-by: Stephen Rothwell 

Applied to kbuild.git#kbuild now.

Thanks,
Michal



Re: [PATCH 2/4] mm, compaction: more reliably increase direct compaction priority

2016-09-22 Thread Vlastimil Babka
On 09/21/2016 07:13 PM, Michal Hocko wrote:
> On Tue 06-09-16 15:52:56, Vlastimil Babka wrote:
> [...]
>> @@ -3204,6 +3199,15 @@ should_compact_retry(struct alloc_context *ac, int 
>> order, int alloc_flags,
>>  if (compaction_retries <= max_retries)
>>  return true;
>>  
>> +/*
>> + * Make sure there is at least one attempt at the highest priority
>> + * if we exhausted all retries at the lower priorities
>> + */
>> +check_priority:
>> +if (*compact_priority > MIN_COMPACT_PRIORITY) {
>> +(*compact_priority)--;
>> +return true;
> 
> Don't we want to reset compaction_retries here? Otherwise we can consume
> all retries on the lower priorities.

Good point, patch-fix below.

> Other than that it looks good to me. With that you can add
> Acked-by: Michal Hocko 

Thanks!
 
>> +}
>>  return false;
>>  }
>>  #else
> 

8<
>From 465e1bd61b7a6d6901a44f09b1a76514dbc220fa Mon Sep 17 00:00:00 2001
From: Vlastimil Babka 
Date: Thu, 22 Sep 2016 13:54:32 +0200
Subject: [PATCH] mm, compaction: more reliably increase direct compaction
 priority-fix

When increasing the compaction priority, also reset retries. Otherwise we can
consume all retries on the lower priorities.

Suggested-by: Michal Hocko 
Signed-off-by: Vlastimil Babka 
---
 mm/page_alloc.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f8bed910e3cf..82fdb690ac62 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3162,7 +3162,7 @@ static inline bool
 should_compact_retry(struct alloc_context *ac, int order, int alloc_flags,
 enum compact_result compact_result,
 enum compact_priority *compact_priority,
-int compaction_retries)
+int *compaction_retries)
 {
int max_retries = MAX_COMPACT_RETRIES;
 
@@ -3196,16 +3196,17 @@ should_compact_retry(struct alloc_context *ac, int 
order, int alloc_flags,
 */
if (order > PAGE_ALLOC_COSTLY_ORDER)
max_retries /= 4;
-   if (compaction_retries <= max_retries)
+   if (*compaction_retries <= max_retries)
return true;
 
/*
-* Make sure there is at least one attempt at the highest priority
-* if we exhausted all retries at the lower priorities
+* Make sure there are attempts at the highest priority if we exhausted
+* all retries or failed at the lower priorities.
 */
 check_priority:
if (*compact_priority > MIN_COMPACT_PRIORITY) {
(*compact_priority)--;
+   *compaction_retries = 0;
return true;
}
return false;
@@ -3224,7 +3225,7 @@ static inline bool
 should_compact_retry(struct alloc_context *ac, unsigned int order, int 
alloc_flags,
 enum compact_result compact_result,
 enum compact_priority *compact_priority,
-int compaction_retries)
+int *compaction_retries)
 {
struct zone *zone;
struct zoneref *z;
@@ -3663,7 +3664,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
if (did_some_progress > 0 &&
should_compact_retry(ac, order, alloc_flags,
compact_result, _priority,
-   compaction_retries))
+   _retries))
goto retry;
 
/* Reclaim has failed us, start killing things */
-- 
2.10.0




Re: [PATCH] drm/i2c: tda998x: don't register the connector

2016-09-22 Thread Russell King - ARM Linux
On Thu, Sep 22, 2016 at 05:32:35AM -0700, Sean Paul wrote:
> On Thu, Sep 22, 2016 at 5:09 AM, Russell King - ARM Linux
>  wrote:
> > On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote:
> >> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
> >>  wrote:
> >> > On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
> >> >> Actually, could you please hold off picking this up? We need to make
> >> >> changes in mali-dp and hdlcd or this will mess up their registration.
> >> >> I will send those patches later today, but better if this all goes in
> >> >> together (whenever that ends up being).
> >> >
> >> > Sorry, but I'm annoyed with this - the impression being given was that
> >> > I was holding up this patch by not testing it on Armada, and I brought
> >> > up the issue about registration at the beginning of this.
> >> >
> >> > Now we're _just_ finding out that there are drivers where removing the
> >> > connector registration in tda998x causes them to break?  It's a bit
> >> > late to be checking your own drivers when you've been chasing me...
> >> >
> >> > Sorry, but it sounds like we're not ready to make this change - and as
> >> > it's the very last day that changes will appear in linux-next prior to
> >> > the merge window (assuming Linus releases 4.8 on Sunday), I'd suggest
> >> > holding off until after the merge window is over, so we can get some
> >> > testing with these other two drivers with this change in place.
> >> >
> >>
> >> sigh. I just pushed my queue to drm-misc, which included this patch.
> >> Sounds like I should revert?
> >
> > Why did you do push it _without_ an ack from the maintainer of the
> > driver when the comments on the list were clearly indicating that it
> > was waiting for testing and such an ack?
> >
> 
> Daniel Acked it on the list on 7/25, and you acked it yesterday asking
> it to be merged to -misc. What am I missing?

Sorry, I thought you were some random person maintaining some random
tree who'd submitted a pull request to be merged into drm-misc.  If
you are in fact the drm-misc maintainer, please add yourself to the
MAINTAINERS file so that everyone knows who you are.  Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


Re: [PATCH] crypto: sun4i-ss: mark sun4i_hash() static

2016-09-22 Thread Herbert Xu
On Sun, Sep 18, 2016 at 08:52:44PM +0800, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/crypto/sunxi-ss/sun4i-ss-hash.c:168:5: warning: no previous prototype 
> for 'sun4i_hash' [-Wmissing-prototypes]
> 
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks it 'static'.
> 
> Signed-off-by: Baoyou Xie 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


[PATCH v2 23/23] drm/omap: panel-lgphilips-lb035q02: Add note for incorrect data drive edge and DE level

2016-09-22 Thread Peter Ujfalusi
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.
The DE is active low according to the documentation.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c 
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index b36fa0a57b61..43d21edb51f5 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -36,6 +36,11 @@ static struct videomode lb035q02_vm = {
.flags  = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
  DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_SYNC_NEGEDGE |
  DISPLAY_FLAGS_PIXDATA_POSEDGE,
+   /*
+* Note: According to the panel documentation:
+* DE is active LOW
+* DATA needs to be driven on the FALLING edge
+*/
 };
 
 struct panel_drv_data {
-- 
2.10.0



[PATCH v2 21/23] drm/omap: panel-tpo-td028ttec1: Add note for incorrect sync drive edge

2016-09-22 Thread Peter Ujfalusi
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c 
b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
index c003f4dd2a18..f313dbfcbacb 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
@@ -56,6 +56,10 @@ static struct videomode td028ttec1_panel_vm = {
.flags  = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
  DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_SYNC_POSEDGE |
  DISPLAY_FLAGS_PIXDATA_NEGEDGE,
+   /*
+* Note: According to the panel documentation:
+* SYNC needs to be driven on the FALLING edge
+*/
 };
 
 #define JBT_COMMAND0x000
-- 
2.10.0



[PATCH v2 17/23] drm/omap: Change the types of struct omap_video_timings members

2016-09-22 Thread Peter Ujfalusi
omap_video_timings struct have the same members as struct videomode, but
their types are different. As first step change the types of the
omap_video_timings struct members to match their counterpart in
struct videomode to catch any type cast related issues.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c |  2 +-
 drivers/gpu/drm/omapdrm/dss/dispc.c |  5 +++--
 drivers/gpu/drm/omapdrm/dss/dpi.c   |  2 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h   | 18 +-
 drivers/gpu/drm/omapdrm/dss/sdi.c   |  2 +-
 5 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index 1493671c6e2f..94e897d90172 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -1024,7 +1024,7 @@ static int dsicm_memory_read(struct omap_dss_device 
*dssdev,
goto err1;
}
 
-   size = min(w * h * 3,
+   size = min((u32)w * h * 3,
dssdev->panel.timings.hactive *
dssdev->panel.timings.vactive * 3);
 
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 4a4cd743fe2f..498838e74d08 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2870,7 +2870,8 @@ int dispc_wb_setup(const struct omap_dss_writeback_info 
*wi,
int wbdelay;
 
wbdelay = min(mgr_timings->vfront_porch +
- mgr_timings->vsync_len + 
mgr_timings->vback_porch, 255);
+ mgr_timings->vsync_len + mgr_timings->vback_porch,
+ (u32)255);
 
/* WBDELAYCOUNT */
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane), wbdelay, 7, 0);
@@ -3242,7 +3243,7 @@ void dispc_mgr_set_timings(enum omap_channel channel,
ht = timings->pixelclock / xtot;
vt = timings->pixelclock / xtot / ytot;
 
-   DSSDBG("pck %u\n", timings->pixelclock);
+   DSSDBG("pck %lu\n", timings->pixelclock);
DSSDBG("hsync_len %d hfp %d hbp %d vsw %d vfp %d vbp %d\n",
t.hsync_len, t.hfront_porch, t.hback_porch,
t.vsync_len, t.vfront_porch, t.vback_porch);
diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index d653f492cbfd..8fb40efa65af 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -351,7 +351,7 @@ static int dpi_set_mode(struct dpi_data *dpi)
pck = fck / lck_div / pck_div;
 
if (pck != t->pixelclock) {
-   DSSWARN("Could not find exact pixel clock. Requested %d Hz, got 
%lu Hz\n",
+   DSSWARN("Could not find exact pixel clock. Requested %lu Hz, 
got %lu Hz\n",
t->pixelclock, pck);
 
t->pixelclock = pck;
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 84d34242d5a4..bd38da3af01f 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -301,23 +301,23 @@ struct omap_dss_dsi_config {
 
 struct omap_video_timings {
/* Unit: pixels */
-   u16 hactive;
+   u32 hactive;
/* Unit: pixels */
-   u16 vactive;
+   u32 vactive;
/* Unit: Hz */
-   u32 pixelclock;
+   unsigned long pixelclock;
/* Unit: pixel clocks */
-   u16 hsync_len;  /* Horizontal synchronization pulse width */
+   u32 hsync_len;  /* Horizontal synchronization pulse width */
/* Unit: pixel clocks */
-   u16 hfront_porch;   /* Horizontal front porch */
+   u32 hfront_porch;   /* Horizontal front porch */
/* Unit: pixel clocks */
-   u16 hback_porch;/* Horizontal back porch */
+   u32 hback_porch;/* Horizontal back porch */
/* Unit: line clocks */
-   u16 vsync_len;  /* Vertical synchronization pulse width */
+   u32 vsync_len;  /* Vertical synchronization pulse width */
/* Unit: line clocks */
-   u16 vfront_porch;   /* Vertical front porch */
+   u32 vfront_porch;   /* Vertical front porch */
/* Unit: line clocks */
-   u16 vback_porch;/* Vertical back porch */
+   u32 vback_porch;/* Vertical back porch */
 
enum display_flags flags;
 };
diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c 
b/drivers/gpu/drm/omapdrm/dss/sdi.c
index 3b076329a3ac..c8658f97ab7d 100644
--- a/drivers/gpu/drm/omapdrm/dss/sdi.c
+++ b/drivers/gpu/drm/omapdrm/dss/sdi.c
@@ -162,7 +162,7 @@ static int sdi_display_enable(struct omap_dss_device 
*dssdev)
pck = fck / dispc_cinfo.lck_div / dispc_cinfo.pck_div;
 
if (pck != t->pixelclock) {
- 

[PATCH v2 16/23] drm/omap: omap_display_timings: Use display_flags for sync edge

2016-09-22 Thread Peter Ujfalusi
In preparation to move the stack to use the generic videmode struct for
display timing information use display_flags for sync edge.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c   |  5 ++---
 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c  |  5 +++--
 .../drm/omapdrm/displays/panel-lgphilips-lb035q02.c|  5 ++---
 .../gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c|  5 ++---
 .../gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c |  5 ++---
 .../gpu/drm/omapdrm/displays/panel-sony-acx565akm.c|  5 ++---
 .../gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c|  5 ++---
 .../gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c|  5 ++---
 drivers/gpu/drm/omapdrm/dss/dispc.c| 18 ++
 drivers/gpu/drm/omapdrm/dss/display.c  |  4 
 drivers/gpu/drm/omapdrm/dss/dsi.c  |  3 ++-
 drivers/gpu/drm/omapdrm/dss/omapdss.h  |  3 ---
 drivers/gpu/drm/omapdrm/dss/rfbi.c |  3 ++-
 drivers/gpu/drm/omapdrm/dss/sdi.c  |  3 +--
 drivers/gpu/drm/omapdrm/dss/venc.c | 10 --
 drivers/gpu/drm/omapdrm/omap_connector.c   |  5 +++--
 16 files changed, 35 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index 6f130862db8a..53967a4a96a7 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -33,10 +33,9 @@ static const struct omap_video_timings dvic_default_timings 
= {
.vsync_len  = 4,
.vback_porch= 7,
 
-   .sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
-
.flags  = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_HIGH |
- DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
+ DISPLAY_FLAGS_SYNC_NEGEDGE | DISPLAY_FLAGS_DE_HIGH |
+ DISPLAY_FLAGS_PIXDATA_POSEDGE,
 };
 
 struct panel_drv_data {
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
index eec079e017f0..69b4feab964c 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
@@ -115,8 +115,9 @@ static void tfp410_disable(struct omap_dss_device *dssdev)
 
 static void tfp410_fix_timings(struct omap_video_timings *timings)
 {
-   timings->sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
-   timings->flags |= DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE;
+   timings->flags |= DISPLAY_FLAGS_DE_HIGH |
+ DISPLAY_FLAGS_PIXDATA_POSEDGE |
+ DISPLAY_FLAGS_SYNC_POSEDGE;
 }
 
 static void tfp410_set_timings(struct omap_dss_device *dssdev,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c 
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 33cdc107ed21..4328d6781228 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -33,10 +33,9 @@ static struct omap_video_timings lb035q02_timings = {
.vfront_porch   = 4,
.vback_porch= 18,
 
-   .sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
-
.flags  = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
- DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
+ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_SYNC_NEGEDGE |
+ DISPLAY_FLAGS_PIXDATA_POSEDGE,
 };
 
 struct panel_drv_data {
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c 
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index 475420239b40..0c30e505f56e 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -77,10 +77,9 @@ static const struct omap_video_timings 
nec_8048_panel_timings = {
.vsync_len  = 1,
.vback_porch= 4,
 
-   .sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
-
.flags  = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
- DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
+ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_SYNC_POSEDGE |
+ DISPLAY_FLAGS_PIXDATA_POSEDGE,
 };
 
 #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c 
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index fb7e032209bd..d41ba3152859 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -49,10 +49,9 @@ static const struct omap_video_timings sharp_ls_timings = 

[PATCH v2 18/23] drm/omap: Replace struct omap_video_timings with videomode

2016-09-22 Thread Peter Ujfalusi
omap_video_timings can be replaced with the generic videomode in omapdrm
and the omap_video_timings can be removed.

This patch will replace the omap_video_timings with videomode.
With the change we no longer need the functions to convert to/from
videomode and drm_display_mode to omap_video_timings, these can be removed
as well.

Signed-off-by: Peter Ujfalusi 
---
 .../gpu/drm/omapdrm/displays/connector-analog-tv.c | 10 +--
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c   | 10 +--
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c  | 10 +--
 drivers/gpu/drm/omapdrm/displays/encoder-opa362.c  |  8 +--
 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c  | 10 +--
 .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c   |  8 +--
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c   | 16 ++---
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c|  2 +-
 .../omapdrm/displays/panel-lgphilips-lb035q02.c| 10 +--
 .../drm/omapdrm/displays/panel-nec-nl8048hl11.c| 10 +--
 .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 10 +--
 .../drm/omapdrm/displays/panel-sony-acx565akm.c| 10 +--
 .../drm/omapdrm/displays/panel-tpo-td028ttec1.c| 10 +--
 .../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 10 +--
 drivers/gpu/drm/omapdrm/dss/dispc.c| 30 
 drivers/gpu/drm/omapdrm/dss/display.c  | 39 +-
 drivers/gpu/drm/omapdrm/dss/dpi.c  | 10 +--
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 24 +++
 drivers/gpu/drm/omapdrm/dss/dss.h  |  4 +-
 drivers/gpu/drm/omapdrm/dss/hdmi.h |  8 +--
 drivers/gpu/drm/omapdrm/dss/hdmi4.c|  8 +--
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.c   |  2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c|  8 +--
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c   |  4 +-
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c  |  6 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h  | 82 +++--
 drivers/gpu/drm/omapdrm/dss/output.c   |  2 +-
 drivers/gpu/drm/omapdrm/dss/rfbi.c |  2 +-
 drivers/gpu/drm/omapdrm/dss/sdi.c  | 10 +--
 drivers/gpu/drm/omapdrm/dss/venc.c | 14 ++--
 drivers/gpu/drm/omapdrm/omap_connector.c   | 84 +++---
 drivers/gpu/drm/omapdrm/omap_crtc.c| 11 +--
 drivers/gpu/drm/omapdrm/omap_drv.h |  7 +-
 drivers/gpu/drm/omapdrm/omap_encoder.c |  6 +-
 34 files changed, 178 insertions(+), 317 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c 
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 264182f97194..53a4e6942616 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -24,12 +24,12 @@ struct panel_drv_data {
 
struct device *dev;
 
-   struct omap_video_timings timings;
+   struct videomode timings;
 
bool invert_polarity;
 };
 
-static const struct omap_video_timings tvc_pal_timings = {
+static const struct videomode tvc_pal_timings = {
.hactive= 720,
.vactive= 574,
.pixelclock = 1350,
@@ -127,7 +127,7 @@ static void tvc_disable(struct omap_dss_device *dssdev)
 }
 
 static void tvc_set_timings(struct omap_dss_device *dssdev,
-   struct omap_video_timings *timings)
+   struct videomode *timings)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata->in;
@@ -139,7 +139,7 @@ static void tvc_set_timings(struct omap_dss_device *dssdev,
 }
 
 static void tvc_get_timings(struct omap_dss_device *dssdev,
-   struct omap_video_timings *timings)
+   struct videomode *timings)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
 
@@ -147,7 +147,7 @@ static void tvc_get_timings(struct omap_dss_device *dssdev,
 }
 
 static int tvc_check_timings(struct omap_dss_device *dssdev,
-   struct omap_video_timings *timings)
+   struct videomode *timings)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata->in;
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index 53967a4a96a7..f4f8bf07f38b 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -19,7 +19,7 @@
 
 #include "../dss/omapdss.h"
 
-static const struct omap_video_timings dvic_default_timings = {
+static const struct videomode dvic_default_timings = {
.hactive= 640,
.vactive= 480,
 
@@ -42,7 +42,7 @@ struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;
 
-   struct omap_video_timings timings;
+   struct videomode timings;
 
struct i2c_adapter 

Re: strace lockup when tracing exec in go

2016-09-22 Thread Michal Hocko
On Thu 22-09-16 12:09:05, Mike Galbraith wrote:
> On Thu, 2016-09-22 at 11:53 +0200, Michal Hocko wrote:
> > On Thu 22-09-16 11:40:09, Mike Galbraith wrote:
> 
> > > This patch doesn't help, nor does the previous patch... but with both
> > > applied, all is well.  All you have to do now is figure out why :)
> > 
> > Ohh, I should be more explicit, this needs the mm_access part as well.
> > Sorry for not being clear enough. So the full change is
> 
> Ah.  That was gonna happen after lunch, but since you already know it
> works, I can get back to un-b0rking one of my trees.

Yeah, it should work. The testcase is running in a loop for more than
hour already and everything seems to be ok. Now the question is whether
the fix is really correct which is something for Oleg.

Also I think there is at least one more issue lurking there. Without or
without the patch I can make tracer get stuck in do_wait waiting for
task which doesn't seem to be alive anymore. I will report it separately
after this one gets resolved to not pull more confusion in.

Anyway, thanks for your time Mike!
-- 
Michal Hocko
SUSE Labs


[PATCH v2 02/23] drm/omap: omap_display_timings: rename y_res to vactive

2016-09-22 Thread Peter Ujfalusi
In preparation to move the stack to use the generic videmode struct for
display timing information rename the y_res member to vactive.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c |  2 +-
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c   |  2 +-
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c  |  2 +-
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c|  8 
 .../gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c|  2 +-
 drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c|  2 +-
 drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c |  2 +-
 drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c|  2 +-
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c|  2 +-
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c|  2 +-
 drivers/gpu/drm/omapdrm/dss/dispc.c| 14 +++---
 drivers/gpu/drm/omapdrm/dss/display.c  |  6 +++---
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 12 ++--
 drivers/gpu/drm/omapdrm/dss/hdmi4.c|  3 ++-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c|  3 ++-
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c   |  6 +++---
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c  |  2 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h  |  2 +-
 drivers/gpu/drm/omapdrm/dss/rfbi.c |  6 +++---
 drivers/gpu/drm/omapdrm/dss/venc.c |  4 ++--
 drivers/gpu/drm/omapdrm/omap_connector.c   |  4 ++--
 21 files changed, 45 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c 
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 190a03672181..a57e1efb12ac 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -31,7 +31,7 @@ struct panel_drv_data {
 
 static const struct omap_video_timings tvc_pal_timings = {
.hactive= 720,
-   .y_res  = 574,
+   .vactive= 574,
.pixelclock = 1350,
.hsw= 64,
.hfp= 12,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index c6e02e1a3799..b25c05c27c80 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -21,7 +21,7 @@
 
 static const struct omap_video_timings dvic_default_timings = {
.hactive= 640,
-   .y_res  = 480,
+   .vactive= 480,
 
.pixelclock = 2350,
 
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index ef5ae08b362b..33bc41c5cf71 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -23,7 +23,7 @@
 
 static const struct omap_video_timings hdmic_default_timings = {
.hactive= 640,
-   .y_res  = 480,
+   .vactive= 480,
.pixelclock = 25175000,
.hsw= 96,
.hfp= 16,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index d6c63d57a274..1493671c6e2f 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -384,7 +384,7 @@ static void dsicm_get_resolution(struct omap_dss_device 
*dssdev,
u16 *xres, u16 *yres)
 {
*xres = dssdev->panel.timings.hactive;
-   *yres = dssdev->panel.timings.y_res;
+   *yres = dssdev->panel.timings.vactive;
 }
 
 static ssize_t dsicm_num_errors_show(struct device *dev,
@@ -894,7 +894,7 @@ static int dsicm_update(struct omap_dss_device *dssdev,
/* XXX no need to send this every frame, but dsi break if not done */
r = dsicm_set_update_window(ddata, 0, 0,
dssdev->panel.timings.hactive,
-   dssdev->panel.timings.y_res);
+   dssdev->panel.timings.vactive);
if (r)
goto err;
 
@@ -1026,7 +1026,7 @@ static int dsicm_memory_read(struct omap_dss_device 
*dssdev,
 
size = min(w * h * 3,
dssdev->panel.timings.hactive *
-   dssdev->panel.timings.y_res * 3);
+   dssdev->panel.timings.vactive * 3);
 
in->ops.dsi->bus_lock(in);
 
@@ -1188,7 +1188,7 @@ static int dsicm_probe(struct platform_device *pdev)
return r;
 
ddata->timings.hactive = 864;
-   ddata->timings.y_res = 480;
+   ddata->timings.vactive = 480;
ddata->timings.pixelclock = 864 * 480 * 60;
 
dssdev = >dssdev;
diff --git 

[PATCH v2 05/23] drm/omap: omap_display_timings: rename hbp to hback_porch

2016-09-22 Thread Peter Ujfalusi
In preparation to move the stack to use the generic videmode struct for
display timing information rename the hbp member to hback_porch.

Signed-off-by: Peter Ujfalusi 
---
 .../gpu/drm/omapdrm/displays/connector-analog-tv.c|  2 +-
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c  |  2 +-
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c |  2 +-
 .../drm/omapdrm/displays/panel-lgphilips-lb035q02.c   |  2 +-
 .../gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c   |  2 +-
 .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c|  2 +-
 .../gpu/drm/omapdrm/displays/panel-sony-acx565akm.c   |  2 +-
 .../gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c   |  2 +-
 .../gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c   |  2 +-
 drivers/gpu/drm/omapdrm/dss/dispc.c   | 19 ++-
 drivers/gpu/drm/omapdrm/dss/display.c |  4 ++--
 drivers/gpu/drm/omapdrm/dss/dsi.c | 11 ++-
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c  |  4 ++--
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c |  6 +++---
 drivers/gpu/drm/omapdrm/dss/omapdss.h |  2 +-
 drivers/gpu/drm/omapdrm/dss/rfbi.c|  2 +-
 drivers/gpu/drm/omapdrm/dss/venc.c|  4 ++--
 drivers/gpu/drm/omapdrm/omap_connector.c  |  4 ++--
 18 files changed, 38 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c 
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 6d089b337bcb..2dbc6a42fb32 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -35,7 +35,7 @@ static const struct omap_video_timings tvc_pal_timings = {
.pixelclock = 1350,
.hsync_len  = 64,
.hfront_porch   = 12,
-   .hbp= 68,
+   .hback_porch= 68,
.vsw= 5,
.vfp= 5,
.vbp= 41,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index cf893866aca0..6cf541cb9933 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -27,7 +27,7 @@ static const struct omap_video_timings dvic_default_timings = 
{
 
.hfront_porch   = 48,
.hsync_len  = 32,
-   .hbp= 80,
+   .hback_porch= 80,
 
.vfp= 3,
.vsw= 4,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index fd1178b57f79..24d047844b7c 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -27,7 +27,7 @@ static const struct omap_video_timings hdmic_default_timings 
= {
.pixelclock = 25175000,
.hsync_len  = 96,
.hfront_porch   = 16,
-   .hbp= 48,
+   .hback_porch= 48,
.vsw= 2,
.vfp= 11,
.vbp= 31,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c 
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 677db7b22a02..295904a5f28d 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -27,7 +27,7 @@ static struct omap_video_timings lb035q02_timings = {
 
.hsync_len  = 2,
.hfront_porch   = 20,
-   .hbp= 68,
+   .hback_porch= 68,
 
.vsw= 2,
.vfp= 4,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c 
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index 8b2601010671..2eaa290a 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -72,7 +72,7 @@ static const struct omap_video_timings nec_8048_panel_timings 
= {
.pixelclock = LCD_PIXEL_CLOCK,
.hfront_porch   = 6,
.hsync_len  = 1,
-   .hbp= 4,
+   .hback_porch= 4,
.vfp= 3,
.vsw= 1,
.vbp= 4,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c 
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index c8348090e745..b36df2c66db1 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -43,7 +43,7 @@ static const struct omap_video_timings sharp_ls_timings = {
 
.hsync_len  = 2,
.hfront_porch   = 1,
-   .hbp= 28,
+   .hback_porch= 28,
 
.vsw= 1,
.vfp= 1,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c 

Re: [PATCH] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Baolin Wang
On 22 September 2016 at 18:58, Mark Brown  wrote:
> On Thu, Sep 22, 2016 at 06:53:12PM +0800, Baolin Wang wrote:
>> From: Badhri Jagan Sridharan 
>>
>> Some USB managament on userspace (like Android system) rely on the uevents
>> generated by the composition driver to generate user notifications. Thus this
>> patch adds uevents to be generated whenever USB changes its state: connected,
>> disconnected, configured.
>>
>> The original code was created by Badhri Jagan Sridharan, and I did some
>> optimization.
>>
>> CC: Badhri Jagan Sridharan 
>> Signed-off-by: Baolin Wang 
>
> If you're sending a patch someone else wrote you need their
> Signed-off-by - if they didn't provide one you need to talk to them
> about that and get it.

Ah, I missed that. I will add it if there are no objection from Badhr.i

>
>> +config USB_CONFIGFS_UEVENT
>> + boolean "Uevent notification of Gadget state"
>> + depends on USB_CONFIGFS
>> + help
>> +   Enable uevent notifications to userspace when the gadget
>> +   state changes. The gadget can be in any of the following
>> +   three states: "CONNECTED/DISCONNECTED/CONFIGURED"
>
> Why not just generate the events unconditionally?

If userspace doesn't need notification, then we can save some time to
do the enumeration without the uevent things.

-- 
Baolin.wang
Best Regards


[PATCH v2 10/23] drm/omap: omap_display_timings: Use display_flags for interlace mode

2016-09-22 Thread Peter Ujfalusi
Remove the interlace member and add display_flags to omap_video_timings to
configure the interlace mode.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c  | 2 --
 drivers/gpu/drm/omapdrm/dss/dispc.c| 7 +++
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c   | 4 ++--
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c  | 6 +++---
 drivers/gpu/drm/omapdrm/dss/omapdss.h  | 4 ++--
 drivers/gpu/drm/omapdrm/dss/rfbi.c | 2 +-
 drivers/gpu/drm/omapdrm/dss/venc.c | 8 
 drivers/gpu/drm/omapdrm/omap_connector.c   | 6 --
 10 files changed, 21 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c 
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index d14cc2e3b8e2..0a7491427832 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -40,7 +40,7 @@ static const struct omap_video_timings tvc_pal_timings = {
.vfront_porch   = 5,
.vback_porch= 41,
 
-   .interlace  = true,
+   .flags  = DISPLAY_FLAGS_INTERLACED,
 };
 
 static const struct of_device_id tvc_of_match[];
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index 00e3aa212202..8e246b9142d7 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -34,8 +34,6 @@ static const struct omap_video_timings hdmic_default_timings 
= {
 
.vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
-
-   .interlace  = false,
 };
 
 struct panel_drv_data {
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index f21b7dd0f492..858d87dd7fe8 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2607,7 +2607,7 @@ static int dispc_ovl_setup_common(enum omap_plane plane,
u16 in_height = height;
u16 in_width = width;
int x_predecim = 1, y_predecim = 1;
-   bool ilace = mgr_timings->interlace;
+   bool ilace = !!(mgr_timings->flags & DISPLAY_FLAGS_INTERLACED);
unsigned long pclk = dispc_plane_pclk_rate(plane);
unsigned long lclk = dispc_plane_lclk_rate(plane);
 
@@ -3128,7 +3128,7 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,
 
if (dss_mgr_is_lcd(channel)) {
/* TODO: OMAP4+ supports interlace for LCD outputs */
-   if (timings->interlace)
+   if (timings->flags & DISPLAY_FLAGS_INTERLACED)
return false;
 
if (!_dispc_lcd_timings_ok(timings->hsync_len,
@@ -3292,7 +3292,7 @@ void dispc_mgr_set_timings(enum omap_channel channel,
 
DSSDBG("hsync %luHz, vsync %luHz\n", ht, vt);
} else {
-   if (t.interlace)
+   if (t.flags & DISPLAY_FLAGS_INTERLACED)
t.vactive /= 2;
 
if (dispc.feat->supports_double_pixel)
@@ -4232,7 +4232,6 @@ static const struct dispc_errata_i734_data {
.vsync_len = 1, .vfront_porch = 1, .vback_porch = 1,
.vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
-   .interlace = false,
.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.de_level = OMAPDSS_SIG_ACTIVE_HIGH,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 9ed17dba2849..0d05ac9931a2 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -4122,7 +4122,7 @@ static int dsi_display_init_dispc(struct platform_device 
*dsidev,
 * override interlace, logic level and edge related parameters in
 * omap_video_timings with default values
 */
-   dsi->timings.interlace = false;
+   dsi->timings.flags &= ~DISPLAY_FLAGS_INTERLACED;
dsi->timings.hsync_level = OMAPDSS_SIG_ACTIVE_HIGH;
dsi->timings.vsync_level = OMAPDSS_SIG_ACTIVE_HIGH;
dsi->timings.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
index 2baef4f7714b..62268f8d62c6 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
@@ -303,7 +303,7 @@ static void hdmi_core_init(struct hdmi_core_vid_config 
*video_cfg,
cfg->timings.vback_porch;
video_cfg->v_fc_config.hdmi_dvi_mode = cfg->hdmi_dvi_mode;
 
-   if (cfg->timings.interlace) {
+   if 

[PATCH v2 22/23] drm/omap: panel-sharp-ls037v7dw01: Add note for incorrect data drive edge

2016-09-22 Thread Peter Ujfalusi
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c 
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index fd33156bc34c..04fe235b7cac 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -52,6 +52,10 @@ static const struct videomode sharp_ls_vm = {
.flags  = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
  DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_SYNC_NEGEDGE |
  DISPLAY_FLAGS_PIXDATA_POSEDGE,
+   /*
+* Note: According to the panel documentation:
+* DATA needs to be driven on the FALLING edge
+*/
 };
 
 #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
-- 
2.10.0



[PATCH v2 20/23] drm/omap: panel-tpo-td043mtea1: Add note for incorrect sync drive edge

2016-09-22 Thread Peter Ujfalusi
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c 
b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c
index f78102aab2e6..0787dba44faa 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c
@@ -89,6 +89,10 @@ static const struct videomode tpo_td043_vm = {
.flags  = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
  DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_SYNC_POSEDGE |
  DISPLAY_FLAGS_PIXDATA_NEGEDGE,
+   /*
+* Note: According to the panel documentation:
+* SYNC needs to be driven on the FALLING edge
+*/
 };
 
 #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
-- 
2.10.0



Re: [PATCH 2/4] drivers: iio: ti_am335x_adc: add dma support

2016-09-22 Thread Peter Ujfalusi
On 09/22/16 13:45, Mugunthan V N wrote:
>>> +   if (!dma->chan)
>>> +   return -ENODEV;
>>> +
>>> +   /* RX buffer */
>>> +   dma->buf = dma_alloc_coherent(dma->chan->device->dev, DMA_BUFFER_SIZE,
>>> + >addr, GFP_KERNEL);
>>> +   if (!dma->buf)
>>> +   goto err;
>>> +
>>> +   dev_dbg_ratelimited(adc_dev->mfd_tscadc->dev, "got dma channel\n");
>>
>> Do we need _ratelimited? AFAICS, this print is called only once.
> 
> True, will change to dev_dbg.

It would be better to remove it. It gives no useful debuggin information apart
from the fact that the driver did not failed to probe.

-- 
Péter


Re: [PATCH net-next v2 1/3] net: ethernet: mediatek: add extension of phy-mode for TRGMII

2016-09-22 Thread Sergei Shtylyov

Hello.

On 9/22/2016 5:33 AM, sean.w...@mediatek.com wrote:


From: Sean Wang 

adds PHY-mode "trgmii" as an extension for the operation
mode of the PHY interface for PHY_INTERFACE_MODE_TRGMII.
and adds a variable trgmii inside mtk_mac as the indication
to make the difference between the MAC connected to internal
switch or connected to external PHY by the given configuration
on the board and then to perform the corresponding setup on
TRGMII hardware module.

Signed-off-by: Sean Wang 
Cc: Florian Fainelli 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 ++
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 3 +++
 include/linux/phy.h | 3 +++
 3 files changed, 8 insertions(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index ca6b501..827f4bd 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -244,6 +244,8 @@ static int mtk_phy_connect(struct mtk_mac *mac)
return -ENODEV;

switch (of_get_phy_mode(np)) {
+   case PHY_INTERFACE_MODE_TRGMII:
+   mac->trgmii = true;
case PHY_INTERFACE_MODE_RGMII_TXID:
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_ID:
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 7c5e534..e3b9525 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -529,6 +529,8 @@ struct mtk_eth {
  * @hw:Backpointer to our main datastruture
  * @hw_stats:  Packet statistics counter
  * @phy_dev:   The attached PHY if available
+ * @trgmii Indicate if the MAC uses TRGMII connected to internal
+   switch
  */
 struct mtk_mac {
int id;
@@ -539,6 +541,7 @@ struct mtk_mac {
struct phy_device   *phy_dev;
__be32  hwlro_ip[MTK_MAX_LRO_IP_CNT];
int hwlro_ip_cnt;
+   booltrgmii;


I don't see where this is used.

[...]

diff --git a/include/linux/phy.h b/include/linux/phy.h
index 2d24b28..e25f183 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -80,6 +80,7 @@ typedef enum {
PHY_INTERFACE_MODE_XGMII,
PHY_INTERFACE_MODE_MOCA,
PHY_INTERFACE_MODE_QSGMII,
+   PHY_INTERFACE_MODE_TRGMII,
PHY_INTERFACE_MODE_MAX,
 } phy_interface_t;

@@ -123,6 +124,8 @@ static inline const char *phy_modes(phy_interface_t 
interface)
return "moca";
case PHY_INTERFACE_MODE_QSGMII:
return "qsgmii";
+   case PHY_INTERFACE_MODE_TRGMII:
+   return "trgmii";
default:
return "unknown";
}


   I think this should be done in a separate phylib patch.

MBR, Sergei



[PATCH v2] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Baolin Wang
From: Badhri Jagan Sridharan 

Some USB managament on userspace (like Android system) rely on the uevents
generated by the composition driver to generate user notifications. Thus this
patch adds uevents to be generated whenever USB changes its state: connected,
disconnected, configured.

The original code was created by Badhri Jagan Sridharan, and I did some
optimization.

Signed-off-by: Badhri Jagan Sridharan 
Signed-off-by: Baolin Wang 
---
Changes since v1:
 - Add Badhri's Signed-off-by.
---
 drivers/usb/gadget/Kconfig|8 +++
 drivers/usb/gadget/configfs.c |  107 +
 2 files changed, 115 insertions(+)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 2ea3fc3..9f5d0c6 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -223,6 +223,14 @@ config USB_CONFIGFS
  appropriate symbolic links.
  For more information see Documentation/usb/gadget_configfs.txt.
 
+config USB_CONFIGFS_UEVENT
+   boolean "Uevent notification of Gadget state"
+   depends on USB_CONFIGFS
+   help
+ Enable uevent notifications to userspace when the gadget
+ state changes. The gadget can be in any of the following
+ three states: "CONNECTED/DISCONNECTED/CONFIGURED"
+
 config USB_CONFIGFS_SERIAL
bool "Generic serial bulk in/out"
depends on USB_CONFIGFS
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 3984787..4c2bc27 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -60,6 +60,11 @@ struct gadget_info {
bool use_os_desc;
char b_vendor_code;
char qw_sign[OS_STRING_QW_SIGN_LEN];
+#ifdef CONFIG_USB_CONFIGFS_UEVENT
+   bool connected;
+   bool sw_connected;
+   struct work_struct work;
+#endif
 };
 
 static inline struct gadget_info *to_gadget_info(struct config_item *item)
@@ -1197,6 +1202,57 @@ int composite_dev_prepare(struct usb_composite_driver 
*composite,
 int composite_os_desc_req_prepare(struct usb_composite_dev *cdev,
  struct usb_ep *ep0);
 
+#ifdef CONFIG_USB_CONFIGFS_UEVENT
+static void configfs_work(struct work_struct *data)
+{
+   struct gadget_info *gi = container_of(data, struct gadget_info, work);
+   struct usb_composite_dev *cdev = >cdev;
+   char *disconnected[2] = { "USB_STATE=DISCONNECTED", NULL };
+   char *connected[2] = { "USB_STATE=CONNECTED", NULL };
+   char *configured[2] = { "USB_STATE=CONFIGURED", NULL };
+   /* 0-connected 1-configured 2-disconnected */
+   bool status[3] = { false, false, false };
+   unsigned long flags;
+   bool uevent_sent = false;
+
+   spin_lock_irqsave(>lock, flags);
+   if (cdev->config && gi->connected)
+   status[1] = true;
+
+   if (gi->connected != gi->sw_connected) {
+   if (gi->connected)
+   status[0] = true;
+   else
+   status[2] = true;
+   gi->sw_connected = gi->connected;
+   }
+   spin_unlock_irqrestore(>lock, flags);
+
+   if (status[0]) {
+   kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, connected);
+   pr_info("%s: sent uevent %s\n", __func__, connected[0]);
+   uevent_sent = true;
+   }
+
+   if (status[1]) {
+   kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, configured);
+   pr_info("%s: sent uevent %s\n", __func__, configured[0]);
+   uevent_sent = true;
+   }
+
+   if (status[2]) {
+   kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, disconnected);
+   pr_info("%s: sent uevent %s\n", __func__, disconnected[0]);
+   uevent_sent = true;
+   }
+
+   if (!uevent_sent) {
+   pr_info("%s: did not send uevent (%d %d %p)\n", __func__,
+   gi->connected, gi->sw_connected, cdev->config);
+   }
+}
+#endif
+
 static void purge_configs_funcs(struct gadget_info *gi)
 {
struct usb_configuration*c;
@@ -1386,13 +1442,60 @@ static void configfs_composite_unbind(struct usb_gadget 
*gadget)
set_gadget_data(gadget, NULL);
 }
 
+#ifdef CONFIG_USB_CONFIGFS_UEVENT
+static int configfs_setup(struct usb_gadget *gadget,
+ const struct usb_ctrlrequest *c)
+{
+   struct usb_composite_dev *cdev = get_gadget_data(gadget);
+   struct gadget_info *gi = container_of(cdev, struct gadget_info, cdev);
+   int value = -EOPNOTSUPP;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   if (!gi->connected) {
+   gi->connected = 1;
+   schedule_work(>work);
+   }
+   spin_unlock_irqrestore(>lock, flags);
+
+   value = composite_setup(gadget, c);
+
+   spin_lock_irqsave(>lock, flags);
+   if (c->bRequest == 

[tip:x86/boot] x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation

2016-09-22 Thread tip-bot for Dan Williams
Commit-ID:  917db484dc6a69969d317b3e57add4208a8d9d42
Gitweb: http://git.kernel.org/tip/917db484dc6a69969d317b3e57add4208a8d9d42
Author: Dan Williams 
AuthorDate: Wed, 21 Sep 2016 12:50:45 -0700
Committer:  Ingo Molnar 
CommitDate: Thu, 22 Sep 2016 12:26:48 +0200

x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation

In commit:

  ec776ef6bbe1 ("x86/mm: Add support for the non-standard protected e820 type")

Christoph references the original patch I wrote implementing pmem support.
The intent of the 'max_pfn' changes in that commit were to enable persistent
memory ranges to be covered by the struct page memmap by default.

However, that approach was abandoned when Christoph ported the patches [1], and
that functionality has since been replaced by devm_memremap_pages().

In the meantime, this max_pfn manipulation is confusing kdump [2] that
assumes that everything covered by the max_pfn is "System RAM".  This
results in kdump hanging or crashing.

 [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-March/000348.html
 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1351098

So fix it.

Reported-by: Zhang Yi 
Reported-by: Jeff Moyer 
Tested-by: Zhang Yi 
Signed-off-by: Dan Williams 
Reviewed-by: Jeff Moyer 
Cc:  # v4.1 and later kernels
Cc: Andrew Morton 
Cc: Boaz Harrosh 
Cc: Christoph Hellwig 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Ross Zwisler 
Cc: Thomas Gleixner 
Cc: linux-nvd...@lists.01.org
Fixes: ec776ef6bbe1 ("x86/mm: Add support for the non-standard protected e820 
type")
Link: 
http://lkml.kernel.org/r/147448744538.34910.11287693517367139607.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/e820.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index bb8c690..b85fe5f 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -350,7 +350,7 @@ int __init sanitize_e820_map(struct e820entry *biosmap, int 
max_nr_map,
 * continue building up new bios map based on this
 * information
 */
-   if (current_type != last_type || current_type == E820_PRAM) {
+   if (current_type != last_type) {
if (last_type != 0)  {
new_bios[new_bios_entry].size =
change_point[chgidx]->addr - last_addr;
@@ -783,7 +783,7 @@ u64 __init early_reserve_e820(u64 size, u64 align)
 /*
  * Find the highest page frame number we have available
  */
-static unsigned long __init e820_end_pfn(unsigned long limit_pfn)
+static unsigned long __init e820_end_pfn(unsigned long limit_pfn, unsigned 
type)
 {
int i;
unsigned long last_pfn = 0;
@@ -794,11 +794,7 @@ static unsigned long __init e820_end_pfn(unsigned long 
limit_pfn)
unsigned long start_pfn;
unsigned long end_pfn;
 
-   /*
-* Persistent memory is accounted as ram for purposes of
-* establishing max_pfn and mem_map.
-*/
-   if (ei->type != E820_RAM && ei->type != E820_PRAM)
+   if (ei->type != type)
continue;
 
start_pfn = ei->addr >> PAGE_SHIFT;
@@ -823,12 +819,12 @@ static unsigned long __init e820_end_pfn(unsigned long 
limit_pfn)
 }
 unsigned long __init e820_end_of_ram_pfn(void)
 {
-   return e820_end_pfn(MAX_ARCH_PFN);
+   return e820_end_pfn(MAX_ARCH_PFN, E820_RAM);
 }
 
 unsigned long __init e820_end_of_low_ram_pfn(void)
 {
-   return e820_end_pfn(1UL << (32-PAGE_SHIFT));
+   return e820_end_pfn(1UL << (32 - PAGE_SHIFT), E820_RAM);
 }
 
 static void __init early_panic(char *msg)


Re: [PATCH net-next 0/9] rxrpc: Preparation for slow-start algorithm [ver #2]

2016-09-22 Thread David Miller
From: David Howells <dhowe...@redhat.com>
Date: Thu, 22 Sep 2016 09:22:00 +0100

> Tagged thusly:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-rewrite-20160922-v2

Pulled, thanks David.


Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

2016-09-22 Thread Arnd Bergmann
On Thursday, September 22, 2016 11:55:45 AM CEST Gabriele Paoloni wrote:
> > > I think extending of_empty_ranges_quirk() may be a reasonable
> > solution.
> > > What do you think Arnd?
> > 
> > I don't really like that idea, that quirk is meant to work around
> > broken DTs, but we can just make the DT valid and implement the
> > code properly.
> 
> Ok  I understand your point where it is not right to use 
> of_empty_ranges_quirk()
> As a quirk is used to work around broken HW or broken FW (as in this case)
> rather than to fix code
> 
> What about the following? I think adding the check you suggested next to
> of_empty_ranges_quirk() is adding the case we need in the right point (thus
> avoiding any duplication)
>  
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -457,6 +457,15 @@ static struct of_bus *of_match_bus(struct device_node 
> *np)
> return NULL;
>  }
>  
> +static inline int of_isa_indirect_io(struct device_node *np)
> +{
> +   /*
> +* check if the current node is an isa bus and if indirectio operation
> +* are registered
> +*/
> +   return (of_bus_isa_match(np) && arm64_extio_ops);
> +}
> +
>  static int of_empty_ranges_quirk(struct device_node *np)
>  {
> if (IS_ENABLED(CONFIG_PPC)) {
> @@ -503,7 +512,7 @@ static int of_translate_one(struct device_node *parent, 
> struct of_bus *bus,
>  * This code is only enabled on powerpc. --gcl
>  */
> ranges = of_get_property(parent, rprop, );
> -   if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
> +   if (ranges == NULL && !of_empty_ranges_quirk(parent) && 
> !of_isa_indirect_io(parent)) {
> pr_debug("OF: no ranges; cannot translate\n");
> return 1;
> }

I don't see what effect that would have. What do you want to
achieve with this?

I think all we need from this function is to return '1' if
we hit an ISA I/O window, and that should happen for the two
interesting cases, either no 'ranges' at all, or no translation
for the range in question, so that __of_translate_address can
return OF_BAD_ADDR, and we can enter the special case
handling in the caller, that handles it like

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903fe9d2..a18d96843fae 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -685,17 +685,24 @@ static int __of_address_to_resource(struct device_node 
*dev,
if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
return -EINVAL;
taddr = of_translate_address(dev, addrp);
-   if (taddr == OF_BAD_ADDR)
-   return -EINVAL;
memset(r, 0, sizeof(struct resource));
+
if (flags & IORESOURCE_IO) {
unsigned long port;
-   port = pci_address_to_pio(taddr);
+
+   if (taddr == OF_BAD_ADDR)
+   port = arch_of_address_to_pio(dev, addrp)
+   else
+   port = pci_address_to_pio(taddr);
+
if (port == (unsigned long)-1)
return -EINVAL;
r->start = port;
r->end = port + size - 1;
} else {
+   if (taddr == OF_BAD_ADDR)
+   return -EINVAL;
+
r->start = taddr;
r->end = taddr + size - 1;
}



Arnd


Re: [PATCH v2] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Greg KH
On Thu, Sep 22, 2016 at 07:43:59PM +0800, Baolin Wang wrote:
> From: Badhri Jagan Sridharan 
> 
> Some USB managament on userspace (like Android system) rely on the uevents
> generated by the composition driver to generate user notifications. Thus this
> patch adds uevents to be generated whenever USB changes its state: connected,
> disconnected, configured.
> 
> The original code was created by Badhri Jagan Sridharan, and I did some
> optimization.
> 
> Signed-off-by: Badhri Jagan Sridharan 

You can't just add someone's signed-off-by to a patch, go read what the
legal agreement you just made for someone else at a different company
(hint, you might get a nasty-gram from a google lawyer...)

> Signed-off-by: Baolin Wang 
> ---
> Changes since v1:
>  - Add Badhri's Signed-off-by.
> ---
>  drivers/usb/gadget/Kconfig|8 +++
>  drivers/usb/gadget/configfs.c |  107 
> +
>  2 files changed, 115 insertions(+)
> 
> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> index 2ea3fc3..9f5d0c6 100644
> --- a/drivers/usb/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -223,6 +223,14 @@ config USB_CONFIGFS
> appropriate symbolic links.
> For more information see Documentation/usb/gadget_configfs.txt.
>  
> +config USB_CONFIGFS_UEVENT
> + boolean "Uevent notification of Gadget state"
> + depends on USB_CONFIGFS



> + help
> +   Enable uevent notifications to userspace when the gadget
> +   state changes. The gadget can be in any of the following
> +   three states: "CONNECTED/DISCONNECTED/CONFIGURED"
> +
>  config USB_CONFIGFS_SERIAL
>   bool "Generic serial bulk in/out"
>   depends on USB_CONFIGFS
> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
> index 3984787..4c2bc27 100644
> --- a/drivers/usb/gadget/configfs.c
> +++ b/drivers/usb/gadget/configfs.c
> @@ -60,6 +60,11 @@ struct gadget_info {
>   bool use_os_desc;
>   char b_vendor_code;
>   char qw_sign[OS_STRING_QW_SIGN_LEN];
> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
> + bool connected;
> + bool sw_connected;
> + struct work_struct work;
> +#endif
>  };
>  
>  static inline struct gadget_info *to_gadget_info(struct config_item *item)
> @@ -1197,6 +1202,57 @@ int composite_dev_prepare(struct usb_composite_driver 
> *composite,
>  int composite_os_desc_req_prepare(struct usb_composite_dev *cdev,
> struct usb_ep *ep0);
>  
> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
> +static void configfs_work(struct work_struct *data)
> +{
> + struct gadget_info *gi = container_of(data, struct gadget_info, work);
> + struct usb_composite_dev *cdev = >cdev;
> + char *disconnected[2] = { "USB_STATE=DISCONNECTED", NULL };
> + char *connected[2] = { "USB_STATE=CONNECTED", NULL };
> + char *configured[2] = { "USB_STATE=CONFIGURED", NULL };
> + /* 0-connected 1-configured 2-disconnected */
> + bool status[3] = { false, false, false };
> + unsigned long flags;
> + bool uevent_sent = false;
> +
> + spin_lock_irqsave(>lock, flags);
> + if (cdev->config && gi->connected)
> + status[1] = true;
> +
> + if (gi->connected != gi->sw_connected) {
> + if (gi->connected)
> + status[0] = true;
> + else
> + status[2] = true;
> + gi->sw_connected = gi->connected;
> + }
> + spin_unlock_irqrestore(>lock, flags);
> +
> + if (status[0]) {
> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, connected);
> + pr_info("%s: sent uevent %s\n", __func__, connected[0]);

You are kidding, right?

> + uevent_sent = true;
> + }
> +
> + if (status[1]) {
> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, configured);
> + pr_info("%s: sent uevent %s\n", __func__, configured[0]);

Come on, please...

> + uevent_sent = true;
> + }
> +
> + if (status[2]) {
> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, disconnected);
> + pr_info("%s: sent uevent %s\n", __func__, disconnected[0]);

This is getting funny...

> + uevent_sent = true;
> + }
> +
> + if (!uevent_sent) {
> + pr_info("%s: did not send uevent (%d %d %p)\n", __func__,
> + gi->connected, gi->sw_connected, cdev->config);

Nope, not funny anymore.

> + }
> +}
> +#endif
> +
>  static void purge_configs_funcs(struct gadget_info *gi)
>  {
>   struct usb_configuration*c;
> @@ -1386,13 +1442,60 @@ static void configfs_composite_unbind(struct 
> usb_gadget *gadget)
>   set_gadget_data(gadget, NULL);
>  }
>  
> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
> +static int configfs_setup(struct usb_gadget *gadget,
> +   const struct usb_ctrlrequest *c)
> +{
> + struct usb_composite_dev *cdev = 

Re: [PATCH net-next] net: ethernet: mediatek: get out of potential invalid pointer access

2016-09-22 Thread David Miller
From: 
Date: Thu, 22 Sep 2016 16:44:16 +0800

> From: Sean Wang 
> 
> Potential dangerous invalid pointer might be accessed if
> the error happens when couple phy_device to net_device so
> cleanup the error path.
> 
> Signed-off-by: Sean Wang 

Applied.


Re: [PATCH] rtc: cmos: avoid unused function warning

2016-09-22 Thread Alexandre Belloni
On 22/09/2016 at 11:48:00 +0200, Arnd Bergmann wrote :
> A bug fix for the ACPI side of this driver caused a harmless
> build warning:
> 
> drivers/rtc/rtc-cmos.c:1115:13: error: 'cmos_check_acpi_rtc_status' defined 
> but not used [-Werror=unused-function]
>  static void cmos_check_acpi_rtc_status(struct device *dev,
> 
> We can avoid the warning and simplify the driver at the same time
> by removing the #ifdef for CONFIG_PM and rely on the SIMPLE_DEV_PM_OPS()
> to set everything up correctly. cmos_resume() has to get marked
> as __maybe_unused so we don't introduce another warning, and
> the two variants of cmos_poweroff() can get merged into one using
> an IS_ENABLED() check.
> 
> Fixes: 983bf1256edb ("rtc: cmos: Clear ACPI-driven alarms upon resume")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/rtc/rtc-cmos.c | 21 -
>  1 file changed, 4 insertions(+), 17 deletions(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


Re: [PATCH net-next] net: ethernet: mediatek: use phydev from struct net_device

2016-09-22 Thread David Miller
From: 
Date: Thu, 22 Sep 2016 16:33:35 +0800

> From: Sean Wang 
> 
> reuse phydev already in struct net_device instead of creating
> another new one in private structure.
> 
> Signed-off-by: Sean Wang 

Applied.


Re: [PATCH net-next] net: ethernet: mediatek: remove superfluous local variable for phy address

2016-09-22 Thread David Miller
From: 
Date: Thu, 22 Sep 2016 16:36:15 +0800

> From: Sean Wang 
> 
> remove the unused variable for parsing PHY address
> and the related logic for sanity test which would
> be all already handled done when of_mdiobus_register
> was called
> 
> Reported-by: Nelson Chang 
> Signed-off-by: Sean Wang 

Applied.


Re: [PATCH net-next v2 0/3] add support for RGMII on GMAC0 through TRGMII hardware module

2016-09-22 Thread David Miller
From: 
Date: Thu, 22 Sep 2016 10:33:53 +0800

> By default, GMAC0 is connected to built-in switch called
> MT7530 through the proprietary interface called Turbo RGMII
> (TRGMII). TRGMII also supports well for RGMII as generic external
> PHY uses but requires some slight changes to the setup of TRGMII 
> and doesn't have well support on current driver.
> 
> So this patchset
> 1) provides the slight changes of the setup for RGMII can work
>through TRGMII
> 2) adds additional setting "trgmii" as PHY_INTERFACE_MODE_TRGMII 
>about phy-mode on device tree to make GMAC0 distinguish which
>mode it runs
> 3) changes dynamically source clock, TX/RX delay and interface
>mode on TRGMII for adapting various link
> 
> Changes since v1:
> - fixed the style of comment which doesn't have a space at 
>the beginning and end of comment lines
> - add support for phy-mode "trgmii" as PHY_INTERFACE_MODE_TRGMII 
>into linux/phy.h
> - enhance the Documentation about device tree binding for trgmii
>   which is applicable only for GMAC0 which uses fixed-link

Series applied.


Re: [PATCH 3/5] mm/vmalloc.c: correct lazy_max_pages() return value

2016-09-22 Thread Michal Hocko
On Thu 22-09-16 09:13:50, zijun_hu wrote:
> On 09/22/2016 08:35 AM, David Rientjes wrote:
[...]
> > The intent is as it is implemented; with your change, lazy_max_pages() is 
> > potentially increased depending on the number of online cpus.  This is 
> > only a heuristic, changing it would need justification on why the new 
> > value is better.  It is opposite to what the comment says: "to be 
> > conservative and not introduce a big latency on huge systems, so go with
> > a less aggressive log scale."  NACK to the patch.
> > 
> my change potentially make lazy_max_pages() decreased not increased, i seems
> conform with the comment
> 
> if the number of online CPUs is not power of 2, both have no any difference
> otherwise, my change remain power of 2 value, and the original code rounds up
> to next power of 2 value, for instance
> 
> my change : (32, 64] -> 64
>32 -> 32, 64 -> 64
> the original code: [32, 63) -> 64
>32 -> 64, 64 -> 128

You still completely failed to explain _why_ this is an improvement/fix
or why it matters. This all should be in the changelog.

-- 
Michal Hocko
SUSE Labs


Re: [PATCH 1/1] lib/ioremap.c: avoid endless loop under ioremapping page unaligned ranges

2016-09-22 Thread Michal Hocko
On Wed 21-09-16 12:19:53, zijun_hu wrote:
> From: zijun_hu 
> 
> endless loop maybe happen if either of parameter addr and end is not
> page aligned for kernel API function ioremap_page_range()

Does this happen in practise or this you found it by reading the code?

> in order to fix this issue and alert improper range parameters to user
> WARN_ON() checkup and rounding down range lower boundary are performed
> firstly, loop end condition within ioremap_pte_range() is optimized due
> to lack of relevant macro pte_addr_end()
> 
> Signed-off-by: zijun_hu 
> ---
>  lib/ioremap.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/ioremap.c b/lib/ioremap.c
> index 86c8911..911bdca 100644
> --- a/lib/ioremap.c
> +++ b/lib/ioremap.c
> @@ -64,7 +64,7 @@ static int ioremap_pte_range(pmd_t *pmd, unsigned long addr,
>   BUG_ON(!pte_none(*pte));
>   set_pte_at(_mm, addr, pte, pfn_pte(pfn, prot));
>   pfn++;
> - } while (pte++, addr += PAGE_SIZE, addr != end);
> + } while (pte++, addr += PAGE_SIZE, addr < end && addr >= PAGE_SIZE);
>   return 0;
>  }

Ble, this just overcomplicate things. Can we just make sure that the
proper alignment is done in ioremap_page_range which is the only caller
of this (and add VM_BUG_ON in ioremap_pud_range to make sure no new
caller will forget about that).

>  
> @@ -129,7 +129,9 @@ int ioremap_page_range(unsigned long addr,
>   int err;
>  
>   BUG_ON(addr >= end);
> + WARN_ON(!PAGE_ALIGNED(addr) || !PAGE_ALIGNED(end));

maybe WARN_ON_ONCE would be sufficient to prevent from swamping logs if
something just happens to do this too often in some pathological path.

>  
> + addr = round_down(addr, PAGE_SIZE);

end = round_up(end, PAGE_SIZE);

wouldn't work?

>   start = addr;
>   phys_addr -= addr;
>   pgd = pgd_offset_k(addr);
> -- 
> 1.9.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 

-- 
Michal Hocko
SUSE Labs


Re: [PATCH] ipvlan: fix building without netfilter

2016-09-22 Thread Arnd Bergmann
On Thursday, September 22, 2016 8:32:05 AM CEST David Miller wrote:
> From: Arnd Bergmann 
> Date: Thu, 22 Sep 2016 11:40:52 +0200
> 
> > The new l3s mode in ipvlan relies on netfilter interfaces, but
> > the ipvlan driver can be configured when CONFIG_NETFILTER is disabled,
> > leading to a build error:
> > 
> > drivers/net/ipvlan/ipvlan.h:132:22: error: 'struct nf_hook_state' declared 
> > inside parameter list will not be visible outside of this definition or 
> > declaration [-Werror]
> > drivers/net/ipvlan/ipvlan_main.c:14:27: error: array type has incomplete 
> > element type 'struct nf_hook_ops'
> > ...
> > 
> > This adds a forward declaration for struct nf_hook_state, and hides
> > the newly added l3s code in an #ifdef.
> > 
> > Fixes: 4fbae7d83c98 ("ipvlan: Introduce l3s mode")
> > Signed-off-by: Arnd Bergmann 
> 
> I'm pretty sure I applied a Kconfig patch that added the
> necessary dependency.

Yes, I see the fix cf714ac147e0 ("ipvlan: Fix dependency issue") now, and
can confirm that today's linux-next works without my patch, thanks!

Arnd


Re: [PATCH v2] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Felipe Balbi


Hi,

Baolin Wang  writes:
>>>  static const struct usb_gadget_driver configfs_driver_template = {
>>>   .bind   = configfs_composite_bind,
>>>   .unbind = configfs_composite_unbind,
>>>
>>> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
>>> + .setup  = configfs_setup,
>>> + .reset  = configfs_disconnect,
>>> + .disconnect = configfs_disconnect,
>>> +#else
>>>   .setup  = composite_setup,
>>>   .reset  = composite_disconnect,
>>>   .disconnect = composite_disconnect,
>>> +#endif

nope, this is quite wrong.

>>> @@ -1453,6 +1556,10 @@ static struct config_group *gadgets_make(
>>>   gi->composite.gadget_driver.function = kstrdup(name, GFP_KERNEL);
>>>   gi->composite.name = gi->composite.gadget_driver.function;
>>>
>>> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
>>> + INIT_WORK(>work, configfs_work);
>>> +#endif
>>
>> This is just way too ugly, please make it so there are no #ifdefs in the
>> .c files.
>>
>> Or, as others said, why is this a build option at all, why would you not
>> always want this enabled if you are relying on it all of the time?
>
> Sometimes userspace does not need the notification, it is not all the
> time. Anyway I will remove the macro if you still insist on that.

what's wrong with the sysfs we already have for this?

-- 
balbi


[PATCH 52/57] perf c2c report: Recalc width of global sort entries

2016-09-22 Thread Jiri Olsa
Using resort callbacks to compute the columns' width.

Computing only the global ones, c2c entries have fixed
width only.

Link: http://lkml.kernel.org/n/tip-zyayvq2u3dzyf3y7i9jza...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index ee64537493ce..c7fe81d49016 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -1722,11 +1722,21 @@ static inline int valid_hitm_or_store(struct hist_entry 
*he)
return has_hitm || c2c_he->stats.store;
 }
 
+static void calc_width(struct hist_entry *he)
+{
+   struct c2c_hists *c2c_hists;
+
+   c2c_hists = container_of(he->hists, struct c2c_hists, hists);
+   hists__calc_col_len(_hists->hists, he);
+}
+
 static int filter_cb(struct hist_entry *he)
 {
if (c2c.show_src && !he->srcline)
he->srcline = hist_entry__get_srcline(he);
 
+   calc_width(he);
+
if (!valid_hitm_or_store(he))
he->filtered = HIST_FILTER__C2C;
 
@@ -1742,6 +1752,8 @@ static int resort_cl_cb(struct hist_entry *he)
c2c_he = container_of(he, struct c2c_hist_entry, he);
c2c_hists = c2c_he->hists;
 
+   calc_width(he);
+
if (display && c2c_hists) {
c2c_hists__reinit(c2c_hists, c2c.cl_output, c2c.cl_resort);
 
-- 
2.7.4



[PATCH v2 3/5] soc/bman: Add self-test for BMan driver

2016-09-22 Thread Claudiu Manoil
Add a self test for the DPAA 1.x Buffer Manager driver. This
test ensures that the driver can properly acquire and release
buffers using the BMan portal infrastructure.

Signed-off-by: Roy Pledge 
Signed-off-by: Claudiu Manoil 
---
v2: none

 drivers/soc/fsl/qbman/Kconfig |  16 
 drivers/soc/fsl/qbman/Makefile|   4 +
 drivers/soc/fsl/qbman/bman_test.c |  53 
 drivers/soc/fsl/qbman/bman_test.h |  35 
 drivers/soc/fsl/qbman/bman_test_api.c | 151 ++
 5 files changed, 259 insertions(+)
 create mode 100644 drivers/soc/fsl/qbman/bman_test.c
 create mode 100644 drivers/soc/fsl/qbman/bman_test.h
 create mode 100644 drivers/soc/fsl/qbman/bman_test_api.c

diff --git a/drivers/soc/fsl/qbman/Kconfig b/drivers/soc/fsl/qbman/Kconfig
index 8f2df64..e6da6a2 100644
--- a/drivers/soc/fsl/qbman/Kconfig
+++ b/drivers/soc/fsl/qbman/Kconfig
@@ -25,4 +25,20 @@ config FSL_DPAA_CHECKING
  Compiles in additional checks, to sanity-check the drivers and
  any use of the exported API. Not recommended for performance.
 
+config FSL_BMAN_TEST
+   tristate "BMan self-tests"
+   help
+ Compile the BMan self-test code. These tests will
+ exercise the BMan APIs to confirm functionality
+ of both the software drivers and hardware device.
+
+config FSL_BMAN_TEST_API
+   bool "High-level API self-test"
+   depends on FSL_BMAN_TEST
+   default y
+   help
+ This requires the presence of cpu-affine portals, and performs
+ high-level API testing with them (whichever portal(s) are affine
+ to the cpu(s) the test executes on).
+
 endif # FSL_DPAA
diff --git a/drivers/soc/fsl/qbman/Makefile b/drivers/soc/fsl/qbman/Makefile
index 6e0ee30..714dd97 100644
--- a/drivers/soc/fsl/qbman/Makefile
+++ b/drivers/soc/fsl/qbman/Makefile
@@ -1,3 +1,7 @@
 obj-$(CONFIG_FSL_DPAA)  += bman_ccsr.o qman_ccsr.o \
   bman_portal.o qman_portal.o \
   bman.o qman.o
+
+obj-$(CONFIG_FSL_BMAN_TEST) += bman-test.o
+bman-test-y  = bman_test.o
+bman-test-$(CONFIG_FSL_BMAN_TEST_API)   += bman_test_api.o
diff --git a/drivers/soc/fsl/qbman/bman_test.c 
b/drivers/soc/fsl/qbman/bman_test.c
new file mode 100644
index 000..09b1c96
--- /dev/null
+++ b/drivers/soc/fsl/qbman/bman_test.c
@@ -0,0 +1,53 @@
+/* Copyright 2008 - 2016 Freescale Semiconductor, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in the
+ *  documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *  names of its contributors may be used to endorse or promote products
+ *  derived from this software without specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "bman_test.h"
+
+MODULE_AUTHOR("Geoff Thorpe");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_DESCRIPTION("BMan testing");
+
+static int test_init(void)
+{
+#ifdef CONFIG_FSL_BMAN_TEST_API
+   int loop = 1;
+
+   while (loop--)
+   bman_test_api();
+#endif
+   return 0;
+}
+
+static void test_exit(void)
+{
+}
+
+module_init(test_init);
+module_exit(test_exit);
diff --git a/drivers/soc/fsl/qbman/bman_test.h 
b/drivers/soc/fsl/qbman/bman_test.h
new file mode 100644
index 000..037ed34
--- /dev/null
+++ b/drivers/soc/fsl/qbman/bman_test.h
@@ -0,0 +1,35 @@
+/* Copyright 

[PATCH 45/57] perf c2c report: Add global stats stdio output

2016-09-22 Thread Jiri Olsa
Display global stats table as part of the stdio output
or when --stats option is speicified:

  $ perf c2c report --stats
  =
  Trace Event Information
  =
Total records :  41237
Locked Load/Store Operations  :   4075
Load Operations   :  20526
Loads - uncacheable   :  0
Loads - IO:  0
Loads - Miss  :552
Loads - no mapping: 31
Load Fill Buffer Hit  :   7333
Load L1D hit  :   6398
Load L2D hit  :144
Load LLC hit  :   4889
Load Local HITM   :   1185
Load Remote HITM  :838
Load Remote HIT   : 52
Load Local DRAM   :183
Load Remote DRAM  :106
Load MESI State Exclusive :289
Load MESI State Shared:  0
Load LLC Misses   :   1179
LLC Misses to Local DRAM  :   15.5%
LLC Misses to Remote DRAM :9.0%
LLC Misses to Remote cache (HIT)  :4.4%
LLC Misses to Remote cache (HITM) :   71.1%
Store Operations  :  20711
Store - uncacheable   :  0
Store - no mapping:  1
Store L1D Hit :  20158
Store L1D Miss:552
No Page Map Rejects   :  7
Unable to parse data source   :  0

Original-patch-by: Dick Fowles 
Original-patch-by: Don Zickus 
Link: http://lkml.kernel.org/n/tip-qkyvao3qsrnwazf0w1jvs...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 56 
 1 file changed, 56 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index a89aa8408c45..49a3af556fa4 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -55,6 +55,7 @@ struct perf_c2c {
 
bool show_src;
bool use_stdio;
+   bool stats_only;
 };
 
 static struct perf_c2c c2c;
@@ -1728,6 +1729,51 @@ static int setup_nodes(struct perf_session *session)
return 0;
 }
 
+static void print_c2c__display_stats(FILE *out)
+{
+   int llc_misses;
+   struct c2c_stats *stats = 
+
+   llc_misses = stats->lcl_dram +
+stats->rmt_dram +
+stats->rmt_hit +
+stats->rmt_hitm;
+
+   fprintf(out, "=\n");
+   fprintf(out, "Trace Event Information  \n");
+   fprintf(out, "=\n");
+   fprintf(out, "  Total records : %10d\n", 
stats->nr_entries);
+   fprintf(out, "  Locked Load/Store Operations  : %10d\n", 
stats->locks);
+   fprintf(out, "  Load Operations   : %10d\n", 
stats->load);
+   fprintf(out, "  Loads - uncacheable   : %10d\n", 
stats->ld_uncache);
+   fprintf(out, "  Loads - IO: %10d\n", 
stats->ld_io);
+   fprintf(out, "  Loads - Miss  : %10d\n", 
stats->ld_miss);
+   fprintf(out, "  Loads - no mapping: %10d\n", 
stats->ld_noadrs);
+   fprintf(out, "  Load Fill Buffer Hit  : %10d\n", 
stats->ld_fbhit);
+   fprintf(out, "  Load L1D hit  : %10d\n", 
stats->ld_l1hit);
+   fprintf(out, "  Load L2D hit  : %10d\n", 
stats->ld_l2hit);
+   fprintf(out, "  Load LLC hit  : %10d\n", 
stats->ld_llchit + stats->lcl_hitm);
+   fprintf(out, "  Load Local HITM   : %10d\n", 
stats->lcl_hitm);
+   fprintf(out, "  Load Remote HITM  : %10d\n", 
stats->rmt_hitm);
+   fprintf(out, "  Load Remote HIT   : %10d\n", 
stats->rmt_hit);
+   fprintf(out, "  Load Local DRAM   : %10d\n", 
stats->lcl_dram);
+   fprintf(out, "  Load Remote DRAM  : %10d\n", 
stats->rmt_dram);
+   fprintf(out, "  Load MESI State Exclusive : %10d\n", 
stats->ld_excl);
+   fprintf(out, "  Load MESI State Shared: %10d\n", 
stats->ld_shared);
+   fprintf(out, "  Load LLC Misses   : %10d\n", 
llc_misses);
+   fprintf(out, "  LLC Misses to Local DRAM  : %10.1f%%\n", 
((double)stats->lcl_dram/(double)llc_misses) * 100.);
+   fprintf(out, "  LLC Misses to Remote DRAM : %10.1f%%\n", 

[PATCH 49/57] perf c2c report: Limit the cachelines table entries

2016-09-22 Thread Jiri Olsa
Add a limit for entries number of the cachelines table
entries. By default now it's the 0.0005% minimum of
remote HITMs.

Also display only cachelines with remote hitm or store data.

Link: http://lkml.kernel.org/n/tip-inykbom2f19difvsu1e18...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 36 ++--
 tools/perf/util/hist.c   |  1 +
 tools/perf/util/hist.h   |  1 +
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 31e311959480..ff89c0b86c44 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -1639,11 +1639,42 @@ static int c2c_hists__reinit(struct c2c_hists 
*c2c_hists,
return hpp_list__parse(_hists->list, output, sort);
 }
 
-static int filter_cb(struct hist_entry *he __maybe_unused)
+#define DISPLAY_LINE_LIMIT  0.0005
+
+static bool he__display(struct hist_entry *he, struct c2c_stats *stats)
+{
+   struct c2c_hist_entry *c2c_he;
+   double ld_dist;
+
+   c2c_he = container_of(he, struct c2c_hist_entry, he);
+
+   if (stats->rmt_hitm) {
+   ld_dist = ((double)c2c_he->stats.rmt_hitm / stats->rmt_hitm);
+   if (ld_dist < DISPLAY_LINE_LIMIT)
+   he->filtered = HIST_FILTER__C2C;
+   } else {
+   he->filtered = HIST_FILTER__C2C;
+   }
+
+   return he->filtered == 0;
+}
+
+static inline int valid_hitm_or_store(struct hist_entry *he)
+{
+   struct c2c_hist_entry *c2c_he;
+
+   c2c_he = container_of(he, struct c2c_hist_entry, he);
+   return c2c_he->stats.rmt_hitm || c2c_he->stats.store;
+}
+
+static int filter_cb(struct hist_entry *he)
 {
if (c2c.show_src && !he->srcline)
he->srcline = hist_entry__get_srcline(he);
 
+   if (!valid_hitm_or_store(he))
+   he->filtered = HIST_FILTER__C2C;
+
return 0;
 }
 
@@ -1651,11 +1682,12 @@ static int resort_cl_cb(struct hist_entry *he)
 {
struct c2c_hist_entry *c2c_he;
struct c2c_hists *c2c_hists;
+   bool display = he__display(he, _stats);
 
c2c_he = container_of(he, struct c2c_hist_entry, he);
c2c_hists = c2c_he->hists;
 
-   if (c2c_hists) {
+   if (display && c2c_hists) {
c2c_hists__reinit(c2c_hists,
"percent_rmt_hitm,"
"percent_lcl_hitm,"
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index b02992efb513..e1be4132054d 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -1195,6 +1195,7 @@ static void hist_entry__check_and_remove_filter(struct 
hist_entry *he,
case HIST_FILTER__GUEST:
case HIST_FILTER__HOST:
case HIST_FILTER__SOCKET:
+   case HIST_FILTER__C2C:
default:
return;
}
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 9928fed8bc59..d4b6514eeef5 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -22,6 +22,7 @@ enum hist_filter {
HIST_FILTER__GUEST,
HIST_FILTER__HOST,
HIST_FILTER__SOCKET,
+   HIST_FILTER__C2C,
 };
 
 enum hist_column {
-- 
2.7.4



[PATCH 51/57] perf c2c report: Allow to set cacheline sort fields

2016-09-22 Thread Jiri Olsa
Allowing user to configure the way the single cacheline
data are sorted after being sorted by offset.

Adding 'c' option to specify sorting fields for single cacheline:

-c, --coalesce 
  coalesce fields: pid,tid,iaddr,dso

It's allowed to use following combination of fields:
  pid   - process pid
  tid   - process tid
  iaddr - code address
  dso   - shared object

Link: http://lkml.kernel.org/n/tip-aka8z31umxoq2gqr5mjd8...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 119 ---
 1 file changed, 102 insertions(+), 17 deletions(-)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 771991cf6946..ee64537493ce 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -46,6 +46,8 @@ struct c2c_hist_entry {
struct hist_entry   he;
 };
 
+static char const *coalesce_default = "pid,tid,iaddr";
+
 struct perf_c2c {
struct perf_tooltool;
struct c2c_histshists;
@@ -65,6 +67,11 @@ struct perf_c2c {
int shared_clines;
 
int  display;
+
+   const char  *coalesce;
+   char*cl_sort;
+   char*cl_resort;
+   char*cl_output;
 };
 
 enum {
@@ -237,7 +244,7 @@ static int process_sample_event(struct perf_tool *tool 
__maybe_unused,
if (!mi_dup)
goto free_mi;
 
-   c2c_hists = he__get_c2c_hists(he, "offset", 2);
+   c2c_hists = he__get_c2c_hists(he, c2c.cl_sort, 2);
if (!c2c_hists)
goto free_mi_dup;
 
@@ -1736,22 +1743,7 @@ static int resort_cl_cb(struct hist_entry *he)
c2c_hists = c2c_he->hists;
 
if (display && c2c_hists) {
-   c2c_hists__reinit(c2c_hists,
-   "percent_rmt_hitm,"
-   "percent_lcl_hitm,"
-   "percent_stores_l1hit,"
-   "percent_stores_l1miss,"
-   "offset,"
-   "pid,"
-   "tid,"
-   "mean_rmt,"
-   "mean_lcl,"
-   "mean_load,"
-   "cpucnt,"
-   "symbol,"
-   "dso,"
-   "node",
-   "offset,rmt_hitm,lcl_hitm");
+   c2c_hists__reinit(c2c_hists, c2c.cl_output, c2c.cl_resort);
 
hists__collapse_resort(_hists->hists, NULL);
hists__output_resort_cb(_hists->hists, NULL, filter_cb);
@@ -1995,6 +1987,7 @@ static void print_c2c_info(FILE *out, struct perf_session 
*session)
}
fprintf(out, "  Cachelines sort on: %s HITMs\n",
c2c.display == DISPLAY_LCL ? "Local" : "Remote");
+   fprintf(out, "  Cacheline data grouping   : %s\n", c2c.cl_sort);
 }
 
 static void perf_c2c__hists_fprintf(FILE *out, struct perf_session *session)
@@ -2274,6 +2267,89 @@ static int setup_display(const char *str)
return 0;
 }
 
+#define for_each_token(__tok, __buf, __sep, __tmp) \
+   for (__tok = strtok_r(__buf, __sep, &__tmp); __tok; \
+__tok = strtok_r(NULL,  __sep, &__tmp))
+
+static int build_cl_output(char *cl_sort)
+{
+   char *tok, *tmp, *buf = strdup(cl_sort);
+   bool add_pid   = false;
+   bool add_tid   = false;
+   bool add_iaddr = false;
+   bool add_sym   = false;
+   bool add_dso   = false;
+   bool add_src   = false;
+
+   if (!buf)
+   return -ENOMEM;
+
+   for_each_token(tok, buf, ",", tmp) {
+   if (!strcmp(tok, "tid")) {
+   add_tid = true;
+   } else if (!strcmp(tok, "pid")) {
+   add_pid = true;
+   } else if (!strcmp(tok, "iaddr")) {
+   add_iaddr = true;
+   add_sym   = true;
+   add_dso   = true;
+   add_src   = true;
+   } else if (!strcmp(tok, "dso")) {
+   add_dso = true;
+   } else if (strcmp(tok, "offset")) {
+   pr_err("unrecognized sort token: %s\n", tok);
+   return -EINVAL;
+   }
+   }
+
+   if (asprintf(_output,
+   "%s%s%s%s%s%s%s%s%s",
+   "percent_rmt_hitm,"
+   "percent_lcl_hitm,"
+   "percent_stores_l1hit,"
+   "percent_stores_l1miss,"
+   "offset,",
+   add_pid   ? "pid," : "",
+   add_tid   ? "tid," : "",
+   add_iaddr ? "iaddr," : "",
+   "mean_rmt,"
+   "mean_lcl,"
+   "mean_load,"
+   "cpucnt,",
+   add_sym ? "symbol," : "",
+  

[PATCH 53/57] perf c2c report: Add cacheline index entry

2016-09-22 Thread Jiri Olsa
It's convenient to have an index for each cacheline to
help discussions about results over the phone.

Add new 'Index' and 'Num' fields in main and single
cacheline tables.

$ perf c2c report
  =
 Shared Data Cache Line Table
  =
  #
  #  Total  Lcl  - LLC Load Hitm -
  # Index   Cacheline  records HitmTotal  Lcl  Rmt  ...
  # .  ..  ...  ...  ...  ...  ...
  #
0  0x880036233b401   11.11%110
1  0x88009ccb29001   11.11%110
2  0x8800b5b3bc407   11.11%110
  ...

  =
Shared Cache Line Distribution Pareto
  =
  #
  #- HITM -  -- Store Refs --Data address
  #   Num  Rmt  Lcl   L1 Hit  L1 Miss  Offset  Pid  ...
  # .  ...  ...  ...  ...  ..  ...
  #
-
00100  0x880036233b40
-
 0.00%  100.00%0.00%0.00%0x300

-
10100  0x88009ccb2900
-
 0.00%  100.00%0.00%0.00%0x28  549
  ...

Link: http://lkml.kernel.org/n/tip-4dhfagaz57tvrfjbg8nd2...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 64 +---
 1 file changed, 61 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index c7fe81d49016..f39947d29765 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -36,6 +36,7 @@ struct c2c_hist_entry {
struct c2c_stats stats;
unsigned long   *cpuset;
struct c2c_stats*node_stats;
+   unsigned int cacheline_idx;
 
struct compute_stats cstats;
 
@@ -1085,6 +1086,29 @@ cpucnt_entry(struct perf_hpp_fmt *fmt __maybe_unused, 
struct perf_hpp *hpp,
return snprintf(hpp->buf, hpp->size, "%*s", width, buf);
 }
 
+static int
+cl_idx_entry(struct perf_hpp_fmt *fmt __maybe_unused, struct perf_hpp *hpp,
+struct hist_entry *he)
+{
+   struct c2c_hist_entry *c2c_he;
+   int width = c2c_width(fmt, hpp, he->hists);
+   char buf[10];
+
+   c2c_he = container_of(he, struct c2c_hist_entry, he);
+
+   snprintf(buf, 10, "%u", c2c_he->cacheline_idx);
+   return snprintf(hpp->buf, hpp->size, "%*s", width, buf);
+}
+
+static int
+cl_idx_empty_entry(struct perf_hpp_fmt *fmt __maybe_unused, struct perf_hpp 
*hpp,
+  struct hist_entry *he)
+{
+   int width = c2c_width(fmt, hpp, he->hists);
+
+   return snprintf(hpp->buf, hpp->size, "%*s", width, "");
+}
+
 #define HEADER_LOW(__h)\
{   \
.line[1] = {\
@@ -1430,6 +1454,30 @@ static struct c2c_dimension dim_srcline = {
.se = _srcline,
 };
 
+static struct c2c_dimension dim_dcacheline_idx = {
+   .header = HEADER_LOW("Index"),
+   .name   = "cl_idx",
+   .cmp= empty_cmp,
+   .entry  = cl_idx_entry,
+   .width  = 5,
+};
+
+static struct c2c_dimension dim_dcacheline_num = {
+   .header = HEADER_LOW("Num"),
+   .name   = "cl_num",
+   .cmp= empty_cmp,
+   .entry  = cl_idx_entry,
+   .width  = 5,
+};
+
+static struct c2c_dimension dim_dcacheline_num_empty = {
+   .header = HEADER_LOW("Num"),
+   .name   = "cl_num_empty",
+   .cmp= empty_cmp,
+   .entry  = cl_idx_empty_entry,
+   .width  = 5,
+};
+
 static struct c2c_dimension *dimensions[] = {
_dcacheline,
_offset,
@@ -1469,6 +1517,9 @@ static struct c2c_dimension *dimensions[] = {
_mean_load,
_cpucnt,
_srcline,
+   _dcacheline_idx,
+   _dcacheline_num,
+   _dcacheline_num_empty,
NULL,
 };
 
@@ -1755,6 +1806,10 @@ static int resort_cl_cb(struct hist_entry *he)
calc_width(he);
 
if (display && c2c_hists) {
+   static unsigned int idx;
+
+   c2c_he->cacheline_idx = idx++;
+
c2c_hists__reinit(c2c_hists, c2c.cl_output, c2c.cl_resort);
 
hists__collapse_resort(_hists->hists, NULL);
@@ -1942,10 +1997,10 @@ static void 

Re: [PATCH] Bluetooth: Add a new 04ca:3011 QCA_ROME device

2016-09-22 Thread Marcel Holtmann
Hi Dmitry,

> BugLink: https://bugs.launchpad.net/bugs/1535802
> 
> T:  Bus=01 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
> D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
> P:  Vendor=04ca ProdID=3011 Rev=00.01
> C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> 
> Signed-off-by: Dmitry Tunin 
> Cc: sta...@vger.kernel.org
> ---
> drivers/bluetooth/btusb.c | 1 +
> 1 file changed, 1 insertion(+)

patch has been applied to bluetooth-next tree.

Regards

Marcel



[PATCH 37/57] perf c2c report: Add stats related sort keys

2016-09-22 Thread Jiri Olsa
Adding statistic dimension key wrapper.

It is to be displayed in the single cacheline output:

  median, mean_rmt, mean_lcl, mean_load, stddev

It displays statistics hits related to cacheline accesses.

Link: http://lkml.kernel.org/n/tip-m1r4uc9lcykf1jhpvwk2g...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 80 
 1 file changed, 80 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 3ffe051f377d..5d42f7912450 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -20,11 +20,20 @@ struct c2c_hists {
struct c2c_statsstats;
 };
 
+struct compute_stats {
+   struct stats lcl_hitm;
+   struct stats rmt_hitm;
+   struct stats load;
+};
+
 struct c2c_hist_entry {
struct c2c_hists*hists;
struct c2c_stats stats;
unsigned long   *cpuset;
struct c2c_stats*node_stats;
+
+   struct compute_stats cstats;
+
/*
 * must be at the end,
 * because of its callchain dynamic entry
@@ -61,6 +70,10 @@ static void *c2c_he_zalloc(size_t size)
if (!c2c_he->node_stats)
return NULL;
 
+   init_stats(_he->cstats.lcl_hitm);
+   init_stats(_he->cstats.rmt_hitm);
+   init_stats(_he->cstats.load);
+
return _he->he;
 }
 
@@ -120,6 +133,20 @@ static void c2c_he__set_cpu(struct c2c_hist_entry *c2c_he,
set_bit(sample->cpu, c2c_he->cpuset);
 }
 
+static void compute_stats(struct c2c_hist_entry *c2c_he,
+ struct c2c_stats *stats,
+ u64 weight)
+{
+   struct compute_stats *cstats = _he->cstats;
+
+   if (stats->rmt_hitm)
+   update_stats(>rmt_hitm, weight);
+   else if (stats->lcl_hitm)
+   update_stats(>lcl_hitm, weight);
+   else if (stats->load)
+   update_stats(>load, weight);
+}
+
 static int process_sample_event(struct perf_tool *tool __maybe_unused,
union perf_event *event,
struct perf_sample *sample,
@@ -198,6 +225,8 @@ static int process_sample_event(struct perf_tool *tool 
__maybe_unused,
c2c_add_stats(_hists->stats, );
c2c_add_stats(_he->node_stats[node], );
 
+   compute_stats(c2c_he, , sample->weight);
+
c2c_he__set_cpu(c2c_he, sample);
 
hists__inc_nr_samples(_hists->hists, he->filtered);
@@ -959,6 +988,30 @@ node_entry(struct perf_hpp_fmt *fmt __maybe_unused, struct 
perf_hpp *hpp,
return 0;
 }
 
+static int
+mean_entry(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
+  struct hist_entry *he, double mean)
+{
+   int width = c2c_width(fmt, hpp, he->hists);
+   char buf[10];
+
+   snprintf(buf, 10, "%6.0f", mean);
+   return snprintf(hpp->buf, hpp->size, "%*s", width, buf);
+}
+
+#define MEAN_ENTRY(__func, __val)  
\
+static int 
\
+__func(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp, struct hist_entry *he)  
\
+{  
\
+   struct c2c_hist_entry *c2c_he;  
\
+   c2c_he = container_of(he, struct c2c_hist_entry, he);   
\
+   return mean_entry(fmt, hpp, he, avg_stats(_he->cstats.__val));  
\
+}
+
+MEAN_ENTRY(mean_rmt_entry,  rmt_hitm);
+MEAN_ENTRY(mean_lcl_entry,  lcl_hitm);
+MEAN_ENTRY(mean_load_entry, load);
+
 #define HEADER_LOW(__h)\
{   \
.line[1] = {\
@@ -1261,6 +1314,30 @@ static struct c2c_dimension dim_node = {
.width  = 4,
 };
 
+static struct c2c_dimension dim_mean_rmt = {
+   .header = HEADER_SPAN("-- cycles --", "rmt 
hitm", 2),
+   .name   = "mean_rmt",
+   .cmp= empty_cmp,
+   .entry  = mean_rmt_entry,
+   .width  = 8,
+};
+
+static struct c2c_dimension dim_mean_lcl = {
+   .header = HEADER_SPAN_LOW("lcl hitm"),
+   .name   = "mean_lcl",
+   .cmp= empty_cmp,
+   .entry  = mean_lcl_entry,
+   .width  = 8,
+};
+
+static struct c2c_dimension dim_mean_load = {
+   .header = HEADER_SPAN_LOW("load"),
+   .name   = "mean_load",
+   .cmp= empty_cmp,
+   .entry  = mean_load_entry,
+   .width  = 8,
+};
+
 static struct c2c_dimension *dimensions[] = {
_dcacheline,
_offset,
@@ -1295,6 +1372,9 @@ static struct c2c_dimension *dimensions[] = {
_symbol,
_dso,
_node,
+   _mean_rmt,
+   _mean_lcl,
+   

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

2016-09-22 Thread zhichang.yuan


On 09/22/2016 11:20 PM, Gabriele Paoloni wrote:



-Original Message-
From: Arnd Bergmann [mailto:a...@arndb.de]
Sent: 22 September 2016 15:59
To: Gabriele Paoloni
Cc: zhichang; linux-arm-ker...@lists.infradead.org;
devicet...@vger.kernel.org; lorenzo.pieral...@arm.com; miny...@acm.org;
linux-...@vger.kernel.org; gre...@linuxfoundation.org; John Garry;
will.dea...@arm.com; linux-kernel@vger.kernel.org; Yuanzhichang;
Linuxarm; xuwei (O); linux-ser...@vger.kernel.org;
b...@kernel.crashing.org; zourongr...@gmail.com; liviu.du...@arm.com;
kant...@163.com
Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on
Hip06

On Thursday, September 22, 2016 2:47:14 PM CEST Gabriele Paoloni wrote:

  static int of_empty_ranges_quirk(struct device_node *np)
  {
 if (IS_ENABLED(CONFIG_PPC)) {
@@ -503,7 +512,7 @@ static int of_translate_one(struct

device_node

*parent, struct of_bus *bus,

  * This code is only enabled on powerpc. --gcl
  */
 ranges = of_get_property(parent, rprop, );
-   if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
+   if (ranges == NULL && !of_empty_ranges_quirk(parent) &&

!of_isa_indirect_io(parent)) {

 pr_debug("OF: no ranges; cannot translate\n");
 return 1;
 }

I don't see what effect that would have. What do you want to
achieve with this?

If I read the code correctly adding the function above would end
up in a 1:1 mapping:
http://lxr.free-electrons.com/source/drivers/of/address.c#L513

so taddr will be assigned with the cpu address space specified
in the children nodes of LPC and we are not using a quirk function
(we are just checking that we have the indirect io assigned and
that we are on a ISA bus). Now probably there is a nit in my
code sketch where of_isa_indirect_io should be probably an

architecture

specific function...

But the point is that it would then return an incorrect address,
which in the worst case could be the same as another I/O space
if that happens to be at CPU address zero.

If we do not touch __of_address_to_resource after taddr is returned
by of_translate_address we will check for (flags & IORESOURCE_IO),
then we call pci_address_to_pio to retrieve the unique token (remember
that LPC driver will register the LPC io range to pci io_range_list).

I do not think that we can have any conflict with any other I/O space
as pci_register_io_range will guarantee that the LPC range does not
overlap with any other I/O range...
If we don't bypass the calling of pci_address_to_pio after 
of_translate_address,
there should no conflict between LPC logical IO range and other logical 
IO ranges

of other devices.
I guess Arnd want to skip all the translation for our LPC IO address. 
But if we do it
like that, it seems we can't avoid the possible conflict with the 
logical IO ranges of
PCI host bridges without any changes on the pci_register_io_range and 
pci_address_to_pio.
Because two completely separate I/O spaces are created without 
synchronization.


Best,
Zhichang

I think all we need from this function is to return '1' if
we hit an ISA I/O window, and that should happen for the two
interesting cases, either no 'ranges' at all, or no translation
for the range in question, so that __of_translate_address can
return OF_BAD_ADDR, and we can enter the special case
handling in the caller, that handles it like


I don't think this is very right as you may fail for different
reasons other than a missing range property, e.g:
http://lxr.free-electrons.com/source/drivers/of/address.c#L575

And even if the only failure case was a missing range if in the
future __of_translate_address had to be reworked we would again
make a wrong assumption...you get my point?

The newly introduced function would clearly have to make
some sanity checks. The idea is that treat the case of
not being able to translate a bus specific I/O address
into a CPU address literally and fall back to another method
of translating that address.

This matches my mental model of how we find the resource:

- start with the bus address
- try to translate that into a CPU address
- if we arrive at a CPU physical address for IORESOURCE_MEM, use that
- if we arrive at a CPU physical address for IORESOURCE_IO, translate
   that into a Linux IORESOURCE_IO token
- if there is no valid CPU physical address, try to translate
   the address into an IORESOURCE_IO using the ISA accessor
- if that fails too, give up.

If you try to fake a CPU physical address inbetween, it just
gets more confusing.

Arnd




[PATCH 36/57] perf c2c report: Add node sort key

2016-09-22 Thread Jiri Olsa
Adding node dimension key wrapper.

It is to be displayed in the single cacheline output:

  node

It displays nodes hits related to cacheline accesses.

The node filed comes in 3 flavors:
  - node IDs separated by ','
  - node IDs with stats for each ID, in following format:
  Node{cpus %hitms %stores}
  - node IDs with list of affected CPUs in following format:
  Node{cpu list}

User can switch the flavor with -N option (-NN,-NNN).
It will be available in TUI to switch this with 'n' key.

Link: http://lkml.kernel.org/n/tip-6742e6g0r7n63y5wc4rrg...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 219 +++
 1 file changed, 219 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index eba46b94b69e..3ffe051f377d 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "util.h"
 #include "debug.h"
 #include "builtin.h"
@@ -22,6 +23,8 @@ struct c2c_hists {
 struct c2c_hist_entry {
struct c2c_hists*hists;
struct c2c_stats stats;
+   unsigned long   *cpuset;
+   struct c2c_stats*node_stats;
/*
 * must be at the end,
 * because of its callchain dynamic entry
@@ -32,6 +35,12 @@ struct c2c_hist_entry {
 struct perf_c2c {
struct perf_tooltool;
struct c2c_histshists;
+
+   unsigned long   **nodes;
+   int  nodes_cnt;
+   int  cpus_cnt;
+   int *cpu2node;
+   int  node_info;
 };
 
 static struct perf_c2c c2c;
@@ -44,6 +53,14 @@ static void *c2c_he_zalloc(size_t size)
if (!c2c_he)
return NULL;
 
+   c2c_he->cpuset = bitmap_alloc(c2c.cpus_cnt);
+   if (!c2c_he->cpuset)
+   return NULL;
+
+   c2c_he->node_stats = zalloc(c2c.nodes_cnt * 
sizeof(*c2c_he->node_stats));
+   if (!c2c_he->node_stats)
+   return NULL;
+
return _he->he;
 }
 
@@ -57,6 +74,8 @@ static void c2c_he_free(void *he)
free(c2c_he->hists);
}
 
+   free(c2c_he->cpuset);
+   free(c2c_he->node_stats);
free(c2c_he);
 }
 
@@ -91,6 +110,16 @@ he__get_c2c_hists(struct hist_entry *he,
return hists;
 }
 
+static void c2c_he__set_cpu(struct c2c_hist_entry *c2c_he,
+   struct perf_sample *sample)
+{
+   if (WARN_ONCE(sample->cpu == (unsigned int) -1,
+ "WARNING: no sample cpu value"))
+   return;
+
+   set_bit(sample->cpu, c2c_he->cpuset);
+}
+
 static int process_sample_event(struct perf_tool *tool __maybe_unused,
union perf_event *event,
struct perf_sample *sample,
@@ -131,10 +160,23 @@ static int process_sample_event(struct perf_tool *tool 
__maybe_unused,
c2c_add_stats(_he->stats, );
c2c_add_stats(_hists->stats, );
 
+   c2c_he__set_cpu(c2c_he, sample);
+
hists__inc_nr_samples(_hists->hists, he->filtered);
ret = hist_entry__append_callchain(he, sample);
 
if (!ret) {
+   /*
+* There's already been warning about missing
+* sample's cpu value. Let's account all to
+* node 0 in this case, without any further
+* warning.
+*
+* Doing node stats only for single callchain data.
+*/
+   int cpu = sample->cpu == (unsigned int) -1 ? 0 : sample->cpu;
+   int node = c2c.cpu2node[cpu];
+
mi = mi_dup;
 
mi_dup = memdup(mi, sizeof(*mi));
@@ -154,6 +196,9 @@ static int process_sample_event(struct perf_tool *tool 
__maybe_unused,
c2c_he = container_of(he, struct c2c_hist_entry, he);
c2c_add_stats(_he->stats, );
c2c_add_stats(_hists->stats, );
+   c2c_add_stats(_he->node_stats[node], );
+
+   c2c_he__set_cpu(c2c_he, sample);
 
hists__inc_nr_samples(_hists->hists, he->filtered);
ret = hist_entry__append_callchain(he, sample);
@@ -823,6 +868,97 @@ pid_cmp(struct perf_hpp_fmt *fmt __maybe_unused,
return left->thread->pid_ - right->thread->pid_;
 }
 
+static int64_t
+empty_cmp(struct perf_hpp_fmt *fmt __maybe_unused,
+ struct hist_entry *left __maybe_unused,
+ struct hist_entry *right __maybe_unused)
+{
+   return 0;
+}
+
+static int
+node_entry(struct perf_hpp_fmt *fmt __maybe_unused, struct perf_hpp *hpp,
+  struct hist_entry *he)
+{
+   struct c2c_hist_entry *c2c_he;
+   bool first = true;
+   int node;
+   int ret = 0;
+
+   c2c_he = container_of(he, struct c2c_hist_entry, he);
+
+   for (node = 0; node < c2c.nodes_cnt; node++) {
+  

[PATCH 34/57] perf c2c report: Add tid sort key

2016-09-22 Thread Jiri Olsa
Adding tid dimension key wrapper.

It is to be displayed in the single cacheline output:

  tid

It's a wrapper for global sort_thread sort entry with
c2c specific header.

Link: http://lkml.kernel.org/n/tip-fr0socae5skzvz5qbkl85...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 20b5e7f64412..55a5a2eadfe8 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -1095,6 +1095,12 @@ static struct c2c_dimension dim_pid = {
.width  = 7,
 };
 
+static struct c2c_dimension dim_tid = {
+   .header = HEADER_LOW("Tid"),
+   .name   = "tid",
+   .se = _thread,
+};
+
 static struct c2c_dimension *dimensions[] = {
_dcacheline,
_offset,
@@ -1125,6 +1131,7 @@ static struct c2c_dimension *dimensions[] = {
_dram_lcl,
_dram_rmt,
_pid,
+   _tid,
NULL,
 };
 
-- 
2.7.4



[PATCH 33/57] perf c2c report: Add pid sort key

2016-09-22 Thread Jiri Olsa
Adding pid dimension key wrapper.

It is to be displayed in the single cacheline output:

  pid

We currently don't have a single 'pid' sort/display entry,
which would output just pid number, hence adding it into
c2c code.

Link: http://lkml.kernel.org/n/tip-3o23qrspxc99b04ci1swl...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 030a33a93caf..20b5e7f64412 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -807,6 +807,22 @@ percent_stores_l1miss_cmp(struct perf_hpp_fmt *fmt 
__maybe_unused,
 STAT_FN(lcl_dram)
 STAT_FN(rmt_dram)
 
+static int
+pid_entry(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
+ struct hist_entry *he)
+{
+   int width = c2c_width(fmt, hpp, he->hists);
+
+   return snprintf(hpp->buf, hpp->size, "%*d", width, he->thread->pid_);
+}
+
+static int64_t
+pid_cmp(struct perf_hpp_fmt *fmt __maybe_unused,
+   struct hist_entry *left, struct hist_entry *right)
+{
+   return left->thread->pid_ - right->thread->pid_;
+}
+
 #define HEADER_LOW(__h)\
{   \
.line[1] = {\
@@ -1071,6 +1087,14 @@ static struct c2c_dimension dim_dram_rmt = {
.width  = 8,
 };
 
+static struct c2c_dimension dim_pid = {
+   .header = HEADER_LOW("Pid"),
+   .name   = "pid",
+   .cmp= pid_cmp,
+   .entry  = pid_entry,
+   .width  = 7,
+};
+
 static struct c2c_dimension *dimensions[] = {
_dcacheline,
_offset,
@@ -1100,6 +1124,7 @@ static struct c2c_dimension *dimensions[] = {
_percent_stores_l1miss,
_dram_lcl,
_dram_rmt,
+   _pid,
NULL,
 };
 
-- 
2.7.4



[PATCH 25/57] perf c2c report: Add loads related dimension keys

2016-09-22 Thread Jiri Olsa
Adding 3 loads related dimension key wrappers.

They are to be displayed in the main cachelines
overall output:

  ld_fbhit, ld_l1hit, ld_l2hit

They all display bare numbers of loads for
FB (Fill Buffer), L1 and L2 cache.

Link: http://lkml.kernel.org/n/tip-wxrzhy74zl8fvkvgjae3w...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 7c62a749eaca..698afbf6330f 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -412,6 +412,9 @@ STAT_FN(lcl_hitm)
 STAT_FN(store)
 STAT_FN(st_l1hit)
 STAT_FN(st_l1miss)
+STAT_FN(ld_fbhit)
+STAT_FN(ld_l1hit)
+STAT_FN(ld_l2hit)
 
 #define HEADER_LOW(__h)\
{   \
@@ -552,6 +555,30 @@ static struct c2c_dimension dim_cl_stores_l1miss = {
.width  = 7,
 };
 
+static struct c2c_dimension dim_ld_fbhit = {
+   .header = HEADER_SPAN("- Core Load Hit -", "FB", 2),
+   .name   = "ld_fbhit",
+   .cmp= ld_fbhit_cmp,
+   .entry  = ld_fbhit_entry,
+   .width  = 7,
+};
+
+static struct c2c_dimension dim_ld_l1hit = {
+   .header = HEADER_SPAN_LOW("L1"),
+   .name   = "ld_l1hit",
+   .cmp= ld_l1hit_cmp,
+   .entry  = ld_l1hit_entry,
+   .width  = 7,
+};
+
+static struct c2c_dimension dim_ld_l2hit = {
+   .header = HEADER_SPAN_LOW("L2"),
+   .name   = "ld_l2hit",
+   .cmp= ld_l2hit_cmp,
+   .entry  = ld_l2hit_entry,
+   .width  = 7,
+};
+
 static struct c2c_dimension *dimensions[] = {
_dcacheline,
_offset,
@@ -566,6 +593,9 @@ static struct c2c_dimension *dimensions[] = {
_stores_l1miss,
_cl_stores_l1hit,
_cl_stores_l1miss,
+   _ld_fbhit,
+   _ld_l1hit,
+   _ld_l2hit,
NULL,
 };
 
-- 
2.7.4



[PATCH 30/57] perf c2c report: Add hitm percent sort key

2016-09-22 Thread Jiri Olsa
Adding HITM percent dimension key wrapper.

It is to be displayed in the main cachelines
overall output:

  percent_hitm

It displays HITMs percentage for cacheline.

It counts remote HITMs at the moment, but it
is changed later to support local as well,
based on the sort configuration.

Link: http://lkml.kernel.org/n/tip-czd17qsh5u5z0yc1estz9...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 87 
 1 file changed, 87 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 11b3db91fce9..e24472f100c6 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -562,6 +562,83 @@ tot_loads_cmp(struct perf_hpp_fmt *fmt __maybe_unused,
return tot_recs_left - tot_recs_right;
 }
 
+typedef double (get_percent_cb)(struct c2c_hist_entry *);
+
+static int
+percent_color(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
+ struct hist_entry *he, get_percent_cb get_percent)
+{
+   struct c2c_hist_entry *c2c_he;
+   int width = c2c_width(fmt, hpp, he->hists);
+   double per;
+
+   c2c_he = container_of(he, struct c2c_hist_entry, he);
+   per = get_percent(c2c_he);
+
+   return hpp_color_scnprintf(hpp, "%*.2f%%", width - 1, per);
+}
+
+static double percent_hitm(struct c2c_hist_entry *c2c_he)
+{
+   struct c2c_hists *hists;
+   struct c2c_stats *stats;
+   struct c2c_stats *total;
+   int tot, st;
+   double p;
+
+   hists = container_of(c2c_he->he.hists, struct c2c_hists, hists);
+   stats = _he->stats;
+   total = >stats;
+
+   st  = stats->rmt_hitm;
+   tot = total->rmt_hitm;
+
+   p = tot ? (double) st / tot : 0;
+
+   return 100 * p;
+}
+
+static int
+percent_hitm_entry(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
+  struct hist_entry *he)
+{
+   struct c2c_hist_entry *c2c_he;
+   int width = c2c_width(fmt, hpp, he->hists);
+   char buf[10];
+   double per;
+
+   c2c_he = container_of(he, struct c2c_hist_entry, he);
+   per = percent_hitm(c2c_he);
+
+   snprintf(buf, 10, "%.2F%%", per);
+   return snprintf(hpp->buf, hpp->size, "%*s", width, buf);
+}
+
+static int
+percent_hitm_color(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
+  struct hist_entry *he)
+{
+   return percent_color(fmt, hpp, he, percent_hitm);
+}
+
+static int64_t
+percent_hitm_cmp(struct perf_hpp_fmt *fmt __maybe_unused,
+struct hist_entry *left, struct hist_entry *right)
+{
+   struct c2c_hist_entry *c2c_left;
+   struct c2c_hist_entry *c2c_right;
+   double per_left;
+   double per_right;
+
+   c2c_left  = container_of(left, struct c2c_hist_entry, he);
+   c2c_right = container_of(right, struct c2c_hist_entry, he);
+
+   per_left  = percent_hitm(c2c_left);
+   per_right = percent_hitm(c2c_right);
+
+   return per_left - per_right;
+}
+
 #define HEADER_LOW(__h)\
{   \
.line[1] = {\
@@ -765,6 +842,15 @@ static struct c2c_dimension dim_tot_loads = {
.width  = 7,
 };
 
+static struct c2c_dimension dim_percent_hitm = {
+   .header = HEADER_LOW("%hitm"),
+   .name   = "percent_hitm",
+   .cmp= percent_hitm_cmp,
+   .entry  = percent_hitm_entry,
+   .color  = percent_hitm_color,
+   .width  = 7,
+};
+
 static struct c2c_dimension *dimensions[] = {
_dcacheline,
_offset,
@@ -787,6 +873,7 @@ static struct c2c_dimension *dimensions[] = {
_ld_llcmiss,
_tot_recs,
_tot_loads,
+   _percent_hitm,
NULL,
 };
 
-- 
2.7.4



[PATCH 16/57] perf c2c report: Add sample processing

2016-09-22 Thread Jiri Olsa
Adding basic sample processing specific hist_entry
allocation callbacks (via hists__add_entry_ops).

Overloading 'struct hist_entry' object with new
'struct c2c_hist_entry'. The new hist entry object
will carry specific stats and nested hists objects.

Link: http://lkml.kernel.org/n/tip-ksr9smz4o1t040h50z28d...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 108 ++-
 1 file changed, 107 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index a3481f86e2ae..29fb9573e292 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -16,6 +16,15 @@ struct c2c_hists {
struct perf_hpp_listlist;
 };
 
+struct c2c_hist_entry {
+   struct c2c_hists*hists;
+   /*
+* must be at the end,
+* because of its callchain dynamic entry
+*/
+   struct hist_entry   he;
+};
+
 struct perf_c2c {
struct perf_tooltool;
struct c2c_histshists;
@@ -23,6 +32,86 @@ struct perf_c2c {
 
 static struct perf_c2c c2c;
 
+static void *c2c_he_zalloc(size_t size)
+{
+   struct c2c_hist_entry *c2c_he;
+
+   c2c_he = zalloc(size + sizeof(*c2c_he));
+   if (!c2c_he)
+   return NULL;
+
+   return _he->he;
+}
+
+static void c2c_he_free(void *he)
+{
+   struct c2c_hist_entry *c2c_he;
+
+   c2c_he = container_of(he, struct c2c_hist_entry, he);
+   if (c2c_he->hists) {
+   hists__delete_entries(_he->hists->hists);
+   free(c2c_he->hists);
+   }
+
+   free(c2c_he);
+}
+
+static struct hist_entry_ops c2c_entry_ops = {
+   .new= c2c_he_zalloc,
+   .free   = c2c_he_free,
+};
+
+static int process_sample_event(struct perf_tool *tool __maybe_unused,
+   union perf_event *event,
+   struct perf_sample *sample,
+   struct perf_evsel *evsel __maybe_unused,
+   struct machine *machine)
+{
+   struct hists *hists = 
+   struct hist_entry *he;
+   struct addr_location al;
+   struct mem_info *mi;
+   int ret;
+
+   if (machine__resolve(machine, , sample) < 0) {
+   pr_debug("problem processing %d event, skipping it.\n",
+event->header.type);
+   return -1;
+   }
+
+   mi = sample__resolve_mem(sample, );
+   if (mi == NULL)
+   return -ENOMEM;
+
+   he = hists__add_entry_ops(hists, _entry_ops,
+ , NULL, NULL, mi,
+ sample, true);
+   if (he == NULL) {
+   free(mi);
+   return -ENOMEM;
+   }
+
+   hists__inc_nr_samples(hists, he->filtered);
+   ret = hist_entry__append_callchain(he, sample);
+
+   addr_location__put();
+   return ret;
+}
+
+static struct perf_c2c c2c = {
+   .tool = {
+   .sample = process_sample_event,
+   .mmap   = perf_event__process_mmap,
+   .mmap2  = perf_event__process_mmap2,
+   .comm   = perf_event__process_comm,
+   .exit   = perf_event__process_exit,
+   .fork   = perf_event__process_fork,
+   .lost   = perf_event__process_lost,
+   .ordered_events = true,
+   .ordering_requires_timestamps = true,
+   },
+};
+
 static const char * const c2c_usage[] = {
"perf c2c {record|report}",
NULL
@@ -314,6 +403,7 @@ static int c2c_hists__reinit(struct c2c_hists *c2c_hists,
 static int perf_c2c__report(int argc, const char **argv)
 {
struct perf_session *session;
+   struct ui_progress prog;
struct perf_data_file file = {
.mode = PERF_DATA_MODE_READ,
};
@@ -330,9 +420,12 @@ static int perf_c2c__report(int argc, const char **argv)
 
argc = parse_options(argc, argv, c2c_options, report_c2c_usage,
 PARSE_OPT_STOP_AT_NON_OPTION);
-   if (!argc)
+   if (argc)
usage_with_options(report_c2c_usage, c2c_options);
 
+   if (!input_name || !strlen(input_name))
+   input_name = "perf.data";
+
file.path = input_name;
 
err = c2c_hists__init(, "dcacheline");
@@ -356,6 +449,19 @@ static int perf_c2c__report(int argc, const char **argv)
goto out_session;
}
 
+   err = perf_session__process_events(session);
+   if (err) {
+   pr_err("failed to process sample\n");
+   goto out_session;
+   }
+
+   ui_progress__init(, c2c.hists.hists.nr_entries, "Sorting...");
+
+   hists__collapse_resort(, NULL);
+   hists__output_resort(, );
+
+   ui_progress__finish();
+
 out_session:
perf_session__delete(session);
 out:
-- 
2.7.4



[PATCH 05/57] perf tools: Make output_field_add and sort_dimension__add global

2016-09-22 Thread Jiri Olsa
Will be used from external places in following patches.

Link: http://lkml.kernel.org/n/tip-15488tnxcj4rtteksy79y...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/sort.c | 8 
 tools/perf/util/sort.h | 4 
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 9e1f6f75a50f..9f7c1ea9e3ad 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -2308,9 +2308,9 @@ int hpp_dimension__add_output(unsigned col)
return __hpp_dimension__add_output(_hpp_list, 
_sort_dimensions[col]);
 }
 
-static int sort_dimension__add(struct perf_hpp_list *list, const char *tok,
-  struct perf_evlist *evlist,
-  int level)
+int sort_dimension__add(struct perf_hpp_list *list, const char *tok,
+   struct perf_evlist *evlist,
+   int level)
 {
unsigned int i;
 
@@ -2685,7 +2685,7 @@ void sort__setup_elide(FILE *output)
}
 }
 
-static int output_field_add(struct perf_hpp_list *list, char *tok)
+int output_field_add(struct perf_hpp_list *list, char *tok)
 {
unsigned int i;
 
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 4efadc1e98c5..e93b0fa43704 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -270,4 +270,8 @@ bool is_strict_order(const char *order);
 
 int hpp_dimension__add_output(unsigned col);
 void reset_dimensions(void);
+int sort_dimension__add(struct perf_hpp_list *list, const char *tok,
+   struct perf_evlist *evlist,
+   int level);
+int output_field_add(struct perf_hpp_list *list, char *tok);
 #endif /* __PERF_SORT_H */
-- 
2.7.4



Re: [PATCH 01/57] perf tools: Add __hist_entry__snprintf function

2016-09-22 Thread Arnaldo Carvalho de Melo
Em Thu, Sep 22, 2016 at 05:36:29PM +0200, Jiri Olsa escreveu:
> Add __hist_entry__snprintf to take perf_hpp_list as an argument
> instead of using he->hists->hpp_list. This way we can display
> arbitrary list of entries regardles of the hists setup, which
> will be useful in following patches.

Thanks, applied,

- Arnaldo


Re: [PATCH 06/57] perf tools: Make several sorting functions global

2016-09-22 Thread Arnaldo Carvalho de Melo
Em Thu, Sep 22, 2016 at 05:36:34PM +0200, Jiri Olsa escreveu:
> Will be used from external places in following patches.
> 
> Link: http://lkml.kernel.org/n/tip-4jyvw21cac7yuqsdkzdo5...@git.kernel.org
> Signed-off-by: Jiri Olsa 

Thanks, applied,

- Arnaldo


[PATCH 24/57] perf c2c report: Add stores related dimension keys

2016-09-22 Thread Jiri Olsa
Adding 5 stores related dimension key wrappers.

First 3 are to be displayed in the main cachelines
overall output:

  stores, stores_l1hit, stores_l1miss

The latter 2 are to be displayed within single
cacheline output:

  cl_stores_l1hit, cl_stores_l1miss

They all display bare numbers of stores for
cacheline or its related offsets.

Link: http://lkml.kernel.org/n/tip-qeml8v53v6q3wl5n8vgbf...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 48 
 1 file changed, 48 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 06c4d3e92ed2..7c62a749eaca 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -409,6 +409,9 @@ __f ## _cmp(struct perf_hpp_fmt *fmt __maybe_unused,
\
 
 STAT_FN(rmt_hitm)
 STAT_FN(lcl_hitm)
+STAT_FN(store)
+STAT_FN(st_l1hit)
+STAT_FN(st_l1miss)
 
 #define HEADER_LOW(__h)\
{   \
@@ -509,6 +512,46 @@ static struct c2c_dimension dim_cl_lcl_hitm = {
.width  = 7,
 };
 
+static struct c2c_dimension dim_stores = {
+   .header = HEADER_SPAN(" Store Reference ", "Total", 2),
+   .name   = "stores",
+   .cmp= store_cmp,
+   .entry  = store_entry,
+   .width  = 7,
+};
+
+static struct c2c_dimension dim_stores_l1hit = {
+   .header = HEADER_SPAN_LOW("L1Hit"),
+   .name   = "stores_l1hit",
+   .cmp= st_l1hit_cmp,
+   .entry  = st_l1hit_entry,
+   .width  = 7,
+};
+
+static struct c2c_dimension dim_stores_l1miss = {
+   .header = HEADER_SPAN_LOW("L1Miss"),
+   .name   = "stores_l1miss",
+   .cmp= st_l1miss_cmp,
+   .entry  = st_l1miss_entry,
+   .width  = 7,
+};
+
+static struct c2c_dimension dim_cl_stores_l1hit = {
+   .header = HEADER_SPAN("-- Store Refs --", "L1 Hit", 1),
+   .name   = "cl_stores_l1hit",
+   .cmp= st_l1hit_cmp,
+   .entry  = st_l1hit_entry,
+   .width  = 7,
+};
+
+static struct c2c_dimension dim_cl_stores_l1miss = {
+   .header = HEADER_SPAN_LOW("L1 Miss"),
+   .name   = "cl_stores_l1miss",
+   .cmp= st_l1miss_cmp,
+   .entry  = st_l1miss_entry,
+   .width  = 7,
+};
+
 static struct c2c_dimension *dimensions[] = {
_dcacheline,
_offset,
@@ -518,6 +561,11 @@ static struct c2c_dimension *dimensions[] = {
_rmt_hitm,
_cl_lcl_hitm,
_cl_rmt_hitm,
+   _stores,
+   _stores_l1hit,
+   _stores_l1miss,
+   _cl_stores_l1hit,
+   _cl_stores_l1miss,
NULL,
 };
 
-- 
2.7.4



Re: [PATCH 09/57] perf tools: Make hists__fprintf_headers function global

2016-09-22 Thread Arnaldo Carvalho de Melo
Em Thu, Sep 22, 2016 at 05:36:37PM +0200, Jiri Olsa escreveu:
> Will be used from external places in following patches.
> 
> Link: http://lkml.kernel.org/n/tip-ydj205bfen9fgflnv39hn...@git.kernel.org
> Signed-off-by: Jiri Olsa 

Thanks, applied,

- Arnaldo


[PATCH v2 4/5] soc/qman: Add self-test for QMan driver

2016-09-22 Thread Claudiu Manoil
Add self tests for the DPAA 1.x Queue Manager driver. The tests
ensure that the driver can properly enqueue and dequeue to/from
frame queues using the QMan portal infrastructure.

Signed-off-by: Roy Pledge 
Signed-off-by: Claudiu Manoil 
---
v2: none

 drivers/soc/fsl/qbman/Kconfig   |  23 ++
 drivers/soc/fsl/qbman/Makefile  |   5 +
 drivers/soc/fsl/qbman/qman_test.c   |  62 
 drivers/soc/fsl/qbman/qman_test.h   |  36 ++
 drivers/soc/fsl/qbman/qman_test_api.c   | 252 +
 drivers/soc/fsl/qbman/qman_test_stash.c | 617 
 6 files changed, 995 insertions(+)
 create mode 100644 drivers/soc/fsl/qbman/qman_test.c
 create mode 100644 drivers/soc/fsl/qbman/qman_test.h
 create mode 100644 drivers/soc/fsl/qbman/qman_test_api.c
 create mode 100644 drivers/soc/fsl/qbman/qman_test_stash.c

diff --git a/drivers/soc/fsl/qbman/Kconfig b/drivers/soc/fsl/qbman/Kconfig
index e6da6a2..757033c 100644
--- a/drivers/soc/fsl/qbman/Kconfig
+++ b/drivers/soc/fsl/qbman/Kconfig
@@ -41,4 +41,27 @@ config FSL_BMAN_TEST_API
  high-level API testing with them (whichever portal(s) are affine
  to the cpu(s) the test executes on).
 
+config FSL_QMAN_TEST
+   tristate "QMan self-tests"
+   help
+ Compile self-test code for QMan.
+
+config FSL_QMAN_TEST_API
+   bool "QMan high-level self-test"
+   depends on FSL_QMAN_TEST
+   default y
+   help
+ This requires the presence of cpu-affine portals, and performs
+ high-level API testing with them (whichever portal(s) are affine to
+ the cpu(s) the test executes on).
+
+config FSL_QMAN_TEST_STASH
+   bool "QMan 'hot potato' data-stashing self-test"
+   depends on FSL_QMAN_TEST
+   default y
+   help
+ This performs a "hot potato" style test enqueuing/dequeuing a frame
+ across a series of FQs scheduled to different portals (and cpus), with
+ DQRR, data and context stashing always on.
+
 endif # FSL_DPAA
diff --git a/drivers/soc/fsl/qbman/Makefile b/drivers/soc/fsl/qbman/Makefile
index 714dd97..7ae199f 100644
--- a/drivers/soc/fsl/qbman/Makefile
+++ b/drivers/soc/fsl/qbman/Makefile
@@ -5,3 +5,8 @@ obj-$(CONFIG_FSL_DPAA)  += bman_ccsr.o 
qman_ccsr.o \
 obj-$(CONFIG_FSL_BMAN_TEST) += bman-test.o
 bman-test-y  = bman_test.o
 bman-test-$(CONFIG_FSL_BMAN_TEST_API)   += bman_test_api.o
+
+obj-$(CONFIG_FSL_QMAN_TEST)+= qman-test.o
+qman-test-y = qman_test.o
+qman-test-$(CONFIG_FSL_QMAN_TEST_API)  += qman_test_api.o
+qman-test-$(CONFIG_FSL_QMAN_TEST_STASH)+= qman_test_stash.o
diff --git a/drivers/soc/fsl/qbman/qman_test.c 
b/drivers/soc/fsl/qbman/qman_test.c
new file mode 100644
index 000..18f7f02
--- /dev/null
+++ b/drivers/soc/fsl/qbman/qman_test.c
@@ -0,0 +1,62 @@
+/* Copyright 2008 - 2016 Freescale Semiconductor, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in the
+ *  documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *  names of its contributors may be used to endorse or promote products
+ *  derived from this software without specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "qman_test.h"
+
+MODULE_AUTHOR("Geoff Thorpe");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_DESCRIPTION("QMan testing");
+
+static int 

[PATCH 21/57] perf c2c report: Add offset dimension key

2016-09-22 Thread Jiri Olsa
Adding cacheline offset dimension key support.
It displays cacheline offset as hex number.

Link: http://lkml.kernel.org/n/tip-m0424ye98lqveg5nopto8...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 335c0fd30757..7c52481ec36b 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -300,6 +300,32 @@ static int dcacheline_entry(struct perf_hpp_fmt *fmt, 
struct perf_hpp *hpp,
return snprintf(hpp->buf, hpp->size, "%*s", width, hex_str(addr));
 }
 
+static int offset_entry(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
+   struct hist_entry *he)
+{
+   uint64_t addr = 0;
+   int width = c2c_width(fmt, hpp, he->hists);
+
+   if (he->mem_info)
+   addr = cl_offset(he->mem_info->daddr.al_addr);
+
+   return snprintf(hpp->buf, hpp->size, "%*s", width, hex_str(addr));
+}
+
+static int64_t
+offset_cmp(struct perf_hpp_fmt *fmt __maybe_unused,
+  struct hist_entry *left, struct hist_entry *right)
+{
+   uint64_t l = 0, r = 0;
+
+   if (left->mem_info)
+   l = cl_offset(left->mem_info->daddr.addr);
+   if (right->mem_info)
+   r = cl_offset(right->mem_info->daddr.addr);
+
+   return (int64_t)(r - l);
+}
+
 #define HEADER_LOW(__h)\
{   \
.line[1] = {\
@@ -343,8 +369,17 @@ static struct c2c_dimension dim_dcacheline = {
.width  = 18,
 };
 
+static struct c2c_dimension dim_offset = {
+   .header = HEADER_BOTH("Data address", "Offset"),
+   .name   = "offset",
+   .cmp= offset_cmp,
+   .entry  = offset_entry,
+   .width  = 18,
+};
+
 static struct c2c_dimension *dimensions[] = {
_dcacheline,
+   _offset,
NULL,
 };
 
-- 
2.7.4



[PATCH 14/57] perf c2c report: Add sort_entry dimension support

2016-09-22 Thread Jiri Olsa
Allow to reuse 'struct sort_entry' objects
within c2c dimension support.

In case the 'struct sort_entry' object meets
the need of c2c report we will use it directly
in following patches.

Link: http://lkml.kernel.org/n/tip-a4jraum43uwhhnp91je2j...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 82 ++--
 1 file changed, 65 insertions(+), 17 deletions(-)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 63c0e2d8d2d8..6b58b537bc9d 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -9,6 +9,7 @@
 #include "hist.h"
 #include "tool.h"
 #include "data.h"
+#include "sort.h"
 
 struct c2c_hists {
struct histshists;
@@ -47,6 +48,7 @@ struct c2c_dimension {
struct c2c_headerheader;
const char  *name;
int  width;
+   struct sort_entry   *se;
 
int64_t (*cmp)(struct perf_hpp_fmt *fmt,
   struct hist_entry *, struct hist_entry *);
@@ -66,34 +68,47 @@ static int c2c_width(struct perf_hpp_fmt *fmt,
 struct hists *hists __maybe_unused)
 {
struct c2c_fmt *c2c_fmt;
+   struct c2c_dimension *dim;
 
c2c_fmt = container_of(fmt, struct c2c_fmt, fmt);
-   return c2c_fmt->dim->width;
+   dim = c2c_fmt->dim;
+
+   return dim->se ? hists__col_len(hists, dim->se->se_width_idx) :
+c2c_fmt->dim->width;
 }
 
 static int c2c_header(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
- struct hists *hists __maybe_unused, int line, int *span)
+ struct hists *hists, int line, int *span)
 {
+   struct perf_hpp_list *hpp_list = hists->hpp_list;
struct c2c_fmt *c2c_fmt;
struct c2c_dimension *dim;
-   int len = c2c_width(fmt, hpp, hists);
-   const char *text;
+   const char *text = NULL;
+   int width = c2c_width(fmt, hpp, hists);
 
c2c_fmt = container_of(fmt, struct c2c_fmt, fmt);
dim = c2c_fmt->dim;
 
-   text = dim->header.line[line].text;
-   if (text == NULL)
-   text = "";
-
-   if (*span) {
-   (*span)--;
-   return 0;
+   if (dim->se) {
+   text = dim->header.line[line].text;
+   /* Use the last line from sort_entry if not defined. */
+   if (!text && (line == hpp_list->nr_header_lines - 1))
+   text = dim->se->se_header;
} else {
-   *span = dim->header.line[line].span;
+   text = dim->header.line[line].text;
+
+   if (*span) {
+   (*span)--;
+   return 0;
+   } else {
+   *span = dim->header.line[line].span;
+   }
}
 
-   return scnprintf(hpp->buf, hpp->size, "%*s", len, text);
+   if (text == NULL)
+   text = "";
+
+   return scnprintf(hpp->buf, hpp->size, "%*s", width, text);
 }
 
 static struct c2c_dimension *dimensions[] = {
@@ -130,6 +145,39 @@ static struct c2c_dimension *get_dimension(const char 
*name)
return NULL;
 }
 
+static int c2c_se_entry(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
+   struct hist_entry *he)
+{
+   struct c2c_fmt *c2c_fmt = container_of(fmt, struct c2c_fmt, fmt);
+   struct c2c_dimension *dim = c2c_fmt->dim;
+   size_t len = fmt->user_len;
+
+   if (!len)
+   len = hists__col_len(he->hists, dim->se->se_width_idx);
+
+   return dim->se->se_snprintf(he, hpp->buf, hpp->size, len);
+}
+
+static int64_t c2c_se_cmp(struct perf_hpp_fmt *fmt,
+ struct hist_entry *a, struct hist_entry *b)
+{
+   struct c2c_fmt *c2c_fmt = container_of(fmt, struct c2c_fmt, fmt);
+   struct c2c_dimension *dim = c2c_fmt->dim;
+
+   return dim->se->se_cmp(a, b);
+}
+
+static int64_t c2c_se_collapse(struct perf_hpp_fmt *fmt,
+  struct hist_entry *a, struct hist_entry *b)
+{
+   struct c2c_fmt *c2c_fmt = container_of(fmt, struct c2c_fmt, fmt);
+   struct c2c_dimension *dim = c2c_fmt->dim;
+   int64_t (*collapse_fn)(struct hist_entry *, struct hist_entry *);
+
+   collapse_fn = dim->se->se_collapse ?: dim->se->se_cmp;
+   return collapse_fn(a, b);
+}
+
 static struct c2c_fmt *get_format(const char *name)
 {
struct c2c_dimension *dim = get_dimension(name);
@@ -149,12 +197,12 @@ static struct c2c_fmt *get_format(const char *name)
INIT_LIST_HEAD(>list);
INIT_LIST_HEAD(>sort_list);
 
-   fmt->cmp= dim->cmp;
-   fmt->sort   = dim->cmp;
-   fmt->entry  = dim->entry;
+   fmt->cmp= dim->se ? c2c_se_cmp   : dim->cmp;
+   fmt->sort   = dim->se ? c2c_se_cmp   : dim->cmp;
+   fmt->entry  = dim->se ? c2c_se_entry : dim->entry;
fmt->header = 

Re: [PATCH] Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR. Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR.

2016-09-22 Thread Tejun Heo
On Thu, Sep 22, 2016 at 01:18:31AM +0530, Harman Kalra wrote:
> Signed-off-by: Harman Kalra 

Fixed up subject and applied to libata/for-4.9.

Thanks.

-- 
tejun


[PATCH 11/57] perf c2c: Add record subcommand

2016-09-22 Thread Jiri Olsa
Adding c2c record subcommand. It setups options related
to HITM cacheline analysis and calls standard perf
record command.

  $ sudo perf c2c record -v -- -a
  calling: record -W -d --sample-cpu -e cpu/mem-loads,ldlat=30/P -e 
cpu/mem-stores/P -a
  ...

It produces perf.data, which is to be reported by
perf c2c report, that comes in following patches.

Details are described in the man page, which is
added in one of the following patches.

Link: http://lkml.kernel.org/n/tip-hjxkryl43njyhaombycca...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 114 +++
 1 file changed, 114 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 8252ed0ba5d0..58924c67f818 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -4,12 +4,116 @@
 #include "debug.h"
 #include "builtin.h"
 #include 
+#include "mem-events.h"
 
 static const char * const c2c_usage[] = {
"perf c2c",
NULL
 };
 
+static int parse_record_events(const struct option *opt __maybe_unused,
+  const char *str, int unset __maybe_unused)
+{
+   bool *event_set = (bool *) opt->value;
+
+   *event_set = true;
+   return perf_mem_events__parse(str);
+}
+
+
+static const char * const __usage_record[] = {
+   "perf c2c record [] []",
+   "perf c2c record [] --  []",
+   NULL
+};
+
+static const char * const *record_mem_usage = __usage_record;
+
+static int perf_c2c__record(int argc, const char **argv)
+{
+   int rec_argc, i = 0, j;
+   const char **rec_argv;
+   int ret;
+   bool all_user = false, all_kernel = false;
+   bool event_set = false;
+   struct option options[] = {
+   OPT_CALLBACK('e', "event", _set, "event",
+"event selector. Use 'perf mem record -e list' to list 
available events",
+parse_record_events),
+   OPT_INCR('v', "verbose", ,
+"be more verbose (show counter open errors, etc)"),
+   OPT_BOOLEAN('u', "all-user", _user, "collect only user level data"),
+   OPT_BOOLEAN('k', "all-kernel", _kernel, "collect only kernel level 
data"),
+   OPT_UINTEGER('l', "ldlat", _mem_events__loads_ldlat, "setup 
mem-loads latency"),
+   OPT_END()
+   };
+
+   if (perf_mem_events__init()) {
+   pr_err("failed: memory events not supported\n");
+   return -1;
+   }
+
+   argc = parse_options(argc, argv, options, record_mem_usage,
+PARSE_OPT_KEEP_UNKNOWN);
+
+   rec_argc = argc + 10; /* max number of arguments */
+   rec_argv = calloc(rec_argc + 1, sizeof(char *));
+   if (!rec_argv)
+   return -1;
+
+   rec_argv[i++] = "record";
+
+   if (!event_set) {
+   perf_mem_events[PERF_MEM_EVENTS__LOAD].record  = true;
+   perf_mem_events[PERF_MEM_EVENTS__STORE].record = true;
+   }
+
+   if (perf_mem_events[PERF_MEM_EVENTS__LOAD].record)
+   rec_argv[i++] = "-W";
+
+   rec_argv[i++] = "-d";
+   rec_argv[i++] = "--sample-cpu";
+
+   for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
+   if (!perf_mem_events[j].record)
+   continue;
+
+   if (!perf_mem_events[j].supported) {
+   pr_err("failed: event '%s' not supported\n",
+  perf_mem_events[j].name);
+   return -1;
+   }
+
+   rec_argv[i++] = "-e";
+   rec_argv[i++] = perf_mem_events__name(j);
+   };
+
+   if (all_user)
+   rec_argv[i++] = "--all-user";
+
+   if (all_kernel)
+   rec_argv[i++] = "--all-kernel";
+
+   for (j = 0; j < argc; j++, i++)
+   rec_argv[i] = argv[j];
+
+   if (verbose > 0) {
+   pr_debug("calling: ");
+
+   j = 0;
+
+   while (rec_argv[j]) {
+   pr_debug("%s ", rec_argv[j]);
+   j++;
+   }
+   pr_debug("\n");
+   }
+
+   ret = cmd_record(i, rec_argv, NULL);
+   free(rec_argv);
+   return ret;
+}
+
 int cmd_c2c(int argc, const char **argv, const char *prefix __maybe_unused)
 {
const struct option c2c_options[] = {
@@ -19,5 +123,15 @@ int cmd_c2c(int argc, const char **argv, const char *prefix 
__maybe_unused)
 
argc = parse_options(argc, argv, c2c_options, c2c_usage,
 PARSE_OPT_STOP_AT_NON_OPTION);
+
+   if (!argc)
+   usage_with_options(c2c_usage, c2c_options);
+
+   if (!strncmp(argv[0], "rec", 3)) {
+   return perf_c2c__record(argc, argv);
+   } else {
+   usage_with_options(c2c_usage, c2c_options);
+   }
+
return 0;
 }
-- 
2.7.4



Re: [PATCH 1/6] mtd: spi-nor: Add quad page program support

2016-09-22 Thread Cyrille Pitchen
Hi Jagan,

The support of Quad Page Program is already addressed by the series for
SPI x-2-2 and x-4-4 protocols and SFDP parsing:
http://lists.infradead.org/pipermail/linux-mtd/2016-June/068212.html

especially patch 5 and 9
http://lists.infradead.org/pipermail/linux-mtd/2016-June/068217.html
http://lists.infradead.org/pipermail/linux-mtd/2016-June/068220.html

Since then, I've tested the series with a small bug fix in
spi_nor_init_params() for the SPI_NOR_NO_FR case:

/* (Fast) Read settings. */
-   params->rd_modes = SNOR_MODE_1_1_1;
-   spi_nor_set_read_settings(>reads[SNOR_PINDEX_1_1_1],
- 0, 8, SPINOR_OP_READ_FAST);
-   if (!(info->flags & SPI_NOR_NO_FR)) {
-   params->rd_modes |= SNOR_MODE_SLOW;
-   spi_nor_set_read_settings(>reads[SNOR_PINDEX_SLOW],
- 0, 0, SPINOR_OP_READ);
-   }
+   params->rd_modes = SNOR_MODE_SLOW;
+   spi_nor_set_read_settings(>reads[SNOR_PINDEX_SLOW],
+ 0, 0, SPINOR_OP_READ);
+   if (!(info->flags & SPI_NOR_NO_FR)) {
+   params->rd_modes |= SNOR_MODE_1_1_1;
+   spi_nor_set_read_settings(>reads[SNOR_PINDEX_1_1_1],
+ 0, 8, SPINOR_OP_READ_FAST);
+   }

I've tested it with more memory samples (Micron, Spansion, Macronix, SST)
and it seems reliable so I should send a new version soon.

Best regards,

Cyrille

Le 09/08/2016 à 22:40, Jagan Teki a écrit :
> Add quad page program support with the use of nor->flags
> and then controller will use 4 lines for data transmission
> which is quite faster than page program(02h)
> 
> Cc: Brian Norris 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/mtd/spi-nor/spi-nor.c | 13 +
>  include/linux/mtd/spi-nor.h   |  2 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index d0fc165..f88bd7e 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -75,6 +75,7 @@ struct flash_info {
>* bit. Must be used with
>* SPI_NOR_HAS_LOCK.
>*/
> +#define SPI_NOR_QUAD_WRITE   BIT(10) /* Flash supports Quad Write */
>  };
>  
>  #define JEDEC_MFR(info)  ((info)->id[0])
> @@ -1306,6 +1307,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, 
> enum read_mode mode)
>   struct device *dev = nor->dev;
>   struct mtd_info *mtd = >mtd;
>   struct device_node *np = spi_nor_get_flash_node(nor);
> + bool need_quad = false;
>   int ret;
>   int i;
>  
> @@ -1441,6 +1443,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, 
> enum read_mode mode)
>   return ret;
>   }
>   nor->flash_read = SPI_NOR_QUAD;
> + need_quad = true;
>   } else if (mode == SPI_NOR_DUAL && info->flags & SPI_NOR_DUAL_READ) {
>   nor->flash_read = SPI_NOR_DUAL;
>   }
> @@ -1465,6 +1468,16 @@ int spi_nor_scan(struct spi_nor *nor, const char 
> *name, enum read_mode mode)
>   }
>  
>   nor->program_opcode = SPINOR_OP_PP;
> + if (nor->flags == SNOR_F_USE_QPP && info->flags & SPI_NOR_QUAD_WRITE) {
> + if (!need_quad)
> + ret = set_quad_mode(nor, info);
> + if (ret) {
> + dev_err(dev, "quad mode not supported\n");
> + return ret;
> + }
> + }
> + nor->program_opcode = SPINOR_OP_QPP;
> + }
>  
>   if (info->addr_width)
>   nor->addr_width = info->addr_width;
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index c425c7b..aa0e6cd 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -46,6 +46,7 @@
>  #define SPINOR_OP_READ_1_1_2 0x3b/* Read data bytes (Dual SPI) */
>  #define SPINOR_OP_READ_1_1_4 0x6b/* Read data bytes (Quad SPI) */
>  #define SPINOR_OP_PP 0x02/* Page program (up to 256 bytes) */
> +#define SPINOR_OP_QPP0x32/* Quad Page program */
>  #define SPINOR_OP_BE_4K  0x20/* Erase 4KiB block */
>  #define SPINOR_OP_BE_4K_PMC  0xd7/* Erase 4KiB block on PMC chips */
>  #define SPINOR_OP_BE_32K 0x52/* Erase 32KiB block */
> @@ -119,6 +120,7 @@ enum spi_nor_ops {
>  enum spi_nor_option_flags {
>   SNOR_F_USE_FSR  = BIT(0),
>   SNOR_F_HAS_SR_TB= BIT(1),
> + SNOR_F_USE_QPP  = BIT(2),
>  };
>  
>  /**
> 



[PATCH 22/57] perf c2c report: Add iaddr dimension key

2016-09-22 Thread Jiri Olsa
Adding iaddr dimension key support. It displays
code address (as hex number) responsible for the
accesses.

Using c2c wrapper to standard 'symbol_iaddr' object
to define own header and simple (just address) code
address output.

Link: http://lkml.kernel.org/n/tip-rhshygbst6kr75kju0muw...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 7c52481ec36b..a2881677c315 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -326,6 +326,26 @@ offset_cmp(struct perf_hpp_fmt *fmt __maybe_unused,
return (int64_t)(r - l);
 }
 
+static int
+iaddr_entry(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
+   struct hist_entry *he)
+{
+   uint64_t addr = 0;
+   int width = c2c_width(fmt, hpp, he->hists);
+
+   if (he->mem_info)
+   addr = he->mem_info->iaddr.addr;
+
+   return snprintf(hpp->buf, hpp->size, "%*s", width, hex_str(addr));
+}
+
+static int64_t
+iaddr_cmp(struct perf_hpp_fmt *fmt __maybe_unused,
+ struct hist_entry *left, struct hist_entry *right)
+{
+   return sort__iaddr_cmp(left, right);
+}
+
 #define HEADER_LOW(__h)\
{   \
.line[1] = {\
@@ -377,9 +397,18 @@ static struct c2c_dimension dim_offset = {
.width  = 18,
 };
 
+static struct c2c_dimension dim_iaddr = {
+   .header = HEADER_LOW("Code address"),
+   .name   = "iaddr",
+   .cmp= iaddr_cmp,
+   .entry  = iaddr_entry,
+   .width  = 18,
+};
+
 static struct c2c_dimension *dimensions[] = {
_dcacheline,
_offset,
+   _iaddr,
NULL,
 };
 
-- 
2.7.4



Re: [PATCH 05/57] perf tools: Make output_field_add and sort_dimension__add global

2016-09-22 Thread Arnaldo Carvalho de Melo
Em Thu, Sep 22, 2016 at 05:36:33PM +0200, Jiri Olsa escreveu:
> Will be used from external places in following patches.
> 
> Link: http://lkml.kernel.org/n/tip-15488tnxcj4rtteksy79y...@git.kernel.org
> Signed-off-by: Jiri Olsa 

Thanks, applied,

- Arnaldo


[PATCH 09/57] perf tools: Make hists__fprintf_headers function global

2016-09-22 Thread Jiri Olsa
Will be used from external places in following patches.

Link: http://lkml.kernel.org/n/tip-ydj205bfen9fgflnv39hn...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/ui/stdio/hist.c | 2 +-
 tools/perf/util/hist.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index a2a50ef4176d..89d8441f9890 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -702,7 +702,7 @@ hists__fprintf_standard_headers(struct hists *hists,
return hpp_list->nr_header_lines + 2;
 }
 
-static int hists__fprintf_headers(struct hists *hists, FILE *fp)
+int hists__fprintf_headers(struct hists *hists, FILE *fp)
 {
char bf[1024];
struct perf_hpp dummy_hpp = {
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index ecc4c0c5ce18..9928fed8bc59 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -489,5 +489,6 @@ int hpp_color_scnprintf(struct perf_hpp *hpp, const char 
*fmt, ...);
 int __hpp__slsmg_color_printf(struct perf_hpp *hpp, const char *fmt, ...);
 int __hist_entry__snprintf(struct hist_entry *he, struct perf_hpp *hpp,
   struct perf_hpp_list *hpp_list);
+int hists__fprintf_headers(struct hists *hists, FILE *fp);
 
 #endif /* __PERF_HIST_H */
-- 
2.7.4



[PATCH 04/57] perf tools: Make reset_dimensions global

2016-09-22 Thread Jiri Olsa
Will be used from external places in following patches.

Link: http://lkml.kernel.org/n/tip-7garqfmx5izaqysde9jik...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/sort.c | 2 +-
 tools/perf/util/sort.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 1884d7f9b9d2..9e1f6f75a50f 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -2748,7 +2748,7 @@ static int setup_output_list(struct perf_hpp_list *list, 
char *str)
return ret;
 }
 
-static void reset_dimensions(void)
+void reset_dimensions(void)
 {
unsigned int i;
 
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 9505483cb95c..4efadc1e98c5 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -269,4 +269,5 @@ int report_parse_ignore_callees_opt(const struct option 
*opt, const char *arg, i
 bool is_strict_order(const char *order);
 
 int hpp_dimension__add_output(unsigned col);
+void reset_dimensions(void);
 #endif /* __PERF_SORT_H */
-- 
2.7.4



[PATCH 06/57] perf tools: Make several sorting functions global

2016-09-22 Thread Jiri Olsa
Will be used from external places in following patches.

Link: http://lkml.kernel.org/n/tip-4jyvw21cac7yuqsdkzdo5...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/sort.c | 6 +++---
 tools/perf/util/sort.h | 6 ++
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 9f7c1ea9e3ad..452e15a10dd2 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -867,7 +867,7 @@ struct sort_entry sort_cycles = {
 };
 
 /* --sort daddr_sym */
-static int64_t
+int64_t
 sort__daddr_cmp(struct hist_entry *left, struct hist_entry *right)
 {
uint64_t l = 0, r = 0;
@@ -896,7 +896,7 @@ static int hist_entry__daddr_snprintf(struct hist_entry 
*he, char *bf,
 width);
 }
 
-static int64_t
+int64_t
 sort__iaddr_cmp(struct hist_entry *left, struct hist_entry *right)
 {
uint64_t l = 0, r = 0;
@@ -1062,7 +1062,7 @@ static int hist_entry__snoop_snprintf(struct hist_entry 
*he, char *bf,
return repsep_snprintf(bf, size, "%-*s", width, out);
 }
 
-static int64_t
+int64_t
 sort__dcacheline_cmp(struct hist_entry *left, struct hist_entry *right)
 {
u64 l, r;
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index e93b0fa43704..099c97557d33 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -274,4 +274,10 @@ int sort_dimension__add(struct perf_hpp_list *list, const 
char *tok,
struct perf_evlist *evlist,
int level);
 int output_field_add(struct perf_hpp_list *list, char *tok);
+int64_t
+sort__iaddr_cmp(struct hist_entry *left, struct hist_entry *right);
+int64_t
+sort__daddr_cmp(struct hist_entry *left, struct hist_entry *right);
+int64_t
+sort__dcacheline_cmp(struct hist_entry *left, struct hist_entry *right);
 #endif /* __PERF_SORT_H */
-- 
2.7.4



[PATCH 15/57] perf c2c report: Fallback to standard dimensions

2016-09-22 Thread Jiri Olsa
Fallback to standard dimensions in case we don't
find the dimension within c2c ones.

Link: http://lkml.kernel.org/n/tip-w3yrcawal0dr1w9pcu4gy...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 6b58b537bc9d..a3481f86e2ae 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -213,8 +213,10 @@ static int c2c_hists__init_output(struct perf_hpp_list 
*hpp_list, char *name)
 {
struct c2c_fmt *c2c_fmt = get_format(name);
 
-   if (!c2c_fmt)
-   return -1;
+   if (!c2c_fmt) {
+   reset_dimensions();
+   return output_field_add(hpp_list, name);
+   }
 
perf_hpp_list__column_register(hpp_list, _fmt->fmt);
return 0;
@@ -224,8 +226,10 @@ static int c2c_hists__init_sort(struct perf_hpp_list 
*hpp_list, char *name)
 {
struct c2c_fmt *c2c_fmt = get_format(name);
 
-   if (!c2c_fmt)
-   return -1;
+   if (!c2c_fmt) {
+   reset_dimensions();
+   return sort_dimension__add(hpp_list, name, NULL, 0);
+   }
 
perf_hpp_list__register_sort_field(hpp_list, _fmt->fmt);
return 0;
-- 
2.7.4



[PATCH 23/57] perf c2c report: Add hitm related dimension keys

2016-09-22 Thread Jiri Olsa
Adding 5 hitm related dimension key wrappers.

First 3 are to be displayed in the main cachelines
overall output:

  tot_hitm, lcl_hitm, rmt_hitm

The latter 2 are to be displayed within single
cacheline output:

  cl_rmt_hitm, cl_lcl_hitm

They all display bare numbers of remote/local/total
HITMs for cacheline or its related offsets.

Link: http://lkml.kernel.org/n/tip-iju5239xa5heqqben65g1...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 109 +++
 1 file changed, 109 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index a2881677c315..06c4d3e92ed2 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -346,6 +346,70 @@ iaddr_cmp(struct perf_hpp_fmt *fmt __maybe_unused,
return sort__iaddr_cmp(left, right);
 }
 
+static int
+tot_hitm_entry(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
+  struct hist_entry *he)
+{
+   struct c2c_hist_entry *c2c_he;
+   int width = c2c_width(fmt, hpp, he->hists);
+   unsigned int tot_hitm;
+
+   c2c_he = container_of(he, struct c2c_hist_entry, he);
+   tot_hitm = c2c_he->stats.lcl_hitm + c2c_he->stats.rmt_hitm;
+
+   return snprintf(hpp->buf, hpp->size, "%*u", width, tot_hitm);
+}
+
+static int64_t
+tot_hitm_cmp(struct perf_hpp_fmt *fmt __maybe_unused,
+struct hist_entry *left, struct hist_entry *right)
+{
+   struct c2c_hist_entry *c2c_left;
+   struct c2c_hist_entry *c2c_right;
+   unsigned int tot_hitm_left;
+   unsigned int tot_hitm_right;
+
+   c2c_left  = container_of(left, struct c2c_hist_entry, he);
+   c2c_right = container_of(right, struct c2c_hist_entry, he);
+
+   tot_hitm_left  = c2c_left->stats.lcl_hitm + c2c_left->stats.rmt_hitm;
+   tot_hitm_right = c2c_right->stats.lcl_hitm + c2c_right->stats.rmt_hitm;
+
+   return tot_hitm_left - tot_hitm_right;
+}
+
+#define STAT_FN_ENTRY(__f) \
+static int \
+__f ## _entry(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,  \
+ struct hist_entry *he)\
+{  \
+   struct c2c_hist_entry *c2c_he;  \
+   int width = c2c_width(fmt, hpp, he->hists); \
+   \
+   c2c_he = container_of(he, struct c2c_hist_entry, he);   \
+   return snprintf(hpp->buf, hpp->size, "%*u", width,  \
+   c2c_he->stats.__f); \
+}
+
+#define STAT_FN_CMP(__f)   \
+static int64_t \
+__f ## _cmp(struct perf_hpp_fmt *fmt __maybe_unused,   \
+   struct hist_entry *left, struct hist_entry *right)  \
+{  \
+   struct c2c_hist_entry *c2c_left, *c2c_right;\
+   \
+   c2c_left  = container_of(left, struct c2c_hist_entry, he);  \
+   c2c_right = container_of(right, struct c2c_hist_entry, he); \
+   return c2c_left->stats.__f - c2c_right->stats.__f;  \
+}
+
+#define STAT_FN(__f)   \
+   STAT_FN_ENTRY(__f)  \
+   STAT_FN_CMP(__f)
+
+STAT_FN(rmt_hitm)
+STAT_FN(lcl_hitm)
+
 #define HEADER_LOW(__h)\
{   \
.line[1] = {\
@@ -405,10 +469,55 @@ static struct c2c_dimension dim_iaddr = {
.width  = 18,
 };
 
+static struct c2c_dimension dim_tot_hitm = {
+   .header = HEADER_SPAN("- LLC Load Hitm -", "Total", 2),
+   .name   = "tot_hitm",
+   .cmp= tot_hitm_cmp,
+   .entry  = tot_hitm_entry,
+   .width  = 7,
+};
+
+static struct c2c_dimension dim_lcl_hitm = {
+   .header = HEADER_SPAN_LOW("Lcl"),
+   .name   = "lcl_hitm",
+   .cmp= lcl_hitm_cmp,
+   .entry  = lcl_hitm_entry,
+   .width  = 7,
+};
+
+static struct c2c_dimension dim_rmt_hitm = {
+   .header = HEADER_SPAN_LOW("Rmt"),
+   .name   = "rmt_hitm",
+   .cmp= rmt_hitm_cmp,
+   .entry  = rmt_hitm_entry,
+   .width  = 7,
+};
+
+static struct c2c_dimension dim_cl_rmt_hitm = {
+   .header = HEADER_SPAN("- HITM -", "Rmt", 1),
+   .name   = "cl_rmt_hitm",
+   .cmp= rmt_hitm_cmp,
+   .entry  = rmt_hitm_entry,
+   .width  = 7,
+};
+
+static struct c2c_dimension dim_cl_lcl_hitm = {
+   .header = HEADER_SPAN_LOW("Lcl"),
+   .name   = 

[PATCH 17/57] perf c2c report: Add cacheline hists processing

2016-09-22 Thread Jiri Olsa
Store cacheline related entries in nested hist
object for each cacheline data. Nested entries
are sorted by 'offset' within related cacheline.

We will allow specific sort keys to be configured
for nested cacheline data entries in following
patches.

Link: http://lkml.kernel.org/n/tip-37f751rgqamq9miubmr89...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 90 
 1 file changed, 84 insertions(+), 6 deletions(-)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 29fb9573e292..cd0406ab8b5d 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -61,6 +61,32 @@ static struct hist_entry_ops c2c_entry_ops = {
.free   = c2c_he_free,
 };
 
+static int c2c_hists__init(struct c2c_hists *hists,
+  const char *sort);
+
+static struct hists*
+he__get_hists(struct hist_entry *he,
+ const char *sort)
+{
+   struct c2c_hist_entry *c2c_he;
+   struct c2c_hists *hists;
+   int ret;
+
+   c2c_he = container_of(he, struct c2c_hist_entry, he);
+   if (c2c_he->hists)
+   return _he->hists->hists;
+
+   hists = c2c_he->hists = zalloc(sizeof(*hists));
+   if (!hists)
+   return NULL;
+
+   ret = c2c_hists__init(hists, sort);
+   if (ret)
+   free(hists);
+
+   return >hists;
+}
+
 static int process_sample_event(struct perf_tool *tool __maybe_unused,
union perf_event *event,
struct perf_sample *sample,
@@ -70,7 +96,7 @@ static int process_sample_event(struct perf_tool *tool 
__maybe_unused,
struct hists *hists = 
struct hist_entry *he;
struct addr_location al;
-   struct mem_info *mi;
+   struct mem_info *mi, *mi_dup;
int ret;
 
if (machine__resolve(machine, , sample) < 0) {
@@ -83,19 +109,50 @@ static int process_sample_event(struct perf_tool *tool 
__maybe_unused,
if (mi == NULL)
return -ENOMEM;
 
+   mi_dup = memdup(mi, sizeof(*mi));
+   if (!mi_dup)
+   goto free_mi;
+
he = hists__add_entry_ops(hists, _entry_ops,
  , NULL, NULL, mi,
  sample, true);
-   if (he == NULL) {
-   free(mi);
-   return -ENOMEM;
-   }
+   if (he == NULL)
+   goto free_mi_dup;
 
hists__inc_nr_samples(hists, he->filtered);
ret = hist_entry__append_callchain(he, sample);
 
+   if (!ret) {
+   mi = mi_dup;
+
+   mi_dup = memdup(mi, sizeof(*mi));
+   if (!mi_dup)
+   goto free_mi;
+
+   hists = he__get_hists(he, "offset");
+   if (!hists)
+   goto free_mi_dup;
+
+   he = hists__add_entry_ops(hists, _entry_ops,
+ , NULL, NULL, mi,
+ sample, true);
+   if (he == NULL)
+   goto free_mi_dup;
+
+   hists__inc_nr_samples(hists, he->filtered);
+   ret = hist_entry__append_callchain(he, sample);
+   }
+
+out:
addr_location__put();
return ret;
+
+free_mi_dup:
+   free(mi_dup);
+free_mi:
+   free(mi);
+   ret = -ENOMEM;
+   goto out;
 }
 
 static struct perf_c2c c2c = {
@@ -400,6 +457,27 @@ static int c2c_hists__reinit(struct c2c_hists *c2c_hists,
return hpp_list__parse(_hists->list, output, sort);
 }
 
+static int filter_cb(struct hist_entry *he __maybe_unused)
+{
+   return 0;
+}
+
+static int resort_cl_cb(struct hist_entry *he)
+{
+   struct c2c_hist_entry *c2c_he;
+   struct c2c_hists *c2c_hists;
+
+   c2c_he = container_of(he, struct c2c_hist_entry, he);
+   c2c_hists = c2c_he->hists;
+
+   if (c2c_hists) {
+   hists__collapse_resort(_hists->hists, NULL);
+   hists__output_resort_cb(_hists->hists, NULL, filter_cb);
+   }
+
+   return 0;
+}
+
 static int perf_c2c__report(int argc, const char **argv)
 {
struct perf_session *session;
@@ -458,7 +536,7 @@ static int perf_c2c__report(int argc, const char **argv)
ui_progress__init(, c2c.hists.hists.nr_entries, "Sorting...");
 
hists__collapse_resort(, NULL);
-   hists__output_resort(, );
+   hists__output_resort_cb(, , resort_cl_cb);
 
ui_progress__finish();
 
-- 
2.7.4



Re: [PATCH 08/57] perf tools: Make __hist_entry__snprintf function global

2016-09-22 Thread Arnaldo Carvalho de Melo
Em Thu, Sep 22, 2016 at 05:36:36PM +0200, Jiri Olsa escreveu:
> Will be used from external places in following patches.
> 
> Link: http://lkml.kernel.org/n/tip-uip4x9u74t3dcz8sh4mei...@git.kernel.org
> Signed-off-by: Jiri Olsa 

Thanks, applied,

- Arnaldo


<    4   5   6   7   8   9   10   11   12   13   >