From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA567C4361B for ; Wed, 9 Dec 2020 05:08:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7CB3A22512 for ; Wed, 9 Dec 2020 05:08:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727139AbgLIFH6 (ORCPT ); Wed, 9 Dec 2020 00:07:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34604 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727087AbgLIFH5 (ORCPT ); Wed, 9 Dec 2020 00:07:57 -0500 Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3BC5EC0613CF for ; Tue, 8 Dec 2020 21:07:17 -0800 (PST) Received: by mail-ej1-x644.google.com with SMTP id g20so274525ejb.1 for ; Tue, 08 Dec 2020 21:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q3NLgFg9+0RUlIIykuKLWs9CjD4F435j35iR2qAmKLE=; b=NxGkpUi/oOts1K+HQSMMHnnn+b8Y+8y6ViAjMpa+UMz0Lkfj3C4lCDwNfKpX7hpU69 Y2JH7fXNBhnthgZQpr9PyPyu1OVysoq6+lMZ8QkM/nk0C9lAGjEc8UbJSZ8pgv7iDU+Y r1Zc2in6pxy8+ig3ljiDeAHzT+NoC07QkFixw= 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=Q3NLgFg9+0RUlIIykuKLWs9CjD4F435j35iR2qAmKLE=; b=LEEAAjJV7O/rYONSA/pz+/1TyyPlWChUAahog/u5lwuG2trAgupoHPWwEWCSMjKK16 boWaErCC9daJfem9YxKAmEqwS3sM444TTude+rgZ7oOtsxcT7Wp+Noyy9GFOgS2AH3h/ t2eTqEsbC/Qsba5vU4P0FIUz7M9NmN/bCFb1Cf4CvRPVT+nR7Z2ky5zqkl/Y9OrO67Hn nbVZb0vKgGwrbNYpSd/XhjwOQvCpT9Rl0kVFB016ZSNnwf7nURo0WE4ca9ZSkCIf3Igi G4+LjKviT4q4dOJ1aJBlkchOJeZ8MSkTiUqEMlSlXjU9VFbCEH9zj/ifJmWFNNvo5xNu qoNA== X-Gm-Message-State: AOAM530dV6ZW763WddQKgCwIi9yJHgKmpfv+ATNEMyN8EEbwOJaHh3Wb BAhkTXu9hyMZubX4iaUkrTcUA7DO30dWiw== X-Google-Smtp-Source: ABdhPJzdDkO7NzfFUFoLh6pk6/54o/Vfy+8mRGbD+dMmeNzTwJtgAegGP1oMeZ1T3HvMr8Lq7NXiZg== X-Received: by 2002:a17:906:68d1:: with SMTP id y17mr579241ejr.447.1607490435475; Tue, 08 Dec 2020 21:07:15 -0800 (PST) Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com. [209.85.221.41]) by smtp.gmail.com with ESMTPSA id z26sm365014edl.71.2020.12.08.21.07.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Dec 2020 21:07:14 -0800 (PST) Received: by mail-wr1-f41.google.com with SMTP id r7so301563wrc.5 for ; Tue, 08 Dec 2020 21:07:13 -0800 (PST) X-Received: by 2002:adf:bb0e:: with SMTP id r14mr543768wrg.159.1607490433220; Tue, 08 Dec 2020 21:07:13 -0800 (PST) MIME-Version: 1.0 References: <20201116155008.118124-1-robert.foss@linaro.org> In-Reply-To: From: Tomasz Figa Date: Wed, 9 Dec 2020 14:07:01 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] media: ov8856: Remove 3280x2464 mode To: Robert Foss Cc: Bingbu Cao , Dongchun Zhu , Mauro Carvalho Chehab , linux-media , linux-kernel , Sakari Ailus , Ben Kao Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 27, 2020 at 10:38 PM Robert Foss wrote: > > Thanks for digging into this everyone! > > Assuming Tomasz doesn't find any stretching, I think we can conclude > that this mode works, and should be kept. Thanks Dongchun for parsing > the datasheet and finding the Bayer mode issue for the two other > recently added resolutions. I checked the raw output and it actually seems to have 3296x2464 non-black pixels. The rightmost 16 ones seem a copy of the ones from 3248. That might be just some padding from the output DMA, though. Generally all the datasheets I've seen still suggest that only the middle 3264x2448 are active pixels to be output, so this warrants double checking this with Omnivision. Let me see what we can do about this. Best regards, Tomasz > > On Fri, 27 Nov 2020 at 11:26, Tomasz Figa wrote: > > > > On Thu, Nov 26, 2020 at 7:00 PM Robert Foss wrote: > > > > > > On Wed, 25 Nov 2020 at 08:32, Tomasz Figa wrote: > > > > > > > > Hi Bingbu, > > > > > > > > On Wed, Nov 25, 2020 at 1:15 PM Bingbu Cao wrote: > > > > > > > > > > > > > > > > > > > > On 11/24/20 6:20 PM, Robert Foss wrote: > > > > > > On Tue, 24 Nov 2020 at 10:42, Bingbu Cao wrote: > > > > > >> > > > > > >> Hi, Robert > > > > > >> > > > > > >> I remember that the full size of ov8856 image sensor is 3296x2480 and we can get the 3280x2464 > > > > > >> frames based on current settings. > > > > > >> > > > > > >> Do you have any issues with this mode? > > > > > > > > > > > > As far as I can tell using the 3280x2464 mode actually yields an > > > > > > output resolution that is 3264x2448. > > > > > > > > > > > > What does your hardware setup look like? And which revision of the > > > > > > sensor are you using? > > > > > > > > > > > > > > > > Robert, the sensor revision I am using is v1.1. I just checked the actual output pixels on our > > > > > hardware, the output resolution with 2464 mode is 3280x2464, no black pixels. > > > > > > > > > > As Tomasz said, some ISP has the requirement of extra pixel padding, From the ov8856 datasheet, > > > > > the central 3264x2448 pixels are *suggested* to be output from the pixel array and the boundary > > > > > pixels can be used for additional processing. In my understanding, the 32 dummy lines are not > > > > > black lines. > > > > > > > > The datasheet says that only 3264x2448 are active pixels. What pixel > > > > values are you seeing outside of that central area? In the datasheet, > > > > those look like "optically black" pixels, which are not 100% black, > > > > but rather as if the sensor cells didn't receive any light - noise can > > > > be still there. > > > > > > > > > > I've been developing support for some Qcom ISP functionality, and > > > during the course of this I ran into the issue I was describing, where > > > the 3280x2464 mode actually outputs 3264x2448. > > > > > > I can think of two reasons for this, either ISP driver bugs on my end > > > or the fact that the sensor is being run outside of the specification > > > and which could be resulting in differences between how the ov8856 > > > sensors behave. > > > > I just confirmed and we're indeed using this mode in a number of our > > projects based on the Intel ISP and it seems to be producing a proper > > image with all pixels of the 3280x2464 matrix having proper values. > > I'm now double checking whether this isn't some processing done by the > > ISP, but I suspect the quality would be bad if it stretched the > > central 3264x2448 part into the 3280x2464 frame. > > > > Best regards, > > Tomasz