| Message ID | 15143985.aGzb1oeyb9@diego (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Heiko On Sat, Aug 1, 2015 at 5:35 AM, Heiko Stübner <heiko@sntech.de> wrote: > The rk3288 has problems accessing the memory region 0xfe000000~0xff000000. > So block off the affected region to prevent its use. > > Tested on 4GB Veyron Minnie and 2GB Veyron Jerry devices. > > Signed-off-by: Heiko Stuebner <heiko@sntech.de> > --- > arch/arm/boot/dts/rk3288.dtsi | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi > index 2db91c9..19766af 100644 > --- a/arch/arm/boot/dts/rk3288.dtsi > +++ b/arch/arm/boot/dts/rk3288.dtsi > @@ -169,6 +169,16 @@ > }; > }; > > + reserved-memory { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + unusable@fe000000 { > + reg = <0xfe000000 0x1000000>; > + }; > + }; > + I don't object to just reserving this memory, but I do object a little to this implementation. It's 16 MB we're talking about here, which is pretty small compared to the 4G of memory that you must have when this is a problem. However, at some point we might want to try to actually use this 16 MB. The memory is actually _not_ unusable, it's only unusable for DMA. In theory the kernel is supposed to have a way to mark memory as unusable for DMA which would then allow us to use this memory for non-DMA purposes... Nobody ever managed to figure this out in the Chrome OS tree (it was 16 megs so we just reserved it and never got back around to it), but when folks were looking at it they looked at things like ZONE_DMA, dma_set_mask_and_coherent, etc. In any case, to leave the door open for people to fix this in the future, it seems prudent to fix this in code like <https://chromium-review.googlesource.com/#/c/245107/> rather than to put the limit in DTS. -Doug
Hi Doug, Am Samstag, 1. August 2015, 14:32:32 schrieb Doug Anderson: > On Sat, Aug 1, 2015 at 5:35 AM, Heiko Stübner <heiko@sntech.de> wrote: > > The rk3288 has problems accessing the memory region 0xfe000000~0xff000000. > > So block off the affected region to prevent its use. > > > > Tested on 4GB Veyron Minnie and 2GB Veyron Jerry devices. > > > > Signed-off-by: Heiko Stuebner <heiko@sntech.de> > > --- > > > > arch/arm/boot/dts/rk3288.dtsi | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi > > index 2db91c9..19766af 100644 > > --- a/arch/arm/boot/dts/rk3288.dtsi > > +++ b/arch/arm/boot/dts/rk3288.dtsi > > @@ -169,6 +169,16 @@ > > > > }; > > > > }; > > > > + reserved-memory { > > + #address-cells = <1>; > > + #size-cells = <1>; > > + ranges; > > + > > + unusable@fe000000 { > > + reg = <0xfe000000 0x1000000>; > > + }; > > + }; > > + > > I don't object to just reserving this memory, but I do object a little > to this implementation. > > It's 16 MB we're talking about here, which is pretty small compared to > the 4G of memory that you must have when this is a problem. However, > at some point we might want to try to actually use this 16 MB. > > The memory is actually _not_ unusable, it's only unusable for DMA. In > theory the kernel is supposed to have a way to mark memory as unusable > for DMA which would then allow us to use this memory for non-DMA > purposes... Ok, the patch message in the chromeos-patch didn't mention dma, but I could've thought of that myself, sorry. > Nobody ever managed to figure this out in the Chrome OS tree (it was > 16 megs so we just reserved it and never got back around to it), but > when folks were looking at it they looked at things like ZONE_DMA, > dma_set_mask_and_coherent, etc. > > In any case, to leave the door open for people to fix this in the > future, it seems prudent to fix this in code like > <https://chromium-review.googlesource.com/#/c/245107/> rather than to > put the limit in DTS. The dt code when creating the platform-devices assumes a 32bit dma mask and expects the drivers to set the correct dma_masks (in of_dma_configure). But from the original description this looks more like a limitation of the rk3288, not the individual dwmmc, dwc2, etc. So from my cursory glance, ZONE_DMA seems to be the best solution. As you said that this was investigated too, do you know if they encountered any obstacles that resulted in not adjusting the dma zone? @Jeffy: do you know how widespread this is? I.e. are socs like the rk3128 or possibly more importantly the rk3368 also affected by this in 4GB configurations? If the rk3368 does it too, this might get "interesting". In one of the mails about ZONE_DMA from september 2014, Arnd mentioned that there was a patch about getting the zone size from devicetree floating around, but it doesn't look like this landed. Heiko
Am Sonntag, 2. August 2015, 00:52:44 schrieb Heiko Stübner: > Hi Doug, > > Am Samstag, 1. August 2015, 14:32:32 schrieb Doug Anderson: > > On Sat, Aug 1, 2015 at 5:35 AM, Heiko Stübner <heiko@sntech.de> wrote: > > > The rk3288 has problems accessing the memory region > > > 0xfe000000~0xff000000. > > > So block off the affected region to prevent its use. > > > > > > Tested on 4GB Veyron Minnie and 2GB Veyron Jerry devices. > > > > > > Signed-off-by: Heiko Stuebner <heiko@sntech.de> > > > --- > > > > > > arch/arm/boot/dts/rk3288.dtsi | 10 ++++++++++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/arch/arm/boot/dts/rk3288.dtsi > > > b/arch/arm/boot/dts/rk3288.dtsi > > > index 2db91c9..19766af 100644 > > > --- a/arch/arm/boot/dts/rk3288.dtsi > > > +++ b/arch/arm/boot/dts/rk3288.dtsi > > > @@ -169,6 +169,16 @@ > > > > > > }; > > > > > > }; > > > > > > + reserved-memory { > > > + #address-cells = <1>; > > > + #size-cells = <1>; > > > + ranges; > > > + > > > + unusable@fe000000 { > > > + reg = <0xfe000000 0x1000000>; > > > + }; > > > + }; > > > + > > > > I don't object to just reserving this memory, but I do object a little > > to this implementation. > > > > It's 16 MB we're talking about here, which is pretty small compared to > > the 4G of memory that you must have when this is a problem. However, > > at some point we might want to try to actually use this 16 MB. > > > > The memory is actually _not_ unusable, it's only unusable for DMA. In > > theory the kernel is supposed to have a way to mark memory as unusable > > for DMA which would then allow us to use this memory for non-DMA > > purposes... > > Ok, the patch message in the chromeos-patch didn't mention dma, but I > could've thought of that myself, sorry. > > > Nobody ever managed to figure this out in the Chrome OS tree (it was > > 16 megs so we just reserved it and never got back around to it), but > > when folks were looking at it they looked at things like ZONE_DMA, > > dma_set_mask_and_coherent, etc. > > > > In any case, to leave the door open for people to fix this in the > > future, it seems prudent to fix this in code like > > <https://chromium-review.googlesource.com/#/c/245107/> rather than to > > put the limit in DTS. > > The dt code when creating the platform-devices assumes a 32bit dma mask and > expects the drivers to set the correct dma_masks (in of_dma_configure). But > from the original description this looks more like a limitation of the > rk3288, not the individual dwmmc, dwc2, etc. > > So from my cursory glance, ZONE_DMA seems to be the best solution. As you > said that this was investigated too, do you know if they encountered any > obstacles that resulted in not adjusting the dma zone? > > > @Jeffy: do you know how widespread this is? I.e. are socs like the rk3128 or > possibly more importantly the rk3368 also affected by this in 4GB > configurations? > > > If the rk3368 does it too, this might get "interesting". In one of the mails > about ZONE_DMA from september 2014, Arnd mentioned that there was a patch > about getting the zone size from devicetree floating around, but it doesn't > look like this landed. actually the "dma-ranges" property also looks promising (through of_dma_get_range() called fromof_dma_configure() )
Am Samstag, 1. August 2015, 14:32:32 schrieb Doug Anderson: > Heiko > > On Sat, Aug 1, 2015 at 5:35 AM, Heiko Stübner <heiko@sntech.de> wrote: > > The rk3288 has problems accessing the memory region 0xfe000000~0xff000000. > > So block off the affected region to prevent its use. > > > > Tested on 4GB Veyron Minnie and 2GB Veyron Jerry devices. > > > > Signed-off-by: Heiko Stuebner <heiko@sntech.de> > > --- > > > > arch/arm/boot/dts/rk3288.dtsi | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi > > index 2db91c9..19766af 100644 > > --- a/arch/arm/boot/dts/rk3288.dtsi > > +++ b/arch/arm/boot/dts/rk3288.dtsi > > @@ -169,6 +169,16 @@ > > > > }; > > > > }; > > > > + reserved-memory { > > + #address-cells = <1>; > > + #size-cells = <1>; > > + ranges; > > + > > + unusable@fe000000 { > > + reg = <0xfe000000 0x1000000>; > > + }; > > + }; > > + > > I don't object to just reserving this memory, but I do object a little > to this implementation. > > It's 16 MB we're talking about here, which is pretty small compared to > the 4G of memory that you must have when this is a problem. However, > at some point we might want to try to actually use this 16 MB. > > The memory is actually _not_ unusable, it's only unusable for DMA. In > theory the kernel is supposed to have a way to mark memory as unusable > for DMA which would then allow us to use this memory for non-DMA > purposes... > > Nobody ever managed to figure this out in the Chrome OS tree (it was > 16 megs so we just reserved it and never got back around to it), but > when folks were looking at it they looked at things like ZONE_DMA, > dma_set_mask_and_coherent, etc. > > In any case, to leave the door open for people to fix this in the > future, it seems prudent to fix this in code like > <https://chromium-review.googlesource.com/#/c/245107/> rather than to > put the limit in DTS. hmm, a counter argument in favor of even having the stopgap section disabling the memory in the dts might be, that as Jeffy said all current Rockchip socs are affected, even the rk3368. So a future real solution would be declaring the usable dma area in devicetree anyway and not in kernel code. So in my mind devices can disable the memory for now in dt and later (once something usable is defined) can switch the soc- level devicetree to this one, describing the actually usable dma area. Old devicetrees would keep working anyway and could switch at their convenience. So I don't see a real transistion problem here (aka no API breakage or so)? Heiko
Hi, On Sat, Aug 1, 2015 at 3:52 PM, Heiko Stübner <heiko@sntech.de> wrote: > The dt code when creating the platform-devices assumes a 32bit dma mask and > expects the drivers to set the correct dma_masks (in of_dma_configure). But > from the original description this looks more like a limitation of the rk3288, > not the individual dwmmc, dwc2, etc. > > So from my cursory glance, ZONE_DMA seems to be the best solution. As you said > that this was investigated too, do you know if they encountered any obstacles > that resulted in not adjusting the dma zone? > > > @Jeffy: do you know how widespread this is? I.e. are socs like the rk3128 or > possibly more importantly the rk3368 also affected by this in 4GB > configurations? > > > If the rk3368 does it too, this might get "interesting". In one of the mails > about ZONE_DMA from september 2014, Arnd mentioned that there was a patch > about getting the zone size from devicetree floating around, but it doesn't > look like this landed. I don't actually know all the details of the problems since others investigated. I was just trying to quickly summarize what I could find in the internal bug for the benefit of the list... Sorry if that's not terribly helpful. :( -Doug
Hi, On Mon, Aug 3, 2015 at 3:38 PM, Heiko Stübner <heiko@sntech.de> wrote: >> I don't object to just reserving this memory, but I do object a little >> to this implementation. >> >> It's 16 MB we're talking about here, which is pretty small compared to >> the 4G of memory that you must have when this is a problem. However, >> at some point we might want to try to actually use this 16 MB. >> >> The memory is actually _not_ unusable, it's only unusable for DMA. In >> theory the kernel is supposed to have a way to mark memory as unusable >> for DMA which would then allow us to use this memory for non-DMA >> purposes... >> >> Nobody ever managed to figure this out in the Chrome OS tree (it was >> 16 megs so we just reserved it and never got back around to it), but >> when folks were looking at it they looked at things like ZONE_DMA, >> dma_set_mask_and_coherent, etc. >> >> In any case, to leave the door open for people to fix this in the >> future, it seems prudent to fix this in code like >> <https://chromium-review.googlesource.com/#/c/245107/> rather than to >> put the limit in DTS. > > hmm, a counter argument in favor of even having the stopgap section disabling > the memory in the dts might be, that as Jeffy said all current Rockchip socs > are affected, even the rk3368. > > So a future real solution would be declaring the usable dma area in devicetree > anyway and not in kernel code. So in my mind devices can disable the memory > for now in dt and later (once something usable is defined) can switch the soc- > level devicetree to this one, describing the actually usable dma area. > > Old devicetrees would keep working anyway and could switch at their > convenience. So I don't see a real transistion problem here (aka no API > breakage or so)? OK, interesting point. OK, we can do this in device tree, but we should probably at least have a comment saying that it's only a problem for DMA? ...or at least something in the commit message? -Doug
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi index 2db91c9..19766af 100644 --- a/arch/arm/boot/dts/rk3288.dtsi +++ b/arch/arm/boot/dts/rk3288.dtsi @@ -169,6 +169,16 @@ }; }; + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + unusable@fe000000 { + reg = <0xfe000000 0x1000000>; + }; + }; + xin24m: oscillator { compatible = "fixed-clock"; clock-frequency = <24000000>;
The rk3288 has problems accessing the memory region 0xfe000000~0xff000000. So block off the affected region to prevent its use. Tested on 4GB Veyron Minnie and 2GB Veyron Jerry devices. Signed-off-by: Heiko Stuebner <heiko@sntech.de> --- arch/arm/boot/dts/rk3288.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)