Hi Dave,
Just two minor fixes this time around.
--
Stefan
The following changes since commit 4eaa39c63caf535dc1a8cc43b9a8677a100c09e1:
Merge branch 'drm-rockchip-next-2017-02-07' of
https://github.com/markyzq/kernel-drm-rockchip into drm-next (2017-02-08
11:28:19 +1000)
are available in th
On Wed, Feb 8, 2017 at 1:45 AM, Mark yao wrote:
> On 2017年02月08日 00:14, Sean Paul wrote:
>>
>> On Sun, Feb 05, 2017 at 03:36:36PM +0800, Mark Yao wrote:
>>>
>>> drm crtc already has mode_fixup callback to can do mode check, but
>>> We actually want to valid display mode on connector getmode time,
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_PIXDATA_NEGEDGE means
>>> the controller drives the
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
Currently the framebuffer content is displayed wit
On Wed, Feb 8, 2017 at 1:33 AM, Eric Anholt wrote:
> Andrzej Pietrasiewicz writes:
>
>> When drm_crtc_init_with_planes() was orignally added
>> (in drm_crtc.c, e13161af80c185ecd8dc4641d0f5df58f9e3e0af
>> drm: Add drm_crtc_init_with_planes() (v2)), it only checked for "primary"
>> being non-null.
Oh. Also this one:
drivers/gpu/drm/zte/zx_plane.c:253 zx_vl_plane_atomic_update()
warn: always true condition '(fmt >= 0) => (0-u32max >= 0)'
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.fre
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_vl_rsz_setup()
warn: always true condition '(fmt >= 0) => (0-u32max >= 0)'
drivers/gpu/drm/zte/zx
https://bugs.freedesktop.org/show_bug.cgi?id=99710
--- Comment #3 from garththei...@hotmail.com ---
Created attachment 129409
--> https://bugs.freedesktop.org/attachment.cgi?id=129409&action=edit
lspci output
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99710
--- Comment #2 from garththei...@hotmail.com ---
GPU: XFX R9 390
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
https://bugs.freedesktop.org/show_bug.cgi?id=99710
--- Comment #1 from garththei...@hotmail.com ---
Created attachment 129408
--> https://bugs.freedesktop.org/attachment.cgi?id=129408&action=edit
Xorg.log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99710
Bug ID: 99710
Summary: [amdgpu R9 390] GPU hang when playing Hearthstone in
Wine
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Dave, Marek,
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_PIXDATA_NEGEDGE means
>> the controller drives the data on pixel clocks falling edge.
>> That i
On 2016-12-28 08:48, Fabio Estevam wrote:
> From: Fabio Estevam
>
> When devm_kzalloc() fails there is no need to assign an error code
> to the 'ret' variable as it will not be used after jumping to the
> 'err_node_put' label, so just remove the assignment.
>
> Signed-off-by: Fabio Estevam
App
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_crtc_funcs should be used instead.
>
> Signed-off-by: Shawn Guo
> Cc: Ste
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
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 v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
.../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchi
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
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 v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c
Signed-off-by: Chris Zhong
Acked-by: Rob Herring
---
Changes in v6: None
Changes in v5: None
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/
correct the coding style, according the checkpatch scripts
Signed-off-by: Chris Zhong
Reviewed-by: Sean Paul
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 29 ++---
1 file changed, 14 insert
Reference the power domain incase dw-mipi power down when
in use.
Signed-off-by: Chris Zhong
Reviewed-by: Sean Paul
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16
1 file changed, 16 insertions(+
https://bugs.freedesktop.org/show_bug.cgi?id=99444
--- Comment #19 from Shmerl ---
(In reply to Samuel Pitoiset from comment #16)
> Does the following patch help?
>
> https://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=dfe111368d11aaffae7f8738c858c335cdec1e9d
>
> It actually fixes the glActive
On 2017年02月07日 20:38, Thierry Reding wrote:
On Tue, Feb 07, 2017 at 04:35:35PM +0800, Mark Yao wrote:
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 la
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;
>>> + int ret;
>>> +
>>> + ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status);
>>> + if (re
Hi Shawn,
On Tue, 2017-02-07 at 17:16 +0800, Shawn Guo wrote:
> 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
On 02/01/2017 06:19 PM, Fabio Estevam wrote:
> Currently when the 'power-supply' regulator is passed via device tree
> it does not actually work since drm_panel_prepare()/drm_panel_enable()
> are never called.
>
> Quoting Thierry Reding: "It should really call drm_panel_prepare() and
> drm_panel_e
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
>>>
>>> Currently the framebuffer content is displayed with incorrect offsets
>>> in both the vertical and horizontal
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 child of dsi. So
> removed the ports and moved burst, esc clock-frequ
Hi Shashank,
Sorry for the late review.
On 06-02-2017 13:59, Shashank Sharma wrote:
> From: Thierry Reding
>
> SCDC is a mechanism defined in the HDMI 2.0 specification that allows
> the source and sink devices to communicate.
>
> This commit introduces helpers to access the SCDC and provides
On 02/02/2017 10:26 PM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Currently the framebuffer content is displayed with incorrect offsets
> in both the vertical and horizontal directions.
>
> The fbdev version of the driver does not show this problem. Breno Lima
> dumped the eLCDIF controller
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
> From: Thierry Reding
>
> This patch implements a small function that finds if a
> given CEA db is hdmi-forum vendor specific data block
> or not.
>
> Signed-off-by: Thierry Reding
> Signed-off-by: Shashank Sharma
Reviewed-by: Jose Ab
On Tue, Feb 07, 2017 at 12:42:15PM +0200, Laurent Pinchart wrote:
> On an unrelated note, for security reasons we should try to make the driver
> structure static, or at least move ops to a static structure.
ITYM "const" not "static".
"static" doesn't get you anything from a security point of vi
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
> This structure will be used to save and indicate if sink
> supports advanced HDMI 2.0 features
> - Adds another structure drm_scdc within drm_
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 patch adds few new functions in drm layer for
> core drivers to enable/disable scrambling.
>
> This patch adds:
> - A function to detect scrambling
On Tue, Feb 07, 2017 at 05:16:18PM +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. As the result,
> f
On Tue, Feb 07, 2017 at 05:16:14PM +0800, Shawn Guo wrote:
For:
> drivers/gpu/drm/armada/armada_drv.c | 1 -
Acked-by: Russell King
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #67 from Michel Dänzer ---
The patch forces most buffers to GTT, which is clearly a bad idea with a
dedicated GPU.
Marek, what theory did you want to test with this patch?
--
You are receiving this mail because:
You are on the CC l
On 7 February 2017 at 14:49, Chris Wilson wrote:
> On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote:
>> On 7 February 2017 at 14:29, Daniel Vetter wrote:
>> > Noticed that everyone duplicates the same logic here and we could safe
>> > a few lines per driver. Yay for lots of drivers to
On Tue, Feb 7, 2017 at 9:36 PM, Rob Herring wrote:
> Except I have no way of knowing whether: a) you omitted a supply
> because you don't (yet) care, b) the panel has a single supply and you
> are using power-supply or c) the panel has multiple supplies and your
> binding is wrong.
>
> I can only
On 2017年02月08日 00:14, Sean Paul wrote:
On Sun, Feb 05, 2017 at 03:36:36PM +0800, Mark Yao wrote:
drm crtc already has mode_fixup callback to can do mode check, but
We actually want to valid display mode on connector getmode time,
mode_fixup can't do it.
So add a private mode_valid callback to r
On 07/02/17 10:16 PM, Dan Carpenter wrote:
> If "rdev->bios" is NULL then we don't need to free it.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
> b/drivers/gpu/drm/radeon/radeon_bios.c
> index 00cfb5d2875f..04c0ed41374f 100644
> --- a/drivers/gpu/drm/r
Andrzej Pietrasiewicz writes:
> When drm_crtc_init_with_planes() was orignally added
> (in drm_crtc.c, e13161af80c185ecd8dc4641d0f5df58f9e3e0af
> drm: Add drm_crtc_init_with_planes() (v2)), it only checked for "primary"
> being non-null. If that was the case, it modified primary->possible_crtcs.
On 2017年02月07日 20:19, Thierry Reding wrote:
On Tue, Feb 07, 2017 at 04:35:38PM +0800, Mark Yao wrote:
drm_mm_insert_node_generic and drm_mm_remove_node may access same
resource with list ops, it's not threads safe, so protect this context
with mutex lock.
Fix bug:
[49451.856244]
==
Colin King writes:
> From: Colin Ian King
>
> If dsi_connector fails to allocate, the exit path via label 'fail'
> checks if connector is null, which it always is, so the cleanup
> that destroys connector is never going to be called. Hence the
> failure path can be more optimally performed by r
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 instead we return 1.
I found this bug with static analysis and I don't know
On Tue, Feb 7, 2017 at 12:55 PM, Fabio Estevam wrote:
> Hi Rob,
>
> On Tue, Feb 7, 2017 at 4:49 PM, Rob Herring wrote:
>
>> No power supply(ies) for this panel?
>
> power-supply is mentioned in simple-panel.txt.
>
>>> +This binding is compatible with the simple-panel binding, which is
>>> speci
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
> >
> > Currently the framebuffer content is displayed with incorrect offsets
> > in both the vertical and horizontal directions.
> >
> > The fbdev version of the d
https://bugs.freedesktop.org/show_bug.cgi?id=98634
--- Comment #2 from Humberto Israel Perez Rodriguez
---
the issue still occurs with the following configuration on SKL
==
Software
==
kernel version
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #66 from Captain Crutches ---
I'm having the same results as everyone else with the patch: hanging seems
diminished, FPS down noticeably (in multiplayer, not free play) but still
playable.
Patched mesa 17.0_rc2
R9 290
--
You are re
From: Boris Brezillon
These are optional, but necessary for HDMI audio support.
Signed-off-by: Boris Brezillon
Signed-off-by: Eric Anholt
---
Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/dis
The HDMI encoder IP embeds all needed blocks to output audio, with a
custom DAI called MAI moving audio between the two parts of the HDMI
core. This driver now exposes a sound card to let users stream audio
to their display.
Using the hdmi-codec driver has been considered here, but MAI meant
havi
From: Boris Brezillon
Add the dmas and dma-names properties to support HDMI audio.
Signed-off-by: Boris Brezillon
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm283x.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
https://bugs.freedesktop.org/show_bug.cgi?id=98869
--- Comment #18 from cosiek...@o2.pl ---
I have compiled couple of times. Here are my results.
b7da8fa11d5c6ec71113350eed1959191a7d5990 working
84b961dd53a0509a6865d8417301838b34a40096 working
e54b2e902aba22f697c0ba8622cd0a905f1edfff working
172b
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:
>
> https://www.x.org/wiki/DRMJanitors/
>
> The goal is to trac
Hi Rob,
On Tue, Feb 7, 2017 at 4:49 PM, Rob Herring wrote:
> No power supply(ies) for this panel?
power-supply is mentioned in simple-panel.txt.
>> +This binding is compatible with the simple-panel binding, which is specified
>> +in simple-panel.txt in this directory.
and this doc refers to
On Thu, Feb 02, 2017 at 06:04:00PM -0200, Breno Lima wrote:
> Add support for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480)
> TFT with Touch-Panel, which can be supported by the simple panel driver.
>
> Data-sheet available at:
> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf
>
> Signe
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #65 from andrei.demin1...@gmail.com ---
> Got it tested on another system with a rx470.
>The hangs are mostly gone, but fps drops from 60+ to ~25. (btw the patch was
>>applied to mesa 13.0.0.4)
Yep, same. FPS drops from 60+ to 30-40 F
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:
https://www.x.org/wiki/DRMJanitors/
The goal is to track a list of refactorings that would be nice to see
merged eventually. Sometime
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
> > >
> > > Commit deb65870b5d9d ("drm/imx: imx-tve: check the value re
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #64 from freedesk...@bremsspur.org ---
Got it tested on another system with a rx470.
The hangs are mostly gone, but fps drops from 60+ to ~25. (btw the patch was
applied to mesa 13.0.0.4)
--
You are receiving this mail because:
You a
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 for imx53-qsb:
https://git.kernel.org/cgit/linux/kernel/git/shawnguo/li
Add a custom CRTC state struct to enable storing driver-private per-CRTC
state. This patch only adds the base drm_crtc_state struct.
Signed-off-by: Mihail Atanassov
Reviewed-by: Brian Starkey
Acked-by: Liviu Dudau
---
Link to v2: https://lkml.org/lkml/2017/2/1/378
Link to v1: https://lkml.org/l
Add gamma via the DRM GAMMA_LUT/GAMMA_LUT_SIZE CRTC
properties. The expected LUT size is 4096 in order
to produce as accurate a set of segments as possible.
This version uses only the green channel's gamma curve
to set the hardware curve on DP550/650. For the sake of
simplicity, it uses the same t
On Tue, Feb 07, 2017 at 04:34:44PM +0100, Maxime Ripard wrote:
> On Mon, Feb 06, 2017 at 12:29:31PM +0100, Noralf Trønnes wrote:
> >
> > Den 06.02.2017 11.39, skrev Maxime Ripard:
> > > Hi Noralf,
> > >
> > > On Fri, Feb 03, 2017 at 07:48:51PM +0100, Noralf Trønnes wrote:
> > > > Den 03.02.2017 1
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
> >
> > Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
> > regulator_set_voltage()") exposes the following probe issue:
> >
On Tue, Feb 07, 2017 at 04:44:42PM +0100, Maxime Ripard wrote:
> Hi Thierry,
>
> On Mon, Feb 06, 2017 at 02:05:49PM +0100, Thierry Reding wrote:
> > On Fri, Feb 03, 2017 at 10:59:05AM +0100, Maxime Ripard wrote:
> > > The Sitronix ST7789V is an LCD panel controller, controlled over SPI, that
> > >
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:
> > > - Adds a new structure (drm_hdmi_info) in d
On Tue, Feb 07, 2017 at 05:16:03PM +0100, Daniel Vetter wrote:
> Noticed that everyone duplicates the same logic here and we could safe
> a few lines per driver. Yay for lots of drivers to make such tiny
> refactors worth-while!
>
> v2: Forgot to git add everything :(
>
> v3: Actually remove rele
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 patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.
Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!
v2: Forgot to git add everything :(
v3: Actually remove release_fbi (Sean, Emil, Chris) ...
Cc: Chris Wilson
Cc: Sean Paul
Cc: Noralf
On Sun, Feb 05, 2017 at 11:54:10AM +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
On Sun, Feb 05, 2017 at 03:36:36PM +0800, Mark Yao wrote:
> drm crtc already has mode_fixup callback to can do mode check, but
> We actually want to valid display mode on connector getmode time,
> mode_fixup can't do it.
>
> So add a private mode_valid callback to rockchip crtc, connectors can
> c
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:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0
On Tue, Feb 07, 2017 at 02:49:38PM +, Chris Wilson wrote:
> On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote:
> > On 7 February 2017 at 14:29, Daniel Vetter wrote:
> > > Noticed that everyone duplicates the same logic here and we could safe
> > > a few lines per driver. Yay for lot
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: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the so
On Tue, Feb 07, 2017 at 09:34:01AM +0800, Mark Yao wrote:
> fix warning:
>
> drivers/gpu/drm/rockchip/cdn-dp-reg.c:632:24: warning:
> 'val[1]' may be used uninitialized in this function [-Wmaybe-uninitialized]
> msa_misc = 2 * val[0] + 32 * val[1] +
>
> Signed-off-by: Mark Yao
> ---
> drive
Regards
Shashank
On 2/7/2017 3:51 PM, Jani Nikula wrote:
On Mon, 06 Feb 2017, Shashank Sharma wrote:
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprin
On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote:
> Noticed that everyone duplicates the same logic here and we could safe
> a few lines per driver. Yay for lots of drivers to make such tiny
> refactors worth-while!
>
> Cc: Chris Wilson
> Cc: Sean Paul
> Cc: Noralf Trønnes
> Signed
On Mon, Feb 06, 2017 at 02:26:20PM +0100, Thierry Reding wrote:
> > +#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int))
> > +#define st7789v_send(ctx, cmd, ...)
> > \
> > + st7789v_write_command_data(ctx, cmd, NUMARGS(__VA_ARGS__), \
>
Hi Thierry,
On Mon, Feb 06, 2017 at 02:05:49PM +0100, Thierry Reding wrote:
> On Fri, Feb 03, 2017 at 10:59:05AM +0100, Maxime Ripard wrote:
> > The Sitronix ST7789V is an LCD panel controller, controlled over SPI, that
> > can drive 18-bits 240x320 LCD displays.
> >
> > Signed-off-by: Maxime Rip
On Thu, Jan 05, 2017 at 05:14:54PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display engine
> the location of the color control surfae (CCS)
On Tue, Feb 07, 2017 at 05:16:29PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> With the vblank hooks in struct drm_crtc_funcs, we do not need to
> maintain struct rockchip_crtc_funcs and the related registration
> functions. Remove them.
>
Reviewed-by: Sean Paul
> Signed-off-by: Shawn Guo
On Mon, Feb 06, 2017 at 12:29:31PM +0100, Noralf Trønnes wrote:
>
> Den 06.02.2017 11.39, skrev Maxime Ripard:
> > Hi Noralf,
> >
> > On Fri, Feb 03, 2017 at 07:48:51PM +0100, Noralf Trønnes wrote:
> > > Den 03.02.2017 10.59, skrev Maxime Ripard:
> > > > Hi,
> > > >
> > > > Here is an attempt at
On Tue, Feb 07, 2017 at 05:16:35PM +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.
>
> The functions
On Tue, Feb 07, 2017 at 05:16:17PM +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.
>
> Signed-off-by:
On Tue, Feb 07, 2017 at 05:16:14PM +0800, Shawn Guo wrote:
> 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 driv
On Tuesday, 2017-02-07 15:59:32 +0100, Thomas H.P. Andersen wrote:
> On Fri, Feb 3, 2017 at 11:57 AM, Eric Engestrom
> wrote:
> >
> > On Thursday, 2017-02-02 23:57:29 +0100, Thomas Hindoe Paaboel Andersen
> > wrote:
> > > Introduced in 028715ee
> > >
> > > Move the dereference after the null chec
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;
+ int ret;
+
+ ret = drm_scdc_readb(adapte
On Fri, Feb 3, 2017 at 11:57 AM, Eric Engestrom
wrote:
>
> On Thursday, 2017-02-02 23:57:29 +0100, Thomas Hindoe Paaboel Andersen wrote:
> > Introduced in 028715ee
> >
> > Move the dereference after the null check.
>
> Fixes: 028715ee707469189505 ("intel: Avoid the need for most overflow
>
"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
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 3f656e3a6e5a..773a45aa18f8 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++
On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote:
> On 7 February 2017 at 14:29, Daniel Vetter wrote:
> > Noticed that everyone duplicates the same logic here and we could safe
> > a few lines per driver. Yay for lots of drivers to make such tiny
> > refactors worth-while!
> >
> > v2:
https://bugs.freedesktop.org/show_bug.cgi?id=99136
--- Comment #21 from siyia ---
(In reply to Gregor Münch from comment #20)
> (In reply to Samuel Pitoiset from comment #19)
> > Created attachment 129356 [details]
> > no blood effects option (v 1.5)
>
> Maybe you need the Blood DLC? (just wild
On Tue, Feb 07, 2017 at 04:34:57PM +0200, Joonas Lahtinen wrote:
> On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote:
> > If "caps.buf" is already NULL then it doesn't need to be freed or set to
> > NULL.
> >
> > Signed-off-by: Dan Carpenter
>
>
>
> > @@ -965,11 +965,8 @@ static long intel
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 decimating horizontally by more that 4 the dss is not ab
On 7 February 2017 at 14:29, Daniel Vetter wrote:
> Noticed that everyone duplicates the same logic here and we could safe
> a few lines per driver. Yay for lots of drivers to make such tiny
> refactors worth-while!
>
> v2: Forgot to git add everything :(
>
Hmm afaict this patch inlines drm_fb_hel
On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 5220a7b5e6ff..074ab22a7cf3 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -781,7 +781,9 @@ EXPORT_SYMB
On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote:
> If "caps.buf" is already NULL then it doesn't need to be freed or set to
> NULL.
>
> Signed-off-by: Dan Carpenter
> @@ -965,11 +965,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
> unsigned int cmd,
>
Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!
v2: Forgot to git add everything :(
Cc: Chris Wilson
Cc: Sean Paul
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/d
On Tue, Feb 07, 2017 at 03:10:49PM +0100, Daniel Vetter wrote:
> While reviewing Chris' patches to properly cancel our async workers I
> checked that this happens after the fbdev is already unregistered.
> That's the case, but I found a small gap in our docs, fill that in.
>
> Note that I don't ex
Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!
Cc: Chris Wilson
Cc: Sean Paul
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
1 - 100 of 190 matches
Mail list logo
