All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@linux.intel.com>
To: Thierry Reding <treding@nvidia.com>
Cc: Nicholas Krause <xerofoify@gmail.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	airlied@redhat.com
Subject: Re: [PATCH] gpu:drm:Change calls to mdelay to msleep in the functions,send_pkg_prepare and send_pkg_done for the file,mdfld_dsi_pkg_sender.c
Date: Mon, 12 Jan 2015 16:14:49 +0000	[thread overview]
Message-ID: <1421079289.31978.34.camel@linux.intel.com> (raw)
In-Reply-To: <20150112161233.GC16118@ulmo.nvidia.com>

On Mon, 2015-01-12 at 17:12 +0100, Thierry Reding wrote:
> On Mon, Jan 12, 2015 at 01:29:27PM +0000, Alan Cox wrote:
> > On Sat, 2015-01-10 at 23:31 -0500, Nicholas Krause wrote:
> > > Changes various calls in the functions,send_pkg_prepare and send_pkg_done
> > > for mdelay to msleep. These changes are needed due to use working with
> > > various sleep modes supported by this hardware and thus needing to sleep
> > > for a small duration instead of using the respectful delay function due
> > > to the need to sleep rather then busy loop the CPU(s) and waste CPU cycles
> > > on the system that could be used to handle other tasks.
> > > 
> > > Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
> > 
> > NAK
> > 
> > Like every other TODO you've been mucking with at random this one is
> > there for a reason.
> > 
> > We can't sleep at this point.
> 
> From a quick look it seems like the only reason why we can't sleep is
> because sender->lock is a spinlock. But it would seem that it could
> simply be a mutex, in which case the delays could become sleeps.
> 
> Do you happen to remember if there were specific reasons to make this a
> spinlock rather than a mutex?

I don't remember the full details and since I don't currently have a
test platform for it, and its obsolete I don't want to touch it.

If someone else does fine, but they need to verify it on real hardware.

Alan


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Alan Cox <alan@linux.intel.com>
To: Thierry Reding <treding@nvidia.com>
Cc: Nicholas Krause <xerofoify@gmail.com>,
	airlied@linux.ie, airlied@redhat.com, damien.lespiau@intel.com,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] gpu:drm:Change calls to mdelay to msleep in the functions,send_pkg_prepare and send_pkg_done for the file,mdfld_dsi_pkg_sender.c
Date: Mon, 12 Jan 2015 16:14:49 +0000	[thread overview]
Message-ID: <1421079289.31978.34.camel@linux.intel.com> (raw)
In-Reply-To: <20150112161233.GC16118@ulmo.nvidia.com>

On Mon, 2015-01-12 at 17:12 +0100, Thierry Reding wrote:
> On Mon, Jan 12, 2015 at 01:29:27PM +0000, Alan Cox wrote:
> > On Sat, 2015-01-10 at 23:31 -0500, Nicholas Krause wrote:
> > > Changes various calls in the functions,send_pkg_prepare and send_pkg_done
> > > for mdelay to msleep. These changes are needed due to use working with
> > > various sleep modes supported by this hardware and thus needing to sleep
> > > for a small duration instead of using the respectful delay function due
> > > to the need to sleep rather then busy loop the CPU(s) and waste CPU cycles
> > > on the system that could be used to handle other tasks.
> > > 
> > > Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
> > 
> > NAK
> > 
> > Like every other TODO you've been mucking with at random this one is
> > there for a reason.
> > 
> > We can't sleep at this point.
> 
> From a quick look it seems like the only reason why we can't sleep is
> because sender->lock is a spinlock. But it would seem that it could
> simply be a mutex, in which case the delays could become sleeps.
> 
> Do you happen to remember if there were specific reasons to make this a
> spinlock rather than a mutex?

I don't remember the full details and since I don't currently have a
test platform for it, and its obsolete I don't want to touch it.

If someone else does fine, but they need to verify it on real hardware.

Alan



  reply	other threads:[~2015-01-12 16:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1420950664-18875-1-git-send-email-xerofoify@gmail.com>
2015-01-12 13:29 ` [PATCH] gpu:drm:Change calls to mdelay to msleep in the functions,send_pkg_prepare and send_pkg_done for the file,mdfld_dsi_pkg_sender.c Alan Cox
2015-01-12 13:29   ` Alan Cox
2015-01-12 16:12   ` Thierry Reding
2015-01-12 16:12     ` Thierry Reding
2015-01-12 16:14     ` Alan Cox [this message]
2015-01-12 16:14       ` Alan Cox

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=1421079289.31978.34.camel@linux.intel.com \
    --to=alan@linux.intel.com \
    --cc=airlied@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=treding@nvidia.com \
    --cc=xerofoify@gmail.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.