).
--
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/20121203/ecc9a677/attachment-0001.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121203/39091e96/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121203/7b400955/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121203/277f5736/attachment.html>
a
global ops structure. That may even work fine for now, but it will break
once you have more than a single host1x in a system. I know this will
never happen, but all of a sudden it happens anyway and the code breaks.
Doing this right isn't very hard and it will lead to a better design and
is less likely to break at some point.
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/20121203/20e79084/attachment.pgp>
On 12/03/2012 08:00 PM, Mark Zhang wrote:
> On 11/28/2012 02:37 PM, Mark Zhang wrote:
>> On 11/28/2012 05:39 AM, Stephen Warren wrote:
>>> On 11/27/2012 11:17 AM, Stephen Warren wrote:
On 11/26/2012 08:16 PM, Mark Zhang wrote:
> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>> On
Hi Dave:
I'm new in kernel development. Could you tell me or give me some
materials to read that why we need to align the size of IOCTL structures
to 64bit? I can understand if we're working in a 64bit kernel but why we
need to do this if we're in a 32bit arm kernel? Besides, why the
pointers in
On Sun, Dec 2, 2012 at 3:03 PM, Marek Ol??k wrote:
> No version bump is required because setting the flag on older DRM has
> no effect.
>
> This only reserves the bit and doesn't use it. I assume we will use it
> for buffer eviction heuristics.
Looks good to me. Seems like it would be handy for
On Wed, Nov 28, 2012 at 1:47 PM, wrote:
> From: Jerome Glisse
>
> Force the use of cached memory when evicting from vram on non agp
> hardware. Also force write combine on agp hw. This is to insure
> the minimum cache type change when allocating memory and improving
> memory eviction especialy
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121203/abe1a518/attachment.html>
On Wed, Nov 28, 2012 at 1:47 PM, wrote:
> From: Jerome Glisse
>
> Force the use of cached memory when evicting from vram on non agp
> hardware. Also force write combine on agp hw. This is to insure
> the minimum cache type change when allocating memory and improving
> memory eviction especialy
Add more CC's
On Mon, Dec 3, 2012 at 12:39 PM, Heinz Diehl wrote:
> Hi,
>
> with latest linus-3.7 git from today, after some time, my machine gets
> more and more unresponsible, fanspeed increases, and that's what I see in the
> logs:
>
> Dec 3 18:08:10 wildsau kernel: [35092.535757]
Changelog v2:
Implement copy sgt code in exynos_get_sgt itself instead of calling
sg_clone_table.
Changelog v1:
During map_dma_buf, a new sgt needs to be created before being mapped to
another device's address space. Currently, this sgt is created by calling
dma_get_sgtable which creates a sgt
On 12/01/2012 07:58 AM, Thierry Reding wrote:
> On Sat, Dec 01, 2012 at 01:31:02PM +0200, Terje Bergstr?m wrote:
...
>> I was thinking of definitions like this:
>>
>> static inline u32 host1x_sync_cfpeek_ctrl_cfpeek_addr_f(u32 v) {
>> return (v & 0x1ff) << 0; }
>>
>> versus
>>
>> #define
On 11/30/2012 03:38 AM, Thierry Reding wrote:
> On Fri, Nov 30, 2012 at 10:56:39AM +0200, Terje Bergstr?m wrote:
>> On 29.11.2012 13:47, Thierry Reding wrote:
>>> On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergstr?m
>>> wrote:
Tegra20 and Tegra30 are compatible, but future chips are not.
According to the new IOMMU framework for exynos sysmmus, the owner
of the sysmmu-tv is mixer (which is the actual device that does DMA)
and not hdmi.
The mmu-master in sysmmu-tv node is set as below in exynos5250.dtsi.
sysmmu-tv {
-
mmu-master = <>;
};
This patch moves the
On Mon, Dec 3, 2012 at 10:30 AM, Mark Zhang wrote:
> I'm new in kernel development. Could you tell me or give me some
> materials to read that why we need to align the size of IOCTL structures
> to 64bit? I can understand if we're working in a 64bit kernel but why we
> need to do this if we're in
On 02.12.2012 22:55, Thierry Reding wrote:
> FWIW I'm convinced that you're genuinely trying to make this work and
> nobody welcomes this more than me. However it is only natural if you
> dump such a large body of code on the community that people will
> disagree with some of the design decisions.
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121203/a243147b/attachment.html>
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/20121203/62fb481a/attachment.html>
Hi Dave:
I'm new in kernel development. Could you tell me or give me some
materials to read that why we need to align the size of IOCTL structures
to 64bit? I can understand if we're working in a 64bit kernel but why we
need to do this if we're in a 32bit arm kernel? Besides, why the
pointers in
On Mon, Dec 3, 2012 at 10:30 AM, Mark Zhang nvmarkzh...@gmail.com wrote:
I'm new in kernel development. Could you tell me or give me some
materials to read that why we need to align the size of IOCTL structures
to 64bit? I can understand if we're working in a 64bit kernel but why we
need to do
https://bugs.freedesktop.org/show_bug.cgi?id=57842
Priority: medium
Bug ID: 57842
Assignee: dri-devel@lists.freedesktop.org
Summary: r200: Culling is broken when rendering to an FBO
Severity: normal
Classification: Unclassified
On 11/30/2012 03:38 AM, Thierry Reding wrote:
On Fri, Nov 30, 2012 at 10:56:39AM +0200, Terje Bergström wrote:
On 29.11.2012 13:47, Thierry Reding wrote:
On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergström
wrote:
Tegra20 and Tegra30 are compatible, but future chips are not.
I was
On Wed, Nov 28, 2012 at 1:47 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
Force the use of cached memory when evicting from vram on non agp
hardware. Also force write combine on agp hw. This is to insure
the minimum cache type change when allocating memory and
On 12/01/2012 07:58 AM, Thierry Reding wrote:
On Sat, Dec 01, 2012 at 01:31:02PM +0200, Terje Bergström wrote:
...
I was thinking of definitions like this:
static inline u32 host1x_sync_cfpeek_ctrl_cfpeek_addr_f(u32 v) {
return (v 0x1ff) 0; }
versus
#define
On Wed, Nov 28, 2012 at 1:47 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
Force the use of cached memory when evicting from vram on non agp
hardware. Also force write combine on agp hw. This is to insure
the minimum cache type change when allocating memory and
On Sun, Dec 2, 2012 at 3:03 PM, Marek Olšák mar...@gmail.com wrote:
No version bump is required because setting the flag on older DRM has
no effect.
This only reserves the bit and doesn't use it. I assume we will use it
for buffer eviction heuristics.
Looks good to me. Seems like it would
On Mon, Dec 03, 2012 at 12:20:30PM -0700, Stephen Warren wrote:
On 11/30/2012 03:38 AM, Thierry Reding wrote:
On Fri, Nov 30, 2012 at 10:56:39AM +0200, Terje Bergström wrote:
On 29.11.2012 13:47, Thierry Reding wrote:
On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergström
wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=39308
--- Comment #3 from Tomasz P. son_of_the_osi...@interia.pl ---
Also have rv350 and it works for me. Can you check again ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=41051
--- Comment #1 from Tomasz P. son_of_the_osi...@interia.pl ---
Still you have the same problem ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #10 from Tomasz P. son_of_the_osi...@interia.pl ---
Do you have still the same problem with current mesa ? On my rv350 works good.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=39308
--- Comment #4 from almos aaalmo...@gmail.com ---
I don't have full access to my old machine with the rv350 anymore (I gave it to
my father), but I'll try to test vdpau on it. If I don't answer in a month,
feel free to close this bug (assuming it
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #11 from Scott Moreau ore...@gmail.com ---
(In reply to comment #10)
Do you have still the same problem with current mesa ? On my rv350 works
good.
Can you say what distro, kernel and mesa version you're using?
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=39308
--- Comment #5 from Andy Furniss li...@andyfurniss.entadsl.com ---
(In reply to comment #4)
I don't have full access to my old machine with the rv350 anymore (I gave it
to my father), but I'll try to test vdpau on it. If I don't answer in a
On 12/03/2012 05:40 PM, Daniel Vetter wrote:
On Mon, Dec 3, 2012 at 10:30 AM, Mark Zhang nvmarkzh...@gmail.com wrote:
I'm new in kernel development. Could you tell me or give me some
materials to read that why we need to align the size of IOCTL structures
to 64bit? I can understand if we're
On 12/04/2012 05:03 AM, Thierry Reding wrote:
[...]
I think there's room for letting Terje's complete knowledge of future
chips guide the design of the current code that's sent upstream.
Certainly we shouldn't add a ton of unnecessary abstraction layers
right now that aren't needed for
On 12/04/2012 05:03 AM, Thierry Reding wrote:
[...]
One other thing that such a design can help with is refactoring common
code or parameterizing code. Maybe newer generations are not compatible
but can easily be made to work with existing code by introducing a
variable such as register
On 11/28/2012 02:37 PM, Mark Zhang wrote:
On 11/28/2012 05:39 AM, Stephen Warren wrote:
On 11/27/2012 11:17 AM, Stephen Warren wrote:
On 11/26/2012 08:16 PM, Mark Zhang wrote:
On 11/27/2012 06:37 AM, Stephen Warren wrote:
On 11/22/2012 12:37 PM, Thierry Reding wrote:
Instead of using the
On 12/03/2012 08:00 PM, Mark Zhang wrote:
On 11/28/2012 02:37 PM, Mark Zhang wrote:
On 11/28/2012 05:39 AM, Stephen Warren wrote:
On 11/27/2012 11:17 AM, Stephen Warren wrote:
On 11/26/2012 08:16 PM, Mark Zhang wrote:
On 11/27/2012 06:37 AM, Stephen Warren wrote:
On 11/22/2012 12:37 PM,
On 12/04/2012 11:50 AM, Stephen Warren wrote:
On 12/03/2012 08:00 PM, Mark Zhang wrote:
On 11/28/2012 02:37 PM, Mark Zhang wrote:
On 11/28/2012 05:39 AM, Stephen Warren wrote:
On 11/27/2012 11:17 AM, Stephen Warren wrote:
On 11/26/2012 08:16 PM, Mark Zhang wrote:
On 11/27/2012 06:37 AM,
2012/12/3 Prathyush K prathyus...@samsung.com
Changelog v2:
Implement copy sgt code in exynos_get_sgt itself instead of calling
sg_clone_table.
Now we are working on dmabuf feature update that adds attach and detach
callbacks and with this patch, exynos_get_sgt function will be removed.
For
2012/12/3 Prathyush K prathyus...@samsung.com
According to the new IOMMU framework for exynos sysmmus, the owner
of the sysmmu-tv is mixer (which is the actual device that does DMA)
and not hdmi.
The mmu-master in sysmmu-tv node is set as below in exynos5250.dtsi.
sysmmu-tv {
-
Changelog v2:
move iommu support feature to mixer side.
And below is Prathyush's comment.
According to the new IOMMU framework for exynos sysmmus,
the owner of the sysmmu-tv is mixer (which is the actual
device that does DMA) and not hdmi.
The mmu-master in sysmmu-tv node is set as below in
On 03.12.2012 23:03, Thierry Reding wrote:
What's really difficult to follow is if an ops structure is accessed via
some global macro. It also breaks encapsulation because you have a
global ops structure. That may even work fine for now, but it will break
once you have more than a single
Add more CC's
On Mon, Dec 3, 2012 at 12:39 PM, Heinz Diehl h...@fancy-poultry.org wrote:
Hi,
with latest linus-3.7 git from today, after some time, my machine gets
more and more unresponsible, fanspeed increases, and that's what I see in the
logs:
Dec 3 18:08:10 wildsau kernel:
46 matches
Mail list logo
