On 12/03/2012 07:23 PM, Michal Nazarewicz wrote:
On 11/30/2012 07:39 PM, Michal Nazarewicz wrote:
Yeah, but what Felipe just made me realise is that if that's the case,
than it makes no sense to have the functions directory outside of the
gadget. Instead we should have something like:
On Mon,
On 12/03/2012 09:42 PM, krumbo...@universalnet.at wrote:
> Hi Marc!
>
>
>>> +/* Send open command to device */
>>> +static int usb_8dev_cmd_open(struct usb_8dev *dev)
>>> +{
>>> +struct can_bittiming *bt = &dev->can.bittiming;
>>> +struct usb_8dev_cmd_msg outmsg;
>>> +struct usb_8dev_
On 12/03/2012 09:15 PM, Wolfgang Grandegger wrote:
> On 12/03/2012 09:32 PM, krumbo...@universalnet.at wrote:
>> Hi Wolfgang!
>>
>>>
>>> And please also drop the remaining sysfs files for firmware and
>>> hardware. I thinks it's enough that the versions are printed when the
>>> device is probed.
>>
Hello.
On 03-12-2012 19:58, Roger Quadros wrote:
On 28-11-2012 18:49, Roger Quadros wrote:
Both OMAP4 and 5 exhibit the same revision ID in the REVISION register
but they have different number of ports i.e. 2 and 3 respectively.
So we can't rely on REVISION register for number of ports on OM
Hello.
On 03-12-2012 18:32, Sebastian Andrzej Siewior wrote:
| In file included from drivers/usb/gadget/acm_ms.c:43:
| f_mass_storage.c:2199:18: warning: comparison of unsigned expression >= 0 is
always true [-Wtautological-compare]
| if (common->lun >= 0 && common->lun < common->nlun
> On 03-12-2012 18:32, Sebastian Andrzej Siewior wrote:
>> | In file included from drivers/usb/gadget/acm_ms.c:43:
>> | f_mass_storage.c:2199:18: warning: comparison of unsigned expression >= 0
>> is always true [-Wtautological-compare]
>> | if (common->lun >= 0 && common->lun < common->n
fsl-ehci probing fails on mpc5121e:
...
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: Could not get controller version
fsl-ehci fsl-ehci.0
mpc5121e doesn't have system interface registers, accessing this
register address space cause the machine check exception and a
kernel crash:
...
Machine check in kernel mode.
Caused by (from SRR1=49030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
MPC5121 ADS
Modules linked in:
NIP
USB_GADGET_FSL_USB2 has been changed to USB_FSL_USB2 by commit
193ab2a6070039e7ee2b9b9bebea754a7c52fd1b (usb: gadget: allow
multiple gadgets to be built). But old USB_GADGET_FSL_USB2 is
still listed as dependency for fsl_otg driver, so the driver
cannot be selected in the configuration currently. F
Just a pointer to the platform data should suffice.
Signed-off-by: Roger Quadros
Acked-by: Felipe Balbi
---
drivers/mfd/omap-usb-tll.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 0db0dfa..18fefdb
Hi,
This patchset addresses the following
- Avoid addressing clocks one by one by name and use a for loop + bunch
of cleanups.
- Get number of channels/ports dynamically either from revision register
or from platform data. Avoids getting clocks that are not present.
- Add OMAP5 and HSIC mode
Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.
The only information we need is whether the USB Host module has
a single ULPI bypass control bit for all ports or individual bypass
control bits for each port. OMAP3 REV2.1 and earlie
Fix channel count detecion for REV2. Also, don't give up
if we don't recognize the IP Revision. We assume the default
number of channels (i.e. 3) for unrecognized IPs.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 20 +++-
1 files changed, 11 insertions(+), 9 de
Every channel has a functional clock that is similarly named.
It makes sense to use a for loop to manage these clocks as OMAPs
can come with up to 3 channels.
Dynamically allocate and get channel clocks depending on the
number of clocks avaiable on the platform.
Signed-off-by: Roger Quadros
---
Use devm_ variants of kzalloc() and ioremap(). Simplify the error path.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 37 +++--
1 files changed, 11 insertions(+), 26 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll
This is a handy macro to check if the port requires the
USB TLL module or not. Use it to Enable the TLL module and manage
the clocks.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/m
omap_enable/disable_tll() can fail if TLL device is not
initialized. It could be due to multiple reasons and not only
due to missing platform data.
Also make local variables static and use 'struct device *'
instead of 'struct platform_device *' for global reference.
Signed-off-by: Roger Quadros
We can just hold the pointer to the platform data instead
of creating a copy of it.
Also get rid of the unnecessary missing platform data checks
in runtime_suspend/resume. We are already checking for missing
platform data in probe.
Signed-off-by: Roger Quadros
Acked-by: Felipe Balbi
---
driver
The TLL module on OMAP5 has 3 channels.
HSIC mode requires the TLL channel to be in Transparent UTMI mode.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/o
Use devm_ variants of kzalloc and ioremap. Also clean up error path.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 36 +---
1 files changed, 9 insertions(+), 27 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
The revision register should tell us how many ports are present.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 32 +++-
1 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 1
Both OMAP4 and 5 exhibit the same revision ID in the REVISION register
but they have different number of ports i.e. 2 and 3 respectively.
So we can't rely on REVISION register for number of ports on OMAP5
and depend on platform data (or device tree) instead.
Signed-off-by: Roger Quadros
---
arch
All ports have similarly named port clocks so we can
bunch them into a port data structure and use for loop
to enable/disable the clocks.
Dynamically allocate and get clocks based on number of ports
available on the platform
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 159 ++
Get rid of the unnecessary spin_lock_irqsave/restore() as there is
no interrupt handler for this driver. Instead we serialize access
to tll_dev using a global spinlock.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 53 ++-
1 files changed
No need to check for missing platform data in runtime_suspend/resume
as it makes more sense to do it in the probe function.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll
There is no such clock as utmi_p1_gfclk. It is only a clock selector
bit to select th the parent of usb_host_hs_utmi_p1_clk.
So we get rid of utmi_p1_gfclk and utmi_p2_gfclk by merging them into
usb_host_hs_utmi_p1_clk and usb_host_hs_utmi_p2_clk respectively.
CC: Paul Walmsley
CC: Rajendra Nayak
Enable the optional HSIC clocks (60MHz and 480MHz) for the ports
that are configured in HSIC mode.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 77 +++---
1 files changed, 71 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/omap-usb-
This driver does not request any gpios so don't free them.
Fixes L3 bus error on multiple modprobe/rmmod of ehci_hcd
with ehci-omap in use.
Signed-off-by: Roger Quadros
---
drivers/usb/host/ehci-omap.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/ho
We don't need multiple aliases for the OMAP USB host clocks and neither
the dummy clocks so remove them.
CC: Paul Walmsley
CC: Rajendra Nayak
CC: Benoit Cousson
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/cclock3xxx_data.c | 11 ---
1 files changed, 0 insertions(+), 11 del
clk_set_parent is expected to fail on OMAP3 platforms. We don't
consider that as fatal so don't spam console.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drive
We don't need multiple aliases for the OMAP USB host clocks so remove them.
CC: Paul Walmsley
CC: Rajendra Nayak
CC: Benoit Cousson
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/cclock44xx_data.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/
The driver does not have an interrupt handler and
we don't really need a spinlock, so get rid of it.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/oma
We split initializing revision 1 and revision 2 into different
functions. Initialization is now done dynamically so that only
the number of ports available on the system are initialized.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 122 +
On Tue, Nov 27, 2012 at 6:30 PM, Felipe Balbi wrote:
> On Tue, Nov 27, 2012 at 04:42:47PM +0200, Roger Quadros wrote:
>> Kevin,
>>
>> I gave a quick look at the issue. It seems that the High Speed USB Host
>> module is kept in Software forced wakeup mode as a quick fix workaround
>> to a bunch of
Hello;
After upgrading my machine from kernel 2.6.18 to kernel 3.5.3 `lsusb`
started to not giving output.
With hwdata-0.213.26-1.el5 package installed:
$ lsusb
Protocol spec without prior Class and Subclass spec at line 4297
Gave this error and nothing more.
After downgrading hwdata to hwdata
On Tue, 4 Dec 2012, Anatolij Gustschin wrote:
> mpc5121e doesn't have system interface registers, accessing this
> register address space cause the machine check exception and a
> kernel crash:
>
> ...
> Machine check in kernel mode.
> Caused by (from SRR1=49030): Transfer error ack signal
> Oops
My strace output is like below. `lsusb` looks for /dev/bus/usb and
since it does not exist gives error. So I created symlink to
/sys/bus/usb but it did not give any output too.
execve("/sbin/lsusb", ["lsusb"], [/* 22 vars */]) = 0
brk(0) = 0x888e000
access("/etc/ld
On Tue, Dec 04, 2012 at 05:10:45PM +0200, Deniz Eren wrote:
> Hello;
>
> After upgrading my machine from kernel 2.6.18 to kernel 3.5.3 `lsusb`
> started to not giving output.
>
> With hwdata-0.213.26-1.el5 package installed:
> $ lsusb
> Protocol spec without prior Class and Subclass spec at line
On Mon, 3 Dec 2012, Piergiorgio Sartor wrote:
> Hi Alan,
>
> I updated the bug report with dmesg dump.
>
> I hope this time it is correct...
Yes, it is. It shows a couple of strange things; I need more
information.
Below is a new test patch; try running the test with this patch in
place of
[CC: list trimmed; the people who were on it should be subscribed to at
least one of the lists anyway.]
On Tue, 4 Dec 2012, Andy Green wrote:
> I think associating ULPI PHY reset and SMSC power and reset with the hub
> port power state is good. Then, you could have the driver in a device
> wi
On Tue, Dec 04, 2012 at 11:40:05AM +0800, Andy Green wrote:
> On 04/12/12 01:09, the mail apparently from Alan Stern included:
> >On Mon, 3 Dec 2012, Andy Green wrote:
> >
> >>Unless someone NAKs it for sure already (if you're already sure you're
> >>going to, please do so to avoid wasting time), I
Add device driver for USB2CAN interface from "8 devices"
(http://www.8devices.com).
Signed-off-by: Bernd Krumboeck
---
drivers/net/can/usb/Kconfig|6 +
drivers/net/can/usb/Makefile |1 +
drivers/net/can/usb/usb_8dev.c | 1093
3 files chang
On 12/04/2012 09:44 PM, krumbo...@universalnet.at wrote:
> Add device driver for USB2CAN interface from "8 devices"
> (http://www.8devices.com).
>
> Signed-off-by: Bernd Krumboeck
> ---
> drivers/net/can/usb/Kconfig|6 +
> drivers/net/can/usb/Makefile |1 +
> drivers/net/can/usb/us
Hi!
My broad goal is to transmit the current system time somewhat
accurately to devices (namely fullspeed microcontrollers).
I'd like to be able correlate some instant of a USB frame (i.e. a point
in time with a known offset to the SOF) with the host's system time.
The host PC can then create a
Hi Wolfgang!
Am 2012-12-04 21:44, schrieb Wolfgang Grandegger:
On 12/04/2012 09:44 PM, krumbo...@universalnet.at wrote:
Add device driver for USB2CAN interface from "8 devices"
(http://www.8devices.com).
Signed-off-by: Bernd Krumboeck
---
drivers/net/can/usb/Kconfig|6 +
drivers/n
Hi Alan,
thanks for the patch.
One question, which kernel version should I use
for this patch?
It's the latest from git?
Thanks,
bye,
pg
On Tue, Dec 04, 2012 at 11:45:14AM -0500, Alan Stern wrote:
> On Mon, 3 Dec 2012, Piergiorgio Sartor wrote:
>
> > Hi Alan,
> >
> > I updated the bug repo
On Tue, 4 Dec 2012, Stefan Tauner wrote:
> Hi!
>
> My broad goal is to transmit the current system time somewhat
> accurately to devices (namely fullspeed microcontrollers).
>
> I'd like to be able correlate some instant of a USB frame (i.e. a point
> in time with a known offset to the SOF) with
Add device driver for USB2CAN interface from "8 devices"
(http://www.8devices.com).
Signed-off-by: Bernd Krumboeck
---
drivers/net/can/usb/Kconfig|6 +
drivers/net/can/usb/Makefile |1 +
drivers/net/can/usb/usb_8dev.c | 1089
3 files chang
On 12/04/2012 09:44 PM, krumbo...@universalnet.at wrote:
> Add device driver for USB2CAN interface from "8 devices"
> (http://www.8devices.com).
Please use git send-email to send patches, your mailer does strange things.
>
> Signed-off-by: Bernd Krumboeck
> ---
> drivers/net/can/usb/Kconfig
On Tue, 4 Dec 2012, Piergiorgio Sartor wrote:
> Hi Alan,
>
> thanks for the patch.
>
> One question, which kernel version should I use
> for this patch?
>
> It's the latest from git?
I think it should work with any fairly recent kernel. The patch was
written against linux-next from about six
On 12/04/2012 11:43 PM, Bernd Krumboeck wrote:
> Add device driver for USB2CAN interface from "8 devices"
> (http://www.8devices.com).
>
> Signed-off-by: Bernd Krumboeck
Please use git send-email.
A changelog would be nice, in the form of:
changes since v4:
- done this, deleted that
If you po
On 12/04/2012 11:11 PM, Marc Kleine-Budde wrote:
> On 12/04/2012 11:43 PM, Bernd Krumboeck wrote:
btw: your clock is wrong by about 1h :)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924
Directly casting a work_struct pointer to a delayed_work is risky if the
work member of struct delayed_work is ever moved from being the first
member.
Instead, use the inline function to_delayed_work(), which does the same
cast in a safer way (using container_of).
Signed-off-by: Cesar Eduardo Bar
On Mon, Dec 03, 2012 at 07:57:33PM +0100, Behan Webster wrote:
> However, in order to approximate what gcc is doing in code, obviously
> some math is required. The thought was that macros would hide the
> worst of it, trying not to obfuscate what was actually being done.
Why hide? The thing that i
If I had to guess, I'd say it was a timing issue. The CD-ROM that
doesn't work is taking slightly longer to discover and maybe longer to
get ready.
Most "LiveCD" type distros I've seen load an initrd which has a
wait-loop in it to wait for the real root device to appear before
mount/chroot.
Matt
Hi,
I hope this is the right place to send this, if not please let me know where
would be more appropriate.
We distribute a 2.6.27-based software load on bootable DVD. It's intended
to boot on a system that has no internal DVD drive, so we use USB DVD drives.
With most drives we have no proble
On 12-12-04 11:24 PM, Sebastian Andrzej Siewior wrote:
On Mon, Dec 03, 2012 at 07:57:33PM +0100, Behan Webster wrote:
However, in order to approximate what gcc is doing in code, obviously
some math is required. The thought was that macros would hide the
worst of it, trying not to obfuscate what
Hi Alan,
I reworked the warm reset patches, could you take a look at them?
Changelog:
- Added xHCI roothub port polling when a change bit is set.
- Removed patch to unconditionally clear all change bits on USB 2.0
port disable, since the port polling should now take care of that.
- Rewor
USB 3.0 hubs and roothubs will automatically transition a failed hot
reset to a warm (BH) reset. In that case, the warm reset change bit
will be set, and the link state change bit may also be set. Change
hub_port_finish_reset to unconditionally clear those change bits for USB
3.0 hubs. If these
When the USB core finishes reseting a USB device, the xHCI driver sends
a Reset Device command to the host. The xHC then updates its internal
representation of the USB device to the 'Default' device state. If the
device was already in the Default state, the xHC will complete the
command with an e
If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects. To get device connect notifications, we
need to p
John's NEC 0.96 xHCI host controller needs a longer timeout for a warm
reset to complete. The logs show it takes 650ms to complete the warm
reset, so extend the hub reset timeout to 800ms to be on the safe side.
This commit should be backported to kernels as old as 3.2, that contain
the commit 75
The port reset code bails out early if the current connect status is
cleared (device disconnected). If we're issuing a hot reset, it may
also look at the link state before the reset is finished.
Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the
Error state or Resetting state,
A USB 3.0 device can transition to the Inactive state if a U1 or U2 exit
transition fails. The current code in hub_events simply issues a warm
reset, but does not call any pre-reset or post-reset driver methods (or
unbind/rebind drivers without them). Therefore the drivers won't know
their device
When a hot reset fails on a USB 3.0 port, the current port reset code
recursively calls hub_port_reset inside hub_port_wait_reset. This isn't
ideal, since we should avoid recursive calls in the kernel, and it also
doesn't allow us to issue multiple warm resets on reset failures.
Rip out the recur
The EHCI host controller needs to prevent EHCI initialization when the
UHCI or OHCI companion controller is in the middle of a port reset. It
uses ehci_cf_port_reset_rwsem to do this. USB 3.0 hubs can't be under
an EHCI host controller, so it makes no sense to down the semaphore for
USB 3.0 hubs.
The USB core hub thread (khubd) is designed with external USB hubs in
mind. It expects that if a port status change bit is set, the hub will
continue to send a notification through the hub status data transfer.
Basically, it expects hub notifications to be level-triggered.
The xHCI host controlle
An empty port can transition to either Inactive or Compliance Mode if a
newly connected USB 3.0 device fails to link train. In that case, we
issue a warm reset. Some devices, such as John's Roseweil eusb3
enclosure, slip back into Compliance Mode after the warm reset.
The current warm reset code
The next patch will refactor the hub port code to rip out the recursive
call to hub_port_reset on a failed hot reset. In preparation for that,
make sure all code paths can deal with being called with a NULL udev.
The usb_device will not be valid if warm reset was issued because a port
transitioned
On Tue, 4 Dec 2012 16:27:00 -0500 (EST)
Alan Stern wrote:
> I don't think referencing times to SOF packets is the best approach,
> although it probably is the approach that would yield the most
> precision. How precise do you want your synchronization to be?
It should be below 1ms accuracy, b
On 2012年11月29日 08:08, Alan Stern wrote:
> On Wed, 28 Nov 2012, Sarah Sharp wrote:
>
The shared code to overwrite the bits should probably print a warning if
the host and ACPI bits differ.
>>>
>>> I'm not so sure about that. For one thing, who wants warnings to be
>>> logged every time
+ Benoît, Mike
Hi Roger,
On Tue, 4 Dec 2012, Roger Quadros wrote:
> There is no such clock as utmi_p1_gfclk. It is only a clock selector
> bit to select th the parent of usb_host_hs_utmi_p1_clk.
> So we get rid of utmi_p1_gfclk and utmi_p2_gfclk by merging them into
> usb_host_hs_utmi_p1_clk and
> On 12/04/2012 11:11 PM, Marc Kleine-Budde wrote:
>> On 12/04/2012 11:43 PM, Bernd Krumboeck wrote:
>
>
> btw: your clock is wrong by about 1h :)
Corrected. I like UTC system clock, but Windows doesn't.
Bernd
--
To unsubscribe from this list: send the line "unsubscribe
Thanks, I installed usbutils-006 package and it worked.
On Tue, Dec 4, 2012 at 6:11 PM, Greg KH wrote:
> On Tue, Dec 04, 2012 at 05:10:45PM +0200, Deniz Eren wrote:
>> Hello;
>>
>> After upgrading my machine from kernel 2.6.18 to kernel 3.5.3 `lsusb`
>> started to not giving output.
>>
>> With hw
On 12/04/2012 11:20 PM, Bernd Krumboeck wrote:
> Hi Wolfgang!
>
>
> Am 2012-12-04 21:44, schrieb Wolfgang Grandegger:
>> On 12/04/2012 09:44 PM, krumbo...@universalnet.at wrote:
>>> Add device driver for USB2CAN interface from "8 devices"
>>> (http://www.8devices.com).
>>>
>>> Signed-off-by: Bern
On 05/12/12 01:10, the mail apparently from Alan Stern included:
[CC: list trimmed; the people who were on it should be subscribed to at
least one of the lists anyway.]
On Tue, 4 Dec 2012, Andy Green wrote:
I think associating ULPI PHY reset and SMSC power and reset with the hub
port power sta
On 05/12/12 02:14, the mail apparently from Sarah Sharp included:
On Tue, Dec 04, 2012 at 11:40:05AM +0800, Andy Green wrote:
On 04/12/12 01:09, the mail apparently from Alan Stern included:
On Mon, 3 Dec 2012, Andy Green wrote:
Unless someone NAKs it for sure already (if you're already sure
77 matches
Mail list logo
