Hi,
Looks like the Linux definition of the (packed) YUV444 format contradicts
wikipedia. According to
https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-packed-yuv.html
The Linux V4L2_PIX_FMT_YUV444 format takes 16 bits per pixel, whereas the
wikipedia
https://en.wikipedia.org/wik
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: Thu Oct 27 05:00:13 CEST 2016
media-tree git hash:bd676c0c04ec94bd830b9192e2c33f2c4532278d
media_build gi
On 10/26/2016 11:09 PM, Hugues FRUCHET wrote:
Hi,
This RFC aims to start discussions in order to define the codec specific
controls structures to fulfill the low-level decoder API needed by non
“Stream API” based decoders (“stateless” or “Frame API” based decoders).
Several implementation e
2016-10-26 Brian Starkey :
> Some parts of setting up the CRTC out-fence can be re-used for
> writeback out-fences. Factor this out into a separate function.
>
> Signed-off-by: Brian Starkey
> ---
> drivers/gpu/drm/drm_atomic.c | 64
> +++---
> 1 file chan
2016-10-26 Brian Starkey :
> If userspace has asked for an out-fence for the writeback, we add a
> fence to malidp_mw_job, to be signaled when the writeback job has
> completed.
>
> Signed-off-by: Brian Starkey
> ---
> drivers/gpu/drm/arm/malidp_hw.c |5 -
> drivers/gpu/drm/arm/malidp_m
2016-10-26 Brian Starkey :
> Add the OUT_FENCE_PTR property to writeback connectors, to enable
> userspace to get a fence which will signal once the writeback is
> complete.
>
> A timeline is added to drm_connector for use by the writeback
> out-fences. It is up to drivers to check for a fence in
2016-10-26 Brian Starkey :
> Some parts of setting up the CRTC out-fence can be re-used for
> writeback out-fences. Factor this out into a separate function.
>
> Signed-off-by: Brian Starkey
> ---
> drivers/gpu/drm/drm_atomic.c | 64
> +++---
> 1 file chan
The rework of the PM support has caused two functions to
be orphaned when CONFIG_PM is disabled:
media/i2c/smiapp/smiapp-core.c:1352:12: error: 'smiapp_power_off' defined but
not used [-Werror=unused-function]
media/i2c/smiapp/smiapp-core.c:1206:12: error: 'smiapp_power_on' defined but
not used
On Wed, Oct 19, 2016 at 4:21 AM, Laurent Pinchart
wrote:
> Hi Todor,
>
> On Wednesday 19 Oct 2016 12:14:55 Todor Tomov wrote:
>> On 10/19/2016 11:49 AM, Laurent Pinchart wrote:
>> > On Friday 14 Oct 2016 15:01:08 Todor Tomov wrote:
>> >> On 09/08/2016 03:22 PM, Laurent Pinchart wrote:
>> >>> On Th
On 26/10/16 15:07, Todor Tomov wrote:
Hi,
On 10/26/2016 03:48 PM, Ian Arkver wrote:
[snip]
+static int ov5645_regulators_enable(struct ov5645 *ov5645)
+{
+int ret;
+
+ret = regulator_enable(ov5645->io_regulator);
+if (ret < 0) {
+dev_err(ov5645->dev, "set io voltage failed\
Hi,
On 10/26/2016 03:48 PM, Ian Arkver wrote:
> [snip]
>>> +static int ov5645_regulators_enable(struct ov5645 *ov5645)
>>> +{
>>> +int ret;
>>> +
>>> +ret = regulator_enable(ov5645->io_regulator);
>>> +if (ret < 0) {
>>> +dev_err(ov5645->dev, "set io
On Wed, Oct 26, 2016 at 01:42:42PM +0100, Brian Starkey wrote:
> On Wed, Oct 26, 2016 at 01:00:21PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 26, 2016 at 09:55:00AM +0100, Brian Starkey wrote:
> > > diff --git a/drivers/gpu/drm/drm_writeback.c
> > > b/drivers/gpu/drm/drm_writeback.c
> > > new fi
[snip]
+static int ov5645_regulators_enable(struct ov5645 *ov5645)
+{
+ int ret;
+
+ ret = regulator_enable(ov5645->io_regulator);
+ if (ret < 0) {
+ dev_err(ov5645->dev, "set io voltage failed\n");
+ return ret;
+ }
+
+ ret = regulator_en
Hi Gustavo,
It would be great if you could cast your eye over this one as-well.
My intention was to be as similar to the CRTC out-fences as possible.
Thanks,
Brian
On Wed, Oct 26, 2016 at 09:55:07AM +0100, Brian Starkey wrote:
Add the OUT_FENCE_PTR property to writeback connectors, to enable
u
On Wed, Oct 26, 2016 at 01:00:21PM +0200, Daniel Vetter wrote:
On Wed, Oct 26, 2016 at 09:55:00AM +0100, Brian Starkey wrote:
Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.
D
On Wed, Oct 26, 2016 at 02:27:23PM +0300, Todor Tomov wrote:
> And using Mark Brown's correct address...
This is an *enormous* e-mail quoted to multiple levels with top posting
and very little editing which makes it incredibly hard to find any
relevant content.
> >> I believe it should be an API
Hi Marek,
On 19/10/16 20:25, Marek Vasut wrote:
On 10/19/2016 06:22 PM, Jack Mitchell wrote:
Hi Philipp,
On 17/10/16 13:12, Philipp Zabel wrote:
Hi Jack,
Am Montag, den 17.10.2016, 12:32 +0100 schrieb Jack Mitchell:
Hi Philipp,
I'm looking at how I would enable a parallel greyscale camera
And using Mark Brown's correct address...
On 10/26/2016 02:15 PM, Todor Tomov wrote:
> Hi,
>
> Adding Mark Brown in --to list.
>
> My reply on comments below.
> The question on regulator bulk API to Mark Brown still holds.
>
>
> On 10/19/2016 11:44 AM, Laurent Pinchart wrote:
>> Hi Todor,
>>
>
Hi,
Adding Mark Brown in --to list.
My reply on comments below.
The question on regulator bulk API to Mark Brown still holds.
On 10/19/2016 11:44 AM, Laurent Pinchart wrote:
> Hi Todor,
>
> (CC'ing Mark Brown for a question on regulators)
>
> On Friday 14 Oct 2016 14:57:01 Todor Tomov wrote:
Hi Gustavo,
As Daniel rightly pointed out you would likely be interested in this
patch.
This is on-top of your v5 patch-set, with the bug-fixes I mentioned
before. I haven't dropped the fence_get(), as I figured you're
probably going to rebase your patches on top of the fence_get() in
sync_file_
On Wed, Oct 26, 2016 at 09:55:07AM +0100, Brian Starkey wrote:
> Add the OUT_FENCE_PTR property to writeback connectors, to enable
> userspace to get a fence which will signal once the writeback is
> complete.
>
> A timeline is added to drm_connector for use by the writeback
> out-fences. It is up
On Wed, Oct 26, 2016 at 09:55:06AM +0100, Brian Starkey wrote:
> Some parts of setting up the CRTC out-fence can be re-used for
> writeback out-fences. Factor this out into a separate function.
>
> Signed-off-by: Brian Starkey
Cc: Gustavo here pls, probably best if he reviews this one.
-Daniel
On Wed, Oct 26, 2016 at 09:55:00AM +0100, Brian Starkey wrote:
> Writeback connectors represent writeback engines which can write the
> CRTC output to a memory framebuffer. Add a writeback connector type and
> related support functions.
>
> Drivers should initialize a writeback connector with
> dr
A previous patch tried to fix a build error, but introduced another
warning:
drivers/media/platform/mtk-mdp/mtk_mdp_core.c:71:13: error: ‘mtk_mdp_clock_off’
defined but not used [-Werror=unused-function]
drivers/media/platform/mtk-mdp/mtk_mdp_core.c:62:13: error: ‘mtk_mdp_clock_on’
defined but n
If userspace has asked for an out-fence for the writeback, we add a
fence to malidp_mw_job, to be signaled when the writeback job has
completed.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/arm/malidp_hw.c |5 -
drivers/gpu/drm/arm/malidp_mw.c | 18 +-
drivers/gpu/d
Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.
Drivers should initialize a writeback connector with
drm_writeback_connector_init() which takes care of setting up all the
writeba
Add the OUT_FENCE_PTR property to writeback connectors, to enable
userspace to get a fence which will signal once the writeback is
complete.
A timeline is added to drm_connector for use by the writeback
out-fences. It is up to drivers to check for a fence in the
connector_state and signal the it a
Some parts of setting up the CRTC out-fence can be re-used for
writeback out-fences. Factor this out into a separate function.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/drm_atomic.c | 64 +++---
1 file changed, 42 insertions(+), 22 deletions(-)
diff
From: Liviu Dudau
Mali-DP display processors are able to write the composition result to a
memory buffer via the SE.
Add entry points in the HAL for enabling/disabling this feature, and
implement support for it on DP650 and DP550. DP500 acts differently and
so is omitted from this change.
Signe
Mali-DP has a memory writeback engine which can be used to write the
composition result to a memory buffer.
Expose this functionality as a DRM writeback connector on supported
hardware.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/arm/Makefile |1 +
drivers/gpu/drm/arm/malidp_crtc.c
We're going to use the same format list for output formats, so rename
everything related to input formats to avoid confusion.
Signed-off-by: Brian Starkey
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_hw.c | 24
drivers/gpu/drm/arm/malidp_hw.h |8
Add a layer bit for the SE memory-write, and add it to the pixel format
matrix for DP550/DP650.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/arm/malidp_hw.c | 28 ++--
drivers/gpu/drm/arm/malidp_hw.h |1 +
2 files changed, 15 insertions(+), 14 deletions(-)
diff
It's possible for CVAL to get set whilst we are in config mode. If this
happens, afer we leave config mode the HW will latch whatever
configuration is in the registers at the next vsync. Most likely this
will be a partial configuration, as we'll be racing against the ongoing
atomic_commit.
To avoi
Hi,
This is an updated RFC series introducing a new connector type:
DRM_MODE_CONNECTOR_WRITEBACK
See v1 here: [1]
Writeback connectors are used to expose the memory writeback engines
found in some display controllers, which can write a CRTC's
composition result to a memory buffer.
This is useful
This patch moves vb2_dc_get_base_sgt() function above mmap buffers
callbacks, particularly vb2_dc_alloc() and vb2_dc_mmap() from where it
will be called for cacheable MMAP support introduced in the next patch.
Signed-off-by: Thierry Escande
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 44
Hi,
This series adds support for cacheable MMAP in DMA coherent allocator.
The first patch moves the vb2_dc_get_base_sgt() function above mmap
callbacks for calls introduced by the second patch. This avoids a
forward declaration.
Changes in v2:
- Put function move in a separate patch
- Added com
From: Heng-Ruey Hsu
DMA allocations for MMAP type are uncached by default. But for
some cases, CPU has to access the buffers. ie: memcpy for format
converter. Supporting cacheable MMAP improves huge performance.
This patch enables cacheable memory for DMA coherent allocator in mmap
buffer alloca
37 matches
Mail list logo