[PATCH] pwm: Add MediaTek MT8183 display PWM driver support
Use the mtk_pwm_data struction to define different registers
and add MT8183 specific register operations, such as MT8183
have commit register, needs to enable double buffer
before writing register, and needs to select commit mode
and use PWM_PERIOD/PWM_HIGH_WIDTH.
Signed-off-by: Jitao Shi
---
drivers/pwm/pwm-mtk-disp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
index 893940d45f0d..15803c71fe80 100644
--- a/drivers/pwm/pwm-mtk-disp.c
+++ b/drivers/pwm/pwm-mtk-disp.c
@@ -277,10 +277,21 @@ static const struct mtk_pwm_data mt8173_pwm_data = {
.commit_mask = 0x1,
};
+static const struct mtk_pwm_data mt8183_pwm_data = {
+ .enable_mask = BIT(0),
+ .con0 = 0x18,
+ .con0_sel = 0x0,
+ .con1 = 0x1c,
+ .has_commit = false,
+ .bls_debug = 0x80,
+ .bls_debug_mask = 0x3,
+};
+
static const struct of_device_id mtk_disp_pwm_of_match[] = {
{ .compatible = "mediatek,mt2701-disp-pwm", .data = &mt2701_pwm_data},
{ .compatible = "mediatek,mt6595-disp-pwm", .data = &mt8173_pwm_data},
{ .compatible = "mediatek,mt8173-disp-pwm", .data = &mt8173_pwm_data},
+ { .compatible = "mediatek,mt8183-disp-pwm", .data = &mt8183_pwm_data},
{ }
};
MODULE_DEVICE_TABLE(of, mtk_disp_pwm_of_match);
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm/sched: Refactor ring mirror list handling.
Am 15.01.19 um 23:01 schrieb Grodzovsky, Andrey: On 01/11/2019 05:03 PM, Andrey Grodzovsky wrote: On 01/11/2019 02:11 PM, Koenig, Christian wrote: Am 11.01.19 um 16:37 schrieb Grodzovsky, Andrey: On 01/11/2019 04:42 AM, Koenig, Christian wrote: Am 10.01.19 um 16:56 schrieb Grodzovsky, Andrey: [SNIP] But we will not be adding the cb back in drm_sched_stop anymore, now we are only going to add back the cb in drm_sched_startr after rerunning those jobs in drm_sched_resubmit_jobs and assign them a new parent there anyway. Yeah, but when we find that we don't need to reset anything anymore then adding the callbacks again won't be possible any more. Christian. I am not sure I understand it, can u point me to example of how this will happen ? I am attaching my latest patches with waiting only for the last job's fence here just so we are on same page regarding the code. Well the whole idea is to prepare all schedulers, then check once more if the offending job hasn't completed in the meantime. If the job completed we need to be able to rollback everything and continue as if nothing had happened. Christian. Oh, but this piece of functionality - skipping HW ASIC reset in case the guilty job done is totally missing form this patch series and so needs to be added. So what you say actually is that for the case were we skip HW asic reset because the guilty job did complete we also need to skip resubmitting the jobs in drm_sched_resubmit_jobs and hence preserve the old parent fence pointer for reuse ? If so I would like to add all this functionality as a third patch since the first 2 patches are more about resolving race condition with jobs in flight while doing reset - what do you think ? Yeah, sounds perfectly fine to me. Christian. I realized there is another complication now for XGMI hive use case, we currently skip gpu recover for adev in case another gpu recover for different adev in same hive is running, under the assumption that we are going to reset all devices in hive anyway because that should cover our own dev too. But if we chose to skip now HW asic reset if our guilty job did finish we will aslo not HW reset any other devices in the hive even if one of them might actually had a bad job, wanted to do gpu recover but skipped it because our recover was in progress in that time. My general idea on that is to keep a list of guilty jobs per hive, when you start gpu recover you first add you guilty job to the hive and trylock hive->reset_lock. Any owner of hive->reset_lock (gpu recovery in progress) once he finished his recovery and released hive->reset_lock should go over hive->bad_jobs_list and if at least one of them is still not signaled (not done) trigger another gpu recovery and so on. If you do manage to trylock you also go over the list, clean it and perform recovery. This list probably needs to be protected with per hive lock. I also think we can for now at least finish reviewing the first 2 patches and submit them since as I said before they are not dealing with this topic and fixing existing race conditions. If you are OK with that I can send for review the last iteration of the first 2 patches where I wait for the last fence in ring mirror list. Andrey I implemented HW reset avoidance including XGMI use case according to the plan i specified. Patch is attached but I can't test it yet due to XGMI regression in PSP which is supposed to be fixed soon. Please take a look. Looks a bit too complicated on first glance. In general we should probably get away from handling a hive in any special way. Multiple timeout jobs in a hive are identical to multiple timeout jobs on different engines on a single device. How about the following handling: 1. Add the timeout job to a list. 2. Try to grab a lock to handle the reset, if that doesn't work because there is already a reset underway return immediately. 3. Stop all schedulers on all affected devices including stopping the timeouts and detaching all callbacks. 4. Double check the list of timed out jobs, if all hw fences of all jobs are completed now we actually don't need to do anything. 5. Do the reset on all affected devices. 6. Drop the lock. 7. Add callbacks again and restart the schedulers. Regards, Christian. Andrey Andrey Andrey ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ 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
Re: [PATCH v2] drm/i915: Pass down rc in intel_encoder->compute_config()
On Tue, 15 Jan 2019, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that means we have the potential to hit a normal modeset
> deadlock. However, because ->compute_config() only returns a bool this
> means we can't return -EDEADLK when we need to drop locks and try again
> which means we end up just failing the atomic check permanently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Changes since v1:
> * Add some newlines
> * Return only -EINVAL from hsw_crt_compute_config()
> * Propogate return code from intel_dp_compute_dsc_params()
> * Change all of the intel_dp_compute_link_config*() variants
> * Don't miss if (hdmi_port_clock_valid()) branch in
> intel_hdmi_compute_config()
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 8 ++--
> drivers/gpu/drm/i915/intel_crt.c | 35 +++---
> drivers/gpu/drm/i915/intel_ddi.c | 6 +--
> drivers/gpu/drm/i915/intel_display.c | 11 +++--
> drivers/gpu/drm/i915/intel_dp.c | 71 +++-
> drivers/gpu/drm/i915/intel_dp_mst.c | 12 ++---
> drivers/gpu/drm/i915/intel_drv.h | 18 +++
> drivers/gpu/drm/i915/intel_dvo.c | 11 +++--
> drivers/gpu/drm/i915/intel_hdmi.c| 14 +++---
> drivers/gpu/drm/i915/intel_lvds.c| 12 ++---
> drivers/gpu/drm/i915/intel_sdvo.c| 14 +++---
> drivers/gpu/drm/i915/intel_tv.c | 8 ++--
> drivers/gpu/drm/i915/vlv_dsi.c | 14 +++---
> 13 files changed, 122 insertions(+), 112 deletions(-)
Despite being an all i915 patch, this got applied to drm-misc-next,
causing conflicts where there really should have been none. :(
I am tempted to suggest reverting and re-applying to drm-intel, because
it will take weeks to sync both to drm-next and backmerge, and applying
further work on top in drm-intel will just cause more trouble.
Other ideas?
BR,
Jani.
>
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index f3a5f03646ce..355b48d1c937 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder
> *encoder,
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
> }
>
> -static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int gen11_dsi_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
> base);
> @@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct
> intel_encoder *encoder,
> pipe_config->clock_set = true;
> pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
>
> - return true;
> + return 0;
> }
>
> static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 33bd2addcbdd..081c333f30d2 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -345,51 +345,52 @@ intel_crt_mode_valid(struct drm_connector *connector,
> return MODE_OK;
> }
>
> -static bool intel_crt_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int intel_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return false;
> + return -EINVAL;
>
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> - return true;
> +
> + return 0;
> }
>
> -static bool pch_crt_compute_config(struct intel_encoder *encoder,
> -struct intel_crtc_state *pipe_config,
> -struct drm_connector_state *conn_stat
Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM
Am 16.01.19 um 01:33 schrieb Benjamin Herrenschmidt: > On Tue, 2019-01-15 at 22:31 +1100, Michael Ellerman wrote: As far as I know Power doesn't really supports un-cached memory at all, except for a very very old and odd configuration with AGP. >>> Hopefully Michael/Ben can elaborate here, but I was under the (possibly >>> mistaken) impression that mismatched attributes could cause a machine-check >>> on Power. >> That's what I've always been told, but I can't actually find where it's >> documented, I'll keep searching. >> >> But you're right that mixing cached / uncached is not really supported, >> and probably results in a machine check or worse. > .. or worse :) It could checkstop. Not sure if that would be so bad, it would at least give us a clear indicator that something is wrong instead of silently corrupting data. > It's also my understanding that on ARM v7 and above, it's technically > forbidden to map the same physical page with both cached and non-cached > mappings, since the cached one could prefetch (or speculatively load), > thus creating collisions and inconsistencies. Am I wrong here ? No, but you answer the wrong question. See we don't want to have different mappings of cached and non-cached on the CPU, but rather want to know if a snooped DMA from the PCIe counts as cached access as well. As far as I know on x86 it doesn't, so when you have an un-cached page you can still access it with a snooping DMA read/write operation and don't cause trouble. > The old hack of using non-cached mapping to avoid snoop cost in AGP and > others is just that ... an ugly and horrible hacks that should have > never eventuated, when the search for performance pushes HW people into > utter insanity :) Well I agree that un-cached system memory makes things much more complicated for a questionable gain. But fact is we now have to deal with the mess, so no point in complaining about it to much :) Cheers, Christian. > > Cheers, > Ben. > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
Am 16.01.19 um 08:09 schrieb Thomas Hellstrom: > On Tue, 2019-01-15 at 21:58 +0100, h...@lst.de wrote: >> On Tue, Jan 15, 2019 at 07:13:11PM +, Koenig, Christian wrote: >>> Thomas is correct that the interface you propose here doesn't work >>> at >>> all for GPUs. >>> >>> The kernel driver is not informed of flush/sync, but rather just >>> setups >>> coherent mappings between system memory and devices. >>> >>> In other words you have an array of struct pages and need to map >>> that to >>> a specific device and so create dma_addresses for the mappings. >> If you want a coherent mapping you need to use dma_alloc_coherent >> and dma_mmap_coherent and you are done, that is not the problem. >> That actually is one of the vmgfx modes, so I don't understand what >> problem we are trying to solve if you don't actually want a non- >> coherent mapping. > For vmwgfx, not making dma_alloc_coherent default has a couple of > reasons: > 1) Memory is associated with a struct device. It has not been clear > that it is exportable to other devices. > 2) There seems to be restrictions in the system pages allowable. GPUs > generally prefer highmem pages but dma_alloc_coherent returns a virtual > address implying GFP_KERNEL? While not used by vmwgfx, TTM typically > prefers HIGHMEM pages to facilitate caching mode switching without > having to touch the kernel map. > 3) Historically we had APIs to allow coherent access to user-space > defined pages. That has gone away not but the infrastructure was built > around it. > > dma_mmap_coherent isn't use because as the data moves between system > memory, swap and VRAM, PTEs of user-space mappings are adjusted > accordingly, meaning user-space doesn't have to unmap when an operation > is initiated that might mean the data is moved. To summarize once more: We have an array of struct pages and want to coherently map that to a device. If that is not possible because of whatever reason we want to get an error code or even not load the driver from the beginning. > > >> Although last time I had that discussion with Daniel Vetter >> I was under the impressions that GPUs really wanted non-coherent >> mappings. > Intel historically has done things a bit differently. And it's also > possible that embedded platforms and ARM prefer this mode of operation, > but I haven't caught up on that discussion. > >> But if you want a coherent mapping you can't go to a struct page, >> because on many systems you can't just map arbitrary memory as >> uncachable. It might either come from very special limited pools, >> or might need other magic applied to it so that it is not visible >> in the normal direct mapping, or at least not access through it. > > The TTM subsystem has been relied on to provide coherent memory with > the option to switch caching mode of pages. But only on selected and > well tested platforms. On other platforms we simply do not load, and > that's fine for now. > > But as mentioned multiple times, to make GPU drivers more compliant, > we'd really want that > > bool dma_streaming_is_coherent(const struct device *) > > API to help us decide when to load or not. Yes, please. Christian. > > Thanks, > Thomas > > > > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
On Tue, 2019-01-15 at 21:58 +0100, h...@lst.de wrote: > On Tue, Jan 15, 2019 at 07:13:11PM +, Koenig, Christian wrote: > > Thomas is correct that the interface you propose here doesn't work > > at > > all for GPUs. > > > > The kernel driver is not informed of flush/sync, but rather just > > setups > > coherent mappings between system memory and devices. > > > > In other words you have an array of struct pages and need to map > > that to > > a specific device and so create dma_addresses for the mappings. > > If you want a coherent mapping you need to use dma_alloc_coherent > and dma_mmap_coherent and you are done, that is not the problem. > That actually is one of the vmgfx modes, so I don't understand what > problem we are trying to solve if you don't actually want a non- > coherent mapping. For vmwgfx, not making dma_alloc_coherent default has a couple of reasons: 1) Memory is associated with a struct device. It has not been clear that it is exportable to other devices. 2) There seems to be restrictions in the system pages allowable. GPUs generally prefer highmem pages but dma_alloc_coherent returns a virtual address implying GFP_KERNEL? While not used by vmwgfx, TTM typically prefers HIGHMEM pages to facilitate caching mode switching without having to touch the kernel map. 3) Historically we had APIs to allow coherent access to user-space defined pages. That has gone away not but the infrastructure was built around it. dma_mmap_coherent isn't use because as the data moves between system memory, swap and VRAM, PTEs of user-space mappings are adjusted accordingly, meaning user-space doesn't have to unmap when an operation is initiated that might mean the data is moved. > Although last time I had that discussion with Daniel Vetter > I was under the impressions that GPUs really wanted non-coherent > mappings. Intel historically has done things a bit differently. And it's also possible that embedded platforms and ARM prefer this mode of operation, but I haven't caught up on that discussion. > > But if you want a coherent mapping you can't go to a struct page, > because on many systems you can't just map arbitrary memory as > uncachable. It might either come from very special limited pools, > or might need other magic applied to it so that it is not visible > in the normal direct mapping, or at least not access through it. The TTM subsystem has been relied on to provide coherent memory with the option to switch caching mode of pages. But only on selected and well tested platforms. On other platforms we simply do not load, and that's fine for now. But as mentioned multiple times, to make GPU drivers more compliant, we'd really want that bool dma_streaming_is_coherent(const struct device *) API to help us decide when to load or not. Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 9/9] drm/mediatek: add dpi dual edge support
___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm/mediatek: using different flags of clk for HDMI phy
Hi, Chunhui:
On Fri, 2019-01-04 at 15:03 +0800, chunhui dai wrote:
> The parent rate of hdmi phy had set by DPI driver.
The difference of DPI driver in MT8173 and MT2701 is
static const struct mtk_dpi_conf mt8173_conf = {
.cal_factor = mt8173_calculate_factor,
.reg_h_fre_con = 0xe0,
};
static const struct mtk_dpi_conf mt2701_conf = {
.cal_factor = mt2701_calculate_factor,
.reg_h_fre_con = 0xb0,
.edge_sel_en = true,
};
Which one influence the phy setting?
Regards,
CK
> We should not set or change the parent rate of MT2701 hdmi phy,
> as a result we should remove the flags of "CLK_SET_RATE_PARENT"
> from the clock of MT2701 hdmi phy.
>
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 13 +
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 1 +
> drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 1 +
> drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 1 +
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> index 79e737d..c0a9cf5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> @@ -109,13 +109,11 @@ static int mtk_hdmi_phy_power_off(struct phy *phy)
> return NULL;
> }
>
> -static void mtk_hdmi_phy_clk_get_ops(struct mtk_hdmi_phy *hdmi_phy,
> - const struct clk_ops **ops)
> +static void mtk_hdmi_phy_clk_get_data(struct mtk_hdmi_phy *hdmi_phy,
> + struct clk_init_data *clk_init)
> {
> - if (hdmi_phy && hdmi_phy->conf && hdmi_phy->conf->hdmi_phy_clk_ops)
> - *ops = hdmi_phy->conf->hdmi_phy_clk_ops;
> - else
> - dev_err(hdmi_phy->dev, "Failed to get clk ops of phy\n");
> + clk_init->flags = hdmi_phy->conf->flags;
> + clk_init->ops = hdmi_phy->conf->hdmi_phy_clk_ops;
> }
>
> static int mtk_hdmi_phy_probe(struct platform_device *pdev)
> @@ -128,7 +126,6 @@ static int mtk_hdmi_phy_probe(struct platform_device
> *pdev)
> struct clk_init_data clk_init = {
> .num_parents = 1,
> .parent_names = (const char * const *)&ref_clk_name,
> - .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
> };
>
> struct phy *phy;
> @@ -166,7 +163,7 @@ static int mtk_hdmi_phy_probe(struct platform_device
> *pdev)
> hdmi_phy->dev = dev;
> hdmi_phy->conf =
> (struct mtk_hdmi_phy_conf *)of_device_get_match_data(dev);
> - mtk_hdmi_phy_clk_get_ops(hdmi_phy, &clk_init.ops);
> + mtk_hdmi_phy_clk_get_data(hdmi_phy, &clk_init);
> hdmi_phy->pll_hw.init = &clk_init;
> hdmi_phy->pll = devm_clk_register(dev, &hdmi_phy->pll_hw);
> if (IS_ERR(hdmi_phy->pll)) {
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> index fdad8b1..446e2ac 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> @@ -21,6 +21,7 @@
>
> struct mtk_hdmi_phy_conf {
> bool tz_disabled;
> + unsigned long flags;
> const struct clk_ops *hdmi_phy_clk_ops;
> void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
> void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> index 68b124f..a28a32d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -248,6 +248,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
> *hdmi_phy)
>
> struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
> .tz_disabled = true,
> + .flags = CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_GATE,
> .hdmi_phy_clk_ops = &mtk_hdmi_phy_pll_ops,
> .hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
> .hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> index cb23c1e..63dde42 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> @@ -317,6 +317,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
> *hdmi_phy)
> }
>
> struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf = {
> + .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
> .hdmi_phy_clk_ops = &mtk_hdmi_phy_pll_ops,
> .hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
> .hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/xen-front: Make shmem backed display buffer coherent
On Wed, Jan 16, 2019 at 07:30:02AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > + if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
> > + DMA_BIDIRECTIONAL)) {
> > + ret = -EFAULT;
> > + goto fail_free_sgt;
> > + }
>
> Hmm, so it seems the arm guys could not come up with a suggestion how to
> solve that one in a better way. Ok, lets go with this then.
>
> But didn't we agree that this deserves a comment exmplaining the purpose
> of the dma_map_sg() call is to flush caches and that there is no actual
> DMA happening here?
Using a dma mapping call to flush caches is complete no-go. But the
real question is why you'd even want to flush cashes if you do not
want a dma mapping?
This whole issue keeps getting more and more confusing.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/xen-front: Make shmem backed display buffer coherent
Hi,
> + if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
> + DMA_BIDIRECTIONAL)) {
> + ret = -EFAULT;
> + goto fail_free_sgt;
> + }
Hmm, so it seems the arm guys could not come up with a suggestion how to
solve that one in a better way. Ok, lets go with this then.
But didn't we agree that this deserves a comment exmplaining the purpose
of the dma_map_sg() call is to flush caches and that there is no actual
DMA happening here?
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/vmwgfx: Remove set but not used variable 'srf'
Yue,
Thanks,
Reviewed-by: Thomas Hellstrom
Will include in the next -next pull.
/Thomas
On Wed, 2019-01-16 at 01:55 +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c: In function
> 'vmw_hw_surface_destroy':
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:335:22: warning:
> variable 'srf' set but not used [-Wunused-but-set-variable]
>
> It never used since commit 543831cfc976 ï¼^"drm/vmwgfx: Break out
> surface and
> context management to separate files")
>
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index 80a01cd..3b6976e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -332,7 +332,6 @@ static void vmw_hw_surface_destroy(struct
> vmw_resource *res)
> {
>
> struct vmw_private *dev_priv = res->dev_priv;
> - struct vmw_surface *srf;
> void *cmd;
>
> if (res->func->destroy == vmw_gb_surface_destroy) {
> @@ -359,7 +358,6 @@ static void vmw_hw_surface_destroy(struct
> vmw_resource *res)
>*/
>
> mutex_lock(&dev_priv->cmdbuf_mutex);
> - srf = vmw_res_to_srf(res);
> dev_priv->used_memory_size -= res->backup_size;
> mutex_unlock(&dev_priv->cmdbuf_mutex);
> }
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Split out drm_probe_helper.h
On Tue, Jan 15, 2019 at 5:41 AM Daniel Vetter wrote: > > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. > > v2: Make it compile. There was so much compile fail on arm drivers > that I figured I'll better not include any of the acks on v1. > > v3: Massive rebase because i915 has lost a lot of drmP.h includes, but > not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h > there was still one, which this patch largely removes. Which means > rolling out lots more includes all over. > > This will also conflict with ongoing drmP.h cleanup by others I > expect. > > v3: Rebase on top of atomic bochs. > > Cc: Sam Ravnborg > Cc: Jani Nikula > Cc: Laurent Pinchart > Acked-by: Rodrigo Vivi (v2) > Acked-by: Benjamin Gaignard (v2) > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: etna...@lists.freedesktop.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-...@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-te...@vger.kernel.org > Cc: xen-de...@lists.xen.org > --- > Merging this is going to be a bit a mess due to all the ongoing drmP.h > cleanups. I think the following should work: > - Apply Sam's prep patches for removing drmP.h from > drm_modeset_helper.h > - Get the i915 drmP.h cleanup backmerged into drm-misc-next > - Apply this patch. > - Apply Sam's patch to remove drmP.h from drm_modeset_helper.h > - All through drm-misc-next, which has some potential for trivial > conflicts around #includes with other drivers unfortunately. > > I hope there's no other driver who'll blow up accidentally because > someone else is doing a drmP.h cleanup. Laurent maybe? > > Jani, ack on this? > -Daniel amdgpu and radeon: Acked-by: Alex Deucher ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/mediatek: Add Mediatek framebuffer device
For Mediatek drm driver, use fbdev emulation to create a framebuffer
device.
Signed-off-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 6ec4ca070382..5fcc0e294696 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -378,6 +379,10 @@ static int mtk_drm_bind(struct device *dev)
if (ret < 0)
goto err_deinit;
+ ret = drm_fbdev_generic_setup(drm, 32);
+ if (ret)
+ DRM_ERROR("Failed to initialize fbdev: %d\n", ret);
+
return 0;
err_deinit:
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/mediatek: Implement gem prime vmap/vunmap function
For some application which need kernel virtual address, such as fbcon,
implement these function to map/unmap kernel virtual address of prime
buffer.
Signed-off-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 46 ++
drivers/gpu/drm/mediatek/mtk_drm_gem.h | 3 ++
3 files changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 6422e99952fe..6ec4ca070382 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -341,6 +341,8 @@ static struct drm_driver mtk_drm_driver = {
.gem_prime_get_sg_table = mtk_gem_prime_get_sg_table,
.gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
.gem_prime_mmap = mtk_drm_gem_mmap_buf,
+ .gem_prime_vmap = mtk_drm_gem_prime_vmap,
+ .gem_prime_vunmap = mtk_drm_gem_prime_vunmap,
.fops = &mtk_drm_fops,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index 259b7b0de1d2..38483e9ee071 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -241,3 +241,49 @@ struct drm_gem_object
*mtk_gem_prime_import_sg_table(struct drm_device *dev,
kfree(mtk_gem);
return ERR_PTR(ret);
}
+
+void *mtk_drm_gem_prime_vmap(struct drm_gem_object *obj)
+{
+ struct mtk_drm_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
+ struct sg_table *sgt;
+ struct sg_page_iter iter;
+ unsigned int npages;
+ unsigned int i = 0;
+
+ if (mtk_gem->kvaddr)
+ return mtk_gem->kvaddr;
+
+ sgt = mtk_gem_prime_get_sg_table(obj);
+ if (IS_ERR(sgt))
+ return NULL;
+
+ npages = obj->size >> PAGE_SHIFT;
+ mtk_gem->pages = kcalloc(npages, sizeof(*mtk_gem->pages), GFP_KERNEL);
+ if (!mtk_gem->pages)
+ goto out;
+
+ for_each_sg_page(sgt->sgl, &iter, sgt->orig_nents, 0) {
+ mtk_gem->pages[i++] = sg_page_iter_page(&iter);
+ if (i > npages)
+ break;
+ }
+ mtk_gem->kvaddr = vmap(mtk_gem->pages, npages, VM_MAP,
+ pgprot_writecombine(PAGE_KERNEL));
+
+out:
+ kfree((void *)sgt);
+
+ return mtk_gem->kvaddr;
+}
+
+void mtk_drm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
+{
+ struct mtk_drm_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
+
+ if (!mtk_gem->pages)
+ return;
+
+ vunmap(vaddr);
+ mtk_gem->kvaddr = 0;
+ kfree((void *)mtk_gem->pages);
+}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.h
b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
index 534639b43a1c..c047a7ef294f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
@@ -37,6 +37,7 @@ struct mtk_drm_gem_obj {
dma_addr_t dma_addr;
unsigned long dma_attrs;
struct sg_table *sg;
+ struct page **pages;
};
#define to_mtk_gem_obj(x) container_of(x, struct mtk_drm_gem_obj, base)
@@ -52,5 +53,7 @@ int mtk_drm_gem_mmap_buf(struct drm_gem_object *obj,
struct sg_table *mtk_gem_prime_get_sg_table(struct drm_gem_object *obj);
struct drm_gem_object *mtk_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach, struct sg_table *sg);
+void *mtk_drm_gem_prime_vmap(struct drm_gem_object *obj);
+void mtk_drm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
#endif
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-misc tree with the drm-intel tree
Hi all,
Today's linux-next merge of the drm-misc tree got conflicts in:
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel_drv.h
between commits:
e845f099f1c6 ("drm/i915/dsc: Add Per connector debugfs node for DSC
support/enable")
f6bff60e927b ("drm/i915/icl: Fix HPD handling for TypeC legacy ports")
from the drm-intel tree and commit:
96550555a78c ("drm/i915: Pass down rc in intel_encoder->compute_config()")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/intel_dp.c
index 0a3ac98a779e,d18b72b5f0b8..
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@@ -2062,11 -2055,11 +2066,12 @@@ intel_dp_compute_link_config(struct int
&limits);
/* enable compression if the mode doesn't fit available BW */
- if (ret) {
+ DRM_DEBUG_KMS("Force DSC en = %d\n", intel_dp->force_dsc_en);
- if (!ret || intel_dp->force_dsc_en) {
- if (!intel_dp_dsc_compute_config(intel_dp, pipe_config,
-conn_state, &limits))
- return false;
++ if (ret || intel_dp->force_dsc_en) {
+ ret = intel_dp_dsc_compute_config(intel_dp, pipe_config,
+ conn_state, &limits);
+ if (ret < 0)
+ return ret;
}
if (pipe_config->dsc_params.compression_enable) {
diff --cc drivers/gpu/drm/i915/intel_drv.h
index 5e5ceec7c004,19d9abd2666e..
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@@ -1816,10 -1805,10 +1815,10 @@@ void intel_dp_sink_set_decompression_st
bool enable);
void intel_dp_encoder_reset(struct drm_encoder *encoder);
void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
-void intel_dp_encoder_destroy(struct drm_encoder *encoder);
+void intel_dp_encoder_flush_work(struct drm_encoder *encoder);
- bool intel_dp_compute_config(struct intel_encoder *encoder,
-struct intel_crtc_state *pipe_config,
-struct drm_connector_state *conn_state);
+ int intel_dp_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state);
bool intel_dp_is_edp(struct intel_dp *intel_dp);
bool intel_dp_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port,
pgp8wVIEEqJcl.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109360] [AMD][TAHITI XT] dota2 vulkan texture glitches
https://bugs.freedesktop.org/show_bug.cgi?id=109360 Sylvain BERTRAND changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Sylvain BERTRAND --- Nope, the texture glitches do happen with the 2 weeks old kernel too. More likely mesa or dota itself. Need more testing in order to locate the faulty component. -- 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 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/14/19 11:13 AM, Liam Mark wrote:
> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>
>> Buffers may not be mapped from the CPU so skip cache maintenance here.
>> Accesses from the CPU to a cached heap should be bracketed with
>> {begin,end}_cpu_access calls so maintenance should not be needed anyway.
>>
>> Signed-off-by: Andrew F. Davis
>> ---
>> drivers/staging/android/ion/ion.c | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion.c
>> b/drivers/staging/android/ion/ion.c
>> index 14e48f6eb734..09cb5a8e2b09 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion.c
>> @@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct
>> dma_buf_attachment *attachment,
>>
>> table = a->table;
>>
>> -if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
>> -direction))
>> +if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
>> + direction, DMA_ATTR_SKIP_CPU_SYNC))
>
> Unfortunately I don't think you can do this for a couple reasons.
> You can't rely on {begin,end}_cpu_access calls to do cache maintenance.
> If the calls to {begin,end}_cpu_access were made before the call to
> dma_buf_attach then there won't have been a device attached so the calls
> to {begin,end}_cpu_access won't have done any cache maintenance.
>
That should be okay though, if you have no attachments (or all
attachments are IO-coherent) then there is no need for cache
maintenance. Unless you mean a sequence where a non-io-coherent device
is attached later after data has already been written. Does that
sequence need supporting? DMA-BUF doesn't have to allocate the backing
memory until map_dma_buf() time, and that should only happen after all
the devices have attached so it can know where to put the buffer. So we
shouldn't expect any CPU access to buffers before all the devices are
attached and mapped, right?
> Also ION no longer provides DMA ready memory, so if you are not doing CPU
> access then there is no requirement (that I am aware of) for you to call
> {begin,end}_cpu_access before passing the buffer to the device and if this
> buffer is cached and your device is not IO-coherent then the cache maintenance
> in ion_map_dma_buf and ion_unmap_dma_buf is required.
>
If I am not doing any CPU access then why do I need CPU cache
maintenance on the buffer?
Andrew
>> return ERR_PTR(-ENOMEM);
>>
>> return table;
>> @@ -272,7 +272,8 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment
>> *attachment,
>>struct sg_table *table,
>>enum dma_data_direction direction)
>> {
>> -dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
>> +dma_unmap_sg_attrs(attachment->dev, table->sgl, table->nents,
>> + direction, DMA_ATTR_SKIP_CPU_SYNC);
>> }
>>
>> static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
>> --
>> 2.19.1
>>
>> ___
>> devel mailing list
>> de...@linuxdriverproject.org
>> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
>>
>
> Qualcomm Innovation Center, Inc. is a member of 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
Re: Armada DRM: bridge with componentized devices
[CC Greg] On Tuesday, January 15, 2019 1:04:02 AM CET Rafael J. Wysocki wrote: > [CC Lukas and linux-pm] > > On Mon, Jan 14, 2019 at 1:32 PM Rafael J. Wysocki wrote: > > > > On Fri, Jan 11, 2019 at 3:49 PM Russell King - ARM Linux > > wrote: > > [cut] > > > > > > > This thread is discussing how to deal with Armada DRM, its use of the > > > component helper, TDA998x's hybrid use of the component helper and > > > DRM bridges. > > > > > > Currently, DRM bridges register into the DRM system and are added to > > > a global list of bridges. When a DRM driver binds, it looks up the > > > DRM bridge and attaches to it. There is no way in generic DRM code > > > for the DRM driver to know if the DRM bridge is unbound from DRM, > > > consequently a DRM driver may continue trying to call functions in > > > the DRM bridge driver using memory that has already been freed. > > > > > > We had similar issues with imx-drm, and a number of years ago at a > > > kernel summit, this was discussed, and I proposed a system which is > > > now known as the component helper. This handles the problem of a > > > multi-component system. > > > > > > However, DRM bridge was already established, and there appears to be > > > no desire to convert DRM bridges and DRM drivers to use the component > > > helper. > > > > > > We are presently in the situation where Armada DRM is incompatible > > > with the DRM bridges way of doing things, and making it compatible > > > essentially means introducing potential use-after-free bugs into the > > > code. > > > > > > Device links in their stateful form appear to provide an alternative > > > to the component helper, in that a stateful device link will remove > > > consumers of a resource when the supplier is going away - which is > > > exactly the problem which the component helper is solving. The > > > difference is that device links look like being a cleaner solution. > > > > > > Just like the component helper, a stateful link would unbind the > > > consumer of a resource when the supplier goes away - which is exactly > > > the behaviour we're wanting. > > > > > > The problem is that the connection between various drivers is only > > > really known when the drivers obtain their resources, and the > > > following can happen: > > > > > > supplierconsumer > > > > > > probe() > > > alloc > > > probe() > > > publish > > > obtain supplier's resource > > > return > > > > > > Where things go wrong is if a stateful link is created when the > > > consumer obtains the suppliers resource before the supplier has > > > finished probing - which from what's been said is illegal. > > > > It just doesn't work (which means "invalid" rather than "illegal" I > > guess, but whatever :-)). > > > > Admittedly, the original design didn't take this particular case into > > account and I'm not actually sure how it can be taken into account > > either. > > > > If the link is created by the consumer in the scenario above, its > > status will be updated twice in a row after the consumer probe returns > > and after the supplier probe returns. It looks like this update would > > need to work regardless of the order it which this happened which > > sounds somewhat challenging. I would need to think about that. > > So if I'm not mistaken it can be made work with the help of the > (completely untested) attached patch (of course, the documentation > would need to be updated too). > > The key observation here is that it should be fine to create a link > from the consumer driver's probe while the supplier is still probing > if the consumer has some way to find out that the supplier is > functional at that point (like when it has published itself already in > your example above). The initial state of the link can be "consumer > probe" in that case and I don't see a reason why that might not work. > Below is a more complete patch that should take all of the corner cases into account unless I have missed anything. Testing it would be appreciated. :-) --- From: Rafael J. Wysocki Subject: [PATCH] driver core: Fix adding device links to probing suppliers Currently, it is not valid to add a device link from a consumer driver ->probe() callback to a supplier that is still probing too, but generally this is a valid use case. For example, if the consumer has just acquired a resource that can only be available when the supplier is functional, adding a device link to that supplier right away should be safe (and even desirable arguably), but device_link_add() doesn't handle that case correctly and the initial state of the link created by it is wrong then. To address this problem, change the initial state of device links added between a probing supplier and a probing consumer to DL_STATE_CONSUMER_PROBE and update device_links_driver_bound() to skip such links on the supplier side. With this change, if the supplier probe completes first, device_links_driver_bound()
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #102 from tempel.jul...@gmail.com --- Is that with latest git version of the xf86 DDX driver, including the PR Michel posted? I had subpar game performance (looked like half of the fps) too without vsync the last time I checked before the aforementioned PR, but everything looks well here now (apart from TearFree breaking issue I just opened). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/panel: simple: add support for PDA 91-00156-A0 panel
Hi Eugen.
Patch looks good, but a small improvement proposal.
On Mon, Jan 14, 2019 at 09:43:31AM +, eugen.hris...@microchip.com wrote:
> From: Eugen Hristev
>
> PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel.
> This panel with backlight is found in PDA 5" LCD screen (TM5000 series or
> AC320005-5).
>
> Signed-off-by: Eugen Hristev
> ---
> drivers/gpu/drm/panel/panel-simple.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 9c69e73..61361ba 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2008,6 +2008,30 @@ static const struct panel_desc ortustech_com43h4m85ulc
> = {
> .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
> };
>
> +static const struct drm_display_mode pda_91_00156_a0_mode = {
> + .clock = 33300,
> + .hdisplay = 800,
> + .hsync_start = 800 + 1,
> + .hsync_end = 800 + 1 + 64,
> + .htotal = 800 + 1 + 64 + 64,
> + .vdisplay = 480,
> + .vsync_start = 480 + 1,
> + .vsync_end = 480 + 1 + 23,
> + .vtotal = 480 + 1 + 23 + 22,
> + .vrefresh = 60,
> +};
.flags are omitted, as it is for many panels in simple-panel.
drm_modes.h do not document any default, so we must assume default equals no
flags.
I would expect two of these as a minimum:
DRM_MODE_FLAG_PHSYNC: horizontal sync is active high.
DRM_MODE_FLAG_NHSYNC: horizontal sync is active low.
DRM_MODE_FLAG_PVSYNC: vertical sync is active high.
DRM_MODE_FLAG_NVSYNC: vertical sync is active low.
But it obviously works for a lot of panel, so one
may say why bother with it.
> +
> +static const struct panel_desc pda_91_00156_a0 = {
> + .modes = &pda_91_00156_a0_mode,
> + .num_modes = 1,
> + .size = {
> + .width = 152,
> + .height = 91,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> +};
.bus_format is specified - good!
Consider if .bus_flags needs to be specified.
(More or less same argumentation like for .flags above).
I could not find any data-sheet on the panel,
so I could not check if it is OK that all delays are 0.
So to recap - things looks fine, but consider to be more explicit
in .flags, bus_flags, and check if it is OK that all timing parameters are 0.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] dt-bindings: add vendor prefix for PDA Precision Design Associates, Inc.
Hi Eugen. On Mon, Jan 14, 2019 at 09:43:26AM +, eugen.hris...@microchip.com wrote: > From: Eugen Hristev > > Precision Design Associates, Inc. (PDA) manufactures standard and custom > capacitive touch screens, LCD's embedded controllers and custom embedded > software. They specialize in industrial, rugged and outdoor applications. > Website: http://www.pdaatl.com/ > > Signed-off-by: Eugen Hristev > Reviewed-by: Rob Herring > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index 3895085..967a670 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -297,6 +297,7 @@ ovti OmniVision Technologies > oxsemi Oxford Semiconductor, Ltd. > panasonicPanasonic Corporation > parade Parade Technologies Inc. > +pda Precision Design Associates, Inc. The website uses "pdaatl" - which looks a little less generic than just "pda". But then I do not get any association from pdaatl to Precision Design Associates) so you can say it is not a good abbrevation either. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm/sched: Refactor ring mirror list handling.
On 01/11/2019 05:03 PM, Andrey Grodzovsky wrote: > > > On 01/11/2019 02:11 PM, Koenig, Christian wrote: >> Am 11.01.19 um 16:37 schrieb Grodzovsky, Andrey: >>> On 01/11/2019 04:42 AM, Koenig, Christian wrote: Am 10.01.19 um 16:56 schrieb Grodzovsky, Andrey: > [SNIP] But we will not be adding the cb back in drm_sched_stop anymore, now we are only going to add back the cb in drm_sched_startr after rerunning those jobs in drm_sched_resubmit_jobs and assign them a new parent there anyway. >>> Yeah, but when we find that we don't need to reset anything anymore >>> then adding the callbacks again won't be possible any more. >>> >>> Christian. >> I am not sure I understand it, can u point me to example of how this >> will happen ? I am attaching my latest patches with waiting only for >> the last job's fence here just so we are on same page regarding >> the code. Well the whole idea is to prepare all schedulers, then check once more if the offending job hasn't completed in the meantime. If the job completed we need to be able to rollback everything and continue as if nothing had happened. Christian. >>> Oh, but this piece of functionality - skipping HW ASIC reset in case >>> the >>> guilty job done is totally missing form this patch series and so needs >>> to be added. So what you say actually is that for the case were we skip >>> HW asic reset because the guilty job did complete we also need to skip >>> resubmitting the jobs in drm_sched_resubmit_jobs and hence preserve the >>> old parent fence pointer for reuse ? If so I would like to add all this >>> functionality as a third patch since the first 2 patches are more about >>> resolving race condition with jobs in flight while doing reset - >>> what do >>> you think ? >> Yeah, sounds perfectly fine to me. >> >> Christian. > > I realized there is another complication now for XGMI hive use case, > we currently skip gpu recover for adev in case another gpu recover for > different adev in same hive is running, under the assumption that we > are going to reset all devices in hive anyway because that should > cover our own dev too. But if we chose to skip now HW asic reset if > our guilty job did finish we will aslo not HW reset any other devices > in the hive even if one of them might actually had a bad job, wanted > to do gpu recover but skipped it because our recover was in progress > in that time. > My general idea on that is to keep a list of guilty jobs per hive, > when you start gpu recover you first add you guilty job to the hive > and trylock hive->reset_lock. Any owner of hive->reset_lock (gpu > recovery in progress) once he finished his recovery and released > hive->reset_lock should go over hive->bad_jobs_list and if at least > one of them is still not signaled (not done) trigger another gpu > recovery and so on. If you do manage to trylock you also go over the > list, clean it and perform recovery. This list probably needs to be > protected with per hive lock. > I also think we can for now at least finish reviewing the first 2 > patches and submit them since as I said before they are not dealing > with this topic and fixing existing race conditions. If you are OK > with that I can send for review the last iteration of the first 2 > patches where I wait for the last fence in ring mirror list. > > Andrey I implemented HW reset avoidance including XGMI use case according to the plan i specified. Patch is attached but I can't test it yet due to XGMI regression in PSP which is supposed to be fixed soon. Please take a look. Andrey > >> >>> Andrey >> Andrey >> ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> ___ >> amd-gfx mailing list >> amd-...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > From 60085547eec4002fe447783be68e7f14342944ff Mon Sep 17 00:00:00 2001 From: Andrey Grodzovsky Date: Tue, 15 Jan 2019 15:39:38 -0500 Subject: drm/sched: Skip HW reset if guilty job is signaled. Also take care of XGMI use case - special care needs to be taken of other devs in hive who had jobs TO but delegated their reset to current reset instance assuming it will do HW reset for them. In such case the reset in progress after finishing (and if HW reset was optimized) will inspect a perhive list of jobs for any jobs which still not finished and will issue another reset for them. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 100 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 29 + drivers/gpu/drm/amd/amdgpu/amdgpu_job.h| 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_xg
[PATCH v2 1/1] drm: fix alpha build after drm_util.h change
0-DAY reported the following bug:
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 21376e2c3c5bad5e87ba700c055c8a8235c2bfd5
commit: e9eafcb589213395232084a2378e2e90f67feb29 [1/2] drm: move
drm_can_sleep() to drm_util.h
config: alpha-allmodconfig (attached as .config)
...
In file included from include/linux/irqflags.h:16:0,
from include/drm/drm_util.h:35,
from drivers/gpu/drm/qxl/qxl_cmd.c:28:
>> arch/alpha/include/asm/irqflags.h:58:15: error: unknown type name 'bool'
static inline bool arch_irqs_disabled_flags(unsigned long flags)
^~~~
And later following bug:
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 21376e2c3c5bad5e87ba700c055c8a8235c2bfd5
commit: e9eafcb589213395232084a2378e2e90f67feb29 [1/2] drm: move
drm_can_sleep() to drm_util.h
config: ia64-allyesconfig (attached as .config)
...
In file included from arch/ia64/include/asm/irqflags.h:14,
from include/linux/irqflags.h:16,
from include/drm/drm_util.h:35,
from drivers/gpu/drm/qxl/qxl_cmd.c:28:
arch/ia64/include/asm/pal.h: In function 'ia64_pal_tr_read':
arch/ia64/include/asm/pal.h:1703:64: error: implicit declaration of function
'ia64_tpa'; did you mean 'ia64_pal'? [-Werror=implicit-function-declaration]
PAL_CALL_PHYS_STK(iprv, PAL_VM_TR_READ, reg_num,
tr_type,(u64)ia64_tpa(tr_buffer));
^~~~
...
So we have a situation where we do not pull in
when building for alpha and for ia64 we need even more definitions
are required.
Two invasive fixes where considered:
- Change all declarations of arch_irqs_disabled_flags() to use bool
- Add include of to all files that uses bool for
arch_irqs_disabled_flags
To invasive with a too high pain/benefit ratio, so dropped.
They would not cover ia64 either.
Some less invasive fixes was also considered:
- Add include of to drm_util.h
- Add include of to drm_util.h
The first was dropped as this did not cover the ia64 case.
The latter was considered the best option as there could
be other similar cases and we would like the header files below
include/drm/ to be selfcontained.
So we end up pulling in a lot of stuff not needed, but this is
the price we pay in drm/ because the kernel headers are not all
selfcontained.
While at it, ordred the includefiles in drm_util in alphabetical order.
Build tested with alpha,ia64,arm,x86 with allmodconfig and allyesconfig.
v2:
- fix ia64 build, changed to include interrupt.h
- sort include files alphabetically
Fixes: 733748ac37b45 ("drm: move drm_can_sleep() to drm_util.h")
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
---
include/drm/drm_util.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_util.h b/include/drm/drm_util.h
index 0500da65b1d1..8163d35f8327 100644
--- a/include/drm/drm_util.h
+++ b/include/drm/drm_util.h
@@ -32,9 +32,9 @@
* Macros and inline functions that does not naturally belong in other places
*/
-#include
-#include
+#include
#include
+#include
#include
/*
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #101 from Hans D --- For me the TearFree Option works flawlessly with amdgpu.dc=0 on 5.0rc2 and 4.20.1, but 3d games lag. With amdgpu.dc=1 there are some slight hiccups every 2-3 seconds (Firefox`s autoscrolling, video playback etc.), but 3d works without noticeable issues. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 43/49] dt-bindings: display: Add OSD Displays OSD070T1718-19TS panel binding
On Fri, Jan 11, 2019 at 05:51:14AM +0200, Laurent Pinchart wrote: > The OSD Displays OSD070T1718-19TS is a 7" WVGA (800x480) 24bit RGB panel > and is compatible with the simple-panel bindings. > > Signed-off-by: Laurent Pinchart > --- > .../display/panel/osddisplays,osd070t1718-19ts.txt | 7 +++ > 1 file changed, 7 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/osddisplays,osd070t1718-19ts.txt > > diff --git > a/Documentation/devicetree/bindings/display/panel/osddisplays,osd070t1718-19ts.txt > > b/Documentation/devicetree/bindings/display/panel/osddisplays,osd070t1718-19ts.txt > new file mode 100644 > index ..ae7011820231 > --- /dev/null > +++ > b/Documentation/devicetree/bindings/display/panel/osddisplays,osd070t1718-19ts.txt > @@ -0,0 +1,7 @@ > +OSD Displays OSD070T1718-19TS 7" WVGA TFT LCD panel > + > +Required properties: > +- compatible: should be "osddisplays,osd070t1718-19ts" > + > +This binding is compatible with the simple-panel binding, which is specified > +in simple-panel.txt in this directory. Please enumerate exactly which properties from simple-panel are used. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 38/49] dt-bindings: display: tfp410: Add bus parameters properties
On Fri, 11 Jan 2019 05:51:09 +0200, Laurent Pinchart wrote: > The TFP410 supports configuration of several input bus parameters > through either the I2C port or chip pins. In the latter case, we need to > specify those parameters in DT. > > Two new properties are added, ti,deskew to specify the data de-skew > configuration (as set through the DK[3:1] pins), and pclk-sample to > specify the pixel clock sampling edge (as set through the EDGE pin). > > Signed-off-by: Laurent Pinchart > Reviewed-by: Tomi Valkeinen > --- > .../bindings/display/bridge/ti,tfp410.txt | 24 ++- > 1 file changed, 18 insertions(+), 6 deletions(-) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102909] radeon 0000:03:00.0: ring 0 stalled for more than 10000msec
https://bugs.freedesktop.org/show_bug.cgi?id=102909 --- Comment #4 from Christopher Clapp --- (In reply to Pander from comment #3) > Christopher, are you still experiencing this bug? Pander, the Radeon graphics card in my computer died, so I replaced it with an Nvidia card. I didn't experience the bug again after that. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 42/49] dt-bindings: Add vendor prefix for OSD Displays
On Fri, 11 Jan 2019 05:51:13 +0200, Laurent Pinchart wrote: > OSD Displays is a panel manufacturer. It has been acquired by New Vision > Displays in 2015 but continues to operate under its own brand name. > > Signed-off-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
On Tue, Jan 15, 2019 at 07:13:11PM +, Koenig, Christian wrote: > Thomas is correct that the interface you propose here doesn't work at > all for GPUs. > > The kernel driver is not informed of flush/sync, but rather just setups > coherent mappings between system memory and devices. > > In other words you have an array of struct pages and need to map that to > a specific device and so create dma_addresses for the mappings. If you want a coherent mapping you need to use dma_alloc_coherent and dma_mmap_coherent and you are done, that is not the problem. That actually is one of the vmgfx modes, so I don't understand what problem we are trying to solve if you don't actually want a non-coherent mapping. Although last time I had that discussion with Daniel Vetter I was under the impressions that GPUs really wanted non-coherent mappings. But if you want a coherent mapping you can't go to a struct page, because on many systems you can't just map arbitrary memory as uncachable. It might either come from very special limited pools, or might need other magic applied to it so that it is not visible in the normal direct mapping, or at least not access through it. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109239] Polaris10: Periodic random black screens for 1-2 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109239 --- Comment #8 from Raman Gupta --- Created attachment 143137 --> https://bugs.freedesktop.org/attachment.cgi?id=143137&action=edit Xorg.0.log with modeset ddx instead of amdgpu ddx (In reply to Michel Dänzer from comment #4) > Does it also happen with the Xorg modesetting driver instead of > xf86-video-amdgpu, or with a Wayland compositor such as GNOME on Wayland? Ok, I've tried both the modeset ddx (Xorg.0.log attached), as well as a Wayland compositor (plasma-wayland), and both exhibit exactly the same behavior. I used kernel setting `amdgpu.dc=0` in both cases. Unfortunately, I can't try it with `amdgpu.dc=1` due to issue https://bugs.freedesktop.org/show_bug.cgi?id=109238. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915: Pass down rc in intel_encoder->compute_config()
On Tue, Jan 15, 2019 at 03:08:00PM -0500, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that means we have the potential to hit a normal modeset
> deadlock. However, because ->compute_config() only returns a bool this
> means we can't return -EDEADLK when we need to drop locks and try again
> which means we end up just failing the atomic check permanently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Changes since v1:
> * Add some newlines
> * Return only -EINVAL from hsw_crt_compute_config()
> * Propogate return code from intel_dp_compute_dsc_params()
> * Change all of the intel_dp_compute_link_config*() variants
> * Don't miss if (hdmi_port_clock_valid()) branch in
> intel_hdmi_compute_config()
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
Patch looks great. Hopefully we got them all.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 8 ++--
> drivers/gpu/drm/i915/intel_crt.c | 35 +++---
> drivers/gpu/drm/i915/intel_ddi.c | 6 +--
> drivers/gpu/drm/i915/intel_display.c | 11 +++--
> drivers/gpu/drm/i915/intel_dp.c | 71 +++-
> drivers/gpu/drm/i915/intel_dp_mst.c | 12 ++---
> drivers/gpu/drm/i915/intel_drv.h | 18 +++
> drivers/gpu/drm/i915/intel_dvo.c | 11 +++--
> drivers/gpu/drm/i915/intel_hdmi.c| 14 +++---
> drivers/gpu/drm/i915/intel_lvds.c| 12 ++---
> drivers/gpu/drm/i915/intel_sdvo.c| 14 +++---
> drivers/gpu/drm/i915/intel_tv.c | 8 ++--
> drivers/gpu/drm/i915/vlv_dsi.c | 14 +++---
> 13 files changed, 122 insertions(+), 112 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index f3a5f03646ce..355b48d1c937 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder
> *encoder,
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
> }
>
> -static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int gen11_dsi_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
> base);
> @@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct
> intel_encoder *encoder,
> pipe_config->clock_set = true;
> pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
>
> - return true;
> + return 0;
> }
>
> static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 33bd2addcbdd..081c333f30d2 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -345,51 +345,52 @@ intel_crt_mode_valid(struct drm_connector *connector,
> return MODE_OK;
> }
>
> -static bool intel_crt_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int intel_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return false;
> + return -EINVAL;
>
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> - return true;
> +
> + return 0;
> }
>
> -static bool pch_crt_compute_config(struct intel_encoder *encoder,
> -struct intel_crtc_state *pipe_config,
> -struct drm_connector_state *conn_state)
> +static int pch_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_m
[PATCH v2] drm/i915: Pass down rc in intel_encoder->compute_config()
Something that I completely missed when implementing the new MST VCPI
atomic helpers is that with those helpers, there's technically a chance
of us having to grab additional modeset locks in ->compute_config() and
furthermore, that means we have the potential to hit a normal modeset
deadlock. However, because ->compute_config() only returns a bool this
means we can't return -EDEADLK when we need to drop locks and try again
which means we end up just failing the atomic check permanently. Whoops.
So, fix this by modifying ->compute_config() to pass down an actual
error code instead of a bool so that the atomic check can be restarted
on modeset deadlocks.
Thanks to Ville Syrjälä for pointing this out!
Changes since v1:
* Add some newlines
* Return only -EINVAL from hsw_crt_compute_config()
* Propogate return code from intel_dp_compute_dsc_params()
* Change all of the intel_dp_compute_link_config*() variants
* Don't miss if (hdmi_port_clock_valid()) branch in
intel_hdmi_compute_config()
Signed-off-by: Lyude Paul
Cc: Ville Syrjälä
Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
---
drivers/gpu/drm/i915/icl_dsi.c | 8 ++--
drivers/gpu/drm/i915/intel_crt.c | 35 +++---
drivers/gpu/drm/i915/intel_ddi.c | 6 +--
drivers/gpu/drm/i915/intel_display.c | 11 +++--
drivers/gpu/drm/i915/intel_dp.c | 71 +++-
drivers/gpu/drm/i915/intel_dp_mst.c | 12 ++---
drivers/gpu/drm/i915/intel_drv.h | 18 +++
drivers/gpu/drm/i915/intel_dvo.c | 11 +++--
drivers/gpu/drm/i915/intel_hdmi.c| 14 +++---
drivers/gpu/drm/i915/intel_lvds.c| 12 ++---
drivers/gpu/drm/i915/intel_sdvo.c| 14 +++---
drivers/gpu/drm/i915/intel_tv.c | 8 ++--
drivers/gpu/drm/i915/vlv_dsi.c | 14 +++---
13 files changed, 122 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index f3a5f03646ce..355b48d1c937 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder
*encoder,
pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
}
-static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
-struct intel_crtc_state *pipe_config,
-struct drm_connector_state *conn_state)
+static int gen11_dsi_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state)
{
struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
base);
@@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct intel_encoder
*encoder,
pipe_config->clock_set = true;
pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
- return true;
+ return 0;
}
static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 33bd2addcbdd..081c333f30d2 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -345,51 +345,52 @@ intel_crt_mode_valid(struct drm_connector *connector,
return MODE_OK;
}
-static bool intel_crt_compute_config(struct intel_encoder *encoder,
-struct intel_crtc_state *pipe_config,
-struct drm_connector_state *conn_state)
+static int intel_crt_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state)
{
struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
- return false;
+ return -EINVAL;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
- return true;
+
+ return 0;
}
-static bool pch_crt_compute_config(struct intel_encoder *encoder,
- struct intel_crtc_state *pipe_config,
- struct drm_connector_state *conn_state)
+static int pch_crt_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state)
{
struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
- return false;
+ return -EINVAL;
pipe_config->has_pch_encoder = true;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
-
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #100 from Brandon Wright --- (In reply to tempel.julian from comment #99) > Does the trick for me too, TearFree with amdgpu.dc=0 seems to be completely > smooth now. Delay / input latency seems to be the same between amdgpu.dc=1 > and 0, I suppose this is as low as it can be with traditional vsync (without > variable vblank). Confirmed here, too. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/5] dt-bindings: display: bridge: fork out ti,ds90c185 from lvds-transmitter
On Fri, 11 Jan 2019 15:18:55 +, Peter Rosin wrote: > DS90C185 has a shutdown pin which does not fit in the lvds-transmitter > binding, which is meant to be generic. > > The sister chip DS90C187 is similar to DS90C185, describe it here as well. > > Signed-off-by: Peter Rosin > --- > .../bindings/display/bridge/lvds-transmitter.txt | 10 ++-- > .../bindings/display/bridge/ti,ds90c185.txt| 55 > ++ > 2 files changed, 59 insertions(+), 6 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109370] [Runelite GPU plugin] Enabling GPU plugin produces incorrect rendering
https://bugs.freedesktop.org/show_bug.cgi?id=109370 MIka R changed: What|Removed |Added Severity|normal |minor Priority|medium |low -- 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] lib/scatterlist: Provide a DMA page iterator
Am 15.01.19 um 19:31 schrieb h...@lst.de: > On Tue, Jan 15, 2019 at 06:03:39PM +, Thomas Hellstrom wrote: >> In the graphics case, it's probably because it doesn't fit the graphics >> use-cases: >> >> 1) Memory typically needs to be mappable by another device. (the "dma- >> buf" interface) > And there is nothing preventing dma-buf sharing of these buffers. > Unlike the get_sgtable mess it can actually work reliably on > architectures that have virtually tagged caches and/or don't > guarantee cache coherency with mixed attribute mappings. > >> 2) DMA buffers are exported to user-space and is sub-allocated by it. >> Mostly there are no GPU user-space kernel interfaces to sync / flush >> subregions and these syncs may happen on a smaller-than-cache-line >> granularity. > I know of no architectures that can do cache maintainance on a less > than cache line basis. Either the instructions require you to > specifcy cache lines, or they do sometimes more, sometimes less > intelligent rounding up. > > Note that as long dma non-coherent buffers are devices owned it > is up to the device and the user space driver to take care of > coherency, the kernel very much is out of the picture. Thomas is correct that the interface you propose here doesn't work at all for GPUs. The kernel driver is not informed of flush/sync, but rather just setups coherent mappings between system memory and devices. In other words you have an array of struct pages and need to map that to a specific device and so create dma_addresses for the mappings. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109370] [Runelite GPU plugin] Enabling GPU plugin produces incorrect rendering
https://bugs.freedesktop.org/show_bug.cgi?id=109370 Bug ID: 109370 Summary: [Runelite GPU plugin] Enabling GPU plugin produces incorrect rendering Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: mika3...@hotmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 143135 --> https://bugs.freedesktop.org/attachment.cgi?id=143135&action=edit Garbled polygons and some missing texture with GPU plugin enabled More info https://github.com/runelite/runelite/issues/6841 -- 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 14/14] staging: android: ion: Add UNMAPPED heap type and helper
On 1/15/19 10:43 AM, Laura Abbott wrote:
On 1/15/19 7:58 AM, Andrew F. Davis wrote:
On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, in
my specific case due to firewalls. This memory can still be
allocated from and used by devices that do have access to the
backing memory.
Based originally on the secure/unmapped heap from Linaro for
the OP-TEE SDP implementation, this was re-written to match
the carveout heap helper code.
Suggested-by: Etienne Carriere
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/Kconfig | 10 ++
drivers/staging/android/ion/Makefile | 1 +
drivers/staging/android/ion/ion.h | 16 +++
.../staging/android/ion/ion_unmapped_heap.c | 123 ++
drivers/staging/android/uapi/ion.h | 3 +
5 files changed, 153 insertions(+)
create mode 100644 drivers/staging/android/ion/ion_unmapped_heap.c
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index 0fdda6f62953..a117b8b91b14 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -42,3 +42,13 @@ config ION_CMA_HEAP
Choose this option to enable CMA heaps with Ion. This heap is
backed
by the Contiguous Memory Allocator (CMA). If your system has
these
regions, you should say Y here.
+
+config ION_UNMAPPED_HEAP
+ bool "ION unmapped heap support"
+ depends on ION
+ help
+ Choose this option to enable UNMAPPED heaps with Ion. This heap is
+ backed in specific memory pools, carveout from the Linux memory.
+ Unlike carveout heaps these are assumed to be not mappable by
+ kernel or user-space.
+ Unless you know your system has these regions, you should say N
here.
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index 17f3a7569e3d..c71a1f3de581 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o
ion_page_pool.o
obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
+obj-$(CONFIG_ION_UNMAPPED_HEAP) += ion_unmapped_heap.o
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index 97b2876b165a..ce74332018ba 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -341,4 +341,20 @@ static inline struct ion_heap
*ion_chunk_heap_create(phys_addr_t base, size_t si
}
#endif
+#ifdef CONFIG_ION_UNMAPPED_HEAP
+/**
+ * ion_unmapped_heap_create
+ * @base: base address of carveout memory
+ * @size: size of carveout memory region
+ *
+ * Creates an unmapped ion_heap using the passed in data
+ */
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t
size);
+#else
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t size)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
#endif /* _ION_H */
diff --git a/drivers/staging/android/ion/ion_unmapped_heap.c
b/drivers/staging/android/ion/ion_unmapped_heap.c
new file mode 100644
index ..7602b659c2ec
--- /dev/null
+++ b/drivers/staging/android/ion/ion_unmapped_heap.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ION Memory Allocator unmapped heap helper
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated -
http://www.ti.com/
+ * Andrew F. Davis
+ *
+ * ION "unmapped" heaps are physical memory heaps not by default
mapped into
+ * a virtual address space. The buffer owner can explicitly request
kernel
+ * space mappings but the underlying memory may still not be
accessible for
+ * various reasons, such as firewalls.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "ion.h"
+
+#define ION_UNMAPPED_ALLOCATE_FAIL -1
+
+struct ion_unmapped_heap {
+ struct ion_heap heap;
+ struct gen_pool *pool;
+};
+
+static phys_addr_t ion_unmapped_allocate(struct ion_heap *heap,
+ unsigned long size)
+{
+ struct ion_unmapped_heap *unmapped_heap =
+ container_of(heap, struct ion_unmapped_heap, heap);
+ unsigned long offset;
+
+ offset = gen_pool_alloc(unmapped_heap->pool, size);
+ if (!offset)
+ return ION_UNMAPPED_ALLOCATE_FAIL;
+
+ return offset;
+}
+
+static void ion_unmapped_free(struct ion_heap *heap, phys_addr_t addr,
+ unsigned long size)
+{
+ struct ion_unmapped_heap *unmapped_heap =
+ container_of(heap, struct ion_unmapped_heap, heap);
+
+ gen_pool_free(unmapped_heap->pool, addr, size);
+}
+
+static int ion_unmapped_heap_allocate(struct ion_heap *heap,
+ struct ion_buffer *buffer,
+ unsigned long size,
+
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/15/19 10:38 AM, Andrew F. Davis wrote:
On 1/15/19 11:45 AM, Liam Mark wrote:
On Tue, 15 Jan 2019, Andrew F. Davis wrote:
On 1/14/19 11:13 AM, Liam Mark wrote:
On Fri, 11 Jan 2019, Andrew F. Davis wrote:
Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses from the CPU to a cached heap should be bracketed with
{begin,end}_cpu_access calls so maintenance should not be needed anyway.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 14e48f6eb734..09cb5a8e2b09 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct
dma_buf_attachment *attachment,
table = a->table;
- if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
- direction))
+ if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
+ direction, DMA_ATTR_SKIP_CPU_SYNC))
Unfortunately I don't think you can do this for a couple reasons.
You can't rely on {begin,end}_cpu_access calls to do cache maintenance.
If the calls to {begin,end}_cpu_access were made before the call to
dma_buf_attach then there won't have been a device attached so the calls
to {begin,end}_cpu_access won't have done any cache maintenance.
That should be okay though, if you have no attachments (or all
attachments are IO-coherent) then there is no need for cache
maintenance. Unless you mean a sequence where a non-io-coherent device
is attached later after data has already been written. Does that
sequence need supporting?
Yes, but also I think there are cases where CPU access can happen before
in Android, but I will focus on later for now.
DMA-BUF doesn't have to allocate the backing
memory until map_dma_buf() time, and that should only happen after all
the devices have attached so it can know where to put the buffer. So we
shouldn't expect any CPU access to buffers before all the devices are
attached and mapped, right?
Here is an example where CPU access can happen later in Android.
Camera device records video -> software post processing -> video device
(who does compression of raw data) and writes to a file
In this example assume the buffer is cached and the devices are not
IO-coherent (quite common).
This is the start of the problem, having cached mappings of memory that
is also being accessed non-coherently is going to cause issues one way
or another. On top of the speculative cache fills that have to be
constantly fought back against with CMOs like below; some coherent
interconnects behave badly when you mix coherent and non-coherent access
(snoop filters get messed up).
The solution is to either always have the addresses marked non-coherent
(like device memory, no-map carveouts), or if you really want to use
regular system memory allocated at runtime, then all cached mappings of
it need to be dropped, even the kernel logical address (area as painful
as that would be).
I agree it's broken, hence my desire to remove it :)
The other problem is that uncached buffers are being used for
performance reason so anything that would involve getting
rid of the logical address would probably negate any performance
benefit.
ION buffer is allocated.
//Camera device records video
dma_buf_attach
dma_map_attachment (buffer needs to be cleaned)
Why does the buffer need to be cleaned here? I just got through reading
the thread linked by Laura in the other reply. I do like +Brian's
suggestion of tracking if the buffer has had CPU access since the last
time and only flushing the cache if it has. As unmapped heaps never get
CPU mapped this would never be the case for unmapped heaps, it solves my
problem.
[camera device writes to buffer]
dma_buf_unmap_attachment (buffer needs to be invalidated)
It doesn't know there will be any further CPU access, it could get freed
after this for all we know, the invalidate can be saved until the CPU
requests access again.
dma_buf_detach (device cannot stay attached because it is being sent down
the pipeline and Camera doesn't know the end of the use case)
This seems like a broken use-case, I understand the desire to keep
everything as modular as possible and separate the steps, but at this
point no one owns this buffers backing memory, not the CPU or any
device. I would go as far as to say DMA-BUF should be free now to
de-allocate the backing storage if it wants, that way it could get ready
for the next attachment, which may change the required backing memory
completely.
All devices should attach before the first mapping, and only let go
after the task is complete, otherwise this buffers data needs copied off
to a different location or the CPU needs to take ownership in-between.
Maybe it's broken but it's the status quo and we spent a good
am
[Bug 202217] Integrated laptop display doesnt come back up after using PRIME on wayland
https://bugzilla.kernel.org/show_bug.cgi?id=202217 Haxk20 (haxk...@gmail.com) changed: What|Removed |Added Severity|normal |high -- 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
Re: [PATCH 00/14] Misc ION cleanups and adding unmapped heap
On 1/15/19 9:47 AM, Andrew F. Davis wrote: On 1/14/19 8:39 PM, Laura Abbott wrote: On 1/11/19 10:05 AM, Andrew F. Davis wrote: Hello all, This is a set of (hopefully) non-controversial cleanups for the ION framework and current set of heaps. These were found as I start to familiarize myself with the framework to help in whatever way I can in getting all this up to the standards needed for de-staging. I would like to get some ideas of what is left to work on to get ION out of staging. Has there been some kind of agreement on what ION should eventually end up being? To me it looks like it is being whittled away at to it's most core functions. To me that is looking like being a DMA-BUF user-space front end, simply advertising available memory backings in a system and providing allocations as DMA-BUF handles. If this is the case then it looks close to being ready to me at least, but I would love to hear any other opinions and concerns. Yes, at this point the only functionality that people are really depending on is the ability to allocate a dma_buf easily from userspace. Back to this patchset, the last patch may be a bit different than the others, it adds an unmapped heaps type and creation helper. I wanted to get this in to show off another heap type and maybe some issues we may have with the current ION framework. The unmapped heap is used when the backing memory should not (or cannot) be touched. Currently this kind of heap is used for firewalled secure memory that can be allocated like normal heap memory but only used by secure devices (OP-TEE, crypto HW, etc). It is basically just copied from the "carveout" heap type with the only difference being it is not mappable to userspace and we do not clear the memory (as we should not map it either). So should this really be a new heap type? Or maybe advertised as a carveout heap but with an additional allocation flag? Perhaps we do away with "types" altogether and just have flags, coherent/non-coherent, mapped/unmapped, etc. Maybe more thinking will be needed afterall.. So the cleanup looks okay (I need to finish reviewing) but I'm not a fan of adding another heaptype without solving the problem of adding some sort of devicetree binding or other method of allocating and placing Ion heaps. That plus uncached buffers are one of the big open problems that need to be solved for destaging Ion. See https://lore.kernel.org/lkml/20181120164636.jcw7li2uaa3cmwc3@DESKTOP-E1NTVVP.localdomain/ for some background on that problem. I'm under the impression that adding heaps like carveouts/chunk will be rather system specific and so do not lend themselves well to a universal DT style exporter. For instance a carveout memory space can be reported by a device at runtime, then the driver managing that device should go and use the carveout heap helpers to export that heap. If this is the case then I'm not sure it is a problem for the ION core framework to solve, but rather the users of it to figure out how best to create the various heaps. All Ion needs to do is allow exporting and advertising them IMHO. I think it is a problem for the Ion core framework to take care of. Ion is useless if you don't actually have the heaps. Nobody has actually gotten a full Ion solution end-to-end with a carveout heap working in mainline because any proposals have been rejected. I think we need at least one example in mainline of how creating a carveout heap would work. Thanks for the background thread link, I've been looking for some info on current status of all this and "ion" is a bit hard to search the lists for. The core reason for posting this cleanup series is to throw my hat into the ring of all this Ion work and start getting familiar with the pending issues. The last two patches are not all that important to get in right now. In that thread you linked above, it seems we may have arrived at a similar problem for different reasons. I think the root issue is the Ion core makes too many assumptions about the heap memory. My proposal would be to allow the heap exporters more control over the DMA-BUF ops, maybe even going as far as letting them provide their own complete struct dma_buf_ops. Let me give an example where I think this is going to be useful. We have the classic constraint solving problem on our SoCs. Our SoCs are full of various coherent and non-coherent devices, some require contiguous memory allocations, others have in-line IOMMUs so can operate on non-contiguous, etc.. DMA-BUF has a solution designed in for this we can use, namely allocation at map time after all the attachments have come in. The checking of each attached device to find the right backing memory is something the DMA-BUF exporter has to do, and so this SoC specific logic would have to be added to each exporting framework (DRM, V4L2, etc), unless we have one unified system exporter everyone uses, Ion. That's how dmabuf is supposed to work in theory but in practice we also have the case
Re: [PATCH 14/14] staging: android: ion: Add UNMAPPED heap type and helper
On 1/15/19 7:58 AM, Andrew F. Davis wrote:
On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, in
my specific case due to firewalls. This memory can still be
allocated from and used by devices that do have access to the
backing memory.
Based originally on the secure/unmapped heap from Linaro for
the OP-TEE SDP implementation, this was re-written to match
the carveout heap helper code.
Suggested-by: Etienne Carriere
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/Kconfig | 10 ++
drivers/staging/android/ion/Makefile | 1 +
drivers/staging/android/ion/ion.h | 16 +++
.../staging/android/ion/ion_unmapped_heap.c | 123 ++
drivers/staging/android/uapi/ion.h | 3 +
5 files changed, 153 insertions(+)
create mode 100644 drivers/staging/android/ion/ion_unmapped_heap.c
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index 0fdda6f62953..a117b8b91b14 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -42,3 +42,13 @@ config ION_CMA_HEAP
Choose this option to enable CMA heaps with Ion. This heap is
backed
by the Contiguous Memory Allocator (CMA). If your system has
these
regions, you should say Y here.
+
+config ION_UNMAPPED_HEAP
+ bool "ION unmapped heap support"
+ depends on ION
+ help
+ Choose this option to enable UNMAPPED heaps with Ion. This heap is
+ backed in specific memory pools, carveout from the Linux memory.
+ Unlike carveout heaps these are assumed to be not mappable by
+ kernel or user-space.
+ Unless you know your system has these regions, you should say N
here.
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index 17f3a7569e3d..c71a1f3de581 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o
ion_page_pool.o
obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
+obj-$(CONFIG_ION_UNMAPPED_HEAP) += ion_unmapped_heap.o
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index 97b2876b165a..ce74332018ba 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -341,4 +341,20 @@ static inline struct ion_heap
*ion_chunk_heap_create(phys_addr_t base, size_t si
}
#endif
+#ifdef CONFIG_ION_UNMAPPED_HEAP
+/**
+ * ion_unmapped_heap_create
+ * @base: base address of carveout memory
+ * @size: size of carveout memory region
+ *
+ * Creates an unmapped ion_heap using the passed in data
+ */
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t
size);
+#else
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t size)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
#endif /* _ION_H */
diff --git a/drivers/staging/android/ion/ion_unmapped_heap.c
b/drivers/staging/android/ion/ion_unmapped_heap.c
new file mode 100644
index ..7602b659c2ec
--- /dev/null
+++ b/drivers/staging/android/ion/ion_unmapped_heap.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ION Memory Allocator unmapped heap helper
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated -
http://www.ti.com/
+ * Andrew F. Davis
+ *
+ * ION "unmapped" heaps are physical memory heaps not by default
mapped into
+ * a virtual address space. The buffer owner can explicitly request
kernel
+ * space mappings but the underlying memory may still not be
accessible for
+ * various reasons, such as firewalls.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "ion.h"
+
+#define ION_UNMAPPED_ALLOCATE_FAIL -1
+
+struct ion_unmapped_heap {
+ struct ion_heap heap;
+ struct gen_pool *pool;
+};
+
+static phys_addr_t ion_unmapped_allocate(struct ion_heap *heap,
+ unsigned long size)
+{
+ struct ion_unmapped_heap *unmapped_heap =
+ container_of(heap, struct ion_unmapped_heap, heap);
+ unsigned long offset;
+
+ offset = gen_pool_alloc(unmapped_heap->pool, size);
+ if (!offset)
+ return ION_UNMAPPED_ALLOCATE_FAIL;
+
+ return offset;
+}
+
+static void ion_unmapped_free(struct ion_heap *heap, phys_addr_t addr,
+ unsigned long size)
+{
+ struct ion_unmapped_heap *unmapped_heap =
+ container_of(heap, struct ion_unmapped_heap, heap);
+
+ gen_pool_free(unmapped_heap->pool, addr, size);
+}
+
+static int ion_unmapped_heap_allocate(struct ion_heap *heap,
+ struct ion_buffer *buffer,
+ unsigned long size,
+ unsigned long flags)
+{
+ struc
Re: [PATCH] drm: Fix drm.h uapi header for GNU/kFreeBSD
Daniel Vetter writes: > On Tue, Jan 15, 2019 at 03:04:18PM +, James Clarke wrote: >> Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t >> types, which differs from the BSDs' headers. Thus we should include >> stdint.h to ensure we have all the required integer types. >> >> Signed-off-by: James Clarke > > Would be good to get an ack from some other *bsd that this is still all > fine. lgtm otherwise. > -Daniel I think there was some need for inttypes.h instead of stdint like a decade ago when I was working on BSDs, but that was already almost irrelevant then. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/15/19 12:38 PM, Andrew F. Davis wrote:
> On 1/15/19 11:45 AM, Liam Mark wrote:
>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>>
>>> On 1/14/19 11:13 AM, Liam Mark wrote:
On Fri, 11 Jan 2019, Andrew F. Davis wrote:
> Buffers may not be mapped from the CPU so skip cache maintenance here.
> Accesses from the CPU to a cached heap should be bracketed with
> {begin,end}_cpu_access calls so maintenance should not be needed anyway.
>
> Signed-off-by: Andrew F. Davis
> ---
> drivers/staging/android/ion/ion.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c
> index 14e48f6eb734..09cb5a8e2b09 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct
> dma_buf_attachment *attachment,
>
> table = a->table;
>
> - if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
> - direction))
> + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
> + direction, DMA_ATTR_SKIP_CPU_SYNC))
Unfortunately I don't think you can do this for a couple reasons.
You can't rely on {begin,end}_cpu_access calls to do cache maintenance.
If the calls to {begin,end}_cpu_access were made before the call to
dma_buf_attach then there won't have been a device attached so the calls
to {begin,end}_cpu_access won't have done any cache maintenance.
>>>
>>> That should be okay though, if you have no attachments (or all
>>> attachments are IO-coherent) then there is no need for cache
>>> maintenance. Unless you mean a sequence where a non-io-coherent device
>>> is attached later after data has already been written. Does that
>>> sequence need supporting?
>>
>> Yes, but also I think there are cases where CPU access can happen before
>> in Android, but I will focus on later for now.
>>
>>> DMA-BUF doesn't have to allocate the backing
>>> memory until map_dma_buf() time, and that should only happen after all
>>> the devices have attached so it can know where to put the buffer. So we
>>> shouldn't expect any CPU access to buffers before all the devices are
>>> attached and mapped, right?
>>>
>>
>> Here is an example where CPU access can happen later in Android.
>>
>> Camera device records video -> software post processing -> video device
>> (who does compression of raw data) and writes to a file
>>
>> In this example assume the buffer is cached and the devices are not
>> IO-coherent (quite common).
>>
>
> This is the start of the problem, having cached mappings of memory that
> is also being accessed non-coherently is going to cause issues one way
> or another. On top of the speculative cache fills that have to be
> constantly fought back against with CMOs like below; some coherent
> interconnects behave badly when you mix coherent and non-coherent access
> (snoop filters get messed up).
>
> The solution is to either always have the addresses marked non-coherent
> (like device memory, no-map carveouts), or if you really want to use
> regular system memory allocated at runtime, then all cached mappings of
> it need to be dropped, even the kernel logical address (area as painful
> as that would be).
>
>> ION buffer is allocated.
>>
>> //Camera device records video
>> dma_buf_attach
>> dma_map_attachment (buffer needs to be cleaned)
>
> Why does the buffer need to be cleaned here? I just got through reading
> the thread linked by Laura in the other reply. I do like +Brian's
Actually +Brian this time :)
> suggestion of tracking if the buffer has had CPU access since the last
> time and only flushing the cache if it has. As unmapped heaps never get
> CPU mapped this would never be the case for unmapped heaps, it solves my
> problem.
>
>> [camera device writes to buffer]
>> dma_buf_unmap_attachment (buffer needs to be invalidated)
>
> It doesn't know there will be any further CPU access, it could get freed
> after this for all we know, the invalidate can be saved until the CPU
> requests access again.
>
>> dma_buf_detach (device cannot stay attached because it is being sent down
>> the pipeline and Camera doesn't know the end of the use case)
>>
>
> This seems like a broken use-case, I understand the desire to keep
> everything as modular as possible and separate the steps, but at this
> point no one owns this buffers backing memory, not the CPU or any
> device. I would go as far as to say DMA-BUF should be free now to
> de-allocate the backing storage if it wants, that way it could get ready
> for the next attachment, which may change the required backing memory
> completely.
>
> All devices should attach before the first mapping, and only let go
> after the task is complete, otherwise this buffers data needs copied off
> to a different loca
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/15/19 11:45 AM, Liam Mark wrote:
> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/14/19 11:13 AM, Liam Mark wrote:
>>> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>>>
Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses from the CPU to a cached heap should be bracketed with
{begin,end}_cpu_access calls so maintenance should not be needed anyway.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 14e48f6eb734..09cb5a8e2b09 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct
dma_buf_attachment *attachment,
table = a->table;
- if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
- direction))
+ if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
+direction, DMA_ATTR_SKIP_CPU_SYNC))
>>>
>>> Unfortunately I don't think you can do this for a couple reasons.
>>> You can't rely on {begin,end}_cpu_access calls to do cache maintenance.
>>> If the calls to {begin,end}_cpu_access were made before the call to
>>> dma_buf_attach then there won't have been a device attached so the calls
>>> to {begin,end}_cpu_access won't have done any cache maintenance.
>>>
>>
>> That should be okay though, if you have no attachments (or all
>> attachments are IO-coherent) then there is no need for cache
>> maintenance. Unless you mean a sequence where a non-io-coherent device
>> is attached later after data has already been written. Does that
>> sequence need supporting?
>
> Yes, but also I think there are cases where CPU access can happen before
> in Android, but I will focus on later for now.
>
>> DMA-BUF doesn't have to allocate the backing
>> memory until map_dma_buf() time, and that should only happen after all
>> the devices have attached so it can know where to put the buffer. So we
>> shouldn't expect any CPU access to buffers before all the devices are
>> attached and mapped, right?
>>
>
> Here is an example where CPU access can happen later in Android.
>
> Camera device records video -> software post processing -> video device
> (who does compression of raw data) and writes to a file
>
> In this example assume the buffer is cached and the devices are not
> IO-coherent (quite common).
>
This is the start of the problem, having cached mappings of memory that
is also being accessed non-coherently is going to cause issues one way
or another. On top of the speculative cache fills that have to be
constantly fought back against with CMOs like below; some coherent
interconnects behave badly when you mix coherent and non-coherent access
(snoop filters get messed up).
The solution is to either always have the addresses marked non-coherent
(like device memory, no-map carveouts), or if you really want to use
regular system memory allocated at runtime, then all cached mappings of
it need to be dropped, even the kernel logical address (area as painful
as that would be).
> ION buffer is allocated.
>
> //Camera device records video
> dma_buf_attach
> dma_map_attachment (buffer needs to be cleaned)
Why does the buffer need to be cleaned here? I just got through reading
the thread linked by Laura in the other reply. I do like +Brian's
suggestion of tracking if the buffer has had CPU access since the last
time and only flushing the cache if it has. As unmapped heaps never get
CPU mapped this would never be the case for unmapped heaps, it solves my
problem.
> [camera device writes to buffer]
> dma_buf_unmap_attachment (buffer needs to be invalidated)
It doesn't know there will be any further CPU access, it could get freed
after this for all we know, the invalidate can be saved until the CPU
requests access again.
> dma_buf_detach (device cannot stay attached because it is being sent down
> the pipeline and Camera doesn't know the end of the use case)
>
This seems like a broken use-case, I understand the desire to keep
everything as modular as possible and separate the steps, but at this
point no one owns this buffers backing memory, not the CPU or any
device. I would go as far as to say DMA-BUF should be free now to
de-allocate the backing storage if it wants, that way it could get ready
for the next attachment, which may change the required backing memory
completely.
All devices should attach before the first mapping, and only let go
after the task is complete, otherwise this buffers data needs copied off
to a different location or the CPU needs to take ownership in-between.
> //buffer is send down the pipeline
>
> // Usersapce software post processing occurs
> mmap buffer
Perhaps the invalidate should happen here in mmap.
> DM
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
On Tue, Jan 15, 2019 at 06:03:39PM +, Thomas Hellstrom wrote: > In the graphics case, it's probably because it doesn't fit the graphics > use-cases: > > 1) Memory typically needs to be mappable by another device. (the "dma- > buf" interface) And there is nothing preventing dma-buf sharing of these buffers. Unlike the get_sgtable mess it can actually work reliably on architectures that have virtually tagged caches and/or don't guarantee cache coherency with mixed attribute mappings. > 2) DMA buffers are exported to user-space and is sub-allocated by it. > Mostly there are no GPU user-space kernel interfaces to sync / flush > subregions and these syncs may happen on a smaller-than-cache-line > granularity. I know of no architectures that can do cache maintainance on a less than cache line basis. Either the instructions require you to specifcy cache lines, or they do sometimes more, sometimes less intelligent rounding up. Note that as long dma non-coherent buffers are devices owned it is up to the device and the user space driver to take care of coherency, the kernel very much is out of the picture. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #99 from tempel.jul...@gmail.com --- Does the trick for me too, TearFree with amdgpu.dc=0 seems to be completely smooth now. Delay / input latency seems to be the same between amdgpu.dc=1 and 0, I suppose this is as low as it can be with traditional vsync (without variable vblank). -- 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] lib/scatterlist: Provide a DMA page iterator
On Tue, 2019-01-15 at 16:20 +0100, h...@lst.de wrote: > On Tue, Jan 15, 2019 at 03:24:55PM +0100, Christian König wrote: > > Yeah, indeed. Bounce buffers are an absolute no-go for GPUs. > > > > If the DMA API finds that a piece of memory is not directly > > accessible by > > the GPU we need to return an error and not try to use bounce > > buffers behind > > the surface. > > > > That is something which always annoyed me with the DMA API, which > > is > > otherwise rather cleanly defined. > > That is exactly what I want to fix with my series to make > DMA_ATTR_NON_CONSISTENT more useful and always available: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fpipermail%2Fiommu%2F2018-December%2F031985.html&data=02%7C01%7Cthellstrom%40vmware.com%7Cb1799c4073024a824f9408d67afcfcea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636831624340834140&sdata=JiRBfzZMvN3joJ4vKiErbzXAHaNzuBcLapRJDL%2Bt6Hc%3D&reserved=0 > > With that you allocate the memory using dma_alloc_attrs with > DMA_ATTR_NON_CONSISTENT, and use dma_sync_single_* to transfer > ownership to the cpu and back to the device, with a gurantee that > there won't be any bouncing. So far the interest by the parties that > requested the feature has been rather lacklustre, though. In the graphics case, it's probably because it doesn't fit the graphics use-cases: 1) Memory typically needs to be mappable by another device. (the "dma- buf" interface) 2) DMA buffers are exported to user-space and is sub-allocated by it. Mostly there are no GPU user-space kernel interfaces to sync / flush subregions and these syncs may happen on a smaller-than-cache-line granularity. So to help the graphics driver, that coherent flag would be much more useful. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #98 from Michel Dänzer --- (In reply to Brandon Wright from comment #95) > For me, at least, it hiccups regularly every second and introduces > noticeable latency. With dc=1 it's smooth Thanks, I was able to reproduce the hiccups with vsynctester.com in windowed Firefox. > and more responsive. Couldn't see a difference there (looking at how much the red dot trails the mouse cursor on vsynctester.com). Ironically, the problem is actually that non-DC can be too responsive, sometimes completing page flips in the same vertical blank period. https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/23 fixes it 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
Re: [PATCH 00/14] Misc ION cleanups and adding unmapped heap
On 1/14/19 8:39 PM, Laura Abbott wrote: > On 1/11/19 10:05 AM, Andrew F. Davis wrote: >> Hello all, >> >> This is a set of (hopefully) non-controversial cleanups for the ION >> framework and current set of heaps. These were found as I start to >> familiarize myself with the framework to help in whatever way I >> can in getting all this up to the standards needed for de-staging. >> >> I would like to get some ideas of what is left to work on to get ION >> out of staging. Has there been some kind of agreement on what ION should >> eventually end up being? To me it looks like it is being whittled away at >> to it's most core functions. To me that is looking like being a DMA-BUF >> user-space front end, simply advertising available memory backings in a >> system and providing allocations as DMA-BUF handles. If this is the case >> then it looks close to being ready to me at least, but I would love to >> hear any other opinions and concerns. >> > > Yes, at this point the only functionality that people are really > depending on is the ability to allocate a dma_buf easily from userspace. > >> Back to this patchset, the last patch may be a bit different than the >> others, it adds an unmapped heaps type and creation helper. I wanted to >> get this in to show off another heap type and maybe some issues we may >> have with the current ION framework. The unmapped heap is used when the >> backing memory should not (or cannot) be touched. Currently this kind >> of heap is used for firewalled secure memory that can be allocated like >> normal heap memory but only used by secure devices (OP-TEE, crypto HW, >> etc). It is basically just copied from the "carveout" heap type with the >> only difference being it is not mappable to userspace and we do not clear >> the memory (as we should not map it either). So should this really be a >> new heap type? Or maybe advertised as a carveout heap but with an >> additional allocation flag? Perhaps we do away with "types" altogether >> and just have flags, coherent/non-coherent, mapped/unmapped, etc. >> >> Maybe more thinking will be needed afterall.. >> > > So the cleanup looks okay (I need to finish reviewing) but I'm not a > fan of adding another heaptype without solving the problem of adding > some sort of devicetree binding or other method of allocating and > placing Ion heaps. That plus uncached buffers are one of the big > open problems that need to be solved for destaging Ion. See > https://lore.kernel.org/lkml/20181120164636.jcw7li2uaa3cmwc3@DESKTOP-E1NTVVP.localdomain/ > > for some background on that problem. > I'm under the impression that adding heaps like carveouts/chunk will be rather system specific and so do not lend themselves well to a universal DT style exporter. For instance a carveout memory space can be reported by a device at runtime, then the driver managing that device should go and use the carveout heap helpers to export that heap. If this is the case then I'm not sure it is a problem for the ION core framework to solve, but rather the users of it to figure out how best to create the various heaps. All Ion needs to do is allow exporting and advertising them IMHO. Thanks for the background thread link, I've been looking for some info on current status of all this and "ion" is a bit hard to search the lists for. The core reason for posting this cleanup series is to throw my hat into the ring of all this Ion work and start getting familiar with the pending issues. The last two patches are not all that important to get in right now. In that thread you linked above, it seems we may have arrived at a similar problem for different reasons. I think the root issue is the Ion core makes too many assumptions about the heap memory. My proposal would be to allow the heap exporters more control over the DMA-BUF ops, maybe even going as far as letting them provide their own complete struct dma_buf_ops. Let me give an example where I think this is going to be useful. We have the classic constraint solving problem on our SoCs. Our SoCs are full of various coherent and non-coherent devices, some require contiguous memory allocations, others have in-line IOMMUs so can operate on non-contiguous, etc.. DMA-BUF has a solution designed in for this we can use, namely allocation at map time after all the attachments have come in. The checking of each attached device to find the right backing memory is something the DMA-BUF exporter has to do, and so this SoC specific logic would have to be added to each exporting framework (DRM, V4L2, etc), unless we have one unified system exporter everyone uses, Ion. Then each system can define one (maybe typeless) heap, the correct backing type is system specific anyway, so let the system specific backing logic in the unified system exporter heap handle picking that. To allow that heaps need direct control of dma_buf_ops. Direct heap control of dma_buf_ops also fixes the cache/non-cache issue, and my unmapped memory issue, each heap ty
[Bug 109366] NULL pointer at pcie_capability_read_dword with Radeon SI vfio passthrough
https://bugs.freedesktop.org/show_bug.cgi?id=109366 --- Comment #2 from Alex Deucher --- Created attachment 143133 --> https://bugs.freedesktop.org/attachment.cgi?id=143133&action=edit possible fix Does this patch fix it? dGPUs are always add in cards, so they always plug into an upstream port on bare metal. The driver needs to query the upstream port to determine what pcie gen speeds and lanes are available on the platform so that the driver can properly adjust them at runtime to save power. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/5] drm/tinydrm: Use damage helper for dirtyfb
On 1/14/19 10:36 PM, Noralf Trønnes wrote: This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty handler. All flushing will now happen in the pipe functions. Also enable the damage plane property for all except repaper which can only do full updates. ili9225: This change made ili9225_init() equal to mipi_dbi_init() so use it. v3: Include vblank header (Sam) ili9225 and st7586 can't use mipi_dbi_enable_flush() (David) v2: Remove fb check in mipi_dbi_enable_flush() it can't be NULL (kbuild test robot) Cc: David Lechner Cc: Eric Anholt Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter Reviewed-by: Sam Ravnborg --- Tested-by: David Lechner Reviewed-by: David Lechner Tested st7586 on LEGO MINDSTORMS EV3 and ili9225 on BeagleBone Green (requires "spi: omap2-mcspi: Fix DMA and FIFO event trigger size mismatch" to work correctly because of recent bug). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202263] AMDGPU: DRM couldn't schedule ib on ring (-22)
https://bugzilla.kernel.org/show_bug.cgi?id=202263 --- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) --- Created attachment 280505 --> https://bugzilla.kernel.org/attachment.cgi?id=280505&action=edit possible fix Does this patch fix the issue? -- 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
[Bug 109366] NULL pointer at pcie_capability_read_dword with Radeon SI vfio passthrough
https://bugs.freedesktop.org/show_bug.cgi?id=109366 Alex Deucher changed: What|Removed |Added Component|DRM/AMDgpu |DRM/Radeon -- 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 109366] NULL pointer at pcie_capability_read_dword with Radeon SI vfio passthrough
https://bugs.freedesktop.org/show_bug.cgi?id=109366 --- Comment #1 from Alex Williamson --- Use a Q35 VM configuration with the assigned GPU downstream of an emulated PCIe root port as a workaround. The driver assumes this configuration, presumably it's the only one that exists on bare metal, and reads from the upstream device without checking that it is actually present. -- 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 14/14] staging: android: ion: Add UNMAPPED heap type and helper
On 1/14/19 8:32 PM, Laura Abbott wrote:
> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>> The "unmapped" heap is very similar to the carveout heap except
>> the backing memory is presumed to be unmappable by the host, in
>> my specific case due to firewalls. This memory can still be
>> allocated from and used by devices that do have access to the
>> backing memory.
>>
>> Based originally on the secure/unmapped heap from Linaro for
>> the OP-TEE SDP implementation, this was re-written to match
>> the carveout heap helper code.
>>
>> Suggested-by: Etienne Carriere
>> Signed-off-by: Andrew F. Davis
>> ---
>> drivers/staging/android/ion/Kconfig | 10 ++
>> drivers/staging/android/ion/Makefile | 1 +
>> drivers/staging/android/ion/ion.h | 16 +++
>> .../staging/android/ion/ion_unmapped_heap.c | 123 ++
>> drivers/staging/android/uapi/ion.h | 3 +
>> 5 files changed, 153 insertions(+)
>> create mode 100644 drivers/staging/android/ion/ion_unmapped_heap.c
>>
>> diff --git a/drivers/staging/android/ion/Kconfig
>> b/drivers/staging/android/ion/Kconfig
>> index 0fdda6f62953..a117b8b91b14 100644
>> --- a/drivers/staging/android/ion/Kconfig
>> +++ b/drivers/staging/android/ion/Kconfig
>> @@ -42,3 +42,13 @@ config ION_CMA_HEAP
>> Choose this option to enable CMA heaps with Ion. This heap is
>> backed
>> by the Contiguous Memory Allocator (CMA). If your system has
>> these
>> regions, you should say Y here.
>> +
>> +config ION_UNMAPPED_HEAP
>> + bool "ION unmapped heap support"
>> + depends on ION
>> + help
>> + Choose this option to enable UNMAPPED heaps with Ion. This heap is
>> + backed in specific memory pools, carveout from the Linux memory.
>> + Unlike carveout heaps these are assumed to be not mappable by
>> + kernel or user-space.
>> + Unless you know your system has these regions, you should say N
>> here.
>> diff --git a/drivers/staging/android/ion/Makefile
>> b/drivers/staging/android/ion/Makefile
>> index 17f3a7569e3d..c71a1f3de581 100644
>> --- a/drivers/staging/android/ion/Makefile
>> +++ b/drivers/staging/android/ion/Makefile
>> @@ -4,3 +4,4 @@ obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o
>> ion_page_pool.o
>> obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
>> obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
>> obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
>> +obj-$(CONFIG_ION_UNMAPPED_HEAP) += ion_unmapped_heap.o
>> diff --git a/drivers/staging/android/ion/ion.h
>> b/drivers/staging/android/ion/ion.h
>> index 97b2876b165a..ce74332018ba 100644
>> --- a/drivers/staging/android/ion/ion.h
>> +++ b/drivers/staging/android/ion/ion.h
>> @@ -341,4 +341,20 @@ static inline struct ion_heap
>> *ion_chunk_heap_create(phys_addr_t base, size_t si
>> }
>> #endif
>> +#ifdef CONFIG_ION_UNMAPPED_HEAP
>> +/**
>> + * ion_unmapped_heap_create
>> + * @base: base address of carveout memory
>> + * @size: size of carveout memory region
>> + *
>> + * Creates an unmapped ion_heap using the passed in data
>> + */
>> +struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t
>> size);
>> +#else
>> +struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t size)
>> +{
>> + return ERR_PTR(-ENODEV);
>> +}
>> +#endif
>> +
>> #endif /* _ION_H */
>> diff --git a/drivers/staging/android/ion/ion_unmapped_heap.c
>> b/drivers/staging/android/ion/ion_unmapped_heap.c
>> new file mode 100644
>> index ..7602b659c2ec
>> --- /dev/null
>> +++ b/drivers/staging/android/ion/ion_unmapped_heap.c
>> @@ -0,0 +1,123 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * ION Memory Allocator unmapped heap helper
>> + *
>> + * Copyright (C) 2015-2016 Texas Instruments Incorporated -
>> http://www.ti.com/
>> + * Andrew F. Davis
>> + *
>> + * ION "unmapped" heaps are physical memory heaps not by default
>> mapped into
>> + * a virtual address space. The buffer owner can explicitly request
>> kernel
>> + * space mappings but the underlying memory may still not be
>> accessible for
>> + * various reasons, such as firewalls.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "ion.h"
>> +
>> +#define ION_UNMAPPED_ALLOCATE_FAIL -1
>> +
>> +struct ion_unmapped_heap {
>> + struct ion_heap heap;
>> + struct gen_pool *pool;
>> +};
>> +
>> +static phys_addr_t ion_unmapped_allocate(struct ion_heap *heap,
>> + unsigned long size)
>> +{
>> + struct ion_unmapped_heap *unmapped_heap =
>> + container_of(heap, struct ion_unmapped_heap, heap);
>> + unsigned long offset;
>> +
>> + offset = gen_pool_alloc(unmapped_heap->pool, size);
>> + if (!offset)
>> + return ION_UNMAPPED_ALLOCATE_FAIL;
>> +
>> + return offset;
>> +}
>> +
>> +static void ion_unmapped_free(struct ion_heap *heap, phys_addr_t addr,
>> + unsigned long size)
>> +{
>> + struct ion_unmapped_heap *unm
Re: HDMI/DVI spurious failure
Hi, (Sending those kind of bug reports to linux-sunxi doesn't really work, you should Cc at least the ML involved in the development of the driver at fault). On Mon, Jan 14, 2019 at 01:29:34PM +, Priit Laes wrote: > I have a somewhat curious case with one HDMI/DVI screen that fails > to initialize properly every 6-7 boots. The display itself is also > somewhat flawed (missing HPD pin and the VSYNC/HSYNC pulse width > is set to 0 in EDID), but I suspect there could be some issues > regarding timing in A20 HDMI driver in Linux. > > HW: Olinuxino Lime2 eMMC > > The same display works out of the box on Raspberry Pi. And I > haven't seen it failing in u-boot on A20 Lime2 hw. > > I have disabled HDMI support in U-boot (there's another issue > with simplefb handover to modesetting, but I currently try to > leave u-boot out of the equation), so kernel itselfs sets up > the display. > Basically the only differences I have found are some timing > differences in DRM logs and following discrepancey in clock > tree when comparing failing and working boots: > > --- clks-failing.dump 2019-01-14 14:45:24.026279493 +0200 > +++ clks-ok.dump 2019-01-14 14:29:59.799715126 +0200 > @@ -6,7 +6,7 @@ > mii_phy_tx 0002500 0 0 > 5 > osc32k 000 32768 0 0 > 5 > osc24M 2212400 0 0 > 5 > -hosc 5512400 0 0 > 5 > +hosc 6612400 0 0 > 5 > out-b 000 32000 0 0 > 5 > out-a 000 32000 0 0 > 5 > hdmi1-slow 0002400 0 0 > 5 > @@ -52,10 +52,10 @@ >apb1-i2c1 1102400 0 0 > 5 >apb1-i2c0 1102400 0 0 > 5 > pll-gpu000 12 0 0 > 5 > - pll-video1 000 32700 0 0 > 5 > - pll-video1-2x 000 65400 0 0 > 5 > - hdmi-tmds00025153846 0 0 > 5 > -hdmi-ddc 000 89835 0 0 > 5 > + pll-video1 110 32700 0 0 > 5 > + pll-video1-2x 110 65400 0 0 > 5 > + hdmi-tmds11025153846 0 0 > 5 > +hdmi-ddc 110 89835 0 0 > 5 > pll-periph-base330 12 0 0 > 5 >mbus110 3 0 0 > 5 >pll-periph-sata 110 1 0 0 > 5 > > > Any hints what else to debug? It doesn't look related to the clock rate itself, since it doesn't change between the two cases. However, in one case the DDC clock is enabled and in the other it's disabled. Was it taken at the same time? Maybe you can try with that patch? http://code.bulix.org/z7jmkm-555344?raw Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Daniel, Dave,
Here is the drm-misc-next PR for this week.
Thanks!
Maxime
drm-misc-next-2019-01-15:
drm-misc-next for 5.1:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- Reorganisation of drm_device and drm_framebuffer headers
- Cleanup of the drmP inclusion
- Fix leaks in the fb-helpers
- Allow for depth different from bpp in fb-helper fbdev emulation
Driver Changes:
- Add reflection properties to rockchip
- a bunch of fixes for virtio
- a bunch of fixes for dp_mst and drivers using it, and introduction of a
new refcounting scheme
- Convertion of bochs to atomic and generic fbdev emulation
- Allow meson to remove the firmware framebuffers
The following changes since commit e3d093070eb0b5e3df668d3eb04100ea79343c65:
Merge tag 'tilcdc-4.22' of https://github.com/jsarha/linux into drm-next
(2019-01-11 06:29:31 +1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-01-15
for you to fetch changes up to ed20151a7699bb2c77eba3610199789a126940c4:
drm/vblank: Allow dynamic per-crtc max_vblank_count (2019-01-14 21:23:55
+0200)
drm-misc-next for 5.1:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- Reorganisation of drm_device and drm_framebuffer headers
- Cleanup of the drmP inclusion
- Fix leaks in the fb-helpers
- Allow for depth different from bpp in fb-helper fbdev emulation
Driver Changes:
- Add reflection properties to rockchip
- a bunch of fixes for virtio
- a bunch of fixes for dp_mst and drivers using it, and introduction of a
new refcounting scheme
- Convertion of bochs to atomic and generic fbdev emulation
- Allow meson to remove the firmware framebuffers
Daniel Vetter (14):
drm/todo: Better defio support in the generic fbdev emulation
drm/crtc-helpers: WARN when used with atomic drivers
drm/ch7006: Stop using drm_crtc_force_disable
drm/nouveau: Stop using drm_crtc_force_disable
drm: Unexport drm_crtc_force_disable
drm/atomic: Add missing () to function ref in kerneldoc
drm: Move the legacy kms disable_all helper to crtc helpers
drm/arc: Don't set the dpms hook
drm/tda998x: Don't set dpms hook
drm/doc: Polish kerneldoc for drm_device.h
drm/docs: improve docs for drm_drv.c
drm/of: Fix kerneldoc
drm/panel: Small documentation polish
drm/doc: Move bridge link target to the right place
Daniele Castagna (2):
drm/rockchip: Fix YUV buffers color rendering
drm/rockchip: Add reflection properties
Enric Balletbo i Serra (1):
drm/rockchip: update cursors asynchronously through atomic.
Ezequiel Garcia (5):
drm/virtio: Remove incorrect kfree()
drm/virtio: Add missing virtqueue reset
drm/virtio: Drop deprecated load/unload initialization
drm/rockchip: Fix typo in VOP macros argument
drm/rockchip: Separate RK3288 from RK3368 win01 registers
Gerd Hoffmann (19):
drm/virtio: log error responses
drm/virtio: fix pageflip flush
drm/virtio: drop virtio_gpu_fence_cleanup()
drm/bochs: encoder cleanup
drm/bochs: split bochs_hw_setmode
drm/bochs: atomic: add atomic_flush+atomic_enable callbacks.
drm/bochs: atomic: add mode_set_nofb callback.
drm/bochs: atomic: switch planes to atomic, wire up helpers.
drm/bochs: atomic: use atomic set_config helper
drm/bochs: atomic: use atomic page_flip helper
drm/bochs: atomic: use suspend/resume helpers
drm/bochs: atomic: set DRIVER_ATOMIC
drm/bochs: remove old bochs_crtc_* functions
drm/bochs: drop unused gpu_addr arg from bochs_bo_pin()
drm/bochs: move ttm_bo_(un)reserve calls into bochs_bo_{pin, unpin}
drm/bochs: add basic prime support
drm/bochs: switch to generic drm fbdev emulation
drm/bochs: drop old fbdev emulation code
drm/bochs: move remaining fb bits to kms
Gustavo A. R. Silva (1):
qxl: Use struct_size() in kzalloc()
Kuo-Hsin Yang (1):
drm/gem: Mark pinned pages as unevictable
Linus Walleij (2):
drm/fb-helper: Scale back depth to supported maximum
drm/panel: Add a driver for the TPO TPG110
Lyude Paul (20):
drm/dp_mst: Fix some formatting in drm_dp_add_port()
drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg()
drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi()
drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi()
drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends
drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails
drm/dp_mst: Stop releasing VCPI when removing ports from topology
drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
drm/i915: Keep malloc re
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #42 from Jerry Zuo --- We are currently looking at the startup issue now. -- 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 109366] NULL pointer at pcie_capability_read_dword with Radeon SI vfio passthrough
https://bugs.freedesktop.org/show_bug.cgi?id=109366 Bug ID: 109366 Summary: NULL pointer at pcie_capability_read_dword with Radeon SI vfio passthrough Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: ryandb...@gmail.com Created attachment 143131 --> https://bugs.freedesktop.org/attachment.cgi?id=143131&action=edit dmesg output My guest is seeing the attached bug and call trace during boot. Kernel 4.20.2-200, also an issue on 4.19 series. 4.18 is similar with the older drm_ prefixed version of the function. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] staging/vboxvideo: Don't set FBINFO_MISC_ALWAYS_SETPAR
On Tue, Jan 15, 2019 at 04:15:49PM +0100, Daniel Vetter wrote: > On Tue, Jan 15, 2019 at 02:45:53PM +0100, Greg Kroah-Hartman wrote: > > On Tue, Jan 15, 2019 at 01:12:28PM +0100, Daniel Vetter wrote: > > > On Tue, Jan 15, 2019 at 11:38:29AM +0100, Greg Kroah-Hartman wrote: > > > > On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote: > > > > > It's a debug hack flag useful to work around driver bugs. That's not a > > > > > good idea for a new driver. Especially for a new drm driver. > > > > > > > > > > Aside: the fbdev support should probably be converted over to the new > > > > > generic fbdev support. > > > > > > > > > > Signed-off-by: Daniel Vetter > > > > > Cc: Greg Kroah-Hartman > > > > > Cc: Hans de Goede > > > > > Cc: Daniel Vetter > > > > > Cc: Bartlomiej Zolnierkiewicz > > > > > Cc: Alexander Kapshuk > > > > > --- > > > > > drivers/staging/vboxvideo/vbox_fb.c | 5 - > > > > > 1 file changed, 5 deletions(-) > > > > > > > > > > > > > Reviewed-by: Greg Kroah-Hartman > > > > > > Since Hans wants to destage vboxvideo this cycle probably best I merge > > > this through drm-misc? Just to make sure it's not lost. > > > > Feel free to do so! > > Applied, thanks for your review. > > I think 2/2 is directly staging material for you (somehow > get_maintainers.pl didn't add you to the cc: list, not sure why ...). Can you resend it, I don't see it anywhere... ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
On Tue, Jan 15, 2019 at 03:24:55PM +0100, Christian König wrote: > Yeah, indeed. Bounce buffers are an absolute no-go for GPUs. > > If the DMA API finds that a piece of memory is not directly accessible by > the GPU we need to return an error and not try to use bounce buffers behind > the surface. > > That is something which always annoyed me with the DMA API, which is > otherwise rather cleanly defined. That is exactly what I want to fix with my series to make DMA_ATTR_NON_CONSISTENT more useful and always available: https://lists.linuxfoundation.org/pipermail/iommu/2018-December/031985.html With that you allocate the memory using dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT, and use dma_sync_single_* to transfer ownership to the cpu and back to the device, with a gurantee that there won't be any bouncing. So far the interest by the parties that requested the feature has been rather lacklustre, though. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for GNU/kFreeBSD
On Tue, Jan 15, 2019 at 03:04:18PM +, James Clarke wrote: > Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t > types, which differs from the BSDs' headers. Thus we should include > stdint.h to ensure we have all the required integer types. > > Signed-off-by: James Clarke Would be good to get an ack from some other *bsd that this is still all fine. lgtm otherwise. -Daniel > --- > include/uapi/drm/drm.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h > index 300f33663..caf4d9b38 100644 > --- a/include/uapi/drm/drm.h > +++ b/include/uapi/drm/drm.h > @@ -50,6 +50,7 @@ typedef unsigned int drm_handle_t; > > #else /* One of the BSDs */ > > +#include > #include > #include > typedef int8_t __s8; > -- > 2.17.1 > > ___ > 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] staging/vboxvideo: Don't set FBINFO_MISC_ALWAYS_SETPAR
On Tue, Jan 15, 2019 at 02:45:53PM +0100, Greg Kroah-Hartman wrote: > On Tue, Jan 15, 2019 at 01:12:28PM +0100, Daniel Vetter wrote: > > On Tue, Jan 15, 2019 at 11:38:29AM +0100, Greg Kroah-Hartman wrote: > > > On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote: > > > > It's a debug hack flag useful to work around driver bugs. That's not a > > > > good idea for a new driver. Especially for a new drm driver. > > > > > > > > Aside: the fbdev support should probably be converted over to the new > > > > generic fbdev support. > > > > > > > > Signed-off-by: Daniel Vetter > > > > Cc: Greg Kroah-Hartman > > > > Cc: Hans de Goede > > > > Cc: Daniel Vetter > > > > Cc: Bartlomiej Zolnierkiewicz > > > > Cc: Alexander Kapshuk > > > > --- > > > > drivers/staging/vboxvideo/vbox_fb.c | 5 - > > > > 1 file changed, 5 deletions(-) > > > > > > > > > > Reviewed-by: Greg Kroah-Hartman > > > > Since Hans wants to destage vboxvideo this cycle probably best I merge > > this through drm-misc? Just to make sure it's not lost. > > Feel free to do so! Applied, thanks for your review. I think 2/2 is directly staging material for you (somehow get_maintainers.pl didn't add you to the cc: list, not sure why ...). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix drm.h uapi header for GNU/kFreeBSD
Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t types, which differs from the BSDs' headers. Thus we should include stdint.h to ensure we have all the required integer types. Signed-off-by: James Clarke --- include/uapi/drm/drm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 300f33663..caf4d9b38 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -50,6 +50,7 @@ typedef unsigned int drm_handle_t; #else /* One of the BSDs */ +#include #include #include typedef int8_t __s8; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202217] Integrated laptop display doesnt come back up after using PRIME on wayland
https://bugzilla.kernel.org/show_bug.cgi?id=202217 --- Comment #7 from Haxk20 (haxk...@gmail.com) --- I did some further testing. The bug seems to be that even when i run just TTY session without GNOME even launched and i suspend the laptop to turn off the screen then the screen doesnt come back up. But i can still type on keyboard and the machine does what i type. So i have to turn it off blindly. This makes the machine unusable outside where you have to suspend the machine. -- 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
Re: [PATCH v2] Staging: fbtft: Switch to the gpio descriptor interface
On Tue, Jan 15, 2019 at 10:17:09AM +0530, Nishad Kamdar wrote: > This switches the fbtft driver to use GPIO descriptors > rather than numerical gpios: > > Utilize the GPIO library's intrinsic handling of OF GPIOs > and polarity. If the line is flagged active low, gpiolib > will deal with this. > > Remove gpios from platform device structure. Neither assign > statically numbers to gpios in platform device nor allow > gpios to be parsed as module parameters. > > Signed-off-by: Nishad Kamdar > Changes in v2: > - Merge all patches in a single patch. This is because the >first patch changes par->gpio from an int to a pointer >so all the checks have to be updated in the same patch. >Otherwie it breaks 'git bisect'. The "v2" information goes below the --- line please. Also, I got 2 copies of this, both different, so I have no idea which to apply. Please fix up and resend a v3. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/i915/dsi: Adjust crtc_clock for burst_mode_ratio
On Sat, Dec 01, 2018 at 12:31:47PM +0100, Hans de Goede wrote: > On devices with a burst_mode_ratio which is not 100 (1:1), the pclk > will have a different value then drm_display_mode.clock . > > On a Prowise PT301 tablet where vbt.lfp_lvds_vbt_mode.clock is 66100 and > burst_mode_ratio is 130 this leads to the following errors: > > [drm:pipe_config_err [i915]] *ERROR* mismatch in > pixel_rate (expected 66100, found 86458) > [drm:pipe_config_err [i915]] *ERROR* mismatch in > base.adjusted_mode.crtc_clock (expected 66100, found 86458) > [drm:pipe_config_err [i915]] *ERROR* mismatch in > port_clock (expected 66100, found 86458) > > This commit makes intel_dsi_compute_config() set > pipe_config.adjusted_mode.crtc_clock, taking the burst_mode_ratio into > account fixing this. > > Signed-off-by: Hans de Goede > --- > drivers/gpu/drm/i915/vlv_dsi.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c > index c21cbfa9653c..d72ccf557a9c 100644 > --- a/drivers/gpu/drm/i915/vlv_dsi.c > +++ b/drivers/gpu/drm/i915/vlv_dsi.c > @@ -347,6 +347,10 @@ static bool intel_dsi_compute_config(struct > intel_encoder *encoder, > return false; > } > > + adjusted_mode->crtc_clock = > + DIV_ROUND_UP(adjusted_mode->crtc_clock * > + intel_dsi->burst_mode_ratio, 100); Hmm. Won't this cause incorrect refresh rate to be used in eg. vblank timestmap calculations? OTOH if the pipe is really fetching data at the higher burst rate then we should rather want to calculate the watermarks/cdclk based on that higher rate. We do have pixel_rate in the crtc state but atm that is computed in generic code. We might have to push that to be encoder specific to do this correctly... > + > pipe_config->clock_set = true; > > return true; > -- > 2.19.1 -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Split out drm_probe_helper.h
On 1/15/19 2:26 PM, Neil Armstrong wrote: On 15/01/2019 11:41, Daniel Vetter wrote: Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. v2: Make it compile. There was so much compile fail on arm drivers that I figured I'll better not include any of the acks on v1. v3: Massive rebase because i915 has lost a lot of drmP.h includes, but not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h there was still one, which this patch largely removes. Which means rolling out lots more includes all over. This will also conflict with ongoing drmP.h cleanup by others I expect. v3: Rebase on top of atomic bochs. Cc: Sam Ravnborg Cc: Jani Nikula Cc: Laurent Pinchart Acked-by: Rodrigo Vivi (v2) Acked-by: Benjamin Gaignard (v2) Signed-off-by: Daniel Vetter Cc: linux-arm-ker...@lists.infradead.org Cc: virtualizat...@lists.linux-foundation.org Cc: etna...@lists.freedesktop.org Cc: linux-samsung-...@vger.kernel.org Cc: intel-...@lists.freedesktop.org Cc: linux-media...@lists.infradead.org Cc: linux-amlo...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: spice-de...@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org Cc: linux-renesas-...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-te...@vger.kernel.org Cc: xen-de...@lists.xen.org --- Merging this is going to be a bit a mess due to all the ongoing drmP.h cleanups. I think the following should work: - Apply Sam's prep patches for removing drmP.h from drm_modeset_helper.h - Get the i915 drmP.h cleanup backmerged into drm-misc-next - Apply this patch. - Apply Sam's patch to remove drmP.h from drm_modeset_helper.h - All through drm-misc-next, which has some potential for trivial conflicts around #includes with other drivers unfortunately. I hope there's no other driver who'll blow up accidentally because someone else is doing a drmP.h cleanup. Laurent maybe? Jani, ack on this? -Daniel --- .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/arm/malidp_crtc.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/arm/malidp_mw.c | 2 +- drivers/gpu/drm/armada/armada_510.c | 2 +- drivers/gpu/drm/armada/armada_crtc.c | 2 +- drivers/gpu/drm/armada/armada_crtc.h | 2 + drivers/gpu/drm/armada/armada_drv.c | 2 +- drivers/gpu/drm/armada/armada_fb.c| 2 +- drivers/gpu/drm/ast/ast_drv.c | 1 + drivers/gpu/drm/ast/ast_mode.c| 1 + .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- drivers/gpu/drm/bochs/bochs_drv.c | 1 + drivers/gpu/drm/bochs/bochs_kms.c | 1 + drivers/gpu/drm/bridge/adv7511/adv7511.h | 5 +- drivers/gpu/drm/bridge/analogix-anx78xx.c | 2 +- .../drm/bridge/analogix/analogix_dp_core.c| 2 +- drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- drivers/gpu/drm/bridge/panel.c| 2 +- drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- drivers/gpu/drm/bridge/tc358764.c | 2 +- drivers/gpu/drm/bridge/tc358767.c | 2 +- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + drivers/gpu/drm/drm_atomic_helper.c | 1 - drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- drivers/gpu/drm/drm_modeset_helper.c | 2 +- drivers/gpu/drm/drm_probe_helper.c| 2 +- drivers/gpu/drm/drm_si
Re: [PATCH 2/4] drm/i915/dsi: Enable dithering for 6 bpc panels
On Sat, Dec 01, 2018 at 12:31:46PM +0100, Hans de Goede wrote: > The display engine has 2 dithering enable bits which both need to be set > for dithering to happen, 1 in the PIPECONF register which is taken care of > by i9xx_set_pipeconf() and a second bit at the encoder level. > > The dsi code was not setting the encoder level dithering enable bit causing > dithering to be disabled, this commit fixes this. > > Signed-off-by: Hans de Goede > --- > drivers/gpu/drm/i915/vlv_dsi.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c > index c10def5efa22..c21cbfa9653c 100644 > --- a/drivers/gpu/drm/i915/vlv_dsi.c > +++ b/drivers/gpu/drm/i915/vlv_dsi.c > @@ -711,6 +711,10 @@ static void intel_dsi_port_enable(struct intel_encoder > *encoder, > LANE_CONFIGURATION_DUAL_LINK_B : > LANE_CONFIGURATION_DUAL_LINK_A; > } > + > + if (intel_dsi->pixel_format != MIPI_DSI_FMT_RGB888) > + temp |= DITHERING_ENABLE; The docs say this was only made to work in C0 stepping. Not sure any BYT-Ts were ever shipped with B2/3, nor am I sure if setting the bit would have any effect there. IMO let's just set the bit and hope for the best. Reviewed-by: Ville Syrjälä > + > /* assert ip_tg_enable signal */ > I915_WRITE(port_ctrl, temp | DPI_ENABLE); > POSTING_READ(port_ctrl); > -- > 2.19.1 -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #97 from Michel Dänzer --- (In reply to tempel.julian from comment #96) > I also noticed that sometimes switching between Vulkan fullscreen windows > (radv) and desktop can break TearFree, it needs to be reactivated then. I > however would like to find a 100% reproducible way to reproduce first before > reporting. Make sure you test with https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/15 before reporting. :) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/i915/dsi: Fix pipe_bpp for handling for 6 bpc pixel-formats
On Sat, Dec 01, 2018 at 12:31:45PM +0100, Hans de Goede wrote:
> There are 3 problems with the dsi code's pipe_bpp handling for 6 bpc
> pixel-formats which this commit addresses:
>
> 1) It assumes that the pipe_bpp is the same as the bpp going over the dsi
> lanes. This assumption is not valid for MIPI_DSI_FMT_RGB666, where pipe_bpp
> should be 18 so that we do proper dithering but we actually send 24 bpp
> over the dsi lanes (MIPI_DSI_FMT_RGB666_PACKED sends 18 bpp).
>
> This assumption is enforced by an assert in *_dsi_get_pclk(). This assert
> triggers on the initial hw-state readback on BYT/CHT devices which use
> MIPI_DSI_FMT_RGB666, such as the Prowise PT301 tablet. PIPECONF is set to
> 6BPC / 18 bpp by the GOP, while mipi_dsi_pixel_format_to_bpp() returns 24.
>
> This commits switches the calculations in *_dsi_get_pclk() to use the bpp
> from mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format) which
> returns the bpp going over the mipi lanes and drops the assert.
>
> 2) On BXT bxt_dsi_get_pipe_config() wrongly overrides the pipe_bpp which
> i9xx_get_pipe_config() reads from PIPECONF with the return value from
> mipi_dsi_pixel_format_to_bpp(). This avoids the assert from 1. but is wrong
> since the pipe is actually running at the value configured in PIPECONF.
>
> This commit drops the override of pipe_bpp from bxt_dsi_get_pipe_config().
>
> 3) The dsi encoder's compute_config() never assigns a value to pipe_bpp,
> unlike most other encoders. Falling back on compute_baseline_pipe_bpp()
> which always picks 24. 24 is only correct for MIPI_DSI_FMT_RGB88 for the
> others we should use 18 bpp so that we correctly do 6bpc color dithering.
>
> This commit adds code to intel_dsi_compute_config() to properly set
> pipe_bpp based on intel_dsi->pixel_format.
>
> Signed-off-by: Hans de Goede
lgtm
Reviewed-by: Ville Syrjälä
That said, I think we could make everything less confusing by doing
something like this:
compute_config() {
port_clock = bitrate;
}
get_config() {
port_clock = readout from pll;
crtc_clock = derive from port_clock;
}
> ---
> drivers/gpu/drm/i915/intel_dsi.h | 4 ++--
> drivers/gpu/drm/i915/vlv_dsi.c | 17
> drivers/gpu/drm/i915/vlv_dsi_pll.c | 31 ++
> 3 files changed, 17 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index c888c219835f..c796a2962a43 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -160,7 +160,7 @@ int vlv_dsi_pll_compute(struct intel_encoder *encoder,
> void vlv_dsi_pll_enable(struct intel_encoder *encoder,
> const struct intel_crtc_state *config);
> void vlv_dsi_pll_disable(struct intel_encoder *encoder);
> -u32 vlv_dsi_get_pclk(struct intel_encoder *encoder, int pipe_bpp,
> +u32 vlv_dsi_get_pclk(struct intel_encoder *encoder,
>struct intel_crtc_state *config);
> void vlv_dsi_reset_clocks(struct intel_encoder *encoder, enum port port);
>
> @@ -170,7 +170,7 @@ int bxt_dsi_pll_compute(struct intel_encoder *encoder,
> void bxt_dsi_pll_enable(struct intel_encoder *encoder,
> const struct intel_crtc_state *config);
> void bxt_dsi_pll_disable(struct intel_encoder *encoder);
> -u32 bxt_dsi_get_pclk(struct intel_encoder *encoder, int pipe_bpp,
> +u32 bxt_dsi_get_pclk(struct intel_encoder *encoder,
>struct intel_crtc_state *config);
> void bxt_dsi_reset_clocks(struct intel_encoder *encoder, enum port port);
>
> diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
> index be3af5f6c7a0..c10def5efa22 100644
> --- a/drivers/gpu/drm/i915/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/vlv_dsi.c
> @@ -322,6 +322,11 @@ static bool intel_dsi_compute_config(struct
> intel_encoder *encoder,
> /* DSI uses short packets for sync events, so clear mode flags for DSI
> */
> adjusted_mode->flags = 0;
>
> + if (intel_dsi->pixel_format == MIPI_DSI_FMT_RGB888)
> + pipe_config->pipe_bpp = 24;
> + else
> + pipe_config->pipe_bpp = 18;
> +
> if (IS_GEN9_LP(dev_priv)) {
> /* Enable Frame time stamp based scanline reporting */
> adjusted_mode->private_flags |=
> @@ -1097,10 +1102,8 @@ static void bxt_dsi_get_pipe_config(struct
> intel_encoder *encoder,
> }
>
> fmt = I915_READ(MIPI_DSI_FUNC_PRG(port)) & VID_MODE_FORMAT_MASK;
> - pipe_config->pipe_bpp =
> - mipi_dsi_pixel_format_to_bpp(
> - pixel_format_from_register_bits(fmt));
> - bpp = pipe_config->pipe_bpp;
> + bpp = mipi_dsi_pixel_format_to_bpp(
> + pixel_format_from_register_bits(fmt));
>
> /* Enable Frame time stamo based scanline reporting */
> adjusted_mode->private_flags |=
> @@ -1238,11 +1241,9 @@ static void intel_dsi_get_config(struct intel_e
Re: [PATCH] [RFC] drm_hwcomposer: Add support for Arm Framebuffer Compression (AFBC) modifiers.
On Tue, Jan 15, 2019 at 02:29:19PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 2:27 PM Liviu Dudau wrote:
> >
> > On Tue, Jan 15, 2019 at 01:38:19PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
> > > >
> > > > On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> > > > > On Mon, Jan 14, 2019 at 03:28:27PM +, Ayan Halder wrote:
> > > > > > One needs to translate the Gralloc buffer flags for AFBC (eg
> > > > > > MALI_GRALLOC_INTFMT_AFBC_BASIC) to the corresponding linux kernel
> > > > > > drm modifiers.
> > > > > > This gets passed to libdrm via drmModeAddFB2WithModifiers.
> > > > > >
> > > > > > Signed-off-by: Ayan Kumar Halder
> > > > > >
> > > > > > /-- Note for reviewer
> > > > > > I was able to get this working for Android P on Juno with Mali
> > > > > > DP650 and Mali
> > > > > > T860 gpu(with some additional hacks). I have not yet validated this
> > > > > > hikey960.
> > > > > >
> > > > > > I have used the following components:-
> > > > > > 1. Gralloc (from
> > > > > > https://android.googlesource.com/device/linaro/hikey/+/master/gralloc960)
> > > > > > - Built with MALI_MMSS=1
> > > > > > 2. Libdrm (from git://anongit.freedesktop.org/mesa/drm)
> > > > > > - You would need drm_fourcc.h and gralloc_handle.h
> > > > > > --/
> > > > >
> > > > > I thought drm_hwcomposer has switched over to gitlab merge requests?
> > > > > README at least says so:
> > > > >
> > > > > https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer
> > > >
> > > > So are we to send pull requests for RFCs as well?
> > >
> > > Hm, not sure you should stuff RFC material into your linux-next
> > > branches. I thought that's only for patches which by all intents are
> > > ready for the next merge window, i.e. reviewed&tested and all that.
> > > Not for in-flight stuff still under discussion.
> >
> > I think you're confusing the documentation patch with the drm_hwcomposer
> > one (this one).
>
> Indeed. And yes everything even RFC. Gitlab even has some special
> support for work in progress, just start your pull request summary
> with WIP.
> -Daniel
>
Thanks, I have created a merge request now. I wasnot sure initially
how the review process worked for gitlab projects.
> >
> > Best regards,
> > Liviu
> >
> > > -Daniel
> > >
> > >
> > > > Best regards,
> > > > Liviu
> > > >
> > > > >
> > > > > Cheers, Daniel
> > > > >
> > > > > > ---
> > > > > > platformdrmgeneric.cpp | 42
> > > > > > ++
> > > > > > platformdrmgeneric.h | 2 ++
> > > > > > platformhisi.cpp | 14 --
> > > > > > 3 files changed, 56 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/platformdrmgeneric.cpp b/platformdrmgeneric.cpp
> > > > > > index 503c04a..a520224 100644
> > > > > > --- a/platformdrmgeneric.cpp
> > > > > > +++ b/platformdrmgeneric.cpp
> > > > > > @@ -18,6 +18,7 @@
> > > > > >
> > > > > > #include "platformdrmgeneric.h"
> > > > > > #include "drmdevice.h"
> > > > > > +#include "mali_gralloc_formats.h"
> > > > > > #include "platform.h"
> > > > > >
> > > > > > #include
> > > > > > @@ -83,6 +84,31 @@ uint32_t
> > > > > > DrmGenericImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
> > > > > >}
> > > > > > }
> > > > > >
> > > > > > +uint64_t
> > > > > > DrmGenericImporter::ConvertGrallocFormatToDrmModifiers(uint64_t
> > > > > > flags,
> > > > > > +
> > > > > > bool is_rgb) {
> > > > > > + uint64_t features = 0;
> > > > > > +
> > > > > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_BASIC)
> > > > > > +features |= AFBC_FORMAT_MOD_BLOCK_SIZE_16x16;
> > > > > > +
> > > > > > + if (is_rgb)
> > > > > > +features |= AFBC_FORMAT_MOD_YTR;
> > > > > > +
> > > > > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_SPLITBLK)
> > > > > > +features |= (AFBC_FORMAT_MOD_SPLIT | AFBC_FORMAT_MOD_SPARSE);
> > > > > > +
> > > > > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_WIDEBLK)
> > > > > > +features |= AFBC_FORMAT_MOD_BLOCK_SIZE_32x8;
> > > > > > +
> > > > > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_TILED_HEADERS)
> > > > > > +features |= AFBC_FORMAT_MOD_TILED;
> > > > > > +
> > > > > > + if (features)
> > > > > > +return DRM_FORMAT_MOD_ARM_AFBC(features);
> > > > > > + else
> > > > > > +return 0;
> > > > > > +}
> > > > > > +
> > > > > > uint32_t DrmGenericImporter::DrmFormatToBitsPerPixel(uint32_t
> > > > > > drm_format) {
> > > > > >switch (drm_format) {
> > > > > > case DRM_FORMAT_ARGB:
> > > > > > @@ -101,6 +127,22 @@ uint32_t
> > > > > > DrmGenericImporter::DrmFormatToBitsPerPixel(uint32_t drm_format) {
> > > > > >}
> > > > > > }
> > > > > >
> > > > > > +bool DrmGenericImporter::IsDrmFormatRgb(uint32_t drm_format) {
> > > > > > + switch (drm_format) {
> > > > > > +case DRM_FORMAT_ARGB:
> > > > > > +case DRM_FORMAT_XBGR:
> > > > > > +case DRM_FORMAT_ABGR:
> > > > > > +cas
[PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
Hi all, I would like to have some Acked-by's from you, the distro media folks Cc'd here, to document your intent to start using Intel's new media driver[1]. So if you recognize yourself (or are otherwise interested), please read on. TL;DR Distro folks, please give your Acked-by on patch [5/6] I believe most are already aware of the situation that Intel is moving to the new codebase for libva backend to support new Intel integrated graphics devices. The existing intel-libva-driver will be continue to be be supported for pre-Icelake platforms (https://patchwork.freedesktop.org/series/49190/ The userspace changes are reviewed and rebased here: https://github.com/intel/media-driver/pull/271 https://github.com/intel/media-driver/pull/463 Best Regards, Joonas Lahtinen Cc: dri-devel@lists.freedesktop.org Cc: Timo Aaltonen Cc: Takashi Iwai Cc: Stephane Marchesin Cc: Dave Airlie Cc: Daniel Vetter PS. This series might result in some CI failures reported as it adds new uAPI and Patchwork / CI synchronization of tests and kernel is currently WIP. [1] https://github.com/intel/media-driver [2] https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements Lionel Landwerlin (2): drm/i915: Record the sseu configuration per-context & engine drm/i915/perf: lock powergating configuration to default when active Tvrtko Ursulin (4): drm/i915/execlists: Move RPCS setup to context pin drm/i915: Add timeline barrier support drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) drm/i915/selftests: Context SSEU reconfiguration tests drivers/gpu/drm/i915/i915_drv.h | 14 + drivers/gpu/drm/i915/i915_gem_context.c | 354 - drivers/gpu/drm/i915/i915_gem_context.h | 10 + drivers/gpu/drm/i915/i915_perf.c | 13 +- drivers/gpu/drm/i915/i915_request.c | 13 + drivers/gpu/drm/i915/i915_request.h | 10 + drivers/gpu/drm/i915/i915_timeline.c | 3 + drivers/gpu/drm/i915/i915_timeline.h | 27 + drivers/gpu/drm/i915/intel_lrc.c | 100 ++-- drivers/gpu/drm/i915/intel_lrc.h | 2 + .../gpu/drm/i915/selftests/i915_gem_context.c | 481 ++ .../gpu/drm/i915/selftests/mock_timeline.c| 2 + include/uapi/drm/i915_drm.h | 64 +++ 13 files changed, 1056 insertions(+), 37 deletions(-) -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Split out drm_probe_helper.h
Hi Daniel, Thank you for the patch. On Tuesday, 15 January 2019 12:41:37 EET Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. > > v2: Make it compile. There was so much compile fail on arm drivers > that I figured I'll better not include any of the acks on v1. > > v3: Massive rebase because i915 has lost a lot of drmP.h includes, but > not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h > there was still one, which this patch largely removes. Which means > rolling out lots more includes all over. > > This will also conflict with ongoing drmP.h cleanup by others I > expect. > > v3: Rebase on top of atomic bochs. > > Cc: Sam Ravnborg > Cc: Jani Nikula > Cc: Laurent Pinchart > Acked-by: Rodrigo Vivi (v2) > Acked-by: Benjamin Gaignard (v2) > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: etna...@lists.freedesktop.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-...@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-te...@vger.kernel.org > Cc: xen-de...@lists.xen.org > --- > Merging this is going to be a bit a mess due to all the ongoing drmP.h > cleanups. I think the following should work: > - Apply Sam's prep patches for removing drmP.h from > drm_modeset_helper.h > - Get the i915 drmP.h cleanup backmerged into drm-misc-next > - Apply this patch. > - Apply Sam's patch to remove drmP.h from drm_modeset_helper.h > - All through drm-misc-next, which has some potential for trivial > conflicts around #includes with other drivers unfortunately. > > I hope there's no other driver who'll blow up accidentally because > someone else is doing a drmP.h cleanup. Laurent maybe? There's a drmP.h cleanup in the R-Car DU driver, but it doesn't conflict with this patch, the combination of both compiles fine. > Jani, ack on this? > -Daniel > --- [snip] > drivers/gpu/drm/bridge/adv7511/adv7511.h | 5 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 2 +- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > drivers/gpu/drm/drm_atomic_helper.c | 1 - > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > drivers/gpu/drm/drm_probe_helper.c| 2 +- > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > drivers/gpu/drm/omapdrm/omap_connector.c | 2 +- > drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +- > drivers/gpu/drm/omapdrm/omap_drv.c| 2 +- > drivers/gpu/drm/omapdrm/omap_drv.h| 2 +- > drivers/gpu/drm/omapdrm/omap_encoder.c| 2 +- > drivers/gpu/drm/omapdrm/omap_fb.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 2 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +- > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 1 + > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 1 + > drivers/gpu/drm/shmobile/shmob_drm_kms.c | 1 + > include/drm/drm_crtc_helper.h | 16 -- > include/drm/drm_probe_helper.h| 50 +++ For the above files, with the comments below addressed, Reviewed-by: Laurent Pinchart > 227 files changed, 289 insertions(+), 200 deletions(-) > create mode 100644 include/drm/drm_probe_helper.h [snip] > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h > b/drivers/gpu/drm/bridge/adv7511/adv7511.h index 73d8ccb97742..d52ffab41eb4 > 100644 > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h > @@ -14,8 +14,11 @@ > #include > #include > > -#include > +#include The probe helpers are needed in adv7511_drv.c only, I would move the include there. > #include > +#include > +#include > +#include Please keep the headers alphabetically sorted, here and in all other drivers. > #define ADV7511_REG_CHIP_REVISION0x00 > #define ADV7511_R
[Bug 109359] Flickering and artifacts on dual 4K displays from RX 570
https://bugs.freedesktop.org/show_bug.cgi?id=109359 --- Comment #3 from Timur Kristóf --- Created attachment 143127 --> https://bugs.freedesktop.org/attachment.cgi?id=143127&action=edit xorg 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 109359] Flickering and artifacts on dual 4K displays from RX 570
https://bugs.freedesktop.org/show_bug.cgi?id=109359 --- Comment #2 from Timur Kristóf --- Created attachment 143126 --> https://bugs.freedesktop.org/attachment.cgi?id=143126&action=edit dmesg 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
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
Am 15.01.19 um 15:17 schrieb Thomas Hellstrom: Hi, Christoph, On Mon, 2019-01-14 at 10:48 +0100, Christoph Hellwig wrote: On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote: Changes since the RFC: - Rework vmwgfx too [CH] - Use a distinct type for the DMA page iterator [CH] - Do not have a #ifdef [CH] ChristophH: Will you ack? This looks generally fine. Are you still OK with the vmwgfx reworking, or should we go back to the original version that didn't have the type safety so this driver can be left broken? I think the map method in vmgfx that just does virt_to_phys is pretty broken. Thomas, can you check if you see any performance difference with just doing the proper dma mapping, as that gets the driver out of interface abuse land? The performance difference is not really the main problem here. The problem is that even though we utilize the streaming DMA interface, we use it only since we have to for DMA-Remapping and assume that the memory is coherent. To be able to be as compliant as possible and ditch the virt-to-phys mode, we *need* a DMA interface flag that tells us when the dma_sync_for_xxx are no-ops. If they aren't we'll refuse to load for now. I'm not sure, but I think also nouveau and radeon suffer from the same issue. Yeah, indeed. Bounce buffers are an absolute no-go for GPUs. If the DMA API finds that a piece of memory is not directly accessible by the GPU we need to return an error and not try to use bounce buffers behind the surface. That is something which always annoyed me with the DMA API, which is otherwise rather cleanly defined. Christian. While we're at it I think we need to merge my series in this area for 5.0, because without that the driver is already broken. Where should we merge it? I can merge it through vmwgfx/drm-fixes. There is an outstanding issue with patch 3. Do you want me to fix that up? Thanks, Thomas ___ 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
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #54 from OliverHB --- Did anyone ever try switching to a text console (CTRL-ALT-F[1-6]) and back (usually CTRl-ALT-F7)to graphical screen? That does the trick for me! However, I wouldn't mind if there is a solution which makes that obsolete... -- 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] lib/scatterlist: Provide a DMA page iterator
Hi, Christoph, On Mon, 2019-01-14 at 10:48 +0100, Christoph Hellwig wrote: > On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote: > > > Changes since the RFC: > > > - Rework vmwgfx too [CH] > > > - Use a distinct type for the DMA page iterator [CH] > > > - Do not have a #ifdef [CH] > > > > ChristophH: Will you ack? > > This looks generally fine. > > > Are you still OK with the vmwgfx reworking, or should we go back to > > the original version that didn't have the type safety so this > > driver > > can be left broken? > > I think the map method in vmgfx that just does virt_to_phys is > pretty broken. Thomas, can you check if you see any performance > difference with just doing the proper dma mapping, as that gets the > driver out of interface abuse land? The performance difference is not really the main problem here. The problem is that even though we utilize the streaming DMA interface, we use it only since we have to for DMA-Remapping and assume that the memory is coherent. To be able to be as compliant as possible and ditch the virt-to-phys mode, we *need* a DMA interface flag that tells us when the dma_sync_for_xxx are no-ops. If they aren't we'll refuse to load for now. I'm not sure, but I think also nouveau and radeon suffer from the same issue. > > While we're at it I think we need to merge my series in this area > for 5.0, because without that the driver is already broken. Where > should we merge it? I can merge it through vmwgfx/drm-fixes. There is an outstanding issue with patch 3. Do you want me to fix that up? Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/xen-front: Make shmem backed display buffer coherent
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content of the buffer which may
lead to screen artifacts. Make sure that the frontend's
memory is coherent and the backend always sees correct display
buffer content.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Oleksandr Andrushchenko
---
Changes since v1:
- Remove GFP_USER|__GFP_DMA32 mapping flags (Gerd)
- Use drm_prime_pages_to_sg directly (Noralf)
drivers/gpu/drm/xen/xen_drm_front_gem.c | 38 ++---
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 28bc501af450..0b0d9b4f97dc 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -32,8 +32,11 @@ struct xen_gem_object {
/* set for buffers allocated by the backend */
bool be_alloc;
- /* this is for imported PRIME buffer */
- struct sg_table *sgt_imported;
+ /*
+* this is for imported PRIME buffer or the one allocated via
+* drm_gem_get_pages.
+*/
+ struct sg_table *sgt;
};
static inline struct xen_gem_object *
@@ -124,8 +127,28 @@ static struct xen_gem_object *gem_create(struct drm_device
*dev, size_t size)
goto fail;
}
+ xen_obj->sgt = drm_prime_pages_to_sg(xen_obj->pages,
+xen_obj->num_pages);
+ if (IS_ERR_OR_NULL(xen_obj->sgt)) {
+ ret = PTR_ERR(xen_obj->sgt);
+ xen_obj->sgt = NULL;
+ goto fail_put_pages;
+ }
+
+ if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
+ DMA_BIDIRECTIONAL)) {
+ ret = -EFAULT;
+ goto fail_free_sgt;
+ }
+
return xen_obj;
+fail_free_sgt:
+ sg_free_table(xen_obj->sgt);
+ xen_obj->sgt = NULL;
+fail_put_pages:
+ drm_gem_put_pages(&xen_obj->base, xen_obj->pages, true, false);
+ xen_obj->pages = NULL;
fail:
DRM_ERROR("Failed to allocate buffer with size %zu\n", size);
return ERR_PTR(ret);
@@ -148,7 +171,7 @@ void xen_drm_front_gem_free_object_unlocked(struct
drm_gem_object *gem_obj)
struct xen_gem_object *xen_obj = to_xen_gem_obj(gem_obj);
if (xen_obj->base.import_attach) {
- drm_prime_gem_destroy(&xen_obj->base, xen_obj->sgt_imported);
+ drm_prime_gem_destroy(&xen_obj->base, xen_obj->sgt);
gem_free_pages_array(xen_obj);
} else {
if (xen_obj->pages) {
@@ -157,6 +180,13 @@ void xen_drm_front_gem_free_object_unlocked(struct
drm_gem_object *gem_obj)
xen_obj->pages);
gem_free_pages_array(xen_obj);
} else {
+ if (xen_obj->sgt) {
+ dma_unmap_sg(xen_obj->base.dev->dev,
+xen_obj->sgt->sgl,
+xen_obj->sgt->nents,
+DMA_BIDIRECTIONAL);
+ sg_free_table(xen_obj->sgt);
+ }
drm_gem_put_pages(&xen_obj->base,
xen_obj->pages, true, false);
}
@@ -202,7 +232,7 @@ xen_drm_front_gem_import_sg_table(struct drm_device *dev,
if (ret < 0)
return ERR_PTR(ret);
- xen_obj->sgt_imported = sgt;
+ xen_obj->sgt = sgt;
ret = drm_prime_sg_to_page_addr_arrays(sgt, xen_obj->pages,
NULL, xen_obj->num_pages);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #96 from tempel.jul...@gmail.com --- Yep, that's my observation as well (no compositor vsync enbled at the same time). I also noticed that sometimes switching between Vulkan fullscreen windows (radv) and desktop can break TearFree, it needs to be reactivated then. I however would like to find a 100% reproducible way to reproduce first before reporting. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] staging/vboxvideo: Don't set FBINFO_MISC_ALWAYS_SETPAR
On Tue, Jan 15, 2019 at 01:12:28PM +0100, Daniel Vetter wrote: > On Tue, Jan 15, 2019 at 11:38:29AM +0100, Greg Kroah-Hartman wrote: > > On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote: > > > It's a debug hack flag useful to work around driver bugs. That's not a > > > good idea for a new driver. Especially for a new drm driver. > > > > > > Aside: the fbdev support should probably be converted over to the new > > > generic fbdev support. > > > > > > Signed-off-by: Daniel Vetter > > > Cc: Greg Kroah-Hartman > > > Cc: Hans de Goede > > > Cc: Daniel Vetter > > > Cc: Bartlomiej Zolnierkiewicz > > > Cc: Alexander Kapshuk > > > --- > > > drivers/staging/vboxvideo/vbox_fb.c | 5 - > > > 1 file changed, 5 deletions(-) > > > > > > > Reviewed-by: Greg Kroah-Hartman > > Since Hans wants to destage vboxvideo this cycle probably best I merge > this through drm-misc? Just to make sure it's not lost. Feel free to do so! thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the mali-dp tree
On Tue, Jan 15, 2019 at 1:23 PM Liviu Dudau wrote: > > On Tue, Jan 15, 2019 at 01:08:36PM +0100, Daniel Vetter wrote: > > On Tue, Jan 15, 2019 at 10:51:02AM +, Liviu Dudau wrote: > > > On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote: > > > > Hi Liviu, > > > > > > > > On Tue, 15 Jan 2019 10:12:19 + Liviu Dudau > > > > wrote: > > > > > > > > > > That looks like the right fix, thank you for that! > > > > > > > > Thanks for your verification. > > > > > > > > > I will roll your patch into my tree. > > > > > > > > You can only do that when your tree is merged with the drm tree (and > > > > it should be part of the merge resolution). > > > > > > I can also rebase on top of the latest drm-next tree, that should not be > > > a problem. > > > > If you have a lot of patches already rebasing is kinda discouraged. There > > might be other stuff that's conflicting and then making your entire tree > > non-bisectable (maybe just on one platform that you missed in testing). > > My tree has always been "unstable", I have been rebasing it on top of > latest drm or drm-next in preparation for sending pull requests. I've hoped > that people don't depend on the linearity of my tree anyway and it hasn't > been an issue so far. "Don't unecessarily rebase" isn't only about screwing up people who base their own stuff on your tree, it's also about invalidating testing. E.g. if there's a silent conflict with latest drm-next, and you rebase before sending out your pull request, but then don't notice that new issue, then all these commit won't work in a bisect for a 2nd issue. But if you don't rebase, then only the merge commit will be broken (until the bugfix was commit, which is hopefully not too long), and all the commits on your branch still work. So summary is that if you regularly rebase your pile of "ready for linux-next" patches, then you're doing something wrong. And the bigger your team (and hence the amount of work going on) the more wrong this becomes. Ime you can rebase to squash in bugfixes with a bigger team still, but rebasing to change the baseline stops being a good idea pretty quickly. -Daniel > TBH, I should've based the latest update of my tree on drm-next anyway, I > just started at the time when it was at v5.0-rc1 so I thought it will not > matter. > > Best regards, > Liviu > > > > > In that case just send out a pull for drm-next and include the merge > > resolution in the pull request so Dave/I can double-check we did it right. > > -Daniel > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > > -- > > | I would like to | > | fix the world, | > | but they're not | > | giving me the | > \ source code! / > --- > ¯\_(ツ)_/¯ > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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] [RFC] drm_hwcomposer: Add support for Arm Framebuffer Compression (AFBC) modifiers.
On Tue, Jan 15, 2019 at 2:27 PM Liviu Dudau wrote:
>
> On Tue, Jan 15, 2019 at 01:38:19PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
> > >
> > > On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> > > > On Mon, Jan 14, 2019 at 03:28:27PM +, Ayan Halder wrote:
> > > > > One needs to translate the Gralloc buffer flags for AFBC (eg
> > > > > MALI_GRALLOC_INTFMT_AFBC_BASIC) to the corresponding linux kernel drm
> > > > > modifiers.
> > > > > This gets passed to libdrm via drmModeAddFB2WithModifiers.
> > > > >
> > > > > Signed-off-by: Ayan Kumar Halder
> > > > >
> > > > > /-- Note for reviewer
> > > > > I was able to get this working for Android P on Juno with Mali DP650
> > > > > and Mali
> > > > > T860 gpu(with some additional hacks). I have not yet validated this
> > > > > hikey960.
> > > > >
> > > > > I have used the following components:-
> > > > > 1. Gralloc (from
> > > > > https://android.googlesource.com/device/linaro/hikey/+/master/gralloc960)
> > > > > - Built with MALI_MMSS=1
> > > > > 2. Libdrm (from git://anongit.freedesktop.org/mesa/drm)
> > > > > - You would need drm_fourcc.h and gralloc_handle.h
> > > > > --/
> > > >
> > > > I thought drm_hwcomposer has switched over to gitlab merge requests?
> > > > README at least says so:
> > > >
> > > > https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer
> > >
> > > So are we to send pull requests for RFCs as well?
> >
> > Hm, not sure you should stuff RFC material into your linux-next
> > branches. I thought that's only for patches which by all intents are
> > ready for the next merge window, i.e. reviewed&tested and all that.
> > Not for in-flight stuff still under discussion.
>
> I think you're confusing the documentation patch with the drm_hwcomposer one
> (this one).
Indeed. And yes everything even RFC. Gitlab even has some special
support for work in progress, just start your pull request summary
with WIP.
-Daniel
>
> Best regards,
> Liviu
>
> > -Daniel
> >
> >
> > > Best regards,
> > > Liviu
> > >
> > > >
> > > > Cheers, Daniel
> > > >
> > > > > ---
> > > > > platformdrmgeneric.cpp | 42
> > > > > ++
> > > > > platformdrmgeneric.h | 2 ++
> > > > > platformhisi.cpp | 14 --
> > > > > 3 files changed, 56 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/platformdrmgeneric.cpp b/platformdrmgeneric.cpp
> > > > > index 503c04a..a520224 100644
> > > > > --- a/platformdrmgeneric.cpp
> > > > > +++ b/platformdrmgeneric.cpp
> > > > > @@ -18,6 +18,7 @@
> > > > >
> > > > > #include "platformdrmgeneric.h"
> > > > > #include "drmdevice.h"
> > > > > +#include "mali_gralloc_formats.h"
> > > > > #include "platform.h"
> > > > >
> > > > > #include
> > > > > @@ -83,6 +84,31 @@ uint32_t
> > > > > DrmGenericImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
> > > > >}
> > > > > }
> > > > >
> > > > > +uint64_t
> > > > > DrmGenericImporter::ConvertGrallocFormatToDrmModifiers(uint64_t flags,
> > > > > +bool
> > > > > is_rgb) {
> > > > > + uint64_t features = 0;
> > > > > +
> > > > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_BASIC)
> > > > > +features |= AFBC_FORMAT_MOD_BLOCK_SIZE_16x16;
> > > > > +
> > > > > + if (is_rgb)
> > > > > +features |= AFBC_FORMAT_MOD_YTR;
> > > > > +
> > > > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_SPLITBLK)
> > > > > +features |= (AFBC_FORMAT_MOD_SPLIT | AFBC_FORMAT_MOD_SPARSE);
> > > > > +
> > > > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_WIDEBLK)
> > > > > +features |= AFBC_FORMAT_MOD_BLOCK_SIZE_32x8;
> > > > > +
> > > > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_TILED_HEADERS)
> > > > > +features |= AFBC_FORMAT_MOD_TILED;
> > > > > +
> > > > > + if (features)
> > > > > +return DRM_FORMAT_MOD_ARM_AFBC(features);
> > > > > + else
> > > > > +return 0;
> > > > > +}
> > > > > +
> > > > > uint32_t DrmGenericImporter::DrmFormatToBitsPerPixel(uint32_t
> > > > > drm_format) {
> > > > >switch (drm_format) {
> > > > > case DRM_FORMAT_ARGB:
> > > > > @@ -101,6 +127,22 @@ uint32_t
> > > > > DrmGenericImporter::DrmFormatToBitsPerPixel(uint32_t drm_format) {
> > > > >}
> > > > > }
> > > > >
> > > > > +bool DrmGenericImporter::IsDrmFormatRgb(uint32_t drm_format) {
> > > > > + switch (drm_format) {
> > > > > +case DRM_FORMAT_ARGB:
> > > > > +case DRM_FORMAT_XBGR:
> > > > > +case DRM_FORMAT_ABGR:
> > > > > +case DRM_FORMAT_BGR888:
> > > > > +case DRM_FORMAT_BGR565:
> > > > > + return true;
> > > > > +case DRM_FORMAT_YVU420:
> > > > > + return false;
> > > > > +default:
> > > > > + ALOGE("Unsupported format %u assuming rgb?", drm_format);
> > > > > + return true;
> > > > > + }
> > > > > +}
> > > > > +
> > > > > int DrmGenericImporter::ImportBuffer(buffer_handle_t handle,
> > > > > hwc_drm_bo_t *bo) {
> > > > >gral
Re: [PATCH] [RFC] drm_hwcomposer: Add support for Arm Framebuffer Compression (AFBC) modifiers.
On Tue, Jan 15, 2019 at 01:38:19PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
> >
> > On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> > > On Mon, Jan 14, 2019 at 03:28:27PM +, Ayan Halder wrote:
> > > > One needs to translate the Gralloc buffer flags for AFBC (eg
> > > > MALI_GRALLOC_INTFMT_AFBC_BASIC) to the corresponding linux kernel drm
> > > > modifiers.
> > > > This gets passed to libdrm via drmModeAddFB2WithModifiers.
> > > >
> > > > Signed-off-by: Ayan Kumar Halder
> > > >
> > > > /-- Note for reviewer
> > > > I was able to get this working for Android P on Juno with Mali DP650
> > > > and Mali
> > > > T860 gpu(with some additional hacks). I have not yet validated this
> > > > hikey960.
> > > >
> > > > I have used the following components:-
> > > > 1. Gralloc (from
> > > > https://android.googlesource.com/device/linaro/hikey/+/master/gralloc960)
> > > > - Built with MALI_MMSS=1
> > > > 2. Libdrm (from git://anongit.freedesktop.org/mesa/drm)
> > > > - You would need drm_fourcc.h and gralloc_handle.h
> > > > --/
> > >
> > > I thought drm_hwcomposer has switched over to gitlab merge requests?
> > > README at least says so:
> > >
> > > https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer
> >
> > So are we to send pull requests for RFCs as well?
>
> Hm, not sure you should stuff RFC material into your linux-next
> branches. I thought that's only for patches which by all intents are
> ready for the next merge window, i.e. reviewed&tested and all that.
> Not for in-flight stuff still under discussion.
I think you're confusing the documentation patch with the drm_hwcomposer one
(this one).
Best regards,
Liviu
> -Daniel
>
>
> > Best regards,
> > Liviu
> >
> > >
> > > Cheers, Daniel
> > >
> > > > ---
> > > > platformdrmgeneric.cpp | 42 ++
> > > > platformdrmgeneric.h | 2 ++
> > > > platformhisi.cpp | 14 --
> > > > 3 files changed, 56 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/platformdrmgeneric.cpp b/platformdrmgeneric.cpp
> > > > index 503c04a..a520224 100644
> > > > --- a/platformdrmgeneric.cpp
> > > > +++ b/platformdrmgeneric.cpp
> > > > @@ -18,6 +18,7 @@
> > > >
> > > > #include "platformdrmgeneric.h"
> > > > #include "drmdevice.h"
> > > > +#include "mali_gralloc_formats.h"
> > > > #include "platform.h"
> > > >
> > > > #include
> > > > @@ -83,6 +84,31 @@ uint32_t
> > > > DrmGenericImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
> > > >}
> > > > }
> > > >
> > > > +uint64_t
> > > > DrmGenericImporter::ConvertGrallocFormatToDrmModifiers(uint64_t flags,
> > > > +bool
> > > > is_rgb) {
> > > > + uint64_t features = 0;
> > > > +
> > > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_BASIC)
> > > > +features |= AFBC_FORMAT_MOD_BLOCK_SIZE_16x16;
> > > > +
> > > > + if (is_rgb)
> > > > +features |= AFBC_FORMAT_MOD_YTR;
> > > > +
> > > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_SPLITBLK)
> > > > +features |= (AFBC_FORMAT_MOD_SPLIT | AFBC_FORMAT_MOD_SPARSE);
> > > > +
> > > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_WIDEBLK)
> > > > +features |= AFBC_FORMAT_MOD_BLOCK_SIZE_32x8;
> > > > +
> > > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_TILED_HEADERS)
> > > > +features |= AFBC_FORMAT_MOD_TILED;
> > > > +
> > > > + if (features)
> > > > +return DRM_FORMAT_MOD_ARM_AFBC(features);
> > > > + else
> > > > +return 0;
> > > > +}
> > > > +
> > > > uint32_t DrmGenericImporter::DrmFormatToBitsPerPixel(uint32_t
> > > > drm_format) {
> > > >switch (drm_format) {
> > > > case DRM_FORMAT_ARGB:
> > > > @@ -101,6 +127,22 @@ uint32_t
> > > > DrmGenericImporter::DrmFormatToBitsPerPixel(uint32_t drm_format) {
> > > >}
> > > > }
> > > >
> > > > +bool DrmGenericImporter::IsDrmFormatRgb(uint32_t drm_format) {
> > > > + switch (drm_format) {
> > > > +case DRM_FORMAT_ARGB:
> > > > +case DRM_FORMAT_XBGR:
> > > > +case DRM_FORMAT_ABGR:
> > > > +case DRM_FORMAT_BGR888:
> > > > +case DRM_FORMAT_BGR565:
> > > > + return true;
> > > > +case DRM_FORMAT_YVU420:
> > > > + return false;
> > > > +default:
> > > > + ALOGE("Unsupported format %u assuming rgb?", drm_format);
> > > > + return true;
> > > > + }
> > > > +}
> > > > +
> > > > int DrmGenericImporter::ImportBuffer(buffer_handle_t handle,
> > > > hwc_drm_bo_t *bo) {
> > > >gralloc_handle_t *gr_handle = gralloc_handle(handle);
> > > >if (!gr_handle)
> > > > diff --git a/platformdrmgeneric.h b/platformdrmgeneric.h
> > > > index 233ba55..43cb618 100644
> > > > --- a/platformdrmgeneric.h
> > > > +++ b/platformdrmgeneric.h
> > > > @@ -36,6 +36,8 @@ class DrmGenericImporter : public Importer {
> > > >bool CanImportBuffer(buffer_handle_t handle) override;
> > > >
> > > >uint32_t ConvertHalFormatToDrm(uint32_t hal_format);
> > > > + uint
Re: [PATCH] drm/i915: Pass down rc in intel_encoder->compute_config()
On Mon, Jan 14, 2019 at 05:29:31PM -0500, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that means we have the potential to hit a normal modeset
> deadlock. However, because ->compute_config() only returns a bool this
> means we can't return -EDEADLK when we need to drop locks and try again
> which means we end up just failing the atomic check permanently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 8 +++
> drivers/gpu/drm/i915/intel_crt.c | 34 ++--
> drivers/gpu/drm/i915/intel_ddi.c | 6 ++---
> drivers/gpu/drm/i915/intel_display.c | 11 +
> drivers/gpu/drm/i915/intel_dp.c | 32 +-
> drivers/gpu/drm/i915/intel_dp_mst.c | 12 +-
> drivers/gpu/drm/i915/intel_drv.h | 18 +++
> drivers/gpu/drm/i915/intel_dvo.c | 10
> drivers/gpu/drm/i915/intel_hdmi.c| 12 +-
> drivers/gpu/drm/i915/intel_lvds.c| 12 +-
> drivers/gpu/drm/i915/intel_sdvo.c| 14 ++--
> drivers/gpu/drm/i915/intel_tv.c | 8 +++
> drivers/gpu/drm/i915/vlv_dsi.c | 14 ++--
> 13 files changed, 97 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index f3a5f03646ce..355b48d1c937 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder
> *encoder,
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
> }
>
> -static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int gen11_dsi_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
> base);
> @@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct
> intel_encoder *encoder,
> pipe_config->clock_set = true;
> pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
>
> - return true;
> + return 0;
> }
>
> static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 33bd2addcbdd..625794883433 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -345,51 +345,51 @@ intel_crt_mode_valid(struct drm_connector *connector,
> return MODE_OK;
> }
>
> -static bool intel_crt_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int intel_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return false;
> + return -EINVAL;
>
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
Please add a newline here while at it.
> - return true;
> + return 0;
> }
>
> -static bool pch_crt_compute_config(struct intel_encoder *encoder,
> -struct intel_crtc_state *pipe_config,
> -struct drm_connector_state *conn_state)
> +static int pch_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return false;
> + return -EINVAL;
>
> pipe_config->has_pch_encoder = true;
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
[Bug 104345] X-Server hangs with showing scrambled picture, sound still playing.
https://bugs.freedesktop.org/show_bug.cgi?id=104345 --- Comment #13 from bernhardu --- Happened again. A way to avoid that crash may be to not stay int first cold boot. I am not sure but I think I never saw this when system was running from a rebooted state (warm boot). [0.00] Linux version 4.19.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.19.12-1 (2018-12-22) ... [32345.334084] amdgpu :08:00.0: GPU fault detected: 146 0x06407704 for process plasmashell pid 1422 thread plasmashel:cs0 pid 1720 [32345.334092] amdgpu :08:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x001002C8 [32345.334096] amdgpu :08:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02077004 [32345.334101] amdgpu :08:00.0: VM fault (0x04, vmid 1, pasid 32775) at page 1049288, read from 'SDM0' (0x53444d30) (119) [32345.334114] amdgpu :08:00.0: GPU fault detected: 146 0x06407704 for process plasmashell pid 1422 thread plasmashel:cs0 pid 1720 [32345.334118] amdgpu :08:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x001002C8 [32345.334121] amdgpu :08:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02077004 [32345.334125] amdgpu :08:00.0: VM fault (0x04, vmid 1, pasid 32775) at page 1049288, read from 'SDM0' (0x53444d30) (119) [32345.334523] amdgpu :08:00.0: GPU fault detected: 146 0x06d8770c for process plasmashell pid 1422 thread plasmashel:cs0 pid 1720 [32345.334528] amdgpu :08:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x001002DB [32345.334532] amdgpu :08:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0207700C [32345.334538] amdgpu :08:00.0: VM fault (0x0c, vmid 1, pasid 32775) at page 1049307, read from 'SDM0' (0x53444d30) (119) [32355.357958] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=947938, emitted seq=947940 [32355.357965] [drm] GPU recovery disabled. [32505.119425] INFO: task kworker/u32:2:12454 blocked for more than 120 seconds. [32505.119433] Tainted: G OE 4.19.0-1-amd64 #1 Debian 4.19.12-1 [32505.119435] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [32505.119438] kworker/u32:2 D0 12454 2 0x8000 [32505.119460] Workqueue: events_unbound commit_work [drm_kms_helper] [32505.119464] Call Trace: [32505.119474] ? __schedule+0x2a2/0x870 [32505.119480] ? __switch_to_asm+0x40/0x70 [32505.119484] schedule+0x28/0x80 [32505.119488] schedule_timeout+0x26d/0x390 [32505.119586] ? dce110_timing_generator_get_position+0x5b/0x70 [amdgpu] [32505.119682] ? dce110_timing_generator_get_crtc_scanoutpos+0x70/0xb0 [amdgpu] [32505.119687] dma_fence_default_wait+0x238/0x2a0 [32505.119691] ? dma_fence_release+0x90/0x90 [32505.119695] dma_fence_wait_timeout+0xdd/0x100 [32505.119699] reservation_object_wait_timeout_rcu+0x173/0x280 [32505.119800] amdgpu_dm_do_flip+0x112/0x340 [amdgpu] [32505.119903] amdgpu_dm_atomic_commit_tail+0x750/0xdb0 [amdgpu] [32505.119909] ? wait_for_completion_timeout+0x3b/0x1a0 [32505.119913] ? __switch_to_asm+0x34/0x70 [32505.119917] ? __switch_to_asm+0x40/0x70 [32505.119921] ? __switch_to_asm+0x34/0x70 [32505.119924] ? __switch_to_asm+0x40/0x70 [32505.119938] commit_tail+0x3d/0x70 [drm_kms_helper] [32505.119946] process_one_work+0x1a7/0x3a0 [32505.119951] worker_thread+0x30/0x390 [32505.119955] ? pwq_unbound_release_workfn+0xd0/0xd0 [32505.119959] kthread+0x112/0x130 [32505.119963] ? kthread_bind+0x30/0x30 [32505.119967] ret_from_fork+0x22/0x40 [32528.537326] sysrq: SysRq : Keyboard mode set to system default -- 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 109239] Polaris10: Periodic random black screens for 1-2 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109239 --- Comment #7 from Harry Wentland --- If you didn't say you tried swapping monitors and cables I'd say it was a cable issue. Are those high refresh rate displays (120Hz+)? If so you might want to give what's suggested in this comment a try: https://bugs.freedesktop.org/show_bug.cgi?id=102646#c41 It would help us diagnose the issue. -- 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] [RFC] drm_hwcomposer: Add support for Arm Framebuffer Compression (AFBC) modifiers.
On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
>
> On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> > On Mon, Jan 14, 2019 at 03:28:27PM +, Ayan Halder wrote:
> > > One needs to translate the Gralloc buffer flags for AFBC (eg
> > > MALI_GRALLOC_INTFMT_AFBC_BASIC) to the corresponding linux kernel drm
> > > modifiers.
> > > This gets passed to libdrm via drmModeAddFB2WithModifiers.
> > >
> > > Signed-off-by: Ayan Kumar Halder
> > >
> > > /-- Note for reviewer
> > > I was able to get this working for Android P on Juno with Mali DP650 and
> > > Mali
> > > T860 gpu(with some additional hacks). I have not yet validated this
> > > hikey960.
> > >
> > > I have used the following components:-
> > > 1. Gralloc (from
> > > https://android.googlesource.com/device/linaro/hikey/+/master/gralloc960)
> > > - Built with MALI_MMSS=1
> > > 2. Libdrm (from git://anongit.freedesktop.org/mesa/drm)
> > > - You would need drm_fourcc.h and gralloc_handle.h
> > > --/
> >
> > I thought drm_hwcomposer has switched over to gitlab merge requests?
> > README at least says so:
> >
> > https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer
>
> So are we to send pull requests for RFCs as well?
Hm, not sure you should stuff RFC material into your linux-next
branches. I thought that's only for patches which by all intents are
ready for the next merge window, i.e. reviewed&tested and all that.
Not for in-flight stuff still under discussion.
-Daniel
> Best regards,
> Liviu
>
> >
> > Cheers, Daniel
> >
> > > ---
> > > platformdrmgeneric.cpp | 42 ++
> > > platformdrmgeneric.h | 2 ++
> > > platformhisi.cpp | 14 --
> > > 3 files changed, 56 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/platformdrmgeneric.cpp b/platformdrmgeneric.cpp
> > > index 503c04a..a520224 100644
> > > --- a/platformdrmgeneric.cpp
> > > +++ b/platformdrmgeneric.cpp
> > > @@ -18,6 +18,7 @@
> > >
> > > #include "platformdrmgeneric.h"
> > > #include "drmdevice.h"
> > > +#include "mali_gralloc_formats.h"
> > > #include "platform.h"
> > >
> > > #include
> > > @@ -83,6 +84,31 @@ uint32_t
> > > DrmGenericImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
> > >}
> > > }
> > >
> > > +uint64_t DrmGenericImporter::ConvertGrallocFormatToDrmModifiers(uint64_t
> > > flags,
> > > +bool
> > > is_rgb) {
> > > + uint64_t features = 0;
> > > +
> > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_BASIC)
> > > +features |= AFBC_FORMAT_MOD_BLOCK_SIZE_16x16;
> > > +
> > > + if (is_rgb)
> > > +features |= AFBC_FORMAT_MOD_YTR;
> > > +
> > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_SPLITBLK)
> > > +features |= (AFBC_FORMAT_MOD_SPLIT | AFBC_FORMAT_MOD_SPARSE);
> > > +
> > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_WIDEBLK)
> > > +features |= AFBC_FORMAT_MOD_BLOCK_SIZE_32x8;
> > > +
> > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_TILED_HEADERS)
> > > +features |= AFBC_FORMAT_MOD_TILED;
> > > +
> > > + if (features)
> > > +return DRM_FORMAT_MOD_ARM_AFBC(features);
> > > + else
> > > +return 0;
> > > +}
> > > +
> > > uint32_t DrmGenericImporter::DrmFormatToBitsPerPixel(uint32_t
> > > drm_format) {
> > >switch (drm_format) {
> > > case DRM_FORMAT_ARGB:
> > > @@ -101,6 +127,22 @@ uint32_t
> > > DrmGenericImporter::DrmFormatToBitsPerPixel(uint32_t drm_format) {
> > >}
> > > }
> > >
> > > +bool DrmGenericImporter::IsDrmFormatRgb(uint32_t drm_format) {
> > > + switch (drm_format) {
> > > +case DRM_FORMAT_ARGB:
> > > +case DRM_FORMAT_XBGR:
> > > +case DRM_FORMAT_ABGR:
> > > +case DRM_FORMAT_BGR888:
> > > +case DRM_FORMAT_BGR565:
> > > + return true;
> > > +case DRM_FORMAT_YVU420:
> > > + return false;
> > > +default:
> > > + ALOGE("Unsupported format %u assuming rgb?", drm_format);
> > > + return true;
> > > + }
> > > +}
> > > +
> > > int DrmGenericImporter::ImportBuffer(buffer_handle_t handle,
> > > hwc_drm_bo_t *bo) {
> > >gralloc_handle_t *gr_handle = gralloc_handle(handle);
> > >if (!gr_handle)
> > > diff --git a/platformdrmgeneric.h b/platformdrmgeneric.h
> > > index 233ba55..43cb618 100644
> > > --- a/platformdrmgeneric.h
> > > +++ b/platformdrmgeneric.h
> > > @@ -36,6 +36,8 @@ class DrmGenericImporter : public Importer {
> > >bool CanImportBuffer(buffer_handle_t handle) override;
> > >
> > >uint32_t ConvertHalFormatToDrm(uint32_t hal_format);
> > > + uint64_t ConvertGrallocFormatToDrmModifiers(uint64_t flags, bool
> > > is_rgb);
> > > + bool IsDrmFormatRgb(uint32_t drm_format);
> > >uint32_t DrmFormatToBitsPerPixel(uint32_t drm_format);
> > >
> > > private:
> > > diff --git a/platformhisi.cpp b/platformhisi.cpp
> > > index 76fe1e7..1cb7e2c 100644
> > > --- a/platformhisi.cpp
> > > +++ b/platformhisi.cpp
> > > @@ -71,6 +71,9 @@ int HisiImporter::Init() {
> > > }
> > >
> > > int H
[PATCH 3/8] drm/meson: add support for HDMI2.0 2160p modes
Now we support the TMDS Clock > 3.4GHz and support the SCDC Control
operation in the DW-HDMI Controller, we can enable support for the
HDMI2.0 3840x2160@60/50 RGB444 display modes.
Signed-off-by: Neil Armstrong
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/meson/meson_venc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_venc.c
b/drivers/gpu/drm/meson/meson_venc.c
index 0ba04f6813e6..66d73a932d19 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -848,6 +848,8 @@ struct meson_hdmi_venc_vic_mode {
{ 93, &meson_hdmi_encp_mode_2160p24 },
{ 94, &meson_hdmi_encp_mode_2160p25 },
{ 95, &meson_hdmi_encp_mode_2160p30 },
+ { 96, &meson_hdmi_encp_mode_2160p25 },
+ { 97, &meson_hdmi_encp_mode_2160p30 },
{ 0, NULL}, /* sentinel */
};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support
Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
Scrambling when supported or mandatory.
This patch also adds an helper to setup the control bit to support
the high TMDS Bit Period/TMDS Clock-Period Ratio as required with
TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes.
These changes were based on work done by Huicong Xu
and Nickey Yang to support HDMI2.0 modes
on the Rockchip 4.4 BSP kernel at [1]
[1] https://github.com/rockchip-linux/kernel/tree/release-4.4
Cc: Nickey Yang
Cc: Huicong Xu
Signed-off-by: Neil Armstrong
Tested-by: Heiko Stuebner
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 88 ++-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 +
include/drm/bridge/dw_hdmi.h | 1 +
3 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 64c3cf027518..fcd941d52753 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -43,6 +44,11 @@
#define HDMI_EDID_LEN 512
+/* DW-HDMI Controller >= 0x200a are at least compliant with SCDC version 1 */
+#define SCDC_MIN_SOURCE_VERSION0x1
+
+#define HDMI14_MAX_TMDSCLK 34000
+
enum hdmi_datamap {
RGB444_8B = 0x01,
RGB444_10B = 0x03,
@@ -1015,6 +1021,33 @@ void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi,
unsigned short data,
}
EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
+/*
+ * HDMI2.0 Specifies the following procedure for High TMDS Bit Rates:
+ * - The Source shall suspend transmission of the TMDS clock and data
+ * - The Source shall write to the TMDS_Bit_Clock_Ratio bit to change it
+ * from a 0 to a 1 or from a 1 to a 0
+ * - The Source shall allow a minimum of 1 ms and a maximum of 100 ms from
+ * the time the TMDS_Bit_Clock_Ratio bit is written until resuming
+ * transmission of TMDS clock and data
+ *
+ * To respect the 100ms maximum delay, the dw_hdmi_set_high_tmds_clock_ratio()
+ * helper should called right before enabling the TMDS Clock and Data in
+ * the PHY configuration callback.
+ */
+void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi *hdmi)
+{
+ unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mpixelclock;
+
+ /* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
+ if (hdmi->connector.display_info.hdmi.scdc.supported) {
+ if (mtmdsclock > HDMI14_MAX_TMDSCLK)
+ drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
+ else
+ drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 0);
+ }
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_set_high_tmds_clock_ratio);
+
static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
{
hdmi_mask_writeb(hdmi, !enable, HDMI_PHY_CONF0,
@@ -1216,6 +1249,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
dw_hdmi_phy_power_off(hdmi);
+ dw_hdmi_set_high_tmds_clock_ratio(hdmi);
+
/* Leave low power consumption mode by asserting SVSRET. */
if (phy->has_svsret)
dw_hdmi_phy_enable_svsret(hdmi, 1);
@@ -1237,6 +1272,10 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
return ret;
}
+ /* Wait for resuming transmission of TMDS clock and data */
+ if (mpixelclock > HDMI14_MAX_TMDSCLK)
+ msleep(100);
+
return dw_hdmi_phy_power_on(hdmi);
}
@@ -1340,11 +1379,12 @@ static void hdmi_tx_hdcp_config(struct dw_hdmi *hdmi)
static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode
*mode)
{
+ bool is_hdmi2_sink = hdmi->connector.display_info.hdmi.scdc.supported;
struct hdmi_avi_infoframe frame;
u8 val;
/* Initialise info frame from DRM mode */
- drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
+ drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, is_hdmi2_sink);
if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
frame.colorspace = HDMI_COLORSPACE_YUV444;
@@ -1503,7 +1543,8 @@ static void hdmi_config_vendor_specific_infoframe(struct
dw_hdmi *hdmi,
static void hdmi_av_composer(struct dw_hdmi *hdmi,
const struct drm_display_mode *mode)
{
- u8 inv_val;
+ u8 inv_val, bytes;
+ struct drm_hdmi_info *hdmi_info = &hdmi->connector.display_info.hdmi;
struct hdmi_vmode *vmode = &hdmi->hdmi_data.video_mode;
int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len;
unsigned int vdisplay;
@@ -1513,7 +1554,9 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
dev_dbg(hdmi->dev, "final pixclk = %d\n", vmode->mpixelclock);
/* Set up HDMI_FC_INVIDCONF */
- inv_val = (hdmi->hdmi_data.hdcp_enable ?
+ inv_val = (hdmi->hdmi_data.hdcp_enable ||
+
[PATCH 4/8] drm/bridge: dw-hdmi: add support for YUV420 output
In order to support the HDMI2.0 YUV420 display modes, this patch
adds support for the YUV420 TMDS Clock divided by 2 and the controller
passthrough mode.
YUV420 Synopsys PHY support will need some specific configuration table
to support theses modes.
This patch is based on work from Zheng Yang in
the Rockchip Linux 4.4 BSP at [1]
[1] https://github.com/rockchip-linux/kernel/tree/release-4.4
Cc: Zheng Yang
Signed-off-by: Neil Armstrong
Tested-by: Heiko Stuebner
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 68 ++-
1 file changed, 54 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index fcd941d52753..4a9a24e854db 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -99,6 +99,7 @@ struct hdmi_vmode {
unsigned int mpixelclock;
unsigned int mpixelrepetitioninput;
unsigned int mpixelrepetitionoutput;
+ unsigned int mtmdsclock;
};
struct hdmi_data_info {
@@ -543,7 +544,7 @@ static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
static void hdmi_clk_regenerator_update_pixel_clock(struct dw_hdmi *hdmi)
{
mutex_lock(&hdmi->audio_mutex);
- hdmi_set_clk_regenerator(hdmi, hdmi->hdmi_data.video_mode.mpixelclock,
+ hdmi_set_clk_regenerator(hdmi, hdmi->hdmi_data.video_mode.mtmdsclock,
hdmi->sample_rate);
mutex_unlock(&hdmi->audio_mutex);
}
@@ -552,7 +553,7 @@ void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned
int rate)
{
mutex_lock(&hdmi->audio_mutex);
hdmi->sample_rate = rate;
- hdmi_set_clk_regenerator(hdmi, hdmi->hdmi_data.video_mode.mpixelclock,
+ hdmi_set_clk_regenerator(hdmi, hdmi->hdmi_data.video_mode.mtmdsclock,
hdmi->sample_rate);
mutex_unlock(&hdmi->audio_mutex);
}
@@ -653,6 +654,20 @@ static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
}
}
+static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
+{
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
+ case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
+ case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
+ case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
+ return true;
+
+ default:
+ return false;
+ }
+}
+
static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
{
switch (bus_format) {
@@ -882,7 +897,8 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi)
u8 val, vp_conf;
if (hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format) ||
- hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format)) {
+ hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format) ||
+ hdmi_bus_fmt_is_yuv420(hdmi->hdmi_data.enc_out_bus_format)) {
switch (hdmi_bus_fmt_color_depth(
hdmi->hdmi_data.enc_out_bus_format)) {
case 8:
@@ -1036,7 +1052,7 @@ EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
*/
void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi *hdmi)
{
- unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mpixelclock;
+ unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mtmdsclock;
/* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
if (hdmi->connector.display_info.hdmi.scdc.supported) {
@@ -1198,6 +1214,8 @@ static int hdmi_phy_configure_dwc_hdmi_3d_tx(struct
dw_hdmi *hdmi,
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
+ /* TOFIX Will need 420 specific PHY configuration tables */
+
/* PLL/MPLL Cfg - always match on final entry */
for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
if (mpixelclock <= mpll_config->mpixelclock)
@@ -1245,6 +1263,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
unsigned long mpixelclock = hdmi->hdmi_data.video_mode.mpixelclock;
+ unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mtmdsclock;
int ret;
dw_hdmi_phy_power_off(hdmi);
@@ -1273,7 +1292,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
}
/* Wait for resuming transmission of TMDS clock and data */
- if (mpixelclock > HDMI14_MAX_TMDSCLK)
+ if (mtmdsclock > HDMI14_MAX_TMDSCLK)
msleep(100);
return dw_hdmi_phy_power_on(hdmi);
@@ -1383,6 +1402,9 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct
drm_display_mode *mode)
struct hdmi_avi_infoframe frame;
u8 val;
+ if (hdmi_bus_fmt_is_yuv420(hdmi->hdmi_data.enc_out_bus_format))
+ is_hdmi2_sink = true;
+
/* Initialise info frame
[PATCH 5/8] drm/bridge: dw-hdmi: support dynamically get input/out color info
From: Zheng Yang
To get input/output bus_format/enc_format dynamically, this patch
introduce following functions in plat_data:
- get_input_bus_format
- get_output_bus_format
- get_enc_in_encoding
- get_enc_out_encoding
Signed-off-by: Zheng Yang
Signed-off-by: Neil Armstrong
Tested-by: Heiko Stuebner
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 28 +--
include/drm/bridge/dw_hdmi.h | 5
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 4a9a24e854db..bd564ffdf18b 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1810,6 +1810,7 @@ static void hdmi_disable_overflow_interrupts(struct
dw_hdmi *hdmi)
static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct drm_display_mode *mode)
{
int ret;
+ void *data = hdmi->plat_data->phy_data;
hdmi_disable_overflow_interrupts(hdmi);
@@ -1821,10 +1822,13 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct
drm_display_mode *mode)
dev_dbg(hdmi->dev, "CEA mode used vic=%d\n", hdmi->vic);
}
- if ((hdmi->vic == 6) || (hdmi->vic == 7) ||
- (hdmi->vic == 21) || (hdmi->vic == 22) ||
- (hdmi->vic == 2) || (hdmi->vic == 3) ||
- (hdmi->vic == 17) || (hdmi->vic == 18))
+ if (hdmi->plat_data->get_enc_out_encoding)
+ hdmi->hdmi_data.enc_out_encoding =
+ hdmi->plat_data->get_enc_out_encoding(data);
+ else if ((hdmi->vic == 6) || (hdmi->vic == 7) ||
+(hdmi->vic == 21) || (hdmi->vic == 22) ||
+(hdmi->vic == 2) || (hdmi->vic == 3) ||
+(hdmi->vic == 17) || (hdmi->vic == 18))
hdmi->hdmi_data.enc_out_encoding = V4L2_YCBCR_ENC_601;
else
hdmi->hdmi_data.enc_out_encoding = V4L2_YCBCR_ENC_709;
@@ -1833,21 +1837,31 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct
drm_display_mode *mode)
hdmi->hdmi_data.video_mode.mpixelrepetitioninput = 0;
/* TOFIX: Get input format from plat data or fallback to RGB888 */
- if (hdmi->plat_data->input_bus_format)
+ if (hdmi->plat_data->get_input_bus_format)
+ hdmi->hdmi_data.enc_in_bus_format =
+ hdmi->plat_data->get_input_bus_format(data);
+ else if (hdmi->plat_data->input_bus_format)
hdmi->hdmi_data.enc_in_bus_format =
hdmi->plat_data->input_bus_format;
else
hdmi->hdmi_data.enc_in_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
/* TOFIX: Get input encoding from plat data or fallback to none */
- if (hdmi->plat_data->input_bus_encoding)
+ if (hdmi->plat_data->get_enc_in_encoding)
+ hdmi->hdmi_data.enc_in_encoding =
+ hdmi->plat_data->get_enc_in_encoding(data);
+ else if (hdmi->plat_data->input_bus_encoding)
hdmi->hdmi_data.enc_in_encoding =
hdmi->plat_data->input_bus_encoding;
else
hdmi->hdmi_data.enc_in_encoding = V4L2_YCBCR_ENC_DEFAULT;
/* TOFIX: Default to RGB888 output format */
- hdmi->hdmi_data.enc_out_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+ if (hdmi->plat_data->get_output_bus_format)
+ hdmi->hdmi_data.enc_out_bus_format =
+ hdmi->plat_data->get_output_bus_format(data);
+ else
+ hdmi->hdmi_data.enc_out_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
hdmi->hdmi_data.pix_repet_factor = 0;
hdmi->hdmi_data.hdcp_enable = 0;
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 7a02744ce0bc..2e797f782c51 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -142,6 +142,11 @@ struct dw_hdmi_plat_data {
int (*configure_phy)(struct dw_hdmi *hdmi,
const struct dw_hdmi_plat_data *pdata,
unsigned long mpixelclock);
+
+ unsigned long (*get_input_bus_format)(void *data);
+ unsigned long (*get_output_bus_format)(void *data);
+ unsigned long (*get_enc_in_encoding)(void *data);
+ unsigned long (*get_enc_out_encoding)(void *data);
};
struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8] drm/meson: Add YUV420 output support
This patch adds support for the YUV420 output from the Amlogic Meson SoCs
Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixel stream to a YUV420
stream.
In addition if pixel stream down-sampling, the Y Cb Cr components must
also be mapped differently to align with the HDMI2.0 specifications.
This mode needs a different clock generation scheme since the TMDS PHY
clock must match the 10x ration with the YUV420 pixel clock, but
the video encoder must run at 2x the pixel clock.
This patch adds the TMDS PHY clock value in all the video clock setup
in order to better support these specific uses cases and switch
to the Common Clock framework for clocks handling in the future.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 110
drivers/gpu/drm/meson/meson_vclk.c | 93 +++-
drivers/gpu/drm/meson/meson_vclk.h | 7 +-
drivers/gpu/drm/meson/meson_venc.c | 6 +-
drivers/gpu/drm/meson/meson_venc.h | 11 +++
drivers/gpu/drm/meson/meson_venc_cvbs.c | 3 +-
6 files changed, 184 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 3d8decb77019..068b56a991b5 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -141,6 +141,8 @@ struct meson_dw_hdmi {
struct regulator *hdmi_supply;
u32 irq_stat;
struct dw_hdmi *hdmi;
+ unsigned long input_bus_format;
+ unsigned long output_bus_format;
};
#define encoder_to_meson_dw_hdmi(x) \
container_of(x, struct meson_dw_hdmi, encoder)
@@ -323,25 +325,36 @@ static void dw_hdmi_set_vclk(struct meson_dw_hdmi
*dw_hdmi,
{
struct meson_drm *priv = dw_hdmi->priv;
int vic = drm_match_cea_mode(mode);
+ unsigned int phy_freq;
unsigned int vclk_freq;
unsigned int venc_freq;
unsigned int hdmi_freq;
vclk_freq = mode->clock;
+ /* For 420, pixel clock is half unlike venc clock */
+ if (dw_hdmi->input_bus_format == MEDIA_BUS_FMT_UYYVYY8_0_5X24)
+ vclk_freq /= 2;
+
+ /* TMDS clock is pixel_clock * 10 */
+ phy_freq = vclk_freq * 10;
+
if (!vic) {
- meson_vclk_setup(priv, MESON_VCLK_TARGET_DMT, vclk_freq,
-vclk_freq, vclk_freq, false);
+ meson_vclk_setup(priv, MESON_VCLK_TARGET_DMT, phy_freq,
+vclk_freq, vclk_freq, vclk_freq, false);
return;
}
+ /* 480i/576i needs global pixel doubling */
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
vclk_freq *= 2;
venc_freq = vclk_freq;
hdmi_freq = vclk_freq;
- if (meson_venc_hdmi_venc_repeat(vic))
+ /* VENC double pixels for 1080i, 720p and YUV420 modes */
+ if (meson_venc_hdmi_venc_repeat(vic) ||
+ dw_hdmi->input_bus_format == MEDIA_BUS_FMT_UYYVYY8_0_5X24)
venc_freq *= 2;
vclk_freq = max(venc_freq, hdmi_freq);
@@ -349,11 +362,11 @@ static void dw_hdmi_set_vclk(struct meson_dw_hdmi
*dw_hdmi,
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
venc_freq /= 2;
- DRM_DEBUG_DRIVER("vclk:%d venc=%d hdmi=%d enci=%d\n",
- vclk_freq, venc_freq, hdmi_freq,
+ DRM_DEBUG_DRIVER("vclk:%d phy=%d venc=%d hdmi=%d enci=%d\n",
+ phy_freq, vclk_freq, venc_freq, hdmi_freq,
priv->venc.hdmi_use_enci);
- meson_vclk_setup(priv, MESON_VCLK_TARGET_HDMI, vclk_freq,
+ meson_vclk_setup(priv, MESON_VCLK_TARGET_HDMI, phy_freq, vclk_freq,
venc_freq, hdmi_freq, priv->venc.hdmi_use_enci);
}
@@ -386,8 +399,9 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
*data,
/* Enable normal output to PHY */
dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_BIST_CNTL, BIT(12));
- /* TMDS pattern setup (TOFIX Handle the YUV420 case) */
- if (mode->clock > 34) {
+ /* TMDS pattern setup */
+ if (mode->clock > 34 &&
+ dw_hdmi->input_bus_format == MEDIA_BUS_FMT_YUV8_1X24) {
dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0);
dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
0x03ff03ff);
@@ -560,6 +574,8 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
const struct drm_display_mode *mode)
{
struct meson_drm *priv = connector->dev->dev_private;
+ bool is_hdmi2_sink = connector->display_info.hdmi.scdc.supported;
+ unsigned int phy_freq;
unsigned int vclk_freq;
unsigned int venc_freq;
unsigned int hdmi_freq;
@@ -573,8 +589,10 @@ dw_hdmi_mode_valid(struct drm_c
[PATCH 8/8] drm/meson: Output in YUV444 if sink supports it
With the YUV420 handling, we can dynamically setup the HDMI output
pixel format depending on the mode and connector info.
So now, we can output in YUV444, which is the native video pipeline
format, directly to the HDMI Sink if it's supported without
necessarily involving the HDMI Controller CSC.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 068b56a991b5..413575b5c3a0 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -669,7 +669,10 @@ static int meson_venc_hdmi_encoder_atomic_check(struct
drm_encoder *encoder,
dw_hdmi->output_bus_format = MEDIA_BUS_FMT_UYYVYY8_0_5X24;
} else {
dw_hdmi->input_bus_format = MEDIA_BUS_FMT_YUV8_1X24;
- dw_hdmi->output_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+ if (info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+ dw_hdmi->output_bus_format = MEDIA_BUS_FMT_YUV8_1X24;
+ else
+ dw_hdmi->output_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
}
return 0;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] drm/meson: Add support for HDMI2.0 4k60
This patchset aims to add support for the following HDMI2.0 4k60 modes: - 594Mhz TMDS frequency needing TMDS Scramling and 1/40 rate for RGB/YUV4:4:4 - 297MHz TMDS frequency with YUV4:2:0 encoding The first mode uses the SCDC helpers introduced by intel to : - discover where the monitor support SCDC - setup the SCDC parameters This is implemented in the dw-hdmi bridge driver by handling scrambling support during the bridge setup and by exporting an helper for the PHY setup to setup the SCDC configuration for the 1/40 TMDS rate. This code will only be active if the encoder support a TMDS rate > 340MHz. This patch could eventually break support on different SoC when connected on a 4k60 monitor with SCDC : - i.MX correctly discards pixel clocks > 216MHz - R-CAR discards discards pixel clocks > 297MHz since [1] - Rockchip discards invalid pixel clocks not in the rockchip_mpll_cfg table - sun8i correctly discards pixel clocks > 297MHz on a83t - sun8i discards discards pixel clocks > 594Mhz on h6, which is already broken First patch should fix support for Allwinner H6. The second mode is implemented by added the missing 4:2:0 bypass handling in the dw-hdmi bridge driver and adding a "mtmdsclock" separating the pixel clock from the tmds clock in the mode setup phase. We also enable support for these modes in the connector only if the platform glue code explicits the support. Only the meson DRM dw_hdmi glue allows ycbcr420 modes, so no breakage is expected here. The remaining patches adds support for : - 1/40 TMDS rate aka DIV40 in the dw-hdmi meson PHY setup - 4:2:0 output and clock setup The dw-hdmi support re-uses the support done by Rockchip engineers on the Linux 4.4 BSP kernel. These modes has been validated using a MuxLab HDMI Signal Analyser in addition to different UHD TVs supporting full 4k60 or the 4:2:0 variant. Changes since RFC v2 at [3]: - Collected tested-by and reviewed-by tags - Changed if condition in "add HDMI div40 TMDS mode" - Updated "Add YUV420 output support" with the same if condition Changes since RFC v1 at [2]: - Fix all comments from Laurent : - Add define for HDMI 1.4 max tmds clock and SCDC supported version - Call dw_hdmi_set_high_tmds_clock_ratio() in dw_hdmi_phy_enable_powerdown() to unbreak Allwinner H6 - Pass in_t(u8, bytes, SCDC_MIN_SOURCE_VERSION) as SCDC version - Finally add comments for SCDC and Scrambling process [1] https://patchwork.freedesktop.org/patch/263616/ [2] https://patchwork.freedesktop.org/series/52950/#rev1 [3] https://patchwork.freedesktop.org/series/52950/#rev2 Neil Armstrong (7): drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support drm/meson: add HDMI div40 TMDS mode drm/meson: add support for HDMI2.0 2160p modes drm/bridge: dw-hdmi: add support for YUV420 output drm/bridge: dw-hdmi: allow ycbcr420 modes for >= 0x200a drm/meson: Add YUV420 output support drm/meson: Output in YUV444 if sink supports it Zheng Yang (1): drm/bridge: dw-hdmi: support dynamically get input/out color info drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 182 +++--- drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 + drivers/gpu/drm/meson/meson_dw_hdmi.c | 128 --- drivers/gpu/drm/meson/meson_vclk.c| 93 --- drivers/gpu/drm/meson/meson_vclk.h| 7 +- drivers/gpu/drm/meson/meson_venc.c| 8 +- drivers/gpu/drm/meson/meson_venc.h| 11 ++ drivers/gpu/drm/meson/meson_venc_cvbs.c | 3 +- include/drm/bridge/dw_hdmi.h | 7 + 9 files changed, 374 insertions(+), 66 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/8] drm/meson: add HDMI div40 TMDS mode
Add support for TMDS Clock > 3.4GHz for HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 807111ebfdd9..3d8decb77019 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -365,7 +365,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
*data,
unsigned int wr_clk =
readl_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING));
- DRM_DEBUG_DRIVER("%d:\"%s\"\n", mode->base.id, mode->name);
+ DRM_DEBUG_DRIVER("%d:\"%s\" div%d\n", mode->base.id, mode->name,
+mode->clock > 34 ? 40 : 10);
/* Enable clocks */
regmap_update_bits(priv->hhi, HHI_HDMI_CLK_CNTL, 0x, 0x100);
@@ -385,9 +386,17 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
*data,
/* Enable normal output to PHY */
dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_BIST_CNTL, BIT(12));
- /* TMDS pattern setup (TOFIX pattern for 4k2k scrambling) */
- dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0x001f001f);
- dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23, 0x001f001f);
+ /* TMDS pattern setup (TOFIX Handle the YUV420 case) */
+ if (mode->clock > 34) {
+ dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0);
+ dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
+ 0x03ff03ff);
+ } else {
+ dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01,
+ 0x001f001f);
+ dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
+ 0x001f001f);
+ }
/* Load TMDS pattern */
dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_CNTL, 0x1);
@@ -413,6 +422,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
*data,
/* Disable clock, fifo, fifo_wr */
regmap_update_bits(priv->hhi, HHI_HDMI_PHY_CNTL1, 0xf, 0);
+ dw_hdmi_set_high_tmds_clock_ratio(hdmi);
+
msleep(100);
/* Reset PHY 3 times in a row */
@@ -562,6 +573,10 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
mode->vdisplay, mode->vsync_start,
mode->vsync_end, mode->vtotal, mode->type, mode->flags);
+ /* If sink max TMDS clock, we reject the mode */
+ if (mode->clock > connector->display_info.max_tmds_clock)
+ return MODE_BAD;
+
/* Check against non-VIC supported modes */
if (!vic) {
status = meson_venc_hdmi_supported_mode(mode);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drm/bridge: dw-hdmi: allow ycbcr420 modes for >= 0x200a
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
for these modes in the connector if the platform supports them.
We limit these modes to DW-HDMI IP version >= 0x200a which
are designed to support HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
Tested-by: Heiko Stuebner
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 ++
include/drm/bridge/dw_hdmi.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bd564ffdf18b..b6987d97f892 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2612,6 +2612,12 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (hdmi->phy.ops->setup_hpd)
hdmi->phy.ops->setup_hpd(hdmi, hdmi->phy.data);
+ if (hdmi->version >= 0x200a)
+ hdmi->connector.ycbcr_420_allowed =
+ hdmi->plat_data->ycbcr_420_allowed;
+ else
+ hdmi->connector.ycbcr_420_allowed = false;
+
memset(&pdevinfo, 0, sizeof(pdevinfo));
pdevinfo.parent = dev;
pdevinfo.id = PLATFORM_DEVID_AUTO;
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 2e797f782c51..3768265d7a5f 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -128,6 +128,7 @@ struct dw_hdmi_plat_data {
const struct drm_display_mode *mode);
unsigned long input_bus_format;
unsigned long input_bus_encoding;
+ bool ycbcr_420_allowed;
/* Vendor PHY support */
const struct dw_hdmi_phy_ops *phy_ops;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Split out drm_probe_helper.h
On 15/01/2019 11:41, Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. > > v2: Make it compile. There was so much compile fail on arm drivers > that I figured I'll better not include any of the acks on v1. > > v3: Massive rebase because i915 has lost a lot of drmP.h includes, but > not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h > there was still one, which this patch largely removes. Which means > rolling out lots more includes all over. > > This will also conflict with ongoing drmP.h cleanup by others I > expect. > > v3: Rebase on top of atomic bochs. > > Cc: Sam Ravnborg > Cc: Jani Nikula > Cc: Laurent Pinchart > Acked-by: Rodrigo Vivi (v2) > Acked-by: Benjamin Gaignard (v2) > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: etna...@lists.freedesktop.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-...@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-te...@vger.kernel.org > Cc: xen-de...@lists.xen.org > --- > Merging this is going to be a bit a mess due to all the ongoing drmP.h > cleanups. I think the following should work: > - Apply Sam's prep patches for removing drmP.h from > drm_modeset_helper.h > - Get the i915 drmP.h cleanup backmerged into drm-misc-next > - Apply this patch. > - Apply Sam's patch to remove drmP.h from drm_modeset_helper.h > - All through drm-misc-next, which has some potential for trivial > conflicts around #includes with other drivers unfortunately. > > I hope there's no other driver who'll blow up accidentally because > someone else is doing a drmP.h cleanup. Laurent maybe? > > Jani, ack on this? > -Daniel > --- > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- > .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_mw.c | 2 +- > drivers/gpu/drm/armada/armada_510.c | 2 +- > drivers/gpu/drm/armada/armada_crtc.c | 2 +- > drivers/gpu/drm/armada/armada_crtc.h | 2 + > drivers/gpu/drm/armada/armada_drv.c | 2 +- > drivers/gpu/drm/armada/armada_fb.c| 2 +- > drivers/gpu/drm/ast/ast_drv.c | 1 + > drivers/gpu/drm/ast/ast_mode.c| 1 + > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- > drivers/gpu/drm/bochs/bochs_drv.c | 1 + > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > drivers/gpu/drm/bridge/adv7511/adv7511.h | 5 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 2 +- > .../drm/bridge/analogix/analogix_dp_core.c| 2 +- > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > drivers/gpu/drm/bridge/panel.c| 2 +- > drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- > drivers/gpu/drm/bridge/sii902x.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > drivers/gpu/drm/bridge/tc358764.c | 2 +- > drivers/gpu/drm/bridge/tc358767.c | 2 +- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + > drivers/gpu/drm/drm_atomic_helper.c | 1 - > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > drivers/gpu/
