[PATCH RFC 000/111] Etnaviv DRM driver

2015-04-08 Thread Jean-Michel Hautbois
Hi Lucas,

Thanks for the patch series ! It sounds great, even if it probably
needs to be squashed down to some patches, as most of the patches are
fixes.

2015-04-02 22:01 GMT+02:00 Robert Nelson :
> On Thu, Apr 2, 2015 at 10:59 AM, Lucas Stach  
> wrote:
>> Am Donnerstag, den 02.04.2015, 16:43 +0100 schrieb Russell King - ARM
>> Linux:
>>> On Thu, Apr 02, 2015 at 05:29:02PM +0200, Lucas Stach wrote:
>>> > Hey all,
>>> >
>>> > this is the Etnaviv DRM driver for Vivante embedded GPUs. It is heavily
>>> > influenced by the MSM driver, as can be clearly seen with the first 
>>> > commits.
>>>
>>> You should be copying Greg KH for staging too.
>>>
>> I didn't do that on purpose. As stated below in the cover letter I'm not
>> really happy to push things into staging. Especially after the
>> experience with imx-drm, where it took us a considerable amount of work
>> to even get people to look at the code after it had landed in staging.
>>
>> If possible I would like to collect feedback now and only if someone
>> feels genuinely unhappy about this code living under drivers/gpu/drm
>> then keep it in staging. Otherwise I would like to move it when removing
>> the RFC from this patchset.
>
> Looks good so far Lucas on my wand quad..
>
> Where's your libdrm/mesa tree located that you've been working on?
>
> debian at arm:~$ uname -r
> 4.0.0-rc6-armv7-devel-r24
> debian at arm:~$ dmesg | grep etnaviv
> [3.711866] etnaviv gpu-subsystem: bound 134000.gpu (ops gpu_ops)
> [3.718015] etnaviv gpu-subsystem: bound 13.gpu (ops gpu_ops)
> [3.724133] etnaviv gpu-subsystem: bound 2204000.gpu (ops gpu_ops)
> [3.730351] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
> [3.771045] etnaviv-gpu 13.gpu: model: GC2000, revision: 5108
> [3.802887] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
> [3.848287] [drm] Initialized etnaviv 1.0.0 20150302 on minor 1

Exactly the same question, I would like to give it a try on my board,
how can I test it ?

Thanks,
JM


[PATCH RFC 000/111] Etnaviv DRM driver

2015-04-07 Thread Daniel Vetter
On Thu, Apr 02, 2015 at 05:59:36PM +0200, Lucas Stach wrote:
> Am Donnerstag, den 02.04.2015, 16:43 +0100 schrieb Russell King - ARM
> Linux:
> > On Thu, Apr 02, 2015 at 05:29:02PM +0200, Lucas Stach wrote:
> > > Hey all,
> > > 
> > > this is the Etnaviv DRM driver for Vivante embedded GPUs. It is heavily
> > > influenced by the MSM driver, as can be clearly seen with the first 
> > > commits.
> > 
> > You should be copying Greg KH for staging too.
> > 
> I didn't do that on purpose. As stated below in the cover letter I'm not
> really happy to push things into staging. Especially after the
> experience with imx-drm, where it took us a considerable amount of work
> to even get people to look at the code after it had landed in staging.
> 
> If possible I would like to collect feedback now and only if someone
> feels genuinely unhappy about this code living under drivers/gpu/drm
> then keep it in staging. Otherwise I would like to move it when removing
> the RFC from this patchset.

If you want feedback can you please squash down the patch series so that
it's clean? I don't like reading drivers and spotting problems just to
realize that a few patches down an issue is fixed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[PATCH RFC 000/111] Etnaviv DRM driver

