Hi Dave,
drm-misc-fixes-2017-02-09:
Last-minute vc4 fix for 4.10.
Cheers, Daniel
The following changes since commit d5adbfcd5f7bcc6fa58a41c5c5ada0e5c826ce2c:
Linux 4.10-rc7 (2017-02-05 15:10:58 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/git/drm-misc tags
On 09.02.2017 02:26, Hoegeun Kwon wrote:
> The OF graph is not needed because the panel is a child of dsi. So
> Remove the ports node and move burst and esc clock frequency
> properties to the parent (DSI node).
>
> Signed-off-by: Hoegeun Kwon
For the whole patchset:
Reviewed-by: Andrzej Hajda
-
On 09.02.2017 02:26, Hoegeun Kwon wrote:
> The dsi + panel is a parental relationship, so OF grpah is not needed.
> Therefore, the current dsi_parse_dt function will throw an error,
> because there is no linked OF graph for case such as fimd + dsi +
> panel. So this patch parse the Pll, burst and e
https://bugs.freedesktop.org/show_bug.cgi?id=99718
Bug ID: 99718
Summary: RX480 - MCLK stuck at 300
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=99484
--- Comment #2 from Timothy Arceri ---
You can see the issue in the progress bar on the main loading screen:
https://drive.google.com/open?id=0B-f68fD4PtpBZmx0M2VPUU1oRms
--
You are receiving this mail because:
You are the assignee for the bug
On Fri, Feb 3, 2017 at 5:15 AM, Michel Dänzer wrote:
> On 02/02/17 06:36 PM, Christian König wrote:
>> Am 02.02.2017 um 07:09 schrieb Michel Dänzer:
>>> [SNIP]
>>> OTOH the people running the kernel aren't always the same people
>>> building it, so the downside is that this would potentially delay
On 02/06/2017 11:09 PM, Jordan Crouse wrote:
In the future we won't have a fixed set of addresses spaces.
Instead of going through the effort of assigning a ID for each
address space just use the address space itself as a token for
getting / putting an iova.
This forces a few changes in the ge
On Tue, Feb 7, 2017 at 5:51 AM, Christian König wrote:
> Am 06.02.2017 um 21:13 schrieb j.gli...@gmail.com:
>>
>> From: Jérôme Glisse
>>
>> When GPU fails to resume we can not trust that value we write to GPU
>> memory will post and we might get garbage (more like 0x on
>> x86) when readi
On Tue, Feb 7, 2017 at 8:16 AM, Dan Carpenter wrote:
> If "rdev->bios" is NULL then we don't need to free it.
>
> Signed-off-by: Dan Carpenter
applied. thanks!
>
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
> b/drivers/gpu/drm/radeon/radeon_bios.c
> index 00cfb5d2875f..04c0ed41374f 100
On Fri, Feb 3, 2017 at 3:23 PM, Colin King wrote:
> From: Colin Ian King
>
> bo_va is being kfree'd twice, once in the call to amdgpu_vm_bo_rmv
> and then a short while later. Fix this double free by removing
> the 2nd kfree.
>
> Detected by CoverityScan, CID#1399524 ("Double Free")
>
> Signed-of
On 2017.02.08 14:49:22 +0200, Joonas Lahtinen wrote:
> On ti, 2017-02-07 at 17:53 +0300, Dan Carpenter wrote:
> > "caps.buf" is always NULL here and "caps.size" is always zero. The code
> > is a no-op and can be removed.
> >
> > Signed-off-by: Dan Carpenter
>
> Reviewed-by: Joonas Lahtinen
>
The from_cache flag was actually "the BO is invisible to userspace",
so we can repurpose to just zero out a cached BO and return it to
userspace.
Improves wall time for a loop of 5 glsl-algebraic-add-add-1 by
-1.44989% +/- 0.862891% (n=28, 1 outlier removed from each that
appeared to be other syst
On 02/08/2017 03:00 PM, Jordan Crouse wrote:
> On Wed, Feb 08, 2017 at 12:30:08PM -0800, Stephen Boyd wrote:
>
>> const struct msm_ringbuffer?
> msm_ringbuffer is actively being modified, so we would have to cast it - can't
> tell if there would be a compiler advantage or not.
>
I just meant for t
Am Dienstag, 7. Februar 2017, 16:35:35 CET schrieb Mark Yao:
> Some iommu patches on the series[0] "iommu/rockchip: Fix bugs and
> enable on ARM64" already landed, So drm/rockchip related patches [1] and [2]
> ready to landed, this series just rebase them to lastest drm-next.
>
> And fix some bugs
On Mon, Feb 06, 2017 at 11:29:50AM +0100, Hans Verkuil wrote:
> From: Benjamin Gaignard
>
> By using the HPD notifier framework there is no longer any reason
> to manually set the physical address. This was the one blocking
> issue that prevented this driver from going out of staging, so do
> thi
https://bugs.freedesktop.org/show_bug.cgi?id=98869
cosiek...@o2.pl changed:
What|Removed |Added
Summary|Electronic Super Joy|Electronic Super Joy
On Wed, Feb 08, 2017 at 12:30:08PM -0800, Stephen Boyd wrote:
> On 02/06/2017 09:39 AM, Jordan Crouse wrote:
> > diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> > b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> > new file mode 100644
> > index 000..348ead7
> > --- /dev/null
> > +++ b/dr
Andrzej Pietrasiewicz writes:
> Hi Eric,
>
> W dniu 08.02.2017 o 01:33, Eric Anholt pisze:
>> Andrzej Pietrasiewicz writes:
>>
>
>
>
>>
>> Thanks for the detailed explanation!
>>
>> I think the cursor's possible_crtcs is getting set in vc4_crtc.c (since
>> we don't pass the cursor into drm_crtc
Unlike the other encoders in the driver, I've also dropped the debug
dump function. There's only really one register to this device, and
we have the debugfs reg entry still.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dpi.c | 13 -
1 file changed, 13 deletions(-)
diff --
On 02/06/2017 09:39 AM, Jordan Crouse wrote:
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> new file mode 100644
> index 000..348ead7
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> @@ -0,0 +1,367 @@
>
> +/*
> + * Tr
Shawn Guo writes:
> From: Shawn Guo
>
> Core code already makes drm_driver.get_vblank_counter hook optional by
> letting drm_vblank_no_hw_counter be the default implementation for the
> function hook. So the drm_vblank_no_hw_counter assignment in the driver
> code becomes redundant and can be r
Shawn Guo writes:
> From: Shawn Guo
>
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.
Thanks for doing this cleanup!
Reviewed-by: Eric Anholt
On Wed, Feb 08, 2017 at 07:24:08PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> For consistency with other reference counting APIs in the kernel, add
> drm_property_blob_get() and drm_property_blob_put() to reference count
> DRM blob properties.
>
> Compatibility aliases are added to
On Wed, Feb 08, 2017 at 07:24:07PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> For consistency with other reference counting APIs in the kernel, add
> drm_gem_object_get() and drm_gem_object_put(), as well as an unlocked
> variant of the latter, to reference count GEM buffer objects.
On Wed, Feb 08, 2017 at 07:24:06PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> For consistency with other reference counting APIs in the kernel, add
> drm_framebuffer_get() and drm_framebuffer_put() to reference count DRM
> framebuffers.
>
> Compatibility aliases are added to keep ex
On Wed, Feb 08, 2017 at 07:24:05PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> For consistency with other reference counting APIs in the kernel, add
> drm_connector_get() and drm_connector_put() functions to reference count
> connectors.
>
> Compatibility aliases are added to keep ex
On Wed, Feb 08, 2017 at 07:24:04PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> For consistency with other reference counting APIs in the kernel, add
> drm_mode_object_get() and drm_mode_object_put() to reference count DRM
> mode objects.
>
> Compatibility aliases are added to keep ex
On Wed, Feb 08, 2017 at 07:24:03PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Subsequent patches will introduce reference counting APIs that are more
> consistent with similar APIs throughout the Linux kernel. These APIs use
> the _get() and _put() suffixes and will collide with this
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #72 from Marek Olšák ---
If the game does any reads or read-modify-write on the mapped buffer memory and
doesn't use the GL_MAP_READ_BIT, it's a bug in the game.
--
You are receiving this mail because:
You are the assignee for the b
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #71 from Marek Olšák ---
The current heuristic in Mesa is that if a buffer is not mapped for read, Mesa
doesn't enable CPU caches for the mapping. It's usually an optimal solution for
write-only buffer uploads.
Enabling CPU caches fo
On Wed, Feb 08, 2017 at 08:10:04PM +0200, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Wednesday 08 Feb 2017 13:30:51 Tomi Valkeinen wrote:
> > On 07/02/17 11:16, Shawn Guo wrote:
> > > From: Shawn Guo
> > >
> > > The vblank is mostly CRTC specific and implemented as part of CRTC
> > > driver. The
From: Thierry Reding
For consistency with other reference counting APIs in the kernel, add
drm_gem_object_get() and drm_gem_object_put(), as well as an unlocked
variant of the latter, to reference count GEM buffer objects.
Compatibility aliases are added to keep existing code working. To help
sp
From: Thierry Reding
For consistency with other reference counting APIs in the kernel, add
drm_property_blob_get() and drm_property_blob_put() to reference count
DRM blob properties.
Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances
From: Thierry Reding
For consistency with other reference counting APIs in the kernel, add
drm_connector_get() and drm_connector_put() functions to reference count
connectors.
Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the
From: Thierry Reding
Subsequent patches will introduce reference counting APIs that are more
consistent with similar APIs throughout the Linux kernel. These APIs use
the _get() and _put() suffixes and will collide with this existing
function.
Rename the function to drm_mode_object_add() which is
From: Thierry Reding
This series introduces DRM reference counting APIs that are consistent
with other reference counting APIs in the kernel. They are also much
shorter. Compatibility aliases are added to keep existing code working
and will stay in place until all users of the old APIs are gone.
From: Thierry Reding
For consistency with other reference counting APIs in the kernel, add
drm_mode_object_get() and drm_mode_object_put() to reference count DRM
mode objects.
Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the
From: Thierry Reding
For consistency with other reference counting APIs in the kernel, add
drm_framebuffer_get() and drm_framebuffer_put() to reference count DRM
framebuffers.
Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #70 from Captain Crutches ---
So, at the risk of sounding ignorant, does that mean the bug actually belongs
to Psyonix because they're just doing it inefficiently, or is there still
something that can be done on the Mesa side?
--
Yo
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #69 from Marek Olšák ---
Actually, the only way to get cached RAM is to map a buffer with
GL_MAP_READ_BIT. There is no other way.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for t
Hi Jyri,
Thank you for the patch.
On Wednesday 08 Feb 2017 16:08:06 Jyri Sarha wrote:
> Let's disable all scaling that requires horizontal decimation with
> higher factor than 4, until we have better estimates of what we can
> and can not do. However, NV12 color format appears to work Ok with
> a
Hi Tomi,
On Wednesday 08 Feb 2017 13:30:51 Tomi Valkeinen wrote:
> On 07/02/17 11:16, 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
Hi Tomi,
On Wednesday 08 Feb 2017 15:51:08 Tomi Valkeinen wrote:
> On 07/02/17 16:41, Jyri Sarha wrote:
> > Let's disable all scaling that requires horizontal decimation with
> > higher factor than 4, until we have better estimates of what we can
> > and can not do. However, 1 byte per pixel color
https://bugs.freedesktop.org/show_bug.cgi?id=99552
--- Comment #2 from Vedran Miletić ---
(In reply to Vedran Miletić from comment #1)
> Start 7: testPrivateVar
> 7/10 Test #7: testPrivateVar ...***Exception: Other 3.22
> sec
Adding native_rsqrt fixes this, patch will a
Hi,
On 07-02-2017 16:36, Thierry Reding wrote:
> On Tue, Feb 07, 2017 at 09:43:15PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 2/7/2017 4:31 PM, Jose Abreu wrote:
>>> Hi Shashank,
>>>
>>>
>>>
>>> On 06-02-2017 13:59, Shashank Sharma wrote:
This patch does following
On Tue, Feb 07, 2017 at 08:01:37PM +0100, Daniel Vetter wrote:
> On Tue, Feb 07, 2017 at 06:51:13PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > This commit adds a TODO list to the GPU driver developer's guide. The
> > content was taken from the DRMJanitors page on the X.Org wiki
On 02/08/2017 08:19 AM, Daniel Vetter wrote:
> On Wed, Feb 8, 2017 at 6:19 AM, Stefan Agner wrote:
>> On 2016-12-14 13:25, Marek Vasut wrote:
>>> On 12/14/2016 09:48 PM, Stefan Agner wrote:
The DRM subsystem specifies the pixel clock polarity from a
controllers perspective: DRM_BUS_FLAG_
Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
regulator_set_voltage()") exposes the following probe issue:
63ff.tve supply dac not found, using dummy regulator
imx-drm display-subsystem: failed to bind 63ff.tve (ops imx_tve_ops): -22
When the 'dac-supply' is not pas
Hi Shashank,
On 07-02-2017 16:09, Sharma, Shashank wrote:
> Thanks for the review Jose, my comments inline.
>
>
> Regards
>
> Shashank
>
>
> On 2/7/2017 4:24 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> Sorry for the late review.
>>
>>
>> On 06-02-2017 13:59, Shashank Sharma wrote:
>>> From: T
Hi Jani,
On 07-02-2017 15:09, Jani Nikula wrote:
> On Tue, 07 Feb 2017, Jose Abreu wrote:
>> Hi Jani,
>>
>>
>> On 07-02-2017 13:35, Jani Nikula wrote:
>>> On Tue, 07 Feb 2017, Jose Abreu wrote:
> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
> +{
> + u8 status
Hi Eric,
W dniu 08.02.2017 o 01:33, Eric Anholt pisze:
Andrzej Pietrasiewicz writes:
Thanks for the detailed explanation!
I think the cursor's possible_crtcs is getting set in vc4_crtc.c (since
we don't pass the cursor into drm_crtc_init_with_planes()).
You are right. Shall I submit a
Hi Shashank,
On 08-02-2017 12:59, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/8/2017 4:57 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>>
>> On 07-02-2017 16:09, Sharma, Shashank wrote:
>>> Thanks for the review Jose, my comments inline.
>>>
>>>
>>> Regards
>>>
>>> Shashank
>>>
>>>
>
Dear Sir/Madam,
I am Sgt Swanson Dennis, I have a good business proposal for you.
There are no risks involved and it is easy. Please reply for briefs
and procedures.
Best regards,
Sgt Swanson Dennis
___
dri-devel mailing list
dri-devel@lists.freedeskto
Hi Shashank,
On 07-02-2017 16:19, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/7/2017 4:44 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>>
>> On 06-02-2017 13:59, Shashank Sharma wrote:
>>> HDMI 2.0 spec mandates scrambling for modes with pixel clock
>>> higher
>>> than 340 MHz. This
On Wed, Feb 8, 2017 at 12:09 PM, Hoegeun Kwon wrote:
> On 02/08/2017 04:32 PM, Krzysztof Kozlowski wrote:
>>
>> On Wed, Feb 8, 2017 at 9:24 AM, Hoegeun Kwon
>> wrote:
"Remove the ports node abd move burst and esc clock frequency properties
to the parent (DSI node)."
The i
On Wed, Feb 8, 2017 at 9:24 AM, Hoegeun Kwon wrote:
>
>>
>> "Remove the ports node abd move burst and esc clock frequency properties
>> to the parent (DSI node)."
>>
>> The information which is missing is the answer for WHY? Why are you
>> doing this?
>
>
> The current mipi-dsi must have at least
Hi Rob,
On Fri, Feb 03, 2017 at 09:36:33PM -0600, Rob Herring wrote:
> Convert drivers to use the new of_graph_get_remote_node() helper
> instead of parsing the endpoint node and then getting the remote device
> node. Now drivers can just specify the device node and which
> port/endpoint and get b
On 02/08/2017 08:17 AM, Daniel Vetter wrote:
> On Tue, Feb 7, 2017 at 11:31 PM, Marek Vasut wrote:
>> On 02/07/2017 11:15 PM, Daniel Vetter wrote:
>>> On Tue, Feb 07, 2017 at 10:44:59PM +0100, Marek Vasut wrote:
On 02/02/2017 10:26 PM, Fabio Estevam wrote:
> From: Fabio Estevam
>
>>>
On 02/08/2017 04:32 PM, Krzysztof Kozlowski wrote:
On Wed, Feb 8, 2017 at 9:24 AM, Hoegeun Kwon wrote:
"Remove the ports node abd move burst and esc clock frequency properties
to the parent (DSI node)."
The information which is missing is the answer for WHY? Why are you
doing this?
The curre
Hi Rob,
On Mon, Feb 06, 2017 at 11:32:01AM -0600, Rob Herring wrote:
> On Mon, Feb 06, 2017 at 11:03:01AM +0100, Maxime Ripard wrote:
> > Hi Rob,
> >
> > On Fri, Feb 03, 2017 at 09:36:34PM -0600, Rob Herring wrote:
> > > Similar to the previous commit, convert drivers open coding OF graph
> > > p
I applied this change on the couple-days old drm-tip, and was not able to get
any "EDID checksum is invalid" messages with it on my SKL. Without this patch I
could generate the ERROR quite easily by switching the outputs and displays
manually.
I don't know if this hides something that it should
從我的 iPad 傳送
> Mauro Carvalho Chehab 於 2017年2月3日 下午10:04 寫道:
>
> Em Thu, 5 Jan 2017 20:27:17 +0200
> Sakari Ailus escreveu:
>
>> Hi Randy,
>>
>>> On Thu, Jan 05, 2017 at 11:22:26PM +0800, ayaka wrote:
>>>
>>>
On 01/05/2017 06:30 PM, Sakari Ailus wrote:
Hi Randy,
Than
Hi krzysztof,
On 02/08/2017 05:13 AM, Krzysztof Kozlowski wrote:
Hi,
I think the subject is not really matching the real work. You are rather
removing the OF graph from DSI node.
On Mon, Feb 06, 2017 at 11:19:41AM +0900, Hoegeun Kwon wrote:
The OF graph is not needed because the panel is a
Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
regulator_set_voltage()") exposes the following probe issue:
63ff.tve supply dac not found, using dummy regulator
imx-drm display-subsystem: failed to bind 63ff.tve (ops imx_tve_ops): -22
When the 'dac-supply' is not pas
On 06/02/17 17:50, Martin Peres wrote:
On 03/02/17 10:04, Daniel Vetter wrote:
On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
On 01/02/17 22:05, Manasi Navare wrote:
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
Jani Nikula writes:
On Tue, 31 Jan 2017, Eric An
On Wed, Feb 08, 2017 at 10:25:16AM +0800, Chris Zhong wrote:
> 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 RK3
On Wed, Feb 08, 2017 at 10:25:18AM +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
https://bugs.freedesktop.org/show_bug.cgi?id=99552
--- Comment #1 from Vedran Miletić ---
How to test:
$ mkdir build; cd build
$ cmake -DWITH_TESTS=ON ..
$ make -j
$ make test
Right now, Mesa/LLVM latest git pulled half an hour ago I get:
Running tests...
Test project /users/miletivn/workspace
On Tue, Feb 07, 2017 at 05:16:12PM +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 plug them into core by adding wrapper functions for
>
On Tue, Feb 07, 2017 at 05:16:22PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.
>
Reviewed-by: Se
https://bugs.freedesktop.org/show_bug.cgi?id=99710
--- Comment #5 from garththei...@hotmail.com ---
I am able to recreate this on Wine-git using modes default and nine.
Additionally this is also a problem in Crossover with Performance Enhanced
Graphics enabled.
--
You are receiving this mail bec
I'm typing this too often on irc.
Acked-by: Sean Paul
Signed-off-by: Daniel Vetter
---
drm-misc.rst | 8
1 file changed, 8 insertions(+)
diff --git a/drm-misc.rst b/drm-misc.rst
index 5c1bef57e3b7..73882dc55be6 100644
--- a/drm-misc.rst
+++ b/drm-misc.rst
@@ -20,6 +20,14 @@ reality, i
Let's disable all scaling that requires horizontal decimation with
higher factor than 4, until we have better estimates of what we can
and can not do. However, NV12 color format appears to work Ok with
all decimation factors.
When decimating horizontally by more that 4 the dss is not able to
fetch
On 07/02/17 16:41, Jyri Sarha wrote:
> Let's disable all scaling that requires horizontal decimation with
> higher factor than 4, until we have better estimates of what we can
> and can not do. However, 1 byte per pixel color format appear to work
> Ok with all decimation factors.
>
> When decima
On 02/08/17 13:25, Laurent Pinchart wrote:
> Hi Jyri,
>
> Thank you for the patch.
>
> On Tuesday 07 Feb 2017 16:41:20 Jyri Sarha wrote:
>> Let's disable all scaling that requires horizontal decimation with
>> higher factor than 4, until we have better estimates of what we can
>> and can not do.
On Wed, Feb 08, 2017 at 01:19:23PM +, Tahvanainen, Jari wrote:
> I applied this change on the couple-days old drm-tip, and was not able to get
> any "EDID checksum is invalid" messages with it on my SKL. Without this patch
> I could generate the ERROR quite easily by switching the outputs and
https://bugs.freedesktop.org/show_bug.cgi?id=99710
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #4 from M
Regards
Shashank
On 2/8/2017 5:06 PM, Jose Abreu wrote:
Hi,
On 07-02-2017 16:36, Thierry Reding wrote:
On Tue, Feb 07, 2017 at 09:43:15PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/7/2017 4:31 PM, Jose Abreu wrote:
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
Regards
Shashank
On 2/8/2017 5:01 PM, Jose Abreu wrote:
Hi Shashank,
On 07-02-2017 16:19, Sharma, Shashank wrote:
Regards
Shashank
On 2/7/2017 4:44 PM, Jose Abreu wrote:
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
HDMI 2.0 spec mandates scrambling for modes with pixel
Regards
Shashank
On 2/8/2017 4:57 PM, Jose Abreu wrote:
Hi Shashank,
On 07-02-2017 16:09, Sharma, Shashank wrote:
Thanks for the review Jose, my comments inline.
Regards
Shashank
On 2/7/2017 4:24 PM, Jose Abreu wrote:
Hi Shashank,
Sorry for the late review.
On 06-02-2017 13:59, S
On ti, 2017-02-07 at 17:53 +0300, Dan Carpenter wrote:
> "caps.buf" is always NULL here and "caps.size" is always zero. The code
> is a no-op and can be removed.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Joonas Lahtinen
I assume Zhenyu will merge this through their tree.
Regards, Joonas
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #68 from Marek Olšák ---
The long hangs are spent in an upload/decompression thread the game uses. The
thread doesn't use any GL calls.
My theory that's now confirmed was that the game maps buffers in VRAM and does
read-modify-write
On Wed, 08 Feb 2017, Jose Abreu wrote:
> Hi Jani,
>
>
>
> On 07-02-2017 15:09, Jani Nikula wrote:
>> On Tue, 07 Feb 2017, Jose Abreu wrote:
>>> Hi Jani,
>>>
>>>
>>> On 07-02-2017 13:35, Jani Nikula wrote:
On Tue, 07 Feb 2017, Jose Abreu wrote:
>> +bool drm_scdc_check_scrambling_status(s
On Tue, Feb 07, 2017 at 09:01:22PM -0800, Stefan Agner wrote:
> On 2017-02-07 01:16, Shawn Guo wrote:
> > From: Shawn Guo
> >
> > The vblank hooks in struct drm_driver are deprecated and only meant for
> > legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks
> > in struct drm_c
On 08/02/17 13:25, Laurent Pinchart wrote:
> Hi Jyri,
>
> Thank you for the patch.
>
> On Tuesday 07 Feb 2017 16:41:20 Jyri Sarha wrote:
>> Let's disable all scaling that requires horizontal decimation with
>> higher factor than 4, until we have better estimates of what we can
>> and can not do.
On Wed, Feb 8, 2017 at 7:52 AM, Philipp Zabel wrote:
> Good point, I suppose what the driver should really do is warn if the
> voltage not set correctly?
Yes, I can do as suggested. Will prepare a patch. Thanks
___
dri-devel mailing list
dri-devel@list
Hi,
On 07/02/17 11:16, 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 plug them into core by adding wrapper functions for
> vblank handling co
Hi Jyri,
Thank you for the patch.
On Tuesday 07 Feb 2017 16:41:20 Jyri Sarha wrote:
> Let's disable all scaling that requires horizontal decimation with
> higher factor than 4, until we have better estimates of what we can
> and can not do. However, 1 byte per pixel color format appear to work
>
On Tue, 2017-02-07 at 14:52 -0200, Fabio Estevam wrote:
> Hi Philipp,
>
> On Tue, Feb 7, 2017 at 2:45 PM, Philipp Zabel wrote:
>
> > I've applied this to the fixes branch, since the current device trees
> > don't have the regulator set.
>
> I have sent a patch providing the dac-supply regulator
On Tue, 2017-02-07 at 18:09 +0100, Lucas Stach wrote:
> Am Dienstag, den 07.02.2017, 17:45 +0100 schrieb Philipp Zabel:
> > On Fri, 2017-02-03 at 10:52 -0200, Fabio Estevam wrote:
> > > Hi Philipp,
> > >
> > > On Tue, Jan 3, 2017 at 5:11 PM, Fabio Estevam wrote:
> > > > From: Fabio Estevam
> > >
On Wed, Feb 08, 2017 at 02:46:01AM +0300, Dan Carpenter wrote:
> Having "ret" be a bool type works for everything except
> ret = funcs->atomic_check(). The other functions all return zero on
> error but ->atomic_check() returns negative error codes. We want to
> propagate the error code but inste
Hi Dan,
Thanks for the report.
On Wed, Feb 08, 2017 at 09:39:51AM +0300, Dan Carpenter wrote:
> Hello Shawn Guo,
>
> The patch 4e986d3705df: "drm: zte: add overlay plane support" from
> Nov 16, 2016, leads to the following static checker warning:
>
> drivers/gpu/drm/zte/zx_plane.c:170 zx_
92 matches
Mail list logo