On Fri, Dec 10, 2021 at 07:54:34PM -0500, Felix Kuehling wrote:
> Do you actually need to restore the exact boot-up mode? If you have the same
> framebuffer memory layout (width, height, bpp, stride) the precise display
> timing doesn't really matter. So we "just" need to switch to a mode that's
Hi,
> > The drivers are asic and platform specific. E.g., the driver for
> > vangogh is different from renoir is different from skylake, etc. The
> > display programming interfaces are asic specific.
>
> Cool, that makes sense! But if you (or anybody here) know some of these
> GOP drivers, e.
On Tue, Dec 01, 2020 at 11:35:40AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert virtgpu to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Gerd Hoffmann
Acked
On Tue, Dec 01, 2020 at 11:35:36AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert qxl to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Gerd Hoffmann
Acked
On Tue, Dec 01, 2020 at 11:35:27AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert cirrus to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Gerd Hoffmann
Acked
On Tue, Dec 01, 2020 at 11:35:26AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert bochs to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Gerd Hoffmann
Acked
> > > The comments I've found suggest very much not ... Or is that all very
> > > old stuff only that no one cares about anymore?
> >
> > I think these days it is possible to override dma_ops per device, which
> > in turn allows virtio to deal with the quirks without the rest of the
> > kernel kno
On Mon, Sep 07, 2020 at 03:53:02PM +0200, Daniel Vetter wrote:
> On Mon, Sep 7, 2020 at 1:24 PM Gerd Hoffmann wrote:
> >
> > Add drm_device argument to drm_prime_pages_to_sg(), so we can
> > call dma_max_mapping_size() to figure the segment size limit
> > and call into
gnore segment size limits
so far ...
v2: place max_segment in drm driver not gem object.
v3: move max_segment next to the other gem fields.
v4: just use dma_max_mapping_size().
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_prime.h | 3 ++-
drivers/gpu/drm/amd/a
> > + /**
> > +* @max_segment:
> > +*
> > +* Max size for scatter list segments. When unset the default
> > +* (SCATTERLIST_MAX_SEGMENT) is used.
> > +*/
> > + size_t max_segment;
>
> Is there no better place for this then "at the bottom"? drm_device is a
> huge structure,
drm driver not gem object.
v3: move max_segment next to the other gem fields.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_device.h| 8
include/drm/drm_prime.h | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 3 ++-
drivers/gpu/drm
drm driver not gem object.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_device.h| 8
include/drm/drm_prime.h | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 3 ++-
drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++-
drivers/gpu/drm
Hi,
> > > I'm missing an explanation why this should be useful (it certainly is).
> > virtio-gpu needs this to work properly with SEV (see patch 2/2 of this
> > series).
>
> Yeah, that's the problem patch 2/2 never showed up here :)
The list should have everything.
Your inbox probably has 1/2
On Tue, Aug 18, 2020 at 09:57:59AM +0200, Christian König wrote:
> Am 18.08.20 um 09:48 schrieb Gerd Hoffmann:
> > Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
> > through to the __sg_alloc_table_from_pages() call, otherwise use
> > SCATTERLIST_MAX_S
Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
through to the __sg_alloc_table_from_pages() call, otherwise use
SCATTERLIST_MAX_SEGMENT.
Also add max_segment field to gem objects and pass it to
drm_prime_pages_to_sg() calls in drivers and helpers.
Signed-off-by: Gerd
On Thu, Mar 05, 2020 at 02:29:08PM +0100, Nirmoy Das wrote:
> Calculate GEM VRAM bo's offset within vram-helper without depending on
> bo->offset.
>
> Signed-off-by: Nirmoy Das
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 9 -
> 1 file changed, 8 insertio
Hi,
> 2 unfortunately I can't say the same for bochs but it works with this patch
> series so I think bochs is fine as well.
bochs needs the offset only to scanout framebuffers, which in turn
requires framebuffers being pinned to vram. So all green here.
cheers,
Gerd
__
On Mon, Feb 17, 2020 at 04:04:25PM +0100, Nirmoy Das wrote:
> Calculate GPU offset within vram-helper without depending on
> bo->offset
>
> Signed-off-by: Nirmoy Das
Acked-by: Gerd Hoffmann
___
amd-gfx mailing list
amd-gfx@lists.
On Mon, Feb 17, 2020 at 04:04:26PM +0100, Nirmoy Das wrote:
> Switch over to GEM VRAM's implementation to retrieve bo->offset
>
> Signed-off-by: Nirmoy Das
Acked-by: Gerd Hoffmann
___
amd-gfx mailing list
amd-gfx@lists.free
On Mon, Feb 17, 2020 at 11:18:40AM +0100, Nirmoy Das wrote:
> Calculate GPU offset within bochs driver itself without depending on
> bo->offset
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/bochs/bochs_kms.c | 3 ++-
> drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
> 2 files changed,
that I'll happily
Acked-by: Gerd Hoffmann
cheers,
Gerd
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> @@ -311,10 +311,8 @@ qxl_bo_physical_address(struct qxl_device *qdev, struct
> qxl_bo *bo,
> (bo->tbo.mem.mem_type == TTM_PL_VRAM)
> ? &qdev->main_slot : &qdev->surfaces_slot;
>
> - WARN_ON_ONCE((bo->tbo.offset & slot->gpu_offset) != slot->gpu_offset);
> -
> -
driver's private dmabuf update. It is not needed
any more now that we are doing this for everybody.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
Reviewed-by: Alex Deucher
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +---
drivers/gp
driver's private dmabuf update. It is not needed
any more now that we are doing this for everybody.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +---
drivers/gpu/drm/drm_prime.c | 4 +++-
2 files changed, 4 insertions(+), 4 deletions(-)
d to series
Signed-off-by: Gerd Hoffmann
Acked-by: Thomas Zimmermann
---
include/drm/ttm/ttm_bo_api.h | 10 --
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 -
drivers/gpu/drm/ttm/ttm_bo_vm.c| 8 ++--
3 files changed, 10 insertions(+), 13 delet
Rename ttm_fbdev_mmap to ttm_bo_mmap_obj. Move the vm_pgoff sanity
check to amdgpu_bo_fbdev_mmap (only ttm_fbdev_mmap user in tree).
The ttm_bo_mmap_obj function can now be used to map any buffer object.
This allows to implement &drm_gem_object_funcs.mmap in gem ttm helpers.
Signed-off-by:
Pass gem vma_offset_manager to ttm_bo_device_init(), so ttm uses it
instead of its own embedded struct. This makes some gem functions
(specifically drm_gem_object_lookup) work on ttm objects.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
1 file changed, 1
_vma_manager is used.
All callers are updated to pass NULL, so the behavior doesn't change.
Signed-off-by: Gerd Hoffmann
---
include/drm/ttm/ttm_bo_driver.h | 8 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 +
drivers/gpu/drm/drm_vram_mm_helper.c| 1 +
drivers/gpu/drm/no
Pass gem vma_offset_manager to ttm_bo_device_init(), so ttm uses it
instead of its own embedded struct. This makes some gem functions
(specifically drm_gem_object_lookup) work on ttm objects.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
1 file changed, 1
Not needed any more for remove_conflicting_pci_framebuffers calls.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_fb_helper.h | 4 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
drivers/gpu/drm/bochs/bochs_drv.c | 2 +-
drivers/gpu/drm/cirrus/cirrus.c | 2
hat when necessary the GEM
> object can be initialized in between. I think that's slightly more
> flexible and easier to understand than a boolean flag.
Yes, that should work too.
Acked-by: Gerd Hoffmann
cheers,
Gerd
___
amd-gfx mailing lis
ng the order doesn't look hard. Patch attached (untested, have no
test hardware). But maybe I missed some detail ...
The other patch attached works around the issue with a flag, to avoid
drm_vma_node_reset() being called twice.
cheers,
Gerd
>From af43f933533140e2df58176a68df0c60ba08227
On Fri, Aug 09, 2019 at 09:47:00AM +0200, Borislav Petkov wrote:
> Hi,
>
> On Fri, Aug 09, 2019 at 09:21:33AM +0200, Gerd Hoffmann wrote:
> > On Thu, Aug 08, 2019 at 07:45:42PM +0200, Borislav Petkov wrote:
> > > Hi,
> > >
> > > for some unfathomable t
Drop vma_node from ttm_buffer_object, use the gem struct
(base.vma_node) instead.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_object.h | 2
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_benchmark.c | 4 ++--
drivers/gpu/drm/radeon/radeon_cs.c| 2 +-
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 6 +++---
drivers/gpu/drm/radeon
Drop drm_gem_object from amdgpu_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/amd/amdgpu
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers
Drop drm_gem_object from radeon_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 3 +--
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_benchmark.c | 4 ++--
drivers/gpu/drm/radeon/radeon_cs.c| 2 +-
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 6 +++---
drivers/gpu/drm/radeon
Drop vma_node from ttm_buffer_object, use the gem struct
(base.vma_node) instead.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_object.h | 2
Drop drm_gem_object from amdgpu_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/amd/amdgpu
Drop drm_gem_object from radeon_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 3 +--
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers
Drop drm_gem_object from radeon_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 3 +--
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_benchmark.c | 4 ++--
drivers/gpu/drm/radeon/radeon_cs.c| 2 +-
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 6 +++---
drivers/gpu/drm/radeon
Drop drm_gem_object from amdgpu_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/amd/amdgpu
Drop vma_node from ttm_buffer_object, use the gem struct
(base.vma_node) instead.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_object.h | 2
Drop vma_node from ttm_buffer_object, use the gem struct
(base.vma_node) instead.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_object.h | 2
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_benchmark.c | 4 ++--
drivers/gpu/drm/radeon/radeon_cs.c| 2 +-
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 6 +++---
drivers/gpu/drm/radeon
Drop drm_gem_object from radeon_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 3 +--
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers
Drop drm_gem_object from amdgpu_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/amd/amdgpu
Signed-off-by: Gerd Hoffmann
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +--
drivers/gpu/drm/amd/amdgpu
Drop vma_node from ttm_buffer_object, use the gem struct
(base.vma_node) instead.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/virtio
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/radeon/radeon_benchmark.c | 4 ++--
drivers/gpu/drm/radeon/radeon_cs.c| 2 +-
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 6 +++---
drivers/gpu/drm/radeon/radeon_mn.c| 2 +-
drivers
Drop drm_gem_object from radeon_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/radeon/radeon.h | 3 +--
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon/radeon_display.c | 4 ++--
drivers/gpu/drm
Drop drm_gem_object from amdgpu_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers/gpu
Drop vma_node from ttm_buffer_object, use the gem struct
(base.vma_node) instead.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/virtio
Hi,
> > R600+ supports bigendian framebuffer formats, so no byteswapping on
> > access is needed. Not sure whenever that includes 16bpp formats or
> > whenever this is limited to the 8 bit-per-color formats [...]
>
> It includes 16bpp. Looking at
> drivers/gpu/drm/radeon/atombios_crtc.c:dce4_c
Hi,
> I also think that this patch requires more comments than the
> commit message has at the moment.
>
> Removing the definition also removes the possibility to describe a lot
> of pixel formats, so that should definitely be mentioned. I think it
> would also be good to have some kind of just
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 995c8f9c69..305bc34be0 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -33,8 +33,6 @@ extern "C" {
> > #define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) <<
Add drm_mode_legacy_fb_format variant which returns fourcc codes
for framebuffer format in host byte order.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_fourcc.h | 3 +++
drivers/gpu/drm/drm_fourcc.c | 54 +++-
2 files changed, 56 insertions
Add fourcc variants in cpu byte order. With these at hand we don't
need #ifdefs in drivers want support framebuffers in cpu endianess.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_fourcc.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/drm/drm_fourcc.h b/in
drm_mode_legacy_fb_format() call in
drm_mode_addfb() ? Add some driver flag?
Gerd Hoffmann (3):
drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN
drm: fourcc byteorder: add DRM_FORMAT_CPU_*
drm: fourcc byteorder: add drm_mode_legacy_fb_format_he
include/drm/drm_fourcc.h | 15 +++
include
It's unused.
Suggested-by: Daniel Vetter
Signed-off-by: Gerd Hoffmann
---
include/uapi/drm/drm_fourcc.h | 2 --
drivers/gpu/drm/drm_fourcc.c | 3 +--
drivers/gpu/drm/drm_framebuffer.c | 2 +-
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/drm_fou
Hi,
> > So just not using the swapping indeed looks like the only sensible
> > option. Which in turn implies there is no BGRA support for dumb
> > bos. Hmm, I can see the problem. Userspace expectation appears to be
> > that ADDFB configures a native endian framebuffer, which the driver
>
Hi,
> > That is done using the RADEON_TILING_SWAP_{16,32}BIT flag mentioned in
> > another thread?
>
> Right.
>
>
> > What about dumb bos? You've mentioned the swap flag isn't used for
> > those. Which implies they are in little endian byte order (both gpu and
> > cpu view).
>
> Right, AFA
> uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
> {
> uint32_t fmt;
> #ifdef __BIG_ENDIAN
> enum { LITTLE_ENDIAN = 0 };
> #else
> enum { LITTLE_ENDIAN = 1 };
> #endif
> /* ... */
>
> (using an enum for
Hi,
> >> Just to reiterate, this won't work for the radeon driver, which programs
> >> the GPU to use (effectively, per the current definition that these are
> >> little endian GPU formats) DRM_FORMAT_XRGB with pre-R600 and
> >> DRM_FORMAT_BGRX with >= R600.
> >
> > Hmm, ok, how does bi
On Di, 2017-04-25 at 12:18 +0900, Michel Dänzer wrote:
> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
> > Return correct fourcc codes on bigendian. Drivers must be adapted to
> > this change.
> >
> > Signed-off-by: Gerd Hoffmann
>
> Just to reiterate, this won&#x
Hi,
> > Gerd Hoffmann (6):
> > drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN
>
> I don't see how it can be dropped. It's only optional for formats where
> all components have 8 bits.
Well, we can, because it is simply not used anywhere ...
We indeed can&
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 857755ac2d..781d35bdff 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_gem.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_plane.c | 31 ---
2 files changed, 1 insertion(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio
pping depending on cpu byte order. So, one way to adapt the
driver would be to simply use the new #defines added by patch #2. The
other way would be to support both XRGB and BGRX and turn on/off
byteswapping depending on framebuffer format instead of cpu byte order.
cheers,
Gerd
Gerd Hoffma
Return correct fourcc codes on bigendian. Drivers must be adapted to
this change.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_fourcc.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index
While wading through the code I've noticed we have a little issue in
virtio: We attach a format to the bo when it is created
(DRM_IOCTL_MODE_CREATE_DUMB), not when we map it as framebuffer
(DRM_IOCTL_MODE_ADDFB).
Easy way out: support a single format only.
Signed-off-by: Gerd Hof
Add fourcc variants in cpu byte order. With these at hand we don't
need #ifdefs in drivers want support framebuffers in cpu endianess.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_fourcc.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/drm/drm_fourcc.h b/in
It's unused.
Suggested-by: Daniel Vetter
Signed-off-by: Gerd Hoffmann
---
include/uapi/drm/drm_fourcc.h | 2 --
drivers/gpu/drm/drm_fourcc.c | 3 +--
drivers/gpu/drm/drm_framebuffer.c | 2 +-
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/drm_fou
Hi,
> > I guess that makes changing drm_mode_legacy_fb_format + drivers a
> > reasonable option ...
>
> Yeah, I came to the same conclusion after chatting with some
> folks on irc.
>
> So my current idea is that we change any driver that wants to follow the
> CPU endianness to declare support
Hi,
> > My personal opinion is that formats in drm_fourcc.h should be
> > independent of the CPU byte order and the function
> > drm_mode_legacy_fb_format() and drivers depending on that incorrect
> > assumption be fixed instead.
>
> The problem is this isn't a kernel-internal thing any more
Hi,
> > "native" to me feels more like "native to the GPU" since these things
> > really are tied to the GPU not the CPU. That's also why I went with the
> > explicit endianness originally so that the driver could properly declare
> > what the GPU supports.
> And to be honest I would really pref
Hi,
> > I personally find "native" more intuitive, but at the end of the day I
> > don't mind much. If people prefer "host" over "native" I'll change it.
>
> "native" to me feels more like "native to the GPU" since these things
> really are tied to the GPU not the CPU.
Ok, then maybe "host" i
On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> > While working on graphics support for virtual machines on ppc64 (which
> > exists in both little and big endian variants) I've figured the comments
> &
Hi,
> > Leaving the yuv formats as-is. I have no idea if and how those are used
> > on bigendian machines.
> just an idea - since we are not sure how the remaining formats are being
> used, should those be marked somehow uncertain whether they are little
> or native endian?
ATM the yuv don't
lia Mirkin
Cc: Michel Dänzer
Cc: Alex Deucher
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Gerd Hoffmann
---
include/uapi/drm/drm_fourcc.h | 82 +--
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/includ
Hi,
> > >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses
> > >> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses
> > >> native endian packed colour values.
> > >
> > > Same is true for DRM_IOCTL_MODE_ADDFB, with depth/bpp 24/32 you'll get
> > > D
Hi,
> Right. Very nice if we can trust the virtual machine at least getting
> things right, gives some chance for people to test anything. Except...
> that's a question of what kind of hardware the virtual machine
> emulates. The display device defines what endianess it uses on
> framebuffers, n
Hi,
> > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest
> > here, it drives the qemu stdvga with offb, not bochs-drm.
>
> I suppose this proves the virtual machine itself is correct about
> framebuffer endianess? Except you are running it on a little-endian
> host machine
Hi,
> > Quite true that this proves nothing. However one should note that
> > fbcon -> fbdev works,
>
> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses
> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses
> native endian packed colour values.
Same is
Hi,
> > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
> > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
> > only format supported by bochs-drm), and we have to interpret that in
> > bigendian byte order on the host side to get a correct displa
Hi,
> > Just let know what you need tested, I should be able to turn it around
> > within a couple of days.
>
> That's part of my problem. I don't really know what should be tested.
> What do people do with their BE machines that we should avoid breaking?
For the virtual machine use case the b
Hi,
> which software have you used as representative of "reality"?
ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
only format supported by bochs-drm), and we have to interpret that in
bigendian byt
the codebase
I suspect this problem applies to more formats. When looking at
drm_mode_legacy_fb_format it seems *all* RGB formats are actually
native endian not little endian.
Dunno where we stand in terms of YCbCr.
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: amd-gfx@lists.freedesktop.org
Sign
94 matches
Mail list logo
