From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heikki Krogerus Subject: Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector Date: Mon, 5 Mar 2018 12:27:53 +0200 Message-ID: <20180305102753.GC10598@kuha.fi.intel.com> References: <20180227071134.28063-1-a.hajda@samsung.com> <20180227071134.28063-2-a.hajda@samsung.com> <20180302131315.GA10598@kuha.fi.intel.com> <8434f820-5016-1e5a-c3cb-5d7789dd69c1@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <8434f820-5016-1e5a-c3cb-5d7789dd69c1@samsung.com> Sender: linux-kernel-owner@vger.kernel.org To: Andrzej Hajda Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Bartlomiej Zolnierkiewicz , Marek Szyprowski , dri-devel@lists.freedesktop.org, Inki Dae , Rob Herring , Mark Rutland , Krzysztof Kozlowski , Chanwoo Choi , Archit Taneja , Laurent Pinchart , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-usb@vger.kernel.org List-Id: linux-samsung-soc@vger.kernel.org On Mon, Mar 05, 2018 at 09:18:10AM +0100, Andrzej Hajda wrote: > On 02.03.2018 14:13, Heikki Krogerus wrote: > > Hi, > > > > On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote: > >> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed > >> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort. > >> +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY. > >> + > >> +ccic: s2mm005@33 { > >> + ... > >> + usb_con: connector { > >> + compatible = "usb-c-connector"; > >> + label = "USB-C"; > > Is this child node really necessary? There will never be more then > > one connector per CC line. > > But there can be more connectors/cc-lines per IC, for example EZ-PD CCG5[1]. OK, in that case the child node is of course needed. > [1]: > http://www.cypress.com/products/ez-pd-ccg5-two-port-usb-type-c-and-power-delivery > > > > > We should prefer device_graph* functions over of_graph* and > I guess you mean fwnode_graph* functions. Yes. > > acpi_graph* functions in the drivers so we don't have to handle the > > same thing multiple times with separate APIs. Is it still possible if > > there is that connector child node? > > Bindings proposed here are OF bindings, I suppose the most important is > to follow OF specification and guidelines and these bindings tries to > follow it. > It looks like it should not be a problem for fwnode framework to handle > such bindings, but it is just my guess. I have not seen any fwnode* > specification I am not sure what is the real purpose of this framework, > but it seems to be just in-kernel abstraction for different firmware > standards (OF, ACPI), so even if it lacks at the moment some > functionality it should not be a barrier for OF bindings. Sure thing. Thanks, -- heikki From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [v5,1/6] dt-bindings: add bindings for USB physical connector From: Heikki Krogerus Message-Id: <20180305102753.GC10598@kuha.fi.intel.com> Date: Mon, 5 Mar 2018 12:27:53 +0200 To: Andrzej Hajda Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Bartlomiej Zolnierkiewicz , Marek Szyprowski , dri-devel@lists.freedesktop.org, Inki Dae , Rob Herring , Mark Rutland , Krzysztof Kozlowski , Chanwoo Choi , Archit Taneja , Laurent Pinchart , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-usb@vger.kernel.org List-ID: T24gTW9uLCBNYXIgMDUsIDIwMTggYXQgMDk6MTg6MTBBTSArMDEwMCwgQW5kcnplaiBIYWpkYSB3 cm90ZToKPiBPbiAwMi4wMy4yMDE4IDE0OjEzLCBIZWlra2kgS3JvZ2VydXMgd3JvdGU6Cj4gPiBI aSwKPiA+Cj4gPiBPbiBUdWUsIEZlYiAyNywgMjAxOCBhdCAwODoxMToyOUFNICswMTAwLCBBbmRy emVqIEhhamRhIHdyb3RlOgo+ID4+ICsyLiBVU0ItQyBjb25uZWN0b3IgYXR0YWNoZWQgdG8gQ0Mg Y29udHJvbGxlciAoczJtbTAwNSksIEhTIGxpbmVzIHJvdXRlZAo+ID4+ICt0byBjb21wYW5pb24g UE1JQyAobWF4Nzc4NjUpLCBTUyBsaW5lcyB0byBVU0IzIFBIWSBhbmQgU0JVIHRvIERpc3BsYXlQ b3J0Lgo+ID4+ICtEaXNwbGF5UG9ydCB2aWRlbyBsaW5lcyBhcmUgcm91dGVkIHRvIHRoZSBjb25u ZWN0b3IgdmlhIFNTIG11eCBpbiBVU0IzIFBIWS4KPiA+PiArCj4gPj4gK2NjaWM6IHMybW0wMDVA MzMgewo+ID4+ICsJLi4uCj4gPj4gKwl1c2JfY29uOiBjb25uZWN0b3Igewo+ID4+ICsJCWNvbXBh dGlibGUgPSAidXNiLWMtY29ubmVjdG9yIjsKPiA+PiArCQlsYWJlbCA9ICJVU0ItQyI7Cj4gPiBJ cyB0aGlzIGNoaWxkIG5vZGUgcmVhbGx5IG5lY2Vzc2FyeT8gVGhlcmUgd2lsbCBuZXZlciBiZSBt b3JlIHRoZW4KPiA+IG9uZSBjb25uZWN0b3IgcGVyIENDIGxpbmUuCj4gCj4gQnV0IHRoZXJlIGNh biBiZSBtb3JlIGNvbm5lY3RvcnMvY2MtbGluZXMgcGVyIElDLCBmb3IgZXhhbXBsZSBFWi1QRCBD Q0c1WzFdLgoKT0ssIGluIHRoYXQgY2FzZSB0aGUgY2hpbGQgbm9kZSBpcyBvZiBjb3Vyc2UgbmVl ZGVkLgoKPiBbMV06Cj4gaHR0cDovL3d3dy5jeXByZXNzLmNvbS9wcm9kdWN0cy9lei1wZC1jY2c1 LXR3by1wb3J0LXVzYi10eXBlLWMtYW5kLXBvd2VyLWRlbGl2ZXJ5Cj4gCj4gPgo+ID4gV2Ugc2hv dWxkIHByZWZlciBkZXZpY2VfZ3JhcGgqIGZ1bmN0aW9ucyBvdmVyIG9mX2dyYXBoKiBhbmQKPiBJ IGd1ZXNzIHlvdSBtZWFuIGZ3bm9kZV9ncmFwaCogZnVuY3Rpb25zLgoKWWVzLgoKPiA+IGFjcGlf Z3JhcGgqIGZ1bmN0aW9ucyBpbiB0aGUgZHJpdmVycyBzbyB3ZSBkb24ndCBoYXZlIHRvIGhhbmRs ZSB0aGUKPiA+IHNhbWUgdGhpbmcgbXVsdGlwbGUgdGltZXMgd2l0aCBzZXBhcmF0ZSBBUElzLiBJ cyBpdCBzdGlsbCBwb3NzaWJsZSBpZgo+ID4gdGhlcmUgaXMgdGhhdCBjb25uZWN0b3IgY2hpbGQg bm9kZT8KPiAKPiBCaW5kaW5ncyBwcm9wb3NlZCBoZXJlIGFyZSBPRiBiaW5kaW5ncywgSSBzdXBw b3NlIHRoZSBtb3N0IGltcG9ydGFudCBpcwo+IHRvIGZvbGxvdyBPRiBzcGVjaWZpY2F0aW9uIGFu ZCBndWlkZWxpbmVzIGFuZCB0aGVzZSBiaW5kaW5ncyB0cmllcyB0bwo+IGZvbGxvdyBpdC4KPiBJ dCBsb29rcyBsaWtlIGl0IHNob3VsZCBub3QgYmUgYSBwcm9ibGVtIGZvciBmd25vZGUgZnJhbWV3 b3JrIHRvIGhhbmRsZQo+IHN1Y2ggYmluZGluZ3MsIGJ1dCBpdCBpcyBqdXN0IG15IGd1ZXNzLiBJ IGhhdmUgbm90IHNlZW4gYW55IGZ3bm9kZSoKPiBzcGVjaWZpY2F0aW9uIEkgYW0gbm90IHN1cmUg d2hhdCBpcyB0aGUgcmVhbCBwdXJwb3NlIG9mIHRoaXMgZnJhbWV3b3JrLAo+IGJ1dCBpdCBzZWVt cyB0byBiZSBqdXN0IGluLWtlcm5lbCBhYnN0cmFjdGlvbiBmb3IgZGlmZmVyZW50IGZpcm13YXJl Cj4gc3RhbmRhcmRzIChPRiwgQUNQSSksIHNvIGV2ZW4gaWYgaXQgbGFja3MgYXQgdGhlIG1vbWVu dCBzb21lCj4gZnVuY3Rpb25hbGl0eSBpdCBzaG91bGQgbm90IGJlIGEgYmFycmllciBmb3IgT0Yg YmluZGluZ3MuCgpTdXJlIHRoaW5nLgoKClRoYW5rcywK From mboxrd@z Thu Jan 1 00:00:00 1970 From: heikki.krogerus@linux.intel.com (Heikki Krogerus) Date: Mon, 5 Mar 2018 12:27:53 +0200 Subject: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector In-Reply-To: <8434f820-5016-1e5a-c3cb-5d7789dd69c1@samsung.com> References: <20180227071134.28063-1-a.hajda@samsung.com> <20180227071134.28063-2-a.hajda@samsung.com> <20180302131315.GA10598@kuha.fi.intel.com> <8434f820-5016-1e5a-c3cb-5d7789dd69c1@samsung.com> Message-ID: <20180305102753.GC10598@kuha.fi.intel.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Mar 05, 2018 at 09:18:10AM +0100, Andrzej Hajda wrote: > On 02.03.2018 14:13, Heikki Krogerus wrote: > > Hi, > > > > On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote: > >> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed > >> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort. > >> +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY. > >> + > >> +ccic: s2mm005 at 33 { > >> + ... > >> + usb_con: connector { > >> + compatible = "usb-c-connector"; > >> + label = "USB-C"; > > Is this child node really necessary? There will never be more then > > one connector per CC line. > > But there can be more connectors/cc-lines per IC, for example EZ-PD CCG5[1]. OK, in that case the child node is of course needed. > [1]: > http://www.cypress.com/products/ez-pd-ccg5-two-port-usb-type-c-and-power-delivery > > > > > We should prefer device_graph* functions over of_graph* and > I guess you mean fwnode_graph* functions. Yes. > > acpi_graph* functions in the drivers so we don't have to handle the > > same thing multiple times with separate APIs. Is it still possible if > > there is that connector child node? > > Bindings proposed here are OF bindings, I suppose the most important is > to follow OF specification and guidelines and these bindings tries to > follow it. > It looks like it should not be a problem for fwnode framework to handle > such bindings, but it is just my guess. I have not seen any fwnode* > specification I am not sure what is the real purpose of this framework, > but it seems to be just in-kernel abstraction for different firmware > standards (OF, ACPI), so even if it lacks at the moment some > functionality it should not be a barrier for OF bindings. Sure thing. Thanks, -- heikki