All of lore.kernel.org
 help / color / mirror / Atom feed
From: "stanley.miao" <stanley.miao@windriver.com>
To: Tony Lindgren <tony@atomide.com>
Cc: David Brownell <david-b@pacbell.net>, linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP: Fix McBSP spin_lock deadlock.
Date: Thu, 06 Nov 2008 20:41:21 +0800	[thread overview]
Message-ID: <1225975281.7337.8.camel@localhost> (raw)
In-Reply-To: <20081106011621.GJ21736@atomide.com>

On Wed, 2008-11-05 at 17:16 -0800, Tony Lindgren wrote:
> * David Brownell <david-b@pacbell.net> [081105 15:53]:
> > On Wednesday 05 November 2008, Stanley.Miao wrote:
> > > @@ -333,7 +333,8 @@ struct omap_mcbsp_platform_data {
> > >         u8 dma_rx_sync, dma_tx_sync;
> > >         u16 rx_irq, tx_irq;
> > >         struct omap_mcbsp_ops *ops;
> > > -       char const *clk_name;
> > > +       char const *ick_name;
> > > +       char const *fck_name;
> > >  };
> > >  
> > >  struct omap_mcbsp {
> > 
> > I thought the idea was to fix this using the clock aliasing
> > facility ... so that the mcbsp driver would just
> > 
> > 	ick = clk_get(dev, "ick");
> > 	fck = clk_get(dev, "fck");
> > 
> > (with IS_ERR checks of course) and the platform data would
> > no longer need to hold those names.
> > 
> > That approach can work on OMAP1 too ... I think this patch
> > breaks OMAP1 boards.
> 
> Russell also has some ideas, so despite the nasty bug, let's put
> the clock aliasing and virtual clocks stuff on hold for a little
> while. Meanwhile, maybe we can just add some function for the
> virtual clock that does not cause the recursion?

After considering your suggestions, I change to another solution and
will re-send the patch.

Stanley.

> 
> Tony

      parent reply	other threads:[~2008-11-06 12:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-05 12:00 [PATCH] OMAP: Fix McBSP spin_lock deadlock Stanley.Miao
2008-11-05 23:46 ` David Brownell
2008-11-06  1:16   ` Tony Lindgren
2008-11-06  1:49     ` stanley.miao
2008-11-06 12:41     ` stanley.miao [this message]

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=1225975281.7337.8.camel@localhost \
    --to=stanley.miao@windriver.com \
    --cc=david-b@pacbell.net \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.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.