Re: [PATCH v4 08/11] tty: add pruss SUART driver

2011-05-11 Thread Subhasish Ghosh
Trace all looks fine. I can't see anything else taking the lock so you'll need to do a bit more debugging and find out why the spin lock change makes the difference and what the real root cause is. We do not support Modem control signals. So, I use -clocal with stty, but I observe that still ena

Re: [PATCH v4 01/11] mfd: add pruss mfd driver.

2011-05-11 Thread Subhasish Ghosh
Please look into implementing one of the three I suggested before you go off in another direction. In case of the third one, the idea was to configure the name of the device for each pru using sysfs, which then gets bound to the driver, which loads its own firmware as you do today. Only in the fir

Re: [PATCH v4 08/11] tty: add pruss SUART driver

2011-05-11 Thread Alan Cox
> We do not support Modem control signals. So, I use -clocal with stty, > but I observe that still enable_ms and get_mctrl handlers get called. > Is that normal, how can I disable these functions from getting called. It is normal. > Actually, this same driver works perfectly with 2.6.33 kernel. >

Re: [PATCH v4 01/11] mfd: add pruss mfd driver.

2011-05-11 Thread Arnd Bergmann
On Wednesday 11 May 2011, Subhasish Ghosh wrote: > > Please look into implementing one of the three I suggested before > > you go off in another direction. In case of the third one, the idea > > was to configure the name of the device for each pru using sysfs, > > which then gets bound to the drive

Re: [PATCH v4 1/1] can: add pruss CAN driver.

2011-05-11 Thread Arnd Bergmann
On Tuesday 10 May 2011, Subhasish Ghosh wrote: > > >> Yes, In case if we allow the ALL implementation, it hogs the CPU. > >> In that case we do not need the PRU. The whole purpose of the PRU > >> is to offload the processor for any such implementations. > > > > So the kernel presumably needs to

Re: [PATCH v4 1/1] can: add pruss CAN driver.

2011-05-11 Thread Arnd Bergmann
On Wednesday 11 May 2011, Arnd Bergmann wrote: > If that interpretation is right, I would seriously recommend rethinking > the design of the CAN firmware for pruss, so you can start doing something > useful with the offload engine that fits into the Socket CAN API, or that > would be a useful exten

Re: [PATCH v4 1/1] can: add pruss CAN driver.

2011-05-11 Thread Alan Cox
> I'm not sure if reprogramming hardware filters on the fly works on evey > can core. The more conservative solution would be to configure the > filter list globally (+when the interface is down) via netlink. For anything that isn't so braindead it ought to be done on the fly and behind the users