On Thu, Mar 20, 2014 at 11:31:26AM +1000, Dave Airlie wrote:
> On Tue, Mar 11, 2014 at 8:30 PM, Daniel Vetter
> wrote:
> > There's not really any value in stating that no locking is needed. And
> > even if the comment is useful, a check for the right mutex at the
> > beginning of the function is
With the recent addition of locking checks in
commit 62ff94a5492175759546f8bc61383189d6b49122
Author: Daniel Vetter
AuthorDate: Thu Jan 23 22:18:47 2014 +0100
drm/crtc-helper: remove LOCKING from kerneldoc
drm_add_edid_modes started to WARN about the mode_config.mutex not
being held in
With the recent addition of locking checks in
commit 62ff94a5492175759546f8bc61383189d6b49122
Author: Daniel Vetter
AuthorDate: Thu Jan 23 22:18:47 2014 +0100
drm/crtc-helper: remove LOCKING from kerneldoc
drm_add_edid_modes started to WARN about the mode_config.mutex not
being held in
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/6e31015d/attachment.html>
sync_end -
> in_mode->crtc_hsync_start;
> > + ielcd->hbpd = in_mode->crtc_htotal - in_mode->crtc_hsync_end;
> > + ielcd->hfpd = in_mode->crtc_hsync_start - in_mode->crtc_hdisplay;
> > +}
> > +
> > +static struct exynos_fimd_pp_ops ielcd_ops = {
> > + .power_on = exynos_ielcd_power_on,
> > + .power_off =exynos_ielcd_display_off,
> > + .mode_set = exynos_ielcd_mode_set,
> > +};
> > +
> > +static struct exynos_fimd_pp ielcd_pp = {
> > + .ops = &ielcd_ops,
> > +};
> > +
> > +int exynos_ielcd_init(struct device *dev, struct exynos_fimd_pp **pp)
> > +{
> > + struct device_node *ielcd_np;
> > + struct ielcd_context *ielcd;
> > + u32 addr[2];
> > + int ret = 0;
> > +
> > + ielcd = kzalloc(sizeof(struct ielcd_context), GFP_KERNEL);
> > + if (!ielcd) {
> > + DRM_ERROR("failed to allocate ielcd\n");
> > + ret = -ENOMEM;
> > + goto error0;
>
> return directly from here and delete the label.
>
> Ok.
> --
> With warm regards,
> Sachin
>
Will address all your comments in next patchset.
Thanks and regards,
Ajay kumar
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/3f61d4ce/attachment.html>
Provides a nice cleanup in radeon.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 117 +
drivers/gpu/drm/radeon/radeon_connectors.c | 44 ++-
drivers/gpu/drm/radeon/radeon_display.c| 11 ++-
drivers/gpu/drm/radeon/radeon_i2c
We need bare address packets at the start and end of
each i2c over aux transaction to properly reset the connection
between transactions. This mirrors what the existing dp i2c
over aux algo currently does.
This fixes EDID fetches on certain monitors especially with
dp bridges.
Signed-off-by: Ale
Needed for proper i2c over aux handling for certain
monitors and configurations (e.g., dp bridges or
adapters).
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombio
This adds a flags field and a new flag, BARE_ADDRESS,
which drivers can use for special handling when they
want to set just the aux address. This is needed
to properly reset the connection between i2c transactions.
Signed-off-by: Alex Deucher
---
include/drm/drm_dp_helper.h | 3 +++
1 file chan
Am 21.03.2014 15:34, schrieb Alex Deucher:
> Switch to debug only to avoid flooding the logs.
> This mirrors the behavior in some other drivers.
>
> Signed-off-by: Alex Deucher
> Reviewed-by: Daniel Vetter
Added to my 3.15 queue
(http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-next-3.
ctly from here.
>
> Ok.
> > + }
> > +
> > + if (of_property_read_u32_array(mdnie_np, "reg", buf, 2)) {
> > + DRM_ERROR("failed to get base address for MDNIE\n");
> > + ret = -ENOMEM;
> > + goto err0;
>
> ditto
>
Ok.
>
>
> + }
> > +
> > + mdnie = kzalloc(sizeof(struct mdnie_context), GFP_KERNEL);
>
> nit: use sizeof(*mdnie)
>
> Ok.
> > + if (!mdnie) {
> > + DRM_ERROR("failed to allocate mdnie\n");
>
> This message is not needed as kzalloc prints OOM message upon failure.
>
Ok.
>
> > + ret = -ENOMEM;
> > + goto err0;
> > + }
>
> return directly.
Ok.
>
> > +
> > + mdnie->exynos_mdnie_base = ioremap(buf[0], buf[1]);
> > + if (!mdnie->exynos_mdnie_base) {
> > + DRM_ERROR("failed to ioremap mdnie device\n");
> > + ret = -ENOMEM;
> > + goto err1;
> > + }
> > +
> > + if (dt_parse_disp1blk_cfg(dev, &disp1blk_phyaddr)) {
> > + DRM_ERROR("failed to get disp1blk property.\n");
> > + ret = -ENODEV;
> > + goto err1;
> > + }
> > +
> > + if (exynos_iomap_disp1blk(mdnie, disp1blk_phyaddr)) {
> > + DRM_ERROR("failed to iopmap disp1blk sysreg.\n");
>
> s/iopmap/iomap
>
> Ok.
>
> --
> With warm regards,
> Sachin
>
I will address your comments in next patchset.
Thanks,
Ajay
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/067c570b/attachment-0001.html>
On Fri, Mar 21, 2014 at 10:34:06AM -0400, Alex Deucher wrote:
> Switch to debug only to avoid flooding the logs.
> This mirrors the behavior in some other drivers.
>
> Signed-off-by: Alex Deucher
> Reviewed-by: Daniel Vetter
Btw I've just noticed that we have a 2nd retry loop with 3 retries and
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/6496c8d9/attachment.html>
Process 590 (sd_festival) dumped
core.
--
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/20140321/11344596/attachment.html>
ble
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/9be15d52/attachment.sig>
lists.freedesktop.org/archives/dri-devel/attachments/20140321/9c7eabd8/attachment.sig>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140321/f56fd1cd/attachment-0001.html>
Hi Dave,
This pull request includes some features and big changes for 3.15.
Highlights
--
Re-factoring works over the exynos drm framework.
- drm_crtc, drm_encoder/drm_connector are implemented by sub drivers
directly.
- Removing pm interfaces from each sub driver, and implem
printk("p1 = %u, p2 = %u, n = %u\n", clock->p1, clock->p2,
> + clock->n);
> if (WARN_ON(clock->n + 2 == 0 || clock->p == 0))
> return;
> clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n + 2);
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Peter
-- next part --
A non-text attachment was scrubbed...
Name: dmesg.gz
Type: application/x-gzip
Size: 73573 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/9dcf27f3/attachment-0001.bin>
https://bugzilla.kernel.org/show_bug.cgi?id=70171
Andreas changed:
What|Removed |Added
Summary|kernel/time/tick-broadcast. |3.13.x:
|c:668 exception and
https://bugzilla.kernel.org/show_bug.cgi?id=70171
Andreas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 03/21/2014 03:53 PM, Daniel Kurtz wrote:
> On Fri, Mar 21, 2014 at 2:39 PM, Joonyoung Shim
> wrote:
>> Exynos drm driver cannot support DRIVER_HAVE_IRQ feature because it uses
>> driver specific one instead of routine of drm framework to
>> install/uninstall irq handler.
> Wouldn't that break
On Fri, Mar 21, 2014 at 12:26:51PM +0100, Peter Senna Tschudin wrote:
> On Thu, Mar 20, 2014 at 10:17 PM, Daniel Vetter wrote:
> > On Thu, Mar 20, 2014 at 05:56:20PM +0100, Peter Senna Tschudin wrote:
> >> When Fedora updated the Kernel package from 3.12 to 3.13 my notebook
> >> stopped booting (K
Exynos drm driver cannot support DRIVER_HAVE_IRQ feature because it uses
driver specific one instead of routine of drm framework to
install/uninstall irq handler.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 3 +--
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 --
On Mon, 17 Mar 2014 15:55:27 +0200, Tomi Valkeinen
wrote:
> Hi Grant,
>
> Ping.
>
> Are you fine with me proceeding with the current V4L2 port/endpoint
> bindings?
Sorry, this thread didn't make it past my email filters. Yes, go ahead.
g.
On Fri, Mar 21, 2014 at 2:39 PM, Joonyoung Shim
wrote:
> Exynos drm driver cannot support DRIVER_HAVE_IRQ feature because it uses
> driver specific one instead of routine of drm framework to
> install/uninstall irq handler.
Wouldn't that break synchronous drm_wait_vblank()?
(drm_wait_vblank whe
t of
it helps?
--
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/20140321/d63cf2cc/attachment.html>
ttm
crc32c_intel drm broadcom microcode psmouse evdev lpc_ich tg3 battery i2c_i801
button processor ac wmi ipv6 ehci_pci ehci_hcd usbcore sr_mod cdrom sd_mod ahci
[ 14.750668] CPU: 2 PID: 189 Comm: systemd-udevd Tainted: G W
3.14.0-rc7-next-20140321-dbg-dirty #192
[ 14.751152] Hardware
On 03/21/2014 11:55 AM, Jean-Francois Moine wrote:
> The tda998x driver accepts only 3 chips from the TDA998x family.
> This patch changes the driver compatible strings to these chips.
Jean-Francois,
be careful with building a DT binding from a Linux driver. Although
we constantly struggle to def
Hi Andrzej,
2014-03-20 22:26 GMT+09:00 Andrzej Hajda :
> The patch adds polarization flags to fimd node.
> It fixes parallel display support.
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi Inki,
>
> Since polarization patches were not merged, polarization
> settings should be provided to fimd via p
ation?
--
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/20140321/65dc0ad5/attachment.html>
On 19 March 2014 19:52, Ajay Kumar wrote:
> Add post processor ops for IELCD and their support functions.
> Expose an interface for the FIMD to register IELCD PP.
[snip]
> +
> +#define exynos_ielcd_readl(addr) readl(ielcd->exynos_ielcd_base + addr)
> +#define exynos_ielcd_writel(addr, val) \
On 03/21/2014 01:12 PM, Maarten Lankhorst wrote:
> Hey,
>
> op 21-03-14 09:27, Thomas Hellstrom schreef:
>> On 03/21/2014 12:55 AM, Dave Airlie wrote:
>>> On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse
>>> wrote:
On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote:
> On 10/18
ainted: GW
3.14.0-rc7-next-20140321-dbg-dirty #189
[ 18.704481] Hardware name: Acer Aspire 5741G/Aspire 5741G
, BIOS V1.20 02/08/2011
[ 18.704482] 88015217f830 813ba2d7
[ 18.704484] 88015217f868 fff
lpc_ich i2c_i801 ipv6 ehci_pci ehci_hcd usbcore sr_mod cdrom
sd_mod ahci
[ 18.707087] CPU: 2 PID: 175 Comm: systemd-udevd Tainted: GW
3.14.0-rc7-next-20140321-dbg-dirty #189
[ 18.707088] Hardware name: Acer Aspire 5741G/Aspire 5741G
, BIOS V1.20 02/08/2011
Hey,
op 21-03-14 09:27, Thomas Hellstrom schreef:
> On 03/21/2014 12:55 AM, Dave Airlie wrote:
>> On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse wrote:
>>> On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote:
On 10/18/2012 04:45 PM, Maarten Lankhorst wrote:
> Op 18-10-12 13:
On Thu, Mar 20, 2014 at 8:09 PM, Fengguang Wu wrote:
> // CC Stephane for RAPL related bug
>
> Bjorn, sorry this bug report is mis-titled. The only new bug that show
> up in aa11fc58dc is on rapl_pmu_init. And it shows up only 1 time, so
> it's hard to reproduce and the bisect is likely not accura
On Fri, Mar 07, 2014 at 12:24:33AM +0100, Laurent Pinchart wrote:
> However, we (as in the V4L2 community, and me personally) would have
> appreciated to be CC'ed on the proposal. As you might know we already had a
> solution for this problem, albeit V4L2-specific, in drivers/media/v4l2-
> core/v
0x110 [i915]
>> [] intel_fbdev_initial_config+0x21/0x30 [i915]
>> [] i915_driver_load+0xdde/0xe10 [i915]
>> [] drm_dev_register+0x7b/0x160 [drm]
>> [] drm_get_pci_dev+0xa0/0x220 [drm]
>> [] i915_pci_probe+0x3b/0x60 [i915]
>> [] local_pci_probe+0x45/0xa0
&g
On Thu, Mar 20, 2014 at 07:17:00PM -0400, Nikolay Martynov wrote:
> Yes, that seem to help. It didn't freeze anymore in 15 mins I used it.
> Thanks!
Thanks indeed,
commit 3f5e0f06a3355a77ace053b4ffc0ac1c413cf2d0
Author: Chris Wilson
Date: Fri Mar 21 07:40:56 2014 +
drm/i915: Fix un
The tda998x driver accepts only 3 chips from the TDA998x family.
This patch changes the driver compatible strings to these chips.
Signed-off-by: Jean-Francois Moine
---
v2: change the subject to drm/i2c
This patch applies after
drm/i2c: tda998x: Fix lack of required reg in DT documentatio
The I2C address (reg) is required for the TDA998x driver to be loaded
and initialized.
Signed-off-by: Jean-Francois Moine
---
- v3
- change subject to drm/i2c
- v2
- don't force the I2C address to be 0x70
This patch applies to linux-next.
---
Documentation/devicetree/bindings/drm
On 2/18/2014 9:44 AM, Michal Nazarewicz wrote:
>> On 2014-02-12 17:33, Russell King - ARM Linux wrote:
>>> What if we did these changes:
>>>
>>> struct page *dma_alloc_from_contiguous(struct device *dev, int count,
>>> unsigned int align)
>>> {
>>> ...
>>>
The 'slave encoder' structure of the tda998x driver asks for glue
between the DRM driver and the encoder/connector structures.
Changing the tda998x driver to a simple encoder/connector simplifies
the code of the tilcdc driver. This change is permitted by
Russell's infrastructure for componentised
On Fri, Mar 21, 2014 at 11:27:45AM +0100, Jean-Francois Moine wrote:
> The 'slave encoder' structure of the tda998x driver asks for glue
> between the DRM driver and the encoder/connector structures.
Given how close we are to the coming merge window, that the discussion
about the of-graph bindings
On Fri, Mar 21, 2014 at 9:25 AM, Dave Airlie wrote:
> There's one in i915 lvds on ironlake, and one in nouveau later.
>
> drm_mode_probed_add locking?
>
> but also others in suspend/resume paths.
>
So I've been nice, and fixes the suspend/resume one, but the edid one
looks like a bit more auditin
According to the media video interface, the video source and sink
ports must be identified by mutual phandles.
This patch adds the 'port' property of the tda998x (sink side).
Signed-off-by: Jean-Francois Moine
---
Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 11 ++-
1 file ch
From: Dave Airlie
Since Daniel documented things with a sledge hammer, we got lots of
nice backtraces in suspend/resume operations, I've check the callers
of this and they all seems safe to me,
This fixes one set of warns I reported.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc_hel
On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski
wrote:
> My system works on a 3.13 Fedora kernel. It does not work on a
> more-or-less identically configured 3.14-rc7+ kernel. The symptom is
> that the Plymouth password prompt flashes and them the screen goes
> blank. Hitting escape brings b
On Fri, Mar 21, 2014 at 9:49 AM, Andy Lutomirski wrote:
> On Fri, Mar 21, 2014 at 7:41 AM, Alex Deucher
> wrote:
>> On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski
>> wrote:
>>> My system works on a 3.13 Fedora kernel. It does not work on a
>>> more-or-less identically configured 3.14-rc7+
Replace the radeon specific version with the generic version.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 30 +-
1 file changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/at
Switch to the new dp helpers. The main difference is
that the DP helpers don't allow an adjustable delay in
the aux transaction, but I don't know that this is
necessary.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 192 +
drivers/gpu/d
Switch to debug only to avoid flooding the logs.
This mirrors the behavior in some other drivers.
Signed-off-by: Alex Deucher
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/
The connection between the video source and sink must follow
the media video interface.
Signed-off-by: Jean-Francois Moine
---
Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/
The tda998x being converted to a normal DRM encoder/connector,
there is no slave notion anymore.
Signed-off-by: Jean-Francois Moine
---
Documentation/devicetree/bindings/drm/tilcdc/slave.txt | 18 --
1 file changed, 18 deletions(-)
delete mode 100644 Documentation/devicetree/bin
// CC Stephane for RAPL related bug
Bjorn, sorry this bug report is mis-titled. The only new bug that show
up in aa11fc58dc is on rapl_pmu_init. And it shows up only 1 time, so
it's hard to reproduce and the bisect is likely not accurate. I'll
retry the bisect with more repeat count. Sorry for th
On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse wrote:
> On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote:
>> On 10/18/2012 04:45 PM, Maarten Lankhorst wrote:
>> >Op 18-10-12 13:55, Thomas Hellstrom schreef:
>> >>On 10/18/2012 01:38 PM, Maarten Lankhorst wrote:
>> >>>Op 18-10-12 13:
The tda998x being moved from a 'slave encoder' to a normal DRM
encoder/connector and the tilcdc_slave glue being removed, the
declaration of the HDMI transmitter description must be changed in
the associated DTs.
Signed-off-by: Jean-Francois Moine
---
arch/arm/boot/dts/am335x-base0033.dts | 28
The tda998x being moved from a 'slave encoder' to a normal DRM
encoder/connector, the tilcdc_slave glue is not needed anymore.
This patch uses the infrastructure for componentised subsystems
for waiting to the tda998x full start and to give it the pointer
to the DRM device.
Signed-off-by: Jean-Fr
On 03/21/2014 08:10 AM, Daniel Vetter wrote:
> On Thu, Mar 20, 2014 at 10:13 PM, Rob Clark wrote:
Ie. an app that was using the gpu for something secure could
simply choose not to if the hw/driver could not guarantee that another
process using the gpu could not get access to the buf
On 03/21/2014 12:55 AM, Dave Airlie wrote:
> On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse wrote:
>> On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote:
>>> On 10/18/2012 04:45 PM, Maarten Lankhorst wrote:
Op 18-10-12 13:55, Thomas Hellstrom schreef:
> On 10/18/2012 01:38 P
: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/ed52f194/attachment-0001.obj>
On Fri, Mar 21, 2014 at 1:53 AM, Dave Airlie wrote:
> So I've been nice, and fixes the suspend/resume one, but the edid one
> looks like a bit more auditing/typing, so I'm leaving it for you to
> look at :-)
With my two patches from yesterday and your resume patch, what's still
missing? Atm I don
The 'slave encoder' structure of the tda998x driver asks for glue
between the DRM driver and the encoder/connector structures.
This patch changes the driver to a normal DRM encoder/connector
thanks to the infrastructure for componentised subsystems.
Signed-off-by: Jean-Francois Moine
---
driver
On Fri, Mar 21, 2014 at 7:41 AM, Alex Deucher wrote:
> On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski
> wrote:
>> My system works on a 3.13 Fedora kernel. It does not work on a
>> more-or-less identically configured 3.14-rc7+ kernel. The symptom is
>> that the Plymouth password prompt flash
Populate PAR in infoframe structure. If there is a user setting for PAR, then
that value is set. Else, value is taken from CEA mode list if VIC is found.
Else, PAR is calculated from resolution. If none of these conditions are
satisfied, PAR is NONE as per initialization.
As a next step, create a
On Thu, Mar 20, 2014 at 10:13 PM, Rob Clark wrote:
>>> Ie. an app that was using the gpu for something secure could
>>> simply choose not to if the hw/driver could not guarantee that another
>>> process using the gpu could not get access to the buffers..
>>
>> IMO that should work fine, but we nee
On Fri, Mar 21, 2014 at 10:46:59AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Since Daniel documented things with a sledge hammer, we got lots of
> nice backtraces in suspend/resume operations, I've check the callers
> of this and they all seems safe to me,
>
> This fixes one set of warns
te.
Thanks
Mengdong
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/e101d1ad/attachment-0001.html>
ceiving 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/20140321/c1ff7627/attachment-0001.html>
d hyper-threading and all but one core.
--
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/20140321/b29f49fa/attachment.html>
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/6afa323e/attachment-0001.html>
gnee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/6de1c5ef/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/5f326457/attachment.html>
Hi Linus,
Some final few intel fixes, all regressions, all stable cc, and one exynos
oops fixer, the biggest is probably the intel display error irqs one, but
it seems to fix a few crashes on startup, and one use after free in drm
core.
Dave.
The following changes since commit dcb99fd9b08cfe
chives/dri-devel/attachments/20140321/54b6fcca/attachment.html>
he compile/build process
locating its include files folder.
--
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/20140321/a5ea4101/attachment.html>
77 matches
Mail list logo
