Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp505752imm; Sat, 8 Sep 2018 03:24:31 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYZyriLJRYLDwMbPBNlakNRsDqsoVYY06q2Jj9tdY/lZDXO+SSRlmDIJ2W3rQK3w9/FDTJZ X-Received: by 2002:a62:cec6:: with SMTP id y189-v6mr13119930pfg.140.1536402271469; Sat, 08 Sep 2018 03:24:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536402271; cv=none; d=google.com; s=arc-20160816; b=wRuQQATcmL7NSDtCwAjsdaYi/ITWlSdVvLTgWrutKhukDRqyuMEKS7J3cS3ejd3SF8 EMazQyMaModiNuXFudHtT0z5beZccE6OFO/jTO3tg/a/TJRn1wVQUv/EBj9Una8xvYq2 NdcteEkW0hyUi1rx84JSa1hL+htDeJwWqM5uueLvfpjkNECaISP+YfOSx1I22OLYd1Zw 5ch5hHIo5nR6Gy0Ct7JuXI0MRe7za5ZHn+8U06wuUdatl8Rtgu8dJD6MrL2iSfunUNke YAoERn3Cuz+7wjVJO0hJupfVNvYkElEdSyFCUpoEfX84rL+YVl6etR1tFKwNf+zK0Zsy +HfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=/7jbFWcKp3kpSFtmSsiFzcZJWHU4EDKwkNrCIi6ZnKI=; b=yCjWuakcFz5d9r6dJ9XiCkl9w50oVE3etYi45ordH1A4WSqE4RUmU/r/uBaTKTIjG4 JBz8IjgIS0n1b0qlxGa56O/lU1wTOanaBT+Uj970by2Cb6F1gvhbSgmACg6dtlaaDhW8 OWf3NME8d7b5JV3YvWeyK8T4iUxaA7slTYu6YdqVdPdjN4Li9lRT5H1G6wFDmF5NZKEC MRZkzhfrSqrYcvEpVcYPjd8hd94xzrnHl2KJ39UbRDIX5SFq6vtRman1zF2tq3DumNO6 mw7nkYjEiZnRQX8mHVo5dQNx0DAqdTOCWp6IUt16JkIxOPxAdRmAJ9smg/rAvxS50hkA labw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g3-v6si10254733pll.395.2018.09.08.03.24.16; Sat, 08 Sep 2018 03:24:31 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726748AbeIHPI3 (ORCPT + 99 others); Sat, 8 Sep 2018 11:08:29 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:39508 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726472AbeIHPI3 (ORCPT ); Sat, 8 Sep 2018 11:08:29 -0400 Received: by mail-ed1-f67.google.com with SMTP id h4-v6so13188184edi.6; Sat, 08 Sep 2018 03:23:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/7jbFWcKp3kpSFtmSsiFzcZJWHU4EDKwkNrCIi6ZnKI=; b=SkDB+0HrjrSX710uN5Hy40PWN/hTVqhyV1hevbOWyJkBjdbRUr11ff6RWEd1gytXqV x9WvWJSf03FAUsGpf/w4eUHscCodKI/6U0XIQkpMlhGBGPblBaRj+1Z2K2NA8X+EwGF5 h7EawAaNSQoLCytVf+B8Bgf81ENCU1XStOEwdICpNBARx9GGontMQpu9bs1FRn0lmznJ OSz+2OdXff6XvWxeT50PtvfgdeNdnhYDtBHIkAH0Pfn91bA1sN9F9x5p7As/t2g9NiCN x2KZSKEJQpl6zBNFVnh+mdjLSqdzdQ8vUYYc3AVUBHY0IirX+3SScrOCsrjPr84kSmop XYbg== X-Gm-Message-State: APzg51DVJInQOzgAaPk7vYreaT8KrMpq5BWGwinyDzhzZSoRAwn7zrqf lrj9OIQuGz6dYLYUKqVRT2sBY7SL X-Received: by 2002:a50:d512:: with SMTP id u18-v6mr13545301edi.291.1536402191808; Sat, 08 Sep 2018 03:23:11 -0700 (PDT) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com. [209.85.221.43]) by smtp.gmail.com with ESMTPSA id g38-v6sm5701557edc.40.2018.09.08.03.23.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Sep 2018 03:23:09 -0700 (PDT) Received: by mail-wr1-f43.google.com with SMTP id g33-v6so17224691wrd.1; Sat, 08 Sep 2018 03:23:09 -0700 (PDT) X-Received: by 2002:adf:d84a:: with SMTP id k10-v6mr8322365wrl.26.1536402189495; Sat, 08 Sep 2018 03:23:09 -0700 (PDT) MIME-Version: 1.0 References: <20180907163347.32312-1-contact@paulk.fr> <11104c03-97ac-8b36-7d75-dfecb8fcce10@xs4all.nl> In-Reply-To: <11104c03-97ac-8b36-7d75-dfecb8fcce10@xs4all.nl> From: Chen-Yu Tsai Date: Sat, 8 Sep 2018 18:22:58 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/2] Follow-up patches for Cedrus v9 To: Hans Verkuil Cc: Paul Kocialkowski , linux-kernel , Linux Media Mailing List , devel@driverdev.osuosl.org, linux-arm-kernel , Maxime Ripard , Paul Kocialkowski , Mauro Carvalho Chehab , Greg Kroah-Hartman , linux-sunxi , Randy Li , ezequiel@collabora.com, Tomasz Figa , Alexandre Courbot , Philipp Zabel , Laurent Pinchart , Sakari Ailus , Thomas Petazzoni Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Sep 8, 2018 at 6:06 PM Hans Verkuil wrote: > > On 09/07/2018 06:33 PM, Paul Kocialkowski wrote: > > This brings the requested modifications on top of version 9 of the > > Cedrus VPU driver, that implements stateless video decoding using the > > Request API. > > > > Paul Kocialkowski (2): > > media: cedrus: Fix error reporting in request validation > > media: cedrus: Add TODO file with tasks to complete before unstaging > > > > drivers/staging/media/sunxi/cedrus/TODO | 7 +++++++ > > drivers/staging/media/sunxi/cedrus/cedrus.c | 15 ++++++++++++--- > > 2 files changed, 19 insertions(+), 3 deletions(-) > > create mode 100644 drivers/staging/media/sunxi/cedrus/TODO > > > > So close... > > When compiling under e.g. intel I get errors since it doesn't know about > the sunxi_sram_claim/release function and the PHYS_PFN_OFFSET define. > > Is it possible to add stub functions to linux/soc/sunxi/sunxi_sram.h > if CONFIG_SUNXI_SRAM is not defined? That would be the best fix for that. > > The use of PHYS_PFN_OFFSET is weird: are you sure this is the right > way? I see that drivers/of/device.c also sets dev->dma_pfn_offset, which > makes me wonder if this information shouldn't come from the device tree. > > You are the only driver that uses this define directly, which makes me > suspicious. On Allwinner platforms, some devices do DMA directly on the memory BUS with the DRAM controller. In such cases, the DRAM has no offset. In all other cases where the DMA goes through the common system bus and the DRAM offset is either 0x40000000 or 0x20000000, depending on the SoC. Since the former case is not described in the device tree (this is being worked on by Maxime BTW), the dma_pfn_offset is not the value it should be. AFAIK only the display and media subsystems (VPU, camera, TS) are wired this way. In drivers/gpu/drm/sun4i/sun4i_backend.c (the display driver) we use PHYS_OFFSET, which is pretty much the same thing. Regards ChenYu