From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751876AbcFUNZO (ORCPT ); Tue, 21 Jun 2016 09:25:14 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:35728 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750783AbcFUNZM (ORCPT ); Tue, 21 Jun 2016 09:25:12 -0400 Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class To: Oliver Neukum , Heikki Krogerus References: <1463661894-22820-1-git-send-email-heikki.krogerus@linux.intel.com> <1466514532.2091.5.camel@suse.com> Cc: Andy Shevchenko , Rajaram R , Felipe Balbi , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org From: Guenter Roeck Message-ID: <57694020.6070300@roeck-us.net> Date: Tue, 21 Jun 2016 06:24:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <1466514532.2091.5.camel@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/21/2016 06:08 AM, 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? > In one of my drivers, the PD protocol is running on an EC and the Linux driver is just interfacing it to the typec class. I don't do any renegotiating but just report the port state to the class. What is wrong with that, and why would it not work ? If the PD protocol runs in Linux (which I implement as well), I tried renegotiating, ie assuming that a contract was already established, with several multi-function adapters. Quite often those 'die' when trying tricks like that, and have to be manually disconnected from power (on both ends) to get back to life. Granted, part of that is that the firmware on those adapters is early and not as stable as I would like it to be, but still that is a significant risk. I ended up always starting with error recovery to avoid that kind of problem, at least for now. Even that doesn't always help. > 2. Multiple GPUs > > How do we know which GPU is connected to which port? > Still working on it, but the basic idea (in my case) is to use devicetree data or platform data if that is not available. Guenter