Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030673AbdIZMca (ORCPT ); Tue, 26 Sep 2017 08:32:30 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:33872 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967859AbdIZMc2 (ORCPT ); Tue, 26 Sep 2017 08:32:28 -0400 X-Google-Smtp-Source: AOwi7QCD81x6sRBUlYK0CQYARym6rNfWPWCE6dqk4IinjAL7LuawpCn63qkochZ1WPKoSoLSogr3ag== Subject: Re: [PATCH v1 0/2] NVIDIA Tegra20 video decoder driver To: Greg Kroah-Hartman Cc: Thierry Reding , Jonathan Hunter , Rob Herring , linux-tegra@vger.kernel.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org References: <20170926065447.GC6250@kroah.com> From: Dmitry Osipenko Message-ID: Date: Tue, 26 Sep 2017 15:32:23 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170926065447.GC6250@kroah.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1551 Lines: 32 On 26.09.2017 09:54, Greg Kroah-Hartman wrote: > On Tue, Sep 26, 2017 at 01:15:41AM +0300, Dmitry Osipenko wrote: >> This driver provides accelerated video decoding to NVIDIA Tegra20 SoC's, >> it is a result of reverse-engineering efforts. Driver has been tested on >> Toshiba AC100 and Acer A500, it should work on any Tegra20 device. >> >> In userspace this driver is utilized by libvdpau-tegra [0] that implements >> VDPAU interface, so any video player that supports VDPAU can provide >> accelerated video decoding on Tegra20 on Linux. > > Why not use the v4l2 api instead? Doesn't that provide the same needed > user/kernel api here instead of creating yet-another-custom ioctl? > 1) The HW doesn't generalize for the common API. Like for example, it isn't capable of unpacking bitstream encoded with CABAC (Context-adaptive binary arithmetic coding), so unpacking should be done in software and then VDE HW isn't capable of decoding such a stream in a fully-automated manner, software would have to feed engine with a chunks of macroblocks untill the whole frame is decoded. That lameness is partially hidden in the BLOB's firmware, that firmware actually is just a driver BTW. 2) We want to have decoding integrated with the presentation of the decoded video frame. So having v4l interface for decoding would be just an extra unnecessary shim, increasing CPU / memory resources usage and complexity of the code. 3) The decoding and presentation are already implemented using VDPAU API and proven to work decently in that way. -- Dmitry