Hello Ben, Tuesday, May 1, 2007, 11:39:00 AM, you wrote:
> On Tue, May 01, 2007 at 08:08:06AM +0300, Paul Sokolovsky wrote: [] >> Initial implementation from few years ago registered per-SoC bus >> for the purpose of attaching subdevices, but during LKML reviews it >> was pointed out that there're no good reasons for that, as such bus >> does not have any special functionality attached, so now platform_bus >> is used instead, for good. >> >> For the most part, subdevices are allocated dynamically, and SoC >> base driver calculates/fixes up resources and parameters for them, >> to be suitable for specific configuration (for example, different >> base address of SoC). >> >> What exact functionality and API a SoC base driver provides depends >> largely on specific chip, there's no specific API a SoC driver should >> implement. Here is a list of common tasks the driver usually would do: >> >> 1. Access handling to the chip (serialization, locking, etc.) >> 2. Managing common chip resources: >> 2.1. Interrupts control, demultiplexing, etc. (using Generic IRQ subsystem) >> 2.2. GPIO handling (adhoc, while eagerly waiting for an extensible GPIO API, >> we posted our implementation at http://lkml.org/lkml/2007/4/10/299 ). >> 2.3. Clocks (Using Platform Clock API) >> 2.4. Other kinds of "enable" and "power" switches (in adhoc manner or >> (ab)using the Clocks API, and waiting for generalization of it). >> 3. Calculating properties and registerting subdevices. > Wow, platform devices with a new name. I don't see how any of this is > not handled by platfrom device. > GPIO devices could be handled by a new resource type of GPIO > > The only other item in the list which we do not yet have is a > form of the clock API which can be extended past the base CPU > clock implementation. > > Anything registering new IRQs could create sub platform devices > with the correct resources. Where did you see a new name? I specially mentioned that era of new names are gone. We talk about device drivers and platform devices, plain and straight. It's just a driver which does convenience operations for a group of platform_devices, and sure, all these convenience operations are well familiar to anyone in topic. How such drivers (SoC base ones) are still useful is also pretty obvious: first of all, they are there, like mentioned sa1111.c and locomo.c. This RFC just calls for recognition of them as a special class of drivers, instead of keeping them hoard arch dirs. As for registering subdevices by SoC driver, it should be also clear why that's useful: as was mentioned, we have 12 devices using ASIC3 now. Instead of polluting machine definitions with duplicate subdevices declarations, we declare a SoC chip devices in them, and let chip driver declare subdevices, handling other boring tasks, as resource munging, at the same time (like that bus_shift thing - some ASIC3 devices has 2 byte register spacing, some 4 (essentially attached to off-by-one address lines)). [] -- Best regards, Paul mailto:[EMAIL PROTECTED] - 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/