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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D10D3C433F5 for ; Thu, 11 Nov 2021 09:50:59 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8A93461152 for ; Thu, 11 Nov 2021 09:50:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8A93461152 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=microchip.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Content-ID:In-Reply-To: References:Message-ID:Date:Subject:To:From:Reply-To:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=P2jVn8Zc4wD6sZ3TPxnN70OCaLBkE2YTqNk2xYQekY8=; b=pE4mRV0aqgg9DN 2FjJ+nmcX19GAmyglQm4ZnUtuku82Ug+Go0V3mzsbSeRnfj+xFst3G+6qYDEBYQ5ANzQuuBFBbpen mm7KdYPY6QwPRA/alYfBh/zxwfLeC76kU5Np32iUXCc1kes/be5xKS1NohgrIm9eh+JwKI2Aemtay BnCZlMn2tMKkE+dg7/i3YMjwZf4SaQRr3l48mVVYvuTsPUATKuPYPqAGiObXXb1A0MP1Na+1aBbdV KiLyWgBO4sNnHP1HGf8F7bIasCHQmSlrMvwuSAG9j8FGkQUhtsHwqcdxPk7Slwzs8Z+i3B65QPRQP PDkgBPrhMP87c9A3RyeQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ml6i4-007btX-Hr; Thu, 11 Nov 2021 09:49:32 +0000 Received: from esa.microchip.iphmx.com ([68.232.153.233]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ml6i0-007bs2-7u for linux-arm-kernel@lists.infradead.org; Thu, 11 Nov 2021 09:49:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1636624168; x=1668160168; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=38XHGyn6wqPj+wjNz2Kv9iuu2sK+8M2EhFZf340oHg4=; b=RhYu2Kn4K5ZwFvcoHQDvmTjLljMxtYARqv625YGNzZzDVBPFKwEpUyPD 9fZLwM4Xh6tJbNjqlap6aubrP4teVc6a5gosKg6xhRRkNR0+3aai9lSN2 9KK1RBH7XNMG1X8p9oH1utWP/tZpoMQksSX+hJtPWKPeSDLhPsOwk3CC+ CjG+vUEMWD+6wUaknMlbkCHEYLsOxppPsHB2nkZVpNymAxuVL/xiJ7cvy GVxIJAIvapI6aYyY+CV2Eypey4ubf0dM7d7nFTfLdV3YM0opNriCWHY3N OuQplD2H9dXv1U+2uKpZ8tqXmtrpfEghutKajqzih/a5+KGRJ7i9+vHtg Q==; IronPort-SDR: iMM4+LhcuQ2IZzQgqgtfytSRMnIryGi6ve0HWWrHNLXqJ5hgvLvjfS9xN+wdkkiyAntxvKEdMZ 3TFjMrvTOAjhWDGH8hMBBXjBh+u8qsLZGo8KWO7t/wWn/oZOaZxdzAEmVlzl09A5MHPHZNUuL7 k/piZD68jCFF8E6H71TFK0egRlV8CnAPjUpaSezY1I2nKUaymw1qYg+ArktVruZyfVsqsqH4Pb qrotD0IIfcZ2HHQ9jcvi047Z0/M3trIuJ8n0ZslpNNHnPZeCwqljXlr628cRV8rP87xryc+JLm CjgoVFo/oXFhPcK5T5C+3Ory X-IronPort-AV: E=Sophos;i="5.87,225,1631602800"; d="scan'208";a="151565127" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa1.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 11 Nov 2021 02:49:25 -0700 Received: from chn-vm-ex04.mchp-main.com (10.10.85.152) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 11 Nov 2021 02:49:25 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (10.10.215.89) by email.microchip.com (10.10.87.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14 via Frontend Transport; Thu, 11 Nov 2021 02:49:25 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dggULYT7wfcSa+baDiyE6jsfUcOIhb/LQhbEuat6AKxhfuOb1sAjKEI8ZXSCvHe8EHsQ6V+8cz9ou4fyiXiZ4CiDJ3MCD4esUHjuE4dSyjCkontutYCUl6k1CEOVFwQWdR+SKxyrs8kp6OMDZphcZqzhU7QVVjuVVtS7VJrdT0vOLQSBum9mNLZN/RWK0Xdbg1AG/OY1Pr685mFkmNsxBO2W/jEvUYv6KZMPzJ+N1ryjGLlGtcSEcf9MHpDRYo6bFI5laaQFLZIi8/K1Ql0OUU/NXyZKp/LZMZ951dH+vV8HTdia/Gj1OHbnZxnM8I7xly9t0HbHhsUayyG1FWznGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=38XHGyn6wqPj+wjNz2Kv9iuu2sK+8M2EhFZf340oHg4=; b=If4wUMhkEg6X2zZw5+xenIWiySc+VmKAQfBgNtBnn3bhw5osBCk2w+W6EY+AifqJpDt+WHosXx0a4gBokh4nphn66V8qfdasggBJURtfNS4UxoL+AJ68BeFfmNBBhT+boLZPUFZzeEFRKfscFgVQWUqccRSTmFZN+cbXBri4TJXVvJL5KZK3IGHY6x380T7P6MgyWxRplBODGGOZOdX2PpkjJFCNgiBTOmX2Ec0yqcYeYmbyuXYpDFqe6xSKk5mHcNeBQW5U17rKNk5y+iiNtHqhDxHojS0DsESmC+Yluf7fdJQmd6dqQd4JAc/iW8/J/obhV3wGDu6qr3dAQgZf/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microchip.com; dmarc=pass action=none header.from=microchip.com; dkim=pass header.d=microchip.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microchiptechnology.onmicrosoft.com; s=selector2-microchiptechnology-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=38XHGyn6wqPj+wjNz2Kv9iuu2sK+8M2EhFZf340oHg4=; b=AZRa1hibMpqE1ac5XZwsMfzlFp16LBJWbrLtnW/jvRaIfoAzHpZ/VEjgJQ3+a4XpHhwKPMkBabXFu0G4vT08A5MHC6qHgW4GuepBBMbptsYWuy1QMcO94nklbIvCIMe+eI1RE5JTHqpubDpuKyAEiorKSvnrDSapgHsZzBspcs0= Received: from BN9PR11MB5514.namprd11.prod.outlook.com (2603:10b6:408:103::7) by BN7PR11MB2820.namprd11.prod.outlook.com (2603:10b6:406:b5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.16; Thu, 11 Nov 2021 09:49:18 +0000 Received: from BN9PR11MB5514.namprd11.prod.outlook.com ([fe80::5933:9a3c:4793:c21]) by BN9PR11MB5514.namprd11.prod.outlook.com ([fe80::5933:9a3c:4793:c21%7]) with mapi id 15.20.4690.019; Thu, 11 Nov 2021 09:49:18 +0000 From: To: Subject: Re: [PATCH 11/21] media: atmel: atmel-isc-base: implement mbus_code support in enumfmt Thread-Topic: [PATCH 11/21] media: atmel: atmel-isc-base: implement mbus_code support in enumfmt Thread-Index: AQHXxxoS1Gy/4w2cQESQ0fKslgfHtKv0wBWAgAAHHgCAABQZAIAEu6+AgAAu5YCABG60gA== Date: Thu, 11 Nov 2021 09:49:18 +0000 Message-ID: <2980afd7-6dcb-859c-cf53-a62ee5dc09e7@microchip.com> References: <20211022075247.518880-1-eugen.hristev@microchip.com> <20211022075247.518880-12-eugen.hristev@microchip.com> <20211105092559.ce6pdm4hwvxkmutd@uno.localdomain> <20211105095128.7tu4rm6mogwy2dz6@uno.localdomain> <60f0d378-d998-464f-2d95-09db4e889b96@microchip.com> <20211108112011.j4wi2z7hcibot6pz@uno.localdomain> <75196668-fbcb-1b31-55ce-46e32a3a675d@microchip.com> In-Reply-To: <75196668-fbcb-1b31-55ce-46e32a3a675d@microchip.com> Accept-Language: en-US, ro-RO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microchip.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2663c1ee-5e3a-47d2-5fba-08d9a4f887b9 x-ms-traffictypediagnostic: BN7PR11MB2820: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WbKuEn2uZI0Pwa6J+xorCn2wfMLCSJry2t8uABBAbS41b2WsCcrbHRPVlZcfZjD9aNvKAbs2EPd0H/l0z96FpSKAzpboyzGRI4T7W9MQ20mkRiSj+F/7DqEojxsK0ekQbbvKW22eXhYvueaAQUFtoq1e1kObYaprUsz2sccQ69DeCZumUQMJMyuu5YxtADZoTgkRVaSlK7D8H/lF6gn08kAN33wX+hyLGBoOQcydSQZ9W5tQ635OBdlyGiim7+KhoqJDWgnEaj4VWn+nDd7vKI+xGBB/HnWFZwCzeOhQomjjWSSD2newOl4JRb7nPBpVLUhdfQwPwUrnT1k9oKOfMEq7yZOxSZ64z1dwWyK5HHaEW7KS0zgMeeJRcusI9+VOaggNt0uuRwlFO3P2hxqjWIGxBFpuQlZtHXuJ3K1c2P5OIDRoJMi3SSxpB2QN6L0UJKbBiWXx4jLyhIV63kDGx6oZb3W3MRM+ytPf4bWNKHsdDzmuike7UWL1Cx92p86uLTieEcESsqmo2vApN8R9g3tu1TmGvEwhc7mkw/Cxfb7r3nrplvnLkoQYIAkiPhfld8S21xlwIZqA3JKURlR8rBKIVYnyruFnKM7fFPzsX0tmdrYQal5EZP9JwZHW1svMtPjJL99dhrYxUSq/RdJSWRHTzQIkCMYeNJQC4l+wVLoYdAYMVFYvt/7Xws18yLW0J1BhIjCFQsx7E34uNFey4s0A6uYfvHtDvQDixaH0/c9JZwt5aVappInMwU4yE1R4FAp5vLBZoehW5zMwI50Vsw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN9PR11MB5514.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(4326008)(71200400001)(6916009)(186003)(6512007)(38100700002)(107886003)(30864003)(26005)(83380400001)(86362001)(54906003)(31686004)(2616005)(316002)(6506007)(2906002)(53546011)(508600001)(66476007)(64756008)(8936002)(66556008)(6486002)(31696002)(122000001)(66946007)(8676002)(66446008)(5660300002)(91956017)(38070700005)(36756003)(76116006)(45980500001)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UzhRa0pZVTAxWndodVVzQmNMVVFwOEl6bTd2U3NMd0J3TW5yaWt5NzdyZHJw?= =?utf-8?B?VVRCNWpHdnBLaXBCRmo5VlV6VjFFbTRGc2d4ME82V1g4TEJBMlY0akYyR3RK?= =?utf-8?B?Umt0V3pWSUp4V1p4akZjcE1lcXpxekhYODdxc2padmJUamJhUjFTOTFEZm1k?= =?utf-8?B?MzRrMzljcDFtdC8wSys0T050U1lFd3dUQzliNGRtVll1NDBZakR3UDJtKy9Y?= =?utf-8?B?d0R2UWpRQk45aENXbyt1WnFzWlhOVURCUjQ2M0ZGZkNBU0Z0MDNjR2F4TnZt?= =?utf-8?B?bnN1amRMb29LdjB0SUNMQTJ3RnRoQnBhbjAyZzBKejJnQStYaVkxMkZxNy9M?= =?utf-8?B?djh3SVZWbDhIUHVKZytmM1VBL1pBVzB5NWVCMEdNeitaR2JwOWpiMWs4Sll0?= =?utf-8?B?RkJLVVhCVlFKYXp2UmdsclVvc3JYbGJUVld6MEU0b3pkSHBIYXc3WG1pNHVr?= =?utf-8?B?eExrU2RRRDgraWlKc3ZSUEF0Sk94WlRQZU0xWG93YTR0S3o0U2J0QVNkNUpY?= =?utf-8?B?YUlZVGlML0NLUFRDYk9mcHVOOVpPclQrR0NBdFM0Y3ArY09CV20rYSt6cGhS?= =?utf-8?B?WTU0Q0dheVgvcW9MRkc4M2FVRll1RWdJU0hTV3RDdzYzZEc1SUs3aWR5UWUr?= =?utf-8?B?UzJNQzduM01xdjg4Q253QjRicWRaZjErRTR2NU5nd3g1OE9YYnFFcnJCd1JM?= =?utf-8?B?THFmaXRoUWlRb3JjK2JnNmdYd0poTE5pYnRpdjVQdCtjdEJ5WTF2aVB1ajc0?= =?utf-8?B?ci9NUGVGbVhUZjdValFFRWlDRUo4MmYrYmZnOUhYWE1paWhMSTE1Vi9IblFH?= =?utf-8?B?T1E4RTMxR0YyWnhwZlk2MEVpd1BsWWNycDI3U2djSytqTWZ3d1pzVWg2U3pm?= =?utf-8?B?R0o3OE9WOGJmeTlIQzBSVHc4WGhSUEh4S1JRcUZuSkNuTnBzbDlnVkRHemVP?= =?utf-8?B?YTZlc25GTm9pM0t1Mk9DOEx6NXNnTEl5QjNkdElqOXdEeVArcjVxUk9KS0Iy?= =?utf-8?B?VGt2NXRqNUR0bGY3anlHUEJuU2xSOWdnNm0zeXVWMEtuT21HengzbDYvbkFy?= =?utf-8?B?WWlMdlJhU25oc3ltQ0NNd3YzZ1BwT3h6cHVtZjA3YWJGSExORVBMcmhRZHkv?= =?utf-8?B?aGQ5S2d0aUZLdHhvbzhvbk84ajBwOFhJVjV1dEpMTUtmREhDZForbkZraFNI?= =?utf-8?B?OGFHVWRXR3Z1SUJMdlRIbDVLaHFsOHFKM1l2bUNaMjI3ZlBoa05ud3FwRE9T?= =?utf-8?B?SWJxeGNrY1BRb3VQd0IrR0R5djBRbWhzYUdXVEt6SSt3aGNQOGxKMVpIM1BT?= =?utf-8?B?R1UzRWd5MGQ5YmRoVk8zYWU5RkZIQlpzQkFVb2lvbGtSSTVPSGw0Y0crY3RU?= =?utf-8?B?MTlaUmtQUHZvTXhaZTdNTUJlaFp3YjZQenpZbGtsRFdsdll5bE1mYWxocjh5?= =?utf-8?B?YWJaSkhrTWFOQ2srYk15SXBkWHNpNkVyVStwVm1iS3dwcEtzMFJ3eFFWQWtQ?= =?utf-8?B?Mzk2ZFpWa3JMVXI1UStoQjhOdmUxRE44ZkFCT1FyMThKWGYzUWJpbFdEc3Bp?= =?utf-8?B?MVYzNlpZdG0yTE5uYnEvQVZNOUJjTXZHSDNjcStyTEFBZEJ6SXVYQWNYZzZw?= =?utf-8?B?MlJoVkVFbHZPMWE2N1UzR1VnOHlMNFdMTjFTTmZpcm1YaldJRkxEU3hTUmZL?= =?utf-8?B?RDVvTmhwdlRNL0xBRWRyU1JTZWpDSkNLRlIvaFJJdVNnNDZSK2F4OHFUajYv?= =?utf-8?B?eHMxQkgyZmpwbXlvNnBUSXVOU0JqVFUwb2U0Z2JPVlA5SExkVWpKc21LWmJm?= =?utf-8?B?MmFZd0pzUUNEOUlDOTRndS9ENVcweDgxTkpMK2R4bnFsSEFkRkpJQ0VzU085?= =?utf-8?B?Tlh5eXpaUkYyOGh6NzdSSE5mKzFpbUNjcUlxSzNaNWFkbm12QjhCYlBpWW1a?= =?utf-8?B?RllPSkNlU3VZY1Q5Ti84RjFvNjI4bnBwYk1XSGg3UzkxN1dOYmJQcGZYZldB?= =?utf-8?B?Qi9sQm9JajFwVXMrdzVMQnpWZFRUN3VZbEFjVDNVanVGZlZsTFk4Z3RoSEMx?= =?utf-8?B?RkdBZVZ5OU5zdkJUT0ZFeWNXNDRrVkJtUGJPbGltNlRhSkVGbW5TTzVJRVds?= =?utf-8?B?c0VyY2ZhTTBSaDdhRk1sT0hMWTFjemhna2JXNlpoTy9DeVN5SUtIVXBoM0Nw?= =?utf-8?B?cmVzZlhobmUyMHN3Y1dnaGdWNHI1bTk4UDVjT0Z4d05GOTNlSldxSk5GWENX?= =?utf-8?B?Q1B6U1ZJRU5jVVQzWnBxYTdQWWhRPT0=?= Content-ID: MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5514.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2663c1ee-5e3a-47d2-5fba-08d9a4f887b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2021 09:49:18.4458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YTjShcPuSfpLNXY0UM9QXq8xMDfWfqYn6PgZW/XQp4jnrIaugzbJk+hYluq92dzHp1WvoNVE5vtbsY80NLqDzxkK87nBY633dx5h6blSS90= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2820 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211111_014928_422723_A6D2AFFA X-CRM114-Status: GOOD ( 22.36 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, sakari.ailus@iki.fi, laurent.pinchart@ideasonboard.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 11/8/21 4:08 PM, Eugen Hristev - M18282 wrote: > On 11/8/21 1:20 PM, Jacopo Mondi wrote: >> Hi Eugen >> >> On Fri, Nov 05, 2021 at 11:03:25AM +0000, Eugen.Hristev@microchip.com wrote: >>> On 11/5/21 11:51 AM, Jacopo Mondi wrote: >>>> Hi Eugen >>>> >>>> On Fri, Nov 05, 2021 at 10:25:59AM +0100, Jacopo Mondi wrote: >>>>> Hi Eugen, >>>>> >>>>> On Fri, Oct 22, 2021 at 10:52:37AM +0300, Eugen Hristev wrote: >>>>>> If enumfmt is called with an mbus_code, the enumfmt handler should only >>>>>> return the formats that are supported for this mbus_code. >>>>>> To make it more easy to understand the formats, changed the report order >>>>>> to report first the native formats, and after that the formats that the ISC >>>>>> can convert to. >>>>>> >>>>>> Signed-off-by: Eugen Hristev >>>>> >>>>> Reviewed-by: Jacopo Mondi >>>>> >>>> >>>> Too soon! Sorry... >>>> >>>>> Thanks >>>>> j >>>>> >>>>>> --- >>>>>> drivers/media/platform/atmel/atmel-isc-base.c | 51 ++++++++++++++++--- >>>>>> 1 file changed, 43 insertions(+), 8 deletions(-) >>>>>> >>>>>> diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c >>>>>> index 2dd2511c7be1..1f7fbe5e4d79 100644 >>>>>> --- a/drivers/media/platform/atmel/atmel-isc-base.c >>>>>> +++ b/drivers/media/platform/atmel/atmel-isc-base.c >>>>>> @@ -499,21 +499,56 @@ static int isc_enum_fmt_vid_cap(struct file *file, void *priv, >>>>>> u32 index = f->index; >>>>>> u32 i, supported_index; >>>>>> >>>>>> - if (index < isc->controller_formats_size) { >>>>>> - f->pixelformat = isc->controller_formats[index].fourcc; >>>>>> - return 0; >>>>>> + supported_index = 0; >>>>>> + >>> >>> Hi Jacopo, >>> >>> This for loop below first iterates through the formats that were >>> identified as directly supported by the subdevice. >>> As we are able in the ISC to just dump what the subdevice can stream, we >>> advertise all these formats here. >>> (if the userspace requires one specific mbus code, we only advertise the >>> corresponding format) >>> >>>>>> + for (i = 0; i < isc->formats_list_size; i++) { >>>>>> + if (!isc->formats_list[i].sd_support) >>>> >>>> >>>>>> + continue; >>>>>> + /* >>>>>> + * If specific mbus_code is requested, provide only >>>>>> + * supported formats with this mbus code >>>>>> + */ >>>>>> + if (f->mbus_code && f->mbus_code != >>>>>> + isc->formats_list[i].mbus_code) >>>>>> + continue; >>>>>> + if (supported_index == index) { >>>>>> + f->pixelformat = isc->formats_list[i].fourcc; >>>>>> + return 0; >>>>>> + } >>>>>> + supported_index++; >>>>>> } >>>>>> >>>>>> - index -= isc->controller_formats_size; >>>>>> + /* >>>>>> + * If the sensor does not support this mbus_code whatsoever, >>>>>> + * there is no reason to advertise any of our output formats >>>>>> + */ >>>>>> + if (supported_index == 0) >>>>>> + return -EINVAL; >>>> >>>> Shouldn't you also return -EINVAL if index > supported_index ? >>> >>> No. If we could not find any format that the sensor can use >>> (supported_index == 0), and that our ISC can also use, then we don't >>> support anything, thus, return -EINVAL regardless of the index. >>> >>>> >>>> In that case, I'm not gettng what the rest of the function is for ? >>>> >>> >>> This is the case when we identified one supported format for both the >>> sensor and the ISC (case where supported_index found earlier is >= 1) >>> >>>>>> + >>>>>> + /* >>>>>> + * If the sensor uses a format that is not raw, then we cannot >>>>>> + * convert it to any of the formats that we usually can with a >>>>>> + * RAW sensor. Thus, do not advertise them. >>>>>> + */ >>>>>> + if (!isc->config.sd_format || >>>>>> + !ISC_IS_FORMAT_RAW(isc->config.sd_format->mbus_code)) >>>>>> + return -EINVAL; >>>>>> >>> >>> Next, if the current format from the subdev is not raw, we are done. >> >> Ok, I think here it's were I disconnect. >> >> I don't think you should care about the -current- format on the >> subdev, as once you move to MC the ISC formats should be enumerated >> regardless of the how the remote subdev is configured. Rather, you >> should consider if IS_RAW(f->mbus_code) and from there enumerate the >> output formats you can generate from raw bayer (in addition to the >> ones that can be produced by dumping the sensor produced formats) > > Actually , in some words, this is what I am doing. > I am following Laurent's advice: > enumerate the formats supported for a given mbus code. > > In consequence, if the mbus code given is a raw mbus code , I can > advertise all my ISC formats, and if the mbus code is not raw, I don't . > > So I am doing what you are saying, namely three cases: > > If there is no mbus code given as a parameter to this function, I > advertise all my formats, raw, non-raw, etc. > > If there is raw mbus code given, I advertise this specific raw mbus code > if the sensor supports it, and the ISC supports it, and in addition, all > the formats ISC can convert from raw to. > > If the mbus code given is not raw, then, I can only advertise this > specific non-raw format, since there is nothing more I can do with it. > It wouldn't make much sense to still advertise my rgb,yuv formats, since > they cannot be used at all, and my later try_validate_formats will bail out > > >> >>> But, if it's raw, we can use it to convert to a plethora of other >>> formats. So we have to enumerate them below : >>> >>> With the previous checks, I am making sure that the ISC can really >>> convert to these formats, otherwise they are badly reported >>> >>> Hope this makes things more clear, but please ask if something looks strange >>> >> >> I think our disconnection comes from the way the supported formats are >> defined in ISC and I think their definition could be reworkd to >> simplify the format selection logic. >> >> The driver defines three lists of formats: >> >> - isc->controller_formats >> >> static const struct isc_format sama7g5_controller_formats[] = { >> { >> .fourcc = V4L2_PIX_FMT_ARGB444, >> }, >> { >> .fourcc = V4L2_PIX_FMT_ARGB555, >> }, >> ... >> >> }; >> >> These are listed with the output fourcc only, and if I get >> try_configure_pipeline() right, they can be generated from any Bayer >> RAW format. Is this right ? >> >> - isc->formats_list >> >> static struct isc_format sama7g5_formats_list[] = { >> { >> .fourcc = V4L2_PIX_FMT_SBGGR8, >> .mbus_code = MEDIA_BUS_FMT_SBGGR8_1X8, >> .pfe_cfg0_bps = ISC_PFE_CFG0_BPS_EIGHT, >> .cfa_baycfg = ISC_BAY_CFG_BGBG, >> }, >> { >> .fourcc = V4L2_PIX_FMT_SGBRG8, >> .mbus_code = MEDIA_BUS_FMT_SGBRG8_1X8, >> .pfe_cfg0_bps = ISC_PFE_CFG0_BPS_EIGHT, >> .cfa_baycfg = ISC_BAY_CFG_GBGB, >> }, >> >> ... >> >> }; >> >> These are formats the ISC can output by dumping the sensor output, >> hence they require a specific format to be output from the sensor >> >> - isc->user_formats >> >> static int isc_formats_init() { >> >> ... >> >> fmt = &isc->formats_list[0]; >> for (i = 0, j = 0; i < list_size; i++) { >> if (fmt->sd_support) >> isc->user_formats[j++] = fmt; >> fmt++; >> } >> >> } >> >> this list is obtained at runtime by restricting the formats_list to >> what the sensor can actually output. I think these, if you move to >> MC should be removed but I'm not 100% sure it is possible with the >> current implementation of set_fmt(). >> >> Do you think controller_formats and formats_list should be unified ? >> >> If my understanding that all controller_formats can be generated from >> RAW Bayer formats you could model struct isc_format as >> >> struct isc_format { >> u32 fourcc; >> bool processed; >> u32 mbus_codes >> u32 cfa_baycfg; >> u32 pfe_cfg0_bps; >> }; >> >> and have in example: >> >> { >> .fourcc = V4L2_PIX_FMT_ARGB444, >> .processed = true, >> .mbus_codes = nullptr, >> .... >> }, >> { >> .fourcc = V4L2_PIX_FMT_SBGGR8, >> .processed = false, >> .mbus_codes = { MEDIA_BUS_FMT_SBGGR8_1X8 } >> .pfe_cfg0_bps = ISC_PFE_CFG0_BPS_EIGHT, >> .cfa_baycfg = ISC_BAY_CFG_BGBG, >> }, >> >> and when enumerating and configuring formats check that >> >> if (isc_format[i].processed && >> (f->mbus_code && IS_RAW(f->mbus)code)) >> >> or >> >> if (!isc_format[i].processed && >> (f->mbus_code == isc_format[i].mbus_code >> >> if you have other restrictions as in example V4L2_PIX_FMT_YUV420 >> requiring a packed YUV format, you can implement more complex >> validations to match processed formats, like you do in try_validate_formats() >> >> Also, and a bit unrelated to enum_fmt, if I got this right >> at format configuration time you match the ISC format with >> the sensor format. I think this should be moved to .link_validate() op time. >> >> The MC core calls .link_validate when streaming is started on each >> entity part of a pipeline, and there you could make sure that the ISC output format can be produced using >> the sensor format (and sizes). This will greatly simplify set_fmt() as >> there you will have just to make sure the supplied format is in the >> list of the ISC supported ones and that's it. If userspace fails to >> configure the pipeline correctly (in example by setting a non RAW >> Bayer sensor on the format and requesting a RAW Bayer format from ISC, >> you will fail at s_stream() time by returning an EPIPE. Hi Jacopo, I tried to look over the link_validate call. It looks like this is only called by media_pipeline_start, which most drivers use in start_streaming() . However, I need the format validation to be done before that, at streamon() time, because after streamon() , the vb2 queue will be filled with buffers, and I need to know exactly which format I will be using. So, do you think it's fine to keep the format validation at streamon() time instead of calling media_pipeline_start in start_streaming ? Currently I am not calling media_pipeline_start at all. Do you think it's required? Or maybe I am missing something and it should be done in a different way ? Thanks ! >> >> Hope all of this makes a bit of sense :) > > About this last part you are telling me: I have to tell you what am I > doing right now: with this patch series, including this patch, I am > adding support for mc handling in this driver, but! the driver is still > completely compatible with 'the old way' like setting fmt-video for > /dev/video0 and everything is propagated down the pipeline. > > I am doing the conversion to mc-only type of driver in multiple steps. > This series adds the 'new way' while having the 'old way' still there. > At the moment I am working on another patch on top of this series that > will basically remove most of my format propagation logic from > /dev/video0 to the subdevice, and after this patch that is on the way, > the 'old way' is gone. The sensor will *have to* be configured through > userspace because ISC will never call set_fmt on it at all. > > So the purpose of the patch you are reviewing now is to have the mbus > code parameter in the enum_fmt_vid_cap in the way the current driver > handles things. > > So if you agree, I will let the other patch speak for itself and rework > the logic completely . > I am currently trying to do it at streamon() time like Laurent told me, > but I can try to have it at validate link as well, to see how it works. > > I will add that patch to the series when it's ready and I have a v2 of > this series as well. So in baby steps, I am working towards the goal. I > am not sure if this means that you could agree to this patch as-is, or I > have to integrate it completely into a bigger patch that will also fix > everything up including the format logic. > > Thanks again for your review and ideas > > Eugen >> >>>>>> + /* >>>>>> + * Iterate again through the formats that we can convert to. >>>>>> + * However, to avoid duplicates, skip the formats that >>>>>> + * the sensor already supports directly >>>>>> + */ >>>>>> + index -= supported_index; >>>>>> supported_index = 0; >>>>>> >>>>>> - for (i = 0; i < isc->formats_list_size; i++) { >>>>>> - if (!ISC_IS_FORMAT_RAW(isc->formats_list[i].mbus_code) || >>>>>> - !isc->formats_list[i].sd_support) >>>>>> + for (i = 0; i < isc->controller_formats_size; i++) { >>>>>> + /* if this format is already supported by sensor, skip it */ >>>>>> + if (find_format_by_fourcc(isc, isc->controller_formats[i].fourcc)) >>>>>> continue; >>>>>> if (supported_index == index) { >>>>>> - f->pixelformat = isc->formats_list[i].fourcc; >>>>>> + f->pixelformat = >>>>>> + isc->controller_formats[i].fourcc; >>>>>> return 0; >>>>>> } >>>>>> supported_index++; >>>>>> -- >>>>>> 2.25.1 >>>>>> >>> > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel