Hello Tvrtko Ursulin,
The patch a19d6ff29a82: "drm/i915: Small compaction of the engine
init code" from Jun 23, 2016, leads to the following static checker
warning:
drivers/gpu/drm/i915/intel_lrc.c:1973 logical_render_ring_init()
warn: passing freed memory 'engine'
drivers/gpu/dr
On Thu, Dec 15, 2016 at 11:44:13PM +0300, Dan Carpenter wrote:
> Hello Tvrtko Ursulin,
>
> The patch a19d6ff29a82: "drm/i915: Small compaction of the engine
> init code" from Jun 23, 2016, leads to the following static checker
> warning:
>
> drivers/gpu/drm/i915/intel_lrc.c:1973 logical_ren
On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> > Even on fast systems a 2 microsecond delay is most likely more efficient
> > as a busy-wait loop. The overhead of a hrtimer does not seem warranted -
> > change this to a udelay(2).
>
I have a laptop with a Radeon X200M card in it. I use Radeon DRM driver
for graphics, and it makes the system hang with display off when trying
to suspend (either to disk or to RAM). Using /sys/power/pm_test
interface revealed that it freezes when suspending devices.
I have tried both Debian re
On Thu, Dec 15, 2016 at 10:27:59AM +0100, Daniel Vetter wrote:
> On Thu, Dec 15, 2016 at 10:25:19AM +0100, Daniel Vetter wrote:
> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
> > > On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> > > > Even on fast systems a 2 microsecond delay is
>-Original Message-
>From: Emil Velikov [mailto:emil.l.velikov at gmail.com]
>Sent: Wednesday, December 14, 2016 9:26 PM
>To: Nath, Arindam
>Cc: David Airlie; Deucher, Alexander; amd-gfx mailing list; ML dri-devel;
>Koenig, Christian
>Subject: Re: [PATCH 1/1] drm/amd/amdgpu: get maximum and
>-Original Message-
>From: Emil Velikov [mailto:emil.l.velikov at gmail.com]
>Sent: Thursday, December 15, 2016 5:01 PM
>To: Nath, Arindam
>Cc: David Airlie; Deucher, Alexander; amd-gfx mailing list; ML dri-devel;
>Koenig, Christian
>Subject: Re: [PATCH 1/1] drm/amd/amdgpu: get maximum and
I would like to help with fbdev maintenance. I can dedicate some time
for reviewing and handling patches but won't have time for much more.
The subsystem will remain in maintenance mode (no new drivers will be
added to it).
Cc: Tomi Valkeinen
Cc: Daniel Vetter
Signed-off-by: Bartlomiej Zolnier
On Tue, Jul 12, 2016 at 2:28 PM, Daniel Vetter wrote:
> Sure can do, but I can't find the raw patch anywhere (I suck, I know).
> Care to resend?
Hey sorry I missed this email requesting the actual patch. I reposted it here:
https://lkml.org/lkml/2016/12/14/814
Hello Gerd,
14.12.2016 11:11, Gerd Hoffmann wrote:
>> So I would be interested to know whether anyone else has thought about
>> this problem, and possibly even about an interface to let the compositor
>> pass the information. If not, would people be open to the idea? I
>> would much rather have
ubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/0738ef98/attachment.html>
>-Original Message-
>From: Grazvydas Ignotas [mailto:notasas at gmail.com]
>Sent: Thursday, December 15, 2016 5:52 PM
>To: Nath, Arindam
>Cc: Emil Velikov; David Airlie; Deucher, Alexander; ML dri-devel; amd-gfx
>mailing list; Koenig, Christian
>Subject: Re: [PATCH 1/1] drm/amd/amdgpu: get
ast_get_dram_info() configures a window in order to access BMC memory.
A BMC register can be configured to disallow this, and if so, causes
an infinite loop in the ast driver which renders the system unusable.
Fix this by erroring out if an error is detected. On powerpc systems with
EEH, this lea
On most platforms, there exists this ifdef:
#define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
This makes this patch functionally useless. However, on PPC, there is
actually an explicit definition of atomic_inc_not_zero with its own
assembly that is slightly more optimized than atomic_a
On Thu, Dec 15, 2016 at 10:47:57AM +0200, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> > usleep_range() is intended for delays in the 10us to 10ms range that need
> > good precision. a useleep_range(1, will effectively be no more than an
> > imprecise udelay with some added
On Thu, Dec 15, 2016 at 12:20:01PM +0200, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Ville Syrjälä wrote:
> > On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote:
> >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> >> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
> >> >
Hi Greg,
On Thu, Dec 15, 2016 at 8:10 PM, Greg KH wrote:
> I'll take it after 4.10-rc1 is out, thanks.
Thank you!
Jason
On most platforms, there exists this ifdef:
#define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
This makes this patch functionally useless. However, on PPC, there is
actually an explicit definition of atomic_inc_not_zero with its own
assembly that is slightly more optimized than atomic_a
On 12/15/2016 02:28 AM, Stefan Agner wrote:
> The LCD bus width does not need to align with the pixel format. The
> LCDIF controller automatically converts between pixel formats and
> bus width by padding or dropping LSBs.
>
> The DRM subsystem has the notion of bus_format which allows to
> determ
On 12/14/2016 11:32 PM, Laurent Pinchart wrote:
> Hi Peter,
>
> On Thursday 01 Sep 2016 14:22:54 Peter Ujfalusi wrote:
>> Hi,
>>
>> The following series will convert the omapdrm stack to use the generic
>> videmode instead of the private omap_video_timings struct for the panel
>> information.
>>
This is just a reposting of the patch that enables endian checks, with addition
of trivial patches that drop __bitwise__ and __CHECK_ENDIAN__ everywhere.
I plan to include this in my pull request unless I hear otherwise.
Michael S. Tsirkin (8):
linux/types.h: enable endian checks for all sparse
Reviewed-by: Stéphane Marchesin
On Tue, Dec 13, 2016 at 7:19 PM, Caesar Wang wrote:
> 10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
> TFT's as an active switching devices. It can be supported by the
> simple-panel driver.
>
> Read the panel default edid information:
101 - 122 of 122 matches
Mail list logo
