On Wed 2018-10-10 19:22:47, Lubomir Rintel wrote:
> It doesn't make sense to always have this built-in, e.g. on ARM
> multiplatform kernels. A better way to address the problem the original
> commit aimed to solve is to fix Kconfig.
>
> This reverts commit f48d1496b8537d75776478c6942dd87f34d7f270.
temperature: 236.9 degrees C
>
> Tested on OLPC XO-1 and OLPC XO-1.75 laptops.
>
> [1] include/linux/power_supply.h
> [2] Documentation/power/power_supply_class.txt
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
&g
and when does it wish to respond with a command (the
> cmd-gpio property).
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> .../bindings/misc/olpc,xo1.75-ec.txt | 24 +++
> 1 file changed, 24 insertions(+)
> create mode 100644
On Wed 2018-10-10 19:22:49, Lubomir Rintel wrote:
> Also, the header is x86 specific, while there are non-x86 OLPC machines.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> drivers/platform/olpc/olpc-ec.c | 1 -
> 1 file changed, 1 deletion(-)
>
&
On Wed 2018-10-10 19:22:50, Lubomir Rintel wrote:
> There are ARM OLPC machines that use mostly the same drivers, including
> EC infrastructure, DCON and Battery.
>
> While at that, fix Kconfig to allow building this as a module.
>
> Signed-off-by: Lubomir Rintel
Acke
On Wed 2018-10-10 19:22:52, Lubomir Rintel wrote:
> Just return ENODEV, so that whoever attempted to use the EC call can
> defer their work.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> drivers/platform/olpc/olpc-ec.c | 7 +--
> 1 file change
On Wed 2018-10-10 19:22:53, Lubomir Rintel wrote:
> It is actually plaform independent. Move it to the olpc-ec driver from
> the X86 OLPC platform, so that it could be used by the ARM based laptops
> too.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
--
On Wed 2018-10-10 19:22:55, Lubomir Rintel wrote:
> The XO-1 and XO-1.5 batteries apparently differ in an ability to report
> ambient temperature.
>
> Signed-off-by: Lubomir Rintel
> Reviewed-by: Rob Herring
Acked-by: Pavel Machek
Rob, can you
On Wed 2018-10-10 19:22:56, Lubomir Rintel wrote:
> The XO-1 and XO-1.5 batteries apparently differ in an ability to report
> ambient temperature. Add a different compatible string to the 1.5
> battery.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> a
On Wed 2018-10-10 19:22:57, Lubomir Rintel wrote:
> Avoid using the x86 OLPC platform specific call to get the board
> version. It won't work on FDT-based ARM MMP2 platform.
>
> Signed-off-by: Lubomir Rintel
> Reviewed-by: Andy Shevchenko
Acked-by: Pavel Machek
AFAICT, th
Hi!
> The global variables for private data are not too nice. I'd like some
> more, and that would clutter the global name space even further.
>
> Signed-off-by: Lubomir Rintel
> Reviewed-by: Andy Shevchenko
Ok...
> - olpc_bat = power_supply_register(&pdev->dev, &olpc_bat_desc, NULL);
> -
On Wed 2018-10-10 19:22:59, Lubomir Rintel wrote:
> This wouldn't work on the DT-based ARM platform. Let's read the EC version
> directly from the EC driver instead.
>
> This makes the driver no longer x86 specific.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel
On Wed 2018-10-10 19:23:00, Lubomir Rintel wrote:
> The battery and the protocol are essentially the same as OLPC XO 1.5,
> but the responses from the EC are LSB first.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelm
On Wed 2018-11-14 22:17:04, David Hildenbrand wrote:
> The content of pages that are marked PG_offline is not of interest
> (e.g. inflated by a balloon driver), let's skip these pages.
>
> Cc: "Rafael J. Wysocki"
Acked-by: Pavel Machek
> diff --git a/kernel/p
Hi!
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> >
> > Easy to maintain when it's sorted.
No / it dep
On Mon 2018-11-19 11:16:15, David Hildenbrand wrote:
> Let's use pfn_to_online_page() instead of pfn_to_page() when checking
> for saveable pages to not save/restore offline memory sections.
>
> Cc: "Rafael J. Wysocki"
Acked-by: Pavel Machek
--
(english)
Hi!
> Use the gpiod interface instead of the deprecated old non-descriptor
> interface in olpc_dcon_xo_1.c.
>
> Signed-off-by: Nishad Kamdar
You may want to cc: lkund...@v3.sk, he was doing great work on OLPC
lately...
Best regards,
Hi!
> - Need to validate the uAPI and document it before moving
>this driver out of staging.
> - Stabilize and document its sysfs interface.
Would you mind starting with this one? We should have existing APIs
for most of functionality described...
We really don't want to merge code wit
Hi!
> > > - Need to validate the uAPI and document it before moving
> > >this driver out of staging.
> >
> > > - Stabilize and document its sysfs interface.
> >
> > Would you mind starting with this one?
>
> Do you mean writing the ABI document for it? Surely I can do that,
> but I
Hi!
> + /*
> + * on-disk error, let's only BUG_ON in the debugging mode.
> + * otherwise, it will return 1 to just skip the invalid name
> + * and go on (in consideration of the lookup performance).
> + */
> + DBG_BUGON(qd->name > qd->end);
I believe you should check f
Hi!
> > > + /*
> > > + * on-disk error, let's only BUG_ON in the debugging mode.
> > > + * otherwise, it will return 1 to just skip the invalid name
> > > + * and go on (in consideration of the lookup performance).
> > > + */
> > > + DBG_BUGON(qd->name > qd->end);
> >
> > I believe you should
Hi!
> The Greybus code has long been "stable" but was living in the
> drivers/staging/ directory to see if there really was going to be
> devices using this protocol over the long-term. With the success of
> millions of phones with this hardware and code in it, and the recent
So, what phones do
Hi!
> > +struct erofs_super_block {
> > +/* 0 */__le32 magic; /* in the little endian */
> > +/* 4 */__le32 checksum;/* crc32c(super_block) */
> > +/* 8 */__le32 features;/* (aka. feature_compat) */
> > +/* 12 */__u8 blkszbits; /* support block_size == PAGE_SIZ
Hi!
> > > Rather than they didn't run "gdb" or "pahole" and change it by mistake.
> >
> > I think Christoph is not right here.
> >
> > Using external tools for validation is extra work
> > when necessary for understanding the code.
>
> The advantage of using the external tools that the informat
Hi!
> > No. gdb tells you what the actual offsets _are_.
>
> Ok, reading your reply twice, I think we have different perspectives. I
> don't trust the comments.
>
> The tool I had in mind is pahole that parses dwarf information about the
> structures, the same as gdb does. The actual value of th
Hi!
> > There's currently 6 filesystems that have the same #define. Move it
> > into errno.h so it's defined in just one place.
> >
> > Signed-off-by: Valdis Kletnieks
> > Acked-by: Darrick J. Wong
> > Reviewed-by: Jan Kara
> > Acked-by: Theodore Ts'o
>
> > fs/erofs/internal.h
On Sat 2014-11-15 21:12:18, Konrad Zapalowicz wrote:
> On 11/15, Christian Resell wrote:
> > Simple style fix (checkpatch.pl: "space prohibited before that ','").
> > For the eudyptula challenge (http://eudyptula-challenge.org/).
>
> Nice, however we do not need the information about the 'eudyptul
On Wed 2014-12-17 09:32:16, Greg KH wrote:
> On Wed, Dec 17, 2014 at 10:54:49AM -0600, at...@opensource.altera.com wrote:
> > From: Alan Tull
> >
> > Enable FPGA manager for Altera socfpga.
> >
> > Signed-off-by: Alan Tull
> > ---
> > v5: s/CONFIG_FPGA_MGR_ALTERA/CONFIG_FPGA_MGR_SOCFPGA/
> > --
Hi!
On Mon 2014-12-15 11:32:22, Greg KH wrote:
> On Mon, Dec 15, 2014 at 08:04:53PM +0100, Richard Weinberger wrote:
> > > Fact is, this is useful code, in this area. In the domain it is used
> > > in, it works properly, and the abi is sufficient. Yes, it's ugly in
> > > spaces, and insecure if
On Mon 2014-12-15 10:41:03, Greg KH wrote:
> On Mon, Dec 15, 2014 at 10:39:15AM -0800, Christoph Hellwig wrote:
> > On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote:
> > > I don't understand this kind of logic.
> > > a) Binder is considered a piece of shite.
> > > b) Google is wor
> +What:/sys/class/fpga_manager//firmware
> +Date:October 2014
> +KernelVersion: 3.18
> +Contact: Alan Tull
> +Description: Name of the FPGA image file to load using firmware class.
This is wrong interface, right? The only use of this string is to pass
i
On Tue 2015-01-06 14:13:37, at...@opensource.altera.com wrote:
> From: Alan Tull
>
> Add documentation under drivers/staging for new fpga manager's
> sysfs interface.
>
> Signed-off-by: Alan Tull
> ---
> v5 : (actually second version, but keeping version numbers
> aligned with rest of pa
On Fri 2015-01-09 13:14:24, atull wrote:
> On Wed, 7 Jan 2015, Pavel Machek wrote:
>
> > On Tue 2015-01-06 14:13:37, at...@opensource.altera.com wrote:
> > > +
> > > +What:/sys/class/fpga_manager//firmware
> > > +Date:Oc
On Sat 2015-01-10 10:10:51, Pantelis Antoniou wrote:
> Hi Pavel,
>
> > On Jan 9, 2015, at 22:56 , Pavel Machek wrote:
> >
> > On Fri 2015-01-09 13:14:24, atull wrote:
> >> On Wed, 7 Jan 2015, Pavel Machek wrote:
> >>
> >>> On Tue
On Sun 2015-01-11 17:24:26, Konrad Zapalowicz wrote:
> On 01/11, atull wrote:
> > On Sat, 10 Jan 2015, Konrad Zapalowicz wrote:
> >
> > > On 01/06, at...@opensource.altera.com wrote:
> > > > From: Alan Tull
> > >
> > > Alan, there is something wrong with your email client configuration
> > > and
On Sun 2015-01-11 21:58:00, Konrad Zapalowicz wrote:
> On 01/11, Pavel Machek wrote:
> > On Sun 2015-01-11 17:24:26, Konrad Zapalowicz wrote:
> > > On 01/11, atull wrote:
> > > > On Sat, 10 Jan 2015, Konrad Zapalowicz wrote:
> > > >
> > &
On Sun 2015-01-11 10:29:00, atull wrote:
> On Sat, 10 Jan 2015, Pavel Machek wrote:
>
> > On Sat 2015-01-10 10:10:51, Pantelis Antoniou wrote:
> > > Hi Pavel,
> > >
> > > > On Jan 9, 2015, at 22:56 , Pavel Machek wrote:
> > > >
> >
Hi!
> +What: /sys/class/fpga_manager//firmware
> +Date: October 2014
> +KernelVersion: 3.18
> +Contact:Alan Tull
> +Description:Name of the FPGA image file to load using
> firmware
> class
On Tue 2015-01-13 09:40:18, Pantelis Antoniou wrote:
> Hi Pavel,
>
> > On Jan 13, 2015, at 09:28 , Pavel Machek wrote:
> >
> > Hi!
> >
> >>>>>>>>>> +What: /sys/class/fpga_manager//firmware
> >>>&
On Tue 2015-01-13 16:21:33, One Thousand Gnomes wrote:
> On Mon, 12 Jan 2015 11:06:08 -0700
> Jason Gunthorpe wrote:
>
> > On Sun, Jan 11, 2015 at 10:29:00AM -0600, atull wrote:
> > > the FPGA image. If someone wants there to be only one FPGA image on
> > > the FGPA forever, they will probably n
Hi!
> I'm looking into moving the sysfs interface to debugfs. Doesn't look too
> hard and you and Alan are making lots of sense about this.
Debugfs: please don't. That's meant for debugging, not for production
use.
Pavel
--
On Wed 2019-06-19 17:46:48, Lukas Schneider wrote:
> This patch fixes the issue reported by checkpatch:
>
> CHECK: usleep_range is preferred over udelay;
> see Doucmentation/timers/timers-howto.txt
>
> It's save to sleep here instead of using busy waiting,
> because we are not in an atomic contex
On Thu 2019-07-11 22:57:31, Gao Xiang wrote:
> Changelog from v1:
> o resend the whole filesystem into a patchset suggested by Greg;
> o code is more cleaner, especially for decompression frontend.
>
> --8<--
>
> Hi,
>
> EROFS file system has been in Linux-staging for about a year.
> I
Hi!
> >> Changelog from v1:
> >> o resend the whole filesystem into a patchset suggested by Greg;
> >> o code is more cleaner, especially for decompression frontend.
> >>
> >> --8<--
> >>
> >> Hi,
> >>
> >> EROFS file system has been in Linux-staging for about a year.
> >> It has been pr
_ENT_F_MUX``
And you probably want to rename it here, too.
With that fixed:
Reviewed-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital sig
On Wed 2017-02-15 18:19:16, Steve Longerbeam wrote:
> v4l2_pipeline_inherit_controls() will add the v4l2 controls from
> all subdev entities in a pipeline to a given video device.
>
> Signed-off-by: Steve Longerbeam
Reviewed-by: Pavel Machek
--
(english) http://www.liv
Hi!
> From: Philipp Zabel
>
> This driver can handle SoC internal and external video bus multiplexers,
> controlled either by register bit fields or by a GPIO. The subdevice
> passes through frame interval and mbus configuration of the active input
> to the output side.
>
> Signed-off-by: Sasch
Hi!
> > Plus you might want to describe which port correspond to which gpio
> > state/bitfield values...
> >
> > > +struct vidsw {
> >
> > I knew it: it is secretely a switch! :-).
>
> This driver started as a two-input gpio controlled bus switch.
> I changed the name when adding support for bi
Hi!
> Argh! that is indeed a bug at libv4l (and maybe at gstreamer).
>
> I guess that the always_needs_conversion logic was meant to be used to
> really odd proprietary formats, e. g:
>
> /* Vendor-specific formats */
> #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cp
On Fri 2017-03-10 16:17:28, Fabio Estevam wrote:
> On Fri, Mar 10, 2017 at 3:59 PM, Troy Kisky
> wrote:
> > On 3/9/2017 8:52 PM, Steve Longerbeam wrote:
> >> There is a pin conflict with GPIO_6. This pin functions as a power
> >> input pin to the OV5642 camera sensor, but ENET uses it as the h/w
>
On Fri 2017-03-10 10:37:21, Steve Longerbeam wrote:
> Hi Hans,
>
> On 03/10/2017 04:03 AM, Hans Verkuil wrote:
> >On 10/03/17 05:52, Steve Longerbeam wrote:
> >>Add a new FRAME_INTERVAL_ERROR event to signal that a video capture or
> >>output device has measured an interval between the reception o
Hi!
> diff --git a/include/uapi/media/Kbuild b/include/uapi/media/Kbuild
> index aafaa5a..fa78958 100644
> --- a/include/uapi/media/Kbuild
> +++ b/include/uapi/media/Kbuild
> @@ -1 +1,2 @@
> # UAPI Header export list
> +header-y += imx.h
> diff --git a/include/uapi/media/imx.h b/include/uapi/medi
Hi!
> >>I tend to agree with that.
> >
> >I agree as well.
> >
> >This is in line with how existing drivers behave, too.
>
>
> Well, sounds like there is consensus on this topic. I guess I'll
> go ahead and remove the control inheritance support. I suppose
> having a control appear in two places
Hi!
> > > Ok, perhaps supporting both subdev API and V4L2 API at the same
> > > time doesn't make much sense. We could disable one in favor of the
> > > other, either at compilation time or at runtime.
> >
> > Right. If the subdev API is disabled, then you have to inherit the subdev
> > control
Hi!
> > > The rationale is that we should support the simplest use cases first.
> > >
> > > In the case of the first MC-based driver (and several subsequent
> > > ones), the simplest use case required MC, as it was meant to suport
> > > a custom-made sophisticated application that required fine c
On Sun 2017-03-12 07:37:45, Russell King - ARM Linux wrote:
> On Sat, Mar 11, 2017 at 07:31:18PM -0800, Steve Longerbeam wrote:
> >
> >
> > On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
> > >On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
> > >>
> > >>
> > >>On 03/11/2
On Sat 2017-03-11 23:14:56, Russell King - ARM Linux wrote:
> On Sat, Mar 11, 2017 at 08:25:49AM -0300, Mauro Carvalho Chehab wrote:
> > This situation is there since 2009. If I remember well, you tried to write
> > such generic plugin in the past, but never finished it, apparently because
> > it i
Hi!
> > Mid-layer is difficult... there are _hundreds_ of possible
> > pipeline setups. If it should live in kernel or in userspace is a
> > question... but I don't think having it in kernel helps in any way.
>
> Mid-layer is difficult, because we either need to feed some
> library with knowledge
On Mon 2017-03-13 10:45:38, Russell King - ARM Linux wrote:
> On Mon, Mar 13, 2017 at 11:02:34AM +0100, Hans Verkuil wrote:
> > On 03/11/2017 07:14 PM, Steve Longerbeam wrote:
> > > The event must be user visible, otherwise the user has no indication
> > > the error, and can't correct it by stream
Hi!
> > > Even if they were merged, if we keep the same mean time to develop a
> > > libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3
> > > years to be developed.
> > >
> > > There's a clear message on it:
> > > - we shouldn't keep pushing for a solution via libv4l.
> >
Hi!
> > Well, I believe first question is: what applications would we want to
> > run on complex devices? Will sending control from video to subdevs
> > actually help?
>
> I would say: camorama, xawtv3, zbar, google talk, skype. If it runs
> with those, it will likely run with any other applicati
Hi!
> > > > mplayer is useful for testing... but that one already works (after you
> > > > setup the pipeline, and configure exposure/gain).
> > > >
> > > > But thats useful for testing, not really for production. Image will be
> > > > out of focus and with wrong white balance.
> > > >
> > > > W
Hi!
>
> Hah! That's the joy of being a maintainer of a driver in staging. Even
> if you filter out outreachy, you are going to get a lot of "basic
> mistakes" and other type patches cc:ed to you.
>
> I strongly suggest, that if you all don't like this type of stuff,
> either:
> - work to
On Fri 2017-03-17 11:42:03, Russell King - ARM Linux wrote:
> On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
> > We're all very driver-development-driven, and userspace gets very little
> > attention in general. So before just throwing in the towel we should take
> > a good look at t
Hi!
> > > Hah! That's the joy of being a maintainer of a driver in staging. Even
> > > if you filter out outreachy, you are going to get a lot of "basic
> > > mistakes" and other type patches cc:ed to you.
> > >
> > > I strongly suggest, that if you all don't like this type of stuff,
> > > eithe
On Mon 2017-03-20 11:30:08, Greg KH wrote:
> On Mon, Mar 20, 2017 at 11:20:32AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > > Hah! That's the joy of being a maintainer of a driver in staging.
> > > > > Even
> > > > >
Hi!
> > Making use of the full potential of the hardware requires using a more
> > expressive interface.
>
> That's the core of the problem: most users don't need "full potential
> of the hardware". It is actually worse than that: several boards
> don't allow "full potential" of the SoC capabili
Hi!
> > I do agree with you that MC places a lot of burden on the user to
> > attain a lot of knowledge of the system's architecture.
>
> Setting up the pipeline is not the hard part. One could write a
> script to do that.
Can you try to write that script? I believe it would solve big part of
t
ed-but-set-variable]
> int err, skip_release = 0;
>^
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Pavel Machek
> diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
> b/drivers/staging/media/bcm2048/radio-bcm2048.c
> index e9d0691b21d3..5e11
Hi!
> + * video stream multiplexer controlled via gpio or syscon
> + *
> + * Copyright (C) 2013 Pengutronix, Sascha Hauer
> + * Copyright (C) 2016 Pengutronix, Philipp Zabel
This is actually quite interesting. Same email address for two
people...
Plus, I believe this wants to say that copyrigh
Hi!
> +https://boundarydevices.com/products/nit6x_5mp
I'd use /product/ in url, as it redirects there.
> +https://boundarydevices.com/product/nit6x_5mp_mipi
..and for consistency.
> +The following example configures a direct conversion pipeline to capture
> +from the OV5640, transmitting on M
Hi!
> +References
> +--
> +
> +[1] "i.MX 6Dual/6Quad Applications Processor Reference Manual"
> +[2] "i.MX 6Solo/6DualLite Applications Processor Reference Manual"
[2] is not present in the text above. [1] is there many times. What is
purpose of this section?
On Wed 2017-04-05 13:58:39, Lucas Stach wrote:
> Am Mittwoch, den 05.04.2017, 13:18 +0200 schrieb Pavel Machek:
> > Hi!
> >
> > > + * video stream multiplexer controlled via gpio or syscon
> > > + *
> > > + * Copyright (C) 2013 Pengutronix, Sascha Hauer
Hi!
> > The MUX framework is already in linux-next. Could you use that instead of
> > adding new driver + bindings that are not compliant with the MUX framework?
> > I don't think it'd be much of a change in terms of code, using the MUX
> > framework appears quite simple.
>
> It is not quite clea
Hi!
> That self-referencing mux-controls property looks a bit superfluous:
>
> mux: video-multiplexer {
> mux-controls = <&mux>;
> };
>
> Other than that, I'm completely fine with splitting the compatible into
> something like video-mux-gpio and video-mux-mmio and reusi
Hi!
> +/* min/typical/max system clock (xclk) frequencies */
> +#define OV5640_XCLK_MIN 600
> +#define OV5640_XCLK_MAX 2400
> +
> +/*
> + * FIXME: there is no subdev API to set the MIPI CSI-2
> + * virtual channel yet, so this is hardcoded for now.
> + */
> +#define OV5640_MIPI_VC 1
Hi!
> >If there's a need for this (there should not be, as the controls are exposed
> >to the user space through the sub-device nodes as the other drivers do), the
> >framework APIs need to be extended.
>
> Right, this gets back to the media framework usability arguments. At least
> myself, Phili
Hi!
> > > + /* Auto/manual exposure */
> > > + ctrls->auto_exp = v4l2_ctrl_new_std_menu(hdl, ops,
> > > + V4L2_CID_EXPOSURE_AUTO,
> > > + V4L2_EXPOSURE_MANUAL, 0,
> > > + V4L2
Hi!
> >>>+ /* Auto/manual exposure */
> >>>+ ctrls->auto_exp = v4l2_ctrl_new_std_menu(hdl, ops,
> >>>+ V4L2_CID_EXPOSURE_AUTO,
> >>>+ V4L2_EXPOSURE_MANUAL, 0,
> >>>+ V4L2
Hi!
> > > According to the docs V4L2_CID_EXPOSURE_ABSOLUTE is in 100 usec units.
> > >
> > > OTOH V4L2_CID_EXPOSURE has no defined unit, so it's a better fit IMO.
> > > >Way more drivers appear to be using EXPOSURE than EXPOSURE_ABSOLUTE, too.
> > >
> > > Done, switched to V4L2_CID_EXPOSURE. It
On Thu 2017-06-08 13:36:12, Steve Longerbeam wrote:
>
>
> On 06/08/2017 01:25 PM, Tim Harvey wrote:
> >
> >
> >Steve,
> >
> >You need to remove the fim node now that you've moved this to V4L2 controls.
> >
>
> Yep, I caught this just after sending the v8 patchset. I'll send
> a v9 of this patch.
Hi!
> >>>Steve,
> >>>
> >>>You need to remove the fim node now that you've moved this to V4L2
> >>>controls.
> >>>
> >>
> >>Yep, I caught this just after sending the v8 patchset. I'll send
> >>a v9 of this patch.
> >
> >This needs ack from devicetree people, then it can be merged. Can you
> >be a
Hi!
> >> Other than that everything is ready AFAICT.
> >>
> >
> > But as Pavel pointed out, in fact we are missing many
> > Acks still, for all of the dts source changes (patches
> > 4-14), as well as really everything else (imx-media staging
> > driver patches).
>
> No Acks needed for the stagi
Hi!
> >> But as Pavel pointed out, in fact we are missing many
> >> Acks still, for all of the dts source changes (patches
> >> 4-14), as well as really everything else (imx-media staging
> >> driver patches).
> >
> > No Acks needed for the staging part. It's staging, so not held
> > to the same
On Tue 2017-06-20 08:05:05, Fabio Estevam wrote:
> On Tue, Jun 20, 2017 at 5:29 AM, Pavel Machek wrote:
>
> > Hmm. I changed the subject to grab Shawn's attetion.
> >
> > But his acks should not be needed for forward progress. Yes, it would
> > be good, but h
On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> Intel(R) SGX is a set of CPU instructions that can be used by
> applications to set aside private regions of code and data. The code
> outside the enclave is disallowed to access the memory inside the
> enclave by the CPU access control.
>
> Th
On Tue 2016-04-26 12:05:48, Andy Lutomirski wrote:
> On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek wrote:
> > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> >> Intel(R) SGX is a set of CPU instructions that can be used by
> >> applications to set aside priva
Hi!
> >> >> The firmware uses PRMRR registers to reserve an area of physical memory
> >> >> called Enclave Page Cache (EPC). There is a hardware unit in the
> >> >> processor called Memory Encryption Engine. The MEE encrypts and decrypts
> >> >> the EPC pages as they enter and leave the processor
On Tue 2016-04-26 21:59:52, One Thousand Gnomes wrote:
> > But... that will mean that my ssh will need to be SGX-aware, and that
> > I will not be able to switch to AMD machine in future. ... or to other
> > Intel machine for that matter, right?
>
> I'm not privy to AMD's CPU design plans.
>
> Ho
Hi!
> > > Preventing cold boot attacks is really just icing on the cake. The
> > > real point of this is to allow you to run an "enclave". An SGX
> > > enclave has unencrypted code but gets access to a key that only it can
> > > access. It could use that key to unwrap your ssh private key and s
Hi!
On Fri 2016-04-29 23:17:44, Jarkko Sakkinen wrote:
> On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
> > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> > > The firmware uses PRMRR registers to reserve an area of physical memory
> > > called Encl
On Wed 2016-04-27 13:27:08, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct sync_merge_data already have documentation on top of the
> struct definition. No need to duplicate it.
>
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Maarten Lankhorst
> @@ -33,8 +33,8 @@ struct sync_merg
Hi!
> -}
> -EXPORT_SYMBOL(sync_file_merge);
> -
> static const char *android_fence_get_driver_name(struct fence *fence)
> {
> struct sync_timeline *parent = fence_parent(fence);
if this is meant to be used outside android, should it select some
better prefix than android_fence_?
Thanks,
Hi!
> We have been following and analyzing this technology since the first
> HASP paper was published detailing its development. We have been
(1)
>
> I told my associates the first time I reviewed this technology that
> SGX has the ability to be a bit of a Pandora's box and it seems to be
> fo
Hi!
> Good morning, I hope everyone's day is starting out well.
:-). Rainy day here.
> > > In the TL;DR department I would highly recommend that anyone
> > > interested in all of this read MIT's 170+ page review of the
> > > technology before jumping to any conclusions :-)
>
> > Would you h
On Fri 2016-05-06 01:52:04, Jarkko Sakkinen wrote:
> On Mon, May 02, 2016 at 11:37:52AM -0400, Austin S. Hemmelgarn wrote:
> > On 2016-04-29 16:17, Jarkko Sakkinen wrote:
> > >On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
> > >>On Mon 2016-04-25 2
> +Optional properties:
> +- fpga-mgr : should contain a phandle to a fpga manager.
fpga->FPGA, globally.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
devel
On Fri 2015-07-17 10:51:11, at...@opensource.altera.com wrote:
> From: Alan Tull
>
> Add a document on the new FPGA manager core.
>
> --- /dev/null
> +++ b/drivers/staging/fpga/Documentation/fpga-mgr.txt
> @@ -0,0 +1,117 @@
> + FPGA Manager Core
> +
> + Alan Tull 2015
> +
> + Overview
> + -
On Fri 2015-07-17 10:51:12, at...@opensource.altera.com wrote:
> From: Alan Tull
>
> Add a document spelling out usage of the simple fpga bus.
> +The DT overlay includes bindings (documented in bindings/simple-fpga-bus.txt)
> +that specify:
> + * Which fpga manager to use
fpga->FPGA, globally.
Hi!
> +What:/sys/class/fpga_manager//state
> +Date:July 2015
> +KernelVersion: 4.2
> +Contact: Alan Tull
> +Description: Read fpga manager state as a string.
fpga->FPGA.
> + Valid states may vary by manufacturer; superset is:
> +
1 - 100 of 155 matches
Mail list logo
