[PATCH v5 0/3] drm/nouveau: set DMA mask before mapping scratch page

mask to probe hook (Alexander) v3: rework code to get rid of DMA_ERROR_CODE references, which is not defined on all architectures v2: replace incorrect comparison of dma_addr_t type var against NULL Ard Biesheuvel (3): drm/nouveau: set streaming DMA mask early drm/nouveau/fb/gf100: defe

[PATCH v5 2/3] drm/nouveau/fb/gf100: defer DMA mapping of scratch page to oneinit() hook

the dma_map_page() to the .oneinit hook, which executes after the DMA mask has been set. Signed-off-by: Ard Biesheuvel --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c | 31 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100

[Nouveau] [PATCH v4 1/3] drm/nouveau: set streaming DMA mask early

On 3 October 2016 at 06:39, Alexandre Courbot wrote: > On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel > wrote: >> Some subdevices (i.e., fb/nv50.c and fb/gf100.c) map a scratch page using >> dma_map_page() way before the TTM layer has had a chance to set the DMA >>

[PATCH v5 3/3] drm/nouveau/fb/nv50: defer DMA mapping of scratch page to oneinit() hook

the dma_map_page() to the .oneinit hook, which executes after the DMA mask has been set. Signed-off-by: Ard Biesheuvel --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c | 33 ++-- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c

[PATCH v5 1/3] drm/nouveau: set streaming DMA mask early

RAM is above 4 GB). So set a preliminary DMA mask right after constructing the PCI device, and base it on the .dma_bits member of the MMU subdevice, which is what the TTM layer will base the DMA mask on as well. Signed-off-by: Ard Biesheuvel --- drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c

[PATCH v5 0/3] drm/nouveau: set DMA mask before mapping scratch page

On 7 October 2016 at 09:12, Alexandre Courbot wrote: > On Fri, Oct 7, 2016 at 12:49 AM, Ard Biesheuvel > wrote: >> This v4 is now a 3 piece series (since v4), after Alexandre pointed out that >> both GF 100 and NV50 are affected by the same issue, and that a related issue

[PATCH v4 0/3] drm/nouveau: set DMA mask before mapping scratch page

ct comparison of dma_addr_t type var against NULL Ard Biesheuvel (3): drm/nouveau: set streaming DMA mask early drm/nouveau/fb/gf100: defer DMA mapping of scratch page to init() hook drm/nouveau/fb/nv50: defer DMA mapping of scratch page to init() hook drivers/gpu/drm/nouveau/nouveau_drm.c

[PATCH v4 1/3] drm/nouveau: set streaming DMA mask early

RAM is above 4 GB). So set a preliminary DMA mask right after constructing the PCI device, and base it on the .dma_bits member of the MMU subdevice, which is what the TTM layer will base the DMA mask on as well. Signed-off-by: Ard Biesheuvel --- drivers/gpu/drm/nouveau/nouveau_drm.c | 11

[PATCH v4 3/3] drm/nouveau/fb/nv50: defer DMA mapping of scratch page to init() hook

the dma_map_page() to the .init hook, which executes after the DMA mask has been set. Signed-off-by: Ard Biesheuvel --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c | 30 +--- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c b

[PATCH v4 2/3] drm/nouveau/fb/gf100: defer DMA mapping of scratch page to init() hook

the dma_map_page() to the .init hook, which executes after the DMA mask has been set. Signed-off-by: Ard Biesheuvel --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c | 26 ++-- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c

[RFC PATCH] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

the dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before performing the call. Signed-off-by: Ard Biesheuvel --- I am sure there is a much better way to address this, but this fixes the problem I get on AMD Seattle with a GeForce 210 PCIe card

[RFC PATCH v2] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

the dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before performing the call. Signed-off-by: Ard Biesheuvel --- I am sure there is a much better way to address this, but this fixes the problem I get on AMD Seattle with a GeForce 210 PCIe card

[RFC PATCH] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

On 23 June 2016 at 11:55, Punit Agrawal wrote: > Ard Biesheuvel writes: > >> The 100c08 scratch page is mapped using dma_map_page() before the TTM >> layer has had a chance to set the DMA mask. This means we are still >> running with the default of 32 when this code e

