From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from galahad.ideasonboard.com ([185.26.127.97]:49679 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751768AbeBDNN2 (ORCPT ); Sun, 4 Feb 2018 08:13:28 -0500 From: Laurent Pinchart To: Hans Verkuil Cc: Linux Media Mailing List , Mauro Carvalho Chehab Subject: Re: MEDIA_IOC_G_TOPOLOGY and pad indices Date: Sun, 04 Feb 2018 15:13:52 +0200 Message-ID: <2979437.fEFkWIelBg@avalon> In-Reply-To: <336b3d54-6c59-d6eb-8fd8-e0a9677c7f5f@xs4all.nl> References: <336b3d54-6c59-d6eb-8fd8-e0a9677c7f5f@xs4all.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-media-owner@vger.kernel.org List-ID: Hi Hans, On Sunday, 4 February 2018 15:06:42 EET Hans Verkuil wrote: > Hi Mauro, > > I'm working on adding proper compliance tests for the MC but I think > something is missing in the G_TOPOLOGY ioctl w.r.t. pads. > > In several v4l-subdev ioctls you need to pass the pad. There the pad is an > index for the corresponding entity. I.e. an entity has 3 pads, so the pad > argument is [0-2]. > > The G_TOPOLOGY ioctl returns a pad ID, which is > 0x01000000. I can't use > that in the v4l-subdev ioctls, so how do I translate that to a pad index in > my application? > > It seems to be a missing feature in the API. I assume this information is > available in the core, so then I would add a field to struct media_v2_pad > with the pad index for the entity. > > Next time we add new public API features I want to see compliance tests > before accepting it. It's much too easy to overlook something, either in > the design or in a driver or in the documentation, so this is really, > really needed IMHO. I agree with you, and would even like to go one step beyond by requiring an implementation in a real use case, not just in a compliance or test tool. On the topic of the G_TOPOLOGY API, it's pretty clear it was merged too hastily. We could try to fix it, but given all the issues we haven't solved yet, I believe a new version of the API would be better. -- Regards, Laurent Pinchart