[PATCH v2 1/4] fsl_rio: fix compile errors
Fixes the following compile problem on E500 platforms:
arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception':
arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared (first use in
this function)
Also fixes the compile problem on non-E500 platforms.
Signed-off-by: Li Yang le...@freescale.com
---
arch/powerpc/sysdev/fsl_rio.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 30e1626..f908ba6 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -240,12 +240,13 @@ struct rio_priv {
static void __iomem *rio_regs_win;
+#ifdef CONFIG_E500
static int (*saved_mcheck_exception)(struct pt_regs *regs);
static int fsl_rio_mcheck_exception(struct pt_regs *regs)
{
const struct exception_table_entry *entry = NULL;
- unsigned long reason = (mfspr(SPRN_MCSR) MCSR_MASK);
+ unsigned long reason = mfspr(SPRN_MCSR);
if (reason MCSR_BUS_RBERR) {
reason = in_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR));
@@ -269,6 +270,7 @@ static int fsl_rio_mcheck_exception(struct pt_regs *regs)
else
return cur_cpu_spec-machine_check(regs);
}
+#endif
/**
* fsl_rio_doorbell_send - Send a MPC85xx doorbell message
@@ -1517,8 +1519,10 @@ int fsl_rio_setup(struct of_device *dev)
fsl_rio_doorbell_init(port);
fsl_rio_port_write_init(port);
+#ifdef CONFIG_E500
saved_mcheck_exception = ppc_md.machine_check_exception;
ppc_md.machine_check_exception = fsl_rio_mcheck_exception;
+#endif
/* Ensure that RFXE is set */
mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2));
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/4] fsl_rio: fix machine check exception for e500mc
The original code only covers e500 v1/v2.
Signed-off-by: Li Yang le...@freescale.com
---
arch/powerpc/sysdev/fsl_rio.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index f908ba6..954a754 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -248,7 +248,8 @@ static int fsl_rio_mcheck_exception(struct pt_regs *regs)
const struct exception_table_entry *entry = NULL;
unsigned long reason = mfspr(SPRN_MCSR);
- if (reason MCSR_BUS_RBERR) {
+ /* covers both e500v1/v2 and e500mc */
+ if (reason (MCSR_BUS_RBERR | MCSR_LD)) {
reason = in_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR));
if (reason (RIO_LTLEDCSR_IER | RIO_LTLEDCSR_PRT)) {
/* Check if we are prepared to handle this fault */
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 4/4] fsl_rio: fix non-standard HID1 register access
The access to HID1 register is only legitimate for e500 v1/v2 cores. Also fixes magic number. Signed-off-by: Li Yang le...@freescale.com --- arch/powerpc/sysdev/fsl_rio.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index 954a754..aa9a21d 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -1523,9 +1523,12 @@ int fsl_rio_setup(struct of_device *dev) #ifdef CONFIG_E500 saved_mcheck_exception = ppc_md.machine_check_exception; ppc_md.machine_check_exception = fsl_rio_mcheck_exception; -#endif - /* Ensure that RFXE is set */ - mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2)); + +#ifndef CONFIG_PPC_E500MC + /* Ensure that RFXE is set on e500 v1/v2 */ + mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | HID1_RFXE)); +#endif /* !PPC_E500MC */ +#endif /* E500 */ return 0; err: -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 3/4] powerpc: add e500 HID1 bit definition
Also make 74xx HID1 definition conditional. Signed-off-by: Li Yang le...@freescale.com --- arch/powerpc/include/asm/reg.h |2 ++ arch/powerpc/include/asm/reg_booke.h | 16 2 files changed, 18 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index d62fdf4..235d356 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -283,6 +283,7 @@ #define HID0_NOPTI (10) /* No-op dcbt and dcbst instr. */ #define SPRN_HID1 0x3F1 /* Hardware Implementation Register 1 */ +#ifdef CONFIG_6xx #define HID1_EMCP (131) /* 7450 Machine Check Pin Enable */ #define HID1_DFS (122) /* 7447A Dynamic Frequency Scaling */ #define HID1_PC0 (116) /* 7450 PLL_CFG[0] */ @@ -292,6 +293,7 @@ #define HID1_SYNCBE(111) /* 7450 ABE for sync, eieio */ #define HID1_ABE (110) /* 7450 Address Broadcast Enable */ #define HID1_PS(116) /* 750FX PLL selection */ +#endif #define SPRN_HID2 0x3F8 /* Hardware Implementation Register 2 */ #define SPRN_HID2_GEKKO0x398 /* Gekko HID2 Register */ #define SPRN_IABR 0x3F2 /* Instruction Address Breakpoint Register */ diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index 2360317..6d393f7 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -245,6 +245,22 @@ store or cache line push */ #endif +/* Bit definitions for the HID1 */ +#ifdef CONFIG_E500 +#ifndef CONFIG_PPC_E500MC +/* e500v1/v2 */ +#define HID1_PLL_CFG_MASK 0xfc00UL /* PLL_CFG input pins */ +#define HID1_RFXE 0x0002UL/* Read fault exception enable */ +#define HID1_R1DPE 0x8000UL/* R1 data bus parity enable */ +#define HID1_R2DPE 0x4000UL/* R2 data bus parity enable */ +#define HID1_ASTME 0x2000UL/* Address bus streaming mode enable */ +#define HID1_ABE 0x1000UL/* Address broadcast enable */ +#define HID1_MPXTT 0x0400UL/* MPX re-map transfer type */ +#define HID1_ATS 0x0080UL/* Atomic status */ +#define HID1_MID_MASK 0x000fUL/* MID input pins */ +#endif +#endif + /* Bit definitions for the DBSR. */ /* * DBSR bits which have conflicting definitions on true Book E versus IBM 40x. -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code
On Sat, Jun 12, 2010 at 02:27:12PM +0800, Barry Song wrote:
On Wed, Aug 19, 2009 at 5:46 AM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
Previosly the driver always tried JEDEC probing, assuming that non-JEDEC
chips will return '0'. But truly non-JEDEC chips (like CAT25) won't do
that, their behaviour on RDID command is undefined, so the driver should
not call jedec_probe() for these chips.
Also, be less strict on error conditions, don't fail to probe if JEDEC
found a chip that is different from what platform code told, instead
just print some warnings and use an information obtained via JEDEC. In
This patch caused a problem:
even though the external flash doesn't exist, it will still pass the
probe() and be registerred into kernel and given the partition table.
You may refer to this bug report:
http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdittracker_item_id=5975start=0
Thanks for the report.
There's little we can do about it. Platform code asked us
to register the device, and JEDEC probing of M25Pxx chips isn't
reliable (thanks to various vendors that make these JEDEC and
non-JEDEC variants), so the best thing we can do is to register
the chip anyway.
OTOH, if the board pulls MISO line up, then the following patch
should help.
If this won't work, we'll have to add some flag to the platform
data, i.e. to force JEDEC probing, and not trust platform data.
Not-yet-Signed-off-by: Anton Vorontsov cbouatmai...@gmail.com
---
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..a307929 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -16,6 +16,7 @@
*/
#include linux/init.h
+#include linux/errno.h
#include linux/module.h
#include linux/device.h
#include linux/interrupt.h
@@ -723,7 +724,7 @@ static const struct spi_device_id *__devinit
jedec_probe(struct spi_device *spi)
if (tmp 0) {
DEBUG(MTD_DEBUG_LEVEL0, %s: error %d reading JEDEC ID\n,
dev_name(spi-dev), tmp);
- return NULL;
+ return ERR_PTR(tmp);
}
jedec = id[0];
jedec = jedec 8;
@@ -737,7 +738,7 @@ static const struct spi_device_id *__devinit
jedec_probe(struct spi_device *spi)
* exist for non-JEDEC chips, but for compatibility they return ID 0.
*/
if (jedec == 0)
- return NULL;
+ return ERR_PTR(-EEXIST);
ext_jedec = id[3] 8 | id[4];
@@ -749,7 +750,7 @@ static const struct spi_device_id *__devinit
jedec_probe(struct spi_device *spi)
return m25p_ids[tmp];
}
}
- return NULL;
+ return ERR_PTR(-ENODEV);
}
@@ -794,9 +795,11 @@ static int __devinit m25p_probe(struct spi_device *spi)
const struct spi_device_id *jid;
jid = jedec_probe(spi);
- if (!jid) {
+ if (IS_ERR(jid) PTR_ERR(jid) == -EEXIST) {
dev_info(spi-dev, non-JEDEC variant of %s\n,
id-name);
+ } else if (IS_ERR(jid)) {
+ return PTR_ERR(jid);
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] serial: Add missing call to init UCC UART port timeout
From: Chuck Meade ch...@theptrgroup.com
The UCC UART driver is missing a call to uart_update_timeout().
Without this call, attempting to close the port after outputting large
amounts of data (i.e. using tty and uart buffering) results in long
timeouts before the port will actually be shut down.
For example, cat a large file to a UCC UART port. With the current
driver, the port will stay open for 30 seconds after the last byte
of data is output. But with this patch, the port is closed as
expected, just after the data has been output (tx fifos empty).
Signed-off-by: Chuck Meade ch...@theptrgroup.com
---
drivers/serial/ucc_uart.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/ucc_uart.c b/drivers/serial/ucc_uart.c
index 907b06f..a136030 100644
--- a/drivers/serial/ucc_uart.c
+++ b/drivers/serial/ucc_uart.c
@@ -961,6 +961,9 @@ static void qe_uart_set_termios(struct uart_port *port,
/* Do we really need a spinlock here? */
spin_lock_irqsave(port-lock, flags);
+ /* Update the per-port timeout. */
+ uart_update_timeout(port, termios-c_cflag, baud);
+
out_be16(uccp-upsmr, upsmr);
if (soft_uart) {
out_be16(uccup-supsmr, supsmr);
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [lm-sensors] [PATCH] hwmon: (tmp421) Add nfactor support (2nd attempt)
On Thu, May 20, 2010 at 09:35:56PM +0200, Andre Prendel wrote:
On Thu, May 20, 2010 at 03:07:05PM -0400, Jeff Angielski wrote:
On 05/20/2010 02:50 PM, Andre Prendel wrote:
You made a careless mistake, see below. Please fix this and resend the
patch
again. Then I added my Acked-by and I think Jean will schedule the patch
for
2.6.35 (after another review of course :))
You sir, would be correct... *sigh* I tried using the scripts/Lindent on
it to
be sure there were no coding style issues but that messed up even your
original
code.
/scripts/checkpatch.pl is the key ;)
In any event, here it is again:
Acked-by: Andre Prendel andre.pren...@gmx.de
Hi Jean,
Any News on this patch?
From 9acd29ff48c64e58a7f5cdb888c86e737c56281c Mon Sep 17 00:00:00 2001
From: Jeff Angielski j...@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 j...@theptrgroup.com
---
Documentation/hwmon/tmp421 | 19 +++
drivers/hwmon/tmp421.c | 41 +
2 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/Documentation/hwmon/tmp421 b/Documentation/hwmon/tmp421
index 0cf07f8..668228a 100644
--- a/Documentation/hwmon/tmp421
+++ b/Documentation/hwmon/tmp421
@@ -17,6 +17,7 @@ Supported chips:
Authors:
Andre Prendel andre.pren...@gmx.de
+ Jeff Angielski j...@theptrgroup.com
Description
---
@@ -34,3 +35,21 @@ the temperature values via the following sysfs files:
temp[1-4]_input
temp[2-4]_fault
+
+The chips allow the user to adjust the n-factor value that is used
+when converting the remote channel measurements to temperature. The
+adjustment has a range of -128 to +127 that yields an effective
+n-factor range of 0.706542 to 1.747977. The power on reset value
+for the adjustment is 0 which results in an n-factor of 1.008.
+
+The effective n-factor is calculated according to the following
+equation:
+
+n_factor = (1.008 * 300) / (300 - nfactor_adjust)
+
+The driver exports the n-factor adjustment value via the following
+sysfs files:
+
+temp[2-4]_n_adjust
+
+
diff --git a/drivers/hwmon/tmp421.c b/drivers/hwmon/tmp421.c
index 738c472..dfd62be 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_N_CORRECT[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 n_adjust[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-n_adjust[i - 1] = i2c_smbus_read_byte_data(client,
+ TMP421_N_CORRECT[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_n_adjust(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-n_adjust[index - 1]);
+}
+
+static ssize_t set_n_adjust(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 n_adjust = simple_strtol(buf, NULL, 10);
+
+ mutex_lock(data-update_lock);
+ i2c_smbus_write_byte_data(client, TMP421_N_CORRECT[index - 1],
+ SENSORS_LIMIT(n_adjust, -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
How to find macro defination in source code ?
For example, a macro in serial driver 8250.c , SERIAL_PORT_DFNS ,I can't find where it is implement. Is there any solutions to find a macro defination in code ? Thx ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to find macro defination in source code ?
2010/6/18 wilbur.chan wilbur...@gmail.com: For example, a macro in serial driver 8250.c , SERIAL_PORT_DFNS ,I can't find where it is implement. Is there any solutions to find a macro defination in code ? Thx Yes, use the lxr engine [1]. [1] http://lxr.linux.no ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Linux cannot run with 0 cores
On Fri, Jun 18, 2010 at 10:33:06AM +1000, Anton Blanchard wrote:
If we configure with CONFIG_SMP=n or set NR_CPUS less than the number of
SMT threads we will set the max cores property to 0 in the
ibm,client-architecture-support structure. On new versions of firmware that
understand this property it obliges and terminates our partition.
Use DIV_ROUND_UP so we handle not only the CONFIG_SMP=n case but also the
case where NR_CPUS isn't a multiple of the number of SMT threads.
Thank you, Anton!!!
Acked-by: Paul E. McKenney paul...@linux.vnet.ibm.com
(Will test as soon as the system that hit this becomes available.)
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: linux-2.6/arch/powerpc/kernel/prom_init.c
===
--- linux-2.6.orig/arch/powerpc/kernel/prom_init.c2010-06-17
09:08:20.0 +1000
+++ linux-2.6/arch/powerpc/kernel/prom_init.c 2010-06-17 09:10:02.0
+1000
@@ -872,7 +872,7 @@ static void __init prom_send_capabilitie
ibm_architecture_vec structure
inconsistent: 0x%x !\n,
*cores);
} else {
- *cores = NR_CPUS / prom_count_smt_threads();
+ *cores = DIV_ROUND_UP(NR_CPUS,
prom_count_smt_threads());
prom_printf(Max number of cores passed to firmware:
0x%x\n,
(unsigned long)*cores);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On 06/15/10 23:52, M. Warner Losh wrote: In message: 4c187013.5000...@firmworks.com Mitch Bradley w...@firmworks.com writes: : Mike Rapoport wrote: : Mitch Bradley wrote: : Mike Rapoport wrote: : Mitch Bradley wrote: : : The second topic is the hypothetical use of OFW as a HAL. That will : not happen for several reasons. The opposition to the idea is : widespread and deeply held, and there are good arguments to support : that opposition. Furthermore, the economic conditions necessary for : the creation of such a HAL do not exist in the ARM world, nor indeed : in the Linux world in general. (The necessary condition is the : ability for one company to impose a substantial change by fiat - : essentially a monopoly position.) : : Shall we agree, then, that any further discussion of the HAL issue is : just for fun, and that nobody needs to feel threatened that it would : actually happen? : : I've recently worked with vendor versions of U-Boot for advanced ARM : SoCs. There is already *huge* chunk of HAL code in those versions. And : if there would be possibility to have callbacks into the firmware : these chunks would only grow, IMHO. : : How can there be HAL code in U-Boot unless there is already the : possibility to have callbacks into the firmware? : : Currently it aims to abstract hardware from U-Boot and reuse the same : HW access code across operating systems and bootloaders. If this code : would have callbacks I afraid the things would became worse. : : The only way I can understand what you said is if I assume that by : callback, you mean the following sequence: : : a) U-boot loads and executes the OS, providing to the OS the address : of some HW access routines that it can use : b) The OS calls one of those HW access routines : c) During the execution of that HW access routine, that routine calls : back into the OS, before returning. So a call into the OS is nested : inside a call into U-boot resident code. : : If that is what you are worried about, it is not what we were : discussing. We were discussing - and many people were against - step : (b). : : Are you saying that step (b) - the OS calling into routines provided : by U-Boot - is already the status quo? I don't know about status quo, but it certainly is supported. There's an option to allow for a secondary boot loader, such as FreeBSD's /boot/loader, to call back into uboot to read things from flash/disk/whatever, do network access, etc. Not so much a HAL, but more of an echo of the functionality provided by PC BIOS functions. /boot/loader can be viewed as a mini OS that calls back into uboot to have it do things. Once /boot/loader loads FreeBSD, btw, it and uboot disappear from the scene, so this isn't exactly a HAL situation... Just for reference, there is a patch request on LKML to enable calling openfirmware from the kernel on OLPC: http://lkml.org/lkml/2010/6/18/336 -Frank ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to find macro defination in source code ?
On Sat, 2010-06-19 at 00:47 +0800, wilbur.chan wrote: For example, a macro in serial driver 8250.c , SERIAL_PORT_DFNS ,I can't find where it is implement. It looks to be in 8250.c, so I don't know why you can't find it. Is there any solutions to find a macro defination in code ? # make tags # vi -t SERIAL_PORT_DFNS Or in general: http://ctags.sourceforge.net/ cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
