Hi Sekhar,
ok, so what you are suggesting is that I implement some
callbacks (like .fifo_alloc, .fifo_dealloc) which can allocate
memory using sram_alloc.
My doubt is, if already such API's are there (by Russel) or you
are suggesting to implement them.
I can add the fifo_alloc/dealloc as
On Mon, May 16, 2011 at 10:47:18, Subhasish Ghosh wrote:
Hi Sekhar,
Say, if the driver is loaded as a module.
If I allocate the sram in the platform code, how to I
free it when the driver is unloaded.
This is what I said in my last e-mail. What is
the issue you see with this
Hi Sekhar,
Say, if the driver is loaded as a module.
If I allocate the sram in the platform code, how to I
free it when the driver is unloaded.
This is what I said in my last e-mail. What is
the issue you see with this approach?
| Thanks for the clarification. In this case, the driver
|
Say, if the driver is loaded as a module.
If I allocate the sram in the platform code, how to I
free it when the driver is unloaded.
This is what I said in my last e-mail. What is
the issue you see with this approach?
| Thanks for the clarification. In this case, the driver
| should use
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
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.
Hi Alan,
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 this function in my driver atall, this is getting called
by
tty_port.c
Can
The driver should probably just get sram
space through platform data so that it doesn't depend on the
platform specific sram allocation function.
Are you suggesting that I go back to that implementation.
No, the platform code should use the SRAM allocator and
pass on the allocated memory to
On Tue, May 10, 2011 at 16:24:35, Subhasish Ghosh wrote:
The driver should probably just get sram
space through platform data so that it doesn't depend on the
platform specific sram allocation function.
Are you suggesting that I go back to that implementation.
No, the platform
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
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 this function in my driver atall, this is getting called by
tty_port.c
int
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
Hi Subhasish,
On Wed, Apr 27, 2011 at 18:45:06, Subhasish Ghosh wrote:
The driver should probably just get sram
space through platform data so that it doesn't depend on the
platform specific sram allocation function.
Are you suggesting that I go back to that implementation.
No, the
On Mon, May 02, 2011 at 14:04:11, Subhasish Ghosh wrote:
SG - So, should I call the sram_alloc() in the platform setup function.
Can you please shed some light on how SRAM
is being used in the driver? Looking at the
driver, it looks like it is used as a shared
buffer between the PRU
On Wed, Apr 27, 2011 at 10:53:38, Subhasish Ghosh wrote:
There should be no build time dependency with this patch
(the above patch just changes which pool of SRAM the
allocation happens from)
But, this brings out an important dependency of the patch
calling platform specific sram
The driver should probably just get sram
space through platform data so that it doesn't depend on the
platform specific sram allocation function.
Are you suggesting that I go back to that implementation.
No, the platform code should use the SRAM allocator and
pass on the allocated memory
Hi Subhasish,
On Wed, Apr 27, 2011 at 18:45:06, Subhasish Ghosh wrote:
The driver should probably just get sram
space through platform data so that it doesn't depend on the
platform specific sram allocation function.
Are you suggesting that I go back to that implementation.
No,
On Tue, Apr 26, 2011 at 02:50:56, Greg KH wrote:
On Fri, Apr 22, 2011 at 05:38:26PM +0530, Subhasish Ghosh wrote:
This patch adds support for the TTY compliant
Soft-UART device emulated on PRUSS.
This patch depends on:
davinci: macro rename DA8XX_LPSC0_DMAX to DA8XX_LPSC0_PRUSS.
On Tue, Apr 26, 2011 at 12:21:04PM +0530, Nori, Sekhar wrote:
On Tue, Apr 26, 2011 at 02:50:56, Greg KH wrote:
On Fri, Apr 22, 2011 at 05:38:26PM +0530, Subhasish Ghosh wrote:
This patch adds support for the TTY compliant
Soft-UART device emulated on PRUSS.
This patch depends on:
Morton
a...@linux-foundation.org; Randy Dunlap randy.dun...@oracle.com; open
list linux-ker...@vger.kernel.org
Subject: Re: [PATCH v4 08/11] tty: add pruss SUART driver
On Tue, Apr 26, 2011 at 12:21:04PM +0530, Nori, Sekhar wrote:
On Tue, Apr 26, 2011 at 02:50:56, Greg KH wrote:
On Fri, Apr 22
On Fri, Apr 22, 2011 at 05:38:26PM +0530, Subhasish Ghosh wrote:
This patch adds support for the TTY compliant
Soft-UART device emulated on PRUSS.
This patch depends on:
davinci: macro rename DA8XX_LPSC0_DMAX to DA8XX_LPSC0_PRUSS.
https://patchwork.kernel.org/patch/615681/
22 matches
Mail list logo
