[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024CBA9959@dbde02.ent.ti.com>
Date: Wed, 27 Apr 2011 16:49:02 +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
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 allocator functions. There
> >> has been SRAM allocator consolidation work done by Russell
> >> and as a result the SRAM allocator API for DaVinci will
> >> actually change.
>
> I earlier had an implementation where I would get the sram memory addresses
> through the .resource structure and ioremap it in the driver.
This is wrong since it assumes the whole SRAM is available
for usage by your driver. We already have an allocator
for 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 to the driver.
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/
Powered by blists - more mailing lists