On 01/23/2017 04:03 PM, Andrzej Hajda wrote:
On 23.01.2017 09:31, Archit Taneja wrote:
On 01/20/2017 01:08 PM, Andrzej Hajda wrote:
Due to asynchronous nature of MHL flow of execution is dispersed. Logical
continuation of some actions happens after response of peer, i.e in interrupt
handler.
On Sun, Jan 22, 2017 at 02:09:01PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> The vblank is mostly CRTC specific and implemented as part of CRTC
> driver. The first patch adds 3 vblank core-driver hooks into struct
> drm_crtc_funcs, and wraps around core vblank handling code to use the
> new
On Sun, Jan 22, 2017 at 02:09:02PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> The vblank is mostly CRTC specific and implemented as part of CRTC
> driver. Let's keep the vblank hooks struct drm_driver for legacy
> drivers, and add corresponding hooks in struct drm_crtc_funcs. These
> hooks t
On Mon, 23 Jan 2017, Daniel Vetter wrote:
> On Mon, Jan 23, 2017 at 03:06:36PM +0100, Andrea Merello wrote:
>> On Mon, Jan 23, 2017 at 1:36 PM, Boris Brezillon
>> wrote:
>> > On Mon, 23 Jan 2017 13:12:12 +0100
>> > Andrea Merello wrote:
>> >
>> >> On Mon, Jan 23, 2017 at 12:32 PM, Jani Nikula
>>
On 01/23/2017 05:50 PM, Arnd Bergmann wrote:
The of_node member in struct drm_bridge is hidden when CONFIG_OF
is disabled, causing a build error:
drivers/gpu/drm/bridge/dw-hdmi.c: In function '__dw_hdmi_probe':
drivers/gpu/drm/bridge/dw-hdmi.c:2063:14: error: 'struct drm_bridge' has no
member
https://bugs.freedesktop.org/show_bug.cgi?id=98520
--- Comment #34 from Ali Hakkı Demiral ---
My problem is almost solved.
The north bridge of my motherboard is unstable.
i test rx480 on ubuntu zesty live image, no crash 5+ hours with other
mainboard. mesa 13.0.2
https://community.amd.com/messag
Hi, Bibby:
On Tue, 2017-01-24 at 13:10 +0800, Bibby Hsieh wrote:
> Current Mediatek DRM driver does not support interlaced mode, and
> will hang if such resolution is used: Filter those to prevent
> kernel hangs, until the DRM driver is fixed properly.
>
> Signed-off-by: Bibby Hsieh
Acked-by: C
https://bugs.freedesktop.org/show_bug.cgi?id=99511
Bug ID: 99511
Summary: Compute Shader can't deal with Depth Buffers correctly
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Hi, Bibby:
On Tue, 2017-01-24 at 12:40 +0800, Bibby Hsieh wrote:
> MT8173 overlay can support UYVY and YUYV format,
> we add the format in DRM driver.
>
> Signed-off-by: Bibby Hsieh
> Reviewed-by: Daniel Kurtz
Acked-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 +++
> d
Hi, YT:
On Mon, 2017-01-23 at 19:05 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so th
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9
head: efa90756f6e447a7e4133b271e10597078fb58fc
commit: b70d2c05b8b81f09a84d49215ab505ff2c0bd404 [4/30] drm/amd/display: Output
Transfer Function Regamma Refactor
config: i386-allmodconfig (attached as .config)
compiler: gcc-6
Current Mediatek DRM driver does not support interlaced mode, and
will hang if such resolution is used: Filter those to prevent
kernel hangs, until the DRM driver is fixed properly.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff -
MT8173 overlay can support UYVY and YUYV format,
we add the format in DRM driver.
Signed-off-by: Bibby Hsieh
Reviewed-by: Daniel Kurtz
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 +++
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++
2 files changed, 9 insertions(+)
diff --git a/driver
On 23 January 2017 at 16:14, Nicolai Hähnle wrote:
> I don't think is correct. The incoming handle is in shared_handle, not in
> handle. Once the code block around line 310 has executed, shared_handle is
> the handle produced by drmPrimeFDToHandle, and closing it on error (as the
> code currently
The DSI0 and DSI1 blocks on the 2835 are related hardware blocks.
Some registers move around, and the featureset is slightly different,
as DSI1 (the 4-lane DSI) is a later version of the hardware block.
This driver doesn't yet enable DSI0, since we don't have any hardware
to test against, but it do
These are part of the vc4 display pipeline.
Signed-off-by: Eric Anholt
---
.../devicetree/bindings/display/brcm,bcm-vc4.txt | 35 ++
1 file changed, 35 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
b/Documentation/devicetree/binding
This is a resend from a month ago of just two of the patches (several
are accepted at this point) from the DSI series, hoping to collect an
ack from DT. Ccing the clock folks as well, since this ends up being
a clock provider.
Eric Anholt (2):
dt-bindings: Document the VC4 DSI module nodes.
d
On Tue, Jan 24, 2017 at 9:35 AM, Bibby Hsieh wrote:
>
> Hi, Daniel,
>
> Thanks for your comment.
>
> On Tue, 2017-01-03 at 14:27 +0800, Daniel Kurtz wrote:
> > On Fri, Dec 30, 2016 at 2:26 PM, Bibby Hsieh
> > wrote:
> > >
> > > MT8173 overlay can support UYVY and YUYV format,
> > > we add the fo
On 01/23/2017 08:49 PM, John Keeping wrote:
Hi Chris,
On Mon, 23 Jan 2017 09:38:54 +0800, Chris Zhong wrote:
On 01/22/2017 12:31 AM, John Keeping wrote:
The multiplication ratio for the PLL is required to be even due to the
use of a "by 2 pre-scaler". Currently we are likely to end up with
Hi,
On 01/23/2017 10:58 PM, Javier Martinez Canillas wrote:
Hello Archit,
On 01/09/2017 06:47 AM, Archit Taneja wrote:
On 01/05/2017 01:01 PM, Sean Paul wrote:
On Fri, Dec 30, 2016 at 4:57 AM, Marek Szyprowski
wrote:
Analogix_dp_bind() can be called from component framework, which doesn't
The MIPI DSI do not need check the validity of resolution, the max
resolution should depend VOP. Hence, remove rk3288_mipi_dsi_mode_valid
here.
Signed-off-by: Chris Zhong
---
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 39 --
Reference the power domain incase dw-mipi power down when
in use.
Signed-off-by: Chris Zhong
Reviewed-by: Sean Paul
---
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/rockchip
Signed-off-by: Chris Zhong
Acked-by: Rob Herring
---
Changes in v4: None
Changes in v3: None
.../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.tx
The dw-mipi-dsi of rk3399 is almost the same as rk3288, the rk3399 has
additional phy config clock.
Signed-off-by: Chris Zhong
Acked-by: Rob Herring
---
Changes in v4: None
Changes in v3: None
.../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 4 +++-
1 file changed, 3 in
The vopb/vopl switch register of RK3399 mipi is different from RK3288,
the default setting for mipi dsi mode is different too, so add a
of_device_id structure to distinguish them, and make sure set the
correct mode before mipi phy init.
Signed-off-by: Chris Zhong
Signed-off-by: Mark Yao
---
Ch
correct the coding style, according the checkpatch scripts
Signed-off-by: Chris Zhong
---
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/rockc
Hi all
This patch serial is for RK3399 MIPI DSI. The MIPI DSI controller of
RK3399 is almost the same as RK3288, except a little bit of difference
in phy clock controlling and port id selection register. These patches
add RK3399 support and the power domain support.
And these patches base on John
Hi Sean
On 01/24/2017 01:48 AM, Sean Paul wrote:
On Fri, Jan 20, 2017 at 06:10:49PM +0800, Chris Zhong wrote:
The MIPI DSI do not need check the validity of resolution, the max
resolution should depend VOP. Hence, remove rk3288_mipi_dsi_mode_valid
here.
Does vop actually enforce this, though?
Hi, Daniel,
Thanks for your comment.
On Tue, 2017-01-03 at 14:27 +0800, Daniel Kurtz wrote:
> On Fri, Dec 30, 2016 at 2:26 PM, Bibby Hsieh wrote:
> >
> > MT8173 overlay can support UYVY and YUYV format,
> > we add the format in DRM driver.
> >
> > Signed-off-by: Bibby Hsieh
> > Reviewed-by: Dan
2017년 01월 23일 18:41에 Chris Wilson 이(가) 쓴 글:
> On Mon, Jan 23, 2017 at 06:32:16PM +0900, Inki Dae wrote:
>>
>>
>> 2017년 01월 21일 01:54에 Tobias Jakobi 이(가) 쓴 글:
>>> From: Dan Carpenter
>>>
>>> We were trying to print an error message if we timed out here, but the
>>> loop actually ends with "tries"
https://bugs.freedesktop.org/show_bug.cgi?id=99510
Bug ID: 99510
Summary: cl_khr_fp64 is reported as supported, but is not, on
CAYMAN
Product: Mesa
Version: 13.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=99078
--- Comment #33 from Michel Dänzer ---
(In reply to Nicolai Hähnle from comment #29)
> We need to keep an eye out on whether this causes a problem in any
> distribution default installation.
Looks like Debian 9 will have Mesa 13 using LLVM 3.9.1
On 11/21/2016 05:50 PM, Hans de Goede wrote:
We need to call drm_helper_hpd_irq_event() on resume to properly detect
monitor connection / disconnection on some laptops, use hpd_work for
this to avoid deadlocks.
Hi,
this seems to introduce a hang of nouveau in 4.10-rc if the gpu is
runtime re
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9
head: efa90756f6e447a7e4133b271e10597078fb58fc
commit: 6d8d2b46e5accb74ce71c834aa95ef5ec9eaa9df [474/507] drm/amdgpu: user BO
priority instead of self coding it
reproduce:
# apt-get install sparse
git checkout
2017년 01월 23일 23:55에 Sean Paul 이(가) 쓴 글:
>
>
> As of now, I don't see any case. even without Maarten's patch set, it
> works well - actually, I had a test with atomic test app more than 10
> hours..
Can you provide this test application? In particular I'm asking this
beca
On Mon, Jan 23, 2017 at 11:05:49AM +0100, Andrzej Hajda wrote:
> Ultra HD modes requires clock ticking at increased rate.
>
> Signed-off-by: Andrzej Hajda
> ---
> v2: long lines wrapped
> v3: moved assigned clocks to cmu_disp node in tm2-common
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2-c
Dear Daniel,
Thanks for the comments.
This contribution was inspired by already available IOCTL DRM_IOCTL_MODE_OBJ_SETPROPERTY.
The atomic APIs are relatively new and are not being used fully/extensively on older version of Linux kernel.
The old world of IOCTLs and properties is still in us
On Mon, Jan 23, 2017 at 11:23:36AM +0100, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Update the bindings documenting the new hdmi phandle and
> update exynos4.dtsi accordingly. This phandle is needed by the
> s5p-cec driver to initialize the HPD notifier framework.
>
> Tested with my Odroid U3
On 01/23/2017 02:10 AM, Fabio Estevam wrote:
> On Sun, Jan 22, 2017 at 12:26 PM, Fabio Estevam wrote:
>> On Sat, Jan 21, 2017 at 2:40 PM, Fabio Estevam wrote:
>>> Hi,
>>>
>>> Stopping kmscube application on mx6q through CTRL + C sometimes leads
>>> to the following kernel warning:
>>>
>>> ^C[ 393
On 13/01/17 15:41, Juergen Gross wrote:
> On 12/01/17 10:21, Chris Wilson wrote:
>> On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote:
>>> On 11/01/17 18:08, Chris Wilson wrote:
On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
> With kernel 4.10rc3 running as Xen
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
https://github.com/anholt/linux drm-vc4-fixes-2017-01-23
for you to fetch changes up to 6b8ac63847bc2f958dd93c09edc941a0118992d9:
drm/vc4: Return -EINVAL on the overflow checks failing. (2017-01-17 22:06:01
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.11-wip
head: a03023d9d5ae93ab2684138f35d53502d61580d4
commit: 9d71b166e8f7a7277abd7b1588ffd2e30a3f88bc [128/131] drm/ttm: revert
"implement LRU add callbacks v2"
config: x86_64-randconfig-i0-201704 (attached as .config)
compiler: g
On Mon, Jan 23, 2017 at 12:50:07PM -0800, Manasi Navare wrote:
> Thanks Jani for reviewing this patch and for your feedback.
> Its very useful feedback and below are some of my comments:
>
> On Fri, Jan 20, 2017 at 05:05:03PM +0200, Jani Nikula wrote:
> > On Fri, 20 Jan 2017, Manasi Navare wrote:
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.11-wip
head: ebe88f26b6161d76f3d74a458bcb19759b15a1b2
commit: ebe88f26b6161d76f3d74a458bcb19759b15a1b2 [131/131] drm/amdgpu: Bring bo
creation in line with radeon driver
config: x86_64-randconfig-x019-201704 (attached as .config)
c
On Sun, Jan 22, 2017 at 8:47 AM, Nicolas Iooss
wrote:
> In smu7_clockpowergating.h, the #ifndef statement which prevents
> multiple inclusions of the header file uses _SMU7_CLOCK_POWER_GATING_H_
> but the following #define statement uses _SMU7_CLOCK__POWER_GATING_H_.
>
> Signed-off-by: Nicolas Ioo
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Monday, January 23, 2017 3:55 AM
> To: Grodzovsky, Andrey
> Cc: Deucher, Alexander ;
> nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org; dri-
> de...@l
On 01/04/2017 06:00 PM, Ayaka wrote:
從我的 iPad 傳送
Daniel Stone 於 2017年1月5日 上午1:02 寫道:
Hi Randy,
On 4 January 2017 at 16:29, Randy Li wrote:
index 90d2cc8..23c8e99 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info
Some drivers may need to acquire P-Unit managed resources from interrupt
context, where they cannot call iosf_mbi_punit_acquire().
This commit adds a notifier chain which allows a driver to get notified
(in a process context) before other drivers start accessing the PMIC bus,
so that the driver ca
Rename accessor_flags to flags, so that we can use the field for
other flags too. This is a preparation patch for adding cherrytrail
support to the punit semaphore code.
Signed-off-by: Hans de Goede
Reviewed-by: Andy Shevchenko
Acked-by: Jarkko Nikula
Tested-by: Takashi Iwai
Acked-by: Wolfram
One some systems the P-Unit accesses the PMIC to change various voltages
through the same bus as other kernel drivers use for e.g. battery
monitoring.
If a driver sends requests to the P-Unit which require the P-Unit to access
the PMIC bus while another driver is also accessing the PMIC bus variou
Hi All,
Here is v2 of my cht i2c-pmic and i915-punit access coordination
patchset. New in this version are some minor spelling / style fixes
and more importantly the inclusion of 6 extra i2c-designware patches.
These 6 patches are ready for merging, they have Wolfram's (the i2c
maintainer's) ack.
Listen for PMIC bus access notifications and get FORCEWAKE_ALL while
the bus is accessed to avoid needing to do any forcewakes, which need
PMIC bus access, while the PMIC bus is busy:
This fixes errors like these showing up in dmesg, usually followed
by a gfx or system freeze:
[drm:fw_domains_get
Rename intel_uncore_early_sanitize to intel_uncore_resume, dropping the
(always true) restore_forcewake argument and add a new intel_uncore_resume
function to replace the intel_uncore_forcewake_reset(dev_priv, false)
calls done from the suspend / runtime_suspend functions and make
intel_uncore_forc
Make sure the P-Unit or the PMIC i2c bus is not in use when we send a
request to the P-Unit by calling iosf_mbi_punit_acquire() / _release()
around P-Unit write accesses.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
Signed-off-by: Hans de Goede
Tested-by: tagorereddy
---
Changes i
Use iosf_mbi_modify instead of iosf_mbi_read + iosf_mbi_write so that
we keep the iosf_mbi_lock locked during the read-modify-write done to
reset the semaphore.
Signed-off-by: Hans de Goede
Reviewed-by: Andy Shevchenko
Acked-by: Jarkko Nikula
Acked-by: Wolfram Sang
---
Changes in v5:
-New patc
Call the iosf_mbi pmic_bus_access_notifier_chain on bus acquire / release.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
Signed-off-by: Hans de Goede
Tested-by: tagorereddy
Reviewed-by: Andy Shevchenko
Acked-by: Wolfram Sang
---
Changes in v2:
-Spelling: P-Unit, PMIC
---
drivers
If (!shared_host) simply return 0, this avoids delaying the probe if
iosf_mbi_available() returns false when an i2c bus is not using the
punit semaphore.
Also move the if (!iosf_mbi_available()) check to above the
dev_info, so that we do not repeat the dev_info on every probe
until iosf_mbi_availa
The cherrytrail punit has the pmic i2c bus access semaphore at a
different register address.
Signed-off-by: Hans de Goede
Reviewed-by: Takashi Iwai
Tested-by: Takashi Iwai
Reviewed-by: Andy Shevchenko
Acked-by: Jarkko Nikula
Acked-by: Wolfram Sang
---
Changes in v2:
-Adjust for accessor_flag
Acquire P-Unit access to stop others from accessing the P-Unit while the
PMIC i2c bus is in use. This is necessary because accessing the P-Unit
from the kernel may result in the P-Unit trying to access the PMIC i2c
bus, which results in a hang when it happens while we own the PMIC i2c
bus semaphore
Pass dw_i2c_dev into the helper functions, this is a preparation patch
for the punit semaphore fixes done in the other patches in this set.
Signed-off-by: Hans de Goede
Reviewed-by: Takashi Iwai
Tested-by: Takashi Iwai
Reviewed-by: Andy Shevchenko
Acked-by: Jarkko Nikula
Acked-by: Wolfram San
On my cherrytrail tablet with axp288 pmic, just doing a bunch of repeated
reads from the pmic, e.g. "i2cdump -y 14 0x34" would lookup the tablet in
1 - 3 runs guaranteed.
This seems to be causes by the cpu trying to enter C6 or C7 while we hold
the punit bus semaphore, at which point everything ju
On Mon, Jan 23, 2017 at 07:05:14PM +0800, YT Shen wrote:
> Add decriptions about supported chips, including MT2701 & MT8173
>
> Signed-off-by: YT Shen
> Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 ++
> Documentation/devicetree/bindings
Thanks Jani for reviewing this patch and for your feedback.
Its very useful feedback and below are some of my comments:
On Fri, Jan 20, 2017 at 05:05:03PM +0200, Jani Nikula wrote:
> On Fri, 20 Jan 2017, Manasi Navare wrote:
> > This patch adds support to handle automated DP compliance
> > link t
https://bugs.freedesktop.org/show_bug.cgi?id=99444
--- Comment #10 from Shmerl ---
And since the game isn't using GL natively, if anything is calling
GL_NV_register_combiners in some situations, it must be Wine.
--
You are receiving this mail because:
You are the assignee for the bug.__
On Sun, Jan 22, 2017 at 07:11:16PM +0100, Noralf Trønnes wrote:
> Add device-tree binding documentation for the MI0283QT display panel.
>
> Signed-off-by: Noralf Trønnes
> ---
>
> Datasheet: https://cdn-shop.adafruit.com/datasheets/MI0283QT-11+V1.1.PDF
>
>
> .../bindings/display/multi-inno,mi
https://bugs.freedesktop.org/show_bug.cgi?id=99444
--- Comment #9 from Shmerl ---
(In reply to Samuel Pitoiset from comment #8)
> Well, the trace is broken somehow, and it has been recorded using NVIDIA
> blob because it relies on NV_register_combiners. That explains the
> GL_COMBINER0_NV errors
On Sun, Jan 22, 2017 at 07:11:15PM +0100, Noralf Trønnes wrote:
> Multi-Inno Technology Co.,Ltd is a Hong Kong based company offering
> LCD, LCD module products and complete panel solutions.
>
> Signed-off-by: Noralf Trønnes
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>
https://bugs.freedesktop.org/show_bug.cgi?id=99444
--- Comment #8 from Samuel Pitoiset ---
Well, the trace is broken somehow, and it has been recorded using NVIDIA blob
because it relies on NV_register_combiners. That explains the GL_COMBINER0_NV
errors while replaying it.
Could you try that gam
If the device-tree 'reg' node doesn't reserve enough
space for the DP, fail to bind.
Reviewed-by: Brian Starkey
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/malidp_drv.c | 20
drivers/gpu/drm/arm/malidp_regs.h | 2 ++
2 files changed, 22 insertions(+)
diff --g
Refuse to bind if the device-tree compatible string
lists a different hardware version.
Reviewed-by: Brian Starkey
Signed-off-by: Mihail Atanassov
---
A couple of small improvements to driver-to-hardware binding.
drivers/gpu/drm/arm/malidp_drv.c | 52 +++
On Mon, Jan 23, 2017 at 03:06:36PM +0100, Andrea Merello wrote:
> On Mon, Jan 23, 2017 at 1:36 PM, Boris Brezillon
> wrote:
> > On Mon, 23 Jan 2017 13:12:12 +0100
> > Andrea Merello wrote:
> >
> >> On Mon, Jan 23, 2017 at 12:32 PM, Jani Nikula
> >> wrote:
> >> > On Mon, 23 Jan 2017, Boris Brezil
On Mon, Jan 23, 2017 at 09:05:02AM -0800, Manasi Navare wrote:
> On Sat, Jan 21, 2017 at 05:16:42PM +0200, Jani Nikula wrote:
> > On Sat, 21 Jan 2017, Manasi Navare wrote:
> > > This patch series addresses all the review comments from the previous
> > > series:
> > > https://patchwork.freedesktop
Hi Dave,
The following changes since commit 25a7087fef1bfe7e0b9f4db4d75e08e9d9b11153:
Merge remote-tracking branch 'vmwgfx_drm_stage/drm-fixes' into
fdo_drm-vmwgfx-fixes (2017-01-19 08:42:10 -0800)
are available in the git repository at:
git://people.freedesktop.org/~syeh/repos_linux drm-v
On Mon, Jan 23, 2017 at 11:20:42AM -0500, Sean Paul wrote:
> On Mon, Jan 23, 2017 at 05:01:56PM +0100, Tobias Jakobi wrote:
> > Sean Paul wrote:
> > >
> > >
> > > As of now, I don't see any case. even without Maarten's patch set, it
> > > works well - actually, I had a test with atomic t
On Fri, Jan 20, 2017 at 06:10:51PM +0800, Chris Zhong wrote:
> Reference the power domain incase dw-mipi power down when
> in use.
>
Reviewed-by: Sean Paul
> Signed-off-by: Chris Zhong
> ---
>
> Changes in v3: None
>
> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16
> 1 file c
On Mon, Jan 23, 2017 at 09:51:55AM -0200, Fabio Estevam wrote:
> On Mon, Jan 23, 2017 at 1:15 AM, Marek Vasut wrote:
>
> > IMHO this will no longer handle the fences correctly and you'll see
> > rendering artifacts sometimes.
>
> Ok, for 4.9.x stable we cannot apply your 782ea2a493ba90800 ("drm/
On Fri, Jan 20, 2017 at 06:10:49PM +0800, Chris Zhong wrote:
> The MIPI DSI do not need check the validity of resolution, the max
> resolution should depend VOP. Hence, remove rk3288_mipi_dsi_mode_valid
> here.
Does vop actually enforce this, though? I see that mode_config.max_width is
4096, but t
On Fri, Jan 20, 2017 at 06:10:48PM +0800, Chris Zhong wrote:
> The vopb/vopl switch register of RK3399 mipi is different from RK3288,
> the default setting for mipi dsi mode is different too, so add a
> of_device_id structure to distinguish them, and make sure set the
> correct mode before mipi phy
Hello Archit,
On 01/09/2017 06:47 AM, Archit Taneja wrote:
>
>
> On 01/05/2017 01:01 PM, Sean Paul wrote:
>> On Fri, Dec 30, 2016 at 4:57 AM, Marek Szyprowski
>> wrote:
>>> Analogix_dp_bind() can be called from component framework, which doesn't
>>> guarantee proper runtime PM state of the devi
On Mon, Jan 23, 2017 at 3:30 AM, Daniel Vetter wrote:
> On Thu, Jan 19, 2017 at 10:10:21AM -0500, Alex Deucher wrote:
>> On Wed, Jan 18, 2017 at 10:34 AM, Jeff Smith wrote:
>> > Hello all,
>> >
>> > This code is very raw at this point, but wanted to get this out there
>> > for feedback.
>> >
>> >
On Sat, Jan 21, 2017 at 05:16:42PM +0200, Jani Nikula wrote:
> On Sat, 21 Jan 2017, Manasi Navare wrote:
> > This patch series addresses all the review comments from the previous
> > series:
> > https://patchwork.freedesktop.org/series/18256/
>
> It does not, and it frustrates me.
>
> BR,
> Jan
On Mon, Jan 23, 2017 at 01:46:42PM +, Mihail Atanassov wrote:
> If the device-tree 'reg' node doesn't reserve enough
> space for the DP, fail to bind.
>
> Reviewed-by: Brian Starkey
> Signed-off-by: Mihail Atanassov
> ---
> drivers/gpu/drm/arm/malidp_drv.c | 20
> driv
https://bugs.freedesktop.org/show_bug.cgi?id=99078
--- Comment #32 from Nicolai Hähnle ---
Corresponding LLVM bug: https://llvm.org/bugs/show_bug.cgi?id=31722
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel maili
Am Montag, den 23.01.2017, 17:33 +0100 schrieb Thierry Reding:
> On Fri, Jan 13, 2017 at 06:36:30PM +0100, Lucas Stach wrote:
> > The i2c adapter on DP AUX is purely a software construct. Linking
> > it to the device node of the parent device is wrong, as it leads to
> > 2 devices sharing the same
On Fri, Jan 13, 2017 at 06:36:30PM +0100, Lucas Stach wrote:
> The i2c adapter on DP AUX is purely a software construct. Linking
> it to the device node of the parent device is wrong, as it leads to
> 2 devices sharing the same device node, which is bad practice, as
Who says that two devices can't
On Mon, Jan 23, 2017 at 05:01:56PM +0100, Tobias Jakobi wrote:
> Sean Paul wrote:
> >
> >
> > As of now, I don't see any case. even without Maarten's patch set, it
> > works well - actually, I had a test with atomic test app more than 10
> > hours..
> Can you provide this test
On 22.01.2017 19:48, Emil Velikov wrote:
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Emil Velikov
Reviewed-by: Nicolai Hähnle
---
amdgpu/amdgpu_bo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index d30fd1e7..c9f31587 100644
--- a/amdgpu
I don't think is correct. The incoming handle is in shared_handle, not
in handle. Once the code block around line 310 has executed,
shared_handle is the handle produced by drmPrimeFDToHandle, and closing
it on error (as the code currently does) should be the correct thing to do.
The only possi
On Fri, Jan 20, 2017 at 12:25:00AM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> It adds the TV Encoder driver to support video output in PAL and NTSC
> format. The driver uses syscon/regmap interface to configure register
> bit sitting in SYSCTRL module for DAC power control.
>
> Signed-off-by
Sean Paul wrote:
>
>
> As of now, I don't see any case. even without Maarten's patch set, it
> works well - actually, I had a test with atomic test app more than 10
> hours..
Can you provide this test application? In particular I'm asking this
because libdrm currently does
On Fri, Jan 20, 2017 at 12:24:58AM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> The clock control module (CRM) cannot always provide desired frequency
> for all VOU output devices. That's why VOU integrates a few dividers
> to further divide the clocks from CRM. Let's add an interface for
> co
On Fri, Jan 20, 2017 at 12:24:57AM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> Although data in struct vou_inf is defined per output device, it doesn't
> belong to the device itself but VOU control module. All these data can
> just be defined in VOU driver, and output device driver only needs
On Fri, Jan 20, 2017 at 12:24:56AM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> It adds interlace mode support in VOU TIMING_CTRL and channel control
> block, so that VOU driver gets ready to support output device in
> interlace mode like TV Encoder.
>
> Signed-off-by: Shawn Guo
> ---
> drive
https://bugs.freedesktop.org/show_bug.cgi?id=99078
--- Comment #31 from Shahar Or ---
I've been using Ubuntu 16.10 for several months without this issue.
On upgrade to 17.04, I was affected by this issue.
Here is the issue in Ubuntu's tracker:
https://bugs.launchpad.net/ubuntu/+source/llvm-tool
> >>> As of now, I don't see any case. even without Maarten's patch set, it
> >>> works well - actually, I had a test with atomic test app more than 10
> >>> hours..
> >> Can you provide this test application? In particular I'm asking this
> >> because libdrm currently doesn't provide any tests
On Fri, Jan 20, 2017 at 12:24:59AM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> It adds bindings doc for ZTE VOU TV Encoder device.
>
> Signed-off-by: Shawn Guo
> ---
> Documentation/devicetree/bindings/display/zte,vou.txt | 15 +++
> 1 file changed, 15 insertions(+)
Acked-by: Ro
https://bugs.freedesktop.org/show_bug.cgi?id=99078
--- Comment #30 from Nicolai Hähnle ---
Re Matt, comment #28, that setting can result in more time spent on shader
compiles. I don't think those are an issue in typical X server loads.
--
You are receiving this mail because:
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=99078
--- Comment #29 from Nicolai Hähnle ---
It's almost certainly because we missed
01a133c760ebb8db1e204f76ba55c19558b1ce01 "AMDGPU: Do not clobber SCC in
SIWholeQuadMode" when back-porting -- probably because that one is not
straight-forward at all
https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #22 from lei.p...@gmail.com ---
(In reply to Michel Dänzer from comment #21)
> (In reply to lei.pero from comment #18)
> > I didn't know that about modesetting driver, anyway, even with
> > LIBGL_DRI3_DISABLE=1 same thing happens.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=99078
--- Comment #28 from Matt Whitlock ---
(In reply to Nicolai Hähnle from comment #27)
> R600_DEBUG=mono
Does this workaround have any negative consequences (e.g., performance
regressions), or is it suitable for use in a daily-driver environment?
1 - 100 of 192 matches
Mail list logo