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 linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
