lkml.org 
[lkml]   [2016]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    SubjectRe: [PATCH] ARM: omapfb: Add early framebuffer memory allocator
    From
    Date
    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

    \
     
     \ /
      Last update: 2016-02-17 08:41    [W:3.280 / U:0.292 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site