From owner-freebsd-arm@freebsd.org Tue Dec 3 10:14:46 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 B01591A8C34 for ; Tue, 3 Dec 2019 10:14:46 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RyX51lT9z4CDg for ; Tue, 3 Dec 2019 10:14:44 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id xB3AEQru065123 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 3 Dec 2019 21:14:31 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id xB3AEKPX087189 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Dec 2019 21:14:20 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id xB3AEKhS087188; Tue, 3 Dec 2019 21:14:20 +1100 (AEDT) (envelope-from peter) Date: Tue, 3 Dec 2019 21:14:20 +1100 From: Peter Jeremy To: Emmanuel Vadot Cc: Michal Meloun , freebsd-arm@freebsd.org Subject: Re: rk_tsadc breaks (my) Rock64 Message-ID: <20191203101420.GA79817@server.rulingia.com> References: <20191201110716.GA41224@server.rulingia.com> <20191202111322.GF37113@server.rulingia.com> <20191202140416.936a457adebce6fca1341b18@bidouilliste.com> <20191202154548.095d7d8ec8796af15e41e47c@bidouilliste.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <20191202154548.095d7d8ec8796af15e41e47c@bidouilliste.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47RyX51lT9z4CDg X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-7.71 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; IP_SCORE(-3.31)[ip: (-9.64), ipnet: 2001:19f0:5800::/38(-4.83), asn: 20473(-2.02), country: US(-0.05)]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[rulingia.com]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; FREEMAIL_CC(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[] 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: Tue, 03 Dec 2019 10:14:46 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-Dec-02 15:45:48 +0100, Emmanuel Vadot wrote: >> >> Firstly, I've found that the syscon@ff100000 FDT entry attaches as two >> >> distinct devices: >> >> rk_grf0: mem 0xff100000-0xff100fff = on ofwbus0 >> >> (via compatible =3D "rockchip,rk3328-grf") >> >> simple_mfd0: mem 0xff450000-0xf= f45ffff on ofwbus0 >> >> (via compatible =3D "simple-mfd") >> >=20 >> > ??? those aren't the same devices. Yes. Looking more closely, I was wrong. There are 2 GRF devices in the RK3328 that probe/attach separately. > 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). I don't understand how the SYSCON_WRITE_4() operations can work when the offsets are outside the memory range allocated to the device. The other oddity I have is that Rockchip_RK3328TRM_V1.1-Part1-20170321.pdf Table 9-1 (the Temperature-to-code mapping table) is identical to rk3288_calib_data and looks completely different to rk3328_calib_data. (Looking more closely, the values in the two tables sum to 4096). I've tried the following, slightly more extensive patch and now get temperature readings that aren't insane (~40=B0C idle and ~52=B0C under heavy FPU load, at 1200MHz with a small heatsink and active airflow). I haven't worked through the TRM in detail to see if there's anything else missing. Index: rk_tsadc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- rk_tsadc.c (revision 355286) +++ rk_tsadc.c (working copy) @@ -98,11 +98,6 @@ int channel; }; =20 -enum tsadc_type { - RK_TSADC_V2, - RK_TSADC_V3 -}; - struct rk_calib_entry { uint32_t raw; int temp; @@ -109,13 +104,14 @@ }; =20 struct tsadc_calib_info { - bool decrement_mode; + //bool decrement_mode; struct rk_calib_entry *table; int nentries; }; =20 struct tsadc_conf { - enum tsadc_type type; + int use_syscon; + int q_sel_ntc; int shutdown_temp; int shutdown_mode; int shutdown_pol; @@ -188,7 +184,8 @@ }; =20 struct tsadc_conf rk3288_tsadc_conf =3D { - .type =3D RK_TSADC_V2, + .use_syscon=3D 0, + .q_sel_ntc=3D 0, .shutdown_temp =3D 95000, .shutdown_mode =3D 1, /* GPIO */ .shutdown_pol =3D 0, /* Low */ @@ -241,7 +238,8 @@ }; =20 static struct tsadc_conf rk3328_tsadc_conf =3D { - .type =3D RK_TSADC_V3, + .use_syscon=3D 0, + .q_sel_ntc=3D 1, .shutdown_temp =3D 95000, .shutdown_mode =3D 0, /* CRU */ .shutdown_pol =3D 0, /* Low */ @@ -296,7 +294,8 @@ }; =20 static struct tsadc_conf rk3399_tsadc_conf =3D { - .type =3D RK_TSADC_V3, + .use_syscon=3D 1, + .q_sel_ntc=3D 1, .shutdown_temp =3D 95000, .shutdown_mode =3D 1, /* GPIO */ .shutdown_pol =3D 0, /* Low */ @@ -444,11 +443,11 @@ val |=3D TSADC_AUTO_CON_POL_HI; else val &=3D ~TSADC_AUTO_CON_POL_HI; - if (sc->conf->type =3D=3D RK_TSADC_V3) + if (sc->conf->q_sel_ntc) val |=3D TSADC_AUTO_Q_SEL; WR4(sc, TSADC_AUTO_CON, val); =20 - if (sc->conf->type =3D=3D RK_TSADC_V2) { + if (!sc->conf->use_syscon) { /* V2 init */ WR4(sc, TSADC_AUTO_PERIOD, 250); /* 250 ms */ WR4(sc, TSADC_AUTO_PERIOD_HT, 50); /* 50 ms */ --=20 Peter Jeremy --azLHFNyN32YCQGCU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAl3mNXVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzSlxg/9Hz2oeasbmcGxMjr4LPqgAY7ozF0QoYFUCzsf8DMPjNKdtufnbPqWhH+Y nqrrDGuNJqxQSs4EmX1GnFBxXIr01i7GDF7Dz4041HbvyQ8HAzcOGQ/GSkgppdnI N8FaXlkOQex3UyoQe/IoiKqRiqsi8llZ/r3I5SIR6hWA3bv33RNilpGGAjfh4TQI 1n2iN1IhEkGX8iGYlZu+wfuxUiH+35Pzpsvz33Ioqv5Q1FUauvu8HWF/muNUzU7Z aAh98QaIiZFXl0XgcnOv2idU9cz8JhyeTXcjwl+PwXfEIvClfR6I4DBsOwwid+1+ rNNCbK4sTwfmEek9ExhMV4FwSDQvqwr6HZQw/6e72FU3g82T4NsiAnms1jvaP2Be 44jtwuiNbQXy/hxZiPzuHxn0hYrCUi5HpNAEPteP9ZLXQnZsy7Uk4UnBs4TlTIm+ 4N969Wel3Zk4qF0+AJrYH6/EKhaXovSjPbJANq8+DfobE9cB/bOJjI8vks6Y7Vl4 2ZcVXAgs3RTf75PCQOwxdOUnd/DFmaLxa7VGAYahoC47ntgytbvrd5S2ooLgahFr 0ajpbTKPXDWcMvTiR7H1mySid6szu5ALXOoMntw7tCqLcaPYA5Ya8mfcYkVsuMYh 1tiWVHRY9fk7x/eFecCTGcb65AeLoJh0UAu1dVoOpFyzBwJ5cJg= =o6z7 -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU--