From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751638AbcFUN64 (ORCPT ); Tue, 21 Jun 2016 09:58:56 -0400 Received: from mga04.intel.com ([192.55.52.120]:32552 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750707AbcFUN6z (ORCPT ); Tue, 21 Jun 2016 09:58:55 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,504,1459839600"; d="scan'208";a="1006679585" Date: Tue, 21 Jun 2016 16:58:45 +0300 From: Heikki Krogerus To: Oliver Neukum Cc: Guenter Roeck , Andy Shevchenko , Rajaram R , Felipe Balbi , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class Message-ID: <20160621135845.GA10715@kuha.fi.intel.com> References: <1463661894-22820-1-git-send-email-heikki.krogerus@linux.intel.com> <1466514532.2091.5.camel@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1466514532.2091.5.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 On Tue, Jun 21, 2016 at 03:08:52PM +0200, Oliver Neukum wrote: > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > > The purpose of this class is to provide unified interface for user > > space to get the status and basic information about USB Type-C > > Connectors in the system, control data role swapping, and when USB PD > > is available, also power role swapping and Alternate Modes. > > This raises two more questions. > > 1. Booting > > It is possible that our only display and, worse, our source > of power is a display that can be used only in an alternate mode > and is connected via a type C connector. > > We need some kind of boot time support for alternate modes. > > 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. 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. > 2. Multiple GPUs > > How do we know which GPU is connected to which port? With ACPI we will have to be able to bind the correct companion to the device presenting the DP alternate mode under the port. Just like we will have to bind the ACPI companion of the actual USB port to the typec port device itself. Cheers, -- heikki