Hi Russell,
Am Montag, den 27.10.2014, 23:57 + schrieb Russell King - ARM Linux:
> On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
> > Looking at the of_drm_find_panel function I actually wonder how that
> > works - the drm_panel doesn't really need to stick around afaics.
> >
On Mon, Nov 3, 2014 at 1:31 PM, Thierry Reding
wrote:
> On Fri, Oct 31, 2014 at 04:51:43PM +0100, Daniel Vetter wrote:
>> On Wed, Oct 29, 2014 at 10:14:37AM +0100, Thierry Reding wrote:
>> > On Wed, Oct 29, 2014 at 09:57:02AM +0100, Daniel Vetter wrote:
>> > > That makes the entire thing a bit
On Mon, Nov 03, 2014 at 09:06:04AM +0100, Thierry Reding wrote:
> On Fri, Oct 31, 2014 at 04:59:40PM +0100, Daniel Vetter wrote:
> > On Wed, Oct 29, 2014 at 10:16:49AM +0100, Thierry Reding wrote:
> > > On Wed, Oct 29, 2014 at 08:51:27AM +0100, Daniel Vetter wrote:
> > > > On Tue, Oct 28, 2014 at
On Fri, Oct 31, 2014 at 04:59:40PM +0100, Daniel Vetter wrote:
> On Wed, Oct 29, 2014 at 10:16:49AM +0100, Thierry Reding wrote:
> > On Wed, Oct 29, 2014 at 08:51:27AM +0100, Daniel Vetter wrote:
> > > On Tue, Oct 28, 2014 at 03:29:47PM +0100, Thierry Reding wrote:
> > > > On Mon, Oct 27, 2014 at
On Fri, Oct 31, 2014 at 04:51:43PM +0100, Daniel Vetter wrote:
> On Wed, Oct 29, 2014 at 10:14:37AM +0100, Thierry Reding wrote:
> > On Wed, Oct 29, 2014 at 09:57:02AM +0100, Daniel Vetter wrote:
> > > That makes the entire thing a bit non-trivial, which is why I think it
> > > would be better as
On Wed, Oct 29, 2014 at 10:09:04AM +0100, Andrzej Hajda wrote:
> On 10/29/2014 08:58 AM, Daniel Vetter wrote:
> > On Tue, Oct 28, 2014 at 04:05:34PM +0100, Thierry Reding wrote:
> >> On Tue, Oct 28, 2014 at 08:16:44PM +0530, Ajay kumar wrote:
> >>> On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding
>
On Wed, Oct 29, 2014 at 10:16:49AM +0100, Thierry Reding wrote:
> On Wed, Oct 29, 2014 at 08:51:27AM +0100, Daniel Vetter wrote:
> > On Tue, Oct 28, 2014 at 03:29:47PM +0100, Thierry Reding wrote:
> > > On Mon, Oct 27, 2014 at 11:20:31PM +0100, Daniel Vetter wrote:
> > > > On Mon, Oct 27, 2014 at
On Thu, Oct 30, 2014 at 10:09:28AM +, Russell King - ARM Linux wrote:
> On Thu, Oct 30, 2014 at 11:01:02AM +0100, Andrzej Hajda wrote:
> > On 10/29/2014 10:14 AM, Thierry Reding wrote:
> > > On Wed, Oct 29, 2014 at 09:57:02AM +0100, Daniel Vetter wrote:
> > >> I think we nee try_get_module for
On Wed, Oct 29, 2014 at 10:14:37AM +0100, Thierry Reding wrote:
> On Wed, Oct 29, 2014 at 09:57:02AM +0100, Daniel Vetter wrote:
> > That makes the entire thing a bit non-trivial, which is why I think it
> > would be better as some generic helper. Which then gets embedded or
> > instantiated for
On 10/29/2014 10:14 AM, Thierry Reding wrote:
> On Wed, Oct 29, 2014 at 09:57:02AM +0100, Daniel Vetter wrote:
>> On Wed, Oct 29, 2014 at 09:38:23AM +0100, Thierry Reding wrote:
>>> On Wed, Oct 29, 2014 at 08:43:14AM +0100, Daniel Vetter wrote:
On Tue, Oct 28, 2014 at 03:35:50PM +0100,
On Thu, Oct 30, 2014 at 11:01:02AM +0100, Andrzej Hajda wrote:
> On 10/29/2014 10:14 AM, Thierry Reding wrote:
> > On Wed, Oct 29, 2014 at 09:57:02AM +0100, Daniel Vetter wrote:
> >> I think we nee try_get_module for the code and kref on the actual data
> >> structures.
> >
> > Agreed, that
On Wed, Oct 29, 2014 at 08:51:27AM +0100, Daniel Vetter wrote:
> On Tue, Oct 28, 2014 at 03:29:47PM +0100, Thierry Reding wrote:
> > On Mon, Oct 27, 2014 at 11:20:31PM +0100, Daniel Vetter wrote:
> > > On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul
> > > wrote:
> > > >>> @@ -660,8 +662,11 @@ struct
On Wed, Oct 29, 2014 at 09:57:02AM +0100, Daniel Vetter wrote:
> On Wed, Oct 29, 2014 at 09:38:23AM +0100, Thierry Reding wrote:
> > On Wed, Oct 29, 2014 at 08:43:14AM +0100, Daniel Vetter wrote:
> > > On Tue, Oct 28, 2014 at 03:35:50PM +0100, Thierry Reding wrote:
> > > > On Mon, Oct 27, 2014 at
On 10/29/2014 08:58 AM, Daniel Vetter wrote:
> On Tue, Oct 28, 2014 at 04:05:34PM +0100, Thierry Reding wrote:
>> On Tue, Oct 28, 2014 at 08:16:44PM +0530, Ajay kumar wrote:
>>> On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding
>>> wrote:
On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter
On Wed, Oct 29, 2014 at 09:38:23AM +0100, Thierry Reding wrote:
> On Wed, Oct 29, 2014 at 08:43:14AM +0100, Daniel Vetter wrote:
> > On Tue, Oct 28, 2014 at 03:35:50PM +0100, Thierry Reding wrote:
> > > On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
> > > > On Mon, Oct 27, 2014 at
On Wed, Oct 29, 2014 at 08:43:14AM +0100, Daniel Vetter wrote:
> On Tue, Oct 28, 2014 at 03:35:50PM +0100, Thierry Reding wrote:
> > On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
> > > On Mon, Oct 27, 2014 at 11:20 PM, Daniel Vetter
> > > wrote:
> > > > On Mon, Oct 27, 2014 at
On Tue, Oct 28, 2014 at 04:05:34PM +0100, Thierry Reding wrote:
> On Tue, Oct 28, 2014 at 08:16:44PM +0530, Ajay kumar wrote:
> > On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding
> > wrote:
> > > On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter wrote:
> > >> On Tue, Oct 28, 2014 at 1:28 PM,
On Tue, Oct 28, 2014 at 03:29:47PM +0100, Thierry Reding wrote:
> On Mon, Oct 27, 2014 at 11:20:31PM +0100, Daniel Vetter wrote:
> > On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul wrote:
> > >>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
> > >>> * @driver_private: pointer to the bridge driver's
On Tue, Oct 28, 2014 at 03:35:50PM +0100, Thierry Reding wrote:
> On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
> > On Mon, Oct 27, 2014 at 11:20 PM, Daniel Vetter wrote:
> > > On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul
> > > wrote:
> > @@ -660,8 +662,11 @@ struct
On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding
wrote:
> On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter wrote:
>> On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote:
>> > On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote:
> [...]
>> >> Hm, if you do this can you pls also update
On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote:
> On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar wrote:
>> Hi Daniel and Sean,
>>
>> Thanks for the comments!
>>
>> On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul wrote:
>>> On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter wrote:
So don't ask
On Tue, Oct 28, 2014 at 08:16:44PM +0530, Ajay kumar wrote:
> On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding
> wrote:
> > On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter wrote:
> >> On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote:
> >> > On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter
On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter wrote:
> On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote:
> > On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote:
[...]
> >> Hm, if you do this can you pls also update drm_panel accordingly? It
> >> shouldn't be a lot of fuzz and would
On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
> On Mon, Oct 27, 2014 at 11:20 PM, Daniel Vetter wrote:
> > On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul wrote:
> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
> * @driver_private: pointer to the bridge driver's internal
On Mon, Oct 27, 2014 at 11:20:31PM +0100, Daniel Vetter wrote:
> On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul wrote:
> >>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
> >>> * @driver_private: pointer to the bridge driver's internal context
> >>> */
> >>> struct drm_bridge {
> >>> -
On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote:
> On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote:
>> On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar wrote:
>>> Hi Daniel and Sean,
>>>
>>> Thanks for the comments!
>>>
>>> On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul wrote:
On Mon, Oct
On Tue, Oct 28, 2014 at 1:41 AM, Sean Paul wrote:
> On Wed, Aug 27, 2014 at 10:29 AM, Ajay Kumar
> wrote:
>> A set of helper functions are defined in this patch to make
>> bridge driver probe independent of the drm flow.
>>
>> The bridge devices register themselves on a lookup table
>> when
On Tue, Oct 28, 2014 at 1:41 AM, Sean Paul wrote:
> On Wed, Aug 27, 2014 at 10:29 AM, Ajay Kumar
> wrote:
>> A set of helper functions are defined in this patch to make
>> bridge driver probe independent of the drm flow.
>>
>> The bridge devices register themselves on a lookup table
>> when
Hi Daniel and Sean,
Thanks for the comments!
On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul wrote:
> On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter wrote:
>> So don't ask why but I accidentally ended up in a branch looking at this
>> patch and didn't like it. So very quick review.
>>
>> First,
On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar wrote:
> Hi Daniel and Sean,
>
> Thanks for the comments!
>
> On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul wrote:
>> On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter wrote:
>>> So don't ask why but I accidentally ended up in a branch looking at this
>>>
On Tue, Oct 28, 2014 at 10:19 AM, Daniel Vetter wrote:
> On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote:
>> On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote:
>>> On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar wrote:
Hi Daniel and Sean,
Thanks for the comments!
On
On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
> Looking at the of_drm_find_panel function I actually wonder how that
> works - the drm_panel doesn't really need to stick around afaics.
> After all panel_list is global so some other driver can unload.
> Russell's of support for
On Mon, Oct 27, 2014 at 11:20 PM, Daniel Vetter wrote:
> On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul wrote:
@@ -660,8 +662,11 @@ struct drm_bridge_funcs {
* @driver_private: pointer to the bridge driver's internal context
*/
struct drm_bridge {
- struct
On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul wrote:
>>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
>>> * @driver_private: pointer to the bridge driver's internal context
>>> */
>>> struct drm_bridge {
>>> - struct drm_device *dev;
>>> + struct device *dev;
>>
>> Please don't rename
So don't ask why but I accidentally ended up in a branch looking at this
patch and didn't like it. So very quick review.
First, please make the patch subject more descriptive: I'd expect a helper
function scaffolding like the various crtc/probe/dp ... helpers we already
have. You instead add code
On Wed, Aug 27, 2014 at 10:29 AM, Ajay Kumar
wrote:
> A set of helper functions are defined in this patch to make
> bridge driver probe independent of the drm flow.
>
> The bridge devices register themselves on a lookup table
> when they get probed by calling "drm_bridge_add".
>
> The parent
On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter wrote:
> So don't ask why but I accidentally ended up in a branch looking at this
> patch and didn't like it. So very quick review.
>
> First, please make the patch subject more descriptive: I'd expect a helper
> function scaffolding like the various
A set of helper functions are defined in this patch to make
bridge driver probe independent of the drm flow.
The bridge devices register themselves on a lookup table
when they get probed by calling "drm_bridge_add".
The parent encoder driver waits till the bridge is available
in the lookup
38 matches
Mail list logo
