On Sat, Nov 19, 2016 at 12:48:27PM -0600, Tom Lendacky wrote:
> Should I move this functionality into the sme_set_mem_* functions or
> remove the sme_set_mem_* functions and use the set_memory_* functions
> directly. The latter means calculating the number of pages, but makes
> it clear that this
Not only media documents may have images. So, move the
rules for building images from graphviz and from SVG to
the Documentation makefile.
With this change, if some Documentation subdir "foo"
can now specify that he has SVG and/or DOT source images
that are included inside the documentation.
All
On Mon, Nov 21, 2016 at 07:48:50AM -0200, Mauro Carvalho Chehab wrote:
> Not only media documents may have images. So, move the
> rules for building images from graphviz and from SVG to
> the Documentation makefile.
>
> With this change, if some Documentation subdir "foo"
> can now specify that he
On Sat, 2016-11-19 at 10:15 -0700, Jonathan Corbet wrote:
>
> I don't know what the ultimate source of these images is (Mauro,
> perhaps you could shed some light there?).
I'd argue that it probably no longer matters. Whether it's xfig, svg,
graphviz originally etc. - the source is probably long
Inserting images with Sphinx is tricky, due to its limited
image support. So, the Kernel building system needs to
provide some help for it to work.
Document how to do it.
Signed-off-by: Mauro Carvalho Chehab
---
Provide documentation about how to include images and diagrams,
based on the change
Em Mon, 21 Nov 2016 11:21:27 +0100
Daniel Vetter escreveu:
> On Mon, Nov 21, 2016 at 07:48:50AM -0200, Mauro Carvalho Chehab wrote:
> > Not only media documents may have images. So, move the
> > rules for building images from graphviz and from SVG to
> > the Documentation makefile.
> >
> > With
On Sun, Nov 20, 2016 at 06:30:19AM +, Levy, Amir (Jer) wrote:
> On Fri, Nov 18 2016, 12:07 PM, gre...@linuxfoundation.org wrote:
> > On Fri, Nov 18, 2016 at 08:48:36AM +, Levy, Amir (Jer) wrote:
> > > > BTW, it is quite a shame that the Thunderbolt firmware version can't
> > > > be read fro
Hi!
The code depends on the _available work in iio which can
be found in linux-next.
v2 -> v3 changes
- have the mux-controller in the parent node of any mux-controller consumer,
to hopefully satisfy complaint from Rob about dt complexity.
- improve commit message of the mux subsystem commit,
When a multiplexer changes how an iio device behaves (for example
by feeding different signals to an ADC), this driver can be used
create one virtual iio channel for each multiplexer state.
Depends on the generic multiplexer subsystem.
Cache any ext_info values from the parent iio channel, creati
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/i2c/i2c-mux-simple.txt | 76 ++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt
b/Do
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/misc/mux-controller.txt| 76 +
.../devicetree/bindings/misc/mux-gpio.txt | 78 ++
MAINTAINERS| 5 ++
3 files changed, 159 insertions(+)
create mode
This is a generic simple i2c mux that uses the generic multiplexer
subsystem to do the muxing.
The user can select if the mux is to be mux-locked and parent-locked
as described in Documentation/i2c/i2c-topology.
Signed-off-by: Peter Rosin
---
drivers/i2c/muxes/Kconfig | 13 +++
driver
Signed-off-by: Peter Rosin
---
.../bindings/iio/multiplexer/iio-mux.txt | 47 ++
MAINTAINERS| 6 +++
2 files changed, 53 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
diff --
Add a new minimalistic subsystem that handles multiplexer controllers.
When multiplexers are used in various places in the kernel, and the
same multiplexer controller can be used for several independent things,
there should be one place to implement support for said multiplexer
controller.
A singl
Extend the inkern api with functions for reading and writing ext_info
of iio channels.
Signed-off-by: Peter Rosin
---
drivers/iio/inkern.c | 55
include/linux/iio/consumer.h | 37 +
2 files changed, 92 insertions(+)
Em Mon, 21 Nov 2016 11:39:41 +0100
Johannes Berg escreveu:
> On Sat, 2016-11-19 at 10:15 -0700, Jonathan Corbet wrote:
> >
> > I don't know what the ultimate source of these images is (Mauro,
> > perhaps you could shed some light there?).
>
> I'd argue that it probably no longer matters. Whet
-abstraction-and-iio-i2c-muxes/20161121-215311
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drive
> > > You had pointed me to this plugin before
> > > https://pythonhosted.org/sphinxcontrib-aafig/
> > >
> > > but I don't think it can actually represent any of the pictures.
> >
> > No, but there are some ascii art images inside some txt/rst files
> > and inside some kernel-doc comments. We co
On Mon, 21 Nov 2016, Johannes Berg wrote:
> I had a hack elsewhere that would embed the fixed-width text if the
> plugin isn't present, which seemed like a decent compromise, but nobody
> is willing to let plugins be used in general to start with, it seems :)
FWIW I'm all for doing this stuff in
On Mon, 2016-11-21 at 12:06 -0200, Mauro Carvalho Chehab wrote:
> Em Mon, 21 Nov 2016 11:39:41 +0100
> Johannes Berg escreveu:
> > On Sat, 2016-11-19 at 10:15 -0700, Jonathan Corbet wrote:
> >
> > > Rather than beating our heads against the wall trying to convert
> > > between various image forma
On Mon, Nov 21, 2016 at 08:53:17AM -0200, Mauro Carvalho Chehab wrote:
> Inserting images with Sphinx is tricky, due to its limited
> image support. So, the Kernel building system needs to
> provide some help for it to work.
>
> Document how to do it.
>
> Signed-off-by: Mauro Carvalho Chehab
> -
On Mon, Nov 21, 2016 at 08:51:55AM -0200, Mauro Carvalho Chehab wrote:
> Em Mon, 21 Nov 2016 11:21:27 +0100
> Daniel Vetter escreveu:
>
> > On Mon, Nov 21, 2016 at 07:48:50AM -0200, Mauro Carvalho Chehab wrote:
> > > Not only media documents may have images. So, move the
> > > rules for building
On Sun, 20 Nov 2016 14:08:31 -0200
Mauro Carvalho Chehab wrote:
> The goal of this patch series is to get rid of PNG images, using either
> graphviz
> or SVG for images.
>
> For old images generated with xfig, stored inside PDF, just convert them to
> SVG
> and cleanup the images using inkscap
On Sat, 19 Nov 2016 16:22:28 -0200
Mauro Carvalho Chehab wrote:
> Nothing really prevents us to maintain the contents in separate, but
> that would make it harder to maintain, as, if we change something,
> we'll have two files to touch. Yet, I suspect that we won't be doing
> too much changes th
Em Mon, 21 Nov 2016 10:44:44 -0700
Jonathan Corbet escreveu:
> On Sun, 20 Nov 2016 14:08:31 -0200
> Mauro Carvalho Chehab wrote:
>
> > The goal of this patch series is to get rid of PNG images, using either
> > graphviz
> > or SVG for images.
> >
> > For old images generated with xfig, stored
Em Mon, 21 Nov 2016 10:48:30 -0700
Jonathan Corbet escreveu:
> On Sat, 19 Nov 2016 16:22:28 -0200
> Mauro Carvalho Chehab wrote:
>
> > Nothing really prevents us to maintain the contents in separate, but
> > that would make it harder to maintain, as, if we change something,
> > we'll have two
Not only media documents may have images. So, move the
rules for building images from graphviz and from SVG to
the Documentation makefile.
With this change, if some Documentation subdir "foo"
can now specify that he has SVG and/or DOT source images
that are included inside the documentation.
All
Inserting images with Sphinx is tricky, due to its limited
image support. So, the Kernel building system needs to
provide some help for it to work.
Document how to do it.
Signed-off-by: Mauro Carvalho Chehab
---
v2: Add the text fixes proposed by Daniel Vetter.
Documentation/doc-guide/images.
Em Mon, 21 Nov 2016 17:03:55 +0100
Daniel Vetter escreveu:
> On Mon, Nov 21, 2016 at 08:53:17AM -0200, Mauro Carvalho Chehab wrote:
> > Inserting images with Sphinx is tricky, due to its limited
> > image support. So, the Kernel building system needs to
> > provide some help for it to work.
> >
Em Mon, 21 Nov 2016 16:44:28 +0100
Johannes Berg escreveu:
> > > > You had pointed me to this plugin before
> > > > https://pythonhosted.org/sphinxcontrib-aafig/
> > > >
> > > > but I don't think it can actually represent any of the pictures.
> > >
> > > No, but there are some ascii art image
30 matches
Mail list logo
