From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] ARM: CSR: Adding CSR SiRFprimaII board support
Date: Wed, 6 Jul 2011 15:44:20 +0200 [thread overview]
Message-ID: <201107061544.20859.arnd@arndb.de> (raw)
In-Reply-To: <CAGsJ_4zzrsKZRR4KCaeFGL9iT5OfMdhKjJE1wG3CGh8M2U4-UQ@mail.gmail.com>
On Wednesday 06 July 2011, Barry Song wrote:
> > I would normally recommend defining the ranges so that addresses are local
> > to the respective bus, like
> >
> > axi {
> > ranges = <0 0x40000000 0x80000000>;
> >
> > sys-iobg {
> > ranges = <0 0x48000000 0x40000>;
> > clock-controller at 0x88000000 {
> > compatible = "sirf,prima2-clkc";
> > reg = <0 0x1000>;
> > }
> >
> > reset-controller at 0x88010000 {
> > compatible = "sirf,prima2-rstc";
> > reg = <0x10000 0x1000>;
> > };
> > }
> > }
>
> i am not sure whether it make us a little more difficult to know the
> real address at first glance.we will need to calculate.
> all addresses are 1:1 mapped in this chip. bus map can work even
> though we only give "ranges;" without real "ranges = <0x....>;".
So each iobg still passes down the entire 32-bit address?
Note that you never have to do the calculation in the driver
source, of_iomap and the resource logic both take care of this.
There are multiple ways to handle this, and an empty ranges property
usually works fine, but I find that less readable.
Another way to handle these is to have a separate range for
each child bus, as in arch/powerpc/boot/dts/gef_ppc9a.dts
To stay in the example, this would mean doing something like
axi {
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x80000000 0x08000000 // axi devices
1 0 0x88000000 0x08000000 // sys-iobg
2 0 0x90000000 0x00010000 // mem-iobg
3 0 0x90010000 0x07fe0000 // disp-iobg
... >;
l2-cache-controller at 80040000 {
compatible = "arm,pl310-cache";
reg = <0 0x40000 0x1000>;
interrupts = <59>;
};
sys-iobg {
#address-cells = <1>;
#size-cells = <1>;
ranges = <1 0 0 0x40000>;
clock-controller at 88000000 {
compatible = "sirf,prima2-clkc";
reg = <0 0x1000>;
}
reset-controller at 88010000 {
compatible = "sirf,prima2-rstc";
reg = <0x10000 0x1000>;
};
}
}
> >> +
> >> + graphics-iobg {
> >> + compatible = "simple-bus";
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + ranges = <0x98000000 0x98000000 0x8000000>;
> >> +
> >> + graphics at 0x98000000 {
> >> + compatible = "sirf,prima2-graphics";
> >> + reg = <0x98000000 0x8000000>;
> >> + interrupts = <6>;
> >> + };
> >> + };
> >
> > Are the display and graphics units CSR developments? If the GPU is
> > in fact licensed from someone else (powervr, arm, ...), you should
> > probably list the actual name of the device.
>
> GPU is powervr sgx 531, so could we define compatible as "powervr,sgx531"?
Probably yes. You should have a look if there are already bindings for
this that define other attributes. Also, if there is any customization
inside of the chip, you should have another more specific identifier
that makes it possible that this is the version that csr has modified.
> >> + multimedia-iobg {
> >> + compatible = "simple-bus";
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + ranges = <0xa0000000 0xa0000000 0x8000000>;
> >> +
> >> + multimedia at 0xa0000000 {
> >> + compatible = "sirf,prima2-multimedia";
> >> + reg = <0xa0000000 0x8000000>;
> >> + interrupts = <5>;
> >> + };
> >> + };
> >
> > "multimedia" sounds like a too generic term. What does this do?
>
> video decoding.
sirf,prima2-video-codec is probably better than, but if anyone has other
suggestions, you could use something else.
> > Are these proprietary uarts, or are they compatible to 8250 and the
> > like? You might want to set a clock-frequency property as of_serial.c
> > uses.
>
> it is not compatible with 8250 .
ok
> > Are these rtc implementations related? From the register layout, I would
> > guess that they are supposed to be used by the same driver, so it's
> > probably a good idea to add a "compatible" property with a common name
> > for all three.
>
> in fact, because they are slow, they can't be accessed by mapped
> address directly, the only common point they have is we need to access
> them through mapped address in rtc-iobg indirectly just like we access
> i2c/spi/nand devices.
>
> they are three different devices with different purpose and register
> layout in fact.
Ok.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Barry Song <21cnbao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
Barry Song <bs14-kQvG35nSl+M@public.gmane.org>,
Bin Shi <Bin.Shi-kQvG35nSl+M@public.gmane.org>,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
workgroup.linux-kQvG35nSl+M@public.gmane.org,
Zhiwu Song <Zhiwu.Song-kQvG35nSl+M@public.gmane.org>,
Rongjun Ying <Rongjun.Ying-kQvG35nSl+M@public.gmane.org>,
Binghua Duan <binghua.duan-kQvG35nSl+M@public.gmane.org>,
Barry Song <Baohua.Song-kQvG35nSl+M@public.gmane.org>,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
Yuping Luo <Yuping.Luo-kQvG35nSl+M@public.gmane.org>,
Huayi Li <Huayi.Li-kQvG35nSl+M@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 1/3] ARM: CSR: Adding CSR SiRFprimaII board support
Date: Wed, 6 Jul 2011 15:44:20 +0200 [thread overview]
Message-ID: <201107061544.20859.arnd@arndb.de> (raw)
In-Reply-To: <CAGsJ_4zzrsKZRR4KCaeFGL9iT5OfMdhKjJE1wG3CGh8M2U4-UQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wednesday 06 July 2011, Barry Song wrote:
> > I would normally recommend defining the ranges so that addresses are local
> > to the respective bus, like
> >
> > axi {
> > ranges = <0 0x40000000 0x80000000>;
> >
> > sys-iobg {
> > ranges = <0 0x48000000 0x40000>;
> > clock-controller@0x88000000 {
> > compatible = "sirf,prima2-clkc";
> > reg = <0 0x1000>;
> > }
> >
> > reset-controller@0x88010000 {
> > compatible = "sirf,prima2-rstc";
> > reg = <0x10000 0x1000>;
> > };
> > }
> > }
>
> i am not sure whether it make us a little more difficult to know the
> real address at first glance.we will need to calculate.
> all addresses are 1:1 mapped in this chip. bus map can work even
> though we only give "ranges;" without real "ranges = <0x....>;".
So each iobg still passes down the entire 32-bit address?
Note that you never have to do the calculation in the driver
source, of_iomap and the resource logic both take care of this.
There are multiple ways to handle this, and an empty ranges property
usually works fine, but I find that less readable.
Another way to handle these is to have a separate range for
each child bus, as in arch/powerpc/boot/dts/gef_ppc9a.dts
To stay in the example, this would mean doing something like
axi {
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x80000000 0x08000000 // axi devices
1 0 0x88000000 0x08000000 // sys-iobg
2 0 0x90000000 0x00010000 // mem-iobg
3 0 0x90010000 0x07fe0000 // disp-iobg
... >;
l2-cache-controller@80040000 {
compatible = "arm,pl310-cache";
reg = <0 0x40000 0x1000>;
interrupts = <59>;
};
sys-iobg {
#address-cells = <1>;
#size-cells = <1>;
ranges = <1 0 0 0x40000>;
clock-controller@88000000 {
compatible = "sirf,prima2-clkc";
reg = <0 0x1000>;
}
reset-controller@88010000 {
compatible = "sirf,prima2-rstc";
reg = <0x10000 0x1000>;
};
}
}
> >> +
> >> + graphics-iobg {
> >> + compatible = "simple-bus";
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + ranges = <0x98000000 0x98000000 0x8000000>;
> >> +
> >> + graphics@0x98000000 {
> >> + compatible = "sirf,prima2-graphics";
> >> + reg = <0x98000000 0x8000000>;
> >> + interrupts = <6>;
> >> + };
> >> + };
> >
> > Are the display and graphics units CSR developments? If the GPU is
> > in fact licensed from someone else (powervr, arm, ...), you should
> > probably list the actual name of the device.
>
> GPU is powervr sgx 531, so could we define compatible as "powervr,sgx531"?
Probably yes. You should have a look if there are already bindings for
this that define other attributes. Also, if there is any customization
inside of the chip, you should have another more specific identifier
that makes it possible that this is the version that csr has modified.
> >> + multimedia-iobg {
> >> + compatible = "simple-bus";
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + ranges = <0xa0000000 0xa0000000 0x8000000>;
> >> +
> >> + multimedia@0xa0000000 {
> >> + compatible = "sirf,prima2-multimedia";
> >> + reg = <0xa0000000 0x8000000>;
> >> + interrupts = <5>;
> >> + };
> >> + };
> >
> > "multimedia" sounds like a too generic term. What does this do?
>
> video decoding.
sirf,prima2-video-codec is probably better than, but if anyone has other
suggestions, you could use something else.
> > Are these proprietary uarts, or are they compatible to 8250 and the
> > like? You might want to set a clock-frequency property as of_serial.c
> > uses.
>
> it is not compatible with 8250 .
ok
> > Are these rtc implementations related? From the register layout, I would
> > guess that they are supposed to be used by the same driver, so it's
> > probably a good idea to add a "compatible" property with a common name
> > for all three.
>
> in fact, because they are slow, they can't be accessed by mapped
> address directly, the only common point they have is we need to access
> them through mapped address in rtc-iobg indirectly just like we access
> i2c/spi/nand devices.
>
> they are three different devices with different purpose and register
> layout in fact.
Ok.
Arnd
next prev parent reply other threads:[~2011-07-06 13:44 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-06 9:47 [PATCH 0/3] ARM: CSR: Adding CSR SiRFprimaII platform Barry Song
2011-07-06 9:47 ` [PATCH 1/3] ARM: CSR: Adding CSR SiRFprimaII board support Barry Song
2011-07-06 11:04 ` Russell King - ARM Linux
2011-07-06 15:16 ` Barry Song
2011-07-06 11:41 ` Arnd Bergmann
2011-07-06 11:41 ` Arnd Bergmann
2011-07-06 12:22 ` Barry Song
2011-07-06 12:22 ` Barry Song
2011-07-06 13:44 ` Arnd Bergmann [this message]
2011-07-06 13:44 ` Arnd Bergmann
2011-07-07 2:26 ` Barry Song
2011-07-07 2:26 ` Barry Song
2011-07-06 12:25 ` Russell King - ARM Linux
2011-07-06 12:42 ` Arnd Bergmann
2011-07-06 13:09 ` Russell King - ARM Linux
2011-07-06 14:41 ` Arnd Bergmann
2011-07-06 15:25 ` Russell King - ARM Linux
2011-07-06 16:13 ` Arnd Bergmann
2011-07-06 13:29 ` Russell King - ARM Linux
2011-07-06 14:51 ` Russell King - ARM Linux
2011-07-06 15:03 ` Arnd Bergmann
2011-07-06 16:35 ` Nicolas Pitre
2011-07-06 17:42 ` Russell King - ARM Linux
2011-07-06 17:59 ` Arnd Bergmann
2011-07-06 18:11 ` Nicolas Pitre
2011-07-06 18:15 ` Russell King - ARM Linux
2011-07-06 18:35 ` Nicolas Pitre
2011-07-06 18:09 ` Nicolas Pitre
2011-07-07 11:23 ` Arnd Bergmann
2011-07-06 16:09 ` Barry Song
2011-07-06 19:10 ` Russell King - ARM Linux
2011-07-06 20:31 ` Arnd Bergmann
2011-07-06 20:50 ` Russell King - ARM Linux
2011-07-06 21:21 ` Arnd Bergmann
2011-07-07 1:20 ` Barry Song
2011-07-07 11:43 ` Arnd Bergmann
2011-07-07 12:37 ` Russell King - ARM Linux
2011-07-07 13:21 ` Arnd Bergmann
2011-07-07 14:12 ` Russell King - ARM Linux
2011-07-08 2:18 ` Barry Song
2011-07-08 9:03 ` Russell King - ARM Linux
2011-07-08 13:38 ` Nicolas Pitre
2011-07-08 16:27 ` Russell King - ARM Linux
2011-07-08 18:09 ` Nicolas Pitre
2011-07-08 21:37 ` Arnd Bergmann
2011-07-21 0:03 ` dynamic VMALLOC_END, was " Nicolas Pitre
2011-07-06 9:47 ` [PATCH 2/3] ARM: CSR: mapping early DEBUG_LL uart Barry Song
2011-07-06 11:05 ` Russell King - ARM Linux
2011-07-06 11:53 ` Barry Song
2011-07-06 11:56 ` Barry Song
2011-07-06 12:10 ` Russell King - ARM Linux
2011-07-06 12:29 ` Barry Song
2011-07-06 11:15 ` Arnd Bergmann
2011-07-06 9:47 ` [PATCH 3/3] ARM: CSR: initilized L2 cache Barry Song
2011-07-06 11:14 ` Arnd Bergmann
[not found] <e66253df-b34a-4c32-bddf-31b1332c716c@VA3EHSMHS031.ehs.local>
2011-07-07 13:48 ` [PATCH 1/3] ARM: CSR: Adding CSR SiRFprimaII board support johnlinn at comcast.net
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201107061544.20859.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.