Re: [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 4:37 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: Hello, I've been spinning some work-in-progress patches for FIT build support in the kernel. With the move to multiplatform support on OMAP, I feel it is a good time to add FIT support, also looking at the proliferating number of dtbs, as it is a nice way I'm not looking to add yet another crappy uboot image format to the kernel just for the hell of uboot. And don't think that the dtbs in the kernel are going to stay there. The longer term plan is for them to end up in an external git tree, entirely separate from the kernel source. So anything that ties them with the kernel build process will ultimately have to be removed again. Sorry for hopping in late as I have been travelling. Guess much has been said, but for courtesy sake till dts/u-boot build support is dropped, would you consider accepting a simple extension to mkuboot.sh with minimal Kbuild changes? I can promise there will be quite a few users. Lots of folks want embedded device trees and there are already out of tree hacks floating as you know that do this. FIT approach to this is more cleaner I feel. Let me know what you can do. Thanks, Joel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Generic PHY Framework
On 02/19/2013 09:05:00 AM, Felipe Balbi wrote: Greg, can you pitch your suggestion here ? It would be great to hear your rationale behind dropping class infrastructure, couldn't find anything through Google and since feature-removal-schedule.txt has been removed (without adding it to feature-removal-schedule.txt, I must add :-) I don't know what's the idea behind removing classes. I actually went through and poked a couple of people about old entries in feature-removal-shedule.txt last year, but I haven't been very active since the kernel.org breakin because my account got disabled, and I needed to meet kernel developers in person to get keys signed to get it switched back on (or set up a separate git tree with signed commits -next could pull from). I don't get out much; as a consultant I have to take time off from work and pay for my own travel and lodging. So I've been to exactly two conferences in the past 3 years: last year's Texas Linux Fest (my house got broken into and a netbook with the key on it stolen the following wednesday), and CELF (which I'm on the plane back from now, Greg KH signed my key! Woo!). If I can use that to get my account back, set up a tree feeding into linux-next, and maybe even recover the ability to update http://kernel.org/doc, I'd happily field some sort of feature-removal-schedule list and make sure it stays current. (Linus didn't ask me about removing the old one, I found out about it from the git log. But I can't blame him, I haven't exactly been tearing through the bureaucracy to get my access back. Volunteer work and painful tend not to combine well on my todo list in terms of scheduling priority...) Rob-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] drivers: phy: add generic PHY framework
On 02/18/2013 11:53:14 PM, Kishon Vijay Abraham I wrote: The PHY framework provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. Given that this has a separately selectable config option, I'm guessing that it's useful all by itself even in the absence of a driver using this phy? (Or it gives user visibility to the phy buried in an E1000 or SATA drive or some such?) +1. Introduction + +*PHY* is the abbreviation for physical layer. It is used to connect a device +to the physical medium e.g., the USB controller has a PHY to provide functions +such as serialization, de-serialization, encoding, decoding and is responsible +for obtaining the required data transmission rate. Note that some USB +controller has PHY functionality embedded into it and others use an external +PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet, +SATA etc. I've usually heard the word transciever used to describe these. +The intention of creating this framework is to bring the phy drivers spread +all over the Linux kernel to drivers/phy to increase code re-use and to +increase code maintainability. + +This framework will be of use only to devices that uses external PHY (PHY +functionality is not embedded within the controller). + +2. Creating the PHY + +The PHY driver should create the PHY in order for other peripheral controllers +to make use of it. The PHY framework provides 2 APIs to create the PHY. Given that a PHY is a chip (random example http://ark.intel.com/products/47620/Intel-82579LM-Gigabit-Ethernet-PHY), you seem to be saying that software should manifest a piece of hardware out of thin air through sheer willpower. I'm pretty sure I've misunderstood this phrasing. +struct phy *phy_create(struct device *dev, struct phy_descriptor *desc); +struct phy *devm_phy_create(struct device *dev, struct phy_descriptor *desc); + +The PHY drivers can use one of the above 2 APIs to create the PHY by passing Um, the driver should _bind_ to the phy, maybe? Allocate? Initialize? +6. Destroying the PHY I've run drivers like that. I try not to, though. +7. Current Status + +Currently only USB in OMAP is made to use this framework. However using the +USB PHY library cannot be completely removed because it is intertwined with +OTG. Once we move OTG out of PHY completely, using the old PHY library can be +completely removed. SATA in OMAP will also more likely use this new framework +and we should have a patch for it soon. Does this paragraph belong in the documentation? (Git commit, sure, but I've seen a lot of stale paragraphs like these hang around a surprisingly long time.) Rob-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
