[PATCH] cpuidle: kirkwood: Move out of mach directory, add DT.

[Andrew Lunn]

> > The block of registers is for controlling the SDRAM. Its not really a
> > MFD. The cpuidle code is putting the SDRAM controller into self
> > refresh mode and then doing a WFI.
> 
> It is multi-function in the sense that multiple subsystems needing to
> access shared registers. If you have ECC, then you would need to give
> EDAC subsystem access to ECC related registers.

There is no ECC. Data sheet specifically says its not supported.

Currently, there are no other users of the SDRAM controller than
cpuidle. Linux is not touching the configuration, so i assume early
boot code in u-boot is setting up the controller.

> >>> I could just hard code the address, since its the same for all
> >>> kirkwood SoCs. Also, the register is not being used by any other
> >>> code on kirkwood, so its not shared.
> >>
> >> Then describe it based on the reference manual, but you need to do so
> >> assuming you are using all the other registers. I assume there are other
> >> registers at say 0x1414 or 0x141c. You have to be careful if you create
> >> separate nodes for each register or sub-group of registers. It needs to
> >> work no matter what the OS expectation is.
> > 
> > I don't understand what you are try to explain here. It makes little
> > sense for the cpuidle driver to take all the SDRAM control registers.
> 
> Exactly. The same is true of the dts. It makes little sense to describe
> only 1 register of a h/w block. Perhaps the memory controller subsystem
> (drivers/memory) can be expanded to include self-refresh functions.
> Entering self-refresh can be tricky, so it might not really be possible
> to define a common api here.

For kirkwood it is easy. Poke 0x7 into the register and then WFI.

However, since there are no other users of the SDRAM controller, it
seems overkill to implement a drivers/memory driver, or a MFD driver,
for just one register.

So maybe i just end up hard coding the register address in the driver?

	Thanks

		Andrew