 and run out. So I'm Linus Ballet, or Balesh, or however you prefer to pronounce it, it's actually French. And I'm here presenting on behalf of S.T. Ericsson actually, but I'm also working for Linaro, which is my 100% assignment in S.T. Ericsson. And I'm presenting in the capacity of pin control subsystem maintainer and GPIO subsystem co-maintenor. The main maintainer of the GPIO subsystem is grant likely. And I wanted to give you an update on what we're doing in these subsystems over the last, say, two years. I said something like 24 months. And I give you, yeah, some pointers and directions on what to think about when doing this kind of stuff right now. So some things have changed and some are new and so on. So it will not be a, I won't just throw you in the middle of the GPIO and pin control soup. I will try to provide some background as I go along. Like this. So we need to define the first problem that people have with GPIO and pin control. They don't know which one is which and which one does what. So this is sort of a definition of it. In the beginnings of the subsystem, it was, of course, confused because we hadn't quite defined yet which one does what. But the GPIO is a one-bit signal that can be high or low. It doesn't have to be on a pin out of a package or something like that. It just has to be something that you can set high or low. It can be between two sections of an SOC or something like that. It's just something general purpose input output pin or signal or gate. It could be output only. It could be input only. But it can either drive a line high or low assert or de-assert, one-bit signal. Or it can read a signal as asserted or de-asserted. Whether it's asserted or not in a certain state depends on whether it's active low or active high. On a schematic, you usually see this that you put a dash above the symbol and it's active low. Actually, when we're talking about the GPIO in the kernel, they have very few electronic properties. We do have a concept of wire and so they can be open drain and open source. That's another open source. It doesn't mean what it usually does. These concepts are very electrical and relate to how you layout gates on your ship. We have also the bounce period, but that's all the electronic characteristics of GPIOs that we actually handle. Apart from that, we're only modeling something that is high or low and high is one and low is zero. It's quite simple. Then you may have IRQ ships connected to the GPIO lines. That's another business altogether. That's basically that you embed a struct IRQ ship into the same driver. It doesn't mean that this is actually part of the GPIO stuff. It's just something that's very close to it. The same driver C file may implement both a struct GPIO ship and a struct IRQ ship. That makes for some confusion. We're trying to make that a little bit simpler. Then the pin control subsystem, that's something else. That's pin multiplexing. That was how it began, allowing you reuse of the same pin for different things. Then it's pin configuration. This is where, if we could just turn back time, this is where we would put all the electrical stuff. Also open drain business and debounce periods and such things. Debounce is this effect when you push a key and mechanically it bounces on and off. If you sample it really quick, you will get a series of zeroes and debounce. You wait for a while and then you sample it in the end and you get the value for that key. Crystal clear. This is a picture from my previous presentation. I had another presentation one year ago, roughly, at the embedded Linux conference. That one tried to build the whole concept from the bottom up. I was discussing electronics and how you build up pin controllers and GPIO in hardware all the way up. Then I took the Linux abstractions at the end. This presentation, on the other hand, is more from the Linux point of view. If you're interested in the electronic stuff, then go check that presentation up or mail me about it and ask me where it is. Usually pins are these guys here or they can be called balls and they can be called pads. This is the pad ring of a ship. This is an IC right here. A GPIO could very well be right in the middle of here somewhere, conceptually speaking. Usually, in most cases, it's the same thing as one of these lines. These guys, these guys, these guys. This is what the electronics looks like. I'm not going to go very far into the details. This is more like a map of the world. This is supposed to be sort of blue, but it looks grayish here. Here, this gray stuff, output enable here, input enable, the IO pad itself, input and output. That's the GPIO parts of this line driver. All the ASIC manufacturers have this kind of things. There's a line driver block here and then you map it to different bits in the software. But that's all the other presentation. Anyway, the GPIO portions is this output enable, input enable, input and output signal. It all reaches that pad or there's a pin here. But it could very well be a connection over to another ship on the same package or something like that. It doesn't have to be a pin. And then there's always some output driver stage here. That's a regular amplifier, usually two MOS transistors stacked on top of each other. That's called a totem pole. And there's an input stage here, which is Schmidt trigger construction. It has some kind of hysteresis and sometimes it's software control. The gray stuff here is about the GPIO. The blue stuff here is supposed to be blue. That's about interrupts in IRQ generation. And the pink stuff, which here is a series of two maxes. And there's a pull up and pull down resistor. That's the pin control business. That's the map of the world in a simplified case. I'm not saying that the world is simple as that all the time, but it could be. The GPIO subsystem, it's in driver's GPIO. There is documentation. It's actually, we're trying to keep it up to date. There are a line near and typically these days non sparse numbers based from zero to N. And the consumers request such a GPIO line with optionally managed resources GPIO request. And they can be set as input or output. And they can be read as high or low. And they can be driven higher low, one and zero. Then they can be mapped to corresponding IRQs if that is supporting. Actually, it doesn't need to support both input and output even. It could be just an input or just an output. But optionally, they can be mapped to IRQs. And then they are inputs, right? Otherwise it won't work. And from that point on, that's the IRQ subsystem that's taking over. So we have a number of IRQ ships in the GPIO subsystem. And usually it's a driver with both parts. And they can, sadly, be exposed to user space with the CISFS. And we have lots of issues with that API. This is what the basic operation structure looks like. This is in the GPIO ship, by the way. This is the GPIO lib. There are still some systems and platforms that do not use GPIO lib. There are some who have completely custom implementation of GPIO. So they have some header file in mark something. And totally custom functions that they call. And then there's the compromise in between, which is generic GPIO. So they have implemented a set of operations, like GPIO request, put, get, enable. You can drive and read the output. The functions will have the same signature that you find in Linux GPIO.h. But it doesn't have this driver structure. That's the generic GPIO. That was invented in the dawn of time of GPIO in order to be able to implement very optimized, compile time-wise code to drive, especially BitBang GPIO off the ship. It's strongly discouraged to just use generic GPIO, i.e. implement the same functions everywhere. Because it will lead to the exact same problem that the clock subsystem is facing, that everybody is implementing the same set of functions with just slightly different semantics. And you can't compile several systems into the same image, of course, because then you will have several functions clashing in the same namespace. So that's a compile-time philosophy kind of thing that we need to get rid of. It should be refactored out. The problem for us doing it is that sometimes nobody's actually running the systems, or there are people in the worst case. There are lots of users of the system, but no developers. So we can't remove it because there are users, and we can't fix it because there are no developers who can actually test the hardware. So that's a bit frustrating. But you are strongly encouraged to use the GPIO lib. And with the GPIO lib comes the GPIO ship. And it has names and devices and so on. You can request lines here. You get, yeah, like you would expect from any specific device driver. Do you see something strange with this device? By the way, there is one big problem with it. It's not a device, right? That's just a pointer there, this star. It means that it hooks into a device, but it is not a device. A usual device structure in the Linux kernel has a structured device, no star here. Which means that it is a device. But this is not the device. It only has a relation to the device here, which is not good. That's one of the things that we need to fix about the GPIO subsystem. And then it uses this. Whenever you try to generate GPIOs or IRQs of your GPIOs. And then you can do all kind of stuff. This is designed for multi-core, big IRQ controllers on high-end servers and so on. So that's why you find a lot of functions here, most of which you don't use when you implement IRQ ship for a GPIO controller. Usually you just need mask and mask. Maybe some startup and enable, disable. These are not really needed either. You only need mask and mask. Maybe startup. Maybe shut down. Yeah, set type. You often want to set type. That's where you go in. For example, if you have a GPIO pin and sometimes you want to configure if it is to trigger on a rising edge or falling edge. You use set type. And set wake is also quite useful. That's for this thing here, right? The asynchronous edge detector here. Wake up enable and wake up signal. That's basically when you take the system down to sleep, everything is turned off. All clocks are turned off. So nothing is clocked in here. But if you have an asynchronous edge detector, you can still wake the thing up with a GPIO signal. That's one of these cool things that the electronics guys do. But when you're running it, sort of you're up and running and you want very quick and synchronous events to happen, you of course you will use the normal IRQ here on the synchronous edge detector. So it's timed with the clock of the system. Otherwise it will be totally unmanageable. So that's the GPIO subsystem and the IRQ ship subsystem. Now I'll tell you a little bit about what we've been doing on the GPIO subsystem the recent two years. This is one of the big things, the IRQ domain refactoring. And we introduced that in the summer of 2011 to translate hardware to Linux IRQs. The problem is that just as it says here that with the number of GPIO controllers going up in system and showing a rising tendency, you tend to want to connect the ever more IO to your SOCs and to your systems. We get expansion first of this hard-coded global GPIO number space that you somehow try to allocate in some header file with some defines and some conditional defines on that define and on the roof of that one in order to sort of line up all the GPIOs after each another in this global GPIO space, which is usually totally compile time. If you can also generate IRQs on all these lines, you get another set of such nasty defines to keep track of all the IRQ in the IRQ number space for the Linux IRQ number. And basically grants set down and looked at this and we discussed a little bit back and forth. And it's basically so that Linux has no need of IRQ number at all. This is like a user thing to keep track of the number of an IRQ. Linux only wants the descriptors, basically the IRQ descriptors. Then you might want a nice number to put in slash proc interrupts. That's a nice thing. But that number doesn't mean very much to Linux. It's just a number. And the problem is that with a rise in tendency, you try to sort of contain and control this number space and we have to get out of it somehow. So the IRQ domain is just basically a very small library or cross reference table that will convert the hardware IRQ number to a Linux IRQ number. And with a hardware IRQ number, I mean interrupt flag zero, one, two, et cetera up to N for this very interrupt controller. This very interrupt chip. On a GPIO expander with eight lines, all of which can be input, there is usually eight flags that you can read. And you can figure out which one triggered an interrupt. And that will usually then be cascaded of some other higher level IRQ controller all up to the IRQ root on the system. So you get the picture that's this one IRQ controller here in the middle of the sock or in the middle of CPU or something that's basically into the actual CPU that's usually just one IRQ line, right? So when that fires and the CPU goes into interrupt handling mode, it will start some code that will go to the associated interrupt controller, read some registers and figure out from the flags which of the interrupts on that controller caused the interrupt. And if that is a cascaded interrupt from a GPIO or whatever, it will have to go to that source, read another set of status registers, figure out which one of these caused the interrupt and then reference all the way back, figure out which Linux interrupt number is associated with that very interrupt and call any handlers eventually. In order to make that simpler, we introduced the IRQ domain. The IRQ domain makes it possible for you to write the driver so that you only need to think about here in my driver about that hardware interrupt number, 0, 1 up to 7 for this 8 bit controller. And then it will translate back for you into some Linux IRQ number, which is just an arbitrary number, basically. The problem with IRQ numbers is that people often lay them out so that they match one to one with the reference manual for the SoC or something like that. For example, Intel does this, so there's some Intel Center to do this. But when you're seeing interrupt number one in proc interrupts, that's just a number. It doesn't mean it has to be interrupt one on the closest interrupt controller that's closest to the CPU or something like that. But it's usually the case. But for Linux, it's just a number. So the IRQ domain makes it possible to write drivers where you only care about your specific offset, this number here. If you look at the change log, you will see that we changed a substantial number of GPIO controls to use that mechanism to translate a certain flag in a certain register for the GPIO controller into a global interrupt number in the Linux IRQ number space. Then another thing that's happening, this is partly merged now for V3.9, is the descriptory factoring. And it's driven by Alexander Kubov. And we had thoughts about doing this. The thing is that when you go into other resources that your consumers say, could be a device driver or something, resources that the device driver is claiming will be things like clocks, regulators, pins from the Ping Control Subsystem and GPIOs. They're all requested with some function underscore request. You all store them up with a pointer in some kind of struct with your state container. And they all are sort of opaque cookies. That's just something, you grab a handle of it. You don't have to know what's inside. This is called object encapsulation or something in programming. It's pretty nice. It makes it impossible to fiddle with things that you don't want to fiddle with. Not GPIOs. So GPIOs return a number. So it's some number that's supposedly opaque but not always treated as such. And that's not good. It should be a cookie like everything else. It's just a pointer. You can't dereference it. You can't make a mess of it. You have to operate on it with using search and accessor functions. Just like you do with clocks, you do clock enable, clock disable. You do regulator set voltage or something like that on something that you don't dereference and look into. GPIOs should be the same. But unfortunately, people have not always done that. By converting it to descriptors, which are opaque cookies, we can get rid of this irritating design pattern. But the most important thing is to get rid of this global GPIO number space. And that's important for the other thing I mentioned earlier, that you tend to stack up a lot of defines in your platform. They're all defined at compile time. If you compile several platforms into the same binary image, you will have to do something like roof the number of GPIOs so that I am sure that all the platforms I compile into this image will fit in this space. And it can be a lot of space. So we have started to move around the code to use such descriptors internally in the GPIO lib. And that's basically it. Much of the design and desire comes out to the IRQ number space with the problem that I just described, that interrupts are just numbers, they should be opaque as well. And in the standard transition period, we will have a possibility to map GPIOs to descriptors and vice versa back and forth. Just like we do with the IRQ domain, where we can map hardware IRQs to Linux IRQs. And some of the basic infrastructures in place. But then we have this little debate that is not resolved because Grant is the actual GPIO subsystem maintainer, he doesn't like error pointers usually from this request function or get function. We get something that might be a pointer or might be an error code. So you have to do something like this is our macro on it to figure out if this pointer is valid or not. And that's a dubious design pattern. I mean it's not exactly elegant. It's one way to do things in C that is easy to do in other languages but here you have to do things like casting. So the pointer is actually casted into unsigned long I think or assigned long and then if it's negative then yeah that's an error code. If it's negative in the beginning of the negative number space then it's an error code. If it's higher up then it's probably a pointer and so on. So we don't know how that's going to be solved. I had had an idea to talk to some toolchain people about whether we can actually tweak the compiler to annotate pointers or something like that. So it would be easier to use these macros and get compile time warnings if you don't check the return value or something like that. So we don't know actually how to resolve it. Right now we have to basically just review all the code and Grant doesn't like that. So I have to find our way about it about that. Then another thing that's been proposed for the GPIO subsystem is blocked GPIO requests. And this could be a kernel internal thing. Basically what it does is that it tries to deal with this problem that you need to toggle two values, GPIO values at the same time with an infinitesimal time delay between the two. Which is easy to do if it's just like an 8.16 or 32-bit register. If you write all the bits at the same time of course you can toggle all the lines at the same time. You can toggle all the 32 lines at the same time up and down like this. And people have done out of three hacks for this for different embedded systems. I think Jean-Christophe told me that they had something like this for the 1891 and I've heard about other things. Roland who's writing the patches here also has this for some system and so on. So this is driven by user needs. People really need to do this. The problem is just how to do it. Myself, I'm okay with it for kernel internal interface. So if I'm using some bit-banged ITC driver for example, I don't see any problem with using this kind of interface to get two lines that I can toggle at the same time so I can toggle the clock and the data line exactly at the same time. Obviously that's good to be able to do that. We won't be able for any bit-bang drivers to guarantee the width of pulses or anything like that. We'll only have like a minimal guarantee. The length of them can be anything but as Roland explained to me, the problem is not the length, the pulse, the problem is the time it switches. So that's something we can solve with this API. We can't create perfect waveforms or anything like that. We won't be able to do that without hard real-time patches but we can make sure that that two lines toggle at the same time. So this is going to be merged I guess in some form. The biggest problem is with the user space API, ABI, which is in SysFS because Roland wants to use this from user space because they have some display array or something like that. Basically that's unpleasant for the maintainer of the subsystem because if we put the user space API in place we have to maintain it perpetually. And if we break it willingly because we say that this is not elegant, we want another user space API. There's some guy called Torvalst that's going to hit us on the head so hard. So you know it's not going to happen. We can't put the API API in place that we're not able to maintain perpetually. I mean he has claimed so many people for this kind of stuff so we're not going to be another one in the line of people doing that. So okay if we can come up with an interface that we really love, actually I don't like any of the SysFS ABI because they are racy and strange and basically I would like to transfer the whole thing over to a proper device or something like that character device. But then I have to do it myself so we'll see about it. But that's being discussed right now. And I guess that for the internal API we're definitely going to merge it. Then what's going to happen next in the GPIO sub system. Yeah we will get this descriptor API in place. Then we will have to go in and all the drivers will have to include a file called Linux slash GPIOD on both days or something like that. And do real requests of things, reference their GPIOs from the devices, a couple the resources so that GPIOs are tied to their devices in the device model, which is nice. Then this SysFS K objects, if you've looked at this code what it actually does, what the GPIO sub system does to get handles in SysFS for all the GPIO things is that it creates a dummy device. So it just cause create device and then attach the SysFS files to it. It doesn't mean that it attaches the SysFS files to the actual GPIO control because it has exactly that problem that I pointed out before. It's not really a device. So that needs to be fixed obviously. You should tie this kind of things to the actual device and the GPIO chip should contain real structure device. That needs to be fixed. Then we need to think about the future user space API. Input is well come. Send mail to the mailing list. Then I have the same kind of two bullets for IRQ, chip, GPIO and pin control because when you get the picture like that when you're involving three different subsystems for the same hardware like this. Do you think it's easy? Can I make this easier to use? Of course I mean this is complex stuff. It's not simple. It's not like going to shop groceries or anything like that. But maybe we can do things in the subsystem structure that makes it easier to create IRQ chips and pin control coupled in deeply with the GPIOs. Maybe. I don't know. I don't see any simple way to do this. Maybe we can always supply an IRQ chip on a GPIO controller for example. Or will people think that that's like footprint wastage? Then GPIO hogs is another thing that came up on the mailing list. So some systems will have a number of GPIOs that they just set up as inputs or outputs when they boot. Sometimes to read an ID number that's hard coded with some straps on the inputs and sometimes to just drive some lines that power some Ethernet adapter or something like that. When we were just using board files for all the arm stuff that was quite simple. You would just write some code and then hard coded GPIO number and just get requested and put it to one. That's not exactly elegant in the context of device trees and such things. So we need to come up with some mechanism that you can do this kind of stuff without needing special board code. Or you can duplicate it with just scanning you know the device tree nodes and manually or machine wise pick them out and raise them to one. Which I have done myself. But maybe it's not that elegant. GPIO hogs would be a better way so that the GPIO subsystem would take these at boot and read out the proper values from the device tree and then sort of set them to zero one or read them or something. Okay that's GPIO. The pin control subsystem on the other hand. We done any questions on GPIO? I think we've got lots of times if you've got something to ask. Okay let's go into pin control as well and then we will get the big picture. Pin control subsystem lives there. I have a documentation file for it. It's updated. Am I talking in a monotone voice that make you sleepy? Or is it just because you just had dinner? It's a silent. I'm sorry. I would blame it on my sort of cold or influenza or whatever it is. Drivers employing pin control. They can control pins in a controlled way. Now they will help you when you're multiplexing stuff for example and when you're cross-referencing pins to the GPIO subsystem and they will also handle like a configuration of different electrical properties just like I mentioned. Pull up pull up pull down drive strength and such things. And we have hogs like I mentioned for the GPIO subsystem. We have hogs so that you can sort of hog a certain configuration or a state as we call it and enable it on boot so you don't have to deal with it from the somewhere else from the drivers for example. But the signature of the functions are very familiar. You get pin control handles you enable them you disable them you put them but we have replaced it with states for the intermediate term. So it's the pink stuff here. Maxis pull up pull down. Hysteresis control could be for example here I said that this is usually like two MOS transistors on top of each other in a totem pole. If you add another pair you have double drive strength through that totem pole right you can drive it with twice as many microamps or milliamps. It's typically something like three milliamps per driver stage. So if you enable several driver stages and that is software control it's a pin control thing. The basic API looks like that. That's not very much here because all the details are in here which is another set of ops so that's a box you open and there's another box inside it's like a matryoshka doll this Russian thing. But when you register such a thing you will get the real structure device. It contains a real structure device. The pin control. And it lists groups and so on. That's not very clear. It was invented in a response to the churn in the arm architecture. If you were to all of all of the session this morning you got to know about this you know Linus Torvald's rant about the state of the arm subsystem. One way to solve it is to take drivers out of arc arm and one place to take them is to the drivers pin control subsystem. If they are pin controllers. And it actually in the beginning I tried to move all this stuff to the GPIO subsystem so I wanted grants to export GPIO to ship. So that I would be able to add a lot of custom functions to all of my drivers. My GPIO drivers for example NMK for nomadic pull up. Come on just a little function. Add it. But in order to add it I need to sort of read the reference the GPIO number that I wanted to pull up so I could get out the struck GPIO ship so I could get to the memory range where it was sort of implemented. So Grant can you let me have it GPIO to ship so I can just sort of you know dereference the GPIO number so I can get out the GPIO ship struck so I can sort of implement pull up pull down all that stuff with custom enumerators and he said no you're not going to have it and as I say ironically it's exported now but for different reasons. But the idea is we do not expand the GPIO subsystem with all this stuff and the main reason for not doing that in why why is not everything handled by one subsystem it's the main reason is that GPIO has a global number space and the global number space totally sucks for device trees because they want to assign resources dynamically. And now we have the pin control subsystem which is totally dynamic it can handle no dynamic pin controllers coming and going and assigning some random pins and so on naming them and denumerating them and interacting with them. But then I also have the old GPIO subsystem and I have to live with it so that's why we have this cross-reference mechanism that's called GPIO ranges. I suggested this in 2011 and iterated and iterated and then it was merged for kernel 3.2 with support for legacy controller the U300 but basically I used it as a guinea pig and then the surf primer 2 was the second one. In the kernel 3.4 which was a year ago also we introduced pin configuration states and we refactured the API so that you get a struct pin control handle with pin control get and then you have to get named states out of that pin control handle in order to be able to switch your handle into different states so it's not just enable disable anymore like with a regulator or it's more like set voltage so that you can actually go with your pins into different states and the states contain for your specific handle both max settings and different configuration settings for the electrical properties of these pins. Any questions? I'm just making fun of you so it's like yeah you can look at the map ask your question while they look at the map I think that actually the if you don't support it in hardware now I'm just I'm just reciting from memory if you don't support it in hardware there is a callback which you can make in your driver to support it in hardware if that is not available if that callback is null the subsystem will employ that with a timer it will set it will just you know delay and then read I haven't thought of that I never had the request before so we have debounds but but that's as far as it goes so maybe I mean in the pin configuration API down here we set a number of properties which are just enumerated things in that you can configure the hardware for the pins for so if it has some bits in a register which you can write to set something up which is related to anything electrical it goes down here so definitely if your hardware supports latching that's a pin control business whether to fall back to software when that's not available that's another thing maybe I don't know if that's the proper division of things the the the pin control subsystem doesn't pull anything it's just the GPIO subsystem doing that so maybe it's right to have the you know debounds and such things up in GPIO I don't know or maybe it needs to be adapter on top of the GPIO subsystem but I mean this this is a rough map of the GPIO subsystem this is where your driver go in and take a pin control handle it could actually be taken by the subsystem itself through a so-called hog subsystem may have several such hogs for different things then it's it maps functions which is basically that I have a UART to groups which is actually I have like these five pins and they can actually be the UART so one such function may have several such pin sets and the pins all have names so you can put them into such groups that can be connected to a certain function and then they will have this bolt on GPIO range thing to cross-reference GPIOs from the global number space and then the GPIO subsystem may want to set the direction of a certain pin and that's best employed by the pin control subsystem so they set input and output down here and you can sort of otherwise it's just request and freedom and then this will be like a back end to the GPIO subsystem this is a explicitly a back end and the configuration stuff goes down on down here it's all related to pins and could also be groups because in some hardware you can set electrical properties for an entire group of pins and it's just like the functions to group mappings it has a one-to-many relation to the handle you have up here so now you realize that you can just you can just get your handle here and then you look up a state and then you have fun with it and then all this stuff goes on in the background did you learn this way of writing for sort of sketching things in engineering classes was it any fun I think it's actually better to read a code I mean it is but but it gives you one little piece at the time or you can take that map and you can sort of bring it up on Christmas Eve or whenever you're really bored and just look at the code and cross-reference the map but all of these systems have actually so so pink control is a huge success I mean it's massive success one of the best the most successful things we did with the with the narrow because we brought over not only my pet system so you don't care very much about them but also the surf prima to the Nvidia Tegra serious the Marvell things Tomas did and yeah including Armada including legacy systems like the Kirkwood and the dove free scale was brought over by Sean go and oh I forgot this other the gentleman that's working on it but a lot three different people at free scale contributed to this as the microelectronic spear which is set up box machine I think Sean Christof converted the 1891 Samsung by Thomas Abraham Exynos the new platform the old legacy platforms Samsung's are not converted yet but we're getting that oh five minutes wow the Broadcom was converted then Tony down here has created the single one which is an abstract variant for all maps and which now also going to be employed by High Silicon rights that's the name the the Huawei guys and we have also two non-arm architectures which is especially fun to see we have the MIPS lentic folk on x-way and super H things that are not SH mobile of course the arm SH mobile is being converted by Laurent Pinschard and the next on the hit list or wish list or whatever you want to call this the old samsung's the old omaps the Da Vinci EP 93X and the the Qualcomm MMSN platforms I am convinced I will get them in there sooner or later next we will have yeah these things are going in I sent a pull request to Linus Torvalds this morning grabbing of default handles from the device core we realized that a lot of devices would just get ping control get enable default so I would look at my default state and enable that and I wouldn't touch the game the meter it all of those subsystem maintainer for the input subsystem didn't like that kind of boilerplate to be added everywhere so we discussed it back and forth with some gentlemen like Mark Brown and Greg Crow Hartman and we actually put it into the device core so the device core will look it up and enable it for you there are some like probe deferral things to think about there but basically works then we have added sleeping hogs so even if you take all your ping control handles with hogs they will be put into sleep state when if there's a sleep state defined when you go to sleep so it's a it this is the subsystem implements suspend or assume for you if you're using hog and we have a PCI driver on its way in we have thoughts about making this business easier it's not easy as long as the GPIO is using a global number space but I added a function which is like GPIO ship add range mapping or whatever I call it that's at least sort of only look using the local GPIO numbers to cross reference and that make making it a little bit simpler we should make the generic portions of ping config more generic I think how Jan is adding it to the single variant for example and we might the way we have solved the vice tree bindings right now is just sort of put in a function and let you do it the way you want in your driver just creates my pin control map for me it's not entirely helpful not to have standardized device rebounded bindings we need to think about that and maybe we want to pin controller to be able to model an entire GPIO ship and maybe the IRQ ship as well as I said maybe I can provide some helper PM in lines because because this code tends to be duplicated everywhere maybe we need to use them from user space preferably not but people always come up with that kind of stuff hey I'm fine any questions