Thread (1 message) 1 message, 1 author, 2011-05-10

Re: [RFC 1/2] ARM: Tegra: Device Tree Support: Update how sdhci devices are initialized

From: John Bonesio <hidden>
Date: 2011-05-10 23:33:27
Also in: linux-arm-kernel, linux-tegra

On 05/10/2011 04:22 PM, Stephen Warren wrote:
John Bonesio wrote at Tuesday, May 10, 2011 4:33 PM:
quoted
The goal I'm working towards right now is to have the platform specific
code continue to register the devices that are inside the SoC. Then use
the device tree to register all other on board devices.
Sure, that sounds right.

Which branch are your patches aimed at? My discussions are all based
on my experience with Grant's devicetree/test branch.
quoted
This patch doesn't accomplish the whole goal in one step, but gets the
code a little closer toward this goal.
So what's confusing me is that I think the devicetree/test branch is
already there; board-dt.c registers all 4 SDHCI controllers,
tegra250.dtsi defines each controller's memory map etc., and disables
them all, then tegra-harmony.dts and tegra-seaboard.dts enable the
relevant subset of those controllers, and provides the required
platform data for them.

When adding the I2C controllers, it seems like they'd just work the
same way as the existing SDHCI code.
From a philosophical point of view, they should be initialized the same way.
Are you thinking that the i2c controller should be in the
harmony_devices array and initialized with the other devices? If so i2c
is different in the kernel. An i2c controller isn't registered with
platform_device_register().

I may not be understanding your question.
So, all this already works without putting the board-specific platform
data definitions into board-dt.c as an temporary measure.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help