Am 30.06.2017 um 04:24 schrieb Michel Dänzer:
On 29/06/17 07:05 PM, Daniel Vetter wrote:
On Thu, Jun 29, 2017 at 06:58:05PM +0900, Michel Dänzer wrote:
On 29/06/17 05:23 PM, Christian König wrote:
Am 29.06.2017 um 04:35 schrieb Michel Dänzer:
On 29/06/17 08:26 AM, John Brooks wrote:
On Wed,
On 29/06/17 21:50, Aaro Koskinen wrote:
> Hi,
>
> On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
>> On 15/06/17 01:11, Aaro Koskinen wrote:
>>> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
>>> is no display.
>>
>> Are you sure it doesn't probe? It fails t
Regards
Shashank
On 6/29/2017 5:38 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
To support ycbcr HDMI output, we need a pipe CSC block to
do the RGB->YCBCR conversion, as the blender output is in RGB.
Current Intel platforms have only one p
On Thu, Jun 29, 2017 at 09:54:38PM +0100, Peter Griffin wrote:
> This patch fixes the following soft lockup:
> BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]
>
> On weston idle-timeout the IP is powered down and reset
> asserted. On weston resume we get a massive vblank
> IRQ storm due to
Regards
Shashank
On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for H
Regards
Shashank
On 6/27/2017 5:44 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:13PM +0530, Shashank Sharma wrote:
HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
- RGB
- YCBCR
Regards
Shashank
On 6/27/2017 5:25 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:04PM +0530, Shashank Sharma wrote:
CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
This block contains a map of indexes of CEA modes, which can
support YCBCR 420 output also. To avoid mult
Regards
Shashank
On 6/27/2017 5:23 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:03PM +0530, Shashank Sharma wrote:
CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 dee
Regards
Shashank
On 6/27/2017 5:22 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:02PM +0530, Shashank Sharma wrote:
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 o
Regards
Shashank
On 6/27/2017 5:02 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:01PM +0530, Shashank Sharma wrote:
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 mo
Hi all,
I'm one of the QEMU SPARC maintainers and I've been investigating why
enabling the fb console via the bochs_drm module causes a panic on
startup. The reproducer with QEMU 2.9 is easy:
$ ./qemu-system-sparc64 -m 512 -kernel rel-sparc/vmlinux -append
'console=ttyS0' -serial stdio
This give
https://bugs.freedesktop.org/show_bug.cgi?id=101653
--- Comment #2 from Alexander Tsoy ---
smu7_get_xclk() returns some crazy values when display is off. And this value
depends on some state that changes every boot.
$ sudo journalctl -b -1 -o cat | grep reference_clock | sort | uniq -c
4 a
https://bugs.freedesktop.org/show_bug.cgi?id=101654
Bug ID: 101654
Summary: The Witcher 3: ground is too dark in some areas
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
S
On 29/06/17 07:05 PM, Daniel Vetter wrote:
> On Thu, Jun 29, 2017 at 06:58:05PM +0900, Michel Dänzer wrote:
>> On 29/06/17 05:23 PM, Christian König wrote:
>>> Am 29.06.2017 um 04:35 schrieb Michel Dänzer:
On 29/06/17 08:26 AM, John Brooks wrote:
> On Wed, Jun 28, 2017 at 03:05:32PM +0200,
On 2017-06-29 09:56 PM, John Brooks wrote:
On Thu, Jun 29, 2017 at 11:35:53AM +0900, Michel Dänzer wrote:
On 29/06/17 08:26 AM, John Brooks wrote:
On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
Am 28.06.2017 um 04:33 schrieb John Brooks:
When the AMDGPU_GEM_CREATE_CPU_ACCESS
On Thu, Jun 29, 2017 at 11:35:53AM +0900, Michel Dänzer wrote:
> On 29/06/17 08:26 AM, John Brooks wrote:
> > On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
> >> Am 28.06.2017 um 04:33 schrieb John Brooks:
> >>> When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by users
> @@ -658,10 +660,14 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
> rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);
>
> if (status & DSSR_FRM) {
> - drm_crtc_handle_vblank(&rcrtc->crtc);
> -
> - if (rcdu->info->gen < 3)
> + /*
>
A recent change to the frame completion handling has changed the order
in which the vblank timestamps are updated.
To fix this requires handling the vblank events on the frame end event
which comes from the VSP1 driver on Gen3 instead.
Prevent the CRTC IRQ from being enabled on Gen3 hardware and
A recent change to the frame completion handling has changed the order
in which the vblank timestamps are updated.
To fix this requires handling the vblank events on the frame end event
which comes from the VSP1 driver on Gen3 instead.
Prevent the CRTC IRQ from being enabled on Gen3 hardware and
Allow interval trees to quickly check for overlaps to avoid
unnecesary tree lookups in interval_tree_iter_first().
As of this patch, all interval tree flavors will require
using a 'rb_root_cached' such that we can have the leftmost
node easily available. While most users will make use of this
feat
The recent changes to the rcar-du driver to fix a race condition inadvertently
change the order of which vblanks are reported.
Correct this by handling vblank events in the same completion handler. This
removes the need for the IRQ handler on DU instances which are sourced by a
VSP1.
For other pl
Hi,
On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> On 15/06/17 01:11, Aaro Koskinen wrote:
> > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> > is no display.
>
> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
> check?
It appears
The rcar_du_crtc_{enable,disable}_vblank functions are configured to
control the VBE interrupt event.
The implementation of interlaced support in the rcar-du changes the
required behavior such that vblanks are handled on frame end events, but
does not update the enable register to reflect this.
E
Quoting Alex Deucher :
On Thu, Jun 29, 2017 at 1:38 PM, Gustavo A. R. Silva
wrote:
Add function header comment to make it clear that local variable sw_cg
is used for debugging and it should not be removed.
Addresses-Coverity-ID: 1198635
Cc: Alex Deucher
Signed-off-by: Gustavo A. R. Silva
On Tue 20 Jun 13:16 PDT 2017, Arnd Bergmann wrote:
> In zap_shader_load_mdt(), we pass a pointer to a phys_addr_t
> into dmam_alloc_coherent, which the compiler warns about:
>
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c: In function 'zap_shader_load_mdt':
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c:54:50
Hi Maxime,
On 30 June 2017 at 01:56, Maxime Ripard
wrote:
> On Wed, Jun 28, 2017 at 08:39:33PM +1000, Jonathan Liu wrote:
>> >> + u32 int_status;
>> >> + u32 fifo_status;
>> >> + /* Read needs empty flag unset, write needs full flag unset */
>> >> + u32 flag = read ? SUN4I_HDMI_DD
Following compilation warnings were observed for these files:
CC [M] drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.o
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c: In function 'blend_setup':
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:223:7: warning: missing braces around
initializer [-Wmissing-braces]
enu
This patch fixes the following soft lockup:
BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]
On weston idle-timeout the IP is powered down and reset
asserted. On weston resume we get a massive vblank
IRQ storm due to the LDI registers having lost some state.
This state loss is caused by ade
Hi,
On Thu, Jun 29, 2017 at 09:50:13PM +0300, Aaro Koskinen wrote:
> On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> > On 15/06/17 01:11, Aaro Koskinen wrote:
> > > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> > > is no display.
> >
> > Are you sure i
On Tue 20 Jun 13:16 PDT 2017, Arnd Bergmann wrote:
> When compile-testing for something other than ARCH_QCOM,
> we run into a link error:
>
> drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_hw_init':
> a5xx_gpu.c:(.text.a5xx_hw_init+0x600): undefined reference to
> `qcom_mdt_get_size'
>
Hi,
On Wed, Jun 28, 2017 at 6:52 PM, Jonathan Liu wrote:
> The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states:
> "As in the general case the DDC bus is accessible by the kernel at the I2C
> level, drivers must make all reasonable efforts to expose it as an I2C
> adapter an
Add function header comment to make it clear that local variable sw_cg
is used for debugging and it should not be removed.
Addresses-Coverity-ID: 1198635
Cc: Alex Deucher
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/radeon/vce_v2_0.c | 4
1 file changed, 4 insertions(+)
diff --g
Hi Chen-Yu,
On 29 June 2017 at 12:47, Chen-Yu Tsai wrote:
> Hi,
>
> On Wed, Jun 28, 2017 at 6:52 PM, Jonathan Liu wrote:
>> The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states:
>> "As in the general case the DDC bus is accessible by the kernel at the I2C
>> level, drivers
https://bugs.freedesktop.org/show_bug.cgi?id=101653
--- Comment #1 from Alexander Tsoy ---
It looks like actual FAN speed doesn't change. It's just reported differently.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-
Hello Christian,
I've running this since you've sent it on-top of amd-staging-4.11. But I
think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 (Nehalem),
PCIe 2.0, 24 GB is to old for this stuff...
[1.066475] pci :05:00.0: VF(n) BAR0 space: [mem
0x-0x0003 64bit] (co
https://bugs.freedesktop.org/show_bug.cgi?id=101653
Bug ID: 101653
Summary: FAN speed is too high when displays are off
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: norma
ied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbdev-locking-rework-and-deferred-setup-take-2/20170629-075405
base: git://people.freedesktop.org/~airlied/linux.git drm-next
:: branch date: 18 hou
Hi,
2017-06-29 Sean Paul :
> On Thu, Jun 29, 2017 at 01:59:24PM +0100, Chris Wilson wrote:
> > Often we have the task of comparing two seqno known to be on the same
> > context, so provide a common __dma_fence_is_later().
> >
> > Signed-off-by: Chris Wilson
> > Cc: Sumit Semwal
> > Cc: Sean Pa
Reviewed-by: Clinton Taylor
-Clint
On 06/29/2017 02:34 PM, Rodrigo Vivi wrote:
By the Spec all CNL Y skus are 2+2, i.e. GT2.
This is a copy of merged i915's
commit 95578277cbdb ("drm/i915/cnl: Add Cannonlake PCI IDs for Y-skus.")
v2: Add kernel commit id for reference.
Cc: Anusha Srivatsa
Reviewed-by: Clinton Taylor
-Clint
On 06/29/2017 02:34 PM, Rodrigo Vivi wrote:
Platform enabling and its power-on are organized in different
skus (U x Y x S x H, etc). So instead of organizing it in
GT1 x GT2 x GT3 let's also use the platform sku.
This is a copy of merged i915's
commit e918
https://bugs.freedesktop.org/show_bug.cgi?id=101528
--- Comment #4 from Alexander Tsoy ---
(In reply to Alex Deucher from comment #3)
> Created attachment 132358 [details] [review]
> possible fix
This patch fixes this bug for me. Thank you!
[ 359.229187] AMDGPU: vblank_time_us: 630, switch_lim
From: Ben Widawsky
This got lost on rebase, I believe
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 2 ++
intel/intel_decode.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 45a26da..71f140f 100
Platform enabling and its power-on are organized in different
skus (U x Y x S x H, etc). So instead of organizing it in
GT1 x GT2 x GT3 let's also use the platform sku.
This is a copy of merged i915's
commit e918d79a5d0a ("drm/i915/cnl: Add Cannonlake PCI IDs for U-skus.")
v2: Remove PCI IDs for
From: Paulo Zanoni
As far as I understand, IS_9XX should return true for it.
Signed-off-by: Paulo Zanoni
---
intel/intel_chipset.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 37579c6..770d21f 100644
--- a/intel/intel
By the Spec all CNL Y skus are 2+2, i.e. GT2.
This is a copy of merged i915's
commit 95578277cbdb ("drm/i915/cnl: Add Cannonlake PCI IDs for Y-skus.")
v2: Add kernel commit id for reference.
Cc: Anusha Srivatsa
Cc: Clinton Taylor
Signed-off-by: Rodrigo Vivi
---
intel/intel_chipset.h | 16 +++
Reduce the list iteration when incrementing the timeline by storing the
fences in increasing order.
v2: Prevent spinlock recursion on free during create
v3: Fixup rebase conflict inside comments that escaped the compiler.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo P
On Thu, Jun 29, 2017 at 1:54 PM, Peter Griffin wrote:
> This patch fixes the following soft lockup:
> BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]
>
> On weston idle-timeout the IP is powered down and reset
> asserted. On weston resume we get a massive vblank
> IRQ storm due to the LDI r
Reduce the list iteration when incrementing the timeline by storing the
fences in increasing order.
v2: Prevent spinlock recursion on free during create
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 49 ++
The sync_pt were not adding themselves atomically to the timeline lists,
corruption imminent. Only a single list is required to track the
unsignaled sync_pt, so reduce it and rename the lock more appropriately
along with using idiomatic names to distinguish a list from links along
it.
v2: Prevent
https://bugs.freedesktop.org/show_bug.cgi?id=101528
--- Comment #3 from Alex Deucher ---
Created attachment 132358
--> https://bugs.freedesktop.org/attachment.cgi?id=132358&action=edit
possible fix
--
You are receiving this mail because:
You are the assignee for the bug.__
On Thu, Jun 29, 2017 at 01:59:24PM +0100, Chris Wilson wrote:
> Often we have the task of comparing two seqno known to be on the same
> context, so provide a common __dma_fence_is_later().
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Sean Paul
Hi Chris,
Thanks for writing the code
On Fri, Jun 23, 2017 at 09:45:44AM -0700, Ben Widawsky wrote:
> v2:
> Support sprite plane.
> Support pipe C/D limitation on GEN9.
>
> This requires rebase on the correct Ville patches
>
> Cc: Daniel Stone
> Cc: Kristian Høgsberg
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/inte
On Fri, Jun 23, 2017 at 09:45:43AM -0700, Ben Widawsky wrote:
> This was based on a patch originally by Kristian. It has been modified
> pretty heavily to use the new callbacks from the previous patch.
>
> v2:
> - Add LINEAR and Yf modifiers to list (Ville)
> - Combine i8xx and i965 into one l
Rob,
On Wed, Jun 14, 2017 at 2:49 PM, Thierry Reding
wrote:
>> +Required properties:
>> +- compatible: should be "sii,43wvf1g".
>> +- "DVDD-supply": 3v3 digital regulator.
>> +- "AVDD-supply": 5v analog regulator.
>
> I don't think we should be using all-uppercase for supply names. So the
> abov
On Fri, Jun 23, 2017 at 09:45:42AM -0700, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
>
> v2:
> * Removed __packed, and alignment (.+)
> * Fix indent in drm_format_modifier fields (Liviu)
> * Remove duplicated modifier > 64 check (Liviu)
> * Change comment about modifi
https://bugs.freedesktop.org/show_bug.cgi?id=101528
--- Comment #2 from Alexander Tsoy ---
I've added printing of some debug info into smu7_hwmgr.c and here what I get
before GPU enters that state:
[ 778.701843] AMDGPU: vblank_time_us: 630, switch_limit_us: 450
[ 778.707608] AMDGPU:
On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote:
> Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42)
> > From: Ville Syrjälä
> >
> > Introduce an rw_semaphore to protect the display commits. All normal
> > commits use down_read() and hence can proceed in parallel, but GPU r
On Thu, Jun 29, 2017 at 1:38 PM, Gustavo A. R. Silva
wrote:
> Add function header comment to make it clear that local variable sw_cg
> is used for debugging and it should not be removed.
>
> Addresses-Coverity-ID: 1198635
> Cc: Alex Deucher
> Signed-off-by: Gustavo A. R. Silva
Applied. thanks!
Quoting Sean Paul (2017-06-29 19:10:11)
> On Thu, Jun 29, 2017 at 01:59:30PM +0100, Chris Wilson wrote:
> > Reduce the list iteration when incrementing the timeline by storing the
> > fences in increasing order.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Sumit Semwal
> > Cc: Sean Paul
> > Cc:
https://bugs.freedesktop.org/show_bug.cgi?id=95269
Ricardo Madrigal changed:
What|Removed |Added
Summary|monitors connected to |[DP] monitors connected to
https://bugs.freedesktop.org/show_bug.cgi?id=95269
Ricardo Madrigal changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Resolution|WORKSFORME
On Thu, Jun 29, 2017 at 01:59:30PM +0100, Chris Wilson wrote:
> Reduce the list iteration when incrementing the timeline by storing the
> fences in increasing order.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Sean Paul
> Cc: Gustavo Padovan
> ---
> drivers/dma-buf/sw_sync.c|
https://bugs.freedesktop.org/show_bug.cgi?id=101651
--- Comment #3 from Vadim Girlin ---
Created attachment 132357
--> https://bugs.freedesktop.org/attachment.cgi?id=132357&action=edit
reduced test
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=101651
--- Comment #2 from Vadim Girlin ---
Created attachment 132356
--> https://bugs.freedesktop.org/attachment.cgi?id=132356&action=edit
llvm patch
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=101651
--- Comment #1 from Vadim Girlin ---
Created attachment 132355
--> https://bugs.freedesktop.org/attachment.cgi?id=132355&action=edit
screenshot (correct rendering)
--
You are receiving this mail because:
You are the assignee for the bug.
Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42)
> From: Ville Syrjälä
>
> Introduce an rw_semaphore to protect the display commits. All normal
> commits use down_read() and hence can proceed in parallel, but GPU reset
> will use down_write() making sure no other commits are in progres
https://bugs.freedesktop.org/show_bug.cgi?id=101651
Bug ID: 101651
Summary: [radeonsi][hawaii] Borderlands 2 rendering issues with
recent mesa/llvm
Product: Mesa
Version: git
Hardware: Other
OS: All
series merged to libdrm. thanks for patches and review.
On Wed, Jun 28, 2017 at 2:09 PM, Clint Taylor
wrote:
>
>
> On 06/21/2017 09:39 AM, Anusha Srivatsa wrote:
>>
>> Add the PCI IDs for U SKU IN CFL by following the spec.
>>
>> v2: Update IDs
>>
>> Cc: Rodrigo Vivi
>> Signed-off-by: Anusha Sri
https://bugs.freedesktop.org/show_bug.cgi?id=101528
--- Comment #1 from Alexander Tsoy ---
Same problem with TONGA. When GPU is idle, mclk goes to its maximum. This is
easily reproducible: just turn off the monitor. I noticed this issue after
upgrade from 4.9.x kernels to 4.11.7. Maybe I'll check
Quoting Sean Paul (2017-06-29 18:22:10)
> On Thu, Jun 29, 2017 at 01:59:29PM +0100, Chris Wilson wrote:
> > The sync_pt were not adding themselves atomically to the timeline lists,
> > corruption imminent. Only a single list is required to track the
> > unsignaled sync_pt, so reduce it and rename
On Thu, Jun 29, 2017 at 01:59:29PM +0100, Chris Wilson wrote:
> The sync_pt were not adding themselves atomically to the timeline lists,
> corruption imminent. Only a single list is required to track the
> unsignaled sync_pt, so reduce it and rename the lock more appropriately
> along with using i
https://bugs.freedesktop.org/show_bug.cgi?id=95269
--- Comment #4 from Ricardo Madrigal ---
Hello,
I just tried to reproduce the problem with following configuration:
BDW NUC, using an MST dongle emulating docking station and two external
monitors, one connected via DVI and the other one via DP
https://bugs.freedesktop.org/show_bug.cgi?id=95269
Ricardo Madrigal changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEEDINF
Hi,
On Wed, Jun 28, 2017 at 08:52:24PM +1000, Jonathan Liu wrote:
> The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states:
> "As in the general case the DDC bus is accessible by the kernel at the I2C
> level, drivers must make all reasonable efforts to expose it as an I2C
> ad
On Wed, Jun 28, 2017 at 08:39:33PM +1000, Jonathan Liu wrote:
> >> + u32 int_status;
> >> + u32 fifo_status;
> >> + /* Read needs empty flag unset, write needs full flag unset */
> >> + u32 flag = read ? SUN4I_HDMI_DDC_FIFO_STATUS_EMPTY :
> >> + SUN4I_HDMI_DDC_
Andrzej Hajda writes:
> On 29.06.2017 07:03, Archit Taneja wrote:
>>
>> On 06/28/2017 01:28 AM, Eric Anholt wrote:
>>> When a mipi_dsi_host is registered, the DT is walked to find any child
>>> nodes with compatible strings. Those get registered as DSI devices,
>>> and most DSI panel drivers are
On 06/28/2017 08:44 AM, Archit Taneja wrote:
>
>
> On 06/19/2017 09:58 PM, Philippe CORNU wrote:
>> Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the
>> Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
>>
>> Signed-off-by: Philippe CORNU
>> ---
>> dr
From: Ville Syrjälä
Introduce an rw_semaphore to protect the display commits. All normal
commits use down_read() and hence can proceed in parallel, but GPU reset
will use down_write() making sure no other commits are in progress when
we have to pull the plug on the display engine on pre-g4x platf
On Thu, Jun 29, 2017 at 04:57:25PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
> > Signed-off-by: Maarten Lankhorst
> > ---
> > drivers/gpu/drm/drm_framebuffer.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/dr
On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_framebuffer.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index fc8ef42203ec..
Quoting ville.syrj...@linux.intel.com (2017-06-29 14:49:48)
> @@ -2640,15 +2600,13 @@ static void i915_reset_device(struct drm_i915_private
> *dev_priv)
> char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
> char *reset_event[] = { I915_RESET_UEVENT "=1", NULL };
> cha
From: Ville Syrjälä
Introduce an rw_semaphore to protect the display commits. All normal
commits use down_read() and hence can proceed in parallel, but GPU reset
will use down_write() making sure no other commits are in progress when
we have to pull the plug on the display engine on pre-g4x platf
From: Ville Syrjälä
I set out to fix the pre-g4x GPU reset by protecting display commits with
an rw_semaphore. I originally went all out and added infrastructure to track
the committed state (as opposed the latest swapped state), but Daniel suggested
that we want to backport the thing so I simpl
From: Ville Syrjälä
Pull the code to reallocate the state->connectors[] array into a
helper function. We'll have another use for this later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 43 +--
include/drm/drm_atomic.h | 5 +
From: Ville Syrjälä
For i915 GPU reset handling we'll want to be able to duplicate the state
that was last committed to the hardware. For that purpose let's provide
a helper function that is supposed to duplicate the state last committed
to the hardware. For now we'll actually just duplicate the
From: Ville Syrjälä
To avoid having to deference plane_state->vma during the commit phase of
plane updates, let's store the vma gtt offset (or the bus address when
we need it) in the plane state. This is crucial for doing the modeset
operations during GPU reset as as plane_state->vma gets cleared
From: Ville Syrjälä
Split intel_atomic_commit_tail() into a lower level function that does
the actual commit, and a higher level one that waits for the
dependencies and signals the commit as done. We'll reuse the lower
level function to perform commits during GPU resets.
Signed-off-by: Ville Syr
-Original Message-
From: Mark Brown [mailto:broo...@kernel.org]
Sent: Wednesday, June 28, 2017 11:36 PM
To: Alex Deucher
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
alsa-de...@alsa-project.org; airl...@gmail.com; Mukunda, Vijendar;
rajeevkumar.li...@gmail.com; lg
For the vmwgfx part:
Reviewed-by: Thomas Hellstrom
On 06/27/2017 11:16 PM, Laurent Pinchart wrote:
The CRTC .disable() helper operation is deprecated for atomic drivers,
the new .atomic_disable() helper operation being preferred. Convert all
atomic drivers to .atomic_disable() to avoid cargo
For the vmwgfx part:
Reviewed-by: Thomas Hellstrom
On 06/27/2017 11:16 PM, Laurent Pinchart wrote:
The old state is useful for drivers that need to perform operations at
enable time that depend on the transition between the old and new
states.
While at it, rename the operation to .atomic_en
Reviewed-by: Thomas Hellstrom
On 06/27/2017 11:16 PM, Laurent Pinchart wrote:
The CRTC .prepare() helper operation is part of the legacy helpers and
is deprecated in favour of the .disable() helper operation. As the
vmwgfx driver provides a .disable() helper operation, and as the
.prepare() hel
Reviewed-by: Thomas Hellstrom
On 06/27/2017 11:16 PM, Laurent Pinchart wrote:
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. Replace the .commit() helper operation
with .enable() in the driver.
Signed-off-by: Laurent Pinchart
---
driv
Often we have the task of comparing two seqno known to be on the same
context, so provide a common __dma_fence_is_later().
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
include/linux/dma-fence.h | 15 ++-
1 file changed, 14 insertions(+), 1 del
Reduce the list iteration when incrementing the timeline by storing the
fences in increasing order.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 49 ++--
drivers/dma-buf/sync_debug.h |
The sync_pt were not adding themselves atomically to the timeline lists,
corruption imminent. Only a single list is required to track the
unsignaled sync_pt, so reduce it and rename the lock more appropriately
along with using idiomatic names to distinguish a list from links along
it.
Signed-off-
The timeline is u32, which limits any single advance to INT_MAX so that
we can detect all fences that need signaling.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/d
Since sync_pt is only allocated from a single location and is no longer
the base class for fences (that is struct dma_fence) it no longer needs
a generic unsized allocator.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c | 12 --
Use the canonical __dma_fence_is_later() to compare the fence seqno
against the timeline seqno to check if the fence is signaled.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
If we know the context under which we are called, then we can use the
simpler form of spin_lock_irq (saving the save/restore).
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 15 +--
drivers/dma-buf/sync_debug.c | 1
On Thu, Jun 29, 2017 at 03:37:20PM +0300, Laurent Pinchart wrote:
> Commit 3fcdcb270936 ("drm/vblank: Switch to bool in_vblank_irq in
> get_vblank_timestamp") inverted a condition by mistake that resulted in
> vblank timestamps always being 0 on hardware without a vblank counter.
> Fix it.
>
> Fix
1 - 100 of 140 matches
Mail list logo
