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 5B9A3C25B7E for ; Tue, 4 Jun 2024 11:39:15 +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:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=6Pw7fj4JwzlL66rHWoiDR7kwnxNxLV6xNeP5JPs8n+g=; b=BFmwaq64BhoQl8 POMPCnwGztijYEq4hJcJnIM8N+Vht6YRwILkICrVrzZdQ8Fnwv/Wj8AKAaSo6OGH3SphqopQ8f2A0 sXixNwlDBei4t5mE1dDFO55UBBRGsBsNlhuyeIuFAwQLTbGRU1cbiGjQlmdqpZA7Wi8Z7kSq6X3hL UmYA2eWHmxFoRm9Q/XlCcQ15UtLHW/eqOToIiz3r3GbICuJJ4fQGuvjOYN6eL5ZHyDcwbeTzpwh4x kSdhGgtwDxAOgVwsq2TW2khggc/m/YhCWETUAQVUHNKpMRQvwh5Y6uPCwh1+a5/IpY4O0k4gT0eTH yul7llh2HRSrcGxsPmIA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sESVJ-000000029h9-2FI7; Tue, 04 Jun 2024 11:39:01 +0000 Received: from mx1.tq-group.com ([93.104.207.81]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sESVG-000000029cd-1GPD for linux-arm-kernel@lists.infradead.org; Tue, 04 Jun 2024 11:39:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1717501138; x=1749037138; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=YoxkqmfgJqrdmMv5DLLQpdpTV2RJUZno4i80lbGS60s=; b=FDudeRKiJUjkU+NXVQEwr2b8k7nGCDmchNj2ZS9iVo2To2LShfFsr12O Z643djNJslNepUI0uDJvDMm48oBiiLUJNP3tEfDBGT+7TYlTPve5GWW2U jWMJQDASZwuLY+g3WF4+IWDyyNpPZzDrbMonvIpd7XOqC3abxD90wtLV9 WrPYsEuXzAaXJfl+QsXo3WL2qk9DNs53BhyftvsYjRiOTFkqQnJAlm0ht 1GaJ5+1D+LSve8NZzrsFPe+eYUhrUbd6zu+T6DeS8zdLn8vh4NifmK13n ZhODas8yZhbWhOcBigKrfjdAMkSKXMmyzouQ1q5Gxd0AbRnMvlnSDIkcE w==; X-CSE-ConnectionGUID: h+LefQ3sTim9ik3KwuncDg== X-CSE-MsgGUID: 5Gec9Im0QGOZRFKomEOW5A== X-IronPort-AV: E=Sophos;i="6.08,213,1712613600"; d="scan'208";a="37211903" Received: from vmailcow01.tq-net.de ([10.150.86.48]) by mx1.tq-group.com with ESMTP; 04 Jun 2024 13:38:48 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id E313717166C; Tue, 4 Jun 2024 13:38:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ew.tq-group.com; s=dkim; t=1717501124; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=YoxkqmfgJqrdmMv5DLLQpdpTV2RJUZno4i80lbGS60s=; b=r5qBjm685dOtjc6FD4lUdJt7rlTowc5KO+i81zeaMU90LW2v9BDRmTcUe6EGsQMboZAO1u 55UNFXCiLeqloK0YO3ItfKflWEqSMeW5ubwBOUo84pESALlDkh4b54ZsHYmhRm1DqYXFvI Wma5yCg5IHfL2gJ14IDtfRpZmDhcqRMmHEFHEfzgZMiO7YbpxUrEs0VM9M172oNoJ91cdw 4qUZMzqeY39HKrbSBe9Jn5sNRiv/iY8VXy0I2SPf4h4dO2KannKd6D5oPD7uZtNgHVnOB4 Ig5+nIbHqi6sP9Mw8ADY/iUtYXCx5iRYJk2z0VLr32gfRPukAODI9dcgXY6cBQ== From: Alexander Stein To: Esben Haabendal Cc: Shawn Guo , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-arm-kernel@lists.infradead.org, Rasmus Villemoes , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ARM: dts: ls1021a: add QUICC Engine node Date: Tue, 04 Jun 2024 13:38:44 +0200 Message-ID: <8425529.NyiUUSuA9g@steina-w> Organization: TQ-Systems GmbH In-Reply-To: <87ttiem4de.fsf@geanix.com> References: <20240530-arm-ls1021a-qe-dts-v1-1-2eda23bdf8c5@geanix.com> <5987259.31r3eYUQgx@steina-w> <87ttiem4de.fsf@geanix.com> MIME-Version: 1.0 X-Last-TLS-Session-Version: TLSv1.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240604_043858_666911_234E092B X-CRM114-Status: GOOD ( 35.43 ) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Esben, Am Freitag, 31. Mai 2024, 16:40:29 CEST schrieb Esben Haabendal: > Alexander Stein writes: > = > > Hi Esben, > > > > Am Freitag, 31. Mai 2024, 14:20:02 CEST schrieb Esben Haabendal: > >> Alexander Stein writes: > >> >> + brg-frequency =3D <150000000>; > >> >> + bus-frequency =3D <300000000>; > >> > > >> > Mh, aren't these values depending on your actual RCW configuration? > >> = > >> Yes, you are right. The QE bus-frequency comes from platform_clk which > >> is controlled by various bits in RCW and sys_ref_clk. > >> = > >> So I guess it should be possible to derive bus-frequency from sysclk > >> clock-frequency attribute and RCW. But fsl,qe bus-frequency is a > >> required property... > >> = > >> Max bus-frequency for LS1021A is 300 MHz. But it should be possible to > >> set it lower, although I suspect that many/most/everyone is running it > >> at 300 MHz. > > > > Thanks for confirmation. I'll let DT maintainer decide how to deal with= this. > = > For reference. > = > The existing DTS with fsl,qe have the following bus-frequency property va= lues: > = > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi: bus-frequency =3D <20000= 0000> > arch/powerpc/boot/dts/fsl/mpc8568si-post.dtsi: bus-frequency =3D <39600= 0000> > arch/powerpc/boot/dts/fsl/mpc8569si-post.dtsi: bus-frequency =3D <0> > arch/powerpc/boot/dts/fsl/p1021si-post.dtsi: missing! > arch/powerpc/boot/dts/fsl/t1024si-post.dtsi: bus-frequency =3D <0> > arch/powerpc/boot/dts/fsl/t1040si-post.dtsi: missing! > arch/powerpc/boot/dts/kmeter1.dts: bus-frequency =3D <0> > arch/powerpc/boot/dts/mpc836x_rdk.dts: bus-frequency =3D <0> > arch/powerpc/boot/dts/mpc832x_rdb.dts: bus-frequency =3D <19800= 0000> > = > The 3 non-zero values are most likely also not guaranteed by SoC design > to always be the right values. But I haven't checked. PowerPC might be completely different. Apparently that's the way it is done until now. > >> >> + fsl,qe-num-riscs =3D <1>; > >> >> + fsl,qe-num-snums =3D <28>; > >> > > >> > Current bindings defines: > >> >> fsl,qe-snums: This property has to be specified as '/bits/ 8' value, > >> >> defining the array of serial number (SNUM) values for the virtual > >> >> threads. > >> > > >> > So '/bits/ 8' is missing. > >> = > >> Ok, so you want me to add an array for fs,qe-snums attribute? > >> None of the existing fsl,qe devices has a fsl,qe-snums. > >> And qe_snums_init() has a fallback, so I don't think it is correct to > >> specify fsl,qe-snums to be a required property in the bindings. It > >> should be listed as optional. > > > > fsl,qe-num-snums is a deprecated property, so IMHO the replacement > > fsl,qe-snums should be used instead for new device tree entries. > > qe_snums_init() supporting 'fsl,qe-num-snums' is just to support > > "legacy bindings" as stated in the comment. > = > Figuring out the correct array values for fsl,qe-snums for ls1021a is > not so easy. It is not so clear from the reference manual, what it > should be. And the default array used for fsl,qe-num-snums =3D <28> does > not look right in any way, but seems to work. > = > It would not feel right to just copy those values and put into DTS, as > it would imply that the values are truly a correct description for the > LS1021A hardware. Maybe copy the currently hardcoded values and add a REVISIT comment or similar describing these are copied, apparently working, but unverified. Best regards, Alexander > >> = > >> >> + }; > >> >> + > >> >> + muram@10000 { > >> >> + #address-cells =3D <1>; > >> >> + #size-cells =3D <1>; > >> >> + compatible =3D "fsl,qe-muram", "fsl,cpm-muram"; > >> >> + ranges =3D <0x0 0x10000 0x6000>; > >> > > >> > Node address but no 'reg' property? I have no idea if this is okay. > >> > Also compatible (and possibly reg) first. > >> = > >> It is done in the same way for all existing fsl,qe-muram devices. So if > >> it is not okay, a tree-wide fixup would be in place. > > > > I can't finally say if this is okay, but at least the compatible shall = be > > listed first. > = > Done. > = > /Esben > = -- = TQ-Systems GmbH | M=FChlstra=DFe 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht M=FCnchen, HRB 105018 Gesch=E4ftsf=FChrer: Detlef Schneider, R=FCdiger Stahl, Stefan Schneider http://www.tq-group.com/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel