Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp575069pxb; Mon, 8 Nov 2021 18:56:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJz5H8XNvK+UA43EWYk3ZSK55CUumrevN3mhDyF/niHMVFJ7glhbeNcTqypbYwICmF/woOLV X-Received: by 2002:a05:6638:1923:: with SMTP id p35mr2999524jal.16.1636426571514; Mon, 08 Nov 2021 18:56:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636426571; cv=none; d=google.com; s=arc-20160816; b=xeFCVdn1/E1psaAM93FnmIfhkc3EgP/SLEPWyd8M3rb3VKH65+/BjR+lMDZabzejKq 4ceuUMnoYwUnnktxTpqc+oht0rREq2yEivTs0lgbH2uMEWoIdFj/d3dGfr2VBT/7Extx rcDsUMKCJcKx5VGwWrWexj4iHTgRNM8OSeoc9eGiBVBlcBdbiU1VKwzKgRxVqiB1J+6+ 54mmleeXsHoi8gvQFSqP0KzQ7lzKHe+9XWPZFO3FaiA8l83RBbTriLI4Gb5wOrggpIY6 jfF6MPL172D5xKR6xPHzXBPxkI0GHMiA+1dgsjPv1y/MwHX+vIWrT1HfX0nTCOHohDWB ljpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=V9Iis9hGWtZOgUPU1mqg1irQSYLApnWnzQFHO9gUfwI=; b=FHVQB69CdmoozMmgJLRLWTytSmFTi6eGDerelnL10pDpVBW2xaj8iynOPYkGLIg76W yDiPAwQdvJldGLz3gThPFpET18FANODOuCqkfqHXoSMgIvYDqDKTRiWgitYDhQois8g5 d4miMPosjbsSWzEmYqiWFkCGmF68vT70SUUpHqbizoVSfRaquvPZ2QE5Ve2TQPnPhZcc g0PYsB8JxiJ9YAMnQPG2/NXaxG3BiNdqSN/MzYAqmPguFuI913BvZstnSaY939Oyxnjl cjW6FfEIt9jNUoqQJAepSyyxxuftsPrLycWJ4+5Z4UNOf+HoS/dtUW8ljnggIyJ6QSAd dGPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@goldelico.com header.s=strato-dkim-0002 header.b=D9aOeIJ1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r17si39937045iov.20.2021.11.08.18.55.46; Mon, 08 Nov 2021 18:56:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@goldelico.com header.s=strato-dkim-0002 header.b=D9aOeIJ1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235675AbhKHSgo (ORCPT + 99 others); Mon, 8 Nov 2021 13:36:44 -0500 Received: from mo4-p02-ob.smtp.rzone.de ([85.215.255.80]:26331 "EHLO mo4-p02-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235246AbhKHSgn (ORCPT ); Mon, 8 Nov 2021 13:36:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1636396431; s=strato-dkim-0002; d=goldelico.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date: From:Subject:Sender; bh=V9Iis9hGWtZOgUPU1mqg1irQSYLApnWnzQFHO9gUfwI=; b=D9aOeIJ1Ym/PITlBZv2L+vSVbh9zw/E080wuh9vTMvTh9wmswt66zbcUOlmdBLNLk6 fj3VraebsAAPkBFkGmd6F6xmARMCZVrsXHvqlCTFNhDi1NqAjATz5cevLLLtF1ipPd+F c78Q1vM5EtEkQOJwwArjsYEtV7hIxwZ/ERKOt526VSm8aLnrmw8M9YRTUwDvOTdD7cP9 REICA5IcDu/oUTNE2vLiw/sbaxWDQgUuRUMeSdaYNWk/LIN+9lkh6sHTrkXC51DsCrHU VajNNoLLmKZoJRiYuC2g9vhMlleoIBlhRj3p513oRFqvO+B5G5gTBSmX9vIje1J78IpA B7oQ== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBj7gpw91N5y2S3gMZ+" X-RZG-CLASS-ID: mo00 Received: from imac.fritz.box by smtp.strato.de (RZmta 47.34.1 DYNA|AUTH) with ESMTPSA id 902c63xA8IXnMN2 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Mon, 8 Nov 2021 19:33:49 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output From: "H. Nikolaus Schaller" In-Reply-To: Date: Mon, 8 Nov 2021 19:33:48 +0100 Cc: Rob Herring , Mark Rutland , Thomas Bogendoerfer , Geert Uytterhoeven , Kees Cook , "Eric W. Biederman" , Miquel Raynal , David Airlie , Daniel Vetter , Neil Armstrong , Robert Foss , Laurent Pinchart , Jernej Skrabec , Harry Wentland , Sam Ravnborg , Maxime Ripard , Hans Verkuil , Liam Girdwood , Mark Brown , Paul Boddie , OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS , linux-mips , linux-kernel , Discussions about the Letux Kernel , Jonas Karlman , dri-devel Content-Transfer-Encoding: quoted-printable Message-Id: References: <2c7d0aa7d3ef480ebb996d37c27cbaa6f722728b.1633436959.git.hns@goldelico.com> <7CEBB741-2218-40A7-9800-B3A154895274@goldelico.com> <229EBE4C-6555-41DE-962F-D82798AEC650@goldelico.com> <2E32F572-72D0-44E7-A700-AF8A2D37BFDA@goldelico.com> <2F8A88BC-2696-491B-9C01-7D07A3B3670A@goldelico.com> To: Paul Cercueil X-Mailer: Apple Mail (2.3445.104.21) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paul, > Am 08.11.2021 um 18:49 schrieb Paul Cercueil : >=20 >>> Variant 4: the variant #2 without the changes to the DTSI files. >> Hm. If there is no cache and we can safely remove tight boundary = checking (by JZ_REG_LCD_SIZE1) for jz4725/40/70 (by not fixing DTSI) why = do we still need the max_register calculation from DTSI specifically for = jz4780 and at all? >=20 > It's better to have the .max_register actually set to the proper = value. Then reading the registers from debugfs = (/sys/kernel/debug/regmap/) will print the actual list of registers = without bogus values. If .max_register is set too high, it will end up = reading outside the registers area. Ok, that is a good reason to convince me. > On Ingenic SoCs such reads just return 0, but on some other SoCs it = can lock up the system. Yes, I know some of these... > So the best way forward is to have .max_register computed from the = register area's size, and fix the DTSI with the proper sizes. Since your = JZ4780 code needs to update .max_register anyway it's a good moment to = add this patch, and the DTSI files can be fixed later (by me or whoever = is up to the task). Well, it would already be part of my Variant #2 (untested). So I could = simply split it up further and you can test the pure dtsi changes and = apply them later or modify if that makes problems. Saves you a little = work. BTW: the jz4740 seems to have even less registers (last register = seems to be LCDCMD1 @ 0x1305005C). >=20 > Fixing the DTS is not a problem in any way, btw. We just need to = ensure that the drivers still work with old DTB files, which will be the = case here. Yes, that is right since the new values are smaller than the originals. Ok, then let's do it that way. BR and thanks, Nikolaus=