* [v2,06/10] platform: x86: intel_cht_int33fe: Fix the identifier for the mux connection
@ 2018-09-03 13:36 Heikki Krogerus
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Krogerus @ 2018-09-03 13:36 UTC (permalink / raw)
To: Hans de Goede, Greg Kroah-Hartman
Cc: Andy Shevchenko, Darren Hart, platform-driver-x86, linux-usb
PI3USB30532 is used for muxing the port to DisplayPort on
CHT platforms, so changing the connection ID so that the
mux will get assigned to the alternate mode device and not
the port device. Connection ID "typec-mux" is now reserved
for Accessory Modes.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
drivers/platform/x86/intel_cht_int33fe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/intel_cht_int33fe.c b/drivers/platform/x86/intel_cht_int33fe.c
index b0cef48f77af..f8c881f871f9 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -179,7 +179,7 @@ static int cht_int33fe_probe(struct i2c_client *client)
data->connections[0].id = "typec-switch";
data->connections[1].endpoint[0] = "i2c-fusb302";
data->connections[1].endpoint[1] = "i2c-pi3usb30532";
- data->connections[1].id = "typec-mux";
+ data->connections[1].id = "idff01m01";
data->connections[2].endpoint[0] = "i2c-fusb302";
data->connections[2].endpoint[1] = "intel_xhci_usb_sw-role-switch";
data->connections[2].id = "usb-role-switch";
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [v2,06/10] platform: x86: intel_cht_int33fe: Fix the identifier for the mux connection
@ 2018-09-03 14:59 Hans de Goede
0 siblings, 0 replies; 6+ messages in thread
From: Hans de Goede @ 2018-09-03 14:59 UTC (permalink / raw)
To: Heikki Krogerus, Greg Kroah-Hartman
Cc: Andy Shevchenko, Darren Hart, platform-driver-x86, linux-usb
Hi,
On 03-09-18 15:36, Heikki Krogerus wrote:
> PI3USB30532 is used for muxing the port to DisplayPort on
> CHT platforms, so changing the connection ID so that the
> mux will get assigned to the alternate mode device and not
> the port device. Connection ID "typec-mux" is now reserved
> for Accessory Modes.
>
> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> drivers/platform/x86/intel_cht_int33fe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/intel_cht_int33fe.c b/drivers/platform/x86/intel_cht_int33fe.c
> index b0cef48f77af..f8c881f871f9 100644
> --- a/drivers/platform/x86/intel_cht_int33fe.c
> +++ b/drivers/platform/x86/intel_cht_int33fe.c
> @@ -179,7 +179,7 @@ static int cht_int33fe_probe(struct i2c_client *client)
> data->connections[0].id = "typec-switch";
> data->connections[1].endpoint[0] = "i2c-fusb302";
> data->connections[1].endpoint[1] = "i2c-pi3usb30532";
> - data->connections[1].id = "typec-mux";
> + data->connections[1].id = "idff01m01";
Hmm, so the mux will start in open connection and needs to
be moved from open to TYPEC_STATE_USB when doing USB3, I assume
the alternative driver is only going to come into play when
actually using a DP over Type-C capable device/dongle, so what
will do the TYPEC_STATE_SAFE -> TYPEC_STATE_USB switching now ?
Regards,
Hans
^ permalink raw reply [flat|nested] 6+ messages in thread
* [v2,06/10] platform: x86: intel_cht_int33fe: Fix the identifier for the mux connection
@ 2018-09-04 7:37 Heikki Krogerus
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Krogerus @ 2018-09-04 7:37 UTC (permalink / raw)
To: Hans de Goede
Cc: Greg Kroah-Hartman, Andy Shevchenko, Darren Hart,
platform-driver-x86, linux-usb
Hi Hans,
On Mon, Sep 03, 2018 at 04:59:51PM +0200, Hans de Goede wrote:
> Hi,
>
> On 03-09-18 15:36, Heikki Krogerus wrote:
> > PI3USB30532 is used for muxing the port to DisplayPort on
> > CHT platforms, so changing the connection ID so that the
> > mux will get assigned to the alternate mode device and not
> > the port device. Connection ID "typec-mux" is now reserved
> > for Accessory Modes.
> >
> > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > ---
> > drivers/platform/x86/intel_cht_int33fe.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/platform/x86/intel_cht_int33fe.c b/drivers/platform/x86/intel_cht_int33fe.c
> > index b0cef48f77af..f8c881f871f9 100644
> > --- a/drivers/platform/x86/intel_cht_int33fe.c
> > +++ b/drivers/platform/x86/intel_cht_int33fe.c
> > @@ -179,7 +179,7 @@ static int cht_int33fe_probe(struct i2c_client *client)
> > data->connections[0].id = "typec-switch";
> > data->connections[1].endpoint[0] = "i2c-fusb302";
> > data->connections[1].endpoint[1] = "i2c-pi3usb30532";
> > - data->connections[1].id = "typec-mux";
> > + data->connections[1].id = "idff01m01";
>
> Hmm, so the mux will start in open connection and needs to
> be moved from open to TYPEC_STATE_USB when doing USB3, I assume
> the alternative driver is only going to come into play when
> actually using a DP over Type-C capable device/dongle, so what
> will do the TYPEC_STATE_SAFE -> TYPEC_STATE_USB switching now ?
Ah, for some reason I assumed that the orientation switch will take
care of that, but of course it does not. So we'll keep the existing
connections, and just add a new one for the alt mode device.
Sorry for this.
Thanks,
^ permalink raw reply [flat|nested] 6+ messages in thread
* [v2,06/10] platform: x86: intel_cht_int33fe: Fix the identifier for the mux connection
@ 2018-09-04 7:40 Hans de Goede
0 siblings, 0 replies; 6+ messages in thread
From: Hans de Goede @ 2018-09-04 7:40 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Greg Kroah-Hartman, Andy Shevchenko, Darren Hart,
platform-driver-x86, linux-usb
HI,
On 04-09-18 09:37, Heikki Krogerus wrote:
> Hi Hans,
>
> On Mon, Sep 03, 2018 at 04:59:51PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 03-09-18 15:36, Heikki Krogerus wrote:
>>> PI3USB30532 is used for muxing the port to DisplayPort on
>>> CHT platforms, so changing the connection ID so that the
>>> mux will get assigned to the alternate mode device and not
>>> the port device. Connection ID "typec-mux" is now reserved
>>> for Accessory Modes.
>>>
>>> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>>> ---
>>> drivers/platform/x86/intel_cht_int33fe.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/platform/x86/intel_cht_int33fe.c b/drivers/platform/x86/intel_cht_int33fe.c
>>> index b0cef48f77af..f8c881f871f9 100644
>>> --- a/drivers/platform/x86/intel_cht_int33fe.c
>>> +++ b/drivers/platform/x86/intel_cht_int33fe.c
>>> @@ -179,7 +179,7 @@ static int cht_int33fe_probe(struct i2c_client *client)
>>> data->connections[0].id = "typec-switch";
>>> data->connections[1].endpoint[0] = "i2c-fusb302";
>>> data->connections[1].endpoint[1] = "i2c-pi3usb30532";
>>> - data->connections[1].id = "typec-mux";
>>> + data->connections[1].id = "idff01m01";
>>
>> Hmm, so the mux will start in open connection and needs to
>> be moved from open to TYPEC_STATE_USB when doing USB3, I assume
>> the alternative driver is only going to come into play when
>> actually using a DP over Type-C capable device/dongle, so what
>> will do the TYPEC_STATE_SAFE -> TYPEC_STATE_USB switching now ?
>
> Ah, for some reason I assumed that the orientation switch will take
> care of that, but of course it does not. So we'll keep the existing
> connections, and just add a new one for the alt mode device.
Ok, so I assume you are going to send a v3 for this ?
Regards,
Hans
^ permalink raw reply [flat|nested] 6+ messages in thread
* [v2,06/10] platform: x86: intel_cht_int33fe: Fix the identifier for the mux connection
@ 2018-09-04 7:44 Heikki Krogerus
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Krogerus @ 2018-09-04 7:44 UTC (permalink / raw)
To: Hans de Goede
Cc: Greg Kroah-Hartman, Andy Shevchenko, Darren Hart,
platform-driver-x86, linux-usb
On Tue, Sep 04, 2018 at 09:40:35AM +0200, Hans de Goede wrote:
> HI,
>
> On 04-09-18 09:37, Heikki Krogerus wrote:
> > Hi Hans,
> >
> > On Mon, Sep 03, 2018 at 04:59:51PM +0200, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 03-09-18 15:36, Heikki Krogerus wrote:
> > > > PI3USB30532 is used for muxing the port to DisplayPort on
> > > > CHT platforms, so changing the connection ID so that the
> > > > mux will get assigned to the alternate mode device and not
> > > > the port device. Connection ID "typec-mux" is now reserved
> > > > for Accessory Modes.
> > > >
> > > > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > > > ---
> > > > drivers/platform/x86/intel_cht_int33fe.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/platform/x86/intel_cht_int33fe.c b/drivers/platform/x86/intel_cht_int33fe.c
> > > > index b0cef48f77af..f8c881f871f9 100644
> > > > --- a/drivers/platform/x86/intel_cht_int33fe.c
> > > > +++ b/drivers/platform/x86/intel_cht_int33fe.c
> > > > @@ -179,7 +179,7 @@ static int cht_int33fe_probe(struct i2c_client *client)
> > > > data->connections[0].id = "typec-switch";
> > > > data->connections[1].endpoint[0] = "i2c-fusb302";
> > > > data->connections[1].endpoint[1] = "i2c-pi3usb30532";
> > > > - data->connections[1].id = "typec-mux";
> > > > + data->connections[1].id = "idff01m01";
> > >
> > > Hmm, so the mux will start in open connection and needs to
> > > be moved from open to TYPEC_STATE_USB when doing USB3, I assume
> > > the alternative driver is only going to come into play when
> > > actually using a DP over Type-C capable device/dongle, so what
> > > will do the TYPEC_STATE_SAFE -> TYPEC_STATE_USB switching now ?
> >
> > Ah, for some reason I assumed that the orientation switch will take
> > care of that, but of course it does not. So we'll keep the existing
> > connections, and just add a new one for the alt mode device.
>
> Ok, so I assume you are going to send a v3 for this ?
Yes. Let me know if there is any other problems.
Thanks,
^ permalink raw reply [flat|nested] 6+ messages in thread
* [v2,06/10] platform: x86: intel_cht_int33fe: Fix the identifier for the mux connection
@ 2018-09-04 7:47 Hans de Goede
0 siblings, 0 replies; 6+ messages in thread
From: Hans de Goede @ 2018-09-04 7:47 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Greg Kroah-Hartman, Andy Shevchenko, Darren Hart,
platform-driver-x86, linux-usb
Hi,
On 04-09-18 09:44, Heikki Krogerus wrote:
> On Tue, Sep 04, 2018 at 09:40:35AM +0200, Hans de Goede wrote:
>> HI,
>>
>> On 04-09-18 09:37, Heikki Krogerus wrote:
>>> Hi Hans,
>>>
>>> On Mon, Sep 03, 2018 at 04:59:51PM +0200, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 03-09-18 15:36, Heikki Krogerus wrote:
>>>>> PI3USB30532 is used for muxing the port to DisplayPort on
>>>>> CHT platforms, so changing the connection ID so that the
>>>>> mux will get assigned to the alternate mode device and not
>>>>> the port device. Connection ID "typec-mux" is now reserved
>>>>> for Accessory Modes.
>>>>>
>>>>> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>>>>> ---
>>>>> drivers/platform/x86/intel_cht_int33fe.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/platform/x86/intel_cht_int33fe.c b/drivers/platform/x86/intel_cht_int33fe.c
>>>>> index b0cef48f77af..f8c881f871f9 100644
>>>>> --- a/drivers/platform/x86/intel_cht_int33fe.c
>>>>> +++ b/drivers/platform/x86/intel_cht_int33fe.c
>>>>> @@ -179,7 +179,7 @@ static int cht_int33fe_probe(struct i2c_client *client)
>>>>> data->connections[0].id = "typec-switch";
>>>>> data->connections[1].endpoint[0] = "i2c-fusb302";
>>>>> data->connections[1].endpoint[1] = "i2c-pi3usb30532";
>>>>> - data->connections[1].id = "typec-mux";
>>>>> + data->connections[1].id = "idff01m01";
>>>>
>>>> Hmm, so the mux will start in open connection and needs to
>>>> be moved from open to TYPEC_STATE_USB when doing USB3, I assume
>>>> the alternative driver is only going to come into play when
>>>> actually using a DP over Type-C capable device/dongle, so what
>>>> will do the TYPEC_STATE_SAFE -> TYPEC_STATE_USB switching now ?
>>>
>>> Ah, for some reason I assumed that the orientation switch will take
>>> care of that, but of course it does not. So we'll keep the existing
>>> connections, and just add a new one for the alt mode device.
>>
>> Ok, so I assume you are going to send a v3 for this ?
>
> Yes. Let me know if there is any other problems.
Otherwise the series looks good to me.
Regards,
Hans
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-09-04 7:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-09-04 7:37 [v2,06/10] platform: x86: intel_cht_int33fe: Fix the identifier for the mux connection Heikki Krogerus
-- strict thread matches above, loose matches on Subject: below --
2018-09-04 7:47 Hans de Goede
2018-09-04 7:44 Heikki Krogerus
2018-09-04 7:40 Hans de Goede
2018-09-03 14:59 Hans de Goede
2018-09-03 13:36 Heikki Krogerus
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).