On 10/16/19 11:54 AM, Fabio Estevam wrote:
On Wed, Oct 16, 2019 at 2:31 PM Steve Longerbeam wrote:
If /dev/video2 is the "ipu1_ic_prpvf capture" node, it's because FIM is
not yet available on those nodes. The FIM is only available on the
"ipuX_csiY capture" nodes
On 10/16/19 6:04 AM, Fabio Estevam wrote:
Hi Steve,
On Tue, Oct 15, 2019 at 10:18 PM Steve Longerbeam wrote:
Here's a quick example that uses the end-of-frame method to measure fi's
(all other FIM controls are left at the default values):
v4l2-ctl -d0 --set-ctrl=fim_enable=1
On 10/15/19 12:11 PM, Fabio Estevam wrote:
Hi Steve,
On Tue, Oct 15, 2019 at 3:19 PM Steve Longerbeam wrote:
I submitted the ICAP driver patch quite a while ago, it was ~2 yrs ago I
think. Can't seem to find the link unfortunately.
I'll work on updating the driver and retestin
On 10/15/19 9:00 AM, Fabio Estevam wrote:
Pass the v4l2-ctl configuration for the imx6q-sabreauto PAL
example for completeness and consistency.
Suggested-by: Steve Longerbeam
Signed-off-by: Fabio Estevam
Acked-by: Steve Longerbeam
---
Changes since v2:
- Newly introduced patch
csi1:0
[5.169953] imx-media: adv7180 4-0021:0 -> ipu1_csi0_mux:4
To avoid confusion, add an entry that shows how to setup the links and
configure the pads that are specific to the i.MX6DL sabrea
Signed-off-by: Fabio Estevam
Acked-by: Steve Longerbeam
---
Changes since v2:
- Fix I2C an
case, but such
config symbol does not exist in mainline.
It seems we still need the input capture support to be able to
measuring frame intervals.
Maybe Steve can shed some light on this?
I submitted the ICAP driver patch quite a while ago, it was ~2 yrs ago I
think. Can't seem to fin
27;ipu1_ic_prp':2 [fmt:AYUV32/720x576 field:none]"
+ media-ctl -V "'ipu1_ic_prpvf':1 [fmt:AYUV32/720x576 field:none]"
Please add (after above line):
# Configure "ipu1_ic_prpvf capture" interface (assumed at /dev/video1)
v4l2-ctl -d1 --set-fmt-video=fie
On 10/14/19 6:54 AM, Fabio Estevam wrote:
In the i.MX6Q sabreauto pipeline example, it is better to provide
a real example for the output format, so do it just like in the
previous lines for consistency.
Signed-off-by: Fabio Estevam
Acke-by: Steve Longerbeam
---
Changes since v1
.
Signed-off-by: Fabio Estevam
Acked-by: Steve Longerbeam
---
Changes since v1:
- New patch
Documentation/media/v4l-drivers/imx.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/media/v4l-drivers/imx.rst
b/Documentation/media/v4l-drivers/imx.rst
index
On 10/12/19 1:14 PM, Steve Longerbeam wrote:
Hi Fabio,
On 10/10/19 8:44 AM, Fabio Estevam wrote:
In kernel 5.3.x the I2C bus that the adv7180 is under has changed from
bus 3 to 4 and the ipu_csi0_mux numbers has also changed as shown by
the kernel log below:
[ 5.159423] imx-media
I'd be curious
in learning how you came about that pad number.
Also, in the last line pass the fmt field explicitly as done in the
previous lines.
Thanks for catching that, it was left over from a pipeline configuration
script of mine.
Steve
Signed-off-by: Fabio Estevam
---
Doc
between i.mx53 and i.mx6, at least according to the reference manuals,
so the non-standard V-bit position set by adv7180, and adjusted for by
the CSI, should work for i.mx53 just like it does for i.mx6. But it's
possible there are some undocumented differences in the CSI between
these SoC
On 10/8/19 10:20 AM, Ian Arkver wrote:
On 08/10/2019 18:14, Steve Longerbeam wrote:
On 10/8/19 9:55 AM, Tim Harvey wrote:
On Tue, Oct 8, 2019 at 4:21 AM Fabio Estevam
wrote:
On Mon, Oct 7, 2019 at 10:07 PM Fabio Estevam
wrote:
So now I need to see if I can get Gstreamer to accept a
he video looks like a broken old TV scrolling the image horizontally:
https://www.dropbox.com/s/2yef8egn6s8z7ff/mx53_adv7180_capture.mp4?dl=0
This would be because of the initial corrupt frames that this and many
other decoders produce while waiting for proper sync. I
On 10/7/19 5:46 PM, Fabio Estevam wrote:
Hi Steve,
On Mon, Oct 7, 2019 at 9:37 PM Steve Longerbeam wrote:
The adv7180 driver in 5.3.x doesn't support seq-bt, only alternate. So
pad format should be "[fmt:UYVY2X8/720x240 field:alternate]".
Thanks for the suggestion. Af
Hi Fabio,
On 10/7/19 5:15 PM, Fabio Estevam wrote:
Hi Steve,
Are you still able to capture from the camera on the imx53-smd board
with kernel 5.3.x?
I haven't tried the SMD board in a while, it's possible something broke,
but see below...
I have a custom board with a ADV7180 a
Hi Sakari, Hans, etc.
Can you take a look at this series at some point? I think there's some
good stuff in here.
Thanks,
Steve
On 8/5/19 4:34 PM, Steve Longerbeam wrote:
This series moves media link creation into the notifier bound callbacks
in the subdevices required by imx.
B
istory:
v2:
- Add missing local var ic_priv in prp_registered() in first patch.
Steve Longerbeam (2):
media: imx: Move capture device init to registered
media: imx: Move pads init to probe
drivers/staging/media/imx/imx-ic-prp.c| 25 -
drivers/staging/media/imx/imx-ic-prpencv
attempt to register a stale video capture
device resulting in the kobject "tried to init an initialized object"
backtrace.
- pad graph objects are added to the media device pad list twice, resulting
in list corruption on the pad list.
The following two patches fix those issu
Hi Philipp,
If you haven't already, can you please test rotation with this version,
with both non-tiled and tiled scaling conversions. I found rotation was
broken in v8.
Steve
On 8/14/19 5:24 AM, Philipp Zabel wrote:
Add a single imx-media mem2mem video device that uses the IPU
On 8/14/19 12:16 AM, Sakari Ailus wrote:
Hi Steve,
On Tue, Aug 13, 2019 at 04:27:06PM -0700, Steve Longerbeam wrote:
Hi Sakari,
On 8/13/19 1:28 AM, Sakari Ailus wrote:
Hi Steve,
On Thu, Aug 08, 2019 at 11:02:29AM -0700, Steve Longerbeam wrote:
On 8/8/19 1:53 AM, Philipp Zabel wrote:
Hi
Hi Sakari,
On 8/13/19 1:28 AM, Sakari Ailus wrote:
Hi Steve,
On Thu, Aug 08, 2019 at 11:02:29AM -0700, Steve Longerbeam wrote:
On 8/8/19 1:53 AM, Philipp Zabel wrote:
Hi Sakari,
On Thu, 2019-08-08 at 11:26 +0300, Sakari Ailus wrote:
[...]
Have you checked how it works if you simply leave
On 8/8/19 11:02 AM, Steve Longerbeam wrote:
On 8/8/19 1:53 AM, Philipp Zabel wrote:
Hi Sakari,
On Thu, 2019-08-08 at 11:26 +0300, Sakari Ailus wrote:
[...]
Have you checked how it works if you simply leave out this test?
Whether this works or not depends on the sensor used, and for some
ore, so these timing issues are likely to be an issue on other SoC's
that use this core. The CSI-2 chapter in the imx6 reference manual is
lifted/hacked-up from designware docs. It would be a good idea to get
the full documentation on the Synopsys DesignWare MIPI CSI-2 Host and
Devi
Implement a notifier bound op to register media links from the remote
sub-device's source pad(s) to the CSI sink pad.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-media-csi.c | 24 +++
1 file changed, 24 insertions(+)
diff --git a/drivers/staging/
nly needs to verify that the media
graph is unchanged, no stream testing is required. If the media graph
is broken, it means the subdevice(s) that bind to the drivers listed
above need to implement the .get_fwnode_pad op.
Steve Longerbeam (22):
media: entity: Pass entity to get_fwnode_pad o
Thanks Fabio,
Reviewed-by: Steve Longerbeam
On 6/27/19 3:29 PM, Fabio Estevam wrote:
From: Ezequiel Garcia
Not all sensors will be able to guarantee a proper initial state.
This may be either because the driver is not properly written,
or (probably unlikely) because the hardware won&#
that the sensor driver needs to be fixed. (Phillip)
- Keep printing the phy_state information (Phillip)
- Do not change csi2_dphy_wait_clock_lane() (Phillip/Steve)
drivers/staging/media/imx/imx6-mipi-csi2.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/st
ster output though, if only as
dev_dbg(). It contains useful output for debugging, for example if only
some of the lanes are in stop state, which could indicate an issue with
connections or lane configuration.
Agreed!
Steve
Hi Fabio,
On 6/26/19 4:22 PM, Fabio Estevam wrote:
Hi Steve,
On Wed, Jun 26, 2019 at 6:19 PM Steve Longerbeam wrote:
Did you only get the LP-11 timeout warning message with this patch on
the OV5645, or both the LP-11 timeout and clock lane timeout warnings?
With this patch applied I get
lane timeout warnings?
As I said it's OK to relax the LP-11 timeout to be warning only, but
clock lane timeout should remain an error, since without an active clock
on the clock lane it's guaranteed that no data will be received from the
sensor.
Steve
Tested-by: Fabio Estevam
th other CSI-2 receivers whose internal state
machine require starting in the LP-11 state.
Agreed, if it's possible the sensor driver should be fixed to enter
LP-11 at power on.
Steve
Which sensor are you using ?
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/imx/imx
Thanks, there was earlier talk of relaxing those CSI-2 bus startup
requirements, but somehow it fell through the cracks.
Acked-by: Steve Longerbeam
On 6/25/19 1:39 PM, Ezequiel Garcia wrote:
Not all sensors will be able to guarantee a proper initial state.
This may be either because the
:
g...@github.com:slongerbeam/mediatree.git, branch imx/mem2mem.v8.
Btw, some bugs have been found and fixed in ipu-image-convert.c. I will
be posting a patch-set shortly. You can review branch imx/bgthree-2136
in my fork for the changes.
Steve
On 4/18/19 9:44 AM, Philipp Zabel wrote:
Add a single imx-
if inf == outf, the identity matrix can be used. Reported
by Tim Harvey.
- move ic_route check above default colorimetry checks, and fill default
colorspace for ic_route, otherwise it's not possible to set BT.709
encoding for ic routes.
Steve Longerbeam (5):
gpu: ipu-v3: ipu-ic: Fix s
ot;gpu: ipu-v3: ipu-ic: allow to manually set resize
coefficients")
d2a34232580a ("gpu: ipu-v3: add driver for Prefetch Resolve Engine")
d32d98642de6 ("[media] Driver for Toshiba TC358743 HDMI to CSI-2 bridge")
dd65d2a93b0c ("gpu: ipu-v3: image-convert: prepare for per-tile
configuration")
e130291212df ("[media] media: Add i.MX media core driver")
ea9c260514c1 ("gpu: ipu-v3: add driver for Prefetch Resolve Gasket")
f0d9c8924e2c ("[media] media: imx: Add IC subdev drivers")
f5dde49b8f36 ("[media] adv7180: Prepare for multi-chip support")
How should we proceed with this patch?
It will be too difficult to backport this patch to stable trees, so the
Fixes: tag should just be removed. I will resubmit this series without it.
Steve
e upstream/downstream search
functions, which no longer require the media device.
- Add a patch to remove getting media device from v4l2_dev driver data.
Steve Longerbeam (9):
Revert "media: staging/imx: add media device to capture register"
media: staging/imx: Switch to sync
On 5/10/19 9:43 AM, Steve Longerbeam wrote:
On 5/10/19 4:18 AM, Hans Verkuil wrote:
On 5/6/19 11:16 PM, Rui Miguel Silva wrote:
Hi Steve,
On Fri 03 May 2019 at 23:43, Steve Longerbeam wrote:
Switch to sync registration for the IPU internal sub-devices,
re-organize
modules, and a few
On 5/10/19 4:18 AM, Hans Verkuil wrote:
On 5/6/19 11:16 PM, Rui Miguel Silva wrote:
Hi Steve,
On Fri 03 May 2019 at 23:43, Steve Longerbeam wrote:
Switch to sync registration for the IPU internal sub-devices, re-organize
modules, and a few other miscellaneous cleanups.
Thanks for the
getting media device from v4l2_dev driver data.
Steve Longerbeam (8):
media: staging/imx: Switch to sync registration for IPU subdevs
media: staging/imx: Pass device to alloc/free_dma_buf
media: staging/imx: Move add_video_device into capture_device_register
Revert "media: imx: Set ca
searches for video devices.
- Remove imxmd pointer arg from all of the functions above, it was
never used in those functions. With that change the i.MX5/6 CSI,
VDIC, and IC sub-devices no longer require the media_device.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-ic
ormat with the source before streaming starts.
Signed-off-by: Steve Longerbeam
---
Changes in v4:
- add **cc arg to __capture_try_fmt_vid_cap() to validate colorspace,
instead of calling ipu_pixelformat_to_colorspace().
- add error message if capture format validation failed.
---
drivers/staging
pipeline upstream/downstream search
functions, which no longer require the media device.
- Add a patch to remove getting media device from v4l2_dev driver data.
Steve Longerbeam (8):
media: staging/imx: Switch to sync registration for IPU subdevs
media: staging/imx: Pass device to alloc
media device from v4l2_dev driver data.
Steve Longerbeam (8):
media: staging/imx: Switch to sync registration for IPU subdevs
media: staging/imx: Pass device to alloc/free_dma_buf
media: staging/imx: Move add_video_device into capture_device_register
Revert "media: imx: Set capture co
Hi Rui,
On second thought, there is no reason to pass the media device to
imx_media_capture_device_register(), because it is already available via
v4l2_dev->mdev. I will be posting a patch in v2 of the "Switch to sync
registration for IPU subdevs" series that fixes this.
Steve
Switch to sync registration for the IPU internal sub-devices, re-organize
modules, and a few other miscellaneous cleanups.
Steve Longerbeam (6):
media: staging/imx: Switch to sync registration for IPU subdevs
media: staging/imx: Pass device to alloc/free_dma_buf
media: staging/imx: Move
Acked-by: Steve Longerbeam
On 4/12/19 9:44 AM, Rui Miguel Silva wrote:
When register the capture media device it is assumed that the device
data is the media device. In the imx6 case is but in the imx7 is not
case. The device data is the csi structure.
Add the explicit argument of the media
sible to set BT.709
encoding for ic routes.
Steve Longerbeam (5):
gpu: ipu-v3: ipu-ic: Fix saturation bit offset in TPMEM
gpu: ipu-v3: ipu-ic: Fully describe colorspace conversions
gpu: ipu-v3: ipu-ic-csc: Add support for limited range encoding
gpu: ipu-v3: ipu-ic-csc: Add support for
On 3/8/19 3:57 AM, Philipp Zabel wrote:
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
Add support for the following conversions:
- YUV full-range to YUV limited-range
- YUV limited-range to YUV full-range
- YUV limited-range to RGB full-range
- RGB full-range to YUV limited
On 3/8/19 3:46 AM, Philipp Zabel wrote:
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
Only providing the input and output RGB/YUV space to the IC task init
functions is not sufficient. To fully characterize a colorspace
conversion, the colorspace (chromaticities), Y'
On 3/8/19 2:23 AM, Philipp Zabel wrote:
Hi Steve,
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
The ycbcr2rgb and inverse rgb2ycbcr tables define the BT.601 Y'CbCr
encoding coefficients.
The rgb2ycbcr table specifically describes the BT.601 encoding from
full range RGB to
Add support for Rec.709 encoding and inverse encoding.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v5:
- moved API changes to a previous patch.
- moved CSC coeff calc to new function calc_csc_coeffs().
Changes in v4:
- fix compile error.
Chnges in v3:
- none.
Changes
RGB limited-range coefficients.
[M_b, O_b] = YUV limited-range to YUV full-range coefficients.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 281 +---
1 file changed, 263 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b
sink and source
pad try_fmt's. The unrelated check for uninitialized field value is
moved out to appropriate places in each subdev try_fmt.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-ic-prp.c | 6 +-
drivers/staging/media/imx/imx-ic-prpencvf.c | 8 +--
drivers/st
ult colorimetry checks, and fill default
colorspace for ic_route, otherwise it's not possible to set BT.709
encoding for ic routes.
Steve Longerbeam (7):
gpu: ipu-v3: ipu-ic: Fix saturation bit offset in TPMEM
gpu: ipu-v3: ipu-ic: Fix BT.601 coefficients
gpu: ipu-v3: ipu-ic: Fully
Converter unit")
Suggested-by: Philipp Zabel
Signed-off-by: Steve Longerbeam
Cc: sta...@vger.kernel.org
---
drivers/gpu/ipu-v3/ipu-ic.c | 61 ++---
1 file changed, 37 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3
The saturation bit was being set at bit 9 in the second 32-bit word
of the TPMEM CSC. This isn't correct, the saturation bit is bit 42,
which is bit 10 of the second word.
Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter unit")
Signed-off-by: Steve Longerbeam
Cc: sta...@
eters are moved to a new function calc_csc_coeffs(),
called by init_csc().
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 136 +---
drivers/gpu/ipu-v3/ipu-image-convert.c | 27 ++--
drivers/staging/media/imx/imx-ic-prpencvf.c | 22 +++-
in
The IC now supports BT.709 Y'CbCr encoding, in addition to existing BT.601
encoding, so allow both, for pipelines that route through the IC.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v5:
- rebased this patch on top of repurposing the functi
The i.MX7 capture support forgot to change the group ID for the CSI
to the IPU CSI in VDIC sub-device, it was left at the i.MX7 CSI
group ID.
Fixes: 67673ed55084 ("media: staging/imx: rearrange group id to take in account
IPU")
Signed-off-by: Steve Longerbeam
---
drivers/staging/med
* TODO: implement VDIC frame skipping
-*/
- fi->interval = *input_fi;
- if (priv->csi_direct)
- fi->interval.denominator *= 2;
+ priv->skip = vdic_find_best_skip(output_fi, &fi->interval);
("media: staging/imx: get CSI bus type from nearest
upstream entity")
Signed-off-by: Steve Longerbeam
Cc: sta...@vger.kernel.org
---
drivers/staging/media/imx/imx-media-csi.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/med
connects
directly to ipu1_csi0 and has a single source port with no "reg"
property.
Fixes: 621b08eabcddb ("media: staging/imx: remove static media link arrays")
Signed-off-by: Steve Longerbeam
Cc: sta...@vger.kernel.org
---
drivers/staging/media/imx/imx-media-of.c | 15 +--
For the functions that add and remove the internal IPU subdevice
descriptors, rename them to make clear they are the subdevs internal
to the IPU. Also rename the platform data structure for the internal
IPU subdevices. No functional changes.
Signed-off-by: Steve Longerbeam
Acked-by: Philipp
The second IPU internal sub-devices were being registered and links
to them created even when the second IPU is not present. This is wrong
for i.MX6 S/DL and i.MX53 which have only a single IPU.
Fixes: e130291212df5 ("[media] media: Add i.MX media core driver")
Signed-off-by: Steve
Some fixes and improvements to support video capture on i.MX5.
History:
v2:
- Rebased with merge of imx7 capture patches.
Steve Longerbeam (4):
media: imx: csi: Allow unknown nearest upstream entities
media: imx: Clear fwnode link struct for each endpoint iteration
media: imx: Rename
nitialized symbol 'curr_phys'.
drivers/staging/media/imx/imx-media-vdic.c:238 prepare_vdi_in_buffers() error:
uninitialized symbol 'next_phys'.
Fixes: 6e537b58de772 ("media: imx: vdic: rely on VDIC for correct field order")
Reported-by: Hans Verkuil
Signed-off-by: Stev
RGB limited-range coefficients.
[M_b, O_b] = YUV limited-range to YUV full-range coefficients.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 281 +---
1 file changed, 263 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b
sink and source
pad try_fmt's. The unrelated check for uninitialized field value is
moved out to appropriate places in each subdev try_fmt.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-ic-prp.c | 6 +-
drivers/staging/media/imx/imx-ic-prpencvf.c | 8 +--
drivers/st
The IC now supports BT.709 Y'CbCr encoding, in addition to existing BT.601
encoding, so allow both, for pipelines that route through the IC.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v5:
- rebased this patch on top of repurposing the functi
The saturation bit was being set at bit 9 in the second 32-bit word
of the TPMEM CSC. This isn't correct, the saturation bit is bit 42,
which is bit 10 of the second word.
Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter unit")
Signed-off-by: Steve Longerbeam
Cc: sta...@
Add support for Rec.709 encoding and inverse encoding.
The determination of the CSC coefficients based on the input/output
colorspace parameters are moved to a new function calc_csc_coeffs().
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v5:
- moved API changes to a
Converter unit")
Suggested-by: Philipp Zabel
Signed-off-by: Steve Longerbeam
Cc: sta...@vger.kernel.org
---
drivers/gpu/ipu-v3/ipu-ic.c | 63 ++---
1 file changed, 38 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3
nge.
- can only encode using BT.601 standard (follow-up patch will add
Rec.709 encoding support).
- cannot convert colorspaces from input to output, the
input and output colorspace chromaticities must be the same.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c
since if inf == outf, the identity matrix can be used. Reported
by Tim Harvey.
- move ic_route check above default colorimetry checks, and fill default
colorspace for ic_route, otherwise it's not possible to set BT.709
encoding for ic routes.
Steve Longerbeam (7):
gpu: ipu-v3: ipu-ic
Hi Hans, pardon the delay, I will post a patch for this tomorrow.
Steve
On 2/16/19 1:27 AM, Hans Verkuil wrote:
On 2/7/19 3:33 PM, Hans Verkuil wrote:
Hi Steve,
It turns out that the daily build never compiled the staging media drivers,
which included imx. Now that I enabled it I get these
On 2/13/19 2:35 AM, Philipp Zabel wrote:
On Tue, 2019-02-12 at 09:42 -0800, Steve Longerbeam wrote:
[...]
But what about this "SAT_MODE" field in the IC task parameter memory?
That just controls the saturation. The result after the matrix
multiplication is either saturated to [0..
On 2/12/19 3:34 AM, Philipp Zabel wrote:
Hi Steve,
On Mon, 2019-02-11 at 17:20 -0800, Steve Longerbeam wrote:
[...]
Should we support YUV BT.601 <-> YUV REC.709 conversions? That would
require separate encodings for input and output.
How about if we pass the input and output encodi
On 2/12/19 2:17 AM, Philipp Zabel wrote:
Hi Steve,
On Mon, 2019-02-11 at 10:24 -0800, Steve Longerbeam wrote:
[...]
Looking more closely at these coefficients now, I see you are right,
they are the BT.601 YUV full-range coefficients (Y range 0 to 1, U and V
range -0.5 to 0.5). Well, not
On 2/11/19 2:12 AM, Philipp Zabel wrote:
On Fri, 2019-02-08 at 17:47 -0800, Steve Longerbeam wrote:
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
On 2/11/19 1:58 AM, Philipp Zabel wrote:
On Fri, 2019-02-08 at 17:47 -0800, Steve Longerbeam wrote:
The ycbcr2rgb and inverse rgb2ycbcr matrices define the BT.601 encoding
coefficients, so rename them to indicate that. And add some comments
to make clear these are BT.601 coefficients
Hi Philipp,
On 2/11/19 1:58 AM, Philipp Zabel wrote:
On Fri, 2019-02-08 at 17:47 -0800, Steve Longerbeam wrote:
The ycbcr2rgb and inverse rgb2ycbcr matrices define the BT.601 encoding
coefficients, so rename them to indicate that. And add some comments
to make clear these are BT.601
Simplify the selection of the Y'CbCr encoding matrices in init_csc().
A side-effect of this change is that init_csc() now allows YUV->YUV
using the identity matrix, intead of returning error.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 12
1 file ch
The IC now supports BT.709 Y'CbCr encoding, in addition to existing BT.601
encoding, so allow both, for pipelines that route through the IC.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- move ic_route check above default colorimetry checks, and fill de
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v4:
- fix compile error.
Chnges in v3:
- none.
Changes in v2:
- only return "Unsupported
ult colorimetry checks, and fill default
colorspace for ic_route, otherwise it's not possible to set BT.709
encoding for ic routes.
Steve Longerbeam (4):
gpu: ipu-v3: ipu-ic: Rename yuv2rgb encoding matrices
gpu: ipu-v3: ipu-ic: Simplify selection of encoding matrix
gpu: ipu-v3: ipu-ic: Ad
rename to ic_csc_identity. No functional changes.
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- rename ic_csc_rgb2rgb matrix to ic_csc_identity.
---
drivers/gpu/ipu-v3/ipu-ic.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu
On 2/8/19 4:20 PM, Tim Harvey wrote:
On Fri, Feb 8, 2019 at 11:28 AM Steve Longerbeam wrote:
if (inf == outf)
params = &ic_csc_identity;
else if (inf == IPUV3_COLORSPACE_YUV)
- params = &ic_csc_ycbcr2rgb_bt601;
+
On 2/8/19 1:23 PM, Tim Harvey wrote:
On Thu, Feb 7, 2019 at 5:54 PM Steve Longerbeam wrote:
Ok there is definitely something wrong when using the IC with
UYVY8_1X16 (passthrough) which works with UYVY8_2X8. It looks to me
like the ipu1_ic_prp isn't negotiating its format properly
Simplify the selection of the Y'CbCr encoding matrices in init_csc().
A side-effect of this change is that init_csc() now allows YUV->YUV
using the identity matrix, intead of returning error.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 12
1 file ch
rename to ic_csc_identity. No functional changes.
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- rename ic_csc_rgb2rgb matrix to ic_csc_identity.
---
drivers/gpu/ipu-v3/ipu-ic.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- only return "Unsupported YCbCr encoding" error if inf != outf,
since if i
The IC now supports BT.709 Y'CbCr encoding, in addition to existing BT.601
encoding, so allow both, for pipelines that route through the IC.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- move ic_route check above default colorimetry checks, and fill de
erwise it's not possible to set BT.709
encoding for ic routes.
Steve Longerbeam (4):
gpu: ipu-v3: ipu-ic: Rename yuv2rgb encoding matrices
gpu: ipu-v3: ipu-ic: Simplify selection of encoding matrix
gpu: ipu-v3: ipu-ic: Add support for BT.709 encoding
media: imx: Allow BT.709 en
Simplify the selection of the Y'CbCr encoding matrices in init_csc().
A side-effect of this change is that init_csc() now allows YUV->YUV
using the identity matrix, intead of returning error.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 12
1 file ch
oding" error if inf != outf,
since if inf == outf, the identity matrix can be used. Reported
by Tim Harvey.
- move ic_route check above default colorimetry checks, and fill default
colorimetry for ic_route, otherwise it's not possible to set BT.709
encoding for ic routes.
Steve Longer
From: Steve Longerbeam
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- only return "Unsupported YCbCr encoding" error if i
From: Steve Longerbeam
The IC now supports BT.709 Y'CbCr encoding, in addition to existing BT.601
encoding, so allow both, for pipelines that route through the IC.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- move ic_route check above default colorimetry c
From: Steve Longerbeam
The ycbcr2rgb and inverse rgb2ycbcr matrices define the BT.601 encoding
coefficients, so rename them to indicate that. And add some comments
to make clear these are BT.601 coefficients encoding between YUV limited
range and RGB full range. The ic_csc_rgb2rgb matrix is just
On 2/8/19 8:24 AM, Tim Harvey wrote:
On Sun, Feb 3, 2019 at 11:48 AM Steve Longerbeam wrote:
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
1 - 100 of 1299 matches
Mail list logo
