[Bug 107655] X segfaults on startup in r300_dri.so, making system unusable
https://bugs.freedesktop.org/show_bug.cgi?id=107655 --- Comment #2 from Sergey Kondakov --- Created attachment 141238 --> https://bugs.freedesktop.org/attachment.cgi?id=141238&action=edit Asus_F3Ke.dmesg dmesg from affected machine. -- 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 107655] X segfaults on startup in r300_dri.so, making system unusable
https://bugs.freedesktop.org/show_bug.cgi?id=107655 --- Comment #1 from Sergey Kondakov --- Created attachment 141237 --> https://bugs.freedesktop.org/attachment.cgi?id=141237&action=edit Xorg.0.log Normal X log. -- 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 107655] X segfaults on startup in r300_dri.so, making system unusable
https://bugs.freedesktop.org/show_bug.cgi?id=107655 Bug ID: 107655 Summary: X segfaults on startup in r300_dri.so, making system unusable Product: Mesa Version: 18.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Drivers/Gallium/r300 Assignee: dri-devel@lists.freedesktop.org Reporter: virtuous...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 141236 --> https://bugs.freedesktop.org/attachment.cgi?id=141236&action=edit Xorg.pid-1154.gdb.log I have updated my old Asus F3Ke notebook with "ATI Mobility Radeon X2300 (ChipID = 0x718a)" after neglecting it for 1-2 years and now I can't launch desktop session because X immediately segfaults. This is what I was able to get after installing debug data and launching Xgdb script. -- 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 4/5] drm/amdgpu: use bulk moves for efficient VM LRU handling (v4)
On Tue, Aug 21, 2018 at 03:54:28PM +0200, Christian König wrote:
> Am 21.08.2018 um 15:43 schrieb Huang Rui:
> >On Mon, Aug 20, 2018 at 09:17:12PM +0800, Christian König wrote:
> >>Am 20.08.2018 um 08:05 schrieb Huang Rui:
> >>>On Fri, Aug 17, 2018 at 06:38:16PM +0800, Koenig, Christian wrote:
> Am 17.08.2018 um 12:08 schrieb Huang Rui:
> >I continue to work for bulk moving that based on the proposal by
> >Christian.
> >
> >Background:
> >amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then
> >move all of
> >them on the end of LRU list one by one. Thus, that cause so many BOs
> >moved to
> >the end of the LRU, and impact performance seriously.
> >
> >Then Christian provided a workaround to not move PD/PT BOs on LRU with
> >below
> >patch:
> >"drm/amdgpu: band aid validating VM PTs"
> >Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae
> >
> >However, the final solution should bulk move all PD/PT and PerVM BOs on
> >the LRU
> >instead of one by one.
> >
> >Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which
> >need to be
> >validated we move all BOs together to the end of the LRU without
> >dropping the
> >lock for the LRU.
> >
> >While doing so we note the beginning and end of this block in the LRU
> >list.
> >
> >Now when amdgpu_vm_validate_pt_bos() is called and we don't have
> >anything to do,
> >we don't move every BO one by one, but instead cut the LRU list into
> >pieces so
> >that we bulk move everything to the end in just one operation.
> >
> >Test data:
> >+--+-+---+---+
> >| |The Talos|Clpeak(OCL)|BusSpeedReadback(OCL)
> >|
> >| |Principle(Vulkan)| |
> >|
> >++
> >| | | |0.319 ms(1k) 0.314 ms(2K)
> >0.308 ms(4K) |
> >| Original | 147.7 FPS | 76.86 us |0.307 ms(8K) 0.310 ms(16K)
> >|
> >++
> >| Orignial + WA| | |0.254 ms(1K) 0.241 ms(2K)
> >|
> >|(don't move | 162.1 FPS | 42.15 us |0.230 ms(4K) 0.223 ms(8K)
> >0.204 ms(16K)|
> >|PT BOs on LRU)| | |
> >|
> >++
> >| Bulk move| 163.1 FPS | 40.52 us |0.244 ms(1K) 0.252 ms(2K)
> >0.213 ms(4K) |
> >| | | |0.214 ms(8K) 0.225 ms(16K)
> >|
> >+--+-+---+---+
> >
> >After test them with above three benchmarks include vulkan and opencl.
> >We can
> >see the visible improvement than original, and even better than original
> >with
> >workaround.
> >
> >v2: move all BOs include idle, relocated, and moved list to the end of
> >LRU and
> >put them together.
> >v3: remove unused parameter and use list_for_each_entry instead of the
> >one with
> >save entry.
> >v4: move the amdgpu_vm_move_to_lru_tail after command submission, at
> >that time,
> >all bo will be back on idle list.
> >
> >Signed-off-by: Christian König
> >Signed-off-by: Huang Rui
> >Tested-by: Mike Lothian
> >Tested-by: Dieter Nützel
> >Acked-by: Chunming Zhou
> >---
> >drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 11 ++
> >drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 71
> > ++
> >drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 11 +-
> >3 files changed, 75 insertions(+), 18 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >index 502b94f..9fbdf02 100644
> >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >@@ -1260,6 +1260,16 @@ static int amdgpu_cs_submit(struct
> >amdgpu_cs_parser *p,
> > return 0;
> >}
> >+static void amdgpu_cs_vm_move_on_lru(struct amdgpu_device *adev,
> >+ struct amdgpu_cs_parser *p)
> >+{
> >+struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
> >+struct amdgpu_vm *vm = &fpriv->vm;
> >+
> >+if (vm->validated)
> That check belongs inside amdgpu_vm_move_to_lru_tail().
>
> >+amdgpu_vm_move_to_lru_tail(adev, vm);
> >+}
> >+
> >int
Re: [PATCH v5 2/9] drm/exynos: move connector creation to attach callback
2018년 08월 21일 20:21에 Andrzej Hajda 이(가) 쓴 글:
> On 21.08.2018 07:27, Inki Dae wrote:
>>
>> 2018년 08월 20일 18:00에 Andrzej Hajda 이(가) 쓴 글:
>>> On 17.08.2018 03:56, Inki Dae wrote:
2018년 08월 13일 20:17에 Andrzej Hajda 이(가) 쓴 글:
> On 07.08.2018 10:53, Inki Dae wrote:
>> 2018년 07월 26일 00:46에 Andrzej Hajda 이(가) 쓴 글:
>>> From: Maciej Purski
>>>
>>> The current implementation assumes that the only possible peripheral
>>> device for DSIM is a panel. Using an output bridge child device
>>> should also be possible.
>>>
>>> If an output bridge is available, don't create a new connector.
>>> Instead, call drm_bridge_attach() and set encoder's bridge to NULL
>>> in order to avoid an out bridge from being visible by the framework, as
>>> the DSI bus needs control on enabling its child output bridge.
>>>
>>> Such sequence is required by Toshiba TC358764 bridge, which is a DSI
>>> peripheral bridge device.
>>>
>>> changed in v5:
>>> - detach bridge in mipi_dsi detach callback
>>>
>>> Signed-off-by: Maciej Purski
>>> [ a.ha...@samsung.com: v5 ]
>>> Signed-off-by: Andrzej Hajda
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 50 -
>>> 1 file changed, 32 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index 351403f9d245..f5f51f584fa0 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -255,6 +255,7 @@ struct exynos_dsi {
>>> struct mipi_dsi_host dsi_host;
>>> struct drm_connector connector;
>>> struct drm_panel *panel;
>>> + struct drm_bridge *out_bridge;
>>> struct device *dev;
>>>
>>> void __iomem *reg_base;
>>> @@ -1499,7 +1500,30 @@ static int exynos_dsi_host_attach(struct
>>> mipi_dsi_host *host,
>>> struct mipi_dsi_device *device)
>>> {
>>> struct exynos_dsi *dsi = host_to_dsi(host);
>>> - struct drm_device *drm = dsi->connector.dev;
>>> + struct drm_encoder *encoder = &dsi->encoder;
>>> + struct drm_device *drm = encoder->dev;
>>> + struct drm_bridge *out_bridge;
>>> +
>>> + out_bridge = of_drm_find_bridge(device->dev.of_node);
>> Is there any reason to find out_bridge without considering device tree
>> graph binding?
> If the sink is a child MIPI-DSI device, the bindings can be omitted, as
> in case of all DSI panels in Exynos platforms.
> In case bindings are not present you cannot use graph functions.
In other words, this means that this patch doesn't allow to use the device
tree graph binding.
I.e., if other people wrote the graph things in his board dts file for the
use of bridge device then with this patch he cannot use the bride device.
So I think it would be better to allow to use both of them, as a child
device and graph binding.
How about trying to bind the graph things using
drm_of_find_panel_or_bridge funtion first and then for child device way?
>>> It could be done this way, but it should be done for panels and for
>>> bridges, and it should be rather generic helper, not Exynos specific. So
>> As the function name says, drm_of_find_panel_or_bridge function will return
>> panel, bridge or both of them according to given arguments.
>>
>>
>>> it is something which require additional investigation, discussion and
>>> separate patchset.
>> So I think we wouldn't need additional discussion at all becuase we don't
>> touch panel but add only bridge device as output, and the use of this
>> function for bridge looks more generic way.
>
> But drm_of_find_panel_or_bridge is only for looking for non-dsi devices,
> or more specifically for looking for devices connected in DTS via
> DT-graph. This is not case of panels and bridges used in Exynos boards.
> So this function is currently useless with our boards. Maybe some day we
> will have bridge/panel controlled via I2C and then it will become
> useful, but for now it serves for nothing.
>
>> Of course, as a separate patch, we could consider using this function for
>> panel device later.
>
> As you said drm_of_find_panel_or_bridge looks for panel and/or bridge,
> and it was created to merge similar code in panel and bridge lookup,
> using it only for bridges and not for panels seems against it's purpose.
>
>>
>>> On the other side this patch is enough to correctly handle all DSI
>>> bridges in existing Exynos boards.
>>>
And I'm not clear about what kinds of devices could be a child device of
DSI, which isn't required for the graph binding.
Is there any document I can refer to?
>>> DSI devices (peripherals) should be described as child nodes of DSI host
>>> node in
RE: [RFC PATCH radeon-alex] drm/amdgpu: amdgpu_kiq_reg_write_reg_wait() can be static
Reviewed-by: Emily Deng
>-Original Message-
>From: kbuild test robot
>Sent: Wednesday, August 22, 2018 10:31 AM
>To: Deng, Emily
>Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Deucher, Alexander
>; Koenig, Christian
>
>Subject: [RFC PATCH radeon-alex] drm/amdgpu:
>amdgpu_kiq_reg_write_reg_wait() can be static
>
>
>Fixes: d790449835e6 ("drm/amdgpu: use kiq to do invalidate tlb")
>Signed-off-by: kbuild test robot
>---
> gmc_v9_0.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>index 0bf8439..4dd5769 100644
>--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>@@ -311,7 +311,7 @@ static uint32_t gmc_v9_0_get_invalidate_req(unsigned
>int vmid)
> return req;
> }
>
>-signed long amdgpu_kiq_reg_write_reg_wait(struct amdgpu_device *adev,
>+static signed long amdgpu_kiq_reg_write_reg_wait(struct amdgpu_device
>*adev,
> uint32_t reg0, uint32_t reg1,
> uint32_t ref, uint32_t mask)
> {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next-4.20-wip 175/184] drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:314:14: sparse: symbol 'amdgpu_kiq_reg_write_reg_wait' was not declared. Should it be static?
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip head: 2034a5eca0c640259d13dbd4c29ca8ce712055cc commit: d790449835e6f61831f6d34dea5b928de918cf60 [175/184] drm/amdgpu: use kiq to do invalidate tlb reproduce: # apt-get install sparse git checkout d790449835e6f61831f6d34dea5b928de918cf60 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:263:55: sparse: missing braces around initializer >> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:314:14: sparse: symbol >> 'amdgpu_kiq_reg_write_reg_wait' was not declared. Should it be static? drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:486:30: sparse: incorrect type in initializer (different address spaces) @@expected void [noderef] *ptr @@got sn:2>*ptr @@ drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:486:30:expected void [noderef] *ptr drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:486:30:got void * Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH radeon-alex] drm/amdgpu: amdgpu_kiq_reg_write_reg_wait() can be static
Fixes: d790449835e6 ("drm/amdgpu: use kiq to do invalidate tlb")
Signed-off-by: kbuild test robot
---
gmc_v9_0.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 0bf8439..4dd5769 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -311,7 +311,7 @@ static uint32_t gmc_v9_0_get_invalidate_req(unsigned int
vmid)
return req;
}
-signed long amdgpu_kiq_reg_write_reg_wait(struct amdgpu_device *adev,
+static signed long amdgpu_kiq_reg_write_reg_wait(struct amdgpu_device *adev,
uint32_t reg0, uint32_t reg1,
uint32_t ref, uint32_t mask)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next-4.20-wip 173/184] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c:74:36: sparse: missing braces around initializer
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip
head: 2034a5eca0c640259d13dbd4c29ca8ce712055cc
commit: 56aebc3d39a70b30eb06b911271b6bdf525f5f55 [173/184] drm/amd/display:
implement DPMS DTN test v2
reproduce:
# apt-get install sparse
git checkout 56aebc3d39a70b30eb06b911271b6bdf525f5f55
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c:74:36:
>> sparse: missing braces around initializer
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c:74:36:
>> sparse: missing braces around initializer
vim +74
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c
70
71 static unsigned int dcn10_get_hubbub_state(struct dc *dc, char *pBuf,
unsigned int bufSize)
72 {
73 struct dc_context *dc_ctx = dc->ctx;
> 74 struct dcn_hubbub_wm wm = {0};
75 int i;
76
77 unsigned int chars_printed = 0;
78 unsigned int remaining_buffer = bufSize;
79
80 const uint32_t ref_clk_mhz =
dc_ctx->dc->res_pool->ref_clock_inKhz / 1000;
81 static const unsigned int frac = 1000;
82
83 hubbub1_wm_read_state(dc->res_pool->hubbub, &wm);
84
85 chars_printed = snprintf_count(pBuf, remaining_buffer,
"wm_set_index,data_urgent,pte_meta_urgent,sr_enter,sr_exit,dram_clk_chanage\n");
86 remaining_buffer -= chars_printed;
87 pBuf += chars_printed;
88
89 for (i = 0; i < 4; i++) {
90 struct dcn_hubbub_wm_set *s;
91
92 s = &wm.sets[i];
93
94 chars_printed = snprintf_count(pBuf, remaining_buffer,
"%x,%d.%03d,%d.%03d,%d.%03d,%d.%03d,%d.%03d\n",
95 s->wm_set,
96 (s->data_urgent * frac) / ref_clk_mhz / frac,
(s->data_urgent * frac) / ref_clk_mhz % frac,
97 (s->pte_meta_urgent * frac) / ref_clk_mhz /
frac, (s->pte_meta_urgent * frac) / ref_clk_mhz % frac,
98 (s->sr_enter * frac) / ref_clk_mhz / frac,
(s->sr_enter * frac) / ref_clk_mhz % frac,
99 (s->sr_exit * frac) / ref_clk_mhz / frac,
(s->sr_exit * frac) / ref_clk_mhz % frac,
100 (s->dram_clk_chanage * frac) / ref_clk_mhz /
frac, (s->dram_clk_chanage * frac) / ref_clk_mhz % frac);
101 remaining_buffer -= chars_printed;
102 pBuf += chars_printed;
103 }
104
105 return bufSize - remaining_buffer;
106 }
107
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107581] Graphics Not Rendered Due to Missing 4.5 COMPAT Profile
https://bugs.freedesktop.org/show_bug.cgi?id=107581 --- Comment #15 from Timothy Arceri --- Created attachment 141230 --> https://bugs.freedesktop.org/attachment.cgi?id=141230&action=edit hack around layout qualifiers The next shader compilation problem is that they are applying layout qualifiers to function params. e.g void WriteTextureCacheFeedback( vec2 lCacheCoords, ivec2 lResolution, float lfDesiredMip, layout( r32i ) iimage2D lFeedbackMap, < uint liFeedbackIndex ) layout( r32i ) can only be applied to uniforms. I've attached another hack that together with the other hack makes the game playable for me. -- 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 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #59 from dwagner --- Created attachment 141228 --> https://bugs.freedesktop.org/attachment.cgi?id=141228&action=edit latest crash trace output, without gpu_reset -- 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 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #58 from dwagner --- Here comes another trace log, with your info2.patch applied. Something must have changed since the last test, as it took pretty long this time to reproduce the crash. Could that have been caused by https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c?h=amd-staging-drm-next&id=b385925f3922faca7435e50e31380bb2602fd6b8 now being part of the kernel? However, the latest trace you find attached below is not much different to the last one, xzcat /tmp/gpu_debug5.txt.xz | grep '^\[' will tell you: [ 1510.023112] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=475104, emitted seq=475106 [ 1510.023117] [drm] GPU recovery disabled. amdgpu_cs:0-806 [012] 1787.493126: amdgpu_vm_bo_cs: soffs=1001a0, eoffs=1001b9, flags=70 amdgpu_cs:0-806 [012] 1787.493127: amdgpu_vm_bo_cs: soffs=100200, eoffs=1021e0, flags=70 amdgpu_cs:0-806 [012] 1787.493127: amdgpu_vm_bo_cs: soffs=102200, eoffs=1041e0, flags=70 amdgpu_cs:0-806 [012] 1787.493129: amdgpu_vm_bo_cs: soffs=10c1e0, eoffs=10c2e1, flags=70 amdgpu_cs:0-806 [012] 1787.493131: drm_sched_job: entity=406345a7, id=10239, fence=7a120377, ring=gfx, job count:8, hw job count:0 And later in the file you can find: -- crash detected! executing umr -O halt_waves -wa No active waves! executing umr -O verbose -R gfx[.] polaris11.gfx.rptr == 512 polaris11.gfx.wptr == 512 polaris11.gfx.drv_wptr == 512 polaris11.gfx.ring[ 481] == 0x1000... polaris11.gfx.ring[ 482] == 0x1000... polaris11.gfx.ring[ 483] == 0x1000... polaris11.gfx.ring[ 484] == 0x1000... polaris11.gfx.ring[ 485] == 0x1000... polaris11.gfx.ring[ 486] == 0x1000... polaris11.gfx.ring[ 487] == 0x1000... polaris11.gfx.ring[ 488] == 0x1000... polaris11.gfx.ring[ 489] == 0x1000... polaris11.gfx.ring[ 490] == 0x1000... polaris11.gfx.ring[ 491] == 0x1000... polaris11.gfx.ring[ 492] == 0x1000... polaris11.gfx.ring[ 493] == 0x1000... polaris11.gfx.ring[ 494] == 0x1000... polaris11.gfx.ring[ 495] == 0x1000... polaris11.gfx.ring[ 496] == 0x1000... polaris11.gfx.ring[ 497] == 0x1000... polaris11.gfx.ring[ 498] == 0x1000... polaris11.gfx.ring[ 499] == 0x1000... polaris11.gfx.ring[ 500] == 0x1000... polaris11.gfx.ring[ 501] == 0x1000... polaris11.gfx.ring[ 502] == 0x1000... polaris11.gfx.ring[ 503] == 0x1000... polaris11.gfx.ring[ 504] == 0x1000... polaris11.gfx.ring[ 505] == 0x1000... polaris11.gfx.ring[ 506] == 0x1000... polaris11.gfx.ring[ 507] == 0x1000... polaris11.gfx.ring[ 508] == 0x1000... polaris11.gfx.ring[ 509] == 0x1000... polaris11.gfx.ring[ 510] == 0x1000... polaris11.gfx.ring[ 511] == 0x1000... polaris11.gfx.ring[ 512] == 0xc0032200rwD trying to get ADR from dmesg output for 'umr -O verbose -vm ...' trying to get VMID from dmesg output for 'umr -O verbose -vm ...' done after crash. --- So even without GPU reset, still no "waves". And the error message also does not state any VM fault address. -- 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
[radeon-alex:drm-next-4.20-wip 168/184] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_hw.c:809:67: sparse: dubious: x | !y
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip
head: 2034a5eca0c640259d13dbd4c29ca8ce712055cc
commit: 14dc68a3fb45425643b608aee8c4fb9f7145c99e [168/184] drm/amd/display:
Create new i2c resource
reproduce:
# apt-get install sparse
git checkout 14dc68a3fb45425643b608aee8c4fb9f7145c99e
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_hw.c:89:6: sparse:
symbol 'dce_i2c_hw_engine_acquire_engine' was not declared. Should it be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_hw.c:113:6: sparse:
symbol 'dce_i2c_engine_acquire_hw' was not declared. Should it be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_hw.c:301:35: sparse:
symbol 'dce_i2c_hw_engine_wait_on_operation_result' was not declared. Should it
be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_hw.c:369:10: sparse:
symbol 'get_reference_clock' was not declared. Should it be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_hw.c:677:6: sparse:
symbol 'dce_i2c_hw_engine_submit_request' was not declared. Should it be static?
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_hw.c:809:67: sparse:
>> dubious: x | !y
--
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_sw.c:73:35: sparse:
symbol 'dce_i2c_sw_engine_get_channel_status' was not declared. Should it be
static?
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_sw.c:371:6: sparse:
symbol 'dce_i2c_sw_engine_set_speed' was not declared. Should it be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_sw.c:385:6: sparse:
symbol 'dce_i2c_sw_engine_acquire_engine' was not declared. Should it be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_sw.c:401:6: sparse:
symbol 'dce_i2c_engine_acquire_sw' was not declared. Should it be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_sw.c:429:6: sparse:
symbol 'dce_i2c_sw_engine_submit_channel_request' was not declared. Should it
be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_sw.c:472:6: sparse:
symbol 'dce_i2c_sw_engine_submit_request' was not declared. Should it be static?
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_sw.c:566:67: sparse:
>> dubious: x | !y
vim +809 drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_hw.c
782
783 bool dce_i2c_submit_command_hw(
784 struct resource_pool *pool,
785 struct ddc *ddc,
786 struct i2c_command *cmd,
787 struct dce_i2c_hw *dce_i2c_hw)
788 {
789 uint8_t index_of_payload = 0;
790 bool result;
791
792 dce_i2c_hw->funcs->set_speed(dce_i2c_hw, cmd->speed);
793
794 result = true;
795
796 while (index_of_payload < cmd->number_of_payloads) {
797 bool mot = (index_of_payload != cmd->number_of_payloads
- 1);
798
799 struct i2c_payload *payload = cmd->payloads +
index_of_payload;
800
801 struct dce_i2c_transaction_request request = { 0 };
802
803 request.operation = payload->write ?
804 DCE_I2C_TRANSACTION_WRITE :
805 DCE_I2C_TRANSACTION_READ;
806
807 request.payload.address_space =
808 DCE_I2C_TRANSACTION_ADDRESS_SPACE_I2C;
> 809 request.payload.address = (payload->address << 1) |
810 !payload->write;
811 request.payload.length = payload->length;
812 request.payload.data = payload->data;
813
814
815 if (!dce_i2c_hw_engine_submit_request(
816 dce_i2c_hw, &request, mot)) {
817 result = false;
818 break;
819 }
820
821
822
823 ++index_of_payload;
824 }
825
826 release_engine_dce_hw(pool, dce_i2c_hw);
827
828 return result;
829 }
830 static const struct dce_i2c_hw_funcs dce100_i2c_hw_funcs = {
831 .setup_engine = setup_engine_hw_dce100,
832 .set_speed = set_speed_hw_dce100,
833 .get_speed = get_speed_hw,
834 .release_engine = release_engine_hw,
835 .process_transaction = process_transaction_hw_dce100,
836 .process_channel_reply =
process_channel_reply_hw_dce100,
837 .is_hw_busy = is_hw_busy,
838 .get_channel_status = get_channel_status_hw,
839 .execute_transaction = execute_transaction_hw,
840 .disable_i2c_hw_engine = disable_i2c_hw_engine
841 };
Re: [RFC] clk: imx6: Mark imx_clk_mux as glitchy by default
Hi Leonard,
On Tue, Aug 21, 2018 at 4:34 PM, Leonard Crestez
wrote:
> More concretely on 6qp-sdb blanking the display happens like this:
> * imx_ldb_encoder_disable switches ipu1_di0_sel to ipu1_di0_pre from
> ldb_di1_podf
> * reparenting to ipu1_di0_pre enables it and its parents up to pll5
> * possibly glitchy muxing
> * ipu_di_disable disables ipu1_di0 (and parents, up to pll5)
Have you seen such glitch issue in practice with the LDB clocks?
We have already taken care of it in these commits:
commit 5d283b083800867dc329e6433576664bf0fc18d5
Author: Fabio Estevam
Date: Mon Oct 17 22:29:14 2016 -0200
clk: imx6: Fix procedure to switch the parent of LDB_DI_CLK
Due to incorrect placement of the clock gate cell in the ldb_di[x]_clk
tree, the glitchy parent mux of ldb_di[x]_clk can cause a glitch to
enter the ldb_di_ipu_div divider. If the divider gets locked up, no
ldb_di[x]_clk is generated, and the LVDS display will hang when the
ipu_di_clk is sourced from ldb_di_clk.
To fix the problem, both the new and current parent of the ldb_di_clk
should be disabled before the switch. This patch ensures that correct
steps are followed when ldb_di_clk parent is switched in the beginning
of boot. The glitchy muxes are then registered as read-only. The clock
parent can be selected using the assigned-clocks and
assigned-clock-parents properties of the ccm device tree node:
&clks {
assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
<&clks IMX6QDL_CLK_LDB_DI1_SEL>;
assigned-clock-parents = <&clks IMX6QDL_CLK_MMDC_CH1_AXI>,
<&clks IMX6QDL_CLK_PLL5_VIDEO_DIV>;
};
The issue is explained in detail in EB821 ("LDB Clock Switch Procedure &
i.MX6 Asynchronous Clock Switching Guidelines") [1].
[1] http://www.nxp.com/files/32bit/doc/eng_bulletin/EB821.pdf
Signed-off-by: Ranjani Vaidyanathan
Signed-off-by: Fabio Estevam
Signed-off-by: Philipp Zabel
Reviewed-by: Akshay Bhat
Tested-by Joshua Clayton
Tested-by: Charles Kang
Signed-off-by: Shawn Guo
commit 03d576f202e8cd40d500aa4f7594ad702d861096
Author: Philipp Zabel
Date: Mon Oct 17 22:29:13 2016 -0200
clk: imx6: Make the LDB_DI0 and LDB_DI1 clocks read-only
Due to incorrect placement of the clock gate cell in the ldb_di[x]_clk
tree, the glitchy parent mux of ldb_di[x]_clk can cause a glitch to
enter the ldb_di_ipu_div divider. If the divider gets locked up, no
ldb_di[x]_clk is generated, and the LVDS display will hang when the
ipu_di_clk is sourced from ldb_di_clk.
To fix the problem, both the new and current parent of the ldb_di_clk
should be disabled before the switch. As this can not be guaranteed by
the clock framework during runtime, make the ldb_di[x]_sel muxes read-only.
A workaround to set the muxes once during boot could be added to the
kernel or bootloader.
Signed-off-by: Philipp Zabel
Signed-off-by: Fabio Estevam
Signed-off-by: Shawn Guo
,but I think we should also take care of the other glitchy muxes as
you propose here.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next-4.20-wip 173/184] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c:74:9: warning: missing braces around initializer
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip
head: 2034a5eca0c640259d13dbd4c29ca8ce712055cc
commit: 56aebc3d39a70b30eb06b911271b6bdf525f5f55 [173/184] drm/amd/display:
implement DPMS DTN test v2
config: i386-randconfig-h1-08211342 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 56aebc3d39a70b30eb06b911271b6bdf525f5f55
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c:
In function 'dcn10_get_hubbub_state':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c:74:9:
>> warning: missing braces around initializer [-Wmissing-braces]
struct dcn_hubbub_wm wm = {0};
^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c:74:9:
warning: (near initialization for 'wm.sets') [-Wmissing-braces]
vim +74
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c
70
71 static unsigned int dcn10_get_hubbub_state(struct dc *dc, char *pBuf,
unsigned int bufSize)
72 {
73 struct dc_context *dc_ctx = dc->ctx;
> 74 struct dcn_hubbub_wm wm = {0};
75 int i;
76
77 unsigned int chars_printed = 0;
78 unsigned int remaining_buffer = bufSize;
79
80 const uint32_t ref_clk_mhz =
dc_ctx->dc->res_pool->ref_clock_inKhz / 1000;
81 static const unsigned int frac = 1000;
82
83 hubbub1_wm_read_state(dc->res_pool->hubbub, &wm);
84
85 chars_printed = snprintf_count(pBuf, remaining_buffer,
"wm_set_index,data_urgent,pte_meta_urgent,sr_enter,sr_exit,dram_clk_chanage\n");
86 remaining_buffer -= chars_printed;
87 pBuf += chars_printed;
88
89 for (i = 0; i < 4; i++) {
90 struct dcn_hubbub_wm_set *s;
91
92 s = &wm.sets[i];
93
94 chars_printed = snprintf_count(pBuf, remaining_buffer,
"%x,%d.%03d,%d.%03d,%d.%03d,%d.%03d,%d.%03d\n",
95 s->wm_set,
96 (s->data_urgent * frac) / ref_clk_mhz / frac,
(s->data_urgent * frac) / ref_clk_mhz % frac,
97 (s->pte_meta_urgent * frac) / ref_clk_mhz /
frac, (s->pte_meta_urgent * frac) / ref_clk_mhz % frac,
98 (s->sr_enter * frac) / ref_clk_mhz / frac,
(s->sr_enter * frac) / ref_clk_mhz % frac,
99 (s->sr_exit * frac) / ref_clk_mhz / frac,
(s->sr_exit * frac) / ref_clk_mhz % frac,
100 (s->dram_clk_chanage * frac) / ref_clk_mhz /
frac, (s->dram_clk_chanage * frac) / ref_clk_mhz % frac);
101 remaining_buffer -= chars_printed;
102 pBuf += chars_printed;
103 }
104
105 return bufSize - remaining_buffer;
106 }
107
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #57 from Andrey Grodzovsky --- (In reply to dwagner from comment #56) > (In reply to Andrey Grodzovsky from comment #55) > > > In above attached file "xz-compressed output of gpu_debug3.sh" there is > > > umr > > > output at the time of the crash (238 seconds after the reboot): > > > > > > -- > > > ... > > > mpv/vo-897 [005] 235.191542: dma_fence_wait_start: > > > driver=drm_sched timeline=gfx context=162 seqno=87 > > > mpv/vo-897 [005] d... 235.191548: dma_fence_enable_signal: > > > driver=drm_sched timeline=gfx context=162 seqno=87 > > > kworker/0:2-92[000] 238.275988: dma_fence_signaled: > > > driver=amdgpu timeline=sdma1 context=11 seqno=210 > > > kworker/0:2-92[000] 238.276004: dma_fence_signaled: > > > driver=amdgpu timeline=sdma1 context=11 seqno=211 > > > [ 238.180634] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 > > > timeout, signaled seq=32624, emitted seq=32626 > > > [ 238.180641] amdgpu :0a:00.0: GPU reset begin! > > > [ 238.180641] amdgpu :0a:00.0: GPU reset begin! > > > > > > crash detected! > > > > > > executing umr -O halt_waves -wa > > > No active waves! > > > > Did you use amdgpu.vm_fault_stop=2 parameter ? In case a fault happened that > > should have froze GPUs compute units and hence the above command would > > produce a lot of wave info. > > Yes I did, as can be seen from the kernel command line at the very beginning > of the file I attached: > [0.00] Command line: BOOT_IMAGE=/vmlinuz-linux_amd > root=UUID=b5d56e15-18f3-4783-af84-bbff3bbff3ef rw > cryptdevice=/dev/nvme0n1p2:root:allow-discards libata.force=1.5 video=DP-1:d > video=DVI-D-1:d video=HDMI-A-1:1024x768 amdgpu.dc=1 amdgpu.vm_update_mode=0 > amdgpu.dpm=-1 amdgpu.ppfeaturemask=0x amdgpu.vm_fault_stop=2 > amdgpu.vm_debug=1 > > Could the "amdgpu :0a:00.0: GPU reset begin!" message indicate a > procedure that discards whatever has been in thoses "waves" before? If yes, > could amdgpu.gpu_recovery=0 prevent that from happening? Yes, missed that one. No resets. -- 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 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #56 from dwagner --- (In reply to Andrey Grodzovsky from comment #55) > > In above attached file "xz-compressed output of gpu_debug3.sh" there is umr > > output at the time of the crash (238 seconds after the reboot): > > > > -- > > ... > > mpv/vo-897 [005] 235.191542: dma_fence_wait_start: > > driver=drm_sched timeline=gfx context=162 seqno=87 > > mpv/vo-897 [005] d... 235.191548: dma_fence_enable_signal: > > driver=drm_sched timeline=gfx context=162 seqno=87 > > kworker/0:2-92[000] 238.275988: dma_fence_signaled: > > driver=amdgpu timeline=sdma1 context=11 seqno=210 > > kworker/0:2-92[000] 238.276004: dma_fence_signaled: > > driver=amdgpu timeline=sdma1 context=11 seqno=211 > > [ 238.180634] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 > > timeout, signaled seq=32624, emitted seq=32626 > > [ 238.180641] amdgpu :0a:00.0: GPU reset begin! > > [ 238.180641] amdgpu :0a:00.0: GPU reset begin! > > > > crash detected! > > > > executing umr -O halt_waves -wa > > No active waves! > > Did you use amdgpu.vm_fault_stop=2 parameter ? In case a fault happened that > should have froze GPUs compute units and hence the above command would > produce a lot of wave info. Yes I did, as can be seen from the kernel command line at the very beginning of the file I attached: [0.00] Command line: BOOT_IMAGE=/vmlinuz-linux_amd root=UUID=b5d56e15-18f3-4783-af84-bbff3bbff3ef rw cryptdevice=/dev/nvme0n1p2:root:allow-discards libata.force=1.5 video=DP-1:d video=DVI-D-1:d video=HDMI-A-1:1024x768 amdgpu.dc=1 amdgpu.vm_update_mode=0 amdgpu.dpm=-1 amdgpu.ppfeaturemask=0x amdgpu.vm_fault_stop=2 amdgpu.vm_debug=1 Could the "amdgpu :0a:00.0: GPU reset begin!" message indicate a procedure that discards whatever has been in thoses "waves" before? If yes, could amdgpu.gpu_recovery=0 prevent that from happening? -- 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 107652] amdgpu couldn't resume after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=107652 --- Comment #1 from mikhail.v.gavri...@gmail.com --- Created attachment 141226 --> https://bugs.freedesktop.org/attachment.cgi?id=141226&action=edit system log -- 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 107652] amdgpu couldn't resume after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=107652 Bug ID: 107652 Summary: amdgpu couldn't resume after suspend Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mikhail.v.gavri...@gmail.com Created attachment 141225 --> https://bugs.freedesktop.org/attachment.cgi?id=141225&action=edit dmesg Steps for reproduce: 1) Put the computer into suspend mode. 2) Wake up the computer with the Power button. $ inxi -bM System:Host: localhost.localdomain Kernel: 4.19.0-0.rc0.git3.1.fc30.x86_64 x86_64 bits: 64 Desktop: Gnome 3.29.90 Distro: Fedora release 29 (Rawhide) Machine: Type: Desktop Mobo: ASUSTeK model: ROG STRIX X470-I GAMING v: Rev 1.xx serial: UEFI: American Megatrends v: 0901 date: 07/23/2018 CPU: 8-Core: AMD Ryzen 7 2700X type: MT MCP speed: 3381 MHz min/max: 2200/3700 MHz Graphics: Card-1: Advanced Micro Devices [AMD/ATI] Vega 10 XT [Radeon RX Vega 64] driver: amdgpu v: kernel Display: wayland server: Fedora Project X.org 11.0 driver: amdgpu resolution: 3840x2160~60Hz OpenGL: renderer: Radeon RX Vega (VEGA10 DRM 3.27.0 4.19.0-0.rc0.git3.1.fc30.x86_64 LLVM 6.0.1) v: 4.5 Mesa 18.1.5 Network: Card-1: Intel I211 Gigabit Network driver: igb Card-2: Realtek RTL8822BE 802.11a/b/g/n/ac WiFi adapter driver: r8822be Drives:Local Storage: total: 11.35 TiB used: 4.39 TiB (38.6%) Info: Processes: 575 Uptime: 2h 00m Memory: 31.36 GiB used: 28.11 GiB (89.6%) Shell: bash inxi: 3.0.20 -- 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: [Mesa-dev] XDC 2018: Call for Papers
Hi all, We received an overwhelming response for this CFP - 35+ proposals (and still some latecomers trickling in), for only 18 slots. What we didn't much get (and the CFP failed to make it clear that we're looking for this) is proposals for the workshop/discussion track in the 2nd room. In the past we scheduled that ad-hoc at the conference, but this year it would make sense to organize this. Especially since we expect a lot of the talks we had to reject to end up in hallway discussions. Formal workshop submissions also help us in scheduling the main track - anything that's expected to generate a lot of discussions will be put early. Right now we have 1 proposal for the workshop track. We'd like to have more. For details please look at "Workshop Track" at https://www.x.org/wiki/Events/PapersCommittee/ If you have a topic, please send your proposal to bo...@foundation.lists.org. Thanks, Daniel On Mon, Apr 2, 2018 at 12:47 PM, Samuel Iglesias Gonsálvez wrote: > Hello, > > I have the pleasure to announce that the X.org Developer Conference 2018 > will be held in A Coruña, Spain from September 26th to September 28th. > The venue is located at the Computer Science faculty of the University > of Coruña. > > This year, we have created a new website for the event: > > https://xdc2018.x.org > > And a Twitter account for announcing updates, please follow us! > > https://twitter.com/xdc2018 > > However, we are going to keep updating the good old wiki too: > > https://www.x.org/wiki/Events/XDC2018 > > As usual, we are open to talks across the layers of the graphics stack, > from the kernel to desktop environments / graphical applications and > about how to make things better for the developers who build them. Other > topics such as Virtual Reality are also welcome. If you're not sure if > something might fit, mail us or add it to the ideas list found in the > program page at: > > https://www.x.org/wiki/Events/XDC2018/Program/ > > The Call for Papers information is here: https://xdc2018.x.org/#cfp. > Remember, the deadline for submissions is Wednesday 25th July 2018 17:00 > UTC. Don't forget to send your proposals to bo...@foundation.x.org! > > The conference is free of charge and open to the general public. If you > plan on coming, please add yourself to the attendees list: > > https://www.x.org/wiki/Events/XDC2018/Attendees/ > > We'll use this list of attendees to make badges and plan for the > catering, so if you are attending please add your name as early as > possible. > > I am looking forward to seeing you there. If you have any > inquiries/questions, please send an email to xdc2...@gpul.org, adding on > CC the X.org board (bo...@foundation.x.org). > > Best regards, > > Sam > ___ > mesa-dev mailing list > mesa-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- 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 v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Tue, Aug 21, 2018 at 7:59 AM, Noralf Trønnes wrote: > Den 21.08.2018 10.44, skrev Daniel Vetter: >> On Mon, Aug 20, 2018 at 11:44:56PM -0700, John Stultz wrote: >>> >>> Since we don't have a drm_gem_cma_object reference in >>> drm_fb_helper_generic_probe(), I instead added: >>> fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer)); >>> >>> And that got things working! >>> >>> So yea, I wanted to figure out if we are just missing the line above >>> in drm_fb_helper_generic_probe()? Or if the kirin driver should be >>> setting the fix.smem_start in some other fashion? >> >> With the generic helpers we can't use the generic fb_mmap() implementation >> in fbdev/core/fbmem.c anymore. Instead Noralf added a generic fb_mmap >> fb_ops callback in drm_fbdev_fb_mmap, which you're supposed to use. Can >> you pls double-check that this is wired up correctly for kirin? >> >> At least I don't see any other place where we use smem_start in the fbdev >> code. It does get copied to userspace, but userspace should never use >> that. > > > I googled 'FBIOGET_FSCREENINFO smem_start' and came across info[1] > about the Mali blob using it and HiKey seems to have a Mali GPU: > > 00:17 BorgCuba: > the mali blob is supposed to open the framebuffer device, > get "smem_start" and try to map this memory via MALI_IOC_MEM_MAP_EXT ioctl > > Could this be the problem here? It does look like that's the case. Looking for smem_start usage, for Android its the gralloc code that fetches it: https://android.googlesource.com/device/linaro/hikey/+/master/gralloc/framebuffer_device.cpp#353 and then puts it into the private_handle_t: https://android.googlesource.com/device/linaro/hikey/+/master/gralloc/framebuffer_device.cpp#384 Which I assume then gets used later in the opaque mali blob (which then results in a similarly opaque hang). While I'm perfectly understanding that folks are not interested as its related to mali (which is fine, I can carry a patch - working to move away from fbdev emulation anyway), I am wondering if it might cause trouble for other users, as smem_start was previously set and now its not, so it seems likely to break userspace examples like: https://www.linuxtv.org/downloads/v4l-dvb-apis-old/osd.html Or are those such old legacy they don't really count? thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200869] UVD cause amdgpu crash on CIK: [amdgpu]] UVD not responding, trying to reset the VCPU
https://bugzilla.kernel.org/show_bug.cgi?id=200869 Janpieter Sollie (janpieter.sol...@dommel.be) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Janpieter Sollie (janpieter.sol...@dommel.be) --- 2nd update: after a double check of /sys/module/amdgpu, it turned out that the parameters for amdgpu were not applied at all when put in /etc/modprobe.d/options. I turned lilo into the following startup string: amdgpu.dc=1 amdgpu.audio=1 amdgpu.si_support=0 which seems to work properly. Sorry for the incorrect bug reporting. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] drm: Add support for handling linear tile formats
The previous patch added tile_w and tile_h, which represent the
horizontal and vertical sizes of a tile.
This one uses that to plumb through drm core in order to be able to
handle linear tile formats without the need for drivers to roll up
their own implementation.
This patch had been written with Mali-dp X0L2 and X0L0 in mind which
is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
bytes per pixel and where tiles are laid out in a linear manner.
Now what are the restrictions:
1. Pitch in bytes is expected to cover at least tile_h * width in
pixels. Due to this the places where the pitch is checked/used need to
be updated to take into consideration the tile_w, tile_h and
tile_size.
tile_size = cpp * tile_w * tile_h
2. When doing source cropping plane_src_x/y need to be a multiple of
tile_w/tile_h and we need to take into consideration the tile_w/tile_h
when computing the start address.
For all non-tiled formats the tile_w and tile_h will be 1, so if I
didn't miss anything nothing should change.
Regarding multi-planar linear tile formats, I'm not sure how those
should be handle I kind of assumed that tile_h/tile_w will have to be
divided by horizontal/subsampling. Anyway, I think it's best to just
put an warning in there and handle it when someone tries to add
support for them.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_atomic.c | 8 +++
drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
drivers/gpu/drm/drm_fourcc.c | 52
drivers/gpu/drm/drm_framebuffer.c| 19 +--
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
include/drm/drm_fourcc.h | 2 +
6 files changed, 94 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3eb061e11e2e..7a3e893a4cd1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct drm_plane
*plane,
return -ENOSPC;
}
+ /* Make sure source coordinates are a multiple of tile sizes */
+ if ((state->src_x >> 16) % state->fb->format->tile_w ||
+ (state->src_y >> 16) % state->fb->format->tile_h) {
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do not meet
tile restrictions",
+plane->base.id, plane->name);
+ return -EINVAL;
+ }
+
if (plane_switching_crtc(state->state, plane, state)) {
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
plane->base.id, plane->name);
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 47e0e2f6642d..4d8052adce67 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer *fb,
struct drm_gem_cma_object *obj;
dma_addr_t paddr;
u8 h_div = 1, v_div = 1;
+ u32 tile_w = drm_format_tile_width(fb->format, plane);
+ u32 tile_h = drm_format_tile_height(fb->format, plane);
obj = drm_fb_cma_get_gem_obj(fb, plane);
if (!obj)
@@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
v_div = fb->format->vsub;
}
- paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
- paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
+ paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >> 16))
+ / h_div;
+ /*
+* For tile formats pitches are expected to cover at least
+* width * tile_h pixels
+*/
+ paddr += ((fb->pitches[plane] / tile_h) * (state->src_y >> 16)) / v_div;
return paddr;
}
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index f55cd93ba2d0..d6c9c5aa4036 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -557,3 +557,55 @@ int drm_format_plane_height(int height, uint32_t format,
int plane)
return height / info->vsub;
}
EXPORT_SYMBOL(drm_format_plane_height);
+
+/**
+ * drm_format_tile_width - width of a tile for tile formats, should be 1 for
all
+ * non-tiled formats.
+ * @format: pixel format
+ * @plane: plane index
+ *
+ * Returns:
+ * The width of a tile, depending on the plane index and horizontal
sub-sampling
+ */
+uint32_t drm_format_tile_width(const struct drm_format_info *info, int plane)
+{
+ WARN_ON(!info->tile_w);
+ if (plane == 0 || info->tile_w == 1)
+ return info->tile_w;
+
+ /*
+* Multi planar tiled formats have never been tested, check that
+* buffer restrictions and source cropping meet the format layout
+* expectations.
+*/
+ WARN_ON("Multi-planar tiled formats unsupported");
+ WARN_ON(info->tile
[PATCH v2 5/5] drm: mali-dp: Enable mali specific buffer formats
Enable the following formats
- DRM_FORMAT_XYUV
- DRM_FORMAT_XVYU2101010
- DRM_FORMAT_X0L0
- DRM_FORMAT_X0L2
- DRM_FORMAT_P010
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/arm/malidp_hw.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index c94a4422e0e9..472cae76e19b 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -74,10 +74,15 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_ABGR1555, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
MALIDP_ID(4, 1) }, \
{ DRM_FORMAT_RGB565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
2) }, \
{ DRM_FORMAT_BGR565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
3) }, \
+ { DRM_FORMAT_XYUV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) }, \
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
+ { DRM_FORMAT_X0L0, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 4)}, \
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
}, \
- { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }
+ { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
+ { DRM_FORMAT_XVYU2101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+ { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}, \
+ { DRM_FORMAT_P010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}
static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/i915: Set tile sizes in drm_format_info
Two new fields had been added to drm_format_info struct, tile_w and
tile_h, this need to be set to 1 for all non-tiled formats.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/i915/intel_display.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bd8956f2544d..fdc679e9dfa3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2440,10 +2440,14 @@ static unsigned int
intel_fb_modifier_to_tiling(uint64_t fb_modifier)
* main surface.
*/
static const struct drm_format_info ccs_formats[] = {
- { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 8, .vsub = 16, },
- { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 8, .vsub = 16, },
- { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 8, .vsub = 16, },
- { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 8, .vsub = 16, },
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = {
4, 1, },
+ .hsub = 8, .vsub = 16, .tile_w = 1, .tile_h = 1 },
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = {
4, 1, },
+ .hsub = 8, .vsub = 16, .tile_w = 1, .tile_h = 1 },
+ { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = {
4, 1, },
+ .hsub = 8, .vsub = 16, .tile_w = 1, .tile_h = 1 },
+ { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = {
4, 1, },
+ .hsub = 8, .vsub = 16, .tile_w = 1, .tile_h = 1 },
};
static const struct drm_format_info *
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/fourcc: Add tile width and height to drm_format_info
Add two new fields(tile_w and tile_h) to drm_format_info, which
represent the horizontal and vertical sizes of a tile in tiled
formats.
This fields will be used by the next patch to add support in drm
core for handling framebuffer restrictions and to correctly handle
source cropping.
Additionally, since I was touching drm_format_info table I decided to
break the lines to the 80 characters limit, they were already getting
out of hand, but let's not focus on that, I don't have any problem
going back to the original line sizes or style them other way, if
someone wants me to.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_fourcc.c | 352 +++
include/drm/drm_fourcc.h | 4 +
2 files changed, 281 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 18bb960e9943..f55cd93ba2d0 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -105,81 +105,283 @@ EXPORT_SYMBOL(drm_get_format_name);
const struct drm_format_info *__drm_format_info(u32 format)
{
static const struct drm_format_info formats[] = {
- { .format = DRM_FORMAT_C8, .depth = 8,
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGB332, .depth = 8,
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGR233, .depth = 8,
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_XRGB,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_XBGR,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGBX,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGRX,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_ARGB,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
- { .format = DRM_FORMAT_ABGR,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
- { .format = DRM_FORMAT_RGBA,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
- { .format = DRM_FORMAT_BGRA,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
- { .format = DRM_FORMAT_XRGB1555,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_XBGR1555,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGBX5551,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGRX5551,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_ARGB1555,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
- { .format = DRM_FORMAT_ABGR1555,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
- { .format = DRM_FORMAT_RGBA5551,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
- { .format = DRM_FORMAT_BGRA5551,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
- { .format = DRM_FORMAT_RGB565, .depth = 16,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGR565, .depth = 16,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGB888, .depth = 24,
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGR888, .depth = 24,
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_XRGB,.depth = 24,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_XBGR,.depth = 24,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGBX,.depth = 24,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGRX,.depth = 24,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGB565_A8, .depth = 24,
.num_planes = 2, .cpp = { 2, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
-
[PATCH v2 1/5] drm/fourcc: Add new fourcc for malidp uncompressed formats
Malidp implements a number of yuv buffer formats which are not
currently described in drm_fourcc.h.
This adds those definitions and describes their memory layout.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_fourcc.c | 7 +++
include/uapi/drm/drm_fourcc.h | 27 ++-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 35c1e2742c27..18bb960e9943 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,13 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_XYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_XVYU2101010, .depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y0L0,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 2, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_X0L0,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_Y0L2,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 2, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_X0L2,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 21c50b39596f..5e01fbcd7a30 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -141,13 +141,31 @@ extern "C" {
#define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
R:G:B:A 10:10:10:2 little endian */
#define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
B:G:R:A 10:10:10:2 little endian */
-/* packed YCbCr */
+/* packed YCbCr422 */
#define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /*
[31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /*
[31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_UYVYfourcc_code('U', 'Y', 'V', 'Y') /*
[31:0] Y1:Cr0:Y0:Cb0 8:8:8:8 little endian */
#define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
+/* packed YCbCr444 */
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0]
X:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XVYU2101010 fourcc_code('X', 'V', '3', '0') /* [31:0]
X:Cr:Y:Cb 2:10:10:10 little endian */
+
+/*
+ * packed YCbCr420 2x2 tiled formats
+ * first 64 bits will contain Y,Cb,Cr components for a 2x2 tile
+ */
+
+/* [63:0] A3:A2:Y3:0:Cr0:0:Y2:0:A1:A0:Y1:0:Cb0:0:Y0:0
1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
+#define DRM_FORMAT_Y0L0fourcc_code('Y', '0', 'L', '0')
+/* [63:0] X3:X2:Y3:0:Cr0:0:Y2:0:X1:X0:Y1:0:Cb0:0:Y0:0
1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
+#define DRM_FORMAT_X0L0fourcc_code('X', '0', 'L', '0')
+
+/* [63:0] A3:A2:Y3:Cr0:Y2:A1:A0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little
endian */
+#define DRM_FORMAT_Y0L2fourcc_code('Y', '0', 'L', '2')
+/* [63:0] X3:X2:Y3:Cr0:Y2:X1:X0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little
endian */
+#define DRM_FORMAT_X0L2fourcc_code('X', '0', 'L', '2')
/*
* 2 plane RGB + A
@@ -177,6 +195,13 @@ extern "C" {
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/*
+ * Each sample packed into the top 10 bits of a 16-bit word.
+ * Y plane: [63:0] Y3:0:Y2:0:Y1:0:Y0:0, 10:6:10:6:10:6:10:6
+ * CrCb plane: [63:0] Cr2:0:Cb2:0:Cr0:0:Cb0:0, 10:6:10:6:10:6:10:6
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
--
2.18.0
__
[PATCH v2 0/5] Add Mali DP non-compressed pixel formats
Change since v1 [1]: - Droped changes that add special handling of the tile formats X0L0/X0L2 in the driver and extend drm_core, by adding tile_h and tile_w in drm_format_info, suggested by Daniel Vetter here [2], see patches 2 to 4. - Use a differnt fourcc code for DRM_FORMAT_XVYU2101010, as suggested by Brian Starkey here [3]. Mali DP supports a bunch of pixel formats that don't have a fourcc code defined in drm_fourcc.h, so this patchset adds the definition for those formats and enables them in mali-dp driver. The following new formats will be added: Packed YCbCr444 * DRM_FORMAT_XYUV * DRM_FORMAT_XVYU2101010 Two plane 10 bits format. * DRM_FORMAT_P010 Packed YCbCr420 2x2 tiled formats * DRM_FORMAT_Y0L0 * DRM_FORMAT_X0L0 * DRM_FORMAT_Y0L2 * DRM_FORMAT_X0L2 The difference between X0L0/X0L2 vs Y0L0/Y0L2 is that the later group have two alpha bits per pixel. This group is a bit special because we are dealing with a tiled format where the first 64 bits in memory represent the pixels for a 2x2 tile, so it needs a bit of special handling when it comes to: - pitch: needs to cover both rows that are in the same tile. - min allocation size: since a pitch cover both rows the formulas defined in drm_gem_fb_create don't work anymore. - handling of src_x and src_y offset: same as above since we are dealing with a tiled format drm_fb_cma_get_gem_obj doesn't return the correct address offset. [1] https://lists.freedesktop.org/archives/dri-devel/2018-July/184597.html [2] https://lists.freedesktop.org/archives/dri-devel/2018-August/186465.html [3] https://lists.freedesktop.org/archives/dri-devel/2018-August/186057.html Alexandru Gheorghe (5): drm/fourcc: Add new fourcc for malidp uncompressed formats drm/fourcc: Add tile width and height to drm_format_info drm/i915: Set tile sizes in drm_format_info drm: Add support for handling linear tile formats drm: mali-dp: Enable mali specific buffer formats drivers/gpu/drm/arm/malidp_hw.c | 7 +- drivers/gpu/drm/drm_atomic.c | 8 + drivers/gpu/drm/drm_fb_cma_helper.c | 11 +- drivers/gpu/drm/drm_fourcc.c | 397 +++ drivers/gpu/drm/drm_framebuffer.c| 19 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 +- drivers/gpu/drm/i915/intel_display.c | 12 +- include/drm/drm_fourcc.h | 6 + include/uapi/drm/drm_fourcc.h| 27 +- 9 files changed, 415 insertions(+), 82 deletions(-) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: fix a compile warning
On Fri, Aug 17, 2018 at 3:01 PM Randy Dunlap wrote:
>
> On 08/16/2018 08:09 PM, Wen Yang wrote:
> > Fix comile warning like,
> > CC [M] drivers/gpu/drm/i915/gvt/execlist.o
> > CC [M] drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.o
> > CC [M] drivers/gpu/drm/radeon/btc_dpm.o
> > CC [M] drivers/isdn/hisax/avm_a1p.o
> > CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_dpp.o
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In
> > function ‘dcn10_update_mpcc’:
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:1903:9:
> > warning: missing braces around initializer [-Wmissing-braces]
> > struct mpcc_blnd_cfg blnd_cfg = {0};
> > ^
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:1903:9:
> > warning: (near initialization for ‘blnd_cfg.black_color’) [-Wmissing-braces]
> >
> > Signed-off-by: Wen Yang
> > Reviewed-by: Jiang Biao
>
> works for me. Thanks.
>
> Acked-by: Randy Dunlap
>
Applied. thanks!
Alex
>
> > ---
> > drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> > b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> > index cfcc54f..a06a035 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> > @@ -1900,7 +1900,7 @@ static void update_dpp(struct dpp *dpp, struct
> > dc_plane_state *plane_state)
> > static void dcn10_update_mpcc(struct dc *dc, struct pipe_ctx *pipe_ctx)
> > {
> > struct hubp *hubp = pipe_ctx->plane_res.hubp;
> > - struct mpcc_blnd_cfg blnd_cfg = {0};
> > + struct mpcc_blnd_cfg blnd_cfg = {{0}};
> > bool per_pixel_alpha = pipe_ctx->plane_state->per_pixel_alpha &&
> > pipe_ctx->bottom_pipe;
> > int mpcc_id;
> > struct mpcc *new_mpcc;
> >
>
>
> --
> ~Randy
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Jan Vesely changed: What|Removed |Added Depends on||99014 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99014 [Bug 99014] clover is broken for Oland in 12.0.4 -- 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] drm/fourcc: Add DOC: overview comment
On Tue, Aug 21, 2018 at 06:51:26PM +0200, Daniel Vetter wrote:
> On Tue, Aug 21, 2018 at 05:16:11PM +0100, Brian Starkey wrote:
> > There's a number of things which haven't previously been documented
> > around the usage of format modifiers. Capture the current
> > understanding in an overview comment and add it to the rst
> > documentation.
> >
> > Ideally, the generated documentation would also include documentation
> > of all of the #defines, but the kernel-doc system doesn't currently
> > support kernel-doc comments on #define constants.
> >
> > Suggested-by: Daniel Vetter
> > Signed-off-by: Brian Starkey
> > ---
> > Documentation/gpu/drm-kms.rst | 6 ++
> > include/uapi/drm/drm_fourcc.h | 36
> > 2 files changed, 42 insertions(+)
> >
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index 1dffd1ac4cd4..1dd9f4824d3b 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -322,6 +322,12 @@ Frame Buffer Functions Reference
> > DRM Format Handling
> > ===
> >
> > +.. kernel-doc:: include/uapi/drm/drm_fourcc.h
> > + :doc: overview
> > +
> > +Format Functions Reference
> > +--
> > +
> > .. kernel-doc:: include/drm/drm_fourcc.h
> > :internal:
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 894fa2da32fd..3f6c0b499323 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -30,6 +30,42 @@
> > extern "C" {
> > #endif
> >
> > +/**
> > + * DOC: overview
> > + *
> > + * In the DRM subsystem, framebuffer pixel formats are described using the
> > + * fourcc codes defined in `include/uapi/drm/drm_fourcc.h`. In addition to
> > the
> > + * fourcc code, a Format Modifier may optionally be provided, in order to
> > + * further describe the buffer's format - for example tiling or
> > compression.
> > + *
> > + * Format Modifiers
> > + *
> > + *
> > + * Format modifiers are used in conjunction with a fourcc code, forming a
> > + * unique fourcc:modifier pair. This format:modifier pair must fully
> > define the
> > + * format and data layout of the buffer, and should be the only way to
> > describe
> > + * that particular buffer.
> > + *
> > + * Having multiple fourcc:modifier pairs which describe the same layout
> > should
> > + * be avoided, as such aliases run the risk of different drivers exposing
> > + * different names for the same data format, forcing userspace to
> > understand
> > + * that they are aliases.
> > + *
> > + * Format modifiers may change any property of the buffer, including the
> > number
> > + * of planes and/or the required allocation size. Format modifiers are
> > + * vendor-namespaced, and as such the relationship between a fourcc code
> > and a
> > + * modifier is specific to the modifer being used. For example, some
> > modifiers
> > + * may preserve meaning - such as number of planes - from the fourcc code,
> > + * whereas others may not.
> > + *
> > + * Vendors are encouraged to document their modifier usage in as much
> > detail as
>
> I'd go with a slightly stronger "... should document ..." but either way:
>
> Reviewed-by: Daniel Vetter
>
> I'll leave pushing to one of the arm committers for drm-misc.
> -Daniel
Done.
>
> > + * possible, to ensure maximum compatibility across devices, drivers and
> > + * applications.
> > + *
> > + * The authoritative list of format modifier codes is found in
> > + * `include/uapi/drm/drm_fourcc.h`
> > + */
> > +
> > #define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
> > ((__u32)(c) << 16) | ((__u32)(d) << 24))
> >
> > --
> > 2.16.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Add support for vkms work without vblank
Thanks for the feedbacks,
I will prepare a V2 based on your suggestions.
On 08/21, Daniel Vetter wrote:
> On Tue, Aug 21, 2018 at 4:52 PM, Rodrigo Siqueira
> wrote:
> > On 08/21, Daniel Vetter wrote:
> >> On Mon, Aug 20, 2018 at 08:55:44PM -0300, Rodrigo Siqueira wrote:
> >> > Currently, vkms needs VBlank to work well. This patch adds another
> >> > operation model that make vkms works without VBlank support.
> >> >
> >> > Signed-off-by: Rodrigo Siqueira
> >> > ---
> >> > drivers/gpu/drm/vkms/vkms_crtc.c | 10 ++
> >> > drivers/gpu/drm/vkms/vkms_drv.c | 12 ++--
> >> > drivers/gpu/drm/vkms/vkms_drv.h | 1 +
> >> > 3 files changed, 21 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> >> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> >> > index bfe6e0312cc4..001fa5c1d326 100644
> >> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> >> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> >> > @@ -145,12 +145,22 @@ static const struct drm_crtc_funcs vkms_crtc_funcs
> >> > = {
> >> > static void vkms_crtc_atomic_enable(struct drm_crtc *crtc,
> >> > struct drm_crtc_state *old_state)
> >> > {
> >> > + struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
> >> > +
> >> > + if (vkms_out->disable_vblank)
> >> > + return;
> >> > +
> >> > drm_crtc_vblank_on(crtc);
> >> > }
> >> >
> >> > static void vkms_crtc_atomic_disable(struct drm_crtc *crtc,
> >> > struct drm_crtc_state *old_state)
> >> > {
> >> > + struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
> >> > +
> >> > + if (vkms_out->disable_vblank)
> >> > + return;
> >> > +
> >> > drm_crtc_vblank_off(crtc);
> >> > }
> >> >
> >> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
> >> > b/drivers/gpu/drm/vkms/vkms_drv.c
> >> > index 5d78bd97e69c..f30c4113d4c4 100644
> >> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> >> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> >> > @@ -21,6 +21,10 @@
> >> >
> >> > static struct vkms_device *vkms_device;
> >> >
> >> > +static bool disable_vblank;
> >> > +module_param_named(disablevblank, disable_vblank, bool, 0444);
> >> > +MODULE_PARM_DESC(disablevblank, "Disable vblank interrupt");
> >>
> >> I think the info output is much clearer, I'd rename this to virtual_hw,
> >> with 0 as default, and a help text along of "Enable virtual HW mode
> >> (disables vblanks and immediately completes flips)."
> >
> > You right, virtual_hw is much better :)
> > I will fix it.
> >
> >> > +
> >> > static const struct file_operations vkms_driver_fops = {
> >> > .owner = THIS_MODULE,
> >> > .open = drm_open,
> >> > @@ -105,9 +109,13 @@ static int __init vkms_init(void)
> >> > goto out_fini;
> >> > }
> >> >
> >> > - vkms_device->drm.irq_enabled = true;
> >> > + vkms_device->output.disable_vblank = disable_vblank;
> >> > + vkms_device->drm.irq_enabled = !disable_vblank ? true : false;
> >> > +
> >> > + if (disable_vblank)
> >> > + DRM_INFO("Virtual Hardware mode enabled");
> >> >
> >> > - ret = drm_vblank_init(&vkms_device->drm, 1);
> >> > + ret = (disable_vblank) ? 0 : drm_vblank_init(&vkms_device->drm, 1);
> >> > if (ret) {
> >> > DRM_ERROR("Failed to vblank\n");
> >> > goto out_fini;
> >> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.h
> >> > b/drivers/gpu/drm/vkms/vkms_drv.h
> >> > index f156c930366a..9ee862e6f7e5 100644
> >> > --- a/drivers/gpu/drm/vkms/vkms_drv.h
> >> > +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> >> > @@ -52,6 +52,7 @@ struct vkms_output {
> >> > struct drm_encoder encoder;
> >> > struct drm_connector connector;
> >> > struct hrtimer vblank_hrtimer;
> >> > + bool disable_vblank;
> >> > ktime_t period_ns;
> >> > struct drm_pending_vblank_event *event;
> >> > bool crc_enabled;
> >>
> >> The vblank handling parts look correct to me.
> >>
> >> Does kms_flip work with this? Virtual hw immediately completes the
> >> drm_crtc_state->event in the atomic_update callback, that part seems to be
> >> missing from your patch.
> >
> > I tested with patched version of kms_flip to skip vblank. Here is the patch:
> >
> > https://patchwork.kernel.org/patch/10570861/
> >
> > About the drm_crtc_state->event, afaiu, the code in the function
> > vkms_crtc_atomic_flush immediately send the vblank event to the user
> > space via drm_crtc_send_vblank_event which make things work in the user
> > space. Make sense? Or I missed something?
>
> Ah, the magic of the vblank_get() == 0 check. A bit tricky, but yes
> this indeed works. I think it'd be good to explain this in the commit
> message.
>
> >> Also I like the idea of switching away from the generic -EINVAL to -ENOTTY
> >> for when vblanks aren't supported. Do you have that somewhere (as a
> >> separate patch).
> >
> > I already started to investigate if the change between -EINVAL to
> > -ENOTTY will break an existing kms userspace com
Re: [PATCH 2/2] drm/nouveau: Fix GM107 disp dmac chan init on ThinkPad P50
As a note: I don't think this patch is ready /just/ yet now as I just hit this
problem again this morning (and it looks like I'm checking the wrong mask for
dmac, it appears to be slightly different from the core), looking into this now
On Mon, 2018-08-20 at 13:20 -0400, Lyude Paul wrote:
> Just like how the P50 will occasionally leave the disp's core channel on
> before nouveau starts initializing, it will occasionally do the same
> thing with the rest of the dmac channel in addition to the core channel.
> Example:
>
> [1.604375] nouveau :01:00.0: disp: outp 04:0006:0f81: no heads (0 3 4)
> [1.604858] nouveau :01:00.0: disp: outp 04:0006:0f81: aux power ->
> always
> [1.605354] nouveau :01:00.0: disp: outp 04:0006:0f81: aux power ->
> demand
> [1.605815] nouveau :01:00.0: disp: outp 05:0002:0f81: no heads (0 3 2)
> [1.607289] nouveau :01:00.0: disp: chid 0 mthd data 0400
> 1000 0002
> [1.608818] nouveau :01:00.0: disp: chid 1 mthd data 0400
> 1000 0002
> [1.609500] nouveau :01:00.0: disp: chid 2 mthd data 0400
> 1000 0002
>
> Which of course, later causes other parts of the card to start timing
> out and failing. Closer inspection shows the same thing happening as
> with our core channel; 0x610490 + (ctrl * 0x10) always has the same
> unknown 0x000a mask set when the phantom mthd failures start
> appearing.
>
> So, implement the same workaround we use for the core disp channel to
> the rest of the disp channels.
>
> This along with the previous patch fix random initialization failures
> observed with the Thinkpad P50.
>
> Signed-off-by: Lyude Paul
> Cc: Karol Herbst
> Cc: sta...@vger.kernel.org
> ---
> .../drm/nouveau/nvkm/engine/disp/dmacgf119.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dmacgf119.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dmacgf119.c
> index edf7dd0d931d..7bc91f260e27 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dmacgf119.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dmacgf119.c
> @@ -35,8 +35,8 @@ gf119_disp_dmac_bind(struct nv50_disp_chan *chan,
>chan->chid.user << 27 | 0x0001);
> }
>
> -void
> -gf119_disp_dmac_fini(struct nv50_disp_chan *chan)
> +static bool
> +gf119_disp_dmac_deactivate(struct nv50_disp_chan *chan)
> {
> struct nvkm_subdev *subdev = &chan->disp->base.engine.subdev;
> struct nvkm_device *device = subdev->device;
> @@ -52,7 +52,16 @@ gf119_disp_dmac_fini(struct nv50_disp_chan *chan)
> ) < 0) {
> nvkm_error(subdev, "ch %d fini: %08x\n", user,
> nvkm_rd32(device, 0x610490 + (ctrl * 0x10)));
> + return false;
> }
> +
> + return true;
> +}
> +
> +void
> +gf119_disp_dmac_fini(struct nv50_disp_chan *chan)
> +{
> + gf119_disp_dmac_deactivate(chan);
> }
>
> static int
> @@ -63,6 +72,12 @@ gf119_disp_dmac_init(struct nv50_disp_chan *chan)
> int ctrl = chan->chid.ctrl;
> int user = chan->chid.user;
>
> + /* shut down the channel if it was left on, probably by the VBIOS */
> + if ((nvkm_rd32(device, 0x610490 + (ctrl * 0x10)) & 0x000a) ==
> 0x000a &&
> + WARN_ON(!gf119_disp_dmac_deactivate(chan))) {
> + return -EBUSY;
> + }
> +
> /* initialise channel for dma command submission */
> nvkm_wr32(device, 0x610494 + (ctrl * 0x0010), chan->push);
> nvkm_wr32(device, 0x610498 + (ctrl * 0x0010), 0x0001);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fourcc: Add DOC: overview comment
On Tue, Aug 21, 2018 at 05:16:11PM +0100, Brian Starkey wrote:
> There's a number of things which haven't previously been documented
> around the usage of format modifiers. Capture the current
> understanding in an overview comment and add it to the rst
> documentation.
>
> Ideally, the generated documentation would also include documentation
> of all of the #defines, but the kernel-doc system doesn't currently
> support kernel-doc comments on #define constants.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Brian Starkey
> ---
> Documentation/gpu/drm-kms.rst | 6 ++
> include/uapi/drm/drm_fourcc.h | 36
> 2 files changed, 42 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 1dffd1ac4cd4..1dd9f4824d3b 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -322,6 +322,12 @@ Frame Buffer Functions Reference
> DRM Format Handling
> ===
>
> +.. kernel-doc:: include/uapi/drm/drm_fourcc.h
> + :doc: overview
> +
> +Format Functions Reference
> +--
> +
> .. kernel-doc:: include/drm/drm_fourcc.h
> :internal:
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 894fa2da32fd..3f6c0b499323 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -30,6 +30,42 @@
> extern "C" {
> #endif
>
> +/**
> + * DOC: overview
> + *
> + * In the DRM subsystem, framebuffer pixel formats are described using the
> + * fourcc codes defined in `include/uapi/drm/drm_fourcc.h`. In addition to
> the
> + * fourcc code, a Format Modifier may optionally be provided, in order to
> + * further describe the buffer's format - for example tiling or compression.
> + *
> + * Format Modifiers
> + *
> + *
> + * Format modifiers are used in conjunction with a fourcc code, forming a
> + * unique fourcc:modifier pair. This format:modifier pair must fully define
> the
> + * format and data layout of the buffer, and should be the only way to
> describe
> + * that particular buffer.
> + *
> + * Having multiple fourcc:modifier pairs which describe the same layout
> should
> + * be avoided, as such aliases run the risk of different drivers exposing
> + * different names for the same data format, forcing userspace to understand
> + * that they are aliases.
> + *
> + * Format modifiers may change any property of the buffer, including the
> number
> + * of planes and/or the required allocation size. Format modifiers are
> + * vendor-namespaced, and as such the relationship between a fourcc code and
> a
> + * modifier is specific to the modifer being used. For example, some
> modifiers
> + * may preserve meaning - such as number of planes - from the fourcc code,
> + * whereas others may not.
> + *
> + * Vendors are encouraged to document their modifier usage in as much detail
> as
I'd go with a slightly stronger "... should document ..." but either way:
Reviewed-by: Daniel Vetter
I'll leave pushing to one of the arm committers for drm-misc.
-Daniel
> + * possible, to ensure maximum compatibility across devices, drivers and
> + * applications.
> + *
> + * The authoritative list of format modifier codes is found in
> + * `include/uapi/drm/drm_fourcc.h`
> + */
> +
> #define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
>((__u32)(c) << 16) | ((__u32)(d) << 24))
>
> --
> 2.16.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Tue, Aug 21, 2018 at 6:03 PM, Noralf Trønnes wrote:
>
> Den 21.08.2018 17.41, skrev Daniel Vetter:
>>
>> On Tue, Aug 21, 2018 at 04:59:46PM +0200, Noralf Trønnes wrote:
>>>
>>> Den 21.08.2018 10.44, skrev Daniel Vetter:
On Mon, Aug 20, 2018 at 11:44:56PM -0700, John Stultz wrote:
>
> On Tue, Jul 3, 2018 at 9:03 AM, Noralf Trønnes
> wrote:
>>
>> This switches the CMA helper drivers that use its fbdev emulation over
>> to the generic fbdev emulation. It's the first phase of using generic
>> fbdev. A later phase will use DRM client callbacks for the
>> lastclose/hotplug/remove callbacks.
>>
>> There are currently 2 fbdev init/fini functions:
>> - drm_fb_cma_fbdev_init/drm_fb_cma_fbdev_fini
>> - drm_fbdev_cma_init/drm_fbdev_cma_fini
>>
>> This is because the work on generic fbdev came up during a fbdev
>> refactoring and thus wasn't completed. No point in completing that
>> refactoring when drivers will soon move to
>> drm_fb_helper_generic_probe().
>>
>> tinydrm uses drm_fb_cma_fbdev_init_with_funcs().
>>
>> Cc: Laurent Pinchart
>> Signed-off-by: Noralf Trønnes
>> Acked-by: Daniel Vetter
>> ---
>>drivers/gpu/drm/drm_fb_cma_helper.c | 360
>> +---
>>include/drm/drm_fb_cma_helper.h | 3 -
>>2 files changed, 42 insertions(+), 321 deletions(-)
>
> ...
>>
>> -static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
>> - struct drm_gem_cma_object
>> *cma_obj)
>> -{
>> - struct fb_deferred_io *fbdefio;
>> - struct fb_ops *fbops;
>> -
>> - /*
>> -* Per device structures are needed because:
>> -* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
>> -* fbdefio: individual delays
>> -*/
>> - fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
>> - fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
>> - if (!fbdefio || !fbops) {
>> - kfree(fbdefio);
>> - kfree(fbops);
>> - return -ENOMEM;
>> - }
>> -
>> - /* can't be offset from vaddr since dirty() uses cma_obj */
>> - fbi->screen_buffer = cma_obj->vaddr;
>> - /* fb_deferred_io_fault() needs a physical address */
>> - fbi->fix.smem_start =
>> page_to_phys(virt_to_page(fbi->screen_buffer));
>> -
>> - *fbops = *fbi->fbops;
>> - fbi->fbops = fbops;
>> -
>> - fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
>> - fbdefio->deferred_io = drm_fb_helper_deferred_io;
>> - fbi->fbdefio = fbdefio;
>> - fb_deferred_io_init(fbi);
>> - fbi->fbops->fb_mmap = drm_fbdev_cma_deferred_io_mmap;
>> -
>> - return 0;
>> -}
>> -
>> -static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
>> -{
>> - if (!fbi->fbdefio)
>> - return;
>> -
>> - fb_deferred_io_cleanup(fbi);
>> - kfree(fbi->fbdefio);
>> - kfree(fbi->fbops);
>> -}
>> -
>> -static int
>> -drm_fbdev_cma_create(struct drm_fb_helper *helper,
>> - struct drm_fb_helper_surface_size *sizes)
>> -{
>> - struct drm_fbdev_cma *fbdev_cma = to_fbdev_cma(helper);
>> - struct drm_device *dev = helper->dev;
>> - struct drm_gem_cma_object *obj;
>> - struct drm_framebuffer *fb;
>> - unsigned int bytes_per_pixel;
>> - unsigned long offset;
>> - struct fb_info *fbi;
>> - size_t size;
>> - int ret;
>> -
>> - DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
>> - sizes->surface_width, sizes->surface_height,
>> - sizes->surface_bpp);
>> -
>> - bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
>> - size = sizes->surface_width * sizes->surface_height *
>> bytes_per_pixel;
>> - obj = drm_gem_cma_create(dev, size);
>> - if (IS_ERR(obj))
>> - return -ENOMEM;
>> -
>> - fbi = drm_fb_helper_alloc_fbi(helper);
>> - if (IS_ERR(fbi)) {
>> - ret = PTR_ERR(fbi);
>> - goto err_gem_free_object;
>> - }
>> -
>> - fb = drm_gem_fbdev_fb_create(dev, sizes, 0, &obj->base,
>> -fbdev_cma->fb_funcs);
>> - if (IS_ERR(fb)) {
>> - dev_err(dev->dev, "Failed to allocate DRM
>> framebuffer.\n");
>> - ret = PTR_ERR(fb);
>> - goto err_fb_info_destroy;
>> - }
>> -
>> - helper->fb = fb;
>> -
>> - fbi->par = helper;
>> - fbi->flags = FBINFO_FLAG_DEFAULT;
>> -
Re: [PATCH] drm/fourcc: Add DOC: overview comment
Hi Matthew,
On Tue, Aug 21, 2018 at 09:26:39AM -0700, Matthew Wilcox wrote:
On Tue, Aug 21, 2018 at 05:16:11PM +0100, Brian Starkey wrote:
There's a number of things which haven't previously been documented
around the usage of format modifiers. Capture the current
understanding in an overview comment and add it to the rst
documentation.
Ideally, the generated documentation would also include documentation
of all of the #defines, but the kernel-doc system doesn't currently
support kernel-doc comments on #define constants.
Can you turn them into enums? This seems to work ok:
-/* color index */
-#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
-
-/* 8 bpp Red */
-#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
+enum {
+ /* color index */
+ DRM_FORMAT_C8 = fourcc_code('C', '8', ' ', ' '), /* [7:0] C */
+ /* 8 bpp Red */
+ DRM_FORMAT_R8 = fourcc_code('R', '8', ' ', ' '), /* [7:0] R */
+};
but I appreciate this is user API and maybe there's some code out there
that does #ifndef DRM_FORMAT_C8 ...
Thanks for the suggestion, Daniel did mention the same. However,
unfortunately I don't think we can safely change the UAPI header in
this manner.
Cheers,
-Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/msm/dpu: fix for cursor blend issue
On Tue, Aug 21, 2018 at 05:54:10PM +0530, Sravanthi Kollukuduru wrote:
> The current driver has the opaque blend mode set as the
> default causing the black box effect around the cursor.
> The fix enables choosing a different blend mode for alpha
> enabled formats.
>
> Signed-off-by: Sravanthi Kollukuduru
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 26 +-
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 0cd9456a6c4c..fc6200c74614 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -297,14 +297,29 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
> }
>
> static void _dpu_crtc_setup_blend_cfg(struct dpu_crtc_mixer *mixer,
> - struct dpu_plane_state *pstate)
> + struct dpu_plane_state *pstate, struct dpu_format *format)
> {
> struct dpu_hw_mixer *lm = mixer->hw_lm;
> + uint32_t blend_op;
>
> /* default to opaque blending */
> - lm->ops.setup_blend_config(lm, pstate->stage, 0XFF, 0,
> - DPU_BLEND_FG_ALPHA_FG_CONST |
> - DPU_BLEND_BG_ALPHA_BG_CONST);
> + blend_op = DPU_BLEND_FG_ALPHA_FG_CONST |
> + DPU_BLEND_BG_ALPHA_BG_CONST;
> +
> + if (format->alpha_enable) {
> + /* coverage blending */
> + blend_op = DPU_BLEND_FG_ALPHA_FG_PIXEL |
> + DPU_BLEND_BG_ALPHA_FG_PIXEL |
> + DPU_BLEND_BG_INV_ALPHA;
> + }
> +
> + lm->ops.setup_blend_config(lm, pstate->stage,
> + 0xFF, 0, blend_op);
> +
> + DPU_DEBUG(
> + "format:%4.4s, alpha_en(%u) blend_op:0x%x\n",
This will fit on one line.
> + (char *) &format->base.pixel_format,
drm_get_format_name() please
> + format->alpha_enable, blend_op);
> }
>
> static void _dpu_crtc_program_lm_output_roi(struct drm_crtc *crtc)
> @@ -401,7 +416,8 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
> *crtc,
>
> /* blend config update */
> for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++) {
> - _dpu_crtc_setup_blend_cfg(mixer + lm_idx, pstate);
> + _dpu_crtc_setup_blend_cfg(mixer + lm_idx,
> + pstate, format);
>
> mixer[lm_idx].flush_mask |= flush_mask;
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/msm/dpu: enable cursor plane on dpu
On Tue, Aug 21, 2018 at 05:54:09PM +0530, Sravanthi Kollukuduru wrote:
> Reserve DMA pipe for cursor plane and attach it to the
> crtc during the initialization.
>
> Signed-off-by: Sravanthi Kollukuduru
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 ++-
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 4 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 53
> +++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 35 +++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 9 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 4 +-
> 6 files changed, 55 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 80cbf75bc2ff..0cd9456a6c4c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -2082,7 +2082,8 @@ static const struct drm_crtc_helper_funcs
> dpu_crtc_helper_funcs = {
> };
>
> /* initialize crtc */
> -struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
> *plane)
> +struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
> *plane,
> + struct drm_plane *cursor)
> {
> struct drm_crtc *crtc = NULL;
> struct dpu_crtc *dpu_crtc = NULL;
> @@ -2119,7 +2120,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
> struct drm_plane *plane)
> dpu_crtc_frame_event_work);
> }
>
> - drm_crtc_init_with_planes(dev, crtc, plane, NULL, &dpu_crtc_funcs,
> + drm_crtc_init_with_planes(dev, crtc, plane, cursor, &dpu_crtc_funcs,
> NULL);
>
> drm_crtc_helper_add(crtc, &dpu_crtc_helper_funcs);
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> index e87109e608e9..a89679160237 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> @@ -375,9 +375,11 @@ void dpu_crtc_complete_commit(struct drm_crtc *crtc,
> * dpu_crtc_init - create a new crtc object
> * @dev: dpu device
> * @plane: base plane
> + * @cursor: cursor plane
> * @Return: new crtc object or error
> */
> -struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
> *plane);
> +struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
> *plane,
> +struct drm_plane *cursor);
>
> /**
> * dpu_crtc_register_custom_event - api for enabling/disabling crtc event
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index 44ee06398b1d..c04f3f3acae4 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -29,6 +29,9 @@
> BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
> BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
>
> +#define DMA_CURSOR_SDM845_MASK \
> + (DMA_SDM845_MASK | BIT(DPU_SSPP_CURSOR))
> +
> #define MIXER_SDM845_MASK \
> (BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
>
> @@ -174,45 +177,35 @@ static const struct dpu_sspp_sub_blks sdm845_dma_sblk_1
> = _DMA_SBLK("9", 2);
> static const struct dpu_sspp_sub_blks sdm845_dma_sblk_2 = _DMA_SBLK("10", 3);
> static const struct dpu_sspp_sub_blks sdm845_dma_sblk_3 = _DMA_SBLK("11", 4);
>
> -#define SSPP_VIG_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
> - { \
> - .name = _name, .id = _id, \
> - .base = _base, .len = 0x1c8, \
> - .features = VIG_SDM845_MASK, \
> - .sblk = &_sblk, \
> - .xin_id = _xinid, \
> - .type = SSPP_TYPE_VIG, \
> - .clk_ctrl = _clkctrl \
> - }
> -
> -#define SSPP_DMA_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
> +#define SSPP_BLK(_name, _id, _base, _features, \
> + _sblk, _xinid, _type, _clkctrl) \
> { \
> .name = _name, .id = _id, \
> .base = _base, .len = 0x1c8, \
> - .features = DMA_SDM845_MASK, \
> + .features = _features, \
> .sblk = &_sblk, \
> .xin_id = _xinid, \
> - .type = SSPP_TYPE_DMA, \
> + .type = _type, \
> .clk_ctrl = _clkctrl \
> }
>
> static struct dpu_sspp_cfg sdm845_sspp[] = {
> - SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x4000,
> - sdm845_vig_sblk_0, 0, DPU_CLK_CTRL_VIG0),
> - SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x6000,
> - sdm845_vig_sblk_1, 4, DPU_CLK_CTRL_VIG1),
> - SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x8000,
> - sdm845_vig_sblk_2, 8, DPU_CLK_CTRL_VIG2),
> - SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xa000,
> - sdm845_vig_sblk_3, 12, DPU_CLK_CTRL_VIG3),
> - SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x24000,
> - sdm845_dma_sblk_0, 1, DPU_CLK_CTRL_DMA0),
> - SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x26000,
> - sdm845_dma_sblk_1, 5, DPU_CLK_CTRL_DMA1),
> -
[PATCH] drm/fourcc: Add DOC: overview comment
There's a number of things which haven't previously been documented
around the usage of format modifiers. Capture the current
understanding in an overview comment and add it to the rst
documentation.
Ideally, the generated documentation would also include documentation
of all of the #defines, but the kernel-doc system doesn't currently
support kernel-doc comments on #define constants.
Suggested-by: Daniel Vetter
Signed-off-by: Brian Starkey
---
Documentation/gpu/drm-kms.rst | 6 ++
include/uapi/drm/drm_fourcc.h | 36
2 files changed, 42 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 1dffd1ac4cd4..1dd9f4824d3b 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -322,6 +322,12 @@ Frame Buffer Functions Reference
DRM Format Handling
===
+.. kernel-doc:: include/uapi/drm/drm_fourcc.h
+ :doc: overview
+
+Format Functions Reference
+--
+
.. kernel-doc:: include/drm/drm_fourcc.h
:internal:
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 894fa2da32fd..3f6c0b499323 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -30,6 +30,42 @@
extern "C" {
#endif
+/**
+ * DOC: overview
+ *
+ * In the DRM subsystem, framebuffer pixel formats are described using the
+ * fourcc codes defined in `include/uapi/drm/drm_fourcc.h`. In addition to the
+ * fourcc code, a Format Modifier may optionally be provided, in order to
+ * further describe the buffer's format - for example tiling or compression.
+ *
+ * Format Modifiers
+ *
+ *
+ * Format modifiers are used in conjunction with a fourcc code, forming a
+ * unique fourcc:modifier pair. This format:modifier pair must fully define the
+ * format and data layout of the buffer, and should be the only way to describe
+ * that particular buffer.
+ *
+ * Having multiple fourcc:modifier pairs which describe the same layout should
+ * be avoided, as such aliases run the risk of different drivers exposing
+ * different names for the same data format, forcing userspace to understand
+ * that they are aliases.
+ *
+ * Format modifiers may change any property of the buffer, including the number
+ * of planes and/or the required allocation size. Format modifiers are
+ * vendor-namespaced, and as such the relationship between a fourcc code and a
+ * modifier is specific to the modifer being used. For example, some modifiers
+ * may preserve meaning - such as number of planes - from the fourcc code,
+ * whereas others may not.
+ *
+ * Vendors are encouraged to document their modifier usage in as much detail as
+ * possible, to ensure maximum compatibility across devices, drivers and
+ * applications.
+ *
+ * The authoritative list of format modifier codes is found in
+ * `include/uapi/drm/drm_fourcc.h`
+ */
+
#define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
((__u32)(c) << 16) | ((__u32)(d) << 24))
--
2.16.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
Den 21.08.2018 17.41, skrev Daniel Vetter:
On Tue, Aug 21, 2018 at 04:59:46PM +0200, Noralf Trønnes wrote:
Den 21.08.2018 10.44, skrev Daniel Vetter:
On Mon, Aug 20, 2018 at 11:44:56PM -0700, John Stultz wrote:
On Tue, Jul 3, 2018 at 9:03 AM, Noralf Trønnes wrote:
This switches the CMA helper drivers that use its fbdev emulation over
to the generic fbdev emulation. It's the first phase of using generic
fbdev. A later phase will use DRM client callbacks for the
lastclose/hotplug/remove callbacks.
There are currently 2 fbdev init/fini functions:
- drm_fb_cma_fbdev_init/drm_fb_cma_fbdev_fini
- drm_fbdev_cma_init/drm_fbdev_cma_fini
This is because the work on generic fbdev came up during a fbdev
refactoring and thus wasn't completed. No point in completing that
refactoring when drivers will soon move to drm_fb_helper_generic_probe().
tinydrm uses drm_fb_cma_fbdev_init_with_funcs().
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_cma_helper.c | 360
+---
include/drm/drm_fb_cma_helper.h | 3 -
2 files changed, 42 insertions(+), 321 deletions(-)
...
-static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
- struct drm_gem_cma_object *cma_obj)
-{
- struct fb_deferred_io *fbdefio;
- struct fb_ops *fbops;
-
- /*
-* Per device structures are needed because:
-* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
-* fbdefio: individual delays
-*/
- fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
- fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
- if (!fbdefio || !fbops) {
- kfree(fbdefio);
- kfree(fbops);
- return -ENOMEM;
- }
-
- /* can't be offset from vaddr since dirty() uses cma_obj */
- fbi->screen_buffer = cma_obj->vaddr;
- /* fb_deferred_io_fault() needs a physical address */
- fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer));
-
- *fbops = *fbi->fbops;
- fbi->fbops = fbops;
-
- fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
- fbdefio->deferred_io = drm_fb_helper_deferred_io;
- fbi->fbdefio = fbdefio;
- fb_deferred_io_init(fbi);
- fbi->fbops->fb_mmap = drm_fbdev_cma_deferred_io_mmap;
-
- return 0;
-}
-
-static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
-{
- if (!fbi->fbdefio)
- return;
-
- fb_deferred_io_cleanup(fbi);
- kfree(fbi->fbdefio);
- kfree(fbi->fbops);
-}
-
-static int
-drm_fbdev_cma_create(struct drm_fb_helper *helper,
- struct drm_fb_helper_surface_size *sizes)
-{
- struct drm_fbdev_cma *fbdev_cma = to_fbdev_cma(helper);
- struct drm_device *dev = helper->dev;
- struct drm_gem_cma_object *obj;
- struct drm_framebuffer *fb;
- unsigned int bytes_per_pixel;
- unsigned long offset;
- struct fb_info *fbi;
- size_t size;
- int ret;
-
- DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
- sizes->surface_width, sizes->surface_height,
- sizes->surface_bpp);
-
- bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
- size = sizes->surface_width * sizes->surface_height * bytes_per_pixel;
- obj = drm_gem_cma_create(dev, size);
- if (IS_ERR(obj))
- return -ENOMEM;
-
- fbi = drm_fb_helper_alloc_fbi(helper);
- if (IS_ERR(fbi)) {
- ret = PTR_ERR(fbi);
- goto err_gem_free_object;
- }
-
- fb = drm_gem_fbdev_fb_create(dev, sizes, 0, &obj->base,
-fbdev_cma->fb_funcs);
- if (IS_ERR(fb)) {
- dev_err(dev->dev, "Failed to allocate DRM framebuffer.\n");
- ret = PTR_ERR(fb);
- goto err_fb_info_destroy;
- }
-
- helper->fb = fb;
-
- fbi->par = helper;
- fbi->flags = FBINFO_FLAG_DEFAULT;
- fbi->fbops = &drm_fbdev_cma_ops;
-
- drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);
- drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height);
-
- offset = fbi->var.xoffset * bytes_per_pixel;
- offset += fbi->var.yoffset * fb->pitches[0];
-
- dev->mode_config.fb_base = (resource_size_t)obj->paddr;
- fbi->screen_base = obj->vaddr + offset;
- fbi->fix.smem_start = (unsigned long)(obj->paddr + offset);
Hey Noralf, all,
I've been digging for a bit on the regression that this patch has
tripped on the HiKey board as reported here:
https://lkml.org/lkml/2018/8/16/81
The first issue was that the kirin driver was setting
mode_config.max_width/height = 2048, which was causing errors as the
the requested resolution was 1920x2160 (due to surfaceflinger
requesting y*2 for page flipping). This was relatively simple enough
to figure out and fix, but b
Re: [PATCH V2 4/4] drm/crc: add pre_crc_read function
On Tue, Aug 21, 2018 at 02:08:58PM +0530, Mahesh Kumar wrote:
> This patch implements a callback function which will be called before
> crc read. In this function driver can implement any preparation work
> required for successfully reading CRC data.
>
> Changes Since V1:
> - rebase
>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Mahesh Kumar
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/drm_debugfs_crc.c | 8
> include/drm/drm_crtc.h| 14 ++
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> b/drivers/gpu/drm/drm_debugfs_crc.c
> index 00e743153e94..e303c194c080 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -274,6 +274,14 @@ static ssize_t crtc_crc_read(struct file *filep, char
> __user *user_buf,
> return 0;
> }
>
> + if (crtc->funcs->pre_crc_read) {
> + ret = crtc->funcs->pre_crc_read(crtc);
> + if (ret) {
> + spin_unlock_irq(&crc->lock);
> + return ret;
> + }
> + }
> +
> /* Nothing to read? */
> while (crtc_crc_data_count(crc) == 0) {
> if (filep->f_flags & O_NONBLOCK) {
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b21437bc95bf..19c2bf63935e 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -761,6 +761,20 @@ struct drm_crtc_funcs {
>*/
> int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
>size_t *values_cnt);
> + /**
> + * @pre_crc_read:
> + *
> + * Driver callback for performing any preparation work required by
> + * driver before reading CRC
> + *
> + * This callback is optional if the driver does not support CRC
> + * generation or no prework is required before reading the crc
> + *
> + * RETURNS:
> + *
> + * 0 on success or a negative error code on failure.
> + */
> + int (*pre_crc_read)(struct drm_crtc *crtc);
> /**
>* @get_crc_sources:
>*
> --
> 2.16.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Improve non-DPLL clock selection
Hi Laurent, Jacopo,
On 21/08/18 09:08, Laurent Pinchart wrote:
> Hi Jacopo,
>
> (CC'ing Kieran)
>
> On Tuesday, 21 August 2018 10:33:57 EEST jacopo mondi wrote:
>> On Tue, Aug 21, 2018 at 01:12:40AM +0300, Laurent Pinchart wrote:
>>> On Tuesday, 21 August 2018 00:49:41 EEST Laurent Pinchart wrote:
From: Jacopo Mondi
DU channels not equipped with a DPLL use an SoC internal (provided by
the CPG) or external clock source combined with a DU internal divider to
generate the desired output dot clock frequency.
The current clock selection procedure does not fully exploit the ability
of external clock sources to generate the exact dot clock frequency by
themselves, but relies instead on tuning the internal DU clock divider
only, resulting in a less precise clock generation process.
When possible, and desirable, ask the external clock source for the
exact output dot clock frequency, and select the clock source that
produces the frequency closest to the desired output dot clock.
This patch specifically targets platforms (like Salvator-X[S] and ULCBs)
where the DU's input dotclock.in is generated by the versaclock VC5
clock source, which is capable of generating the exact rate the DU needs
as pixel clock output.
This patch fixes higher resolution modes which requires an high pixel
clock output currently not working on non-HDMI DU channel (such as
1920x1080@60Hz on the VGA output).
>>>
>>> Just for the record, with this patch the following modes (as printed by
>>>
>>> modetest) on the VGA output now produce correct result with my monitor:
>>> 1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 flags: nhsync,
>>> nvsync
>>> 1600x1200 60 1600 1664 1856 2160 1200 1201 1204 1250 flags: phsync,
>>> pvsync
>>> 1360x768 60 1360 1424 1536 1792 768 771 777 795 flags: phsync, pvsync
>>>
>>> The second mode used to not display at all, with a message telling that
>>> timings were out of range, and the other two modes used to produce a
>>> displayed image partly shifted or scaled out of the screen boundaries.
>>>
>>> The following modes still produce an image partly out of the screen
>>> boundaries.
>>>
>>> 1600x900 60 1600 1624 1704 1800 900 901 904 1000 flags: phsync, pvsync
>>> 1280x960 60 1280 1376 1488 1800 960 961 964 1000 flags: phsync, pvsync
>>> 1366x768 60 1366 1436 1579 1792 768 771 774 798 flags: phsync, pvsync
>>> 1366x768 60 1366 1380 1436 1500 768 769 772 800 flags: phsync, pvsync
>>> 1280x720 60 1280 1390 1430 1650 720 725 730 750 flags: phsync, pvsync
>>>
>>> And this one is reported to be out of range.
>>>
>>> 1920x1200 60 1920 2056 2256 2592 1200 1203 1209 1245 flags: nhsync,
>>> pvsync
>>>
>>> There is thus still room for improvement (some of the issues are possibly
>>> due to my monitor though), but there's also an improvement, and no
>>> noticeable regression.
>>>
Fixes: 1b30dbde8596 ("drm: rcar-du: Add support for external pixel
clock")
Signed-off-by: Jacopo Mondi
[Factor out code to a helper function]
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 86 +++-
1 file changed, 55 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index
f8068170905a..2c9405458bbf
100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -165,6 +165,48 @@ static void rcar_du_dpll_divider(struct
rcar_du_crtc *rcrtc,
best_diff);
}
+struct du_clk_params {
+ struct clk *clk;
+ unsigned long rate;
+ unsigned long diff;
+ u32 escr;
+};
+
+static void rcar_du_escr_divider(struct rcar_du_crtc *rcrtc, struct clk
*clk,
+ unsigned long target, u32 escr,
+ struct du_clk_params *params)
>>
>> I don't see the rcrtc parameter ever being used in this function.
>> Do you want to keep it anyhow?
>
> You're right, I'll remove it.
>
+{
+ unsigned long rate;
+ unsigned long diff;
+ u32 div;
+
+ /*
+ * If the target rate has already been achieved perfectly we can't do
+ * better.
+ */
+ if (params->diff == 0)
+ return;
+
+ /*
+ * Compute the input clock rate and internal divisor values to obtain
+ * the clock rate closest to the target frequency.
+ */
+ rate = clk_round_rate(clk, target);
+ div = clamp(DIV_ROUND_CLOSEST(rate, target), 1UL, 64UL) - 1;
+ diff = abs(rate / (div + 1) - target);
+
+ /*
+ * If the resulting frequency is better than any previously obtained,
>>
>> s/obtained,/obtained one,/ ?
>
> Any opinion from a native English speaker ? :-)
I'd probably write:
Stor
Re: [PATCH] drm/vkms: Add support for vkms work without vblank
On Tue, Aug 21, 2018 at 4:52 PM, Rodrigo Siqueira
wrote:
> On 08/21, Daniel Vetter wrote:
>> On Mon, Aug 20, 2018 at 08:55:44PM -0300, Rodrigo Siqueira wrote:
>> > Currently, vkms needs VBlank to work well. This patch adds another
>> > operation model that make vkms works without VBlank support.
>> >
>> > Signed-off-by: Rodrigo Siqueira
>> > ---
>> > drivers/gpu/drm/vkms/vkms_crtc.c | 10 ++
>> > drivers/gpu/drm/vkms/vkms_drv.c | 12 ++--
>> > drivers/gpu/drm/vkms/vkms_drv.h | 1 +
>> > 3 files changed, 21 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
>> > b/drivers/gpu/drm/vkms/vkms_crtc.c
>> > index bfe6e0312cc4..001fa5c1d326 100644
>> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
>> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
>> > @@ -145,12 +145,22 @@ static const struct drm_crtc_funcs vkms_crtc_funcs =
>> > {
>> > static void vkms_crtc_atomic_enable(struct drm_crtc *crtc,
>> > struct drm_crtc_state *old_state)
>> > {
>> > + struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
>> > +
>> > + if (vkms_out->disable_vblank)
>> > + return;
>> > +
>> > drm_crtc_vblank_on(crtc);
>> > }
>> >
>> > static void vkms_crtc_atomic_disable(struct drm_crtc *crtc,
>> > struct drm_crtc_state *old_state)
>> > {
>> > + struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
>> > +
>> > + if (vkms_out->disable_vblank)
>> > + return;
>> > +
>> > drm_crtc_vblank_off(crtc);
>> > }
>> >
>> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
>> > b/drivers/gpu/drm/vkms/vkms_drv.c
>> > index 5d78bd97e69c..f30c4113d4c4 100644
>> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
>> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
>> > @@ -21,6 +21,10 @@
>> >
>> > static struct vkms_device *vkms_device;
>> >
>> > +static bool disable_vblank;
>> > +module_param_named(disablevblank, disable_vblank, bool, 0444);
>> > +MODULE_PARM_DESC(disablevblank, "Disable vblank interrupt");
>>
>> I think the info output is much clearer, I'd rename this to virtual_hw,
>> with 0 as default, and a help text along of "Enable virtual HW mode
>> (disables vblanks and immediately completes flips)."
>
> You right, virtual_hw is much better :)
> I will fix it.
>
>> > +
>> > static const struct file_operations vkms_driver_fops = {
>> > .owner = THIS_MODULE,
>> > .open = drm_open,
>> > @@ -105,9 +109,13 @@ static int __init vkms_init(void)
>> > goto out_fini;
>> > }
>> >
>> > - vkms_device->drm.irq_enabled = true;
>> > + vkms_device->output.disable_vblank = disable_vblank;
>> > + vkms_device->drm.irq_enabled = !disable_vblank ? true : false;
>> > +
>> > + if (disable_vblank)
>> > + DRM_INFO("Virtual Hardware mode enabled");
>> >
>> > - ret = drm_vblank_init(&vkms_device->drm, 1);
>> > + ret = (disable_vblank) ? 0 : drm_vblank_init(&vkms_device->drm, 1);
>> > if (ret) {
>> > DRM_ERROR("Failed to vblank\n");
>> > goto out_fini;
>> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.h
>> > b/drivers/gpu/drm/vkms/vkms_drv.h
>> > index f156c930366a..9ee862e6f7e5 100644
>> > --- a/drivers/gpu/drm/vkms/vkms_drv.h
>> > +++ b/drivers/gpu/drm/vkms/vkms_drv.h
>> > @@ -52,6 +52,7 @@ struct vkms_output {
>> > struct drm_encoder encoder;
>> > struct drm_connector connector;
>> > struct hrtimer vblank_hrtimer;
>> > + bool disable_vblank;
>> > ktime_t period_ns;
>> > struct drm_pending_vblank_event *event;
>> > bool crc_enabled;
>>
>> The vblank handling parts look correct to me.
>>
>> Does kms_flip work with this? Virtual hw immediately completes the
>> drm_crtc_state->event in the atomic_update callback, that part seems to be
>> missing from your patch.
>
> I tested with patched version of kms_flip to skip vblank. Here is the patch:
>
> https://patchwork.kernel.org/patch/10570861/
>
> About the drm_crtc_state->event, afaiu, the code in the function
> vkms_crtc_atomic_flush immediately send the vblank event to the user
> space via drm_crtc_send_vblank_event which make things work in the user
> space. Make sense? Or I missed something?
Ah, the magic of the vblank_get() == 0 check. A bit tricky, but yes
this indeed works. I think it'd be good to explain this in the commit
message.
>> Also I like the idea of switching away from the generic -EINVAL to -ENOTTY
>> for when vblanks aren't supported. Do you have that somewhere (as a
>> separate patch).
>
> I already started to investigate if the change between -EINVAL to
> -ENOTTY will break an existing kms userspace compositors. I already
> checked:
>
> * kwin
> * sway
> * wayland-core
> * weston
>
> I still have to check the X drivers, chromium, and drm_hwc.
Awesome, keep up the great work.
Cheers, Daniel
>
> Thanks for the feedback.
>
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>
> --
> Rodrigo Siqueira
>
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Tue, Aug 21, 2018 at 04:59:46PM +0200, Noralf Trønnes wrote:
>
> Den 21.08.2018 10.44, skrev Daniel Vetter:
> > On Mon, Aug 20, 2018 at 11:44:56PM -0700, John Stultz wrote:
> > > On Tue, Jul 3, 2018 at 9:03 AM, Noralf Trønnes wrote:
> > > > This switches the CMA helper drivers that use its fbdev emulation over
> > > > to the generic fbdev emulation. It's the first phase of using generic
> > > > fbdev. A later phase will use DRM client callbacks for the
> > > > lastclose/hotplug/remove callbacks.
> > > >
> > > > There are currently 2 fbdev init/fini functions:
> > > > - drm_fb_cma_fbdev_init/drm_fb_cma_fbdev_fini
> > > > - drm_fbdev_cma_init/drm_fbdev_cma_fini
> > > >
> > > > This is because the work on generic fbdev came up during a fbdev
> > > > refactoring and thus wasn't completed. No point in completing that
> > > > refactoring when drivers will soon move to
> > > > drm_fb_helper_generic_probe().
> > > >
> > > > tinydrm uses drm_fb_cma_fbdev_init_with_funcs().
> > > >
> > > > Cc: Laurent Pinchart
> > > > Signed-off-by: Noralf Trønnes
> > > > Acked-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 360
> > > > +---
> > > > include/drm/drm_fb_cma_helper.h | 3 -
> > > > 2 files changed, 42 insertions(+), 321 deletions(-)
> > > ...
> > > > -static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
> > > > - struct drm_gem_cma_object *cma_obj)
> > > > -{
> > > > - struct fb_deferred_io *fbdefio;
> > > > - struct fb_ops *fbops;
> > > > -
> > > > - /*
> > > > -* Per device structures are needed because:
> > > > -* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
> > > > -* fbdefio: individual delays
> > > > -*/
> > > > - fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
> > > > - fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
> > > > - if (!fbdefio || !fbops) {
> > > > - kfree(fbdefio);
> > > > - kfree(fbops);
> > > > - return -ENOMEM;
> > > > - }
> > > > -
> > > > - /* can't be offset from vaddr since dirty() uses cma_obj */
> > > > - fbi->screen_buffer = cma_obj->vaddr;
> > > > - /* fb_deferred_io_fault() needs a physical address */
> > > > - fbi->fix.smem_start =
> > > > page_to_phys(virt_to_page(fbi->screen_buffer));
> > > > -
> > > > - *fbops = *fbi->fbops;
> > > > - fbi->fbops = fbops;
> > > > -
> > > > - fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
> > > > - fbdefio->deferred_io = drm_fb_helper_deferred_io;
> > > > - fbi->fbdefio = fbdefio;
> > > > - fb_deferred_io_init(fbi);
> > > > - fbi->fbops->fb_mmap = drm_fbdev_cma_deferred_io_mmap;
> > > > -
> > > > - return 0;
> > > > -}
> > > > -
> > > > -static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
> > > > -{
> > > > - if (!fbi->fbdefio)
> > > > - return;
> > > > -
> > > > - fb_deferred_io_cleanup(fbi);
> > > > - kfree(fbi->fbdefio);
> > > > - kfree(fbi->fbops);
> > > > -}
> > > > -
> > > > -static int
> > > > -drm_fbdev_cma_create(struct drm_fb_helper *helper,
> > > > - struct drm_fb_helper_surface_size *sizes)
> > > > -{
> > > > - struct drm_fbdev_cma *fbdev_cma = to_fbdev_cma(helper);
> > > > - struct drm_device *dev = helper->dev;
> > > > - struct drm_gem_cma_object *obj;
> > > > - struct drm_framebuffer *fb;
> > > > - unsigned int bytes_per_pixel;
> > > > - unsigned long offset;
> > > > - struct fb_info *fbi;
> > > > - size_t size;
> > > > - int ret;
> > > > -
> > > > - DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
> > > > - sizes->surface_width, sizes->surface_height,
> > > > - sizes->surface_bpp);
> > > > -
> > > > - bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
> > > > - size = sizes->surface_width * sizes->surface_height *
> > > > bytes_per_pixel;
> > > > - obj = drm_gem_cma_create(dev, size);
> > > > - if (IS_ERR(obj))
> > > > - return -ENOMEM;
> > > > -
> > > > - fbi = drm_fb_helper_alloc_fbi(helper);
> > > > - if (IS_ERR(fbi)) {
> > > > - ret = PTR_ERR(fbi);
> > > > - goto err_gem_free_object;
> > > > - }
> > > > -
> > > > - fb = drm_gem_fbdev_fb_create(dev, sizes, 0, &obj->base,
> > > > -fbdev_cma->fb_funcs);
> > > > - if (IS_ERR(fb)) {
> > > > - dev_err(dev->dev, "Failed to allocate DRM
> > > > framebuffer.\n");
> > > > - ret = PTR_ERR(fb);
> > > > - goto err_fb_info_destroy;
> > > > - }
> > > > -
> > > > - helper->fb = fb;
> > > > -
> > > > - fbi->par = helper;
> > > > - fbi->flags = FBINFO_FLAG_DEFAULT;
> > > > - fbi->fbops = &drm_fbdev_cma_ops
[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #22 from CheatCodesOfLife --- You're welcome. Not the exact same problem, no. I can get a hard-lock by trying to use amdvlk to play rpcs3, but it doesn't produce the same error and it's not as consistent (takes up to 15 minutes to crash) Not sure if it's worth noting but I went back and tried every Cemu version back to 1.5 and a lot of wine versions going back to 2.8. It happens every time as soon as the game loads. -- 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 v5 4/8] drm/cma-helper: Use the generic fbdev emulation
Den 21.08.2018 10.44, skrev Daniel Vetter:
On Mon, Aug 20, 2018 at 11:44:56PM -0700, John Stultz wrote:
On Tue, Jul 3, 2018 at 9:03 AM, Noralf Trønnes wrote:
This switches the CMA helper drivers that use its fbdev emulation over
to the generic fbdev emulation. It's the first phase of using generic
fbdev. A later phase will use DRM client callbacks for the
lastclose/hotplug/remove callbacks.
There are currently 2 fbdev init/fini functions:
- drm_fb_cma_fbdev_init/drm_fb_cma_fbdev_fini
- drm_fbdev_cma_init/drm_fbdev_cma_fini
This is because the work on generic fbdev came up during a fbdev
refactoring and thus wasn't completed. No point in completing that
refactoring when drivers will soon move to drm_fb_helper_generic_probe().
tinydrm uses drm_fb_cma_fbdev_init_with_funcs().
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_cma_helper.c | 360 +---
include/drm/drm_fb_cma_helper.h | 3 -
2 files changed, 42 insertions(+), 321 deletions(-)
...
-static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
- struct drm_gem_cma_object *cma_obj)
-{
- struct fb_deferred_io *fbdefio;
- struct fb_ops *fbops;
-
- /*
-* Per device structures are needed because:
-* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
-* fbdefio: individual delays
-*/
- fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
- fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
- if (!fbdefio || !fbops) {
- kfree(fbdefio);
- kfree(fbops);
- return -ENOMEM;
- }
-
- /* can't be offset from vaddr since dirty() uses cma_obj */
- fbi->screen_buffer = cma_obj->vaddr;
- /* fb_deferred_io_fault() needs a physical address */
- fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer));
-
- *fbops = *fbi->fbops;
- fbi->fbops = fbops;
-
- fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
- fbdefio->deferred_io = drm_fb_helper_deferred_io;
- fbi->fbdefio = fbdefio;
- fb_deferred_io_init(fbi);
- fbi->fbops->fb_mmap = drm_fbdev_cma_deferred_io_mmap;
-
- return 0;
-}
-
-static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
-{
- if (!fbi->fbdefio)
- return;
-
- fb_deferred_io_cleanup(fbi);
- kfree(fbi->fbdefio);
- kfree(fbi->fbops);
-}
-
-static int
-drm_fbdev_cma_create(struct drm_fb_helper *helper,
- struct drm_fb_helper_surface_size *sizes)
-{
- struct drm_fbdev_cma *fbdev_cma = to_fbdev_cma(helper);
- struct drm_device *dev = helper->dev;
- struct drm_gem_cma_object *obj;
- struct drm_framebuffer *fb;
- unsigned int bytes_per_pixel;
- unsigned long offset;
- struct fb_info *fbi;
- size_t size;
- int ret;
-
- DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
- sizes->surface_width, sizes->surface_height,
- sizes->surface_bpp);
-
- bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
- size = sizes->surface_width * sizes->surface_height * bytes_per_pixel;
- obj = drm_gem_cma_create(dev, size);
- if (IS_ERR(obj))
- return -ENOMEM;
-
- fbi = drm_fb_helper_alloc_fbi(helper);
- if (IS_ERR(fbi)) {
- ret = PTR_ERR(fbi);
- goto err_gem_free_object;
- }
-
- fb = drm_gem_fbdev_fb_create(dev, sizes, 0, &obj->base,
-fbdev_cma->fb_funcs);
- if (IS_ERR(fb)) {
- dev_err(dev->dev, "Failed to allocate DRM framebuffer.\n");
- ret = PTR_ERR(fb);
- goto err_fb_info_destroy;
- }
-
- helper->fb = fb;
-
- fbi->par = helper;
- fbi->flags = FBINFO_FLAG_DEFAULT;
- fbi->fbops = &drm_fbdev_cma_ops;
-
- drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);
- drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height);
-
- offset = fbi->var.xoffset * bytes_per_pixel;
- offset += fbi->var.yoffset * fb->pitches[0];
-
- dev->mode_config.fb_base = (resource_size_t)obj->paddr;
- fbi->screen_base = obj->vaddr + offset;
- fbi->fix.smem_start = (unsigned long)(obj->paddr + offset);
Hey Noralf, all,
I've been digging for a bit on the regression that this patch has
tripped on the HiKey board as reported here:
https://lkml.org/lkml/2018/8/16/81
The first issue was that the kirin driver was setting
mode_config.max_width/height = 2048, which was causing errors as the
the requested resolution was 1920x2160 (due to surfaceflinger
requesting y*2 for page flipping). This was relatively simple enough
to figure out and fix, but bumping the values up on its own didn't
seem to resolve the issue entirely, as I started to see hard hangs on
bootu
[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #21 from Andrey Grodzovsky --- (In reply to CheatCodesOfLife from comment #17) > (In reply to Andrey Grodzovsky from comment #16) > > Hi everyone, I've tried with latest kernel and latest VEGA10 firmware and > > wasn't able to reproduce this problem. > > > > From the logs it seems all of you are running 4.17.x kernel or earlier - try > > latest 4.18 and latest firmware form here - > > > > https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ > > Hi, > > I can reproduce this every time, on kernel 4.18 with mesa 18.3 and a Vega64. > > Simply try to open Mario Kart 8 in Cemu with wine, and the system will crash > with the exact same dmesg. I had mesa 18.2 so I updated to 18.3 - still nothing. Could you provide glxinfo dump ? What LLVM are you using ? I have 7.(In reply to CheatCodesOfLife from comment #20) > Created attachment 141210 [details] > glxinfo dump as requested Thanks for the info, is there any other way you reproduce it without the wine platform ? -- 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] drm/vkms: Add support for vkms work without vblank
On 08/21, Daniel Vetter wrote:
> On Mon, Aug 20, 2018 at 08:55:44PM -0300, Rodrigo Siqueira wrote:
> > Currently, vkms needs VBlank to work well. This patch adds another
> > operation model that make vkms works without VBlank support.
> >
> > Signed-off-by: Rodrigo Siqueira
> > ---
> > drivers/gpu/drm/vkms/vkms_crtc.c | 10 ++
> > drivers/gpu/drm/vkms/vkms_drv.c | 12 ++--
> > drivers/gpu/drm/vkms/vkms_drv.h | 1 +
> > 3 files changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index bfe6e0312cc4..001fa5c1d326 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -145,12 +145,22 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
> > static void vkms_crtc_atomic_enable(struct drm_crtc *crtc,
> > struct drm_crtc_state *old_state)
> > {
> > + struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
> > +
> > + if (vkms_out->disable_vblank)
> > + return;
> > +
> > drm_crtc_vblank_on(crtc);
> > }
> >
> > static void vkms_crtc_atomic_disable(struct drm_crtc *crtc,
> > struct drm_crtc_state *old_state)
> > {
> > + struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
> > +
> > + if (vkms_out->disable_vblank)
> > + return;
> > +
> > drm_crtc_vblank_off(crtc);
> > }
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
> > b/drivers/gpu/drm/vkms/vkms_drv.c
> > index 5d78bd97e69c..f30c4113d4c4 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > @@ -21,6 +21,10 @@
> >
> > static struct vkms_device *vkms_device;
> >
> > +static bool disable_vblank;
> > +module_param_named(disablevblank, disable_vblank, bool, 0444);
> > +MODULE_PARM_DESC(disablevblank, "Disable vblank interrupt");
>
> I think the info output is much clearer, I'd rename this to virtual_hw,
> with 0 as default, and a help text along of "Enable virtual HW mode
> (disables vblanks and immediately completes flips)."
You right, virtual_hw is much better :)
I will fix it.
> > +
> > static const struct file_operations vkms_driver_fops = {
> > .owner = THIS_MODULE,
> > .open = drm_open,
> > @@ -105,9 +109,13 @@ static int __init vkms_init(void)
> > goto out_fini;
> > }
> >
> > - vkms_device->drm.irq_enabled = true;
> > + vkms_device->output.disable_vblank = disable_vblank;
> > + vkms_device->drm.irq_enabled = !disable_vblank ? true : false;
> > +
> > + if (disable_vblank)
> > + DRM_INFO("Virtual Hardware mode enabled");
> >
> > - ret = drm_vblank_init(&vkms_device->drm, 1);
> > + ret = (disable_vblank) ? 0 : drm_vblank_init(&vkms_device->drm, 1);
> > if (ret) {
> > DRM_ERROR("Failed to vblank\n");
> > goto out_fini;
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.h
> > b/drivers/gpu/drm/vkms/vkms_drv.h
> > index f156c930366a..9ee862e6f7e5 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.h
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> > @@ -52,6 +52,7 @@ struct vkms_output {
> > struct drm_encoder encoder;
> > struct drm_connector connector;
> > struct hrtimer vblank_hrtimer;
> > + bool disable_vblank;
> > ktime_t period_ns;
> > struct drm_pending_vblank_event *event;
> > bool crc_enabled;
>
> The vblank handling parts look correct to me.
>
> Does kms_flip work with this? Virtual hw immediately completes the
> drm_crtc_state->event in the atomic_update callback, that part seems to be
> missing from your patch.
I tested with patched version of kms_flip to skip vblank. Here is the patch:
https://patchwork.kernel.org/patch/10570861/
About the drm_crtc_state->event, afaiu, the code in the function
vkms_crtc_atomic_flush immediately send the vblank event to the user
space via drm_crtc_send_vblank_event which make things work in the user
space. Make sense? Or I missed something?
> Also I like the idea of switching away from the generic -EINVAL to -ENOTTY
> for when vblanks aren't supported. Do you have that somewhere (as a
> separate patch).
I already started to investigate if the change between -EINVAL to
-ENOTTY will break an existing kms userspace compositors. I already
checked:
* kwin
* sway
* wayland-core
* weston
I still have to check the X drivers, chromium, and drm_hwc.
Thanks for the feedback.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Rodrigo Siqueira
http://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #55 from Andrey Grodzovsky --- (In reply to dwagner from comment #54) > (In reply to Andrey Grodzovsky from comment #53) > > Created attachment 141198 [details] [review] [review] > > add_debug_info2.patch > > > > Try this patch instead, i might be missing some prints in the first one. > > Can try that this evening. > > > In the last log you attached I haven't seen any UMR dumps or GPU fault > > prints in dmesg. THe GPU fault has to be in the log to compare the faulty > > address against the debug prints in the patch. > > In above attached file "xz-compressed output of gpu_debug3.sh" there is umr > output at the time of the crash (238 seconds after the reboot): > > -- > ... > mpv/vo-897 [005] 235.191542: dma_fence_wait_start: > driver=drm_sched timeline=gfx context=162 seqno=87 > mpv/vo-897 [005] d... 235.191548: dma_fence_enable_signal: > driver=drm_sched timeline=gfx context=162 seqno=87 > kworker/0:2-92[000] 238.275988: dma_fence_signaled: > driver=amdgpu timeline=sdma1 context=11 seqno=210 > kworker/0:2-92[000] 238.276004: dma_fence_signaled: > driver=amdgpu timeline=sdma1 context=11 seqno=211 > [ 238.180634] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 > timeout, signaled seq=32624, emitted seq=32626 > [ 238.180641] amdgpu :0a:00.0: GPU reset begin! > [ 238.180641] amdgpu :0a:00.0: GPU reset begin! > > crash detected! > > executing umr -O halt_waves -wa > No active waves! Did you use amdgpu.vm_fault_stop=2 parameter ? In case a fault happened that should have froze GPUs compute units and hence the above command would produce a lot of wave info. > > > executing umr -O verbose -R gfx[.] > > polaris11.gfx.rptr == 1792 > polaris11.gfx.wptr == 1792 > polaris11.gfx.drv_wptr == 1792 > polaris11.gfx.ring[1761] == 0x1000... > polaris11.gfx.ring[1762] == 0x1000... > polaris11.gfx.ring[1763] == 0x1000... > polaris11.gfx.ring[1764] == 0x1000... > polaris11.gfx.ring[1765] == 0x1000... > polaris11.gfx.ring[1766] == 0x1000... > polaris11.gfx.ring[1767] == 0x1000... > polaris11.gfx.ring[1768] == 0x1000... > polaris11.gfx.ring[1769] == 0x1000... > polaris11.gfx.ring[1770] == 0x1000... > polaris11.gfx.ring[1771] == 0x1000... > polaris11.gfx.ring[1772] == 0x1000... > polaris11.gfx.ring[1773] == 0x1000... > polaris11.gfx.ring[1774] == 0x1000... > polaris11.gfx.ring[1775] == 0x1000... > polaris11.gfx.ring[1776] == 0x1000... > polaris11.gfx.ring[1777] == 0x1000... > polaris11.gfx.ring[1778] == 0x1000... > polaris11.gfx.ring[1779] == 0x1000... > polaris11.gfx.ring[1780] == 0x1000... > polaris11.gfx.ring[1781] == 0x1000... > polaris11.gfx.ring[1782] == 0x1000... > polaris11.gfx.ring[1783] == 0x1000... > polaris11.gfx.ring[1784] == 0x1000... > polaris11.gfx.ring[1785] == 0x1000... > polaris11.gfx.ring[1786] == 0x1000... > polaris11.gfx.ring[1787] == 0x1000... > polaris11.gfx.ring[1788] == 0x1000... > polaris11.gfx.ring[1789] == 0x1000... > polaris11.gfx.ring[1790] == 0x1000... > polaris11.gfx.ring[1791] == 0x1000... > polaris11.gfx.ring[1792] == 0xc0032200rwD > > trying to get ADR from dmesg output for 'umr -O verbose -vm ...' > trying to get VMID from dmesg output for 'umr -O verbose -vm ...' > > done after crash, flashing NUMLOCK LED. > amdgpu_cs:0-799 [001] 286.852838: amdgpu_bo_list_set: > list=99c16b5c, bo=1771c26f, bo_size=131072 > amdgpu_cs:0-799 [001] 286.852846: amdgpu_bo_list_set: > list=99c16b5c, bo=46bfd439, bo_size=131072 > ... > -- > > But sure, there were no "VM_CONTEXT1_PROTECTION_FAULT_ADDR" error messages > this time. Sometimes such are emitted, sometimes not. -- 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: [Intel-gfx] [PATCH 3/4] drm/i915: preparations for enabling P010, P012, P016 formats
On 16-Aug-18 6:25 PM, Juha-Pekka Heikkila wrote:
Preparations for enabling P010, P012 and P016 formats. These
formats will extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 3 +-
drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 46 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 19 ++---
drivers/gpu/drm/i915/intel_sprite.c | 18 +++-
6 files changed, 69 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index b04952b..ab76b72 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -334,8 +334,7 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
/* set scaler mode */
if ((INTEL_GEN(dev_priv) >= 9) &&
plane_state && plane_state->base.fb &&
- plane_state->base.fb->format->format ==
- DRM_FORMAT_NV12) {
+ is_planar_yuv_format(plane_state->base.fb->format->format))
{
if (INTEL_GEN(dev_priv) == 9 &&
!IS_GEMINILAKE(dev_priv) &&
!IS_SKYLAKE(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index dcba645..58b2fc6 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -182,7 +182,7 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
else
crtc_state->active_planes &= ~BIT(intel_plane->id);
- if (state->visible && state->fb->format->format == DRM_FORMAT_NV12)
+ if (state->visible && is_planar_yuv_format(state->fb->format->format))
crtc_state->nv12_planes |= BIT(intel_plane->id);
else
crtc_state->nv12_planes &= ~BIT(intel_plane->id);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 690e1e8..80ce742 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2667,6 +2667,12 @@ int skl_format_to_fourcc(int format, bool rgb_order,
bool alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+ case PLANE_CTL_FORMAT_P010:
+ return DRM_FORMAT_P010;
+ case PLANE_CTL_FORMAT_P012:
+ return DRM_FORMAT_P012;
+ case PLANE_CTL_FORMAT_P016:
+ return DRM_FORMAT_P016;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3182,7 +3188,7 @@ int skl_check_plane_surface(const struct intel_crtc_state
*crtc_state,
* Handle the AUX surface first since
* the main surface setup depends on it.
*/
- if (fb->format->format == DRM_FORMAT_NV12) {
+ if (is_planar_yuv_format(fb->format->format)) {
ret = skl_check_nv12_surface(crtc_state, plane_state);
if (ret)
return ret;
@@ -3507,6 +3513,12 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+ case DRM_FORMAT_P010:
+ return PLANE_CTL_FORMAT_P010;
+ case DRM_FORMAT_P012:
+ return PLANE_CTL_FORMAT_P012;
+ case DRM_FORMAT_P016:
+ return PLANE_CTL_FORMAT_P016;
default:
MISSING_CASE(pixel_format);
}
@@ -4808,8 +4820,7 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
need_scaling = src_w != dst_w || src_h != dst_h;
if (plane_scaler_check)
- if (pixel_format == DRM_FORMAT_NV12)
- need_scaling = true;
+ need_scaling = is_planar_yuv_format(pixel_format);
if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
need_scaling = true;
@@ -4850,7 +4861,7 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
return 0;
}
- if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12 &&
+ if (plane_scaler_check && is_planar_yuv_format(pixel_format) &&
(src_h < SKL_MIN_YUV_420_SRC_H || src_w < SKL_MIN_YUV_420_SRC_W)) {
DRM_DEBUG_KMS("NV12: src dimensions not met\n");
return -EINVAL;
@@ -4955,6 +4966,9 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_P010:
+ case DRM_FORMAT_P012:
+ case DRM_F
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
Den 21.08.2018 08.44, skrev John Stultz:
On Tue, Jul 3, 2018 at 9:03 AM, Noralf Trønnes wrote:
This switches the CMA helper drivers that use its fbdev emulation over
to the generic fbdev emulation. It's the first phase of using generic
fbdev. A later phase will use DRM client callbacks for the
lastclose/hotplug/remove callbacks.
There are currently 2 fbdev init/fini functions:
- drm_fb_cma_fbdev_init/drm_fb_cma_fbdev_fini
- drm_fbdev_cma_init/drm_fbdev_cma_fini
This is because the work on generic fbdev came up during a fbdev
refactoring and thus wasn't completed. No point in completing that
refactoring when drivers will soon move to drm_fb_helper_generic_probe().
tinydrm uses drm_fb_cma_fbdev_init_with_funcs().
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_cma_helper.c | 360 +---
include/drm/drm_fb_cma_helper.h | 3 -
2 files changed, 42 insertions(+), 321 deletions(-)
...
-static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
- struct drm_gem_cma_object *cma_obj)
-{
- struct fb_deferred_io *fbdefio;
- struct fb_ops *fbops;
-
- /*
-* Per device structures are needed because:
-* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
-* fbdefio: individual delays
-*/
- fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
- fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
- if (!fbdefio || !fbops) {
- kfree(fbdefio);
- kfree(fbops);
- return -ENOMEM;
- }
-
- /* can't be offset from vaddr since dirty() uses cma_obj */
- fbi->screen_buffer = cma_obj->vaddr;
- /* fb_deferred_io_fault() needs a physical address */
- fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer));
-
- *fbops = *fbi->fbops;
- fbi->fbops = fbops;
-
- fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
- fbdefio->deferred_io = drm_fb_helper_deferred_io;
- fbi->fbdefio = fbdefio;
- fb_deferred_io_init(fbi);
- fbi->fbops->fb_mmap = drm_fbdev_cma_deferred_io_mmap;
-
- return 0;
-}
-
-static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
-{
- if (!fbi->fbdefio)
- return;
-
- fb_deferred_io_cleanup(fbi);
- kfree(fbi->fbdefio);
- kfree(fbi->fbops);
-}
-
-static int
-drm_fbdev_cma_create(struct drm_fb_helper *helper,
- struct drm_fb_helper_surface_size *sizes)
-{
- struct drm_fbdev_cma *fbdev_cma = to_fbdev_cma(helper);
- struct drm_device *dev = helper->dev;
- struct drm_gem_cma_object *obj;
- struct drm_framebuffer *fb;
- unsigned int bytes_per_pixel;
- unsigned long offset;
- struct fb_info *fbi;
- size_t size;
- int ret;
-
- DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
- sizes->surface_width, sizes->surface_height,
- sizes->surface_bpp);
-
- bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
- size = sizes->surface_width * sizes->surface_height * bytes_per_pixel;
- obj = drm_gem_cma_create(dev, size);
- if (IS_ERR(obj))
- return -ENOMEM;
-
- fbi = drm_fb_helper_alloc_fbi(helper);
- if (IS_ERR(fbi)) {
- ret = PTR_ERR(fbi);
- goto err_gem_free_object;
- }
-
- fb = drm_gem_fbdev_fb_create(dev, sizes, 0, &obj->base,
-fbdev_cma->fb_funcs);
- if (IS_ERR(fb)) {
- dev_err(dev->dev, "Failed to allocate DRM framebuffer.\n");
- ret = PTR_ERR(fb);
- goto err_fb_info_destroy;
- }
-
- helper->fb = fb;
-
- fbi->par = helper;
- fbi->flags = FBINFO_FLAG_DEFAULT;
- fbi->fbops = &drm_fbdev_cma_ops;
-
- drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);
- drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height);
-
- offset = fbi->var.xoffset * bytes_per_pixel;
- offset += fbi->var.yoffset * fb->pitches[0];
-
- dev->mode_config.fb_base = (resource_size_t)obj->paddr;
- fbi->screen_base = obj->vaddr + offset;
- fbi->fix.smem_start = (unsigned long)(obj->paddr + offset);
Hey Noralf, all,
I've been digging for a bit on the regression that this patch has
tripped on the HiKey board as reported here:
https://lkml.org/lkml/2018/8/16/81
The first issue was that the kirin driver was setting
mode_config.max_width/height = 2048, which was causing errors as the
the requested resolution was 1920x2160 (due to surfaceflinger
requesting y*2 for page flipping). This was relatively simple enough
to figure out and fix, but bumping the values up on its own didn't
seem to resolve the issue entirely, as I started to see hard hangs on
bootup when userspace started using the emulated fbdev device.
After
[PATCH v5 3/7] drm/bridge/synopsys: dsi: add ability to have glue-specific attach and detach
With the regular means of adding the dsi-component in probe it creates
a race condition with the panel probing, as the panel device only gets
created after the dsi-bus got created.
When the panel-driver is build as a module it currently fails hard as the
panel cannot be probed directly:
dw_mipi_dsi_bind()
__dw_mipi_dsi_probe()
creates dsi bus
creates panel device
triggers panel module load
panel not probed (module not loaded or panel probe slow)
drm_bridge_attach
fails with -EINVAL due to empty panel_bridge
Additionally the panel probing can run concurrently with dsi bringup
making it possible that the panel can already be found but dsi-attach
hasn't finished running.
To solve that cleanly we may want to only create the component after
the panel has finished probing, by calling component_add from the
host-attach dsi callback.
As that is specific to glue drivers, add a new struct for host_ops
so that glue drivers can tell the bridge to call specific functions
after the common host-attach and before the common host-detach run.
Suggested-by: Andrzej Hajda
Reviewed-by: Andrzej Hajda
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 15 +++
include/drm/bridge/dw_mipi_dsi.h | 8
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index bb4aeca5c0f9..3962e5d84e1e 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -270,6 +270,7 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
struct mipi_dsi_device *device)
{
struct dw_mipi_dsi *dsi = host_to_dsi(host);
+ const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data;
struct drm_bridge *bridge;
struct drm_panel *panel;
int ret;
@@ -300,6 +301,12 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
drm_bridge_add(&dsi->bridge);
+ if (pdata->host_ops && pdata->host_ops->attach) {
+ ret = pdata->host_ops->attach(pdata->priv_data, device);
+ if (ret < 0)
+ return ret;
+ }
+
return 0;
}
@@ -307,6 +314,14 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host
*host,
struct mipi_dsi_device *device)
{
struct dw_mipi_dsi *dsi = host_to_dsi(host);
+ const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data;
+ int ret;
+
+ if (pdata->host_ops && pdata->host_ops->detach) {
+ ret = pdata->host_ops->detach(pdata->priv_data, device);
+ if (ret < 0)
+ return ret;
+ }
drm_of_panel_bridge_remove(host->dev->of_node, 1, 0);
diff --git a/include/drm/bridge/dw_mipi_dsi.h b/include/drm/bridge/dw_mipi_dsi.h
index 6d7f8eb5d9f2..a9c03099cf3e 100644
--- a/include/drm/bridge/dw_mipi_dsi.h
+++ b/include/drm/bridge/dw_mipi_dsi.h
@@ -19,6 +19,13 @@ struct dw_mipi_dsi_phy_ops {
unsigned int *lane_mbps);
};
+struct dw_mipi_dsi_host_ops {
+ int (*attach)(void *priv_data,
+ struct mipi_dsi_device *dsi);
+ int (*detach)(void *priv_data,
+ struct mipi_dsi_device *dsi);
+};
+
struct dw_mipi_dsi_plat_data {
void __iomem *base;
unsigned int max_data_lanes;
@@ -27,6 +34,7 @@ struct dw_mipi_dsi_plat_data {
const struct drm_display_mode *mode);
const struct dw_mipi_dsi_phy_ops *phy_ops;
+ const struct dw_mipi_dsi_host_ops *host_ops;
void *priv_data;
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 7/7] drm/rockchip: dsi: add dual mipi support
Add the Rockchip-sepcific dual-dsi setup and hook it into the VOP as well.
As described in the general dual-dsi devicetree binding, the panel should
define two input ports and point each of them to one of the used dsi-
controllers, as well as declare one of them as clock-master.
This is used to determine the dual-dsi state and get access to both
controller instances.
Signed-off-by: Heiko Stuebner
v4:
add component directly in probe when adding empty dsi slave controller
v5:
use driver-internal mechanism to find dual dsi slave
---
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 105 ++
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 4 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
5 files changed, 114 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index b3aae8439aa3..e4aee2ccbf4d 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -218,6 +218,10 @@ struct dw_mipi_dsi_rockchip {
struct clk *grf_clk;
struct clk *phy_cfg_clk;
+ /* dual-channel */
+ bool is_slave;
+ struct dw_mipi_dsi_rockchip *slave;
+
unsigned int lane_mbps; /* per lane */
u16 input_div;
u16 feedback_div;
@@ -226,6 +230,7 @@ struct dw_mipi_dsi_rockchip {
struct dw_mipi_dsi *dmd;
const struct rockchip_dw_dsi_chip_data *cdata;
struct dw_mipi_dsi_plat_data pdata;
+ int devcnt;
};
struct dphy_pll_parameter_map {
@@ -602,6 +607,8 @@ dw_mipi_dsi_encoder_atomic_check(struct drm_encoder
*encoder,
}
s->output_type = DRM_MODE_CONNECTOR_DSI;
+ if (dsi->slave)
+ s->output_flags = ROCKCHIP_OUTPUT_DSI_DUAL;
return 0;
}
@@ -617,6 +624,8 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
return;
pm_runtime_get_sync(dsi->dev);
+ if (dsi->slave)
+ pm_runtime_get_sync(dsi->slave->dev);
/*
* For the RK3399, the clk of grf must be enabled before writing grf
@@ -630,6 +639,8 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
}
dw_mipi_dsi_rockchip_config(dsi, mux);
+ if (dsi->slave)
+ dw_mipi_dsi_rockchip_config(dsi->slave, mux);
clk_disable_unprepare(dsi->grf_clk);
}
@@ -638,6 +649,8 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder
*encoder)
{
struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
+ if (dsi->slave)
+ pm_runtime_put(dsi->slave->dev);
pm_runtime_put(dsi->dev);
}
@@ -673,14 +686,76 @@ static int rockchip_dsi_drm_create_encoder(struct
dw_mipi_dsi_rockchip *dsi,
return 0;
}
+static int dw_mipi_dsi_rockchip_match_second(struct device *dev, void *data)
+{
+ struct dw_mipi_dsi_rockchip *dsi = data;
+ struct drm_bridge *bridge1, *bridge2;
+ struct drm_panel *panel1, *panel2;
+ int ret;
+
+ if (dsi->dev->of_node == dev->of_node)
+ return 0;
+
+ ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0,
+ &panel1, &bridge1);
+ if (ret)
+ return ret;
+
+ ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
+ &panel2, &bridge2);
+ if (ret)
+ return ret;
+
+ return (panel1 == panel2) && (bridge1 == bridge2);
+}
+
static int dw_mipi_dsi_rockchip_bind(struct device *dev,
struct device *master,
void *data)
{
struct dw_mipi_dsi_rockchip *dsi = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
+ struct device *second;
+ bool master1, master2;
int ret;
+ second = driver_find_device(dsi->dev->driver, NULL, dsi,
+ dw_mipi_dsi_rockchip_match_second);
+ if (IS_ERR(second))
+ return PTR_ERR(second);
+
+ if (second) {
+ master1 = of_property_read_bool(dsi->dev->of_node,
+ "clock-master");
+ master2 = of_property_read_bool(second->of_node,
+ "clock-master");
+
+ if (master1 && master2) {
+ DRM_DEV_ERROR(dsi->dev, "only one clock-master
allowed\n");
+ return -EINVAL;
+ }
+
+ if (!master1 && !master2) {
+ DRM_DEV_ERROR(dsi->dev, "no clock-master defined\n");
+ return -EINVAL;
+ }
+
+ /* we are the slave in dual-DSI */
+ if (!master1) {
+ dsi->is_slave =
[PATCH v5 2/7] drm/bridge/synopsys: dsi: don't call __dw_mipi_dsi_probe from dw_mipi_dsi_bind
__dw_mipi_dsi_probe() does all the grabbing of resources and does it using
devm-helpers. So this is happening on each try of master bringup possibly
slowing down things a lot.
Drivers using the component framework may instead want to call
dw_mipi_dsi_probe separately in their probe function to setup resources
early. That way the dsi bus also gets created earlier and also not
recreated on each bind-try, so that attached panels can load their modules
and be probed way before the bridge-attach in the bind call.
So drop the call to __dw_mipi_dsi_probe and modify the function to take
a struct dw_mipi_dsi instead of the platform-device.
Signed-off-by: Heiko Stuebner
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 15 +++
include/drm/bridge/dw_mipi_dsi.h | 5 +
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 07cde255cab2..bb4aeca5c0f9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -966,31 +966,22 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
/*
* Bind/unbind API, used from platforms based on the component framework.
*/
-struct dw_mipi_dsi *
-dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_mipi_dsi_plat_data *plat_data)
+int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct drm_encoder *encoder)
{
- struct dw_mipi_dsi *dsi;
int ret;
- dsi = __dw_mipi_dsi_probe(pdev, plat_data);
- if (IS_ERR(dsi))
- return dsi;
-
ret = drm_bridge_attach(encoder, &dsi->bridge, NULL);
if (ret) {
- dw_mipi_dsi_remove(dsi);
DRM_ERROR("Failed to initialize bridge with drm\n");
- return ERR_PTR(ret);
+ return ret;
}
- return dsi;
+ return ret;
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_bind);
void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi)
{
- __dw_mipi_dsi_remove(dsi);
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_unbind);
diff --git a/include/drm/bridge/dw_mipi_dsi.h b/include/drm/bridge/dw_mipi_dsi.h
index d9c6d549f971..6d7f8eb5d9f2 100644
--- a/include/drm/bridge/dw_mipi_dsi.h
+++ b/include/drm/bridge/dw_mipi_dsi.h
@@ -35,10 +35,7 @@ struct dw_mipi_dsi *dw_mipi_dsi_probe(struct platform_device
*pdev,
const struct dw_mipi_dsi_plat_data
*plat_data);
void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi);
-struct dw_mipi_dsi *dw_mipi_dsi_bind(struct platform_device *pdev,
-struct drm_encoder *encoder,
-const struct dw_mipi_dsi_plat_data
-*plat_data);
+int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct drm_encoder *encoder);
void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi);
#endif /* __DW_MIPI_DSI__ */
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/7] drm/bridge/synopsys: dsi: move mipi_dsi_host_unregister to __dw_mipi_dsi_remove
Right now the host is only unregistered when the driver is used via the
bridge api and not via the component api, leading to the host staying
registered in cases like probe deferral.
So move the host unregister to the general remove function, so that it
gets cleaned up in all cases.
Signed-off-by: Heiko Stuebner
Reviewed-by: Andrzej Hajda
Reviewed-by: Philippe Cornu
Tested-by: Philippe Cornu
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index fd7999642cf8..07cde255cab2 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -941,6 +941,8 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
static void __dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
{
+ mipi_dsi_host_unregister(&dsi->dsi_host);
+
pm_runtime_disable(dsi->dev);
}
@@ -957,8 +959,6 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_probe);
void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
{
- mipi_dsi_host_unregister(&dsi->dsi_host);
-
__dw_mipi_dsi_remove(dsi);
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 5/7] drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver
From: Nickey Yang Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare MIPI DSI host controller bridge and remove the old separate one. changes: v2: add err_pllref, remove unnecessary encoder.enable & disable correct spelling mistakes v3: call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind() fix typo, use of_device_get_match_data(), change some bind() logic into probe() add 'dev_set_drvdata()' v4: return -EINVAL when can not get best_freq add a clarifying comment when get vco add review tag v5: keep our power domain enabled while touching GRF v6: change func name dw_mipi_encoder_disable to dw_mipi_dsi_encoder_disable v7: none v8: Heiko add Archit's Review tag adapt to recent changes in the original rockchip-dsi driver beautify grf-handling split hw-setup (resources, dsi-host) from bind into probe v2-new: Heiko add SPDX header instead of license blurb drop old versioning to not confuse people v3-new: Heiko include ordering moved hwaccess from mode_set to enable callback move pllref_clk enablement to bind (needed by bridge mode_set->lane_mbps) v4-new: Heiko rebase against recent rockchip-dsi changes move to call component_add in the new glue host-attach Signed-off-by: Nickey Yang Signed-off-by: Brian Norris Reviewed-by: Brian Norris Reviewed-by: Sean Paul Reviewed-by: Archit Taneja Reviewed-by: Andrzej Hajda Signed-off-by: Heiko Stuebner --- drivers/gpu/drm/rockchip/Kconfig |2 +- drivers/gpu/drm/rockchip/Makefile |2 +- .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 939 drivers/gpu/drm/rockchip/dw-mipi-dsi.c| 1349 - drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +- 6 files changed, 943 insertions(+), 1353 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 0ccc76217ee4..9eb4795596d3 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -7,7 +7,7 @@ config DRM_ROCKCHIP select VIDEOMODE_HELPERS select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP select DRM_DW_HDMI if ROCKCHIP_DW_HDMI - select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI + select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC help Choose this option if you have a Rockchip soc chipset. diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index a314e2109e76..0f22dad1c996 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -11,7 +11,7 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o -rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o +rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi-rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c new file mode 100644 index ..b3aae8439aa3 --- /dev/null +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c @@ -0,0 +1,939 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd + * Author: + * Chris Zhong + * Nickey Yang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "rockchip_drm_drv.h" +#include "rockchip_drm_vop.h" + +#define DSI_PHY_RSTZ 0xa0 +#define PHY_DISFORCEPLL0 +#define PHY_ENFORCEPLL BIT(3) +#define PHY_DISABLECLK 0 +#define PHY_ENABLECLK BIT(2) +#define PHY_RSTZ 0 +#define PHY_UNRSTZ BIT(1) +#define PHY_SHUTDOWNZ 0 +#define PHY_UNSHUTDOWNZBIT(0) + +#define DSI_PHY_IF_CFG 0xa4 +#define N_LANES(n) n) - 1) & 0x3) << 0) +#define PHY_STOP_WAIT_TIME(cycle) (((cycle) & 0xff) << 8) + +#define DSI_PHY_STATUS 0xb0 +#define LOCK BIT(0) +#define STOP_STATE_CLK_LANEBIT(2) + +#define DSI_PHY_TST_CTRL0 0xb4 +#define PHY_TESTCLKBIT(1) +#define PHY_UNTESTCLK 0 +#define PHY_TESTCLRBIT(0) +#define PHY_UNTESTCLR 0 + +#define DSI_PHY_TST_CTRL1 0xb8 +#define PHY_TES
[PATCH v5 4/7] dt-bindings: display: rockchip: update DSI controller
From: Nickey Yang
This patch update describe panel/port links, including
unit addresses in documentation of device tree bindings
for the rockchip DSI controller based on the Synopsys
DesignWare MIPI DSI host controller.
Signed-off-by: Nickey Yang
Reviewed-by: Brian Norris
Reviewed-by: Rob Herring
Signed-off-by: Heiko Stuebner
---
.../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
index 6bb59ab39f2f..ce4c1fc9116c 100644
---
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -14,6 +14,8 @@ Required properties:
- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
- ports: contain a port node with endpoint definitions as defined in [2].
For vopb,set the reg = <0> and set the reg = <1> for vopl.
+- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
+- video port 1 for either a panel or subsequent encoder
Optional properties:
- power-domains: a phandle to mipi dsi power domain node.
@@ -40,11 +42,12 @@ Example:
ports {
#address-cells = <1>;
#size-cells = <0>;
- reg = <1>;
- mipi_in: port {
+ mipi_in: port@0 {
+ reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
+
mipi_in_vopb: endpoint@0 {
reg = <0>;
remote-endpoint = <&vopb_out_mipi>;
@@ -54,6 +57,16 @@ Example:
remote-endpoint = <&vopl_out_mipi>;
};
};
+
+ mipi_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_out_panel: endpoint {
+ remote-endpoint = <&panel_in_mipi>;
+ };
+ };
};
panel {
@@ -64,5 +77,11 @@ Example:
pinctrl-names = "default";
pinctrl-0 = <&lcd_en>;
backlight = <&backlight>;
+
+ port {
+ panel_in_mipi: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
};
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/8] drm/rockchip: migrate to common dw-mipi-dsi bridge and dual-dsi
The Rockchip DSI driver was separate till now, not using the common bridge driver that was introduced a bit later. So this series migrates over to use that common bridge driver and then also adds support for dual-dsi to both the bridge and Rockchip glue code. The bridge-migration itself is based on Nickeys earlier v8 work, but adapted to current kernels and with a new split between probe and bind, so that we do not create and drop the dsi-host on each deferred bind attempt. changes in v2: - rebase against newer drm code (dsi-bridge+rockchip changes) - add SPDX header to new glue driver - expect regular interface lanes from panel (like 4) not the double number Similar to tegra - keep links to both master and slave changes in v3: - don't defer in bridge_attach, instead add ability to check for finalized panel attachement, for example in bind - address bridge-conversion comments from Andrzej: - include ordering - moved hwaccess from mode_set to enable callback - move pllref_clk enablement to bind (needed by bridge mode_set->lane_mbps) - limited slave settings to dw_mipi_dsi_set_slave - address dual-dsi comments from Philippe: - remove unneeded separate variables - remove unneeded second slave settings - disable slave before master - lane-sum calculation comments changes in v4: - rebase against some legacy rockchip-dsi changes - add dsi-component only after panel has attached to dsi host This solves quite some concurrency problems that happen when trying to determine dsi-panel availability changes in v5: - use driver-internal method to find second host - drop of-graph based dsi method for it Unchanged from review comments: - kept dw_mipi_dsi_bind, as the dsi->bridge member is only part of the bridge drivers struct, so not accessible from glue drivers - kept dual-dsi handling that mimicks tegra Heiko Stuebner (4): drm/bridge/synopsys: dsi: move mipi_dsi_host_unregister to __dw_mipi_dsi_remove drm/bridge/synopsys: dsi: don't call __dw_mipi_dsi_probe from dw_mipi_dsi_bind drm/bridge/synopsys: dsi: add ability to have glue-specific attach and detach drm/rockchip: dsi: add dual mipi support Nickey Yang (3): dt-bindings: display: rockchip: update DSI controller drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver drm/bridge/synopsys: dsi: add dual-dsi support .../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 114 +- drivers/gpu/drm/rockchip/Kconfig |2 +- drivers/gpu/drm/rockchip/Makefile |2 +- .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1044 + drivers/gpu/drm/rockchip/dw-mipi-dsi.c| 1349 - drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h |3 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c |3 + drivers/gpu/drm/rockchip/rockchip_drm_vop.h |4 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c |1 + include/drm/bridge/dw_mipi_dsi.h | 14 +- 12 files changed, 1182 insertions(+), 1379 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 6/7] drm/bridge/synopsys: dsi: add dual-dsi support
From: Nickey Yang
Allow to also drive a slave dw-mipi-dsi controller in a dual-dsi
setup. This will require additional implementation-specific
code to look up the slave instance and do specific setup.
Also will probably need code in the specific crtcs as dual-dsi
does not equal two separate dsi outputs.
To activate, the implementation-specific code should set the slave
using dw_mipi_dsi_set_slave() before calling __dw_mipi_dsi_bind().
v2:
- expect real interface number of lanes
- keep links to both master and slave
v3:
- remove unneeded separate variables
- remove unneeded second slave settings
- disable slave before master
- lane-sum calculation comments
Signed-off-by: Nickey Yang
Signed-off-by: Heiko Stuebner
Tested-by: Philippe Cornu
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 80 +--
include/drm/bridge/dw_mipi_dsi.h | 1 +
2 files changed, 75 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 3962e5d84e1e..2f4b145b73af 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -230,9 +230,20 @@ struct dw_mipi_dsi {
u32 format;
unsigned long mode_flags;
+ struct dw_mipi_dsi *master; /* dual-dsi master ptr */
+ struct dw_mipi_dsi *slave; /* dual-dsi slave ptr */
+
const struct dw_mipi_dsi_plat_data *plat_data;
};
+/*
+ * Check if either a link to a master or slave is present
+ */
+static inline bool dw_mipi_is_dual_mode(struct dw_mipi_dsi *dsi)
+{
+ return dsi->slave || dsi->master;
+}
+
/*
* The controller should generate 2 frames before
* preparing the peripheral.
@@ -456,10 +467,17 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
mipi_dsi_host *host,
}
dw_mipi_message_config(dsi, msg);
+ if (dsi->slave)
+ dw_mipi_message_config(dsi->slave, msg);
ret = dw_mipi_dsi_write(dsi, &packet);
if (ret)
return ret;
+ if (dsi->slave) {
+ ret = dw_mipi_dsi_write(dsi->slave, &packet);
+ if (ret)
+ return ret;
+ }
if (msg->rx_buf && msg->rx_len) {
ret = dw_mipi_dsi_read(dsi, msg);
@@ -598,7 +616,11 @@ static void dw_mipi_dsi_video_packet_config(struct
dw_mipi_dsi *dsi,
* DSI_VNPCR.NPSIZE... especially because this driver supports
* non-burst video modes, see dw_mipi_dsi_video_mode_config()...
*/
- dsi_write(dsi, DSI_VID_PKT_SIZE, VID_PKT_SIZE(mode->hdisplay));
+
+ dsi_write(dsi, DSI_VID_PKT_SIZE,
+ dw_mipi_is_dual_mode(dsi) ?
+ VID_PKT_SIZE(mode->hdisplay / 2) :
+ VID_PKT_SIZE(mode->hdisplay));
}
static void dw_mipi_dsi_command_mode_config(struct dw_mipi_dsi *dsi)
@@ -770,24 +792,43 @@ static void dw_mipi_dsi_bridge_post_disable(struct
drm_bridge *bridge)
*/
dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
+ if (dsi->slave) {
+ dw_mipi_dsi_disable(dsi->slave);
+ clk_disable_unprepare(dsi->slave->pclk);
+ pm_runtime_put(dsi->slave->dev);
+ }
dw_mipi_dsi_disable(dsi);
+
clk_disable_unprepare(dsi->pclk);
pm_runtime_put(dsi->dev);
}
-static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+static unsigned int dw_mipi_dsi_get_lanes(struct dw_mipi_dsi *dsi)
+{
+ /* this instance is the slave, so add the master's lanes */
+ if (dsi->master)
+ return dsi->master->lanes + dsi->lanes;
+
+ /* this instance is the master, so add the slave's lanes */
+ if (dsi->slave)
+ return dsi->lanes + dsi->slave->lanes;
+
+ /* single-dsi, so no other instance to consider */
+ return dsi->lanes;
+}
+
+static void dw_mipi_dsi_mode_set(struct dw_mipi_dsi *dsi,
+ struct drm_display_mode *adjusted_mode)
{
- struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
void *priv_data = dsi->plat_data->priv_data;
int ret;
+ u32 lanes = dw_mipi_dsi_get_lanes(dsi);
clk_prepare_enable(dsi->pclk);
ret = phy_ops->get_lane_mbps(priv_data, adjusted_mode, dsi->mode_flags,
-dsi->lanes, dsi->format, &dsi->lane_mbps);
+lanes, dsi->format, &dsi->lane_mbps);
if (ret)
DRM_DEBUG_DRIVER("Phy get_lane_mbps() failed\n");
@@ -819,12 +860,25 @@ static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
*bridge,
dw_mipi_dsi_set_mode(dsi, 0);
}
+static void dw_mipi
Re: [PATCH v4 6/8] drm/dsi: add helper function to find the second host in a dual-dsi setup
Hi Andrzej, Am Montag, 20. August 2018, 13:37:24 CEST schrieb Andrzej Hajda: > On 14.08.2018 12:26, Heiko Stuebner wrote: > > >From a specified output port of one dsi controller this function allows to > > iterate over the list of registered dsi controllers trying to find a second > > instance connected to the same display, like it is used in dual-dsi setups. > > As I said earlier it looks for me incorrectly. You create helper to > access/control one DSI controller from another but there is no point in > doing it. If CRTC is able to send video stream via two links it should > be CRTC's responsibility to setup and use DSI controllers attached to > these links. If the panel is able to combine stream from two DSI links > into one image it should be panel's responsibility to inform DSI > controllers about each link's configuration. > > Moreover from usage of this helper (patch 8/8) it looks like you > assumes, that second host must be also synopsys, this is not > true/generic at all. > > I know there could be many obstacles in alternative approach, so you > really insist on this hack, please use it inside the driver, you can use > for example driver_for_each_device/driver_find_device to find 2nd DSI host. Ok, I'll move that inside the rockchip-driver. My rationale still is that both msm (with a Committer-Signed-off by Rob Clark) and Tegra (code from Thierry), do follow the expectation of two controllers of the same type) ... people doing graphics stuff way longer than me. So I'd like to believe the valid issue you are raising will have been discussed at least two times already ;-) . So I really prefer not to open that can of worms myself if I don't have to ;-) . Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/5] drm/amdgpu: use bulk moves for efficient VM LRU handling (v4)
Am 21.08.2018 um 15:43 schrieb Huang Rui:
On Mon, Aug 20, 2018 at 09:17:12PM +0800, Christian König wrote:
Am 20.08.2018 um 08:05 schrieb Huang Rui:
On Fri, Aug 17, 2018 at 06:38:16PM +0800, Koenig, Christian wrote:
Am 17.08.2018 um 12:08 schrieb Huang Rui:
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end of the LRU, and impact performance seriously.
Then Christian provided a workaround to not move PD/PT BOs on LRU with below
patch:
"drm/amdgpu: band aid validating VM PTs"
Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae
However, the final solution should bulk move all PD/PT and PerVM BOs on the LRU
instead of one by one.
Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which need to be
validated we move all BOs together to the end of the LRU without dropping the
lock for the LRU.
While doing so we note the beginning and end of this block in the LRU list.
Now when amdgpu_vm_validate_pt_bos() is called and we don't have anything to do,
we don't move every BO one by one, but instead cut the LRU list into pieces so
that we bulk move everything to the end in just one operation.
Test data:
+--+-+---+---+
| |The Talos|Clpeak(OCL)|BusSpeedReadback(OCL)
|
| |Principle(Vulkan)| |
|
++
| | | |0.319 ms(1k) 0.314 ms(2K) 0.308
ms(4K) |
| Original | 147.7 FPS | 76.86 us |0.307 ms(8K) 0.310 ms(16K)
|
++
| Orignial + WA| | |0.254 ms(1K) 0.241 ms(2K)
|
|(don't move | 162.1 FPS | 42.15 us |0.230 ms(4K) 0.223 ms(8K) 0.204
ms(16K)|
|PT BOs on LRU)| | |
|
++
| Bulk move| 163.1 FPS | 40.52 us |0.244 ms(1K) 0.252 ms(2K) 0.213
ms(4K) |
| | | |0.214 ms(8K) 0.225 ms(16K)
|
+--+-+---+---+
After test them with above three benchmarks include vulkan and opencl. We can
see the visible improvement than original, and even better than original with
workaround.
v2: move all BOs include idle, relocated, and moved list to the end of LRU and
put them together.
v3: remove unused parameter and use list_for_each_entry instead of the one with
save entry.
v4: move the amdgpu_vm_move_to_lru_tail after command submission, at that time,
all bo will be back on idle list.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
Tested-by: Dieter Nützel
Acked-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 11 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 71
++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 11 +-
3 files changed, 75 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 502b94f..9fbdf02 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1260,6 +1260,16 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
return 0;
}
+static void amdgpu_cs_vm_move_on_lru(struct amdgpu_device *adev,
+struct amdgpu_cs_parser *p)
+{
+ struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
+ struct amdgpu_vm *vm = &fpriv->vm;
+
+ if (vm->validated)
That check belongs inside amdgpu_vm_move_to_lru_tail().
+ amdgpu_vm_move_to_lru_tail(adev, vm);
+}
+
int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct drm_file
*filp)
{
struct amdgpu_device *adev = dev->dev_private;
@@ -1310,6 +1320,7 @@ int amdgpu_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
r = amdgpu_cs_submit(&parser, cs);
+ amdgpu_cs_vm_move_on_lru(adev, &parser);
out:
amdgpu_cs_parser_fini(&parser, r, reserved_buffers);
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 9c84770..037cfbc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -268,6 +268,53 @@ void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
}
/**
+ * amdgpu_vm_move_to_lru_tail_by_list - move one list of BOs to end of LRU
+ *
+ * @vm: vm providing the BOs
+ * @list: the list that sto
Re: [PATCH v4 3/8] drm/bridge/synopsys: dsi: add ability to have glue-specific attach and detach
Hi,
Am Montag, 20. August 2018, 12:34:37 CEST schrieb Andrzej Hajda:
> On 14.08.2018 12:26, Heiko Stuebner wrote:
> > With the regular means of adding the dsi-component in probe it creates
> > a race condition with the panel probing, as the panel device only gets
> > created after the dsi-bus got created.
> >
> > When the panel-driver is build as a module it currently fails hard as the
> > panel cannot be probed directly:
> >
> > dw_mipi_dsi_bind()
> > __dw_mipi_dsi_probe()
> > creates dsi bus
> > creates panel device
> > triggers panel module load
> > panel not probed (module not loaded or panel probe slow)
> > drm_bridge_attach
> > fails with -EINVAL due to empty panel_bridge
> >
> > Additionally the panel probing can run concurrently with dsi bringup
> > making it possible that the panel can already be found but dsi-attach
> > hasn't finished running.
> >
> > To solve that cleanly we may want to only create the component after
> > the panel has finished probing, by calling component_add from the
> > host-attach dsi callback.
> >
> > As that is specific to glue drivers, add a new struct for host_ops
> > so that glue drivers can tell the bridge to call specific functions
> > after the common host-attach and before the common host-detach run.
>
> Sometimes I have an impression that core/glue driver architecture with
> callbacks to glue drivers is quite complicated, and smells mid-layer
> mistake :), I wonder if simple bunch of helpers with some base object
> wouldn't be better, but this is subject for other discussion.
>
> >
> > Suggested-by: Andrzej Hajda
> > Signed-off-by: Heiko Stuebner
> > @@ -300,6 +301,12 @@ static int dw_mipi_dsi_host_attach(struct
> > mipi_dsi_host *host,
> >
> > drm_bridge_add(&dsi->bridge);
> >
> > + if (pdata->host_ops && pdata->host_ops->attach) {
> > + ret = pdata->host_ops->attach(pdata->priv_data, device);
> > + if (ret < 0)
> > + return ret;
>
> It could be replaced by:
> return pdata->host_ops->attach(pdata->priv_data, device);
>
> But no strong feelings. With or without the change:
I'll keep it the way it is then ;-) .
My rationale is that the "return 0" below is the last line of this
function and returns the success.
The specialized attach is only called in a fraction of instances, so
having a return on success in there, might be surprising if later on
additional code gets added between the attach call and the return below
and might be missed to modify in that case, possibly causing breakage.
> > + }
> > +
> > return 0;
> > }
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/5] drm/amdgpu: use bulk moves for efficient VM LRU handling (v4)
On Mon, Aug 20, 2018 at 09:17:12PM +0800, Christian König wrote:
> Am 20.08.2018 um 08:05 schrieb Huang Rui:
> > On Fri, Aug 17, 2018 at 06:38:16PM +0800, Koenig, Christian wrote:
> >> Am 17.08.2018 um 12:08 schrieb Huang Rui:
> >>> I continue to work for bulk moving that based on the proposal by
> >>> Christian.
> >>>
> >>> Background:
> >>> amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move
> >>> all of
> >>> them on the end of LRU list one by one. Thus, that cause so many BOs
> >>> moved to
> >>> the end of the LRU, and impact performance seriously.
> >>>
> >>> Then Christian provided a workaround to not move PD/PT BOs on LRU with
> >>> below
> >>> patch:
> >>> "drm/amdgpu: band aid validating VM PTs"
> >>> Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae
> >>>
> >>> However, the final solution should bulk move all PD/PT and PerVM BOs on
> >>> the LRU
> >>> instead of one by one.
> >>>
> >>> Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which need
> >>> to be
> >>> validated we move all BOs together to the end of the LRU without dropping
> >>> the
> >>> lock for the LRU.
> >>>
> >>> While doing so we note the beginning and end of this block in the LRU
> >>> list.
> >>>
> >>> Now when amdgpu_vm_validate_pt_bos() is called and we don't have anything
> >>> to do,
> >>> we don't move every BO one by one, but instead cut the LRU list into
> >>> pieces so
> >>> that we bulk move everything to the end in just one operation.
> >>>
> >>> Test data:
> >>> +--+-+---+---+
> >>> | |The Talos|Clpeak(OCL)|BusSpeedReadback(OCL)
> >>>|
> >>> | |Principle(Vulkan)| |
> >>>|
> >>> ++
> >>> | | | |0.319 ms(1k) 0.314 ms(2K)
> >>> 0.308 ms(4K) |
> >>> | Original | 147.7 FPS | 76.86 us |0.307 ms(8K) 0.310 ms(16K)
> >>>|
> >>> ++
> >>> | Orignial + WA| | |0.254 ms(1K) 0.241 ms(2K)
> >>>|
> >>> |(don't move | 162.1 FPS | 42.15 us |0.230 ms(4K) 0.223 ms(8K)
> >>> 0.204 ms(16K)|
> >>> |PT BOs on LRU)| | |
> >>>|
> >>> ++
> >>> | Bulk move| 163.1 FPS | 40.52 us |0.244 ms(1K) 0.252 ms(2K)
> >>> 0.213 ms(4K) |
> >>> | | | |0.214 ms(8K) 0.225 ms(16K)
> >>>|
> >>> +--+-+---+---+
> >>>
> >>> After test them with above three benchmarks include vulkan and opencl. We
> >>> can
> >>> see the visible improvement than original, and even better than original
> >>> with
> >>> workaround.
> >>>
> >>> v2: move all BOs include idle, relocated, and moved list to the end of
> >>> LRU and
> >>> put them together.
> >>> v3: remove unused parameter and use list_for_each_entry instead of the
> >>> one with
> >>> save entry.
> >>> v4: move the amdgpu_vm_move_to_lru_tail after command submission, at that
> >>> time,
> >>> all bo will be back on idle list.
> >>>
> >>> Signed-off-by: Christian König
> >>> Signed-off-by: Huang Rui
> >>> Tested-by: Mike Lothian
> >>> Tested-by: Dieter Nützel
> >>> Acked-by: Chunming Zhou
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 11 ++
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 71
> >>> ++
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 11 +-
> >>>3 files changed, 75 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >>> index 502b94f..9fbdf02 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >>> @@ -1260,6 +1260,16 @@ static int amdgpu_cs_submit(struct
> >>> amdgpu_cs_parser *p,
> >>> return 0;
> >>>}
> >>>
> >>> +static void amdgpu_cs_vm_move_on_lru(struct amdgpu_device *adev,
> >>> + struct amdgpu_cs_parser *p)
> >>> +{
> >>> + struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
> >>> + struct amdgpu_vm *vm = &fpriv->vm;
> >>> +
> >>> + if (vm->validated)
> >> That check belongs inside amdgpu_vm_move_to_lru_tail().
> >>
> >>> + amdgpu_vm_move_to_lru_tail(adev, vm);
> >>> +}
> >>> +
> >>>int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct
> >>> drm_file *filp)
> >>>{
> >>> struct amdgpu_device *adev = dev->dev_private;
> >>> @@ -1310,6 +1320,7 @@ int amdgpu_cs_ioctl(struct drm_device *dev, void
> >>> *data, struct drm_file *filp
Re: [PATCH] drm/scheduler: avoid redundant shifting of the entity v2
Am 21.08.2018 um 15:29 schrieb Nayan Deshmukh: do not remove entity from the rq if the current rq is from the least loaded scheduler. Signed-off-by: Nayan Deshmukh Reviewed and pushed into our internal repo. Thanks, Christian. --- drivers/gpu/drm/scheduler/sched_entity.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index 1416edb2642a..a51c7654cc78 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -472,6 +472,9 @@ void drm_sched_entity_select_rq(struct drm_sched_entity *entity) return; rq = drm_sched_entity_get_free_sched(entity); + if (rq == entity->rq) + return; + spin_lock(&entity->rq_lock); drm_sched_rq_remove_entity(entity->rq, entity); entity->rq = rq; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Improve non-DPLL clock selection
And for the records, I forgot to add
On Tue, Aug 21, 2018 at 12:35:48PM +0200, jacopo mondi wrote:
> Hi Laurent,
>I run some tests, and here below there's a summary of what I see
>
> On Tue, Aug 21, 2018 at 01:12:40AM +0300, Laurent Pinchart wrote:
> > Hi Jacopo,
> >
> > On Tuesday, 21 August 2018 00:49:41 EEST Laurent Pinchart wrote:
> > > From: Jacopo Mondi
> > >
> > > DU channels not equipped with a DPLL use an SoC internal (provided by
> > > the CPG) or external clock source combined with a DU internal divider to
> > > generate the desired output dot clock frequency.
> > >
> > > The current clock selection procedure does not fully exploit the ability
> > > of external clock sources to generate the exact dot clock frequency by
> > > themselves, but relies instead on tuning the internal DU clock divider
> > > only, resulting in a less precise clock generation process.
> > >
> > > When possible, and desirable, ask the external clock source for the
> > > exact output dot clock frequency, and select the clock source that
> > > produces the frequency closest to the desired output dot clock.
> > >
> > > This patch specifically targets platforms (like Salvator-X[S] and ULCBs)
> > > where the DU's input dotclock.in is generated by the versaclock VC5
> > > clock source, which is capable of generating the exact rate the DU needs
> > > as pixel clock output.
> > >
> > > This patch fixes higher resolution modes which requires an high pixel
> > > clock output currently not working on non-HDMI DU channel (such as
> > > 1920x1080@60Hz on the VGA output).
> >
> > Just for the record, with this patch the following modes (as printed by
> > modetest) on the VGA output now produce correct result with my monitor:
> >
> > 1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 flags: nhsync, nvsync
> > 1600x1200 60 1600 1664 1856 2160 1200 1201 1204 1250 flags: phsync, pvsync
> > 1360x768 60 1360 1424 1536 1792 768 771 777 795 flags: phsync, pvsync
> >
> > The second mode used to not display at all, with a message telling that
> > timings were out of range, and the other two modes used to produce a
> > displayed
> > image partly shifted or scaled out of the screen boundaries.
> >
> > The following modes still produce an image partly out of the screen
> > boundaries.
> >
> > 1600x900 60 1600 1624 1704 1800 900 901 904 1000 flags: phsync, pvsync
> > 1280x960 60 1280 1376 1488 1800 960 961 964 1000 flags: phsync, pvsync
> > 1366x768 60 1366 1436 1579 1792 768 771 774 798 flags: phsync, pvsync
> > 1366x768 60 1366 1380 1436 1500 768 769 772 800 flags: phsync, pvsync
> > 1280x720 60 1280 1390 1430 1650 720 725 730 750 flags: phsync, pvsync
> >
> > And this one is reported to be out of range.
> >
> > 1920x1200 60 1920 2056 2256 2592 1200 1203 1209 1245 flags: nhsync, pvsync
> >
> > There is thus still room for improvement (some of the issues are possibly
> > due
> > to my monitor though), but there's also an improvement, and no noticeable
> > regression.
>
> The following table compares results obtained with the latest
> renesas-drivers, with and without this series applied on top.
>
> ---
> Legend:
> A = image badly aligned: not all 4 blue/red borders visible
> F = flickering: disturbance in the shown image
> B = broken: mode is not displayed
>
> Results: I = improvement
>R = regression
>
> renesas-drivers du_clk result
> 1024x768
> 1920x1200 F A I
> 1920x1200 A A
> 1920x1080 A A
> 1600x1200 B I
> 1680x1050
> 1680x1050
> 1400x1050
> 1400x1050
> 1600x900 A A
> 1280x1024
> 1440x900
> 1440x900
> 1280x960
> 1366x768 A A
> 1366x768 A A
> 1360x768 A R
> 1280x800
> 1280x768 A A
> 1280x768 A A
> 1280x768 A A
> 1280x720 A A
> 800x600
> 800x600
> 848x480
> 640x480
> ---
>
> Overall I see two modes that were broken or unusable due to flickering
> (1600x1200 and 1920x1200 respectively) to be now (almost) fixed.
>
> There are visible alignement problems on some modes on both versions,
> but I only see one 'regression' (the last 1360x768 that is now
> slightly not aligned).
>
> I guess monitors play a role here, with each one being different, but
> overall I guess our test results match.
>
>
> >
> > > Fixes: 1b30dbde8596 ("drm: rcar-du: Add support for external pixel clock")
> > > Signed-off-by: Jacopo Mondi
> > > [Factor out code to a helper function]
> > > Signed-off-by: Laurent Pinchart
> > >
Acked-by: Jacopo Mondi
To your re-worked version of the patch!
Thanks
j
> > > ---
> > > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 86
> > > +++
[PATCH] drm/scheduler: avoid redundant shifting of the entity v2
do not remove entity from the rq if the current rq is from the least loaded scheduler. Signed-off-by: Nayan Deshmukh --- drivers/gpu/drm/scheduler/sched_entity.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index 1416edb2642a..a51c7654cc78 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -472,6 +472,9 @@ void drm_sched_entity_select_rq(struct drm_sched_entity *entity) return; rq = drm_sched_entity_get_free_sched(entity); + if (rq == entity->rq) + return; + spin_lock(&entity->rq_lock); drm_sched_rq_remove_entity(entity->rq, entity); entity->rq = rq; -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/scheduler: avoid redundant shifting of the entity
My bad. How could I miss this :( Thanks for pointing it out. Nayan On Tue, Aug 21, 2018 at 4:09 PM Michel Dänzer wrote: > > On 2018-08-21 11:29 a.m., Nayan Deshmukh wrote: > > do not remove entity from the rq if the current rq is from > > the least loaded scheduler. > > > > Signed-off-by: Nayan Deshmukh > > --- > > drivers/gpu/drm/scheduler/sched_entity.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/scheduler/sched_entity.c > > b/drivers/gpu/drm/scheduler/sched_entity.c > > index 1416edb2642a..5cae6661ef2f 100644 > > --- a/drivers/gpu/drm/scheduler/sched_entity.c > > +++ b/drivers/gpu/drm/scheduler/sched_entity.c > > @@ -472,6 +472,9 @@ void drm_sched_entity_select_rq(struct drm_sched_entity > > *entity) > > return; > > > > rq = drm_sched_entity_get_free_sched(entity); > > +if (rq == entity->rq) > > +return; > > Looks like the newly added lines use spaces for indentation. The kernel > coding style uses tabs. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107581] Graphics Not Rendered Due to Missing 4.5 COMPAT Profile
https://bugs.freedesktop.org/show_bug.cgi?id=107581 --- Comment #14 from Benjamin Hodgetts --- I've just rebuilt Mesa again with your patch, no CCache or anything this time, just in case. I'm still getting no clouds on the loading screen (you can see the stars as white dot and the names, but there's no colour, everything is just black and white) and then when it gets "in game" the menu is there, but the screen is still just white. I wonder if the card is specific here: OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.26.0, 4.18.3-1-clear, LLVM 8.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.0-devel (git-9e5e3a8ead) -- 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 107581] Graphics Not Rendered Due to Missing 4.5 COMPAT Profile
https://bugs.freedesktop.org/show_bug.cgi?id=107581 --- Comment #13 from Benjamin Hodgetts --- AFAIK it works fine on Windows. The only people that had issues were people with old cards (e.g. 6000 series and below, due to lack of support). Just to clarify, you're using the latest version of the game, labeled "NEXT"? -- 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] drm/vkms: Add support for vkms work without vblank
On Mon, Aug 20, 2018 at 08:55:44PM -0300, Rodrigo Siqueira wrote:
> Currently, vkms needs VBlank to work well. This patch adds another
> operation model that make vkms works without VBlank support.
>
> Signed-off-by: Rodrigo Siqueira
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 10 ++
> drivers/gpu/drm/vkms/vkms_drv.c | 12 ++--
> drivers/gpu/drm/vkms/vkms_drv.h | 1 +
> 3 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index bfe6e0312cc4..001fa5c1d326 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -145,12 +145,22 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
> static void vkms_crtc_atomic_enable(struct drm_crtc *crtc,
> struct drm_crtc_state *old_state)
> {
> + struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
> +
> + if (vkms_out->disable_vblank)
> + return;
> +
> drm_crtc_vblank_on(crtc);
> }
>
> static void vkms_crtc_atomic_disable(struct drm_crtc *crtc,
>struct drm_crtc_state *old_state)
> {
> + struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
> +
> + if (vkms_out->disable_vblank)
> + return;
> +
> drm_crtc_vblank_off(crtc);
> }
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 5d78bd97e69c..f30c4113d4c4 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -21,6 +21,10 @@
>
> static struct vkms_device *vkms_device;
>
> +static bool disable_vblank;
> +module_param_named(disablevblank, disable_vblank, bool, 0444);
> +MODULE_PARM_DESC(disablevblank, "Disable vblank interrupt");
I think the info output is much clearer, I'd rename this to virtual_hw,
with 0 as default, and a help text along of "Enable virtual HW mode
(disables vblanks and immediately completes flips)."
> +
> static const struct file_operations vkms_driver_fops = {
> .owner = THIS_MODULE,
> .open = drm_open,
> @@ -105,9 +109,13 @@ static int __init vkms_init(void)
> goto out_fini;
> }
>
> - vkms_device->drm.irq_enabled = true;
> + vkms_device->output.disable_vblank = disable_vblank;
> + vkms_device->drm.irq_enabled = !disable_vblank ? true : false;
> +
> + if (disable_vblank)
> + DRM_INFO("Virtual Hardware mode enabled");
>
> - ret = drm_vblank_init(&vkms_device->drm, 1);
> + ret = (disable_vblank) ? 0 : drm_vblank_init(&vkms_device->drm, 1);
> if (ret) {
> DRM_ERROR("Failed to vblank\n");
> goto out_fini;
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index f156c930366a..9ee862e6f7e5 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -52,6 +52,7 @@ struct vkms_output {
> struct drm_encoder encoder;
> struct drm_connector connector;
> struct hrtimer vblank_hrtimer;
> + bool disable_vblank;
> ktime_t period_ns;
> struct drm_pending_vblank_event *event;
> bool crc_enabled;
The vblank handling parts look correct to me.
Does kms_flip work with this? Virtual hw immediately completes the
drm_crtc_state->event in the atomic_update callback, that part seems to be
missing from your patch.
Also I like the idea of switching away from the generic -EINVAL to -ENOTTY
for when vblanks aren't supported. Do you have that somewhere (as a
separate patch).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] backlight: pwm_bl: switch to using "atomic" PWM API
Am Dienstag, 14. August 2018, 18:50:59 CEST schrieb Enric Balletbo i Serra: > The "atomic" API allows us to configure PWM period and duty_cycle and > enable it in one call. > > The patch also moves the pwm_init_state just before any use of the > pwm_state struct, this fixes a potential bug where pwm_get_state > can be called before pwm_init_state. > > Signed-off-by: Enric Balletbo i Serra On a Rockchip rk3399-scarlet tablet Tested-by: Heiko Stuebner This patch also _fixes_ the kernel bug below. Scarlet is not yet submitted upstream, but when I remove the brightness-levels and default-brightness-level properties in my wip devicetree files to rely on the newly introduced automatic level calculation, I end up with the following: [ 136.723586] Internal error: ptrace BRK handler: f20003e8 [#1] PREEMPT SMP [ 136.735920] Modules linked in: drm_panel_orientation_quirks pwm_bl(+) ip_tables x_tables ipv6 smsc95xx smsc75xx ax88179_178a asix usbnet phy_rockchip_pcie i2c_hid [ 136.752227] CPU: 5 PID: 1547 Comm: systemd-udevd Tainted: GW 4.18.0-12611-g04bcfe5fee2d-dirty #1033 [ 136.763916] Hardware name: Google Scarlet (DT) [ 136.763923] pstate: 8005 (Nzcv daif -PAN -UAO) [ 136.763943] pc : pwm_backlight_probe+0x610/0x850 [pwm_bl] [ 136.763958] lr : pwm_backlight_probe+0x108/0x850 [pwm_bl] [ 136.786349] sp : 0a33b930 [ 136.794421] x29: 0a33b930 x28: 0a33bdf0 [ 136.800373] x27: 0100 x26: 00ada110 [ 136.806327] x25: x24: 00ad9348 [ 136.806343] x23: 8000f1a3e400 x22: 08e29000 [ 136.818239] x21: 8000f1a3e410 x20: 8000f097a798 [ 136.824189] x19: 0a33b9a0 x18: [ 136.830137] x17: x16: [ 136.836156] x15: 0400 x14: 0400 [ 136.842104] x13: x12: 0001 [ 136.848052] x11: 0003 x10: 0101010101010101 [ 136.855639] x9 : fffd x8 : 7f7f7f7f7f7f7f7f [ 136.861588] x7 : x6 : 0005 [ 136.867727] x5 : 8000f150c900 x4 : 8000f1a3e610 [ 136.876571] x3 : 8000f097a880 x2 : [ 136.882519] x1 : 800016393500 x0 : [ 136.888481] Process systemd-udevd (pid: 1547, stack limit = 0x95c9ae43) [ 136.888484] Call trace: [ 136.888498] pwm_backlight_probe+0x610/0x850 [pwm_bl] [ 136.888523] platform_drv_probe+0x50/0xa0 [ 136.909550] really_probe+0x1c8/0x2a0 [ 136.914515] driver_probe_device+0x58/0x108 [ 136.919196] __driver_attach+0xdc/0xe0 [ 136.930103] driver_attach+0x20/0x28 [ 136.934286] bus_add_driver+0x1b8/0x228 [ 136.938580] driver_register+0x60/0x110 [ 136.942890] __platform_driver_register+0x40/0x48 [ 136.948172] pwm_backlight_driver_init+0x1c/0x1000 [pwm_bl] [ 136.948187] do_one_initcall+0x5c/0x180 [ 136.958709] do_init_module+0x58/0x1b0 [ 136.962905] load_module+0x1bfc/0x2200 [ 136.967104] __se_sys_finit_module+0xc0/0xd8 [ 136.971967] __arm64_sys_finit_module+0x14/0x20 [ 136.977038] el0_svc_common+0x60/0xe8 [ 136.981136] el0_svc_handler+0x24/0x88 [ 136.985333] el0_svc+0x8/0xc [ 136.988558] Code: 95eb49f6 1725 9101c3b3 17fffe8d (d4207d00) [ 136.995379] ---[ end trace 0f7902d334b84f12 ]--- ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107581] Graphics Not Rendered Due to Missing 4.5 COMPAT Profile
https://bugs.freedesktop.org/show_bug.cgi?id=107581 --- Comment #12 from Timothy Arceri --- (In reply to Benjamin Hodgetts from comment #11) > Applied the patch in attachment 141209 [details] [review] and rebuilt, but > the game looks the same. Something of note is that it's supposed to build > the shaders on the first load of the game, but the SHADERCACHE folder of the > game is remaining empty (I assume as the shaders are failing to build). The hack should make the planets/stars render correctly on the shader loading screen. It also helps the sky render in-game, everything else is missing but I'm sure it's because of the remaining failing shaders. All in all this game is extremely buggy. Do you know if it actually renders correctly on the AMD windows drivers? -- 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
[PATCH 2/2] drm/msm/dpu: fix for cursor blend issue
The current driver has the opaque blend mode set as the
default causing the black box effect around the cursor.
The fix enables choosing a different blend mode for alpha
enabled formats.
Signed-off-by: Sravanthi Kollukuduru
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 0cd9456a6c4c..fc6200c74614 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -297,14 +297,29 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
}
static void _dpu_crtc_setup_blend_cfg(struct dpu_crtc_mixer *mixer,
- struct dpu_plane_state *pstate)
+ struct dpu_plane_state *pstate, struct dpu_format *format)
{
struct dpu_hw_mixer *lm = mixer->hw_lm;
+ uint32_t blend_op;
/* default to opaque blending */
- lm->ops.setup_blend_config(lm, pstate->stage, 0XFF, 0,
- DPU_BLEND_FG_ALPHA_FG_CONST |
- DPU_BLEND_BG_ALPHA_BG_CONST);
+ blend_op = DPU_BLEND_FG_ALPHA_FG_CONST |
+ DPU_BLEND_BG_ALPHA_BG_CONST;
+
+ if (format->alpha_enable) {
+ /* coverage blending */
+ blend_op = DPU_BLEND_FG_ALPHA_FG_PIXEL |
+ DPU_BLEND_BG_ALPHA_FG_PIXEL |
+ DPU_BLEND_BG_INV_ALPHA;
+ }
+
+ lm->ops.setup_blend_config(lm, pstate->stage,
+ 0xFF, 0, blend_op);
+
+ DPU_DEBUG(
+ "format:%4.4s, alpha_en(%u) blend_op:0x%x\n",
+ (char *) &format->base.pixel_format,
+ format->alpha_enable, blend_op);
}
static void _dpu_crtc_program_lm_output_roi(struct drm_crtc *crtc)
@@ -401,7 +416,8 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
/* blend config update */
for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++) {
- _dpu_crtc_setup_blend_cfg(mixer + lm_idx, pstate);
+ _dpu_crtc_setup_blend_cfg(mixer + lm_idx,
+ pstate, format);
mixer[lm_idx].flush_mask |= flush_mask;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] Enable cursor plane on DPU
This patchset adds the cursor plane support on DPU driver. It also includes the fix for the black box artifacts seen around the cursor when enabled. Sravanthi Kollukuduru (2): drm/msm/dpu: enable cursor plane on dpu drm/msm/dpu: fix for cursor blend issue drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 31 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 53 +++--- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 35 +++-- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 9 + drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 4 +- 6 files changed, 76 insertions(+), 60 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm/dpu: enable cursor plane on dpu
Reserve DMA pipe for cursor plane and attach it to the
crtc during the initialization.
Signed-off-by: Sravanthi Kollukuduru
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 53 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 35 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 9 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 4 +-
6 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 80cbf75bc2ff..0cd9456a6c4c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -2082,7 +2082,8 @@ static const struct drm_crtc_helper_funcs
dpu_crtc_helper_funcs = {
};
/* initialize crtc */
-struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane *plane)
+struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane *plane,
+ struct drm_plane *cursor)
{
struct drm_crtc *crtc = NULL;
struct dpu_crtc *dpu_crtc = NULL;
@@ -2119,7 +2120,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
struct drm_plane *plane)
dpu_crtc_frame_event_work);
}
- drm_crtc_init_with_planes(dev, crtc, plane, NULL, &dpu_crtc_funcs,
+ drm_crtc_init_with_planes(dev, crtc, plane, cursor, &dpu_crtc_funcs,
NULL);
drm_crtc_helper_add(crtc, &dpu_crtc_helper_funcs);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index e87109e608e9..a89679160237 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -375,9 +375,11 @@ void dpu_crtc_complete_commit(struct drm_crtc *crtc,
* dpu_crtc_init - create a new crtc object
* @dev: dpu device
* @plane: base plane
+ * @cursor: cursor plane
* @Return: new crtc object or error
*/
-struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
*plane);
+struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane *plane,
+ struct drm_plane *cursor);
/**
* dpu_crtc_register_custom_event - api for enabling/disabling crtc event
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 44ee06398b1d..c04f3f3acae4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -29,6 +29,9 @@
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
+#define DMA_CURSOR_SDM845_MASK \
+ (DMA_SDM845_MASK | BIT(DPU_SSPP_CURSOR))
+
#define MIXER_SDM845_MASK \
(BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
@@ -174,45 +177,35 @@ static const struct dpu_sspp_sub_blks sdm845_dma_sblk_1 =
_DMA_SBLK("9", 2);
static const struct dpu_sspp_sub_blks sdm845_dma_sblk_2 = _DMA_SBLK("10", 3);
static const struct dpu_sspp_sub_blks sdm845_dma_sblk_3 = _DMA_SBLK("11", 4);
-#define SSPP_VIG_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
- { \
- .name = _name, .id = _id, \
- .base = _base, .len = 0x1c8, \
- .features = VIG_SDM845_MASK, \
- .sblk = &_sblk, \
- .xin_id = _xinid, \
- .type = SSPP_TYPE_VIG, \
- .clk_ctrl = _clkctrl \
- }
-
-#define SSPP_DMA_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
+#define SSPP_BLK(_name, _id, _base, _features, \
+ _sblk, _xinid, _type, _clkctrl) \
{ \
.name = _name, .id = _id, \
.base = _base, .len = 0x1c8, \
- .features = DMA_SDM845_MASK, \
+ .features = _features, \
.sblk = &_sblk, \
.xin_id = _xinid, \
- .type = SSPP_TYPE_DMA, \
+ .type = _type, \
.clk_ctrl = _clkctrl \
}
static struct dpu_sspp_cfg sdm845_sspp[] = {
- SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x4000,
- sdm845_vig_sblk_0, 0, DPU_CLK_CTRL_VIG0),
- SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x6000,
- sdm845_vig_sblk_1, 4, DPU_CLK_CTRL_VIG1),
- SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x8000,
- sdm845_vig_sblk_2, 8, DPU_CLK_CTRL_VIG2),
- SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xa000,
- sdm845_vig_sblk_3, 12, DPU_CLK_CTRL_VIG3),
- SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x24000,
- sdm845_dma_sblk_0, 1, DPU_CLK_CTRL_DMA0),
- SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x26000,
- sdm845_dma_sblk_1, 5, DPU_CLK_CTRL_DMA1),
- SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x28000,
- sdm845_dma_sblk_2, 9, DPU_CLK_CTRL_CURSOR0),
- SSPP_DMA_BLK("sspp_11", SSPP_DMA3, 0x2a000,
- sdm845_dma_sblk_3, 13, DPU_CLK_CTRL_CURSOR1),
+ SSPP_BLK("sspp_0",
Re: [PATCH 1/1] linux-firmware: add firmware for mhdp8546
On Mon, Aug 20, 2018 at 8:50 AM Damian Kos wrote: > > Add binary firmware for Cadence MHDP8546 DP bridge. > > Release version: 1.2.12 > > Signed-off-by: Damian Kos > --- > LICENCE.cadence | 63 +++ > WHENCE | 9 +++ > cadence/mhdp8546.bin | Bin 0 -> 131072 bytes > 3 files changed, 72 insertions(+) > create mode 100644 LICENCE.cadence > create mode 100755 cadence/mhdp8546.bin Applied and pushed out. Thanks. josh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PROTO][PATCH 00/10] R-Car D3 LVDS/HDMI support (with PLL)
> On August 20, 2018 at 11:50 AM Laurent Pinchart > wrote: > On Tuesday, 14 August 2018 16:49:54 EEST Ulrich Hecht wrote: > > Instructions for testing this are found at > > https://elinux.org/User:Uli/D3_HDMI_Test, including links to git trees based > > on renesas-drivers and drm-next, as well as config files for each. > > The instructions there end with > > "4. Boot kernel and observe activity on HDMI display." > > Does "activity" mean that I can expect a working HDMI output with a proper > image on the display ? :-) Yes, you can. :) CU Uli ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PROTO][PATCH 05/10] drm/bridge: adv7511: Add max-clock, min-vrefresh options
> On August 20, 2018 at 11:28 AM Laurent Pinchart > wrote: > > > Hi Ulrich, > > Thank you for the patch. > > On Tuesday, 14 August 2018 16:49:59 EEST Ulrich Hecht wrote: > > From: Koji Matsuoka > > > > This patch adds the option to specify a maximal clock and a minimal vertical > > refresh rate. > > What is this needed for ? Somewhere in the chain there is a component that will not tolerate clocks in excess of 135 MHz; if you don't limit it, the default for a 1920x1200 display is somewhere along 148 MHz, and the HDMI signal output is invalid. CU Uli ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linux-graphics-maintainer] [PATCH] drm/vmwgfx: Convert drm_atomic_helper_suspend/resume()
On Tue, Aug 21, 2018 at 3:04 AM, Deepak Singh Rawat wrote:
> Hi, thanks for the patch. Perhaps can get rid of vmw_kms_resume
> and vmw_kms_suspend, otherwise looks good to me.
Ok, will remove in v2.
>
>>
>> convert drm_atomic_helper_suspend/resume() to use
>> drm_mode_config_helper_suspend/resume().
>>
>> suspend_state can be removed from vmw_private as
>> it will not be used anymore.
>>
>> Signed-off-by: Ajit Negi
>> Signed-off-by: Souptick Joarder
>> ---
>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 6 +++---
>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 -
>> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 25 ++---
>> 3 files changed, 5 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> index bb6dbbe..a317cda 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> @@ -1521,7 +1521,7 @@ static int vmw_pm_freeze(struct device *kdev)
>> WARN_ON(vmw_request_device_late(dev_priv));
>> dev_priv->suspend_locked = false;
>> ttm_suspend_unlock(&dev_priv->reservation_sem);
>> - if (dev_priv->suspend_state)
>> + if (dev->mode_config.suspend_state)
>> vmw_kms_resume(dev);
>> if (dev_priv->enable_fb)
>> vmw_fb_on(dev_priv);
>> @@ -1558,8 +1558,8 @@ static int vmw_pm_restore(struct device *kdev)
>> vmw_fence_fifo_up(dev_priv->fman);
>> dev_priv->suspend_locked = false;
>> ttm_suspend_unlock(&dev_priv->reservation_sem);
>> - if (dev_priv->suspend_state)
>> - vmw_kms_resume(dev_priv->dev);
>> + if (dev->mode_config.suspend_state)
>> + vmw_kms_resume(dev);
>>
>> if (dev_priv->enable_fb)
>> vmw_fb_on(dev_priv);
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> index 1abe217..b8e200b 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> @@ -438,7 +438,6 @@ struct vmw_private {
>> struct vmw_framebuffer *implicit_fb;
>> struct mutex global_kms_state_mutex;
>> spinlock_t cursor_lock;
>> - struct drm_atomic_state *suspend_state;
>>
>> /*
>>* Context and surface management.
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
>> index 23beff5..2d011a1 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
>> @@ -3028,19 +3028,7 @@ int vmw_kms_set_config(struct drm_mode_set
>> *set,
>> */
>> int vmw_kms_suspend(struct drm_device *dev)
>> {
>> - struct vmw_private *dev_priv = vmw_priv(dev);
>> -
>> - dev_priv->suspend_state = drm_atomic_helper_suspend(dev);
>> - if (IS_ERR(dev_priv->suspend_state)) {
>> - int ret = PTR_ERR(dev_priv->suspend_state);
>> -
>> - DRM_ERROR("Failed kms suspend: %d\n", ret);
>> - dev_priv->suspend_state = NULL;
>> -
>> - return ret;
>> - }
>> -
>> - return 0;
>> + return drm_mode_config_helper_suspend(dev);
>> }
>>
>>
>> @@ -3055,16 +3043,7 @@ int vmw_kms_suspend(struct drm_device *dev)
>> */
>> int vmw_kms_resume(struct drm_device *dev)
>> {
>> - struct vmw_private *dev_priv = vmw_priv(dev);
>> - int ret;
>> -
>> - if (WARN_ON(!dev_priv->suspend_state))
>> - return 0;
>> -
>> - ret = drm_atomic_helper_resume(dev, dev_priv->suspend_state);
>> - dev_priv->suspend_state = NULL;
>> -
>> - return ret;
>> + return drm_mode_config_helper_resume(dev);
>> }
>>
>> /**
>> --
>> 1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: fix unsigned comparison with less than zero
From: Colin Ian King
The return from the call to _mixer_stages can be a negative error
code however this is being assigned to an unsigned variable 'stages'
hence the check is always false. Fix this by making 'stages' an
int.
Detected by Coccinelle ("Unsigned expression compared with zero:
stages < 0")
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 06be7cf7ce50..79bafea66354 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -310,7 +310,7 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl
*ctx,
u32 mixercfg = 0, mixercfg_ext = 0, mix, ext;
u32 mixercfg_ext2 = 0, mixercfg_ext3 = 0;
int i, j;
- u8 stages;
+ int stages;
int pipes_per_stage;
stages = _mixer_stages(ctx->mixer_hw_caps, ctx->mixer_count, lm);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/9] drm/exynos: move connector creation to attach callback
On 21.08.2018 07:27, Inki Dae wrote:
>
> 2018년 08월 20일 18:00에 Andrzej Hajda 이(가) 쓴 글:
>> On 17.08.2018 03:56, Inki Dae wrote:
>>> 2018년 08월 13일 20:17에 Andrzej Hajda 이(가) 쓴 글:
On 07.08.2018 10:53, Inki Dae wrote:
> 2018년 07월 26일 00:46에 Andrzej Hajda 이(가) 쓴 글:
>> From: Maciej Purski
>>
>> The current implementation assumes that the only possible peripheral
>> device for DSIM is a panel. Using an output bridge child device
>> should also be possible.
>>
>> If an output bridge is available, don't create a new connector.
>> Instead, call drm_bridge_attach() and set encoder's bridge to NULL
>> in order to avoid an out bridge from being visible by the framework, as
>> the DSI bus needs control on enabling its child output bridge.
>>
>> Such sequence is required by Toshiba TC358764 bridge, which is a DSI
>> peripheral bridge device.
>>
>> changed in v5:
>> - detach bridge in mipi_dsi detach callback
>>
>> Signed-off-by: Maciej Purski
>> [ a.ha...@samsung.com: v5 ]
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 50 -
>> 1 file changed, 32 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 351403f9d245..f5f51f584fa0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -255,6 +255,7 @@ struct exynos_dsi {
>> struct mipi_dsi_host dsi_host;
>> struct drm_connector connector;
>> struct drm_panel *panel;
>> +struct drm_bridge *out_bridge;
>> struct device *dev;
>>
>> void __iomem *reg_base;
>> @@ -1499,7 +1500,30 @@ static int exynos_dsi_host_attach(struct
>> mipi_dsi_host *host,
>>struct mipi_dsi_device *device)
>> {
>> struct exynos_dsi *dsi = host_to_dsi(host);
>> -struct drm_device *drm = dsi->connector.dev;
>> +struct drm_encoder *encoder = &dsi->encoder;
>> +struct drm_device *drm = encoder->dev;
>> +struct drm_bridge *out_bridge;
>> +
>> +out_bridge = of_drm_find_bridge(device->dev.of_node);
> Is there any reason to find out_bridge without considering device tree
> graph binding?
If the sink is a child MIPI-DSI device, the bindings can be omitted, as
in case of all DSI panels in Exynos platforms.
In case bindings are not present you cannot use graph functions.
>>> In other words, this means that this patch doesn't allow to use the device
>>> tree graph binding.
>>> I.e., if other people wrote the graph things in his board dts file for the
>>> use of bridge device then with this patch he cannot use the bride device.
>>>
>>> So I think it would be better to allow to use both of them, as a child
>>> device and graph binding.
>>>
>>> How about trying to bind the graph things using drm_of_find_panel_or_bridge
>>> funtion first and then for child device way?
>> It could be done this way, but it should be done for panels and for
>> bridges, and it should be rather generic helper, not Exynos specific. So
> As the function name says, drm_of_find_panel_or_bridge function will return
> panel, bridge or both of them according to given arguments.
>
>
>> it is something which require additional investigation, discussion and
>> separate patchset.
> So I think we wouldn't need additional discussion at all becuase we don't
> touch panel but add only bridge device as output, and the use of this
> function for bridge looks more generic way.
But drm_of_find_panel_or_bridge is only for looking for non-dsi devices,
or more specifically for looking for devices connected in DTS via
DT-graph. This is not case of panels and bridges used in Exynos boards.
So this function is currently useless with our boards. Maybe some day we
will have bridge/panel controlled via I2C and then it will become
useful, but for now it serves for nothing.
> Of course, as a separate patch, we could consider using this function for
> panel device later.
As you said drm_of_find_panel_or_bridge looks for panel and/or bridge,
and it was created to merge similar code in panel and bridge lookup,
using it only for bridges and not for panels seems against it's purpose.
>
>> On the other side this patch is enough to correctly handle all DSI
>> bridges in existing Exynos boards.
>>
>>> And I'm not clear about what kinds of devices could be a child device of
>>> DSI, which isn't required for the graph binding.
>>> Is there any document I can refer to?
>> DSI devices (peripherals) should be described as child nodes of DSI host
>> node in DT bindings, it is described in [1]. And you can find all dsi
>> panels in exynos based boards are modeled this way.
>> And the graph documentation [2] s
[Bug 107581] Graphics Not Rendered Due to Missing 4.5 COMPAT Profile
https://bugs.freedesktop.org/show_bug.cgi?id=107581 --- Comment #11 from Benjamin Hodgetts --- Applied the patch in attachment 141209 and rebuilt, but the game looks the same. Something of note is that it's supposed to build the shaders on the first load of the game, but the SHADERCACHE folder of the game is remaining empty (I assume as the shaders are failing to build). -- 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
[PATCH] drm/pl111: add in missing sentinel to a of_device_id array
From: Colin Ian King
Array vexpress_muxfpga_match is missing an end of array sentinel,
add it.
Detected by Coccinelle: ("vexpress_muxfpga_match is not NULL
terminated at line")
Fixes: ca454bd42dc2 ("drm/pl111: Support the Versatile Express")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/pl111/pl111_vexpress.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.c
b/drivers/gpu/drm/pl111/pl111_vexpress.c
index a534b225e31b..48e2afcd4798 100644
--- a/drivers/gpu/drm/pl111/pl111_vexpress.c
+++ b/drivers/gpu/drm/pl111/pl111_vexpress.c
@@ -111,7 +111,8 @@ static int vexpress_muxfpga_probe(struct platform_device
*pdev)
}
static const struct of_device_id vexpress_muxfpga_match[] = {
- { .compatible = "arm,vexpress-muxfpga", }
+ { .compatible = "arm,vexpress-muxfpga", },
+ { /* sentinel */ }
};
static struct platform_driver vexpress_muxfpga_driver = {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107581] Graphics Not Rendered Due to Missing 4.5 COMPAT Profile
https://bugs.freedesktop.org/show_bug.cgi?id=107581 --- Comment #10 from Benjamin Hodgetts --- BTW, the attachment limit on bugs is 4GB and my attachment was 286MB. If people shouldn't post large attachments then it's probably worth lowering that limit, otherwise people have no way of knowing that they aren't supposed to attach large files. -- 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 107581] Graphics Not Rendered Due to Missing 4.5 COMPAT Profile
https://bugs.freedesktop.org/show_bug.cgi?id=107581 --- Comment #9 from Benjamin Hodgetts --- >Please try using force_glsl_extensions_warn=true it works around some game >bugs. That generated the two new messages in the terminal... ATTENTION: default value of option force_glsl_extensions_warn overridden by environment. ATTENTION: option value of option force_glsl_extensions_warn ignored. ... so I assume it was picked up properly, but rendering behaviour didn't change. The nebula clouds were still missing on the loading screen (so space is just black) and in-game looked the same as the screenshot I originally posted (screen is just white except for the menu). All in all, no change. I'll try with your hack patch and see if that changes behaviour. -- 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] drm/scheduler: avoid redundant shifting of the entity
On 2018-08-21 11:29 a.m., Nayan Deshmukh wrote: > do not remove entity from the rq if the current rq is from > the least loaded scheduler. > > Signed-off-by: Nayan Deshmukh > --- > drivers/gpu/drm/scheduler/sched_entity.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/scheduler/sched_entity.c > b/drivers/gpu/drm/scheduler/sched_entity.c > index 1416edb2642a..5cae6661ef2f 100644 > --- a/drivers/gpu/drm/scheduler/sched_entity.c > +++ b/drivers/gpu/drm/scheduler/sched_entity.c > @@ -472,6 +472,9 @@ void drm_sched_entity_select_rq(struct drm_sched_entity > *entity) > return; > > rq = drm_sched_entity_get_free_sched(entity); > +if (rq == entity->rq) > +return; Looks like the newly added lines use spaces for indentation. The kernel coding style uses tabs. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Improve non-DPLL clock selection
Hi Laurent,
I run some tests, and here below there's a summary of what I see
On Tue, Aug 21, 2018 at 01:12:40AM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Tuesday, 21 August 2018 00:49:41 EEST Laurent Pinchart wrote:
> > From: Jacopo Mondi
> >
> > DU channels not equipped with a DPLL use an SoC internal (provided by
> > the CPG) or external clock source combined with a DU internal divider to
> > generate the desired output dot clock frequency.
> >
> > The current clock selection procedure does not fully exploit the ability
> > of external clock sources to generate the exact dot clock frequency by
> > themselves, but relies instead on tuning the internal DU clock divider
> > only, resulting in a less precise clock generation process.
> >
> > When possible, and desirable, ask the external clock source for the
> > exact output dot clock frequency, and select the clock source that
> > produces the frequency closest to the desired output dot clock.
> >
> > This patch specifically targets platforms (like Salvator-X[S] and ULCBs)
> > where the DU's input dotclock.in is generated by the versaclock VC5
> > clock source, which is capable of generating the exact rate the DU needs
> > as pixel clock output.
> >
> > This patch fixes higher resolution modes which requires an high pixel
> > clock output currently not working on non-HDMI DU channel (such as
> > 1920x1080@60Hz on the VGA output).
>
> Just for the record, with this patch the following modes (as printed by
> modetest) on the VGA output now produce correct result with my monitor:
>
> 1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 flags: nhsync, nvsync
> 1600x1200 60 1600 1664 1856 2160 1200 1201 1204 1250 flags: phsync, pvsync
> 1360x768 60 1360 1424 1536 1792 768 771 777 795 flags: phsync, pvsync
>
> The second mode used to not display at all, with a message telling that
> timings were out of range, and the other two modes used to produce a displayed
> image partly shifted or scaled out of the screen boundaries.
>
> The following modes still produce an image partly out of the screen
> boundaries.
>
> 1600x900 60 1600 1624 1704 1800 900 901 904 1000 flags: phsync, pvsync
> 1280x960 60 1280 1376 1488 1800 960 961 964 1000 flags: phsync, pvsync
> 1366x768 60 1366 1436 1579 1792 768 771 774 798 flags: phsync, pvsync
> 1366x768 60 1366 1380 1436 1500 768 769 772 800 flags: phsync, pvsync
> 1280x720 60 1280 1390 1430 1650 720 725 730 750 flags: phsync, pvsync
>
> And this one is reported to be out of range.
>
> 1920x1200 60 1920 2056 2256 2592 1200 1203 1209 1245 flags: nhsync, pvsync
>
> There is thus still room for improvement (some of the issues are possibly due
> to my monitor though), but there's also an improvement, and no noticeable
> regression.
The following table compares results obtained with the latest
renesas-drivers, with and without this series applied on top.
---
Legend:
A = image badly aligned: not all 4 blue/red borders visible
F = flickering: disturbance in the shown image
B = broken: mode is not displayed
Results: I = improvement
R = regression
renesas-drivers du_clk result
1024x768
1920x1200 F A I
1920x1200 A A
1920x1080 A A
1600x1200 B I
1680x1050
1680x1050
1400x1050
1400x1050
1600x900A A
1280x1024
1440x900
1440x900
1280x960
1366x768A A
1366x768A A
1360x768A R
1280x800
1280x768A A
1280x768A A
1280x768A A
1280x720A A
800x600
800x600
848x480
640x480
---
Overall I see two modes that were broken or unusable due to flickering
(1600x1200 and 1920x1200 respectively) to be now (almost) fixed.
There are visible alignement problems on some modes on both versions,
but I only see one 'regression' (the last 1360x768 that is now
slightly not aligned).
I guess monitors play a role here, with each one being different, but
overall I guess our test results match.
>
> > Fixes: 1b30dbde8596 ("drm: rcar-du: Add support for external pixel clock")
> > Signed-off-by: Jacopo Mondi
> > [Factor out code to a helper function]
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 86 --
> > 1 file changed, 55 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index f8068170905a..2c9405458bbf
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -165,6 +165,48 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc
Re: [RFC v4 7/8] drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
Hi Uma,
On Fri, Aug 17, 2018 at 07:48:50PM +0530, Uma Shankar wrote:
> Implement Plane Gamma feature for BDW and Gen9 platforms.
>
> v2: Used newly added drm_color_lut_ext structure for enhanced
> precision for Gamma LUT entries.
>
> v3: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/i915_pci.c | 5 +++-
> drivers/gpu/drm/i915/i915_reg.h | 25
> drivers/gpu/drm/i915/intel_color.c | 58
>
> drivers/gpu/drm/i915/intel_display.c | 4 +++
> drivers/gpu/drm/i915/intel_sprite.c | 4 +++
> 5 files changed, 95 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index e931b48..40de78c 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -54,7 +54,10 @@
> .cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET,
> IVB_CURSOR_C_OFFSET }
>
> #define BDW_COLORS \
> - .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
> + .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }, \
> + .plane_color = { .plane_degamma_lut_size = 0, \
> + .plane_gamma_lut_size = 16 }
> +
> #define CHV_COLORS \
> .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
> #define GLK_COLORS \
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0c9f03d..2db6a84 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -172,6 +172,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
> #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
>
> +/* Plane Gamma Registers */
> +#define _MMIO_PLANE_GAMC(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) * 4)
> +#define _MMIO_PLANE_GAMC16(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) *
> 4)
> +
> #define __MASKED_FIELD(mask, value) ((mask) << 16 | (value))
> #define _MASKED_FIELD(mask, value) ({
>\
> if (__builtin_constant_p(mask))\
> @@ -9713,6 +9717,27 @@ enum skl_power_gate {
> #define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A,
> _PRE_CSC_GAMC_INDEX_B)
> #define PRE_CSC_GAMC_DATA(pipe) _MMIO_PIPE(pipe,
> _PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
>
> +/* Plane Gamma in Gen9+ */
> +#define _PLANE_GAMC_1_A 0x701d0
> +#define _PLANE_GAMC_1_B 0x711d0
> +#define _PLANE_GAMC_2_A 0x702d0
> +#define _PLANE_GAMC_2_B 0x712d0
> +#define _PLANE_GAMC_1(pipe) _PIPE(pipe, _PLANE_GAMC_1_A, _PLANE_GAMC_1_B)
> +#define _PLANE_GAMC_2(pipe) _PIPE(pipe, _PLANE_GAMC_2_A, _PLANE_GAMC_2_B)
> +#define PLANE_GAMC(pipe, plane, i) \
> + _MMIO_PLANE_GAMC(plane, i, _PLANE_GAMC_1(pipe), _PLANE_GAMC_2(pipe))
> +
> +#define _PLANE_GAMC16_1_A0x70210
> +#define _PLANE_GAMC16_1_B0x71210
> +#define _PLANE_GAMC16_2_A0x70310
> +#define _PLANE_GAMC16_2_B0x71310
> +#define _PLANE_GAMC16_1(pipe)_PIPE(pipe, _PLANE_GAMC16_1_A, \
> + _PLANE_GAMC16_1_B)
> +#define _PLANE_GAMC16_2(pipe)_PIPE(pipe, _PLANE_GAMC16_2_A, \
> + _PLANE_GAMC16_2_B)
> +#define PLANE_GAMC16(pipe, plane, i) _MMIO_PLANE_GAMC16(plane, i, \
> + _PLANE_GAMC16_1(pipe), _PLANE_GAMC16_2(pipe))
> +
> /* pipe CSC & degamma/gamma LUTs on CHV */
> #define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
> #define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index fb8402f..2b5c0cd 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -492,6 +492,59 @@ static void broadwell_load_luts(struct drm_crtc_state
> *state)
> I915_WRITE(PREC_PAL_INDEX(pipe), 0);
> }
>
> +static void bdw_load_plane_gamma_lut(const struct drm_plane_state *state,
> + u32 offset)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
> + enum pipe pipe = to_intel_plane(state->plane)->pipe;
> + enum plane_id plane = to_intel_plane(state->plane)->id;
> + uint32_t i, lut_size =
> + INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size;
> +
> + if (state->gamma_lut) {
> + struct drm_color_lut_ext *lut =
> + (struct drm_color_lut_ext *) state->gamma_lut->data;
> +
> + for (i = 0; i < lut_size; i++) {
> + uint32_t word =
> + (drm_color_lut_extract(lut[i].red, 10) << 20) |
> + (drm_color_lut_extract(lut[i].green, 10) << 10) |
> + drm_color_lut_extract(lut[i].blue, 10);
Shouldn't you be using drm_color_lut_extract_ext ?
> +
> + I915_WRITE(P
Re: [RFC v4 5/8] drm: Define helper function for plane color enabling
Hi Uma,
On Fri, Aug 17, 2018 at 07:48:48PM +0530, Uma Shankar wrote:
> Define helper function to enable Plane color features
> to attach plane color properties to plane structure.
>
> v2: Rebase
>
> v3: Modiefied the function to use updated property names.
>
> v4: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_plane.c | 42 ++
> include/drm/drm_color_mgmt.h | 5 +
> 2 files changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index d0bf10b..d1b4ac1 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -144,6 +144,48 @@ static int create_in_format_blob(struct drm_device *dev,
> struct drm_plane *plane
> }
>
> /**
> + * drm_plane_enable_color_mgmt - enable color management properties
> + * @plane: DRM Plane
> + * @plane_degamma_lut_size: the size of the degamma lut (before CSC)
> + * @plane_has_ctm: whether to attach ctm_property for CSC matrix
> + * @plane_gamma_lut_size: the size of the gamma lut (after CSC)
> + *
> + * This function lets the driver enable the color correction
> + * properties on a plane. This includes 3 degamma, csc and gamma
> + * properties that userspace can set and 2 size properties to inform
> + * the userspace of the lut sizes. Each of the properties are
> + * optional. The gamma and degamma properties are only attached if
> + * their size is not 0 and ctm_property is only attached if has_ctm is
> + * true.
> + */
> +void drm_plane_enable_color_mgmt(struct drm_plane *plane,
> + uint plane_degamma_lut_size,
> + bool plane_has_ctm,
> + uint plane_gamma_lut_size)
> +{
> + if (plane_degamma_lut_size) {
> + drm_object_attach_property(&plane->base,
> + plane->degamma_lut_property, 0);
> + drm_object_attach_property(&plane->base,
> + plane->degamma_lut_size_property,
> + plane_degamma_lut_size);
> + }
> +
> + if (plane_has_ctm)
> + drm_object_attach_property(&plane->base,
> + plane->ctm_property, 0);
> +
> + if (plane_gamma_lut_size) {
> + drm_object_attach_property(&plane->base,
> + plane->gamma_lut_property, 0);
> + drm_object_attach_property(&plane->base,
> + plane->gamma_lut_size_property,
> + plane_gamma_lut_size);
> + }
> +}
> +EXPORT_SYMBOL(drm_plane_enable_color_mgmt);
> +
> +/**
> * drm_universal_plane_init - Initialize a new universal plane object
> * @dev: DRM device
> * @plane: plane object to init
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 44f04233..9b8e566 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -68,4 +68,9 @@ int drm_plane_create_color_properties(struct drm_plane
> *plane,
> u32 supported_ranges,
> enum drm_color_encoding default_encoding,
> enum drm_color_range default_range);
> +
> +void drm_plane_enable_color_mgmt(struct drm_plane *plane,
> + uint plane_degamma_lut_size,
> + bool plane_has_ctm,
> + uint plane_gamma_lut_size);
> #endif
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Reviewed-by: Alexandru Gheorghe
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4 4/8] drm: Add Plane Gamma properties
Hi Uma,
On Fri, Aug 17, 2018 at 07:48:47PM +0530, Uma Shankar wrote:
> Add plane gamma as blob property and size as a
> range property.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instantiate
> these properties and removed from drm_mode_create_standard_properties
> Added property documentation as suggested by Daniel, Vetter.
>
> v4: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> Documentation/gpu/drm-kms.rst | 6 ++
> drivers/gpu/drm/drm_atomic.c| 9 +
> drivers/gpu/drm/drm_atomic_helper.c | 3 +++
> drivers/gpu/drm/drm_plane.c | 23 +++
> include/drm/drm_plane.h | 22 ++
> 5 files changed, 63 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 16d6d8d..bcf9a86 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -563,6 +563,12 @@ Plane Color Management Properties
> .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> :doc: ctm_property
>
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: gamma_lut_property
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: gamma_lut_size_property
> +
> Tile Group Property
> ---
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ddda935..8b0bf14 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -925,6 +925,13 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> &replaced);
> state->color_mgmt_changed |= replaced;
> return ret;
> + } else if (property == plane->gamma_lut_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + &state->gamma_lut,
> + val, -1, sizeof(struct drm_color_lut),
> + &replaced);
> + state->color_mgmt_changed |= replaced;
> + return ret;
> } else if (plane->funcs->atomic_set_property) {
> return plane->funcs->atomic_set_property(plane, state,
> property, val);
> @@ -998,6 +1005,8 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> state->degamma_lut->base.id : 0;
> } else if (property == plane->ctm_property) {
> *val = (state->ctm) ? state->ctm->base.id : 0;
> + } else if (property == plane->gamma_lut_property) {
> + *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> } else if (plane->funcs->atomic_get_property) {
> return plane->funcs->atomic_get_property(plane, state,
> property, val);
> } else {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 866181f..f524255 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3618,6 +3618,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct
> drm_plane *plane,
> drm_property_blob_get(state->degamma_lut);
> if (state->ctm)
> drm_property_blob_get(state->ctm);
> + if (state->gamma_lut)
> + drm_property_blob_put(state->gamma_lut);
>
> state->color_mgmt_changed = false;
> }
> @@ -3667,6 +3669,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
> drm_plane_state *state)
>
> drm_property_blob_put(state->degamma_lut);
> drm_property_blob_put(state->ctm);
> + drm_property_blob_put(state->gamma_lut);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 97520b1..d0bf10b 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -494,6 +494,15 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
> * Blob property which allows a userspace to provide CTM coefficients
> * to do color space conversion or any other enhancement by doing a
> * matrix multiplication using the h/w CTM processing engine
> + *
> + * gamma_lut_property:
> + * Blob property which allows a userspace to provide LUT values
> + * to apply gamma/tone-mapping curve using the h/w plane gamma
> + * processing engine, thereby making the content as non-linear
> + * or to perform any tone mapping operation for HDR usecases.
> + *
> + * gamma_lut_size_property:
> + * Range Property to indicate size of the plane gamma LUT.
> */
> int drm_plane_color_create_prop(struct drm_device *dev,
> struct drm_plane *plane)
> @@ -521,6 +530,20 @@ int drm_plane_color_create_prop(struct drm_device *dev,
> return -ENOMEM;
> plane->ctm_property = prop;
>
> + prop = drm_property_create(dev,
> +
Re: [RFC v4 3/8] drm: Add Plane CTM property
Hi Uma,
On Fri, Aug 17, 2018 at 07:48:46PM +0530, Uma Shankar wrote:
> Add a blob property for plane CSC usage.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instantiate
> these properties and removed from drm_mode_create_standard_properties
> Added property documentation as suggested by Daniel, Vetter.
>
> v4: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> Documentation/gpu/drm-kms.rst | 3 +++
> drivers/gpu/drm/drm_atomic.c| 10 ++
> drivers/gpu/drm/drm_atomic_helper.c | 4
> drivers/gpu/drm/drm_plane.c | 12
> include/drm/drm_plane.h | 15 +++
> 5 files changed, 44 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 8b10b12..16d6d8d 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -560,6 +560,9 @@ Plane Color Management Properties
> .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> :doc: degamma_lut_size_property
>
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: ctm_property
> +
> Tile Group Property
> ---
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index f8cad9b..ddda935 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -917,6 +917,14 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> &replaced);
> state->color_mgmt_changed |= replaced;
> return ret;
> + } else if (property == plane->ctm_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + &state->ctm,
> + val,
> + sizeof(struct drm_color_ctm), -1,
> + &replaced);
> + state->color_mgmt_changed |= replaced;
> + return ret;
> } else if (plane->funcs->atomic_set_property) {
> return plane->funcs->atomic_set_property(plane, state,
> property, val);
> @@ -988,6 +996,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> } else if (property == plane->degamma_lut_property) {
> *val = (state->degamma_lut) ?
> state->degamma_lut->base.id : 0;
> + } else if (property == plane->ctm_property) {
> + *val = (state->ctm) ? state->ctm->base.id : 0;
> } else if (plane->funcs->atomic_get_property) {
> return plane->funcs->atomic_get_property(plane, state,
> property, val);
> } else {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 67c5b51..866181f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3616,6 +3616,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct
> drm_plane *plane,
>
> if (state->degamma_lut)
> drm_property_blob_get(state->degamma_lut);
> + if (state->ctm)
> + drm_property_blob_get(state->ctm);
> +
> state->color_mgmt_changed = false;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> @@ -3663,6 +3666,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
> drm_plane_state *state)
> drm_crtc_commit_put(state->commit);
>
> drm_property_blob_put(state->degamma_lut);
> + drm_property_blob_put(state->ctm);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 03e0560..97520b1 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -489,6 +489,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
> *
> * degamma_lut_size_property:
> * Range Property to indicate size of the plane degamma LUT.
> + *
> + * ctm_property:
> + * Blob property which allows a userspace to provide CTM coefficients
> + * to do color space conversion or any other enhancement by doing a
> + * matrix multiplication using the h/w CTM processing engine
> */
> int drm_plane_color_create_prop(struct drm_device *dev,
> struct drm_plane *plane)
> @@ -509,6 +514,13 @@ int drm_plane_color_create_prop(struct drm_device *dev,
> return -ENOMEM;
> plane->degamma_lut_size_property = prop;
>
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB,
> + "PLANE_CTM", 0);
> + if (!prop)
> + return -ENOMEM;
> + plane->ctm_property = prop;
> +
> return 0;
> }
> EXPORT_SYMBOL(drm_plane_color_create_prop);
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 28357ac..5143277 100644
> --- a/include/drm/drm_plane.h
> +++ b/in
Re: [RFC v4 2/8] drm: Add Plane Degamma properties
Hi Uma,
On Fri, Aug 17, 2018 at 07:48:45PM +0530, Uma Shankar wrote:
> Add Plane Degamma as a blob property and plane degamma size as
> a range property.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instantiate
> these properties and removed from drm_mode_create_standard_properties
> Added property documentation as suggested by Daniel, Vetter.
>
> v4: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> Documentation/gpu/drm-kms.rst | 9 +
> drivers/gpu/drm/drm_atomic.c| 13 +
> drivers/gpu/drm/drm_atomic_helper.c | 6 ++
> drivers/gpu/drm/drm_plane.c | 35 +++
> include/drm/drm_plane.h | 24
> 5 files changed, 87 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 5dee6b8..8b10b12 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -551,6 +551,15 @@ Color Management Properties
> .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> :export:
>
> +Plane Color Management Properties
> +---
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: degamma_lut_property
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: degamma_lut_size_property
> +
> Tile Group Property
> ---
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3eb061e..f8cad9b 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -857,6 +857,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> {
> struct drm_device *dev = plane->dev;
> struct drm_mode_config *config = &dev->mode_config;
> + bool replaced = false;
> + int ret;
>
> if (property == config->prop_fb_id) {
> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
> val);
> @@ -908,6 +910,13 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> state->color_encoding = val;
> } else if (property == plane->color_range_property) {
> state->color_range = val;
> + } else if (property == plane->degamma_lut_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + &state->degamma_lut,
> + val, -1, sizeof(struct drm_color_lut),
> + &replaced);
> + state->color_mgmt_changed |= replaced;
> + return ret;
> } else if (plane->funcs->atomic_set_property) {
> return plane->funcs->atomic_set_property(plane, state,
> property, val);
> @@ -976,6 +985,9 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> *val = state->color_encoding;
> } else if (property == plane->color_range_property) {
> *val = state->color_range;
> + } else if (property == plane->degamma_lut_property) {
> + *val = (state->degamma_lut) ?
> + state->degamma_lut->base.id : 0;
> } else if (plane->funcs->atomic_get_property) {
> return plane->funcs->atomic_get_property(plane, state,
> property, val);
> } else {
> @@ -1116,6 +1128,7 @@ static void drm_atomic_plane_print_state(struct
> drm_printer *p,
> drm_get_color_encoding_name(state->color_encoding));
> drm_printf(p, "\tcolor-range=%s\n",
> drm_get_color_range_name(state->color_range));
> + drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
>
> if (plane->funcs->atomic_print_state)
> plane->funcs->atomic_print_state(p, state);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 38ce9a3..67c5b51 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3613,6 +3613,10 @@ void __drm_atomic_helper_plane_duplicate_state(struct
> drm_plane *plane,
>
> state->fence = NULL;
> state->commit = NULL;
> +
> + if (state->degamma_lut)
> + drm_property_blob_get(state->degamma_lut);
> + state->color_mgmt_changed = false;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
>
> @@ -3657,6 +3661,8 @@ void __drm_atomic_helper_plane_destroy_state(struct
> drm_plane_state *state)
>
> if (state->commit)
> drm_crtc_commit_put(state->commit);
> +
> + drm_property_blob_put(state->degamma_lut);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index cd71fd0..03e0560 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -478,6 +478,41 @@ int drm_mode_plane_set_obj_prop(s
[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off
https://bugs.freedesktop.org/show_bug.cgi?id=105046 --- Comment #15 from Lothar Paltins --- Hi Michael, in order to work at boot time, you have to add your edid file to your initrd or initramfs. Don't know, what distribution you are using, but if it uses dracut, then you should create a file /etc/dracut.conf.d/99-edid.conf (the filename is arbitrary, but it must have the suffix ".conf") with the following content: install_items+=" /lib/firmware/edid/mizapfmon.bin " and then run mkinitrd. But as I've said, this didn't fix the issue for me. Lothar -- 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: [RFC v4 1/8] drm: Add Enhanced Gamma LUT precision structure
Hi Uma,
On Fri, Aug 17, 2018 at 07:48:44PM +0530, Uma Shankar wrote:
> Existing LUT precision structure is having only 16 bit
> precision. This is not enough for upcoming enhanced hardwares
> and advance usecases like HDR processing. Hence added a new
> structure with 32 bit precision values. Also added the code,
> for extracting the same from values passed from userspace.
>
> v4: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_plane.c | 19 +++
> include/uapi/drm/drm_mode.h | 15 +++
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 6153cbd..cd71fd0 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -430,6 +430,25 @@ void drm_plane_force_disable(struct drm_plane *plane)
> }
> EXPORT_SYMBOL(drm_plane_force_disable);
>
> +/*
> + * Added to accommodate enhanced LUT precision.
> + * Max LUT precision is 32 bits.
> + */
> +uint32_t drm_color_lut_extract_ext(uint32_t user_input, uint32_t
> bit_precision)
You should declare this function in a header file as well.
With that fixed
Reviewed-by: Alexandru Gheorghe
> +{
> + uint32_t val = user_input;
> + uint32_t max = 0x >> (32 - bit_precision);
> +
> + /* Round only if we're not using full precision. */
> + if (bit_precision < 32) {
> + val += 1UL << (32 - bit_precision - 1);
> + val >>= 32 - bit_precision;
> + }
> +
> + return clamp_val(val, 0, max);
> +}
> +EXPORT_SYMBOL(drm_color_lut_extract_ext);
> +
> /**
> * drm_mode_plane_set_obj_prop - set the value of a property
> * @plane: drm plane object to set property value for
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 8d67243..874407b 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -629,6 +629,21 @@ struct drm_color_lut {
> __u16 reserved;
> };
>
> +/*
> + * Creating 32 bit palette entries for better data
> + * precision. This will be required for HDR and
> + * similar color processing usecases.
> + */
> +struct drm_color_lut_ext {
> + /*
> + * Data is U0.32 fixed point format.
> + */
> + __u32 red;
> + __u32 green;
> + __u32 blue;
> + __u32 reserved;
> +};
> +
> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/scheduler: avoid redundant shifting of the entity
do not remove entity from the rq if the current rq is from the least loaded scheduler. Signed-off-by: Nayan Deshmukh --- drivers/gpu/drm/scheduler/sched_entity.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index 1416edb2642a..5cae6661ef2f 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -472,6 +472,9 @@ void drm_sched_entity_select_rq(struct drm_sched_entity *entity) return; rq = drm_sched_entity_get_free_sched(entity); +if (rq == entity->rq) +return; + spin_lock(&entity->rq_lock); drm_sched_rq_remove_entity(entity->rq, entity); entity->rq = rq; -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Clarify DRM_MODE_REFLECT_X/Y documentation
Hi,
On Tue, Aug 21, 2018 at 10:54:52AM +0200, Daniel Vetter wrote:
> On Mon, Aug 20, 2018 at 10:10:52AM +0100, Alexandru-Cosmin Gheorghe wrote:
> > On Tue, Aug 14, 2018 at 10:36:58AM +0200, Daniel Vetter wrote:
> > > On Fri, Aug 10, 2018 at 06:50:31PM +0100, Alexandru Gheorghe wrote:
> > > > DRM_MODE_REFLECT_X and DRM_MODE_REFLECT_Y meaning seems a bit unclear
> > > > to me, so try to clarify that with a bit of ascii graphics.
> > > >
> > > > Signed-off-by: Alexandru Gheorghe
> > > > ---
> > > > include/uapi/drm/drm_mode.h | 11 ++-
> > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > > index 8d67243952f4..ac5de85c93eb 100644
> > > > --- a/include/uapi/drm/drm_mode.h
> > > > +++ b/include/uapi/drm/drm_mode.h
> > > > @@ -186,9 +186,18 @@ extern "C" {
> > > > /*
> > > > * DRM_MODE_REFLECT_
> > > > *
> > > > - * Signals that the contents of a drm plane is reflected in the
> > > > axis,
> > > > + * Signals that the contents of a drm plane is reflected along the
> > > > axis,
> > > > * in the same way as mirroring.
> > > > *
> > > > + * DRM_MODE_REFLECT_X
> > > > + * |o || o|
> > > > + * | | -> | |
> > > > + * | v||v |
> > > > + *
> > > > + * DRM_MODE_REFLECT_Y
> > > > + * |o || ^|
> > > > + * | | -> | |
> > > > + * | v||o |
> > >
> > > I think the above won't render correctly in sphinx. I think you need some
> > > fixed-block quoting. Please run
> > >
> > > $ make htmldocs
> > >
> > > and check the output. With that addressed:
> >
> > One small problem here this file is not included in the htmldoc
> > generation and no comment in here is marked to be included in html
> > documentation.
>
> Hah, I guess my review was sub-par. And with that I realized we have have
> this prop fairly well documented already, but it's hidden in
> drm_plane_create_rotation_property(). Plus linked from
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-properties
>
> Might be better to move everything there, and just leave a hint here?
I agree, it makes perfectly sense to move it to
drm_plane_create_rotation_property and just point to that here.
I will do that in v2.
> -Daniel
>
> >
> > >
> > > Reviewed-by: Daniel Vetter
> > >
> > > > * This define is provided as a convenience, looking up the property id
> > > > * using the name->prop id lookup is the preferred method.
> > > > */
> > > > --
> > > > 2.18.0
> > > >
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> >
> > --
> > Cheers,
> > Alex G
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Clarify DRM_MODE_REFLECT_X/Y documentation
On Mon, Aug 20, 2018 at 10:10:52AM +0100, Alexandru-Cosmin Gheorghe wrote:
> On Tue, Aug 14, 2018 at 10:36:58AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 10, 2018 at 06:50:31PM +0100, Alexandru Gheorghe wrote:
> > > DRM_MODE_REFLECT_X and DRM_MODE_REFLECT_Y meaning seems a bit unclear
> > > to me, so try to clarify that with a bit of ascii graphics.
> > >
> > > Signed-off-by: Alexandru Gheorghe
> > > ---
> > > include/uapi/drm/drm_mode.h | 11 ++-
> > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > index 8d67243952f4..ac5de85c93eb 100644
> > > --- a/include/uapi/drm/drm_mode.h
> > > +++ b/include/uapi/drm/drm_mode.h
> > > @@ -186,9 +186,18 @@ extern "C" {
> > > /*
> > > * DRM_MODE_REFLECT_
> > > *
> > > - * Signals that the contents of a drm plane is reflected in the
> > > axis,
> > > + * Signals that the contents of a drm plane is reflected along the
> > > axis,
> > > * in the same way as mirroring.
> > > *
> > > + * DRM_MODE_REFLECT_X
> > > + * |o || o|
> > > + * | | -> | |
> > > + * | v||v |
> > > + *
> > > + * DRM_MODE_REFLECT_Y
> > > + * |o || ^|
> > > + * | | -> | |
> > > + * | v||o |
> >
> > I think the above won't render correctly in sphinx. I think you need some
> > fixed-block quoting. Please run
> >
> > $ make htmldocs
> >
> > and check the output. With that addressed:
>
> One small problem here this file is not included in the htmldoc
> generation and no comment in here is marked to be included in html
> documentation.
Hah, I guess my review was sub-par. And with that I realized we have have
this prop fairly well documented already, but it's hidden in
drm_plane_create_rotation_property(). Plus linked from
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-properties
Might be better to move everything there, and just leave a hint here?
-Daniel
>
> >
> > Reviewed-by: Daniel Vetter
> >
> > > * This define is provided as a convenience, looking up the property id
> > > * using the name->prop id lookup is the preferred method.
> > > */
> > > --
> > > 2.18.0
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> --
> Cheers,
> Alex G
--
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 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #20 from CheatCodesOfLife --- Created attachment 141210 --> https://bugs.freedesktop.org/attachment.cgi?id=141210&action=edit glxinfo dump as requested -- 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 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #19 from CheatCodesOfLife --- (In reply to Andrey Grodzovsky from comment #18) > (In reply to CheatCodesOfLife from comment #17) > > (In reply to Andrey Grodzovsky from comment #16) > > > Hi everyone, I've tried with latest kernel and latest VEGA10 firmware and > > > wasn't able to reproduce this problem. > > > > > > From the logs it seems all of you are running 4.17.x kernel or earlier - > > > try > > > latest 4.18 and latest firmware form here - > > > > > > https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ > > > > Hi, > > > > I can reproduce this every time, on kernel 4.18 with mesa 18.3 and a Vega64. > > > > Simply try to open Mario Kart 8 in Cemu with wine, and the system will crash > > with the exact same dmesg. > > I had mesa 18.2 so I updated to 18.3 - still nothing. Could you provide > glxinfo dump ? What LLVM are you using ? I have 7. I have had this problem with mesa 18.2 and LLVM7. Currently on mesa 18.3 and LLVM8. I also had this result with a Vega56, and I know people online who have the same problem. Nobody can open Mario Kart 8 in Cemu with wine if they have a Vega card. I've attached my glxinfo > glxinfo.txt -- 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 v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Mon, Aug 20, 2018 at 11:44:56PM -0700, John Stultz wrote:
> On Tue, Jul 3, 2018 at 9:03 AM, Noralf Trønnes wrote:
> > This switches the CMA helper drivers that use its fbdev emulation over
> > to the generic fbdev emulation. It's the first phase of using generic
> > fbdev. A later phase will use DRM client callbacks for the
> > lastclose/hotplug/remove callbacks.
> >
> > There are currently 2 fbdev init/fini functions:
> > - drm_fb_cma_fbdev_init/drm_fb_cma_fbdev_fini
> > - drm_fbdev_cma_init/drm_fbdev_cma_fini
> >
> > This is because the work on generic fbdev came up during a fbdev
> > refactoring and thus wasn't completed. No point in completing that
> > refactoring when drivers will soon move to drm_fb_helper_generic_probe().
> >
> > tinydrm uses drm_fb_cma_fbdev_init_with_funcs().
> >
> > Cc: Laurent Pinchart
> > Signed-off-by: Noralf Trønnes
> > Acked-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_fb_cma_helper.c | 360
> > +---
> > include/drm/drm_fb_cma_helper.h | 3 -
> > 2 files changed, 42 insertions(+), 321 deletions(-)
> ...
> > -static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
> > - struct drm_gem_cma_object *cma_obj)
> > -{
> > - struct fb_deferred_io *fbdefio;
> > - struct fb_ops *fbops;
> > -
> > - /*
> > -* Per device structures are needed because:
> > -* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
> > -* fbdefio: individual delays
> > -*/
> > - fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
> > - fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
> > - if (!fbdefio || !fbops) {
> > - kfree(fbdefio);
> > - kfree(fbops);
> > - return -ENOMEM;
> > - }
> > -
> > - /* can't be offset from vaddr since dirty() uses cma_obj */
> > - fbi->screen_buffer = cma_obj->vaddr;
> > - /* fb_deferred_io_fault() needs a physical address */
> > - fbi->fix.smem_start =
> > page_to_phys(virt_to_page(fbi->screen_buffer));
> > -
> > - *fbops = *fbi->fbops;
> > - fbi->fbops = fbops;
> > -
> > - fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
> > - fbdefio->deferred_io = drm_fb_helper_deferred_io;
> > - fbi->fbdefio = fbdefio;
> > - fb_deferred_io_init(fbi);
> > - fbi->fbops->fb_mmap = drm_fbdev_cma_deferred_io_mmap;
> > -
> > - return 0;
> > -}
> > -
> > -static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
> > -{
> > - if (!fbi->fbdefio)
> > - return;
> > -
> > - fb_deferred_io_cleanup(fbi);
> > - kfree(fbi->fbdefio);
> > - kfree(fbi->fbops);
> > -}
> > -
> > -static int
> > -drm_fbdev_cma_create(struct drm_fb_helper *helper,
> > - struct drm_fb_helper_surface_size *sizes)
> > -{
> > - struct drm_fbdev_cma *fbdev_cma = to_fbdev_cma(helper);
> > - struct drm_device *dev = helper->dev;
> > - struct drm_gem_cma_object *obj;
> > - struct drm_framebuffer *fb;
> > - unsigned int bytes_per_pixel;
> > - unsigned long offset;
> > - struct fb_info *fbi;
> > - size_t size;
> > - int ret;
> > -
> > - DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
> > - sizes->surface_width, sizes->surface_height,
> > - sizes->surface_bpp);
> > -
> > - bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
> > - size = sizes->surface_width * sizes->surface_height *
> > bytes_per_pixel;
> > - obj = drm_gem_cma_create(dev, size);
> > - if (IS_ERR(obj))
> > - return -ENOMEM;
> > -
> > - fbi = drm_fb_helper_alloc_fbi(helper);
> > - if (IS_ERR(fbi)) {
> > - ret = PTR_ERR(fbi);
> > - goto err_gem_free_object;
> > - }
> > -
> > - fb = drm_gem_fbdev_fb_create(dev, sizes, 0, &obj->base,
> > -fbdev_cma->fb_funcs);
> > - if (IS_ERR(fb)) {
> > - dev_err(dev->dev, "Failed to allocate DRM framebuffer.\n");
> > - ret = PTR_ERR(fb);
> > - goto err_fb_info_destroy;
> > - }
> > -
> > - helper->fb = fb;
> > -
> > - fbi->par = helper;
> > - fbi->flags = FBINFO_FLAG_DEFAULT;
> > - fbi->fbops = &drm_fbdev_cma_ops;
> > -
> > - drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);
> > - drm_fb_helper_fill_var(fbi, helper, sizes->fb_width,
> > sizes->fb_height);
> > -
> > - offset = fbi->var.xoffset * bytes_per_pixel;
> > - offset += fbi->var.yoffset * fb->pitches[0];
> > -
> > - dev->mode_config.fb_base = (resource_size_t)obj->paddr;
> > - fbi->screen_base = obj->vaddr + offset;
> > - fbi->fix.smem_start = (unsigned long)(obj->paddr + offset);
>
> Hey Noralf, all,
> I've been digging for a bit on the regression that this patch has
> tripped on the HiKey
