ring back on
another bug report that most likely has the same root cause.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/bc9ad1d5/attachment.html>
ode.h | 11 +-
> 17 files changed, 600 insertions(+), 22 deletions(-)
> create mode 100644 drivers/dma-buf/fence-collection.c
> create mode 100644 include/linux/fence-collection.h
>
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/356c86d0/attachment-0001.html>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/f667fc1c/attachment.html>
Some more tables with constant data were added with the polaris support
v2: missed a few
Signed-off-by: Nils Wallménius
---
.../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 32 --
.../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h | 2 +-
.../drm/amd/powerplay/hwmgr/po
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/a178d2b0/attachment.html>
On Mon, Apr 25, 2016 at 08:35:18PM +0200, Noralf Trønnes wrote:
>
> Den 25.04.2016 18:38, skrev Ville Syrjälä:
> >On Mon, Apr 25, 2016 at 06:05:20PM +0200, Daniel Vetter wrote:
> >>On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote:
> >>>On Mon, Apr 25, 2016 at 04:03:13PM +0200, No
https://bugzilla.kernel.org/show_bug.cgi?id=117181
--- Comment #3 from yves.dufournaud at gmail.com ---
Created attachment 214301
--> https://bugzilla.kernel.org/attachment.cgi?id=214301&action=edit
dmesg_after.txt
output of dmesg > dmesg_before; echo mem > /sys/power/state; dmesg >
dmesg_after
https://bugzilla.kernel.org/show_bug.cgi?id=117181
--- Comment #2 from yves.dufournaud at gmail.com ---
tested with CONFIG_PM_DEBUG with core/processors/device
dmesg > dmesg_before; echo mem > /sys/power/state; dmesg > dmesg_after
machine resume after few second, but mouse pointer is lost (not v
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #16 from Alex Deucher ---
(In reply to 3pb33h+1ymmkx54pslys from comment #15)
> Seems like alex made an typo i think it should be modprobe.blacklist=radeon
Yes you are correct, sorry about that.
--
You are receiving this mail becau
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #15 from 3pb33h+1ymmkx54pslys at sharklasers.com ---
Seems like alex made an typo i think it should be modprobe.blacklist=radeon
--
You are receiving this mail because:
You are watching the assignee of the bug.
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/e8cabb76/attachment.html>
Den 25.04.2016 18:38, skrev Ville Syrjälä:
> On Mon, Apr 25, 2016 at 06:05:20PM +0200, Daniel Vetter wrote:
>> On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote:
>>> On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote:
Den 25.04.2016 15:02, skrev Ville Syrjälä:
>
Applied patchset to my fsl-dcu tree.
--
Stefan
On 2016-04-16 22:25, Stefan Agner wrote:
> Hi all,
>
> This patchset fixes several issues around unloading/unbinding
> the driver. There is still one WARNING when unloading the driver
> while vblank interrupts are enabled. I am not sure what/who
> s
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/41fe6d14/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #14 from Alex Deucher ---
It sounds like it's a bug in the intel driver. The radeon driver appears to be
loading fine. Can you get any display on the intel card at all? You can
blacklist the radeon driver (append modeprobe.blanklis
Hi Arnd,
Thank you for the patch.
On Monday 25 Apr 2016 15:11:08 Arnd Bergmann wrote:
> A cleanup for the rcar-du driver left an unused variable behind:
>
> drm/rcar-du/rcar_du_drv.c: In function 'rcar_du_probe':
> drm/rcar-du/rcar_du_drv.c:300:24: error: unused variable 'connector'
> [-Werror=u
https://bugzilla.kernel.org/show_bug.cgi?id=117181
--- Comment #1 from yves.dufournaud at gmail.com ---
there is another issue: resuming from suspend to ram is failing, I would have
filled a separate bug, but apparently it can be linked to graphics.
following the instruction here:
https://01.org/
The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.
if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
drm_helper_hpd_irq_event(dp->drm_dev);
So there would no drm hpd event when cable plug in, to fix that
just nee
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #13 from Jason Vas Dias ---
Yes, radeon.runpm=0 has stopped the ACPI problem - but the latest Xorg
xf86-video-intel driver ( 2.99.917 ) apparently does not work with the
latest xorg server (1.18.3) and gets a segmentation violation o
Rockchip VOP couldn't output YUV video format for eDP controller, so
when driver detect connector support YUV video format, we need to hack
it down to RGB888.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 19 +++
1 file changed, 19 insertions(+)
On Mon, Apr 25, 2016 at 06:05:20PM +0200, Daniel Vetter wrote:
> On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote:
> > On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote:
> > >
> > > Den 25.04.2016 15:02, skrev Ville Syrjälä:
> > > > On Mon, Apr 25, 2016 at 02:55:52PM
It's helpful to expand the mode_valid callback to platform driver,
so they could valid the display mode or information.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 15 +++
include/drm/bridge/analogix_dp.h | 4
2 files cha
Some boards don't need to declare a panel device node, like the
display interface is DP monitors, so it's necessary to make the
panel detect to an optional action.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 48 -
1 file changed, 22 ins
There're an register define error in ANALOGIX_DP_PLL_REG_1 which introduced
by commit bcec20fd5ad6 ("drm: bridge: analogix/dp: add some rk3288 special
registers setting").
The PHY PLL input clock source is selected by ANALOGIX_DP_PLL_REG_1
BIT 0, not BIT 1.
Signed-off-by: Yakir Yang
---
drivers
RK3399 and RK3288 shared the same eDP IP controller, only some light
difference with VOP configure and GRF configure.
Signed-off-by: Yakir Yang
---
.../bindings/display/bridge/analogix_dp.txt| 1 +
.../display/rockchip/analogix_dp-rockchip.txt | 2 +-
drivers/gpu/drm/rockchip/anal
eDP controller need to declare which vop provide the video source,
and it's defined in GRF registers.
But different chips have different GRF register address, so we need to
create a device data to declare the GRF messages for each chips.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/rockchip/an
From: Gustavo Padovan
Support DRM out-fences creating a sync_file with a fence for each crtc
update with the DRM_MODE_ATOMIC_OUT_FENCE flag.
We then send an struct drm_out_fences array with the out-fences fds back in
the drm_atomic_ioctl() as an out arg in the out_fences_ptr field.
struct drm_o
From: Gustavo Padovan
Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init()
From: Gustavo Padovan
Now a drm_pending_event can either send a real drm_event or signal a
fence, or both. It allow us to signal via fences when the buffer is
displayed on the screen. Which in turn means that the previous buffer
is not in use anymore and can be freed or sent back to another drive
From: Gustavo Padovan
There is now a new property called FENCE_FD attached to every plane
state that receives the sync_file fd from userspace via the atomic commit
IOCTL.
The fd is then translated to a fence (that may be a fence_collection
subclass or just a normal fence) and then used by DRM to
From: Gustavo Padovan
If userspace is running an synchronously atomic commit and interrupts the
atomic operation during fence_wait() it will hang until the timer expires,
so here we change the wait to be interruptible so it stop immediately when
userspace wants to quit.
Also adds the necessary e
From: Gustavo Padovan
Creates a function that given an sync file descriptor returns a
fence_collection containing all fences in the sync_file.
If there is only one fence in the sync_file this fence itself is returned,
however if there is more than one, a fence_collection fence is returned.
v2:
From: Gustavo Padovan
Include fence-collection files in the DocBook.
Signed-off-by: Gustavo Padovan
---
Documentation/DocBook/device-drivers.tmpl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/DocBook/device-drivers.tmpl
b/Documentation/DocBook/device-drivers.tmpl
index 5
From: Gustavo Padovan
struct fence_collection inherits from struct fence and carries a
collection of fences that needs to be waited together.
It is useful to translate a sync_file to a fence to remove the complexity
of dealing with sync_files on DRM drivers. So even if there are many
fences in t
From: Gustavo Padovan
Hi,
Currently the Linux Kernel only have an implicit fencing mechanism
where the fence are attached directly to buffers and userspace is unaware of
what is happening. On the other hand explicit fencing which is not supported
yet by Linux but it expose fences to the userspac
Rename RK3288_DP marcos to ROCKCHIP_DP, prepare to add eDP
support for more Rockchip chips.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ++--
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 6 +++---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/367eb80d/attachment.html>
RK3399 and RK3288 shared the same eDP IP controller, only some light
difference with VOP configure and GRF configure.
Also same misc fix to analogix_dp driver:
- Hotplug invalid which report by Dan Carpenter
- Make panel detect to an optional action
- correct the register bit define error in ANAL
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #12 from Jason Vas Dias ---
Created attachment 214151
--> https://bugzilla.kernel.org/attachment.cgi?id=214151&action=edit
dmesg boot log
Boot DMESG log as requested
--
You are receiving this mail because:
You are watching the as
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #11 from Alex Deucher ---
(In reply to Jason Vas Dias from comment #10)
> OK, fine, I have to use FGLRX to use the Radeon as the primary display
> as I do under OEL7 (Linux 3.10) -
> what a terrific new open source radeon driver Lin
On 25 April 2016 at 18:08, Liviu Dudau wrote:
> On Mon, Apr 25, 2016 at 05:00:02PM +0100, Emil Velikov wrote:
>> On 25 April 2016 at 15:19, Liviu Dudau wrote:
>> > Add MAINTAINERS entry for ARM Mali-DP driver and update the
>> > HDLCD file matching pattern to cover only HDLCD rather than
>> > the
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #10 from Jason Vas Dias ---
OK, fine, I have to use FGLRX to use the Radeon as the primary display
as I do under OEL7 (Linux 3.10) -
what a terrific new open source radeon driver Linux 4.5 has.
But I cannot even get the Intel card
On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote:
>
> Den 25.04.2016 15:02, skrev Ville Syrjälä:
> > On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
> >> Den 25.04.2016 14:39, skrev Ville Syrjälä:
> >>> On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes w
On Mon, Apr 25, 2016 at 05:00:02PM +0100, Emil Velikov wrote:
> On 25 April 2016 at 15:19, Liviu Dudau wrote:
> > Add MAINTAINERS entry for ARM Mali-DP driver and update the
> > HDLCD file matching pattern to cover only HDLCD rather than
> > the whole drivers/gpu/drm/arm directory.
> >
> > Signed-
On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote:
> >
> > Den 25.04.2016 15:02, skrev Ville Syrjälä:
> > > On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
> > >> Den 25.04.2016 14:39, skrev Ville S
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/f6edfeaf/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #9 from Alex Deucher ---
(In reply to Jason Vas Dias from comment #8)
> As stated on the web-page quoted above ,
> ( https://wiki.archlinux.org/index.php/PRIME )
> an example xorg.conf to use the discrete card
> as primary GPU is:
>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/057e8dbf/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #8 from Jason Vas Dias ---
As stated on the web-page quoted above ,
( https://wiki.archlinux.org/index.php/PRIME )
an example xorg.conf to use the discrete card
as primary GPU is:
# Discrete Card as Primary GPU
Section "ServerLayo
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #7 from Jason Vas Dias ---
(In reply to Alex Deucher from comment #6)
> Your system is muxless so there is no mux to switch. The displays are only
> connected to the IGP. You need to use the xserver PRIME stuff to render
> with the
Provide a small convenience wrapper that transmits
ia set_tear_scanline command as suggested by
Thierry Reding.
Also includes small build fixes from Sumit Semwal.
Cc: Archit Taneja
Cc: John Stultz
Cc: Thierry Reding
Cc: Sumit Semwal
Signed-off-by: Vinay Simha BN
---
v2:
* Added fix for com
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160425/ccca2221/attachment.html>
|RESOLVED
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/739f179b/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/86496701/attachment.html>
fers often.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/487c3031/attachment.html>
l/attachments/20160425/9cfcde54/attachment.html>
nt was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/2e0abace/attachment-0001.html>
Hi Mario,
2016-04-25 Mario Kleiner :
> On 04/14/2016 07:48 PM, Gustavo Padovan wrote:
> >From: Gustavo Padovan
> >
> >Replace the legacy drm_send_vblank_event() with the new helper function.
> >
> >Signed-off-by: Gustavo Padovan
> >---
> > drivers/gpu/drm/nouveau/nouveau_display.c | 4 +++-
> >
On 25 April 2016 at 15:19, Liviu Dudau wrote:
> Add MAINTAINERS entry for ARM Mali-DP driver and update the
> HDLCD file matching pattern to cover only HDLCD rather than
> the whole drivers/gpu/drm/arm directory.
>
> Signed-off-by: Liviu Dudau
> ---
> MAINTAINERS | 10 +-
> 1 file change
Hi Maxime,
On 25 April 2016 at 14:22, Maxime Ripard
wrote:
> Documentation/devicetree/bindings/clock/sunxi.txt | 2 +
> .../bindings/display/sunxi/sun4i-drm.txt | 258
> arch/arm/boot/dts/sun5i-a13.dtsi | 39 +-
> arch/arm/boot/dts/sun5i-r8-chip.dts
https://bugzilla.kernel.org/show_bug.cgi?id=117181
Bug ID: 117181
Summary: graphic glitches for Kernel > 4.2 Intel HD 5xx and
skylake
Product: Drivers
Version: 2.5
Kernel Version: 4.5.2
Hardware: Intel
O
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/d9592bd8/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/05e483c1/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/1b9f4b9f/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/47875db4/attachment-0001.html>
On Sun, Apr 24, 2016 at 7:22 AM, Nils Wallménius
wrote:
> Signed-off-by: Nils Wallménius
Let me check with the powerplay team and make sure they are planning
to use these in the near future.
Alex
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h | 59
> +
> 1
On Sun, Apr 24, 2016 at 7:21 AM, Nils Wallménius
wrote:
> Signed-off-by: Nils Wallménius
Applied, thanks!
Alex
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.h
On Mon, Apr 25, 2016 at 3:31 PM, Nils Wallménius
wrote:
> Some more tables with constant data were added with the polaris support
>
> v2: missed a few
>
> Signed-off-by: Nils Wallménius
Applied. thanks!
Alex
> ---
> .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 32
> ---
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/a7c33cde/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=117111
MichaÅ Pecio changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Den 25.04.2016 15:02, skrev Ville Syrjälä:
> On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
>> Den 25.04.2016 14:39, skrev Ville Syrjälä:
>>> On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
Add some utility functions for struct drm_clip_rect.
>>> Looks l
On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
>
> Den 25.04.2016 14:39, skrev Ville Syrjälä:
> > On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
> >> Add some utility functions for struct drm_clip_rect.
> > Looks like mostly you're just duplicating the drm_rec
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/233ef7bc/attachment-0001.html>
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/f62c4b02/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/bf631032/attachment.html>
op.org/archives/dri-devel/attachments/20160425/14c02077/attachment-0001.html>
The load/unload drm_driver ops are deprecated. They should be removed as
they result in creation of devices visible to userspace even before
the drm_device is registered.
Drop these ops and use drm_dev_alloc/register and drm_dev_unregister/unref
to explicitly create and destroy the drm device in t
Move the drm_connector registration from the encoder(HDMI/DSI etc) drivers
to the msm platform driver. This will simplify the task of ensuring that
the connectors are registered only after the drm_device itself is
registered.
The connectors' destroy ops are made to use kzalloc instead of
devm_kzal
Calling the legacy gpio_free on an invalid GPIO (a GPIO numbered -1)
results in kernel warnings. This causes a lot of backtraces when
we try to unload the drm/msm module.
Call gpio_free only on valid GPIOs.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 19
Registering the drm_device using the drm_driver load/unload ops is
deprecated since it is prone to race conditions.
The second and third patches removes the usage of these ops. The first
patch prevents warnings when we try to remove the drm/msm kernel module.
Changes in v2:
- Use the recently cre
On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
> Add some utility functions for struct drm_clip_rect.
Looks like mostly you're just duplicating the drm_rect stuff. Why can't
you use what's there already?
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_rect.c |
org/archives/dri-devel/attachments/20160425/e375fc26/attachment.html>
org/archives/dri-devel/attachments/20160425/95ea0939/attachment.html>
On Mon, Apr 25, 2016 at 06:35:48AM +0200, Mario Kleiner wrote:
> Sorry for the late review, but see below...
>
> On 04/19/2016 09:52 AM, Maarten Lankhorst wrote:
> > This function is useful for gen2 intel devices which have no frame
> > counter, but need a way to determine the current vblank count
The CHIP has a composite output available muxed with the microphone in the
micro-jack plug.
Enable the composite output in its DTS.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-r8-chip.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-r8-c
The TCON, tv-encoder and display engine backends and frontends are combined
to create our display pipeline.
Add them to the R8 DTSI. It's supposed to be perfectly compatible with the
A10s and A13, but since we haven't tested it on them yet, it's safer to
just enable it on the R8. Eventually, it sh
Add the settings to support the NTSC standard.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tv.c | 45
1 file changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index ccf275a90132..b
Now that we have support for the composite output, we can start adding new
supported standards. Start with PAL, and we will add other eventually.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tv.c | 42
1 file changed, 42 insertions(+)
dif
Some Allwinner SoCs have an IP called the TV encoder that is used to output
composite and VGA signals. In such a case, we need to use the second TCON
channel.
Add support for that TV encoder.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Makefile | 2 +
drivers/gpu/drm/sun4i/sun4i_
One of the A10 display pipeline possible output is an RGB interface to
drive LCD panels directly. This is done through the first channel of the
TCON that will output our video signals directly.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Makefile | 1 +
drivers/gpu/drm/sun4i/sun
The Allwinner A10 and subsequent SoCs share the same display pipeline, with
variations in the number of controllers (1 or 2), or the presence or not of
some output (HDMI, TV, VGA) or not.
Add a driver with a limited set of features for now, and we will hopefully
support all of them eventually
Sig
The display pipeline of the Allwinner A10 is involving several loosely
coupled components.
Add a documentation for the bindings.
Signed-off-by: Maxime Ripard
---
.../bindings/display/sunxi/sun4i-drm.txt | 258 +
1 file changed, 258 insertions(+)
create mode 100644
Otherwise, building with DEBUG_FS enabled will trigger a build warning
because we're using a structure that has not been declared.
Signed-off-by: Maxime Ripard
---
include/drm/drm_fb_cma_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/
Enable the display and TCON (channel 0 and channel 1) clocks that are going
to be needed to drive the display engine, tcon and TV encoders.
Acked-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-a13.dtsi | 39 +--
arch/arm/boot/dts/su
The A10 SoCs and its relatives has a special clock controller to drive the
display engines (both frontend and backend), that have a lot in common with
the clock to drive the first TCON channel.
Add a driver to support both.
Signed-off-by: Maxime Ripard
Acked-by: Rob Herring
---
Documentation/d
Hi everyone,
The Allwinner SoCs (except for the very latest ones) all share the
same set of controllers, loosely coupled together to form the display
pipeline.
Depending on the SoC, the number of instances of the controller will
change (2 instances of each in the A10, only one in the A13, for
exa
Add MAINTAINERS entry for ARM Mali-DP driver and update the
HDLCD file matching pattern to cover only HDLCD rather than
the whole drivers/gpu/drm/arm directory.
Signed-off-by: Liviu Dudau
---
MAINTAINERS | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/
Add support for the new family of Display Processors from ARM Ltd.
This commit adds basic support for Mali DP500, DP550 and DP650
parts, with only the display engine being supported at the moment.
Cc: David Brown
Cc: Brian Starkey
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/Kconfig
Add DT bindings documentation for the Mali Display Processor. The bindings
describe the Mali DP500, DP550 and DP650 processors from ARM Ltd.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Liviu Dudau
---
.../devicetree/bindings/display/arm,ma
1 - 100 of 172 matches
Mail list logo
