From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com> Date: 2018-06-26 13:29:34
Hi
to be more specific
On Tue, Jun 26, 2018 at 3:06 PM, Michael Nazzareno Trimarchi
[off-list ref] wrote:
Hi
On Tue., 26 Jun. 2018, 12:01 pm Hans de Goede, [off-list ref] wrote:
quoted
Hi,
On 25-06-18 15:29, Michael Nazzareno Trimarchi wrote:
quoted
Hi Hans
In order to let it even registered the simplefb I have added this
change. According on what I understand
from the code seems that this is the way to acquire memory with the
correct attribute
diff --git a/drivers/video/fbdev/simplefb.c
b/drivers/video/fbdev/simplefb.c
index a3c44ec..7e61ce3 100644
This looks like GPIOS to me why are you modeling this a supplies?
Anyways ...
quoted
display = <&lcdif>;
};
};
};
How do you ensure that regulators that are bind to gpios can be
maintain during boot?
Any regulators listed in the simplefb dt-node will be kept enabled
until remove_conflicting_framebuffers is called() from the native
display driver. To keep them enabled while loading the native
display driver, you should get and enable them in the native display
driver *before* calling remove_conflicting_framebuffers()
(and the same goes for the clocks).
I will check it
Thank you
Michael
quoted
Regards,
Hans
quoted
A small minor comment is how to automatic switch then to normal
framebuffer. Anyway seems
that
#address-cells = <1>;
#size-cells = <1>;
ranges;
are mandatory and they are in the dts documentation.
Best regards
Michael
From: Hans de Goede <hidden> Date: 2018-06-26 13:36:35
Hi,
On 26-06-18 15:29, Michael Nazzareno Trimarchi wrote:
Hi
to be more specific
On Tue, Jun 26, 2018 at 3:06 PM, Michael Nazzareno Trimarchi
[off-list ref] wrote:
quoted
Hi
On Tue., 26 Jun. 2018, 12:01 pm Hans de Goede, [off-list ref] wrote:
quoted
Hi,
On 25-06-18 15:29, Michael Nazzareno Trimarchi wrote:
quoted
Hi Hans
In order to let it even registered the simplefb I have added this
change. According on what I understand
from the code seems that this is the way to acquire memory with the
correct attribute
diff --git a/drivers/video/fbdev/simplefb.c
b/drivers/video/fbdev/simplefb.c
index a3c44ec..7e61ce3 100644
I'm not sure why you need this? wb certainly is not optimal
for a framebuffer, the existing wc mapping is really what you
want.
Well in this way raise a WARN and get a nice NULL on memory remap on imx6ull
SoC
[ 0.397484] WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:303
__arm_ioremap_pfn_caller+0x80/0x1cc
This is causes by a mismatch in memory attributes, which means the
memory is already mapped by the kernel as regular RAM and may
already be used for other purposes by the kernel!
Memory used by a simplefb framebuffer must be reserved by the
bootloader, so that it does not get used by the kernel as regular
RAM. See e.g.:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/video/sunxi/sunxi_display.c
Near the end of the file where the framebuffer RAM gets excluded from
the memory-range reported to the kernel as usable RAM. Note this relies
on the u-boot sunxi video code putting the framebuffer at the end of the
RAM.
Regards,
Hans
From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com> Date: 2018-06-26 13:38:56
Hi
On Tue, Jun 26, 2018 at 3:36 PM, Hans de Goede [off-list ref] wrote:
Hi,
On 26-06-18 15:29, Michael Nazzareno Trimarchi wrote:
quoted
Hi
to be more specific
On Tue, Jun 26, 2018 at 3:06 PM, Michael Nazzareno Trimarchi
[off-list ref] wrote:
quoted
Hi
On Tue., 26 Jun. 2018, 12:01 pm Hans de Goede, [off-list ref]
wrote:
quoted
Hi,
On 25-06-18 15:29, Michael Nazzareno Trimarchi wrote:
quoted
Hi Hans
In order to let it even registered the simplefb I have added this
change. According on what I understand
from the code seems that this is the way to acquire memory with the
correct attribute
diff --git a/drivers/video/fbdev/simplefb.c
b/drivers/video/fbdev/simplefb.c
index a3c44ec..7e61ce3 100644
I'm not sure why you need this? wb certainly is not optimal
for a framebuffer, the existing wc mapping is really what you
want.
Well in this way raise a WARN and get a nice NULL on memory remap on
imx6ull
SoC
[ 0.397484] WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:303
__arm_ioremap_pfn_caller+0x80/0x1cc
This is causes by a mismatch in memory attributes, which means the
memory is already mapped by the kernel as regular RAM and may
already be used for other purposes by the kernel!
Memory used by a simplefb framebuffer must be reserved by the
bootloader, so that it does not get used by the kernel as regular
RAM. See e.g.:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/video/sunxi/sunxi_display.c
Near the end of the file where the framebuffer RAM gets excluded from
the memory-range reported to the kernel as usable RAM. Note this relies
on the u-boot sunxi video code putting the framebuffer at the end of the
RAM.
Thank you very much for this lesson ;). I will try to document better
after my tour ;)
Michael
From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com> Date: 2018-06-26 14:42:33
Hi Hans
On Tue, Jun 26, 2018 at 3:38 PM, Michael Nazzareno Trimarchi
[off-list ref] wrote:
Hi
On Tue, Jun 26, 2018 at 3:36 PM, Hans de Goede [off-list ref] wrote:
quoted
Hi,
On 26-06-18 15:29, Michael Nazzareno Trimarchi wrote:
quoted
Hi
to be more specific
On Tue, Jun 26, 2018 at 3:06 PM, Michael Nazzareno Trimarchi
[off-list ref] wrote:
quoted
Hi
On Tue., 26 Jun. 2018, 12:01 pm Hans de Goede, [off-list ref]
wrote:
quoted
Hi,
On 25-06-18 15:29, Michael Nazzareno Trimarchi wrote:
quoted
Hi Hans
In order to let it even registered the simplefb I have added this
change. According on what I understand
from the code seems that this is the way to acquire memory with the
correct attribute
diff --git a/drivers/video/fbdev/simplefb.c
b/drivers/video/fbdev/simplefb.c
index a3c44ec..7e61ce3 100644
I'm not sure why you need this? wb certainly is not optimal
for a framebuffer, the existing wc mapping is really what you
want.
Well in this way raise a WARN and get a nice NULL on memory remap on
imx6ull
SoC
[ 0.397484] WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:303
__arm_ioremap_pfn_caller+0x80/0x1cc
This is causes by a mismatch in memory attributes, which means the
memory is already mapped by the kernel as regular RAM and may
already be used for other purposes by the kernel!
Memory used by a simplefb framebuffer must be reserved by the
bootloader, so that it does not get used by the kernel as regular
RAM. See e.g.:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/video/sunxi/sunxi_display.c
Near the end of the file where the framebuffer RAM gets excluded from
the memory-range reported to the kernel as usable RAM. Note this relies
on the u-boot sunxi video code putting the framebuffer at the end of the
RAM.
+ aliases {
+ display0 = &lcdif;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display_reserved: framebuffer@86fd6080 {
+ reg = <0x86fd6080 (480 * 272 *4)>;
+ };
+
This should do the trick but I have still the same problem on memory
type. Any idea?
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0x1000000>;
+ linux,cma-default;
+ };
+ };
+
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ stdout-path = &uart1;
+ framebuffer0: framebuffer@86fd6080 {
+ compatible = "simple-framebuffer";
+ reg = <0x86fd6080 (480 * 272 * 4)>;
Here I try to use the same. I will create in uboot a dynamic way to
track down. I think that
we can even add to the simple buffer a way to get hand of reserved
region automatically
Michael
+ width = <480>;
+ height = <272>;
+ stride = <(480 * 4)>;
+ format = "a8r8g8b8";
+ clocks = <&clks IMX6UL_CLK_LCDIF_PIX>,
+ <&clks IMX6UL_CLK_LCDIF_APB>,
+ <&clks IMX6UL_CLK_DUMMY>,
+ <&clks IMX6UL_CLK_GPIO3>,
+ <&clks IMX6UL_CLK_GPIO4>;
+ nshut-supply = <®_lcd_nshut>;
+ nreset-supply = <®_lcd_nreset>;
+ display = <&lcdif>;
+ status = "okay";
+ };
quoted
Thank you very much for this lesson ;). I will try to document better
after my tour ;)
Michael
From: Hans de Goede <hidden> Date: 2018-06-26 14:47:16
Hi,
On 26-06-18 16:42, Michael Nazzareno Trimarchi wrote:
Hi Hans
On Tue, Jun 26, 2018 at 3:38 PM, Michael Nazzareno Trimarchi
[off-list ref] wrote:
quoted
Hi
On Tue, Jun 26, 2018 at 3:36 PM, Hans de Goede [off-list ref] wrote:
quoted
Hi,
On 26-06-18 15:29, Michael Nazzareno Trimarchi wrote:
quoted
Hi
to be more specific
On Tue, Jun 26, 2018 at 3:06 PM, Michael Nazzareno Trimarchi
[off-list ref] wrote:
quoted
Hi
On Tue., 26 Jun. 2018, 12:01 pm Hans de Goede, [off-list ref]
wrote:
quoted
Hi,
On 25-06-18 15:29, Michael Nazzareno Trimarchi wrote:
quoted
Hi Hans
In order to let it even registered the simplefb I have added this
change. According on what I understand
from the code seems that this is the way to acquire memory with the
correct attribute
diff --git a/drivers/video/fbdev/simplefb.c
b/drivers/video/fbdev/simplefb.c
index a3c44ec..7e61ce3 100644
I'm not sure why you need this? wb certainly is not optimal
for a framebuffer, the existing wc mapping is really what you
want.
Well in this way raise a WARN and get a nice NULL on memory remap on
imx6ull
SoC
[ 0.397484] WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:303
__arm_ioremap_pfn_caller+0x80/0x1cc
This is causes by a mismatch in memory attributes, which means the
memory is already mapped by the kernel as regular RAM and may
already be used for other purposes by the kernel!
Memory used by a simplefb framebuffer must be reserved by the
bootloader, so that it does not get used by the kernel as regular
RAM. See e.g.:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/video/sunxi/sunxi_display.c
Near the end of the file where the framebuffer RAM gets excluded from
the memory-range reported to the kernel as usable RAM. Note this relies
on the u-boot sunxi video code putting the framebuffer at the end of the
RAM.
+ aliases {
+ display0 = &lcdif;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display_reserved: framebuffer@86fd6080 {
+ reg = <0x86fd6080 (480 * 272 *4)>;
+ };
+
This should do the trick but I have still the same problem on memory
type. Any idea?
For starters your start address and size are not page-size
(multiple of 4k aligned), you need to fix that.
After that double check in the memory map reported by the
kernel during boot that your reservation actually works.
Regards,
Hans
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0x1000000>;
+ linux,cma-default;
+ };
+ };
+
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ stdout-path = &uart1;
+ framebuffer0: framebuffer@86fd6080 {
+ compatible = "simple-framebuffer";
+ reg = <0x86fd6080 (480 * 272 * 4)>;
Here I try to use the same. I will create in uboot a dynamic way to
track down. I think that
we can even add to the simple buffer a way to get hand of reserved
region automatically
Michael
+ width = <480>;
+ height = <272>;
+ stride = <(480 * 4)>;
+ format = "a8r8g8b8";
+ clocks = <&clks IMX6UL_CLK_LCDIF_PIX>,
+ <&clks IMX6UL_CLK_LCDIF_APB>,
+ <&clks IMX6UL_CLK_DUMMY>,
+ <&clks IMX6UL_CLK_GPIO3>,
+ <&clks IMX6UL_CLK_GPIO4>;
+ nshut-supply = <®_lcd_nshut>;
+ nreset-supply = <®_lcd_nreset>;
+ display = <&lcdif>;
+ status = "okay";
+ };
quoted
quoted
Thank you very much for this lesson ;). I will try to document better
after my tour ;)
Michael
From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com> Date: 2018-06-26 16:35:16
Hi Hans
On Tue, Jun 26, 2018 at 4:47 PM, Hans de Goede [off-list ref] wrote:
Hi,
On 26-06-18 16:42, Michael Nazzareno Trimarchi wrote:
quoted
Hi Hans
On Tue, Jun 26, 2018 at 3:38 PM, Michael Nazzareno Trimarchi
[off-list ref] wrote:
quoted
Hi
On Tue, Jun 26, 2018 at 3:36 PM, Hans de Goede [off-list ref]
wrote:
quoted
Hi,
On 26-06-18 15:29, Michael Nazzareno Trimarchi wrote:
quoted
Hi
to be more specific
On Tue, Jun 26, 2018 at 3:06 PM, Michael Nazzareno Trimarchi
[off-list ref] wrote:
quoted
Hi
On Tue., 26 Jun. 2018, 12:01 pm Hans de Goede, [off-list ref]
wrote:
quoted
Hi,
On 25-06-18 15:29, Michael Nazzareno Trimarchi wrote:
quoted
Hi Hans
In order to let it even registered the simplefb I have added this
change. According on what I understand
from the code seems that this is the way to acquire memory with the
correct attribute
diff --git a/drivers/video/fbdev/simplefb.c
b/drivers/video/fbdev/simplefb.c
index a3c44ec..7e61ce3 100644
I'm not sure why you need this? wb certainly is not optimal
for a framebuffer, the existing wc mapping is really what you
want.
Well in this way raise a WARN and get a nice NULL on memory remap on
imx6ull
SoC
[ 0.397484] WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:303
__arm_ioremap_pfn_caller+0x80/0x1cc
This is causes by a mismatch in memory attributes, which means the
memory is already mapped by the kernel as regular RAM and may
already be used for other purposes by the kernel!
Memory used by a simplefb framebuffer must be reserved by the
bootloader, so that it does not get used by the kernel as regular
RAM. See e.g.:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/video/sunxi/sunxi_display.c
Near the end of the file where the framebuffer RAM gets excluded from
the memory-range reported to the kernel as usable RAM. Note this relies
on the u-boot sunxi video code putting the framebuffer at the end of the
RAM.
+ aliases {
+ display0 = &lcdif;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display_reserved: framebuffer@86fd6080 {
+ reg = <0x86fd6080 (480 * 272 *4)>;
+ };
+
This should do the trick but I have still the same problem on memory
type. Any idea?
For starters your start address and size are not page-size
(multiple of 4k aligned), you need to fix that.
From: Hans de Goede <hidden> Date: 2018-06-26 18:45:05
Hi,
On 26-06-18 18:35, Michael Nazzareno Trimarchi wrote:
Hi Hans
On Tue, Jun 26, 2018 at 4:47 PM, Hans de Goede [off-list ref] wrote:
quoted
Hi,
On 26-06-18 16:42, Michael Nazzareno Trimarchi wrote:
quoted
Hi Hans
On Tue, Jun 26, 2018 at 3:38 PM, Michael Nazzareno Trimarchi
[off-list ref] wrote:
quoted
Hi
On Tue, Jun 26, 2018 at 3:36 PM, Hans de Goede [off-list ref]
wrote:
quoted
Hi,
On 26-06-18 15:29, Michael Nazzareno Trimarchi wrote:
quoted
Hi
to be more specific
On Tue, Jun 26, 2018 at 3:06 PM, Michael Nazzareno Trimarchi
[off-list ref] wrote:
quoted
Hi
On Tue., 26 Jun. 2018, 12:01 pm Hans de Goede, [off-list ref]
wrote:
quoted
Hi,
On 25-06-18 15:29, Michael Nazzareno Trimarchi wrote:
quoted
Hi Hans
In order to let it even registered the simplefb I have added this
change. According on what I understand
from the code seems that this is the way to acquire memory with the
correct attribute
diff --git a/drivers/video/fbdev/simplefb.c
b/drivers/video/fbdev/simplefb.c
index a3c44ec..7e61ce3 100644
I'm not sure why you need this? wb certainly is not optimal
for a framebuffer, the existing wc mapping is really what you
want.
Well in this way raise a WARN and get a nice NULL on memory remap on
imx6ull
SoC
[ 0.397484] WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:303
__arm_ioremap_pfn_caller+0x80/0x1cc
This is causes by a mismatch in memory attributes, which means the
memory is already mapped by the kernel as regular RAM and may
already be used for other purposes by the kernel!
Memory used by a simplefb framebuffer must be reserved by the
bootloader, so that it does not get used by the kernel as regular
RAM. See e.g.:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/video/sunxi/sunxi_display.c
Near the end of the file where the framebuffer RAM gets excluded from
the memory-range reported to the kernel as usable RAM. Note this relies
on the u-boot sunxi video code putting the framebuffer at the end of the
RAM.
+ aliases {
+ display0 = &lcdif;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display_reserved: framebuffer@86fd6080 {
+ reg = <0x86fd6080 (480 * 272 *4)>;
+ };
+
This should do the trick but I have still the same problem on memory
type. Any idea?
For starters your start address and size are not page-size
(multiple of 4k aligned), you need to fix that.
Hmm, I guess the kernel does map the entire region its get
passed and simply makes sure to not touch the reserved mem,
where as with the changes to the passed in mem-region the
sunxi u-boot code does the memory does not get mapped by
the kernel at all ?
I think at this point this may have more become more of a
question for the ARM folks then for the fbdev list.
Regards,
Hans
Michael
quoted
After that double check in the memory map reported by the
kernel during boot that your reservation actually works.
Regards,
Hans
quoted
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0x1000000>;
+ linux,cma-default;
+ };
+ };
+
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ stdout-path = &uart1;
+ framebuffer0: framebuffer@86fd6080 {
+ compatible = "simple-framebuffer";
+ reg = <0x86fd6080 (480 * 272 * 4)>;
Here I try to use the same. I will create in uboot a dynamic way to
track down. I think that
we can even add to the simple buffer a way to get hand of reserved
region automatically
Michael
+ width = <480>;
+ height = <272>;
+ stride = <(480 * 4)>;
+ format = "a8r8g8b8";
+ clocks = <&clks IMX6UL_CLK_LCDIF_PIX>,
+ <&clks IMX6UL_CLK_LCDIF_APB>,
+ <&clks IMX6UL_CLK_DUMMY>,
+ <&clks IMX6UL_CLK_GPIO3>,
+ <&clks IMX6UL_CLK_GPIO4>;
+ nshut-supply = <®_lcd_nshut>;
+ nreset-supply = <®_lcd_nreset>;
+ display = <&lcdif>;
+ status = "okay";
+ };
quoted
quoted
Thank you very much for this lesson ;). I will try to document better
after my tour ;)
Michael
Hmm, I guess the kernel does map the entire region its get
passed and simply makes sure to not touch the reserved mem,
where as with the changes to the passed in mem-region the
sunxi u-boot code does the memory does not get mapped by
the kernel at all ?
If the intent is to reserve memory _and_ prevent it from being included
in the kernel's linear map, then it is also necessary to include the
'no-map' property for this reserved-mem node.
From Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt:
no-map (optional) - empty property
- Indicates the operating system must not create a virtual mapping
of the region as part of its standard mapping of system memory,
nor permit speculative access to it under any circumstances other
than under the control of the device driver using the region.
Julia