Received: by 10.223.164.202 with SMTP id h10csp494666wrb; Tue, 7 Nov 2017 09:31:57 -0800 (PST) X-Google-Smtp-Source: ABhQp+ShGe8ljd2zMnr7hZY/R97qqbu9BWnsqPxB+hE/BWL4cpEGc3wZI+qwLNUfvqC3DyVs6ipr X-Received: by 10.159.194.135 with SMTP id y7mr19055792pln.33.1510075917171; Tue, 07 Nov 2017 09:31:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510075917; cv=none; d=google.com; s=arc-20160816; b=smC5wa8d0asdOCSK/e3WZMUIhpLRXWAiYoZGa17W0VP7k84JUmxH2RUL5SeHPozKw1 SD2oN2VC2Vug3d+ZW7Mc81OMRmlPlPEEju87X37g2/CHsY3Bp+yx9auG0tw5QDI6qoQg 43+6zFAIb2eQBX9WVb0oUiTzhEU/dgxpkhQ2ofFovFONSYo8Tk08uPhjc9MWPcuXSFFC 79wWTW+HmmPkPMo3cqM4jKklLYIjdk04N3+G9HR9coQ2Zk5Zo5vtdEteyDAL6rumoHYF SzrBIUhFSm4RLzqh/rLYhi2leIhLS8OtT2hF/8BL+H5NSEpgLVx2jFsso7IOyyTrTGRN QRAg== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=cRltTnfcETY6nlXY+YgEhBcVJwSGY5iOQ1vhVJxmJvQ=; b=zF56rw7Y53dlanuphF9v4PRBDf6lkMpdQYIZQSecbKgPlRM/CkDMDpbrqAQdATuLjP 5SAImZ4lLytqWG7i1451Oquj2hg85RiVL2j4bCdft3z8v5+6Z0Ax2IbhQRf/uRCPxLb5 WQbA7ACw0ilmKljzRQKhrmB37Uc/gPeAhfd3OeuyMaifvw9vHQhOvbUUiM0bxr66GrQw KtSkyH35dq4SFj7Kw1sckZwaivw/f8A54gwyrogC6PLe/JEg9CFJTd6qUYZcwMKeH9Ek B6I9gl0KqObhOmDGWeKCJVgLuOD1LdDFfrdPoNyHa+Ng9Lgt+H1znElknifkrBVE/tT6 7Uhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gateworks-com.20150623.gappssmtp.com header.s=20150623 header.b=L2FSfYW0; 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 s7si1728519pgc.415.2017.11.07.09.31.43; Tue, 07 Nov 2017 09:31:57 -0800 (PST) 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; dkim=pass header.i=@gateworks-com.20150623.gappssmtp.com header.s=20150623 header.b=L2FSfYW0; 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 S1754014AbdKGGEf (ORCPT + 91 others); Tue, 7 Nov 2017 01:04:35 -0500 Received: from mail-wr0-f171.google.com ([209.85.128.171]:56808 "EHLO mail-wr0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753962AbdKGGEb (ORCPT ); Tue, 7 Nov 2017 01:04:31 -0500 Received: by mail-wr0-f171.google.com with SMTP id q66so7165392wrb.13 for ; Mon, 06 Nov 2017 22:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gateworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cRltTnfcETY6nlXY+YgEhBcVJwSGY5iOQ1vhVJxmJvQ=; b=L2FSfYW002vi9N4QDARwVuOzHxiXzoK5hCgKvblHPMr8yGiDMxBAVmkDWe0E9BAgMc afRCFFfVJVh7BwsyjD3Yw8HYDJkHfyOw857kMg0O9kFEwFwovkkM1ZfIyIIOjldpj+JO IT/bHgNJGD+Wg75KYhFxWDxw+sPx9g9wGmKPYBvVDYGrXDRpiX199G9bfjMvs/CIj8cu PSCQ4pQwOQ/Qm4YMkFiTNJPO3xx2q499hp2uuWJd2zNSAnTu7RpdvMWh2UATC6e1mcAj 42YpjOyiygZR7bMyTQCyO+EQ6h6LMSR3FRM/7E08xnLUKRFpH3rJAGCv+sVbsyhFBVCf jpng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cRltTnfcETY6nlXY+YgEhBcVJwSGY5iOQ1vhVJxmJvQ=; b=XIRQg15ov7BVydgOUePfjFZDOYun7wfFUJGobUfjHZ4S7ZI5/rojh5iZJshqyoqF9Z RiLDmS6kSybnCXNTCSTImX6rO8Gz0eoBx40wtVcNc3Daa06nkvis9+28JOF+cYHlfDHR POV0ZpGwMWUe5aAzxo5R1XR689ThVL7P04SqX5H0JJL3lCjV+ACqe8j167NK6Qis/OSe 7JsseRuBY21V8heGDhGZ9e99Bm2FQi9pkWq6J+HwWLKNHoYDWWZdBNCUXgjHZgzhzIlo VrEVavXCj1JFqAfIIdUET3GC5h0Mfa5YqjFazi4z0HSrHQDhXE1PJ7ilY7eWu3C+Kv4M c7Og== X-Gm-Message-State: AMCzsaVg+0aoB5UEw3Soxp8KKMzquxlAEvB6bCqXNDwwzLr8uLZPiyD0 Mtwyj0QmzwEPgYULZd60U65QuaEBZk4MjzT0Xkh2rw== X-Received: by 10.223.163.11 with SMTP id c11mr14172473wrb.102.1510034670321; Mon, 06 Nov 2017 22:04:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.228.215 with HTTP; Mon, 6 Nov 2017 22:04:29 -0800 (PST) In-Reply-To: References: <1507783506-3884-1-git-send-email-tharvey@gateworks.com> <1507783506-3884-4-git-send-email-tharvey@gateworks.com> <230ceb18-1d69-7fa8-acb0-c810094f8e50@xs4all.nl> From: Tim Harvey Date: Mon, 6 Nov 2017 22:04:29 -0800 Message-ID: Subject: Re: [PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver To: Hans Verkuil Cc: linux-media , alsa-devel@alsa-project.org, "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Shawn Guo , Steve Longerbeam , Philipp Zabel , Hans Verkuil , Mauro Carvalho Chehab 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 Fri, Oct 20, 2017 at 7:00 AM, Tim Harvey wrote: > On Thu, Oct 19, 2017 at 12:39 AM, Hans Verkuil wrote: > >>> >>> Regarding video standard detection where this chip provides me with >>> vertical-period, horizontal-period, and horizontal-pulse-width I >>> should be able to detect the standard simply based off of >>> vertical-period (framerate) and horizontal-period (line width >>> including blanking) right? I wasn't sure if my method of matching >>> these within 14% tolerance made sense. I will be removing the hsmatch >>> logic from that as it seems the horizontal-pulse-width should be >>> irrelevant. >> >> For proper video detection you ideally need: >> >> h/v sync size >> h/v back/front porch size >> h/v polarity >> pixelclock (usually an approximation) >> >> The v4l2_find_dv_timings_cap() helper can help you find the corresponding >> timings, allowing for pixelclock variation. >> >> That function assumes that the sync/back/frontporch values are all known. >> But not all devices can actually discover those values. What can your >> hardware detect? Can it tell front and backporch apart? Can it determine >> the sync size? >> >> I've been considering for some time to improve that helper function to be >> able to handle hardware that isn't able separate sync/back/frontporch values. >> > > The TDA1997x provides only the vertical/horizontal periods and the > horizontal pulse > width (section 8.3.4 of datasheet [1]). > > Can you point me to a good primer on the relationship between these > values and the h/v back/front porch? > > Currently I iterate over the list of known formats calculating hper > (bt->pixelclock / V4L2_DV_BT_FRAME_WIDTH(bt)) and vper (hper / > V4L2_DV_BT_FRAME_HEIGHT(bt)) (framerate) and find the closest match > within +/- 7% tolerance. The list of supported formats is sorted by > framerate then width. > > /* look for matching timings */ > for (i = 0; i < ARRAY_SIZE(tda1997x_hdmi_modes); i++) { > const struct tda1997x_video_std *std = &tda1997x_hdmi_modes[i]; > const struct v4l2_bt_timings *bt = &std->timings.bt; > int _hper, _vper, _hsper; > int vmin, vmax, hmin, hmax, hsmin, hsmax; > int vmatch, hsmatch; > > width = V4L2_DV_BT_FRAME_WIDTH(bt); > lines = V4L2_DV_BT_FRAME_HEIGHT(bt); > > _hper = (int)bt->pixelclock / (int)width; > _vper = _hper / lines; > _hsper = (int)bt->pixelclock / (int)bt->hsync; > if (bt->interlaced) > _vper *= 2; > /* vper +/- 0.7% */ > vmin = 993 * (27000000 / _vper) / 1000; > vmax = 1007 * (27000000 / _vper) / 1000; > _hsper = (int)bt->pixelclock / (int)bt->hsync; > if (bt->interlaced) > _vper *= 2; > /* vper +/- 0.7% */ > vmin = 993 * (27000000 / _vper) / 1000; > vmax = 1007 * (27000000 / _vper) / 1000; > /* hper +/- 0.7% */ > hmin = 993 * (27000000 / _hper) / 1000; > hmax = 1007 * (27000000 / _hper) / 1000; > > /* vmatch matches the framerate */ > vmatch = ((vper <= vmax) && (vper >= vmin)) ? 1 : 0; > /* hmatch matches the width */ > hmatch = ((hper <= hmax) && (hper >= hmin)) ? 1 : 0; > if (vmatch && hsmatch) { > v4l_info(state->client, > "resolution: %dx%d%c@%d (%d/%d/%d) %dMHz %d\n", > bt->width, bt->height, bt->interlaced?'i':'p', > _vper, vper, hper, hsper, pixrate, hsmatch); > state->fps = (int)bt->pixelclock / (width * lines); > state->std = std; > return 0; > } > } > > Note that I've thrown out any comparisons based on horizontal pulse > width from my first patch as that didn't appear to fit well. So far > the above works well however I do fail to recognize the following > modes (using a Marshall SG4K HDMI test generator): > Hans, I've found that I do indeed need to look at the 'hsper' that the TDA provides above along with the vper/hper as there are several timings that match a given vper/hper. However I haven't figured out how to make sense of the hsper value that is returned. Here are some example timings and the vper/hper/hsper returned from the TDA: V4L2_DV_BT_DMT_1280X960P60 449981/448/55 V4L2_DV_BT_DMT_1280X1024P60 449833/420/27 V4L2_DV_BT_DMT_1280X768P60 450021/568/11 V4L2_DV_BT_DMT_1360X768P60 449867/564/34 Do you know what the hsper could be here? It doesn't appear to match v4l2_bt_timings hsync ((27MHz/bt->pixelclock)*bt->hsync). Thanks, Tim From 1583424475659454000@xxx Tue Nov 07 16:14:14 +0000 2017 X-GM-THRID: 1581025700141870942 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread