From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 AA70037106E for ; Wed, 22 Apr 2026 08:55:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776848143; cv=none; b=uMPDJLqDyDIE+h0p82pcHDrZ8WR1v5cNr9k/lp5gQVl+1luWBkQXdQLoLncfQyVCrePcvD7IAAy9lis9K/F4DfD0I1BcDdBjHUOLeaVNyRExUIe5Y95rICIo8YzarKDgB4AvDyXQ+XXgEAmiCrRCbUXa63zyuD53cozra5xOf/g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776848143; c=relaxed/simple; bh=0uvBMUOSwyAYA20cd5mCnPA8P6u+FM5mCCnYDev5/mM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=T/oeGK0iAkTM6V19T1mfcRO1p1icEYVd8GMTsKWehe0W7BGspzTyG95RXYsh/CUickchOla8Q1uCJ/Z+duNmhh4W2ESVfoS80/Bfil2ww1mbzk67wMevVfWzPlaI2F+4T/Eb3j7EsmSIzhSGzpCCfYUtWvQgM5kI4i5ZOlr+6ao= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tuxon.dev; spf=pass smtp.mailfrom=tuxon.dev; dkim=pass (2048-bit key) header.d=tuxon.dev header.i=@tuxon.dev header.b=VXA8eOxG; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tuxon.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=tuxon.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=tuxon.dev header.i=@tuxon.dev header.b="VXA8eOxG" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-43fe3e22e33so3445059f8f.0 for ; Wed, 22 Apr 2026 01:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxon.dev; s=google; t=1776848140; x=1777452940; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=uugn1Iy/EUw8QWPEjCkPMfHWiB+g/iglcdvhK7LYU78=; b=VXA8eOxG6ewEDz8BKGe3wv938EqC6LamL6FgVXiA1WcckdEvXdn+nEghWJxaxsnkZr huurGUfdDyG1scCnnQJdz/Zqik2JhPcPp2xxEvG7pBhfpeavOpVn8rLN9G+HUiYK8Lq5 PXxXtF0TF7dMZU5WVHcCZFzyHYLtw552F1L/3CtR/CYoO0cz1qJc4dOUA0TT4BT7q5nS D1+AZ0cVGSOpgN24QlJMqEzXOOq5FuTvjbgLIQai9UEcB+HIFpUD3fFIJYklnp6iewJv etVEG5s6Ot4m5jnPDPMz7EmUS4FrIvJtoJnqRQV1A6ORIiF6Hb60d7Of3VDuROitlTM6 skJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776848140; x=1777452940; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uugn1Iy/EUw8QWPEjCkPMfHWiB+g/iglcdvhK7LYU78=; b=LA//4+oM7Ofqzcmf4A8Tqza4UrizTV/g/ZeqO4+h+G13F+ZaZAt5t2novr00qC+681 Feu7gpLvkKtoCoxAlkvnTALyd91ULB8jLIMfLI4jziHWe8cPEftxxD6UJneHeGcsZiLp XUGtIk3CXkIvL03joJAauwKolqqE3b3TY3X3Ot0YCT05mXWSljNumfS1QyNvmFr+TsVM 8RJWS3NnvB8+NExDP7AOLwi7bpenVSsDYA5aKIZm6T08FM4p12SYIr8Ym1vHKHYfZ0sM jTG20qaWvP9bwaCqCYq6Tf9zw0+rrbqy9tPqVF3AxZfqEHAGrenoXWAFZxlJ99Liyqvx jkgA== X-Forwarded-Encrypted: i=1; AFNElJ+HN68dFETNZkMT+Y6gQEGeTBtUZdWHS4mkhSznUUZYv374iX3mzziuma6GXmeUyerIHQ1lmkx9S48hZCk=@vger.kernel.org X-Gm-Message-State: AOJu0YynbQKxAOUXh7nCLIVCnnvJfjxJNJt4+QF8CawK/MrQibLKHKjy OaR8COQvWzEFOtAujii/HFDv2tQDcE/1nmeIS+Zt0y9T56XLcSXxcQkyDSizEzY3hCU= X-Gm-Gg: AeBDievMeWokdSvPQnkl8yekECYbUY9ysH5cmqIgaT9+1Z/r0JFkwc1rnbT0sPQFNr9 YkcYrRRnLoM2Ca4JmtFqA/6uH8B2SujRRgXCFHpkt9I6IVoUZ4JZdQMzKETX0y/bcnLTtAmagoZ R7mrzwHgGwT41oZf9p9JwX/or2w7GDtcilKs13vrOmDGAijPyUx9kbYxBHRZrxmUNGwuwB+/O+V zb06IqkO2pVNq6IYs89myRZiZcfERczdOEeokxLjKTCjaZNQzpO+h/2nZLGCCniL3KPq3mJhg2M wXMABdqBg7qiOXbXahboFVMRf3WnUHOd6TqfJlzUNTcq/y8Bl2SxpUR5a0jXecCL25+m8PEwFFQ 8FRKJk8TxLVyHfOkp7P6P1vcYUSD7lSEBc6558Sw8QVul4jieHzaHq9+VUjOitiM0SojVE704Uj IRjqbXZVvLzBb7vxIx1l9PuqZL86D+9IQo4aJGI2FjIg== X-Received: by 2002:a05:6000:2510:b0:43d:7508:c9c9 with SMTP id ffacd0b85a97d-43fe3e0984bmr34562736f8f.27.1776848139576; Wed, 22 Apr 2026 01:55:39 -0700 (PDT) Received: from [192.168.50.4] ([82.78.167.162]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43fe4cc0d51sm43898728f8f.10.2026.04.22.01.55.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Apr 2026 01:55:39 -0700 (PDT) Message-ID: Date: Wed, 22 Apr 2026 11:55:37 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] drm: renesas: rz-du: Add support for RZ/G3L LVDS encoder To: Dmitry Baryshkov Cc: Biju , Biju Das , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Philipp Zabel , Geert Uytterhoeven , Magnus Damm , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad , Tommaso Merciai References: <20260417175235.224809-1-biju.das.jz@bp.renesas.com> <20260417175235.224809-4-biju.das.jz@bp.renesas.com> <9523bd97-2730-4b99-b3d0-6accc7622478@tuxon.dev> Content-Language: en-US From: Claudiu Beznea In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/21/26 14:22, Dmitry Baryshkov wrote: > On Tue, Apr 21, 2026 at 12:11:28PM +0300, Claudiu Beznea wrote: >> Hi, >> >> On 4/19/26 18:58, Dmitry Baryshkov wrote: >>> On Fri, Apr 17, 2026 at 06:52:30PM +0100, Biju wrote: >>>> From: Biju Das >>>> >>>> Add support for the RZ/G3L LVDS encoder driver. It operates in single-link >>>> mode with 4 lanes (Data) + 1 lane (Clock) and supports pixel clock rates >>>> from 25 to 87 MHz. The LVDS module cannot be used at the same time as >>>> MIPI-DSI. However, LVDS and the DSI interface share a peripheral clock and >>>> the MIPI_DSI_PRESET_N reset signal. Also, the MIPI_DSI_CMN_RSTB and >>>> MIPI_DSI_ARESET_N reset signals must be asserted before using the LVDS >>>> module. >>>> >>>> Signed-off-by: Tommaso Merciai >>>> Signed-off-by: Biju Das >>>> --- >> >> [ ...] >> >>>> +/* ----------------------------------------------------------------------------- >>>> + * Bridge >>>> + */ >>>> +static void rzg3l_lvds_atomic_enable(struct drm_bridge *bridge, >>>> + struct drm_atomic_state *state) >>>> +{ >>>> + struct rzg3l_lvds *lvds = bridge_to_rzg3l_lvds(bridge); >>>> + const struct drm_bridge_state *bridge_state; >>>> + int ret; >>>> + u32 fmt; >>>> + >>>> + /* Get the LVDS format from the bridge state. */ >>>> + bridge_state = drm_atomic_get_new_bridge_state(state, bridge); >>>> + if (!bridge_state) { >>>> + dev_err(lvds->dev, "failed to get bridge state\n"); >>>> + return; >>>> + } >>>> + >>>> + switch (bridge_state->output_bus_cfg.format) { >>>> + case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA: >>>> + fmt = RZG3L_LVDS_MODE_JEIDA; >>>> + break; >>>> + case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG: >>>> + fmt = RZG3L_LVDS_MODE_VESA; >>>> + break; >>>> + default: >>>> + fmt = RZG3L_LVDS_MODE_VESA; >>>> + dev_warn(lvds->dev, "Unsupported bus fmt 0x%04x\n", >>>> + bridge_state->output_bus_cfg.format); >>>> + break; >>>> + } >>>> + >>>> + ret = pm_runtime_resume_and_get(lvds->dev); >>> >>> If this fails for any reason, the atomic_disable() would still be >>> called and it will decrement the counter, potentially undeflowing it. >>> Consider switching to pm_runtime_get_sync(), which suits better here. >> >> AFAIK, the clocks of this HW blocks have MSTOP functionality. HW manual of >> RZ/G3S [1] (should be the same for RZ/G3L as well) mentions the following in >> the chapter 41.2.1. "If the master accesses a module that has the clock >> stopped and the MSTOP bit set, a bus error will occur". [1] >> MSTOP is set though the clock enable/disable APIs. >> >> The clocks on RZ/G3L are part of clock power domains. If the >> pm_runtime_resume_and_get() fails (or any runtime PM resume calls), the >> clocks will be off and MSTOP set. In this case, calling atomic_disable() or >> any API setting HW registers will lead to sync aborts. > > Then you've identified a bug in the code. The atomic_enable() doesn't > fail, so for each enable there always will be an atomic_disable() call. > Is this something that should be solved by individual drivers providing struct drm_bridge_funcs to the upper layers or by the subsystem itself? Accessing HW w/o its power being on (whatever power means here, e.g. clocks, resets, regulators) seems odd and may lead to critical failures. On some Renesas SoCs this used to work previously but it is not anymore with the addition of the so called MSTOP functionality. Thank you, Claudiu