On Fri, Apr 25, 2014 at 04:36:01PM +0200, Andrzej Hajda wrote:
On 04/23/2014 07:13 PM, Russell King - ARM Linux wrote:
Let me be absolutely clear *why* I'm very interested in this - and that
is because I'm presently converting TDA998x and Armada DRM to use the
component helpers. If your
On 04/23/2014 07:13 PM, Russell King - ARM Linux wrote:
On Wed, Apr 23, 2014 at 05:43:28PM +0100, Russell King - ARM Linux wrote:
So, maybe you would like to finally address *my* point about TDA998x
and your solution in a way that provides a satisfactory answer. *Show*
how it can be done, or
On 04/22/2014 01:51 PM, Russell King - ARM Linux wrote:
On Tue, Apr 22, 2014 at 01:29:54PM +0200, Andrzej Hajda wrote:
On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote:
On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
Separation of the interfaces exposed by the device from
On Wed, Apr 23, 2014 at 05:04:46PM +0200, Andrzej Hajda wrote:
On 04/22/2014 01:51 PM, Russell King - ARM Linux wrote:
Yes, I know that you're desperate to play that down, but you can't get
Not true. I only try to find the best solution and the approach with
multiple re-probing just to
On Wed, Apr 23, 2014 at 05:43:28PM +0100, Russell King - ARM Linux wrote:
So, maybe you would like to finally address *my* point about TDA998x
and your solution in a way that provides a satisfactory answer. *Show*
how it can be done, or *outline* how it can be done.
Let me be absolutely clear
Hi Russel,
My answer little bit later due to Easter.
On 04/18/2014 02:42 PM, Russell King - ARM Linux wrote:
On Fri, Apr 18, 2014 at 01:27:53PM +0200, Andrzej Hajda wrote:
Hi Russel,
Thanks for comments.
On 04/17/2014 11:47 PM, Russell King - ARM Linux wrote:
On Thu, Apr 17, 2014 at
On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote:
On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
Separation of the interfaces exposed by the device from the device itself
seems to me a good thing. I would even consider it as a biggest
advantage of this solution :)
The
On Tue, Apr 22, 2014 at 01:29:54PM +0200, Andrzej Hajda wrote:
On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote:
On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
Separation of the interfaces exposed by the device from the device itself
seems to me a good thing. I would
On 04/18/2014 12:04 AM, Russell King - ARM Linux wrote:
On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote:
+static int exynos_drm_add_blocker(struct device *dev, void *data)
+{
+struct device_driver *drv = data;
+
+if (!platform_bus_type.match(dev, drv))
+
On Fri, Apr 18, 2014 at 01:27:53PM +0200, Andrzej Hajda wrote:
Hi Russel,
Thanks for comments.
On 04/17/2014 11:47 PM, Russell King - ARM Linux wrote:
On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote:
+out:
+ if (ret != -EPROBE_DEFER)
+
On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
Separation of the interfaces exposed by the device from the device itself
seems to me a good thing. I would even consider it as a biggest
advantage of this solution :)
The problem of re-initialization does not seems to be
exynos_drm is composed from multiple devices which provides different
interfaces. To properly start/stop drm master device it should track
readiness of all its components. This patch uses pending_components
framework to perform this task.
On module initialization before component driver
On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote:
+out:
+ if (ret != -EPROBE_DEFER)
+ exynos_drm_dev_ready(pdev-dev);
So we end up with everyone needing a ready call in each sub-driver
back into the main driver... this makes it impossible to write a
generic
On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote:
+static int exynos_drm_add_blocker(struct device *dev, void *data)
+{
+ struct device_driver *drv = data;
+
+ if (!platform_bus_type.match(dev, drv))
+ return 0;
+
+ device_lock(dev);
+ if
14 matches
Mail list logo
