Hi Linus,
A bunch of change across the board, the main things are some vblank
fallout in radeon and nouveau required some work, but I think this should
fix it all. There is also one drm fix for an oops in vmwgfx with how we
pass the drm master around.
The rest is just some amdgpu, i915, imx a
On Sat, Dec 05, 2015 at 09:12:34AM +0100, Takashi Iwai wrote:
> On Sat, 05 Dec 2015 12:27:03 +0100,
> Subhransu S. Prusty wrote:
> >
> > On Fri, Dec 04, 2015 at 06:59:19AM +0100, Takashi Iwai wrote:
> > > On Fri, 04 Dec 2015 12:08:26 +0100,
> > > Subhransu S. Prusty wrote:
> > > >
> > > > On Thu,
#x27;s going wrong here. This way you should be able to
finally dig up what's the issue with radeon.
Thanks for sticking with that.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/1e5da638/attachment-0001.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/3a39335c/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=64661
Jason Schulz changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
he build process to produce an unbootable
kernel is the bad one, and by skipping it I've made it impossible to identify
it as the initial bad commit?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/e74ef256/attachment.html>
On Fri, Dec 4, 2015 at 5:48 PM, Greg Hackmann wrote:
> On 12/04/2015 11:23 AM, Rob Herring wrote:
>>
>> On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard
>> wrote:
>>>
>>> Hi Rob,
>>>
>>> I got the same problem today with sti drm/kms driver and dumb Bo.
>>> The issue comes become hwcomposer beca
On Sat, Dec 5, 2015 at 5:42 AM, Russell King - ARM Linux
wrote:
> On Sat, Dec 05, 2015 at 12:26:19PM +0100, Lucas Stach wrote:
>> I see where you are going here and I appreciate that this discussion
>> isn't a exercise in bikeshed, but based on technical facts.
>
> It would be nice (for the sake o
On Fri, Dec 04, 2015 at 06:59:19AM +0100, Takashi Iwai wrote:
> On Fri, 04 Dec 2015 12:08:26 +0100,
> Subhransu S. Prusty wrote:
> >
> > On Thu, Dec 03, 2015 at 04:57:14PM +0100, Takashi Iwai wrote:
> > > On Thu, 03 Dec 2015 22:08:53 +0100,
> > > Subhransu S. Prusty wrote:
> > > >
> > > > Setting
On Sat, Dec 05, 2015 at 12:27:19AM +0200, Laurent Pinchart wrote:
> OMAP GEM objects backed by dma_buf reuse the current OMAP GEM object
> support as much as possible. If the imported buffer is physically
> contiguous its physical address will be used directly, reusing the
> OMAP_BO_MEM_DMA_API cod
On Sat, Dec 05, 2015 at 11:02:09AM +, Russell King - ARM Linux wrote:
> On Sat, Dec 05, 2015 at 11:12:08AM +0100, Daniel Vetter wrote:
> > Given that I think the current etnaviv is a sound architecture. And I'm
> > not saying that because drm requires everything to be smashed into one
> > drive
2015-12-04 15:00 GMT+01:00 Lucas Stach :
> Signed-off-by: Lucas Stach
Acked-by: Christian Gmeiner
greets
--
Christian Gmeiner, MSc
https://soundcloud.com/christian-gmeiner
On Sat, Dec 05, 2015 at 04:35:11PM +0100, Daniel Vetter wrote:
> In theory dma-buf could keep track of who's flushed a buffer already, but
> there's no implementation of that yet. And for a generic one we'd need to
> violate the current dma api abstractions. So yeah, perf is going to tank
> until t
On Sat, Dec 5, 2015 at 3:40 PM, Rob Herring wrote:
> On Fri, Dec 4, 2015 at 5:48 PM, Greg Hackmann wrote:
>> On 12/04/2015 11:23 AM, Rob Herring wrote:
>>>
>>> On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard
>>> wrote:
Hi Rob,
I got the same problem today with sti drm/kms
Am Freitag, den 04.12.2015, 14:19 -0600 schrieb Rob Herring:
> On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach
> wrote:
> > Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
> > > On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach > > .de> wrote:
> > > > Am Freitag, den 04.12.2015, 10:29 -0600
On Sat, Dec 05, 2015 at 12:26:19PM +0100, Lucas Stach wrote:
> I already sketched up the alternative of having the master driver scan
> the DT for matching GPU nodes at probe time and binding them together
> into a single device. But given that we end up with one master device
> anyways, do you rea
On Sat, Dec 05, 2015 at 12:26:19PM +0100, Lucas Stach wrote:
> I see where you are going here and I appreciate that this discussion
> isn't a exercise in bikeshed, but based on technical facts.
It would be nice (for the sake of this discussion not getting heated)
if Rob could show that he's been r
Patch #1 & #2 are Reviewed-by: Christian König
For patch #3:
Couldn't we just in a loop go over all the dw in the IB and swap them
after writing them? That would simplify the patch massively.
And line like the one below just look a bit odd to me:
> for (i = ib.length_dw; i < ib_size_dw;
On Fri, Dec 04, 2015 at 03:48:26PM -0800, Greg Hackmann wrote:
> On 12/04/2015 11:23 AM, Rob Herring wrote:
> >On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard
> > wrote:
> >>Hi Rob,
> >>
> >>I got the same problem today with sti drm/kms driver and dumb Bo.
> >>The issue comes become hwcomposer b
On Fri, Dec 04, 2015 at 05:43:33PM -0500, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 5:05 PM, Russell King - ARM Linux
> wrote:
> > On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote:
> >> On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux
> >> wrote:
> >> > Moreover, DRI3 is not
On Sat, Dec 05, 2015 at 11:12:08AM +0100, Daniel Vetter wrote:
> Given that I think the current etnaviv is a sound architecture. And I'm
> not saying that because drm requires everything to be smashed into one
> driver, since that's simple not the case.
There's other reasons as well, mostly from t
Hello,
I sent the path below a few weeks ago and did not have any feedback.
Is there any issue in it that I need to fix before submitting it again?
Thanks,
Nicolas Iooss
On 11/18/2015 06:58 PM, Nicolas Iooss wrote:
> drm_dev_set_unique() formats its parameter using kvasprintf() but many
> of its
On Sat, 05 Dec 2015 15:05:49 +0100,
Subhransu S. Prusty wrote:
>
> On Sat, Dec 05, 2015 at 09:12:34AM +0100, Takashi Iwai wrote:
> > On Sat, 05 Dec 2015 12:27:03 +0100,
> > Subhransu S. Prusty wrote:
> > >
> > > On Fri, Dec 04, 2015 at 06:59:19AM +0100, Takashi Iwai wrote:
> > > > On Fri, 04 Dec
On 4 December 2015 at 00:21, Rob Herring wrote:
> On Sat, Nov 28, 2015 at 4:38 AM, Xinliang Liu
> wrote:
>> Add DRM master driver for hi6220 SoC which used in HiKey board.
>> Add dumb buffer feature.
>> Add prime dmabuf feature.
>>
>> Signed-off-by: Xinliang Liu
>> Signed-off-by: Xinwei Kong
>
On Sat, 05 Dec 2015 12:27:03 +0100,
Subhransu S. Prusty wrote:
>
> On Fri, Dec 04, 2015 at 06:59:19AM +0100, Takashi Iwai wrote:
> > On Fri, 04 Dec 2015 12:08:26 +0100,
> > Subhransu S. Prusty wrote:
> > >
> > > On Thu, Dec 03, 2015 at 04:57:14PM +0100, Takashi Iwai wrote:
> > > > On Thu, 03 Dec
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/0cb2f705/attachment.html>
my kernel ".config" as well.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/de4bc5f4/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/7e87ff02/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/971a548e/attachment-0001.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/0caafa2d/attachment.html>
OMAP GEM objects backed by dma_buf reuse the current OMAP GEM object
support as much as possible. If the imported buffer is physically
contiguous its physical address will be used directly, reusing the
OMAP_BO_MEM_DMA_API code paths. Otherwise it will be mapped through the
TILER using a pages list
Split the individual steps of GEM object allocation and initialization
clearly. This improves readability and prepares for dma_buf import
support.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 75 ++
1 file changed, 43 insertions(+),
The GEM object can't be tiled without a usergart as that condition is
checked and considered as an error when creating the GEM object.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
The goto error statement end up just returning NULL without performing
any cleanup, replace it with a direct return.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem
The drm_gem_free_mmap_offset() call in omap_gem_free_object() is
redundant as the same function is called from drm_gem_object_release().
Remove it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/
The GEM object free handler frees memory allocated by the driver using
the pointer to the drm_gem_object instead of the pointer to the
omap_gem_object that embeds it. This doesn't cause any issue in practice
as the drm_gem_object is the first field of omap_gem_object, but would
cause memory corrupt
The driver assumes that only objects backed by shmem need to be mapped
through DMM. While this is true with the current code, the assumption
won't hold with dma_buf import support.
Condition the mapping based on whether the buffer has been allocated
using the DMA mapping API instead and clean up t
The 8 high order bits of the buffer flags are reserved for internal use.
Mask them out from the flags passed by userspace.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.c | 9 ++---
include/uapi/drm/omap_drm.h| 1 +
2 files changed, 7 insertions(+), 3 deletions
The field is set to true iff the usergart field is not NULL. Test
usergart instead.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
drivers/gpu/drm/omapdrm/omap_drv.h | 1 -
drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
drivers/gpu/drm/omapdrm/omap_gem.c | 5 +
The structure contains data related to a device instance, it shouldn't
be a global variable.
While at it rename the usergart structures with an omap_drm_ prefix.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h | 3 +++
drivers/gpu/drm/omapdrm/omap_gem.c | 54
Divide the GEM implementation in groups of functions to improve
readability.
No code change is performed by this commit.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 140 +++--
1 file changed, 87 insertions(+), 53 deletions(-)
diff --
Reorder functions to get rid of forward declarations
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 90 +++---
1 file changed, 46 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/o
Several DRM core function prototypes refer to functions that don't exist
anymore and are thus obviously never called. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b
Don't compile the fbdev emulation code when fbdev emulation support is
disabled.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/Makefile | 3 ++-
drivers/gpu/drm/omapdrm/omap_debugfs.c | 4
drivers/gpu/drm/omapdrm/omap_drv.c | 4
drivers/gpu/drm/omapdrm/omap_d
The plane reset handler frees the plane state and allocates a new
default state, but when doing so attempt to free the plane state using
the base plane state pointer instead of casting it to the
driver-specific state object that has been allocated. Fix it by using
the omap_plane_atomic_destroy_stat
Hello,
This patch series implements support for dma_buf import in the omapdrm driver.
The patches are based on top of the latest drm-next branch and can be found in
my git tree at
git://linuxtv.org/pinchartl/fbdev.git omapdrm/dmabuf-import
The first two patches are unrelated fixes and en
46 matches
Mail list logo
