Message ID | 20240206-onboard_xvf3500-v3-6-f85b04116688@wolfvision.net |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-55073-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:168b:b0:106:860b:bbdd with SMTP id ma11csp1555737dyb; Tue, 6 Feb 2024 06:02:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IGXYZrVBaWt3+w96mSik5Fi7UXDs9MRWlE0+c2D+7gJZ1WulkWeoZxbyYn2DJ4WP9tPCiJ0 X-Received: by 2002:a25:9709:0:b0:dbc:d57f:4632 with SMTP id d9-20020a259709000000b00dbcd57f4632mr1519142ybo.61.1707228159759; Tue, 06 Feb 2024 06:02:39 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCVc00qNhbF2A00fwx/izRVJwh6FCiwq4tZuU8EvrJe5BF0LtzqWAvBrVaNY6geHXkPfNM7lPJ3ijvoHtIhIiMvcYjBMtA== Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id d34-20020a253622000000b00dc6d2e9fd6dsi1168940yba.89.2024.02.06.06.02.39 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Feb 2024 06:02:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-55073-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@wolfvision.net header.s=selector2 header.b=Jx8FC6Jk; arc=fail (signature failed); spf=pass (google.com: domain of linux-kernel+bounces-55073-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-55073-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=wolfvision.net 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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 81C571C209A2 for <ouuuleilei@gmail.com>; Tue, 6 Feb 2024 14:02:33 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 15E47134CC0; Tue, 6 Feb 2024 14:00:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=wolfvision.net header.i=@wolfvision.net header.b="Jx8FC6Jk" Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on2132.outbound.protection.outlook.com [40.107.13.132]) (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 0331F1332A8; Tue, 6 Feb 2024 13:59:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.13.132 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707227995; cv=fail; b=BpwPD+cXFButVm+WDSRioWtyMTsm0MVa6ttJnRkduBW+ayECmCdSuhycdZCfmzkA0PihHlaPSaNzBD6lA5n0lMbEDYtaCP96X9XtQFb0y1WCb9HUOduAEsCOWomrs0WIhPWlZmBQ3rEvci7cHHi6wCX0ut84ge01mSrQtrBzXeY= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707227995; c=relaxed/simple; bh=P+pRhh18QK3BNTzJ/6eD6eokmpO/XHx3bEHFgHsEn2w=; h=From:Date:Subject:Content-Type:Message-Id:References:In-Reply-To: To:Cc:MIME-Version; b=tJdcNsz/+kMndrn+QOAWWDV4KcKCOroZuViROgxNgRZ3Aj6tIdIsnycNLNJuKFbaQq4meOSyjQ6Rz9ylPsDfFgHvTk8RJ68Al8OOTFhnVeZsoL5qCQ5WUopRdlOYIeIDPAp70H6zoRCWH5XZvIeqDNY+Z15NIBM0+7ev0bGsBVw= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=wolfvision.net; spf=pass smtp.mailfrom=wolfvision.net; dkim=pass (1024-bit key) header.d=wolfvision.net header.i=@wolfvision.net header.b=Jx8FC6Jk; arc=fail smtp.client-ip=40.107.13.132 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=wolfvision.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wolfvision.net ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ai1oQbRX/VUnXKscfA8HPVrbKz0oQX9ONK+dM8cRy3XIq23NsW3yH+KQXh1HAFLaTACpxDW7aGBj1O7Z8MzFGeIAi9ZUUl48XBr7FEAMWAOntJ/IyeJ2aYiO2f3UWa4Mm4xQhnvLisddRcziWuUaLgb04zOJZGCTaajMLHAu0DG+pqb/XgpSZostvW+Yrhe+tArYnDvjb9nkzRzy4QbVkFWZ2RldmgOjipzkRo9A6k0RXwBd/ze/K+PplQlCpz1htpMsRfotVNC6EOtkV3RqwbsIzi9GBfM8XfTLvpjXPTpDnrJ4PCR6gT3jQ0aqw6e0q8WkXWyrXBR9yjntTU6mqg== 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=KDxIaRZ7Ensmyd7vx7fG5DcGCLnp9dflFDxzCOd3Nlc=; b=IXOoGo1yqHDuZgo0WdZbdeBKlhPSeym8kPZCKFv0kjGuiq2uo1+Y1dZ1aW2MJwUOkvCS0VHP7Yv5Nd11CTD1Lnn8/8+qEP/Fv2o7ig4PP8NA1eE1Dj1qBcwXQqoF61cbSZmbd/6Rwl7KaEHmS9PdqmlibHgF4L46SHkyqBCOtVWHxm8M8JpxePJ+eGPxsDRMqBUqaASNHgfXpAGvAzCv9QYPaYM1rpIoljRaXIhTNwbpxc+6e5l58Mp54xJ1rIxVgRsOk1HT4uG3t3/ADgEzHEJ6SIH5jechv1YEX/RSO7Nx/zUyNywZSjaItyZZKxKVYi3lQzi1C+IbqGZnWZlGvQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wolfvision.net; dmarc=pass action=none header.from=wolfvision.net; dkim=pass header.d=wolfvision.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wolfvision.net; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KDxIaRZ7Ensmyd7vx7fG5DcGCLnp9dflFDxzCOd3Nlc=; b=Jx8FC6JkYRa8ra8kIbmIClfexR8orpjw82L6KssHDkS8VqHrmGcHP///VnlBBtFF0QA7bvi/gNcqYDPoubj0C8IVjUEGW1GbbINH/Qtbyub+jecmXsZPChxENLOM8mxJTV+4SGfCZsnVKwlyqWi63I0P/wZXl4OAlK0Ud2WVCi0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=wolfvision.net; Received: from VE1PR08MB4974.eurprd08.prod.outlook.com (2603:10a6:803:111::15) by DB9PR08MB6330.eurprd08.prod.outlook.com (2603:10a6:10:263::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.36; Tue, 6 Feb 2024 13:59:41 +0000 Received: from VE1PR08MB4974.eurprd08.prod.outlook.com ([fe80::c8ee:9414:a0c6:42ab]) by VE1PR08MB4974.eurprd08.prod.outlook.com ([fe80::c8ee:9414:a0c6:42ab%7]) with mapi id 15.20.7249.035; Tue, 6 Feb 2024 13:59:40 +0000 From: Javier Carrasco <javier.carrasco@wolfvision.net> Date: Tue, 06 Feb 2024 14:59:34 +0100 Subject: [PATCH v3 6/7] ASoC: dt-bindings: xmos,xvf3500: add XMOS XVF3500 voice processor Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20240206-onboard_xvf3500-v3-6-f85b04116688@wolfvision.net> References: <20240206-onboard_xvf3500-v3-0-f85b04116688@wolfvision.net> In-Reply-To: <20240206-onboard_xvf3500-v3-0-f85b04116688@wolfvision.net> To: Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Matthias Kaehlcke <mka@chromium.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-sound@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, Javier Carrasco <javier.carrasco@wolfvision.net> X-Mailer: b4 0.13-dev-0434a X-Developer-Signature: v=1; a=ed25519-sha256; t=1707227975; l=2060; i=javier.carrasco@wolfvision.net; s=20230509; h=from:subject:message-id; bh=P+pRhh18QK3BNTzJ/6eD6eokmpO/XHx3bEHFgHsEn2w=; b=ej2hYt/TrY9j5jwk/mH8mw4C8NG2n/tCPflsCLQ193/BHGdQ+bkVaIgOlHNJDCDjK85QAlK/b 2q+YBthLcnZDPA6pjNY9UHc/fsSqsqeIAKE+vGIUbmknl2n/X+HUp0j X-Developer-Key: i=javier.carrasco@wolfvision.net; a=ed25519; pk=tIGJV7M+tCizagNijF0eGMBGcOsPD+0cWGfKjl4h6K8= X-ClientProxiedBy: FR5P281CA0038.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:f3::8) To VE1PR08MB4974.eurprd08.prod.outlook.com (2603:10a6:803:111::15) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VE1PR08MB4974:EE_|DB9PR08MB6330:EE_ X-MS-Office365-Filtering-Correlation-Id: f886cddf-ba2b-4d68-46dc-08dc271bdd2b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SKMxH5UXokjvUDkdNHDtAKVkAvzbbaiEfLJ3I0qEPhUWYSRbMpmTkUxYZFjph1JqWZDM93dqMalzQn2FCysv0vPokNZ43+x9p7bk0lKwtw0xTwcuLUq1nA2YfVHjGs2/g0/jEYRLfbRYrAA83qWWh3CayHLn6RrzNg+c9Xf+qUsGo/T18CV2582KS+3VCrpsHUkVFN9aHeYx09jZm9BEIjesYsK4oZXkuWVExzta+8zDBiZMiXMLsYTOk2HA0n8rx9OGyb8vmr8MTbj0UsTCwTM567P+wpiIQL+LGzYZiDpogrlQYDRO5d2KZd1oBU2Ftc57DgaDbzLeY8yHr7r2TkH4wFk9tzvFV8nC9QqGF01MJZT2MNqiomCAfBD9H/nmyxT9vCgTKr/bkUl1cPceU4WaC/rTPAcK7F0T3WIweScUXHvEl/XYjRaturZyaTLDHRk9CMOrjK9m5It9NdDbNKgZK7qBDTbPqhD8/YlIqHeM38AJxwEeJANM4ldRzGkN/kVH11t+jGAGIf5lNZCUPLTZof7GEtl1FIS8uVEM+O55fPPdKiCcejEAWKDLfdtgQmRrWFxNfNnfDX1S5UmQwuLP0qXAKZ5eif/NxQuTKRU= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR08MB4974.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366004)(346002)(39850400004)(396003)(376002)(136003)(230922051799003)(186009)(64100799003)(451199024)(1800799012)(38100700002)(44832011)(26005)(2616005)(6486002)(966005)(107886003)(86362001)(6506007)(6666004)(478600001)(6512007)(52116002)(36756003)(316002)(38350700005)(41300700001)(66946007)(66556008)(66476007)(110136005)(8676002)(4326008)(2906002)(8936002)(5660300002)(7416002);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?q?sgnzlTMFg8yjqNGFcEAU7vN2IfQD?= =?utf-8?q?1Q+CsckMXkh+Q0AF9PXYMES3RBqFOvu2JyWUFE/ZGcRgnbZoCHrVSE75lxo8YFHvE?= =?utf-8?q?XHVk8F1GPL11eZLGp7SbuaG6Sk/7FMX+CaA6ikje4GrqUl4BBqD4pmaQvntlpn/rT?= =?utf-8?q?QCNbjIkeLkV8l2FN4QZ/oywnk0yqUS8B2Hwuf4RvHx2ZpE24IymMYEcsobpKPrtz+?= =?utf-8?q?Y6ZEBEO8GllBpT46/dzLaQ71y8a90RD1eGfbn01Dz6V8LferLnDHJpnUJ6fcU/ii6?= =?utf-8?q?njdUsjlIGc6TaoyS5VehRR5saInQXlVcDPx6xNfifnAfax5739wKVNojHybod5KEl?= =?utf-8?q?+zQX89BLCacnIRbX45Lx1GzIB3ug7QKiHo4u28sIsdkMGJD9rWX6l1dsdPJFUYm7e?= =?utf-8?q?PRs2+mt1nMRCc/4ZJdQncWWyP96b1x+CSDiYcMn3/8uDyrEAsCtv1YnF/nN9FFKe9?= =?utf-8?q?aLYMmuAVTz6jmy8p/26N9eeTyffX6Z5n5ugyb/KnIs+kJn4Weyg5j+kKxsLg3gOQP?= =?utf-8?q?NzVXu3H+Fp5q9LKrkgW/1ApHzUEEvr1ACqAHaCaHHyR1XM3yt10X5+PrskHYn2aAT?= =?utf-8?q?aLz6HB0lbY3u/adjqUw//Bs/yiNFX+i+vxzHLbXAEuI/Gi5n17Wlx7z4rimbIeugo?= =?utf-8?q?2IHO/W/+tYtd633NSJh+hetqggJUtwEiDahzVpH0OgjT4wbse7a1t6VexmIcJjNcG?= =?utf-8?q?8h6wex20hFUks68no4ISPPM76Wuc4ct3s/c3dXXmLaUkJH8lgMzaJgKYW9aVMmhjq?= =?utf-8?q?NdyIPviAtgbKJHoAIG32gMy6eUCsdlJeTSwYPBMuyWoo2cnABsTr2DEzMYVwvXGow?= =?utf-8?q?SsoU5RDmgEvzGHOtPPyQFCZzeC/5EnX8Trf7xGeaHxw+jdtDCQvg/nOvgEKkgC38I?= =?utf-8?q?Ny6WDtl4ZcMxm4USq7EsUOEHlGNIombCTkhiklrExfOHSOjjozmdJK37yhACl2hGq?= =?utf-8?q?jopKnBv3djxoSxU5G2D4NY1xnCVg8+OLSk8NAcZCvdCssX62Y6p5v3zK5qUusFy+V?= =?utf-8?q?aJOY9DfaGEdXUXPbZ3cOfvEvjJNFyiGhu1FOmlYXXMHVSNZq1M0jevhl0nYSU/XV8?= =?utf-8?q?PmNyVjcTTwYBtMEDWrCxAZL7RqzkIBn0KJe80WTXxcc5iwOs9ImkzEit8o+TFkUk1?= =?utf-8?q?UQR4I86xaQKLU0zFT6IpCsh6rIMNsrbl/btXDFxJR0b+jYNzD8fWz4gxpEOsKSVrO?= =?utf-8?q?ZjU5btUvH73CHjUn1NxuSDhflAJyUsM2ZgsL14tdbUJf5TyhTnHY3okYS2gHaWAsY?= =?utf-8?q?qDPXP96qMoiSZa+fgI2xuqdkua+CvaMXuQW80AYwAsheahrpe6NxuwXRC49B1sdzp?= =?utf-8?q?Sfhx5MbPaN/lNRubZU2xWZVzrUR22odenNZfdMW5jQK9vSJExfmvlNp2Kyr0qSsc3?= =?utf-8?q?MpF85R3K12DOWhXUpB+GyaODWDJXEdvUhOCwhNjETcg7nAhX7+n4yHYvGIGmgul25?= =?utf-8?q?gOdIWWgi8fseTtpIlliCk9yZ3ReFoPzRjrrMVxCnqSOc+2mubGGtwYlWpT+ApgqMR?= =?utf-8?q?gWS+MBy+CFo44YBdXowWk3YmTONGIjgqH4MEW9iPvoBC+PAAFD4RfWs=3D?= X-OriginatorOrg: wolfvision.net X-MS-Exchange-CrossTenant-Network-Message-Id: f886cddf-ba2b-4d68-46dc-08dc271bdd2b X-MS-Exchange-CrossTenant-AuthSource: VE1PR08MB4974.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2024 13:59:40.8812 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e94ec9da-9183-471e-83b3-51baa8eb804f X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: hRyvfFGYE9cjyfWIdPP33O7VvfyAib0WNh/rl0cOIS2r0DglusWqVi4BL0eFAv6cTlR3NirsnLhGjwFJeSELbXcISBHxhEv6HJOJbXQL254= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6330 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790158474764625606 X-GMAIL-MSGID: 1790158474764625606 |
Series |
usb: misc: onboard_hub: add support for XMOS XVF3500
|
|
Commit Message
Javier Carrasco
Feb. 6, 2024, 1:59 p.m. UTC
The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
multicore controller for voice processing.
Add new bindings to define the device properties.
[1] https://www.xmos.com/xvf3500/
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
.../devicetree/bindings/sound/xmos,xvf3500.yaml | 63 ++++++++++++++++++++++
1 file changed, 63 insertions(+)
Comments
On Tue, Feb 06, 2024 at 02:59:34PM +0100, Javier Carrasco wrote: > The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit > multicore controller for voice processing. Acked-by: Mark Brown <broonie@kernel.org> though... > + vdd-supply: > + description: > + Regulator for the 1V0 supply. > + > + vdd2-supply: > + description: > + Regulator for the 3V3 supply. ..it's a bit weird that the supplies are named like this, usually there'd be some sort of meaningful name (even if it's just VDD_1V0 and VDD_3V3 or something). Are you sure these are the actual names?
On 06.02.24 15:32, Mark Brown wrote: > On Tue, Feb 06, 2024 at 02:59:34PM +0100, Javier Carrasco wrote: > >> The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit >> multicore controller for voice processing. > > Acked-by: Mark Brown <broonie@kernel.org> > > though... > >> + vdd-supply: >> + description: >> + Regulator for the 1V0 supply. >> + >> + vdd2-supply: >> + description: >> + Regulator for the 3V3 supply. > > ...it's a bit weird that the supplies are named like this, usually > there'd be some sort of meaningful name (even if it's just VDD_1V0 and > VDD_3V3 or something). Are you sure these are the actual names? The names in the datasheet are vdd for the 1V0 supply and vddio for the 3V3 supply. I named the latter vdd2 instead because this device does not have its own driver and instead it uses the onboard_usb_hub generic driver, where the supplies are named vdd and vdd2. Those are the names used for devm_regulator_bulk_get(). Is that not the right way to match them? Thank you and best regards, Javier Carrasco
On Tue, Feb 06, 2024 at 04:05:15PM +0100, Javier Carrasco wrote: > On 06.02.24 15:32, Mark Brown wrote: > > On Tue, Feb 06, 2024 at 02:59:34PM +0100, Javier Carrasco wrote: > > > >> The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit > >> multicore controller for voice processing. > > > > Acked-by: Mark Brown <broonie@kernel.org> > > > > though... > > > >> + vdd-supply: > >> + description: > >> + Regulator for the 1V0 supply. > >> + > >> + vdd2-supply: > >> + description: > >> + Regulator for the 3V3 supply. > > > > ...it's a bit weird that the supplies are named like this, usually > > there'd be some sort of meaningful name (even if it's just VDD_1V0 and > > VDD_3V3 or something). Are you sure these are the actual names? > > The names in the datasheet are vdd for the 1V0 supply and vddio for the > 3V3 supply. I named the latter vdd2 instead because this device does not > have its own driver and instead it uses the onboard_usb_hub generic > driver, where the supplies are named vdd and vdd2. > > Those are the names used for devm_regulator_bulk_get(). Is that not the > right way to match them? If desired the driver could be extended to support device specific regulator names through struct onboard_hub/dev_pdata.
On Tue, Feb 06, 2024 at 04:05:15PM +0100, Javier Carrasco wrote: > The names in the datasheet are vdd for the 1V0 supply and vddio for the > 3V3 supply. I named the latter vdd2 instead because this device does not > have its own driver and instead it uses the onboard_usb_hub generic > driver, where the supplies are named vdd and vdd2. > Those are the names used for devm_regulator_bulk_get(). Is that not the > right way to match them? The binding should really use vddio instead of vdd2 but if that's an existing binding then it gets more annoying, probably that existing binding is wrong too since vddio does sound like an entirely plausible standard name for a 3.3V supply. :/ At the very least the binding should document the weird mapping, though ideally the driver would be tought to request names matching the datasheet if the compatible is the one for this device. Doing the better naming might be too much hassle though.
On 06.02.24 16:22, Matthias Kaehlcke wrote: > On Tue, Feb 06, 2024 at 04:05:15PM +0100, Javier Carrasco wrote: >> On 06.02.24 15:32, Mark Brown wrote: >>> On Tue, Feb 06, 2024 at 02:59:34PM +0100, Javier Carrasco wrote: >>> >>>> The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit >>>> multicore controller for voice processing. >>> >>> Acked-by: Mark Brown <broonie@kernel.org> >>> >>> though... >>> >>>> + vdd-supply: >>>> + description: >>>> + Regulator for the 1V0 supply. >>>> + >>>> + vdd2-supply: >>>> + description: >>>> + Regulator for the 3V3 supply. >>> >>> ...it's a bit weird that the supplies are named like this, usually >>> there'd be some sort of meaningful name (even if it's just VDD_1V0 and >>> VDD_3V3 or something). Are you sure these are the actual names? >> >> The names in the datasheet are vdd for the 1V0 supply and vddio for the >> 3V3 supply. I named the latter vdd2 instead because this device does not >> have its own driver and instead it uses the onboard_usb_hub generic >> driver, where the supplies are named vdd and vdd2. >> >> Those are the names used for devm_regulator_bulk_get(). Is that not the >> right way to match them? > > If desired the driver could be extended to support device specific regulator > names through struct onboard_hub/dev_pdata. the onboard_usb_hub driver as well and their supplies are named vdd and vdd2: Documentation/devicetree/bindings/usb/cypress,hx3.yaml I took a look at its datasheet and there is no vdd2 as such, so I think we are in a similar situation here. Actually that device requires five supplies and they have been grouped into vdd and vdd2 according to their voltage level. Best regards, Javier Carrasco
On 06.02.24 16:35, Mark Brown wrote: > On Tue, Feb 06, 2024 at 04:05:15PM +0100, Javier Carrasco wrote: > >> The names in the datasheet are vdd for the 1V0 supply and vddio for the >> 3V3 supply. I named the latter vdd2 instead because this device does not >> have its own driver and instead it uses the onboard_usb_hub generic >> driver, where the supplies are named vdd and vdd2. > >> Those are the names used for devm_regulator_bulk_get(). Is that not the >> right way to match them? > > The binding should really use vddio instead of vdd2 but if that's an > existing binding then it gets more annoying, probably that existing > binding is wrong too since vddio does sound like an entirely plausible > standard name for a 3.3V supply. :/ At the very least the binding > should document the weird mapping, though ideally the driver would be > tought to request names matching the datasheet if the compatible is the > one for this device. Doing the better naming might be too much hassle > though. That is in line with my last reply, where the bindings I used as an example mention the real names of the supplies as they are defined in the datasheet. I can add that for the next version. Best regards, Javier Carrasco
On Tue, Feb 06, 2024 at 03:35:44PM +0000, Mark Brown wrote: > On Tue, Feb 06, 2024 at 04:05:15PM +0100, Javier Carrasco wrote: > > > The names in the datasheet are vdd for the 1V0 supply and vddio for the > > 3V3 supply. I named the latter vdd2 instead because this device does not > > have its own driver and instead it uses the onboard_usb_hub generic > > driver, where the supplies are named vdd and vdd2. > > > Those are the names used for devm_regulator_bulk_get(). Is that not the > > right way to match them? > > The binding should really use vddio instead of vdd2 but if that's an > existing binding then it gets more annoying, probably that existing > binding is wrong too since vddio does sound like an entirely plausible > standard name for a 3.3V supply. :/ At the very least the binding > should document the weird mapping, though ideally the driver would be > tought to request names matching the datasheet if the compatible is the > one for this device. Doing the better naming might be too much hassle > though. Initially the driver targeted a device with a single supply, the name 'vdd' was kept generic since it was expected that other devices would be supported (except for a couple of minor bits the driver is not device specific). Later support for a device with two supplies was added, with the generic name 'vdd2' to support other devices with multiple regulators. Using the correct naming would be doable, with the caveat that the old naming still needs to be supported for backwards compatibility.
On Tue, Feb 06, 2024 at 04:35:54PM +0100, Javier Carrasco wrote: > I took a look at its datasheet and there is no vdd2 as such, so I think > we are in a similar situation here. Actually that device requires five > supplies and they have been grouped into vdd and vdd2 according to their > voltage level. That binding is just broken then and should be updated to reflect the reality of the hardware. The current thing just won't work if any of those supplies come from different regulators. It's really hard to understand how bindings like this get written :/
On Tue, Feb 06, 2024 at 03:49:35PM +0000, Matthias Kaehlcke wrote: > Initially the driver targeted a device with a single supply, the name > 'vdd' was kept generic since it was expected that other devices would be > supported (except for a couple of minor bits the driver is not device > specific). Later support for a device with two supplies was added, with > the generic name 'vdd2' to support other devices with multiple regulators. It's generally always going to be a problem to add generic names that don't reflect the actual hardware names, you still end up needing to define the mapping from the real names to the generic names that have been define when you end up with the regulators being controllable. > Using the correct naming would be doable, with the caveat that the old > naming still needs to be supported for backwards compatibility. Yes, the existing bindings need to be supported as a legacy/fallback thing.
diff --git a/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml new file mode 100644 index 000000000000..3e77bb9d5eb0 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/xmos,xvf3500.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: XMOS XVF3500 VocalFusion Voice Processor + +maintainers: + - Javier Carrasco <javier.carrasco@wolfvision.net> + +description: + The XMOS XVF3500 VocalFusion Voice Processor is a low-latency, 32-bit + multicore controller for voice processing. + https://www.xmos.com/xvf3500/ + +allOf: + - $ref: /schemas/usb/usb-device.yaml# + +properties: + compatible: + const: usb20b1,0013 + + reg: true + + reset-gpios: + maxItems: 1 + + vdd-supply: + description: + Regulator for the 1V0 supply. + + vdd2-supply: + description: + Regulator for the 3V3 supply. + +required: + - compatible + - reg + - reset-gpios + - vdd-supply + - vdd2-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + usb { + #address-cells = <1>; + #size-cells = <0>; + + voice_processor: voice-processor@1 { + compatible = "usb20b1,0013"; + reg = <1>; + reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>; + vdd-supply = <&vcc1v0>; + vdd2-supply = <&vcc3v3>; + }; + }; + +...