RE: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory

[Sell, Timothy C]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Sunday, August 21, 2016 2:05 PM
> To: Kershner, David A 
> Cc: cor...@lwn.net; t...@linutronix.de; mi...@redhat.com;
> h...@zytor.com; Arfvidson, Erik ; Sell, Timothy
> C ; hof...@osadl.org; dzic...@redhat.com;
> jes.soren...@redhat.com; Curtin, Alexander Paul
> ; janani.rvchn...@gmail.com;
> sudipm.mukher...@gmail.com; pra...@redhat.com; Binder, David Anthony
> ; nhor...@redhat.com;
> dan.j.willi...@intel.com; linux-ker...@vger.kernel.org; linux-
> d...@vger.kernel.org; driverdev-de...@linuxdriverproject.org; *S-Par-
> Maintainer 
> Subject: Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory
> 
> On Fri, Jun 10, 2016 at 11:23:56PM -0400, David Kershner wrote:
> > visorbus is currently located at drivers/staging/visorbus,
> > this patch moves it to drivers/virt.
> >
> > Signed-off-by: David Kershner 
> > Reviewed-by: Tim Sell 
> > ---
> >  drivers/staging/unisys/Kconfig| 3 
> > +--
> >  drivers/staging/unisys/Makefile   | 1 -
> >  drivers/virt/Kconfig  | 2 
> > ++
> >  drivers/virt/Makefile | 1 +
> >  drivers/{staging/unisys => virt}/visorbus/Kconfig | 0
> >  drivers/{staging/unisys => virt}/visorbus/Makefile| 0
> >  drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h  | 0
> >  drivers/{staging/unisys => virt}/visorbus/controlvmcompletionstatus.h | 0
> >  drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h | 0
> >  drivers/{staging/unisys => virt}/visorbus/vbuschannel.h   | 0
> >  drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h| 0
> >  drivers/{staging/unisys => virt}/visorbus/vbushelper.h| 0
> >  drivers/{staging/unisys => virt}/visorbus/visorbus_main.c | 0
> >  drivers/{staging/unisys => virt}/visorbus/visorbus_private.h  | 0
> >  drivers/{staging/unisys => virt}/visorbus/visorchannel.c  | 0
> >  drivers/{staging/unisys => virt}/visorbus/visorchipset.c  | 0
> 
> I picked one random file here, this last one, and found a number of
> "odd" things in it.
> 
> So, given that I can't really comment on the patch itself, I'm going to
> include the file below, quote it, and then provide some comments, ok?
> > /* visorchipset_main.c
> > ...
> > static void
> > controlvm_init_response(struct controlvm_message *msg,
> > struct controlvm_message_header *msg_hdr, int response)
> > {
> > memset(msg, 0, sizeof(struct controlvm_message));
> > memcpy(>hdr, msg_hdr, sizeof(struct controlvm_message_header));
> > msg->hdr.payload_bytes = 0;
> > msg->hdr.payload_vm_offset = 0;
> > msg->hdr.payload_max_bytes = 0;
> > if (response < 0) {
> > msg->hdr.flags.failed = 1;
> > msg->hdr.completion_status = (u32)(-response);
> > }
> > }
> > 
> > static void
> > Billy(struct controlvm_message_header *msg_hdr, int response)
> 
> Not John?  Bob?  Sally?  Alice?  Bernise?  Jean?  Molly?

Huh? What version of source code are you looking at??

The file being moved by this patch should be
drivers/staging/unisys/visorbus/visorchipset.c in your staging-next branch  
(https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/unisys/visorbus/visorchipset.c?h=staging-next).
If you look there, you will NOT find "Billy()", but instead 
"controlvm_respond()", i.e.:

static void
controlvm_init_response(struct controlvm_message *msg,
struct controlvm_message_header *msg_hdr, int response)
{
memset(msg, 0, sizeof(struct controlvm_message));
memcpy(>hdr, msg_hdr, sizeof(struct controlvm_message_header));
msg->hdr.payload_bytes = 0;
msg->hdr.payload_vm_offset = 0;
msg->hdr.payload_max_bytes = 0;
if (response < 0) {
msg->hdr.flags.failed = 1;
msg->hdr.completion_status = (u32)(-response);
}
}

static void
controlvm_respond(struct controlvm_message_header *msg_hdr, int response)
{
struct controlvm_message outmsg;

controlvm_init_response(, msg_hdr, response);
if (outmsg.hdr.flags.test_message == 1)
return;

if (!visorchannel_signalinsert(controlvm_channel,
   CONTROLVM_QUEUE_REQUEST, )) {
return;
}
}

One (or both) of us is confused.

Tim Sell

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [RFC PATCH-tip v4 07/10] locking/rwsem: Change RWSEM_WAITING_BIAS for better disambiguation

[Wanpeng Li]

2016-08-20 0:21 GMT+08:00 Waiman Long :
> On 08/19/2016 01:57 AM, Wanpeng Li wrote:
>>
>> 2016-08-19 5:11 GMT+08:00 Waiman Long:
>>>
>>> When the count value is in between 0 and RWSEM_WAITING_BIAS, there
>>> are 2 possibilities.
>>> Either a writer is present and there is no waiter
>>
>> count = 0x0001
>>
>>> or there are waiters and readers. There is no easy way to
>>
>> count = 0x000X
>>
>> However, RWSEM_WAITING_BIAS is equal to 0x, so both these two
>> cases are beyond RWSEM_WAITING_BIAS, right?
>>
>> Regards,
>> Wanpeng Li
>
>
> Perhaps I should make it clear that I am talking from a signed quantity
> point of view (it is an atomic_long_t). So
>
> RWSEM_WAITING_BIAS < RWSEM_ACTIVE_WRITE_BIAS < 0
>
> Hope this clarify your question.

Yeah, thank you. :)

Regards,
Wanpeng Li
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Zhou, Wenjian/周文剑]

On 08/19/2016 11:57 PM, Jonathan Corbet wrote:

On Fri, 19 Aug 2016 08:33:21 +0800
"Zhou, Wenjian/周文剑"  wrote:


I was also confused by maxcpus and nr_cpus before writing this patch.
I think it is a good choice to describe it in kernel-parameters.txt.

Then, only two things need to be done I think.
One is move the above description to maxcpus= in kernel-parameters.txt.
And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.

How do you think?


That is not quite what I had in mind, sorry.  What I would really like to
see in kernel-parameters.txt is an explanation of how those two parameters
differ - what do they do differently and how should a user choose one over
the other?  What we have now offers no guidance in that matter.



I thought about it. I think user may not need this.
What user really want to know is how to choose.
And it is also not a hard work. If nr_cpus is not supported by the ARCH, use 
maxcpus.
Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be 
supported
by some ARCHes.

I think it may be why the author didn't write too much description of it.


I suspect that may be a bit more than you had signed up to do.  As an
intermediate step, how about this: rather than tacking on those lines in
kdump.txt, rewrite that paragraph to simply say what the reader should
use.  If nr_cpus is good for everybody, just say that, but your previous
patch suggests that the situation isn't quite that simple?



Actually, if nr_cpus always usable, there won't be these discussions.


--
Thanks
Zhou


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PACTH v2 0/3] Implement /proc//totmaps

[Minchan Kim]

On Fri, Aug 19, 2016 at 10:05:32AM +0200, Michal Hocko wrote:
> On Fri 19-08-16 11:26:34, Minchan Kim wrote:
> > Hi Michal,
> > 
> > On Thu, Aug 18, 2016 at 08:01:04PM +0200, Michal Hocko wrote:
> > > On Thu 18-08-16 10:47:57, Sonny Rao wrote:
> > > > On Thu, Aug 18, 2016 at 12:44 AM, Michal Hocko  
> > > > wrote:
> > > > > On Wed 17-08-16 11:57:56, Sonny Rao wrote:
> > > [...]
> > > > >> 2) User space OOM handling -- we'd rather do a more graceful shutdown
> > > > >> than let the kernel's OOM killer activate and need to gather this
> > > > >> information and we'd like to be able to get this information to make
> > > > >> the decision much faster than 400ms
> > > > >
> > > > > Global OOM handling in userspace is really dubious if you ask me. I
> > > > > understand you want something better than SIGKILL and in fact this is
> > > > > already possible with memory cgroup controller (btw. memcg will give
> > > > > you a cheap access to rss, amount of shared, swapped out memory as
> > > > > well). Anyway if you are getting close to the OOM your system will 
> > > > > most
> > > > > probably be really busy and chances are that also reading your new 
> > > > > file
> > > > > will take much more time. I am also not quite sure how is pss useful 
> > > > > for
> > > > > oom decisions.
> > > > 
> > > > I mentioned it before, but based on experience RSS just isn't good
> > > > enough -- there's too much sharing going on in our use case to make
> > > > the correct decision based on RSS.  If RSS were good enough, simply
> > > > put, this patch wouldn't exist.
> > > 
> > > But that doesn't answer my question, I am afraid. So how exactly do you
> > > use pss for oom decisions?
> > 
> > My case is not for OOM decision but I agree it would be great if we can get
> > *fast* smap summary information.
> > 
> > PSS is really great tool to figure out how processes consume memory
> > more exactly rather than RSS. We have been used it for monitoring
> > of memory for per-process. Although it is not used for OOM decision,
> > it would be great if it is speed up because we don't want to spend
> > many CPU time for just monitoring.
> > 
> > For our usecase, we don't need AnonHugePages, ShmemPmdMapped, 
> > Shared_Hugetlb,
> > Private_Hugetlb, KernelPageSize, MMUPageSize because we never enable THP and
> > hugetlb. Additionally, Locked can be known via vma flags so we don't need 
> > it,
> > either. Even, we don't need address range for just monitoring when we don't
> > investigate in detail.
> > 
> > Although they are not severe overhead, why does it emit the useless
> > information? Even bloat day by day. :( With that, userspace tools should
> > spend more time to parse which is pointless.
> 
> So far it doesn't really seem that the parsing is the biggest problem.
> The major cycles killer is the output formatting and that doesn't sound

I cannot understand how kernel space is more expensive.
Hmm. I tested your test program on my machine.


#!/bin/sh
./smap_test &
pid=$!

for i in $(seq 25)
do
cat /proc/$pid/smaps > /dev/null
done
kill $pid

root@bbox:/home/barrios/test/smap# time ./s_v.sh
pid:21925
real0m3.365s
user0m0.031s
sys 0m3.046s


vs.

#!/bin/sh
./smap_test &
pid=$!

for i in $(seq 25)
do
awk '/^Rss/{rss+=$2} /^Pss/{pss+=$2} END {}' \
 /proc/$pid/smaps
done
kill $pid

root@bbox:/home/barrios/test/smap# time ./s.sh 
pid:21973

real0m17.812s
user0m12.612s
sys 0m5.187s

perf report says

39.56%  awkgawk   [.] dfaexec   
  
 7.61%  awk[kernel.kallsyms]  [k] format_decode 
  
 6.37%  awkgawk   [.] avoid_dfa 
  
 5.85%  awkgawk   [.] interpret 
  
 5.69%  awk[kernel.kallsyms]  [k] __memcpy  
  
 4.37%  awk[kernel.kallsyms]  [k] vsnprintf 
  
 2.69%  awk[kernel.kallsyms]  [k] number.isra.13
  
 2.10%  awkgawk   [.] research  
  
 1.91%  awkgawk   [.] 0x000351d0
  
 1.49%  awkgawk   [.] free_wstr 
  
 1.27%  awkgawk   [.] unref 
  
 1.19%  awkgawk   [.] reset_record  
  
 0.95%  awkgawk   [.] set_record
  
 0.95%  awkgawk   [.] get_field 
  
 0.94%  awk[kernel.kallsyms]  [k] show_smap 
  

Parsing is much expensive than kernel.
Could you retest your test program?

> like a problem we are not able to address. And I would even argue that
> we want to address it in a generic way as much as possible.

Sure. What solution do you 

Re: [PATCH 1/3] include: linux: visorbus: Add visorbus to include/linux directory

[Greg KH]

On Fri, Jun 10, 2016 at 11:23:54PM -0400, David Kershner wrote:
> Update include/linux to include the s-Par associated common include
> header files needed for the s-Par visorbus.
> 
> Since we have now moved the include directories over to
> include/linux/visorbus this patch makes all of the visor
> drivers visorbus, visorinput, visornic, and visorhba use
> the new include folders.
> 
> Signed-off-by: David Kershner 
> Reviewed-by: Tim Sell 
> ---
>  drivers/staging/unisys/MAINTAINERS| 2 +-
>  drivers/staging/unisys/visorbus/Makefile  | 2 --
>  drivers/staging/unisys/visorbus/controlvmchannel.h| 2 +-
>  drivers/staging/unisys/visorbus/vbuschannel.h | 3 ++-
>  drivers/staging/unisys/visorbus/visorbus_main.c   | 6 +++---
>  drivers/staging/unisys/visorbus/visorchannel.c| 4 ++--
>  drivers/staging/unisys/visorbus/visorchipset.c| 8 
> 
>  drivers/staging/unisys/visorbus/vmcallinterface.h | 5 ++---
>  drivers/staging/unisys/visorhba/Makefile  | 2 --
>  drivers/staging/unisys/visorhba/visorhba_main.c   | 5 ++---
>  drivers/staging/unisys/visorinput/Makefile| 2 --
>  drivers/staging/unisys/visorinput/visorinput.c| 6 +++---
>  drivers/staging/unisys/visornic/Makefile  | 2 --
>  drivers/staging/unisys/visornic/visornic_main.c   | 5 ++---
>  .../staging/unisys/include => include/linux/visorbus}/channel.h   | 0
>  .../unisys/include => include/linux/visorbus}/channel_guid.h  | 0
>  .../unisys/include => include/linux/visorbus}/diagchannel.h   | 0
>  .../unisys/include => include/linux/visorbus}/guestlinuxdebug.h   | 0
>  .../staging/unisys/include => include/linux/visorbus}/iochannel.h | 0
>  .../staging/unisys/include => include/linux/visorbus}/version.h   | 0
>  .../staging/unisys/include => include/linux/visorbus}/visorbus.h  | 0
>  21 files changed, 22 insertions(+), 32 deletions(-)
>  rename {drivers/staging/unisys/include => include/linux/visorbus}/channel.h 
> (100%)
>  rename {drivers/staging/unisys/include => 
> include/linux/visorbus}/channel_guid.h (100%)
>  rename {drivers/staging/unisys/include => 
> include/linux/visorbus}/diagchannel.h (100%)
>  rename {drivers/staging/unisys/include => 
> include/linux/visorbus}/guestlinuxdebug.h (100%)
>  rename {drivers/staging/unisys/include => 
> include/linux/visorbus}/iochannel.h (100%)
>  rename {drivers/staging/unisys/include => include/linux/visorbus}/version.h 
> (100%)
>  rename {drivers/staging/unisys/include => include/linux/visorbus}/visorbus.h 
> (100%)
> 
> diff --git a/drivers/staging/unisys/MAINTAINERS 
> b/drivers/staging/unisys/MAINTAINERS
> index 1f0425b..146a8c3 100644
> --- a/drivers/staging/unisys/MAINTAINERS
> +++ b/drivers/staging/unisys/MAINTAINERS
> @@ -1,5 +1,5 @@
>  Unisys s-Par drivers
>  M:   David Kershner 
>  S:   Maintained
> -F:   Documentation/s-Par/overview.txt
> +F:   Documentation/visorbus.txt
>  F:   drivers/staging/unisys/

This MAINTAINERS change doesn't have anything to do with moving the .h
files around :(

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory

[Greg KH]

On Fri, Jun 10, 2016 at 11:23:56PM -0400, David Kershner wrote:
> visorbus is currently located at drivers/staging/visorbus,
> this patch moves it to drivers/virt.
> 
> Signed-off-by: David Kershner 
> Reviewed-by: Tim Sell 
> ---
>  drivers/staging/unisys/Kconfig| 3 +--
>  drivers/staging/unisys/Makefile   | 1 -
>  drivers/virt/Kconfig  | 2 ++
>  drivers/virt/Makefile | 1 +
>  drivers/{staging/unisys => virt}/visorbus/Kconfig | 0
>  drivers/{staging/unisys => virt}/visorbus/Makefile| 0
>  drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h  | 0
>  drivers/{staging/unisys => virt}/visorbus/controlvmcompletionstatus.h | 0
>  drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h | 0
>  drivers/{staging/unisys => virt}/visorbus/vbuschannel.h   | 0
>  drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h| 0
>  drivers/{staging/unisys => virt}/visorbus/vbushelper.h| 0
>  drivers/{staging/unisys => virt}/visorbus/visorbus_main.c | 0
>  drivers/{staging/unisys => virt}/visorbus/visorbus_private.h  | 0
>  drivers/{staging/unisys => virt}/visorbus/visorchannel.c  | 0
>  drivers/{staging/unisys => virt}/visorbus/visorchipset.c  | 0

I picked one random file here, this last one, and found a number of
"odd" things in it.

So, given that I can't really comment on the patch itself, I'm going to
include the file below, quote it, and then provide some comments, ok?


> /* visorchipset_main.c
> >  *
>  * Copyright (C) 2010 - 2015 UNISYS CORPORATION
>  * All rights reserved.
>  *
>  * This program is free software; you can redistribute it and/or modify it
>  * under the terms and conditions of the GNU General Public License,
>  * version 2, as published by the Free Software Foundation.
>  *
>  * This program is distributed in the hope that it will be useful, but
>  * WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
>  * NON INFRINGEMENT.  See the GNU General Public License for more
>  * details.
>  */
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #include "channel_guid.h"
> #include "controlvmchannel.h"
> #include "controlvmcompletionstatus.h"
> #include "guestlinuxdebug.h"
> #include "version.h"