[PATCH v3] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

the dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before performing the call. Signed-off-by: Ard Biesheuvel --- I am sure there is a much better way to address this, but this fixes the problem I get on AMD Seattle with a GeForce 210 PCIe card

[PATCH v3] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

On 7 July 2016 at 18:59, Ard Biesheuvel wrote: > The 100c08 scratch page is mapped using dma_map_page() before the TTM > layer has had a chance to set the DMA mask. This means we are still > running with the default of 32 when this code executes, and this causes > problems f

[Nouveau] [PATCH v3] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

On 15 July 2016 at 07:52, Alexandre Courbot wrote: > On Fri, Jul 8, 2016 at 1:59 AM, Ard Biesheuvel > wrote: >> The 100c08 scratch page is mapped using dma_map_page() before the TTM >> layer has had a chance to set the DMA mask. This means we are still >> running wit

[RFC PATCH v2] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

On 21 June 2016 at 14:50, Ard Biesheuvel wrote: > The 100c08 scratch page is mapped using dma_map_page() before the TTM > layer has had a chance to set the DMA mask. This means we are still > running with the default of 32 when this code executes, and this causes > problems f

Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

On 24 August 2017 at 01:57, Dave Airlie wrote: >> Yeah, maybe it's time to disconnect the "default display device" idea >> from the VGA arbiter. I have no idea what (if any) dependencies X has >> on the legacy VGA resources. I assume X works fine on power, where it >> sounds

Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

On 22 August 2017 at 23:19, Bjorn Helgaas wrote: > On Mon, Aug 21, 2017 at 11:53:01AM +0100, Lorenzo Pieralisi wrote: >> On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote: >> > A system without PCI legacy resources (e.g. ARM64) may find that no >> > default/boot

Re: [PATCH v3 0/3] Split default display handling out from VGA arbiter

.html > If we are all in agreement that fixing X is not an option, I think this is a reasonable approach Acked-by: Ard Biesheuvel <ard.biesheu...@linaro.org> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] vgaarb: Factor out EFI and fallback default device selection

ice(pdev); >> > + >> > + list_for_each_entry(vgadev, _list, list) { >> > + struct device *dev = >pdev->dev; >> > + >> > + if (vgadev->bridge_has_one_vga) >> > + vgaarb_info(dev, "bridge control possible\n"); >> > + else >> > + vgaarb_info(dev, "no bridge control possible\n"); >> > + } >> >> Initially I wondered if this info printk could be moved into >> vga_arbiter_check_bridge_sharing(), but it's been separated out since >> 3448a19da479b ("vgaarb: use bridges to control VGA routing where >> possible."), and upon closer examination, it seems you can't be sure a >> device doesn't share a bridge until the end of the process, so this is >> indeed correct. >> >> Everything else also looks good to me. >> >> Reviewed-by: Daniel Axtens <d...@axtens.net> > > R-b for both patches? And ok with everyone if I pull this into drm-misc > for 4.15 (deadline is end of this week for feature-y stuff)? > For both patches Acked-by: Ard Biesheuvel <ard.biesheu...@linaro.org> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

On 8 December 2017 at 19:30, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly > into nv04_instobj") introduced some new calls to the refcount api to > the nv50 mapping code. In one par

