On 02.11.2015 16:31, Pavel Fedin wrote:
> Hello!
>
>>> --- cut exynos5410.dtsi ---
>>> sromc: sromc@12250000 {
>>> #address-cells = <2>;
>>> #size-cells = <1>;
>>> ranges = <0 0 0x04000000 0x20000
>>> 1 0 0x05000000 0x20000
>>> 2 0 0x06000000 0x20000
>>> 3 0 0x07000000 0x20000>;
>>
>> Do you have to use 2 cells for address? Cannot it be:
>> ranges = <0 0x04000000 0x20000
>> 1 0x05000000 0x20000
>> 2 0x06000000 0x20000
>> 3 0x07000000 0x20000>;
>
> I tried this first, but it didn't work, and ranges translation
> gave me something really weird (like addr = 0x80 and
> size = 0x04000004).
Did you change the address-cells to <1>?
> I decided not to dig deeply into
> "ranges" processing, but just followed GPMC approach. They say
> that first number is range ID and second number is offset within
> the range. And it just worked.
>
>>> 3. About samsung,srom-config array. I have the following reasons to keep if this way:
>>> - listing every property under own name is just too much typing
>>> - these values really do not make sense without each other, or partialy. I would say
>> that in array form they are even better
>>> readable, because it is the same order in which they go into the register.
>>
>> For timings - OK. PMC is separate. This is not a timing.
>
> But it's srom-config, and not srom-timing anymore. So do you want
> two properties like srom-timing + srom-page-mode (with vendor prefix
> of course)?
Yes, I still want separate properties because this too generic. In next
SoC they will extend the register and you will have to extend the
binding. I agree for simplicity reasons to group timings in an array.
But not entire register.
>> You need to document them. We are not gonna put some data looking like a
>> vendor blob into the binding. I understand that document has
>> confidential mark... all of Samsung datasheets I've seen had it. I don't
>> find it as problem but of course I am not the one to judge here. If you
>> do not feel comfortable publishing such data, get an approval from your
>> manager. You can also try to search for this in vendor code
>> (opensource.samsung.com). If it is published there, then this won't be a
>> disclosure.
>
> I've seen the actual SROMc settings in some old Android kernels, like 3.0.4.
> But they are not documented there, no comments, just #define's.
> Ok, i'll try to take a look how to minimize the actual information. :)
Actually 15 secs of search by grep revealed that they are already
documented and published. I looked at first image coming into my mind:
GT-I9300_JB
arch/arm/mach-exynos/include/mach/sromc-exynos4.h
>> BTW, your email client is weird. You are sending non-wrapped emails
>> without format=flowed in Content-Type. Please stick to mailing list
>> convention of wrapping at 72-char.
>
> I know, sorry, this is MS Outlook (not Express), and it's impossible
> to configure it this way (if i just set up word wrap, it starts to
> corrupt patches). I am now trying to wrap the text by hands, i hope
> it's better. And i cannot use anything else because... You know why. :)
Actually no... I don't know why...
All of us are using whatever we want (mutt+MDA, thunderbird, kmail,
etc.). At least in two locations I've been: in Polish R&D and in HQ.
Best regards,
Krzysztof
--
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
