Re: Linux 3.4-rc1
On Sat, Mar 31, 2012 at 6:58 PM, Linus Torvalds wrote: > - drm dma-buf prime support. Dave Airlie sent me the pull request but > didn't push very hard for it, it's in my "ok, I can still pull it for > 3.4 if individual DRM driver people tell me that it will make their > lives easier." So this is in limbo - I have nothing against it, but I > won't pull unless I get a few people say "yes, please". yes, please :-) Note that the core drm dma-buf/prime support has already been reviewed by a lot of folks, and tested with a few different drivers (exynos, omapdrm, i915, nouveau, udl) with some driver support that could be pushed for 3.5 cycle if the core support makes it in for 3.4 cycle. BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH dri2proto] RFC: video support for dri2
From: Rob Clark
To allow the potential use of overlays to display video content, a few
extra parameters are required:
+ source buffer in different format (for example, various YUV formats)
and size as compared to destination drawable
+ multi-planar formats where discontiguous buffers are used for
different planes. For example, luma and chroma split across
multiple memory banks or with different tiled formats.
+ flipping between multiple back buffers, perhaps not in order (to
handle video formats with B-frames)
+ cropping during swap.. in case of video, perhaps the required hw
buffers are larger than the visible picture to account for codec
borders (for example, reference frames where a block/macroblock
moves past the edge of the visible picture, but back again in
subsequent frames).
Current solutions use the GPU to do a scaled/colorconvert into a DRI2
buffer from the client context. The goal of this protocol change is
to push the decision to use overlay or GPU blit to the xorg driver.
---
Eventually this should replace Xv. With a few additions, like attributes,
it could perhaps be possible to implement the client side Xv API on top
of dri2.
Note: video is not exactly the same as 3d, there are a number of other
things to consider (scaling, colorconvert, multi-planar formats). But
on the other hand the principle is similar (direct rendering from hw
video codecs). And a lot infrastructure of connection, authentication,
is same. So there are two options, either extend DRI2 or add a new
protocol which duplicates some parts. I'd like to consider extending
DRI2 first, but if people think the requirements for video are too
much different from 3d, then I could split this into a new protocol.
In either case, I will implement the xserver side infrastructure, but
I wanted to get some feel for what is the preferred approach (extend
dri2 or new videoproto) first.
dri2proto.txt | 60 -
1 files changed, 59 insertions(+), 1 deletions(-)
diff --git a/dri2proto.txt b/dri2proto.txt
index df763c7..aa83b1a 100644
--- a/dri2proto.txt
+++ b/dri2proto.txt
@@ -163,7 +163,8 @@ and DRI2InvalidateBuffers.
6. Protocol Types
DRI2DRIVER { DRI2DriverDRI
-DRI2DriverVDPAU }
+DRI2DriverVDPAU,
+DRI2DriverXV }
These values describe the type of driver the client will want
to load. The server sends back the name of the driver to use
@@ -184,6 +185,10 @@ DRI2ATTACHMENT { DRI2BufferFrontLeft
These values describe various attachment points for DRI2
buffers.
+ In the case of video driver (DRI2DriverXV) the attachment,
+ other than DRI2BufferFrontLeft, just indicates buffer
+ number and has no other special significance.
+
DRI2BUFFER { attachment: CARD32
name: CARD32
pitch: CARD32
@@ -203,6 +208,16 @@ DRI2ATTACH_FORMAT { attachment: CARD32
format. 'attachment' describes the attachment point for the buffer,
'format' describes an opaque, device-dependent format for the buffer.
+
+DRI2ATTACH_VIDEO { attachment: CARD32
+ format: CARD32,
+ width, height: CARD32 }
+
+ The DRI2ATTACH_VIDEO describes an attachment and the associated
+ format for video buffers. 'attachment' describes the attachment
+ point for the buffer, 'format' describes a fourcc value for the
+ buffer.
+
⚙ ⚙ ⚙ ⚙ ⚙ ⚙
@@ -367,6 +382,15 @@ The name of this extension is "DRI2".
later.
┌───
+DRI2GetVideoBuffers
+ drawable: DRAWABLE
+ attachments: LISTofDRI2ATTACH_VIDEO
+ ▶
+ width, height: CARD32
+ buffers: LISTofDRI2BUFFER
+└───
+
+┌───
DRI2GetMSC
drawable: DRAWABLE
▶
@@ -585,11 +609,21 @@ A.1 Common Types
4 CARD32 pitch
4 CARD32 cpp
4 CARD32 flags
+ 4 n extra names length
+ 4n LISTof extra names
└───
A DRI2 buffer specifies the attachment, the kernel memory
manager name, the pitch and chars per pixel for a buffer
attached to a given drawable.
+ In case of multi-planar video formats, 'extra names' will give the
+ list of additional buffer names if there is one buffer per plane.
+ For example, I420 has one Y plane in with a 8bit luma value per
+ pixel, followed by one U plane subsampled 2x2 (with one 8bit U value
+ per 2x2 pixel block), followed by one V plane subsampled 2x2. This
+ could either be represented as a single buffer name, or three
+ separate buffer names, one each for Y, U, and V.
+
┌───
DRI2ATTACH_FORMAT
4 CARD32 attachment
@@ -599,6 +633,17 @@ A.1 Common Types
This data type is only available with protocol version 1.1 or
later.
Fwd: [PATCH dri2proto] RFC: video support for dri2
fwd'ing because my original reply from other account didn't seem to be allowed by linaro-dev -- Forwarded message ------ From: Rob Clark Date: Fri, Aug 19, 2011 at 8:43 AM Subject: Re: [PATCH dri2proto] RFC: video support for dri2 To: Pauli Nieminen Cc: xorg-de...@lists.freedesktop.org, linaro-dev@lists.linaro.org On Fri, Aug 19, 2011 at 5:18 AM, Pauli Nieminen wrote: > On Thu, Aug 18, 2011 at 09:58:07PM -0500, Rob Clark wrote: >> From: Rob Clark >> >> To allow the potential use of overlays to display video content, a few >> extra parameters are required: >> >> + source buffer in different format (for example, various YUV formats) >> and size as compared to destination drawable >> + multi-planar formats where discontiguous buffers are used for >> different planes. For example, luma and chroma split across >> multiple memory banks or with different tiled formats. >> + flipping between multiple back buffers, perhaps not in order (to >> handle video formats with B-frames) >> + cropping during swap.. in case of video, perhaps the required hw >> buffers are larger than the visible picture to account for codec >> borders (for example, reference frames where a block/macroblock >> moves past the edge of the visible picture, but back again in >> subsequent frames). >> >> Current solutions use the GPU to do a scaled/colorconvert into a DRI2 >> buffer from the client context. The goal of this protocol change is >> to push the decision to use overlay or GPU blit to the xorg driver. >> --- >> Eventually this should replace Xv. With a few additions, like attributes, >> it could perhaps be possible to implement the client side Xv API on top >> of dri2. >> >> Note: video is not exactly the same as 3d, there are a number of other >> things to consider (scaling, colorconvert, multi-planar formats). But >> on the other hand the principle is similar (direct rendering from hw >> video codecs). And a lot infrastructure of connection, authentication, >> is same. So there are two options, either extend DRI2 or add a new >> protocol which duplicates some parts. I'd like to consider extending >> DRI2 first, but if people think the requirements for video are too >> much different from 3d, then I could split this into a new protocol. >> >> In either case, I will implement the xserver side infrastructure, but >> I wanted to get some feel for what is the preferred approach (extend >> dri2 or new videoproto) first. >> > > XvPutVideo is already existing alternative to use for video playback > to overlays. But XvPutVideo API isn't perfect for the job either. We have until now actually used an unholy marriage of v4l2 and XvPutVideo.. part of the motivation to either extend dri2 or introduce a direct-video-rendering proto is have a better solution for some of the sort-comings of the current solution: + currently the client has to realize it is using an overlay.. and which overlay.. switching between overlay and GPU blitting is not transparent to the client + which results in a resource management issue if there are multiple videos playing, or if you need to scale beyond what can be done w/ overlay, etc + in some cases, you might want some way for the window-manager to signal to xorg driver to switch to blitting because there are some transformational effects.. ie. wobbly windows and that sort of thing.. (I'm thinking maybe setting some property on the root window?) Ideally this would be transparent to the video player app. some of this could be accomplished w/ XvPutImage, but then you are restricted to memory that can be obtained from shmem, which is not sufficient for hw video codecs in most cases. > How would client know which formats are supported by driver? Xv expose > list of supported image formats to client. well, in current version of the patch, the client would "just have to know".. which is sort of how it is on the 3d side for dri2. Although if there was an attribute mechanism, then I guess we could actually make it possible to have a completely generic client. One other issue to tackle then is what exactly is the buffer name. Currently for dri2 this is left as an implementation detail between the client and server. But we could decree that it is a GEM buffer flink name, or possibly that it is a dmabuf file-descriptor (see http://lists.linaro.org/pipermail/linaro-mm-sig/2011-August/000509.html ) For a first step, I was ok that the client side of the dri2 connection would have to know some implementation details of the xorg driver that it is talking too, since this is how it already is for dri2, and it could be handled by an approach like vaapi/vdpau where there is some driver spec
Re: [PATCH dri2proto] RFC: video support for dri2
On Fri, Aug 19, 2011 at 5:18 AM, Pauli Nieminen wrote: > On Thu, Aug 18, 2011 at 09:58:07PM -0500, Rob Clark wrote: >> From: Rob Clark >> >> To allow the potential use of overlays to display video content, a few >> extra parameters are required: >> >> + source buffer in different format (for example, various YUV formats) >> and size as compared to destination drawable >> + multi-planar formats where discontiguous buffers are used for >> different planes. For example, luma and chroma split across >> multiple memory banks or with different tiled formats. >> + flipping between multiple back buffers, perhaps not in order (to >> handle video formats with B-frames) >> + cropping during swap.. in case of video, perhaps the required hw >> buffers are larger than the visible picture to account for codec >> borders (for example, reference frames where a block/macroblock >> moves past the edge of the visible picture, but back again in >> subsequent frames). >> >> Current solutions use the GPU to do a scaled/colorconvert into a DRI2 >> buffer from the client context. The goal of this protocol change is >> to push the decision to use overlay or GPU blit to the xorg driver. >> --- >> Eventually this should replace Xv. With a few additions, like attributes, >> it could perhaps be possible to implement the client side Xv API on top >> of dri2. >> >> Note: video is not exactly the same as 3d, there are a number of other >> things to consider (scaling, colorconvert, multi-planar formats). But >> on the other hand the principle is similar (direct rendering from hw >> video codecs). And a lot infrastructure of connection, authentication, >> is same. So there are two options, either extend DRI2 or add a new >> protocol which duplicates some parts. I'd like to consider extending >> DRI2 first, but if people think the requirements for video are too >> much different from 3d, then I could split this into a new protocol. >> >> In either case, I will implement the xserver side infrastructure, but >> I wanted to get some feel for what is the preferred approach (extend >> dri2 or new videoproto) first. >> > > XvPutVideo is already existing alternative to use for video playback > to overlays. But XvPutVideo API isn't perfect for the job either. We have until now actually used an unholy marriage of v4l2 and XvPutVideo.. part of the motivation to either extend dri2 or introduce a direct-video-rendering proto is have a better solution for some of the sort-comings of the current solution: + currently the client has to realize it is using an overlay.. and which overlay.. switching between overlay and GPU blitting is not transparent to the client + which results in a resource management issue if there are multiple videos playing, or if you need to scale beyond what can be done w/ overlay, etc + in some cases, you might want some way for the window-manager to signal to xorg driver to switch to blitting because there are some transformational effects.. ie. wobbly windows and that sort of thing.. (I'm thinking maybe setting some property on the root window?) Ideally this would be transparent to the video player app. some of this could be accomplished w/ XvPutImage, but then you are restricted to memory that can be obtained from shmem, which is not sufficient for hw video codecs in most cases. > How would client know which formats are supported by driver? Xv expose > list of supported image formats to client. well, in current version of the patch, the client would "just have to know".. which is sort of how it is on the 3d side for dri2. Although if there was an attribute mechanism, then I guess we could actually make it possible to have a completely generic client. One other issue to tackle then is what exactly is the buffer name. Currently for dri2 this is left as an implementation detail between the client and server. But we could decree that it is a GEM buffer flink name, or possibly that it is a dmabuf file-descriptor (see http://lists.linaro.org/pipermail/linaro-mm-sig/2011-August/000509.html ) For a first step, I was ok that the client side of the dri2 connection would have to know some implementation details of the xorg driver that it is talking too, since this is how it already is for dri2, and it could be handled by an approach like vaapi/vdpau where there is some driver specific code on the client side, above dri2. But on the other hand, allowing for a completely generic client using the video/dri2 proto could be interesting. I guess it depends on what folk's general feeling is.. if completely generic client side is important, then I'll go back and start adding attributes and this sort of thi
[PATCH] RFCv2: video support for dri2
To allow the potential use of overlays to display video content, a few
extra parameters are required:
+ source buffer in different format (for example, various YUV formats)
and size as compared to destination drawable
+ multi-planar formats where discontiguous buffers are used for
different planes. For example, luma and chroma split across
multiple memory banks or with different tiled formats.
+ flipping between multiple back buffers, perhaps not in order (to
handle video formats with B-frames)
+ cropping during swap.. in case of video, perhaps the required hw
buffers are larger than the visible picture to account for codec
borders (for example, reference frames where a block/macroblock
moves past the edge of the visible picture, but back again in
subsequent frames).
Current solutions use the GPU to do a scaled/colorconvert into a DRI2
buffer from the client context. The goal of this protocol change is
to push the decision to use overlay or GPU blit to the xorg driver.
In many cases, an overlay will avoid several passes through memory
(blit/scale/colorconvert to DRI back-buffer on client side, blit to
front and fake-front, and then whatever compositing is done by the
window manager). On the other hand, overlays can often be handled
directly by the scanout engine in the display hardware, with the GPU
switched off.
The disadvantages of overlays are that they are (usually) a limited
resource, sometimes with scaling constraints, and certainly with
limitations about transformational effects.
The goal of combining video and dri2 is to have the best of both worlds,
to have the flexibility of GPU blitting (ie. no limited number of video
ports, no constraint about transformational effects), while still having
the power consumption benefits of overlays (reduced memory bandwidth
usage and ability to shut off the GPU) when the UI is relatively
static other than the playing video.
Note: video is not exactly the same as 3d, there are a number of other
things to consider (scaling, colorconvert, multi-planar formats). But
on the other hand the principle is similar (direct rendering from hw
video codecs). And a lot infrastructure of connection, authentication,
is same. So there are two options, either extend DRI2 or add a new
protocol which duplicates some parts. I'd like to consider extending
DRI2 first, but if people think the requirements for video are too
much different from 3d, then I could split this into a new protocol.
---
dri2proto.txt | 133 -
1 files changed, 131 insertions(+), 2 deletions(-)
diff --git a/dri2proto.txt b/dri2proto.txt
index df763c7..92f85a4 100644
--- a/dri2proto.txt
+++ b/dri2proto.txt
@@ -163,7 +163,8 @@ and DRI2InvalidateBuffers.
6. Protocol Types
DRI2DRIVER { DRI2DriverDRI
-DRI2DriverVDPAU }
+DRI2DriverVDPAU,
+DRI2DriverXV }
These values describe the type of driver the client will want
to load. The server sends back the name of the driver to use
@@ -184,6 +185,11 @@ DRI2ATTACHMENT { DRI2BufferFrontLeft
These values describe various attachment points for DRI2
buffers.
+ In the case of video driver (DRI2DriverXV) the attachment,
+ other than DRI2BufferFrontLeft, just indicates buffer
+ number and has no other special significance. There is no
+ automatic maintenance of DRI2BufferFakeFrontLeft.
+
DRI2BUFFER { attachment: CARD32
name: CARD32
pitch: CARD32
@@ -201,7 +207,8 @@ DRI2ATTACH_FORMAT { attachment: CARD32
The DRI2ATTACH_FORMAT describes an attachment and the associated
format. 'attachment' describes the attachment point for the buffer,
- 'format' describes an opaque, device-dependent format for the buffer.
+ 'format' describes an opaque, device-dependent format for the buffer,
+ or a fourcc for non-device-dependent formats.
⚙ ⚙ ⚙ ⚙ ⚙ ⚙
@@ -440,6 +447,97 @@ The name of this extension is "DRI2".
DRI2SwapBuffers requests to swap at most once per interval frames,
which is useful useful for limiting the frame rate.
+┌───
+DRI2SetAttribute
+ drawable: DRAWABLE
+ attribute: ATOM
+ value: INT32
+ ▶
+└───
+ Errors: Window, Match, Value
+
+ The DRI2SetAttribute request sets the value of a drawable attribute.
+ The drawable attribute is identified by the attribute atom. The
+ following strings are guaranteed to generate valid atoms using the
+ InternAtom request.
+
+ StringType
+ -
+
+ "XV_ENCODING" ENCODINGID
+ "XV_HUE" [-1000..1000]
+ "XV_SATURATION" [-1000..1000]
+ "XV_BRIGHTNESS" [-1000..1000]
+ "XV_CONTRAST" [-1000..1000]
+ "XV_WIDTH"[0..MAX_INT]
Re: [PATCH] RFCv2: video support for dri2
On Thu, Sep 1, 2011 at 5:22 PM, Younes Manton wrote: > On Thu, Sep 1, 2011 at 4:52 PM, Rob Clark wrote: >> To allow the potential use of overlays to display video content, a few >> extra parameters are required: >> >> + source buffer in different format (for example, various YUV formats) >> and size as compared to destination drawable >> + multi-planar formats where discontiguous buffers are used for >> different planes. For example, luma and chroma split across >> multiple memory banks or with different tiled formats. >> + flipping between multiple back buffers, perhaps not in order (to >> handle video formats with B-frames) >> + cropping during swap.. in case of video, perhaps the required hw >> buffers are larger than the visible picture to account for codec >> borders (for example, reference frames where a block/macroblock >> moves past the edge of the visible picture, but back again in >> subsequent frames). >> >> Current solutions use the GPU to do a scaled/colorconvert into a DRI2 >> buffer from the client context. The goal of this protocol change is >> to push the decision to use overlay or GPU blit to the xorg driver. >> >> In many cases, an overlay will avoid several passes through memory >> (blit/scale/colorconvert to DRI back-buffer on client side, blit to >> front and fake-front, and then whatever compositing is done by the >> window manager). On the other hand, overlays can often be handled >> directly by the scanout engine in the display hardware, with the GPU >> switched off. >> >> The disadvantages of overlays are that they are (usually) a limited >> resource, sometimes with scaling constraints, and certainly with >> limitations about transformational effects. >> >> The goal of combining video and dri2 is to have the best of both worlds, >> to have the flexibility of GPU blitting (ie. no limited number of video >> ports, no constraint about transformational effects), while still having >> the power consumption benefits of overlays (reduced memory bandwidth >> usage and ability to shut off the GPU) when the UI is relatively >> static other than the playing video. >> >> Note: video is not exactly the same as 3d, there are a number of other >> things to consider (scaling, colorconvert, multi-planar formats). But >> on the other hand the principle is similar (direct rendering from hw >> video codecs). And a lot infrastructure of connection, authentication, >> is same. So there are two options, either extend DRI2 or add a new >> protocol which duplicates some parts. I'd like to consider extending >> DRI2 first, but if people think the requirements for video are too >> much different from 3d, then I could split this into a new protocol. > > ... > >> +┌─── >> + DRI2SetAttribute >> + drawable: DRAWABLE >> + attribute: ATOM >> + value: INT32 >> + ▶ >> +└─── >> + Errors: Window, Match, Value >> + >> + The DRI2SetAttribute request sets the value of a drawable attribute. >> + The drawable attribute is identified by the attribute atom. The >> + following strings are guaranteed to generate valid atoms using the >> + InternAtom request. >> + >> + String Type >> + - >> + >> + "XV_ENCODING" ENCODINGID >> + "XV_HUE" [-1000..1000] >> + "XV_SATURATION" [-1000..1000] >> + "XV_BRIGHTNESS" [-1000..1000] >> + "XV_CONTRAST" [-1000..1000] >> + "XV_WIDTH" [0..MAX_INT] >> + "XV_HEIGHT" [0..MAX_INT] >> + "XV_OSD" XID >> + >> + If the given attribute doesn't match an attribute supported by the >> + drawable a Match error is generated. The supplied encoding >> + must be one of the encodings listed for the adaptor, otherwise an >> + Encoding error is generated. >> + >> + If the adaptor doesn't support the exact hue, saturation, >> + brightness, and contrast levels supplied, the closest levels >> + supported are assumed. The DRI2GetAttribute request can be used >> + to query the resulting levels. >> + >> + The "XV_WIDTH" and "XV_HEIGHT" attributes default to zero, indicating >> + that no scaling is performed and the buffer sizes match the draw
Re: [PATCH] RFCv2: video support for dri2 (Rob Clark)
2011/9/2 Christian König :
> Hi Rob,
>
>> + flipping between multiple back buffers, perhaps not in order (to
>> handle video formats with B-frames)
> Oh, yes please. The closed source drivers seems to do this also all the
> time, and I never really understood why DRI is limiting the buffers to
> the OGL attachment points.
>
> ...
>
>> Current solutions use the GPU to do a scaled/colorconvert into a DRI2
>> buffer from the client context. The goal of this protocol change is
>> to push the decision to use overlay or GPU blit to the xorg driver.
> You left one corner case out, HDMI allows for the framebuffer to be in
> YUV 4:4:4 format. So it is possible to send YUV data to the display
> (usually a TV) without color conversion at all, but I think with the
> current state of X we are years away from that.
heh, yeah..
possibly w/ overlays, at least when fullscreen and gfx layer is not
visible, we could send YUV direct to the TV.. but I'm not really sure
the practicality of switching back and forth between RGB and YUV
> ...
>
>> In many cases, an overlay will avoid several passes through memory
>> (blit/scale/colorconvert to DRI back-buffer on client side, blit to
>> front and fake-front, and then whatever compositing is done by the
>> window manager). On the other hand, overlays can often be handled
>> directly by the scanout engine in the display hardware, with the GPU
>> switched off.
> Actually AMD has thrown out the hardware support for overlay with the
> R7xx (or was it evergreen?) series, because they got support for turning
> shader pipes off separately and figured out that it use less power to
> turn off all shaders except one and then use this one for color
> conversion and scaling, compared to having a distinct hardware block
> doing the job. But there are tendencies to get a distinct color
> conversion block back again.
>
The nice thing would be, by pushing this decision of *how* to render
video to the DDX, the xorg driver can make intelligent choices about
how best to implement it for a particular generation of gfx card or
SoC. Nothing forces the use of overlays, but the goal is just to
allow overlays to be used when/if it makes sense.
> ...
>
>> Note: video is not exactly the same as 3d, there are a number of other
>> things to consider (scaling, colorconvert, multi-planar formats). But
>> on the other hand the principle is similar (direct rendering from hw
>> video codecs). And a lot infrastructure of connection, authentication,
>> is same. So there are two options, either extend DRI2 or add a new
>> protocol which duplicates some parts. I'd like to consider extending
>> DRI2 first, but if people think the requirements for video are too
>> much different from 3d, then I could split this into a new protocol.
> If you ask me extending things seems the better way to do this.
Ok, I'm glad that folks don't seem too scared off by adding some video
stuff in dri2proto :-)
> ..
>
>> @@ -184,6 +185,11 @@ DRI2ATTACHMENT { DRI2BufferFrontLeft
>> These values describe various attachment points for DRI2
>> buffers.
>>
>> + In the case of video driver (DRI2DriverXV) the attachment,
>> + other than DRI2BufferFrontLeft, just indicates buffer
>> + number and has no other special significance. There is no
>> + automatic maintenance of DRI2BufferFakeFrontLeft.
> I think that will created compatibility problems with existing
> implementations, because the DDX side doesn't know if it's talking to a
> video or 3D client side.
On the xorg/DDX side, we'd have to expose the 'driverType' to the DRI2
implementation somehow. I'm not sure yet the best way to handle this,
but I guess it is a solvable problem.
Once it seems like I'm basically the right track I'll start putting
together some patches for xserver tree to go along with the proto
changes and sort out these details. I wanted to at least make sure I
was on the right track by extending dri2 as opposed to adding a new
extension first.
> ...
>
>> + The "XV_OSD" attribute specifies the XID of a pixmap containing
>> + ARGB data to be non-destructively overlayed over the video. This
>> + could be used to implement subtiles, on-screen-menus, etc.
> Why an XID? I'm not 100% sure about it, but using a DRI buffer name
> directly here seems to be the better alternative.
I'm debating back and forth between two approaches here..
1) attribute w/ pixmap XID (which itself could be
DRI2CreateDrawable()'d if needed, which would give you DRI buffers)
2) have some special attachment points
In the second case, it seemed a bit awkward to me, because we'd
probably need a way to SwapBuffers w/ both a src and dst specified (so
you aren't always swapping to the front).. (well, maybe CopyRegion is
sufficient). And also, now some of the non-front buffers are RGB and
not scaled vs YUV and scaled. But with the first approach it is
consistent, all non-front buffers are same dimensions/format.
Also, for a generic (non-3d) clien
Re: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
On Sat, Sep 3, 2011 at 1:57 AM, Dave Airlie wrote: >> >> A simple "plugin" mechanism is provided to allow integration with >> external kernel modules (*cough* PVR), but also to keep the code more >> modular as support is added for various other accelerator blocks that >> exist in various different OMAP variants. (2D accel, video encode/ >> decode, etc.) However this driver and userspace xorg driver are >> themselves fully functional without any closed-source components. It >> doesn't (and won't) provide any command submission to IP blocks with >> closed-source kernel or userspace components. > > At the moment I'd rather not merge any sort of plugin layer, until we > had some users for it that were part of an open driver stack. Ok, that is fair. It should be not too hard to keep this as a patch on top for now. I'm hoping to have the first open user of the API in a month or so. > I'll try and review the rest next week. Thanks BR, -R > Dave. > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
On Sat, Sep 3, 2011 at 1:53 PM, Daniel Vetter wrote:
> Hi Rob,
>
> I've taken a look at your driver, some comments inline. Can't really
> comment much on the kms side because of lack of expertise in that area.
>
> I think most can be trivially addressed by dropping the plugin layer ;-)
>
> Cheers, Daniel
>
> On Fri, Sep 02, 2011 at 03:07:27PM -0500, Rob Clark wrote:
>
>> [snip]
>
>> +int omap_connector_sync(struct drm_connector *connector)
>> +{
>> + struct omap_connector *omap_connector = to_omap_connector(connector);
>> + struct omap_dss_device *dssdev = omap_connector->dssdev;
>> + struct omap_dss_driver *dssdrv = dssdev->driver;
>> +
>> + DBG("%s", omap_connector->dssdev->name);
>> +
>> + if (dssdrv->sync) {
>> + return dssdrv->sync(dssdev);
>> + }
>> +
>> + return -EINVAL;
>> +}
>> +EXPORT_SYMBOL(omap_connector_sync);
>
> What is this for? There seem to be a few other EXPORT_SYMBOLS (beside
> those to register plugins) that look a bit strange - especially since
> there already is the dss layer to arbitrage between all the drivers (drm,
> v4l, fbdev). Or is that all stuff needed by your plugins? If so, better
> drop them until the first user shows up (and even then it's likely easer
> if the glue code comes as a separate patch).
this particular one is a remnant from an earlier version, where page
flipping and vsync sync'ing was handled in the PVR code.. once I
started adding sync-obj I've moved this into omap_crtc using the
normal page-flip ioctl.. it looks like I missed a bit of cleanup of
some of these fxns which are no longer needed since I moved the page
flipping into the KMS code.
At this point, I think it is just the exported symbols in the GEM bits
that are needed by the PVR plugin (and at least some would be needed
by other upcoming plugins for video encode/decode and then 2d).
>> [snip]
>
>> +/** ensure backing pages are allocated */
>> +/* NOTE: a bit similar to psb_gtt_attach_pages().. perhaps could be common?
>> + * and maybe a bit similar to i915_gem_object_get_pages_gtt()
>> + */
>
> Actually see also i915_gem_object_get_pages_gtt for yet another copy of
> this. This is a bit a mess and I'm not sure what to do, safe to slowly
> evolve gem into something resembling ttm ...
Yeah, I'd like to refactor out the attach/detach_pages stuff.. it is
on my todo list (I guess I should at least mention that in the TODO
file..)
>> [snip]
>
>> + * already contiguous, remap it to pin in physically contiguous memory..
>> (ie.
>> + * map in TILER)
>> + */
>> +int omap_gem_get_paddr(struct drm_gem_object *obj,
>> + unsigned long *paddr, bool remap)
>> +{
>> + struct omap_gem_object *omap_obj = to_omap_bo(obj);
>> +
>> + if (!(omap_obj->flags & OMAP_BO_DMA)) {
>> + /* TODO: remap to TILER */
>> + return -ENOMEM;
>> + }
>> +
>> + *paddr = omap_obj->paddr;
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(omap_gem_get_paddr);
>> +
>> +/* Release physical address, when DMA is no longer being performed.. this
>> + * could potentially unpin and unmap buffers from TILER
>> + */
>> +int omap_gem_put_paddr(struct drm_gem_object *obj)
>> +{
>> + /* do something here when remap to TILER is used.. */
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(omap_gem_put_paddr);
>> +
>> +/* acquire pages when needed (for example, for DMA where physically
>> + * contiguous buffer is not required
>> + */
>> +int omap_gem_get_pages(struct drm_gem_object *obj, struct page ***pages)
>> +{
>> + struct omap_gem_object *omap_obj = to_omap_bo(obj);
>> + /* TODO: we could attach/detach pages on demand */
>> + int ret; // XXX below is common in _fault()..
>> + if (obj->filp && !omap_obj->pages) {
>> + ret = omap_gem_attach_pages(obj);
>> + if (ret) {
>> + dev_err(obj->dev->dev, "could not attach pages\n");
>> + return ret;
>> + }
>> + }
>> + /* TODO: even phys-contig.. we should have a list of pages */
>> + *pages = omap_obj->pages;
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(omap_gem_get_pages);
>> +
>> +/* release pages when DMA no longer being performed */
>> +int omap_gem_put_pages(struct drm_gem_object *obj)
>> +{
>> + /* do something here if we dynamically attach/detach pages.. at
>> + * leas
Re: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
On Sun, Sep 4, 2011 at 2:49 PM, Daniel Vetter wrote:
> On Sun, Sep 04, 2011 at 11:29:43AM -0500, Rob Clark wrote:
>> > Above set of get/put functions seem to do very little. Drop them for the
>> > first round?
>>
>> The intention is to do attach/detach_pages here.. and in case of
>> get/put_paddr do remapping into TILER if the buffer isn't physically
>> contiguous. (Although in the TILER case, we are seeing how/if we can
>> fit this into the IOMMU framework.. so API's here are still in flux.
>> Non-tiled buffers are a natural fit for IOMMU, I think... but tiled
>> buffers, perhaps not.)
>>
>> I wanted to at least get the right API's in place here, even though
>> the implementation is still being sorted out.
>
> If I've grepped that one correctly, there not (yet) used, so just confuse
> when reviewing. They're also easier to understand with actual users ;-)
The omap_fb.c stuff does a put_paddr() when it is done using a buffer
for scanout, fwiw. But the put_paddr() stuff will make more sense
when I add support to remap discontiguous buffers for scanout.
> I think that's even true (perhaps even more so) for userspace stuff -
> there's an enormous body of precedence for adding feature flags in drm
> land for such stuff.
>
>> >> [snip]
>> >
>> >> +/* Buffer Synchronization:
>> >> + */
>> >> +
>> >> +struct omap_gem_sync_waiter {
>> >> + struct list_head list;
>> >> + struct omap_gem_object *omap_obj;
>> >> + enum omap_gem_op op;
>> >> + uint32_t read_target, write_target;
>> >> + /* notify called w/ sync_lock held */
>> >> + void (*notify)(void *arg);
>> >> + void *arg;
>> >> +};
>> >> +
>> >> +/* list of omap_gem_sync_waiter.. the notify fxn gets called back when
>> >> + * the read and/or write target count is achieved which can call a user
>> >> + * callback (ex. to kick 3d and/or 2d), wakeup blocked task (prep for
>> >> + * cpu access), etc.
>> >> + */
>> >> +static LIST_HEAD(waiters);
>> >> +
>> >> +static inline bool is_waiting(struct omap_gem_sync_waiter *waiter)
>> >> +{
>> >> + struct omap_gem_object *omap_obj = waiter->omap_obj;
>> >> + if ((waiter->op & OMAP_GEM_READ) &&
>> >> + (omap_obj->sync->read_complete <
>> >> waiter->read_target))
>> >> + return true;
>> >> + if ((waiter->op & OMAP_GEM_WRITE) &&
>> >> + (omap_obj->sync->write_complete <
>> >> waiter->write_target))
>> >> + return true;
>> >> + return false;
>> >> +}
>> >
>> > On a quick read this looks awfully like handrolled gpu sync objects. For
>> > which we already have a fully-featured implementation in ttm. And
>> > and something handrolled in i915 (request tracking). Can we do better?
>> >
>> > [ Looks like it's part of the plugin layer, so problem postponed. Puhh ]
>>
>> yeah, it is a bit handrolled sync-objects. I've looked a bit
>> (although maybe not enough) at the TTM code, although not immediately
>> sure how to do better. For better or for worse, some of the
>> implementation (like the in-memory layout) is dictated by SGX. It's
>> an area that I'm still working on and trying to figure out how to
>> improve, but somehow has to coexist w/ SGX otherwise the page-flipping
>> in the KMS part won't work.
>
> My gripes aren't with the hw interfacing side but more with the
> wheel-reinventing for the signalling and boilerblate accounting code.
ahh, ok, I get your point. When I started, I thought full blown TTM
would be overkill for a UMA setup.. but maybe I should revisit that.
Or if nothing else, see how to somehow refactor some of that out.. I'm
not really sure what the best thing to do would be at this point.
Although I suppose the gma500 driver would be in the same boat..
> Which ttm has a complete framework for.
>
> Up to now only i915 has been the odd man out, adding more is imo Not So
> Good (tm). Unfortunately there's no easy way out: Unifying ttm and i915
> style gem is a hellalotta work, and growing gem into something like ttm is
> pretty pointless (which code like this will eventually lead to).
yeah, that makes sense.. well, I'm open to suggestions here :-)
BR,
-R
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
DBG("par=%p, %dx%d", fbi->par, fbi->var.xres, fbi->var.yres);
>> + DBG("allocated %dx%d fb", fbdev->fb->width, fbdev->fb->height);
>> +
>> + mutex_unlock(&dev->struct_mutex);
>> +
>> + return 0;
>> +
>> +fail:
>> + mutex_unlock(&dev->struct_mutex);
>> + // TODO cleanup?
>> + return ret;
>> +}
>> +
>> +static void omap_crtc_fb_gamma_set(struct drm_crtc *crtc,
>> + u16 red, u16 green, u16 blue, int regno)
>> +{
>> + DBG("fbdev: set gamma");
>> +}
>> +
>> +static void omap_crtc_fb_gamma_get(struct drm_crtc *crtc,
>> + u16 *red, u16 *green, u16 *blue, int regno)
>> +{
>> + DBG("fbdev: get gamma");
>> +}
>> +
>> +static int omap_fbdev_probe(struct drm_fb_helper *helper,
>> + struct drm_fb_helper_surface_size *sizes)
>> +{
>> + int new_fb = 0;
>> + int ret;
>> +
>> + if (!helper->fb) {
>> + ret = omap_fbdev_create(helper, sizes);
>> + if (ret)
>> + return ret;
>> + new_fb = 1;
>> + }
>> + return new_fb;
>> +}
>> +
>
> This strange code must be because of mainline code below.
> fb_probe callback of drm_fb_helper_single_fb_probe function needs return
> values of three types. :( I think this mainline code should be modified
> properly.
>
yeah
[snip]
>> +
>> +struct omap_gem_object {
>> + struct drm_gem_object base;
>> +
>> + uint32_t flags;
>> +
>> + /**
>> + * if buffer is physically contiguous or remapped in TILER, the
>> + * OMAP_BO_DMA flag is set and the paddr is valid.
>> + *
>> + * Note that OMAP_BO_SCANOUT is a hint from userspace that DMA
>> capable
>> + * buffer is requested, but doesn't mean that it is. Use the
>> + * OMAP_BO_DMA flag to determine if the buffer has a DMA capable
>> + * physical address.
>> + */
>> + unsigned long paddr;
>> +
>> + /**
>> + * Array of backing pages, if allocated. Note that pages are never
>> + * allocated for buffers originally allocated from contiguous
>> memory
>> + * (which will have obj->filp==NULL)
>> + */
>> + struct page **pages;
>
> Is this array of backing pages used for physically non-continuous memory?.
> it appears that sgx core with iommu is considered.
yes (and will be similar for 2d hw). But even in case of scanout
buffers, we can remap them into TILER (which you can think of as a
sort of IOMMU on OMAP4+). The code for this isn't in place yet, but
the intention is to
a) if userspace knows it will be a scannout buffer, allocate
physically contiguous to begin with.. if that fails, fall back to
dis-contiguous.
b) if we need to scan it out, but it isn't contiguous, fall back to
remapping into TILER.
That is a bit of over-simplification.. for tiled buffers, and buffers
for video encode/decode, these would always be allocated as pages and
remapped into TILER.
[sync]
>> +
>> +static inline void sync_op(struct drm_gem_object *obj,
>> + enum omap_gem_op op, bool start)
>> +{
>> + struct omap_gem_object *omap_obj = to_omap_bo(obj);
>> +
>> + spin_lock(&sync_lock);
>> +
>> + if (!omap_obj->sync) {
>> + omap_obj->sync = kzalloc(sizeof(*omap_obj->sync),
>> GFP_KERNEL);
>> + }
>
> If sync_op function is called at interrupt context, use GFP_ATOMIC instead
> of GFP_KERNEL. from what you use spin_lock/unlock here, it appears that this
> function would be called at interrupt context.
yeah, that is an oversight.. I updated omap_gem_set_sync_object() but
missed this one
[snip]
>> +
>> +/* common constructor body */
>> +static struct drm_gem_object * omap_gem_new_impl(struct drm_device *dev,
>> + size_t size, uint32_t flags, unsigned long paddr, struct
>> page **pages,
>> + struct omap_gem_vm_ops *ops)
>> +{
>
> so many arguments are used at this function. I encourage you to use maximum
> four arguments for ARM system.
>
I know the reasoning for this.. although the alternative is to stick
extra param's in a struct on the stack, which roughly amounts to what
the compiler is doing for you anyways for args above the 1st four (ie.
pushing them to the stack).
anyways it is a static fxn so compiler has some flexibility to inline
or optimize however it sees fit..
[snip]
>> diff --git a/include/linux/omap_drm.h b/include/linux/omap_
Re: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
On Wed, Sep 7, 2011 at 1:00 AM, Inki Dae wrote:
> Hello, Rob.
>
[snip]
>> >> +static void page_flip_cb(void *arg)
>> >> +{
>> >> + struct drm_crtc *crtc = arg;
>> >> + struct drm_device *dev = crtc->dev;
>> >> + struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>> >> + struct drm_pending_vblank_event *event = omap_crtc->event;
>> >> + struct timeval now;
>> >> + unsigned long flags;
>> >> +
>> >> + WARN_ON(!event);
>> >> +
>> >> + omap_crtc->event = NULL;
>> >> +
>> >> + update_scanout(crtc);
>> >> + commit(crtc);
>> >> +
>> >> + /* wakeup userspace */
>> >> + // TODO: this should happen *after* flip.. somehow..
>> >> + if (event) {
>> >> + spin_lock_irqsave(&dev->event_lock, flags);
>> >> + event->event.sequence =
>> >> + drm_vblank_count_and_time(dev,
>> > omap_crtc->id,
>> >> &now);
>> >> + event->event.tv_sec = now.tv_sec;
>> >> + event->event.tv_usec = now.tv_usec;
>> >> + list_add_tail(&event->base.link,
>> >> + &event->base.file_priv->event_list);
>> >> +
> wake_up_interruptible(&event->base.file_priv->event_wait);
>> >> + spin_unlock_irqrestore(&dev->event_lock, flags);
>> >> + }
>> >
>> > How about moving codes above into interrupt handler for vblank?
>> > maybe there
>>
>> I should mention a couple of things:
>>
>> 1) drm vblank stuff isn't really used currently.. it is actually DSS2
>> layer that is registering for the display related interrupt(s). I'm
>> not really sure how to handle this best. I suppose the DRM driver
>> could *also* register for these interrupts, but that seems a bit odd..
>>
>
> DRM Framework supports only one interrupt handler. this issue should be
> resolved. and currently I made our driver to use its own request_irq, not
> DRM Framework side. we only sets drm_device->irq_enabled to 1 and interrupt
> handler is registered at display controller or hdmi driver respectively. but
> I'm not sure that this way is best so I will look over more. Anyway current
> drm framework should be fixed to be considered with multiple irq.
Or perhaps even callbacks (some other driver handling the irq's directly)?
>> Also, I guess it is also worth mentioning.. when it comes to vblank,
>> there are two fundamentally different sorts of displays we deal with.
>> Something like DVI/HDMI/etc which need constant refreshing. In these
>> cases we constantly scan-out the buffer until the next page
>> flip+vsync. And smart panels, where they get scanned out once and
>> then DSS is no longer reading the scanout buffer until we manually
>> trigger an update.
>>
>
> Is the Smart panel CPU interface based lcd panel that has its own
> framebuffer internally.?
yes
[snip]
>>
>> The main reason for the page-flip cb is actually not vsync
>> synchronization, but rather synchronizing with other hw blocks that
>> might be rendering to the buffer.. the page flip can be submitted
>> from userspace while some other hw block (3d, 2d, etc) is still
>> DMA'ing to the buffer. The sync-obj is intended to give a way to
>> defer the (in this case) page flip until other hw blocks are done
>> writing to the buffer.
>
> I thought page-flip is used to change buffer register value of display
> controller into another one like the Pan Display feature of linux
> framebuffer. actually page flip interface of libdrm library,
> page_flip_handler, is called with new framebuffer id that has its own
> buffer. and then the controller using current crtc would be set to buffer
> address of new framebuffer. and I understood that for other blocks such as
> 2d/3d accelerators, rendering synchronization you already mentioned above,
> is not depend on page flip action. It’s a sequence with my understanding
> below.
>
> 1. allocate a new buffer through drm interface such as DUMB_* or SPECIFIC
> IOCTLs.
> 2. render something on this buffer through DRM interfaces that handle 2D/3D
> Accelerators and also it would use their own interfaces for synchronization.
> 3. allocate a new framebuffer and attach the buffer to this framebuffer.
> 4. call page flip to change current framebuffer to the framebuffer above at
> vblank moment. at this time, buffer address of the framebuffer would be set
> to a controller.
>
> finally, we can see some image rendered on diplay. thus, I think page flip
> and rendering synchronization have no any relationship. if I missed any
> points, please give me your comments.
Well, I guess it depends on whether synchronization of the 3d/2d
render is done in userspace, or whether you just submit all the render
commands and then immediately submit the page-flip.
The actual page-flip should be a fairly light operation (writing a few
registers) and could be done directly from some sort of
render-complete interrupt from 2d/3d core.
[snip]
>> >> +int omap_framebuffer_get_buffer(struct drm_framebuffer *fb, int x, int
>> y,
>> >> + vo
Re: Fwd: Would you send me your hard float experiment results you presented in Budapest?
On Fri, Sep 2, 2011 at 1:27 PM, Christian Robottom Reis wrote: > On Tue, Aug 30, 2011 at 11:24:59AM -0500, Zach Pfeffer wrote: >> I'd like you to meet Jim who did the initial hardfloat work. This >> email contains the results that Jim produced. > > Hmm, but the email seems to not actually contain a hard-float run. Or am > I misreading what he means by Fixed vs VFP? > >> I believe that the conclusion was that skia and webkit may benefit, >> but that such benefits would impose an undue burden on Android's >> distribution model which tries to create libs that can run on as many >> architectures as possible. > > You may be confusing things here. Hard-float is a pure software ABI > change, and any platform which supports VFP can use it if you build it > that way. However, since it is an ABI change it requires that hard-float > libraries be available. > > What /would/ stop code from running on certain platforms is using > NEON (it would exclude the Tegra2 and some existing Marvell v7s). But > that doesn't seem to be in question here. Fwiw, VFP and NEON share same registers.. so as long as Tegra2 has VFP, I think it could use hard-float. Are we supporting any armv7-a that doesn't have at least VFP? Although I'm a bit lost on this topic, are we comparing non-hard-float-but-vfp-enabled (ie. fp op's not falling back to sw) vs hard-float? Or soft-float vs hard-float? BR, -R >> -- Forwarded message -- >> From: Jim Huang >> Date: 7 August 2011 18:01 >> Subject: Re: Would you send me your hard float experiment results you >> presented in Budapest? >> To: Zach Pfeffer >> >> >> 2011/8/7 Zach Pfeffer : >> > Jim, >> > >> > Thanks. Would it be possible to post them by the end of the day? >> >> skia -> >> >> Switch from VFP back to fixed scalar based calculation >> >> Previous configuration enabled ARM VFP for scalar float, but VFP on >> ARM11 is not as powerful as VFPv3 or NEON. >> >> Reference benchmark: >> Item Fixed based VFP-based >> --- - >> Draw Canvas 58.37 fps 58.40 fps >> Draw Circle 37.48 fps 22.93 fps >> Draw Circle2 17.14 fps 18.31 fps >> Draw Rect 17.62 fps 20.69 fps >> Draw Arc 24.79 fps 27.45 fps >> Draw Image 19.08 fps 18.73 fps >> Draw Text 29.22 fps 25.79 fps >> >> >> > >> > Also, have you sync'd up with Mike? He wants to negotiate on your contract. >> >> I sent mail to Mike already. I don't know how to proceed. >> >> Thanks, >> -jserv > > > >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev > > -- > Christian Robottom Reis, Engineering VP > Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 > Linaro.org: Open Source Software for ARM SoCs > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/6] drm/gem: add functions for mmap offset creation
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 88 +
include/drm/drmP.h|3 ++
2 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 186d62e..396e60c 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -285,6 +285,94 @@ again:
}
EXPORT_SYMBOL(drm_gem_handle_create);
+
+/**
+ * drm_gem_free_mmap_offset - release a fake mmap offset for an object
+ * @obj: obj in question
+ *
+ * This routine frees fake offsets allocated by drm_gem_create_mmap_offset().
+ */
+void
+drm_gem_free_mmap_offset(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+ struct drm_gem_mm *mm = dev->mm_private;
+ struct drm_map_list *list = &obj->map_list;
+
+ drm_ht_remove_item(&mm->offset_hash, &list->hash);
+ drm_mm_put_block(list->file_offset_node);
+ kfree(list->map);
+ list->map = NULL;
+}
+EXPORT_SYMBOL(drm_gem_free_mmap_offset);
+
+/**
+ * drm_gem_create_mmap_offset - create a fake mmap offset for an object
+ * @obj: obj in question
+ *
+ * GEM memory mapping works by handing back to userspace a fake mmap offset
+ * it can use in a subsequent mmap(2) call. The DRM core code then looks
+ * up the object based on the offset and sets up the various memory mapping
+ * structures.
+ *
+ * This routine allocates and attaches a fake offset for @obj.
+ */
+int
+drm_gem_create_mmap_offset(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+ struct drm_gem_mm *mm = dev->mm_private;
+ struct drm_map_list *list;
+ struct drm_local_map *map;
+ int ret = 0;
+
+ /* Set the object up for mmap'ing */
+ list = &obj->map_list;
+ list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
+ if (!list->map)
+ return -ENOMEM;
+
+ map = list->map;
+ map->type = _DRM_GEM;
+ map->size = obj->size;
+ map->handle = obj;
+
+ /* Get a DRM GEM mmap offset allocated... */
+ list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
+ obj->size / PAGE_SIZE, 0, 0);
+
+ if (!list->file_offset_node) {
+ DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
+ ret = -ENOSPC;
+ goto out_free_list;
+ }
+
+ list->file_offset_node = drm_mm_get_block(list->file_offset_node,
+ obj->size / PAGE_SIZE, 0);
+ if (!list->file_offset_node) {
+ ret = -ENOMEM;
+ goto out_free_list;
+ }
+
+ list->hash.key = list->file_offset_node->start;
+ ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
+ if (ret) {
+ DRM_ERROR("failed to add to map hash\n");
+ goto out_free_mm;
+ }
+
+ return 0;
+
+out_free_mm:
+ drm_mm_put_block(list->file_offset_node);
+out_free_list:
+ kfree(list->map);
+ list->map = NULL;
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_create_mmap_offset);
+
/** Returns a reference to the object named by the handle. */
struct drm_gem_object *
drm_gem_object_lookup(struct drm_device *dev, struct drm_file *filp,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9b7c2bb..43538b6 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1624,6 +1624,9 @@ drm_gem_object_handle_unreference_unlocked(struct
drm_gem_object *obj)
drm_gem_object_unreference_unlocked(obj);
}
+void drm_gem_free_mmap_offset(struct drm_gem_object *obj);
+int drm_gem_create_mmap_offset(struct drm_gem_object *obj);
+
struct drm_gem_object *drm_gem_object_lookup(struct drm_device *dev,
struct drm_file *filp,
u32 handle);
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 6/6] drm/gma500: use common functions for get/put pages
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/staging/gma500/gtt.c | 47 ++---
1 files changed, 12 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/gma500/gtt.c b/drivers/staging/gma500/gtt.c
index 461ead2..f453321 100644
--- a/drivers/staging/gma500/gtt.c
+++ b/drivers/staging/gma500/gtt.c
@@ -140,39 +140,21 @@ static void psb_gtt_remove(struct drm_device *dev, struct
gtt_range *r)
*/
static int psb_gtt_attach_pages(struct gtt_range *gt)
{
- struct inode *inode;
- struct address_space *mapping;
- int i;
- struct page *p;
- int pages = gt->gem.size / PAGE_SIZE;
+ struct page **pages;
WARN_ON(gt->pages);
- /* This is the shared memory object that backs the GEM resource */
- inode = gt->gem.filp->f_path.dentry->d_inode;
- mapping = inode->i_mapping;
-
- gt->pages = kmalloc(pages * sizeof(struct page *), GFP_KERNEL);
- if (gt->pages == NULL)
- return -ENOMEM;
- gt->npage = pages;
-
- for (i = 0; i < pages; i++) {
- /* FIXME: review flags later */
- p = read_cache_page_gfp(mapping, i,
- __GFP_COLD | GFP_KERNEL);
- if (IS_ERR(p))
- goto err;
- gt->pages[i] = p;
+ /* FIXME: review flags later */
+ pages = drm_gem_get_pages(>->gem,
+ __GFP_DMA32 | __GFP_COLD | GFP_KERNEL);
+ if (IS_ERR(pages)) {
+ dev_err(gt->gem.dev->dev, "could not get pages: %ld\n",
+ PTR_ERR(pages));
+ return PTR_ERR(pages);
}
- return 0;
-err:
- while (i--)
- page_cache_release(gt->pages[i]);
- kfree(gt->pages);
- gt->pages = NULL;
- return PTR_ERR(p);
+ gt->pages = pages;
+ return 0;
}
/**
@@ -185,13 +167,8 @@ err:
*/
static void psb_gtt_detach_pages(struct gtt_range *gt)
{
- int i;
- for (i = 0; i < gt->npage; i++) {
- /* FIXME: do we need to force dirty */
- set_page_dirty(gt->pages[i]);
- page_cache_release(gt->pages[i]);
- }
- kfree(gt->pages);
+ /* FIXME: do we need to force dirty */
+ drm_gem_put_pages(>->gem, gt->pages, true, false);
gt->pages = NULL;
}
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 4/6] drm/gem: add functions to get/put pages
From: Rob Clark
This factors out common code from psb_gtt_attach_pages()/
i915_gem_object_get_pages_gtt() and psb_gtt_detach_pages()/
i915_gem_object_put_pages_gtt().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 68 +
include/drm/drmP.h|3 ++
2 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 396e60c..05113c3 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -285,6 +285,74 @@ again:
}
EXPORT_SYMBOL(drm_gem_handle_create);
+/**
+ * drm_gem_get_pages - helper to allocate backing pages for a GEM object
+ * @obj: obj in question
+ * @gfpmask: gfp mask of requested pages
+ */
+struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask)
+{
+ struct inode *inode;
+ struct address_space *mapping;
+ struct page *p, **pages;
+ int i, npages;
+
+ /* This is the shared memory object that backs the GEM resource */
+ inode = obj->filp->f_path.dentry->d_inode;
+ mapping = inode->i_mapping;
+
+ npages = obj->size >> PAGE_SHIFT;
+
+ pages = drm_malloc_ab(npages, sizeof(struct page *));
+ if (pages == NULL)
+ return ERR_PTR(-ENOMEM);
+
+ gfpmask |= mapping_gfp_mask(mapping);
+
+ for (i = 0; i < npages; i++) {
+ p = shmem_read_mapping_page_gfp(mapping, i, gfpmask);
+ if (IS_ERR(p))
+ goto fail;
+ pages[i] = p;
+ }
+
+ return pages;
+
+fail:
+ while (i--) {
+ page_cache_release(pages[i]);
+ }
+ drm_free_large(pages);
+ return ERR_PTR(PTR_ERR(p));
+}
+EXPORT_SYMBOL(drm_gem_get_pages);
+
+/**
+ * drm_gem_put_pages - helper to free backing pages for a GEM object
+ * @obj: obj in question
+ * @pages: pages to free
+ */
+void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
+ bool dirty, bool accessed)
+{
+ int i, npages;
+
+ npages = obj->size >> PAGE_SHIFT;
+
+ for (i = 0; i < npages; i++) {
+ if (dirty)
+ set_page_dirty(pages[i]);
+
+ if (accessed)
+ mark_page_accessed(pages[i]);
+
+ /* Undo the reference we took when populating the table */
+ page_cache_release(pages[i]);
+ }
+
+ drm_free_large(pages);
+}
+EXPORT_SYMBOL(drm_gem_put_pages);
/**
* drm_gem_free_mmap_offset - release a fake mmap offset for an object
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 43538b6..a62d8fe 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1624,6 +1624,9 @@ drm_gem_object_handle_unreference_unlocked(struct
drm_gem_object *obj)
drm_gem_object_unreference_unlocked(obj);
}
+struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask);
+void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
+ bool dirty, bool accessed);
void drm_gem_free_mmap_offset(struct drm_gem_object *obj);
int drm_gem_create_mmap_offset(struct drm_gem_object *obj);
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 5/6] drm/i915: use common functions for get/put pages
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_gem.c | 51 +++---
1 files changed, 10 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ee59f31..6b49b4e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1450,52 +1450,29 @@ static int
i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj,
gfp_t gfpmask)
{
- int page_count, i;
- struct address_space *mapping;
- struct inode *inode;
- struct page *page;
+ struct page **pages;
- /* Get the list of pages out of our struct file. They'll be pinned
-* at this point until we release them.
-*/
- page_count = obj->base.size / PAGE_SIZE;
BUG_ON(obj->pages != NULL);
- obj->pages = drm_malloc_ab(page_count, sizeof(struct page *));
- if (obj->pages == NULL)
- return -ENOMEM;
-
- inode = obj->base.filp->f_path.dentry->d_inode;
- mapping = inode->i_mapping;
- gfpmask |= mapping_gfp_mask(mapping);
- for (i = 0; i < page_count; i++) {
- page = shmem_read_mapping_page_gfp(mapping, i, gfpmask);
- if (IS_ERR(page))
- goto err_pages;
+ pages = drm_gem_get_pages(&obj->base, gfpmask);
- obj->pages[i] = page;
+ if (IS_ERR(pages)) {
+ dev_err(obj->base.dev->dev,
+ "could not get pages: %ld\n", PTR_ERR(pages));
+ return PTR_ERR(pages);
}
if (obj->tiling_mode != I915_TILING_NONE)
i915_gem_object_do_bit_17_swizzle(obj);
- return 0;
-
-err_pages:
- while (i--)
- page_cache_release(obj->pages[i]);
+ obj->pages = pages;
- drm_free_large(obj->pages);
- obj->pages = NULL;
- return PTR_ERR(page);
+ return 0;
}
static void
i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj)
{
- int page_count = obj->base.size / PAGE_SIZE;
- int i;
-
BUG_ON(obj->madv == __I915_MADV_PURGED);
if (obj->tiling_mode != I915_TILING_NONE)
@@ -1504,18 +1481,10 @@ i915_gem_object_put_pages_gtt(struct
drm_i915_gem_object *obj)
if (obj->madv == I915_MADV_DONTNEED)
obj->dirty = 0;
- for (i = 0; i < page_count; i++) {
- if (obj->dirty)
- set_page_dirty(obj->pages[i]);
-
- if (obj->madv == I915_MADV_WILLNEED)
- mark_page_accessed(obj->pages[i]);
+ drm_gem_put_pages(&obj->base, obj->pages, obj->dirty,
+ obj->madv == I915_MADV_WILLNEED);
- page_cache_release(obj->pages[i]);
- }
obj->dirty = 0;
-
- drm_free_large(obj->pages);
obj->pages = NULL;
}
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 0/6] Common functions for GEM (v2)
From: Rob Clark In the process of adding GEM support for omapdrm driver, I noticed that I was adding code for creating/freeing mmap offsets which was virtually identical to what was already duplicated in i915 and gma500 drivers. And the code for attach/detatch_pages was quite similar as well. Rather than duplicating the code a 3rd time, it seemed like a good idea to move it to the GEM core. Note that I don't actually have a way to test psb or i915, but the changes seem straightforward enough. v1: initial patches v2: rebase + add common get/put_pages functions Rob Clark (6): drm/gem: add functions for mmap offset creation drm/i915: use common functions for mmap offset creation drm/gma500: use common functions for mmap offset creation drm/gem: add functions to get/put pages drm/i915: use common functions for get/put pages drm/gma500: use common functions for get/put pages drivers/gpu/drm/drm_gem.c | 156 + drivers/gpu/drm/i915/i915_gem.c | 136 +++- drivers/staging/gma500/gem.c |2 +- drivers/staging/gma500/gem_glue.c | 61 +-- drivers/staging/gma500/gem_glue.h |1 - drivers/staging/gma500/gtt.c | 47 +++ include/drm/drmP.h|6 ++ 7 files changed, 188 insertions(+), 221 deletions(-) -- 1.7.5.4 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 3/6] drm/gma500: use common functions for mmap offset creation
From: Rob Clark
Signed-off-by: Rob Clark
Signed-off-by: Alan Cox
---
drivers/staging/gma500/gem.c |2 +-
drivers/staging/gma500/gem_glue.c | 61 +
drivers/staging/gma500/gem_glue.h |1 -
3 files changed, 2 insertions(+), 62 deletions(-)
diff --git a/drivers/staging/gma500/gem.c b/drivers/staging/gma500/gem.c
index 65fdd6b..1ac438a 100644
--- a/drivers/staging/gma500/gem.c
+++ b/drivers/staging/gma500/gem.c
@@ -77,7 +77,7 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct
drm_device *dev,
/* Make it mmapable */
if (!obj->map_list.map) {
- ret = gem_create_mmap_offset(obj);
+ ret = drm_gem_create_mmap_offset(obj);
if (ret)
goto out;
}
diff --git a/drivers/staging/gma500/gem_glue.c
b/drivers/staging/gma500/gem_glue.c
index daac121..90e5f98 100644
--- a/drivers/staging/gma500/gem_glue.c
+++ b/drivers/staging/gma500/gem_glue.c
@@ -24,66 +24,7 @@ void drm_gem_object_release_wrap(struct drm_gem_object *obj)
{
/* Remove the list map if one is present */
if (obj->map_list.map) {
- struct drm_gem_mm *mm = obj->dev->mm_private;
- struct drm_map_list *list = &obj->map_list;
- drm_ht_remove_item(&mm->offset_hash, &list->hash);
- drm_mm_put_block(list->file_offset_node);
- kfree(list->map);
- list->map = NULL;
+ drm_gem_free_mmap_offset(obj);
}
drm_gem_object_release(obj);
}
-
-/**
- * gem_create_mmap_offset - invent an mmap offset
- * @obj: our object
- *
- * Standard implementation of offset generation for mmap as is
- * duplicated in several drivers. This belongs in GEM.
- */
-int gem_create_mmap_offset(struct drm_gem_object *obj)
-{
- struct drm_device *dev = obj->dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list;
- struct drm_local_map *map;
- int ret;
-
- list = &obj->map_list;
- list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
- if (list->map == NULL)
- return -ENOMEM;
- map = list->map;
- map->type = _DRM_GEM;
- map->size = obj->size;
- map->handle = obj;
-
- list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
- obj->size / PAGE_SIZE, 0, 0);
- if (!list->file_offset_node) {
- dev_err(dev->dev, "failed to allocate offset for bo %d\n",
- obj->name);
- ret = -ENOSPC;
- goto free_it;
- }
- list->file_offset_node = drm_mm_get_block(list->file_offset_node,
- obj->size / PAGE_SIZE, 0);
- if (!list->file_offset_node) {
- ret = -ENOMEM;
- goto free_it;
- }
- list->hash.key = list->file_offset_node->start;
- ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
- if (ret) {
- dev_err(dev->dev, "failed to add to map hash\n");
- goto free_mm;
- }
- return 0;
-
-free_mm:
- drm_mm_put_block(list->file_offset_node);
-free_it:
- kfree(list->map);
- list->map = NULL;
- return ret;
-}
diff --git a/drivers/staging/gma500/gem_glue.h
b/drivers/staging/gma500/gem_glue.h
index ce5ce30..891b7b6 100644
--- a/drivers/staging/gma500/gem_glue.h
+++ b/drivers/staging/gma500/gem_glue.h
@@ -1,2 +1 @@
extern void drm_gem_object_release_wrap(struct drm_gem_object *obj);
-extern int gem_create_mmap_offset(struct drm_gem_object *obj);
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/6] drm/i915: use common functions for mmap offset creation
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_gem.c | 85 +--
1 files changed, 2 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a546a71..ee59f31 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1265,74 +1265,6 @@ out:
}
/**
- * i915_gem_create_mmap_offset - create a fake mmap offset for an object
- * @obj: obj in question
- *
- * GEM memory mapping works by handing back to userspace a fake mmap offset
- * it can use in a subsequent mmap(2) call. The DRM core code then looks
- * up the object based on the offset and sets up the various memory mapping
- * structures.
- *
- * This routine allocates and attaches a fake offset for @obj.
- */
-static int
-i915_gem_create_mmap_offset(struct drm_i915_gem_object *obj)
-{
- struct drm_device *dev = obj->base.dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list;
- struct drm_local_map *map;
- int ret = 0;
-
- /* Set the object up for mmap'ing */
- list = &obj->base.map_list;
- list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
- if (!list->map)
- return -ENOMEM;
-
- map = list->map;
- map->type = _DRM_GEM;
- map->size = obj->base.size;
- map->handle = obj;
-
- /* Get a DRM GEM mmap offset allocated... */
- list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
- obj->base.size / PAGE_SIZE,
- 0, 0);
- if (!list->file_offset_node) {
- DRM_ERROR("failed to allocate offset for bo %d\n",
- obj->base.name);
- ret = -ENOSPC;
- goto out_free_list;
- }
-
- list->file_offset_node = drm_mm_get_block(list->file_offset_node,
- obj->base.size / PAGE_SIZE,
- 0);
- if (!list->file_offset_node) {
- ret = -ENOMEM;
- goto out_free_list;
- }
-
- list->hash.key = list->file_offset_node->start;
- ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
- if (ret) {
- DRM_ERROR("failed to add to map hash\n");
- goto out_free_mm;
- }
-
- return 0;
-
-out_free_mm:
- drm_mm_put_block(list->file_offset_node);
-out_free_list:
- kfree(list->map);
- list->map = NULL;
-
- return ret;
-}
-
-/**
* i915_gem_release_mmap - remove physical page mappings
* @obj: obj in question
*
@@ -1360,19 +1292,6 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
obj->fault_mappable = false;
}
-static void
-i915_gem_free_mmap_offset(struct drm_i915_gem_object *obj)
-{
- struct drm_device *dev = obj->base.dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list = &obj->base.map_list;
-
- drm_ht_remove_item(&mm->offset_hash, &list->hash);
- drm_mm_put_block(list->file_offset_node);
- kfree(list->map);
- list->map = NULL;
-}
-
static uint32_t
i915_gem_get_gtt_size(struct drm_device *dev, uint32_t size, int tiling_mode)
{
@@ -1485,7 +1404,7 @@ i915_gem_mmap_gtt(struct drm_file *file,
}
if (!obj->base.map_list.map) {
- ret = i915_gem_create_mmap_offset(obj);
+ ret = drm_gem_create_mmap_offset(&obj->base);
if (ret)
goto out;
}
@@ -3752,7 +3671,7 @@ static void i915_gem_free_object_tail(struct
drm_i915_gem_object *obj)
trace_i915_gem_object_destroy(obj);
if (obj->base.map_list.map)
- i915_gem_free_mmap_offset(obj);
+ drm_gem_free_mmap_offset(&obj->base);
drm_gem_object_release(&obj->base);
i915_gem_info_remove_obj(dev_priv, obj->base.size);
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 6/6] drm/gma500: use common functions for get/put pages
On Mon, Sep 12, 2011 at 3:31 PM, Alan Cox wrote: > On Mon, 12 Sep 2011 14:21:26 -0500 > Rob Clark wrote: > >> From: Rob Clark >> >> Signed-off-by: Rob Clark > > Generally looks sensible but: > > 1. This is a staging driver, so good practise is to cc the staging > maintainer and preferably the author (though I'm on dri-devel so its ok). > It needs to be co-ordinated with existing staging changes and the > maintainer needs to know what is going on ok, will do that in the future > 2. It needs a changelog. Your 0/6 won't be in the git tree and someone > chasing regressions may only see the individual patch changelog and not > be sure what it relates to. From/Signed off by alone is not helpful. ok.. in this case the changelog only applied to the first patches (initial patchset didn't have the drm_gem_get/put_pages()) but I will do this in the future as needed > 3. GMA500 used the old way of doing things because last mail conversation > I had with Hugh the cleaned up interfaces could not guarantee the page is > mapped in the low 32bits and for any of the GMA500/600 series devices. > > Has that changed ? I think I'd also prefer it if the methods had a > BUG_ON() getting a high page when they asked for DMA32. Hmm, ok, I found this thread, which is I guess what you are referring to: https://lkml.org/lkml/2011/7/11/269 I'm not really sure if anything has changed.. But it doesn't look like the gma500 driver ever unpins anything.. so I guess it isn't a problem (yet). (Well, either that or I am overlooking something.) btw, I could be missing something, but it seems like as long as you remove the pages from any userspace mmap'ing before you unpin the pages, that you shouldn't hit the case of page getting swapped back in >4gb.. if you are always in control of bringing the page back into memory, you can ensure that DMA32 is always specified. Not sure if that helps at all. But at some point in the not too distant future, I'll be in the same boat so I am interested in a good way to handle this. re: BUG_ON(): I wonder if a check would better belong in shmem_read_mapping_page_gfp() or shmem_getpage_gfp()? BR, -R > > Alan > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 4/6] drm/gem: add functions to get/put pages
On Mon, Sep 12, 2011 at 2:21 PM, Rob Clark wrote:
> From: Rob Clark
>
> This factors out common code from psb_gtt_attach_pages()/
> i915_gem_object_get_pages_gtt() and psb_gtt_detach_pages()/
> i915_gem_object_put_pages_gtt().
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem.c | 68
> +
> include/drm/drmP.h | 3 ++
> 2 files changed, 71 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 396e60c..05113c3 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -285,6 +285,74 @@ again:
> }
> EXPORT_SYMBOL(drm_gem_handle_create);
>
> +/**
> + * drm_gem_get_pages - helper to allocate backing pages for a GEM object
> + * @obj: obj in question
> + * @gfpmask: gfp mask of requested pages
> + */
> +struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask)
> +{
> + struct inode *inode;
> + struct address_space *mapping;
> + struct page *p, **pages;
> + int i, npages;
> +
> + /* This is the shared memory object that backs the GEM resource */
> + inode = obj->filp->f_path.dentry->d_inode;
> + mapping = inode->i_mapping;
> +
> + npages = obj->size >> PAGE_SHIFT;
> +
> + pages = drm_malloc_ab(npages, sizeof(struct page *));
> + if (pages == NULL)
> + return ERR_PTR(-ENOMEM);
> +
> + gfpmask |= mapping_gfp_mask(mapping);
> +
> + for (i = 0; i < npages; i++) {
> + p = shmem_read_mapping_page_gfp(mapping, i, gfpmask);
note: I'll send an updated version of this patch w/ a
BUG_ON((gfpmask & __GFP_DMA32) && (page_to_pfn(p) >= 0x0010UL));
or something roughly like this, to catch cases where
shmem_read_mapping_page_gfp() doesn't actually give us a page in the
low 4GB..
It is only a theoretical issue currently, as (AFAIK) no devices w/ 4GB
restriction currently have enough memory to hit this problem. But it
would be good to have some error checking in case
shmem_read_mapping_page_gfp() isn't fixed by the time we have devices
that would have this problem.
BR,
-R
> + if (IS_ERR(p))
> + goto fail;
> + pages[i] = p;
> + }
> +
> + return pages;
> +
> +fail:
> + while (i--) {
> + page_cache_release(pages[i]);
> + }
> + drm_free_large(pages);
> + return ERR_PTR(PTR_ERR(p));
> +}
> +EXPORT_SYMBOL(drm_gem_get_pages);
> +
> +/**
> + * drm_gem_put_pages - helper to free backing pages for a GEM object
> + * @obj: obj in question
> + * @pages: pages to free
> + */
> +void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
> + bool dirty, bool accessed)
> +{
> + int i, npages;
> +
> + npages = obj->size >> PAGE_SHIFT;
> +
> + for (i = 0; i < npages; i++) {
> + if (dirty)
> + set_page_dirty(pages[i]);
> +
> + if (accessed)
> + mark_page_accessed(pages[i]);
> +
> + /* Undo the reference we took when populating the table */
> + page_cache_release(pages[i]);
> + }
> +
> + drm_free_large(pages);
> +}
> +EXPORT_SYMBOL(drm_gem_put_pages);
>
> /**
> * drm_gem_free_mmap_offset - release a fake mmap offset for an object
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 43538b6..a62d8fe 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1624,6 +1624,9 @@ drm_gem_object_handle_unreference_unlocked(struct
> drm_gem_object *obj)
> drm_gem_object_unreference_unlocked(obj);
> }
>
> +struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask);
> +void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
> + bool dirty, bool accessed);
> void drm_gem_free_mmap_offset(struct drm_gem_object *obj);
> int drm_gem_create_mmap_offset(struct drm_gem_object *obj);
>
> --
> 1.7.5.4
>
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
On Wed, Sep 14, 2011 at 12:44 AM, Inki Dae wrote:
> Hello Rob.
> Sorry for being late. here was a national holiday.
>
>
>> -Original Message-
>> From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of Rob
>> Clark
>> Sent: Thursday, September 08, 2011 3:44 AM
>> To: Inki Dae
>> Cc: linaro-dev@lists.linaro.org; dri-de...@lists.freedesktop.org
>> Subject: Re: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
>>
>> On Wed, Sep 7, 2011 at 1:00 AM, Inki Dae wrote:
>> > Hello, Rob.
>> >
>> [snip]
>> >> >> +static void page_flip_cb(void *arg)
>> >> >> +{
>> >> >> + struct drm_crtc *crtc = arg;
>> >> >> + struct drm_device *dev = crtc->dev;
>> >> >> + struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>> >> >> + struct drm_pending_vblank_event *event = omap_crtc->event;
>> >> >> + struct timeval now;
>> >> >> + unsigned long flags;
>> >> >> +
>> >> >> + WARN_ON(!event);
>> >> >> +
>> >> >> + omap_crtc->event = NULL;
>> >> >> +
>> >> >> + update_scanout(crtc);
>> >> >> + commit(crtc);
>> >> >> +
>> >> >> + /* wakeup userspace */
>> >> >> + // TODO: this should happen *after* flip.. somehow..
>> >> >> + if (event) {
>> >> >> + spin_lock_irqsave(&dev->event_lock, flags);
>> >> >> + event->event.sequence =
>> >> >> + drm_vblank_count_and_time(dev,
>> >> > omap_crtc->id,
>> >> >> &now);
>> >> >> + event->event.tv_sec = now.tv_sec;
>> >> >> + event->event.tv_usec = now.tv_usec;
>> >> >> + list_add_tail(&event->base.link,
>> >> >> + &event->base.file_priv->event_list);
>> >> >> +
>> > wake_up_interruptible(&event->base.file_priv->event_wait);
>> >> >> + spin_unlock_irqrestore(&dev->event_lock, flags);
>> >> >> + }
>> >> >
>> >> > How about moving codes above into interrupt handler for vblank?
>> >> > maybe there
>> >>
>> >> I should mention a couple of things:
>> >>
>> >> 1) drm vblank stuff isn't really used currently.. it is actually DSS2
>> >> layer that is registering for the display related interrupt(s). I'm
>> >> not really sure how to handle this best. I suppose the DRM driver
>> >> could *also* register for these interrupts, but that seems a bit odd..
>> >>
>> >
>> > DRM Framework supports only one interrupt handler. this issue should be
>> > resolved. and currently I made our driver to use its own request_irq,
>> not
>> > DRM Framework side. we only sets drm_device->irq_enabled to 1 and
>> interrupt
>> > handler is registered at display controller or hdmi driver respectively.
>> but
>> > I'm not sure that this way is best so I will look over more. Anyway
>> current
>> > drm framework should be fixed to be considered with multiple irq.
>>
>> Or perhaps even callbacks (some other driver handling the irq's directly)?
>>
>
> Yes.
>
>> >> Also, I guess it is also worth mentioning.. when it comes to vblank,
>> >> there are two fundamentally different sorts of displays we deal with.
>> >> Something like DVI/HDMI/etc which need constant refreshing. In these
>> >> cases we constantly scan-out the buffer until the next page
>> >> flip+vsync. And smart panels, where they get scanned out once and
>> >> then DSS is no longer reading the scanout buffer until we manually
>> >> trigger an update.
>> >>
>> >
>> > Is the Smart panel CPU interface based lcd panel that has its own
>> > framebuffer internally.?
>>
>> yes
>>
>
> CPU Interface based lcd panel needs manual updating once all contents of
> internal framebuffer are transferred to panel. thus, the Smart Panel(cpu
> interface based lcd panel) has advantage of power consumption with
> user-requested update. this means application should trigger display
> controller to be transferred to lcd panel at framedone signal of lcd p
Re: Proposal for a low-level Linux display framework
On Thu, Sep 15, 2011 at 12:21 PM, Tomi Valkeinen wrote: > On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote: >> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen >> wrote: >> >> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if >> > the plan is to make DRM the core Linux display framework, upon which >> > everything else is built, and fb and v4l2 are changed to use DRM. >> >> I'd like to think we could make DRM the underlying display framework; >> it already exposes an fb interface, and with overlays, a bit more of the >> v4l2 stuff is done as well. Certainly eliminating three copies of mode >> setting infrastructure would be nice... > > Ok, sounds good to me. We (as in OMAP display people) are already > planning to take DRM into use, so no problem there. > >> > But even if it was done like that, I see that it's combining two >> > separate things: 1) the lower level HW control, and 2) the upper level >> > buffer management, policies and userspace interfaces. >> >> Those are split between the DRM layer and the underlying device driver, >> which provides both kernel (via fb) and user space interfaces. > > I'm not so familiar with DRM, but with device driver you mean a driver > for the the hardware which handles display output (gfx cards or whatever > it is on that platform)? I think he is more referring to the DRM core and the individual device drivers.. We are (AFAIK) unique in having a two layer driver, where the DRM part is more of a wrapper (for the KMS parts)... but I see that as more of a transition thing.. eventually we should be able to merge it all into the DRM layer. > If so, it sounds good. That quite well matches what omapdss driver does > currently for us. But we still have semi-complex omapdrm between omapdss > and the standard drm layer. > > Rob, would you say omapdrm is more of a DRM wrapper for omapdss than a > real separate entity? If so, then we could possibly in the future (when > nobody else uses omapdss) change omapdss to support DRM natively. (or > make omapdrm support omap HW natively, which ever way =). Yeah, I think eventually it would make sense to merge all into one. Although I'm not sure about how best to handle various different custom DSI panels.. BR, -R >> > 2) It's missing the panel driver part. This is rather important on >> > embedded systems, as the panels often are not "dummy" panels, but they >> > need things like custom initialization, sending commands to adjust >> > backlight, etc. >> >> We integrate the panel (and other video output) drivers into the device >> drivers. With desktop chips, they're not easily separable. None of the >> desktop output drivers are simple; things like DisplayPort require link >> training, and everyone needs EDID. We share some of that code in the DRM >> layer today, and it would be nice to share even more. > > I don't think we speak of similar panel drivers. I think there are two > different drivers here: > > 1) output drivers, handles the output from the SoC / gfx card. For > example DVI, DisplayPort, MIPI DPI/DBI/DSI. > > 2) panel drivers, handles panel specific things. Each panel may support > custom commands and features, for which we need a dedicated driver. And > this driver is not platform specific, but should work with any platform > which has the output used with the panel. > > As an example, DSI command mode displays can be quite complex: > > DSI bus is a half-duplex serial bus, and while it's designed for > displays you could use it easily for any communication between the SoC > and the peripheral. > > The panel could have a feature like content adaptive backlight control, > and this would be configured via the DSI bus, sending a particular > command to the panel (possibly by first reading something from the > panel). The panel driver would accomplish this more or less the same way > one uses, say, i2c, so it would use the platform's DSI support to send > and receive packets. > > Or a more complex scenario (but still a realistic scenario, been there, > done that) is sending the image to the panel in multiple parts, and > between each part sending configuration commands to the panel. (and > still getting it done in time so we avoid tearing). > > And to complicate things more, there are DSI bus features like LP mode > (low power, basically low speed mode) and HS mode (high speed), virtual > channel IDs, and whatnot, which each panel may need to be used in > particular manner. Some panels may require initial configuration done in > LP, or configuration commands sent to a certain virtual channel ID. > > The point is that we cannot have standard "MIPI DSI command mode panel > driver" which would work for all DSI cmd mode panels, but we need (in > the worst case) separate driver for each panel. > > The same goes to lesser extent for other panels also. Some are > configured via i2c or spi. > > Tomi > > > ___ > dri-devel mailing list > dri-de...@lists.free
Re: Proposal for a low-level Linux display framework
On Sat, Sep 17, 2011 at 9:44 AM, Felipe Contreras wrote: > On Thu, Sep 15, 2011 at 9:58 PM, Alan Cox wrote: >>> One of my biggest problems with KMS is that it has (naturally) a lot more >>> complexity than the fb API which leads to instability. Basically it's very >> >> It shouldn't do - and a sample of one (your machine) is not a >> statistically valid set. Fb is pretty much ununsable in contrast on my >> main box, but that's not a statistically valid sample either. >> >> I'm not that convinced by the complexity either. For a simple video card >> setup such as those that the fb layer can kind of cope with (ie linear >> buffer, simple mode changes, no client rendering, no vblank flipping, >> limited mode management, no serious multi-head) a DRM driver is also >> pretty tiny and simple. > > That's not true, many drivers work around the lack of features in the > fb API by providing custom interfaces. For example, in omapfb it's > possible to use the overlays from user-space, configure some YUV > format, do vsink, and multipages just fine: > > https://github.com/felipec/gst-omapfb/blob/master/omapfb.c > > It's perfect to render video clips. Of course, it would be even better > if those custom interfaces were merged into the fb API. fwiw, as was mentioned earlier in the thread, there is already an effort underway for a standardized overlay interface for KMS: http://lists.freedesktop.org/archives/dri-devel/2011-April/010559.html Anyways, it is also possible to extend DRM drivers w/ custom API.. and even possible extend the fbdev on top of DRM/KMS with custom interfaces if you *really* wanted to. I have some patches somewhere that add support a portion of the omapfb ioctls to the fbdev layer in omapdrm driver for the benefit of some legacy display test app. If someone really wanted to, I guess there is no reason that you couldn't support all of the omapfb custom ioctls. >From userspace perspective, fbdev doesn't go away. It is just a legacy interface provided on top of DRM/KMS driver mostly via helper functions. With this approach, you get the richer KMS API (and all the related plumbing for hotplug, EDID parsing, multi-head support, flipping, etc) for userspace stuff that needs that, but can keep the fbdev userspace interface for legacy apps. It is the best of both worlds. There isn't really any good reason to propagate standalone fbdev driver anymore. BR, -R > -- > Felipe Contreras > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Proposal for a low-level Linux display framework
On Sat, Sep 17, 2011 at 11:11 AM, Florian Tobias Schandinat wrote: > On 09/17/2011 03:16 PM, Rob Clark wrote: >>>From userspace perspective, fbdev doesn't go away. It is just a >> legacy interface provided on top of DRM/KMS driver mostly via helper >> functions. With this approach, you get the richer KMS API (and all >> the related plumbing for hotplug, EDID parsing, multi-head support, >> flipping, etc) for userspace stuff that needs that, but can keep the >> fbdev userspace interface for legacy apps. It is the best of both >> worlds. There isn't really any good reason to propagate standalone >> fbdev driver anymore. > > I disagree. This depends on the functionality the hardware has, the desired > userspace and the manpower one has to do it. And of course if you just want fb > having fb via DRM/KMS has some overhead/bloat. It's perfectly okay to have > just > an fb driver for devices that can't do more anyway. > And fb is no legacy interface but actively developed, just with other goals > than > DRM/KMS is, it aims for stability and to provide a direct interface, not > needing > any X or wayland crap. Hmm, for simple enough devices, maybe fb is fine.. but if you are covering a range of devices which include stuff with more sophisticated userspace (X/wayland), then just doing DRM/KMS and using the DRM fbdev helpers, vs doing both DRM/KMS and standalone fbdev.. well that seems like a no-brainer. I still think, if you are starting a new driver, you should just go ahead and use DRM/KMS.. a simple DRM/KMS driver that doesn't support all the features is not so complex, and going this route future-proofs you better when future generations of hardware gain more capabilities and sw gain more requirements. BR, -R > > Best regards, > > Florian Tobias Schandinat > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Proposal for a low-level Linux display framework
On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart wrote: > Hi everybody, > > On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote: >> On 09/15/2011 05:52 PM, Alex Deucher wrote: >> > >> > Please don't claim that the DRM developers do not want to cooperate. >> > I realize that people have strong opinions about existing APIs, put >> > there has been just as much, if not more obstinacy from the v4l and fb >> > people. >> >> Well, I think it's too late to really fix this thing. We now have 3 APIs in >> the kernel that have to be kept. Probably the best we can do now is figure >> out how we can reduce code duplication and do extensions to those APIs in >> a way that they are compatible with each other or completely independent >> and can be used across the APIs. > > Sorry for jumping late into the discussion. Let me try to shed some new light > on this. > > I've been thinking about the DRM/KMS/FB/V4L APIs overlap for quite some time > now. All of them have their share of issues, historical nonsense and unique > features. I don't think we can pick one of those APIs today and decide to drop > the others, but we certainly need to make DRM, KMS, FB and V4L interoperable > at various levels. The alternative is to keep ignoring each other and let the > market decice. I think we need to differentiate between V4L camera, and display.. MC and subdev stuff clearly seem to be the way to go for complex camera / imaging subsystems. But that is a very different problem domain from GPU+display. We need to stop blurring the two topics. > Thinking that the market could pick something like OpenMAX > scares me, so I'd rather find a good compromise and move forward. > > Disclaimer: My DRM/KMS knowledge isn't as good as my FB and V4L knowledge, so > please feel free to correct my mistakes. > > All our video-related APIs started as solutions to different problems. They > all share an important feature: they assume that the devices they control is > more or less monolithic. For that reason they expose a single device to > userspace, and mix device configuration and data transfer on the same device > node. > > This shortcoming became painful in V4L a couple of years ago. When I started > working on the OMAP3 ISP (camera) driver I realized that trying to configure a > complex hardware pipeline without exposing its internals to userspace > applications wouldn't be possible. DRM, KMS and FB ran into the exact same > problem, just more recently, as showed by various RFCs ([1], [2]). But I do think that overlays need to be part of the DRM/KMS interface, simply because flipping still needs to be synchronized w/ the GPU. I have some experience using V4L for display, and this is one (of several) broken aspects of that. > To fix this issue, the V4L community developed a new API called the Media > Controller [3]. In a nutshell, the MC aims at > > - exposing the device topology to userspace as an oriented graph of entities > connected with links through pads > > - controlling the device topology from userspace by enabling/disabling links > > - giving userspace access to per-entity controls > > - configuring formats at individual points in the pipeline from userspace. > > The MC API solves the first two problems. The last two require help from V4L > (which has been extended with new MC-aware ioctls), as MC is media-agnostic > and can't thus configure video formats. > > To support this, the V4L subsystem exposes an in-kernel API based around the > concept of sub-devices. A single high-level hardware device is handled by > multiple sub-devices, possibly controlled by different drivers. For instance, > in the OMAP3-based N900 digital camera, the OMAP3 ISP is made of 8 sub-devices > (all controlled by the OMAP3 ISP driver), and the two sensors, flash > controller and lens controller all have their own sub-device, each of them > controlled by its own driver. > > All this infrastructure exposes the devices a the graph showed in [4] to > applications, and the V4L sub-device API can be used to set formats at > individual pads. This allows controlling scaling, cropping, composing and > other video-related operations on the pipeline. > > With the introduction of the media controller architecture, I now see V4L as > being made of three parts. > > 1. The V4L video nodes streaming API, used to manage video buffers memory, map > it to userspace, and control video streaming (and data transfers). > > 2. The V4L sub-devices API, used to control parameters on individual entities > in the graph and configure formats. > > 3. The V4L video nodes formats and control API, used to perform the same tasks > as the V4L sub-devices API for drivers that don't support the media controller > API, or to provide support for pure V4L applications with drivers that support > the media controller API. > > V4L is made of those three parts, but I believe it helps to think about them > individually. With today's (and tomorrow's) devices, DRM, KMS and FB are
ioctl ABI considerations for 64b ARM?
I don't suppose there are any guidelines from ARM about compatibility
between 32bit userspace and 64bit kernel on some hypothetical future
version of the ARM architecture? Some hints about what to do or not
do could perhaps save some ioctl compat glue later on down the line..
BR,
-R
-- Forwarded message --
From: Rob Clark
Date: Sun, Sep 18, 2011 at 3:15 PM
Subject: Re: [PATCH] RFCv2: omapdrm DRM/KMS driver for TI OMAP platforms
To: Thomas Hellstrom
Cc: Inki Dae , dri-de...@lists.freedesktop.org,
patc...@linaro.org
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
>>>>
[snip]
>>>>
>>>> diff --git a/include/drm/omap_drm.h b/include/drm/omap_drm.h
>>>> new file mode 100644
>>>> index 000..ea0ae8e
>>>> --- /dev/null
>>>> +++ b/include/drm/omap_drm.h
>>>> @@ -0,0 +1,111 @@
>>>> +/*
>>>> + * linux/include/drm/omap_drm.h
>>>> + *
>>>> + * Copyright (C) 2011 Texas Instruments
>>>> + * Author: Rob Clark
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> it
>>>> + * under the terms of the GNU General Public License version 2 as
>>>> published by
>>>> + * the Free Software Foundation.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful, but
>>>> WITHOUT
>>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>>>> or
>>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
>>>> License
>>>> for
>>>> + * more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> along with
>>>> + * this program. If not, see<http://www.gnu.org/licenses/>.
>>>> + */
>>>> +
>>>> +#ifndef __OMAP_DRM_H__
>>>> +#define __OMAP_DRM_H__
>>>> +
>>>> +#include "drm.h"
>>>> +
>>>> +/* Please note that modifications to all structs defined here are
>>>> + * subject to backwards-compatibility constraints.
>>>> + */
>>>> +
>>>> +#define OMAP_PARAM_CHIPSET_ID 1 /* ie. 0x3430, 0x4430, etc */
>>>> +
>>>> +struct drm_omap_param {
>>>> + uint64_t param; /* in */
>>>> + uint64_t value; /* in (set_param), out
>>>> (get_param)
>>>> */
>>>> +};
>>>> +
>>>> +struct drm_omap_get_base {
>>>> + char plugin_name[64]; /* in */
>>>> + uint32_t ioctl_base; /* out */
>>>> +};
>>>>
>>>>
>>>
>>> What about future ARM 64-bit vs 32-bit structure sizes? On x86 we always
>>> take care to make structures appearing in the drm user-space interfaces
>>> having sizes that are a multiple of 64-bits, to avoid having to maintain
>>> compat code for 32-bit apps running on 64 bit kernels. For the same
>>> reasons, structure members with 64 bit alignment requirements on 64-bit
>>> systems need to be carefully places.
>>>
>>> I don't know whether there is or will be a 64-bit ARM, but it might be
>>> worth
>>> taking into consideration.
>>>
>>
>> There isn't currently any 64-bit ARM, but it is a safe assumption that
>> there will be some day.. I guess we'll have enough fun w/ various
>> random 32b devices when LPAE arrives w/ the cortex-a15..
>>
>> I did try to make sure any uint64_t's were aligned to a 64bit offset,
>> but beyond that I confess to not being an expert on how 64 vs 32b
>> ioctl compat stuff is handled or what the issues going from 32->64b
>> are. If there are some additional considerations that should be taken
>> care of, then now is the time. So far I don't have any pointer fields
>> in any of the ioctl structs. Beyond that, I'm not entirely sure what
>> else needs to be done, but would appreciate any pointers to docs about
>> how the compat stuff works.
>>
>> BR,
>> -R
>>
>
> I've actually avoided writing compat ioctl code myself, by trying to make
> sure that structures look
Re: Proposal for a low-level Linux display framework
On Sun, Sep 18, 2011 at 5:23 PM, Alan Cox wrote: >> This would leave us with the issue of controlling formats and other >> parameters >> on the pipelines. We could keep separate DRM, KMS, FB and V4L APIs for that, > > There are some other differences that matter. The exact state and > behaviour of memory, sequencing of accesses, cache control and management > are a critical part of DRM for most GPUs, as is the ability to have them > in swap backed objects and to do memory management of them. Fences and > the like are a big part of the logic of many renderers and the same > fencing has to be applied between capture and GPU, and also in some cases > between playback accelerators (eg MP4 playback) and GPU. > > To glue them together I think you'd need to support the use of GEM objects > (maybe extended) in V4L. That may actually make life cleaner and simpler > in some respects because GEM objects are refcounted nicely and have > handles. fwiw, I think the dmabuf proposal that linaro GWG is working on should be sufficient for V4L to capture directly into a GEM buffer that can be scanned out (overlay) or composited by GPU, etc, in cases where the different dma initiators can all access some common memory: http://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000616.html The idea is that you could allocate a GEM buffer, export a dmabuf handle for that buffer that could be passed to v4l2 camera device (ie. V4L2_MEMORY_DMABUF), video encoder, etc.. the importing device should bracket DMA to/from the buffer w/ get/put_scatterlist() so an unused buffer could be unpinned if needed. > DRM and KMS abstract out stuff into what is akin to V4L subdevices for > the various objects the video card has that matter for display - from > scanout buffers to the various video outputs, timings and the like. > > I don't know what it's like with OMAP but for some of the x86 stuff > particularly low speed/power stuff the capture devices, GPU and overlays > tend to be fairly incestuous in order to do things like 1080i/p preview > while recording from the camera. We don't like extra memcpy's, but something like dmabuf fits us nicely.. and I expect it would work well in any sort of UMA system where camera, encoder, GPU, overlay, etc all can share the same memory and formats. I suspect the situation is similar in the x86 SoC world.. but would be good to get some feedback on the proposal. (I guess next version of the RFC would go out to more mailing lists for broader review.) BR, -R > GPU is also a bit weird in some ways because while its normally > nonsensical to do things like use the capture facility one card to drive > part of another, it's actually rather useful (although not supported > really by DRM) to do exactly that with GPUs. A simple example is a dual > headed box with a dumb frame buffer and an accelerated output both of > which are using memory that can be hit by the accelerated card. Classic > example being a USB plug in monitor. > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ioctl ABI considerations for 64b ARM?
On Mon, Sep 19, 2011 at 2:15 AM, Arnd Bergmann wrote: > On Sunday 18 September 2011 15:24:37 Rob Clark wrote: >> I don't suppose there are any guidelines from ARM about compatibility >> between 32bit userspace and 64bit kernel on some hypothetical future >> version of the ARM architecture? Some hints about what to do or not >> do could perhaps save some ioctl compat glue later on down the line.. > > There are some rules that should be followed regardless: > > * ioctl commands should never be written in an architecture specific > way. In the example of the OMAP driver, you definitely want to be > able ot use the same command when running Linux on the C6x DSP. > > * If possible, use only scalar values as ioctl arguments > > * Avoid types that are register sized: 'long', 'size_t', pointer. > Instead use only __u8, __u16, __u32 and __u64 and their signed > versions. ok.. I'm using stdint types (ie. uint8_t, etc..) so same result > * If you use structures, try very hard to avoid pointers in them, > it messes up all sorts of tools. > > * If you use structures, make all members naturally aligned, and pad > the size of the structures to a multiple of the maximum member size. > > * Never put sub-command numbers into a structure. I didn't get this comment.. what is special about sub-command #'s? BR, -R >> > But since there is no 64-bit ARM yet, it might be better to rely on using >> > compat code in the future than on making guesses about alignment >> > restrictions of the ABI... >> >> hmm, it might be nice to get some guidelines from ARM on this, since I >> really have no idea what a 64b ARM architecture would look like... > > Assuming that we can prevent any funny stuff from going into such an ABI, > we only need to worry about the warts of the current ABI for ARM specific > considerations. The one thing that I've noticed before is that structs > on ARM (at least on one of the ABIs, forgot which) are padded to 32 bits, > even if all members inside are smaller. > > It would be a huge pain if a 64 bit ABI had /different/ padding rules > here, like not padding (logical choice by itself, but hurts is here), > or padding everything to 64 bits (maybe not worth porting the kernel to > then). > > Arnd > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ioctl ABI considerations for 64b ARM?
On Mon, Sep 19, 2011 at 10:39 AM, Will Deacon wrote: > Arnd, > > On Mon, Sep 19, 2011 at 08:15:45AM +0100, Arnd Bergmann wrote: >> Assuming that we can prevent any funny stuff from going into such an ABI, >> we only need to worry about the warts of the current ABI for ARM specific >> considerations. The one thing that I've noticed before is that structs >> on ARM (at least on one of the ABIs, forgot which) are padded to 32 bits, >> even if all members inside are smaller. > > This is only the case for the old ABI. EABI lays out structures so that they > are aligned to their most aligned member and padded to be the smallest > possible multiple of that alignment which can contain all of their aligned > members. Hmm, so then since you can build the kernel w/ OABI compatibility, it seems like structs should always have padding fields to force them to be a multiple of 32bits... BR, -R > It's described more formally in the PCS document: > > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf > > Will > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
arm 0-day kernel builders?
Btw, not sure if any of you have seen the 0-day kbuild setup that intel has.. https://lists.01.org/mailman/listinfo/kbuild runs various builds for different archs on every commit with different configs, randconfig, etc. And various checks with sparse, smatch, etc. Seems kinda useful, and would be a worthwhile goal to get arm arch to the point of "it just compiles and boots" like x86 is, vs arm which has a lot higher tendency to be broken if you don't have the right kernel config, etc. I guess on x86, they boot test all the kernels too on VMs. Perhaps we could go one better with something tied in to lava? BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: arm 0-day kernel builders?
On Mon, Jan 21, 2013 at 12:11 PM, John Stultz wrote: > On 01/20/2013 06:57 AM, Rob Clark wrote: >> >> Btw, not sure if any of you have seen the 0-day kbuild setup that intel >> has.. >> >> https://lists.01.org/mailman/listinfo/kbuild >> >> runs various builds for different archs on every commit with different >> configs, randconfig, etc. And various checks with sparse, smatch, >> etc. Seems kinda useful, and would be a worthwhile goal to get arm >> arch to the point of "it just compiles and boots" like x86 is, vs arm >> which has a lot higher tendency to be broken if you don't have the >> right kernel config, etc. I guess on x86, they boot test all the >> kernels too on VMs. Perhaps we could go one better with something >> tied in to lava? > > > +1 on this, Rob. > > Just about every time I go to bump kernel revisions for the linaro.android > tree, and actually try to build and boot on a board, I regularly hit compile > and boot issues. > > Although for the boot issues, there's still the hard problem for > hardware-simpletons like me in being able to figure out what configs I > actually need to enable (especially as those options change over time). I > suspect these sorts of problems are unlikely to be something we can test > away, and instead need a more critical eye as to how the kconfig options are > added (so there's less of a random set of options that you have to pick the > right combination, and more of the existing physical dependencies being > properly stating in the kconfig - but I realize this is more complicated to > do then say). well, at least for build test, randconfig is actually good for tracking down missing 'select XYZ's.. although I suppose I wouldn't expect every random config to boot, at least not in a meaningful way.. BR, -R > thanks > -john > > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
gallium llvmpipe for ppc, why not arm/neon yet?
http://www.phoronix.com/scan.php?page=news_item&px=MTI5OTM just sayin.. linaro has the right people w/ toolchain and neon expertise. We may be getting closer to the point of viable opensrc 3d drivers, but having a decent fallback when no opensrc 3d driver and no blob driver is available still seems like a good thing. And I bet you it could run circles around android's sw gles implementation. BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: gallium llvmpipe for ppc, why not arm/neon yet?
oh, cool :-) On Mon, Feb 11, 2013 at 9:33 PM, Thomas Gall wrote: > It's already a session at Linaro Connect in March. ;-) > > Regards > Tom > > On Feb 11, 2013, at 8:16 PM, Rob Clark wrote: > >> http://www.phoronix.com/scan.php?page=news_item&px=MTI5OTM >> >> just sayin.. linaro has the right people w/ toolchain and neon >> expertise. We may be getting closer to the point of viable opensrc 3d >> drivers, but having a decent fallback when no opensrc 3d driver and no >> blob driver is available still seems like a good thing. And I bet you >> it could run circles around android's sw gles implementation. >> >> BR, >> -R >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain.
On Wed, Apr 17, 2013 at 6:43 AM, Arnd Bergmann wrote: >> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c:#ifdef __linux__ >> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.h:#ifdef __linux__ >> drivers/scsi/dpt/osd_defs.h:#if (defined(__linux__)) >> drivers/staging/ced1401/machine.h:#if (defined(__linux__) || defined(_linux) >> || defined(__linux)) && !defined(LINUX) > > These are all drivers that are shared with another OS, or used > to be. In most of them, we can probably just remove the > #else path, since I don't think they are getting synchronized > any more. note that DRM gets periodically ported to the *BSD's, so possibly the same applies here.. BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Eclipse Day 2010
better support for cross development in linuxtools plugin would be nice, IMHO. The oprofile/systemtap/etc support looks interesting, but when I looked at it last those features were assuming that eclipse was running on the same machine that oprofile/systemtap/etc was running on. a simulated local environment might be an option, but when I looked last, qemu couldn't hack it when it came to neon/vfp. (Has there been some improvement in that area recently? I've not been keeping track.) BR, -R On Sep 3, 2010, at 7:59 AM, Tom Gall wrote: > Eclipse is certainly an interesting full function development > environment for those that want more than vim|emacs and friends from > the command line. > > How far of a solution would you advocate? > > Native on arm - edit / build / debug / perf tools / others? > edit on intel / cross build (intel -> arm) / cross debug / cross perf > tools / others? > > Should the solution have the ability to roll system images in some fashion? > > What's the definition of cross above? It is just be able to call cross > compilers or should it include the ability to deploy an app to a > remote arm system and debug it in some fashion? > > Should the solution be akin to android in the ability to run a > simulated arm system local on the box? > > Seems like perhaps a good UDS/Linaro session. > > Regards, > Tom > > On Fri, Sep 3, 2010 at 6:13 AM, Loïc Minier wrote: >>Hey >> >> Slides from Eclipse Day 2010 were just published at: >> http://wiki.eclipse.org/Eclipse_Day_At_Googleplex_2010#Presentation_Slides >> >> I think we're lacking in developers tools ATM, and found some >> presentations interesting, the two I read in full were: >>Eclipse Linux Tools Project - Andrew Overholt (Red Hat) >> which I recommend and: >>Android Tools for Eclipse - Xavier Ducrohet (Google) >> which I don't recommend. >> >> Cheers >> -- >> Loïc Minier >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev >> > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
