On 01.12.2016 16:12, Daniel Vetter wrote:
> On Thu, Dec 01, 2016 at 02:22:18PM +0100, Andrzej Hajda wrote:
>> On 01.12.2016 08:18, Daniel Vetter wrote:
>>> On Thu, Dec 01, 2016 at 08:07:29AM +0100, Andrzej Hajda wrote:
On 30.11.2016 14:09, Daniel Vetter wrote:
> On Wed, Nov 30, 2016 at
On Thu, Dec 01, 2016 at 02:22:18PM +0100, Andrzej Hajda wrote:
> On 01.12.2016 08:18, Daniel Vetter wrote:
> > On Thu, Dec 01, 2016 at 08:07:29AM +0100, Andrzej Hajda wrote:
> >> On 30.11.2016 14:09, Daniel Vetter wrote:
> >>> On Wed, Nov 30, 2016 at 01:03:20PM +0200, Laurent Pinchart wrote:
>
On 01.12.2016 08:18, Daniel Vetter wrote:
> On Thu, Dec 01, 2016 at 08:07:29AM +0100, Andrzej Hajda wrote:
>> On 30.11.2016 14:09, Daniel Vetter wrote:
>>> On Wed, Nov 30, 2016 at 01:03:20PM +0200, Laurent Pinchart wrote:
On Wednesday 30 Nov 2016 11:55:20 Daniel Vetter wrote:
> Why
On Thu, Dec 01, 2016 at 08:07:29AM +0100, Andrzej Hajda wrote:
> On 30.11.2016 14:09, Daniel Vetter wrote:
> > On Wed, Nov 30, 2016 at 01:03:20PM +0200, Laurent Pinchart wrote:
> >> On Wednesday 30 Nov 2016 11:55:20 Daniel Vetter wrote:
> >>> Why exactly do you want to hotplug encoders? Or bridges
On 30.11.2016 14:09, Daniel Vetter wrote:
> On Wed, Nov 30, 2016 at 01:03:20PM +0200, Laurent Pinchart wrote:
>> On Wednesday 30 Nov 2016 11:55:20 Daniel Vetter wrote:
>>> Why exactly do you want to hotplug encoders? Or bridges fwiw ... since at
>>> least only making those hotpluggable will make
On 30.11.2016 10:39, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Wednesday 30 Nov 2016 10:26:24 Andrzej Hajda wrote:
>> On 30.11.2016 09:16, Laurent Pinchart wrote:
>>> On Wednesday 30 Nov 2016 09:11:56 Andrzej Hajda wrote:
On 29.11.2016 22:12, Jyri Sarha wrote:
> Store the module that
On Wed, Nov 30, 2016 at 01:03:20PM +0200, Laurent Pinchart wrote:
> On Wednesday 30 Nov 2016 11:55:20 Daniel Vetter wrote:
> > Why exactly do you want to hotplug encoders? Or bridges fwiw ... since at
> > least only making those hotpluggable will make the uabi story easier since
> > they're not
Hi Daniel,
On Wednesday 30 Nov 2016 11:55:20 Daniel Vetter wrote:
> On Wed, Nov 30, 2016 at 11:56:25AM +0200, Laurent Pinchart wrote:
> > On Wednesday 30 Nov 2016 10:12:01 Daniel Vetter wrote:
> >> On Wed, Nov 30, 2016 at 10:25:57AM +0200, Laurent Pinchart wrote:
> >>> On Wednesday 30 Nov 2016
Hi Daniel,
On Wednesday 30 Nov 2016 10:12:01 Daniel Vetter wrote:
> On Wed, Nov 30, 2016 at 10:25:57AM +0200, Laurent Pinchart wrote:
> > On Wednesday 30 Nov 2016 09:13:00 Daniel Vetter wrote:
> >> On Wed, Nov 30, 2016 at 12:06:25AM +0200, Laurent Pinchart wrote:
> >>> On Tuesday 29 Nov 2016
On Wed, Nov 30, 2016 at 11:56:25AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 30 Nov 2016 10:12:01 Daniel Vetter wrote:
> > On Wed, Nov 30, 2016 at 10:25:57AM +0200, Laurent Pinchart wrote:
> > > On Wednesday 30 Nov 2016 09:13:00 Daniel Vetter wrote:
> > >> On Wed, Nov 30, 2016
Hi Andrzej,
On Wednesday 30 Nov 2016 10:26:24 Andrzej Hajda wrote:
> On 30.11.2016 09:16, Laurent Pinchart wrote:
> > On Wednesday 30 Nov 2016 09:11:56 Andrzej Hajda wrote:
> >> On 29.11.2016 22:12, Jyri Sarha wrote:
> >>> Store the module that provides the bridge and adjust its refcount
> >>>
Hi Jyri,
On Wednesday 30 Nov 2016 11:13:41 Jyri Sarha wrote:
> On 11/30/16 11:03, Laurent Pinchart wrote:
> >>> This would require combining lookup and attach in all cases. I'm not
> >>> sure
> >>>
> > that would be very convenient for drivers. Keeping the two
> > operations separate
On 11/30/16 11:03, Laurent Pinchart wrote:
>>> This would require combining lookup and attach in all cases. I'm not sure
>>> > > that would be very convenient for drivers. Keeping the two operations
>>> > > separate would be more flexible.
>> >
>> > That could be avoided if of_drm_find_bridge()
Hi Jyri,
On Wednesday 30 Nov 2016 10:55:10 Jyri Sarha wrote:
> On 11/30/16 10:37, Laurent Pinchart wrote:
> >>> To fix this properly I think we need to make the bridge object
> >>> refcounted,
> >>>
> > with a release callback to signal to the bridge driver that memory
> > can be freed.
On 11/30/16 10:37, Laurent Pinchart wrote:
>>> To fix this properly I think we need to make the bridge object refcounted,
>>> > > with a release callback to signal to the bridge driver that memory can
>>> > > be
>>> > > freed. The refcount should be increased in of_drm_find_bridge(), and
>>> > >
Hi Jyri,
On Wednesday 30 Nov 2016 10:32:40 Jyri Sarha wrote:
> On 11/30/16 00:06, Laurent Pinchart wrote:
> >> > /**
> >> > * drm_bridge_remove - remove the given bridge from the global bridge
> >> > list
> >> > @@ -114,6 +118,9 @@ int drm_bridge_attach(struct drm_device *dev,
> >> > struct
On 11/30/16 00:06, Laurent Pinchart wrote:
>> > /**
>> > * drm_bridge_remove - remove the given bridge from the global bridge list
>> > @@ -114,6 +118,9 @@ int drm_bridge_attach(struct drm_device *dev, struct
>> > drm_bridge *bridge) if (bridge->dev)
>> >return -EBUSY;
>> >
>> > +
On 30.11.2016 09:16, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Wednesday 30 Nov 2016 09:11:56 Andrzej Hajda wrote:
>> On 29.11.2016 22:12, Jyri Sarha wrote:
>>> Store the module that provides the bridge and adjust its refcount
>>> accordingly. The bridge module unload should not be allowed
Hi Daniel,
On Wednesday 30 Nov 2016 09:13:00 Daniel Vetter wrote:
> On Wed, Nov 30, 2016 at 12:06:25AM +0200, Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 23:12:56 Jyri Sarha wrote:
> >> Store the module that provides the bridge and adjust its refcount
> >> accordingly. The bridge module
Hi Andrzej,
On Wednesday 30 Nov 2016 09:11:56 Andrzej Hajda wrote:
> On 29.11.2016 22:12, Jyri Sarha wrote:
> > Store the module that provides the bridge and adjust its refcount
> > accordingly. The bridge module unload should not be allowed while the
> > bridge is attached.
>
> Module
On Wed, Nov 30, 2016 at 10:25:57AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 30 Nov 2016 09:13:00 Daniel Vetter wrote:
> > On Wed, Nov 30, 2016 at 12:06:25AM +0200, Laurent Pinchart wrote:
> > > On Tuesday 29 Nov 2016 23:12:56 Jyri Sarha wrote:
> > >> Store the module that
On Wed, Nov 30, 2016 at 12:06:25AM +0200, Laurent Pinchart wrote:
> Hi Jyri,
>
> Thank you for the patch.
>
> On Tuesday 29 Nov 2016 23:12:56 Jyri Sarha wrote:
> > Store the module that provides the bridge and adjust its refcount
> > accordingly. The bridge module unload should not be allowed
On 29.11.2016 22:12, Jyri Sarha wrote:
> Store the module that provides the bridge and adjust its refcount
> accordingly. The bridge module unload should not be allowed while the
> bridge is attached.
Module refcounting as a way of preventing driver from unbinding
is quite popular, but as other
Hi Jyri,
Thank you for the patch.
On Tuesday 29 Nov 2016 23:12:56 Jyri Sarha wrote:
> Store the module that provides the bridge and adjust its refcount
> accordingly. The bridge module unload should not be allowed while the
> bridge is attached.
>
> Signed-off-by: Jyri Sarha
> ---
>
On 11/29/16 23:12, Jyri Sarha wrote:
> @@ -114,6 +118,9 @@ int drm_bridge_attach(struct drm_device *dev, struct
> drm_bridge *bridge)
> if (bridge->dev)
> return -EBUSY;
>
> + if (!try_module_get(bridge->module))
> + return -ENOENT;
> +
> bridge->dev =
Store the module that provides the bridge and adjust its refcount
accordingly. The bridge module unload should not be allowed while the
bridge is attached.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/drm_bridge.c | 15 ---
include/drm/drm_bridge.h | 11 ++-
2 files
26 matches
Mail list logo
