* Re: [PATCH v2] of: Change logic to overwrite cmd_line with CONFIG_CMDLINE
From: Benjamin Herrenschmidt @ 2012-01-10 9:10 UTC (permalink / raw)
To: Doug Anderson; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <CAD=FV=UVo-vCe-s9tdXq_Od3jJnJ58Nx=4f-S3XfWBfDhxoXMg@mail.gmail.com>
On Fri, 2012-01-06 at 16:48 -0800, Doug Anderson wrote:
> I know this is a long-dead thread, but I was a little curious about
> the motivation here.
Hi ! Sorry, I planned to reply earlier and then forgot about it...
> I'm looking at trying to support CONFIG_CMDLINE_EXTEND (an ARM
> Kconfig) in this function and don't know in which cases I should look
> at the CONFIG_CMDLINE and in which cases I should use whatever
> happened to be in data before the function was called.
I'll have a look later (gotta run soon) but basically, the reason I did
that logic change is that in some specific circumstances and firmware
version, I end up writing the user-specified command line in the global
prior to actually booting the kernel :-)
So in that case, I really don't want CONFIG_CMDLINE to take over because
there's nothing in the device-tree, the user -did- specify something but
not via the device-tree.
Now, that's a bit of an oddball scenario but I felt that the logic
change was harmless.
For those interested in gory details, it's when doing the OPAL takeover
on some machines with the version 1 of OPAL firmware. We basically boot
under pHyp normally (pSeries hypervisor) and do a magic hcall which
relocates the kernel to contiguous physical memory and re-starts it with
a flat device-tree.
The takeover mechanism didn't provide me with a way for passing a
command line in that fdt. So I had to do it from prom_init (still
running under pHyp context), change the kernel global before it gets
relocated.
Cheers,
Ben.
> Here's the definition in the KConfig:
> <http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=arch/arm/Kconfig;h=24626b0419ee97e963e68329a8eb6769360b46ea;hb=HEAD#l1984>
>
> Which case do you have CONFIG_CMDLINE defined but not CMDLINE_FORCE?
> In those cases, do you happen to have CONFIG_CMDLINE_EXTEND or
> CMDLINE_FROM_BOOTLOADER defined?
>
> Thanks much!
>
> -Doug
>
> ---
>
> On Mon, Sep 19, 2011 at 9:55 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> >
> > On Tue, Sep 20, 2011 at 02:50:15PM +1000, Benjamin Herrenschmidt wrote:
> > > We used to overwrite with CONFIG_CMDLINE if we found a chosen
> > > node but failed to get bootargs out of it or they were empty,
> > > unless CONFIG_CMDLINE_FORCE is set.
> > >
> > > Instead change that to overwrite if "data" is non empty after
> > > the bootargs check. It allows arch code to have other mechanisms
> > > to retrieve the command line prior to parsing the device-tree.
> > >
> > > Note: CONFIG_CMDLINE_FORCE case should ideally be handled elsewhere
> > > as it won't work as it-is if the device-tree has no /chosen node
> > >
> > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > CC: devicetree-discuss@lists-ozlabs.org
> > > CC: Grant Likely <grant.likely@secretlab.ca>
> >
> > Looks okay to me.
> >
> > Acked-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > > ---
> > > drivers/of/fdt.c | 7 ++++++-
> > > 1 files changed, 6 insertions(+), 1 deletions(-)
> > >
> > > v2. Use "data" instead of "cmd_line" so it works on archs like
> > > mips who don't pass cmd_line to that function to start with, also
> > > add a comment explaining the mechanism.
> > >
> > > (resent with right list address as well while at it)
> > >
> > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > > index 65200af..323b722 100644
> > > --- a/drivers/of/fdt.c
> > > +++ b/drivers/of/fdt.c
> > > @@ -681,9 +681,14 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
> > > if (p != NULL && l > 0)
> > > strlcpy(data, p, min((int)l, COMMAND_LINE_SIZE));
> > >
> > > + /*
> > > + * CONFIG_CMDLINE is meant to be a default in case nothing else
> > > + * managed to set the command line, unless CONFIG_CMDLINE_FORCE
> > > + * is set in which case we override whatever was found earlier.
> > > + */
> > > #ifdef CONFIG_CMDLINE
> > > #ifndef CONFIG_CMDLINE_FORCE
> > > - if (p == NULL || l == 0 || (l == 1 && (*p) == 0))
> > > + if (!data[0])
> > > #endif
> > > strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> > > #endif /* CONFIG_CMDLINE */
> > > --
> > > 1.7.4.1
> > >
> > >
> > >
> > >
> > _______________________________________________
> > devicetree-discuss mailing list
> > devicetree-discuss@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* Re: [PATCH v2 0/3] ppc32/kprobe: Fix a bug for kprobe stwu r1
From: tiejun.chen @ 2012-01-10 9:15 UTC (permalink / raw)
To: Tiejun Chen; +Cc: linuxppc-dev
In-Reply-To: <1323946810-4868-1-git-send-email-tiejun.chen@windriver.com>
Tiejun Chen wrote:
> Changes from V1:
>
> * use memcpy simply to withdraw copy_exc_stack
> * add !(regs->msr & MSR_PR)) and
> WARN_ON(test_thread_flag(TIF_EMULATE_STACK_STORE));
> to make sure we're in goot path.
> * move this migration process inside 'restore'
> * clear TIF flag atomically
Ben,
Is this series OK?
Thanks
Tiejun
>
> Tiejun Chen (3):
> powerpc/kprobe: introduce a new thread flag
> ppc32/kprobe: complete kprobe and migrate exception frame
> ppc32/kprobe: don't emulate store when kprobe stwu r1
>
> arch/powerpc/include/asm/thread_info.h | 3 ++
> arch/powerpc/kernel/entry_32.S | 35 ++++++++++++++++++++++++++++++++
> arch/powerpc/lib/sstep.c | 25 +++++++++++++++++++++-
> 3 files changed, 61 insertions(+), 2 deletions(-)
>
> Tiejun
^ permalink raw reply
* Mac address in the DT
From: smitha.vanga @ 2012-01-10 9:37 UTC (permalink / raw)
To: wd; +Cc: scottwood, linuxppc-dev
In-Reply-To: <20120109224027.A8B591167AA4@gemini.denx.de>
Hi,
The fdt_fixup_ethernet() is not supported in the older version of u-boot. So=
how to go about it in u-boot 1.3.0 version.
Regards,
Smitha
Please do not print this email unless it is absolutely necessary. =0A=
=0A=
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and may=
contain proprietary, confidential or privileged information. If you are not=
the intended recipient, you should not disseminate, distribute or copy this=
e-mail. Please notify the sender immediately and destroy all copies of this=
message and any attachments. =0A=
=0A=
WARNING: Computer viruses can be transmitted via email. The recipient should=
check this email and any attachments for the presence of viruses. The compa=
ny accepts no liability for any damage caused by any virus transmitted by th=
is email. =0A=
=0A=
www.wipro.com
^ permalink raw reply
* Re: Mac address in the DT
From: Joakim Tjernlund @ 2012-01-10 9:47 UTC (permalink / raw)
To: smitha.vanga; +Cc: scottwood, linuxppc-dev, wd
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE01D3F2@HYD-MKD-MBX4.wipro.com>
<smitha.vanga@wipro.com> wrote on 2012/01/10 10:37:14:
>
>
> Hi,
>
> The fdt_fixup_ethernet() is not supported in the older version of u-boot. So how to go about it in u-boot 1.3.0 version.
Upgrade or find out how its done in your older version, I have no idea.
^ permalink raw reply
* [PATCH 2/3] driver/misc: Add Pulse Width Modulator (PWM) driver for freescale
From: Chunhe Lan @ 2012-01-10 10:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Chunhe Lan
In-Reply-To: <1326191203-11207-1-git-send-email-Chunhe.Lan@freescale.com>
The PSC913x PWM with the following features:
* 12-bit prescaler for division of clock
* Active-high or active-low configured output
* Interrupts at compare and roll-over
* Programmable pulse width (duty cycle) and interval (period cycle)
A sysfs interface is provided to control the PWM output:
* Set duty cycle and period cycle
echo 1000 > /sys/devices/soc.0/e500.2/ff713000.pwm/duty_ns
echo 5000 > /sys/devices/soc.0/e500.2/ff713000.pwm/period_ns
* Show duty cycle and period cycle
cat /sys/devices/soc.0/e500.2/ff713000.pwm/duty_ns
cat /sys/devices/soc.0/e500.2/ff713000.pwm/period_ns
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
---
arch/powerpc/include/asm/fsl_pwm.h | 111 +++++++++
drivers/misc/Kconfig | 11 +
drivers/misc/Makefile | 1 +
drivers/misc/fsl_pwm.c | 471 ++++++++++++++++++++++++++++++++++++
4 files changed, 594 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsl_pwm.h
create mode 100644 drivers/misc/fsl_pwm.c
diff --git a/arch/powerpc/include/asm/fsl_pwm.h b/arch/powerpc/include/asm/fsl_pwm.h
new file mode 100644
index 0000000..a6d3bf5
--- /dev/null
+++ b/arch/powerpc/include/asm/fsl_pwm.h
@@ -0,0 +1,111 @@
+/*
+ * Freescale PWM Register Definitions
+ *
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Author: Chunhe Lan <Chunhe.Lan@freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __ARCH_FSL_PWM_H
+#define __ARCH_FSL_PWM_H
+
+#define FSL_PWMCR_STOPEN (1 << 25)
+#define FSL_PWMCR_DOZEEN (1 << 24)
+#define FSL_PWMCR_WAITEN (1 << 23)
+#define FSL_PWMCR_DEBUGEN (1 << 22)
+#define FSL_PWMCR_BCTR (1 << 21)
+#define FSL_PWMCR_HCTR (1 << 20)
+#define FSL_PWMCR_POUTC_HIGHT (0 << 18)
+#define FSL_PWMCR_POUTC_LOW (1 << 18)
+#define FSL_PWMCR_CLKSRC (1 << 16)
+#define FSL_PWMCR_PRESCALER(x) (((x - 1) & 0xFFF) << 4)
+#define FSL_MAX_PRESCALER 0x00000FFF
+#define FSL_PWMCR_SWR (1 << 3)
+#define FSL_PWMCR_REPEAT_ONE (0 << 1)
+#define FSL_PWMCR_REPEAT_TWO (1 << 1)
+#define FSL_PWMCR_REPEAT_FOUR (2 << 1)
+#define FSL_PWMCR_REPEAT_EIGHT (3 << 1)
+#define FSL_PWMCR_EN (1 << 0)
+
+#define FSL_PWMSR_ALL_MASK 0x0000007F
+#define FSL_PWMSR_FWE_CMP_ROV_MASK 0x00000070
+#define FSL_PWMSR_FWE (1 << 6)
+#define FSL_PWMSR_CMP (1 << 5)
+#define FSL_PWMSR_ROV (1 << 4)
+#define FSL_PWMSR_FE (1 << 3)
+#define FSL_PWMSR_FIFOAV (7 << 0)
+
+#define FSL_PWMIR (7 << 0)
+#define FSL_PWMIR_CIE (1 << 2)
+#define FSL_PWMIR_RIE (1 << 1)
+#define FSL_PWMIR_FIE (1 << 0)
+
+#define FSL_PMUXCR1_SPI1_ANT_TCXO_PWM_GPIO (3 << 0)
+#define FSL_PMUXCR1_ANT_TCXO_PWM_GPIO (1 << 0)
+#define FSL_PMUXCR2_UART_PWM_GPIO (3 << 28)
+#define FSL_PMUXCR2_PWM_GPIO (1 << 28)
+
+#define FSL_DEVDISR2_PWM1 (1 << 23)
+#define FSL_DEVDISR2_PWM1_EN (0 << 23)
+#define FSL_DEVDISR2_PWM2 (1 << 22)
+#define FSL_DEVDISR2_PWM2_EN (0 << 22)
+
+#define FSL_DEFAULT_IPG_CLK 500000000 /* 500MHz */
+
+struct pwm_reg {
+ u32 pwmcr; /* PWM Control Register */
+ u32 pwmsr; /* PWM Status Register */
+ u32 pwmir; /* PWM Interrupt Register */
+ u32 pwmsar; /* PWM Sample Register */
+ u32 pwmpr; /* PWM Period Register */
+ u32 pwmcnr; /* PWM Counter Register */
+};
+
+struct pwm_device {
+ struct list_head node;
+ struct device dev;
+
+ const char *label;
+ struct clk *clk;
+ int clk_enabled;
+ struct pwm_reg __iomem *regs;
+ int irq;
+
+ unsigned int use_count;
+ unsigned int pwm_id;
+ int duty;
+ int period;
+ int pwmo_invert;
+ void (*enable_pwm_pad)(void);
+ void (*disable_pwm_pad)(void);
+};
+
+struct gubr {
+ u32 res24[0x18];
+ u32 pmuxcr1;
+ u32 pmuxcr2;
+ u32 res3[0x03];
+ u32 devdisr2;
+};
+
+extern int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
+extern int pwm_enable(struct pwm_device *pwm);
+extern void pwm_disable(struct pwm_device *pwm);
+extern struct pwm_device *pwm_request(int pwm_id, const char *label);
+extern void pwm_free(struct pwm_device *pwm);
+
+#endif /* __ARCH_FSL_PWM_H */
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 5664696..fbb72df 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -509,4 +509,15 @@ source "drivers/misc/lis3lv02d/Kconfig"
source "drivers/misc/carma/Kconfig"
source "drivers/misc/altera-stapl/Kconfig"
+ config FSL_PWM
+ bool "Freescale PWM support"
+ select PPC_CLOCK
+ default n
+ help
+ This option enables device driver support for the PWM channels
+ on certain Freescale processors(e.g. PSC9131RDB). Pulse Width
+ Modulation is used for purposes including software controlled
+ power-efficient backlights on LCD displays, motor control, and
+ waveform generation and so on.
+
endif # MISC_DEVICES
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index b26495a..b3e0dd4 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_AD525X_DPOT_I2C) += ad525x_dpot-i2c.o
obj-$(CONFIG_AD525X_DPOT_SPI) += ad525x_dpot-spi.o
obj-$(CONFIG_INTEL_MID_PTI) += pti.o
obj-$(CONFIG_ATMEL_PWM) += atmel_pwm.o
+obj-$(CONFIG_FSL_PWM) += fsl_pwm.o
obj-$(CONFIG_ATMEL_SSC) += atmel-ssc.o
obj-$(CONFIG_ATMEL_TCLIB) += atmel_tclib.o
obj-$(CONFIG_BMP085) += bmp085.o
diff --git a/drivers/misc/fsl_pwm.c b/drivers/misc/fsl_pwm.c
new file mode 100644
index 0000000..cfe2002
--- /dev/null
+++ b/drivers/misc/fsl_pwm.c
@@ -0,0 +1,471 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * PWM (Pulse Width Modulator) controller driver
+ *
+ * Author: Chunhe Lan <Chunhe.Lan@freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/interrupt.h>
+#include <linux/err.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/pwm.h>
+#include <linux/of_platform.h>
+#include <sysdev/fsl_soc.h>
+#include <asm/fsl_pwm.h>
+#include <asm/clock.h>
+#include <asm/prom.h>
+
+static DEFINE_MUTEX(pwm_lock);
+static LIST_HEAD(pwm_list);
+
+static ssize_t show_duty_ns(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct pwm_device *pwm = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%u\n", pwm->duty);
+}
+
+static ssize_t show_period_ns(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct pwm_device *pwm = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%u\n", pwm->period);
+}
+
+static ssize_t store_duty_ns(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct pwm_device *pwm = dev_get_drvdata(dev);
+ unsigned long val;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ mutex_lock(&pwm_lock);
+
+ pwm->duty = (int)val;
+ if ((pwm->duty < pwm->period) || (pwm->duty == pwm->period)) {
+ pwm_disable(pwm);
+ pwm_config(pwm, pwm->duty, pwm->period);
+ pwm_enable(pwm);
+ }
+
+ mutex_unlock(&pwm_lock);
+
+ return count;
+}
+
+static ssize_t store_period_ns(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct pwm_device *pwm = dev_get_drvdata(dev);
+ unsigned long val;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ mutex_lock(&pwm_lock);
+
+ pwm->period = (int)val;
+ if ((pwm->duty < pwm->period) || (pwm->duty == pwm->period)) {
+ pwm_disable(pwm);
+ pwm_config(pwm, pwm->duty, pwm->period);
+ pwm_enable(pwm);
+ }
+
+ mutex_unlock(&pwm_lock);
+
+ return count;
+}
+
+static DEVICE_ATTR(duty_ns, S_IRUGO | S_IWUSR,
+ show_duty_ns, store_duty_ns);
+static DEVICE_ATTR(period_ns, S_IRUGO | S_IWUSR,
+ show_period_ns, store_period_ns);
+
+static struct attribute *pwm_attrs[] = {
+ &dev_attr_duty_ns.attr,
+ &dev_attr_period_ns.attr,
+ NULL
+};
+
+static const struct attribute_group pwm_group = {
+ .attrs = pwm_attrs,
+};
+
+int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+{
+ unsigned long long c;
+ unsigned long period_cycles, duty_cycles, prescale;
+ u32 cr;
+
+ if (pwm == NULL || period_ns == 0 || duty_ns > period_ns)
+ return -EINVAL;
+
+ if (pwm->pwmo_invert)
+ duty_ns = period_ns - duty_ns;
+
+ c = clk_get_rate(pwm->clk);
+ c = c * period_ns;
+ do_div(c, 1000000000);
+ period_cycles = c;
+
+ prescale = period_cycles / 0x10000 + 1;
+ if (prescale > FSL_MAX_PRESCALER)
+ return -EINVAL;
+
+ period_cycles /= prescale;
+ c = (unsigned long long)period_cycles * duty_ns;
+ do_div(c, period_ns);
+ duty_cycles = c;
+
+ out_be32(&pwm->regs->pwmsar, duty_cycles);
+ out_be32(&pwm->regs->pwmpr, period_cycles);
+
+ cr = FSL_PWMCR_POUTC_HIGHT | FSL_PWMCR_CLKSRC | FSL_PWMCR_DOZEEN |
+ FSL_PWMCR_WAITEN | FSL_PWMCR_DEBUGEN | FSL_PWMCR_STOPEN;
+ cr |= FSL_PWMCR_PRESCALER(prescale);
+ out_be32(&pwm->regs->pwmcr, cr);
+
+ return 0;
+}
+EXPORT_SYMBOL(pwm_config);
+
+int pwm_enable(struct pwm_device *pwm)
+{
+ unsigned int reg;
+ int rc = 0;
+
+ if (!pwm->clk_enabled) {
+ rc = clk_enable(pwm->clk);
+ if (!rc)
+ pwm->clk_enabled = 1;
+ }
+
+ reg = in_be32(&pwm->regs->pwmcr);
+ reg |= FSL_PWMCR_EN;
+ out_be32(&pwm->regs->pwmcr, reg);
+
+ if (pwm->enable_pwm_pad)
+ pwm->enable_pwm_pad();
+
+ return rc;
+}
+EXPORT_SYMBOL(pwm_enable);
+
+void pwm_disable(struct pwm_device *pwm)
+{
+ unsigned int reg;
+
+ if (pwm->disable_pwm_pad)
+ pwm->disable_pwm_pad();
+
+ reg = in_be32(&pwm->regs->pwmcr);
+ reg &= ~FSL_PWMCR_EN;
+ out_be32(&pwm->regs->pwmcr, reg);
+
+ if (pwm->clk_enabled) {
+ clk_disable(pwm->clk);
+ pwm->clk_enabled = 0;
+ }
+}
+EXPORT_SYMBOL(pwm_disable);
+
+struct pwm_device *pwm_request(int pwm_id, const char *label)
+{
+ struct pwm_device *pwm;
+ int found = 0;
+
+ mutex_lock(&pwm_lock);
+
+ list_for_each_entry(pwm, &pwm_list, node) {
+ if (pwm->pwm_id == pwm_id) {
+ found = 1;
+ break;
+ }
+ }
+
+ if (found) {
+ if (pwm->use_count == 0) {
+ pwm->use_count++;
+ pwm->label = label;
+ } else
+ pwm = ERR_PTR(-EBUSY);
+ } else
+ pwm = ERR_PTR(-ENOENT);
+
+ mutex_unlock(&pwm_lock);
+ return pwm;
+}
+EXPORT_SYMBOL(pwm_request);
+
+void pwm_free(struct pwm_device *pwm)
+{
+ mutex_lock(&pwm_lock);
+
+ if (pwm->use_count) {
+ pwm->use_count--;
+ pwm->label = NULL;
+ } else
+ pr_warning("PWM device already freed\n");
+
+ mutex_unlock(&pwm_lock);
+}
+EXPORT_SYMBOL(pwm_free);
+
+static irqreturn_t fsl_pwm_irq(int irq, void *context_data)
+{
+ struct pwm_device *fsl_pwm = context_data;
+ u32 status;
+
+ /* Get interrupt events */
+ status = in_be32(&fsl_pwm->regs->pwmsr);
+
+ if (status) {
+ if (status & FSL_PWMSR_FWE)
+ dev_err(&fsl_pwm->dev, "FIFO write error occurred: "
+ "PWMSR 0x%08X\n", status);
+ if (status & FSL_PWMSR_CMP)
+ dev_err(&fsl_pwm->dev, "Compare event occurred: "
+ "PWMSR 0x%08X\n", status);
+ if (status & FSL_PWMSR_ROV)
+ dev_err(&fsl_pwm->dev, "Roll-over event occurred: "
+ "PWMSR 0x%08X\n", status);
+
+ if (status & ~FSL_PWMSR_ALL_MASK)
+ dev_err(&fsl_pwm->dev, "Unknown error: "
+ "PWMSR 0x%08X\n", status);
+
+ /* Clear the events */
+ out_be32(&fsl_pwm->regs->pwmsr, status &
+ FSL_PWMSR_FWE_CMP_ROV_MASK);
+ return IRQ_HANDLED;
+ }
+
+ return IRQ_NONE;
+}
+
+static int __devinit fsl_pwm_probe(struct platform_device *dev)
+{
+ struct device_node *np;
+ struct gubr __iomem *gubr;
+ struct pwm_device *fsl_pwm;
+ struct resource res_mem;
+ struct resource res_irq;
+ struct resource *res = &res_mem;
+ struct resource *irq = &res_irq;
+ const u32 *id;
+ int ret = 0;
+ unsigned long rate;
+
+ fsl_pwm = kzalloc(sizeof(struct pwm_device), GFP_KERNEL);
+ if (fsl_pwm == NULL) {
+ dev_err(&dev->dev, "failed to allocate memory\n");
+ return -ENOMEM;
+ }
+
+ ret = of_address_to_resource(dev->dev.of_node, 0, res);
+ if (ret) {
+ dev_err(&dev->dev, "invalid address\n");
+ goto err_free;
+ }
+
+ if (!request_mem_region(res->start,
+ res->end - res->start + 1, "fsl-pwm")) {
+ dev_err(&dev->dev, "memory request failure\n");
+ ret = -ENXIO;
+ goto err_free;
+ }
+
+ /* IOMAP the entire PWM region */
+ fsl_pwm->regs = ioremap(res->start, res->end - res->start + 1);
+ if (fsl_pwm->regs == NULL) {
+ dev_err(&dev->dev, "failed to ioremap memory region\n");
+ ret = -ENOMEM;
+ goto err_release;
+ }
+
+ fsl_pwm->clk = clk_get(&dev->dev, "pwm-clk");
+ if (IS_ERR(fsl_pwm->clk)) {
+ dev_err(&dev->dev, "failed to get clock\n");
+ ret = PTR_ERR(fsl_pwm->clk);
+ goto err_unmap;
+ }
+
+ rate = fsl_get_sys_freq();
+ if (rate)
+ fsl_pwm->clk->rate_hz = rate;
+ else
+ fsl_pwm->clk->rate_hz = FSL_DEFAULT_IPG_CLK;
+
+ /* Find the id of the pwm */
+ id = of_get_property(dev->dev.of_node, "cell-index", NULL);
+ if (!id) {
+ dev_err(&dev->dev, "failed to get cell-index\n");
+ goto err_unmap;
+ }
+
+ fsl_pwm->pwm_id = *id;
+ fsl_pwm->clk_enabled = 0;
+ fsl_pwm->use_count = 0;
+ fsl_pwm->duty = 0;
+ fsl_pwm->period = 0;
+ fsl_pwm->dev = dev->dev;
+
+ np = of_find_node_by_name(NULL, "global-utilities");
+ if (np) {
+ gubr = of_iomap(np, 0);
+
+ if (fsl_pwm->pwm_id) {
+ clrsetbits_be32(&gubr->pmuxcr2,
+ FSL_PMUXCR2_UART_PWM_GPIO,
+ FSL_PMUXCR2_PWM_GPIO);
+ clrsetbits_be32(&gubr->devdisr2, FSL_DEVDISR2_PWM2,
+ FSL_DEVDISR2_PWM2_EN);
+ } else {
+ clrsetbits_be32(&gubr->pmuxcr1,
+ FSL_PMUXCR1_SPI1_ANT_TCXO_PWM_GPIO,
+ FSL_PMUXCR1_ANT_TCXO_PWM_GPIO);
+ clrsetbits_be32(&gubr->devdisr2, FSL_DEVDISR2_PWM1,
+ FSL_DEVDISR2_PWM1_EN);
+ }
+
+ of_node_put(np);
+ } else {
+ printk(KERN_EMERG "Error: Global Utilities Block Register "
+ "node is not found!\n");
+ goto err_unmap;
+ }
+
+ ret = of_irq_to_resource(dev->dev.of_node, 0, irq);
+ if (ret == NO_IRQ) {
+ dev_warn(&dev->dev, "no IRQ found\n");
+ goto err_unmap;
+ }
+
+ fsl_pwm->irq = irq->start;
+ if (fsl_pwm->irq < 0) {
+ ret = -ENXIO;
+ goto err_unmap;
+ }
+
+ /* Register for PWM Interrupt */
+ ret = request_irq(fsl_pwm->irq, fsl_pwm_irq, 0, "fsl-pwm", fsl_pwm);
+ if (ret != 0)
+ goto err_unmap;
+ else
+ dev_info(&dev->dev,
+ "Freescale PWM Controller driver at 0x%p (irq = %d)\n",
+ fsl_pwm->regs, fsl_pwm->irq);
+
+ /* Register sysfs hooks */
+ ret = sysfs_create_group(&dev->dev.kobj, &pwm_group);
+ if (ret != 0)
+ goto err_unmap;
+
+ dev_set_drvdata(&dev->dev, fsl_pwm);
+
+ mutex_lock(&pwm_lock);
+ list_add_tail(&fsl_pwm->node, &pwm_list);
+ mutex_unlock(&pwm_lock);
+
+ return 0;
+
+err_unmap:
+ iounmap(fsl_pwm->regs);
+err_release:
+ release_mem_region(res->start, res->end - res->start + 1);
+err_free:
+ kfree(fsl_pwm);
+ return ret;
+}
+
+static int __devexit fsl_pwm_remove(struct platform_device *dev)
+{
+ struct pwm_device *fsl_pwm;
+
+ fsl_pwm = dev_get_drvdata(&dev->dev);
+ if (fsl_pwm == NULL)
+ return -ENODEV;
+
+ mutex_lock(&pwm_lock);
+ list_del(&fsl_pwm->node);
+ mutex_unlock(&pwm_lock);
+
+ if (fsl_pwm->regs)
+ iounmap(fsl_pwm->regs);
+
+ dev_set_drvdata(&dev->dev, NULL);
+ clk_put(fsl_pwm->clk);
+ sysfs_remove_group(&dev->dev.kobj, &pwm_group);
+ kfree(fsl_pwm);
+
+ return 0;
+}
+
+static const struct of_device_id fsl_pwm_match[] = {
+ {
+ .compatible = "fsl,psc9131-pwm",
+ },
+ {},
+};
+
+static struct platform_driver fsl_pwm_driver = {
+ .driver = {
+ .name = "fsl-pwm",
+ .of_match_table = fsl_pwm_match,
+ },
+ .probe = fsl_pwm_probe,
+ .remove = fsl_pwm_remove,
+};
+
+static int __init fsl_pwm_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&fsl_pwm_driver);
+ if (ret)
+ printk(KERN_ERR "fsl-pwm: Failed to register platform "
+ "driver\n");
+
+ return ret;
+}
+
+static void __exit fsl_pwm_exit(void)
+{
+ platform_driver_unregister(&fsl_pwm_driver);
+}
+
+module_init(fsl_pwm_init);
+module_exit(fsl_pwm_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Chunhe Lan <Chunhe.Lan@freescale.com>");
+MODULE_DESCRIPTION("Freescale PWM Controller driver");
--
1.5.6.5
^ permalink raw reply related
* [PATCH 1/3] powerpc/85xx: Add clock driver for PWM
From: Chunhe Lan @ 2012-01-10 10:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Chunhe Lan
Plugs into the generic powerpc clock driver in
arch/powerpc/kernel/clock.c
The following subset of clk_interface is implemented:
clk_get: get clock via name
clk_put: stubbed
clk_enable: enable clock
clk_disable: disable clock
clk_get_rate: get clock rate in Hz
clk_set_rate: NULL
clk_round_rate: NULL
clk_set_parent: NULL
clk_get_parent: NULL
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
---
arch/powerpc/include/asm/clock.h | 33 +++++++
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/pwm-clock.c | 161 +++++++++++++++++++++++++++++++
3 files changed, 195 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/clock.h
create mode 100644 arch/powerpc/platforms/85xx/pwm-clock.c
diff --git a/arch/powerpc/include/asm/clock.h b/arch/powerpc/include/asm/clock.h
new file mode 100644
index 0000000..98447eb
--- /dev/null
+++ b/arch/powerpc/include/asm/clock.h
@@ -0,0 +1,33 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Author: Chunhe Lan <Chunhe.Lan@freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+struct clk {
+ struct list_head node;
+ const char *name; /* unique clock name */
+ const char *function; /* function of the clock */
+ struct device *dev; /* device associated with function */
+ unsigned int id:2; /* clock identification */
+ unsigned long rate_hz;
+ struct clk *parent;
+ void (*mode)(struct clk *clk, int status);
+ u16 users;
+};
+
+extern int clk_register(struct clk *clk);
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index bc5acb9..ba0d0a9 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_P3041_DS) += p3041_ds.o corenet_ds.o
obj-$(CONFIG_P3060_QDS) += p3060_qds.o corenet_ds.o
obj-$(CONFIG_P4080_DS) += p4080_ds.o corenet_ds.o
obj-$(CONFIG_P5020_DS) += p5020_ds.o corenet_ds.o
+obj-$(CONFIG_FSL_PWM) += pwm-clock.o
obj-$(CONFIG_STX_GP3) += stx_gp3.o
obj-$(CONFIG_TQM85xx) += tqm85xx.o
obj-$(CONFIG_SBC8560) += sbc8560.o
diff --git a/arch/powerpc/platforms/85xx/pwm-clock.c b/arch/powerpc/platforms/85xx/pwm-clock.c
new file mode 100644
index 0000000..bba9872
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/pwm-clock.c
@@ -0,0 +1,161 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Implements the clk api defined in include/linux/clk.h
+ *
+ * Author: Chunhe Lan <Chunhe.Lan@freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/export.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/list.h>
+#include <linux/errno.h>
+#include <linux/err.h>
+#include <linux/spinlock.h>
+#include <linux/delay.h>
+#include <linux/clk.h>
+#include <linux/of_platform.h>
+#include <asm/clk_interface.h>
+#include <asm/clock.h>
+
+static LIST_HEAD(clocks);
+static DEFINE_SPINLOCK(clk_lock);
+
+static struct clk pwm_clk = {
+ .name = "pwm-clk",
+ .rate_hz = 0,
+ .users = 1, /* always on */
+ .id = 0,
+};
+
+static struct clk *all_clocks[] __initdata = {
+ &pwm_clk,
+};
+
+/* clocks cannot be de-registered no refcounting necessary */
+static struct clk *fsl_clk_get(struct device *dev, const char *id)
+{
+ struct clk *clk;
+
+ list_for_each_entry(clk, &clocks, node) {
+ if (strcmp(id, clk->name) == 0)
+ return clk;
+ }
+
+ return ERR_PTR(-ENOENT);
+}
+
+static void fsl_clk_put(struct clk *clk)
+{
+}
+
+static void __clk_enable(struct clk *clk)
+{
+ if (clk->parent)
+ __clk_enable(clk->parent);
+ if (clk->users++ == 0 && clk->mode)
+ clk->mode(clk, 1);
+}
+
+static int fsl_clk_enable(struct clk *clk)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&clk_lock, flags);
+ __clk_enable(clk);
+ spin_unlock_irqrestore(&clk_lock, flags);
+
+ return 0;
+}
+
+static void __clk_disable(struct clk *clk)
+{
+ BUG_ON(clk->users == 0);
+
+ if (--clk->users == 0 && clk->mode)
+ clk->mode(clk, 0);
+ if (clk->parent)
+ __clk_disable(clk->parent);
+}
+
+static void fsl_clk_disable(struct clk *clk)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&clk_lock, flags);
+ __clk_disable(clk);
+ spin_unlock_irqrestore(&clk_lock, flags);
+}
+
+static unsigned long fsl_clk_get_rate(struct clk *clk)
+{
+ unsigned long flags;
+ unsigned long rate;
+
+ spin_lock_irqsave(&clk_lock, flags);
+ for (;;) {
+ rate = clk->rate_hz;
+ if (rate || !clk->parent)
+ break;
+ clk = clk->parent;
+ }
+ spin_unlock_irqrestore(&clk_lock, flags);
+
+ return rate;
+}
+
+static struct clk_interface fsl_clk_functions = {
+ .clk_get = fsl_clk_get,
+ .clk_put = fsl_clk_put,
+ .clk_enable = fsl_clk_enable,
+ .clk_disable = fsl_clk_disable,
+ .clk_get_rate = fsl_clk_get_rate,
+};
+
+/* Register a new clock */
+int clk_register(struct clk *clk)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&clk_lock, flags);
+ list_add(&clk->node, &clocks);
+ spin_unlock_irqrestore(&clk_lock, flags);
+
+ return 0;
+}
+EXPORT_SYMBOL(clk_register);
+
+static int fsl_register_clocks(void)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(all_clocks); i++)
+ clk_register(all_clocks[i]);
+
+ return 0;
+}
+
+static int __init fsl_clk_init(void)
+{
+ fsl_register_clocks();
+ clk_functions = fsl_clk_functions;
+
+ return 0;
+}
+
+arch_initcall(fsl_clk_init);
--
1.5.6.5
^ permalink raw reply related
* [PATCH 3/3] powerpc/fsl: Document Pulse Width Modulator controller device tree binding
From: Chunhe Lan @ 2012-01-10 10:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Chunhe Lan
In-Reply-To: <1326191203-11207-1-git-send-email-Chunhe.Lan@freescale.com>
This document is created for freescale PWM node in dts file. In addition,
it explicates the properties and gives example about PWM node.
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
---
.../devicetree/bindings/powerpc/fsl/pwm.txt | 27 ++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/pwm.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pwm.txt b/Documentation/devicetree/bindings/powerpc/fsl/pwm.txt
new file mode 100644
index 0000000..92d68e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/pwm.txt
@@ -0,0 +1,27 @@
+=====================================================================
+Freescale Pulse Width Modulator Controller Node
+Copyright (C) 2012 Freescale Semiconductor Inc.
+=====================================================================
+
+Properties:
+
+- name : Should be pwm.
+- compatible : Should contain "fsl,psc9131-pwm".
+- cell-index : The cell index is the pwm controller serial number,
+ <0> = PWM1, <1> = PWM2, and so on.
+- #address-cells : Should be one.
+- #size-cells : Should be zero.
+- reg : Offset and length of the register set for the device.
+- interrupts : <interrupt mapping for PWM IRQ>
+
+Example:
+
+ pwm@13000 {
+ cell-index = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,psc9131-pwm";
+ reg = <0x13000 0x1000>;
+ interrupts = <44 2 0 0>;
+ interrupt-parent = <&mpic>;
+ };
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] powerpc/85xx: Add P1024rdb dts support
From: Scott Wood @ 2012-01-10 17:45 UTC (permalink / raw)
To: Tang Yuantian-B29983; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <D07C73A334FF604B95B3CBD2A545D07B02444B@039-SN2MPN1-013.039d.mgd.msft.net>
On 01/09/2012 09:45 PM, Tang Yuantian-B29983 wrote:
>
>> On 01/09/2012 02:37 AM, b29983@freescale.com wrote:
>>> +/include/ "p1024rdb.dtsi"
>>> +/include/ "fsl/p1020si-post.dtsi"
>>
>> Is p1024 100% software-compatible with p1020?
>>
>> They have different manuals...
>>
>> -Scott
>
> P1020rdb has vitesse-7385 switch.
I'm talking about the SoC, not the board.
> fsl/p1020si-post.dtsi can be used for both boards.
What are you basing this on? Has someone looked over both manuals in
detail and concluded that every device described is 100% compatible?
-Scott
^ permalink raw reply
* Re: OpenPIC warnings on P1022RDK AMP configuration
From: Scott Wood @ 2012-01-10 21:02 UTC (permalink / raw)
To: Arshad, Farrukh; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <93CD5F41FDBC6042A6B449764F3B35CC050CD17A@EU-MBX-03.mgc.mentorg.com>
On 01/10/2012 02:43 AM, Arshad, Farrukh wrote:
> Change kernel configuration as per following to fix this warning.
>=20
> =20
>=20
> Disable Kernel Options -> Support for enabling/disabling CPUs
>=20
> Disable Kernel Options -> Distribute interrupts on all CPUs by default
>=20
> =20
>=20
> Regards,
>=20
> Farrukh Arshad
>=20
> =20
>=20
> *From:*Arshad, Farrukh
> *Sent:* Friday, December 23, 2011 11:18 AM
> *To:* linuxppc-dev@lists.ozlabs.org
> *Subject:* OpenPIC warnings on P1022RDK AMP configuration
>=20
> =20
>=20
> Greetings All
>=20
> =20
>=20
> I am running dual linux on P1022RDK in AMP configuration. My memory
> partitioning is as below
>=20
> =20
>=20
> ---------------------------------------------------------------------
>=20
> Core | Base Address | Size |
>=20
> --------------------------|---------------|-------------------------|
>=20
> Core 0 (MEL RT Kernel) | 0x0000,0000 | 0x0C00,0000 - 192 (MB) |
>=20
> Core 1 (LTIB Kernel) |0x0C00,0000 | 0x1000,0000 - 256 (MB) |
>=20
> MCAPI - Shared Mem | 0x1C00,0000 | 0x0400,0000 - 64=20
> (MB) | =20
>=20
> ---------------------------------------------------------------------
>=20
> =20
>=20
> My kernel command lines are for both cores
>=20
> =20
>=20
> setenv core0bootargs root=3D/dev/mmcblk0p3 rootdelay=3D5 rw mem=3D192M
>=20
> setenv core1bootargs root=3D/dev/nfs nfsroot=3D<serverip>:/<rootfs> ip=3D=
dhcp
> mem=3D256M
>=20
> =20
>=20
> I have also partitioned my hardware among both cores and supplied
> appropriate =93protected-sources=94 in mpic node of both DTS files. The
> problem is, I receive following warning continuously only on Core 0
> console, but Core 1 is running smooth. In following warnings source irq=
s
> are mostly which I have assigned to Core 1, but they are present in Cor=
e
> 0 mpic node =93protected-sources=94 list, then why I am getting these m=
essages.
>=20
> =20
>=20
> [ 6.219204] __ratelimit: 5796 callbacks suppressed
>=20
> [ 6.223996] OpenPIC : Got protected source 30 !
>=20
> [ 7.005809] OpenPIC : Got protected source 30 !
>=20
> [ 8.005906] OpenPIC : Got protected source 30 !
>=20
> [ 8.433053] OpenPIC : Got protected source 29 !
>=20
> [ 8.437942] OpenPIC : Got protected source 30 !
>=20
> [ 8.443101] OpenPIC : Got protected source 30 !
>=20
> [ 8.448428] OpenPIC : Got protected source 30 !
>=20
> =20
>=20
> Any thoughts ?
Does each dtb have the correct CPU number, both from the command line
boot cpu flag and in the CPU node?
Do both device trees have pic-no-reset in the mpic node?
If neither of those are the issue, start dumping the relevant MPIC
interrupt destination registers, and tracethe code where they're
supposed to be set up. Also make sure that no interrupts are enabled
when Linux receives control from U-Boot.
-Scott
^ permalink raw reply
* Re: Mac address in the DT
From: Wolfgang Denk @ 2012-01-10 21:55 UTC (permalink / raw)
To: smitha.vanga; +Cc: scottwood, linuxppc-dev
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE01D3F2@HYD-MKD-MBX4.wipro.com>
Dear smitha.vanga@wipro.com,
In message <40631E9A2581F14BA60888C87A76A1FE01D3F2@HYD-MKD-MBX4.wipro.com> you wrote:
>
> The fdt_fixup_ethernet() is not supported in the older version of u-boot. So
> how to go about it in u-boot 1.3.0 version.
U-Boot v1.3.0 is more than 4 years old.
Update, or restrict yourself to using 4 years old Linux kernel
versions as well, like v2.6.23 or so :-(
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Everyting looks interesting until you do it. Then you find it's just
another job. - Terry Pratchett, _Moving Pictures_
^ permalink raw reply
* Re: [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support
From: Scott Wood @ 2012-01-10 22:03 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <A1483A2E-FF86-4E25-93CC-9EA1BA4925D4@suse.de>
On 01/09/2012 09:11 PM, Alexander Graf wrote:
> On 10.01.2012, at 01:51, Scott Wood wrote:
>> On 01/09/2012 11:46 AM, Alexander Graf wrote:
>>> On 21.12.2011, at 02:34, Scott Wood wrote:
>>>> + /* For debugging, encode the failing instruction and
>>>> + * report it to userspace. */
>>>> + run->hw.hardware_exit_reason = ~0ULL << 32;
>>>> + run->hw.hardware_exit_reason |= vcpu->arch.last_inst;
>>>
>>>
>>> I'm fairly sure you want to fix this :)
>>
>> Likewise, that's what booke.c already does. What should it do instead?
>
> This is what book3s does:
>
> case EMULATE_FAIL:
> printk(KERN_CRIT "%s: emulation at %lx failed (%08x)\n",
> __func__, kvmppc_get_pc(vcpu), kvmppc_get_last_inst(vcpu));
> kvmppc_core_queue_program(vcpu, flags);
> r = RESUME_GUEST;
>
> which also doesn't throttle the printk, but I think injecting a
> program fault into the guest is the most sensible thing to do if we
> don't know what the instruction is supposed to do. Best case we get
> an oops inside the guest telling us what broke :).
Ah, yes, it should send a program check.
>>> Ah, so that's what you want to use regs for. So is having a pt_regs
>>> struct that only contains useful register values in half its fields
>>> any useful here? Or could we keep control of the registers ourselves,
>>> enabling us to maybe one day optimize things more.
>>
>> I think it contains enough to be useful for debugging code such as sysrq
>> and tracers, and as noted in the comment we could copy the rest if we
>> care enough. MSR might be worth copying.
>>
>> It will eventually be used for machine checks as well, which I'd like to
>> hand reasonable register state to, at least for GPRs, LR, and PC.
>>
>> If there's a good enough performance reason, we could just copy
>> everything over for machine checks and pass NULL to do_IRQ (I think it
>> can take this -- a dummy regs struct if not), but it seems premature at
>> the moment unless the switch already causes measured performance loss
>> (cache utilization?).
>
> I'm definitely not concerned about performance, but complexity and uniqueness.
>
> With the pt_regs struct, we have a bunch of fields in the vcpu that are there, but unused. I find that situation pretty confusing.
I removed the registers from the vcpu, that are to be used in regs instead.
There are a few fields in regs that are not valid, though it is
explicitly pointed out via a comment.
> So yes, I would definitely prefer to copy registers during MC and keep the registers where they are today - unless there are SPRs for them of course.
>
> Imagine we'd one day want to share GPRs with user space through the
> kvm_run structure (see the s390 patches on the ML for this). I really
> wouldn't want to make pt_regs part of our userspace ABI.
Neither would I. If that's something that's reasonably likely to
happen, I guess that's a good enough reason to avoid this. We could
always add later a debug option to copy regs even on normal interrupts,
if needed.
>> We probably should defer the check until after we've disabled
>> interrupts, similar to signals -- even if we didn't exit for an
>> interrupt, we could have received one after enabling them.
>
> Yup. I just don't think you can call resched() with interrupts disabled, so a bit cleverness is probably required here.
I think it is actually allowed, but interrupts will be enabled on
return. We'll need to repeat prepare_to_enter if we do schedule. Since
we already need special handling for that, we might as well add a
local_irq_enable() once we know we are going to schedule, just in case.
>>>> diff --git a/arch/powerpc/kvm/booke.h b/arch/powerpc/kvm/booke.h
>>>> index 05d1d99..d53bcf2 100644
>>>> --- a/arch/powerpc/kvm/booke.h
>>>> +++ b/arch/powerpc/kvm/booke.h
>>>> @@ -48,7 +48,20 @@
>>>> #define BOOKE_IRQPRIO_PERFORMANCE_MONITOR 19
>>>> /* Internal pseudo-irqprio for level triggered externals */
>>>> #define BOOKE_IRQPRIO_EXTERNAL_LEVEL 20
>>>> -#define BOOKE_IRQPRIO_MAX 20
>>>> +#define BOOKE_IRQPRIO_DBELL 21
>>>> +#define BOOKE_IRQPRIO_DBELL_CRIT 22
>>>> +#define BOOKE_IRQPRIO_MAX 23
>>>
>>> So was MAX wrong before or is it too big now?
>>
>> MAX is just a marker for how many IRQPRIOs we have, not any sort of
>> external limit. This patch adds new IRQPRIOs, so MAX goes up.
>>
>> The actual limit is the number of bits in a long.
>
> Yes, and before the highest value was 20 with MAX being 20, now the
> highest value is 22 with MAX being 23. Either MAX == highest number
> or MAX == highest number + 1, but you're changing the semantics of
> MAX here. Maybe it was wrong before, I don't know, hence I'm asking
> :).
Oh, didn't notice that.
Actually, it looks like the two places that reference BOOKE_IRQPRIO_MAX
don't agree on what they're expecting. book3s uses "one greater than
the highest irqprio", so I guess we should resolve it that way (even
though I'd normally expect that to be phrased "num" rather than "max")
-- as a separate patch, of course.
-Scott
^ permalink raw reply
* Re: [RFC PATCH 16/16] KVM: PPC: e500mc support
From: Scott Wood @ 2012-01-10 22:20 UTC (permalink / raw)
To: Avi Kivity; +Cc: Liu Yu, kvm, agraf, kvm-ppc, Varun Sethi, linuxppc-dev
In-Reply-To: <4F0BF8BB.4080309@redhat.com>
On 01/10/2012 02:37 AM, Avi Kivity wrote:
> On 01/09/2012 09:29 PM, Scott Wood wrote:
>>>
>>> Best to include their signoffs, if possible.
>>
>> These patches are based in part on a bunch of different patches from
>> these people (for which I did receive signoffs). I was reluctant to put
>> their signoff directly on the new patches, since I didn't want to make
>> it look like they had submitted the patch in anything resembling its
>> current form. I wanted to give them credit for what they did, but not
>> blame for what I did with their code.
>>
>
> Signoffs are for assigning neither credit nor blame, but for
> attributing authorship and affirming that a contributor has
> the right to contribute code or pass it along.
That's its formal purpose, but some people draw other conclusions from
it regardless. From Documentation/SubmittingPatches: "Rule (b) allows
you to adjust the code, but then it is very impolite to change one
submitter's code and make him endorse your bugs."
Please read the DCO at
> https://lwn.net/Articles/437739/.
I've read it. My signoff here qualifies based on (a) and (b).
> (a) The contribution was created in whole or in part by me and I
> have the right to submit it under the open source license
> indicated in the file; or
Note "or in part". The contributions in this patch were all produced by
Freescale employees on a work for hire basis (other than the extent to
which the code is derived from code already in the Linux kernel, which
is covered by (b)), and I am authorized to submit this work on
Freescale's behalf for inclusion into the Linux kernel under GPLv2.
I'm not trying to be difficult, just to avoid looking like it was a
patch passed more-or-less as-is from person to person. When I resubmit,
I can put the sign-offs in with [scottwood@freescale.com: significant
rework] after them, or list them separately as part of the "based on..."
paragraph.
-Scott
^ permalink raw reply
* Re: [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support
From: Alexander Graf @ 2012-01-10 23:06 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <4F0CB5B1.6010601@freescale.com>
On 10.01.2012, at 23:03, Scott Wood wrote:
> On 01/09/2012 09:11 PM, Alexander Graf wrote:
>> On 10.01.2012, at 01:51, Scott Wood wrote:
>>> On 01/09/2012 11:46 AM, Alexander Graf wrote:
>>>> On 21.12.2011, at 02:34, Scott Wood wrote:
>>>>> + /* For debugging, encode the failing instruction and
>>>>> + * report it to userspace. */
>>>>> + run->hw.hardware_exit_reason =3D ~0ULL << 32;
>>>>> + run->hw.hardware_exit_reason |=3D vcpu->arch.last_inst;
>>>>=20
>>>>=20
>>>> I'm fairly sure you want to fix this :)
>>>=20
>>> Likewise, that's what booke.c already does. What should it do =
instead?
>>=20
>> This is what book3s does:
>>=20
>> case EMULATE_FAIL:
>> printk(KERN_CRIT "%s: emulation at %lx failed =
(%08x)\n",
>> __func__, kvmppc_get_pc(vcpu), =
kvmppc_get_last_inst(vcpu));
>> kvmppc_core_queue_program(vcpu, flags);
>> r =3D RESUME_GUEST;
>>=20
>> which also doesn't throttle the printk, but I think injecting a
>> program fault into the guest is the most sensible thing to do if we
>> don't know what the instruction is supposed to do. Best case we get
>> an oops inside the guest telling us what broke :).
>=20
> Ah, yes, it should send a program check.
>=20
>>>> Ah, so that's what you want to use regs for. So is having a pt_regs
>>>> struct that only contains useful register values in half its fields
>>>> any useful here? Or could we keep control of the registers =
ourselves,
>>>> enabling us to maybe one day optimize things more.
>>>=20
>>> I think it contains enough to be useful for debugging code such as =
sysrq
>>> and tracers, and as noted in the comment we could copy the rest if =
we
>>> care enough. MSR might be worth copying.
>>>=20
>>> It will eventually be used for machine checks as well, which I'd =
like to
>>> hand reasonable register state to, at least for GPRs, LR, and PC.
>>>=20
>>> If there's a good enough performance reason, we could just copy
>>> everything over for machine checks and pass NULL to do_IRQ (I think =
it
>>> can take this -- a dummy regs struct if not), but it seems premature =
at
>>> the moment unless the switch already causes measured performance =
loss
>>> (cache utilization?).
>>=20
>> I'm definitely not concerned about performance, but complexity and =
uniqueness.
>>=20
>> With the pt_regs struct, we have a bunch of fields in the vcpu that =
are there, but unused. I find that situation pretty confusing.
>=20
> I removed the registers from the vcpu, that are to be used in regs =
instead.
>=20
> There are a few fields in regs that are not valid, though it is
> explicitly pointed out via a comment.
Yes, and if there was real technical reason to do it this way I'd agree. =
But there isn't.
>=20
>> So yes, I would definitely prefer to copy registers during MC and =
keep the registers where they are today - unless there are SPRs for them =
of course.
>>=20
>> Imagine we'd one day want to share GPRs with user space through the
>> kvm_run structure (see the s390 patches on the ML for this). I really
>> wouldn't want to make pt_regs part of our userspace ABI.
>=20
> Neither would I. If that's something that's reasonably likely to
> happen, I guess that's a good enough reason to avoid this. We could
> always add later a debug option to copy regs even on normal =
interrupts,
> if needed.
Yup. I don't want to walk in the wrong direction basically. The overhead =
of copying
a couple fields to the stack on machine checks doesn't sound too bad =
compared
to the flexibility we maintain by keeping fields under our control.
Another imaginary case. I experimented with putting the GPRs into the =
PACA
back in the day. I don't remember why anymore, but it was for some =
speedup
of something.
That wouldn't be possible if we mandate everyone to use pt_regs.
>=20
>>> We probably should defer the check until after we've disabled
>>> interrupts, similar to signals -- even if we didn't exit for an
>>> interrupt, we could have received one after enabling them.
>>=20
>> Yup. I just don't think you can call resched() with interrupts =
disabled, so a bit cleverness is probably required here.
>=20
> I think it is actually allowed, but interrupts will be enabled on
> return. We'll need to repeat prepare_to_enter if we do schedule. =
Since
> we already need special handling for that, we might as well add a
> local_irq_enable() once we know we are going to schedule, just in =
case.
Yup :). And then check again.
>=20
>>>>> diff --git a/arch/powerpc/kvm/booke.h b/arch/powerpc/kvm/booke.h
>>>>> index 05d1d99..d53bcf2 100644
>>>>> --- a/arch/powerpc/kvm/booke.h
>>>>> +++ b/arch/powerpc/kvm/booke.h
>>>>> @@ -48,7 +48,20 @@
>>>>> #define BOOKE_IRQPRIO_PERFORMANCE_MONITOR 19
>>>>> /* Internal pseudo-irqprio for level triggered externals */
>>>>> #define BOOKE_IRQPRIO_EXTERNAL_LEVEL 20
>>>>> -#define BOOKE_IRQPRIO_MAX 20
>>>>> +#define BOOKE_IRQPRIO_DBELL 21
>>>>> +#define BOOKE_IRQPRIO_DBELL_CRIT 22
>>>>> +#define BOOKE_IRQPRIO_MAX 23
>>>>=20
>>>> So was MAX wrong before or is it too big now?
>>>=20
>>> MAX is just a marker for how many IRQPRIOs we have, not any sort of
>>> external limit. This patch adds new IRQPRIOs, so MAX goes up.
>>>=20
>>> The actual limit is the number of bits in a long.
>>=20
>=20
>> Yes, and before the highest value was 20 with MAX being 20, now the
>> highest value is 22 with MAX being 23. Either MAX =3D=3D highest =
number
>> or MAX =3D=3D highest number + 1, but you're changing the semantics =
of
>> MAX here. Maybe it was wrong before, I don't know, hence I'm asking
>> :).
>=20
> Oh, didn't notice that.
>=20
> Actually, it looks like the two places that reference =
BOOKE_IRQPRIO_MAX
> don't agree on what they're expecting. book3s uses "one greater than
> the highest irqprio", so I guess we should resolve it that way (even
> though I'd normally expect that to be phrased "num" rather than "max")
> -- as a separate patch, of course.
Yup. As long as it's consistent it's fine. I just really stumbled over =
this since the semantics of the define changed.
Alex=
^ permalink raw reply
* Re: [PATCH v2 0/3] ppc32/kprobe: Fix a bug for kprobe stwu r1
From: Benjamin Herrenschmidt @ 2012-01-11 0:53 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev
In-Reply-To: <4F0C01BA.3040302@windriver.com>
On Tue, 2012-01-10 at 17:15 +0800, tiejun.chen wrote:
> Tiejun Chen wrote:
> > Changes from V1:
> >
> > * use memcpy simply to withdraw copy_exc_stack
> > * add !(regs->msr & MSR_PR)) and
> > WARN_ON(test_thread_flag(TIF_EMULATE_STACK_STORE));
> > to make sure we're in goot path.
> > * move this migration process inside 'restore'
> > * clear TIF flag atomically
>
> Ben,
>
> Is this series OK?
Not completely sorry. I was about to send you some comments a couple of
weeks ago then had to leave urgently and forgot about it, then started
rewriting your code and didn't finish :-)
I'll give you some more feedback asap, sorry about that. It's getting
there but there's a couple of things I'd like to see done a bit
differently.
Cheers,
Ben.
> Thanks
> Tiejun
>
> >
> > Tiejun Chen (3):
> > powerpc/kprobe: introduce a new thread flag
> > ppc32/kprobe: complete kprobe and migrate exception frame
> > ppc32/kprobe: don't emulate store when kprobe stwu r1
> >
> > arch/powerpc/include/asm/thread_info.h | 3 ++
> > arch/powerpc/kernel/entry_32.S | 35 ++++++++++++++++++++++++++++++++
> > arch/powerpc/lib/sstep.c | 25 +++++++++++++++++++++-
> > 3 files changed, 61 insertions(+), 2 deletions(-)
> >
> > Tiejun
^ permalink raw reply
* [PATCH] cpuidle: Default y for pseries
From: Benjamin Herrenschmidt @ 2012-01-11 1:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Shaohua Li, linux-pm, Venkatesh Pallipadi
We just replaced the pseries platform idle loops with a cpuidle backend,
however that means that you won't get any power saving and won't return
any unused idle time to the hypervisor unless cpuidle is enabled.
Thus is should default to y when pseries is enabled. I prefer that to
a select so we can still make it modular if we want to.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Linus, do you want to just pick that up or should I put it into powerpc.git
and ask you to pull ? I will have 2 or 3 other fixes there later today,
but I wanted to make sure you were ok with the approach with this
specific one.
diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index 7dbc4a8..62ca70d 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
@@ -1,7 +1,8 @@
config CPU_IDLE
bool "CPU idle PM support"
- default ACPI
+ default y if ACPI
+ default y if PPC_PSERIES
help
CPU idle is a generic framework for supporting software-controlled
idle processor power management. It includes modular cross-platform
^ permalink raw reply related
* RE: [PATCH] powerpc/85xx: Add P1024rdb dts support
From: Tang Yuantian-B29983 @ 2012-01-11 2:41 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F0C7928.1020803@freescale.com>
> >
> > P1020rdb has vitesse-7385 switch.
>=20
> I'm talking about the SoC, not the board.
>=20
> > fsl/p1020si-post.dtsi can be used for both boards.
>=20
> What are you basing this on? Has someone looked over both manuals in
> detail and concluded that every device described is 100% compatible?
>=20
I ported this from the dts in kernel 2.6.35.=20
I found they are 100% compatible from dts point of view.
Regards,
Yuantian
^ permalink raw reply
* RE: Mac address in the DT
From: smitha.vanga @ 2012-01-11 6:03 UTC (permalink / raw)
To: wd; +Cc: scottwood, linuxppc-dev
In-Reply-To: <20120110215509.2D08D1167AA4@gemini.denx.de>
Hi,
I am using 2.6.21 linux kernel with this bootloader.
The ethernet driver in the kernel reads the mac address from the .dtb file.
Regards,
Smitha
Please do not print this email unless it is absolutely necessary. =0A=
=0A=
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and may=
contain proprietary, confidential or privileged information. If you are not=
the intended recipient, you should not disseminate, distribute or copy this=
e-mail. Please notify the sender immediately and destroy all copies of this=
message and any attachments. =0A=
=0A=
WARNING: Computer viruses can be transmitted via email. The recipient should=
check this email and any attachments for the presence of viruses. The compa=
ny accepts no liability for any damage caused by any virus transmitted by th=
is email. =0A=
=0A=
www.wipro.com
^ permalink raw reply
* Re: [PATCH] cpuidle: Default y for pseries
From: Linus Torvalds @ 2012-01-11 6:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Shaohua Li, linux-pm, Venkatesh Pallipadi
In-Reply-To: <1326243935.23910.85.camel@pasglop>
On Tue, Jan 10, 2012 at 5:05 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
> Linus, do you want to just pick that up or should I put it into powerpc.git
> and ask you to pull ? I will have 2 or 3 other fixes there later today,
> but I wanted to make sure you were ok with the approach with this
> specific one.
It doesn't seem to be all that different from the "default y if ACPI"
case, so I guess it works ok.
That said, I wonder if the right approach wouldn't be
default y if SUPPORT_CPU_IDLE
or something along those lines. And then both ACPI and PPC_PSERIES
could just select that instead. Because I do hate having random
board-level knowledge in something like this. I dunno.
Linus
^ permalink raw reply
* Re: [PATCH] cpuidle: Default y for pseries
From: Benjamin Herrenschmidt @ 2012-01-11 7:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Shaohua Li, linux-pm, Venkatesh Pallipadi
In-Reply-To: <CA+55aFycfYKFagVgckrEm3dAFHNZEvm0Hkw0UbH+XfKQu8Cvzg@mail.gmail.com>
On Tue, 2012-01-10 at 22:08 -0800, Linus Torvalds wrote:
> On Tue, Jan 10, 2012 at 5:05 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> > Linus, do you want to just pick that up or should I put it into powerpc.git
> > and ask you to pull ? I will have 2 or 3 other fixes there later today,
> > but I wanted to make sure you were ok with the approach with this
> > specific one.
>
> It doesn't seem to be all that different from the "default y if ACPI"
> case, so I guess it works ok.
It works for my case, that's tested, but ...
> That said, I wonder if the right approach wouldn't be
>
> default y if SUPPORT_CPU_IDLE
>
> or something along those lines. And then both ACPI and PPC_PSERIES
> could just select that instead. Because I do hate having random
> board-level knowledge in something like this. I dunno.
I tend to agree, I wasn't too keen on touching ACPI related stuff I
suppose it shouldn't be hard :-) Btw, what about the change:
- default ACPI
+ default y if ACPI
(To be honest I'm not sure what the first form does in details).
Oh, also, I just see that in drivers/acpi/Kconfig:
config ACPI_PROCESSOR
tristate "Processor"
select THERMAL
select CPU_IDLE
default y
Hrm... maybe I should just do the same in pseries and remove both the
"default" statements above, what do you think ?
On pSeries I'm keen to build that in rather than make it a module too
because you get no idle handling until it loads which can be
problematic. Built-in, it seems to be quite early in the link order (if
we can still trust that nowadays ...).
Cheers,
Ben.
^ permalink raw reply
* RE: OpenPIC warnings on P1022RDK AMP configuration
From: Arshad, Farrukh @ 2012-01-11 7:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F0CA749.3000306@freescale.com>
>> Does each dtb have the correct CPU number, both from the command line bo=
ot cpu flag and in the CPU node?
Yes both CPUs have the correct CPU numbers and also both DTBs are build wit=
h their respective -b flag.=20
>> Do both device trees have pic-no-reset in the mpic node?
Yes, both have pic-no-reset mode.
>> If neither of those are the issue, start dumping the relevant MPIC inter=
rupt destination registers, and tracethe code where they're supposed to be =
set up. Also make sure that no interrupts are enabled when Linux receives=
control from U-Boot.
Yes, interrupts are disabled when Linux receives control from U-Boot.
^ permalink raw reply
* RE: [PATCH] dmaengine: async_xor, fix zero address issue when xor highmem page
From: Shi Xuelin-B29237 @ 2012-01-11 7:51 UTC (permalink / raw)
To: dan.j.williams@intel.com
Cc: vinod.koul@intel.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Li Yang-R58472
In-Reply-To: <1324967446-28939-1-git-send-email-b29237@freescale.com>
Hello Dan Williams,
Do you have any comment about this patch?
Thanks,
Forrest
-----Original Message-----
From: Shi Xuelin-B29237=20
Sent: 2011=1B$BG/=1B(B12=1B$B7n=1B(B27=1B$BF|=1B(B 14:31
To: vinod.koul@intel.com; dan.j.williams@intel.com; linuxppc-dev@lists.ozla=
bs.org; linux-kernel@vger.kernel.org; Li Yang-R58472
Cc: Shi Xuelin-B29237
Subject: [PATCH] dmaengine: async_xor, fix zero address issue when xor high=
mem page
From: Forrest shi <b29237@freescale.com>
we may do_sync_xor high mem pages, in this case, page_address will
return zero address which cause a failure.
this patch uses kmap_atomic before xor the pages and kunmap_atomic
after it.
Signed-off-by: b29237@freescale.com <xuelin.shi@freescale.com>
---
crypto/async_tx/async_xor.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c inde=
x bc28337..5b416d1 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -26,6 +26,7 @@
#include <linux/kernel.h>
#include <linux/interrupt.h>
#include <linux/mm.h>
+#include <linux/highmem.h>
#include <linux/dma-mapping.h>
#include <linux/raid/xor.h>
#include <linux/async_tx.h>
@@ -126,7 +127,7 @@ do_sync_xor(struct page *dest, struct page **src_list, =
unsigned int offset,
int src_cnt, size_t len, struct async_submit_ctl *submit) {
int i;
- int xor_src_cnt =3D 0;
+ int xor_src_cnt =3D 0, kmap_cnt=3D0;
int src_off =3D 0;
void *dest_buf;
void **srcs;
@@ -138,11 +139,13 @@ do_sync_xor(struct page *dest, struct page **src_list=
, unsigned int offset,
=20
/* convert to buffer pointers */
for (i =3D 0; i < src_cnt; i++)
- if (src_list[i])
- srcs[xor_src_cnt++] =3D page_address(src_list[i]) + offset;
+ if (src_list[i]) {
+ srcs[xor_src_cnt++] =3D kmap_atomic(src_list[i], KM_USER1) + offset;
+ }
+ kmap_cnt =3D xor_src_cnt;
src_cnt =3D xor_src_cnt;
/* set destination address */
- dest_buf =3D page_address(dest) + offset;
+ dest_buf =3D kmap_atomic(dest, KM_USER0) + offset;
=20
if (submit->flags & ASYNC_TX_XOR_ZERO_DST)
memset(dest_buf, 0, len);
@@ -157,6 +160,11 @@ do_sync_xor(struct page *dest, struct page **src_list,=
unsigned int offset,
src_off +=3D xor_src_cnt;
}
=20
+ kunmap_atomic(dest_buf, KM_USER0);
+ for (i =3D 0; i < kmap_cnt; i++)=20
+ if (src_list[i])
+ kunmap_atomic(srcs[i], KM_USER1);
+
async_tx_sync_epilog(submit);
}
=20
--
1.7.0.4
^ permalink raw reply
* RE: [PATCH] fsldma: fix performance degradation by optimizing spinlock use.
From: Shi Xuelin-B29237 @ 2012-01-11 7:54 UTC (permalink / raw)
To: iws@ovro.caltech.edu
Cc: vinod.koul@intel.com, dan.j.williams@intel.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1324879263-11845-1-git-send-email-b29237@freescale.com>
Hello Iris,
As we discussed in the previous patch, I add one smp_mb() in fsl_tx_status.
In my testing with iozone, this smp_mb() could cause 1%~2% performance degr=
adation.
Anyway it is acceptable for me. Do you have any other comments?
Thanks,
Forrest
-----Original Message-----
From: Shi Xuelin-B29237=20
Sent: 2011=1B$BG/=1B(B12=1B$B7n=1B(B26=1B$BF|=1B(B 14:01
To: iws@ovro.caltech.edu; vinod.koul@intel.com; dan.j.williams@intel.com; l=
inuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
Cc: Shi Xuelin-B29237
Subject: [PATCH] fsldma: fix performance degradation by optimizing spinlock=
use.
From: Forrest shi <b29237@freescale.com>
dma status check function fsl_tx_status is heavily called in
a tight loop and the desc lock in fsl_tx_status contended by
the dma status update function. this caused the dma performance
degrades much.
this patch releases the lock in the fsl_tx_status function, and
introduce the smp_mb() to avoid possible memory inconsistency.
Signed-off-by: Forrest Shi <xuelin.shi@freescale.com>
---
drivers/dma/fsldma.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index 8a78154..008=
fb5e 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -986,15 +986,11 @@ static enum dma_status fsl_tx_status(struct dma_chan =
*dchan,
struct fsldma_chan *chan =3D to_fsl_chan(dchan);
dma_cookie_t last_complete;
dma_cookie_t last_used;
- unsigned long flags;
-
- spin_lock_irqsave(&chan->desc_lock, flags);
=20
last_complete =3D chan->completed_cookie;
+ smp_mb();
last_used =3D dchan->cookie;
=20
- spin_unlock_irqrestore(&chan->desc_lock, flags);
-
dma_set_tx_state(txstate, last_complete, last_used, 0);
return dma_async_is_complete(cookie, last_complete, last_used); }
--
1.7.0.4
^ permalink raw reply
* RE: [PATCH][v2] mmc:sdhci: restore the enabled dma when do reset all
From: Xie Shaohui-B21989 @ 2012-01-11 9:12 UTC (permalink / raw)
To: cjb@laptop.org, linux-mmc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989
In-Reply-To: <1325147580-31281-1-git-send-email-Shaohui.Xie@freescale.com>
Hello, Chris,
May I have your attention to this patch, please?
Best Regards,=20
Shaohui Xie=20
>-----Original Message-----
>From: Xie Shaohui-B21989
>Sent: Friday, January 06, 2012 3:58 PM
>To: 'cjb@laptop.org'; linux-mmc@vger.kernel.org
>Cc: linuxppc-dev@lists.ozlabs.org; Xie Shaohui-B21989
>Subject: RE: [PATCH][v2] mmc:sdhci: restore the enabled dma when do reset
>all
>
>Hello, Chris,
>
>Do you have any concern for this patch?
>
>
>Best Regards,
>Shaohui Xie
>
>>-----Original Message-----
>>From: Xie Shaohui-B21989
>>Sent: Thursday, December 29, 2011 4:33 PM
>>To: linux-mmc@vger.kernel.org
>>Cc: linuxppc-dev@lists.ozlabs.org; Xie Shaohui-B21989
>>Subject: [PATCH][v2] mmc:sdhci: restore the enabled dma when do reset
>>all
>>
>>If dma is enabled, it'll be cleared when reset all is performed, this
>>can be observed on some platforms, such as P2041 which has a version
>>2.3 controller, but platform like P4080 which has a version 2.2
>>controller, does not suffer this, so we will check if the dma is
>>enabled, we should restore it after reset all.
>>
>>Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>>---
>>based on http://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git,
>>branch 'for-linus'.
>>
>>changes for v2:
>>call the wrapper API instead of access the register directly.
>>
>> drivers/mmc/host/sdhci.c | 5 +++++
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>>diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index
>>19ed580..cf6a048 100644
>>--- a/drivers/mmc/host/sdhci.c
>>+++ b/drivers/mmc/host/sdhci.c
>>@@ -214,6 +214,11 @@ static void sdhci_reset(struct sdhci_host *host,
>>u8
>>mask)
>>
>> if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
>> sdhci_clear_set_irqs(host, SDHCI_INT_ALL_MASK, ier);
>>+
>>+ if (host->flags & (SDHCI_USE_SDMA | SDHCI_USE_ADMA)) {
>>+ if ((host->ops->enable_dma) && (mask & SDHCI_RESET_ALL))
>>+ host->ops->enable_dma(host);
>>+ }
>> }
>>
>> static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
>>--
>>1.6.4
^ permalink raw reply
* RE: Problem in getting shared memory access on P1022RDK
From: Arshad, Farrukh @ 2012-01-11 15:52 UTC (permalink / raw)
To: tiejun.chen; +Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F050653.6010601@windriver.com>
QWRkaW5nIG1vcmUgaXQsIA0KDQpJIGhhdmUgcmVtb3ZlZCB0aGUgc2hhcmVkIG1lbW9yeSBrZXJu
ZWwgZHJpdmVyIGRlcGVuZGVuY3kganVzdCB0byBuYXJyb3cgZG93biB0aGUgcHJvYmxlbSBhcmVh
IGFuZCBJIGhhdmUgd3JpdHRlbiBhIHNtYWxsIHBpZWNlIG9mIGNvZGUgaW4gdXNlciBzcGFjZS4g
QSB3cml0ZXIgJiBhIHJlYWRlciBhcHBsaWNhdGlvbiB3aGljaCBhY2Nlc3MgdGhlIHNoYXJlZCBt
ZW1vcnkgYW5kIEkgZ290IHRoZSBzYW1lIGJlaGF2aW9yIGFzIHdpdGggdGhlIHNoYXJlZCBtZW1v
cnkga2VybmVsIGRyaXZlci4gSW50ZXJlc3RpbmdseSwgbXkgdXNlciBzcGFjZSBhcHBsaWNhdGlv
biB3b3JrIGZpbmUgb24gUDEwMjJEUyBidXQgbm90IG9uIFAxMDIyUkRLIGhvd2V2ZXIgYm90aCB1
c2luZyB0aGUgc2FtZSBDUFUgbW9kdWxlcy4NCg0KV2hlbiBJIHdyaXRlIGEgc2ltcGxlIHN0cmlu
ZyBvbiBzaGFyZWQgbWVtb3J5IGZyb20gQ29yZSAxIGl0IGlzIHJlYWQgYXQgQ29yZSAwIHByb3Bl
cmx5DQpXaGVuIEkgd3JpdGUgYSBzaW1wbGUgc3RyaW5nIG9uIHNoYXJlZCBtZW1vcnkgZnJvbSBD
b3JlIDAgaXQgaXMgbm90IHJlYWQgYXQgQ29yZSAxLiANCg0KV2l0aCB0aGlzIHRlc3Qgbm93IEkg
YW0gc3VyZSB0aGUgcHJvYmxlbSBsaWVzIGluIHRoZSBrZXJuZWwgaXRzZWxmLiBBbnkgcG9pbnRl
cnMgdG8gbG9vayBmb3IgdGhlIHRyb3VibGVkIGFyZWEgPw0KDQpNeSBhcHBsaWNhdGlvbiBjb2Rl
IGlzIChlcnJvciBjaGVja2luZyBhbmQgb3RoZXIgY29kZSBpcyBvbWl0dGVkKQ0KDQojZGVmaW5l
IAlTSE1fQkFTRSAJMHgxQzAwMDAwMA0KI2RlZmluZQlTSE1fU0laRSAJMHg0MDAwMDAJCS8vIDQg
TUIgb2YgU2hhcmVkIE1lbW9yeQ0KI2RlZmluZSAJUEFHRV9TSVpFIAkoNCoxMDI0KQ0KDQpmZCA9
IG9wZW4oZGV2aWNlLCBPX1JEV1IpOw0KDQpzaG0gPSBtYWxsb2MoU0hNX1NJWkUgKyAoUEFHRV9T
SVpFIC0gMSkpOw0KaWYgKCAodW5zaWduZWQgbG9uZykgc2htICUgUEFHRV9TSVpFKSB7DQoJc2ht
ICs9IFBBR0VfU0laRSAtICgodW5zaWduZWQgbG9uZylzaG0gJSBQQUdFX1NJWkUpOw0KfQ0KDQpz
aG0gPSBtbWFwKHNobSwgU0hNX1NJWkUsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfU0hBUkVE
IHwgTUFQX0ZJWEVELCBmZCwgU0hNX0JBU0UpOw0KLi4uLi4uDQouLi4uLi4gd3JpdGUgc29tZSBz
dHJpbmcgYXQgc2htLg0KDQpNeSBtZW1vcnkgcGFydGl0aW9uaW5nIGZvciBib3RoIHN5c3RlbXMg
aXMgDQoNCkNvcmUgICAgICAgICAgICAgICAgIAkJQmFzZSBBZGRyZXNzICAgICAgICAgCVNpemUN
CkNvcmUgMCAgICAgICAgICAgICAgIAkJMHgwMDAwLDAwMDAgICAgICAgICAgCTB4MTAwMCwwMDAw
DQpDb3JlIDEgICAgICAgICAgICAgICAJCTB4MTAwMCwwMDAwICAgICAgICAgIAkweDBDMDAsMDAw
MA0KU2hhcmVkIE1lbW9yeSAgICAJMHgxQzAwLDAwMDAgICAgICAgICAgCTB4MDQwMCwwMDAwDQoN
ClJlZ2FyZHMsDQpGYXJydWtoIEFyc2hhZC4NCk1lbnRvciBHcmFwaGljcyBQYWtpc3Rhbg0K
^ permalink raw reply
* Re: [PATCH] fsldma: fix performance degradation by optimizing spinlock use.
From: Ira W. Snyder @ 2012-01-11 16:13 UTC (permalink / raw)
To: Shi Xuelin-B29237
Cc: vinod.koul@intel.com, dan.j.williams@intel.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <DBB740589CE8814680DECFE34BE197AB1665A3@039-SN1MPN1-006.039d.mgd.msft.net>
On Wed, Jan 11, 2012 at 07:54:55AM +0000, Shi Xuelin-B29237 wrote:
> Hello Iris,
>
> As we discussed in the previous patch, I add one smp_mb() in fsl_tx_status.
> In my testing with iozone, this smp_mb() could cause 1%~2% performance degradation.
> Anyway it is acceptable for me. Do you have any other comments?
>
This patch looks fine to me.
Ira
> -----Original Message-----
> From: Shi Xuelin-B29237
> Sent: 2011年12月26日 14:01
> To: iws@ovro.caltech.edu; vinod.koul@intel.com; dan.j.williams@intel.com; linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Cc: Shi Xuelin-B29237
> Subject: [PATCH] fsldma: fix performance degradation by optimizing spinlock use.
>
> From: Forrest shi <b29237@freescale.com>
>
> dma status check function fsl_tx_status is heavily called in
> a tight loop and the desc lock in fsl_tx_status contended by
> the dma status update function. this caused the dma performance
> degrades much.
>
> this patch releases the lock in the fsl_tx_status function, and
> introduce the smp_mb() to avoid possible memory inconsistency.
>
> Signed-off-by: Forrest Shi <xuelin.shi@freescale.com>
> ---
> drivers/dma/fsldma.c | 6 +-----
> 1 files changed, 1 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index 8a78154..008fb5e 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -986,15 +986,11 @@ static enum dma_status fsl_tx_status(struct dma_chan *dchan,
> struct fsldma_chan *chan = to_fsl_chan(dchan);
> dma_cookie_t last_complete;
> dma_cookie_t last_used;
> - unsigned long flags;
> -
> - spin_lock_irqsave(&chan->desc_lock, flags);
>
> last_complete = chan->completed_cookie;
> + smp_mb();
> last_used = dchan->cookie;
>
> - spin_unlock_irqrestore(&chan->desc_lock, flags);
> -
> dma_set_tx_state(txstate, last_complete, last_used, 0);
> return dma_async_is_complete(cookie, last_complete, last_used); }
> --
> 1.7.0.4
>
>
^ 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