On Tue, Jun 24, 2014 at 6:26 AM, Greg KH wrote:
> On Mon, Jun 23, 2014 at 04:18:39PM -0400, Ilia Mirkin wrote:
>> On Mon, Jun 23, 2014 at 4:15 PM, Pavel Machek wrote:
>> > Hi!
>> >
>> >> >> >> > I guess better interface would be something like
>> >> >> >> >
>> >> >> >> > pstate/07/core_clock_min
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/12fd4560/attachment.html>
Hi Joe,
On Tue, Jun 24, 2014 at 5:13 AM, Joe Perches wrote:
> On Mon, 2014-06-23 at 10:25 -0700, Luis R. Rodriguez wrote:
>> On Mon, Jun 23, 2014 at 06:41:28AM -0700, Joe Perches wrote:
>> > Adding the helper reduces object code size as well as overall
>> > source size line count.
>> >
>> > It's
.org/archives/dri-devel/attachments/20140624/e3b29061/attachment-0001.html>
ing 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/20140624/65f7c61b/attachment.html>
-
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/20140624/d0529230/attachment.html>
Looks good to me.
Reviewed-by: Zhenyu Wang
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Dig
Hi Tomasz,
On 23 June 2014 20:08, Tomasz Figa wrote:
> Hi Rahul,
>
> On 23.06.2014 15:58, Rahul Sharma wrote:
>> Hi Ajay, Inki,
>>
>> I tested this series for Exynos5420 based peach-pit board,
>> Exynos5800 based Peach-pi board and Exynos5250 based
>> Snow board. I verified with the chrome test e
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/7d81985c/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/89e72de3/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/668aa0e2/attachment.html>
e.
--
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/20140624/8fe3bf55/attachment-0001.html>
On 2014? 06? 23? 14:32, Rahul Sharma wrote:
> Allowing only one layer update per vsync can cause issues
> while there are update available for both layers. There is
> a good amount of possibility to loose updates if we allow
> single update per vsync.
>
> Signed-off-by: Rahul Sharma
> ---
> driv
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/6bf0a73d/attachment.html>
es just yet, they don't seem to be working yet.
--
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/20140624/69d069a8/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/36dd5f81/attachment.html>
On 23.06.2014 18:56, Christian K?nig wrote:
> Am 23.06.2014 10:15, schrieb Michel D?nzer:
>> On 19.06.2014 18:45, Christian K?nig wrote:
>>
>>> I think even when we revert to the old code we have a couple of unsolved
>>> problems with the VM support or in the driver in general where we should
>>> t
ving 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/20140624/cf5fb343/attachment.html>
For this v2 I have fixed the patches that are non-controversial (all Lucas' :))
and am resubmitting them in the hope that they will get merged. This will
just leave the issue of Nouveau system-memory buffers mapping to be solved.
This issue is quite complex, so let me summarize the situation and t
From: Lucas Stach
Signed-off-by: Lucas Stach
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1df856f78568..30e5d90cb7bc 100644
From: Lucas Stach
On architectures for which access to GPU memory is non-coherent,
caches need to be flushed and invalidated explicitly at the
appropriate places. Introduce two small helpers to make things
easy for TTM-based drivers.
Signed-off-by: Lucas Stach
Signed-off-by: Alexandre Courbot
From: Lucas Stach
Use the newly-introduced TTM cache sync functions in Nouveau.
Signed-off-by: Lucas Stach
[acourbot at nvidia.com: rearrange code, make platform-friendly]
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 47 +++
driv
On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
> From: Lucas Stach
>
> On architectures for which access to GPU memory is non-coherent,
> caches need to be flushed and invalidated explicitly at the
> appropriate places. Introduce two small helpers to make things
> easy for TTM
On 24.06.2014 05:32, Dieter N?tzel wrote:
> Am 23.06.2014 21:46, schrieb Dieter N?tzel:
>> Am 23.06.2014 11:34, schrieb Michel D?nzer:
>>> On 18.06.2014 18:14, Christian K?nig wrote:
Am 18.06.2014 07:53, schrieb Michel D?nzer:
>
> (WW) RADEON(0): radeon_dri2_flip_event_handler: Pagef
On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
> On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
>> From: Lucas Stach
>>
>> On architectures for which access to GPU memory is non-coherent,
>> caches need to be flushed and invalidated explicitly at the
>> appropriate pla
On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
>> On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
>>> From: Lucas Stach
>>>
>>> On architectures for which access to GPU memory is non-coherent,
>>> caches need to be flus
https://bugzilla.kernel.org/show_bug.cgi?id=78221
--- Comment #9 from t3st3r at mail.ru ---
Hmm, this patch does not applies cleanly to 3.16-rc1 or -rc2, mostly having
bunch of conflicts in radeon_vm.c, which are a bit over my head to resolve at
this point. Which version of kernel I'm supposed to
On Thu, 19 Jun 2014, Randy Dunlap wrote:
> On 06/18/14 23:16, Stephen Rothwell wrote:
>> Hi all,
>>
>> The powerpc allyesconfig is again broken more than usual.
>>
>> Changes since 20140618:
>>
>
> on i386:
>
> CONFIG_ACPI is not enabled.
>
> CC drivers/gpu/drm/i915/i915_drv.o
> ../drive
On Tue, 2014-06-24 at 09:27 +1000, Julian Calaby wrote:
> > - x = (T)pci_alloc_consistent(E1,E2,E3);
> > + x = pci_zalloc_consistent(E1,E2,E3);
> > if ((x==NULL) || ...) S
> > - memset((T2)x,0,E2);
>
> I don't know much about SmPL, but wouldn't having that if statement
> there reduce your match
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/454bcacc/attachment.html>
op 24-06-14 14:23, Alexandre Courbot schreef:
> On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot
> wrote:
>> On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
>>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
>
Hi Ajay,
On 06/24/2014 01:09 PM, Ajay Kumar wrote:
> Add the missing setting for DP CLKCON register.
>
> This register is present on Exynos5 based FIMD controllers,
> and needs to be used if we are using DP.
>
> Signed-off-by: Ajay Kumar
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c |5
On Tue, Jun 24, 2014 at 09:23:05PM +0900, Alexandre Courbot wrote:
> On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot
> wrote:
> > The only alternative I see here is to flush the CPU caches when syncing for
> > the device, and invalidate them for the other direction. Of course if the
> > device
L:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/69b0e967/attachment.html>
Am Dienstag, den 24.06.2014, 22:52 +0900 schrieb Alexandre Courbot:
> On Tue, Jun 24, 2014 at 10:25 PM, Lucas Stach
> wrote:
> > Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst:
> >> op 24-06-14 14:23, Alexandre Courbot schreef:
> >> > On Tue, Jun 24, 2014 at 7:55 PM, Alexandre
Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst:
> op 24-06-14 14:23, Alexandre Courbot schreef:
> > On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot
> > wrote:
> >> On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
> >>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
On 06/24/2014 03:14 PM, Ajay kumar wrote:
> On Tue, Jun 24, 2014 at 9:01 AM, Andrzej Hajda wrote:
>> Hi Ajay,
>>
>> On 06/24/2014 01:09 PM, Ajay Kumar wrote:
>>> Add the missing setting for DP CLKCON register.
>>>
>>> This register is present on Exynos5 based FIMD controllers,
>>> and needs to be
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/b459f033/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=78661
--- Comment #3 from Nikolaus Waxweiler ---
Created attachment 140851
--> https://bugzilla.kernel.org/attachment.cgi?id=140851&action=edit
Full dmesg output for the day where the hangs occured up to the bug report
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=78661
--- Comment #4 from Nikolaus Waxweiler ---
Will try radeon.dpm=0 and report back.
--
You are receiving this mail because:
You are watching the assignee of the bug.
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/65bc0b44/attachment.html>
Hi Dave,
This pull-request fixes hdmi power-off order issue, mixer issues
related to power on/off, and includes trivial fixups.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:
Linux 3.16-rc
2014-06-24 20:38 GMT+09:00 Andreas F?rber :
> Am 24.06.2014 07:21, schrieb Inki Dae:
>> On 2014? 06? 23? 14:32, Rahul Sharma wrote:
>>> Allowing only one layer update per vsync can cause issues
>>> while there are update available for both layers. There is
>>> a good amount of possibility to loose
On Mon, Jun 16, 2014 at 12:11:20PM +0200, Denis Carikli wrote:
> We need a way to pass signal polarity informations
> between DRM panels, and the display drivers.
>
> To do that, a pol_flags field was added to drm_display_mode.
>
> Signed-off-by: Denis Carikli
This patch needs an ack from the
On Mon, Jun 16, 2014 at 12:11:19PM +0200, Denis Carikli wrote:
> The imx-drm driver can't use the de-active and
> pixelclk-active display-timings properties yet.
>
> Instead the data-enable and the pixel data clock
> polarity are hardcoded in the imx-drm driver.
>
> So theses properties are now s
Denis,
This patch creates binding documentation. Any patch which does so
should be copied to the DT people so they can review the bindings
and give appropriate acks. It would be better if you separate the
binding documentation updates from the other functional changes too.
I've added them on th
On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli
It would be nice to have a little more explanation in the commit messages
for these patches. If you'd like to send me better commit messages for
these patches, I'll add them to what I already have:
On Tue, Jun 24, 2014 at 10:06:06AM +1000, Ben Skeggs wrote:
>
> But, as I said on IRC yesterday, let's just move this to debugfs to
> save this waste of time argument, and move on.
I like that idea, great plan :)
greg k-h
https://bugzilla.kernel.org/show_bug.cgi?id=78221
Alex Deucher changed:
What|Removed |Added
Attachment #140711|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=78221
Alex Deucher changed:
What|Removed |Added
Attachment #140721|0 |1
is obsolete|
://lists.freedesktop.org/archives/dri-devel/attachments/20140624/167f6243/attachment.html>
On Tue, Jun 24, 2014 at 06:25:19PM +0200, Denis Carikli wrote:
> On 06/24/2014 05:13 PM, Russell King - ARM Linux wrote:
> [...]
>> If you'd like to send me better commit messages for
>> these patches, I'll add them to what I already have:
>
>> imx-drm: use defines for clock polarity settings
On Tue, Jun 17, 2014 at 11:17:03AM -0300, Guido Mart?nez wrote:
> Currently tda998x_encoder_destroy() calls cec_write() and reg_clear(),
> as part of the release procedure. Such calls need to access the I2C bus
> and therefore, we need to call them before drm_i2c_encoder_destroy()
> which unregiste
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/4f1b4101/attachment.html>
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/bc05ccec/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/6aacf143/attachment.html>
I'll fall back down to 3.13 for now and try
to get it to occur.
--
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/20140624/badc9fd4/attachment.html>
A while back, Laurent raised some comments about the component helper,
which this patch set starts to address.
The first point it addresses is the repeated parsing inefficiency when
deferred probing occurs. When DT is used, the structure of the
component helper today means that masters end up par
On Tue, Jun 24, 2014 at 10:58 PM, Lucas Stach wrote:
> Am Dienstag, den 24.06.2014, 22:52 +0900 schrieb Alexandre Courbot:
>> On Tue, Jun 24, 2014 at 10:25 PM, Lucas Stach
>> wrote:
>> > Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst:
>> >> op 24-06-14 14:23, Alexandre Courbo
Hi Javier,
Thanks for the review.
On Mon, Jun 23, 2014 at 11:30 AM, Javier Martinez Canillas
wrote:
> Hello Ajay,
>
> Not an extensive review since I'm not familiar with the graphics stack
> but a few things I noticed are commented below.
>
> On Wed, Jun 11, 2014 at 8:27 PM, Ajay Kumar
> wrote
Hi Gmeiner,
On Mon, Jun 23, 2014 at 12:55 PM, Christian Gmeiner
wrote:
> Hi
>
>
> 2014-06-11 20:27 GMT+02:00 Ajay Kumar :
>> This patch adds a simple driver to handle all the LCD and LED
>> powerup/down routines needed to support eDP/LVDS panels.
>>
>> The LCD and LED units are usually powered up
tion to tell grup to use the latest installed
kernel instead of the one with the highest version number? Can't seem to
find that any more.
Please try attached patches instead,
Christian.
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-Revert-dro
Am 24.06.2014 07:21, schrieb Inki Dae:
> On 2014? 06? 23? 14:32, Rahul Sharma wrote:
>> Allowing only one layer update per vsync can cause issues
>> while there are update available for both layers. There is
>> a good amount of possibility to loose updates if we allow
>> single update per vsync.
>>
On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot
wrote:
> On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
>>
>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
>>>
>>> On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
From: Lucas Stach
On architect
On Tue, Jun 24, 2014 at 10:09 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 24, 2014 at 09:23:05PM +0900, Alexandre Courbot wrote:
>> On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot
>> wrote:
>> > The only alternative I see here is to flush the CPU caches when syncing for
>> > the device,
On Tue, Jun 24, 2014 at 10:25 PM, Lucas Stach wrote:
> Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst:
>> op 24-06-14 14:23, Alexandre Courbot schreef:
>> > On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot > > nvidia.com> wrote:
>> >> On 06/24/2014 07:33 PM, Alexandre Courbot
In try_to_bring_up_master(), we tear down the master's component list
for each error case, except for devres group failure. Fix this
oversight by making the code less prone to such mistakes.
Signed-off-by: Russell King
---
drivers/base/component.c | 62 --
Permit masters to call component_master_add_child() and match the same
child multiple times. This may happen if there's multiple connections
to a single component device from other devices. In such scenarios,
we should not return a failure, but instead ignore the attempt.
Signed-off-by: Russell
Add support for generating a set of component matches at master probe
time, and submitting them to the component layer. This allows the
component layer to perform the matches internally without needing to
call into the master driver, and allows for further restructuring of
the component helper.
S
Update MSM's DRM driver to use the component match support rather than
add_components.
Signed-off-by: Russell King
---
drivers/gpu/drm/msm/msm_drv.c | 83 ++-
1 file changed, 35 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/d
Update the imx-drm driver to use the component match support rather than
add_components.
Signed-off-by: Russell King
---
drivers/staging/imx-drm/imx-drm-core.c | 57 +++---
1 file changed, 4 insertions(+), 53 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-drm-
Now that drivers create an array of component matches at probe time, we
can retire the old methods. This involves removing the add_components
master method, and removing component_master_add_child() from public
view. We also remove component_add_master() as that interface is no
longer useful.
Si
Clean up the code a little; we don't need to check that the master is
unbound for every invocation of try_to_bring_up_master(), so let's move
it to where it's really needed - try_to_bring_up_masters(), where we may
encounter already bound masters.
Signed-off-by: Russell King
---
drivers/base/com
Since we now have an array which defines each component, maintain the
components to be bound in the array rather than a separate list. We
also need duplicate tracking so we can eliminate multiple bind calls
for the same component: we preserve the list-based component order in
that the first match
Add the missing setting for DP CLKCON register.
This register is present on Exynos5 based FIMD controllers,
and needs to be used if we are using DP.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
include/video/samsung_fimd.h |4
2 files
On Tue, Jun 24, 2014 at 9:01 AM, Andrzej Hajda wrote:
> Hi Ajay,
>
> On 06/24/2014 01:09 PM, Ajay Kumar wrote:
>> Add the missing setting for DP CLKCON register.
>>
>> This register is present on Exynos5 based FIMD controllers,
>> and needs to be used if we are using DP.
>>
>> Signed-off-by: Ajay
On 06/24/2014 05:13 PM, Russell King - ARM Linux wrote:
[...]
> If you'd like to send me better commit messages for
> these patches, I'll add them to what I already have:
> imx-drm: use defines for clock polarity settings
The comment of the clk_pol field of the ipu_di_signal_cfg struct was
Hi Javier,
Thanks for the review.
On Mon, Jun 23, 2014 at 12:05 PM, Javier Martinez Canillas
wrote:
> Hello Ajay,
>
> On Wed, Jun 11, 2014 at 8:27 PM, Ajay Kumar
> wrote:
>> From: Vincent Palatin
>>
>> This patch adds drm_bridge driver for parade DisplayPort
>> to LVDS bridge chip.
>>
>> Sign
Am 24.06.2014 12:05, schrieb Michel D?nzer:
> On 24.06.2014 05:32, Dieter N?tzel wrote:
>> Am 23.06.2014 21:46, schrieb Dieter N?tzel:
>>> Am 23.06.2014 11:34, schrieb Michel D?nzer:
On 18.06.2014 18:14, Christian K?nig wrote:
> Am 18.06.2014 07:53, schrieb Michel D?nzer:
>>
>>
On Mon, 02 June 2014 Bruno Pr?mont wrote:
> With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
> Matthew Garrett introduced a efifb vga_default_device() so that EFI
> systems that do not load shadow VBIOS or setup VGA get proper value for
> boot_vga PCI sysfs attribute on the
ation/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/6168382a/attachment.sig>
Am 24.06.2014 12:05, schrieb Michel D?nzer:
> On 24.06.2014 05:32, Dieter N?tzel wrote:
>> Am 23.06.2014 21:46, schrieb Dieter N?tzel:
>>> Am 23.06.2014 11:34, schrieb Michel D?nzer:
On 18.06.2014 18:14, Christian K?nig wrote:
> Am 18.06.2014 07:53, schrieb Michel D?nzer:
>>
>>
#x27;t you using:
>
> Documentation/devicetree/bindings/video/display-timing.txt
Because it's redundant information. We need to have a compatible for the
panel in the device tree anyway and that already implicitly defines the
display mode.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140624/15203d17/attachment-0001.sig>
y insight to secret Intel review process. :-)
>
> Dave.
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Sent with Postbox <http://www.getpostbox.co
p_hot_plug;
>
> + intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> + dev_priv->hpd_irq_port[port] = intel_dig_port;
> +
> if (!intel_dp_init_connector(intel_dig_port, intel_connector)) {
> drm_encoder_cleanup(encoder);
> kfree(intel_dig_port);
> diff --git a/drivers/gpu/drm/i9
On 06/17/2014 09:17 AM, Guido Mart?nez wrote:
> Use module_init instead of late_initcall, as is the norm for modular
> drivers.
>
> module_init was used until 6e8de0bd6a51fdeebd5d975c4fcc426f730b339b
> ("drm/tilcdc: add encoder slave (v2)") changed it to a late_initcall,
> but it does not explain w
Guido,
On 06/17/2014 09:17 AM, Guido Mart?nez wrote:
> The TI tilcdc driver is designed with a notion of submodules. Currently,
> at unload time, these submodules are iterated and destroyed.
>
> Now that the tilcdc remove order is fixed, this can be handled perfectly
I am not sure I understand th
On Tue, Jun 24, 2014 at 10:06 AM, Russell King - ARM Linux
wrote:
> Denis,
>
> This patch creates binding documentation. Any patch which does so
> should be copied to the DT people so they can review the bindings
> and give appropriate acks. It would be better if you separate the
> binding docum
This patch fixes memory leak detected by Kernel memory leak detector,
and cleans up functions which call drm_ht_remove_item() and
vmw_compat_shader_free() so that an unused parameter is not passed.
Part of logs from /sys/kernel/debug/kmemleak is as follows:
unreferenced object 0xc900086ed00
drm_ht_remove() should be called in vmw_compat_shader_man_destroy()
This is because memory was allocated for (&man->shaders)->table by
vmw_compat_shader_man_create() -> drm_ht_create()
but this memory is not freed when vmw_compat_shader_mager is destroied.
Signed-off-by: Masaru Nomura
---
driver
removed drm_open_hash from drm_ht_remove_item() as the parameter is
not used within the function.
Signed-off-by: Masaru Nomura
---
Please review this patch carefully. The reason the parameter is passed
might be some historical one or clarity of which drm_open_hash
we remove an item from.
driver
Hi Thierry,
Le Tue, 24 Jun 2014 23:49:37 +0200,
Thierry Reding a ?crit :
> On Mon, Jun 16, 2014 at 12:11:22PM +0200, Denis Carikli wrote:
> [...]
> > diff --git
> > a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
> > b/Documentation/devicetree/bindings/panel/eukrea,mbim
On Wed, 2014-06-25 at 00:55 +0200, Bruno Pr?mont wrote:
> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
> while having native drivers for the GPU also makes selecting
> sysfb/efifb optional.
>
Both look good to me.
Acked-by: Matthew Garrett
--
Matthew Garrett
vm_compat_shader_manager is only used for drm_ht_remove_item() within the
function.
As drm_ht_remove_item() does not need a paremeter drm_open_hash(&man-> shaders),
vm_compat_shader_manager(*man) does not have to be passed to this function.
Signed-off-by: Masaru Nomura
---
drivers/gpu/drm/vmwgf
On Tue, Jun 24, 2014 at 6:25 AM, Lucas Stach wrote:
> Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst:
>> op 24-06-14 14:23, Alexandre Courbot schreef:
>> > On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot > > nvidia.com> wrote:
>> >> On 06/24/2014 07:33 PM, Alexandre Courbot
95 matches
Mail list logo
