From: Roger Larsson <roger.larsson@norran•net>
To: Benjamin Herrenschmidt <benh@kernel•crashing.org>
Cc: linuxppc-embedded@ozlabs•org
Subject: Re: shared config registers and locking
Date: Thu, 7 Dec 2006 02:22:06 +0100 [thread overview]
Message-ID: <200612070222.07456.roger.larsson@norran.net> (raw)
In-Reply-To: <1165448053.5469.145.camel@localhost.localdomain>
On Thursday 07 December 2006 00:34, you wrote:
> > GACK! Many better engineers than any of us have spent countless hours
> > breaking down locks. A lock takes nearly no space at all, you're not
> > proposing to lock any less often, so multiple locks take no less time,
> > the only thing you stand to gain by protecting multiple data structures
> > with one lock is the possibility of lock contention. Please reconsider.
>
> Wait wait wait.... I'm perfectly aware of lock contention issues and I'm
> not proposing to have a giant lock for everything in the system.
>
> I was proposing something very clearly aimed at configuration type
> things that are generally accessed a bit at boot time and then every
> time the phase of the moon changes, in which case, it's just a pain to
> have to use fine grained locking and one shared lock is plenty enough.
>
> 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?
- - -
> Another approach would be to remove the code from EMAC and have it
> instead use the "feature call" thingy to call into platform code to do
> the magic clock tweaking (with appropriate locking) but I don't like
> much that idea as all 4xx platforms pretty much would have to duplicate
> that code, and I prefer keeping some of that magic in the EMAC driver
> itself.
I usually preferre this approach. Since the magic from one point of view
(EMAC) is normal configuration from another.
Good candidates from EMACs(!) point of view...
EMAC_RX_CLK_TX(int idx)
EMAC_RX_CLK_DEFAULT(int idx)
But form clock config it is probably closer to this.
CLK_DEFAULT(int idx)
...
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(...)
#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
/RogerL
next prev parent reply other threads:[~2006-12-07 1:22 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 [this message]
2006-12-07 2:47 ` Benjamin Herrenschmidt
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=200612070222.07456.roger.larsson@norran.net \
--to=roger.larsson@norran$(echo .)net \
--cc=benh@kernel$(echo .)crashing.org \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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