From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B142620C463 for ; Tue, 10 Feb 2026 09:32:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770715970; cv=none; b=EAKxw+9i4mwgaY1unYCdjuDu1hjE0CuVxxudCyWLIP1d/OkFXtSrwTk0qVoiGAlfHsFPis+l7Q+Lt0elI+RS/2si+5LeUMA3cRFL1tKvWRPVfvtA1mOop6L3F3JmdxgYqwqHUCuYzRaMSO5A2kKUg+PkFPODk0yXQGDROyHLGdI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770715970; c=relaxed/simple; bh=laKkbAsQf0SJtxRljSNn44EolGwtZv0xIZlmeJAHA0A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Qt1ATIN3DgZqX9o82R9lMeXxIr//x0L0ed+aBBD7siR4ZU/SyNjTVDjqK1qCpnSPLCiPF4F14AWu3jTMtMkmXJUJp2cpwNwtX1VnVl2QwCt9bdhNKaD4O74LnsbIZxeMkLMGqWDQSgcIJu/+tvox1+n65tjLqccNGCudjvIEZZI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=XfXYf+Mg; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XfXYf+Mg" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4833115090dso5734095e9.3 for ; Tue, 10 Feb 2026 01:32:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770715967; x=1771320767; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=kDX1cQwulzVuiLj3eO/jgS06mt+GxmC17rynSR+42DU=; b=XfXYf+MgNrpjM9F2C/C4PKZjNKGijbUnuiUN1RfeLblhP6d51TmZDRAfv9l20fqiwK kwM7RunYYoVNJPQgUtMXJLJaY1/R4B0zMXQRgiYD5Udda/vgYXWHwxkw3v6I49MgSFq2 dh9tpuvtz6Vi2OLHWbGElL7fH7SpFpWiH7khR7zeszNiQNTS2SHOLHj39C8z8ixYwyrV r328avN7fdNEzgRtrSGvtVM82u3t5PU9Miv57RJ2d9EJ8ELs9jgVCU0JFHNAE7XdwPOl GcZ6BZN0f2LI4Zw1cgo3s3zh6RYEHJCAsweSN7DCz7b0zX3T3gm80Hl7QkD67DTZD1aO 7XCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770715967; x=1771320767; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kDX1cQwulzVuiLj3eO/jgS06mt+GxmC17rynSR+42DU=; b=ex4F0f/8dIu7h4w2u0nqmChiueufz3hpSH6MGXetFv/8rR9dBIVMZKK1wH7chmoJWM S/fViICbs9VGUd4HnDFDObuxpyGtYQNbDvR2DiTEJEQxe2gW3rI4weNt1lgar7LixYcX P5G1GqBsVQ09z8Mn/UexKao6mhdWeGrVPoF2GbTZBkxBCJ3HaTiwVMBl90EqixnxgtmI wa059sa3oloaUBbX6o5spvNI+klrrQa3EAC7Hoh0dawqkApsQOfsX2itPogYNr/BOKys Mge7n7ITxdWGIZOxu5exS9jAMAdAR1KQwLNx3qbnMUhxlN02rTWN+qEZhsExl8nZK1xw Mv4Q== X-Forwarded-Encrypted: i=1; AJvYcCWoVqkx0Fdzq9KCXdF5mGxD2ky+ZYs95HVVCDptERAQBBq0oU3SEpEPpe18lEqHta2WeNbXhO1orhXreoo=@vger.kernel.org X-Gm-Message-State: AOJu0YwxsHhhnbO0lghCL/nL9iH5cxNXQPZxF112a1Nl/+fR324IRL/T 1UA7tUQNCEAqLyoh4EYGgo+6Ge7wYZ7c7GlUcZYsMW6uiq/cXr/AWNRV X-Gm-Gg: AZuq6aLpimliL4hIT0NL33vwYCevfsxNB5xlSefclN2UkepuZjFiCmWCPhYOdQoHGEw sD6tYNoBAIurZOR6wxpdmrusDNQoI/Dh/VJxjYnlQty6+THimbfq4ynnVnCb+bvl9fzUGiT3qDK cuMtdiqhGsVo5WcjLY3Lor5hBAoc8v+QVrJAW3TevouISNR4tKikN1QuHViIFpudsndx96VAzWC zyRq2YSrCtM2C0Zk4nP3U+3cAszlrhzc2uyMEt5IFKTNKDDiCgw4Bli8xRyRPvQIsUdOAuLNciY 1fLv/MA4nHWj3MIj1jv3tOdQKR+YXK+lixdac3f4YRwF9aX5eBsTOZtQVBgTVD5CxYCuSQwGEyO GXvPg3yntw17fTC+0BRWB56P/iNCywROL6KieBrX34IU3xxF75MW5vJhXd+EzQVW79pwTIbwlHm YKHBFayC/VCQVQDj0QgdRCQOKn39vj4lU4QdKfMlay6ciV6KAup0MDZ/nt97BYmCUK7r/KhfESk eK8gPQDaki/Zi2WHBEuZh0Enx7TaCYkEVPSTjqUcXoKfQ== X-Received: by 2002:a05:600c:4f0e:b0:477:9eb8:97d2 with SMTP id 5b1f17b1804b1-483201dce33mr230022905e9.8.1770715966548; Tue, 10 Feb 2026 01:32:46 -0800 (PST) Received: from Lord-Beerus.station (net-188-152-100-94.cust.dsl.teletu.it. [188.152.100.94]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48320410b78sm174961565e9.2.2026.02.10.01.32.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Feb 2026 01:32:46 -0800 (PST) Date: Tue, 10 Feb 2026 10:32:44 +0100 From: Stefano Radaelli To: Kuninori Morimoto Cc: Mark Brown , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org, alexander.h@variscite.com, pierluigi.p@variscite.com, Stefano Radaelli Subject: Re: [PATCH v1] ASoC: simple-card-utils: set CPU sysclk before codec for mclk-fs Message-ID: References: <20260206134014.143057-1-stefano.r@variscite.com> <873439o1xt.wl-kuninori.morimoto.gx@renesas.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <873439o1xt.wl-kuninori.morimoto.gx@renesas.com> Hi Kuninori > > Actually, this is one of my concern (= which should be worked first > (CPU or Codec)). I don't remember why current code calls Codec first, > but maybe original code was. > I guess, some other Card needs to call as-is (= Codec first), and > you want to call opposite (= CPU first). It depends on clock > provider/consumer settings, instead of mclk-fs, but based on each Card. > > Not same but similar issue we had before about how we want to call > .trigger. > > 356caf663deee8dc46ff3168ec0b24bcbeb00b28 > ("ASoC: add new trigger ordering method") > > It was fixed order, but is now controlled by flag. > Maybe we want to have similar method ? > > // unreliable name > #define XX_CLK_START_CODEC_FIRST 0 > #define XX_CLK_START_CPU_FIRST 1 > > if (xx_clk_start_first == XX_CLK_START_CODEC_FIRST) { > // same as current code > start_codec_clk() > start_cpu_clk() > } else { > // opposite > start_cpu_clk() > start_codec_clk() > } > Thank you for your suggestion. I agree that the default ordering should remain unchanged to maintain backward compatibility, and we should implement a configurable feature to change the order when needed. Following your recommendation, I could implement something similar to the trigger ordering approach: #define SND_SOC_SYSCLK_ORDER_CODEC_FIRST 0 #define SND_SOC_SYSCLK_ORDER_CPU_FIRST 1 static int asoc_simple_init_dai(struct snd_soc_dai *dai, struct asoc_simple_dai *simple_dai) { int sysclk_order = SND_SOC_SYSCLK_ORDER_CODEC_FIRST; // <- Default if (simple_dai->sysclk) { if (sysclk_order == SND_SOC_SYSCLK_ORDER_CODEC_FIRST) { // Codec first ret = snd_soc_dai_set_sysclk(codec_dai, 0, sysclk, ...); ret = snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, ...); } else { // CPU first ret = snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, ...); ret = snd_soc_dai_set_sysclk(codec_dai, 0, sysclk, ...); } } } This approach would work well for our case and is acceptable as-is for now. The ordering would be controlled via the define in the driver code. As a future enhancement, would you be open to adding a device tree property to make this configurable per-board? I'll send you v2 with this modification. Thanks a lot for your guidance, Best Regards, Stefano