removing inb()/outb() from devices
I'd like to finalize the newbus work by changing inb()/outb() calls to bus_space_write calls. Is there a device where this has been partially done already? I'd like to see the old and new styles, then i would fix the vpo/imm zip driver first, since i know that code well. After that, i could start working my way through the tree. jcm -- "I drank WHAT ?!" - Socrates To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: removing inb()/outb() from devices
Thus spake j mckitrick ([EMAIL PROTECTED]): > I'd like to finalize the newbus work by changing inb()/outb() calls to > bus_space_write calls. Is there a device where this has been partially done > already? I'd like to see the old and new styles, then i would fix the It has been done to sys/dev/ed/ about half a year ago. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: removing inb()/outb() from devices
On Wed, May 23, 2001 at 07:04:15PM +0200, Alexander Langer wrote: | Thus spake j mckitrick ([EMAIL PROTECTED]): | | > I'd like to finalize the newbus work by changing inb()/outb() calls to | > bus_space_write calls. Is there a device where this has been partially done | > already? I'd like to see the old and new styles, then i would fix the | | It has been done to sys/dev/ed/ about half a year ago. Found it! Thanks. jcm -- "I drank WHAT ?!" - Socrates To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: removing inb()/outb() from devices
In message <[EMAIL PROTECTED]> j mckitrick writes: : I'd like to finalize the newbus work by changing inb()/outb() calls to : bus_space_write calls. Is there a device where this has been partially done : already? I'd like to see the old and new styles, then i would fix the : vpo/imm zip driver first, since i know that code well. After that, i could : start working my way through the tree. Look at what I just did to the pcic_isa.c and pcic.c drivers wrt to converting from using inb/outb to using bus_space routines. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: removing inb()/outb() from devices
On Thu, May 24, 2001 at 08:06:58PM -0600, Warner Losh wrote: | In message <[EMAIL PROTECTED]> j mckitrick writes: | : I'd like to finalize the newbus work by changing inb()/outb() calls to | : bus_space_write calls. Is there a device where this has been partially done | : already? I'd like to see the old and new styles, then i would fix the | : vpo/imm zip driver first, since i know that code well. After that, i could | : start working my way through the tree. | | Look at what I just did to the pcic_isa.c and pcic.c drivers wrt to | converting from using inb/outb to using bus_space routines. Okay, here's what i will do, then. I will just port all the macros to bus_space calls, and add bus_space_handle and tag to the softc struct for ppc. There are still a lot of direct inb/outb calls, as well as the multi-byte transfer versions. I will try to get those as well. jcm -- "I drank WHAT ?!" - Socrates To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: removing inb()/outb() from devices
One more question: In the probe routines, the values of the hardware ports are changing from one chipset to the next. Throughout the ppc driver, the regular macros are used to access the parallel port control registers, but in the probe routine it reverts to inb/outb, probably because it makes no sense to allocate a port for 2 or three operations, then deallocate it and choose another one. So, should the inb/outb calls in the probe functions be left alone? This is specifically for the ppc driver, where several possible chipsets must be addressed by one driver. jcm -- "I drank WHAT ?!" - Socrates To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: removing inb()/outb() from devices
In message <[EMAIL PROTECTED]> j mckitrick writes: : In the probe routines, the values of the hardware ports are changing from : one chipset to the next. Throughout the ppc driver, the regular macros are : used to access the parallel port control registers, but in the probe routine : it reverts to inb/outb, probably because it makes no sense to allocate a : port for 2 or three operations, then deallocate it and choose another one. Yes, but it does make sense to do that. Some busses you cannot access the resources until they have been activated. pcmcia comes to mind :-). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: removing inb()/outb() from devices
| Yes, but it does make sense to do that. Some busses you cannot access | the resources until they have been activated. pcmcia comes to mind :-). ah, but of course. :-) Well, then, let me know if my plan is acceptable: I will newbussify all macros, and any inb/outb calls i find that are not inside a probe function. How is that? jcm -- "I drank WHAT ?!" - Socrates To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: removing inb()/outb() from devices
In message <[EMAIL PROTECTED]> j mckitrick writes: : I will newbussify all macros, and any inb/outb calls i find that are not : inside a probe function. : : How is that? Ummm, including inb/outb that are in the probe would be better. This would allow us to write a pcmcia attachment to the ppc driver. I have a pcmcia <-> parallel card knocking around somewhere I think. I also have sevearl universal pcmcia port replicators that I'd like to support as well. They are all basically a super I/O chip with pcmcia glue around it. This will likely require a puc-like driver (qv NetBSD's puc driver) so we can attach the children and manage their resources properly. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
