SoC base drivers
cover SoC base drivers
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.
Signature · 2 lines
Best regards, Paul mailto:[email protected]
Quoted 62 lines · Paul Sokolovsky
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_basedriver 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_busis 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:
Quoted 9 lines
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.
Quoted 36 lines
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/anddrivers/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.cand 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 usingasic3_basedriver.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.candarch/arm/common/locomo.care 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.
Signature · 4 lines
Ben Q: What's a light-year? A: One-third less calories than a regular year.
Hello Ben,
Quoted 1 line · you
On Tue, May 01, 2007 at 08:08:06AM +0300, Paul Sokolovsky wrote:
[]
Quoted 28 lines
Quoted 15 lines
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_busis 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:
Quoted 9 lines
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.
Quoted 8 lines
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)).
[]
Signature · 2 lines
Best regards, Paul mailto:[email protected]
Quoted 3 lines · Ben Dooks
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.)
Quoted 2 lines
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,
Quoted 3 lines · Paul Sokolovsky
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,
Quoted 7 lines · you
Hi Paul,
Quoted 3 lines · Paul Sokolovsky
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.
Quoted 7 lines
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).
Quoted 2 lines
Regards,
Dmitry
Signature · 2 lines
Best regards, Paul mailto:[email protected]
Quoted 11 lines · Paul Sokolovsky
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 aDocumentation/entry for that, I'd mention companion chips, peripheral/integrated controllers, etc. But renamingdrivers/soc/todrivers/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
Quoted 4 lines · Dmitry Krivoschekov
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.
Quoted 12 lines · Paul Sokolovsky
Hello Dmitry,
Quoted 7 lines · you
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.
Quoted 4 lines
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.
Quoted 3 lines
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?
Quoted 8 lines
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?
Quoted 3 lines
But I'm open to specific suggestions for improvement. For
example, if I was to write aDocumentation/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".
Quoted 2 lines
But renaming
drivers/soc/todrivers/companion/would be more confusing,
Not for me.
Quoted 6 lines
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
Quoted 10 lines · ian
Quoted 4 lines · Dmitry Krivoschekov
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,
Quoted 7 lines · you
Quoted 6 lines · ian
Quoted 4 lines · Dmitry Krivoschekov
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.
Quoted 8 lines
Quoted 4 lines
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).
Quoted 2 lines
Thanks,
Dmitry
Signature · 2 lines
Best regards, Paul mailto:[email protected]
Hello Richard,
Quoted 13 lines · you
Quoted 11 lines · Paul Sokolovsky
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 aDocumentation/entry for that, I'd mention companion chips, peripheral/integrated controllers, etc. But renamingdrivers/soc/todrivers/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).
Quoted 4 lines
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!
Quoted 1 line
Richard
Signature · 2 lines
Best regards, Paul mailto:[email protected]
Quoted 2 lines · Dmitry Krivoschekov
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.
Quoted 6 lines · Paul Sokolovsky
Quoted 4 lines · you
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...
Quoted 8 lines
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
Quoted 6 lines · ian
Quoted 2 lines · Dmitry Krivoschekov
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
Quoted 8 lines · Paul Sokolovsky
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.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Hello Dmitry,
Quoted 20 lines · you
Quoted 6 lines · ian
Quoted 2 lines · Dmitry Krivoschekov
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.
Quoted 4 lines
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 todrivers/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.
Quoted 2 lines
Regards,
Dmitry
Signature · 2 lines
Best regards, Paul mailto:[email protected]
Hello Paul,
Quoted 7 lines · Paul Sokolovsky
Quoted 4 lines
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 todrivers/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?
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 6 lines
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,
Quoted 8 lines · you
Hello Paul,
Quoted 5 lines · Paul Sokolovsky
Quoted 4 lines
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 todrivers/asic/directory.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 16 lines
Quoted 3 lines
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.Quoted 6 lines
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.
Quoted 2 lines
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...).
Quoted 2 lines
Thanks,
Dmitry
Signature · 2 lines
Best regards, Paul mailto:[email protected]