-next plans/status

[Thierry Reding]

On Mon, Nov 03, 2014 at 08:29:24AM +1000, Dave Airlie wrote:
> So since -rc5/6 cutoff last merge windows was so successful from my
> POV, I think I'll keep trucking with the idea.
> 
> Things I have on my radar for this window, outside normal driver pull 
> requests:
> 
> a) rockchip drm - this needs IOMMU driver merged first so I can even
> compile it, on hold but shouldn't be a problem if the iommu driver
> gets merged somewhere first.
> 
> b) atmel hlcdc - where are we on the precursor patches for this?
> 
> c) atomic - Daniel seems to have done a good job pulling the helpers
> in line, Rob, Sean, Collabora - please jump on board and get this
> thing over the line.
> 
> d) Exynos/bridge/make my chromebook work upstream patches, where are
> we on these, Ajay/Thierry I believe you are in the know.

Daniel briefly looked at this and was somewhat disgusted with how little
safety this framework has built in. The infrastructure was copied from
DRM panel which therefore suffers from the same shortcomings. I've been
working on a small set of patches to implement some generic mechanism to
add reference counting and such for this type of infrastructure.

Until those patches are ready I think we either can't merge the patches
or we take the risk that drivers will actually use the current fragile
infrastructure in a safe way and then supply the safer infrastructure
later on.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

-next plans/status

[Alex Deucher]

On Sun, Nov 2, 2014 at 5:29 PM, Dave Airlie  wrote:
> So since -rc5/6 cutoff last merge windows was so successful from my
> POV, I think I'll keep trucking with the idea.
>
> Things I have on my radar for this window, outside normal driver pull 
> requests:
>
> a) rockchip drm - this needs IOMMU driver merged first so I can even
> compile it, on hold but shouldn't be a problem if the iommu driver
> gets merged somewhere first.
>
> b) atmel hlcdc - where are we on the precursor patches for this?
>
> c) atomic - Daniel seems to have done a good job pulling the helpers
> in line, Rob, Sean, Collabora - please jump on board and get this
> thing over the line.
>
> d) Exynos/bridge/make my chromebook work upstream patches, where are
> we on these, Ajay/Thierry I believe you are in the know.
>
> e) AMD new driver, if this was aiming for next merge window you are
> probably late, since it will require review at a guess.

No plans to merge amdgpu for 3.19.

Alex

-next plans/status

[Boris Brezillon]

Hi Dave,

On Mon, 3 Nov 2014 08:29:24 +1000
Dave Airlie  wrote:

> So since -rc5/6 cutoff last merge windows was so successful from my
> POV, I think I'll keep trucking with the idea.
> 
> Things I have on my radar for this window, outside normal driver pull 
> requests:
> 
> a) rockchip drm - this needs IOMMU driver merged first so I can even
> compile it, on hold but shouldn't be a problem if the iommu driver
> gets merged somewhere first.
> 
> b) atmel hlcdc - where are we on the precursor patches for this?

What do you mean by "precursor patches" ?

If by precursor patches you mean the dependencies of the DRM driver,
here is a quick status:

- The atmel-hlcdc [1] MFD driver has been taken by Lee Jones
- My series reworking the flip-work infrastructure [2] has been acked by
  Rob and is waiting for you (I guess I should rebase it on
  3.18-rcX or drm-next) ;-)
- My series sharing video bus format definitions between the V4L2 and
  DRM subsystems [3] is still being discussed. AFAICT, the only blocking
  point is that we need a documentation describing the available
  formats and we don't know which format to use (DocBook or txt) and
  where this documentation should be stored.

Regarding the driver itself, I still have to address Nicolas' (Ferre)
comments, and Thierry (Reding) was concerned by the proposed DT
binding (don't know if it's still the case).

Anyway, I really expect this driver to merged in 3.19 so let me know if
you see other blocking issues...

Best Regards,

Boris

