On Thu, 24 Dec 2015 12:36:10 +
Russell King - ARM Linux wrote:
> It seems that you're trying to work around a limitation in Linux by
> modifying the hardware representation...
Sorry to come back to this topic, but I think you are wrong.
Looking at the imx6 DTs, the problem comes from the
On Thu, 24 Dec 2015 10:52:07 +
Russell King - ARM Linux wrote:
> On Thu, Dec 24, 2015 at 09:15:28AM +0100, Jean-Francois Moine wrote:
> > Well, two topics:
> >
> > - adding a second 'of_compare' function complexifies the code
> > and people may wonder why such a function is needed and
On Thu, Dec 24, 2015 at 01:27:08PM +0100, Jean-Francois Moine wrote:
> On Thu, 24 Dec 2015 10:52:07 +
> Russell King - ARM Linux wrote:
> > However, when we come to the Linux implementation, things get sticky
> > because we need to select the correct platform device corresponding
> > with the
On Thu, Dec 24, 2015 at 09:15:28AM +0100, Jean-Francois Moine wrote:
> On Wed, 23 Dec 2015 18:59:48 +
> Russell King - ARM Linux wrote:
>
> > > > Have a look at my v2 where I've introduced two compare functions and
> > > > also
> > > > modified the Rockchip compare_port() to use
On Wed, 23 Dec 2015 18:59:48 +
Russell King - ARM Linux wrote:
> > > Have a look at my v2 where I've introduced two compare functions and also
> > > modified the Rockchip compare_port() to use port->parent in the
> > > comparison. I
> > > guess that should solve your problem.
> >
> >
On Wed, Dec 23, 2015 at 06:20:33PM +0100, Jean-Francois Moine wrote:
> On Wed, 23 Dec 2015 10:05:34 +
> Liviu Dudau wrote:
>
> > > What was the reason to keep the "ports" node instead of the device?
> >
> > The function is an extract of common code sprinkled through a few DRM
> > drivers,
On Wed, 23 Dec 2015 10:05:34 +
Liviu Dudau wrote:
> > What was the reason to keep the "ports" node instead of the device?
>
> The function is an extract of common code sprinkled through a few DRM drivers,
> they all used port rather than port->parent.
Sorry for I could find such drivers.
On 23 December 2015 at 03:38, Liviu Dudau wrote:
> On Fri, Nov 20, 2015 at 02:22:03PM +, Liviu Dudau wrote:
>> Hello,
>>
>> This is v2 of the patchset trying to make drm_of_component_probe() cope with
>> finding
>> both local crtc ports and remote encoder ones. Heiko Stübner was nice
>>
On Tue, 22 Dec 2015 17:38:00 +
Liviu Dudau wrote:
> On Fri, Nov 20, 2015 at 02:22:03PM +, Liviu Dudau wrote:
> > Hello,
> >
> > This is v2 of the patchset trying to make drm_of_component_probe() cope
> > with finding
> > both local crtc ports and remote encoder ones. Heiko Stübner was
On Wed, Dec 23, 2015 at 10:39:06AM +0100, Jean-Francois Moine wrote:
> On Tue, 22 Dec 2015 17:38:00 +
> Liviu Dudau wrote:
>
> > On Fri, Nov 20, 2015 at 02:22:03PM +, Liviu Dudau wrote:
> > > Hello,
> > >
> > > This is v2 of the patchset trying to make drm_of_component_probe() cope
> >
On Fri, Nov 20, 2015 at 02:22:03PM +, Liviu Dudau wrote:
> Hello,
>
> This is v2 of the patchset trying to make drm_of_component_probe() cope with
> finding
> both local crtc ports and remote encoder ones. Heiko Stübner was nice enough
> to test
> an earlier version that was patched
Hi Dave,
Am Freitag, 20. November 2015, 14:22:03 schrieb Liviu Dudau:
> This is v2 of the patchset trying to make drm_of_component_probe() cope with
> finding both local crtc ports and remote encoder ones. Heiko Stübner was
> nice enough to test an earlier version that was patched following
Am Freitag, 20. November 2015, 14:22:03 schrieb Liviu Dudau:
> Hello,
>
> This is v2 of the patchset trying to make drm_of_component_probe() cope with
> finding both local crtc ports and remote encoder ones. Heiko Stübner was
> nice enough to test an earlier version that was patched following
Hello,
This is v2 of the patchset trying to make drm_of_component_probe() cope with
finding
both local crtc ports and remote encoder ones. Heiko Stübner was nice enough
to test
an earlier version that was patched following Russell's suggestions on rk3288,
but
I haven't seen any reports from
14 matches
Mail list logo
