> -Original Message-
> From: Sean Paul [mailto:seanpaul at chromium.org]
> Sent: Tuesday, November 05, 2013 12:44 AM
> To: Inki Dae
> Cc: Thierry Reding; Laurent Pinchart; dri-devel; Sylwester Nawrocki;
> St?phane Marchesin
> Subject: Re: [PATCH v2 12/26] drm/
2013/11/4 Thierry Reding :
> On Tue, Oct 29, 2013 at 08:46:03PM -0700, St?phane Marchesin wrote:
>> On Tue, Oct 29, 2013 at 1:50 PM, Tomasz Figa
>> wrote:
>>
>> > Hi Sean,
>> >
>> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
>> > > On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa
>> > w
On Mon, Nov 04, 2013 at 01:52:33PM +0100, Thierry Reding wrote:
> On Mon, Nov 04, 2013 at 07:14:27AM -0500, Rob Clark wrote:
> > On Mon, Nov 4, 2013 at 5:10 AM, Thierry Reding > gmail.com> wrote:
> > > On Tue, Oct 29, 2013 at 05:29:55PM -0400, Rob Clark wrote:
> > >> On Tue, Oct 29, 2013 at 4:50 P
On Mon, Nov 04, 2013 at 07:14:27AM -0500, Rob Clark wrote:
> On Mon, Nov 4, 2013 at 5:10 AM, Thierry Reding
> wrote:
> > On Tue, Oct 29, 2013 at 05:29:55PM -0400, Rob Clark wrote:
> >> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa
> >> wrote:
> > [...]
> >> > I believe this is a huge step backwa
On Wed, Oct 30, 2013 at 11:32:24AM -0400, Sean Paul wrote:
> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
> > Hi Sean,
> >
> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
> >> On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa
> > wrote:
> >> > Hi,
> >> >
> >> > On Wednesday 23 of Oc
On Tue, Oct 29, 2013 at 08:46:03PM -0700, St?phane Marchesin wrote:
> On Tue, Oct 29, 2013 at 1:50 PM, Tomasz Figa wrote:
>
> > Hi Sean,
> >
> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
> > > On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa
> > wrote:
> > > > Hi,
> > > >
> > > > On We
On Wed, Oct 30, 2013 at 12:32:11AM +0100, Laurent Pinchart wrote:
> Hello,
>
> On Tuesday 29 October 2013 17:29:55 Rob Clark wrote:
> > On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
> > > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
> > > > On Mon, Oct 28, 2013 at 7:13 PM, Tomasz
Hi Daniel,
On Wednesday 30 October 2013 16:53:22 Daniel Vetter wrote:
> On Wed, Oct 30, 2013 at 4:32 PM, Sean Paul wrote:
> > Once all required nodes have been "claimed", the main driver's probe
> > would call drm_platform/pci_init to kick off load(). After load() has
> > finished, the drm layer
Hi Sean,
Sorry for the late reply.
On Wednesday 30 October 2013 11:56:18 Sean Paul wrote:
> On Wed, Oct 30, 2013 at 11:45 AM, Laurent Pinchart wrote:
> > On Wednesday 30 October 2013 11:32:24 Sean Paul wrote:
> >> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
> >> > On Tuesday 29 of October
On Tue, Oct 29, 2013 at 05:29:55PM -0400, Rob Clark wrote:
> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
[...]
> > I believe this is a huge step backwards from current kernel design
> > standards, which prefer modularity.
>
> But it makes things behave in the way that userspace expects, w
On Wed, Oct 23, 2013 at 04:22:11PM +0100, Dave Airlie wrote:
> On Wed, Oct 23, 2013 at 3:45 PM, Sean Paul wrote:
> > On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote:
> >>> As I mentioned earlier, display_ops is needed to have no any
> >>> dependency of drm framework directly like below,
> >>>
On Mon, Nov 4, 2013 at 6:30 AM, Inki Dae wrote:
> 2013/11/4 Thierry Reding :
>> On Tue, Oct 29, 2013 at 08:46:03PM -0700, St?phane Marchesin wrote:
>>> On Tue, Oct 29, 2013 at 1:50 PM, Tomasz Figa
>>> wrote:
>>>
>>> > Hi Sean,
>>> >
>>> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
>
On Mon, Nov 4, 2013 at 5:10 AM, Thierry Reding
wrote:
> On Tue, Oct 29, 2013 at 05:29:55PM -0400, Rob Clark wrote:
>> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa
>> wrote:
> [...]
>> > I believe this is a huge step backwards from current kernel design
>> > standards, which prefer modularity.
>
On Wed, Oct 30, 2013 at 4:32 PM, Sean Paul wrote:
> Once all required nodes have been "claimed", the main driver's probe
> would call drm_platform/pci_init to kick off load(). After load() has
> finished, the drm layer would then call the various standalone driver
> hooks that were previously regi
On Wednesday 30 October 2013 11:32:24 Sean Paul wrote:
> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
[snip]
> >> An example: exynos_drm_drv would be a platform_driver which implements
> >> drm_driver. On drm_load, it would enumer
On Wed, Oct 30, 2013 at 11:45 AM, Laurent Pinchart
wrote:
> On Wednesday 30 October 2013 11:32:24 Sean Paul wrote:
>> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
>> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
>
> [snip]
>
>> >> An example: exynos_drm_drv would be a platform_d
On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
> Hi Sean,
>
> On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
>> On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa
> wrote:
>> > Hi,
>> >
>> > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
>> >> On Wed, Oct 23, 2013 at 11:53 AM,
Hello,
On Tuesday 29 October 2013 17:29:55 Rob Clark wrote:
> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
> > > On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa wrote:
> >> > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
>
Hello,
On Tuesday 29 October 2013 20:47:44 Sylwester Nawrocki wrote:
> On 29/10/13 20:23, Tomasz Figa wrote:
> > On Tuesday 29 of October 2013 12:19:35 Olof Johansson wrote:
> > > It's a very deeply nested structure, I'm not sure there's a need to
> > > make a ports {} subnode really.
Agreed, thi
Hi Sean,
On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
> On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa
wrote:
> > Hi,
> >
> > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
> >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie
wrote:
> >> > I think we need to start consid
Hi,
On 29/10/13 20:23, Tomasz Figa wrote:
>> It's a very deeply nested structure, I'm not sure there's a need to
>> > make a ports {} subnode really.
>> >
>> > Also, I don't know if it makes sense to always name it
>> > remote-endpoint, or to use a more flexible name depending on what is
>> > act
On Tue, Oct 29, 2013 at 1:50 PM, Tomasz Figa wrote:
> Hi Sean,
>
> On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
> > On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa
> wrote:
> > > Hi,
> > >
> > > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
> > >> On Wed, Oct 23, 2013 at 11:5
On Tuesday 29 of October 2013 12:19:35 Olof Johansson wrote:
> On Mon, Oct 28, 2013 at 4:13 PM, Tomasz Figa
wrote:
> > Hi,
> >
> > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
> >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie
wrote:
> >> > I think we need to start considering
On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
> Hi Sean,
>
> On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
>> On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa
> wrote:
>> > Hi,
>> >
>> > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
>> >> On Wed, Oct 23, 2013 at 11:53 AM,
On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa wrote:
> Hi,
>
> On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
>> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote:
>> > I think we need to start considering a framework where subdrivers
>> > just
>> > add drm objects themsel
On Mon, Oct 28, 2013 at 4:13 PM, Tomasz Figa wrote:
> Hi,
>
> On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
>> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote:
>> > I think we need to start considering a framework where subdrivers
>> > just
>> > add drm objects themsel
Hi,
On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote:
> > I think we need to start considering a framework where subdrivers
> > just
> > add drm objects themselves, then the toplevel node is responsible
> > for
> >
On Thu, Oct 24, 2013 at 3:46 AM, Inki Dae wrote:
> 2013/10/23 Rob Clark :
>> On Wed, Oct 23, 2013 at 9:18 AM, Inki Dae wrote:
>>> Look at omapdrm, nouveau, and radeon drm drivers.
>>
>>
>> btw, please don't look at omapdrm as a "good" example in this regard.
>> The layering is really not a good i
On Mon, Oct 28, 2013 at 12:49 PM, Olof Johansson wrote:
> On Wed, Oct 23, 2013 at 9:09 AM, Sean Paul wrote:
>> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote:
>>>
>>> I think we need to start considering a framework where subdrivers just
>>> add drm objects themselves,
On Wed, Oct 23, 2013 at 9:09 AM, Sean Paul wrote:
> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote:
>>>
>>
>> I think we need to start considering a framework where subdrivers just
>> add drm objects themselves, then the toplevel node is responsible for
>> knowing that ev
Sorry for some typos.
2013/10/24 Inki Dae :
> 2013/10/23 Rob Clark :
>> On Wed, Oct 23, 2013 at 9:18 AM, Inki Dae wrote:
>>> Look at omapdrm, nouveau, and radeon drm drivers.
>>
>>
>> btw, please don't look at omapdrm as a "good" example in this regard.
>> The layering is really not a good idea a
2013/10/23 Rob Clark :
> On Wed, Oct 23, 2013 at 9:18 AM, Inki Dae wrote:
>> Look at omapdrm, nouveau, and radeon drm drivers.
>
>
> btw, please don't look at omapdrm as a "good" example in this regard.
> The layering is really not a good idea and for a long time caused a
> lot of problems, which
2013/10/23 Sean Paul :
> On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote:
>>> As I mentioned earlier, display_ops is needed to have no any
>>> dependency of drm framework directly like below,
>>>
>>> DRM Framework
>>>
> On Tue, Oct 22, 2013 at 7:28 PM, Inki Dae
>>>>>> >> > wrote:
>>>>>> >> >>
>>>>>> >> >> 2013/10/22 Sean Paul :
>>>>>> >> >> > On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae >>>&g
>
I think we need to start considering a framework where subdrivers just
add drm objects themselves, then the toplevel node is responsible for
knowing that everything for the current configuration is loaded.
>>>
>>> It would be nice to specify the various pieces in dt,
On Wed, Oct 23, 2013 at 3:45 PM, Sean Paul wrote:
> On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote:
>>> As I mentioned earlier, display_ops is needed to have no any
>>> dependency of drm framework directly like below,
>>>
>>> DRM Framework
>>>
> As I mentioned earlier, display_ops is needed to have no any
> dependency of drm framework directly like below,
>
> DRM Framework
>|
> Exynos DRM Framework
>
t 1:30 AM, Inki Dae
>>>> >> >> > wrote:
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>> -Original Message-
>>>> >> >> >>> From: Se
2013/10/22 Inki Dae :
> 2013/10/17 Sean Paul :
>> This patch splits display and manager from subdrv. The result is that
>> crtc functions can directly call into manager callbacks and encoder
>> functions can directly call into display callbacks. This will allow
>> us to remove the exynos_drm_hdmi s
; On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae
>> >> >> > wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >>> -Original Message-
>> >> >> >>> From: Sean Paul [mailto:seanp
gt; >> >>> manager/display/subdrv
>> >> >>>
>> >> >>> On Mon, Oct 21, 2013 at 10:46 AM, Sean Paul
>> >> >>> wrote:
>> >> >>> > On Thu, Oct 17, 2013 at 10:31 PM, Inki Dae
>> >> >
gt; >>> From: Sean Paul [mailto:seanpaul at chromium.org]
>> >>> Sent: Tuesday, October 22, 2013 6:18 AM
>> >>> To: Inki Dae
>> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
>> >>> Subject: Re: [PATCH v2 12/26] dr
On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote:
>>
>
> I think we need to start considering a framework where subdrivers just
> add drm objects themselves, then the toplevel node is responsible for
> knowing that everything for the current configuration is loaded.
>
>>
Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
>>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
>>>
>>> On Mon, Oct 21, 2013 at 10:46 AM, Sean Paul
>>> wrote:
>>> > On Thu, Oct 17, 2013 at 10:31 PM, Inki Dae
On Wed, Oct 23, 2013 at 11:27 AM, Sean Paul wrote:
> On Wed, Oct 23, 2013 at 11:22 AM, Dave Airlie wrote:
>> On Wed, Oct 23, 2013 at 3:45 PM, Sean Paul wrote:
>>> On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote:
> As I mentioned earlier, display_ops is needed to have no any
> depend
On Wed, Oct 23, 2013 at 11:22 AM, Dave Airlie wrote:
> On Wed, Oct 23, 2013 at 3:45 PM, Sean Paul wrote:
>> On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote:
As I mentioned earlier, display_ops is needed to have no any
dependency of drm framework directly like below,
On Wed, Oct 23, 2013 at 11:22 AM, Dave Airlie wrote:
> On Wed, Oct 23, 2013 at 3:45 PM, Sean Paul wrote:
>> On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote:
As I mentioned earlier, display_ops is needed to have no any
dependency of drm framework directly like below,
On Wed, Oct 23, 2013 at 9:18 AM, Inki Dae wrote:
> Look at omapdrm, nouveau, and radeon drm drivers.
btw, please don't look at omapdrm as a "good" example in this regard.
The layering is really not a good idea and for a long time caused a
lot of problems, which we essentially solved by bypassing
On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote:
>> As I mentioned earlier, display_ops is needed to have no any
>> dependency of drm framework directly like below,
>>
>> DRM Framework
>>|
>>
> >>
>>>>> >> >> 2013/10/22 Sean Paul :
>>>>> >> >> > On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae >>>> >> >> > samsung.com>
>>>>> >> >> > wrote:
>>>>> >
> >> >> >>> >>> From: Sean Paul [mailto:seanpaul at chromium.org]
>>> >> >> >>> >>> Sent: Thursday, October 17, 2013 11:37 PM
>>> >> >> >>> >>> To: Inki Dae
>>>
nt: Tuesday, October 22, 2013 6:18 AM
>>>> To: Inki Dae
>>>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
>>>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
>>>>
>>>>
t; >>
> >> >> >>> -Original Message-
> >> >> >>> From: Sean Paul [mailto:seanpaul at chromium.org]
> >> >> >>> Sent: Tuesday, October 22, 2013 6:18 AM
> >> >> >>> To: Inki Dae
> >>
> wrote:
> >> >>
> >> >>
> >> >>> -Original Message-
> >> >>> From: Sean Paul [mailto:seanpaul at chromium.org]
> >> >>> Sent: Tuesday, October 22, 2013 6:18 AM
> >> >>> To: Inki Dae
> >
> Sent: Tuesday, October 22, 2013 6:18 AM
> >>> To: Inki Dae
> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
> >>>
> >
2013/10/17 Sean Paul :
> This patch splits display and manager from subdrv. The result is that
> crtc functions can directly call into manager callbacks and encoder
> functions can directly call into display callbacks. This will allow
> us to remove the exynos_drm_hdmi shim and support mixer/hdmi &
> -Original Message-
> From: Sean Paul [mailto:seanpaul at chromium.org]
> Sent: Tuesday, October 22, 2013 6:18 AM
> To: Inki Dae
> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
&
> -Original Message-
> From: Sean Paul [mailto:seanpaul at chromium.org]
> Sent: Monday, October 21, 2013 11:47 PM
> To: Inki Dae
> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
&
;> >>> From: Sean Paul [mailto:seanpaul at chromium.org]
>> >>> Sent: Thursday, October 17, 2013 11:37 PM
>> >>> To: Inki Dae
>> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
>> >>> Subject:
To: Inki Dae
>>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
>>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
>>>
>>> On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae wrote:
>>> >
>>> >
>>> >&g
>> Sent: Thursday, October 17, 2013 4:27 AM
>> >> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
>> >> Cc: airlied at linux.ie; tomasz.figa at gmail.com; marcheu at
>> >> chromium.org; Sean
>> >> Paul
>> >> Subje
> -Original Message-
> From: Sean Paul [mailto:seanpaul at chromium.org]
> Sent: Thursday, October 17, 2013 11:37 PM
> To: Inki Dae
> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
&
n
> Paul
> Subject: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
>
> This patch splits display and manager from subdrv. The result is that
> crtc functions can directly call into manager callbacks and encoder
> functions can directly call into display callbacks
airlied at linux.ie; tomasz.figa at gmail.com; marcheu at chromium.org;
>> Sean
>> Paul
>> Subject: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
>>
>> This patch splits display and manager from subdrv. The result is that
>> crtc functions can directly cal
This patch splits display and manager from subdrv. The result is that
crtc functions can directly call into manager callbacks and encoder
functions can directly call into display callbacks. This will allow
us to remove the exynos_drm_hdmi shim and support mixer/hdmi & fimd/dp
with common code.
Sig
65 matches
Mail list logo
