Hi Andrzej,
2015ë
10ì 20ì¼ 18:22ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> DECON-TV IP is responsible for generating video stream which is transferred
> to HDMI IP. It is almost fully compatible with DECON IP.
>
> The patch is based on initial work of Hyungwon Hwang.
>
> Signed-off-by: Andrzej Ha
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/20151023/e50fcf15/attachment.html>
Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.
But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.
Reviewed-by: Krzyszt
link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.
Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7G
Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- Resequence
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.
Beside the new analogix_dp driver would export four hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_detect()" and "analogix_dp
In order to move exynos dp code to bridge directory,
we need to convert driver drm bridge mode first. As
dp driver already have a ptn3460 bridge, so we need
to move ptn bridge to the next bridge of dp bridge.
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
C
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/188eb5db/attachment.html>
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 bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
control
readl((u32 __iomem *)vc4->hvs->dlist + 0),
>> +readl((u32 __iomem *)vc4->hvs->dlist + 1),
>> +readl((u32 __iomem *)vc4->hvs->dlist + 2),
>> + readl((u32 __iomem *)vc4->hvs->dlist + 3));
>
> Looks like you lost the +i here, no?
Indeed. Thanks!
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/cf15c1f0/attachment-0001.sig>
From: Maruthi Srinivas Bayyavarapu
DW i2s controller's master/slave config can be read from a
read-only register. Machine driver can try to set a master/slave
format on cpu-dai using 'set_fmt' of dai ops. A check is added to
verify codec is master when dwc is slave and vice-versa.
Signed-off-by:
On Thu, Oct 22, 2015 at 10:56 AM, Mark Brown wrote:
> On Thu, Oct 08, 2015 at 12:12:34PM -0400, Alex Deucher wrote:
>> From: Maruthi Srinivas Bayyavarapu
>>
>> DW i2s controller's master/slave config can be read from a
>> read-only register. Machine driver can try to set a master/slave
>> format
Hi Dave,
More amdgpu and radeon stuff for drm-next. Stoney support is the big change.
The rest is just bug fixes and code cleanups. The Stoney stuff is pretty
low impact with respect to existing chips.
The following changes since commit 2fcef6ec87a044221fc3c2f16873f7c02b9ae991:
drm/amdgpu: f
On Fri, Oct 23, 2015 at 3:31 PM, Mark Brown wrote:
> On Sat, Oct 24, 2015 at 12:20:09AM +0530, maruthi srinivas wrote:
>> On Thu, Oct 22, 2015 at 9:44 PM, Mark Brown wrote:
>> > On Thu, Oct 08, 2015 at 12:12:40PM -0400, Alex Deucher wrote:
>
>> >> +/* ACP DMA irq handler routine for playback, cap
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/c480719d/attachment.html>
On 10/23/2015 01:55 PM, Inki Dae wrote:
> Hi Andrzej,
>
>
> 2015ë
10ì 20ì¼ 18:22ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>> DECON-TV IP is responsible for generating video stream which is transferred
>> to HDMI IP. It is almost fully compatible with DECON IP.
>>
>> The patch is based on initial wor
On 10/22/2015 09:26 PM, Greg Kroah-Hartman wrote:
> On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote:
>> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>>
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
But that's moot currently because Greg believes that
Hi,
On 22 October 2015 at 21:25, Daniel Vetter wrote:
> Maarten Lankhorst had patches to do that for i915, but they just didn't go
> anywhere since i915 gem locking is a bit ... antique. But if your goal is
> to only fix up the page_flip path, and only for i915 as the display
> driver, then the o
-target-feature -pclmul -target-feature -avx512f -target-feature -f16c
-target-feature +ssse3 -target-feature +mmx -target-feature +cmov
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
On Fri, Oct 23, 2015 at 11:32:35AM +0100, Eric Anholt wrote:
> We would scan out the memory around them if an upscale was attempted,
> and would just scan out incorrectly for downscaling.
>
> Signed-off-by: Eric Anholt
> ---
>
> It looks like, while modetest only wants to set scaling on overlay
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 31 ---
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Reviewed-by: Christian König
Reviewed-by: Jammy Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 34 +-
1 file changed,
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Reviewed-by: Christian König
Reviewed-by: Jammy Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 36 ++
1 file changed,
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Reviewed-by: Christian König
Reviewed-by: Jammy Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 38 +++
1 file changed,
Hi Dave,
Two regression fixes and a memory leak fix for amdgpu and radeon.
The following changes since commit c50f13f911b90a722308bffbf26187ff3890aa1e:
Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux
into drm-fixes (2015-10-22 10:24:55 +1000)
are available in the gi
On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird wrote:
> On 10/22/2015 11:53 AM, Frank Rowand wrote:
>> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>>
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
But that's moot currently because Greg believes that the time spent
>>
Hi
On Thu, Oct 22, 2015 at 7:11 PM, Daniel Vetter
wrote:
> It's racy, creating mmap offsets is a slowpath, so better to remove it
> to avoid drivers doing broken things.
>
> The only user is i915, and it's ok there because everything (well
> almost) is protected by dev->struct_mutex in i915-gem.
These were all touch-tested with modetest.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_plane.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 887f3ca..b31dfce 100644
--- a/drivers/gpu/drm/vc
We would scan out the memory around them if an upscale was attempted,
and would just scan out incorrectly for downscaling.
Signed-off-by: Eric Anholt
---
It looks like, while modetest only wants to set scaling on overlay
planes, one could do so on our primary/cursor planes if the fd was in
unive
Caught by the kbuild test robot.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_crtc.c | 3 ++-
drivers/gpu/drm/vc4/vc4_hvs.c | 8
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index a3a77dd..32c03
From: Julia Lawall
Connector cannot be null because it is a list entry, ie accessed at an
offset from the positions of the list structure pointers themselves.
Generated by: scripts/coccinelle/iterators/itnull.cocci
Signed-off-by: Fengguang Wu
Signed-off-by: Julia Lawall
Signed-off-by: Eric An
From: Julia Lawall
drivers/gpu/drm/vc4/vc4_drv.c:248:3-8: No need to set .owner here. The core
will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Fengguang Wu
Signed-off-by: Julia Lawal
From: kbuild test robot
Signed-off-by: Fengguang Wu
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_plane.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index cdd8b10..2db5092 100644
--- a/d
Merging vc4 to drm-next got a few automatic sparse and coccinelle
warning reports generated. The first 3 patches come from the
maintainers of those systems (thanks!), and the last 3 are fixes I've
come up with in the last few days.
This removes ones which aren't used 0x190b, 192a), and adds some new ones. I
kept the original names where possible.
Cc: Kristian Høgsberg
Cc: Damien Lespiau
Signed-off-by: Ben Widawsky
---
intel/intel_chipset.h | 46 ++
1 file changed, 26 insertion
Cc: Kristian Høgsberg
Cc: Damien Lespiau
Signed-off-by: Ben Widawsky
---
intel/intel_chipset.h | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 253ea71..6c8dc73 100644
--- a/intel/intel_chipset.h
+++ b/intel/in
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/27b4efcc/attachment-0001.html>
tch that should fix this.
--
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/20151023/a94544ca/attachment.html>
|
|sktop.org |
--
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/d1a3f1ff/attachment.html>
>hvs->dlist + 2),
> +readl((u32 __iomem *)vc4->hvs->dlist + 3));
Looks like you lost the +i here, no?
> }
> }
>
> --
> 2.6.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/1aaabece/attachment-0001.html>
Hi Matt,
[auto build test WARNING on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Matt-Roper/CRTC-background-color-support-for-i915/20151023-082852
reproduce: make htmldocs
All war
Hi Matt,
[auto build test WARNING on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Matt-Roper/CRTC-background-color-support-for-i915/20151023-082852
config: x86_64-rhel (attach
On 10/22/2015 11:53 AM, Frank Rowand wrote:
> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>
>>
>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>> But that's moot currently because Greg believes that the time spent
>>> probing devices at boot time could be reduced enough so
Hi Matt,
[auto build test WARNING on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Matt-Roper/CRTC-background-color-support-for-i915/20151023-082852
config: x86_64-randconfig-x005-102
you proposed is good for addressing
that.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/e3085cff/attachment-0001.sig>
On 23 October 2015 at 05:58, Daniel Vetter wrote:
> On Thu, Oct 22, 2015 at 12:40:23PM -0500, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 4:53 AM, Eric Anholt wrote:
>> > Dave suggested it was time to just send a pull request on the driver, so
>> > here goes:
>>
>> Why is that when the binding
On Fri, Oct 16, 2015 at 3:12 PM, Philipp Zabel
wrote:
> From: CK Hu
>
> Add device tree binding documentation for the display subsystem in
> Mediatek MT8173 SoCs. The display function block nodes are grouped
> under a display-subsystem node.
>
> Signed-off-by: CK Hu
> Signed-off-by: Philipp Zab
On Fri, Oct 16, 2015 at 3:12 PM, Philipp Zabel
wrote:
> Add the device tree binding documentation for Mediatek HDMI,
> HDMI PHY and HDMI DDC devices.
>
> Signed-off-by: Philipp Zabel
> ---
> Changes since v3:
> - Split CEC block into a separate node, move the hotplug interrupt there
> - Remove
Hi Daniel,
[auto build test WARNING on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Update-GEM-refcounting-docs/20151023-011317
config: x86_64-randconfig-s1-102
Hi Daniel,
[auto build test ERROR on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Update-GEM-refcounting-docs/20151023-011317
config: i386-randconfig-s1-201542 (att
System RAM to SRAM)
> + * In this case, it will be runtime->start_threshold
> + * (2 ALSA periods) of transfer. Rendering starts after this
> + * threshold is met.
> + */
> + dma_ch_sts = acp_reg_read(acp_mmio, mmACP_DMA_CH_STS);
> + udelay(20);
> + } while (dma_ch_sts & channel_mask);
This will hang hard if the hardware fails to respond for some reason,
please have a timeout. A cpu_relax() would also be friendly.
> +#define DISABLE 0
> +#define ENABLE 1
Please don't do this :(
> +#define STATUS_SUCCESS 0
> +#define STATUS_UNSUCCESSFUL -1
Please use normal Linux error codes.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/a6917f9c/attachment.sig>
--- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/2b08108f/attachment.sig>
On Thu, Oct 22, 2015 at 11:31 PM, Alexander Goins wrote:
>>This looks really strange - you force-complete the fence already attached
>>(which might be from any driver attached to this dma-buf)?
>>The creator of the fence is supposed to complete it when whatever async
>>operation that is schedule
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20151023/efe583ea/attachment-0001.html>
are...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/4a18b5ed/attachment.sig>
n/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/430d83d2/attachment.sig>
56 matches
Mail list logo
