On Fri, Feb 13, 2015 at 02:35:16PM +0200, Heikki Krogerus wrote:
Hi,
On Thu, Feb 12, 2015 at 05:52:42PM -0800, David Cohen wrote:
Hi Heikki,
Sorry I am starting a new branch on this thread.
I need to go back to another topic on this same patch.
On Fri, Jan 23, 2015 at 05:12:58PM
Hi Felipe,
[snip]
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 8d95056..53902ea 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -21,6 +21,7 @@
#include linux/slab.h
#include linux/pci.h
#include linux/platform_device.h
On Fri, Feb 13, 2015 at 02:02:11PM -0800, David Cohen wrote:
Hi Felipe,
[snip]
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 8d95056..53902ea 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -21,6 +21,7 @@
#include
On Fri, Feb 13, 2015 at 04:03:57PM -0600, Felipe Balbi wrote:
On Fri, Feb 13, 2015 at 02:02:11PM -0800, David Cohen wrote:
Hi Felipe,
[snip]
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 8d95056..53902ea 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
Hi,
On Thu, Feb 12, 2015 at 05:52:42PM -0800, David Cohen wrote:
Hi Heikki,
Sorry I am starting a new branch on this thread.
I need to go back to another topic on this same patch.
On Fri, Jan 23, 2015 at 05:12:58PM +0200, Heikki Krogerus wrote:
TUSB1210 ULPI PHY has vendor specific
Hi Heikki,
Sorry I am starting a new branch on this thread.
I need to go back to another topic on this same patch.
On Fri, Jan 23, 2015 at 05:12:58PM +0200, Heikki Krogerus wrote:
TUSB1210 ULPI PHY has vendor specific register for eye
diagram tuning. On some platforms the system firmware has
On Wed, Feb 11, 2015 at 03:12:55PM +0200, Heikki Krogerus wrote:
Hi David,
Hi Heikki,
In order for phy to be functional, it does not depend only on toggling
GPIOs. It depends on DWC3 going to reset state, then phy executes
power
on sequence, then DWC3 going out of reset
Hi David,
In order for phy to be functional, it does not depend only on toggling
GPIOs. It depends on DWC3 going to reset state, then phy executes power
on sequence, then DWC3 going out of reset state to sync clocks with phy.
You're saying we should tell BIOS is concurrently mess
On Tue, Feb 03, 2015 at 01:37:39PM +0200, Heikki Krogerus wrote:
Hi David, Felipe,
Hi Heikki,
why would you have dwc3 mess around with the PHY's gpios ? Doesn't
look
very good.
..but unfortunately we can't use the bus without it :(. We depend on
being able to read
On Tue, Feb 10, 2015 at 11:05:31AM -0800, David Cohen wrote:
On Mon, Feb 02, 2015 at 02:59:59PM +0200, Heikki Krogerus wrote:
You can't really compare a bus like i2c, which can't enumerate
devices
natively, to ULPI which can.
why not ? The BIOS might not need to use
On Mon, Feb 02, 2015 at 02:59:59PM +0200, Heikki Krogerus wrote:
You can't really compare a bus like i2c, which can't enumerate devices
natively, to ULPI which can.
why not ? The BIOS might not need to use the PHY (or USB) at all, it can
very well decide to never turn it on,
Hi David, Felipe,
why would you have dwc3 mess around with the PHY's gpios ? Doesn't look
very good.
..but unfortunately we can't use the bus without it :(. We depend on
being able to read the vendor and product id's in the bus driver.
Doesn't the ugly platform device case
Hi David,
What exactly are we breaking here? The USB on BYT-CR does not work yet
with the mainline kernel, or does it? To enable it, I already
suggested the BYT quirk (attached again).
It used to work with mainline with minor restrictions. It stopped
working (and I failed
You can't really compare a bus like i2c, which can't enumerate devices
natively, to ULPI which can.
why not ? The BIOS might not need to use the PHY (or USB) at all, it can
very well decide to never turn it on, right ?
If ULPI was seen as a bus, then no. BIOS would have
On Fri, Jan 30, 2015 at 11:29:56AM +0200, Heikki Krogerus wrote:
Hi,
You can't really compare a bus like i2c, which can't enumerate devices
natively, to ULPI which can.
why not ? The BIOS might not need to use the PHY (or USB) at all, it can
very well decide to never turn it on,
On Fri, Jan 30, 2015 at 10:14:12AM -0600, Felipe Balbi wrote:
On Fri, Jan 30, 2015 at 11:29:56AM +0200, Heikki Krogerus wrote:
Hi,
You can't really compare a bus like i2c, which can't enumerate devices
natively, to ULPI which can.
why not ? The BIOS might not need to use the
On Fri, Jan 30, 2015 at 11:29:56AM +0200, Heikki Krogerus wrote:
Hi,
You can't really compare a bus like i2c, which can't enumerate devices
natively, to ULPI which can.
why not ? The BIOS might not need to use the PHY (or USB) at all, it can
very well decide to never turn it on,
On Fri, Jan 30, 2015 at 08:25:23AM -0800, David Cohen wrote:
On Fri, Jan 30, 2015 at 10:14:12AM -0600, Felipe Balbi wrote:
On Fri, Jan 30, 2015 at 11:29:56AM +0200, Heikki Krogerus wrote:
Hi,
You can't really compare a bus like i2c, which can't enumerate devices
natively, to
On Fri, Jan 30, 2015 at 02:18:42PM +0200, Heikki Krogerus wrote:
Hi,
What exactly are we breaking here? The USB on BYT-CR does not work yet
with the mainline kernel, or does it? To enable it, I already
suggested the BYT quirk (attached again).
It used to work with mainline with
On Fri, Jan 30, 2015 at 08:20:38AM -0800, David Cohen wrote:
On Fri, Jan 30, 2015 at 11:29:56AM +0200, Heikki Krogerus wrote:
Hi,
You can't really compare a bus like i2c, which can't enumerate devices
natively, to ULPI which can.
why not ? The BIOS might not need to use the
Also, I was chatting in private with David and, apparently, there's
a
way to request for eye diagram data from BIOS straight. That's more
in-line with what we would do for DT-based boots, passing that
eye-diagram data as a DT attribute.
Care to comment ?
Hi,
You can't really compare a bus like i2c, which can't enumerate devices
natively, to ULPI which can.
why not ? The BIOS might not need to use the PHY (or USB) at all, it can
very well decide to never turn it on, right ?
If ULPI was seen as a bus, then no. BIOS would have definitely
Hi,
What exactly are we breaking here? The USB on BYT-CR does not work yet
with the mainline kernel, or does it? To enable it, I already
suggested the BYT quirk (attached again).
It used to work with mainline with minor restrictions. It stopped
working (and I failed to catch it
Hi Heikki, Felipe,
On Thu, Jan 29, 2015 at 10:20:23AM -0600, Felipe Balbi wrote:
Hi
On Thu, Jan 29, 2015 at 04:14:12PM +0200, Heikki Krogerus wrote:
Can you share how tusb1210 is connected on the platform you're
using as
test for this patch? I don't think this driver
On Thu, Jan 29, 2015 at 10:04:16AM -0800, David Cohen wrote:
On Thu, Jan 29, 2015 at 10:20:49AM -0600, Felipe Balbi wrote:
On Thu, Jan 29, 2015 at 04:30:53PM +0200, Heikki Krogerus wrote:
Also, I was chatting in private with David and, apparently, there's a
way to request for eye
On Thu, Jan 29, 2015 at 10:20:49AM -0600, Felipe Balbi wrote:
On Thu, Jan 29, 2015 at 04:30:53PM +0200, Heikki Krogerus wrote:
Also, I was chatting in private with David and, apparently, there's a
way to request for eye diagram data from BIOS straight. That's more
in-line with what we
Can you share how tusb1210 is connected on the platform you're using
as
test for this patch? I don't think this driver would work reliably
with
this device:
http://liliputing.com/2014/11/trekstor-launches-first-android-tablet-based-intels-irda-reference-design.html
Also, I was chatting in private with David and, apparently, there's a
way to request for eye diagram data from BIOS straight. That's more
in-line with what we would do for DT-based boots, passing that
eye-diagram data as a DT attribute.
Care to comment ? If that's the case, I'd rather use
Hi
On Thu, Jan 29, 2015 at 04:14:12PM +0200, Heikki Krogerus wrote:
Can you share how tusb1210 is connected on the platform you're
using as
test for this patch? I don't think this driver would work reliably
with
this device:
On Thu, Jan 29, 2015 at 04:30:53PM +0200, Heikki Krogerus wrote:
Also, I was chatting in private with David and, apparently, there's a
way to request for eye diagram data from BIOS straight. That's more
in-line with what we would do for DT-based boots, passing that
eye-diagram data as a DT
On Thu, Jan 29, 2015 at 10:25:38AM -0800, David Cohen wrote:
On Thu, Jan 29, 2015 at 10:04:16AM -0800, David Cohen wrote:
On Thu, Jan 29, 2015 at 10:20:49AM -0600, Felipe Balbi wrote:
On Thu, Jan 29, 2015 at 04:30:53PM +0200, Heikki Krogerus wrote:
Also, I was chatting in private with
Hi,
Can you share how tusb1210 is connected on the platform you're using as
test for this patch? I don't think this driver would work reliably with
this device:
http://liliputing.com/2014/11/trekstor-launches-first-android-tablet-based-intels-irda-reference-design.html
The only
On Wed, Jan 28, 2015 at 04:20:25PM +0200, Heikki Krogerus wrote:
Hi,
Can you share how tusb1210 is connected on the platform you're using as
test for this patch? I don't think this driver would work reliably with
this device:
On Fri, Jan 23, 2015 at 05:12:58PM +0200, Heikki Krogerus wrote:
TUSB1210 ULPI PHY has vendor specific register for eye
diagram tuning. On some platforms the system firmware has
set optimized value to it. In order to not loose the
optimized value, the driver stores it during probe and
On Mon, Jan 26, 2015 at 11:23:37AM -0800, David Cohen wrote:
On Mon, Jan 26, 2015 at 02:55:03PM +0200, Heikki Krogerus wrote:
On Sat, Jan 24, 2015 at 03:58:11PM -0800, David Cohen wrote:
+static int tusb1210_power_on(struct phy *phy)
+{
+ struct tusb1210 *tusb =
Hi guys,
I'm only using the init and exit hooks instead of just
power_on/power_off because I'm not sure which the controllers will
use. For example, now dwc3 calls phy_init() in it's resume routine and
not phy_power_on() like I would expect. I know the problem has been
pointed out by others,
On Tue, Jan 27, 2015 at 11:28:56AM +0200, Heikki Krogerus wrote:
On Mon, Jan 26, 2015 at 11:23:37AM -0800, David Cohen wrote:
On Mon, Jan 26, 2015 at 02:55:03PM +0200, Heikki Krogerus wrote:
On Sat, Jan 24, 2015 at 03:58:11PM -0800, David Cohen wrote:
+static int
Hi David,
On Sat, Jan 24, 2015 at 03:58:11PM -0800, David Cohen wrote:
+static int tusb1210_power_on(struct phy *phy)
+{
+ struct tusb1210 *tusb = phy_get_drvdata(phy);
+
+ gpiod_set_value_cansleep(tusb-gpio_reset, 1);
+ gpiod_set_value_cansleep(tusb-gpio_cs, 1);
+
+ /*
Hi Heikki,
On Mon, Jan 26, 2015 at 02:55:03PM +0200, Heikki Krogerus wrote:
Hi David,
On Sat, Jan 24, 2015 at 03:58:11PM -0800, David Cohen wrote:
+static int tusb1210_power_on(struct phy *phy)
+{
+ struct tusb1210 *tusb = phy_get_drvdata(phy);
+
+
Hi Heikki,
On Fri, Jan 23, 2015 at 05:12:58PM +0200, Heikki Krogerus wrote:
TUSB1210 ULPI PHY has vendor specific register for eye
diagram tuning. On some platforms the system firmware has
set optimized value to it. In order to not loose the
optimized value, the driver stores it during probe
TUSB1210 ULPI PHY has vendor specific register for eye
diagram tuning. On some platforms the system firmware has
set optimized value to it. In order to not loose the
optimized value, the driver stores it during probe and
restores it every time the PHY is powered back on.
Signed-off-by: Heikki
41 matches
Mail list logo
