All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <treding@nvidia.com>
To: Alan Cox <alan@linux.intel.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 17:12:34 +0100	[thread overview]
Message-ID: <20150112161233.GC16118@ulmo.nvidia.com> (raw)
In-Reply-To: <1421069367.31978.21.camel@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]

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?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <treding@nvidia.com>
To: Alan Cox <alan@linux.intel.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 17:12:34 +0100	[thread overview]
Message-ID: <20150112161233.GC16118@ulmo.nvidia.com> (raw)
In-Reply-To: <1421069367.31978.21.camel@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]

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?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-01-12 16:12 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 [this message]
2015-01-12 16:12     ` Thierry Reding
2015-01-12 16:14     ` Alan Cox
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=20150112161233.GC16118@ulmo.nvidia.com \
    --to=treding@nvidia.com \
    --cc=airlied@linux.ie \
    --cc=airlied@redhat.com \
    --cc=alan@linux.intel.com \
    --cc=damien.lespiau@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.