Re: [PATCH] drm/panel: st7701: Swap vertical front and back porch timings
On Mon, May 13, 2019 at 12:18:27AM +0530, Jagan Teki wrote: > Vertical front and back porch values on existing driver are swapped. > The existing timings are still working as expected, but to make sure > it can compatible with techstar ts8550b bsp timings this patch swap > the same values. > > Signed-off-by: Jagan Teki Thanks, applied. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RE-RESEND 1/2] drm/panel: Add support for Armadeus ST0700 Adapt
On Tue, May 07, 2019 at 05:27:12PM +0200, Sébastien Szymanski wrote: > This patch adds support for the Armadeus ST0700 Adapt. It comes with a > Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so > that it can be connected on the TFT header of Armadeus Dev boards. > > Cc: sta...@vger.kernel.org # v4.19 > Reviewed-by: Rob Herring > Signed-off-by: Sébastien Szymanski Thanks, applied. Only patch 1/2 applied, as patch 2/2 is missing review. Sam
Re: [PATCH v4 2/2] drm/panel: simple: Add KOE tx14d24vm1bpa display support (320x240)
On Wed, May 15, 2019 at 06:06:12PM +0200, Lukasz Majewski wrote: > This commit adds support for KOE's 5.7" display. > > Signed-off-by: Lukasz Majewski > Reviewed-by: Rob Herring Thanks, applied. Sam
Re: [PATCH v4 1/2] dt-bindings: display/panel: Add KOE tx14d24vm1bpa display description
On Wed, May 15, 2019 at 06:04:28PM +0200, Lukasz Majewski wrote: > This commit adds documentation entry description for KOE's 5.7" display. > > Signed-off-by: Lukasz Majewski Thanks, applied Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/vmwgfx: remove custom ioctl io encoding check
Hi, Emil On Fri, 2019-05-24 at 16:26 +0100, Emil Velikov wrote: > On 2019/05/24, Thomas Hellstrom wrote: > > On Fri, 2019-05-24 at 13:14 +0100, Emil Velikov wrote: > > > On 2019/05/23, Thomas Hellstrom wrote: > > > > Hi, Emil, > > > > > > > > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote: > > > > > From: Emil Velikov > > > > > > > > > > Drop the custom ioctl io encoding check - core drm does it > > > > > for > > > > > us. > > > > > > > > I fail to see where the core does this, or do I miss something? > > > > > > drm_ioctl() allows for the encoding to be changed and attributes > > > that > > > only the > > > appropriate size is copied in/out of the kernel. > > > > > > Technically the function is more relaxed relative to the vmwgfx > > > check, yet > > > seems perfectly reasonable. > > > > > > Is there any corner-case that isn't but should be handled in > > > drm_ioctl()? > > > > I'd like to turn the question around and ask whether there's a > > reason > > we should relax the vmwgfx test? In the past it has trapped quite a > > few > > user-space errors. > > > The way I see it either: > - the check, as-is, is unnessesary, or > - it is needed, and we should do something equivalent for all of DRM > > We had a very long brainstorming session with a colleague and we > could not see > any cases where this would cause a problem. If you recall anything > concrete > please let me know - I would be more than happy to take a closer > look. If you have a good reason to drop an ioctl sanity check, I'd be perfectly happy to do it. To me, a good reason even includes "I have a non-open-source customer having problems with this check" because of reason etc. etc. as long as I have a way to evaluate those reasons and determine if they're valid or not. "No other drm driver nor the core is doing this" is NOT a valid reason to me. In particular if the check is not affecting performance. So unless you provide additional reasons to drop this check, it's a solid NAK from my side. Thanks, Thomas > > Thanks > Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/msm/dpu: Use provided drm_minor to initialize debugfs
On Fri, May 24, 2019 at 1:43 PM Stephen Boyd wrote: > > Quoting Sean Paul (2019-05-24 10:32:18) > > From: Sean Paul > > > > Instead of reaching into dev->primary for debugfs_root, use the minor > > passed into debugfs_init. > > > > This avoids creating the debug directory under /sys/kernel/debug/ and > > instead creates the directory under the correct node in > > /sys/kernel/debug/dri// > > So does this make it become /sys/kernel/debug/dri//debug? > > I wonder why it can't all be created under /sys/kernel/debug/dri/ > and then avoid the extra "debug" directory that isn't adding any value? > From the looks of it, it will still create the 'debug' dir, but at least under the correct .. for the record, I'm all for getting rid of the extra 'debug' directory, it saves me some extra typing ;-) BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/dsi: Use a fuzzy check for burst mode clock check
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.2-rc1 next-20190524]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-i915-dsi-Use-a-fuzzy-check-for-burst-mode-clock-check/20190525-045136
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
vim +867 drivers/gpu/drm/i915/intel_dsi_vbt.c
803
804 bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id)
805 {
806 struct drm_device *dev = intel_dsi->base.base.dev;
807 struct drm_i915_private *dev_priv = to_i915(dev);
808 struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
809 struct mipi_pps_data *pps = dev_priv->vbt.dsi.pps;
810 struct drm_display_mode *mode = dev_priv->vbt.lfp_lvds_vbt_mode;
811 u16 burst_mode_ratio;
812 enum port port;
813
814 DRM_DEBUG_KMS("\n");
815
816 intel_dsi->eotp_pkt = mipi_config->eot_pkt_disabled ? 0 : 1;
817 intel_dsi->clock_stop = mipi_config->enable_clk_stop ? 1 : 0;
818 intel_dsi->lane_count = mipi_config->lane_cnt + 1;
819 intel_dsi->pixel_format =
820 pixel_format_from_register_bits(
821 mipi_config->videomode_color_format <<
7);
822
823 intel_dsi->dual_link = mipi_config->dual_link;
824 intel_dsi->pixel_overlap = mipi_config->pixel_overlap;
825 intel_dsi->operation_mode = mipi_config->is_cmd_mode;
826 intel_dsi->video_mode_format = mipi_config->video_transfer_mode;
827 intel_dsi->escape_clk_div = mipi_config->byte_clk_sel;
828 intel_dsi->lp_rx_timeout = mipi_config->lp_rx_timeout;
829 intel_dsi->hs_tx_timeout = mipi_config->hs_tx_timeout;
830 intel_dsi->turn_arnd_val = mipi_config->turn_around_timeout;
831 intel_dsi->rst_timer_val = mipi_config->device_reset_timer;
832 intel_dsi->init_count = mipi_config->master_init_timer;
833 intel_dsi->bw_timer = mipi_config->dbi_bw_timer;
834 intel_dsi->video_frmt_cfg_bits =
835 mipi_config->bta_enabled ? DISABLE_VIDEO_BTA : 0;
836 intel_dsi->bgr_enabled = mipi_config->rgb_flip;
837
838 /* Starting point, adjusted depending on dual link and burst
mode */
839 intel_dsi->pclk = mode->clock;
840
841 /* In dual link mode each port needs half of pixel clock */
842 if (intel_dsi->dual_link) {
843 intel_dsi->pclk /= 2;
844
845 /* we can enable pixel_overlap if needed by panel. In
this
846 * case we need to increase the pixelclock for extra
pixels
847 */
848 if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK) {
849 intel_dsi->pclk += DIV_ROUND_UP(mode->vtotal *
intel_dsi->pixel_overlap * 60, 1000);
850 }
851 }
852
853 /* Burst Mode Ratio
854 * Target ddr frequency from VBT / non burst ddr freq
855 * multiply by 100 to preserve remainder
856 */
857 if (intel_dsi->video_mode_format == VIDEO_MODE_BURST) {
858 if (mipi_config->target_burst_mode_freq) {
859 u32 bitrate = intel_dsi_bitrate(intel_dsi);
860
861 /*
862 * Sometimes the VBT contains a slightly lower
clock,
863 * then the bitrate we have calculated, in this
case
864 * just replace it with the calculated bitrate.
865 */
866 if (mipi_config->target_burst_mode_freq <
bitrate &&
> 867 intel_fuzzy_clock_check(
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/dsi: Use a fuzzy check for burst mode clock check
Hi Hans,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v5.2-rc1 next-20190524]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-i915-dsi-Use-a-fuzzy-check-for-burst-mode-clock-check/20190525-045136
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x001-201920 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
In file included from include/asm-generic/bug.h:5:0,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/gpio/consumer.h:5,
from drivers/gpu/drm/i915/intel_dsi_vbt.c:27:
drivers/gpu/drm/i915/intel_dsi_vbt.c: In function 'intel_dsi_vbt_init':
drivers/gpu/drm/i915/intel_dsi_vbt.c:867:8: error: implicit declaration of
function 'intel_fuzzy_clock_check'; did you mean 'intel_guc_log_create'?
[-Werror=implicit-function-declaration]
intel_fuzzy_clock_check(
^
include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu/drm/i915/intel_dsi_vbt.c:866:4: note: in expansion of macro 'if'
if (mipi_config->target_burst_mode_freq < bitrate &&
^~
cc1: some warnings being treated as errors
vim +/if +866 drivers/gpu/drm/i915/intel_dsi_vbt.c
803
804 bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id)
805 {
806 struct drm_device *dev = intel_dsi->base.base.dev;
807 struct drm_i915_private *dev_priv = to_i915(dev);
808 struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
809 struct mipi_pps_data *pps = dev_priv->vbt.dsi.pps;
810 struct drm_display_mode *mode = dev_priv->vbt.lfp_lvds_vbt_mode;
811 u16 burst_mode_ratio;
812 enum port port;
813
814 DRM_DEBUG_KMS("\n");
815
816 intel_dsi->eotp_pkt = mipi_config->eot_pkt_disabled ? 0 : 1;
817 intel_dsi->clock_stop = mipi_config->enable_clk_stop ? 1 : 0;
818 intel_dsi->lane_count = mipi_config->lane_cnt + 1;
819 intel_dsi->pixel_format =
820 pixel_format_from_register_bits(
821 mipi_config->videomode_color_format <<
7);
822
823 intel_dsi->dual_link = mipi_config->dual_link;
824 intel_dsi->pixel_overlap = mipi_config->pixel_overlap;
825 intel_dsi->operation_mode = mipi_config->is_cmd_mode;
826 intel_dsi->video_mode_format = mipi_config->video_transfer_mode;
827 intel_dsi->escape_clk_div = mipi_config->byte_clk_sel;
828 intel_dsi->lp_rx_timeout = mipi_config->lp_rx_timeout;
829 intel_dsi->hs_tx_timeout = mipi_config->hs_tx_timeout;
830 intel_dsi->turn_arnd_val = mipi_config->turn_around_timeout;
831 intel_dsi->rst_timer_val = mipi_config->device_reset_timer;
832 intel_dsi->init_count = mipi_config->master_init_timer;
833 intel_dsi->bw_timer = mipi_config->dbi_bw_timer;
834 intel_dsi->video_frmt_cfg_bits =
835 mipi_config->bta_enabled ? DISABLE_VIDEO_BTA : 0;
836 intel_dsi->bgr_enabled = mipi_config->rgb_flip;
837
838 /* Starting point, adjusted depending on dual link and burst
mode */
839 intel_dsi->pclk = mode->clock;
840
841 /* In dual link mode each port needs half of pixel clock */
842 if (intel_dsi->dual_link) {
843 intel_dsi->pclk /= 2;
844
845 /* we can enable pixel_overlap if needed by panel. In
this
846 * case we need to increase the pixelclock for extra
pixels
847 */
848 if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK) {
849 intel_dsi->pclk += DIV_ROUND_UP(mode->vtotal *
intel_dsi->pixel_overlap * 60, 1000);
850 }
851 }
852
853 /* Burst Mode Ratio
854 * Target ddr frequency from VBT / non burst ddr freq
855 * multiply by 100 to preserve remainder
856 */
857 if (intel_dsi->v
Re: [PATCH v4 1/2] dt-bindings: display/panel: Add KOE tx14d24vm1bpa display description
On Wed, 15 May 2019 18:04:28 +0200, Lukasz Majewski wrote: > This commit adds documentation entry description for KOE's 5.7" display. > > Signed-off-by: Lukasz Majewski > > --- > Previous discussion (and Rob's Reviewed-by) about this patch > https://patchwork.kernel.org/patch/10339595/ > > Changes for v4: > - Rebase on top of newest mainline > SHA1: 5ac94332248ee017964ba368cdda4ce647e3aba7 > > Changes for v3 : > - New patch > --- > .../bindings/display/panel/koe,tx14d24vm1bpa.txt | 42 > ++ > 1 file changed, 42 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/6] dt-bindings: display: hdmi-connector: Support DDC bus enable
On Tue, 21 May 2019 01:50:07 +0200, meg...@megous.com wrote: > From: Ondrej Jirman > > Some Allwinner SoC using boards (Orange Pi 3 for example) need to enable > on-board voltage shifting logic for the DDC bus using a gpio to be able > to access DDC bus. Use ddc-en-gpios property on the hdmi-connector to > model this. > > Add binding documentation for optional ddc-en-gpios property. > > Signed-off-by: Ondrej Jirman > --- > .../devicetree/bindings/display/connector/hdmi-connector.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][next] drm/i915/gtt: set err to -ENOMEM on memory allocation failure
Quoting Colin King (2019-05-24 22:26:27)
> From: Colin Ian King
>
> Currently when the allocation of ppgtt->work fails the error return
> path via err_free returns an uninitialized value in err. Fix this
> by setting err to the appropriate error return of -ENOMEM.
>
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: d3622099c76f ("drm/i915/gtt: Always acquire struct_mutex for
> gen6_ppgtt_cleanup")
> Signed-off-by: Colin Ian King
Saw that last night but got distracted by the panic-on-boot...
Reviewed-by: Chris Wilson
-Chris
Re: [PATCH 10/10] drm/amdgpu: stop removing BOs from the LRU v3
On 2019-05-23 5:06 a.m., Christian König wrote:
> [CAUTION: External Email]
>
> Leaving BOs on the LRU is harmless. We always did this for VM page table
> and per VM BOs.
>
> The key point is that BOs which couldn't be reserved can't be evicted.
> So what happened is that an application used basically all of VRAM
> during CS and because of this X server couldn't pin a BO for scanout.
>
> Now we keep the BOs on the LRU and modify TTM to block for the CS to
> complete, which in turn allows the X server to pin its BO for scanout.
OK, let me rephrase that to make sure I understand it correctly. I think
the point is that eviction candidates come from an LRU list, so leaving
things on the LRU makes more BOs available for eviction and avoids OOM
situations. To take advantage of that, patch 6 adds the ability to wait
for reserved BOs when there is nothing easier to evict.
ROCm applications like to use lots of memory. So it probably makes sense
for us to stop removing our BOs from the LRU as well while we
mass-validate our BOs in amdgpu_amdkfd_gpuvm_restore_process_bos.
Regards,
Felix
>
> Christian.
>
> Am 22.05.19 um 21:43 schrieb Kuehling, Felix:
>> Can you explain how this avoids OOM situations? When is it safe to leave
>> a reserved BO on the LRU list? Could we do the same thing in
>> amdgpu_amdkfd_gpuvm.c? And if we did, what would be the expected side
>> effects or consequences?
>>
>> Thanks,
>> Felix
>>
>> On 2019-05-22 8:59 a.m., Christian König wrote:
>>> [CAUTION: External Email]
>>>
>>> This avoids OOM situations when we have lots of threads
>>> submitting at the same time.
>>>
>>> v3: apply this to the whole driver, not just CS
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 2 +-
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 ++--
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
>>> 4 files changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>> index 20f2955d2a55..3e2da24cd17a 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>> @@ -648,7 +648,7 @@ static int amdgpu_cs_parser_bos(struct
>>> amdgpu_cs_parser *p,
>>> }
>>>
>>> r = ttm_eu_reserve_buffers(&p->ticket, &p->validated, true,
>>> - &duplicates, true);
>>> + &duplicates, false);
>>> if (unlikely(r != 0)) {
>>> if (r != -ERESTARTSYS)
>>> DRM_ERROR("ttm_eu_reserve_buffers
>>> failed.\n");
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
>>> index 06f83cac0d3a..f660628e6af9 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
>>> @@ -79,7 +79,7 @@ int amdgpu_map_static_csa(struct amdgpu_device
>>> *adev, struct amdgpu_vm *vm,
>>> list_add(&csa_tv.head, &list);
>>> amdgpu_vm_get_pd_bo(vm, &list, &pd);
>>>
>>> - r = ttm_eu_reserve_buffers(&ticket, &list, true, NULL, true);
>>> + r = ttm_eu_reserve_buffers(&ticket, &list, true, NULL, false);
>>> if (r) {
>>> DRM_ERROR("failed to reserve CSA,PD BOs:
>>> err=%d\n", r);
>>> return r;
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> index d513a5ad03dd..ed25a4e14404 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> @@ -171,7 +171,7 @@ void amdgpu_gem_object_close(struct
>>> drm_gem_object *obj,
>>>
>>> amdgpu_vm_get_pd_bo(vm, &list, &vm_pd);
>>>
>>> - r = ttm_eu_reserve_buffers(&ticket, &list, false,
>>> &duplicates, true);
>>> + r = ttm_eu_reserve_buffers(&ticket, &list, false,
>>> &duplicates, false);
>>> if (r) {
>>> dev_err(adev->dev, "leaking bo va because "
>>> "we fail to reserve bo (%d)\n", r);
>>> @@ -608,7 +608,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev,
>>> void *data,
>>>
>>> amdgpu_vm_get_pd_bo(&fpriv->vm, &list, &vm_pd);
>>>
>>> - r = ttm_eu_reserve_buffers(&ticket, &list, true,
>>> &duplicates, true);
>>> + r = ttm_eu_reserve_buffers(&ticket, &list, true,
>>> &duplicates, false);
>>> if (r)
>>> goto error_unref;
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>>> index c430e8259038..d60593cc436e 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>>> @@ -155,7 +155,7 @@ static inline int amdgpu_bo_reserve(struct
>>> amdgpu_bo *bo, bool no_intr)
>>> struct amdgpu_device *adev = amdgpu_
[PATCH][next] drm/i915/gtt: set err to -ENOMEM on memory allocation failure
From: Colin Ian King
Currently when the allocation of ppgtt->work fails the error return
path via err_free returns an uninitialized value in err. Fix this
by setting err to the appropriate error return of -ENOMEM.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: d3622099c76f ("drm/i915/gtt: Always acquire struct_mutex for
gen6_ppgtt_cleanup")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8d8a4b0ad4d9..8a9b506387d4 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2035,8 +2035,10 @@ static struct i915_hw_ppgtt *gen6_ppgtt_create(struct
drm_i915_private *i915)
ppgtt->base.vm.pte_encode = ggtt->vm.pte_encode;
ppgtt->work = kmalloc(sizeof(*ppgtt->work), GFP_KERNEL);
- if (!ppgtt->work)
+ if (!ppgtt->work) {
+ err = -ENOMEM;
goto err_free;
+ }
err = gen6_ppgtt_init_scratch(ppgtt);
if (err)
--
2.20.1
[PATCH] drm/msm: Re-order uninit function to work during probe defer
From: Sean Paul
If bind fails, we can call msm_drm_uninit before kms elements have been
created. In this case, drm_atomic_helper_shutdown will fail since there
are no drm objects. Only call drm unregistration and shutdown if drm is
registered.
Also while we're in here move the workqueue destruction to below
component_unbind since components could be actively using the wq during
uninit or in their unbind routine.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/msm_drv.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 31deb87abfc6..9f16a995ed42 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -259,13 +259,24 @@ static int msm_drm_uninit(struct device *dev)
struct msm_mdss *mdss = priv->mdss;
int i;
+ /*
+* Shutdown the hw if we're far enough along where things might be on.
+* If we run this too early, we'll end up panicking in any variety of
+* places. Since we don't register the drm device until late in
+* msm_drm_init, drm_dev->registered is used as an indicator that the
+* shutdown will be successful.
+*/
+ if (ddev->registered) {
+ drm_dev_unregister(ddev);
+ drm_atomic_helper_shutdown(ddev);
+ }
+
/* We must cancel and cleanup any pending vblank enable/disable
* work before drm_irq_uninstall() to avoid work re-enabling an
* irq after uninstall has disabled it.
*/
flush_workqueue(priv->wq);
- destroy_workqueue(priv->wq);
/* clean up event worker threads */
for (i = 0; i < priv->num_crtcs; i++) {
@@ -279,8 +290,6 @@ static int msm_drm_uninit(struct device *dev)
drm_kms_helper_poll_fini(ddev);
- drm_dev_unregister(ddev);
-
msm_perf_debugfs_cleanup(priv);
msm_rd_debugfs_cleanup(priv);
@@ -288,7 +297,7 @@ static int msm_drm_uninit(struct device *dev)
if (fbdev && priv->fbdev)
msm_fbdev_free(ddev);
#endif
- drm_atomic_helper_shutdown(ddev);
+
drm_mode_config_cleanup(ddev);
pm_runtime_get_sync(dev);
@@ -313,6 +322,7 @@ static int msm_drm_uninit(struct device *dev)
ddev->dev_private = NULL;
drm_dev_put(ddev);
+ destroy_workqueue(priv->wq);
kfree(priv);
return 0;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/msm/dpu: Remove _dpu_debugfs_init
On 2019-05-24 10:32, Sean Paul wrote:
From: Sean Paul
Fold it into dpu_debugfs_init.
Cc: Stephen Boyd
Signed-off-by: Sean Paul
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index d77071965431..0a8c334c3a9f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -231,8 +231,9 @@ void *dpu_debugfs_create_regset32(const char
*name, umode_t mode,
regset, &dpu_fops_regset32);
}
-static int _dpu_debugfs_init(struct dpu_kms *dpu_kms, struct drm_minor
*minor)
+static int dpu_kms_debugfs_init(struct msm_kms *kms, struct drm_minor
*minor)
{
+ struct dpu_kms *dpu_kms = to_dpu_kms(kms);
void *p = dpu_hw_util_get_log_mask_ptr();
struct dentry *entry;
@@ -578,13 +579,6 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms
*dpu_kms)
return ret;
}
-#ifdef CONFIG_DEBUG_FS
-static int dpu_kms_debugfs_init(struct msm_kms *kms, struct drm_minor
*minor)
-{
- return _dpu_debugfs_init(to_dpu_kms(kms), minor);
-}
-#endif
-
static long dpu_kms_round_pixclk(struct msm_kms *kms, unsigned long
rate,
struct drm_encoder *encoder)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/msm/dpu: Use provided drm_minor to initialize debugfs
On 2019-05-24 10:32, Sean Paul wrote:
From: Sean Paul
Instead of reaching into dev->primary for debugfs_root, use the minor
passed into debugfs_init.
This avoids creating the debug directory under /sys/kernel/debug/ and
instead creates the directory under the correct node in
/sys/kernel/debug/dri//
Reported-by: Stephen Boyd
Signed-off-by: Sean Paul
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 885bf88afa3e..d77071965431 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -231,7 +231,7 @@ void *dpu_debugfs_create_regset32(const char
*name, umode_t mode,
regset, &dpu_fops_regset32);
}
-static int _dpu_debugfs_init(struct dpu_kms *dpu_kms)
+static int _dpu_debugfs_init(struct dpu_kms *dpu_kms, struct drm_minor
*minor)
{
void *p = dpu_hw_util_get_log_mask_ptr();
struct dentry *entry;
@@ -239,7 +239,7 @@ static int _dpu_debugfs_init(struct dpu_kms
*dpu_kms)
if (!p)
return -EINVAL;
- entry = debugfs_create_dir("debug",
dpu_kms->dev->primary->debugfs_root);
+ entry = debugfs_create_dir("debug", minor->debugfs_root);
if (IS_ERR_OR_NULL(entry))
return -ENODEV;
@@ -581,7 +581,7 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms
*dpu_kms)
#ifdef CONFIG_DEBUG_FS
static int dpu_kms_debugfs_init(struct msm_kms *kms, struct drm_minor
*minor)
{
- return _dpu_debugfs_init(to_dpu_kms(kms));
+ return _dpu_debugfs_init(to_dpu_kms(kms), minor);
}
#endif
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #6 from tempel.jul...@gmail.com --- Situation is unchanged with 5.3-wip. It also occurs with amdvlk instead of radv if you turn on pageflipping via UseFlipHint,1 in amdPalSettings.cfg (for incomprehensible reasons it is disabled by default and the amdvlk developers unfortunately seem to ignore user complaints regarding it). Instead of pageflipping, the issue can also be triggered with amdvlk + TearFree. Btw: There is a free demo of Hitman 2 on Steam, it might work out of the box with Steam Play/Proton. - Little off-topic: I head to re-write this entire comment because freedesktop.org servers are a nightmare. Complete migration to GitLab would be great thing. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/tegra: dc: Extend debug stats with total number of events
I found useful to know the total number of underflow events while was
working on adding support for memory bandwidth management. Currently
the debug stats are getting reset after disabling CRTC, let's account
the overall number of events that doesn't get reset.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c | 10 ++
drivers/gpu/drm/tegra/dc.h | 5 +
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 3e13948dcdcd..e537c0d4bfdd 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1477,6 +1477,11 @@ static int tegra_dc_show_stats(struct seq_file *s, void
*data)
seq_printf(s, "underflow: %lu\n", dc->stats.underflow);
seq_printf(s, "overflow: %lu\n", dc->stats.overflow);
+ seq_printf(s, "frames total: %lu\n", dc->stats.frames_total);
+ seq_printf(s, "vblank total: %lu\n", dc->stats.vblank_total);
+ seq_printf(s, "underflow total: %lu\n", dc->stats.underflow_total);
+ seq_printf(s, "overflow total: %lu\n", dc->stats.overflow_total);
+
return 0;
}
@@ -1940,6 +1945,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): frame end\n", __func__);
*/
+ dc->stats.frames_total++;
dc->stats.frames++;
}
@@ -1948,6 +1954,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
dev_dbg(dc->dev, "%s(): vertical blank\n", __func__);
*/
drm_crtc_handle_vblank(&dc->base);
+ dc->stats.vblank_total++;
dc->stats.vblank++;
}
@@ -1955,6 +1962,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): underflow\n", __func__);
*/
+ dc->stats.underflow_total++;
dc->stats.underflow++;
}
@@ -1962,11 +1970,13 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): overflow\n", __func__);
*/
+ dc->stats.overflow_total++;
dc->stats.overflow++;
}
if (status & HEAD_UF_INT) {
dev_dbg_ratelimited(dc->dev, "%s(): head underflow\n",
__func__);
+ dc->stats.underflow_total++;
dc->stats.underflow++;
}
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index 1256dfb6b2f5..ab25157c948e 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -41,6 +41,11 @@ struct tegra_dc_stats {
unsigned long vblank;
unsigned long underflow;
unsigned long overflow;
+
+ unsigned long frames_total;
+ unsigned long vblank_total;
+ unsigned long underflow_total;
+ unsigned long overflow_total;
};
struct tegra_windowgroup_soc {
--
2.21.0
[PATCH v2 0/3] Tegra DRM: Support memory bandwidth management for display
Hello, Display controllers have a need for minimum memory bandwidth in order to maintain data-stream to output at a required rate. There is a visual corruption once the requirement is violated and CRTC reset may be required in order to recover. This series adds preliminary support for the memory bandwidth management, it will become active once Memory Controller drivers will get support for the PM memory bandwidth QoS. Changelog: v2: The total size of framebuffer is now calculated more accurately for planar formats, taking into account chroma sub-sampling. Dmitry Osipenko (3): drm/tegra: dc: Tune up high priority request controls on Tegra20 drm/tegra: dc: Extend debug stats with total number of events drm/tegra: Support PM QoS memory bandwidth management drivers/gpu/drm/tegra/dc.c| 250 +- drivers/gpu/drm/tegra/dc.h| 13 ++ drivers/gpu/drm/tegra/drm.c | 18 +++ drivers/gpu/drm/tegra/plane.c | 1 + drivers/gpu/drm/tegra/plane.h | 4 +- 5 files changed, 280 insertions(+), 6 deletions(-) -- 2.21.0
[PATCH v2 1/3] drm/tegra: dc: Tune up high priority request controls on Tegra20
Tegra20 has a high priority request control that allow to configure when display's memory client should perform read requests with a higher priority (Tegra30+ uses other means). Set up the controls for a more aggressive prefetching to reliably avoid FIFO underflow on a lower memory frequency, this allow to safely drop the memory bandwidth requirement by about two times in a most popular cases (only one display active, video overlay inactive, no scaling is done). Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/dc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 079250c85733..3e13948dcdcd 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -1828,12 +1828,12 @@ static void tegra_crtc_atomic_enable(struct drm_crtc *crtc, tegra_dc_writel(dc, value, DC_CMD_INT_POLARITY); /* initialize timer */ - value = CURSOR_THRESHOLD(0) | WINDOW_A_THRESHOLD(0x20) | - WINDOW_B_THRESHOLD(0x20) | WINDOW_C_THRESHOLD(0x20); + value = CURSOR_THRESHOLD(0) | WINDOW_A_THRESHOLD(0x70) | + WINDOW_B_THRESHOLD(0x30) | WINDOW_C_THRESHOLD(0x70); tegra_dc_writel(dc, value, DC_DISP_DISP_MEM_HIGH_PRIORITY); - value = CURSOR_THRESHOLD(0) | WINDOW_A_THRESHOLD(1) | - WINDOW_B_THRESHOLD(1) | WINDOW_C_THRESHOLD(1); + value = CURSOR_THRESHOLD(0) | WINDOW_A_THRESHOLD(0) | + WINDOW_B_THRESHOLD(0) | WINDOW_C_THRESHOLD(0); tegra_dc_writel(dc, value, DC_DISP_DISP_MEM_HIGH_PRIORITY_TIMER); value = VBLANK_INT | WIN_A_UF_INT | WIN_B_UF_INT | WIN_C_UF_INT | -- 2.21.0
[PATCH v2 3/3] drm/tegra: Support PM QoS memory bandwidth management
Display controller (DC) performs isochronous memory transfers and thus
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.
The External Memory Controller drivers will provide memory bandwidth
management facility via the generic Power Management QoS API soonish.
This patch wires up the PM QoS API support for the display driver
beforehand.
Display won't have visual corruption on coming up from suspend state when
devfreq driver is active once all prerequisite bits will get upstreamed.
The devfreq reaction has a quite significant latency and it also doesn't
take into account the ISO transfers which may result in assumption about
lower memory bandwidth requirement than actually needed.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c| 232 +-
drivers/gpu/drm/tegra/dc.h| 8 ++
drivers/gpu/drm/tegra/drm.c | 18 +++
drivers/gpu/drm/tegra/plane.c | 1 +
drivers/gpu/drm/tegra/plane.h | 4 +-
5 files changed, 261 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index e537c0d4bfdd..1e0d5cf0343b 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -517,6 +517,123 @@ static void tegra_dc_setup_window(struct tegra_plane
*plane,
tegra_plane_setup_blending(plane, window);
}
+static unsigned long
+tegra_plane_memory_bandwidth(struct drm_plane_state *state,
+struct tegra_dc_window *window)
+{
+ struct tegra_plane_state *tegra_state;
+ struct drm_crtc_state *crtc_state;
+ const struct drm_format_info *fmt;
+ struct tegra_dc_window win;
+ unsigned int bpp_plane;
+ unsigned int bpp;
+ unsigned int mul;
+ unsigned int i;
+
+ if (!state->fb || !state->visible)
+ return 0;
+
+ crtc_state = drm_atomic_get_new_crtc_state(state->state, state->crtc);
+ tegra_state = to_tegra_plane_state(state);
+
+ if (!window)
+ window = &win;
+
+ window->src.w = drm_rect_width(&state->src) >> 16;
+ window->src.h = drm_rect_height(&state->src) >> 16;
+ window->dst.w = drm_rect_width(&state->dst);
+ window->dst.h = drm_rect_height(&state->dst);
+ window->tiling = tegra_state->tiling;
+
+ fmt = state->fb->format;
+
+ /*
+* Note that real memory bandwidth vary depending on format and
+* memory layout, we are not taking that into account because small
+* estimation error isn't important since bandwidth is rounded up
+* anyway.
+*/
+ for (i = 0, bpp = 0; i < fmt->num_planes; i++) {
+ bpp_plane = fmt->cpp[i] * 8;
+
+ /*
+* Sub-sampling is relevant for chroma planes only and vertical
+* readouts are not cached, hence only horizontal sub-sampling
+* matters.
+*/
+ if (i > 0)
+ bpp_plane /= fmt->hsub;
+
+ bpp += bpp_plane;
+ }
+
+ /*
+* Horizontal downscale takes extra bandwidth which roughly depends
+* on the scaled width.
+*/
+ if (window->src.w > window->dst.w)
+ mul = (window->src.w - window->dst.w) * bpp / 2048 + 1;
+ else
+ mul = 1;
+
+ /*
+* Ignore window if its width is small enough such that data-prefetch
+* FIFO will easily help to overcome temporal memory pressure. This is
+* a typical case for the cursor's plane.
+*/
+ if (mul == 1 && window->src.w * bpp <= 2048)
+ return 0;
+
+ /* mode.clock in kHz, bandwidth in Mbit/s */
+ return crtc_state->mode.clock / 1000 * bpp * mul;
+}
+
+static unsigned long
+tegra20_plane_memory_bandwidth(struct drm_plane_state *state)
+{
+ /* x2: ~50% efficiency */
+ return tegra_plane_memory_bandwidth(state, NULL) * 2;
+}
+
+static unsigned long
+tegra30_plane_memory_bandwidth(struct drm_plane_state *state)
+{
+ struct tegra_dc_window window;
+ unsigned long bandwidth;
+
+ bandwidth = tegra_plane_memory_bandwidth(state, &window);
+
+ /* x2 memory overfetch for tiled framebuffer and DDR3 */
+ if (window.tiling.mode == TEGRA_BO_TILING_MODE_TILED)
+ bandwidth *= 2;
+
+ /* x2: ~50% efficiency */
+ return bandwidth * 2;
+}
+
+static unsigned long
+tegra114_plane_memory_bandwidth(struct drm_plane_state *state)
+{
+ struct tegra_dc_window window;
+ unsigned long bandwidth;
+
+ bandwidth = tegra_plane_memory_bandwidth(state, &window);
+
+ /* x2 memory overfetch for tiled framebuffer and DDR3 */
+ if (window.tiling.mode == TEGRA_BO_TILING_MODE_TILED)
+ bandwidth *= 2;
+
+ /* 2-channel memory */
+
[Bug 109754] util_blitter_generate_mipmap: Assertion `!util_format_has_stencil(desc)' failed
https://bugs.freedesktop.org/show_bug.cgi?id=109754 --- Comment #1 from Pierre-Eric Pelloux-Prayer --- Thanks for your bug report. I've opened a merge request to fix this bug: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/946 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm_edid-load: Fix a missing-check bug in drm_load_edid_firmware()
On Fri, 24 May 2019, Gen Zhang wrote:
> In drm_load_edid_firmware(), fwstr is allocated by kstrdup(). And fwstr
> is dereferenced in the following codes. However, memory allocation
> functions such as kstrdup() may fail and returns NULL. Dereferencing
> this null pointer may cause the kernel go wrong. Thus we should check
> this kstrdup() operation.
> Further, if kstrdup() returns NULL, we should return ERR_PTR(-ENOMEM) to
> the caller site.
>
> Signed-off-by: Gen Zhang
> Reviewed-by: Jani Nikula
Pushed to drm-misc-next, thanks for the patch.
BR,
Jani.
> ---
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index a491509..a0e107a 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -290,6 +290,8 @@ struct edid *drm_load_edid_firmware(struct drm_connector
> *connector)
>* the last one found one as a fallback.
>*/
> fwstr = kstrdup(edid_firmware, GFP_KERNEL);
> + if (!fwstr)
> + return ERR_PTR(-ENOMEM);
> edidstr = fwstr;
>
> while ((edidname = strsep(&edidstr, ","))) {
> ---
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/i915: Make intel_fuzzy_clock_check available outside of intel_display.c
The next patch in this series uses intel_fuzzy_clock_check from the
vlv_dsi.c code.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5098228f1302..ceb78f44f087 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11942,7 +11942,7 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
return 0;
}
-static bool intel_fuzzy_clock_check(int clock1, int clock2)
+bool intel_fuzzy_clock_check(int clock1, int clock2)
{
int diff;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a38b9cff5cd0..e85cd377a652 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1742,6 +1742,7 @@ int vlv_force_pll_on(struct drm_i915_private *dev_priv,
enum pipe pipe,
const struct dpll *dpll);
void vlv_force_pll_off(struct drm_i915_private *dev_priv, enum pipe pipe);
int lpt_get_iclkip(struct drm_i915_private *dev_priv);
+bool intel_fuzzy_clock_check(int clock1, int clock2);
/* modesetting asserts */
void assert_panel_unlocked(struct drm_i915_private *dev_priv,
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/i915/dsi: Use a fuzzy check for burst mode clock check
Prior to this commit we fail to init the DSI panel on the GPD MicroPC:
https://www.indiegogo.com/projects/gpd-micropc-6-inch-handheld-industry-laptop#/
The problem is intel_dsi_vbt_init() failing with the following error:
*ERROR* Burst mode freq is less than computed
The pclk in the VBT panel modeline is 7, together with 24 bpp and
4 lines this results in a bitrate value of 7 * 24 / 4 = 42.
But the target_burst_mode_freq in the VBT is 418000.
This commit works around this problem by adding an intel_fuzzy_clock_check
when target_burst_mode_freq < bitrate and setting target_burst_mode_freq to
bitrate when that checks succeeds, fixing the panel not working.
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 022bf59418df..a2a9b9d0eeaa 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -895,6 +895,17 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
if (mipi_config->target_burst_mode_freq) {
u32 bitrate = intel_dsi_bitrate(intel_dsi);
+ /*
+* Sometimes the VBT contains a slightly lower clock,
+* then the bitrate we have calculated, in this case
+* just replace it with the calculated bitrate.
+*/
+ if (mipi_config->target_burst_mode_freq < bitrate &&
+ intel_fuzzy_clock_check(
+ mipi_config->target_burst_mode_freq,
+ bitrate))
+ mipi_config->target_burst_mode_freq = bitrate;
+
if (mipi_config->target_burst_mode_freq < bitrate) {
DRM_ERROR("Burst mode freq is less than
computed\n");
return false;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
Hi Dave, Daniel - First i915 feature pull for v5.3. BR, Jani. drm-intel-next-2019-05-24: Features: - Engine discovery query (Tvrtko) - Support for DP YCbCr4:2:0 outputs (Gwan-gyeong) - HDCP revocation support, refactoring (Ramalingam) - Remove DRM_AUTH from IOCTLs which also have DRM_RENDER_ALLOW (Christian König) - Asynchronous display power disabling (Imre) - Perma-pin uC firmware and re-enable global reset (Fernando) - GTT remapping for display, for bigger fb size and stride (Ville) - Enable pipe HDR mode on ICL if only HDR planes are used (Ville) - Kconfig to tweak the busyspin durations for i915_wait_request (Chris) - Allow multiple user handles to the same VM (Chris) - GT/GEM runtime pm improvements using wakerefs (Chris) - Gen 4&5 render context support (Chris) - Allow userspace to clone contexts on creation (Chris) - SINGLE_TIMELINE flags for context creation (Chris) - Allow specification of parallel execbuf (Chris) Refactoring: - Header refactoring (Jani) - Move GraphicsTechnology files under gt/ (Chris) - Sideband code refactoring (Chris) Fixes: - ICL DSI state readout and checker fixes (Vandita) - GLK DSI picture corruption fix (Stanislav) - HDMI deep color fixes (Clinton, Aditya) - Fix driver unbinding from a device in use (Janusz) - Fix clock gating with pipe scaling (Radhakrishna) - Disable broken FBC on GLK (Daniel Drake) - Miscellaneous GuC fixes (Michal) - Fix MG PHY DP register programming (Imre) - Add missing combo PHY lane power setup (Imre) - Workarounds for early ICL VBT issues (Imre) - Fix fastset vs. pfit on/off on HSW EDP transcoder (Ville) - Add readout and state check for pch_pfit.force_thru (Ville) - Miscellaneous display fixes and refactoring (Ville) - Display workaround fixes (Ville) - Enable audio even if ELD is bogus (Ville) - Fix use-after-free in reporting create.size (Chris) - Sideband fixes to avoid BYT hard lockups (Chris) - Workaround fixes and improvements (Chris) Maintainer shortcomings: - Failure to adequately describe and give credit for all changes (Jani) The following changes since commit 7c13e5cc2391950541f41fc9ab0336aae77c7f63: Merge tag 'drm-intel-next-fixes-2019-04-25' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2019-04-26 11:35:59 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2019-05-24 for you to fetch changes up to c0a74c732568ad347f7b3de281922808dab30504: drm/i915: Update DRIVER_DATE to 20190524 (2019-05-24 20:35:22 +0300) Features: - Engine discovery query (Tvrtko) - Support for DP YCbCr4:2:0 outputs (Gwan-gyeong) - HDCP revocation support, refactoring (Ramalingam) - Remove DRM_AUTH from IOCTLs which also have DRM_RENDER_ALLOW (Christian König) - Asynchronous display power disabling (Imre) - Perma-pin uC firmware and re-enable global reset (Fernando) - GTT remapping for display, for bigger fb size and stride (Ville) - Enable pipe HDR mode on ICL if only HDR planes are used (Ville) - Kconfig to tweak the busyspin durations for i915_wait_request (Chris) - Allow multiple user handles to the same VM (Chris) - GT/GEM runtime pm improvements using wakerefs (Chris) - Gen 4&5 render context support (Chris) - Allow userspace to clone contexts on creation (Chris) - SINGLE_TIMELINE flags for context creation (Chris) - Allow specification of parallel execbuf (Chris) Refactoring: - Header refactoring (Jani) - Move GraphicsTechnology files under gt/ (Chris) - Sideband code refactoring (Chris) Fixes: - ICL DSI state readout and checker fixes (Vandita) - GLK DSI picture corruption fix (Stanislav) - HDMI deep color fixes (Clinton, Aditya) - Fix driver unbinding from a device in use (Janusz) - Fix clock gating with pipe scaling (Radhakrishna) - Disable broken FBC on GLK (Daniel Drake) - Miscellaneous GuC fixes (Michal) - Fix MG PHY DP register programming (Imre) - Add missing combo PHY lane power setup (Imre) - Workarounds for early ICL VBT issues (Imre) - Fix fastset vs. pfit on/off on HSW EDP transcoder (Ville) - Add readout and state check for pch_pfit.force_thru (Ville) - Miscellaneous display fixes and refactoring (Ville) - Display workaround fixes (Ville) - Enable audio even if ELD is bogus (Ville) - Fix use-after-free in reporting create.size (Chris) - Sideband fixes to avoid BYT hard lockups (Chris) - Workaround fixes and improvements (Chris) Maintainer shortcomings: - Failure to adequately describe and give credit for all changes (Jani) Aditya Swarup (1): drm/i915/icl: Fix setting 10 bit deep color mode Chris Wilson (87): drm/i915: Verify workarounds immediately after application drm/i915: Verify the engine workarounds stick on application drm/i915: Make workaround verification *optional* drm/i915: Avoid use-after-free in reporting create.size drm/i915: Stop overwriti
Re: [git pull] drm fixes for 5.2-rc2
The pull request you sent on Fri, 24 May 2019 14:28:08 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-05-24 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c074989171801171af6c5f53dd16b27f36b31deb Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.2-rc2 (try two)
The pull request you sent on Fri, 24 May 2019 20:01:35 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-05-24-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a3b25d157d5a52ef3f9296a739ee28f5d36e8968 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm/dpu: Use provided drm_minor to initialize debugfs
From: Sean Paul
Instead of reaching into dev->primary for debugfs_root, use the minor
passed into debugfs_init.
This avoids creating the debug directory under /sys/kernel/debug/ and
instead creates the directory under the correct node in
/sys/kernel/debug/dri//
Reported-by: Stephen Boyd
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 885bf88afa3e..d77071965431 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -231,7 +231,7 @@ void *dpu_debugfs_create_regset32(const char *name, umode_t
mode,
regset, &dpu_fops_regset32);
}
-static int _dpu_debugfs_init(struct dpu_kms *dpu_kms)
+static int _dpu_debugfs_init(struct dpu_kms *dpu_kms, struct drm_minor *minor)
{
void *p = dpu_hw_util_get_log_mask_ptr();
struct dentry *entry;
@@ -239,7 +239,7 @@ static int _dpu_debugfs_init(struct dpu_kms *dpu_kms)
if (!p)
return -EINVAL;
- entry = debugfs_create_dir("debug",
dpu_kms->dev->primary->debugfs_root);
+ entry = debugfs_create_dir("debug", minor->debugfs_root);
if (IS_ERR_OR_NULL(entry))
return -ENODEV;
@@ -581,7 +581,7 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
#ifdef CONFIG_DEBUG_FS
static int dpu_kms_debugfs_init(struct msm_kms *kms, struct drm_minor *minor)
{
- return _dpu_debugfs_init(to_dpu_kms(kms));
+ return _dpu_debugfs_init(to_dpu_kms(kms), minor);
}
#endif
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/msm/dpu: Remove _dpu_debugfs_init
From: Sean Paul
Fold it into dpu_debugfs_init.
Cc: Stephen Boyd
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index d77071965431..0a8c334c3a9f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -231,8 +231,9 @@ void *dpu_debugfs_create_regset32(const char *name, umode_t
mode,
regset, &dpu_fops_regset32);
}
-static int _dpu_debugfs_init(struct dpu_kms *dpu_kms, struct drm_minor *minor)
+static int dpu_kms_debugfs_init(struct msm_kms *kms, struct drm_minor *minor)
{
+ struct dpu_kms *dpu_kms = to_dpu_kms(kms);
void *p = dpu_hw_util_get_log_mask_ptr();
struct dentry *entry;
@@ -578,13 +579,6 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
return ret;
}
-#ifdef CONFIG_DEBUG_FS
-static int dpu_kms_debugfs_init(struct msm_kms *kms, struct drm_minor *minor)
-{
- return _dpu_debugfs_init(to_dpu_kms(kms), minor);
-}
-#endif
-
static long dpu_kms_round_pixclk(struct msm_kms *kms, unsigned long rate,
struct drm_encoder *encoder)
{
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/6] Allwinner H6 Mali GPU support
On 21/05/2019 17:10, Clément Péron wrote: Hi, The Allwinner H6 has a Mali-T720 MP2 which should be supported by the new panfrost driver. This series fix two issues and introduce the dt-bindings but a simple benchmark show that it's still NOT WORKING. I'm pushing it in case someone want to continue the work. This has been tested with Mesa3D 19.1.0-RC2 and a GPU bitness patch[1]. One patch is from Icenowy Zheng where I changed the order as required by Rob Herring[2]. Thanks, Clement [1] https://gitlab.freedesktop.org/kszaq/mesa/tree/panfrost_64_32 [2] https://patchwork.kernel.org/patch/10699829/ [ 345.204813] panfrost 180.gpu: mmu irq status=1 [ 345.209617] panfrost 180.gpu: Unhandled Page fault in AS0 at VA 0x02400400 [ 345.209617] Reason: TODO [ 345.209617] raw fault status: 0x82C1 [ 345.209617] decoded fault status: SLAVE FAULT [ 345.209617] exception type 0xC1: TRANSLATION_FAULT_LEVEL1 [ 345.209617] access type 0x2: READ [ 345.209617] source id 0x8000 [ 345.729957] panfrost 180.gpu: gpu sched timeout, js=0, status=0x8, head=0x2400400, tail=0x2400400, sched_job=9e204de9 [ 346.055876] panfrost 180.gpu: mmu irq status=1 [ 346.060680] panfrost 180.gpu: Unhandled Page fault in AS0 at VA 0x02C00A00 [ 346.060680] Reason: TODO [ 346.060680] raw fault status: 0x810002C1 [ 346.060680] decoded fault status: SLAVE FAULT [ 346.060680] exception type 0xC1: TRANSLATION_FAULT_LEVEL1 [ 346.060680] access type 0x2: READ [ 346.060680] source id 0x8100 [ 346.561955] panfrost 180.gpu: gpu sched timeout, js=1, status=0x8, head=0x2c00a00, tail=0x2c00a00, sched_job=b55a9a85 [ 346.573913] panfrost 180.gpu: mmu irq status=1 [ 346.578707] panfrost 180.gpu: Unhandled Page fault in AS0 at VA 0x02C00B80 FWIW I seem to have reproduced the same behaviour on a different T720 setup, so this may well be more about the GPU than the platform. There doesn't look to be anything obviously wrong with the pagetables, but if I can find some more free time I may have a bit more of a poke around. Robin. Change in v5: - Remove fix indent Changes in v4: - Add bus_clock probe - Fix sanity check in io-pgtable - Add vramp-delay - Merge all boards into one patch - Remove upstreamed Neil A. patch Change in v3 (Thanks to Maxime Ripard): - Reauthor Icenowy for her path Changes in v2 (Thanks to Maxime Ripard): - Drop GPU OPP Table - Add clocks and clock-names in required Clément Péron (5): drm: panfrost: add optional bus_clock iommu: io-pgtable: fix sanity check for non 48-bit mali iommu dt-bindings: gpu: mali-midgard: Add H6 mali gpu compatible arm64: dts: allwinner: Add ARM Mali GPU node for H6 arm64: dts: allwinner: Add mali GPU supply for H6 boards Icenowy Zheng (1): dt-bindings: gpu: add bus clock for Mali Midgard GPUs .../bindings/gpu/arm,mali-midgard.txt | 15 - .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 6 + .../dts/allwinner/sun50i-h6-orangepi-3.dts| 6 + .../dts/allwinner/sun50i-h6-orangepi.dtsi | 6 + .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 6 + arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 14 drivers/gpu/drm/panfrost/panfrost_device.c| 22 +++ drivers/gpu/drm/panfrost/panfrost_device.h| 1 + drivers/iommu/io-pgtable-arm.c| 2 +- 9 files changed, 76 insertions(+), 2 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/mmu: use struct_size() helper
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.
So, replace the following form:
sizeof(*kind) + sizeof(*kind->data) * mmu->kind_nr;
with:
struct_size(kind, data, mmu->kind_nr)
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/nouveau/nvif/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvif/mmu.c
b/drivers/gpu/drm/nouveau/nvif/mmu.c
index ae08a1ca8044..5641bda2046d 100644
--- a/drivers/gpu/drm/nouveau/nvif/mmu.c
+++ b/drivers/gpu/drm/nouveau/nvif/mmu.c
@@ -110,7 +110,7 @@ nvif_mmu_init(struct nvif_object *parent, s32 oclass,
struct nvif_mmu *mmu)
if (mmu->kind_nr) {
struct nvif_mmu_kind_v0 *kind;
- u32 argc = sizeof(*kind) + sizeof(*kind->data) * mmu->kind_nr;
+ size_t argc = struct_size(kind, data, mmu->kind_nr);
if (ret = -ENOMEM, !(kind = kmalloc(argc, GFP_KERNEL)))
goto done;
--
2.21.0
[PATCH] drm/i915/kvmgt: Use struct_size() helper
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.
So, replace the following form:
sizeof(*sparse) + (nr_areas * sizeof(*sparse->areas)
with:
struct_size(sparse, areas, sparse->nr_areas)
and so on...
Also, notice that variable size is unnecessary, hence it is removed.
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 144301b778df..9674738b89df 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1306,7 +1306,6 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
unsigned int cmd,
unsigned int i;
int ret;
struct vfio_region_info_cap_sparse_mmap *sparse = NULL;
- size_t size;
int nr_areas = 1;
int cap_type_id;
@@ -1349,9 +1348,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
unsigned int cmd,
VFIO_REGION_INFO_FLAG_WRITE;
info.size = gvt_aperture_sz(vgpu->gvt);
- size = sizeof(*sparse) +
- (nr_areas * sizeof(*sparse->areas));
- sparse = kzalloc(size, GFP_KERNEL);
+ sparse = kzalloc(struct_size(sparse, areas, nr_areas),
+GFP_KERNEL);
if (!sparse)
return -ENOMEM;
@@ -1416,9 +1414,9 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
unsigned int cmd,
switch (cap_type_id) {
case VFIO_REGION_INFO_CAP_SPARSE_MMAP:
ret = vfio_info_add_capability(&caps,
- &sparse->header, sizeof(*sparse) +
- (sparse->nr_areas *
- sizeof(*sparse->areas)));
+ &sparse->header,
+ struct_size(sparse, areas,
+ sparse->nr_areas));
if (ret) {
kfree(sparse);
return ret;
--
2.21.0
Re: RFC: Run a dedicated hmm.git for 5.3
On Fri, May 24, 2019 at 6:53 PM Jason Gunthorpe wrote: > > On Fri, May 24, 2019 at 06:27:09PM +0200, Daniel Vetter wrote: > > Sure topic branch sounds fine, we do that all the time with various > > subsystems all over. We have ready made scripts for topic branches and > > applying pulls from all over, so we can even soak test everything in our > > integration tree. In case there's conflicts or just to make sure > > everything works, before we bake the topic branch into permanent history > > (the main drm.git repo just can't be rebased, too much going on and too > > many people involvd). > > We don't rebase rdma.git either for the same reasons and nor does > netdev > > So the usual flow for a shared topic branch is also no-rebase - > testing/etc needs to be done before things get applied to it. Rebasing before it gets baked into any tree is still ok. And for something like this we do need a test branch first, which might need a fixup patch squashed in. On the drm side we have a drm-local integration tree for this stuff (like linux-next, but without all the other stuff that's not relevant for graphics). But yeah that's just details, easy to figure out. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: Run a dedicated hmm.git for 5.3
On Fri, May 24, 2019 at 06:27:09PM +0200, Daniel Vetter wrote: > Sure topic branch sounds fine, we do that all the time with various > subsystems all over. We have ready made scripts for topic branches and > applying pulls from all over, so we can even soak test everything in our > integration tree. In case there's conflicts or just to make sure > everything works, before we bake the topic branch into permanent history > (the main drm.git repo just can't be rebased, too much going on and too > many people involvd). We don't rebase rdma.git either for the same reasons and nor does netdev So the usual flow for a shared topic branch is also no-rebase - testing/etc needs to be done before things get applied to it. Cheers, Jason
Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On Fri, 24 May 2019 19:30:45 +0300 Nikolay Borisov wrote: > > Yes I do. I corrected it in my next email. > > > > http://lkml.kernel.org/r/20190523133648.591f9...@gandalf.local.home > > Or perhaps just using is_power_of_2 from include/linux/log2.h ? Even better. Thanks, -- Steve
[PATCH resend for CI] drm/i915/dsi: Call drm_connector_cleanup on vlv_dsi_init error exit path
If we exit vlv_dsi_init() because we failed to find a fixed_mode, then
we've already called drm_connector_init() and we should call
drm_connector_cleanup() to unregister the connector object.
Reviewed-by: Ville Syrjälä
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/vlv_dsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index 7ecffd4b9f6b..fce8b58f7f93 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1817,7 +1817,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
if (!fixed_mode) {
DRM_DEBUG_KMS("no fixed mode\n");
- goto err;
+ goto err_cleanup_connector;
}
intel_panel_init(&intel_connector->panel, fixed_mode, NULL);
@@ -1827,6 +1827,8 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
return;
+err_cleanup_connector:
+ drm_connector_cleanup(&intel_connector->base);
err:
drm_encoder_cleanup(&intel_encoder->base);
kfree(intel_dsi);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On 24.05.19 г. 18:26 ч., Steven Rostedt wrote:
> On Fri, 24 May 2019 16:11:14 +0100
> Roger Willcocks wrote:
>
>> On 23/05/2019 16:27, Steven Rostedt wrote:
>>>
>>> I haven't yet tested this, but what about something like the following:
>>>
>>> ...perhaps forget about the constant check, and just force
>>> the power of two check:
>>>
>>> \
>>> if (!(__y & (__y >> 1))) { \
>>> __x = round_up(x, y); \
>>> } else {\
>>
>> You probably want
>>
>> if (!(__y & (__y - 1))
>>
>> --
>
> Yes I do. I corrected it in my next email.
>
> http://lkml.kernel.org/r/20190523133648.591f9...@gandalf.local.home
Or perhaps just using is_power_of_2 from include/linux/log2.h ?
>
>> #define roundup(x, y) ( \
>> {\
>> typeof(y) __y = y; \
>> typeof(x) __x; \
>> \
>> if (__y & (__y - 1))\
>> __x = round_up(x, __y); \
>> else\
>> __x = (((x) + (__y - 1)) / __y) * __y; \
>> __x;\
>> })
>
>
> -- Steve
>
[PATCH 3/4] drm/i915/dsi: Move vlv/icl_dphy_param_init call out of intel_dsi_vbt_init
The vlv/icl_dphy_param_init calls do various calculations to set dphy
parameters based on the pclk.
Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give
vlv_dsi_init a chance to tweak the pclk before these calculations are done.
This also removes the single "if (IS_ICELAKE(dev_priv))" check from
intel_dsi_vbt_init making it fully platform agnostic.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/icl_dsi.c | 1 +
drivers/gpu/drm/i915/intel_dsi.h | 2 ++
drivers/gpu/drm/i915/intel_dsi_vbt.c | 9 ++---
drivers/gpu/drm/i915/vlv_dsi.c | 2 ++
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 9d962ea1e635..0f43ef07efec 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1455,6 +1455,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
+ icl_dphy_param_init(intel_dsi);
return;
err:
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 705a609050c0..a58d3d988d9f 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -192,5 +192,7 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id);
void intel_dsi_vbt_exec_sequence(struct intel_dsi *intel_dsi,
enum mipi_seq seq_id);
void intel_dsi_msleep(struct intel_dsi *intel_dsi, int msec);
+void icl_dphy_param_init(struct intel_dsi *intel_dsi);
+void vlv_dphy_param_init(struct intel_dsi *intel_dsi);
#endif /* _INTEL_DSI_H */
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 3448e8d51057..022bf59418df 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -578,7 +578,7 @@ static void intel_dsi_log_params(struct intel_dsi
*intel_dsi)
#define ICL_HS_ZERO_CNT_MAX0xf
#define ICL_EXIT_ZERO_CNT_MAX 0x7
-static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
+void icl_dphy_param_init(struct intel_dsi *intel_dsi)
{
struct drm_device *dev = intel_dsi->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -677,7 +677,7 @@ static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
intel_dsi_log_params(intel_dsi);
}
-static void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
+void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
{
struct drm_device *dev = intel_dsi->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -914,11 +914,6 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
intel_dsi->burst_mode_ratio = burst_mode_ratio;
- if (INTEL_GEN(dev_priv) >= 11)
- icl_dphy_param_init(intel_dsi);
- else
- vlv_dphy_param_init(intel_dsi);
-
/* delays in VBT are in unit of 100us, so need to convert
* here in ms
* Delay (100us) * 100 /1000 = Delay / 10 (ms) */
diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index fce8b58f7f93..3329ccf3b346 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1782,6 +1782,8 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
+ vlv_dphy_param_init(intel_dsi);
+
/*
* In case of BYT with CRC PMIC, we need to use GPIO for
* Panel control.
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/i915/dsi: Move logging of DSI VBT parameters to a helper function
This is a preparation patch for moving the calling of *_dphy_param_init()
out of intel_dsi_vbt_init.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 77 +++-
1 file changed, 42 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 3074448446bc..3448e8d51057 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -532,6 +532,44 @@ void intel_dsi_msleep(struct intel_dsi *intel_dsi, int
msec)
msleep(msec);
}
+static void intel_dsi_log_params(struct intel_dsi *intel_dsi)
+{
+ DRM_DEBUG_KMS("Pclk %d\n", intel_dsi->pclk);
+ DRM_DEBUG_KMS("Pixel overlap %d\n", intel_dsi->pixel_overlap);
+ DRM_DEBUG_KMS("Lane count %d\n", intel_dsi->lane_count);
+ DRM_DEBUG_KMS("DPHY param reg 0x%x\n", intel_dsi->dphy_reg);
+ DRM_DEBUG_KMS("Video mode format %s\n",
+ intel_dsi->video_mode_format ==
VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE ?
+ "non-burst with sync pulse" :
+ intel_dsi->video_mode_format ==
VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS ?
+ "non-burst with sync events" :
+ intel_dsi->video_mode_format == VIDEO_MODE_BURST ?
+ "burst" : "");
+ DRM_DEBUG_KMS("Burst mode ratio %d\n", intel_dsi->burst_mode_ratio);
+ DRM_DEBUG_KMS("Reset timer %d\n", intel_dsi->rst_timer_val);
+ DRM_DEBUG_KMS("Eot %s\n", enableddisabled(intel_dsi->eotp_pkt));
+ DRM_DEBUG_KMS("Clockstop %s\n",
enableddisabled(!intel_dsi->clock_stop));
+ DRM_DEBUG_KMS("Mode %s\n", intel_dsi->operation_mode ? "command" :
"video");
+ if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK)
+ DRM_DEBUG_KMS("Dual link: DSI_DUAL_LINK_FRONT_BACK\n");
+ else if (intel_dsi->dual_link == DSI_DUAL_LINK_PIXEL_ALT)
+ DRM_DEBUG_KMS("Dual link: DSI_DUAL_LINK_PIXEL_ALT\n");
+ else
+ DRM_DEBUG_KMS("Dual link: NONE\n");
+ DRM_DEBUG_KMS("Pixel Format %d\n", intel_dsi->pixel_format);
+ DRM_DEBUG_KMS("TLPX %d\n", intel_dsi->escape_clk_div);
+ DRM_DEBUG_KMS("LP RX Timeout 0x%x\n", intel_dsi->lp_rx_timeout);
+ DRM_DEBUG_KMS("Turnaround Timeout 0x%x\n", intel_dsi->turn_arnd_val);
+ DRM_DEBUG_KMS("Init Count 0x%x\n", intel_dsi->init_count);
+ DRM_DEBUG_KMS("HS to LP Count 0x%x\n", intel_dsi->hs_to_lp_count);
+ DRM_DEBUG_KMS("LP Byte Clock %d\n", intel_dsi->lp_byte_clk);
+ DRM_DEBUG_KMS("DBI BW Timer 0x%x\n", intel_dsi->bw_timer);
+ DRM_DEBUG_KMS("LP to HS Clock Count 0x%x\n",
intel_dsi->clk_lp_to_hs_count);
+ DRM_DEBUG_KMS("HS to LP Clock Count 0x%x\n",
intel_dsi->clk_hs_to_lp_count);
+ DRM_DEBUG_KMS("BTA %s\n",
+ enableddisabled(!(intel_dsi->video_frmt_cfg_bits &
DISABLE_VIDEO_BTA)));
+}
+
#define ICL_PREPARE_CNT_MAX0x7
#define ICL_CLK_ZERO_CNT_MAX 0xf
#define ICL_TRAIL_CNT_MAX 0x7
@@ -635,6 +673,8 @@ static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
HS_TRAIL(trail_cnt) |
HS_EXIT_OVERRIDE |
HS_EXIT(exit_zero_cnt));
+
+ intel_dsi_log_params(intel_dsi);
}
static void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
@@ -794,6 +834,8 @@ static void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
DIV_ROUND_UP(2 * tlpx_ui + trail_cnt * 2 + 8,
8);
intel_dsi->clk_hs_to_lp_count += extra_byte_count;
+
+ intel_dsi_log_params(intel_dsi);
}
bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id)
@@ -877,41 +919,6 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
else
vlv_dphy_param_init(intel_dsi);
- DRM_DEBUG_KMS("Pclk %d\n", intel_dsi->pclk);
- DRM_DEBUG_KMS("Pixel overlap %d\n", intel_dsi->pixel_overlap);
- DRM_DEBUG_KMS("Lane count %d\n", intel_dsi->lane_count);
- DRM_DEBUG_KMS("DPHY param reg 0x%x\n", intel_dsi->dphy_reg);
- DRM_DEBUG_KMS("Video mode format %s\n",
- intel_dsi->video_mode_format ==
VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE ?
- "non-burst with sync pulse" :
- intel_dsi->video_mode_format ==
VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS ?
- "non-burst with sync events" :
- intel_dsi->video_mode_format == VIDEO_MODE_BURST ?
- "burst" : "");
- DRM_DEBUG_KMS("Burst mode ratio %d\n", intel_dsi->burst_mode_ratio);
- DRM_DEBUG_KMS("Reset timer %d\n", intel_dsi->rst_timer_val);
- DRM_DEBUG_KMS("Eot %s\n", enableddisabled(intel_dsi->eotp_pkt));
- DRM_DEBUG_KMS("Clockstop %s\n",
enableddisabled(!intel_dsi->clock_stop));
- DRM_DEBUG_KMS("Mode %s\n", intel_dsi-
[PATCH 1/4] drm/i915: Make intel_fuzzy_clock_check available outside of intel_display.c
The next patch in this series uses intel_fuzzy_clock_check from the
vlv_dsi.c code.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5098228f1302..ceb78f44f087 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11942,7 +11942,7 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
return 0;
}
-static bool intel_fuzzy_clock_check(int clock1, int clock2)
+bool intel_fuzzy_clock_check(int clock1, int clock2)
{
int diff;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a38b9cff5cd0..e85cd377a652 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1742,6 +1742,7 @@ int vlv_force_pll_on(struct drm_i915_private *dev_priv,
enum pipe pipe,
const struct dpll *dpll);
void vlv_force_pll_off(struct drm_i915_private *dev_priv, enum pipe pipe);
int lpt_get_iclkip(struct drm_i915_private *dev_priv);
+bool intel_fuzzy_clock_check(int clock1, int clock2);
/* modesetting asserts */
void assert_panel_unlocked(struct drm_i915_private *dev_priv,
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/i915/dsi: Read back pclk set by GOP and use that as pclk (v3)
The GOP sometimes initializes the pclk at a (slightly) different frequency
then the pclk which we've calculated.
This commit makes the DSI code read-back the pclk set by the GOP and
if that is within a reasonable margin of the calculated pclk, uses
that instead.
This fixes the first modeset being a full modeset instead of a
fast modeset on systems where the GOP pclk is different.
Changes in v2:
-Use intel_encoder_current_mode() to get the pclk setup by the GOP
Changes in v3:
-Back to the readback approach, skipping the dsi_pll.ctrl / .dev checks
in intel_pipe_config_compare() when adjust is set leads to:
[drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.ctrl (...)
[drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.div (...)
-Do the readback and pclk overriding from vlv_dsi_init(), rather then from
intel_dsi_vbt_init() as the vbt code should not be touching the hw
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/vlv_dsi.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index 3329ccf3b346..49975dd84ff4 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1701,7 +1701,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
struct drm_encoder *encoder;
struct intel_connector *intel_connector;
struct drm_connector *connector;
- struct drm_display_mode *fixed_mode;
+ struct drm_display_mode *current_mode, *fixed_mode;
enum port port;
DRM_DEBUG_KMS("\n");
@@ -1745,6 +1745,9 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
intel_connector->get_hw_state = intel_connector_get_hw_state;
intel_encoder->port = port;
+ intel_encoder->type = INTEL_OUTPUT_DSI;
+ intel_encoder->power_domain = POWER_DOMAIN_PORT_DSI;
+ intel_encoder->cloneable = 0;
/*
* On BYT/CHV, pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI
@@ -1782,6 +1785,20 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
+ /* Use clock read-back from current hw-state for fastboot */
+ current_mode = intel_encoder_current_mode(intel_encoder);
+ if (current_mode) {
+ DRM_DEBUG_KMS("Calculated pclk %d GOP %d\n",
+ intel_dsi->pclk, current_mode->clock);
+ if (intel_fuzzy_clock_check(intel_dsi->pclk,
+ current_mode->clock)) {
+ DRM_DEBUG_KMS("Using GOP pclk\n");
+ intel_dsi->pclk = current_mode->clock;
+ }
+
+ kfree(current_mode);
+ }
+
vlv_dphy_param_init(intel_dsi);
/*
@@ -1799,9 +1816,6 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
}
}
- intel_encoder->type = INTEL_OUTPUT_DSI;
- intel_encoder->power_domain = POWER_DOMAIN_PORT_DSI;
- intel_encoder->cloneable = 0;
drm_connector_init(dev, connector, &intel_dsi_connector_funcs,
DRM_MODE_CONNECTOR_DSI);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[[PATCH 0/4] drm/i915/dsi: Read back pclk set by GOP and use that as pclk (version 3)
Hi All, This is a resend of my 3th attempt to fix the pclk we calculate for DSI panels and the pclk which the GOP has configured, causing fastboot to not work. As requested in the review of earlier versions, this version moves the overriding of the pclk out of intel_dsi_vbt.c and into vlv_dsi.c. This series was first posted in December 2018, but has gotten 0 comments. This resend is rebased on top of 4.12-rc1 and applies cleanly to the current drm-tip. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: Run a dedicated hmm.git for 5.3
On Fri, May 24, 2019 at 09:44:55AM -0300, Jason Gunthorpe wrote: > On Thu, May 23, 2019 at 11:40:51PM -0700, Christoph Hellwig wrote: > > On Thu, May 23, 2019 at 04:10:38PM -0300, Jason Gunthorpe wrote: > > > > > > On Thu, May 23, 2019 at 02:24:58PM -0400, Jerome Glisse wrote: > > > > I can not take mmap_sem in range_register, the READ_ONCE is fine and > > > > they are no race as we do take a reference on the hmm struct thus > > > > > > Of course there are use after free races with a READ_ONCE scheme, I > > > shouldn't have to explain this. > > > > > > If you cannot take the read mmap sem (why not?), then please use my > > > version and push the update to the driver through -mm.. > > > > I think it would really help if we queue up these changes in a git tree > > that can be pulled into the driver trees. Given that you've been > > doing so much work to actually make it usable I'd nominate rdma for the > > "lead" tree. > > Sure, I'm willing to do that. RDMA has experience successfully running > shared git trees with netdev. It can work very well, but requires > discipline and understanding of the limitations. > > I really want to see the complete HMM solution from Jerome (ie the > kconfig fixes, arm64, api fixes, etc) in one cohesive view, not > forced to be sprinkled across multiple kernel releases to work around > a submission process/coordination problem. > > Now that -mm merged the basic hmm API skeleton I think running like > this would get us quickly to the place we all want: comprehensive in tree > users of hmm. > > Andrew, would this be acceptable to you? > > Dave, would you be willing to merge a clean HMM tree into DRM if it is > required for DRM driver work in 5.3? > > I'm fine to merge a tree like this for RDMA, we already do this > pattern with netdev. > > Background: The issue that is motivating this is we want to make > changes to some of the API's for hmm, which mean changes in existing > DRM, changes in to-be-accepted RDMA code, and to-be-accepted DRM > driver code. Coordintating the mm/hmm.c, RDMA and DRM changes is best > done with the proven shared git tree pattern. As CH explains I would > run a clean/minimal hmm tree that can be merged into driver trees as > required, and I will commit to sending a PR to Linus for this tree > very early in the merge window so that driver PR's are 'clean'. > > The tree will only contain uncontroversial hmm related commits, bug > fixes, etc. > > Obviouisly I will also commit to providing review for patches flowing > through this tree. Sure topic branch sounds fine, we do that all the time with various subsystems all over. We have ready made scripts for topic branches and applying pulls from all over, so we can even soak test everything in our integration tree. In case there's conflicts or just to make sure everything works, before we bake the topic branch into permanent history (the main drm.git repo just can't be rebased, too much going on and too many people involvd). If Jerome is ok with wrestling with our scripting we could even pull these updates in while the hmm.git tree is evolving. Cheers, Daniel (drm co-maintainer fwiw) -- 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] drm/etnaviv: lock MMU while dumping core
Am Freitag, den 24.05.2019, 16:31 +0100 schrieb Russell King - ARM Linux admin:
> On Wed, May 22, 2019 at 11:55:14AM +0200, Lucas Stach wrote:
> > The devcoredump needs to operate on a stable state of the MMU while
> > it is writing the MMU state to the coredump. The missing lock
> > allowed both the userspace submit, as well as the GPU job finish
> > paths to mutate the MMU state while a coredump is under way.
>
> This locking does little to solve this problem. We actually rely on the
> GPU being deadlocked at this point - we aren't expecting the GPU to make
> any progress. The only thing that can realistically happen is for
> userspace to submit a new job, but adding this locking does little to
> avoid that.
The GPU is dead at the point where we do the dump. But there is nothing
that would stop the workers that clean up finished jobs before the GPU
stopped execution to manipulate the MMU mapping list, which happens
when buffers become unreferenced due to the finished GPU operation.
Also new mappings can be added to the MMU due to a userspace submit,
even if the GPU is blocked.
> > Fixes: a8c21a5451d8 (drm/etnaviv: add initial etnaviv DRM driver)
> > > > Reported-by: David Jander
> > > > Signed-off-by: Lucas Stach
> > > > Tested-by: David Jander
> > ---
> > drivers/gpu/drm/etnaviv/etnaviv_dump.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> > b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> > index 33854c94cb85..515515ef24f9 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> > @@ -125,6 +125,8 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
> > > > return;
> > > > etnaviv_dump_core = false;
> >
> > > > + mutex_lock(&gpu->mmu->lock);
> > +
> > > > mmu_size = etnaviv_iommu_dump_size(gpu->mmu);
> >
> > > > /* We always dump registers, mmu, ring and end marker */
> > @@ -167,6 +169,7 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
> > > > iter.start = __vmalloc(file_size, GFP_KERNEL | __GFP_NOWARN |
> > > > __GFP_NORETRY,
> > > > PAGE_KERNEL);
> > > > if (!iter.start) {
> > > > + mutex_unlock(&gpu->mmu->lock);
> > > > dev_warn(gpu->dev, "failed to allocate devcoredump
> > > > file\n");
> > > > return;
> > > > }
> > @@ -234,6 +237,8 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
> > > > obj->base.size);
> > > > }
> >
> > > > + mutex_unlock(&gpu->mmu->lock);
> > +
>
> All that this lock does is prevent the lists from changing while we
> build up what we're going to write out. At this point, you drop the
> lock, before we've written anything out to the coredump. Things
> can now change, including the ring buffer.
At this point we finished moving all the dump data into the vmalloced
memory allocated earlier. Why wound we need to hold the lock after this
is finished? Nothing is going to touch the MMU mappings after that
point.
> > etnaviv_core_dump_header(&iter, ETDUMP_BUF_END, iter.data);
> >
> > dev_coredumpv(gpu->dev, iter.start, iter.data - iter.start, GFP_KERNEL);
>
> Here we write out the data, which includes the command buffers, ring
> buffers, BOs, etc. The data in the ring buffer can still change
> because the lock has been dropped.
>
> However, all those objects should be pinned, so none of them should
> go away: things like the command buffers that have been submitted
> should be immutable at this point (if they aren't, it could well be
> a reason why the GPU has gone awol.)
We do not have a big etnaviv lock that would prevent cleanup or new
submit work to make progress while the GPU is busy or hung. All those
operations are able to mutate the MMU state, even when the GPU is
locked up. The only things that are guaranteed to be stable are the
objects referenced by the hanging job, which is also why I think we
should dump only the hanging job and the GPU state, but that's a much
bigger patch. I've kept this one small, so it can be applied to the
stable kernels without any conflicts.
> It is also not nice to hold the lock over the _big_ vmalloc() which
> may take some time.
At the time we detect the GPU lockup, we've already lost a lot of GPU
not executing pending jobs. I don't really care about blocking a
userspace submit a bit longer while the dump and recovery is under way.
> Have you actually seen problems here, or is this just theoretical?
This fixes a real kernel crashing issue as we overrun the vmalloced
buffer when new BOs are added into the MMU between the time we go over
the mappings to get the dump size and actually moving the BO data into
the dump. This has been reported and tracked down by David.
Regards,
Lucas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freede
Re: [PATCH] drm/qxl: drop WARN_ONCE()
On Fri, May 24, 2019 at 12:42:50PM +0200, Gerd Hoffmann wrote:
> There is no good reason to flood the kernel log with a WARN
> stacktrace just because someone tried to mmap a prime buffer.
Yeah no userspace triggerable dmesg noise above debug level.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/qxl/qxl_prime.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_prime.c b/drivers/gpu/drm/qxl/qxl_prime.c
> index 114653b471c6..7d3816fca5a8 100644
> --- a/drivers/gpu/drm/qxl/qxl_prime.c
> +++ b/drivers/gpu/drm/qxl/qxl_prime.c
> @@ -77,6 +77,5 @@ void qxl_gem_prime_vunmap(struct drm_gem_object *obj, void
> *vaddr)
> int qxl_gem_prime_mmap(struct drm_gem_object *obj,
> struct vm_area_struct *area)
> {
> - WARN_ONCE(1, "not implemented");
> return -ENOSYS;
> }
> --
> 2.18.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: linux-next: build failure after merge of the drm-fixes tree
On Fri, May 24, 2019 at 08:15:48PM +1000, Stephen Rothwell wrote:
> Hi Daniel,
>
> On Fri, 24 May 2019 10:09:28 +0200 Daniel Vetter wrote:
> >
> > On Fri, May 24, 2019 at 12:29 AM Stephen Rothwell
> > wrote:
> > >
> > > After merging the drm-fixes tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
> > > 'load_dmcu_fw':
> > > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:667:7: error:
> > > implicit declaration of function 'ASICREV_IS_PICASSO'; did you mean
> > > 'ASICREV_IS_VEGA12_P'? [-Werror=implicit-function-declaration]
> > >if (ASICREV_IS_PICASSO(adev->external_rev_id))
> > >^~
> > >ASICREV_IS_VEGA12_P
> > >
> > > Caused by commit
> > >
> > > 55143dc23ca4 ("drm/amd/display: Don't load DMCU for Raven 1")
> > >
> > > I have reverted that commit for today.
> >
> > Seems to compile fine here, and Dave just sent out the pull so I guess
> > works for him too. What's your .config?
>
> See above "x86_64 allmodconfig"
>
> Looking at it closely now, I can't see how that error comes about.
>
> Ah, in the drm-fixes tree, the definition of is protected by
>
> #if defined(CONFIG_DRM_AMD_DC_DCN1_01)
>
> which gets removed in the amdgpu tree (merged later). So I can only
> presume that CONFIG_DRM_AMD_DC_DCN1_01 was not set for the build I did.
>
> config DRM_AMD_DC
> bool "AMD DC - Enable new display engine"
> default y
> select DRM_AMD_DC_DCN1_0 if X86 && !(KCOV_INSTRUMENT_ALL &&
> KCOV_ENABLE_
> COMPARISONS)KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS
> select DRM_AMD_DC_DCN1_01 if X86 && !(KCOV_INSTRUMENT_ALL &&
> KCOV_ENABLE_COMPARISONS)
>
> So maybe KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS are set for
> allmodconfig. I no longer have the actual .config file any more, sorry.
Ah yes. Dave figured it out too and added a revert on top and redid the
pull to Linus. Thanks for spotting&reporting this.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v11 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs
Hi, On 24/05/19 5:53 PM, Fabio Estevam wrote: > Hi Kishon, > > On Sun, May 12, 2019 at 7:49 AM Guido Günther wrote: >> >> This adds support for the Mixel DPHY as found on i.MX8 CPUs but since >> this is an IP core it will likely be found on others in the future. So >> instead of adding this to the nwl host driver make it a generic PHY >> driver. >> >> The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be >> added once the necessary system controller bits are in via >> mixel_dphy_devdata. >> >> Signed-off-by: Guido Günther >> Co-developed-by: Robert Chiras >> Signed-off-by: Robert Chiras >> Reviewed-by: Fabio Estevam >> Reviewed-by: Sam Ravnborg > > Would you have any comments on this series, please? I don't have any comments. I'll queue this once I start queuing patches for the next merge window. Thanks Kishon
Re: [PATCH 4/4] drm/TODO: add a task to kill DRM_UNLOCKED
On Fri, May 24, 2019 at 04:17:16PM +0100, Emil Velikov wrote: > On 2019/05/22, Daniel Vetter wrote: > > On Wed, May 22, 2019 at 04:47:02PM +0100, Emil Velikov wrote: > > > From: Emil Velikov > > > > > > Should minimise the copy/paste mistakes, fixed with previous patches. > > > > > > Cc: Daniel Vetter > > > Signed-off-by: Emil Velikov > > > --- > > > Daniel, not 100% sold on the idea. That plus listing you as a contact > > > point ;-) > > > > > > What do you thing? > > > Emil > > > --- > > > Documentation/gpu/todo.rst | 19 +++ > > > 1 file changed, 19 insertions(+) > > > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > > index 66f05f4e469f..9e67d125f2fd 100644 > > > --- a/Documentation/gpu/todo.rst > > > +++ b/Documentation/gpu/todo.rst > > > @@ -397,6 +397,25 @@ Some of these date from the very introduction of KMS > > > in 2008 ... > > >end, for which we could add drm_*_cleanup_kfree(). And then there's > > > the (for > > >historical reasons) misnamed drm_primary_helper_destroy() function. > > > > > > +Use DRM_LOCKED instead of DRM_UNLOCKED > > > +-- > > > + > > > +DRM_UNLOCKED is a remainder from the legacy DRM drivers. Seemingly > > > drivers get > > > +tricked by it and it ends up in the driver private ioctls. > > > + > > > +Today no more legacy drivers are allowed and most core DRM ioctls are > > > unlocked. > > > + > > > +Introduce DRM_LOCKED, use it to annotate only the relevant ioctls and > > > kill the > > > +old DRM_UNLOCKED. > > > + > > > +Patch series should be split as follows: > > > + - Patch 1: drm: add the new DRM_LOCKED flag and honour it > > > + - Patch 2: drm: convert core ioctls from DRM_UNLOCKED to DRM_LOCKED > > > + - Patch 3-...: drm/driverX: convert driver ioctls from ... > > > + - Patch X: drm: remove no longer used DRM_UNLOCKED, drop todo item > > > > Seems like too much bother for legacy drivers ... What I'd do is something > > a lot cheaper, since all we're touching here are legacy drivers: > > > > Remove DRM_UNLOCKED from everything except the old vblank ioctl. That one > > we need to keep, because it freezes X: > > > > commit 8f4ff2b06afcd6f151868474a432c603057eaf56 > > Author: Ilija Hadzic > > Date: Mon Oct 31 17:46:18 2011 -0400 > > > > drm: do not sleep on vblank while holding a mutex > > > > Anything else I think is either never used by legacy userspace, or just > > doesn't matter. That's simple enough that I don't think we really need a > > todo for it :-) I guess if you want to kill DRM_UNLOCKED you could replace > > the check with ioctl->func == drm_vblank_ioctl, ofc only in the > > DRIVER_LEGACY path. > > > Sounds like a much simpler solution indeed. Sadly I don't have much time to > double-check that this won't cause problems elsewhere, so I'll leave it that > to someone else. I did dig through enough history that I'm confident. I'll type a patch and some awkward-long commit message :-) -Daniel > > > On patches 1-3 in your series: > > > > Reviewed-by: Daniel Vetter > > > Thank you very much. > > -Emil -- 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] drm/etnaviv: lock MMU while dumping core
On Wed, May 22, 2019 at 11:55:14AM +0200, Lucas Stach wrote:
> The devcoredump needs to operate on a stable state of the MMU while
> it is writing the MMU state to the coredump. The missing lock
> allowed both the userspace submit, as well as the GPU job finish
> paths to mutate the MMU state while a coredump is under way.
This locking does little to solve this problem. We actually rely on the
GPU being deadlocked at this point - we aren't expecting the GPU to make
any progress. The only thing that can realistically happen is for
userspace to submit a new job, but adding this locking does little to
avoid that.
> Fixes: a8c21a5451d8 (drm/etnaviv: add initial etnaviv DRM driver)
> Reported-by: David Jander
> Signed-off-by: Lucas Stach
> Tested-by: David Jander
> ---
> drivers/gpu/drm/etnaviv/etnaviv_dump.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> index 33854c94cb85..515515ef24f9 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> @@ -125,6 +125,8 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
> return;
> etnaviv_dump_core = false;
>
> + mutex_lock(&gpu->mmu->lock);
> +
> mmu_size = etnaviv_iommu_dump_size(gpu->mmu);
>
> /* We always dump registers, mmu, ring and end marker */
> @@ -167,6 +169,7 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
> iter.start = __vmalloc(file_size, GFP_KERNEL | __GFP_NOWARN |
> __GFP_NORETRY,
> PAGE_KERNEL);
> if (!iter.start) {
> + mutex_unlock(&gpu->mmu->lock);
> dev_warn(gpu->dev, "failed to allocate devcoredump file\n");
> return;
> }
> @@ -234,6 +237,8 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
>obj->base.size);
> }
>
> + mutex_unlock(&gpu->mmu->lock);
> +
All that this lock does is prevent the lists from changing while we
build up what we're going to write out. At this point, you drop the
lock, before we've written anything out to the coredump. Things
can now change, including the ring buffer.
> etnaviv_core_dump_header(&iter, ETDUMP_BUF_END, iter.data);
>
> dev_coredumpv(gpu->dev, iter.start, iter.data - iter.start, GFP_KERNEL);
Here we write out the data, which includes the command buffers, ring
buffers, BOs, etc. The data in the ring buffer can still change
because the lock has been dropped.
However, all those objects should be pinned, so none of them should
go away: things like the command buffers that have been submitted
should be immutable at this point (if they aren't, it could well be
a reason why the GPU has gone awol.)
It is also not nice to hold the lock over the _big_ vmalloc() which
may take some time.
Have you actually seen problems here, or is this just theoretical?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 24/33] Revert "backlight/fbcon: Add FB_EVENT_CONBLANK"
Hi Daniel,
On Fri, May 24, 2019 at 3:14 PM Daniel Thompson
wrote:
>
> On Fri, May 24, 2019 at 10:53:45AM +0200, Daniel Vetter wrote:
> > This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928.
> >
> > The justification is that if hw blanking fails (i.e. fbops->fb_blank)
> > fails, then we still want to shut down the backlight. Which is exactly
> > _not_ what fb_blank() does and so rather inconsistent if we end up
> > with different behaviour between fbcon and direct fbdev usage. Given
> > that the entire notifier maze is getting in the way anyway I figured
> > it's simplest to revert this not well justified commit.
> >
> > v2: Add static inline to the dummy version.
> >
> > Cc: Richard Purdie
> > Signed-off-by: Daniel Vetter
> > Cc: Lee Jones
> > Cc: Daniel Thompson
> > Cc: Jingoo Han
> > Cc: Bartlomiej Zolnierkiewicz
> > Cc: Daniel Vetter
> > Cc: Hans de Goede
> > Cc: Yisheng Xie
> > Cc: linux-fb...@vger.kernel.org
>
> Hi Daniel
>
> When this goes round again could you add me to the covering letter?
>
> I looked at all three of the patches and no objections on my side but
> I'm reluctant to send out acks because I'm not sure I understood the
> wider picture well enough.
It's one of these patch series with some many different subsystems and
people you can't cc the cover to all of them or mailing lists start
rejecting you because too many recipients. I tried to spam sufficient
mailng lists, but I guess not enough.
Cover letter of version one, which tries to explain the full big picture:
https://lists.freedesktop.org/archives/dri-devel/2019-May/218362.html
tldr; I have a multi-year plan to improve fbcon locking, because the
current thing is a bit a mess.
Cover letter of this version, where I detail a bit more the details
fixed in this one here:
https://lists.freedesktop.org/archives/dri-devel/2019-May/218984.html
I can also bounce these to you if you want.
Thanks, Daniel
>
>
> Daniel.
>
>
> > ---
> > drivers/video/backlight/backlight.c | 2 +-
> > drivers/video/fbdev/core/fbcon.c| 14 +-
> > drivers/video/fbdev/core/fbmem.c| 1 +
> > include/linux/fb.h | 4 +---
> > include/linux/fbcon.h | 2 ++
> > 5 files changed, 6 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/video/backlight/backlight.c
> > b/drivers/video/backlight/backlight.c
> > index deb824bef6e2..c55590ec0057 100644
> > --- a/drivers/video/backlight/backlight.c
> > +++ b/drivers/video/backlight/backlight.c
> > @@ -46,7 +46,7 @@ static int fb_notifier_callback(struct notifier_block
> > *self,
> > int fb_blank = 0;
> >
> > /* If we aren't interested in this event, skip it immediately ... */
> > - if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
> > + if (event != FB_EVENT_BLANK)
> > return 0;
> >
> > bd = container_of(self, struct backlight_device, fb_notif);
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index 259cdd118475..d9f545f1a81b 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -2350,8 +2350,6 @@ static int fbcon_switch(struct vc_data *vc)
> > static void fbcon_generic_blank(struct vc_data *vc, struct fb_info *info,
> > int blank)
> > {
> > - struct fb_event event;
> > -
> > if (blank) {
> > unsigned short charmask = vc->vc_hi_font_mask ?
> > 0x1ff : 0xff;
> > @@ -2362,13 +2360,6 @@ static void fbcon_generic_blank(struct vc_data *vc,
> > struct fb_info *info,
> > fbcon_clear(vc, 0, 0, vc->vc_rows, vc->vc_cols);
> > vc->vc_video_erase_char = oldc;
> > }
> > -
> > -
> > - lock_fb_info(info);
> > - event.info = info;
> > - event.data = ␣
> > - fb_notifier_call_chain(FB_EVENT_CONBLANK, &event);
> > - unlock_fb_info(info);
> > }
> >
> > static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
> > @@ -3240,7 +3231,7 @@ int fbcon_fb_registered(struct fb_info *info)
> > return ret;
> > }
> >
> > -static void fbcon_fb_blanked(struct fb_info *info, int blank)
> > +void fbcon_fb_blanked(struct fb_info *info, int blank)
> > {
> > struct fbcon_ops *ops = info->fbcon_par;
> > struct vc_data *vc;
> > @@ -3344,9 +3335,6 @@ static int fbcon_event_notify(struct notifier_block
> > *self,
> > con2fb = event->data;
> > con2fb->framebuffer = con2fb_map[con2fb->console - 1];
> > break;
> > - case FB_EVENT_BLANK:
> > - fbcon_fb_blanked(info, *(int *)event->data);
> > - break;
> > case FB_EVENT_REMAP_ALL_CONSOLE:
> > idx = info->node;
> > fbcon_remap_all(idx);
> > diff --git a/drivers/video/fbdev/core/fbmem.c
> > b/drivers/video/fbdev/core/fbmem.c
> > index ddc0c16b8bbf..9366fbe99a58 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/
Re: [PATCH 4/5] drm/vmwgfx: remove custom ioctl io encoding check
On 2019/05/24, Thomas Hellstrom wrote: > On Fri, 2019-05-24 at 13:14 +0100, Emil Velikov wrote: > > On 2019/05/23, Thomas Hellstrom wrote: > > > Hi, Emil, > > > > > > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote: > > > > From: Emil Velikov > > > > > > > > Drop the custom ioctl io encoding check - core drm does it for > > > > us. > > > > > > I fail to see where the core does this, or do I miss something? > > > > drm_ioctl() allows for the encoding to be changed and attributes that > > only the > > appropriate size is copied in/out of the kernel. > > > > Technically the function is more relaxed relative to the vmwgfx > > check, yet > > seems perfectly reasonable. > > > > Is there any corner-case that isn't but should be handled in > > drm_ioctl()? > > I'd like to turn the question around and ask whether there's a reason > we should relax the vmwgfx test? In the past it has trapped quite a few > user-space errors. > The way I see it either: - the check, as-is, is unnessesary, or - it is needed, and we should do something equivalent for all of DRM We had a very long brainstorming session with a colleague and we could not see any cases where this would cause a problem. If you recall anything concrete please let me know - I would be more than happy to take a closer look. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On Fri, 24 May 2019 16:11:14 +0100
Roger Willcocks wrote:
> On 23/05/2019 16:27, Steven Rostedt wrote:
> >
> > I haven't yet tested this, but what about something like the following:
> >
> > ...perhaps forget about the constant check, and just force
> > the power of two check:
> >
> > \
> > if (!(__y & (__y >> 1))) { \
> > __x = round_up(x, y); \
> > } else {\
>
> You probably want
>
> if (!(__y & (__y - 1))
>
> --
Yes I do. I corrected it in my next email.
http://lkml.kernel.org/r/20190523133648.591f9...@gandalf.local.home
> #define roundup(x, y) ( \
> { \
> typeof(y) __y = y; \
> typeof(x) __x; \
> \
> if (__y & (__y - 1))\
> __x = round_up(x, __y); \
> else\
> __x = (((x) + (__y - 1)) / __y) * __y; \
> __x;\
> })
-- Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/8] drm/fb-helper: Move modesetting code to drm_client
Hi Linus. Thanks for the response. > > Could one of you take a look at this series. > > Daniel already ack'ed the series on irc, but an extra pair of eyes > > is never bad. > > I would if I had a chance of understanding them. I am still pretty > novice with DRM so what I do is trace down to the calls I > need and understand the small pieces I use. We are almost on the same page here, expect that I am sometimes at loss understanding :-) Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/tegra: remove irrelevant DRM_UNLOCKED flag
On 2019/05/23, Thierry Reding wrote: > On Wed, May 22, 2019 at 04:46:59PM +0100, Emil Velikov wrote: > > From: Emil Velikov > > > > DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it. > > > > Cc: Thierry Reding > > Cc: linux-te...@vger.kernel.org > > Cc: Daniel Vetter > > Signed-off-by: Emil Velikov > > --- > > drivers/gpu/drm/tegra/drm.c | 28 ++-- > > 1 file changed, 14 insertions(+), 14 deletions(-) > > I assume you want to take this through drm-misc? In that case: > > Acked-by: Thierry Reding > > Otherwise let me know and I'll pick it up into the Tegra tree. > Yes, I'll pick it up through drm-misc. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On 23/05/2019 16:27, Steven Rostedt wrote:
I haven't yet tested this, but what about something like the following:
...perhaps forget about the constant check, and just force
the power of two check:
\
if (!(__y & (__y >> 1))) {\
__x = round_up(x, y); \
} else {\
You probably want
if (!(__y & (__y - 1))
--
Roger
Re: [PATCH v6 0/8] drm/fb-helper: Move modesetting code to drm_client
On Thu, May 23, 2019 at 6:53 PM Sam Ravnborg wrote: > Could one of you take a look at this series. > Daniel already ack'ed the series on irc, but an extra pair of eyes > is never bad. I would if I had a chance of understanding them. I am still pretty novice with DRM so what I do is trace down to the calls I need and understand the small pieces I use. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/TODO: add a task to kill DRM_UNLOCKED
On 2019/05/22, Daniel Vetter wrote: > On Wed, May 22, 2019 at 04:47:02PM +0100, Emil Velikov wrote: > > From: Emil Velikov > > > > Should minimise the copy/paste mistakes, fixed with previous patches. > > > > Cc: Daniel Vetter > > Signed-off-by: Emil Velikov > > --- > > Daniel, not 100% sold on the idea. That plus listing you as a contact > > point ;-) > > > > What do you thing? > > Emil > > --- > > Documentation/gpu/todo.rst | 19 +++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > index 66f05f4e469f..9e67d125f2fd 100644 > > --- a/Documentation/gpu/todo.rst > > +++ b/Documentation/gpu/todo.rst > > @@ -397,6 +397,25 @@ Some of these date from the very introduction of KMS > > in 2008 ... > >end, for which we could add drm_*_cleanup_kfree(). And then there's the > > (for > >historical reasons) misnamed drm_primary_helper_destroy() function. > > > > +Use DRM_LOCKED instead of DRM_UNLOCKED > > +-- > > + > > +DRM_UNLOCKED is a remainder from the legacy DRM drivers. Seemingly drivers > > get > > +tricked by it and it ends up in the driver private ioctls. > > + > > +Today no more legacy drivers are allowed and most core DRM ioctls are > > unlocked. > > + > > +Introduce DRM_LOCKED, use it to annotate only the relevant ioctls and kill > > the > > +old DRM_UNLOCKED. > > + > > +Patch series should be split as follows: > > + - Patch 1: drm: add the new DRM_LOCKED flag and honour it > > + - Patch 2: drm: convert core ioctls from DRM_UNLOCKED to DRM_LOCKED > > + - Patch 3-...: drm/driverX: convert driver ioctls from ... > > + - Patch X: drm: remove no longer used DRM_UNLOCKED, drop todo item > > Seems like too much bother for legacy drivers ... What I'd do is something > a lot cheaper, since all we're touching here are legacy drivers: > > Remove DRM_UNLOCKED from everything except the old vblank ioctl. That one > we need to keep, because it freezes X: > > commit 8f4ff2b06afcd6f151868474a432c603057eaf56 > Author: Ilija Hadzic > Date: Mon Oct 31 17:46:18 2011 -0400 > > drm: do not sleep on vblank while holding a mutex > > Anything else I think is either never used by legacy userspace, or just > doesn't matter. That's simple enough that I don't think we really need a > todo for it :-) I guess if you want to kill DRM_UNLOCKED you could replace > the check with ioctl->func == drm_vblank_ioctl, ofc only in the > DRIVER_LEGACY path. > Sounds like a much simpler solution indeed. Sadly I don't have much time to double-check that this won't cause problems elsewhere, so I'll leave it that to someone else. > On patches 1-3 in your series: > > Reviewed-by: Daniel Vetter > Thank you very much. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: lock MMU while dumping core
On Wed, 2019-05-22 at 11:55 +0200, Lucas Stach wrote:
> The devcoredump needs to operate on a stable state of the MMU while
> it is writing the MMU state to the coredump. The missing lock
> allowed both the userspace submit, as well as the GPU job finish
> paths to mutate the MMU state while a coredump is under way.
>
> Fixes: a8c21a5451d8 (drm/etnaviv: add initial etnaviv DRM driver)
> Reported-by: David Jander
> Signed-off-by: Lucas Stach
> Tested-by: David Jander
Reviewed-by: Philipp Zabel
> ---
> drivers/gpu/drm/etnaviv/etnaviv_dump.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> index 33854c94cb85..515515ef24f9 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> @@ -125,6 +125,8 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
> return;
> etnaviv_dump_core = false;
>
> + mutex_lock(&gpu->mmu->lock);
> +
> mmu_size = etnaviv_iommu_dump_size(gpu->mmu);
>
> /* We always dump registers, mmu, ring and end marker */
> @@ -167,6 +169,7 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
> iter.start = __vmalloc(file_size, GFP_KERNEL | __GFP_NOWARN |
> __GFP_NORETRY,
> PAGE_KERNEL);
> if (!iter.start) {
> + mutex_unlock(&gpu->mmu->lock);
> dev_warn(gpu->dev, "failed to allocate devcoredump file\n");
> return;
> }
> @@ -234,6 +237,8 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
>obj->base.size);
> }
>
> + mutex_unlock(&gpu->mmu->lock);
> +
> etnaviv_core_dump_header(&iter, ETDUMP_BUF_END, iter.data);
>
> dev_coredumpv(gpu->dev, iter.start, iter.data - iter.start, GFP_KERNEL);
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/nouveau: remove open-coded drm_invalid_op()
On 2019/05/23, Ben Skeggs wrote: > On Thu, 23 May 2019 at 01:03, Emil Velikov wrote: > > > > From: Emil Velikov > > > > Cc: Ben Skeggs > > Cc: nouv...@lists.freedesktop.org > > Signed-off-by: Emil Velikov > Thanks! > Forgot to mention, any objections if I take this through drm-misc? I'm about to send a lengthy series which will conflict with this patch, albeit trivially. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
+ Tom He's been looking into SEV as well. On Fri, May 24, 2019 at 8:30 AM Thomas Hellstrom wrote: > > On 5/24/19 2:03 PM, Koenig, Christian wrote: > > Am 24.05.19 um 12:37 schrieb Thomas Hellstrom: > >> [CAUTION: External Email] > >> > >> On 5/24/19 12:18 PM, Koenig, Christian wrote: > >>> Am 24.05.19 um 11:55 schrieb Thomas Hellstrom: > [CAUTION: External Email] > > On 5/24/19 11:11 AM, Thomas Hellstrom wrote: > > Hi, Christian, > > > > On 5/24/19 10:37 AM, Koenig, Christian wrote: > >> Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware): > >>> [CAUTION: External Email] > >>> > >>> From: Thomas Hellstrom > >>> > >>> With SEV encryption, all DMA memory must be marked decrypted > >>> (AKA "shared") for devices to be able to read it. In the future we > >>> might > >>> want to be able to switch normal (encrypted) memory to decrypted in > >>> exactly > >>> the same way as we handle caching states, and that would require > >>> additional > >>> memory pools. But for now, rely on memory allocated with > >>> dma_alloc_coherent() which is already decrypted with SEV enabled. > >>> Set up > >>> the page protection accordingly. Drivers must detect SEV enabled and > >>> switch > >>> to the dma page pool. > >>> > >>> This patch has not yet been tested. As a follow-up, we might want to > >>> cache decrypted pages in the dma page pool regardless of their > >>> caching > >>> state. > >> This patch is unnecessary, SEV support already works fine with at > >> least > >> amdgpu and I would expect that it also works with other drivers as > >> well. > >> > >> Also see this patch: > >> > >> commit 64e1f830ea5b3516a4256ed1c504a265d7f2a65c > >> Author: Christian König > >> Date: Wed Mar 13 10:11:19 2019 +0100 > >> > >> drm: fallback to dma_alloc_coherent when memory encryption is > >> active > >> > >> We can't just map any randome page we get when memory > >> encryption is > >> active. > >> > >> Signed-off-by: Christian König > >> Acked-by: Alex Deucher > >> Link: https://patchwork.kernel.org/patch/10850833/ > >> > >> Regards, > >> Christian. > > Yes, I noticed that. Although I fail to see where we automagically > > clear the PTE encrypted bit when mapping coherent memory? For the > > linear kernel map, that's done within dma_alloc_coherent() but for > > kernel vmaps and and user-space maps? Is that done automatically by > > the x86 platform layer? > >>> Yes, I think so. Haven't looked to closely at this either. > >> This sounds a bit odd. If that were the case, the natural place would be > >> the PAT tracking code, but it only handles caching flags AFAICT. Not > >> encryption flags. > >> > >> But when you tested AMD with SEV, was that running as hypervisor rather > >> than a guest, or did you run an SEV guest with PCI passthrough to the > >> AMD device? > > Yeah, well the problem is we never tested this ourself :) > > > > /Thomas > > > And, as a follow up question, why do we need dma_alloc_coherent() when > using SME? I thought the hardware performs the decryption when DMA-ing > to / from an encrypted page with SME, but not with SEV? > >>> I think the issue was that the DMA API would try to use a bounce buffer > >>> in this case. > >> SEV forces SWIOTLB bouncing on, but not SME. So it should probably be > >> possible to avoid dma_alloc_coherent() in the SME case. > > In this case I don't have an explanation for this. > > > > For the background what happened is that we got reports that SVE/SME > > doesn't work with amdgpu. So we told the people to try using the > > dma_alloc_coherent() path and that worked fine. Because of this we came > > up with the patch I noted earlier. > > > > I can confirm that it indeed works now for a couple of users, but we > > still don't have a test system for this in our team. > > > > Christian. > > OK, undestood, > > But unless there is some strange magic going on, (which there might be > of course),I do think the patch I sent is correct, and the reason that > SEV works is that the AMD card is used by the hypervisor and not the > guest, and TTM is actually incorrectly creating conflicting maps and > treating the coherent memory as encrypted. But since the memory is only > accessed through encrypted PTEs, the hardware does the right thing, > using the hypervisor key for decryption > > But that's only a guess, and this is not super-urgent. I will be able to > follow up if / when we bring vmwgfx up for SEV. > > /Thomas > > >> /Thomas > >> > >> > >>> Christian. > >>> > Thanks, Thomas > > > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel __
Re: [PATCH] drm/i915/dsi: Use a fuzzy check for burst mode clock check
Hi,
On 5/24/19 3:06 PM, Hans de Goede wrote:
Prior to this commit we fail to init the DSI panel on the GPD MicroPC:
https://www.indiegogo.com/projects/gpd-micropc-6-inch-handheld-industry-laptop#/
The problem is intel_dsi_vbt_init() failing with the following error:
*ERROR* Burst mode freq is less than computed
The pclk in the VBT panel modeline is 7, together with 24 bpp and
4 lines this results in a bitrate value of 7 * 24 / 4 = 42.
But the target_burst_mode_freq in the VBT is 418000.
This commit works around this problem by adding an intel_fuzzy_clock_check
when target_burst_mode_freq < bitrate and setting target_burst_mode_freq to
bitrate when that checks succeeds, fixing the panel not working.
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede
I just realized that this patch depends on a patch from another series of
mine which exports intel_fuzzy_clock_check, I will resend this as a series
with the patch doing the exporting as first patch, so that the CI can test
this.
Regards,
Hans
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 022bf59418df..a2a9b9d0eeaa 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -895,6 +895,17 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
if (mipi_config->target_burst_mode_freq) {
u32 bitrate = intel_dsi_bitrate(intel_dsi);
+ /*
+* Sometimes the VBT contains a slightly lower clock,
+* then the bitrate we have calculated, in this case
+* just replace it with the calculated bitrate.
+*/
+ if (mipi_config->target_burst_mode_freq < bitrate &&
+ intel_fuzzy_clock_check(
+ mipi_config->target_burst_mode_freq,
+ bitrate))
+ mipi_config->target_burst_mode_freq = bitrate;
+
if (mipi_config->target_burst_mode_freq < bitrate) {
DRM_ERROR("Burst mode freq is less than
computed\n");
return false;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vmwgfx: fix a warning due to missing dma_parms
On Fri, May 24, 2019 at 11:57:04AM +, Thomas Hellstrom wrote: > It's a PCI device. The struct device * used in dma_map_sg() is the same > as the &pci_dev->dev handed to the probe() callback. But at probe time, > the struct device::dma_parms is non-NULL, at least on my system so > there shouldn't really be a need to kzalloc() it. Then there is something really odd going on in the OPs setup..
Re: [PATCH v2] video: fbdev: atmel_lcdfb: add COMPILE_TEST support
Hi Bartlomiej,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.2-rc1 next-20190524]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Bartlomiej-Zolnierkiewicz/video-fbdev-atmel_lcdfb-add-COMPILE_TEST-support/20190524-184331
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-7-g2b96cd8-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/video/fbdev/atmel_lcdfb.c:354:27: sparse: sparse: incorrect type in
>> assignment (different address spaces) @@expected char [noderef]
>> *screen_base @@got n:2> *screen_base @@
>> drivers/video/fbdev/atmel_lcdfb.c:354:27: sparse:expected char [noderef]
>> *screen_base
>> drivers/video/fbdev/atmel_lcdfb.c:354:27: sparse:got void *
>> drivers/video/fbdev/atmel_lcdfb.c:362:9: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@expected void *s @@got char
>> [noderef] > drivers/video/fbdev/atmel_lcdfb.c:362:9: sparse:expected void *s
>> drivers/video/fbdev/atmel_lcdfb.c:362:9: sparse:got char [noderef]
>> *screen_base
>> drivers/video/fbdev/atmel_lcdfb.c:333:59: sparse: sparse: incorrect type in
>> argument 3 (different address spaces) @@expected void *cpu_addr @@
>> got char [noderef] > drivers/video/fbdev/atmel_lcdfb.c:333:59: sparse:expected void *cpu_addr
drivers/video/fbdev/atmel_lcdfb.c:333:59: sparse:got char [noderef]
*screen_base
>> drivers/video/fbdev/atmel_lcdfb.c:333:59: sparse: sparse: incorrect type in
>> argument 3 (different address spaces) @@expected void *cpu_addr @@
>> got char [noderef] > drivers/video/fbdev/atmel_lcdfb.c:333:59: sparse:expected void *cpu_addr
drivers/video/fbdev/atmel_lcdfb.c:333:59: sparse:got char [noderef]
*screen_base
vim +354 drivers/video/fbdev/atmel_lcdfb.c
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 328
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 329
static inline void atmel_lcdfb_free_video_memory(struct atmel_lcdfb_info *sinfo)
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 330 {
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 331
struct fb_info *info = sinfo->info;
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 332
f6e45661 drivers/video/fbdev/atmel_lcdfb.c Luis R. Rodriguez 2016-01-22 @333
dma_free_wc(info->device, info->fix.smem_len, info->screen_base,
f6e45661 drivers/video/fbdev/atmel_lcdfb.c Luis R. Rodriguez 2016-01-22 334
info->fix.smem_start);
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 335 }
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 336
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 337
/**
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 338
* atmel_lcdfb_alloc_video_memory - Allocate framebuffer memory
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 339
* @sinfo: the frame buffer to allocate memory for
1d01e835 drivers/video/atmel_lcdfb.c Krzysztof Helt 2009-07-08 340
*
1d01e835 drivers/video/atmel_lcdfb.c Krzysztof Helt 2009-07-08 341
* This function is called only from the atmel_lcdfb_probe()
1d01e835 drivers/video/atmel_lcdfb.c Krzysztof Helt 2009-07-08 342
* so no locking by fb_info->mm_lock around smem_len setting is needed.
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 343
*/
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 344
static int atmel_lcdfb_alloc_video_memory(struct atmel_lcdfb_info *sinfo)
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 345 {
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 346
struct fb_info *info = sinfo->info;
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 347
struct fb_var_screeninfo *var = &info->var;
ea757aca drivers/video/atmel_lcdfb.c Haavard Skinnemoen 2008-08-12 348
unsigned int smem_len;
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 349
ea757aca drivers/video/atmel_lcdfb.c Haavard Skinnemoen 2008-08-12 350
smem_len = (var->xres_virtual * var->yres_virtual
14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 351
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #24 from Mauro Gaspari --- (In reply to Sylvain BERTRAND from comment #23) > It seems I get the same freezes than you. It takes hours of gaming to get > some > random hard hang (no log). I thought I was overheating, but realized that my > system is on > "vacation" while playing. > linux amd-staging-drm-new/x11 native/mesa/llvm(erk...), all git no older > than a > week. > playing mostly dota2 vulkan on AMD TAHITI XT Hi, a bit frustrating eh? :) I have been asking around and it seems that RadeonVII and RX590 do not suffer those issues. Probably related to default clock speeds by manufacturers. Anyway, If you try the kernel parameters I mentioned above, those should help. I have not had crashes in weeks after I enabled those on my grub. And not related to distribution, those grub kernel settings worked for me on Tumbleweed, Arch, Ubuntu Budgie. I hope it helps. -- 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] video: fbdev: atmel_lcdfb: add COMPILE_TEST support
Hi Bartlomiej, I love your patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v5.2-rc1 next-20190524] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Bartlomiej-Zolnierkiewicz/video-fbdev-atmel_lcdfb-add-COMPILE_TEST-support/20190524-184331 config: x86_64-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): drivers/video//fbdev/atmel_lcdfb.c: In function 'atmel_lcdfb_set_par': >> drivers/video//fbdev/atmel_lcdfb.c:71:51: warning: large integer implicitly >> truncated to unsigned type [-Woverflow] #define lcdc_writel(sinfo, reg, val) __raw_writel((val), (sinfo)->mmio+(reg)) ^ >> drivers/video//fbdev/atmel_lcdfb.c:676:2: note: in expansion of macro >> 'lcdc_writel' lcdc_writel(sinfo, ATMEL_LCDC_IDR, ~0UL); ^~~ drivers/video//fbdev/atmel_lcdfb.c: In function 'atmel_lcdfb_suspend': >> drivers/video//fbdev/atmel_lcdfb.c:71:51: warning: large integer implicitly >> truncated to unsigned type [-Woverflow] #define lcdc_writel(sinfo, reg, val) __raw_writel((val), (sinfo)->mmio+(reg)) ^ drivers/video//fbdev/atmel_lcdfb.c:1294:2: note: in expansion of macro 'lcdc_writel' lcdc_writel(sinfo, ATMEL_LCDC_IDR, ~0UL); ^~~ vim +71 drivers/video//fbdev/atmel_lcdfb.c b985172b drivers/video/atmel_lcdfb.c Jean-Christophe PLAGNIOL-VILLARD 2013-03-29 69 14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 70 #define lcdc_readl(sinfo, reg) __raw_readl((sinfo)->mmio+(reg)) 14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 @71 #define lcdc_writel(sinfo, reg, val) __raw_writel((val), (sinfo)->mmio+(reg)) 14340586 drivers/video/atmel_lcdfb.c Nicolas Ferre 2007-05-10 72 :: The code at line 71 was first introduced by commit :: 14340586148e7c88d7b1b752876f5b5227b200b9 atmel_lcdfb: AT91/AT32 LCD Controller framebuffer driver :: TO: Nicolas Ferre :: CC: Linus Torvalds --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 24/33] Revert "backlight/fbcon: Add FB_EVENT_CONBLANK"
On Fri, May 24, 2019 at 10:53:45AM +0200, Daniel Vetter wrote:
> This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928.
>
> The justification is that if hw blanking fails (i.e. fbops->fb_blank)
> fails, then we still want to shut down the backlight. Which is exactly
> _not_ what fb_blank() does and so rather inconsistent if we end up
> with different behaviour between fbcon and direct fbdev usage. Given
> that the entire notifier maze is getting in the way anyway I figured
> it's simplest to revert this not well justified commit.
>
> v2: Add static inline to the dummy version.
>
> Cc: Richard Purdie
> Signed-off-by: Daniel Vetter
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Daniel Vetter
> Cc: Hans de Goede
> Cc: Yisheng Xie
> Cc: linux-fb...@vger.kernel.org
Hi Daniel
When this goes round again could you add me to the covering letter?
I looked at all three of the patches and no objections on my side but
I'm reluctant to send out acks because I'm not sure I understood the
wider picture well enough.
Daniel.
> ---
> drivers/video/backlight/backlight.c | 2 +-
> drivers/video/fbdev/core/fbcon.c| 14 +-
> drivers/video/fbdev/core/fbmem.c| 1 +
> include/linux/fb.h | 4 +---
> include/linux/fbcon.h | 2 ++
> 5 files changed, 6 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/video/backlight/backlight.c
> b/drivers/video/backlight/backlight.c
> index deb824bef6e2..c55590ec0057 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -46,7 +46,7 @@ static int fb_notifier_callback(struct notifier_block *self,
> int fb_blank = 0;
>
> /* If we aren't interested in this event, skip it immediately ... */
> - if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
> + if (event != FB_EVENT_BLANK)
> return 0;
>
> bd = container_of(self, struct backlight_device, fb_notif);
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 259cdd118475..d9f545f1a81b 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2350,8 +2350,6 @@ static int fbcon_switch(struct vc_data *vc)
> static void fbcon_generic_blank(struct vc_data *vc, struct fb_info *info,
> int blank)
> {
> - struct fb_event event;
> -
> if (blank) {
> unsigned short charmask = vc->vc_hi_font_mask ?
> 0x1ff : 0xff;
> @@ -2362,13 +2360,6 @@ static void fbcon_generic_blank(struct vc_data *vc,
> struct fb_info *info,
> fbcon_clear(vc, 0, 0, vc->vc_rows, vc->vc_cols);
> vc->vc_video_erase_char = oldc;
> }
> -
> -
> - lock_fb_info(info);
> - event.info = info;
> - event.data = ␣
> - fb_notifier_call_chain(FB_EVENT_CONBLANK, &event);
> - unlock_fb_info(info);
> }
>
> static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
> @@ -3240,7 +3231,7 @@ int fbcon_fb_registered(struct fb_info *info)
> return ret;
> }
>
> -static void fbcon_fb_blanked(struct fb_info *info, int blank)
> +void fbcon_fb_blanked(struct fb_info *info, int blank)
> {
> struct fbcon_ops *ops = info->fbcon_par;
> struct vc_data *vc;
> @@ -3344,9 +3335,6 @@ static int fbcon_event_notify(struct notifier_block
> *self,
> con2fb = event->data;
> con2fb->framebuffer = con2fb_map[con2fb->console - 1];
> break;
> - case FB_EVENT_BLANK:
> - fbcon_fb_blanked(info, *(int *)event->data);
> - break;
> case FB_EVENT_REMAP_ALL_CONSOLE:
> idx = info->node;
> fbcon_remap_all(idx);
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index ddc0c16b8bbf..9366fbe99a58 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1068,6 +1068,7 @@ fb_blank(struct fb_info *info, int blank)
> event.data = ␣
>
> early_ret = fb_notifier_call_chain(FB_EARLY_EVENT_BLANK, &event);
> + fbcon_fb_blanked(info, blank);
>
> if (info->fbops->fb_blank)
> ret = info->fbops->fb_blank(blank, info);
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 0d86aa31bf8d..1e66fac3124f 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -137,12 +137,10 @@ struct fb_cursor_user {
> #define FB_EVENT_GET_CONSOLE_MAP0x07
> /* CONSOLE-SPECIFIC: set console to framebuffer mapping */
> #define FB_EVENT_SET_CONSOLE_MAP0x08
> -/* A hardware display blank change occurred */
> +/* A display blank is requested */
> #define FB_EVENT_BLANK 0x09
> /* Private modelist is to be replaced */
> #define FB_EVENT_MODE_CHANGE_ALL 0x0B
> -/* A software display blank change occurred */
> -#define FB_EVE
Re: [PATCH v15 14/17] media/v4l2-core, arm64: untag user pointers in videobuf_dma_contig_user_get
Em Mon, 6 May 2019 18:31:00 +0200
Andrey Konovalov escreveu:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> videobuf_dma_contig_user_get() uses provided user pointers for vma
> lookups, which can only by done with untagged pointers.
>
> Untag the pointers in this function.
>
> Signed-off-by: Andrey Konovalov
Acked-by: Mauro Carvalho Chehab
> ---
> drivers/media/v4l2-core/videobuf-dma-contig.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
> b/drivers/media/v4l2-core/videobuf-dma-contig.c
> index e1bf50df4c70..8a1ddd146b17 100644
> --- a/drivers/media/v4l2-core/videobuf-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
> @@ -160,6 +160,7 @@ static void videobuf_dma_contig_user_put(struct
> videobuf_dma_contig_memory *mem)
> static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory
> *mem,
> struct videobuf_buffer *vb)
> {
> + unsigned long untagged_baddr = untagged_addr(vb->baddr);
> struct mm_struct *mm = current->mm;
> struct vm_area_struct *vma;
> unsigned long prev_pfn, this_pfn;
> @@ -167,22 +168,22 @@ static int videobuf_dma_contig_user_get(struct
> videobuf_dma_contig_memory *mem,
> unsigned int offset;
> int ret;
>
> - offset = vb->baddr & ~PAGE_MASK;
> + offset = untagged_baddr & ~PAGE_MASK;
> mem->size = PAGE_ALIGN(vb->size + offset);
> ret = -EINVAL;
>
> down_read(&mm->mmap_sem);
>
> - vma = find_vma(mm, vb->baddr);
> + vma = find_vma(mm, untagged_baddr);
> if (!vma)
> goto out_up;
>
> - if ((vb->baddr + mem->size) > vma->vm_end)
> + if ((untagged_baddr + mem->size) > vma->vm_end)
> goto out_up;
>
> pages_done = 0;
> prev_pfn = 0; /* kill warning */
> - user_address = vb->baddr;
> + user_address = untagged_baddr;
>
> while (pages_done < (mem->size >> PAGE_SHIFT)) {
> ret = follow_pfn(vma, user_address, &this_pfn);
Thanks,
Mauro
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/dsi: Use a fuzzy check for burst mode clock check
Prior to this commit we fail to init the DSI panel on the GPD MicroPC:
https://www.indiegogo.com/projects/gpd-micropc-6-inch-handheld-industry-laptop#/
The problem is intel_dsi_vbt_init() failing with the following error:
*ERROR* Burst mode freq is less than computed
The pclk in the VBT panel modeline is 7, together with 24 bpp and
4 lines this results in a bitrate value of 7 * 24 / 4 = 42.
But the target_burst_mode_freq in the VBT is 418000.
This commit works around this problem by adding an intel_fuzzy_clock_check
when target_burst_mode_freq < bitrate and setting target_burst_mode_freq to
bitrate when that checks succeeds, fixing the panel not working.
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 022bf59418df..a2a9b9d0eeaa 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -895,6 +895,17 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
if (mipi_config->target_burst_mode_freq) {
u32 bitrate = intel_dsi_bitrate(intel_dsi);
+ /*
+* Sometimes the VBT contains a slightly lower clock,
+* then the bitrate we have calculated, in this case
+* just replace it with the calculated bitrate.
+*/
+ if (mipi_config->target_burst_mode_freq < bitrate &&
+ intel_fuzzy_clock_check(
+ mipi_config->target_burst_mode_freq,
+ bitrate))
+ mipi_config->target_burst_mode_freq = bitrate;
+
if (mipi_config->target_burst_mode_freq < bitrate) {
DRM_ERROR("Burst mode freq is less than
computed\n");
return false;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
On Fri, May 24, 2019 at 02:13:59PM +0200, Torsten Duwe wrote:
> On Thu, May 23, 2019 at 07:48:03AM -0700, Vasily Khoruzhick wrote:
> > On Wed, May 22, 2019 at 11:54 PM Torsten Duwe wrote:
> > >
> > >
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > @@ -65,6 +65,21 @@
> > > };
> > > };
> > >
> > > + panel: panel {
> > > + compatible ="innolux,n116bge", "simple-panel";
> >
> > IIRC Rob wanted it to be edp-connector, not simple-panel. Also you
> > need to introduce edp-connector binding.
>
> This line is identically found in
> arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi and
> arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
That's not really an argument though. These are using rather old
bindings, and realising that they are flawed and fixing these flaws is
a natural process.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/vmwgfx: remove custom ioctl io encoding check
On Fri, 2019-05-24 at 13:14 +0100, Emil Velikov wrote: > On 2019/05/23, Thomas Hellstrom wrote: > > Hi, Emil, > > > > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote: > > > From: Emil Velikov > > > > > > Drop the custom ioctl io encoding check - core drm does it for > > > us. > > > > I fail to see where the core does this, or do I miss something? > > drm_ioctl() allows for the encoding to be changed and attributes that > only the > appropriate size is copied in/out of the kernel. > > Technically the function is more relaxed relative to the vmwgfx > check, yet > seems perfectly reasonable. > > Is there any corner-case that isn't but should be handled in > drm_ioctl()? I'd like to turn the question around and ask whether there's a reason we should relax the vmwgfx test? In the past it has trapped quite a few user-space errors. Thanks, Thomas > > -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm: panel-orientation-quirks: Add quirk for GPD MicroPC
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_micropc data struct may very well need to be updated
with some extra bios-dates in the future.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 98679c831f66..d8a0bcd02f34 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -42,6 +42,14 @@ static const struct drm_dmi_panel_orientation_data
asus_t100ha = {
.orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
};
+static const struct drm_dmi_panel_orientation_data gpd_micropc = {
+ .width = 720,
+ .height = 1280,
+ .bios_dates = (const char * const []){ "04/26/2019",
+ NULL },
+ .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
static const struct drm_dmi_panel_orientation_data gpd_pocket = {
.width = 1200,
.height = 1920,
@@ -107,6 +115,14 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
},
.driver_data = (void *)&asus_t100ha,
+ }, {/* GPD MicroPC (generic strings, also match on bios date) */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
+ },
+ .driver_data = (void *)&gpd_micropc,
}, {/*
* GPD Pocket, note that the the DMI data is less generic then
* it seems, devices with a board-vendor of "AMI Corporation"
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm: panel-orientation-quirks: Add quirk for GPD pocket2
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_pocket2 data struct may very well need to be updated
with some extra bios-dates in the future.
Changes in v2:
-Add one more known BIOS date to the list of BIOS dates
Cc: Jurgen Kramer
Reported-by: Jurgen Kramer
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 521aff99b08a..98679c831f66 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -50,6 +50,14 @@ static const struct drm_dmi_panel_orientation_data
gpd_pocket = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+static const struct drm_dmi_panel_orientation_data gpd_pocket2 = {
+ .width = 1200,
+ .height = 1920,
+ .bios_dates = (const char * const []){ "06/28/2018", "08/28/2018",
+ "12/07/2018", NULL },
+ .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
static const struct drm_dmi_panel_orientation_data gpd_win = {
.width = 720,
.height = 1280,
@@ -112,6 +120,14 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
},
.driver_data = (void *)&gpd_pocket,
+ }, {/* GPD Pocket 2 (generic strings, also match on bios date) */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
+ },
+ .driver_data = (void *)&gpd_pocket2,
}, {/* GPD Win (same note on DMI match as GPD Pocket) */
.matches = {
DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] media: uapi: Add RGB bus formats for the GiantPlus GPM940B0 panel
Em Mon, 22 Apr 2019 11:37:21 +0200 Paul Cercueil escreveu: > The GiantPlus GPM940B0 is a 24-bit TFT panel where the RGB components > are transferred sequentially on a 8-bit bus. > > Signed-off-by: Paul Cercueil > --- > > Notes: > v2: New patch > > v3: No change > > include/uapi/linux/media-bus-format.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/media-bus-format.h > b/include/uapi/linux/media-bus-format.h > index d6a5a3bfe6c4..f31724d6cd40 100644 > --- a/include/uapi/linux/media-bus-format.h > +++ b/include/uapi/linux/media-bus-format.h > @@ -34,7 +34,7 @@ > > #define MEDIA_BUS_FMT_FIXED 0x0001 > > -/* RGB - next is 0x101b */ > +/* RGB - next is 0x101d */ > #define MEDIA_BUS_FMT_RGB444_1X120x1016 > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE0x1001 > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE0x1002 > @@ -54,6 +54,8 @@ > #define MEDIA_BUS_FMT_RGB888_1X240x100a > #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b > #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c > +#define MEDIA_BUS_FMT_RGB888_3X8_BE 0x101b > +#define MEDIA_BUS_FMT_RGB888_3X8_LE 0x101c > #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG 0x1011 > #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012 > #define MEDIA_BUS_FMT_ARGB_1X32 0x100d You should also patch the documentation text at: Documentation/media/uapi/v4l/subdev-formats.rst In order to describe the new formats that will be included. (also patch needs to be rebased, as it conflicts to some other new formats added there) Thanks, Mauro
RFC: Run a dedicated hmm.git for 5.3
On Thu, May 23, 2019 at 11:40:51PM -0700, Christoph Hellwig wrote: > On Thu, May 23, 2019 at 04:10:38PM -0300, Jason Gunthorpe wrote: > > > > On Thu, May 23, 2019 at 02:24:58PM -0400, Jerome Glisse wrote: > > > I can not take mmap_sem in range_register, the READ_ONCE is fine and > > > they are no race as we do take a reference on the hmm struct thus > > > > Of course there are use after free races with a READ_ONCE scheme, I > > shouldn't have to explain this. > > > > If you cannot take the read mmap sem (why not?), then please use my > > version and push the update to the driver through -mm.. > > I think it would really help if we queue up these changes in a git tree > that can be pulled into the driver trees. Given that you've been > doing so much work to actually make it usable I'd nominate rdma for the > "lead" tree. Sure, I'm willing to do that. RDMA has experience successfully running shared git trees with netdev. It can work very well, but requires discipline and understanding of the limitations. I really want to see the complete HMM solution from Jerome (ie the kconfig fixes, arm64, api fixes, etc) in one cohesive view, not forced to be sprinkled across multiple kernel releases to work around a submission process/coordination problem. Now that -mm merged the basic hmm API skeleton I think running like this would get us quickly to the place we all want: comprehensive in tree users of hmm. Andrew, would this be acceptable to you? Dave, would you be willing to merge a clean HMM tree into DRM if it is required for DRM driver work in 5.3? I'm fine to merge a tree like this for RDMA, we already do this pattern with netdev. Background: The issue that is motivating this is we want to make changes to some of the API's for hmm, which mean changes in existing DRM, changes in to-be-accepted RDMA code, and to-be-accepted DRM driver code. Coordintating the mm/hmm.c, RDMA and DRM changes is best done with the proven shared git tree pattern. As CH explains I would run a clean/minimal hmm tree that can be merged into driver trees as required, and I will commit to sending a PR to Linus for this tree very early in the merge window so that driver PR's are 'clean'. The tree will only contain uncontroversial hmm related commits, bug fixes, etc. Obviouisly I will also commit to providing review for patches flowing through this tree. Regards, Jason (rdma subsystem co-maintainer, FWIW)
[PATCH v2] drm/vmwgfx: fix a warning due to missing dma_parms
Booting up with DMA_API_DEBUG_SG=y generates a warning due to the driver
forgot to set dma_parms appropriately. Set it just after vmw_dma_masks()
in vmw_driver_load().
DMA-API: vmwgfx :00:0f.0: mapping sg segment longer than device
claims to support [len=2097152] [max=65536]
WARNING: CPU: 2 PID: 261 at kernel/dma/debug.c:1232
debug_dma_map_sg+0x360/0x480
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop
Reference Platform, BIOS 6.00 04/13/2018
RIP: 0010:debug_dma_map_sg+0x360/0x480
Call Trace:
vmw_ttm_map_dma+0x3b1/0x5b0 [vmwgfx]
vmw_bo_map_dma+0x25/0x30 [vmwgfx]
vmw_otables_setup+0x2a8/0x750 [vmwgfx]
vmw_request_device_late+0x78/0xc0 [vmwgfx]
vmw_request_device+0xee/0x4e0 [vmwgfx]
vmw_driver_load.cold+0x757/0xd84 [vmwgfx]
drm_dev_register+0x1ff/0x340 [drm]
drm_get_pci_dev+0x110/0x290 [drm]
vmw_probe+0x15/0x20 [vmwgfx]
local_pci_probe+0x7a/0xc0
pci_device_probe+0x1b9/0x290
really_probe+0x1b5/0x630
driver_probe_device+0xa3/0x1a0
device_driver_attach+0x94/0xa0
__driver_attach+0xdd/0x1c0
bus_for_each_dev+0xfe/0x150
driver_attach+0x2d/0x40
bus_add_driver+0x290/0x350
driver_register+0xdc/0x1d0
__pci_register_driver+0xda/0xf0
vmwgfx_init+0x34/0x1000 [vmwgfx]
do_one_initcall+0xe5/0x40a
do_init_module+0x10f/0x3a0
load_module+0x16a5/0x1a40
__se_sys_finit_module+0x183/0x1c0
__x64_sys_finit_module+0x43/0x50
do_syscall_64+0xc8/0x606
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
Signed-off-by: Qian Cai
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index bf6c3500d363..e10fe109ee48 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -747,6 +747,8 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
if (unlikely(ret != 0))
goto out_err0;
+ dma_set_max_seg_size(dev->dev, U32_MAX);
+
if (dev_priv->capabilities & SVGA_CAP_GMR2) {
DRM_INFO("Max GMR ids is %u\n",
(unsigned)dev_priv->max_gmr_ids);
--
2.20.1 (Apple Git-117)
Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
On 5/24/19 2:03 PM, Koenig, Christian wrote: Am 24.05.19 um 12:37 schrieb Thomas Hellstrom: [CAUTION: External Email] On 5/24/19 12:18 PM, Koenig, Christian wrote: Am 24.05.19 um 11:55 schrieb Thomas Hellstrom: [CAUTION: External Email] On 5/24/19 11:11 AM, Thomas Hellstrom wrote: Hi, Christian, On 5/24/19 10:37 AM, Koenig, Christian wrote: Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware): [CAUTION: External Email] From: Thomas Hellstrom With SEV encryption, all DMA memory must be marked decrypted (AKA "shared") for devices to be able to read it. In the future we might want to be able to switch normal (encrypted) memory to decrypted in exactly the same way as we handle caching states, and that would require additional memory pools. But for now, rely on memory allocated with dma_alloc_coherent() which is already decrypted with SEV enabled. Set up the page protection accordingly. Drivers must detect SEV enabled and switch to the dma page pool. This patch has not yet been tested. As a follow-up, we might want to cache decrypted pages in the dma page pool regardless of their caching state. This patch is unnecessary, SEV support already works fine with at least amdgpu and I would expect that it also works with other drivers as well. Also see this patch: commit 64e1f830ea5b3516a4256ed1c504a265d7f2a65c Author: Christian König Date: Wed Mar 13 10:11:19 2019 +0100 drm: fallback to dma_alloc_coherent when memory encryption is active We can't just map any randome page we get when memory encryption is active. Signed-off-by: Christian König Acked-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10850833/ Regards, Christian. Yes, I noticed that. Although I fail to see where we automagically clear the PTE encrypted bit when mapping coherent memory? For the linear kernel map, that's done within dma_alloc_coherent() but for kernel vmaps and and user-space maps? Is that done automatically by the x86 platform layer? Yes, I think so. Haven't looked to closely at this either. This sounds a bit odd. If that were the case, the natural place would be the PAT tracking code, but it only handles caching flags AFAICT. Not encryption flags. But when you tested AMD with SEV, was that running as hypervisor rather than a guest, or did you run an SEV guest with PCI passthrough to the AMD device? Yeah, well the problem is we never tested this ourself :) /Thomas And, as a follow up question, why do we need dma_alloc_coherent() when using SME? I thought the hardware performs the decryption when DMA-ing to / from an encrypted page with SME, but not with SEV? I think the issue was that the DMA API would try to use a bounce buffer in this case. SEV forces SWIOTLB bouncing on, but not SME. So it should probably be possible to avoid dma_alloc_coherent() in the SME case. In this case I don't have an explanation for this. For the background what happened is that we got reports that SVE/SME doesn't work with amdgpu. So we told the people to try using the dma_alloc_coherent() path and that worked fine. Because of this we came up with the patch I noted earlier. I can confirm that it indeed works now for a couple of users, but we still don't have a test system for this in our team. Christian. OK, undestood, But unless there is some strange magic going on, (which there might be of course),I do think the patch I sent is correct, and the reason that SEV works is that the AMD card is used by the hypervisor and not the guest, and TTM is actually incorrectly creating conflicting maps and treating the coherent memory as encrypted. But since the memory is only accessed through encrypted PTEs, the hardware does the right thing, using the hypervisor key for decryption But that's only a guess, and this is not super-urgent. I will be able to follow up if / when we bring vmwgfx up for SEV. /Thomas /Thomas Christian. Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
It seems I get the same freezes than you. It takes hours of gaming to get some random hard hang (no log). I thought I was overheating, but realized that my system is on "vacation" while playing. linux amd-staging-drm-new/x11 native/mesa/llvm(erk...), all git no older than a week. playing mostly dota2 vulkan on AMD TAHITI XT ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #23 from Sylvain BERTRAND --- It seems I get the same freezes than you. It takes hours of gaming to get some random hard hang (no log). I thought I was overheating, but realized that my system is on "vacation" while playing. linux amd-staging-drm-new/x11 native/mesa/llvm(erk...), all git no older than a week. playing mostly dota2 vulkan on AMD TAHITI XT -- 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 v11 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs
Hi Kishon, On Sun, May 12, 2019 at 7:49 AM Guido Günther wrote: > > This adds support for the Mixel DPHY as found on i.MX8 CPUs but since > this is an IP core it will likely be found on others in the future. So > instead of adding this to the nwl host driver make it a generic PHY > driver. > > The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be > added once the necessary system controller bits are in via > mixel_dphy_devdata. > > Signed-off-by: Guido Günther > Co-developed-by: Robert Chiras > Signed-off-by: Robert Chiras > Reviewed-by: Fabio Estevam > Reviewed-by: Sam Ravnborg Would you have any comments on this series, please? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/vmwgfx: remove custom ioctl io encoding check
On 2019/05/23, Thomas Hellstrom wrote: > Hi, Emil, > > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote: > > From: Emil Velikov > > > > Drop the custom ioctl io encoding check - core drm does it for us. > > I fail to see where the core does this, or do I miss something? drm_ioctl() allows for the encoding to be changed and attributes that only the appropriate size is copied in/out of the kernel. Technically the function is more relaxed relative to the vmwgfx check, yet seems perfectly reasonable. Is there any corner-case that isn't but should be handled in drm_ioctl()? -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
On Thu, May 23, 2019 at 07:48:03AM -0700, Vasily Khoruzhick wrote:
> On Wed, May 22, 2019 at 11:54 PM Torsten Duwe wrote:
> >
> >
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > @@ -65,6 +65,21 @@
> > };
> > };
> >
> > + panel: panel {
> > + compatible ="innolux,n116bge", "simple-panel";
>
> IIRC Rob wanted it to be edp-connector, not simple-panel. Also you
> need to introduce edp-connector binding.
This line is identically found in
arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi and
arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
> > + status = "okay";
> > + power-supply = <®_dcdc1>;
> > + backlight = <&backlight>;
> > +
> > + ports {
> > + panel_in: port {
> > + panel_in_edp: endpoint {
> > + remote-endpoint = <&anx6345_out>;
> > + };
> > + };
> > + };
The whole node is the same as in rk3288-veyron-chromebook.dtsi; I only adapted
the power-supply and remote-endpoint properties.
Is there anything wrong with that?
Torsten
Re: [PATCH] drm/komeda: Added AFBC support for komeda driver
On Fri, May 24, 2019 at 11:10:09AM +, Brian Starkey wrote:
> Hi,
>
> On Tue, May 21, 2019 at 09:45:58AM +0100, james qian wang (Arm Technology
> China) wrote:
> > On Thu, May 16, 2019 at 09:57:49PM +0800, Ayan Halder wrote:
> > > On Thu, Apr 04, 2019 at 12:06:14PM +0100, james qian wang (Arm Technology
> > > China) wrote:
> > > >
> > > > +static int
> > > > +komeda_fb_afbc_size_check(struct komeda_fb *kfb, struct drm_file *file,
> > > > + const struct drm_mode_fb_cmd2 *mode_cmd)
> > > > +{
> > > > + struct drm_framebuffer *fb = &kfb->base;
> > > > + const struct drm_format_info *info = fb->format;
> > > > + struct drm_gem_object *obj;
> > > > + u32 alignment_w = 0, alignment_h = 0, alignment_header;
> > > > + u32 n_blocks = 0, min_size = 0;
> > > > +
> > > > + obj = drm_gem_object_lookup(file, mode_cmd->handles[0]);
> > > > + if (!obj) {
> > > > + DRM_DEBUG_KMS("Failed to lookup GEM object\n");
> > > > + return -ENOENT;
> > > > + }
> > > > +
> > > > + switch (fb->modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> > > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
> > > > + alignment_w = 32;
> > > > + alignment_h = 8;
> > > > + break;
> > > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> > > > + alignment_w = 16;
> > > > + alignment_h = 16;
> > > > + break;
> > > > + default:
> > > Can we have something like a warn here ?
> >
> > will add a WARN here.
> >
>
> I think it's better not to. fb->modifier comes from
> userspace, so a malicious app could spam us with WARNs, effectively
> dos-ing the system. -EINVAL should be sufficient.
Should probably check that the entire modifier+format is
actually valid. Otherwise you risk passing on a bogus
modifier deeper into the driver which may trigger
interesting bugs.
Also theoretically (however unlikely) some broken userspace
might start to depend on the ability to create framebuffers
with crap modifiers, which could later break if you change
the way you handle the modifiers. Then you're stuck between
the rock and hard place because you can't break existing
userspace but you still want to change the way modifiers
are handled in the kernel.
Best not give userspace too much rope IMO. Two ways to go about
that:
1) drm_any_plane_has_format() (assumes your .format_mod_supported()
does its job properly)
2) roll your own
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/8] drm/fb-helper: Move modesetting code to drm_client
On Thu, May 23, 2019 at 06:53:20PM +0200, Sam Ravnborg wrote: > Hi Linus, Gerd. > > > This moves the modesetting code from drm_fb_helper to drm_client so it > > can be shared by all internal clients. > > Could one of you take a look at this series. > Daniel already ack'ed the series on irc, but an extra pair of eyes > is never bad. > > For my part I have been through them all, but I still do not have > the full picture of the DRM subsystem so my review may not > suffice. Looks sane to me overall. Tried to give the series a spin in qemu, but: ERROR: "drm_client_panel_rotation" [drivers/gpu/drm/drm_kms_helper.ko] undefined! EXPORT_SYMBOL() missing? cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
Am 24.05.19 um 12:37 schrieb Thomas Hellstrom: > [CAUTION: External Email] > > On 5/24/19 12:18 PM, Koenig, Christian wrote: >> Am 24.05.19 um 11:55 schrieb Thomas Hellstrom: >>> [CAUTION: External Email] >>> >>> On 5/24/19 11:11 AM, Thomas Hellstrom wrote: Hi, Christian, On 5/24/19 10:37 AM, Koenig, Christian wrote: > Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware): >> [CAUTION: External Email] >> >> From: Thomas Hellstrom >> >> With SEV encryption, all DMA memory must be marked decrypted >> (AKA "shared") for devices to be able to read it. In the future we >> might >> want to be able to switch normal (encrypted) memory to decrypted in >> exactly >> the same way as we handle caching states, and that would require >> additional >> memory pools. But for now, rely on memory allocated with >> dma_alloc_coherent() which is already decrypted with SEV enabled. >> Set up >> the page protection accordingly. Drivers must detect SEV enabled and >> switch >> to the dma page pool. >> >> This patch has not yet been tested. As a follow-up, we might want to >> cache decrypted pages in the dma page pool regardless of their >> caching >> state. > This patch is unnecessary, SEV support already works fine with at > least > amdgpu and I would expect that it also works with other drivers as > well. > > Also see this patch: > > commit 64e1f830ea5b3516a4256ed1c504a265d7f2a65c > Author: Christian König > Date: Wed Mar 13 10:11:19 2019 +0100 > > drm: fallback to dma_alloc_coherent when memory encryption is > active > > We can't just map any randome page we get when memory > encryption is > active. > > Signed-off-by: Christian König > Acked-by: Alex Deucher > Link: https://patchwork.kernel.org/patch/10850833/ > > Regards, > Christian. Yes, I noticed that. Although I fail to see where we automagically clear the PTE encrypted bit when mapping coherent memory? For the linear kernel map, that's done within dma_alloc_coherent() but for kernel vmaps and and user-space maps? Is that done automatically by the x86 platform layer? >> Yes, I think so. Haven't looked to closely at this either. > > This sounds a bit odd. If that were the case, the natural place would be > the PAT tracking code, but it only handles caching flags AFAICT. Not > encryption flags. > > But when you tested AMD with SEV, was that running as hypervisor rather > than a guest, or did you run an SEV guest with PCI passthrough to the > AMD device? Yeah, well the problem is we never tested this ourself :) > >> /Thomas >>> And, as a follow up question, why do we need dma_alloc_coherent() when >>> using SME? I thought the hardware performs the decryption when DMA-ing >>> to / from an encrypted page with SME, but not with SEV? >> I think the issue was that the DMA API would try to use a bounce buffer >> in this case. > > SEV forces SWIOTLB bouncing on, but not SME. So it should probably be > possible to avoid dma_alloc_coherent() in the SME case. In this case I don't have an explanation for this. For the background what happened is that we got reports that SVE/SME doesn't work with amdgpu. So we told the people to try using the dma_alloc_coherent() path and that worked fine. Because of this we came up with the patch I noted earlier. I can confirm that it indeed works now for a couple of users, but we still don't have a test system for this in our team. Christian. > > /Thomas > > >> >> Christian. >> >>> Thanks, Thomas >>> >>> >>> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: assure aux_dev is nonzero before using it
On Fri, May 24, 2019 at 06:48:32AM -0400, tony camuso wrote: > On 5/24/19 4:36 AM, Jani Nikula wrote: > > On Thu, 23 May 2019, tcamuso wrote: > >> From Daniel Kwon > >> > >> The system was crashed due to invalid memory access while trying to access > >> auxiliary device. > >> > >> crash> bt > >> PID: 9863 TASK: 89d1bdf11040 CPU: 1 COMMAND: "ipmitool" > >> #0 [89cedd7f3868] machine_kexec at b0663674 > >> #1 [89cedd7f38c8] __crash_kexec at b071cf62 > >> #2 [89cedd7f3998] crash_kexec at b071d050 > >> #3 [89cedd7f39b0] oops_end at b0d6d758 > >> #4 [89cedd7f39d8] no_context at b0d5bcde > >> #5 [89cedd7f3a28] __bad_area_nosemaphore at b0d5bd75 > >> #6 [89cedd7f3a78] bad_area at b0d5c085 > >> #7 [89cedd7f3aa0] __do_page_fault at b0d7080c > >> #8 [89cedd7f3b10] do_page_fault at b0d70905 > >> #9 [89cedd7f3b40] page_fault at b0d6c758 > >> [exception RIP: drm_dp_aux_dev_get_by_minor+0x3d] > >> RIP: c0a589bd RSP: 89cedd7f3bf0 RFLAGS: 00010246 > >> RAX: RBX: RCX: 89cedd7f3fd8 > >> RDX: RSI: RDI: c0a613e0 > >> RBP: 89cedd7f3bf8 R8: 89f1bcbabbd0 R9: > >> R10: 89f1be7a1cc0 R11: R12: > >> R13: 89f1b32a2830 R14: 89d18fadfa00 R15: > >> ORIG_RAX: CS: 0010 SS: 0018 > >> RIP: 2b45f0d80d30 RSP: 7ffc416066a0 RFLAGS: 00010246 > >> RAX: 0002 RBX: 56062e212d80 RCX: 7ffc41606810 > >> RDX: RSI: 0002 RDI: 7ffc41606ec0 > >> RBP: R8: 56062dfed229 R9: 2b45f0cdf14d > >> R10: 0002 R11: 0246 R12: 7ffc41606ec0 > >> R13: 7ffc41606ed0 R14: 7ffc41606ee0 R15: > >> ORIG_RAX: 0002 CS: 0033 SS: 002b > >> > >> > >> > >> It was trying to open '/dev/ipmi0', but as no entry in aux_dir, it returned > >> NULL from 'idr_find()'. This drm_dp_aux_dev_get_by_minor() should have > >> done a > >> check on this, but had failed to do it. > > > > I think the better question is, *why* does the idr_find() return NULL? I > > don't think it should, under any circumstances. I fear adding the check > > here papers over some other problem, taking us further away from the > > root cause. > > That's a very good question. > > > Also, can you reproduce this on a recent upstream kernel? The aux device > > nodes were introduced in kernel v4.6. Whatever you reproduced on v3.10 > > is pretty much irrelevant for upstream. > > I will look into this deeper, using the upstream kernel. Should be trivial to reproduce with mknod. I wonder if we should stick a test like that into igt actually. Not sure how happy people would be if igt creates new device nodes... -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] video: fbdev: pvr2fb: add COMPILE_TEST support
Add COMPILE_TEST support to pvr2fb driver for better compile
testing coverage.
While at it:
- mark pvr2fb_interrupt() and pvr2fb_common_init() with
__maybe_unused tag (to silence build warnings when
!SH_DREAMCAST)
- convert mmio_base in struct pvr2fb_par to 'void __iomem *'
from 'unsigned long' (needed to silence build warnings on
ARM).
- split pvr2_get_param() on pvr2_get_param_name() and
pvr2_get_param_val() (needed to silence build warnings on
x86).
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v3: fix 'space prohibited before that close parenthesis ')'
checkpatch errors
v2: fix build warnings on x86 reported by kbuild test robot
patch #1/2 is unchanged so I'm not sending it again
drivers/video/fbdev/Kconfig |3 +-
drivers/video/fbdev/pvr2fb.c | 61 +++
2 files changed, 36 insertions(+), 28 deletions(-)
Index: b/drivers/video/fbdev/Kconfig
===
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -807,7 +807,8 @@ config FB_XVR1000
config FB_PVR2
tristate "NEC PowerVR 2 display support"
- depends on FB && SH_DREAMCAST
+ depends on FB && HAS_IOMEM
+ depends on SH_DREAMCAST || COMPILE_TEST
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
Index: b/drivers/video/fbdev/pvr2fb.c
===
--- a/drivers/video/fbdev/pvr2fb.c
+++ b/drivers/video/fbdev/pvr2fb.c
@@ -139,7 +139,7 @@ static struct pvr2fb_par {
unsigned char is_doublescan;/* Are scanlines output twice?
(doublescan) */
unsigned char is_lowres;/* Is horizontal pixel-doubling
enabled? */
- unsigned long mmio_base;/* MMIO base */
+ void __iomem *mmio_base;/* MMIO base */
u32 palette[16];
} *currentpar;
@@ -325,9 +325,9 @@ static int pvr2fb_setcolreg(unsigned int
* anything if the cable type has been overidden (via "cable:XX").
*/
-#define PCTRA 0xff80002c
-#define PDTRA 0xff800030
-#define VOUTC 0xa0702c00
+#define PCTRA ((void __iomem *)0xff80002c)
+#define PDTRA ((void __iomem *)0xff800030)
+#define VOUTC ((void __iomem *)0xa0702c00)
static int pvr2_init_cable(void)
{
@@ -619,7 +619,7 @@ static void pvr2_do_blank(void)
is_blanked = do_blank > 0 ? do_blank : 0;
}
-static irqreturn_t pvr2fb_interrupt(int irq, void *dev_id)
+static irqreturn_t __maybe_unused pvr2fb_interrupt(int irq, void *dev_id)
{
struct fb_info *info = dev_id;
@@ -722,23 +722,30 @@ static struct fb_ops pvr2fb_ops = {
.fb_imageblit = cfb_imageblit,
};
-static int pvr2_get_param(const struct pvr2_params *p, const char *s, int val,
- int size)
+static int pvr2_get_param_val(const struct pvr2_params *p, const char *s,
+ int size)
{
int i;
- for (i = 0 ; i < size ; i++ ) {
- if (s != NULL) {
- if (!strncasecmp(p[i].name, s, strlen(s)))
- return p[i].val;
- } else {
- if (p[i].val == val)
- return (int)p[i].name;
- }
+ for (i = 0 ; i < size; i++) {
+ if (!strncasecmp(p[i].name, s, strlen(s)))
+ return p[i].val;
}
return -1;
}
+static char *pvr2_get_param_name(const struct pvr2_params *p, int val,
+ int size)
+{
+ int i;
+
+ for (i = 0 ; i < size; i++) {
+ if (p[i].val == val)
+ return p[i].name;
+ }
+ return NULL;
+}
+
/**
* pvr2fb_common_init
*
@@ -757,7 +764,7 @@ static int pvr2_get_param(const struct p
* in for flexibility anyways. Who knows, maybe someone has tv-out on a
* PCI-based version of these things ;-)
*/
-static int pvr2fb_common_init(void)
+static int __maybe_unused pvr2fb_common_init(void)
{
struct pvr2fb_par *par = currentpar;
unsigned long modememused, rev;
@@ -770,8 +777,8 @@ static int pvr2fb_common_init(void)
goto out_err;
}
- par->mmio_base = (unsigned long)ioremap_nocache(pvr2_fix.mmio_start,
- pvr2_fix.mmio_len);
+ par->mmio_base = ioremap_nocache(pvr2_fix.mmio_start,
+pvr2_fix.mmio_len);
if (!par->mmio_base) {
printk(KERN_ERR "pvr2fb: Failed to remap mmio space\n");
goto out_err;
@@ -819,8 +826,8 @@ static int pvr2fb_common_init(void)
fb_info->var.xres, fb_info->var.yres,
fb_info->var.bits_per_pixel,
get_line_length(fb_info->var.xres, fb_info->var.bits_per_pixel),
- (char *)pvr2_get_param(cables, NULL, cable_type, 3),
- (char *)pvr2_get_param(outputs,
Re: [PATCH] drm/vmwgfx: fix a warning due to missing dma_parms
On Fri, 2019-05-24 at 08:19 +0200, Christoph Hellwig wrote: > On Thu, May 23, 2019 at 10:37:19PM -0400, Qian Cai wrote: > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > > index bf6c3500d363..5c567b81174f 100644 > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > > @@ -747,6 +747,13 @@ static int vmw_driver_load(struct drm_device > > *dev, unsigned long chipset) > > if (unlikely(ret != 0)) > > goto out_err0; > > > > + dev->dev->dma_parms = kzalloc(sizeof(*dev->dev->dma_parms), > > + GFP_KERNEL); > > + if (!dev->dev->dma_parms) > > + goto out_err0; > > What bus does this device come from? I though vmgfx was a > (virtualized) > PCI device, in which case this should be provided by the PCI core. > Or are we calling DMA mapping routines on arbitrary other struct > device, > in which case that is the real bug and we should switch the PCI > device > instead. It's a PCI device. The struct device * used in dma_map_sg() is the same as the &pci_dev->dev handed to the probe() callback. But at probe time, the struct device::dma_parms is non-NULL, at least on my system so there shouldn't really be a need to kzalloc() it. > > > + dma_set_max_seg_size(dev->dev, *dev->dev->dma_mask); The max is U32_MAX. /Thomas > > That looks odd. If you want to support an unlimited segment size > just pass UINT_MAX here. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] video: fbdev: pvr2fb: add COMPILE_TEST support
Add COMPILE_TEST support to pvr2fb driver for better compile
testing coverage.
While at it:
- mark pvr2fb_interrupt() and pvr2fb_common_init() with
__maybe_unused tag (to silence build warnings when
!SH_DREAMCAST)
- convert mmio_base in struct pvr2fb_par to 'void __iomem *'
from 'unsigned long' (needed to silence build warnings on
ARM).
- split pvr2_get_param() on pvr2_get_param_name() and
pvr2_get_param_val() (needed to silence build warnings on
x86).
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2: fix build warnings on x86 reported by kbuild test robot
patch #1/2 is unchanged so I'm not sending it again
drivers/video/fbdev/Kconfig |3 +-
drivers/video/fbdev/pvr2fb.c | 61 +++
2 files changed, 36 insertions(+), 28 deletions(-)
Index: b/drivers/video/fbdev/Kconfig
===
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -807,7 +807,8 @@ config FB_XVR1000
config FB_PVR2
tristate "NEC PowerVR 2 display support"
- depends on FB && SH_DREAMCAST
+ depends on FB && HAS_IOMEM
+ depends on SH_DREAMCAST || COMPILE_TEST
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
Index: b/drivers/video/fbdev/pvr2fb.c
===
--- a/drivers/video/fbdev/pvr2fb.c
+++ b/drivers/video/fbdev/pvr2fb.c
@@ -139,7 +139,7 @@ static struct pvr2fb_par {
unsigned char is_doublescan;/* Are scanlines output twice?
(doublescan) */
unsigned char is_lowres;/* Is horizontal pixel-doubling
enabled? */
- unsigned long mmio_base;/* MMIO base */
+ void __iomem *mmio_base;/* MMIO base */
u32 palette[16];
} *currentpar;
@@ -325,9 +325,9 @@ static int pvr2fb_setcolreg(unsigned int
* anything if the cable type has been overidden (via "cable:XX").
*/
-#define PCTRA 0xff80002c
-#define PDTRA 0xff800030
-#define VOUTC 0xa0702c00
+#define PCTRA ((void __iomem *)0xff80002c)
+#define PDTRA ((void __iomem *)0xff800030)
+#define VOUTC ((void __iomem *)0xa0702c00)
static int pvr2_init_cable(void)
{
@@ -619,7 +619,7 @@ static void pvr2_do_blank(void)
is_blanked = do_blank > 0 ? do_blank : 0;
}
-static irqreturn_t pvr2fb_interrupt(int irq, void *dev_id)
+static irqreturn_t __maybe_unused pvr2fb_interrupt(int irq, void *dev_id)
{
struct fb_info *info = dev_id;
@@ -722,23 +722,30 @@ static struct fb_ops pvr2fb_ops = {
.fb_imageblit = cfb_imageblit,
};
-static int pvr2_get_param(const struct pvr2_params *p, const char *s, int val,
- int size)
+static int pvr2_get_param_val(const struct pvr2_params *p, const char *s,
+ int size)
{
int i;
- for (i = 0 ; i < size ; i++ ) {
- if (s != NULL) {
- if (!strncasecmp(p[i].name, s, strlen(s)))
- return p[i].val;
- } else {
- if (p[i].val == val)
- return (int)p[i].name;
- }
+ for (i = 0 ; i < size; i++ ) {
+ if (!strncasecmp(p[i].name, s, strlen(s)))
+ return p[i].val;
}
return -1;
}
+static char *pvr2_get_param_name(const struct pvr2_params *p, int val,
+ int size)
+{
+ int i;
+
+ for (i = 0 ; i < size; i++ ) {
+ if (p[i].val == val)
+ return p[i].name;
+ }
+ return NULL;
+}
+
/**
* pvr2fb_common_init
*
@@ -757,7 +764,7 @@ static int pvr2_get_param(const struct p
* in for flexibility anyways. Who knows, maybe someone has tv-out on a
* PCI-based version of these things ;-)
*/
-static int pvr2fb_common_init(void)
+static int __maybe_unused pvr2fb_common_init(void)
{
struct pvr2fb_par *par = currentpar;
unsigned long modememused, rev;
@@ -770,8 +777,8 @@ static int pvr2fb_common_init(void)
goto out_err;
}
- par->mmio_base = (unsigned long)ioremap_nocache(pvr2_fix.mmio_start,
- pvr2_fix.mmio_len);
+ par->mmio_base = ioremap_nocache(pvr2_fix.mmio_start,
+pvr2_fix.mmio_len);
if (!par->mmio_base) {
printk(KERN_ERR "pvr2fb: Failed to remap mmio space\n");
goto out_err;
@@ -819,8 +826,8 @@ static int pvr2fb_common_init(void)
fb_info->var.xres, fb_info->var.yres,
fb_info->var.bits_per_pixel,
get_line_length(fb_info->var.xres, fb_info->var.bits_per_pixel),
- (char *)pvr2_get_param(cables, NULL, cable_type, 3),
- (char *)pvr2_get_param(outputs, NULL, video_output, 3));
+ pvr2_get_param_name(cables, cable_type,
Re: [PATCH v2 3/6] drm/sun4i: dsi: Add bridge support
Hi, On Fri, May 24, 2019 at 04:13:14PM +0530, Jagan Teki wrote: > Some display panels would come up with a non-DSI output which > can have an option to connect DSI interface by means of bridge > converter. > > This DSI to non-DSI bridge converter would require a bridge > driver that would communicate the DSI controller for bridge > functionalities. > > So, add support for bridge functionalities in Allwinner DSI > controller. > > Signed-off-by: Jagan Teki > --- > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 60 +++--- > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 1 + > 2 files changed, 45 insertions(+), 16 deletions(-) > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > index ae2fe31b05b1..2b4b1355a88f 100644 > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > @@ -775,6 +775,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder > *encoder) > if (!IS_ERR(dsi->panel)) > drm_panel_prepare(dsi->panel); > > + if (!IS_ERR(dsi->bridge)) > + drm_bridge_pre_enable(dsi->bridge); > + drm_panel_bridge provides what's needed to deal with both a panel and a bridge, I guess it would make sense to use this instead of duplicating everything. 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
Re: [PATCH] drm/komeda: Added AFBC support for komeda driver
Hi,
On Tue, May 21, 2019 at 09:45:58AM +0100, james qian wang (Arm Technology
China) wrote:
> On Thu, May 16, 2019 at 09:57:49PM +0800, Ayan Halder wrote:
> > On Thu, Apr 04, 2019 at 12:06:14PM +0100, james qian wang (Arm Technology
> > China) wrote:
> > >
> > > +static int
> > > +komeda_fb_afbc_size_check(struct komeda_fb *kfb, struct drm_file *file,
> > > + const struct drm_mode_fb_cmd2 *mode_cmd)
> > > +{
> > > + struct drm_framebuffer *fb = &kfb->base;
> > > + const struct drm_format_info *info = fb->format;
> > > + struct drm_gem_object *obj;
> > > + u32 alignment_w = 0, alignment_h = 0, alignment_header;
> > > + u32 n_blocks = 0, min_size = 0;
> > > +
> > > + obj = drm_gem_object_lookup(file, mode_cmd->handles[0]);
> > > + if (!obj) {
> > > + DRM_DEBUG_KMS("Failed to lookup GEM object\n");
> > > + return -ENOENT;
> > > + }
> > > +
> > > + switch (fb->modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
> > > + alignment_w = 32;
> > > + alignment_h = 8;
> > > + break;
> > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> > > + alignment_w = 16;
> > > + alignment_h = 16;
> > > + break;
> > > + default:
> > Can we have something like a warn here ?
>
> will add a WARN here.
>
I think it's better not to. fb->modifier comes from
userspace, so a malicious app could spam us with WARNs, effectively
dos-ing the system. -EINVAL should be sufficient.
Thanks,
-Brian
Re: [PATCH 3/5] drm/vmwgfx: use core drm to extend/check vmw_execbuf_ioctl
On 5/24/19 12:53 PM, Emil Velikov wrote:
On 2019/05/24, Daniel Vetter wrote:
On Fri, May 24, 2019 at 8:05 AM Thomas Hellstrom wrote:
On Wed, 2019-05-22 at 21:09 +0200, Daniel Vetter wrote:
On Wed, May 22, 2019 at 9:01 PM Thomas Hellstrom <
thellst...@vmware.com> wrote:
Hi, Emil,
On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
From: Emil Velikov
Currently vmw_execbuf_ioctl() open-codes the permission checking,
size
extending and copying that is already done in core drm.
Kill all the duplication, adding a few comments for clarity.
Ah, there is core functionality for this now.
What worries me though with the core approach is that the sizes are
not
capped by the size of the kernel argument definition, which makes
mailicious user-space being able to force kmallocs() the size of
the
maximum ioctl size. Should probably be fixed before pushing this.
Hm I always worked under the assumption that kmalloc and friends
should be userspace hardened. Otherwise stuff like kmalloc_array
doesn't make any sense, everyone just feeds it unchecked input and
expects that helper to handle overflows.
If we assume kmalloc isn't hardened against that, then we have a much
bigger problem than just vmwgfx ioctls ...
After checking the drm_ioctl code I realize that what I thought was new
behaviour actually has been around for a couple of years, so
fixing isn't really tied to this patch series...
What caused me to react was that previously we used to have this
e4fda9f264e1 ("drm: Perform ioctl command validation on the stored
kernel values")
and we seem to have lost that now, if not for the io flags then at
least for the size part. For the size of the ioctl arguments, I think
in general if the kernel only touches a subset of the user-space
specified size I see no reason why we should malloc / copy more than
that?
I guess we could optimize that, but we'd probably still need to zero
clear the added size for forward compat with newer userspace. Iirc
we've had some issues in this area.
Now, given the fact that the maximum ioctl argument size is quite
limited, that might not be a big problem or a problem at all. Otherwise
it would be pretty easy for a malicious process to allocate most or all
of a system's resident memory?
The biggest you can allocate from kmalloc is limited by the largest
contiguous chunk alloc_pages gives you, which is limited by MAX_ORDER
from the page buddy allocator. You need lots of process to be able to
exhaust memory like that (and like I said, the entire kernel would be
broken if we'd consider this a security issue). If you want to make
sure that a process group can't exhaust memory this way then you need
to set appropriate cgroups limits.
I do agree with all the sentiments that drm_ioctl() could use some extra
optimisation and hardening. At the same time I would remind that the
code has been used as-is by vmwgfx and other drivers for years.
In other words: let's keep that work as orthogonal series.
What do you guys think?
I agree. Then I only had a concern with one of the patches.
/Thomas
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/vmwgfx: use core drm to extend/check vmw_execbuf_ioctl
On 2019/05/24, Daniel Vetter wrote:
> On Fri, May 24, 2019 at 8:05 AM Thomas Hellstrom
> wrote:
> >
> > On Wed, 2019-05-22 at 21:09 +0200, Daniel Vetter wrote:
> > > On Wed, May 22, 2019 at 9:01 PM Thomas Hellstrom <
> > > thellst...@vmware.com> wrote:
> > > > Hi, Emil,
> > > >
> > > > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> > > > > From: Emil Velikov
> > > > >
> > > > > Currently vmw_execbuf_ioctl() open-codes the permission checking,
> > > > > size
> > > > > extending and copying that is already done in core drm.
> > > > >
> > > > > Kill all the duplication, adding a few comments for clarity.
> > > >
> > > > Ah, there is core functionality for this now.
> > > >
> > > > What worries me though with the core approach is that the sizes are
> > > > not
> > > > capped by the size of the kernel argument definition, which makes
> > > > mailicious user-space being able to force kmallocs() the size of
> > > > the
> > > > maximum ioctl size. Should probably be fixed before pushing this.
> > >
> > > Hm I always worked under the assumption that kmalloc and friends
> > > should be userspace hardened. Otherwise stuff like kmalloc_array
> > > doesn't make any sense, everyone just feeds it unchecked input and
> > > expects that helper to handle overflows.
> > >
> > > If we assume kmalloc isn't hardened against that, then we have a much
> > > bigger problem than just vmwgfx ioctls ...
> >
> > After checking the drm_ioctl code I realize that what I thought was new
> > behaviour actually has been around for a couple of years, so
> > fixing isn't really tied to this patch series...
> >
> > What caused me to react was that previously we used to have this
> >
> > e4fda9f264e1 ("drm: Perform ioctl command validation on the stored
> > kernel values")
> >
> > and we seem to have lost that now, if not for the io flags then at
> > least for the size part. For the size of the ioctl arguments, I think
> > in general if the kernel only touches a subset of the user-space
> > specified size I see no reason why we should malloc / copy more than
> > that?
>
> I guess we could optimize that, but we'd probably still need to zero
> clear the added size for forward compat with newer userspace. Iirc
> we've had some issues in this area.
>
> > Now, given the fact that the maximum ioctl argument size is quite
> > limited, that might not be a big problem or a problem at all. Otherwise
> > it would be pretty easy for a malicious process to allocate most or all
> > of a system's resident memory?
>
> The biggest you can allocate from kmalloc is limited by the largest
> contiguous chunk alloc_pages gives you, which is limited by MAX_ORDER
> from the page buddy allocator. You need lots of process to be able to
> exhaust memory like that (and like I said, the entire kernel would be
> broken if we'd consider this a security issue). If you want to make
> sure that a process group can't exhaust memory this way then you need
> to set appropriate cgroups limits.
I do agree with all the sentiments that drm_ioctl() could use some extra
optimisation and hardening. At the same time I would remind that the
code has been used as-is by vmwgfx and other drivers for years.
In other words: let's keep that work as orthogonal series.
What do you guys think?
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] drm/bridge: Add Chipone ICN6211 MIPI-DSI/RGB converter bridge
ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
It has a flexible configuration of MIPI DSI signal input
and produce RGB565, RGB666, RGB888 output format.
Add bridge driver for it.
Signed-off-by: Jagan Teki
---
Note:
- drm_panel_bridge_add seems not working or incompatible
as per driver setup. any inputs on this would be great.
MAINTAINERS | 6 +
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/chipone-icn6211.c | 344 +++
4 files changed, 361 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/chipone-icn6211.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4cc30c360fda..97ffb265bedc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4991,6 +4991,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
S: Maintained
F: drivers/gpu/drm/bochs/
+DRM DRIVER FOR CHIPONE ICN6211 MIPI-DSI to RGB CONVERTOR BRIDGE
+M: Jagan Teki
+S: Maintained
+F: drivers/gpu/drm/bridge/chipone-icn6211.c
+F: Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt
+
DRM DRIVER FOR FARADAY TVE200 TV ENCODER
M: Linus Walleij
T: git git://anongit.freedesktop.org/drm/drm-misc
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3dff9997f5e3..2e06be1aaca3 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -36,6 +36,16 @@ config DRM_CDNS_DSI
Support Cadence DPI to DSI bridge. This is an internal
bridge and is meant to be directly embedded in a SoC.
+config DRM_CHIPONE_ICN6211
+ tristate "Chipone ICN6211 MIPI-DSI/RGB converter bridge"
+ depends on DRM && DRM_PANEL
+ depends on OF
+ select DRM_MIPI_DSI
+ help
+ ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
+ It has a flexible configuration of MIPI DSI signal input
+ and produce RGB565, RGB666, RGB888 output format.
+
config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf5a6f8..541fdccad10b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
+obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c
b/drivers/gpu/drm/bridge/chipone-icn6211.c
new file mode 100644
index ..76edda52dc57
--- /dev/null
+++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions
+ * Author: Jagan Teki
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct chipone_bridge_desc {
+ unsigned int lanes;
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ void (*chipone_bridge_init)(struct drm_bridge *bridge);
+};
+
+struct chipone {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+ struct drm_panel *panel;
+ const struct drm_display_mode *mode;
+ const struct chipone_bridge_desc *desc;
+
+ struct gpio_desc *reset_gpio;
+};
+
+static inline struct chipone *bridge_to_chipone(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct chipone, bridge);
+}
+
+static inline
+struct chipone *connector_to_chipone(struct drm_connector *connector)
+{
+ return container_of(connector, struct chipone, connector);
+}
+
+static int chipone_get_modes(struct drm_connector *connector)
+{
+ struct chipone *icn = connector_to_chipone(connector);
+
+ return drm_panel_get_modes(icn->panel);
+}
+
+static const
+struct drm_connector_helper_funcs chipone_connector_helper_funcs = {
+ .get_modes = chipone_get_modes,
+};
+
+static const struct drm_connector_funcs chipone_connector_funcs = {
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = drm_connector_cleanup,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static void chipone_disable(struct drm_bridge *bridge)
+{
+ struct chipone *icn = bridge_to_chipone(bridge);
+ int ret;
+
+ ret = drm_panel_disable(bridge_to_chipone(bridge)->panel);
+ if (ret < 0)
+ DRM_DEV_ERROR(icn->dev, "error disabling panel (%d)\n", ret);
+}
+
+st
Re: [PATCH] drm/komeda: Creates plane alpha and blend mode properties
On Fri, May 24, 2019 at 05:20:24PM +0800, Lowry Li (Arm Technology China) wrote: > From: "Lowry Li (Arm Technology China)" > > Creates plane alpha and blend mode properties attached to plane. > > This patch depends on: > - https://patchwork.freedesktop.org/series/59915/ > - https://patchwork.freedesktop.org/series/58665/ > - https://patchwork.freedesktop.org/series/59000/ > - https://patchwork.freedesktop.org/series/59002/ > - https://patchwork.freedesktop.org/series/59471/ > > Changes since v1: > - Adds patch denpendency in the comment > > Changes since v2: > - Remove [RFC] from the subject > > Changes since v3: > - Rebase the code > > Signed-off-by: Lowry Li (Arm Technology China) > --- > drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c > b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c > index e7cd690..9b87c25 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c > @@ -303,6 +303,17 @@ static int komeda_plane_add(struct komeda_kms_dev *kms, > > drm_plane_helper_add(plane, &komeda_plane_helper_funcs); > > + err = drm_plane_create_alpha_property(plane); > + if (err) > + goto cleanup; > + > + err = drm_plane_create_blend_mode_property(plane, > + BIT(DRM_MODE_BLEND_PIXEL_NONE) | > + BIT(DRM_MODE_BLEND_PREMULTI) | > + BIT(DRM_MODE_BLEND_COVERAGE)); > + if (err) > + goto cleanup; > + > err = komeda_plane_create_layer_properties(kplane, layer); > if (err) > goto cleanup; > -- > 1.9.1 > lgtm. Reviewed-by: James Qian Wang (Arm Technology China)
Re: [PATCH] drm: assure aux_dev is nonzero before using it
On 5/24/19 4:36 AM, Jani Nikula wrote: On Thu, 23 May 2019, tcamuso wrote: From Daniel Kwon The system was crashed due to invalid memory access while trying to access auxiliary device. crash> bt PID: 9863 TASK: 89d1bdf11040 CPU: 1 COMMAND: "ipmitool" #0 [89cedd7f3868] machine_kexec at b0663674 #1 [89cedd7f38c8] __crash_kexec at b071cf62 #2 [89cedd7f3998] crash_kexec at b071d050 #3 [89cedd7f39b0] oops_end at b0d6d758 #4 [89cedd7f39d8] no_context at b0d5bcde #5 [89cedd7f3a28] __bad_area_nosemaphore at b0d5bd75 #6 [89cedd7f3a78] bad_area at b0d5c085 #7 [89cedd7f3aa0] __do_page_fault at b0d7080c #8 [89cedd7f3b10] do_page_fault at b0d70905 #9 [89cedd7f3b40] page_fault at b0d6c758 [exception RIP: drm_dp_aux_dev_get_by_minor+0x3d] RIP: c0a589bd RSP: 89cedd7f3bf0 RFLAGS: 00010246 RAX: RBX: RCX: 89cedd7f3fd8 RDX: RSI: RDI: c0a613e0 RBP: 89cedd7f3bf8 R8: 89f1bcbabbd0 R9: R10: 89f1be7a1cc0 R11: R12: R13: 89f1b32a2830 R14: 89d18fadfa00 R15: ORIG_RAX: CS: 0010 SS: 0018 RIP: 2b45f0d80d30 RSP: 7ffc416066a0 RFLAGS: 00010246 RAX: 0002 RBX: 56062e212d80 RCX: 7ffc41606810 RDX: RSI: 0002 RDI: 7ffc41606ec0 RBP: R8: 56062dfed229 R9: 2b45f0cdf14d R10: 0002 R11: 0246 R12: 7ffc41606ec0 R13: 7ffc41606ed0 R14: 7ffc41606ee0 R15: ORIG_RAX: 0002 CS: 0033 SS: 002b It was trying to open '/dev/ipmi0', but as no entry in aux_dir, it returned NULL from 'idr_find()'. This drm_dp_aux_dev_get_by_minor() should have done a check on this, but had failed to do it. I think the better question is, *why* does the idr_find() return NULL? I don't think it should, under any circumstances. I fear adding the check here papers over some other problem, taking us further away from the root cause. That's a very good question. Also, can you reproduce this on a recent upstream kernel? The aux device nodes were introduced in kernel v4.6. Whatever you reproduced on v3.10 is pretty much irrelevant for upstream. I will look into this deeper, using the upstream kernel. BR, Jani. -- snip --
[DO NOT MERGE] [PATCH v2 6/6] ARM: dts: sun8i: bananapi-m2m: Enable Bananapi S070WV20-CT16 DSI panel
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M2M board.
Bananapi S070WV20-CT16 is a pure RGB output panel with ICN6211 DSI/RGB
convertor bridge, so enable bridge along with associated panel.
DSI panel connected via board DSI port with,
- DCDC1 as VCC-DSI supply
- PL5 gpio for bridge reset gpio pin
- PB7 gpio for lcd enable gpio pin
- PL4 gpio for backlight enable pin
Signed-off-by: Jagan Teki
---
arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 86
1 file changed, 86 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
index e1c75f7fa3ca..5f3f9523a03e 100644
--- a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
+++ b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
@@ -44,6 +44,7 @@
#include "sun8i-a33.dtsi"
#include
+#include
/ {
model = "BananaPi M2 Magic";
@@ -61,6 +62,14 @@
stdout-path = "serial0:115200n8";
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <1 2 4 8 16 32 64 128 255>;
+ default-brightness-level = <8>;
+ enable-gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PL4
*/
+ };
+
leds {
compatible = "gpio-leds";
@@ -81,6 +90,18 @@
};
};
+ panel {
+ compatible = "bananapi,s070wv20-ct16", "simple-panel";
+ enable-gpios = <&pio 1 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PB7
*/
+ backlight = <&backlight>;
+
+ port {
+ panel_out_bridge: endpoint {
+ remote-endpoint = <&bridge_out_panel>;
+ };
+ };
+ };
+
reg_vcc5v0: vcc5v0 {
compatible = "regulator-fixed";
regulator-name = "vcc5v0";
@@ -122,6 +143,61 @@
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dcdc1>; /* VCC-DSI */
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsi_out: port@0 {
+ reg = <0>;
+
+ dsi_out_bridge: endpoint {
+ remote-endpoint = <&bridge_out_dsi>;
+ };
+ };
+ };
+
+ bridge@0 {
+ compatible = "chipone,icn6211";
+ reg = <0>;
+ reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge_in: port@0 {
+ reg = <0>;
+
+ bridge_out_dsi: endpoint {
+ remote-endpoint = <&dsi_out_bridge>;
+ };
+ };
+
+ bridge_out: port@1 {
+ reg = <1>;
+
+ bridge_out_panel: endpoint {
+ remote-endpoint = <&panel_out_bridge>;
+ };
+ };
+ };
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -157,6 +233,12 @@
status = "okay";
};
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pin>;
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
@@ -269,6 +351,10 @@
status = "okay";
};
+&tcon0 {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.18.0.321.gffc6fa0e3
[PATCH v2 3/6] drm/sun4i: dsi: Add bridge support
Some display panels would come up with a non-DSI output which
can have an option to connect DSI interface by means of bridge
converter.
This DSI to non-DSI bridge converter would require a bridge
driver that would communicate the DSI controller for bridge
functionalities.
So, add support for bridge functionalities in Allwinner DSI
controller.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 60 +++---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 1 +
2 files changed, 45 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index ae2fe31b05b1..2b4b1355a88f 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -775,6 +775,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
*encoder)
if (!IS_ERR(dsi->panel))
drm_panel_prepare(dsi->panel);
+ if (!IS_ERR(dsi->bridge))
+ drm_bridge_pre_enable(dsi->bridge);
+
/*
* FIXME: This should be moved after the switch to HS mode.
*
@@ -790,6 +793,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
*encoder)
if (!IS_ERR(dsi->panel))
drm_panel_enable(dsi->panel);
+ if (!IS_ERR(dsi->bridge))
+ drm_bridge_enable(dsi->bridge);
+
sun6i_dsi_start(dsi, DSI_START_HSC);
udelay(1000);
@@ -806,6 +812,9 @@ static void sun6i_dsi_encoder_disable(struct drm_encoder
*encoder)
if (!IS_ERR(dsi->panel)) {
drm_panel_disable(dsi->panel);
drm_panel_unprepare(dsi->panel);
+ } else if (!IS_ERR(dsi->bridge)) {
+ drm_bridge_disable(dsi->bridge);
+ drm_bridge_post_disable(dsi->bridge);
}
phy_power_off(dsi->dphy);
@@ -969,11 +978,12 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host,
dsi->device = device;
ret = drm_of_find_panel_or_bridge(host->dev->of_node, 0, 0,
- &dsi->panel, NULL);
+ &dsi->panel, &dsi->bridge);
if (ret)
return ret;
- dev_info(host->dev, "Attached device %s\n", device->name);
+ dev_info(host->dev, "Attached %s %s\n",
+dsi->bridge ? "bridge" : "panel", device->name);
return 0;
}
@@ -983,7 +993,10 @@ static int sun6i_dsi_detach(struct mipi_dsi_host *host,
{
struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
- dsi->panel = NULL;
+ if (dsi->panel)
+ dsi->panel = NULL;
+ else if (dsi->bridge)
+ dsi->bridge = NULL;
dsi->device = NULL;
return 0;
@@ -1055,8 +1068,10 @@ static int sun6i_dsi_bind(struct device *dev, struct
device *master,
struct sun4i_tcon *tcon0 = sun4i_get_tcon0(drm);
int ret;
- if (!dsi->panel)
+ if (!(dsi->panel || dsi->bridge)) {
+ dev_info(drm->dev, "No panel or bridge found... DSI output
disabled\n");
return -EPROBE_DEFER;
+ }
dsi->drv = drv;
@@ -1078,19 +1093,29 @@ static int sun6i_dsi_bind(struct device *dev, struct
device *master,
}
dsi->encoder.possible_crtcs = BIT(0);
- drm_connector_helper_add(&dsi->connector,
-&sun6i_dsi_connector_helper_funcs);
- ret = drm_connector_init(drm, &dsi->connector,
-&sun6i_dsi_connector_funcs,
-DRM_MODE_CONNECTOR_DSI);
- if (ret) {
- dev_err(dsi->dev,
- "Couldn't initialise the DSI connector\n");
- goto err_cleanup_connector;
+ if (dsi->panel) {
+ drm_connector_helper_add(&dsi->connector,
+&sun6i_dsi_connector_helper_funcs);
+ ret = drm_connector_init(drm, &dsi->connector,
+&sun6i_dsi_connector_funcs,
+DRM_MODE_CONNECTOR_DSI);
+ if (ret) {
+ dev_err(dsi->dev,
+ "Couldn't initialise the DSI connector\n");
+ goto err_cleanup_connector;
+ }
+
+ drm_connector_attach_encoder(&dsi->connector, &dsi->encoder);
+ drm_panel_attach(dsi->panel, &dsi->connector);
}
- drm_connector_attach_encoder(&dsi->connector, &dsi->encoder);
- drm_panel_attach(dsi->panel, &dsi->connector);
+ if (dsi->bridge) {
+ ret = drm_bridge_attach(&dsi->encoder, dsi->bridge, NULL);
+ if (ret) {
+ dev_err(dsi->dev, "Couldn't attach the DSI bridge\n");
+ goto err_cleanup_connector;
+ }
+ }
return 0;
@@ -1104,7 +1129,10 @@ static void sun6i_dsi_unbind(struct device *
[DO NOT MERGE] [PATCH v2 2/6] ARM: dts: sun8i: bananapi-m2m: Enable Bananapi S070WV20-CT16 DSI panel
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M2M board.
DSI panel connected via board DSI port with,
- DCDC1 as VCC-DSI supply
- PL5 gpio for lcd reset gpio pin
- PB7 gpio for lcd enable gpio pin
- PL4 gpio for backlight enable pin
Signed-off-by: Jagan Teki
---
arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 59
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
index e1c75f7fa3ca..762d4cfcff01 100644
--- a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
+++ b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
@@ -44,6 +44,7 @@
#include "sun8i-a33.dtsi"
#include
+#include
/ {
model = "BananaPi M2 Magic";
@@ -61,6 +62,14 @@
stdout-path = "serial0:115200n8";
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <1 2 4 8 16 32 64 128 255>;
+ default-brightness-level = <8>;
+ enable-gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PL4
*/
+ };
+
leds {
compatible = "gpio-leds";
@@ -122,6 +131,46 @@
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dcdc1>; /* VCC-DSI */
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsi_out: port@0 {
+ reg = <0>;
+
+ dsi_out_panel: endpoint {
+ remote-endpoint = <&panel_out_dsi>;
+ };
+ };
+ };
+
+ panel@0 {
+ compatible = "bananapi,s070wv20-ct16-icn6211";
+ reg = <0>;
+ enable-gpios = <&pio 1 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PB7
*/
+ reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
+ backlight = <&backlight>;
+
+ port {
+ panel_out_dsi: endpoint {
+ remote-endpoint = <&dsi_out_panel>;
+ };
+ };
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -157,6 +206,12 @@
status = "okay";
};
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pin>;
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
@@ -269,6 +324,10 @@
status = "okay";
};
+&tcon0 {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.18.0.321.gffc6fa0e3
[PATCH v2 4/6] dt-bindings: display: bridge: Add ICN6211 MIPI-DSI to RGB converter bridge
ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
It has a flexible configuration of MIPI DSI signal input
and produce RGB565, RGB666, RGB888 output format.
Add dt-bingings for it.
Signed-off-by: Jagan Teki
---
.../display/bridge/chipone,icn6211.txt| 78 +++
1 file changed, 78 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt
b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt
new file mode 100644
index ..53a9848ef8b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt
@@ -0,0 +1,78 @@
+Chipone ICN6211 MIPI-DSI to RGB Converter Bridge
+
+ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
+It has a flexible configuration of MIPI DSI signal input
+and produce RGB565, RGB666, RGB888 output format.
+
+Required properties for RGB:
+- compatible: must be "chipone,icn6211"
+- reg: the virtual channel number of a DSI peripheral
+- reset-gpios: a GPIO phandle for the reset pin
+
+The device node can contain following 'port' child nodes,
+according to the OF graph bindings defined in [1]:
+ 0: DSI Input, not required, if the bridge is DSI controlled
+ 1: RGB Output, mandatory
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel {
+ compatible = "bananapi,s070wv20-ct16", "simple-panel";
+ enable-gpios = <&pio 1 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PB7
*/
+ backlight = <&backlight>;
+
+ port {
+ panel_out_bridge: endpoint {
+ remote-endpoint = <&bridge_out_panel>;
+ };
+ };
+ };
+
+&dsi {
+ vcc-dsi-supply = <®_dcdc1>; /* VCC-DSI */
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsi_out: port@0 {
+ reg = <0>;
+
+ dsi_out_bridge: endpoint {
+ remote-endpoint = <&bridge_out_dsi>;
+ };
+ };
+ };
+
+ bridge@0 {
+ compatible = "chipone,icn6211";
+ reg = <0>;
+ reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge_in: port@0 {
+ reg = <0>;
+
+ bridge_out_dsi: endpoint {
+ remote-endpoint = <&dsi_out_bridge>;
+ };
+ };
+
+ bridge_out: port@1 {
+ reg = <1>;
+
+ bridge_out_panel: endpoint {
+ remote-endpoint = <&panel_out_bridge>;
+ };
+ };
+ };
+ };
+};
--
2.18.0.321.gffc6fa0e3
