From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 15CA1664DE for ; Mon, 29 Jan 2024 14:37:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706539077; cv=none; b=KdhqBBS5ruIdhL1wWscn2EPIEPKHT2wX6vlqysypDPrv/dtI7t1u09wAv0UAsM0Tn+8AwzJJCx6lK87F/G+Uj6cd0hGUdLts2f+UfSKlOC0z8FuFVS1R5Q3iiu3gqU+8ZIElwTvXbD5LUKNTvzVCnh+775RU2OlHoLojeKpYBtA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706539077; c=relaxed/simple; bh=SmWaA/jXBIlPgwAcnJn6HDF5NUaZECMDSYWUbzda9r8=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=gh2PQW+akLboWspa6FOdVnTOCY1L+NGE1tHQNFPNf6l76l3Zl5Th6NAWWRLgBSQifXjHYg07XR4sAkBzdB+qIBK9ePVx53vj7P1hBFCh8jZZtMJV4jGGpk4zTANYQiazICHlVLKjyg6kNbE0Ntez5bn0d/uuSObZZiqBz9v4pYY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=El8Q78qb; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="El8Q78qb" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-40e775695c6so24853975e9.3 for ; Mon, 29 Jan 2024 06:37:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1706539074; x=1707143874; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=SmWaA/jXBIlPgwAcnJn6HDF5NUaZECMDSYWUbzda9r8=; b=El8Q78qbjmyOVCC4xkZZ4quoatMRN7ejL0miRg2KVswoomaRcJu0qW3x6LaeCr0+iT mAIqA9ZOf845bjZ5SeKtzbjGjeyQV0ee3indEK2UH3jVVJewTRI8MrywK9uCtc82bc91 B6vJLp1kswzhewyq2YHV6SBj938Ol5B/QQHL+2RQnQUf31OhQCAJfvIjl6m4ylfl7ta7 q2PyJeefcHwJaSwXs6wK53vI9U8jZv0mhjXAEK3clOFgmdVHf2Aewx/wWoLfz33mChKI ZwTUsFtLYhki/xJmi/JmgOMKW4IUERXll87J/0+RFsWpzN+kqIJS1FXHJgKRAdppGfmb IyQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706539074; x=1707143874; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=SmWaA/jXBIlPgwAcnJn6HDF5NUaZECMDSYWUbzda9r8=; b=HHanJvmZ9zAiuKMHlPbkl99JDz0keLFxOeJlt0+h/SLAF0XyOX36Gv3h+8VyKimMWt LubxI/6mAmHQ3DrLscMnQZrfi7gr8IJuKtAZsyfBoZP3SymeAaFDVJAqXFmQxKouWA4Q QgvAdSoiThf1rz5eyzLfwRIlPxppEUHt7deZjQiRf7BgkpLMGeWEHfFYIisN/m8l6Fge jWByGvgoOe74ZVQ2aALFzuIOzH5HCpaqVk9ASB1jifINDGqJTo6MZPVrRW7qkv1U0hxI eyLxo8W/KpgitwPAiHVTfYSGkL7qIEt0xOZPLnVpqEXvh01M3ERDrSxVRBeRskAV3wNZ aY7A== X-Gm-Message-State: AOJu0YzQS77RsfG6CJlbLQAypJkzU47Mpr4WWOJGVJGNpQVID5AcC7/g O5RsvhIJXSEYSfPkBcMtrWl0suNmt7VsowtLjxOPhhO+RjGYi4/OgFZmmvjLfcA= X-Google-Smtp-Source: AGHT+IFlhYu+Wi9LgAtOmfbOEKRnmv6zUQNGWbIWu5r4mGku1fc+uQFrXI3/gxZ2Vg9uB2zaQSX1sA== X-Received: by 2002:a05:600c:20d3:b0:40e:ac8f:e6c with SMTP id y19-20020a05600c20d300b0040eac8f0e6cmr6041047wmm.30.1706539074163; Mon, 29 Jan 2024 06:37:54 -0800 (PST) Received: from draszik.lan ([80.111.64.44]) by smtp.gmail.com with ESMTPSA id cl10-20020a5d5f0a000000b0033aeb20f5b8sm3906577wrb.13.2024.01.29.06.37.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 06:37:53 -0800 (PST) Message-ID: Subject: Re: [PATCH 5/5] clk: samsung: gs101: don't mark non-essential clocks as critical From: =?ISO-8859-1?Q?Andr=E9?= Draszik To: Sam Protsenko Cc: peter.griffin@linaro.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com, tudor.ambarus@linaro.org, willmcvicker@google.com, alim.akhtar@samsung.com, s.nawrocki@samsung.com, tomasz.figa@gmail.com, cw00.choi@samsung.com, mturquette@baylibre.com, sboyd@kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org Date: Mon, 29 Jan 2024 14:37:52 +0000 In-Reply-To: References: <20240127003607.501086-1-andre.draszik@linaro.org> <20240127003607.501086-6-andre.draszik@linaro.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.1-1 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hi Sam, On Fri, 2024-01-26 at 21:30 -0600, Sam Protsenko wrote: > On Fri, Jan 26, 2024 at 6:37=E2=80=AFPM Andr=C3=A9 Draszik wrote: >=20 > >=20 > > Note that this commit has the side-effect of causing earlycon to stop > > to work sometime into the boot for two reasons: > > =C2=A0=C2=A0=C2=A0 * peric0_top1_ipclk_0 requires its parent gout_cmu_p= eric0_ip to be > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 running, but because earlycon doesn't de= al with clocks that > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 parent will be disabled when none of the= other drivers that > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 actually deal with clocks correctly requ= ire it to be running and > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the real serial driver (which does deal = with clocks) hasn't taken > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 over yet >=20 > That's weird. Doesn't your bootloader setup serial clocks properly? > AFAIU, earlycon should rely on everything already configured in > bootloader. I tried to explain that above, but let me try again... The console UART, and I2C bus 8 are on the same cmu_peric0 controller, and that cmu_peric0 has two clocks coming from cmu_top, ip and bus. For I2C8 & = UART to work, both of these clocks from cmu_top need to to be on as they are the parent of the i2c8-(ip|pclk) and uart-(ip|pclk) each. The bootloader leaves those clocks running, yes. So earlycon works (for a while). At some point into the boot, one of two things happens: 1) Linux will load the i2c driver. That driver does clock handling (correctly), it will initialise and then it has nothing to do, therefore it disables cmu_peric0's i2c8 ip and pclk clocks. Because at that stage nothin= g appears to be using the cmu_peric0's ip clock (the real serial driver hasn'= t initialised yet), Linux decides to also disable the parent ip clock coming from cmu_top. At this stage, the earlycon driver stops working, as the parent ip clock of the uart ip clock is not running any more. No serial output can be observed from this stage onwards. I think what is probably happening is that the console uart FIFO doesn't get emptied anymore, and earlycon will simply wai= t forever for space to become available in the FIFO (but I didn't debug this)= . Anyway, the boot doesn't progress, the system appears to hang. In any case = it's not usable as we have no other means of using it at this stage (network / usb / display etc.). 2) Alternatively, the UART driver will load at this stage. Again, it will tweak the clocks and after probe it will leave its clocks disabled. The serial console driver hasn't taken over at this stage and earlycon is still active. Again, the system will hang, because IP and PCLK have been disabled by the UART driver. Once the serial console is enabled, clocks are being enabled again, but because earlycon is still waiting for progress, the boot doesn't progress past disabling ip and pclk. It never gets to enabling the serial console (re-enabling the clocks). So in both cases we get some output from earlycon, but the system hangs onc= e the first consumer driver of an IP attached to cmu_peric0 has completed probing. > > =C2=A0=C2=A0=C2=A0 * hand-over between earlycon and serial driver appea= rs to be > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fragile and clocks get enabled and disab= led a few times, which > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 also causes register access to hang whil= e earlycon is still > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 active > > Nonetheless we shouldn't keep these clocks running unconditionally just > > for earlycon. Clocks should be disabled where possible. If earlycon is > > required in the future, e.g. for debug, this commit can simply be > > reverted (locally!). >=20 > That sounds... not ideal. The ability to enable earlycon just by > adding some string to bootargs can be very useful for developers. > Maybe just make those clocks CLK_IGNORE_UNUSED, if that keeps earlycon > functional? With corresponding comments of course. CLK_IGNORE_UNUSED doesn't help in this case, the i2c and uart drivers will = load and probe before earlycon gets disabled and as part of their probing disabl= e the cmu_top ip clock going to cmu_peric0 If earlycon is not enabled in kernel command line, everything works fine, t= he kernel buffers its messages and once the real serial console driver starts, all messages since boot are being printed. Other than keeping it as CLK_IS_CRITICAL, there is no way that I can see to way to make the hand-over from earlycon to the real serial driver work in all cases. They are not critical clocks for the system, though, so it's wrong to alway= s keep them running unconditionally. We are past a stage where earlycon is generally required. If it's required for some local development, people can revert this patch l= ocally. BTW, downstream doesn't suffer from this problem because downstream uses AC= G throughout and clocks are enabled automatically in hardware as required. Cheers, Andre'