* Multiple I2C busses on PPC405
From: Tolunay Orkun @ 2005-08-12 22:37 UTC (permalink / raw)
To: linuxppc-embedded
I have a working embedded linux on Cogent CSB472 board (PPC405GP)
currently based on off 2.4.31. We are already using the I2C bus on
PowerPC using hardware I2C driver (IBM IIC I2C Interface) at Fast
(400khz) mode.
We need to add support for yet another (slow) I2C bus with PPC405 being
the master and I'm looking at implementing bit bang interface using GPIO
pins.
What is the best way to get this going? I am looking at modifying the
bit bang driver (PPC_405_I2C_Algorithm?) for the I/O pins I'll use.
Anyone has done something similar. I appreciate all the advice I can get.
Best Regards,
Tolunay
^ permalink raw reply
* Re: What's wrong with the serial port?
From: Shawn Jin @ 2005-08-12 21:38 UTC (permalink / raw)
To: ppcembed
In-Reply-To: <c3d0340b05081214282adeda4c@mail.gmail.com>
> Has the serial port enabled interrupt so far at this stage?
Don't bother. I found the answer. console_init() is before
local_irq_enable(). So no interrupt is enabled before
local_irq_enable().
-Shawn.
^ permalink raw reply
* Re: What's wrong with the serial port?
From: Shawn Jin @ 2005-08-12 21:28 UTC (permalink / raw)
To: ppcembed
In-Reply-To: <20050811231710.GB5796@gate.ebshome.net>
On 8/11/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Thu, Aug 11, 2005 at 04:14:54PM -0700, Eugene Surovegin wrote:
> > > MMU:exit
> > > setup_arch: enter
> > > setup_arch: bootmem
> > > arch: exit
> > > ??????
> >
> > Try disabling early text debugging (all that "MMU:..." stuff).
> >
>=20
> Also, make sure you pass correct "console=3D..." line to the kernel
> (with correct device name and baud rate).
After early text debugging is disabled and the correct "console=3DttyS0,
115200" option is passed to kernel, the problem still exists. Also I'm
sure the divisor set to UART is also correct because they are the same
values when U-Boot sets up the port.
Has the serial port enabled interrupt so far at this stage?
Thanks,
-Shawn.
^ permalink raw reply
* Re: [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Kumar Gala @ 2005-08-12 19:48 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <42FCCEA4.2030409@ru.mvista.com>
On Aug 12, 2005, at 11:30 AM, Vitaly Bordug wrote:
> Kumar Gala wrote:
>
>> Can you do a sizeof instead?
>>
>> #define num_ele sizeof(ppc_sys_specs[])/sizeof(struct ppc_sys_spec)
>>
>> Something like matchted[num_ele] ??
>>
>>
>
> That's what the first I tried actually :)
> gcc is not happy with it:
>
> arch/ppc/syslib/ppc_sys.c: In function `find_chip_by_name_and_id':
> arch/ppc/syslib/ppc_sys.c:54: error: parse error before ']' token
>
> and if I remove [] from the ppc_sys_specs, it outputs:
>
> arch/ppc/syslib/ppc_sys.c: In function `find_chip_by_name_and_id':
> arch/ppc/syslib/ppc_sys.c:54: error: invalid application of
> `sizeof' to
> incomplete type `({anonymous})'
>
> So I cannot use sizeof this case, I think...
Realized the same thing. I'm thinking that your original method is
the best solution to just do this on the stack. In general the
number or processors (array size) is going to be less than 100. So
at most this array is going to end up being 100 bytes on the stack.
I dont think that's a big deal at the point we are calling this.
- kumar
^ permalink raw reply
* [PATCH] ppc32: Cleaned up global namespace of Book-E watchdog variables
From: Kumar Gala @ 2005-08-12 19:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
Renamed global variables used to convey if the watchdog is enabled and
periodicity of the timer and moved the declarations into a header for these
variables
Signed-off-by: Matt McClintock <msm@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 9aa56fc06c3b2cbd116fa42c3fee5f227c3ff27c
tree 331dbfbfda8463f584578ad788411cb0aabcd746
parent d6dee08c314c1952921adc99e8f5ff6c332341ef
author Kumar K. Gala <kumar.gala@freescale.com> Fri, 12 Aug 2005 14:39:28 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Fri, 12 Aug 2005 14:39:28 -0500
arch/ppc/kernel/setup.c | 8 ++------
drivers/char/watchdog/Kconfig | 3 +++
drivers/char/watchdog/booke_wdt.c | 23 ++++++++++++-----------
include/asm-ppc/system.h | 4 ++++
4 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/arch/ppc/kernel/setup.c b/arch/ppc/kernel/setup.c
--- a/arch/ppc/kernel/setup.c
+++ b/arch/ppc/kernel/setup.c
@@ -619,10 +619,8 @@ machine_init(unsigned long r3, unsigned
/* Checks wdt=x and wdt_period=xx command-line option */
int __init early_parse_wdt(char *p)
{
- extern u32 wdt_enable;
-
if (p && strncmp(p, "0", 1) != 0)
- wdt_enable = 1;
+ booke_wdt_enabled = 1;
return 0;
}
@@ -630,10 +628,8 @@ early_param("wdt", early_parse_wdt);
int __init early_parse_wdt_period (char *p)
{
- extern u32 wdt_period;
-
if (p)
- wdt_period = simple_strtoul(p, NULL, 0);
+ booke_wdt_period = simple_strtoul(p, NULL, 0);
return 0;
}
diff --git a/drivers/char/watchdog/Kconfig b/drivers/char/watchdog/Kconfig
--- a/drivers/char/watchdog/Kconfig
+++ b/drivers/char/watchdog/Kconfig
@@ -349,6 +349,9 @@ config 8xx_WDT
config BOOKE_WDT
tristate "PowerPC Book-E Watchdog Timer"
depends on WATCHDOG && (BOOKE || 4xx)
+ ---help---
+ Please see Documentation/watchdog/watchdog-api.txt for
+ more information.
# MIPS Architecture
diff --git a/drivers/char/watchdog/booke_wdt.c b/drivers/char/watchdog/booke_wdt.c
--- a/drivers/char/watchdog/booke_wdt.c
+++ b/drivers/char/watchdog/booke_wdt.c
@@ -23,6 +23,7 @@
#include <asm/reg_booke.h>
#include <asm/uaccess.h>
+#include <asm/system.h>
/* If the kernel parameter wdt_enable=1, the watchdog will be enabled at boot.
* Also, the wdt_period sets the watchdog timer period timeout.
@@ -38,8 +39,8 @@
#define WDT_PERIOD_DEFAULT 4 /* Refer to the PPC40x and PPC4xx manuals */
#endif /* for timing information */
-u32 wdt_enable = 0;
-u32 wdt_period = WDT_PERIOD_DEFAULT;
+u32 booke_wdt_enabled = 0;
+u32 booke_wdt_period = WDT_PERIOD_DEFAULT;
#ifdef CONFIG_FSL_BOOKE
#define WDTP(x) ((((63-x)&0x3)<<30)|(((63-x)&0x3c)<<15))
@@ -55,7 +56,7 @@ static __inline__ void booke_wdt_enable(
u32 val;
val = mfspr(SPRN_TCR);
- val |= (TCR_WIE|TCR_WRC(WRC_CHIP)|WDTP(wdt_period));
+ val |= (TCR_WIE|TCR_WRC(WRC_CHIP)|WDTP(booke_wdt_period));
mtspr(SPRN_TCR, val);
}
@@ -108,12 +109,12 @@ static int booke_wdt_ioctl (struct inode
booke_wdt_ping();
return 0;
case WDIOC_SETTIMEOUT:
- if (get_user(wdt_period, (u32 *) arg))
+ if (get_user(booke_wdt_period, (u32 *) arg))
return -EFAULT;
- mtspr(SPRN_TCR, (mfspr(SPRN_TCR)&~WDTP(0))|WDTP(wdt_period));
+ mtspr(SPRN_TCR, (mfspr(SPRN_TCR)&~WDTP(0))|WDTP(booke_wdt_period));
return 0;
case WDIOC_GETTIMEOUT:
- return put_user(wdt_period, (u32 *) arg);
+ return put_user(booke_wdt_period, (u32 *) arg);
case WDIOC_SETOPTIONS:
if (get_user(tmp, (u32 *) arg))
return -EINVAL;
@@ -134,11 +135,11 @@ static int booke_wdt_ioctl (struct inode
*/
static int booke_wdt_open (struct inode *inode, struct file *file)
{
- if (wdt_enable == 0) {
- wdt_enable = 1;
+ if (booke_wdt_enabled == 0) {
+ booke_wdt_enabled = 1;
booke_wdt_enable();
printk (KERN_INFO "PowerPC Book-E Watchdog Timer Enabled (wdt_period=%d)\n",
- wdt_period);
+ booke_wdt_period);
}
return 0;
@@ -180,9 +181,9 @@ static int __init booke_wdt_init(void)
return ret;
}
- if (wdt_enable == 1) {
+ if (booke_wdt_enabled == 1) {
printk (KERN_INFO "PowerPC Book-E Watchdog Timer Enabled (wdt_period=%d)\n",
- wdt_period);
+ booke_wdt_period);
booke_wdt_enable();
}
diff --git a/include/asm-ppc/system.h b/include/asm-ppc/system.h
--- a/include/asm-ppc/system.h
+++ b/include/asm-ppc/system.h
@@ -87,6 +87,10 @@ extern void cacheable_memzero(void *p, u
extern int do_page_fault(struct pt_regs *, unsigned long, unsigned long);
extern void bad_page_fault(struct pt_regs *, unsigned long, int);
extern void die(const char *, struct pt_regs *, long);
+#ifdef CONFIG_BOOKE_WDT
+extern u32 booke_wdt_enabled;
+extern u32 booke_wdt_period;
+#endif /* CONFIG_BOOKE_WDT */
struct device_node;
extern void note_scsi_host(struct device_node *, void *);
^ permalink raw reply
* [PATCH] cpm_uart: Fix 2nd serial port on MPC8560 ADS
From: Kumar Gala @ 2005-08-12 16:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: tie-fei.zang, linux-kernel, linuxppc-embedded
The 2nd serial port on the MPC8560 ADS was not being configured correctly
and thus could not be used as a console. Updated the defconfig for the
board to configure the proper SCC channel for the 2nd serial port.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 51a75dcea8fe0407f06467de36e258616cda68f9
tree 6adc8ec04a037f64f77e8f17669dec8532557d08
parent 468e916c3b742602a0a10fa12dab015531cd4843
author Kumar K. Gala <kumar.gala@freescale.com> Fri, 12 Aug 2005 11:24:12 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Fri, 12 Aug 2005 11:24:12 -0500
arch/ppc/configs/mpc8560_ads_defconfig | 273 ++++++++++++++++++-------------
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 9 +
2 files changed, 171 insertions(+), 111 deletions(-)
diff --git a/arch/ppc/configs/mpc8560_ads_defconfig b/arch/ppc/configs/mpc8560_ads_defconfig
--- a/arch/ppc/configs/mpc8560_ads_defconfig
+++ b/arch/ppc/configs/mpc8560_ads_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.11-rc1
-# Thu Jan 20 01:24:56 2005
+# Linux kernel version: 2.6.13-rc6
+# Thu Aug 11 18:14:45 2005
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
@@ -11,6 +11,7 @@ CONFIG_HAVE_DEC_LOCK=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
#
# Code maturity level options
@@ -18,6 +19,7 @@ CONFIG_GENERIC_NVRAM=y
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
@@ -29,12 +31,14 @@ CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
-CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
CONFIG_EMBEDDED=y
# CONFIG_KALLSYMS is not set
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
# CONFIG_EPOLL is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
@@ -44,6 +48,7 @@ CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
#
# Loadable module support
@@ -59,12 +64,16 @@ CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
+# CONFIG_E200 is not set
CONFIG_E500=y
CONFIG_BOOKE=y
CONFIG_FSL_BOOKE=y
+# CONFIG_PHYS_64BIT is not set
CONFIG_SPE=y
CONFIG_MATH_EMULATION=y
+# CONFIG_KEXEC is not set
# CONFIG_CPU_FREQ is not set
+# CONFIG_PM is not set
CONFIG_85xx=y
CONFIG_PPC_INDIRECT_PCI_BE=y
@@ -72,9 +81,11 @@ CONFIG_PPC_INDIRECT_PCI_BE=y
# Freescale 85xx options
#
# CONFIG_MPC8540_ADS is not set
+# CONFIG_MPC8548_CDS is not set
# CONFIG_MPC8555_CDS is not set
CONFIG_MPC8560_ADS=y
# CONFIG_SBC8560 is not set
+# CONFIG_STX_GP3 is not set
CONFIG_MPC8560=y
#
@@ -83,11 +94,25 @@ CONFIG_MPC8560=y
CONFIG_CPM2=y
# CONFIG_PC_KEYBOARD is not set
# CONFIG_SMP is not set
-# CONFIG_PREEMPT is not set
# CONFIG_HIGHMEM is not set
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
+# CONFIG_PREEMPT is not set
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+# CONFIG_SPARSEMEM_MANUAL is not set
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_CMDLINE_BOOL is not set
+CONFIG_SECCOMP=y
+CONFIG_ISA_DMA_API=y
#
# Bus options
@@ -103,10 +128,6 @@ CONFIG_PCI_NAMES=y
# CONFIG_PCCARD is not set
#
-# PC-card bridges
-#
-
-#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set
@@ -121,6 +142,69 @@ CONFIG_TASK_SIZE=0x80000000
CONFIG_BOOT_LOAD=0x00800000
#
+# Networking
+#
+CONFIG_NET=y
+
+#
+# Networking options
+#
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_UNIX=y
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_FIB_HASH=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IP_PNP_RARP is not set
+# CONFIG_NET_IPIP is not set
+# CONFIG_NET_IPGRE is not set
+# CONFIG_IP_MROUTE is not set
+# CONFIG_ARPD is not set
+CONFIG_SYN_COOKIES=y
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_TUNNEL is not set
+CONFIG_IP_TCPDIAG=y
+# CONFIG_IP_TCPDIAG_IPV6 is not set
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_BIC=y
+# CONFIG_IPV6 is not set
+# CONFIG_NETFILTER is not set
+
+#
+# SCTP Configuration (EXPERIMENTAL)
+#
+# CONFIG_IP_SCTP is not set
+# CONFIG_ATM is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_DECNET is not set
+# CONFIG_LLC2 is not set
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_NET_DIVERT is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+# CONFIG_NET_SCHED is not set
+# CONFIG_NET_CLS_ROUTE is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+
+#
# Device Drivers
#
@@ -193,6 +277,7 @@ CONFIG_IOSCHED_CFQ=y
#
# Fusion MPT device support
#
+# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
@@ -209,71 +294,8 @@ CONFIG_IOSCHED_CFQ=y
#
#
-# Networking support
-#
-CONFIG_NET=y
-
-#
-# Networking options
-#
-CONFIG_PACKET=y
-# CONFIG_PACKET_MMAP is not set
-# CONFIG_NETLINK_DEV is not set
-CONFIG_UNIX=y
-# CONFIG_NET_KEY is not set
-CONFIG_INET=y
-CONFIG_IP_MULTICAST=y
-# CONFIG_IP_ADVANCED_ROUTER is not set
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-CONFIG_IP_PNP_BOOTP=y
-# CONFIG_IP_PNP_RARP is not set
-# CONFIG_NET_IPIP is not set
-# CONFIG_NET_IPGRE is not set
-# CONFIG_IP_MROUTE is not set
-# CONFIG_ARPD is not set
-CONFIG_SYN_COOKIES=y
-# CONFIG_INET_AH is not set
-# CONFIG_INET_ESP is not set
-# CONFIG_INET_IPCOMP is not set
-# CONFIG_INET_TUNNEL is not set
-CONFIG_IP_TCPDIAG=y
-# CONFIG_IP_TCPDIAG_IPV6 is not set
-# CONFIG_IPV6 is not set
-# CONFIG_NETFILTER is not set
-
+# Network device support
#
-# SCTP Configuration (EXPERIMENTAL)
-#
-# CONFIG_IP_SCTP is not set
-# CONFIG_ATM is not set
-# CONFIG_BRIDGE is not set
-# CONFIG_VLAN_8021Q is not set
-# CONFIG_DECNET is not set
-# CONFIG_LLC2 is not set
-# CONFIG_IPX is not set
-# CONFIG_ATALK is not set
-# CONFIG_X25 is not set
-# CONFIG_LAPB is not set
-# CONFIG_NET_DIVERT is not set
-# CONFIG_ECONET is not set
-# CONFIG_WAN_ROUTER is not set
-
-#
-# QoS and/or fair queueing
-#
-# CONFIG_NET_SCHED is not set
-# CONFIG_NET_CLS_ROUTE is not set
-
-#
-# Network testing
-#
-# CONFIG_NET_PKTGEN is not set
-# CONFIG_NETPOLL is not set
-# CONFIG_NET_POLL_CONTROLLER is not set
-# CONFIG_HAMRADIO is not set
-# CONFIG_IRDA is not set
-# CONFIG_BT is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
@@ -311,8 +333,10 @@ CONFIG_MII=y
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
+# CONFIG_SKGE is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
+# CONFIG_BNX2 is not set
CONFIG_GIANFAR=y
CONFIG_GFAR_NAPI=y
@@ -342,6 +366,8 @@ CONFIG_GFAR_NAPI=y
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
#
# ISDN subsystem
@@ -368,14 +394,6 @@ CONFIG_INPUT=y
# CONFIG_INPUT_EVBUG is not set
#
-# Input I/O drivers
-#
-# CONFIG_GAMEPORT is not set
-CONFIG_SOUND_GAMEPORT=y
-# CONFIG_SERIO is not set
-# CONFIG_SERIO_I8042 is not set
-
-#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
@@ -385,6 +403,12 @@ CONFIG_SOUND_GAMEPORT=y
# CONFIG_INPUT_MISC is not set
#
+# Hardware I/O ports
+#
+# CONFIG_SERIO is not set
+# CONFIG_GAMEPORT is not set
+
+#
# Character devices
#
# CONFIG_VT is not set
@@ -403,11 +427,12 @@ CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_CPM=y
CONFIG_SERIAL_CPM_CONSOLE=y
CONFIG_SERIAL_CPM_SCC1=y
-# CONFIG_SERIAL_CPM_SCC2 is not set
+CONFIG_SERIAL_CPM_SCC2=y
# CONFIG_SERIAL_CPM_SCC3 is not set
-CONFIG_SERIAL_CPM_SCC4=y
+# CONFIG_SERIAL_CPM_SCC4 is not set
# CONFIG_SERIAL_CPM_SMC1 is not set
# CONFIG_SERIAL_CPM_SMC2 is not set
+# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
@@ -436,6 +461,11 @@ CONFIG_GEN_RTC=y
# CONFIG_RAW_DRIVER is not set
#
+# TPM devices
+#
+# CONFIG_TCG_TPM is not set
+
+#
# I2C support
#
CONFIG_I2C=y
@@ -458,11 +488,11 @@ CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
+# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_ISA is not set
CONFIG_I2C_MPC=y
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
-# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
@@ -473,19 +503,46 @@ CONFIG_I2C_MPC=y
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set
+# CONFIG_I2C_SENSOR is not set
#
-# Hardware Sensors Chip support
+# Miscellaneous I2C Chip support
#
-# CONFIG_I2C_SENSOR is not set
+# CONFIG_SENSORS_DS1337 is not set
+# CONFIG_SENSORS_DS1374 is not set
+# CONFIG_SENSORS_EEPROM is not set
+# CONFIG_SENSORS_PCF8574 is not set
+# CONFIG_SENSORS_PCA9539 is not set
+# CONFIG_SENSORS_PCF8591 is not set
+# CONFIG_SENSORS_RTC8564 is not set
+# CONFIG_SENSORS_M41T00 is not set
+# CONFIG_SENSORS_MAX6875 is not set
+# CONFIG_I2C_DEBUG_CORE is not set
+# CONFIG_I2C_DEBUG_ALGO is not set
+# CONFIG_I2C_DEBUG_BUS is not set
+# CONFIG_I2C_DEBUG_CHIP is not set
+
+#
+# Dallas's 1-wire bus
+#
+# CONFIG_W1 is not set
+
+#
+# Hardware Monitoring support
+#
+CONFIG_HWMON=y
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
+# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ASB100 is not set
+# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
+# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
+# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
@@ -496,31 +553,18 @@ CONFIG_I2C_MPC=y
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
+# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
-# CONFIG_SENSORS_SMSC47B397 is not set
+# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
+# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
-
-#
-# Other I2C Chip support
-#
-# CONFIG_SENSORS_EEPROM is not set
-# CONFIG_SENSORS_PCF8574 is not set
-# CONFIG_SENSORS_PCF8591 is not set
-# CONFIG_SENSORS_RTC8564 is not set
-# CONFIG_I2C_DEBUG_CORE is not set
-# CONFIG_I2C_DEBUG_ALGO is not set
-# CONFIG_I2C_DEBUG_BUS is not set
-# CONFIG_I2C_DEBUG_CHIP is not set
-
-#
-# Dallas's 1-wire bus
-#
-# CONFIG_W1 is not set
+# CONFIG_SENSORS_W83627EHF is not set
+# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Misc devices
@@ -540,7 +584,6 @@ CONFIG_I2C_MPC=y
# Graphics support
#
# CONFIG_FB is not set
-# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Sound
@@ -550,13 +593,9 @@ CONFIG_I2C_MPC=y
#
# USB support
#
-# CONFIG_USB is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
-
-#
-# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
-#
+# CONFIG_USB is not set
#
# USB Gadget Support
@@ -574,10 +613,15 @@ CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_INFINIBAND is not set
#
+# SN Devices
+#
+
+#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
+# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
@@ -587,9 +631,15 @@ CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
+# CONFIG_FS_POSIX_ACL is not set
+
+#
+# XFS support
+#
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
+CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
@@ -614,7 +664,6 @@ CONFIG_DNOTIFY=y
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
-# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
@@ -648,7 +697,7 @@ CONFIG_NFS_FS=y
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
-# CONFIG_EXPORTFS is not set
+CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
@@ -700,7 +749,9 @@ CONFIG_CRC32=y
#
# Kernel hacking
#
+# CONFIG_PRINTK_TIME is not set
# CONFIG_DEBUG_KERNEL is not set
+CONFIG_LOG_BUF_SHIFT=14
# CONFIG_KGDB_CONSOLE is not set
#
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -142,12 +142,21 @@ void scc2_lineif(struct uart_cpm_port *p
* be supported in a sane fashion.
*/
#ifndef CONFIG_STX_GP3
+#ifdef CONFIG_MPC8560_ADS
+ volatile iop_cpm2_t *io = &cpm2_immr->im_ioport;
+ io->iop_ppard |= 0x00000018;
+ io->iop_psord &= ~0x00000008; /* Rx */
+ io->iop_psord &= ~0x00000010; /* Tx */
+ io->iop_pdird &= ~0x00000008; /* Rx */
+ io->iop_pdird |= 0x00000010; /* Tx */
+#else
volatile iop_cpm2_t *io = &cpm2_immr->im_ioport;
io->iop_pparb |= 0x008b0000;
io->iop_pdirb |= 0x00880000;
io->iop_psorb |= 0x00880000;
io->iop_pdirb &= ~0x00030000;
io->iop_psorb &= ~0x00030000;
+#endif
#endif
cpm2_immr->im_cpmux.cmx_scr &= 0xff00ffff;
cpm2_immr->im_cpmux.cmx_scr |= 0x00090000;
^ permalink raw reply
* Re: [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Vitaly Bordug @ 2005-08-12 16:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list
In-Reply-To: <12EA7634-C020-4B0A-BCF0-80B11E4E55D2@freescale.com>
Kumar Gala wrote:
> Can you do a sizeof instead?
>
> #define num_ele sizeof(ppc_sys_specs[])/sizeof(struct ppc_sys_spec)
>
> Something like matchted[num_ele] ??
>
That's what the first I tried actually :)
gcc is not happy with it:
arch/ppc/syslib/ppc_sys.c: In function `find_chip_by_name_and_id':
arch/ppc/syslib/ppc_sys.c:54: error: parse error before ']' token
and if I remove [] from the ppc_sys_specs, it outputs:
arch/ppc/syslib/ppc_sys.c: In function `find_chip_by_name_and_id':
arch/ppc/syslib/ppc_sys.c:54: error: invalid application of `sizeof' to
incomplete type `({anonymous})'
So I cannot use sizeof this case, I think...
> - kumar
>
> On Aug 12, 2005, at 10:37 AM, Vitaly Bordug wrote:
>
>> Marcelo Tosatti wrote:
>>
>>> On Thu, Aug 11, 2005 at 07:25:20PM +0400, Vitaly Bordug wrote:
>>>
>>>
>>>> Marcelo Tosatti wrote:
>>>>
>>>>
>>>>> On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:
>>>>>
>>>>>
>>>>>
>>>>>> +static int __init find_chip_by_name_and_id(char *name, u32 id)
>>>>>> +{
>>>>>> + int ret = -1;
>>>>>> + unsigned int i = 0;
>>>>>> + unsigned int j = 0;
>>>>>> + unsigned int dups = 0;
>>>>>> +
>>>>>> + unsigned int matched[count_sys_specs()];
>>>>>>
>>>>>> Is is legit in the kernel to use dynamically sized array?
>>>>>>
>>>>>
>>>>>
>>>>> kmalloc() is certainly safer - why not use it?
>>>>>
>>>>
>>>> Practically , version with kmalloc works, but setup_arch and thus
>>>> this
>>>> function is called before mem_init, so I just wonder if kmalloc can
>>>> handle this case. On the other hand, I don't like to deal with
>>>> alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp
>>>> does) just for the temporary buffer.
>>>>
>>>> But it's the only _right_ way (or I 've missed something) - sure I'll
>>>> follow it.
>>>>
>>>
>>>
>>> I dont see any problem with dynamic array usage on the kernel (maybe
>>> someone
>>> else has good argumentation against it).
>>>
>>> Just that you have a 4kb stack. Does count_sys_specs() have an
>>> appropriate
>>> maximum?
>>>
>>>
>>>
>> Yes it does, but there is no define for it. The ppc_sys_specs array
>> should always end at the "default match" - element with name field set
>> to "" and value=0 (without it every existing ppc_sys identify will fall
>> into infinite loop). This array is defined in syslib/<board>_sys.c end
>> is finite of course. Its size depends on amount of supported boards.
>>
>> So, if the dynamic array is ok with conditions, it will be great.
>> But now I'm inclined to implement the same using kmalloc/alloc_bootmem
>> to prevent flame when it will proceed. BTW, will free_bootmem properly
>> release the memory allocated by alloc_bootmem()? I haven't encountered
>> examples of this so far...
>>
>>
>> --
>> Sincerely,
>> Vitaly
>>
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Kumar Gala @ 2005-08-12 16:18 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <42FCC234.8070008@ru.mvista.com>
Can you do a sizeof instead?
#define num_ele sizeof(ppc_sys_specs[])/sizeof(struct ppc_sys_spec)
Something like matchted[num_ele] ??
- kumar
On Aug 12, 2005, at 10:37 AM, Vitaly Bordug wrote:
> Marcelo Tosatti wrote:
>
>> On Thu, Aug 11, 2005 at 07:25:20PM +0400, Vitaly Bordug wrote:
>>
>>
>>> Marcelo Tosatti wrote:
>>>
>>>
>>>> On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:
>>>>
>>>>
>>>>
>>>>> +static int __init find_chip_by_name_and_id(char *name, u32 id)
>>>>> +{
>>>>> + int ret = -1;
>>>>> + unsigned int i = 0;
>>>>> + unsigned int j = 0;
>>>>> + unsigned int dups = 0;
>>>>> +
>>>>> + unsigned int matched[count_sys_specs()];
>>>>>
>>>>> Is is legit in the kernel to use dynamically sized array?
>>>>>
>>>>
>>>>
>>>> kmalloc() is certainly safer - why not use it?
>>>>
>>>
>>> Practically , version with kmalloc works, but setup_arch and
>>> thus this
>>> function is called before mem_init, so I just wonder if kmalloc can
>>> handle this case. On the other hand, I don't like to deal with
>>> alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp
>>> does) just for the temporary buffer.
>>>
>>> But it's the only _right_ way (or I 've missed something) - sure
>>> I'll
>>> follow it.
>>>
>>
>>
>> I dont see any problem with dynamic array usage on the kernel
>> (maybe someone
>> else has good argumentation against it).
>>
>> Just that you have a 4kb stack. Does count_sys_specs() have an
>> appropriate
>> maximum?
>>
>>
>>
> Yes it does, but there is no define for it. The ppc_sys_specs array
> should always end at the "default match" - element with name field set
> to "" and value=0 (without it every existing ppc_sys identify will
> fall
> into infinite loop). This array is defined in syslib/<board>_sys.c end
> is finite of course. Its size depends on amount of supported boards.
>
> So, if the dynamic array is ok with conditions, it will be great.
> But now I'm inclined to implement the same using kmalloc/alloc_bootmem
> to prevent flame when it will proceed. BTW, will free_bootmem properly
> release the memory allocated by alloc_bootmem()? I haven't encountered
> examples of this so far...
>
>
> --
> Sincerely,
> Vitaly
>
^ permalink raw reply
* Re: [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Vitaly Bordug @ 2005-08-12 15:37 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded list
In-Reply-To: <20050811224523.GA5395@dmt.cnet>
Marcelo Tosatti wrote:
> On Thu, Aug 11, 2005 at 07:25:20PM +0400, Vitaly Bordug wrote:
>
>>Marcelo Tosatti wrote:
>>
>>>On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:
>>>
>>>
>>>>+static int __init find_chip_by_name_and_id(char *name, u32 id)
>>>>+{
>>>>+ int ret = -1;
>>>>+ unsigned int i = 0;
>>>>+ unsigned int j = 0;
>>>>+ unsigned int dups = 0;
>>>>+
>>>>+ unsigned int matched[count_sys_specs()];
>>>>
>>>>Is is legit in the kernel to use dynamically sized array?
>>>
>>>
>>>kmalloc() is certainly safer - why not use it?
>>
>>Practically , version with kmalloc works, but setup_arch and thus this
>>function is called before mem_init, so I just wonder if kmalloc can
>>handle this case. On the other hand, I don't like to deal with
>>alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp
>>does) just for the temporary buffer.
>>
>>But it's the only _right_ way (or I 've missed something) - sure I'll
>>follow it.
>
>
> I dont see any problem with dynamic array usage on the kernel (maybe someone
> else has good argumentation against it).
>
> Just that you have a 4kb stack. Does count_sys_specs() have an appropriate
> maximum?
>
>
Yes it does, but there is no define for it. The ppc_sys_specs array
should always end at the "default match" - element with name field set
to "" and value=0 (without it every existing ppc_sys identify will fall
into infinite loop). This array is defined in syslib/<board>_sys.c end
is finite of course. Its size depends on amount of supported boards.
So, if the dynamic array is ok with conditions, it will be great.
But now I'm inclined to implement the same using kmalloc/alloc_bootmem
to prevent flame when it will proceed. BTW, will free_bootmem properly
release the memory allocated by alloc_bootmem()? I haven't encountered
examples of this so far...
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: GDB backtrace and signal trampolines
From: Hollis Blanchard @ 2005-08-12 13:58 UTC (permalink / raw)
To: Anton Blanchard; +Cc: PPC64-dev List, Linux PPC Dev
In-Reply-To: <20050812050609.GA7355@krispykreme>
On Aug 12, 2005, at 12:06 AM, Anton Blanchard wrote:
>
>> Would it make sense to limit the test to within a few hundred bytes of
>> the stack pointer? Or some better way to detect that the PC is in a
>> signal trampoline?
>
> With recent kernels we should be able to use the dwarf2 unwind
> information in the vdso I think.
I guess compatibility with older kernels will still need to be
maintained, though.
I see this note in arch/ppc64/mm/fault.c:
/*
* N.B. The POWER/Open ABI allows programs to access up to
* 288 bytes below the stack pointer.
* The kernel signal delivery code writes up to about 1.5kB
* below the stack pointer (r1) before decrementing it.
* The exec code can write slightly over 640kB to the stack
* before setting the user r1. Thus we allow the stack to
* expand to 1MB without further checks.
*/
So would 2KB be a reasonable limit to the signal frame check, as I
described before?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* BankOfTheWest Inc: Please Confirm Your Banking Details [Fri, 12 Aug 2005 12:38:14 -0100]
From: BankOfTheWest @ 2005-08-12 13:16 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 3864 bytes --]
^ permalink raw reply
* BankOfTheWest Inc: Please Confirm Your Banking Details [Fri, 12 Aug 2005 12:38:14 -0100]
From: BankOfTheWest @ 2005-08-12 13:16 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 3864 bytes --]
^ permalink raw reply
* Re: [PATCH] Use todc on Mot PReP platforms
From: Christian @ 2005-08-12 10:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20050811194307.GW3187@smtp.west.cox.net>
> On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:
>>If anybody has objections to this as the default, let me know. It
>>still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't
>>affect the IBM PReP paths. My goal with this is to be able to run
>>a stock 2.6 defconfig PReP build on qemu.
i applied the patch to the latest 2.6-git tree and my PReP[1] boots just
fine!
thanks for maintaining this exotic platform,
Christian.
[1] http://www.nerdbynature.de/bits/hal/2.6.13-rc6
--
BOFH excuse #367:
Webmasters kidnapped by evil cult.
^ permalink raw reply
* Re: 8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
From: cajus.hahn @ 2005-08-12 8:21 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050812080113.AA881352B36@atlas.denx.de>
My description seems to be a little misleading.
WITHOUT the force_reinit() my SPI driver reports transmission errors if the
I2C bus has longer disturbances.
WITH the force_reinit() my SPI driver works fine.
This sounds like the I2C allocates a new buffer for every timed-out
transmision. If all I2C buffers are full, the SPI buffers get overwritten
!?
I did not really trace back the problem, this is only my suspicion.
Because the force_reinit() resets all the buffer pointer to their init
values the problem with the SPI does not occur.
Cajus
Message from Wolfgang Denk <wd@denx.de>@denx.de received on 12.08.2005
10:01
12.08.2005 Wolfgang Denk <wd@denx.de>@denx.de
10:01
Sent by wd@denx.de
To: Cajus Hahn/DEAPR/ABB@ABB_DE01
cc: linuxppc-embedded@ozlabs.org
Subject: Re: 8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
In message
<OF29EF0D8D.F0A40A5C-ONC125705B.0028FA70-C125705B.002AF212@de.abb.com> you
wrote:
>
> Then I set the SCL line to ground to simulate a longer bus disturbance.
> After some timeouts my SPI bus, yes the SPI bus, reportet transmission
> errors. Both bus-interfaces use the CPM. It looks like the SPI buffer
gets
> garbaged by the I2C interface.
This is "normal". We see similar problems even with perfectly legal
operations on the CPM. The SPI is running at lowest priority on the
CPM, and anything that causes higher CPM load will starve SPI.
Obviously your operation causes the CPM to go into some strange
state.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There are certain things men must do to remain men.
-- Kirk, "The Ultimate Computer", stardate 4929.4
^ permalink raw reply
* Re: 8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
From: Wolfgang Denk @ 2005-08-12 8:01 UTC (permalink / raw)
To: cajus.hahn; +Cc: linuxppc-embedded
In-Reply-To: <OF29EF0D8D.F0A40A5C-ONC125705B.0028FA70-C125705B.002AF212@de.abb.com>
In message <OF29EF0D8D.F0A40A5C-ONC125705B.0028FA70-C125705B.002AF212@de.abb.com> you wrote:
>
> Then I set the SCL line to ground to simulate a longer bus disturbance.
> After some timeouts my SPI bus, yes the SPI bus, reportet transmission
> errors. Both bus-interfaces use the CPM. It looks like the SPI buffer gets
> garbaged by the I2C interface.
This is "normal". We see similar problems even with perfectly legal
operations on the CPM. The SPI is running at lowest priority on the
CPM, and anything that causes higher CPM load will starve SPI.
Obviously your operation causes the CPM to go into some strange
state.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There are certain things men must do to remain men.
-- Kirk, "The Ultimate Computer", stardate 4929.4
^ permalink raw reply
* Re: strange things about swap on NFS
From: Wolfgang Denk @ 2005-08-12 7:58 UTC (permalink / raw)
To: FCG WANG Baohua; +Cc: linuxppc-embedded
In-Reply-To: <A9DE2BAF233E444FA9C5E77A5825A01E86505F@ydmail.sbell.com.cn>
In message <A9DE2BAF233E444FA9C5E77A5825A01E86505F@ydmail.sbell.com.cn> you wrote:
>
> But I found that the "dd if=/dev/zero of=swapfile bs=1M
> count=62" is not easy to executed:
This command alone should just work fine.
> The system is often no response after execute this command. On several
> time, it add swap successfully.
> But when I start to compile package. The system then no response !!
>From your subject and this description I understand that you then try
to use this file as swapfile over NFS, and this causes problems.
There is a known problem with swap over NFS, at least for 2.4 kernels.
> How to slove the problem? Is the reason of my hard disk? I think not,
RTFM. A solution is described in detail at
http://www.denx.de/twiki/bin/view/DULG/SwappingOverNFS
Note that this is terribly slow, though - but sometimes it's better
to have a slow and working system than one which is fast and out of
memory.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3
^ permalink raw reply
* 8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
From: cajus.hahn @ 2005-08-12 7:49 UTC (permalink / raw)
To: linuxppc-embedded
Hello Tjernlund, Hello Debora
>Try changing all
> i2c->i2c_i2com |= 0x80; /* Begin transmission */
>to
> i2c->i2c_i2com |= 0x80 | 0x01; /* Begin transmission */
>
>That should remove the need to do force_reinit(cpm) I hope.
This is NOT working in every case!
It will work, on short bus-disturbances on the SCL line.
I suggest adding the "| 0x01" even this will not help on every transmission
problem.
If you have longer disturbances on SCL or SDA, something in the CPM will
prevent the I2C bus to continue working after the disturbances are gone.
Perhaps there is a problem with the buffer allocation.
I changed the i2c-algo-8xx.c to work with your patch and without the
force_reinit() code.
Then I set the SCL line to ground to simulate a longer bus disturbance.
After some timeouts my SPI bus, yes the SPI bus, reportet transmission
errors. Both bus-interfaces use the CPM. It looks like the SPI buffer gets
garbaged by the I2C interface.
With the force_reinit() this problem did not occur.
Cajus
^ permalink raw reply
* strange things about swap on NFS
From: FCG WANG Baohua @ 2005-08-12 6:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
Dear all:
I use ELDK 3.1.1, kernel 2.4.25 on my HD860 board, using NFS. I add a "ext2.img" as mentioned in the ELDK doc.
But I found that the "dd if=/dev/zero of=swapfile bs=1M count=62" is not easy to executed:
The system is often no response after execute this command. On several time, it add swap successfully.
But when I start to compile package. The system then no response !!
How to slove the problem? Is the reason of my hard disk? I think not,
thanks!
[-- Attachment #2: Type: text/html, Size: 1509 bytes --]
^ permalink raw reply
* Re: [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Marcelo Tosatti @ 2005-08-11 22:45 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <42FB6DE0.4070506@ru.mvista.com>
On Thu, Aug 11, 2005 at 07:25:20PM +0400, Vitaly Bordug wrote:
> Marcelo Tosatti wrote:
> >On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:
> >
> >>+static int __init find_chip_by_name_and_id(char *name, u32 id)
> >>+{
> >>+ int ret = -1;
> >>+ unsigned int i = 0;
> >>+ unsigned int j = 0;
> >>+ unsigned int dups = 0;
> >>+
> >>+ unsigned int matched[count_sys_specs()];
> >>
> >>Is is legit in the kernel to use dynamically sized array?
> >
> >
> >kmalloc() is certainly safer - why not use it?
> Practically , version with kmalloc works, but setup_arch and thus this
> function is called before mem_init, so I just wonder if kmalloc can
> handle this case. On the other hand, I don't like to deal with
> alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp
> does) just for the temporary buffer.
>
> But it's the only _right_ way (or I 've missed something) - sure I'll
> follow it.
I dont see any problem with dynamic array usage on the kernel (maybe someone
else has good argumentation against it).
Just that you have a 4kb stack. Does count_sys_specs() have an appropriate
maximum?
^ permalink raw reply
* Re: 8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
From: Debora Liu @ 2005-08-12 5:11 UTC (permalink / raw)
To: Tjernlund; +Cc: Linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]
Hello, Tjernlund
In message <2005-08-12 01:50:45 tjernlund@tjernlund.se> you wrote:
>Try changing all
> i2c->i2c_i2com |= 0x80; /* Begin transmission */
>to
> i2c->i2c_i2com |= 0x80 | 0x01; /* Begin transmission */
>
>That should remove the need to do force_reinit(cpm) I hope.
>See http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019600.html for a litte more info.
>
>Also, I think you should remove the busy wait code. Its not needed IMHO.
update i2c_algo_8xx.c as same
= = = = = = = = = = = = = = = = = = = =
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Debora Liu
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡deboralh@fel.com.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-08-12
^ permalink raw reply
* Re: GDB backtrace and signal trampolines
From: Anton Blanchard @ 2005-08-12 5:06 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: PPC64-dev List, Linux PPC Dev
In-Reply-To: <a22149f6d9cc6f65ae2f8f339d982dd2@us.ibm.com>
Hi,
> Would it make sense to limit the test to within a few hundred bytes of
> the stack pointer? Or some better way to detect that the PC is in a
> signal trampoline?
With recent kernels we should be able to use the dwarf2 unwind
information in the vdso I think.
Anton
^ permalink raw reply
* Re: What's wrong with the serial port?
From: Debora Liu @ 2005-08-12 5:01 UTC (permalink / raw)
To: Shawn Jin; +Cc: Linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
Hello, Shawn Jin
In message <2005-08-12 06:41:21 shawnxjin@gmail.com> you wrote:
>Hi,
>
>I'm porting linux 2.6.11.4 to a custom SoC with ppc440 core. The UART
>is 16550 compatible. U-Boot is already running fine.
Please check your uboot bootargs console rate setting.
= = = = = = = = = = = = = = = = = = = =
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Debora Liu
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡deboralh@fel.com.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-08-12
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Tom Rini @ 2005-08-12 4:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Becky Bruce, linuxppc64-dev
In-Reply-To: <17148.7234.193140.997481@cargo.ozlabs.ibm.com>
On Fri, Aug 12, 2005 at 01:49:22PM +1000, Paul Mackerras wrote:
> Tom Rini writes:
>
> > I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
> > OpenFirmware-containing ppc64 box (like Maple) ? How about just 9xx/
>
> Ummm, no, not exactly. The distinctive thing about pSeries is the
> hypervisor interfaces. And in fact most pSeries boxes aren't
> 970-based, rather POWER4/4+/5. If you want to generalize, we could
> call the directory "papr" (for Power Architecture Platform
> Requirements, the name of the document that describes the pSeries
> platforms) rather than pSeries, but I suspect that would just confuse
> people. :)
Ok. How about 9xx/ instead of classic64 ?
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Paul Mackerras @ 2005-08-12 3:49 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, Becky Bruce, linuxppc64-dev
In-Reply-To: <20050811195927.GX3187@smtp.west.cox.net>
Tom Rini writes:
> I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
> OpenFirmware-containing ppc64 box (like Maple) ? How about just 9xx/
Ummm, no, not exactly. The distinctive thing about pSeries is the
hypervisor interfaces. And in fact most pSeries boxes aren't
970-based, rather POWER4/4+/5. If you want to generalize, we could
call the directory "papr" (for Power Architecture Platform
Requirements, the name of the document that describes the pSeries
platforms) rather than pSeries, but I suspect that would just confuse
people. :)
Paul.
^ permalink raw reply
* Redwood-6 and 2.6
From: Otto Solares @ 2005-08-12 3:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
Redwood-6 support in 2.6 is broken. I subscribed to this
list just to know if somebody is working on it? 2.4.30
works ok.
If nobody is working on it please just tell me what is wrong
and I would try to figure out:
---
CC arch/ppc/syslib/ppc4xx_dma.o
arch/ppc/syslib/ppc4xx_dma.c: In function `ppc4xx_enable_burst': arch/ppc/syslib/ppc4xx_dma.c:638: error: `DMA_CTC_BTEN' undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_dma.c:638: error: (Each undeclared identifier is reported only once arch/ppc/syslib/ppc4xx_dma.c:638: error: for each function it appears in.)
arch/ppc/syslib/ppc4xx_dma.c: In function `ppc4xx_disable_burst': arch/ppc/syslib/ppc4xx_dma.c:657: error: `DMA_CTC_BTEN' undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_dma.c: In function `ppc4xx_set_burst_size': arch/ppc/syslib/ppc4xx_dma.c:682: error: `DMA_CTC_BSIZ_MSK' undeclared (first use in this function)
make[1]: *** [arch/ppc/syslib/ppc4xx_dma.o] Error 1
make: *** [arch/ppc/syslib] Error 2
---
In 2.4 'DMA_CTC_BTEN' does not exists.
Thanks.
-otto
^ 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