Hi Andrzej,
2016-04-05 20:07 GMT+09:00 Andrzej Hajda :
> Hi Inki,
>
> On 04/05/2016 10:27 AM, Inki Dae wrote:
>> This patch cleans up interface type relevant codes.
>>
>> Trigger mode is determinded only by i80 mode, which isn't
>> related to Display types - HDMI or Display controller.
>> So
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160405/01c86b5f/attachment-0001.html>
nts/20160405/70b58021/attachment.html>
-devel/attachments/20160405/1de7ebf4/attachment.html>
was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160405/653b3aa9/attachment.html>
Hi Bastien,
On Tue, Apr 05, 2016 at 06:59:40PM +0200, Bastien Nocera wrote:
> I tested the runtime patches for Radeon on top of 4.6.0-rc2, and
> writing DIGD failed. I also saw a number of messages with the
> vga_switcheroo core in the kernel trying to switch GPUs but failed
> because "client 1"
Hi Jose,
On Tuesday 05 Apr 2016 12:00:54 Jose Abreu wrote:
> On 04-04-2016 22:41, Laurent Pinchart wrote:
> > On Monday 04 Apr 2016 10:05:39 Jose Abreu wrote:
> >> On 01-04-2016 18:10, Laurent Pinchart wrote:
> >>> On Monday 28 Mar 2016 15:36:09 Jose Abreu wrote:
> This patch adds audio
On Mon, 2016-03-14 at 13:41 +0100, Lukas Wunner wrote:
>
> > So I'd push DIGD to the switch sysfs entry on boot. But I'm
> > guessing
> > that won't turn off the other output we're not interested in.
> IGD and DIGD switch to the integrated GPU and also turn off the
> discrete
> GPU. However if
Hi Vineet,
> From: Alexey Brodkin [abrodkin at synopsys.com]
> Sent: Monday, March 28, 2016 2:36 PM
> To: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org; Alexey Brodkin; Vineet Gupta;
> linux-snps-arc at lists.infradead.org
> Subject: [PATCH 4/5 v5] arc: Add our own
There is no need to unmask all interrupts at I2S start. This
can cause performance issues in slower platforms.
Unmask only the interrupts for the used channels.
Signed-off-by: Jose Abreu
---
Changes v2 -> v3:
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for
This patch adds audio support for the ADV7511 HDMI transmitter
using ALSA SoC.
The code was ported from Analog Devices linux tree from
commit 1770c4a1e32b ("Merge remote-tracking branch
'xilinx/master' into xcomm_zynq"), which is available at:
- https://github.com/analogdevicesinc/linux/
Main file of adv7511 driver was renamed from adv7511.c
to adv7511_core.c and moved to separate folder in order
to prepare the adding of audio support.
Struct adv7511 was moved to adv7511.h and functions
adv7511_packet_enable() and adv7511_packet_disable()
were made public also to prepare the
ARC AXS10x platforms consist of a mainboard with several peripherals.
One of those peripherals is an HDMI output port controlled by the ADV7511
transmitter.
This patch set adds audio for the ADV7511 transmitter and I2S audio for
the AXS10x platform.
Changes v2 -> v3:
* Removed pll_config
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160405/9142ee7f/attachment.html>
This patch cleans up interface type relevant codes.
Trigger mode is determinded only by i80 mode, which isn't
related to Display types - HDMI or Display controller.
So this patch makes the trigger mode to be set only in case of
i80 mode.
Signed-off-by: Inki Dae
---
This patch adds HW trigger support on i80 mode.
Until now, Exynos DRM only supported SW trigger which was set
SWTRGCMD bit of TRIGCON register by CPU to transfer scanout
buffer to Display bus device or panel.
With this patch, the transmission to Display bus device or
panel will be initiated by
This patch cleans up wait_for_vblank relevant codes.
wait_for_vblank callback isn't used anymore in Exynos drm driver
so it removes relevant codes. However, display controllers -
FIMD and DECON - still use this function driver internally
to ensure shadow registers to be updated, which resolves
This patch series adds HW trigger on i80 mode, including one cleanup patch.
Until now, Exynos drm driver used SW trigger in case of i80 panel
and trigger mode setting of DECON HDMI was not reasonable because
the trigger mode is related to only i80 mode so also corrects it.
With this patch
Hi,
On 03/31/2016 12:23 AM, Mark Brown wrote:
> The voltage changing code in this driver is broken and should be
> removed. The driver sets a single, exact voltage on probe. Unless
> there is a very good reason for this (which should be documented in
> comments) constraints like this need to be
Transitional drivers might access the NULL pointer plane->state in
drm_helper_crtc_mode_set_base(), which causes NULL pointer dereference.
So, let's reset it before handing it over to those drivers.
commit e4f31ad2b713 ("drm: reset empty state in transitional helpers")
did the same thing for other
On 4 April 2016 at 23:41, Rob Clark wrote:
> On Mon, Apr 4, 2016 at 5:02 AM, Maarten Lankhorst
> wrote:
>> Op 31-03-16 om 22:23 schreef Rob Clark:
>>> In the atomic modesetting path, each driver simply wants to grab a ref
>>> to the exclusive fence from a reservation object to store in the
On 4 April 2016 at 17:44, Daniel Stone wrote:
> Hi Tomeu,
>
> On 4 April 2016 at 14:55, Tomeu Vizoso wrote:
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> index 3b8f652698f8..8305bbd2a4d7 100644
>> ---
On 05.04.2016 13:07, Boszormenyi Zoltan wrote:
> 2016-04-05 05:40 keltezéssel, Michel Dänzer Ãrta:
>> On 05.04.2016 00:25, Boszormenyi Zoltan wrote:
>>>
>>> The application is Chromium in kiosk mode. The problem is that
>>> sometimes the screen stays black after KMS kicks in.
>> So the problem
Hi,
On 5 April 2016 at 15:04, Rob Clark wrote:
> On Tue, Apr 5, 2016 at 8:57 AM, Daniel Stone wrote:
>> I've been assuming that it would have to be write-only; I don't
>> believe there would be any meaningful usecases for read. Do you have
>> any in mind, or is it just a symmetry/cleanliness
This is used when reading Display Control capability Registers on the sink
device.
cc: dri-devel at lists.freedesktop.org
Signed-off-by: Yetunde Adebisi
Reviewed-by: Jani Nikula
---
include/drm/drm_dp_helper.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_dp_helper.h
arm_iommu_attach_device() takes its own reference to the mapping we give
it. Since we do not keep a reference to the mapping ourselves, we must
release it before returning.
Also fix the error path, which fails to release the mapping if it has
called arm_iommu_detach_device() since that clears
The call to arm_iommu_detach_device() on the previous line sets
dev->archdata.mapping to NULL so this call is always a no-op.
Signed-off-by: John Keeping
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git
This is used when reading Display Control capability Registers on the sink
device.
cc: Jani Nikula
cc: dri-devel at lists.freedesktop.org
Signed-off-by: Yetunde Adebisi
---
include/drm/drm_dp_helper.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_dp_helper.h
https://bugzilla.kernel.org/show_bug.cgi?id=115911
--- Comment #4 from Jan Prunk ---
I am not in a position to help you with my own custom kernel compiling
however...
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=115911
--- Comment #3 from Jan Prunk ---
Hi !
The bug happens with this kernel (4.5.0):
# apt-cache show linux-image-4.5.0-gnu
Package: linux-image-4.5.0-gnu
Source: linux-4.5.0-gnu
Version: 4.5.0-gnu-1.0
Architecture: amd64
Maintainer: Jason Self
On Tue, Apr 05, 2016 at 01:57:36PM +0100, Chris Wilson wrote:
> I have instances where I want to use drm_malloc_ab() but with a custom
> gfp mask. And with those, where I want a temporary allocation, I want to
> try a high-order kmalloc() before using a vmalloc().
>
> So refactor my usage into
https://bugzilla.kernel.org/show_bug.cgi?id=115911
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2
I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want to
try a high-order kmalloc() before using a vmalloc().
So refactor my usage into drm_malloc_gfp().
Signed-off-by: Chris Wilson
Cc: dri-devel at
Hi,
On 5 April 2016 at 13:36, Rob Clark wrote:
> ok, so I've been slacking on writing up the reasons that I don't like
> the idea of using a property for fd's (including fence fd's).. I did
> at one point assume we'd use properties for fence fd's, but that idea
> falls apart pretty quickly when
On Wed, 30 Mar 2016, Ville Syrjälä wrote:
> On Sat, Mar 26, 2016 at 01:18:38PM +, Paul Parsons wrote:
>> The EDID 1.4 specification section 3.10.3.9 defines an Established Timings
>> III
>> descriptor (tag #F7h). The parsing of this descriptor by drm_est3_modes() is
>> off by one byte: the
On Mon, 04 Apr 2016, Ville Syrjälä wrote:
> On Sat, Apr 02, 2016 at 11:08:06AM +0100, Paul Parsons wrote:
>> Three of the VESA DMT timings in edid_est_modes[] are slightly off.
>> 1. 640x480 at 72Hz vsync_end should be 492, not 491.
>> 2. 640x480 at 60Hz clock should be 25175, not 25200.
>> 3.
On Tue, 05 Apr 2016, Ville Syrjälä wrote:
> On Mon, Apr 04, 2016 at 08:36:34PM +0100, Paul Parsons wrote:
>> One of the VESA DMT timings in drm_dmt_modes[] is slightly off.
>> 1024x768 at 43Hz (interlaced) vsync_end should be 776, not 772.
>> This brings it into line with the identical timings
Add some additional information (input vs. output port, sink associated
with VC, peer device type, max number of VCs supported) and ensure that
any embedded '\0' characters in a branch device's devid string are not
written to debugfs.
cc: dri-devel at lists.freedesktop.org
Signed-off-by: Jim
In order to include monitor name information in debugfs
output we needed to add a function that would extract the
monitor name from the EDID, and that function needed to
reside in the file where the rest of the EDID helper
functions are implemented.
cc: dri-devel at lists.freedesktop.org
Hi Inki,
On 04/05/2016 10:27 AM, Inki Dae wrote:
> This patch cleans up interface type relevant codes.
>
> Trigger mode is determinded only by i80 mode, which isn't
> related to Display types - HDMI or Display controller.
> So this patch makes the trigger mode to be set only in case of
> i80
On 05.04.2016 00:25, Boszormenyi Zoltan wrote:
>
> we have a bunch of Zotac ZBOX NANO-AQ01 with this APU:
>
> [2.234372] [drm] initializing kernel modesetting (KABINI
> 0x1002:0x9832 0x1002:0x0123).
>
> For our application, we force 1440x900 resolution via this modeline
> ("cvt 1440 900"):
On Mon, Apr 04, 2016 at 08:36:34PM +0100, Paul Parsons wrote:
> One of the VESA DMT timings in drm_dmt_modes[] is slightly off.
> 1024x768 at 43Hz (interlaced) vsync_end should be 776, not 772.
> This brings it into line with the identical timings in edid_est_modes[].
>
> Signed-off-by: Paul
On 04/04/2016 10:58 PM, Ville Syrjälä wrote:
>
>> Since this VBT mode is probably junk anyway, I commented out the
>> if-statement that selects it (in intel_lvds.c), so that the code will
>> pick the mode as set by BIOS. The result is much better, I actually get
>> proper looking output! X also
https://bugzilla.kernel.org/show_bug.cgi?id=115911
Jani Nikula changed:
What|Removed |Added
CC|intel-gfx-bugs at lists.freede |
|sktop.org
Hi Laurent,
On 04-04-2016 22:41, Laurent Pinchart wrote:
> Hi Jose,
>
> On Monday 04 Apr 2016 10:05:39 Jose Abreu wrote:
>> On 01-04-2016 18:10, Laurent Pinchart wrote:
>>> On Monday 28 Mar 2016 15:36:09 Jose Abreu wrote:
This patch adds audio support for the ADV7511 HDMI transmitter
ure.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160405/db45e7c7/attachment.sig>
(Adding Jani again, who got dropped for some reason)
On 1 April 2016 at 16:50, Ezequiel Garcia
wrote:
> On 01 Apr 06:46 PM, Ville Syrjälä wrote:
>> On Fri, Apr 01, 2016 at 12:38:11PM -0300, Ezequiel Garcia wrote:
>> > El abr. 1, 2016 11:47 AM, "Ville Syrjälä" > > linux.intel.com>
>> >
On Tue, Apr 5, 2016 at 10:19 AM, Daniel Stone wrote:
>
>> hmm, I'm assuming that the in/out arrays are handled in
>> drm_mode_atomic_ioctl() and the drivers never see 'em..
>
> True, but it complicates the (already not hugely straightforward)
> parsing that the ioctl has to do. It also makes
Hi,
Any comment on this?
Gustavo
2016-03-22 Gustavo Padovan :
> From: Gustavo Padovan
>
> virtio_gpu was failing to send vblank events when using the atomic IOCTL
> with the DRM_MODE_PAGE_FLIP_EVENT flag set. This patch fixes each and
> enables atomic pageflips updates.
>
>
Hi Greg,
Any comments on this?
Thanks,
Gustavo
2016-03-18 Gustavo Padovan :
> From: Gustavo Padovan
>
> Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid
> future API breaks and optimize buffer allocation.
>
> Now num_fences can be filled by the caller to
Hi David,
This v2 pull request just fixed the module compiled failed problem which
pointed by Guenter,
detail relate to [1]
Thanks,
- Yakir
[1]: https://lkml.org/lkml/2016/3/30/762
The following changes since commit 4604202ca8d2a5e33b4bca0812b5d92975ed1bd8:
Merge branch 'drm-next-4.6'
On Mon, Apr 4, 2016 at 3:24 AM, David Binderman wrote:
> Hello there,
>
> 1.
>
> linux-4.6-rc2/drivers/gpu/drm/radeon/si_dpm.c:3788]: (style) Condition
> 'td==0' is always true
>
> Source code is
>
> enum r600_td td = R600_TD_DFLT;
>
> for (i = 0; i < R600_PM_NUMBER_OF_TC; i++)
>
On 04/01/2016 12:02 AM, Doug Anderson wrote:
> Hi,
>
> On Thu, Mar 31, 2016 at 2:56 AM, Thierry Reding wrote:
>> Ugh... most of these functions shouldn't be there in the first place. We
>> have helpers in the core that already do this. Most of the functionality
>> is duplicated in this driver.
Hi Daniel,
On 03/31/2016 06:15 PM, Daniel Vetter wrote:
> On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:
>> Hi all,
>>
>>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
>> share the same IP, so a lot of parts can be re-used. I split the common
>> code into
On Tue, Apr 5, 2016 at 8:57 AM, Daniel Stone wrote:
> Hi,
>
> On 5 April 2016 at 13:36, Rob Clark wrote:
>> ok, so I've been slacking on writing up the reasons that I don't like
>> the idea of using a property for fd's (including fence fd's).. I did
>> at one point assume we'd use properties for
Hi Guenter
On 03/31/2016 04:32 AM, Guenter Roeck wrote:
> Hi,
>
> On Mon, Feb 15, 2016 at 07:09:36PM +0800, Yakir Yang wrote:
>> Split the dp core driver from exynos directory to bridge directory,
>> and rename the core driver to analogix_dp_*, rename the platform
>> code to exynos_dp.
>>
>>
anything by
sending it on.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160405/0534bdbc/attachment.sig>
On 2016å¹´03æ31æ¥ 04:03, Emil Velikov wrote:
> On 29 March 2016 at 14:13, Emil Velikov wrote:
>> On 28 March 2016 at 23:13, Heiko Stübner wrote:
>>
>>> I have the feeling we're going quite a bit off-topic right now :-) .
>>> The binary-driver-crazyness, hasn't really anything to do with
On Wed, Mar 23, 2016 at 2:47 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> FENCE_FD can now be set by the user during an atomic IOCTL, it
> will be used by atomic_commit to wait until the sync_file is signalled,
> i.e., the framebuffer is ready for scanout.
ok, so I've been slacking on
all.
--
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/20160405/a3cc92f3/attachment.html>
2016-04-05 05:40 keltezéssel, Michel Dänzer Ãrta:
> On 05.04.2016 00:25, Boszormenyi Zoltan wrote:
>> we have a bunch of Zotac ZBOX NANO-AQ01 with this APU:
>>
>> [2.234372] [drm] initializing kernel modesetting (KABINI
>> 0x1002:0x9832 0x1002:0x0123).
>>
>> For our application, we force
https://bugzilla.kernel.org/show_bug.cgi?id=64721
--- Comment #7 from stanleyk ---
Well 2 years later things have changed. That set of HW died and I got a 2nd
hand Acer box with an Intel 2 core chip. it's a bit old so I upped the RAM to
4gig DDR2 and put in my HD6450 and it works really good,
Hi Jose,
On Monday 04 Apr 2016 10:05:39 Jose Abreu wrote:
> On 01-04-2016 18:10, Laurent Pinchart wrote:
> > On Monday 28 Mar 2016 15:36:09 Jose Abreu wrote:
> >> This patch adds audio support for the ADV7511 HDMI transmitter
> >> using ALSA SoC.
> >>
> >> The code was ported from Analog Devices
63 matches
Mail list logo
