On Tue, Jul 15, 2014 at 5:41 AM, Benjamin Gaignard benjamin.gaignard@linaro.org wrote:
Hi all,
Does version 6 fit to all your expectations ? If yes will you consider to merge it into drm-next ? If no, please tell me what need to be fixed.
I had another pass over the driver, and didn't find anything to complain about, so for the series:
Reviewed-by: Rob Clark robdclark@gmail.com
Regards, Benjamin
2014-07-04 15:54 GMT+02:00 Benjamin Gaignard benjamin.gaignard@linaro.org:
Hi,
I have following Russel advice to rebase my patches on top of the new component helpers API.
A new branch "drm_kms_for_next-v6" is available here git://git.linaro.org/people/benjamin.gaignard/kernel.git
Regards, Benjamin
2014-07-04 10:39 GMT+02:00 Benjamin Gaignard benjamin.gaignard@linaro.org:
Rob, Russel,
What I can do is to rebase my driver on driver-core-next branch from Greg tree (git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git).
Does that could help ?
Regards, Benjamin
2014-07-03 23:59 GMT+02:00 Rob Clark robdclark@gmail.com:
On Thu, Jul 3, 2014 at 5:52 PM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Thu, Jul 03, 2014 at 05:31:21PM -0400, Rob Clark wrote:
>From a brief look, it looks like my comments have been addressed, so I think this is starting to shape up..
Laurent/Thierry/Russell, I don't suppose any of you are likely to have time before 3.17 merge window to give sti one last once-over to see what I missed ;-)
As this appears to be using the component helpers, it would be good for the author to be pre-warned about the change to the API. I'm going to be doing this as a two step thing.
The first stage of it has just been taken by Greg this evening. This retires old behaviour that was needed for the initial versions of imx-drm, and fixes a bug. More importantly, it introduces a new interface where you build the list of expected components before calling component_master_add(), passing it into that function.
It is slightly less flexible from the driver writer's view point, but allows us to do more in the component helper, and support some features that others would like to see (such as being able to add additional optional components after the initial bind (that's not much interest to DRM though.)
This should make the v3.17 merge window. I'm hoping that by forewarning about the change, that people can be aware of it and have patches prepared for v3.18 (or maybe even v3.17) to convert over to it, so we can get rid of the older interface before we get too many users of it.
I've just peeked at the binding document in the first patch. I notice that it isn't making use of the of_graph stuff, which is a bit of a shame because I've sent a RFC patch adding drivers/gpu/drm/drm_of.c to provide a helper which encoders can use to get the CRTC mask from an of_graph representation.
which reminds me, I need to have a look at the drm_of stuff..
I'm using this not only for imx-drm, but also for tda998x - and that's where the problems are likely to start if we end up with different DRM implementations doing different solutions to the connectivity problem.
If it simplifies merge-order stuff, I'd be ok with a follow-up patch that converts over (assuming it shouldn't have an impact on the DT bindings, which I'm only assuming it should not..)
Probably it would be a good idea if Benjamin at least had a patch ready to go to convert over which could be merged right after your stuff hits drm-next.
BR, -R
-- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
-- Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
-- Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
-- Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog