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 y
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 don
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 cle
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 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 dev
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 :)
>
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
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,
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 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 rel
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)
> >> + exynos_d
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)
>> +exynos_drm_dev_ready(&pdev->dev);
> So we end up with everyone needing a "ready" call
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 (
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 s
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 registratio
15 matches
Mail list logo
