All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
Date: Fri, 16 Nov 2012 07:15:13 +0000	[thread overview]
Message-ID: <50A5E801.3000100@ti.com> (raw)
In-Reply-To: <20121112225037.GU6801@atomide.com>

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

On 2012-11-13 00:50, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [121112 02:27]:
>> Hi,
>>
>> This series changes omapfb to use standard dma_alloc funcs instead of omap
>> specific vram allocator. This let's us remove the omap vram allocator, making
>> omapfb platform independent.
>>
>> However, note that using standard dma funcs causes the following downsides:
>>
>> 1) dma_alloc_attrs doesn't let us allocate at certain physical address.
>> However, this should not be a problem as this feature of vram allocator
>> is only used when reserving the framebuffer that was initialized by the
>> bootloader, and we don't currently support "passing" a framebuffer from
>> the bootloader to the kernel anyway.
>>
>> 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
>> we don't need the ioremap when using VRFB. This patch uses
>> DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
>> not operational.
>>
>> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
>> changed the ioctl to return 64M for all the values, which, I hope, the
>> applications will interpret as "there's enough vram".
>>
>> 4) "vram" kernel parameter to define how much ram to reserve for video use no
>> longer works. The user needs to enable CMA and use "cma" parameter.
> 
> Great, thanks for fixing these. Could you please queue these into
> a separate branch against v3.7-rc5 that I can also merge into
> omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3?
> 
> Feel free to add my Acked-by: Tony Lindgren <tony@atomide.com> to the
> arch/arm/*omap*/* parts.

I added your acks, and pushed:

git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion

It's based on -rc4 as my other branches are based on that.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: archit@ti.com, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
Date: Fri, 16 Nov 2012 09:15:13 +0200	[thread overview]
Message-ID: <50A5E801.3000100@ti.com> (raw)
In-Reply-To: <20121112225037.GU6801@atomide.com>

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

On 2012-11-13 00:50, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [121112 02:27]:
>> Hi,
>>
>> This series changes omapfb to use standard dma_alloc funcs instead of omap
>> specific vram allocator. This let's us remove the omap vram allocator, making
>> omapfb platform independent.
>>
>> However, note that using standard dma funcs causes the following downsides:
>>
>> 1) dma_alloc_attrs doesn't let us allocate at certain physical address.
>> However, this should not be a problem as this feature of vram allocator
>> is only used when reserving the framebuffer that was initialized by the
>> bootloader, and we don't currently support "passing" a framebuffer from
>> the bootloader to the kernel anyway.
>>
>> 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
>> we don't need the ioremap when using VRFB. This patch uses
>> DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
>> not operational.
>>
>> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
>> changed the ioctl to return 64M for all the values, which, I hope, the
>> applications will interpret as "there's enough vram".
>>
>> 4) "vram" kernel parameter to define how much ram to reserve for video use no
>> longer works. The user needs to enable CMA and use "cma" parameter.
> 
> Great, thanks for fixing these. Could you please queue these into
> a separate branch against v3.7-rc5 that I can also merge into
> omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3?
> 
> Feel free to add my Acked-by: Tony Lindgren <tony@atomide.com> to the
> arch/arm/*omap*/* parts.

I added your acks, and pushed:

git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion

It's based on -rc4 as my other branches are based on that.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: tomi.valkeinen@ti.com (Tomi Valkeinen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
Date: Fri, 16 Nov 2012 09:15:13 +0200	[thread overview]
Message-ID: <50A5E801.3000100@ti.com> (raw)
In-Reply-To: <20121112225037.GU6801@atomide.com>

