* Re: Posix message queue
From: Murray Jensen @ 2005-03-17 21:53 UTC (permalink / raw)
To: Vlad L, Embedded Linux
In-Reply-To: <20050317082021.79119.qmail@web90204.mail.scd.yahoo.com>
At 07:20 PM 17/03/2005, Vlad L wrote:
>I have MPC5200 based board and looking for Posix
>Message Queue for kernel 2.4... Can you, please,
>direct me to resorce where I can load such patch or
>library.
I typed "linux posix message queues" into google and came up with these:
<http://lists.debian.org/debian-mentors/2004/07/msg00420.html>http://lists.debian.org/debian-mentors/2004/07/msg00420.html
http://www.uwsg.iu.edu/hypermail/linux/kernel/0211.3/1184.html
<http://www-users.mat.uni.torun.pl/~golbi/priv/index-en.html>http://www-users.mat.uni.torun.pl/~golbi/priv/index-en.html
http://www.geocities.com/wronski12/posix_ipc/index.html
<http://www.xenotime.net/linux/linux-posix.html>http://www.xenotime.net/linux/linux-posix.html
http://www.garret.ru/~knizhnik/sal.html
<http://lwn.net/Articles/52273/>http://lwn.net/Articles/52273/
http://lwn.net/Articles/52274/
The kernel code is for 2.6, but there are some user level implementations
that might be good enough. Cheers!
Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au
To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.
^ permalink raw reply
* Ext2fs on a MPC850 running BusyBox Linux and a 2.4.27 kernel
From: Wouter Thielen @ 2005-03-17 10:53 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am trying to get a 128K read/write partition on the 4M NAND flash chip
to store configuration data for the system in ext2 format. mke2fs and
mounting works fine. The problem starts when I write to the partition: I
can write to it fine, but without proper umounting the data written
won't be saved. I tried the following things:
- mounting with -o sync
- checking the fs/ext2/* code and trying to get fs update operations to
call the functions that umount calls (ext2_put_super and
ext2_sync_super), but that only results in kernel oopses and no saved
data either.
I have been suggested to use a flash filesystem like jffs2, but the
problem is that I have only 1 block to work with. Flash filesystems
require more, jffs2 requires 6 blocks for 1 usable block and that would
be an inacceptable overhead of 83%. So I'd like to try to use ext2 (or
minixfs which is slimmer than ext2, but still has the same problem) for
that small read/write partition. Anyone got any ideas/suggestions on how
to make ext2 sync to disk after write operations in the buffer?
Wouter Thielen
MuLogic B.V. Netherlands
^ permalink raw reply
* RE: RTC with TQM823L
From: Murray Jensen @ 2005-03-17 21:36 UTC (permalink / raw)
To: Jean Nicollerat MD; +Cc: Linuxppc-Embedded
In-Reply-To: <HMECJAKDCPLOGPDHNAHEAEKHCAAA.jean.nicollerat@microdev.ch>
At 08:27 PM 17/03/2005, Jean Nicollerat MD wrote:
>I have to read message that comme on the CAN bus every 2ms. Then I have to
>show values on the LCD and transfers some message on the RS232.
Sounds like a simple device driver would handle this.
>I need a timer to the check the reception of the messages.
Could this be done by setting a timeout which you keep rescheduling?
Note that the standard clock tick on linux has 10ms resolution - i.e. 100Hz.
You might want to increase this to 1000Hz (i.e. 1ms resolution). I have read
of people doing this in this list.
>I seem it is difficult with linux.
No, its not difficult at all - its very easy. There is a learning curve
though, just
like anything. Cheers!
Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au
To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.
^ permalink raw reply
* Re: RTC with TQM823L
From: Wolfgang Denk @ 2005-03-17 10:39 UTC (permalink / raw)
To: Jean Nicollerat MD; +Cc: Linuxppc-Embedded
In-Reply-To: <HMECJAKDCPLOGPDHNAHEAEKHCAAA.jean.nicollerat@microdev.ch>
In message <HMECJAKDCPLOGPDHNAHEAEKHCAAA.jean.nicollerat@microdev.ch> you wrote:
>
> I'm used to program on processor without OS. I want try linux to use linux
That was what I expected from your posting.
> I have to read message that comme on the CAN bus every 2ms. Then I have to
> show values on the LCD and transfers some message on the RS232.
Ok.
> I need a timer to the check the reception of the messages.
No. This is fundamentally wrong. You do NOT need a timer to check if
a device driver has data available.
This is exactly what I meant when sayin you will have to get used to
working in a Unix environment., Under Unix, you will not use a time
triggered control loops which polls all your drivers, but you will
use select() or poll() to wait for events from your drivers. It's the
incoming data which triggers your control loop, not a timer.
> I seem it is difficult with linux. I will try with the RTAI.
DO NOT DO IT. This will only make things worse. You are on the wrong
track. Don't try to stick with a software design which does not fit
any more. Change your design to take advantage of the services
provided by a Unix operating system.
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
Never call a man a fool. Borrow from him.
^ permalink raw reply
* Re: FW: LED driver
From: Hans Schillstrom @ 2005-03-17 9:46 UTC (permalink / raw)
To: srinivas.surabhi; +Cc: linuxppc-embedded
In-Reply-To: <EF9B29C78F41FA488927FCBC7750AF0E011DA945@hyd-mdp-msg.wipro.com>
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]
Hi,
I have made a driver for our mpc8270 board
It is based upon Denx led_driver and made for 2.6 kernel
(See atached file)
To control the leds you have to perfom some ioctl's
first create your devices
mknod led0 c 151 0 ...
Example howto use it:
void led_off( int file )
{
if (ioctl(file,STATUSLED_SET,0) < 0)
perror("led off: ");
}
void led_blink( int file )
{
if (ioctl(file,STATUSLED_SET,1) < 0)
perror("led blink: ");
}
void led_on( int file )
{
if (ioctl(file,STATUSLED_SET,2) < 0)
perror("led on: ");
}
void led_per( int file, int period )
{
if (ioctl(file,STATUSLED_PERIOD,period) < 0)
perror("led on: ");
}
...
int led0 = open("/dev/led0",O_RDWR)
...
led_blink(led0); /* turn on green LED */
..
/Hans
On Thu, 2005-03-17 at 06:15, srinivas.surabhi@wipro.com wrote:
>
> -----Original Message-----
> From: Srinivas Surabhi (WT01 - TELECOM SOLUTIONS)
> Sent: Thursday, March 17, 2005 7:53 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: LED driver
>
> Hi,
>
> I am working on the MPC8270 board having connected GPIO 3 lines
> connected to 3 LEDs. So can any one help me in finding out the best
> solution of controlling the LEDs from MVlinux (kernel and user space) or
> any pointers who has done it before.
>
> Thanks & Rgds
> SS
>
>
>
>
> Confidentiality Notice
>
> The information contained in this electronic message and any attachments to this message are intended
> for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
> you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
> and destroy all copies of this message and any attachments.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: rcb8270_led.c --]
[-- Type: text/x-c, Size: 17175 bytes --]
/******************************************************************************
*
* (C) Copyright 2004
* LGP Allgon AB
* Hans Schillstrom, hans.schillstrom@lgpallgon.com
*
* Based upon DENX status_led.c
*
* This Device driver handles LED blinks etc., Relay outputs and Alarm inputs
*
******************************************************************************/
/*
* Standard in kernel modules
*/
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/devfs_fs_kernel.h>
#include <linux/version.h>
#include <linux/init.h>
#include <linux/poll.h>
#include <linux/spinlock.h>
#include <asm/types.h>
#include <asm/uaccess.h>
#include <linux/interrupt.h>
#include <asm/immap_cpm2.h>
#include <asm/cpm2.h>
#include <asm/mpc8260.h>
#undef DEBUG
#ifdef DEBUG
# define debugk(fmt,args...) printk(fmt ,##args)
#else
# define debugk(fmt,args...)
#endif
/*
* Deal with CONFIG_MODVERSIONS
*/
#if CONFIG_MODVERSIONS==1
/* # define MODVERSIONS */
# include <linux/modversions.h>
#endif
/*
* For character devices
*/
#include <linux/fs.h> /* character device definitions */
/* ioctl's */
#define STATUSLED_GET _IOR('L', 1, unsigned long)
#define STATUSLED_SET _IOW('L', 2, unsigned long)
#define STATUSLED_PERIOD _IOW('L', 3, unsigned long)
#define STATUS_SWITCH_GET _IOR('L', 4, unsigned long)
#define STATUS_RESET_GET _IOR('L', 5, unsigned long)
#define STATUS_RESET_SET _IOW('L', 6, unsigned long)
#define STATUS_LED_PAR im_ioport.iop_pparc
#define STATUS_LED_DIR im_ioport.iop_pdirc
#define STATUS_LED_DAT im_ioport.iop_pdatc
#define STATUS_LED_OFF 0
#define STATUS_LED_BLINKING 1
#define STATUS_LED_ON 2
#define STATUS_RELAY_BIT0 0x00000008 /* RELAY 1 bit 28 */
#define STATUS_RELAY_PERIOD0 (HZ)
#define STATUS_RELAY_STATE0 STATUS_LED_OFF
#define STATUS_RELAY_BIT1 0x10000040 /* RELAY 2 bit 25 */
#define STATUS_RELAY_PERIOD1 (HZ)
#define STATUS_RELAY_STATE1 STATUS_LED_OFF
#define STATUS_LED_BIT 0x20000000 /* LED 0 is on PC.2 OPERATE_LED */
#define STATUS_LED_PERIOD (HZ)
#define STATUS_LED_STATE STATUS_LED_BLINKING
#define STATUS_LED_BIT1 0x10000000 /* LED 1 is on PC.3 ALARM_LED */
#define STATUS_LED_PERIOD1 (HZ)
#define STATUS_LED_STATE1 STATUS_LED_ON
#define STATUS_LED_BIT2 0x08000000 /* LED 2 is on PC.4 BOOT_LED */
#define STATUS_LED_PERIOD2 (HZ)
#define STATUS_LED_STATE2 STATUS_LED_OFF
#define STATUS_LED_ACTIVE 0 /* LED on for bit == 1 */
#define STATUS_LED_BOOT 2 /* LED 0 used for boot status */
#define PCMCIA_LED 0
#define STATUS_LED 1
#define FRONT_LED 2
#define LED_MAJOR 151 /* Reserverd for "Front panel LEDs" */
#define DRIVER_VERSION "$Revision: 1.0 $"
static void statusled_blink (unsigned long minor);
/*
* Device Declarations
* PB25 & PB28
*/
typedef struct {
uint iop_pdirx;
uint iop_pparx;
uint iop_psorx;
uint iop_podrx;
uint iop_pdatx;
char res1[12];
} iop ;
typedef struct {
unsigned long mask;
int state;
int period;
int flags;
int pol; // Polarity
iop *iptr;
struct timer_list timer;
} led_dev_t;
#define SL_FLAG_OPEN 1
led_dev_t led_dev[] = {
{ STATUS_LED_BIT,
STATUS_LED_STATE,
STATUS_LED_PERIOD,
0,
STATUS_LED_ACTIVE,
(iop*)&((cpm2_map_t *)IMAP_ADDR)->STATUS_LED_DIR,
{ function: statusled_blink, data: 0UL /* minor 0 */ },
},
#if defined(STATUS_LED_BIT1)
{ STATUS_LED_BIT1,
STATUS_LED_STATE1,
STATUS_LED_PERIOD1,
0,
STATUS_LED_ACTIVE,
(iop*)&((cpm2_map_t *)IMAP_ADDR)->im_ioport.iop_pdirc,
{ function: statusled_blink, data: 1UL /* minor 1 */ },
},
#endif /* STATUS_LED_BIT1 */
#if defined(STATUS_LED_BIT2)
{ STATUS_LED_BIT2,
STATUS_LED_STATE2,
STATUS_LED_PERIOD2,
0,
STATUS_LED_ACTIVE,
(iop*)&((cpm2_map_t *)IMAP_ADDR)->im_ioport.iop_pdirc,
{ function: statusled_blink, data: 2UL /* minor 2 */ },
},
#endif /* STATUS_RELAY_0 */
{ STATUS_RELAY_BIT0,
STATUS_RELAY_STATE0,
STATUS_RELAY_PERIOD0,
0,
1,
(iop*)&((cpm2_map_t *)IMAP_ADDR)->im_ioport.iop_pdirb,
{ function: statusled_blink, data: 2UL /* minor 2 */ },
},
{ STATUS_RELAY_BIT1,
STATUS_RELAY_STATE1,
STATUS_RELAY_PERIOD1,
0,
1,
(iop*)&((cpm2_map_t *)IMAP_ADDR)->im_ioport.iop_pdirb,
{ function: statusled_blink, data: 2UL /* minor 2 */ },
},
};
#define MAX_LED_DEV (sizeof(led_dev)/sizeof(led_dev_t))
/*
* On the IVM* we handle 2 additional devices with this driver:
* MAX_LED_DEV+0 => "Interlock Switch" and "Device Reset Monitor":
* Both are input pins, which are polled periodically,
* and the user can wait with select() for a status change.
* MAX_LED_DEV+1 => "Device Reset Enable", an output device we can set or reset.
*/
#if defined(CONFIG_IVMS8) || defined(CONFIG_IVML24)
# define MAX_IO_DEV 2
static int io_dev_flags[MAX_IO_DEV] = { 0, }; /* additional I/O devices */
#else
# define MAX_IO_DEV 0
#endif /* CONFIG_IVMS8, CONFIG_IVML24 */
static volatile cpm2_map_t *limmr = 0;
/*
* The name for our device, as it will appear in /proc/devices
*/
#define DEVICE_NAME "status_led"
/*
* Prototypes
*/
static int statusled_init (void) __init;
static int statusled_open(struct inode *, struct file *);
static int statusled_release(struct inode *, struct file *);
# if defined(CONFIG_IVMS8) || defined(CONFIG_IVML24)
static ssize_t statusled_read(struct file *, char *, size_t, loff_t *);
static unsigned int statusled_poll (struct file *, poll_table *);
# endif /* CONFIG_IVMS8, CONFIG_IVML24 */
int init_module(void);
void cleanup_module(void);
static ssize_t statusled_ioctl(struct inode *, struct file *,
unsigned int, unsigned long);
static struct file_operations statusled_fops = {
owner: THIS_MODULE,
open: statusled_open,
release: statusled_release,
ioctl: statusled_ioctl,
# if defined(CONFIG_IVMS8) || defined(CONFIG_IVML24)
read: statusled_read,
poll: statusled_poll,
# endif /* CONFIG_IVMS8, CONFIG_IVML24 */
};
static int Major;
/*
* Initialize the driver - Register the character device
*/
static int __init statusled_init (void)
{
int i;
if (!limmr) { /* init CPM ptr */
limmr = (volatile cpm2_map_t *)IMAP_ADDR;
}
/*
* Register the character device
*/
if ((i = register_chrdev(LED_MAJOR, DEVICE_NAME, &statusled_fops)) < 0) {
limmr = NULL;
printk("Unable to get major %d for status LED driver: rc=%d\n",
LED_MAJOR, i);
return (i);
}
Major = LED_MAJOR;
printk (KERN_INFO
"Status LED driver " DRIVER_VERSION " initialized\n");
for (i=0; i<MAX_LED_DEV; ++i) {
led_dev[i].iptr->iop_pparx &= ~(led_dev[i].mask);
#ifdef STATUS_LED_ODR
led_dev[i].iptr->iop_podrx &= ~(led_dev[i].mask);
#endif
if (led_dev[i].state == STATUS_LED_ON) {
if( led_dev[i].pol == 0 ) /* start with LED on */
led_dev[i].iptr->iop_pdatx &= ~(led_dev[i].mask);
else
led_dev[i].iptr->iop_pdatx |= led_dev[i].mask ;
} else {
if( led_dev[i].pol == 0 ) /* start with LED off */
led_dev[i].iptr->iop_pdatx |= led_dev[i].mask ;
else
led_dev[i].iptr->iop_pdatx &= ~(led_dev[i].mask);
}
led_dev[i].iptr->iop_pdirx |= led_dev[i].mask;
statusled_blink(i);
}
#if defined(CONFIG_IVMS8) || defined(CONFIG_IVML24)
/*
* We use the same function (originally for the ILOCK device only)
* to poll both the ILOCK and RESET_MON ports
*/
io_timer.function = status_io_poll;
io_timer.data = STATUS_ILOCK_PERIOD;
last_io_state = (char)status_io_test();
changed_io_state = 0;
init_timer(&io_timer);
io_timer.expires = jiffies + io_timer.data;
add_timer(&io_timer);
#endif /* CONFIG_IVMS8, CONFIG_IVML24 */
return (0);
}
/*
* called whenever a process attempts to open the device
*/
static int statusled_open (struct inode *inode, struct file *file)
{
int minor = MINOR(inode->i_rdev);
debugk ("statusled_open(%p,%p): minor %d\n", inode, file, minor);
/*
* Allow for MAX_LED_DEV status LEDs
* On IVMS8 and IVML24: allow for additional I/O devices
*/
if (minor >= MAX_LED_DEV + MAX_IO_DEV)
return (-ENXIO);
if (!limmr)
return (-ENODEV);
/*
* exclusive open only
*/
if (minor < MAX_LED_DEV) {
if (led_dev[minor].flags & SL_FLAG_OPEN)
return -EBUSY;
led_dev[minor].flags |= SL_FLAG_OPEN;
}
/*
* Make sure that the module isn't removed while
* the file is open by incrementing the usage count
*/
debugk ("LED_OPEN: minor %d dir=0x%x par=0x%x dat=0x%x\n",
minor,
limmr->STATUS_LED_DIR, limmr->STATUS_LED_PAR, limmr->STATUS_LED_DAT);
return 0;
}
/*
* Called when a process closes the device.
* Doesn't have a return value in version 2.0.x because it can't fail,
* but in version 2.2.x it is allowed to fail
*/
static int statusled_release (struct inode *inode, struct file *file)
{
int minor = MINOR(inode->i_rdev);
debugk ("statusled_release(%p,%p)\n", inode, file);
if (!limmr)
return (-ENODEV);
/* We're now ready for our next caller */
if (minor < MAX_LED_DEV) {
led_dev[minor].flags &= ~SL_FLAG_OPEN;
}
debugk ("LED_CLOSE: dir=0x%x par=0x%x dat=0x%x\n",
limmr->STATUS_LED_DIR, limmr->STATUS_LED_PAR, limmr->STATUS_LED_DAT);
return 0;
}
#if defined(CONFIG_IVMS8) || defined(CONFIG_IVML24)
/*
* read entry point:
* Only supported for interlock switch (return ENXIO for LED devices).
* For the ilock switch, block until the next status change happens;
* then return exactly one byte containing the current state
* (0x00 switch open, 0x01 switch closed).
*/
static ssize_t statusled_read (struct file *file,
char *buf, size_t count, loff_t *ppos)
{
DECLARE_WAITQUEUE(wait, current);
int minor = MINOR(file->f_dentry->d_inode->i_rdev);
int rc = 0;
char c;
if (minor != MAX_LED_DEV)
return (-ENXIO);
add_wait_queue(&statusled_wait, &wait);
current->state = TASK_INTERRUPTIBLE;
for (;;) {
if (changed_io_state)
break;
if (file->f_flags & O_NONBLOCK) {
rc = -EAGAIN;
goto OUT;
}
if (signal_pending(current)) {
rc = -ERESTARTSYS;
goto OUT;
}
schedule ();
}
spin_lock (&statusled_lock);
c = (char)status_io_test ();
changed_io_state = 0;
spin_unlock (&statusled_lock);
/* Copy out */
if ((rc = verify_area(VERIFY_WRITE, buf, 1)) != 0) {
goto OUT;
}
rc = 1; copy_to_user((void *)buf, (void*)(&c), rc);
OUT:
current->state = TASK_RUNNING;
remove_wait_queue(&statusled_wait, &wait);
return (rc);
}
static unsigned int statusled_poll (struct file *file, poll_table *wait)
{
poll_wait(file, &statusled_wait, wait);
if (changed_io_state)
return POLLIN | POLLRDNORM;
return 0;
}
#endif /* CONFIG_IVMS8, CONFIG_IVML24 */
/*
* ioctl entry point:
*/
static ssize_t statusled_ioctl (
struct inode *inode,
struct file *file,
unsigned int cmd,
unsigned long arg)
{
int minor = MINOR(inode->i_rdev);
int n;
if (!limmr)
return (-ENODEV);
debugk ("IOCTL: minor=%d, cmd=%s, arg=%ld\n",
minor,
(cmd == STATUSLED_GET ) ? "STATUSLED_GET" :
(cmd == STATUSLED_SET ) ? "STATUSLED_SET" :
(cmd == STATUSLED_PERIOD) ? "STATUSLED_PERIOD" :
"<unknown>",
arg);
if (minor < MAX_LED_DEV) {
switch (cmd) {
case STATUSLED_GET:
switch (led_dev[minor].state) {
case STATUS_LED_OFF: n = 0;
break;
case STATUS_LED_ON: n = -1;
break;
default: n = led_dev[minor].period;
break;
}
return (copy_to_user((int *)arg, &n, sizeof (int)));
case STATUSLED_SET:
switch (arg) {
case STATUS_LED_OFF:
debugk ("IOCTL: was %d, set %ld=OFF\n",
led_dev[minor].state, arg);
if (led_dev[minor].state == STATUS_LED_BLINKING)
del_timer(&led_dev[minor].timer);
led_dev[minor].state = arg;
if( led_dev[minor].pol == 0 )
led_dev[minor].iptr->iop_pdatx |= led_dev[minor].mask ;
else
led_dev[minor].iptr->iop_pdatx &= ~(led_dev[minor].mask);
return (0);
case STATUS_LED_ON:
debugk ("IOCTL: was %d, set %ld=ON\n",
led_dev[minor].state, arg);
if (led_dev[minor].state == STATUS_LED_BLINKING)
del_timer(&led_dev[minor].timer);
led_dev[minor].state = arg;
if( led_dev[minor].pol == 0 )
led_dev[minor].iptr->iop_pdatx &= ~(led_dev[minor].mask);
else
led_dev[minor].iptr->iop_pdatx |= led_dev[minor].mask ;
return (0);
case STATUS_LED_BLINKING:
debugk ("IOCTL: was %d, set %ld=BLINKING\n",
led_dev[minor].state, arg);
if (led_dev[minor].state == STATUS_LED_BLINKING)
return (0);
led_dev[minor].state = arg; /* must come first! */
/* start blinking */
statusled_blink (minor);
return (0);
}
return (-EINVAL);
case STATUSLED_PERIOD:
led_dev[minor].period = arg;
debugk ("IOCTL: set PERIOD=%d\n", arg);
return (0);
}
}
#if defined(CONFIG_IVMS8) || defined(CONFIG_IVML24)
else {
int m = minor - MAX_LED_DEV;
switch (m) {
case 0: /* Interlock switch and device reset monitor */
if (cmd == STATUS_SWITCH_GET) {
n = status_io_test ();
return (copy_to_user((int *)arg, &n, sizeof (int)));
}
break;
case 1: /* Device reset enable output */
if (cmd == STATUS_RESET_GET) {
if (limmr->im_ioport.iop_pcdat & STATUS_RESET_ENA) {
n = 1;
} else {
n = 0;
}
return (copy_to_user((int *)arg, &n, sizeof (int)));
}
if (cmd == STATUS_RESET_SET) {
if (arg == 0) {
limmr->im_ioport.iop_pcdat &= ~STATUS_RESET_ENA;
} else {
limmr->im_ioport.iop_pcdat |= STATUS_RESET_ENA;
}
return (0);
}
break;
default:
break;
}
}
#endif
return (-EINVAL);
}
#if defined(CONFIG_IVMS8) || defined(CONFIG_IVML24)
/*
* Test status of interlock switch
*/
static int status_io_test (void)
{
int n = 0;
#if defined(CONFIG_IVMS8)
spin_lock (&statusled_lock);
if ((limmr->im_siu_conf.sc_sipend & STATUS_ILOCK_SWITCH) != 0)
n |= STATUS_ILOCK_BIT;
limmr->im_siu_conf.sc_sipend = STATUS_ILOCK_SWITCH;
spin_unlock (&statusled_lock);
#elif defined(CONFIG_IVML24)
if ((limmr->im_cpm.cp_pbdat & STATUS_ILOCK_SWITCH) != 0)
n |= STATUS_ILOCK_BIT;
#endif
if ((limmr->im_ioport.iop_pcdat & STATUS_RESET_MON) != 0)
n |= STATUS_RESET_MON_BIT;
return (n);
}
static void status_io_poll (unsigned long period)
{
char c;
spin_lock (&statusled_lock);
c = (char)status_io_test ();
if (c != last_io_state) {
last_io_state = c;
changed_io_state = 1;
}
spin_unlock (&statusled_lock);
if (changed_io_state)
wake_up_interruptible(&statusled_wait);
init_timer(&io_timer);
io_timer.expires = jiffies + io_timer.data;
add_timer(&io_timer);
}
#endif /* CONFIG_IVMS8, CONFIG_IVML24 */
/*
* Timer controlled blink entry point.
*
* We delete the timer when the status is changed to non-blinking
* or when the module is unloaded.
*/
static void statusled_blink (unsigned long minor)
{
unsigned long flags;
if (!limmr)
return;
if (led_dev[minor].state != STATUS_LED_BLINKING) {
/* don't change any more */
return;
}
limmr->STATUS_LED_DAT ^= led_dev[minor].mask;
save_flags(flags);
cli();
init_timer(&led_dev[minor].timer);
led_dev[minor].timer.expires = jiffies + led_dev[minor].period;
add_timer(&led_dev[minor].timer);
restore_flags(flags);
}
/******************************
**** Module Declarations *****
**************************** */
module_init (statusled_init);
#ifdef MODULE
/*
* Cleanup - unregister the driver
*/
void statusled_cleanup (void)
{
int minor, ret;
/*
* Cleanup timer
*/
for (minor=0; minor<MAX_LED_DEV; ++minor) {
if (led_dev[minor].state == STATUS_LED_BLINKING)
del_timer(&led_dev[minor].timer);
if( led_dev[minor].pol == 0 )
led_dev[minor].iptr->iop_pdatx |= led_dev[minor].mask ;
else
led_dev[minor].iptr->iop_pdatx &= ~(led_dev[minor].mask);
led_dev[minor].state = STATUS_LED_OFF;
}
#if defined(CONFIG_IVMS8) || defined(CONFIG_IVML24)
del_timer(&io_timer);
#endif /* CONFIG_IVMS8, CONFIG_IVML24 */
/*
* Unregister the device
*/
ret = unregister_chrdev (Major, DEVICE_NAME);
/*
* If there's an error, report it
*/
if (ret < 0) {
printk ("unregister_chrdev: error %d\n", ret);
}
}
module_exit (statusled_cleanup);
MODULE_DESCRIPTION("RCB8270 led & relay driver");
MODULE_AUTHOR("Hans Schillstrom LPG Allgon AB <hans.schillstrom@pwav.com>");
MODULE_LICENSE("GPL");
#endif /* MODULE */
^ permalink raw reply
* Re: mapping large amount of memory on physical addresses
From: Jean-Christophe Dubois @ 2005-03-17 9:57 UTC (permalink / raw)
To: scarayol; +Cc: linuxppc-embedded
In-Reply-To: <OFF0E6C961.C5D53940-ONC1256FC7.002D9E1C@brime.fr>
Hello Sophie,
If you really need the 36MB block in DV to be a physically contiguous
memory block one possible simple solution would be to exclude both high
memory blocks from Linux at boot time with mem=3D220M on the cmdline.
Then you could write 2 simple mapping drivers for the DV and MC memory
blocks. This would allow you to map the 2 areas from user space and copy
data back and forth. The drivers you would write would not do ioremap()
but rather remap_page_range() in the implementation of the mmap()
function.
Now I am not sure if you want to use the PPC to transfer data between
the 2 areas or if you have some other hardware mean to do it. If so you
could also integrate this in your driver.
Now if you don't really care if the 36MB block is physically contiguous
(but only logically contiguous and physically scattered), you would
write only the MC driver part and use standard memory allocation for the
36MB block (with the drawback that you will not be necessarily sure to
be able to allocate such memory block as it would not be
pre-allocated/reserved and it depends if there is enough free space at
the allocation time. So pre-allocation at boot time could be your best
bet anyway).
Regards
JC
=20
On Thu, 2005-03-17 at 09:51 +0100, scarayol@assystembrime.com wrote:
> Hello,
>=20
> Could you help me : I work on embedded Linux on a MPC885 processor
> (PowerPC). On my embedded system, i have 2 different components of RAM. O=
ne
> (name =3D DV, total size of 256 MB ) is only accessed by the processor, t=
he
> other (name =3D MC, size =3D 2MB on the top of the RAM) is also access by=
an
> FPGA. I want to do data transferts between each others. For that, I have =
to
> allocate a big structure on DV for a size of 36 MB.
> - Could I do like that to have contiguous memory on DV ?
> For MC, it would be more complicated : I have to map on the physical
> adresses of MC (for example 1300 0000-13FF FFFF) in order to be sure that
> the memory will be really allocated on MC and not on DV (as there is enou=
gh
> place on DV).
> - How can I do that ?
> - Do I have to write a driver and use ioremap on the physical address of =
MC
> (with reserving the top of memory with 'mem=3D' at boot time) ? Can i use
> physical addresses with ioremap or is it only virtual addresses ?
> I think i can reserve the memory early in boot via the bootmem allocator
> but i think it isn't with physical addresses only an amount of memory and
> it's only forbdrivers directly linked in the kernel image and i want a
> module.
> - Is there another solution to do that ?
>=20
> Thank you really for your help.
>=20
> Best regards.
>=20
> ----------------------------------------------------------
> Sophie CARAYOL
>=20
> TECHNOLOGIES & SYSTEMES
> 50 rue du Pr=C3=A9sident Sadate
> F - 29337 QUIMPER CEDEX
>=20
> T=C3=A9l: +33 2 98 10 30 06
> mailto:scarayol@assystembrime.com
> ----------------------------------------------------------
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: RTC with TQM823L
From: Jean Nicollerat MD @ 2005-03-17 9:27 UTC (permalink / raw)
To: wd; +Cc: Linuxppc-Embedded
In-Reply-To: <20050317083415.4BCD5C1510@atlas.denx.de>
Thanks for your answer.
I'm used to program on processor without OS. I want try linux to use linux
to have have LCD, ethernet, USB, ... , dirvers.
I have to read message that comme on the CAN bus every 2ms. Then I have to
show values on the LCD and transfers some message on the RS232.
I need a timer to the check the reception of the messages.
I seem it is difficult with linux. I will try with the RTAI.
regards
Jean Nicollerat
regards
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: Thursday, March 17, 2005 9:34 AM
To: Jean Nicollerat MD
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: RTC with TQM823L
In message <HMECJAKDCPLOGPDHNAHECEKFCAAA.jean.nicollerat@microdev.ch> you
wrote:
>
> I need to have an interrup every 10ms in my application running in linux.
This is an oxymoron. Interrups are processed in kernel space,
applications are running in userspace. You cannot process interrupts
in aplication code.
> I try to use the RTC modules but with the code :
>
> fd = open ("/dev/rtc", O_RDONLY);
>
> if (fd == -1) {
> perror("/dev/rtc");
> }
> /* Turn on update interrupts (one per second) */
You mentioned you wanted signals (not interrupts) every 10 millisec,
not every second -- what exactly is it that you want?
> retval = ioctl(fd, RTC_UIE_ON, 0);
...
> ioctl : invalide argument # for then line :"retval = ioctl(fd,
RTC_UIE_ON,
> 0);"
Which means that the driver does not support this ioctl.
> Can somebody help ? why it is not working or a better way to get function
> called each 10ms
You can use setitimer. But be warned. Your requirement of having
signals every 10 milliseconds means that there is a serious problem
with your software design. You are doing someting really, really
wrong. To me it sounds as if you try to implement your own timer
based control loop in user space with an insane smapp period. This
will never work reliably (as there is no guarantee that your tasks
will be scheduled in time), and will waste a lot of CPU power.
Never take existing software designs from other operating system
environments and put them without thinking into a Unix environment.
Often there are much better and more efficient approaches in Unix.
Just in case you really must stick with that 10 millisecond raster:
in this case you will probably have to use RTAI (especially on a
resource-limted CPU like the 823).
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
The trouble with our times is that the future is not what it used to
be. - Paul Valery
^ permalink raw reply
* mapping large amount of memory on physical addresses
From: scarayol @ 2005-03-17 8:51 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
Could you help me : I work on embedded Linux on a MPC885 processor
(PowerPC). On my embedded system, i have 2 different components of RAM.=
One
(name =3D DV, total size of 256 MB ) is only accessed by the processor,=
the
other (name =3D MC, size =3D 2MB on the top of the RAM) is also access =
by an
FPGA. I want to do data transferts between each others. For that, I hav=
e to
allocate a big structure on DV for a size of 36 MB.
- Could I do like that to have contiguous memory on DV ?
For MC, it would be more complicated : I have to map on the physical
adresses of MC (for example 1300 0000-13FF FFFF) in order to be sure th=
at
the memory will be really allocated on MC and not on DV (as there is en=
ough
place on DV).
- How can I do that ?
- Do I have to write a driver and use ioremap on the physical address o=
f MC
(with reserving the top of memory with 'mem=3D' at boot time) ? Can i u=
se
physical addresses with ioremap or is it only virtual addresses ?
I think i can reserve the memory early in boot via the bootmem allocato=
r
but i think it isn't with physical addresses only an amount of memory a=
nd
it's only forbdrivers directly linked in the kernel image and i want a=
module.
- Is there another solution to do that ?
Thank you really for your help.
Best regards.
----------------------------------------------------------
Sophie CARAYOL
TECHNOLOGIES & SYSTEMES
50 rue du Pr=E9sident Sadate
F - 29337 QUIMPER CEDEX
T=E9l: +33 2 98 10 30 06
mailto:scarayol@assystembrime.com
----------------------------------------------------------
=
^ permalink raw reply
* Re: RTC with TQM823L
From: Jaap-Jan Boor @ 2005-03-17 8:23 UTC (permalink / raw)
To: Jean Nicollerat MD; +Cc: linuxppc-embedded
In-Reply-To: <HMECJAKDCPLOGPDHNAHECEKFCAAA.jean.nicollerat@microdev.ch>
Can't you use a cpmtimer to fire every 10ms and wakeup a
high priority thread?
Jaap-Jan
On 17-mrt-05, at 8:47, Jean Nicollerat MD wrote:
> Hello,
> I need to have an interrup every 10ms in my application running in
> linux.
> I have a PowerPC 823 on the board TQM823L LCD from denx.
> I use the ocan driver.
> I try to use the RTC modules but with the code :
>
> fd = open ("/dev/rtc", O_RDONLY);
>
> if (fd == -1) {
> perror("/dev/rtc");
> }
> /* Turn on update interrupts (one per second) */
>
> retval = ioctl(fd, RTC_UIE_ON, 0);
> if (retval == -1) {
> perror("ioctl");
> //exit(errno);
> }
>
> I get an error message :
> ioctl : invalide argument # for then line :"retval = ioctl(fd,
> RTC_UIE_ON,
> 0);"
>
> Can somebody help ? why it is not working or a better way to get
> function
> called each 10ms
>
> Thanks
>
> Jean
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: RTC with TQM823L
From: Wolfgang Denk @ 2005-03-17 8:34 UTC (permalink / raw)
To: Jean Nicollerat MD; +Cc: linuxppc-embedded
In-Reply-To: <HMECJAKDCPLOGPDHNAHECEKFCAAA.jean.nicollerat@microdev.ch>
In message <HMECJAKDCPLOGPDHNAHECEKFCAAA.jean.nicollerat@microdev.ch> you wrote:
>
> I need to have an interrup every 10ms in my application running in linux.
This is an oxymoron. Interrups are processed in kernel space,
applications are running in userspace. You cannot process interrupts
in aplication code.
> I try to use the RTC modules but with the code :
>
> fd = open ("/dev/rtc", O_RDONLY);
>
> if (fd == -1) {
> perror("/dev/rtc");
> }
> /* Turn on update interrupts (one per second) */
You mentioned you wanted signals (not interrupts) every 10 millisec,
not every second -- what exactly is it that you want?
> retval = ioctl(fd, RTC_UIE_ON, 0);
...
> ioctl : invalide argument # for then line :"retval = ioctl(fd, RTC_UIE_ON,
> 0);"
Which means that the driver does not support this ioctl.
> Can somebody help ? why it is not working or a better way to get function
> called each 10ms
You can use setitimer. But be warned. Your requirement of having
signals every 10 milliseconds means that there is a serious problem
with your software design. You are doing someting really, really
wrong. To me it sounds as if you try to implement your own timer
based control loop in user space with an insane smapp period. This
will never work reliably (as there is no guarantee that your tasks
will be scheduled in time), and will waste a lot of CPU power.
Never take existing software designs from other operating system
environments and put them without thinking into a Unix environment.
Often there are much better and more efficient approaches in Unix.
Just in case you really must stick with that 10 millisecond raster:
in this case you will probably have to use RTAI (especially on a
resource-limted CPU like the 823).
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
The trouble with our times is that the future is not what it used to
be. - Paul Valery
^ permalink raw reply
* Posix message queue
From: Vlad L @ 2005-03-17 8:20 UTC (permalink / raw)
To: Embedded Linux
Dear all,
I have MPC5200 based board and looking for Posix
Message Queue for kernel 2.4... Can you, please,
direct me to resorce where I can load such patch or
library.
Thank you.
Vlad.
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
^ permalink raw reply
* RTC with TQM823L
From: Jean Nicollerat MD @ 2005-03-17 7:47 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I need to have an interrup every 10ms in my application running in linux.
I have a PowerPC 823 on the board TQM823L LCD from denx.
I use the ocan driver.
I try to use the RTC modules but with the code :
fd = open ("/dev/rtc", O_RDONLY);
if (fd == -1) {
perror("/dev/rtc");
}
/* Turn on update interrupts (one per second) */
retval = ioctl(fd, RTC_UIE_ON, 0);
if (retval == -1) {
perror("ioctl");
//exit(errno);
}
I get an error message :
ioctl : invalide argument # for then line :"retval = ioctl(fd, RTC_UIE_ON,
0);"
Can somebody help ? why it is not working or a better way to get function
called each 10ms
Thanks
Jean
^ permalink raw reply
* Re: [PATCH] Make sleep/wakeup work with USB on powerbooks
From: Benjamin Herrenschmidt @ 2005-03-17 7:35 UTC (permalink / raw)
To: Colin Leroy; +Cc: linuxppc-dev list, Paul Mackerras, Linux-USB
In-Reply-To: <20050317075157.19aa4df0@jack.colino.net>
> Would it be the "proper" patch I was looking for in the thread named
> "[PATCH] Re-power USB ports on wakeup" ?
>
> Or does it fix different issues ? Mine fixed, with a hack I think, the
> fact that USB ports kept being powered down after one wakeup out of
> two. I never got any machine check, however.
Test please, your patch shouldn't be necessary.
Ben.
^ permalink raw reply
* Re: [PATCH] Make sleep/wakeup work with USB on powerbooks
From: Colin Leroy @ 2005-03-17 6:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <16953.5968.397116.341920@cargo.ozlabs.ibm.com>
On 17 Mar 2005 at 16h03, Paul Mackerras wrote:
Hi,
> I am currently using this patch on my powerbook to fix the problems
> that USB was causing with sleep and wakeup. Basically one of the USB
> controllers was getting a spurious wakeup immediately when put it
> into the suspend state. This would cause the resume routine to be run
> after we had turned off the device, causing a machine check.
>
> Also we had some races where we would turn off the clock to the apple
> OHCI cell(s) and then try to access them. With this patch, sleep and
> wakeup are quite reliable. The patch is against 2.6.11.
Would it be the "proper" patch I was looking for in the thread named
"[PATCH] Re-power USB ports on wakeup" ?
Or does it fix different issues ? Mine fixed, with a hack I think, the
fact that USB ports kept being powered down after one wakeup out of
two. I never got any machine check, however.
Thanks,
--
Colin
^ permalink raw reply
* RE: LED driver
From: akash kaul @ 2005-03-17 6:15 UTC (permalink / raw)
To: srinivas.surabhi, linuxppc-embedded
In-Reply-To: <EF9B29C78F41FA488927FCBC7750AF0E011DA945@hyd-mdp-msg.wipro.com>
Hi Surabhi,
You basically have to write appropriate values into Port data register
corresponding to the GPIO pin to switch the led on or of. The register
can be accessed thru the immap pointer.(i.e internal memory map pointer
)look at the file include/asm-ppc/immap_cpm2.h relative to ur kernel
source base. You will find the mapped register variable in this file.
If you need to access this immap memory from userspace then u have to
make a system call to enter kernel space and access the immap memory.
Regards,
Akash Kaul
Hi,
I am working on the MPC8270 board having connected GPIO 3 lines
connected to 3 LEDs. So can any one help me in finding out the best
solution of controlling the LEDs from MVlinux (kernel and user space) or
any pointers who has done it before.
Thanks & Rgds
SS
Confidentiality Notice
The information contained in this electronic message and any attachments
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] Make sleep/wakeup work with USB on powerbooks
From: Paul Mackerras @ 2005-03-17 5:36 UTC (permalink / raw)
To: linuxppc-dev, linux-usb-devel
I am currently using this patch on my powerbook to fix the problems
that USB was causing with sleep and wakeup. Basically one of the USB
controllers was getting a spurious wakeup immediately when put it
into the suspend state. This would cause the resume routine to be run
after we had turned off the device, causing a machine check.
Also we had some races where we would turn off the clock to the apple
OHCI cell(s) and then try to access them. With this patch, sleep and
wakeup are quite reliable. The patch is against 2.6.11.
Paul.
diff -urN linux-2.6.11/drivers/usb/core/hcd-pci.c pmac-2.6.11/drivers/usb/core/hcd-pci.c
--- linux-2.6.11/drivers/usb/core/hcd-pci.c 2004-12-19 00:54:45.000000000 +1100
+++ pmac-2.6.11/drivers/usb/core/hcd-pci.c 2005-02-07 14:49:12.000000000 +1100
@@ -32,6 +32,12 @@
#include <linux/usb.h>
#include "hcd.h"
+#ifdef CONFIG_PMAC_PBOOK
+#include <asm/machdep.h>
+#include <asm/pmac_feature.h>
+#include <asm/pci-bridge.h>
+#include <asm/prom.h>
+#endif
/* PCI-based HCs are normal, but custom bus glue should be ok */
@@ -360,6 +366,17 @@
break;
}
+#ifdef CONFIG_PMAC_PBOOK
+ if (retval == 0 && _machine == _MACH_Pmac) {
+ struct device_node *of_node;
+
+ /* Disable USB PAD & cell clock */
+ of_node = pci_device_to_OF_node (dev);
+ if (of_node)
+ pmac_call_feature(PMAC_FTR_USB_ENABLE, of_node, 0, 0);
+ }
+#endif /* CONFIG_PMAC_PBOOK */
+
/* update power_state **ONLY** to make sysfs happier */
if (retval == 0)
dev->dev.power.power_state = state;
@@ -380,6 +397,20 @@
int has_pci_pm;
hcd = pci_get_drvdata(dev);
+
+#ifdef CONFIG_PMAC_PBOOK
+ if (_machine == _MACH_Pmac) {
+ struct device_node *of_node;
+
+ /* Re-enable USB PAD & cell clock */
+ of_node = pci_device_to_OF_node(dev);
+ if (of_node) {
+ pmac_call_feature (PMAC_FTR_USB_ENABLE, of_node, 0, 1);
+ mdelay(10);
+ }
+ }
+#endif /* CONFIG_PMAC_PBOOK */
+
if (hcd->state != HCD_STATE_SUSPENDED) {
dev_dbg (hcd->self.controller,
"can't resume, not suspended!\n");
@@ -396,14 +427,8 @@
if (has_pci_pm)
pci_set_power_state (dev, 0);
+ mdelay(1);
dev->dev.power.power_state = 0;
- retval = request_irq (dev->irq, usb_hcd_irq, SA_SHIRQ,
- hcd->driver->description, hcd);
- if (retval < 0) {
- dev_err (hcd->self.controller,
- "can't restore IRQ after resume!\n");
- return retval;
- }
hcd->saw_irq = 0;
pci_restore_state (dev);
#ifdef CONFIG_USB_SUSPEND
@@ -417,6 +442,16 @@
"resume fail, retval %d\n", retval);
usb_hc_died (hcd);
}
+ if (retval)
+ return retval;
+
+ retval = request_irq (dev->irq, usb_hcd_irq, SA_SHIRQ,
+ hcd->driver->description, hcd);
+ if (retval < 0) {
+ dev_err (hcd->self.controller,
+ "can't restore IRQ after resume!\n");
+ return retval;
+ }
return retval;
}
diff -urN linux-2.6.11/drivers/usb/host/ohci-hcd.c pmac-2.6.11/drivers/usb/host/ohci-hcd.c
--- linux-2.6.11/drivers/usb/host/ohci-hcd.c 2005-01-31 17:33:41.000000000 +1100
+++ pmac-2.6.11/drivers/usb/host/ohci-hcd.c 2005-02-07 16:27:33.000000000 +1100
@@ -609,8 +609,10 @@
ohci_writel (ohci, ohci->hc_control, &ohci->regs->control);
ohci_to_hcd(ohci)->state = USB_STATE_RUNNING;
+#ifdef CONFIG_USB_SUSPEND
/* wake on ConnectStatusChange, matching external hubs */
ohci_writel (ohci, RH_HS_DRWE, &ohci->regs->roothub.status);
+#endif
/* Choose the interrupts we care about now, others later on demand */
mask = OHCI_INTR_INIT;
@@ -720,7 +722,9 @@
if (ints & OHCI_INTR_RD) {
ohci_vdbg (ohci, "resume detect\n");
- schedule_work(&ohci->rh_resume);
+ ohci_writel (ohci, OHCI_INTR_RD, ®s->intrstatus);
+ if (!(ohci->flags & OHCI_SUSPENDING))
+ schedule_work(&ohci->rh_resume);
}
if (ints & OHCI_INTR_WDH) {
diff -urN linux-2.6.11/drivers/usb/host/ohci-hub.c pmac-2.6.11/drivers/usb/host/ohci-hub.c
--- linux-2.6.11/drivers/usb/host/ohci-hub.c 2004-12-23 10:48:43.000000000 +1100
+++ pmac-2.6.11/drivers/usb/host/ohci-hub.c 2005-02-07 15:23:56.000000000 +1100
@@ -102,10 +102,12 @@
ohci_writel (ohci, ohci_readl (ohci, &ohci->regs->intrstatus),
&ohci->regs->intrstatus);
+#ifdef CONFIG_USB_SUSPEND
/* maybe resume can wake root hub */
if (hcd->remote_wakeup)
ohci->hc_control |= OHCI_CTRL_RWE;
else
+#endif
ohci->hc_control &= ~OHCI_CTRL_RWE;
/* Suspend hub */
diff -urN linux-2.6.11/drivers/usb/host/ohci-pci.c pmac-2.6.11/drivers/usb/host/ohci-pci.c
--- linux-2.6.11/drivers/usb/host/ohci-pci.c 2004-12-19 02:22:52.000000000 +1100
+++ pmac-2.6.11/drivers/usb/host/ohci-pci.c 2005-02-07 15:23:53.000000000 +1100
@@ -114,23 +114,22 @@
(void) usb_suspend_device (hcd->self.root_hub, state);
#else
usb_lock_device (hcd->self.root_hub);
+
+ /* don't wake on ConnectStatusChange */
+ ohci_writel(ohci, RH_HS_CRWE, &ohci->regs->roothub.status);
+ ohci_readl(ohci, &ohci->regs->roothub.status);
+ ohci->flags |= OHCI_SUSPENDING;
+ msleep(10);
+
(void) ohci_hub_suspend (hcd);
usb_unlock_device (hcd->self.root_hub);
+
#endif
/* let things settle down a bit */
+ flush_scheduled_work();
msleep (100);
-#ifdef CONFIG_PMAC_PBOOK
- if (_machine == _MACH_Pmac) {
- struct device_node *of_node;
-
- /* Disable USB PAD & cell clock */
- of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.controller));
- if (of_node)
- pmac_call_feature(PMAC_FTR_USB_ENABLE, of_node, 0, 0);
- }
-#endif /* CONFIG_PMAC_PBOOK */
return 0;
}
@@ -140,17 +139,6 @@
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
int retval = 0;
-#ifdef CONFIG_PMAC_PBOOK
- if (_machine == _MACH_Pmac) {
- struct device_node *of_node;
-
- /* Re-enable USB PAD & cell clock */
- of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.controller));
- if (of_node)
- pmac_call_feature (PMAC_FTR_USB_ENABLE, of_node, 0, 1);
- }
-#endif /* CONFIG_PMAC_PBOOK */
-
/* resume root hub */
if (time_before (jiffies, ohci->next_statechange))
msleep (100);
@@ -159,6 +147,7 @@
retval = usb_resume_device (hcd->self.root_hub);
#else
usb_lock_device (hcd->self.root_hub);
+ ohci->flags &= ~OHCI_SUSPENDING;
retval = ohci_hub_resume (hcd);
usb_unlock_device (hcd->self.root_hub);
#endif
diff -urN linux-2.6.11/drivers/usb/host/ohci.h pmac-2.6.11/drivers/usb/host/ohci.h
--- linux-2.6.11/drivers/usb/host/ohci.h 2004-12-19 02:22:52.000000000 +1100
+++ pmac-2.6.11/drivers/usb/host/ohci.h 2005-02-06 12:32:37.000000000 +1100
@@ -397,6 +397,7 @@
#define OHCI_QUIRK_INITRESET 0x04 /* SiS, OPTi, ... */
#define OHCI_BIG_ENDIAN 0x08 /* big endian HC */
// there are also chip quirks/bugs in init logic
+#define OHCI_SUSPENDING 0x100
};
^ permalink raw reply
* FW: LED driver
From: srinivas.surabhi @ 2005-03-17 5:15 UTC (permalink / raw)
To: linuxppc-embedded
-----Original Message-----
From: Srinivas Surabhi (WT01 - TELECOM SOLUTIONS)=0D
Sent: Thursday, March 17, 2005 7:53 AM
To: linuxppc-embedded@ozlabs.org
Subject: LED driver=0D
Hi,
I am working on the MPC8270 board having connected GPIO 3 lines
connected to 3 LEDs. So can any one help me in finding out the best
solution of controlling the LEDs from MVlinux (kernel and user space) or
any pointers who has done it before.=0D
Thanks & Rgds
SS=0D
Confidentiality Notice=0D
The information contained in this electronic message and any attachments to=
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or=
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or=
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
^ permalink raw reply
* Re: [PATCH] boot time scheduling w hile atomic fix
From: Tom Rini @ 2005-03-17 1:47 UTC (permalink / raw)
To: Takeharu KATO; +Cc: linuxppc-dev, tmm
In-Reply-To: <4238D681.1040003@jp.fujitsu.com>
On Thu, Mar 17, 2005 at 09:59:45AM +0900, Takeharu KATO wrote:
> Hi Tom:
>
> Thank you for your response.
>
> >This is a great first start. But please see
> >Documentation/SubmittingPatches and provide a Signed-off-by line and
> >resubmit. Thanks!
> >
> IIRC, I alreday added the Signed-off-by line.
> And moreI made the patch with "diff -Nupr".
> What's wrong with my mail?
My fault, sorry.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] boot time scheduling w hile atomic fix
From: Takeharu KATO @ 2005-03-17 0:59 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, tmm
In-Reply-To: <20050316221907.GB8345@smtp.west.cox.net>
Hi Tom:
Thank you for your response.
> This is a great first start. But please see
> Documentation/SubmittingPatches and provide a Signed-off-by line and
> resubmit. Thanks!
>
IIRC, I alreday added the Signed-off-by line.
And moreI made the patch with "diff -Nupr".
What's wrong with my mail?
Regards,
--
Takeharu KATO
Fujitsu Limited
Email:kato.takeharu at jp.fujitsu.com
^ permalink raw reply
* Re: boot time scheduling hile atomic
From: Takeharu KATO @ 2005-03-17 0:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1111012124.15509.18.camel@gaston>
Hi Benjamin:
Benjamin Herrenschmidt wrote:
>
> There may be other kernel bits calling syscall, it sounds saner to
> always make sure we don't reschedule when in atomic (though it's dubious
> that it's allowed to do syscalls in atomic regions, let's be safe
> there).
>
> In fact, we are thinking about consolidating the syscall return path and
> the normal irq return path like we did on ppc64.
>
Thkans, I make sense.
Would you send me Paul's patch?
Regards,
--
Takeharu KATO
Fujitsu Limited
Email:kato.takeharu at jp.fujitsu.com
^ permalink raw reply
* Re: [PATCH] compilation failure due to confliction of time_offset
From: Takeharu KATO @ 2005-03-17 0:36 UTC (permalink / raw)
To: Tom Rini; +Cc: galak, linuxppc-embedded
In-Reply-To: <20050316222215.GC8345@smtp.west.cox.net>
Tom:
Sorry, I did misunderstand about it.
I'll fix this if nobody is working on this problem.
Tom Rini wrote:
>
>
> Are you certain that the 'time_offset' referenced in <linux/timex.h> is
> what wants to be used in arch/ppc/kernel/time.c ? Thanks.
>
--
Takeharu KATO
Fujitsu Limited
Email:kato.takeharu at jp.fujitsu.com
^ permalink raw reply
* Re: 440EP FPU patch
From: Tom Rini @ 2005-03-16 23:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <97927672280934c417f3e8fceb7a144b@freescale.com>
On Wed, Mar 16, 2005 at 04:52:00PM -0600, Kumar Gala wrote:
> I dont have either of these readily available at this point.
>
> If you dont mind running it through when you get a chance. However, is
> this going to test anything but FP?
It's more of a funkiness test, just in case.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: porting linux & u-boot on Mdp Pro 8xx board
From: Wolfgang Denk @ 2005-03-16 23:08 UTC (permalink / raw)
To: veikko romppainen; +Cc: linuxppc-embedded
In-Reply-To: <BAY12-F147D953D7254016B942F2994480@phx.gbl>
In message <BAY12-F147D953D7254016B942F2994480@phx.gbl> you wrote:
>
> I have currently running wxWorks on Mdp Pro 823 board. Now i'm trying port
> Linux on it. Firstable i have to get u-boot working on it. I hope someone
> has done this.
Probably not. At least I don't know of any port of U-boot for this
board.
BUT: this is off topic here. Please post U-Boot related questions on
the U-Boot mailing list instead.
> Is there working configuration from u-boot to this board?
> I have modified QS823 conf, because it looks quite similar.
Similar is not good enough.
> Can I use VisionIce 2 and SingleStep to flash u-boot?
Probably, if you know how to use these tools. Sorry, I'm afraid there
is little help for these on tyhe U-Boot list.
> We dont't have BDI in our school, shame. I flashed u-boot by using Ice
> starting at 0xfff00000. It seemed that it went correct place but nothing
> happened when i started my board.
Is this the correct address for your board? Did you use the correct
terminal baudrate?
> I suppose that I can't debug it with Ice and SingleStep.
You should be able to. If not, return the tools to the vendor and get
your money back.
> Do i have to flash more than just u-boot.bin in right address?
No.
> (Environment?)
No. If the environment is invalid (bad CRC checksum), then a
compiled-in default environment will be used.
> Do i need some reg files or prj files?
Dunno.
> I would appreciate if someone could help me with these addresses and
> configs.
>
> Board specs:
> MPC 823 66 Mhz
> 4Mb flash
> 128 Mb RAM
> 512 K SRAM
> 8 K eeprom
Sorry, you need a lot more information about the hardware to give any
usable help - and then it requires a non-negligible amount of work to
come up with the right config data. Don't expect too much from a
mailing list.
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
Don't tell me how hard you work. Tell me how much you get done.
- James J. Ling
^ permalink raw reply
* Re: 440EP FPU patch
From: Kumar Gala @ 2005-03-16 22:52 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20050316221402.GA8345@smtp.west.cox.net>
I dont have either of these readily available at this point.
If you dont mind running it through when you get a chance. However, is=20=
this going to test anything but FP?
- kumar
On Mar 16, 2005, at 4:14 PM, Tom Rini wrote:
> On Wed, Mar 16, 2005 at 01:22:48AM -0600, Kumar Gala wrote:
>
> > Jason,
> >
> > Is it possible to make this against a newer tree (like a current bk
> > pull).=A0 The patch doesn't apply cleanly against head.S, which I'm
> > guessing is due to the SPRN changes pushed upstream recently.
> >
> > If I can apply it cleanly, I will get it pushed upstream.
>
> Can one of you run say LTP on a classic box, just as a sanity test
> before pushing?=A0 If not, lemme know and I'll do it :)
>
> --=20
> Tom Rini
> http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: boot time scheduling hile atomic
From: Benjamin Herrenschmidt @ 2005-03-16 22:28 UTC (permalink / raw)
To: Takeharu KATO; +Cc: linuxppc-dev list
In-Reply-To: <42383D85.7050108@ybb.ne.jp>
On Wed, 2005-03-16 at 23:07 +0900, Takeharu KATO wrote:
> Hi Benjamin:
>
> I can not figure out why my previous patch is more preferable than
> later one.
> Could you explain the reason of that please.
There may be other kernel bits calling syscall, it sounds saner to
always make sure we don't reschedule when in atomic (though it's dubious
that it's allowed to do syscalls in atomic regions, let's be safe
there).
In fact, we are thinking about consolidating the syscall return path and
the normal irq return path like we did on ppc64.
Ben.
^ 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