* io.h question
@ 2006-01-05 21:00 mcnernbm
2006-01-05 23:54 ` Andrei Konovalov
2006-01-06 12:03 ` Arnd Bergmann
0 siblings, 2 replies; 5+ messages in thread
From: mcnernbm @ 2006-01-05 21:00 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 606 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: io.h question
2006-01-05 21:00 io.h question mcnernbm
@ 2006-01-05 23:54 ` Andrei Konovalov
2006-01-06 12:03 ` Arnd Bergmann
1 sibling, 0 replies; 5+ messages in thread
From: Andrei Konovalov @ 2006-01-05 23:54 UTC (permalink / raw)
To: mcnernbm; +Cc: linuxppc-embedded
Brett,
Is your program a kernel module?
asm/io.h is for kernel only (everything is inside #ifdef __KERNEL__ ... #endif)
Probably you build the module incorrectly so that __KERNEL__ is not defined.
If this is the case you may want to check the LDD book, chapter 2 "Building and
Running Modules".
Thanks,
Andrei
mcnernbm@notes•udayton.edu wrote:
> I finally noticed out_8 and in_8 and what not are located in the ppc
> io.h file in the kernel development download. But when I tried to do a
> io.h with in my program I added #include <asm/io.h> and it seems to
> find it with not problems but it can not find the functions with in that
> file. Am i missing a define I need to set or something so I can see the
> right files with in io.h I am compiling for a ppc405 on a xilinx virtex
> 4 board.
> Thanks
> Brett
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs•org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: io.h question
2006-01-05 21:00 io.h question mcnernbm
2006-01-05 23:54 ` Andrei Konovalov
@ 2006-01-06 12:03 ` Arnd Bergmann
1 sibling, 0 replies; 5+ messages in thread
From: Arnd Bergmann @ 2006-01-06 12:03 UTC (permalink / raw)
To: linuxppc-embedded
On Thursday 05 January 2006 21:00, mcnernbm@notes•udayton.edu wrote:
> I finally noticed out_8 and in_8 and what not are located in the
> ppc io.h file in the kernel development download. But when I
> tried to do a io.h with in my program I added #include <asm/io.h>
> and it seems to find it with not problems but it can not find the
> functions with in that file. Am i missing a define I need to set
> or something so I can see the right files with in io.h I am
> compiling for a ppc405 on a xilinx virtex 4 board.
The definitions in that file are only usable from inside the kernel,
you can not use them in a user space application.
The correct way to solve your problem (which you did not explain, so
I can only guess) would be to write a kernel device driver for
the peripherial you want to drive, at least if it does not exist yet.
For prototyping, you can play with mmap() on /dev/mem in a user
application, but that is often not very reliable.
Arnd <><
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: io.h question
@ 2006-01-09 12:16 Fillod Stephane
2006-01-09 12:39 ` Arnd Bergmann
0 siblings, 1 reply; 5+ messages in thread
From: Fillod Stephane @ 2006-01-09 12:16 UTC (permalink / raw)
To: linuxppc-embedded, Arnd Bergmann
Arnd Bergmann wrote:
>On Thursday 05 January 2006 21:00, mcnernbm@notes•udayton.edu wrote:
>> I finally noticed out_8 and in_8 and what not are located in the
>> ppc io.h file in the kernel development download.=A0 But when I=20
>> tried to do a io.h with in my program I added #include <asm/io.h>=A0
>> and it seems to find it with not problems but it can not find the
>> functions with in that file.=A0 Am i missing a define I need to set
>> or something so I can see the right files with in io.h I am
>> compiling for a ppc405 on a xilinx virtex 4 board. =20
>
>The definitions in that file are only usable from inside the kernel,
>you can not use them in a user space application.
You may not include the file directly from a user-land application
program, but you may copy/paste the in_*/out_* macros, with appropriate=20
care off course.
>The correct way to solve your problem (which you did not explain, so
>I can only guess) would be to write a kernel device driver for
>the peripherial you want to drive, at least if it does not exist yet.
Sometimes, user-land access can make things simpler. YMMV.
>For prototyping, you can play with mmap() on /dev/mem in a user
>application, but that is often not very reliable.
For sake of curiosity, what is not reliable in mmap'ed access
by user application?
Regards,
--=20
Stephane
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: io.h question
2006-01-09 12:16 Fillod Stephane
@ 2006-01-09 12:39 ` Arnd Bergmann
0 siblings, 0 replies; 5+ messages in thread
From: Arnd Bergmann @ 2006-01-09 12:39 UTC (permalink / raw)
To: linuxppc-embedded
On Monday 09 January 2006 12:16, Fillod Stephane wrote:
> You may not include the file directly from a user-land application
> program, but you may copy/paste the in_*/out_* macros, with appropriate
> care off course.
Yes, that happens to work on some architectures, but it makes your program
not portable. Also, on some architectures you need special privileges,
e.g. i386 requires you to call iopl() first.
> >The correct way to solve your problem (which you did not explain, so
> >I can only guess) would be to write a kernel device driver for
> >the peripherial you want to drive, at least if it does not exist yet.
>
> Sometimes, user-land access can make things simpler. YMMV.
Yes, that's true. I that's why I said I was only guessing ;-).
But even if I want to do the access from user space, I would
normally write a small device driver that exposes the registers
as an mmappable character device.
> >For prototyping, you can play with mmap() on /dev/mem in a user
> >application, but that is often not very reliable.
>
> For sake of curiosity, what is not reliable in mmap'ed access
> by user application?
- Depending on your device, you may not be able to guarantee the
correct timing for accessing the device.
- Some devices require locking to ensure you are accessing the
registers in the right order. This breaks if you accidentally
run your user space program more than once at a time.
- If the hardware changes with a later revision, you need to change
your user space programs. Such changes ought to be hidden in the
kernel.
- If your program is buggy, you might end up writing to a different
device or memory location, which is very hard to debug.
Arnd <><
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-01-09 12:39 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-05 21:00 io.h question mcnernbm
2006-01-05 23:54 ` Andrei Konovalov
2006-01-06 12:03 ` Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2006-01-09 12:16 Fillod Stephane
2006-01-09 12:39 ` Arnd Bergmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox