From owner-freebsd-arm@freebsd.org Tue Jun 25 15:58:12 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E1A315D0443 for ; Tue, 25 Jun 2019 15:58:12 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7EE26A168 for ; Tue, 25 Jun 2019 15:58:10 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Tue, 25 Jun 2019 17:58:02 +0200 id 00DD62E9.5D12448A.00002917 Date: Tue, 25 Jun 2019 17:58:02 +0200 From: Milan Obuch To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org Subject: Re: Pine64+ HDMI output note Message-ID: <20190625175802.50c8c3e0@zeta.dino.sk> In-Reply-To: <20190625083249.8802d2fb4723a8c7c79bf953@bidouilliste.com> References: <20190616093439.5bcbe869@zeta.dino.sk> <20190625083249.8802d2fb4723a8c7c79bf953@bidouilliste.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; i386-portbld-freebsd11.2) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A7EE26A168 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk X-Spamd-Result: default: False [-5.42 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dino.sk]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mail.dino.sk]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[72.65.245.84.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; IP_SCORE(-2.13)[ip: (-6.74), ipnet: 84.245.64.0/18(-3.37), asn: 16160(-0.60), country: SK(0.07)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16160, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2] 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, 25 Jun 2019 15:58:12 -0000 On Tue, 25 Jun 2019 08:32:49 +0200 Emmanuel Vadot wrote: > On Sun, 16 Jun 2019 09:34:39 +0200 > Milan Obuch wrote: [ snip ] > > which makes me think, together with presence of getty processes > > attached to /dev/ttyvN devices, that all what's missing is just > > physical video output signal, and this is most probably caused by > > output buffer being shut down. So I googled a bit and found a hint, > > tried it - I put line > > > > hw.regulator.disable_unused=0 > > > > into /boot/loader.conf file and it works. I think it just uses HDMI > > output engine configured by u-boot instead of configuring it > > itself, as we have no driver for hdmi and hdmi-phy devices on A64 > > SoCs. > > With this you are using efifb. > The reason for the tunable is that since there is no node in the dtb > related to efifb the kernel will shutdown every regulator that isn't > referenced, this is 1) to save power 2) to do the same thing as the > Linux kernel as at one point I commited some bad DTS into Linux where > almost every regulator got shutdown after a while. > Thanks for explanation. > > Maybe this is just as simple as adding appropriate compatible string > > into arm/allwinner/a10_hdmi.c file, but I do not know if A20 and A64 > > cores are compatible in this area... and workaround found is just OK > > for me. > > No, A64 uses the version 2 of the Allwinner display engine, I have a > DRM driver working for it (but still have some work to do on it). > https://github.com/evadot/freebsd/tree/drm_aw_de2 > OK. Maybe I'll try it, but I have no immediate need for it... good to know I can expect it in some future, far or near :) > > Next step would be to try X on Pine64+... Any hint on this? I am > > going to try scfb video driver for this, as noted on > > FreeBSD/arm/Allwinner wiki page. As for this wiki page - maybe it > > could be updated in 'supported devices' table, in column A64 - I > > think framebuffer works and HDMI video too, kind of, leaving it in > > pre-initialised state with above mentioned workaround. > > SCFB driver will work correctly with efifb. > Confirmed. I checked it on my Pine64-LTS acquired recently as well. Now I am trying various ports/applications on it when time permits... Regards, Milan