All of lore.kernel.org
 help / color / mirror / Atom feed
From: marek.vasut@gmail.com (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] MXS: Convert mutexes in clock.c to spinlocks
Date: Mon, 19 Dec 2011 22:43:49 +0100	[thread overview]
Message-ID: <201112192243.49355.marek.vasut@gmail.com> (raw)
In-Reply-To: <201112192237.42034.marek.vasut@gmail.com>

> > On Mon, Dec 19, 2011 at 10:05:25PM +0100, Marek Vasut wrote:
> > > > On Mon, Dec 19, 2011 at 09:54:25PM +0100, Marek Vasut wrote:
> > > > > > So, in summary, you have everything you require to fix it outside
> > > > > > the driver.  You just have to decide which of the two options you
> > > > > > want to proceed with, and actually (and finally) do it instead of
> > > > > > endlessly procrastinating and waiting for more and more bug
> > > > > > reports (which is exactly what has happened so far.)
> > > > > 
> > > > > What the hell, I just recently found this bug and I submitted a
> > > > > patch right away! What are you complaining about?!
> > > > 
> > > > If you want to take that attitude to my attempt to help you
> > > > understand the problem and see solutions, I'll ignore you
> > > > permanently for being an absolute twit.
> > > 
> > > Go ahead, but you accused me of procrastinating and waiting even if the
> > > first thing I did when I saw the bug was start solving it. That's just
> > > insane!
> > > 
> > > > I'm not going to spend time giving a detailed explaination
> > > > about the background and options over something to only then have it
> > > > immediately shoved back in my face with such a response.
> > > 
> > > I consider my response to the last part of your email appropriate.
> > 
> > Sorry, it wasn't directed personally at you, but to the entire MXS
> 
> > community.  The facts over this are:
> Ah! I'm sorry I was so direct and rude too. I was unaware it was discussed
> before, I started this effort on my own just recently.
> 
> > 1. This problem has been known about since October.
> 
> I was really away from the kernel community for a while so I didn't know.
> 
> > 2. It's been discussed several times - every time along the same lines.
> > 3. There is zero apparant progress on the issue.
> > 
> > Here's two of the discussions over it, where I've said exactly the same
> > thing:
> > 
> > http://lists.arm.linux.org.uk/lurker/thread/20111018.173744.46c4bd76.en.h
> > tm l
> > http://lists.arm.linux.org.uk/lurker/thread/20111123.183640.222b05cf.en.h
> > t ml
> > 
> > So now, tell me - is this _finally_ going to get fixed in the MXS code,
> > or is the previous discussion about converting stuff to spinlocks etc
> > just going to be repeated yet again?
> 
> Spinlocks are OK as far as the code within them is fast, right ? But hm ...
> actually, we might be able to toggle the clock in one instruction by using
> the bitwise set/clear registers. That way, we won't need the locks at all,
> but we'd loose the usecount ... which is useless anyway).
> 
> M

I see ... clk_set_rate() can be slow. OK, looking further into it.

WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marek.vasut@gmail.com>
To: "Russell King - ARM Linux" <linux@arm.linux.org.uk>
Cc: Shawn Guo <shawn.guo@freescale.com>, Wolfgang Denk <wd@denx.de>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	linux-kernel@vger.kernel.org, Huang Shijie <b32955@freescale.com>,
	linux-arm-kernel@lists.infradead.org,
	Shawn Guo <shawn.guo@linaro.org>, Stefano Babic <sbabic@denx.de>
Subject: Re: [PATCH] MXS: Convert mutexes in clock.c to spinlocks
Date: Mon, 19 Dec 2011 22:43:49 +0100	[thread overview]
Message-ID: <201112192243.49355.marek.vasut@gmail.com> (raw)
In-Reply-To: <201112192237.42034.marek.vasut@gmail.com>

