From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753010AbdCFNmA (ORCPT ); Mon, 6 Mar 2017 08:42:00 -0500 Received: from mga01.intel.com ([192.55.52.88]:25884 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752209AbdCFNlv (ORCPT ); Mon, 6 Mar 2017 08:41:51 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,253,1484035200"; d="scan'208";a="56564747" Date: Mon, 6 Mar 2017 15:14:42 +0200 From: Heikki Krogerus To: Mats Karrman Cc: Guenter Roeck , Greg KH , Felipe Balbi , Oliver Neukum , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class Message-ID: <20170306131442.GC6999@kuha.fi.intel.com> References: <20170221142405.76299-1-heikki.krogerus@linux.intel.com> <20170221142405.76299-3-heikki.krogerus@linux.intel.com> <4b4bbffc-db02-3b54-04bc-e7de79b2d9ed@roeck-us.net> <07618170-d561-e7fe-08e0-91316c53d832@gmail.com> <20170303125940.GA6999@kuha.fi.intel.com> <6ddb2eac-03d5-127e-df1e-ad189968e6b2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ddb2eac-03d5-127e-df1e-ad189968e6b2@gmail.com> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mats, On Fri, Mar 03, 2017 at 08:27:08PM +0100, Mats Karrman wrote: > On 2017-03-03 13:59, Heikki Krogerus wrote: > > > On Fri, Mar 03, 2017 at 08:29:18AM +0100, Mats Karrman wrote: > > .... > > > How would something like that sound to you guys? > > Complicated... Need to marinate on that for a while ;) Sorry about the bad explanation :-). Let me try again.. I'm simply looking for a method that is as scalable as possible to handle the alternate modes, basically how to couple the different components involved. Bus would feel like the best approach at the moment. > > > My system is a bit different. It's an i.MX6 SoC with the typec phy and DP controller connected > > > directly to the SoC and it's using DTB/OF. > > Is this "DP controller" a controller that is capable of taking care of > > the USB Power Delivery communication with the partner regarding > > DisplayPort alternate mode? > > No, the "DP controller" just talks DP and knows nothing about Type-C or USB PD. > It takes a video stream from the SoC and turns it into a DP link, set up and orchestrated > by the corresponding driver. And all the driver needs from Type-C is the plugged in / interrupt / > plugged out events. Got it. > The analog switching between USB / safe / DP signal levels in the Type-C connector is, I think, > best handled by the software doing the USB PD negotiation / Altmode handling (using some GPIOs). > > > > Do we need to further standardize attributes under (each) specific alternate mode to > > > include things such as HPD for the DP mode? > > I'm not completely sure what kind of system you have, but I would > > imagine that if we had the bus, your DP controller driver would be the > > port (and partner) alternate mode driver. The bus would bind you to > > the typec phy. > > So, both the DP controller and the USB PD phy are I2C devices, and now I have to make them both > attach to the AM bus as well? The DP controller would provide the driver and the USB PD phy (actually, the typec class) the device. Would it be a problem to register these I2C devices with some other subsystem, was it extcon or something like AM bus? It really would not be that uncommon. Or have I misunderstood your question? Thanks, -- heikki