From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Roger Larsson <roger.larsson@norran.net>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: shared config registers and locking
Date: Thu, 07 Dec 2006 13:47:43 +1100 [thread overview]
Message-ID: <1165459663.5469.159.camel@localhost.localdomain> (raw)
In-Reply-To: <200612070222.07456.roger.larsson@norran.net>
> > The specific example that made me think about it was some clock control
> > registers on 4xx that the EMAC driver is whacking every now and then (on
> > link state change, no lock contention to be worried about here), though
> > they could be used by other drivers too (or platform code). Since those
> > registers are a bit different from one 4xx to the next too, and since I
> > now have a non-4xx platform that needs to use EMAC and has similar clock
> > control bits I might have to toggle there too, I'm basically ending up
> > with a global spinlock that I can't precisely define better than "global
> > clock control lock" ....
> >
>
> Do all EMAC implementations have this problem?
No, only some of them.
> Another approach might be to factor out the modification code only,
> keeping the original locking code for comparation...
> static inline modify_dcr(reg, set_mask, reset_mask)
> {
> unsigned long flags;
> local_irq_save(flags);
> mtdcr(reg, mfdcr(reg) & ~reset_mask | set_mask ))
> local_irq_restore(flags);
> }
> and
> static inline SDR_MODIFY(...)
Since we need a spinlock here (the whole point of the exercise is to
make it SMP and -rt safe), that means having a global spinlock used by
modify_dcr / SDR_MODIFY which boils down to something not far from my
proposal.
> #if defined(CONFIG_405EP)
> #define EMAC_RX_CLK_TX(idx) modify_dcr(0xf3, 1<< (idx), 0)
> #else
> #define EMAC_RX_CLK_TX(idx) SDR_MODIFY(DCRN_SDR_MFR, (0x08000000 >> idx), 0)
> #endif
The ifdef's are going away in my rework in favor of something like
if (emac_has_feature(dev, EMAC_FTR_NEED_405EP_CLK_FIX))
xxxx
So that we can build support for multiple models in one driver if we
want. If we don't, the above if will turn into if (0) / if (1) depending
on what we build for and thus the compiler will do the right thing and
optimize out unused code. That's the approach we use already for CPU and
firmware features and it works well.
Ben.
next prev parent reply other threads:[~2006-12-07 2:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-06 5:10 shared config registers and locking Benjamin Herrenschmidt
2006-12-06 5:16 ` Benjamin Herrenschmidt
2006-12-06 6:06 ` Eugene Surovegin
2006-12-06 6:36 ` Benjamin Herrenschmidt
2006-12-06 21:57 ` Roger Larsson
2006-12-06 22:57 ` Benjamin Herrenschmidt
2006-12-06 23:14 ` Michael Galassi
2006-12-06 23:34 ` Benjamin Herrenschmidt
2006-12-07 1:22 ` Roger Larsson
2006-12-07 2:47 ` Benjamin Herrenschmidt [this message]
2006-12-07 18:18 ` Roger Larsson
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=1165459663.5469.159.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=roger.larsson@norran.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).