On Wed, 24 May 2017, "Chauhan, Madhav" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Wednesday, May 24, 2017 7:22 PM
>> To: Chauhan, Madhav ; Ville Syrjälä
>>
>> Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
>> ; Hiremath, Shashidhar
>>
>> Subject: RE: [
On Wed, 24 May 2017, Tvrtko Ursulin wrote:
> On 23/05/2017 22:58, kai.c...@intel.com wrote:
>> From: Kai Chen
>>
>> This is a follow-up patch to the previous patch ([PATCH[1/2] drm/i915:
>> Disable decoupled MMIO) to remove the dead code for decoupled MMIO
>> implementation, as it won't be used a
On 05/29/2017 09:00 PM, Daniel Vetter wrote:
On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
On 05/26/2017 09:15 AM, Daniel Vetter wrote:
Did you look into also wiring this up for dp mst chains?
Isn't this sufficient? I have no way of testing mst chains.
I think I need some poi
On Tue, 30 May 2017, Hans Verkuil wrote:
> On 05/29/2017 09:00 PM, Daniel Vetter wrote:
>> On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
>>> On 05/26/2017 09:15 AM, Daniel Vetter wrote:
Did you look into also wiring this up for dp mst chains?
>>>
>>> Isn't this sufficient? I h
On 05/24/2017 11:28 AM, Daniel Vetter wrote:
> We can't check this when applying (since r-b/a-b tags often get added
> afterwards), but we can check this when pushing. This only looks at
> patches authored by the pusher.
>
> Also update the docs to highlight that review requirements hold
> especia
On 05/24/2017 04:51 PM, Daniel Vetter wrote:
> And document them lightly. Unfortunately kernel-doc isn't the most
> awesome for documenting #defines that don't look like functions, it
> makes functions out of them :-/
>
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drmP.h | 17
On 05/24/2017 04:51 PM, Daniel Vetter wrote:
> This is a leftover from the drm_bus days, where we've had a
> bus-specific device type for every bus type in drm_device. Except for
> pci (which we can't remove because dri1 drivers) this is all gone. And
> the virt driver also doesn't really need it,
On 05/24/2017 04:51 PM, Daniel Vetter wrote:
> The kernel doc explained what needs to happen, but not how to most
> easily accomplish that using the functions. Fix that.
>
> Cc: Boris Brezillon
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drm_crtc.h | 4 +++-
> 1 file changed, 3 insertion
On to, 2017-05-25 at 21:48 +0100, Chris Wilson wrote:
> Add kerneldoc for the vma_list stored on the i915_gem_object, in
> particular, documenting the expected ordering of elements -- i.e. that
> we do expect GGTT VMA first followed by the ppGTT VMA.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas L
Hey,
Op 29-05-17 om 21:34 schreef Daniel Vetter:
> In the conversion to drop drm_modeset_lock_all and the magic implicit
> context I failed to realize that _resume starts out with a pile of
> state copies, but not with the locks. And hence drm_atomic_commit
> won't grab these for us.
>
> Cc: Jyri
On pe, 2017-05-26 at 11:13 +, Michal Wajdeczko wrote:
> In earlier patch 789a625 we were enabling send function only
> after successful init. For completeness, we should make sure
> that we disable it on fini.
>
> v2: don't group steps by submission flag (Chris)
>
> Signed-off-by: Michal Wajd
On ma, 2017-05-22 at 16:19 +0800, Tina Zhang wrote:
> Enable the guest i915 full ppgtt functionality when host can provide this
> capability. vgt_caps is introduced to guest i915 driver to get the vgpu
> capabilities from the device model. VGT_CPAS_FULL_PPGTT is one of the
> capabilities type to le
On to, 2017-05-25 at 16:03 +0100, Chris Wilson wrote:
> On Thu, May 25, 2017 at 05:58:33PM +0300, Joonas Lahtinen wrote:
> >
> > Lock used to work as a serializer, isn't this going to get contended
> > now?
>
> lockdep_set_current ?
>
> The intention is to allow the contention to reach i915_g
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, May 30, 2017 12:34 PM
> To: Chauhan, Madhav ; Ville Syrjälä
>
> Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
> ; Hiremath, Shashidhar
>
> Subject: RE: [Intel-gfx] [PATCH 2/2] drm/i915/glk: Enable cold boot for
Op 26-05-17 om 17:15 schreef Mahesh Kumar:
> Don't trust cached DDB values. Recalculate the ddb value if cached value
> is zero.
>
> If i915 is build as a module, there may be a race condition when
> cursor_disable call comes even before intel_fbdev_initial_config.
> Which may lead to cached value
Hi,
> This patch set adds the dma-buf support for intel GVT-g.
> dma-buf is a uniform mechanism to share DMA buffers across different
> devices and sub-systems.
> dma-buf for intel GVT-g is mainly used to share the vgpu's
> framebuffer
> to other users or sub-systems so they can use the dma-buf
Hey,
Op 02-05-17 om 11:56 schreef Daniel Vetter:
> On Mon, May 01, 2017 at 03:37:57PM +0200, Maarten Lankhorst wrote:
>> Some atomic properties are common between the various kinds of
>> connectors, for example a lot of them use panel fitting mode.
>> It makes sense to put a lot of it in a common
On 29.05.2017 16:01, Chris Wilson wrote:
> On Mon, May 29, 2017 at 03:08:07PM +0300, Abdiel Janulgue wrote:
>> Support executing external processes with the goal of capturing its
>> standard streams to the igt logging infrastructure in addition to its
>> exit status.
>
> This is not an exec wrap
On Tue, May 30, 2017 at 01:31:46PM +0300, Abdiel Janulgue wrote:
>
>
> On 29.05.2017 16:01, Chris Wilson wrote:
> > On Mon, May 29, 2017 at 03:08:07PM +0300, Abdiel Janulgue wrote:
> >> Support executing external processes with the goal of capturing its
> >> standard streams to the igt logging in
On pe, 2017-05-26 at 09:37 +0800, Weinan Li wrote:
> I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace.
> In gvt environment, each vm only use the ballooned part of aperture, so we
> should return the correct available aperture size exclude the reserved part
> by balloon.
>
On Tue, May 30, 2017 at 11:11:44AM +0300, Joonas Lahtinen wrote:
> On to, 2017-05-25 at 21:48 +0100, Chris Wilson wrote:
> > Add kerneldoc for the vma_list stored on the i915_gem_object, in
> > particular, documenting the expected ordering of elements -- i.e. that
> > we do expect GGTT VMA first fo
On Fri, May 26, 2017 at 12:11:04PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> AM_PROG_FLEX macro will set the LEX variable using the missing
> script when the flex is not present. This will confuse the
> configure.ac check, which expects the AC_PROG_FLEX behaviour,
> and will so fail
This patch series adds DRM layer support for YCBCR HDMI output handling.
The target HDMI YCBCR outputs are:
- YCBCR444
- YCBCR422
- YCBCR420
As YCBCR420 output is added in HDMI 2.0, this patch series also
contain few patches to handle new EDID extention blocks, added
for YCBCR420 modes (CEA-861-F)
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if
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 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onw
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 deep color support from the
EDID and adding it into display information stored.
Cc: Ville Syrjälä
Cc: Jose Abreu
Signed-off-by: Sha
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 444
- YCBCR 422
- YCBCR 420
This patch adds a drm property, using which, a userspace
can specify its preference, for the HDMI outp
This patch adds helper functions for ycbcr HDMI output handling.
These functions provide functionality like:
- getting the highest subsamled ycbcr output
- getting the lowest subsamled ycbcr output
- check if a given source and sink combination can support any YCBCR output
- check if a given source
This patch adds support for HDMI ycbcr outputs in i915 layer.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HDMI output type selected by user.
And if they both can, it commits the hdmi output type into crtc state,
for further staging in driver.
V2:
HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.
As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI i
When HDMI output is other than RGB, we have to load the
corresponding colorspace of output mode. This patch fills
the colorspace of AVI infoframe as per the HDMI output mode.
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c
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 pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.
This function adds a csc handler, t
On 11/05/2017 14:16, Tvrtko Ursulin wrote:
On 11/05/2017 14:07, Chris Wilson wrote:
On Thu, May 11, 2017 at 02:00:45PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
For userspace receiving binary data it is easier if all related
request tracepoints emit the binary data in the same order
HDMI 2.0 spec adds support for ycbcr420 sub-sampled output.
CEA-861-F adds two new blocks in EDID, to provide information
about sink's support for ycbcr420 output.
One of these new blocks is: ycbcr420cmdb(ycbcr 420 capability
map data block). This gives information about video modes which
can supp
To get a ycbcr420 output from intel platforms, there are two
major steps:
- RGB->YCBCR conversion using a pipe CSC.
- Program PIPE_MISC register to generate a ycbcr420 output.
- Scaling down YCBCR444 samples to YCBCR420 samples using a pipe
scaler.
This patch:
- Does scaler allocation for HDMI y
As another precaution when testing whether the CS engine is actually
idle, also inspect the ring's HEAD/TAIL registers, which should be equal
when there are no commands left to execute by the GPU.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_engine_cs.c | 5 +
If the device is asleep (no GT wakeref), we know the GPU is already idle.
If we add an early return, we can avoid touching registers and checking
hw state outside of the assumed GT wakelock. This prevents causing such
errors whilst debugging:
[ 2613.401647] RPM wakelock ref not held during HW acce
Allow intel_engine_is_idle() to be called outside of the GT wakeref by
acquiring the device runtime pm for ourselves. This allows the function
to act as check after we assume the engine is idle and we release the GT
wakeref held whilst we have requests.
[ 2613.401647] RPM wakelock ref not held dur
On 30/05/2017 13:13, Chris Wilson wrote:
If the device is asleep (no GT wakeref), we know the GPU is already idle.
If we add an early return, we can avoid touching registers and checking
hw state outside of the assumed GT wakelock. This prevents causing such
errors whilst debugging:
[ 2613.4016
On Tue, May 30, 2017 at 01:21:29PM +0100, Tvrtko Ursulin wrote:
>
> On 30/05/2017 13:13, Chris Wilson wrote:
> >If the device is asleep (no GT wakeref), we know the GPU is already idle.
> >If we add an early return, we can avoid touching registers and checking
> >hw state outside of the assumed GT
On 30/05/2017 13:13, Chris Wilson wrote:
Allow intel_engine_is_idle() to be called outside of the GT wakeref by
acquiring the device runtime pm for ourselves. This allows the function
to act as check after we assume the engine is idle and we release the GT
wakeref held whilst we have requests.
On ti, 2017-05-30 at 13:13 +0100, Chris Wilson wrote:
> If the device is asleep (no GT wakeref), we know the GPU is already idle.
> If we add an early return, we can avoid touching registers and checking
> hw state outside of the assumed GT wakelock. This prevents causing such
> errors whilst debug
On Sat, May 27, 2017 at 10:01:48AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2,1/3] drm/i915/gvt: Add gvt options sanitize
> function
> URL : https://patchwork.freedesktop.org/series/24982/
> State : success
Sigh. Had to resort to checking pw, but it lgt
On Tue, May 30, 2017 at 03:41:15PM +0300, Joonas Lahtinen wrote:
> On ti, 2017-05-30 at 13:13 +0100, Chris Wilson wrote:
> > If the device is asleep (no GT wakeref), we know the GPU is already idle.
> > If we add an early return, we can avoid touching registers and checking
> > hw state outside of
On Tue, May 30, 2017 at 01:37:23PM +0100, Tvrtko Ursulin wrote:
>
> On 30/05/2017 13:13, Chris Wilson wrote:
> >Allow intel_engine_is_idle() to be called outside of the GT wakeref by
> >acquiring the device runtime pm for ourselves. This allows the function
> >to act as check after we assume the e
Hi Maarten,
Thanks for review :)
On Tuesday 30 May 2017 03:30 PM, Maarten Lankhorst wrote:
Op 26-05-17 om 17:15 schreef Mahesh Kumar:
Don't trust cached DDB values. Recalculate the ddb value if cached value
is zero.
If i915 is build as a module, there may be a race condition when
cursor_disa
When looking at simple ioctls coupled with conveniently small user
parameters, the overhead of the syscall and drm_ioctl() present large
low hanging fruit. Profiling trivial microbenchmarks around
i915_gem_busy_ioctl, the low hanging fruit comprises of the call to
copy_user(). Those calls are only
On 30/05/2017 13:50, Chris Wilson wrote:
On Tue, May 30, 2017 at 01:37:23PM +0100, Tvrtko Ursulin wrote:
On 30/05/2017 13:13, Chris Wilson wrote:
Allow intel_engine_is_idle() to be called outside of the GT wakeref by
acquiring the device runtime pm for ourselves. This allows the function
to a
On ti, 2017-05-30 at 13:45 +0100, Chris Wilson wrote:
> On Sat, May 27, 2017 at 10:01:48AM -, Patchwork wrote:
> >
> > == Series Details ==
> >
> > Series: series starting with [v2,1/3] drm/i915/gvt: Add gvt options
> > sanitize function
> > URL : https://patchwork.freedesktop.org/series/2
On ti, 2017-05-30 at 13:55 +0100, Chris Wilson wrote:
> When looking at simple ioctls coupled with conveniently small user
> parameters, the overhead of the syscall and drm_ioctl() present large
> low hanging fruit. Profiling trivial microbenchmarks around
> i915_gem_busy_ioctl, the low hanging fru
== Series Details ==
Series: HDMI YCBCR output handling in DRM layer (rev2)
URL : https://patchwork.freedesktop.org/series/22684/
State : failure
== Summary ==
Series 22684v2 HDMI YCBCR output handling in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/22684/revisions/2/mbox/
Test
== Series Details ==
Series: series starting with [1/3] drm/i915: Short-circuit
i915_gem_wait_for_idle() if already idle
URL : https://patchwork.freedesktop.org/series/25039/
State : success
== Summary ==
Series 25039v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/ser
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Hans Verkuil wrote:
On 05/29/2017 09:00 PM, Daniel Vetter wrote:
On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
On 05/26/2017 09:15 AM, Daniel Vetter wrote:
Did you look into also wiring this up for dp mst chain
== Series Details ==
Series: drm: Optimise drm_ioctl() for small user args
URL : https://patchwork.freedesktop.org/series/25044/
State : success
== Summary ==
Series 25044v1 drm: Optimise drm_ioctl() for small user args
https://patchwork.freedesktop.org/api/1.0/series/25044/revisions/1/mbox/
Mahesh Kumar schreef op di 30-05-2017 om 18:26 [+0530]:
> Hi Maarten,
>
> Thanks for review :)
>
>
> On Tuesday 30 May 2017 03:30 PM, Maarten Lankhorst wrote:
> > Op 26-05-17 om 17:15 schreef Mahesh Kumar:
> > > Don't trust cached DDB values. Recalculate the ddb value if
> > > cached value
> > >
On 05/29/2017 04:06 AM, Jani Nikula wrote:
On Thu, 18 May 2017, Clint Taylor wrote:
On 05/18/2017 04:10 AM, Jani Nikula wrote:
Face the fact, there are Display Port sink and branch devices out there
in the wild that don't follow the Display Port specifications, or they
have bugs, or just oth
On Tue, May 30, 2017 at 01:55:20PM +0100, Chris Wilson wrote:
> When looking at simple ioctls coupled with conveniently small user
> parameters, the overhead of the syscall and drm_ioctl() present large
> low hanging fruit. Profiling trivial microbenchmarks around
> i915_gem_busy_ioctl, the low han
On Mon, 2017-05-29 at 11:26 +0300, Ander Conselvan De Oliveira wrote:
> On Fri, 2017-05-26 at 16:23 -0700, Rodrigo Vivi wrote:
> > According to spec this WA is needed for every gen9.
>
> Actually GLK has a gen10 display, so the gen9 workarounds don't apply.
Oh, indeed!
Please ignore this patch.
On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to
On Tue, May 30, 2017 at 05:43:41PM +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 modes (VIC=1 to VIC=64). Now
> to be able to parse new CEA
On Tue, May 30, 2017 at 02:09:53PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] drm/i915: Short-circuit
> i915_gem_wait_for_idle() if already idle
> URL : https://patchwork.freedesktop.org/series/25039/
> State : success
>
> == Summary ==
>
> Series 25
Regards
Shashank
On 5/30/2017 9:48 PM, Ville Syrjälä wrote:
On Tue, May 30, 2017 at 05:43:41PM +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
On Tue, May 30, 2017 at 05:43:42PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec adds support for ycbcr420 sub-sampled output.
> CEA-861-F adds two new blocks in EDID, to provide information
> about sink's support for ycbcr420 output.
>
> One of these new blocks is: ycbcr420cmdb(ycbcr 420 capabili
Regards
Shashank
On 5/30/2017 9:43 PM, Ville Syrjälä wrote:
On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support vid
On Tue, May 30, 2017 at 05:43:43PM +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 deep color support from the
> EDID and adding it into display i
On Tue, May 30, 2017 at 05:43:44PM +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 444
> - YCBCR 422
> - YCBCR 420
>
> This patch adds a d
Regards
Shashank
On 5/30/2017 10:06 PM, Ville Syrjälä wrote:
On Tue, May 30, 2017 at 05:43:44PM +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
On 05/30/2017 04:19 PM, Clint Taylor wrote:
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Hans Verkuil wrote:
On 05/29/2017 09:00 PM, Daniel Vetter wrote:
On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
On 05/26/2017 09:15 AM, Daniel Vetter wrote:
Did you l
On 05/30/2017 06:49 PM, Hans Verkuil wrote:
On 05/30/2017 04:19 PM, Clint Taylor wrote:
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Hans Verkuil wrote:
On 05/29/2017 09:00 PM, Daniel Vetter wrote:
On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
On 05/26/2
Patch merged to dinq, thanks.
I didn't put on fixes nor Cc'ed stable after chatting with Daniel about that.
Since PSR is currently disabled on 4.11 there is no risk of this
blowing anything nor changing the expected default behaviour.
So dinq seemed to be the right place for this patch.
Thanks,
R
There is pretty obvious bug with this patch as some OA configs spans
more registers write than what MI_LOAD_REGISTER_IMM can do (> 128).
I'll send an updated patch.
That doesn't affect patch 14 though.
-
Lionel
On 26/05/17 12:56, Lionel Landwerlin wrote:
Dynamic slices/subslices shutdown will
Hi,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Chris Wilson
> Sent: Tuesday, May 30, 2017 7:21 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3]
> drm/i915: Sho
On Tue, May 30, 2017 at 07:18:20PM +, Saarinen, Jani wrote:
> Hi,
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of
> > Chris Wilson
> > Sent: Tuesday, May 30, 2017 7:21 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject:
Hi Dave (both of them),
topic/e1000e-fix-2017-05-30:
Just an e1000e crash fix that somehow got stuck in a trivial bikeshed,
see
https://patchwork.ozlabs.org/patch/729312/
Sending this your way since not even the intel-internal escalation seems
to have worked out. If the e1000e maintainer wants t
On Tue, May 30, 2017 at 4:01 PM, Harry Wentland wrote:
> AMD GPUs can have 6 CRTCs.
>
> This requires us to allocate the combinations on the heap.
>
> Signed-off-by: Harry Wentland
> ---
> tests/kms_setmode.c | 25 +++--
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
>
On 05/30/2017 09:49 AM, Hans Verkuil wrote:
On 05/30/2017 04:19 PM, Clint Taylor wrote:
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Hans Verkuil wrote:
On 05/29/2017 09:00 PM, Daniel Vetter wrote:
On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
On 05/26
On 05/30/2017 09:54 AM, Hans Verkuil wrote:
On 05/30/2017 06:49 PM, Hans Verkuil wrote:
On 05/30/2017 04:19 PM, Clint Taylor wrote:
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Hans Verkuil wrote:
On 05/29/2017 09:00 PM, Daniel Vetter wrote:
On Fri, May 26, 2017 at 12
On 2017-05-26 00:00, Daniel Vetter wrote:
> On Thu, May 25, 2017 at 10:18 AM, Stefan Agner wrote:
>> On 2017-05-24 07:51, Daniel Vetter wrote:
>>> Again cleanup before irq disabling doesn't really stop the races,
>>> so just drop it. Proper fix would be to put drm_atomic_helper_shutdown
>>> before
AMD GPUs can have 6 CRTCs.
This requires us to allocate the combinations on the heap.
v2:
Of course We should free the new allocation. Thanks, Alex.
Signed-off-by: Harry Wentland
---
tests/kms_setmode.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
dif
On 05/30/2017 10:32 PM, Clint Taylor wrote:
On 05/30/2017 09:54 AM, Hans Verkuil wrote:
On 05/30/2017 06:49 PM, Hans Verkuil wrote:
On 05/30/2017 04:19 PM, Clint Taylor wrote:
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Hans Verkuil wrote:
On 05/29/2017 09:00 PM, Dan
From: Dhinakaran Pandiyan
The first two bytes of PCI ID for CNP_LP PCH are the same as that of
SPT_LP. We should really be looking at the first 9 bits instead of the
first 8 to identify platforms, although this seems to have not caused any
problems on earlier platforms. Introduce a 9 bit extended
Split out BXT and CNP's setup_backlight(),enable_backlight(),
disable_backlight() and hz_to_pwm() into
two separate functions instead of reusing BXT function.
Reuse set_backlight() and get_backlight() since they have
no reference to the utility pin.
v2: Reuse BXT functions with controller 0 inste
As for BXT, PP_DIVISOR was removed from CNP PCH and power
cycle delay has been moved to PP_CONTROL.
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/dr
Most of south engine display that is in PCH is still the
same as SPT and KBP, except for this key differences:
- Backlight: Backlight programming changed in CNP PCH.
- Panel Power: Sligh programming changed in CNP PCH.
- GMBUS and GPIO: The pin mapping has changed in CNP PCH.
All of these changes
RAWCLK_FREQ register has changed for platforms with CNP+.
[29:26] This field provides the denominator for the fractional
part of the microsecond counter divider. The numerator
is fixed at 1. Program this field to the denominator of
the fractional portion of reference frequ
On CNP PCH based platforms the gmbus is on the south display that
is on PCH. The existing implementation for previous platforms
already covers the need for CNP expect for the pin pair configuration
that follows similar definitions that we had on BXT.
v2: Don't drop "_BXT" as the indicator of the f
Jani, Daniel, could I merge the 5 patches already after CI respond?
I rebased and retest here on CNL But I'd like to start merging so
we unblock CFL as well, maybe on top of this CNP before CNL...
Jani, also I believe you would be the best reviewer for this 6th patch
here, could you please co
== Series Details ==
Series: series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH.
URL : https://patchwork.freedesktop.org/series/25066/
State : failure
== Summary ==
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/genera
Split out BXT and CNP's setup_backlight(),enable_backlight(),
disable_backlight() and hz_to_pwm() into
two separate functions instead of reusing BXT function.
Reuse set_backlight() and get_backlight() since they have
no reference to the utility pin.
v2: Reuse BXT functions with controller 0 inste
From: Dhinakaran Pandiyan
The first two bytes of PCI ID for CNP_LP PCH are the same as that of
SPT_LP. We should really be looking at the first 9 bits instead of the
first 8 to identify platforms, although this seems to have not caused any
problems on earlier platforms. Introduce a 9 bit extended
RAWCLK_FREQ register has changed for platforms with CNP+.
[29:26] This field provides the denominator for the fractional
part of the microsecond counter divider. The numerator
is fixed at 1. Program this field to the denominator of
the fractional portion of reference frequ
On CNP PCH based platforms the gmbus is on the south display that
is on PCH. The existing implementation for previous platforms
already covers the need for CNP expect for the pin pair configuration
that follows similar definitions that we had on BXT.
v2: Don't drop "_BXT" as the indicator of the f
Most of south engine display that is in PCH is still the
same as SPT and KBP, except for this key differences:
- Backlight: Backlight programming changed in CNP PCH.
- Panel Power: Sligh programming changed in CNP PCH.
- GMBUS and GPIO: The pin mapping has changed in CNP PCH.
All of these changes
As for BXT, PP_DIVISOR was removed from CNP PCH and power
cycle delay has been moved to PP_CONTROL.
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/dr
== Series Details ==
Series: series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH.
URL : https://patchwork.freedesktop.org/series/25068/
State : success
== Summary ==
Series 25068v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/25068/revisions/1/mbo
AMD GPUs can have 6 CRTCs.
This requires us to allocate the combinations on the heap.
Signed-off-by: Harry Wentland
---
tests/kms_setmode.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
index 430568a1c24
Hi Shashank,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20170530]
[cannot apply to v4.12-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Shashank-Sharma/HDMI
On CNP PCH based platforms the gmbus is on the south display that
is on PCH. The existing implementation for previous platforms
already covers the need for CNP expect for the pin pair configuration
that follows similar definitions that we had on BXT.
v2: Don't drop "_BXT" as the indicator of the f
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
include/drm/i915_pciids.h | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 31ea988..0b1c96d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++
From: Dhinakaran Pandiyan
The first two bytes of PCI ID for CNP_LP PCH are the same as that of
SPT_LP. We should really be looking at the first 9 bits instead of the
first 8 to identify platforms, although this seems to have not caused any
problems on earlier platforms. Introduce a 9 bit extended
1 - 100 of 139 matches
Mail list logo
