From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: devel@driverdev.osuosl.org,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
Mathias Nyman <mathias.nyman@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
platform-driver-x86@vger.kernel.org,
Sathyanarayanan Kuppuswamy Natarajan <sathyaosid@gmail.com>,
Chanwoo Choi <cw00.choi@samsung.com>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Guenter Roeck <linux@roeck-us.net>,
Darren Hart <dvhart@infradead.org>, Peter Rosin <peda@axentia.se>,
Andy Shevchenko <andy@infradead.org>
Subject: Re: [PATCH v3 05/14] mux: core: Add usb.h header with MUX_USB_* and and MUX_TYPEC_* state constants
Date: Tue, 26 Sep 2017 10:45:56 +0300 [thread overview]
Message-ID: <20170926074556.GA14296@kuha.fi.intel.com> (raw)
In-Reply-To: <20170922183803.10701-5-hdegoede@redhat.com>
Hi Hans,
Sorry about the late response.
On Fri, Sep 22, 2017 at 08:37:54PM +0200, Hans de Goede wrote:
> Add MUX_USB_* and MUX_TYPEC_* state constant defines, which can be used by
> USB device/host, resp. Type-C polarity/role/altmode mux drivers and
> consumers to ensure that they agree on the meaning of the
> mux_control_select() state argument.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> Changes in v2:
> -Start numbering of defines at 0 not 1
> -Use a new usb.h header, rather then adding these to consumer.h
> -Add separate MUX_USB_* and MUX_TYPEC_* defines
>
> Changes in v3:
> -Simplify MUX_TYPEC_* states, drop having separate USB HOST / DEVICE states
> ---
> include/linux/mux/usb.h | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 include/linux/mux/usb.h
>
> diff --git a/include/linux/mux/usb.h b/include/linux/mux/usb.h
> new file mode 100644
> index 000000000000..2fec06846e14
> --- /dev/null
> +++ b/include/linux/mux/usb.h
> @@ -0,0 +1,31 @@
> +/*
> + * mux/usb.h - definitions for USB multiplexers
> + *
> + * Copyright (C) 2017 Hans de Goede <hdegoede@redhat.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef _LINUX_MUX_USB_H
> +#define _LINUX_MUX_USB_H
> +
> +/* Mux state values for USB device/host role muxes */
> +#define MUX_USB_DEVICE (0) /* USB device mode */
> +#define MUX_USB_HOST (1) /* USB host mode */
> +#define MUX_USB_STATES (2)
> +
> +/*
> + * Mux state values for Type-C polarity/role/altmode muxes.
> + *
> + * MUX_TYPEC_POLARITY_INV may be or-ed together with any other mux-state as
> + * inverted-polarity (Type-C plugged in upside down) can happen with any
> + * other mux-state.
> + */
> +#define MUX_TYPEC_POLARITY_INV BIT(0) /* Polarity inverted bit */
> +#define MUX_TYPEC_USB (0 << 1) /* USB only mode */
Predefined values for the usb role are probable OK (maybe), but..
> +#define MUX_TYPEC_USB_AND_DP (1 << 1) /* USB host + 2 lanes DP */
> +#define MUX_TYPEC_DP (2 << 1) /* 4 lanes Display Port */
> +#define MUX_TYPEC_STATES (3 << 1)
..for alternate modes, no way. We don't need to try to keep a list of
all the possible states in one place. The pin configurations need to be
defined per alternate mode (per SVID), and we should not mix the
whole mux subsystem into that.
You are also only considering muxing. We need to deliver the
negotiated pin configurations to other components as well. For
example, in case of DisplayPort, the DP controller will need to know
at least the lane count, but also most likely the plug orientation.
And also, I think this is clear to everybody, but just in case it
isn't: Let's not mix TCPM or TCPC into the alternate mode specific pin
configuration handling at all. The alternate mode specific drivers can
take care of that. I think I need to prepare RFC out of my "alternate
mode bus" idea to give you guys an idea how that should work. Give me
a day or two.
But in any case, drop all alternate mode stuff from this series.
Let's move one step at the time.
Thanks,
--
heikki
WARNING: multiple messages have this Message-ID (diff)
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>,
Chanwoo Choi <cw00.choi@samsung.com>,
Guenter Roeck <linux@roeck-us.net>,
Darren Hart <dvhart@infradead.org>,
Andy Shevchenko <andy@infradead.org>,
Peter Rosin <peda@axentia.se>,
Mathias Nyman <mathias.nyman@intel.com>,
linux-kernel@vger.kernel.org,
platform-driver-x86@vger.kernel.org, devel@driverdev.osuosl.org,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
Sathyanarayanan Kuppuswamy Natarajan <sathyaosid@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org
Subject: Re: [PATCH v3 05/14] mux: core: Add usb.h header with MUX_USB_* and and MUX_TYPEC_* state constants
Date: Tue, 26 Sep 2017 10:45:56 +0300 [thread overview]
Message-ID: <20170926074556.GA14296@kuha.fi.intel.com> (raw)
In-Reply-To: <20170922183803.10701-5-hdegoede@redhat.com>
Hi Hans,
Sorry about the late response.
On Fri, Sep 22, 2017 at 08:37:54PM +0200, Hans de Goede wrote:
> Add MUX_USB_* and MUX_TYPEC_* state constant defines, which can be used by
> USB device/host, resp. Type-C polarity/role/altmode mux drivers and
> consumers to ensure that they agree on the meaning of the
> mux_control_select() state argument.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> Changes in v2:
> -Start numbering of defines at 0 not 1
> -Use a new usb.h header, rather then adding these to consumer.h
> -Add separate MUX_USB_* and MUX_TYPEC_* defines
>
> Changes in v3:
> -Simplify MUX_TYPEC_* states, drop having separate USB HOST / DEVICE states
> ---
> include/linux/mux/usb.h | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 include/linux/mux/usb.h
>
> diff --git a/include/linux/mux/usb.h b/include/linux/mux/usb.h
> new file mode 100644
> index 000000000000..2fec06846e14
> --- /dev/null
> +++ b/include/linux/mux/usb.h
> @@ -0,0 +1,31 @@
> +/*
> + * mux/usb.h - definitions for USB multiplexers
> + *
> + * Copyright (C) 2017 Hans de Goede <hdegoede@redhat.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef _LINUX_MUX_USB_H
> +#define _LINUX_MUX_USB_H
> +
> +/* Mux state values for USB device/host role muxes */
> +#define MUX_USB_DEVICE (0) /* USB device mode */
> +#define MUX_USB_HOST (1) /* USB host mode */
> +#define MUX_USB_STATES (2)
> +
> +/*
> + * Mux state values for Type-C polarity/role/altmode muxes.
> + *
> + * MUX_TYPEC_POLARITY_INV may be or-ed together with any other mux-state as
> + * inverted-polarity (Type-C plugged in upside down) can happen with any
> + * other mux-state.
> + */
> +#define MUX_TYPEC_POLARITY_INV BIT(0) /* Polarity inverted bit */
> +#define MUX_TYPEC_USB (0 << 1) /* USB only mode */
Predefined values for the usb role are probable OK (maybe), but..
> +#define MUX_TYPEC_USB_AND_DP (1 << 1) /* USB host + 2 lanes DP */
> +#define MUX_TYPEC_DP (2 << 1) /* 4 lanes Display Port */
> +#define MUX_TYPEC_STATES (3 << 1)
..for alternate modes, no way. We don't need to try to keep a list of
all the possible states in one place. The pin configurations need to be
defined per alternate mode (per SVID), and we should not mix the
whole mux subsystem into that.
You are also only considering muxing. We need to deliver the
negotiated pin configurations to other components as well. For
example, in case of DisplayPort, the DP controller will need to know
at least the lane count, but also most likely the plug orientation.
And also, I think this is clear to everybody, but just in case it
isn't: Let's not mix TCPM or TCPC into the alternate mode specific pin
configuration handling at all. The alternate mode specific drivers can
take care of that. I think I need to prepare RFC out of my "alternate
mode bus" idea to give you guys an idea how that should work. Give me
a day or two.
But in any case, drop all alternate mode stuff from this series.
Let's move one step at the time.
Thanks,
--
heikki
next prev parent reply other threads:[~2017-09-26 7:45 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-22 18:37 [PATCH v3 01/14] mux: core: Add mux_control_get_optional() API Hans de Goede
2017-09-22 18:37 ` [PATCH v3 02/14] mux: core: Add explicit hook to leave the mux as-is on init/registration Hans de Goede
2017-09-22 18:37 ` Hans de Goede
2017-09-22 18:37 ` [PATCH v3 03/14] mux: core: Add of_mux_control_get helper function Hans de Goede
2017-09-22 18:37 ` Hans de Goede
2017-09-22 18:37 ` [PATCH v3 04/14] mux: core: Add support for getting a mux controller on a non DT platform Hans de Goede
2017-09-22 18:37 ` Hans de Goede
2017-09-22 18:37 ` [PATCH v3 05/14] mux: core: Add usb.h header with MUX_USB_* and and MUX_TYPEC_* state constants Hans de Goede
2017-09-22 18:37 ` Hans de Goede
2017-09-26 7:45 ` Heikki Krogerus [this message]
2017-09-26 7:45 ` Heikki Krogerus
2017-09-22 18:37 ` [PATCH v3 06/14] xhci: Add option to get next extended capability in list by passing id = 0 Hans de Goede
2017-09-22 18:37 ` Hans de Goede
2017-09-22 18:37 ` [PATCH v3 07/14] xhci: Add Intel cherrytrail extended cap / otg phy mux handling Hans de Goede
2017-09-22 18:37 ` Hans de Goede
2017-10-05 11:13 ` Mathias Nyman
2017-09-22 18:37 ` [PATCH v3 08/14] mux: Add Intel Cherrytrail USB mux driver Hans de Goede
2017-09-22 18:37 ` Hans de Goede
2017-09-22 18:37 ` [PATCH v3 09/14] mux: Add Pericom PI3USB30532 Type-C " Hans de Goede
2017-09-22 18:37 ` Hans de Goede
2017-09-22 18:37 ` [PATCH v3 10/14] extcon: intel-int3496: Add support for controlling the USB-role mux Hans de Goede
2017-09-22 18:37 ` Hans de Goede
2017-10-18 2:33 ` Chanwoo Choi
2017-10-18 9:14 ` Hans de Goede
2017-10-18 9:14 ` Hans de Goede
2017-10-18 9:40 ` Chanwoo Choi
2017-09-22 18:38 ` [PATCH v3 11/14] staging: typec: tcpm: Set mux to device mode when configured as such Hans de Goede
2017-09-22 18:38 ` [PATCH v3 12/14] staging: typec: Add Generic TCPC mux driver using the mux subsys Hans de Goede
[not found] ` <20170922183803.10701-1-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-09-22 18:38 ` [PATCH v3 13/14] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support Hans de Goede
2017-09-22 18:38 ` Hans de Goede
2017-09-22 18:38 ` [PATCH v3 14/14] platform/x86: intel_cht_int33fe: Add mux mappings for the Type-C port Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170926074556.GA14296@kuha.fi.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=andy@infradead.org \
--cc=cw00.choi@samsung.com \
--cc=devel@driverdev.osuosl.org \
--cc=dvhart@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mathias.nyman@intel.com \
--cc=myungjoo.ham@samsung.com \
--cc=peda@axentia.se \
--cc=platform-driver-x86@vger.kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=sathyaosid@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.