Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758699AbcDEQxl (ORCPT ); Tue, 5 Apr 2016 12:53:41 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:45412 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753456AbcDEQxi (ORCPT ); Tue, 5 Apr 2016 12:53:38 -0400 Date: Tue, 5 Apr 2016 09:53:05 -0700 From: Mark Brown To: Peter Chen Cc: Baolin Wang , Felipe Balbi , Greg KH , Sebastian Reichel , Dmitry Eremin-Solenikov , David Woodhouse , Peter Chen , Alan Stern , r.baldyga@samsung.com, Yoshihiro Shimoda , Lee Jones , Charles Keepax , patches@opensource.wolfsonmicro.com, Linux PM list , USB , device-mainlining@lists.linuxfoundation.org, LKML Message-ID: <20160405165305.GD1924@sirena.org.uk> References: <20160405064637.GA31351@shlinux2.ap.freescale.net> <20160405081222.GC31351@shlinux2.ap.freescale.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iVCmgExH7+hIHJ1A" Content-Disposition: inline In-Reply-To: <20160405081222.GC31351@shlinux2.ap.freescale.net> X-Cookie: Even bytes get lonely for a little bit. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 209.65.105.100 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2595 Lines: 59 --iVCmgExH7+hIHJ1A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 05, 2016 at 04:12:22PM +0800, Peter Chen wrote: > On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote: > > Hi Peter, > > Yeah, this patchset did not give an example to read charger type from > > PMIC registers. (Cause now the user 'wm831x_power' don't need this.) > > But I think user can get it easily by implementing below callbacks. > > (1) gadget->ops->get_charger_type(); > > (2) power_supply_get_property(uchger->psy, POWER_SUPPLY_PROP_CHARGE_TYPE, &val); > > (3) uchger->get_charger_type(); > I just would like if you can have this, then, we (you) can test it, eg, > you can test if the wm831x can charge more than 1500mA for DCP. The hardware in the wm831x is extremely simple here - all it does is take in the power rail from USB, apply a current limit to it and feed it into the power source selection circuitry it has. It doesn't see any of the USB data signals, it relies on the rest of the system to identify and configure the limit by writing a register. The highest limit it supports is 1.8A. > > The framework does not want to focus on charger detection too much, > > and just supplies one callback '->charger_detect()' for user to be > > implemented if they ensure they need to do the SW charger detection > > manually (Note: must at the right time to do the SW detection.). So > > the usb charger just focus on dealing with the usb gadget power > > negotiation, and it does not need to care much how to do charger > > detection on your platform. > No, this comment is common one, but only for SW detection. Eg, when > the PMIC tells you it is a SDP, you can't notify to charger IC about > 500mA at once, you need to do it after host allows you to do it. Note that this isn't just the charger device that needs to constrain current consumption - it's the entire system. You can't charge to the limit for system power draw if the USB controller is supplying the main system rail. --iVCmgExH7+hIHJ1A Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXA+1tAAoJECTWi3JdVIfQX2IH+QEr2tHAwAGVsCI+YJqgRZXw /dCbhw8yo2MnbVWALnfgbqzNjCXKPPExRUip3mx5KPspFdytSZeIjSYg1O7JJuJN vX29sm7fkxLUQqpBt95s4Qh1VHcl7GdhckLyuxQF2mYum0B4pFbEZcEKV96nAu02 5IuVpIiuhnC9uLX/EVs+yVarHjYvwVV+v5AH/xaR/TKqUEvBCh+5Grndpb2VeBc8 9+zkctHc9I05+kv2fiOC0Up+w2PO9LDdiPXiKAFfOjZsRgOY0h/L5XVkZNaw0Kf1 LEBja2rCDKkxPs0KlIGJ/UrHml0vxe4Wy7iuiAzO8E0LoYcyds9WecUJpvm3sM4= =JWD5 -----END PGP SIGNATURE----- --iVCmgExH7+hIHJ1A--