From owner-freebsd-current@freebsd.org Thu Nov 22 12:51:46 2018 Return-Path: Delivered-To: freebsd-current@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 90E9C1147FBD for ; Thu, 22 Nov 2018 12:51:46 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36BFD75412; Thu, 22 Nov 2018 12:51:46 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 740CF221B9; Thu, 22 Nov 2018 07:51:45 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 22 Nov 2018 07:51:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=b3Jn/2 gJbtUgWA8xRk7JJAm7IaPv/MtK8GW9r1zkMCE=; b=xjDGCG3flpRpi6Y0DZIHRG S/vjwZTlPaoj+zaIhQkI4Z/rLOAA2tsfjgWADoHMARjwSVbcFvFZkf5m1zjWSicg 1jPKAx5M5KkmDigBPueeDvKn9VOamxg0aXRfto0/Ux57PxpJY1NoTKvSvtP/G8Fs LbwDYd88JQyJAXVVWu/3dqwAczCuFPSOPEhfAKpUr1vc0ZaRcBXKnAj8iFG2fins oRtEx8PbGzaVFCwyZWUtTia3r0gh6FcHdsLksbe9GFQ0Hb6+HOCJaf//dUSKsC5P Fc+49u+YYk+sETGtAgJ5prrHZinZY4E5r4IVWSaL9s8Ay39u/NwgeWL/gwtZ9MPg == X-ME-Sender: X-ME-Proxy: Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [137.50.17.12]) by mail.messagingengine.com (Postfix) with ESMTPA id 0594D102A0; Thu, 22 Nov 2018 07:51:43 -0500 (EST) Date: Thu, 22 Nov 2018 12:51:42 +0000 From: Tom Jones To: Emmanuel Vadot Cc: Johannes Lundberg , freebsd-current , manu@freebsd.org Subject: Re: axp288 on Intel HW Message-ID: <20181122125141.GA34096@tom-desk.erg.abdn.ac.uk> References: <20181122061745.98faaa8b790e97c7da019588@bidouilliste.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181122061745.98faaa8b790e97c7da019588@bidouilliste.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 36BFD75412 X-Spamd-Result: default: False [0.42 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.06)[-0.062,0]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; NEURAL_SPAM_SHORT(0.51)[0.510,0]; NEURAL_HAM_LONG(-0.03)[-0.027,0] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 12:51:46 -0000 On Thu, Nov 22, 2018 at 06:17:45AM +0100, Emmanuel Vadot wrote: > > Hi, > > Allwinner PMIC on X86, interesting :) > > On Fri, 16 Nov 2018 08:51:31 +0000 > Johannes Lundberg wrote: > > > Hi > > > > I have a Lenovo Ideapad Miix 310 that has a Intel CherryTrail CPU and it > > runs FreeBSD quite nicely (with accelerated graphics). What I'm missing is > > battery life status.. > > > > I can get this information using smb (for some reason i2c just returns > > error sending start condition) > > smbmsg -f /dev/smb6 -s 0x68 -c 0xB9 -i 1 -F %d > > > > In emergency this works but it would be nice to have a kernel driver for > > it. > > > > I found the axp2xx driver for Allwinner in the tree. Would it be possible > > to share this with amd64 with not too much effort? > > The first step would be to add acpi attach functions (no idea how this > works), then compare the registers with the pmics supported by the > axp2xx driver to check what regulators are present and controllable (if > any) and also checking the registers for talking to the battery > controller part. > I don't see why it wouldn't work but I haven't checked details on how > supported chips differs with this one. > > > > > If not, all I'm really interested in is battery status so I might just hack > > together a simple driver for that report values to hw.acpi.battery (because > > I don't think there is a sysctl for battery info that aggregates different > > sources?) > > We don't have a generic battery/power supply framework yes. On an ACPI there is an IOCTL that will collate battery information from anything in the battery devclass. There is an acpi_battery_register function, but what it actually does is set up sysctls. I have a patch to land (hopefully this week) that you would need first. I have a driver for a maxim fuel gauge on a unreasonably complicated laptop that includes an example of what you have to do to be a battery: https://github.com/adventureloop/gpdpocket/blob/master/chvpower/chvpower.c#L148 To support battery on arm (say for the pinebook) we need a more general system. I plan to extract out the current battery code from acpi as a first attempt at this. - [tj]