From owner-freebsd-arm@freebsd.org Mon Dec 2 14:45:52 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5A7A11AC0BF for ; Mon, 2 Dec 2019 14:45:52 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RSbM5yHbz3R2s; Mon, 2 Dec 2019 14:45:51 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 18fef891; Mon, 2 Dec 2019 15:45:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=Un7xzeU/30T3J8p3RfZ7vxbj150=; b=D/d44CIh87pRHS79yG8oX9NBHUog FN4MjkceLRq/J7nfGcQBQXH6zrASkRK4qWQuWG5vGh8TEqnBcdICDpBIjJZE6L9v ewq29XC8vGr6yrFURPNn7t4fGgDYtANaSNPv7o0hnPArwElFKOi4mHwtACYd5/Rs VIYk2OeHdI6Hgk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=Y1Of+MiW1U7wksyjGwMoV6MPxK67G3INRS1Gq797VFEa96XM2RzHRPc5 EuHkFis+O9rI/6WGWfcp079IDYSwAGD5MqkZ7O5YvvcoSQU81e+kj3Phw3eRLrT8 FO7VWCT4nKuola0hUVGBVpstojLbyr0mUpSQaPhyl50dhCZEO0A= Received: from sonic.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 1a0c5f36 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 2 Dec 2019 15:45:49 +0100 (CET) Date: Mon, 2 Dec 2019 15:45:48 +0100 From: Emmanuel Vadot To: mmel@freebsd.org Cc: Michal Meloun , Peter Jeremy , freebsd-arm@freebsd.org Subject: Re: rk_tsadc breaks (my) Rock64 Message-Id: <20191202154548.095d7d8ec8796af15e41e47c@bidouilliste.com> In-Reply-To: References: <20191201110716.GA41224@server.rulingia.com> <20191202111322.GF37113@server.rulingia.com> <20191202140416.936a457adebce6fca1341b18@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47RSbM5yHbz3R2s X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; TAGGED_RCPT(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.990,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 14:45:52 -0000 On Mon, 2 Dec 2019 14:53:07 +0100 Michal Meloun wrote: > > > On 02.12.2019 14:04, Emmanuel Vadot wrote: > > On Mon, 2 Dec 2019 22:13:22 +1100 > > Peter Jeremy wrote: > > > >> On 2019-Dec-01 22:07:16 +1100, Peter Jeremy wrote: > >>> r355173 added code to read the Rockchip temperature sensors. Unfortunately, > >>> this breaks on my Rock64. I've tried to understand what's going wrong but > >>> haven't managed to make much headway. It looks like there some configuration > >>> missing from syscon that tsadc needs but I'm not sure what (and I don't really > >>> understand what syscon is doing). I'd appreciate any insights. > >> > >> I've added a pile of printf's and done some more digging and have made some > >> progress. > >> > >> Firstly, I've found that the syscon@ff100000 FDT entry attaches as two > >> distinct devices: > >> rk_grf0: mem 0xff100000-0xff100fff on ofwbus0 > >> (via compatible = "rockchip,rk3328-grf") > >> simple_mfd0: mem 0xff450000-0xff45ffff on ofwbus0 > >> (via compatible = "simple-mfd") > > > > ??? those aren't the same devices. > > > >> Based on the traceback going via simple_mfd_syscon_write_4(), I had assumed > >> that tsadc_attach() was using the latter device but when I added code to > >> print structure addresses, I discovered it was the former. > >> > >> This makes the problem clearer: rk_grf0 requests and is allocated 4KiB > >> memory ("reg = <0x0 0xff100000 0x0 0x1000>;" in the FDT and > >> "mem 0xff100000-0xff100fff" in the device attach message above) but the > >> tsadc_init() code is doing: > >> SYSCON_WRITE_4(sc->grf, GRF_TSADC_TESTBIT_L, > >> GRF_TSADC_VCM_EN_L); > >> with > >> #define GRF_TSADC_TESTBIT_L 0x0e648 > >> and that offset is well outside the 4KiB allocated to the device. > >> (On the positive side, a panic makes the problem a lot clearer than > >> writing to a random device location would have been). > >> > >> Ganbold's followup shows that the RK3399 allocates 64KiB to the syscon > >> device so the equivalent write is valid on a RK3399. > >> > >> I suspect the problem is that the following defines are only valid for > >> the RK3399 since I can't find any matches to either the names or offsets > >> in the following: > >> #define GRF_SARADC_TESTBIT 0x0e644 > >> #define GRF_TSADC_TESTBIT_L 0x0e648 > >> #define GRF_TSADC_TESTBIT_H 0x0e64c > >> > >> Unfortunately, that also means I currently have no idea what the RK3328 > >> equivalents to those offsets are. > >> > >> -- > >> Peter Jeremy > > > > root@rock64:~ # uname -a > > FreeBSD rock64.home.blih.net 13.0-CURRENT FreeBSD 13.0-CURRENT #13 r355188:355190M: Thu Nov 28 21:43:00 CET 2019 manu@skull.home.blih.net:/usr/home/manu/Work/freebsd/obj/usr/home/manu/Work/freebsd/freebsd-svn/base/head/arm64.aarch64/sys/GENERIC arm64 > > root@rock64:~ # sysctl hw.temperature > > hw.temperature.CPU: 50.7C > > > > Everything is working for me after I've added the clocks, so I don't > > know what's happening for you. But after looking again at the docs it > > seems that rk3328 is a mix between v2 and v3 so the GRF write are wrong. > > I'll have a look today or tomorow and fix this. > > > > Peter, > can you please try following trivial patch? > Michal > This isn't enough, RK3328 initialization is V2 but needs the AUTO_Q_SEL bit too (like v3). There might be other stuff that I haven't found yet. That still doesn't explain why it's working for me (both DEBUG and NODEBUG kernels). -- Emmanuel Vadot