Changes are as per these discussions
http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg22841.html
Please let me know if there are any comments on this patch?
It never got here for some reason. Last I have in my mailbox is the
discussion of the 17th April ?
As per my understanding, tty count keeps the count of tty_open and
tty_release, that is
how many open and close happened on the tty device file(/dev/ttyS*).
The requirement here is a tty count check, if it is greater than zero then
only it should
proceed for further execution.
The
I will have a look at this and add the lock if necessary.
At the very least you need reference counts held on the tty struct and to
allow for the tty having vanished under you.
I am planning to add tty-termios_mutex lock. Any comments ?
Explain how this will help. You need a
On Thu, 5 Apr 2012 10:40:55 +
Shankarmurthy, Akshay aksha...@ti.com wrote:
Hi,
On Tue, Apr 03, 2012 at 15:25:30, Alan Cox wrote:
This patch was submitted 2 years ago but didn't make it to the mainline.
Now i am reposting it.
Can you fix it instead of just reposting
This patch was submitted 2 years ago but didn't make it to the mainline. Now
i am reposting it.
Can you fix it instead of just reposting it ?
+#ifdef CONFIG_CPU_FREQ
+static int serial8250_cpufreq_transition(struct notifier_block *nb,
+ unsigned
I know nothing about journalling file systems or how well they limit the
critical sections of time where the file system is exposed to corruption
from sudden power failure. Its an interesting question though.
A properly written journalling file system has no critical sections. The
only things
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.
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
On Tue, 10 May 2011 15:41:49 +0530
Subhasish Ghosh subhas...@mistralsolutions.com wrote:
It sounds to me like the best solution would be change the firmware
to lift that restriction and simply allow all IDs, in case it's not
actually a hardware limitation (which sounds unlikely).
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.
___
Davinci-linux-open-source mailing list
I then modified this function to as follows and the error is not observed
anymore.
That looks like you are somehow calling uart_carrier_raised somewhere
with interrupts disabled ?
Alan
___
Davinci-linux-open-source mailing list
On Mon, 9 May 2011 19:20:17 +0530
Subhasish Ghosh subhas...@mistralsolutions.com wrote:
I then modified this function to as follows and the error is not observed
anymore.
That looks like you are somehow calling uart_carrier_raised somewhere
with interrupts disabled ?
I am not calling
I tried using a tasklet for the TX part, but that did not help.
Another way is to prepare the buffer for the next read and read the data
immediately.
Something like this:
1. Call tty_prepare_flip_string while startup.
2. When the read interrupt arrives, read the data immediately.
3. Call
On Fri, 18 Feb 2011 19:17:38 +0530
Subhasish Ghosh subhas...@mistralsolutions.com wrote:
Hello,
Regarding the semaphore to mutex migration.
We are using down_trylock in interrupt context,
mutex_trylock cannot be used in interrupt context, so we cannot use mutex in
our driver.
Then you
Don't see why it needs its own sub-directory
+#ifdef __SUART_DEBUG
+#define __suart_debug(fmt, args...) \
+ printk(KERN_DEBUG suart_debug: fmt, ## args)
+#else
+#define __suart_debug(fmt, args...)
+#endif
+
+#define __suart_err(fmt, args...) printk(KERN_ERR suart_err:
This patch was tested using a MityDSP-L138F platform having a UART CTS pin
connected to a clock signal (and configured, via pinmux, as a clock input
for another peripheral function).
Please hide such horrors in your platform code. We are trying todrive all
the quirks stuff we can out of the
On Thu, 21 Oct 2010 17:01:02 -0400
Cyril Chemparathy cy...@ti.com wrote:
TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial
port
device. It has a built-in programmable execution engine that can be
programmed
to operate as almost any serial bus (I2C, SPI, EasyScale,
17 matches
Mail list logo
