Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756503AbdCGWdL (ORCPT ); Tue, 7 Mar 2017 17:33:11 -0500 Received: from mail-lf0-f68.google.com ([209.85.215.68]:35675 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756180AbdCGWdH (ORCPT ); Tue, 7 Mar 2017 17:33:07 -0500 Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class To: Heikki Krogerus , Guenter Roeck 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> <20170306131442.GC6999@kuha.fi.intel.com> Cc: Greg KH , Felipe Balbi , Oliver Neukum , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org From: Mats Karrman Message-ID: <696552a7-c36a-1d73-9517-543907e9da39@gmail.com> Date: Tue, 7 Mar 2017 23:30:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170306131442.GC6999@kuha.fi.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2526 Lines: 51 On 2017-03-06 14:14, Heikki Krogerus wrote: > Hi Mats, > > On Fri, Mar 03, 2017 at 08:27:08PM +0100, Mats Karrman wrote: >>>> 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? OK, so a bus could be used for drivers to find each other but it still does not say anything about how those drivers are supposed to communicate so that must be prescribed separately, right? If I read Heikki's original suggestion I understand it like the DP driver would be responsible for AM specific USB PD/VDM communication. But wouldn't that lead to a lot of code duplication since the AM protocol is the same for all drivers of a kind? I'm still struggling to catch up on what you guys have been up to during the last year or so :-) and came across some patches of Guenter from last October: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1243527.html What happened to them? Has there been any progress since then? BR // Mats