Hi,
On Tue, 2013-08-06 at 12:31 +0100, Tom Cooksey wrote:
> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> > >> wrote:
> > that was part of the reason to punt this problem to userspace ;-)
> >
> > In practice, the kernel drivers doesn't usually know too much about
> > the dimensions/format/
> >> > Turning to DRM/KMS, it seems the supported formats of a plane
> >> > can be queried using drm_mode_get_plane. However, there doesn't
> >> > seem to be a way to query the supported formats of a crtc? If
> >> > display HW only supports scanning out from a single buffer
> >> > (like pl111 d
> >> > Turning to DRM/KMS, it seems the supported formats of a plane
> >> > can be queried using drm_mode_get_plane. However, there doesn't
> >> > seem to be a way to query the supported formats of a crtc? If
> >> > display HW only supports scanning out from a single buffer
> >> > (like pl111 d
> > Turning to DRM/KMS, it seems the supported formats of a plane can be
> > queried using drm_mode_get_plane. However, there doesn't seem to be a
> > way to query the supported formats of a crtc? If display HW only
> > supports scanning out from a single buffer (like pl111 does), I think
> > it w
On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey wrote:
>
>> > Turning to DRM/KMS, it seems the supported formats of a plane can be
>> > queried using drm_mode_get_plane. However, there doesn't seem to be a
>> > way to query the supported formats of a crtc? If display HW only
>> > supports scanning ou
On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey wrote:
>
>> > Turning to DRM/KMS, it seems the supported formats of a plane can be
>> > queried using drm_mode_get_plane. However, there doesn't seem to be a
>> > way to query the supported formats of a crtc? If display HW only
>> > supports scanning ou
> > Turning to DRM/KMS, it seems the supported formats of a plane can be
> > queried using drm_mode_get_plane. However, there doesn't seem to be a
> > way to query the supported formats of a crtc? If display HW only
> > supports scanning out from a single buffer (like pl111 does), I think
> > it w
> >> > Didn't you say that programmatically describing device placement
> >> > constraints was an unbounded problem? I guess we would have to
> >> > accept that it's not possible to describe all possible constraints
> >> > and instead find a way to describe the common ones?
> >>
> >> well, the poi
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote:
>
>> >> > Didn't you say that programmatically describing device placement
>> >> > constraints was an unbounded problem? I guess we would have to
>> >> > accept that it's not possible to describe all possible constraints
>> >> > and instead find a
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote:
>
>> >> > Didn't you say that programmatically describing device placement
>> >> > constraints was an unbounded problem? I guess we would have to
>> >> > accept that it's not possible to describe all possible constraints
>> >> > and instead find a
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote:
>
>> >> > Didn't you say that programmatically describing device placement
>> >> > constraints was an unbounded problem? I guess we would have to
>> >> > accept that it's not possible to describe all possible constraints
>> >> > and instead find a
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote:
>
>> >> > Didn't you say that programmatically describing device placement
>> >> > constraints was an unbounded problem? I guess we would have to
>> >> > accept that it's not possible to describe all possible constraints
>> >> > and instead find a
> >> > Didn't you say that programmatically describing device placement
> >> > constraints was an unbounded problem? I guess we would have to
> >> > accept that it's not possible to describe all possible constraints
> >> > and instead find a way to describe the common ones?
> >>
> >> well, the poi
On Wed, Aug 7, 2013 at 12:23 AM, John Stultz wrote:
> On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark wrote:
>> well, let's divide things up into two categories:
>>
>> 1) the arrangement and format of pixels.. ie. what userspace would
>> need to know if it mmap's a buffer. This includes pixel format,
On Wed, Aug 7, 2013 at 12:23 AM, John Stultz wrote:
> On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark wrote:
>> well, let's divide things up into two categories:
>>
>> 1) the arrangement and format of pixels.. ie. what userspace would
>> need to know if it mmap's a buffer. This includes pixel format,
On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark wrote:
> On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey wrote:
>>
>>> > So in some respects, there is a constraint on how buffers which will
>>> > be drawn to using the GPU are allocated. I don't really like the idea
>>> > of teaching the display controller
On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark wrote:
> On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey wrote:
>>
>>> > So in some respects, there is a constraint on how buffers which will
>>> > be drawn to using the GPU are allocated. I don't really like the idea
>>> > of teaching the display controller
On Mon, Jul 29, 2013 at 7:58 AM, Rob Clark wrote:
> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey wrote:
>> Hi Rob,
>>
>>> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>>> >allocate buffers for the GPU. Still not sure how to resolve this
>>> >as we don't use DRM fo
On Mon, Jul 29, 2013 at 7:58 AM, Rob Clark wrote:
> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey wrote:
>> Hi Rob,
>>
>>> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>>> >allocate buffers for the GPU. Still not sure how to resolve this
>>> >as we don't use DRM fo
> >> ... This is the purpose of the attach step,
> >> so you know all the devices involved in sharing up front before
> >> allocating the backing pages. (Or in the worst case, if you have a
> >> "late attacher" you at least know when no device is doing dma access
> >> to a buffer and can reallocat
On Tue, Aug 6, 2013 at 2:18 PM, Lucas Stach wrote:
> I strongly disagree with exposing low-level hardware details like tiling
> to userspace. If we have to do the negotiation of those things in
> userspace we will end up with having to pipe those information through
> things like the wayland proto
Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark:
> On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote:
> > Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
> >> Hi Rob,
> >>
> >> +lkml
> >>
> >> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> >> > >> wrote:
> >> > >> >
On Tue, Aug 6, 2013 at 1:38 PM, Tom Cooksey wrote:
>
>> >> ... This is the purpose of the attach step,
>> >> so you know all the devices involved in sharing up front before
>> >> allocating the backing pages. (Or in the worst case, if you have a
>> >> "late attacher" you at least know when no devi
Hi Rob,
> >> > We may also then have additional constraints when sharing buffers
> >> > between the display HW and video decode or even camera ISP HW.
> >> > Programmatically describing buffer allocation constraints is very
> >> > difficult and I'm not sure you can actually do it - there's some
>
Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
> Hi Rob,
>
> +lkml
>
> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> > >> wrote:
> > >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to
> > >> >> >also allocate buffers for the GPU. Still not sure how to
Hi Rob,
+lkml
> >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> >> wrote:
> >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to
> >> >> >also allocate buffers for the GPU. Still not sure how to
> >> >> >resolve this as we don't use DRM for our GPU driver.
> >> >>
>
On Tue, Aug 6, 2013 at 1:38 PM, Tom Cooksey wrote:
>
>> >> ... This is the purpose of the attach step,
>> >> so you know all the devices involved in sharing up front before
>> >> allocating the backing pages. (Or in the worst case, if you have a
>> >> "late attacher" you at least know when no devi
On Tue, Aug 6, 2013 at 10:36 AM, Lucas Stach wrote:
> Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark:
>> On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach
>> wrote:
>> > Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
>> >> Hi Rob,
>> >>
>> >> +lkml
>> >>
>> >> > >> On Fri, J
> >> ... This is the purpose of the attach step,
> >> so you know all the devices involved in sharing up front before
> >> allocating the backing pages. (Or in the worst case, if you have a
> >> "late attacher" you at least know when no device is doing dma access
> >> to a buffer and can reallocat
On Tue, Aug 6, 2013 at 10:03 AM, Tom Cooksey wrote:
> Hi Rob,
>
>> >> > We may also then have additional constraints when sharing buffers
>> >> > between the display HW and video decode or even camera ISP HW.
>> >> > Programmatically describing buffer allocation constraints is very
>> >> > difficu
On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote:
> Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
>> Hi Rob,
>>
>> +lkml
>>
>> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
>> > >> wrote:
>> > >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to
>> > >> >> >
On Tue, Aug 6, 2013 at 2:18 PM, Lucas Stach wrote:
> I strongly disagree with exposing low-level hardware details like tiling
> to userspace. If we have to do the negotiation of those things in
> userspace we will end up with having to pipe those information through
> things like the wayland proto
On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey wrote:
>
>> > So in some respects, there is a constraint on how buffers which will
>> > be drawn to using the GPU are allocated. I don't really like the idea
>> > of teaching the display controller DRM driver about the GPU buffer
>> > constraints, even i
On Tue, Aug 6, 2013 at 10:36 AM, Lucas Stach wrote:
> Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark:
>> On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote:
>> > Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
>> >> Hi Rob,
>> >>
>> >> +lkml
>> >>
>> >> > >> On Fri, Jul 2
On Tue, Aug 6, 2013 at 10:03 AM, Tom Cooksey wrote:
> Hi Rob,
>
>> >> > We may also then have additional constraints when sharing buffers
>> >> > between the display HW and video decode or even camera ISP HW.
>> >> > Programmatically describing buffer allocation constraints is very
>> >> > difficu
Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark:
> On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote:
> > Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
> >> Hi Rob,
> >>
> >> +lkml
> >>
> >> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> >> > >> wrote:
> >> > >> >
On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote:
> Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
>> Hi Rob,
>>
>> +lkml
>>
>> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
>> > >> wrote:
>> > >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to
>> > >> >> >
Hi Rob,
> >> > We may also then have additional constraints when sharing buffers
> >> > between the display HW and video decode or even camera ISP HW.
> >> > Programmatically describing buffer allocation constraints is very
> >> > difficult and I'm not sure you can actually do it - there's some
>
Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
> Hi Rob,
>
> +lkml
>
> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> > >> wrote:
> > >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to
> > >> >> >also allocate buffers for the GPU. Still not sure how to
On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey wrote:
>
>> > So in some respects, there is a constraint on how buffers which will
>> > be drawn to using the GPU are allocated. I don't really like the idea
>> > of teaching the display controller DRM driver about the GPU buffer
>> > constraints, even i
Hi Rob,
+lkml
> >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> >> wrote:
> >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to
> >> >> >also allocate buffers for the GPU. Still not sure how to
> >> >> >resolve this as we don't use DRM for our GPU driver.
> >> >>
>
Hi Rob,
+linux-media, +linaro-mm-sig for discussion of video/camera
buffer constraints...
> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> wrote:
> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
> >> >allocate buffers for the GPU. Still not sure how to resolve
> >>
On Mon, Aug 5, 2013 at 1:10 PM, Tom Cooksey wrote:
> Hi Rob,
>
> +linux-media, +linaro-mm-sig for discussion of video/camera
> buffer constraints...
>
>
>> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
>> wrote:
>> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>> >> >
On Mon, Aug 5, 2013 at 1:10 PM, Tom Cooksey wrote:
> Hi Rob,
>
> +linux-media, +linaro-mm-sig for discussion of video/camera
> buffer constraints...
>
>
>> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
>> wrote:
>> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>> >> >
Hi Rob,
+linux-media, +linaro-mm-sig for discussion of video/camera
buffer constraints...
> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> wrote:
> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
> >> >allocate buffers for the GPU. Still not sure how to resolve
> >>
On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey wrote:
> Hi Rob,
>
>> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>> >allocate buffers for the GPU. Still not sure how to resolve this
>> >as we don't use DRM for our GPU driver.
>>
>> any thoughts/plans about a DRM GPU
On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey wrote:
> Hi Rob,
>
>> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>> >allocate buffers for the GPU. Still not sure how to resolve this
>> >as we don't use DRM for our GPU driver.
>>
>> any thoughts/plans about a DRM GPU
On Fri, Jul 26, 2013 at 04:58:55PM +0100, Tom Cooksey wrote:
> Hi Rob,
>
> > > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
> > >allocate buffers for the GPU. Still not sure how to resolve this
> > >as we don't use DRM for our GPU driver.
> >
> > any thoughts/plans a
Hi Rob,
> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
> >allocate buffers for the GPU. Still not sure how to resolve this
> >as we don't use DRM for our GPU driver.
>
> any thoughts/plans about a DRM GPU driver? Ideally long term (esp.
> once the dma-fence stuff
On Fri, 2013-07-26 at 15:21 +0100, Rob Clark wrote:
> Well, if you have something complex enough to benefit from CDF, then
> you probably ought to be looking at drm/kms.
That's what we're doing - hope you appreciate Tom's effort of re-writing
a driver for something that pre-dates DRM/KMS by gener
On Thu, Jul 25, 2013 at 02:21:59PM -0400, Rob Clark wrote:
> On Thu, Jul 25, 2013 at 1:17 PM, wrote:
> > Known issues:
> > * It uses KDS. We intend to switch to whatever implicit per-buffer
> >synchronisation mechanism gets merged, once something is merged.
> > * It abuses flags parameter o
On Thu, 2013-07-25 at 19:21 +0100, Rob Clark wrote:
> > * Only supports 640x480 mode, which is hard-coded. We intend to
> >rebase on top of CDF once it is merged, which hopefully will
> >handle a lot of the EDID parsing & mode setting for us (once
> >Pawel's CDF patches for VExpress al
On Fri, Jul 26, 2013 at 04:58:55PM +0100, Tom Cooksey wrote:
> Hi Rob,
>
> > > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
> > >allocate buffers for the GPU. Still not sure how to resolve this
> > >as we don't use DRM for our GPU driver.
> >
> > any thoughts/plans a
On Fri, Jul 26, 2013 at 10:14 AM, Russell King - ARM Linux
wrote:
> On Thu, Jul 25, 2013 at 02:21:59PM -0400, Rob Clark wrote:
>> On Thu, Jul 25, 2013 at 1:17 PM, wrote:
>> > Known issues:
>> > * It uses KDS. We intend to switch to whatever implicit per-buffer
>> >synchronisation mechanism
On Fri, Jul 26, 2013 at 10:06 AM, Pawel Moll wrote:
> On Thu, 2013-07-25 at 19:21 +0100, Rob Clark wrote:
>> > * Only supports 640x480 mode, which is hard-coded. We intend to
>> >rebase on top of CDF once it is merged, which hopefully will
>> >handle a lot of the EDID parsing & mode setti
On Fri, 2013-07-26 at 15:21 +0100, Rob Clark wrote:
> Well, if you have something complex enough to benefit from CDF, then
> you probably ought to be looking at drm/kms.
That's what we're doing - hope you appreciate Tom's effort of re-writing
a driver for something that pre-dates DRM/KMS by gener
On Thu, Jul 25, 2013 at 02:21:59PM -0400, Rob Clark wrote:
> On Thu, Jul 25, 2013 at 1:17 PM, wrote:
> > Known issues:
> > * It uses KDS. We intend to switch to whatever implicit per-buffer
> >synchronisation mechanism gets merged, once something is merged.
> > * It abuses flags parameter o
On Thu, 2013-07-25 at 19:21 +0100, Rob Clark wrote:
> > * Only supports 640x480 mode, which is hard-coded. We intend to
> >rebase on top of CDF once it is merged, which hopefully will
> >handle a lot of the EDID parsing & mode setting for us (once
> >Pawel's CDF patches for VExpress al
Hi Rob,
> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
> >allocate buffers for the GPU. Still not sure how to resolve this
> >as we don't use DRM for our GPU driver.
>
> any thoughts/plans about a DRM GPU driver? Ideally long term (esp.
> once the dma-fence stuff
On Fri, Jul 26, 2013 at 10:14 AM, Russell King - ARM Linux
wrote:
> On Thu, Jul 25, 2013 at 02:21:59PM -0400, Rob Clark wrote:
>> On Thu, Jul 25, 2013 at 1:17 PM, wrote:
>> > Known issues:
>> > * It uses KDS. We intend to switch to whatever implicit per-buffer
>> >synchronisation mechanism
On Fri, Jul 26, 2013 at 10:06 AM, Pawel Moll wrote:
> On Thu, 2013-07-25 at 19:21 +0100, Rob Clark wrote:
>> > * Only supports 640x480 mode, which is hard-coded. We intend to
>> >rebase on top of CDF once it is merged, which hopefully will
>> >handle a lot of the EDID parsing & mode setti
From: Tom Cooksey
Please find below the current state of our pl111 DRM/KMS driver. This
is lightly tested on a Versatile Express using X running the
xf86-video-armsoc DDX driver[i] with the patches applied to drm-next
as of ~last week. To actually see anything on the DVI output, you
must also app
On Thu, Jul 25, 2013 at 1:17 PM, wrote:
> From: Tom Cooksey
>
> Please find below the current state of our pl111 DRM/KMS driver. This
> is lightly tested on a Versatile Express using X running the
> xf86-video-armsoc DDX driver[i] with the patches applied to drm-next
> as of ~last week. To actua
On Thu, Jul 25, 2013 at 1:17 PM, wrote:
> From: Tom Cooksey
>
> Please find below the current state of our pl111 DRM/KMS driver. This
> is lightly tested on a Versatile Express using X running the
> xf86-video-armsoc DDX driver[i] with the patches applied to drm-next
> as of ~last week. To actua
From: Tom Cooksey
Please find below the current state of our pl111 DRM/KMS driver. This
is lightly tested on a Versatile Express using X running the
xf86-video-armsoc DDX driver[i] with the patches applied to drm-next
as of ~last week. To actually see anything on the DVI output, you
must also app
65 matches
Mail list logo
