* [PATCH] net/ucc_geth: allow to set mac address on running device
From: Kevin Hao @ 2009-05-27 1:48 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, leoli, netdev
Inspired by the patch for 8139too (bda6a15a).
Currently we can't set mac address on a running ucc_geth device.
But this is needed when you use this device as a bonding slave in
bonding device in balance-alb mode. So add this feature for ucc_geth
device.
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
---
drivers/net/ucc_geth.c | 33 ++++++++++++++++++++++++++++++++-
1 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 9dd16c9..3c595d7 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3339,6 +3339,37 @@ static void ucc_netpoll(struct net_device *dev)
}
#endif /* CONFIG_NET_POLL_CONTROLLER */
+static int ucc_geth_set_mac_addr(struct net_device *dev, void *p)
+{
+ struct ucc_geth_private *ugeth = netdev_priv(dev);
+ struct sockaddr *addr = p;
+
+ if (!is_valid_ether_addr(addr->sa_data))
+ return -EADDRNOTAVAIL;
+
+ memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
+
+ /*
+ * If device is not running, we will set mac addr register
+ * when opening the device.
+ */
+ if (!netif_running(dev))
+ return 0;
+
+ spin_lock_irq(&ugeth->lock);
+ init_mac_station_addr_regs(dev->dev_addr[0],
+ dev->dev_addr[1],
+ dev->dev_addr[2],
+ dev->dev_addr[3],
+ dev->dev_addr[4],
+ dev->dev_addr[5],
+ &ugeth->ug_regs->macstnaddr1,
+ &ugeth->ug_regs->macstnaddr2);
+ spin_unlock_irq(&ugeth->lock);
+
+ return 0;
+}
+
/* Called when something needs to use the ethernet device */
/* Returns 0 for success. */
static int ucc_geth_open(struct net_device *dev)
@@ -3515,7 +3546,7 @@ static const struct net_device_ops ucc_geth_netdev_ops = {
.ndo_stop = ucc_geth_close,
.ndo_start_xmit = ucc_geth_start_xmit,
.ndo_validate_addr = eth_validate_addr,
- .ndo_set_mac_address = eth_mac_addr,
+ .ndo_set_mac_address = ucc_geth_set_mac_addr,
.ndo_change_mtu = eth_change_mtu,
.ndo_set_multicast_list = ucc_geth_set_multi,
.ndo_tx_timeout = ucc_geth_timeout,
--
1.6.0.4.771.gef3b3
^ permalink raw reply related
* Re: [PATCH] Display processor virtualization resource allocations in lparcfg
From: Michael Ellerman @ 2009-05-27 1:14 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev
In-Reply-To: <4A1C2E10.9020109@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]
On Tue, 2009-05-26 at 12:59 -0500, Nathan Fontenot wrote:
> This patch updates the output from /proc/ppc64/lparcfg to display the
> processor virtualization resource allocations for a shared processor
> partition.
> @@ -267,6 +281,28 @@
> seq_printf(m, "capped=%d\n", ppp_data.capped);
> seq_printf(m, "unallocated_capacity=%lld\n",
> ppp_data.unallocated_entitlement);
> +
> + /* The last bits of information returned from h_get_ppp are only
> + * valid if the ibm,partition-performance-parameters-level
> + * property is >= 1.
> + */
> + root = of_find_node_by_path("/");
> + if (root) {
> + perf_level = of_get_property(root,
> + "ibm,partition-performance-parameters-level",
> + NULL);
What if there is no such property?
> + if (*perf_level >= 1) {
> + seq_printf(m,
> + "physical_procs_allocated_to_virtualization=%d\n",
> + ppp_data.phys_platform_procs);
> + seq_printf(m, "max_proc_capacity_available=%d\n",
> + ppp_data.max_proc_cap_avail);
> + seq_printf(m, "entitled_proc_capacity_available=%d\n",
> + ppp_data.entitled_proc_cap_avail);
> + }
> +
> + of_node_put(root);
> + }
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH] Modify mpc5200 AC97 driver to use V9 of spin_event_timeout()
From: Jon Smirl @ 2009-05-27 1:01 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <ed82fe3e0905261753v1cb9c901i3b66cd903e4adda6@mail.gmail.com>
On Tue, May 26, 2009 at 8:53 PM, Timur Tabi <timur@freescale.com> wrote:
> On Tue, May 26, 2009 at 7:44 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>
>> Because Grant didn't want me doing udelay(50) just to delay things in
>> order to give the AC97 controller time to initialize. Your function
>> lets me loop on cpu_relax() for 50us.
>
> But udelay() calls HMT_low(), which is like cpu_relax().
Then why did you need to make your routine that calls cpu_relax()?
I don't know what goes on in the guts of HMT_low() and cpu_relax(),
when you guys decide which one I should use let me know and I can
adjust the patch.
The hardware needs a minimum 50us pause. It doesn't matter if the
pause is more than that. If the CPU has something to keep it busy for
a few milliseconds that's fine.
> --
> Timur Tabi
> Linux kernel developer at Freescale
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [alsa-devel] [PATCH] Modify mpc5200 AC97 driver to use V9 of spin_event_timeout()
From: Timur Tabi @ 2009-05-27 0:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <9e4733910905261744j3589ace8wd427ef8a5998eccf@mail.gmail.com>
On Tue, May 26, 2009 at 7:44 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> Because Grant didn't want me doing udelay(50) just to delay things in
> order to give the AC97 controller time to initialize. Your function
> lets me loop on cpu_relax() for 50us.
But udelay() calls HMT_low(), which is like cpu_relax().
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH] Modify mpc5200 AC97 driver to use V9 of spin_event_timeout()
From: Jon Smirl @ 2009-05-27 0:44 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <ed82fe3e0905261738u655f6f5at2351341a0a5e50d5@mail.gmail.com>
On Tue, May 26, 2009 at 8:38 PM, Timur Tabi <timur@freescale.com> wrote:
> On Tue, May 26, 2009 at 7:25 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>
>> - =A0 =A0 =A0 spin_event_timeout(0, 10, 0, rc);
>> + =A0 =A0 =A0 spin_event_timeout(0, 10, 0);
>> =A0 =A0 =A0 =A0out_8(®s->op0, MPC52xx_PSC_OP_RES);
>> - =A0 =A0 =A0 spin_event_timeout(0, 50, 0, rc);
>> + =A0 =A0 =A0 spin_event_timeout(0, 50, 0);
>
> Jon, I'm still hoping you'll explain why you're not using udelay() here.
Because Grant didn't want me doing udelay(50) just to delay things in
order to give the AC97 controller time to initialize. Your function
lets me loop on cpu_relax() for 50us.
I have to delay 50us because ALSA tries to access the hardware
immediately after the function returns.
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [alsa-devel] [PATCH] Modify mpc5200 AC97 driver to use V9 of spin_event_timeout()
From: Timur Tabi @ 2009-05-27 0:38 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090527002530.16740.62502.stgit@terra>
On Tue, May 26, 2009 at 7:25 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> - =A0 =A0 =A0 spin_event_timeout(0, 10, 0, rc);
> + =A0 =A0 =A0 spin_event_timeout(0, 10, 0);
> =A0 =A0 =A0 =A0out_8(®s->op0, MPC52xx_PSC_OP_RES);
> - =A0 =A0 =A0 spin_event_timeout(0, 50, 0, rc);
> + =A0 =A0 =A0 spin_event_timeout(0, 50, 0);
Jon, I'm still hoping you'll explain why you're not using udelay() here.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] Modify mpc5200 AC97 driver to use V9 of spin_event_timeout()
From: Jon Smirl @ 2009-05-27 0:25 UTC (permalink / raw)
To: grant.likely, linuxppc-dev, alsa-devel, broonie, timur
The function signature for spin_event_timeout() has changed in version V9.
Adjust the mpc5200 AC97 driver to use the new function.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
sound/soc/fsl/mpc5200_psc_ac97.c | 30 ++++++++++++++----------------
1 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c
index 9f2df15..bab80ac 100644
--- a/sound/soc/fsl/mpc5200_psc_ac97.c
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -31,13 +31,13 @@ static struct psc_dma *psc_dma;
static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
{
- int rc;
+ int status;
unsigned int val;
/* Wait for command send status zero = ready */
- spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
- MPC52xx_PSC_SR_CMDSEND), 100, 0, rc);
- if (rc == 0) {
+ status= spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
+ MPC52xx_PSC_SR_CMDSEND), 100, 0);
+ if (status == 0) {
pr_err("timeout on ac97 bus (rdy)\n");
return -ENODEV;
}
@@ -45,9 +45,9 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
out_be32(&psc_dma->psc_regs->ac97_cmd, (1<<31) | ((reg & 0x7f) << 24));
/* Wait for the answer */
- spin_event_timeout((in_be16(&psc_dma->psc_regs->sr_csr.status) &
- MPC52xx_PSC_SR_DATA_VAL), 100, 0, rc);
- if (rc == 0) {
+ status = spin_event_timeout((in_be16(&psc_dma->psc_regs->sr_csr.status) &
+ MPC52xx_PSC_SR_DATA_VAL), 100, 0);
+ if (status == 0) {
pr_err("timeout on ac97 read (val) %x\n",
in_be16(&psc_dma->psc_regs->sr_csr.status));
return -ENODEV;
@@ -66,12 +66,12 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
static void psc_ac97_write(struct snd_ac97 *ac97,
unsigned short reg, unsigned short val)
{
- int rc;
+ int status;
/* Wait for command status zero = ready */
- spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
- MPC52xx_PSC_SR_CMDSEND), 100, 0, rc);
- if (rc == 0) {
+ status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
+ MPC52xx_PSC_SR_CMDSEND), 100, 0);
+ if (status == 0) {
pr_err("timeout on ac97 bus (write)\n");
return;
}
@@ -82,24 +82,22 @@ static void psc_ac97_write(struct snd_ac97 *ac97,
static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
{
- int rc;
struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs;
out_be32(®s->sicr, psc_dma->sicr | MPC52xx_PSC_SICR_AWR);
- spin_event_timeout(0, 3, 0, rc);
+ spin_event_timeout(0, 3, 0);
out_be32(®s->sicr, psc_dma->sicr);
}
static void psc_ac97_cold_reset(struct snd_ac97 *ac97)
{
- int rc;
struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs;
/* Do a cold reset */
out_8(®s->op1, MPC52xx_PSC_OP_RES);
- spin_event_timeout(0, 10, 0, rc);
+ spin_event_timeout(0, 10, 0);
out_8(®s->op0, MPC52xx_PSC_OP_RES);
- spin_event_timeout(0, 50, 0, rc);
+ spin_event_timeout(0, 50, 0);
psc_ac97_warm_reset(ac97);
}
^ permalink raw reply related
* Re: [GIT PULL] fsldma driver fixes
From: Dan Williams @ 2009-05-26 23:59 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev Development, Ira Snyder, lkml
In-Reply-To: <2a27d3730905220347s59dbd152kc69c8399693ae307@mail.gmail.com>
On Fri, May 22, 2009 at 3:47 AM, Li Yang <leoli@freescale.com> wrote:
> Hi Dan,
>
> Here are fixes for Freescale DMA engine driver.
>
> Thanks,
> - Leo
>
>
> The following changes since commit 5805977e63a36ad56594a623f3bd2bebcb7db2=
33:
> =A0Linus Torvalds (1):
> =A0 =A0 =A0 =A0Merge branch 'for-linus' of git://git.kernel.org/.../jbarn=
es/drm-2.6
>
> are available in the git repository at:
>
> =A0git://git.kernel.org/pub/scm/linux/kernel/git/leo/fsl-soc.git fsldma
>
> Ira Snyder (4):
> =A0 =A0 =A0fsldma: fix "DMA halt timeout!" errors
> =A0 =A0 =A0fsldma: fix infinite loop on multi-descriptor DMA chain comple=
tion
> =A0 =A0 =A0fsldma: snooping is not enabled for last entry in descriptor c=
hain
> =A0 =A0 =A0fsldma: fix memory leak on error path in fsl_dma_prep_memcpy()
>
> Li Yang (1):
> =A0 =A0 =A0fsldma: update mailling list address in MAINTAINERS
>
> Roel Kluin (1):
> =A0 =A0 =A0fsldma: fix check on potential fdev->chan[] overflow
>
Pulled, thanks. These all look like 2.6.30 candidates, right? I'll
send these upstream in the next few days as I have not heard back from
Kumar on taking fsldma patches through his tree [1].
Thanks,
Dan
[1]: http://marc.info/?l=3Dlinux-kernel&m=3D124225089507475&w=3D2
^ permalink raw reply
* Re: [U-Boot] [PATCH 1/2] 83xx: Replace CONFIG_MPC83XX with CONFIG_MPC83xx
From: Kim Phillips @ 2009-05-26 23:38 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Peter Tyser, u-boot
In-Reply-To: <20090524201327.CB44C832E416@gemini.denx.de>
On Sun, 24 May 2009 22:13:27 +0200
Wolfgang Denk <wd@denx.de> wrote:
> Dear Peter,
>
> In message <1243192952.703.7.camel@ptyser-laptop> you wrote:
> >
> > > CodingStyle Ch.12 suggests that it's the other fsl arches that are in
> > > violation here, not 83XX:
>
> Agreed...
>
> > Either way is fine with me, as long as things are consistent. It looked
> > like most Freescale CPUs in U-Boot as well as Linux used the lowercase
> > convention for CONFIG_<cpu type> so I thought:
> > a. Most likely someone made a conscious decision to use lowercase
I can understand it in comments and quotes, just not in constants in
the code.
> > b. It'd be much easier to change just 83xx than all other arches:)
that's not a good reason to do it this way though.
> > If others would prefer standardizing on uppercase, I can submit new
> > patches for 85xx, 5xxx, 86xx, etc. This would be still be inconsistent
> > with Linux though, which is a bit annoying.
>
> It seems Linux uses 8?xx with very few exceptions (CONFIG_SND_VIA82XX*
> and CONFIG_EDAC_MPC85XX), so let's do the same here.
so linux is inconsistent too.
I'm a fan of a more self-consistent CONFIG_MPC85XX_MDS over mixed-case
names like linux' CONFIG_MPC85xx_MDS.
I wonder if the linux ppc guys would accept a
s/CONFIG_MPC8?xx/CONFIG_MPC8?XX/g rename patch for linux...
Kim
^ permalink raw reply
* Re: Wrong looking statement in cpm_common.c
From: Scott Wood @ 2009-05-26 22:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1243376537.17847.11.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Tue, 2009-05-26 at 17:15 -0500, Scott Wood wrote:
>> Benjamin Herrenschmidt wrote:
>>> On Tue, 2009-05-26 at 12:56 -0500, Scott Wood wrote:
>>>> Any suggestions for how to do it properly?
>>> ioremap ? :-)
>> Does ioremap work that early?
>
> It works very early on ppc32 but maybe not -that- early... It works from
> start_kernel on. You might be able to do the ioremaps in machine_init
> (provided LMBs are up) but they won't be "effective" until MMU_init
> returns, but then, neither will setbat anyway.
Before the setbat takes effect, there is a BAT established by
setup_cpm_bat in head_32.S.
How about something similar to btext_unmap to tell cpm2 udbg that the
mapping is gone, and to do ioremap at that point (or perhaps it would be
better to wait until the next print after unmap is called, which should
be after load_up_mmu assuming nothing crashes in the assembly code)?
-Scott
^ permalink raw reply
* Re: Wrong looking statement in cpm_common.c
From: Benjamin Herrenschmidt @ 2009-05-26 22:22 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev list
In-Reply-To: <4A1C69F8.9090301@freescale.com>
On Tue, 2009-05-26 at 17:15 -0500, Scott Wood wrote:
> Benjamin Herrenschmidt wrote:
> > On Tue, 2009-05-26 at 12:56 -0500, Scott Wood wrote:
> >> Any suggestions for how to do it properly?
> >
> > ioremap ? :-)
>
> Does ioremap work that early?
It works very early on ppc32 but maybe not -that- early... It works from
start_kernel on. You might be able to do the ioremaps in machine_init
(provided LMBs are up) but they won't be "effective" until MMU_init
returns, but then, neither will setbat anyway.
However, since that's the only user of setbat I can still find and we
want to replace that with something saner, I'd rather kill it.
Ben.
^ permalink raw reply
* Re: Wrong looking statement in cpm_common.c
From: Scott Wood @ 2009-05-26 22:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1243375671.17847.0.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Tue, 2009-05-26 at 12:56 -0500, Scott Wood wrote:
>> Any suggestions for how to do it properly?
>
> ioremap ? :-)
Does ioremap work that early?
-Scott
^ permalink raw reply
* Re: Wrong looking statement in cpm_common.c
From: Benjamin Herrenschmidt @ 2009-05-26 22:07 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev list
In-Reply-To: <20090526175613.GB9464@loki.buserror.net>
On Tue, 2009-05-26 at 12:56 -0500, Scott Wood wrote:
>
> Any suggestions for how to do it properly?
ioremap ? :-)
Ben.
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Ben Dooks @ 2009-05-26 21:33 UTC (permalink / raw)
To: Esben Haabendal; +Cc: linuxppc-dev, linux-i2c, Esben Haabendal
In-Reply-To: <d2b9ea600905260430i72290901p9266de4cade049c1@mail.gmail.com>
On Tue, May 26, 2009 at 01:30:21PM +0200, Esben Haabendal wrote:
> On Tue, May 19, 2009 at 7:22 AM, Esben Haabendal <eha@doredevelopment.dk> wrote:
> > This fixes MAL (arbitration lost) bug caused by illegal use of
> > RSTA (repeated START) after STOP condition generated after last byte
> > of reads. With this patch, it is possible to do an i2c_transfer() with
> > additional i2c_msg's following the I2C_M_RD messages.
> >
> > It still needs to be resolved if it is possible to fix this issue
> > by removing the STOP condition after reads in a robust way.
> >
> > Signed-off-by: Esben Haabendal <eha@doredevelopment.dk>
> > ---
> > ?drivers/i2c/busses/i2c-mpc.c | ? ?9 +++++++--
> > ?1 files changed, 7 insertions(+), 2 deletions(-)
>
> Any blockers to get this accepted?
It would be nice to get an ack from someone who can actually test
the driver before getting this merged.
> /Esben
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: 82xx multiple soc support/initialization
From: Scott Wood @ 2009-05-26 20:25 UTC (permalink / raw)
To: Carl-Erwin GRIFFITH; +Cc: linuxppc-dev
In-Reply-To: <5c90346a0905250723t2c9d30a0qd4fbebed38917cd7@mail.gmail.com>
On Mon, May 25, 2009 at 04:23:37PM +0200, Carl-Erwin GRIFFITH wrote:
> Hi guys,
>
>
> I'm working on an derived muas3001 board (kernel version 2.6.30-rc5),
>
> and so far I did not find an example of multiple SOCs initialization.
>
> The board has 3 cpus (only one core activated).
This is not currently supported -- there are lots of places, especially
in 82xx/CPM code, that assume there's only one instance of the SoC.
> 1) Is there a special syntax to use in the device tree ?
You'd have multiple instances of the soc node (plus kernel changes to
make this work). You'll probably need some way of indicating which one
contains the running core.
-Scott
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 2/5] Main rewite of the mpc5200 audio DMA code
From: Mark Brown @ 2009-05-26 20:21 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <ed82fe3e0905261008n68672c6dk7bfc99e4cd614747@mail.gmail.com>
On Tue, May 26, 2009 at 12:08:01PM -0500, Timur Tabi wrote:
> It won't be that simple. V9 of my patch changes the number of
> parameters, so not only will you need to whack this copy of the macro,
> you'll also need to change the callers.
OK, in the interests of cutting down on the amount of review here I've
applied v5 of the series and then marked the AC97 machine drivers as
BROKEN for the time being - once everything lands in mainline we can
make sure that the driver is in sync with the final spin_event_timeout()
API and remove the BROKEN marking.
^ permalink raw reply
* Re: [PATCH 1/2] [PATCH 1/2 v9] powerpc: introduce macro spin_event_timeout()
From: Geoff Thorpe @ 2009-05-26 19:25 UTC (permalink / raw)
To: Timur Tabi; +Cc: arnd, linuxppc-dev, geert.uytterhoeven
In-Reply-To: <1243351302-32062-2-git-send-email-timur@freescale.com>
Acked-by: Geoff Thorpe <Geoff.Thorpe@freescale.com>
Not sure that it's the most consistent formulation, but it's definitely
better than debating indefinitely.
Cheers,
Geoff
Timur Tabi wrote:
> The macro spin_event_timeout() takes a condition and timeout value
> (in microseconds) as parameters. It spins until either the condition is true
> or the timeout expires. It returns the result of the condition when the loop
> was terminated.
>
> This primary purpose of this macro is to poll on a hardware register until a
> status bit changes. The timeout ensures that the loop still terminates if the
> bit doesn't change as expected. This macro makes it easier for driver
> developers to perform this kind of operation properly.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> v9: changed the macro to return the value, instead of having it passed in
[snip]
^ permalink raw reply
* Re: [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()
From: Jon Smirl @ 2009-05-26 19:04 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Geoff Thorpe, smaclennan
In-Reply-To: <4A1C3230.8030009@freescale.com>
On Tue, May 26, 2009 at 2:17 PM, Timur Tabi <timur@freescale.com> wrote:
> Geoff Thorpe wrote:
>
>> rc =3D spin_event_timeout((ret =3D in_be32(x) & 0x14), ...);
>
> It's an interesting idea, but I have two problems with it:
>
> 1) This approach is that it depends on the internals of the macro. =A0Tha=
t is, you're sneaking in an assignment in the hopes that the code will beha=
ve properly. =A0You see that the current code evaluates the condition only =
once, so it works. =A0The code will look like this:
>
> 2) Unlike the wait_event_xxx macros, I believe that the actual evaluated =
expression is important to the caller. =A0So 90% of the time, the caller is=
going to pass in "ret =3D (condition)", which means it makes more sense to=
have this as a built-in feature of the macro.
The only time you need the result is when you are waiting on multiple
bits. I don't think looping while waiting on multiple bits is the
common case.
> So if you're okay with v9 of the patch, please ACK it.
I'll ACK ths so that I can get my driver in. But every time I used
this function I got it wrong on the first try. This is going to be a
source of bugs.
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-05-26 18:17 UTC (permalink / raw)
To: Geoff Thorpe; +Cc: linuxppc-dev, smaclennan
In-Reply-To: <4A1C3059.40303@freescale.com>
Geoff Thorpe wrote:
> rc = spin_event_timeout((ret = in_be32(x) & 0x14), ...);
It's an interesting idea, but I have two problems with it:
1) This approach is that it depends on the internals of the macro. That is, you're sneaking in an assignment in the hopes that the code will behave properly. You see that the current code evaluates the condition only once, so it works. The code will look like this:
2) Unlike the wait_event_xxx macros, I believe that the actual evaluated expression is important to the caller. So 90% of the time, the caller is going to pass in "ret = (condition)", which means it makes more sense to have this as a built-in feature of the macro.
So if you're okay with v9 of the patch, please ACK it.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] RFC: powerpc: expose the multi-bit ops that underlie single-bit ops.
From: Geoff Thorpe @ 2009-05-26 18:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geoff Thorpe
NOT FOR COMMIT, THIS IS A REQUEST FOR FEEDBACK.
The bitops.h functions that operate on a single bit in a bitfield are
implemented by operating on the corresponding word location. In all cases
the inner logic appears to be valid if the mask being applied has more
than one bit set, so this patch exposes those inner operations. Indeed,
set_bits() was already available, but it duplicated code from set_bit()
(rather than making the latter a wrapper) - it was also missing the
PPC405_ERR77() workaround and the "volatile" address qualifier present in
other APIs. This corrects that, and exposes the other multi-bit
equivalents.
One advantage of these multi-bit forms is that they allow word-sized
variables to essentially be their own spinlocks.
NB, the same factoring is possible in asm-generic/bitops/[non-]atomic.h.
I would be happy to provide corresponding patches if this approach is
deemed appropriate. Feedback would be most welcome.
Signed-off-by: Geoff Thorpe <Geoff.Thorpe@freescale.com>
---
arch/powerpc/include/asm/bitops.h | 111 +++++++++++++++++++++++--------------
1 files changed, 69 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/include/asm/bitops.h b/arch/powerpc/include/asm/bitops.h
index 897eade..72de28c 100644
--- a/arch/powerpc/include/asm/bitops.h
+++ b/arch/powerpc/include/asm/bitops.h
@@ -56,11 +56,10 @@
#define BITOP_WORD(nr) ((nr) / BITS_PER_LONG)
#define BITOP_LE_SWIZZLE ((BITS_PER_LONG-1) & ~0x7)
-static __inline__ void set_bit(int nr, volatile unsigned long *addr)
+static __inline__ void set_bits(unsigned long mask, volatile unsigned long *_p)
{
unsigned long old;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
+ unsigned long *p = (unsigned long *)_p;
__asm__ __volatile__(
"1:" PPC_LLARX "%0,0,%3 # set_bit\n"
@@ -73,11 +72,16 @@ static __inline__ void set_bit(int nr, volatile unsigned long *addr)
: "cc" );
}
-static __inline__ void clear_bit(int nr, volatile unsigned long *addr)
+static __inline__ void set_bit(int nr, volatile unsigned long *addr)
+{
+ set_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr));
+}
+
+static __inline__ void clear_bits(unsigned long mask,
+ volatile unsigned long *_p)
{
unsigned long old;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
+ unsigned long *p = (unsigned long *)_p;
__asm__ __volatile__(
"1:" PPC_LLARX "%0,0,%3 # clear_bit\n"
@@ -90,11 +94,16 @@ static __inline__ void clear_bit(int nr, volatile unsigned long *addr)
: "cc" );
}
-static __inline__ void clear_bit_unlock(int nr, volatile unsigned long *addr)
+static __inline__ void clear_bit(int nr, volatile unsigned long *addr)
+{
+ clear_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr));
+}
+
+static __inline__ void clear_bits_unlock(unsigned long mask,
+ volatile unsigned long *_p)
{
unsigned long old;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
+ unsigned long *p = (unsigned long *)_p;
__asm__ __volatile__(
LWSYNC_ON_SMP
@@ -108,11 +117,16 @@ static __inline__ void clear_bit_unlock(int nr, volatile unsigned long *addr)
: "cc", "memory");
}
-static __inline__ void change_bit(int nr, volatile unsigned long *addr)
+static __inline__ void clear_bit_unlock(int nr, volatile unsigned long *addr)
+{
+ clear_bits_unlock(BITOP_MASK(nr), addr + BITOP_WORD(nr));
+}
+
+static __inline__ void change_bits(unsigned long mask,
+ volatile unsigned long *_p)
{
unsigned long old;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
+ unsigned long *p = (unsigned long *)_p;
__asm__ __volatile__(
"1:" PPC_LLARX "%0,0,%3 # change_bit\n"
@@ -125,12 +139,16 @@ static __inline__ void change_bit(int nr, volatile unsigned long *addr)
: "cc" );
}
-static __inline__ int test_and_set_bit(unsigned long nr,
- volatile unsigned long *addr)
+static __inline__ void change_bit(int nr, volatile unsigned long *addr)
+{
+ change_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr));
+}
+
+static __inline__ unsigned long test_and_set_bits(unsigned long mask,
+ volatile unsigned long *_p)
{
unsigned long old, t;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
+ unsigned long *p = (unsigned long *)_p;
__asm__ __volatile__(
LWSYNC_ON_SMP
@@ -144,15 +162,21 @@ static __inline__ int test_and_set_bit(unsigned long nr,
: "r" (mask), "r" (p)
: "cc", "memory");
- return (old & mask) != 0;
+ return (old & mask);
}
-static __inline__ int test_and_set_bit_lock(unsigned long nr,
+static __inline__ int test_and_set_bit(unsigned long nr,
volatile unsigned long *addr)
{
+ return test_and_set_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr)) != 0;
+}
+
+static __inline__ unsigned long test_and_set_bits_lock(
+ unsigned long mask,
+ volatile unsigned long *_p)
+{
unsigned long old, t;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
+ unsigned long *p = (unsigned long *)_p;
__asm__ __volatile__(
"1:" PPC_LLARX "%0,0,%3 # test_and_set_bit_lock\n"
@@ -165,15 +189,21 @@ static __inline__ int test_and_set_bit_lock(unsigned long nr,
: "r" (mask), "r" (p)
: "cc", "memory");
- return (old & mask) != 0;
+ return (old & mask);
}
-static __inline__ int test_and_clear_bit(unsigned long nr,
- volatile unsigned long *addr)
+static __inline__ int test_and_set_bit_lock(unsigned long nr,
+ volatile unsigned long *addr)
+{
+ return test_and_set_bits_lock(BITOP_MASK(nr),
+ addr + BITOP_WORD(nr)) != 0;
+}
+
+static __inline__ unsigned long test_and_clear_bits(unsigned long mask,
+ volatile unsigned long *_p)
{
unsigned long old, t;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
+ unsigned long *p = (unsigned long *)_p;
__asm__ __volatile__(
LWSYNC_ON_SMP
@@ -187,15 +217,20 @@ static __inline__ int test_and_clear_bit(unsigned long nr,
: "r" (mask), "r" (p)
: "cc", "memory");
- return (old & mask) != 0;
+ return (old & mask);
}
-static __inline__ int test_and_change_bit(unsigned long nr,
- volatile unsigned long *addr)
+static __inline__ int test_and_clear_bit(unsigned long nr,
+ volatile unsigned long *addr)
+{
+ return test_and_clear_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr)) != 0;
+}
+
+static __inline__ unsigned long test_and_change_bits(unsigned long mask,
+ volatile unsigned long *_p)
{
unsigned long old, t;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
+ unsigned long *p = (unsigned long *)_p;
__asm__ __volatile__(
LWSYNC_ON_SMP
@@ -209,21 +244,13 @@ static __inline__ int test_and_change_bit(unsigned long nr,
: "r" (mask), "r" (p)
: "cc", "memory");
- return (old & mask) != 0;
+ return (old & mask);
}
-static __inline__ void set_bits(unsigned long mask, unsigned long *addr)
+static __inline__ int test_and_change_bit(unsigned long nr,
+ volatile unsigned long *addr)
{
- unsigned long old;
-
- __asm__ __volatile__(
-"1:" PPC_LLARX "%0,0,%3 # set_bits\n"
- "or %0,%0,%2\n"
- PPC_STLCX "%0,0,%3\n"
- "bne- 1b"
- : "=&r" (old), "+m" (*addr)
- : "r" (mask), "r" (addr)
- : "cc");
+ return test_and_change_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr)) != 0;
}
#include <asm-generic/bitops/non-atomic.h>
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()
From: Geoff Thorpe @ 2009-05-26 18:09 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Geoff Thorpe, smaclennan
In-Reply-To: <4A1C20EA.5080603@freescale.com>
Timur Tabi wrote:
> Geoff Thorpe wrote:
>
>> So from this user's perspective (FWIW), it would come as a surprise if
>> the return value reflected the evaluated expression rather than what
>> happened w.r.t. the spin/timeout.
>
> It shouldn't come as a surprise because I've thoroughly documented the behavior. I also think returning the actual value of the expression is better than a return code. Remember, the primary purpose of this macro is to wait for a hardware register to change. Contrast this to wait_event_xxx, which usually queries a variable. Therefore, the hardware register may set multiple bits. For instance, you could do this:
>
> ret = spin_event_timeout(in_be32(x) & 0x14, ...);
>
> if (ret & 0x10)
> do something here
>
> if (ret & 0x04)
> do something else here
>
> I think the ability to do this is more important than making the code as similar as possible to wait_event_xxx.
I was just providing feedback after (recently) coming to grips with the
subtleties of similar assists in the kernel. Documentation helps when
you don't know what to expect - but if you're expecting a certain
behaviour (consistency of success==0), it's easy to misread the doc, or
just not read it at all.
BTW, your example above does not illustrate the use of the timeout, and
you'd have to infer it because the return value does not provide any
direct indication. As for access to the evaluated expression, I believe
the following is functionally equivalent;
rc = spin_event_timeout((ret = in_be32(x) & 0x14), ...);
You can ignore the return value if you don't care, which gives the same
thing as your original example, but with the 'ret' assignment inside the
spin call instead of outside it.
Anyway, just my $0.02 FWIW. I have no strongly-held opinion here,
especially as the closest precedent I know of is wait_event_timeout(),
which also does something unexpected, but it doesn't do the same
unexpected thing as your function does. :-) It's based on jiffies rather
than microseconds, and it returns zero if the timeout elapses otherwise
it returns the number of remaining jiffies when the condition evaluated
true.
Cheers,
Geoff
^ permalink raw reply
* Re: [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-05-26 18:01 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, Geoff Thorpe, smaclennan
In-Reply-To: <9e4733910905261056v7a1a8e77ie6f273820ce1fd3e@mail.gmail.com>
Jon Smirl wrote:
> Then if I don't care about the result (which I think is the common case)...
>
> rc = spin_event_timeout(in_be32(x) & 0x14, ...);
> if (rc)
> timeout_happened;
That's another way of doing it, but I'm already at version 9 of my patch, and I'm not inclined to make any changes that don't add any real functionality. Every time I post a new version of this patch, someone new comes out of the woodwork to tell me that I should do it a different way. Where were you two months ago?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()
From: Jon Smirl @ 2009-05-26 17:56 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Geoff Thorpe, smaclennan
In-Reply-To: <4A1C20EA.5080603@freescale.com>
On Tue, May 26, 2009 at 1:03 PM, Timur Tabi <timur@freescale.com> wrote:
> Geoff Thorpe wrote:
>
>> So from this user's perspective (FWIW), it would come as a surprise if
>> the return value reflected the evaluated expression rather than what
>> happened w.r.t. the spin/timeout.
>
> It shouldn't come as a surprise because I've thoroughly documented the be=
havior. =A0I also think returning the actual value of the expression is bet=
ter than a return code. =A0Remember, the primary purpose of this macro is t=
o wait for a hardware register to change. =A0Contrast this to wait_event_xx=
x, which usually queries a variable. =A0Therefore, the hardware register ma=
y set multiple bits. =A0For instance, you could do this:
>
> ret =3D spin_event_timeout(in_be32(x) & 0x14, ...);
>
> if (ret & 0x10)
> =A0 =A0 =A0 =A0do something here
>
> if (ret & 0x04)
> =A0 =A0 =A0 =A0do something else here
If (ret =3D=3D 0)
timeout_happened;
That's the part that looks wrong.
>
> I think the ability to do this is more important than making the code as =
similar as possible to wait_event_xxx.
Why not this?
rc =3D spin_event_timeout(result =3D (in_be32(x) & 0x14), ...);
if (rc)
timeout_happened;
if (result & 0x10)
do something here
if (result & 0x04)
do something else here
Then if I don't care about the result (which I think is the common case)...
rc =3D spin_event_timeout(in_be32(x) & 0x14, ...);
if (rc)
timeout_happened;
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] Display processor virtualization resource allocations in lparcfg
From: Nathan Fontenot @ 2009-05-26 17:59 UTC (permalink / raw)
To: linuxppc-dev
This patch updates the output from /proc/ppc64/lparcfg to display the
processor virtualization resource allocations for a shared processor
partition.
This information is already gathered via the h_get_ppp call, we just
have to make sure that the ibm,partition-performance-parameters-level
property is >= 1 to ensure that the information is valid.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
---
Index: linux-2.6/arch/powerpc/kernel/lparcfg.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/lparcfg.c 2009-05-21 10:24:57.000000000 -0500
+++ linux-2.6/arch/powerpc/kernel/lparcfg.c 2009-05-26 11:06:59.000000000 -0500
@@ -169,6 +169,9 @@
u8 unallocated_weight;
u16 active_procs_in_pool;
u16 active_system_procs;
+ u16 phys_platform_procs;
+ u32 max_proc_cap_avail;
+ u32 entitled_proc_cap_avail;
};
/*
@@ -190,13 +193,18 @@
* XX - Unallocated Variable Processor Capacity Weight.
* XXXX - Active processors in Physical Processor Pool.
* XXXX - Processors active on platform.
+ * R8 (QQQQRRRRRRSSSSSS). if ibm,partition-performance-parameters-level >= 1
+ * XXXX - Physical platform procs allocated to virtualization.
+ * XXXXXX - Max procs capacity % available to the partitions pool.
+ * XXXXXX - Entitled procs capacity % available to the
+ * partitions pool.
*/
static unsigned int h_get_ppp(struct hvcall_ppp_data *ppp_data)
{
unsigned long rc;
- unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+ unsigned long retbuf[PLPAR_HCALL9_BUFSIZE];
- rc = plpar_hcall(H_GET_PPP, retbuf);
+ rc = plpar_hcall9(H_GET_PPP, retbuf);
ppp_data->entitlement = retbuf[0];
ppp_data->unallocated_entitlement = retbuf[1];
@@ -210,6 +218,10 @@
ppp_data->active_procs_in_pool = (retbuf[3] >> 2 * 8) & 0xffff;
ppp_data->active_system_procs = retbuf[3] & 0xffff;
+ ppp_data->phys_platform_procs = retbuf[4] >> 6 * 8;
+ ppp_data->max_proc_cap_avail = (retbuf[4] >> 3 * 8) & 0xffffff;
+ ppp_data->entitled_proc_cap_avail = retbuf[4] & 0xffffff;
+
return rc;
}
@@ -234,6 +246,8 @@
static void parse_ppp_data(struct seq_file *m)
{
struct hvcall_ppp_data ppp_data;
+ struct device_node *root;
+ const int *perf_level;
int rc;
rc = h_get_ppp(&ppp_data);
@@ -267,6 +281,28 @@
seq_printf(m, "capped=%d\n", ppp_data.capped);
seq_printf(m, "unallocated_capacity=%lld\n",
ppp_data.unallocated_entitlement);
+
+ /* The last bits of information returned from h_get_ppp are only
+ * valid if the ibm,partition-performance-parameters-level
+ * property is >= 1.
+ */
+ root = of_find_node_by_path("/");
+ if (root) {
+ perf_level = of_get_property(root,
+ "ibm,partition-performance-parameters-level",
+ NULL);
+ if (*perf_level >= 1) {
+ seq_printf(m,
+ "physical_procs_allocated_to_virtualization=%d\n",
+ ppp_data.phys_platform_procs);
+ seq_printf(m, "max_proc_capacity_available=%d\n",
+ ppp_data.max_proc_cap_avail);
+ seq_printf(m, "entitled_proc_capacity_available=%d\n",
+ ppp_data.entitled_proc_cap_avail);
+ }
+
+ of_node_put(root);
+ }
}
/**
^ permalink raw reply
* Re: Wrong looking statement in cpm_common.c
From: Scott Wood @ 2009-05-26 17:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1243224033.24376.18.camel@pasglop>
On Mon, May 25, 2009 at 02:00:33PM +1000, Benjamin Herrenschmidt wrote:
> Hi Scott !
>
> There's this pearl in cpm_common.c :
>
> void __init udbg_init_cpm(void)
> {
> if (cpm_udbg_txdesc) {
> #ifdef CONFIG_CPM2
> setbat(1, 0xf0000000, 0xf0000000, 1024*1024, PAGE_KERNEL_NCG);
> #endif
> udbg_putc = udbg_putc_cpm;
> }
> }
>
> Now, last I looked, 0xf0000000 (virtual) lands about right in the middle
> of the vmalloc space... so unless there's code somewhere that I missed
> that reserves that region of virtual space for use by that crap above,
> I think somebody is in trouble :-)
:-(
> Additionally, that's the last user of setbat that I can find outside
> of the linear mapping setup proper, so scott, once you've fixed that
> I'll happily make setbat static once for all. We -can- still provide
> a facility for using BATs for early ioremap's but that should be done
> properly, not by whacking setbat with random hard wired virtual
> addresses.
Any suggestions for how to do it properly?
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox