Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp88645ybm; Mon, 20 May 2019 12:23:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqyaLMr+AyOONyk6Y8oGH1P+11Pz/qQC405tYd/0iNW39fbEcO+yEuVjpchBViqZqFvtEqhY X-Received: by 2002:a63:78cf:: with SMTP id t198mr39666229pgc.82.1558380239269; Mon, 20 May 2019 12:23:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558380239; cv=none; d=google.com; s=arc-20160816; b=BX/28tKLA1DUNkAm4PFsY24UzvrlqRSS2fk2gF+2zkol6PEU/6bHZw3iv4CseEntPD kJ2ftwK17FVLUfASb0CsL3Mn5hLJ2asx87mjUmh/2/vMa+3XBdeu3gniPj8JSXWx1HZ3 2gF9KBuvBnzWllTYJ2f9EnFylqyc+tFWXrtios+CU216A2y5A/xeGkRgWFDet6IEsVR7 jAMfYYIV3gfUktA/1gF62d0tG3HGRlxmtgkrrBR6aX/rYhCmB+lqzyjf/dLbr4RqfdNa veQYkGpIR8mnB4J452KdTruCk8d/9LjUn+pTusbHBI+StvQnyzY4GI0oL6M/m1piV4d2 6lhA== 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=qLeKx+i91aPI9IrO5QzrN+wFBTKYOAL634gBH/9vFbA=; b=OLPI5kLY297B41v7yg7dXJGnDG2x0nTsrBkIoMYXedj/doukIjOgInkHKQjSF5DhYk uGSdBkwrztLTaaFy9NkIpXqgSnhlBb86Je8EHbmwSwt7Z3PJkf+KayGG4xnDgsVuVSF/ 4tGNPY2xABozEjDyxK/i2CA8MLEC9qUsj36HYuTs2/f57cAKI/kHfzywz4MQKll+YhZO GmbMnxkyHAqc1yF5xaG7+Xm9IaQzUd4nDB5suEWr9sHZae5sgGbarb4G8zQIyDrGHhEU Vd/rS/8weca31tXBCV4LVK50x/CAN15yBtxXRmxnpnF1rJlYUpvkJ61qcp+dMmCRCu++ UKtw== 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 r14si18381924pgf.45.2019.05.20.12.23.44; Mon, 20 May 2019 12:23:59 -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 S1726111AbfETTV7 (ORCPT + 99 others); Mon, 20 May 2019 15:21:59 -0400 Received: from smtp01.smtpout.orange.fr ([80.12.242.123]:29627 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725776AbfETTV6 (ORCPT ); Mon, 20 May 2019 15:21:58 -0400 Received: from mail-qt1-f170.google.com ([209.85.160.170]) by mwinf5d48 with ME id EjMv2000F3gswE903jMwHW; Mon, 20 May 2019 21:21:56 +0200 X-ME-Helo: mail-qt1-f170.google.com X-ME-Auth: bWF4aS5qb3VyZGFuQHdhbmFkb28uZnI= X-ME-Date: Mon, 20 May 2019 21:21:56 +0200 X-ME-IP: 209.85.160.170 Received: by mail-qt1-f170.google.com with SMTP id h1so17719306qtp.1 for ; Mon, 20 May 2019 12:21:56 -0700 (PDT) X-Gm-Message-State: APjAAAUjJrxYF9EoJOdQKfjL7mPwFttEQB2h7mv1fjLnsEB/oTBGZNXJ Fhr2Hh7dw7WKTxp4dHbjIqlH6eqzjvw4/i9Akng= X-Received: by 2002:a0c:d941:: with SMTP id t1mr61382342qvj.204.1558380115291; Mon, 20 May 2019 12:21:55 -0700 (PDT) MIME-Version: 1.0 References: <20190413171532.25967-1-martin.blumenstingl@googlemail.com> In-Reply-To: From: Maxime Jourdan Date: Mon, 20 May 2019 21:21:43 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3] 32-bit Meson: add the canvas module To: Martin Blumenstingl Cc: Maxime Jourdan , linux-amlogic , Kevin Hilman , mjourdan@baylibre.com, Linux Kernel Mailing List , linux-arm-kernel@lists.infradead.org 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 Hey Martin, so sorry for forgetting about this. On Thu, Apr 18, 2019 at 9:50 PM Martin Blumenstingl wrote: > > Hi Maxime, > > On Sat, Apr 13, 2019 at 8:54 PM Maxime Jourdan wrote: > > > > Hi Martin, > > On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl > > wrote: > > > > > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas > > > IP is used by the video decoder hardware as well as the VPU (video > > > output) hardware. > > > > > > Neither the VPU nor the video decoder driver support the 32-bit SoCs > > > yet. However, we can still add the canvas module to have it available > > > once these drivers gain support for the older SoCs. > > > > > > I have tested this on my Meson8m2 board by hacking the VPU driver to > > > not re-initialize the VPU (and to use the configuration set by u-boot). > > > With that hack I could get some image out of the CVBS connector. No > > > changes to the canvas driver were required. > > > > > > Due to lack of hardware I could not test Meson8, but I'm following (as > > > always) what the Amlogic 3.10 vendor kernel uses. > > > Meson8b is also not tested because u-boot of my EC-100 doesn't have > > > video output enabled (so I couldn't use the same hack I used on my > > > Meson8m2 board). > > > > > > This series meant to be applied on top of "Meson8b: add support for the > > > RTC on EC-100 and Odroid-C1" from [0] > > > > > > > > > > The series looks good to me, however I wonder if we should maybe add a > > new compatible ? > > > > The canvas IP before the GX* generation does not handle what Amlogic > > calls "endianness", the field that allows doing some byte-switching to > > get proper NV12/NV21. So the following defines are unusable: > > > > #define MESON_CANVAS_ENDIAN_SWAP16 0x1 > > #define MESON_CANVAS_ENDIAN_SWAP32 0x3 > > #define MESON_CANVAS_ENDIAN_SWAP64 0x7 > > #define MESON_CANVAS_ENDIAN_SWAP128 0xf > I didn't know about this - thank you for pointing this out. > > your suggestions to add new compatible strings is a good idea for that case. > Amlogic uses different defines for Meson8 and Meson8m2 in their vendor > kernel and they keep Meson8b different. > I will add three new compatibles, one for each SoC (Meson8, Meson8b, > Meson8m2) just to be on the safe side if we discover differences in > the canvas IP on these SoCs. > > what do you think? > Sure thing. Keep an eye out for any hints regarding the amount of canvases as well, I *think* I remember some old SoCs having only 192 but I haven't been able to find it again. > > It wouldn't change much functionally, but we could have e.g a warning > > if a m8 canvas user tries to set endianness even though it does > > nothing. > this is a good idea, that will make it easier to spot why something > doesn't work. > we can also return -EINVAL, like you already do for the case where the > canvas ID is already used. > Yes, returning an error is a good idea. Maxime > > Martin