Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7163818imu; Thu, 31 Jan 2019 06:05:22 -0800 (PST) X-Google-Smtp-Source: ALg8bN4DvvgidlbpngDMoW+XatlX+htiZCFkmiZWbjBjskArsI/57XtP3sRwAKRpZ1pSpvx/Q8Cm X-Received: by 2002:a62:5003:: with SMTP id e3mr36058134pfb.23.1548943522857; Thu, 31 Jan 2019 06:05:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548943522; cv=none; d=google.com; s=arc-20160816; b=JmUgRMdYzXbhRU79m6SnCJTD6YYaFaD1FI63+LD55PNTIM7hHex3tvVk8UJ2ix30zw tj4YFOkZcLwAnlIRtqAaO4Y7ZBAdSI9qWZ43AySlwbWuUYD2Yjl+ZBQ6T/x8lpPzo3b+ LlrsmiGGKu17zdnEYq2RWxsraw9qMIeEWCOzI5G43SwlYnPZm2PDBxLhpNnwLQP3O82G +er4MRQm8a1tZHeo4XpCghmwOdt95I7cOOw8TSt2Jxv6XCzvyvIEkeE3vYVnam5Fg962 0piRPnwGNoZIw1qtJM+pqMYOcRi4qaeEuzKZ4jTT+JlQQpeaJiZbXI5MaQ7DZOeM5K1z hqqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:organization:references:in-reply-to:date:cc:to:from :subject:message-id; bh=dn7W8RLvU8oM4ji3Cpqt/oAZ4f8/v9zSYoHl9GLquVM=; b=MAZMVxlJNi7CdqiFKHhxxfG5JnsW3RMkRyLc1uWxePsmTBCrvYmIwR4DzOIwgPXKlG UhKDF2dhiB8i0olSObeuon3X7103vdKoU6+7+puB0NVGL/JNDxCtrf51zpXqnkvd4s1f bJvACjTfkgy+WM6wa3u7WaZXZse4vqDbpYXtniP2UQAHOXWYCKmN/jLVwBvHlsmY+dFv V/46LQyxIoky6XVopcXwC1JYE6WLyuDsPubnAVrk8Xb3HTUU+aNzxomjObILN7Pib8/Y cikwdtHhh2RIfrcz7ns0PGP1sSJLMWhYzcbOEjzMNr6LOkmKzod8tpxOuBOvoB2L0qQJ 96qA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s5si4328219pgl.481.2019.01.31.06.05.06; Thu, 31 Jan 2019 06:05:22 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733155AbfAaODV (ORCPT + 99 others); Thu, 31 Jan 2019 09:03:21 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:44122 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727248AbfAaODU (ORCPT ); Thu, 31 Jan 2019 09:03:20 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id 5CFD127FEAC Message-ID: Subject: Re: [PATCH 0/4] WIP: rockchip mpp for v4l2 video decoder From: Ezequiel Garcia To: ayaka , linux-media@vger.kernel.org Cc: acourbot@chromium.org, nicolas@ndufresne.ca, paul.kocialkowski@bootlin.com, jernej.skrabec@gmail.com, joro@8bytes.org, mchehab@kernel.org, maxime.ripard@bootlin.com, hverkuil@xs4all.nl, thomas.petazzoni@bootlin.com, randy.li@rock-chips.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org Date: Thu, 31 Jan 2019 11:03:06 -0300 In-Reply-To: <20190131031333.11905-1-ayaka@soulik.info> References: <20190131031333.11905-1-ayaka@soulik.info> Organization: Collabora Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey Ayaka! On Thu, 2019-01-31 at 11:13 +0800, ayaka wrote: > From: Randy 'ayaka' Li > > Hello > Those patches are based on the previous vendor driver I post before, > but it can apply without the previous one. > I really want to make it work before FOSDEM and I didn't. And upcoming > the lunar new year holiday would last two week. > > I have verified the v4l2 part but I meet a problem with power or > clock, it would be a complex problem, I would handle to solve it after I > am back. But I just tell my design on this kind dirver. > This the branch I'm about to submit: http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/vpu-mpeg-2-almost-ready-for-upstream And it has no power issues. Perhaps you can take a look inside, you might be just missing a few pm_ statements? Perhaps a devicetree thing? > A few questions I think you may ask I would like to answer it here. > I have another question: is this patchset meant to support for mpeg-2 decoding only? I can't find any other codec code. Thanks, Ezequiel > 1. Why it is based on the previous vendor driver ? > The vendor driver I post to mail list is a clean version which having a > efficient work flow and those platform dependency controls having been > merged into it. > > For the stateless device, V4L2 is just another interface for userspace > to translate it into registers. > > 2. Why use a structure to store register infomation not marco ? > I really don't want to define many marcos for a device having more than > a hundred of registers. And there are many fields in a registers. > > For the VDPU1/VDPU2 which would support more than 10 video codecs, these > two devices would re-use many registers for many codecs, It would be > hard to show the conflict relations between them in marco but more easy > with C union and structure. > > BTW, I would prefer to write a number of registers into the device > though AHB bus not just generate one then write one, you can save some > times here. > > > Besides the two previous answers. I really have a big problem with v4l2 > design. Which would driver wait the work of the previous picture is > done, leading a large gap time more idle of the device. > > I am ok the current face that v4l2 stateless driver is not stateless. > But it would limit the ability of stateless decoder. It is more flexible > to those videos having different resolution or orientation sequences. > > But I don't like the method to reconstruct the bitstream in driver, it > is a bad idea to limit what data the device want. Those problem is > mainly talking in the HEVC slice thread. And it was ironic for the VPx > serial codec, which mixed compressed data and umcompress header together > and twisted. Even for the ITU H serial codec, it would become a problem > in SVC or Google Android CTS test. > > And thanks kwiboo, ezequielg and Paulk, I copy some v4l2 code from their > code. > > Randy Li (1): > staging: video: rockchip: add video codec > > ayaka (3): > [WIP]: staging: video: rockchip: add v4l2 common > [WIP] staging: video: rockchip: vdpu2 > [TEST]: rockchip: mpp: support qtable > > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile | 1 + > drivers/staging/rockchip-mpp/Kconfig | 54 + > drivers/staging/rockchip-mpp/Makefile | 8 + > drivers/staging/rockchip-mpp/mpp_debug.h | 87 ++ > drivers/staging/rockchip-mpp/mpp_dev_common.c | 1365 +++++++++++++++++ > drivers/staging/rockchip-mpp/mpp_dev_common.h | 215 +++ > drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c | 878 +++++++++++ > drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 755 +++++++++ > drivers/staging/rockchip-mpp/mpp_service.c | 197 +++ > drivers/staging/rockchip-mpp/mpp_service.h | 38 + > drivers/staging/rockchip-mpp/rkvdec/hal.h | 53 + > drivers/staging/rockchip-mpp/rkvdec/regs.h | 395 +++++ > drivers/staging/rockchip-mpp/vdpu2/hal.h | 52 + > drivers/staging/rockchip-mpp/vdpu2/mpeg2.c | 253 +++ > drivers/staging/rockchip-mpp/vdpu2/regs.h | 699 +++++++++ > 16 files changed, 5052 insertions(+) > create mode 100644 drivers/staging/rockchip-mpp/Kconfig > create mode 100644 drivers/staging/rockchip-mpp/Makefile > create mode 100644 drivers/staging/rockchip-mpp/mpp_debug.h > create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.c > create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.h > create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c > create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c > create mode 100644 drivers/staging/rockchip-mpp/mpp_service.c > create mode 100644 drivers/staging/rockchip-mpp/mpp_service.h > create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hal.h > create mode 100644 drivers/staging/rockchip-mpp/rkvdec/regs.h > create mode 100644 drivers/staging/rockchip-mpp/vdpu2/hal.h > create mode 100644 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c > create mode 100644 drivers/staging/rockchip-mpp/vdpu2/regs.h >