linux-kernel - RE: [PATCH v4 08/11] tty: add pruss SUART driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024CBA9B31@dbde02.ent.ti.com>
Date:	Wed, 27 Apr 2011 23:20:18 +0530
From:	"Nori, Sekhar" <nsekhar@...com>
To:	Subhasish Ghosh <subhasish@...tralsolutions.com>,
	Greg KH <gregkh@...e.de>
CC:	Greg KH <greg@...ah.com>,
	"davinci-linux-open-source@...ux.davincidsp.com" 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"Watkins, Melissa" <m-watkins@...com>,
	"sachi@...tralsolutions.com" <sachi@...tralsolutions.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	open list <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v4 08/11] tty: add pruss SUART driver

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 platform code should use the SRAM allocator and
> > pass on the allocated memory to the driver.
> 
> 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 firmware and kernel.

If yes, how do you cope with dynamic allocation
of SRAM? That is, how do you inform the firmware
what portion of SRAM has been allocated to the
driver?

Also, usage of SRAM is not required for basic driver
function, correct? So, a platform which does not
have SRAM to spare for this driver could still have
a portion of SDRAM/DDR allocated to be used as the
shared buffer? I guess SRAM was used only for lower
access times. But it should still be possible to
sustain lower baudrates with SDRAM/DDR?

Thanks,
Sekhar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/