On Mon, Jul 18, 2011 at 3:45 AM, Ben Dooks <ben-i2c@xxxxxxxxx> wrote:
> On Sun, Jul 17, 2011 at 10:30:59PM -0600, Grant Likely wrote:
>> On Mon, Jul 18, 2011 at 06:20:41AM +0530, Thomas Abraham wrote:
>> > Add device node for i2c instance 1 and list all its connected slave
>> > devices.
>> >
>> > Signed-off-by: Thomas Abraham <thomas.abraham@xxxxxxxxxx>
>> > ---
>> > arch/arm/boot/dts/exynos4-smdkv310.dts | 19 ++++++++++++++++++-
>> > arch/arm/mach-exynos4/Kconfig | 1 +
>> > arch/arm/mach-exynos4/mach-exynos4-dt.c | 9 +++++++++
>> > 3 files changed, 28 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/arch/arm/boot/dts/exynos4-smdkv310.dts b/arch/arm/boot/dts/exynos4-smdkv310.dts
>> > index d65c18c..29c40ed 100644
>> > --- a/arch/arm/boot/dts/exynos4-smdkv310.dts
>> > +++ b/arch/arm/boot/dts/exynos4-smdkv310.dts
>> > @@ -23,7 +23,7 @@
>> > };
>> >
>> > chosen {
>> > - bootargs = "root=/dev/mmcblk0p1 rootfstype=ext3 rootwait console=ttySAC1,115200";
>> > + bootargs = "root=/dev/mmcblk0p1 rootfstype=ext3 rootwait console=ttySAC1,115200 init=/linuxrc";
>> > };
>> >
>> > soc {
>> > @@ -64,5 +64,22 @@
>> > samsung,sdhci-cd-type = <0>;
>> > samsung,sdhci-clkdiv-external;
>> > };
>> > +
>> > + i2c@13870000 {
>> > + compatible = "samsung,s3c2440-i2c";
>> > + reg = <0x13870000 0x100>;
>> > + interrupts = <345>;
>> > + samsung,i2c-bus-number = <1>;
>> > + samsung,i2c-slave-addr = <16>;
>> > + samsung,i2c-sda-delay = <100>;
>> > + samsung,i2c-max-bus-freq = <100000>;
>> > + #address-cells = <1>;
>> > + #size-cells = <0>;
>> > +
>> > + wm8994@1a {
>> > + compatible = "wlf,wm8994";
>> > + reg = <0x1a>;
>> > + };
>> > + };
>> > };
>> > };
>> > diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
>> > index bb97b7e..c7fce3e 100644
>> > --- a/arch/arm/mach-exynos4/Kconfig
>> > +++ b/arch/arm/mach-exynos4/Kconfig
>> > @@ -193,6 +193,7 @@ config MACH_EXYNOS4_DT
>> > select S3C_DEV_HSMMC
>> > select S3C_DEV_HSMMC2
>> > select EXYNOS4_SETUP_SDHCI
>> > + select EXYNOS4_SETUP_I2C1
>> > help
>> > Machine support for Samsung Exynos4 machine with device tree enabled.
>> >
>> > diff --git a/arch/arm/mach-exynos4/mach-exynos4-dt.c b/arch/arm/mach-exynos4/mach-exynos4-dt.c
>> > index 120665a..ef6b4cb 100644
>> > --- a/arch/arm/mach-exynos4/mach-exynos4-dt.c
>> > +++ b/arch/arm/mach-exynos4/mach-exynos4-dt.c
>> > @@ -23,7 +23,10 @@
>> > #include <plat/regs-serial.h>
>> > #include <plat/exynos4.h>
>> > #include <plat/cpu.h>
>> > +#include <plat/devs.h>
>> > #include <plat/sdhci.h>
>> > +#include <plat/iic.h>
>> > +#include <plat/iic-core.h>
>> >
>> > #include <mach/map.h>
>> >
>> > @@ -62,6 +65,10 @@ static struct s3c2410_uartcfg smdkv310_uartcfgs[] __initdata = {
>> > },
>> > };
>> >
>> > +static struct s3c2410_platform_i2c exynos4_dt_i2c_data1 __initdata = {
>> > + .cfg_gpio = s3c_i2c1_cfg_gpio,
>> > +};
>> > +
>> > /*
>> > * The following lookup table is used to override device names when devices
>> > * are registered from device tree. Optionally, the platform data can also
>> > @@ -75,6 +82,8 @@ static const struct of_dev_auxdata exynos4_auxdata_lookup[] __initconst = {
>> > "s3c-sdhci.2", &s3c_hsmmc2_def_platdata),
>> > OF_DEV_AUXDATA("samsung,s3c6410-sdhci", EXYNOS4_PA_HSMMC(0),
>> > "s3c-sdhci.0", &s3c_hsmmc0_def_platdata),
>> > + OF_DEV_AUXDATA("samsung,s3c2440-i2c", EXYNOS4_PA_IIC(1),
>> > + "s3c2440-i2c.1", &exynos4_dt_i2c_data1),
>>
>> Should not need the platform_data here. Add DT support to the GPIO
>> driver and decode the data from there (which should be easy).
>
> Hmm, do we have any sane way of passing which configuration settings
> should be applied to the gpio pins (given that there can be up to 13
> non-IO settings for some of these pins).
I've been looking at having an IO routing configuration node that sets
up the SoC for a particular board. This works for static
configuration, which seems to be 99% of the use cases, but it doesn't
help much for IO configuration that needs to be manipulated at
runtime.
> Also, since this data is really part of the SoC, I don't really want
> to see n different .dts files hanging around with the same information
> in it.
Yes, the SoC details should be in a .dtsi (dts include file) file that
is included by the board file. Properties in the board .dts file will
overlay and override data in the SoC file.
> Maybe it is time for a standardised callback to allow devices to connect
> themselves to the pins they need, and have dt capability of over-riding
> the information if it needs it.
Linus W. has been working on the pinmux subsystem to handle doing
that. Personally, I'm not excited about device drivers managing their
own pin configuration just because the interactions and requirements
between device can be very complex. I'd rather have it handled in a
single place for the whole system, but I'm not the one concentrating
on that problems space.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
