t works for you).
--
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>
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] [drm:i915_
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 ho
And Below is my comments and please send them as code cleanup. Actually,
your patch includes code cleanup also.
Thanks,
Inki Dae
2012/12/3 Prathyush K
> 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)
> a
d 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 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>
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 exynos
2012/12/3 Prathyush K
> 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 =
2012/12/3 Prathyush K
> 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 this, please refe
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
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
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
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:
>> Inst
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 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/03/2012 05:40 PM, Daniel Vetter wrote:
> 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 64bi
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 I
https://bugs.freedesktop.org/show_bug.cgi?id=39308
--- Comment #5 from Andy Furniss ---
(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
> month, feel free to close thi
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #11 from Scott Moreau ---
(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 receiving this mail be
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 o
https://bugs.freedesktop.org/show_bug.cgi?id=39308
--- Comment #4 from almos ---
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 works for you).
--
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121203/abe1a518/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #10 from Tomasz P. ---
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.
___
dri-deve
https://bugs.freedesktop.org/show_bug.cgi?id=41051
--- Comment #1 from Tomasz P. ---
Still you have the same problem ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=39308
--- Comment #3 from Tomasz P. ---
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.
___
dri-devel mailing list
dri-de
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 o
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
> >>>
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 o
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] [drm:i915_
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 f
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 host1x
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 = <&mixer>;
};
This patch moves the io
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 host1x
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 o
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.
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.
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 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
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 I
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>
47 matches
Mail list logo
