On 03/15/2017 08:20 PM, Andrzej Hajda wrote:
DSI forwards te-gpios interrupts to display controller, but if display
controller works in HW-TRIGGER mode this interrupt is not necessary.
Making te-gpios property optional allows to avoid generating spare
interrupts.
With this patch we can get rid of
On 04/18/2017 03:00 PM, Andrzej Hajda wrote:
On 17.04.2017 08:02, Hoegeun Kwon wrote:
This patch add the panel device tree node for s6e3hf2 display
controller to TM2e dts.
Signed-off-by: Hoegeun Kwon
Maybe it would be good to remove te-gpios property - tm2/tm2e uses
hardware trigger, so it is
On 18.04.2017 09:44, Hoegeun Kwon wrote:
> On 04/18/2017 03:00 PM, Andrzej Hajda wrote:
>> On 17.04.2017 08:02, Hoegeun Kwon wrote:
>>> This patch add the panel device tree node for s6e3hf2 display
>>> controller to TM2e dts.
>>>
>>> Signed-off-by: Hoegeun Kwon
>> Maybe it would be good to remove
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #150 from Alfredo Mendez ---
I have an ASUS Strix R9 390 and attempted to get it to work, in a nutshell for
those looking for redemption... it didn't work.
I tried to switch drivers from radeon to amdgpu, and both equally fail
random
On Sat, 15 Apr 2017 22:21:42 +0300
Dan Carpenter wrote:
> It's not possible for endpoint to be zero so the test doesn't work. If
> we break on the first iteration through the loop then endpoint is 1 and
> "ret" is uninitialized.
>
> Fixes: ebc944613567 ("drm: convert drivers to use
> drm_of_fi
2017년 04월 18일 14:55에 Andrzej Hajda 이(가) 쓴 글:
> On 17.04.2017 08:02, Hoegeun Kwon wrote:
>> This patch supports TM2e panel and the panel has 1600x2560 resolution
>> in 5.65" physical.
>>
>> This identify panel type with compatibility string, also invoke
>> display mode that matches the type. So ad
On 04/18/2017 04:56 PM, Andrzej Hajda wrote:
On 18.04.2017 09:44, Hoegeun Kwon wrote:
On 04/18/2017 03:00 PM, Andrzej Hajda wrote:
On 17.04.2017 08:02, Hoegeun Kwon wrote:
This patch add the panel device tree node for s6e3hf2 display
controller to TM2e dts.
Signed-off-by: Hoegeun Kwon
Maybe
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45
warnings (v4.11-rc6-1973-ga4b2d83360ec)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1973-ga4b2d83360ec/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1973-ga4b2d83360ec
Git
This patch add the panel device tree node for s6e3hf2 display
controller to TM2e dts.
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
---
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-
Hi all,
The purpose of this patch is add support for s6e3hf2 AMOLED panel on
the TM2e board. The panel has 1600x2560 resolution in 5.65" physical
panel in the TM2e device.
The s6e3hf2 panel(5.65") is simliar to the previous s6e3ha2 panel(5.7"),
but resolution and some command message are differen
This patch supports TM2e panel and the panel has 1600x2560 resolution
in 5.65" physical.
This identify panel type with compatibility string, also invoke
display mode that matches the type. So add the check code for s6e3ha2
compatibility and s6e3hf2 type and select the drm_display_mode of
default a
The samsung s6e3hf2 panel is a 5.65" 1600x2560 AMOLED panel connected
using MIPI-DSI interfaces.
The s6e3hf2 is add to samsung,s6e3ha2.txt binding because it is a
panel similar to the s6e3ha2. So add the compatible string and
comments.
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
---
On Mon, 17 Apr 2017, Georgios Dakidis wrote:
> lspci -n
> 00:02.0 0300: 8086:0f31 (rev 0e)
> lspci -nn
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor
> Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e)
>
> dmesg ( with drm.debug=14)
Hi there, did you not
Hi,
Thanks for that rework.
On Sun, Apr 16, 2017 at 08:08:43PM +0800, Icenowy Zheng wrote:
> As we are going to add support for the Allwinner DE2 engine in sun4i-drm
> driver, we will finally have two types of display engines -- the DE1
> backend and the DE2 mixer. They both do some display blend
Hi Daniel,
On Tuesday 18 Apr 2017 08:20:29 Daniel Vetter wrote:
> On Sat, Apr 15, 2017 at 11:16 AM, Laurent Pinchart wrote:
> > - DRM_IOCTL_DEF_DRV(OMAP_GEM_CPU_PREP, ioctl_gem_cpu_prep,
> > + DRM_IOCTL_DEF_DRV(OMAP_GEM_CPU_PREP, ioctl_gem_cpu_prep_fini,
> > D
On Sun, Apr 16, 2017 at 08:08:44PM +0800, Icenowy Zheng wrote:
> Allwinner have a new "Display Engine 2.0" in their new SoCs, which comes
> with mixers to do graphic processing and feed data to TCON, like the old
> backends and frontends.
>
> Add support for the mixer on Allwinner V3s SoC; it's th
Hi Chen-Yu,
On Sat, Apr 08, 2017 at 01:30:55AM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Thu, Mar 9, 2017 at 10:40 PM, Maxime Ripard
> wrote:
> > On Thu, Mar 09, 2017 at 07:20:30PM +0800, Chen-Yu Tsai wrote:
> >> On Thu, Mar 9, 2017 at 6:36 PM, Maxime Ripard
> >> wrote:
> >> > Hi,
> >> >
> >> > O
Hi,
> > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
> > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
> > only format supported by bochs-drm), and we have to interpret that in
> > bigendian byte order on the host side to get a correct displa
freedesktop.org has adopted a formal&enforced code of conduct:
https://www.fooishbar.org/blog/fdo-contributor-covenant/
https://www.freedesktop.org/wiki/CodeOfConduct/
Besides formalizing things a bit more I don't think this changes
anything for us, we've already peer-enforced respectful and
cons
Hi,
> > Quite true that this proves nothing. However one should note that
> > fbcon -> fbdev works,
>
> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses
> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses
> native endian packed colour values.
Same is
On 17 April 2017 at 21:13, Robert Foss wrote:
> From: Sean Paul
>
> From drm_crtc.h, for use with the plane "rotation" property.
>
Please see the include/drm/README.
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedes
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings
(v4.11-rc6-1975-g4d374295ace9)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1975-g4d374295ace9/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1975-g4d374295ace9
Git Commit: 4d3
On Tue, 18 Apr 2017 12:00:17 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
> > > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
> > > only format supported by bochs-drm), and we have to interpret that
With LVDS we were incorrectly picking the pre-programmed mode instead of
the prefered mode provided by VBT. Make sure we pick the VBT mode if
one is provided. It is likely that the mode read-out code is still wrong
but this patch fixes the immediate problem on most machines.
Bugzilla: https://bugs
drm-tip/drm-tip boot: 17 boots: 2 failed, 15 passed
(v4.11-rc6-1973-ga4b2d83360ec)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1973-ga4b2d83360ec/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1973-ga4b2d8
All the error codes we (ab)use are strictly not the right ones (since
they're all for the vfs, and the only thing we're allowed to do from
an ioctl is EINVAL). But ENOENT is the common error code for failed to
look up an object throughout drm, so let's use it in the cma helpers,
too.
Cc: Laurent P
Hi Daniel,
Thank you for the patch.
On Tuesday 18 Apr 2017 14:11:20 Daniel Vetter wrote:
> All the error codes we (ab)use are strictly not the right ones (since
> they're all for the vfs, and the only thing we're allowed to do from
> an ioctl is EINVAL). But ENOENT is the common error code for fa
https://bugs.freedesktop.org/show_bug.cgi?id=100708
Bug ID: 100708
Summary: Trine 2 doesn't start on radeonsi on mesa 17
Product: Mesa
Version: 17.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Sev
https://bugs.freedesktop.org/show_bug.cgi?id=100708
Nikita Krupenko changed:
What|Removed |Added
URL||https://bugs.mageia.org/sho
Linux core provide helpers for polling with timeout, lets use them.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gp
MIC driver should use info from CRTC to check mode of work instead of
illegally peeking into nodes of other devices.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 44 +++--
1 file changed, 4 insertions(+), 40 deletions(-)
diff --git a/dri
Hi Inki,
This patchset beside cleanup/refactoring patches (01-03) adds code to propagate
info provided by MIPI-DSI panels about its mode of work (video/command mode).
The propagation is performed for whole pipeline as every its elements uses it.
Regards
Andrzej
Andrzej Hajda (7):
drm/exynos/d
mipi_dsi framework provides information about panel's mode of work.
This info should be propagated upstream to configure all elements of
the pipeline. As CRTC is the common nominator of the pipeline we can put
such info into its structures.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos
Description of drm_helper_hpd_irq_event clearly states that drivers
supporting hotplug events per connector should use different helper -
drm_kms_helper_hotplug_event. To achieve it following changes have
been performed:
- moved down all DSI ops - they require exynos_dsi_disable function
to be defi
All encoders share the same code to set encoders possible_crtcs field.
The patch creates helper to abstract out this code.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_dp.c | 15 +--
drivers/gpu/drm/exynos/exynos_drm_core.c | 1 +
drivers/gpu/drm/exynos/exyno
Since panel's mode of work is propagated properly from panel to DECON,
there is no need to use redundant private property. The only issue with
such approach is that check for required interrupts should be postponed
until panel communicate its requirements - ie to atomic_check.
Signed-off-by: Andrz
Since i80/command mode is determined in runtime by propagating info
from panel this property can be removed.
Signed-off-by: Andrzej Hajda
---
.../devicetree/bindings/display/exynos/exynos5433-decon.txt | 6 --
1 file changed, 6 deletions(-)
diff --git
a/Documentation/devicetree/bin
fourcc is not a string, it's a packed integer. This happens to work out
on LE, but gets reversed on BE.
Signed-off-by: Ilia Mirkin
---
tests/modetest/modetest.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
i
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45
warnings (v4.11-rc6-1976-gb15e4217c2dc)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1976-gb15e4217c2dc/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1976-gb15e4217c2dc
Git
Hi,
> > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest
> > here, it drives the qemu stdvga with offb, not bochs-drm.
>
> I suppose this proves the virtual machine itself is correct about
> framebuffer endianess? Except you are running it on a little-endian
> host machine
On Tue, 18 Apr 2017 15:39:53 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest
> > > here, it drives the qemu stdvga with offb, not bochs-drm.
> >
> > I suppose this proves the virtual machine itself is correct about
> > framebuf
On Mon, Apr 03, 2017 at 11:57:55AM -0700, Laura Abbott wrote:
> When CMA was first introduced, its primary use was for DMA allocation
> and the only way to get CMA memory was to call dma_alloc_coherent. This
> put Ion in an awkward position since there was no device structure
> readily available an
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45
warnings (v4.11-rc6-1976-gba8ae8c72f16)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1976-gba8ae8c72f16/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1976-gba8ae8c72f16
Git
https://bugs.freedesktop.org/show_bug.cgi?id=100465
Julien Isorce changed:
What|Removed |Added
Attachment #130788|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=100465
Julien Isorce changed:
What|Removed |Added
Attachment #130787|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=100465
Julien Isorce changed:
What|Removed |Added
Attachment #130789|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=100465
Julien Isorce changed:
What|Removed |Added
Attachment #130790|0 |1
is obsolete|
On Tue, Apr 18, 2017 at 02:13:59PM +, David Laight wrote:
> From: Logan Gunthorpe
> > Sent: 13 April 2017 23:05
> > Straightforward conversion to the new helper, except due to
> > the lack of error path, we have to warn if unmapable memory
> > is ever present in the sgl.
Interesting that you d
drm-tip/drm-tip boot: 114 boots: 2 failed, 112 passed
(v4.11-rc6-1975-g4d374295ace9)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1975-g4d374295ace9/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1975-g4d37
2017-04-17 Sumit Semwal :
> On 17 April 2017 at 18:43, Gustavo Padovan wrote:
> > 2017-04-13 Dave Airlie :
> >
> >> From: Dave Airlie
> >>
> >> sync_file uses the reference count of the file, the internal
> >> kref was never getting moved past 1.
> >>
> >> We can reintroduce this if we decide we
On Tue, Apr 18, 2017 at 03:29:29PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Tuesday 18 Apr 2017 14:11:20 Daniel Vetter wrote:
> > All the error codes we (ab)use are strictly not the right ones (since
> > they're all for the vfs, and the only thing we're allo
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45
warnings (v4.11-rc6-1977-gbd206d943e83)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1977-gbd206d943e83/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1977-gbd206d943e83
Git
https://bugs.freedesktop.org/show_bug.cgi?id=100712
Bug ID: 100712
Summary: ring 0 stalled after bytes_moved_threshold reached -
Cap Verde - HD 7770
Product: DRI
Version: DRI git
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=100712
--- Comment #1 from Julien Isorce ---
Created attachment 130902
--> https://bugs.freedesktop.org/attachment.cgi?id=130902&action=edit
dmesg_HD7770_kernel_amd-staging-4.9_ring_stalled
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=100712
--- Comment #2 from Julien Isorce ---
Created attachment 130903
--> https://bugs.freedesktop.org/attachment.cgi?id=130903&action=edit
dmesg_HD7770_kernel_amd-staging-4.9_ring_stalled
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=100712
Julien Isorce changed:
What|Removed |Added
Attachment #130903|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=100465
--- Comment #23 from Julien Isorce ---
I confirm that comment #9 and #12 are about a different issue (or at least
different symptoms). I reported it here:
https://bugs.freedesktop.org/show_bug.cgi?id=100712
--
You are receiving this mail becau
On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia
wrote:
> Hi there
>
> I am Raghav Jajodia, an Engineering student from India. While going through
> the X.org foundation, I felt that X.org is a great community for new Open
> Source developers. I am deeply interested in being a part of the community
On Tue, Apr 18, 2017 at 09:42:20AM -0600, Logan Gunthorpe wrote:
>
>
> On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote:
> > Interesting that you didn't CC any of the maintainers. Could you
> > do that in the future please?
>
> Please read the cover letter. The distribution list for the patchs
On Tue, Apr 18, 2017 at 10:40:21AM -0400, Sean Paul wrote:
> On Tue, Apr 18, 2017 at 03:29:29PM +0300, Laurent Pinchart wrote:
> > Hi Daniel,
> >
> > Thank you for the patch.
> >
> > On Tuesday 18 Apr 2017 14:11:20 Daniel Vetter wrote:
> > > All the error codes we (ab)use are strictly not the rig
drm-tip/drm-tip boot: 17 boots: 2 failed, 15 passed
(v4.11-rc6-1976-gb15e4217c2dc)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1976-gb15e4217c2dc/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1976-gb15e42
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings
(v4.11-rc6-1978-g7204beb80dcd)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1978-g7204beb80dcd/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1978-g7204beb80dcd
Git Commit: 720
On 18 April 2017 at 11:32, Emil Velikov wrote:
> On 17 April 2017 at 21:13, Robert Foss wrote:
>> From: Sean Paul
>>
>> From drm_crtc.h, for use with the plane "rotation" property.
>>
> Please see the include/drm/README.
>
To elaborate a bit:
The headers in include/drm should be synced via make
On 18 April 2017 at 16:48, Rob Clark wrote:
> On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia
> wrote:
>> Hi there
>>
>> I am Raghav Jajodia, an Engineering student from India. While going through
>> the X.org foundation, I felt that X.org is a great community for new Open
>> Source developers. I
Hi Boris,
On Fri, Apr 14, 2017 at 11:35:17AM +0200, Boris Brezillon wrote:
Hi Brian,
On Fri, 25 Nov 2016 16:48:58 +
Brian Starkey wrote:
Hi,
This is v3 of my series introducing a new connector type:
DRM_MODE_CONNECTOR_WRITEBACK
See v1 and v2 here: [1] [2]
Writeback connectors are used
On Fri, Apr 14, 2017 at 12:11:14PM +0200, Boris Brezillon wrote:
On Fri, 25 Nov 2016 16:49:00 +
Brian Starkey wrote:
Add the OUT_FENCE_PTR property to writeback connectors, to enable
userspace to get a fence which will signal once the writeback is
complete. It is not allowed to request an
Hi Boris,
On Fri, Apr 14, 2017 at 12:08:23PM +0200, Boris Brezillon wrote:
On Fri, 25 Nov 2016 16:48:59 +
Brian Starkey wrote:
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b5c6a8e..6bbd93f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers
On Fri, Apr 14, 2017 at 11:47:00AM +0200, Boris Brezillon wrote:
On Fri, 25 Nov 2016 16:49:04 +
Brian Starkey wrote:
+static int
+malidp_mw_encoder_atomic_check(struct drm_encoder *encoder,
+ struct drm_crtc_state *crtc_state,
+ str
Hi Laurent,
On Fri, Mar 31, 2017 at 11:19 AM, Laurent Pinchart
wrote:
> On Monday 27 Mar 2017 13:05:48 Geert Uytterhoeven wrote:
>> On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart wrote:
>> > The property is used by the driver but is missing from the DT bindings.
>> > Document it.
>> >
>> > Re
On Mon, Apr 17, 2017 at 1:13 PM, Robert Foss wrote:
> From: Sean Paul
>
> From drm_crtc.h, for use with the plane "rotation" property.
>
> Signed-off-by: Sean Paul
> Signed-off-by: Robert Foss
> Reviewed-by: Sumit Semwal
> ---
> Changes since v1:
> - Added r-b
>
> include/drm/drm.h | 8 +
drm-tip/drm-tip boot: 17 boots: 2 failed, 15 passed
(v4.11-rc6-1976-gba8ae8c72f16)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1976-gba8ae8c72f16/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1976-gba8ae8
Commit 10383aea2f44 ("kref: Implement 'struct kref' using refcount_t")
updated the kref implementation to use refcount_t. Commit 29dee3c03abc
("locking/refcounts: Out-of-line everything") changed the refcount_t
utility functions from static inline to EXPORT_SYMBOL_GPL functions.
Through a chain o
Commit 10383aea2f44 ("kref: Implement 'struct kref' using refcount_t")
updated the kref implementation to use refcount_t. Commit 29dee3c03abc
("locking/refcounts: Out-of-line everything") changed the refcount_t
utility functions from static inline to EXPORT_SYMBOL_GPL functions.
Through a chain o
I don't expect these two patches to be terribly popular, but let's see.
Nikhil Mahale described the problem here:
https://lists.freedesktop.org/archives/dri-devel/2017-April/138731.html
In short:
Commit 10383aea2f44 ("kref: Implement 'struct kref' using refcount_t")
updated the kref
On 18 April 2017 at 18:38, Kristian Høgsberg wrote:
> On Mon, Apr 17, 2017 at 1:13 PM, Robert Foss
> wrote:
>> From: Sean Paul
>>
>> From drm_crtc.h, for use with the plane "rotation" property.
>>
>> Signed-off-by: Sean Paul
>> Signed-off-by: Robert Foss
>> Reviewed-by: Sumit Semwal
>> ---
>
Hi,
This is v4 of the series to cleanup to Ion. Greg took some of the patches
that weren't CMA related already. There was a minor bisectability problem
with the CMA APIs so this is a new version to address that. I also
addressed some minor comments on the patch to collapse header files.
Thanks,
L
On Tue, Apr 18, 2017 at 1:32 PM, Emil Velikov wrote:
> On 18 April 2017 at 16:48, Rob Clark wrote:
>> On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia
>> wrote:
>>> Hi there
>>>
>>> I am Raghav Jajodia, an Engineering student from India. While going through
>>> the X.org foundation, I felt that X
Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.
Signed-off-by: Laura Abbott
---
include/linux/cma.h | 2 ++
mm/cma.c| 14 ++
2 files changed, 16 insertions(+)
diff --git a/include/
Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
useful to have an explicit name attached to each region. Store the name
in each CMA structure.
Signed-off-by: Laura Abbott
---
arch/powerpc/kvm/book3s_hv_builtin.c | 3 ++-
drivers/base/dma-contiguous.c| 5 +++--
i
When CMA was first introduced, its primary use was for DMA allocation
and the only way to get CMA memory was to call dma_alloc_coherent. This
put Ion in an awkward position since there was no device structure
readily available and setting one up messed up the coherency model.
These days, CMA can be
Now that we have proper caching, stop setting the DMA address manually.
It should be set after properly calling dma_map.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/staging/android
Several of the Ion ioctls were designed in such a way that they
necessitate compat ioctls. We're breaking a bunch of other ABIs and
cleaning stuff up anyway so let's follow the ioctl guidelines and clean
things up while everyone is busy converting things over anyway. As part
of this, also remove th
Once upon a time, phys_addr_t was not everywhere in the kernel. These
days it is used enough places that having a separate Ion type doesn't
make sense. Remove the extra type and just use phys_addr_t directly.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.h | 12 ++
The current model of Ion heap registration is based on the outdated
model of board files. The replacement for board files (devicetree)
isn't a good replacement for what Ion wants to do. In actuality, Ion
wants to show what memory is available in the system for something else
to figure out what to
Nobody uses this interface externally. Drop it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 59 ---
1 file changed, 59 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 7d40233..5a82
Most of the items have been taken care of by a clean up series. Remove
the completed items and add a few new ones.
Signed-off-by: Laura Abbott
---
drivers/staging/android/TODO | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/android/TODO
This never got set in the ioctl. Properly set a return value of 0 on
success.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 9eeb06f..d6fd350 100644
ion_handle was introduced as an abstraction to represent a reference to
a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf
emerged as the preferred standard for use in the kernel. This has made
the ion_handle an unnecessary abstraction and prone to race
conditions. ion_cli
Ion current has ion_priv.h and ion.h as header files. ion.h was intended
to be used for public APIs but Ion never ended up really having anything
public. Combine the two headers so there is only one internal header.
Signed-off-by: Laura Abbott
---
v4: minor cleanup suggested by Emil Velikov
---
On Tue, Apr 18, 2017 at 11:03 AM, Emil Velikov wrote:
> On 18 April 2017 at 18:38, Kristian Høgsberg wrote:
>> On Mon, Apr 17, 2017 at 1:13 PM, Robert Foss
>> wrote:
>>> From: Sean Paul
>>>
>>> From drm_crtc.h, for use with the plane "rotation" property.
>>>
>>> Signed-off-by: Sean Paul
>>> S
drm-tip/drm-tip boot: 17 boots: 2 failed, 15 passed
(v4.11-rc6-1977-gbd206d943e83)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1977-gbd206d943e83/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1977-gbd206d
https://bugs.freedesktop.org/show_bug.cgi?id=100681
--- Comment #5 from Andy Furniss ---
OK, I sent a mail - awaiting moderation for the cc as I am not on any llvm
lists.
I did try to add the author as cc on the tracker when I filed the bug, but no
luck, it would be handy if committers could joi
For the Raspberry Pi's bindings, the power domain also implicitly
turns on the clock and deasserts reset, but for the new Cygnus port we
start representing the clock in the devicetree.
Signed-off-by: Eric Anholt
---
.../devicetree/bindings/display/brcm,bcm-vc4.txt | 3 ++
drivers/gpu/drm/vc4/
Cygnus has V3D 2.6 instead of 2.1, and doesn't use the VC4 display
modules. The V3D can be uniquely identified by the IDENT[01]
registers, and there's nothing to key off of for the display change
other than the lack of DT nodes for the display components, but it's
convention to have new compatible
The FBDEV initialization would throw an error in dmesg, when we just
want to silently not initialize fbdev on a V3D-only VC4 instance.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_kms.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/v
Eric Anholt writes:
> For the Raspberry Pi's bindings, the power domain also implicitly
> turns on the clock and deasserts reset, but for the new Cygnus port we
> start representing the clock in the devicetree.
> + v3d->clk = devm_clk_get(dev, "v3d_clk");
> + if (IS_ERR(v3d->clk)) {
> +
On Tue, 2017-04-18 at 12:10 +0200, Daniel Vetter wrote:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this chan
On 14 April 2017 at 19:45, Chris Wilson wrote:
> On Tue, Apr 11, 2017 at 01:22:12PM +1000, Dave Airlie wrote:
>> This set of sync object patches should address most of the issues
>> raised in review.
>>
>> The major changes:
>> Race on destroy should be gone,
>> Documentation fixups
>> amdgpu inte
On Tue, Apr 18, 2017 at 02:27:14PM -0400, Rob Clark wrote:
> On Tue, Apr 18, 2017 at 1:32 PM, Emil Velikov
> wrote:
> > On 18 April 2017 at 16:48, Rob Clark wrote:
> >> On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia
> >> wrote:
> >>> Hi there
> >>>
> >>> I am Raghav Jajodia, an Engineering stu
https://bugzilla.kernel.org/show_bug.cgi?id=194843
--- Comment #6 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
Some more observation: It seems the hangs happen much more often/frequent with
kernel 4.11 than with 4.10. Where 4.10 kernels running usually several days, I
have a hang with 4.
1 - 100 of 143 matches
Mail list logo
