On Mon, Sep 26, 2011 at 8:55 AM, Konrad Rzeszutek Wilk
wrote:
>> I'm a bit undecided on some of this error handling at startup.. ?I
>> guess ENOMEM is clear enough. ?But some of the other parts, like
>> connector initialization, could fail just because some hw is not
>> present/populated. ?Like mi
On Mon, Sep 26, 2011 at 8:55 AM, Konrad Rzeszutek Wilk
wrote:
>> I'm a bit undecided on some of this error handling at startup.. I
>> guess ENOMEM is clear enough. But some of the other parts, like
>> connector initialization, could fail just because some hw is not
>> present/populated. Like mi
On Mon, Sep 26, 2011 at 09:55:44AM -0400, Konrad Rzeszutek Wilk wrote:
> > >> + ? ? commit(crtc);
> > >
> > > So no checking of its return value.. Should you at least wrap
> > > it with WARN_ON(?)
> >
> > Is it safe to rely on the "payload" of the WARN_ON() always being
> > evaluated, or is there
On Mon, Sep 26, 2011 at 09:55:44AM -0400, Konrad Rzeszutek Wilk wrote:
> > >> + commit(crtc);
> > >
> > > So no checking of its return value.. Should you at least wrap
> > > it with WARN_ON(?)
> >
> > Is it safe to rely on the "payload" of the WARN_ON() always being
> > evaluated, or is there
> >> + ? ? commit(crtc);
> >
> > So no checking of its return value.. Should you at least wrap
> > it with WARN_ON(?)
>
> Is it safe to rely on the "payload" of the WARN_ON() always being
> evaluated, or is there any scenario that you could have something like
Hmm, good question. I assumed so, bu
> >> + commit(crtc);
> >
> > So no checking of its return value.. Should you at least wrap
> > it with WARN_ON(?)
>
> Is it safe to rely on the "payload" of the WARN_ON() always being
> evaluated, or is there any scenario that you could have something like
Hmm, good question. I assumed so, bu
On Wed, Sep 21, 2011 at 5:32 PM, Konrad Rzeszutek Wilk
wrote:
> So I did a cursory look and stopped at omap_drv.h
> due to the lack of time.
>
> Some comments below.
>
>> +++ b/drivers/staging/omapdrm/Kconfig
>> @@ -0,0 +1,24 @@
>> +
>> +config DRM_OMAP
>> + ? ? tristate "OMAP DRM (EXPERIMENTAL)"
On Wed, Sep 21, 2011 at 5:32 PM, Konrad Rzeszutek Wilk
wrote:
> So I did a cursory look and stopped at omap_drv.h
> due to the lack of time.
>
> Some comments below.
>
>> +++ b/drivers/staging/omapdrm/Kconfig
>> @@ -0,0 +1,24 @@
>> +
>> +config DRM_OMAP
>> + tristate "OMAP DRM (EXPERIMENTAL)"
So I did a cursory look and stopped at omap_drv.h
due to the lack of time.
Some comments below.
> +++ b/drivers/staging/omapdrm/Kconfig
> @@ -0,0 +1,24 @@
> +
> +config DRM_OMAP
> + tristate "OMAP DRM (EXPERIMENTAL)"
> + depends on DRM && !CONFIG_FB_OMAP2
Since it says EXPERIMENTAL shoul
To: dri-devel at lists.freedesktop.org
> Cc: patches at linaro.org; Inki Dae; Rob Clark
> Subject: [PATCH] RFCv2: omapdrm DRM/KMS driver for TI OMAP platforms
>
> From: Rob Clark
>
> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
> and omap_vout (v4l2 dis
On Mon, Sep 19, 2011 at 2:44 AM, Inki Dae wrote:
> Hello Rob.
>
> Is there some reason that you don't head your driver gpu/drm, just staging?
> and below is my short comments. thank you.
>
mainly because it is still a work-in-progress.. I expect some
re-shuffling of the mode-setting code when drm
On Mon, Sep 19, 2011 at 2:44 AM, Inki Dae wrote:
> Hello Rob.
>
> Is there some reason that you don't head your driver gpu/drm, just staging?
> and below is my short comments. thank you.
>
mainly because it is still a work-in-progress.. I expect some
re-shuffling of the mode-setting code when drm
On 09/18/2011 10:15 PM, Rob Clark wrote:
> On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hellstrom
> wrote:
>
>> On 09/18/2011 09:50 PM, Rob Clark wrote:
>>
>>> On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
>>> wrote:
>>>
>>>
On 09/17/2011 11:32 PM, Rob Clark wrote:
>>
On 09/18/2011 09:50 PM, Rob Clark wrote:
> On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
> wrote:
>
>> On 09/17/2011 11:32 PM, Rob Clark wrote:
>>
>>> From: Rob Clark
>>>
>>> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
>>> and omap_vout (v4l2 display) drive
On 09/17/2011 11:32 PM, Rob Clark wrote:
> From: Rob Clark
>
> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
> and omap_vout (v4l2 display) drivers in the past, this driver uses the
> DSS2 driver to access the display hardware, including support for
> HDMI, DVI, and various
On Sun, Sep 18, 2011 at 10:31:45AM -0500, Rob Clark wrote:
> On Sun, Sep 18, 2011 at 5:23 AM, Daniel Vetter wrote:
> > On Sat, Sep 17, 2011 at 04:32:09PM -0500, Rob Clark wrote:
> On Sun, Sep 18, 2011 at 5:23 AM, Daniel Vetter wrote:
> >> +struct drm_omap_gem_cpu_fini {
> >> + uint32_t handle
On Sun, Sep 18, 2011 at 3:31 PM, Thomas Hellstrom
wrote:
> On 09/18/2011 10:15 PM, Rob Clark wrote:
>>
>> On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> On 09/18/2011 09:50 PM, Rob Clark wrote:
>>>
On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
?wrote:
>
On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hellstrom
wrote:
> On 09/18/2011 09:50 PM, Rob Clark wrote:
>>
>> On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> On 09/17/2011 11:32 PM, Rob Clark wrote:
>>>
From: Rob Clark
A DRM display driver for TI OMAP platf
On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
wrote:
> On 09/17/2011 11:32 PM, Rob Clark wrote:
>>
>> From: Rob Clark
>>
>> A DRM display driver for TI OMAP platform. ?Similar to omapfb (fbdev)
>> and omap_vout (v4l2 display) drivers in the past, this driver uses the
>> DSS2 driver to access
On Sun, Sep 18, 2011 at 3:31 PM, Thomas Hellstrom wrote:
> On 09/18/2011 10:15 PM, Rob Clark wrote:
>>
>> On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hellstrom
>> wrote:
>>
>>>
>>> On 09/18/2011 09:50 PM, Rob Clark wrote:
>>>
On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
wrote:
>>
On Sun, Sep 18, 2011 at 10:55 AM, Daniel Vetter wrote:
> There's the little funny caveat though that if userspace passes in less
> data than the kernel expects, it's not being cleared. But that can be
> fixed.
oh, heh, good catch.. I'll send a patch for that shortly, before I
forget and spend a b
On 09/18/2011 10:15 PM, Rob Clark wrote:
On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hellstrom wrote:
On 09/18/2011 09:50 PM, Rob Clark wrote:
On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
wrote:
On 09/17/2011 11:32 PM, Rob Clark wrote:
From: Rob Clark
A DRM
On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hellstrom wrote:
> On 09/18/2011 09:50 PM, Rob Clark wrote:
>>
>> On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
>> wrote:
>>
>>>
>>> On 09/17/2011 11:32 PM, Rob Clark wrote:
>>>
From: Rob Clark
A DRM display driver for TI OMAP platfo
On 09/18/2011 09:50 PM, Rob Clark wrote:
On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom wrote:
On 09/17/2011 11:32 PM, Rob Clark wrote:
From: Rob Clark
A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
and omap_vout (v4l2 display) drivers in the past, this dri
On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom wrote:
> On 09/17/2011 11:32 PM, Rob Clark wrote:
>>
>> From: Rob Clark
>>
>> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
>> and omap_vout (v4l2 display) drivers in the past, this driver uses the
>> DSS2 driver to access t
On 09/17/2011 11:32 PM, Rob Clark wrote:
From: Rob Clark
A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
and omap_vout (v4l2 display) drivers in the past, this driver uses the
DSS2 driver to access the display hardware, including support for
HDMI, DVI, and various types of
On Sat, Sep 17, 2011 at 04:32:09PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
> and omap_vout (v4l2 display) drivers in the past, this driver uses the
> DSS2 driver to access the display hardware, including support for
> HDM
On Sun, Sep 18, 2011 at 10:55 AM, Daniel Vetter wrote:
> There's the little funny caveat though that if userspace passes in less
> data than the kernel expects, it's not being cleared. But that can be
> fixed.
oh, heh, good catch.. I'll send a patch for that shortly, before I
forget and spend a b
On Sun, Sep 18, 2011 at 5:23 AM, Daniel Vetter wrote:
> On Sat, Sep 17, 2011 at 04:32:09PM -0500, Rob Clark wrote:
>> From: Rob Clark
>>
>> A DRM display driver for TI OMAP platform. ?Similar to omapfb (fbdev)
>> and omap_vout (v4l2 display) drivers in the past, this driver uses the
>> DSS2 drive
On Sun, Sep 18, 2011 at 10:31:45AM -0500, Rob Clark wrote:
> On Sun, Sep 18, 2011 at 5:23 AM, Daniel Vetter wrote:
> > On Sat, Sep 17, 2011 at 04:32:09PM -0500, Rob Clark wrote:
> On Sun, Sep 18, 2011 at 5:23 AM, Daniel Vetter wrote:
> >> +struct drm_omap_gem_cpu_fini {
> >> + uint32_t handle
On Sun, Sep 18, 2011 at 5:23 AM, Daniel Vetter wrote:
> On Sat, Sep 17, 2011 at 04:32:09PM -0500, Rob Clark wrote:
>> From: Rob Clark
>>
>> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
>> and omap_vout (v4l2 display) drivers in the past, this driver uses the
>> DSS2 drive
On Sat, Sep 17, 2011 at 04:32:09PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
> and omap_vout (v4l2 display) drivers in the past, this driver uses the
> DSS2 driver to access the display hardware, including support for
> HDM
From: Rob Clark
A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
and omap_vout (v4l2 display) drivers in the past, this driver uses the
DSS2 driver to access the display hardware, including support for
HDMI, DVI, and various types of LCD panels. And it implements GEM
support
33 matches
Mail list logo
