Tomasz, On Thu, May 1, 2014 at 10:30 AM, Tomasz Figa <tomasz.figa@xxxxxxxxx> wrote: > On 01.05.2014 17:40, Doug Anderson wrote: >> >> Arun, >> >> On Wed, Apr 30, 2014 at 4:08 AM, Arun Kumar K <arun.kk@xxxxxxxxxxx> wrote: >>> >>> + memory { >>> + reg = <0x20000000 0x80000000>; >> >> >> As mentioned in the other thread, I think this should be 0 0 > > > I guess it may depend on your boards, but DT might contain safe default > configuration that would work on all variants, so if you have for example 1 > GiB and 2 GiB variants, 1 GiB configuration here should be fine to get the > board running even without a bootloader that could inject remaining data. That was part of the debate yesterday, I thought. Tom Rini (U-Boot guy) said that right now U-Boot clobbers the memory node _always_ and fills it in with whatever it detects. He wasn't sure this was a good idea. Someone said they thought that it wasn't a good idea, but someone could request U-Boot keep clobbering things by doing <0 0> Tom: did I summarize that correctly? >>> +&pinctrl_0 { >>> + tpm_irq: tpm-irq { >>> + samsung,pins = "gpx1-0"; >>> + samsung,pin-function = <0>; >>> + samsung,pin-pud = <0>; >> >> >> Is there any way to use the #defines PIN_PULL_NONE here? > > > I wonder if we already have this kind of #define defined. Keep in mind that > this value is specific for Exynos SoCs, so we would need to define it in > Exynos-specific header, like include/dt-bindings/pinctrl/exynos.h. I dunno. I'd actually love to see function 0/1 defined (input / output) too. ...and drive strengths (since 0, 1, 2, 3 don't map nicely to x1, x2, x3, x4). I requested PIN_PULL_NONE though, since I saw it being used. ...oh, but it's a #define in a .dtsi. Hrm. arch/arm/boot/dts/s3c64xx-pinctrl.dtsi:#define PIN_PULL_NONE 0 I guess I'd say that it would be nice to do this properly for exynos, but we could do it in a later patch. -Doug -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html