On Tue, Oct 28, 2014 at 10:04:55AM +0100, Alexandre Belloni wrote: > > > > I'd rather keep the reset driver as is and move SDRAM related macros > > > > into a specific header (include/linux/memory/atmel-sdram.h or > > > > include/soc/atmel/memory.h as you proposed) so that the reset driver > > > > can reference them without including mach headers. > > > > > > > > > > My personal opinion is that it is better to hide the registers/bits from > > > the reset driver right now as we have two different IPs and the sdram > > > driver already knows how to make the difference between them. > > > > The reset driver doesn't do anything anymore with these patches. Why > > not just remove it altogether? > > > > It does, the reset driver knows about the reset registers.
So the only thing it does it to define a few register and that's it? It looks like it's a case for a header, not a driver. > The plan is to move the actual reset back to that driver when the > kernel will be able to easily execute code from sram. Why not go directly for the plan then? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
signature.asc
Description: Digital signature
