Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>]

On 06/30/2014 04:25 PM, Russell King - ARM Linux wrote:
> On Mon, Jun 30, 2014 at 03:22:58PM +0200, Sebastian Hesselbarth wrote:
>> Of course we thought about it. But as you are dealing with different
>> SoCs at a time, we also have to care about some more SoCs than just
>> Dove. And, of course, we also run out of spare time to prepare proper
>> patches over and over again. I really /know/ that if you send patches,
>> they are well thought and well tested, so I basically postpone work
>> on that if I know you are working on it.
>>
>> My current idea of PMU register space is to have a DT provided regmap
>> but again, there are patches floating around but currently that regmap
>> helpers are still WIP. FWIW, if you look at dove pinctrl, we did a
>> last-minute patch for the PMU regs - just because you mentioned a
>> concern, so we really care about your opinion. The fact that it is not
>> solved is pure lack of time.
>
> Nothing has changed on the PMU patches since I posted them, because
> they're based on 3.15 and there's been no changes there.

I offered to deal with mainlining them end of April, you never replied.
I know that if you dislike something you answer, but it is hard to tell
if silence means agreement.

I am not going to waste any time preparing patches just to get a NAK.

>> Exactly that increasing amount of (valuable) patches makes it more
>> and more difficult for you and us to reproduce any issues. All I am
>> asking for is: if you don't push that branch for good reason, try to
>> split off at least some patches. Hunting issues like the HDMI thing
>> with 250 patches off, really isn't going to work well.
>
> Right, so what I have against mainline right now in my tree is:
>
> * two SPI patches, which have been taken by Mark
> * one long term core ARM patch adding optimised memset/memcpy IO operations
> * the PMU stuff
> * BMM (already published in git form)
> * Vmeta (already published in git form)
> * ASoC cleanup patches, which Mark took last week.
>
> What isn't visible is the stuff which converts Armada DRM to component
> support, along with the TDA998x driver (and it sounds like the TI LCDC
> people may end up blocking that effort).  This is necessary to convert
> it to DT support.  However, this depends on the component helper, and
> that's where there's a blocking problem.
>
> I sent out a bunch of patches last week, with a request for help from
> the Exynos people.  So far, that has only attracted one relatively minor
> comment from the iMX people.  I can't move forwards with the Armada
> DRM until this is sorted.  Neither can I move forward with the TDA998x
> driver.
>
> As for the ASoC stuff which you avoided commenting on, let me repeat
> that _that_ stuff is now totally dead and can /never/ be merged into
> mainline without breaking the existing ASoC kirkwood support.  In
> that case, it's not like I wasn't sending the patches out, because
> I had been... so everyone was aware of what was going on there,
> but I guess converting stuff to DT in ways that totally fuck over
> other patches is what now happens in the kernel.

If you are talking about "Kirkwood ASoC updates", you got a Tested-by
from Andrew even before I read your patches. And besides, just because
I am interested in Dove does not mean I just swallowed the whole Linux
API knowledge. I simply avoided commenting on it, because there is
/nothing/ I can add to it.

Really, I know you do dig down to the bottom of every subsystem you
are working with but I simply cannot. Just because I don't have the
time for it.

> What I think you're missing is that for those of us who want to have
> a platform fully supported, the choice has been non-DT until relatively
> recently.  We're now at the point where the DT support on Dove has
> matured to the point where it's relatively easy to end up with a fully
> functional (but not necessarily bug free) setup with DT.  It's at the
> sweet spot where you can switch between DT and non-DT and preserve
> that functionality... but as soon as we get there we want to rip out
> the old stuff.

Oh, ok.. you think it is "me" and "us"? It is you who actually want to
use Dove and me just wanting a DT representation for it?

It is not my fault that your patches are blocked by others. I can offer
help to track down the issue, but I am not going to be your scapegoat.

> Let me put that another way: it's at the point where those of us who
> have been using non-DT support can start moving the remaining drivers
> over to a DT environment without any functional loss.
>
> What I'm trying to get you to understand is that leaving the old stuff
> behind for a little while longer is beneficial - while those who have
> been running crippled DT based setups for the last year don't care
> about having full support, there are those who do.

Ok, let's have mach-dove for a little longer, fine with me.

> Of course, there's another solution to this.  I stay with my present
> 3.15 kernel for ever.  That basically bars me from sending any further
> patches.  It also means that I stop maintaining TDA998x and Armada DRM,
> and you will have to take those over, which means you get the additional
> workload from those.  Is that what you really want?

What I really want is to stop that blackmailing with giving up on
sending patches. It will be a huge loss if you do and many have said
that in the past.

If it is really me who upsets you because you feel I am blocking your
patches, just ignore my comments. Jason will happily pick them up
just because you signed them off.

Sebastian

> The Cubox is the /only/ ARM platform I have which is a capable media
> player, and I'm trying not to have it screwed by this kind of crap.
>