2015-04-05 Thread Christian Gmeiner
2015-04-02 22:01 GMT+02:00 Robert Nelson :
> On Thu, Apr 2, 2015 at 10:59 AM, Lucas Stach  
> wrote:
>> Am Donnerstag, den 02.04.2015, 16:43 +0100 schrieb Russell King - ARM
>> Linux:
>>> On Thu, Apr 02, 2015 at 05:29:02PM +0200, Lucas Stach wrote:
>>> > Hey all,
>>> >
>>> > this is the Etnaviv DRM driver for Vivante embedded GPUs. It is heavily
>>> > influenced by the MSM driver, as can be clearly seen with the first 
>>> > commits.
>>>
>>> You should be copying Greg KH for staging too.
>>>
>> I didn't do that on purpose. As stated below in the cover letter I'm not
>> really happy to push things into staging. Especially after the
>> experience with imx-drm, where it took us a considerable amount of work
>> to even get people to look at the code after it had landed in staging.
>>
>> If possible I would like to collect feedback now and only if someone
>> feels genuinely unhappy about this code living under drivers/gpu/drm
>> then keep it in staging. Otherwise I would like to move it when removing
>> the RFC from this patchset.
>
> Looks good so far Lucas on my wand quad..
>
> Where's your libdrm/mesa tree located that you've been working on?
>
> debian at arm:~$ uname -r
> 4.0.0-rc6-armv7-devel-r24
> debian at arm:~$ dmesg | grep etnaviv
> [3.711866] etnaviv gpu-subsystem: bound 134000.gpu (ops gpu_ops)
> [3.718015] etnaviv gpu-subsystem: bound 13.gpu (ops gpu_ops)
> [3.724133] etnaviv gpu-subsystem: bound 2204000.gpu (ops gpu_ops)
> [3.730351] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
> [3.771045] etnaviv-gpu 13.gpu: model: GC2000, revision: 5108
> [3.802887] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
> [3.848287] [drm] Initialized etnaviv 1.0.0 20150302 on minor 1
>
> Regards,
>
> --

Where can we find the userspace (libdrm, mesa, ..)?

--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner


[PATCH RFC 000/111] Etnaviv DRM driver

2015-04-02 Thread Lucas Stach
Am Donnerstag, den 02.04.2015, 16:43 +0100 schrieb Russell King - ARM
Linux:
> On Thu, Apr 02, 2015 at 05:29:02PM +0200, Lucas Stach wrote:
> > Hey all,
> > 
> > this is the Etnaviv DRM driver for Vivante embedded GPUs. It is heavily
> > influenced by the MSM driver, as can be clearly seen with the first commits.
> 
> You should be copying Greg KH for staging too.
> 
I didn't do that on purpose. As stated below in the cover letter I'm not
really happy to push things into staging. Especially after the
experience with imx-drm, where it took us a considerable amount of work
to even get people to look at the code after it had landed in staging.

If possible I would like to collect feedback now and only if someone
feels genuinely unhappy about this code living under drivers/gpu/drm
then keep it in staging. Otherwise I would like to move it when removing
the RFC from this patchset.

Regards,
Lucas

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



[PATCH RFC 000/111] Etnaviv DRM driver

2015-04-02 Thread Lucas Stach
Hey all,

this is the Etnaviv DRM driver for Vivante embedded GPUs. It is heavily
influenced by the MSM driver, as can be clearly seen with the first commits.

The userspace interface does a look a lot like the MSM one, with some small
differences:

- Each GPU core is a pipe as with MSM, but Vivante doesn't have a strict
  separation of tasks between the pipes. On some SoCs like the i.MX6 each
  pipe feeds one rendering backend (2D, 3D, VG), but there are also SoCs
  out there where on core (pipe) houses more than one backend. So pipes
  on Etnaviv represent one core, that may be switched between multiple
  execution state through the command stream. To allow for proper separation
  between processes each process may specify the expected execution state
  on submit.

- OR-ing and shifting of BO reloc addresses has been removed, as there is
  need for this on Vivante GPUs. The register interface is designed in a way
  that one always fills in complete 32bit addresses without any additional
  informations.

- Presumption of BO addresses is not used right now, as the GPU MMU v1 can not
  quarantee full protection. There is a 2GB window into physical memory without
  any MMU translation in between, so we always have to process all relocs to 
guard
  against malicious userspace. I've left it in the interface though as MMU v2
  seems to be able to give full protection and it might become useful at that
  point.

Unfinished stuff:
- GPU PM and context switching. This already works for the GPU 2D where there
  isn't much state to retain on the GPU itself. For full context switching and
  power down support on the GPU 3D the userspace needs to aid the kernel with a
  context restore buffer. This part isn't done yet.

It's a rather long series. I already tried to squash some commits together, but
wanted to retain the authorship of the individual people that worked on this
driver for now. Maybe if everyone involved is okay with it we could squash some
of the fixup commits a bit more.

I've kept things in staging for now, as that's the place where Christian started
this driver, but would really like to move it to DRM proper _before_ merging. So
please review stuff with that in mind. 

Russell King has some experimental support in the xf86-video-armada driver to
get some X accel running atop of this. I have a working libdrm/MESA stack that
basically works for some simple applications, but needs a good deal more work to
clean up.

If you would like to look at this stuff as a git tree feel free to fetch:

git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream

Regards,
Lucas

Christian Gmeiner (2):
  staging: etnaviv: add drm driver
  staging: etnaviv: quiten down kernel log output

