Re: ohci, hub TUSB2046B, AT91SAM9G20 problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 05, 2012 at 07:55:34PM +0100, j.uzycki@xxxxxxxxxxxxxx wrote:
> >>You are right, I know. As I wrote the latest kernel version does not
> >>guarantee of stable system and generates a lot of work again
> >>especialy in case of embedded systems (runs slower, kernel/drivers
> >>tasks/interrupts race appears).
> >
> >What do you mean?  That the 3.2 kernel has problems for you?  What
> >specific ones?  If you don't work to get them fixed, then you will be
> >stuck with these problems for forever :)
> 
> Please look here:
> http://www.at91.com/linux4sam/bin/view/Linux4SAM/LinuxKernel => last
> public patch 2.6.30 (in unofficial folder 2.6.39)
> and here:
> http://maxim.org.za/at91_26.html => last patch 2.6.38, maybe
> included into valinila?

These might all be merged into mainline already, if not, they should be :)

> Kernel 3.2 is to new for me because I am not strong enough yet
> (time, knowledge) to port everything(whole platform) to this version
> now. If I change kernel every version I will never finish to write
> code.

If the code is upstream, in the kernel.org releases, nothing new should
need to be "ported", it should "just work".  If not, we are doing
something wrong in the kernel development process.

> I hope that somebody had similar problem in the past (old kernels)
> or even now and he will remind. I didn't found proper word
> combination in Google for my problem - not enough data to exact
> identify problem yet.
> 
> Interrupt/tasklets racing is not visible on machines like fast PC.
> Even for current kernel, 280MHz CPU and eg. external UART chipset
> the CPU under high load is not able to service interrupt before FIFO
> overrun. Additional protection code must be added because UART
> chip's FIFO blocks after the overrun and linux kernel drivers rule
> "write simple as you can but not simpler" is not always good.

What FIFO are you talking about here?  What driver is affected?

> >>If I had easy choice I would use at least 2.6.33 embedded-stable
> >>version. The kernel was patched a lot for the CPU and other drivers
> >>(back-compatibility issue). For example compat-wireless was used for
> >>WIFI stack update. Is there something similar for USB tree?
> >
> >No, not at all, sorry.
> 
> And there is no plans for the future? It seems only host/gadget
> small part is

No, there are no plans to do this, it's a non-trivial task, one that I
did for my employer once, and never want to, and never will, do again
(900+ patches to just get the USB 3.0 code working in the 2.6.32 kernel
release.)

> >>So I still hope for solution using 2.6.30.10.
> >
> >I think you are on your own here, sorry.  There's nothing the
> >community
> >can do with such an old and obsolete kernel version.
> 
> I will try to investigate and wait for some time. It would be nice
> to learn use usbmon and debug. In case of failure I will try the
> newest kernel.

usbmon should work on your existing kernel.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux