when the full display
pipeline has completed for the frame.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 8 ++--
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 1 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 9 +
3
to be registered within the VSP DRM interface.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
v2:
- vsp1_du_setup_lif() uses config structure to set callbacks
- vsp1_du_pipeline_frame_end() moved to interrupt section
- vsp1_du_pipeline_frame_end regi
when the full display
pipeline has completed for the frame.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
v2:
- Commit message completely re-worded for patch re-work.
- drm_crtc_handle_vblank() re-instated in event of rcrtc->pending
- removed passing of un
flips at the end of
VSP processing.
These patches have been tested by introducing artificial delays in the commit
code paths and verifying that no visual tearing or flickering occurs.
Manual start/stop testing has also been performed
Kieran Bingham (3):
v4l: vsp1: extend VSP1 module
-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_dl.c | 9 +++--
drivers/media/platform/vsp1/vsp1_dl.h | 2 +-
drivers/media/platform/vsp1/vsp1_drm.c | 4 +++-
drivers/media/platform/vsp1/vsp1_pipe.c | 6 +-
drivers/media/pl
Hi Laurent,
On 03/03/17 02:17, Laurent Pinchart wrote:
> 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 w
Hi Laurent,
On 03/03/17 02:11, Laurent Pinchart wrote:
> 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
Hi Laurent,
Thanks for the review,
On 03/03/17 01:57, Laurent Pinchart wrote:
> 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 inter
The struct vsp1_drm references a member 'planes' which doesn't exist.
Correctly identify this documentation against the 'inputs'
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_drm.h | 2 +-
1 file changed, 1 insertion(+), 1 de
off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> ---
> drivers/media/platform/vsp1/vsp1_pipe.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/dr
an extra frame completion interrupt.
Track this delay, by passing the frame flip event through the VSP
module; It will be returned only when the frame has completed and can be
returned to the caller.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/gpu/drm/r
as
the output.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_drm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index cd209dccff1b..8e2aa3
, the event can be returned back to the originator through the
registered callback.
We must not have bidirectional dependencies on the two components to
maintain support for loadable modules, thus we extend the API to allow
a callback to be registered within the VSP DRM interface.
Signed-off-by: Kieran
believe this is due to the one frame latency imposed by the
VSPD and will need further investigation.
Kieran Bingham (3):
v4l: vsp1: Register pipe with output WPF
v4l: vsp1: extend VSP1 module API to allow DRM callback registration
drm: rcar-du: Register a completion callback with VSP1
drivers
memory formats
> support")
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bing...@ideasonboard.com>
> ---
> drivers/media/platform/vsp1/vsp1_wpf.c | 9 +
> 1 file changed, 9 insertions(+)
>
to it's predecessor in the pipeline.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_entity.h | 8 -
drivers/media/platform/vsp1/vsp1_pipe.c | 22 -
drivers/media/platform/vsp1/vsp1_pipe.h
To improve image quality when scaling using the UDS we need to correctly
determine the start phase value for each partition window.
Provide helper functions for calculating the phase, and write this value
to the registers when used.
Signed-off-by: Kieran Bingham <kieran.bingham+r
When generating the partition windows, operate directly on the partition
struct rather than copying and duplicating the processed data
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_video.c | 43 -
Increase the overlap on the left edge to allow a margin to provide
better image scaling
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_rpf.c | 7 +-
drivers/media/platform/vsp1/vsp1_uds.c | 39 ---
2
As we develop the partition algorithm, we need to store more information
per partition to describe the phase and other parameters.
To keep this data together, further abstract the existing v4l2_rect
into a partition specific structure
Signed-off-by: Kieran Bingham <kieran.bingham+r
The image partition algorithm operates on the image dimensions as input
into the WPF entity.
Correct this in the code, and document what defines the properties for
the algorithm in the section header
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers
Provide register definitions required for UDS phase and partition
algorithm support
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_regs.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/media/platfor
The UDS and other entities are already tracked directly through the
pipeline object. To follow the design pattern, and allow us to reference
the SRU convert the usage of 'sru_found'
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platfor
s from one partition to the next.
[0] https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg08631.html
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#vsp1/pa-phases-2017-02-10
Kieran Bingham (8):
v4l: vsp1: Provide UDS register updates
v4l: vsp1: Track the
Hi Avraham,
On 08/02/17 12:11, Avraham Shukron wrote:
> Hi!
>
> I submitted a patch which is now at v3 already.
> In patchwork they appear separated / unrelated.
> 1. Is there a way to tell patchwork that they are all actually iterations
>of the same patch?
I don't believe this is possible
Hi Laurent,
I've been reworking this series to split things out and adapt for the
comments you've provided, but I have the following queries outstanding:
On 15/12/16 11:50, Kieran Bingham wrote:
> Hi Laurent,
>
> On 14/12/16 16:30, Laurent Pinchart wrote:
>> Hi Kieran,
Move the static vsp1_video_setup_pipeline() function in preparation for
the callee updates so that the vsp1_video_pipeline_run() call can
configure pipelines following suspend resume actions.
This commit is just a code move for clarity performing no functional
change.
Signed-off-by: Kieran
When a suspend/resume action is taken, the pipeline is reset and never
reconfigured.
To correct this, we establish a new flag pipe->configured and utilise
this to establish when we write a full configuration set to the current
display list.
Signed-off-by: Kieran Bingham <kieran.bingha
ere a display list is committed without having
called vsp1_video_setup_pipeline() first
Repair this issue, by ensuring that only the stream which configures the
pipeline is able to start it.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
v4:
- Revert and re
The pipe->dl is used only inside vsp1_du_atomic_flush(), and can be
obtained and stored locally to simplify the code.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_drm.c | 20 ++--
drivers/media/plat
e_init to vsp1_reset_wpf()
- Clean up flag dereferencing with a local struct *
v2:
- Refactor video pipeline configuration implementation to solve both suspend
resume and the VSP BRU race in a single change
v1:
- Original pipeline configuration rework
Kieran Bingham (4):
v4l: vsp1: Prevent multiple st
On 03/01/17 13:36, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Tuesday 03 Jan 2017 13:12:11 Kieran Bingham wrote:
>> Drivers must not perform unbalanced calls to stop the entity pipeline,
>> however if they do they will fault in the core m
nts, with a check on
NULL pipe elements instead, as this is the symptom of unbalanced
media_pipeline_stop calls.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/media-entity.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/driv
is not zero).
>
> Add ".4" to the format specifier to limit the number of printed
> characters to four. The resulting format specifier "%4.4s" is also used
> by other media drivers to print pixelformat value.
>
> Signed-off-by: Nicolas Iooss <nicolas.i
Hi Laurent,
On 14/12/16 16:30, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Tuesday 13 Dec 2016 17:59:42 Kieran Bingham wrote:
>> With multiple inputs through the BRU it is feasible for the streams to
>> race each other at stream-on.
&g
at this.
--
Regards
Kieran
On 13/12/16 17:59, Kieran Bingham wrote:
> media_entity_pipeline_stop() can be called through error paths with a
> NULL entity pipe object. In this instance, stopping is a no-op, so
> simply return without any action
>
> Signed-off-by: Kieran Bingham <k
Hi Sakari,
On 14/12/16 12:43, Sakari Ailus wrote:
> Hi Kieran,
>
> On Wed, Dec 14, 2016 at 12:27:37PM +0000, Kieran Bingham wrote:
>> Hi Sakari,
>>
>> On 14/12/16 07:28, Sakari Ailus wrote:
>>> Hi Kieran,
>>>
>>> On Tue,
Hi Sakari,
On 14/12/16 07:28, Sakari Ailus wrote:
> Hi Kieran,
>
> On Tue, Dec 13, 2016 at 05:59:44PM +0000, Kieran Bingham wrote:
>> media_entity_pipeline_stop() can be called through error paths with a
>> NULL entity pipe object. In this instance, stopping is a no-op
media_entity_pipeline_stop() can be called through error paths with a
NULL entity pipe object. In this instance, stopping is a no-op, so
simply return without any action
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
I've marked this patch as RFC, although if
ent side effect of this, by specifying that the
configuration has been lost during suspend/resume actions - the
vsp1_video_pipeline_run() call can re-initialise pipelines when
necessary thus repairing resume actions for active m2m pipelines.
Signed-off-by: Kieran Bingham <kieran.bingha
dl is set during the atomic begin hook, but it is
not utilised until the flush. Moving this should do no harm.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_drm.c | 20 +++---
drivers/media/platform/vsp1/vsp1_pipe.h |
U race in a single change
v1:
- Original pipeline configuration rework
Kieran Bingham (4):
v4l: vsp1: Move vsp1_video_setup_pipeline()
v4l: vsp1: Refactor video pipeline configuration
v4l: vsp1: Use local display lists and remove global pipe->dl
media: Catch null pipes on pipe
Move the static vsp1_video_setup_pipeline() function in preparation for
the callee updates so that the vsp1_video_pipeline_run() call can
configure pipelines following suspend resume actions.
This commit is just a code move for clarity performing no functional
change.
Signed-off-by: Kieran
Reviewing my own patch here, as I've just seen something...
On 06/12/16 09:35, Kieran Bingham wrote:
> With multiple inputs through the BRU it is feasible for the streams to
> race each other at stream-on. In the case of the video pipelines, this
> can present two serious issues.
>
nsider it as
blocking for the first three patches of this series.
Kieran Bingham (4):
v4l: vsp1: Move vsp1_video_setup_pipeline()
v4l: vsp1: Refactor video pipeline configuration
v4l: vsp1: Use local display lists and remove global pipe->dl
media: Catch null pipes on pipeline stop
ent side effect of this, by specifying that the
configuration has been lost during suspend/resume actions - the
vsp1_video_pipeline_run() call can re-initialise pipelines when
necessary thus repairing resume actions for active m2m pipelines.
Signed-off-by: Kieran Bingham <kieran.bingha
media_entity_pipeline_stop() can be called through error paths with a
NULL entity pipe object. In this instance, stopping is a no-op, so
simply return without any action
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
I've marked this patch as RFC, although if
dl is set during the atomic begin hook, but it is
not utilised until the flush. Moving this should do no harm.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_drm.c | 20 +++---
drivers/media/platform/vsp1/vsp1_pipe.h |
Move the static vsp1_video_setup_pipeline() function in preparation for
the callee updates so that the vsp1_video_pipeline_run() call can
configure pipelines following suspend resume actions.
This commit is just a code move for clarity performing no functional
change.
Signed-off-by: Kieran
the issue repaired here.
--
Regards
Kieran
On 11/11/16 10:31, Kieran Bingham wrote:
> With multiple inputs through the BRU it is feasible for the streams to
> race each other at stream-on. In the case of the video pipelines, this
> can present two serious issues.
>
> 1) A null-derefere
ned-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
I considered a few options to fix this issue. If anyone disagrees with my
reasoning, and believes one of the below approaches should be used, let me
know and I'll rework the patch.
A) Moving the vsp1_video_pipeline_r
the function without any code change.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_video.c | 74
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_vide
, the use of an SRU will always engage the partition
algorithm, therefore we must always ensure the restrictions are met on
Gen3 hardware utilising an SRU in the pipeline.
A pipeline with an SRU connected after the UDS will disable any scaling
features of the SRU.
Signed-off-by: Kieran Bingham
.
Utilise local variables for the processing as required.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_pipe.h | 4
drivers/media/platform/vsp1/vsp1_video.c | 19 +--
2 files changed, 9 insertions(+), 14 del
algorithm on Gen3 hardware.
Patches 2,3 and 4 clean up the calculation of the partition sizes such that they
are only calculated once at streamon - and the partition windows are stored in
the vsp1_pipeline object.
Kieran Bingham (4):
v4l: vsp1: Implement partition algorithm restrictions
v4l: vsp1
the partition sizes into this table.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_pipe.h | 6 ++
drivers/media/platform/vsp1/vsp1_video.c | 8 ++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/d
.
The source will be able to perform pixel format conversion, but not
rescaling, and as such the output from the memory node will always be
of the same dimensions as the display output.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
Changes since RFC
eback mode if there is an
output buffer, or disable it (leaving the existing display pipeline
unharmed) otherwise.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_video.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/driver
/VSP1 specific.
Kieran Bingham (2):
Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
v4l: vsp1: Provide a writeback video device
drivers/media/platform/vsp1/vsp1.h | 1 +
drivers/media/platform/vsp1/vsp1_drm.c | 19
drivers/media/platform/vsp1/
.
The source will be able to perform pixel format conversion, but not
rescaling, and as such the output from the memory node will always be
of the same dimensions as the display output.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
With the patch "[media
Hi Laurent,
On 02/11/16 23:59, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Thursday 27 Oct 2016 15:01:24 Kieran Bingham wrote:
>> The upcoming writeback feature of the VSP1 WPF, allows the active output
>> of the DU to be written back
Looks like I forgot to run checkpatch here, and it picked up a few things.
Please disregard them in your review, and they will be fixed for next
version.
On 27/10/16 15:01, Kieran Bingham wrote:
> When the VSP1 is used in an active display pipeline, the output of the
> WPF can supply t
.
The source will be able to perform pixel format conversion, but not
rescaling, and as such the output from the memory node will always be
of the same dimensions as the display output.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/
of the entity. Configured in this mode,
the WPF will output to both the LIF, and to a memory (V4L2 video)
device.
Support this feature by extending vsp1_entity_init() to specify the
number of source and sink pads.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.
Video node
from the VSP-D. On Salvator-H3, on renesas-drivers-2016-10-25-v4.9-rc2 this is
active at /dev/video28
Kieran Bingham (3):
Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
v4l: vsp1: allow entities to have multiple source pads
v4l: vsp1: Provide a writeback vi
it (leaving the existing display pipeline
unharmed) otherwise.
Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_video.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_video.c
b/d
respin.
--
Regards
Kieran
On 24/10/16 10:03, Laurent Pinchart wrote:
> From: Kieran Bingham <kieran+rene...@bingham.xyz>
>
> The FDP1 driver performs advanced de-interlacing on a memory 2 memory
> based video stream, and supports conversion from YCbCr/YUV
> to RGB pixel fo
t;0 0xfe94 0 0x2400>;
> + interrupts = ;
> + clocks = < CPG_MOD 119>;
> + power-domains = < R8A7796_PD_A3VC>;
> + renesas,fcp = <>;
> + };
> };
> };
>
On 14/09/16 00:16, Laurent Pinchart wrote:
> From: Kieran Bingham <kieran+rene...@bingham.xyz>
>
> The frame-end function releases and completes the buffers on the input
> and output entities of the pipe before marking the pipe->state as
> 'STOPPED'. This introduces a ra
I've gone through this one as well, and certainly seems like some much
better approaches in there.
I can't find anything to fault it.
Acked-by: Kieran Bingham <kie...@bingham.xyz>
Reviewed-by: Kieran Bingham <kie...@bingham.xyz>
Thanks again,
Kieran
On 07/09/16 23:25, Laurent Pi
, and preparing the buffers early is
clearly more elegant and less prone to failure.
Thanks
Kieran
...
Obligatory over tagging
Acked-by: Kieran Bingham <kie...@bingham.xyz>
Reviewed-by: Kieran Bingham <kie...@bingham.xyz>
On 07/09/16 23:25, Laurent Pinchart wrote:
> The struct fdp1_b
tainly isn't a bad thing to verify they are what we were told they
would be :D
--
Reviewed-by: Kieran Bingham <kie...@bingham.xyz>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
> ---
> drivers/media/platform/rcar_fdp1.c | 40
> +
On 07/09/16 23:25, Laurent Pinchart wrote:
> The structure is not used, remove it.
Ahh yes, looks like a left over from my first attempt at serialising
input fields.
Reviewed-by: Kieran Bingham <kie...@bingham.xyz>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@i
experimental
> and doesn't fix any known bug. I've included the patch in the series to get
> feedback on whether this is a good idea.
>
> Kieran, I noticed that your patches are authored by
>
> Kieran Bingham <kie...@ksquared.org.uk>
>
> Is that correct o
p1_queue_setup(),
> - Convert the FDP1 driver to use the new vb2_queue dev field, cfr.
> commit 53ddcc683faef8c7 ("[media] media/platform: convert drivers to
> use the new vb2_queue dev field").
>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
inchart+rene...@ideasonboard.com>
Reviewed-by: Kieran Bingham <kie...@bingham.xyz>
> ---
> Documentation/media/uapi/v4l/extended-controls.rst | 4
> drivers/media/v4l2-core/v4l2-ctrls.c | 2 ++
> include/uapi/linux/v4l2-controls.h | 1 +
>
> /* M2M registration */
> @@ -2327,9 +2317,6 @@ release_m2m:
> unreg_dev:
> v4l2_device_unregister(>v4l2_dev);
>
> -vb2_allocator_rollback:
> - vb2_dma_contig_cleanup_ctx(fdp1->alloc_ctx);
> -
> return ret;
> }
>
> @@ -2340,7 +2327,6 @@ static int fdp1_remove(struct platform_device *pdev)
> v4l2_m2m_release(fdp1->m2m_dev);
> video_unregister_device(>vfd);
> v4l2_device_unregister(>v4l2_dev);
> - vb2_dma_contig_cleanup_ctx(fdp1->alloc_ctx);
> pm_runtime_disable(>dev);
>
> return 0;
>
--
Regards
Kieran Bingham
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
The FDP1 is a de-interlacing module which converts interlaced video to
progressive video. It is also capable of performing pixel format conversion
between YCbCr/YUV formats and RGB formats.
Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Signed-off-by: Kieran Bingha
The FCP driver can also support the FCPF variant for FDP1 compatible
processing.
Acked-by: Rob Herring <r...@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
---
Documentation/devicetree/bind
The power domain must be specified to bring the device out of module
standby. Document this in the bindings provided, so that new additions
are not missed.
Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
---
Documentation/devicetree/bindings/media/renesas,fcp.txt | 5 +
1 file chan
compatibles as we have a
HW version register available to us in the hardware so we can detect at
run-time what device version we are running on.
Kieran Bingham (3):
dt-bindings: Update Renesas R-Car FCP DT binding
dt-bindings: Document Renesas R-Car FCP power-domains usage
dt-bindings: Add Renesas R
at the same time as converting interlaced content to progressive.
Kieran Bingham (1):
v4l: platform: Add Renesas R-Car FDP1 Driver
MAINTAINERS|9 +
drivers/media/platform/Kconfig | 13 +
drivers/media/platform/Makefile|1 +
drivers/media/platform
The FDP1 driver performs advanced de-interlacing on a memory 2 memory
based video stream, and supports conversion from YCbCr/YUV
to RGB pixel formats
Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
---
MAINTAINERS|9 +
drivers/media/platform/Kconfig
de pix_mp, not after it.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
Tested-by: Kieran Bingham <kie...@bingham.xyz>
> ---
> drivers/media/v4l2-core/v4l2-ioctl.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> K
On 10/06/16 18:40, Rob Herring wrote:
> On Thu, Jun 09, 2016 at 02:41:34PM +0100, Kieran Bingham wrote:
>> The FDP1 is a de-interlacing module which converts interlaced video to
>> progressive video. It is also capable of performing pixel format conversion
>> between YCbC
On 10/06/16 18:37, Rob Herring wrote:
> On Thu, Jun 09, 2016 at 02:41:32PM +0100, Kieran Bingham wrote:
>> The FCP driver, can also support the FCPF variant for FDP1 compatible
>
> Drop the comma.
Ok
>> processing.
>>
>> Signed-off-by: K
Today I learned about make C=1
So ... reviewing my own patch, consider the following sparse warnings
'fixed up'
I'll run make C=1 before any future submissions from now on.
On 09/06/16 18:37, Kieran Bingham wrote:
> The FDP1 driver performs advanced de-interlacing on a memory 2 memory
>
Minor tweaks to document the swap register and make the documentation
match the struct ordering
Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
---
drivers/media/platform/vsp1/vsp1_pipe.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platfor
Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 66de4da2d244..bc083b58e478 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7312,6 +7312,15 @@ S: Supported
F: Documen
The FDP1 driver performs advanced de-interlacing on a memory 2 memory
based video stream, and supports conversion from YCbCr/YUV
to RGB pixel formats
Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
---
drivers/media/platform/Kconfig | 13 +
drivers/media/platform/Makefile
driver this seemed
like an apt point to start the review process.
Kieran Bingham (2):
v4l: platform: Add Renesas R-Car FDP1 Driver
MAINTAINERS: Add support for FDP driver
MAINTAINERS|9 +
drivers/media/platform/Kconfig | 13 +
drivers/media/platform/Makefile
The FCP must be powered up for the FDP1 to function, even when the FDP1
does not make use of the FCNL features. Extend the compatible list
to allow us to use the power domain and runtime-pm support.
Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
---
drivers/media/platform/rcar-fcp.c |
.html
Kieran Bingham (1):
v4l: Extend FCP compatible list to support the FDP
drivers/media/platform/rcar-fcp.c | 1 +
1 file changed, 1 insertion(+)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kerne
The FDP1 is a de-interlacing module which converts interlaced video to
progressive video. It is also capable of performing pixel format conversion
between YCbCr/YUV formats and RGB formats.
Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
---
.../devicetree/bindings/media/renesas,fd
The FCP driver, can also support the FCPF variant for FDP1 compatible
processing.
Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
---
Documentation/devicetree/bindings/media/renesas,fcp.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devi
The power domain must be specified to bring the device out of module
standby. Document this in the example provided, so that new additions
are not missed.
Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
---
Documentation/devicetree/bindings/media/renesas,fcp.txt | 1 +
1 file chan
Hi Geert,
On 28/05/16 20:03, Geert Uytterhoeven wrote:
> Hi Kieran,
>
> On Fri, May 27, 2016 at 7:19 PM, Kieran Bingham <kie...@ksquared.org.uk>
> wrote:
>> The example misses the power-domains usage, and documentation that the
>> property is used by the nod
Hi Geert!
On 28/05/16 20:06, Geert Uytterhoeven wrote:
> Hi Kieran,
>
> On Fri, May 27, 2016 at 7:19 PM, Kieran Bingham <kie...@ksquared.org.uk>
> wrote:
>> The FCP driver, can also support the FCPF variant for FDP1 compatible
>> processing.
>>
&
My apologies - I had a stale file in my patches folder :(
This one had the wrong commit-shortlog, please ignore.
--
Kieran
On 27/05/16 18:19, Kieran Bingham wrote:
> The FCP must be powered up for the FDP1 to function, even when the FDP1
> does not make use of the FCNL features.
The FCP must be powered up for the FDP1 to function, even when the FDP1
does not make use of the FCNL features. Extend the compatible list
to allow us to use the power domain and runtime-pm support.
Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
---
drivers/media/platform/rcar-fcp.c |
601 - 700 of 705 matches
Mail list logo