Lucas Stach (28):
  staging: etnaviv: add devicetree bindings
  staging: etnaviv: import new headers
  staging: etnaviv: remove IOMMUv2 stubs
  staging: etnaviv: allow to draw up to 256 rectangles in one draw call
  staging: etnaviv: align command stream size to 64 bit
  staging: etnaviv: correct instruction count for GC2000 and GC880
  staging: etnaviv: reconfigure bus mapping on GC2000
  staging: etnaviv: fix cache cleaning for uncached SHM buffers
  staging: etnaviv: properly flush all TLBs on MMUv1
  staging: etnaviv: convert to_etnaviv_bo() to real function
  staging: etnaviv: take gpu instead of pipe as input to fence wait
function
  staging: etnaviv: plug in fence waiting in cpu_prepare
  staging: etnaviv: allow to map buffer object into multiple address
spaces
  staging: etnaviv: don't pretend to have a single MMU
  staging: etnaviv: use GPU device to construct MMU
  staging: etnaviv: flush MMU when switching context
  staging: etnaviv: add flag to force buffer through MMU
  staging: etnaviv: use more natural devicetree abstraction
  staging: etnaviv: don't override platform provided IRQ flags
  staging: etnaviv: separate GPU pipes from execution state
  staging: etnaviv: make sure to unlock DRM mutex when component bind
fails
  staging: etnaviv: clean up public API
  staging: etnaviv: prune dumb buffer support
  staging: etnaviv: properly prefix all prime functions to etnaviv
  staging: etnaviv: rename last remaining bits from msm to etnaviv
  staging: etnaviv: add proper license header to all files
  staging: etnaviv: some final trivial changes to the module
  ARM: imx6: add Vivante GPU nodes

Philipp Zabel (1):
  of: Add vendor prefix for Vivante Corporation

Russell King (80):
  staging: etnaviv: fix oops on unbind
  staging: etnaviv: fix oops in timer subsystem caused by hangcheck
timer
  staging: etnaviv: fix etnaviv_add_components()
  staging: etnaviv: fix etnaviv_hw_reset()
  staging: etnaviv: fix etnaviv gpu debugfs output
  staging: etnaviv: fix fence implementation
  staging: etnaviv: fix buffer dumping code
  staging: etnaviv: fix ring buffer overflow check
  staging: etnaviv: fix cleanup of imported dmabufs
  staging: etnaviv: fix printk formats
  staging: etnaviv: validation: ensure space for 

[PATCH RFC 000/111] Etnaviv DRM driver

2015-04-02 Thread Russell King - ARM Linux
On Thu, Apr 02, 2015 at 05:29:02PM +0200, Lucas Stach wrote:
> Hey all,
> 
> this is the Etnaviv DRM driver for Vivante embedded GPUs. It is heavily
> influenced by the MSM driver, as can be clearly seen with the first commits.

You should be copying Greg KH for staging too.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.


[PATCH RFC 000/111] Etnaviv DRM driver

2015-04-02 Thread Robert Nelson
On Thu, Apr 2, 2015 at 10:59 AM, Lucas Stach  wrote:
> Am Donnerstag, den 02.04.2015, 16:43 +0100 schrieb Russell King - ARM
> Linux:
>> On Thu, Apr 02, 2015 at 05:29:02PM +0200, Lucas Stach wrote:
>> > Hey all,
>> >
>> > this is the Etnaviv DRM driver for Vivante embedded GPUs. It is heavily
>> > influenced by the MSM driver, as can be clearly seen with the first 
>> > commits.
>>
>> You should be copying Greg KH for staging too.
>>
> I didn't do that on purpose. As stated below in the cover letter I'm not
> really happy to push things into staging. Especially after the
> experience with imx-drm, where it took us a considerable amount of work
> to even get people to look at the code after it had landed in staging.
>
> If possible I would like to collect feedback now and only if someone
> feels genuinely unhappy about this code living under drivers/gpu/drm
> then keep it in staging. Otherwise I would like to move it when removing
> the RFC from this patchset.

Looks good so far Lucas on my wand quad..

Where's your libdrm/mesa tree located that you've been working on?

debian at arm:~$ uname -r
4.0.0-rc6-armv7-devel-r24
debian at arm:~$ dmesg | grep etnaviv
[3.711866] etnaviv gpu-subsystem: bound 134000.gpu (ops gpu_ops)
[3.718015] etnaviv gpu-subsystem: bound 13.gpu (ops gpu_ops)
[3.724133] etnaviv gpu-subsystem: bound 2204000.gpu (ops gpu_ops)
[3.730351] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[3.771045] etnaviv-gpu 13.gpu: model: GC2000, revision: 5108
[3.802887] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
[3.848287] [drm] Initialized etnaviv 1.0.0 20150302 on minor 1

Regards,

-- 
Robert Nelson
https://rcn-ee.com/