l crash on kernel 3.18.x series. I'm testing the
patch now.
--
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/20
David,
Please incorporate the latest TDA998x I2C driver fixes, which can be
found at:
git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-tda998x-fixes
with SHA1 4a6ca1a2c2530af4611024476ba7005bf0336dfe.
This fixes the double-checksumming of the AVI infoframe which was
resulting in the checksum
On Wed, Aug 05, 2015 at 08:03:12PM +0100, Liviu Dudau wrote:
> I have to confess that I am not entirely up to speed with the TDA19988
> situation at the moment. Andrew Jackson was dealing with that and
> working with Jean to get that in the upstream, but his contract has
> ended and he has moved to
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150805/4e3fca23/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150805/558af61d/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150805/46b01c12/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=102351
beta992 at gmail.com changed:
What|Removed |Added
Kernel Version|Linux 4.2RC5|Linux desktop1
|
https://bugzilla.kernel.org/show_bug.cgi?id=102351
--- Comment #3 from beta992 at gmail.com ---
Created attachment 184491
--> https://bugzilla.kernel.org/attachment.cgi?id=184491&action=edit
xorg log
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=102351
--- Comment #2 from beta992 at gmail.com ---
Created attachment 184481
--> https://bugzilla.kernel.org/attachment.cgi?id=184481&action=edit
dmesg
dmesg output
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=102351
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 f
https://bugzilla.kernel.org/show_bug.cgi?id=102351
Bug ID: 102351
Summary: Radeon R9 270: Flickering Screen (Dual Monitor setup)
Product: Drivers
Version: 2.5
Kernel Version: Linux 4.2RC5
Hardware: All
OS: Linux
From: Gustavo Padovan
This functions was just hiding the encoder and connector creation in
a way that was less clean than if we get rid of it. For example,
exynos_encoder ops had .create_connector() defined only because we were
handing off the encoder and connector creation to
exynos_drm_create_e
From: Gustavo Padovan
.commit() is not used anymore, Exynos encoders now follow the
.enable()/.disable() semantics from drm atomic core, so remove this
callback.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
drivers/gpu/drm/exynos/exynos_drm_encoder.c |
From: Gustavo Padovan
exynos_dp_commit() was getting called twice by exynos encoder core, once
inside the .enable() call and another time by .commit() itself.
The remove of the second call caused the wake of a bug, the operations
orders inside exynos_dp_commit was wrong and we had to move
exynos
From: Gustavo Padovan
hdmi_commit() was getting called twice by exynos encoder core, once inside
the .enable() call and another time by .commit() itself.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
From: Gustavo Padovan
This struct was just representing encoder information, it was a member of
struct exynos_drm_encoder, so any code trying to access encoder data would
have to go through the encoder struct, get the display struct and then get
the data it want.
During this patchset we also rea
From: Gustavo Padovan
All CRTCs can only be LCD, HDMI or VIDI, so basically all CRTCs will be a
possible CRTCs. This patch removes an extra function with switch that was
only checking if the CRTC type was one of those three above.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exyno
From: Gustavo Padovan
These two display_ops are not used anywhere, remove them.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
From: Gustavo Padovan
phy_power_on() and phy_power_off() already checks for NULL pointer.
This patch removes the wrappers exynos_dp_phy_init() and
exynos_dp_phy_exit() since the only think they were doing was a check for
NULL phy.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exyno
From: Gustavo Padovan
The DRM Core doesn't have a dpms() operation anymore, everything
now is enable() or disable().
Signed-off-by: Gustavo Padovan
---
v2: set dp->dpms_mode after enable/disable
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 34 ---
drivers/gpu/drm/exynos/exyno
From: Gustavo Padovan
Hi,
This patchset is another important step in the exynos clean up, it removes
two exynos internal structs in favor of wider use of struct drm_encoder.
Structs exynos_drm_display and exynos_drm_encoder were doing exactly what
struct drm_encoder does so remove them makes th
Op 05-08-15 om 17:03 schreef Daniel Vetter:
> On Wed, Aug 5, 2015 at 4:57 PM, Maarten Lankhorst
> wrote:
>> Op 05-08-15 om 15:08 schreef Daniel Vetter:
>>> We want to make sure that no one tries to acquire more locks and
>>> states, and ww mutexes provide debug facilities for that. So use them.
>>
On Wed, Aug 05, 2015 at 06:53:03PM +0100, Russell King - ARM Linux wrote:
> On Wed, Aug 05, 2015 at 03:28:11PM +0100, Liviu Dudau wrote:
> > + hdmi-transmitter at 71 {
> > compatible = "nxp,tda998x";
> > reg = <0x71>;
> > + port {
Userspace is the one in charge of flush CPU by wrapping mmap with
begin{,end}_cpu_access.
v2: Remove LLC check cause we have dma-buf sync providers now. Also, fix return
before transferring ownership when mmap fails.
Signed-off-by: Tiago Vignatti
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 18
From: Daniel Vetter
FIXME: Update kerneldoc for begin/end to make it clear that those are
for mmap too.
Open: Do we need a special indication that the begin/end is from
userspace mmap and not from kernel mmap?
There's also the question already about kernel internal users - vmap
and kmap interfa
From: Daniel Thompson
Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
(DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
to mmap() the resulting dma-buf even when this is supported by the
DRM driver.
It is trivial to relax the restriction and permit read/write a
Hi,
I've tested these patches (in drm-intel-nightly, but also in CrOS kernel
v3.14) and they seem just enough for what we want to do: the idea is to create
a GEM bo in one process and pass the prime handle of the it to another
process, which in turn uses the handle only to map and write. This coul
On Wed, Aug 05, 2015 at 03:28:11PM +0100, Liviu Dudau wrote:
> + hdmi-transmitter at 71 {
> compatible = "nxp,tda998x";
> reg = <0x71>;
> + port {
> + tda998x_1_input: endpoint at 0 {
> +
On Wed, Aug 05, 2015 at 12:01:53AM +0100, Russell King - ARM Linux wrote:
> On Tue, Aug 04, 2015 at 08:05:57AM +0200, Jean-Francois Moine wrote:
> > On Tue, 28 Jul 2015 15:59:17 +0200
> > Jean-Francois Moine wrote:
> >
> > > Using hdmi_avi_infoframe_pack() to create the AVI infoframe calculates
>
https://bugzilla.kernel.org/show_bug.cgi?id=101391
--- Comment #3 from Michael Long ---
Sorry for the delay, I tried a bisect:
git bisect start 'v4.0..v4.1' 'drivers/gpu/drm'
# good: [39a8804455fb23f09157341d3ba7db6d7ae6ee76] Linux 4.0
git bisect good 39a8804455fb23f09157341d3ba7db6d7ae6ee76
# b
On 08/05/2015 04:08 AM, Daniel Vetter wrote:
> On Tue, Aug 04, 2015 at 06:30:25PM -0300, Tiago Vignatti wrote:
> Nah they don't have to be equal since the problem isn't that nothing goes
> out to memory where the display can see it, but usually only parts of it.
> I.e. you need to change your test
On Wed, Aug 5, 2015 at 4:57 PM, Maarten Lankhorst
wrote:
>
> Op 05-08-15 om 15:08 schreef Daniel Vetter:
>> We want to make sure that no one tries to acquire more locks and
>> states, and ww mutexes provide debug facilities for that. So use them.
>>
>> Cc: Rob Clark
>> Cc: Maarten Lankhorst
>> S
Hey,
Op 05-08-15 om 15:08 schreef Daniel Vetter:
> We want to make sure that no one tries to acquire more locks and
> states, and ww mutexes provide debug facilities for that. So use them.
>
> Cc: Rob Clark
> Cc: Maarten Lankhorst
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atom
If we shut down the crtc we might run into WM consistency checks which
fail because we haven't yet read out the WM state. So do that before
we sanitized the state.
This fixes a WARNING in the ilk wm code which assumes that level 0 WM
are always enabled in it's internal tracking. But since we start
Hi Linus,
Dave is on vacation at the moment, so please pull these fixes directly.
Just a few amdgpu fixes to make sure we report the proper firmware information
and number of render buffers to userspace and a typo in a debugging function.
The following changes since commit 4469942bbbe5ebf845e0497
Pending interrupt status needs to be cleared before enable the
interrupt. Otherwise it's possible to get a pending interrupt instead
of an incoming interrupt.
Signed-off-by: Jilai Wang
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c | 10 +++---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 3 ++-
Update MAINTAINERS file for HDLCD driver.
Cc: Andrew Morton
Cc: Arnd Bergmann
Cc: Mauro Carvalho Chehab
Cc: Greg KH
Cc: Joe Perches
Cc: Jiri Slaby
Signed-off-by: Liviu Dudau
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 443dc62..
ARM's Juno board has two HDLCD controllers, each linked to an NXP
TDA19988 HDMI transmitter that provides output encoding. Add them
to the device tree.
Signed-off-by: Liviu Dudau
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 70 +-
1 file changed, 68 insertions(+),
The HDLCD controller is a display controller that supports resolutions
up to 4096x4096 pixels. It is present on various development boards
produced by ARM Ltd and emulated by the latest Fast Models from the
company.
Cc: David Airlie
Cc: Robin Murphy
Signed-off-by: Liviu Dudau
---
drivers/gpu/
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Liviu Dudau
---
.../devicetree/bindings/drm/arm/arm,hdlcd.txt | 74 ++
1 file changed, 74 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/arm/arm,h
This series adds support for ARM's HDLCD display controller found in Juno
and ARM TC2 Coretile. The HDLCD outputs an RGB stream that feeds into a
single digital encoder (DVI or HDMI).
This series depends on Sudeep Holla's series that introduces support for
SCPI[1] on Juno.
Only the Juno functiona
From: Zhao Junwang
Since driver is now fully atomic, we should add DRIVER_ATOMIC to
.driver_features
Cc: Daniel Vetter
Cc: Gerd Hoffmann
Cc: Matthew Garrett
Cc: Dave Airlie
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/cirrus/cirrus_drv.c |2 +-
1 file changed, 1 insertion(+), 1 del
From: Zhao Junwang
Run dpms operations through the atomic interfaces. This basically
removes the .dpms() callback from encoders and crtcs and use .disable
and .enable to turn the crtc on and off.
use drm_atomic_helper_connector_dpms for connector
Cc: Daniel Vetter
Cc: Gerd Hoffmann
Cc: Matthe
From: Zhao Junwang
Now that phase 1 and phase 2 are completed, switch .set_config
helper to use the atomic one.
-stop looking legacy crtc->primary->fb, instead we should use
crtc->primary->state->fb
.prepare() calls are no more needed, remove them
.mode_set() and .mode_set_base are no longer ne
From: Zhao Junwang
when the first modeset calls prepare_fb, bo->pin_count change from
0 to 1, then the second modeset with the same fb, that should set
bo->pin_count to 2, and then when cleanup_fb was called, bo->pin_count
should be 2 to 1.
But in the cirrus_bo_pin, it will set bo->pin_count = 1
From: Zhao Junwang
Now that phase 1 and 2 are complete we can switch the
update/disable_plane callbacks to their atomic version
Cc: Daniel Vetter
Cc: Gerd Hoffmann
Cc: Matthew Garrett
Cc: Dave Airlie
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/cirrus/cirrus_main.c |3 +++
drivers/g
From: Zhao Junwang
Set CRTC, planes and connectors to use the default implementations
from the atomic helper library.
Cc: Daniel Vetter
Cc: Gerd Hoffmann
Cc: Matthew Garrett
Cc: Dave Airlie
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/cirrus/cirrus_mode.c | 12
1 file cha
From: Zhao Junwang
-register driver's own primary plane
-use drm_crtc_init_with_planes instead drm_crtc_init
-the new atomic_infrastructure needs ->mode_set_nofb callback
Cc: Daniel Vetter
Cc: Gerd Hoffmann
Cc: Matthew Garrett
Cc: Dave Airlie
Signed-off-by: Zhao Junwang
---
drivers/gpu/dr
From: Zhao Junwang
This patch series aim to convert DRM_CIRRUS to atomic mode-setting.
This mostly reference my previous patch series on DRM_BOCHS and
Gustavo Padovan;s patch series on drm/exynos.
Zhao Junwang (7):
drm/cirrus: phase 1 - use the transitional helpers
drm/cirrus: phase 2: wire
DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
.load = cirrus_driver_load,
.unload = cirrus_driver_unload,
.set_busid = drm_pci_set_busid,
--
1.7.10.4
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150805/fc0e255a/attachment.html>
From: Zhao Junwang
Since driver is now fully atomic, we should add DRIVER_ATOMIC to
.driver_features
Cc: Daniel Vetter
Cc: Gerd Hoffmann
Cc: Matthew Garrett
Cc: Dave Airlie
Cc: Zhao Junwang
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/cirrus/cirrus_drv.c |2 +-
1 file changed, 1 i
We want to make sure that no one tries to acquire more locks and
states, and ww mutexes provide debug facilities for that. So use them.
Cc: Rob Clark
Cc: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/driver
ktop.org/archives/dri-devel/attachments/20150805/4312d6bc/attachment.html>
On 08/01/2015 03:32 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> Thank you for the patch.
>
> On Monday 13 July 2015 12:13:52 Archit Taneja wrote:
>> Remove FB_* config options since the driver doesn't call any fbdev
>> functions directly.
>>
>> Remove FB_KMS_HELPER as this would now be selected
Legacy fbdev emulation support via DRM is achieved through KMS FB helpers.
Most modesetting drivers enable provide fbdev emulation by default by
selecting KMS FB helpers. A few provide a separate Kconfig option for the
user to enable or disbale fbdev emulation.
Enabling fbdev emulation is finally
On Wed, Aug 05, 2015 at 10:49:57AM +0300, Oded Gabbay wrote:
> On Wed, Aug 5, 2015 at 10:48 AM, Daniel Vetter wrote:
> > Forwarding -fixes pull to Linus since Dave is on vacation for 2 weeks.
> > -Daniel
> >
>
> Daniel,
> This is for 4.3 merge window...
> This is not for 4.2-rcX
> I don't think w
On Wed, Aug 5, 2015 at 10:48 AM, Daniel Vetter wrote:
> Forwarding -fixes pull to Linus since Dave is on vacation for 2 weeks.
> -Daniel
>
Daniel,
This is for 4.3 merge window...
This is not for 4.2-rcX
I don't think we need to forward this to Linus.
Oded
2015-08-05 Inki Dae :
Hi Inki,
> On 2015ë
08ì 04ì¼ 23:47, Gustavo Padovan wrote:
> > Hi Inki,
> >
> > 2015-08-04 Inki Dae :
> >
> >> On 2015ë
08ì 04ì¼ 04:09, Gustavo Padovan wrote:
> >>> From: Gustavo Padovan
> >>>
> >>> struct exynos_drm_encoder was justing wrapping struct drm_encod
Hi all,
On Wed, Jun 10, 2015 at 6:44 PM, Gary Bisson
wrote:
> Hi all,
>
> This patch is the follow-up of a request from Philipp to add the Okaya display
> to the simple panel driver.
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/346657.html
>
> v2:
> - split into 2 patches, add
On 2015ë
08ì 04ì¼ 23:47, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-08-04 Inki Dae :
>
>> On 2015ë
08ì 04ì¼ 04:09, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
>>> only a drm_encoder member and the in
Hi Dave,
Two small bug fixes for the code you pulled for 4.3:
- Used a SHIFT define instead of a MASK define to check if a bit is turned on
when destroying hqd. Luckily, this is in gfx7 interface file with amdgpu,
which was used only for bring-up purposes of amdgpu, so no real effect on
a
Forwarding -fixes pull to Linus since Dave is on vacation for 2 weeks.
-Daniel
On Wed, Aug 05, 2015 at 10:05:00AM +0300, Oded Gabbay wrote:
> Hi Dave,
>
> Two small bug fixes for the code you pulled for 4.3:
>
> - Used a SHIFT define instead of a MASK define to check if a bit is turned on
> wh
(near initialization
for âomap_crtc_helper_funcs.atomic_flushâ) [-Werror]
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150805/60ee84d1/attachment.sig>
On Tue, Aug 04, 2015 at 06:30:25PM -0300, Tiago Vignatti wrote:
> On 07/31/2015 06:02 PM, Chris Wilson wrote:
> >
> >The first problem is that llc does not guarrantee that the buffer is
> >cache coherent with all aspects of the GPU. For scanout and similar
> >writes need to be WC.
> >
> >if (obj->h
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150805/6e349d9b/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150805/08a621e2/attachment.html>
-
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/20150805/066270dc/attachment.html>
On Tue, Aug 04, 2015 at 08:05:57AM +0200, Jean-Francois Moine wrote:
> On Tue, 28 Jul 2015 15:59:17 +0200
> Jean-Francois Moine wrote:
>
> > Using hdmi_avi_infoframe_pack() to create the AVI infoframe calculates
> > the checksum of the frame and breaks the second calculation which is
> > done in
68 matches
Mail list logo
