On Wed, Jul 29, 2015 at 6:39 PM, Theodore Ts'o wrote:
>
> It's here: https://goo.gl/photos/xHjn2Z97JQEw6k2C9
You didn't catch enough of the code line to decode the code, but it's
early enough in drm_crtc_index() (just five bytes in) that it's almost
certainly the very first dereference, so it's
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:53 PM, Michel Thierry wrote:
v2: Clean up patch after rebases.
v3: gen8_dump_ppgtt for 32b and 48b PPGTT.
v4: Use used_pml4es/pdpes (Akash).
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
v6: Rely
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:53 PM, Michel Thierry wrote:
In a 48b world, users can try to allocate buffers bigger than 4GB; in
these cases it is important that size is a 64b variable.
v2: Drop the warning about bind with size 0, it shouldn't hap
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:53 PM, Michel Thierry wrote:
Otherwise it can overflow in 48-bit mode, and cause an incorrect
exec_start.
Before commit 5f19e2bffa63a91cd4ac1adcec648e14a44277ce ("drm/i915: Merged
the many do_execbuf() parameters int
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:54 PM, Michel Thierry wrote:
GTT was only 32b and its max value is 4GB. In order to allow objects
bigger than 4GB in 48b PPGTT, i915_gem_userptr_ioctl we could check
against max 48b range (1ULL << 48).
But since the c
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:54 PM, Michel Thierry wrote:
There are some allocations that must be only referenced by 32-bit
offsets. To limit the chances of having the first 4GB already full,
objects not requiring this workaround use DRM_MM_SEARCH
On 7/29/2015 9:54 PM, Michel Thierry wrote:
Use 48b addresses if hw supports it (i915.enable_ppgtt=3).
Note, aliasing PPGTT remains 32b only.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++---
drivers/gpu/drm/i915/i915_params.c | 2 +-
2 files changed, 3 in
On Thu, Jul 30, 2015 at 4:43 AM, Dave Airlie wrote:
> (are there any closed source compositors?)
Afaik everyone's hwc driver for surface flinger is a blob and only
code-dropped for nexus devices since google requires that. So can't
really use those one-offs to develop new stuff since it's a fork
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to CRT.
V2:
-
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to LVDS.
V2:
-
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to HDMI.
V2:
-
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DisplayPort.
Store max dotclock into dev_priv structure so we are able
to filter out the modes that are not supported by our
platforms.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 20
2 files changed, 21 insertions(+)
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DSI.
V2:
-
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DisplayPort
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DVO.
V2:
-
Information on maximum supported DOT clock frequency to
i915_frequency_info.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 23a69307..4ba02b5
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to SDVO.
V2:
-
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to TV.
V2:
- r
From EDID we can read and request higher pixel clock than
our HW can support. This set of patches add checks if
requested pixel clock is lower than the one supported by the HW.
The requested mode is discarded if we cannot support the requested
pixel clock. For example for Cherryview
'cvt 2560 1600
On Thu, Jul 30, 2015 at 09:49:33AM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
Op 29-07-15 om 15:26 schreef Ander Conselvan De Oliveira:
> On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
>> Now that everything's atomic, checking encoder->base.crtc is enough.
> Don't you need to check encoder->base.crtc->state->active too?
Not sure, I think stealing a encoder being
On Thu, Jul 30, 2015 at 09:49:30AM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
101 - 123 of 123 matches
Mail list logo
