Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S969597AbdIZWRQ (ORCPT ); Tue, 26 Sep 2017 18:17:16 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:37322 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967632AbdIZWRO (ORCPT ); Tue, 26 Sep 2017 18:17:14 -0400 X-Google-Smtp-Source: AOwi7QBJeQZFRajYExlEZxtRYQ2EQ6IHXkevSRYt3F7CuhnJzpjJj5vrIWqnHz2V6tMrevZDZXxHSw== Subject: Re: [PATCH v1 0/2] NVIDIA Tegra20 video decoder driver To: Greg Kroah-Hartman Cc: devel@driverdev.osuosl.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Rob Herring , Jonathan Hunter , Thierry Reding , linux-tegra@vger.kernel.org References: <20170926065447.GC6250@kroah.com> <20170926213549.GE3418@kroah.com> From: Dmitry Osipenko Message-ID: Date: Wed, 27 Sep 2017 01:17:10 +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: <20170926213549.GE3418@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: 1973 Lines: 42 On 27.09.2017 00:35, Greg Kroah-Hartman wrote: > On Tue, Sep 26, 2017 at 03:32:23PM +0300, Dmitry Osipenko wrote: >> 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. > > This sounds like something you should be talking over with the media > driver developers, why are they not even cc:ed on this submission? > > I need their ack on this new api before I can take this. > Indeed, will cc media on V2. -- Dmitry