Why do you have this "version.h" file anyway?  It should be deleted, as
parts of it are obviously wrong :(

> #include "visorbus.h"
> #include "visorbus_private.h"
> #include "vmcallinterface.h"

That's loads of "private" .h files, are they all really needed?

> 
> #define CURRENT_FILE_PC VISOR_CHIPSET_PC_visorchipset_main_c

???

> 
> #define MAX_NAME_SIZE 128

name of what?  I don't think you even use this in the file!

> #define MAX_IP_SIZE   50

Huh?  You don't use this either?

> #define MAXOUTSTANDINGCHANNELCOMMAND 256

Here, have a '_', they are free.

But again, I don't see this being used.

> #define POLLJIFFIES_CONTROLVMCHANNEL_FAST   1
> #define POLLJIFFIES_CONTROLVMCHANNEL_SLOW 100

Right-hand alignment?  That's a glutton for punishment.

> 
> #define MAX_CONTROLVM_PAYLOAD_BYTES (1024 * 128)
> 
> #define VISORCHIPSET_MMAP_CONTROLCHANOFFSET   0x
> 
> #define UNISYS_SPAR_LEAF_ID 0x4000
> 
> /* The s-Par leaf ID returns "UnisysSpar64" encoded across ebx, ecx, edx */
> #define UNISYS_SPAR_ID_EBX 0x73696e55
> #define UNISYS_SPAR_ID_ECX 0x70537379
> #define UNISYS_SPAR_ID_EDX 0x34367261
> 
> /*
>  * Module parameters
>  */
> static int visorchipset_major;

major number should not be a module option, just grab a dynamic one and
run with it please.

> static int visorchipset_visorbusregwait = 1;  /* default is on */

Why even have this option?  Who is going to ever change it?  Why would
they?

> static unsigned long controlvm_payload_bytes_buffered;

Not a module option :(

> static u32 dump_vhba_bus;

Not an option, only ever set, never tested :(

> 
> static int
> visorchipset_open(struct inode *inode, struct file *file)
> {
>   unsigned int minor_number = iminor(inode);
> 
>   if (minor_number)
>   return -ENODEV;

What is this check for?  You only ever want one minor number?  If so,
why do you want a whole major number?

>   file->private_data = NULL;

Isn't this already true?

>   return 0;
> }
> 
> static int
> visorchipset_release(struct inode *inode, struct file *file)
> {
>   return 0;
> }

If you do nothing in a release function, then don't provide it at all.

> 
> /*
>  * When the controlvm channel is idle for at least MIN_IDLE_SECONDS,
>  * we switch to slow polling mode. As soon as we get a controlvm
>  * message, we switch back 

[PATCH 1/2] [media] docs-rst: fix some LaTeX errors when in interactive mode

[Mauro Carvalho Chehab]

There are several minor issues that are seen when building
PDF on interactive mode.

Fix them.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/v4l/dev-sliced-vbi.rst  | 2 +-
 Documentation/media/uapi/v4l/dev-subdev.rst  | 2 +-
 Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst   | 3 +--
 Documentation/media/uapi/v4l/subdev-formats.rst  | 6 +++---
 Documentation/media/uapi/v4l/vidioc-enumstd.rst  | 2 +-
 Documentation/media/uapi/v4l/vidioc-g-sliced-vbi-cap.rst | 2 +-
 Documentation/media/uapi/v4l/vidioc-g-tuner.rst  | 4 ++--
 7 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/Documentation/media/uapi/v4l/dev-sliced-vbi.rst 
b/Documentation/media/uapi/v4l/dev-sliced-vbi.rst
index 074aa3798152..86d2d698d2af 100644
--- a/Documentation/media/uapi/v4l/dev-sliced-vbi.rst
+++ b/Documentation/media/uapi/v4l/dev-sliced-vbi.rst
@@ -255,7 +255,7 @@ Sliced VBI services
 
 .. raw:: latex
 
-\newline\newline\begin{adjustbox}{width=\columnwidth}
+\begin{adjustbox}{width=\columnwidth}
 
 .. tabularcolumns:: |p{5.0cm}|p{1.4cm}|p{3.0cm}|p{2.5cm}|p{9.0cm}|
 
diff --git a/Documentation/media/uapi/v4l/dev-subdev.rst 
b/Documentation/media/uapi/v4l/dev-subdev.rst
index 7d20c725583d..1045b3c61031 100644
--- a/Documentation/media/uapi/v4l/dev-subdev.rst
+++ b/Documentation/media/uapi/v4l/dev-subdev.rst
@@ -204,7 +204,7 @@ list entity names and pad numbers).
 
 .. raw:: latex
 
-\newline\newline\begin{adjustbox}{width=\columnwidth}
+\begin{adjustbox}{width=\columnwidth}
 
 .. tabularcolumns:: 
|p{4.5cm}|p{4.5cm}|p{4.5cm}|p{4.5cm}|p{4.5cm}|p{4.5cm}|p{4.5cm}|
 
diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst 
b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
index 39875b4158d2..c94e1a5fee4d 100644
--- a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
@@ -16,7 +16,7 @@ next to each other in memory.
 
 .. raw:: latex
 
-\newline\newline\begin{adjustbox}{width=\columnwidth}
+\begin{adjustbox}{width=\columnwidth}
 
 .. tabularcolumns:: 
|p{4.5cm}|p{3.3cm}|p{0.7cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.2cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.2cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.2cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{1.7cm}|
 
@@ -1114,7 +1114,6 @@ either the corresponding ARGB or XRGB format, depending 
on the driver.
 
 .. raw:: latex
 
-\newline\newline
 \begin{adjustbox}{width=\columnwidth}
 
 .. tabularcolumns:: 
|p{4.2cm}|p{1.0cm}|p{0.7cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.2cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.2cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.2cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{0.4cm}|p{1.7cm}|
diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
b/Documentation/media/uapi/v4l/subdev-formats.rst
index 0b31943bb300..8b1ba4f53b18 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -159,7 +159,7 @@ The following tables list existing packed RGB formats.
 .. it switches to long table, and there's no way to override it.
 
 
-.. tabularcolumns:: 
|p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22}|
+.. tabularcolumns:: 
|p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
 
 .. _v4l2-mbus-pixelcode-rgb:
 
@@ -2377,7 +2377,7 @@ JEIDA defined bit mapping will be named
 
 .. raw:: latex
 
-\newline\newline\begin{adjustbox}{width=\columnwidth}
+\begin{adjustbox}{width=\columnwidth}
 
 .. _v4l2-mbus-pixelcode-rgb-lvds:
 
@@ -3764,7 +3764,7 @@ the following codes.
 -  d for dummy bits
 
 
-.. tabularcolumns:: 
|p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22}|
+.. tabularcolumns:: 

[PATCH 2/2] [media] index.rst: Fix LaTeX error in interactive mode on Sphinx 1.4.x

[Mauro Carvalho Chehab]

The Sphinx 1.4.x definition for \DUrole is:

\providecommand*{\DUrole}[2]{%
  \ifcsname DUrole#1\endcsname%
\csname DUrole#1\endcsname{#2}%
  \else% backwards compatibility: try \docutilsrole#1{#2}
\ifcsname docutilsrole#1\endcsname%
  \csname docutilsrole#1\endcsname{#2}%
\else%
  #2%
\fi%
  \fi%
}

This is broken when it is used inside a \begin{alltt} block.
So, replace it by just "#2", as this won't cause troubles, and
it is one of the fallback methods for it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/index.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
index 7f8f0af620ce..e347a3e7bdef 100644
--- a/Documentation/media/index.rst
+++ b/Documentation/media/index.rst
@@ -1,6 +1,11 @@
 Linux Media Subsystem Documentation
 ===
 
+.. Sphinx 1.4.x has a definition for DUrole that doesn't work on alltt blocks
+.. raw:: latex
+
+   \renewcommand*{\DUrole}[2]{ #2 }
+
 Contents:
 
 .. toctree::
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fw: [PATCH 0/2] Two additional patches for Documentation/conf.py

[Mauro Carvalho Chehab]

Sorry, forgot to copy patch 0/2 to Linux-doc people.

Forwarded message:

Date: Sun, 21 Aug 2016 15:23:02 -0300
From: Mauro Carvalho Chehab 
To: Linux Media Mailing List 
Cc: Mauro Carvalho Chehab , Mauro Carvalho Chehab 

Subject: [PATCH 0/2] Two additional patches for Documentation/conf.py


The first patch in this series use the type of notice box to color the box,
providing a functionality that it is also used on the HTML theme we use.

The second patch is a fix for a non-fatal error when building LaTeX on
interactive mode.

Mauro Carvalho Chehab (2):
  docs-rst: Use better colors for note/warning/attention boxes
  docs-rst: Fix an warning when in interactive mode

 Documentation/conf.py | 44 +---
 1 file changed, 29 insertions(+), 15 deletions(-)

-- 
2.7.4





Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] docs-rst: Use better colors for note/warning/attention boxes

[Mauro Carvalho Chehab]

Instead of painting the box with gray, let's use a colored
box. IMHO, that makes easier to warn users about some issue
pointed by the Sphinx. It also matches to what we do already
with the HTML output.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/conf.py | 34 --
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 011f6dac0c6c..f71b71048e37 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -277,11 +277,12 @@ latex_elements = {
 % Allow generate some pages in landscape
 \\usepackage{lscape}
 
-% Put notes in gray color and let them be inside a table
-
-\\definecolor{MyGray}{rgb}{0.80,0.80,0.80}
-
-\\makeatletter\\newenvironment{graybox}{%
+% Put notes in color and let them be inside a table
+   \\definecolor{NoteColor}{RGB}{204,255,255}
+   \\definecolor{WarningColor}{RGB}{255,204,204}
+   \\definecolor{AttentionColor}{RGB}{255,255,204}
+   \\definecolor{OtherColor}{RGB}{204,204,204}
+\\makeatletter\\newenvironment{coloredbox}[1]{%
   \\newlength{\\py@noticelength}
   \\setlength{\\fboxrule}{1pt}
   \\setlength{\\fboxsep}{7pt}
@@ -289,20 +290,33 @@ latex_elements = {
   \\addtolength{\\py@noticelength}{-2\\fboxsep}
   \\addtolength{\\py@noticelength}{-2\\fboxrule}

\\begin{lrbox}{\\@tempboxa}\\begin{minipage}{\\py@noticelength}}{\\end{minipage}\\end{lrbox}%
-   \\colorbox{MyGray}{\\usebox{\\@tempboxa}}
+  \\ifthenelse%
+ {\\equal{\\py@noticetype}{note}}%
+ {\\colorbox{NoteColor}{\\usebox{\\@tempboxa}}}%
+ {%
+\\ifthenelse%
+{\\equal{\\py@noticetype}{warning}}%
+{\\colorbox{WarningColor}{\\usebox{\\@tempboxa}}}%
+{%
+   \\ifthenelse%
+   {\\equal{\\py@noticetype}{attention}}%
+   {\\colorbox{AttentionColor}{\\usebox{\\@tempboxa}}}%
+   {\\colorbox{OtherColor}{\\usebox{\\@tempboxa}}}%
+}%
+ }%
 }\\makeatother
 
 \\makeatletter
-\\renewenvironment{notice}[2]{
-  \\begin{graybox}
-  \\bf\\it
+\\renewenvironment{notice}[2]{%
   \\def\\py@noticetype{#1}
+  \\begin{coloredbox}{#1}
+  \\bf\\it
   \\par\\strong{#2}
   \\csname py@noticestart@#1\\endcsname
 }
{
   \\csname py@noticeend@\\py@noticetype\\endcsname
-  \\end{graybox}
+  \\end{coloredbox}
 }
\\makeatother
 
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] docs-rst: Fix an warning when in interactive mode

[Mauro Carvalho Chehab]

When XeLaTeX is in interactive mode, it complains that
py@noticelength already exists. Rename it and declare it
only once to avoid such messages.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/conf.py | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index f71b71048e37..42045c26581b 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -282,14 +282,14 @@ latex_elements = {
\\definecolor{WarningColor}{RGB}{255,204,204}
\\definecolor{AttentionColor}{RGB}{255,255,204}
\\definecolor{OtherColor}{RGB}{204,204,204}
+\\newlength{\\mynoticelength}
 \\makeatletter\\newenvironment{coloredbox}[1]{%
-  \\newlength{\\py@noticelength}
   \\setlength{\\fboxrule}{1pt}
   \\setlength{\\fboxsep}{7pt}
-  \\setlength{\\py@noticelength}{\\linewidth}
-  \\addtolength{\\py@noticelength}{-2\\fboxsep}
-  \\addtolength{\\py@noticelength}{-2\\fboxrule}
-   
\\begin{lrbox}{\\@tempboxa}\\begin{minipage}{\\py@noticelength}}{\\end{minipage}\\end{lrbox}%
+  \\setlength{\\mynoticelength}{\\linewidth}
+  \\addtolength{\\mynoticelength}{-2\\fboxsep}
+  \\addtolength{\\mynoticelength}{-2\\fboxrule}
+   
\\begin{lrbox}{\\@tempboxa}\\begin{minipage}{\\mynoticelength}}{\\end{minipage}\\end{lrbox}%
   \\ifthenelse%
  {\\equal{\\py@noticetype}{note}}%
  {\\colorbox{NoteColor}{\\usebox{\\@tempboxa}}}%
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] docs-rst: kernel-doc: better output struct members

[Mauro Carvalho Chehab]

Right now, for a struct, kernel-doc produces the following output:

.. c:type:: struct v4l2_prio_state

   stores the priority states

**Definition**

::

  struct v4l2_prio_state {
atomic_t prios[4];
  };

**Members**

``atomic_t prios[4]``
  array with elements to store the array priorities

Putting a member name in verbatim and adding a continuation line
causes the LaTeX output to generate something like:
item[atomic_t prios\[4\]] array with elements to store the array 
priorities

Everything inside "item" is non-breakable, with may produce
lines bigger than the column width.

Also, for function members, like:

int (* rx_read) (struct v4l2_subdev *sd, u8 *buf, size_t count,ssize_t 
*num);

It puts the name of the member at the end, like:

int (*) (struct v4l2_subdev *sd, u8 *buf, size_t count,ssize_t *num) 
read

With is very confusing.

The best is to highlight what really matters: the member name; the type
is a secondary information.

So, change kernel-doc, for it to produce the output on a different way:

**Members**

``prios[4]``
  - **type**: ``atomic_t``

  array with elements to store the array priorities

With such change, the name of the member will be the first visible
thing, and will be in bold style. The type will still be there, inside
a list.

Also, as the type is not part of LaTeX "item[]", LaTeX will split it into
multiple lines, if needed.

So, both LaTeX/PDF and HTML outputs will look good.

It should be noticed, however, that the way Sphinx LaTeX output handles
things like:

Foo
   bar

is different than the HTML output. On HTML, it will produce something
like:

**Foo**
   bar

While, on LaTeX, it puts both foo and bar at the same line, like:

**Foo** bar

By starting the second line with a dash, both HTML and LaTeX output
will do the same thing.

Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kernel-doc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index ba081c7636a2..78e355281e1a 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -2000,7 +2000,8 @@ sub output_struct_rst(%) {
($args{'parameterdescs'}{$parameter_name} ne $undescribed) || next;
$type = $args{'parametertypes'}{$parameter};
 print_lineno($parameterdesc_start_lines{$parameter_name});
-   print "``$type $parameter``\n";
+   print "``" . $parameter . "``\n";
+   print "  - **type**: ``$type``\n\n";
output_highlight_rst($args{'parameterdescs'}{$parameter_name});
print "\n";
 }
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] doc-rst: generic way to build only sphinx sub-folders

[Mauro Carvalho Chehab]

Em Sat, 20 Aug 2016 09:51:57 -0300
Mauro Carvalho Chehab  escreveu:

> Em Fri, 19 Aug 2016 17:52:07 +0200
> Markus Heiser  escreveu:
> 
> > Am 19.08.2016 um 14:49 schrieb Jani Nikula :
> >   
> > > On Fri, 19 Aug 2016, Markus Heiser  wrote:
> > >> Am 19.08.2016 um 00:35 schrieb Jonathan Corbet :
> > >> * the pdf goes to the "latex" folder .. since this is WIP
> > >>  and there are different solutions conceivable ... I left
> > >>  it open for the first.
> > > 
> > > Mea culpa. As I said, I intended my patches as RFC only.
> > 
> > I think this is OK for the first. I thought that we first
> > let finish Mauro's task on making the media PDF and after
> > this we decide how move from the latex folder to a pdf folder
> > (one solution see below).  
> 
> Finished handling all tables. I'm sending the last 2 patches
> right now. Now, all tables fit into the page margins. Yet, I
> suspect that flat-table extension causes some troubles when cspan
> is used for LaTeX. It would be good if Markus could double check them.
> 
> There are just two things that won't fit at the margins of the document:
> 
> 1) included files with long lines. We might put those includes into
> a begingroup and use a smaller font, but IMHO the best is to fix the
> few cases on them, as those lines are very likely violating the 80 column
> limit;
> 
> 2) kernel-doc output for big arguments.
> 
> We have lots of function argument inside several media structs, like
> at:
>   struct v4l2_subdev_core_ops.
> 
> one of such arguments is this function:
> 
> int (* s_io_pin_config) (struct v4l2_subdev *sd, size_t n,struct 
> v4l2_subdev_io_pin_config *pincfg);
> 
> When kernel-doc generates the Members description, as the above line is
> bigger than 80 columns, it simply truncates its description to:
> 
>   Members
>   int (*)(struct v4l2_subdev *sd) log_status callback for 
> VIDIOC_LOG_STATUS ioctl handler code.
>   int (*)(struct v4l2_subdev *sd,size_t n,struct 
> v4l2_subdev_io_pin_config *pincfg) s_io_pin_con
>   ...
> 
> The LaTeX output for it is:
> 
>   \textbf{Members}
>   \begin{description}
>   \item[{\sphinxcode{int (*)(struct v4l2\_subdev *sd) log\_status}}] 
> \leavevmode
>   callback for \sphinxcode{VIDIOC\_LOG\_STATUS} ioctl handler code.
> 
>   \item[{\sphinxcode{int (*)(struct v4l2\_subdev *sd, size\_t n,struct 
> v4l2\_subdev\_io\_pin\_config *pincfg) s\_io\_pin\_config}}] \leavevmode
>   configure one or more chip I/O pins for chips that
>   multiplex different internal signal pads out to IO pins.  This function
>   takes a pointer to an array of `n' pin configuration entries, one for
>   each pin being configured.  This function could be called at times
>   other than just subdevice initialization.
> 
> It seems that \sphinxcode{} doesn't allow line breaks. Maybe we can
> override it via conf.py. I'll play with it and see if I can find a
> solution. Yet, this could have side effects on other places.
> 
> Any suggestions about how to fix it?

The problem is actually because Sphinx uses item[], with doesn't split
into multiple lines. Doing something like:

\\DeclareRobustCommand{\\sphinxcode}[1]{\\begin{minipage}{\\columnwidth}\\texttt{#1}\\end{minipage}}

Could fix, but, after sleeping into it, I think that the problem is actually
at the way the kernel-doc is output.

Right now, for a struct, it produces the following output:

.. c:type:: struct v4l2_prio_state

   stores the priority states

**Definition**

::

  struct v4l2_prio_state {
atomic_t prios[4];
  };

**Members**

``atomic_t prios[4]``
  array with elements to store the array priorities

Putting everything inside `` is the culprit for having a very big line
there.

Also, IMHO, the best would be to output it on a different way, like:

**Members**

``prios[4]``
  type: ``atomic_t``

  array with elements to store the array priorities

In order to highlight what really matters: the member name. The type
is a secondary information. Also, it is "hidden" in the middle of a
long string in the case of function parameters. The order for function
parameters is also counter-intuitive, as struct member like:

int (* rx_read) (struct v4l2_subdev *sd, u8 *buf, size_t count,ssize_t 
*num);

Is currently shown as:

int (*) (struct v4l2_subdev *sd, u8 *buf, size_t count,ssize_t *num) 
read

With sounds weird, at least to my eyes. Also, if the line is too big,
on PDF output, the member name will be missed, with is very bad.

So, I think that the best solution here is to actually patch
kernel-doc, for it to produce the output on a different way:

**Members**

``prios[4]``
  - **type**: ``atomic_t``

  array with elements to store the array priorities

With such