* Re: [PATCH v3 3/3] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Richard Cochran @ 2010-05-18 6:36 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, devicetree-discuss, linuxppc-dev
In-Reply-To: <4BF18582.6000500@freescale.com>
On Mon, May 17, 2010 at 01:05:54PM -0500, Scott Wood wrote:
> >>> >+ - tmr_fiper1 Fixed interval period pulse generator.
> >>> >+ - tmr_fiper2 Fixed interval period pulse generator.
> >>
>
> MPC8572 and P2020 have fiper3 as well.
I doubt they really have a third fiper.
First of all, this signal is not routed anywhere on the boards. Also,
according to the documentation, it has no bit in the TMR_CTRL or the
TMR_TEMASK registers. Unless there is a bit in TMR_TEMASK, you cannot
get an interrupt from it.
If you cannot use the signal externally (in the "real" world) and you
cannot get an interrupt, what good is it to have such a periodic
signal? Polling the bit in the TMR_TEVENT to see when a pulse occurs
seems pointless.
Scott, you have connections, right? Can you clarify this for me?
Thanks,
Richard
^ permalink raw reply
* [PATCH 1/1] RapidIO: Fix maintenance access to higher memory areas
From: Thomas Moll @ 2010-05-18 6:28 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel, alexandre.bounine, linuxppc-dev
Fix the maintenance access functions to farend RapidIO devices.
1. Fixed shift of the given offset, to open the maintenance window
2. Mask offset to limit access to the opened maintenance window
3. Added extended destid part to rowtear register, required for 16bit mode
This method is matching maintenance transactions generation described
by Freescale in the appnote AN2932. With this modification full access
to a 16MB maintenance window is possible, this patch is required for
IDT cps switches. For easier handling of the access routines, the
access was limited to aligned memory regions. This should be no problem
because all registers are 32bit wide.
The patch was generated against 2.6.34 kernel + patches from
Alexandre Bounine
Signed-off-by: Thomas Moll <thomas.moll@sysgo.com>
Tested-by: Alexandre Bounine <alexandre.bounine@idt.com>
---
fsl_rio.c | 34 ++++++++++++++++++++++++++++------
1 file changed, 28 insertions(+), 6 deletions(-)
diff -purN linux-base/arch/powerpc/sysdev/fsl_rio.c linux-new/arch/powerpc/sysdev/fsl_rio.c
--- linux-base/arch/powerpc/sysdev/fsl_rio.c 2010-05-17 08:56:43.000000000 +0200
+++ linux-new/arch/powerpc/sysdev/fsl_rio.c 2010-05-17 09:40:41.000000000 +0200
@@ -1,6 +1,10 @@
/*
* Freescale MPC85xx/MPC86xx RapidIO support
*
+ * Copyright 2009 Sysgo AG
+ * Thomas Moll <thomas.moll@sysgo.com>
+ * - fixed maintenance access routines, check for aligned access
+ *
* Copyright 2009 Integrated Device Technology, Inc.
* Alex Bounine <alexandre.bounine@idt.com>
* - Added Port-Write message handling
@@ -371,10 +375,17 @@ fsl_rio_config_read(struct rio_mport *mp
pr_debug
("fsl_rio_config_read: index %d destid %d hopcount %d offset %8.8x len %d\n",
index, destid, hopcount, offset, len);
+
+ /* 16MB maintenance window possible */
+ /* allow only aligned access to maintenance registers */
+ if (offset > (0x1000000 - len) || !IS_ALIGNED(offset, len))
+ return -EINVAL;
+
out_be32(&priv->maint_atmu_regs->rowtar,
- (destid << 22) | (hopcount << 12) | ((offset & ~0x3) >> 9));
+ (destid << 22) | (hopcount << 12) | (offset >> 12));
+ out_be32(&priv->maint_atmu_regs->rowtear, (destid >> 10));
- data = (u8 *) priv->maint_win + offset;
+ data = (u8 *) priv->maint_win + (offset & (RIO_MAINT_WIN_SIZE - 1));
switch (len) {
case 1:
__fsl_read_rio_config(rval, data, err, "lbz");
@@ -382,9 +393,11 @@ fsl_rio_config_read(struct rio_mport *mp
case 2:
__fsl_read_rio_config(rval, data, err, "lhz");
break;
- default:
+ case 4:
__fsl_read_rio_config(rval, data, err, "lwz");
break;
+ default:
+ return -EINVAL;
}
if (err) {
@@ -419,10 +432,17 @@ fsl_rio_config_write(struct rio_mport *m
pr_debug
("fsl_rio_config_write: index %d destid %d hopcount %d offset %8.8x len %d val %8.8x\n",
index, destid, hopcount, offset, len, val);
+
+ /* 16MB maintenance windows possible */
+ /* allow only aligned access to maintenance registers */
+ if (offset > (0x1000000 - len) || !IS_ALIGNED(offset, len))
+ return -EINVAL;
+
out_be32(&priv->maint_atmu_regs->rowtar,
- (destid << 22) | (hopcount << 12) | ((offset & ~0x3) >> 9));
+ (destid << 22) | (hopcount << 12) | (offset >> 12));
+ out_be32(&priv->maint_atmu_regs->rowtear, (destid >> 10));
- data = (u8 *) priv->maint_win + offset;
+ data = (u8 *) priv->maint_win + (offset & (RIO_MAINT_WIN_SIZE - 1));
switch (len) {
case 1:
out_8((u8 *) data, val);
@@ -430,9 +450,11 @@ fsl_rio_config_write(struct rio_mport *m
case 2:
out_be16((u16 *) data, val);
break;
- default:
+ case 4:
out_be32((u32 *) data, val);
break;
+ default:
+ return -EINVAL;
}
return 0;
@@ -1483,7 +1505,8 @@ int fsl_rio_setup(struct of_device *dev)
/* Configure maintenance transaction window */
out_be32(&priv->maint_atmu_regs->rowbar, law_start >> 12);
- out_be32(&priv->maint_atmu_regs->rowar, 0x80077015); /* 4M */
+ out_be32(&priv->maint_atmu_regs->rowar,
+ 0x80077000 | (ilog2(RIO_MAINT_WIN_SIZE) - 1));
priv->maint_win = ioremap(law_start, RIO_MAINT_WIN_SIZE);
^ permalink raw reply
* Re: [PATCH v5] powerpc: Add hibernation support for FSL BookE processors
From: Anton Vorontsov @ 2010-05-18 5:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Milton Miller
In-Reply-To: <ECFF23B7-26B3-42D1-8609-FB53054BEF06@kernel.crashing.org>
On Mon, May 17, 2010 at 04:22:37PM -0500, Kumar Gala wrote:
[...]
> > arch/powerpc/kernel/Makefile | 8 +-
> > arch/powerpc/kernel/swsusp_booke.S | 193 ++++++++++++++++++++++++++++++++++++
> > 2 files changed, 199 insertions(+), 2 deletions(-)
> > create mode 100644 arch/powerpc/kernel/swsusp_booke.S
>
> Is there board specific code to go along with this?
Nope.
> When I enable I get:
>
> arch/powerpc/kernel/built-in.o: In function `cpu_idle':
> /home/galak/git/master/powerpc/arch/powerpc/kernel/idle.c:98: undefined reference to `cpu_die'
> make: *** [.tmp_vmlinux1] Error 1
This isn't caused by hibernation or my patch specifically.
Instead, it's a long standing issue, enabling CONFIG_SMP and
CONFIG_SUSPEND is enough to trigger this. Patch exists:
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg27982.html
No idea why it didn't make Linus' tree.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] 85xx: Enable support for ports 3 and 4 on 8548 CDS
From: Kumar Gala @ 2010-05-18 4:25 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev
In-Reply-To: <1269913148-6450-1-git-send-email-afleming@freescale.com>
On Mar 29, 2010, at 8:39 PM, Andy Fleming wrote:
> I believe support was disabled due to issues with earlier versions of
> the board/processor. At worst, adding the ports back into the device
> tree should result in enabling ports that don't work on older systems,
> so the default should be to enable them.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8548cds.dts | 4 ----
> 1 files changed, 0 insertions(+), 4 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH v2] kexec-tools, ppc64: Fix segfault parsing DR memory property
From: Michael Neuling @ 2010-05-17 23:30 UTC (permalink / raw)
To: Matt Evans; +Cc: linuxppc-dev, Simon Horman, kexec
In-Reply-To: <4BECBE89.3020108@ozlabs.org>
In message <4BECBE89.3020108@ozlabs.org> you wrote:
> add_dyn_reconf_usable_mem_property() iterates over memory spans
> in /ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory and intersects
> these with usablemem_rgns ranges. In doing so it used an unchecked
> fixed-size array which will overrun on machines with lots of LMBs.
>
> This patch removes the fixed-sized arrays from
> add_dyn_reconf_usable_mem_property() and add_usable_mem_property(), in lieu o
f
> malloc/realloc/free.
>
> Signed-off-by: Matt Evans <matt@ozlabs.org>
So this works our large P7 machine unlike the last one.
Acked-by: Michael Neuling <mikey@neuling.org>
> ---
> kexec/arch/ppc64/fs2dt.c | 82 +++++++++++++++++++++++++++++++++++++++-----
--
> 1 files changed, 70 insertions(+), 12 deletions(-)
>
> diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
> index 762bf04..4400f13 100644
> --- a/kexec/arch/ppc64/fs2dt.c
> +++ b/kexec/arch/ppc64/fs2dt.c
> @@ -37,7 +37,7 @@
> #define NAMESPACE 16384 /* max bytes for property names */
> #define INIT_TREE_WORDS 65536 /* Initial num words for prop values */
> #define MEMRESERVE 256 /* max number of reserved memory blocks
*/
> -#define MAX_MEMORY_RANGES 1024
> +#define MEM_RANGE_CHUNK_SZ 2048 /* Initial num dwords for mem ranges */
>
> static char pathname[MAXPATH], *pathstart;
> static char propnames[NAMESPACE] = { 0 };
> @@ -148,7 +148,8 @@ static void add_dyn_reconf_usable_mem_property(int fd)
> {
> char fname[MAXPATH], *bname;
> uint64_t buf[32];
> - uint64_t ranges[2*MAX_MEMORY_RANGES];
> + uint64_t *ranges;
> + int ranges_size = MEM_RANGE_CHUNK_SZ;
> uint64_t base, end, loc_base, loc_end;
> size_t i, rngs_cnt, range;
> int rlen = 0;
> @@ -165,6 +166,11 @@ static void add_dyn_reconf_usable_mem_property(int fd)
> die("unrecoverable error: error seeking in \"%s\": %s\n",
> pathname, strerror(errno));
>
> + ranges = malloc(ranges_size*8);
> + if (!ranges)
> + die("unrecoverable error: can't alloc %d bytes for ranges.\n",
> + ranges_size*8);
> +
> rlen = 0;
> for (i = 0; i < num_of_lmbs; i++) {
> if (read(fd, buf, 24) < 0)
> @@ -180,24 +186,57 @@ static void add_dyn_reconf_usable_mem_property(int fd)
>
> rngs_cnt = 0;
> for (range = 0; range < usablemem_rgns.size; range++) {
> + int add = 0;
> loc_base = usablemem_rgns.ranges[range].start;
> loc_end = usablemem_rgns.ranges[range].end;
> if (loc_base >= base && loc_end <= end) {
> - ranges[rlen++] = loc_base;
> - ranges[rlen++] = loc_end - loc_base;
> - rngs_cnt++;
> + add = 1;
> } else if (base < loc_end && end > loc_base) {
> if (loc_base < base)
> loc_base = base;
> if (loc_end > end)
> loc_end = end;
> + add = 1;
> + }
> +
> + if (add) {
> + if (rlen >= (ranges_size-2)) {
> + ranges_size += MEM_RANGE_CHUNK_SZ;
> + ranges = realloc(ranges, ranges_size*8)
;
> + if (!ranges)
> + die("unrecoverable error: can't
"
> + " realloc %d bytes for"
> + " ranges.\n",
> + ranges_size*8);
> + }
> ranges[rlen++] = loc_base;
> ranges[rlen++] = loc_end - loc_base;
> rngs_cnt++;
> }
> }
> - /* Store the count of (base, size) duple */
> - ranges[tmp_indx] = rngs_cnt;
> + if (rngs_cnt == 0) {
> + /* We still need to add a counter for every LMB because
> + * the kernel parsing code is dumb. We just have
> + * a zero in this case, with no following base/len.
> + */
> + ranges[tmp_indx] = 0;
> + /* rlen is already just tmp_indx+1 as we didn't write
> + * anything. Check array size here, as we'll probably
> + * go on for a while writing zeros now.
> + */
> + if (rlen >= (ranges_size-1)) {
> + ranges_size += MEM_RANGE_CHUNK_SZ;
> + ranges = realloc(ranges, ranges_size*8);
> + if (!ranges)
> + die("unrecoverable error: can't"
> + " realloc %d bytes for"
> + " ranges.\n",
> + ranges_size*8);
> + }
> + } else {
> + /* Store the count of (base, size) duple */
> + ranges[tmp_indx] = rngs_cnt;
> + }
> }
>
> rlen = rlen * sizeof(uint64_t);
> @@ -210,7 +249,8 @@ static void add_dyn_reconf_usable_mem_property(int fd)
> *dt++ = propnum("linux,drconf-usable-memory");
> if ((rlen >= 8) && ((unsigned long)dt & 0x4))
> dt++;
> - memcpy(dt, &ranges, rlen);
> + memcpy(dt, ranges, rlen);
> + free(ranges);
> dt += (rlen + 3)/4;
> }
>
> @@ -218,7 +258,8 @@ static void add_usable_mem_property(int fd, size_t len)
> {
> char fname[MAXPATH], *bname;
> uint64_t buf[2];
> - uint64_t ranges[2*MAX_MEMORY_RANGES];
> + uint64_t *ranges;
> + int ranges_size = MEM_RANGE_CHUNK_SZ;
> uint64_t base, end, loc_base, loc_end;
> size_t range;
> int rlen = 0;
> @@ -247,17 +288,33 @@ static void add_usable_mem_property(int fd, size_t len)
> base = buf[0];
> end = base + buf[1];
>
> + ranges = malloc(ranges_size*8);
> + if (!ranges)
> + die("unrecoverable error: can't alloc %d bytes for ranges.\n",
> + ranges_size*8);
> +
> for (range = 0; range < usablemem_rgns.size; range++) {
> + int add = 0;
> loc_base = usablemem_rgns.ranges[range].start;
> loc_end = usablemem_rgns.ranges[range].end;
> if (loc_base >= base && loc_end <= end) {
> - ranges[rlen++] = loc_base;
> - ranges[rlen++] = loc_end - loc_base;
> + add = 1;
> } else if (base < loc_end && end > loc_base) {
> if (loc_base < base)
> loc_base = base;
> if (loc_end > end)
> loc_end = end;
> + add = 1;
> + }
> + if (add) {
> + if (rlen >= (ranges_size-2)) {
> + ranges_size += MEM_RANGE_CHUNK_SZ;
> + ranges = realloc(ranges, ranges_size*8);
> + if (!ranges)
> + die("unrecoverable error: can't realloc
"
> + "%d bytes for ranges.\n",
> + ranges_size*8);
> + }
> ranges[rlen++] = loc_base;
> ranges[rlen++] = loc_end - loc_base;
> }
> @@ -283,7 +340,8 @@ static void add_usable_mem_property(int fd, size_t len)
> *dt++ = propnum("linux,usable-memory");
> if ((rlen >= 8) && ((unsigned long)dt & 0x4))
> dt++;
> - memcpy(dt,&ranges,rlen);
> + memcpy(dt, ranges, rlen);
> + free(ranges);
> dt += (rlen + 3)/4;
> }
>
> --
> 1.6.3.3
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
^ permalink raw reply
* Re: [PATCH v5] powerpc: Add hibernation support for FSL BookE processors
From: Kumar Gala @ 2010-05-17 21:22 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20100517185652.GA11081@oksana.dev.rtsoft.ru>
On May 17, 2010, at 1:56 PM, Anton Vorontsov wrote:
> This is started as swsusp_32.S modifications, but the amount of =
#ifdefs
> made the whole file horribly unreadable, so let's put the support into
> its own separate file.
>=20
> The code should be relatively easy to modify to support 44x BookEs as
> well, but since I don't have any 44x to test, let's confine the code =
to
> FSL BookE. (The only FSL-specific part so far is 'flush_dcache_L1'.)
>=20
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> Acked-by: Scott Wood <scottwood@freescale.com>
> ---
>=20
> On Mon, May 17, 2010 at 01:12:37PM -0500, Scott Wood wrote:
>> On 04/16/2010 02:03 PM, Anton Vorontsov wrote:
>>> + /* restore the MSR */
>>> + lwz r3,SL_MSR(r11)
>>> +
>>> + /* Restore TB */
>>> + li r3,0
>>=20
>> Missing mtmsr?
>>=20
>> Otherwise ACK.
>=20
> Fixed, thanks!
>=20
> arch/powerpc/kernel/Makefile | 8 +-
> arch/powerpc/kernel/swsusp_booke.S | 193 =
++++++++++++++++++++++++++++++++++++
> 2 files changed, 199 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/kernel/swsusp_booke.S
Is there board specific code to go along with this?
When I enable I get:
arch/powerpc/kernel/built-in.o: In function `cpu_idle':
/home/galak/git/master/powerpc/arch/powerpc/kernel/idle.c:98: undefined =
reference to `cpu_die'
make: *** [.tmp_vmlinux1] Error 1
- k=
^ permalink raw reply
* Re: [PATCH v5] powerpc: Add hibernation support for FSL BookE processors
From: Kumar Gala @ 2010-05-17 21:17 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20100517185652.GA11081@oksana.dev.rtsoft.ru>
On May 17, 2010, at 1:56 PM, Anton Vorontsov wrote:
> This is started as swsusp_32.S modifications, but the amount of =
#ifdefs
> made the whole file horribly unreadable, so let's put the support into
> its own separate file.
>=20
> The code should be relatively easy to modify to support 44x BookEs as
> well, but since I don't have any 44x to test, let's confine the code =
to
> FSL BookE. (The only FSL-specific part so far is 'flush_dcache_L1'.)
>=20
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> Acked-by: Scott Wood <scottwood@freescale.com>
> ---
>=20
> On Mon, May 17, 2010 at 01:12:37PM -0500, Scott Wood wrote:
>> On 04/16/2010 02:03 PM, Anton Vorontsov wrote:
>>> + /* restore the MSR */
>>> + lwz r3,SL_MSR(r11)
>>> +
>>> + /* Restore TB */
>>> + li r3,0
>>=20
>> Missing mtmsr?
>>=20
>> Otherwise ACK.
>=20
> Fixed, thanks!
>=20
> arch/powerpc/kernel/Makefile | 8 +-
> arch/powerpc/kernel/swsusp_booke.S | 193 =
++++++++++++++++++++++++++++++++++++
> 2 files changed, 199 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/kernel/swsusp_booke.S
applied to next (fixed one white space issue).
- k=
^ permalink raw reply
* [PATCH] hwmon: (tmp421) Add nfactor support (2nd attempt)
From: Jeff Angielski @ 2010-05-17 20:30 UTC (permalink / raw)
To: Andre Prendel, linuxppc-dev, Jeff Angielski, lm-sensors
Here is a second attempt at a patch to add nfactor support to the tmp421 driver.
This includes the changes as suggested by Andre Prendel, the original driver author.
>From 8ebe84174ff6bd294656d77183758044f19d8900 Mon Sep 17 00:00:00 2001
From: Jeff Angielski <jeff@theptrgroup.com>
Date: Mon, 10 May 2010 10:26:34 -0400
Subject: [PATCH] hwmon: (tmp421) Add nfactor support
Add support for reading and writing the n-factor correction
registers. This is needed to compensate for the characteristics
of a particular sensor hanging off of the remote channels.
Signed-off-by: Jeff Angielski <jeff@theptrgroup.com>
---
drivers/hwmon/tmp421.c | 41 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/hwmon/tmp421.c b/drivers/hwmon/tmp421.c
index 738c472..ce1f6d1 100644
--- a/drivers/hwmon/tmp421.c
+++ b/drivers/hwmon/tmp421.c
@@ -49,6 +49,7 @@ enum chips { tmp421, tmp422, tmp423 };
static const u8 TMP421_TEMP_MSB[4] = { 0x00, 0x01, 0x02, 0x03 };
static const u8 TMP421_TEMP_LSB[4] = { 0x10, 0x11, 0x12, 0x13 };
+static const u8 TMP421_NFACTOR[3] = { 0x21, 0x22, 0x23 };
/* Flags */
#define TMP421_CONFIG_SHUTDOWN 0x40
@@ -76,6 +77,7 @@ struct tmp421_data {
int channels;
u8 config;
s16 temp[4];
+ s8 nfactor[3];
};
static int temp_from_s16(s16 reg)
@@ -115,6 +117,10 @@ static struct tmp421_data *tmp421_update_device(struct device *dev)
data->temp[i] |= i2c_smbus_read_byte_data(client,
TMP421_TEMP_LSB[i]);
}
+ for (i = 1; i < data->channels; i++) {
+ data->nfactor[i - 1] = i2c_smbus_read_byte_data(client,
+ TMP421_NFACTOR[i - 1]);
+ }
data->last_updated = jiffies;
data->valid = 1;
}
@@ -157,6 +163,32 @@ static ssize_t show_fault(struct device *dev,
return sprintf(buf, "0\n");
}
+static ssize_t show_nfactor(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ int index = to_sensor_dev_attr(devattr)->index;
+ struct tmp421_data *data = tmp421_update_device(dev);
+
+ return sprintf(buf, "%d\n", data->nfactor[index - 1]);
+}
+
+static ssize_t set_nfactor(struct device *dev,
+ struct device_attribute *devattr,
+ const char *buf, size_t count)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct tmp421_data *data = i2c_get_clientdata(client);
+ int index = to_sensor_dev_attr(devattr)->index;
+ int nfactor = simple_strtol(buf, NULL, 10);
+
+ mutex_lock(&data->update_lock);
+ i2c_smbus_write_byte_data(client, TMP421_NFACTOR[index - 1],
+ SENSORS_LIMIT(nfactor, -128, 127));
+ mutex_unlock(&data->update_lock);
+
+ return count;
+}
+
static mode_t tmp421_is_visible(struct kobject *kobj, struct attribute *a,
int n)
{
@@ -177,19 +209,28 @@ static mode_t tmp421_is_visible(struct kobject *kobj, struct attribute *a,
static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp_value, NULL, 0);
static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, show_temp_value, NULL, 1);
static SENSOR_DEVICE_ATTR(temp2_fault, S_IRUGO, show_fault, NULL, 1);
+static SENSOR_DEVICE_ATTR(temp2_nfactor, S_IRUSR | S_IWUSR | S_IRGRP,
+ show_nfactor, set_nfactor, 1);
static SENSOR_DEVICE_ATTR(temp3_input, S_IRUGO, show_temp_value, NULL, 2);
static SENSOR_DEVICE_ATTR(temp3_fault, S_IRUGO, show_fault, NULL, 2);
+static SENSOR_DEVICE_ATTR(temp3_nfactor, S_IRUSR | S_IWUSR | S_IRGRP,
+ show_nfactor, set_nfactor, 2);
static SENSOR_DEVICE_ATTR(temp4_input, S_IRUGO, show_temp_value, NULL, 3);
static SENSOR_DEVICE_ATTR(temp4_fault, S_IRUGO, show_fault, NULL, 3);
+static SENSOR_DEVICE_ATTR(temp4_nfactor, S_IRUSR | S_IWUSR | S_IRGRP,
+ show_nfactor, set_nfactor, 3);
static struct attribute *tmp421_attr[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr,
&sensor_dev_attr_temp2_input.dev_attr.attr,
&sensor_dev_attr_temp2_fault.dev_attr.attr,
+ &sensor_dev_attr_temp2_nfactor.dev_attr.attr,
&sensor_dev_attr_temp3_input.dev_attr.attr,
&sensor_dev_attr_temp3_fault.dev_attr.attr,
+ &sensor_dev_attr_temp3_nfactor.dev_attr.attr,
&sensor_dev_attr_temp4_input.dev_attr.attr,
&sensor_dev_attr_temp4_fault.dev_attr.attr,
+ &sensor_dev_attr_temp4_nfactor.dev_attr.attr,
NULL
};
--
Jeff Angielski
The PTR Group
www.theptrgroup.com
^ permalink raw reply related
* Re: mpc870 support in the powerpc arch?
From: Scott Wood @ 2010-05-17 19:54 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTikk8-jiDZNtP8eucP90DLYRALwu749H-3v9LsHI@mail.gmail.com>
On Fri, May 14, 2010 at 02:41:29PM -0700, Shawn Jin wrote:
> Hi,
>
> Is mpc870 fully supported in the powerpc arch? I know it's an old
> processor but 8xx is still one of platforms in the powerpc arch. If
> it's not supported, how much effort will it be to resurrect mpc870 in
> the new arch considering we have substantial 8xx support?
It should work, with appropriate board support -- MPC875 and MPC885 have
been used with arch/powerpc, and MPC870 is very similar (albeit with fewer
devices).
-Scott
^ permalink raw reply
* Re: [RFC PATCH v2 1/2] powerpc: cleanup APIs for cpu/thread/core mappings
From: Vaidyanathan Srinivasan @ 2010-05-17 18:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Anton Blanchard, linuxppc-dev
In-Reply-To: <20100510054801.GG5612@dirshya.in.ibm.com>
* Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> [2010-05-10 11:18:01]:
> * Paul Mackerras <paulus@samba.org> [2010-05-10 09:05:22]:
>
> > On Fri, May 07, 2010 at 05:18:42PM +0530, Vaidyanathan Srinivasan wrote:
> >
> > > These APIs take logical cpu number as input
> > > Change cpu_first_thread_in_core() to cpu_leftmost_thread_sibling()
> > > Change cpu_last_thread_in_core() to cpu_rightmost_thread_sibling()
> > >
> > > These APIs convert core number (index) to logical cpu/thread numbers
> > > Add cpu_first_thread_of_core(int core)
> > > Changed cpu_thread_to_core() to cpu_core_of_thread(int cpu)
> >
> > Why make all these changes? The end result doesn't seem any cleaner
> > or better than how it was before, and your patch description doesn't
> > give any reason for us to think "yes, we should make this change".
> > I assume you think this is a good change to make, so you need to
> > explain why it's a good idea and convince the rest of us.
>
> Sure Paul.. let me explain. The crux of the issue is to make
> 'threads_per_core' accessible to the pseries_energy module. In the
> first RFC, I had directly exported the variable which is not a good
> design. Ben H suggested to make an API around it and then export the
> function:
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-April/081610.html
>
> Instead of making an API to read threads_per_core, as Ben suggested,
> I have made a wrapper at a higher level to make an API to convert from
> logical cpu number to core number.
>
> The current APIs cpu_first_thread_in_core() and
> cpu_last_thread_in_core() returns logical CPU number while
> cpu_thread_to_core() returns core number or index which is not
> a logical CPU number.
>
> Ben recommended to clearly name them to distinguish 'core number'
> versus first and last 'logical cpu number' in that core.
>
> Hence in the new scheme, I have:
>
> > > Change cpu_first_thread_in_core() to cpu_leftmost_thread_sibling()
> > > Change cpu_last_thread_in_core() to cpu_rightmost_thread_sibling()
>
> which work on logical cpu numbers.
> While cpu_first_thread_of_core() and cpu_core_of_thread() work on core
> index.
>
> Example usage: (4 threads per core system)
>
> cpu_leftmost_thread_sibling(5) = 4
> cpu_rightmost_thread_sibling(5) = 7
> cpu_core_of_thread(5) = 1
> cpu_first_thread_of_core(1) = 4
>
> cpu_core_of_thread() is used in cpu_to_drc_index() in the module and
> cpu_first_thread_of_core() is used in drc_index_to_cpu() in the
> module. These APIs may be useful in other modules in future, and the
> proposed design is a good method to export these APIs to modules.
>
> An alternative approach could be to move both the base functions
> cpu_to_drc_index() and drc_index_to_cpu() into the kernel like in
> arch/powerpc/kernel/smp.c
>
> Thanks for the review, I hope I have explained the requirements and
> design for this cleanup.
Hi Paul and Ben,
Do you have any further comments on this patch series and related
cleanup? I will post the next iteration in a day or two.
Thanks,
Vaidy
^ permalink raw reply
* [PATCH v5] powerpc: Add hibernation support for FSL BookE processors
From: Anton Vorontsov @ 2010-05-17 18:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4BF18715.8050201@freescale.com>
This is started as swsusp_32.S modifications, but the amount of #ifdefs
made the whole file horribly unreadable, so let's put the support into
its own separate file.
The code should be relatively easy to modify to support 44x BookEs as
well, but since I don't have any 44x to test, let's confine the code to
FSL BookE. (The only FSL-specific part so far is 'flush_dcache_L1'.)
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Acked-by: Scott Wood <scottwood@freescale.com>
---
On Mon, May 17, 2010 at 01:12:37PM -0500, Scott Wood wrote:
> On 04/16/2010 02:03 PM, Anton Vorontsov wrote:
> >+ /* restore the MSR */
> >+ lwz r3,SL_MSR(r11)
> >+
> >+ /* Restore TB */
> >+ li r3,0
>
> Missing mtmsr?
>
> Otherwise ACK.
Fixed, thanks!
arch/powerpc/kernel/Makefile | 8 +-
arch/powerpc/kernel/swsusp_booke.S | 193 ++++++++++++++++++++++++++++++++++++
2 files changed, 199 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/kernel/swsusp_booke.S
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 8773263..58d0572 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -57,8 +57,12 @@ obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_E500) += idle_e500.o
obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
obj-$(CONFIG_TAU) += tau_6xx.o
-obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o \
- swsusp_$(CONFIG_WORD_SIZE).o
+obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o
+ifeq ($(CONFIG_FSL_BOOKE),y)
+obj-$(CONFIG_HIBERNATION) += swsusp_booke.o
+else
+obj-$(CONFIG_HIBERNATION) += swsusp_$(CONFIG_WORD_SIZE).o
+endif
obj64-$(CONFIG_HIBERNATION) += swsusp_asm64.o
obj-$(CONFIG_MODULES) += module.o module_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_44x) += cpu_setup_44x.o
diff --git a/arch/powerpc/kernel/swsusp_booke.S b/arch/powerpc/kernel/swsusp_booke.S
new file mode 100644
index 0000000..b674d6d
--- /dev/null
+++ b/arch/powerpc/kernel/swsusp_booke.S
@@ -0,0 +1,193 @@
+/*
+ * Based on swsusp_32.S, modified for FSL BookE by
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
+ * Copyright (c) 2009-2010 MontaVista Software, LLC.
+ */
+
+#include <linux/threads.h>
+#include <asm/processor.h>
+#include <asm/page.h>
+#include <asm/cputable.h>
+#include <asm/thread_info.h>
+#include <asm/ppc_asm.h>
+#include <asm/asm-offsets.h>
+#include <asm/mmu.h>
+
+/*
+ * Structure for storing CPU registers on the save area.
+ */
+#define SL_SP 0
+#define SL_PC 4
+#define SL_MSR 8
+#define SL_TCR 0xc
+#define SL_SPRG0 0x10
+#define SL_SPRG1 0x14
+#define SL_SPRG2 0x18
+#define SL_SPRG3 0x1c
+#define SL_SPRG4 0x20
+#define SL_SPRG5 0x24
+#define SL_SPRG6 0x28
+#define SL_SPRG7 0x2c
+#define SL_TBU 0x30
+#define SL_TBL 0x34
+#define SL_R2 0x38
+#define SL_CR 0x3c
+#define SL_LR 0x40
+#define SL_R12 0x44 /* r12 to r31 */
+#define SL_SIZE (SL_R12 + 80)
+
+ .section .data
+ .align 5
+
+_GLOBAL(swsusp_save_area)
+ .space SL_SIZE
+
+
+ .section .text
+ .align 5
+
+_GLOBAL(swsusp_arch_suspend)
+ lis r11,swsusp_save_area@h
+ ori r11,r11,swsusp_save_area@l
+
+ mflr r0
+ stw r0,SL_LR(r11)
+ mfcr r0
+ stw r0,SL_CR(r11)
+ stw r1,SL_SP(r11)
+ stw r2,SL_R2(r11)
+ stmw r12,SL_R12(r11)
+
+ /* Save MSR & TCR */
+ mfmsr r4
+ stw r4,SL_MSR(r11)
+ mfspr r4,SPRN_TCR
+ stw r4,SL_TCR(r11)
+
+ /* Get a stable timebase and save it */
+1: mfspr r4,SPRN_TBRU
+ stw r4,SL_TBU(r11)
+ mfspr r5,SPRN_TBRL
+ stw r5,SL_TBL(r11)
+ mfspr r3,SPRN_TBRU
+ cmpw r3,r4
+ bne 1b
+
+ /* Save SPRGs */
+ mfsprg r4,0
+ stw r4,SL_SPRG0(r11)
+ mfsprg r4,1
+ stw r4,SL_SPRG1(r11)
+ mfsprg r4,2
+ stw r4,SL_SPRG2(r11)
+ mfsprg r4,3
+ stw r4,SL_SPRG3(r11)
+ mfsprg r4,4
+ stw r4,SL_SPRG4(r11)
+ mfsprg r4,5
+ stw r4,SL_SPRG5(r11)
+ mfsprg r4,6
+ stw r4,SL_SPRG6(r11)
+ mfsprg r4,7
+ stw r4,SL_SPRG7(r11)
+
+ /* Call the low level suspend stuff (we should probably have made
+ * a stackframe...
+ */
+ bl swsusp_save
+
+ /* Restore LR from the save area */
+ lis r11,swsusp_save_area@h
+ ori r11,r11,swsusp_save_area@l
+ lwz r0,SL_LR(r11)
+ mtlr r0
+
+ blr
+
+_GLOBAL(swsusp_arch_resume)
+ sync
+
+ /* Load ptr the list of pages to copy in r3 */
+ lis r11,(restore_pblist)@h
+ ori r11,r11,restore_pblist@l
+ lwz r3,0(r11)
+
+ /* Copy the pages. This is a very basic implementation, to
+ * be replaced by something more cache efficient */
+1:
+ li r0,256
+ mtctr r0
+ lwz r5,pbe_address(r3) /* source */
+ lwz r6,pbe_orig_address(r3) /* destination */
+2:
+ lwz r8,0(r5)
+ lwz r9,4(r5)
+ lwz r10,8(r5)
+ lwz r11,12(r5)
+ addi r5,r5,16
+ stw r8,0(r6)
+ stw r9,4(r6)
+ stw r10,8(r6)
+ stw r11,12(r6)
+ addi r6,r6,16
+ bdnz 2b
+ lwz r3,pbe_next(r3)
+ cmpwi 0,r3,0
+ bne 1b
+
+ bl flush_dcache_L1
+ bl flush_instruction_cache
+
+ lis r11,swsusp_save_area@h
+ ori r11,r11,swsusp_save_area@l
+
+ lwz r4,SL_SPRG0(r11)
+ mtsprg 0,r4
+ lwz r4,SL_SPRG1(r11)
+ mtsprg 1,r4
+ lwz r4,SL_SPRG2(r11)
+ mtsprg 2,r4
+ lwz r4,SL_SPRG3(r11)
+ mtsprg 3,r4
+ lwz r4,SL_SPRG4(r11)
+ mtsprg 4,r4
+ lwz r4,SL_SPRG5(r11)
+ mtsprg 5,r4
+ lwz r4,SL_SPRG6(r11)
+ mtsprg 6,r4
+ lwz r4,SL_SPRG7(r11)
+ mtsprg 7,r4
+
+ /* restore the MSR */
+ lwz r3,SL_MSR(r11)
+ mtmsr r3
+
+ /* Restore TB */
+ li r3,0
+ mtspr SPRN_TBWL,r3
+ lwz r3,SL_TBU(r11)
+ lwz r4,SL_TBL(r11)
+ mtspr SPRN_TBWU,r3
+ mtspr SPRN_TBWL,r4
+
+ /* Restore TCR and clear any pending bits in TSR. */
+ lwz r4,SL_TCR(r11)
+ mtspr SPRN_TCR,r4
+ lis r4, (TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS)@h
+ mtspr SPRN_TSR,r4
+
+ /* Kick decrementer */
+ li r0,1
+ mtdec r0
+
+ /* Restore the callee-saved registers and return */
+ lwz r0,SL_CR(r11)
+ mtcr r0
+ lwz r2,SL_R2(r11)
+ lmw r12,SL_R12(r11)
+ lwz r1,SL_SP(r11)
+ lwz r0,SL_LR(r11)
+ mtlr r0
+
+ li r3,0
+ blr
--
1.7.0.5
^ permalink raw reply related
* Re: [PATCH 2/3] powerpc/fsl: 85xx: p2020rdb: add cache sram node
From: Kumar Gala @ 2010-05-17 18:49 UTC (permalink / raw)
To: Gupta Maneesh-B18878; +Cc: linuxppc-dev
In-Reply-To: <1260257477-21942-2-git-send-email-vivek.mahajan@freescale.com>
On Dec 8, 2009, at 1:31 AM, Vivek Mahajan wrote:
> Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
> ---
> arch/powerpc/boot/dts/p2020rdb.dts | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/boot/dts/p2020rdb.dts =
b/arch/powerpc/boot/dts/p2020rdb.dts
> index da4cb0d..8a26050 100644
> --- a/arch/powerpc/boot/dts/p2020rdb.dts
> +++ b/arch/powerpc/boot/dts/p2020rdb.dts
> @@ -583,4 +583,10 @@
> 0x0 0x100000>;
> };
> };
> +
> + cache-sram@fff00000 {
> + fsl,cache-sram-ctlr-handle =3D <&L2>;
> + reg =3D <0 0xfff00000 0 0x10000>;
> + compatible =3D "fsl,p2020-cache-sram";
> + };
> };
> --=20
> 1.5.6.5
Sorry, we've let this sit too long:
This should be created by u-boot instead of static in the .dts. The =
assumption should be the cache/SRAM is already setup this way via u-boot =
and its just conveying the HW config to the kernel.
In the future we should have the kernel dynamically allocate a physical =
address region for the SRAM (if its not already setup by u-boot).
- k=
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/fsl: 85xx: document cache sram bindings
From: Kumar Gala @ 2010-05-17 18:48 UTC (permalink / raw)
To: Gupta Maneesh-B18878; +Cc: linuxppc-dev
In-Reply-To: <1260257477-21942-1-git-send-email-vivek.mahajan@freescale.com>
On Dec 8, 2009, at 1:31 AM, Vivek Mahajan wrote:
> Adds binding documentation for cache sram for the PQ3 and
> some QorIQ based platforms.
>=20
> Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
> ---
> .../powerpc/dts-bindings/fsl/85xx_cache_sram.txt | 20 =
++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
> create mode 100644 =
Documentation/powerpc/dts-bindings/fsl/85xx_cache_sram.txt
This looks fine, I'm going to rename the file when I apply this patch =
since its applicable to more than 85xx.
- k=
^ permalink raw reply
* Re: [PATCH v2] powerpc/e500mc: Implement machine check handler.
From: Kumar Gala @ 2010-05-17 18:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <1270705102-18343-1-git-send-email-galak@kernel.crashing.org>
On Apr 8, 2010, at 12:38 AM, Kumar Gala wrote:
> From: Scott Wood <scottwood@freescale.com>
>=20
> Most of the MSCR bit assigments are different in e500mc versus
> e500, and they are now write-one-to-clear.
>=20
> Some e500mc machine check conditions are made recoverable (as long as
> they aren't stuck on), most notably L1 instruction cache parity =
errors.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> * Fix build error
>=20
> arch/powerpc/include/asm/cputable.h | 1 +
> arch/powerpc/include/asm/reg_booke.h | 33 +++++++++----
> arch/powerpc/kernel/cputable.c | 2 +-
> arch/powerpc/kernel/traps.c | 88 =
+++++++++++++++++++++++++++++++++-
> 4 files changed, 112 insertions(+), 12 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Kumar Gala @ 2010-05-17 18:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.1005132327390.30346@localhost.localdomain>
On May 13, 2010, at 11:28 PM, Kumar Gala wrote:
> The following changes since commit =
131c6c9eddfa252e376edb4aeff9c7fe1b96a798:
> Benjamin Herrenschmidt (1):
> Merge commit 'kumar/merge' into merge
>=20
> are available in the git repository at:
>=20
> git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git merge
>=20
> Kumar Gala (1):
> powerpc/fsl-booke: Move loadcam_entry back to asm code to fix SMP =
ftrace
>=20
> Li Yang (1):
> powerpc/fsl-booke: Fix InstructionTLBError execute permission =
check
>=20
> arch/powerpc/kernel/asm-offsets.c | 8 ++++++++
> arch/powerpc/kernel/head_fsl_booke.S | 13 ++++++++++---
> arch/powerpc/mm/fsl_booke_mmu.c | 25 +++----------------------
> arch/powerpc/mm/mmu_decl.h | 10 +++++++++-
> arch/powerpc/mm/tlb_nohash_low.S | 28 =
++++++++++++++++++++++++++++
> 5 files changed, 58 insertions(+), 26 deletions(-)
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
I've just moved these into my next branch. Will send them to stable =
once they get pulled into .35.
- k=
^ permalink raw reply
* Re: [PATCH v4] powerpc: Add hibernation support for FSL BookE processors
From: Scott Wood @ 2010-05-17 18:12 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20100416190319.GA4104@oksana.dev.rtsoft.ru>
On 04/16/2010 02:03 PM, Anton Vorontsov wrote:
> + /* restore the MSR */
> + lwz r3,SL_MSR(r11)
> +
> + /* Restore TB */
> + li r3,0
Missing mtmsr?
Otherwise ACK.
-Scott
^ permalink raw reply
* Re: [PATCH v3 3/3] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Scott Wood @ 2010-05-17 18:05 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, devicetree-discuss, linuxppc-dev
In-Reply-To: <20100517082757.GA9703@riccoc20.at.omicron.at>
On 05/17/2010 03:27 AM, Richard Cochran wrote:
> On Fri, May 14, 2010 at 12:46:57PM -0500, Scott Wood wrote:
>> On 05/14/2010 11:46 AM, Richard Cochran wrote:
>>> diff --git a/Documentation/powerpc/dts-bindings/fsl/tsec.txt b/Documentation/powerpc/dts-bindings/fsl/tsec.txt
>>
>> Get rid of both device_type and model, and specify a compatible
>> string instead (e.g. "fsl,etsec-ptp").
>
> Okay, will do. I really am at a loss at understanding all the rules in
> the whole device tree world. I just tried to follow
> Documentation/powerpc and what is already present in the kernel.
There's some stuff in there that isn't how we'd do it now, but is slow
to change for compatibility reasons.
>> Or perhaps this should just be some additional properties on the
>> existing gianfar nodes, rather than presenting it as a separate
>> device? How do you associate a given ptp block with the
>> corresponding gianfar node?
>
> There only one PTP clock. Its registers repeat in each port's memory
> space, but you are only supposed to touch the first set of PTP
> registers.
OK. I'm not too familiar with PTP itself, was looking more at the
device tree and similar structural bits.
> There are no differences (that I know of) in how the PTP clocks
> work. I have in house the mpc8313, the mpc8572, and the p2020. The
> mpc8572 appears to lack some of the TMR_CTRL bits, but this is
> probably a documentation bug. I will check it.
If there's any possibility of needing to make a distinction (which
probably can't be ruled out with future chips), the chip name could be
made part of the compatible string, with a secondary compatible showing
a canonical part name for that version of the PTP block. E.g. p2020
might have:
compatble = "fsl,p2020-etsec-ptp", "fsl,mpc8313-etsec-ptp";
The driver would bind only on the mpc8313 version.
There are several examples of this, such as the Freescale i2c driver and
binding (ignore the legacy "fsl-i2c").
>> > >+ - tmr_fiper1 Fixed interval period pulse generator.
>> > >+ - tmr_fiper2 Fixed interval period pulse generator.
>>
MPC8572 and P2020 have fiper3 as well.
>> They should probably have an "fsl,ptp-" prefix as well.
>
> Okay, but must I then change the following code in order to find them?
> Does adding the prefix just mean that I also add it to my search
> strings, or is it preprocessed (stripped) somehow?
It is not stripped; you have to change the code as well.
>> You've got two IRQs, with the same handler, and the same dev_id?
>> From the manual it looks like there's one PTP interrupt per eTSEC
>> (which would explain 3 interrupts on p2020).
>
> Will reduce to just one IRQ.
The device tree should still contain all of the interrupts, in case
they're needed later -- and put a comment in the driver saying why the
first interrupt seems sufficient.
>>> +static struct of_device_id match_table[] = {
>>> + { .type = "ptp_clock" },
>>> + {},
>>> +};
>>
>> This driver controls every possible PTP implementation?
>
> No, I only want to match with the eTSEC clock device. Given the
> compatible string above ("fsl,etsec-ptp"), what is the correct way to
> do this? (pointer to an existing driver to emulate would be enough)
Put .compatible = "fsl,etsec-ptp" (or "fsl,mpc8313-etsec-ptp") where you
have .type = "ptp_clock".
-Scott
^ permalink raw reply
* Re: [PATCH v4] powerpc: Add hibernation support for FSL BookE processors
From: Kumar Gala @ 2010-05-17 18:03 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list, Anton Vorontsov
In-Reply-To: <20100416190319.GA4104@oksana.dev.rtsoft.ru>
On Apr 16, 2010, at 2:03 PM, Anton Vorontsov wrote:
> This is started as swsusp_32.S modifications, but the amount of =
#ifdefs
> made the whole file horribly unreadable, so let's put the support into
> its own separate file.
>=20
> The code should be relatively easy to modify to support 44x BookEs as
> well, but since I don't have any 44x to test, let's confine the code =
to
> FSL BookE. (The only FSL-specific part so far is 'flush_dcache_L1'.)
>=20
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
>=20
> On Fri, Apr 16, 2010 at 10:54:36AM -0500, Scott Wood wrote:
>> Anton Vorontsov wrote:
>>> + /* Invalidate TLB0 & TLB1 */
>>> + li r6,0x04
>>> + tlbivax 0,r6
>>> + TLBSYNC
>>> + li r6,0x0c
>>> + tlbivax 0,r6
>>> + TLBSYNC
>>=20
>> Is this needed? Shouldn't the boot process have already given us a
>> sane TLB?
>=20
> Thanks for catching, it seems that it's just a left over from
> some debugging code and not actually needed. ..that reminded me
> the time I spent inserting BookE specific code into swsusp_32.S,
> and then debugging all that #ifdef mess...
>=20
> This is tested on e500v2.
>=20
> arch/powerpc/kernel/Makefile | 8 +-
> arch/powerpc/kernel/swsusp_booke.S | 192 =
++++++++++++++++++++++++++++++++++++
> 2 files changed, 198 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/kernel/swsusp_booke.S
Scott, you ok (ACK) this version or still need tweaks?
- k=
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/8610: add probing for individual DMA channels, not just DMA controllers
From: Kumar Gala @ 2010-05-17 15:55 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel, broonie, lrg
In-Reply-To: <1272923655-31807-1-git-send-email-timur@freescale.com>
On May 3, 2010, at 4:54 PM, Timur Tabi wrote:
> A future version of the MPC8610 HPCD's ASoC DMA driver will probe on =
individual
> DMA channel nodes, so the DMA controller nodes' compatible string must =
be listed
> in mpc8610_ids[] for the probe to work.
>=20
> Also remove the "gianfar" compatible from mpc8610_ids[], since there =
is no
> gianfar (or any other networking device) on the 8610.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> Kumar, the ASoC mainters are willing to pick up this patch, but they =
want an
> ACK from you first. Or, you could pick it up, since by itself it's =
harmless.
>=20
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/83xx: Add MCU LEDs support for MPC837xRDB and MPC8315RDB boards
From: Kumar Gala @ 2010-05-17 15:55 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20100502172705.GA22021@oksana.dev.rtsoft.ru>
On May 2, 2010, at 12:27 PM, Anton Vorontsov wrote:
> There are two front-panel LEDs on MPC837xRDB and MPC8315RDB boards: PWR
> and HDD. After adding appropriate nodes we can program these LEDs from
> kernel and user space.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
> arch/powerpc/boot/dts/mpc8315erdb.dts | 14 ++++++++++++++
> arch/powerpc/boot/dts/mpc8377_rdb.dts | 14 ++++++++++++++
> arch/powerpc/boot/dts/mpc8378_rdb.dts | 14 ++++++++++++++
> arch/powerpc/boot/dts/mpc8379_rdb.dts | 14 ++++++++++++++
> arch/powerpc/platforms/83xx/mpc831x_rdb.c | 1 +
> arch/powerpc/platforms/83xx/mpc837x_rdb.c | 1 +
> 6 files changed, 58 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Fix P1020RDB boot hang due USB2
From: Kumar Gala @ 2010-05-17 15:55 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20100422154447.GA30785@oksana.dev.rtsoft.ru>
On Apr 22, 2010, at 10:44 AM, Anton Vorontsov wrote:
> Since USB2 is shared with local bus, either local bus or USB2
> should be disabled. By default U-Boot enables local bus, so we
> have to disable USB2, otherwise kernel hangs:
>
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
> fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
> fsl-ehci fsl-ehci.0: irq 28, io base 0xffe22000
> fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
> fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
> <hangs here>
>
> Note that U-Boot doesn't clear 'status' property when it enables
> USB2, so we have to comment out the whole node.
>
> To enable USB2, one can issue
> 'setenv hwconfig usb2:dr_mode=<host|peripheral>' command at the
> U-Boot prompt.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
> arch/powerpc/boot/dts/p1020rdb.dts | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH-V3] mpc8xxx_gpio: add interrupt support
From: Kumar Gala @ 2010-05-17 15:55 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: avorontsov, linuxppc-dev
In-Reply-To: <1262883466-29371-1-git-send-email-jacmet@sunsite.dk>
On Jan 7, 2010, at 10:57 AM, Peter Korsgaard wrote:
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> ---
> Changes since v1:
> - Document OF binding for IRQ as requested by Kumar.
>=20
> Changes since v2:
> - Fix xlate prototype mismatch warning (intspec should be const)
>=20
> .../powerpc/dts-bindings/fsl/8xxx_gpio.txt | 22 +++-
> arch/powerpc/sysdev/mpc8xxx_gpio.c | 147 =
++++++++++++++++++++
> 2 files changed, 168 insertions(+), 1 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Add eTSEC 2.0 support for P1020RDB boards
From: Kumar Gala @ 2010-05-17 15:53 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Felix Radensky, Aggrwal Poonam-B10812,
Sandeep Gopalpet
In-Reply-To: <20100415183631.GA25923@oksana.dev.rtsoft.ru>
On Apr 15, 2010, at 1:36 PM, Anton Vorontsov wrote:
> This patch adds support for eTSEC 2.0 as found in P1020.
> The changes include introduction of the group nodes for
> the etsec nodes.
>=20
> Signed-off-by: Sandeep Gopalpet <sandeep.kumar@freescale.com>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
>=20
> This is based on
> =
http://www.bitshrine.org/gpp/kernel-2.6.32-rc3-P1020RDB-DTS-Support-for-eT=
SEC-2.0-v0.patch
> but revamped for the mainline's OF bindings.
>=20
> arch/powerpc/boot/dts/p1020rdb.dts | 119 =
++++++++++++++++++++++++++++++++++++
> 1 files changed, 119 insertions(+), 0 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] powerpc: remove tls_ssl_stream descriptor type capability in sec3.3 node
From: Kumar Gala @ 2010-05-17 15:51 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20100422192513.27ce5356.kim.phillips@freescale.com>
On Apr 22, 2010, at 7:25 PM, Kim Phillips wrote:
> Technically, whilst SEC v3.3 h/w honours the tls_ssl_stream descriptor
> type, it lacks the ARC4 algorithm execution unit required to be able
> to execute anything meaningful with it. Change the node to agree with
> the documentation that declares that the sec3.3 really doesn't have such
> a descriptor type.
>
> Reported-by: Haiying Wang <Haiying.Wang@freescale.com>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8315erdb.dts | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH v3 3/3] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Wolfgang Grandegger @ 2010-05-17 15:41 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, devicetree-discuss, linuxppc-dev
In-Reply-To: <ee6c3edca3ee6aa86565e59da999375f79c9de1b.1273855017.git.richard.cochran@omicron.at>
On 05/14/2010 06:46 PM, Richard Cochran wrote:
> The eTSEC includes a PTP clock with quite a few features. This patch adds
> support for the basic clock adjustment functions, plus two external time
> stamps and one alarm.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Tested-by: Wolfgang Grandegger <wg@denx.de>
on my Freescale MPC8313 setup with ptpd and ptpv2d.
FYI: checkplatch.pl reports various errors for this patch series.
Wolfgang.
^ 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