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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
