On Thu, Dec 07, 2017 at 05:40:40PM +0100, Hans de Goede wrote: > Hi, > > On 07-12-17 16:00, Heikki Krogerus wrote: > > Hi Hans, > > > > On Tue, Dec 05, 2017 at 03:56:05PM +0100, Hans de Goede wrote: > > > Hi, > > > > > > On 01-12-17 09:38, Heikki Krogerus wrote: > > > > Hi, > > > > > > > > Thanks for taking a look at this.. > > > > > > > > On Sun, Nov 26, 2017 at 12:23:31PM +0100, Hans de Goede wrote: > > > > > Hi Heiko, > > > > > > > > > > On 28-09-17 13:35, Heikki Krogerus wrote: > > > > > > Hi guys, > > > > > > > > > > > > The bus allows SVID specific communication with the partners to be > > > > > > handled in separate drivers for each alternate mode. > > > > > > > > > > > > Alternate mode handling happens with two separate logical devices: > > > > > > 1. Partner alternate mode devices which represent the alternate modes > > > > > > on the partner. The driver for them will handle the alternate mode > > > > > > specific communication with the partner using VDMs. > > > > > > 2. Port alternate mode devices which represent connections from the > > > > > > USB Type-C port to devices on the platform. > > > > > > > > > > > > The drivers will be bind to the partner alternate modes. The alternate > > > > > > mode drivers will need to deliver the result of the negotiated pin > > > > > > configurations to the rest of the platform (towards the port alternate > > > > > > mode devices). This series includes API for that, however, not the > > > > > > final implementation yet. > > > > > > > > > > > > The connections to the other devices on the platform the ports have > > > > > > can be described by using the remote endpoint concept [1][2] on ACPI > > > > > > and DT platforms, but I have no solution for the "platform data" case > > > > > > where we have neither DT nor ACPI to describe the connections for us. > > > > > > > > > > Sorry about the slow reply, I've been a bit swamped with other stuff, > > > > > but now I would like to get back to this. > > > > > > > > > > I've been trying to wrap my head around what you're proposing here and > > > > > I see how this can help with implementing display-port alternate mode > > > > > support, but I don't see how it is going to help with regular superspeed > > > > > USB support / the mux problem. > > > > > > > > > > The problems I see / questions I have are: > > > > > > > > > > 1) This seems to be driven by having a bus using svid-s as match functions, > > > > > but the standard USB function does not have any svid, or at least currently > > > > > does not show as such under e.g. /sys/class/typec/port0/port0-partner > > > > > > > > USB is the "normal" mode, not alt-mode. We don't need any specific > > > > driver for the USB mode. In alternate modes, we have to communicate > > > > with the partner using SVID specific messages, and that is what we > > > > need the drivers for. > > > > > > Ack, but we do still need to control the mux in USB-mode I was under > > > the impression that the alt-mode drivers would be responsible for > > > switching the mux to the right component in the graph, if (which > > > may not be true) the alt-mode drivers indeed will be the ones controlling > > > the mux, then we need a dummy alt-mode for USB mode and a dummy > > > alt-mode driver for that. > > > > The Type-C/PD PHY/controller drivers (the port drivers) will be in > > control of the dual-role (USB) mux, not an alternate mode driver. The > > port driver will know if we need to be UFP or DFP in any case, so it > > just needs to pass that detail to the mux driver. There is no need for > > an extra driver in the middle just for that. > > Right, but that only deals with the "USB MUX" i your ascii-art > diagram not with the one you labelled "MUX" and the one you labelled > "MUX" also needs to switch between "tristate(floating) / normal SuperSpeed USB / > upside-down SuperSpeed USB. Well, I would say the cable orientation is actually a third mux, missing from my ascii-art. > > But logically we will have two muxes to deal with - one for the USB > > handled by the port drivers, and one for the type-c handled by the > > alt-mode drivers - even in case the same physical mux component > > handles both cases on the platform. > > Right, but as mentioned above even for just the non alt-mode Superspeed > USB stuff to work we also need to control the Type-C mux/switch. Yes, you are correct. > > > > > 2) The alt-mode drivers you are suggesting seem to be about 2 things: > > > > > a) Alt-mode specific PD communication > > > > > b) Telling other components about pin-configs, e.g. telling the i915 driver how > > > > > much display port lanes are configured > > > > > > > > > > What this seems to miss a mechanism to control the mux between the "superspeed" > > > > > data-pairs on the port and the dp-port pins on the SoC / the superspeed USB > > > > > pins on the SoC. Even leaving display-port out of the picture for now we still > > > > > need to control the port -> SoC superspeed pins routing which need to be > > > > > one of: tristated (default) / normal / upside-down routing. > > > > > > > > We will need to deliver the orientation to the GPU/DP drivers and I'm > > > > not supporting that yet in this draft. > > > > > > That depends, at least with the PI3USB30532 USB switch, the switch/mux > > > should take care of upside-downness, but I believe I remember some other > > > hw where the displayport lanes get swapped when upside down, so I guess > > > that we need to add info like if the upside-downness is handled inside > > > the mux to the graph info. > > > > Good point. That needs to be considered. > > > > > > I'm preparing a more complete > > > > version of these, and I'll propose something for the orientation as > > > > well, though it is a little bit out side the scope of this series. > > > > That information comes from the device drivers or tcpm, not the > > > > alternate mode drivers. > > > > > > > > The USB MUX question is a separate topic, however, the idea of > > > > describing the connections a Type-C port (or any usb port) has to > > > > other components in ACPI and DT, including the USB mux, should be done > > > > using device graph (remote-endpoints) in the future. For the existing > > > > boards we need to figure out somekind of a lookup method to do the > > > > same, and that is the biggest missing thing we still have IMO. > > > > > > If you can provide proof-of-concept code for the graph stuff + > > > code to driver the mux from there, etc. perhaps even tested on > > > a device which has the graph in dt so that it actually works :) > > > > Unfortunately I don't have actual hardware to test that with, but I > > can add dummy devices to the ACPI tables that pretend to be muxes, and > > link them to the type-c connector devices using the remote-endpoints. > > > > I'm not going to use any of_* or acpi_* functions, nor DT platforms > > for testing (I don't have access to any). I'm will use the generic > > fnode_graph_* functions, so if I get something working on ACPI > > platform, I will assume it works also on DT platforms. > > > > > Then I can try to implement a lookup method for my Cherry Trail + > > > Whiskey Cove PMIC + FUSB302 USB Type-C Controller + PI3USB30532 > > > USB switch boards. > > > > You know, you could actually test the code for me already with added > > ACPI tables. I can write ASL for you? If you could also test the DP > > alt-mode driver I have as well, I would really appreciate it. > > With the remark / caution that this is a spare time project for me, so that > you may see bursts of activity followed by long-ish silence, sure I > would love to test this. np. > > > > --------------- > > > > | Type-C port | > > > > --------------- > > > > | > > > > ------- > > > > / MUX \ > > > > ----------- > > > > / \ > > > > / \ > > > > / \ > > > > ---------- --------- > > > > | GPU | / USB MUX \ > > > > ---------- ------------- > > > > / \ > > > > / \ > > > > / \ > > > > ------------------- --------------------- > > > > | Host controller | | Device controller | > > > > ------------------- --------------------- > > > > > > > > > Yes this is pretty much what my HW looks like :) > > > > > > > > ### end Type-c discussion ### > > > > > > > > > > ### Related USB device/host mode switch discussion ### > > > > > > > > > > Another problem for USB is even once the right pins on the port are routed to > > > > > the right pins on the SoC then the SoC may have an internal mux to route > > > > > all the USB pins (both USB-2 and superspeed) to either the host or device > > > > > USB controller. > > > > > > > > > > My previous patches for this tried to use the mux framework for this, but that > > > > > was nacked because of a misunderstanding how the current mux framemork works. > > > > > > > > > > The current mux framework is based on the notion of there being a shared > > > > > bus between e.g. the SoC and various devices, where the devices are not > > > > > directly addressable from the bus, but there is a mux in between which > > > > > connects the SoC to the device it wants to talk to. So the SoC can reach > > > > > all connected devices, but only one add at a time. To make this clear > > > > > a driver talking to one of the devices needs to switch the mux to a > > > > > specific device and then release the mux when it is done. If another > > > > > driver tries to switch the mux before it is released its request will > > > > > block until the mux gets released. > > > > > > > > If the framework was designed for only such specific cases, I'm not > > > > sure it should be called "mux framework" at all. > > > > > > I think it was mainly designed to model (ARM + devicetree) boards > > > with i2c muxes on them. > > > > > > > > With USB OTG / Type-C things are different, there is only one device > > > > > connected, and depending on which type of device is detected as being > > > > > connected we need to connect the OTG / Type-C port pins to the > > > > > corresponding controller inside the SoC. There is no "time-shared" > > > > > access to multiple devices at the same time. Thus the current mux > > > > > subsys is a poor match for the needs for USB OTG / Type-C. > > > > > > > > > > One option I've been considering is to introduce a new usb_mux subsys > > > > > when I get around to this (hopefully sometime the coming month) which > > > > > will be modelled after the mux subsys, but without the "time-sharing" > > > > > concepts and thus without the need to release a mux setting before > > > > > the mux can be switched to route the data else where. > > > > > > > > Wasn't that basically what Baolu proposed [1] ? > > > > > > More or less, that seems to lack anyway to lookup a mux device though, > > > typically you will want to have one driver for the mux and another > > > which decides what the role should be, that second driver needs a way > > > to lookup the mux, so that it can then actually call portmux_switch() > > > (in Baolu's code) on the mux to switch its role. > > > > > > > I really hoped we had a generic mux framework instead of usb specific > > > > one. How about if you call it "demux framework" :-) > > > > > > I like Baolu's portmux name, and I like the over structure from the > > > existing mux framework, Peter Rosin the mux framework maintainer does > > > not really want to extend the existing mux framework for the Type-C > > > use-case it seems and perhaps more importantly the DT bindings for > > > the existing framework are a poor match for Type-C I think, so > > > maybe as part of the graph work you can do a new portmux; or > > > graphmux core (this can be quite small) which the Type-C code can > > > use and which ties into the graph DT bindings ? > > > > I don't have any ideas for the mux subsystem (except that we > > should probable use device graph as the method for the bindings). I > > was hoping that we have a generic mux framework that we can use, but > > we need it for USB, and to be honest, we need it quickly. > > > > I was hoping that you will send a proposal for the usb_mux idea. If > > you are too busy at the moment, let me know. > > Ok, my plan was to simply copy + paste (with some renames) the existing > mux subsys (as I already have working code for that) and then rip-out > the "time-sharing" bits. I can still take a shot at doing that and > then we can see from there. OK, great! One thing that the mux framework is missing, but what we will need, is user space control. We need to be able to request role swapping in some cases from user space when the connector is not Type-C. > About my working code using the existing mux framework (which has been > more or less nacked), if you want to take a peek you can find it here: > > https://github.com/jwrdegoede/linux-sunxi/commits/v4.14-footrail > > The commits which are relevant to this start with the commit titled: > "mux: core: Add mux_control_get_optional() API" > and end with: > "platform/x86: intel_cht_int33fe: Add mux mappings for the Type-C port" Thanks, I'll take a peek. > > > > In any case, we still need a way to describe the connections. I don't > > > > think we should propose yet an other framework specific lookup method. > > > > There really should be a generic "device graph for board files" > > > > solution that we could use also here. Well, ideally. > > > > > > Ack, for me this is a sparetime project and I don't think having > > > 2 chefs in the kitchen is going to help here. So I'm just going to > > > wait and see what you come up with. > > > > I don't see any conflicts in our efforts, especially if we first > > consider only the USB muxes. We really need a solution for the USB > > muxes, not only because of USB Type-C, > > Ack we need it for OTG on micro-USB connectors too. > > > and I'm not proposing anything > > for that. All I'm doing is proposing a way we handle the alternate > > modes inside the USB Type-C frameworks. > > > > If you can prepare something for the usb_mux, I would really _really_ > > appreciate it. The lookup would be ideally something generic, but we > > can hack initially. > > I currently have a hack which assumes a lookup table gets filled by > platform specific code (platform/x86 drivers binding to some ACPI > devs in my case) I can easily port this from the existing not > as generic as we hoped mux framework to a new usb_mux framework. > > > > If you've something which is > > > testable even if I still need to hack together the lookup stuff > > > let me know and I will try to get it going for my boards / use-case. > > > > Cool, I'll start preparing the code for you. Can you send me ACPI dump > > of the board so I can prepare the ASL for the remote endpoints? > > I'll send you the dump in a private mail. Note the Type-C stuff > currently is mostly described by the int33fe device to which I currently > add a bunch of manual lookups for my mux WIP in this commit: > https://github.com/jwrdegoede/linux-sunxi/commit/6667304b5d10e74e3cdcfb6c8fba2bf1004e0761 > > The "WIDR" int33fe device (the one which has a non 0 _STA return) contains 4 > I2cSerialBusV2 resources for 4 different chips attached to various i2c busses: > 1. The Whiskey Cove pmic, which is also described by the INT34D3 ACPI device > 2. Maxim MAX17047 Fuel Gauge Controller > 3. FUSB302 USB Type-C Controller > 4. PI3USB30532 USB switch Oh, ic. So int33fe is mfd that presents all those components... > Not sure of this is relevant for your "remote endpoints" ASL, but in > case you need to tie them to something I guess the "WIDR" int33fe device > is the one to use. Well, that actually makes this a bit tricky. In order to take advantage of the remote-endpoints, we would need separate device objects in the ACPI for all the components. A remote-endpoint is just a reference to an other device object. I'll think about this, but the remote-endpoint support is not the first priority. We will have to use lookups with the existing platforms in any case. Let's concentrate on figuring out how do we handle the muxes. Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
