Hi Emil,
On Fri, Sep 30, 2016 at 01:34:14PM +0100, Emil Velikov wrote:
> Hi Shawn,
>
> A couple of fly-by suggestions, which I hope you'll find useful :-)
Thanks for the suggestions.
> On 24 September 2016 at 15:26, Shawn Guo wrote:
>
> > +
> > + val = ((vm.hsync_len - 1) <<
On 09/29/2016 11:28 AM, Daniel Vetter wrote:
> On Tue, Sep 27, 2016 at 02:20:49PM +0200, Marek Vasut wrote:
>> On 09/27/2016 02:16 PM, Noralf Trønnes wrote:
>>>
>>> Den 27.09.2016 12:29, skrev Marek Vasut:
On 09/27/2016 09:49 AM, Daniel Vetter wrote:
> On Mon, Sep 26, 2016 at 2:59 PM,
On 09/29/2016 11:37 AM, Daniel Vetter wrote:
> On Mon, Sep 26, 2016 at 03:01:04PM +0200, Marek Vasut wrote:
>> Remove the common code from the driver and use the drm_fb_cma_setup_fence()
>> helper instead. Moveover, call the helper from prepare_fb() plane hook .
>>
>> Signed-off-by: Marek Vasut
Add .prepare_fb and .cleanup_fb plane hooks into the drm_simple_kms.
These can be used by drivers to call ie. the drm_fb_cma_setup_fence()
helper.
Signed-off-by: Marek Vasut
Cc: Noralf Trønnes
Cc: Daniel Vetter
Cc: David Airlie
---
V2: Fix the documentation style to play well with make
On 09/29/2016 11:36 AM, Daniel Vetter wrote:
> On Wed, Sep 28, 2016 at 10:08:21PM +0200, Marek Vasut wrote:
>> On 09/28/2016 03:55 PM, Lucas Stach wrote:
>>> Hi Marek,
>>>
>>> Am Montag, den 26.09.2016, 15:01 +0200 schrieb Marek Vasut:
Add new drm_fb_cma_setup_fence() helper function
On 09/29/2016 11:39 AM, Daniel Vetter wrote:
> On Mon, Sep 26, 2016 at 03:01:52PM +0200, Marek Vasut wrote:
>> Add .prepare_fb and .cleanup_fb plane hooks into the drm_simple_kms.
>> These can be used by drivers to call ie. the drm_fb_cma_setup_fence()
>> helper.
>>
>> Signed-off-by: Marek Vasut
Hi Linus,
One big regression fix for udl, along with two amdgpu fixes and two
nouveau fixes.
All seems pretty safe and useful.
Dave.
The following changes since commit 08895a8b6b06ed2323cd97a36ee40a116b3db8ed:
Linux 4.8-rc8 (2016-09-25 18:47:13 -0700)
are available in the git repository
On Thu, 2016-09-29 at 10:46 +0200, Matthias Brugger wrote:
>
> On 29/09/16 06:01, CK Hu wrote:
> > Acked-by: CK Hu
> >
> > On Thu, 2016-09-29 at 11:22 +0800, Bibby Hsieh wrote:
> >> Fix the typo: OD_RELAYMODE->OD_CFG
> >>
>
Hi, Matthias
Thanks for your reply.
> Although it is quite clear what
Hi Andrezj,
On 09/26/2016 07:10 PM, Andrzej Hajda wrote:
> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
> It is controlled via I2C bus. Its interaction with other
> devices in video pipeline is performed mainly on HW level.
> The only interaction it does on device driver level is
>
using drm_vblank_no_hw_counter() to eliminate kernel warning.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index
Hi Daniel,
Thanks for very descriptive comment.
Few comments/questions below.
On 29.09.2016 17:50, Daniel Vetter wrote:
> It's not that obvious how a driver can all race the atomic commit with
> handling the completion event. And there's unfortunately a pile of
> drivers with rather bad event
---
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 55095 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/af802c1a/attachment-0001.gz>
Hi,
On 30-09-16 05:09, Laszlo Ersek wrote:
> Hello Daniel,
>
> On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
>> We already have a fallback in place to fill out the unique from
>> dev->unique, which is set to something reasonable in drm_dev_alloc.
>>
>> Which means we only
Hi Stefan,
2016-09-29 Stefan Christ :
> Hi,
>
> this series is refactoring work suggested by Daniel Vetter in the email:
>
>https://lists.freedesktop.org/archives/dri-devel/2016-July/113237.html
>
> The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default
> implementations
On Fri, Sep 30, 2016 at 9:56 AM, Andrzej Hajda wrote:
> Hi Daniel,
>
> Thanks for very descriptive comment.
> Few comments/questions below.
>
> On 29.09.2016 17:50, Daniel Vetter wrote:
>> It's not that obvious how a driver can all race the atomic commit with
>> handling the completion event. And
On Thu, Sep 29, 2016 at 11:04 PM, Marek Vasut wrote:
> On 09/29/2016 11:28 AM, Daniel Vetter wrote:
>> On Tue, Sep 27, 2016 at 02:20:49PM +0200, Marek Vasut wrote:
>>> On 09/27/2016 02:16 PM, Noralf Trønnes wrote:
Den 27.09.2016 12:29, skrev Marek Vasut:
> On 09/27/2016 09:49 AM,
On Thu, Sep 29, 2016 at 11:44 PM, Marek Vasut wrote:
> I have the following right now, I think that's more descriptive as this
> function is not preparing the FB in any way.
>
> /**
> * drm_fb_cma_extract_and_attach_fence() - Extract fence from plane and
> attach to planestate
> * @plane: Which
Hi all
On 30 September 2016 at 04:09, Laszlo Ersek wrote:
> Hello Daniel,
>
> On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
>> We already have a fallback in place to fill out the unique from
>> dev->unique, which is set to something reasonable in drm_dev_alloc.
>>
>> Which
On Thu, Sep 29, 2016 at 11:58 PM, Marek Vasut wrote:
> + /**
> +* @prepare_fb:
> +*
> +* Optional, called by struct _plane_helper_funcs ->prepare_fb .
> +*/
You've lost the hint that people should look there for what this hook
should do. Same with
Add stub for intel_crtc_set_crc_source() and fix arguments of stub for
intel_display_crc_init().
Signed-off-by: Tomeu Vizoso
Fixes: 21165bd933ac ("drm/i915/debugfs: Move out pipe CRC code")
Fixes: 13fa0253d97a ("drm/i915: Use new CRC debugfs API")
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
It's not that obvious how a driver can all race the atomic commit with
handling the completion event. And there's unfortunately a pile of
drivers with rather bad event handling which misdirect people into the
wrong direction.
Try to remedy this by documenting everything better.
v2: Type fixes
On Fri, Sep 30, 2016 at 09:30:16AM +0530, Archit Taneja wrote:
> Hi Andrezj,
>
> On 09/26/2016 07:10 PM, Andrzej Hajda wrote:
> > SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
> > It is controlled via I2C bus. Its interaction with other
> > devices in video pipeline is performed
On Thu, Sep 29, 2016 at 10:48:37PM +0200, Stefan Christ wrote:
> The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default
> implementations for functions in struct fb_ops. A drm driver can use it
> like:
>
> static struct fb_ops drm_fbdev_cma_ops = {
> .owner =
We get 4 warnings when building kernel with W=1:
drivers/gpu/drm/radeon/si.c:7850:5: warning: no previous prototype for
'si_vce_send_vcepll_ctlreq' [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_dp_mst.c:226:21: warning: no previous prototype
for 'radeon_mst_best_encoder'
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/radeon/radeon_clocks.c:35:10: warning: no previous prototype
for 'radeon_legacy_get_engine_clock' [-Wmissing-prototypes]
drivers/gpu/drm/radeon/atombios_encoders.c:75:1: warning: no previous prototype
for
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smumgr.c:162:5: warning: no
previous prototype for 'fiji_setup_pwr_virus' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smc.c:2052:5: warning: no
previous
Hello Daniel,
On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
> We already have a fallback in place to fill out the unique from
> dev->unique, which is set to something reasonable in drm_dev_alloc.
>
> Which means we only need to have a special set_busid for pci devices,
> to
We get 4 warnings when building kernel with W=1:
drivers/gpu/drm/radeon/si.c:7850:5: warning: no previous prototype for
'si_vce_send_vcepll_ctlreq' [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_dp_mst.c:226:21: warning: no previous prototype
for 'radeon_mst_best_encoder'
We get 10 warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_clockpowergating.c:65:6:
warning: no previous prototype for 'cz_phm_is_safe_for_asic_block'
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_clockpowergating.c:71:5:
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/si.c:908:5: warning: no previous prototype for
'si_pciep_rreg' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/si.c:921:6: warning: no previous prototype for
'si_pciep_wreg' [-Wmissing-prototypes]
In fact, these
On 09/30/16 10:28, Hans de Goede wrote:
> Hi,
>
> On 30-09-16 05:09, Laszlo Ersek wrote:
>> Hello Daniel,
>>
>> On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
>>> We already have a fallback in place to fill out the unique from
>>> dev->unique, which is set to something
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/radeon/radeon_device.c:642:6: warning: no previous prototype
for 'radeon_device_is_virtual' [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:56:5: warning: no previous prototype for
'radeon_driver_unload_kms'
On 30.09.2016 12:07, Daniel Vetter wrote:
> On Fri, Sep 30, 2016 at 09:30:16AM +0530, Archit Taneja wrote:
>> Hi Andrezj,
>>
>> On 09/26/2016 07:10 PM, Andrzej Hajda wrote:
>>> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
>>> It is controlled via I2C bus. Its interaction with other
h should fix this,
please give them a try.
Regards,
Hans
-- next part --
A non-text attachment was scrubbed...
Name: 0001-xfree86-Make-adding-unclaimed-devices-as-GPU-devices.patch
Type: text/x-patch
Size: 2991 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/arc
On 30 September 2016 at 10:55, Emil Velikov wrote:
> Hi all
>
> On 30 September 2016 at 04:09, Laszlo Ersek wrote:
>> Hello Daniel,
>>
>> On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
>>> We already have a fallback in place to fill out the unique from
>>> dev->unique, which
dma_buf_export() adds a reference to the owning module to the dmabuf (to
prevent the driver from being unloaded whilst a third party still refers
to the dmabuf). However, drm_gem_prime_export() was passing its own
THIS_MODULE (i.e. drm.ko) rather than the driver. Expand the interface
so that
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/ea00ccd1/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/3f38563f/attachment.html>
Hi,
On 29 September 2016 at 16:20, Daniel Vetter wrote:
> + * 1. Driver commits new hardware state into vblank-synchronized registes.
> + * 2. A vblank happes, committing the hardware state. Also the corresponding
> + *vblank interrupt is fired off and fully processed by the interrupt
> + *
On 30 September 2016 at 11:55, Daniel Stone wrote:
> Hi,
>
> [...]
... and with that, Reviewed-by: Daniel Stone
Cheers,
Daniel, off to find more coffee
dma_buf_export() adds a reference to the owning module to the dmabuf (to
prevent the driver from being unloaded whilst a third party still refers
to the dmabuf). However, drm_gem_prime_export() was passing its own
THIS_MODULE (i.e. drm.ko) rather than the driver. Expand the interface
so that
dma_buf may live a long time, longer than the last direct user of the
driver. We already hold a reference to the owner module (that prevents
the object code from disappearing), but there is no reference to the
drm_dev - so the pointers to the driver backend themselves may vanish.
Suggested-by:
Ah! Here is patch #2. I'm indeed not deeply into the atombios stuff, so
it probably was correct to not CC me :)
Anyway patch is Acked-by: Christian König .
Cheers,
Christian.
Am 30.09.2016 um 10:14 schrieb Baoyou Xie:
> We get a few warnings when building kernel with W=1:
>
On Fri, Sep 30, 2016 at 11:58:42AM +0200, Tomeu Vizoso wrote:
> Add stub for intel_crtc_set_crc_source() and fix arguments of stub for
> intel_display_crc_init().
>
> Signed-off-by: Tomeu Vizoso
> Fixes: 21165bd933ac ("drm/i915/debugfs: Move out pipe CRC code")
> Fixes: 13fa0253d97a ("drm/i915:
This one and patch #3 are Reviewed-by: Christian König
.
Where is patch #2? That never made it into my inbox.
Regards,
Christian.
Am 30.09.2016 um 10:13 schrieb Baoyou Xie:
> We get a few warnings when building kernel with W=1:
> drivers/gpu/drm/radeon/radeon_clocks.c:35:10: warning: no
Hi,
This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.
Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the
Some boards have an entirely passive RGB to VGA bridge, based on either
DACs or resistor ladders.
Those might or might not have an i2c bus routed to the VGA connector in
order to access the screen EDIDs.
Add a bridge that doesn't do anything but expose the modes available on the
screen, either
Now that we have support for the VGA bridges using our DRM driver, enable
the display engine for the Olimex A13-Olinuxino.
Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 +++
1 file changed, 54 insertions(+)
Enable the RGB to VGA bridge driver in the defconfig
Signed-off-by: Maxime Ripard
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 2c8665cd9dc5..22ef41afc658 100644
---
Enable the VGA bridge used on the A13-Olinuxino in the sunxi defconfig
Signed-off-by: Maxime Ripard
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 714da336ec86..d830e258db59
The atomic helpers already call the drm_bridge_enable on our behalf,
there's no need to do it a second time.
Reported-by: Sean Paul
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
Both patches are Acked-by: Christian König .
Regards,
Christian.
Am 30.09.2016 um 11:58 schrieb Baoyou Xie:
> We get a few warnings when building kernel with W=1:
> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smumgr.c:162:5: warning:
> no previous prototype for 'fiji_setup_pwr_virus'
Add stub for intel_crtc_set_crc_source() and fix arguments of
intel_display_crc_init().
Signed-off-by: Tomeu Vizoso
Fixes: 21165bd933ac ("drm/i915/debugfs: Move out pipe CRC code")
Fixes: 13fa0253d97a ("drm/i915: Use new CRC debugfs API")
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
Hi Shawn,
A couple of fly-by suggestions, which I hope you'll find useful :-)
On 24 September 2016 at 15:26, Shawn Guo wrote:
> +
> + val = ((vm.hsync_len - 1) << SYNC_WIDE_SHIFT) & SYNC_WIDE_MASK;
To save some writing/minimise the chances to typos getting, in you can
have
org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 55095 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/20cde162/attachment-0001.gz>
Why not just use dev->fops->owner instead of changing the interface
everywhere?
Regards,
Christian.
Am 30.09.2016 um 13:44 schrieb Chris Wilson:
> dma_buf_export() adds a reference to the owning module to the dmabuf (to
> prevent the driver from being unloaded whilst a third party still refers
Due to some potential tweaks for the da850 LCDC (for example: the
required memory bandwith settings) we need a separate compatible
for the IP present on the da850 boards.
Suggested-by: Sekhar Nori
Signed-off-by: Bartosz Golaszewski
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 +
1 file changed,
On Fri, Sep 30, 2016 at 02:20:30PM +0200, Tomeu Vizoso wrote:
> Add stub for intel_crtc_set_crc_source() and fix arguments of
> intel_display_crc_init().
>
> Signed-off-by: Tomeu Vizoso
> Fixes: 21165bd933ac ("drm/i915/debugfs: Move out pipe CRC code")
> Fixes: 13fa0253d97a ("drm/i915: Use new
On Fri, 30 Sep 2016, Chris Wilson wrote:
> On Fri, Sep 30, 2016 at 02:20:30PM +0200, Tomeu Vizoso wrote:
>> Add stub for intel_crtc_set_crc_source() and fix arguments of
>> intel_display_crc_init().
>>
>> Signed-off-by: Tomeu Vizoso
>> Fixes: 21165bd933ac ("drm/i915/debugfs: Move out pipe CRC
Due to some potential tweaks for the da850 LCDC (for example: the
required memory bandwith settings) we need a separate compatible
for the IP present on the da850 boards.
Suggested-by: Sekhar Nori
Signed-off-by: Bartosz Golaszewski
---
v1 -> v2:
- added the new compatible to the bindings
2016-09-30 15:00 GMT+02:00 Bartosz Golaszewski :
> Due to some potential tweaks for the da850 LCDC (for example: the
> required memory bandwith settings) we need a separate compatible
> for the IP present on the da850 boards.
>
> Suggested-by: Sekhar Nori
> Signed-off-by: Bartosz Golaszewski
>
On Fri, Sep 30, 2016 at 3:19 PM, Jani Nikula
wrote:
> On Fri, 30 Sep 2016, Chris Wilson wrote:
>> On Fri, Sep 30, 2016 at 02:20:30PM +0200, Tomeu Vizoso wrote:
>>> Add stub for intel_crtc_set_crc_source() and fix arguments of
>>> intel_display_crc_init().
>>>
>>> Signed-off-by: Tomeu Vizoso
>>>
dma_buf_export() adds a reference to the owning module to the dmabuf (to
prevent the driver from being unloaded whilst a third party still refers
to the dmabuf). However, drm_gem_prime_export() was passing its own
THIS_MODULE (i.e. drm.ko) rather than the driver. Extract the right
owner from the
In order to keep the dmabuf alive whilst the mmap is, we need to hold a
reference to the dmabuf and not the backing object. This is important as
the dmabuf not only keeps the object alive, but also the device so that
dmabuf = vgem_create_dmabuf();
ptr = mmap(... dmabuf ...);
dma_buf may live a long time, longer than the last direct user of the
driver. We already hold a reference to the owner module (that prevents
the object code from disappearing), but there is no reference to the
drm_dev - so the pointers to the driver backend themselves may vanish.
Testcase:
> -Original Message-
> From: Baoyou Xie [mailto:baoyou.xie at linaro.org]
> Sent: Friday, September 30, 2016 4:15 AM
> To: Deucher, Alexander; Koenig, Christian; airlied at linux.ie
> Cc: dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org;
> arnd at arndb.de; baoyou.xie at
Am 30.09.2016 um 15:59 schrieb Chris Wilson:
> dma_buf_export() adds a reference to the owning module to the dmabuf (to
> prevent the driver from being unloaded whilst a third party still refers
> to the dmabuf). However, drm_gem_prime_export() was passing its own
> THIS_MODULE (i.e. drm.ko)
https://bugs.freedesktop.org/show_bug.cgi?id=97986
Bug ID: 97986
Summary: sony vaio with ati graphics flashing flikering
Product: Mesa
Version: 12.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Our planes cannot be set at negative coordinates. Make sure we reject such
configuration.
Reported-by: Boris Brezillon
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_layer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c
--- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/8aa0eb9b/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/861d3034/attachment.html>
Subject: [PATCH v5 0/5] drm: Add Support for Passive RGB to VGA bridges
Hi,
This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.
Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any
The atomic helpers already call the drm_bridge_enable on our behalf,
there's no need to do it a second time.
Reported-by: Sean Paul
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
Some boards have an entirely passive RGB to VGA bridge, based on either
DACs or resistor ladders.
Those might or might not have an i2c bus routed to the VGA connector in
order to access the screen EDIDs.
Add a bridge that doesn't do anything but expose the modes available on the
screen, either
Enable the RGB to VGA bridge driver in the defconfig
Signed-off-by: Maxime Ripard
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 2c8665cd9dc5..22ef41afc658 100644
---
Enable the VGA bridge used on the A13-Olinuxino in the sunxi defconfig
Signed-off-by: Maxime Ripard
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 714da336ec86..d830e258db59
Now that we have support for the VGA bridges using our DRM driver, enable
the display engine for the Olimex A13-Olinuxino.
Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 +++
1 file changed, 54 insertions(+)
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/b2218154/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/eb809b0d/attachment.html>
ou 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/20160930/332fc9f8/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/f078a8a5/attachment.html>
ttachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/235d14d8/attachment-0001.html>
Hi,
On 30-09-16 16:51, Laszlo Ersek wrote:
> On 09/30/16 12:35, Hans de Goede wrote:
>
>> Attached are 2 patches against the xserver which should fix this,
>> please give them a try.
>
> Sorry about the delay.
>
> The patches don't seem to fix the issue for me. Please see the Xorg log
> attached.
vel/attachments/20160930/e246dcb1/attachment.html>
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/11d405d8/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/b3541e16/attachment.html>
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/7cdf37e2/attachment.html>
-
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/20160930/8a10f495/attachment.html>
On Fri, 30 Sep 2016 16:33:20 +0200
Maxime Ripard wrote:
> Our planes cannot be set at negative coordinates. Make sure we reject such
> configuration.
>
> Reported-by: Boris Brezillon
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun4i_layer.c | 3 +++
> 1 file changed, 3
On Fri, Sep 30, 2016 at 06:08:26PM +0200, Boris Brezillon wrote:
> On Fri, 30 Sep 2016 16:33:20 +0200
> Maxime Ripard wrote:
>
> > Our planes cannot be set at negative coordinates. Make sure we reject such
> > configuration.
> >
> > Reported-by: Boris Brezillon
> > Signed-off-by: Maxime Ripard
> -Original Message-
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Friday, September 30, 2016 12:21 PM
> To: Deucher, Alexander; Koenig, Christian
> Cc: Arnd Bergmann; David Airlie; Zhou, Jammy; Zhu, Rex; dri-
> devel at lists.freedesktop.org; linux-kernel at vger.kernel.org
>
Using the newly exported amd_set_clockgating_by_smu function in the main amdgpu
driver
means that we can no longer build the driver without also enabling the powerplay
component, otherwise we get this link error:
ERROR: "amd_set_clockgating_by_smu" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
On 2016-09-28 01:24, Meng Yi wrote:
> Gamma correction is optional and can be used to adjust the color
> output values to match the gamut of a particular TFT LCD panel
>
> Split the DCU regs into "regs", "palette", "gamma" and "cursor".
> Create a second regmap for gamma memory space using little
On Fri, 30 Sep 2016 19:22:11 +0300
Ville Syrjälä wrote:
> On Fri, Sep 30, 2016 at 06:08:26PM +0200, Boris Brezillon wrote:
> > On Fri, 30 Sep 2016 16:33:20 +0200
> > Maxime Ripard wrote:
> >
> > > Our planes cannot be set at negative coordinates. Make sure we reject such
> > >
Hi,
On 30-09-16 17:33, Laszlo Ersek wrote:
> On 09/30/16 16:59, Hans de Goede wrote:
>> Hi,
>>
>> On 30-09-16 16:51, Laszlo Ersek wrote:
>>> On 09/30/16 12:35, Hans de Goede wrote:
>>>
Attached are 2 patches against the xserver which should fix this,
please give them a try.
>>>
>>>
On Fri, Sep 30, 2016 at 7:52 AM, Christian König
wrote:
> This one and patch #3 are Reviewed-by: Christian König
> .
>
Applied 1 and 3, thanks!
Alex
> Where is patch #2? That never made it into my inbox.
>
> Regards,
> Christian.
>
>
> Am 30.09.2016 um 10:13 schrieb Baoyou Xie:
>>
>> We get
On Fri, Sep 30, 2016 at 8:16 AM, Christian König
wrote:
> Both patches are Acked-by: Christian König .
Applied patch 1. I'd like to get Rex's ack on patch 2 before applying it.
Alex
>
> Regards,
> Christian.
>
>
> Am 30.09.2016 um 11:58 schrieb Baoyou Xie:
>>
>> We get a few warnings when
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/5d7bdf7e/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160930/a1a76c82/attachment.html>
v2: merge codepaths where possible
--
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/20160930/166fe652/attachment.html>
1 - 100 of 112 matches
Mail list logo
