Hi Ville,
On Mon, Jun 18, 2018 at 03:09:15PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 07, 2018 at 11:06:33AM +0100, Sudip Mukherjee wrote:
> > Hi All,
> >
> > We are running v4.14.47 kernel and recently in one of our test cycle
> > we saw the below trace. I know t
On Thu, Jun 07, 2018 at 11:06:33AM +0100, Sudip Mukherjee wrote:
> Hi All,
>
> We are running v4.14.47 kernel and recently in one of our test cycle
> we saw the below trace. I know this is not the usual way to raise a
> BUG report, but since this was seen only once in one of the a
Hi All,
We are running v4.14.47 kernel and recently in one of our test cycle
we saw the below trace. I know this is not the usual way to raise a
BUG report, but since this was seen only once in one of the automated
test cycle so I donot have anything else apart from this trace.
Is this a known iss
On Mon, May 09, 2016 at 11:19:16AM +0300, Jani Nikula wrote:
> On Fri, 06 May 2016, Sudip Mukherjee wrote:
> > On Fri, May 06, 2016 at 12:21:04PM +0100, Sudip Mukherjee wrote:
> >> Hi Daniel,
> >> I am trying to use i915 in one of our board which has Intel ATOM E
On Fri, May 06, 2016 at 12:21:04PM +0100, Sudip Mukherjee wrote:
> Hi Daniel,
> I am trying to use i915 in one of our board which has Intel ATOM E3840.
> I know Intel has released emgd driver for this cpu to use i915 but emgd
> is not supported on v4.5 (or v4.6). The board is having
Hi Daniel,
I am trying to use i915 in one of our board which has Intel ATOM E3840.
I know Intel has released emgd driver for this cpu to use i915 but emgd
is not supported on v4.5 (or v4.6). The board is having SFI (simple
firmware interface) and maybe for that i915 is not finding the VBIOS and
oth
On Thu, Oct 08, 2015 at 04:29:31PM +0200, Daniel Vetter wrote:
> On Thu, Oct 08, 2015 at 07:28:00PM +0530, Sudip Mukherjee wrote:
> > We were not checking the return value of drm_encoder_init() which can
> > fail. And if it fails then we will be working with an uninitiali
We were not checking the return value of drm_encoder_init() which can
fail. And if it fails then we will be working with an uninitialized
encoder.
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-by: Sudip Mukherjee
---
Sent on 27/07/2015
drivers/gpu/drm/i915/intel_dp.c | 6 --
1 file
: Sudip Mukherjee
---
Sent on 27/07/2015
drivers/gpu/drm/i915/intel_dp.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8d34ca7..18bcfbe 100644
--- a/drivers/gpu/drm/i915
On Mon, Aug 03, 2015 at 12:54:33PM +0200, Daniel Vetter wrote:
> On Mon, Aug 03, 2015 at 02:56:42PM +0530, Sudip Mukherjee wrote:
> > On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote:
> > > debugfs files are not necessary for the usual operation of the driver
&g
On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote:
> debugfs files are not necessary for the usual operation of the driver
> and the device. No need to check for the return values from the debugfs
> file creation. Even if one debugfs file fails to create we try with t
We were not checking the return value of drm_encoder_init() which can
fail. And if it fails then we will be working with an uninitialized
encoder.
Signed-off-by: Sudip Mukherjee
---
drivers/gpu/drm/i915/intel_dp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers
Use goto to handle the error path to avoid duplicating the same code. In
the error path intel_dig_port is the last one to be released as it was
the first one to be allocated and ideally the error path should be the
reverse of the execution path.
Signed-off-by: Sudip Mukherjee
---
drivers/gpu
to load.
cleanup will clean all the created debugfs files as the list of file
that are created are maintained in minor->debugfs_list.
Cc: Chris Wilson
Signed-off-by: Sudip Mukherjee
---
v1 was drm/i915: add error path
drivers/gpu/drm/i915/i915_debugfs.c | 31 ---
On Wed, Jul 22, 2015 at 12:39:37PM +0100, Chris Wilson wrote:
> On Wed, Jul 22, 2015 at 04:58:47PM +0530, Sudip Mukherjee wrote:
> > If any of the debug file creation fails we were just returning the
> > error code to the drm layer. But the debug files that we created in the
>
If any of the debug file creation fails we were just returning the
error code to the drm layer. But the debug files that we created in the
process were not removed. And debugfs files are not automatically
cleaned up.
Signed-off-by: Sudip Mukherjee
---
Hi Daniel,
Whom should i keep Cc: for this
On Tue, Jul 21, 2015 at 03:51:40PM +0200, Daniel Vetter wrote:
> On Tue, Jul 21, 2015 at 05:36:45PM +0530, Sudip Mukherjee wrote:
> > While creating the debugfs file we are setting the inode->i_private to
> > dev. That same dev is passed to these functions as private of struc
The extra check for connector_type is not required as we are already
checking for connector_type != DRM_MODE_CONNECTOR_DisplayPort.
The check was added by commit eb3394faeb97 ("drm/i915: Add debugfs test
control files for Displayport compliance testing")
Signed-off-by: Sudip Mukherjee
added by commit eb3394faeb97 ("drm/i915: Add debugfs test
control files for Displayport compliance testing")
Signed-off-by: Sudip Mukherjee
---
v3: removed the check in i915_displayport_test_active_write also
v2: removed null check
v1 was drm/i915: fix possible null pointer dereferenc
On Mon, Jul 20, 2015 at 05:33:50PM +0200, Daniel Vetter wrote:
> On Mon, Jul 20, 2015 at 08:36:01PM +0530, Sudip Mukherjee wrote:
> > While creating the debugfs file we are setting the inode->i_private to
> > dev. That same dev is passed to these functions as private of struc
While creating the debugfs file we are setting the inode->i_private to
dev. That same dev is passed to these functions as private of struct
seq_file via single_open(). So at this point it can never be NULL.
Signed-off-by: Sudip Mukherjee
---
v1 was drm/i915: fix possible null poin
On Mon, Jul 20, 2015 at 01:38:46PM +0100, Chris Wilson wrote:
> On Mon, Jul 20, 2015 at 05:59:29PM +0530, Sudip Mukherjee wrote:
> > We were dereferencing dev first and then checking if it is NULL. Lets
> > check for NULL first and then dereference.
>
> The code is bonkers.
We were dereferencing dev first and then checking if it is NULL. Lets
check for NULL first and then dereference.
Signed-off-by: Sudip Mukherjee
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b
On Wed, May 13, 2015 at 01:27:06PM +0200, Thomas Gummerer wrote:
> Sudip Mukherjee writes:
>
> > On Wed, May 13, 2015 at 11:53:19AM +0200, Jan Niehusmann wrote:
> > http://patchwork.freedesktop.org/patch/46071/
>
> Thank you for the pointer, but this seems to be an unr
On Wed, May 13, 2015 at 01:10:11PM +0200, Jan Niehusmann wrote:
> On Wed, May 13, 2015 at 04:02:25PM +0530, Sudip Mukherjee wrote:
> > > What I'm missing in the report, are some log entries I'm seeing on my
> > > notebook:
> > >
On Wed, Apr 01, 2015 at 10:01:50AM +0530, Sudip Mukherjee wrote:
> On Tue, Mar 31, 2015 at 04:35:49PM +0100, Chris Wilson wrote:
> > On Tue, Mar 31, 2015 at 08:40:12PM +0530, Sudip Mukherjee wrote:
> > > This reverts commit <0f71979ab7fbd0c71c41c2798de3d33937915434>.
>
On Tue, Mar 31, 2015 at 04:35:49PM +0100, Chris Wilson wrote:
> On Tue, Mar 31, 2015 at 08:40:12PM +0530, Sudip Mukherjee wrote:
> > This reverts commit <0f71979ab7fbd0c71c41c2798de3d33937915434>.
> >
> > my display was getting garbled for a moment very frequently.
is not having that problem.
Signed-off-by: Sudip Mukherjee
---
my system is x86_64.
lspci -k gives:
"VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
processor Graphics Controller (rev 09)
Subsystem: Foxconn International, Inc. Device 0d74
Kernel driver in use: i91
On Thu, Jan 01, 2015 at 05:22:15PM +0300, Andrey Skvortsov wrote:
> Hi,
>
> this warning does not exist in 3.19-rc1, but it happens every boot in
> 3.19-rc2. If you need any other information or data, I would be glad
> to help to debug it.
mine is also i915, but i am not seeing any warning. if y
29 matches
Mail list logo
