[RFC 4/7] dt-bindings: gpu: mali-utgard: Add Realtek RTD1195
Define a compatible string for Realtek RTD1195 SoC family. Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml index afde81be3c29..b01b95cf5cdf 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml @@ -26,6 +26,7 @@ properties: - allwinner,sun7i-a20-mali - allwinner,sun8i-h3-mali - allwinner,sun50i-a64-mali + - realtek,rtd1195-mali - rockchip,rk3036-mali - rockchip,rk3066-mali - rockchip,rk3188-mali -- 2.16.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 6/7] dt-bindings: gpu: mali-utgard: Add Realtek RTD1395
Define compatible strings for Mali-470 and Realtek RTD1395 SoC family. Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml index b01b95cf5cdf..62d5d3603c5d 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml @@ -44,6 +44,10 @@ properties: - hisilicon,hi6220-mali - rockchip,rk3328-mali - const: arm,mali-450 + - items: + - enum: + - realtek,rtd1395-mali + - const: arm,mali-470 # "arm,mali-300" -- 2.16.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] gpu: host1x: Remove dev_err() on platform_get_irq() failure
platform_get_irq() will call dev_err() itself on failure,
so there is no need for the driver to also do this.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/gpu/host1x/dev.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index a738ea5..388bcc2 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -339,10 +339,8 @@ static int host1x_probe(struct platform_device *pdev)
}
syncpt_irq = platform_get_irq(pdev, 0);
- if (syncpt_irq < 0) {
- dev_err(&pdev->dev, "failed to get IRQ: %d\n", syncpt_irq);
+ if (syncpt_irq < 0)
return syncpt_irq;
- }
mutex_init(&host->devices_lock);
INIT_LIST_HEAD(&host->devices);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/18] goldish_pipe: rename local pin_user_pages() routine
1. Avoid naming conflicts: rename local static function from
"pin_user_pages()" to "pin_goldfish_pages()".
An upcoming patch will introduce a global pin_user_pages()
function.
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
drivers/platform/goldfish/goldfish_pipe.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index cef0133aa47a..7ed2a21a0bac 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -257,12 +257,12 @@ static int goldfish_pipe_error_convert(int status)
}
}
-static int pin_user_pages(unsigned long first_page,
- unsigned long last_page,
- unsigned int last_page_size,
- int is_write,
- struct page *pages[MAX_BUFFERS_PER_COMMAND],
- unsigned int *iter_last_page_size)
+static int pin_goldfish_pages(unsigned long first_page,
+ unsigned long last_page,
+ unsigned int last_page_size,
+ int is_write,
+ struct page *pages[MAX_BUFFERS_PER_COMMAND],
+ unsigned int *iter_last_page_size)
{
int ret;
int requested_pages = ((last_page - first_page) >> PAGE_SHIFT) + 1;
@@ -354,9 +354,9 @@ static int transfer_max_buffers(struct goldfish_pipe *pipe,
if (mutex_lock_interruptible(&pipe->lock))
return -ERESTARTSYS;
- pages_count = pin_user_pages(first_page, last_page,
-last_page_size, is_write,
-pipe->pages, &iter_last_page_size);
+ pages_count = pin_goldfish_pages(first_page, last_page,
+last_page_size, is_write,
+pipe->pages, &iter_last_page_size);
if (pages_count < 0) {
mutex_unlock(&pipe->lock);
return pages_count;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/7] dt-bindings: gpu: arm-bifrost: Add Realtek RTD1619
$subject: "mali-bifrost" obviously. Fixed on my branch. Am 04.11.19 um 02:39 schrieb Andreas Färber: > Define a compatible string for Realtek RTD1619 SoC family. > > Signed-off-by: Andreas Färber > --- > Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 1 + > 1 file changed, 1 insertion(+) [snip] Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] Individuals interested in VESA memberships?
On Sat, 2 Nov 2019 at 07:06, Lyude Paul wrote: > Hi! Recently I've been working with the rest of the X.Org board to try to > get > X.org access to VESA memberships so that contributors that don't have an > employer who is able/willing to join VESA can potentially get access to the > various benefits of a VESA membership, such as access to DisplayPort > specifications. Since I need to gather a list of interested X.org members, > I'd > like to know who all might be interested in a membership like this. There > are > no costs involved, as the VESA membership we're looking at in particular > comes > at no cost to us since we're a non-profit. > > The current plan is to extend VESA membership to X.Org members who > specifically request it. If you think you'd be at all interested in this, > or > know any projects or contributors who would be, please feel free to > respond to > this message and let me know! > Hi Lyude, This is super helpful, thank you for advancing this with X.org <> VESA. I would be interested, as recently released nvidia register documentation on crc functionality in the display block removes another roadblock for nouveau testing support in igt-gpu-tools. My time to work on nouveau independently remains limited, so if there's a limit on the number of VESA memberships available -- I'd rather not be at the top of that list over other more active open source contributors. Regards, Rhys > -- > Cheers, > Lyude Paul > > ___ > Nouveau mailing list > nouv...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] dt-bindings: gpu: mali-midgard: Tidy up conversion to YAML
Instead of grouping alphabetically by third-party vendor, leading to
one-element enums, sort by Mali model number, as done for Utgard.
This already allows us to de-duplicate two "arm,mali-t760" sections and
will make it easier to add new vendor compatibles.
Fixes: 553cedf60056 ("dt-bindings: Convert Arm Mali Midgard GPU to DT schema")
Fixes: 1be5b54d26ae ("dt-bindings: gpu: mali-midgard: Add samsung exynos5250
compatible")
Cc: Rob Herring
Signed-off-by: Andreas Färber
---
.../devicetree/bindings/gpu/arm,mali-midgard.yaml | 32 ++
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
index 8e00a21b36f5..ffdb24c4ab6a 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
@@ -16,36 +16,32 @@ properties:
oneOf:
- items:
- enum:
- - allwinner,sun50i-h6-mali
- - const: arm,mali-t720
- - items:
- - enum:
- - amlogic,meson-gxm-mali
- - const: arm,mali-t820
+ - samsung,exynos5250-mali
+ - const: arm,mali-t604
- items:
- enum:
- arm,juno-mali
- const: arm,mali-t624
+ # "arm,mali-t628"
- items:
- enum:
- - rockchip,rk3288-mali
- - const: arm,mali-t760
+ - allwinner,sun50i-h6-mali
+ - const: arm,mali-t720
- items:
- enum:
- - rockchip,rk3399-mali
- - const: arm,mali-t860
+ - rockchip,rk3288-mali
+ - samsung,exynos5433-mali
+ - const: arm,mali-t760
- items:
- enum:
- - samsung,exynos5250-mali
- - const: arm,mali-t604
+ - amlogic,meson-gxm-mali
+ - const: arm,mali-t820
+ # "arm,mali-t830"
- items:
- enum:
- - samsung,exynos5433-mali
- - const: arm,mali-t760
-
- # "arm,mali-t628"
- # "arm,mali-t830"
- # "arm,mali-t880"
+ - rockchip,rk3399-mali
+ - const: arm,mali-t860
+ # "arm,mali-t880"
reg:
maxItems: 1
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/7] dt-bindings: gpu: arm-bifrost: Add Realtek RTD1619
Define a compatible string for Realtek RTD1619 SoC family. Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index e50a0cc78fff..0c426e371e71 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -17,6 +17,7 @@ properties: items: - enum: - amlogic,meson-g12a-mali + - realtek,rtd1619-mali - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable reg: -- 2.16.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.
From: Wei Hu Sent: Tuesday, October 22, 2019 4:11 AM
>
> On Hyper-V, Generation 1 VMs can directly use VM's physical memory for
> their framebuffers. This can improve the efficiency of framebuffer and
> overall performence for VM. The physical memory assigned to framebuffer
> must be contiguous. We use CMA allocator to get contiguouse physicial
> memory when the framebuffer size is greater than 4MB. For size under
> 4MB, we use alloc_pages to achieve this.
>
> To enable framebuffer memory allocation from CMA, supply a kernel
> parameter to give enough space to CMA allocator at boot time. For
> example:
> cma=130m
> This gives 130MB memory to CAM allocator that can be allocated to
> framebuffer. If this fails, we fall back to the old way of using
> mmio for framebuffer.
>
> Signed-off-by: Wei Hu
> ---
[snip]
> +/*
> + * Allocate enough contiguous physical memory.
> + * Return physical address if succeeded or -1 if failed.
> + */
> +static unsigned long hvfb_get_phymem(unsigned int request_size)
> +{
> + struct page *page = NULL;
> + unsigned int request_pages;
> + unsigned long paddr = 0;
Using 'unsigned long' for physical addresses is problematic on 32-bit
systems with Physical Address Extension (PAE) enabled. Linux has
phys_addr_t that handles 32-bit PAE correctly and that probably
should be used here. This whole driver needs to be carefully
checked for the correct type for physical addresses.
> + unsigned int order = get_order(request_size);
> +
> + if (request_size == 0)
> + return -1;
> +
> + /* Try call alloc_pages if the size is less than 2^MAX_ORDER */
> + if (order < MAX_ORDER) {
> + page = alloc_pages(GFP_KERNEL | __GFP_ZERO, order);
> + if (!page)
> + return -1;
> +
> + request_pages = (1 << order);
> + goto get_phymem1;
> + }
> +
> + /* Allocate from CMA */
> + // request_pages = (request_size >> PAGE_SHIFT) + 1;
> + request_pages = (round_up(request_size, PAGE_SIZE) >> PAGE_SHIFT);
> + page = dma_alloc_from_contiguous(NULL, request_pages, 0, false);
> +
> + if (page == NULL)
> + return -1;
> +
> +get_phymem1:
> + paddr = (page_to_pfn(page) << PAGE_SHIFT);
> +
> + pr_info("Allocated %d pages starts at physical addr 0x%lx\n",
> + request_pages, paddr);
> +
> + return paddr;
> +}
> +
> +/* Release contiguous physical memory */
> +static void hvfb_release_phymem(unsigned long paddr, unsigned int size)
Same issue here with 'unsigned long paddr'.
> +{
> + unsigned int order = get_order(size);
> +
> + if (order < MAX_ORDER)
> + __free_pages(pfn_to_page(paddr >> PAGE_SHIFT), order);
> + else
> + dma_release_from_contiguous(NULL,
> + pfn_to_page(paddr >> PAGE_SHIFT),
> + (round_up(size, PAGE_SIZE) >>
> + PAGE_SHIFT));
> + // (size >> PAGE_SHIFT) + 1);
> +}
> +
>
> /* Get framebuffer memory from Hyper-V video pci space */
> static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info)
> @@ -947,8 +1017,58 @@ static int hvfb_getmem(struct hv_device *hdev, struct
> fb_info
> *info)
> void __iomem *fb_virt;
> int gen2vm = efi_enabled(EFI_BOOT);
> resource_size_t pot_start, pot_end;
> + unsigned long paddr;
Same issue with 'unsigned long'.
> int ret;
>
> + if (!gen2vm) {
> + pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
> + PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
> + if (!pdev) {
> + pr_err("Unable to find PCI Hyper-V video\n");
> + return -ENODEV;
> + }
> + }
> +
> + info->apertures = alloc_apertures(1);
> + if (!info->apertures)
> + goto err1;
> +
> + if (gen2vm) {
> + info->apertures->ranges[0].base = screen_info.lfb_base;
> + info->apertures->ranges[0].size = screen_info.lfb_size;
> + } else {
> + info->apertures->ranges[0].base = pci_resource_start(pdev, 0);
> + info->apertures->ranges[0].size = pci_resource_len(pdev, 0);
> + }
> +
> + /*
> + * For Gen 1 VM, we can directly use the contiguous memory
> + * from VM. If we success, deferred IO happens directly
> + * on this allocated framebuffer memory, avoiding extra
> + * memory copy.
> + */
> + if (!gen2vm) {
> + paddr = hvfb_get_phymem(screen_fb_size);
> + if (paddr != (unsigned long) -1) {
phys_addr_t
> + par->mmio_pp = paddr;
I'm not really sure what to do about the above, because mmio_pp is
declared as 'unsigned long' when it really should be phys_addr_t.
But maybe a MMIO address will always be less than 4 Gb and therefore
will fit in 32 bits?
> + par->mmio_
[PATCH v2 07/18] infiniband: set FOLL_PIN, FOLL_LONGTERM via pin_longterm_pages*()
Convert infiniband to use the new wrapper calls, and stop
explicitly setting FOLL_LONGTERM at the call sites.
The new pin_longterm_*() calls replace get_user_pages*()
calls, and set both FOLL_LONGTERM and a new FOLL_PIN
flag. The FOLL_PIN flag requires that the caller must
return the pages via put_user_page*() calls, but
infiniband was already doing that as part of an earlier
commit.
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
drivers/infiniband/core/umem.c | 5 ++---
drivers/infiniband/core/umem_odp.c | 10 +-
drivers/infiniband/hw/hfi1/user_pages.c | 4 ++--
drivers/infiniband/hw/mthca/mthca_memfree.c | 3 +--
drivers/infiniband/hw/qib/qib_user_pages.c | 8
drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
drivers/infiniband/hw/usnic/usnic_uiom.c| 9 -
drivers/infiniband/sw/siw/siw_mem.c | 5 ++---
8 files changed, 21 insertions(+), 25 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 24244a2f68cc..c5a78d3e674b 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -272,11 +272,10 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata,
unsigned long addr,
while (npages) {
down_read(&mm->mmap_sem);
- ret = get_user_pages(cur_base,
+ ret = pin_longterm_pages(cur_base,
min_t(unsigned long, npages,
PAGE_SIZE / sizeof (struct page *)),
-gup_flags | FOLL_LONGTERM,
-page_list, NULL);
+gup_flags, page_list, NULL);
if (ret < 0) {
up_read(&mm->mmap_sem);
goto umem_release;
diff --git a/drivers/infiniband/core/umem_odp.c
b/drivers/infiniband/core/umem_odp.c
index 163ff7ba92b7..a38b67b83db5 100644
--- a/drivers/infiniband/core/umem_odp.c
+++ b/drivers/infiniband/core/umem_odp.c
@@ -534,7 +534,7 @@ static int ib_umem_odp_map_dma_single_page(
} else if (umem_odp->page_list[page_index] == page) {
umem_odp->dma_list[page_index] |= access_mask;
} else {
- pr_err("error: got different pages in IB device and from
get_user_pages. IB device page: %p, gup page: %p\n",
+ pr_err("error: got different pages in IB device and from
pin_longterm_pages. IB device page: %p, gup page: %p\n",
umem_odp->page_list[page_index], page);
/* Better remove the mapping now, to prevent any further
* damage. */
@@ -639,11 +639,11 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp
*umem_odp, u64 user_virt,
/*
* Note: this might result in redundent page getting. We can
* avoid this by checking dma_list to be 0 before calling
-* get_user_pages. However, this make the code much more
-* complex (and doesn't gain us much performance in most use
-* cases).
+* pin_longterm_pages. However, this makes the code much
+* more complex (and doesn't gain us much performance in most
+* use cases).
*/
- npages = get_user_pages_remote(owning_process, owning_mm,
+ npages = pin_longterm_pages_remote(owning_process, owning_mm,
user_virt, gup_num_pages,
flags, local_page_list, NULL, NULL);
up_read(&owning_mm->mmap_sem);
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c
b/drivers/infiniband/hw/hfi1/user_pages.c
index 469acb961fbd..9b55b0a73e29 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -104,9 +104,9 @@ int hfi1_acquire_user_pages(struct mm_struct *mm, unsigned
long vaddr, size_t np
bool writable, struct page **pages)
{
int ret;
- unsigned int gup_flags = FOLL_LONGTERM | (writable ? FOLL_WRITE : 0);
+ unsigned int gup_flags = (writable ? FOLL_WRITE : 0);
- ret = get_user_pages_fast(vaddr, npages, gup_flags, pages);
+ ret = pin_longterm_pages_fast(vaddr, npages, gup_flags, pages);
if (ret < 0)
return ret;
diff --git a/drivers/infiniband/hw/mthca/mthca_memfree.c
b/drivers/infiniband/hw/mthca/mthca_memfree.c
index edccfd6e178f..beec7e4b8a96 100644
--- a/drivers/infiniband/hw/mthca/mthca_memfree.c
+++ b/drivers/infiniband/hw/mthca/mthca_memfree.c
@@ -472,8 +472,7 @@ int mthca_map_user_db(struct mthca_dev *dev, struct
mthca_uar *uar,
goto out;
}
- ret = get_user_pages_fast(uaddr & PAGE_MASK, 1,
- FOLL_WRITE | FOLL_LONGTERM, pages);
+ ret = pin_longterm_pages_fast(uaddr & PAGE_MASK, 1, FOLL_WRITE, pages);
RE: [PATCH] video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.
> From: linux-hyperv-ow...@vger.kernel.org
> On Behalf Of Wei Hu
> Sent: Tuesday, October 22, 2019 4:11 AM
> ...
> + /* Allocate from CMA */
> + // request_pages = (request_size >> PAGE_SHIFT) + 1;
"//" seems rare in Linux kernel code.
IMO "/* */" is more common.
> + pr_info("Unable to allocate enough contiguous physical
> memory
> on Gen 1 VM. Use MMIO instead.\n");
The line exceeds 80 chars.
> @@ -1060,6 +1168,7 @@ static int hvfb_probe(struct hv_device *hdev,
> par = info->par;
> par->info = info;
> par->fb_ready = false;
> + par->need_docopy = false;
Maybe it's better if we set the default value to true? This way we can save
the " par->need_docopy = true;" in hvfb_getmem().
Thanks,
-- Dexuan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] dt-bindings: gpu: mali-midgard: Add Realtek RTD1295
Define a compatible string for Realtek RTD1295 SoC family. Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml index ffdb24c4ab6a..f7e84d175dd2 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml @@ -35,6 +35,7 @@ properties: - items: - enum: - amlogic,meson-gxm-mali + - realtek,rtd1295-mali - const: arm,mali-t820 # "arm,mali-t830" - items: -- 2.16.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] fbdev: c2p: Fix link failure on non-inlining
Hi Bartlomiej, Andrew,
On Fri, Sep 27, 2019 at 11:47 AM Geert Uytterhoeven
wrote:
> When the compiler decides not to inline the Chunky-to-Planar core
> functions, the build fails with:
>
> c2p_planar.c:(.text+0xd6): undefined reference to `c2p_unsupported'
> c2p_planar.c:(.text+0x1dc): undefined reference to `c2p_unsupported'
> c2p_iplan2.c:(.text+0xc4): undefined reference to `c2p_unsupported'
> c2p_iplan2.c:(.text+0x150): undefined reference to `c2p_unsupported'
>
> Fix this by marking the functions __always_inline.
>
> While this could be triggered before by manually enabling both
> CONFIG_OPTIMIZE_INLINING and CONFIG_CC_OPTIMIZE_FOR_SIZE, it was exposed
> in the m68k defconfig by commit ac7c3e4ff401b304 ("compiler: enable
> CONFIG_OPTIMIZE_INLINING forcibly").
>
> Fixes: 9012d011660ea5cf ("compiler: allow all arches to enable
> CONFIG_OPTIMIZE_INLINING")
> Reported-by: nore...@ellerman.id.au
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Masahiro Yamada
> ---
> This is a fix for v5.4-rc1.
Can you please apply this for v5.4?
This is one of the 4 remaining build regressions, compared to v5.3.
Thanks!
> v2:
> - Add Reviewed-by,
> - Fix Fixes,
> - Add more explanation.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2] drm/sched: Fix passing zero to 'PTR_ERR' warning
Reviewed-by: Emily Deng
>-Original Message-
>From: amd-gfx On Behalf Of
>Andrey Grodzovsky
>Sent: Wednesday, October 30, 2019 2:08 AM
>To: dan.carpen...@oracle.com
>Cc: Grodzovsky, Andrey ; amd-
>g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Subject: [PATCH v2] drm/sched: Fix passing zero to 'PTR_ERR' warning
>
>Fix a static code checker warning.
>
>v2: Drop PTR_ERR_OR_ZERO.
>
>Signed-off-by: Andrey Grodzovsky
>---
> drivers/gpu/drm/scheduler/sched_main.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>b/drivers/gpu/drm/scheduler/sched_main.c
>index f39b97e..dba4390 100644
>--- a/drivers/gpu/drm/scheduler/sched_main.c
>+++ b/drivers/gpu/drm/scheduler/sched_main.c
>@@ -496,8 +496,10 @@ void drm_sched_resubmit_jobs(struct
>drm_gpu_scheduler *sched)
> fence = sched->ops->run_job(s_job);
>
> if (IS_ERR_OR_NULL(fence)) {
>+ if (IS_ERR(fence))
>+ dma_fence_set_error(&s_fence->finished,
>PTR_ERR(fence));
>+
> s_job->s_fence->parent = NULL;
>- dma_fence_set_error(&s_fence->finished,
>PTR_ERR(fence));
> } else {
> s_job->s_fence->parent = fence;
> }
>@@ -741,8 +743,9 @@ static int drm_sched_main(void *param)
> r);
> dma_fence_put(fence);
> } else {
>+ if (IS_ERR(fence))
>+ dma_fence_set_error(&s_fence->finished,
>PTR_ERR(fence));
>
>- dma_fence_set_error(&s_fence->finished,
>PTR_ERR(fence));
> drm_sched_process_job(NULL, &sched_job->cb);
> }
>
>--
>2.7.4
>
>___
>amd-gfx mailing list
>amd-...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2 v5] drm/panel: Add generic DSI panel YAML bindings
This adds a starting point for processing and defining generic bindings used by DSI panels. We just define one single bool property to force the panel into video mode for now. Cc: devicet...@vger.kernel.org Suggested-by: Rob Herring Signed-off-by: Linus Walleij --- ChangeLog v4->v5: - Drop the example. - I still have a vert annoying error message in the Sony panel bindings that uses this schema: sony,acx424akp.example.dt.yaml: panel@0: $nodename:0: 'panel@0' does not match '^dsi-controller(@.*)?$' As this is modeled very closely to Documentation/devicetree/bindings/net/mdio.yaml and that one doesn't emit this type of warning for its ethernet-phy@0 etc I am pretty much clueless and just can't see what the problem is. - If I can't figure this out the only viable next step is to drop the ambition to create yaml bindings simply because I'm unable to do it, and go back to traditional text bindings :( ChangeLog v3->v4: - Rename into display/dsi-controller.yaml - Require a virtual channel number for the DSI panel, as DSI have this 2-bit virtual address field. - Bring in some but not all properties from the existing MIPI DSI bindings. This schema can be used with simpler panels but not complex panels with multiple virtual channels for the moment. Let's handle it when we get there. - Add an example. ChangeLog v2->v3: - Make a more complete DSI panel binding including the controller and its address-cells and size-cells and a pattern for the panel nodes. The panel is one per DSI master, the reg property is compulsory but should always be 0 (as far as I can tell) as only one panel can be connected. The bus doesn't really have any addresses for the panel, the address/reg notation seems to be cargo-culted from the port graphs and is not necessary to parse some device trees, it is used to tell whether the node is a panel or not rather than any addressing. - I have no idea how many displays you can daisychain on a single DSI master, I just guess 15 will be enough. The MIPI-specs are memberwalled. Someone who knows can tell perhaps? ChangeLog v1->v2: - New patch after feedback. --- .../bindings/display/dsi-controller.yaml | 74 +++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/dsi-controller.yaml diff --git a/Documentation/devicetree/bindings/display/dsi-controller.yaml b/Documentation/devicetree/bindings/display/dsi-controller.yaml new file mode 100644 index ..9e2bf7776c15 --- /dev/null +++ b/Documentation/devicetree/bindings/display/dsi-controller.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/dsi-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common Properties for DSI Display Panels + +maintainers: + - Linus Walleij + +description: | + This document defines device tree properties common to DSI, Display + Serial Interface panels. It doesn't constitute a device tree binding + specification by itself but is meant to be referenced by device tree + bindings. + + When referenced from panel device tree bindings the properties defined in + this document are defined as follows. The panel device tree bindings are + responsible for defining whether each property is required or optional. + + Notice: this binding concerns DSI panels connected directly to a master + without any intermediate port graph to the panel. Each DSI master + can control exactly one panel. They should all just have a node "panel" + for their panel with their reg-property set to 0. + +properties: + $nodename: +pattern: "^dsi-controller(@.*)?$" + + "#address-cells": +const: 1 + + "#size-cells": +const: 0 + +patternProperties: + "^panel@[0-3]$": +description: Panels connected to the DSI link +type: object + +properties: + reg: +minimum: 0 +maximum: 3 +description: + The virtual channel number of a DSI peripheral. Must be in the range + from 0 to 3, as DSI uses a 2-bit addressing scheme. Some DSI + peripherals respond to more than a single virtual channel. In that + case the reg property can take multiple entries, one for each virtual + channel that the peripheral responds to. + + clock-master: +type: boolean +description: + Should be enabled if the host is being used in conjunction with + another DSI host to drive the same peripheral. Hardware supporting + such a configuration generally requires the data on both the busses + to be driven by the same clock. Only the DSI host instance + controlling this clock should contain this property. + + enforce-video-mode: +type: boolean +description: + The best option is usually to run a panel in command mode, as this + gives better control ov
[PATCH 2/2 v5] drm/panel: Add DT bindings for Sony ACX424AKP
This adds device tree bindings for the Sony ACX424AKP panel.
Let's use YAML.
Cc: devicet...@vger.kernel.org
Signed-off-by: Linus Walleij
---
ChangeLog v4->v5:
- Fix up all warnings etc incurred from the now working schema check
and DTS compilation.
- I still have a vert annoying error message in the Sony
panel bindings that uses this schema:
sony,acx424akp.example.dt.yaml: panel@0: $nodename:0: 'panel@0' does not
match '^dsi-controller(@.*)?$'
As this is modeled very closely to
Documentation/devicetree/bindings/net/mdio.yaml
and that one doesn't emit this type of warning for its ethernet-phy@0
etc I am pretty much clueless and just can't see what the problem
is.
- If I can't figure this out the only viable next step is to drop the
ambition to create yaml bindings simply because I'm unable to do
it, and go back to traditional text bindings :(
ChangeLog v3->v4:
- Adjust to adjusted DSI bindings.
ChangeLog v2->v3:
- Put the example inside a dsi-controller so we have a complete
example that verifies to the DSI panel generic binding.
ChangeLog v1->v2:
- Suggest a stand-alone YAML bindings file for DSI panels in
a separate patch, and use that to reference the
boolean "enforce-video-mode" attribute for DSI panels
---
.../display/panel/sony,acx424akp.yaml | 50 +++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
new file mode 100644
index ..1c123139b80a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/sony,acx424akp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony ACX424AKP 4" 480x864 AMOLED panel
+
+maintainers:
+ - Linus Walleij
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: ../dsi-controller.yaml#
+
+properties:
+ compatible:
+const: sony,acx424akp
+ reg: true
+ reset-gpios: true
+ vddi-supply:
+ description: regulator that supplies the vddi voltage
+ enforce-video-mode: true
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi-controller@a0351000 {
+compatible = "ste,mcde-dsi";
+reg = <0xa0351000 0x1000>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "sony,acx424akp";
+reg = <0>;
+vddi-supply = <&foo>;
+reset-gpios = <&foo_gpio 0 GPIO_ACTIVE_LOW>;
+};
+};
+
+...
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Overlay support in the i.MX7 display
Hi Laurent, On 2019-11-01 09:43, Laurent Pinchart wrote: > Hello, > > I'm looking at the available options to support overlays in the display > pipeline of the i.MX7. The LCDIF itself unfortunaltey doesn't support > overlays, the feature being implemented in the PXP. A driver for the PXP > is available but only supports older SoCs whose PXP doesn't support > overlays. This driver is implemented as a V4L2 mem2mem driver, which > makes support of additional input channels impossible. Thanks for bringing this up, it is a topic I have wondered too: Interaction between PXP and mxsfb. I am not very familiar with the V4L2 subsystem so take my opinions with a grain of salt. > > Here are the options I can envision: > > - Extend the existing PXP driver to support multiple channels. This is > technically feasible, but will require moving away from the V4L2 > mem2mem framework, which would break userspace. I don't think this > path could lead anywhere. > > - Write a new PXP driver for the i.MX7, still using V4L2, but with > multiple video nodes. This would allow blending multiple layers, but > would require writing the output to memory, while the PXP has support > for direct connections to the LCDIF (through small SRAM buffers). > Performances would thus be suboptimal. The API would also be awkward, > as using the PXP for display would require usage of V4L2 in > applications. So the video nodes would be sinks? I would expect overlays to be usable through KMS, I guess that would then not work, correct? > > - Extend the mxsfb driver with PXP support, and expose the PXP inputs as > KMS planes. The PXP would only be used when available, and would be > transparent to applications. This would however prevent using it > separately from the display (to perform multi-pass alpha blending for > instance). KMS planes are well defined and are well integrated with the KMS API, so I prefer this option. But is this compatible with the currently supported video use-case? E.g. could we make PXP available through V4L2 and through DRM/mxsfb? Not sure what your use case is exactly, but when playing a video I wonder where is the higher value using PXP: Color conversion and scaling or compositing...? I would expect higher value in the former use case. > > What would be the best option going forward ? Would any of you, by any > chance, have already started work in this area ? I have not worked in that area, so feel free! -- Stefan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Individuals interested in VESA memberships?
On Fri, Nov 1, 2019 at 9:06 PM Lyude Paul wrote: > > Hi! Recently I've been working with the rest of the X.Org board to try to get > X.org access to VESA memberships so that contributors that don't have an > employer who is able/willing to join VESA can potentially get access to the > various benefits of a VESA membership, such as access to DisplayPort > specifications. Since I need to gather a list of interested X.org members, I'd > like to know who all might be interested in a membership like this. There are > no costs involved, as the VESA membership we're looking at in particular comes > at no cost to us since we're a non-profit. > > The current plan is to extend VESA membership to X.Org members who > specifically request it. If you think you'd be at all interested in this, or > know any projects or contributors who would be, please feel free to respond to > this message and let me know! Hi Lyude, I would be interested. Thanks, Roman > -- > Cheers, > Lyude Paul > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic
Hi allen,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.4-rc5 next-20191031]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/allen/drm-edid-fixup-EDID-1-3-and-1-4-judge-reduced-blanking-timings-logic/20191102-200357
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
1204c70d9dcba31164f78ad5d8c88c42335d51f8
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
smatch warnings:
drivers/gpu/drm/drm_edid.c:2042 drm_monitor_supports_rb() warn: always true
condition '(closure.support_rb >= 0) => (0-255 >= 0)'
vim +2042 drivers/gpu/drm/drm_edid.c
2030
2031 /* EDID 1.4 defines this explicitly. For EDID 1.3, we guess, badly. */
2032 static bool
2033 drm_monitor_supports_rb(struct edid *edid)
2034 {
2035 struct edid_support_rb_closure closure = {
2036 .edid = edid,
2037 .support_rb = -1,
2038 };
2039
2040 if (edid->revision >= 4) {
2041 drm_for_each_detailed_block((u8 *)edid, is_rb,
&closure);
> 2042 if (closure.support_rb >= 0)
2043 return closure.support_rb;
2044 }
2045
2046 return true;
2047 }
2048
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
