On Thu 24-08-17 15:58:01, Roman Gushchin wrote:
> On Thu, Aug 24, 2017 at 04:13:37PM +0200, Michal Hocko wrote:
> > On Thu 24-08-17 14:58:42, Roman Gushchin wrote:
[...]
> > > Both ways are not ideal, and sum of the processes is not ideal too.
> > > Especially, if you take oom_score_adj into accoun
On 24/08/17 14:07, Mauro Carvalho Chehab wrote:
> From: "mche...@s-opensource.com"
>
> When we added support for omap3, back in 2010, we added a new
> type of V4L2 devices that aren't fully controlled via the V4L2
> device node. Yet, we never made it clear, at the V4L2 spec,
> about the differenc
Em Fri, 25 Aug 2017 10:59:40 +0200
Hans Verkuil escreveu:
> On 24/08/17 14:07, Mauro Carvalho Chehab wrote:
> > From: "mche...@s-opensource.com"
> >
> > When we added support for omap3, back in 2010, we added a new
> > type of V4L2 devices that aren't fully controlled via the V4L2
> > device no
Em Thu, 24 Aug 2017 18:07:48 +0300
Sakari Ailus escreveu:
> Hi Mauro,
>
> Thanks for the update! A few comments below.
>
> (Cc Hans and Laurent.)
>
> On Thu, Aug 24, 2017 at 09:07:35AM -0300, Mauro Carvalho Chehab wrote:
> > From: "mche...@s-opensource.com"
> >
> > When we added support for
From: "mche...@s-opensource.com"
When we added support for omap3, back in 2010, we added a new
type of V4L2 devices that aren't fully controlled via the V4L2
device node. Yet, we never made it clear, at the V4L2 spec,
about the differences between both types.
Let's document them with the current
From: Mauro Carvalho Chehab
Those devices are controlled via their V4L2 device. Add a
flag to indicate them as such.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/pci/bt8xx/bttv-driver.c | 4 +++-
drivers/media/pci/cobalt/cobalt-v4l2.c
From: Mauro Carvalho Chehab
As both vdev-centric and mc-centric devices may implement the
same APIs, we need a flag to allow userspace to distinguish
between them.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/media/uapi/v4l/open.rst|
On 2010, we introduced a new way to control complex V4L2 devices used
on embedded systems, but this was never documented, nor it is possible
for an userspace applicatin to detect the kind of control a device supports.
This series fill the gap.
Mauro Carvalho Chehab (3):
media: open.rst: documen
On Fri, 2017-08-25 at 06:40 -0300, Mauro Carvalho Chehab wrote:
> From: Mauro Carvalho Chehab
>
> Those devices are controlled via their V4L2 device. Add a
> flag to indicate them as such.
>
> Signed-off-by: Mauro Carvalho Chehab
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Lubomir Rintel
On 08/25/2017 11:40 AM, Mauro Carvalho Chehab wrote:
> From: Mauro Carvalho Chehab
>
> As both vdev-centric and mc-centric devices may implement the
> same APIs, we need a flag to allow userspace to distinguish
> between them.
>
> Signed-off-by: Mauro Carvalho Chehab
> Signed-off-by: Mauro Carv
Em Fri, 25 Aug 2017 11:44:27 +0200
Hans Verkuil escreveu:
> On 08/25/2017 11:40 AM, Mauro Carvalho Chehab wrote:
> > From: Mauro Carvalho Chehab
> >
> > As both vdev-centric and mc-centric devices may implement the
> > same APIs, we need a flag to allow userspace to distinguish
> > between them
On 08/25/2017 12:06 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 25 Aug 2017 11:44:27 +0200
> Hans Verkuil escreveu:
>
>> On 08/25/2017 11:40 AM, Mauro Carvalho Chehab wrote:
>>> From: Mauro Carvalho Chehab
>>>
>>> As both vdev-centric and mc-centric devices may implement the
>>> same APIs, we nee
Hi Sakari,
On Thursday, 24 August 2017 12:18:56 EEST Sakari Ailus wrote:
> On Wed, Aug 23, 2017 at 10:42:28AM -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 23 Aug 2017 12:37:30 +0300 Sakari Ailus escreveu:
> >> On Sat, Aug 19, 2017 at 07:04:40AM -0300, Mauro Carvalho Chehab wrote:
> >>> When we
On 25/08/17 11:40, Mauro Carvalho Chehab wrote:
> From: "mche...@s-opensource.com"
>
> When we added support for omap3, back in 2010, we added a new
> type of V4L2 devices that aren't fully controlled via the V4L2
> device node. Yet, we never made it clear, at the V4L2 spec,
> about the differenc
Em Fri, 25 Aug 2017 12:13:53 +0200
Hans Verkuil escreveu:
> On 08/25/2017 12:06 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 25 Aug 2017 11:44:27 +0200
> > Hans Verkuil escreveu:
> >
> >> On 08/25/2017 11:40 AM, Mauro Carvalho Chehab wrote:
> >>> From: Mauro Carvalho Chehab
> >>>
> >>> As
On Fri, Aug 25, 2017 at 10:14:03AM +0200, Michal Hocko wrote:
> On Thu 24-08-17 15:58:01, Roman Gushchin wrote:
> > On Thu, Aug 24, 2017 at 04:13:37PM +0200, Michal Hocko wrote:
> > > On Thu 24-08-17 14:58:42, Roman Gushchin wrote:
> [...]
> > > > Both ways are not ideal, and sum of the processes i
On 08/25/2017 12:35 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 25 Aug 2017 12:13:53 +0200
> Hans Verkuil escreveu:
>
>> On 08/25/2017 12:06 PM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 25 Aug 2017 11:44:27 +0200
>>> Hans Verkuil escreveu:
>>>
On 08/25/2017 11:40 AM, Mauro Carvalho Chehab
Em Fri, 25 Aug 2017 12:42:51 +0200
Hans Verkuil escreveu:
> On 08/25/2017 12:35 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 25 Aug 2017 12:13:53 +0200
> > Hans Verkuil escreveu:
> >
> >> On 08/25/2017 12:06 PM, Mauro Carvalho Chehab wrote:
> >>> Em Fri, 25 Aug 2017 11:44:27 +0200
> >>> Han
On 25/08/17 12:50, Mauro Carvalho Chehab wrote:
> Em Fri, 25 Aug 2017 12:42:51 +0200
> Hans Verkuil escreveu:
>
>> On 08/25/2017 12:35 PM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 25 Aug 2017 12:13:53 +0200
>>> Hans Verkuil escreveu:
>>>
On 08/25/2017 12:06 PM, Mauro Carvalho Chehab wrot
On Fri 25-08-17 11:39:51, Roman Gushchin wrote:
> On Fri, Aug 25, 2017 at 10:14:03AM +0200, Michal Hocko wrote:
> > On Thu 24-08-17 15:58:01, Roman Gushchin wrote:
> > > On Thu, Aug 24, 2017 at 04:13:37PM +0200, Michal Hocko wrote:
> > > > On Thu 24-08-17 14:58:42, Roman Gushchin wrote:
> > [...]
>
Hi David!
On Wed, Aug 23, 2017 at 04:19:11PM -0700, David Rientjes wrote:
> On Wed, 23 Aug 2017, Roman Gushchin wrote:
>
> > Traditionally, the OOM killer is operating on a process level.
> > Under oom conditions, it finds a process with the highest oom score
> > and kills it.
> >
> > This behav
Hi Mauro,
Thanks for the update. A few more small comments below.
On Fri, Aug 25, 2017 at 06:40:05AM -0300, Mauro Carvalho Chehab wrote:
> From: "mche...@s-opensource.com"
>
> When we added support for omap3, back in 2010, we added a new
> type of V4L2 devices that aren't fully controlled via t
Em Fri, 25 Aug 2017 12:56:30 +0200
Hans Verkuil escreveu:
> On 25/08/17 12:50, Mauro Carvalho Chehab wrote:
> > Em Fri, 25 Aug 2017 12:42:51 +0200
> > Hans Verkuil escreveu:
> >
> >> On 08/25/2017 12:35 PM, Mauro Carvalho Chehab wrote:
> >>> Em Fri, 25 Aug 2017 12:13:53 +0200
> >>> Hans Ver
Currently there are no ->swap_{in,out} method in address_space_operations
sructure definition, so the statement that anything is going to be proxied
through them is wrong.
Signed-off-by: Nikolay Borisov
---
Documentation/filesystems/vfs.txt | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-
Em Fri, 25 Aug 2017 08:15:03 -0300
Mauro Carvalho Chehab escreveu:
> Em Fri, 25 Aug 2017 12:56:30 +0200
> Hans Verkuil escreveu:
>
> > On 25/08/17 12:50, Mauro Carvalho Chehab wrote:
> > > Em Fri, 25 Aug 2017 12:42:51 +0200
> > > Hans Verkuil escreveu:
> > >
> > >> On 08/25/2017 12:35 P
Em Fri, 25 Aug 2017 08:30:37 -0300
Mauro Carvalho Chehab escreveu:
> Em Fri, 25 Aug 2017 08:15:03 -0300
> Mauro Carvalho Chehab escreveu:
>
> > Em Fri, 25 Aug 2017 12:56:30 +0200
> > Hans Verkuil escreveu:
> >
> > > On 25/08/17 12:50, Mauro Carvalho Chehab wrote:
> > > > Em Fri, 25 Aug 2017
On 25/08/17 13:35, Mauro Carvalho Chehab wrote:
> Em Fri, 25 Aug 2017 08:30:37 -0300
> Mauro Carvalho Chehab escreveu:
>
>> Em Fri, 25 Aug 2017 08:15:03 -0300
>> Mauro Carvalho Chehab escreveu:
>>
>>> Em Fri, 25 Aug 2017 12:56:30 +0200
>>> Hans Verkuil escreveu:
>>>
On 25/08/17 12:50, Maur
Hi Hans,
On Friday, 25 August 2017 11:59:40 EEST Hans Verkuil wrote:
> On 24/08/17 14:07, Mauro Carvalho Chehab wrote:
> > From: "mche...@s-opensource.com"
> >
> > When we added support for omap3, back in 2010, we added a new
> > type of V4L2 devices that aren't fully controlled via the V4L2
> >
On 2010, we introduced a new way to control complex V4L2 devices used
on embedded systems, but this was never documented, nor it is possible
for an userspace applicatin to detect the kind of control a device supports.
This series fill the gap.
Mauro Carvalho Chehab (3):
media: open.rst: better
From: "mche...@s-opensource.com"
When we added support for omap3, back in 2010, we added a new
type of V4L2 devices that aren't fully controlled via the V4L2
device node. Yet, we never made it clear, at the V4L2 spec,
about the differences between both types.
Let's document them with the current
Right now, only kAPI documentation describes the device naming.
However, such description is needed at the uAPI too. Add it,
and describe how to get an unique identify for a given device.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/media/uapi/v4l/open.rst | 40
From: Mauro Carvalho Chehab
As both vdev-centric and MC-centric devices may implement the
same APIs, we need a flag to allow userspace to distinguish
between them.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/media/uapi/v4l/open.rst|
Em Fri, 25 Aug 2017 09:52:40 -0300
Mauro Carvalho Chehab escreveu:
> Right now, only kAPI documentation describes the device naming.
> However, such description is needed at the uAPI too. Add it,
> and describe how to get an unique identify for a given device.
>
> Signed-off-by: Mauro Carvalho C
Hi Mauro,
Thank you for the patch.
On Friday, 25 August 2017 12:40:05 EEST Mauro Carvalho Chehab wrote:
> From: "mche...@s-opensource.com"
>
> When we added support for omap3, back in 2010, we added a new
> type of V4L2 devices that aren't fully controlled via the V4L2
> device node. Yet, we ne
Hi Mauro,
On Friday, 25 August 2017 13:06:32 EEST Mauro Carvalho Chehab wrote:
> Em Fri, 25 Aug 2017 11:44:27 +0200 Hans Verkuil escreveu:
> > On 08/25/2017 11:40 AM, Mauro Carvalho Chehab wrote:
> > > From: Mauro Carvalho Chehab
> > >
> > > As both vdev-centric and mc-centric devices may implem
On 25/08/17 14:52, Mauro Carvalho Chehab wrote:
> Right now, only kAPI documentation describes the device naming.
> However, such description is needed at the uAPI too. Add it,
> and describe how to get an unique identify for a given device.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Docum
Em Fri, 25 Aug 2017 16:11:15 +0300
Laurent Pinchart escreveu:
> Hi Mauro,
>
> Thank you for the patch.
>
> On Friday, 25 August 2017 12:40:05 EEST Mauro Carvalho Chehab wrote:
> > From: "mche...@s-opensource.com"
> >
> > When we added support for omap3, back in 2010, we added a new
> > type o
On 25/08/17 14:52, Mauro Carvalho Chehab wrote:
> From: "mche...@s-opensource.com"
>
> When we added support for omap3, back in 2010, we added a new
> type of V4L2 devices that aren't fully controlled via the V4L2
> device node. Yet, we never made it clear, at the V4L2 spec,
> about the differenc
Hi Mauro,
On Friday, 25 August 2017 16:38:23 EEST Mauro Carvalho Chehab wrote:
> Em Fri, 25 Aug 2017 16:11:15 +0300 Laurent Pinchart escreveu:
> > On Friday, 25 August 2017 12:40:05 EEST Mauro Carvalho Chehab wrote:
> >> From: "mche...@s-opensource.com"
> >>
> >> When we added support for omap3,
On 25/08/17 15:11, Laurent Pinchart wrote:
> Hi Mauro,
>
> Thank you for the patch.
>
> On Friday, 25 August 2017 12:40:05 EEST Mauro Carvalho Chehab wrote:
>> From: "mche...@s-opensource.com"
>>
>> When we added support for omap3, back in 2010, we added a new
>> type of V4L2 devices that aren't
On 08/24/2017 02:50 PM, John Stultz wrote:
> On Thu, Aug 24, 2017 at 6:42 AM, Prarit Bhargava wrote:
>> --- a/include/linux/timekeeping.h
>> +++ b/include/linux/timekeeping.h
>> @@ -239,6 +239,7 @@ static inline u64 ktime_get_raw_ns(void)
>> extern u64 ktime_get_mono_fast_ns(void);
>> extern u
On Fri, 25 Aug 2017 10:46:21 -0400
Prarit Bhargava wrote:
> np. I'm going to copy the code for
>
> u64 notrace ktime_get_boot_fast_ns(void)
>
> but I'm unsure why the function is marked "notrace", and if
> __ktime_get_real_fast_ns_unsafe() must be as well? I don't see anything in
> the
> gi
The documentation doesn't mention if vdev-centric hardware
control would have subdev API or not.
Add a notice about that, reflecting the current status, where
three drivers use it, in order to support some subdev-specific
controls.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/media/ua
As both vdev-centric and MC-centric devices may implement the
same APIs, we need a flag to allow userspace to distinguish
between them.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/media/uapi/v4l/open.rst| 7 +++
Documentation/media/uapi/v4l/vidioc-querycap.rst | 5
Add a glossary of terms for V4L2, as several concepts are complex
enough to cause misunderstandings.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/media/uapi/v4l/glossary.rst | 95 +++
Documentation/media/uapi/v4l/v4l2.rst | 1 +
2 files changed, 96 inse
On 2010, we introduced a new way to control complex V4L2 devices used
on embedded systems, but this was never documented, nor it is possible
for an userspace applicatin to detect the kind of control a device supports.
This series fill the gap.
Mauro Carvalho Chehab (7):
media: add glossary.rst
As we now have a glossary, some terms used on open.rst
require adjustments.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/media/uapi/v4l/open.rst | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/media/uapi/v4l/open.rst
b/Documentation/media
Right now, only kAPI documentation describes the device naming.
However, such description is needed at the uAPI too. Add it,
and describe how to get an unique identify for a given device.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/media/uapi/v4l/open.rst | 39
minor numbers use to range between 0 to 255, but that
was changed a long time ago. While it still applies when
CONFIG_VIDEO_FIXED_MINOR_RANGES, when the minor number is
dynamically allocated, this may not be true. In any case,
this is not relevant, as udev will take care of it.
So, remove this use
When we added support for omap3, back in 2010, we added a new
type of V4L2 devices that aren't fully controlled via the V4L2
device node.
Yet, we have never clearly documented in the V4L2 specification
the differences between the two types.
Let's document them based on the the current implementat
printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
timestamp to printk messages. The local hardware clock loses time each
day making it difficult to determine exactly when an issue has occurred in
the kernel log, and making it difficult to determine how kernel and
hardware i
printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
timestamp to printk messages. The local hardware clock loses time each
day making it difficult to determine exactly when an issue has occurred in
the kernel log, and making it difficult to determine how kernel and
hardware i
On Tue, Aug 22, 2017 at 01:23:20PM +0800, Icenowy Zheng wrote:
> The compatible string for Allwinner V3s SoC used to be missing.
>
> Add it to the binding document.
>
> Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC")
> Signed-off-by: Icenowy Zheng
> ---
> Documentation/devicetree/bi
On Tue, Aug 22, 2017 at 01:23:22PM +0800, Icenowy Zheng wrote:
> Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
> like A20.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng
> ---
> Changes in v2:
> - Fix alphabetical orders.
>
> Documentation/arm/sunxi/README
On Fri, 25 Aug 2017, Prarit Bhargava wrote:
> +
> + if (printk_time_source == PRINTK_TIME_UNDEFINED)
> + printk_time_source = _printk_time;
> +#ifndef CONFIG_PRINTK_TIME_DEBUG
> + else if ((printk_time_source != _printk_time) &&
> + (_printk_time != PRINTK_TIME_DISA
Jonathan,
> The kerneldoc comment for scsi_initialize_rq() neglected to document
> the "rq" parameter, leading to this docs build warning:
Applied to 4.14/scsi-queue. Tweaked the wording based on Bart's
comments. Thank you!
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe
> On Aug 9, 2017, at 2:26 PM, Khalid Aziz wrote:
>
> ADI is a new feature supported on SPARC M7 and newer processors to allow
> hardware to catch rogue accesses to memory. ADI is supported for data
> fetches only and not instruction fetches. An app can enable ADI on its
> data pages, set version
57 matches
Mail list logo
