From mboxrd@z Thu Jan 1 00:00:00 1970 From: moinejf@free.fr (Jean-Francois Moine) Date: Sun, 2 Feb 2014 21:07:54 +0100 Subject: [PATCH v5 00/23] In-Reply-To: <20140202191505.GK26684@n2100.arm.linux.org.uk> References: <20140202124358.GD26684@n2100.arm.linux.org.uk> <20140202190606.6fa193ce@armhf> <20140202182349.GJ26684@n2100.arm.linux.org.uk> <20140202195400.073f4eb4@armhf> <20140202191505.GK26684@n2100.arm.linux.org.uk> Message-ID: <20140202210754.307b41e8@armhf> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Sun, 2 Feb 2014 19:15:05 +0000 Russell King - ARM Linux wrote: > In which case, it may be better to reorder the remaining patches such > that the DT changes are at the very end - which means we can still > benefit from the rest of the patches if the DT solution remains an > open question. > > We do have another option now that my generic component support is in > mainline (merged during this window), which should result in a much > cleaner solution. If we convert TDA998x to a component, armada DRM > to a component master (and same for other tda998x users) then we don't > need the drm_encoder_slave stuff - all that goes away since it's no > longer necessary. > > We also solve this problem as well - because we're then not messing > around with working out if there's a DT node present: the TDA998x > device must pre-exist. For non-DT setups, this can be done when > the I2C bus is created - devices on it would be created using the > standard mechanisms already present via the i2c_board_data array. > For DT setups, the devices are created by parsing the I2C bus node > in DT. > > Both cases result in a component being registered upon invocation of > tda998x_probe(), and removal of the component when tda998x_remove() > is called. The tda998x driver becomes a standard I2C driver. > > This is something I've been intending to look at now that the component > stuff is in place - as I said previously when the questions around DT > and Armada DRM were first posed, we need to solve these issues in a > generic way first, rather than hacking around them. Agree. I was looking in the same direction... -- Ken ar c'henta? | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Francois Moine Subject: Re: [PATCH v5 00/23] Date: Sun, 2 Feb 2014 21:07:54 +0100 Message-ID: <20140202210754.307b41e8@armhf> References: <20140202124358.GD26684@n2100.arm.linux.org.uk> <20140202190606.6fa193ce@armhf> <20140202182349.GJ26684@n2100.arm.linux.org.uk> <20140202195400.073f4eb4@armhf> <20140202191505.GK26684@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 83445FD0BA for ; Sun, 2 Feb 2014 12:07:35 -0800 (PST) In-Reply-To: <20140202191505.GK26684@n2100.arm.linux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: Russell King - ARM Linux Cc: linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org T24gU3VuLCAyIEZlYiAyMDE0IDE5OjE1OjA1ICswMDAwClJ1c3NlbGwgS2luZyAtIEFSTSBMaW51 eCA8bGludXhAYXJtLmxpbnV4Lm9yZy51az4gd3JvdGU6Cgo+IEluIHdoaWNoIGNhc2UsIGl0IG1h eSBiZSBiZXR0ZXIgdG8gcmVvcmRlciB0aGUgcmVtYWluaW5nIHBhdGNoZXMgc3VjaAo+IHRoYXQg dGhlIERUIGNoYW5nZXMgYXJlIGF0IHRoZSB2ZXJ5IGVuZCAtIHdoaWNoIG1lYW5zIHdlIGNhbiBz dGlsbAo+IGJlbmVmaXQgZnJvbSB0aGUgcmVzdCBvZiB0aGUgcGF0Y2hlcyBpZiB0aGUgRFQgc29s dXRpb24gcmVtYWlucyBhbgo+IG9wZW4gcXVlc3Rpb24uCj4gCj4gV2UgZG8gaGF2ZSBhbm90aGVy IG9wdGlvbiBub3cgdGhhdCBteSBnZW5lcmljIGNvbXBvbmVudCBzdXBwb3J0IGlzIGluCj4gbWFp bmxpbmUgKG1lcmdlZCBkdXJpbmcgdGhpcyB3aW5kb3cpLCB3aGljaCBzaG91bGQgcmVzdWx0IGlu IGEgbXVjaAo+IGNsZWFuZXIgc29sdXRpb24uICBJZiB3ZSBjb252ZXJ0IFREQTk5OHggdG8gYSBj b21wb25lbnQsIGFybWFkYSBEUk0KPiB0byBhIGNvbXBvbmVudCBtYXN0ZXIgKGFuZCBzYW1lIGZv ciBvdGhlciB0ZGE5OTh4IHVzZXJzKSB0aGVuIHdlIGRvbid0Cj4gbmVlZCB0aGUgZHJtX2VuY29k ZXJfc2xhdmUgc3R1ZmYgLSBhbGwgdGhhdCBnb2VzIGF3YXkgc2luY2UgaXQncyBubwo+IGxvbmdl ciBuZWNlc3NhcnkuCj4gCj4gV2UgYWxzbyBzb2x2ZSB0aGlzIHByb2JsZW0gYXMgd2VsbCAtIGJl Y2F1c2Ugd2UncmUgdGhlbiBub3QgbWVzc2luZwo+IGFyb3VuZCB3aXRoIHdvcmtpbmcgb3V0IGlm IHRoZXJlJ3MgYSBEVCBub2RlIHByZXNlbnQ6IHRoZSBUREE5OTh4Cj4gZGV2aWNlIG11c3QgcHJl LWV4aXN0LiAgRm9yIG5vbi1EVCBzZXR1cHMsIHRoaXMgY2FuIGJlIGRvbmUgd2hlbgo+IHRoZSBJ MkMgYnVzIGlzIGNyZWF0ZWQgLSBkZXZpY2VzIG9uIGl0IHdvdWxkIGJlIGNyZWF0ZWQgdXNpbmcg dGhlCj4gc3RhbmRhcmQgbWVjaGFuaXNtcyBhbHJlYWR5IHByZXNlbnQgdmlhIHRoZSBpMmNfYm9h cmRfZGF0YSBhcnJheS4KPiBGb3IgRFQgc2V0dXBzLCB0aGUgZGV2aWNlcyBhcmUgY3JlYXRlZCBi eSBwYXJzaW5nIHRoZSBJMkMgYnVzIG5vZGUKPiBpbiBEVC4KPiAKPiBCb3RoIGNhc2VzIHJlc3Vs dCBpbiBhIGNvbXBvbmVudCBiZWluZyByZWdpc3RlcmVkIHVwb24gaW52b2NhdGlvbiBvZgo+IHRk YTk5OHhfcHJvYmUoKSwgYW5kIHJlbW92YWwgb2YgdGhlIGNvbXBvbmVudCB3aGVuIHRkYTk5OHhf cmVtb3ZlKCkKPiBpcyBjYWxsZWQuICBUaGUgdGRhOTk4eCBkcml2ZXIgYmVjb21lcyBhIHN0YW5k YXJkIEkyQyBkcml2ZXIuCj4gCj4gVGhpcyBpcyBzb21ldGhpbmcgSSd2ZSBiZWVuIGludGVuZGlu ZyB0byBsb29rIGF0IG5vdyB0aGF0IHRoZSBjb21wb25lbnQKPiBzdHVmZiBpcyBpbiBwbGFjZSAt IGFzIEkgc2FpZCBwcmV2aW91c2x5IHdoZW4gdGhlIHF1ZXN0aW9ucyBhcm91bmQgRFQKPiBhbmQg QXJtYWRhIERSTSB3ZXJlIGZpcnN0IHBvc2VkLCB3ZSBuZWVkIHRvIHNvbHZlIHRoZXNlIGlzc3Vl cyBpbiBhCj4gZ2VuZXJpYyB3YXkgZmlyc3QsIHJhdGhlciB0aGFuIGhhY2tpbmcgYXJvdW5kIHRo ZW0uCgpBZ3JlZS4gSSB3YXMgbG9va2luZyBpbiB0aGUgc2FtZSBkaXJlY3Rpb24uLi4KCi0tIApL ZW4gYXIgYydoZW50YcOxCXwJICAgICAgKiogQnJlaXpoIGhhIExpbnV4IGF0YXYhICoqCkplZgkJ fAkJaHR0cDovL21vaW5lamYuZnJlZS5mci8KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMu ZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0 aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752448AbaBBUHi (ORCPT ); Sun, 2 Feb 2014 15:07:38 -0500 Received: from smtp1-g21.free.fr ([212.27.42.1]:46337 "EHLO smtp1-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752413AbaBBUHh convert rfc822-to-8bit (ORCPT ); Sun, 2 Feb 2014 15:07:37 -0500 Date: Sun, 2 Feb 2014 21:07:54 +0100 From: Jean-Francois Moine To: Russell King - ARM Linux Cc: dri-devel@lists.freedesktop.org, Dave Airlie , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Rob Clark Subject: Re: [PATCH v5 00/23] Message-ID: <20140202210754.307b41e8@armhf> In-Reply-To: <20140202191505.GK26684@n2100.arm.linux.org.uk> References: <20140202124358.GD26684@n2100.arm.linux.org.uk> <20140202190606.6fa193ce@armhf> <20140202182349.GJ26684@n2100.arm.linux.org.uk> <20140202195400.073f4eb4@armhf> <20140202191505.GK26684@n2100.arm.linux.org.uk> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; arm-unknown-linux-gnueabihf) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2 Feb 2014 19:15:05 +0000 Russell King - ARM Linux wrote: > In which case, it may be better to reorder the remaining patches such > that the DT changes are at the very end - which means we can still > benefit from the rest of the patches if the DT solution remains an > open question. > > We do have another option now that my generic component support is in > mainline (merged during this window), which should result in a much > cleaner solution. If we convert TDA998x to a component, armada DRM > to a component master (and same for other tda998x users) then we don't > need the drm_encoder_slave stuff - all that goes away since it's no > longer necessary. > > We also solve this problem as well - because we're then not messing > around with working out if there's a DT node present: the TDA998x > device must pre-exist. For non-DT setups, this can be done when > the I2C bus is created - devices on it would be created using the > standard mechanisms already present via the i2c_board_data array. > For DT setups, the devices are created by parsing the I2C bus node > in DT. > > Both cases result in a component being registered upon invocation of > tda998x_probe(), and removal of the component when tda998x_remove() > is called. The tda998x driver becomes a standard I2C driver. > > This is something I've been intending to look at now that the component > stuff is in place - as I said previously when the questions around DT > and Armada DRM were first posed, we need to solve these issues in a > generic way first, rather than hacking around them. Agree. I was looking in the same direction... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/