Re: A new Subsystem for Current Management
Hi, On Tue, Nov 08, 2011 at 04:39:17PM +0530, R, Durgadoss wrote: > [Very Sorry for the Big Email] > > [I have posted this on lm-sensors and platform-drivers-x86 > lists earlier. As per some recommendations there, posting it > here] > > As we all know, Linux is increasingly being used in handhelds. > The Hardware that supports the handhelds is also becoming > Performance-centric. With this, we need a way to efficiently > monitor the current consumption of the platform and take actions > when the platform draws more current, than it should. > > Where this can happen ? > --- > In a handheld, there are many components that demand high > Current. For example, Camera Flash, Video Streaming, 3G Voice > Call etc. Typically, two or more of these components are used > simultaneously in a real-time scenario. When this happens, the > current draw of the platform surges. If this surge lasts for > more than a specific time, it could crash the platform irrecoverably. > > How do we tackle this ? > --- > In Intel Medfield (Atom based) platform we had a driver that > Configures the current limits. When the platform current draws > more current than the programmed limit, the hardware generates > interrupt. The driver receives this interrupt and notifies the > user space to take appropriate actions. > The patch and the subsequent discussions can be found here: > http://comments.gmane.org/gmane.linux.drivers.platform.x86.devel/1197 > > To Generalize: > -- > With many more platforms to come, having a separate driver for each > results in heavy code duplication. Also, there arises a problem of > where to put these kind of drivers ? Hence I propose the idea of having > a Current Management subsystem. > > This will provide a generic ABI, API, so that the platform specific > drivers can register with this framework (and thus avail the basic > needs) and handle the events in their own way. > > In simple terms, this framework will offer something like this: > Current[1-N]_limit - set of current limits > Voltage[1-X]_limit - set of voltage limits > Controllers[1-Y]_enable - These are the components by throttling/ > disabling which the current consumption can be brought down. > > With the Controllers we can follow two approaches: > A) Each component driver registers with the current framework and gets > notified when the current surge happens. On receiving the notification, > it throttles its performance. There will be a follow-up notification, > indicating that 'we are out of the high current' situation; so that > the component resumes to operation at its full performance. > > B) The Current framework forwards the notification to the upper > layers and lets them decide what to do. > > I agree that A) bloats the size of all the component drivers a bit, > but considering the fact that the surge has to be brought down as > soon as possible (and the delay in reacting to the event if we > pass it to the upper layers) I am inclined towards A). > > I would like to see the opinion of the community on this entire > stuff, before I start writing some code. looks like this should be done on hwmon ? -- balbi signature.asc Description: Digital signature
Re: omap udc driver problem with beagle board
On Mon, May 31, 2010 at 09:06:35AM +0200, ext Marco Stornelli wrote: Oops, my fault. I see the error in the configuration. Thank you very much for your response. I'll try again. no problem. -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap udc driver problem with beagle board
On Sun, May 30, 2010 at 11:53:49AM +0200, Marco Stornelli wrote: > Hi, > > I'm using the kernel 2.6.34 with the beagle board rev. c4. I have got > some problems with the ethernet gadget to use nfs over usb. The problem > is with the usb. When the g_ether driver register itself, the omap udc > driver returns ENODEV because the kernel didn't call the probe for > this driver. Looking at the code, it seems the problem is in board > specific management of the usb. There isn't the registration of the > platform device to match the omap udc platform driver. It should be done > in the omap_usb_init() but in case of beagle board this function is > never called, so omap udc driver cannot work. Is it a regression? Is > there any workaround? beagle board uses musb. You shouldn't be relying on the udc controller. Your Kconfig is just wrong. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Libmtp-discuss] [RFC/PATCH 0/2] u_char.c and mtp.c patches
Hi, On Fri, Apr 23, 2010 at 03:02:31PM +0200, ext pouly amaury wrote: Those two patents may apply: System and method to specify extended configuration descriptor information in USB devices System and method to specify device specific user interface information in the firmware of a USB device exactly, those are the ones. Thanks a lot for finding that out. -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
On Tue, Apr 20, 2010 at 12:44:51AM +0200, ext Greg KH wrote: If you know the patent numbers, please send them to me. There are very simple methods of routing around patents. Also, the USB-IF is very interested in patents that cover USB related things, as they could possibly violate the USB-IF agreement that companies are forced to sign to join it. you might have better contacts than I do. Last time I contacted them regarding MS problems - at that time, I was complaining that Windows doesn't fetch all config descriptors - they replied that "other devices have passed USB Certification, so why can't you?" It's too bad when the Specification authority doesn't want to hear about mis-implementations of their own specification. Anyways... Take a look here: http://www.microsoft.com/whdc/connect/usb/os_desc.mspx it doesn't say the patent number but it does say that "Microsoft agrees to grant a nonexclusive, royalty-free, world-wide license under these copyrights, patents or applications solely to implement the Microsoft OS Descriptor Specification to interface with (i) a Microsoft OS Descriptor enabled operating system or (ii) other systems authorized by Microsoft to retrieve and use this information, on condition that you agree not to assert any intellectual property rights against Microsoft or other companies for their implementation of the Specification." We just need to check whether Linux falls into the "other systems authorized by Microsoft" category. I would guess not :-p -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
On Mon, Apr 19, 2010 at 11:03:24PM +0200, ext Steve Calfee wrote: Also have you found a device that actually responds to the "get osdescriptor" request? any mtp device pre-USB-IF spec will do it. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
On Mon, Apr 19, 2010 at 09:23:46PM +0200, ext Linus Walleij wrote: ...so I read you like it's not going to be supported with the proposed solution? I think that if you want you gadget to work with older Windowses, you simply have to support this. if you're willing to pay the Royalty fees, let me know :-p seriously, we just can't support it. AFAICT, M$ has patents over the OS Descriptor thingy (I could wrong though) and we don't want to give linux foundation a law suit, do we ? :-) There's no simple way to support old windows OSes. We could provide another .inf file on the kernel source for that at least. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
On Mon, Apr 19, 2010 at 08:57:18PM +0200, ext Michał Nazarewicz wrote: On Mon, Apr 19, 2010 at 06:55:53PM +0200, Michał Nazarewicz wrote: On related news, I've just posted FunctionFS driver. :) It's still imperfect but appears to be working. On Mon, Apr 19, 2010 at 07:15:34PM +0200, ext Greg KH wrote: Yes, that should solve the gadgetfs issue for you, right Felipe? On Mon, 19 Apr 2010 19:24:04 +0200, Felipe Balbi wrote: sure it should. Will take a look at it :-) As I've said it's still imperfect. In particular the throughput won't be impressive but that's on the TODO list (I first want to put a real driver yeah, I saw that you allocate the memory whenever you get read()/write(). That's a good choice IMO. It would be nice if you would have a vmalloc()ed kfifo instead and use that a ring buffer. Then you unload in smaller chunks. on top of FunctionFS before optimising the code) and in particular u_char seem to be a good piece to steal code from. ;) Still, as said, I haven't analysed possible optimisations just yet. go for it :-) It's free software anyways :-D -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
On Mon, Apr 19, 2010 at 07:15:34PM +0200, ext Greg KH wrote: On Mon, Apr 19, 2010 at 06:55:53PM +0200, Michał Nazarewicz wrote: > On Mon, Apr 19, 2010 at 06:10:52PM +0200, ext Linus Walleij wrote: >> Further comments: there is apparently a driver floating around this list >> for supporting PTP through the gadgetfs. How does this work relate >> to that, and why can't you use gadgetfs? On Mon, 19 Apr 2010 18:26:11 +0200, Felipe Balbi wrote: > dude, can't you read ? gadgetfs prevents us from combining into a > composite gadget. We went throught that already. Please follow the > thread before commenting. On related news, I've just posted FunctionFS driver. :) It's still imperfect but appears to be working. Yes, that should solve the gadgetfs issue for you, right Felipe? sure it should. Will take a look at it :-) -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
On Mon, Apr 19, 2010 at 06:10:52PM +0200, ext Linus Walleij wrote: 2010/4/18 Linus Walleij : The following two patches are RFC because we still have a few open questions regarding them. Further comments: there is apparently a driver floating around this list for supporting PTP through the gadgetfs. How does this work relate to that, and why can't you use gadgetfs? dude, can't you read ? gadgetfs prevents us from combining into a composite gadget. We went throught that already. Please follow the thread before commenting. Second: after looking at this, I think that atleast the part of functionality called "OS descriptor" should be in the kernel and not in userspace, is the OS descriptor the reason to why you want to expose EP0 to userspace, or are you using this for other things in the MTP stack? OS descriptor is MS specific crap, it's not on the USB-IF mtp spec and most like MS has some patent on that. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