> > On Mon, Dec 19, 2011 at 10:05:25PM +0100, Marek Vasut wrote:
> > > > On Mon, Dec 19, 2011 at 09:54:25PM +0100, Marek Vasut wrote:
> > > > > > So, in summary, you have everything you require to fix it outside
> > > > > > the driver.  You just have to decide which of the two options you
> > > > > > want to proceed with, and actually (and finally) do it instead of
> > > > > > endlessly procrastinating and waiting for more and more bug
> > > > > > reports (which is exactly what has happened so far.)
> > > > > 
> > > > > What the hell, I just recently found this bug and I submitted a
> > > > > patch right away! What are you complaining about?!
> > > > 
> > > > If you want to take that attitude to my attempt to help you
> > > > understand the problem and see solutions, I'll ignore you
> > > > permanently for being an absolute twit.
> > > 
> > > Go ahead, but you accused me of procrastinating and waiting even if the
> > > first thing I did when I saw the bug was start solving it. That's just
> > > insane!
> > > 
> > > > I'm not going to spend time giving a detailed explaination
> > > > about the background and options over something to only then have it
> > > > immediately shoved back in my face with such a response.
> > > 
> > > I consider my response to the last part of your email appropriate.
> > 
> > Sorry, it wasn't directed personally at you, but to the entire MXS
> 
> > community.  The facts over this are:
> Ah! I'm sorry I was so direct and rude too. I was unaware it was discussed
> before, I started this effort on my own just recently.
> 
> > 1. This problem has been known about since October.
> 
> I was really away from the kernel community for a while so I didn't know.
> 
> > 2. It's been discussed several times - every time along the same lines.
> > 3. There is zero apparant progress on the issue.
> > 
> > Here's two of the discussions over it, where I've said exactly the same
> > thing:
> > 
> > http://lists.arm.linux.org.uk/lurker/thread/20111018.173744.46c4bd76.en.h
> > tm l
> > http://lists.arm.linux.org.uk/lurker/thread/20111123.183640.222b05cf.en.h
> > t ml
> > 
> > So now, tell me - is this _finally_ going to get fixed in the MXS code,
> > or is the previous discussion about converting stuff to spinlocks etc
> > just going to be repeated yet again?
> 
> Spinlocks are OK as far as the code within them is fast, right ? But hm ...
> actually, we might be able to toggle the clock in one instruction by using
> the bitwise set/clear registers. That way, we won't need the locks at all,
> but we'd loose the usecount ... which is useless anyway).
> 
> M

I see ... clk_set_rate() can be slow. OK, looking further into it.

  reply	other threads:[~2011-12-19 21:43 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-18 14:06 [PATCH] MXS: Convert mutexes in clock.c to spinlocks Marek Vasut
2011-12-18 14:06 ` Marek Vasut
2011-12-19  3:27 ` Shawn Guo
2011-12-19  3:27   ` Shawn Guo
2011-12-19  4:03   ` Marek Vasut
2011-12-19  4:03     ` Marek Vasut
2011-12-19  8:22     ` Russell King - ARM Linux
2011-12-19  8:22       ` Russell King - ARM Linux
2011-12-19 11:57       ` Marek Vasut
2011-12-19 11:57         ` Marek Vasut
2011-12-19 12:15         ` Russell King - ARM Linux
2011-12-19 12:15           ` Russell King - ARM Linux
2011-12-19 20:54           ` Marek Vasut
2011-12-19 20:54             ` Marek Vasut
2011-12-19 21:03             ` Russell King - ARM Linux
2011-12-19 21:03               ` Russell King - ARM Linux
2011-12-19 21:05               ` Marek Vasut
2011-12-19 21:05                 ` Marek Vasut
2011-12-19 21:28                 ` Russell King - ARM Linux
2011-12-19 21:28                   ` Russell King - ARM Linux
2011-12-19 21:37                   ` Marek Vasut
2011-12-19 21:37                     ` Marek Vasut
2011-12-19 21:43                     ` Marek Vasut [this message]
2011-12-19 21:43                       ` Marek Vasut
2011-12-19 23:23             ` Shawn Guo
2011-12-19 23:23               ` Shawn Guo
2011-12-19 23:35               ` Marek Vasut
2011-12-19 23:35                 ` Marek Vasut
2011-12-20  0:19                 ` Shawn Guo
2011-12-20  0:19                   ` Shawn Guo
2011-12-20  3:09                   ` Marek Vasut
2011-12-20  3:09                     ` Marek Vasut

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=201112192243.49355.marek.vasut@gmail.com \
    --to=marek.vasut@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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.