Hi Kieran,
Thank you for the patch.
On Wednesday 01 Mar 2017 13:12:55 Kieran Bingham wrote:
> To be able to perform page flips in DRM without flicker we need to be
> able to notify the rcar-du module when the VSP has completed its
> processing.
>
> To synchronise the page flip events for userspa
Now that we have an extension to handle images, use it.
Signed-off-by: Mauro Carvalho Chehab
---
This patch is based on Daniel Vetter & Markus Heiser's work to support
PNG and SVG via kpicture Sphinx extension:
[PATCH] docs-rst: automatically convert Graphviz and SVG images
v2: Don't use
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Fri Mar 3 05:00:24 CET 2017
media-tree git hash:e6b377dbbb944d5e3ceef4e5d429fc5c841e3692
media_build git
On 03/02/2017 08:02 AM, Sakari Ailus wrote:
Hi Steve,
On Wed, Feb 15, 2017 at 06:19:16PM -0800, 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
---
drivers/me
On 03/02/2017 06:55 PM, Arnd Bergmann wrote:
> On Thu, Mar 2, 2017 at 5:51 PM, Christian Borntraeger
> wrote:
>> On 03/02/2017 05:38 PM, Arnd Bergmann wrote:
>>>
>>> This attempts a rewrite of the two macros, using a simpler implementation
>>> for the most common case of having a naturally aligned
Hi Kieran,
Thank you for the patch.
On Wednesday 01 Mar 2017 13:12:56 Kieran Bingham wrote:
> Updating the state in a running VSP1 requires two interrupts from the
> VSP. Initially, the updated state will be committed - but only after the
> VSP1 has completed processing it's current frame will th
On 03/02/2017 03:48 PM, Steve Longerbeam wrote:
On 03/02/2017 08:02 AM, Sakari Ailus wrote:
Hi Steve,
On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
v4l2_pipeline_inherit_controls() will add the v4l2 controls from
all subdev entities in a pipeline to a given video device
Hi Kieran,
Thank you for the patch.
On Wednesday 01 Mar 2017 13:12:54 Kieran Bingham wrote:
> The DRM object does not register the pipe with the WPF object. This is
> used internally throughout the driver as a means of accessing the pipe.
> As such this breaks operations which require access to t
On 03/02/2017 03:48 PM, Steve Longerbeam wrote:
On 03/02/2017 08:02 AM, Sakari Ailus wrote:
Hi Steve,
On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
v4l2_pipeline_inherit_controls() will add the v4l2 controls from
all subdev entities in a pipeline to a given video device
On Thu, 2017-03-02 at 23:59 +0100, Arnd Bergmann wrote:
> KASAN decides that passing a pointer to _m into an extern function
> (_mlog_printk) is potentially dangerous, as that function might
> keep a reference to that pointer after it goes out of scope,
> or it might not know the correct length of
On Thu, Mar 2, 2017 at 11:40 PM, Joe Perches wrote:
> On Thu, 2017-03-02 at 23:22 +0100, Arnd Bergmann wrote:
>> On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches wrote:
>> > On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote:
>> > > The internal logging infrastructure in ocfs2 causes special warni
On 03/02/2017 07:53 AM, Sakari Ailus wrote:
Hi Steve,
On Wed, Feb 15, 2017 at 06:19:15PM -0800, Steve Longerbeam wrote:
Add a new FRAME_TIMEOUT event to signal that a video capture or
output device has timed out waiting for reception or transmit
completion of a video frame.
Signed-off-by: St
On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches wrote:
> On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote:
>> The internal logging infrastructure in ocfs2 causes special warning code to
>> be
>> used with KASAN, which produces rather large stack frames:
>
>> fs/ocfs2/super.c: In function 'ocfs2
On Thu, 2017-03-02 at 23:22 +0100, Arnd Bergmann wrote:
> On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches wrote:
> > On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote:
> > > The internal logging infrastructure in ocfs2 causes special warning code
> > > to be
> > > used with KASAN, which produces
Practiaclly speaking, most Ion heaps are either going to be available
all the time (system heaps) or found based off of the reserved-memory
node. Parse the CMA and reserved-memory nodes to assign the heaps.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Makefile| 2 +-
dri
The align field was supposed to be used to specify the alignment of
the allocation. Nobody actually does anything with it except to check
if the alignment specified is out of bounds. Since this has no effect
on the actual allocation, just remove it.
Signed-off-by: Laura Abbott
---
drivers/stagi
The reference counting of dma_map calls was removed. Remove the
associated counter field as well.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion_priv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion_priv.h
b/drivers/staging/android/ion/io
Hi,
There's been some recent discussions[1] about Ion-like frameworks. There's
apparently interest in just keeping Ion since it works reasonablly well.
This series does what should be the final clean ups for it to possibly be
moved out of staging.
This includes the following:
- Some general clean
Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.
Signed-off-by: Laura Abbott
---
include/linux/cma.h | 2 ++
mm/cma.c| 14 ++
2 files changed, 16 insertions(+)
diff --git a/include
On Thu, Mar 2, 2017 at 8:00 PM, Christian Borntraeger
wrote:
> On 03/02/2017 06:55 PM, Arnd Bergmann wrote:
>> On Thu, Mar 2, 2017 at 5:51 PM, Christian Borntraeger
>> wrote:
>>> On 03/02/2017 05:38 PM, Arnd Bergmann wrote:
This attempts a rewrite of the two macros, using a simpler impl
Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
useful to have an explicit name attached to each region. Store the name
in each CMA structure.
Signed-off-by: Laura Abbott
---
drivers/base/dma-contiguous.c | 5 +++--
include/linux/cma.h | 4 +++-
mm/cma.c
Currently, all heaps are compiled in all the time. In switching to
a better platform model, let's allow these to be compiled out for good
measure.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Kconfig| 32
drivers/staging/android/ion/Makefile | 8 +++--
When CMA was first introduced, its primary use was for DMA allocation
and the only way to get CMA memory was to call dma_alloc_coherent. This
put Ion in an awkward position since there was no device structure
readily available and setting one up messed up the coherency model.
These days, CMA can b
Device specific platform support has been haphazard for Ion. There have
been several independent attempts and there are still objections to
what bindings exist right now. Just remove everything for a fresh start.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Kconfig
Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
Technically, calling dma_buf_map_attachment should return a buffer
properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
ensure this happens. As a side effect, this lets Ion buffers take
advantage of the dma_buf sync ioctls.
Signed-off-by: Laura Abbott
---
drivers/staging/android/
The new method of syncing with dma_map means that the page faulting sync
implementation is no longer applicable. Remove it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 117 --
1 file changed, 117 deletions(-)
diff --git a/drivers/stag
Now that we call dma_map in the dma_buf API callbacks there is no need
to use the existing cache APIs. Remove the sync ioctl and the existing
bad dma_sync calls. Explicit caching can be handled with the dma_buf
sync API.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion-ioctl.c
From: Konstantin Kozhevnikov
The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to a
Hi!
> > > static int isp_fwnode_parse(struct device *dev, struct fwnode_handle
> > > *fwn,
> > >
> > > struct isp_async_subdev *isd)
> > >
> > > {
> > >
> > > - struct isp_bus_cfg *buscfg = &isd->bus;
> > > + struct isp_bus_cfg *buscfg;
> > >
> > > struct v4l2_fwno
Hi Laurent,
On Thu, Mar 02, 2017 at 08:39:51PM +0200, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Thursday 02 Mar 2017 16:16:17 Sakari Ailus wrote:
> > On Thu, Mar 02, 2017 at 10:07:27AM +0100, Pavel Machek wrote:
> > > Hi!
> > >
> > > > Making the sub-device bus configuration a pointer should b
Now that we have an extension to handle images, use it.
Signed-off-by: Mauro Carvalho Chehab
---
This patch is based on Daniel Vetter & Markus Heiser's work to support
PNG and SVG via kpicture Sphinx extension.
PS.: With this RFC patch, I'm getting now some extra warnings:
/devel/v4l/patchwork
This patch removes unnecessary typecast of c90 int constant.
WARNING: Unnecessary typecast of c90 int constant
Signed-off-by: simran singhal
---
drivers/staging/media/atomisp/i2c/gc2235.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c
Add blank line after a declaration. Problem found
using checkpatch.
This patch fixes these warning messages found by checkpatch.pl:
WARNING : Missing a blank line after declarations.
Signed-off-by: simran singhal
---
drivers/staging/media/atomisp/i2c/gc2235.c | 7 +++
1 file changed, 7 inse
Hi Pavel,
Thank you for the patch.
On Thursday 02 Mar 2017 13:45:32 Pavel Machek wrote:
> If regulator returns -EPROBE_DEFER, we need to return it too, so that
> omap3isp will be re-probed when regulator is ready.
>
> Signed-off-by: Pavel Machek
>
> diff --git a/drivers/media/platform/omap3isp
Remove multiple blank lines. Problem found using checkpatch.pl
"CHECK: Please don't use multiple blank lines".
Signed-off-by: simran singhal
---
drivers/staging/media/atomisp/i2c/gc2235.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/gc2235.c
b/drivers/
Use x instead of x != NULL .
This patch removes the explicit NULL comparisons.This issue is found by
checkpatch.pl script.
Signed-off-by: simran singhal
---
drivers/staging/media/atomisp/i2c/gc2235.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/
Remove multiple assignments by factorizing them. Problem found using
checkpatch.pl
CHECK: multiple assignments should be avoided
Signed-off-by: simran singhal
---
drivers/staging/media/atomisp/i2c/gc2235.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/med
Remove unneeded blank lines preceding/following '}' and '{' braces, as
pointed out by checkpatch.
This patch addresses the following checkpatch checks:
CHECK: Blank lines aren't necessary before a close brace '}'
CHECK: Blank lines aren't necessary after an open brace '{'
Signed-off-by: simran s
Use ! in comparison tests using "==NULL" rather than moving the
"==NULL" to the right side of the test.
Addesses multiple instances of the checkpatch.pl warning:
WARNING: Comparisons should place the constant on the right side of the
test
Signed-off-by: simran singhal
---
drivers/staging/media/
Hans, Mauro,
Ping.
Regards,
Benoit
Tomi Valkeinen wrote on Fri [2017-Feb-17 11:45:41
+0200]:
> On 13/02/17 15:06, Benoit Parrot wrote:
> > This patch series enables user specified buffer stride to be used
> > instead of always forcing the stride from the driver side.
> >
> > Benoit Parrot (2)
When CONFIG_KASAN is used, we consume a lot of extra stack space:
drivers/mtd/chips/cfi_cmdset_0020.c: In function 'do_write_buffer':
drivers/mtd/chips/cfi_cmdset_0020.c:603:1: error: the frame size of 2080 bytes
is larger than 1536 bytes [-Werror=frame-larger-than=]
drivers/mtd/chips/cfi_cmdset_
The internal logging infrastructure in ocfs2 causes special warning code to be
used with KASAN, which produces rather large stack frames:
fs/ocfs2/super.c: In function 'ocfs2_fill_super':
fs/ocfs2/super.c:1219:1: error: the frame size of 3264 bytes is larger than
3072 bytes [-Werror=frame-larger-
Hi Sakari,
On Thursday 02 Mar 2017 16:16:17 Sakari Ailus wrote:
> On Thu, Mar 02, 2017 at 10:07:27AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > Making the sub-device bus configuration a pointer should be in a
> > > separate patch. It makes sense since the entire configuration is not
> > > valid
Hi Pavel,
On Thu, Mar 02, 2017 at 03:58:08PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > Making the sub-device bus configuration a pointer should be in a
> > > > separate
> > > > patch. It makes sense since the entire configuration is not valid for
> > > > all
> > > > sub-devices attached to the
With CONFIG_KASAN, this driver has shown a ridiculously large stack frame
in one configuration:
drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame size of 94000
bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
In most builds, it's only about 3300 bytes, but that's stil
From: Evgeni Raikhel
Change Log:
- Fixing FourCC description in v4l2_ioctl.c to be less than 32 bytes
- Reorder INZI format entry in Documentation chapter
Daniel Patrick Johnson (1):
uvcvideo: Add support for Intel SR300 depth camera
eraikhel (1):
Documentation: Intel SR300 Depth camera I
From: eraikhel
Provide the frame structure and data layout of V4L2-PIX-FMT-INZI
format utilized by Intel SR300 Depth camera.
Signed-off-by: Evgeni Raikhel
Reviewed-by: Laurent Pinchart
---
Documentation/media/uapi/v4l/depth-formats.rst | 1 +
Documentation/media/uapi/v4l/pixfmt-inzi.rst |
On Thu, Mar 2, 2017 at 5:51 PM, Christian Borntraeger
wrote:
> On 03/02/2017 05:38 PM, Arnd Bergmann wrote:
>>
>> This attempts a rewrite of the two macros, using a simpler implementation
>> for the most common case of having a naturally aligned 1, 2, 4, or (on
>> 64-bit architectures) 8 byte obj
On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote:
> The internal logging infrastructure in ocfs2 causes special warning code to be
> used with KASAN, which produces rather large stack frames:
> fs/ocfs2/super.c: In function 'ocfs2_fill_super':
> fs/ocfs2/super.c:1219:1: error: the frame size
Enabling CONFIG_KASAN can lead to an instant stack overflow:
drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_generic_mmio_info':
drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 30464
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/gvt/
When CONFIG_KASAN is set, we use a large amount of stack in the btcoexist code,
presumably due to lots of inlining of functions that each add to the kernel
stack.
net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c:3762:1: error: the
frame size of 4032 bytes is larger than 3072 bytes
net/wir
In the previous commit I left the indentation alone to help reviewing
the patch, this one now runs the three new functions through 'indent -kr -8'
with some manual fixups to avoid silliness.
No changes other than whitespace are intended here.
Signed-off-by: Arnd Bergmann
---
.../broadcom/brcm80
As reported by kernelci, some functions in the VT code use significant
amounts of kernel stack when local variables get inlined into the caller
multiple times:
drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is larger
tha
With KASAN and a couple of other patches applied, this driver is one
of the few remaining ones that actually use more than 2048 bytes of
kernel stack:
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function
'wlc_phy_workarounds_nphy_gainctrl':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning
It took a long while to get this done, but I'm finally ready
to send the first half of the KASAN stack size patches that
I did in response to the kernelci.org warnings.
As before, it's worth mentioning that things are generally worse
with gcc-7.0.1 because of the addition of -fsanitize-address-use
The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an
object
on the stack, which will each require a redzone with KASAN and lead to possible
stack overflow:
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function
'wlc_phy_workarounds_nphy':
drivers/net/wi
With KASAN enabled, the typecheck macro leads to some serious stack memory,
as seen in the rt2xxx drivers:
drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function
'rt2800_init_registers':
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5068:1: error: the frame size of
23768 bytes is larger th
Inlining these functions creates lots of stack variables when KASAN is
enabled, leading to this warning about potential stack overflow:
drivers/net/ethernet/rocker/rocker_ofdpa.c: In function
'ofdpa_cmd_flow_tbl_add':
drivers/net/ethernet/rocker/rocker_ofdpa.c:621:1: error: the frame size of 2752
When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large
stack frames in some functions. This goes unnoticed normally because
CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit
3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with
KASAN
Inlining functions with local variables can lead to excessive stack usage
with KASAN:
drivers/net/wireless/wl3501_cs.c: In function 'wl3501_rx_interrupt':
drivers/net/wireless/wl3501_cs.c:1103:1: error: the frame size of 2232 bytes is
larger than 1536 bytes [-Werror=frame-larger-than=]
Marking a
When building with KASAN, we get a stack frame size warning about a function
that could potentially cause a stack overflow:
drivers/media/i2c/adv7604.c: In function 'adv76xx_log_status':
drivers/media/i2c/adv7604.c:2615:1: error: the frame size of 3248 bytes is
larger than 3072 bytes [-Werror=fra
When CONFIG_KASAN is set, we can run into some code that uses incredible
amounts of kernel stack:
drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 2 bytes is
larger than 2048 bytes [-Werror=frame-larger-than=]
drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame s
The stack consumption in this driver is still relatively high, with one
remaining warning if the warning level is lowered to 1536 bytes:
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error:
the frame size of 1880 bytes is larger than 1536 bytes
[-Werror=frame-larger-than=
When CONFIG_KASAN is enabled, we see very large stack usage in some
functions, e.g.:
drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 3184 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
drivers/media/tuners/
With CONFIG_KASAN, the init function uses a large amount of kernel stack:
drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
drivers/media/usb/em28xx/em28xx-dvb.c:2069:1: error: the frame size of 4280
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
By splitting ou
We get a lot of very large stack frames using gcc-7.0.1 with the default
-fsanitize-address-use-after-scope --param asan-stack=1 options, which
can easily cause an overflow of the kernel stack, e.g.
drivers/acpi/nfit/core.c:2686:1: warning: the frame size of 4080 bytes is
larger than 2048 bytes [
When CONFIG_KASAN is enabled, the READ_ONCE/WRITE_ONCE macros cause
rather large kernel stacks, e.g.:
mm/vmscan.c: In function 'shrink_page_list':
mm/vmscan.c:1333:1: error: the frame size of 3456 bytes is larger than 3072
bytes [-Werror=frame-larger-than=]
block/cfq-iosched.c: In function 'cfqg_
A typical code fragment was copied across many dvb-frontend
drivers and causes large stack frames when built with
-fsanitize-address-use-after-scope, e.g.
drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
dri
When CONFIG_KASAN is set, we see overly large stack frames from inlining
functions with local variables:
drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c: In function
'rtl8225se_rf_init':
drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c:431:1: warning: the
frame size of 4384 byte
With KASAN, we get an overly long stack frame due to inlining
the register access function:
drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is
larger than 2048 bytes [-Werror=frame-larger-than=]
An earl
When CONFIG_KASAN is set, inlining of functions with local variables
causes excessive stack usage:
drivers/media/i2c/ks0127.c: In function 'ks0127_s_routing':
drivers/media/i2c/ks0127.c:541:1: error: the frame size of 3136 bytes is larger
than 2048 bytes [-Werror=frame-larger-than=]
Marking one
When CONFIG_KASAN is set, each call to ps8622_set() adds an object to the
stack frame, leading to a warning about possible stack overflow:
drivers/gpu/drm/bridge/parade-ps8622.c: In function 'ps8622_send_config':
drivers/gpu/drm/bridge/parade-ps8622.c:338:1: error: the frame size of 5872
bytes is
When CONFIG_KASAN is enabled, we have several functions that use rather
large kernel stacks, e.g.
drivers/isdn/hardware/eicon/message.c: In function 'group_optimization':
drivers/isdn/hardware/eicon/message.c:14841:1: warning: the frame size of 864
bytes is larger than 500 bytes [-Wframe-larger-t
On 03/02/2017 05:38 PM, Arnd Bergmann wrote:
> When CONFIG_KASAN is enabled, the READ_ONCE/WRITE_ONCE macros cause
> rather large kernel stacks, e.g.:
>
> mm/vmscan.c: In function 'shrink_page_list':
> mm/vmscan.c:1333:1: error: the frame size of 3456 bytes is larger than 3072
> bytes [-Werror=fr
Hi Steve,
On Wed, Feb 15, 2017 at 06:19:16PM -0800, 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
> ---
> drivers/media/v4l2-core/v4l2-mc.c | 48
> +
> + /* If there is no buffer in flight, wake up */
> + if (ctx->qsequence == ctx->osequence) {
Not sure about this one, I would have done something like :
if (!(ctx->fh.m2m_ctx->job_flags)) {
> + dst_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx,
> +
Hi Steve,
On Wed, Feb 15, 2017 at 06:19:15PM -0800, Steve Longerbeam wrote:
> Add a new FRAME_TIMEOUT event to signal that a video capture or
> output device has timed out waiting for reception or transmit
> completion of a video frame.
>
> Signed-off-by: Steve Longerbeam
> ---
> Documentation/
From: Daniel Patrick Johnson
Add support for Intel SR300 depth camera in uvc driver.
This includes adding three uvc GUIDs for the required pixel formats
and updating the uvc driver GUID-to-4cc tables with the new formats.
Signed-off-by: Daniel Patrick Johnson
Signed-off-by: Aviv Greenberg
Sign
Hi Laurent,
On Tue, Feb 28, 2017 at 05:03:19PM +0200, Laurent Pinchart wrote:
> V4L2 exposes parameters that influence buffers sizes through the format
> ioctls (VIDIOC_G_FMT, VIDIOC_TRY_FMT and VIDIO_S_FMT). Other parameters
> not part of the format structure may also influence buffer sizes or
>
Hi!
> > > Making the sub-device bus configuration a pointer should be in a separate
> > > patch. It makes sense since the entire configuration is not valid for all
> > > sub-devices attached to the ISP anymore. I think it originally was a
> > > separate patch, but they probably have been merged at
Hi Pavel,
On Thu, Mar 02, 2017 at 10:07:27AM +0100, Pavel Machek wrote:
> Hi!
>
> > Making the sub-device bus configuration a pointer should be in a separate
> > patch. It makes sense since the entire configuration is not valid for all
> > sub-devices attached to the ISP anymore. I think it origi
On 3/1/17, Sean Young wrote:
>
> Sorry Vincent, but are you sure you're running the patch with the
> & 0xff mask? That should have solved it.
>
er, no. Some kind of build issue. Once I applied your media_build
patch and then the latest kernel patch you sent, this is what the test
run looks like.
On Sat, Feb 25, 2017 at 11:51:32AM +, Sean Young wrote:
> @@ -362,10 +394,15 @@ static unsigned int ir_lirc_poll(struct file *filep,
>
> poll_wait(filep, &lirc->wait_poll, wait);
>
> - if (!lirc->drv.attached)
> + if (!lirc->drv.attached) {
> events = POLLHUP;
>
If regulator returns -EPROBE_DEFER, we need to return it too, so that
omap3isp will be re-probed when regulator is ready.
Signed-off-by: Pavel Machek
diff --git a/drivers/media/platform/omap3isp/ispccp2.c
b/drivers/media/platform/omap3isp/ispccp2.c
index ca09523..b6e055e 100644
--- a/drivers/m
Hi!
> > Ok, how about this one?
> > omap3isp: add rest of CSI1 support
> >
> > CSI1 needs one more bit to be set up. Do just that.
> >
> > It is not as straightforward as I'd like, see the comments in the code
> > for explanation.
...
> > + if (isp->phy_type == ISP_PHY_TYPE_3430) {
> >
Hi Kieran,
Thank you for the patch.
On Thursday 02 Mar 2017 10:12:22 Kieran Bingham wrote:
> The struct vsp1_drm references a member 'planes' which doesn't exist.
> Correctly identify this documentation against the 'inputs'
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
and
Hi Pavel,
On Thu, Mar 02, 2017 at 11:16:04AM +0100, Pavel Machek wrote:
> Hi!
>
> > > > >> +++ b/drivers/media/platform/omap3isp/ispccp2.c
> > > > >> @@ -160,6 +163,33 @@ static int ccp2_if_enable(struct isp_ccp2_device
> > > > >> *ccp2, u8 enable) return ret;
> > > > >>
> > > > >> }
> > >
I don't know what the BWB unit is, I guess W is for write and one of the
Bs is for burst. All I know is that there repeatedly have been issues
with it hanging on certain streams (ENGR00223231, ENGR00293425), with
various firmware versions, sometimes blocking something related to the
GDI bus or the
The struct vsp1_drm references a member 'planes' which doesn't exist.
Correctly identify this documentation against the 'inputs'
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/vsp
Hi Philipp,
2017-03-02 10:51 GMT+01:00 Philipp Zabel :
> There is no need to call v4l2_m2m_try_schedule to kick off draining the
> bitstream buffer for the encoder, but we have to wake up the destination
> queue in case there are no new OUTPUT buffers to be encoded and userspace
> is already polli
Hi Jean-Michel,
On Thu, 2017-03-02 at 11:02 +0100, Jean-Michel Hautbois wrote:
> Hi Philipp,
>
> 2017-03-02 10:51 GMT+01:00 Philipp Zabel :
> > There is no need to call v4l2_m2m_try_schedule to kick off draining the
> > bitstream buffer for the encoder, but we have to wake up the destination
> >
Hi!
> > > >> +++ b/drivers/media/platform/omap3isp/ispccp2.c
> > > >> @@ -160,6 +163,33 @@ static int ccp2_if_enable(struct isp_ccp2_device
> > > >> *ccp2, u8 enable) return ret;
> > > >>
> > > >>}
> > > >>
> > > >> + if (isp->revision == ISP_REVISION_2_0) {
> > > >
> > > > The isp
There is no need to call v4l2_m2m_try_schedule to kick off draining the
bitstream buffer for the encoder, but we have to wake up the destination
queue in case there are no new OUTPUT buffers to be encoded and userspace
is already polling for new CAPTURE buffers.
Signed-off-by: Philipp Zabel
---
On Wed, Mar 1, 2017 at 12:36 PM, Philipp Zabel wrote:
> Recently, an unfinished patch was merged that added a third entry to the
> beginning of the array of firmware locations without changing the code
> to also look at the third element, thus pushing an old firmware location
> off the list.
>
> F
Hi Laurent,
LGTM! :-)
On 28/02/17 23:08, Laurent Pinchart wrote:
> While all VSP instances can process HSV internally, on Gen3 hardware
> reading or writing HSV24 or HSV32 from/to memory causes the device to
> hang. Disable those pixel formats on Gen3 hardware.
>
> Signed-off-by: Laurent Pinchar
Hi!
> Making the sub-device bus configuration a pointer should be in a separate
> patch. It makes sense since the entire configuration is not valid for all
> sub-devices attached to the ISP anymore. I think it originally was a
> separate patch, but they probably have been merged at some point. I c
Hi!
> > >> +
> > >> +static int isp_of_parse_node_endpoint(struct device *dev,
> > >> + struct device_node *node,
> > >> + struct isp_async_subdev *isd)
> > >> +{
> > >> +struct isp_bus_cfg *buscfg;
> > >> +s
On Mon 2017-02-13 12:20:35, Sakari Ailus wrote:
> Hi Pavel,
>
> On Mon, Feb 13, 2017 at 10:54:20AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > Take a look at the wikipedia. If you do "one at a time" at 100Hz, you
> > > > can claim it is time-domain multiplex. But we are plain switching the
> >
On Wed 2017-03-01 15:41:23, Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_probe() which specifically d
100 matches
Mail list logo
