Eddie: ping!
Regards,
Hans
On 6/6/19 2:53 AM, Jae Hyun Yoo wrote:
> Hi Eddie,
>
> All patches in this series were queued to linux/media tree except this
> one. Can you please review this patch?
>
> Thanks,
> Jae
>
> On 5/31/2019 3:15 PM, Jae Hyun Yoo wrote:
>> AST2500 silicon revision
Florian: ping!
Regards,
Hans
On 6/4/19 2:36 PM, Hans Verkuil wrote:
> Instead of filling in the struct v4l2_capability device_caps
> field, fill in the struct video_device device_caps field.
>
> That way the V4L2 core knows what the capabilities of the
> video device are.
>
> But this
On Tue, Jun 11, 2019 at 04:09:55PM +0100, Rui Miguel Silva wrote:
> When the upstream endpoint is neither a mux nor a CSI2 module, just get
> the source pad directly upstream from the CSI.
>
> Fixes: 05f634040c0d ("media: staging/imx7: add imx7 CSI subdev driver")
> Reported-by: Sebastien Szymansk
On 6/11/19 2:50 PM, Philipp Zabel wrote:
> There are several other SoCs that contain Hantro IP based VPUs, such as
> NXP i.MX8MQ (Hantro G1 and G2) and i.MX8MM (Hantro G1, G2, and H1). To
> maximize code sharing, add initial support for these SoCs to the
> Rockchip VPU driver, after renaming it to
On 6/12/19 9:55 AM, Hans Verkuil wrote:
> On 6/11/19 2:50 PM, Philipp Zabel wrote:
>> There are several other SoCs that contain Hantro IP based VPUs, such as
>> NXP i.MX8MQ (Hantro G1 and G2) and i.MX8MM (Hantro G1, G2, and H1). To
>> maximize code sharing, add initial support for these SoCs to the
On 2019-06-11 14:50, Philipp Zabel wrote:
> Rename the driver and all relevant identifiers from Rockchip to Hantro,
> as other Hantro IP based VPU implementations can be supported by the
> same driver.
> The RK3288 decoder is Hantro G1 based, the encoder is Hantro H1.
The RK3288 has two VPU blocks
Hi Nicolas,
On Tue, Jun 11, 2019 at 08:09:13PM -0400, Nicolas Dufresne wrote:
> Le mardi 11 juin 2019 à 13:24 +0300, Laurent Pinchart a écrit :
> > On Fri, Jun 07, 2019 at 03:38:39PM -0400, Nicolas Dufresne wrote:
> >> Le vendredi 07 juin 2019 à 16:58 +0300, Laurent Pinchart a écrit :
> >>> On Fri
On Wed, 12 Jun 2019 08:14:35 +
Jonas Karlman wrote:
> On 2019-06-11 14:50, Philipp Zabel wrote:
> > Rename the driver and all relevant identifiers from Rockchip to Hantro,
> > as other Hantro IP based VPU implementations can be supported by the
> > same driver.
> > The RK3288 decoder is Hantr
On Wed, 12 Jun 2019 10:00:45 +0200
Hans Verkuil wrote:
> On 6/12/19 9:55 AM, Hans Verkuil wrote:
> > On 6/11/19 2:50 PM, Philipp Zabel wrote:
> >> There are several other SoCs that contain Hantro IP based VPUs, such as
> >> NXP i.MX8MQ (Hantro G1 and G2) and i.MX8MM (Hantro G1, G2, and H1). To
Sorry, didn't realize you'd also need my feedback. No complaints.
Acked-by: Florian Echtler
Best, Florian
On 04.06.19 18:06, Dmitry Torokhov wrote:
> Hi Hans,
>
> On Tue, Jun 04, 2019 at 02:36:27PM +0200, Hans Verkuil wrote:
>> Instead of filling in the struct v4l2_capability device_caps
>> fi
There are several other SoCs that contain Hantro IP based VPUs, such as
NXP i.MX8MQ (Hantro G1 and G2) and i.MX8MM (Hantro G1, G2, and H1). To
maximize code sharing, add initial support for these SoCs to the
Rockchip VPU driver, after renaming it to Hantro VPU.
This series is based on the br-v5.3g
Add devicetree binding documentation for the Hantro G1/G2 VPU on i.MX8MQ
and for the Hantro G1/G2/H1 VPU on i.MX8MM.
Signed-off-by: Philipp Zabel
---
.../devicetree/bindings/media/imx8m-vpu.txt | 56 +++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicet
This should enable MPEG-2 decoding on the Hantro G1 and JPEG encoding on
the Hantro H1 on i.MX8MM.
Signed-off-by: Philipp Zabel
---
drivers/staging/media/hantro/hantro_drv.c | 1 +
drivers/staging/media/hantro/hantro_hw.h| 1 +
drivers/staging/media/hantro/imx8m_vpu_hw.c | 139
It can be helpful to know which video device was registered at which
device node.
Signed-off-by: Philipp Zabel
Reviewed-by: Boris Brezillon
---
drivers/staging/media/hantro/hantro_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/hantro/hantro_drv
On i.MX8MQ/MM a separate control block contains registers for per-core
resets, clock gating, and fuse register control.
Signed-off-by: Philipp Zabel
Reviewed-by: Boris Brezillon
---
drivers/staging/media/hantro/hantro.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/media
The i.MX8MQ bindings will use different IRQ names ("g1" instead of
"vdpu", and "g2"), so make them configurable. This also allows to
register more than two IRQs, which will be required for i.MX8MM support
later (it will add "h1" instead of "vepu").
Signed-off-by: Philipp Zabel
Reviewed-by: Boris
It seems that on i.MX8MQ the power domain controller does not propagate
resets to the VPU cores on resume. Add a callback to allow implementing
manual reset of the VPU cores after ungating the power domain.
Signed-off-by: Philipp Zabel
Reviewed-by: Boris Brezillon
---
drivers/staging/media/hant
Dynamically allocate clocks and move clock names out of struct
hantro_variant. This lifts the four clock limit and allows to use
ARRAY_SIZE() to fill .num_clocks to reduce the risk of mismatches.
Signed-off-by: Philipp Zabel
Reviewed-by: Boris Brezillon
---
Changes since v4 [1]:
- Rebased onto
Add support for multiple register ranges with SoC specific names.
Signed-off-by: Philipp Zabel
Reviewed-by: Boris Brezillon
---
drivers/staging/media/hantro/hantro.h | 8 ++--
drivers/staging/media/hantro/hantro_drv.c | 24 +--
2 files changed, 24 insertions(+), 8 d
For now this just enables MPEG-2 decoding on the Hantro G1 on i.MX8MQ.
Signed-off-by: Philipp Zabel
--
Changes since v4 [1]:
- Fix duplicated num_irqs initializer
[1] https://patchwork.linuxtv.org/patch/56802/
---
drivers/staging/media/hantro/Kconfig| 16 +-
drivers/staging/media/hant
From: Jonas Karlman
Add necessary bits to support MPEG2 decoding on RK3328.
Signed-off-by: Jonas Karlman
Signed-off-by: Ezequiel Garcia
Signed-off-by: Philipp Zabel
---
Changes since v6 [1]:
- Rebased onto Hantro rename series [2]
[1] https://patchwork.linuxtv.org/patch/56402/
[2] https://pa
On Wed, 2019-06-12 at 10:00 +0200, Hans Verkuil wrote:
> On 6/12/19 9:55 AM, Hans Verkuil wrote:
> > On 6/11/19 2:50 PM, Philipp Zabel wrote:
> > > There are several other SoCs that contain Hantro IP based VPUs, such as
> > > NXP i.MX8MQ (Hantro G1 and G2) and i.MX8MM (Hantro G1, G2, and H1). To
>
When the upstream endpoint is neither a mux nor a CSI2 module, just get
the source pad directly upstream from the CSI.
Fixes: 05f634040c0d ("media: staging/imx7: add imx7 CSI subdev driver")
Reported-by: Sebastien Szymanski
Signed-off-by: Rui Miguel Silva
---
v1->v2:
Dan Carpenter:
- s/in/is/
This PR contains patches 1-7 of this series:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg147710.html
Patch 8 is still waiting for an Acked-by so I postpone that and the
following patches for a future PR.
Let's do the rename now to get that out of the way.
Regards,
Hans
On 6/6/19 6:12 PM, Ezequiel Garcia wrote:
> Rework std_init adding an explicit initialization for
> compound controls.
>
> While here, make sure the control is initialized to zero,
> before providing default values for all its fields.
>
> Signed-off-by: Ezequiel Garcia
> ---
> Changes from v2:
>
On 6/8/19 4:03 PM, W. Talsma wrote:
Dear,
Today decided to dust off my Anysee E30 S2 Plus, and hope to get it to work
with the Debian stretch tvheadend server.
Once I plug it in however, I see the following:
[27054.699829] usb 1-1.6: new high-speed USB device number 7 using ehci-pci
[27055.2
pgd = f25837f9
[] *pgd=bd93d835
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
Modules linked in: btmrvl_sdio btmrvl bluetooth mwifiex_sdio mwifiex
ecdh_generic ecc
CPU: 0 PID: 1430 Comm: v4l2_decode Not tainted
5.2.0-rc4-next-20190612-6-gf077fba72e95-dirty #6167
Hardware name: SAMS
Dear all,
When using kernel 4.19.X and sending IR commands with LIRC,
the number of pulse-spaces of IR sequence is restricted to be smaller than 256.
In kernel 4.19, this restriction is caused by the following line in
media/rc/lirc_dev.c,
which did not exist kernel 4.14.
https://github.com/torva
The following changes since commit 4e8c120de9268fc26f583268b9d22e7d37c4595f:
media: fdp1: Support M3N and E3 platforms (2019-06-11 12:29:54 -0400)
are available in the Git repository at:
git://linuxtv.org/hverkuil/media_tree.git for-v5.3p
for you to fetch changes up to 4ca498ad26603d78d76de
Dear Takashi Kanamaru,
On Wed, Jun 12, 2019 at 11:08:34PM +0900, Takashi Kanamaru wrote:
> Dear all,
>
> When using kernel 4.19.X and sending IR commands with LIRC,
> the number of pulse-spaces of IR sequence is restricted to be smaller than
> 256.
>
> In kernel 4.19, this restriction is cause
On 6/12/19 2:17 AM, Hans Verkuil wrote:
Eddie: ping!
Regards,
Hans
On 6/6/19 2:53 AM, Jae Hyun Yoo wrote:
Hi Eddie,
All patches in this series were queued to linux/media tree except this
one. Can you please review this patch?
Thanks,
Jae
On 5/31/2019 3:15 PM, Jae Hyun Yoo wrote:
It is the default in all the si2168 drivers, but the signal is lost
somehow in this hw version of the t230c v2. The clock is 0 (null) Mhz!
So, no data *at all* without setting it manually. IMy best guess is
that it was a design flaw.
I meant it is the default value for the SI2168D. I'll g
On 6/12/2019 8:03 AM, Eddie James wrote:
On 6/12/19 2:17 AM, Hans Verkuil wrote:
Eddie: ping!
Regards,
Hans
On 6/6/19 2:53 AM, Jae Hyun Yoo wrote:
Hi Eddie,
All patches in this series were queued to linux/media tree except this
one. Can you please review this patch?
Thanks,
Jae
On 5/
On 12 Jun 2019 at 1:28, Antti Palosaari wrote:
[...]
>
> What is that T230C2 stick?
JP has already explained the details, how that name was arrived at.
As previously suggested, I can call it T230C v2 in the descriptive
texts. I'd suggest keeping T230C2 in the USB ID macro (or suggest
a more appr
Renesas media binding documentation files uses a naming schema of
'renesas,.txt'. Rename VIN and CSI-2 files to match this
pattern.
Signed-off-by: Niklas Söderlund
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Ulrich Hecht
---
.../media/{renesas,rcar-csi2.txt => renesas,csi2.txt} | 0
.
35 matches
Mail list logo
