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/
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_PRU
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
esday, April 26, 2011 6:15 PM
To: "Nori, Sekhar"
Cc: "Greg KH" ; "Subhasish Ghosh"
;
;
; "Watkins, Melissa"
; ; "Andrew Morton"
; "Randy Dunlap" ; "open
list"
Subject: Re: [PATCH v4 08/11] tty: add pruss SUART driver
O
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 sp
>> >>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 m
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 imple
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 implementat
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 bet
> 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
Davinci-linux-open-s
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 tty_port_block_til_r
On Mon, 9 May 2011 19:20:17 +0530
"Subhasish Ghosh" 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 this function
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
>>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 memo
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
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
Davinci-linu
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
> 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.
>
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 platf
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
| shou
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 y
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
22 matches
Mail list logo
