default functions for gpio
WHY I"M ASKING THIS QUESTION: I'm implementing some gpio calls in the ep93xx arch. My problem is that gpio's are really board specific, not just mach specific. I can code the function calls into my board init, but where should these functions be prototyped? Ideally, I think the compiler should build a "default" function for int gpio_request which fails, rather than a compile error for other boards within the same arch. THE ACTUAL QUESTION: Is there a way to build a "default" function, which is compiled in if it's not defined elsewhere? Anyone know where an example of this might be lurking. Also, if this is possible, is it a good idea? thx, NZG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: passing function pointers through platform devices?
On Wednesday 07 March 2007 11:55 am, David Brownell wrote: > > I'm developing an SPI- bus >MMC/SD block driver translation layer. > > Another one? There's already been significant work in that area. See for > example > > http://marc.theaimsgroup.com/?l=linux-kernel&m=117000652529003&w=2 Nice, I'll build on that, my previous work ignored the SPI/MMC layers (because they didn't exist at the time) and just build a stacked driver on a character SPI driver. This gives me some direction as to how to proceed. > Which admittedly didn't behave when I just put it onto my test rig, > but seems nonetheless to be a significant step forward. It's not like > everyone has hardware that can use such a driver after all! True, but it's fairly common right now, until every microcontroller gets a hardware SD controller (which seems to be the trend) > That's how it's done in that patch. The model being what the PXA MMC/SD > card driver does, since that's the most generic model I found ... handling > for example systems which need to poll for card detect, as well as ones > that can use real gpio based IRQs. The mmc_spi driver doesn't need to know > which kind of platform it's got. Sounds good, thanks NZG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: passing function pointers through platform devices?
>http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4c20386c8d0719b42503efe65abe47ad3fb3d711 > Your mail seems to be about a gpio userspace interface, which is > something entirely different from an in-kernel API, Sort of, IMHO sysfs classes seems the logical final incarnation for user space access. But to get there it has to migrate down from the machine layer to something that declares it's mapping to the pins on a board. However, just like gpio.txt discusses I am using them to detect MMC insertion, so I needed standard way to declare the pin. This provides that, thank you. NZG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: passing function pointers through platform devices?
> The -mm patches are a set of patches, released by Andrew Morton, against > the official kernel series. They are frequently more experimental in nature > than the official series. These patches are available in Andrew's kernel > directory: Thank you for pointing this out, I will use at as another source for background work before beginning future projects. NZG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: passing function pointers through platform devices?
> Once the generic GPIO framework migrates upstream from -mm Thank you, but I've reorganized my system to pass platform resources to a driver, which then registers simple gpio/pwm/quadencoder type devices as standard classes declared in a subdirectory. Specific methods are then simple exported by stackable drivers. It's unlikely I will adopt the GPIO interface at this point unless they really bring something new to the table. I googled extensively and requested information on any current work here before I began this project and got zip. (see forwarded email paste) I also emailed Robert Schwebel directly and he told me to ask VGER as it was being developed by someone else. I don't mean to sound rude, but I really tried to build on existing work and it wasn't made available, so I've gone my own way, I had not other choice. P.S. Forgive my VGER newbness, but what is "-mm" ? thx, NZG > -- Forwarded Message -- > > Subject: GPIO device class driver > Date: Tuesday 20 February 2007 10:40 am > From: NZG <[EMAIL PROTECTED]> > To: Linux kernel mailing list > > I am currently developing support for an ep9xx based SBC and want to export > it's GPIO through sysfs in a simple and standard way, > without adding yet another platform specific gpio driver to the kernel. > > As I understand it, a gpio class has already been begun by Robert Schwebel > in but has not as of yet become part of the mainstream kernel. > > Searching the archives for this yields no results since 2006. > > Can anyone point me to a current patch? > I'd like to start from there. > > thank you, > NZG > > - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
passing function pointers through platform devices?
I'm developing an SPI- bus >MMC/SD block driver translation layer. As part of this layer the write protect and card detect lines need to be read. The method for determining the state of these lines will be board specific. Is it appropriate to pass a function pointer through a platform device (declared in the mach initialization) to implement card_available and write_protect function calls? Or is there a cleaner way to do it? thank you, NZG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
GPIO device class driver
I am currently developing support for an ep9xx based SBC and want to export it's GPIO through sysfs in a simple and standard way, without adding yet another platform specific gpio driver to the kernel. As I understand it, a gpio class has already been begun by Robert Schwebel in but has not as of yet become part of the mainstream kernel. Searching the archives for this yields no results since 2006. Can anyone point me to a current patch? I'd like to start from there. thank you, NZG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6VMM, uClinux, & Comedi
I'm running comedi-0.7.70, but the issue is seems be be coming from the fact that I'm using a nommu arch. grepping through my arch and include/asm, these symbols are indeed not defined. This makes sense because uClinux has no true virtual memory, vmalloc is just a wrapper for kmalloc. The implementation of these functions is probably trivial, but It's taking me a bit since I didn't really understand the VM code before (now I have a small inkling) I'll get there, I'm just surprised this hasn't been attempted before. NZG. On Tuesday 02 August 2005 08:27, Ian Abbott wrote: > On 01/08/05 14:17, NZG wrote: > > I managed to successfully cross-compile Comedi for the Coldfire uClinux > > 2.6, however it has several unresolved symbols when I try to load it. > > > > comedi: Unknown symbol pgd_offset_k > > comedi: Unknown symbol pmd_none > > comedi: Unknown symbol remap_page_range > > comedi: Unknown symbol pte_present > > comedi: Unknown symbol pte_offset_kernel > > comedi: Unknown symbol VMALLOC_VMADDR > > comedi: Unknown symbol pte_page > > It's probably coming to grief in Comedi's Linux compatibility headers > somewhere, but as this stuff has changed a few times, which version of > Comedi and which kernel version are you using exactly? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6VMM, uClinux, & Comedi
I managed to successfully cross-compile Comedi for the Coldfire uClinux 2.6, however it has several unresolved symbols when I try to load it. comedi: Unknown symbol pgd_offset_k comedi: Unknown symbol pmd_none comedi: Unknown symbol remap_page_range comedi: Unknown symbol pte_present comedi: Unknown symbol pte_offset_kernel comedi: Unknown symbol VMALLOC_VMADDR comedi: Unknown symbol pte_page Apparently uClinux isn't implementing these paged memory functions,which kind of makes sense, but I'm a little fuzzy on what the nommu code is supposed to be doing exactly, and I couldn't find any documentation on what these functions are doing in the vanilla 2.6 kernel. Has anyone else been down this road before? I found Mel Gorman's Thesis on the 2.4 mm functions, but I couldn't find most of these symbols in it. It's looking like the 2.6 mm stuff is still pretty undocumented, any links to documentation (or short text explanations)would be appreciated. thx. NZG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
