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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 5D616EB64DA for ; Thu, 22 Jun 2023 12:53:14 +0000 (UTC) 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:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:Cc:To:Subject: From:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=vxlEM92hziLCO7yLjDxKO3AXKRmtiHdB2UVkLX8LN9k=; b=ojFxlReZkFWB6p 7X3njKptmvwv4hSs6b7a/xpxRJ+Cx33NoXyjQXaeiW4JV18LOynZK5rqNmI6yfPf5R2dNc4jZ5xiD TDSkNNwme9GwfmeE7nQ6tE9HwiiAHacBNuJ+4Xq+keFEoFe1x3Z3lmsKXI4YqH3U1spw0l6YDot63 J+Y+DnmI15DoX5Os7IkKe5Ip20v3vAtuhims6Y4PONcnfFP+yUT5/zOfoaK1RxATnY3v6PwT5bG6o mOnv/55HBnaK4pTQz/CGmp1hYi8AD6l0Pdts70Bg3mk2WVlgYUHTdS4s0z7Vu02CteAB6KHy0xGFy TWVCPUJzQfFzuo76hEdg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qCJnn-000f52-2T; Thu, 22 Jun 2023 12:52:43 +0000 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qCJnk-000f3D-2M for linux-arm-kernel@lists.infradead.org; Thu, 22 Jun 2023 12:52:42 +0000 Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3113306a595so6093660f8f.1 for ; Thu, 22 Jun 2023 05:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687438358; x=1690030358; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=3Gd2rN+LYgXaVXhDv5TDP/9OSYFS9BOQ/d4mluuIDQQ=; b=W1SASCkJJx2JO4wmg5Y6XkrTiXnrIUmpqlOoiFo3KS15TLJ6H/xk0vQ4Hm0HZkO68F GDlJbHZ7dKmp82vgwqfoPTjib2LdB9lTTD/5o8RWM3YvcTatPyqdhuOOhQindOKs5EGr K4wZgoIMzmQywDiTJhxSJ4yHq8rCaNFppDdMrqRXs1DsEDzETwMgpd5i1M3rFyjrHch7 F5jFUvcWPTGXsPdoH7lmjFhSHFNs5cqtfyShsm84McHFcCsMYwCkGCyFboY44d8iO8QB OdX8UgmKwO0u3cGc5ulLlNWdMonv+t7d5Eu1ytR7gpP7IOceNDZX69hdNYHkQyCmukPc 8eIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687438358; x=1690030358; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3Gd2rN+LYgXaVXhDv5TDP/9OSYFS9BOQ/d4mluuIDQQ=; b=MBCZPuQwZ7Z4zvVUA4uURgNcfLvnJz4dGbAoMMlp0r2a4MLGJGnJm5pLcOwvnjnz5q 4ZkDXbiRFzse1JJOH1jL5hOO/c0+9/vFHmZT+kNLZx6H98jvIK2/WAmvpO+mANmUsVG1 0l6HTKoeYcTewwbZQGWEll+BGL+3OkZARw9UhWlEeEXWyTkCJt+lw/O/ud5XH4ADX5dU 5EQvtzTsuX7f7jERA3Dfnuq3kzV6Li86X/fDgHQB99/us8ltkBID0VKCO2qxZHMxWCCx EamSD9Oa3szgFEbxj9xpeulbV/tYj+vm9O3odjTgMt02jwTwnATnBQ2JzQpzO5tFZs9M LYeQ== X-Gm-Message-State: AC+VfDyp/1DxDnwWjZIJLw+RjmMtaSShwgiK8FyUvN35UvUFRDRBxrJI 2WcCjXlko26m9VdpTolWXYI= X-Google-Smtp-Source: ACHHUZ7ZYlmGLpIp0K2LCIOaOUR7YxW9hjMU9sBUEZ4cRW5uMjQdIBs4ZoVUvmJM6BFMi/rCW1clng== X-Received: by 2002:a05:6000:1191:b0:30a:b147:69db with SMTP id g17-20020a056000119100b0030ab14769dbmr17036899wrx.24.1687438357849; Thu, 22 Jun 2023 05:52:37 -0700 (PDT) Received: from [192.168.50.244] (83.8.116.77.ipv4.supernova.orange.pl. [83.8.116.77]) by smtp.gmail.com with ESMTPSA id g3-20020adff3c3000000b0030e52d4c1bcsm7017073wrp.71.2023.06.22.05.52.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jun 2023 05:52:37 -0700 (PDT) Message-ID: <72af054e-e82b-917c-1f9b-fe231dcfa5bf@gmail.com> Date: Thu, 22 Jun 2023 14:52:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 From: Artur Weber Subject: Re: [PATCH v4] ARM: dts: exynos: Add Samsung Galaxy Tab 3 8.0 boards To: Krzysztof Kozlowski , Olof Johansson , Krzysztof Kozlowski Cc: Arnd Bergmann , soc@kernel.org, Rob Herring , Conor Dooley , Alim Akhtar , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org, ~postmarketos/upstreaming@lists.sr.ht References: <20230604165627.16963-1-aweber.kernel@gmail.com> Content-Language: en-US In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230622_055240_766088_55EACFC4 X-CRM114-Status: GOOD ( 22.08 ) 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: , 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 04/06/2023 21:15, Krzysztof Kozlowski wrote: > On 04/06/2023 18:56, Artur Weber wrote: >> +/* >> + * This device does not use the built-in RTC; instead, the RTC in the >> + * S5M8786 PMIC is used instead. Remove the unused node to avoid DTB check >> + * warnings. >> + */ >> +/delete-node/ &rtc; > > This is not the solution. The S3C RTC is there. Just like all other > boards we have two RTCs and DTS should be complete. Definitely you > should not remove something just because there were warnings. Instead > warnings should be fixed. The problem is that the built-in RTC does not seem to work on this device. I attempted to add it, using the same clocks as other devices in mainline using the S5M8676 PMIC: &rtc { status = "okay"; clocks = <&clock CLK_RTC>, <&s5m8767_osc S2MPS11_CLK_AP>; clock-names = "rtc", "rtc_src"; }; However, it just prints the following on startup: s3c-rtc 10070000.rtc: rtc disabled, re-enabling s3c-rtc 10070000.rtc: registered as rtc0 s3c-rtc 10070000.rtc: hctosys: unable to read the hardware clock Since the internal RTC gets registered as rtc0, it's used as the default by the OS, whereas the working RTC from the PMIC is registered as rtc1. Writing to the internal RTC succeeds but the settings are not kept after a reboot. The PMIC's RTC works fine. This isn't a mainline-only issue; the internal RTC does not work in the downstream kernel on this device either. Not adding the RTC node results in a warning about missing clocks (exynos4.dtsi only provides 1 clock, whereas bindings require 2): arch/arm/boot/dts/exynos4212-tab3-3g8.dtb: rtc@10070000: clocks: [[5, 346]] is too short From schema: /mnt/linux/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml arch/arm/boot/dts/exynos4212-tab3-3g8.dtb: rtc@10070000: clock-names: ['rtc'] is too short From schema: /mnt/linux/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml ...which makes sense, since we don't want to add clocks given that we're not going to be using this RTC. I suppose deleting the node with delete-node is a bit too destructive though. I guess a good solution would be to set up the &rtc node as seen in the snippet I sent earlier, but keep it disabled + add a note explaining why it's done. In your opinion, what would be the best solution? Best regards Artur _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel