lkml.org 
[lkml]   [2015]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform
    On Wed, Nov 25, 2015 at 09:05:02PM +0100, Arnd Bergmann wrote:
    > On Wednesday 25 November 2015 18:37:28 Russell King - ARM Linux wrote:
    > > On Wed, Nov 25, 2015 at 05:09:37PM +0100, Andrew Lunn wrote:
    > > > Russell, you are the last known user of mach-dove. What are your
    > > > plans? You keep saying you have given up trying to mainline your Cubox
    > > > patches. Have you really given up? Can we remove mach-dove?
    > >
    > > Right now, I'm developing etnaviv in spare time on the Cubox[*], which
    > > is still primarily running a non-DT kernel.
    > >
    > > It's actually a kernel that I've hacked which is capable of booting
    > > both DT and non-DT, but even when booted in DT mode, I still require
    > > much of the arch/arm/mach-dove infrastructure to get things like
    > > armada-drm, etnaviv and other drivers running. Especially because
    > > we're missing things like the high-speed clocks (the stuff above the
    > > tclk domain.) I've not even started to work out how to get that
    > > into mainline, or how to integrate that with CCF. Quite what can be
    > > done with the audio patches, I've no idea, that remains a bone of
    > > contention and stalemate, and currently isn't DT-able. See the list
    > > of patches at the end of this message...
    >
    > I think it's ok to keep mach-dove around for a longer time to keep the
    > board file, I'm way more interested in completing the multiplatform
    > work at last.
    >
    > If I understand you right, being able to build mach-dove and mach-mvebu
    > together will actually help you remove one or more of your patches,
    > but of course will require a small bit of rebasing.

    This is something I already do, and it's trivial to make it work.
    You're doing it by moving some includes around, I've found that it's
    not necessary to move any includes around what so ever.

    The problem I have right now is that people are expecting me to do
    everything at once: people want me to write documentation for the
    component helper. People want me to merge more Dove patches. People
    want me to merge the Armada 38x work I have queued. People are wanting
    to get the etnaviv kernel driver out for merging this week, now that
    I've solved the final part of the etnaviv puzzle - but yesterday I've
    uncovered another user API issue that needs to be discussed and
    resolved.

    You know, there aren't enough me's to do everything - people just have
    to get used to the idea that if they're not willing to put the work in
    (iow, I have to put the work in) then things are going to be slow for
    anything that isn't funded work, because I have a lot on my plate.

    In the case of Dove, I only ever look at the current state of things
    once every kernel cycle, as I only ever update the tree to a final
    kernel release. That means it takes about five months between
    submission and seeing the result of those patches merged, so I can
    then sort through what other stuff needs to be sent. Why six months?
    Get it queued for the next merge window (which can be up to six to
    eight weeks away). Then wait a full kernel cycle (eight to ten weeks)
    for it to appear in a final kernel. That's 14 to 18 weeks.

    The last stuff which was merged was the PMU driver, merged in August.
    It's taken until 4.3 for this to become "visible" in my Dove tree.
    I should, at some point during this cycle - depending on my available
    time - start looking at what other pieces I can send, but what I'm
    saying is that this is the _earliest_ opportunity I have to start
    looking again at this.

    Meanwhile, during this last merge window, more Armada DRM patches have
    gone in, along with some TDA998x patches - both of which I term Dove
    patches because that's their applicable kernel tree that they get
    tested with.

    Meanwhile, Etnaviv is progressing, which again, is a Dove thing,
    because the Dove has a Vivante GC600 GPU, which etnaviv drives.

    Meanwhile, Andrew's complaining that he's not seen anything from me
    for a long time. What Andrew can't see is that the work is going on
    at the peripheral driver level, not at the core level, /because/ it's
    the peripheral drivers which are blocking me dropping the non-DT
    support.

    --
    FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
    according to speedtest.net.


    \
     
     \ /
      Last update: 2015-11-26 00:01    [W:2.264 / U:0.652 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site