Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

On Thu, Apr 12, 2012 at 08:50:55PM +0200, Cousson, Benoit wrote:
> + Felipe,
> 
> Hi Paul,
> 
> On 4/12/2012 7:00 PM, Paul Walmsley wrote:
> >Hi
> >
> >On Thu, 12 Apr 2012, Mohammed, Afzal wrote:
> >
> >>On Thu, Apr 12, 2012 at 18:40:45, Greg KH wrote:
> >>>On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote:
> >>>>I was hoping that we will have some thing like drivers/memory/*
> >>>>but since it doesn't exist, we used drivers/misc.
> >>>
> >>>Why not create it?  I have no objection to that, it makes it more
> >>>obvious as to what this really is.
> >>
> >>There is another memory controller used in a few TI SoCs,
> >>namely GPMC [1], do you prefer having it too there.
> >>
> >>As of now it is not a driver, platform code handles GPMC, a patch
> >>series for converting it into a driver (but still residing in
> >>platform folder) was sent a few days back [2,3].
> >
> >Probably the GPMC driver should go into a slightly different place than
> >SDRC/EMIF.
> >
> >GPMC is actually a general-purpose parallel bus driver.  It's used to
> >interface Ethernet controllers, UARTs, FPGAs, NAND/NOR flash, SRAM, etc.
> >It cannot be used to control DRAM, at least not without a separate DRAM
> >controller chip.
> >
> >SDRC/EMIF are both DRAM controllers.  That's all they do.  They can't be
> >used to control anything else.  They implement DRAM refresh, etc.
> 
> The LPDDR2 spec does consider as well NVM (Non Volatile Memory), so I
> think we should stick to driver/memory for EMIF.
> 
> >So perhaps something like drivers/memory/dram/ for the SDRAM controllers,
> >and maybe drivers/memory/ for the GPMC?
> 
> In fact Felipe was considering something else for that kind of
> general purpose bus driver like GMPC, C2C and LLI...
> 
> ... But I do not remember the name :-)

the name matters very little :-) But the idea was to avoid writing yet
another bus driver and just use the platform_bus instead. We would do
all the channel/port setup before hand and far-end device driver
wouldn't have to know if it's integrated into the SoC or plugged though
LLI/C2C/GPMC.

From the driver's perspective it would look the same.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]