| Message ID | f1fbd1a7877090f4318705f0fccbf4d96c0ebc9c.1446122247.git.p.fedin@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 29.10.2015 21:42, Pavel Fedin wrote: > Add documentation for new subnode properties, allowing bank configuration. > Based on u-boot implementation, but heavily reworked. Please, carefully look at: Documentation/devicetree/bindings/net/gpmc-eth.txt Documentation/devicetree/bindings/bus/ti-gpmc.txt 1. Try to re-use existing bindings. Although I see existing bank-width and gpmc,device-width but yours samsung,srom-data-width seems better. Maybe there are other to re-use? 2. The array of "PMC, Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs" is poorly extendable and not very descriptive/readable. You mapped directly device register which is the easier way for the driver but that is not the purpose of binding. 3. Please provide ranges for valid values and units. 4. PMC is not a timing. I doubt that TI GPMC could be used in Exynos SROM but please look at it and get useful stuff from it. Best regards, Krzysztof > > Signed-off-by: Pavel Fedin <p.fedin@samsung.com> > --- > .../bindings/arm/samsung/exynos-srom.txt | 50 +++++++++++++++++++++- > 1 file changed, 48 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt > index 33886d5..02ecc7f 100644 > --- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt > +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt > @@ -5,8 +5,54 @@ Required properties: > > - reg: offset and length of the register set > > -Example: > +- #address-cells, #size-cells : should be '1' if the device has sub-nodes > + with 'reg' property. > +- ranges: allows valid 1:1 translation between child's address space and > + parent's address space > + > +Sub-nodes: > +The SROM controller can be used to attach external peripherials. In this case > +device nodes should be added as subnodes to the SROMc node. These subnodes, > +except regular device specification, should contain the following properties, > +describing configuration of the relevant SROM bank: > + > +Required properties: > +- samsung,srom-bank : bank number (0 - 3) > + > +- samsung,srom-timing : array of 7 integers: PMC, Tacp, Tcah, Tcoh, Tacc, Tcos, > + Tacs > + > +Optional properties: > +- samsung,srom-data-width : data width in bytes (1 or 2). If omitted, default > + of 1 is used. > + > +Example: basic definition, no banks are configured > sromc@12570000 { > compatible = "samsung,exynos-srom"; > - reg = <0x12570000 0x10>; > + reg = <0x12570000 0x14>; > + }; > + > +Example: SROMc with smsc 911x ethernet chip on bank 3 > + sromc@12570000 { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + compatible = "samsung,exynos-srom"; > + reg = <0x12570000 0x14>; > + > + ethernet@07000000 { > + compatible = "smsc,lan9115"; > + reg = <0x07000000 0x10000>; > + phy-mode = "mii"; > + interrupt-parent = <&gpx0>; > + interrupts = <5 8>; > + reg-io-width = <2>; > + smsc,irq-push-pull; > + smsc,force-internal-phy; > + > + samsung,srom-bank = <3>; > + samsung,srom-data-width = <2>; > + samsung,srom-timing = <1 9 12 1 9 1 1>; > + }; > }; >
Hello! > > Add documentation for new subnode properties, allowing bank configuration. > > Based on u-boot implementation, but heavily reworked. > > Please, carefully look at: > Documentation/devicetree/bindings/net/gpmc-eth.txt > Documentation/devicetree/bindings/bus/ti-gpmc.txt Thank you very much. Indeed, this looks very similar. By the way, should i document smsc over sromc in the same manner, writing devicetree/bindings/net/sromc-eth.txt? This is a short reply for now, i'll make longer one (or just a new version) after studying these existing bindings and trying to apply them. Pankaj: > > +&sromc { > > + pinctrl-names = "default"; > > + pinctrl-0 = <&srom_ctl>, <&srom_ebi>; > > + > > + ethernet@07000000 { > > + compatible = "smsc,lan9115"; > > + reg = <0x07000000 0x10000>; > > + phy-mode = "mii"; > > + interrupt-parent = <&gpx0>; > > + interrupts = <5 8>; > > + reg-io-width = <2>; > > + smsc,irq-push-pull; > > + smsc,force-internal-phy; > > + > > + samsung,srom-bank = <3>; > > + samsung,srom-data-width = <2>; > > + samsung,srom-timing = <1 9 12 1 9 1 1>; > > I think this is not correct. We can't change binding of "smsc,lan9115" > which is already documented here [1]. These samsung specific srom > properties should be in srom node or its subnode, but not in this way. So, if you look at gpmc-eth.txt, you'll see that this approach is perfectly valid (this is a reply to another msg, just don't want to post one more single-line reply). Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
On 30.10.2015 15:58, Pavel Fedin wrote: > Hello! > >>> Add documentation for new subnode properties, allowing bank configuration. >>> Based on u-boot implementation, but heavily reworked. >> >> Please, carefully look at: >> Documentation/devicetree/bindings/net/gpmc-eth.txt >> Documentation/devicetree/bindings/bus/ti-gpmc.txt > > Thank you very much. Indeed, this looks very similar. By the way, should i document smsc over sromc in the same manner, writing > devicetree/bindings/net/sromc-eth.txt? > > This is a short reply for now, i'll make longer one (or just a new version) after studying these existing bindings and trying to > apply them. Existing SROMC bindings document is small so one document for everything should be sufficient. This can be always split if new type of devices will be using SROMC (BTW, do you know of any other devices using SROMC on Exynos?). > > Pankaj: > >>> +&sromc { >>> + pinctrl-names = "default"; >>> + pinctrl-0 = <&srom_ctl>, <&srom_ebi>; >>> + >>> + ethernet@07000000 { >>> + compatible = "smsc,lan9115"; >>> + reg = <0x07000000 0x10000>; >>> + phy-mode = "mii"; >>> + interrupt-parent = <&gpx0>; >>> + interrupts = <5 8>; >>> + reg-io-width = <2>; >>> + smsc,irq-push-pull; >>> + smsc,force-internal-phy; >>> + >>> + samsung,srom-bank = <3>; >>> + samsung,srom-data-width = <2>; >>> + samsung,srom-timing = <1 9 12 1 9 1 1>; >> >> I think this is not correct. We can't change binding of "smsc,lan9115" >> which is already documented here [1]. These samsung specific srom >> properties should be in srom node or its subnode, but not in this way. > > So, if you look at gpmc-eth.txt, you'll see that this approach is perfectly valid (this is a reply to another msg, just don't want > to post one more single-line reply). Yes, the binding of smsc,lan9115 is not changed. Putting srom properties in separate bank node would be good also but then some mapping (connection) between ethernet and bank should be added probably... Best regards, Krzysztof
Hello! > Please, carefully look at: > Documentation/devicetree/bindings/net/gpmc-eth.txt > Documentation/devicetree/bindings/bus/ti-gpmc.txt > > 1. Try to re-use existing bindings. Although I see existing bank-width > and gpmc,device-width but yours samsung,srom-data-width seems better. > Maybe there are other to re-use? I've done this and this is what i currently came up with. I'd like to discuss this before respin because nobody needs this back-and-forth bouncing. --- 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>; compatible = "samsung,exynos-srom"; reg = <0x12250000 0x14>; }; --- cut exynos5410.dtsi --- --- cut exynos5410-smdk5410.dts --- &sromc { pinctrl-names = "default"; pinctrl-0 = <&srom_ctl>, <&srom_ebi>; ethernet@3 { compatible = "smsc,lan9115"; reg = <3 0 0x10000>; phy-mode = "mii"; interrupt-parent = <&gpx0>; interrupts = <5 8>; reg-io-width = <2>; smsc,irq-push-pull; smsc,force-internal-phy; samsung,srom-config = <1 9 12 1 9 1 1>; }; }; --- cut exynos5410-smdk5410.dts --- 1. After writing proper ranges i was able to get rid of dedicated bank number property, because now it is the first value in device's "reg". 2. I noticed that smsc binding already uses reg-io-width property. I searched for it, and it appears to be reused by many devices. So, i decided to use it to specify bank width, since it's already there. ti-gpmc uses bank-width because it supports configurations like reg-io-width = 4 && bank-width = 2. I don't know if it's possible to do the same with SROMc, Exynos doc doesn't tell anything about 32-bit accesses. But, if you want to support it too, i would suggest the following algorithm: if (have bank-width) width = bank-width else if (have reg-io-width) width = reg-io-width else width = 1 /* default */ 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. However, it is still a nice idea do document them, but... my PDF has "confidential" watermark on it, and this would mean that i essentially copy some information from it into Linux doc. Is it okay to do this? If you still dislike the array, i'll redo is a set of properties like samsung,srom-tacs, samsung,srom-tcos, etc. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
On Fri, Oct 30, 2015 at 2:23 AM, Krzysztof Kozlowski <k.kozlowski@samsung.com> wrote: > On 30.10.2015 15:58, Pavel Fedin wrote: >> Hello! >> >>>> Add documentation for new subnode properties, allowing bank configuration. >>>> Based on u-boot implementation, but heavily reworked. >>> >>> Please, carefully look at: >>> Documentation/devicetree/bindings/net/gpmc-eth.txt >>> Documentation/devicetree/bindings/bus/ti-gpmc.txt >> >> Thank you very much. Indeed, this looks very similar. By the way, should i document smsc over sromc in the same manner, writing >> devicetree/bindings/net/sromc-eth.txt? >> >> This is a short reply for now, i'll make longer one (or just a new version) after studying these existing bindings and trying to >> apply them. > > Existing SROMC bindings document is small so one document for everything > should be sufficient. This can be always split if new type of devices > will be using SROMC (BTW, do you know of any other devices using SROMC > on Exynos?). > >> >> Pankaj: >> >>>> +&sromc { >>>> + pinctrl-names = "default"; >>>> + pinctrl-0 = <&srom_ctl>, <&srom_ebi>; >>>> + >>>> + ethernet@07000000 { >>>> + compatible = "smsc,lan9115"; >>>> + reg = <0x07000000 0x10000>; >>>> + phy-mode = "mii"; >>>> + interrupt-parent = <&gpx0>; >>>> + interrupts = <5 8>; >>>> + reg-io-width = <2>; >>>> + smsc,irq-push-pull; >>>> + smsc,force-internal-phy; >>>> + >>>> + samsung,srom-bank = <3>; >>>> + samsung,srom-data-width = <2>; >>>> + samsung,srom-timing = <1 9 12 1 9 1 1>; >>> >>> I think this is not correct. We can't change binding of "smsc,lan9115" >>> which is already documented here [1]. These samsung specific srom >>> properties should be in srom node or its subnode, but not in this way. >> >> So, if you look at gpmc-eth.txt, you'll see that this approach is perfectly valid (this is a reply to another msg, just don't want >> to post one more single-line reply). > > > Yes, the binding of smsc,lan9115 is not changed. > > Putting srom properties in separate bank node would be good also but > then some mapping (connection) between ethernet and bank should be added > probably... Is this to get some data needed by the ethernet from the ROM? We have the nvmem binding to support that. Rob
W dniu 31.10.2015 o 02:15, Rob Herring pisze: > On Fri, Oct 30, 2015 at 2:23 AM, Krzysztof Kozlowski > <k.kozlowski@samsung.com> wrote: >> On 30.10.2015 15:58, Pavel Fedin wrote: >>> Hello! >>> >>>>> Add documentation for new subnode properties, allowing bank configuration. >>>>> Based on u-boot implementation, but heavily reworked. >>>> >>>> Please, carefully look at: >>>> Documentation/devicetree/bindings/net/gpmc-eth.txt >>>> Documentation/devicetree/bindings/bus/ti-gpmc.txt >>> >>> Thank you very much. Indeed, this looks very similar. By the way, should i document smsc over sromc in the same manner, writing >>> devicetree/bindings/net/sromc-eth.txt? >>> >>> This is a short reply for now, i'll make longer one (or just a new version) after studying these existing bindings and trying to >>> apply them. >> >> Existing SROMC bindings document is small so one document for everything >> should be sufficient. This can be always split if new type of devices >> will be using SROMC (BTW, do you know of any other devices using SROMC >> on Exynos?). >> >>> >>> Pankaj: >>> >>>>> +&sromc { >>>>> + pinctrl-names = "default"; >>>>> + pinctrl-0 = <&srom_ctl>, <&srom_ebi>; >>>>> + >>>>> + ethernet@07000000 { >>>>> + compatible = "smsc,lan9115"; >>>>> + reg = <0x07000000 0x10000>; >>>>> + phy-mode = "mii"; >>>>> + interrupt-parent = <&gpx0>; >>>>> + interrupts = <5 8>; >>>>> + reg-io-width = <2>; >>>>> + smsc,irq-push-pull; >>>>> + smsc,force-internal-phy; >>>>> + >>>>> + samsung,srom-bank = <3>; >>>>> + samsung,srom-data-width = <2>; >>>>> + samsung,srom-timing = <1 9 12 1 9 1 1>; >>>> >>>> I think this is not correct. We can't change binding of "smsc,lan9115" >>>> which is already documented here [1]. These samsung specific srom >>>> properties should be in srom node or its subnode, but not in this way. >>> >>> So, if you look at gpmc-eth.txt, you'll see that this approach is perfectly valid (this is a reply to another msg, just don't want >>> to post one more single-line reply). >> >> >> Yes, the binding of smsc,lan9115 is not changed. >> >> Putting srom properties in separate bank node would be good also but >> then some mapping (connection) between ethernet and bank should be added >> probably... > > Is this to get some data needed by the ethernet from the ROM? We have > the nvmem binding to support that. No, this does not act like nvram driver. It is rather a memory controller. The same as existing TI GPMC: Documentation/devicetree/bindings/net/gpmc-eth.txt although configuration is different so gpmc driver cannot be reused. Best regards, Krzysztof
W dniu 30.10.2015 o 19:43, Pavel Fedin pisze: > Hello! > >> Please, carefully look at: >> Documentation/devicetree/bindings/net/gpmc-eth.txt >> Documentation/devicetree/bindings/bus/ti-gpmc.txt >> >> 1. Try to re-use existing bindings. Although I see existing bank-width >> and gpmc,device-width but yours samsung,srom-data-width seems better. >> Maybe there are other to re-use? > > I've done this and this is what i currently came up with. I'd like to discuss this before respin because nobody needs this > back-and-forth bouncing. > --- 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>; > > compatible = "samsung,exynos-srom"; > reg = <0x12250000 0x14>; Put compatible and reg at beginning. > }; > --- cut exynos5410.dtsi --- > --- cut exynos5410-smdk5410.dts --- > &sromc { > pinctrl-names = "default"; > pinctrl-0 = <&srom_ctl>, <&srom_ebi>; > > ethernet@3 { > compatible = "smsc,lan9115"; > reg = <3 0 0x10000>; > phy-mode = "mii"; > interrupt-parent = <&gpx0>; > interrupts = <5 8>; > reg-io-width = <2>; > smsc,irq-push-pull; > smsc,force-internal-phy; > > samsung,srom-config = <1 9 12 1 9 1 1>; > }; > }; > --- cut exynos5410-smdk5410.dts --- > > 1. After writing proper ranges i was able to get rid of dedicated bank number property, because now it is the first value in > device's "reg". Good, I like your approach. > 2. I noticed that smsc binding already uses reg-io-width property. I searched for it, and it appears to be reused by many devices. > So, i decided to use it to specify bank width, since it's already there. ti-gpmc uses bank-width because it supports configurations > like reg-io-width = 4 && bank-width = 2. I don't know if it's possible to do the same with SROMc, Exynos doc doesn't tell anything > about 32-bit accesses. But, if you want to support it too, i would suggest the following algorithm: > if (have bank-width) > width = bank-width > else if (have reg-io-width) > width = reg-io-width > else > width = 1 /* default */ Re-using reg-io-width seems fine. In future, if needed, this can be extended by introducing bank-width but now there is no sense in it. > 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. > However, it is still a nice idea do document them, but... > my PDF has "confidential" watermark on it, and this would mean that i essentially copy some information from it into Linux doc. Is > it okay to do this? 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. > If you still dislike the array, i'll redo is a set of properties like samsung,srom-tacs, samsung,srom-tcos, etc. > Ok, array for timings, but PMC IMHO is different. 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. It is really difficult to read your replies. Best regards, Krzysztof
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). 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)? > 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. :) > 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. :) Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
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
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>? Of course i did. I don't quote the rest because i simply agree to what you've said. Will respin with these changes. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
On 03.11.2015 15:58, 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>? > > Of course i did. I saw some other nodes use the ranges without the offset but maybe some more steps are required for such configuration. So anyway send the version with the child offset and I will try to figure out why it is required. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt index 33886d5..02ecc7f 100644 --- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt @@ -5,8 +5,54 @@ Required properties: - reg: offset and length of the register set -Example: +- #address-cells, #size-cells : should be '1' if the device has sub-nodes + with 'reg' property. +- ranges: allows valid 1:1 translation between child's address space and + parent's address space + +Sub-nodes: +The SROM controller can be used to attach external peripherials. In this case +device nodes should be added as subnodes to the SROMc node. These subnodes, +except regular device specification, should contain the following properties, +describing configuration of the relevant SROM bank: + +Required properties: +- samsung,srom-bank : bank number (0 - 3) + +- samsung,srom-timing : array of 7 integers: PMC, Tacp, Tcah, Tcoh, Tacc, Tcos, + Tacs + +Optional properties: +- samsung,srom-data-width : data width in bytes (1 or 2). If omitted, default + of 1 is used. + +Example: basic definition, no banks are configured sromc@12570000 { compatible = "samsung,exynos-srom"; - reg = <0x12570000 0x10>; + reg = <0x12570000 0x14>; + }; + +Example: SROMc with smsc 911x ethernet chip on bank 3 + sromc@12570000 { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + compatible = "samsung,exynos-srom"; + reg = <0x12570000 0x14>; + + ethernet@07000000 { + compatible = "smsc,lan9115"; + reg = <0x07000000 0x10000>; + phy-mode = "mii"; + interrupt-parent = <&gpx0>; + interrupts = <5 8>; + reg-io-width = <2>; + smsc,irq-push-pull; + smsc,force-internal-phy; + + samsung,srom-bank = <3>; + samsung,srom-data-width = <2>; + samsung,srom-timing = <1 9 12 1 9 1 1>; + }; };
Add documentation for new subnode properties, allowing bank configuration. Based on u-boot implementation, but heavily reworked. Signed-off-by: Pavel Fedin <p.fedin@samsung.com> --- .../bindings/arm/samsung/exynos-srom.txt | 50 +++++++++++++++++++++- 1 file changed, 48 insertions(+), 2 deletions(-)