[pull] amdgpu drm-fixes-5.10
Hi Dave, Daniel, Fixes for 5.10. The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.10-2020-10-29 for you to fetch changes up to 65d437b83b2b8eb9ae47b6145399fc7683b028f7: drm/amdgpu/pm: fix the fan speed in fan1_input in manual mode for navi1x (2020-10-27 14:08:03 -0400) amd-drm-fixes-5.10-2020-10-29: amdgpu: - Add new navi1x PCI ID - GPUVM reserved area fixes - Misc display fixes - Fix bad interactions between display code and CONFIG_KGDB - Fixes for SMU manual fan control and i2c Alex Deucher (3): drm/amdgpu/display: use kvzalloc again in dc_create_state drm/amdgpu/swsmu: drop smu i2c bus on navi1x drm/amdgpu/pm: fix the fan speed in fan1_input in manual mode for navi1x Christian König (1): drm/amdgpu: increase the reserved VM size to 2MB David Galiffi (1): drm/amd/display: Fixed panic during seamless boot. Dmytro Laktyushkin (1): drm/amd/display: prevent null pointer access Kenneth Feng (1): drm/amd/pm: fix the wrong fan speed in fan1_input Madhav Chauhan (1): drm/amdgpu: don't map BO in reserved region Martin Leung (1): drm/amd/display: adding ddc_gpio_vga_reg_list to ddc reg def'ns Takashi Iwai (3): drm/amd/display: Fix kernel panic by dal_gpio_open() error drm/amd/display: Don't invoke kgdb_breakpoint() unconditionally drm/amd/display: Clean up debug macros Tianci.Yin (2): drm/amdgpu: disable DCN and VCN for navi10 blockchain SKU(v3) drm/amdgpu: add DID for navi10 blockchain SKU drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 10 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 4 +-- drivers/gpu/drm/amd/amdgpu/nv.c| 14 +++-- drivers/gpu/drm/amd/display/Kconfig| 1 + drivers/gpu/drm/amd/display/dc/core/dc.c | 4 +-- .../gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 +- .../gpu/drm/amd/display/dc/dcn30/dcn30_resource.c | 12 +--- .../amd/display/dc/gpio/dcn30/hw_factory_dcn30.c | 12 drivers/gpu/drm/amd/display/dc/gpio/gpio_base.c| 4 +-- drivers/gpu/drm/amd/display/dc/os_types.h | 33 drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c| 36 ++ .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c| 11 ++- 13 files changed, 69 insertions(+), 76 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: Disable accelerated scrolling
On 28. 10. 20, 17:06, Daniel Vetter wrote:
So ever since syzbot discovered fbcon, we have solid proof that it's
full of bugs. And often the solution is to just delete code and remove
features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
...
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1147,11 +1147,13 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->graphics = 0;
- if ((cap & FBINFO_HWACCEL_COPYAREA) &&
- !(cap & FBINFO_HWACCEL_DISABLED))
- p->scrollmode = SCROLL_MOVE;
- else /* default to something safe */
- p->scrollmode = SCROLL_REDRAW;
+ /*
+* No more hw acceleration for fbcon.
+*
+* FIXME: Garabge collect all the now dead code after sufficient time
If you go this non-invasive path, then only a nit here: "Garbage"
thanks,
--
js
suse labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/drm_gem.c
between commit:
f49a51bfdc8e ("drm/shme-helpers: Fix dma_buf_mmap forwarding bug")
from the drm-misc-fixes tree and commit:
d693def4fd1c ("drm: Remove obsolete GEM and PRIME callbacks from struct
drm_driver")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/drm_gem.c
index 69c2c079d803,1da67d34e55d..
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@@ -1085,9 -1076,7 +1076,9 @@@ int drm_gem_mmap_obj(struct drm_gem_obj
*/
drm_gem_object_get(obj);
+ vma->vm_private_data = obj;
+
- if (obj->funcs && obj->funcs->mmap) {
+ if (obj->funcs->mmap) {
ret = obj->funcs->mmap(obj, vma);
if (ret) {
drm_gem_object_put(obj);
pgpB83ZrdwiUQ.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v3,3/3] dt-bindings: drm/msm/gpu: Add cooling device support
On Wed, Oct 28, 2020 at 07:09:54PM +0530, Akhil P Oommen wrote:
> Add cooling device support to gpu. A cooling device is bound to a
> thermal zone to allow thermal mitigation.
>
> Signed-off-by: Akhil P Oommen
> ---
> Documentation/devicetree/bindings/display/msm/gpu.txt | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt
> b/Documentation/devicetree/bindings/display/msm/gpu.txt
> index 1af0ff1..090dcb3 100644
> --- a/Documentation/devicetree/bindings/display/msm/gpu.txt
> +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
> @@ -39,6 +39,10 @@ Required properties:
> a4xx Snapdragon SoCs. See
> Documentation/devicetree/bindings/sram/qcom,ocmem.yaml.
>
> +Optional properties:
> +- #cooling-cells: The value must be 2. For details, please refer
> + Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml.
> +
> Example 3xx/4xx:
>
> / {
> @@ -61,6 +65,7 @@ Example 3xx/4xx:
> power-domains = <&mmcc OXILICX_GDSC>;
> operating-points-v2 = <&gpu_opp_table>;
> iommus = <&gpu_iommu 0>;
> + #cooling-cells = <2>;
> };
>
> gpu_sram: ocmem@fdd0 {
> @@ -98,6 +103,8 @@ Example a6xx (with GMU):
> reg = <0x500 0x4>, <0x509e000 0x10>;
> reg-names = "kgsl_3d0_reg_memory", "cx_mem";
>
> + #cooling-cells = <2>;
> +
> /*
>* Look ma, no clocks! The GPU clocks and power are
>* controlled entirely by the GMU
Reviewed-by: Matthias Kaehlcke
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: xlnx: Use dma_request_chan for DMA channel request
On Tue, Oct 27, 2020 at 06:36:02PM -0700, Hyun Kwon wrote:
> Hi Peter,
>
> Thanks for the patch.
>
> On Fri, Oct 23, 2020 at 02:46:02AM -0700, Peter Ujfalusi wrote:
> > There is no need to use the of_dma_request_slave_channel() directly as
> > dma_request_chan() is going to try to get the channel via OF as well.
> >
> > Signed-off-by: Peter Ujfalusi
>
> So now dma_request_chan() has sysfs / debugfs registrations, and this looks
> good to me. I'll commit this within next couple days and keep it posted here.
>
Applied to drm-misc-next.
Thanks!
-hyun
> Thanks,
> -hyun
>
> > ---
> > drivers/gpu/drm/xlnx/zynqmp_disp.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > index 98bd48f13fd1..a4405d081aca 100644
> > --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > @@ -28,7 +28,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > @@ -1316,8 +1315,7 @@ static int zynqmp_disp_layer_request_dma(struct
> > zynqmp_disp *disp,
> >
> > snprintf(dma_channel_name, sizeof(dma_channel_name),
> > "%s%u", dma_names[layer->id], i);
> > - dma->chan = of_dma_request_slave_channel(disp->dev->of_node,
> > -dma_channel_name);
> > + dma->chan = dma_request_chan(disp->dev, dma_channel_name);
> > if (IS_ERR(dma->chan)) {
> > dev_err(disp->dev, "failed to request dma channel\n");
> > ret = PTR_ERR(dma->chan);
> > --
> > Peter
> >
> > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v3,2/3] arm64: dts: qcom: sc7180: Add gpu cooling support
Hi Akhil,
On Wed, Oct 28, 2020 at 07:09:53PM +0530, Akhil P Oommen wrote:
> Add cooling-cells property and the cooling maps for the gpu tzones
> to support GPU cooling.
>
> Signed-off-by: Akhil P Oommen
> ---
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 30 +++---
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index d46b383..a7ea029 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -2,7 +2,7 @@
> /*
> * SC7180 SoC device tree source
> *
> - * Copyright (c) 2019, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2019-20, The Linux Foundation. All rights reserved.
> */
>
> #include
> @@ -1886,6 +1886,8 @@
> operating-points-v2 = <&gpu_opp_table>;
> qcom,gmu = <&gmu>;
>
> + #cooling-cells = <2>;
> +
> interconnects = <&gem_noc MASTER_GFX3D &mc_virt
> SLAVE_EBI1>;
> interconnect-names = "gfx-mem";
>
> @@ -3825,16 +3827,16 @@
> };
>
> gpuss0-thermal {
> - polling-delay-passive = <0>;
> + polling-delay-passive = <100>;
> polling-delay = <0>;
>
> thermal-sensors = <&tsens0 13>;
>
> trips {
> gpuss0_alert0: trip-point0 {
> - temperature = <9>;
> + temperature = <95000>;
> hysteresis = <2000>;
> - type = "hot";
> + type = "passive";
> };
>
> gpuss0_crit: gpuss0_crit {
> @@ -3843,19 +3845,26 @@
> type = "critical";
> };
> };
> +
> + cooling-maps {
> + map0 {
> + trip = <&gpuss0_alert0>;
> + cooling-device = <&gpu THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + };
> + };
> };
>
> gpuss1-thermal {
> - polling-delay-passive = <0>;
> + polling-delay-passive = <100>;
> polling-delay = <0>;
>
> thermal-sensors = <&tsens0 14>;
>
> trips {
> gpuss1_alert0: trip-point0 {
> - temperature = <9>;
> + temperature = <95000>;
> hysteresis = <2000>;
> - type = "hot";
> + type = "passive";
> };
>
> gpuss1_crit: gpuss1_crit {
> @@ -3864,6 +3873,13 @@
> type = "critical";
> };
> };
> +
> + cooling-maps {
> + map0 {
> + trip = <&gpuss0_alert0>;
Copy & paste error, this should be 'gpuss1_alert0'.
> + cooling-device = <&gpu THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + };
> + };
> };
>
> aoss1-thermal {
Other than the C&P error:
Reviewed-by: Matthias Kaehlcke
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap
This adds a heap that allocates non-contiguous buffers that are
marked as writecombined, so they are not cached by the CPU.
This is useful, as most graphics buffers are usually not touched
by the CPU or only written into once by the CPU. So when mapping
the buffer over and over between devices, we can skip the CPU
syncing, which saves a lot of cache management overhead, greatly
improving performance.
For folk using ION, there was a ION_FLAG_CACHED flag, which
signaled if the returned buffer should be CPU cacheable or not.
With DMA-BUF heaps, we do not yet have such a flag, and by default
the current heaps (system and cma) produce CPU cachable buffers.
So for folks transitioning from ION to DMA-BUF Heaps, this fills
in some of that missing functionality.
There has been a suggestion to make this functionality a flag
(DMAHEAP_FLAG_UNCACHED?) on the system heap, similar to how
ION used the ION_FLAG_CACHED. But I want to make sure an
_UNCACHED flag would truely be a generic attribute across all
heaps. So far that has been unclear, so having it as a separate
heap seemes better for now. (But I'm open to discussion on this
point!)
This is a rework of earlier efforts to add a uncached system heap,
done utilizing the exisitng system heap, adding just a bit of
logic to handle the uncached case.
Feedback would be very welcome!
Many thanks to Liam Mark for his help to get this working.
Pending opensource users of this code include:
* AOSP HiKey960 gralloc:
- https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519
- Visibly improves performance over the system heap
* AOSP Codec2 (possibly, needs more review):
-
https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v4:
* Make sys_uncached_heap static, as
Reported-by: kernel test robot
* Fix wrong return value, caught by smatch
Reported-by: kernel test robot
Reported-by: Dan Carpenter
* Ensure we call flush/invalidate_kernel_vmap_range() in the
uncached cases to try to address feedback about VIVT caches
from Christoph
* Reorder a few lines as suggested by BrianS
* Avoid holding the initial mapping for the lifetime of the buffer
as suggested by BrianS
* Fix a unlikely race between allocate and updating the dma_mask
that BrianS noticed.
---
drivers/dma-buf/heaps/system_heap.c | 111
1 file changed, 95 insertions(+), 16 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index ef4b2c1032df..a328c76249d2 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -22,6 +22,7 @@
#include
static struct dma_heap *sys_heap;
+static struct dma_heap *sys_uncached_heap;
struct system_heap_buffer {
struct dma_heap *heap;
@@ -31,6 +32,8 @@ struct system_heap_buffer {
struct sg_table sg_table;
int vmap_cnt;
void *vaddr;
+
+ bool uncached;
};
struct dma_heap_attachment {
@@ -38,6 +41,8 @@ struct dma_heap_attachment {
struct sg_table *table;
struct list_head list;
bool mapped;
+
+ bool uncached;
};
#define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
@@ -94,7 +99,7 @@ static int system_heap_attach(struct dma_buf *dmabuf,
a->dev = attachment->dev;
INIT_LIST_HEAD(&a->list);
a->mapped = false;
-
+ a->uncached = buffer->uncached;
attachment->priv = a;
mutex_lock(&buffer->lock);
@@ -124,9 +129,13 @@ static struct sg_table *system_heap_map_dma_buf(struct
dma_buf_attachment *attac
{
struct dma_heap_attachment *a = attachment->priv;
struct sg_table *table = a->table;
+ int attr = 0;
int ret;
- ret = dma_map_sgtable(attachment->dev, table, direction, 0);
+ if (a->uncached)
+ attr = DMA_ATTR_SKIP_CPU_SYNC;
+
+ ret = dma_map_sgtable(attachment->dev, table, direction, attr);
if (ret)
return ERR_PTR(ret);
@@ -139,9 +148,12 @@ static void system_heap_unmap_dma_buf(struct
dma_buf_attachment *attachment,
enum dma_data_direction direction)
{
struct dma_heap_attachment *a = attachment->priv;
+ int attr = 0;
+ if (a->uncached)
+ attr = DMA_ATTR_SKIP_CPU_SYNC;
a->mapped = false;
- dma_unmap_sgtable(attachment->dev, table, direction, 0);
+ dma_unmap_sgtable(attachment->dev, table, direction, attr);
}
static int system_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
@@ -155,10 +167
[RESEND][PATCH v4 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
Hey All, So just wanted to resend my last revision of my patch series of performance optimizations to the dma-buf system heap. This series reworks the system heap to use sgtables, and then consolidates the pagelist method from the heap-helpers into the CMA heap. After which the heap-helpers logic is removed (as it is unused). I'd still like to find a better way to avoid some of the logic duplication in implementing the entire dma_buf_ops handlers per heap. But unfortunately that code is tied somewhat to how the buffer's memory is tracked. As more heaps show up I think we'll have a better idea how to best share code, so for now I think this is ok. After this, the series introduces an optimization that Ørjan Eide implemented for ION that avoids calling sync on attachments that don't have a mapping. Next, an optimization to use larger order pages for the system heap. This change brings us closer to the current performance of the ION allocation code (though there still is a gap due to ION using a mix of deferred-freeing and page pools, I'll be looking at integrating those eventually). Finally, a reworked version of my uncached system heap implementation I was submitting a few weeks back. Since it duplicated a lot of the now reworked system heap code, I realized it would be much simpler to add the functionality to the system_heap implementation itself. While not improving the core allocation performance, the uncached heap allocations do result in *much* improved performance on HiKey960 as it avoids a lot of flushing and invalidating buffers that the cpu doesn't touch often. Feedback on these would be great! thanks -john New in v4: * Make sys_heap static (indirectly) Reported-by: kernel test robot * Spelling fixes suggested by BrianS * Make sys_uncached_heap static, as Reported-by: kernel test robot * Fix wrong return value, caught by smatch Reported-by: kernel test robot Reported-by: Dan Carpenter * Ensure we call flush/invalidate_kernel_vmap_range() in the uncached cases to try to address feedback about VIVT caches from Christoph * Reorder a few lines as suggested by BrianS * Avoid holding the initial mapping for the lifetime of the buffer as suggested by BrianS * Fix a unlikely race between allocate and updating the dma_mask that BrianS noticed. Cc: Sumit Semwal Cc: Liam Mark Cc: Laura Abbott Cc: Brian Starkey Cc: Hridya Valsaraju Cc: Suren Baghdasaryan Cc: Sandeep Patil Cc: Daniel Mentz Cc: Chris Goldsworthy Cc: Ørjan Eide Cc: Robin Murphy Cc: Ezequiel Garcia Cc: Simon Ser Cc: James Jones Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org John Stultz (7): dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists dma-buf: heaps: Move heap-helper logic into the cma_heap implementation dma-buf: heaps: Remove heap-helpers code dma-buf: heaps: Skip sync if not mapped dma-buf: system_heap: Allocate higher order pages if available dma-buf: dma-heap: Keep track of the heap device struct dma-buf: system_heap: Add a system-uncached heap re-using the system heap drivers/dma-buf/dma-heap.c | 33 +- drivers/dma-buf/heaps/Makefile | 1 - drivers/dma-buf/heaps/cma_heap.c | 324 +++--- drivers/dma-buf/heaps/heap-helpers.c | 270 --- drivers/dma-buf/heaps/heap-helpers.h | 53 --- drivers/dma-buf/heaps/system_heap.c | 488 --- include/linux/dma-heap.h | 9 + 7 files changed, 747 insertions(+), 431 deletions(-) delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/7] dma-buf: system_heap: Allocate higher order pages if available
While the system heap can return non-contiguous pages,
try to allocate larger order pages if possible.
This will allow slight performance gains and make implementing
page pooling easier.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
v3:
* Use page_size() rather then opencoding it
---
drivers/dma-buf/heaps/system_heap.c | 83 ++---
1 file changed, 65 insertions(+), 18 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 15b36bc862b1..ef4b2c1032df 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -40,6 +40,14 @@ struct dma_heap_attachment {
bool mapped;
};
+#define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
+ | __GFP_NORETRY) & ~__GFP_RECLAIM) \
+ | __GFP_COMP)
+#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP)
+static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP, LOW_ORDER_GFP};
+static const unsigned int orders[] = {8, 4, 0};
+#define NUM_ORDERS ARRAY_SIZE(orders)
+
static struct sg_table *dup_sg_table(struct sg_table *table)
{
struct sg_table *new_table;
@@ -270,8 +278,11 @@ static void system_heap_dma_buf_release(struct dma_buf
*dmabuf)
int i;
table = &buffer->sg_table;
- for_each_sgtable_sg(table, sg, i)
- __free_page(sg_page(sg));
+ for_each_sg(table->sgl, sg, table->nents, i) {
+ struct page *page = sg_page(sg);
+
+ __free_pages(page, compound_order(page));
+ }
sg_free_table(table);
kfree(buffer);
}
@@ -289,6 +300,26 @@ static const struct dma_buf_ops system_heap_buf_ops = {
.release = system_heap_dma_buf_release,
};
+static struct page *alloc_largest_available(unsigned long size,
+ unsigned int max_order)
+{
+ struct page *page;
+ int i;
+
+ for (i = 0; i < NUM_ORDERS; i++) {
+ if (size < (PAGE_SIZE << orders[i]))
+ continue;
+ if (max_order < orders[i])
+ continue;
+
+ page = alloc_pages(order_flags[i], orders[i]);
+ if (!page)
+ continue;
+ return page;
+ }
+ return NULL;
+}
+
static int system_heap_allocate(struct dma_heap *heap,
unsigned long len,
unsigned long fd_flags,
@@ -296,11 +327,13 @@ static int system_heap_allocate(struct dma_heap *heap,
{
struct system_heap_buffer *buffer;
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+ unsigned long size_remaining = len;
+ unsigned int max_order = orders[0];
struct dma_buf *dmabuf;
struct sg_table *table;
struct scatterlist *sg;
- pgoff_t pagecount;
- pgoff_t pg;
+ struct list_head pages;
+ struct page *page, *tmp_page;
int i, ret = -ENOMEM;
buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
@@ -312,25 +345,35 @@ static int system_heap_allocate(struct dma_heap *heap,
buffer->heap = heap;
buffer->len = len;
- table = &buffer->sg_table;
- pagecount = len / PAGE_SIZE;
- if (sg_alloc_table(table, pagecount, GFP_KERNEL))
- goto free_buffer;
-
- sg = table->sgl;
- for (pg = 0; pg < pagecount; pg++) {
- struct page *page;
+ INIT_LIST_HEAD(&pages);
+ i = 0;
+ while (size_remaining > 0) {
/*
* Avoid trying to allocate memory if the process
* has been killed by SIGKILL
*/
if (fatal_signal_pending(current))
- goto free_pages;
- page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ goto free_buffer;
+
+ page = alloc_largest_available(size_remaining, max_order);
if (!page)
- goto free_pages;
+ goto free_buffer;
+
+ list_add_tail(&page->lru, &pages);
+ size_remaining -= page_size(page);
+ max_order = compound_order(page);
+ i++;
+ }
+
+ table = &buffer->sg_table;
+ if (sg_alloc_table(table, i, GFP_KERNEL))
+ goto free_buffer;
+
+ sg = table->sgl;
+ list_for_each_entry_safe(page, tmp_page, &pages, lru) {
sg_set_page(sg, page, page_size(page), 0);
sg = sg_next(sg);
+ list_del(&page->lru);
[PATCH v4 1/7] dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists
In preparation for some patches to optmize the system
heap code, rework the dmabuf exporter to utilize sgtables rather
then pageslists for tracking the associated pages.
This will allow for large order page allocations, as well as
more efficient page pooling.
In doing so, the system heap stops using the heap-helpers logic
which sadly is not quite as generic as I was hoping it to be, so
this patch adds heap specific implementations of the dma_buf_ops
function handlers.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
v2:
* Fix locking issue and an unused return value Reported-by:
kernel test robot
Julia Lawall
* Make system_heap_buf_ops static Reported-by:
kernel test robot
v3:
* Use the new sgtable mapping functions, as Suggested-by:
Daniel Mentz
v4:
* Make sys_heap static (indirectly) Reported-by:
kernel test robot
* Spelling fix suggested by BrianS
---
drivers/dma-buf/heaps/system_heap.c | 344
1 file changed, 298 insertions(+), 46 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 0bf688e3c023..5c44f9c06807 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -3,7 +3,11 @@
* DMABUF System heap exporter
*
* Copyright (C) 2011 Google, Inc.
- * Copyright (C) 2019 Linaro Ltd.
+ * Copyright (C) 2019, 2020 Linaro Ltd.
+ *
+ * Portions based off of Andrew Davis' SRAM heap:
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
*/
#include
@@ -15,72 +19,321 @@
#include
#include
#include
-#include
-#include
+#include
+
+static struct dma_heap *sys_heap;
-#include "heap-helpers.h"
+struct system_heap_buffer {
+ struct dma_heap *heap;
+ struct list_head attachments;
+ struct mutex lock;
+ unsigned long len;
+ struct sg_table sg_table;
+ int vmap_cnt;
+ void *vaddr;
+};
-struct dma_heap *sys_heap;
+struct dma_heap_attachment {
+ struct device *dev;
+ struct sg_table *table;
+ struct list_head list;
+};
-static void system_heap_free(struct heap_helper_buffer *buffer)
+static struct sg_table *dup_sg_table(struct sg_table *table)
{
- pgoff_t pg;
+ struct sg_table *new_table;
+ int ret, i;
+ struct scatterlist *sg, *new_sg;
+
+ new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+ if (!new_table)
+ return ERR_PTR(-ENOMEM);
+
+ ret = sg_alloc_table(new_table, table->orig_nents, GFP_KERNEL);
+ if (ret) {
+ kfree(new_table);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ new_sg = new_table->sgl;
+ for_each_sgtable_sg(table, sg, i) {
+ sg_set_page(new_sg, sg_page(sg), sg->length, sg->offset);
+ new_sg = sg_next(new_sg);
+ }
+
+ return new_table;
+}
+
+static int system_heap_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct system_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a;
+ struct sg_table *table;
+
+ a = kzalloc(sizeof(*a), GFP_KERNEL);
+ if (!a)
+ return -ENOMEM;
+
+ table = dup_sg_table(&buffer->sg_table);
+ if (IS_ERR(table)) {
+ kfree(a);
+ return -ENOMEM;
+ }
+
+ a->table = table;
+ a->dev = attachment->dev;
+ INIT_LIST_HEAD(&a->list);
+
+ attachment->priv = a;
+
+ mutex_lock(&buffer->lock);
+ list_add(&a->list, &buffer->attachments);
+ mutex_unlock(&buffer->lock);
+
+ return 0;
+}
+
+static void system_heap_detach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct system_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a = attachment->priv;
+
+ mutex_lock(&buffer->lock);
+ list_del(&a->list);
+ mutex_unlock(&buffer->lock);
+
+ sg_free_table(a->table);
+ kfree(a->table);
+ kfree(a);
+}
- for (pg = 0; pg < buffer->pagecount; pg++)
- __free_page(buffer->pages[pg]);
- kfree(buffer->pages);
+static struct sg_table *system_heap_map_dma_buf(struct dma_buf_attachment
*attachment,
+ enum dma_data_direction
direction)
+{
+ struct dma_heap_attachment *a = attachment->priv;
+ struct sg_table *table = a->table;
+ int ret;
+
+ ret = dma_map_sgtable(attachment->dev, table, direction, 0);
+ if (ret)
+ return ERR_PTR(
[PATCH v4 4/7] dma-buf: heaps: Skip sync if not mapped
This patch is basically a port of Ørjan Eide's similar patch for ION
https://lore.kernel.org/lkml/20200414134629.54567-1-orjan.e...@arm.com/
Only sync the sg-list of dma-buf heap attachment when the attachment
is actually mapped on the device.
dma-bufs may be synced at any time. It can be reached from user space
via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when
syncs may be attempted, and dma_buf_end_cpu_access() and
dma_buf_begin_cpu_access() may not be paired.
Since the sg_list's dma_address isn't set up until the buffer is used
on the device, and dma_map_sg() is called on it, the dma_address will be
NULL if sync is attempted on the dma-buf before it's mapped on a device.
Before v5.0 (commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops
into the dma_direct code")) this was a problem as the dma-api (at least
the swiotlb_dma_ops on arm64) would use the potentially invalid
dma_address. How that failed depended on how the device handled physical
address 0. If 0 was a valid address to physical ram, that page would get
flushed a lot, while the actual pages in the buffer would not get synced
correctly. While if 0 is an invalid physical address it may cause a
fault and trigger a crash.
In v5.0 this was incidentally fixed by commit 55897af63091 ("dma-direct:
merge swiotlb_dma_ops into the dma_direct code"), as this moved the
dma-api to use the page pointer in the sg_list, and (for Ion buffers at
least) this will always be valid if the sg_list exists at all.
But, this issue is re-introduced in v5.3 with
commit 449fa54d6815 ("dma-direct: correct the physical addr in
dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old
behaviour and picks the dma_address that may be invalid.
dma-buf core doesn't ensure that the buffer is mapped on the device, and
thus have a valid sg_list, before calling the exporter's
begin_cpu_access.
Logic and commit message originally by: Ørjan Eide
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/cma_heap.c| 10 ++
drivers/dma-buf/heaps/system_heap.c | 10 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 5341e5e226d5..028f1e8d6041 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -43,6 +43,7 @@ struct dma_heap_attachment {
struct device *dev;
struct sg_table table;
struct list_head list;
+ bool mapped;
};
static int cma_heap_attach(struct dma_buf *dmabuf,
@@ -67,6 +68,7 @@ static int cma_heap_attach(struct dma_buf *dmabuf,
a->dev = attachment->dev;
INIT_LIST_HEAD(&a->list);
+ a->mapped = false;
attachment->priv = a;
@@ -101,6 +103,7 @@ static struct sg_table *cma_heap_map_dma_buf(struct
dma_buf_attachment *attachme
ret = dma_map_sgtable(attachment->dev, table, direction, 0);
if (ret)
return ERR_PTR(-ENOMEM);
+ a->mapped = true;
return table;
}
@@ -108,6 +111,9 @@ static void cma_heap_unmap_dma_buf(struct
dma_buf_attachment *attachment,
struct sg_table *table,
enum dma_data_direction direction)
{
+ struct dma_heap_attachment *a = attachment->priv;
+
+ a->mapped = false;
dma_unmap_sgtable(attachment->dev, table, direction, 0);
}
@@ -122,6 +128,8 @@ static int cma_heap_dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
+ if (!a->mapped)
+ continue;
dma_sync_sgtable_for_cpu(a->dev, &a->table, direction);
}
mutex_unlock(&buffer->lock);
@@ -140,6 +148,8 @@ static int cma_heap_dma_buf_end_cpu_access(struct dma_buf
*dmabuf,
mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
+ if (!a->mapped)
+ continue;
dma_sync_sgtable_for_device(a->dev, &a->table, direction);
}
mutex_unlock(&buffer->lock);
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 5c44f9c06807..15b36bc862b1 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -37,6 +37,7 @@ struct dma_heap_attachment {
struct device *dev;
struct sg_table *table;
struct list_head list;
+ bool mapped;
};
static struct sg_table *dup_sg_table(struct sg_table *table)
@@ -84,6 +85,7 @@ static int system_heap_attach(struc
[PATCH v4 2/7] dma-buf: heaps: Move heap-helper logic into the cma_heap implementation
Since the heap-helpers logic ended up not being as generic as
hoped, move the heap-helpers dma_buf_ops implementations into
the cma_heap directly.
This will allow us to remove the heap_helpers code in a following
patch.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
v2:
* Fix unused return value and locking issue Reported-by:
kernel test robot
Julia Lawall
* Make cma_heap_buf_ops static suggested by
kernel test robot
* Fix uninitialized return in cma Reported-by:
kernel test robot
* Minor cleanups
v3:
* Use the new sgtable mapping functions, as Suggested-by:
Daniel Mentz
v4:
* Spelling fix suggested by BrianS
---
drivers/dma-buf/heaps/cma_heap.c | 314 ++-
1 file changed, 265 insertions(+), 49 deletions(-)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index e55384dc115b..5341e5e226d5 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -2,76 +2,290 @@
/*
* DMABUF CMA heap exporter
*
- * Copyright (C) 2012, 2019 Linaro Ltd.
+ * Copyright (C) 2012, 2019, 2020 Linaro Ltd.
* Author: for ST-Ericsson.
+ *
+ * Also utilizing parts of Andrew Davis' SRAM heap:
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
*/
-
#include
-#include
#include
#include
#include
#include
-#include
#include
+#include
+#include
#include
-#include
#include
-#include
+#include
-#include "heap-helpers.h"
struct cma_heap {
struct dma_heap *heap;
struct cma *cma;
};
-static void cma_heap_free(struct heap_helper_buffer *buffer)
+struct cma_heap_buffer {
+ struct cma_heap *heap;
+ struct list_head attachments;
+ struct mutex lock;
+ unsigned long len;
+ struct page *cma_pages;
+ struct page **pages;
+ pgoff_t pagecount;
+ int vmap_cnt;
+ void *vaddr;
+};
+
+struct dma_heap_attachment {
+ struct device *dev;
+ struct sg_table table;
+ struct list_head list;
+};
+
+static int cma_heap_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
{
- struct cma_heap *cma_heap = dma_heap_get_drvdata(buffer->heap);
- unsigned long nr_pages = buffer->pagecount;
- struct page *cma_pages = buffer->priv_virt;
+ struct cma_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a;
+ int ret;
- /* free page list */
- kfree(buffer->pages);
- /* release memory */
- cma_release(cma_heap->cma, cma_pages, nr_pages);
+ a = kzalloc(sizeof(*a), GFP_KERNEL);
+ if (!a)
+ return -ENOMEM;
+
+ ret = sg_alloc_table_from_pages(&a->table, buffer->pages,
+ buffer->pagecount, 0,
+ buffer->pagecount << PAGE_SHIFT,
+ GFP_KERNEL);
+ if (ret) {
+ kfree(a);
+ return ret;
+ }
+
+ a->dev = attachment->dev;
+ INIT_LIST_HEAD(&a->list);
+
+ attachment->priv = a;
+
+ mutex_lock(&buffer->lock);
+ list_add(&a->list, &buffer->attachments);
+ mutex_unlock(&buffer->lock);
+
+ return 0;
+}
+
+static void cma_heap_detach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct cma_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a = attachment->priv;
+
+ mutex_lock(&buffer->lock);
+ list_del(&a->list);
+ mutex_unlock(&buffer->lock);
+
+ sg_free_table(&a->table);
+ kfree(a);
+}
+
+static struct sg_table *cma_heap_map_dma_buf(struct dma_buf_attachment
*attachment,
+enum dma_data_direction direction)
+{
+ struct dma_heap_attachment *a = attachment->priv;
+ struct sg_table *table = &a->table;
+ int ret;
+
+ ret = dma_map_sgtable(attachment->dev, table, direction, 0);
+ if (ret)
+ return ERR_PTR(-ENOMEM);
+ return table;
+}
+
+static void cma_heap_unmap_dma_buf(struct dma_buf_attachment *attachment,
+ struct sg_table *table,
+ enum dma_data_direction direction)
+{
+ dma_unmap_sgtable(attachment->dev, table, direction, 0);
+}
+
+static int cma_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
+enum dma_data_direction direction)
+{
+ struct cma_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attac
[PATCH v4 3/7] dma-buf: heaps: Remove heap-helpers code
The heap-helpers code was not as generic as initially hoped
and it is now not being used, so remove it from the tree.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/Makefile | 1 -
drivers/dma-buf/heaps/heap-helpers.c | 270 ---
drivers/dma-buf/heaps/heap-helpers.h | 53 --
3 files changed, 324 deletions(-)
delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c
delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 6e54cdec3da0..974467791032 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,4 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
-obj-y += heap-helpers.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
deleted file mode 100644
index d0696cf937af..
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ /dev/null
@@ -1,270 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "heap-helpers.h"
-
-void init_heap_helper_buffer(struct heap_helper_buffer *buffer,
-void (*free)(struct heap_helper_buffer *))
-{
- buffer->priv_virt = NULL;
- mutex_init(&buffer->lock);
- buffer->vmap_cnt = 0;
- buffer->vaddr = NULL;
- buffer->pagecount = 0;
- buffer->pages = NULL;
- INIT_LIST_HEAD(&buffer->attachments);
- buffer->free = free;
-}
-
-struct dma_buf *heap_helper_export_dmabuf(struct heap_helper_buffer *buffer,
- int fd_flags)
-{
- DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
-
- exp_info.ops = &heap_helper_ops;
- exp_info.size = buffer->size;
- exp_info.flags = fd_flags;
- exp_info.priv = buffer;
-
- return dma_buf_export(&exp_info);
-}
-
-static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
-{
- void *vaddr;
-
- vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, PAGE_KERNEL);
- if (!vaddr)
- return ERR_PTR(-ENOMEM);
-
- return vaddr;
-}
-
-static void dma_heap_buffer_destroy(struct heap_helper_buffer *buffer)
-{
- if (buffer->vmap_cnt > 0) {
- WARN(1, "%s: buffer still mapped in the kernel\n", __func__);
- vunmap(buffer->vaddr);
- }
-
- buffer->free(buffer);
-}
-
-static void *dma_heap_buffer_vmap_get(struct heap_helper_buffer *buffer)
-{
- void *vaddr;
-
- if (buffer->vmap_cnt) {
- buffer->vmap_cnt++;
- return buffer->vaddr;
- }
- vaddr = dma_heap_map_kernel(buffer);
- if (IS_ERR(vaddr))
- return vaddr;
- buffer->vaddr = vaddr;
- buffer->vmap_cnt++;
- return vaddr;
-}
-
-static void dma_heap_buffer_vmap_put(struct heap_helper_buffer *buffer)
-{
- if (!--buffer->vmap_cnt) {
- vunmap(buffer->vaddr);
- buffer->vaddr = NULL;
- }
-}
-
-struct dma_heaps_attachment {
- struct device *dev;
- struct sg_table table;
- struct list_head list;
-};
-
-static int dma_heap_attach(struct dma_buf *dmabuf,
- struct dma_buf_attachment *attachment)
-{
- struct dma_heaps_attachment *a;
- struct heap_helper_buffer *buffer = dmabuf->priv;
- int ret;
-
- a = kzalloc(sizeof(*a), GFP_KERNEL);
- if (!a)
- return -ENOMEM;
-
- ret = sg_alloc_table_from_pages(&a->table, buffer->pages,
- buffer->pagecount, 0,
- buffer->pagecount << PAGE_SHIFT,
- GFP_KERNEL);
- if (ret) {
- kfree(a);
- return ret;
- }
-
- a->dev = attachment->dev;
- INIT_LIST_HEAD(&a->list);
-
- attachment->priv = a;
-
- mutex_lock(&buffer->lock);
- list_add(&a->list, &buffer->attachments);
- mutex_unlock(&buffer->lock);
-
- return 0;
-}
-
-static void dma_heap_detach(struct dma_buf *dmabuf,
- struct dma_buf_attachment *attachment)
-{
- struct dma_heaps_attachment *a = attachment->priv;
- struct heap_helper_buffer *buffer = dmabuf->priv;
-
- mutex_lock(&buffer->lock);
- list_del(&a->list);
- mutex_unlock(&buffer->lock);
-
- sg_free_table(&a->table
[PATCH v4 6/7] dma-buf: dma-heap: Keep track of the heap device struct
Keep track of the heap device struct.
This will be useful for special DMA allocations
and actions.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/dma-heap.c | 33 +
include/linux/dma-heap.h | 9 +
2 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9dbdcf..72c746755d89 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -30,6 +30,7 @@
* @heap_devt heap device node
* @list list head connecting to list of heaps
* @heap_cdev heap char device
+ * @heap_dev heap device struct
*
* Represents a heap of memory from which buffers can be made.
*/
@@ -40,6 +41,7 @@ struct dma_heap {
dev_t heap_devt;
struct list_head list;
struct cdev heap_cdev;
+ struct device *heap_dev;
};
static LIST_HEAD(heap_list);
@@ -190,10 +192,21 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
return heap->priv;
}
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap)
+{
+ return heap->heap_dev;
+}
+
struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
{
struct dma_heap *heap, *h, *err_ret;
- struct device *dev_ret;
unsigned int minor;
int ret;
@@ -247,16 +260,20 @@ struct dma_heap *dma_heap_add(const struct
dma_heap_export_info *exp_info)
goto err1;
}
- dev_ret = device_create(dma_heap_class,
- NULL,
- heap->heap_devt,
- NULL,
- heap->name);
- if (IS_ERR(dev_ret)) {
+ heap->heap_dev = device_create(dma_heap_class,
+ NULL,
+ heap->heap_devt,
+ NULL,
+ heap->name);
+ if (IS_ERR(heap->heap_dev)) {
pr_err("dma_heap: Unable to create device\n");
- err_ret = ERR_CAST(dev_ret);
+ err_ret = ERR_CAST(heap->heap_dev);
goto err2;
}
+
+ /* Make sure it doesn't disappear on us */
+ heap->heap_dev = get_device(heap->heap_dev);
+
/* Add heap to the list */
mutex_lock(&heap_list_lock);
list_add(&heap->list, &heap_list);
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 454e354d1ffb..82857e096910 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -50,6 +50,15 @@ struct dma_heap_export_info {
*/
void *dma_heap_get_drvdata(struct dma_heap *heap);
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap);
+
/**
* dma_heap_add - adds a heap to dmabuf heaps
* @exp_info: information needed to register this heap
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm: panel: simple: Add BOE NV110WTM-N61
Add support for the BOE NV110WTM-N61 panel. The EDID lists two modes
(one for 60 Hz refresh rate and one for 40 Hz), so we'll list both of
them here.
Note that the panel datasheet requires 80 ms between HPD asserting and
the backlight power being turned on. We'll use the new timing
constraints structure to do this cleanly. This assumes that the
backlight will be enabled _after_ the panel enable finishes. This is
how it works today and seems a sane assumption.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Adjust for shorter names in patch #1.
drivers/gpu/drm/panel/panel-simple.c | 48
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 2613b9434548..aef9f9b00d2b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1401,6 +1401,51 @@ static const struct panel_desc boe_nv101wxmn51 = {
},
};
+static const struct drm_display_mode boe_nv110wtm_n61_modes[] = {
+ {
+ .clock = 207800,
+ .hdisplay = 2160,
+ .hsync_start = 2160 + 48,
+ .hsync_end = 2160 + 48 + 32,
+ .htotal = 2160 + 48 + 32 + 100,
+ .vdisplay = 1440,
+ .vsync_start = 1440 + 3,
+ .vsync_end = 1440 + 3 + 6,
+ .vtotal = 1440 + 3 + 6 + 31,
+ },
+ {
+ .clock = 138500,
+ .hdisplay = 2160,
+ .hsync_start = 2160 + 48,
+ .hsync_end = 2160 + 48 + 32,
+ .htotal = 2160 + 48 + 32 + 100,
+ .vdisplay = 1440,
+ .vsync_start = 1440 + 3,
+ .vsync_end = 1440 + 3 + 6,
+ .vtotal = 1440 + 3 + 6 + 31,
+ },
+};
+
+static const struct panel_desc boe_nv110wtm_n61 = {
+ .modes = boe_nv110wtm_n61_modes,
+ .num_modes = ARRAY_SIZE(boe_nv110wtm_n61_modes),
+ .bpc = 8,
+ .size = {
+ .width = 233,
+ .height = 155,
+ },
+ .delay = {
+ .hpd_absent_delay = 200,
+ },
+ .min_times = {
+ .prepare_to_enable = 80,
+ .unprepare_to_prepare = 500,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DATA_MSB_TO_LSB,
+ .connector_type = DRM_MODE_CONNECTOR_eDP,
+};
+
/* Also used for boe_nv133fhm_n62 */
static const struct drm_display_mode boe_nv133fhm_n61_modes = {
.clock = 147840,
@@ -4063,6 +4108,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "boe,nv101wxmn51",
.data = &boe_nv101wxmn51,
+ }, {
+ .compatible = "boe,nv110wtm-n61",
+ .data = &boe_nv110wtm_n61,
}, {
.compatible = "boe,nv133fhm-n61",
.data = &boe_nv133fhm_n61,
--
2.29.1.341.ge80a0c044ae-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] dt-bindings: dt-bindings: display: simple: Add BOE NV110WTM-N61
Add yet another eDP panel. Signed-off-by: Douglas Anderson --- (no changes since v1) .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index edb53ab0d9eb..93e244c67e8a 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -76,6 +76,8 @@ properties: # BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel - boe,nv101wxmn51 # BOE NV133FHM-N61 13.3" FHD (1920x1080) TFT LCD Panel + - boe,nv110wtm-n61 +# BOE NV110WTM-N61 11.0" 2160x1440 TFT LCD Panel - boe,nv133fhm-n61 # BOE NV133FHM-N62 13.3" FHD (1920x1080) TFT LCD Panel - boe,nv133fhm-n62 -- 2.29.1.341.ge80a0c044ae-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm: panel: simple: Allow timing constraints, not fixed delays
The simple panel code currently allows panels to define fixed delays
at certain stages of initialization. These work OK, but they don't
really map all that clearly to the requirements presented in many
panel datasheets. Instead of defining a fixed delay, those datasheets
provide a timing diagram and specify a minimum amount of time that
needs to pass from event A to event B.
Because of the way things are currently defined, most panels end up
over-delaying. One prime example here is that a number of panels I've
looked at define the amount of time that must pass between turning a
panel off and turning it back on again. Since there is no way to
specify this, many developers have listed this as the "unprepare"
delay. However, if nobody ever tried to turn the panel on again in
the next 500 ms (or whatever the delay was) then this delay was
pointless. It's better to do the delay only in the case that someone
tried to turn the panel on too quickly.
Let's support specifying delays as constraints. We'll start with the
one above and also a second one: the minimum time between prepare
being done and doing the enable. On the panel I'm looking at, there's
an 80 ms minimum time between HPD being asserted by the panel and
setting the backlight enable GPIO. By specifying as a constraint we
can enforce this without over-delaying. Specifically the link
training is allowed to happen in parallel with this delay so adding a
fixed 80 ms delay isn't ideal.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Inline the kernel doc for the two new members.
- Beefed up kernel doc saying exactly when the delay happens.
- Removed "_ms" from the end of members to shorten them.
- Renamed "timing_constraints" to "min_times" to shorten it.
- Renamed "enforce_constraint()" to "wait_min_time()" to shorten it.
- Check "prepared_time" against 0 to see if we've been prepared.
drivers/gpu/drm/panel/panel-simple.c | 99 ++--
1 file changed, 92 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 2be358fb46f7..2613b9434548 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -92,6 +92,68 @@ struct panel_desc {
unsigned int unprepare;
} delay;
+ struct {
+ /**
+* @prepare_to_enable: Time between prepare and enable.
+*
+* The minimum time, in milliseconds, that needs to have passed
+* between when prepare finished and enable may begin. If at
+* enable time less time has passed since prepare finished,
+* the driver waits for the remaining time.
+*
+* If a fixed enable delay is also specified, we'll start
+* counting before delaying for the fixed delay.
+*
+* If a fixed prepare delay is also specified, we won't start
+* counting until after the fixed delay. We can't overlap this
+* fixed delay with the min time because the fixed delay
+* doesn't happen at the end of the function if a HPD GPIO was
+* specified.
+*
+* In other words:
+* prepare()
+* ...
+* // do fixed prepare delay
+* // wait for HPD GPIO if applicable
+* // start counting for prepare_to_enable
+*
+* enable()
+* // do fixed enable delay
+* // enforce prepare_to_enable min time
+*/
+ unsigned int prepare_to_enable;
+
+ /**
+* @unprepare_to_prepare: Time between unprepare and prepare.
+*
+* The minimum time, in milliseconds, that needs to have passed
+* between when unprepare finished and prepare may begin. If at
+* prepare time less time has passed since unprepare finished,
+* the driver waits for the remaining time.
+*
+* If a fixed unprepare delay is also specified, we'll start
+* counting before delaying for the fixed delay.
+*
+* If a fixed prepare delay is also specified, it will happen
+* separately and after we've enforced this minimum. We can't
+* overlap this fixed delay with the min time because the
+* fixed delay doesn't happen at the start of the function
+* if a regulator or enable GPIO was specified.
+*
+* In other words:
+* unprepare():
+* ...
+* // start counting for unprepare_to_prepare
+* // do fixed unprepare delay
+*
+
Re: [PATCH] drm/gma500: Remove GTT roll support
On Wed, Oct 28, 2020 at 4:41 PM Daniel Vetter wrote:
>
> On Wed, Oct 28, 2020 at 3:36 PM Patrik Jakobsson
> wrote:
> >
> > GTT roll support was used to accelerate fb panning on some machines.
> > Unfortunately this never worked properly with multiple monitors and
> > caused issues on others where the framebuffer wouldn't fit in stolen
> > memory. Let's remove it!
> Acked-by: Daniel Vetter
>
> btw I tried to figure out whether the accel code is of any use too,
> and we don't set FBINFO_HWACCEL_COPYAREA, despite that we have an
> accelerated copyarea. So I think we could delete all that code too,
> since essentially unused. And aside of fbcon no one is using these
> acceleration functions anyway.
> -Daniel
Yes, it can also go away. It'll remove quite a bit of code. I'll have a look.
-Patrik
>
> >
> > Signed-off-by: Patrik Jakobsson
> > ---
> > drivers/gpu/drm/gma500/framebuffer.c | 96
> > drivers/gpu/drm/gma500/gtt.c | 52 +--
> > drivers/gpu/drm/gma500/gtt.h | 3 -
> > 3 files changed, 14 insertions(+), 137 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/gma500/framebuffer.c
> > b/drivers/gpu/drm/gma500/framebuffer.c
> > index 5ede24fb44ae..2d64c58607f5 100644
> > --- a/drivers/gpu/drm/gma500/framebuffer.c
> > +++ b/drivers/gpu/drm/gma500/framebuffer.c
> > @@ -76,27 +76,6 @@ static int psbfb_setcolreg(unsigned regno, unsigned red,
> > unsigned green,
> > return 0;
> > }
> >
> > -static int psbfb_pan(struct fb_var_screeninfo *var, struct fb_info *info)
> > -{
> > - struct drm_fb_helper *fb_helper = info->par;
> > - struct drm_framebuffer *fb = fb_helper->fb;
> > - struct drm_device *dev = fb->dev;
> > - struct gtt_range *gtt = to_gtt_range(fb->obj[0]);
> > -
> > - /*
> > -* We have to poke our nose in here. The core fb code assumes
> > -* panning is part of the hardware that can be invoked before
> > -* the actual fb is mapped. In our case that isn't quite true.
> > -*/
> > - if (gtt->npage) {
> > - /* GTT roll shifts in 4K pages, we need to shift the right
> > - number of pages */
> > - int pages = info->fix.line_length >> 12;
> > - psb_gtt_roll(dev, gtt, var->yoffset * pages);
> > - }
> > -return 0;
> > -}
> > -
> > static vm_fault_t psbfb_vm_fault(struct vm_fault *vmf)
> > {
> > struct vm_area_struct *vma = vmf->vma;
> > @@ -176,17 +155,6 @@ static const struct fb_ops psbfb_ops = {
> > .fb_sync = psbfb_sync,
> > };
> >
> > -static const struct fb_ops psbfb_roll_ops = {
> > - .owner = THIS_MODULE,
> > - DRM_FB_HELPER_DEFAULT_OPS,
> > - .fb_setcolreg = psbfb_setcolreg,
> > - .fb_fillrect = drm_fb_helper_cfb_fillrect,
> > - .fb_copyarea = drm_fb_helper_cfb_copyarea,
> > - .fb_imageblit = drm_fb_helper_cfb_imageblit,
> > - .fb_pan_display = psbfb_pan,
> > - .fb_mmap = psbfb_mmap,
> > -};
> > -
> > static const struct fb_ops psbfb_unaccel_ops = {
> > .owner = THIS_MODULE,
> > DRM_FB_HELPER_DEFAULT_OPS,
> > @@ -312,8 +280,6 @@ static int psbfb_create(struct drm_fb_helper *fb_helper,
> > int ret;
> > struct gtt_range *backing;
> > u32 bpp, depth;
> > - int gtt_roll = 0;
> > - int pitch_lines = 0;
> >
> > mode_cmd.width = sizes->surface_width;
> > mode_cmd.height = sizes->surface_height;
> > @@ -324,50 +290,15 @@ static int psbfb_create(struct drm_fb_helper
> > *fb_helper,
> > if (bpp == 24)
> > bpp = 32;
> >
> > - do {
> > - /*
> > -* Acceleration via the GTT requires pitch to be
> > -* power of two aligned. Preferably page but less
> > -* is ok with some fonts
> > -*/
> > - mode_cmd.pitches[0] = ALIGN(mode_cmd.width * ((bpp + 7) /
> > 8), 4096 >> pitch_lines);
> > -
> > - size = mode_cmd.pitches[0] * mode_cmd.height;
> > - size = ALIGN(size, PAGE_SIZE);
> > -
> > - /* Allocate the fb in the GTT with stolen page backing */
> > - backing = psbfb_alloc(dev, size);
> > -
> > - if (pitch_lines)
> > - pitch_lines *= 2;
> > - else
> > - pitch_lines = 1;
> > - gtt_roll++;
> > - } while (backing == NULL && pitch_lines <= 16);
> > -
> > - /* The final pitch we accepted if we succeeded */
> > - pitch_lines /= 2;
> > -
> > - if (backing == NULL) {
> > - /*
> > -* We couldn't get the space we wanted, fall back to
> > the
> > -* display engine requirement instead. The HW requires
> > -* the pitch to be 64 byte aligned
> > -*/
> > -
> > - gtt_roll = 0; /* Don't use G
Re: linux-next: Signed-off-by missing for commit in the drm-intel-fixes tree
Quoting Stephen Rothwell (2020-10-28 21:28:23)
> Hi all,
>
> Commit
>
> d13208a88f41 ("lockdep: Fix nr_unused_locks")
>
> is missing a Signed-off-by from its author.
>
> Also, the author's email name is missing the leading 'P'.
And it shouldn't be in the drm-intel-fixes tree.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] nouveau broken on Riva TNT2 in 5.9.0-rc8: GPU not supported on big-endian
I sent a patch to the mailing list and wanted to have some review on that from at least Ben, but no idea if Ben already picked it and if it's good enough for sending it to stable yet. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: Signed-off-by missing for commit in the drm-intel-fixes tree
Hi all,
Commit
d13208a88f41 ("lockdep: Fix nr_unused_locks")
is missing a Signed-off-by from its author.
Also, the author's email name is missing the leading 'P'.
--
Cheers,
Stephen Rothwell
pgp1YjPCOl5iy.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: Disable accelerated scrolling
On Wed, Oct 28, 2020 at 7:50 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
> >
> > Now the problem is that most modern-ish drivers really only treat
> > fbcon as an dumb kernel console until userspace takes over, and Oops
> > printer for some emergencies. Looking at drm drivers and the basic
> > vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> > acceleration:
> >
> > - nouveau, seems to be enabled by default
> > - omapdrm, when a DMM remapper exists using remapper rewriting for
> > y/xpanning
> > - gma500, but that is getting deleted now for the GTT remapper trick,
> > and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> > flag, so unused (and could be deleted already I think).
> >
> > No other driver supportes accelerated fbcon. And fbcon is the only
> > user of this accel code (it's not exposed as uapi through ioctls),
> > which means we could garbage collect fairly enormous amounts of code
> > if we kill this.
> >
> > Plus because syzbot only runs on virtual hardware, and none of the
> > drivers for that have acceleration, we'd remove a huge gap in testing.
> > And there's no other even remotely comprehensive testing aside from
> > syzbot.
> >
> > This patch here just disables the acceleration code by always
> > redrawing when scrolling. The plan is that once this has been merged
> > for well over a year in released kernels, we can start to go around
> > and delete a lot of code.
>
> See below for a warning fix.
>
> Some figures from trying to toss accel code out from a few fbdev drivers:
>
> drivers/video/fbdev/cirrusfb.c | 300
> +
> 1 file changed, 4 insertions(+), 296 deletions(-)
>
> drivers/video/fbdev/aty/radeon_accel.c | 174
> -
> drivers/video/fbdev/aty/radeon_base.c | 43 ++--
> drivers/video/fbdev/aty/radeon_pm.c| 7 --
> drivers/video/fbdev/aty/radeonfb.h | 3 -
> 4 files changed, 7 insertions(+), 220 deletions(-)
>
> This may open up the discussion if the right course of action would be
> to drop the drivers in favour of drm counterparts - but thats another
> story.
Yeah I think we can start deleting drivers for which we have drm
drivers which are mostly feature parity and see whether anyone pipes
up. There's always going to be the odd corner case (like apparently
the fbdev ati driver works better on some ppc machines than the drm
one).
The thing is, we can't delete the entire accel code with this, I think
only fb_copyarea goes away. The other hooks I think still have some
users.
-Daniel
>
> Sam
>
> > @@ -1961,7 +1963,6 @@ static void updatescrollmode(struct fbcon_display *p,
> > {
> > struct fbcon_ops *ops = info->fbcon_par;
> > int fh = vc->vc_font.height;
> > - int cap = info->flags;
> > u16 t = 0;
> > int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> > info->fix.xpanstep);
> > @@ -1969,37 +1970,12 @@ static void updatescrollmode(struct fbcon_display
> > *p,
> > int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> > int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> > info->var.xres_virtual);
> > - int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> > - divides(ypan, vc->vc_font.height) && vyres > yres;
> > - int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> > - divides(ywrap, vc->vc_font.height) &&
> > - divides(vc->vc_font.height, vyres) &&
> > - divides(vc->vc_font.height, yres);
> > - int reading_fast = cap & FBINFO_READS_FAST;
> > - int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> > - !(cap & FBINFO_HWACCEL_DISABLED);
> > - int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> > - !(cap & FBINFO_HWACCEL_DISABLED);
>
> Some bot will likely tell you that this causes warnings.
> At least it did in my sparc64 build.
>
> Fix:
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 398914e035e9..e8b009c621d8 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2150,10 +2150,6 @@ static void updatescrollmode(struct fbcon_display *p,
> {
> struct fbcon_ops *ops = info->fbcon_par;
> int fh = vc->vc_font.height;
> - u16 t = 0;
> - int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> - info->fix.xpanstep);
> - int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> int vyres = FBCON_SWAP(ops
Re: [PATCH] fbcon: Disable accelerated scrolling
On Wed, Oct 28, 2020 at 8:02 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 28.10.20 um 17:06 schrieb Daniel Vetter:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
> >
> > Now the problem is that most modern-ish drivers really only treat
> > fbcon as an dumb kernel console until userspace takes over, and Oops
> > printer for some emergencies. Looking at drm drivers and the basic
> > vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> > acceleration:
> >
> > - nouveau, seems to be enabled by default
> > - omapdrm, when a DMM remapper exists using remapper rewriting for
> > y/xpanning
> > - gma500, but that is getting deleted now for the GTT remapper trick,
> > and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> > flag, so unused (and could be deleted already I think).
> >
> > No other driver supportes accelerated fbcon. And fbcon is the only
> > user of this accel code (it's not exposed as uapi through ioctls),
> > which means we could garbage collect fairly enormous amounts of code
> > if we kill this.
> >
> > Plus because syzbot only runs on virtual hardware, and none of the
> > drivers for that have acceleration, we'd remove a huge gap in testing.
> > And there's no other even remotely comprehensive testing aside from
> > syzbot.
> >
> > This patch here just disables the acceleration code by always
> > redrawing when scrolling. The plan is that once this has been merged
> > for well over a year in released kernels, we can start to go around
> > and delete a lot of code.
>
> Why wait a year? I'd say delete early, delete often. ;)
>
> >
> > Cc: Bartlomiej Zolnierkiewicz
> > Cc: Greg Kroah-Hartman
> > Cc: Linus Torvalds
> > Cc: Ben Skeggs
> > Cc: nouv...@lists.freedesktop.org
> > Cc: Tomi Valkeinen
> > Cc: Daniel Vetter
> > Cc: Jiri Slaby
> > Cc: "Gustavo A. R. Silva"
> > Cc: Tetsuo Handa
> > Cc: Peilin Ye
> > Cc: George Kennedy
> > Cc: Nathan Chancellor
> > Cc: Peter Rosin
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/video/fbdev/core/fbcon.c | 38 ++--
> > 1 file changed, 7 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index cef437817b0d..d74ccbbb29bb 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -1147,11 +1147,13 @@ static void fbcon_init(struct vc_data *vc, int init)
> >
> > ops->graphics = 0;
> >
> > - if ((cap & FBINFO_HWACCEL_COPYAREA) &&
> > - !(cap & FBINFO_HWACCEL_DISABLED))
> > - p->scrollmode = SCROLL_MOVE;
> > - else /* default to something safe */
> > - p->scrollmode = SCROLL_REDRAW;
> > + /*
> > + * No more hw acceleration for fbcon.
> > + *
> > + * FIXME: Garabge collect all the now dead code after sufficient time
> > + * has passed.
> > + */
> > + p->scrollmode = SCROLL_REDRAW;
>
> I just grepped for scrollmode and there aren't many places that use it.
> Could you remove it as well?
Removing scrollmode will start the delete feast. In fbcon alone I
think we can drop half the code.
-Daniel
>
> In any case
>
> Reviewed-by: Thomas Zimmermann
>
> Best regards
> Thomas
>
> >
> > /*
> >* ++guenther: console.c:vc_allocate() relies on initializing
> > @@ -1961,7 +1963,6 @@ static void updatescrollmode(struct fbcon_display *p,
> > {
> > struct fbcon_ops *ops = info->fbcon_par;
> > int fh = vc->vc_font.height;
> > - int cap = info->flags;
> > u16 t = 0;
> > int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> > info->fix.xpanstep);
> > @@ -1969,37 +1970,12 @@ static void updatescrollmode(struct fbcon_display
> > *p,
> > int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> > int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> > info->var.xres_virtual);
> > - int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> > - divides(ypan, vc->vc_font.height) && vyres > yres;
> > - int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> > - divides(ywrap, vc->vc_font.height) &&
> > - divides(vc->vc_font.height, vyres) &&
> > - divides(vc->vc_font.height, yres);
> > - int reading_fast = cap & FBINFO_READS_FAST;
> > - int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> > - !(cap & FBINFO_HWACCEL_DISABLED);
> > - int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> > - !(cap & FBINFO_HWACCEL_DISABLED);
> >
> > p->vrows = vyres/fh;
> > if (yres > (fh * (vc->vc_rows + 1)))
> > p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
> > if ((yres % fh) && (vyres % fh < yres % fh))
> >
Re: [PATCH] drm: Remove SCATTERLIST_MAX_SEGMENT
On Wed, Oct 28, 2020 at 04:15:26PM -0300, Jason Gunthorpe wrote:
> Since commit 9a40401cfa13 ("lib/scatterlist: Do not limit max_segment to
> PAGE_ALIGNED values") the max_segment input to sg_alloc_table_from_pages()
> does not have to be any special value. The new algorithm will always
> create something less than what the user provides. Thus eliminate this
> confusing constant.
>
> - vmwgfx should use the HW capability, not mix in the OS page size for
> calling dma_set_max_seg_size()
>
> - i915 uses i915_sg_segment_size() both for sg_alloc_table_from_pages
> and for some open coded sgl construction. This doesn't change the value
> since rounddown(size, UINT_MAX) == SCATTERLIST_MAX_SEGMENT
>
> - drm_prime_pages_to_sg uses it as a default if max_segment is zero,
> UINT_MAX is fine to use directly.
>
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: Thomas Hellstrom
> Cc: Qian Cai
> Cc: "Ursulin, Tvrtko"
> Suggested-by: Christoph Hellwig
> Signed-off-by: Jason Gunthorpe
lgtm. Do you want to push this through some other queue, or should I put
this into drm trees? Prefer 5.10 or 5.11?
If you want to merge this Acked-by: Daniel Vetter
-Daniel
> ---
> drivers/gpu/drm/drm_prime.c | 4 ++--
> drivers/gpu/drm/i915/i915_scatterlist.h | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +--
> include/linux/scatterlist.h | 6 --
> tools/testing/scatterlist/main.c| 2 +-
> 5 files changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index d6808f678db541..c3693e5e8b74b0 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -816,8 +816,8 @@ struct sg_table *drm_prime_pages_to_sg(struct drm_device
> *dev,
>
> if (dev)
> max_segment = dma_max_mapping_size(dev->dev);
> - if (max_segment == 0 || max_segment > SCATTERLIST_MAX_SEGMENT)
> - max_segment = SCATTERLIST_MAX_SEGMENT;
> + if (max_segment == 0)
> + max_segment = UINT_MAX;
> sge = __sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
> nr_pages << PAGE_SHIFT,
> max_segment,
> diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
> b/drivers/gpu/drm/i915/i915_scatterlist.h
> index b7b59328cb76ab..883dd8d09d6bf2 100644
> --- a/drivers/gpu/drm/i915/i915_scatterlist.h
> +++ b/drivers/gpu/drm/i915/i915_scatterlist.h
> @@ -112,7 +112,7 @@ static inline unsigned int i915_sg_segment_size(void)
> unsigned int size = swiotlb_max_segment();
>
> if (size == 0)
> - return SCATTERLIST_MAX_SEGMENT;
> + size = UINT_MAX;
>
> size = rounddown(size, PAGE_SIZE);
> /* swiotlb_max_segment_size can return 1 byte when it means one page. */
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 31e3e5c9f36223..c1817f1a3006e0 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -792,8 +792,7 @@ static int vmw_driver_load(struct drm_device *dev,
> unsigned long chipset)
> if (unlikely(ret != 0))
> goto out_err0;
>
> - dma_set_max_seg_size(dev->dev, min_t(unsigned int, U32_MAX & PAGE_MASK,
> - SCATTERLIST_MAX_SEGMENT));
> + dma_set_max_seg_size(dev->dev, U32_MAX);
>
> if (dev_priv->capabilities & SVGA_CAP_GMR2) {
> DRM_INFO("Max GMR ids is %u\n",
> diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
> index 36c47e7e66a203..6f70572b2938be 100644
> --- a/include/linux/scatterlist.h
> +++ b/include/linux/scatterlist.h
> @@ -18,12 +18,6 @@ struct scatterlist {
> #endif
> };
>
> -/*
> - * Since the above length field is an unsigned int, below we define the
> maximum
> - * length in bytes that can be stored in one scatterlist entry.
> - */
> -#define SCATTERLIST_MAX_SEGMENT (UINT_MAX & PAGE_MASK)
> -
> /*
> * These macros should be used after a dma_map_sg call has been done
> * to get bus addresses of each of the SG entries and their lengths.
> diff --git a/tools/testing/scatterlist/main.c
> b/tools/testing/scatterlist/main.c
> index b2c7e9f7b8d3dc..d264bf853034bd 100644
> --- a/tools/testing/scatterlist/main.c
> +++ b/tools/testing/scatterlist/main.c
> @@ -50,7 +50,7 @@ static void fail(struct test *test, struct sg_table *st,
> const char *cond)
>
> int main(void)
> {
> - const unsigned int sgmax = SCATTERLIST_MAX_SEGMENT;
> + const unsigned int sgmax = UINT_MAX;
> struct test *test, tests[] = {
> { -EINVAL, 1, pfn(0), PAGE_SIZE, PAGE_SIZE + 1, 1 },
> { -EINVAL, 1, pfn(0), PAGE_SIZE, 0, 1 },
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.fre
[PATCH v6 03/10] drm/etnaviv: Remove empty etnaviv_gem_prime_vunmap()
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 5 -
3 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 914f0867ff71..9682c26d89bb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -52,7 +52,6 @@ int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct
*vma);
int etnaviv_gem_mmap_offset(struct drm_gem_object *obj, u64 *offset);
struct sg_table *etnaviv_gem_prime_get_sg_table(struct drm_gem_object *obj);
void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj);
-void etnaviv_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
int etnaviv_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
struct drm_gem_object *etnaviv_gem_prime_import_sg_table(struct drm_device
*dev,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 67d9a2b9ea6a..bbd235473645 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -571,7 +571,6 @@ static const struct drm_gem_object_funcs
etnaviv_gem_object_funcs = {
.unpin = etnaviv_gem_prime_unpin,
.get_sg_table = etnaviv_gem_prime_get_sg_table,
.vmap = etnaviv_gem_prime_vmap,
- .vunmap = etnaviv_gem_prime_vunmap,
.vm_ops = &vm_ops,
};
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index 135fbff6fecf..a6d9932a32ae 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -27,11 +27,6 @@ void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj)
return etnaviv_gem_vmap(obj);
}
-void etnaviv_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
-{
- /* TODO msm_gem_vunmap() */
-}
-
int etnaviv_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma)
{
--
2.29.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 06/10] drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory,
either system or I/O memory. GEM VRAM helpers and qxl now use ttm_bo_vmap()
et al. Amdgpu, nouveau and radeon use drm_gem_ttm_vmap() et al instead of
implementing their own vmap callbacks.
v5:
* update vkms after switch to shmem
v4:
* use ttm_bo_vmap(), drm_gem_ttm_vmap(), et al. (Daniel, Christian)
* fix a trailing { in drm_gem_vmap()
* remove several empty functions instead of converting them (Daniel)
* comment uses of raw pointers with a TODO (Daniel)
* TODO list: convert more helpers to use struct dma_buf_map
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Tested-by: Sam Ravnborg
---
Documentation/gpu/todo.rst | 18
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 36 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/ast/ast_cursor.c| 27 +++--
drivers/gpu/drm/ast/ast_drv.h | 7 +-
drivers/gpu/drm/drm_gem.c | 23 +++--
drivers/gpu/drm/drm_gem_cma_helper.c| 10 +-
drivers/gpu/drm/drm_gem_shmem_helper.c | 48 +
drivers/gpu/drm/drm_gem_vram_helper.c | 107 ++--
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 9 +-
drivers/gpu/drm/lima/lima_gem.c | 6 +-
drivers/gpu/drm/lima/lima_sched.c | 11 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
drivers/gpu/drm/nouveau/Kconfig | 1 +
drivers/gpu/drm/nouveau/nouveau_bo.h| 2 -
drivers/gpu/drm/nouveau/nouveau_gem.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_gem.h | 2 -
drivers/gpu/drm/nouveau/nouveau_prime.c | 20
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 14 +--
drivers/gpu/drm/qxl/qxl_display.c | 11 +-
drivers/gpu/drm/qxl/qxl_draw.c | 14 ++-
drivers/gpu/drm/qxl/qxl_drv.h | 11 +-
drivers/gpu/drm/qxl/qxl_object.c| 31 +++---
drivers/gpu/drm/qxl/qxl_object.h| 2 +-
drivers/gpu/drm/qxl/qxl_prime.c | 12 +--
drivers/gpu/drm/radeon/radeon.h | 1 -
drivers/gpu/drm/radeon/radeon_gem.c | 7 +-
drivers/gpu/drm/radeon/radeon_prime.c | 20
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 22 ++--
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 4 +-
drivers/gpu/drm/tiny/cirrus.c | 10 +-
drivers/gpu/drm/tiny/gm12u320.c | 10 +-
drivers/gpu/drm/udl/udl_modeset.c | 8 +-
drivers/gpu/drm/vboxvideo/vbox_mode.c | 11 +-
drivers/gpu/drm/vc4/vc4_bo.c| 6 +-
drivers/gpu/drm/vc4/vc4_drv.h | 2 +-
drivers/gpu/drm/vgem/vgem_drv.c | 16 ++-
drivers/gpu/drm/vkms/vkms_plane.c | 15 ++-
drivers/gpu/drm/vkms/vkms_writeback.c | 22 ++--
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 ++--
drivers/gpu/drm/xen/xen_drm_front_gem.h | 6 +-
include/drm/drm_gem.h | 5 +-
include/drm/drm_gem_cma_helper.h| 2 +-
include/drm/drm_gem_shmem_helper.h | 4 +-
include/drm/drm_gem_vram_helper.h | 14 +--
49 files changed, 345 insertions(+), 308 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 700637e25ecd..7e6fc3c04add 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -446,6 +446,24 @@ Contact: Ville Syrjälä, Daniel Vetter
Level: Intermediate
+Use struct dma_buf_map throughout codebase
+--
+
+Pointers to shared device memory are stored in struct dma_buf_map. Each
+instance knows whether it refers to system or I/O memory. Most of the DRM-wide
+interface have been converted to use struct dma_buf_map, but implementations
+often still use raw pointers.
+
+The task is to use struct dma_buf_map where it makes sense.
+
+* Memory managers should use struct dma_buf_map for dma-buf-imported buffers.
+* TTM might benefit from using struct dma_buf_map internally.
+* Framebuffer copying and blitting helpers should operate on struct
dma_buf_map.
+
+Contact: Thomas Zimmermann , Christian König, Daniel
Vetter
+
+Level: Intermediate
+
Core refactorings
=
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 32257189e09b..e479b04e955e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -239,6 +239,7 @@ config DRM_RADEON
select FW_LOADER
select DRM_KMS_HELPER
se
[PATCH v6 07/10] drm/gem: Update internal GEM vmap/vunmap interfaces to use struct dma_buf_map
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client.c | 18 +++---
drivers/gpu/drm/drm_gem.c | 26 +-
drivers/gpu/drm/drm_internal.h | 5 +++--
drivers/gpu/drm/drm_prime.c| 14 --
4 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 495f47d23d87..ac0082bed966 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -3,6 +3,7 @@
* Copyright 2018 Noralf Trønnes
*/
+#include
#include
#include
#include
@@ -304,7 +305,8 @@ drm_client_buffer_create(struct drm_client_dev *client, u32
width, u32 height, u
*/
void *drm_client_buffer_vmap(struct drm_client_buffer *buffer)
{
- void *vaddr;
+ struct dma_buf_map map;
+ int ret;
if (buffer->vaddr)
return buffer->vaddr;
@@ -317,13 +319,13 @@ void *drm_client_buffer_vmap(struct drm_client_buffer
*buffer)
* fd_install step out of the driver backend hooks, to make that
* final step optional for internal users.
*/
- vaddr = drm_gem_vmap(buffer->gem);
- if (IS_ERR(vaddr))
- return vaddr;
+ ret = drm_gem_vmap(buffer->gem, &map);
+ if (ret)
+ return ERR_PTR(ret);
- buffer->vaddr = vaddr;
+ buffer->vaddr = map.vaddr;
- return vaddr;
+ return map.vaddr;
}
EXPORT_SYMBOL(drm_client_buffer_vmap);
@@ -337,7 +339,9 @@ EXPORT_SYMBOL(drm_client_buffer_vmap);
*/
void drm_client_buffer_vunmap(struct drm_client_buffer *buffer)
{
- drm_gem_vunmap(buffer->gem, buffer->vaddr);
+ struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(buffer->vaddr);
+
+ drm_gem_vunmap(buffer->gem, &map);
buffer->vaddr = NULL;
}
EXPORT_SYMBOL(drm_client_buffer_vunmap);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index a89ad4570e3c..4d5fff4bd821 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1206,32 +1206,32 @@ void drm_gem_unpin(struct drm_gem_object *obj)
obj->funcs->unpin(obj);
}
-void *drm_gem_vmap(struct drm_gem_object *obj)
+int drm_gem_vmap(struct drm_gem_object *obj, struct dma_buf_map *map)
{
- struct dma_buf_map map;
int ret;
if (!obj->funcs->vmap)
- return ERR_PTR(-EOPNOTSUPP);
+ return -EOPNOTSUPP;
- ret = obj->funcs->vmap(obj, &map);
+ ret = obj->funcs->vmap(obj, map);
if (ret)
- return ERR_PTR(ret);
- else if (dma_buf_map_is_null(&map))
- return ERR_PTR(-ENOMEM);
+ return ret;
+ else if (dma_buf_map_is_null(map))
+ return -ENOMEM;
- return map.vaddr;
+ return 0;
}
-void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr)
+void drm_gem_vunmap(struct drm_gem_object *obj, struct dma_buf_map *map)
{
- struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(vaddr);
-
- if (!vaddr)
+ if (dma_buf_map_is_null(map))
return;
if (obj->funcs->vunmap)
- obj->funcs->vunmap(obj, &map);
+ obj->funcs->vunmap(obj, map);
+
+ /* Always set the mapping to NULL. Callers may rely on this. */
+ dma_buf_map_clear(map);
}
/**
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 2bdac3557765..81d386b5b92a 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -33,6 +33,7 @@
struct dentry;
struct dma_buf;
+struct dma_buf_map;
struct drm_connector;
struct drm_crtc;
struct drm_framebuffer;
@@ -187,8 +188,8 @@ void drm_gem_print_info(struct drm_printer *p, unsigned int
indent,
int drm_gem_pin(struct drm_gem_object *obj);
void drm_gem_unpin(struct drm_gem_object *obj);
-void *drm_gem_vmap(struct drm_gem_object *obj);
-void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr);
+int drm_gem_vmap(struct drm_gem_object *obj, struct dma_buf_map *map);
+void drm_gem_vunmap(struct drm_gem_object *obj, struct dma_buf_map *map);
/* drm_debugfs.c drm_debugfs_crc.c */
#if defined(CONFIG_DEBUG_FS)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 89e2a2496734..cb8fbeeb731b 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -667,21 +667,15 @@ EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
*
* Sets up a kernel virtual mapping. This can be used as the &dma_buf_ops.vmap
* callback. Calls into &drm_gem_object_funcs.vmap for device specific
handling.
+ * The kernel virtual address is returned in map.
*
- * Returns the kernel virtual address or NULL on failure.
+ * Returns 0 on success or a negative errno code otherwise.
*/
int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map *map)
{
[PATCH v6 01/10] drm/vram-helper: Remove invariant parameters from internal kmap function
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Reviewed-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_gem_vram_helper.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 9da823eb0edd..f445b84c43c4 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -379,32 +379,22 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
}
EXPORT_SYMBOL(drm_gem_vram_unpin);
-static void *drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo,
- bool map, bool *is_iomem)
+static void *drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo)
{
int ret;
struct ttm_bo_kmap_obj *kmap = &gbo->kmap;
+ bool is_iomem;
if (gbo->kmap_use_count > 0)
goto out;
- if (kmap->virtual || !map)
- goto out;
-
ret = ttm_bo_kmap(&gbo->bo, 0, gbo->bo.num_pages, kmap);
if (ret)
return ERR_PTR(ret);
out:
- if (!kmap->virtual) {
- if (is_iomem)
- *is_iomem = false;
- return NULL; /* not mapped; don't increment ref */
- }
++gbo->kmap_use_count;
- if (is_iomem)
- return ttm_kmap_obj_virtual(kmap, is_iomem);
- return kmap->virtual;
+ return ttm_kmap_obj_virtual(kmap, &is_iomem);
}
static void drm_gem_vram_kunmap_locked(struct drm_gem_vram_object *gbo)
@@ -449,7 +439,7 @@ void *drm_gem_vram_vmap(struct drm_gem_vram_object *gbo)
ret = drm_gem_vram_pin_locked(gbo, 0);
if (ret)
goto err_ttm_bo_unreserve;
- base = drm_gem_vram_kmap_locked(gbo, true, NULL);
+ base = drm_gem_vram_kmap_locked(gbo);
if (IS_ERR(base)) {
ret = PTR_ERR(base);
goto err_drm_gem_vram_unpin_locked;
--
2.29.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's location ani/or writecombine flags.
On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(),
two helpers that convert a GEM object into the TTM BO and forward the call
to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object
callbacks.
v5:
* use size_t for storing mapping size (Christian)
* ignore premapped memory areas correctly in ttm_bo_vunmap()
* rebase onto latest TTM interfaces (Christian)
* remove BUG() from ttm_bo_vmap() (Christian)
v4:
* drop ttm_kmap_obj_to_dma_buf() in favor of vmap helpers (Daniel,
Christian)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Acked-by: Daniel Vetter
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++
drivers/gpu/drm/ttm/ttm_bo_util.c| 72
include/drm/drm_gem_ttm_helper.h | 6 +++
include/drm/ttm/ttm_bo_api.h | 28 +++
include/linux/dma-buf-map.h | 20
5 files changed, 164 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
b/drivers/gpu/drm/drm_gem_ttm_helper.c
index 0e4fb9ba43ad..db4c14d78a30 100644
--- a/drivers/gpu/drm/drm_gem_ttm_helper.c
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -49,6 +49,44 @@ void drm_gem_ttm_print_info(struct drm_printer *p, unsigned
int indent,
}
EXPORT_SYMBOL(drm_gem_ttm_print_info);
+/**
+ * drm_gem_ttm_vmap() - vmap &ttm_buffer_object
+ * @gem: GEM object.
+ * @map: [out] returns the dma-buf mapping.
+ *
+ * Maps a GEM object with ttm_bo_vmap(). This function can be used as
+ * &drm_gem_object_funcs.vmap callback.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int drm_gem_ttm_vmap(struct drm_gem_object *gem,
+struct dma_buf_map *map)
+{
+ struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ return ttm_bo_vmap(bo, map);
+
+}
+EXPORT_SYMBOL(drm_gem_ttm_vmap);
+
+/**
+ * drm_gem_ttm_vunmap() - vunmap &ttm_buffer_object
+ * @gem: GEM object.
+ * @map: dma-buf mapping.
+ *
+ * Unmaps a GEM object with ttm_bo_vunmap(). This function can be used as
+ * &drm_gem_object_funcs.vmap callback.
+ */
+void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
+ struct dma_buf_map *map)
+{
+ struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ ttm_bo_vunmap(bo, map);
+}
+EXPORT_SYMBOL(drm_gem_ttm_vunmap);
+
/**
* drm_gem_ttm_mmap() - mmap &ttm_buffer_object
* @gem: GEM object.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ecb54415d1ca..7ccb2295cac1 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -471,6 +472,77 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
}
EXPORT_SYMBOL(ttm_bo_kunmap);
+int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ struct ttm_resource *mem = &bo->mem;
+ int ret;
+
+ ret = ttm_mem_io_reserve(bo->bdev, mem);
+ if (ret)
+ return ret;
+
+ if (mem->bus.is_iomem) {
+ void __iomem *vaddr_iomem;
+ size_t size = bo->num_pages << PAGE_SHIFT;
+
+ if (mem->bus.addr)
+ vaddr_iomem = (void __iomem *)mem->bus.addr;
+ else if (mem->bus.caching == ttm_write_combined)
+ vaddr_iomem = ioremap_wc(mem->bus.offset, size);
+ else
+ vaddr_iomem = ioremap(mem->bus.offset, size);
+
+ if (!vaddr_iomem)
+ return -ENOMEM;
+
+ dma_buf_map_set_vaddr_iomem(map, vaddr_iomem);
+
+ } else {
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
+ struct ttm_tt *ttm = bo->ttm;
+ pgprot_t prot;
+ void *vaddr;
+
+ ret = ttm_tt_populate(bo->bdev, ttm, &ctx);
+ if (ret)
+ return ret;
+
+ /*
+* We need to use vmap to get the desired page protection
+* or to make the buffer object look contiguous.
+*/
+ prot = ttm_io_prot(bo, mem, PAGE_KERNEL);
+ vaddr = vmap(ttm->pages, bo->num_pages, 0, prot);
+ if (!vaddr)
+ return -ENOMEM;
+
+ dma_buf_map_set_vaddr(map, vaddr);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(ttm_bo_vmap);
+
+void ttm_bo_vunmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ s
[PATCH v6 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
To do framebuffer updates, one needs memcpy from system memory and a
pointer-increment function. Add both interfaces with documentation.
v5:
* include to build on sparc64 (Sam)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
Tested-by: Sam Ravnborg
---
include/linux/dma-buf-map.h | 73 -
1 file changed, 63 insertions(+), 10 deletions(-)
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
index 2e8bbecb5091..583a3a1f9447 100644
--- a/include/linux/dma-buf-map.h
+++ b/include/linux/dma-buf-map.h
@@ -7,6 +7,7 @@
#define __DMA_BUF_MAP_H__
#include
+#include
/**
* DOC: overview
@@ -32,6 +33,14 @@
* accessing the buffer. Use the returned instance and the helper functions
* to access the buffer's memory in the correct way.
*
+ * The type :c:type:`struct dma_buf_map ` and its helpers are
+ * actually independent from the dma-buf infrastructure. When sharing buffers
+ * among devices, drivers have to know the location of the memory to access
+ * the buffers in a safe way. :c:type:`struct dma_buf_map `
+ * solves this problem for dma-buf and its users. If other drivers or
+ * sub-systems require similar functionality, the type could be generalized
+ * and moved to a more prominent header file.
+ *
* Open-coding access to :c:type:`struct dma_buf_map ` is
* considered bad style. Rather then accessing its fields directly, use one
* of the provided helper functions, or implement your own. For example,
@@ -51,6 +60,14 @@
*
* dma_buf_map_set_vaddr_iomem(&map. 0xdeadbeaf);
*
+ * Instances of struct dma_buf_map do not have to be cleaned up, but
+ * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
+ * always refer to system memory.
+ *
+ * .. code-block:: c
+ *
+ * dma_buf_map_clear(&map);
+ *
* Test if a mapping is valid with either dma_buf_map_is_set() or
* dma_buf_map_is_null().
*
@@ -73,17 +90,19 @@
* if (dma_buf_map_is_equal(&sys_map, &io_map))
* // always false
*
- * Instances of struct dma_buf_map do not have to be cleaned up, but
- * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
- * always refer to system memory.
+ * A set up instance of struct dma_buf_map can be used to access or manipulate
+ * the buffer memory. Depending on the location of the memory, the provided
+ * helpers will pick the correct operations. Data can be copied into the memory
+ * with dma_buf_map_memcpy_to(). The address can be manipulated with
+ * dma_buf_map_incr().
*
- * The type :c:type:`struct dma_buf_map ` and its helpers are
- * actually independent from the dma-buf infrastructure. When sharing buffers
- * among devices, drivers have to know the location of the memory to access
- * the buffers in a safe way. :c:type:`struct dma_buf_map `
- * solves this problem for dma-buf and its users. If other drivers or
- * sub-systems require similar functionality, the type could be generalized
- * and moved to a more prominent header file.
+ * .. code-block:: c
+ *
+ * const void *src = ...; // source buffer
+ * size_t len = ...; // length of src
+ *
+ * dma_buf_map_memcpy_to(&map, src, len);
+ * dma_buf_map_incr(&map, len); // go to first byte after the memcpy
*/
/**
@@ -210,4 +229,38 @@ static inline void dma_buf_map_clear(struct dma_buf_map
*map)
}
}
+/**
+ * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
+ * @dst: The dma-buf mapping structure
+ * @src: The source buffer
+ * @len: The number of byte in src
+ *
+ * Copies data into a dma-buf mapping. The source buffer is in system
+ * memory. Depending on the buffer's location, the helper picks the correct
+ * method of accessing the memory.
+ */
+static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const void
*src, size_t len)
+{
+ if (dst->is_iomem)
+ memcpy_toio(dst->vaddr_iomem, src, len);
+ else
+ memcpy(dst->vaddr, src, len);
+}
+
+/**
+ * dma_buf_map_incr - Increments the address stored in a dma-buf mapping
+ * @map: The dma-buf mapping structure
+ * @incr: The number of bytes to increment
+ *
+ * Increments the address stored in a dma-buf mapping. Depending on the
+ * buffer's location, the correct value will be updated.
+ */
+static inline void dma_buf_map_incr(struct dma_buf_map *map, size_t incr)
+{
+ if (map->is_iomem)
+ map->vaddr_iomem += incr;
+ else
+ map->vaddr += incr;
+}
+
#endif /* __DMA_BUF_MAP_H__ */
--
2.29.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 08/10] drm/gem: Store client buffer mappings as struct dma_buf_map
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and modified with
dma_buf_map interfaces.
v6:
* don't call page_to_phys() on framebuffers in I/O memory;
warn instead (Daniel)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client.c| 34 +++--
drivers/gpu/drm/drm_fb_helper.c | 32 ---
include/drm/drm_client.h| 7 ---
3 files changed, 45 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index ac0082bed966..fe573acf1067 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -235,7 +235,7 @@ static void drm_client_buffer_delete(struct
drm_client_buffer *buffer)
{
struct drm_device *dev = buffer->client->dev;
- drm_gem_vunmap(buffer->gem, buffer->vaddr);
+ drm_gem_vunmap(buffer->gem, &buffer->map);
if (buffer->gem)
drm_gem_object_put(buffer->gem);
@@ -291,25 +291,31 @@ drm_client_buffer_create(struct drm_client_dev *client,
u32 width, u32 height, u
/**
* drm_client_buffer_vmap - Map DRM client buffer into address space
* @buffer: DRM client buffer
+ * @map_copy: Returns the mapped memory's address
*
* This function maps a client buffer into kernel address space. If the
- * buffer is already mapped, it returns the mapping's address.
+ * buffer is already mapped, it returns the existing mapping's address.
*
* Client buffer mappings are not ref'counted. Each call to
* drm_client_buffer_vmap() should be followed by a call to
* drm_client_buffer_vunmap(); or the client buffer should be mapped
* throughout its lifetime.
*
+ * The returned address is a copy of the internal value. In contrast to
+ * other vmap interfaces, you don't need it for the client's vunmap
+ * function. So you can modify it at will during blit and draw operations.
+ *
* Returns:
- * The mapped memory's address
+ * 0 on success, or a negative errno code otherwise.
*/
-void *drm_client_buffer_vmap(struct drm_client_buffer *buffer)
+int
+drm_client_buffer_vmap(struct drm_client_buffer *buffer, struct dma_buf_map
*map_copy)
{
- struct dma_buf_map map;
+ struct dma_buf_map *map = &buffer->map;
int ret;
- if (buffer->vaddr)
- return buffer->vaddr;
+ if (dma_buf_map_is_set(map))
+ goto out;
/*
* FIXME: The dependency on GEM here isn't required, we could
@@ -319,13 +325,14 @@ void *drm_client_buffer_vmap(struct drm_client_buffer
*buffer)
* fd_install step out of the driver backend hooks, to make that
* final step optional for internal users.
*/
- ret = drm_gem_vmap(buffer->gem, &map);
+ ret = drm_gem_vmap(buffer->gem, map);
if (ret)
- return ERR_PTR(ret);
+ return ret;
- buffer->vaddr = map.vaddr;
+out:
+ *map_copy = *map;
- return map.vaddr;
+ return 0;
}
EXPORT_SYMBOL(drm_client_buffer_vmap);
@@ -339,10 +346,9 @@ EXPORT_SYMBOL(drm_client_buffer_vmap);
*/
void drm_client_buffer_vunmap(struct drm_client_buffer *buffer)
{
- struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(buffer->vaddr);
+ struct dma_buf_map *map = &buffer->map;
- drm_gem_vunmap(buffer->gem, &map);
- buffer->vaddr = NULL;
+ drm_gem_vunmap(buffer->gem, map);
}
EXPORT_SYMBOL(drm_client_buffer_vunmap);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index c2f72bb6afb1..6ce0b9119ef2 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -378,7 +378,7 @@ static void drm_fb_helper_dirty_blit_real(struct
drm_fb_helper *fb_helper,
unsigned int cpp = fb->format->cpp[0];
size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
void *src = fb_helper->fbdev->screen_buffer + offset;
- void *dst = fb_helper->buffer->vaddr + offset;
+ void *dst = fb_helper->buffer->map.vaddr + offset;
size_t len = (clip->x2 - clip->x1) * cpp;
unsigned int y;
@@ -400,7 +400,8 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
struct drm_clip_rect *clip = &helper->dirty_clip;
struct drm_clip_rect clip_copy;
unsigned long flags;
- void *vaddr;
+ struct dma_buf_map map;
+ int ret;
spin_lock_irqsave(&helper->dirty_lock, flags);
clip_copy = *clip;
@@ -413,8 +414,8 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
/* Generic fbdev uses a shadow buffer */
if (helper->buffer) {
- vaddr
[PATCH v6 02/10] drm/cma-helper: Remove empty drm_gem_cma_prime_vunmap()
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 -
drivers/gpu/drm/vc4/vc4_bo.c | 1 -
include/drm/drm_gem_cma_helper.h | 1 -
3 files changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 2165633c9b9e..d527485ea0b7 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -537,23 +537,6 @@ void *drm_gem_cma_prime_vmap(struct drm_gem_object *obj)
}
EXPORT_SYMBOL_GPL(drm_gem_cma_prime_vmap);
-/**
- * drm_gem_cma_prime_vunmap - unmap a CMA GEM object from the kernel's virtual
- * address space
- * @obj: GEM object
- * @vaddr: kernel virtual address where the CMA GEM object was mapped
- *
- * This function removes a buffer exported via DRM PRIME from the kernel's
- * virtual address space. This is a no-op because CMA buffers cannot be
- * unmapped from kernel space. Drivers using the CMA helpers should set this
- * as their &drm_gem_object_funcs.vunmap callback.
- */
-void drm_gem_cma_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
-{
- /* Nothing to do */
-}
-EXPORT_SYMBOL_GPL(drm_gem_cma_prime_vunmap);
-
static const struct drm_gem_object_funcs drm_gem_cma_default_funcs = {
.free = drm_gem_cma_free_object,
.print_info = drm_gem_cma_print_info,
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index f432278173cd..557f0d1e6437 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -387,7 +387,6 @@ static const struct drm_gem_object_funcs
vc4_gem_object_funcs = {
.export = vc4_prime_export,
.get_sg_table = drm_gem_cma_prime_get_sg_table,
.vmap = vc4_prime_vmap,
- .vunmap = drm_gem_cma_prime_vunmap,
.vm_ops = &vc4_vm_ops,
};
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 2bfa2502607a..a064b0d1c480 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -104,7 +104,6 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
void *drm_gem_cma_prime_vmap(struct drm_gem_object *obj);
-void drm_gem_cma_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
struct drm_gem_object *
drm_gem_cma_create_object_default_funcs(struct drm_device *dev, size_t size);
--
2.29.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 00/10] Support GEM object mappings from I/O memory
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to forward pointers
of type struct dma_buf_map and updates the generic fbdev emulation to
use them correctly. This enables I/O-memory operations on all framebuffers
that require and support them.
Patches #1 to #4 prepare VRAM helpers and drivers.
Next is the update of the GEM vmap functions. Patch #5 adds vmap and vunmap
that is usable with TTM-based GEM drivers, and patch #6 updates GEM's
vmap/vunmap callback to forward instances of type struct dma_buf_map. While
the patch touches many files throughout the DRM modules, the applied changes
are mostly trivial interface fixes. Several TTM-based GEM drivers now use
the new vmap code. Patch #7 updates GEM's internal vmap/vunmap functions to
forward struct dma_buf_map.
With struct dma_buf_map propagated through the layers, patches #8 to #10
convert DRM clients and generic fbdev emulation to use it. Updating the
fbdev framebuffer will select the correct functions, either for system or
I/O memory.
v6:
* don't call page_to_phys() on fbdev framebuffers in I/O memory;
warn instead (Daniel)
v5:
* rebase onto latest TTM changes (Christian)
* support TTM premapped memory correctly (Christian)
* implement fb_read/fb_write internally (Sam, Daniel)
* cleanups
v4:
* provide TTM vmap/vunmap plus GEM helpers and convert drivers
over (Christian, Daniel)
* remove several empty functions
* more TODOs and documentation (Daniel)
v3:
* recreate the whole patchset on top of struct dma_buf_map
v2:
* RFC patchset
Thomas Zimmermann (10):
drm/vram-helper: Remove invariant parameters from internal kmap
function
drm/cma-helper: Remove empty drm_gem_cma_prime_vunmap()
drm/etnaviv: Remove empty etnaviv_gem_prime_vunmap()
drm/exynos: Remove empty exynos_drm_gem_prime_{vmap,vunmap}()
drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM
backends
drm/gem: Update internal GEM vmap/vunmap interfaces to use struct
dma_buf_map
drm/gem: Store client buffer mappings as struct dma_buf_map
dma-buf-map: Add memcpy and pointer-increment interfaces
drm/fb_helper: Support framebuffers in I/O memory
Documentation/gpu/todo.rst | 37 ++-
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 36 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/ast/ast_cursor.c| 27 +-
drivers/gpu/drm/ast/ast_drv.h | 7 +-
drivers/gpu/drm/bochs/bochs_kms.c | 1 -
drivers/gpu/drm/drm_client.c| 38 +--
drivers/gpu/drm/drm_fb_helper.c | 257 ++--
drivers/gpu/drm/drm_gem.c | 29 ++-
drivers/gpu/drm/drm_gem_cma_helper.c| 27 +-
drivers/gpu/drm/drm_gem_shmem_helper.c | 48 ++--
drivers/gpu/drm/drm_gem_ttm_helper.c| 38 +++
drivers/gpu/drm/drm_gem_vram_helper.c | 117 -
drivers/gpu/drm/drm_internal.h | 5 +-
drivers/gpu/drm/drm_prime.c | 14 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 3 +-
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 12 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 -
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 -
drivers/gpu/drm/lima/lima_gem.c | 6 +-
drivers/gpu/drm/lima/lima_sched.c | 11 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
drivers/gpu/drm/nouveau/Kconfig | 1 +
drivers/gpu/drm/nouveau/nouveau_bo.h| 2 -
drivers/gpu/drm/nouveau/nouveau_gem.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_gem.h | 2 -
drivers/gpu/drm/nouveau/nouveau_prime.c | 20 --
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 14 +-
drivers/gpu/drm/qxl/qxl_display.c | 11 +-
drivers/gpu/drm/qxl/qxl_draw.c | 14 +-
drivers/gpu/drm/qxl/qxl_drv.h | 11 +-
drivers/gpu/drm/qxl/qxl_object.c| 31 ++-
drivers/gpu/drm/qxl/qxl_object.h| 2 +-
drivers/gpu/drm/qxl/qxl_prime.c | 12 +-
drivers/gpu/drm/radeon/radeon.h | 1 -
drivers/gpu/drm/radeon/radeon_gem.c | 7 +-
drivers/gpu/drm/radeon/radeon_prime.c | 20 --
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 22 +-
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 4 +-
drivers/gpu/drm/tiny/cirrus.c | 10 +-
drivers/gpu/drm/tiny/gm12u320.c | 10 +-
drivers/gpu/d
[PATCH v6 10/10] drm/fb_helper: Support framebuffers in I/O memory
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions. Read and write operations are implemented
internally by DRM's fbdev helper.
For drivers that employ a shadow buffer, fbdev's blit function retrieves
the framebuffer address as struct dma_buf_map, and uses dma_buf_map
interfaces to access the buffer.
The bochs driver on sparc64 uses a workaround to flag the framebuffer as
I/O memory and avoid a HW exception. With the introduction of struct
dma_buf_map, this is not required any longer. The patch removes the rsp
code from both, bochs and fbdev.
v5:
* implement fb_read/fb_write internally (Daniel, Sam)
v4:
* move dma_buf_map changes into separate patch (Daniel)
* TODO list: comment on fbdev updates (Daniel)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Tested-by: Sam Ravnborg
---
Documentation/gpu/todo.rst| 19 ++-
drivers/gpu/drm/bochs/bochs_kms.c | 1 -
drivers/gpu/drm/drm_fb_helper.c | 227 --
include/drm/drm_mode_config.h | 12 --
4 files changed, 230 insertions(+), 29 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 7e6fc3c04add..638b7f704339 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup()
Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
-atomic modesetting and GEM vmap support. Current generic fbdev emulation
-expects the framebuffer in system memory (or system-like memory).
+atomic modesetting and GEM vmap support. Historically, generic fbdev emulation
+expected the framebuffer in system memory or system-like memory. By employing
+struct dma_buf_map, drivers with frambuffers in I/O memory can be supported
+as well.
Contact: Maintainer of the driver you plan to convert
Level: Intermediate
+Reimplement functions in drm_fbdev_fb_ops without fbdev
+---
+
+A number of callback functions in drm_fbdev_fb_ops could benefit from
+being rewritten without dependencies on the fbdev module. Some of the
+helpers could further benefit from using struct dma_buf_map instead of
+raw pointers.
+
+Contact: Thomas Zimmermann , Daniel Vetter
+
+Level: Advanced
+
+
drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
-
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 13d0d04c4457..853081d186d5 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs)
bochs->dev->mode_config.preferred_depth = 24;
bochs->dev->mode_config.prefer_shadow = 0;
bochs->dev->mode_config.prefer_shadow_fbdev = 1;
- bochs->dev->mode_config.fbdev_use_iomem = true;
bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
bochs->dev->mode_config.funcs = &bochs_mode_funcs;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 6ce0b9119ef2..714ce3bd6221 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct
work_struct *work)
}
static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
- struct drm_clip_rect *clip)
+ struct drm_clip_rect *clip,
+ struct dma_buf_map *dst)
{
struct drm_framebuffer *fb = fb_helper->fb;
unsigned int cpp = fb->format->cpp[0];
size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
void *src = fb_helper->fbdev->screen_buffer + offset;
- void *dst = fb_helper->buffer->map.vaddr + offset;
size_t len = (clip->x2 - clip->x1) * cpp;
unsigned int y;
- for (y = clip->y1; y < clip->y2; y++) {
- if (!fb_helper->dev->mode_config.fbdev_use_iomem)
- memcpy(dst, src, len);
- else
- memcpy_toio((void __iomem *)dst, src, len);
+ dma_buf_map_incr(dst, offset); /* go to first pixel within clip rect */
+ for (y = clip->y1; y < clip->y2; y++) {
+ dma_buf_map_memcpy_to(dst, src, len);
+ dma_buf_map_incr(dst, fb->pitches[0]);
src += fb->pitches[0];
- dst += fb->pitches[0];
}
}
@@ -417,8 +415,9 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
r
[PATCH v6 04/10] drm/exynos: Remove empty exynos_drm_gem_prime_{vmap, vunmap}()
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index e7a6eb96f692..13a35623ac04 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -137,8 +137,6 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
static const struct drm_gem_object_funcs exynos_drm_gem_object_funcs = {
.free = exynos_drm_gem_free_object,
.get_sg_table = exynos_drm_gem_prime_get_sg_table,
- .vmap = exynos_drm_gem_prime_vmap,
- .vunmap = exynos_drm_gem_prime_vunmap,
.vm_ops = &exynos_drm_gem_vm_ops,
};
@@ -471,16 +469,6 @@ exynos_drm_gem_prime_import_sg_table(struct drm_device
*dev,
return &exynos_gem->base;
}
-void *exynos_drm_gem_prime_vmap(struct drm_gem_object *obj)
-{
- return NULL;
-}
-
-void exynos_drm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
-{
- /* Nothing to do */
-}
-
int exynos_drm_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma)
{
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 74e926abeff0..a23272fb96fb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -107,8 +107,6 @@ struct drm_gem_object *
exynos_drm_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
struct sg_table *sgt);
-void *exynos_drm_gem_prime_vmap(struct drm_gem_object *obj);
-void exynos_drm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
int exynos_drm_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
--
2.29.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 41/52] memory: tegra124-emc: Use devm_platform_ioremap_resource()
On Tue, Oct 27, 2020 at 11:30:31PM +0300, Dmitry Osipenko wrote: > 27.10.2020 13:27, Krzysztof Kozlowski пишет: > > On Mon, Oct 26, 2020 at 01:17:24AM +0300, Dmitry Osipenko wrote: > >> Use devm_platform_ioremap_resource() helper which makes code a bit > >> cleaner. > > > > Such cleanups (and few other in this patchset) should be at beginning of > > patchset or even as part of a separate one. I think there is not much > > stopping anyone from applying these... except that you put them in the > > middle of big dependency. > > Some of these cleanup patches can't be applied separately without a need > to make a rebase. I think it should be more preferred to have all the > patches within a single series. > > I'll try to reorder the patches in v7 if this will ease the review, thanks. If feasible, that would be good. Thanks. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 13/52] dt-bindings: memory: tegra124: emc: Document new interconnect property
On Tue, Oct 27, 2020 at 11:16:29PM +0300, Dmitry Osipenko wrote: > 27.10.2020 22:48, Krzysztof Kozlowski пишет: > > On Tue, Oct 27, 2020 at 10:19:28PM +0300, Dmitry Osipenko wrote: > >> 27.10.2020 13:25, Krzysztof Kozlowski пишет: > >>> On Mon, Oct 26, 2020 at 01:16:56AM +0300, Dmitry Osipenko wrote: > External memory controller is interconnected with memory controller and > with external memory. Document new interconnect property which turns > External Memory Controller into interconnect provider. > > Signed-off-by: Dmitry Osipenko > --- > .../bindings/memory-controllers/nvidia,tegra124-emc.yaml | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml > > b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml > index 278549f9e051..ac00832ceac1 100644 > --- > a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml > +++ > b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml > @@ -29,6 +29,9 @@ properties: > items: > - const: emc > > + "#interconnect-cells": > +const: 0 > + > nvidia,memory-controller: > $ref: /schemas/types.yaml#/definitions/phandle > description: > @@ -327,6 +330,7 @@ required: > - clocks > - clock-names > - nvidia,memory-controller > + - "#interconnect-cells" > >>> > >>> Another required property, what about all existing users of this binding? > >> > >> EMC/devfreq drivers check presence of the new properties and ask users > >> to upgrade the DT. The kernel will continue to work fine using older > >> DTBs, but devfreq driver won't load. > > > > If the devfreq was working fine before (with these older DTBs and older > > kernel) then you break the feature. > > > > If devfreq was not working or was not stable enough, then nothing is > > broken so such change is accepted. > > > > Which one is then? > > Definitely the latter. The current devfreq works okay'ish, but we rely > on hardware to recover from temporal FIFO underflows and it's a > user-visible problem which this series addresses. I understand. Fine with me, thanks for explanation. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] fbdev/atafb: Remove unused extern variables
Am 27.10.20 um 17:31 schrieb Peilin Ye:
> Remove 6 unused extern variables to reduce confusion. It is worth
> mentioning that lib/fonts/font_8x8.c and lib/fonts/font_8x16.c also
> declare `fontdata_8x8` and `fontdata_8x16` respectively, and this file
> has nothing to do with them.
>
> Signed-off-by: Peilin Ye
Acked-by: Thomas Zimmermann
> ---
> $ # Build-tested (Ubuntu 20.04)
> $ sudo apt install gcc-m68k-linux-gnu
> $ cp arch/m68k/configs/atari_defconfig .config
> $ make ARCH=m68k menuconfig
> $ make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- -j`nproc` all
>
> drivers/video/fbdev/atafb.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
> index f253daa05d9d..e3812a8ff55a 100644
> --- a/drivers/video/fbdev/atafb.c
> +++ b/drivers/video/fbdev/atafb.c
> @@ -240,14 +240,6 @@ static int *MV300_reg = MV300_reg_8bit;
>
> static int inverse;
>
> -extern int fontheight_8x8;
> -extern int fontwidth_8x8;
> -extern unsigned char fontdata_8x8[];
> -
> -extern int fontheight_8x16;
> -extern int fontwidth_8x16;
> -extern unsigned char fontdata_8x16[];
> -
> /*
> * struct fb_ops {
> * * open/release and usage marking
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Remove GTT roll support
Hi Patrik
Am 28.10.20 um 15:36 schrieb Patrik Jakobsson:
> GTT roll support was used to accelerate fb panning on some machines.
> Unfortunately this never worked properly with multiple monitors and
> caused issues on others where the framebuffer wouldn't fit in stolen
> memory. Let's remove it!
>
> Signed-off-by: Patrik Jakobsson
Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/gma500/framebuffer.c | 96
> drivers/gpu/drm/gma500/gtt.c | 52 +--
> drivers/gpu/drm/gma500/gtt.h | 3 -
> 3 files changed, 14 insertions(+), 137 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 5ede24fb44ae..2d64c58607f5 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -76,27 +76,6 @@ static int psbfb_setcolreg(unsigned regno, unsigned red,
> unsigned green,
> return 0;
> }
>
> -static int psbfb_pan(struct fb_var_screeninfo *var, struct fb_info *info)
> -{
> - struct drm_fb_helper *fb_helper = info->par;
> - struct drm_framebuffer *fb = fb_helper->fb;
> - struct drm_device *dev = fb->dev;
> - struct gtt_range *gtt = to_gtt_range(fb->obj[0]);
> -
> - /*
> - * We have to poke our nose in here. The core fb code assumes
> - * panning is part of the hardware that can be invoked before
> - * the actual fb is mapped. In our case that isn't quite true.
> - */
> - if (gtt->npage) {
> - /* GTT roll shifts in 4K pages, we need to shift the right
> -number of pages */
> - int pages = info->fix.line_length >> 12;
> - psb_gtt_roll(dev, gtt, var->yoffset * pages);
> - }
> -return 0;
> -}
> -
> static vm_fault_t psbfb_vm_fault(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> @@ -176,17 +155,6 @@ static const struct fb_ops psbfb_ops = {
> .fb_sync = psbfb_sync,
> };
>
> -static const struct fb_ops psbfb_roll_ops = {
> - .owner = THIS_MODULE,
> - DRM_FB_HELPER_DEFAULT_OPS,
> - .fb_setcolreg = psbfb_setcolreg,
> - .fb_fillrect = drm_fb_helper_cfb_fillrect,
> - .fb_copyarea = drm_fb_helper_cfb_copyarea,
> - .fb_imageblit = drm_fb_helper_cfb_imageblit,
> - .fb_pan_display = psbfb_pan,
> - .fb_mmap = psbfb_mmap,
> -};
> -
> static const struct fb_ops psbfb_unaccel_ops = {
> .owner = THIS_MODULE,
> DRM_FB_HELPER_DEFAULT_OPS,
> @@ -312,8 +280,6 @@ static int psbfb_create(struct drm_fb_helper *fb_helper,
> int ret;
> struct gtt_range *backing;
> u32 bpp, depth;
> - int gtt_roll = 0;
> - int pitch_lines = 0;
>
> mode_cmd.width = sizes->surface_width;
> mode_cmd.height = sizes->surface_height;
> @@ -324,50 +290,15 @@ static int psbfb_create(struct drm_fb_helper *fb_helper,
> if (bpp == 24)
> bpp = 32;
>
> - do {
> - /*
> - * Acceleration via the GTT requires pitch to be
> - * power of two aligned. Preferably page but less
> - * is ok with some fonts
> - */
> - mode_cmd.pitches[0] = ALIGN(mode_cmd.width * ((bpp + 7) / 8),
> 4096 >> pitch_lines);
> -
> - size = mode_cmd.pitches[0] * mode_cmd.height;
> - size = ALIGN(size, PAGE_SIZE);
> -
> - /* Allocate the fb in the GTT with stolen page backing */
> - backing = psbfb_alloc(dev, size);
> -
> - if (pitch_lines)
> - pitch_lines *= 2;
> - else
> - pitch_lines = 1;
> - gtt_roll++;
> - } while (backing == NULL && pitch_lines <= 16);
> -
> - /* The final pitch we accepted if we succeeded */
> - pitch_lines /= 2;
> -
> - if (backing == NULL) {
> - /*
> - * We couldn't get the space we wanted, fall back to the
> - * display engine requirement instead. The HW requires
> - * the pitch to be 64 byte aligned
> - */
> -
> - gtt_roll = 0; /* Don't use GTT accelerated scrolling */
> - pitch_lines = 64;
> -
> - mode_cmd.pitches[0] = ALIGN(mode_cmd.width * ((bpp + 7) / 8),
> 64);
> -
> - size = mode_cmd.pitches[0] * mode_cmd.height;
> - size = ALIGN(size, PAGE_SIZE);
> -
> - /* Allocate the framebuffer in the GTT with stolen page backing
> */
> - backing = psbfb_alloc(dev, size);
> - if (backing == NULL)
> - return -ENOMEM;
> - }
> + mode_cmd.pitches[0] = ALIGN(mode_cmd.width * DIV_ROUND_UP(bpp, 8), 64);
> +
> + size = mode_cmd.pitches[0] * mode_cmd.height;
> + size = ALIGN(size, PAGE_SIZE);
> +
> + /* Allocate the framebuffer in the GTT with stolen page backing */
> + backing = psbfb_alloc(dev, size);
> + if (backing ==
Re: [PATCH] fbcon: Disable accelerated scrolling
Hi
Am 28.10.20 um 17:06 schrieb Daniel Vetter:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now the problem is that most modern-ish drivers really only treat
> fbcon as an dumb kernel console until userspace takes over, and Oops
> printer for some emergencies. Looking at drm drivers and the basic
> vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> acceleration:
>
> - nouveau, seems to be enabled by default
> - omapdrm, when a DMM remapper exists using remapper rewriting for
> y/xpanning
> - gma500, but that is getting deleted now for the GTT remapper trick,
> and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> flag, so unused (and could be deleted already I think).
>
> No other driver supportes accelerated fbcon. And fbcon is the only
> user of this accel code (it's not exposed as uapi through ioctls),
> which means we could garbage collect fairly enormous amounts of code
> if we kill this.
>
> Plus because syzbot only runs on virtual hardware, and none of the
> drivers for that have acceleration, we'd remove a huge gap in testing.
> And there's no other even remotely comprehensive testing aside from
> syzbot.
>
> This patch here just disables the acceleration code by always
> redrawing when scrolling. The plan is that once this has been merged
> for well over a year in released kernels, we can start to go around
> and delete a lot of code.
Why wait a year? I'd say delete early, delete often. ;)
>
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Greg Kroah-Hartman
> Cc: Linus Torvalds
> Cc: Ben Skeggs
> Cc: nouv...@lists.freedesktop.org
> Cc: Tomi Valkeinen
> Cc: Daniel Vetter
> Cc: Jiri Slaby
> Cc: "Gustavo A. R. Silva"
> Cc: Tetsuo Handa
> Cc: Peilin Ye
> Cc: George Kennedy
> Cc: Nathan Chancellor
> Cc: Peter Rosin
> Signed-off-by: Daniel Vetter
> ---
> drivers/video/fbdev/core/fbcon.c | 38 ++--
> 1 file changed, 7 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index cef437817b0d..d74ccbbb29bb 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -1147,11 +1147,13 @@ static void fbcon_init(struct vc_data *vc, int init)
>
> ops->graphics = 0;
>
> - if ((cap & FBINFO_HWACCEL_COPYAREA) &&
> - !(cap & FBINFO_HWACCEL_DISABLED))
> - p->scrollmode = SCROLL_MOVE;
> - else /* default to something safe */
> - p->scrollmode = SCROLL_REDRAW;
> + /*
> + * No more hw acceleration for fbcon.
> + *
> + * FIXME: Garabge collect all the now dead code after sufficient time
> + * has passed.
> + */
> + p->scrollmode = SCROLL_REDRAW;
I just grepped for scrollmode and there aren't many places that use it.
Could you remove it as well?
In any case
Reviewed-by: Thomas Zimmermann
Best regards
Thomas
>
> /*
>* ++guenther: console.c:vc_allocate() relies on initializing
> @@ -1961,7 +1963,6 @@ static void updatescrollmode(struct fbcon_display *p,
> {
> struct fbcon_ops *ops = info->fbcon_par;
> int fh = vc->vc_font.height;
> - int cap = info->flags;
> u16 t = 0;
> int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> info->fix.xpanstep);
> @@ -1969,37 +1970,12 @@ static void updatescrollmode(struct fbcon_display *p,
> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> info->var.xres_virtual);
> - int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> - divides(ypan, vc->vc_font.height) && vyres > yres;
> - int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> - divides(ywrap, vc->vc_font.height) &&
> - divides(vc->vc_font.height, vyres) &&
> - divides(vc->vc_font.height, yres);
> - int reading_fast = cap & FBINFO_READS_FAST;
> - int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> - !(cap & FBINFO_HWACCEL_DISABLED);
> - int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> - !(cap & FBINFO_HWACCEL_DISABLED);
>
> p->vrows = vyres/fh;
> if (yres > (fh * (vc->vc_rows + 1)))
> p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
> if ((yres % fh) && (vyres % fh < yres % fh))
> p->vrows--;
> -
> - if (good_wrap || good_pan) {
> - if (reading_fast || fast_copyarea)
> - p->scrollmode = good_wrap ?
> - SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
> - else
> - p->scrollmode = good_wrap ? SCROLL_REDRAW :
> - SCROLL_PAN_REDRAW;
> - } else {
Re: [PATCH] fbcon: Disable accelerated scrolling
Hi Daniel.
On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now the problem is that most modern-ish drivers really only treat
> fbcon as an dumb kernel console until userspace takes over, and Oops
> printer for some emergencies. Looking at drm drivers and the basic
> vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> acceleration:
>
> - nouveau, seems to be enabled by default
> - omapdrm, when a DMM remapper exists using remapper rewriting for
> y/xpanning
> - gma500, but that is getting deleted now for the GTT remapper trick,
> and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> flag, so unused (and could be deleted already I think).
>
> No other driver supportes accelerated fbcon. And fbcon is the only
> user of this accel code (it's not exposed as uapi through ioctls),
> which means we could garbage collect fairly enormous amounts of code
> if we kill this.
>
> Plus because syzbot only runs on virtual hardware, and none of the
> drivers for that have acceleration, we'd remove a huge gap in testing.
> And there's no other even remotely comprehensive testing aside from
> syzbot.
>
> This patch here just disables the acceleration code by always
> redrawing when scrolling. The plan is that once this has been merged
> for well over a year in released kernels, we can start to go around
> and delete a lot of code.
See below for a warning fix.
Some figures from trying to toss accel code out from a few fbdev drivers:
drivers/video/fbdev/cirrusfb.c | 300 +
1 file changed, 4 insertions(+), 296 deletions(-)
drivers/video/fbdev/aty/radeon_accel.c | 174 -
drivers/video/fbdev/aty/radeon_base.c | 43 ++--
drivers/video/fbdev/aty/radeon_pm.c| 7 --
drivers/video/fbdev/aty/radeonfb.h | 3 -
4 files changed, 7 insertions(+), 220 deletions(-)
This may open up the discussion if the right course of action would be
to drop the drivers in favour of drm counterparts - but thats another
story.
Sam
> @@ -1961,7 +1963,6 @@ static void updatescrollmode(struct fbcon_display *p,
> {
> struct fbcon_ops *ops = info->fbcon_par;
> int fh = vc->vc_font.height;
> - int cap = info->flags;
> u16 t = 0;
> int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> info->fix.xpanstep);
> @@ -1969,37 +1970,12 @@ static void updatescrollmode(struct fbcon_display *p,
> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> info->var.xres_virtual);
> - int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> - divides(ypan, vc->vc_font.height) && vyres > yres;
> - int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> - divides(ywrap, vc->vc_font.height) &&
> - divides(vc->vc_font.height, vyres) &&
> - divides(vc->vc_font.height, yres);
> - int reading_fast = cap & FBINFO_READS_FAST;
> - int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> - !(cap & FBINFO_HWACCEL_DISABLED);
> - int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> - !(cap & FBINFO_HWACCEL_DISABLED);
Some bot will likely tell you that this causes warnings.
At least it did in my sparc64 build.
Fix:
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 398914e035e9..e8b009c621d8 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2150,10 +2150,6 @@ static void updatescrollmode(struct fbcon_display *p,
{
struct fbcon_ops *ops = info->fbcon_par;
int fh = vc->vc_font.height;
- u16 t = 0;
- int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
- info->fix.xpanstep);
- int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
info->var.xres_virtual);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/5] Fonts: Make font size unsigned in font_desc
On Wed, Oct 28, 2020 at 06:56:47AM -0400, Peilin Ye wrote:
> `width` and `height` are defined as unsigned in our UAPI font descriptor
> `struct console_font`. Make them unsigned in our kernel font descriptor
> `struct font_desc`, too.
>
> Also, change the corresponding printk() format identifiers from `%d` to
> `%u`, in sti_select_fbfont().
>
> Signed-off-by: Peilin Ye
Pushed to drm-misc-next, thanks for the patch.
-Daniel
> ---
> Change in v2:
> - Mention `struct console_font` in the commit message. (Suggested by
> Daniel Vetter )
>
> drivers/video/console/sticore.c | 2 +-
> include/linux/font.h| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/console/sticore.c b/drivers/video/console/sticore.c
> index 6a26a364f9bd..d1bb5915082b 100644
> --- a/drivers/video/console/sticore.c
> +++ b/drivers/video/console/sticore.c
> @@ -502,7 +502,7 @@ sti_select_fbfont(struct sti_cooked_rom *cooked_rom,
> const char *fbfont_name)
> if (!fbfont)
> return NULL;
>
> - pr_info("STI selected %dx%d framebuffer font %s for sticon\n",
> + pr_info("STI selected %ux%u framebuffer font %s for sticon\n",
> fbfont->width, fbfont->height, fbfont->name);
>
> bpc = ((fbfont->width+7)/8) * fbfont->height;
> diff --git a/include/linux/font.h b/include/linux/font.h
> index b5b312c19e46..4f50d736ea72 100644
> --- a/include/linux/font.h
> +++ b/include/linux/font.h
> @@ -16,7 +16,7 @@
> struct font_desc {
> int idx;
> const char *name;
> -int width, height;
> +unsigned int width, height;
> const void *data;
> int pref;
> };
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm: bridge: Propagate the bus flags from bridge->timings
On 14:31-20201021, Tomi Valkeinen wrote: > On 16/10/2020 13:39, Nikhil Devshatwar wrote: > > When the next bridge does not specify any bus flags, use the > > bridge->timings->input_bus_flags as fallback when propagating > > bus flags from next bridge to current bridge. > > > > Signed-off-by: Nikhil Devshatwar > > --- > > drivers/gpu/drm/drm_bridge.c | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > > index 64f0effb52ac..8353723323ab 100644 > > --- a/drivers/gpu/drm/drm_bridge.c > > +++ b/drivers/gpu/drm/drm_bridge.c > > @@ -975,6 +975,13 @@ drm_atomic_bridge_propagate_bus_flags(struct > > drm_bridge *bridge, > > * duplicate the "dummy propagation" logic. > > */ > > bridge_state->input_bus_cfg.flags = output_flags; > > + > > + /* > > +* Use the bridge->timings->input_bus_flags as fallback if the next > > bridge > > +* does not specify the flags > > +*/ > > + if (!bridge_state->input_bus_cfg.flags) > > + bridge_state->input_bus_cfg.flags = > > bridge->timings->input_bus_flags; > > According to docs, timings can be NULL. > > And, hmm... It's too easy to get confused with these, but... If the bridge > defines timings, and > timings->input_bus_flags != 0, should we always pick that, even if we got > something via > output_flags? Logic being, if this bridge defines timings->input_bus_flags, > it probably wants that > to be used regardless whether we got something from the next bridge. Got it, the flags from timings if present should be prioritized rather than treating them as fallback. Nikhil D > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] drm/tidss: Use new connector model for tidss
On 15:11-20201019, Tomi Valkeinen wrote: > Hi Nikhil, > > On 16/10/2020 13:39, Nikhil Devshatwar wrote: > > This series moves the tidss to using new connectoe model, where the > > SoC driver (tidss) creates the connector and all the bridges are > > attached with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR > > > > Since the bridges do not create the connector, the bus format and > > bus_flag is set after the format negotiation. > > Support format negotiations in the tfp410 and mhdp bridge drivers. > > > > Nikhil Devshatwar (5): > > drm/tidss: Move to newer connector model > > drm/tidss: Set bus_format correctly from bridge/connector > > drm: bridge: Propagate the bus flags from bridge->timings > > drm/bridge: tfp410: Support format negotiation > > drm/bridge: mhdp8564: Support format negotiation > > I think the patch order could be a bit different. If you first change the > tidss to use the new > connector model, and only afterwards fix the bridges we use, then there's a > time when the displays > won't work. > Agreed. I will change the order in next version > Also, with J7 EVM and DP, when I unload the modules I see: > I confirm the same issue. I doubt if it is because of the change I did. Will try to revert the patches and confirm again > [ 43.238895] irq 31: nobody cared (try booting with the "irqpoll" option) > [ 43.245591] CPU: 0 PID: 349 Comm: irq/31-mhdp8546 Not tainted > 5.9.0-rc5-00605-g08a291316f86 #4 > [ 43.254186] Hardware name: Texas Instruments K3 J721E SoC (DT) > [ 43.260006] Call trace: > [ 43.262453] dump_backtrace+0x0/0x1d8 > [ 43.266107] show_stack+0x18/0x28 > [ 43.269416] dump_stack+0xe0/0x14c > [ 43.272810] __report_bad_irq+0x4c/0xdc > [ 43.276637] note_interrupt+0x2cc/0x388 > [ 43.280465] handle_irq_event_percpu+0x88/0x90 > [ 43.284898] handle_irq_event+0x48/0xf8 > [ 43.288725] handle_fasteoi_irq+0xcc/0x180 > [ 43.292811] generic_handle_irq+0x30/0x48 > [ 43.296811] __handle_domain_irq+0x94/0x108 > [ 43.300986] gic_handle_irq+0x60/0x158 > [ 43.304726] el1_irq+0xbc/0x180 > [ 43.307862] _raw_spin_unlock_irq+0x48/0x90 > [ 43.312035] irq_finalize_oneshot.part.0+0x68/0x108 > [ 43.316903] irq_thread_fn+0x60/0xa0 > [ 43.320469] irq_thread+0x1b8/0x248 > [ 43.323949] kthread+0x128/0x160 > [ 43.327169] ret_from_fork+0x10/0x34 > [ 43.330735] handlers: > [ 43.333020] [<5367c4f9>] irq_default_primary_handler threaded > [<7e02b601>] > cdns_mhdp_irq_handler [cdns_mhdp8546] > [ 43.344607] Disabling IRQ #31 > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v6 4/4] RDMA/mlx5: Support dma-buf based userspace memory region
> -Original Message-
> From: Jason Gunthorpe
> Sent: Wednesday, October 28, 2020 9:36 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH v6 4/4] RDMA/mlx5: Support dma-buf based userspace memory
> region
>
> On Tue, Oct 27, 2020 at 08:33:52PM +, Xiong, Jianxin wrote:
> > > > @@ -801,6 +816,52 @@ static int pagefault_implicit_mr(struct mlx5_ib_mr
> > > > *imr,
> > > > * Returns:
> > > > * -EFAULT: The io_virt->bcnt is not within the MR, it covers pages
> > > > that are
> > > > * not accessible, or the MR is no longer valid.
> > > > + * -EAGAIN: The operation should be retried
> > > > + *
> > > > + * >0: Number of pages mapped
> > > > + */
> > > > +static int pagefault_dmabuf_mr(struct mlx5_ib_mr *mr, struct ib_umem
> > > > *umem,
> > > > + u64 io_virt, size_t bcnt, u32
> > > > *bytes_mapped,
> > > > + u32 flags)
> > > > +{
> > > > + struct ib_umem_dmabuf *umem_dmabuf = to_ib_umem_dmabuf(umem);
> > > > + u64 user_va;
> > > > + u64 end;
> > > > + int npages;
> > > > + int err;
> > > > +
> > > > + if (unlikely(io_virt < mr->mmkey.iova))
> > > > + return -EFAULT;
> > > > + if (check_add_overflow(io_virt - mr->mmkey.iova,
> > > > + (u64)umem->address, &user_va))
> > > > + return -EFAULT;
> > > > + /* Overflow has alreddy been checked at the umem creation time
> > > > */
> > > > + end = umem->address + umem->length;
> > > > + if (unlikely(user_va >= end || end - user_va < bcnt))
> > > > + return -EFAULT;
> > >
> > > Why duplicate this sequence? Caller does it
> >
> > The sequence in the caller is for umem_odp only.
>
> Nothing about umem_odp in this code though??
The code in the caller uses ib_umem_end(odp) instead of the 'end' here, but we
can consolidate that with some minor changes.
>
> > > > /* prefetch with write-access must be supported by the MR */
> > > > if (advice == IB_UVERBS_ADVISE_MR_ADVICE_PREFETCH_WRITE &&
> > > > - !odp->umem.writable)
> > > > + !mr->umem->writable)
> > >
> > > ??
>
> > There is no need to use umem_odp here, mr->umem is the same as &odp->umem.
> > This change makes the code works for both umem_odp and umem_dmabuf.
>
> Ok
>
> Can you please also think about how to test this? I very much prefer to see
> new pyverbs tests for new APIs.
>
> Distros are running the rdma-core test suite, if you want this to work widely
> we need a public test for it.
>
Will look into that.
> Thanks,
> Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: Disable accelerated scrolling
On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now the problem is that most modern-ish drivers really only treat
> fbcon as an dumb kernel console until userspace takes over, and Oops
> printer for some emergencies. Looking at drm drivers and the basic
> vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> acceleration:
>
> - nouveau, seems to be enabled by default
> - omapdrm, when a DMM remapper exists using remapper rewriting for
> y/xpanning
> - gma500, but that is getting deleted now for the GTT remapper trick,
> and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> flag, so unused (and could be deleted already I think).
>
> No other driver supportes accelerated fbcon. And fbcon is the only
> user of this accel code (it's not exposed as uapi through ioctls),
> which means we could garbage collect fairly enormous amounts of code
> if we kill this.
>
> Plus because syzbot only runs on virtual hardware, and none of the
> drivers for that have acceleration, we'd remove a huge gap in testing.
> And there's no other even remotely comprehensive testing aside from
> syzbot.
>
> This patch here just disables the acceleration code by always
> redrawing when scrolling. The plan is that once this has been merged
> for well over a year in released kernels, we can start to go around
> and delete a lot of code.
>
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Greg Kroah-Hartman
> Cc: Linus Torvalds
> Cc: Ben Skeggs
> Cc: nouv...@lists.freedesktop.org
> Cc: Tomi Valkeinen
> Cc: Daniel Vetter
> Cc: Jiri Slaby
> Cc: "Gustavo A. R. Silva"
> Cc: Tetsuo Handa
> Cc: Peilin Ye
> Cc: George Kennedy
> Cc: Nathan Chancellor
> Cc: Peter Rosin
> Signed-off-by: Daniel Vetter
> ---
> drivers/video/fbdev/core/fbcon.c | 38 ++--
> 1 file changed, 7 insertions(+), 31 deletions(-)
Nice!
But I'm with Sam, delete early :)
Reviewed-by: Greg Kroah-Hartman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: Disable accelerated scrolling
On Wed, Oct 28, 2020 at 5:45 PM Sam Ravnborg wrote:
>
> Hi Daniel et al.
>
> On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
> >
> > Now the problem is that most modern-ish drivers really only treat
> > fbcon as an dumb kernel console until userspace takes over, and Oops
> > printer for some emergencies. Looking at drm drivers and the basic
> > vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> > acceleration:
> >
> > - nouveau, seems to be enabled by default
> > - omapdrm, when a DMM remapper exists using remapper rewriting for
> > y/xpanning
> > - gma500, but that is getting deleted now for the GTT remapper trick,
> > and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> > flag, so unused (and could be deleted already I think).
> >
> > No other driver supportes accelerated fbcon. And fbcon is the only
> > user of this accel code (it's not exposed as uapi through ioctls),
> > which means we could garbage collect fairly enormous amounts of code
> > if we kill this.
> >
> > Plus because syzbot only runs on virtual hardware, and none of the
> > drivers for that have acceleration, we'd remove a huge gap in testing.
> > And there's no other even remotely comprehensive testing aside from
> > syzbot.
> >
> > This patch here just disables the acceleration code by always
> > redrawing when scrolling.
>
> So far I follow you - and agree.
> Acked-by: Sam Ravnborg
>
> > The plan is that once this has been merged
> > for well over a year in released kernels, we can start to go around
> > and delete a lot of code.
>
> Why wait one year? We deleted the scrollback code without any prior
> warning - which was fine. And acceleration support has less users
> so there should be no reason to wait.
>
> So unless there are good arguments that I miss then we should just
> delete the acceleration code outright.
If you grep for FBINFO_HWACCEL and related stuff, we could delete like
half the driver code, plus a ton of the related support code in fbcon
and fbdev core. It's going to be a lot of work, and I don't want to do
that and then have to back it out again. Compared to this the
softscrollback removal was nothing.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: Disable accelerated scrolling
Hi Daniel et al.
On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now the problem is that most modern-ish drivers really only treat
> fbcon as an dumb kernel console until userspace takes over, and Oops
> printer for some emergencies. Looking at drm drivers and the basic
> vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> acceleration:
>
> - nouveau, seems to be enabled by default
> - omapdrm, when a DMM remapper exists using remapper rewriting for
> y/xpanning
> - gma500, but that is getting deleted now for the GTT remapper trick,
> and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> flag, so unused (and could be deleted already I think).
>
> No other driver supportes accelerated fbcon. And fbcon is the only
> user of this accel code (it's not exposed as uapi through ioctls),
> which means we could garbage collect fairly enormous amounts of code
> if we kill this.
>
> Plus because syzbot only runs on virtual hardware, and none of the
> drivers for that have acceleration, we'd remove a huge gap in testing.
> And there's no other even remotely comprehensive testing aside from
> syzbot.
>
> This patch here just disables the acceleration code by always
> redrawing when scrolling.
So far I follow you - and agree.
Acked-by: Sam Ravnborg
> The plan is that once this has been merged
> for well over a year in released kernels, we can start to go around
> and delete a lot of code.
Why wait one year? We deleted the scrollback code without any prior
warning - which was fine. And acceleration support has less users
so there should be no reason to wait.
So unless there are good arguments that I miss then we should just
delete the acceleration code outright.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbcon: Disable accelerated scrolling
So ever since syzbot discovered fbcon, we have solid proof that it's
full of bugs. And often the solution is to just delete code and remove
features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
Now the problem is that most modern-ish drivers really only treat
fbcon as an dumb kernel console until userspace takes over, and Oops
printer for some emergencies. Looking at drm drivers and the basic
vesa/efi fbdev drivers shows that only 3 drivers support any kind of
acceleration:
- nouveau, seems to be enabled by default
- omapdrm, when a DMM remapper exists using remapper rewriting for
y/xpanning
- gma500, but that is getting deleted now for the GTT remapper trick,
and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
flag, so unused (and could be deleted already I think).
No other driver supportes accelerated fbcon. And fbcon is the only
user of this accel code (it's not exposed as uapi through ioctls),
which means we could garbage collect fairly enormous amounts of code
if we kill this.
Plus because syzbot only runs on virtual hardware, and none of the
drivers for that have acceleration, we'd remove a huge gap in testing.
And there's no other even remotely comprehensive testing aside from
syzbot.
This patch here just disables the acceleration code by always
redrawing when scrolling. The plan is that once this has been merged
for well over a year in released kernels, we can start to go around
and delete a lot of code.
Cc: Bartlomiej Zolnierkiewicz
Cc: Greg Kroah-Hartman
Cc: Linus Torvalds
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Cc: Tomi Valkeinen
Cc: Daniel Vetter
Cc: Jiri Slaby
Cc: "Gustavo A. R. Silva"
Cc: Tetsuo Handa
Cc: Peilin Ye
Cc: George Kennedy
Cc: Nathan Chancellor
Cc: Peter Rosin
Signed-off-by: Daniel Vetter
---
drivers/video/fbdev/core/fbcon.c | 38 ++--
1 file changed, 7 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index cef437817b0d..d74ccbbb29bb 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1147,11 +1147,13 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->graphics = 0;
- if ((cap & FBINFO_HWACCEL_COPYAREA) &&
- !(cap & FBINFO_HWACCEL_DISABLED))
- p->scrollmode = SCROLL_MOVE;
- else /* default to something safe */
- p->scrollmode = SCROLL_REDRAW;
+ /*
+* No more hw acceleration for fbcon.
+*
+* FIXME: Garabge collect all the now dead code after sufficient time
+* has passed.
+*/
+ p->scrollmode = SCROLL_REDRAW;
/*
* ++guenther: console.c:vc_allocate() relies on initializing
@@ -1961,7 +1963,6 @@ static void updatescrollmode(struct fbcon_display *p,
{
struct fbcon_ops *ops = info->fbcon_par;
int fh = vc->vc_font.height;
- int cap = info->flags;
u16 t = 0;
int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
info->fix.xpanstep);
@@ -1969,37 +1970,12 @@ static void updatescrollmode(struct fbcon_display *p,
int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
info->var.xres_virtual);
- int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
- divides(ypan, vc->vc_font.height) && vyres > yres;
- int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
- divides(ywrap, vc->vc_font.height) &&
- divides(vc->vc_font.height, vyres) &&
- divides(vc->vc_font.height, yres);
- int reading_fast = cap & FBINFO_READS_FAST;
- int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
- !(cap & FBINFO_HWACCEL_DISABLED);
- int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
- !(cap & FBINFO_HWACCEL_DISABLED);
p->vrows = vyres/fh;
if (yres > (fh * (vc->vc_rows + 1)))
p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
if ((yres % fh) && (vyres % fh < yres % fh))
p->vrows--;
-
- if (good_wrap || good_pan) {
- if (reading_fast || fast_copyarea)
- p->scrollmode = good_wrap ?
- SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
- else
- p->scrollmode = good_wrap ? SCROLL_REDRAW :
- SCROLL_PAN_REDRAW;
- } else {
- if (reading_fast || (fast_copyarea && !fast_imageblit))
- p->scrollmode = SCROLL_MOVE;
- else
- p->scrollmode = SCROLL_REDRAW;
- }
}
#define PITCH(w) (((w) + 7) >> 3)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/li
[PATCH RFC v2 4/5] fbdev: Avoid using FNTCHARCNT() and hard-coded font charcount
For user-provided fonts, the framebuffer layer is using a
negative-indexing macro, FNTCHARCNT(), to keep track of their number of
characters. For built-in fonts, it is using hard-coded values (256). This
results in something like the following:
map.length = (ops->p->userfont) ?
FNTCHARCNT(ops->p->fontdata) : 256;
Recently we added a `charcount` field to `struct font_desc`. Use it, and
set `vc->vc_font.charcount` properly whenever `vc->vc_font.data` is set,
so that we can use `vc->vc_font.charcount` instead of an if-else between
FNTCHARCNT() and 256.
This patch depends on patch "Fonts: Add charcount field to font_desc".
Signed-off-by: Peilin Ye
---
FNTCHARCNT() now disappeared from drivers/video/fbdev/core/. There is one
more in drivers/video/console/newport_con.c, but I think that file needs
to be handled separately.
Changes in v2:
- Try avoid using FNTCHARCNT() altogether, instead of only changing a
little bit (Suggested by Daniel Vetter )
- Change the title, since we are now removing FNTCHARCNT()
- Set `vc->vc_font.charcount` properly, in fbcon_startup(),
fbcon_init(), fbcon_set_disp() and fbcon_do_set_font()
- Replace hard-coded 256 whenever possible
drivers/video/fbdev/core/fbcon.c| 58 ++---
drivers/video/fbdev/core/fbcon_rotate.c | 2 +-
drivers/video/fbdev/core/tileblit.c | 3 +-
3 files changed, 25 insertions(+), 38 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index cef437817b0d..253eb9bcff25 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1004,7 +1004,7 @@ static const char *fbcon_startup(void)
vc->vc_font.width = font->width;
vc->vc_font.height = font->height;
vc->vc_font.data = (void *)(p->fontdata = font->data);
- vc->vc_font.charcount = 256; /* FIXME Need to support more
fonts */
+ vc->vc_font.charcount = font->charcount;
} else {
p->fontdata = vc->vc_font.data;
}
@@ -1032,7 +1032,7 @@ static void fbcon_init(struct vc_data *vc, int init)
struct vc_data **default_mode = vc->vc_display_fg;
struct vc_data *svc = *default_mode;
struct fbcon_display *t, *p = &fb_display[vc->vc_num];
- int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
+ int logo = 1, new_rows, new_cols, rows, cols;
int cap, ret;
if (WARN_ON(info_idx == -1))
@@ -1068,6 +1068,7 @@ static void fbcon_init(struct vc_data *vc, int init)
fvc->vc_font.data);
vc->vc_font.width = fvc->vc_font.width;
vc->vc_font.height = fvc->vc_font.height;
+ vc->vc_font.charcount = fvc->vc_font.charcount;
p->userfont = t->userfont;
if (p->userfont)
@@ -1083,17 +1084,13 @@ static void fbcon_init(struct vc_data *vc, int init)
vc->vc_font.width = font->width;
vc->vc_font.height = font->height;
vc->vc_font.data = (void *)(p->fontdata = font->data);
- vc->vc_font.charcount = 256; /* FIXME Need to
- support more fonts */
+ vc->vc_font.charcount = font->charcount;
}
}
- if (p->userfont)
- charcnt = FNTCHARCNT(p->fontdata);
-
vc->vc_can_do_color = (fb_get_color_depth(&info->var, &info->fix)!=1);
vc->vc_complement_mask = vc->vc_can_do_color ? 0x7700 : 0x0800;
- if (charcnt == 256) {
+ if (vc->vc_font.charcount == 256) {
vc->vc_hi_font_mask = 0;
} else {
vc->vc_hi_font_mask = 0x100;
@@ -1358,7 +1355,7 @@ static void fbcon_set_disp(struct fb_info *info, struct
fb_var_screeninfo *var,
struct vc_data **default_mode, *vc;
struct vc_data *svc;
struct fbcon_ops *ops = info->fbcon_par;
- int rows, cols, charcnt = 256;
+ int rows, cols;
p = &fb_display[unit];
@@ -1378,12 +1375,11 @@ static void fbcon_set_disp(struct fb_info *info, struct
fb_var_screeninfo *var,
vc->vc_font.data = (void *)(p->fontdata = t->fontdata);
vc->vc_font.width = (*default_mode)->vc_font.width;
vc->vc_font.height = (*default_mode)->vc_font.height;
+ vc->vc_font.charcount = (*default_mode)->vc_font.charcount;
p->userfont = t->userfont;
if (p->userfont)
REFCOUNT(p->fontdata)++;
}
- if (p->userfont)
- charcnt = FNTCHARCNT(p->fontdata);
var->activate = FB_ACTIVATE_NOW;
info->var.activate = var->activate;
@@ -1393,7 +1389,7 @@ static void fbcon_set_disp(struct fb_info *info, struct
fb_var_scr
Re: [PATCH] drm/gma500: Remove GTT roll support
On Wed, Oct 28, 2020 at 3:36 PM Patrik Jakobsson
wrote:
>
> GTT roll support was used to accelerate fb panning on some machines.
> Unfortunately this never worked properly with multiple monitors and
> caused issues on others where the framebuffer wouldn't fit in stolen
> memory. Let's remove it!
Acked-by: Daniel Vetter
btw I tried to figure out whether the accel code is of any use too,
and we don't set FBINFO_HWACCEL_COPYAREA, despite that we have an
accelerated copyarea. So I think we could delete all that code too,
since essentially unused. And aside of fbcon no one is using these
acceleration functions anyway.
-Daniel
>
> Signed-off-by: Patrik Jakobsson
> ---
> drivers/gpu/drm/gma500/framebuffer.c | 96
> drivers/gpu/drm/gma500/gtt.c | 52 +--
> drivers/gpu/drm/gma500/gtt.h | 3 -
> 3 files changed, 14 insertions(+), 137 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 5ede24fb44ae..2d64c58607f5 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -76,27 +76,6 @@ static int psbfb_setcolreg(unsigned regno, unsigned red,
> unsigned green,
> return 0;
> }
>
> -static int psbfb_pan(struct fb_var_screeninfo *var, struct fb_info *info)
> -{
> - struct drm_fb_helper *fb_helper = info->par;
> - struct drm_framebuffer *fb = fb_helper->fb;
> - struct drm_device *dev = fb->dev;
> - struct gtt_range *gtt = to_gtt_range(fb->obj[0]);
> -
> - /*
> -* We have to poke our nose in here. The core fb code assumes
> -* panning is part of the hardware that can be invoked before
> -* the actual fb is mapped. In our case that isn't quite true.
> -*/
> - if (gtt->npage) {
> - /* GTT roll shifts in 4K pages, we need to shift the right
> - number of pages */
> - int pages = info->fix.line_length >> 12;
> - psb_gtt_roll(dev, gtt, var->yoffset * pages);
> - }
> -return 0;
> -}
> -
> static vm_fault_t psbfb_vm_fault(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> @@ -176,17 +155,6 @@ static const struct fb_ops psbfb_ops = {
> .fb_sync = psbfb_sync,
> };
>
> -static const struct fb_ops psbfb_roll_ops = {
> - .owner = THIS_MODULE,
> - DRM_FB_HELPER_DEFAULT_OPS,
> - .fb_setcolreg = psbfb_setcolreg,
> - .fb_fillrect = drm_fb_helper_cfb_fillrect,
> - .fb_copyarea = drm_fb_helper_cfb_copyarea,
> - .fb_imageblit = drm_fb_helper_cfb_imageblit,
> - .fb_pan_display = psbfb_pan,
> - .fb_mmap = psbfb_mmap,
> -};
> -
> static const struct fb_ops psbfb_unaccel_ops = {
> .owner = THIS_MODULE,
> DRM_FB_HELPER_DEFAULT_OPS,
> @@ -312,8 +280,6 @@ static int psbfb_create(struct drm_fb_helper *fb_helper,
> int ret;
> struct gtt_range *backing;
> u32 bpp, depth;
> - int gtt_roll = 0;
> - int pitch_lines = 0;
>
> mode_cmd.width = sizes->surface_width;
> mode_cmd.height = sizes->surface_height;
> @@ -324,50 +290,15 @@ static int psbfb_create(struct drm_fb_helper *fb_helper,
> if (bpp == 24)
> bpp = 32;
>
> - do {
> - /*
> -* Acceleration via the GTT requires pitch to be
> -* power of two aligned. Preferably page but less
> -* is ok with some fonts
> -*/
> - mode_cmd.pitches[0] = ALIGN(mode_cmd.width * ((bpp + 7) /
> 8), 4096 >> pitch_lines);
> -
> - size = mode_cmd.pitches[0] * mode_cmd.height;
> - size = ALIGN(size, PAGE_SIZE);
> -
> - /* Allocate the fb in the GTT with stolen page backing */
> - backing = psbfb_alloc(dev, size);
> -
> - if (pitch_lines)
> - pitch_lines *= 2;
> - else
> - pitch_lines = 1;
> - gtt_roll++;
> - } while (backing == NULL && pitch_lines <= 16);
> -
> - /* The final pitch we accepted if we succeeded */
> - pitch_lines /= 2;
> -
> - if (backing == NULL) {
> - /*
> -* We couldn't get the space we wanted, fall back to the
> -* display engine requirement instead. The HW requires
> -* the pitch to be 64 byte aligned
> -*/
> -
> - gtt_roll = 0; /* Don't use GTT accelerated scrolling */
> - pitch_lines = 64;
> -
> - mode_cmd.pitches[0] = ALIGN(mode_cmd.width * ((bpp + 7) /
> 8), 64);
> -
> - size = mode_cmd.pitches[0] * mode_cmd.height;
> - size = ALIGN(size, PAGE_SIZE);
> -
> - /* Allocate the framebuffer in the GTT with stolen page
> backing */
> - backing = psb
Re: [PATCH v6 04/52] dt-bindings: memory: tegra20: emc: Document nvidia,memory-controller property
On Wed, Oct 28, 2020 at 10:23:03AM -0500, Rob Herring wrote: > On Tue, Oct 27, 2020 at 08:30:39PM +0100, Krzysztof Kozlowski wrote: > > On Tue, Oct 27, 2020 at 10:17:19PM +0300, Dmitry Osipenko wrote: > > > 27.10.2020 11:54, Krzysztof Kozlowski пишет: > > > > On Mon, Oct 26, 2020 at 01:16:47AM +0300, Dmitry Osipenko wrote: > > > >> Tegra20 External Memory Controller talks to DRAM chips and it needs to > > > >> be > > > >> reprogrammed when memory frequency changes. Tegra Memory Controller > > > >> sits > > > >> behind EMC and these controllers are tightly coupled. This patch adds > > > >> the > > > >> new phandle property which allows to properly express connection of EMC > > > >> and MC hardware in a device-tree, it also put the Tegra20 EMC binding > > > >> on > > > >> par with Tegra30+ EMC bindings, which is handy to have. > > > >> > > > >> Signed-off-by: Dmitry Osipenko > > > >> --- > > > >> .../bindings/memory-controllers/nvidia,tegra20-emc.txt | 2 ++ > > > >> 1 file changed, 2 insertions(+) > > > >> > > > >> diff --git > > > >> a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt > > > >> > > > >> b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt > > > >> index 567cffd37f3f..1b0d4417aad8 100644 > > > >> --- > > > >> a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt > > > >> +++ > > > >> b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt > > > >> @@ -12,6 +12,7 @@ Properties: > > > >>irrespective of ram-code configuration. > > > >> - interrupts : Should contain EMC General interrupt. > > > >> - clocks : Should contain EMC clock. > > > >> +- nvidia,memory-controller : Phandle of the Memory Controller node. > > > > > > > > It looks like you adding a required property which is an ABI break. > > > The T20 EMC driver is unused so far in upstream and it will become used > > > only once this series is applied. Hence it's fine to change the ABI. > > > > The ABI is not about upstream, but downstream. > > "If it's not upstream, it doesn't exist." > > Though we do have to account for out of tree users where the DT is not > in tree, but upstream drivers are used. Downstream as in vendor kernels > typically has loads of other crap. That's the case I am referring to. Maybe not in case of Tegra, but multiple other designs are quite popular in industrial uses and their DTSes were not upstreamed. This is anyway different case, as Dmitry explained - nothing got broken because not much was working before around this. > > > There are no other > > upstreams using this ABI. Unless you have in mind that existing T20 EMC > > driver was a noop, doing absolutely nothing, therefore there is no > > breakage of any other users? > > ABI breaks are ultimately up to the platform maintainers to decide. Cool! That reshapes significantly my existing point of view, especially about discussions on Exynos bindings (long time ago). Thanks for clarification. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 19/52] dt-bindings: memory: tegra124: Add memory client IDs
On Mon, 26 Oct 2020 01:17:02 +0300, Dmitry Osipenko wrote: > Each memory client have a unique hardware ID, this patch adds these IDs. > > Signed-off-by: Dmitry Osipenko > --- > include/dt-bindings/memory/tegra124-mc.h | 68 > 1 file changed, 68 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 15/52] dt-bindings: tegra30-actmon: Document OPP and interconnect properties
On Mon, 26 Oct 2020 01:16:58 +0300, Dmitry Osipenko wrote: > Document EMC DFS OPP table and interconnect paths that will be used > for scaling of system's memory bandwidth based on memory utilization > statistics. Previously ACTMON was supposed to drive EMC clock rate > directly, but now it should do it using interconnect framework in order > to support shared voltage scaling in addition to the frequency scaling. > > Signed-off-by: Dmitry Osipenko > --- > .../arm/tegra/nvidia,tegra30-actmon.txt | 25 +++ > 1 file changed, 25 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 14/52] dt-bindings: memory: tegra124: emc: Document OPP table and voltage regulator
On Mon, 26 Oct 2020 01:16:57 +0300, Dmitry Osipenko wrote: > Document new OPP table and voltage regulator properties which are needed > for supporting dynamic voltage-frequency scaling of the memory controller. > Some boards may have a fixed core voltage regulator, hence it's optional > because frequency scaling still may be desired. > > Signed-off-by: Dmitry Osipenko > --- > .../memory-controllers/nvidia,tegra124-emc.yaml | 11 +++ > 1 file changed, 11 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 11/52] dt-bindings: memory: tegra30: emc: Document OPP table and voltage regulator
On Mon, 26 Oct 2020 01:16:54 +0300, Dmitry Osipenko wrote: > Document new OPP table and voltage regulator properties which are needed > for supporting dynamic voltage-frequency scaling of the memory controller. > Some boards may have a fixed core voltage regulator, hence it's optional > because frequency scaling still may be desired. > > Signed-off-by: Dmitry Osipenko > --- > .../memory-controllers/nvidia,tegra30-emc.yaml | 12 > 1 file changed, 12 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 08/52] dt-bindings: memory: tegra20: emc: Document mfd-simple compatible and statistics sub-device
On Mon, Oct 26, 2020 at 01:16:51AM +0300, Dmitry Osipenko wrote:
> External Memory Controller can gather various hardware statistics that
> are intended to be used for debugging purposes and for dynamic frequency
> scaling of memory bus.
>
> Document the new mfd-simple compatible and EMC statistics sub-device.
It's simple-mfd.
That should only be used if the child has no dependencies on the parent
node (and driver).
> The subdev contains EMC DFS OPP table and interconnect paths to be used
> for dynamic scaling of system's memory bandwidth based on EMC utilization
> statistics.
>
> Signed-off-by: Dmitry Osipenko
> ---
> .../memory-controllers/nvidia,tegra20-emc.txt | 43 +--
> 1 file changed, 40 insertions(+), 3 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
> b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
> index 8d09b228ac42..382aabcd6952 100644
> ---
> a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
> +++
> b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
> @@ -4,7 +4,7 @@ Properties:
> - name : Should be emc
> - #address-cells : Should be 1
> - #size-cells : Should be 0
> -- compatible : Should contain "nvidia,tegra20-emc".
> +- compatible : Should contain "nvidia,tegra20-emc" and "simple-mfd".
> - reg : Offset and length of the register set for the device
> - nvidia,use-ram-code : If present, the sub-nodes will be addressed
>and chosen using the ramcode board selector. If omitted, only one
> @@ -17,7 +17,8 @@ Properties:
> - core-supply: Phandle of voltage regulator of the SoC "core" power domain.
> - operating-points-v2: See ../bindings/opp/opp.txt for details.
>
> -Child device nodes describe the memory settings for different configurations
> and clock rates.
> +Child device nodes describe the memory settings for different configurations
> and clock rates,
> +as well as EMC activity statistics collection sub-device.
>
> Example:
>
> @@ -31,17 +32,34 @@ Example:
> ...
> };
>
> + emc_bw_dfs_opp_table: emc_opp_table1 {
> + compatible = "operating-points-v2";
> +
> + opp@3600 {
> + opp-hz = /bits/ 64 <3600>;
> + opp-peak-kBps = <144000>;
> + };
> + ...
> + };
> +
> memory-controller@7000f400 {
> #address-cells = < 1 >;
> #size-cells = < 0 >;
> #interconnect-cells = < 0 >;
> - compatible = "nvidia,tegra20-emc";
> + compatible = "nvidia,tegra20-emc", "simple-mfd";
> reg = <0x7000f400 0x400>;
> interrupts = <0 78 0x04>;
> clocks = <&tegra_car TEGRA20_CLK_EMC>;
> nvidia,memory-controller = <&mc>;
> core-supply = <&core_vdd_reg>;
> operating-points-v2 = <&emc_icc_dvfs_opp_table>;
> +
> + emc-stats {
> + compatible = "nvidia,tegra20-emc-statistics";
> + operating-points-v2 = <&emc_bw_dfs_opp_table>;
> + interconnects = <&mc TEGRA20_MC_MPCORER &emc>;
> + interconnect-names = "cpu";
> + };
> }
>
>
> @@ -120,3 +138,22 @@ Properties:
>0 0 0 0 0 0 0 0 0 0 0 0 0 0
>0 0 0 0 >;
> };
> +
> +
> +
> +Embedded Memory Controller statistics gathering sub-device
> +
> +EMC statistics subdev gathers information about hardware utilization
> +which is intended to be used for debugging purposes and for dynamic
> +frequency scaling based on the collected stats.
> +
> +Properties:
> +- name : Should be emc-stats.
> +- compatible : Should contain "nvidia,tegra20-emc-statistics".
> +- operating-points-v2: See ../bindings/opp/opp.txt for details.
> +- interconnects: Should contain entries for memory clients sitting on
> + MC->EMC memory interconnect path.
> +- interconnect-names: Should include name of the interconnect path for each
> + interconnect entry. Consult TRM documentation for
> + information about available memory clients, see MEMORY
> + CONTROLLER section.
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 08/52] dt-bindings: memory: tegra20: emc: Document mfd-simple compatible and statistics sub-device
On Tue, Oct 27, 2020 at 11:18:34PM +0300, Dmitry Osipenko wrote:
> 27.10.2020 22:44, Krzysztof Kozlowski пишет:
> > On Tue, Oct 27, 2020 at 10:22:19PM +0300, Dmitry Osipenko wrote:
> >> 27.10.2020 12:02, Krzysztof Kozlowski пишет:
> @@ -31,17 +32,34 @@ Example:
> ...
> };
>
> +emc_bw_dfs_opp_table: emc_opp_table1 {
> >>> Hyphens for node name.
> >>
> >> We already use underscores for the Tegra CPU OPP table.
> >>
> >> https://elixir.bootlin.com/linux/v5.10-rc1/source/arch/arm/boot/dts/tegra20-cpu-opp.dtsi#L4
> >>
> >> What makes you think that hyphens will be a better choice? Is it a
> >> documented naming convention?
> >
> > Unfortunately that's the source of confusion also for me because
> > Devicetree spec mentions both of them (and does not specify preferences).
> >
> > The choice of dashes/hyphens comes now explicitly from all dtschema
> > files. Previously, the documentation were emails from Rob. :)
>
> Okay, I'll change it in v7. So far I haven't seen warnings about it from
> the schema-checker.
dtc with W=2 will warn.
The bigger issue is the name should be generic.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 04/52] dt-bindings: memory: tegra20: emc: Document nvidia, memory-controller property
On Mon, 26 Oct 2020 01:16:47 +0300, Dmitry Osipenko wrote: > Tegra20 External Memory Controller talks to DRAM chips and it needs to be > reprogrammed when memory frequency changes. Tegra Memory Controller sits > behind EMC and these controllers are tightly coupled. This patch adds the > new phandle property which allows to properly express connection of EMC > and MC hardware in a device-tree, it also put the Tegra20 EMC binding on > par with Tegra30+ EMC bindings, which is handy to have. > > Signed-off-by: Dmitry Osipenko > --- > .../bindings/memory-controllers/nvidia,tegra20-emc.txt | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 04/52] dt-bindings: memory: tegra20: emc: Document nvidia,memory-controller property
On Tue, Oct 27, 2020 at 08:30:39PM +0100, Krzysztof Kozlowski wrote: > On Tue, Oct 27, 2020 at 10:17:19PM +0300, Dmitry Osipenko wrote: > > 27.10.2020 11:54, Krzysztof Kozlowski пишет: > > > On Mon, Oct 26, 2020 at 01:16:47AM +0300, Dmitry Osipenko wrote: > > >> Tegra20 External Memory Controller talks to DRAM chips and it needs to be > > >> reprogrammed when memory frequency changes. Tegra Memory Controller sits > > >> behind EMC and these controllers are tightly coupled. This patch adds the > > >> new phandle property which allows to properly express connection of EMC > > >> and MC hardware in a device-tree, it also put the Tegra20 EMC binding on > > >> par with Tegra30+ EMC bindings, which is handy to have. > > >> > > >> Signed-off-by: Dmitry Osipenko > > >> --- > > >> .../bindings/memory-controllers/nvidia,tegra20-emc.txt | 2 ++ > > >> 1 file changed, 2 insertions(+) > > >> > > >> diff --git > > >> a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt > > >> > > >> b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt > > >> index 567cffd37f3f..1b0d4417aad8 100644 > > >> --- > > >> a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt > > >> +++ > > >> b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt > > >> @@ -12,6 +12,7 @@ Properties: > > >>irrespective of ram-code configuration. > > >> - interrupts : Should contain EMC General interrupt. > > >> - clocks : Should contain EMC clock. > > >> +- nvidia,memory-controller : Phandle of the Memory Controller node. > > > > > > It looks like you adding a required property which is an ABI break. > > The T20 EMC driver is unused so far in upstream and it will become used > > only once this series is applied. Hence it's fine to change the ABI. > > The ABI is not about upstream, but downstream. "If it's not upstream, it doesn't exist." Though we do have to account for out of tree users where the DT is not in tree, but upstream drivers are used. Downstream as in vendor kernels typically has loads of other crap. > There are no other > upstreams using this ABI. Unless you have in mind that existing T20 EMC > driver was a noop, doing absolutely nothing, therefore there is no > breakage of any other users? ABI breaks are ultimately up to the platform maintainers to decide. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 03/52] dt-bindings: memory: tegra20: emc: Correct registers range in example
On Mon, 26 Oct 2020 01:16:46 +0300, Dmitry Osipenko wrote: > There is superfluous zero in the registers base address and registers > size should be twice bigger. > > Signed-off-by: Dmitry Osipenko > --- > .../bindings/memory-controllers/nvidia,tegra20-emc.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/3] backlight: pwm_bl: Fix interpolation
On Wed, Oct 21, 2020 at 10:04:45PM -0700, Alexandru Stan wrote: > The previous behavior was a little unexpected, its properties/problems: > 1. It was designed to generate strictly increasing values (no repeats) > 2. It had quantization errors when calculating step size. Resulting in > unexpected jumps near the end of some segments. > > Example settings: > brightness-levels = <0 1 2 4 8 16 32 64 128 256>; > num-interpolated-steps = <16>; > > Whenever num-interpolated-steps was larger than the distance > between 2 consecutive brightness levels the table would get really > discontinuous. The slope of the interpolation would stick with > integers only and if it was 0 the whole line segment would get skipped. > > The distances between 1 2 4 and 8 would be 1 (property #1 fighting us), > and only starting with 16 it would start to interpolate properly. > > Property #1 is not enough. The goal here is more than just monotonically > increasing. We should still care about the shape of the curve. Repeated > points might be desired if we're in the part of the curve where we want > to go slow (aka slope near 0). > > Problem #2 is plainly a bug. Imagine if the 64 entry was 63 instead, > the calculated slope on the 32-63 segment will be almost half as it > should be. > > The most expected and simplest algorithm for interpolation is linear > interpolation, which would handle both problems. > Let's just implement that! > > Take pairs of points from the brightness-levels array and linearly > interpolate between them. On the X axis (what userspace sees) we'll > now have equally sized intervals (num-interpolated-steps sized, > as opposed to before where we were at the mercy of quantization). > > END INTERESTING. I guess this a copy 'n paste error from some internal log book? Better removed... but I won't lose sleep over it. > Signed-off-by: Alexandru Stan I've waited a bit to see how strong the feelings were w.r.t. getting rid of the division from the table initialization. It was something I was aware of during an earlier review but it was below my personal nitpicking threshold (which could be badly calibrated... hence waiting). However it's all been quiet so: Reviewed-by: Daniel Thompson Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/gma500: avoid Woverride-init warning
On Tue, Oct 27, 2020 at 5:50 PM Arnd Bergmann wrote:
>
> On Tue, Oct 27, 2020 at 10:54 AM Patrik Jakobsson
> wrote:
> > On Tue, Oct 27, 2020 at 10:33 AM Daniel Vetter wrote:
> > > On Mon, Oct 26, 2020 at 08:41:04PM +0100, Arnd Bergmann wrote:
> > > > From: Arnd Bergmann
> > > >
> > > > gcc -Wextra notices that one of the fields in psbfb_roll_ops has two
> > > > initializers:
> > > >
> > > > drivers/gpu/drm/gma500/framebuffer.c:185:20: warning: initialized field
> > > > overwritten [-Woverride-init]
> > > >
> > > > Open-code this instead, leaving out the extraneous initializers for
> > > > .fb_pan_display.
> > > >
> > > > Fixes: 3da6c2f3b730 ("drm/gma500: use DRM_FB_HELPER_DEFAULT_OPS for
> > > > fb_ops")
> > > > Signed-off-by: Arnd Bergmann
> > >
> > > Scrollback is dead, so I'm not sure it's even worth to keep all this. I'd
> > > just garbage-collect this, maybe als the entire accelerator code and just
> > > leave psbfb_unaccel_ops behind ...
> > > -Daniel
> >
> > That's been my idea for quite some time. The gtt roll code is also
> > broken in multi display setups.
> >
> > Arnd, I can take care of this unless you feel an urge to do it yourself.
>
> That would be good, thanks
Should be fixed with:
https://patchwork.freedesktop.org/patch/397482/?series=83153&rev=1
>
> I have no specific interest in the drm drivers, this is just part of a
> larger work to enable more of the W=1 options across the kernel
> by default, after all the existing warnings are addressed.
>
>Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/msm: Fix duplicate gpu node in icc summary
The dev_pm_opp_of_add_table() api initializes the icc nodes for gpu
indirectly. So we can avoid using of_icc_get() api in the common
probe path. To improve this, move of_icc_get() to target specific code
where it is required.
This patch helps to fix duplicate gpu node listed in the interconnect
summary from the debugfs.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
1. Minor updates (Jordan)
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 21 +++--
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 20 ++--
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 32 +---
3 files changed, 38 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index f29c77d..93da668 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -519,6 +519,8 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+ struct icc_path *ocmem_icc_path;
+ struct icc_path *icc_path;
int ret;
if (!pdev) {
@@ -566,13 +568,28 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
goto fail;
}
+ icc_path = devm_of_icc_get(&pdev->dev, "gfx-mem");
+ ret = IS_ERR(icc_path);
+ if (ret)
+ goto fail;
+
+ ocmem_icc_path = devm_of_icc_get(&pdev->dev, "ocmem");
+ ret = IS_ERR(ocmem_icc_path);
+ if (ret) {
+ /* allow -ENODATA, ocmem icc is optional */
+ if (ret != -ENODATA)
+ goto fail;
+ ocmem_icc_path = NULL;
+ }
+
+
/*
* Set the ICC path to maximum speed for now by multiplying the fastest
* frequency by the bus width (8). We'll want to scale this later on to
* improve battery life.
*/
- icc_set_bw(gpu->icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8);
- icc_set_bw(gpu->ocmem_icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8);
+ icc_set_bw(icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8);
+ icc_set_bw(ocmem_icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8);
return gpu;
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 2b93b33..c0be3a0 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -648,6 +648,8 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+ struct icc_path *ocmem_icc_path;
+ struct icc_path *icc_path;
int ret;
if (!pdev) {
@@ -694,13 +696,27 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
goto fail;
}
+ icc_path = devm_of_icc_get(&pdev->dev, "gfx-mem");
+ ret = IS_ERR(icc_path);
+ if (ret)
+ goto fail;
+
+ ocmem_icc_path = devm_of_icc_get(&pdev->dev, "ocmem");
+ ret = IS_ERR(ocmem_icc_path);
+ if (ret) {
+ /* allow -ENODATA, ocmem icc is optional */
+ if (ret != -ENODATA)
+ goto fail;
+ ocmem_icc_path = NULL;
+ }
+
/*
* Set the ICC path to maximum speed for now by multiplying the fastest
* frequency by the bus width (8). We'll want to scale this later on to
* improve battery life.
*/
- icc_set_bw(gpu->icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8);
- icc_set_bw(gpu->ocmem_icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8);
+ icc_set_bw(icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8);
+ icc_set_bw(ocmem_icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8);
return gpu;
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index fd8f491..ddbd863 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -899,7 +899,6 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
struct adreno_platform_config *config = dev->platform_data;
struct msm_gpu_config adreno_gpu_config = { 0 };
struct msm_gpu *gpu = &adreno_gpu->base;
- int ret;
adreno_gpu->funcs = funcs;
adreno_gpu->info = adreno_info(config->rev);
@@ -918,37 +917,8 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
pm_runtime_use_autosuspend(dev);
pm_runtime_enable(dev);
- ret = msm_gpu_init(drm, pdev, &adreno_gpu->base, &funcs->base,
+ return msm_gpu_init(drm, pdev, &adreno_gpu->base, &funcs->base,
adreno_gpu->info->name, &adreno_gpu_config);
- if (ret)
- return ret;
-
- /*
-* The legacy case, before "interconnect-
[PATCH] drm/gma500: Remove GTT roll support
GTT roll support was used to accelerate fb panning on some machines.
Unfortunately this never worked properly with multiple monitors and
caused issues on others where the framebuffer wouldn't fit in stolen
memory. Let's remove it!
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/framebuffer.c | 96
drivers/gpu/drm/gma500/gtt.c | 52 +--
drivers/gpu/drm/gma500/gtt.h | 3 -
3 files changed, 14 insertions(+), 137 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 5ede24fb44ae..2d64c58607f5 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -76,27 +76,6 @@ static int psbfb_setcolreg(unsigned regno, unsigned red,
unsigned green,
return 0;
}
-static int psbfb_pan(struct fb_var_screeninfo *var, struct fb_info *info)
-{
- struct drm_fb_helper *fb_helper = info->par;
- struct drm_framebuffer *fb = fb_helper->fb;
- struct drm_device *dev = fb->dev;
- struct gtt_range *gtt = to_gtt_range(fb->obj[0]);
-
- /*
-* We have to poke our nose in here. The core fb code assumes
-* panning is part of the hardware that can be invoked before
-* the actual fb is mapped. In our case that isn't quite true.
-*/
- if (gtt->npage) {
- /* GTT roll shifts in 4K pages, we need to shift the right
- number of pages */
- int pages = info->fix.line_length >> 12;
- psb_gtt_roll(dev, gtt, var->yoffset * pages);
- }
-return 0;
-}
-
static vm_fault_t psbfb_vm_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
@@ -176,17 +155,6 @@ static const struct fb_ops psbfb_ops = {
.fb_sync = psbfb_sync,
};
-static const struct fb_ops psbfb_roll_ops = {
- .owner = THIS_MODULE,
- DRM_FB_HELPER_DEFAULT_OPS,
- .fb_setcolreg = psbfb_setcolreg,
- .fb_fillrect = drm_fb_helper_cfb_fillrect,
- .fb_copyarea = drm_fb_helper_cfb_copyarea,
- .fb_imageblit = drm_fb_helper_cfb_imageblit,
- .fb_pan_display = psbfb_pan,
- .fb_mmap = psbfb_mmap,
-};
-
static const struct fb_ops psbfb_unaccel_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
@@ -312,8 +280,6 @@ static int psbfb_create(struct drm_fb_helper *fb_helper,
int ret;
struct gtt_range *backing;
u32 bpp, depth;
- int gtt_roll = 0;
- int pitch_lines = 0;
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
@@ -324,50 +290,15 @@ static int psbfb_create(struct drm_fb_helper *fb_helper,
if (bpp == 24)
bpp = 32;
- do {
- /*
-* Acceleration via the GTT requires pitch to be
-* power of two aligned. Preferably page but less
-* is ok with some fonts
-*/
- mode_cmd.pitches[0] = ALIGN(mode_cmd.width * ((bpp + 7) / 8),
4096 >> pitch_lines);
-
- size = mode_cmd.pitches[0] * mode_cmd.height;
- size = ALIGN(size, PAGE_SIZE);
-
- /* Allocate the fb in the GTT with stolen page backing */
- backing = psbfb_alloc(dev, size);
-
- if (pitch_lines)
- pitch_lines *= 2;
- else
- pitch_lines = 1;
- gtt_roll++;
- } while (backing == NULL && pitch_lines <= 16);
-
- /* The final pitch we accepted if we succeeded */
- pitch_lines /= 2;
-
- if (backing == NULL) {
- /*
-* We couldn't get the space we wanted, fall back to the
-* display engine requirement instead. The HW requires
-* the pitch to be 64 byte aligned
-*/
-
- gtt_roll = 0; /* Don't use GTT accelerated scrolling */
- pitch_lines = 64;
-
- mode_cmd.pitches[0] = ALIGN(mode_cmd.width * ((bpp + 7) / 8),
64);
-
- size = mode_cmd.pitches[0] * mode_cmd.height;
- size = ALIGN(size, PAGE_SIZE);
-
- /* Allocate the framebuffer in the GTT with stolen page backing
*/
- backing = psbfb_alloc(dev, size);
- if (backing == NULL)
- return -ENOMEM;
- }
+ mode_cmd.pitches[0] = ALIGN(mode_cmd.width * DIV_ROUND_UP(bpp, 8), 64);
+
+ size = mode_cmd.pitches[0] * mode_cmd.height;
+ size = ALIGN(size, PAGE_SIZE);
+
+ /* Allocate the framebuffer in the GTT with stolen page backing */
+ backing = psbfb_alloc(dev, size);
+ if (backing == NULL)
+ return -ENOMEM;
memset(dev_priv->vram_addr + backing->offset, 0, size);
@@ -387,17 +318,14 @@ static int psbfb_create(struct drm_fb_helper *fb_helper,
fb_hel
[PATCH v2 1/2] drm/msm: Implement shutdown callback for adreno
Implement the shutdown callback for adreno gpu platform device
to safely shutdown it before a system reboot. This helps to avoid
futher transactions from gpu after the smmu is moved to bypass mode.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 58e03b2..87c8b03 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -475,6 +475,11 @@ static int adreno_remove(struct platform_device *pdev)
return 0;
}
+static void adreno_shutdown(struct platform_device *pdev)
+{
+ pm_runtime_force_suspend(&pdev->dev);
+}
+
static const struct of_device_id dt_match[] = {
{ .compatible = "qcom,adreno" },
{ .compatible = "qcom,adreno-3xx" },
@@ -509,6 +514,7 @@ static const struct dev_pm_ops adreno_pm_ops = {
static struct platform_driver adreno_driver = {
.probe = adreno_probe,
.remove = adreno_remove,
+ .shutdown = adreno_shutdown,
.driver = {
.name = "adreno",
.of_match_table = dt_match,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 19/33] docs: ABI: stable: make files ReST compatible
From: Mauro Carvalho Chehab Several entries at the stable ABI files won't parse if we pass them directly to the ReST output. Adjust them, in order to allow adding their contents as-is at the stable ABI book. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/stable/firewire-cdev| 4 + Documentation/ABI/stable/sysfs-acpi-pmprofile | 22 +++-- Documentation/ABI/stable/sysfs-bus-firewire | 3 + Documentation/ABI/stable/sysfs-bus-nvmem | 19 ++-- Documentation/ABI/stable/sysfs-bus-usb| 6 +- .../ABI/stable/sysfs-class-backlight | 1 + .../ABI/stable/sysfs-class-infiniband | 93 +-- Documentation/ABI/stable/sysfs-class-rfkill | 13 ++- Documentation/ABI/stable/sysfs-class-tpm | 90 +- Documentation/ABI/stable/sysfs-devices| 5 +- Documentation/ABI/stable/sysfs-driver-ib_srp | 1 + .../ABI/stable/sysfs-firmware-efi-vars| 4 + .../ABI/stable/sysfs-firmware-opal-dump | 5 + .../ABI/stable/sysfs-firmware-opal-elog | 2 + Documentation/ABI/stable/sysfs-hypervisor-xen | 3 + Documentation/ABI/stable/vdso | 5 +- 16 files changed, 176 insertions(+), 100 deletions(-) diff --git a/Documentation/ABI/stable/firewire-cdev b/Documentation/ABI/stable/firewire-cdev index f72ed653878a..c9e8ff026154 100644 --- a/Documentation/ABI/stable/firewire-cdev +++ b/Documentation/ABI/stable/firewire-cdev @@ -14,12 +14,14 @@ Description: Each /dev/fw* is associated with one IEEE 1394 node, which can be remote or local nodes. Operations on a /dev/fw* file have different scope: + - The 1394 node which is associated with the file: - Asynchronous request transmission - Get the Configuration ROM - Query node ID - Query maximum speed of the path between this node and local node + - The 1394 bus (i.e. "card") to which the node is attached to: - Isochronous stream transmission and reception - Asynchronous stream transmission and reception @@ -31,6 +33,7 @@ Description: manager - Query cycle time - Bus reset initiation, bus reset event reception + - All 1394 buses: - Allocation of IEEE 1212 address ranges on the local link layers, reception of inbound requests to such @@ -43,6 +46,7 @@ Description: userland implement different access permission models, some operations are restricted to /dev/fw* files that are associated with a local node: + - Addition of descriptors or directories to the local nodes' Configuration ROM - PHY packet transmission and reception diff --git a/Documentation/ABI/stable/sysfs-acpi-pmprofile b/Documentation/ABI/stable/sysfs-acpi-pmprofile index 964c7a8afb26..fd97d22b677f 100644 --- a/Documentation/ABI/stable/sysfs-acpi-pmprofile +++ b/Documentation/ABI/stable/sysfs-acpi-pmprofile @@ -6,17 +6,21 @@ Description: The ACPI pm_profile sysfs interface exports the platform power management (and performance) requirement expectations as provided by BIOS. The integer value is directly passed as retrieved from the FADT ACPI table. -Values: For possible values see ACPI specification: + +Values:For possible values see ACPI specification: 5.2.9 Fixed ACPI Description Table (FADT) Field: Preferred_PM_Profile Currently these values are defined by spec: - 0 Unspecified - 1 Desktop - 2 Mobile - 3 Workstation - 4 Enterprise Server - 5 SOHO Server - 6 Appliance PC - 7 Performance Server + + == = + 0 Unspecified + 1 Desktop + 2 Mobile + 3 Workstation + 4 Enterprise Server + 5 SOHO Server + 6 Appliance PC + 7 Performance Server >7 Reserved + == = diff --git a/Documentation/ABI/stable/sysfs-bus-firewire b/Documentation/ABI/stable/sysfs-bus-firewire index 41e5a0cd1e3e..9ac9eddb82ef 100644 --- a/Documentation/ABI/stable/sysfs-bus-firewire +++ b/Documentation/ABI/stable/sysfs-bus-firewire @@ -47,6 +47,7 @@ Description: IEEE 1394 node device attribute. Read-only and immutable. Values:1: The sysfs entry represents a local node (a controller card). +
Re: [PATCH] drm/vc4: Rework the structure convertion functions
s/convertion/conversion in subject line
On Wed, 28 Oct 2020 at 12:37, Maxime Ripard wrote:
>
> Most of the helpers to retrieve vc4 structures from the DRM base structures
> rely on the fact that the first member of the vc4 structure is the DRM one
> and just cast the pointers between them.
>
> However, this is pretty fragile especially since there's no check to make
> sure that the DRM structure is indeed at the offset 0 in the structure, so
> let's use container_of to make it more robust.
>
> Signed-off-by: Maxime Ripard
Otherwise
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_drv.h | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 236dde0bb9a1..836fdca5e643 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -287,7 +287,7 @@ struct vc4_bo {
> static inline struct vc4_bo *
> to_vc4_bo(struct drm_gem_object *bo)
> {
> - return (struct vc4_bo *)bo;
> + return container_of(to_drm_gem_cma_obj(bo), struct vc4_bo, base);
> }
>
> struct vc4_fence {
> @@ -300,7 +300,7 @@ struct vc4_fence {
> static inline struct vc4_fence *
> to_vc4_fence(struct dma_fence *fence)
> {
> - return (struct vc4_fence *)fence;
> + return container_of(fence, struct vc4_fence, base);
> }
>
> struct vc4_seqno_cb {
> @@ -347,7 +347,7 @@ struct vc4_plane {
> static inline struct vc4_plane *
> to_vc4_plane(struct drm_plane *plane)
> {
> - return (struct vc4_plane *)plane;
> + return container_of(plane, struct vc4_plane, base);
> }
>
> enum vc4_scaling_mode {
> @@ -423,7 +423,7 @@ struct vc4_plane_state {
> static inline struct vc4_plane_state *
> to_vc4_plane_state(struct drm_plane_state *state)
> {
> - return (struct vc4_plane_state *)state;
> + return container_of(state, struct vc4_plane_state, base);
> }
>
> enum vc4_encoder_type {
> @@ -499,7 +499,7 @@ struct vc4_crtc {
> static inline struct vc4_crtc *
> to_vc4_crtc(struct drm_crtc *crtc)
> {
> - return (struct vc4_crtc *)crtc;
> + return container_of(crtc, struct vc4_crtc, base);
> }
>
> static inline const struct vc4_crtc_data *
> @@ -537,7 +537,7 @@ struct vc4_crtc_state {
> static inline struct vc4_crtc_state *
> to_vc4_crtc_state(struct drm_crtc_state *crtc_state)
> {
> - return (struct vc4_crtc_state *)crtc_state;
> + return container_of(crtc_state, struct vc4_crtc_state, base);
> }
>
> #define V3D_READ(offset) readl(vc4->v3d->regs + offset)
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: hdmi: Block odd horizontal timings
Hi Maxime
On Fri, 25 Sep 2020 at 14:00, Maxime Ripard wrote:
>
> The FIFO between the pixelvalve and the HDMI controller runs at 2 pixels
> per clock cycle, and cannot deal with odd timings.
>
> Let's reject any mode with such timings.
>
> Signed-off-by: Maxime Ripard
It's unsupported due to the architecture rather than broken.
I'd hope the compiler would convert "% 2" to "& 1" in these cases, but
it's not a critical performance path anyway.
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 12
> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 1c4dc774d56e..acfb4e235214 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -879,6 +879,11 @@ static int vc4_hdmi_encoder_atomic_check(struct
> drm_encoder *encoder,
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> unsigned long long pixel_rate = mode->clock * 1000;
>
> + if (vc4_hdmi->variant->broken_odd_h_timings &&
> + ((mode->hdisplay % 2) || (mode->hsync_start % 2) ||
> +(mode->hsync_end % 2) || (mode->htotal % 2)))
> + return -EINVAL;
> +
> if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> pixel_rate *= 2;
>
> @@ -901,6 +906,11 @@ vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
> {
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
>
> + if (vc4_hdmi->variant->broken_odd_h_timings &&
> + ((mode->hdisplay % 2) || (mode->hsync_start % 2) ||
> +(mode->hsync_end % 2) || (mode->htotal % 2)))
> + return MODE_H_ILLEGAL;
> +
> if ((mode->clock * 1000) > vc4_hdmi->variant->max_pixel_clock)
> return MODE_CLOCK_HIGH;
>
> @@ -1950,6 +1960,7 @@ static const struct vc4_hdmi_variant
> bcm2711_hdmi0_variant = {
> PHY_LANE_2,
> PHY_LANE_CK,
> },
> + .broken_odd_h_timings = true,
>
> .init_resources = vc5_hdmi_init_resources,
> .csc_setup = vc5_hdmi_csc_setup,
> @@ -1975,6 +1986,7 @@ static const struct vc4_hdmi_variant
> bcm2711_hdmi1_variant = {
> PHY_LANE_CK,
> PHY_LANE_2,
> },
> + .broken_odd_h_timings = true,
>
> .init_resources = vc5_hdmi_init_resources,
> .csc_setup = vc5_hdmi_csc_setup,
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index af45b0d81dec..40e51ece8efe 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -62,6 +62,9 @@ struct vc4_hdmi_variant {
> */
> enum vc4_hdmi_phy_channel phy_lane_mapping[4];
>
> + /* The BCM2711 cannot deal with odd horizontal pixel timings */
> + bool broken_odd_h_timings;
> +
> /* Callback to get the resources (memory region, interrupts,
> * clocks, etc) for that variant.
> */
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] arm64: dts: qcom: sc7180: Add gpu cooling support
Add cooling-cells property and the cooling maps for the gpu tzones
to support GPU cooling.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index d46b383..a7ea029 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2,7 +2,7 @@
/*
* SC7180 SoC device tree source
*
- * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019-20, The Linux Foundation. All rights reserved.
*/
#include
@@ -1886,6 +1886,8 @@
operating-points-v2 = <&gpu_opp_table>;
qcom,gmu = <&gmu>;
+ #cooling-cells = <2>;
+
interconnects = <&gem_noc MASTER_GFX3D &mc_virt
SLAVE_EBI1>;
interconnect-names = "gfx-mem";
@@ -3825,16 +3827,16 @@
};
gpuss0-thermal {
- polling-delay-passive = <0>;
+ polling-delay-passive = <100>;
polling-delay = <0>;
thermal-sensors = <&tsens0 13>;
trips {
gpuss0_alert0: trip-point0 {
- temperature = <9>;
+ temperature = <95000>;
hysteresis = <2000>;
- type = "hot";
+ type = "passive";
};
gpuss0_crit: gpuss0_crit {
@@ -3843,19 +3845,26 @@
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss0_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss1-thermal {
- polling-delay-passive = <0>;
+ polling-delay-passive = <100>;
polling-delay = <0>;
thermal-sensors = <&tsens0 14>;
trips {
gpuss1_alert0: trip-point0 {
- temperature = <9>;
+ temperature = <95000>;
hysteresis = <2000>;
- type = "hot";
+ type = "passive";
};
gpuss1_crit: gpuss1_crit {
@@ -3864,6 +3873,13 @@
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss0_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
+ };
+ };
};
aoss1-thermal {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] dt-bindings: drm/msm/gpu: Add cooling device support
Add cooling device support to gpu. A cooling device is bound to a
thermal zone to allow thermal mitigation.
Signed-off-by: Akhil P Oommen
---
Documentation/devicetree/bindings/display/msm/gpu.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 1af0ff1..090dcb3 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -39,6 +39,10 @@ Required properties:
a4xx Snapdragon SoCs. See
Documentation/devicetree/bindings/sram/qcom,ocmem.yaml.
+Optional properties:
+- #cooling-cells: The value must be 2. For details, please refer
+ Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml.
+
Example 3xx/4xx:
/ {
@@ -61,6 +65,7 @@ Example 3xx/4xx:
power-domains = <&mmcc OXILICX_GDSC>;
operating-points-v2 = <&gpu_opp_table>;
iommus = <&gpu_iommu 0>;
+ #cooling-cells = <2>;
};
gpu_sram: ocmem@fdd0 {
@@ -98,6 +103,8 @@ Example a6xx (with GMU):
reg = <0x500 0x4>, <0x509e000 0x10>;
reg-names = "kgsl_3d0_reg_memory", "cx_mem";
+ #cooling-cells = <2>;
+
/*
* Look ma, no clocks! The GPU clocks and power are
* controlled entirely by the GMU
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/msm: Add support for GPU cooling
Register GPU as a devfreq cooling device so that it can be passively
cooled by the thermal framework.
Signed-off-by: Akhil P Oommen
---
Changes in v3:
1. Minor fix in binding documentation (RobH)
Changes in v2:
1. Update the dt bindings documentation
drivers/gpu/drm/msm/msm_gpu.c | 12
drivers/gpu/drm/msm/msm_gpu.h | 2 ++
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 55d1648..9f9db46 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -107,9 +108,18 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
if (IS_ERR(gpu->devfreq.devfreq)) {
DRM_DEV_ERROR(&gpu->pdev->dev, "Couldn't initialize GPU
devfreq\n");
gpu->devfreq.devfreq = NULL;
+ return;
}
devfreq_suspend_device(gpu->devfreq.devfreq);
+
+ gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
+ gpu->devfreq.devfreq);
+ if (IS_ERR(gpu->cooling)) {
+ DRM_DEV_ERROR(&gpu->pdev->dev,
+ "Couldn't register GPU cooling device\n");
+ gpu->cooling = NULL;
+ }
}
static int enable_pwrrail(struct msm_gpu *gpu)
@@ -1005,4 +1015,6 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
gpu->aspace->mmu->funcs->detach(gpu->aspace->mmu);
msm_gem_address_space_put(gpu->aspace);
}
+
+ devfreq_cooling_unregister(gpu->cooling);
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 6c9e1fd..9a8f20d 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -147,6 +147,8 @@ struct msm_gpu {
struct msm_gpu_state *crashstate;
/* True if the hardware supports expanded apriv (a650 and newer) */
bool hw_apriv;
+
+ struct thermal_cooling_device *cooling;
};
static inline struct msm_gpu *dev_to_gpu(struct device *dev)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: hdmi: Add a name to the codec DAI component
Hi Maxime
On Wed, 8 Jul 2020 at 15:46, Maxime Ripard wrote:
>
> Since the components for a given device in ASoC are identified by their
> name, it makes sense to add one even though it's not strictly necessary.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 15a11cd4de25..a057db0d9baa 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -983,6 +983,7 @@ static const struct snd_soc_dapm_route
> vc4_hdmi_audio_routes[] = {
> };
>
> static const struct snd_soc_component_driver vc4_hdmi_audio_component_drv = {
> + .name = "vc4-hdmi-codec-dai-component",
> .controls = vc4_hdmi_audio_controls,
> .num_controls = ARRAY_SIZE(vc4_hdmi_audio_controls),
> .dapm_widgets = vc4_hdmi_audio_widgets,
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/65] drm/malidp: Annotate dma-fence critical section in commit path
On Fri, Oct 23, 2020 at 02:21:21PM +0200, Daniel Vetter wrote: > Again needs to be put right after the call to > drm_atomic_helper_commit_hw_done(), since that's the last thing which > can hold up a subsequent atomic commit. > > No surprises here. > > Signed-off-by: Daniel Vetter > Cc: "James (Qian) Wang" > Cc: Liviu Dudau Acked-by: Liviu Dudau Thanks for the patch! Best regards, Liviu > Cc: Mihail Atanassov > --- > drivers/gpu/drm/arm/malidp_drv.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c > b/drivers/gpu/drm/arm/malidp_drv.c > index 69fee05c256c..26e60401a8e1 100644 > --- a/drivers/gpu/drm/arm/malidp_drv.c > +++ b/drivers/gpu/drm/arm/malidp_drv.c > @@ -234,6 +234,7 @@ static void malidp_atomic_commit_tail(struct > drm_atomic_state *state) > struct drm_crtc *crtc; > struct drm_crtc_state *old_crtc_state; > int i; > + bool fence_cookie = dma_fence_begin_signalling(); > > pm_runtime_get_sync(drm->dev); > > @@ -260,6 +261,8 @@ static void malidp_atomic_commit_tail(struct > drm_atomic_state *state) > > malidp_atomic_commit_hw_done(state); > > + dma_fence_end_signalling(fence_cookie); > + > pm_runtime_put(drm->dev); > > drm_atomic_helper_cleanup_planes(drm, state); > -- > 2.28.0 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/amd/pm: fix out-of-bound read on pptable->SkuReserved
From: Colin Ian King
A recent change added two uint16_t elements to PPTable_t and reduced the
uint32_t array down to 8 elements. This results in the dev_info printing
of pptable->SkuReserved[8] accessing a value that is out-of-range on
array SkuReserved. The array has been shrunk by 1 element, so remove
this extraneous dev_info message.
Addresses-Coverity: ("Out-of-bounds read")
Fixes: 1dc3c5a95b08 ("drm/amd/pm: update driver if file for sienna cichlid")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index fa3842f460fc..0600befc6e4c 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -2279,7 +2279,6 @@ static void sienna_cichlid_dump_pptable(struct
smu_context *smu)
dev_info(smu->adev->dev, "SkuReserved[5] = 0x%x\n",
pptable->SkuReserved[5]);
dev_info(smu->adev->dev, "SkuReserved[6] = 0x%x\n",
pptable->SkuReserved[6]);
dev_info(smu->adev->dev, "SkuReserved[7] = 0x%x\n",
pptable->SkuReserved[7]);
- dev_info(smu->adev->dev, "SkuReserved[8] = 0x%x\n",
pptable->SkuReserved[8]);
dev_info(smu->adev->dev, "GamingClk[0] = 0x%x\n",
pptable->GamingClk[0]);
dev_info(smu->adev->dev, "GamingClk[1] = 0x%x\n",
pptable->GamingClk[1]);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Warn on pinning without holding a reference
Am 28.10.20 um 12:31 schrieb Daniel Vetter:
Not technically a problem for ttm, but very likely a driver bug and
pretty big time confusing for reviewing code.
So warn about it, both at cleanup time (so we catch these for sure)
and at pin/unpin time (so we know who's the culprit).
Signed-off-by: Daniel Vetter
Cc: Christian Koenig
Cc: Huang Rui
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
include/drm/ttm/ttm_bo_api.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index f51b5e20fa17..a011072ab61d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -509,7 +509,7 @@ static void ttm_bo_release(struct kref *kref)
* shrinkers, now that they are queued for
* destruction.
*/
- if (bo->pin_count) {
+ if (WARN_ON(bo->pin_count)) {
bo->pin_count = 0;
ttm_bo_del_from_lru(bo);
ttm_bo_add_mem_to_lru(bo, &bo->mem);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 37102e45e496..b45aee23d7d0 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -571,6 +571,7 @@ static inline bool ttm_bo_uses_embedded_gem_object(struct
ttm_buffer_object *bo)
static inline void ttm_bo_pin(struct ttm_buffer_object *bo)
{
dma_resv_assert_held(bo->base.resv);
+ WARN_ON_ONCE(!kref_read(&bo->kref));
++bo->pin_count;
}
@@ -584,6 +585,7 @@ static inline void ttm_bo_unpin(struct ttm_buffer_object *bo)
{
dma_resv_assert_held(bo->base.resv);
WARN_ON_ONCE(!bo->pin_count);
+ WARN_ON_ONCE(!kref_read(&bo->kref));
--bo->pin_count;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection
Ok, I have initiated the steps to upgrade the CI machine's silicon & BIOS. Thanks Hariom Pandey > -Original Message- > From: Vivi, Rodrigo > Sent: Wednesday, October 28, 2020 5:24 PM > To: Pandey, Hariom ; Szwichtenberg, Radoslaw > > Cc: Chris Wilson ; Ausmus, James > ; Nikula, Jani ; intel- > g...@lists.freedesktop.org; Souza, Jose ; dri-devel > ; Surendrakumar Upadhyay, TejaskumarX > ; K, SrinivasX > ; Meena, Mahesh > Subject: Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe > protection > > > > > On Oct 27, 2020, at 11:49 PM, Pandey, Hariom > wrote: > > > > Hi Chris, > > > > Awaiting your kind response here… > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9208/fi-ehl- > 1/igt@i915_selftest@live@gt_pm.html > "Did not enter RC6!" > > Chris already told that we need to get RC6 working on CI. > If we need BIOS update or machine replacement there we need to work with > CI team to make that happen. > > > > > Thanks > > Hariom Pandey > > > > From: Pandey, Hariom > > Sent: Tuesday, October 20, 2020 9:28 PM > > To: Chris Wilson > > Cc: Ausmus, James ; Nikula, Jani > > ; intel-gfx@ > intel-...@lists.freedesktop.org>; Souza, Jose ; > > dri-devel@ ; > > Surendrakumar Upadhyay, TejaskumarX > > ; K, SrinivasX > > ; Vivi, Rodrigo ; > > Meena, Mahesh > > Subject: RE: [Intel-gfx] [PATCH] drm/i915/ehl: Remove > > require_force_probe protection > > > > Hi Chris, > > > > We have run RC6 test cases as recently as 4 days ago on EHL and they have > passed. Below are the pass log links & attached email has the DRM/IGT tag > where they have passed. We are finding that the “EHL BAT setup” is not upto > date in terms of Silicon & BIOS which we are working to upgrade. But just for > that, should we block this patch? Just trying to understand as there is no > inherent or latent RC6 issue anymore. > > > > • igt@i915_pm_rc6_residency@rc6-accuracy --- PASS - Log • > > igt@i915_pm_rc6_residency@rc6-fence --- PASS – Log • > > igt@i915_pm_rc6_residency@rc6-idle --- PASS - Log • > > igt@perf@rc6-disable --- PASS - Log • igt@perf_pmu@rc6 --- PASS - Log > > • igt@perf_pmu@rc6-runtime-pm --- PASS - Log • > > igt@perf_pmu@rc6-runtime-pm-long --- PASS – Log > > > > > > Thanks > > Hariom Pandey > > > > > -Original Message- > > > From: Chris Wilson > > > Sent: Tuesday, October 20, 2020 12:04 AM > > > To: K, SrinivasX ; Vivi, Rodrigo > > > > > > Cc: Pandey, Hariom ; Ausmus, James > > > ; Nikula, Jani ; > > > intel-gfx@ ; > > > Souza, Jose ; dri-devel@ > > > ; > > > Surendrakumar Upadhyay, TejaskumarX > > > > > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove > > > require_force_probe protection > > > > > > Quoting Rodrigo Vivi (2020-10-19 19:29:36) > > > > > > > > I just checked the CI picture and it looks much better indeed. > > > > > > > > Only bad case being the gt_pm, which is also failing on other platforms. > > > > > > Not nearly in the same manner. CI is indicating that there is no RC6 > > > entry and no power saving at all; neither in the selftests nor visible > > > from > userspace. > > > That is a critical battery eating bug. > > > > > > If there's a patch to fix it for ehl and jsl, send it to CI for proving. > > > -Chris > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection
> On Oct 27, 2020, at 11:49 PM, Pandey, Hariom wrote: > > Hi Chris, > > Awaiting your kind response here… https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9208/fi-ehl-1/igt@i915_selftest@live@gt_pm.html "Did not enter RC6!" Chris already told that we need to get RC6 working on CI. If we need BIOS update or machine replacement there we need to work with CI team to make that happen. > > Thanks > Hariom Pandey > > From: Pandey, Hariom > Sent: Tuesday, October 20, 2020 9:28 PM > To: Chris Wilson > Cc: Ausmus, James ; Nikula, Jani > ; intel-gfx@ intel-...@lists.freedesktop.org>; Souza, Jose ; > dri-devel@ ; > Surendrakumar Upadhyay, TejaskumarX > ; K, SrinivasX > ; Vivi, Rodrigo ; Meena, > Mahesh > Subject: RE: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe > protection > > Hi Chris, > > We have run RC6 test cases as recently as 4 days ago on EHL and they have > passed. Below are the pass log links & attached email has the DRM/IGT tag > where they have passed. We are finding that the “EHL BAT setup” is not upto > date in terms of Silicon & BIOS which we are working to upgrade. But just for > that, should we block this patch? Just trying to understand as there is no > inherent or latent RC6 issue anymore. > > • igt@i915_pm_rc6_residency@rc6-accuracy --- PASS - Log > • igt@i915_pm_rc6_residency@rc6-fence --- PASS – Log > • igt@i915_pm_rc6_residency@rc6-idle --- PASS - Log > • igt@perf@rc6-disable --- PASS - Log > • igt@perf_pmu@rc6 --- PASS - Log > • igt@perf_pmu@rc6-runtime-pm --- PASS - Log > • igt@perf_pmu@rc6-runtime-pm-long --- PASS – Log > > > Thanks > Hariom Pandey > > > -Original Message- > > From: Chris Wilson > > Sent: Tuesday, October 20, 2020 12:04 AM > > To: K, SrinivasX ; Vivi, Rodrigo > > > > Cc: Pandey, Hariom ; Ausmus, James > > ; Nikula, Jani ; intel-gfx@ > > ; Souza, Jose > > ; dri-devel@ > de...@lists.freedesktop.org>; Surendrakumar Upadhyay, TejaskumarX > > > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe > > protection > > > > Quoting Rodrigo Vivi (2020-10-19 19:29:36) > > > > > > I just checked the CI picture and it looks much better indeed. > > > > > > Only bad case being the gt_pm, which is also failing on other platforms. > > > > Not nearly in the same manner. CI is indicating that there is no RC6 entry > > and > > no power saving at all; neither in the selftests nor visible from userspace. > > That is a critical battery eating bug. > > > > If there's a patch to fix it for ehl and jsl, send it to CI for proving. > > -Chris > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Warn on pinning without holding a reference
On Wed, Oct 28, 2020 at 07:31:20PM +0800, Daniel Vetter wrote:
> Not technically a problem for ttm, but very likely a driver bug and
> pretty big time confusing for reviewing code.
>
> So warn about it, both at cleanup time (so we catch these for sure)
> and at pin/unpin time (so we know who's the culprit).
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Huang Rui
> Cc: Christian Koenig
> Cc: Huang Rui
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
> include/drm/ttm/ttm_bo_api.h | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index f51b5e20fa17..a011072ab61d 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -509,7 +509,7 @@ static void ttm_bo_release(struct kref *kref)
>* shrinkers, now that they are queued for
>* destruction.
>*/
> - if (bo->pin_count) {
> + if (WARN_ON(bo->pin_count)) {
> bo->pin_count = 0;
> ttm_bo_del_from_lru(bo);
> ttm_bo_add_mem_to_lru(bo, &bo->mem);
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 37102e45e496..b45aee23d7d0 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -571,6 +571,7 @@ static inline bool ttm_bo_uses_embedded_gem_object(struct
> ttm_buffer_object *bo)
> static inline void ttm_bo_pin(struct ttm_buffer_object *bo)
> {
> dma_resv_assert_held(bo->base.resv);
> + WARN_ON_ONCE(!kref_read(&bo->kref));
> ++bo->pin_count;
> }
>
> @@ -584,6 +585,7 @@ static inline void ttm_bo_unpin(struct ttm_buffer_object
> *bo)
> {
> dma_resv_assert_held(bo->base.resv);
> WARN_ON_ONCE(!bo->pin_count);
> + WARN_ON_ONCE(!kref_read(&bo->kref));
> --bo->pin_count;
> }
>
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 01/13] drm/ttm: nuke ttm_tt_set_(un)populated again
[AMD Public Use]
-Original Message-
From: Chauhan, Madhav
Sent: Tuesday, October 27, 2020 12:57 AM
To: Koenig, Christian ;
dri-devel@lists.freedesktop.org
Cc: Huang, Ray
Subject: RE: [PATCH 01/13] drm/ttm: nuke ttm_tt_set_(un)populated again
[AMD Public Use]
-Original Message-
From: Christian König
Sent: Monday, October 26, 2020 7:14 PM
To: Chauhan, Madhav ; dri-devel@lists.freedesktop.org
Cc: Huang, Ray
Subject: Re: [PATCH 01/13] drm/ttm: nuke ttm_tt_set_(un)populated again
Am 26.10.20 um 14:36 schrieb Chauhan, Madhav:
> [AMD Public Use]
>
> -Original Message-
> From: Christian König
> Sent: Sunday, October 25, 2020 9:11 PM
> To: Chauhan, Madhav ;
> dri-devel@lists.freedesktop.org
> Cc: Huang, Ray
> Subject: [PATCH 01/13] drm/ttm: nuke ttm_tt_set_(un)populated again
>
> Neither page allocation backend nor the driver should mess with that.
>
> Looks fine to me: Reviewed-by: Madhav Chauhan
Just for this patch or the series?
Complete series looks good to me now. Series, Reviewed-by: Madhav Chauhan
Will be doing MHT 3.0/3.1 offscreen/regression analysis to find the impact of
this optimized allocator and update If found any issues.
Tested this new allocator thoroughly with Raven Ridge APU, Navi 14 dGPU.
Results:
1. No regression/BO allocation error observed while running LIBDRM testapps
2. MHT 3.0/3.1 1080P offscreen results are at par/similar with old allocator.
Regards,
Madhav
Regards,
Madhav
Christian.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 --
> drivers/gpu/drm/nouveau/nouveau_bo.c | 1 -
> drivers/gpu/drm/radeon/radeon_ttm.c | 2 --
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 --
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 2 --
> drivers/gpu/drm/ttm/ttm_tt.c | 11 +++
> include/drm/ttm/ttm_tt.h | 10 --
> 7 files changed, 7 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 62f9194b1dd1..169468572930 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1363,7 +1363,6 @@ static int amdgpu_ttm_tt_populate(struct ttm_bo_device
> *bdev,
> return -ENOMEM;
>
> ttm->page_flags |= TTM_PAGE_FLAG_SG;
> - ttm_tt_set_populated(ttm);
> return 0;
> }
>
> @@ -1383,7 +1382,6 @@ static int amdgpu_ttm_tt_populate(struct ttm_bo_device
> *bdev,
> drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
>gtt->ttm.dma_address,
>ttm->num_pages);
> - ttm_tt_set_populated(ttm);
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index acff82afe260..06a1f4c4e96e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1321,7 +1321,6 @@ nouveau_ttm_tt_populate(struct ttm_bo_device *bdev,
> /* make userspace faulting work */
> drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
>ttm_dma->dma_address,
> ttm->num_pages);
> - ttm_tt_set_populated(ttm);
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 321c09d20c6c..75fa2f55186b 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -670,14 +670,12 @@ static int radeon_ttm_tt_populate(struct ttm_bo_device
> *bdev,
> return -ENOMEM;
>
> ttm->page_flags |= TTM_PAGE_FLAG_SG;
> - ttm_tt_set_populated(ttm);
> return 0;
> }
>
> if (slave && ttm->sg) {
> drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
>gtt->ttm.dma_address,
> ttm->num_pages);
> - ttm_tt_set_populated(ttm);
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index c8f6790962b9..04099dddce16 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -1041,7 +1041,6 @@ ttm_pool_unpopulate_helper(struct ttm_tt *ttm, unsigned
> mem_count_update)
> put_pages:
> ttm_put_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
> ttm->caching);
> - ttm_tt_set_unpopulated(ttm);
> }
>
> int ttm_pool_populate(struct ttm_tt *ttm, struct ttm_operation_ctx *ctx) @@
> -1080,7 +1079,6 @@ int ttm_pool_populate(struct ttm_tt *ttm, struct
> ttm_operation_ctx *ctx)
> }
> }
>
> - ttm_tt_set_populated(ttm);
> return 0;
> }
> EXPORT_SYMBOL(
[PATCH] drm/ttm: Warn on pinning without holding a reference
Not technically a problem for ttm, but very likely a driver bug and
pretty big time confusing for reviewing code.
So warn about it, both at cleanup time (so we catch these for sure)
and at pin/unpin time (so we know who's the culprit).
Signed-off-by: Daniel Vetter
Cc: Christian Koenig
Cc: Huang Rui
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
include/drm/ttm/ttm_bo_api.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index f51b5e20fa17..a011072ab61d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -509,7 +509,7 @@ static void ttm_bo_release(struct kref *kref)
* shrinkers, now that they are queued for
* destruction.
*/
- if (bo->pin_count) {
+ if (WARN_ON(bo->pin_count)) {
bo->pin_count = 0;
ttm_bo_del_from_lru(bo);
ttm_bo_add_mem_to_lru(bo, &bo->mem);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 37102e45e496..b45aee23d7d0 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -571,6 +571,7 @@ static inline bool ttm_bo_uses_embedded_gem_object(struct
ttm_buffer_object *bo)
static inline void ttm_bo_pin(struct ttm_buffer_object *bo)
{
dma_resv_assert_held(bo->base.resv);
+ WARN_ON_ONCE(!kref_read(&bo->kref));
++bo->pin_count;
}
@@ -584,6 +585,7 @@ static inline void ttm_bo_unpin(struct ttm_buffer_object
*bo)
{
dma_resv_assert_held(bo->base.resv);
WARN_ON_ONCE(!bo->pin_count);
+ WARN_ON_ONCE(!kref_read(&bo->kref));
--bo->pin_count;
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/vc4: drv: Add error handding for bind
On Tue, Oct 27, 2020 at 03:54:31PM +0100, Maxime Ripard wrote: > Hi, > > On Tue, Oct 27, 2020 at 01:14:42PM +0900, Hoegeun Kwon wrote: > > There is a problem that if vc4_drm bind fails, a memory leak occurs on > > the drm_property_create side. Add error handding for drm_mode_config. > > > > Signed-off-by: Hoegeun Kwon > > Applied, thanks! Switching over to drmm_ version of this would also be good I think. Together with the devm_ version for allocating the drm_device you could delete a pile of that fragile cleanup code. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] Fonts: Make font size unsigned in font_desc
`width` and `height` are defined as unsigned in our UAPI font descriptor
`struct console_font`. Make them unsigned in our kernel font descriptor
`struct font_desc`, too.
Also, change the corresponding printk() format identifiers from `%d` to
`%u`, in sti_select_fbfont().
Signed-off-by: Peilin Ye
---
Change in v2:
- Mention `struct console_font` in the commit message. (Suggested by
Daniel Vetter )
drivers/video/console/sticore.c | 2 +-
include/linux/font.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/console/sticore.c b/drivers/video/console/sticore.c
index 6a26a364f9bd..d1bb5915082b 100644
--- a/drivers/video/console/sticore.c
+++ b/drivers/video/console/sticore.c
@@ -502,7 +502,7 @@ sti_select_fbfont(struct sti_cooked_rom *cooked_rom, const
char *fbfont_name)
if (!fbfont)
return NULL;
- pr_info("STI selected %dx%d framebuffer font %s for sticon\n",
+ pr_info("STI selected %ux%u framebuffer font %s for sticon\n",
fbfont->width, fbfont->height, fbfont->name);
bpc = ((fbfont->width+7)/8) * fbfont->height;
diff --git a/include/linux/font.h b/include/linux/font.h
index b5b312c19e46..4f50d736ea72 100644
--- a/include/linux/font.h
+++ b/include/linux/font.h
@@ -16,7 +16,7 @@
struct font_desc {
int idx;
const char *name;
-int width, height;
+unsigned int width, height;
const void *data;
int pref;
};
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] xf86drm.c: Use integer logarithm.
On 10/28/20 13:30, Michel Dänzer wrote:
> On 2020-10-28 11:09 a.m., Paul Gofman wrote:
>> On 10/28/20 11:18, Pekka Paalanen wrote:
>>>
+static unsigned log2_int(unsigned x)
+{
+ unsigned l;
+
+ if (x < 2) {
+ return 0;
+ }
+ for (l = 2; ; l++) {
+ if ((unsigned)(1 << l) > x) {
>>> Hi,
>>>
>>> wouldn't this loop fail to end when x >= 0x8000?
>>>
>>> Sure, such value probably cannot occur where this is currently used,
>>> but it seems like a landmine for the next developer to step on.
>>>
>> Indeed, thanks. I've sent the patches for consideration which avoid
>> function duplication and potentially infinite loop.
>
> libdrm uses GitLab merge requests now:
> https://gitlab.freedesktop.org/mesa/drm/-/merge_requests
>
>
I see, thanks. I was following the instructions in CONTRIBUTING.rst.
Do you think I should proceed with merge request for these patches or
those already sent could be considered this way?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] Fonts: Make font size unsigned in font_desc
On Wed, Oct 28, 2020 at 09:18:44AM +0100, Daniel Vetter wrote: > On Wed, Oct 28, 2020 at 01:43:07AM -0400, Peilin Ye wrote: > > On Tue, Oct 27, 2020 at 07:50:58PM +0100, Daniel Vetter wrote: > > > On Tue, Oct 27, 2020 at 12:33:05PM -0400, Peilin Ye wrote: > > > > It is improper to define `width` and `height` as signed in `struct > > > > font_desc`. Make them unsigned. Also, change the corresponding printk() > > > > format identifiers from `%d` to `%u`, in sti_select_fbfont(). > > > > > > > > Signed-off-by: Peilin Ye > > > > > > I'm not entirely sure of the motivation here ... height/width should never > > > ever be even close to the limit here. Or have you seen integer math that > > > could potentially go wrong if we go with unsigned instead of int? > > > > Oh... No, I have not. I just thought we shouldn't represent a length > > using a signed value. Also, width and height in console_font are > > unsigned int - that shouldn't matter that much though. > > Oh this is actually a good reason, since that's the uapi structure. And so > using the exact same signedness should help a bit with accidental casting > bugs. > > If you mention this in the commit message I think this is good to go. Ah, I see, v2 on the way. Please ignore [v2 3/5], that doesn't hunk with this patch in effect... One newbie question, should I mention in the commit message, if a patch depends on another patch in the series in order to hunk properly? Peilin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] xf86drm.c: Use integer logarithm.
On 2020-10-28 11:09 a.m., Paul Gofman wrote:
On 10/28/20 11:18, Pekka Paalanen wrote:
+static unsigned log2_int(unsigned x)
+{
+unsigned l;
+
+if (x < 2) {
+return 0;
+}
+for (l = 2; ; l++) {
+if ((unsigned)(1 << l) > x) {
Hi,
wouldn't this loop fail to end when x >= 0x8000?
Sure, such value probably cannot occur where this is currently used,
but it seems like a landmine for the next developer to step on.
Indeed, thanks. I've sent the patches for consideration which avoid
function duplication and potentially infinite loop.
libdrm uses GitLab merge requests now:
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/ttm: replace last move_notify with delete_mem_notify
On Wed, Oct 28, 2020 at 10:53 AM Christian König
wrote:
>
> Am 28.10.20 um 10:16 schrieb Daniel Vetter:
> > On Wed, Oct 21, 2020 at 11:58:45AM +0200, Christian König wrote:
> >> Am 21.10.20 um 06:40 schrieb Dave Airlie:
> >>> From: Dave Airlie
> >>>
> >>> The move notify callback is only used in one place, this should
> >>> be removed in the future, but for now just rename it to the use
> >>> case which is to notify the driver that the GPU memory is to be
> >>> deleted.
> >> Probably the right thing to do is to call the move callback with move(from,
> >> NULL) in this case as well.
> >>
> >> And then driver can call the necessary function to throw away the backing
> >> store pipelined.
> >>
> >>> Drivers can be cleaned up after this separately.
> >>>
> >>> Signed-off-by: Dave Airlie
> >> Reviewed-by: Christian König
> > Not sure where to best ask this question, but while reading code I
> > stumbled over the bo->pin_count check in ttm_bo_release(). And I'm
> > confused.
> >
> > Allowing a bo to be pinned without holding a full reference to it feels
> > like a pretty serious bug. Where&why is that needed? I'm kinda tempted to
> > wrap this in a WARN_ON, just to make sure there's no surprises in usage
> > (and maybe warn in unpin if we drop the pin count with the refcount at 0
> > already).
>
> Yeah, I was wondering about that as well.
>
> In general I don't see harm from the TTM perspective to drop the last
> reference while a BO is still pinned.
>
> Only from the driver side it sounds like a bug to me, so I decided to
> not going to enforce this in TTM.
Yeah implementing it doesn't sound tricky, but it also doesn't sound
like something anyone would ever want to do intentionally. I think
I'll stitch some WARN_ONs together.
-Daniel
>
> Christian.
>
> > -Daniel
> >
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 8 +++-
> >>>drivers/gpu/drm/drm_gem_vram_helper.c | 8 +++-
> >>>drivers/gpu/drm/nouveau/nouveau_bo.c | 8 +++-
> >>>drivers/gpu/drm/qxl/qxl_ttm.c | 7 ++-
> >>>drivers/gpu/drm/radeon/radeon_ttm.c| 8 +++-
> >>>drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
> >>>drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 8 +++-
> >>>include/drm/ttm/ttm_bo_driver.h| 10 ++
> >>>8 files changed, 41 insertions(+), 20 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> index 87e10a212b8a..62f9194b1dd1 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> @@ -1730,6 +1730,12 @@ static int amdgpu_ttm_access_memory(struct
> >>> ttm_buffer_object *bo,
> >>> return ret;
> >>>}
> >>> +static void
> >>> +amdgpu_bo_delete_mem_notify(struct ttm_buffer_object *bo)
> >>> +{
> >>> + amdgpu_bo_move_notify(bo, false, NULL);
> >>> +}
> >>> +
> >>>static struct ttm_bo_driver amdgpu_bo_driver = {
> >>> .ttm_tt_create = &amdgpu_ttm_tt_create,
> >>> .ttm_tt_populate = &amdgpu_ttm_tt_populate,
> >>> @@ -1739,7 +1745,7 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
> >>> .evict_flags = &amdgpu_evict_flags,
> >>> .move = &amdgpu_bo_move,
> >>> .verify_access = &amdgpu_verify_access,
> >>> - .move_notify = &amdgpu_bo_move_notify,
> >>> + .delete_mem_notify = &amdgpu_bo_delete_mem_notify,
> >>> .release_notify = &amdgpu_bo_release_notify,
> >>> .io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
> >>> .io_mem_pfn = amdgpu_ttm_io_mem_pfn,
> >>> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> >>> b/drivers/gpu/drm/drm_gem_vram_helper.c
> >>> index 19087b22bdbb..9da823eb0edd 100644
> >>> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> >>> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> >>> @@ -949,9 +949,7 @@ static void bo_driver_evict_flags(struct
> >>> ttm_buffer_object *bo,
> >>> drm_gem_vram_bo_driver_evict_flags(gbo, placement);
> >>>}
> >>> -static void bo_driver_move_notify(struct ttm_buffer_object *bo,
> >>> - bool evict,
> >>> - struct ttm_resource *new_mem)
> >>> +static void bo_driver_delete_mem_notify(struct ttm_buffer_object *bo)
> >>>{
> >>> struct drm_gem_vram_object *gbo;
> >>> @@ -961,7 +959,7 @@ static void bo_driver_move_notify(struct
> >>> ttm_buffer_object *bo,
> >>> gbo = drm_gem_vram_of_bo(bo);
> >>> - drm_gem_vram_bo_driver_move_notify(gbo, evict, new_mem);
> >>> + drm_gem_vram_bo_driver_move_notify(gbo, false, NULL);
> >>>}
> >>>static int bo_driver_move(struct ttm_buffer_object *bo,
> >>> @@ -1002,7 +1000,7 @@ static struct ttm_bo_driver bo_driver = {
> >>> .eviction_valuable = ttm_bo_eviction_valuable,
> >>> .evict_flags = bo_driver_evict_flags,
> >>> .move = bo_driver_move,
> >>> - .move_notify = bo_driver_move_notify,
> >>> + .delete_mem_notify = bo_driver_delete_mem_notify,
> >>> .i
Re: [PATCH] drm/shme-helpers: Fix dma_buf_mmap forwarding bug
On Wed, Oct 28, 2020 at 09:44:15AM +0100, Boris Brezillon wrote:
> On Tue, 27 Oct 2020 22:49:22 +0100
> Daniel Vetter wrote:
>
> > When we forward an mmap to the dma_buf exporter, they get to own
> > everything. Unfortunately drm_gem_mmap_obj() overwrote
> > vma->vm_private_data after the driver callback, wreaking the
> > exporter complete. This was noticed because vb2_common_vm_close blew
> > up on mali gpu with panfrost after commit 26d3ac3cb04d
> > ("drm/shmem-helpers: Redirect mmap for imported dma-buf").
> >
> > Unfortunately drm_gem_mmap_obj also acquires a surplus reference that
> > we need to drop in shmem helpers, which is a bit of a mislayer
> > situation. Maybe the entire dma_buf_mmap forwarding should be pulled
> > into core gem code.
> >
> > Note that the only two other drivers which forward mmap in their own
> > code (etnaviv and exynos) get this somewhat right by overwriting the
> > gem mmap code. But they seem to still have the leak. This might be a
> > good excuse to move these drivers over to shmem helpers completely.
> >
> > Note to stable team: There's a trivial context conflict with
> > d693def4fd1c ("drm: Remove obsolete GEM and PRIME callbacks from
> > struct drm_driver"). I'm assuming it's clear where to put the first
> > hunk, otherwise I can send a 5.9 version of this.
> >
> > Cc: Christian König
> > Cc: Sumit Semwal
> > Cc: Lucas Stach
> > Cc: Russell King
> > Cc: Christian Gmeiner
> > Cc: Inki Dae
> > Cc: Joonyoung Shim
> > Cc: Seung-Woo Kim
> > Cc: Kyungmin Park
> > Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported
> > dma-buf")
> > Cc: Boris Brezillon
>
> Reviewed-by: Boris Brezillon
Patch pushed to drm-misc-fixes, thanks for taking a look.
-Daniel
>
> > Cc: Thomas Zimmermann
> > Cc: Gerd Hoffmann
> > Cc: Rob Herring
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: # v5.9+
> > Reported-and-tested-by: piotr.oniszc...@gmail.com
> > Cc: piotr.oniszc...@gmail.com
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_gem.c | 4 ++--
> > drivers/gpu/drm/drm_gem_shmem_helper.c | 7 ++-
> > 2 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index 1da67d34e55d..d586068f5509 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -1076,6 +1076,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj,
> > unsigned long obj_size,
> > */
> > drm_gem_object_get(obj);
> >
> > + vma->vm_private_data = obj;
> > +
> > if (obj->funcs->mmap) {
> > ret = obj->funcs->mmap(obj, vma);
> > if (ret) {
> > @@ -1096,8 +1098,6 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj,
> > unsigned long obj_size,
> > vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
> > }
> >
> > - vma->vm_private_data = obj;
> > -
> > return 0;
> > }
> > EXPORT_SYMBOL(drm_gem_mmap_obj);
> > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > index fb11df7aced5..8233bda4692f 100644
> > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > @@ -598,8 +598,13 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj,
> > struct vm_area_struct *vma)
> > /* Remove the fake offset */
> > vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node);
> >
> > - if (obj->import_attach)
> > + if (obj->import_attach) {
> > + /* Drop the reference drm_gem_mmap_obj() acquired.*/
> > + drm_gem_object_put(obj);
> > + vma->vm_private_data = NULL;
> > +
> > return dma_buf_mmap(obj->dma_buf, vma, 0);
> > + }
> >
> > shmem = to_drm_gem_shmem_obj(obj);
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] xf86drm.c: Use integer logarithm.
On 10/28/20 11:18, Pekka Paalanen wrote:
>
>>
>> +static unsigned log2_int(unsigned x)
>> +{
>> +unsigned l;
>> +
>> +if (x < 2) {
>> +return 0;
>> +}
>> +for (l = 2; ; l++) {
>> +if ((unsigned)(1 << l) > x) {
> Hi,
>
> wouldn't this loop fail to end when x >= 0x8000?
>
> Sure, such value probably cannot occur where this is currently used,
> but it seems like a landmine for the next developer to step on.
>
Indeed, thanks. I've sent the patches for consideration which avoid
function duplication and potentially infinite loop.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/2] include: Factor out log2_int() function.
Signed-off-by: Paul Gofman
---
radeon/radeon_surface.c | 20 +---
util_math.h | 14 ++
xf86drm.c | 16
3 files changed, 15 insertions(+), 35 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index ea0a27a9..c59dcc83 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -38,6 +38,7 @@
#include "xf86drm.h"
#include "radeon_drm.h"
#include "radeon_surface.h"
+#include "util_math.h"
#define CIK_TILE_MODE_COLOR_2D 14
#define CIK_TILE_MODE_COLOR_2D_SCANOUT 10
@@ -47,10 +48,6 @@
#define CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_512 3
#define CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_ROW_SIZE 4
-#define ALIGN(value, alignment) (((value) + alignment - 1) & ~(alignment - 1))
-#define MAX2(A, B) ((A) > (B) ? (A) : (B))
-#define MIN2(A, B) ((A) < (B) ? (A) : (B))
-
/* keep this private */
enum radeon_family {
CHIP_UNKNOWN,
@@ -887,21 +884,6 @@ static int eg_surface_init(struct radeon_surface_manager
*surf_man,
return r;
}
-static unsigned log2_int(unsigned x)
-{
-unsigned l;
-
-if (x < 2) {
-return 0;
-}
-for (l = 2; ; l++) {
-if ((unsigned)(1 << l) > x) {
-return l - 1;
-}
-}
-return 0;
-}
-
/* compute best tile_split, bankw, bankh, mtilea
* depending on surface
*/
diff --git a/util_math.h b/util_math.h
index 35bf4512..e2fa95f5 100644
--- a/util_math.h
+++ b/util_math.h
@@ -31,4 +31,18 @@
#define __align_mask(value, mask) (((value) + (mask)) & ~(mask))
#define ALIGN(value, alignment)__align_mask(value,
(__typeof__(value))((alignment) - 1))
+static inline unsigned log2_int(unsigned x)
+{
+unsigned l;
+
+if (x < 2) {
+return 0;
+}
+for (l = 2; ; l++) {
+if ((unsigned)(1 << l) > x) {
+return l - 1;
+}
+}
+return 0;
+}
#endif /*_UTIL_MATH_H_*/
diff --git a/xf86drm.c b/xf86drm.c
index dbb7c14b..ca4738e1 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -124,22 +124,6 @@ static drmServerInfoPtr drm_server_info;
static bool drmNodeIsDRM(int maj, int min);
static char *drmGetMinorNameForFD(int fd, int type);
-static unsigned log2_int(unsigned x)
-{
-unsigned l;
-
-if (x < 2) {
-return 0;
-}
-for (l = 2; ; l++) {
-if ((unsigned)(1 << l) > x) {
-return l - 1;
-}
-}
-return 0;
-}
-
-
drm_public void drmSetServerInfo(drmServerInfoPtr info)
{
drm_server_info = info;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/2] include: Avoid potentially infinite loop in log2_int().
Signed-off-by: Paul Gofman
---
util_math.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/util_math.h b/util_math.h
index e2fa95f5..f6bbe192 100644
--- a/util_math.h
+++ b/util_math.h
@@ -38,6 +38,9 @@ static inline unsigned log2_int(unsigned x)
if (x < 2) {
return 0;
}
+if (x & 0x8000) {
+return 31;
+}
for (l = 2; ; l++) {
if ((unsigned)(1 << l) > x) {
return l - 1;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] fbdev/atafb: Remove unused extern variables
On Tue, Oct 27, 2020 at 6:12 PM Peilin Ye wrote:
> Remove 6 unused extern variables to reduce confusion. It is worth
> mentioning that lib/fonts/font_8x8.c and lib/fonts/font_8x16.c also
> declare `fontdata_8x8` and `fontdata_8x16` respectively, and this file
> has nothing to do with them.
>
> Signed-off-by: Peilin Ye
Reviewed-by: Geert Uytterhoeven
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: [Linaro-mm-sig] [PATCH] drm/shme-helpers: Fix dma_buf_mmap forwarding bug
Am 27.10.20 um 22:49 schrieb Daniel Vetter:
When we forward an mmap to the dma_buf exporter, they get to own
everything. Unfortunately drm_gem_mmap_obj() overwrote
vma->vm_private_data after the driver callback, wreaking the
exporter complete. This was noticed because vb2_common_vm_close blew
up on mali gpu with panfrost after commit 26d3ac3cb04d
("drm/shmem-helpers: Redirect mmap for imported dma-buf").
Unfortunately drm_gem_mmap_obj also acquires a surplus reference that
we need to drop in shmem helpers, which is a bit of a mislayer
situation. Maybe the entire dma_buf_mmap forwarding should be pulled
into core gem code.
Note that the only two other drivers which forward mmap in their own
code (etnaviv and exynos) get this somewhat right by overwriting the
gem mmap code. But they seem to still have the leak. This might be a
good excuse to move these drivers over to shmem helpers completely.
Note to stable team: There's a trivial context conflict with
d693def4fd1c ("drm: Remove obsolete GEM and PRIME callbacks from
struct drm_driver"). I'm assuming it's clear where to put the first
hunk, otherwise I can send a 5.9 version of this.
Cc: Christian König
Cc: Sumit Semwal
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf")
Cc: Boris Brezillon
Cc: Thomas Zimmermann
Cc: Gerd Hoffmann
Cc: Rob Herring
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: # v5.9+
Reported-and-tested-by: piotr.oniszc...@gmail.com
Cc: piotr.oniszc...@gmail.com
Signed-off-by: Daniel Vetter
Acked-by: Christian König
---
drivers/gpu/drm/drm_gem.c | 4 ++--
drivers/gpu/drm/drm_gem_shmem_helper.c | 7 ++-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1da67d34e55d..d586068f5509 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1076,6 +1076,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned
long obj_size,
*/
drm_gem_object_get(obj);
+ vma->vm_private_data = obj;
+
if (obj->funcs->mmap) {
ret = obj->funcs->mmap(obj, vma);
if (ret) {
@@ -1096,8 +1098,6 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned
long obj_size,
vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
}
- vma->vm_private_data = obj;
-
return 0;
}
EXPORT_SYMBOL(drm_gem_mmap_obj);
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index fb11df7aced5..8233bda4692f 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -598,8 +598,13 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
/* Remove the fake offset */
vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node);
- if (obj->import_attach)
+ if (obj->import_attach) {
+ /* Drop the reference drm_gem_mmap_obj() acquired.*/
+ drm_gem_object_put(obj);
+ vma->vm_private_data = NULL;
+
return dma_buf_mmap(obj->dma_buf, vma, 0);
+ }
shmem = to_drm_gem_shmem_obj(obj);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 19/20] drm/tegra: Implement new UAPI
On 10/27/20 9:06 PM, Dmitry Osipenko wrote: 26.10.2020 12:11, Mikko Perttunen пишет: The first patches should be the ones that are relevant to the existing userspace code, like support for the waits. Can you elaborate what you mean by this? All features that don't have an immediate real use-case should be placed later in the series because we may defer merging of those patches until we will see userspace that uses those features since we can't really decide whether these are decisions that we won't regret later on, only practical application can confirm the correctness. I was more referring to the "support for waits" part, should have clarified that. Partial mappings should be a separate feature because it's a questionable feature that needs to be proved by a real userspace first. Maybe it would be even better to drop it for the starter, to ease reviewing. Considering that the "no-op" support for it (map the whole buffer but just keep track of the starting offset) is only a couple of lines, I'd like to keep it in. There is no tracking in the current code which prevents the duplicated mappings, will we need to care about it? This a bit too questionable feature for now, IMO. I'd like to see it as a separate patch. I don't think there is any need to special case duplicated mappings. I think this is a pretty obvious feature to have, but I can rename them to reserved0 and reserved1 and require that reserved0 is zero and reserved1 is the size of the passed GEM object. ... I'd like to see the DRM_SCHED and syncobj support. I can help you with it if it's out of yours scope for now. I already wrote some code for syncobj I can probably pull in. Regarding DRM_SCHED, help is accepted. However, we should keep using the hardware scheduler, and considering it's a bigger piece of work, let's not block this series on it. I'd like to see all the custom IOCTLs to be deprecated and replaced with the generic DRM API wherever possible. Hence, I think it should be a mandatory features that we need to focus on. The current WIP userspace already uses and relies on DRM_SCHED. From my point of view, the ABI needs to be designed such that it can replace what we have downstream, i.e. it needs to support the usecases the downstream nvhost ABI supports currently. Otherwise there is no migration path to upstream and it's not worth it for me to work on this. Although, I don't see what this ABI is missing that your userspace would rely on. Does it submit jobs in reverse order that would deadlock if drm_sched didn't reorder them based on prefences, or something? Software-based scheduling might make sense in situations where the channel is shared by all processes, but at least for modern chips that are designed to use hardware scheduling, I want to use that capability. Mikko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/ttm: replace last move_notify with delete_mem_notify
Am 28.10.20 um 10:16 schrieb Daniel Vetter:
On Wed, Oct 21, 2020 at 11:58:45AM +0200, Christian König wrote:
Am 21.10.20 um 06:40 schrieb Dave Airlie:
From: Dave Airlie
The move notify callback is only used in one place, this should
be removed in the future, but for now just rename it to the use
case which is to notify the driver that the GPU memory is to be
deleted.
Probably the right thing to do is to call the move callback with move(from,
NULL) in this case as well.
And then driver can call the necessary function to throw away the backing
store pipelined.
Drivers can be cleaned up after this separately.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
Not sure where to best ask this question, but while reading code I
stumbled over the bo->pin_count check in ttm_bo_release(). And I'm
confused.
Allowing a bo to be pinned without holding a full reference to it feels
like a pretty serious bug. Where&why is that needed? I'm kinda tempted to
wrap this in a WARN_ON, just to make sure there's no surprises in usage
(and maybe warn in unpin if we drop the pin count with the refcount at 0
already).
Yeah, I was wondering about that as well.
In general I don't see harm from the TTM perspective to drop the last
reference while a BO is still pinned.
Only from the driver side it sounds like a bug to me, so I decided to
not going to enforce this in TTM.
Christian.
-Daniel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 8 +++-
drivers/gpu/drm/drm_gem_vram_helper.c | 8 +++-
drivers/gpu/drm/nouveau/nouveau_bo.c | 8 +++-
drivers/gpu/drm/qxl/qxl_ttm.c | 7 ++-
drivers/gpu/drm/radeon/radeon_ttm.c| 8 +++-
drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 8 +++-
include/drm/ttm/ttm_bo_driver.h| 10 ++
8 files changed, 41 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 87e10a212b8a..62f9194b1dd1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1730,6 +1730,12 @@ static int amdgpu_ttm_access_memory(struct
ttm_buffer_object *bo,
return ret;
}
+static void
+amdgpu_bo_delete_mem_notify(struct ttm_buffer_object *bo)
+{
+ amdgpu_bo_move_notify(bo, false, NULL);
+}
+
static struct ttm_bo_driver amdgpu_bo_driver = {
.ttm_tt_create = &amdgpu_ttm_tt_create,
.ttm_tt_populate = &amdgpu_ttm_tt_populate,
@@ -1739,7 +1745,7 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.evict_flags = &amdgpu_evict_flags,
.move = &amdgpu_bo_move,
.verify_access = &amdgpu_verify_access,
- .move_notify = &amdgpu_bo_move_notify,
+ .delete_mem_notify = &amdgpu_bo_delete_mem_notify,
.release_notify = &amdgpu_bo_release_notify,
.io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
.io_mem_pfn = amdgpu_ttm_io_mem_pfn,
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 19087b22bdbb..9da823eb0edd 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -949,9 +949,7 @@ static void bo_driver_evict_flags(struct ttm_buffer_object
*bo,
drm_gem_vram_bo_driver_evict_flags(gbo, placement);
}
-static void bo_driver_move_notify(struct ttm_buffer_object *bo,
- bool evict,
- struct ttm_resource *new_mem)
+static void bo_driver_delete_mem_notify(struct ttm_buffer_object *bo)
{
struct drm_gem_vram_object *gbo;
@@ -961,7 +959,7 @@ static void bo_driver_move_notify(struct ttm_buffer_object
*bo,
gbo = drm_gem_vram_of_bo(bo);
- drm_gem_vram_bo_driver_move_notify(gbo, evict, new_mem);
+ drm_gem_vram_bo_driver_move_notify(gbo, false, NULL);
}
static int bo_driver_move(struct ttm_buffer_object *bo,
@@ -1002,7 +1000,7 @@ static struct ttm_bo_driver bo_driver = {
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = bo_driver_evict_flags,
.move = bo_driver_move,
- .move_notify = bo_driver_move_notify,
+ .delete_mem_notify = bo_driver_delete_mem_notify,
.io_mem_reserve = bo_driver_io_mem_reserve,
};
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 70b6f3b1ae85..acff82afe260 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1401,6 +1401,12 @@ nouveau_bo_fence(struct nouveau_bo *nvbo, struct
nouveau_fence *fence, bool excl
dma_resv_add_shared_fence(resv, &fence->base);
}
+static void
+nouveau_bo_delete_mem_notify(struct ttm_buffer_object *bo)
+{
+ nouveau_bo_move_ntfy(bo, false, NULL);
+}
+
struct ttm_bo_driver nouveau_bo_driver = {
.ttm_tt_create = &nouveau_ttm_tt_create,
.ttm_tt_popula
Re: [PATCH 3/3] drm/ttm: avoid multihop moves in drivers.
On Wed, Oct 21, 2020 at 02:40:31PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Currently drivers get called to move a buffer, but if they have to
> move it temporarily through another space (SYSTEM->VRAM via TT)
> then they can end up with a lot of ttm->driver->ttm call stacks,
> if the temprorary space moves requires eviction.
>
> Instead of letting the driver do all the placement/space for the
> temporary, allow it to report back (-EMULTIHOP) a placement (hop)
> to the move code, which will then do the temporary move, and the
> correct placement move afterwards.
>
> This removes a lot of code from drivers, at the expense of
> adding some midlayering. I've some further ideas on how to turn
> it inside out, but I think this is a good solution to the call
> stack problems.
>
> Signed-off-by: Dave Airlie
I think it'd be good to split out the ttm infrastructure work from the
driver conversions. I'm not seeing any dependencies that require the flag
day approach here, and might help if this blows up somehow.
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 139 +++--
> drivers/gpu/drm/drm_gem_vram_helper.c | 3 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 115 +++--
> drivers/gpu/drm/qxl/qxl_ttm.c | 3 +-
> drivers/gpu/drm/radeon/radeon_ttm.c| 122 +++---
> drivers/gpu/drm/ttm/ttm_bo.c | 62 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 3 +-
> include/drm/ttm/ttm_bo_driver.h| 5 +-
> 8 files changed, 108 insertions(+), 344 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 62f9194b1dd1..0fd4f270d794 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -515,119 +515,6 @@ static int amdgpu_move_blit(struct ttm_buffer_object
> *bo,
> return r;
> }
>
> -/**
> - * amdgpu_move_vram_ram - Copy VRAM buffer to RAM buffer
> - *
> - * Called by amdgpu_bo_move().
> - */
> -static int amdgpu_move_vram_ram(struct ttm_buffer_object *bo, bool evict,
> - struct ttm_operation_ctx *ctx,
> - struct ttm_resource *new_mem)
> -{
> - struct ttm_resource *old_mem = &bo->mem;
> - struct ttm_resource tmp_mem;
> - struct ttm_place placements;
> - struct ttm_placement placement;
> - int r;
> -
> - /* create space/pages for new_mem in GTT space */
> - tmp_mem = *new_mem;
> - tmp_mem.mm_node = NULL;
> - placement.num_placement = 1;
> - placement.placement = &placements;
> - placement.num_busy_placement = 1;
> - placement.busy_placement = &placements;
> - placements.fpfn = 0;
> - placements.lpfn = 0;
> - placements.mem_type = TTM_PL_TT;
> - placements.flags = 0;
> - r = ttm_bo_mem_space(bo, &placement, &tmp_mem, ctx);
> - if (unlikely(r)) {
> - pr_err("Failed to find GTT space for blit from VRAM\n");
> - return r;
> - }
> -
> - r = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
> - if (unlikely(r))
> - goto out_cleanup;
> -
> - /* Bind the memory to the GTT space */
> - r = amdgpu_ttm_backend_bind(bo->bdev, bo->ttm, &tmp_mem);
> - if (unlikely(r)) {
> - goto out_cleanup;
> - }
> -
> - /* blit VRAM to GTT */
> - r = amdgpu_move_blit(bo, evict, &tmp_mem, old_mem);
> - if (unlikely(r)) {
> - goto out_cleanup;
> - }
> -
> - r = ttm_bo_wait_ctx(bo, ctx);
> - if (unlikely(r))
> - goto out_cleanup;
> -
> - amdgpu_ttm_backend_unbind(bo->bdev, bo->ttm);
> - ttm_resource_free(bo, &bo->mem);
> - ttm_bo_assign_mem(bo, new_mem);
> -out_cleanup:
> - ttm_resource_free(bo, &tmp_mem);
> - return r;
> -}
> -
> -/**
> - * amdgpu_move_ram_vram - Copy buffer from RAM to VRAM
> - *
> - * Called by amdgpu_bo_move().
> - */
> -static int amdgpu_move_ram_vram(struct ttm_buffer_object *bo, bool evict,
> - struct ttm_operation_ctx *ctx,
> - struct ttm_resource *new_mem)
> -{
> - struct ttm_resource *old_mem = &bo->mem;
> - struct ttm_resource tmp_mem;
> - struct ttm_placement placement;
> - struct ttm_place placements;
> - int r;
> -
> - /* make space in GTT for old_mem buffer */
> - tmp_mem = *new_mem;
> - tmp_mem.mm_node = NULL;
> - placement.num_placement = 1;
> - placement.placement = &placements;
> - placement.num_busy_placement = 1;
> - placement.busy_placement = &placements;
> - placements.fpfn = 0;
> - placements.lpfn = 0;
> - placements.mem_type = TTM_PL_TT;
> - placements.flags = 0;
> - r = ttm_bo_mem_space(bo, &placement, &tmp_mem, ctx);
> - if (unlikely(r)) {
> - pr_err("Failed to find GTT space for blit to VRAM\n");
> - return r;
> - }
> -
> - /* move/bind old memory t
Re: [PATCH 1/3] drm/ttm: replace last move_notify with delete_mem_notify
On Wed, Oct 21, 2020 at 11:58:45AM +0200, Christian König wrote:
> Am 21.10.20 um 06:40 schrieb Dave Airlie:
> > From: Dave Airlie
> >
> > The move notify callback is only used in one place, this should
> > be removed in the future, but for now just rename it to the use
> > case which is to notify the driver that the GPU memory is to be
> > deleted.
>
> Probably the right thing to do is to call the move callback with move(from,
> NULL) in this case as well.
>
> And then driver can call the necessary function to throw away the backing
> store pipelined.
>
> >
> > Drivers can be cleaned up after this separately.
> >
> > Signed-off-by: Dave Airlie
>
> Reviewed-by: Christian König
Not sure where to best ask this question, but while reading code I
stumbled over the bo->pin_count check in ttm_bo_release(). And I'm
confused.
Allowing a bo to be pinned without holding a full reference to it feels
like a pretty serious bug. Where&why is that needed? I'm kinda tempted to
wrap this in a WARN_ON, just to make sure there's no surprises in usage
(and maybe warn in unpin if we drop the pin count with the refcount at 0
already).
-Daniel
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 8 +++-
> > drivers/gpu/drm/drm_gem_vram_helper.c | 8 +++-
> > drivers/gpu/drm/nouveau/nouveau_bo.c | 8 +++-
> > drivers/gpu/drm/qxl/qxl_ttm.c | 7 ++-
> > drivers/gpu/drm/radeon/radeon_ttm.c| 8 +++-
> > drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
> > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 8 +++-
> > include/drm/ttm/ttm_bo_driver.h| 10 ++
> > 8 files changed, 41 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > index 87e10a212b8a..62f9194b1dd1 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > @@ -1730,6 +1730,12 @@ static int amdgpu_ttm_access_memory(struct
> > ttm_buffer_object *bo,
> > return ret;
> > }
> > +static void
> > +amdgpu_bo_delete_mem_notify(struct ttm_buffer_object *bo)
> > +{
> > + amdgpu_bo_move_notify(bo, false, NULL);
> > +}
> > +
> > static struct ttm_bo_driver amdgpu_bo_driver = {
> > .ttm_tt_create = &amdgpu_ttm_tt_create,
> > .ttm_tt_populate = &amdgpu_ttm_tt_populate,
> > @@ -1739,7 +1745,7 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
> > .evict_flags = &amdgpu_evict_flags,
> > .move = &amdgpu_bo_move,
> > .verify_access = &amdgpu_verify_access,
> > - .move_notify = &amdgpu_bo_move_notify,
> > + .delete_mem_notify = &amdgpu_bo_delete_mem_notify,
> > .release_notify = &amdgpu_bo_release_notify,
> > .io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
> > .io_mem_pfn = amdgpu_ttm_io_mem_pfn,
> > diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> > b/drivers/gpu/drm/drm_gem_vram_helper.c
> > index 19087b22bdbb..9da823eb0edd 100644
> > --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> > @@ -949,9 +949,7 @@ static void bo_driver_evict_flags(struct
> > ttm_buffer_object *bo,
> > drm_gem_vram_bo_driver_evict_flags(gbo, placement);
> > }
> > -static void bo_driver_move_notify(struct ttm_buffer_object *bo,
> > - bool evict,
> > - struct ttm_resource *new_mem)
> > +static void bo_driver_delete_mem_notify(struct ttm_buffer_object *bo)
> > {
> > struct drm_gem_vram_object *gbo;
> > @@ -961,7 +959,7 @@ static void bo_driver_move_notify(struct
> > ttm_buffer_object *bo,
> > gbo = drm_gem_vram_of_bo(bo);
> > - drm_gem_vram_bo_driver_move_notify(gbo, evict, new_mem);
> > + drm_gem_vram_bo_driver_move_notify(gbo, false, NULL);
> > }
> > static int bo_driver_move(struct ttm_buffer_object *bo,
> > @@ -1002,7 +1000,7 @@ static struct ttm_bo_driver bo_driver = {
> > .eviction_valuable = ttm_bo_eviction_valuable,
> > .evict_flags = bo_driver_evict_flags,
> > .move = bo_driver_move,
> > - .move_notify = bo_driver_move_notify,
> > + .delete_mem_notify = bo_driver_delete_mem_notify,
> > .io_mem_reserve = bo_driver_io_mem_reserve,
> > };
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index 70b6f3b1ae85..acff82afe260 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -1401,6 +1401,12 @@ nouveau_bo_fence(struct nouveau_bo *nvbo, struct
> > nouveau_fence *fence, bool excl
> > dma_resv_add_shared_fence(resv, &fence->base);
> > }
> > +static void
> > +nouveau_bo_delete_mem_notify(struct ttm_buffer_object *bo)
> > +{
> > + nouveau_bo_move_ntfy(bo, false, NULL);
> > +}
> > +
> > struct ttm_bo_driver nouveau_bo_driver = {
> > .ttm_tt_create = &nouveau_ttm_tt_create,
> > .ttm_tt_populate = &nouveau_ttm_tt_populate,
> > @@ -1408,7 +1414,7 @
Re: [PATCH 1/8] mm: slab: provide krealloc_array()
On Tue, Oct 27, 2020 at 01:17:18PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> When allocating an array of elements, users should check for
> multiplication overflow or preferably use one of the provided helpers
> like: kmalloc_array().
>
> There's no krealloc_array() counterpart but there are many users who use
> regular krealloc() to reallocate arrays. Let's provide an actual
> krealloc_array() implementation.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> include/linux/slab.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index dd6897f62010..0e6683affee7 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -592,6 +592,17 @@ static inline void *kmalloc_array(size_t n, size_t size,
> gfp_t flags)
> return __kmalloc(bytes, flags);
> }
>
Can you please add kernel-doc here and a word or two about this function
to Documentation/core-api/memory-allocation.rst?
> +static __must_check inline void *
> +krealloc_array(void *p, size_t new_n, size_t new_size, gfp_t flags)
> +{
> + size_t bytes;
> +
> + if (unlikely(check_mul_overflow(new_n, new_size, &bytes)))
> + return NULL;
> +
> + return krealloc(p, bytes, flags);
> +}
> +
> /**
> * kcalloc - allocate memory for an array. The memory is set to zero.
> * @n: number of elements.
> --
> 2.29.1
>
>
--
Sincerely yours,
Mike.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/shme-helpers: Fix dma_buf_mmap forwarding bug
On Tue, 27 Oct 2020 22:49:22 +0100
Daniel Vetter wrote:
> When we forward an mmap to the dma_buf exporter, they get to own
> everything. Unfortunately drm_gem_mmap_obj() overwrote
> vma->vm_private_data after the driver callback, wreaking the
> exporter complete. This was noticed because vb2_common_vm_close blew
> up on mali gpu with panfrost after commit 26d3ac3cb04d
> ("drm/shmem-helpers: Redirect mmap for imported dma-buf").
>
> Unfortunately drm_gem_mmap_obj also acquires a surplus reference that
> we need to drop in shmem helpers, which is a bit of a mislayer
> situation. Maybe the entire dma_buf_mmap forwarding should be pulled
> into core gem code.
>
> Note that the only two other drivers which forward mmap in their own
> code (etnaviv and exynos) get this somewhat right by overwriting the
> gem mmap code. But they seem to still have the leak. This might be a
> good excuse to move these drivers over to shmem helpers completely.
>
> Note to stable team: There's a trivial context conflict with
> d693def4fd1c ("drm: Remove obsolete GEM and PRIME callbacks from
> struct drm_driver"). I'm assuming it's clear where to put the first
> hunk, otherwise I can send a 5.9 version of this.
>
> Cc: Christian König
> Cc: Sumit Semwal
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Christian Gmeiner
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf")
> Cc: Boris Brezillon
Reviewed-by: Boris Brezillon
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Rob Herring
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: # v5.9+
> Reported-and-tested-by: piotr.oniszc...@gmail.com
> Cc: piotr.oniszc...@gmail.com
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem.c | 4 ++--
> drivers/gpu/drm/drm_gem_shmem_helper.c | 7 ++-
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 1da67d34e55d..d586068f5509 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1076,6 +1076,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj,
> unsigned long obj_size,
>*/
> drm_gem_object_get(obj);
>
> + vma->vm_private_data = obj;
> +
> if (obj->funcs->mmap) {
> ret = obj->funcs->mmap(obj, vma);
> if (ret) {
> @@ -1096,8 +1098,6 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj,
> unsigned long obj_size,
> vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
> }
>
> - vma->vm_private_data = obj;
> -
> return 0;
> }
> EXPORT_SYMBOL(drm_gem_mmap_obj);
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index fb11df7aced5..8233bda4692f 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -598,8 +598,13 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj,
> struct vm_area_struct *vma)
> /* Remove the fake offset */
> vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node);
>
> - if (obj->import_attach)
> + if (obj->import_attach) {
> + /* Drop the reference drm_gem_mmap_obj() acquired.*/
> + drm_gem_object_put(obj);
> + vma->vm_private_data = NULL;
> +
> return dma_buf_mmap(obj->dma_buf, vma, 0);
> + }
>
> shmem = to_drm_gem_shmem_obj(obj);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] Fonts: Make font size unsigned in font_desc
On Wed, Oct 28, 2020 at 01:43:07AM -0400, Peilin Ye wrote: > On Tue, Oct 27, 2020 at 07:50:58PM +0100, Daniel Vetter wrote: > > On Tue, Oct 27, 2020 at 12:33:05PM -0400, Peilin Ye wrote: > > > It is improper to define `width` and `height` as signed in `struct > > > font_desc`. Make them unsigned. Also, change the corresponding printk() > > > format identifiers from `%d` to `%u`, in sti_select_fbfont(). > > > > > > Signed-off-by: Peilin Ye > > > > I'm not entirely sure of the motivation here ... height/width should never > > ever be even close to the limit here. Or have you seen integer math that > > could potentially go wrong if we go with unsigned instead of int? > > Oh... No, I have not. I just thought we shouldn't represent a length > using a signed value. Also, width and height in console_font are > unsigned int - that shouldn't matter that much though. Oh this is actually a good reason, since that's the uapi structure. And so using the exact same signedness should help a bit with accidental casting bugs. If you mention this in the commit message I think this is good to go. -Daniel > > [3/5] doesn't hunk properly without this patch, I'll send a v2 for [3/5] > soon. > > Peilin > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
