From: Boris Brezillon <boris.brezillon@collabora.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Philipp Zabel <p.zabel@pengutronix.de>,
linux-media@vger.kernel.org,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Ezequiel Garcia <ezequiel@collabora.com>,
Nicolas Dufresne <nicolas@ndufresne.ca>,
Jonas Karlman <jonas@kwiboo.se>,
devicetree@vger.kernel.org, kernel@pengutronix.de
Subject: Re: [PATCH v4 00/10] Rename Rockchip VPU driver to Hantro, add initial i.MX8M support
Date: Wed, 12 Jun 2019 10:30:28 +0200 [thread overview]
Message-ID: <20190612103028.47b8e129@collabora.com> (raw)
In-Reply-To: <d6a0007c-72b9-f45d-2f4c-736dd1214dbd@xs4all.nl>
On Wed, 12 Jun 2019 10:00:45 +0200
Hans Verkuil <hverkuil@xs4all.nl> 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
> >> 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 tag, commit e568d2cc1ef6
> >> ("rockchip/vpu: Add support for MPEG-2 decoding on RK3288") with
> >> https://patchwork.linuxtv.org/patch/56402/ ("rockchip/vpu: Add support
> >> for MPEG-2 decoding on RK3328") applied on top. It supports MPEG-2
> >> decoding on i.MX8MQ. MPEG-2 decoding and JPEG encoding on i.MX8MM may
> >> or may not work, I don't have the hardware to test.
> >>
> >> Changes since v3:
> >> - Split rk3288_vpu_regs.h into hantro_g1_regs.h and hantro_h1_regs.h,
> >> rename VDPU register defines to G1 and VEPU register defines to H1.
> >> - Make Rockchip / i.MX8M support configurable.
> >> - Keep staging/media Kconfig in alphabetic order.
> >> - Rename bases to reg_bases
> >> - Move dynamic clocks before i.MX8M support.
> >
> > Can you please rebase this on top of the media_tree master? This series
> > doesn't apply there.
> >
> > I'd like to get this rename series in asap since keeping this out-of-tree
> > is a pain.
> >
> > It looks in good shape in general.
>
> In fact, I would like to hold off on applying any other rockchip patches
> until this is in (and that means any pending rockchip patches probably
> need rebasing).
Ack. Actually, Ezequiel and I are waiting for this series to land
before sending new patches, so that'd be nice to have at least patches
1 to 7 applied really soon.
>
> So if a v5 applies cleanly and doesn't throw up new sparse/smatch issues,
> then I'll take it.
Great!
next prev parent reply other threads:[~2019-06-12 8:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-11 12:50 [PATCH v4 00/10] Rename Rockchip VPU driver to Hantro, add initial i.MX8M support Philipp Zabel
2019-06-11 12:50 ` [PATCH v4 01/10] rockchip/vpu: rename from rockchip to hantro Philipp Zabel
2019-06-12 8:14 ` Jonas Karlman
2019-06-12 8:23 ` Boris Brezillon
2019-06-11 12:50 ` [PATCH v4 02/10] media: hantro: print video device name in addition to device node Philipp Zabel
2019-06-11 12:50 ` [PATCH v4 03/10] media: hantro: add PM runtime resume callback Philipp Zabel
2019-06-11 12:50 ` [PATCH v4 04/10] media: hantro: make irq names configurable Philipp Zabel
2019-06-11 12:50 ` [PATCH v4 05/10] media: hantro: add support for named register ranges Philipp Zabel
2019-06-11 12:50 ` [PATCH v4 06/10] media: hantro: add support for separate control block Philipp Zabel
2019-06-11 12:50 ` [PATCH v4 07/10] media: hantro: allow arbitrary number of clocks Philipp Zabel
2019-06-11 12:50 ` [PATCH v4 08/10] media: dt-bindings: Document i.MX8MQ and i.MX8MM VPU bindings Philipp Zabel
2019-06-11 12:50 ` [PATCH v4 09/10] media: hantro: add initial i.MX8MQ support Philipp Zabel
2019-06-11 12:50 ` [PATCH v4 10/10] media: hantro: add initial i.MX8MM support (untested) Philipp Zabel
2019-06-12 7:55 ` [PATCH v4 00/10] Rename Rockchip VPU driver to Hantro, add initial i.MX8M support Hans Verkuil
2019-06-12 8:00 ` Hans Verkuil
2019-06-12 8:30 ` Boris Brezillon [this message]
2019-06-12 9:46 ` Philipp Zabel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190612103028.47b8e129@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=ezequiel@collabora.com \
--cc=hverkuil@xs4all.nl \
--cc=jonas@kwiboo.se \
--cc=kernel@pengutronix.de \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=nicolas@ndufresne.ca \
--cc=p.zabel@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.