Re: Status of arch/arm in linux-next

Re: Status of arch/arm in linux-next

[Tony Lindgren]

* Mark Brown <broonie@opensource.wolfsonmicro.com> [110418 16:54]:
> On Mon, Apr 18, 2011 at 11:10:52AM +0300, Tony Lindgren wrote:
> > * Mark Brown <broonie@opensource.wolfsonmicro.com> [110416 19:54]:
> 
> > > ...this is the negative side of the message - what we're not willing to
> > > accept.  What's the positive side of the message, what can people do to
> > > help?  What is the level of consolidation work that's needed before we
> > > can develop again, and what's needed to make progress there?
> 
> > I gues a large chunk of the consolidation work will happen only after
> > we have some new frameworks in place.
> 
> > But meanwhile there is still tons of work left to do in coalescing
> > code just within the various ARM architectures. 
> 
> > I think we _should_ accept new platforms if they're sane as we
> > don't have any alternative available.
> 
> > But with the existing platforms, I think that the policy for the
> > next merge window should  be that more code disappears than gets
> > added.
> 
> This is all fairly sensible and reasonable but unfortunately it's not
> what's actually being said - what's actually being said is a flat
> refusal to accept any new code at all, even when we have no idea what a
> viable alternative might be and no matter what other progress is made,
> and no clear route to opening up that possibility.

Yeah you're right, it's all a bit unclear :) But already new common
code is popping up for various things like common SRAM support, genirq
etc. So it's a moving target for adding new platforms until that settles
down a bit.

> I do think that a flat lines of code criterion isn't terribly helpful as
> it isn't *really* what we're trying to optimise and will needlessly
> peanalise newer architectures which have good reasons for active
> development (like having been merged recently and only having stub
> support initially).  There's a big difference between an established
> architecture and a recent one here.

Sure. But for an existing platform it can tell something indirectly.
 
> > > For example, with support for new machines are we saying that for
> > > example we're going to refuse to accept anything that isn't device tree
> > > based?  If so then what needs doing?
> 
> > Well we can't require that until the device tree code is merged.
> > And for older platforms, we need the device tree append support.
> 
> > It seems that there is still at least one problem with the device
> > tree append support, but once that's sorted out we should
> > probably merge that code.
> 
> I think we need the append support for all platforms - the idea of
> having the description of the CPU in each board device tree just doesn't
> seem sensible to me.

I think the CPU or SoC can be just included into the board description
file. Or do you have something else in mind for that?

> > Adding a new machine should be a minimal amount of code already.
> > So with existing platforms that amount of code can be "exchanged"
> > for some platform code consolidation patches :)
> 
> You can easily be pushing at something in four digits by the time you
> map out a large board, it's certainly not a trivial amount of code to go
> trying to save especially when that's not really directly relevant to
> improving the reuse for board drivers and you get into diminishing
> returns fairly rapidly.

I guess I'd rather stick to only minimal board additions for now.
At least for me merging anything larger means that later on I may
have deal with sorting it out which is not nice..

BTW, this issue can be already avoided for most part by creating
generic platform init code, like what we have for gpmc-*.c for
any devices connected to the GPMC bus on omaps. And that's something
that can be done already for various platforms.
 
> This does also come back to the whole thing about pointing at relevant
> work that people can do - we're not telling people the code they're
> submitting is problematic and they need to address things with it, we're
> saying that we're not even willing to look at the code or talk about
> things that would make it OK.  That's a really negative response that's
> essentially impossible to work with.

I don't think that's the intention.. But I agree with you, we
need to coordinate things on the mailing lists so everybody knows
what can be done.

Maybe let's try to come up with some checklist on what people
can already help with? How about:

- Is there already generic code posted for review that could
  be used insted?

- Can the platform specific code and defconfigs be combined
  within the platform?

- Is the platform specific data separate from code so that
  the data can be eventually be passed from bootloader using
  device tree?

- Can the new code be made generic?

- Can the new code be made into a loadable module under
  drivers directory?

Regards,

Tony

Re: Status of arch/arm in linux-next

[Mark Brown]

On Mon, Apr 18, 2011 at 05:41:14PM +0300, Tony Lindgren wrote:
> * Mark Brown <broonie@opensource.wolfsonmicro.com> [110418 16:54]:

> > I do think that a flat lines of code criterion isn't terribly helpful as
> > it isn't *really* what we're trying to optimise and will needlessly
> > peanalise newer architectures which have good reasons for active

> Sure. But for an existing platform it can tell something indirectly.

Right, but my point is that it's being treated as gospel not an
indicator.

> > I think we need the append support for all platforms - the idea of
> > having the description of the CPU in each board device tree just doesn't
> > seem sensible to me.

> I think the CPU or SoC can be just included into the board description
> file. Or do you have something else in mind for that?

There's the device tree bits that represent the internals of the CPU
(there was a push to use device tree there too) - that needs to be
merged with the off-chip definitions from the board.

> > You can easily be pushing at something in four digits by the time you
> > map out a large board, it's certainly not a trivial amount of code to go
> > trying to save especially when that's not really directly relevant to
> > improving the reuse for board drivers and you get into diminishing
> > returns fairly rapidly.

> I guess I'd rather stick to only minimal board additions for now.
> At least for me merging anything larger means that later on I may
> have deal with sorting it out which is not nice..

Like I say right now we're just flat out refusing to accept boards at
all so it's all rather moot.

> BTW, this issue can be already avoided for most part by creating
> generic platform init code, like what we have for gpmc-*.c for
> any devices connected to the GPMC bus on omaps. And that's something
> that can be done already for various platforms.

That doesn't really achieve a huge amount for platforms where it really
is just providing resources for the device rather than doing any bus
configuration like gpmc does - on some platforms you just spec the
memory regions and IRQ ranges and you're done.  TBH for those systems it
doesn't seem like a valuable use of time to implement this when device
tree is (probably) just round the corner as for these systems it's only
factoring out data, not actual code.

> > This does also come back to the whole thing about pointing at relevant
> > work that people can do - we're not telling people the code they're
> > submitting is problematic and they need to address things with it, we're
> > saying that we're not even willing to look at the code or talk about
> > things that would make it OK.  That's a really negative response that's
> > essentially impossible to work with.

> I don't think that's the intention.. But I agree with you, we
> need to coordinate things on the mailing lists so everybody knows
> what can be done.

And also so that when people can see what they're aiming for.

> Maybe let's try to come up with some checklist on what people
> can already help with? How about:

> - Is there already generic code posted for review that could
>   be used insted?

> - Can the platform specific code and defconfigs be combined
>   within the platform?

> - Is the platform specific data separate from code so that
>   the data can be eventually be passed from bootloader using
>   device tree?

> - Can the new code be made generic?

> - Can the new code be made into a loadable module under
>   drivers directory?

That looks pretty sensible to me - I'd probably merge the "can it be
generic" with the first point but other than that it looks OK and mostly
also covers drivers as well.