> -Original Message-
> From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
> Sent: Wednesday, February 06, 2013 2:30 PM
> To: linux-me...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> devicetree-disc...@lists.ozlabs.org
> Cc: k.deb...@samsung.com; sachin.ka...@linaro.org; inki@sam
Hello,
We've hosted a CDF meeting at the FOSDEM on Sunday morning. Here's a summary
of the discussions.
I would like to start with a big thank to UrLab, the ULB university hacker
space, for providing us with a meeting room.
The meeting would of course not have been successful without the wide
From: Ajay Kumar
This patch adds device tree match table for Exynos G2D controller.
Signed-off-by: Ajay Kumar
Signed-off-by: Sachin Kamat
---
Patch based on exynos-drm-fixes branch of Inki Dae's tree:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
Changes since v1:
Modif
This patch adds device tree based discovery support to G2D driver
Signed-off-by: Sachin Kamat
---
Based on for_v3.9 branch of below tree:
git://linuxtv.org/snawrocki/samsung.git
Changes since v1:
* Addressed review comments from Sylwester .
* Modified the compatible string as per the discussions
Add display-timing node parsing to drm fimd and depends on
the display helper patchset at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html
It also adds pinctrl support for drm fimd.
changes since v4:
- addressed comments from Paul Menzel
, to modify the co
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drive
On 5 February 2013 15:03, Sylwester Nawrocki wrote:
> On 02/05/2013 04:03 AM, Inki Dae wrote:
> [...]
>>> Exynos4210 has same g2d IP (v3.0) as C110 or V210; so the same
>>> comptible string will be used for this one too.
>>>
And please check if exynos4212 and 4412 SoCs have same fimg-2d ip.
>
Hello,
We've hosted a CDF meeting at the FOSDEM on Sunday morning. Here's a summary
of the discussions.
I would like to start with a big thank to UrLab, the ULB university hacker
space, for providing us with a meeting room.
The meeting would of course not have been successful without the wide
On Tue, Feb 05, 2013 at 10:04:27PM +0100, Daniel Vetter wrote:
> On Tue, Feb 05, 2013 at 03:51:55PM +0800, Aaron.Chen 陈俊杰 wrote:
> > This is an initial patch for Siliconmotion Graphics chips. It add SM750
> > chip support with 2d accelerate and hw curser support. It is a complete
> > new driver. S
Now that the fbdev helper interface for drivers is trimmed down,
update the kerneldoc for all the remaining exported functions.
I've tried to beat the DocBook a bit by reordering the function
references a bit into a more sensible ordering. But that didn't work
out at all. Hence just extend the in-
On Fri, Feb 01, 2013 at 01:21:29PM +0100, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thanks for improving the documentation :-)
>
> On Sunday 27 January 2013 18:42:16 Daniel Vetter wrote:
> > Now that the fbdev helper interface for drivers is trimmed down,
> > update the kerneldoc for all the remai
Use PCI_EXP_LNKCAP_SLS_2_5GB and PCI_EXP_LNKCAP_SLS_5_0GB instead
of hardcoded values for readability. These bit definitions were
added by commit 130f1b8 ("PCI: Add PCIe Link Capability link speed
and width names")
Signed-off-by: Jingoo Han
---
drivers/gpu/drm/drm_pci.c |4 ++--
1 files chan
On Tue, Feb 05, 2013 at 03:51:55PM +0800, Aaron.Chen ??? wrote:
> This is an initial patch for Siliconmotion Graphics chips. It add SM750
> chip support with 2d accelerate and hw curser support. It is a complete
> new driver. So the patch is a little bit big. Is it OK for review?
Adding a new fbd
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/256e6c3f/attachment-0001.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/a7886ed0/attachment.html>
ment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/65281a80/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=43751
--- Comment #9 from cyberbat 2013-02-05 20:11:50 ---
Created an attachment (id=92571)
--> (https://bugzilla.kernel.org/attachment.cgi?id=92571)
Config of working linux-3.7.4
Tried a kernel 3.7.4 for some days and it seems to work with confi
On 02/05/2013 05:56 PM, Sean Paul wrote:
> On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren
> wrote:
>> On 02/05/2013 05:37 PM, Sean Paul wrote:
>>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
>>> wrote:
n 02/05/2013 04:42 PM, Sean Paul wrote:
> Use the compatible string in the device
Hi!
On Fri, Feb 01, 2013 at 06:29:50PM +0900, Jingoo Han wrote:
> On Friday, January 25, 2013 6:02 PM, Steffen Trumtrar wrote
> >
> > + fbmode->sync = 0;
> > + fbmode->vmode = 0;
> > + if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> > + fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
> > + if
On 2013년 02월 06일 09:56, Sean Paul wrote:
> On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren wrote:
>> On 02/05/2013 05:37 PM, Sean Paul wrote:
>>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
>>> wrote:
n 02/05/2013 04:42 PM, Sean Paul wrote:
> Use the compatible string in the device
On 02/05/2013 05:56 PM, Sean Paul wrote:
> On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren wrote:
>> On 02/05/2013 05:37 PM, Sean Paul wrote:
>>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
>>> wrote:
n 02/05/2013 04:42 PM, Sean Paul wrote:
> Use the compatible string in the device tr
https://bugs.freedesktop.org/show_bug.cgi?id=60347
Priority: medium
Bug ID: 60347
Assignee: dri-devel@lists.freedesktop.org
Summary: Reproducible GPU lockup CP stall in Amnesia game
Severity: normal
Classification: Unclassified
On 02/06/2013 09:56 AM, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren wrote:
On 02/05/2013 05:37 PM, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren wrote:
n 02/05/2013 04:42 PM, Sean Paul wrote:
Use the compatible string in the device tree to determine whi
On 02/05/2013 05:37 PM, Sean Paul wrote:
> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
> wrote:
>> n 02/05/2013 04:42 PM, Sean Paul wrote:
>>> Use the compatible string in the device tree to determine which
>>> registers/functions to use in the HDMI driver. Also changes the
>>> references from
On 02/05/2013 12:03 PM, Inki Dae wrote:
> 2013/2/4 Sachin Kamat :
>> On 1 February 2013 18:28, Inki Dae wrote:
>>>
>>>
>>>
>>> 2013. 2. 1. ?? 8:52 Inki Dae ??:
>>>
> -Original Message-
> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
> owner at vger.kerne
n 02/05/2013 04:42 PM, Sean Paul wrote:
> Use the compatible string in the device tree to determine which
> registers/functions to use in the HDMI driver. Also changes the
> references from v13 to 4210 and v14 to 4212 to reflect the IP
> block version instead of the HDMI version.
> diff --git a/Do
On Tue, Feb 05, 2013 at 04:38:35PM +0100, Maarten Lankhorst wrote:
> Argh, next attempt, based on i915's Kconfig.
>
> It seems that not only I have to select ACPI_VIDEO, I also have to select all
> the dependencies.
> Is this a Kconfig bug or working as intended? i915 seems to have a
> workaroun
--
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/20130205/59e6f7ad/attachment.html>
On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren wrote:
> On 02/05/2013 05:37 PM, Sean Paul wrote:
>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren wrote:
>>> n 02/05/2013 04:42 PM, Sean Paul wrote:
Use the compatible string in the device tree to determine which
registers/functions to us
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/7f328719/attachment.html>
On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren wrote:
> On 02/05/2013 05:37 PM, Sean Paul wrote:
>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
>> wrote:
>>> n 02/05/2013 04:42 PM, Sean Paul wrote:
Use the compatible string in the device tree to determine which
registers/functions t
Hi Inki,
On 2013? 02? 05? 12:03, Inki Dae wrote:
> 2013/2/4 Sachin Kamat :
>> On 1 February 2013 18:28, Inki Dae wrote:
>>>
>>>
>>>
>>>
>>> 2013. 2. 1. ?? 8:52 Inki Dae ??:
>>>
> -Original Message-
> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
>
On Wed, Feb 6, 2013 at 9:42 AM, Stephen Warren wrote:
> On 02/05/2013 05:37 PM, Sean Paul wrote:
>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren wrote:
>>> n 02/05/2013 04:42 PM, Sean Paul wrote:
Use the compatible string in the device tree to determine which
registers/functions to us
On 02/05/2013 05:37 PM, Sean Paul wrote:
> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren wrote:
>> n 02/05/2013 04:42 PM, Sean Paul wrote:
>>> Use the compatible string in the device tree to determine which
>>> registers/functions to use in the HDMI driver. Also changes the
>>> references from v1
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren wrote:
> n 02/05/2013 04:42 PM, Sean Paul wrote:
>> Use the compatible string in the device tree to determine which
>> registers/functions to use in the HDMI driver. Also changes the
>> references from v13 to 4210 and v14 to 4212 to reflect the IP
>>
Op 05-02-13 15:52, Borislav Petkov schreef:
> On Mon, Feb 04, 2013 at 04:41:22PM +0100, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 04-02-13 16:23, Borislav Petkov schreef:
>>> Hi,
>>>
>>> I'm guessing someone has already triggered this on latest Linus' tree
>>> and has a fix?
>>>
>>> drivers/built-i
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren wrote:
> n 02/05/2013 04:42 PM, Sean Paul wrote:
>> Use the compatible string in the device tree to determine which
>> registers/functions to use in the HDMI driver. Also changes the
>> references from v13 to 4210 and v14 to 4212 to reflect the IP
>>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/45787ec5/attachment.html>
n 02/05/2013 04:42 PM, Sean Paul wrote:
> Use the compatible string in the device tree to determine which
> registers/functions to use in the HDMI driver. Also changes the
> references from v13 to 4210 and v14 to 4212 to reflect the IP
> block version instead of the HDMI version.
> diff --git a/Do
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/02806332/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/3b1d63da/attachment.html>
On Mon, Feb 04, 2013 at 04:41:22PM +0100, Maarten Lankhorst wrote:
> Hey,
>
> Op 04-02-13 16:23, Borislav Petkov schreef:
> > Hi,
> >
> > I'm guessing someone has already triggered this on latest Linus' tree
> > and has a fix?
> >
> > drivers/built-in.o: In function `nouveau_acpi_edid':
> > /w/ker
org/archives/dri-devel/attachments/20130205/54b694b9/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-Siliconmotion-initial-patch.patch
Type: application/octet-stream
Size: 256151 bytes
Desc: 0001-Siliconmotion-initial-patch.pat
With the change "drm/exynos: Get HDMI version from device tree",
exynos5-hdmi is no longer relevant. Update references to exynos4-hdmi
and update the hdmi compatibility string to accurately reflect the hdmi
driver.
Signed-off-by: Sean Paul
---
arch/arm/boot/dts/exynos5250.dtsi |3 ++-
a
Use the compatible string in the device tree to determine which
registers/functions to use in the HDMI driver. Also changes the
references from v13 to 4210 and v14 to 4212 to reflect the IP
block version instead of the HDMI version.
Signed-off-by: Sean Paul
---
.../devicetree/bindings/drm/exynos
This set changes the hdmi device tree node to properly represent the version of
the IP block. The first patch changes the drm hdmi driver to use the compatible
field to determine which registers/functions to call, and removes the
unfortunate v1.3/v1.4 naming convention. The second patch updates the
With the change "drm/exynos: Get HDMI version from device tree",
exynos5-hdmi is no longer relevant. Update references to exynos4-hdmi
and update the hdmi compatibility string to accurately reflect the hdmi
driver.
Signed-off-by: Sean Paul
---
arch/arm/boot/dts/exynos5250.dtsi |3 ++-
a
Use the compatible string in the device tree to determine which
registers/functions to use in the HDMI driver. Also changes the
references from v13 to 4210 and v14 to 4212 to reflect the IP
block version instead of the HDMI version.
Signed-off-by: Sean Paul
---
.../devicetree/bindings/drm/exynos
This set changes the hdmi device tree node to properly represent the version of
the IP block. The first patch changes the drm hdmi driver to use the compatible
field to determine which registers/functions to call, and removes the
unfortunate v1.3/v1.4 naming convention. The second patch updates the
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/20130205/2dee58f8/attachment.html>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher (2):
radeon: add OLAND family
radeon: add OLAND pci ids
David Herrmann (1):
man: fix manpage build instructions
Jesse Barnes (1):
intel: add more VLV PCI IDs
Maarten Lankhorst (3):
nouveau: use @PACKAGE_VER
is no change but R600_LLVM=0 solves
everything. Thanks
--
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/20130205/05ffba2f/attachment.html>
uld solve your problems.
I am running rc6 now and the same problems.
--
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/
||
--
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/20130205/98387751/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/3f94b384/attachment.html>
Now that the fbdev helper interface for drivers is trimmed down,
update the kerneldoc for all the remaining exported functions.
I've tried to beat the DocBook a bit by reordering the function
references a bit into a more sensible ordering. But that didn't work
out at all. Hence just extend the in-
On Fri, Feb 01, 2013 at 01:21:29PM +0100, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thanks for improving the documentation :-)
>
> On Sunday 27 January 2013 18:42:16 Daniel Vetter wrote:
> > Now that the fbdev helper interface for drivers is trimmed down,
> > update the kerneldoc for all the remai
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/b8e5e7e4/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=59332
Matt Turner changed:
What|Removed |Added
Blocks|59304 |
--
You are receiving this mail because:
On Tue, Feb 5, 2013 at 12:03 PM, Inki Dae wrote:
> 2013/2/4 Sachin Kamat :
>> On 1 February 2013 18:28, Inki Dae wrote:
>>>
>>>
>>>
>>>
>>> 2013. 2. 1. ?? 8:52 Inki Dae ??:
>>>
> -Original Message-
> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
>
On Tue, Feb 05, 2013 at 10:04:27PM +0100, Daniel Vetter wrote:
> On Tue, Feb 05, 2013 at 03:51:55PM +0800, Aaron.Chen ??? wrote:
> > This is an initial patch for Siliconmotion Graphics chips. It add SM750
> > chip support with 2d accelerate and hw curser support. It is a complete
> > new driver. S
On Tue, Feb 5, 2013 at 12:55 AM, Daniel Vetter wrote:
> On Thu, Jan 31, 2013 at 07:43:38PM +0200, ville.syrjala at linux.intel.com
> wrote:
>> From: Ville Syrj?l?
>>
>> Support for real RGB332 is a rarity, most hardware only really support
>> C8. So use C8 instead of RGB332 when determining the
https://bugs.freedesktop.org/show_bug.cgi?id=59332
Mike Lothian changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, Feb 05, 2013 at 03:51:55PM +0800, Aaron.Chen 陈俊杰 wrote:
> This is an initial patch for Siliconmotion Graphics chips. It add SM750
> chip support with 2d accelerate and hw curser support. It is a complete
> new driver. So the patch is a little bit big. Is it OK for review?
Adding a new fbd
On Mon, Feb 04, 2013 at 10:59:28PM +0100, Maarten Lankhorst wrote:
> Op 04-02-13 22:30, Marcin Slusarz schreef:
> > 1) Lockdep thinks all nouveau subdevs belong to the same class and can be
> > locked in arbitrary order, which is not true (at least in general case).
> > Tell it to distinguish subde
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #53 from Benjamin Lee ---
I can also confirm that Radeon KMS works on my MacBookPro8,2 with kernel
version 3.8-rc6 and EFI stub boot. I also needed to add a device section to my
xorg.conf.
I don't see any video BIOS in /dev/mem so I
https://bugzilla.kernel.org/show_bug.cgi?id=43751
--- Comment #9 from cyberbat 2013-02-05 20:11:50 ---
Created an attachment (id=92571)
--> (https://bugzilla.kernel.org/attachment.cgi?id=92571)
Config of working linux-3.7.4
Tried a kernel 3.7.4 for some days and it seems to work with confi
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130205/5c913bbe/attachment.html>
2013/2/4 Sachin Kamat :
> On 1 February 2013 18:28, Inki Dae wrote:
>>
>>
>>
>>
>> 2013. 2. 1. ?? 8:52 Inki Dae ??:
>>
>>>
>>>
-Original Message-
From: linux-media-owner at vger.kernel.org [mailto:linux-media-
owner at vger.kernel.org] On Behalf Of Sachin Kamat
Sent: F
Hi Dave,
Probably the last feature pull for 3.9, there's some fixes outstanding
thought that I'd like to sneak in. And maybe 3.8 takes a bit longer ...
Anyway, highlights of this pull:
- Kill the horrible IS_DISPLAYREG hack to handle the mmio offset movements
on vlv, big thanks to Ville.
- Dynam
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/be6eb4dc/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/76184584/attachment.html>
Add a flag NVOBJ_FLAG_CREAT_EXCL, which will make sure that only 1 engctx will
be created.
This removes the need of having multiple
Fixes the following lockdep splat:
=
[ INFO: possible recursive locking detected ]
3.8.0-rc6-ninja+ #1 Not tainted
This patch adds display-timing node parsing using video helper function
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 41 +++---
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu
This patch adds display-timing node parsing to drm fimd, this depends on
the display helper patchset at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html
It also adds pinctrl support for drm fimd.
changes since v3:
- addressed comments from Sean Paul , to
modify
t; >> +struct tegra_drm_syncpt_wait_args {
> >> + __u32 id;
> >> + __u32 thresh;
> >> + __s32 timeout;
> >> + __u32 value;
> >> +};
> >> +
> >> +#define DRM_TEGRA_NO_TIMEOUT (-1)
> >
> > Is this the only reason why timeout is signed? If so maybe a better
> > choice would be __u32 and DRM_TEGRA_NO_TIMEOUT 0x.
>
> I believe it is so. In fact we'd need to rename it to something like
> INFINITE_TIMEOUT, because we also have a case of timeout=0, which
> returns immediately, i.e. doesn't have a timeout either.
For timeout == 0 I don't think we need a symbolic name. It is pretty
common for 0 to mean no timeout. But yes, DRM_TEGRA_INFINITE_TIMEOUT
should be okay.
> >> +struct tegra_drm_syncpt_incr {
> >> + __u32 syncpt_id;
> >> + __u32 syncpt_incrs;
> >> +};
> >
> > Maybe the fields would be better named id and incrs. Though I also
> > notice that incrs is never used. I guess that's supposed to be used in
> > the future to allow increments by more than a single value. If so,
> > perhaps value would be a better name.
>
> It's actually used in the dreaded patch 3, as part of tegra_drm_submit_args.
Okay. The superfluous syncpt_ prefixes should still go away.
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/20130205/1443dce9/attachment.pgp>
rn -EINVAL;
> + }
> }
>
> panel = &pdata->panel;
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/2e7004c1/attachment.pgp>
On 02/05/2013 04:03 AM, Inki Dae wrote:
[...]
>> Exynos4210 has same g2d IP (v3.0) as C110 or V210; so the same
>> comptible string will be used for this one too.
>>
>>> And please check if exynos4212 and 4412 SoCs have same fimg-2d ip.
>>> If it's different, we might need to add ip version proper
Hi!
On Fri, Feb 01, 2013 at 06:29:50PM +0900, Jingoo Han wrote:
> On Friday, January 25, 2013 6:02 PM, Steffen Trumtrar wrote
> >
> > + fbmode->sync = 0;
> > + fbmode->vmode = 0;
> > + if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> > + fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
> > + if
dules isn't nice, I merged them to
> same module and that seemed to force merging Makefile.
>
> If anybody has an idea on how to do it otherwise, I'd be happy to keep
> the Makefiles separate.
Okay, I'll take a look.
Thierry
-- next part --
; >> + switch (cbstat) {
> >> + case 0x00010008:
> >
> > Again, symbolic names would be nice.
>
> I propose I remove the decoding from kernel, and save 200 lines.
I think it could be more than 200 lines. If all we provide in the kernel
is some statistics about syncpoint usage or channel state that should be
a lot less code than we have now.
However that would make it necessary to provide userspace tools that can
provide the same quality of diagnostics, so I'm not sure if it's doable
without access to the in-kernel data structures.
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/20130205/ca8a97e8/attachment.pgp>
; + */
> >> +int host1x_syncpt_wait(struct host1x_syncpt *sp,
> >> + u32 thresh, long timeout, u32 *value)
> >> +{
> > [...]
> >> +}
> >> +EXPORT_SYMBOL(host1x_syncpt_wait);
> >
> > This doesn't only seem to be the main entrypoint, but it's basically the
> > only way to currently wait for syncpoints. One actual use-case where
> > this might turn out to be a problem is video capturing. The problem is
> > that using this API you can't very well asynchronously capture frames.
> > So eventually I think we need a way to allow a generic handler to be
> > attached to syncpoints so that you can have this handler continuously
> > invoked after each frame is captured and just pass the buffer back to
> > userspace.
>
> Yep, so far all asynchronous waits have been done in user space. We
> would probably allow attaching a handler to a syncpt value, so that we'd
> call that handler once a value is reached. In effect, similar to a
> wake_up event that is now added via host1x_intr_add_action, but simpler.
> That'd mean that the handler needs to be re-added after each frame.
>
> We could also add the handler as persistent if re-adding would be a
> problem. That'd require some new wiring and I'll have to think how to
> implement that.
Yes, that sounds like what I had in mind. Again, no need to worry about
it now. We can cross that bridge when we come to it.
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/20130205/e1507241/attachment-0001.pgp>
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/20130205/b02ccf44/attachment.html>
not a single one for all results as a whole.
--
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/20130205/1d9137e4/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #10 from Paul Heldens ---
Yes for me this effect varies also
if I open , say a browser with a complex webpage, and then start xonotic again
the text may be garbled the 2nd start
its as if video memory or some caches get corrupted
-
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #9 from Andy Furniss ---
(In reply to comment #0)
> bisected to this commit
>
> 325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit
> commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc
> Author: Jerome Glisse
> Date: Mon
ally passed to a function ending in _request? Allocate
> would just allocate the next available - as host1x_syncpt_allocate does.
That's certainly true for interrupts. However, if you look at the DMA
subsystem for example, you can also request an unnamed resource.
The difference is sufficiently subtle that host1x_syncpt_allocate()
would work for me too, though. I just have a slight preference for
host1x_syncpt_request().
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/20130205/9e8c64e1/attachment-0001.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #8 from Paul Heldens ---
OpenGL renderer string: Gallium 0.4 on AMD RV730
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lis
On Tue, Feb 05, 2013 at 04:38:35PM +0100, Maarten Lankhorst wrote:
> Argh, next attempt, based on i915's Kconfig.
>
> It seems that not only I have to select ACPI_VIDEO, I also have to select all
> the dependencies.
> Is this a Kconfig bug or working as intended? i915 seems to have a
> workaroun
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #7 from Jerome Glisse ---
And what GPU is this ? Because here it works ...
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@li
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #6 from Paul Heldens ---
Tested it again to be sure
Linux borgir 3.7.6 does NOT have the problem, pardon the mistake.
--
You are receiving this mail because:
You are the assignee for the bug.
__
Op 05-02-13 15:52, Borislav Petkov schreef:
> On Mon, Feb 04, 2013 at 04:41:22PM +0100, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 04-02-13 16:23, Borislav Petkov schreef:
>>> Hi,
>>>
>>> I'm guessing someone has already triggered this on latest Linus' tree
>>> and has a fix?
>>>
>>> drivers/built-i
On Mon, Feb 04, 2013 at 04:41:22PM +0100, Maarten Lankhorst wrote:
> Hey,
>
> Op 04-02-13 16:23, Borislav Petkov schreef:
> > Hi,
> >
> > I'm guessing someone has already triggered this on latest Linus' tree
> > and has a fix?
> >
> > drivers/built-in.o: In function `nouveau_acpi_edid':
> > /w/ker
https://bugs.freedesktop.org/show_bug.cgi?id=60294
Michel Dänzer changed:
What|Removed |Added
Summary|Flashplayer crashing|[LLVM] Flashplayer crashing
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=60294
--- Comment #12 from René Blokland ---
(In reply to comment #9)
> Does setting the environment variable R600_LLVM=0 or building Mesa without
> --enable-r600-llvm-compiler work around the problem?
without --enable-r600-llvm-compiler there is no c
https://bugs.freedesktop.org/show_bug.cgi?id=60294
--- Comment #11 from René Blokland ---
(In reply to comment #8)
> It's not that I am a dev or something, but you should first consider
> upgrading the kernel. Releases from 3.8-rc2 to 3.8-rc6 include lot of fixes
> and maybe it could solve your p
https://bugs.freedesktop.org/show_bug.cgi?id=60236
smoki changed:
What|Removed |Added
Attachment #74238|text/plain |image/png
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=60294
--- Comment #10 from René Blokland ---
Created attachment 74247
--> https://bugs.freedesktop.org/attachment.cgi?id=74247&action=edit
my current config
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #5 from Alex Deucher ---
(In reply to comment #1)
> linux 3.8-rc63.7.4 had it also
325422c49449acdd8df1eb2ca8ed81f7696c38cc (r600g: add async for staging buffer
upload v2) only takes affect on 3.8 kernels. Previous kernels didn'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher (2):
radeon: add OLAND family
radeon: add OLAND pci ids
David Herrmann (1):
man: fix manpage build instructions
Jesse Barnes (1):
intel: add more VLV PCI IDs
Maarten Lankhorst (3):
nouveau: use @PACKAGE_VER
1 - 100 of 119 matches
Mail list logo
