[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-08 Thread Lucas Stach 
Am Mittwoch, den 08.04.2015, 10:13 +1000 schrieb Dave Airlie:
> >> Okay got it.
> >>
> >> > In the common case when nothing has disturbed the context we don't want
> >> > to insert the context buffer, as we really want minimal state updates in
> >> > that case. We need a way to tell the kernel which command buffer is the
> >> > context buffer, so the kernel only splices this buffer into the stream
> >> > if the context is dirty.
> >>
> >> So the context buffer holds the full GPU context and the kernel does the 
> >> partial
> >> update of the current hardware context. This makes the user space a lot 
> >> simpler
> >> as we can send the whole context and do not need take care of partial 
> >> updates.
> >>
> >> I like the idea.
> >>
> > I still think your understanding is not completely what I wanted to say
> > with that.
> >
> > You are right that I want to kick out all this state tracking on
> > individual registers. But I don't want to move it into the kernel, but
> > scrap it altogether.
> >
> > Let me try to explain this in a bit more detail:
> >
> > First let's postulate that we already have pretty good dirty state
> > tracking on the gallium state object level. I don't think it buys us
> > anything to do more fine grained state tracking.
> >
> > The gallium userspace driver only pushes state _changes_ to a normal
> > command buffer. For example this means that if nothing has changed since
> > the last submit of this process except some vertex buffers the only
> > thing that will be contained in the command buffer are a few SET_STATEs
> > for the vertex buffer addresses and the DRAW call.
> >
> > The context buffer in contrast holds the full GPU context as of the last
> > flush. So if you flush the stream MESA dumps the full Gallium state into
> > the context buffer.
> >
> > Now if you submit both buffers together the kernel can check if your
> > context is still valid (nothing other has touched the GPU since your
> > last submit) and in that case only splice the normal command bo into the
> > stream. If something has changed since your last submit the kernel will
> > splice the context buffer first, then the command buffer. This way you
> > always get a predictable state without tracking any GPU state on a
> > register level.
> >
> 
> My memory of trying to make this work in some other driver
> in some other time is pretty bad.
> 
> I think I realised that you never had the "last known good" state, you'd just
> generate the latest state,
> 
> so it was really hard to split things into two state buffers, one containing 
> the
> "current" state and one with state updates, in the end I gave up and just
> submitted everything everytime.
> 
> I'm not saying its not possible, but the userspace driver model didn't
> lend itself
> to making it easy.
> 
Hm, this together with the argument that we have to push out all state
with relocs anyway on a single submit really makes me think we should do
away with the context buffer stuff and just dirty all state on flush in
the userspace driver.

Regards,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-08 Thread Dave Airlie 
>> Okay got it.
>>
>> > In the common case when nothing has disturbed the context we don't want
>> > to insert the context buffer, as we really want minimal state updates in
>> > that case. We need a way to tell the kernel which command buffer is the
>> > context buffer, so the kernel only splices this buffer into the stream
>> > if the context is dirty.
>>
>> So the context buffer holds the full GPU context and the kernel does the 
>> partial
>> update of the current hardware context. This makes the user space a lot 
>> simpler
>> as we can send the whole context and do not need take care of partial 
>> updates.
>>
>> I like the idea.
>>
> I still think your understanding is not completely what I wanted to say
> with that.
>
> You are right that I want to kick out all this state tracking on
> individual registers. But I don't want to move it into the kernel, but
> scrap it altogether.
>
> Let me try to explain this in a bit more detail:
>
> First let's postulate that we already have pretty good dirty state
> tracking on the gallium state object level. I don't think it buys us
> anything to do more fine grained state tracking.
>
> The gallium userspace driver only pushes state _changes_ to a normal
> command buffer. For example this means that if nothing has changed since
> the last submit of this process except some vertex buffers the only
> thing that will be contained in the command buffer are a few SET_STATEs
> for the vertex buffer addresses and the DRAW call.
>
> The context buffer in contrast holds the full GPU context as of the last
> flush. So if you flush the stream MESA dumps the full Gallium state into
> the context buffer.
>
> Now if you submit both buffers together the kernel can check if your
> context is still valid (nothing other has touched the GPU since your
> last submit) and in that case only splice the normal command bo into the
> stream. If something has changed since your last submit the kernel will
> splice the context buffer first, then the command buffer. This way you
> always get a predictable state without tracking any GPU state on a
> register level.
>

My memory of trying to make this work in some other driver
in some other time is pretty bad.

I think I realised that you never had the "last known good" state, you'd just
generate the latest state,

so it was really hard to split things into two state buffers, one containing the
"current" state and one with state updates, in the end I gave up and just
submitted everything everytime.

I'm not saying its not possible, but the userspace driver model didn't
lend itself
to making it easy.

Dave.

[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-07 Thread Jerome Glisse 
On Tue, Apr 07, 2015 at 02:52:31PM +0200, Lucas Stach wrote:
> Am Dienstag, den 07.04.2015, 11:46 +0100 schrieb Russell King - ARM
> Linux:
> > 
> > For both Vivante and Etnaviv, it's already the accepted way that 2D
> > cores need the full context loaded for each operation, and the few
> > userspace bits we have comply with that today.
> > 
> > With Etnaviv DRM, we already must ensure that the command buffer
> > submitted to the GPU contains all references to buffer objects to be
> > operated on by that command block - or to put it another way, we
> > need to ensure that each GPU operation is complete inside the command
> > submitted buffer.
> > 
> Right that's one thing that I really hadn't thought through until now.
> So this means we must at least emit all states that contain relocs,
> which may further reduce the possibility to do minimal state updates.
> Urghs.

Before trying hard to minimize the number of state emitted i would like
to encourage you to actually benchmark this and see if it really makes
a difference. I was convinced once it would be usefull but simple bench
mark proved me wrong. Like you could draw over and over a simple vbo
with bunch of states versus submitting the same vbo over and over and
submitting the states once.

Turns out on other hw the cost of tracking dirty state (cpu overhead)
was more important that the very small fraction (i think it was barely
significative in respect to the standard deviation) of performance
improvement.

[...]

> > 
> > An important question is whether the context buffer, built by userspace,
> > should be submitted as one of these command buffers, or kept separate so
> > the kernel can keep track of it and decide whether or not to use it
> > according to the state it's tracking.
> > 
> > Another point to bring up here is about how command buffers are submitted.
> > 
> > Consider this scenario:
> > 
> > - Userspace creates a command buffer, and arranges for the initial
> >   commands to be time consuming (eg, long WAIT commands.)  It fills the
> >   rest of the buffer with dummy LOAD STATE commands.
> > - Userspace submits this, the kernel validates the command buffer, and
> >   submits it to the GPU.  The GPU starts executing the buffer.
> > - Userspace, which still has access to the command buffer, overwrites
> >   the LOAD STATE commands with malicious GPU commands.
> > - GPU executes malicious GPU commands.
> > 
> > This brings up several questions:
> > 
> > 1. Do we care about this?
> > 2. If we do care, should we insist that a command buffer is not mapped
> >in userspace when it is submitted, and prevent an in-use command
> >buffer being mapped?
> > 3. If we don't care, what's the point of validating the supplied command
> >buffer?
> > 
> > (2) would be quite an API change over what we have today, and introduce
> > an amount of overhead, though something which could be handled in the
> > userspace library (eg, if we're modelling on etnaviv's five command
> > buffer model, we could copy the command buffer immediately before
> > submission.)
> > 
> > Given this, I think (3) has some value irrespective of the outcome of
> > (1) as it gives us a way to catch silly errors from userspace before
> > they hit the GPU and become a problem.
> > 
> I think we should care.
> I fail to see how this would have to be an API change. Why can't we just
> hand out buffers to userspace like we do now and copy their contents
> into an internal buffer as we validate and apply relocs?
> This model may be beneficial even without the security benefits, as we
> could hand out cached buffers to userspace, so we can read them more
> efficiently for validation and stuff things into an internal
> write-combined buffer.

You should definitly care about that. For instance in the radeon driver
for GPU we can not trust (ie gpu where userspace could access physical
memory through the gpu) we do copy the user space command buffer while
validating it inside the kernel. Yes there is an overhead for doing that
but this is the only way to have security on such GPU.

In case you have virtual address space and userspace can not reprogram
it from the command buffer than yes you can directly execute the user
cmd buffer without copying or checking it.

I would strongly advice not to give up on security.

Cheers,
Jérôme

[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-07 Thread Lucas Stach 
Am Dienstag, den 07.04.2015, 11:46 +0100 schrieb Russell King - ARM
Linux:
> On Tue, Apr 07, 2015 at 11:20:10AM +0200, Lucas Stach wrote:
> > Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner:
> > > What role does GPU power management plays here? For the context switching
> > > it could make sense. But for the 2d core the context is so small that
> > > it does not
> > > hurt to send it with every command stream. For the 3d core it is much
> > > bigger, but
> > > this could be done completely in the kernel. Or I am wrong here?
> >
> > If you power down the GPU you loose the context. You are right that we
> > could save/restore the context from kernel space, but that is really
> > taking a toll on CPU time. It is much better to have userspace provide a
> > context buffer to get the GPU in the expected state, as you then only
> > need to splice this into the execution stream to restore the context
> > instead of pushing it with the CPU. Reading back the context on every
> > switch will kill any performance.
> 
> For both Vivante and Etnaviv, it's already the accepted way that 2D
> cores need the full context loaded for each operation, and the few
> userspace bits we have comply with that today.
> 
> With Etnaviv DRM, we already must ensure that the command buffer
> submitted to the GPU contains all references to buffer objects to be
> operated on by that command block - or to put it another way, we
> need to ensure that each GPU operation is complete inside the command
> submitted buffer.
> 
Right that's one thing that I really hadn't thought through until now.
So this means we must at least emit all states that contain relocs,
which may further reduce the possibility to do minimal state updates.
Urghs.

> The 2D core is rather messy as far as which bits of state need to be
> preserved, especially when you consider that you have the 2D drawing
> and blit ops, as well as a video rasteriser which shares some state
> registers for the destination, but uses different state registers for
> the source.  It quickly becomes rather messy to keep track of the
> GPU state.
> 
> In any case, the amount of state which needs to be loaded for 2D
> operations is small, so I think it really makes sense to require
> userspace to only submit complete, fully described 2D operations
> within a single command buffer.
> 
> > > I tend to get things up and running and do the optimization step if it
> > > is really worth.
> > > Also I like stuff to be stupid simple. There is an other interesting
> > > fact: flushing the
> > > iommuv2 is done via command stream and we need to reserve more space
> > > for the tail of the used bo. So if we reserve some space in the
> > > command buffer, we have other space limits for the tail depending on
> > > used hardware.
> 
> I would much rather we only appended LINK commands to the submitted
> command BO, and added whatever GPU management commands to either the
> ring buffer (which is easy) or a separate GPU management command
> buffer.  Given that I'm already doing this to flush the V1 MMU in
> the kernel ring buffer, this is the option I prefer.
> 
> > You may be aware that once this is upstream there is no easy way to
> > change the userspace interface anymore. So whatever is left out now is
> > likely to be very hard to reintroduce later.
> 
> Indeed - we need to agree what the submited command buffer will contain,
> and how much space to enforce at the end of the command buffer.
> 
> The minimum space is one LINK command, which is 8 bytes.  As long as we
> can add a LINK command, we can redirect the GPU's execution elsewhere to
> do whatever other operations we want to do.
> 
> I think the only danger there is if Vivante produce a GPU with 64-bit
> addressing for the command stream - if they do, commands like LINK will
> most likely change format, and possibly would be a different number of
> bits.
> 
> The simple solution to this would be to introduce into the API a
> property (like is done for the feature bits) which tells userspace the
> minimum number of bytes which must be reserved at the end of the command
> buffer.  If we need to change that in the future, we have the flexibility
> to do so.
> 

Yes, that seems to be the straight forward solution. Export a property
from the kernel to signal the userspace how much free space is needed at
the end of the buffer and reject any buffer violating this.

Though I agree that we should not overuse this and try to do as much as
possible outside of the user command streams.

> > What' the problem with having a command buffer in the kernel to flush
> > the MMUv2? Why do you need to insert those commands into the userspace
> > command stream?
> 
> That's certainly where I would put it.
> 
> > > >> > +#define ETNA_SUBMIT_BO_READ 0x0001
> > > >> > +#define ETNA_SUBMIT_BO_WRITE0x0002
> > > >> > +struct drm_etnaviv_gem_submit_bo {
> > > >> > +   uint32_t flags;  /* in, mask of ETNA_SUBMIT_BO_x */
> >

[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-07 Thread Lucas Stach 
Am Dienstag, den 07.04.2015, 11:58 +0200 schrieb Christian Gmeiner:
> Hi Lucas.
> 
> 2015-04-07 11:47 GMT+02:00 Lucas Stach :
> > Am Dienstag, den 07.04.2015, 11:40 +0200 schrieb Christian Gmeiner:
> >> 2015-04-07 11:20 GMT+02:00 Lucas Stach :
> >> > Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner:
> >> >> Hi Lucas
> >> >>
> >> >> 2015-04-07 9:35 GMT+02:00 Lucas Stach :
> >> >> > Am Sonntag, den 05.04.2015, 21:26 +0200 schrieb Christian Gmeiner:
> >> >> >> 2015-04-02 17:29 GMT+02:00 Lucas Stach :
> >> >> >> > From: Christian Gmeiner 
> >> >> >> >
> >> >> >> > This is a consolidation by Russell King of Christian's drm work.
> >> >> >> >
> >> >> >> > Signed-off-by: Christian Gmeiner 
> >> >> >> > Signed-off-by: Russell King 
> >> >> >
> >> >> >> > ---
> >> >> > [...]
> >> >> >
> >> >> >> > +#endif /* STATE_HI_XML */
> >> >> >> > diff --git a/include/uapi/drm/etnaviv_drm.h 
> >> >> >> > b/include/uapi/drm/etnaviv_drm.h
> >> >> >> > new file mode 100644
> >> >> >> > index ..f7b5ac6f3842
> >> >> >> > --- /dev/null
> >> >> >> > +++ b/include/uapi/drm/etnaviv_drm.h
> >> >> >> > @@ -0,0 +1,225 @@
> >> >> >> > +/*
> >> >> >> > + * Copyright (C) 2013 Red Hat
> >> >> >> > + * 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 .
> >> >> >> > + */
> >> >> >> > +
> >> >> >> > +#ifndef __ETNAVIV_DRM_H__
> >> >> >> > +#define __ETNAVIV_DRM_H__
> >> >> >> > +
> >> >> >> > +#include 
> >> >> >> > +#include 
> >> >> >> > +
> >> >> >> > +/* Please note that modifications to all structs defined here are
> >> >> >> > + * subject to backwards-compatibility constraints:
> >> >> >> > + *  1) Do not use pointers, use uint64_t instead for 32 bit / 64 
> >> >> >> > bit
> >> >> >> > + * user/kernel compatibility
> >> >> >> > + *  2) Keep fields aligned to their size
> >> >> >> > + *  3) Because of how drm_ioctl() works, we can add new fields at
> >> >> >> > + * the end of an ioctl if some care is taken: drm_ioctl() will
> >> >> >> > + * zero out the new fields at the tail of the ioctl, so a zero
> >> >> >> > + * value should have a backwards compatible meaning.  And for
> >> >> >> > + * output params, userspace won't see the newly added output
> >> >> >> > + * fields.. so that has to be somehow ok.
> >> >> >> > + */
> >> >> >> > +
> >> >> >> > +#define ETNA_PIPE_3D  0x00
> >> >> >> > +#define ETNA_PIPE_2D  0x01
> >> >> >> > +#define ETNA_PIPE_VG  0x02
> >> >> >> > +
> >> >> >> > +#define ETNA_MAX_PIPES3
> >> >> >> > +
> >> >> >> > +/* timeouts are specified in clock-monotonic absolute times (to 
> >> >> >> > simplify
> >> >> >> > + * restarting interrupted ioctls).  The following struct is 
> >> >> >> > logically the
> >> >> >> > + * same as 'struct timespec' but 32/64b ABI safe.
> >> >> >> > + */
> >> >> >> > +struct drm_etnaviv_timespec {
> >> >> >> > +   int64_t tv_sec;  /* seconds */
> >> >> >> > +   int64_t tv_nsec; /* nanoseconds */
> >> >> >> > +};
> >> >> >> > +
> >> >> >> > +#define ETNAVIV_PARAM_GPU_MODEL 0x01
> >> >> >> > +#define ETNAVIV_PARAM_GPU_REVISION  0x02
> >> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_00x03
> >> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_10x04
> >> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_20x05
> >> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_30x06
> >> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_40x07
> >> >> >> > +
> >> >> >> > +#define ETNAVIV_PARAM_GPU_STREAM_COUNT  0x10
> >> >> >> > +#define ETNAVIV_PARAM_GPU_REGISTER_MAX  0x11
> >> >> >> > +#define ETNAVIV_PARAM_GPU_THREAD_COUNT  0x12
> >> >> >> > +#define ETNAVIV_PARAM_GPU_VERTEX_CACHE_SIZE 0x13
> >> >> >> > +#define ETNAVIV_PARAM_GPU_SHADER_CORE_COUNT 0x14
> >> >> >> > +#define ETNAVIV_PARAM_GPU_PIXEL_PIPES   0x15
> >> >> >> > +#define ETNAVIV_PARAM_GPU_VERTEX_OUTPUT_BUFFER_SIZE 0x16
> >> >> >> > +#define ETNAVIV_PARAM_GPU_BUFFER_SIZE   0x17
> >> >> >> > +#define ETNAVIV_PARAM_GPU_INSTRUCTION_COUNT 0x18
> >> >> >> > +#define

[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-07 Thread Christian Gmeiner 
Hi Lucas.

2015-04-07 11:47 GMT+02:00 Lucas Stach :
> Am Dienstag, den 07.04.2015, 11:40 +0200 schrieb Christian Gmeiner:
>> 2015-04-07 11:20 GMT+02:00 Lucas Stach :
>> > Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner:
>> >> Hi Lucas
>> >>
>> >> 2015-04-07 9:35 GMT+02:00 Lucas Stach :
>> >> > Am Sonntag, den 05.04.2015, 21:26 +0200 schrieb Christian Gmeiner:
>> >> >> 2015-04-02 17:29 GMT+02:00 Lucas Stach :
>> >> >> > From: Christian Gmeiner 
>> >> >> >
>> >> >> > This is a consolidation by Russell King of Christian's drm work.
>> >> >> >
>> >> >> > Signed-off-by: Christian Gmeiner 
>> >> >> > Signed-off-by: Russell King 
>> >> >
>> >> >> > ---
>> >> > [...]
>> >> >
>> >> >> > +#endif /* STATE_HI_XML */
>> >> >> > diff --git a/include/uapi/drm/etnaviv_drm.h 
>> >> >> > b/include/uapi/drm/etnaviv_drm.h
>> >> >> > new file mode 100644
>> >> >> > index ..f7b5ac6f3842
>> >> >> > --- /dev/null
>> >> >> > +++ b/include/uapi/drm/etnaviv_drm.h
>> >> >> > @@ -0,0 +1,225 @@
>> >> >> > +/*
>> >> >> > + * Copyright (C) 2013 Red Hat
>> >> >> > + * 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 .
>> >> >> > + */
>> >> >> > +
>> >> >> > +#ifndef __ETNAVIV_DRM_H__
>> >> >> > +#define __ETNAVIV_DRM_H__
>> >> >> > +
>> >> >> > +#include 
>> >> >> > +#include 
>> >> >> > +
>> >> >> > +/* Please note that modifications to all structs defined here are
>> >> >> > + * subject to backwards-compatibility constraints:
>> >> >> > + *  1) Do not use pointers, use uint64_t instead for 32 bit / 64 bit
>> >> >> > + * user/kernel compatibility
>> >> >> > + *  2) Keep fields aligned to their size
>> >> >> > + *  3) Because of how drm_ioctl() works, we can add new fields at
>> >> >> > + * the end of an ioctl if some care is taken: drm_ioctl() will
>> >> >> > + * zero out the new fields at the tail of the ioctl, so a zero
>> >> >> > + * value should have a backwards compatible meaning.  And for
>> >> >> > + * output params, userspace won't see the newly added output
>> >> >> > + * fields.. so that has to be somehow ok.
>> >> >> > + */
>> >> >> > +
>> >> >> > +#define ETNA_PIPE_3D  0x00
>> >> >> > +#define ETNA_PIPE_2D  0x01
>> >> >> > +#define ETNA_PIPE_VG  0x02
>> >> >> > +
>> >> >> > +#define ETNA_MAX_PIPES3
>> >> >> > +
>> >> >> > +/* timeouts are specified in clock-monotonic absolute times (to 
>> >> >> > simplify
>> >> >> > + * restarting interrupted ioctls).  The following struct is 
>> >> >> > logically the
>> >> >> > + * same as 'struct timespec' but 32/64b ABI safe.
>> >> >> > + */
>> >> >> > +struct drm_etnaviv_timespec {
>> >> >> > +   int64_t tv_sec;  /* seconds */
>> >> >> > +   int64_t tv_nsec; /* nanoseconds */
>> >> >> > +};
>> >> >> > +
>> >> >> > +#define ETNAVIV_PARAM_GPU_MODEL 0x01
>> >> >> > +#define ETNAVIV_PARAM_GPU_REVISION  0x02
>> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_00x03
>> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_10x04
>> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_20x05
>> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_30x06
>> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_40x07
>> >> >> > +
>> >> >> > +#define ETNAVIV_PARAM_GPU_STREAM_COUNT  0x10
>> >> >> > +#define ETNAVIV_PARAM_GPU_REGISTER_MAX  0x11
>> >> >> > +#define ETNAVIV_PARAM_GPU_THREAD_COUNT  0x12
>> >> >> > +#define ETNAVIV_PARAM_GPU_VERTEX_CACHE_SIZE 0x13
>> >> >> > +#define ETNAVIV_PARAM_GPU_SHADER_CORE_COUNT 0x14
>> >> >> > +#define ETNAVIV_PARAM_GPU_PIXEL_PIPES   0x15
>> >> >> > +#define ETNAVIV_PARAM_GPU_VERTEX_OUTPUT_BUFFER_SIZE 0x16
>> >> >> > +#define ETNAVIV_PARAM_GPU_BUFFER_SIZE   0x17
>> >> >> > +#define ETNAVIV_PARAM_GPU_INSTRUCTION_COUNT 0x18
>> >> >> > +#define ETNAVIV_PARAM_GPU_NUM_CONSTANTS 0x19
>> >> >> > +
>> >> >> > +//#define MSM_PARAM_GMEM_SIZE  0x02
>> >> >> > +
>> >> >> > +struct drm_etnaviv_param {
>> >> >> > +   uint32_t pipe;   /* in, ETNA_PIPE_x */
>> >> >> > +   uint32_t param;  /* in, ETNAVIV_PARAM_x

[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-07 Thread Lucas Stach 
Am Dienstag, den 07.04.2015, 11:40 +0200 schrieb Christian Gmeiner:
> 2015-04-07 11:20 GMT+02:00 Lucas Stach :
> > Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner:
> >> Hi Lucas
> >>
> >> 2015-04-07 9:35 GMT+02:00 Lucas Stach :
> >> > Am Sonntag, den 05.04.2015, 21:26 +0200 schrieb Christian Gmeiner:
> >> >> 2015-04-02 17:29 GMT+02:00 Lucas Stach :
> >> >> > From: Christian Gmeiner 
> >> >> >
> >> >> > This is a consolidation by Russell King of Christian's drm work.
> >> >> >
> >> >> > Signed-off-by: Christian Gmeiner 
> >> >> > Signed-off-by: Russell King 
> >> >
> >> >> > ---
> >> > [...]
> >> >
> >> >> > +#endif /* STATE_HI_XML */
> >> >> > diff --git a/include/uapi/drm/etnaviv_drm.h 
> >> >> > b/include/uapi/drm/etnaviv_drm.h
> >> >> > new file mode 100644
> >> >> > index ..f7b5ac6f3842
> >> >> > --- /dev/null
> >> >> > +++ b/include/uapi/drm/etnaviv_drm.h
> >> >> > @@ -0,0 +1,225 @@
> >> >> > +/*
> >> >> > + * Copyright (C) 2013 Red Hat
> >> >> > + * 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 .
> >> >> > + */
> >> >> > +
> >> >> > +#ifndef __ETNAVIV_DRM_H__
> >> >> > +#define __ETNAVIV_DRM_H__
> >> >> > +
> >> >> > +#include 
> >> >> > +#include 
> >> >> > +
> >> >> > +/* Please note that modifications to all structs defined here are
> >> >> > + * subject to backwards-compatibility constraints:
> >> >> > + *  1) Do not use pointers, use uint64_t instead for 32 bit / 64 bit
> >> >> > + * user/kernel compatibility
> >> >> > + *  2) Keep fields aligned to their size
> >> >> > + *  3) Because of how drm_ioctl() works, we can add new fields at
> >> >> > + * the end of an ioctl if some care is taken: drm_ioctl() will
> >> >> > + * zero out the new fields at the tail of the ioctl, so a zero
> >> >> > + * value should have a backwards compatible meaning.  And for
> >> >> > + * output params, userspace won't see the newly added output
> >> >> > + * fields.. so that has to be somehow ok.
> >> >> > + */
> >> >> > +
> >> >> > +#define ETNA_PIPE_3D  0x00
> >> >> > +#define ETNA_PIPE_2D  0x01
> >> >> > +#define ETNA_PIPE_VG  0x02
> >> >> > +
> >> >> > +#define ETNA_MAX_PIPES3
> >> >> > +
> >> >> > +/* timeouts are specified in clock-monotonic absolute times (to 
> >> >> > simplify
> >> >> > + * restarting interrupted ioctls).  The following struct is 
> >> >> > logically the
> >> >> > + * same as 'struct timespec' but 32/64b ABI safe.
> >> >> > + */
> >> >> > +struct drm_etnaviv_timespec {
> >> >> > +   int64_t tv_sec;  /* seconds */
> >> >> > +   int64_t tv_nsec; /* nanoseconds */
> >> >> > +};
> >> >> > +
> >> >> > +#define ETNAVIV_PARAM_GPU_MODEL 0x01
> >> >> > +#define ETNAVIV_PARAM_GPU_REVISION  0x02
> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_00x03
> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_10x04
> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_20x05
> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_30x06
> >> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_40x07
> >> >> > +
> >> >> > +#define ETNAVIV_PARAM_GPU_STREAM_COUNT  0x10
> >> >> > +#define ETNAVIV_PARAM_GPU_REGISTER_MAX  0x11
> >> >> > +#define ETNAVIV_PARAM_GPU_THREAD_COUNT  0x12
> >> >> > +#define ETNAVIV_PARAM_GPU_VERTEX_CACHE_SIZE 0x13
> >> >> > +#define ETNAVIV_PARAM_GPU_SHADER_CORE_COUNT 0x14
> >> >> > +#define ETNAVIV_PARAM_GPU_PIXEL_PIPES   0x15
> >> >> > +#define ETNAVIV_PARAM_GPU_VERTEX_OUTPUT_BUFFER_SIZE 0x16
> >> >> > +#define ETNAVIV_PARAM_GPU_BUFFER_SIZE   0x17
> >> >> > +#define ETNAVIV_PARAM_GPU_INSTRUCTION_COUNT 0x18
> >> >> > +#define ETNAVIV_PARAM_GPU_NUM_CONSTANTS 0x19
> >> >> > +
> >> >> > +//#define MSM_PARAM_GMEM_SIZE  0x02
> >> >> > +
> >> >> > +struct drm_etnaviv_param {
> >> >> > +   uint32_t pipe;   /* in, ETNA_PIPE_x */
> >> >> > +   uint32_t param;  /* in, ETNAVIV_PARAM_x */
> >> >> > +   uint64_t value;  /* out (get_param) or in (set_param) 
> >> >> > */
> >> >> > +};
> >> >> > +
> >> >> > +/*
> >> >> > + * GEM buffers:

[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-07 Thread Russell King - ARM Linux 
On Tue, Apr 07, 2015 at 11:20:10AM +0200, Lucas Stach wrote:
> Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner:
> > What role does GPU power management plays here? For the context switching
> > it could make sense. But for the 2d core the context is so small that
> > it does not
> > hurt to send it with every command stream. For the 3d core it is much
> > bigger, but
> > this could be done completely in the kernel. Or I am wrong here?
>
> If you power down the GPU you loose the context. You are right that we
> could save/restore the context from kernel space, but that is really
> taking a toll on CPU time. It is much better to have userspace provide a
> context buffer to get the GPU in the expected state, as you then only
> need to splice this into the execution stream to restore the context
> instead of pushing it with the CPU. Reading back the context on every
> switch will kill any performance.

For both Vivante and Etnaviv, it's already the accepted way that 2D
cores need the full context loaded for each operation, and the few
userspace bits we have comply with that today.

With Etnaviv DRM, we already must ensure that the command buffer
submitted to the GPU contains all references to buffer objects to be
operated on by that command block - or to put it another way, we
need to ensure that each GPU operation is complete inside the command
submitted buffer.

The 2D core is rather messy as far as which bits of state need to be
preserved, especially when you consider that you have the 2D drawing
and blit ops, as well as a video rasteriser which shares some state
registers for the destination, but uses different state registers for
the source.  It quickly becomes rather messy to keep track of the
GPU state.

In any case, the amount of state which needs to be loaded for 2D
operations is small, so I think it really makes sense to require
userspace to only submit complete, fully described 2D operations
within a single command buffer.

> > I tend to get things up and running and do the optimization step if it
> > is really worth.
> > Also I like stuff to be stupid simple. There is an other interesting
> > fact: flushing the
> > iommuv2 is done via command stream and we need to reserve more space
> > for the tail of the used bo. So if we reserve some space in the
> > command buffer, we have other space limits for the tail depending on
> > used hardware.

I would much rather we only appended LINK commands to the submitted
command BO, and added whatever GPU management commands to either the
ring buffer (which is easy) or a separate GPU management command
buffer.  Given that I'm already doing this to flush the V1 MMU in
the kernel ring buffer, this is the option I prefer.

> You may be aware that once this is upstream there is no easy way to
> change the userspace interface anymore. So whatever is left out now is
> likely to be very hard to reintroduce later.

Indeed - we need to agree what the submited command buffer will contain,
and how much space to enforce at the end of the command buffer.

The minimum space is one LINK command, which is 8 bytes.  As long as we
can add a LINK command, we can redirect the GPU's execution elsewhere to
do whatever other operations we want to do.

I think the only danger there is if Vivante produce a GPU with 64-bit
addressing for the command stream - if they do, commands like LINK will
most likely change format, and possibly would be a different number of
bits.

The simple solution to this would be to introduce into the API a
property (like is done for the feature bits) which tells userspace the
minimum number of bytes which must be reserved at the end of the command
buffer.  If we need to change that in the future, we have the flexibility
to do so.

> What' the problem with having a command buffer in the kernel to flush
> the MMUv2? Why do you need to insert those commands into the userspace
> command stream?

That's certainly where I would put it.

> > >> > +#define ETNA_SUBMIT_BO_READ 0x0001
> > >> > +#define ETNA_SUBMIT_BO_WRITE0x0002
> > >> > +struct drm_etnaviv_gem_submit_bo {
> > >> > +   uint32_t flags;  /* in, mask of ETNA_SUBMIT_BO_x */
> > >> > +   uint32_t handle; /* in, GEM handle */
> > >> > +   uint64_t presumed;   /* in/out, presumed buffer address */
> > >>
> > >> presumed support should never hit etnaviv driver.
> > >>
> > > As stated in the cover letter I think presumed support will become
> > > possible with MMUv2 and may provide a good optimization there. So I
> > > would rather leave this in here and just ignore it for now.

Could we rename this member 'reserved' if it's something that we think
we're going to implement in the near future - but also please add a
flag which indicates whether the presumed address is present or not.
Zero _can_ be a valid address too!

> A presumed address can not be a physical address, but is an address in
> the VM context of that process. Nouveau uses

[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-07 Thread Christian Gmeiner 
2015-04-07 11:20 GMT+02:00 Lucas Stach :
> Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner:
>> Hi Lucas
>>
>> 2015-04-07 9:35 GMT+02:00 Lucas Stach :
>> > Am Sonntag, den 05.04.2015, 21:26 +0200 schrieb Christian Gmeiner:
>> >> 2015-04-02 17:29 GMT+02:00 Lucas Stach :
>> >> > From: Christian Gmeiner 
>> >> >
>> >> > This is a consolidation by Russell King of Christian's drm work.
>> >> >
>> >> > Signed-off-by: Christian Gmeiner 
>> >> > Signed-off-by: Russell King 
>> >
>> >> > ---
>> > [...]
>> >
>> >> > +#endif /* STATE_HI_XML */
>> >> > diff --git a/include/uapi/drm/etnaviv_drm.h 
>> >> > b/include/uapi/drm/etnaviv_drm.h
>> >> > new file mode 100644
>> >> > index ..f7b5ac6f3842
>> >> > --- /dev/null
>> >> > +++ b/include/uapi/drm/etnaviv_drm.h
>> >> > @@ -0,0 +1,225 @@
>> >> > +/*
>> >> > + * Copyright (C) 2013 Red Hat
>> >> > + * 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 .
>> >> > + */
>> >> > +
>> >> > +#ifndef __ETNAVIV_DRM_H__
>> >> > +#define __ETNAVIV_DRM_H__
>> >> > +
>> >> > +#include 
>> >> > +#include 
>> >> > +
>> >> > +/* Please note that modifications to all structs defined here are
>> >> > + * subject to backwards-compatibility constraints:
>> >> > + *  1) Do not use pointers, use uint64_t instead for 32 bit / 64 bit
>> >> > + * user/kernel compatibility
>> >> > + *  2) Keep fields aligned to their size
>> >> > + *  3) Because of how drm_ioctl() works, we can add new fields at
>> >> > + * the end of an ioctl if some care is taken: drm_ioctl() will
>> >> > + * zero out the new fields at the tail of the ioctl, so a zero
>> >> > + * value should have a backwards compatible meaning.  And for
>> >> > + * output params, userspace won't see the newly added output
>> >> > + * fields.. so that has to be somehow ok.
>> >> > + */
>> >> > +
>> >> > +#define ETNA_PIPE_3D  0x00
>> >> > +#define ETNA_PIPE_2D  0x01
>> >> > +#define ETNA_PIPE_VG  0x02
>> >> > +
>> >> > +#define ETNA_MAX_PIPES3
>> >> > +
>> >> > +/* timeouts are specified in clock-monotonic absolute times (to 
>> >> > simplify
>> >> > + * restarting interrupted ioctls).  The following struct is logically 
>> >> > the
>> >> > + * same as 'struct timespec' but 32/64b ABI safe.
>> >> > + */
>> >> > +struct drm_etnaviv_timespec {
>> >> > +   int64_t tv_sec;  /* seconds */
>> >> > +   int64_t tv_nsec; /* nanoseconds */
>> >> > +};
>> >> > +
>> >> > +#define ETNAVIV_PARAM_GPU_MODEL 0x01
>> >> > +#define ETNAVIV_PARAM_GPU_REVISION  0x02
>> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_00x03
>> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_10x04
>> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_20x05
>> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_30x06
>> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_40x07
>> >> > +
>> >> > +#define ETNAVIV_PARAM_GPU_STREAM_COUNT  0x10
>> >> > +#define ETNAVIV_PARAM_GPU_REGISTER_MAX  0x11
>> >> > +#define ETNAVIV_PARAM_GPU_THREAD_COUNT  0x12
>> >> > +#define ETNAVIV_PARAM_GPU_VERTEX_CACHE_SIZE 0x13
>> >> > +#define ETNAVIV_PARAM_GPU_SHADER_CORE_COUNT 0x14
>> >> > +#define ETNAVIV_PARAM_GPU_PIXEL_PIPES   0x15
>> >> > +#define ETNAVIV_PARAM_GPU_VERTEX_OUTPUT_BUFFER_SIZE 0x16
>> >> > +#define ETNAVIV_PARAM_GPU_BUFFER_SIZE   0x17
>> >> > +#define ETNAVIV_PARAM_GPU_INSTRUCTION_COUNT 0x18
>> >> > +#define ETNAVIV_PARAM_GPU_NUM_CONSTANTS 0x19
>> >> > +
>> >> > +//#define MSM_PARAM_GMEM_SIZE  0x02
>> >> > +
>> >> > +struct drm_etnaviv_param {
>> >> > +   uint32_t pipe;   /* in, ETNA_PIPE_x */
>> >> > +   uint32_t param;  /* in, ETNAVIV_PARAM_x */
>> >> > +   uint64_t value;  /* out (get_param) or in (set_param) */
>> >> > +};
>> >> > +
>> >> > +/*
>> >> > + * GEM buffers:
>> >> > + */
>> >> > +
>> >> > +#define ETNA_BO_CMDSTREAM0x0001
>> >> > +#define ETNA_BO_CACHE_MASK   0x000f
>> >> > +/* cache modes */
>> >> > +#define ETNA_BO_CACHED   0x0001
>> >> > +#define ETNA_BO_WC   0x0002
>> >> > +#define ETNA_BO_UNCACHED 0x0004
>> >> > +

[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-07 Thread Lucas Stach 
Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner:
> Hi Lucas
> 
> 2015-04-07 9:35 GMT+02:00 Lucas Stach :
> > Am Sonntag, den 05.04.2015, 21:26 +0200 schrieb Christian Gmeiner:
> >> 2015-04-02 17:29 GMT+02:00 Lucas Stach :
> >> > From: Christian Gmeiner 
> >> >
> >> > This is a consolidation by Russell King of Christian's drm work.
> >> >
> >> > Signed-off-by: Christian Gmeiner 
> >> > Signed-off-by: Russell King 
> >
> >> > ---
> > [...]
> >
> >> > +#endif /* STATE_HI_XML */
> >> > diff --git a/include/uapi/drm/etnaviv_drm.h 
> >> > b/include/uapi/drm/etnaviv_drm.h
> >> > new file mode 100644
> >> > index ..f7b5ac6f3842
> >> > --- /dev/null
> >> > +++ b/include/uapi/drm/etnaviv_drm.h
> >> > @@ -0,0 +1,225 @@
> >> > +/*
> >> > + * Copyright (C) 2013 Red Hat
> >> > + * 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 .
> >> > + */
> >> > +
> >> > +#ifndef __ETNAVIV_DRM_H__
> >> > +#define __ETNAVIV_DRM_H__
> >> > +
> >> > +#include 
> >> > +#include 
> >> > +
> >> > +/* Please note that modifications to all structs defined here are
> >> > + * subject to backwards-compatibility constraints:
> >> > + *  1) Do not use pointers, use uint64_t instead for 32 bit / 64 bit
> >> > + * user/kernel compatibility
> >> > + *  2) Keep fields aligned to their size
> >> > + *  3) Because of how drm_ioctl() works, we can add new fields at
> >> > + * the end of an ioctl if some care is taken: drm_ioctl() will
> >> > + * zero out the new fields at the tail of the ioctl, so a zero
> >> > + * value should have a backwards compatible meaning.  And for
> >> > + * output params, userspace won't see the newly added output
> >> > + * fields.. so that has to be somehow ok.
> >> > + */
> >> > +
> >> > +#define ETNA_PIPE_3D  0x00
> >> > +#define ETNA_PIPE_2D  0x01
> >> > +#define ETNA_PIPE_VG  0x02
> >> > +
> >> > +#define ETNA_MAX_PIPES3
> >> > +
> >> > +/* timeouts are specified in clock-monotonic absolute times (to simplify
> >> > + * restarting interrupted ioctls).  The following struct is logically 
> >> > the
> >> > + * same as 'struct timespec' but 32/64b ABI safe.
> >> > + */
> >> > +struct drm_etnaviv_timespec {
> >> > +   int64_t tv_sec;  /* seconds */
> >> > +   int64_t tv_nsec; /* nanoseconds */
> >> > +};
> >> > +
> >> > +#define ETNAVIV_PARAM_GPU_MODEL 0x01
> >> > +#define ETNAVIV_PARAM_GPU_REVISION  0x02
> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_00x03
> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_10x04
> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_20x05
> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_30x06
> >> > +#define ETNAVIV_PARAM_GPU_FEATURES_40x07
> >> > +
> >> > +#define ETNAVIV_PARAM_GPU_STREAM_COUNT  0x10
> >> > +#define ETNAVIV_PARAM_GPU_REGISTER_MAX  0x11
> >> > +#define ETNAVIV_PARAM_GPU_THREAD_COUNT  0x12
> >> > +#define ETNAVIV_PARAM_GPU_VERTEX_CACHE_SIZE 0x13
> >> > +#define ETNAVIV_PARAM_GPU_SHADER_CORE_COUNT 0x14
> >> > +#define ETNAVIV_PARAM_GPU_PIXEL_PIPES   0x15
> >> > +#define ETNAVIV_PARAM_GPU_VERTEX_OUTPUT_BUFFER_SIZE 0x16
> >> > +#define ETNAVIV_PARAM_GPU_BUFFER_SIZE   0x17
> >> > +#define ETNAVIV_PARAM_GPU_INSTRUCTION_COUNT 0x18
> >> > +#define ETNAVIV_PARAM_GPU_NUM_CONSTANTS 0x19
> >> > +
> >> > +//#define MSM_PARAM_GMEM_SIZE  0x02
> >> > +
> >> > +struct drm_etnaviv_param {
> >> > +   uint32_t pipe;   /* in, ETNA_PIPE_x */
> >> > +   uint32_t param;  /* in, ETNAVIV_PARAM_x */
> >> > +   uint64_t value;  /* out (get_param) or in (set_param) */
> >> > +};
> >> > +
> >> > +/*
> >> > + * GEM buffers:
> >> > + */
> >> > +
> >> > +#define ETNA_BO_CMDSTREAM0x0001
> >> > +#define ETNA_BO_CACHE_MASK   0x000f
> >> > +/* cache modes */
> >> > +#define ETNA_BO_CACHED   0x0001
> >> > +#define ETNA_BO_WC   0x0002
> >> > +#define ETNA_BO_UNCACHED 0x0004
> >> > +
> >> > +struct drm_etnaviv_gem_new {
> >> > +   uint64_t size;   /* in */
> >> > +   uint32_t flags;  /* in, mask of ETNA_BO_x */
> >> > +   uint32_t

[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-07 Thread Christian Gmeiner 
Hi Lucas

2015-04-07 9:35 GMT+02:00 Lucas Stach :
> Am Sonntag, den 05.04.2015, 21:26 +0200 schrieb Christian Gmeiner:
>> 2015-04-02 17:29 GMT+02:00 Lucas Stach :
>> > From: Christian Gmeiner 
>> >
>> > This is a consolidation by Russell King of Christian's drm work.
>> >
>> > Signed-off-by: Christian Gmeiner 
>> > Signed-off-by: Russell King 
>
>> > ---
> [...]
>
>> > +#endif /* STATE_HI_XML */
>> > diff --git a/include/uapi/drm/etnaviv_drm.h 
>> > b/include/uapi/drm/etnaviv_drm.h
>> > new file mode 100644
>> > index ..f7b5ac6f3842
>> > --- /dev/null
>> > +++ b/include/uapi/drm/etnaviv_drm.h
>> > @@ -0,0 +1,225 @@
>> > +/*
>> > + * Copyright (C) 2013 Red Hat
>> > + * 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 .
>> > + */
>> > +
>> > +#ifndef __ETNAVIV_DRM_H__
>> > +#define __ETNAVIV_DRM_H__
>> > +
>> > +#include 
>> > +#include 
>> > +
>> > +/* Please note that modifications to all structs defined here are
>> > + * subject to backwards-compatibility constraints:
>> > + *  1) Do not use pointers, use uint64_t instead for 32 bit / 64 bit
>> > + * user/kernel compatibility
>> > + *  2) Keep fields aligned to their size
>> > + *  3) Because of how drm_ioctl() works, we can add new fields at
>> > + * the end of an ioctl if some care is taken: drm_ioctl() will
>> > + * zero out the new fields at the tail of the ioctl, so a zero
>> > + * value should have a backwards compatible meaning.  And for
>> > + * output params, userspace won't see the newly added output
>> > + * fields.. so that has to be somehow ok.
>> > + */
>> > +
>> > +#define ETNA_PIPE_3D  0x00
>> > +#define ETNA_PIPE_2D  0x01
>> > +#define ETNA_PIPE_VG  0x02
>> > +
>> > +#define ETNA_MAX_PIPES3
>> > +
>> > +/* timeouts are specified in clock-monotonic absolute times (to simplify
>> > + * restarting interrupted ioctls).  The following struct is logically the
>> > + * same as 'struct timespec' but 32/64b ABI safe.
>> > + */
>> > +struct drm_etnaviv_timespec {
>> > +   int64_t tv_sec;  /* seconds */
>> > +   int64_t tv_nsec; /* nanoseconds */
>> > +};
>> > +
>> > +#define ETNAVIV_PARAM_GPU_MODEL 0x01
>> > +#define ETNAVIV_PARAM_GPU_REVISION  0x02
>> > +#define ETNAVIV_PARAM_GPU_FEATURES_00x03
>> > +#define ETNAVIV_PARAM_GPU_FEATURES_10x04
>> > +#define ETNAVIV_PARAM_GPU_FEATURES_20x05
>> > +#define ETNAVIV_PARAM_GPU_FEATURES_30x06
>> > +#define ETNAVIV_PARAM_GPU_FEATURES_40x07
>> > +
>> > +#define ETNAVIV_PARAM_GPU_STREAM_COUNT  0x10
>> > +#define ETNAVIV_PARAM_GPU_REGISTER_MAX  0x11
>> > +#define ETNAVIV_PARAM_GPU_THREAD_COUNT  0x12
>> > +#define ETNAVIV_PARAM_GPU_VERTEX_CACHE_SIZE 0x13
>> > +#define ETNAVIV_PARAM_GPU_SHADER_CORE_COUNT 0x14
>> > +#define ETNAVIV_PARAM_GPU_PIXEL_PIPES   0x15
>> > +#define ETNAVIV_PARAM_GPU_VERTEX_OUTPUT_BUFFER_SIZE 0x16
>> > +#define ETNAVIV_PARAM_GPU_BUFFER_SIZE   0x17
>> > +#define ETNAVIV_PARAM_GPU_INSTRUCTION_COUNT 0x18
>> > +#define ETNAVIV_PARAM_GPU_NUM_CONSTANTS 0x19
>> > +
>> > +//#define MSM_PARAM_GMEM_SIZE  0x02
>> > +
>> > +struct drm_etnaviv_param {
>> > +   uint32_t pipe;   /* in, ETNA_PIPE_x */
>> > +   uint32_t param;  /* in, ETNAVIV_PARAM_x */
>> > +   uint64_t value;  /* out (get_param) or in (set_param) */
>> > +};
>> > +
>> > +/*
>> > + * GEM buffers:
>> > + */
>> > +
>> > +#define ETNA_BO_CMDSTREAM0x0001
>> > +#define ETNA_BO_CACHE_MASK   0x000f
>> > +/* cache modes */
>> > +#define ETNA_BO_CACHED   0x0001
>> > +#define ETNA_BO_WC   0x0002
>> > +#define ETNA_BO_UNCACHED 0x0004
>> > +
>> > +struct drm_etnaviv_gem_new {
>> > +   uint64_t size;   /* in */
>> > +   uint32_t flags;  /* in, mask of ETNA_BO_x */
>> > +   uint32_t handle; /* out */
>> > +};
>> > +
>> > +struct drm_etnaviv_gem_info {
>> > +   uint32_t handle; /* in */
>> > +   uint32_t pad;
>> > +   uint64_t offset; /* out, offset to pass to mmap() */
>> > +};
>> > +
>> > +#define ETNA_PREP_READ0x01
>> > +#define ETNA_PREP_WRITE   0x02

[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-07 Thread Lucas Stach 
Am Sonntag, den 05.04.2015, 21:26 +0200 schrieb Christian Gmeiner:
> 2015-04-02 17:29 GMT+02:00 Lucas Stach :
> > From: Christian Gmeiner 
> >
> > This is a consolidation by Russell King of Christian's drm work.
> >
> > Signed-off-by: Christian Gmeiner 
> > Signed-off-by: Russell King 

> > ---
[...]

> > +#endif /* STATE_HI_XML */
> > diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h
> > new file mode 100644
> > index ..f7b5ac6f3842
> > --- /dev/null
> > +++ b/include/uapi/drm/etnaviv_drm.h
> > @@ -0,0 +1,225 @@
> > +/*
> > + * Copyright (C) 2013 Red Hat
> > + * 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 .
> > + */
> > +
> > +#ifndef __ETNAVIV_DRM_H__
> > +#define __ETNAVIV_DRM_H__
> > +
> > +#include 
> > +#include 
> > +
> > +/* Please note that modifications to all structs defined here are
> > + * subject to backwards-compatibility constraints:
> > + *  1) Do not use pointers, use uint64_t instead for 32 bit / 64 bit
> > + * user/kernel compatibility
> > + *  2) Keep fields aligned to their size
> > + *  3) Because of how drm_ioctl() works, we can add new fields at
> > + * the end of an ioctl if some care is taken: drm_ioctl() will
> > + * zero out the new fields at the tail of the ioctl, so a zero
> > + * value should have a backwards compatible meaning.  And for
> > + * output params, userspace won't see the newly added output
> > + * fields.. so that has to be somehow ok.
> > + */
> > +
> > +#define ETNA_PIPE_3D  0x00
> > +#define ETNA_PIPE_2D  0x01
> > +#define ETNA_PIPE_VG  0x02
> > +
> > +#define ETNA_MAX_PIPES3
> > +
> > +/* timeouts are specified in clock-monotonic absolute times (to simplify
> > + * restarting interrupted ioctls).  The following struct is logically the
> > + * same as 'struct timespec' but 32/64b ABI safe.
> > + */
> > +struct drm_etnaviv_timespec {
> > +   int64_t tv_sec;  /* seconds */
> > +   int64_t tv_nsec; /* nanoseconds */
> > +};
> > +
> > +#define ETNAVIV_PARAM_GPU_MODEL 0x01
> > +#define ETNAVIV_PARAM_GPU_REVISION  0x02
> > +#define ETNAVIV_PARAM_GPU_FEATURES_00x03
> > +#define ETNAVIV_PARAM_GPU_FEATURES_10x04
> > +#define ETNAVIV_PARAM_GPU_FEATURES_20x05
> > +#define ETNAVIV_PARAM_GPU_FEATURES_30x06
> > +#define ETNAVIV_PARAM_GPU_FEATURES_40x07
> > +
> > +#define ETNAVIV_PARAM_GPU_STREAM_COUNT  0x10
> > +#define ETNAVIV_PARAM_GPU_REGISTER_MAX  0x11
> > +#define ETNAVIV_PARAM_GPU_THREAD_COUNT  0x12
> > +#define ETNAVIV_PARAM_GPU_VERTEX_CACHE_SIZE 0x13
> > +#define ETNAVIV_PARAM_GPU_SHADER_CORE_COUNT 0x14
> > +#define ETNAVIV_PARAM_GPU_PIXEL_PIPES   0x15
> > +#define ETNAVIV_PARAM_GPU_VERTEX_OUTPUT_BUFFER_SIZE 0x16
> > +#define ETNAVIV_PARAM_GPU_BUFFER_SIZE   0x17
> > +#define ETNAVIV_PARAM_GPU_INSTRUCTION_COUNT 0x18
> > +#define ETNAVIV_PARAM_GPU_NUM_CONSTANTS 0x19
> > +
> > +//#define MSM_PARAM_GMEM_SIZE  0x02
> > +
> > +struct drm_etnaviv_param {
> > +   uint32_t pipe;   /* in, ETNA_PIPE_x */
> > +   uint32_t param;  /* in, ETNAVIV_PARAM_x */
> > +   uint64_t value;  /* out (get_param) or in (set_param) */
> > +};
> > +
> > +/*
> > + * GEM buffers:
> > + */
> > +
> > +#define ETNA_BO_CMDSTREAM0x0001
> > +#define ETNA_BO_CACHE_MASK   0x000f
> > +/* cache modes */
> > +#define ETNA_BO_CACHED   0x0001
> > +#define ETNA_BO_WC   0x0002
> > +#define ETNA_BO_UNCACHED 0x0004
> > +
> > +struct drm_etnaviv_gem_new {
> > +   uint64_t size;   /* in */
> > +   uint32_t flags;  /* in, mask of ETNA_BO_x */
> > +   uint32_t handle; /* out */
> > +};
> > +
> > +struct drm_etnaviv_gem_info {
> > +   uint32_t handle; /* in */
> > +   uint32_t pad;
> > +   uint64_t offset; /* out, offset to pass to mmap() */
> > +};
> > +
> > +#define ETNA_PREP_READ0x01
> > +#define ETNA_PREP_WRITE   0x02
> > +#define ETNA_PREP_NOSYNC  0x04
> > +
> > +struct drm_etnaviv_gem_cpu_prep {
> > +   uint32_t handle; /* in */
> > +   uint32_t op; /* in, mask of

[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-05 Thread Christian Gmeiner 
2015-04-02 17:29 GMT+02:00 Lucas Stach :
> From: Christian Gmeiner 
>
> This is a consolidation by Russell King of Christian's drm work.
>
> Signed-off-by: Christian Gmeiner 
> Signed-off-by: Russell King 
> ---
>  drivers/staging/Kconfig  |   2 +
>  drivers/staging/Makefile |   1 +
>  drivers/staging/etnaviv/Kconfig  |  20 +
>  drivers/staging/etnaviv/Makefile |  17 +
>  drivers/staging/etnaviv/cmdstream.xml.h  | 218 ++
>  drivers/staging/etnaviv/common.xml.h | 253 +++
>  drivers/staging/etnaviv/etnaviv_buffer.c | 201 ++
>  drivers/staging/etnaviv/etnaviv_drv.c| 621 +
>  drivers/staging/etnaviv/etnaviv_drv.h| 143 
>  drivers/staging/etnaviv/etnaviv_gem.c| 706 +++
>  drivers/staging/etnaviv/etnaviv_gem.h| 100 +++
>  drivers/staging/etnaviv/etnaviv_gem_prime.c  |  56 ++
>  drivers/staging/etnaviv/etnaviv_gem_submit.c | 407 +++
>  drivers/staging/etnaviv/etnaviv_gpu.c| 984 
> +++
>  drivers/staging/etnaviv/etnaviv_gpu.h| 152 +
>  drivers/staging/etnaviv/etnaviv_iommu.c  | 185 +
>  drivers/staging/etnaviv/etnaviv_iommu.h  |  25 +
>  drivers/staging/etnaviv/etnaviv_iommu_v2.c   |  32 +
>  drivers/staging/etnaviv/etnaviv_iommu_v2.h   |  25 +
>  drivers/staging/etnaviv/etnaviv_mmu.c| 111 +++
>  drivers/staging/etnaviv/etnaviv_mmu.h|  37 +
>  drivers/staging/etnaviv/state.xml.h  | 348 ++
>  drivers/staging/etnaviv/state_hi.xml.h   | 405 +++
>  include/uapi/drm/etnaviv_drm.h   | 225 ++
>  24 files changed, 5274 insertions(+)
>  create mode 100644 drivers/staging/etnaviv/Kconfig
>  create mode 100644 drivers/staging/etnaviv/Makefile
>  create mode 100644 drivers/staging/etnaviv/cmdstream.xml.h
>  create mode 100644 drivers/staging/etnaviv/common.xml.h
>  create mode 100644 drivers/staging/etnaviv/etnaviv_buffer.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_drv.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_drv.h
>  create mode 100644 drivers/staging/etnaviv/etnaviv_gem.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_gem.h
>  create mode 100644 drivers/staging/etnaviv/etnaviv_gem_prime.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_gem_submit.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_gpu.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_gpu.h
>  create mode 100644 drivers/staging/etnaviv/etnaviv_iommu.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_iommu.h
>  create mode 100644 drivers/staging/etnaviv/etnaviv_iommu_v2.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_iommu_v2.h
>  create mode 100644 drivers/staging/etnaviv/etnaviv_mmu.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_mmu.h
>  create mode 100644 drivers/staging/etnaviv/state.xml.h
>  create mode 100644 drivers/staging/etnaviv/state_hi.xml.h
>  create mode 100644 include/uapi/drm/etnaviv_drm.h
>
> diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
> index 45baa83be7ce..441b1afbfe4c 100644
> --- a/drivers/staging/Kconfig
> +++ b/drivers/staging/Kconfig
> @@ -108,4 +108,6 @@ source "drivers/staging/fbtft/Kconfig"
>
>  source "drivers/staging/i2o/Kconfig"
>
> +source "drivers/staging/etnaviv/Kconfig"
> +
>  endif # STAGING
> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
> index 29160790841f..f53cf8412c0c 100644
> --- a/drivers/staging/Makefile
> +++ b/drivers/staging/Makefile
> @@ -46,3 +46,4 @@ obj-$(CONFIG_UNISYSSPAR)  += unisys/
>  obj-$(CONFIG_COMMON_CLK_XLNX_CLKWZRD)  += clocking-wizard/
>  obj-$(CONFIG_FB_TFT)   += fbtft/
>  obj-$(CONFIG_I2O)  += i2o/
> +obj-$(CONFIG_DRM_ETNAVIV)  += etnaviv/
> diff --git a/drivers/staging/etnaviv/Kconfig b/drivers/staging/etnaviv/Kconfig
> new file mode 100644
> index ..6f034eda914c
> --- /dev/null
> +++ b/drivers/staging/etnaviv/Kconfig
> @@ -0,0 +1,20 @@
> +
> +config DRM_ETNAVIV
> +   tristate "etnaviv DRM"
> +   depends on DRM
> +   select SHMEM
> +   select TMPFS
> +   select IOMMU_API
> +   select IOMMU_SUPPORT
> +   default y
> +   help
> + DRM driver for Vivante GPUs.
> +
> +config DRM_ETNAVIV_REGISTER_LOGGING
> +   bool "etnaviv DRM register logging"
> +   depends on DRM_ETNAVIV
> +   default n
> +   help
> + Compile in support for logging register reads/writes in a format
> + that can be parsed by envytools demsm tool.  If enabled, register
> + logging can be switched on via etnaviv.reglog=y module param.
> diff --git a/drivers/staging/etnaviv/Makefile 
> b/drivers/staging/etnaviv/Makefile
> new file mode 100644
> index ..ef0cffabdcce
> --- /dev/null
> +++ b/drivers/staging/etnaviv/Makefile
> @@ -0,0 +1,17 @@
> +ccflags-y := -Iinclude/drm

[PATCH RFC 003/111] staging: etnaviv: add drm driver

2015-04-02 Thread Lucas Stach 
From: Christian Gmeiner 

This is a consolidation by Russell King of Christian's drm work.

Signed-off-by: Christian Gmeiner 
Signed-off-by: Russell King 
---
 drivers/staging/Kconfig  |   2 +
 drivers/staging/Makefile |   1 +
 drivers/staging/etnaviv/Kconfig  |  20 +
 drivers/staging/etnaviv/Makefile |  17 +
 drivers/staging/etnaviv/cmdstream.xml.h  | 218 ++
 drivers/staging/etnaviv/common.xml.h | 253 +++
 drivers/staging/etnaviv/etnaviv_buffer.c | 201 ++
 drivers/staging/etnaviv/etnaviv_drv.c| 621 +
 drivers/staging/etnaviv/etnaviv_drv.h| 143 
 drivers/staging/etnaviv/etnaviv_gem.c| 706 +++
 drivers/staging/etnaviv/etnaviv_gem.h| 100 +++
 drivers/staging/etnaviv/etnaviv_gem_prime.c  |  56 ++
 drivers/staging/etnaviv/etnaviv_gem_submit.c | 407 +++
 drivers/staging/etnaviv/etnaviv_gpu.c| 984 +++
 drivers/staging/etnaviv/etnaviv_gpu.h| 152 +
 drivers/staging/etnaviv/etnaviv_iommu.c  | 185 +
 drivers/staging/etnaviv/etnaviv_iommu.h  |  25 +
 drivers/staging/etnaviv/etnaviv_iommu_v2.c   |  32 +
 drivers/staging/etnaviv/etnaviv_iommu_v2.h   |  25 +
 drivers/staging/etnaviv/etnaviv_mmu.c| 111 +++
 drivers/staging/etnaviv/etnaviv_mmu.h|  37 +
 drivers/staging/etnaviv/state.xml.h  | 348 ++
 drivers/staging/etnaviv/state_hi.xml.h   | 405 +++
 include/uapi/drm/etnaviv_drm.h   | 225 ++
 24 files changed, 5274 insertions(+)
 create mode 100644 drivers/staging/etnaviv/Kconfig
 create mode 100644 drivers/staging/etnaviv/Makefile
 create mode 100644 drivers/staging/etnaviv/cmdstream.xml.h
 create mode 100644 drivers/staging/etnaviv/common.xml.h
 create mode 100644 drivers/staging/etnaviv/etnaviv_buffer.c
 create mode 100644 drivers/staging/etnaviv/etnaviv_drv.c
 create mode 100644 drivers/staging/etnaviv/etnaviv_drv.h
 create mode 100644 drivers/staging/etnaviv/etnaviv_gem.c
 create mode 100644 drivers/staging/etnaviv/etnaviv_gem.h
 create mode 100644 drivers/staging/etnaviv/etnaviv_gem_prime.c
 create mode 100644 drivers/staging/etnaviv/etnaviv_gem_submit.c
 create mode 100644 drivers/staging/etnaviv/etnaviv_gpu.c
 create mode 100644 drivers/staging/etnaviv/etnaviv_gpu.h
 create mode 100644 drivers/staging/etnaviv/etnaviv_iommu.c
 create mode 100644 drivers/staging/etnaviv/etnaviv_iommu.h
 create mode 100644 drivers/staging/etnaviv/etnaviv_iommu_v2.c
 create mode 100644 drivers/staging/etnaviv/etnaviv_iommu_v2.h
 create mode 100644 drivers/staging/etnaviv/etnaviv_mmu.c
 create mode 100644 drivers/staging/etnaviv/etnaviv_mmu.h
 create mode 100644 drivers/staging/etnaviv/state.xml.h
 create mode 100644 drivers/staging/etnaviv/state_hi.xml.h
 create mode 100644 include/uapi/drm/etnaviv_drm.h

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 45baa83be7ce..441b1afbfe4c 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -108,4 +108,6 @@ source "drivers/staging/fbtft/Kconfig"

 source "drivers/staging/i2o/Kconfig"

+source "drivers/staging/etnaviv/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 29160790841f..f53cf8412c0c 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -46,3 +46,4 @@ obj-$(CONFIG_UNISYSSPAR)  += unisys/
 obj-$(CONFIG_COMMON_CLK_XLNX_CLKWZRD)  += clocking-wizard/
 obj-$(CONFIG_FB_TFT)   += fbtft/
 obj-$(CONFIG_I2O)  += i2o/
+obj-$(CONFIG_DRM_ETNAVIV)  += etnaviv/
diff --git a/drivers/staging/etnaviv/Kconfig b/drivers/staging/etnaviv/Kconfig
new file mode 100644
index ..6f034eda914c
--- /dev/null
+++ b/drivers/staging/etnaviv/Kconfig
@@ -0,0 +1,20 @@
+
+config DRM_ETNAVIV
+   tristate "etnaviv DRM"
+   depends on DRM
+   select SHMEM
+   select TMPFS
+   select IOMMU_API
+   select IOMMU_SUPPORT
+   default y
+   help
+ DRM driver for Vivante GPUs.
+
+config DRM_ETNAVIV_REGISTER_LOGGING
+   bool "etnaviv DRM register logging"
+   depends on DRM_ETNAVIV
+   default n
+   help
+ Compile in support for logging register reads/writes in a format
+ that can be parsed by envytools demsm tool.  If enabled, register
+ logging can be switched on via etnaviv.reglog=y module param.
diff --git a/drivers/staging/etnaviv/Makefile b/drivers/staging/etnaviv/Makefile
new file mode 100644
index ..ef0cffabdcce
--- /dev/null
+++ b/drivers/staging/etnaviv/Makefile
@@ -0,0 +1,17 @@
+ccflags-y := -Iinclude/drm -Idrivers/staging/vivante
+ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
+   ccflags-y += -Werror
+endif
+
+etnaviv-y := \
+   etnaviv_drv.o \
+   etnaviv_gem.o \
+   etnaviv_gem_prime.o \
+   etnaviv_gem_submit.o \
+