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

2016-11-01 Thread Brian Starkey
On Tue, Nov 01, 2016 at 03:04:14PM +, Russell King - ARM Linux wrote:
>
>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.)

I think it's fine to send that. I don't have a branch to send a pull
request for and I'm struggling with a flaky connection, so if you've
got a branch, just send it.

Thanks,
-Brian
>
>-- 
>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.


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

2016-11-01 Thread 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:


   ABCD-Merge
`EFGH---^

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:

   ABCD---Merge
  `EFGH---^

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.


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

2016-10-24 Thread Jyri Sarha
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.

Since first version of this series:
- Dropped "drm/i2c: tda998x: Remove obsolete drm_connector_register() call"
  - an earlier instance of the same patch already exists
- Got rid of unload callback and deprecated drm_put_dev() calls

A patch[1] that crashed all drm drivers using load() hook was briefly
part of linux-next, so became aware that tilcdc should stop using
that too.

The two first patches should be merged before the third can be
merged. So the merge order should be agreed with tda998x before going
forward.

The last patch is just a cleanup, but depends on earlier ones.

Best regards,
Jyri

[1] https://patchwork.kernel.org/patch/9322771/

Jyri Sarha (3):
  drm/tilcdc: Remove obsolete drm_connector_register() calls
  drm/tilcdc: Stop using struct drm_driver load() callback
  drm/tilcdc: Use unload to handle initialization failures

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  10 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 185 +++--
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   3 +-
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  |   2 -
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |   2 -
 5 files changed, 93 insertions(+), 109 deletions(-)

-- 
1.9.1