All of lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@nokia.com>
To: "Syrjala Ville (Nokia-D/Helsinki)" <ville.syrjala@nokia.com>
Cc: "Valkeinen Tomi (Nokia-D/Helsinki)" <Tomi.Valkeinen@nokia.com>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory
Date: Wed, 17 Mar 2010 17:34:07 +0000	[thread overview]
Message-ID: <20100317173407.GD30422@localhost> (raw)
In-Reply-To: <1267795582-21004-1-git-send-email-ville.syrjala@nokia.com>

Hi,

couple of minor comments inlined.

On Fri, Mar 05, 2010 at 02:26:19PM +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 mem_idx parameter of omapfb_plane_info. If the
> mem_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>
> ---
> Changes since v2:
> * Removed the use_count and rely on just counting all active overlays. A bit racy
>   but no chance of getting stuck in a state where memory allocation can't be changed.
> * s/source_idx/mem_idx as that seems to be a little more self explanatory
> [...]
> 
>  drivers/video/omap2/omapfb/omapfb-ioctl.c |  163 ++++++++++++++++++++-----
>  drivers/video/omap2/omapfb/omapfb-main.c  |  184 +++++++++++++++++++----------
>  drivers/video/omap2/omapfb/omapfb-sysfs.c |   60 ++++++++--
>  drivers/video/omap2/omapfb/omapfb.h       |   38 ++++++-
>  include/linux/omapfb.h                    |    5 +-
>  5 files changed, 339 insertions(+), 111 deletions(-)
> 
> diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
> index 1ffa760..cd00bdc 100644
> --- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
> +++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
> [...]
>  static int omapfb_query_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
>  {
>         struct omapfb_info *ofbi = FB2OFB(fbi);
> +       struct omap_overlay *ovl = ofbi->overlays[0];
> +       struct omap_overlay_info *ovli = &ovl->info;
> 
>         if (ofbi->num_overlays != 1) {
>                 memset(pi, 0, sizeof(*pi));
>         } else {
> -               struct omap_overlay_info *ovli;
> -               struct omap_overlay *ovl;
> -
> -               ovl = ofbi->overlays[0];
> -               ovli = &ovl->info;
> -

Is this really necessary?

>                 pi->pos_x = ovli->pos_x;
>                 pi->pos_y = ovli->pos_y;
>                 pi->enabled = ovli->enabled;
>                 pi->channel_out = 0; /* xxx */
>                 pi->mirror = 0;
> +               pi->mem_idx = get_mem_idx(ofbi);
>                 pi->out_width = ovli->out_width;
>                 pi->out_height = ovli->out_height;
>         }
> @@ -115,30 +184,57 @@ static int omapfb_setup_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
>         struct omapfb_info *ofbi = FB2OFB(fbi);
>         struct omapfb2_device *fbdev = ofbi->fbdev;
>         struct omapfb2_mem_region *rg;
> -       int r, i;
> +       int r = 0;
>         size_t size;
> +       int i;
> 
>         if (mi->type > OMAPFB_MEMTYPE_MAX)
>                 return -EINVAL;
> 
>         size = PAGE_ALIGN(mi->size);
> 
> -       rg = &ofbi->region;
> +       rg = ofbi->region;
> 
> -       for (i = 0; i < ofbi->num_overlays; i++) {
> -               if (ofbi->overlays[i]->info.enabled)
> -                       return -EBUSY;
> +       /* FIXME probably should be a rwsem ... */
> +       mutex_lock(&rg->mtx);
> +       while (rg->ref) {
> +               mutex_unlock(&rg->mtx);
> +               schedule();
> +               mutex_lock(&rg->mtx);
> +       }

Yes, rwsem would mean no unnecessary scheduling and also make things
clearer.

> [...]
>  static int omapfb_query_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
> @@ -146,12 +242,15 @@ static int omapfb_query_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
>         struct omapfb_info *ofbi = FB2OFB(fbi);
>         struct omapfb2_mem_region *rg;
> 
> -       rg = &ofbi->region;
>         memset(mi, 0, sizeof(*mi));
> 
> +       rg = omapfb_get_mem_region(ofbi->region);

At some other users of region I haven't seen omapfb_get_mem_region,
like store_mirror, store_overlays_rotate.

It wouldn't have been nice to have this patch in smaller chunks. For example
one for converting all region. to region-> and another one for adding the
locking for it, then the rest.

Otherwise it looks ok to me.

--Imre


WARNING: multiple messages have this Message-ID (diff)
From: Imre Deak <imre.deak@nokia.com>
To: "Syrjala Ville (Nokia-D/Helsinki)" <ville.syrjala@nokia.com>
Cc: "Valkeinen Tomi (Nokia-D/Helsinki)" <Tomi.Valkeinen@nokia.com>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions
Date: Wed, 17 Mar 2010 19:34:07 +0200	[thread overview]
Message-ID: <20100317173407.GD30422@localhost> (raw)
In-Reply-To: <1267795582-21004-1-git-send-email-ville.syrjala@nokia.com>

Hi,

couple of minor comments inlined.

On Fri, Mar 05, 2010 at 02:26:19PM +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 mem_idx parameter of omapfb_plane_info. If the
> mem_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>
> ---
> Changes since v2:
> * Removed the use_count and rely on just counting all active overlays. A bit racy
>   but no chance of getting stuck in a state where memory allocation can't be changed.
> * s/source_idx/mem_idx as that seems to be a little more self explanatory
> [...]
> 
>  drivers/video/omap2/omapfb/omapfb-ioctl.c |  163 ++++++++++++++++++++-----
>  drivers/video/omap2/omapfb/omapfb-main.c  |  184 +++++++++++++++++++----------
>  drivers/video/omap2/omapfb/omapfb-sysfs.c |   60 ++++++++--
>  drivers/video/omap2/omapfb/omapfb.h       |   38 ++++++-
>  include/linux/omapfb.h                    |    5 +-
>  5 files changed, 339 insertions(+), 111 deletions(-)
> 
> diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
> index 1ffa760..cd00bdc 100644
> --- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
> +++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
> [...]
>  static int omapfb_query_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
>  {
>         struct omapfb_info *ofbi = FB2OFB(fbi);
> +       struct omap_overlay *ovl = ofbi->overlays[0];
> +       struct omap_overlay_info *ovli = &ovl->info;
> 
>         if (ofbi->num_overlays != 1) {
>                 memset(pi, 0, sizeof(*pi));
>         } else {
> -               struct omap_overlay_info *ovli;
> -               struct omap_overlay *ovl;
> -
> -               ovl = ofbi->overlays[0];
> -               ovli = &ovl->info;
> -

Is this really necessary?

>                 pi->pos_x = ovli->pos_x;
>                 pi->pos_y = ovli->pos_y;
>                 pi->enabled = ovli->enabled;
>                 pi->channel_out = 0; /* xxx */
>                 pi->mirror = 0;
> +               pi->mem_idx = get_mem_idx(ofbi);
>                 pi->out_width = ovli->out_width;
>                 pi->out_height = ovli->out_height;
>         }
> @@ -115,30 +184,57 @@ static int omapfb_setup_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
>         struct omapfb_info *ofbi = FB2OFB(fbi);
>         struct omapfb2_device *fbdev = ofbi->fbdev;
>         struct omapfb2_mem_region *rg;
> -       int r, i;
> +       int r = 0;
>         size_t size;
> +       int i;
> 
>         if (mi->type > OMAPFB_MEMTYPE_MAX)
>                 return -EINVAL;
> 
>         size = PAGE_ALIGN(mi->size);
> 
> -       rg = &ofbi->region;
> +       rg = ofbi->region;
> 
> -       for (i = 0; i < ofbi->num_overlays; i++) {
> -               if (ofbi->overlays[i]->info.enabled)
> -                       return -EBUSY;
> +       /* FIXME probably should be a rwsem ... */
> +       mutex_lock(&rg->mtx);
> +       while (rg->ref) {
> +               mutex_unlock(&rg->mtx);
> +               schedule();
> +               mutex_lock(&rg->mtx);
> +       }

Yes, rwsem would mean no unnecessary scheduling and also make things
clearer.

> [...]
>  static int omapfb_query_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
> @@ -146,12 +242,15 @@ static int omapfb_query_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
>         struct omapfb_info *ofbi = FB2OFB(fbi);
>         struct omapfb2_mem_region *rg;
> 
> -       rg = &ofbi->region;
>         memset(mi, 0, sizeof(*mi));
> 
> +       rg = omapfb_get_mem_region(ofbi->region);

At some other users of region I haven't seen omapfb_get_mem_region,
like store_mirror, store_overlays_rotate.

It wouldn't have been nice to have this patch in smaller chunks. For example
one for converting all region. to region-> and another one for adding the
locking for it, then the rest.

Otherwise it looks ok to me.

--Imre

--
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

  parent reply	other threads:[~2010-03-17 17:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-05 13:26 [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions ville.syrjala
2010-03-05 13:26 ` ville.syrjala
2010-03-05 13:26 ` [PATCH 2/4] DSS2: Check if display supports update mode changes ville.syrjala
2010-03-05 13:26   ` ville.syrjala
2010-03-05 13:26 ` [PATCH 3/4] DSS2: Make wait_for_go() succeed for disabled displays ville.syrjala
2010-03-05 13:26   ` ville.syrjala
2010-03-05 13:26 ` [PATCH 4/4] DSS2: clear spurious SYNC_LOST_DIGIT interrupts ville.syrjala
2010-03-05 13:26   ` ville.syrjala
2010-03-05 15:19   ` Aguirre, Sergio
2010-03-05 15:19     ` Aguirre, Sergio
2010-03-05 15:25     ` Tomi Valkeinen
2010-03-05 15:25       ` Tomi Valkeinen
2010-03-05 15:28       ` Aguirre, Sergio
2010-03-05 15:28         ` Aguirre, Sergio
2010-03-17 13:50 ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Tomi Valkeinen
2010-03-17 13:50   ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions Tomi Valkeinen
2010-03-17 15:51   ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Ville Syrjälä
2010-03-17 15:51     ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions Ville Syrjälä
2010-03-17 17:34 ` Imre Deak [this message]
2010-03-17 17:34   ` Imre Deak
2010-03-17 20:14   ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Ville Syrjälä
2010-03-17 20:14     ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions Ville Syrjälä
2010-03-18  8:52     ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Imre Deak
2010-03-18  8:52       ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions Imre Deak
2010-03-18 15:26       ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Ville Syrjälä
2010-03-18 15:26         ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions Ville Syrjälä
2010-03-19  7:46         ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Imre Deak
2010-03-19  7:46           ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions Imre Deak
2010-03-19 12:23           ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Ville Syrjälä
2010-03-19 12:23             ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions 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=20100317173407.GD30422@localhost \
    --to=imre.deak@nokia.com \
    --cc=Tomi.Valkeinen@nokia.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ville.syrjala@nokia.com \
    /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.