Hi Jani,
On Wednesday 31 May 2017 02:57 PM, Shobhit Kumar wrote:
Hi All,
Its been long since I have been sitting on these after I had received Tested-by
for the same by Lluís for atleast the backlight working fine. The related bugs
Can you have a look at these patches.
Regards
Shobhit
are -
On Wednesday 31 May 2017 10:16 PM, kbuild test robot wrote:
Hi Shobhit,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.12-rc3 next-20170531]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
Guess this needs to
On Monday 18 April 2016 09:47 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
The power cycle delay starts _after_ turning off the panel power. Do the
msleep after frobbing the pmic panel power gpio.
Also toss in a FIXME about optimizing away needless waits.
Cc: Shobhit Kumar
Cc
On Wednesday 06 April 2016 04:26 PM, Lluís Batlle i Rossell wrote:
On Tue, Apr 05, 2016 at 09:06:25PM +0200, Lluís Batlle i Rossell wrote:
On Tue, Apr 05, 2016 at 12:39:30PM +0200, Lluís Batlle i Rossell wrote:
On Tue, Apr 05, 2016 at 12:03:44PM +0530, Kumar, Shobhit wrote:
On Thursday 31
Hi
On Thursday 31 March 2016 03:57 PM, Lluís Batlle i Rossell wrote:
Hello,
I saw that you did some work for LPSS PWM:
https://lists.freedesktop.org/archives/intel-gfx/2016-January/085006.html
Apart from above apply the following as well -
https://patchwork.freedesktop.org/patch/70965/
This
On 03/08/2016 06:35 AM, Matt Roper wrote:
This series of patches was mostly written by Mahesh and Shobhit; the last
iteration posted was by Shobhit here:
https://patchwork.freedesktop.org/series/2881/
I believe they've been busy recently and haven't had time to revisit this work,
so I'
On 02/16/2016 03:44 PM, Kumar, Shobhit wrote:
On 01/05/2016 03:44 PM, Daniel Vetter wrote:
On Mon, Jan 04, 2016 at 07:18:26PM +0530, Kumar, Shobhit wrote:
On 12/23/2015 08:22 AM, Kumar, Shobhit wrote:
On 12/21/2015 05:39 PM, Daniel Vetter wrote:
On Fri, Dec 18, 2015 at 07:24:19AM -0800, Matt
On 01/05/2016 03:44 PM, Daniel Vetter wrote:
On Mon, Jan 04, 2016 at 07:18:26PM +0530, Kumar, Shobhit wrote:
On 12/23/2015 08:22 AM, Kumar, Shobhit wrote:
On 12/21/2015 05:39 PM, Daniel Vetter wrote:
On Fri, Dec 18, 2015 at 07:24:19AM -0800, Matt Roper wrote:
On Fri, Dec 18, 2015 at 07:14
On 02/05/2016 07:59 PM, Matt Roper wrote:
On Wed, Jan 27, 2016 at 09:39:59PM +0530, Shobhit Kumar wrote:
From: "Kumar, Mahesh"
don't always use 8 ddb as minimum, instead calculate using proper
algorithm.
v2: optimizations as per Matt's comments.
Cc: matthew.d.ro...@intel.com
Signed-off-by: K
On 01/27/2016 09:39 PM, Shobhit Kumar wrote:
From: "Kumar, Mahesh"
Use plane size for relative data rate calculation. don't always use
pipe source width & height.
adjust height & width according to rotation.
use plane size for watermark calculations also.
v2: Address Matt's comments.
Use
On 01/15/2016 07:14 AM, Matt Roper wrote:
On Thu, Jan 14, 2016 at 05:32:47PM +0530, Shobhit Kumar wrote:
This is needed for WM computation workaround for arbitrated display
bandwidth.
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/i915_dma.c | 19 +++
drivers/gpu/drm/
On 01/21/2016 05:47 PM, Kumar, Abhay wrote:
On 1/20/2016 5:06 AM, Ville Syrjälä wrote:
On Wed, Jan 20, 2016 at 03:29:00PM +0530, Kumar, Shobhit wrote:
On 01/20/2016 02:30 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 02:37:55PM -0800, Kumar, Abhay wrote:
On 1/12/2016 5:57 PM, Kumar
On 01/20/2016 02:30 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 02:37:55PM -0800, Kumar, Abhay wrote:
On 1/12/2016 5:57 PM, Kumar, Abhay wrote:
From: Abhay Kumar
Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12)
if this time is already spent in suspend/poweron ti
On 01/20/2016 01:50 AM, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 09:00:40PM +0530, Kumar, Shobhit wrote:
On 01/19/2016 08:45 PM, Shobhit Kumar wrote:
INTEL_SOC_PMIC is loading later than I915 failing the gpiod_get and
pwm_get calls in i915. Add a retry to give time for the INTEL_SOC_PMIC
On 01/19/2016 08:45 PM, Shobhit Kumar wrote:
INTEL_SOC_PMIC is loading later than I915 failing the gpiod_get and
pwm_get calls in i915. Add a retry to give time for the INTEL_SOC_PMIC
to load. This was fine till now but broke in latest kernel. Maybe load
time for the INTEL_SOC_PMIC has increased.
On 01/15/2016 12:37 AM, Matt Roper wrote:
On Thu, Jan 14, 2016 at 05:32:42PM +0530, Shobhit Kumar wrote:
From: "Kumar, Mahesh"
Don't always use bytes_per_pixel using y_plane=0, instead use it
according to pixel format. If NV12 use y_plane eqal to 1
Signed-off-by: Kumar, Mahesh
The second p
On 01/15/2016 07:18 AM, Matt Roper wrote:
On Thu, Jan 14, 2016 at 05:32:41PM +0530, Shobhit Kumar wrote:
Hi,
This series add a set of updates to the WM calculation and also enables
arbitrated display bandwidth based WA. Some of these patches do overlap
with Matts work but we wanted to send them
On 01/13/2016 07:27 AM, abhay.ku...@intel.com wrote:
From: Abhay Kumar
Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12)
if this time is already spent in suspend/poweron time.
v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle
delay calculation(Ville).
On 01/13/2016 11:00 AM, C. B. wrote:
On 12 January 2016 at 08:59, Shobhit Kumar wrote:
Not sending yet to pwm mailing list as this is all untested. C.B. please
test the patches and see if they work at all for you. For testing Please
enable -
CONFIG_PWM_LPSS=y
CONFIG_PWM_LPSS_PLATFORM=y
I ap
On 12/23/2015 08:22 AM, Kumar, Shobhit wrote:
On 12/21/2015 05:39 PM, Daniel Vetter wrote:
On Fri, Dec 18, 2015 at 07:24:19AM -0800, Matt Roper wrote:
On Fri, Dec 18, 2015 at 07:14:17AM -0800, Matt Roper wrote:
On Fri, Dec 18, 2015 at 05:10:12PM +0200, Ville Syrjälä wrote:
On Fri, Dec 18
On 01/04/2016 03:12 PM, Jani Nikula wrote:
On Fri, 01 Jan 2016, "C. B." wrote:
Hello All,
Re: http://lists.freedesktop.org/archives/intel-gfx/2015-April/065313.html
Recently I noticed another device Dell Venue 8 Pro (BYT-CR) which
should be using LPSS backlight control. There is already a LP
On 12/30/2015 05:27 PM, Jani Nikula wrote:
On Wed, 23 Dec 2015, Gary Wang wrote:
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
old mode 100644
new mode 100755
Please pay more attention to not changing the file permissions.
Yeah, and the new permissions
On 12/23/2015 01:41 PM, Gary Wang wrote:
The total delay of HDMI hotplug detecting with 30ms is sometimes not
enoughtfor HDMI live status up with specific HDMI monitors in BSW platform.
After doing experiments for following monitors, it needs 80ms at least
for those worst cases.
Lenovo L246 1xw
On 12/21/2015 05:39 PM, Daniel Vetter wrote:
On Fri, Dec 18, 2015 at 07:24:19AM -0800, Matt Roper wrote:
On Fri, Dec 18, 2015 at 07:14:17AM -0800, Matt Roper wrote:
On Fri, Dec 18, 2015 at 05:10:12PM +0200, Ville Syrjälä wrote:
On Fri, Dec 18, 2015 at 06:58:58AM -0800, Matt Roper wrote:
On Fr
On 12/21/2015 09:02 PM, Matt Roper wrote:
On Mon, Dec 21, 2015 at 11:15:04AM +0530, Kumar, Shobhit wrote:
On 12/19/2015 08:14 AM, Matt Roper wrote:
On Fri, Dec 18, 2015 at 03:58:52PM -0800, Radhakrishna Sripada wrote:
Original value of 32 blocks is not sufficient when using cursor size of
On 12/19/2015 08:14 AM, Matt Roper wrote:
On Fri, Dec 18, 2015 at 03:58:52PM -0800, Radhakrishna Sripada wrote:
Original value of 32 blocks is not sufficient when using cursor size of
256x256 causing FIFO underruns when the reworked wm
caluclations in
commit 024c9045221fe45482863c47c4b4c47d37f9
On 12/19/2015 05:28 AM, Radhakrishna Sripada wrote:
Original value of 32 blocks is not sufficient when using cursor size of
256x256 causing FIFO underruns when the reworked wm
caluclations in
commit 024c9045221fe45482863c47c4b4c47d37f97cbf
Author: Matt Roper
Date: Thu Sep 24 15:53:11 2015 -07
On 12/16/2015 03:46 AM, abhay.ku...@intel.com wrote:
From: Abhay Kumar
Make resume codepath not to wait for panel_power_cycle_delay(t11_t12)
if this time is already spent in suspend/poweron time.
Signed-off-by: Abhay Kumar
---
drivers/gpu/drm/i915/intel_ddi.c | 3 +++
drivers/gpu/drm/i915
On 12/11/2015 10:30 PM, Daniel Vetter wrote:
On Fri, Dec 11, 2015 at 05:11:23PM +0530, Kumar, Shobhit wrote:
On 12/11/2015 04:55 PM, Thulasimani, Sivakumar wrote:
On 12/10/2015 8:32 PM, Ville Syrjälä wrote:
On Thu, Dec 10, 2015 at 08:09:01PM +0530, Thulasimani, Sivakumar wrote:
On 12/10
10, 2015 at 03:01:02PM +0530, Kumar, Shobhit wrote:
On 12/09/2015 09:35 PM, Ville Syrjälä wrote:
On Wed, Dec 09, 2015 at 08:59:26PM +0530, Shobhit Kumar wrote:
On Wed, Dec 9, 2015 at 8:34 PM, Chris Wilson
wrote:
On Wed, Dec 09, 2015 at 08:07:10PM +0530, Shobhit Kumar wrote:
On Wed, Dec 9, 2015
On 12/10/2015 06:45 PM, Ville Syrjälä wrote:
On Thu, Dec 10, 2015 at 03:01:02PM +0530, Kumar, Shobhit wrote:
On 12/09/2015 09:35 PM, Ville Syrjälä wrote:
On Wed, Dec 09, 2015 at 08:59:26PM +0530, Shobhit Kumar wrote:
On Wed, Dec 9, 2015 at 8:34 PM, Chris Wilson wrote:
On Wed, Dec 09, 2015
On 12/10/2015 03:20 PM, Daniel Vetter wrote:
On Thu, Dec 10, 2015 at 03:01:02PM +0530, Kumar, Shobhit wrote:
On 12/09/2015 09:35 PM, Ville Syrjälä wrote:
On Wed, Dec 09, 2015 at 08:59:26PM +0530, Shobhit Kumar wrote:
On Wed, Dec 9, 2015 at 8:34 PM, Chris Wilson wrote:
On Wed, Dec 09, 2015
On 12/09/2015 09:35 PM, Ville Syrjälä wrote:
On Wed, Dec 09, 2015 at 08:59:26PM +0530, Shobhit Kumar wrote:
On Wed, Dec 9, 2015 at 8:34 PM, Chris Wilson wrote:
On Wed, Dec 09, 2015 at 08:07:10PM +0530, Shobhit Kumar wrote:
On Wed, Dec 9, 2015 at 7:27 PM, Ville Syrjälä
wrote:
On Wed, Dec 09,
On 12/09/2015 06:51 PM, Shobhit Kumar wrote:
During resume, while turning the EDP panel power on, we need not wait
blindly for panel_power_cycle_delay. Check if panel power down sequence
in progress and then only wait. This improves our resume time significantly.
With this in case of actual su
On 12/09/2015 05:42 PM, Ville Syrjälä wrote:
On Wed, Dec 09, 2015 at 04:25:41PM +0530, Kumar, Shobhit wrote:
On 12/08/2015 02:22 AM, Paulo Zanoni wrote:
2015-12-07 18:28 GMT-02:00 :
From: Abhay Kumar
Moving 250ms from T12 timing to suspend path so that
resume path will be faster.
Can you
On 12/08/2015 02:22 AM, Paulo Zanoni wrote:
2015-12-07 18:28 GMT-02:00 :
From: Abhay Kumar
Moving 250ms from T12 timing to suspend path so that
resume path will be faster.
Can you please elaborate more on your motivation for this patch? I'm a
little confused. You're trying to make resume fa
Hi Ville,
On 11/02/2015 05:25 PM, Shobhit Kumar wrote:
SWF18 is set if the display has been intialized by the pre-os. It
also gives what configuration is enabled on which pipe. The DPLL and
CDCLK verification checks can fail as the pre-os does initialize the
DPLL for Audio codec initialization.
On 11/02/2015 05:25 PM, Shobhit Kumar wrote:
The cdclock sanitization patch reviewed and merged at -
http://patchwork.freedesktop.org/patch/msgid/1445344992-14658-1-git-send-email-shobhit.ku...@intel.com
made the assumptions that DPLL should not be enabled when pre-os does not
enable display an
On 11/02/2015 11:48 PM, Thulasimani, Sivakumar wrote:
On 11/2/2015 11:17 PM, Kumar, Shobhit wrote:
On 11/02/2015 10:07 PM, Thulasimani, Sivakumar wrote:
On 11/2/2015 6:49 PM, Kumar, Shobhit wrote:
On 11/02/2015 06:40 PM, Jani Nikula wrote:
On Mon, 02 Nov 2015, Shobhit Kumar wrote
On 11/02/2015 10:07 PM, Thulasimani, Sivakumar wrote:
On 11/2/2015 6:49 PM, Kumar, Shobhit wrote:
On 11/02/2015 06:40 PM, Jani Nikula wrote:
On Mon, 02 Nov 2015, Shobhit Kumar wrote:
SWF18 is set if the display has been intialized by the pre-os. It
also gives what configuration is enabled
On 11/02/2015 06:40 PM, Jani Nikula wrote:
On Mon, 02 Nov 2015, Shobhit Kumar wrote:
SWF18 is set if the display has been intialized by the pre-os. It
also gives what configuration is enabled on which pipe. The DPLL and
CDCLK verification checks can fail as the pre-os does initialize the
DPLL f
On 10/20/2015 04:49 PM, Ville Syrjälä wrote:
On Tue, Oct 20, 2015 at 03:27:24PM +0530, Kumar, Shobhit wrote:
On 10/19/2015 07:18 PM, Ville Syrjälä wrote:
On Fri, Oct 16, 2015 at 06:48:53PM +0530, Shobhit Kumar wrote:
Especially in cases where pre-os does not enable display, cdclk might
not be
On 10/19/2015 07:18 PM, Ville Syrjälä wrote:
On Fri, Oct 16, 2015 at 06:48:53PM +0530, Shobhit Kumar wrote:
Especially in cases where pre-os does not enable display, cdclk might
not be in sane state. During sanitization initialize cdclk with maximum
value till we get dynamic cdclk support.
v2:
On 10/16/2015 06:48 PM, Shobhit Kumar wrote:
Especially in cases where pre-os does not enable display, cdclk might
not be in sane state. During sanitization initialize cdclk with maximum
value till we get dynamic cdclk support.
v2: Check if BIOS programmed correctly rather than always calling in
On 10/08/2015 05:54 PM, Ville Syrjälä wrote:
On Thu, Oct 08, 2015 at 05:43:41PM +0530, Kumar, Shobhit wrote:
On 10/08/2015 04:59 PM, Imre Deak wrote:
On to, 2015-10-08 at 09:58 +0530, Shobhit Kumar wrote:
Reuse what is programmed by pre-os, but in case there is no pre-os
initialization, init
On 10/08/2015 05:54 PM, Ville Syrjälä wrote:
On Thu, Oct 08, 2015 at 05:43:41PM +0530, Kumar, Shobhit wrote:
On 10/08/2015 04:59 PM, Imre Deak wrote:
On to, 2015-10-08 at 09:58 +0530, Shobhit Kumar wrote:
Reuse what is programmed by pre-os, but in case there is no pre-os
initialization, init
On 10/08/2015 04:59 PM, Imre Deak wrote:
On to, 2015-10-08 at 09:58 +0530, Shobhit Kumar wrote:
Reuse what is programmed by pre-os, but in case there is no pre-os
initialization, init the cdclk with the max value by default untill
dynamic cdclk support comes.
v2: Check if BIOS programmed correc
On 10/06/2015 06:55 PM, Ville Syrjälä wrote:
On Tue, Oct 06, 2015 at 06:13:52PM +0530, Kumar, Shobhit wrote:
On 10/06/2015 05:49 PM, Daniel Vetter wrote:
On Tue, Oct 06, 2015 at 02:41:44PM +0300, Ville Syrjälä wrote:
On Tue, Oct 06, 2015 at 01:19:52PM +0200, Daniel Vetter wrote:
On Tue, Oct
On 10/06/2015 05:49 PM, Daniel Vetter wrote:
On Tue, Oct 06, 2015 at 02:41:44PM +0300, Ville Syrjälä wrote:
On Tue, Oct 06, 2015 at 01:19:52PM +0200, Daniel Vetter wrote:
On Tue, Oct 06, 2015 at 04:33:43PM +0530, Kumar, Shobhit wrote:
On 10/06/2015 04:11 PM, Imre Deak wrote:
On ti, 2015-10
On 10/06/2015 04:11 PM, Imre Deak wrote:
On ti, 2015-10-06 at 15:26 +0530, Kumar, Shobhit wrote:
On 10/05/2015 09:05 PM, Imre Deak wrote:
On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:
Mostly reuse what is programmed by pre-os, but in case there is no
pre-os initialization, init the
On 10/06/2015 12:05 PM, Jani Nikula wrote:
On Mon, 05 Oct 2015, Imre Deak wrote:
On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:
Mostly reuse what is programmed by pre-os, but in case there is no
pre-os initialization, init the cdclk with the default value.
Cc: Imre Deak
Signed-off-by
On 10/05/2015 09:05 PM, Imre Deak wrote:
On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:
Mostly reuse what is programmed by pre-os, but in case there is no
pre-os initialization, init the cdclk with the default value.
Cc: Imre Deak
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i91
On Monday 27 July 2015 04:51 PM, Thierry Reding wrote:
On Thu, Jul 23, 2015 at 09:38:46AM +0200, Daniel Vetter wrote:
[...]
On Thu, Jul 23, 2015 at 9:31 AM, Daniel Vetter wrote:
[...]
Shobhit Kumar (8):
[...]
pwm: crc: Add Crystalcove (CRC) PWM driver
Would you mind removing this
On Tuesday 21 July 2015 11:10 PM, Daniel Vetter wrote:
On Tue, Jul 21, 2015 at 09:17:21PM +0530, Kumar, Shobhit wrote:
On Tuesday 21 July 2015 07:35 PM, Daniel Vetter wrote:
On Tue, Jul 21, 2015 at 07:22:37PM +0800, kbuild test robot wrote:
tree: git://anongit.freedesktop.org/drm-intel
On Tuesday 21 July 2015 07:35 PM, Daniel Vetter wrote:
On Tue, Jul 21, 2015 at 07:22:37PM +0800, kbuild test robot wrote:
tree: git://anongit.freedesktop.org/drm-intel topic/crc-pmic
head: b029e66fa8e39ba10dcc47b114be8da8b082493b
commit: 61dd2ca2d44e493b050adbbb75bc50db11c367dd [2/7] mfd:
i
.
Regards
Shobhit
From: Brain WrecK [mailto:blofte...@gmail.com]
Sent: Wednesday, June 17, 2015 10:17 PM
To: Kumar, Shobhit
Cc: intel-gfx@lists.freedesktop.org
Subject: T100TA Backlight
Hello all
I am one of the people who is trying to work on getting linux working on the
ASUS T100TA
i am
On Wed, 2015-03-25 at 13:27 +0100, Linus Walleij wrote:
> On Wed, Feb 18, 2015 at 1:18 PM, Shobhit Kumar
> wrote:
>
> > Export Panel BACKLIGHT_EN(offset 0x51) and PANEL_EN(offset 0x52) as two
> > additional GPIOs. Needed by display driver to enable the DSI panel on
> > BYT platform where the Pan
On Mon, 2015-03-09 at 18:15 +0100, Linus Walleij wrote:
> On Fri, Mar 6, 2015 at 5:23 PM, Kumar, Shobhit
> wrote:
>
> > There are actually two lines for Panel Power control and Backlight
> > enable/disable. I have already moved towards adding a new Cell device
> > for
On Fri, 2015-03-06 at 12:04 +0100, Linus Walleij wrote:
> On Wed, Feb 18, 2015 at 1:18 PM, Shobhit Kumar
> wrote:
>
> > Export Panel BACKLIGHT_EN(offset 0x51) and PANEL_EN(offset 0x52) as two
> > additional GPIOs. Needed by display driver to enable the DSI panel on
> > BYT platform where the Pan
On 2/26/2015 3:43 PM, Alexandre Courbot wrote:
On Wed, Feb 18, 2015 at 9:18 PM, Shobhit Kumar wrote:
The CRC (Crystal Cove) PMIC, controls the panel enable and disable
signals for BYT for dsi panels. This is indicated in the VBT fields. Use
that to initialize and use GPIO based control for thes
On 1/12/2015 1:56 PM, Kumar, Shobhit wrote:
On 1/9/2015 6:38 PM, Jani Nikula wrote:
On Fri, 02 Jan 2015, Shobhit Kumar wrote:
This driver provides support for the "crystal_cove_panel" cell device.
On BYT-T pmic has to be used to enable/disable panel.
This needs to be sent to
On 1/9/2015 6:38 PM, Jani Nikula wrote:
On Fri, 02 Jan 2015, Shobhit Kumar wrote:
This driver provides support for the "crystal_cove_panel" cell device.
On BYT-T pmic has to be used to enable/disable panel.
This needs to be sent to dri-devel.
Will do for the updated patch after addressing a
On 1/9/2015 6:47 PM, Jani Nikula wrote:
On Fri, 02 Jan 2015, Shobhit Kumar wrote:
This allows for proper PPS during enable/disable of BYT-T platforms
where these signals are routed through PMIC. Needs DRM_PANEL to be
selected by default as well
Signed-off-by: Shobhit Kumar
---
drivers/gpu/d
On 1/9/2015 6:20 PM, Jani Nikula wrote:
On Fri, 02 Jan 2015, Shobhit Kumar wrote:
For scenarios where OF is not available, we can use panel identification by
name.
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/drm_panel.c | 18 ++
include/drm/drm_panel.h | 3 +++
2
On 1/2/2015 7:11 PM, Shobhit Kumar wrote:
Hi All
Please find modifed set of patches. Sending as a separate thread as initial
patches were a crude implementation to trigger discussion, but these have been
tested and also do not need intel_soc_pmic_writeb/readb functionaly, but uses
the regmap inte
On 1/5/2015 9:14 PM, Jani Nikula wrote:
On Mon, 05 Jan 2015, Daniel Vetter wrote:
On Fri, Dec 26, 2014 at 03:53:27PM +0530, Shobhit Kumar wrote:
As of now this includes only PPS and BLC delays. New things can be added
as and when needed
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915
On 10/29/2014 2:12 PM, Gaurav K Singh wrote:
Hi,
These set of patches build on top of the existing DSI Video mode support to
enable dual link MIPI panels with high resolutions. These patches have been
tested on a 25x16 panel and works well.
v2: Commit message added to all patches. All review co
On 7/25/2014 1:20 PM, Daniel Vetter wrote:
On Fri, Jul 25, 2014 at 09:47:06AM +0200, Daniel Vetter wrote:
On Thu, Jul 24, 2014 at 03:16:12PM +0100, rafael.barba...@intel.com wrote:
From: Rafael Barbalho
This particular nasty presented itself while trying to register the
intelfb device (intel_
On 7/24/2014 7:46 PM, rafael.barba...@intel.com wrote:
From: Rafael Barbalho
This particular nasty presented itself while trying to register the
intelfb device (intel_fbdev.c). During the process of registering the device
the driver will disable the crtc via i9xx_crtc_disable. These will
also d
On 4/11/2014 8:18 PM, Sharma, Shashank wrote:
Ok, I will change the implementation.
Regards
Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Friday, April 11, 2014 7:53 PM
To: Sharma, Shashank
Cc: Daniel Vetter; C, Ramalinga
On 7/14/2014 9:20 PM, Daniel Vetter wrote:
On Mon, Jul 14, 2014 at 4:36 PM, Kumar, Shobhit wrote:
/* XXX: read flags, set to adjusted_mode */
+ pipe_config->quirks = 1;
Nack. First you need to use one of the symbolic quirk definitions
(there's a bunch of them). Sec
On 7/12/2014 5:28 PM, Daniel Vetter wrote:
On Sat, Jul 12, 2014 at 1:47 PM, Shobhit Kumar wrote:
Call to vlv_crtc_clock_get is not needed for DSI and was causing dpio
read WARN dumps as well. Absence of ->get_config was casuing othet WARN
dumps as well. With this the last of the known WARN dump
On 6/6/2014 9:33 AM, Kumar, Shobhit wrote:
On 6/5/2014 9:34 PM, Jesse Barnes wrote:
On Thu, 5 Jun 2014 16:09:29 +0300
Ville Syrjälä wrote:
On Thu, Jun 05, 2014 at 06:25:13PM +0530, Shobhit Kumar wrote:
The DEVICE_TYPE_eDP has been changed to 0x1806 in case of BYT which
can causes wrong
On 6/5/2014 9:34 PM, Jesse Barnes wrote:
On Thu, 5 Jun 2014 16:09:29 +0300
Ville Syrjälä wrote:
On Thu, Jun 05, 2014 at 06:25:13PM +0530, Shobhit Kumar wrote:
The DEVICE_TYPE_eDP has been changed to 0x1806 in case of BYT which
can causes wrong detection failures for eDP. Reduce the number of
On 5/26/2014 6:22 PM, Jani Nikula wrote:
On Mon, 19 May 2014, Imre Deak wrote:
So far we used the wrong opcodes to access the DSI registers, so the
register writes during DSI programming didn't actually succeed and left
the registers unchanged. This wasn't a problem for the initial modeset,
whe
On 5/27/2014 9:30 PM, Imre Deak wrote:
If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at the next modeset-enable.
Note that according to the VLV2 display cluster HAS, we should disable
th
On 5/27/2014 8:42 PM, Imre Deak wrote:
On Tue, 2014-05-27 at 19:45 +0530, Kumar, Shobhit wrote:
On 5/27/2014 6:45 PM, Imre Deak wrote:
If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at
On 5/27/2014 7:49 PM, Damien Lespiau wrote:
On Tue, May 27, 2014 at 07:23:46PM +0530, Shobhit Kumar wrote:
Fix warnings introduced by the following commit -
commit 9c92da2c7c17eea79b6321b37592df0a002d24df
Author: Shobhit Kumar
Date: Fri May 23 21:35:27 2014 +0530
drm/i915: Add support
On 5/27/2014 7:47 PM, Damien Lespiau wrote:
Sorry to be such a bore but:
On Tue, May 27, 2014 at 07:33:59PM +0530, Shobhit Kumar wrote:
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -660,6 +660,10 @@ bool intel_dsi_init(struct drm_device *dev)
DRM_DEB
On 5/27/2014 6:45 PM, Imre Deak wrote:
If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at the next modeset-enable.
Note that according to the VLV2 display cluster HAS, we should disable
th
On 5/27/2014 5:02 PM, Damien Lespiau wrote:
On Fri, May 23, 2014 at 09:39:28PM +0530, Shobhit Kumar wrote:
It seems by default the VBT has MIPI configuration block as well. The
Generic driver will assume always MIPI if MIPI configuration block is found.
This is causing probelm when actually ther
On 5/27/2014 5:10 PM, Daniel Vetter wrote:
On Fri, May 23, 2014 at 09:39:28PM +0530, Shobhit Kumar wrote:
It seems by default the VBT has MIPI configuration block as well. The
Generic driver will assume always MIPI if MIPI configuration block is found.
This is causing probelm when actually there
On 5/27/2014 5:09 PM, Daniel Vetter wrote:
On Tue, May 27, 2014 at 04:51:55PM +0530, Kumar, Shobhit wrote:
On 5/27/2014 4:32 PM, Damien Lespiau wrote:
On Fri, May 23, 2014 at 09:35:27PM +0530, Shobhit Kumar wrote:
This driver makes use of the generic panel information from the VBT.
Panel
On 5/27/2014 4:32 PM, Damien Lespiau wrote:
On Fri, May 23, 2014 at 09:35:27PM +0530, Shobhit Kumar wrote:
This driver makes use of the generic panel information from the VBT.
Panel information is classified into two - panel configuration and panel
power sequence which is unique to each panel. T
On 5/21/2014 2:25 AM, Damien Lespiau wrote:
On Tue, May 20, 2014 at 09:46:01PM +0530, Shobhit Kumar wrote:
- UI is a period, so is homogeneous to time (s), but ui_num being in
s^-1 and ui_den a constant, ui_num/ui_den looks like a frequency. Or
could it be that UI = ui_den / ui_num? would
On 4/25/2014 3:24 AM, Daniel Vetter wrote:
Looking at our current dsi driver I note that:
- We don't have any slave driver right now.
- There's zero support for the hardware state readout and cross check
code.
- All the modeset state seems to be tracked in the intel_dsi structure
instead of
drm/i915: Shovel hw setup code out of i9xx_crtc_mode_set
drm/i915: Move lowfreq_avail around a bit in ilk/hsw_crtc_mode_set
drm/i915: Shovel hw setup code out of ilk_crtc_mode_set
drm/i915: Shovel hw setup code out of hsw_crtc_mode_set
drm/i915: Extract i9xx_set_pll_dividers
drm/
On 5/15/2014 6:05 AM, Jon Pry wrote:
Do you know if the DSI patch set is being maintained? I noticed it is
not integrated into drm-intel-next, the patches don't apply cleanly to
anything, and there has been no activity in about a month on them.
The basic DSI sequence is merged already and the
Hi Jani, Damien,
On 4/14/2014 11:18 AM, Shobhit Kumar wrote:
Hi,
This series enabled generic MIPI panel driver support, the ground for which
has been built up from the patches -
http://lists.freedesktop.org/archives/intel-gfx/2014-February/040764.html
http://lists.freedesktop.org/archives/intel
On 4/25/2014 2:58 PM, Chris Wilson wrote:
On Fri, Apr 25, 2014 at 11:12:06AM +0200, Daniel Vetter wrote:
On Fri, Apr 25, 2014 at 01:54:06PM +0530, Kumar, Shobhit wrote:
On 4/25/2014 1:32 PM, Daniel Vetter wrote:
I will then push a new patch on version check.
I've figured Chris could
On 4/25/2014 1:32 PM, Daniel Vetter wrote:
On Thu, Apr 24, 2014 at 09:22:23PM +0530, Kumar, Shobhit wrote:
On 4/19/2014 2:34 AM, Rodrigo Vivi wrote:
From: Chris Wilson
Be we read and chase pointers from the VBT, it is prudent to make sure
that those accesses are wholly contained within the
On 4/19/2014 2:34 AM, Rodrigo Vivi wrote:
From: Chris Wilson
Make sure that the whole BDB section is within the MMIO region prior to
accessing it contents. That we don't read outside of the secion is left
up to the individual section parsers.
Signed-off-by: Chris Wilson
Signed-off-by: Rodrigo
On 4/19/2014 2:34 AM, Rodrigo Vivi wrote:
From: Chris Wilson
Be we read and chase pointers from the VBT, it is prudent to make sure
that those accesses are wholly contained within the MMIO region, or else
we may cause a kernel panic during boot.
Signed-off-by: Chris Wilson
Signed-off-by: Rodr
On 4/14/2014 2:35 PM, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 01:24:43PM +0530, Kumar, Shobhit wrote:
On 4/14/2014 12:32 PM, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 11:00:34AM +0530, Shobhit Kumar wrote:
The parser extracts the config block(#52) and sequence(#53) data
and store in
On 4/14/2014 12:32 PM, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 11:00:34AM +0530, Shobhit Kumar wrote:
The parser extracts the config block(#52) and sequence(#53) data
and store in private data structures.
v2: Address review comments by Jani
- adjust code for the structure changes for
On 4/9/2014 8:21 PM, Daniel Vetter wrote:
On Wed, Apr 09, 2014 at 01:59:29PM +0530, Shobhit Kumar wrote:
Hi,
The changes in DSI sequence are as suggested by HW and SV teams. Notable
difference apart form few WAs is that for MIPI it is suggetsed that the
PORT is enabled before PIPE and PLANE. The
> -Original Message-
> From: intel-gfx-bounces+shobhit.kumar=intel@lists.freedesktop.org
> [mailto:intel-gfx-bounces+shobhit.kumar=intel@lists.freedesktop.org]
> On Behalf Of Vijay Purushothaman
> Sent: Friday, June 28, 2013 7:46 PM
> To: Intel Graphics
> Subject: [Intel-gfx] [PATCH
97 matches
Mail list logo
