From: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
To: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>,
Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
linux ARM
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH] cpuidle: kirkwood: Move out of mach directory, add DT.
Date: Fri, 28 Dec 2012 17:38:15 +0100 [thread overview]
Message-ID: <20121228163815.GD5172@lunn.ch> (raw)
In-Reply-To: <50DDC54A.3020509-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > 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
next prev parent reply other threads:[~2012-12-28 16:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-28 12:47 [PATCH] cpuidle: kirkwood: Move out of mach directory, add DT Andrew Lunn
2012-12-28 14:32 ` Florian Fainelli
[not found] ` <50DDAD68.4090704-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
2012-12-28 14:37 ` Andrew Lunn
[not found] ` <1356698844-4220-1-git-send-email-andrew-g2DYL2Zd6BY@public.gmane.org>
2012-12-28 14:18 ` Rob Herring
[not found] ` <50DDAA42.2020101-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-28 14:35 ` Andrew Lunn
[not found] ` <20121228143517.GA5172-g2DYL2Zd6BY@public.gmane.org>
2012-12-28 14:55 ` Rob Herring
[not found] ` <50DDB2E3.103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-28 15:49 ` Andrew Lunn
[not found] ` <20121228154927.GC5172-g2DYL2Zd6BY@public.gmane.org>
2012-12-28 16:14 ` Rob Herring
[not found] ` <50DDC54A.3020509-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-28 16:38 ` Andrew Lunn [this message]
[not found] ` <20121228163815.GD5172-g2DYL2Zd6BY@public.gmane.org>
2012-12-28 16:59 ` Rob Herring
2012-12-28 16:56 ` Santosh Shilimkar
[not found] ` <50DDCF47.1030305-l0cyMroinI0@public.gmane.org>
2012-12-28 17:28 ` Andrew Lunn
[not found] ` <20121228172807.GA7578-g2DYL2Zd6BY@public.gmane.org>
2012-12-28 17:50 ` Santosh Shilimkar
[not found] ` <50DDDBEB.3000002-l0cyMroinI0@public.gmane.org>
2012-12-28 17:56 ` Andrew Lunn
[not found] ` <20121228175618.GC7578-g2DYL2Zd6BY@public.gmane.org>
2012-12-28 18:02 ` Santosh Shilimkar
2013-02-08 21:34 ` Grant Likely
2013-02-10 18:58 ` Andrew Lunn
2013-02-11 11:41 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121228163815.GD5172@lunn.ch \
--to=andrew-g2dyl2zd6by@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org \
--cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).