On 19 January 2015 at 21:00, Chris Wilson wrote:
> In order to suport GLX_EXT_buffer_age in DRI2, we need to pass back the
> last swap buffer count that the back buffer was defined for. For
> simplicity, we can reuse an existing field in the DRI2GetBuffers reply
> that is not used by current drive
On 9 January 2015 at 09:18, Dave Airlie wrote:
> On 8 December 2014 at 18:45, Benjamin Gaignard
> wrote:
>> Hello David,
>>
>> This series of patches fix various issues in STI drm driver.
>> Now HDMI i2c adapter could be selected in device tree
>> and plug detection doesn't use gpio anymore.
>> I
Hi,
On Monday 19 January 2015 18:05:07 Javier Martinez Canillas wrote:
> On 01/19/2015 05:30 PM, Thierry Reding wrote:
> >> I know you probably are very busy but it would be great if you can take a
> >> look to this series to avoid another kernel release to be missed since
> >> we are already at v
On 19 January 2015 at 21:03, Thomas Hellstrom wrote:
> Fixes a case where we call vmw_fifo_idle() from within a wait function with
> task state !TASK_RUNNING, which is illegal.
>
> In addition, make the locking fine-grained, so that it is performed once
> for every read- and write operation. This
Hi Linus,
Just back from LCA + some days off, had some fixes from the past 2 weeks,
some amdkfd code removal for a feature that wasn't ready,
otherwise just one fix for core helper sleeping,
exynos, i915, and radeon fixes.
I thought I had some sti fixes but they were already in, and it confused
On Thu, Jan 15, 2015 at 3:07 PM, Jan Safrata wrote:
> psb_driver_unload did not call drm_irq_uninstall causing kernel oops
> in modprobe after rmmod gma500_gfx:
>
> BUG: unable to handle kernel paging request at f858cf08
> IP: [] strcmp+0x13/0x30
> *pdpt = 016ea001 *pde = 36c44067
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/600e9795/attachment.html>
On Thu, Jan 15, 2015 at 3:10 PM, Jan Safrata wrote:
> Fixes to allow removal of gma500_gfx module (after frame buffer
> console unbind) when used with Atom E6xx gpu chipset.
>
> The oaktrail_lvds_init() uses i2c_adap only to read edid
> and therefore it should call i2c_put_adapter() after.
> Added
Hi Boris,
can you update with Thierry's acks and send again, I'll pull it then.
Dave.
On 17 January 2015 at 01:09, Thierry Reding wrote:
> On Fri, Jan 09, 2015 at 04:03:42PM +0100, Boris Brezillon wrote:
>> Dave, Thierry,
>>
>> Here is the pull request for the Atmel HLCDC driver and its
>> depe
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/6e14fe2d/attachment.html>
Mark: did you get a chance to fixup the "Reported-by" line? It's not
a bit deal if you didn't.
Dave: did you pick up this pull request? Did Mark request properly?
On Fri, Jan 9, 2015 at 12:01 PM, Daniel Kurtz wrote:
> On Wed, Jan 7, 2015 at 5:27 PM, Daniel Kurtz wrote:
>> dma_alloc_attrs() re
On 21 January 2015 at 12:43, Daniel Kurtz wrote:
> Mark: did you get a chance to fixup the "Reported-by" line? It's not
> a bit deal if you didn't.
>
> Dave: did you pick up this pull request? Did Mark request properly?
I was waiting for the fixed reported-by but it isn't that urgent, I'll
get
.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/b230aea8/attachment.html>
Hello Everyone,
Based on review comments received, I've split my earlier patchset on
'dma-buf constraints-enabled allocation' [1] into 2 sets:
- first one is this one, to use dma_parms and related parameters from
struct device to share constraints, and then to use these constraints in
dma-bu
From: Rob Clark
For devices which have constraints about maximum number of segments in
an sglist. For example, a device which could only deal with contiguous
buffers would set max_segment_count to 1.
The initial motivation is for devices sharing buffers via dma-buf,
to allow the buffer exporter
Add some helpers to share the constraints of devices while attaching
to the dmabuf buffer.
At each attach, the constraints are calculated based on the following:
- dma_mask, coherent_dma_mask from struct device,
- max_segment_size, max_segment_count, segment_boundary_mask from
device_dma_parame
Hi, Dave,
It's intended for -fixes. I was just about to send a pull request but
got distracted.
Thanks,
Thomas
On 01/21/2015 12:45 AM, Dave Airlie wrote:
> On 19 January 2015 at 21:03, Thomas Hellstrom
> wrote:
>> Fixes a case where we call vmw_fifo_idle() from within a wait function with
>>
vel/attachments/20150121/90a2f345/attachment.html>
iving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/47e4120c/attachment.html>
On Tue, Jan 20, 2015 at 01:03:51PM -0500, Rob Clark wrote:
> Since drm_helper_probe_single_connector_modes_merge_bits() and other
> places also update connector->status, the output_poll_execute() and/or
> drm_helper_hpd_irq_event() logic can get confused and forget to send
> a HPD event.
>
> There
There's a race window (small for hpd, 10s large for polled outputs)
where userspace could sneak in with an unrelated connnector probe
ioctl call and eat the hotplug event (since neither the hpd nor the
poll code see a state change).
To avoid this, check whether the connector state changes in all o
On some chipset we try to avoid possibly invasive output detection
methods (like load detect which can cause flickering elsewhere) in the
output poll work. Drivers could hence return unknown when a previous
full ->detect call returned a different state.
This change will generate a hotplug event, f
Not a new type exposed to userspace, just a standard way to create
them since between range, bitmask and enum there's 3 different ways to
pull out a boolean prop.
Also add the kerneldoc for the recently added new prop types, which
Rob forgot all about.
v2: Fixup kerneldoc, spotted by Rob.
Cc: Ro
and issues. Please report a new bug for your problem.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/5c0751fb/attachment.html>
From: Michel Dänzer
radeon_vm_map_gart can use rdev->gart.pages_entry instead.
Also move the masking of the page address to radeon_vm_map_gart from its
callers.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/cik_sdma.c| 1 -
drivers/gpu/drm/radeon/ni_dma.c | 1 -
drivers
From: Michel Dänzer
The GART table BO has to be moved out of VRAM for suspend/resume. Any
updates to the GART table during that time were silently dropped without
this change. This caused GPU lockups on resume in some cases, see the bug
reports referenced below.
This might also make GPU reset m
From: Michel Dänzer
get_page_entry calculates the GART page table entry, which is just written
to the GART page table by set_page_entry.
This is a prerequisite for the following fix.
Cc: stable at vger.kernel.org
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/r100.c | 10 +
*Facebook <http://www.facebook.com/pages/Linaro> | Twitter
<http://twitter.com/#!/linaroorg> | Blog
<http://www.linaro.org/linaro-blog/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/28753478/attachment-0001.html>
Hi Dave,
Here is the pull request for the Atmel HLCDC driver and its
dependencies (some modifications to drm/core and drm/panel to define
output bus format).
I've added Thierry's acks and rebased on drm-next, let me know if you
need something else.
Best Regards,
Boris
The following changes sinc
Hey,
Op 14-01-15 om 03:16 schreef Zhou, Jammy:
>>> I think it would be best to leave timeout=0 returning 0. Not handling it
>>> differently gives the same semantics as used by fence_wait_time and
>>> wait_event_timeout.
>>> Are there really many cases in which you don't know if timeout = 0 befor
Am 21.01.2015 um 09:36 schrieb Michel Dänzer:
> From: Michel Dänzer
>
> The GART table BO has to be moved out of VRAM for suspend/resume. Any
> updates to the GART table during that time were silently dropped without
> this change. This caused GPU lockups on resume in some cases, see the bug
> r
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Maarten Lankhorst changed:
What|Removed |Added
Attachment #163871|0 |1
is obsolete|
Sure. I will send the patches out later.
Regards,
Jammy
-Original Message-
From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com]
Sent: Wednesday, January 21, 2015 5:12 PM
To: Zhou, Jammy; Daniel Vetter
Cc: Koenig, Christian; dri-devel; Deucher, Alexander
Subject: Re: [PATCH] r
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Maarten Lankhorst changed:
What|Removed |Added
Attachment #164121|0 |1
is obsolete|
When the timeout value passed to reservation_object_wait_timeout_rcu
is zero, no wait should be done if the fences are not signaled.
Return '1' for idle and '0' for busy if the specified timeout is '0'
to keep consistent with the case of non-zero timeout.
v2: call fence_put if not signaled in the
When specified timeout is zero for fence_wait_timeout, just check if the fence
is signaled or not without wait.
Signed-off-by: Jammy Zhou
---
drivers/dma-buf/fence.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index e554111..50ef8bd 10
d...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/8e9bc941/attachment.html>
org/archives/dri-devel/attachments/20150121/283178ca/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/29271709/attachment.html>
ed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/db6f77e1/attachment-0001.html>
https://bugs.freedesktop.org/show_bug.cgi?id=88408
--- Comment #15 from Iwo ---
Here is glxinfo:
[iwo at antec ~]$ glxinfo
name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_conte
information
BusID "PCI:1:0:0"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor"Monitor0"
SubSection "Display"
Viewport 0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/ca1825b6/attachment.html>
Op 21-01-15 om 11:35 schreef Jammy Zhou:
> When the timeout value passed to reservation_object_wait_timeout_rcu
> is zero, no wait should be done if the fences are not signaled.
>
> Return '1' for idle and '0' for busy if the specified timeout is '0'
> to keep consistent with the case of non-zero t
Op 21-01-15 om 11:35 schreef Jammy Zhou:
> When specified timeout is zero for fence_wait_timeout, just check if the fence
> is signaled or not without wait.
>
> Signed-off-by: Jammy Zhou
>
Reviewed-By: Maarten Lankhorst
|Kabini |playback on Kabini
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/b50bc2a6/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/a3a25907/attachment.html>
This patch replaces the two current amdkfd module parameters with a new one.
The current parameters that are being replaced are:
- Maximum number of HSA processes
- Maximum number of queues per process
The new parameter that replaces them is called "Maximum queues per device"
This replacement a
Am 21.01.2015 um 11:35 schrieb Jammy Zhou:
> When specified timeout is zero for fence_wait_timeout, just check if the fence
> is signaled or not without wait.
>
> Signed-off-by: Jammy Zhou
Reviewed-by: Christian König
> ---
> drivers/dma-buf/fence.c | 3 +++
> 1 file changed, 3 insertions(+
https://bugzilla.kernel.org/show_bug.cgi?id=91371
Adis HamziÄ changed:
What|Removed |Added
CC||adis at hamzadis.com
--- Comment #2 from A
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/9a42018a/attachment.html>
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: 0e3c37cedf582819b6dbdd0bf0b14a15d3c2e47d
commit: d7a60d8ea5cd4560e0496d2683643d2e4930e609 [357/550] drm/radeon: Enable
sdma preemption
reproduce:
# apt-get install sparse
git checkout d7a60d8ea5cd4560e0496d2683643d2e4930
drivers/gpu/drm/radeon/cik_sdma.c:293:6: sparse: symbol
'cik_sdma_ctx_switch_enable' was not declared. Should it be static?
Signed-off-by: Fengguang Wu
---
cik_sdma.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c
b/drivers/gpu/drm/rade
d.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/8c732533/attachment.html>
Hi Dave,
Another pull request for 3.20.
drm-amdkfd-next-2015-01-21:
- Infrastructure work in amdkfd to prepare for VI support. This work mainly
includes separating modules into ASIC-specific functionality, adding
new properties that are relevant for VI, making sure that shared code is
r
There's a race window (small for hpd, 10s large for polled outputs)
where userspace could sneak in with an unrelated connnector probe
ioctl call and eat the hotplug event (since neither the hpd nor the
poll code see a state change).
To avoid this, check whether the connector state changes in all o
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/e9c324db/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Maarten Lankhorst changed:
What|Removed |Added
Attachment #164131|0 |1
is obsolete|
think my first bisect is still valid for that.
--
You are receiving this mail because:
You are the assignee for the bug.
------ next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/749e9597/attachment.html>
rn an -EINVAL if
clk_has_parent() fails.
> > + */
> > +int clk_try_parent(struct clk *clk, struct clk *parent);
>
> The name makes me think of mutex_trylock(), so I immediately think this
> tries to set the parent. Perhaps a better name would be
> clk_can_have_parent() or clk_has_parent()?
clk_has_parent() sounds good to me.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/abc9003e/attachment.sig>
required.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/f9fcce2d/attachment-0001.sig>
ter the latest Radeon updates to Linus' 3.19.0-rc5,
lock-up occurred sooner.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attac
From: Thierry Reding
This new function is similar to clk_set_parent(), except that it doesn't
actually change the parent. It merely checks that the given parent clock
can be a parent for the given clock.
A situation where this is useful is to check that a particular setup is
valid before switchi
On Wed, Jan 21, 2015 at 5:31 AM, Maarten Lankhorst
wrote:
> Op 21-01-15 om 11:35 schreef Jammy Zhou:
>> When the timeout value passed to reservation_object_wait_timeout_rcu
>> is zero, no wait should be done if the fences are not signaled.
>>
>> Return '1' for idle and '0' for busy if the specifie
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/63b9e90e/attachment.html>
On Mon, 12 Jan 2015, Jeremiah Mahler wrote:
> Commit 6dda730e55f4 introduced a bug which resulted in inconsistent
> brightness levels on different machines. If a suspended was entered
> with the screen off some machines would resume with the screen
> at minimum brightness and others at maximum bri
On Fri, Oct 31, 2014 at 6:53 PM, Steve Longerbeam
wrote:
> Hi, this affects only Freescale imx IPU and imx-drm staging drivers,
> except for two patches that affect drm core (patch 53 and 63, see below).
>
> New features for imx-drm staging driver:
>
> - Support for multi-display (HDMI and LVDS).
Hey,
On 21-01-15 17:16, Alex Deucher wrote:
> On Wed, Jan 21, 2015 at 5:31 AM, Maarten Lankhorst
> wrote:
>> Op 21-01-15 om 11:35 schreef Jammy Zhou:
>>> When the timeout value passed to reservation_object_wait_timeout_rcuy,
>>> is zero, no wait should be done if the fences are not signaled.
>>>
On Wed, Jan 21, 2015 at 09:46:47AM +0530, Sumit Semwal wrote:
> +static int calc_constraints(struct device *dev,
> + struct dma_buf_constraints *calc_cons)
> +{
> + struct dma_buf_constraints cons = *calc_cons;
> +
> + cons.dma_mask &= dma_get_mask(dev);
I don't thi
On Wed, Jan 21, 2015 at 12:30 PM, Maarten Lankhorst
wrote:
> Hey,
>
> On 21-01-15 17:16, Alex Deucher wrote:
>> On Wed, Jan 21, 2015 at 5:31 AM, Maarten Lankhorst
>> wrote:
>>> Op 21-01-15 om 11:35 schreef Jammy Zhou:
When the timeout value passed to reservation_object_wait_timeout_rcuy,
>>>
Am Dienstag, den 20.01.2015, 20:44 -0200 schrieb Fabio Estevam:
> From: Fabio Estevam
>
> In the case of errors we should propagate them.
>
> Signed-off-by: Fabio Estevam
> ---
> Changes since v2:
> - Propage the error in more places like suggested by Philipp
Thank you, I have queued this patc
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #16 from Gustaw Smolarczyk ---
Unfortunately, the last patch doesn't seem to help in any way. Should I test
the other two too?
--
You are receiving this mail because:
You are watching the assignee of the bug.
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/69d317f2/attachment.html>
On Wed, Jan 21, 2015 at 06:44:05PM +, Liviu Dudau wrote:
> On Fri, Nov 07, 2014 at 08:31:25AM +, Andrew Jackson wrote:
> > The I2C address for the TDA9989 and TDA19989 is fixed at 0x34
> > but the two LSBs of the TDA19988's address are set by two configuration
> > pins on the chip. Irrespe
On Fri, Nov 07, 2014 at 08:31:25AM +, Andrew Jackson wrote:
> The I2C address for the TDA9989 and TDA19989 is fixed at 0x34
> but the two LSBs of the TDA19988's address are set by two configuration
> pins on the chip. Irrespective of the chip, the associated CEC
> peripheral's I2C address is b
On Wed, Jan 21, 2015 at 06:46:58PM +, Russell King - ARM Linux wrote:
> On Wed, Jan 21, 2015 at 06:44:05PM +, Liviu Dudau wrote:
> > On Fri, Nov 07, 2014 at 08:31:25AM +, Andrew Jackson wrote:
> > > The I2C address for the TDA9989 and TDA19989 is fixed at 0x34
> > > but the two LSBs of
On some (well, maybe just one) HDMI monitor I get a spurious disconnect
in the process of lighting up the display. A low-pass filter on HPD
events, in the form of leaving the HPD irq disabled for 100ms after the
previous HPD irq, seems to do a good job of working around the issue.
A somewhat simp
On Wed, Jan 21, 2015 at 2:47 AM, Daniel Vetter
wrote:
> Not a new type exposed to userspace, just a standard way to create
> them since between range, bitmask and enum there's 3 different ways to
> pull out a boolean prop.
>
> Also add the kerneldoc for the recently added new prop types, which
>
On Wed, Jan 21, 2015 at 9:41 AM, Daniel Vetter
wrote:
> There's a race window (small for hpd, 10s large for polled outputs)
> where userspace could sneak in with an unrelated connnector probe
> ioctl call and eat the hotplug event (since neither the hpd nor the
> poll code see a state change).
>
On Wed, Jan 21, 2015 at 2:45 AM, Daniel Vetter
wrote:
> On some chipset we try to avoid possibly invasive output detection
> methods (like load detect which can cause flickering elsewhere) in the
> output poll work. Drivers could hence return unknown when a previous
> full ->detect call returned
Looks basically sane.. you have a branch on top of drm-next w/ this
patchset somewhere? There is enough to it that I probably need to
actually try it out and see what explodes ;-)
couple minor comments below
On Tue, Jan 20, 2015 at 5:09 PM, Daniel Vetter
wrote:
[snip]
> diff --git a/drivers/g
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150121/889454b9/attachment.html>
In cases where MMU_NOTIFIER is not available, userptr will not be
available. Similar to i915, although not making an exception for
CAP_SYS_ADMIN.
The proposed userspace patches for userptr seem to handle the fall-
back properly, so a userptr-less kernel should not be a problem.
Signed-off-by: Ro
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/651df3a5/attachment.html>
The rotation property is shared by multiple drivers, so it makes sense
to store the rotation value (for atomic-converted drivers) in the common
plane state so that core code can eventually access it as well.
Cc: dri-devel at lists.freedesktop.org
Suggested-by: Daniel Vetter
Signed-off-by: Matt Ro
Hi All
Please find modifed set of patches using regmap interface to accedd the PMIC
registers. These patches implement a drm_panel as a platform driver for the
mfd_cell device declared in intel_soc_pmic_core.c.
DRM is extended to provide a find panel by name in absence of OF.
Backlight control
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 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/
On BYT-T configuration, panel enable/disable signals are routed through
PMIC. Add a cell device for the same.
Signed-off-by: Shobhit Kumar
---
drivers/mfd/intel_soc_pmic_crc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc
This driver provides support for the "crystal_cove_panel" cell device.
On BYT-T pmic has to be used to enable/disable panel.
v2: Addressed Jani's comments
- Moved inside i915
- Correct licensing
- Remove unused stuff
- Do not initialize prepare/unprepare as they are not needed as o
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
v2: Adapt to panel find function name change in drm_panel
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/Kconfig
David,
Please incorporate the latest TDA998x I2C driver fixes, which can be found at:
git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-tda998x-fixes
with SHA1 cfe387572585216ffd452256181a719ca90b529e.
This will update the following files:
drivers/gpu/drm/i2c/tda998x_drv.c | 52
Hello!
Inki Dae wrote:
> The use of spin lock, reg_slock, has been used for a long time and we
> hadn't some cleanups to spin lock codes so far. The spin lock is also
> used in here and there of mixer driver. And at least, it seems that
> the use of spin lock isn't required in mixer_win_reset. I
sts.freedesktop.org/archives/dri-devel/attachments/20150121/9442eb26/attachment-0001.sig>
On 01/21/2015 08:13 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> This new function is similar to clk_set_parent(), except that it doesn't
> actually change the parent. It merely checks that the given parent clock
> can be a parent for the given clock.
>
> A situation where this is useful i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adam Cheney (1):
Add new DRM_MODE_CONNECTOR and _ENCODER defines
Chris Wilson (1):
intel: Avoid overcounting fences when emitting self-referential relocs
Damien Lespiau (3):
intel/skl: Add SKL PCI ids
intel/skl: Add gen9 to th
I'm doing memory allocation failure injection test using 3.19-rc5 and
it seems to me that there is a memory corruption bug in ttm or vmwgfx code.
-- Crash pattern 1 start --
[ 80.751971] [TTM] Failed allocating page table
[ 83.000393] BUG: unable to handle kernel NULL pointer d
Hi Sumit,
On 21/01/15 04:16, Sumit Semwal wrote:
> From: Rob Clark
>
> For devices which have constraints about maximum number of segments in
> an sglist. For example, a device which could only deal with contiguous
> buffers would set max_segment_count to 1.
>
> The initial motivation is for dev
96 matches
Mail list logo