[1]https://patchwork.ozlabs.org/patch/396808/
[2]http://thread.gmane.org/gmane.comp.video.dri.devel/110016
[3]https://lkml.org/lkml/2014/9/29/330



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-next plans/status

[Oded Gabbay]

Hi Dave,

I would like to add one more thing to your radar - amdkfd ;)

We are going to release AMD's HSA Runtime library as Open Source in the next 
few 
days, and coupled with the modification that Thomas Stellard did for the r600 
LLVM back-end, we are effectively releasing a _complete_ userspace Open Source 
stack/solution for running OpenCL applications on top of amdkfd.

The method for building & running kernel programs involves offline compilation 
of a .cl source file, using clang plus a version of the r600 LLVM back end 
which 
Tom has modified so that a HW ISA binary file is generated. That binary file 
will then be imported into the HSAIL RT using the hsa_code_unit_load() API 
function in the HSA RT, and can then be used in compute operations initiated 
via 
calls to the HSAIL RT API and writes to userspace queues.

The HSA RT communicates with the amdkfd through the libhsakmt userspace library 
(equivalent of libdrm). That library is already open sourced.

We will supply a fully working application (port of the MatrixMultiplication 
application), both .cl file and .c file. The .cl file can be compiled with the 
above mentioned method and the application will load it and submit it through 
the HSA RT queues.

I'm going to publish a v5 of the amdkfd patch-set together with the HSA RT. The 
major changed are:

1. Move driver to new /drm/amd/amdkfd location (As /drm/amd will contain all 
AMD's code in the future).
2. Add support for AQL packets because the HSA RT is now defaulting to work now 
with AQL packets and not PM4 packets.

Of course, I will send a more detailed cover letter with that version.

I know my v3 and v4 patch-set weren't reviewed (except for Alex who r-b my 
radeon patches), but I hope you/Jerome can review my v5 and coupled with the 
full stack open source, we won't have any show-stoppers from merging amdkfd to 
your 3.19 pull request to Linus.

We are of course committed and working on providing Open Source solution to 
other HSA enabled languages (e.g. Java, C++AMP) but that would require some 
more 
time.

Please tell me if you think this is an appropriate plan.

Thanks,

Oded


On 11/03/2014 12:29 AM, Dave Airlie wrote:
> So since -rc5/6 cutoff last merge windows was so successful from my
> POV, I think I'll keep trucking with the idea.
>
> Things I have on my radar for this window, outside normal driver pull 
> requests:
>
> a) rockchip drm - this needs IOMMU driver merged first so I can even
> compile it, on hold but shouldn't be a problem if the iommu driver
> gets merged somewhere first.
>
> b) atmel hlcdc - where are we on the precursor patches for this?
>
> c) atomic - Daniel seems to have done a good job pulling the helpers
> in line, Rob, Sean, Collabora - please jump on board and get this
> thing over the line.
>
> d) Exynos/bridge/make my chromebook work upstream patches, where are
> we on these, Ajay/Thierry I believe you are in the know.
>
> e) AMD new driver, if this was aiming for next merge window you are
> probably late, since it will require review at a guess.
>
> Dave.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

-next plans/status

[Dave Airlie]

So since -rc5/6 cutoff last merge windows was so successful from my
POV, I think I'll keep trucking with the idea.

Things I have on my radar for this window, outside normal driver pull requests:

a) rockchip drm - this needs IOMMU driver merged first so I can even
compile it, on hold but shouldn't be a problem if the iommu driver
gets merged somewhere first.

b) atmel hlcdc - where are we on the precursor patches for this?

c) atomic - Daniel seems to have done a good job pulling the helpers
in line, Rob, Sean, Collabora - please jump on board and get this
thing over the line.

d) Exynos/bridge/make my chromebook work upstream patches, where are
we on these, Ajay/Thierry I believe you are in the know.

e) AMD new driver, if this was aiming for next merge window you are
probably late, since it will require review at a guess.

Dave.