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.
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.
--
Best regards,
Paul mailto:[email protected]
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.
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]
On Tue, 2007-05-01 at 09:39 +0100, Ben Dooks wrote:
>
> Wow, platform devices with a new name. I don't see how any of this is
> not handled by platfrom device.
No, not so. That was a criticism levelled at a previous incarnation of
this code which has since been addressed - this is now a convienience
layer on top of platform device, as opposed to what it used to be - a
complete device class of its own.
It eliminates a _lot_ of code duplication for hh.org, where we have
multiple machines with multiple CPU types all sharing multiple SoC chips
which have varying subsets of decices in them (eg. the TMIO SoCs share
MMC blocks with the ASIC3 ones, w1 is shared in a few devices, etc.)
> Anything registering new IRQs could create sub platform devices
> with the correct resources.
Which is exactly what this code does, but without requiring each and
every platform to rewrite the same glue code over and over.
Hi Paul,
Paul Sokolovsky wrote:
> 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.
I think your referring to the term "SoC (system-on-chip)" is confusing
(at least for me). You rather consider companion chips than SoCs.
Yes, any chip integrating a number of controllers could be considered
as a system-on-chip but if the chip doesn't make sense without
some master chip (processor) I'd consider the chip as a companion
(to the processor) chip.
Regards,
Dmitry
Hello Dmitry,
Tuesday, May 1, 2007, 4:53:09 PM, you wrote:
> Hi Paul,
> Paul Sokolovsky wrote:
>> 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.
> I think your referring to the term "SoC (system-on-chip)" is confusing
> (at least for me). You rather consider companion chips than SoCs.
> Yes, any chip integrating a number of controllers could be considered
> as a system-on-chip but if the chip doesn't make sense without
> some master chip (processor) I'd consider the chip as a companion
> (to the processor) chip.
Ditto for me - I find "companion" thing confusing. What's
important for the RFC/topic discussed is that it is integrated
controller with many diversified functions, not what it is helper to
something. I understand that for many people SoC means CPU with ties,
but IMHO, it's less stretch to take such chip, remove CPU, and still
call it a SoC, than call an integrated audio/touchscreen controller a
companion chip (well, of course it is; and RAM chip too ;-) ).
Either way, I don't pledge to be a HW designer with
contemporary lexicon. The aim was simple - as a single word would be
too ambiguous, general, or vice-versa, omitting, then acronym is
needed, hopefully existing, and not new, and SoC is the most fitting
TLA, IMHO. But I'm open to specific suggestions for improvement. For
example, if I was to write a Documentation/ entry for that, I'd mention
companion chips, peripheral/integrated controllers, etc. But renaming
drivers/soc/ to drivers/companion/ would be more confusing, as the
concept described is not tied to companion chips per se (even though
many of chips we (handhelds.org) deal with, can be classified as
such).
> Regards,
> Dmitry
--
Best regards,
Paul mailto:[email protected]
On Tue, 2007-05-01 at 17:36 +0300, Paul Sokolovsky wrote:
> Either way, I don't pledge to be a HW designer with
> contemporary lexicon. The aim was simple - as a single word would be
> too ambiguous, general, or vice-versa, omitting, then acronym is
> needed, hopefully existing, and not new, and SoC is the most fitting
> TLA, IMHO. But I'm open to specific suggestions for improvement. For
> example, if I was to write a Documentation/ entry for that, I'd mention
> companion chips, peripheral/integrated controllers, etc. But renaming
> drivers/soc/ to drivers/companion/ would be more confusing, as the
> concept described is not tied to companion chips per se (even though
> many of chips we (handhelds.org) deal with, can be classified as
> such).
A while back I proposed drivers/mfd/ (multi function devices) and there
are a couple of drivers in there in mainline which probably fit your
description of SoC. The code I had once intended for there is probably
more ASoC related now...
Richard
On Tue, 2007-05-01 at 17:53 +0400, Dmitry Krivoschekov wrote:
> Hi Paul,
> I think your referring to the term "SoC (system-on-chip)" is confusing
> (at least for me). You rather consider companion chips than SoCs.
A 'System' does not imply a CPU. A 'Computer System' would but the word
system itself doesnt even imply electronic.
Paul Sokolovsky wrote:
> Hello Dmitry,
>
> Tuesday, May 1, 2007, 4:53:09 PM, you wrote:
>
>> I think your referring to the term "SoC (system-on-chip)" is confusing
>> (at least for me). You rather consider companion chips than SoCs.
>
>> Yes, any chip integrating a number of controllers could be considered
>> as a system-on-chip but if the chip doesn't make sense without
>> some master chip (processor) I'd consider the chip as a companion
>> (to the processor) chip.
>
> Ditto for me - I find "companion" thing confusing. What's
> important for the RFC/topic discussed is that it is integrated
> controller with many diversified functions, not what it is helper to
> something.
It's exactly helper. It helps to expand functionality of a main
processor.
> I understand that for many people SoC means CPU with ties,
> but IMHO, it's less stretch to take such chip, remove CPU, and still
> call it a SoC,
I do not know any chip that would be "just add a CPU and you'll get
a complete system", do you?
> than call an integrated audio/touchscreen controller a
> companion chip (well, of course it is; and RAM chip too ;-) ).
>
> Either way, I don't pledge to be a HW designer with
> contemporary lexicon. The aim was simple - as a single word would be
> too ambiguous, general, or vice-versa, omitting, then acronym is
> needed, hopefully existing, and not new, and SoC is the most fitting
> TLA, IMHO.
If you used ASIC acronym it would be more appropriate and not so
ambiguous.
What kind of chips you deal with does not fit ASIC acronym?
> But I'm open to specific suggestions for improvement. For
> example, if I was to write a Documentation/ entry for that, I'd mention
> companion chips, peripheral/integrated controllers, etc.
"peripheral/integrated controllers" are also within companion chips.
Every type of CMOS devices may be a part of processor chip or
may be a standalone chip as well as a group of CMOS devices
may be a part of the proc chip or may organize a standalone chip.
When your chip is missing a processor device then it is not
a system but a part of a system, you can not build a complete
system on a such chip, so you can not call it a "system-on-chip".
> But renaming
> drivers/soc/ to drivers/companion/ would be more confusing,
Not for me.
> as the
> concept described is not tied to companion chips per se (even though
> many of chips we (handhelds.org) deal with, can be classified as
> such).
>
>
Regards,
Dmitry
ian wrote:
> On Tue, 2007-05-01 at 17:53 +0400, Dmitry Krivoschekov wrote:
>> Hi Paul,
>
>> I think your referring to the term "SoC (system-on-chip)" is confusing
>> (at least for me). You rather consider companion chips than SoCs.
>
> A 'System' does not imply a CPU. A 'Computer System' would but the word
> system itself doesnt even imply electronic.
>
>
A "system" means something complete. Yes I agree it doesn't imply a CPU,
but acronym SoC traditionally imply something different than you propose.
Adding another meaning for SoC will confuse people because they will have
to distinguish if it is a processor or just a slave IC.
Thanks,
Dmitry
Thanks,
Dmitry
Hello Dmitry,
Tuesday, May 1, 2007, 7:38:44 PM, you wrote:
> ian wrote:
>> On Tue, 2007-05-01 at 17:53 +0400, Dmitry Krivoschekov wrote:
>>> Hi Paul,
>>
>>> I think your referring to the term "SoC (system-on-chip)" is confusing
>>> (at least for me). You rather consider companion chips than SoCs.
>>
>> A 'System' does not imply a CPU. A 'Computer System' would but the word
>> system itself doesnt even imply electronic.
>>
>>
> A "system" means something complete. Yes I agree it doesn't imply a CPU,
> but acronym SoC traditionally imply something different than you propose.
> Adding another meaning for SoC will confuse people because they will have
> to distinguish if it is a processor or just a slave IC.
I'm afraid we'd just have ontological argument unless tried to
bring in some references. But wikipedia does agree with you,
http://en.wikipedia.org/wiki/System-on-a-chip . So, well, down with
redefining SoC then. But "companion" is still too narrow and buzzwordy,
so let's explore Richard Purdie suggestion (in the other mail).
> Thanks,
> Dmitry
--
Best regards,
Paul mailto:[email protected]
Hello Richard,
Tuesday, May 1, 2007, 6:01:15 PM, you wrote:
> On Tue, 2007-05-01 at 17:36 +0300, Paul Sokolovsky wrote:
>> Either way, I don't pledge to be a HW designer with
>> contemporary lexicon. The aim was simple - as a single word would be
>> too ambiguous, general, or vice-versa, omitting, then acronym is
>> needed, hopefully existing, and not new, and SoC is the most fitting
>> TLA, IMHO. But I'm open to specific suggestions for improvement. For
>> example, if I was to write a Documentation/ entry for that, I'd mention
>> companion chips, peripheral/integrated controllers, etc. But renaming
>> drivers/soc/ to drivers/companion/ would be more confusing, as the
>> concept described is not tied to companion chips per se (even though
>> many of chips we (handhelds.org) deal with, can be classified as
>> such).
> A while back I proposed drivers/mfd/ (multi function devices) and there
> are a couple of drivers in there in mainline which probably fit your
> description of SoC. The code I had once intended for there is probably
> more ASoC related now...
Well, while description catches the essence of course, TLA is
far from being perfect: 1) Completely unknown; 2) can be easily
confused with mtd.
But it's even more funny: there *is* drivers/mfd/ already in
mainline. I'd say that we were blind, but even you say "proposed", not
"exists", nor anybody else brought that to attention. I'm afraid, that
proves point 1 above ;-).
Well, now that it's there, we have little choice but use it, so
we'll move our stuff there.
Thanks everyone for hints!
> Richard
--
Best regards,
Paul mailto:[email protected]
On Tue, 2007-05-01 at 20:29 +0400, Dmitry Krivoschekov wrote:
> If you used ASIC acronym it would be more appropriate and not so
> ambiguous.
Actually, thats not bad. I'd be ok with that is SoC isnt used.
On Tue, 2007-05-01 at 20:18 +0300, Paul Sokolovsky wrote:
> Tuesday, May 1, 2007, 6:01:15 PM, you wrote:
> > A while back I proposed drivers/mfd/ (multi function devices) and there
> > are a couple of drivers in there in mainline which probably fit your
> > description of SoC. The code I had once intended for there is probably
> > more ASoC related now...
>
> Well, while description catches the essence of course, TLA is
> far from being perfect: 1) Completely unknown; 2) can be easily
> confused with mtd.
>
> But it's even more funny: there *is* drivers/mfd/ already in
> mainline. I'd say that we were blind, but even you say "proposed", not
> "exists", nor anybody else brought that to attention. I'm afraid, that
> proves point 1 above ;-).
"there are a couple of drivers in there in mainline" implies I knew of
its existence ;-).
As for your second point, most users will just see "Multi Function" or
"Memory Technology" which should be different enough.
Cheers,
Richard
ian wrote:
> On Tue, 2007-05-01 at 20:29 +0400, Dmitry Krivoschekov wrote:
>> If you used ASIC acronym it would be more appropriate and not so
>> ambiguous.
>
> Actually, thats not bad. I'd be ok with that is SoC isnt used.
>
I'm ok with that too, i.e. very rough definition is:
SoC (system-on-chip) is a platform level chip which incorporates processor
devices (CPU, cache, coprocessors, memory controller etc.), system devices
(timers, interrupt controllers etc.) and peripheral devices
(UARTs, LCD controllers, USB controllers etc),
while ASIC (Application-specific integrated circuit) is also a platform
level
chip which incorporates peripheral and system devices but does not include
processor devices. ASICs are designed to expand processor functionality,
it could supplement a normal processor (non-SoC) and also could supplement
a SoC processor.
ASIC-related code (I mean core) forms additional platform layer, so I
suggest
adding ASIC helpers to generic platform code i.e. drivers/platform.c, but
ASIC drivers to drivers/asic/ directory.
Regards,
Dmitry
On Tue, May 01, 2007 at 08:18:21PM +0300, Paul Sokolovsky wrote:
> Well, while description catches the essence of course, TLA is
> far from being perfect: 1) Completely unknown; 2) can be easily
> confused with mtd.
>
> But it's even more funny: there *is* drivers/mfd/ already in
> mainline. I'd say that we were blind, but even you say "proposed", not
> "exists", nor anybody else brought that to attention. I'm afraid, that
> proves point 1 above ;-).
It's only unknown to communities which do not read this mailing list.
drivers/mfd was suggested after discussion here about where to put the
UCB1[23]00 device drivers, since it was felt that drivers/misc was
inappropriate.
There's not much infrastructure there though.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
Hello Dmitry,
Tuesday, May 1, 2007, 10:08:23 PM, you wrote:
> ian wrote:
>> On Tue, 2007-05-01 at 20:29 +0400, Dmitry Krivoschekov wrote:
>>> If you used ASIC acronym it would be more appropriate and not so
>>> ambiguous.
>>
>> Actually, thats not bad. I'd be ok with that is SoC isnt used.
>>
> I'm ok with that too, i.e. very rough definition is:
> SoC (system-on-chip) is a platform level chip which incorporates processor
> devices (CPU, cache, coprocessors, memory controller etc.), system devices
> (timers, interrupt controllers etc.) and peripheral devices
> (UARTs, LCD controllers, USB controllers etc),
> while ASIC (Application-specific integrated circuit) is also a platform
> level
> chip which incorporates peripheral and system devices but does not include
> processor devices. ASICs are designed to expand processor functionality,
> it could supplement a normal processor (non-SoC) and also could supplement
> a SoC processor.
> ASIC-related code (I mean core) forms additional platform layer, so I
> suggest
> adding ASIC helpers to generic platform code i.e. drivers/platform.c, but
> ASIC drivers to drivers/asic/ directory.
There problem here is the same - our target chips are not
just ASICs. It just happens that the one we start with called such,
but we have different ones too. It's still important that they contain
blocks with different functionality, and drivers we propose deal with
basic, common functionality of chips. Now that it was pointed out that
there's place in the tree for such drivers, it would be not wise to
try to create another one.
> Regards,
> Dmitry
--
Best regards,
Paul mailto:[email protected]
Hello Paul,
Paul Sokolovsky wrote:
>> ASIC-related code (I mean core) forms additional platform layer, so I
>> suggest
>> adding ASIC helpers to generic platform code i.e. drivers/platform.c, but
>> ASIC drivers to drivers/asic/ directory.
>
> There problem here is the same - our target chips are not
> just ASICs.
You say they are chips so they are integrated circuits (ICs), they
are designed to solve some specific needs, so they are
application-specific ICs, i.e. ASICs, what's the problem?
> It just happens that the one we start with called such,
> but we have different ones too.
Interesting what are they?
Power management ICs? Power management + audio
+ touchscreen + ADC + USB transceiver + UART + whatever
all such chips may be considered as ASICs.
> It's still important that they contain
> blocks with different functionality, and drivers we propose deal with
> basic, common functionality of chips.
That different functionality blocks will be handled by appropriate
device drivers, and in general the drivers should not depend on
a particular ASIC but use common ASIC API.
But "common functionality" drivers are ASIC-specific.
> Now that it was pointed out that
> there's place in the tree for such drivers, it would be not wise to
> try to create another one.
>
>
>
Perhaps, so. Actually, MFD (multi functional device) doesn't
imply a platform-level device but ASIC seems does.
Thanks,
Dmitry
Hello Dmitry,
Wednesday, May 2, 2007, 12:17:33 AM, you wrote:
> Hello Paul,
> Paul Sokolovsky wrote:
>>> ASIC-related code (I mean core) forms additional platform layer, so I
>>> suggest
>>> adding ASIC helpers to generic platform code i.e. drivers/platform.c, but
>>> ASIC drivers to drivers/asic/ directory.
>>
>> There problem here is the same - our target chips are not
>> just ASICs.
> You say they are chips so they are integrated circuits (ICs), they
> are designed to solve some specific needs, so they are
> application-specific ICs, i.e. ASICs, what's the problem?
The issue is that in this case functional organization what's
important, not thing like (original) design purpose/method, expressed in
vague terms like ASIC. A "passive" (from CPU point of view) chip of
30-50 gates dealing with clock/control signals destribution is of
course ASIC too, but has nothing to do with chips in question.
>> It just happens that the one we start with called such,
>> but we have different ones too.
> Interesting what are they?
> Power management ICs? Power management + audio
> + touchscreen + ADC + USB transceiver + UART + whatever
> all such chips may be considered as ASICs.
"May" is a keyword here. They may be considered SoCs too, as
they share one important trait with them: multiple devices of
different functions in one package. I'd of course love idea of calling
any chip but CPU and memory an ASIC, but that doesn't correspond with
reality. As an example, ICH, etc chipsets are of course ASICs, but I
personally never heard them called such, and I'm sure few listeners
would be confused, if someone called them such.
>> It's still important that they contain
>> blocks with different functionality, and drivers we propose deal with
>> basic, common functionality of chips.
> That different functionality blocks will be handled by appropriate
> device drivers, and in general the drivers should not depend on
> a particular ASIC but use common ASIC API.
> But "common functionality" drivers are ASIC-specific.
>> Now that it was pointed out that
>> there's place in the tree for such drivers, it would be not wise to
>> try to create another one.
>>
>>
>>
> Perhaps, so. Actually, MFD (multi functional device) doesn't
> imply a platform-level device but ASIC seems does.
That's also a subject of interpretation for specific
chip/driver. Proposed soc-core is actually a helper, not a strict API
to follow. We just found that many our drivers do common things, so
factored out functionality for easier reuse. It of course can be
extended given the need (but yes, so far all our MFD chips and their
subdevices are treated as platform devices).
But back from ontology to specific ideas of patch
restructuring. Given a need to distinguish discussed chips' handling
model from "generic" MFDs (like ones already in drivers/mfd/), and the
fact that Ian Molton, author of soc-core.*, likes ASIC designator, this
warrants rename of it to asic-core.*, I guess. All it still goes to
drivers/mfd/ to not create more stuff than needed.
As for driver headers, they apparently go to include/linux/ .
That's of course keeps being out of hand, but small guy's way to
a solution is apparently to accelerate that. When number of files in
include/linux/ will hit 1K, I guess core maintainers will notice
that something's wrong and find a global solution. (One good idea is to
separate driver-specific headers from global and subsystem ones, but
all that is out of scope for this discussion...).
> Thanks,
> Dmitry
--
Best regards,
Paul mailto:[email protected]