On 2012-11-13 00:50, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [121112 02:27]:
>> Hi,
>>
>> This series changes omapfb to use standard dma_alloc funcs instead of omap
>> specific vram allocator. This let's us remove the omap vram allocator, making
>> omapfb platform independent.
>>
>> However, note that using standard dma funcs causes the following downsides:
>>
>> 1) dma_alloc_attrs doesn't let us allocate at certain physical address.
>> However, this should not be a problem as this feature of vram allocator
>> is only used when reserving the framebuffer that was initialized by the
>> bootloader, and we don't currently support "passing" a framebuffer from
>> the bootloader to the kernel anyway.
>>
>> 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
>> we don't need the ioremap when using VRFB. This patch uses
>> DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
>> not operational.
>>
>> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
>> changed the ioctl to return 64M for all the values, which, I hope, the
>> applications will interpret as "there's enough vram".
>>
>> 4) "vram" kernel parameter to define how much ram to reserve for video use no
>> longer works. The user needs to enable CMA and use "cma" parameter.
> 
> Great, thanks for fixing these. Could you please queue these into
> a separate branch against v3.7-rc5 that I can also merge into
> omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3?
> 
> Feel free to add my Acked-by: Tony Lindgren <tony@atomide.com> to the
> arch/arm/*omap*/* parts.

I added your acks, and pushed:

git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion

It's based on -rc4 as my other branches are based on that.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121116/826d1247/attachment.sig>

  reply	other threads:[~2012-11-16  7:15 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-12 10:25 [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 1/5] OMAP: FB: use DMA_BIT_MASK() for fb's coherent_dma_mask Tomi Valkeinen
2012-11-12 10:25   ` Tomi Valkeinen
2012-11-12 10:25   ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 2/5] OMAPFB: use dma_alloc_attrs to allocate memory Tomi Valkeinen
2012-11-12 10:25   ` Tomi Valkeinen
2012-11-12 10:25   ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 3/5] OMAP: RX51: remove use of vram Tomi Valkeinen
2012-11-12 10:25   ` Tomi Valkeinen
2012-11-12 10:25   ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 4/5] OMAP: common.c: remove init call to vram Tomi Valkeinen
2012-11-12 10:25   ` Tomi Valkeinen
2012-11-12 10:25   ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 5/5] OMAP: remove vram allocator Tomi Valkeinen
2012-11-12 10:25   ` Tomi Valkeinen
2012-11-12 10:25   ` Tomi Valkeinen
2012-11-12 13:39 ` [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Grazvydas Ignotas
2012-11-12 13:39   ` Grazvydas Ignotas
2012-11-12 13:39   ` Grazvydas Ignotas
2012-11-12 13:50   ` Tomi Valkeinen
2012-11-12 13:50     ` Tomi Valkeinen
2012-11-12 13:50     ` Tomi Valkeinen
2012-11-12 13:57   ` Tomi Valkeinen
2012-11-12 13:57     ` Tomi Valkeinen
2012-11-12 13:57     ` Tomi Valkeinen
2012-11-12 22:50 ` Tony Lindgren
2012-11-12 22:50   ` Tony Lindgren
2012-11-12 22:50   ` Tony Lindgren
2012-11-16  7:15   ` Tomi Valkeinen [this message]
2012-11-16  7:15     ` Tomi Valkeinen
2012-11-16  7:15     ` Tomi Valkeinen
2012-11-20 22:14     ` Tony Lindgren
2012-11-20 22:14       ` Tony Lindgren
2012-11-20 22:14       ` Tony Lindgren
2012-11-21 14:22       ` Jello huang
2012-11-21 14:22         ` Jello huang
2012-11-21 14:22         ` Jello huang
2012-11-22 13:52         ` Tomi Valkeinen
2012-11-22 13:52           ` Tomi Valkeinen
2012-11-22 13:52           ` Tomi Valkeinen
2012-11-23 10:07           ` Jello huang
2012-11-23 10:07             ` Jello huang
2012-11-16  9:06   ` Tomi Valkeinen
2012-11-16  9:06     ` Tomi Valkeinen
2012-11-16  9:06     ` Tomi Valkeinen
2012-11-19 22:04     ` Tony Lindgren
2012-11-19 22:04       ` Tony Lindgren
2012-11-19 22:04       ` Tony Lindgren
2012-11-20 15:09       ` Tomi Valkeinen
2012-11-20 15:09         ` Tomi Valkeinen
2012-11-20 15:09         ` Tomi Valkeinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50A5E801.3000100@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.