Re: [Nouveau] [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

erre, Thanks for the reply. If a fix has been queued, I don't mind leaving it up to Ben to decide when it gets sent onwards. -- Ard. > [0]: > https://github.com/skeggsb/nouveau/commit/9068f1df2394f0e4ab2b2a28cac06b462fe0a0aa > > On 2017-12-18 — 09:27, Ard Biesheuvel wrote: >>

[PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

refcount_inc(>maps); } i.e., it calls refcount_inc() to increment the refcount when it is known to be zero, which is explicitly forbidden by the API. Instead, use refcount_set() to set it to 1. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- Apologies if this was alre

Re: [PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge

On 17 May 2018 at 16:55, Peter Jones wrote: > On Thu, May 17, 2018 at 09:22:23AM -0400, Sinan Kaya wrote: >> A host bridge is allowed to remap BAR addresses using _TRA attribute in >> _CRS windows. >> >> pci_bus :00: root bus resource [mem 0x8010010-0x8011fff

Re: [PATCH 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer

Hallo Hans, On 17 June 2018 at 17:32, Hans de Goede wrote: > On systems where fbcon is configured for deferred console takeover, the > intend is for the framebuffer to show the boot graphics (e.g a vendor > logo) until some message (e.g. an error) is printed or a graphical > session takes over.

Re: [PATCH 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer

On 18 June 2018 at 11:13, Hans de Goede wrote: > Hi, > > > On 18-06-18 10:43, Ard Biesheuvel wrote: >> >> On 18 June 2018 at 10:30, Hans de Goede wrote: >>> >>> Hi, >>> >>> On 18-06-18 09:36, Ard Biesheuvel wrote: >>>>

Re: [PATCH 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer

On 18 June 2018 at 10:30, Hans de Goede wrote: > Hi, > > On 18-06-18 09:36, Ard Biesheuvel wrote: >> >> Hallo Hans, >> >> On 17 June 2018 at 17:32, Hans de Goede wrote: >>> >>> On systems where fbcon is configured for deferred console take

Re: [PATCH 1/2] efi/bgrt: Drop __initdata from bgrt_image_size

e __initdata. > > Signed-off-by: Hans de Goede Acked-by: Ard Biesheuvel > --- > drivers/firmware/efi/efi-bgrt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/firmware/efi/efi-bgrt.c b/drivers/firmware/efi/efi-bgrt.c > index 50793fda7819.

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

to convert bus address to > resource address in the fixup. > > Signed-off-by: Sinan Kaya Reviewed-by: Ard Biesheuvel Bartlomiej, could you please take these via the fbdev tree for v4.19? Peter already gave his ack but Sinan dropped it (presumably because of the split in v2) Sinan

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

On 13 June 2018 at 16:22, Sinan Kaya wrote: > Hi Ard, > > On 5/18/2018 10:17 AM, Sinan Kaya wrote: >> A host bridge is allowed to remap BAR addresses using _TRA attribute in >> _CRS windows. >> >> pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window] >> (bus address

Re: [PATCH V2 1/2] efi/fb: Simplify fixup code to prefer struct resource

On 18 May 2018 at 16:17, Sinan Kaya wrote: > Get rid of base and size variables in favor of a struct resource. > The conditional for checking window can be replaced with > resource_contains(). > > Signed-off-by: Sinan Kaya Reviewed-by: Ard Biesheuvel > --- > drivers/vid

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

On 13 June 2018 at 17:17, wrote: > On 2018-06-13 11:06, Ard Biesheuvel wrote: >> >> On 13 June 2018 at 16:22, Sinan Kaya wrote: >>> >>> Hi Ard, >>> >>> On 5/18/2018 10:17 AM, Sinan Kaya wrote: >>>> >>>> A host bridge

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

On 22 June 2018 at 21:29, Ard Biesheuvel wrote: > On 22 June 2018 at 20:30, Sinan Kaya wrote: >> On 6/22/2018 2:01 PM, Ard Biesheuvel wrote: >>>> Yes, it is part of the PCI I/O protocol definition. FrameBufferBase is >>>> described as >>>> >&g

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

On 25 June 2018 at 19:28, Sinan Kaya wrote: > On 6/25/2018 11:52 AM, ok...@codeaurora.org wrote: >>> Note that this is not the only MMIO translation related change made by >>> Heyi Guo to the generic PCI host bridge and bus drivers, but given >>> that those did not support MMIO translation at

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

On 22 June 2018 at 15:55, Ard Biesheuvel wrote: > On 22 June 2018 at 15:52, Sinan Kaya wrote: >> Hi Ard, >> >> On 6/22/2018 7:21 AM, Ard Biesheuvel wrote: >>> Apologies for only bringing this up now, but I think this patch is >>> wrong after all. &

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

On 22 June 2018 at 20:30, Sinan Kaya wrote: > On 6/22/2018 2:01 PM, Ard Biesheuvel wrote: >>> Yes, it is part of the PCI I/O protocol definition. FrameBufferBase is >>> described as >>> >>> """ >>> Base address of graphics linea

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

On 13 June 2018 at 18:08, Bartlomiej Zolnierkiewicz wrote: > On Wednesday, June 13, 2018 05:45:48 PM Ard Biesheuvel wrote: >> On 18 May 2018 at 16:17, Sinan Kaya wrote: >> > A host bridge is allowed to remap BAR addresses using _TRA attribute in >> > _CRS windows. >

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

On 20 June 2018 at 00:29, Bjorn Helgaas wrote: > Minor subject nit: From the caller's point of view, we must convert a bus > address to a resource *always* (the caller has no knowledge of "whether it > is translated by the host bridge"). > > On Fri, May 18, 2018 at 10:17:51AM -0400, Sinan Kaya

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

On 22 June 2018 at 15:52, Sinan Kaya wrote: > Hi Ard, > > On 6/22/2018 7:21 AM, Ard Biesheuvel wrote: >> Apologies for only bringing this up now, but I think this patch is >> wrong after all. >> >> screen_info.lfb_base is supposed to be a CPU address, and so >

Re: [PATCH v2 1/2] efi/bgrt: Drop __initdata from bgrt_image_size

On 2 July 2018 at 13:57, Bartlomiej Zolnierkiewicz wrote: > On Monday, July 02, 2018 01:46:09 PM Ard Biesheuvel wrote: >> On 2 July 2018 at 13:26, Hans de Goede wrote: >> > Bartlomiej, >> > >> > Now that the fbcon deferred console takeover patches have been &

Re: [PATCH v2 1/2] efi/bgrt: Drop __initdata from bgrt_image_size

; the efifb code. The efifb driver is a platform driver, using a normal >> driver probe() driver callback. So even though it is always builtin it >> cannot reference __initdata. >> >> Acked-by: Ard Biesheuvel >> Signed-off-by: Hans de Goede >> --- >>

Re: [PATCH v2 1/2] efi/bgrt: Drop __initdata from bgrt_image_size

On 3 July 2018 at 17:24, Bartlomiej Zolnierkiewicz wrote: > On Monday, July 02, 2018 02:02:47 PM Ard Biesheuvel wrote: >> On 2 July 2018 at 13:57, Bartlomiej Zolnierkiewicz >> wrote: >> > On Monday, July 02, 2018 01:46:09 PM Ard Biesheuvel wrote: >> >> On

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

On Thu, 17 Jan 2019 at 07:07, Benjamin Herrenschmidt wrote: > > On Wed, 2019-01-16 at 08:47 +0100, Ard Biesheuvel wrote: > > > As far as I know on x86 it doesn't, so when you have an un-cached page > > > you can still access it with a snooping DMA read/write operati

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig wrote: > > On Mon, Jan 21, 2019 at 05:14:37PM +0100, Ard Biesheuvel wrote: > > > I'll add big fat comments. But the fact that nothing is exported > > > there should be a fairly big hint. > > > > > > &

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote: > > On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote: > > On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig wrote: > > > >> Until that happens we should just change the driver ifdefs to default > >> the hacks t

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Mon, 21 Jan 2019 at 16:07, Christoph Hellwig wrote: > > > +#include > > This header is not for usage in device drivers, but purely for > dma-mapping implementations! > Is that documented anywhere? > > +static inline bool drm_device_can_wc_memory(struct drm_device *ddev) > > { > > + if

[RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

Koenig Cc: Alex Deucher Cc: David Zhou Cc: Huang Rui Cc: Junwei Zhang Cc: Michel Daenzer Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Will Deacon Reported-by: Carsten Haitzler Signed-off-by: Ard

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Mon, 21 Jan 2019 at 17:35, Christoph Hellwig wrote: > > On Mon, Jan 21, 2019 at 05:30:00PM +0100, Ard Biesheuvel wrote: > > > Until that happens we should just change the driver ifdefs to default > > > the hacks to off and only enable them on setups where we 10

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Mon, 21 Jan 2019 at 16:59, Christoph Hellwig wrote: > > On Mon, Jan 21, 2019 at 04:33:27PM +0100, Ard Biesheuvel wrote: > > On Mon, 21 Jan 2019 at 16:07, Christoph Hellwig wrote: > > > > > > > +#include > > > > > > This header is not fo

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Mon, 21 Jan 2019 at 20:04, Michel Dänzer wrote: > > On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote: > > On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote: > >> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote: > >>> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wro

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Mon, 21 Jan 2019 at 20:04, Michel Dänzer wrote: > > On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote: > > On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote: > >> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote: > >>> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wro

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote: > > On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote: > > On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote: > >> > >> On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote: > >>> On Mon, 21 Jan 2019

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote: > > On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote: > > On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote: > >> > >> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote: > >>> On Mon, 21 Jan 2019 at 18:55, Mich

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Tue, 22 Jan 2019 at 21:56, Alex Deucher wrote: > > On Tue, Jan 22, 2019 at 4:19 AM Ard Biesheuvel > wrote: > > > > On Mon, 21 Jan 2019 at 20:04, Michel Dänzer wrote: > > > > > > On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote: > > > >

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

On Thu, 10 Jan 2019 at 10:34, Michel Dänzer wrote: > > On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote: > > ARM systems do not permit the use of anything other than cached > > mappings for system memory, since that memory may be mapped in the > > linear region as well, a

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

On Mon, 14 Jan 2019 at 12:38, Koenig, Christian wrote: > > Am 14.01.19 um 11:53 schrieb Ard Biesheuvel: > > On Thu, 10 Jan 2019 at 10:34, Michel Dänzer wrote: > >> On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote: > >>> ARM systems do not permit the use of anything

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

On Wed, 16 Jan 2019 at 08:36, Koenig, Christian wrote: > > Am 16.01.19 um 01:33 schrieb Benjamin Herrenschmidt: > > On Tue, 2019-01-15 at 22:31 +1100, Michael Ellerman wrote: > As far as I know Power doesn't really supports un-cached memory at all, > except for a very very old and odd

[RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

Cc: Junwei Zhang Cc: David Airlie Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel --- drivers/gpu/drm/ttm/ttm_bo_util.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index 046a6dda690a..0c1eef5f7ae3

Re: [PATCH] drm: enable uncached DMA optimization for ARM and arm64

On Fri, 25 Jan 2019 at 12:30, Christian König wrote: > > Am 25.01.19 um 09:43 schrieb Ard Biesheuvel: > > On Thu, 24 Jan 2019 at 15:01, Alex Deucher wrote: > >> On Thu, Jan 24, 2019 at 9:00 AM Ard Biesheuvel > >> wrote: > >>> On Thu, 24 Jan 201

Re: [PATCH] drm: enable uncached DMA optimization for ARM and arm64

On Wed, 6 Feb 2019 at 19:38, Christian König wrote: > > Am 06.02.19 um 18:23 schrieb Ard Biesheuvel: > > On Fri, 25 Jan 2019 at 11:35, Ard Biesheuvel > > wrote: > >> On Fri, 25 Jan 2019 at 12:30, Christian König > >> wrote: > >>> Am 25.01.19 um

Re: [PATCH] drm: enable uncached DMA optimization for ARM and arm64

On Thu, 7 Feb 2019 at 16:33, Alex Deucher wrote: > > On Thu, Feb 7, 2019 at 10:20 AM Ard Biesheuvel > wrote: > > > > On Wed, 6 Feb 2019 at 19:38, Christian König > > wrote: > > > > > > Am 06.02.19 um 18:23 schrieb Ard Biesheuvel: > &g

Re: [PATCH] drm: enable uncached DMA optimization for ARM and arm64

On Fri, 25 Jan 2019 at 11:35, Ard Biesheuvel wrote: > > On Fri, 25 Jan 2019 at 12:30, Christian König > wrote: > > > > Am 25.01.19 um 09:43 schrieb Ard Biesheuvel: > > > On Thu, 24 Jan 2019 at 15:01, Alex Deucher wrote: > > >> On Thu, Jan 24, 20

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Thu, 24 Jan 2019 at 12:23, Koenig, Christian wrote: > > Am 24.01.19 um 10:59 schrieb Ard Biesheuvel: > > [SNIP] > > This is *exactly* my point the whole time. > > > > The current code has > > > > static inline bool drm_arch_can_wc_memory(void) >

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Thu, 24 Jan 2019 at 10:25, Koenig, Christian wrote: > > Am 24.01.19 um 10:13 schrieb Christoph Hellwig: > > On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote: > >> But my concern is that it seems likely that non-cache coherent > >> implementations ar

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Thu, 24 Jan 2019 at 14:54, Alex Deucher wrote: > > On Thu, Jan 24, 2019 at 6:45 AM Ard Biesheuvel > wrote: > > > > On Thu, 24 Jan 2019 at 12:37, Koenig, Christian > > wrote: > > > > > > Am 24.01.19 um 12:26 schrieb Ard Biesheuvel: > >

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Thu, 24 Jan 2019 at 10:31, Michel Dänzer wrote: > > On 2019-01-23 5:52 p.m., Ard Biesheuvel wrote: > > On Wed, 23 Jan 2019 at 17:44, Christoph Hellwig wrote: > >> > >> I think we just want a driver-local check for those combinations > >> where we know

Re: [PATCH] drm: enable uncached DMA optimization for ARM and arm64

On Thu, 24 Jan 2019 at 15:01, Alex Deucher wrote: > > On Thu, Jan 24, 2019 at 9:00 AM Ard Biesheuvel > wrote: > > > > On Thu, 24 Jan 2019 at 13:31, Koenig, Christian > > wrote: > > > > > > Am 24.01.19 um 13:06 schrieb Ard Biesheuvel: > > >

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Thu, 24 Jan 2019 at 10:45, Koenig, Christian wrote: > > Am 24.01.19 um 10:28 schrieb Ard Biesheuvel: > > On Thu, 24 Jan 2019 at 10:25, Koenig, Christian > > wrote: > >> Am 24.01.19 um 10:13 schrieb Christoph Hellwig: > >>> On Wed, Jan 23, 2019 at

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Thu, 24 Jan 2019 at 12:37, Koenig, Christian wrote: > > Am 24.01.19 um 12:26 schrieb Ard Biesheuvel: > > On Thu, 24 Jan 2019 at 12:23, Koenig, Christian > > wrote: > >> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel: > >>> [SNIP] > >

[PATCH] drm: enable uncached DMA optimization for ARM and arm64

Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel --- include/drm/drm_cache.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h index bfe1639df02d..97fc498dc767 100644 --- a/include/drm/drm_cache.h +++ b/include/drm

Re: [PATCH] drm: enable uncached DMA optimization for ARM and arm64

On Thu, 24 Jan 2019 at 13:31, Koenig, Christian wrote: > > Am 24.01.19 um 13:06 schrieb Ard Biesheuvel: > > The DRM driver stack is designed to work with cache coherent devices > > only, but permits an optimization to be enabled in some cases, where > > for some buffers,

Re: [PATCH 1/3] treewide: Lift switch variables out of switches

On Wed, 23 Jan 2019 at 13:09, Jann Horn wrote: > > On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote: > > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote: > > > Variables declared in a switch statement before any case statements > > > cannot be initialized, so move all instances out of the

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Wed, 23 Jan 2019 at 08:15, Christoph Hellwig wrote: > > On Tue, Jan 22, 2019 at 10:07:07PM +0100, Ard Biesheuvel wrote: > > Yes, so much was clear. And the reason this breaks on some arm64 > > systems is because > > a) non-snooped PCIe TLP attributes may be ignored, an

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Wed, 23 Jan 2019 at 17:44, Christoph Hellwig wrote: > > I think we just want a driver-local check for those combinations > where we know this hack actually works, which really just seems > to be x86-64 with PAT. Something like the patch below, but maybe with > even more strong warnings to not

Re: [PATCH] efifb: BGRT: Add check for new BGRT status field rotation bits

On Mon, 10 Jun 2019 at 17:12, Ard Biesheuvel wrote: > > On Wed, 29 May 2019 at 17:46, Hans de Goede wrote: > > > > Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer > > reserved. These bits are now used to indicate if the image needs to be

Re: [PATCH] efifb: BGRT: Add check for new BGRT status field rotation bits

On Tue, 11 Jun 2019 at 16:24, Hans de Goede wrote: > > Hi, > > On 11-06-19 16:04, Ard Biesheuvel wrote: > > On Mon, 10 Jun 2019 at 17:12, Ard Biesheuvel > > wrote: > >> > >> On Wed, 29 May 2019 at 17:46, Hans de Goede wrote: > >>> > &

Re: [PATCH] efifb: BGRT: Add check for new BGRT status field rotation bits

rotating the image before copying it to > the screen. > > This commit adds a check for these new bits and if they are set leaves the > fb contents as is instead of trying to use the un-rotated BGRT image. > > Signed-off-by: Hans de Goede Acked-by: Ard Biesheuvel > --- > drive

Re: [PATCH 2/4] efi/libstub: detect panel-id

On Wed, 3 Jul 2019 at 19:41, Rob Clark wrote: > > On Wed, Jul 3, 2019 at 9:33 AM Leif Lindholm wrote: > > > > On Tue, Jul 02, 2019 at 03:48:48PM -0700, Rob Clark wrote: > > > > > There is one kernel, and there > > > > > are N distro's, so debugging a users "I don't get a screen at boot" > > > >

Re: [PATCH 2/4] efi/libstub: detect panel-id

On Sun, 30 Jun 2019 at 22:36, Rob Clark wrote: > > From: Rob Clark > > On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided > to communicate some information about the display. Crutially it has the > panel-id, so the appropriate panel driver can be selected. Read this > out

Re: [PATCH 2/4] efi/libstub: detect panel-id

On Tue, 2 Jul 2019 at 23:02, Rob Clark wrote: > > On Tue, Jul 2, 2019 at 1:35 PM Ard Biesheuvel > wrote: > > > > On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel > > wrote: > > > > > > On Sun, 30 Jun 2019 at 22:36, Rob Clark wrote: > > > &g

Re: [PATCH 2/4] efi/libstub: detect panel-id

On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel wrote: > > On Sun, 30 Jun 2019 at 22:36, Rob Clark wrote: > > > > From: Rob Clark > > > > On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided > > to communicate some information about the display

Re: [patch 00/13] preempt: Make preempt count unconditional

On Tue, 15 Sep 2020 at 01:43, Linus Torvalds wrote: > > On Mon, Sep 14, 2020 at 3:24 PM Linus Torvalds > wrote: > > > > Ard and Herbert added to participants: see > > chacha20poly1305_crypt_sg_inplace(), which does > > > > flags = SG_MITER_TO_SG; > > if (!preemptible()) > >

Re: [patch 00/13] preempt: Make preempt count unconditional

On Wed, 16 Sep 2020 at 21:32, Linus Torvalds wrote: > > But something like a driver list walking thing should not be doing > different things behind peoples back depending on whether they hold > spinlocks or not. It should either just work regardless, or there > should be a flag (or special

Re: [PATCH] efi: avoid error message when booting under Xen

On Fri, 10 Jul 2020 at 16:38, Jürgen Groß wrote: > > On 10.07.20 15:27, Ard Biesheuvel wrote: > > On Fri, 10 Jul 2020 at 13:17, Bartlomiej Zolnierkiewicz > > wrote: > >> > >> > >> [ added EFI Maintainer & ML to Cc: ] > >>

Re: [PATCH] efi: avoid error message when booting under Xen

On Fri, 10 Jul 2020 at 13:17, Bartlomiej Zolnierkiewicz wrote: > > > [ added EFI Maintainer & ML to Cc: ] > > Hi, > > On 7/9/20 11:17 AM, Jürgen Groß wrote: > > On 28.06.20 10:50, Jürgen Groß wrote: > >> Ping? > >> > >> On 10.06.20 16:10, Juergen Gross wrote: > >>> efifb_probe() will issue an

Re: [PATCH v2] efi: avoid error message when booting under Xen

ixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when > mapping the FB") > Signed-off-by: Juergen Gross Acked-by: Ard Biesheuvel > --- > drivers/video/fbdev/efifb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel wrote: > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher wrote: > > > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel wrote: > > > > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa. > > &g

[PATCH] drm/amd/display: Revert "add DCN support for aarch64"

Martin Cc: Rob Herring Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Daniel Kolesa Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Ard Biesheuvel --- drivers/gpu/drm/amd/display/Kconfig

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

On Wed, 16 Dec 2020 at 19:00, Alex Deucher wrote: > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel wrote: > > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa. > > > > Simply disabling -mgeneral-regs-only left and right is risky, given that > &

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

On Tue, 5 Jan 2021 at 17:23, Alex Deucher wrote: > > On Tue, Jan 5, 2021 at 8:05 AM Will Deacon wrote: > > > > On Mon, Jan 04, 2021 at 11:27:24AM -0500, Alex Deucher wrote: > > > On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel wrote: > > > > > > >

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

On Mon, 4 Jan 2021 at 17:27, Alex Deucher wrote: > > On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel wrote: > > > > On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel wrote: > > > > > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher wrote: > > > > > &g

Re: [PATCH 0/2] allow the sysfb support to be used in non-x86 arches

Hello Javier, On Fri, 21 May 2021 at 21:29, Javier Martinez Canillas wrote: > > The x86 architecture platform has a Generic System Framebuffers (sysfb) > support, that register a system frambuffer platform devices. It either > registers a "simple-framebuffer" for the simple{fb,drm} drivers or

Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms

On Mon, 19 Jul 2021 at 04:59, Dave Airlie wrote: > > On Thu, 15 Jul 2021 at 18:11, Thomas Zimmermann wrote: > > > > Hi > > > > Am 13.07.21 um 18:59 schrieb Javier Martinez Canillas: > > > On 6/25/21 3:09 PM, Javier Martinez Canillas wrote: > > >> The simplefb and simpledrm drivers match against

Re: [PATCH] efi: sysfb_efi: fix build when EFI is not set

ion of > ‘sysfb_apply_efi_quirks’ was here > static inline void sysfb_apply_efi_quirks(struct platform_device *pd) > ^~~~~~ > > Signed-off-by: Randy Dunlap > Cc: Ard Biesheuvel > Cc: linux-...@vger.kernel.org > Cc: dri-devel@lists.fre

Re: [PATCH] efi: sysfb_efi: fix build when EFI is not set

On Wed, 28 Jul 2021 at 10:39, Geert Uytterhoeven wrote: > > Hi Randy, > > On Tue, Jul 27, 2021 at 7:06 AM Randy Dunlap wrote: > > When # CONFIG_EFI is not set, there are 2 definitions of > > sysfb_apply_efi_quirks(). The stub from sysfb.h should be used > > and the __init function from

Re: [next] arm: panel-edp.c:(.text+0xb74): undefined reference to `drm_panel_dp_aux_backlight'

On Wed, 2 Feb 2022 at 10:08, Thomas Zimmermann wrote: > > Hi > > Am 02.02.22 um 10:02 schrieb Naresh Kamboju: > > Following builds failed on Linux next 20220202 arm architecture. > >- arm-gcc-10-omap2plus_defconfig > >- arm-clang-nightly-shmobile_defconfig > >-

Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID block count and size helpers")

On Thu, 2 Jun 2022 at 14:12, Arnd Bergmann wrote: > > On Thu, Jun 2, 2022 at 1:21 PM Tetsuo Handa > wrote: > > On 2022/06/02 16:38, Arnd Bergmann wrote: > > >> But let's cc the tomoyo and chelsio people. > > > > > > I think both of them work because the structures are always > > > embedded

Re: [PATCH v2 0/3] Add generic framebuffer support to EFI earlycon driver

On Sat, 6 Aug 2022 at 18:34, Markuss Broks wrote: > > Make the EFI earlycon driver be suitable for any linear framebuffers. > This should be helpful for early porting of boards with no other means of > output, like smartphones/tablets. There seems to be an issue with > early_ioremap > function

Re: [PATCH v3 0/3] Add generic framebuffer support to EFI earlycon driver

(cc Andy) On Wed, 21 Dec 2022 at 11:54, Markuss Broks wrote: > > Make the EFI earlycon driver be suitable for any linear framebuffers. > This should be helpful for early porting of boards with no other means of > output, like smartphones/tablets. There seems to be an issue with > early_ioremap

  1   2   >