similar to: [PATCH 00/15] Share TTM code among framebuffer drivers

On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: > Hi > > Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: > > Hi, > > > >> If not for TTM, what would be the alternative? One VMA manager per > >> memory region per device? > > > > Depends pretty much on the device. > > > > The cirrus is a display device with

On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi > > Am 15.04.19 um 17:54 schrieb Daniel Vetter: > > On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: > >> Hi > >> > >> Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: > >>> Hi, > >>> > >>>> If not

On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi > > Am 15.04.19 um 17:54 schrieb Daniel Vetter: > > On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: > >> Hi > >> > >> Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: > >>> Hi, > >>> > >>>> If not

On Tue, 9 Apr 2019 at 17:12, kraxel at redhat.com <kraxel at redhat.com> wrote: > > Hi, > > > If not for TTM, what would be the alternative? One VMA manager per > > memory region per device? > > Depends pretty much on the device. > > The cirrus is a display device with only 4 MB of vram. You can't fit > much in there. A single 1024x768 @ 24bpp

On Tue, Apr 16, 2019 at 12:05 PM Koenig, Christian <Christian.Koenig at amd.com> wrote: > > Am 15.04.19 um 21:17 schrieb Daniel Vetter: > > On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > >> Hi > >> > >> Am 15.04.19 um 17:54 schrieb Daniel Vetter: > >>> On Tue, Apr 09, 2019 at 09:50:40AM +0200,

Am 15.04.19 um 21:17 schrieb Daniel Vetter: > On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> Hi >> >> Am 15.04.19 um 17:54 schrieb Daniel Vetter: >>> On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: >>>> Hi >>>> >>>> Am 09.04.19 um 09:12 schrieb kraxel at redhat.com:

Hi Am 06.05.19 um 14:22 schrieb Gerd Hoffmann: >> GEM VRAM could implement PRIME helpers, which would allow for using >> the generic fbcon. > > bochs_gem_prime_*() functions with this series applied look like you can > just rename them & move over to vram helpers. > > It's not a full prime implementation, specifically actual export/import > isn't there.

Hi Am 06.05.19 um 14:22 schrieb Gerd Hoffmann: >> GEM VRAM could implement PRIME helpers, which would allow for using >> the generic fbcon. > > bochs_gem_prime_*() functions with this series applied look like you can > just rename them & move over to vram helpers. > > It's not a full prime implementation, specifically actual export/import > isn't there.

Well first problem is I'm not sure if that is a good idea. Essentially we want to get rid of TTM in the long run. On the other hand this work might aid with that goal, so it might be worth a try. Second is that this might actually not work of hand. The problem is here: > + /* TODO: This test used to be performed by drivers, but can > + * this actually happen? If so, should we put

Hi, most of this patch set still needs reviews. If it's too large for merging or reviewing at once, I could move the driver changes into separate patch sets. The vbox driver's changes have been accepted by Hans already. So only keeping the core changes plus vbox would be an option. Best regards Thomas Am 08.05.19 um 10:26 schrieb Thomas Zimmermann: > Several simple framebuffer

Am 08.04.19 um 13:59 schrieb Thomas Zimmermann: [SNIP] > If not for TTM, what would be the alternative? One VMA manager per > memory region per device? Since everybody vital seems to be on this mail thread anyway, let's use it a bit for brain storming what a possible replacement for TTM should look like. Well for simple drivers like qemu/bochs and cirrus the answer is to not use it

On Mon, May 06, 2019 at 10:26:30AM +0200, Thomas Zimmermann wrote: > Several simple framebuffer drivers copy most of the TTM code from each > other. The implementation is always the same; except for the name of > some data structures. > > As recently discussed, this patch set provides generic memory-management > code for simple framebuffers with dedicated video memory. It

On Wed, Apr 15, 2020 at 10:01 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > > > Am 15.04.20 um 09:40 schrieb Daniel Vetter: > > Because it is. Huge congrats to everyone who made this kind of > > refactoring happen! > > Every other week, I felt an urge to send out this patch. Thank you so > much, Daniel! There are more candidates for tiny/. They are

On Wed, Apr 15, 2020 at 10:01 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > > > Am 15.04.20 um 09:40 schrieb Daniel Vetter: > > Because it is. Huge congrats to everyone who made this kind of > > refactoring happen! > > Every other week, I felt an urge to send out this patch. Thank you so > much, Daniel! There are more candidates for tiny/. They are

On Mon, May 06, 2019 at 03:09:20PM +0200, Thomas Zimmermann wrote: > Hi > > Am 06.05.19 um 14:22 schrieb Gerd Hoffmann: > >> GEM VRAM could implement PRIME helpers, which would allow for using > >> the generic fbcon. > > > > bochs_gem_prime_*() functions with this series applied look like you can > > just rename them & move over to vram helpers.

On Wed, May 15, 2019 at 09:05:54AM +0200, Thomas Zimmermann wrote: > Hi, > > most of this patch set still needs reviews. > > If it's too large for merging or reviewing at once, I could move the > driver changes into separate patch sets. The vbox driver's changes have > been accepted by Hans already. So only keeping the core changes plus > vbox would be an option.

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same