From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751809AbcFVJkq (ORCPT ); Wed, 22 Jun 2016 05:40:46 -0400 Received: from mga01.intel.com ([192.55.52.88]:42874 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751078AbcFVJkn (ORCPT ); Wed, 22 Jun 2016 05:40:43 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,509,1459839600"; d="scan'208";a="126531511" Date: Wed, 22 Jun 2016 12:31:57 +0300 From: Heikki Krogerus To: Oliver Neukum Cc: Andy Shevchenko , Rajaram R , Felipe Balbi , Mathias Nyman , Greg KH , Guenter Roeck , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class Message-ID: <20160622093156.GA19856@kuha.fi.intel.com> References: <1463661894-22820-1-git-send-email-heikki.krogerus@linux.intel.com> <1466514532.2091.5.camel@suse.com> <20160621135845.GA10715@kuha.fi.intel.com> <1466541785.2014.16.camel@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1466541785.2014.16.camel@suse.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Oliver, On Tue, Jun 21, 2016 at 10:43:05PM +0200, Oliver Neukum wrote: > On Tue, 2016-06-21 at 16:58 +0300, Heikki Krogerus wrote: > > On Tue, Jun 21, 2016 at 03:08:52PM +0200, Oliver Neukum wrote: > > > > > The firmware will surely want to display something. So it is possible > > > that we start the OS will a valid power contract. How do we deal > > > with that? Renegotiate? > > > > Systems where the firmware has to negotiate PD will likely provide > > firmware interface like UCSI, and where the OS has no direct > > interaction with the USB PD transceiver. In these case there is no > > need to renegotiate as we are just reporting in OS the initial state > > after bootup. > > How certain is that? I was under the impression that on many systems > the OS would speak to the TCPM directly. I think we gonna see systems where the OS has access to TCPC and where the TCPM is expected to be implemented in the OS, but we will have quite a few systems where the TCPC/PD controller/non TCPC compliant Type-C PHY is attached to a microcontroller like EC, and where that microcontroller will implement TCPM and the OS is exposed just a separate interface, most likely UCSI. > > We do have a system where the typec port is used to power the board. > > On these systems the firmware does not communicate PD (so we will > > never have the firmware displaying anything over Type-C on those > > systems), but the USB PD chargers for example are detected as 3.0A > > Type-C power supplies before any USB PD negotiation takes place, just > > like the spec says, and that is more then enough to power these boards. > > Now correct me, if I am misreading the spec. I am sure the system > will boot unless it needs ridiculous amounts of power, but > will we see anything on the screen? As far as I can tell the spec > actually says that you cannot enter an alternate mode without having > established a power contract. > If we really leave entering modes up to user space, we have lost > printk before getting into the initrd at the earliest. With these boards, you will not see anything on the screen that is attached to a Type-C connector until the OS has booted to the point where it has negotiated the power contract and entered a mode. If the system has BIOS/FW/EC capable of negotiating the power contract and enter a mode, but where we still are expected to take over the whole TCPM in OS, I think the connection will be reset. Thanks, -- heikki