[PATCH v2 0/3] drm/tilcdc: Cleanup tilcdc init sequence

[Russell King - ARM Linux]

On Mon, Oct 24, 2016 at 06:34:42PM +0300, Jyri Sarha wrote:
> This series depends on tda998x dropping the drm_connector_register().
> Please keep me in loop so that I know when it gets merged so that I
> know when it is safe send a pull request for these.

This suggests that you think that delaying a merge somehow solves issues.
It doesn't really solve anything.

While it may make a particular tree remain correctly functional before
the merge and after the merge, it breaks bisecting.  Consider this:


   A----B----C----D-----Merge
    `E----F----G----H---^

Let's say that commit F depends on commit C for the result to work.
Bisect can choose _any_ of those commits as a potential point to test,
and if it were to choose G, then we will test commits A, E, F and G,
without the dependency - resulting in failure.

Hence, this is broken.  Delaying git pulls really solves nothing,
except giving the illusion of solving a problem.

The only way to avoid that is to base the changes on C.  In other words:

   A----B----C----D---------------Merge
              `E----F----G----H---^

which then means that, when bisect chooses G, it gets A, B, C, E, F,
and G, and the dependencies for E are correctly satisfied.

Of course, if F were to depend on several other independent commits
(eg, let's say that F depends on the TDA998x changes and some other
tilcdc changes) then the right thing would be to merge the dependencies
before the affected commit.

In other words, let's say that the TDA998x changes you need are in
my drm-tda998x-mali branch, but you already have some development
in your tilcdc tree which your changes will depend on.  You'd pull my
drm-tda998x-mali into your tilcdc tree before committing the dependent
changes.

Now, what about sending it up - the polite thing to do is to wait for
the dependencies to be merged upstream first, as asking for your tree
to be pulled upstream will cause the dependencies to also be pulled
upstream.

So... where do we stand at the moment...

I've merged the mali changes from Brian Starkey into a separate branch
called drm-tda998x-mali, which we can all share (I'm waiting for
agreement before pushing it out.)  drm-tda998x-mali is already merged
into the bottom of my unmerged drm-tda998x-devel branch, which has ten
patches on top.  It's also going to be merged into my drm-armada-devel
branch, so I can add the de-midlayering patch for armada there too.
You will also need to merge the drm-tda998x-mali branch before your
patches as well.

It's rather unfortunate that kernel development effectively shuts down
when the kernel summit happens, so I guess it will end up being next
week before we can move forward on this.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.