From: Saranya Gopal
USB audio class 3.0 specification introduced many significant
changes like
- new power domains, support for LPM/L1
- new cluster descriptor
- new high capability and class-specific string descriptors
- BADD profiles
- ... and many other things (check spec from link
Hi Peter,
> > Latest NVIDIA GPU card has USB Type-C interface. There is a Type-C
> > controller which can be accessed over I2C.
> >
> > This driver adds I2C bus driver to communicate with Type-C controller.
> > I2C client driver will be part of USB Type-C UCSI driver.
> >
> > Signed-off-by: Ajay
On 2018-09-11 19:45, Ajay Gupta wrote:
> Latest NVIDIA GPU card has USB Type-C interface. There is a
> Type-C controller which can be accessed over I2C.
>
> This driver adds I2C bus driver to communicate with Type-C controller.
> I2C client driver will be part of USB Type-C UCSI driver.
>
>
On Wed, Sep 12, 2018 at 01:03:57AM +0530, saranya.go...@intel.com wrote:
> From: Saranya Gopal
Any reason you forgot to cc: the usb maintainer? :)
>
> USB audio class 3.0 specification introduced many significant
> changes like
> - new power domains, support for LPM/L1
> - new cluster
When operating in USB 2.0 speeds (HS/FS), if GUSB2PHYCFG.ENBLSLPM or
GUSB2PHYCFG.SUSPHY is set, it must be cleared before issuing an endpoint
command.
Current implementation only save and restore GUSB2PHYCFG.SUSPHY
configuration. We must save and clear both GUSB2PHYCFG.ENBLSLPM and
From: Saranya Gopal
USB audio class 3.0 specification introduced many significant
changes like
- new power domains, support for LPM/L1
- new cluster descriptor
- new high capability and class-specific string descriptors
- BADD profiles
- ... and many other things (check spec from link
From: Saranya Gopal
USB audio class 3.0 specification introduced many significant
changes like
- new power domains, support for LPM/L1
- new cluster descriptor
- new high capability and class-specific string descriptors
- BADD profiles
- ... and many other things (check spec from link
Latest NVIDIA GPU card has USB Type-C interface. There is a
Type-C controller which can be accessed over I2C.
This driver adds I2C bus driver to communicate with Type-C controller.
I2C client driver will be part of USB Type-C UCSI driver.
Signed-off-by: Ajay Gupta
Reviewed-by: Andy Shevchenko
Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller
over I2C interface.
This UCSI I2C driver uses I2C bus driver interface for communicating
with Type-C controller.
Signed-off-by: Ajay Gupta
Reviewed-by: Andy Shevchenko
Acked-by: Heikki Krogerus
---
Changes from v1 -> v2
After commit 1cbd53c8cd85 ("usb: core: introduce per-port over-current
counters") usb ports expose a sysfs value 'over_current_count'
to user space. This value on its own is not very useful as it requires
manual polling.
As a solution, fire a udev event from the usb hub device that specifies
the
Hi,
On 11-09-18 12:10, Heikki Krogerus wrote:
Hi,
This is fourth version of this series. There was one bug in patch 2/10
that Hans noticed. It should be fixed now.
The commit message from v3:
These patches will introduce a few improvements to the USB Type-C
support on Intel CHT platform. In
Hi Peter,
> -Original Message-
> From: linux-i2c-ow...@vger.kernel.org
> On Behalf Of Peter Rosin
> Sent: Tuesday, September 11, 2018 1:55 AM
> To: Ajay Gupta ; w...@the-dreams.de;
> heikki.kroge...@linux.intel.com
> Cc: linux-usb@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re:
* Laurent Pinchart [180911 16:12]:
> On Tuesday, 11 September 2018 18:16:41 EEST Tony Lindgren wrote:
> > * Laurent Pinchart [180911 15:10]:
> > > Hello,
> > >
> > > This series fixes a v4.19-rc1 regression that results in OMAP EHCI failing
> > > to probe (patch 1/3) and then moves on to
On Tuesday, 11 September 2018 18:53:19 EEST Ladislav Michl wrote:
> On Tue, Sep 11, 2018 at 06:06:08PM +0300, Laurent Pinchart wrote:
> > The omap-usb-host driver uses platform_driver_probe() in the fs initcall
> > level to ensure that the devices get probed before the EHCI and OHCI
> > drivers
Hi Tony,
On Tuesday, 11 September 2018 18:16:41 EEST Tony Lindgren wrote:
> * Laurent Pinchart [180911 15:10]:
> > Hello,
> >
> > This series fixes a v4.19-rc1 regression that results in OMAP EHCI failing
> > to probe (patch 1/3) and then moves on to cleaning up related code
> > (patches 2/3
On Tue, Sep 11, 2018 at 06:06:08PM +0300, Laurent Pinchart wrote:
> The omap-usb-host driver uses platform_driver_probe() in the fs initcall
> level to ensure that the devices get probed before the EHCI and OHCI
> drivers arer probed.
>
> The EHCI and OHCI devices are created and registered by
* Tony Lindgren [180911 15:21]:
> * Laurent Pinchart [180911 15:10]:
> > Tony, as patch 1/3 fixes a problem introduced by one of your DT changes,
> > could
> > you please review it ? Out of curiosity, is ethernet on the Pandaboard not
> > part of your regression tests ?
>
> Sorry not any
* Laurent Pinchart [180911 15:10]:
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -855,31 +856,14 @@ static struct platform_driver usbhs_omap_driver = {
> .pm = _dev_pm_ops,
> .of_match_table = usbhs_omap_dt_ids,
> },
> +
* Laurent Pinchart [180911 15:10]:
> Hello,
>
> This series fixes a v4.19-rc1 regression that results in OMAP EHCI failing to
> probe (patch 1/3) and then moves on to cleaning up related code (patches 2/3
> and 3/3).
>
> The first patch is a regression fix and should thus be merged before
Now that all platforms using OMAP USB host devices have been converted
to DT, drop support for legacy non-DT probe from the driver.
Signed-off-by: Laurent Pinchart
---
drivers/mfd/omap-usb-host.c| 153 +++--
include/linux/platform_data/usb-omap.h | 4 -
Several legacy USB-related functions, structures and macros are not used
anymore after conversion to DT. Remove them.
Signed-off-by: Laurent Pinchart
---
arch/arm/mach-omap2/common.h| 2 -
arch/arm/mach-omap2/omap_phy_internal.c | 96 +
The omap-usb-host driver uses platform_driver_probe() in the fs initcall
level to ensure that the devices get probed before the EHCI and OHCI
drivers arer probed.
The EHCI and OHCI devices are created and registered by the omap-usb-host
driver, and if no driver is present yet to handle them they
Hello,
This series fixes a v4.19-rc1 regression that results in OMAP EHCI failing to
probe (patch 1/3) and then moves on to cleaning up related code (patches 2/3
and 3/3).
The first patch is a regression fix and should thus be merged before v4.19.
The other two patches can wait until v4.20.
On Mon, Sep 10, 2018 at 06:21:04AM -0700, Guenter Roeck wrote:
> On 09/10/2018 04:58 AM, Heikki Krogerus wrote:
> > Moving all the drivers that depend on the Port Controller
> > Manager under a new directory drivers/usb/typec/tcpm/ and
> > making Guenter Roeck the designated reviewer of that code.
Hi Peter
> On Sep 10, 2018, at 11:29 PM, Peter Rosin wrote:
>
>> On 2018-09-11 06:30, Ajay Gupta wrote:
>> Hi Peter,
>>
>>> +static int ucsi_ccg_send_data(struct ucsi_ccg *uc) {
>>> +unsigned char buf1[USBC_MSG_OUT_SIZE];
>>> +unsigned char
The company atmes.de manufactures a SMSC95xx device with default USB
ID 0424:9e00 , but with external NXP TJA1100 PHY at address 0x4. This
PHY is not 802.3 c22 compliant, but rather c96 compliant. The register
set is slightly different and does not provide link state information
in c22-compliant
The SMSC95xx chip can use either the internal PHY or an external one.
Currently, the driver hard-codes support for the internal PHY only.
This patch reads out the HW_CFG register to determine whether external
PHY is attached or not. If an external PHY is not attached, the driver
falls back to
Hi,
This is fourth version of this series. There was one bug in patch 2/10
that Hans noticed. It should be fixed now.
The commit message from v3:
These patches will introduce a few improvements to the USB Type-C
support on Intel CHT platform. In this series I'm preparing Intel CHT
mux handling
USB Type-C class driver now expects the muxes to be always
assigned to the ports and not controllers, so the
connections for the mux and fusb302 can be removed.
Signed-off-by: Heikki Krogerus
Acked-by: Andy Shevchenko
---
drivers/platform/x86/intel_cht_int33fe.c | 18 --
1 file
It is not possible to use the parent of the port device when
requesting mux handles as the parent may be a multiport USB
Type-C or PD controller. The muxes must be assigned to the
ports, not the controllers.
This will also move the requesting of the muxes after the
port device is initialized.
The debugfs needs to be initialized as the last step in
probe in this case. The struct dentry *rootdir can't be
pointing to anything unless driver probe really finishes
successfully.
It is also not necessary to clear the i2c clientdata if the
probe fails, so removing the extra label used for
Assigning the mux to the USB Type-C port on top of fusb302.
That will prepare this driver for the change in the USB
Type-C class code, where the class driver will assume the
muxes to be always assigned to the ports and not the
controllers.
Once the USB Type-C class driver has been updated, the
Functions typec_mux_get() and typec_switch_get() already
make sure that the mux device reference count is
incremented, but the same must be done to the driver module
as well to prevent the drivers from being unloaded in the
middle of operation.
This fixes a potential "BUG: unable to handle kernel
This fixes potential "BUG: unable to handle kernel paging
request at ..." from happening.
Fixes: fde0aa6c175a ("usb: common: Small class for USB role switches")
Cc:
Signed-off-by: Heikki Krogerus
---
drivers/usb/common/roles.c | 15 ---
1 file changed, 12 insertions(+), 3
Adding a connection for the DisplayPort alternate mode.
PI3USB30532 is used for muxing the port to DisplayPort on
CHT platforms. The connection allows the alternate mode
device to get handle to the mux, and therefore make it
possible to use the USB Type-C connector as DisplayPort.
Signed-off-by:
We can register all device connection descriptors with a
single call to device_connections_add().
Signed-off-by: Heikki Krogerus
Acked-by: Andy Shevchenko
---
drivers/platform/x86/intel_cht_int33fe.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git
Introducing helpers for adding and removing multiple device
connection descriptions at once.
Signed-off-by: Heikki Krogerus
---
include/linux/device.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index
The connections create clear dependency on the muxes.
fusb302 fails to probe unless we have the mux drivers
available.
Signed-off-by: Heikki Krogerus
Acked-by: Andy Shevchenko
---
drivers/platform/x86/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/platform/x86/Kconfig
[I seem to have lost my local copy of the mail I'm responding to, so I
copied bits of it from an archive and broke threading in the process,
sorry about that]
On 2018-09-11 00:22, Ajay Gupta wrote:
>> Hmm, that goto stop is however not perfect. Ideally,
>> you shouldn't issue stop if i == 0 and
On Mon, Sep 10, 2018 at 03:12:22PM -0700, Jon Flatley wrote:
> On Mon, Sep 10, 2018 at 11:14 AM Greg KH wrote:
> >
> > On Fri, Aug 31, 2018 at 10:14:19AM -0700, Jon Flatley wrote:
> > > After commit 1cbd53c8cd85 ("usb: core: introduce per-port over-current
> > > counters") usb ports expose a
Intel Apollo Lake has the same internal USB role mux as
Intel Cherry Trail.
Signed-off-by: Heikki Krogerus
---
drivers/usb/host/xhci-pci.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index
On 2018-09-11 06:30, Ajay Gupta wrote:
> Hi Peter,
>
>> +static int ucsi_ccg_send_data(struct ucsi_ccg *uc) {
>> +unsigned char buf1[USBC_MSG_OUT_SIZE];
>> +unsigned char buf2[USBC_CONTROL_SIZE];
>> +int status;
>> +u16 rab;
>> +
42 matches
Mail list logo
