or this driver. */
> #define V4L2_CID_USER_IMX_BASE (V4L2_CID_USER_BASE +
> 0x10b0)
>
> +/* The base for the mediatek FD driver controls */
> +/* We reserve 16 controls for this driver. */
> +#define V4L2_CID_USER_MTK_FD_BASE(V4L2_CID_USER_BASE + 0x10d0)
Why only the base, but not the actual IDs in uapi ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
a piece of glue code for triggering device probing
on that bus. (so, it really needs to provide a full blown i2c driver ?)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
On 08.07.19 13:08, Marc Gonzalez wrote:
> The tuner (si2157) is not on the i2c5 bus, instead it is on a private
> i2c bus *behind* si2168, which routes requests to the proper client.
Should the si2168 make up it's own i2c controller ?
--mtx
--
Enrico Weigelt, metux IT consult
Fr
Am 08.06.2015 um 12:04 schrieb Hans Verkuil:
Just curious: as we're talking about userland libraries,
why not just using gstreamer ?
--mtx
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA
21333 B
Wich
s all old stuff and has developed quite a lot since then. We'll
post new series here on the lists when they are ready for mainline.
Great :)
Do you have them on some public repo, so I can give 'em a try ?
--mtx
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik
k to ipu and vpu ?
>
> Not that I am aware of.
Well, you perhaps can imagine - I dont trust these guys ...
--mtx
ps: greetings from Bene ... you won't guess where I met him
last weekend ;-)
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Re
ow moved to Phillip's recent ipuv3 patches, but still
have lots of others (about 30) for my tqma53-based board, which might
be generic enough for going into mainline someday (many of them by
ptx folks).
Should I post them to lkml or somewhere else ?
cu
--
Enrico Weigelt, metux
7;s now several weeks ago (IIRC, on rc1) - I'm currently rebasing
everything again to the recent master.
cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA
21333 B
Wichtiger Hinweis: Diese Nachricht kann vertraulich
y driver
(or the gpus itself) might talk to ipu and vpu ?
cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA
21333 B
Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen
begrenzten Personenkreis be
I'd prefer some pure filesystem-based approach - like @Plan9 or
sysfs.
cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA
21333 B
Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen
begrenzte
ion:
when using it w/ gst for video playback, can be directly pass buffers
between VPU, IPU and FB (or let them directly write into shared
buffers), so CPU doesn't need to act on each frame for each step
in the decoding pipeline ?
Playing an 800x400 mp4 still produces about 70..75%.
cu
--
Enrico
Hi folks,
I've rebased the IPUv3 patches from ptx folks onto 4.0.4,
working good for me. (now gst plays h264 @25fps on imx53)
https://github.com/metux/linux/commits/submit-4.0-imx53-ipuv3
(Haven't 4.1rc* yet, as it broke some other things for me.)
cu
--
Enrico Weigelt, metux
each other ? Is it possible to directly exchange
buffers between GPUs, VPUs, IPUs, FBs, etc ?
cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA
21333 B
Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder
13 matches
Mail list logo