From: Kevin Hilman <hidden> Date: 2011-03-31 14:43:20
Thomas Gleixner [off-list ref] writes:
But the current SoC maintainer model does not work either. The SoC
maintainers care about their sandbox and have exactly zero incentive
to look at the overall picture, e.g reuse of code for the same IP
blocks, better abstraction mechanisms etc.
zero incentive? that's a bit strong, IMO.
That may be true for some SoCs, it's not really fair as a sweeping
statement.
Some SoCs families (like OMAP) have huge amount of diversity even within
the SoC family, so better abstractions and generic infrastrucure
improvements are an obvious win, even staying within the SoC.
There are several examples of SoC maintainers looking at the overall
picture and contributing to better abstractions and common
infrastructure code.
One is USB as Felipe already pointed out where the same USB OTG IP block
(with vendor tweaks of course) is used across several completely
different SoCs with common infrastructure code.
Another example that I'm more familiar with is power management. In
OMAP land, we have been been very supportive and active in generic
infrastructure improvements (like runtime PM.) In fact runtime PM was
born partially because one of the other ARM SoC maintainers (Magnus
Damm, SH-mobile) proposed the idea as he was implementing PM for that
SoC family. We have been actively contributing to the runtime PM
infrastructure with both code, testing, converting our drivers over to
using runtime PM. and contributing back fixes and enhancements as we
find problems or limitations. In addition, personally, I have spent the
last year evangelizing the importance of using common frameworks like
runtime PM to the embedded community via talks at the Embedded Linux
Conference (ELC, US and Europe.) Especially as IP blocks are reused
across SoC families, abstractions like runtime PM are the only way to
keep the SoC specifics of PM out of the common driver.
Yes, ARM SoC maintainers have to make up some ground. But compare this
to just a couple years ago where the common complaint was "why aren't
embedded SoC people contributing code to mainline", and you'll see we
have come a long way.
Kevin
Maintainer of parts of the ARM kernel:
- TI Davinci SoC family
- TI OMAP Power Management infrastructure
From: Thomas Gleixner <hidden> Date: 2011-03-31 15:02:00
On Thu, 31 Mar 2011, Kevin Hilman wrote:
Thomas Gleixner [off-list ref] writes:
quoted
But the current SoC maintainer model does not work either. The SoC
maintainers care about their sandbox and have exactly zero incentive
to look at the overall picture, e.g reuse of code for the same IP
blocks, better abstraction mechanisms etc.
zero incentive? that's a bit strong, IMO.
That may be true for some SoCs, it's not really fair as a sweeping
statement.
Fair enough, but it's the perception in general.
Conference (ELC, US and Europe.) Especially as IP blocks are reused
across SoC families, abstractions like runtime PM are the only way to
keep the SoC specifics of PM out of the common driver.
Right, I know that these things happen, but at the same time the sheer
amount of stuff flowing in makes it hard that these infrastructure
stuff really works out. And we are only at the beginning of the big
shuffle "code in to mainline" game.
After cleaning up the whole irq stuff across the tree I can tell you,
that the mess is non-linear growing with the number of instances.
You can see the patterns which are:
- copy and paste
- introduce different bugs
- add more abuse
That's what I'm really concerned about.
Yes, ARM SoC maintainers have to make up some ground. But compare this
to just a couple years ago where the common complaint was "why aren't
embedded SoC people contributing code to mainline", and you'll see we
have come a long way.
Well, code comes in, which is progress. But we need to figure out how
to deal with the increasingly growing flood before we drown in it.
Thanks,
tglx
From: Russell King - ARM Linux <hidden> Date: 2011-03-31 15:06:15
On Thu, Mar 31, 2011 at 05:01:40PM +0200, Thomas Gleixner wrote:
On Thu, 31 Mar 2011, Kevin Hilman wrote:
quoted
Thomas Gleixner [off-list ref] writes:
quoted
But the current SoC maintainer model does not work either. The SoC
maintainers care about their sandbox and have exactly zero incentive
to look at the overall picture, e.g reuse of code for the same IP
blocks, better abstraction mechanisms etc.
zero incentive? that's a bit strong, IMO.
That may be true for some SoCs, it's not really fair as a sweeping
statement.
Fair enough, but it's the perception in general.
quoted
Conference (ELC, US and Europe.) Especially as IP blocks are reused
across SoC families, abstractions like runtime PM are the only way to
keep the SoC specifics of PM out of the common driver.
Right, I know that these things happen, but at the same time the sheer
amount of stuff flowing in makes it hard that these infrastructure
stuff really works out. And we are only at the beginning of the big
shuffle "code in to mainline" game.
After cleaning up the whole irq stuff across the tree I can tell you,
that the mess is non-linear growing with the number of instances.
You can see the patterns which are:
- copy and paste
- introduce different bugs
- add more abuse
That's what I'm really concerned about.
quoted
Yes, ARM SoC maintainers have to make up some ground. But compare this
to just a couple years ago where the common complaint was "why aren't
embedded SoC people contributing code to mainline", and you'll see we
have come a long way.
Well, code comes in, which is progress. But we need to figure out how
to deal with the increasingly growing flood before we drown in it.
How about we declare the remainder of this cycle and the next merge window
as being only for bug and regression fixes, and consolidation of stuff like
the IRQ controller and GPIO controller code for the next merge window?
Some SoCs families (like OMAP) have huge amount of diversity even within
the SoC family, so better abstractions and generic infrastrucure
improvements are an obvious win, even staying within the SoC.
But that's the point. The incentive is there for managing the infrastructure
within the SoC, but not across SoCs. Allow me to use OMAP as a bad example
while pointing out that it's really one of the best supported platforms
we currently have, while the others are usually much worse in terms of
working with the community (or at least they are behind on the learning
curve but getting there):
* OMAP2 introduced the hwmod concept as an attempt to reduce duplication
between board code, but the code was done on the mach-omap2 level
instead of finding a way to make it work across SOC vendors, or using
an existing solution.
* The IOMMU code in omap2 duplicates the API we have in the common kernel,
with slight differences, instead of using the existing code, making it
impossible to share a driver between SOC families.
* The ti-st code duplicates parts of the bluetooth layer (apparently
that is getting fixed soon).
* The DSS display drivers introduce new infrastructure include new bus
types that have the complexity to make them completely generic, but
in practice can only work on OMAP, and are clearly not written with
cross-vendor abstractions in mind.
Arnd
On Thu, 31 Mar 2011, Russell King - ARM Linux wrote:
On Thu, Mar 31, 2011 at 05:01:40PM +0200, Thomas Gleixner wrote:
quoted
On Thu, 31 Mar 2011, Kevin Hilman wrote:
quoted
Thomas Gleixner [off-list ref] writes:
quoted
Yes, ARM SoC maintainers have to make up some ground. But compare this
to just a couple years ago where the common complaint was "why aren't
embedded SoC people contributing code to mainline", and you'll see we
have come a long way.
Well, code comes in, which is progress. But we need to figure out how
to deal with the increasingly growing flood before we drown in it.
How about we declare the remainder of this cycle and the next merge window
as being only for bug and regression fixes, and consolidation of stuff like
the IRQ controller and GPIO controller code for the next merge window?
well, now that -rc1 has been released, the remainder of this cycleis
already only bug and regression fixes.
declaring the next merge window as the same may or may not help, depending
on if it pushes people to do more consolodations work or just delay
submitting the work they are doing.
David Lang
From: Thomas Gleixner <hidden> Date: 2011-03-31 16:59:12
On Thu, 31 Mar 2011, Arnd Bergmann wrote:
On Thursday 31 March 2011, Kevin Hilman wrote:
quoted
Some SoCs families (like OMAP) have huge amount of diversity even within
the SoC family, so better abstractions and generic infrastrucure
improvements are an obvious win, even staying within the SoC.
But that's the point. The incentive is there for managing the infrastructure
within the SoC, but not across SoCs. Allow me to use OMAP as a bad example
while pointing out that it's really one of the best supported platforms
we currently have, while the others are usually much worse in terms of
working with the community (or at least they are behind on the learning
curve but getting there):
* OMAP2 introduced the hwmod concept as an attempt to reduce duplication
between board code, but the code was done on the mach-omap2 level
instead of finding a way to make it work across SOC vendors, or using
an existing solution.
* The IOMMU code in omap2 duplicates the API we have in the common kernel,
with slight differences, instead of using the existing code, making it
impossible to share a driver between SOC families.
* The ti-st code duplicates parts of the bluetooth layer (apparently
that is getting fixed soon).
* The DSS display drivers introduce new infrastructure include new bus
types that have the complexity to make them completely generic, but
in practice can only work on OMAP, and are clearly not written with
cross-vendor abstractions in mind.
Right, but the problem starts in way simpler areas like irq chips and
gpio stuff, where lots of the IP cores are similar and trivial enough
to be shared across many SoC families.
Even the OMAP "consolidated" code is silly:
static void _set_gpio_dataout(struct gpio_bank *bank, int gpio, int enable)
{
void __iomem *reg = bank->base;
u32 l = 0;
switch (bank->method) {
#ifdef CONFIG_ARCH_OMAP1
case METHOD_MPUIO:
reg += OMAP_MPUIO_OUTPUT / bank->stride;
l = __raw_readl(reg);
if (enable)
l |= 1 << gpio;
else
l &= ~(1 << gpio);
break;
#endif
#ifdef CONFIG_ARCH_OMAP15XX
case METHOD_GPIO_1510:
reg += OMAP1510_GPIO_DATA_OUTPUT;
l = __raw_readl(reg);
if (enable)
l |= 1 << gpio;
else
l &= ~(1 << gpio);
break;
#endif
#ifdef CONFIG_ARCH_OMAP16XX
case METHOD_GPIO_1610:
if (enable)
reg += OMAP1610_GPIO_SET_DATAOUT;
else
reg += OMAP1610_GPIO_CLEAR_DATAOUT;
l = 1 << gpio;
break;
#endif
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
case METHOD_GPIO_7XX:
reg += OMAP7XX_GPIO_DATA_OUTPUT;
l = __raw_readl(reg);
if (enable)
l |= 1 << gpio;
else
l &= ~(1 << gpio);
break;
#endif
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
case METHOD_GPIO_24XX:
if (enable)
reg += OMAP24XX_GPIO_SETDATAOUT;
else
reg += OMAP24XX_GPIO_CLEARDATAOUT;
l = 1 << gpio;
break;
#endif
#ifdef CONFIG_ARCH_OMAP4
case METHOD_GPIO_44XX:
if (enable)
reg += OMAP4_GPIO_SETDATAOUT;
else
reg += OMAP4_GPIO_CLEARDATAOUT;
l = 1 << gpio;
break;
#endif
default:
WARN_ON(1);
return;
}
__raw_writel(l, reg);
}
So we have 2 types of sections:
#1
data = read_reg();
if (enable)
data |= bit;
else
data &= ~bit;
write_reg(data);
#2
if (enable)
write_enable_reg(bit);
else
write_disable_reg(bit);
But the code above has 6 cases in the switch because nobody abstracted
it out consequently. Not to talk about the ifdef mess.
So now look@tons of other gpio implementations all over the DOZENS
of ARM plat-/mach- space and guess what.
Most have either type #1 or type #2 just slightly different copied,
less or better abstracted and I'm pretty damned sure, that you could
consolidate all that stuff into a handful or even less drivers which
provide the code across the board.
Same for irq chips. Most of these gpio things have callbacks which do:
irq_xxx(struct irq_data *d)
{
gpio = irq_data_get_irq_chip_data(d);
irq = d->irq - gpio->base_irq;
reg = convert_to_reg(gpio, irq);
mask = convert_to_mask(gpio);
write(reg, mask);
}
I saw all those incarnations lately and you can boil them down to a
handful or less as well which fit all over the place.
Start off with such a trivial, but immense effective cleanup and see
what it helps to share code even accross SoC vendors. They all glue
together random IP blocks from the market and there are not soo many
sources which are relevant. This makes sense in all aspects:
1) less and better code
2) faster setup for new SoCs
3) shared benefit for all vendors
Thanks,
tglx
From: Nicolas Pitre <nico@fluxnic.net> Date: 2011-03-31 18:23:25
On Thu, 31 Mar 2011, Thomas Gleixner wrote:
Start off with such a trivial, but immense effective cleanup and see
what it helps to share code even accross SoC vendors. They all glue
together random IP blocks from the market and there are not soo many
sources which are relevant. This makes sense in all aspects:
1) less and better code
2) faster setup for new SoCs
3) shared benefit for all vendors
If this was always true. Someone commented on the fact that the IP
block providing USB on OMAP is shared with a couple other platforms.
But about 2600 lines of pure glue is still necessary around the common
driver to make it work for everyone. I'm not saying that separate
drivers are called for here, simply that hardware people _will_ screw it
up, especially when they are hooking it up to a non-standard
SOC-specific bus.
Another example: there used to be many different IP blocks providing
MMC/SD/SDIO support that people were adding to their SOCs. Each SOC
would have its own reinvention of the wheel but they were all different
but simple wheels, and drivers for them were obvious and straight
forward. Then came the SDHCI "standard". At first few implementation
existed so the sdhci driver was, too, rather straight forward. But
hardware manufacturers thought (rightfully) that this would be a good
idea to use that standard instead of using their custom simple wheel.
And so they did, releasing new SOC revision with the old wheel replaced
by a square implementation of the sdhci one. Today the sdhci driver is
literally bastardized by all the quirks needed to work around all the
different and creative bugs or even standard misinterpretation of the
standard out there in the field. And in many cases the sdhci version is
even _less_ functional than the custom and already supported
implementation it replaced.
And what would the hardware guys tell you? That software is cheap.
Nicolas
From: Thomas Gleixner <hidden> Date: 2011-03-31 18:56:05
On Thu, 31 Mar 2011, Nicolas Pitre wrote:
On Thu, 31 Mar 2011, Thomas Gleixner wrote:
quoted
Start off with such a trivial, but immense effective cleanup and see
what it helps to share code even accross SoC vendors. They all glue
together random IP blocks from the market and there are not soo many
sources which are relevant. This makes sense in all aspects:
1) less and better code
2) faster setup for new SoCs
3) shared benefit for all vendors
If this was always true. Someone commented on the fact that the IP
block providing USB on OMAP is shared with a couple other platforms.
But about 2600 lines of pure glue is still necessary around the common
driver to make it work for everyone. I'm not saying that separate
drivers are called for here, simply that hardware people _will_ screw it
up, especially when they are hooking it up to a non-standard
SOC-specific bus.
Right. That's a problem, but we should not ignore the places where
reusing stuff is easy possible. And making good examples out of it.
And it really _IS_ worth the trouble. Look at the git log of
drivers/spi/pxa2xx* . We could have slapped the other "x86" driver
into spi, but that does not make any sense from a software engineering
and maintainability POV. And it would have been more work in the end
to cleanup the separate driver than isolating the existing one and
reuse it.
This is a sustainability issue. And we need to become more clever
about identifying the places where we can abstract stuff into shared
drivers and infrastructure when we want to sustain Linux for another
few decades.
And what would the hardware guys tell you? That software is cheap.
If you can prove with simple examples that using existing software
removes 6 month of useless reinventing the wheel and another 6 month
of testing plus the fight with the kernel folks, then eventually they
start to listen as you can express this in $$$.
Thanks,
tglx
From: Tomi Valkeinen <hidden> Date: 2011-04-01 07:32:44
On Thu, 2011-03-31 at 17:23 +0200, Arnd Bergmann wrote:
* The DSS display drivers introduce new infrastructure include new bus
types that have the complexity to make them completely generic, but
in practice can only work on OMAP, and are clearly not written with
cross-vendor abstractions in mind.
If you mean the panel drivers, then I disagree. They are currently OMAP
specific, but they are designed so that making them generic shouldn't be
too difficult. It's been my aim for a long time already to make the
panel drivers generic, but I've never had time and it's never been quite
clear to me what would be the best way to do that.
The core DSS driver is OMAP specific, and while the DSS IP could in
theory be used in some other platform, that is not currently the case
and I wouldn't want to needlessly start abstracting things for just the
sake of abstracting.
Tomi
On Thu, 2011-03-31 at 17:23 +0200, Arnd Bergmann wrote:
quoted
* The DSS display drivers introduce new infrastructure include new bus
types that have the complexity to make them completely generic, but
in practice can only work on OMAP, and are clearly not written with
cross-vendor abstractions in mind.
If you mean the panel drivers, then I disagree. They are currently OMAP
specific, but they are designed so that making them generic shouldn't be
too difficult. It's been my aim for a long time already to make the
panel drivers generic, but I've never had time and it's never been quite
clear to me what would be the best way to do that.
The core DSS driver is OMAP specific, and while the DSS IP could in
theory be used in some other platform, that is not currently the case
and I wouldn't want to needlessly start abstracting things for just the
sake of abstracting.
Ok, fair enough. I haven't looked at the OMAP DSS code in detail, so
I apologise if I did it injustice. What I did review is the ST Ericsson
MCDE code which was written by taking the OMAP code as an example.
The symptom I'm describing is that infrastructure is getting added
to platform specific code without making clear that it is mean to
be generic. I.e. the code is hidded away in the drivers/video/omap
directory, where other people would not go looking for it.
What I would have hoped you to do is to tell the ST Ericsson people
when they posted their code that they should instead work with you
to integrate the two implementations. As far as I remember (I may be
wrong again), that did not happen.
Arnd
On Thu, 31 Mar 2011, Arnd Bergmann wrote:
Right, but the problem starts in way simpler areas like irq chips and
gpio stuff, where lots of the IP cores are similar and trivial enough
to be shared across many SoC families.
Yes, I'm sure that there are more obvious examples than the ones I've
given, those were just the ones that I had noticed myself.
Even the OMAP "consolidated" code is silly:
But the code above has 6 cases in the switch because nobody abstracted
it out consequently. Not to talk about the ifdef mess.
From: Tomi Valkeinen <hidden> Date: 2011-04-01 11:55:24
(dropping people from cc, as this is getting quite DSS spesific)
On Fri, 2011-04-01 at 13:22 +0200, Arnd Bergmann wrote:
On Friday 01 April 2011, Tomi Valkeinen wrote:
quoted
On Thu, 2011-03-31 at 17:23 +0200, Arnd Bergmann wrote:
quoted
* The DSS display drivers introduce new infrastructure include new bus
types that have the complexity to make them completely generic, but
in practice can only work on OMAP, and are clearly not written with
cross-vendor abstractions in mind.
If you mean the panel drivers, then I disagree. They are currently OMAP
specific, but they are designed so that making them generic shouldn't be
too difficult. It's been my aim for a long time already to make the
panel drivers generic, but I've never had time and it's never been quite
clear to me what would be the best way to do that.
The core DSS driver is OMAP specific, and while the DSS IP could in
theory be used in some other platform, that is not currently the case
and I wouldn't want to needlessly start abstracting things for just the
sake of abstracting.
Ok, fair enough. I haven't looked at the OMAP DSS code in detail, so
I apologise if I did it injustice. What I did review is the ST Ericsson
MCDE code which was written by taking the OMAP code as an example.
The symptom I'm describing is that infrastructure is getting added
to platform specific code without making clear that it is mean to
be generic. I.e. the code is hidded away in the drivers/video/omap
directory, where other people would not go looking for it.
What I would have hoped you to do is to tell the ST Ericsson people
when they posted their code that they should instead work with you
to integrate the two implementations. As far as I remember (I may be
wrong again), that did not happen.
I don't seem to remember seeing anything from ST Ericsson... While my
memory doesn't always serve me well, I would imagine I'd remember if I'd
seen code based on my code.
Ah, found them from fbdev mail archive. I was rather busy at that
period, I didn't really read the mailing lists.
I totally agree with you that we should have a common panel interface
layer. As I said, I've had it as a target for a long time. And hopefully
now that I moved from Nokia to TI I'll finally have time to work on it
also.
Thanks for pointing me to the MCDE stuff. I doesn't seem to be merged,
though. I need to contact them and see if they're still interested in
working on the common interface.
Tomi
Thanks for pointing me to the MCDE stuff. I doesn't seem to be merged,
though. I need to contact them and see if they're still interested in
working on the common interface.
I pushed back quite hard on some of the aspects there, which probably
prevented it from going in so far. If the code is as much based on
the OMAP DSS as I think, quite a number of changes are required to
both in order to get them into shape for a decent cross-platform layer,
but there should not be any fundamental issues.
Arnd
From: Tomi Valkeinen <hidden> Date: 2011-04-01 12:15:22
On Fri, 2011-04-01 at 14:07 +0200, Arnd Bergmann wrote:
On Friday 01 April 2011, Tomi Valkeinen wrote:
quoted
Thanks for pointing me to the MCDE stuff. I doesn't seem to be merged,
though. I need to contact them and see if they're still interested in
working on the common interface.
I pushed back quite hard on some of the aspects there, which probably
prevented it from going in so far. If the code is as much based on
the OMAP DSS as I think, quite a number of changes are required to
both in order to get them into shape for a decent cross-platform layer,
but there should not be any fundamental issues.
I only looked it briefly, but I'm not sure if there's that much code
that could be common. But I need to read the mail thread properly.
The driver for the display HW on the SoC doesn't probably have anything
in common with OMAP one. What could and should be common is the panel
side, which was just a single patch in that patch set.
Tomi