Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 16.02.2016 15:51, Tomi Valkeinen wrote:

Does it work for you? I haven't used DT reserved-memory, do you have an
example .dts change?


Yes, it does work, I tested it on n900:

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 1e94237..863d547 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -59,6 +59,18 @@
                reg = <0x80000000 0x10000000>; /* 256 MB */
        };

+       reserved-memory {
+               #address-cells = <1>;
+               #size-cells = <1>;
+               ranges;
+
+               omapfb_reserved: omapfb {
+                       size = <0x700000>;
+                       alignment = <0x100000>;
+                       compatible = "ti,omapfb-memsize";
+               };
+       };
+
        gpio_keys {
                compatible = "gpio-keys";

@@ -1083,6 +1095,8 @@

        vdds_sdi-supply = <&vaux1>;

+       memory-region = <&omapfb_reserved>;
+
        ports {
                #address-cells = <1>;
                #size-cells = <0>;

Now, having to support DT bindings is not any better than supporting
cmdline options. But with a quick read of reserved-memory.txt I like the
idea. However we should have "reserved memory for display", not for
omapfb, so that the same reserved area could be used by omapdrm too.

Sounds reasonable and I don't really care how it is to be called or who does the actual reservation, as long as there is some reserved memory we can use for omapfb :)

Keep in mind that the changes I did were just a quick-n-dirty hack to see if it will work and if you will accept something like that. A better approach is maybe to move RESERVEDMEM_OF_DECLARE() and co to display.c and pass base and size to whoever needs them (be it omapfb or omapdrm). Also, compatible could be called "ti,dss-memsize" or the like, but those are cosmetics IMO.


Another thing, with v4.5, omapfb has moved into maintenance mode. I
don't want to merge new features there. Are you planning to move to
omapdrm, and if not, why? I'd rather see all this done for omapdrm only.

I don't see a reason to not merge a small change like that in omapfb if there is reserved display memory used by omapdrm, but still, I am not the maintainer.

Pali already explained the situation with PVR driver we use to boot maemo UI. Honestly, I have no idea what it takes to move from omapfb to omapdrm. Any hints?

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux