From: arnd@arndb•de (Arnd Bergmann)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v4 3/6] ARM: vexpress: Add DT support for the motherboard
Date: Thu, 8 Dec 2011 15:41:39 +0000 [thread overview]
Message-ID: <201112081541.39263.arnd@arndb.de> (raw)
In-Reply-To: <1323340679.32116.26.camel@hornet.cambridge.arm.com>
On Thursday 08 December 2011, Pawel Moll wrote:
> On Wed, 2011-12-07 at 22:49 +0000, Arnd Bergmann wrote:
> > On Tuesday 06 December 2011 15:43:46 Pawel Moll wrote:
> > > +
> > > +static struct of_dev_auxdata v2m_dt_auxdata_lookup[] __initdata = {
> > > + OF_DEV_AUXDATA("arm,vexpress-flash", V2M_NOR0, "physmap-flash",
> > > + &v2m_flash_data),
> > > + OF_DEV_AUXDATA("arm,primecell", V2M_MMCI, "mb:mmci", &v2m_mmci_data),
> > > + {}
> > > +};
> >
> > One more thing I noticed. While I'm not familiar with the progress on
> > device driver conversion,
>
> I'm aware of these two last non-DT bits and actually already started
> working on them, but this won't happen this year (I'm on holiday
> starting next Friday without any access to Internet whatsoever :-)
Ok, fine with me. Let's make sure we get everything else ready for 3.3
then.
> > I think you should be using the physmap_of
> > driver instead of physmap, which will remove the need for the
> > platform data.
>
> There's one bit missing in the physmap_of. The "set_vpp" handle which is
> used on VE:
>
> static struct physmap_flash_data v2m_flash_data = {
> .width = 4,
> .set_vpp = v2m_flash_set_vpp,
> };
>
> My plan is to extend the physmap_of driver so it could operate VPP via
> gpio API and make the sysreg a gpio controller, having Flash VPP, CF &
> MMC card detects and DVI output control (that's for CLCD) as internal
> GPIO lines.
>
> > For mmci, it should not be hard to do change the driver so it
> > understands the device tree, too. The easiest implementation for
> > that would be to add some code into mmci_probe and allocate
> > an mmci_platform_data structure that gets filled with the required
> > attributes.
>
> I've started the implementation already, but it turned out much trickier
> that I was hoping... One thing is the "status" handle (card detect line
> "virtual gpio" I mentioned above), the second problem is the fact that
> mmci platform data can take generic caps MMC_CAP_* from
> include/linux/mmc/host.h (now even caps2 as well)... This issue was
> already briefly mentioned here:
> http://article.gmane.org/gmane.linux.kernel.samsung-soc/7639 and as
> there was no generic resolution my plan is to reuse as much properties
> from other MMC host controllers and forge the missing one (as a superset
> of ARM's and STE's cell implementations). But as I said, it's unlikely
> to happen this year...
I see. Thanks for the explanation.
Arnd
next prev parent reply other threads:[~2011-12-08 15:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-06 15:43 [PATCH v4 0/6] Versatile Express DT support Pawel Moll
2011-12-06 15:43 ` [PATCH v4 1/6] ARM: versatile: Add missing ENDPROC to headsmp.S Pawel Moll
2011-12-06 22:52 ` Arnd Bergmann
2011-12-06 15:43 ` [PATCH v4 2/6] ARM: vexpress: Get rid of MMIO_P2V Pawel Moll
2011-12-06 22:49 ` Arnd Bergmann
2011-12-06 15:43 ` [PATCH v4 3/6] ARM: vexpress: Add DT support for the motherboard Pawel Moll
2011-12-06 22:50 ` Arnd Bergmann
2011-12-07 22:49 ` Arnd Bergmann
2011-12-08 10:37 ` Pawel Moll
2011-12-08 15:41 ` Arnd Bergmann [this message]
2011-12-06 15:43 ` [PATCH v4 4/6] ARM: vexpress: Motherboard RS1 memory map support Pawel Moll
2011-12-06 22:51 ` Arnd Bergmann
2011-12-06 15:43 ` [PATCH v4 5/6] ARM: vexpress: DT-based support for Cortex-A5 and Cortex-A9 based tiles Pawel Moll
2011-12-06 22:53 ` Arnd Bergmann
2011-12-06 23:13 ` Arnd Bergmann
2011-12-07 19:06 ` Pawel Moll
2011-12-07 22:50 ` Arnd Bergmann
2011-12-07 15:08 ` Dave Martin
2011-12-07 19:12 ` Pawel Moll
2011-12-07 15:33 ` Dave Martin
2011-12-07 19:09 ` Pawel Moll
2011-12-08 11:40 ` Dave Martin
2011-12-06 15:43 ` [PATCH v4 6/6] ARM: vexpress: DT-based support for Cortex-A7 and Cortex-A15 " Pawel Moll
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=201112081541.39263.arnd@arndb.de \
--to=arnd@arndb$(echo .)de \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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