Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support
On Sun, May 5, 2019 at 3:04 PM Brian Masney wrote: > Add the MDP5, DSI and DSI PHY blocks for the display found on the > msm8974 SoCs. This is based on work from msm8916.dtsi and Jonathan > Marek. > > Signed-off-by: Brian Masney From my limited understanding it looks good: Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 6/6] ARM: dts: qcom: msm8974-hammerhead: add support for display
On Sun, May 5, 2019 at 3:04 PM Brian Masney wrote: > Add initial support for the display found on the LG Nexus 5 (hammerhead) > phone. > > Signed-off-by: Brian Masney Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 5/6] ARM: dts: qcom: msm8974-hammerhead: add support for backlight
On Sun, May 5, 2019 at 3:04 PM Brian Masney wrote:
> Add necessary device tree nodes for the main LCD backlight.
>
> Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
> This requires this series that I submitted to the LED / backlight
> subsystem:
> https://lore.kernel.org/lkml/20190424092505.6578-1-masn...@onstation.org/
> It's received 3 {Reviewed,Acked}-Bys, and has no outstanding change
> requests, so I expect it'll be merged soon.
If the DT bindings are ACKed and reviewed we can merge DTS
files using it IMO.
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 3/6] ARM: qcom_defconfig: add display-related options
On Sun, May 5, 2019 at 3:04 PM Brian Masney wrote: > Add the CMA (Contiguous Memory Allocator) for the MSM DRM driver, the > simple panel, and the TI LM3630A driver in order to support the display > on the LG Nexus 5 (hammerhead) phone. > > Signed-off-by: Brian Masney Reviewed-by: Linus Walleij > The panel and backlight are currently compiled into the kernel, but will > be moved to be modules once the display is fully working in a later > verison of this patch series. I don't see why we would want to do that, the FB console is traditionally (x86) good to alwaýs get up, as serial console might not always be available. For example for people who can't solder special cables but still want to boot a custom ROM on their Nexus. So I'd say keep it like this. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] RFC: console: hack up console_trylock more
On Fri, May 3, 2019 at 5:14 PM Petr Mladek wrote: > On Thu 2019-05-02 16:16:43, Daniel Vetter wrote: > > console_trylock, called from within printk, can be called from pretty > > much anywhere. Including try_to_wake_up. Note that this isn't common, > > usually the box is in pretty bad shape at that point already. But it > > really doesn't help when then lockdep jumps in and spams the logs, > > potentially obscuring the real backtrace we're really interested in. > > One case I've seen (slightly simplified backtrace): > > > > Call Trace: > > > > console_trylock+0xe/0x60 > > vprintk_emit+0xf1/0x320 > > printk+0x4d/0x69 > > __warn_printk+0x46/0x90 > > native_smp_send_reschedule+0x2f/0x40 > > check_preempt_curr+0x81/0xa0 > > ttwu_do_wakeup+0x14/0x220 > > try_to_wake_up+0x218/0x5f0 > > pollwake+0x6f/0x90 > > credit_entropy_bits+0x204/0x310 > > add_interrupt_randomness+0x18f/0x210 > > handle_irq+0x67/0x160 > > do_IRQ+0x5e/0x130 > > common_interrupt+0xf/0xf > > > > > > This alone isn't a problem, but the spinlock in the semaphore is also > > still held while waking up waiters (up() -> __up() -> try_to_wake_up() > > callchain), which then closes the runqueue vs. semaphore.lock loop, > > and upsets lockdep, which issues a circular locking splat to dmesg. > > Worse it upsets developers, since we don't want to spam dmesg with > > clutter when the machine is dying already. > > > > Fix this by creating a __down_trylock which only trylocks the > > semaphore.lock. This isn't correct in full generality, but good enough > > for console_lock: > > > > - there's only ever one console_lock holder, we won't fail spuriously > > because someone is doing a down() or up() while there's still room > > (unlike other semaphores with count > 1). > > > > - console_unlock() has one massive retry loop, which will catch anyone > > who races the trylock against the up(). This makes sure that no > > printk lines will get lost. Making the trylock more racy therefore > > has no further impact. > > To be honest, I do not see how this could solve the problem. > > The circular dependency is still there. If the new __down_trylock() > succeeds then console_unlock() will get called in the same context > and it will still need to call up() -> try_to_wake_up(). > > Note that there are many other console_lock() callers that might > happen in parallel and might appear in the wait queue. Hm right. It's very rare we hit this in our CI and I don't know how to repro otherwise, so just threw this out at the wall to see if it sticks. I'll try and come up with a new trick then. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/stm: ltdc: manage the get_irq probe defer case
Le ven. 26 avr. 2019 à 14:30, Philippe CORNU a écrit :
>
> Hi Fabien,
> and thank you for your patch,
>
> Acked-by: Philippe Cornu
>
> Philippe :-)
>
> On 4/24/19 4:03 PM, Fabien Dessenne wrote:
> > Manage the -EPROBE_DEFER error case for the ltdc IRQ.
> >
> > Signed-off-by: Fabien Dessenne
Applied on drm-misc-next.
Thanks,
Benjamin
> > ---
> > drivers/gpu/drm/stm/ltdc.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> > index 566b0d8..521ba83 100644
> > --- a/drivers/gpu/drm/stm/ltdc.c
> > +++ b/drivers/gpu/drm/stm/ltdc.c
> > @@ -1174,6 +1174,9 @@ int ltdc_load(struct drm_device *ddev)
> >
> > for (i = 0; i < MAX_IRQ; i++) {
> > irq = platform_get_irq(pdev, i);
> > + if (irq == -EPROBE_DEFER)
> > + goto err;
> > +
> > if (irq < 0)
> > continue;
> >
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/stm: ltdc: return appropriate error code during probe
Le ven. 26 avr. 2019 à 14:30, Philippe CORNU a écrit :
>
> Hi Fabien,
> and thank you for your patch,
>
> Acked-by: Philippe Cornu
>
> Philippe :-)
>
> On 4/24/19 4:03 PM, Fabien Dessenne wrote:
> > During probe, return the "clk_get" error value instead of -ENODEV.
> >
> > Signed-off-by: Fabien Dessenne
Applied on drm-misc-next.
Thanks,
Benjamin
> > ---
> > drivers/gpu/drm/stm/ltdc.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> > index 521ba83..97912e2 100644
> > --- a/drivers/gpu/drm/stm/ltdc.c
> > +++ b/drivers/gpu/drm/stm/ltdc.c
> > @@ -1145,8 +1145,9 @@ int ltdc_load(struct drm_device *ddev)
> >
> > ldev->pixel_clk = devm_clk_get(dev, "lcd");
> > if (IS_ERR(ldev->pixel_clk)) {
> > - DRM_ERROR("Unable to get lcd clock\n");
> > - return -ENODEV;
> > + if (PTR_ERR(ldev->pixel_clk) != -EPROBE_DEFER)
> > + DRM_ERROR("Unable to get lcd clock\n");
> > + return PTR_ERR(ldev->pixel_clk);
> > }
> >
> > if (clk_prepare_enable(ldev->pixel_clk)) {
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v14 08/17] mm, arm64: untag user pointers in get_vaddr_frames
On Tue, Apr 30, 2019 at 03:25:04PM +0200, Andrey Konovalov wrote: > This patch is a part of a series that extends arm64 kernel ABI to allow to > pass tagged user pointers (with the top byte set to something else other > than 0x00) as syscall arguments. > > get_vaddr_frames uses provided user pointers for vma lookups, which can > only by done with untagged pointers. Instead of locating and changing > all callers of this function, perform untagging in it. > > Signed-off-by: Andrey Konovalov > --- > mm/frame_vector.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/frame_vector.c b/mm/frame_vector.c > index c64dca6e27c2..c431ca81dad5 100644 > --- a/mm/frame_vector.c > +++ b/mm/frame_vector.c > @@ -46,6 +46,8 @@ int get_vaddr_frames(unsigned long start, unsigned int > nr_frames, > if (WARN_ON_ONCE(nr_frames > vec->nr_allocated)) > nr_frames = vec->nr_allocated; > > + start = untagged_addr(start); > + > down_read(&mm->mmap_sem); > locked = 1; > vma = find_vma_intersection(mm, start, start + 1); Is this some buffer that the user may have malloc'ed? I got lost when trying to track down the provenience of this buffer. -- Catalin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/5] cgroup support for GPU devices
Leon Romanovsky writes: First group (programmers) is using special API [1] through libibverbs [2] without any notion of cgroups or any limitations. Second group (sysadmins) is less interested in application specifics and for them "device memory" means "memory" and not "rdma, nic specific, internal memory". I'd suggest otherwise, based on historic precedent -- sysadmins are typically very opinionated about operation of the memory subsystem (hence the endless discussions about swap, caching behaviour, etc). Especially in this case, these types of memory operate fundamentally differently and have significantly different performance and availability characteristics. That's not something that can be trivially abstracted over without non-trivial drawbacks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/powerplay: remove spurious semicolon
Remove unnecessary semicolons at the end of line.
Signed-off-by: Andrea Righi
---
drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 8
drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index 3f73f7cd18b9..1052f5119087 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -1304,7 +1304,7 @@ static int pp_notify_smu_enable_pwe(void *handle)
if (hwmgr->hwmgr_func->smus_notify_pwe == NULL) {
pr_info_ratelimited("%s was not implemented.\n", __func__);
- return -EINVAL;;
+ return -EINVAL;
}
mutex_lock(&hwmgr->smu_lock);
@@ -1341,7 +1341,7 @@ static int pp_set_min_deep_sleep_dcefclk(void *handle,
uint32_t clock)
if (hwmgr->hwmgr_func->set_min_deep_sleep_dcefclk == NULL) {
pr_debug("%s was not implemented.\n", __func__);
- return -EINVAL;;
+ return -EINVAL;
}
mutex_lock(&hwmgr->smu_lock);
@@ -1360,7 +1360,7 @@ static int pp_set_hard_min_dcefclk_by_freq(void *handle,
uint32_t clock)
if (hwmgr->hwmgr_func->set_hard_min_dcefclk_by_freq == NULL) {
pr_debug("%s was not implemented.\n", __func__);
- return -EINVAL;;
+ return -EINVAL;
}
mutex_lock(&hwmgr->smu_lock);
@@ -1379,7 +1379,7 @@ static int pp_set_hard_min_fclk_by_freq(void *handle,
uint32_t clock)
if (hwmgr->hwmgr_func->set_hard_min_fclk_by_freq == NULL) {
pr_debug("%s was not implemented.\n", __func__);
- return -EINVAL;;
+ return -EINVAL;
}
mutex_lock(&hwmgr->smu_lock);
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
index c1c51c115e57..70f7f47a2fcf 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
@@ -76,7 +76,7 @@ int phm_set_power_state(struct pp_hwmgr *hwmgr,
int phm_enable_dynamic_state_management(struct pp_hwmgr *hwmgr)
{
struct amdgpu_device *adev = NULL;
- int ret = -EINVAL;;
+ int ret = -EINVAL;
PHM_FUNC_CHECK(hwmgr);
adev = hwmgr->adev;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v14 10/17] fs, arm64: untag user pointers in fs/userfaultfd.c
On Tue, Apr 30, 2019 at 03:25:06PM +0200, Andrey Konovalov wrote: > This patch is a part of a series that extends arm64 kernel ABI to allow to > pass tagged user pointers (with the top byte set to something else other > than 0x00) as syscall arguments. > > userfaultfd_register() and userfaultfd_unregister() use provided user > pointers for vma lookups, which can only by done with untagged pointers. > > Untag user pointers in these functions. > > Signed-off-by: Andrey Konovalov > --- > fs/userfaultfd.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > index f5de1e726356..fdee0db0e847 100644 > --- a/fs/userfaultfd.c > +++ b/fs/userfaultfd.c > @@ -1325,6 +1325,9 @@ static int userfaultfd_register(struct userfaultfd_ctx > *ctx, > goto out; > } > > + uffdio_register.range.start = > + untagged_addr(uffdio_register.range.start); > + > ret = validate_range(mm, uffdio_register.range.start, >uffdio_register.range.len); > if (ret) > @@ -1514,6 +1517,8 @@ static int userfaultfd_unregister(struct > userfaultfd_ctx *ctx, > if (copy_from_user(&uffdio_unregister, buf, sizeof(uffdio_unregister))) > goto out; > > + uffdio_unregister.start = untagged_addr(uffdio_unregister.start); > + > ret = validate_range(mm, uffdio_unregister.start, >uffdio_unregister.len); > if (ret) Wouldn't it be easier to do this in validate_range()? There are a few more calls in this file, though I didn't check whether a tagged address would cause issues. -- Catalin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests
On 5/2/19 10:36 PM, Brendan Higgins wrote: > On Thu, May 2, 2019 at 6:45 PM Frank Rowand wrote: >> >> On 5/2/19 4:45 PM, Brendan Higgins wrote: >>> On Thu, May 2, 2019 at 2:16 PM Frank Rowand wrote: On 5/2/19 11:07 AM, Brendan Higgins wrote: > On Thu, May 2, 2019 at 4:02 AM Greg KH wrote: >> >> On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote: >>> From: Felix Guo >>> >>> The ultimate goal is to create minimal isolated test binaries; in the >>> meantime we are using UML to provide the infrastructure to run tests, so >>> define an abstract way to configure and run tests that allow us to >>> change the context in which tests are built without affecting the user. >>> This also makes pretty and dynamic error reporting, and a lot of other >>> nice features easier. >>> >>> kunit_config.py: >>> - parse .config and Kconfig files. >>> >>> kunit_kernel.py: provides helper functions to: >>> - configure the kernel using kunitconfig. >>> - build the kernel with the appropriate configuration. >>> - provide function to invoke the kernel and stream the output back. >>> >>> Signed-off-by: Felix Guo >>> Signed-off-by: Brendan Higgins >> >> Ah, here's probably my answer to my previous logging format question, >> right? What's the chance that these wrappers output stuff in a standard >> format that test-framework-tools can already parse? :) >>> >>> To be clear, the test-framework-tools format we are talking about is >>> TAP13[1], correct? >> >> I'm not sure what the test community prefers for a format. I'll let them >> jump in and debate that question. >> >> >>> >>> My understanding is that is what kselftest is being converted to use. >>> > > It should be pretty easy to do. I had some patches that pack up the > results into a serialized format for a presubmit service; it should be > pretty straightforward to take the same logic and just change the > output format. When examining and trying out the previous versions of the patch I found the wrappers useful to provide information about how to control and use the tests, but I had no interest in using the scripts as they do not fit in with my personal environment and workflow. In the previous versions of the patch, these helper scripts are optional, which is good for my use case. If the helper scripts are required to >>> >>> They are still optional. >>> get the data into the proper format then the scripts are not quite so optional, they become the expected environment. I think the proper format should exist without the helper scripts. >>> >>> That's a good point. A couple things, >>> >>> First off, supporting TAP13, either in the kernel or the wrapper >>> script is not hard, but I don't think that is the real issue that you >>> raise. >>> >>> If your only concern is that you will always be able to have human >>> readable KUnit results printed to the kernel log, that is a guarantee >>> I feel comfortable making. Beyond that, I think it is going to take a >>> long while before I would feel comfortable guaranteeing anything about >>> how will KUnit work, what kind of data it will want to expose, and how >>> it will be organized. I think the wrapper script provides a nice >>> facade that I can maintain, can mediate between the implementation >>> details and the user, and can mediate between the implementation >>> details and other pieces of software that might want to consume >>> results. >>> >>> [1] https://testanything.org/tap-version-13-specification.html >> >> My concern is based on a focus on my little part of the world >> (which in _previous_ versions of the patch series was the devicetree >> unittest.c tests being converted to use the kunit infrastructure). >> If I step back and think of the entire kernel globally I may end >> up with a different conclusion - but I'm going to remain myopic >> for this email. >> >> I want the test results to be usable by me and my fellow >> developers. I prefer that the test results be easily accessible >> (current printk() implementation means that kunit messages are >> just as accessible as the current unittest.c printk() output). >> If the printk() output needs to be filtered through a script >> to generate the actual test results then that is sub-optimal >> to me. It is one more step added to my workflow. And >> potentially with an embedded target a major pain to get a >> data file (the kernel log file) transferred from a target >> to my development host. > > That's fair. If that is indeed your only concern, then I don't think > the wrapper script will ever be an issue for you. You will always be > able to execute a given test the old fashioned/manual way, and the > wrapper script only summarizes results, it does not change the > contents. > >> >> I want a reported test failure to be easy to trace back to the >> point
[PATCH RFC 2/6] drm/msm: add dirty framebuffer helper
Add drm_atomic_helper_dirtyfb() callback to the msm framebuffer driver
for the dirty ioctl.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/msm_fb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
index 136058978e0f..8624a8e4025f 100644
--- a/drivers/gpu/drm/msm/msm_fb.c
+++ b/drivers/gpu/drm/msm/msm_fb.c
@@ -16,6 +16,7 @@
*/
#include
+#include
#include
#include
@@ -35,6 +36,7 @@ static struct drm_framebuffer *msm_framebuffer_init(struct
drm_device *dev,
static const struct drm_framebuffer_funcs msm_framebuffer_funcs = {
.create_handle = drm_gem_fb_create_handle,
.destroy = drm_gem_fb_destroy,
+ .dirty = drm_atomic_helper_dirtyfb,
};
#ifdef CONFIG_DEBUG_FS
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu/drm: Remove duplicate headers
From: Jagadeesh Pagadala
Remove duplicate headers which are included twice.
Signed-off-by: Jagadeesh Pagadala
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 1 -
drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c| 2 --
drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 1 -
3 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 018df2c..45a5bc6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -15,7 +15,6 @@
#include "dpu_hwio.h"
#include "dpu_hw_lm.h"
#include "dpu_hw_mdss.h"
-#include "dpu_kms.h"
#define LM_OP_MODE0x00
#define LM_OUT_SIZE 0x04
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c
index c80b967..2b44ba5 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c
@@ -26,8 +26,6 @@
#include
-#include
-
static void
nv04_bus_intr(struct nvkm_bus *bus)
{
diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
index 2c9c972..cacf2e0 100644
--- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -53,7 +53,6 @@
#include
#include
-#include
#include
#include
#include
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: display: Add ETM0700G0DH6 compatible string
The ETM0700G0DH6 is currently documented as using edt,etm070080dh6 compatible string, however the Linux kernel driver as well as a couple of DTs use edt,etm0700g0dh6 compatible string. Add it into the documentation. Signed-off-by: Marek Vasut Cc: Rob Herring Cc: Jan Tuerk Cc: Thierry Reding Cc: devicet...@vger.kernel.org To: dri-devel@lists.freedesktop.org --- .../devicetree/bindings/display/panel/edt,et-series.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt index d9f21d62422e..4cbb9dcbb344 100644 --- a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt +++ b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt @@ -32,7 +32,7 @@ simple-panel.txt | Identifier | compatbile | description | +=+=+=+ | ETM0700G0DH6| edt,etm070080dh6| WVGA TFT Display with capacitive| -| | | Touchscreen | +| | edt,etm0700g0dh6| Touchscreen | +-+-+-+ | ETM0700G0BDH6 | edt,etm070080bdh6 | Same as ETM0700G0DH6 but with | | | | inverted pixel clock. | -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 3/3] drm/tegra: Support PM QoS memory bandwidth management
Display controller (DC) performs isochronous memory transfers and thus
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.
The External Memory Controller drivers will provide memory bandwidth
management facility via the generic Power Management QoS API soonish.
This patch wires up the PM QoS API support for the display driver
beforehand.
Display won't have visual corruption on coming up from suspend state when
devfreq driver is active once all prerequisite bits will get upstreamed.
The devfreq reaction has a quite significant latency and it also doesn't
take into account the ISO transfers which may result in assumption about
lower memory bandwidth requirement than actually needed.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c| 216 +-
drivers/gpu/drm/tegra/dc.h| 8 ++
drivers/gpu/drm/tegra/drm.c | 18 +++
drivers/gpu/drm/tegra/plane.c | 1 +
drivers/gpu/drm/tegra/plane.h | 4 +-
5 files changed, 245 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 41cb67db6dbc..8c5b9e71ca6f 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -514,6 +514,107 @@ static void tegra_dc_setup_window(struct tegra_plane
*plane,
tegra_plane_setup_blending(plane, window);
}
+static unsigned long
+tegra_plane_memory_bandwidth(struct drm_plane_state *state,
+struct tegra_dc_window *window)
+{
+ struct tegra_plane_state *tegra_state;
+ struct drm_crtc_state *crtc_state;
+ struct tegra_dc_window win;
+ unsigned int mul;
+ unsigned int bpp;
+ bool planar;
+ bool yuv;
+
+ if (!state->fb || !state->visible)
+ return 0;
+
+ crtc_state = drm_atomic_get_new_crtc_state(state->state, state->crtc);
+ tegra_state = to_tegra_plane_state(state);
+
+ if (!window)
+ window = &win;
+
+ window->src.w = drm_rect_width(&state->src) >> 16;
+ window->src.h = drm_rect_height(&state->src) >> 16;
+ window->dst.w = drm_rect_width(&state->dst);
+ window->dst.h = drm_rect_height(&state->dst);
+ window->format = tegra_state->format;
+ window->tiling = tegra_state->tiling;
+
+ yuv = tegra_plane_format_is_yuv(window->format, &planar);
+ if (!yuv || !planar)
+ bpp = state->fb->format->cpp[0] * 8;
+ else
+ bpp = 16;
+
+ /*
+* Horizontal downscale takes extra bandwidth which roughly depends
+* on the scaled width.
+*/
+ if (window->src.w > window->dst.w)
+ mul = (window->src.w - window->dst.w) * bpp / 2048 + 1;
+ else
+ mul = 1;
+
+ /*
+* Ignore window if its width is small enough such that data-prefetch
+* FIFO will easily help to overcome temporal memory pressure. This is
+* a typical case for the cursor's plane.
+*/
+ if (mul == 1 && window->src.w * bpp <= 2048)
+ return 0;
+
+ /* mode.clock in kHz, bandwidth in Mbit/s */
+ return crtc_state->mode.clock / 1000 * bpp * mul;
+}
+
+static unsigned long
+tegra20_plane_memory_bandwidth(struct drm_plane_state *state)
+{
+ /* x2: ~50% efficiency */
+ return tegra_plane_memory_bandwidth(state, NULL) * 2;
+}
+
+static unsigned long
+tegra30_plane_memory_bandwidth(struct drm_plane_state *state)
+{
+ struct tegra_dc_window window;
+ unsigned long bandwidth;
+
+ bandwidth = tegra_plane_memory_bandwidth(state, &window);
+
+ /* x2 memory overfetch for tiled framebuffer and DDR3 */
+ if (window.tiling.mode == TEGRA_BO_TILING_MODE_TILED)
+ bandwidth *= 2;
+
+ /* x2: ~50% efficiency */
+ return bandwidth * 2;
+}
+
+static unsigned long
+tegra114_plane_memory_bandwidth(struct drm_plane_state *state)
+{
+ struct tegra_dc_window window;
+ unsigned long bandwidth;
+
+ bandwidth = tegra_plane_memory_bandwidth(state, &window);
+
+ /* x2 memory overfetch for tiled framebuffer and DDR3 */
+ if (window.tiling.mode == TEGRA_BO_TILING_MODE_TILED)
+ bandwidth *= 2;
+
+ /* 2-channel memory */
+ return bandwidth;
+}
+
+static unsigned long
+tegra124_plane_memory_bandwidth(struct drm_plane_state *state)
+{
+ /* 64bit memory bus */
+ return tegra_plane_memory_bandwidth(state, NULL);
+}
+
static const u32 tegra20_primary_formats[] = {
DRM_FORMAT_ARGB,
DRM_FORMAT_ARGB1555,
@@ -603,8 +704,10 @@ static int tegra_plane_atomic_check(struct drm_plane
*plane,
int err;
/* no need for further checks if the plane is being disabled */
- if (!state->crtc)
+ if (!state->crtc) {
+ plane_state->memory
[PATCH RFC 1/6] drm/msm: fix null pointer dereference in msm_atomic_prepare_fb()
_msm_gem_new() calls msm_gem_new_impl() with a NULL reservation_object
struct. msm_atomic_prepare_fb() assumes that the reservation_object is
always set, and attempts to reference a NULL pointer. Correct this by
checking to see if this value is NULL.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/msm_atomic.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index f5b1256e32b6..0da80a93876a 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -56,10 +56,12 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
return 0;
obj = msm_framebuffer_bo(new_state->fb, 0);
- msm_obj = to_msm_bo(obj);
- fence = reservation_object_get_excl_rcu(msm_obj->resv);
- drm_atomic_set_fence_for_plane(new_state, fence);
+ msm_obj = to_msm_bo(obj);
+ if (msm_obj->resv) {
+ fence = reservation_object_get_excl_rcu(msm_obj->resv);
+ drm_atomic_set_fence_for_plane(new_state, fence);
+ }
return msm_framebuffer_prepare(new_state->fb, kms->aspace);
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 5/6] ARM: dts: qcom: msm8974-hammerhead: add support for backlight
Add necessary device tree nodes for the main LCD backlight.
Signed-off-by: Brian Masney
---
This requires this series that I submitted to the LED / backlight
subsystem:
https://lore.kernel.org/lkml/20190424092505.6578-1-masn...@onstation.org/
It's received 3 {Reviewed,Acked}-Bys, and has no outstanding change
requests, so I expect it'll be merged soon.
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 34 +++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
index b3b04736a159..b7cf4b1019e9 100644
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -289,6 +289,16 @@
};
};
+ i2c11_pins: i2c11 {
+ mux {
+ pins = "gpio83", "gpio84";
+ function = "blsp_i2c11";
+
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
i2c12_pins: i2c12 {
mux {
pins = "gpio87", "gpio88";
@@ -369,6 +379,30 @@
};
};
+ i2c@f9967000 {
+ status = "ok";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c11_pins>;
+ clock-frequency = <355000>;
+ qcom,src-freq = <5000>;
+
+ led-controller@38 {
+ compatible = "ti,lm3630a";
+ status = "ok";
+ reg = <0x38>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ led-sources = <0 1>;
+ label = "lcd-backlight";
+ default-brightness = <200>;
+ };
+ };
+ };
+
i2c@f9968000 {
status = "ok";
pinctrl-names = "default";
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v14 13/17] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr
On Tue, Apr 30, 2019 at 03:25:09PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> mlx4_get_umem_mr() uses provided user pointers for vma lookups, which can
> only by done with untagged pointers.
>
> Untag user pointers in this function.
>
> Signed-off-by: Andrey Konovalov
> Reviewed-by: Leon Romanovsky
> ---
> drivers/infiniband/hw/mlx4/mr.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/infiniband/hw/mlx4/mr.c b/drivers/infiniband/hw/mlx4/mr.c
> index 395379a480cb..9a35ed2c6a6f 100644
> --- a/drivers/infiniband/hw/mlx4/mr.c
> +++ b/drivers/infiniband/hw/mlx4/mr.c
> @@ -378,6 +378,7 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata
> *udata, u64 start,
>* again
>*/
> if (!ib_access_writable(access_flags)) {
> + unsigned long untagged_start = untagged_addr(start);
> struct vm_area_struct *vma;
>
> down_read(¤t->mm->mmap_sem);
> @@ -386,9 +387,9 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata
> *udata, u64 start,
>* cover the memory, but for now it requires a single vma to
>* entirely cover the MR to support RO mappings.
>*/
> - vma = find_vma(current->mm, start);
> - if (vma && vma->vm_end >= start + length &&
> - vma->vm_start <= start) {
> + vma = find_vma(current->mm, untagged_start);
> + if (vma && vma->vm_end >= untagged_start + length &&
> + vma->vm_start <= untagged_start) {
> if (vma->vm_flags & VM_WRITE)
> access_flags |= IB_ACCESS_LOCAL_WRITE;
> } else {
Discussion ongoing on the previous version of the patch but I'm more
inclined to do this in ib_uverbs_(re)reg_mr() on cmd.start.
--
Catalin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm/pgtable: Drop pgtable_t variable from pte_fn_t functions
On Thu, May 02, 2019 at 04:14:57PM +0200, Martin Schwidefsky wrote: > On Thu, 2 May 2019 06:46:23 -0700 > Matthew Wilcox wrote: > > > On Thu, May 02, 2019 at 06:48:46PM +0530, Anshuman Khandual wrote: > > > Drop the pgtable_t variable from all implementation for pte_fn_t as none > > > of > > > them use it. apply_to_pte_range() should stop computing it as well. Should > > > help us save some cycles. > > > > You didn't add Martin Schwidefsky for some reason. He introduced > > it originally for s390 for sub-page page tables back in 2008 (commit > > 2f569afd9c). I think he should confirm that he no longer needs it. > > With its 2K pte tables s390 can not deal with a (struct page *) as a reference > to a page table. But if there are no user of the apply_to_page_range() API > left which actually make use of the token argument we can safely drop it. Interestingly, I don't think there ever was a user which used that argument. Looking at your 2f56 patch, you only converted one function (presumably there was only one caller of apply_to_page_range() at the time), and it didn't u se any of the arguments. Xen was the initial user, and the two other functions they added also didn't use that argument. Looking at a quick sample of users added since, none of them appear to have ever used that argument. So removing it seems best. Acked-by: Matthew Wilcox ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
KASAN: use-after-free Read in add_uevent_var
Hello,
syzbot found the following crash on:
HEAD commit:a4ccb5f9 Merge tag 'drm-fixes-2019-05-03' of git://anongit..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1205d570a0
kernel config: https://syzkaller.appspot.com/x/.config?x=2bd0da4b8de0b004
dashboard link: https://syzkaller.appspot.com/bug?extid=6da9575ba2db4da91831
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
userspace arch: i386
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1769f62ca0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=167ae984a0
The bug was bisected to:
commit 0a1c7959acd9674a0e4e59f911f3e5fbf25fd693
Author: Wolfram Sang
Date: Wed May 17 15:22:18 2017 +
gpu: drm: tc35876x: move header file out of I2C realm
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=138fe12ca0
final crash:https://syzkaller.appspot.com/x/report.txt?x=104fe12ca0
console output: https://syzkaller.appspot.com/x/log.txt?x=178fe12ca0
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6da9575ba2db4da91...@syzkaller.appspotmail.com
Fixes: 0a1c7959acd9 ("gpu: drm: tc35876x: move header file out of I2C
realm")
RAX: ffda RBX: 0003 RCX: 5502
RDX: RSI: 080daf20 RDI: 080f0f84
RBP: R08: R09:
R10: R11: R12:
R13: R14: R15:
==
BUG: KASAN: use-after-free in string+0x208/0x230 lib/vsprintf.c:606
Read of size 1 at addr 8880a55aa200 by task syz-executor222/7839
CPU: 1 PID: 7839 Comm: syz-executor222 Not tainted 5.1.0-rc7+ #98
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
__asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:129
string+0x208/0x230 lib/vsprintf.c:606
vsnprintf+0xbfc/0x1af0 lib/vsprintf.c:2396
add_uevent_var+0x14d/0x310 lib/kobject_uevent.c:661
input_dev_uevent+0x163/0x890 drivers/input/input.c:1594
dev_uevent+0x312/0x580 drivers/base/core.c:1180
kobject_uevent_env+0x487/0x1030 lib/kobject_uevent.c:549
kobject_uevent+0x20/0x26 lib/kobject_uevent.c:638
kobject_cleanup lib/kobject.c:649 [inline]
kobject_release lib/kobject.c:691 [inline]
kref_put include/linux/kref.h:67 [inline]
kobject_put.cold+0x177/0x2ec lib/kobject.c:708
put_device+0x20/0x30 drivers/base/core.c:2205
input_put_device include/linux/input.h:349 [inline]
evdev_free+0x51/0x70 drivers/input/evdev.c:369
device_release+0x7d/0x210 drivers/base/core.c:1064
kobject_cleanup lib/kobject.c:662 [inline]
kobject_release lib/kobject.c:691 [inline]
kref_put include/linux/kref.h:67 [inline]
kobject_put.cold+0x28f/0x2ec lib/kobject.c:708
cdev_default_release+0x41/0x50 fs/char_dev.c:607
kobject_cleanup lib/kobject.c:662 [inline]
kobject_release lib/kobject.c:691 [inline]
kref_put include/linux/kref.h:67 [inline]
kobject_put.cold+0x28f/0x2ec lib/kobject.c:708
cdev_put.part.0+0x39/0x50 fs/char_dev.c:368
cdev_put+0x20/0x30 fs/char_dev.c:366
__fput+0x6df/0x8d0 fs/file_table.c:281
fput+0x16/0x20 fs/file_table.c:309
task_work_run+0x14a/0x1c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x90a/0x2fa0 kernel/exit.c:876
do_group_exit+0x135/0x370 kernel/exit.c:980
__do_sys_exit_group kernel/exit.c:991 [inline]
__se_sys_exit_group kernel/exit.c:989 [inline]
__ia32_sys_exit_group+0x44/0x50 kernel/exit.c:989
do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
do_fast_syscall_32+0x281/0xc98 arch/x86/entry/common.c:397
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7ff7849
Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90 90
90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:fff2db8c EFLAGS: 0292 ORIG_RAX: 00fc
RAX: ffda RBX: RCX: 080f1298
RDX: RSI: 080daf1c RDI: 080f12a0
RBP: 0001 R08: R09:
R10: R11: R12:
R13: R14: R15:
Allocated by task 7839:
save_stack+0x45/0xd0 mm/kasan/common.c:75
set_track mm/kasan/common.c:87 [inline]
__kasan_kmalloc mm/kasan/common.c:497 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:511
__do_kmalloc mm/slab.c:3727 [inline]
__kmalloc_track_ca
[PATCH v1 2/3] drm/tegra: dc: Extend debug stats with total number of events
I found useful to know the total number of underflow events while was
working on adding support for memory bandwidth management. Currently
the debug stats are getting reset after disabling CRTC, let's account
the overall number of events that doesn't get reset.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c | 10 ++
drivers/gpu/drm/tegra/dc.h | 5 +
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index cf622a07e9b6..41cb67db6dbc 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1482,6 +1482,11 @@ static int tegra_dc_show_stats(struct seq_file *s, void
*data)
seq_printf(s, "underflow: %lu\n", dc->stats.underflow);
seq_printf(s, "overflow: %lu\n", dc->stats.overflow);
+ seq_printf(s, "frames total: %lu\n", dc->stats.frames_total);
+ seq_printf(s, "vblank total: %lu\n", dc->stats.vblank_total);
+ seq_printf(s, "underflow total: %lu\n", dc->stats.underflow_total);
+ seq_printf(s, "overflow total: %lu\n", dc->stats.overflow_total);
+
return 0;
}
@@ -1945,6 +1950,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): frame end\n", __func__);
*/
+ dc->stats.frames_total++;
dc->stats.frames++;
}
@@ -1953,6 +1959,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
dev_dbg(dc->dev, "%s(): vertical blank\n", __func__);
*/
drm_crtc_handle_vblank(&dc->base);
+ dc->stats.vblank_total++;
dc->stats.vblank++;
}
@@ -1960,6 +1967,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): underflow\n", __func__);
*/
+ dc->stats.underflow_total++;
dc->stats.underflow++;
}
@@ -1967,11 +1975,13 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): overflow\n", __func__);
*/
+ dc->stats.overflow_total++;
dc->stats.overflow++;
}
if (status & HEAD_UF_INT) {
dev_dbg_ratelimited(dc->dev, "%s(): head underflow\n",
__func__);
+ dc->stats.underflow_total++;
dc->stats.underflow++;
}
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index 1256dfb6b2f5..ab25157c948e 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -41,6 +41,11 @@ struct tegra_dc_stats {
unsigned long vblank;
unsigned long underflow;
unsigned long overflow;
+
+ unsigned long frames_total;
+ unsigned long vblank_total;
+ unsigned long underflow_total;
+ unsigned long overflow_total;
};
struct tegra_windowgroup_soc {
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/3] Tegra DRM: Support memory bandwidth management for display
Hello, Display controllers have a need for minimum memory bandwidth in order to maintain data-stream to output at a required rate. There is a visual corruption once the requirement is violated and CRTC reset may be required in order to recover. This series adds preliminary support for the memory bandwidth management, it will become active once Memory Controller drivers will get support for the PM memory bandwidth QoS. Dmitry Osipenko (3): drm/tegra: dc: Tune up high priority request controls on Tegra20 drm/tegra: dc: Extend debug stats with total number of events drm/tegra: Support PM QoS memory bandwidth management drivers/gpu/drm/tegra/dc.c| 234 +- drivers/gpu/drm/tegra/dc.h| 13 ++ drivers/gpu/drm/tegra/drm.c | 18 +++ drivers/gpu/drm/tegra/plane.c | 1 + drivers/gpu/drm/tegra/plane.h | 4 +- 5 files changed, 264 insertions(+), 6 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EXT] Re: [PATCH v9 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs
On Jo, 2019-05-02 at 17:36 +0200, Andreas Färber wrote: > > Am 30.04.19 um 16:40 schrieb Guido Günther: > > > > This adds support for the Mixel DPHY as found on i.MX8 CPUs but > > since > > this is an IP core it will likely be found on others in the future. > > So > > instead of adding this to the nwl host driver make it a generic PHY > > driver. > > > > The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP > > can be > > added once the necessary system controller bits are in via > > mixel_dphy_devdata. > > > > Co-authored-by: Robert Chiras > This should be Co-developed-by and is lacking a Signed-off-by from > that > author. Robert, can you please provide one? Sure. Added below. > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .kernel.org%2Fdoc%2Fhtml%2Flatest%2Fprocess%2Fsubmitting- > patches.html%23when-to-use-acked-by-cc-and-co-developed- > by&data=02%7C01%7Crobert.chiras%40nxp.com%7C012f6577aab440f62e160 > 8d6cf13f2a0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636924081917 > 754411&sdata=%2FrFNrAaL7MwPXuaYOlxfa8O4JLNILq5eFEq92qV2JZg%3D& > ;reserved=0 > > > > > Signed-off-by: Guido Günther Signed-off-by: Robert Chiras > Thanks, > Andreas > > -- > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah > HRB 21284 (AG Nürnberg) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests
On 5/3/19 4:14 PM, Brendan Higgins wrote: >> On 5/2/19 10:36 PM, Brendan Higgins wrote: >>> On Thu, May 2, 2019 at 6:45 PM Frank Rowand wrote: On 5/2/19 4:45 PM, Brendan Higgins wrote: > On Thu, May 2, 2019 at 2:16 PM Frank Rowand > wrote: >> >> On 5/2/19 11:07 AM, Brendan Higgins wrote: >>> On Thu, May 2, 2019 at 4:02 AM Greg KH >>> wrote: On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote: > From: Felix Guo > > The ultimate goal is to create minimal isolated test binaries; in the > meantime we are using UML to provide the infrastructure to run tests, > so > define an abstract way to configure and run tests that allow us to > change the context in which tests are built without affecting the > user. > This also makes pretty and dynamic error reporting, and a lot of other > nice features easier. > > kunit_config.py: > - parse .config and Kconfig files. > > kunit_kernel.py: provides helper functions to: > - configure the kernel using kunitconfig. > - build the kernel with the appropriate configuration. > - provide function to invoke the kernel and stream the output back. > > Signed-off-by: Felix Guo > Signed-off-by: Brendan Higgins Ah, here's probably my answer to my previous logging format question, right? What's the chance that these wrappers output stuff in a standard format that test-framework-tools can already parse? :) > > To be clear, the test-framework-tools format we are talking about is > TAP13[1], correct? I'm not sure what the test community prefers for a format. I'll let them jump in and debate that question. > > My understanding is that is what kselftest is being converted to use. > >>> >>> It should be pretty easy to do. I had some patches that pack up the >>> results into a serialized format for a presubmit service; it should be >>> pretty straightforward to take the same logic and just change the >>> output format. >> >> When examining and trying out the previous versions of the patch I found >> the wrappers useful to provide information about how to control and use >> the tests, but I had no interest in using the scripts as they do not >> fit in with my personal environment and workflow. >> >> In the previous versions of the patch, these helper scripts are optional, >> which is good for my use case. If the helper scripts are required to > > They are still optional. > >> get the data into the proper format then the scripts are not quite so >> optional, they become the expected environment. I think the proper >> format should exist without the helper scripts. > > That's a good point. A couple things, > > First off, supporting TAP13, either in the kernel or the wrapper > script is not hard, but I don't think that is the real issue that you > raise. > > If your only concern is that you will always be able to have human > readable KUnit results printed to the kernel log, that is a guarantee > I feel comfortable making. Beyond that, I think it is going to take a > long while before I would feel comfortable guaranteeing anything about > how will KUnit work, what kind of data it will want to expose, and how > it will be organized. I think the wrapper script provides a nice > facade that I can maintain, can mediate between the implementation > details and the user, and can mediate between the implementation > details and other pieces of software that might want to consume > results. > > [1] https://testanything.org/tap-version-13-specification.html My concern is based on a focus on my little part of the world (which in _previous_ versions of the patch series was the devicetree unittest.c tests being converted to use the kunit infrastructure). If I step back and think of the entire kernel globally I may end up with a different conclusion - but I'm going to remain myopic for this email. I want the test results to be usable by me and my fellow developers. I prefer that the test results be easily accessible (current printk() implementation means that kunit messages are just as accessible as the current unittest.c printk() output). If the printk() output needs to be filtered through a script to generate the actual test results then that is sub-optimal to me. It is one more step added to my workflow. And potentially with an embedded target a major pain to get a data file (the kernel log file) transferred from a target to my development host. >>> >>> That's fair. If that is indeed your only concern, then I don't think >>>
[PATCH RFC 4/6] ARM: dts: msm8974: add display support
Add the MDP5, DSI and DSI PHY blocks for the display found on the
msm8974 SoCs. This is based on work from msm8916.dtsi and Jonathan
Marek.
Signed-off-by: Brian Masney
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 132
1 file changed, 132 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 45b5c8ef0374..3f613c5b95a1 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -3,6 +3,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1085,6 +1086,137 @@
};
};
};
+
+ mdss: mdss@fd90 {
+ status = "disabled";
+
+ compatible = "qcom,mdss";
+ reg = <0xfd90 0x100>,
+ <0xfd924000 0x1000>;
+ reg-names = "mdss_phys",
+ "vbif_phys";
+
+ power-domains = <&mmcc MDSS_GDSC>;
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "vsync";
+
+ interrupts = ;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mdp: mdp@fd90 {
+ status = "disabled";
+
+ compatible = "qcom,mdp5";
+ reg = <0xfd900100 0x22000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0 0>;
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_MDP_CLK>,
+<&mmcc MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdp5_intf1_out: endpoint {
+ remote-endpoint =
<&dsi0_in>;
+ };
+ };
+ };
+ };
+
+ dsi0: dsi@fd922800 {
+ status = "disabled";
+
+ compatible = "qcom,mdss-dsi-ctrl";
+ reg = <0xfd922800 0x1f8>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
+
+ assigned-clocks = <&mmcc BYTE0_CLK_SRC>,
+ <&mmcc PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi_phy0 0>,
+<&dsi_phy0 1>;
+
+ clocks = <&mmcc MDSS_MDP_CLK>,
+<&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_BYTE0_CLK>,
+<&mmcc MDSS_PCLK0_CLK>,
+<&mmcc MDSS_ESC0_CLK>,
+<&mmcc MMSS_MISC_AHB_CLK>;
+ clock-names = "mdp_core",
+ "iface",
+ "bus",
+ "byte",
+ "pixel",
+ "core",
+ "core_mmss";
+
+ phys = <&dsi_phy0>;
+ phy-names = "dsi-phy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+
[PATCH] drm: panel-orientation-quirks: Update GPD Win 2 FW dates
The GPD Win 2 is shipping with a new firmware release date. As
the quirk is still required with the new firmware, this commit
adds the new release date to the quirks table.
Signed-off-by: Jared Baldridge
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 52e445bb1aa5..e0d0f3169581 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -63,7 +63,7 @@ static const struct drm_dmi_panel_orientation_data gpd_win2 =
{
.width = 720,
.height = 1280,
.bios_dates = (const char * const []){
- "12/07/2017", "05/24/2018", "06/29/2018", NULL },
+ "12/07/2017", "05/24/2018", "06/29/2018", "07/30/2018", NULL },
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 0/6] ARM: qcom: initial Nexus 5 display support
Here is a patch series that adds initial display support for the LG Nexus 5 (hammerhead) phone. The board boots into terminal mode, however there is a several second (or more) delay when writing to tty1 compared to when the changes are actually shown on the screen. The following errors are in dmesg: msm fd90.mdss: pp done time out, lm=0 [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:49:crtc-0] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:32:plane-0] flip_done timed out mdp5_get_scanoutpos() and mdp5_get_vblank_counter() both return 0, which is causing this stack trace to be dumped into the system log several times: WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1430 drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290 [CRTC:49:crtc-0] vblank wait timed out Modules linked in: CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.1.0-rc6-next-20190426-6-g35c0d32a96e1-dirty #191 Hardware name: Generic DT based system Workqueue: events deferred_probe_work_func [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x78/0x8c) [] (dump_stack) from [] (__warn.part.3+0xb8/0xd4) [] (__warn.part.3) from [] (warn_slowpath_fmt+0x64/0x88) [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290) [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] (mdp5_complete_commit+0x14/0x40) [] (mdp5_complete_commit) from [] (msm_atomic_commit_tail+0xa8/0x140) [] (msm_atomic_commit_tail) from [] (commit_tail+0x40/0x6c) [] (drm_atomic_helper_commit) from [] (restore_fbdev_mode_atomic+0x168/0x1d4) In mdp5_irq(), I see that a few vblank IRQ statuses (0x1000) come through when the board boots, drm_handle_vblank() is called, and the screen updates, however mdp5_get_scanoutpos() continues to return 0 after these operations complete. I don't see any ping-pong done IRQ statuses (0x100) come through in mdp5_irq(). I can get the text console to work with a 4.17 kernel with this patch https://patchwork.kernel.org/patch/10321845/ plus about a dozen or more other patches that have been mainlined since that release. The pp done and vblank messages still happen, however tty1 is updated when I write to it and Wayland works. The lg,acx467akm-7 panel listed below is currently handled by the simple panel driver since it is sufficient for 4.17 kernel, but that may need to change in the future for the power on commands. To be sure, I followed the instructions at https://github.com/freedreno/freedreno/wiki/DSI-Panel-Driver-Porting for porting the almost 400 panel on commands from the downstream kernel sources at https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L645. The screen turns all white when the panel display is turned on and the panel exits sleep mode. Unfortunately, there are a lot of power on commands listed in the downstream device tree that aren't listed in mipi_display.h. Thanks in advance for any advice that you can provide. Brian Masney (6): drm/msm: fix null pointer dereference in msm_atomic_prepare_fb() drm/msm: add dirty framebuffer helper ARM: qcom_defconfig: add display-related options ARM: dts: msm8974: add display support ARM: dts: qcom: msm8974-hammerhead: add support for backlight ARM: dts: qcom: msm8974-hammerhead: add support for display .../qcom-msm8974-lge-nexus5-hammerhead.dts| 79 +++ arch/arm/boot/dts/qcom-msm8974.dtsi | 132 ++ arch/arm/configs/qcom_defconfig | 5 + drivers/gpu/drm/msm/msm_atomic.c | 8 +- drivers/gpu/drm/msm/msm_fb.c | 2 + 5 files changed, 223 insertions(+), 3 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/3] drm/tegra: dc: Tune up high priority request controls on Tegra20
Tegra20 has a high priority request control that allow to configure when display's memory client should perform read requests with a higher priority (Tegra30+ uses other means). Set up the controls for a more aggressive prefetching to reliably avoid FIFO underflow on a lower memory frequency, this allow to safely drop the memory bandwidth requirement by about two times in a most popular cases (only one display active, video overlay inactive, no scaling is done). Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/dc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 607a6ea17ecc..cf622a07e9b6 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -1833,12 +1833,12 @@ static void tegra_crtc_atomic_enable(struct drm_crtc *crtc, tegra_dc_writel(dc, value, DC_CMD_INT_POLARITY); /* initialize timer */ - value = CURSOR_THRESHOLD(0) | WINDOW_A_THRESHOLD(0x20) | - WINDOW_B_THRESHOLD(0x20) | WINDOW_C_THRESHOLD(0x20); + value = CURSOR_THRESHOLD(0) | WINDOW_A_THRESHOLD(0x70) | + WINDOW_B_THRESHOLD(0x30) | WINDOW_C_THRESHOLD(0x70); tegra_dc_writel(dc, value, DC_DISP_DISP_MEM_HIGH_PRIORITY); - value = CURSOR_THRESHOLD(0) | WINDOW_A_THRESHOLD(1) | - WINDOW_B_THRESHOLD(1) | WINDOW_C_THRESHOLD(1); + value = CURSOR_THRESHOLD(0) | WINDOW_A_THRESHOLD(0) | + WINDOW_B_THRESHOLD(0) | WINDOW_C_THRESHOLD(0); tegra_dc_writel(dc, value, DC_DISP_DISP_MEM_HIGH_PRIORITY_TIMER); value = VBLANK_INT | WIN_A_UF_INT | WIN_B_UF_INT | WIN_C_UF_INT | -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: use-after-free Read in add_uevent_var
This seems to be triggered by "pkg/report: skip printk and other printing functions " on syzbot side. The fix should be "kobject: Don't trigger kobject_uevent(KOBJ_REMOVE) twice." in linux-next.git. #syz dup: KASAN: use-after-free Read in string ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/17] kunit: test: add support for test abort
On 2019-05-03 12:48 a.m., Brendan Higgins wrote:
> On Thu, May 2, 2019 at 8:15 PM Logan Gunthorpe wrote:
>> On 2019-05-01 5:01 p.m., Brendan Higgins wrote:
>>> +/*
>>> + * struct kunit_try_catch - provides a generic way to run code which might
>>> fail.
>>> + * @context: used to pass user data to the try and catch functions.
>>> + *
>>> + * kunit_try_catch provides a generic, architecture independent way to
>>> execute
>>> + * an arbitrary function of type kunit_try_catch_func_t which may bail out
>>> by
>>> + * calling kunit_try_catch_throw(). If kunit_try_catch_throw() is called,
>>> @try
>>> + * is stopped at the site of invocation and @catch is catch is called.
>>
>> I found some of the C++ comparisons in this series a bit distasteful but
>> wasn't going to say anything until I saw the try catch But looking
>> into the implementation it's just a thread that can exit early which
>> seems fine to me. Just a poor choice of name I guess...
>
> Guilty as charged (I have a long history with C++, sorry). Would you
> prefer I changed the name? I just figured that try-catch is a commonly
> understood pattern that describes exactly what I am doing.
It is a commonly understood pattern, but I don't think it's what the
code is doing. Try-catch cleans up an entire stack and allows each level
of the stack to apply local cleanup. This implementation simply exits a
thread and has none of that complexity. To me, it seems like an odd
abstraction here as it's really just a test runner that can exit early
(though I haven't seen the follow-up UML implementation).
I would prefer to see this cleaned up such that the abstraction matches
more what's going on but I don't feel that strongly about it so I'll
leave it up to you to figure out what's best unless other reviewers have
stronger opinions.
>>
>> [snip]
>>
>>> +static void __noreturn kunit_abort(struct kunit *test)
>>> +{
>>> + kunit_set_death_test(test, true);
>>> +
>>> + kunit_try_catch_throw(&test->try_catch);
>>> +
>>> + /*
>>> + * Throw could not abort from test.
>>> + *
>>> + * XXX: we should never reach this line! As kunit_try_catch_throw is
>>> + * marked __noreturn.
>>> + */
>>> + WARN_ONCE(true, "Throw could not abort from test!\n");
>>> +}
>>> +
>>> int kunit_init_test(struct kunit *test, const char *name)
>>> {
>>> spin_lock_init(&test->lock);
>>> @@ -77,6 +103,7 @@ int kunit_init_test(struct kunit *test, const char *name)
>>> test->name = name;
>>> test->vprintk = kunit_vprintk;
>>> test->fail = kunit_fail;
>>> + test->abort = kunit_abort;
>>
>> There are a number of these function pointers which seem to be pointless
>> to me as you only ever set them to one function. Just call the function
>> directly. As it is, it is an unnecessary indirection for someone reading
>> the code. If and when you have multiple implementations of the function
>> then add the pointer. Don't assume you're going to need it later on and
>> add all this maintenance burden if you never use it..
>
> Ah, yes, Frank (and probably others) previously asked me to remove
> unnecessary method pointers; I removed all the totally unused ones. As
> for these, I don't use them in this patchset, but I use them in my
> patchsets that will follow up this one. These in particular are
> present so that they can be mocked out for testing.
Adding indirection and function pointers solely for the purpose of
mocking out while testing doesn't sit well with me and I don't think it
should be a pattern that's encouraged. Adding extra complexity like this
to a design to make it unit-testable doesn't seem like something that
makes sense in kernel code. Especially given that indirect calls are
more expensive in the age of spectre.
Also, mocking these particular functions seems like it's an artifact of
how you've designed the try/catch abstraction. If the abstraction was
more around an abort-able test runner then it doesn't make sense to need
to mock out the abort/fail functions as you will be testing overly
generic features of something that don't seem necessary to the
implementation.
>>
>> [snip]
>>
>>> +void kunit_generic_try_catch_init(struct kunit_try_catch *try_catch)
>>> +{
>>> + try_catch->run = kunit_generic_run_try_catch;
>>> + try_catch->throw = kunit_generic_throw;
>>> +}
>>
>> Same here. There's only one implementation of try_catch and I can't
>> really see any sensible justification for another implementation. Even
>> if there is, add the indirection when the second implementation is
>> added. This isn't C++ and we don't need to make everything a "method".
>
> These methods are for a UML specific implementation in a follow up
> patchset, which is needed for some features like crash recovery, death
> tests, and removes dependence on kthreads.
>
> I know this probably sounds like premature complexity. Arguably it is
> in hindsight, but I wrote those features before I pulled out these
> interfaces (they wer
[PATCH RFC 3/6] ARM: qcom_defconfig: add display-related options
Add the CMA (Contiguous Memory Allocator) for the MSM DRM driver, the simple panel, and the TI LM3630A driver in order to support the display on the LG Nexus 5 (hammerhead) phone. Signed-off-by: Brian Masney --- The panel and backlight are currently compiled into the kernel, but will be moved to be modules once the display is fully working in a later verison of this patch series. arch/arm/configs/qcom_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig index c1854751c99a..4f02636f832e 100644 --- a/arch/arm/configs/qcom_defconfig +++ b/arch/arm/configs/qcom_defconfig @@ -37,6 +37,7 @@ CONFIG_ARM_CPUIDLE=y CONFIG_VFP=y CONFIG_NEON=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +CONFIG_CMA=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -146,12 +147,14 @@ CONFIG_REGULATOR_QCOM_SMD_RPM=y CONFIG_REGULATOR_QCOM_SPMI=y CONFIG_MEDIA_SUPPORT=y CONFIG_DRM=y +CONFIG_DRM_PANEL_SIMPLE=y CONFIG_FB=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_GENERIC is not set +CONFIG_BACKLIGHT_LM3630A=y CONFIG_BACKLIGHT_LP855X=y CONFIG_SOUND=y CONFIG_SND=y @@ -262,6 +265,8 @@ CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y +CONFIG_DMA_CMA=y +CONFIG_CMA_SIZE_MBYTES=256 CONFIG_PRINTK_TIME=y CONFIG_DYNAMIC_DEBUG=y CONFIG_DEBUG_INFO=y -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 6/6] ARM: dts: qcom: msm8974-hammerhead: add support for display
Add initial support for the display found on the LG Nexus 5 (hammerhead)
phone.
Signed-off-by: Brian Masney
---
See the cover letter on this patch series for details about the issue
that I'm running into with this board.
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 45 +++
1 file changed, 45 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
index b7cf4b1019e9..749226e18ab5 100644
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -500,6 +500,51 @@
};
};
};
+
+ mdss@fd90 {
+ status = "ok";
+
+ mdp@fd90 {
+ status = "ok";
+ };
+
+ dsi@fd922800 {
+ status = "ok";
+
+ vdda-supply = <&pm8941_l2>;
+ vdd-supply = <&pm8941_lvs3>;
+ vddio-supply = <&pm8941_l12>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&panel_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+
+ panel: panel@0 {
+ reg = <0>;
+ compatible = "lg,acx467akm-7";
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+
+ dsi-phy@fd922a00 {
+ status = "ok";
+
+ vddio-supply = <&pm8941_l12>;
+ };
+ };
};
&spmi_bus {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] RFC: console: hack up console_trylock more
On Thu 2019-05-02 16:16:43, Daniel Vetter wrote: > console_trylock, called from within printk, can be called from pretty > much anywhere. Including try_to_wake_up. Note that this isn't common, > usually the box is in pretty bad shape at that point already. But it > really doesn't help when then lockdep jumps in and spams the logs, > potentially obscuring the real backtrace we're really interested in. > One case I've seen (slightly simplified backtrace): > > Call Trace: > > console_trylock+0xe/0x60 > vprintk_emit+0xf1/0x320 > printk+0x4d/0x69 > __warn_printk+0x46/0x90 > native_smp_send_reschedule+0x2f/0x40 > check_preempt_curr+0x81/0xa0 > ttwu_do_wakeup+0x14/0x220 > try_to_wake_up+0x218/0x5f0 > pollwake+0x6f/0x90 > credit_entropy_bits+0x204/0x310 > add_interrupt_randomness+0x18f/0x210 > handle_irq+0x67/0x160 > do_IRQ+0x5e/0x130 > common_interrupt+0xf/0xf > > > This alone isn't a problem, but the spinlock in the semaphore is also > still held while waking up waiters (up() -> __up() -> try_to_wake_up() > callchain), which then closes the runqueue vs. semaphore.lock loop, > and upsets lockdep, which issues a circular locking splat to dmesg. > Worse it upsets developers, since we don't want to spam dmesg with > clutter when the machine is dying already. > > Fix this by creating a __down_trylock which only trylocks the > semaphore.lock. This isn't correct in full generality, but good enough > for console_lock: > > - there's only ever one console_lock holder, we won't fail spuriously > because someone is doing a down() or up() while there's still room > (unlike other semaphores with count > 1). > > - console_unlock() has one massive retry loop, which will catch anyone > who races the trylock against the up(). This makes sure that no > printk lines will get lost. Making the trylock more racy therefore > has no further impact. To be honest, I do not see how this could solve the problem. The circular dependency is still there. If the new __down_trylock() succeeds then console_unlock() will get called in the same context and it will still need to call up() -> try_to_wake_up(). Note that there are many other console_lock() callers that might happen in parallel and might appear in the wait queue. Best Regards, Petr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110143] Doom 3: BFG Edition - Steam and GOG.com - white flickering screen
https://bugs.freedesktop.org/show_bug.cgi?id=110143 Timothy Arceri changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #6 from Timothy Arceri --- Should be fixed by: commit 1af72fa4d665b9847dff9b22d7a7dea01c0960c7 (HEAD -> master, origin/master, origin/HEAD) Author: Timothy Arceri Date: Fri May 3 13:59:05 2019 +1000 util/drirc: add workarounds for bugs in Doom 3: BFG This makes the game playable on radeonsi. Cc: "19.0" "19.1" Reviewed-by: Samuel Pitoiset Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110143 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/1] drm/fb-helper: Avoid race with DRM userspace
On Sun, May 05, 2019 at 11:16:54AM +0200, Noralf Trønnes wrote:
>
>
> Den 04.05.2019 14.34, skrev Noralf Trønnes:
> >
> >
> > Den 25.04.2019 10.31, skrev Noralf Trønnes:
> >> drm_fb_helper_is_bound() is used to check if DRM userspace is in control.
> >> This is done by looking at the fb on the primary plane. By the time
> >> fb-helper gets around to committing, it's possible that the facts have
> >> changed.
> >>
> >> Avoid this race by holding the drm_device->master_mutex lock while
> >> committing. When DRM userspace does its first open, it will now wait
> >> until fb-helper is done. The helper will stay away if there's a master.
> >>
> >> Locking rule: Always take the fb-helper lock first.
> >>
> >> v2:
> >> - Remove drm_fb_helper_is_bound() (Daniel Vetter)
> >> - No need to check fb_helper->dev->master in
> >> drm_fb_helper_single_fb_probe(), restore_fbdev_mode() has the check.
> >>
> >> Suggested-by: Daniel Vetter
> >> Signed-off-by: Noralf Trønnes
> >> Reviewed-by: Daniel Vetter
> >> ---
> >> drivers/gpu/drm/drm_auth.c | 20
> >> drivers/gpu/drm/drm_fb_helper.c | 90 -
> >> drivers/gpu/drm/drm_internal.h | 2 +
> >> 3 files changed, 67 insertions(+), 45 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> >> index 1669c42c40ed..db199807b7dc 100644
> >> --- a/drivers/gpu/drm/drm_auth.c
> >> +++ b/drivers/gpu/drm/drm_auth.c
> >> @@ -368,3 +368,23 @@ void drm_master_put(struct drm_master **master)
> >>*master = NULL;
> >> }
> >> EXPORT_SYMBOL(drm_master_put);
> >> +
> >> +/* Used by drm_client and drm_fb_helper */
> >> +bool drm_master_internal_acquire(struct drm_device *dev)
> >> +{
> >> + mutex_lock(&dev->master_mutex);
> >> + if (dev->master) {
> >> + mutex_unlock(&dev->master_mutex);
> >> + return false;
> >> + }
> >> +
> >> + return true;
> >> +}
> >> +EXPORT_SYMBOL(drm_master_internal_acquire);
> >> +
> >> +/* Used by drm_client and drm_fb_helper */
> >> +void drm_master_internal_release(struct drm_device *dev)
> >> +{
> >> + mutex_unlock(&dev->master_mutex);
> >> +}
> >> +EXPORT_SYMBOL(drm_master_internal_release);
> >> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >> b/drivers/gpu/drm/drm_fb_helper.c
> >> index 2339f0f8f5a8..578428461391 100644
> >> --- a/drivers/gpu/drm/drm_fb_helper.c
> >> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >> @@ -44,6 +44,7 @@
> >>
> >> #include "drm_crtc_internal.h"
> >> #include "drm_crtc_helper_internal.h"
> >> +#include "drm_internal.h"
> >>
> >> static bool drm_fbdev_emulation = true;
> >> module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
> >> @@ -509,7 +510,7 @@ static int restore_fbdev_mode_legacy(struct
> >> drm_fb_helper *fb_helper)
> >>return ret;
> >> }
> >>
> >> -static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
> >> +static int restore_fbdev_mode_force(struct drm_fb_helper *fb_helper)
> >> {
> >>struct drm_device *dev = fb_helper->dev;
> >>
> >> @@ -519,6 +520,21 @@ static int restore_fbdev_mode(struct drm_fb_helper
> >> *fb_helper)
> >>return restore_fbdev_mode_legacy(fb_helper);
> >> }
> >>
> >> +static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
> >> +{
> >> + struct drm_device *dev = fb_helper->dev;
> >> + int ret;
> >> +
> >> + if (!drm_master_internal_acquire(dev))
> >> + return -EBUSY;
> >> +
> >> + ret = restore_fbdev_mode_force(fb_helper);
> >> +
> >> + drm_master_internal_release(dev);
> >> +
> >> + return ret;
> >> +}
> >> +
> >> /**
> >> * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
> >> * @fb_helper: driver-allocated fbdev helper, can be NULL
> >
> > The Intel CI doesn't like this patch. AFAICT the reason is that the
> > igt@kms_fbcon_fbt@psr-suspend test expects fbcon to work while it has an
> > open fd that is master. This doesn't match the new rule of bailing out
> > if there's a master.
> >
> > Adding this debug output:
> >
> > @@ -558,6 +558,17 @@ int
> > drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
> > return 0;
> >
> > mutex_lock(&fb_helper->lock);
> > +if (READ_ONCE(fb_helper->dev->master)) {
> > + int level = default_message_loglevel;
> > +
> > + default_message_loglevel = LOGLEVEL_DEBUG;
> > + printk("\n");
> > + printk("\n");
> > + printk("%s\n", __func__);
> > + printk("THERE IS A MASTER\n");
> > + dump_stack();
> > + default_message_loglevel = level;
> > +}
> > ret = restore_fbdev_mode_force(fb_helper);
> >
> > do_delayed = fb_helper->delayed_hotplug;
> >
> > Gives these log entries:
> >
> > <7> [1857.940072] drm_fb_helper_restore_fbdev_mode_unlocked
> > <7> [1857.940074] THERE IS A MASTER
> > <7> [1857.940079] CPU: 4 PID: 8209 Comm: kms_fbcon_fbt Tainted: G U
> > 5.1.0-rc7-CI-Trybot_4252+ #1
> > <7> [1857.940081] Hardware name: Intel Corporation Ice Lake Client
> > Platform/Ic
Re: [PATCH 10/12] drm/amdgpu: add independent DMA-buf export v3
On Fri, May 03, 2019 at 02:35:02PM +0200, Christian König wrote:
> Am 30.04.19 um 16:16 schrieb Daniel Vetter:
> > [SNIP]
> > > /**
> > > - * amdgpu_gem_map_attach - &dma_buf_ops.attach implementation
> > > - * @dma_buf: Shared DMA buffer
> > > + * amdgpu_gem_pin_dma_buf - &dma_buf_ops.pin_dma_buf implementation
> > > + *
> > > + * @dma_buf: DMA-buf to pin in memory
> > > + *
> > > + * Pin the BO which is backing the DMA-buf so that it can't move any
> > > more.
> > > + */
> > > +static int amdgpu_gem_pin_dma_buf(struct dma_buf *dma_buf)
> > > +{
> > > + struct drm_gem_object *obj = dma_buf->priv;
> > > + struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> > > +
> > > + /* pin buffer into GTT */
> > > + return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
> > This is kinda what I mean with "shouldn't we pin the attachment" - afaiui
> > this can fail is someone already pinned the buffer into vram. And that
> > kind of checking is supposed to happen in the buffer attachment.
>
> Why is that supposed to happen on the attachment? I mean it could be nice to
> have for debugging, but I still don't see any practical reason for this.
dma_buf_attach is supposed to make sure the buffer won't land somewhere
where you can't get at it anymore. Wrt pin that means the exporter needs
to make sure it can't get pinned into a wrong place, and also isn't pinned
into a wrong place anymore. That's why I think pinning ties in with
dma_buf_attach and not the overall buffer.
In a way there's two pieces of a pin:
- Do not move the buffer anymore.
- Make sure I can still get at it.
Internally the 2nd part is encoded in the domain parameter you pass to
amdgpu_bo_pin. When going through dma-buf that information is derived
from the attachment (e.g. if it's a p2p one, then you can put it wherever
you feel like, if it's a normal one it must be in system ram). The dma-buf
alone doesn't tell you _where_ to pin something.
> > Also will p2p pin into VRAM if all attachments are p2p capable? Or is your
> > plan to require dynamic invalidate to avoid fragmenting vram badly with
> > pinned stuff you can't move?
>
> My plan was to make dynamic invalidation a must have for P2P, exactly for
> the reason you noted.
>
> > +/**
> > + * amdgpu_gem_dma_buf_attach - &dma_buf_ops.attach implementation
> > + *
> > + * @dma_buf: DMA-buf we attach to
> >* @attach: DMA-buf attachment
> >*
> > + * Returns:
> > + * Always zero for success.
> > + */
> > +static int amdgpu_gem_dma_buf_attach(struct dma_buf *dma_buf,
> > +struct dma_buf_attachment *attach)
> > +{
> > + struct drm_gem_object *obj = dma_buf->priv;
> > + struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> > +
> > + /* Make sure the buffer is pinned when userspace didn't set GTT as
> > +* preferred domain. This avoid ping/pong situations with scan out BOs.
> > +*/
> > + if (!(bo->preferred_domains & AMDGPU_GEM_DOMAIN_GTT))
> > + attach->invalidate = NULL;
> > Not following here at all. If the BO can't be in GTT I'd guess you should
> > reject the attach outright, since the pinning/map later on will fail I
> > guess? At least I'm not making the connection with why dynamic dma-buf
> > won't work anymore, since dynamic dma-buf is to make p2p of bo in vram
> > work better, which is exactly what this here seems to check for.
> >
> > Or is this just a quick check until you add full p2p support?
> >
> > Count me confused ...
>
> Well completely amdgpu internal handling here. Key point is we have both
> preferred_domains as well as allowed_domains.
>
> During command submission we always try to move a BO to the
> preferred_domains again.
>
> Now what could happen if we don't have this check is the following:
>
> 1. BO is allocate in VRAM. And preferred_domains says only VRAM please, but
> allowed_domains says VRAM or GTT.
>
> 2. DMA-buf Importer comes along and moves the BO to GTT, which is perfectly
> valid because of the allowed_domains.
>
> 3. Command submission is made and moves the BO to VRAM again.
>
> 4. Importer comes along and moves the BO to GTT.
>
>
> E.g. a nice ping/pong situation which just eats up memory bandwidth.
Hm yeah the ping/pong is bad, but I figure you have to already handle that
(with some bias or whatever). Outright disabling invalidate/dynamic
dma-buf seems like overkill.
What about upgradging preferred_domains to include GTT here? Defacto what
you do is forcing GTT, so just adding GTT as a possible domain seems like
the better choice. Bonus points for undoing that when the last importer
disappears.
In general I think dynamic dma-buf needs to be able to handle this
somehow, or it won't really work. Simplest is probably to just stop moving
buffers around so much for buffers that are dynamically exported (so maybe
could also change that in the CS ioctl to not move exported buffers
anymore, would achieve the same).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
[Bug 109345] drm-next-2018-12-14 -Linux PPC
https://bugs.freedesktop.org/show_bug.cgi?id=109345 --- Comment #32 from Christian Zigotzky --- Hi All, Allan successfully tested the sixth test kernel today. He wrote: Christian DRM6 boots to Firepro. cheers ace -- This step has been marked as good because the sixth test kernel boots to FirePro. Next step: git bisect good Output: Bisecting: 11 revisions left to test after this (roughly 4 steps) [068f304781804e208f901d8f6083189e0e28c420] drm/drm_pci.c: Use dma_zalloc_coherent make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage Download: http://www.xenosoft.de/uImage-drm7 @Allan (acefnq/ace) Please test it. Thanks, Christian -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: use-after-free Read in add_uevent_var
On Sat, May 04, 2019 at 11:16:05AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:a4ccb5f9 Merge tag 'drm-fixes-2019-05-03' of git://anongit..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1205d570a0
> kernel config: https://syzkaller.appspot.com/x/.config?x=2bd0da4b8de0b004
> dashboard link: https://syzkaller.appspot.com/bug?extid=6da9575ba2db4da91831
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> userspace arch: i386
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1769f62ca0
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=167ae984a0
>
> The bug was bisected to:
>
> commit 0a1c7959acd9674a0e4e59f911f3e5fbf25fd693
> Author: Wolfram Sang
> Date: Wed May 17 15:22:18 2017 +
>
> gpu: drm: tc35876x: move header file out of I2C realm
Bisect seems to have gone off the rails. No idea where or why.
-Daniel
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=138fe12ca0
> final crash:https://syzkaller.appspot.com/x/report.txt?x=104fe12ca0
> console output: https://syzkaller.appspot.com/x/log.txt?x=178fe12ca0
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6da9575ba2db4da91...@syzkaller.appspotmail.com
> Fixes: 0a1c7959acd9 ("gpu: drm: tc35876x: move header file out of I2C
> realm")
>
> RAX: ffda RBX: 0003 RCX: 5502
> RDX: RSI: 080daf20 RDI: 080f0f84
> RBP: R08: R09:
> R10: R11: R12:
> R13: R14: R15:
> ==
> BUG: KASAN: use-after-free in string+0x208/0x230 lib/vsprintf.c:606
> Read of size 1 at addr 8880a55aa200 by task syz-executor222/7839
>
> CPU: 1 PID: 7839 Comm: syz-executor222 Not tainted 5.1.0-rc7+ #98
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> __asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:129
> string+0x208/0x230 lib/vsprintf.c:606
> vsnprintf+0xbfc/0x1af0 lib/vsprintf.c:2396
> add_uevent_var+0x14d/0x310 lib/kobject_uevent.c:661
> input_dev_uevent+0x163/0x890 drivers/input/input.c:1594
> dev_uevent+0x312/0x580 drivers/base/core.c:1180
> kobject_uevent_env+0x487/0x1030 lib/kobject_uevent.c:549
> kobject_uevent+0x20/0x26 lib/kobject_uevent.c:638
> kobject_cleanup lib/kobject.c:649 [inline]
> kobject_release lib/kobject.c:691 [inline]
> kref_put include/linux/kref.h:67 [inline]
> kobject_put.cold+0x177/0x2ec lib/kobject.c:708
> put_device+0x20/0x30 drivers/base/core.c:2205
> input_put_device include/linux/input.h:349 [inline]
> evdev_free+0x51/0x70 drivers/input/evdev.c:369
> device_release+0x7d/0x210 drivers/base/core.c:1064
> kobject_cleanup lib/kobject.c:662 [inline]
> kobject_release lib/kobject.c:691 [inline]
> kref_put include/linux/kref.h:67 [inline]
> kobject_put.cold+0x28f/0x2ec lib/kobject.c:708
> cdev_default_release+0x41/0x50 fs/char_dev.c:607
> kobject_cleanup lib/kobject.c:662 [inline]
> kobject_release lib/kobject.c:691 [inline]
> kref_put include/linux/kref.h:67 [inline]
> kobject_put.cold+0x28f/0x2ec lib/kobject.c:708
> cdev_put.part.0+0x39/0x50 fs/char_dev.c:368
> cdev_put+0x20/0x30 fs/char_dev.c:366
> __fput+0x6df/0x8d0 fs/file_table.c:281
> fput+0x16/0x20 fs/file_table.c:309
> task_work_run+0x14a/0x1c0 kernel/task_work.c:113
> exit_task_work include/linux/task_work.h:22 [inline]
> do_exit+0x90a/0x2fa0 kernel/exit.c:876
> do_group_exit+0x135/0x370 kernel/exit.c:980
> __do_sys_exit_group kernel/exit.c:991 [inline]
> __se_sys_exit_group kernel/exit.c:989 [inline]
> __ia32_sys_exit_group+0x44/0x50 kernel/exit.c:989
> do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
> do_fast_syscall_32+0x281/0xc98 arch/x86/entry/common.c:397
> entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
> RIP: 0023:0xf7ff7849
> Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90 90
> 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90
> 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
> RSP: 002b:fff2db8c EFLAGS: 0292 ORIG_RAX: 00fc
> RAX: ffda RBX: RCX: 080f1298
> RDX: RSI: 080daf1c RDI: 080f12a0
> RBP: 0001 R08: R09:
> R10: R11: R12:
> R13: R14: R15:
>
> Alloc
Re: [PATCH] drm: Fix drm.h uapi header for GNU/kFreeBSD
On Sat, May 04, 2019 at 09:43:14PM +0100, James Clarke wrote: > On 15 Jan 2019, at 18:41, Eric Anholt wrote: > > > > Daniel Vetter writes: > > > >> On Tue, Jan 15, 2019 at 03:04:18PM +, James Clarke wrote: > >>> Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t > >>> types, which differs from the BSDs' headers. Thus we should include > >>> stdint.h to ensure we have all the required integer types. > >>> > >>> Signed-off-by: James Clarke > >> > >> Would be good to get an ack from some other *bsd that this is still all > >> fine. lgtm otherwise. > >> -Daniel > > > > I think there was some need for inttypes.h instead of stdint like a > > decade ago when I was working on BSDs, but that was already almost > > irrelevant then. > > Hi, just following up on this; is there still the need for an ACK? Yeah and ack without a "decades ago" qualifier would be nice. -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 v4 11/19] drm/bochs: Convert bochs driver to |struct drm_gem_vram_object|
The data structure |struct drm_gem_vram_object| and its helpers replace
|struct bochs_bo|. It's the same implementation; except for the type
names.
v4:
* cleanups from checkpatch.pl
* select config option DRM_VRAM_HELPER
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/bochs/Kconfig | 1 +
drivers/gpu/drm/bochs/bochs.h | 34 +---
drivers/gpu/drm/bochs/bochs_drv.c | 5 +-
drivers/gpu/drm/bochs/bochs_kms.c | 18 +-
drivers/gpu/drm/bochs/bochs_mm.c | 270 +++---
5 files changed, 35 insertions(+), 293 deletions(-)
diff --git a/drivers/gpu/drm/bochs/Kconfig b/drivers/gpu/drm/bochs/Kconfig
index bd2718015cdb..4cbcff9e2eb8 100644
--- a/drivers/gpu/drm/bochs/Kconfig
+++ b/drivers/gpu/drm/bochs/Kconfig
@@ -3,6 +3,7 @@ config DRM_BOCHS
depends on DRM && PCI && MMU
select DRM_KMS_HELPER
select DRM_TTM
+ select DRM_VRAM_HELPER
help
Choose this option for qemu.
If M is selected the module will be called bochs-drm.
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index 341cc9d1bab4..4ccf82e1ca68 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include
@@ -81,30 +82,6 @@ struct bochs_device {
} ttm;
};
-struct bochs_bo {
- struct ttm_buffer_object bo;
- struct ttm_placement placement;
- struct ttm_bo_kmap_obj kmap;
- struct drm_gem_object gem;
- struct ttm_place placements[3];
- int pin_count;
-};
-
-static inline struct bochs_bo *bochs_bo(struct ttm_buffer_object *bo)
-{
- return container_of(bo, struct bochs_bo, bo);
-}
-
-static inline struct bochs_bo *gem_to_bochs_bo(struct drm_gem_object *gem)
-{
- return container_of(gem, struct bochs_bo, gem);
-}
-
-static inline u64 bochs_bo_mmap_offset(struct bochs_bo *bo)
-{
- return drm_vma_node_offset_addr(&bo->bo.vma_node);
-}
-
/* -- */
/* bochs_hw.c */
@@ -124,17 +101,8 @@ int bochs_mm_init(struct bochs_device *bochs);
void bochs_mm_fini(struct bochs_device *bochs);
int bochs_mmap(struct file *filp, struct vm_area_struct *vma);
-int bochs_gem_create(struct drm_device *dev, u32 size, bool iskernel,
-struct drm_gem_object **obj);
-int bochs_gem_init_object(struct drm_gem_object *obj);
-void bochs_gem_free_object(struct drm_gem_object *obj);
int bochs_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
-int bochs_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev,
- uint32_t handle, uint64_t *offset);
-
-int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag);
-int bochs_bo_unpin(struct bochs_bo *bo);
int bochs_gem_prime_pin(struct drm_gem_object *obj);
void bochs_gem_prime_unpin(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index 6b6e037258c3..04fed41d6c00 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -82,9 +82,10 @@ static struct drm_driver bochs_driver = {
.date = "20130925",
.major = 1,
.minor = 0,
- .gem_free_object_unlocked = bochs_gem_free_object,
+ .gem_free_object_unlocked =
+ drm_gem_vram_driver_gem_free_object_unlocked,
.dumb_create= bochs_dumb_create,
- .dumb_map_offset= bochs_dumb_mmap_offset,
+ .dumb_map_offset= drm_gem_vram_driver_dumb_mmap_offset,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 5e905f50449d..9e3ee7b511fb 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -30,16 +30,16 @@ static const uint32_t bochs_formats[] = {
static void bochs_plane_update(struct bochs_device *bochs,
struct drm_plane_state *state)
{
- struct bochs_bo *bo;
+ struct drm_gem_vram_object *gbo;
if (!state->fb || !bochs->stride)
return;
- bo = gem_to_bochs_bo(state->fb->obj[0]);
+ gbo = drm_gem_vram_of_gem(state->fb->obj[0]);
bochs_hw_setbase(bochs,
state->crtc_x,
state->crtc_y,
-bo->bo.offset);
+gbo->bo.offset);
bochs_hw_setformat(bochs, state->fb->format);
}
@@ -72,23 +72,23 @@ static void bochs_pipe_update(struct
drm_simple_display_pipe *pipe,
static int bochs_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *new_state)
{
- struct bochs_bo *bo;
+ struct drm_gem_vram_ob
[PATCH v4 08/19] drm/ast: Convert AST driver to |struct drm_gem_vram_object|
The data structure |struct drm_gem_vram_object| and its helpers replace
|struct ast_bo|. It's the same implementation; except for the type names.
v4:
* cleanups from checkpatch.pl
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/Kconfig| 2 +-
drivers/gpu/drm/ast/ast_drv.c | 5 +-
drivers/gpu/drm/ast/ast_drv.h | 52 +-
drivers/gpu/drm/ast/ast_fb.c | 23 +++--
drivers/gpu/drm/ast/ast_main.c | 74 ++
drivers/gpu/drm/ast/ast_mode.c | 78 +--
drivers/gpu/drm/ast/ast_ttm.c | 172 +
7 files changed, 75 insertions(+), 331 deletions(-)
diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig
index 9647e1f07088..f3737488630b 100644
--- a/drivers/gpu/drm/ast/Kconfig
+++ b/drivers/gpu/drm/ast/Kconfig
@@ -3,7 +3,7 @@ config DRM_AST
depends on DRM && PCI && MMU
select DRM_TTM
select DRM_KMS_HELPER
- select DRM_TTM
+ select DRM_VRAM_HELPER
help
Say yes for experimental AST GPU driver. Do not enable
this driver without having a working -modesetting,
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 3871b39d4dea..7012b17b984f 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -228,9 +228,10 @@ static struct drm_driver driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
- .gem_free_object_unlocked = ast_gem_free_object,
+ .gem_free_object_unlocked =
+ drm_gem_vram_driver_gem_free_object_unlocked,
.dumb_create = ast_dumb_create,
- .dumb_map_offset = ast_dumb_mmap_offset,
+ .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset,
};
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 1cf0c75e411d..712838f725dc 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -38,6 +38,7 @@
#include
#include
+#include
#include
#include
@@ -321,25 +322,6 @@ void ast_fbdev_fini(struct drm_device *dev);
void ast_fbdev_set_suspend(struct drm_device *dev, int state);
void ast_fbdev_set_base(struct ast_private *ast, unsigned long gpu_addr);
-struct ast_bo {
- struct ttm_buffer_object bo;
- struct ttm_placement placement;
- struct ttm_bo_kmap_obj kmap;
- struct drm_gem_object gem;
- struct ttm_place placements[3];
- int pin_count;
-};
-#define gem_to_ast_bo(gobj) container_of((gobj), struct ast_bo, gem)
-
-static inline struct ast_bo *
-ast_bo(struct ttm_buffer_object *bo)
-{
- return container_of(bo, struct ast_bo, bo);
-}
-
-
-#define to_ast_obj(x) container_of(x, struct ast_gem_object, base)
-
#define AST_MM_ALIGN_SHIFT 4
#define AST_MM_ALIGN_MASK ((1 << AST_MM_ALIGN_SHIFT) - 1)
@@ -347,45 +329,13 @@ extern int ast_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-extern void ast_gem_free_object(struct drm_gem_object *obj);
-extern int ast_dumb_mmap_offset(struct drm_file *file,
- struct drm_device *dev,
- uint32_t handle,
- uint64_t *offset);
-
int ast_mm_init(struct ast_private *ast);
void ast_mm_fini(struct ast_private *ast);
-int ast_bo_create(struct drm_device *dev, int size, int align,
- uint32_t flags, struct ast_bo **pastbo);
-
int ast_gem_create(struct drm_device *dev,
u32 size, bool iskernel,
struct drm_gem_object **obj);
-int ast_bo_pin(struct ast_bo *bo, u32 pl_flag, u64 *gpu_addr);
-int ast_bo_unpin(struct ast_bo *bo);
-
-static inline int ast_bo_reserve(struct ast_bo *bo, bool no_wait)
-{
- int ret;
-
- ret = ttm_bo_reserve(&bo->bo, true, no_wait, NULL);
- if (ret) {
- if (ret != -ERESTARTSYS && ret != -EBUSY)
- DRM_ERROR("reserve failed %p\n", bo);
- return ret;
- }
- return 0;
-}
-
-static inline void ast_bo_unreserve(struct ast_bo *bo)
-{
- ttm_bo_unreserve(&bo->bo);
-}
-
-void ast_ttm_placement(struct ast_bo *bo, int domain);
-int ast_bo_push_sysram(struct ast_bo *bo);
int ast_mmap(struct file *filp, struct vm_area_struct *vma);
/* ast post */
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index e718d0f60d6b..778423fcf352 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -49,7 +49,7 @@ static void ast_dirty_update(struct ast_fbdev *afbdev,
{
int i;
struct drm_gem_object *obj;
- struct ast_bo *bo;
+ struct drm_gem_vram_object *gbo;
int src_offset, dst_offset;
int bpp = afbdev->afb.base.format->cpp[0];
int ret = -EBUSY;
@@ -59,7 +59,7 @@ static void ast_dirty_update(struct ast_fbdev *afbdev,
unsigned long flags;
obj = afbdev->afb
[PATCH v4 19/19] drm/hisilicon: Convert hibmc-drm driver to VRAM MM
The data structure |struct drm_vram_mm| and its helpers replace hibmc's
TTM-based memory manager. It's the same implementation; except for the
type names.
v4:
* don't select DRM_TTM or DRM_VRAM_MM_HELPER
v3:
* use drm_gem_vram_mm_funcs
* convert driver to drm_device-based instance
v2:
* implement hibmc_mmap() with drm_vram_mm_mmap()
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/Kconfig | 1 -
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 8 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 8 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 139 ++
4 files changed, 12 insertions(+), 144 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig
b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
index 04d0bc685560..c36ec03f3d92 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig
+++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
@@ -2,7 +2,6 @@ config DRM_HISI_HIBMC
tristate "DRM Support for Hisilicon Hibmc"
depends on DRM && PCI && MMU
select DRM_KMS_HELPER
- select DRM_TTM
select DRM_VRAM_HELPER
help
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 7027a1a05768..7243603de261 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -27,14 +27,8 @@
static const struct file_operations hibmc_fops = {
.owner = THIS_MODULE,
- .open = drm_open,
- .release= drm_release,
- .unlocked_ioctl = drm_ioctl,
- .compat_ioctl = drm_compat_ioctl,
- .mmap = hibmc_mmap,
- .poll = drm_poll,
- .read = drm_read,
.llseek = no_llseek,
+ DRM_VRAM_MM_FILE_OPERATIONS
};
static irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 6b3430fc5148..3967693ecbdc 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -24,7 +24,7 @@
#include
#include
#include
-#include
+#include
struct hibmc_framebuffer {
struct drm_framebuffer fb;
@@ -49,13 +49,8 @@ struct hibmc_drm_private {
struct drm_device *dev;
bool mode_config_initialized;
- /* ttm */
- struct ttm_bo_device bdev;
- bool initialized;
-
/* fbdev */
struct hibmc_fbdev *fbdev;
- bool mm_inited;
};
#define to_hibmc_framebuffer(x) container_of(x, struct hibmc_framebuffer, fb)
@@ -81,7 +76,6 @@ int hibmc_mm_init(struct hibmc_drm_private *hibmc);
void hibmc_mm_fini(struct hibmc_drm_private *hibmc);
int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
-int hibmc_mmap(struct file *filp, struct vm_area_struct *vma);
extern const struct drm_mode_config_funcs hibmc_mode_funcs;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index fbf8eb048ebc..52fba8cb8ddd 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -17,157 +17,38 @@
*/
#include
-#include
#include "hibmc_drm_drv.h"
-static inline struct hibmc_drm_private *
-hibmc_bdev(struct ttm_bo_device *bd)
-{
- return container_of(bd, struct hibmc_drm_private, bdev);
-}
-
-static int
-hibmc_bo_init_mem_type(struct ttm_bo_device *bdev, u32 type,
- struct ttm_mem_type_manager *man)
-{
- switch (type) {
- case TTM_PL_SYSTEM:
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
- break;
- case TTM_PL_VRAM:
- man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED |
- TTM_MEMTYPE_FLAG_MAPPABLE;
- man->available_caching = TTM_PL_FLAG_UNCACHED |
- TTM_PL_FLAG_WC;
- man->default_caching = TTM_PL_FLAG_WC;
- break;
- default:
- DRM_ERROR("unsupported memory type %u\n", type);
- return -EINVAL;
- }
- return 0;
-}
-
-static int hibmc_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
- struct ttm_mem_reg *mem)
-{
- struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
- struct hibmc_drm_private *hibmc = hibmc_bdev(bdev);
-
- mem->bus.addr = NULL;
- mem->bus.offset = 0;
- mem->bus.size = mem->num_pages << PAGE_SHIFT;
- mem->bus.base = 0;
- mem->bus.is_iomem = false;
- if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
- return -EINVAL;
- switch (mem->mem_typ
[PATCH v4 03/19] drm: Add |struct drm_gem_vram_object| callbacks for |struct drm_driver|
The provided helpers can be used for the respective callback functions
in |struct drm_driver|.
v4:
* cleanups from checkpatch.pl
v2:
* documentation fixes
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 49 +++
include/drm/drm_gem_vram_helper.h | 10 ++
2 files changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index e929a18c03f3..41f971908b78 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -460,3 +460,52 @@ int drm_gem_vram_bo_driver_verify_access(struct
ttm_buffer_object *bo,
filp->private_data);
}
EXPORT_SYMBOL(drm_gem_vram_bo_driver_verify_access);
+
+/*
+ * Helpers for struct drm_driver
+ */
+
+/**
+ * drm_gem_vram_driver_gem_free_object_unlocked() - \
+ Implements &struct drm_driver.gem_free_object_unlocked
+ * @gem: GEM object. Refers to &struct drm_gem_vram_object.gem
+ */
+void drm_gem_vram_driver_gem_free_object_unlocked(struct drm_gem_object *gem)
+{
+ struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
+
+ drm_gem_vram_put(gbo);
+}
+EXPORT_SYMBOL(drm_gem_vram_driver_gem_free_object_unlocked);
+
+/**
+ * drm_gem_vram_driver_dumb_mmap_offset() - \
+ Implements &struct drm_driver.dumb_mmap_offset
+ * @file: DRM file pointer.
+ * @dev: DRM device.
+ * @handle:GEM handle
+ * @offset:Returns the mapping's memory offset on success
+ *
+ * Returns:
+ * 0 on success, or
+ * a negative errno code otherwise.
+ */
+int drm_gem_vram_driver_dumb_mmap_offset(struct drm_file *file,
+struct drm_device *dev,
+uint32_t handle, uint64_t *offset)
+{
+ struct drm_gem_object *gem;
+ struct drm_gem_vram_object *gbo;
+
+ gem = drm_gem_object_lookup(file, handle);
+ if (!gem)
+ return -ENOENT;
+
+ gbo = drm_gem_vram_of_gem(gem);
+ *offset = drm_gem_vram_mmap_offset(gbo);
+
+ drm_gem_object_put_unlocked(gem);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_gem_vram_driver_dumb_mmap_offset);
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index f92e0f531a68..d6a75d860f4e 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -99,4 +99,14 @@ void drm_gem_vram_bo_driver_evict_flags(struct
ttm_buffer_object *bo,
int drm_gem_vram_bo_driver_verify_access(struct ttm_buffer_object *bo,
struct file *filp);
+/*
+ * Helpers for struct drm_driver
+ */
+
+void drm_gem_vram_driver_gem_free_object_unlocked(struct drm_gem_object *gem);
+
+int drm_gem_vram_driver_dumb_mmap_offset(struct drm_file *file,
+struct drm_device *dev,
+uint32_t handle, uint64_t *offset);
+
#endif
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 16/19] drm/vboxvideo: Convert vboxvideo driver to |struct drm_gem_vram_object|
This patch replaces |struct vbox_bo| and its helpers with the generic
implementation of |struct drm_gem_vram_object|. The only change in
semantics is that &ttm_bo_driver.verify_access() now does the actual
verification.
v4:
* select config option DRM_VRAM_HELPER
v3:
* remove forward declaration of struct vbox_gem_object
v2:
nothing
Signed-off-by: Thomas Zimmermann
Reviewed-by: Hans de Goede
---
drivers/gpu/drm/vboxvideo/Kconfig | 1 +
drivers/gpu/drm/vboxvideo/vbox_drv.c | 5 +-
drivers/gpu/drm/vboxvideo/vbox_drv.h | 60 +--
drivers/gpu/drm/vboxvideo/vbox_fb.c | 22 +--
drivers/gpu/drm/vboxvideo/vbox_main.c | 70 +---
drivers/gpu/drm/vboxvideo/vbox_mode.c | 36 +++--
drivers/gpu/drm/vboxvideo/vbox_ttm.c | 223 +-
7 files changed, 45 insertions(+), 372 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/Kconfig
b/drivers/gpu/drm/vboxvideo/Kconfig
index 1f4182e2e980..f8f689c55e94 100644
--- a/drivers/gpu/drm/vboxvideo/Kconfig
+++ b/drivers/gpu/drm/vboxvideo/Kconfig
@@ -3,6 +3,7 @@ config DRM_VBOXVIDEO
depends on DRM && X86 && PCI
select DRM_KMS_HELPER
select DRM_TTM
+ select DRM_VRAM_HELPER
select GENERIC_ALLOCATOR
help
This is a KMS driver for the virtual Graphics Card used in
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index fb6a0f0b8167..336a8e03e151 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -215,9 +215,10 @@ static struct drm_driver driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
- .gem_free_object_unlocked = vbox_gem_free_object,
+ .gem_free_object_unlocked =
+ drm_gem_vram_driver_gem_free_object_unlocked,
.dumb_create = vbox_dumb_create,
- .dumb_map_offset = vbox_dumb_mmap_offset,
+ .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h
b/drivers/gpu/drm/vboxvideo/vbox_drv.h
index ece31f395540..12e47392b2f9 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -96,8 +97,6 @@ struct vbox_private {
#undef CURSOR_PIXEL_COUNT
#undef CURSOR_DATA_SIZE
-struct vbox_gem_object;
-
struct vbox_connector {
struct drm_connector base;
char name[32];
@@ -170,73 +169,16 @@ int vboxfb_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes);
void vbox_fbdev_fini(struct vbox_private *vbox);
-struct vbox_bo {
- struct ttm_buffer_object bo;
- struct ttm_placement placement;
- struct ttm_bo_kmap_obj kmap;
- struct drm_gem_object gem;
- struct ttm_place placements[3];
- int pin_count;
-};
-
-#define gem_to_vbox_bo(gobj) container_of((gobj), struct vbox_bo, gem)
-
-static inline struct vbox_bo *vbox_bo(struct ttm_buffer_object *bo)
-{
- return container_of(bo, struct vbox_bo, bo);
-}
-
-#define to_vbox_obj(x) container_of(x, struct vbox_gem_object, base)
-
-static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo)
-{
- return bo->bo.offset;
-}
-
int vbox_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-void vbox_gem_free_object(struct drm_gem_object *obj);
-int vbox_dumb_mmap_offset(struct drm_file *file,
- struct drm_device *dev,
- u32 handle, u64 *offset);
-
int vbox_mm_init(struct vbox_private *vbox);
void vbox_mm_fini(struct vbox_private *vbox);
-int vbox_bo_create(struct vbox_private *vbox, int size, int align,
- u32 flags, struct vbox_bo **pvboxbo);
-
int vbox_gem_create(struct vbox_private *vbox,
u32 size, bool iskernel, struct drm_gem_object **obj);
-
-int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag);
-int vbox_bo_unpin(struct vbox_bo *bo);
-
-static inline int vbox_bo_reserve(struct vbox_bo *bo, bool no_wait)
-{
- int ret;
-
- ret = ttm_bo_reserve(&bo->bo, true, no_wait, NULL);
- if (ret) {
- if (ret != -ERESTARTSYS && ret != -EBUSY)
- DRM_ERROR("reserve failed %p\n", bo);
- return ret;
- }
- return 0;
-}
-
-static inline void vbox_bo_unreserve(struct vbox_bo *bo)
-{
- ttm_bo_unreserve(&bo->bo);
-}
-
-void vbox_ttm_placement(struct vbox_bo *bo, int domain);
-int vbox_bo_push_sysram(struct vbox_bo *bo);
int vbox_mmap(struct file *filp, struct vm_area_struct *vma);
-void *vbox_bo_kmap(struct vbox_bo *bo);
-void vbox_bo_kunmap(struct vbox_bo *bo);
/* vbox_prime.c */
int vbox_gem_prime_pin
[PATCH v4 15/19] drm/mgag200: Replace mapping code with drm_gem_vram_{kmap/kunmap}()
The mgag200 driver establishes several memory mappings for frame buffers
and cursors. This patch converts the driver to use the equivalent
drm_gem_vram_kmap() functions. It removes the dependencies on TTM
and cleans up the code.
v4:
* cleanups from checkpatch.pl
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 35 +++-
drivers/gpu/drm/mgag200/mgag200_drv.h| 1 -
drivers/gpu/drm/mgag200/mgag200_fb.c | 24 ++--
drivers/gpu/drm/mgag200/mgag200_mode.c | 9 --
4 files changed, 37 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index cca3922f9f67..6c1a9d724d85 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -43,6 +43,7 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
struct drm_gem_object *obj;
struct drm_gem_vram_object *gbo = NULL;
int ret = 0;
+ u8 *src, *dst;
unsigned int i, row, col;
uint32_t colour_set[16];
uint32_t *next_space = &colour_set[0];
@@ -126,18 +127,17 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
dev_err(&dev->pdev->dev, "failed to reserve user bo\n");
goto out1;
}
- if (!gbo->kmap.virtual) {
- ret = ttm_bo_kmap(&gbo->bo, 0, gbo->bo.num_pages, &gbo->kmap);
- if (ret) {
- dev_err(&dev->pdev->dev, "failed to kmap user buffer
updates\n");
- goto out2;
- }
+ src = drm_gem_vram_kmap(gbo, true, NULL);
+ if (IS_ERR(src)) {
+ ret = PTR_ERR(src);
+ dev_err(&dev->pdev->dev, "failed to kmap user buffer
updates\n");
+ goto out2;
}
memset(&colour_set[0], 0, sizeof(uint32_t)*16);
/* width*height*4 = 16384 */
for (i = 0; i < 16384; i += 4) {
- this_colour = ioread32(gbo->kmap.virtual + i);
+ this_colour = ioread32(src + i);
/* No transparency */
if (this_colour>>24 != 0xff &&
this_colour>>24 != 0x0) {
@@ -189,21 +189,18 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
}
/* Map up-coming buffer to write colour indices */
- if (!pixels_prev->kmap.virtual) {
- ret = ttm_bo_kmap(&pixels_prev->bo, 0,
- pixels_prev->bo.num_pages,
- &pixels_prev->kmap);
- if (ret) {
- dev_err(&dev->pdev->dev, "failed to kmap cursor
updates\n");
- goto out3;
- }
+ dst = drm_gem_vram_kmap(pixels_prev, true, NULL);
+ if (IS_ERR(dst)) {
+ ret = PTR_ERR(dst);
+ dev_err(&dev->pdev->dev, "failed to kmap cursor updates\n");
+ goto out3;
}
/* now write colour indices into hardware cursor buffer */
for (row = 0; row < 64; row++) {
memset(&this_row[0], 0, 48);
for (col = 0; col < 64; col++) {
- this_colour = ioread32(gbo->kmap.virtual + 4*(col +
64*row));
+ this_colour = ioread32(src + 4*(col + 64*row));
/* write transparent pixels */
if (this_colour>>24 == 0x0) {
this_row[47 - col/8] |= 0x80>>(col%8);
@@ -221,7 +218,7 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
}
}
}
- memcpy_toio(pixels_prev->kmap.virtual + row*48, &this_row[0],
48);
+ memcpy_toio(dst + row*48, &this_row[0], 48);
}
/* Program gpu address of cursor buffer */
@@ -247,9 +244,9 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
}
ret = 0;
- ttm_bo_kunmap(&pixels_prev->kmap);
+ drm_gem_vram_kunmap(pixels_prev);
out3:
- ttm_bo_kunmap(&gbo->kmap);
+ drm_gem_vram_kunmap(gbo);
out2:
drm_gem_vram_unreserve(gbo);
out1:
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 16ce6b338dce..6180acbca7ca 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -115,7 +115,6 @@ struct mga_fbdev {
struct mga_framebuffer mfb;
void *sysram;
int size;
- struct ttm_bo_kmap_obj mapping;
int x1, y1, x2, y2; /* dirty rect */
spinlock_t dirty_lock;
};
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index 1bcf0d65868d..87217bdce9f8 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -27,6 +27,7 @@ static void mga_dirty_update(struct mga_fbdev *mfbdev,
int src_offset, dst_offset;
int bpp = mfbdev->mfb.base.fo
[PATCH v4 06/19] drm: Add default instance for VRAM MM callback functions
VRAM MM is most likely be used with GEM VRAM. The latter now provides the
required instance of struct drm_vram_mm_funcs for drivers to use.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 14 ++
include/drm/drm_gem_vram_helper.h | 3 +++
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 461ed20b779b..33321291475a 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -2,6 +2,7 @@
#include
#include
+#include
#include
/**
@@ -523,6 +524,19 @@ int drm_gem_vram_bo_driver_verify_access(struct
ttm_buffer_object *bo,
}
EXPORT_SYMBOL(drm_gem_vram_bo_driver_verify_access);
+/**
+ * drm_gem_vram_mm_funcs - Functions for &struct drm_vram_mm
+ *
+ * Most users of @struct drm_gem_vram_object will also use
+ * @struct drm_vram_mm. This instance of &struct drm_vram_mm_funcs
+ * can be used to connect both.
+ */
+const struct drm_vram_mm_funcs drm_gem_vram_mm_funcs = {
+ .evict_flags = drm_gem_vram_bo_driver_evict_flags,
+ .verify_access = drm_gem_vram_bo_driver_verify_access
+};
+EXPORT_SYMBOL(drm_gem_vram_mm_funcs);
+
/*
* Helpers for struct drm_driver
*/
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 68edb28d4508..f09f1594b4f8 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -9,6 +9,7 @@
#include /* for container_of() */
struct drm_mode_create_dumb;
+struct drm_vram_mm_funcs;
struct filp;
#define DRM_GEM_VRAM_PL_FLAG_VRAM TTM_PL_FLAG_VRAM
@@ -107,6 +108,8 @@ void drm_gem_vram_bo_driver_evict_flags(struct
ttm_buffer_object *bo,
int drm_gem_vram_bo_driver_verify_access(struct ttm_buffer_object *bo,
struct file *filp);
+extern const struct drm_vram_mm_funcs drm_gem_vram_mm_funcs;
+
/*
* Helpers for struct drm_driver
*/
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 12/19] drm/bochs: Convert bochs driver to VRAM MM
The data structure |struct drm_vram_mm| and its helpers replace bochs'
TTM-based memory manager. It's the same implementation; except for the
type names.
v4:
* don't select DRM_TTM or DRM_VRAM_MM_HELPER
v3:
* use drm_gem_vram_mm_funcs
* convert driver to drm_device-based instance
v2:
* implement bochs_mmap() with drm_vram_mm_mmap()
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/bochs/Kconfig | 1 -
drivers/gpu/drm/bochs/bochs.h | 13 +--
drivers/gpu/drm/bochs/bochs_drv.c | 14 +--
drivers/gpu/drm/bochs/bochs_mm.c | 148 ++
4 files changed, 12 insertions(+), 164 deletions(-)
diff --git a/drivers/gpu/drm/bochs/Kconfig b/drivers/gpu/drm/bochs/Kconfig
index 4cbcff9e2eb8..e1f6ae9dd042 100644
--- a/drivers/gpu/drm/bochs/Kconfig
+++ b/drivers/gpu/drm/bochs/Kconfig
@@ -2,7 +2,6 @@ config DRM_BOCHS
tristate "DRM Support for bochs dispi vga interface (qemu stdvga)"
depends on DRM && PCI && MMU
select DRM_KMS_HELPER
- select DRM_TTM
select DRM_VRAM_HELPER
help
Choose this option for qemu.
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index 4ccf82e1ca68..323dcca256a3 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -12,8 +12,7 @@
#include
#include
-#include
-#include
+#include
/* -- */
@@ -74,12 +73,6 @@ struct bochs_device {
struct drm_device *dev;
struct drm_simple_display_pipe pipe;
struct drm_connector connector;
-
- /* ttm */
- struct {
- struct ttm_bo_device bdev;
- bool initialized;
- } ttm;
};
/* -- */
@@ -99,10 +92,6 @@ int bochs_hw_load_edid(struct bochs_device *bochs);
/* bochs_mm.c */
int bochs_mm_init(struct bochs_device *bochs);
void bochs_mm_fini(struct bochs_device *bochs);
-int bochs_mmap(struct file *filp, struct vm_area_struct *vma);
-
-int bochs_dumb_create(struct drm_file *file, struct drm_device *dev,
- struct drm_mode_create_dumb *args);
int bochs_gem_prime_pin(struct drm_gem_object *obj);
void bochs_gem_prime_unpin(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index 04fed41d6c00..f3bb5fba30bf 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -63,14 +63,8 @@ static int bochs_load(struct drm_device *dev)
static const struct file_operations bochs_fops = {
.owner = THIS_MODULE,
- .open = drm_open,
- .release= drm_release,
- .unlocked_ioctl = drm_ioctl,
- .compat_ioctl = drm_compat_ioctl,
- .poll = drm_poll,
- .read = drm_read,
.llseek = no_llseek,
- .mmap = bochs_mmap,
+ DRM_VRAM_MM_FILE_OPERATIONS
};
static struct drm_driver bochs_driver = {
@@ -82,10 +76,8 @@ static struct drm_driver bochs_driver = {
.date = "20130925",
.major = 1,
.minor = 0,
- .gem_free_object_unlocked =
- drm_gem_vram_driver_gem_free_object_unlocked,
- .dumb_create= bochs_dumb_create,
- .dumb_map_offset= drm_gem_vram_driver_dumb_mmap_offset,
+
+ DRM_GEM_VRAM_DRIVER,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 86062804e54f..e5de0e1a4ace 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -9,157 +9,25 @@
/* -- */
-static inline struct bochs_device *bochs_bdev(struct ttm_bo_device *bd)
-{
- return container_of(bd, struct bochs_device, ttm.bdev);
-}
-
-static int bochs_bo_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
- struct ttm_mem_type_manager *man)
-{
- switch (type) {
- case TTM_PL_SYSTEM:
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
- break;
- case TTM_PL_VRAM:
- man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED |
- TTM_MEMTYPE_FLAG_MAPPABLE;
- man->available_caching = TTM_PL_FLAG_UNCACHED |
- TTM_PL_FLAG_WC;
- man->default_caching = TTM_PL_FLAG_WC;
- break;
- default:
- DRM_ERROR("Unsupported memory type %u\n", (unsigned)type);
- return -EINVAL;
- }
- return 0;
-}
-
-stat
[PATCH v4 09/19] drm/ast: Convert AST driver to VRAM MM
The data structure |struct drm_vram_mm| and its helpers replace ast's
TTM-based memory manager. It's the same implementation; except for the
type names.
v4:
* don't select DRM_TTM or DRM_VRAM_MM_HELPER
v3:
* use drm_gem_vram_mm_funcs
* convert driver to drm_device-based instance
v2:
* implement ast_mmap() with drm_vram_mm_mmap()
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/Kconfig| 1 -
drivers/gpu/drm/ast/ast_drv.c | 14 +---
drivers/gpu/drm/ast/ast_drv.h | 18 +
drivers/gpu/drm/ast/ast_main.c | 13 +---
drivers/gpu/drm/ast/ast_ttm.c | 134 ++---
5 files changed, 13 insertions(+), 167 deletions(-)
diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig
index f3737488630b..7c7e7c57911a 100644
--- a/drivers/gpu/drm/ast/Kconfig
+++ b/drivers/gpu/drm/ast/Kconfig
@@ -1,7 +1,6 @@
config DRM_AST
tristate "AST server chips"
depends on DRM && PCI && MMU
- select DRM_TTM
select DRM_KMS_HELPER
select DRM_VRAM_HELPER
help
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 7012b17b984f..3811997e78c4 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -205,13 +205,7 @@ static struct pci_driver ast_pci_driver = {
static const struct file_operations ast_fops = {
.owner = THIS_MODULE,
- .open = drm_open,
- .release = drm_release,
- .unlocked_ioctl = drm_ioctl,
- .mmap = ast_mmap,
- .poll = drm_poll,
- .compat_ioctl = drm_compat_ioctl,
- .read = drm_read,
+ DRM_VRAM_MM_FILE_OPERATIONS
};
static struct drm_driver driver = {
@@ -228,11 +222,7 @@ static struct drm_driver driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
- .gem_free_object_unlocked =
- drm_gem_vram_driver_gem_free_object_unlocked,
- .dumb_create = ast_dumb_create,
- .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset,
-
+ DRM_GEM_VRAM_DRIVER
};
static int __init ast_init(void)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 712838f725dc..32096a191aaf 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -31,15 +31,11 @@
#include
#include
-#include
-#include
-#include
-#include
-#include
-
#include
#include
+#include
+
#include
#include
@@ -104,10 +100,6 @@ struct ast_private {
int fb_mtrr;
- struct {
- struct ttm_bo_device bdev;
- } ttm;
-
struct drm_gem_object *cursor_cache;
uint64_t cursor_cache_gpu_addr;
/* Acces to this cache is protected by the crtc->mutex of the only crtc
@@ -325,10 +317,6 @@ void ast_fbdev_set_base(struct ast_private *ast, unsigned
long gpu_addr);
#define AST_MM_ALIGN_SHIFT 4
#define AST_MM_ALIGN_MASK ((1 << AST_MM_ALIGN_SHIFT) - 1)
-extern int ast_dumb_create(struct drm_file *file,
- struct drm_device *dev,
- struct drm_mode_create_dumb *args);
-
int ast_mm_init(struct ast_private *ast);
void ast_mm_fini(struct ast_private *ast);
@@ -336,8 +324,6 @@ int ast_gem_create(struct drm_device *dev,
u32 size, bool iskernel,
struct drm_gem_object **obj);
-int ast_mmap(struct file *filp, struct vm_area_struct *vma);
-
/* ast post */
void ast_enable_vga(struct drm_device *dev);
void ast_enable_mmio(struct drm_device *dev);
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 61fc7b8ea470..4c7e31cb45ff 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -593,7 +593,6 @@ int ast_gem_create(struct drm_device *dev,
u32 size, bool iskernel,
struct drm_gem_object **obj)
{
- struct ast_private *ast = dev->dev_private;
struct drm_gem_vram_object *gbo;
int ret;
@@ -603,7 +602,7 @@ int ast_gem_create(struct drm_device *dev,
if (size == 0)
return -EINVAL;
- gbo = drm_gem_vram_create(dev, &ast->ttm.bdev, size, 0, false);
+ gbo = drm_gem_vram_create(dev, &dev->vram_mm->bdev, size, 0, false);
if (IS_ERR(gbo)) {
ret = PTR_ERR(gbo);
if (ret != -ERESTARTSYS)
@@ -613,13 +612,3 @@ int ast_gem_create(struct drm_device *dev,
*obj = &gbo->gem;
return 0;
}
-
-int ast_dumb_create(struct drm_file *file,
- struct drm_device *dev,
- struct drm_mode_create_dumb *args)
-{
- struct ast_private *ast = dev->dev_private;
-
- return drm_gem_vram_fill_create_dumb(file, dev, &ast->ttm.bdev, 0,
-false, args);
-}
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 794ebb755a5d..779c53efee8e 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/dr
[PATCH v4 13/19] drm/mgag200: Convert mgag200 driver to |struct drm_gem_vram_object|
The data structure |struct drm_gem_vram_object| and its helpers replace
|struct mgag200_bo|. It's the same implementation; except for the type
names.
v4:
* cleanups from checkpatch.pl
* select config option DRM_VRAM_HELPER
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/Kconfig | 1 +
drivers/gpu/drm/mgag200/mgag200_cursor.c | 63 +
drivers/gpu/drm/mgag200/mgag200_drv.c| 5 +-
drivers/gpu/drm/mgag200/mgag200_drv.h| 62 ++--
drivers/gpu/drm/mgag200/mgag200_fb.c | 22 +--
drivers/gpu/drm/mgag200/mgag200_main.c | 84 +++
drivers/gpu/drm/mgag200/mgag200_mode.c | 46 +++---
drivers/gpu/drm/mgag200/mgag200_ttm.c| 172 +--
8 files changed, 107 insertions(+), 348 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig
index db58578719d2..907bb2162228 100644
--- a/drivers/gpu/drm/mgag200/Kconfig
+++ b/drivers/gpu/drm/mgag200/Kconfig
@@ -3,6 +3,7 @@ config DRM_MGAG200
depends on DRM && PCI && MMU
select DRM_KMS_HELPER
select DRM_TTM
+ select DRM_VRAM_HELPER
help
This is a KMS driver for the MGA G200 server chips, it
does not support the original MGA G200 or any of the desktop
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index 968e20379d54..cca3922f9f67 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -23,9 +23,9 @@ static void mga_hide_cursor(struct mga_device *mdev)
WREG8(MGA_CURPOSXL, 0);
WREG8(MGA_CURPOSXH, 0);
if (mdev->cursor.pixels_1->pin_count)
- mgag200_bo_unpin(mdev->cursor.pixels_1);
+ drm_gem_vram_unpin(mdev->cursor.pixels_1);
if (mdev->cursor.pixels_2->pin_count)
- mgag200_bo_unpin(mdev->cursor.pixels_2);
+ drm_gem_vram_unpin(mdev->cursor.pixels_2);
}
int mga_crtc_cursor_set(struct drm_crtc *crtc,
@@ -36,12 +36,12 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
{
struct drm_device *dev = crtc->dev;
struct mga_device *mdev = (struct mga_device *)dev->dev_private;
- struct mgag200_bo *pixels_1 = mdev->cursor.pixels_1;
- struct mgag200_bo *pixels_2 = mdev->cursor.pixels_2;
- struct mgag200_bo *pixels_current = mdev->cursor.pixels_current;
- struct mgag200_bo *pixels_prev = mdev->cursor.pixels_prev;
+ struct drm_gem_vram_object *pixels_1 = mdev->cursor.pixels_1;
+ struct drm_gem_vram_object *pixels_2 = mdev->cursor.pixels_2;
+ struct drm_gem_vram_object *pixels_current =
mdev->cursor.pixels_current;
+ struct drm_gem_vram_object *pixels_prev = mdev->cursor.pixels_prev;
struct drm_gem_object *obj;
- struct mgag200_bo *bo = NULL;
+ struct drm_gem_vram_object *gbo = NULL;
int ret = 0;
unsigned int i, row, col;
uint32_t colour_set[16];
@@ -50,7 +50,7 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
uint32_t this_colour;
bool found = false;
int colour_count = 0;
- u64 gpu_addr;
+ s64 gpu_addr;
u8 reg_index;
u8 this_row[48];
@@ -79,44 +79,55 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
if (!obj)
return -ENOENT;
- ret = mgag200_bo_reserve(pixels_1, true);
+ ret = drm_gem_vram_reserve(pixels_1, true);
if (ret) {
WREG8(MGA_CURPOSXL, 0);
WREG8(MGA_CURPOSXH, 0);
goto out_unref;
}
- ret = mgag200_bo_reserve(pixels_2, true);
+ ret = drm_gem_vram_reserve(pixels_2, true);
if (ret) {
WREG8(MGA_CURPOSXL, 0);
WREG8(MGA_CURPOSXH, 0);
- mgag200_bo_unreserve(pixels_1);
+ drm_gem_vram_unreserve(pixels_1);
goto out_unreserve1;
}
/* Move cursor buffers into VRAM if they aren't already */
if (!pixels_1->pin_count) {
- ret = mgag200_bo_pin(pixels_1, TTM_PL_FLAG_VRAM,
-&mdev->cursor.pixels_1_gpu_addr);
+ ret = drm_gem_vram_pin(pixels_1, DRM_GEM_VRAM_PL_FLAG_VRAM);
if (ret)
goto out1;
+ gpu_addr = drm_gem_vram_offset(pixels_1);
+ if (gpu_addr < 0) {
+ drm_gem_vram_unpin(pixels_1);
+ goto out1;
+ }
+ mdev->cursor.pixels_1_gpu_addr = gpu_addr;
}
if (!pixels_2->pin_count) {
- ret = mgag200_bo_pin(pixels_2, TTM_PL_FLAG_VRAM,
-&mdev->cursor.pixels_2_gpu_addr);
+ ret = drm_gem_vram_pin(pixels_2, DRM_GEM_VRAM_PL_FLAG_VRAM);
if (ret) {
- mgag200_bo_unpin(pixels_1);
+ drm_gem_vram_unpin(pixels_1);
+ g
[PATCH v4 01/19] drm: Add |struct drm_gem_vram_object| and helpers
The type |struct drm_gem_vram_object| implements a GEM object for simple
framebuffer devices with dedicated video memory. The BO is either located
in VRAM or system memory.
The implementation has been created from the respective code in ast,
bochs and mgag200. These drivers copy their implementation from each
other; except for the names of several data types. The helpers are
currently build with TTM, but this is considered an implementation
detail and may change in future updates.
v4:
* cleanups from checkpatch.pl
* removed several fixed-size types from interfaces
* DRM_VRAM_HELPER now selects DRM_TTM
* remove separate config option for GEM VRAM
v2:
* rename to |struct drm_gem_vram_object|
* move drm_is_gem_ttm() to a later patch in the series
* add drm_gem_vram_kmap_at()
* return is_iomem from kmap functions
* redefine TTM placement flags for public interface
* documentation fixes
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/drm-mm.rst | 15 +
drivers/gpu/drm/Kconfig | 7 +
drivers/gpu/drm/Makefile | 4 +
drivers/gpu/drm/drm_gem_vram_helper.c| 412 +++
drivers/gpu/drm/drm_vram_helper_common.c | 6 +
include/drm/drm_gem_vram_helper.h| 92 +
6 files changed, 536 insertions(+)
create mode 100644 drivers/gpu/drm/drm_gem_vram_helper.c
create mode 100644 drivers/gpu/drm/drm_vram_helper_common.c
create mode 100644 include/drm/drm_gem_vram_helper.h
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 54a696d961a7..a3b685089512 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -380,6 +380,21 @@ GEM CMA Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
:export:
+VRAM Helper Function Reference
+==
+
+GEM VRAM Helper Functions Reference
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_gem_vram_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c
+ :export:
+
VMA Offset Manager
==
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2267e84d5cb4..13d7b321db0d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -160,6 +160,13 @@ config DRM_TTM
GPU memory types. Will be enabled automatically if a device driver
uses it.
+config DRM_VRAM_HELPER
+ tristate
+ depends on DRM
+ select DRM_TTM
+ help
+ Helpers for VRAM memory management
+
config DRM_GEM_CMA_HELPER
bool
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 72f5036d9bfa..ed49b2480766 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,6 +32,10 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm_vram_helper-y := drm_gem_vram_helper.o \
+drm_vram_helper_common.o
+obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
+
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o
drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
new file mode 100644
index ..cac5b70c7ffb
--- /dev/null
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -0,0 +1,412 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include
+#include
+
+/**
+ * DOC: overview
+ *
+ * This library provides a GEM buffer object that is backed by video RAM
+ * (VRAM). It can be used for framebuffer devices with dedicated memory.
+ */
+
+/*
+ * Buffer-objects helpers
+ */
+
+static void drm_gem_vram_cleanup(struct drm_gem_vram_object *gbo)
+{
+ /* We got here via ttm_bo_put(), which means that the
+* TTM buffer object in 'bo' has already been cleaned
+* up; only release the GEM object.
+*/
+ drm_gem_object_release(&gbo->gem);
+}
+
+static void drm_gem_vram_destroy(struct drm_gem_vram_object *gbo)
+{
+ drm_gem_vram_cleanup(gbo);
+ kfree(gbo);
+}
+
+static void ttm_buffer_object_destroy(struct ttm_buffer_object *bo)
+{
+ struct drm_gem_vram_object *gbo = drm_gem_vram_of_bo(bo);
+
+ drm_gem_vram_destroy(gbo);
+}
+
+static void drm_gem_vram_placement(struct drm_gem_vram_object *gbo,
+ unsigned long pl_flag)
+{
+ unsigned int i;
+ unsigned int c = 0;
+
+ gbo->placement.placement = gbo->placements;
+ gbo->placement.busy_placement = gbo->placements;
+
+ if (pl_flag & TTM_PL_FLAG_VRAM)
+ gbo->placements[c++].flags = TTM_PL_FLA
[PATCH v4 07/19] drm: Integrate VRAM MM into struct drm_device
There's now a pointer to struct drm_vram_mm stored in struct drm_device.
DRM drivers that use VRAM MM should use this field to refer to their
instance of the data structure. Appropriate helpers are now provided as
well.
Adding struct drm_vram_mm to struct drm_device further avoids wrappers
and boilerplate code in drivers. This patch implements default functions
for callbacks in struct drm_driver and struct file_operations that use
the struct drm_vram_mm stored in struct drm_device. Drivers that need to
provide their own implementations can still do so.
The patch also adds documentation for the VRAM helper library in general.
v4:
* cleanups from checkpatch.pl
* document VRAM helper library
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/drm-mm.rst | 6 ++
drivers/gpu/drm/drm_gem_vram_helper.c| 28
drivers/gpu/drm/drm_vram_helper_common.c | 92
drivers/gpu/drm/drm_vram_mm_helper.c | 85 ++
include/drm/drm_device.h | 4 ++
include/drm/drm_gem_vram_helper.h| 18 -
include/drm/drm_vram_mm_helper.h | 32 +
7 files changed, 264 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index eba50afbda42..c8ebd4f66a6a 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -382,6 +382,12 @@ GEM CMA Helper Functions Reference
VRAM Helper Function Reference
==
+.. kernel-doc:: drivers/gpu/drm/drm_vram_helper_common.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_gem_vram_helper.h
+ :internal:
+
GEM VRAM Helper Functions Reference
---
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 33321291475a..7def6cedc4ae 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-or-later
#include
+#include
#include
#include
#include
@@ -554,6 +555,33 @@ void drm_gem_vram_driver_gem_free_object_unlocked(struct
drm_gem_object *gem)
}
EXPORT_SYMBOL(drm_gem_vram_driver_gem_free_object_unlocked);
+/**
+ * drm_gem_vram_driver_create_dumb() - \
+ Implements &struct drm_driver.dumb_create
+ * @file: the DRM file
+ * @dev: the DRM device
+ * @args: the arguments as provided to \
+ &struct drm_driver.dumb_create
+ *
+ * This function requires the driver to use @drm_device.vram_mm for its
+ * instance of VRAM MM.
+ *
+ * Returns:
+ * 0 on success, or
+ * a negative error code otherwise.
+ */
+int drm_gem_vram_driver_dumb_create(struct drm_file *file,
+ struct drm_device *dev,
+ struct drm_mode_create_dumb *args)
+{
+ if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized"))
+ return -EINVAL;
+
+ return drm_gem_vram_fill_create_dumb(file, dev, &dev->vram_mm->bdev, 0,
+false, args);
+}
+EXPORT_SYMBOL(drm_gem_vram_driver_dumb_create);
+
/**
* drm_gem_vram_driver_dumb_mmap_offset() - \
Implements &struct drm_driver.dumb_mmap_offset
diff --git a/drivers/gpu/drm/drm_vram_helper_common.c
b/drivers/gpu/drm/drm_vram_helper_common.c
index 7c25daca18d0..3b47f7002115 100644
--- a/drivers/gpu/drm/drm_vram_helper_common.c
+++ b/drivers/gpu/drm/drm_vram_helper_common.c
@@ -2,5 +2,97 @@
#include
+/**
+ * DOC: overview
+ *
+ * This library provides &struct drm_gem_vram_object (GEM VRAM), a GEM
+ * buffer object that is backed by video RAM. It can be used for
+ * framebuffer devices with dedicated memory. The video RAM can be
+ * managed with &struct drm_vram_mm (VRAM MM). Both data structures are
+ * supposed to be used together, but can also be used individually.
+ *
+ * With the GEM interface userspace applications create, manage and destroy
+ * graphics buffers, such as an on-screen framebuffer. GEM does not provide
+ * an implementation of these interfaces. It's up to the DRM driver to
+ * provide an implementation that suits the hardware. If the hardware device
+ * contains dedicated video memory, the DRM driver can use the VRAM helper
+ * library. Each active buffer object is stored in video RAM. Active
+ * buffer are used for drawing the current frame, typically something like
+ * the frame's scanout buffer or the cursor image. If there's no more space
+ * left in VRAM, inactive GEM objects can be moved to system memory.
+ *
+ * The easiest way to use the VRAM helper library is to call
+ * drm_vram_helper_alloc_mm(). The function allocates and initializes an
+ * instance of &struct drm_vram_mm in &struct drm_device.vram_mm . Use
+ * &DRM_GEM_VRAM_DRIVER to initialize &struct drm_driver and
+ * &DRM_VRAM_MM_FILE_OPERATIONS to initialize &struct file_operations;
+ * as illustrated be
Re: Support for 2D engines/blitters in V4L2 and DRM
On Wed, 17 Apr 2019 20:10:15 +0200 Paul Kocialkowski wrote: > There's also the possibility of writing up a drm-render DDX to handle > these 2D blitters that can make things a lot faster when running a > desktop environment. As for wayland, well, I don't really know what to > think. I was under the impression that it relies on GL for 2D > operations, but am really not sure how true that actually is. Hi Paul, Wayland does not rely on anything really, it does not even have any rendering commands, and is completely agnostic to how applications or display servers might be drawing things. Wayland (protocol) does care about buffer types and fences though, since those are the things passed between applications and servers. In a Wayland architecture, each display server (called a Wayland compositor, corresponding to Xorg + window manager + compositing manager) uses whatever they want to use for putting the screen contents together. OpenGL is a popular choice, yes, but they may also use Vulkan, Pixman, Cairo, Skia, DRM KMS planes, and whatnot or a mix of any. Sometimes it may so happen that the display server does not need to render at all, the display hardware can realize the screen contents through e.g. KMS planes. Writing a hardware specific driver (like a DDX for Xorg) for one display server (or a display server library like wlroots or libweston) is no longer reasonable. You would have to do it on so many display server projects. What really makes it infeasible is the hardware-specific aspect. People would have to write a driver for every display server project for every hardware model. That's just not feasible today. Some display server projects even refuse to take hardware-specific code upstream, because keeping it working has a high cost and only very few people can test it. The only way as I see that you could have Wayland compositors at large take advantage of 2D hardware units is to come up with the common userspace API in the sense similar to Vulkan or OpenGL, so that each display server would only need to support the API, and the API implementation would handle the hardware-specific parts. OpenWF by Khronos may have been the most serious effort in that, good luck finding any users or implementations today. Although maybe Android's hwcomposer could be the next one. However, if someone is doing a special Wayland compositor to be used on specific hardware, they can of course use whatever to put the screen contents together in a downstream fork. Wayland does not restrict that in any way, not even by buffer or fence types because you can extend Wayland to deal with anything you need, as long as you also modify the apps or toolkits to do it too. The limitations are really more political and practical if you aim for upstream and wide-spread use of 2D hardware blocks. Thanks, pq pgpM_7Shy6L2t.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 18/19] drm/hisilicon: Convert hibmc-drm driver to |struct drm_gem_vram_object|
The data structure |struct drm_gem_vram_object| and its helpers replace
|struct hibmc_bo|. It's the same implementation; except for the type
names.
v4:
* select config option DRM_VRAM_HELPER
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/Kconfig | 1 +
.../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 21 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 25 +--
.../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 30 +--
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 210 +-
6 files changed, 44 insertions(+), 248 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig
b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
index c7129dc3bdfc..04d0bc685560 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig
+++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
@@ -3,6 +3,7 @@ config DRM_HISI_HIBMC
depends on DRM && PCI && MMU
select DRM_KMS_HELPER
select DRM_TTM
+ select DRM_VRAM_HELPER
help
Choose this option if you have a Hisilicon Hibmc soc chipset.
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 9316b724e7a2..db0dfa57844e 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -96,27 +96,32 @@ static void hibmc_plane_atomic_update(struct drm_plane
*plane,
struct drm_plane_state *state = plane->state;
u32 reg;
int ret;
- u64 gpu_addr = 0;
+ s64 gpu_addr = 0;
unsigned int line_l;
struct hibmc_drm_private *priv = plane->dev->dev_private;
struct hibmc_framebuffer *hibmc_fb;
- struct hibmc_bo *bo;
+ struct drm_gem_vram_object *gbo;
if (!state->fb)
return;
hibmc_fb = to_hibmc_framebuffer(state->fb);
- bo = gem_to_hibmc_bo(hibmc_fb->obj);
- ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
+ gbo = drm_gem_vram_of_gem(hibmc_fb->obj);
+ ret = drm_gem_vram_reserve(gbo, false);
if (ret) {
- DRM_ERROR("failed to reserve ttm_bo: %d", ret);
+ DRM_ERROR("failed to reserve BO: %d", ret);
return;
}
- ret = hibmc_bo_pin(bo, TTM_PL_FLAG_VRAM, &gpu_addr);
- ttm_bo_unreserve(&bo->bo);
+ ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM);
+ drm_gem_vram_unreserve(gbo);
if (ret) {
- DRM_ERROR("failed to pin hibmc_bo: %d", ret);
+ DRM_ERROR("failed to pin bo: %d", ret);
+ return;
+ }
+ gpu_addr = drm_gem_vram_offset(gbo);
+ if (gpu_addr < 0) {
+ drm_gem_vram_unpin(gbo);
return;
}
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 8ed94fcd42a7..7027a1a05768 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -63,9 +63,10 @@ static struct drm_driver hibmc_driver = {
.desc = "hibmc drm driver",
.major = 1,
.minor = 0,
- .gem_free_object_unlocked = hibmc_gem_free_object,
+ .gem_free_object_unlocked =
+ drm_gem_vram_driver_gem_free_object_unlocked,
.dumb_create= hibmc_dumb_create,
- .dumb_map_offset= hibmc_dumb_mmap_offset,
+ .dumb_map_offset= drm_gem_vram_driver_dumb_mmap_offset,
.irq_handler= hibmc_drm_interrupt,
};
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 0a381c22de26..6b3430fc5148 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
struct hibmc_framebuffer {
@@ -59,25 +60,6 @@ struct hibmc_drm_private {
#define to_hibmc_framebuffer(x) container_of(x, struct hibmc_framebuffer, fb)
-struct hibmc_bo {
- struct ttm_buffer_object bo;
- struct ttm_placement placement;
- struct ttm_bo_kmap_obj kmap;
- struct drm_gem_object gem;
- struct ttm_place placements[3];
- int pin_count;
-};
-
-static inline struct hibmc_bo *hibmc_bo(struct ttm_buffer_object *bo)
-{
- return container_of(bo, struct hibmc_bo, bo);
-}
-
-static inline struct hibmc_bo *gem_to_hibmc_bo(struct drm_gem_object *gem)
-{
- return container_of(gem, struct hibmc_bo, gem);
-}
-
void hibmc_set_power_mode(struct hibmc_drm_private *priv,
unsigned int power_mode);
void hibmc_set_current_gate(struct hibmc_drm_private *priv,
@@ -97,13 +79,8 @@ hibmc_framebuffer_init(struct drm_device *dev,
int hibmc_mm_init(struct hibmc_drm_private *hibmc);
void hibmc_mm_fini(struct hibmc_drm_priv
[PATCH v4 05/19] drm: Add VRAM MM, a simple memory manager for dedicated VRAM
The VRAM MM memory manager is a helper library that manages dedicated video
memory of simple framebuffer devices. It is supported to be used with
struct drm_gem_vram_object, but does not depend on it.
The implementation is based on the respective code from ast, bochs, and
mgag200. These drivers share the exact same implementation except for type
names. The helpers are currently build with TTM. This may change in future
revisions.
v4:
* cleanups from checkpatch.pl
v2:
* renamed to struct drm_vram_mm
* add drm_vram_mm_mmap() helper
* documentation fixes
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/drm-mm.rst | 13 +-
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_vram_mm_helper.c | 210 +++
include/drm/drm_vram_mm_helper.h | 69 +
4 files changed, 293 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/drm_vram_mm_helper.c
create mode 100644 include/drm/drm_vram_mm_helper.h
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index a3b685089512..eba50afbda42 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -79,7 +79,6 @@ count for the TTM, which will call your initialization
function.
See the radeon_ttm.c file for an example of usage.
-
The Graphics Execution Manager (GEM)
@@ -395,6 +394,18 @@ GEM VRAM Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c
:export:
+VRAM MM Helper Functions Reference
+--
+
+.. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_vram_mm_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c
+ :export:
+
VMA Offset Manager
==
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index ed49b2480766..4c3dc4268b65 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -33,7 +33,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
drm_vram_helper-y := drm_gem_vram_helper.o \
-drm_vram_helper_common.o
+drm_vram_helper_common.o \
+drm_vram_mm_helper.o
obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o
drm_probe_helper.o \
diff --git a/drivers/gpu/drm/drm_vram_mm_helper.c
b/drivers/gpu/drm/drm_vram_mm_helper.c
new file mode 100644
index ..d17c5169b018
--- /dev/null
+++ b/drivers/gpu/drm/drm_vram_mm_helper.c
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include
+#include
+#include
+
+/**
+ * DOC: overview
+ *
+ * The data structure &struct drm_vram_mm and its helpers implement a memory
+ * manager for simple framebuffer devices with dedicated video memory. Buffer
+ * objects are either placed in video RAM or evicted to system memory. These
+ * helper functions work well with &struct drm_gem_vram_object.
+ */
+
+/*
+ * TTM TT
+ */
+
+static void backend_func_destroy(struct ttm_tt *tt)
+{
+ ttm_tt_fini(tt);
+ kfree(tt);
+}
+
+static struct ttm_backend_func backend_func = {
+ .destroy = backend_func_destroy
+};
+
+/*
+ * TTM BO device
+ */
+
+static struct ttm_tt *bo_driver_ttm_tt_create(struct ttm_buffer_object *bo,
+ uint32_t page_flags)
+{
+ struct ttm_tt *tt;
+ int ret;
+
+ tt = kzalloc(sizeof(*tt), GFP_KERNEL);
+ if (!tt)
+ return NULL;
+
+ tt->func = &backend_func;
+
+ ret = ttm_tt_init(tt, bo, page_flags);
+ if (ret < 0)
+ goto err_ttm_tt_init;
+
+ return tt;
+
+err_ttm_tt_init:
+ kfree(tt);
+ return NULL;
+}
+
+static int bo_driver_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
+ struct ttm_mem_type_manager *man)
+{
+ switch (type) {
+ case TTM_PL_SYSTEM:
+ man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->available_caching = TTM_PL_MASK_CACHING;
+ man->default_caching = TTM_PL_FLAG_CACHED;
+ break;
+ case TTM_PL_VRAM:
+ man->func = &ttm_bo_manager_func;
+ man->flags = TTM_MEMTYPE_FLAG_FIXED |
+TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->available_caching = TTM_PL_FLAG_UNCACHED |
+TTM_PL_FLAG_WC;
+ man->default_caching = TTM_PL_FLAG_WC;
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static void bo_driver_evict_flags(struct ttm_buffer_object *bo,
+ struct ttm_placement *placement)
+{
+ struct drm_vram_mm *vmm = drm_vram_mm_of_bdev(bo->bdev);
+
+ if (vmm->funcs && vm
[PATCH v4 17/19] drm/vboxvideo: Convert vboxvideo driver to VRAM MM
The data structure |struct drm_vram_mm| and its helpers replace vboxvideo's
TTM-based memory manager. It's the same implementation; except for the type
names.
v4:
* don't select DRM_TTM or DRM_VRAM_MM_HELPER
v3:
* use drm_gem_vram_mm_funcs
* convert driver to drm_device-based instance
v2:
* implement vbox_mmap() with drm_vram_mm_mmap()
Signed-off-by: Thomas Zimmermann
Reviewed-by: Hans de Goede
---
drivers/gpu/drm/vboxvideo/Kconfig | 1 -
drivers/gpu/drm/vboxvideo/vbox_drv.c | 13 +--
drivers/gpu/drm/vboxvideo/vbox_drv.h | 15 +--
drivers/gpu/drm/vboxvideo/vbox_main.c | 13 +--
drivers/gpu/drm/vboxvideo/vbox_ttm.c | 136 ++
5 files changed, 13 insertions(+), 165 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/Kconfig
b/drivers/gpu/drm/vboxvideo/Kconfig
index f8f689c55e94..fc16a5589379 100644
--- a/drivers/gpu/drm/vboxvideo/Kconfig
+++ b/drivers/gpu/drm/vboxvideo/Kconfig
@@ -2,7 +2,6 @@ config DRM_VBOXVIDEO
tristate "Virtual Box Graphics Card"
depends on DRM && X86 && PCI
select DRM_KMS_HELPER
- select DRM_TTM
select DRM_VRAM_HELPER
select GENERIC_ALLOCATOR
help
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index 336a8e03e151..02537ab9cc08 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -191,13 +191,7 @@ static struct pci_driver vbox_pci_driver = {
static const struct file_operations vbox_fops = {
.owner = THIS_MODULE,
- .open = drm_open,
- .release = drm_release,
- .unlocked_ioctl = drm_ioctl,
- .compat_ioctl = drm_compat_ioctl,
- .mmap = vbox_mmap,
- .poll = drm_poll,
- .read = drm_read,
+ DRM_VRAM_MM_FILE_OPERATIONS
};
static struct drm_driver driver = {
@@ -215,10 +209,7 @@ static struct drm_driver driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
- .gem_free_object_unlocked =
- drm_gem_vram_driver_gem_free_object_unlocked,
- .dumb_create = vbox_dumb_create,
- .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset,
+ DRM_GEM_VRAM_DRIVER,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h
b/drivers/gpu/drm/vboxvideo/vbox_drv.h
index 12e47392b2f9..9028f946bc06 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
@@ -20,11 +20,7 @@
#include
#include
-#include
-#include
-#include
-#include
-#include
+#include
#include "vboxvideo_guest.h"
#include "vboxvideo_vbe.h"
@@ -78,10 +74,6 @@ struct vbox_private {
int fb_mtrr;
- struct {
- struct ttm_bo_device bdev;
- } ttm;
-
struct mutex hw_mutex; /* protects modeset and accel/vbva accesses */
struct work_struct hotplug_work;
u32 input_mapping_width;
@@ -169,16 +161,11 @@ int vboxfb_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes);
void vbox_fbdev_fini(struct vbox_private *vbox);
-int vbox_dumb_create(struct drm_file *file,
-struct drm_device *dev,
-struct drm_mode_create_dumb *args);
-
int vbox_mm_init(struct vbox_private *vbox);
void vbox_mm_fini(struct vbox_private *vbox);
int vbox_gem_create(struct vbox_private *vbox,
u32 size, bool iskernel, struct drm_gem_object **obj);
-int vbox_mmap(struct file *filp, struct vm_area_struct *vma);
/* vbox_prime.c */
int vbox_gem_prime_pin(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c
b/drivers/gpu/drm/vboxvideo/vbox_main.c
index 525e9fd63f4d..18693e2bf72a 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_main.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
@@ -283,7 +283,8 @@ int vbox_gem_create(struct vbox_private *vbox,
if (size == 0)
return -EINVAL;
- gbo = drm_gem_vram_create(&vbox->ddev, &vbox->ttm.bdev, size, 0, false);
+ gbo = drm_gem_vram_create(&vbox->ddev, &vbox->ddev.vram_mm->bdev,
+ size, 0, false);
if (IS_ERR(gbo)) {
ret = PTR_ERR(gbo);
if (ret != -ERESTARTSYS)
@@ -295,13 +296,3 @@ int vbox_gem_create(struct vbox_private *vbox,
return 0;
}
-
-int vbox_dumb_create(struct drm_file *file,
-struct drm_device *dev, struct drm_mode_create_dumb *args)
-{
- struct vbox_private *vbox = dev->dev_private;
-
- return drm_gem_vram_fill_create_dumb(file, dev, &vbox->ttm.bdev, 0,
- false, args);
-
-}
diff --git a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
index 0989d656eed6..b82595a9ed0f 100644
--- a/drivers/gpu/drm/vboxvide
[PATCH v4 10/19] drm/ast: Replace mapping code with drm_gem_vram_{kmap/kunmap}()
The AST driver establishes several memory mappings for frame buffers
and cursors. This patch converts the driver to use the equivalent
drm_gem_vram_kmap() functions. It removes the dependencies on TTM
and cleans up the code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 1 -
drivers/gpu/drm/ast/ast_fb.c | 23 +--
drivers/gpu/drm/ast/ast_mode.c | 54 --
3 files changed, 53 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 32096a191aaf..b6cac9511796 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -256,7 +256,6 @@ struct ast_fbdev {
struct ast_framebuffer afb;
void *sysram;
int size;
- struct ttm_bo_kmap_obj mapping;
int x1, y1, x2, y2; /* dirty rect */
spinlock_t dirty_lock;
};
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 778423fcf352..505e602855c0 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -53,6 +53,7 @@ static void ast_dirty_update(struct ast_fbdev *afbdev,
int src_offset, dst_offset;
int bpp = afbdev->afb.base.format->cpp[0];
int ret = -EBUSY;
+ u8 *dst;
bool unmap = false;
bool store_for_later = false;
int x2, y2;
@@ -101,27 +102,31 @@ static void ast_dirty_update(struct ast_fbdev *afbdev,
afbdev->x2 = afbdev->y2 = 0;
spin_unlock_irqrestore(&afbdev->dirty_lock, flags);
- if (!gbo->kmap.virtual) {
- ret = ttm_bo_kmap(&gbo->bo, 0, gbo->bo.num_pages, &gbo->kmap);
- if (ret) {
+ dst = drm_gem_vram_kmap(gbo, false, NULL);
+ if (IS_ERR(dst)) {
+ DRM_ERROR("failed to kmap fb updates\n");
+ goto out;
+ } else if (!dst) {
+ dst = drm_gem_vram_kmap(gbo, true, NULL);
+ if (IS_ERR(dst)) {
DRM_ERROR("failed to kmap fb updates\n");
- drm_gem_vram_unreserve(gbo);
- return;
+ goto out;
}
unmap = true;
}
+
for (i = y; i <= y2; i++) {
/* assume equal stride for now */
src_offset = dst_offset =
i * afbdev->afb.base.pitches[0] + (x * bpp);
- memcpy_toio(gbo->kmap.virtual + src_offset,
- afbdev->sysram + dst_offset,
+ memcpy_toio(dst + dst_offset, afbdev->sysram + src_offset,
(x2 - x + 1) * bpp);
-
}
+
if (unmap)
- ttm_bo_kunmap(&gbo->kmap);
+ drm_gem_vram_kunmap(gbo);
+out:
drm_gem_vram_unreserve(gbo);
}
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index b75ed3816642..3475591a22c3 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -532,6 +532,7 @@ static int ast_crtc_do_set_base(struct drm_crtc *crtc,
struct drm_gem_vram_object *gbo;
int ret;
s64 gpu_addr;
+ void *base;
/* push the previous fb to system ram */
if (!atomic && fb) {
@@ -564,11 +565,13 @@ static int ast_crtc_do_set_base(struct drm_crtc *crtc,
if (&ast->fbdev->afb == ast_fb) {
/* if pushing console in kmap it */
- ret = ttm_bo_kmap(&gbo->bo, 0, gbo->bo.num_pages, &gbo->kmap);
- if (ret)
+ base = drm_gem_vram_kmap(gbo, true, NULL);
+ if (IS_ERR(base)) {
+ ret = PTR_ERR(base);
DRM_ERROR("failed to kmap fbcon\n");
- else
+ } else {
ast_fbdev_set_base(ast, gpu_addr);
+ }
}
drm_gem_vram_unreserve(gbo);
@@ -928,6 +931,7 @@ static int ast_cursor_init(struct drm_device *dev)
struct drm_gem_object *obj;
struct drm_gem_vram_object *gbo;
s64 gpu_addr;
+ void *base;
size = (AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE) * AST_DEFAULT_HWC_NUM;
@@ -951,9 +955,11 @@ static int ast_cursor_init(struct drm_device *dev)
}
/* kmap the object */
- ret = ttm_bo_kmap(&gbo->bo, 0, gbo->bo.num_pages, &ast->cache_kmap);
- if (ret)
+ base = drm_gem_vram_kmap_at(gbo, true, NULL, &ast->cache_kmap);
+ if (IS_ERR(base)) {
+ ret = PTR_ERR(base);
goto fail;
+ }
ast->cursor_cache = obj;
ast->cursor_cache_gpu_addr = gpu_addr;
@@ -966,7 +972,9 @@ static int ast_cursor_init(struct drm_device *dev)
static void ast_cursor_fini(struct drm_device *dev)
{
struct ast_private *ast = dev->dev_private;
- ttm_bo_kunmap(&ast->cache_kmap);
+ struct drm_gem_vram_object *gbo =
+ drm_gem_vram_of_gem(ast->cursor_cache);
+ drm_gem_vram_kunm
[PATCH v4 02/19] drm: Add |struct drm_gem_vram_object| callbacks for |struct ttm_bo_driver|
The provided helpers can be used for the respective callback functions
in |struct ttm_bo_driver|.
v2:
* drm_is_gem_vram() is now a private function
* documentation fixes
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 50 +++
include/drm/drm_gem_vram_helper.h | 10 ++
2 files changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index cac5b70c7ffb..e929a18c03f3 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -410,3 +410,53 @@ void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo)
drm_gem_vram_kunmap_at(gbo, &gbo->kmap);
}
EXPORT_SYMBOL(drm_gem_vram_kunmap);
+
+/*
+ * Helpers for struct ttm_bo_driver
+ */
+
+static bool drm_is_gem_vram(struct ttm_buffer_object *bo)
+{
+ return (bo->destroy == ttm_buffer_object_destroy);
+}
+
+/**
+ * drm_gem_vram_bo_driver_evict_flags() - \
+ Implements &struct ttm_bo_driver.evict_flags
+ * @bo:TTM buffer object. Refers to &struct drm_gem_vram_object.bo
+ * @pl:TTM placement information.
+ */
+void drm_gem_vram_bo_driver_evict_flags(struct ttm_buffer_object *bo,
+ struct ttm_placement *pl)
+{
+ struct drm_gem_vram_object *gbo;
+
+ /* TTM may pass BOs that are not GEM VRAM BOs. */
+ if (!drm_is_gem_vram(bo))
+ return;
+
+ gbo = drm_gem_vram_of_bo(bo);
+ drm_gem_vram_placement(gbo, TTM_PL_FLAG_SYSTEM);
+ *pl = gbo->placement;
+}
+EXPORT_SYMBOL(drm_gem_vram_bo_driver_evict_flags);
+
+/**
+ * drm_gem_vram_bo_driver_verify_access() - \
+ Implements &struct ttm_bo_driver.verify_access
+ * @bo:TTM buffer object. Refers to &struct
drm_gem_vram_object.bo
+ * @filp: File pointer.
+ *
+ * Returns:
+ * 0 on success, or
+ * a negative errno code otherwise.
+ */
+int drm_gem_vram_bo_driver_verify_access(struct ttm_buffer_object *bo,
+struct file *filp)
+{
+ struct drm_gem_vram_object *gbo = drm_gem_vram_of_bo(bo);
+
+ return drm_vma_node_verify_access(&gbo->gem.vma_node,
+ filp->private_data);
+}
+EXPORT_SYMBOL(drm_gem_vram_bo_driver_verify_access);
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index a8fd580d434d..f92e0f531a68 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -89,4 +89,14 @@ void drm_gem_vram_kunmap_at(struct drm_gem_vram_object *gbo,
struct ttm_bo_kmap_obj *kmap);
void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo);
+/*
+ * Helpers for struct ttm_bo_driver
+ */
+
+void drm_gem_vram_bo_driver_evict_flags(struct ttm_buffer_object *bo,
+ struct ttm_placement *pl);
+
+int drm_gem_vram_bo_driver_verify_access(struct ttm_buffer_object *bo,
+struct file *filp);
+
#endif
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 04/19] drm: Add drm_gem_vram_fill_create_dumb() to create dumb buffers
The helper function drm_gem_vram_fill_create_dumb() implements most of
struct drm_driver.dumb_create() for GEM-VRAM buffer objects. It's not a
full implementation of the callback, as several driver-specific parameters
are still required.
v4:
* cleanups from checkpatch.pl
v2:
* documentation fixes
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 62 +++
include/drm/drm_gem_vram_helper.h | 8
2 files changed, 70 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 41f971908b78..461ed20b779b 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-or-later
#include
+#include
#include
/**
@@ -411,6 +412,67 @@ void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo)
}
EXPORT_SYMBOL(drm_gem_vram_kunmap);
+/**
+ * drm_gem_vram_fill_create_dumb() - \
+ Helper for implementing &struct drm_driver.dumb_create
+ * @file: the DRM file
+ * @dev: the DRM device
+ * @bdev: the TTM BO device managing the buffer object
+ * @pg_align: the buffer's alignment in multiples of the page size
+ * @interruptible: sleep interruptible if waiting for memory
+ * @args: the arguments as provided to \
+ &struct drm_driver.dumb_create
+ *
+ * This helper function fills &struct drm_mode_create_dumb, which is used
+ * by &struct drm_driver.dumb_create. Implementations of this interface
+ * should forwards their arguments to this helper, plus the driver-specific
+ * parameters.
+ *
+ * Returns:
+ * 0 on success, or
+ * a negative error code otherwise.
+ */
+int drm_gem_vram_fill_create_dumb(struct drm_file *file,
+ struct drm_device *dev,
+ struct ttm_bo_device *bdev,
+ unsigned long pg_align,
+ bool interruptible,
+ struct drm_mode_create_dumb *args)
+{
+ size_t pitch, size;
+ struct drm_gem_vram_object *gbo;
+ int ret;
+ u32 handle;
+
+ pitch = args->width * ((args->bpp + 7) / 8);
+ size = pitch * args->height;
+
+ size = roundup(size, PAGE_SIZE);
+ if (!size)
+ return -EINVAL;
+
+ gbo = drm_gem_vram_create(dev, bdev, size, pg_align, interruptible);
+ if (IS_ERR(gbo))
+ return PTR_ERR(gbo);
+
+ ret = drm_gem_handle_create(file, &gbo->gem, &handle);
+ if (ret)
+ goto err_drm_gem_object_put_unlocked;
+
+ drm_gem_object_put_unlocked(&gbo->gem);
+
+ args->pitch = pitch;
+ args->size = size;
+ args->handle = handle;
+
+ return 0;
+
+err_drm_gem_object_put_unlocked:
+ drm_gem_object_put_unlocked(&gbo->gem);
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_vram_fill_create_dumb);
+
/*
* Helpers for struct ttm_bo_driver
*/
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index d6a75d860f4e..68edb28d4508 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -8,6 +8,7 @@
#include
#include /* for container_of() */
+struct drm_mode_create_dumb;
struct filp;
#define DRM_GEM_VRAM_PL_FLAG_VRAM TTM_PL_FLAG_VRAM
@@ -89,6 +90,13 @@ void drm_gem_vram_kunmap_at(struct drm_gem_vram_object *gbo,
struct ttm_bo_kmap_obj *kmap);
void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo);
+int drm_gem_vram_fill_create_dumb(struct drm_file *file,
+ struct drm_device *dev,
+ struct ttm_bo_device *bdev,
+ unsigned long pg_align,
+ bool interruptible,
+ struct drm_mode_create_dumb *args);
+
/*
* Helpers for struct ttm_bo_driver
*/
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 14/19] drm/mgag200: Convert mgag200 driver to VRAM MM
The data structure |struct drm_vram_mm| and its helpers replace mgag200's
TTM-based memory manager. It's the same implementation; except for the type
names.
v4:
* don't select DRM_TTM or DRM_VRAM_MM_HELPER
v3:
* use drm_gem_vram_mm_funcs
* convert driver to drm_device-based instance
v2:
* implement mgag200_mmap() with drm_vram_mm_mmap()
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/Kconfig| 1 -
drivers/gpu/drm/mgag200/mgag200_drv.c | 14 +--
drivers/gpu/drm/mgag200/mgag200_drv.h | 11 +-
drivers/gpu/drm/mgag200/mgag200_main.c | 17 +---
drivers/gpu/drm/mgag200/mgag200_ttm.c | 133 ++---
5 files changed, 15 insertions(+), 161 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig
index 907bb2162228..738ed20163c7 100644
--- a/drivers/gpu/drm/mgag200/Kconfig
+++ b/drivers/gpu/drm/mgag200/Kconfig
@@ -2,7 +2,6 @@ config DRM_MGAG200
tristate "Kernel modesetting driver for MGA G200 server engines"
depends on DRM && PCI && MMU
select DRM_KMS_HELPER
- select DRM_TTM
select DRM_VRAM_HELPER
help
This is a KMS driver for the MGA G200 server chips, it
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index 1f2a034d5a9b..93bd1589e50e 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -59,13 +59,7 @@ static void mga_pci_remove(struct pci_dev *pdev)
static const struct file_operations mgag200_driver_fops = {
.owner = THIS_MODULE,
- .open = drm_open,
- .release = drm_release,
- .unlocked_ioctl = drm_ioctl,
- .mmap = mgag200_mmap,
- .poll = drm_poll,
- .compat_ioctl = drm_compat_ioctl,
- .read = drm_read,
+ DRM_VRAM_MM_FILE_OPERATIONS
};
static struct drm_driver driver = {
@@ -79,11 +73,7 @@ static struct drm_driver driver = {
.major = DRIVER_MAJOR,
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
-
- .gem_free_object_unlocked =
- drm_gem_vram_driver_gem_free_object_unlocked,
- .dumb_create = mgag200_dumb_create,
- .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset,
+ DRM_GEM_VRAM_DRIVER
};
static struct pci_driver mgag200_pci_driver = {
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 86b33e23ab7f..16ce6b338dce 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -17,15 +17,12 @@
#include
#include
-#include
-#include
-#include
-#include
-#include
#include
#include
+#include
+
#include
#include
@@ -212,10 +209,6 @@ struct mga_device {
int fb_mtrr;
- struct {
- struct ttm_bo_device bdev;
- } ttm;
-
/* SE model number stored in reg 0x1e24 */
u32 unique_rev_id;
};
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 59a4028a5c6c..f3687fed4075 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -230,10 +230,10 @@ int mgag200_driver_load(struct drm_device *dev, unsigned
long flags)
}
/* Make small buffers to store a hardware cursor (double buffered icon
updates) */
- mdev->cursor.pixels_1 = drm_gem_vram_create(dev, &mdev->ttm.bdev,
+ mdev->cursor.pixels_1 = drm_gem_vram_create(dev, &dev->vram_mm->bdev,
roundup(48*64, PAGE_SIZE),
0, 0);
- mdev->cursor.pixels_2 = drm_gem_vram_create(dev, &mdev->ttm.bdev,
+ mdev->cursor.pixels_2 = drm_gem_vram_create(dev, &dev->vram_mm->bdev,
roundup(48*64, PAGE_SIZE),
0, 0);
if (IS_ERR(mdev->cursor.pixels_2) || IS_ERR(mdev->cursor.pixels_1)) {
@@ -274,7 +274,6 @@ int mgag200_gem_create(struct drm_device *dev,
u32 size, bool iskernel,
struct drm_gem_object **obj)
{
- struct mga_device *mdev = dev->dev_private;
struct drm_gem_vram_object *gbo;
int ret;
@@ -284,7 +283,7 @@ int mgag200_gem_create(struct drm_device *dev,
if (size == 0)
return -EINVAL;
- gbo = drm_gem_vram_create(dev, &mdev->ttm.bdev, size, 0, false);
+ gbo = drm_gem_vram_create(dev, &dev->vram_mm->bdev, size, 0, false);
if (IS_ERR(gbo)) {
ret = PTR_ERR(gbo);
if (ret != -ERESTARTSYS)
@@ -294,13 +293,3 @@ int mgag200_gem_create(struct drm_device *dev,
*obj = &gbo->gem;
return 0;
}
-
-int mgag200_dumb_create(struct drm_file *file,
- struct drm_device *dev,
- struct drm_mode_create_dumb *args)
-{
- struct mga_device *mde
[PATCH v4 00/19] Share TTM code among DRM framebuffer drivers
Several simple framebuffer drivers copy most of the TTM code from each
other. The implementation is always the same; except for the name of
some data structures.
As recently discussed, this patch set provides generic memory-management
code for simple framebuffers with dedicated video memory. It further
converts the respective drivers to the generic code. The shared code
is basically the same implementation as the one copied among individual
drivers.
The patch set contains two major changes: first, it introduces
|struct drm_gem_vram_object| and helpers (GEM VRAM). It's a GEM object
that is backed by VRAM. The type's purpose is somewhat similar to
|struct drm_gem_{cma, shmem}_object|: it provides an commom implementation
that handles all the basic cases. Second, the patch set introduces
|struct drm_vram_mm| and helpers (VRAM MM). It's an implementation of a
basic memory manager for VRAM.
Both, GEM VRAM and VRAM MM, support buffer placement in VRAM and system
memory. Both can be used independedly from each other if desired by the
DRM driver.
Currently ast, bochs, mgag200, vboxvideo and hisilicon/hibmc can use
these helpers.
Future directions: with these changes, the respective drivers can also
share some of their mode-setting or fbdev code. GEM VRAM could implement
PRIME helpers, which would allow for using the generic fbcon.
The patch set is against a recent drm-tip.
v4:
* cleanups from checkpatch.pl
* add more documentation for VRAM helpers
* remove several fixed-size types from interfaces
* don't make drivers depend on DRM_TTM; auto-selected if necessary
* use single config optiom DRM_VRAM_HELPER
v3:
* share VRAM MM callback structure among drivers
* move VRAM MM instances to drm_device and share rsp. code
v2:
* rename |struct drm_gem_ttm_object| to |struct drm_gem_vram_object|
* rename |struct drm_simple_ttm| to |struct drm_vram_mm|
* make drm_is_gem_ttm() an internal helper
* add drm_gem_vram_kmap_at()
* return is_iomem from kmap functions
* redefine TTM placement flags for public interface
* add drm_vram_mm_mmap() helper
* replace almost all of driver's TTM code with these helpers
* documentation fixes
Thomas Zimmermann (19):
drm: Add |struct drm_gem_vram_object| and helpers
drm: Add |struct drm_gem_vram_object| callbacks for |struct
ttm_bo_driver|
drm: Add |struct drm_gem_vram_object| callbacks for |struct
drm_driver|
drm: Add drm_gem_vram_fill_create_dumb() to create dumb buffers
drm: Add VRAM MM, a simple memory manager for dedicated VRAM
drm: Add default instance for VRAM MM callback functions
drm: Integrate VRAM MM into struct drm_device
drm/ast: Convert AST driver to |struct drm_gem_vram_object|
drm/ast: Convert AST driver to VRAM MM
drm/ast: Replace mapping code with drm_gem_vram_{kmap/kunmap}()
drm/bochs: Convert bochs driver to |struct drm_gem_vram_object|
drm/bochs: Convert bochs driver to VRAM MM
drm/mgag200: Convert mgag200 driver to |struct drm_gem_vram_object|
drm/mgag200: Convert mgag200 driver to VRAM MM
drm/mgag200: Replace mapping code with drm_gem_vram_{kmap/kunmap}()
drm/vboxvideo: Convert vboxvideo driver to |struct
drm_gem_vram_object|
drm/vboxvideo: Convert vboxvideo driver to VRAM MM
drm/hisilicon: Convert hibmc-drm driver to |struct
drm_gem_vram_object|
drm/hisilicon: Convert hibmc-drm driver to VRAM MM
Documentation/gpu/drm-mm.rst | 34 +-
drivers/gpu/drm/Kconfig | 7 +
drivers/gpu/drm/Makefile | 5 +
drivers/gpu/drm/ast/Kconfig | 3 +-
drivers/gpu/drm/ast/ast_drv.c | 13 +-
drivers/gpu/drm/ast/ast_drv.h | 71 +-
drivers/gpu/drm/ast/ast_fb.c | 34 +-
drivers/gpu/drm/ast/ast_main.c| 77 +--
drivers/gpu/drm/ast/ast_mode.c| 124 ++--
drivers/gpu/drm/ast/ast_ttm.c | 302 +
drivers/gpu/drm/bochs/Kconfig | 2 +-
drivers/gpu/drm/bochs/bochs.h | 47 +-
drivers/gpu/drm/bochs/bochs_drv.c | 13 +-
drivers/gpu/drm/bochs/bochs_kms.c | 18 +-
drivers/gpu/drm/bochs/bochs_mm.c | 408 +---
drivers/gpu/drm/drm_gem_vram_helper.c | 615 ++
drivers/gpu/drm/drm_vram_helper_common.c | 98 +++
drivers/gpu/drm/drm_vram_mm_helper.c | 295 +
drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 21 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 33 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 30 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 341 +-
drivers/gpu/drm/mgag200/Kconfig | 2 +-
drivers/gpu/drm/mgag200/mgag200_cursor.c | 88 +--
drivers/g
Re: [PATCH] RFC: console: hack up console_trylock more
On Mon, May 6, 2019 at 9:48 AM Petr Mladek wrote: > On Mon 2019-05-06 09:11:37, Daniel Vetter wrote: > > On Fri, May 3, 2019 at 5:14 PM Petr Mladek wrote: > > > On Thu 2019-05-02 16:16:43, Daniel Vetter wrote: > > > > console_trylock, called from within printk, can be called from pretty > > > > much anywhere. Including try_to_wake_up. Note that this isn't common, > > > > usually the box is in pretty bad shape at that point already. But it > > > > really doesn't help when then lockdep jumps in and spams the logs, > > > > potentially obscuring the real backtrace we're really interested in. > > > > One case I've seen (slightly simplified backtrace): > > > > > > > > Call Trace: > > > > > > > > console_trylock+0xe/0x60 > > > > vprintk_emit+0xf1/0x320 > > > > printk+0x4d/0x69 > > > > __warn_printk+0x46/0x90 > > > > native_smp_send_reschedule+0x2f/0x40 > > > > check_preempt_curr+0x81/0xa0 > > > > ttwu_do_wakeup+0x14/0x220 > > > > try_to_wake_up+0x218/0x5f0 > > > > pollwake+0x6f/0x90 > > > > credit_entropy_bits+0x204/0x310 > > > > add_interrupt_randomness+0x18f/0x210 > > > > handle_irq+0x67/0x160 > > > > do_IRQ+0x5e/0x130 > > > > common_interrupt+0xf/0xf > > > > > > > > > > > > This alone isn't a problem, but the spinlock in the semaphore is also > > > > still held while waking up waiters (up() -> __up() -> try_to_wake_up() > > > > callchain), which then closes the runqueue vs. semaphore.lock loop, > > > > and upsets lockdep, which issues a circular locking splat to dmesg. > > > > Worse it upsets developers, since we don't want to spam dmesg with > > > > clutter when the machine is dying already. > > > > > > > > Fix this by creating a __down_trylock which only trylocks the > > > > semaphore.lock. This isn't correct in full generality, but good enough > > > > for console_lock: > > > > > > > > - there's only ever one console_lock holder, we won't fail spuriously > > > > because someone is doing a down() or up() while there's still room > > > > (unlike other semaphores with count > 1). > > > > > > > > - console_unlock() has one massive retry loop, which will catch anyone > > > > who races the trylock against the up(). This makes sure that no > > > > printk lines will get lost. Making the trylock more racy therefore > > > > has no further impact. > > > > > > To be honest, I do not see how this could solve the problem. > > > > > > The circular dependency is still there. If the new __down_trylock() > > > succeeds then console_unlock() will get called in the same context > > > and it will still need to call up() -> try_to_wake_up(). > > > > > > Note that there are many other console_lock() callers that might > > > happen in parallel and might appear in the wait queue. > > > > Hm right. It's very rare we hit this in our CI and I don't know how to > > repro otherwise, so just threw this out at the wall to see if it > > sticks. I'll try and come up with a new trick then. > > Single messages are printed from scheduler via printk_deferred(). > WARN() might be solved by introducing printk deferred context, > see the per-cpu variable printk_context. I convinced myself that I can take the wake_up_process out from under the spinlock, for the limited case of the console lock. I think that's a cleaner and more robust fix than leaking printk_context trickery into the console_unlock code. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108893] Slow redrawing of menu in Gothic 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=108893 --- Comment #16 from Michel Dänzer --- (In reply to supercoolemail from comment #11) > 42.80% Gothic2.exe radeonsi_dri.so [.] > _mesa_unpack_depth_span It would be interesting to know where _mesa_unpack_depth_span is getting called from. Can you enable call graphs for the perf data gathering and reporting? (It might be easier to use sysprof and attach the profile data saved from that) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/17] kunit: test: add support for test abort
On Fri, May 3, 2019 at 5:33 AM Logan Gunthorpe wrote:
>
>
>
> On 2019-05-03 12:48 a.m., Brendan Higgins wrote:
> > On Thu, May 2, 2019 at 8:15 PM Logan Gunthorpe wrote:
> >> On 2019-05-01 5:01 p.m., Brendan Higgins wrote:
> >>> +/*
> >>> + * struct kunit_try_catch - provides a generic way to run code which
> >>> might fail.
> >>> + * @context: used to pass user data to the try and catch functions.
> >>> + *
> >>> + * kunit_try_catch provides a generic, architecture independent way to
> >>> execute
> >>> + * an arbitrary function of type kunit_try_catch_func_t which may bail
> >>> out by
> >>> + * calling kunit_try_catch_throw(). If kunit_try_catch_throw() is
> >>> called, @try
> >>> + * is stopped at the site of invocation and @catch is catch is called.
> >>
> >> I found some of the C++ comparisons in this series a bit distasteful but
> >> wasn't going to say anything until I saw the try catch But looking
> >> into the implementation it's just a thread that can exit early which
> >> seems fine to me. Just a poor choice of name I guess...
> >
> > Guilty as charged (I have a long history with C++, sorry). Would you
> > prefer I changed the name? I just figured that try-catch is a commonly
> > understood pattern that describes exactly what I am doing.
>
> It is a commonly understood pattern, but I don't think it's what the
> code is doing. Try-catch cleans up an entire stack and allows each level
> of the stack to apply local cleanup. This implementation simply exits a
> thread and has none of that complexity. To me, it seems like an odd
> abstraction here as it's really just a test runner that can exit early
> (though I haven't seen the follow-up UML implementation).
Yeah, that is closer to what the UML specific version does, but that's
a conversation for another time.
>
> I would prefer to see this cleaned up such that the abstraction matches
> more what's going on but I don't feel that strongly about it so I'll
> leave it up to you to figure out what's best unless other reviewers have
> stronger opinions.
Cool. Let's revisit this with the follow-up patchset.
>
> >>
> >> [snip]
> >>
> >>> +static void __noreturn kunit_abort(struct kunit *test)
> >>> +{
> >>> + kunit_set_death_test(test, true);
> >>> +
> >>> + kunit_try_catch_throw(&test->try_catch);
> >>> +
> >>> + /*
> >>> + * Throw could not abort from test.
> >>> + *
> >>> + * XXX: we should never reach this line! As kunit_try_catch_throw is
> >>> + * marked __noreturn.
> >>> + */
> >>> + WARN_ONCE(true, "Throw could not abort from test!\n");
> >>> +}
> >>> +
> >>> int kunit_init_test(struct kunit *test, const char *name)
> >>> {
> >>> spin_lock_init(&test->lock);
> >>> @@ -77,6 +103,7 @@ int kunit_init_test(struct kunit *test, const char
> >>> *name)
> >>> test->name = name;
> >>> test->vprintk = kunit_vprintk;
> >>> test->fail = kunit_fail;
> >>> + test->abort = kunit_abort;
> >>
> >> There are a number of these function pointers which seem to be pointless
> >> to me as you only ever set them to one function. Just call the function
> >> directly. As it is, it is an unnecessary indirection for someone reading
> >> the code. If and when you have multiple implementations of the function
> >> then add the pointer. Don't assume you're going to need it later on and
> >> add all this maintenance burden if you never use it..
> >
> > Ah, yes, Frank (and probably others) previously asked me to remove
> > unnecessary method pointers; I removed all the totally unused ones. As
> > for these, I don't use them in this patchset, but I use them in my
> > patchsets that will follow up this one. These in particular are
> > present so that they can be mocked out for testing.
>
> Adding indirection and function pointers solely for the purpose of
> mocking out while testing doesn't sit well with me and I don't think it
> should be a pattern that's encouraged. Adding extra complexity like this
> to a design to make it unit-testable doesn't seem like something that
> makes sense in kernel code. Especially given that indirect calls are
> more expensive in the age of spectre.
Indirection is a pretty common method to make something mockable or
fakeable. Nevertheless, probably an easier discussion to have once we
have some examples to discuss.
>
> Also, mocking these particular functions seems like it's an artifact of
> how you've designed the try/catch abstraction. If the abstraction was
> more around an abort-able test runner then it doesn't make sense to need
> to mock out the abort/fail functions as you will be testing overly
> generic features of something that don't seem necessary to the
> implementation.
>
> >>
> >> [snip]
> >>
> >>> +void kunit_generic_try_catch_init(struct kunit_try_catch *try_catch)
> >>> +{
> >>> + try_catch->run = kunit_generic_run_try_catch;
> >>> + try_catch->throw = kunit_generic_throw;
> >>> +}
> >>
> >> Same here. There's only one implementation of try
[Bug 107049] monitor not found in 4.17+ kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107049 Michel Dänzer changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Michel Dänzer --- (In reply to Dan Horák from comment #10) > and the dc=0 was still required for 5.0, so sound like an improvement in 5.1 Glad to hear it's fixed in 5.1! Thanks for the follow-ups, resolving accordingly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/virtio: set seqno for dma-fence
On Mon, Apr 29, 2019 at 03:08:23PM -0700, Chia-I Wu wrote: > This is motivated by having meaningful ftrace events, but it also > fixes use cases where dma_fence_is_later is called, such as in > sync_file_merge. > > In other drivers, fence creation and cmdbuf submission normally > happen atomically, > > mutex_lock(); > fence = dma_fence_create(..., ++timeline->seqno); > submit_cmdbuf(); > mutex_unlock(); > > and have no such issue. But in our driver, because most ioctls > queue commands into ctrlq, we do not want to grab a lock. Instead, > we set seqno to 0 when a fence is created, and update it when the > command is finally queued and the seqno is known. Series pushed to drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: allocate fences with GFP_KERNEL
On Mon, Apr 29, 2019 at 03:10:21PM -0700, Chia-I Wu wrote: > It was changed to GFP_ATOMIC in commit ec2f0577c (add & use > virtio_gpu_queue_fenced_ctrl_buffer) because the allocation happened > with a spinlock held. That was no longer true after commit > 9fdd90c0f (add virtio_gpu_alloc_fence()). Added to drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: Remove redundant return type
On Fri, May 03, 2019 at 06:38:04PM +0200, Robert Foss wrote: > virtio_gpu_fence_emit() always returns 0, since it > has no error paths. > > Consequently no calls for virtio_gpu_fence_emit() > use the return value, and it can be removed. > > Signed-off-by: Robert Foss > Suggested-by: Emil Velikov Doesn't apply cleanly to drm-misc-next, probably conflicts with one of the other virtio fence patches just pushed. Can you rebase and resend? thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110616] vce module in h264 encode
https://bugs.freedesktop.org/show_bug.cgi?id=110616 --- Comment #1 from Michel Dänzer --- Please attach the corresponding output of dmesg and vainfo. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/17] kunit: test: add test managed resource tests
On Fri, May 3, 2019 at 7:34 AM shuah wrote: > > On 5/1/19 5:01 PM, Brendan Higgins wrote: > > From: Avinash Kondareddy > > > > Tests how tests interact with test managed resources in their lifetime. > > > > Signed-off-by: Avinash Kondareddy > > Signed-off-by: Brendan Higgins > > --- > > I think this change log could use more details. It is vague on what it > does. Agreed. Will fix in next revision. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110615] starting X on AMDGPU takes up to a minute
https://bugs.freedesktop.org/show_bug.cgi?id=110615 Michel Dänzer changed: What|Removed |Added Attachment #144169|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/26] compat_ioctl: cleanups
On Tue, Apr 16, 2019 at 11:23 PM Arnd Bergmann wrote: > > Hi Al, > > It took me way longer than I had hoped to revisit this series, see > https://lore.kernel.org/lkml/20180912150142.157913-1-a...@arndb.de/ > for the previously posted version. > > I've come to the point where all conversion handlers and most > COMPATIBLE_IOCTL() entries are gone from this file, but for > now, this series only has the parts that have either been reviewed > previously, or that are simple enough to include. > > The main missing piece is the SG_IO/SG_GET_REQUEST_TABLE conversion. > I'll post the patches I made for that later, as they need more > testing and review from the scsi maintainers. > > I hope you can still take these for the coming merge window, unless > new problems come up. > drivers/platform/x86/wmi.c | 2 +- Acked-by: Andy Shevchenko -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/virtio: Remove redundant return type
virtio_gpu_fence_emit() always returns 0, since it
has no error paths.
Consequently no calls for virtio_gpu_fence_emit()
use the return value, and it can be removed.
Signed-off-by: Robert Foss
Suggested-by: Emil Velikov
Reviewed-by: Chia-I Wu
---
This patch was suggested in this email thread:
[PATCH] drm/virtio: allocate fences with GFP_KERNEL
https://www.spinics.net/lists/dri-devel/msg208536.html
Changes since v1:
- Rebased on drm-misc-next
- Added r-b from Chia-I Wu
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
drivers/gpu/drm/virtio/virtgpu_fence.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 90461feeafdb..2d3e5b1debb3 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -355,7 +355,7 @@ int virtio_gpu_mmap(struct file *filp, struct
vm_area_struct *vma);
bool virtio_fence_signaled(struct dma_fence *f);
struct virtio_gpu_fence *virtio_gpu_fence_alloc(
struct virtio_gpu_device *vgdev);
-int virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
+void virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
struct virtio_gpu_ctrl_hdr *cmd_hdr,
struct virtio_gpu_fence *fence);
void virtio_gpu_fence_event_process(struct virtio_gpu_device *vdev,
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 8aecc36a0417..70d6c4329778 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -85,7 +85,7 @@ struct virtio_gpu_fence *virtio_gpu_fence_alloc(struct
virtio_gpu_device *vgdev)
return fence;
}
-int virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
+void virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
struct virtio_gpu_ctrl_hdr *cmd_hdr,
struct virtio_gpu_fence *fence)
{
@@ -102,7 +102,6 @@ int virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
cmd_hdr->flags |= cpu_to_le32(VIRTIO_GPU_FLAG_FENCE);
cmd_hdr->fence_id = cpu_to_le64(fence->f.seqno);
- return 0;
}
void virtio_gpu_fence_event_process(struct virtio_gpu_device *vgdev,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110616] vce module in h264 encode
https://bugs.freedesktop.org/show_bug.cgi?id=110616 --- Comment #2 from baopeng --- (In reply to Michel Dänzer from comment #1) > Please attach the corresponding output of dmesg and vainfo. It doesn't matter with dmesg and vainfo ? Dmesg and vainfo can't see anything -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110616] vce module in h264 encode
https://bugs.freedesktop.org/show_bug.cgi?id=110616 Michel Dänzer changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Michel Dänzer --- We need the information printed by dmesg and vainfo, otherwise we cannot help you. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2 3/3] drm/mediatek: add mipi_tx driver for mt8183
Hi, Jitao:
On Tue, 2019-04-16 at 13:42 +0800, Jitao Shi wrote:
> This patch add mt8183 mipi_tx driver.
> And also support other chips that use the same binding and driver.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/Makefile | 1 +
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 2 +
> drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 1 +
> drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 154 ++
> 4 files changed, 158 insertions(+)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
>
[snip]
> +
> +static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
> +{
> + struct mtk_mipi_tx *mipi_tx = mtk_mipi_tx_from_clk_hw(hw);
> + unsigned int txdiv, txdiv0;
> + u64 pcw;
> + int ret;
> +
> + dev_dbg(mipi_tx->dev, "prepare: %u bps\n", mipi_tx->data_rate);
> +
> + if (mipi_tx->data_rate >= 20) {
> + txdiv = 1;
> + txdiv0 = 0;
> + } else if (mipi_tx->data_rate >= 10) {
> + txdiv = 2;
> + txdiv0 = 1;
> + } else if (mipi_tx->data_rate >= 5) {
> + txdiv = 4;
> + txdiv0 = 2;
> + } else if (mipi_tx->data_rate > 25000) {
> + txdiv = 8;
> + txdiv0 = 3;
> + } else if (mipi_tx->data_rate >= 12500) {
> + txdiv = 16;
> + txdiv0 = 4;
> + } else {
> + return -EINVAL;
> + }
> +
> + ret = clk_prepare_enable(mipi_tx->ref_clk);
> + if (ret < 0) {
> + dev_err(mipi_tx->dev,
> + "can't prepare and enable mipi_tx ref_clk %d\n", ret);
> + return ret;
> + }
You enable the parent clock when prepare this clock here, this behavior
looks strange. I think the flow should be:
1. Parent clock prepare
2. This clock prepare
3. Parent clock enable
4. This clock enable
Maybe you should implement 'enable callback' so that parent clock would
be already enabled.
One question is, mipi_tx_pll is used by dsi driver, but I does not see
dsi prepare_enable() mipi_tx_pll, how does this work?
Regards,
CK
> +
> + mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_PLL_CON4, RG_DSI_PLL_IBIAS);
> +
> + mtk_mipi_tx_set_bits(mipi_tx, MIPITX_PLL_PWR, AD_DSI_PLL_SDM_PWR_ON);
> + usleep_range(30, 100);
> + mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_PLL_PWR, AD_DSI_PLL_SDM_ISO_EN);
> + pcw = div_u64(((u64)mipi_tx->data_rate * txdiv) << 24, 2600);
> + writel(pcw, mipi_tx->regs + MIPITX_PLL_CON0);
> + mtk_mipi_tx_update_bits(mipi_tx, MIPITX_PLL_CON1, RG_DSI_PLL_POSDIV,
> + txdiv0 << 8);
> + usleep_range(1000, 2000);
> + mtk_mipi_tx_set_bits(mipi_tx, MIPITX_PLL_CON1, RG_DSI_PLL_EN);
> +
> + return 0;
> +}
> +
> +static void mtk_mipi_tx_pll_unprepare(struct clk_hw *hw)
> +{
> + struct mtk_mipi_tx *mipi_tx = mtk_mipi_tx_from_clk_hw(hw);
> +
> + dev_dbg(mipi_tx->dev, "unprepare\n");
> +
> + mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_PLL_CON1, RG_DSI_PLL_EN);
> +
> + mtk_mipi_tx_set_bits(mipi_tx, MIPITX_PLL_PWR, AD_DSI_PLL_SDM_ISO_EN);
> + mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_PLL_PWR, AD_DSI_PLL_SDM_PWR_ON);
> + clk_disable_unprepare(mipi_tx->ref_clk);
> +}
> +
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/17] MAINTAINERS: add entry for KUnit the unit testing framework
On Fri, May 3, 2019 at 7:38 AM shuah wrote: > > On 5/1/19 5:01 PM, Brendan Higgins wrote: > > Add myself as maintainer of KUnit, the Linux kernel's unit testing > > framework. > > > > Signed-off-by: Brendan Higgins > > --- > > MAINTAINERS | 10 ++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 5c38f21aee787..c78ae95c56b80 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -8448,6 +8448,16 @@ S: Maintained > > F: tools/testing/selftests/ > > F: Documentation/dev-tools/kselftest* > > > > +KERNEL UNIT TESTING FRAMEWORK (KUnit) > > +M: Brendan Higgins > > +L: kunit-...@googlegroups.com > > +W: https://google.github.io/kunit-docs/third_party/kernel/docs/ > > +S: Maintained > > +F: Documentation/kunit/ > > +F: include/kunit/ > > +F: kunit/ > > +F: tools/testing/kunit/ > > + > > Please add kselftest mailing list to this entry, based on our > conversation on taking these patches through kselftest tree. Will do. Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/edid: drmP.h include removal
Continue to get rid of drmP.h. Add minimal includes to build. Sort includes while at it. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_edid.c | 11 +++ drivers/gpu/drm/drm_edid_load.c | 7 +-- 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 2c22ea4..f1632cb 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -27,16 +27,19 @@ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER * DEALINGS IN THE SOFTWARE. */ -#include -#include + #include #include +#include #include +#include #include -#include + +#include +#include #include #include -#include +#include #include #include "drm_crtc_internal.h" diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c index a491509..18d52dc 100644 --- a/drivers/gpu/drm/drm_edid_load.c +++ b/drivers/gpu/drm/drm_edid_load.c @@ -19,12 +19,15 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. */ -#include #include -#include +#include +#include + #include #include +#include #include +#include static char edid_firmware[PATH_MAX]; module_param_string(edid_firmware, edid_firmware, sizeof(edid_firmware), 0644); -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/dp: drmP.h include removal
Continue to get rid of drmP.h. Add minimal includes to build. Sort includes while at it. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_dp_aux_dev.c | 8 +--- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 4 +++- drivers/gpu/drm/drm_dp_helper.c | 12 +++- drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++-- 4 files changed, 22 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c b/drivers/gpu/drm/drm_dp_aux_dev.c index 0e4f25d..5be28e 100644 --- a/drivers/gpu/drm/drm_dp_aux_dev.c +++ b/drivers/gpu/drm/drm_dp_aux_dev.c @@ -27,15 +27,17 @@ #include #include -#include #include #include #include +#include +#include #include #include -#include + #include -#include +#include +#include #include "drm_crtc_helper_internal.h" diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c b/drivers/gpu/drm/drm_dp_dual_mode_helper.c index e7f4fe2..1c9ea9f 100644 --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c @@ -20,13 +20,15 @@ * OTHER DEALINGS IN THE SOFTWARE. */ +#include #include #include #include #include #include + #include -#include +#include /** * DOC: dp dual mode helpers diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 54a641..e6af75 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -20,16 +20,18 @@ * OF THIS SOFTWARE. */ -#include -#include #include -#include #include -#include #include +#include +#include +#include +#include #include + #include -#include +#include +#include #include "drm_crtc_helper_internal.h" diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index c630ed..da1abc 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -20,19 +20,20 @@ * OF THIS SOFTWARE. */ -#include #include -#include #include +#include +#include +#include #include #include -#include -#include -#include -#include #include #include +#include +#include +#include +#include #include /** -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/panel: simple: Add FriendlyELEC HD702E 800x1280 LCD panel
Hi Sam,
On Thu, May 2, 2019 at 1:04 AM Sam Ravnborg wrote:
>
> Hi Jagan
>
> On Wed, May 01, 2019 at 05:44:47PM +0530, Jagan Teki wrote:
> > HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
> > resolution. It has built in Goodix, GT9271 captive touchscreen
> > with backlight adjustable via PWM.
> >
> > Add support for it.
> >
> > Cc: Thierry Reding
> > Cc: Sam Ravnborg
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Jagan Teki
>
> Please submit the binding in a separate patch as per
> Documentation/devicetree/bindings/submitting-patches.txt
Hmm.. prepared like this initially but few of my patches were combined
earlier even-though I sent it separately. anyway let me separate it
again.
>
> The binding looks like it is compatible with common-panel and
> simple-panel - please say so in the bindings.
> See for example the last few binding documents added to the kernel tree.
Correct, will update.
>
> > ---
> > .../display/panel/friendlyarm,hd702e.txt | 29 +++
> > drivers/gpu/drm/panel/panel-simple.c | 26 +
> > 2 files changed, 55 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt
> > b/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt
> > new file mode 100644
> > index ..67349d7f79be
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt
> > @@ -0,0 +1,29 @@
> > +FriendlyELEC HD702E 800x1280 LCD panel
> > +
> > +HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
> > +resolution. It has built in Goodix, GT9271 captive touchscreen
> > +with backlight adjustable via PWM.
> > +
> > +Required properties:
> > +- compatible: should be "friendlyarm,hd702e"
> > +- power-supply: regulator to provide the supply voltage
> > +
> > +Optional properties:
> > +- backlight: phandle of the backlight device attached to the panel
> > +
> > +Optional nodes:
> > +- Video port for LCD panel input.
> > +
> > +Example:
> > +
> > + panel {
> > + compatible ="friendlyarm,hd702e";
> > + backlight = <&backlight>;
> > + power-supply = <&vcc3v3_sys>;
> > +
> > + port {
> > + panel_in_edp: endpoint {
> > + remote-endpoint = <&edp_out_panel>;
> > + };
> > + };
> > + };
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 9e8218f6a3f2..9db3c0c65ef2 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1184,6 +1184,29 @@ static const struct panel_desc
> > foxlink_fl500wvr00_a0t = {
> > .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> > };
> >
> > +static const struct drm_display_mode friendlyarm_hd702e_mode = {
> > + .clock = 67185,
> > + .hdisplay = 800,
> > + .hsync_start= 800 + 20,
> > + .hsync_end = 800 + 20 + 24,
> > + .htotal = 800 + 20 + 24 + 20,
> > + .vdisplay = 1280,
> > + .vsync_start= 1280 + 4,
> > + .vsync_end = 1280 + 4 + 8,
> > + .vtotal = 1280 + 4 + 8 + 4,
> > + .vrefresh = 60,
> > + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> > +};
> > +
> > +static const struct panel_desc friendlyarm_hd702e = {
> > + .modes = &friendlyarm_hd702e_mode,
> > + .num_modes = 1,
> > + .size = {
> > + .width = 94,
> > + .height = 151,
> > + },
> > +};
> As I read the datasheet then this panel needs at least a prepare delay
> of 10 ms (it says > 10 ms from VGH until Data).
> And then we also know that VGH shall be valid at least 10 ms after DVDD
> so prepare is likely 20 ms.
>
> Based on datasheet found here:
> https://pan.baidu.com/s/1geEfBLh/
>
> Please evaluate all delays.
This part I'm unclear, I tried to get the datasheet of this but
couldn't find it either. I have a reference for these FriendlyELEC
panels from
https://github.com/friendlyarm/kernel-rockchip/blob/nanopi4-linux-v4.4.y/drivers/gpu/drm/panel/panel-friendlyelec.c
but they are not using any of these delays.
>
> > +
> > static const struct drm_display_mode giantplus_gpg482739qs5_mode = {
> > .clock = 9000,
> > .hdisplay = 480,
> > @@ -2634,6 +2657,9 @@ static const struct of_device_id platform_of_match[]
> > = {
> > }, {
> > .compatible = "edt,etm0700g0edh6",
> > .data = &edt_etm0700g0bdh6,
> > + }, {
> > + .compatible = "friendlyarm,hd702e",
> > + .data = &friendlyarm_hd702e,
> > }, {
> > .compatible = "foxlink,fl500wvr00-a0t",
> > .data = &foxlink_fl500wvr00_a0t,
>
> Add these in sorted order.
>
Re: [PATCHv2 03/22] drm/bridge: tc358767: fix ansi 8b10b use
Hi Laurent, Andrey, On 03/05/2019 20:11, Laurent Pinchart wrote: >> I agree that if the panel Andrey mentioned is still used, we need to >> handle it somehow. But I think explicitly handling such a case is better >> than guessing. > > The risk may not be worth it, I agree. I would explain this in details > in the commit message though, and add a comment to the code as well, to > ease future debugging. Andrey, do you still have the panel that doesn't work with 8b10b? Is it used in real life (i.e. it was not just a temporary development phase panel)? What's the model, and is there a public datasheet? Everywhere I look, I always see 8b10b as mandatory for all DP versions for the main link. If the panel in question requires 8b10b to be disabled, I would imagine that mentioned in its datasheet, as it's kind of a big thing. I would guess that the panel doesn't work with many eDP sources. >> And isn't this something that's not really TC358767 specific? If that >> panel is used with other bridges, we need to deal with this case with >> those bridges too? Or is TC358767 the only bridge that allows disabling >> 8b10b? > > I don't know about other bridges, but I think it would need to be > handled globally, yes. Ok. This does sound like a relatively big work, adding a new field to simple panel, or maybe a new DT property to the panels, and making the bridges work use that data (even if we'd add the support only to tc358767 for now). I don't want to break Andrey's panel, but I have to say I'm not very enthusiastic about this work either =). The DP 1.0 spec does say that PRBS7 test pattern is not 8b10b encoded. I understand this meaning that 8b10b is not used for some particular tests, which would explain why 8b10b can be turned off in tc358767 (and maybe that also means it can be turned off in all/most other DP sources). 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
[Bug 108893] Slow redrawing of menu in Gothic 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=108893 --- Comment #17 from supercoolem...@seznam.cz --- Created attachment 144173 --> https://bugs.freedesktop.org/attachment.cgi?id=144173&action=edit sysprof of Gothic 2 menu -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108893] Slow redrawing of menu in Gothic 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=108893 --- Comment #18 from supercoolem...@seznam.cz --- Created attachment 144174 --> https://bugs.freedesktop.org/attachment.cgi?id=144174&action=edit sysprof of Gothic 2 menu with LIBGL_ALWAYS_SOFTWARE=1 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/12] drm/amdgpu: add independent DMA-buf export v3
Am 06.05.19 um 10:04 schrieb Daniel Vetter: > [SNIP] + /* pin buffer into GTT */ + return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT); >>> This is kinda what I mean with "shouldn't we pin the attachment" - afaiui >>> this can fail is someone already pinned the buffer into vram. And that >>> kind of checking is supposed to happen in the buffer attachment. >> Why is that supposed to happen on the attachment? I mean it could be nice to >> have for debugging, but I still don't see any practical reason for this. > dma_buf_attach is supposed to make sure the buffer won't land somewhere > where you can't get at it anymore. Wrt pin that means the exporter needs > to make sure it can't get pinned into a wrong place, and also isn't pinned > into a wrong place anymore. That's why I think pinning ties in with > dma_buf_attach and not the overall buffer. > > In a way there's two pieces of a pin: > - Do not move the buffer anymore. > - Make sure I can still get at it. > > Internally the 2nd part is encoded in the domain parameter you pass to > amdgpu_bo_pin. When going through dma-buf that information is derived > from the attachment (e.g. if it's a p2p one, then you can put it wherever > you feel like, if it's a normal one it must be in system ram). The dma-buf > alone doesn't tell you _where_ to pin something. Ok, that finally makes some sense. So the attachment describes where the buffer needs to be for the attaching device/use case to be able to access it. Going to change it to use an attachment instead. >> Well completely amdgpu internal handling here. Key point is we have both >> preferred_domains as well as allowed_domains. >> >> During command submission we always try to move a BO to the >> preferred_domains again. >> >> Now what could happen if we don't have this check is the following: >> >> 1. BO is allocate in VRAM. And preferred_domains says only VRAM please, but >> allowed_domains says VRAM or GTT. >> >> 2. DMA-buf Importer comes along and moves the BO to GTT, which is perfectly >> valid because of the allowed_domains. >> >> 3. Command submission is made and moves the BO to VRAM again. >> >> 4. Importer comes along and moves the BO to GTT. >> >> >> E.g. a nice ping/pong situation which just eats up memory bandwidth. > Hm yeah the ping/pong is bad, but I figure you have to already handle that > (with some bias or whatever). Outright disabling invalidate/dynamic > dma-buf seems like overkill. > > What about upgradging preferred_domains to include GTT here? Defacto what > you do is forcing GTT, so just adding GTT as a possible domain seems like > the better choice. Bonus points for undoing that when the last importer > disappears. Well that's exactly what we want to avoid here. The preferred_domains is where userspace likes the buffer to be and should never be changed by the kernel. The allowed_domains is where the buffer should be based on the hardware restrictions and is usually updated by the kernel driver. > In general I think dynamic dma-buf needs to be able to handle this > somehow, or it won't really work. Simplest is probably to just stop moving > buffers around so much for buffers that are dynamically exported (so maybe > could also change that in the CS ioctl to not move exported buffers > anymore, would achieve the same). Yeah, that's the obvious alternative. But I didn't wanted to add even more complexity to the patch right now. Cleaning this up is pure amdgpu internally, e.g. we need to make sure to not move buffers around so much on command submission. Christian. > -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
[Bug 109345] drm-next-2018-12-14 -Linux PPC
https://bugs.freedesktop.org/show_bug.cgi?id=109345 --- Comment #33 from Christian Zigotzky --- Hi All, Allan successfully tested the seventh test kernel today. He wrote: Christian DRM7 boots to SI card. ace -- This step has been marked as bad because the seventh test kernel doesn't boot to the FirePro. Next step: git bisect bad Output: Bisecting: 5 revisions left to test after this (roughly 3 steps) [e51767279f11571b112dbeaef2628968c62f90a6] drm/selftest: Refactor test-drm_plane_helper make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage Download: http://www.xenosoft.de/uImage-drm8 @Allan (acefnq/ace) Please test it. Thanks, Christian -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110619] Dump process stacktraces in case a test hangs
https://bugs.freedesktop.org/show_bug.cgi?id=110619 Bug ID: 110619 Summary: Dump process stacktraces in case a test hangs Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: imre.d...@intel.com Feature request (ideas from Chris) to help determining where a test gets stuck: - provide the stack traces off all existing processes (cat /proc/*/stack) in case of a timeout - ptrace all the child from the IGT runner and provide the trace in case of a timeout -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/dp: drmP.h include removal
Den 06.05.2019 11.52, skrev Jani Nikula: > Continue to get rid of drmP.h. Add minimal includes to build. Sort > includes while at it. > > Signed-off-by: Jani Nikula > --- Reviewed-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/edid: drmP.h include removal
Den 06.05.2019 11.52, skrev Jani Nikula: > Continue to get rid of drmP.h. Add minimal includes to build. Sort > includes while at it. > > Signed-off-by: Jani Nikula > --- Reviewed-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/19] Share TTM code among DRM framebuffer drivers
> GEM VRAM could implement PRIME helpers, which would allow for using > the generic fbcon. bochs_gem_prime_*() functions with this series applied look like you can just rename them & move over to vram helpers. It's not a full prime implementation, specifically actual export/import isn't there. But pin+vmap (needed by generic fbcon) is implemented. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/19] drm: Add |struct drm_gem_vram_object| and helpers
> +/**
> + * drm_gem_vram_unpin() - Unpins a GEM VRAM object
> + * @gbo: the GEM VRAM object
> + *
> + * Returns:
> + * 0 on success, or
> + * a negative error code otherwise.
> + */
> +int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
> +{
> + int i, ret;
> + struct ttm_operation_ctx ctx = { false, false };
> +
> + if (!gbo->pin_count)
> + return 0;
WARN_ON_ONCE() here? That should not happen ...
> +/**
> + * drm_gem_vram_push_to_system() - \
> + Unpins a GEM VRAM object and moves it to system memory
> + * @gbo: the GEM VRAM object
> + *
> + * This operation only works if the caller holds the final pin on the
> + * buffer object.
> + *
> + * Returns:
> + * 0 on success, or
> + * a negative error code otherwise.
> + */
> +int drm_gem_vram_push_to_system(struct drm_gem_vram_object *gbo)
> +{
> + int i, ret;
> + struct ttm_operation_ctx ctx = { false, false };
> +
> + if (!gbo->pin_count)
> + return 0;
Likewise.
> + --gbo->pin_count;
> + if (gbo->pin_count)
> + return 0;
> +
> + if (gbo->kmap.virtual)
> + ttm_bo_kunmap(&gbo->kmap);
> +
> + drm_gem_vram_placement(gbo, TTM_PL_FLAG_SYSTEM);
> + for (i = 0; i < gbo->placement.num_placement ; ++i)
> + gbo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
> +
> + ret = ttm_bo_validate(&gbo->bo, &gbo->placement, &ctx);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_gem_vram_push_to_system);
Very simliar to drm_gem_vram_unpin, can't we just call that function?
Something like this:
drm_gem_vram_push_to_system()
{
if (gbo->pin_count == 1 && gbo->kmap.virtual)
ttm_bo_kunmap(&gbo->kmap);
return drm_gem_vram_unpin();
}
> +struct drm_gem_vram_object {
> + /* Supported placements are %TTM_PL_VRAM and %TTM_PL_SYSTEM */
> + struct ttm_placement placement;
> + struct ttm_place placements[3];
placements[2] should be enough I guess?
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/19] Share TTM code among DRM framebuffer drivers
On Mon, May 06, 2019 at 10:26:30AM +0200, Thomas Zimmermann wrote:
> Several simple framebuffer drivers copy most of the TTM code from each
> other. The implementation is always the same; except for the name of
> some data structures.
>
> As recently discussed, this patch set provides generic memory-management
> code for simple framebuffers with dedicated video memory. It further
> converts the respective drivers to the generic code. The shared code
> is basically the same implementation as the one copied among individual
> drivers.
>
> The patch set contains two major changes: first, it introduces
> |struct drm_gem_vram_object| and helpers (GEM VRAM). It's a GEM object
> that is backed by VRAM. The type's purpose is somewhat similar to
> |struct drm_gem_{cma, shmem}_object|: it provides an commom implementation
> that handles all the basic cases. Second, the patch set introduces
> |struct drm_vram_mm| and helpers (VRAM MM). It's an implementation of a
> basic memory manager for VRAM.
>
> Both, GEM VRAM and VRAM MM, support buffer placement in VRAM and system
> memory. Both can be used independedly from each other if desired by the
> DRM driver.
Looks good to me overall, some small nits in replies to patches.
> Currently ast, bochs, mgag200, vboxvideo and hisilicon/hibmc can use
> these helpers.
I've tested bochs on qemu, works fine.
What is the testing status of the other drivers?
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110621] inbox is going to blank page
https://bugs.freedesktop.org/show_bug.cgi?id=110621 abcd changed: What|Removed |Added Priority|medium |high Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: use-after-free Read in add_uevent_var
> > The bug was bisected to: > > > > commit 0a1c7959acd9674a0e4e59f911f3e5fbf25fd693 > > Author: Wolfram Sang > > Date: Wed May 17 15:22:18 2017 + > > > > gpu: drm: tc35876x: move header file out of I2C realm > > Bisect seems to have gone off the rails. No idea where or why. Yes, luckily it was obvious here, saving us from chasing ghosts. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 12/19] drm/bochs: Convert bochs driver to VRAM MM
Hi,
> static const struct file_operations bochs_fops = {
> .owner = THIS_MODULE,
> - .open = drm_open,
> - .release= drm_release,
> - .unlocked_ioctl = drm_ioctl,
> - .compat_ioctl = drm_compat_ioctl,
> - .poll = drm_poll,
> - .read = drm_read,
> .llseek = no_llseek,
> - .mmap = bochs_mmap,
> + DRM_VRAM_MM_FILE_OPERATIONS
> };
What about llseek? I think it should either be deleted (if not needed)
or added to DRM_VRAM_MM_FILE_OPERATIONS (if needed).
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110621] inbox is going to blank page
https://bugs.freedesktop.org/show_bug.cgi?id=110621 abcd changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/19] drm: Add |struct drm_gem_vram_object| and helpers
Hi
thanks for reviewing the patches.
Am 06.05.19 um 14:31 schrieb Gerd Hoffmann:
>> +--gbo->pin_count;
>> +if (gbo->pin_count)
>> +return 0;
>> +
>> +if (gbo->kmap.virtual)
>> +ttm_bo_kunmap(&gbo->kmap);
>> +
>> +drm_gem_vram_placement(gbo, TTM_PL_FLAG_SYSTEM);
>> +for (i = 0; i < gbo->placement.num_placement ; ++i)
>> +gbo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
>> +
>> +ret = ttm_bo_validate(&gbo->bo, &gbo->placement, &ctx);
>> +if (ret)
>> +return ret;
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(drm_gem_vram_push_to_system);
>
> Very simliar to drm_gem_vram_unpin, can't we just call that function?
>
> Something like this:
>
> drm_gem_vram_push_to_system()
> {
> if (gbo->pin_count == 1 && gbo->kmap.virtual)
> ttm_bo_kunmap(&gbo->kmap);
> return drm_gem_vram_unpin();
> }
This misses the call to drm_gem_vram_placement(), where
drm_gem_vram_push_to_system() enforces placement in system memory. We
could build a common implementation out of both interfaces, but that
would obfuscate the code IMHO. I'd just leave it as it is.
The function is only used by ast and mgag200 framebuffer handling. It's
actually something that should be done by VRAM MM, but both drivers are
non-atomic and could require an overhaul anyway.
>> +struct drm_gem_vram_object {
>> +/* Supported placements are %TTM_PL_VRAM and %TTM_PL_SYSTEM */
>> +struct ttm_placement placement;
>> +struct ttm_place placements[3];
>
> placements[2] should be enough I guess?
TTM_PL_VRAM has index 2 and TTM_PL_SYSTEM has index 0. There's TTM_PL_TT
at index 1. We don't use all three array entries here, but I'm not sure
if something in TTM does. I took the line from the drivers and didn't
change it for that reason.
Best regards
Thomas
> cheers,
> Gerd
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110250] [Regression linux 5.1-rc1] Displayport 1.2 tty second monitor corruption
https://bugs.freedesktop.org/show_bug.cgi?id=110250 Sibren Vasse changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/19] Share TTM code among DRM framebuffer drivers
Hi
Am 06.05.19 um 14:43 schrieb Gerd Hoffmann:
> On Mon, May 06, 2019 at 10:26:30AM +0200, Thomas Zimmermann wrote:
>> Several simple framebuffer drivers copy most of the TTM code from each
>> other. The implementation is always the same; except for the name of
>> some data structures.
>>
>> As recently discussed, this patch set provides generic memory-management
>> code for simple framebuffers with dedicated video memory. It further
>> converts the respective drivers to the generic code. The shared code
>> is basically the same implementation as the one copied among individual
>> drivers.
>>
>> The patch set contains two major changes: first, it introduces
>> |struct drm_gem_vram_object| and helpers (GEM VRAM). It's a GEM object
>> that is backed by VRAM. The type's purpose is somewhat similar to
>> |struct drm_gem_{cma, shmem}_object|: it provides an commom implementation
>> that handles all the basic cases. Second, the patch set introduces
>> |struct drm_vram_mm| and helpers (VRAM MM). It's an implementation of a
>> basic memory manager for VRAM.
>>
>> Both, GEM VRAM and VRAM MM, support buffer placement in VRAM and system
>> memory. Both can be used independedly from each other if desired by the
>> DRM driver.
>
> Looks good to me overall, some small nits in replies to patches.
>
>> Currently ast, bochs, mgag200, vboxvideo and hisilicon/hibmc can use
>> these helpers.
>
> I've tested bochs on qemu, works fine.
Thank you!
> What is the testing status of the other drivers?
I've tested ast and mgag200 on hardware. I only compiled the others,
including bochs. I did verify that the code I replaced is basically the
same as in the new helpers.
Best regards
Thomas
> cheers,
> Gerd
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/19] Share TTM code among DRM framebuffer drivers
Hi Am 06.05.19 um 14:22 schrieb Gerd Hoffmann: >> GEM VRAM could implement PRIME helpers, which would allow for using >> the generic fbcon. > > bochs_gem_prime_*() functions with this series applied look like you can > just rename them & move over to vram helpers. > > It's not a full prime implementation, specifically actual export/import > isn't there. But pin+vmap (needed by generic fbcon) is implemented. I did have a patch to do this, but then I read that prime requires DMA for buffer sharing and bochs works only because it's emulated. If bochs' implementation is complete enough to be useful for other drivers, I'll add it to the patch set. Best regards Thomas > cheers, > Gerd > -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/dp: drmP.h include removal
On Mon, 06 May 2019, Noralf Trønnes wrote: > Den 06.05.2019 11.52, skrev Jani Nikula: >> Continue to get rid of drmP.h. Add minimal includes to build. Sort >> includes while at it. >> >> Signed-off-by: Jani Nikula >> --- > > Reviewed-by: Noralf Trønnes Pushed both to drm-misc-next, thanks for the review. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
