Re: [PATCH v4 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Krzysztof Kozlowski]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/