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

quoted

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.

quoted

quoted

quoted

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