On Jan 18, 2008 7:22 PM, Jenkins, Clive <
Clive.Jenkins@xerox.com> wrote:
> From: linuxppc-embedded-bounces+clive.jenkins=xerox.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+clive.jenkins=xerox.com@ozlabs.org]
> On Behalf Of Ramkumar J
> Sent: 18 January 2008 10:54
> To: linuxppc-embedded@ozlabs.org
> Subject: Adding new driver in Linux 2.6 - read fails with -1
>
> Hi All,
>
> I m using the Linux 2.6(2.6.23-rc2) from Grants for ML-403 and
> I tried to add a new driver for a hardware based stream.
> [...] For read, the function doesnt seem calling the drivers read
> routine and exits with -1. [...]
You are not giving enough information -- better to supply the complete
code of driver and application, and the complete kernel log, or put
them on a web/ftp site and supply pointers to them.
When your application calls read(), I cannot see whether you are
passing a valid file descriptor, whether you have opened the device
etc. You say read() returns -1, but you don't give the value of errno
or the error string corresponding to that value. An easy way to get
this is to use perror() in your app.
> /* Wait while empty. */
> while (((status=readl( ((volatile unsigned char*)
remapped_address)
> + 8)&3))==0)
One thing I can see is that you have a "busy wait" loop in your
driver's read method. This will waste CPU time and may hang
indefinitely. Better to use wait-event_interruptible, and check for
termination of the wait by unexpected events such as signals and
changes of power management state.
Clive
Hi,
Thanks a lot for replying. I will try using the perror() function and modify the busy-loop through wait-for functions. Also, the way I have accessed the memory mapped IO, is to ioremap() the physical address and then use readl() functions. Is this correct.
Following is the link to the driver file,
This is intermediate layer and part of my application space,
The application is,
Logs at,
My apologies for the dirty code. To add some background, it starts from the main() in HelloWorld.c and it proceeds calling the hear_hello() in HelloWorld_sw.c . The co_stream_* functions are defined in intermediate layer co_stream_linux.c and co_stream_open is defined to nothing in one header file. The open and ioctl call ( modified a little in the driver now for debugging) map from co_stream_attach.
co_stream_read is read and co_stream_write is the write to driver.
Though the logs indicate the call of release function before the read, I m not quite sure about this as the read not being called have failed to get inside the kernel messages.
Thanks and Regards,
Ramkumar.