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.
> > A
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 no
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 0
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 1
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 s
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 8
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 sp
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, Thierry
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 should
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 d
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 1
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 1
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 8:
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 drm_bridg
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 drm_pa
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 w
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 m
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 c
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 {
> >>> - struc
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 2
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 they
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 they
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&grumpy review.
>>
>> Firs
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
>>> p
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 T
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 poss
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 drm_device
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&grumpy 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 ad
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 enco
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&grumpy review.
>
> First, please make the patch subject more descriptive: I'd expect a helper
> function scaffolding like the v
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 table(
38 matches
Mail list logo
