Hi Niklas,
On 10/12/2018 12:55, Niklas Söderlund wrote:
> Hi Koji-san, Kieran(-san),
>
> Thanks for your work.
>
> On 2018-12-10 12:29:01 +, Kieran Bingham wrote:
>> From: Koji Matsuoka
>>
>> The ADV7481 Register Control Manual states that bit 2 in the Vid
Hi Matsuoka-san,
Thank you for the patch,
On 10/12/2018 12:07, Kieran Bingham wrote:
> From: Koji Matsuoka
>
> By video decoder user's manual, the bit 2 in Video Standard
> Selection register must be reserved with the value of 1.
> This driver cleared it with 0 when writin
ensure that it is always set when
writing to the SDP_VID_SEL register.
Reviewed-by: Kieran Bingham
Signed-off-by: Koji Matsuoka
[Kieran: Updated commit message, utilised BIT macro]
Signed-off-by: Kieran Bingham
---
drivers/media/i2c/adv748x/adv748x-afe.c | 3 ++-
drivers/media/i2c/adv748x
From: Koji Matsuoka
By video decoder user's manual, the bit 2 in Video Standard
Selection register must be reserved with the value of 1.
This driver cleared it with 0 when writing back.
This patch corrects it.
Signed-off-by: Koji Matsuoka
---
drivers/media/i2c/adv748x/adv748x-afe.c | 3 ++-
dr
Provide a new option '--reset-controls' which will enumerate the
available controls on a device or sub-device, and re-initialise them to
defaults.
Signed-off-by: Kieran Bingham
---
v2:
- Rebase and rework to sit on top of the compound control changes
With this patch, and the u
In the partition sizing the term 'prevents' is inappropriately
pluralized. Simplify to 'prevent'.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_video.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/vsp1/vsp
Provide a new option '--reset-controls' which will enumerate the
available controls on a device or sub-device, and re-initialise them to
defaults.
Signed-off-by: Kieran Bingham
---
This 'extends' the video_list_controls() function with an extra bool
flag for 'reset&#x
Hi Sakari,
Thank you for your review,
On 20/11/2018 08:34, Sakari Ailus wrote:
> Hi Kieran,
>
> On Fri, Nov 02, 2018 at 03:47:23PM +0000, Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> The RDACM20 is a GMSL camera supporting 1280x800 resolution images
>
+Wolfram,
Hi Luca,
On 14/11/2018 02:04, Luca Ceresoli wrote:
> Hi Kieran,
>
> On 14/11/18 00:12, Kieran Bingham wrote:
>> Hi Luca,
>>
>> On 13/11/2018 14:42, Luca Ceresoli wrote:
>>> Hi Kieran, All,
>>>
>>> sorry for joining this late... See
MI_MATCH(DMI_PRODUCT_NAME, "A6VM")
> + }
I guess these strings match the strings produced by dmi-decode on your
laptop?
Assuming so:
Reviewed-by: Kieran Bingham
> + },
> {}
> };
>
>
--
Regards
--
Kieran
Hi Andreas,
Thank you for the patch,
On 23/11/2018 16:14, Andreas Pape wrote:
> stk_start_stream can only be called successfully if stk_initialise and
> stk_setup_format are called before. When using e.g. cheese it was observed
> that stk_initialise and stk_setup_format have not been called befor
eturn 0; could be on it's own, and the else
statement would then not be needed, but I see this follows the style
used by stk_camera_write_reg() - so it looks good to me.
Reviewed-by: Kieran Bingham
> }
>
> static int stk_start_stream(struct stk_camera *dev)
>
--
Regards
--
Kieran
Hi Andreas,
On 22/11/2018 19:23, Andreas Pape wrote:
> Hello,
>
> I recently updated my old 2006 Asus A6VM notebook with the latest 32bit
> Ubuntu 18.04 LTS (kernel 4.15.0) and found out that the driver for the
> webcam (Syntek USB2.0, USB ID 174f:a311) was not working. I only got error
> message
t; Gen3 VSPD, breaking operation on all Gen2 platforms as well as on
> H3 ES2.0, M3-N, V3M and V3H. Fix it.
Ouch. :-S
> Fixes: de2bc45c84f7 ("media: vsp1: Update LIF buffer thresholds")
> Reported-by: Colin Ian King
> Signed-off-by: Laurent Pinchart
At least it
Hi Luca,
My apologies for my travel induced delay in responding here,
On 14/11/2018 02:04, Luca Ceresoli wrote:
> Hi Kieran,
>
> On 14/11/18 01:46, Kieran Bingham wrote:
>> Hi Luca,
>>
>> Thank you for your review,
>>
>> On 13/11/2018 14:49,
Hi Luca,
Thank you for your review,
On 13/11/2018 14:49, Luca Ceresoli wrote:
> Hi Kieran, All,
>
> below a few minor questions, and a big one at the bottom.
>
> On 02/11/18 16:47, Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> The MAX9286 is a 4-chann
Hi Luca,
On 13/11/2018 14:42, Luca Ceresoli wrote:
> Hi Kieran, All,
>
> sorry for joining this late... See below my considerations.
I'd say you're on time - not late,
Thanks for joining :)
>
> On 02/11/18 16:47, Kieran Bingham wrote:
>> From: Laurent Pinchart
Hi Laurent,
I see that you made changes to this patch before accepting it last time.
I'm afraid I haven't made those changes here, so please just cherry-pick
your previous incarnation. There are no changes here from me between v5,
and v6.
Regards
--
Kieran
On 09/11/2018 17:05, Kier
Hi Laurent,
I'm sorry - I didn't update the commit message on this one.
On 09/11/2018 17:05, Kieran Bingham wrote:
> We have both uvc_init_video() and uvc_video_init() calls which can be
> quite confusing to determine the process for each. Now that video
> uvc_video_enable()
uvc_uninit_video() to
uvc_video_stop().
Signed-off-by: Kieran Bingham
---
v6:
- Append _transfer to {_stop,_start}
drivers/media/usb/uvc/uvc_video.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc
A new iterator is available for processing UVC URB structures. This
simplifies the processing of the internal stream data.
Convert the manual loop iterators to the new helper, adding an index
helper to keep the existing debug print.
Signed-off-by: Kieran Bingham
---
v6:
- rename lone &#
, we will instead return -ENOMEM.
While we're here, fix the trivial spelling error in the function banner
of uvc_delete().
Signed-off-by: Kieran Bingham
---
drivers/media/usb/uvc/uvc_driver.c | 54 +--
1 file changed, 38 insertions(+), 16 deletions(-)
diff --
x27;.
This can result in data rates of up to 2 gigabits per second being
processed.
To improve efficiency, and maximise throughput, handle the URB decode
processing through a work queue to move it from interrupt context, and
allow multiple processors to work on URBs in parallel.
Signed-off-
.
Signed-off-by: Kieran Bingham
---
drivers/media/usb/uvc/uvc_queue.c | 4 +-
drivers/media/usb/uvc/uvc_video.c | 56 +++-
drivers/media/usb/uvc/uvcvideo.h | 3 +-
3 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_queue.c
b/drivers
: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
v2:
- Fix coding style of conditional statements
v3:
- No change
v4:
- Rebase on top of linux-media/master (v4.16-rc4, metadata additions)
drivers/media/usb/uvc/uvc_queue.c | 33 +++-
drivers/media/usb/uvc
The URB completion handlers currently reference the stream context.
Now that each URB has its own context structure, convert the decode (and
one encode) functions to utilise this context for URB management.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
v2:
- fix checkpatch
reference count tracks the
active use of the buffer, returning the buffer to the VB2 stack at
completion.
Signed-off-by: Kieran Bingham
v5:
- uvc_queue_requeue() -> uvc_queue_buffer_requeue()
- Fix comment
---
drivers/media/usb/uvc/uvc_queue.c | 61 ++--
driv
Both uvc_start_streaming(), and uvc_stop_streaming() are called from
userspace context, with interrupts enabled. As such, they do not need to
save the IRQ state, and can use spin_lock_irq() and spin_unlock_irq()
respectively.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
v4
rkqueue.
- Append _transfer to {_stop,_start} in uvc_video_{stop,start}_transfer
- rename lone 'j' iterator to 'i'
- Remove conversion which doesn't make sense due to needing the
iterator value.
Kieran Bingham (10):
media: uvcvideo: Refactor URB descriptors
medi
for consistency.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
v2:
- Re-describe URB context structure
- Re-name uvc_urb->{urb_buffer,urb_dma}{buffer,dma}
v3:
- No change
v4:
- Rebase on top of linux-media/master (v4.16-rc4, metadata additions)
drivers/media/usb/
On 09/11/2018 15:41, Philipp Zabel wrote:
> On Wed, 2018-11-07 at 22:25 +0200, Laurent Pinchart wrote:
>> Hi Kieran,
>>
>> On Wednesday, 7 November 2018 16:30:46 EET Kieran Bingham wrote:
>>> On 06/11/2018 23:13, Laurent Pinchart wrote:
>>>> On Tuesday, 6
Hi Laurent,
On 08/11/2018 17:01, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Wednesday, 7 November 2018 01:31:29 EET Laurent Pinchart wrote:
>> On Tuesday, 6 November 2018 23:27:11 EET Kieran Bingham wrote:
>>> From: Kieran Bingham
>>>
>>> The L
allows us to configure each camera independently
(which is essential because they are all configured to the same i2c
address by default at power on)
Hope this helps, and feel free to ask if you have any more questions.
--
Regards
Kieran
On 02/11/2018 15:47, Kieran Bingham wrote:
> From: Kieran Bi
Hi Laurent,
On 06/11/2018 23:13, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Tuesday, 6 November 2018 23:27:19 EET Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> We have both uvc_init_video() and uvc_video_init() calls w
Hi Laurent,
On 06/11/2018 23:21, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Tuesday, 6 November 2018 23:27:20 EET Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> A new iterator is available for processing UVC URB structures.
On 06/11/2018 22:58, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Tuesday, 6 November 2018 23:27:17 EET Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> Newer high definition cameras, and cameras with multiple lenses such as
>
Hi Laurent,
On 06/11/2018 23:08, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Tuesday, 6 November 2018 23:27:18 EET Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> uvc_video_enable() is used both to start and stop the video str
From: Kieran Bingham
uvc_video_enable() is used both to start and stop the video stream
object, however the single function entry point shares no code between
the two operations.
Split the function into two distinct calls, and rename to
uvc_video_start_streaming() and uvc_video_stop_streaming
From: Kieran Bingham
A new iterator is available for processing UVC URB structures. This
simplifies the processing of the internal stream data.
Convert the manual loop iterators to the new helper, adding an index
helper to keep the existing debug print.
Signed-off-by: Kieran Bingham
---
This
From: Kieran Bingham
We have both uvc_init_video() and uvc_video_init() calls which can be
quite confusing to determine the process for each. Now that video
uvc_video_enable() has been renamed to uvc_video_start_streaming(),
adapt these calls to suit the new flow.
Rename uvc_init_video() to
From: Kieran Bingham
The URB completion handlers currently reference the stream context.
Now that each URB has its own context structure, convert the decode (and
one encode) functions to utilise this context for URB management.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
From: Kieran Bingham
We currently store three separate arrays for each URB reference we hold.
Objectify the data needed to track URBs into a single uvc_urb structure,
allowing better object management and tracking of the URB.
All accesses to the data pointers through stream, are converted to
From: Kieran Bingham
Both uvc_start_streaming(), and uvc_stop_streaming() are called from
userspace context, with interrupts enabled. As such, they do not need to
save the IRQ state, and can use spin_lock_irq() and spin_unlock_irq()
respectively.
Signed-off-by: Kieran Bingham
Reviewed-by
From: Kieran Bingham
The Linux UVC driver has long provided adequate performance capabilities for
web-cams and low data rate video devices in Linux while resolutions were low.
Modern USB cameras are now capable of high data rates thanks to USB3 with
1080p, and even 4k capture resolutions
From: Kieran Bingham
The URB completion operation obtains the current buffer by reading
directly into the queue internal interface.
Protect this queue abstraction by providing a helper
uvc_queue_get_current_buffer() which can be used by both the decode
task, and the uvc_queue_next_buffer
From: Kieran Bingham
Newer high definition cameras, and cameras with multiple lenses such as
the range of stereo-vision cameras now available have ever increasing
data rates.
The inclusion of a variable length packet header in URB packets mean
that we must memcpy the frame data out to our
From: Kieran Bingham
The buffer queue interface currently operates sequentially, processing
buffers after they have fully completed.
In preparation for supporting parallel tasks operating on the buffers,
we will need to support buffers being processed on multiple CPUs.
Adapt the
Hi Tomasz,
On 07/08/2018 10:54, Tomasz Figa wrote:
> Hi Kieran,
>
> On Wed, Mar 28, 2018 at 1:47 AM Kieran Bingham
> wrote:
> [snip]
>> @@ -1544,25 +1594,29 @@ static int uvc_alloc_urb_buffers(struct
>> uvc_streaming *stream,
>> */
>> static voi
Hi Laurent,
On 30/07/2018 20:57, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Tuesday, 27 March 2018 19:46:01 EEST Kieran Bingham wrote:
>> Both uvc_start_streaming(), and uvc_stop_streaming() are called from
>> userspace context, with
t wrote:
>> On Friday, 12 January 2018 11:19:26 EET Kieran Bingham wrote:
>>> The buffer queue interface currently operates sequentially, processing
>>> buffers after they have fully completed.
>>>
>>> In preparation for supporting parallel tasks operating on
From: Laurent Pinchart
The MAX9286 deserializes video data received on up to 4 Gigabit
Multimedia Serial Links (GMSL) and outputs them on a CSI-2 port using up
to 4 data lanes.
Signed-off-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
Signed-off-by: Kieran Bingham
---
v3:
- Update
sl/v4
Further anticipated work in this area includes supporting the RDACM21
camera, at which point the RDACM20 will be adapted to separate out the
MAX9271 and the OV10635 sensor components.
Jacopo Mondi (1):
dt-bindings: media: i2c: Add bindings for IMI RDACM20
Kieran Bingham (2):
media: i2c
From: Jacopo Mondi
The IMI RDACM20 is a Gigabit Multimedia Serial Link (GMSL) camera
capable of transmitting video and I2C control messages on a coax cable
physical link for automotive applications.
Document its device tree binding interface.
Signed-off-by: Jacopo Mondi
Signed-off-by: Kieran
From: Kieran Bingham
The RDACM20 is a GMSL camera supporting 1280x800 resolution images
developed by IMI based on an Omnivision 10635 sensor and a Maxim MAX9271
GMSL serializer.
The GMSL link carries power, control (I2C) and video data over a
single coax cable.
Signed-off-by: Jacopo Mondi
From: Kieran Bingham
The MAX9286 is a 4-channel GMSL deserializer with coax or STP input and
CSI-2 output. The device supports multicamera streaming applications,
and features the ability to synchronise the attached cameras.
CSI-2 output can be configured with 1 to 4 lanes, and a control
Hi Sakari,
On 02/11/2018 14:18, Sakari Ailus wrote:
> On Fri, Nov 02, 2018 at 01:35:02PM +0000, Kieran Bingham wrote:
>> Hi Sakari, Niklas,
>>
>> On 02/11/2018 13:15, Sakari Ailus wrote:
>>> Hi Kieran,
>>>
>>> On Fri, Nov 02, 2018 at 12:27:11PM +00
Hi Sakari, Niklas,
On 02/11/2018 13:15, Sakari Ailus wrote:
> Hi Kieran,
>
> On Fri, Nov 02, 2018 at 12:27:11PM +0000, Kieran Bingham wrote:
>> Hi Niklas, Sakari
>>
>> On 23/08/2018 14:25, Niklas Söderlund wrote:
>>> From: Sakari Ailus
>>>
>>
Hi Jacopo,
On 15/10/2018 20:37, jacopo mondi wrote:
> Hi Kieran,
>
> On Mon, Oct 15, 2018 at 06:37:40PM +0100, Kieran Bingham wrote:
>> Hi Sakari,
>>
>> Thank you for the review,
>>
>> On 15/10/18 17:45, Sakari Ailus wrote:
>>> Hi Kieran,
>&
On 16/10/2018 01:37, Laurent Pinchart wrote:
> Hello,
>
> On Monday, 15 October 2018 22:01:21 EEST Niklas Söderlund wrote:
>> On 2018-10-15 18:37:40 +0100, Kieran Bingham wrote:
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/media/i2c/maxim
Hi Niklas, Sakari
On 23/08/2018 14:25, Niklas Söderlund wrote:
> From: Sakari Ailus
>
> Signed-off-by: Sakari Ailus
> ---
> include/media/v4l2-subdev.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index 5acaeeb9b
Hi Jacopo,
On 02/11/2018 11:04, jacopo mondi wrote:
> Hi Niklas,
>
> On Fri, Nov 02, 2018 at 11:44:25AM +0100, Niklas Söderlund wrote:
>> Hi Jacopo,
>>
>> Thanks for your feedback.
>>
>> On 2018-10-05 12:46:15 +0200, Jacopo Mondi wrote:
>>> Hi Niklas,
>>>
>>> On Thu, Oct 04, 2018 at 10:41:38PM +0
Hi Niklas,
On 02/11/2018 10:34, Niklas Söderlund wrote:
> Hi Laurent, Jacopo
>
> Thanks for your comments.
>
> On 2018-10-05 13:02:53 +0300, Laurent Pinchart wrote:
>> Hi Jacopo,
>>
>> On Friday, 5 October 2018 11:49:45 EEST jacopo mondi wrote:
>>> On Fri, Oct 05, 2018 at 01:00:47AM +0300, Laure
Hi Jiri,
On 30/10/2018 14:36, Jiri Slaby wrote:
> Hi,
>
> I have a Dell Lattitude 7280 with two webcams. The standard one works
> fine (/dev/video0). The other one is an IR camera (/dev/video1). The
> camera proper works fine and produces 340x374 frames. But there is an IR
> led supposed to light
do a v4 post after I've gone through some of your comments, and
make sure I remember the DT guys this time :)
> On Tue, Oct 09, 2018 at 09:57:23PM +0100, Kieran Bingham wrote:
>> From: Laurent Pinchart
>>
>> The MAX9286 deserializes video data received on up to 4 Gigabit
Hi Vladimir,
On 12/10/18 11:58, Vladimir Zapolskiy wrote:
> Hi Kieran,
>
> On 10/12/2018 12:20 PM, Kieran Bingham wrote:
>> Hi Vladimir,
>>
>> On 12/10/18 09:39, Lee Jones wrote:
>>> On Fri, 12 Oct 2018, Vladimir Zapolskiy wrote:
>>>> On 10/12/2018
Hi Vladimir,
On 12/10/18 09:39, Lee Jones wrote:
> On Fri, 12 Oct 2018, Vladimir Zapolskiy wrote:
>> On 10/12/2018 09:03 AM, Lee Jones wrote:
>>> On Tue, 09 Oct 2018, Vladimir Zapolskiy wrote:
>>>
From: Vladimir Zapolskiy
The change adds I2C device driver for TI DS90Ux9xx de-/seria
Hi Rajmohan
Thank you for the patch,
On 10/10/18 00:42, Rajmohan Mani wrote:
> Removed redundant CIO2_IMAGE_MAX_* definitions
>
> Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
>
> Signed-off-by: Rajmohan Mani
Reviewed-by: Kieran Bingha
zes too ?
I could certainly acknowledge it's worth providing a means for a
userspace app to test that it handles minimum sizes correctly.
> Signed-off-by: Hans Verkuil
If the minimum is desired:
Reviewed-by: Kieran Bingham
> ---
> diff --git a/drivers/media/platform/vicodec/vicodec-
ret = ret;
> ~~~ ^ ~~~
> 1 warning generated.
>
> Signed-off-by: Nathan Chancellor
Certainly somewhat redundant.
Reviewed-by: Kieran Bingham
> ---
> drivers/media/i2c/tc358743.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --gi
From: Laurent Pinchart
The MAX9286 deserializes video data received on up to 4 Gigabit
Multimedia Serial Links (GMSL) and outputs them on a CSI-2 port using up
to 4 data lanes.
Signed-off-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
Signed-off-by: Kieran Bingham
---
v3:
- Update
From: Jacopo Mondi
The IMI RDACM20 is a Gigabit Multimedia Serial Link (GMSL) camera
capable of transmitting video and I2C control messages on a coax cable
physical link for automotive applications.
Document its device tree binding interface.
Signed-off-by: Jacopo Mondi
Signed-off-by: Kieran
From: Kieran Bingham
The MAX9286 is a 4-channel GMSL deserializer with coax or STP input and
CSI-2 output. The device supports multicamera streaming applications,
and features the ability to synchronise the attached cameras.
CSI-2 output can be configured with 1 to 4 lanes, and a control
From: Kieran Bingham
The RDACM20 is a GMSL camera supporting 1280x800 resolution images
developed by IMI based on an Omnivision 10635 sensor and a Maxim MAX9271
GMSL serializer.
The GMSL link carries power, control (I2C) and video data over a
single coax cable.
Signed-off-by: Jacopo Mondi
indings:
- Fixes from Laurent's review comments on V2
Jacopo Mondi (1):
dt-bindings: media: i2c: Add bindings for IMI RDACM20
Kieran Bingham (2):
media: i2c: Add MAX9286 driver
media: i2c: Add RDACM20 driver
Laurent Pinchart (1):
dt-bindings: media: i2c: Add bindings for
Hi Keiichi,
Thank you for the patch update,
On 09/10/18 14:43, Keiichi Watanabe wrote:
> Support 640x480 as a frame size for video input devices of vivid.
>
> Signed-off-by: Keiichi Watanabe
My concerns have been addressed,
Reviewed-by: Kieran Bingham
> ---
> drivers/media
Hi Hans
On 08/10/18 12:53, Hans Verkuil wrote:
> Hi all,
>
> I would like to meet up somewhere during the ELCE to discuss userspace support
> for stateless (and perhaps stateful as well?) codecs.
>
> It is also planned as a topic during the summit, but I would prefer to prepare
> for that in adv
On 08/10/18 10:00, Hans Verkuil wrote:
> On 10/08/2018 10:35 AM, Kieran Bingham wrote:
>> On 06/10/18 11:29, Keiichi Watanabe wrote:
>>> Hi all,
>>>
>>> On Fri, Oct 5, 2018 at 6:18 PM, Hans Verkuil wrote:
>>>> On 10/03/18 09:08, Keiichi Watanabe
On 06/10/18 11:29, Keiichi Watanabe wrote:
> Hi all,
>
> On Fri, Oct 5, 2018 at 6:18 PM, Hans Verkuil wrote:
>> On 10/03/18 09:08, Keiichi Watanabe wrote:
>>> I think 480p is a common frame size and it's worth supporting in vivid.
>>> But, my patch might be ad-hoc. Actually, I'm not sure which va
Hi Hans, Mauro,
I believe I selected attendance when registering for the conference, but
please add my name to the list here as well.
I have a small topic which might start off in the hallway track before
hand that I'd like to kick off too.
"Fault tolerant V4L2" ...
In other words, how should w
Hi Steve,
On 08/06/18 18:43, Steve Longerbeam wrote:
> The ADV748x CSI-2 subdevices are HMDI/AFE to MIPI CSI-2 bridges.
Just spotted this :D
s/HMDI/HDMI/
Regards
Kieran
>
> Signed-off-by: Steve Longerbeam
> ---
> drivers/media/i2c/adv748x/adv748x-csi2.c | 2 +-
> 1 file changed, 1 insertio
Hi Steve,
On 08/06/18 22:34, Steve Longerbeam wrote:
> Hi Kieran,
>
>
> On 06/08/2018 02:29 PM, Kieran Bingham wrote:
>> Hi Steve,
>>
>> Thankyou for the patch.
>>
>> On 08/06/18 18:43, Steve Longerbeam wrote:
>>> The ADV748x CSI-2 subdevices
f your other work on
CSI2 drivers - or have you been looking to test the ADV748x with your CSI2
receiver? I'd love to know if the driver works with other (non-renesas)
platforms!
> Signed-off-by: Steve Longerbeam
Acked-by: Kieran Bingham
> ---
> drivers/media/i2c/adv748x/adv748x-csi
Hi Mauro
On 31/05/18 14:22, Mauro Carvalho Chehab wrote:
> Em Mon, 28 May 2018 10:43:51 -0300
> More details about the meeting:
>
> Date: June, 19
> Site: Google
> Address: 〒106-6126 Tokyo, Minato, Roppongi, 6 Chome−10−1 Roppongi Hills Mori
> Tower 44F
>
> Please confirm who will be attendin
In commit 2d9445db0ee9 ("media: vsp1: Use reference counting for
bodies"), a new field was introduced to the vsp1_dl_body structure to
account for usage tracking of the body.
Document the newly added field in the kerneldoc.
Signed-off-by: Kieran Bingham
---
drivers/media/pla
looking into those
>> in separate).
>>
>> For now, I'll apply it, but I reserve the right of not pulling any
>> new patchsets that would add more warnings.
>>
>>>
>>>
>>&g
On 18/05/18 21:53, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Friday, 18 May 2018 23:41:54 EEST Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> Commit 372b2b0399fc ("media: v4l: vsp1: Release buffers in
>> start_s
From: Kieran Bingham
The suspend and resume handlers are only utilised by video pipelines,
yet the functions currently reside in the vsp1_pipe object.
This causes an issue with resume, as the functions incorrectly call
vsp1_pipeline_run() directly instead of processing the video object
through
From: Kieran Bingham
The entities provide a single .configure operation which configures the
object into the target display list, based on the vsp1_entity_params
selection.
Split the configure function into three parts, '.configure_stream()',
'.configure_frame()', and &
From: Kieran Bingham
Currently the entities store their configurations into a display list.
Adapt this such that the code can be configured into a body directly,
allowing greater flexibility and control of the content.
All users of vsp1_dl_list_write() are removed in this process, thus it
too
From: Kieran Bingham
The body write function relies on the code never asking it to write more
than the entries available in the list.
Currently with each list body containing 256 entries, this is fine, but
we can reduce this number greatly saving memory. In preparation of this
add a level of
From: Kieran Bingham
Adapt the dl->body0 object to use an object from the body pool. This
greatly reduces the pressure on the TLB for IPMMU use cases, as all of
the lists use a single allocation for the main body.
The CLU and LUT objects pre-allocate a pool containing three bodies,
allowin
From: Kieran Bingham
Extend the display list body with a reference count, allowing bodies to
be kept as long as a reference is maintained. This provides the ability
to keep a cached copy of bodies which will not change, so that they can
be re-applied to multiple display lists.
Signed-off-by
From: Kieran Bingham
Throughout the codebase, the term 'fragment' is used to represent a
display list body. This term duplicates the 'body' which is already in
use.
The datasheet references these objects as a body, therefore replace all
mentions of a fragment with a
From: Kieran Bingham
Each display list allocates a body to store register values in a dma
accessible buffer from a dma_alloc_wc() allocation. Each of these
results in an entry in the IOMMU TLB, and a large number of display list
allocations adds pressure to this resource.
Reduce TLB pressure on
From: Kieran Bingham
We are now able to configure a pipeline directly into a local display
list body. Take advantage of this fact, and create a cacheable body to
store the configuration of the pipeline in the video object.
vsp1_video_pipeline_run() is now the last user of the pipe->dl obj
From: Kieran Bingham
Commit 372b2b0399fc ("media: v4l: vsp1: Release buffers in
start_streaming error path") introduced a helper to clean up buffers on
error paths, but inadvertently changed the code such that only the
output WPF buffers were cleaned, rather than the video node being
o
From: Kieran Bingham
Each display list currently allocates an area of DMA memory to store register
settings for the VSP1 to process. Each of these allocations adds pressure to
the IPMMU TLB entries.
We can reduce the pressure by pre-allocating larger areas and dividing the area
across multiple
Hi Laurent,
On 17/05/18 20:57, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Thursday, 17 May 2018 20:24:01 EEST Kieran Bingham wrote:
>> We are now able to configure a pipeline directly into a local display
>> list body. Take advantage
allocating multiple display list
bodies in a single allocation, and providing these to the display list
through a 'body pool'. A pool can be allocated by the display list
manager or entities which require their own body allocations.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
,150,160,200,210,230,240: pass
Testing histogram HGT with hue areas
240,20,60,80,100,120,140,160,180,200,210,220: pass
- vsp-unit-test-0024.sh
Test requires unavailable feature set `rpf.0 rpf.1 brs wpf.0': skipped
168 tests: 147 passed, 0 failed, 3 skipped
Kieran Bingham (8):
media: vsp1:
101 - 200 of 848 matches
Mail list logo
