Received: by 2002:a05:7208:13ce:b0:7f:395a:35b6 with SMTP id r14csp324392rbe; Thu, 29 Feb 2024 00:03:06 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVvYP+zfHsdmKR5D0GujrP7YKvHfM4O50y2hEn3FAGTel12jshOVTSMoOswoCBCRpOz+McYmyPPfL/9Re5TxmPUte7sRnL5QScnOdbUPw== X-Google-Smtp-Source: AGHT+IHfnWOI03o/L7wV1EJvhCYIFiYIOlss2JZQnWwSR9WisBpCSLCcUReJMnXdRk12ZhRzO5ZQ X-Received: by 2002:a17:906:7f12:b0:a3f:da1c:ae4c with SMTP id d18-20020a1709067f1200b00a3fda1cae4cmr1016744ejr.54.1709193786553; Thu, 29 Feb 2024 00:03:06 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709193786; cv=pass; d=google.com; s=arc-20160816; b=ObgUrPTd+qVX2sZl0xgwchbhMDgLW72wtST5eEYMyAYxx2cxb2DPjWf2c6SDoUAKxx Cs07IaoU8PtB+CCU5tccyrAtUsunlkTD5EM+s+ldhYeIdET7zmW3n4ICjxYhUlbRbVkg g03On1khoWySo/ORSGigVL0pjeMhZS3OuCIlCINYoE7KpHutLcAwXvHxJ0zX4BnM/2rC oeW7l3SF9BzxFXTWmcaJ5N/2IQZGpIgRrAQFKU38h7fZxNCosS+OuOYJRvqE1gq6Z6hW tnglZzDPIIeXCtbh1Zw5Mo4g8UKyQ4P1maHJ77U91IvTx0kX+Qk+ELpACZahAOZRFmfI GUow== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=MoXHuQymBgnoPrRrvPebe+2FtaHhXS1SppwxJYKZKsg=; fh=1Nu60LhnqbUs/2a/YpmPa+5ou6YTk6h/U8AZ6ueS+20=; b=JchyJvfwUf5k5mIL+xVSajGnXkft9UnpqmnjhqGzamyRC0JX68lUB0I6kEsMOtNntw nMnDwiUtbuHlSTlXdBa7M/a1EgAsYjuadz0GGYSoWAPvwEVYpgJ51pujt9Dgtmz3mVJZ uThWgAHJyS8TS7WtfopTm5+SYiRJJZtAWLrP6CuaovQ4rI3+FeljRu1VBcu6nX9RXT2X FlS6YUr70dUSdt8ABfNGVBe7p5rHmTQBgFYumceB/UmAZFiJv4sk5rCAwpg7xmrnDuRy +IQYmSvHO3wXNFYdwTXTm5b0cOYXL0/vBpSpNY0dC2XG2U7kTi70CFNhX5Ks1Dn9/BJ1 9CLw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-86258-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-86258-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id gt12-20020a170906f20c00b00a44454cc6a3si281707ejb.662.2024.02.29.00.03.06 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Feb 2024 00:03:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-86258-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-86258-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-86258-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 4FCDA1F21971 for ; Thu, 29 Feb 2024 08:03:06 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B980B481CD; Thu, 29 Feb 2024 08:02:55 +0000 (UTC) Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3618044C9E; Thu, 29 Feb 2024 08:02:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709193775; cv=none; b=iXuO3NG6DQhAsh1P95KrQcCZhsFV8naqYd6l5YKDnAEzJpqPaNKJ6IRazqqy5VFStVaOkXCj7iUtKhY/8az7MoWmuZXX9vC+7e8/6QyMbeCABTIVCYal1Q3QrGoNg75e5pUW9B5EW5xKpAuC7VEZmaNVbMw24LNVSEobQacJ0Xs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709193775; c=relaxed/simple; bh=7k/vpqip6N2vOj8cgKjOPE36pEsJVMgA/FdZblV+Xl8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=DRma3zYvYK3N0uI2o5ArEy+zON1AIFZPpWF4QCd3imFTHmN5R7Uam4AALngODQoiv3pnlhFB3TsH5OVgK/6hwLTg3+m5TXQ6JK7XbqtEfNAS28zkQ9TrwZoVJGA97zabIRL2j/YtXKP+4lAx7DCTQ9TzUJcnS07ubnuRsH3J4oQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57A78C433C7; Thu, 29 Feb 2024 08:02:51 +0000 (UTC) Message-ID: <03f65fbc-9cf8-4347-8277-e53cb01b00a5@xs4all.nl> Date: Thu, 29 Feb 2024 09:02:49 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/9] media: v4l2-subdev: Add a pad variant of .query_dv_timings() Content-Language: en-US, nl To: =?UTF-8?Q?Pawe=C5=82_Anikiel?= Cc: airlied@gmail.com, akpm@linux-foundation.org, conor+dt@kernel.org, daniel@ffwll.ch, dinguyen@kernel.org, krzysztof.kozlowski+dt@linaro.org, maarten.lankhorst@linux.intel.com, mchehab@kernel.org, mripard@kernel.org, robh+dt@kernel.org, tzimmermann@suse.de, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, chromeos-krk-upstreaming@google.com, ribalda@chromium.org References: <20240221160215.484151-1-panikiel@google.com> <20240221160215.484151-2-panikiel@google.com> From: Hans Verkuil In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 28/02/2024 16:34, Paweł Anikiel wrote: > On Wed, Feb 28, 2024 at 12:25 PM Hans Verkuil wrote: >> >> Hi Paweł, >> >> On 21/02/2024 17:02, Paweł Anikiel wrote: >>> Currently, .query_dv_timings() is defined as a video callback without >>> a pad argument. This is a problem if the subdevice can have different >>> dv timings for each pad (e.g. a DisplayPort receiver with multiple >>> virtual channels). >>> >>> To solve this, add a pad variant of this callback which includes >>> the pad number as an argument. >> >> So now we have two query_dv_timings ops: one for video ops, and one >> for pad ops. That's not very maintainable. I would suggest switching >> all current users of the video op over to the pad op. > > I agree it would be better if there was only one. However, I have some concerns: > 1. Isn't there a problem with backwards compatibility? For example, an > out-of-tree driver is likely to use this callback, which would break. > I'm asking because I'm not familiar with how such API changes are > handled. It's out of tree, so they will just have to adapt. That's how life is if you are not part of the mainline kernel. > 2. If I do switch all current users to the pad op, I can't test those > changes. Isn't that a problem? I can test one or two drivers, but in general I don't expect this to be a problem. > 3. Would I need to get ACK from all the driver maintainers? CC the patches to the maintainers. Generally you will get back Acks from some but not all maintainers, but that's OK. For changes affecting multiple drivers you never reach 100% on that. I can review the remainder. The DV Timings API is my expert area, so that shouldn't be a problem. A quick grep gives me these subdev drivers that implement it: adv748x, adv7604, adv7842, tc358743, tda1997x, tvp7002, gs1662. And these bridge drivers that call the subdevs: cobalt, rcar-vin, vpif_capture. The bridge drivers can use the following pad when calling query_dv_timings: cobalt: ADV76XX_PAD_HDMI_PORT_A rcar_vin: vin->parallel.sink_pad vpif_capture: 0 The converted subdev drivers should check if the pad is an input pad. Ideally it should check if the pad is equal to the current input pad since most devices can only query the timings for the currently selected input pad. But some older drivers predate the pad concept and they ignore the pad value. Regards, Hans