lkml.org 
[lkml]   [2007]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC, PATCH 0/4] SoC base drivers
    On Tue, May 01, 2007 at 08:08:06AM +0300, Paul Sokolovsky wrote:
    > Hello linux-kernel,
    >
    >
    > In contemporary systems, lots of functionality oftentimes handled by various
    > kinds of SoCs (system-on-chip), representing a number of deversified
    > controllers packaged in one chip. Handling them is arguably an ongoing
    > problem, as diversity and number of devices included make it hard to
    > come with maintainable and reusable solution for writing drivers. Common
    > examples are developing one monolithic driver for all internal devices, or
    > making one of device drivers export functions required by others, leading
    > to not very clean dependencies like touchscreen driver depending on
    > a sound one.
    >
    > Handhelds.org kernel project (dealing with Linux porting to consumer,
    > real-world embedded devices, and majority of our devices have different kinds
    > of SoCs) for few years developed a more clean approach to handling
    > SoCs - using the concept of "SoC base drivers". This is not the first time
    > we're submitting these patches, with reworking and elaborating them based on
    > the feedback received. We also extend supported machine base for these
    > drivers (for example, asic3_base driver in the following patches is used by
    > a dozen of machines).
    >
    > SoC base drivers - concept
    > --------------------------
    >
    > A SoC base driver is a special kind of driver which manages a SoC chip's
    > common and shared resources and functionality, and provides interfaces
    > for subdevice drivers to use. This in particukar solves "tangled
    > dependencies" issues mentioned above - different subdevices now depend
    > not on each other, but on a common foundation, forming a hierarchial
    > structure.
    >
    > Term "interfaces" is used intentionally, as besides offering an API adhoc
    > to specific SoC functionality, the intent is to reuse existing kernel
    > susbystems/interfaces as much as possible, essentially breaking tight
    > coupledness of subdevice drivers and base driver. For example, Generic
    > IRQ Subsystem is used to handle SoC interrupts, so subdevice drivers
    > just use existing generic API to request and free IRQs.
    >
    > More importantly, existing driver model is used to handle subdevices
    > of a SoC. For each subdevice, a standard struct device is allocated,
    > and LDM is used to handle driver binding and further lifecycle. So,
    > this is a special trair of SoC base drivers: these are the drivers
    > which register other devices (note that it is not a case of "legacy"
    > driver where single module registers both a device and a driver
    > serving it - SoC base driver registers other devices to be handled by
    > other driver, namely SoC individual subdevices and drivers for them).
    > 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.

    > There's a helper soc-core API to help SoC base drivers with common tasks,
    > like registering subdevices.
    >
    > The implementation and patches following is structured as follows:
    >
    > 1. include/linux/soc/ and drivers/soc/ directories are created to
    > keep namespaces clean (we have around 10 SoC base drivers now). Note
    > that these dirs are for base drivers only, subdevice drivers go to
    > one of standard dirs based on their functionality (for a example,
    > video driver goes to driver/video/).
    >
    > 2. soc-core.c, soc-core.h: helper API to calculate subdevice resources
    > and register them based on template definitions provided by SoC drivers.
    >
    > 3. asic3_base.c and associated headers: SoC base driver for HTC ASIC3,
    > a popular SoC for ARM-based handheld devices, currently known to be used
    > in 12 machines, including one machine which is already in mainline.
    >
    > 4. mach-3715.c: A patch for HP iPaq rx3715 machine, already in mainline,
    > to add ASIC3 support using asic3_base driver.
    >
    >
    > I would like to end this RFC with the fact that mainline of course
    > already contains drivers for non-CPU SoC chips. arch/arm/common/sa1111.c
    > and arch/arm/common/locomo.c are two examples from the ARM realm. This RFC
    > grows from this fact, and aims to provide consistent definition and
    > best prctices for handling such SoCs.
    >
    > Finally, in the beginning, term "reusability" is used, and this is not empty
    > word. Besides clean structural approach and improved source-level reusability
    > due to this, the approach proposed proved to offer immediate subdevice
    > driver reusability across different SoCs. One vivid example is ds1wm driver,
    > for a W1 bus controller. It was found that this controller is found in few
    > SoC chips used in consumer handhelds (at least ASIC3, SAMCOP, HAMCOP chips),
    > and immediately usable, as long as base drivers prepares IRQ resources and
    > clocks for it.

    --
    Ben

    Q: What's a light-year?
    A: One-third less calories than a regular year.

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

    \
     
     \ /
      Last update: 2007-05-01 11:19    [W:3.993 / U:0.416 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site