From: Joe Konno <joe.ko...@intel.com>
There are mechanisms for "set and return previous" underrun reporting
state, but no convenience functions for simply getting the underrun
reporting state for a particular pipe or pch transcoder.
Signed-off-by: Joe Konno <joe.ko...@intel.co
From: Joe Konno <joe.ko...@intel.com>
Previously, cpu and pch underrun reporting was done on a "report once
and disable" basis to prevent interrupt/dmesg floods.
With this change, do not disable the underrun interrupt handlers.
Instead, use throttled (DRM_ERROR_RATELIMITED) dmesg
From: Joe Konno <joe.ko...@intel.com>
In tracking down a watermark bug, I discovered the pch and cpu underrun
interrupt handlers would disable themselves after initial reports to prevent an
interrupt/dmesg storm. Storms are bad, but underrun interrupt handling should
not cease. For my c
From: Joe Konno <joe.ko...@intel.com>
Add atomic cpu and pch underrun counters to struct intel_crtc, and
increment them each time their respective interrupt handler executes.
Whether dmesg underrun reporting is disabled or not, keep a count of cpu
and pch underrun interrupts. D
On 01/26/2016 12:51 PM, Daniel Vetter wrote:
> On Tue, Jan 26, 2016 at 11:36:54AM -0800, Joe Konno wrote:
>> From: Joe Konno <joe.ko...@intel.com>
>>
>> In tracking down a watermark bug, I discovered the pch and cpu underrun
>> interrupt handlers would disable
Who will commit to reviewing this series to danvet's satisfaction? Jani
and Damien?
On 05/28/2015 09:01 AM, Daniel Vetter wrote:
On Thu, May 28, 2015 at 04:29:10PM +0100, Damien Lespiau wrote:
On Wed, May 27, 2015 at 02:49:38PM -0700, Joe Konno wrote:
Do we have an idea when this patch series
Do we have an idea when this patch series will be reviewed? Customers
are awaiting for this to be merged to the drm-intel fd.o repository.
Cheers
On 05/22/2015 01:22 AM, Mika Kahola wrote:
This patch series rebases Ville's original cdclk patch series
excluding the ones that are already
On 02/27/2015 06:53 AM, Daniel Vetter wrote:
On Thu, Feb 26, 2015 at 05:47:35PM -0800, Matt Roper wrote:
So your patch below could result in sleeps happening while vblanks are
disabled, which is bad (IIRC, most of those sleeps are in the SKL
codepath right now, but I think there's a
From: Joe Konno joe.ko...@intel.com
In instances where cursor sizes change, as in Chromium Ozone/Freon,
watermarks should be recomputed. There should be no hard-coded
assumptions about cursor widths. This was corrected originally here:
commit 64f962e3e38bf6f40bbd2462f8380dee0369e1bf
Reviewed-By: Joe Konno joe.ko...@intel.com
On 09/29/2014 03:49 PM, U. Artie Eoff wrote:
Improper truncated integer division in the scale() function causes
actual_brightness != brightness. This (partial) work-around should be
sufficient for a majority of use-cases, but it is by no means
Reviewed-By: Joe Konno joe.ko...@intel.com
On 09/29/2014 03:49 PM, U. Artie Eoff wrote:
Move the duplicated DIV_ROUND_CLOSEST_ULL macro into the intel_drv.h
header file so that it can be shared between intel_display.c
and intel_panel.c.
Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com
Many thanks, Chris. I'll incorporate your feedback into v2.
On 09/23/2014 11:04 PM, Chris Wilson wrote:
On Tue, Sep 23, 2014 at 03:50:25PM -0700, Joe Konno wrote:
From: Joe Konno joe.ko...@intel.com
Improper integer division-- truncated rather than rounded-- in the
That's confusing. It reads
From: Joe Konno joe.ko...@intel.com
Improper truncated integer division in the scale() function causes
actual_brightness != brightness. This (partial) work-around should be
sufficient for a majority of use-cases, but it is by no means a complete
solution.
TODO: Determine how best to scale user
From: Joe Konno joe.ko...@intel.com
Improper integer division-- truncated rather than rounded-- in the
scale() function causes actual_brightness != brightness. This (partial)
work-around should be sufficient for a majority of use-cases, but it is
by no means a complete solution.
TODO: Determine
)
return -ENOMEM;
Tested-by: Joe Konno joe.ko...@intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
,
+ connector-kdev,
+ to_intel_connector(connector),
intel_panel_bl_ops, props);
if (IS_ERR(dev_priv-backlight.device)) {
Tested-by: Joe Konno joe.ko...@intel.com
= BACKLIGHT_DUTY_CYCLE_MASK;
+ I915_WRITE(VLV_BLC_PWM_CTL(pipe), (0xf42 16) |
+ cur_val);
+ }
}
}
Tested-by: Joe Konno joe.ko...@intel.com
___
Intel-gfx mailing list
Intel-gfx
intel_panel_init(struct intel_panel *panel,
struct drm_display_mode *fixed_mode)
Tested-by: Joe Konno joe.ko...@intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
-display.get_max_backlight = i9xx_get_max_backlight;
+ }
+}
+
int intel_panel_init(struct intel_panel *panel,
struct drm_display_mode *fixed_mode)
{
Tested-by: Joe Konno joe.ko...@intel.com
___
Intel-gfx mailing list
Intel-gfx
= intel_panel_get_backlight(dev, 0);
+ panel-backlight.enabled = panel-backlight.level != 0;
intel_backlight_device_register(intel_connector);
Tested-by: Joe Konno joe.ko...@intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
= to_intel_connector(connector);
+ struct intel_panel *panel = intel_connector-panel;
+ panel-backlight.present = false;
intel_backlight_device_unregister(intel_connector);
}
Tested-by: Joe Konno joe.ko...@intel.com
___
Intel-gfx mailing list
On Fri, Nov 01, 2013 at 03:28:53PM +0200, Jani Nikula wrote:
Please post the dmesg with drm.debug=0xe module parameter.
Sent to you privately.
Does it work with plain drm-intel-nightly?
First item on my TODO list. In case it's interesting, test failed with
plain drm-intel-next-queued.
Did
Hi Jani,
Applied this patchset to danvet/drm-intel-next-queued and did a quick test
on VLV2 with mutter. Tested eDP + VGA hotplug, test failed.
Hot-plugging VGA with eDP active resulted in the eDP's backlight being
kicked off. Then, after unplugging and replugging, the eDP backlight returned.
23 matches
Mail list logo
