From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751173AbdFAOyj (ORCPT ); Thu, 1 Jun 2017 10:54:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57216 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751078AbdFAOyi (ORCPT ); Thu, 1 Jun 2017 10:54:38 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A3A893DBEC Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hdegoede@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A3A893DBEC Subject: Re: [PATCH v1 1/1] mux: mux-intel-usb: Add Intel USB Multiplexer driver To: sathyanarayanan.kuppuswamy@linux.intel.com, Andy Shevchenko Cc: Peter Rosin , "Krogerus, Heikki" , "linux-kernel@vger.kernel.org" , Sathyanarayanan Kuppuswamy Natarajan References: <84e3fdaf979c070a5c39c7635910fee30c3a8b06.1496104447.git.sathyanarayanan.kuppuswamy@linux.intel.com> <0e2a3df8-e3b4-28d3-eea9-5ec6a684bf53@linux.intel.com> <402e68ce-0fcd-bfe5-0db5-b02526937495@linux.intel.com> From: Hans de Goede Message-ID: <372ee565-7add-c81e-46cd-5696e03bfe6e@redhat.com> Date: Thu, 1 Jun 2017 16:54:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <402e68ce-0fcd-bfe5-0db5-b02526937495@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 01 Jun 2017 14:54:38 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org HI, On 01-06-17 01:12, sathyanarayanan kuppuswamy wrote: > Hi Hans, > > > On 05/31/2017 05:21 AM, Hans de Goede wrote: >> Hi, >> >> On 30-05-17 20:50, Andy Shevchenko wrote: >>> On Tue, May 30, 2017 at 9:21 PM, sathyanarayanan kuppuswamy >>> wrote: >>>>> On Tue, May 30, 2017 at 3:47 AM, >>>>> wrote: >>> >>>>>> + tristate "Intel USB Mux" >>>>> >>>>> It's indeed Intel's IP? >>>> >>>> Register map to control this MUX comes from Intel vendor defined XHCI >>>> extended cap region of SOC. >>>>> >>>>> I would rather believe that it is some 3rd >>>>> party known IP block with platform specific soldering. >>>> >>>> I don't think its platform specific support. I believe its a SOC specific >>>> thing( mainly for CHT and APL SoCs). >>> >>> Okay, the best people to give a feedback here are Heikki and Hans. >> >> Interesting, I have been working on this myself too (and posted >> a version of my driver for the mux block a while back), see: >> >> https://www.spinics.net/lists/linux-usb/msg151032.html >> https://www.spinics.net/lists/linux-usb/msg151033.html >> https://www.spinics.net/lists/linux-usb/msg151034.html >> >> I was actually planning on posting a new version of this set >> soon. I still need to to modify the first patch to trigger >> bu PCI-ids to avoid registering non existing mux platform >> device on non CHT / APL Intel platforms. >> >> I've since changed the second patch into a platform driver, >> see: >> >> https://github.com/jwrdegoede/linux-sunxi/commit/e51057609102c35dd35b4a5965139aff81fbefb8 >> >> Note that this patch has 2 differences compared to >> sathyanarayanan's patch: >> >> 1) It ties directly into the extcon framework and responds >> to extcon events instead of using the mux framework, > What about devices with no ID events ? At least the APL device that I am > using does not have external IRQ for VBUS and ID. >> actually this is the first time I hear about a mux framework >> at all. Is there a git tree with the patches for this somewhere ? >> >> 2) It controls the ID and VBUS bits separately, this is >> important because on some Cherry Trail devices the ID bit >> is automatically set be ACPI code (through a gpio irq >> event handler), but the ACPI code does not update the >> VBUS bit causing the otg port on these devices to not >> work in device mode. > Even if you listen to ID and VBUS events separately, I think the end > result is selecting either SW host or SW device mode right ? No, the ID bit causes the mux to get thrown either way, the VBUS bit causes the device controller to see a connect or not. > Then why not abstract MUX functionality outside the your driver and > control the MUX from your driver appropriately ? or do we get > any advantage is modifying just VBUS_VALID or SW_IDPIN bits > separately ? They MUST be controlled separately because on some systems the SW_IDPIN bit is controller by ACPI AML code, where as the VBUS_VALID needs to be set by the kernel. We could model the VBUS_VALID bit as a separate mux_controller, that would be a bit weird though ... Regards, Hans