Message-ID: <609081207.20070501131108@gmail.com>
Date:	Tue, 1 May 2007 13:11:08 +0300
From:	Paul Sokolovsky <pmiscml@...il.com>
To:	Ben Dooks <ben-linux-arm@...ff.org>
CC:	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	<kernel-discuss@...dhelds.org>
Subject: Re: [RFC, PATCH 0/4] SoC base drivers

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:pmiscml@...il.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists