From: "Ville Syrjälä" <ville.syrjala@nokia.com>
To: "Valkeinen Tomi (Nokia-D/Helsinki)" <Tomi.Valkeinen@nokia.com>
Cc: "linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v2] DSS2: OMAPFB: Add support for switching memory
Date: Thu, 04 Mar 2010 14:01:59 +0000 [thread overview]
Message-ID: <20100304140159.GC18243@nokia.com> (raw)
In-Reply-To: <1267555019-18176-1-git-send-email-ville.syrjala@nokia.com>
On Tue, Mar 02, 2010 at 07:36:59PM +0100, Syrjala Ville (Nokia-D/Helsinki) wrote:
> From: Ville Syrjälä <ville.syrjala@nokia.com>
>
> Separate the memory region from the framebuffer device a little bit.
> It's now possible to select the memory region used by the framebuffer
> device using the new source_idx parameter of omapfb_plane_info. If the
> source_idx is specified it will be interpreted as an index into the
> memory regions array, if it's not specified the framebuffer's index is
> used instead. So by default each framebuffer keeps using it's own
> memory region which preserves backwards compatibility.
>
> This allows cloning the same memory region to several overlays and yet
> each overlay can be controlled independently since they can be
> associated with separate framebuffer devices.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com>
Actaully scrap this one. The use_count thing makes it's somewhat too
easy to get stuck in a state where you can't change the memory size
anymore and going in via sysfs in an effort to fix it doesn't work. I
think I'll just go back to checking all the overlays and expand it to
loop over all the fb devices too. The check won't be entirely accurate
since the fb_infos can't be locked as that could easily lead to ABBA
deadlock with the fb_info lock and the region mutex, but I suppose it's
better than not being able to free/allocate memory anymore.
--
Ville Syrjälä
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@nokia.com>
To: "Valkeinen Tomi (Nokia-D/Helsinki)" <Tomi.Valkeinen@nokia.com>
Cc: "linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v2] DSS2: OMAPFB: Add support for switching memory regions
Date: Thu, 4 Mar 2010 16:01:59 +0200 [thread overview]
Message-ID: <20100304140159.GC18243@nokia.com> (raw)
In-Reply-To: <1267555019-18176-1-git-send-email-ville.syrjala@nokia.com>
On Tue, Mar 02, 2010 at 07:36:59PM +0100, Syrjala Ville (Nokia-D/Helsinki) wrote:
> From: Ville Syrjälä <ville.syrjala@nokia.com>
>
> Separate the memory region from the framebuffer device a little bit.
> It's now possible to select the memory region used by the framebuffer
> device using the new source_idx parameter of omapfb_plane_info. If the
> source_idx is specified it will be interpreted as an index into the
> memory regions array, if it's not specified the framebuffer's index is
> used instead. So by default each framebuffer keeps using it's own
> memory region which preserves backwards compatibility.
>
> This allows cloning the same memory region to several overlays and yet
> each overlay can be controlled independently since they can be
> associated with separate framebuffer devices.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com>
Actaully scrap this one. The use_count thing makes it's somewhat too
easy to get stuck in a state where you can't change the memory size
anymore and going in via sysfs in an effort to fix it doesn't work. I
think I'll just go back to checking all the overlays and expand it to
loop over all the fb devices too. The check won't be entirely accurate
since the fb_infos can't be locked as that could easily lead to ABBA
deadlock with the fb_info lock and the region mutex, but I suppose it's
better than not being able to free/allocate memory anymore.
--
Ville Syrjälä
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-03-04 14:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 18:36 [PATCH v2] DSS2: OMAPFB: Add support for switching memory regions ville.syrjala
2010-03-02 18:36 ` ville.syrjala
2010-03-04 14:01 ` Ville Syrjälä [this message]
2010-03-04 14:01 ` Ville Syrjälä
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=20100304140159.GC18243@nokia.com \
--to=ville.syrjala@nokia.com \
--cc=Tomi.Valkeinen@nokia.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.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.