Re: [PATCH][drm-next] drm/amd/display: fix a potential null pointer dereference
On Fri, Aug 16, 2019 at 11:10:11PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently the pointer init_data is dereferenced on the assignment
> of fw_info before init_data is sanity checked to see if it is null.
> Fix te potential null pointer dereference on init_data by only
> performing dereference after it is null checked.
>
> Addresses-Coverity: ("Dereference before null check")
> Fixes: 9adc8050bf3c ("drm/amd/display: make firmware info only load once
> during dc_bios create")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> index bee81bf288be..926954c804a6 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> @@ -1235,7 +1235,7 @@ static bool calc_pll_max_vco_construct(
> struct calc_pll_clock_source_init_data *init_data)
> {
> uint32_t i;
> - struct dc_firmware_info *fw_info = &init_data->bp->fw_info;
> + struct dc_firmware_info *fw_info;
> if (calc_pll_cs == NULL ||
> init_data == NULL ||
> init_data->bp == NULL)
init_data can't be NULL. I'm mostly pointing this out because that NULL
check is written so higgledy-piggledy. At first I thought this was
staging code so I was planning to ignore the patch. :P
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204181] NULL pointer dereference regression in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181 --- Comment #32 from Sergey Kondakov (virtuous...@gmail.com) --- Just got exactly the same 0010:amdgpu_vm_update_directories+0xe7/0x260 dereference immediately on login even with PageFlip & TearFree disabled and ShadowPrimary NOT enabled. Even with all the same addresses as before. So, now I'm not sure about what actually triggers it. However, my setup is as non-default as it gets: amdgpu has these parameters: cik_support=1 si_support=1 msi=1 sched_policy=1 compute_multipipe=1 gartsize=1024 vm_fragment_size=9 max_num_of_queues_per_device=65536 sched_hw_submission=32 sched_jobs=1024 job_hang_limit=8000 halt_if_hws_hang=1 vm_fault_stop=0 vm_update_mode=3 vm_size=20 disp_priority=2 deep_color=1 gpu_recovery=1 irqbalance is enabled with interval=1 and rtirq has this: RTIRQ_NAME_LIST="timer rtc snd drm amdgpu radeon i915 nvidia usb i8042 ahci" RTIRQ_HIGH_LIST="watchdogd oom_reaper rcu_preempt rcu_sched rcu_bh rcub rcuc gfx sdma ksoftirqd khugepaged" RTIRQ_PRIO_HIGH=80 RTIRQ_PRIO_DECR=2 RTIRQ_PRIO_LOW=50 RTIRQ_RESET_ALL=0 to boost amdgpu's processes to highest RT/FIFO priorities in hope to avoid video stuttering and audio x-runs under full load. Transparent hugepages are enabled in attempt to spare crappy AMD FX's TLB cache and MMU (hence the vm_fragment_size=9). Maybe it's non-default vm_update_mode that does it. And few kernel versions back default gart of 256MB was triggering some kind of fault, probably stall and reset, maybe it even still does but I'm not going to check. Or maybe it's all irrelevant. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #114 from ReddestDream --- 5. Tom B., it is probably worth getting a full dmesg with your two monitors in on a relatively new 5.2.x kernel using at least: amdgpu.dc_log=1 drm.debug=0x1e log_buf_len=2M And anything else you might think of. Just to try to get more debug info. Thx! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #113 from ReddestDream --- 4. > Given that two different versions of the code produce the same result, my > hunch is that the problem is B. The card is not in a state where it's able to > receive power changes. Something to consider: In pretty much all the dmesg logs we see, amdgpu attempts to reset the GPU, sometimes successfully, and yet it still can't properly message the GPU afterward and we see the same sequence of failures starting with "amdgpu: [powerplay] Failed to send message 0x28, response 0x0 amdgpu: [powerplay] [SetUclkToHightestDpmLevel] Set hard min uclk failed!" Eventually we start to see: "[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!" This comes from: https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c I'm not sure what the -125 error code indicates. My guess is ECANCELED (Operation Cancelled) as the negated error code 125. https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/errno.h -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #112 from ReddestDream --- More ideas: 3. Looking through the crash in sehellion's comment 45: gfx_v9_0_ring_test_ring+0x19e/0x230 [amdgpu] amdgpu_ring_test_helper+0x1e/0x90 [amdgpu] gfx_v9_0_hw_fini+0x299/0x690 [amdgpu] amdgpu_device_ip_suspend_phase2+0x6c/0xa0 [amdgpu] amdgpu_device_ip_suspend+0x44/0x80 [amdgpu] amdgpu_device_pre_asic_reset+0x1ef/0x204 [amdgpu] amdgpu_device_gpu_recover+0x7b/0x7a3 [amdgpu] amdgpu_job_timedout+0xfc/0x120 [amdgpu] We see gfx_v9_0_ring_test and gfx_v9_0_hw_fini which both come from: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c There's a 5.1-rc1 commit in this file pertaining to a "wave ID mismatch" that could cause deadlocks. https://github.com/torvalds/linux/commit/41cca166cc57e75e94d888595a428d23a3bf4e36 Along with updated "golden values" for Vega in 5.1-rc1: https://github.com/torvalds/linux/commit/919a94d8101ebc29868940b580fe9e9811b7dc86 https://github.com/torvalds/linux/commit/f7b1844bacecca96dd8d813675e4d8adec02cd66 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #111 from ReddestDream --- A few other ideas to ponder: 1. Looking into DPM, I found this commit for 5.1-rc1 that looks interesting: https://github.com/torvalds/linux/commit/7ca881a8651bdeffd99ba8e0010160f9bf60673e Looks like it exposes "ppfeatures" interface on Vega 10 and later GPU, including some code for Vega 20. 2. I also found two interesting commits that pertain to "doorbell" register initialization on Vega 20. Also from 5.1-rc1. Might be related to setting up the GPU ASICs . I must admit I'm not exactly sure what these do . . . https://github.com/torvalds/linux/commit/fd4855409f6ebe015406cd2b2ffa4fee4cd1f4a7 https://github.com/torvalds/linux/commit/828845b7c86c5338f6ca02f4b525718f31b2 -- 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] nouveau/hmm: map pages after migration
On Fri, Aug 16, 2019 at 5:11 PM Christoph Hellwig wrote: > > On Mon, Aug 12, 2019 at 12:42:30PM -0700, Ralph Campbell wrote: > > > > On 8/10/19 4:13 AM, Christoph Hellwig wrote: > >> On something vaguely related to this patch: > >> > >> You use the NVIF_VMM_PFNMAP_V0_V* defines from nvif/if000c.h, which are > >> a little odd as we only ever set these bits, but they also don't seem > >> to appear to be in values that are directly fed to the hardware. > >> > >> On the other hand mmu/vmm.h defines a set of NVIF_VMM_PFNMAP_V0_* > > > > Yes, I see NVKM_VMM_PFN_* > > > >> constants with similar names and identical values, and those are used > >> in mmu/vmmgp100.c and what appears to finally do the low-level dma > >> mapping and talking to the hardware. Are these two sets of constants > >> supposed to be the same? Are the actual hardware values or just a > >> driver internal interface? > > > > It looks a bit odd to me too. > > I don't really know the structure/history of nouveau. > > Perhaps Ben Skeggs can shed more light on your question. > > Ben, do you have any insights on these constants? Those sets of constants are (currently) supposed to be the same value. They don't necessarily map to the HW directly at this stage, and something different will likely be done in the future as HW changes. Ben. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/60] drm/bridge: Add connector-related bridge operations and data
Hi Daniel,
On Sat, Aug 17, 2019 at 02:30:08AM +0300, Laurent Pinchart wrote:
> On Wed, Aug 14, 2019 at 07:02:29PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 14, 2019 at 04:30:57PM +0300, Laurent Pinchart wrote:
> >> On Wed, Aug 14, 2019 at 03:03:29PM +0200, Daniel Vetter wrote:
> >>> On Thu, Aug 08, 2019 at 09:36:31PM +0300, Laurent Pinchart wrote:
> On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote:
> > On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> >> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>> Hi Laurent,
> >>>
> >>> I like the approach, current practice when almost every bridge should
> >>> optionally implement connector, or alternatively downstream bridge or
> >>> panel is very painful.
> >>
> >> Yeah I think this looks mostly reasonable. Some api design comments on
> >> top
> >> of Andrzej', with the fair warning that I didn't bother to read up on
> >> how
> >> it's all used in the end. I probably should go and do that, at least to
> >> get a feeling for what your hpd_cb usually does.
> >>
> >>> More comments inlined.
> >>>
> >>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> To support implementation of DRM connectors on top of DRM bridges
> instead of by bridges, the drm_bridge needs to expose new operations
> and
> data:
>
> - Output detection, hot-plug notification, mode retrieval and EDID
> retrieval operations
> - Bitmask of supported operations
> >>>
> >>>
> >>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>> operation's callback?
> >>
> >> Yeah also not a huge fan of these bitmasks. Smells like
> >> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >> add, generally good excuse to not have to think through the design
> >> between
> >> different parts of drivers - "just" add another flag.
> >
> > The reason is that a bridge may support an operation (as in implemented
> > in the bridge hardware), but that operation may not be supported on a
> > particular board. For instance an HDMI encoder may support reading EDID
> > when the DDC lines are connected to the encoder, but a board may connect
> > the DDC lines to an I2C port of the SoC. We thus need to decouple
> > if a particular instance of the device supports the operation (exposed
> > by the ops flags) from the function pointers.
> >
> > We could of course allocate the drm_bridge_funcs structure dynamically
> > for each bridge instance, and fill it with function pointers manually,
> > leaving the unused ops always NULL, but that would require making the
> > structure writable, which is considered a security issue. That's why I
> > decided to keep the drm_bridge_funcs structure as a global static const
> > structure, and add an ops bitmask.
> >
> - Bridge output type
>
> Add and document these.
>
> Three new bridge helper functions are also added to handle hot plug
> notification in a way that is as transparent as possible for the
> bridges.
> >>>
> >>> Documentation of new opses does not explain how it should cooperate
> >>> with
> >>> bridge chaining, I suppose they should be chained explicitly, am I
> >>> right? More comments about it later.
> >
> > No, the whole point is that they should not be chained at all. A bridge
> > does not have to propagate, for instance, .get_edid() to the next
> > bridge. That's one of the core design principles in this series, I want
> > to keep the bridges as simple as possible, and move the complexity of
> > the boilerplate code that is currently copied all around to helpers. See
> > patch "drm: Add helper to create a connector for a chain of bridges" for
> > more information about how this is used, with a helper that delegates
> > the connector operations to the correct bridge in the chain based on the
> > ops reported by each bridge.
> >
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_bridge.c | 92 +++
> include/drm/drm_bridge.h | 170
> ++-
> 2 files changed, 261 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c
> b/drivers/gpu/drm/drm_bridge.c
> index 519577f363e3..3c2a255df7af 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> */
> void drm_bridge_add(struct drm_bridge *bridge)
> {
> +mutex_init(&bridge->hpd_mutex);
> +
> mutex_lock(&bridge_lock
Re: [PATCH 09/60] drm/bridge: Add connector-related bridge operations and data
Hi Daniel,
On Wed, Aug 14, 2019 at 07:02:29PM +0200, Daniel Vetter wrote:
> On Wed, Aug 14, 2019 at 04:30:57PM +0300, Laurent Pinchart wrote:
> > On Wed, Aug 14, 2019 at 03:03:29PM +0200, Daniel Vetter wrote:
> >> On Thu, Aug 08, 2019 at 09:36:31PM +0300, Laurent Pinchart wrote:
> >>> On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote:
> On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> > On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >> Hi Laurent,
> >>
> >> I like the approach, current practice when almost every bridge should
> >> optionally implement connector, or alternatively downstream bridge or
> >> panel is very painful.
> >
> > Yeah I think this looks mostly reasonable. Some api design comments on
> > top
> > of Andrzej', with the fair warning that I didn't bother to read up on
> > how
> > it's all used in the end. I probably should go and do that, at least to
> > get a feeling for what your hpd_cb usually does.
> >
> >> More comments inlined.
> >>
> >> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>> To support implementation of DRM connectors on top of DRM bridges
> >>> instead of by bridges, the drm_bridge needs to expose new operations
> >>> and
> >>> data:
> >>>
> >>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>> retrieval operations
> >>> - Bitmask of supported operations
> >>
> >>
> >> Why do we need these bitmask at all? Why cannot we rely on presence of
> >> operation's callback?
> >
> > Yeah also not a huge fan of these bitmasks. Smells like
> > DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> > add, generally good excuse to not have to think through the design
> > between
> > different parts of drivers - "just" add another flag.
>
> The reason is that a bridge may support an operation (as in implemented
> in the bridge hardware), but that operation may not be supported on a
> particular board. For instance an HDMI encoder may support reading EDID
> when the DDC lines are connected to the encoder, but a board may connect
> the DDC lines to an I2C port of the SoC. We thus need to decouple
> if a particular instance of the device supports the operation (exposed
> by the ops flags) from the function pointers.
>
> We could of course allocate the drm_bridge_funcs structure dynamically
> for each bridge instance, and fill it with function pointers manually,
> leaving the unused ops always NULL, but that would require making the
> structure writable, which is considered a security issue. That's why I
> decided to keep the drm_bridge_funcs structure as a global static const
> structure, and add an ops bitmask.
>
> >>> - Bridge output type
> >>>
> >>> Add and document these.
> >>>
> >>> Three new bridge helper functions are also added to handle hot plug
> >>> notification in a way that is as transparent as possible for the
> >>> bridges.
> >>
> >> Documentation of new opses does not explain how it should cooperate
> >> with
> >> bridge chaining, I suppose they should be chained explicitly, am I
> >> right? More comments about it later.
>
> No, the whole point is that they should not be chained at all. A bridge
> does not have to propagate, for instance, .get_edid() to the next
> bridge. That's one of the core design principles in this series, I want
> to keep the bridges as simple as possible, and move the complexity of
> the boilerplate code that is currently copied all around to helpers. See
> patch "drm: Add helper to create a connector for a chain of bridges" for
> more information about how this is used, with a helper that delegates
> the connector operations to the correct bridge in the chain based on the
> ops reported by each bridge.
>
> >>> Signed-off-by: Laurent Pinchart
> >>> ---
> >>> drivers/gpu/drm/drm_bridge.c | 92 +++
> >>> include/drm/drm_bridge.h | 170
> >>> ++-
> >>> 2 files changed, 261 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_bridge.c
> >>> b/drivers/gpu/drm/drm_bridge.c
> >>> index 519577f363e3..3c2a255df7af 100644
> >>> --- a/drivers/gpu/drm/drm_bridge.c
> >>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>> */
> >>> void drm_bridge_add(struct drm_bridge *bridge)
> >>> {
> >>> + mutex_init(&bridge->hpd_mutex);
> >>> +
> >>> mutex_lock(&bridge_lock);
> >>> list_add_tail(&bridge->list, &bridge_list);
> >>> mutex_unlock(&bridge_lock);
> >>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #110 from ReddestDream --- > 1. The functions in vega20_ppt.c are used with this new patch so that answers > my question from earlier, that's what this file is for and why it contains > similar/identical functions. I was hoping this was the case as the duplicated functions were confusing me too. Glad we got this figured out! :) > I tried it, it didn't help the crashing issue and I was stuck at 30w. As soon > as I started sddm the system froze. I've attached my dmesg from amdgpu.dpm=2 > boot. It doesn't fix the issue but it does help answer a few questions I had: This is disappointing tho. I was hoping that setting amdgpu.dpm=2 would use the more "actively developed" path and that would fix the issue. :/ > Given that two different versions of the code produce the same result, my > hunch is that the problem is B. The card is not in a state where it's able to > receive power changes. I tend to agree, but it's still not clear why or how the card ends up in a bad state when commands to it via smu_send_smc_msg_with_param seem to just suddenly stop working. And given the amount of same/similar functions in vega20_hwmgr.c and vega20_ppt.c it's hard to rule out A entirely. Since amdgpu.dpm=0 resolves the issue (albeit at the cost of being stuck at minimum clocks inherited from the VBIOS/GOP/UEFI/firmware), it seems that the card is starting out in a reasonable state and then being thrown into a bad state later by bad driver code. And that code is part of the DPM (Dynamic Power Management) system. We are pretty confident that dpm_state.hard_min_level is stable the whole time, so that's probably not what's throwing the card into a bad state. But perhaps another value in the DPM table is . . . It doesn't make intuitive sense that the soft min/max values would be problematic since they are presumably "more flexible," but it's possible that they get calculated out of spec or something and logging them should be possible like how dpm_state.hard_min_level was logged. -- 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/kms: Catch mode_object lifetime errors
On Sat, 2019-06-29 at 17:39 +0200, Daniel Vetter wrote:
> On Fri, Jun 28, 2019 at 7:24 PM Sean Paul wrote:
> > On Fri, Jun 14, 2019 at 08:17:23AM +0200, Daniel Vetter wrote:
> > > Only dynamic mode objects, i.e. those which are refcounted and
> > > have a free
> > > callback, can be added while the overall drm_device is visible to
> > > userspace. All others must be added before drm_dev_register and
> > > removed after drm_dev_unregister.
> > >
> > > Small issue around drivers still using the load/unload callbacks,
> > > we
> > > need to make sure we set dev->registered so that load/unload code
> > > in
> > > these callbacks doesn't trigger false warnings. Only a small
> > > adjustement in drm_dev_register was needed.
> > >
> > > Motivated by some irc discussions about object ids of dynamic
> > > objects
> > > like blobs become invalid, and me going on a bit an audit spree.
> > >
> >
> > Seems like a very worthwhile change, any idea how many drivers are
> > going
> > to be sad after this change?
>
> None I think/hope, really just defense WARN_ON just in case. The main
> ones that would be sad are all the ones that have a ->load callback,
> but I'm taking care of them. Everyone else does things correctly and
> calls drm_dev_register last in their probe function (or around where
> they set up fbdev, which is also register the driver at least to the
> fbdev world, so really the same).
>
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 4 ++--
> > > drivers/gpu/drm/drm_mode_object.c | 4
> > > 2 files changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c
> > > b/drivers/gpu/drm/drm_drv.c
> > > index cb6f0245de7c..48c84e3e1931 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -997,14 +997,14 @@ int drm_dev_register(struct drm_device
> > > *dev, unsigned long flags)
> > > if (ret)
> > > goto err_minors;
> > >
> > > - dev->registered = true;
> > > -
> > > if (dev->driver->load) {
> > > ret = dev->driver->load(dev, flags);
> > > if (ret)
> > > goto err_minors;
> > > }
> > >
> > > + dev->registered = true;
> > > +
> > > if (drm_core_check_feature(dev, DRIVER_MODESET))
> > > drm_modeset_register_all(dev);
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_object.c
> > > b/drivers/gpu/drm/drm_mode_object.c
> > > index 1c6e51135962..c355ba8e6d5d 100644
> > > --- a/drivers/gpu/drm/drm_mode_object.c
> > > +++ b/drivers/gpu/drm/drm_mode_object.c
> > > @@ -42,6 +42,8 @@ int __drm_mode_object_add(struct drm_device
> > > *dev, struct drm_mode_object *obj,
> > > {
> > > int ret;
> > >
> > > + WARN_ON(dev->registered && !obj_free_cb);
Getting warnings on i915 with MST, we add fake MST connectors when a
sink with MST support is connected;
intel_dp_add_mst_connector()->drm_connector_attach_max_bpc_property()
Not sure how to fix that, add a global i915 device property like we do
for "audio" and "Broadcast RGB" don't look the right approach here.
Any tips?
We definitely need a platform with a MST sink on our CI.
> >
> > These should probably have a comment above them giving some
> > guidance to the
> > driver developer.
> >
> > With some comments, this is:
>
> What comment do you expect here? drm_dev_register explains what you
> should do already, and I expect driver developers to find that one
> pretty quickly. From there: "This should be done last in the device
> initialization sequence to make sure userspace can't access an
> inconsistent state."
> -Daniel
>
> > Reviewed-by: Sean Paul
> >
> >
> > > +
> > > mutex_lock(&dev->mode_config.idr_mutex);
> > > ret = idr_alloc(&dev->mode_config.object_idr, register_obj
> > > ? obj : NULL,
> > > 1, 0, GFP_KERNEL);
> > > @@ -102,6 +104,8 @@ void drm_mode_object_register(struct
> > > drm_device *dev,
> > > void drm_mode_object_unregister(struct drm_device *dev,
> > > struct drm_mode_object *object)
> > > {
> > > + WARN_ON(dev->registered && !object->free_cb);
> > > +
> > > mutex_lock(&dev->mode_config.idr_mutex);
> > > if (object->id) {
> > > idr_remove(&dev->mode_config.object_idr, object-
> > > >id);
> > > --
> > > 2.20.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111122] 2500U: Graphics corruption on kernel 5.2
https://bugs.freedesktop.org/show_bug.cgi?id=22 --- Comment #19 from Brian Schott --- I haven't had a lot of time to work on this, but I do have one more data point: Mesa 19.1.4 has no corruption in Dolphin but still requires the nodcc workaround with kernel 5.2.6. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #109 from Tom B --- Created attachment 145080 --> https://bugs.freedesktop.org/attachment.cgi?id=145080&action=edit dmesg with amdgpu.dpm=2 > Tom B., did you try booting with amdgpu.dpm=1 or amdgpu.dpm=2 (default is > generally -1 for automatic)? Seems like one of those might enable the new > experimental SW SMU v11 feature on Vega20 . . . Now that is interesting.dpm=-1 is the same as default, and default is 1, enabled so dpm=1 is what we've been using all along. But dpm=2 and the patch you linked to are interesting. I tried it, it didn't help the crashing issue and I was stuck at 30w. As soon as I started sddm the system froze. I've attached my dmesg from amdgpu.dpm=2 boot. It doesn't fix the issue but it does help answer a few questions I had: 1. The functions in vega20_ppt.c are used with this new patch so that answers my question from earlier, that's what this file is for and why it contains similar/identical functions. 2. It explains the difference I found in comment 97: This commit https://github.com/torvalds/linux/commit/94ed6d0cfdb867be9bf05f03d682980bce5d0036 has the new else block for smu_display_configuration_change which we now know is the software version of this function. More importantly, though, knowing that enabling DPM causes the crash, this tells us either: A) The bug is present in both versions of the vega20 code: vega20_hwmgr.c and vega20_ppt.c or.. B) The card reaches an invalid state before DPM is initialised and the card is fine until it receives a DPM change. Given that two different versions of the code produce the same result, my hunch is that the problem is B. The card is not in a state where it's able to receive power changes. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][drm-next] drm/amd/display: fix a potential null pointer dereference
From: Colin Ian King
Currently the pointer init_data is dereferenced on the assignment
of fw_info before init_data is sanity checked to see if it is null.
Fix te potential null pointer dereference on init_data by only
performing dereference after it is null checked.
Addresses-Coverity: ("Dereference before null check")
Fixes: 9adc8050bf3c ("drm/amd/display: make firmware info only load once during
dc_bios create")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
index bee81bf288be..926954c804a6 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
@@ -1235,7 +1235,7 @@ static bool calc_pll_max_vco_construct(
struct calc_pll_clock_source_init_data *init_data)
{
uint32_t i;
- struct dc_firmware_info *fw_info = &init_data->bp->fw_info;
+ struct dc_firmware_info *fw_info;
if (calc_pll_cs == NULL ||
init_data == NULL ||
init_data->bp == NULL)
@@ -1244,6 +1244,7 @@ static bool calc_pll_max_vco_construct(
if (init_data->bp->fw_info_valid)
return false;
+ fw_info = &init_data->bp->fw_info;
calc_pll_cs->ctx = init_data->ctx;
calc_pll_cs->ref_freq_khz = fw_info->pll_info.crystal_frequency;
calc_pll_cs->min_vco_khz =
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111412] 4k 60hz unavailable RX 560 over HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=111412 --- Comment #3 from Alfie Day --- Created attachment 145079 --> https://bugs.freedesktop.org/attachment.cgi?id=145079&action=edit lspci -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111412] 4k 60hz unavailable RX 560 over HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=111412 --- Comment #2 from Alfie Day --- trek00 from IRC found this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=104412#c14 which mentions running these commands, which seems to work and enable 4k60 over HDMI. xrandr --newmode "mymode" 594 3840 4016 4104 4400 2160 2168 2178 2250 +hsync +vsync xrandr --addmode HDMI-A-0 mymode xrandr --output HDMI-A-0 --mode mymode -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/connector: Allow max possible encoders to attach to a connector (rev2)
On Fri, 2019-08-16 at 21:29 +, Patchwork wrote: > == Series Details == > > Series: drm/connector: Allow max possible encoders to attach to a > connector (rev2) > URL : https://patchwork.freedesktop.org/series/62743/ > State : warning > > == Summary == > > $ dim sparse origin/drm-tip > Sparse version: v0.6.0 > Commit: drm/connector: Allow max possible encoders to attach to a > connector > + ^ > + } > +drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4802:1: > warning: control reaches end of non-void function [-Wreturn-type] > +drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In > function ‘amdgpu_dm_connector_to_encoder’: Missed a "return NULL;" that will not be reached. Will fix that in the next version after get some comments. > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111412] 4k 60hz unavailable RX 560 over HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=111412 --- Comment #1 from Alfie Day --- Someone on IRC said I should mention I was able to achieve 4k 60hz with a DisplayPort cable to the monitor (sadly this doesn't get me 4k 60hz on my TV, which only has HDMI) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111412] 4k 60hz unavailable RX 560 over HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=111412 Bug ID: 111412 Summary: 4k 60hz unavailable RX 560 over HDMI Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: freedesk...@azelphur.com Created attachment 145078 --> https://bugs.freedesktop.org/attachment.cgi?id=145078&action=edit xorg log Hi, My RX 560 won't do 4k 60hz over HDMI. I have tested the cable/display with a different PC (that has a 1080Ti) and it works fine, so I can confirm that both the cable and the TV are capable of displaying a 4k 60hz signal. I have also tested with a monitor that is capable of doing 4k 60hz over HDMI. xrandr only shows 30hz as an option on both the TV and the monitor. -- 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: Linux Kernel 5.2.8 (uvc or i915? <<<)
Kernel is the dmesg from the kernel I run on a daily basis. On 8/16/19, Laurent Pinchart wrote: > Hi Randy, > > On Thu, Aug 15, 2019 at 08:10:03PM -0700, Randy Dunlap wrote: >> [adding mailing lists etc. with Nathaniel's test info] >> >> On 8/15/19 7:21 PM, Nathaniel Russell wrote: >> > Well i surpressed the uvcvideo driver and you are right Randy it >> > definitely is not the uvcvideo driver. There is something going on in >> > the i915 driver. >> > >> > On 8/15/19, Randy Dunlap wrote: >> >> On 8/15/19 6:15 PM, Nathaniel Russell wrote: >> >>> I would really like help with the kernel error with my uvcvideo >> >>> driver. >> >> >> >> Hi again. >> >> >> >> What makes you think that the problem is related to the uvcvideo >> >> driver? >> >> Does some previous kernel version work correctly? If so, what >> >> version(s)? >> >> >> >> >> >> Does this warning message only happen when the uvcvideo driver is >> >> being >> >> loaded? >> >> Can you suppress loading of the uvcvideo driver to find out? >> >> >> >> Most of the problems/errors/warnings that I see are related to the >> >> i915 >> >> driver: >> >> >> >> [ 13.032341] timed out waiting for port C ready: got 0x20, expected >> >> 0xe0 >> >> [ 13.032872] WARNING: CPU: 1 PID: 239 at >> >> drivers/gpu/drm/i915/intel_display.c:1597 >> >> vlv_wait_port_ready+0x99/0xe0 >> >> [i915] >> >> [ 13.033632] RIP: 0010:vlv_wait_port_ready+0x99/0xe0 [i915] >> >> >> >> although there are a few uvcvideo warnings: >> >> [ 13.039305] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was >> >> not >> >> initialized! >> >> [ 13.039318] uvcvideo 1-5:1.0: Entity type for entity Extension 3 was >> >> not >> >> initialized! >> >> [ 13.039330] uvcvideo 1-5:1.0: Entity type for entity Processing 2 >> >> was not >> >> initialized! >> >> [ 13.039339] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was >> >> not >> >> initialized! >> >> >> >> Laurent, do you see any uvc issues here? Any ideas/suggestions? > > No, uvcvideo seems completely reunlated. > >> >> @intel-gfx: any ideas about what is going on here with the i915 >> >> driver? >> >> >> >> Original message to lkml: >> >> https://lore.kernel.org/lkml/CAONH+Jm-O6=dq+k2n5pntnmg2sq1kcvnfluwevh6w82opef...@mail.gmail.com/T/#u >> >> >> >> Previous message for 5.1.21 kernel: >> >> https://lore.kernel.org/lkml/CAONH+JkTFujY9vEyNNuem+9rJ2qBKkf-PbKk9=DBSVEp6kW=y...@mail.gmail.com/ > > -- > Regards, > > Laurent Pinchart > kernel Description: Binary data
Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk
On 8/16/19 10:28 AM, Jason Gunthorpe wrote: On Fri, Aug 16, 2019 at 10:21:41AM -0700, Dan Williams wrote: We can do a get_dev_pagemap inside the page_walk and touch the pgmap, or we can do the 'device mutex && retry' pattern and touch the pgmap in the driver, under that lock. However in all cases the current get_dev_pagemap()'s in the page walk are not necessary, and we can delete them. Yes, as long as 'struct page' instances resulting from that lookup are not passed outside of that lock. Indeed. Also, I was reflecting over lunch that the hmm_range_fault should only return DEVICE_PRIVATE pages for the caller's device (see other thread with HCH), and in this case, the caller should also be responsible to ensure that the driver is not calling hmm_range_fault at the same time it is deleting it's own DEVICE_PRIVATE mapping - ie by fencing its page fault handler. Yes, that would make it a one step process to access another device's migrated memory pages. Right now, it has to be a two step process where the caller calls hmm_range_fault, check the struct page to see if it is device private and not owned, then call hmm_range_fault again with range->pfns[i] |= range->flags[HMM_PFN_DEVICE_PRIVATE] to cause the other device to migrate the page back to system memory. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs
On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > Hi Uwe, > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > Backlight brightness curves can have different shapes. The two main > > > > types are linear and non-linear curves. The human eye doesn't > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > (like the number of brightness levels) to decide whether to treat a > > > > backlight device as linear or non-linear. > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > 'unknown'. For devices that don't provide information about the scale > > > > of their brightness curve the value of the 'scale' attribute is > > > > 'unknown'. > > > > > > > > Signed-off-by: Matthias Kaehlcke > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > that in a few words? > > > > The human eye perceives brightness in a logarithmic manner. For > > backlights with a linear brightness curve brightness controls like > > sliders need to use a mapping to achieve a behavior that is perceived > > as linear-ish (more details: > > http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > As of now userspace doesn't have information about the type of the > > brightness curve, and often uses heuristics to make a guess, which may > > be right most of the time, but not always. The new attribute eliminates > > the need to guess. > > This is about backlights right? So the kernel provides to userspace an > interval [0, x] for some x and depending on the physics of the the > backlight configuring x/2 (probably?) either means 50% measured light or > 50% perceived light, right? correct > I wonder if it would be possible instead of giving different backlight > implementations the freedom to use either linear or logarithmic (or > quadratic?) scaling and tell userspace which of the options were picked > require the drivers to provide a (say) linear scaling and then userspace > wouldn't need to care about the exact physics. In an ideal world the backlight interface would be consistent as you suggest, however there are plenty of existing devices which use the 'other' scaling (regardless of which is chosen as the 'correct' one). Userspace still has to deal with these. And changing previously 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, when it keeps using its 'old' scaling, which now isn't correct anymore. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #108 from ReddestDream --- > Booting with amdgpu.dpm=0 on 5.2.7 works. Tom B., did you try booting with amdgpu.dpm=1 or amdgpu.dpm=2 (default is generally -1 for automatic)? Seems like one of those might enable the new experimental SW SMU v11 feature on Vega20 . . . https://dri.freedesktop.org/docs/drm/gpu/amdgpu.html https://lists.freedesktop.org/archives/amd-gfx/2019-January/030788.html?print=anzwix -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #105 from magist3r --- (In reply to reject5514 from comment #103) > I have this problem on Archlinux 5.2.8-arch1-1-ARCH when connected 2 > monitors(1920x1080 @ 60Hz) and amdgpu.ppfeaturemask=0x option > enabled. Patch didn't work for me. > > My GPU is RX570. Try this patch: https://lists.freedesktop.org/archives/amd-gfx/2019-June/036022.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204599] amdgpu: RX 560 randomly hangs with kernel >= 5.1
https://bugzilla.kernel.org/show_bug.cgi?id=204599 Evgeny Shvits (tony.da...@gmail.com) changed: What|Removed |Added Regression|No |Yes Severity|normal |high -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204599] amdgpu: RX 560 randomly hangs with kernel >= 5.1
https://bugzilla.kernel.org/show_bug.cgi?id=204599 --- Comment #4 from Evgeny Shvits (tony.da...@gmail.com) --- Created attachment 284469 --> https://bugzilla.kernel.org/attachment.cgi?id=284469&action=edit dmesg 5.2.8 after clean boot run "darktable" application what use OpenCL -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Fix memory leak in dma_buf_set_name
Hi Bharath, Thanks for taking the time to try to fix this report. However, this doesn't look right. On Fri, 2019-08-16 at 23:30 +0530, Bharath Vedartham wrote: > This patch fixes a memory leak bug reported by syzbot. Link to the > bug is given at [1]. > > A local variable name is used to hold the copied user buffer string > using strndup_user. strndup_user allocates memory using > kmalloc_track_caller in memdup_user. This kmalloc allocation needs to be > followed by a kfree. > > This patch has been tested by a compile test. > > [1] > https://syzkaller.appspot.com/bug?id=ce692a3aa13e00e335e090be7846c6eb60ddff7a > > Reported-by: syzbot+b2098bc44728a4efb...@syzkaller.appspotmail.com > Signed-off-by: Bharath Vedartham > --- > drivers/dma-buf/dma-buf.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index f45bfb2..9798f6d 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -342,6 +342,7 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, > const char __user *buf) > } > kfree(dmabuf->name); > dmabuf->name = name; > + kfree(name); > Just by looking at this, you can deduce something is not right. You are assigning "name" to dmabuf->name, but then releasing "name"! So now, dmabuf->name has free memory, which will lead to user-after-free issues. Note also, that this function doesn't look leaky since the previous "name" is freed, before setting a new one. Maybe the syzbot report is some kind of false positive? Also, I _strongly_ suggest that in the future you don't compile-test only these kind of not trivial fixes. Since you are touching a crucial part of the kernel here, you should really be testing properly. Specially since syzbot produces a reproducer. Consider compile test as something you do when your changes are only cosmetic, and you are completely and absolutely sure things will be OK. Thanks. Ezequiel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v3 1/2] dt/bindings: display: Add optional property node for Mali DP500
On Fri, Aug 16, 2019 at 4:14 AM Wen He wrote:
>
> Add optional property node 'arm,malidp-arqos-value' for the Mali DP500.
> This property describe the ARQoS levels of DP500's QoS signaling.
>
> Signed-off-by: Wen He
> ---
> change in v3:
> - correction the describe of the node
>
> Documentation/devicetree/bindings/display/arm,malidp.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/arm,malidp.txt
> b/Documentation/devicetree/bindings/display/arm,malidp.txt
> index 2f7870983ef1..1f711d32f235 100644
> --- a/Documentation/devicetree/bindings/display/arm,malidp.txt
> +++ b/Documentation/devicetree/bindings/display/arm,malidp.txt
> @@ -37,6 +37,8 @@ Optional properties:
> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
> to be used for the framebuffer; if not present, the framebuffer may
> be located anywhere in memory.
> + - arm,malidp-arqos-high-level: phandle to describing the ARQoS levels of
> DP500's
> +QoS signaling.
The driver is reading a u32... Did you test this?
>
>
> Example:
> @@ -54,6 +56,7 @@ Example:
> clocks = <&oscclk2>, <&fpgaosc0>, <&fpgaosc1>, <&fpgaosc1>;
> clock-names = "pxlclk", "mclk", "aclk", "pclk";
> arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
> + arm,malidp-arqos-high-level = <&rqosvalue>;
> port {
> dp0_output: endpoint {
> remote-endpoint = <&tda998x_2_input>;
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/connector: Allow max possible encoders to attach to a connector
From: Dhinakaran Pandiyan
Currently we restrict the number of encoders that can be linked to
a connector to 3, increase it to match the maximum number of encoders
that can be initialized(32).
To more effiently do that lets switch from an array of encoder ids to
bitmask.
Also removing the best_encoder hook from the drivers that only have
one encoder per connector(this ones have one encoder in the whole
driver), pick_single_encoder_for_connector() will do the same job
with no functional change.
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Alex Deucher
Cc: dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 23 +-
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 5 ++-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++-
drivers/gpu/drm/ast/ast_mode.c| 12 ---
drivers/gpu/drm/drm_atomic_helper.c | 9 --
drivers/gpu/drm/drm_client_modeset.c | 3 +-
drivers/gpu/drm/drm_connector.c | 31 +--
drivers/gpu/drm/drm_probe_helper.c| 3 +-
drivers/gpu/drm/mgag200/mgag200_mode.c| 11 ---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 7 ++---
drivers/gpu/drm/radeon/radeon_connectors.c| 27 ++--
drivers/gpu/drm/udl/udl_connector.c | 8 -
include/drm/drm_connector.h | 18 +--
15 files changed, 53 insertions(+), 114 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index ece55c8fa673..d8729285f731 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -217,11 +217,10 @@ amdgpu_connector_update_scratch_regs(struct drm_connector
*connector,
struct drm_encoder *encoder;
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
bool connected;
- int i;
best_encoder = connector_funcs->best_encoder(connector);
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if ((encoder == best_encoder) && (status ==
connector_status_connected))
connected = true;
else
@@ -236,9 +235,8 @@ amdgpu_connector_find_encoder(struct drm_connector
*connector,
int encoder_type)
{
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (encoder->encoder_type == encoder_type)
return encoder;
}
@@ -347,10 +345,9 @@ static struct drm_encoder *
amdgpu_connector_best_single_encoder(struct drm_connector *connector)
{
struct drm_encoder *encoder;
- int i;
/* pick the first one */
- drm_connector_for_each_possible_encoder(connector, encoder, i)
+ drm_connector_for_each_possible_encoder(connector, encoder)
return encoder;
return NULL;
@@ -1065,9 +1062,8 @@ amdgpu_connector_dvi_detect(struct drm_connector
*connector, bool force)
/* find analog encoder */
if (amdgpu_connector->dac_load_detect) {
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (encoder->encoder_type != DRM_MODE_ENCODER_DAC &&
encoder->encoder_type != DRM_MODE_ENCODER_TVDAC)
continue;
@@ -1117,9 +1113,8 @@ amdgpu_connector_dvi_encoder(struct drm_connector
*connector)
{
struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(connector);
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (amdgpu_connector->use_digital == true) {
if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
return encoder;
@@ -1134,7 +1129,7 @@ amdgpu_connector_dvi_encoder(struct drm_connector
*connector)
/* then check use digitial */
/* pick the first one */
- drm_connector_for_each_possible_encoder(connector, encoder, i)
+ drm_connector_for_each_possible_encoder(connector, encoder)
return encoder;
return NULL;
@@ -1271,9 +126
Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs
On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > Hi Uwe, > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > Backlight brightness curves can have different shapes. The two main > > > types are linear and non-linear curves. The human eye doesn't > > > perceive linearly increasing/decreasing brightness as linear (see > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > linearly to human eye"), hence many backlights use non-linear (often > > > logarithmic) brightness curves. The type of curve currently is opaque > > > to userspace, so userspace often uses more or less reliable heuristics > > > (like the number of brightness levels) to decide whether to treat a > > > backlight device as linear or non-linear. > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > 'unknown'. For devices that don't provide information about the scale > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > Signed-off-by: Matthias Kaehlcke > > > > I wonder what kind of problem you are solving here. Can you describe > > that in a few words? > > The human eye perceives brightness in a logarithmic manner. For > backlights with a linear brightness curve brightness controls like > sliders need to use a mapping to achieve a behavior that is perceived > as linear-ish (more details: > http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > As of now userspace doesn't have information about the type of the > brightness curve, and often uses heuristics to make a guess, which may > be right most of the time, but not always. The new attribute eliminates > the need to guess. This is about backlights right? So the kernel provides to userspace an interval [0, x] for some x and depending on the physics of the the backlight configuring x/2 (probably?) either means 50% measured light or 50% perceived light, right? I wonder if it would be possible instead of giving different backlight implementations the freedom to use either linear or logarithmic (or quadratic?) scaling and tell userspace which of the options were picked require the drivers to provide a (say) linear scaling and then userspace wouldn't need to care about the exact physics. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204599] amdgpu: RX 560 randomly hangs with kernel >= 5.1
https://bugzilla.kernel.org/show_bug.cgi?id=204599 --- Comment #3 from Evgeny Shvits (tony.da...@gmail.com) --- Created attachment 284467 --> https://bugzilla.kernel.org/attachment.cgi?id=284467&action=edit dmidecode -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204599] amdgpu: RX 560 randomly hangs with kernel >= 5.1
https://bugzilla.kernel.org/show_bug.cgi?id=204599 --- Comment #2 from Evgeny Shvits (tony.da...@gmail.com) --- Created attachment 284465 --> https://bugzilla.kernel.org/attachment.cgi?id=284465&action=edit dmesg hang on 5.2.2 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204599] amdgpu: RX 560 randomly hangs with kernel >= 5.1
https://bugzilla.kernel.org/show_bug.cgi?id=204599 --- Comment #1 from Evgeny Shvits (tony.da...@gmail.com) --- Created attachment 284463 --> https://bugzilla.kernel.org/attachment.cgi?id=284463&action=edit dmesg with hang on 5.2.8 kernel -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204599] New: amdgpu: RX 560 randomly hangs with kernel >= 5.1
https://bugzilla.kernel.org/show_bug.cgi?id=204599 Bug ID: 204599 Summary: amdgpu: RX 560 randomly hangs with kernel >= 5.1 Product: Drivers Version: 2.5 Kernel Version: 5.2.8 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: tony.da...@gmail.com Regression: No I have hybrid graphics on Lenovo Ideapad 720 laptop (Intel i7 8550U and AMD RX 560), use amdgpu and i have randomly hangs with kernels > 5.0.13. AMDGPU hangs on laptop returned from hibernate, but on latest time i go to 5.2.8 and now AMDGPU hangs on normal work (only suspend to ram, without hibenates). # lscpi -v: 01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] (rev e0) Subsystem: Lenovo Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] Flags: bus master, fast devsel, latency 0, IRQ 127 Memory at a000 (64-bit, prefetchable) [size=256M] Memory at b000 (64-bit, prefetchable) [size=2M] I/O ports at d000 [size=256] Memory at d130 (32-bit, non-prefetchable) [size=256K] Expansion ROM at d134 [disabled] [size=128K] Capabilities: Kernel driver in use: amdgpu Kernel modules: amdgpu -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dma-fence: Simply wrap dma_fence_signal_locked with dma_fence_signal
Quoting Daniel Vetter (2019-08-16 20:07:24)
> On Fri, Aug 16, 2019 at 9:02 PM Koenig, Christian
> wrote:
> >
> > Am 16.08.19 um 17:21 schrieb Chris Wilson:
> > > Currently dma_fence_signal() tries to avoid the spinlock and only takes
> > > it if absolutely required to walk the callback list. However, to allow
> > > for some users to surreptitiously insert lazy signal callbacks that
> > > do not depend on enabling the signaling mechanism around every fence,
> > > we always need to notify the callbacks on signaling. As such, we will
> > > always need to take the spinlock and dma_fence_signal() effectively
> > > becomes a clone of dma_fence_signal_locked().
> > >
> > > Signed-off-by: Chris Wilson
> > > Cc: Christian König
> > > Cc: Daniel Vetter
> > > ---
> > > drivers/dma-buf/dma-fence.c | 19 +--
> > > 1 file changed, 5 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > > index ff0cd6eae766..f23eb9f19b4e 100644
> > > --- a/drivers/dma-buf/dma-fence.c
> > > +++ b/drivers/dma-buf/dma-fence.c
> > > @@ -176,6 +176,7 @@ EXPORT_SYMBOL(dma_fence_signal_locked);
> > > int dma_fence_signal(struct dma_fence *fence)
> > > {
> > > unsigned long flags;
> > > + int ret;
> > >
> > > if (!fence)
> > > return -EINVAL;
> > > @@ -183,21 +184,11 @@ int dma_fence_signal(struct dma_fence *fence)
> > > if (test_and_set_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> > > return -EINVAL;
> >
> > I need to take my review back. You also need to drop this
> > test_and_set_bit here or your completely break drivers using this.
First time we were here, it was just a plain test_bit(). Skipping a
patch, so had to start from scratch... (I blame glancing at the original
outcome and glossing over the test_bit vs test_and_set_bit.)
> Time for a pile of dma_fence selftests? Maybe with a bit of dma_resv
> thrown in for good? This stuff is tricky, and it feels like we had a
> few oopsies in review recently ...
dma_fence_signal vs dma_fence_add_callback
Something like:
while (!timeout)
f1 = mock_fence_create()
push f1 to other thread
pull f2 from other thread
dma_fence_signal(f2);
dma_fence_add_callback(f1)
dma_fence_signal(f1);
check cb
Can't see an obvious way to make the test_and_set_bit window larger.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 --- Comment #27 from mib...@gmx.at --- fwiw downgrading to 5.1.16 seems to fix the issue here too -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] video: omapfb2: Make standard and custom panel drivers mutually exclusive
Hi Laurent. On Fri, Aug 16, 2019 at 09:39:05PM +0300, Laurent Pinchart wrote: > Hi Sam, > > On Fri, Aug 16, 2019 at 07:31:05PM +0200, Sam Ravnborg wrote: > > Hi Laurent > > > > Thanks for beating me on this! > > > > On Fri, Aug 16, 2019 at 03:22:27PM +0300, Laurent Pinchart wrote: > > > Standard DRM panel drivers for several panels used by omapfb2 are now > > > available. Their module name clashes with the modules from > > > drivers/gpu/drm/omapdrm/displays/, part of the deprecated omapfb2 fbdev > > > driver. As omapfb2 can only be compiled when the omapdrm driver is > > > disabled, and the DRM panel drivers are useless in that case, make the > > > omapfb2 panels depend on the standard DRM panels being disabled to fix > > > the name clash. > > > > > > Signed-off-by: Laurent Pinchart > > > --- > > > drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig > > > b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig > > > index 8c1c5a4cfe18..744416dc530e 100644 > > > --- a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig > > > +++ b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig > > > @@ -49,6 +49,7 @@ config FB_OMAP2_PANEL_DSI_CM > > > config FB_OMAP2_PANEL_SONY_ACX565AKM > > > tristate "ACX565AKM Panel" > > > depends on SPI && BACKLIGHT_CLASS_DEVICE > > > + depends on DRM_PANEL_SONY_ACX565AKM = n > > > > Would: > > depends on !DRM_PANEL_SONY_ACX565AKM > > > > do the same? > > > > Example: > > config FB_INTEL > > tristate "Intel > > 830M/845G/852GM/855GM/865G/915G/945G/945GM/965G/965GM support" > > depends on FB && PCI && X86 && AGP_INTEL && EXPERT > > ... > > depends on !DRM_I915 > > > > > > DRM_915 is a tristate symbol. > > > > It is maybe bikeshedding, but the ! seems more logical/readable to > > me. > > The two are equivalent as far as I can tell, so I'm fine with !. > Would you change that when applying, or should I send a v2 ? I failed to convince myself they are equivalent. From kconfig-languae.rst: " '!'(6) (6) Returns the result of (2-/expr/). An expression can have a value of 'n', 'm' or 'y' (or 0, 1, 2 respectively for calculations). A menu entry becomes visible when its expression evaluates to 'm' or 'y'. " So ! equals 1 for m and 0 for y. If I get it right. My testing was not fully conclusive. So I left it as is. Added a few Fixes: etc. tags. Applied and pushed to drm-misc-next. Ohh, and dim came to my rescue. My Fixes: syntax was wrong but it was caught in my "dim push" - nice. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] Fix module name clash with omapdrm and DRM panel modules
Hi all On Fri, Aug 16, 2019 at 03:22:26PM +0300, Laurent Pinchart wrote: > Hello, > > The patch series "[PATCH v4 0/9] DRM panel drivers for omapdrm" added > new DRM panel drivers for a set of panels used on OMAP platforms, with > the omapdrm and omapfb2 drivers. Both those drivers contain > omap-specific panel drivers, which the new DRM panel drivers aims to > replace for omapdrm. The new drivers use the same module name as the old > ones (with one exception), resulting in module name clashes. > > This needs to be fixed separately for omapfb2 and omapdrm. > > For omapfb2, we can disable the omapfb2-specific panel drivers in > Kconfig when the standard drivers are enabled. As omapfb2 and omapdrm > are mutually exclusive, the DRM panel drivers are not useful with > omapfb2 in any case. This is done in patch 1/2. > > For omapdrm, we can simply drop the omapdrm-specific panel drivers, as > the new drivers replace them. This is done in patch 2/2, which was > already part of the larger omapdrm patch series "[PATCH 00/60] drm/omap: > Replace custom display drivers with drm_bridge and drm_panel". > > Laurent Pinchart (2): > video: omapfb2: Make standard and custom panel drivers mutually > exclusive > drm/omap: displays: Remove unused panel drivers Applied and pushed to drm-misc-next. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Refactor ttm_bo_pipeline_move
Am 16.08.19 um 20:59 schrieb Brian Welty:
> ttm_bo_pipeline_move needlessly duplicates code. Refactor this to
> instead call ttm_bo_move_accel_cleanup.
>
> Signed-off-by: Brian Welty
At least of hand that looks valid to me, Reviewed-by: Christian König
for now.
Regards,
Christian.
>
> ---
> Builds but otherwise currently untested.
> Came across this duplication and thought would see if others cared
> to see it cleaned up this way or not.
>
> drivers/gpu/drm/ttm/ttm_bo_util.c | 64 +++
> 1 file changed, 5 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index fe81c565e7ef..086ba2c2f60b 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -746,49 +746,10 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
> {
> struct ttm_bo_device *bdev = bo->bdev;
> struct ttm_mem_reg *old_mem = &bo->mem;
> -
> struct ttm_mem_type_manager *from = &bdev->man[old_mem->mem_type];
> - struct ttm_mem_type_manager *to = &bdev->man[new_mem->mem_type];
> -
> - int ret;
> -
> - dma_resv_add_excl_fence(bo->base.resv, fence);
> -
> - if (!evict) {
> - struct ttm_buffer_object *ghost_obj;
> -
> - /**
> - * This should help pipeline ordinary buffer moves.
> - *
> - * Hang old buffer memory on a new buffer object,
> - * and leave it to be released when the GPU
> - * operation has completed.
> - */
> -
> - dma_fence_put(bo->moving);
> - bo->moving = dma_fence_get(fence);
>
> - ret = ttm_buffer_object_transfer(bo, &ghost_obj);
> - if (ret)
> - return ret;
> -
> - dma_resv_add_excl_fence(ghost_obj->base.resv, fence);
> -
> - /**
> - * If we're not moving to fixed memory, the TTM object
> - * needs to stay alive. Otherwhise hang it on the ghost
> - * bo to be unbound and destroyed.
> - */
> -
> - if (!(to->flags & TTM_MEMTYPE_FLAG_FIXED))
> - ghost_obj->ttm = NULL;
> - else
> - bo->ttm = NULL;
> -
> - ttm_bo_unreserve(ghost_obj);
> - ttm_bo_put(ghost_obj);
> -
> - } else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
> + if (evict && from->flags & TTM_MEMTYPE_FLAG_FIXED) {
> + dma_resv_add_excl_fence(bo->base.resv, fence);
>
> /**
>* BO doesn't have a TTM we need to bind/unbind. Just remember
> @@ -807,27 +768,12 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
> dma_fence_put(bo->moving);
> bo->moving = dma_fence_get(fence);
>
> + *old_mem = *new_mem;
> + new_mem->mm_node = NULL;
> } else {
> - /**
> - * Last resort, wait for the move to be completed.
> - *
> - * Should never happen in pratice.
> - */
> -
> - ret = ttm_bo_wait(bo, false, false);
> - if (ret)
> - return ret;
> -
> - if (to->flags & TTM_MEMTYPE_FLAG_FIXED) {
> - ttm_tt_destroy(bo->ttm);
> - bo->ttm = NULL;
> - }
> - ttm_bo_free_old_node(bo);
> + return ttm_bo_move_accel_cleanup(bo, fence, evict, new_mem);
> }
>
> - *old_mem = *new_mem;
> - new_mem->mm_node = NULL;
> -
> return 0;
> }
> EXPORT_SYMBOL(ttm_bo_pipeline_move);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dma-fence: Simply wrap dma_fence_signal_locked with dma_fence_signal
On Fri, Aug 16, 2019 at 9:02 PM Koenig, Christian
wrote:
>
> Am 16.08.19 um 17:21 schrieb Chris Wilson:
> > Currently dma_fence_signal() tries to avoid the spinlock and only takes
> > it if absolutely required to walk the callback list. However, to allow
> > for some users to surreptitiously insert lazy signal callbacks that
> > do not depend on enabling the signaling mechanism around every fence,
> > we always need to notify the callbacks on signaling. As such, we will
> > always need to take the spinlock and dma_fence_signal() effectively
> > becomes a clone of dma_fence_signal_locked().
> >
> > Signed-off-by: Chris Wilson
> > Cc: Christian König
> > Cc: Daniel Vetter
> > ---
> > drivers/dma-buf/dma-fence.c | 19 +--
> > 1 file changed, 5 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index ff0cd6eae766..f23eb9f19b4e 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -176,6 +176,7 @@ EXPORT_SYMBOL(dma_fence_signal_locked);
> > int dma_fence_signal(struct dma_fence *fence)
> > {
> > unsigned long flags;
> > + int ret;
> >
> > if (!fence)
> > return -EINVAL;
> > @@ -183,21 +184,11 @@ int dma_fence_signal(struct dma_fence *fence)
> > if (test_and_set_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> > return -EINVAL;
>
> I need to take my review back. You also need to drop this
> test_and_set_bit here or your completely break drivers using this.
Time for a pile of dma_fence selftests? Maybe with a bit of dma_resv
thrown in for good? This stuff is tricky, and it feels like we had a
few oopsies in review recently ...
-Daniel
> Regards,
> Christian.
>
> >
> > - fence->timestamp = ktime_get();
> > - set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags);
> > - trace_dma_fence_signaled(fence);
> > -
> > - if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags)) {
> > - struct dma_fence_cb *cur, *tmp;
> > + spin_lock_irqsave(fence->lock, flags);
> > + ret = dma_fence_signal_locked(fence);
> > + spin_unlock_irqrestore(fence->lock, flags);
> >
> > - spin_lock_irqsave(fence->lock, flags);
> > - list_for_each_entry_safe(cur, tmp, &fence->cb_list, node) {
> > - list_del_init(&cur->node);
> > - cur->func(fence, cur);
> > - }
> > - spin_unlock_irqrestore(fence->lock, flags);
> > - }
> > - return 0;
> > + return ret;
> > }
> > EXPORT_SYMBOL(dma_fence_signal);
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dma-fence: Simply wrap dma_fence_signal_locked with dma_fence_signal
Am 16.08.19 um 17:21 schrieb Chris Wilson:
> Currently dma_fence_signal() tries to avoid the spinlock and only takes
> it if absolutely required to walk the callback list. However, to allow
> for some users to surreptitiously insert lazy signal callbacks that
> do not depend on enabling the signaling mechanism around every fence,
> we always need to notify the callbacks on signaling. As such, we will
> always need to take the spinlock and dma_fence_signal() effectively
> becomes a clone of dma_fence_signal_locked().
>
> Signed-off-by: Chris Wilson
> Cc: Christian König
> Cc: Daniel Vetter
> ---
> drivers/dma-buf/dma-fence.c | 19 +--
> 1 file changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index ff0cd6eae766..f23eb9f19b4e 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -176,6 +176,7 @@ EXPORT_SYMBOL(dma_fence_signal_locked);
> int dma_fence_signal(struct dma_fence *fence)
> {
> unsigned long flags;
> + int ret;
>
> if (!fence)
> return -EINVAL;
> @@ -183,21 +184,11 @@ int dma_fence_signal(struct dma_fence *fence)
> if (test_and_set_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> return -EINVAL;
I need to take my review back. You also need to drop this
test_and_set_bit here or your completely break drivers using this.
Regards,
Christian.
>
> - fence->timestamp = ktime_get();
> - set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags);
> - trace_dma_fence_signaled(fence);
> -
> - if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags)) {
> - struct dma_fence_cb *cur, *tmp;
> + spin_lock_irqsave(fence->lock, flags);
> + ret = dma_fence_signal_locked(fence);
> + spin_unlock_irqrestore(fence->lock, flags);
>
> - spin_lock_irqsave(fence->lock, flags);
> - list_for_each_entry_safe(cur, tmp, &fence->cb_list, node) {
> - list_del_init(&cur->node);
> - cur->func(fence, cur);
> - }
> - spin_unlock_irqrestore(fence->lock, flags);
> - }
> - return 0;
> + return ret;
> }
> EXPORT_SYMBOL(dma_fence_signal);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: Refactor ttm_bo_pipeline_move
ttm_bo_pipeline_move needlessly duplicates code. Refactor this to
instead call ttm_bo_move_accel_cleanup.
Signed-off-by: Brian Welty
---
Builds but otherwise currently untested.
Came across this duplication and thought would see if others cared
to see it cleaned up this way or not.
drivers/gpu/drm/ttm/ttm_bo_util.c | 64 +++
1 file changed, 5 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index fe81c565e7ef..086ba2c2f60b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -746,49 +746,10 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
{
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_mem_reg *old_mem = &bo->mem;
-
struct ttm_mem_type_manager *from = &bdev->man[old_mem->mem_type];
- struct ttm_mem_type_manager *to = &bdev->man[new_mem->mem_type];
-
- int ret;
-
- dma_resv_add_excl_fence(bo->base.resv, fence);
-
- if (!evict) {
- struct ttm_buffer_object *ghost_obj;
-
- /**
-* This should help pipeline ordinary buffer moves.
-*
-* Hang old buffer memory on a new buffer object,
-* and leave it to be released when the GPU
-* operation has completed.
-*/
-
- dma_fence_put(bo->moving);
- bo->moving = dma_fence_get(fence);
- ret = ttm_buffer_object_transfer(bo, &ghost_obj);
- if (ret)
- return ret;
-
- dma_resv_add_excl_fence(ghost_obj->base.resv, fence);
-
- /**
-* If we're not moving to fixed memory, the TTM object
-* needs to stay alive. Otherwhise hang it on the ghost
-* bo to be unbound and destroyed.
-*/
-
- if (!(to->flags & TTM_MEMTYPE_FLAG_FIXED))
- ghost_obj->ttm = NULL;
- else
- bo->ttm = NULL;
-
- ttm_bo_unreserve(ghost_obj);
- ttm_bo_put(ghost_obj);
-
- } else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
+ if (evict && from->flags & TTM_MEMTYPE_FLAG_FIXED) {
+ dma_resv_add_excl_fence(bo->base.resv, fence);
/**
* BO doesn't have a TTM we need to bind/unbind. Just remember
@@ -807,27 +768,12 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
dma_fence_put(bo->moving);
bo->moving = dma_fence_get(fence);
+ *old_mem = *new_mem;
+ new_mem->mm_node = NULL;
} else {
- /**
-* Last resort, wait for the move to be completed.
-*
-* Should never happen in pratice.
-*/
-
- ret = ttm_bo_wait(bo, false, false);
- if (ret)
- return ret;
-
- if (to->flags & TTM_MEMTYPE_FLAG_FIXED) {
- ttm_tt_destroy(bo->ttm);
- bo->ttm = NULL;
- }
- ttm_bo_free_old_node(bo);
+ return ttm_bo_move_accel_cleanup(bo, fence, evict, new_mem);
}
- *old_mem = *new_mem;
- new_mem->mm_node = NULL;
-
return 0;
}
EXPORT_SYMBOL(ttm_bo_pipeline_move);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DMA-API: cacheline tracking ENOMEM, dma-debug disabled due to nouveau ?
On Fri, Aug 16, 2019 at 4:31 PM Corentin Labbe wrote: > On Wed, Aug 14, 2019 at 07:49:27PM +0200, Daniel Vetter wrote: > > On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote: > > > Hello > > > > > > Since lot of release (at least since 4.19), I hit the following error > > > message: > > > DMA-API: cacheline tracking ENOMEM, dma-debug disabled > > > > > > After hitting that, I try to check who is creating so many DMA mapping > > > and see: > > > cat /sys/kernel/debug/dma-api/dump | cut -d' ' -f2 | sort | uniq -c > > > 6 ahci > > > 257 e1000e > > > 6 ehci-pci > > >5891 nouveau > > > 24 uhci_hcd > > > > > > Does nouveau having this high number of DMA mapping is normal ? > > > > Yeah seems perfectly fine for a gpu. > > Note that it never go down and when I terminate my X session, it stays the > same. > So without any "real" GPU work, does it is still normal to have so many > active mapping ? Might just be the dma_alloc cache. It should go down under memory pressure I think. Otherwise might also be a leak. > For example, when doing some transfer, the ahci mapping number changes and > then always go down to 6. gpu drivers tend to cache everything, all the time ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] video: omapfb2: Make standard and custom panel drivers mutually exclusive
Hi Sam, On Fri, Aug 16, 2019 at 07:31:05PM +0200, Sam Ravnborg wrote: > Hi Laurent > > Thanks for beating me on this! > > On Fri, Aug 16, 2019 at 03:22:27PM +0300, Laurent Pinchart wrote: > > Standard DRM panel drivers for several panels used by omapfb2 are now > > available. Their module name clashes with the modules from > > drivers/gpu/drm/omapdrm/displays/, part of the deprecated omapfb2 fbdev > > driver. As omapfb2 can only be compiled when the omapdrm driver is > > disabled, and the DRM panel drivers are useless in that case, make the > > omapfb2 panels depend on the standard DRM panels being disabled to fix > > the name clash. > > > > Signed-off-by: Laurent Pinchart > > --- > > drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig > > b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig > > index 8c1c5a4cfe18..744416dc530e 100644 > > --- a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig > > +++ b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig > > @@ -49,6 +49,7 @@ config FB_OMAP2_PANEL_DSI_CM > > config FB_OMAP2_PANEL_SONY_ACX565AKM > > tristate "ACX565AKM Panel" > > depends on SPI && BACKLIGHT_CLASS_DEVICE > > + depends on DRM_PANEL_SONY_ACX565AKM = n > > Would: > depends on !DRM_PANEL_SONY_ACX565AKM > > do the same? > > Example: > config FB_INTEL > tristate "Intel 830M/845G/852GM/855GM/865G/915G/945G/945GM/965G/965GM > support" > depends on FB && PCI && X86 && AGP_INTEL && EXPERT > ... > depends on !DRM_I915 > > > DRM_915 is a tristate symbol. > > It is maybe bikeshedding, but the ! seems more logical/readable to me. The two are equivalent as far as I can tell, so I'm fine with !. Would you change that when applying, or should I send a v2 ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=104602 --- Comment #22 from Marek Olšák --- Connor, the hardware manages the scratch buffer alloc/dealloc. You don't have to allocate more than one. The problem with Civ VI is that VGPR indexing has never been properly implemented for gfx9 in LLVM. -- 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] dma-buf: Fix memory leak in dma_buf_set_name
This patch fixes a memory leak bug reported by syzbot. Link to the bug is given at [1]. A local variable name is used to hold the copied user buffer string using strndup_user. strndup_user allocates memory using kmalloc_track_caller in memdup_user. This kmalloc allocation needs to be followed by a kfree. This patch has been tested by a compile test. [1] https://syzkaller.appspot.com/bug?id=ce692a3aa13e00e335e090be7846c6eb60ddff7a Reported-by: syzbot+b2098bc44728a4efb...@syzkaller.appspotmail.com Signed-off-by: Bharath Vedartham --- drivers/dma-buf/dma-buf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index f45bfb2..9798f6d 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -342,6 +342,7 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) } kfree(dmabuf->name); dmabuf->name = name; + kfree(name); out_unlock: mutex_unlock(&dmabuf->lock); -- 2.7.4
Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs
On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote: > On 07/08/2019 21:15, Matthias Kaehlcke wrote: > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > Backlight brightness curves can have different shapes. The two main > > > types are linear and non-linear curves. The human eye doesn't > > > perceive linearly increasing/decreasing brightness as linear (see > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > linearly to human eye"), hence many backlights use non-linear (often > > > logarithmic) brightness curves. The type of curve currently is opaque > > > to userspace, so userspace often uses more or less reliable heuristics > > > (like the number of brightness levels) to decide whether to treat a > > > backlight device as linear or non-linear. > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > 'unknown'. For devices that don't provide information about the scale > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > Signed-off-by: Matthias Kaehlcke > > > > Daniel (et al): do you have any more comments on this patch/series or > > is it ready to land? > > I decided to leave it for a long while for others to review since I'm still > a tiny bit uneasy about the linear/non-linear terminology. > > However that's my only concern, its fairly minor and I've dragged by feet > for more then long enough, so: > Reviewed-by: Daniel Thompson Thanks! If you or someone else has another suggestion for the terminology that we can all agree on I'm happy to change it.
Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs
Hi Uwe, On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > Backlight brightness curves can have different shapes. The two main > > types are linear and non-linear curves. The human eye doesn't > > perceive linearly increasing/decreasing brightness as linear (see > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > linearly to human eye"), hence many backlights use non-linear (often > > logarithmic) brightness curves. The type of curve currently is opaque > > to userspace, so userspace often uses more or less reliable heuristics > > (like the number of brightness levels) to decide whether to treat a > > backlight device as linear or non-linear. > > > > Export the type of the brightness curve via the new sysfs attribute > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > 'unknown'. For devices that don't provide information about the scale > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > Signed-off-by: Matthias Kaehlcke > > I wonder what kind of problem you are solving here. Can you describe > that in a few words? The human eye perceives brightness in a logarithmic manner. For backlights with a linear brightness curve brightness controls like sliders need to use a mapping to achieve a behavior that is perceived as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) As of now userspace doesn't have information about the type of the brightness curve, and often uses heuristics to make a guess, which may be right most of the time, but not always. The new attribute eliminates the need to guess. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] video: omapfb2: Make standard and custom panel drivers mutually exclusive
Hi Laurent Thanks for beating me on this! On Fri, Aug 16, 2019 at 03:22:27PM +0300, Laurent Pinchart wrote: > Standard DRM panel drivers for several panels used by omapfb2 are now > available. Their module name clashes with the modules from > drivers/gpu/drm/omapdrm/displays/, part of the deprecated omapfb2 fbdev > driver. As omapfb2 can only be compiled when the omapdrm driver is > disabled, and the DRM panel drivers are useless in that case, make the > omapfb2 panels depend on the standard DRM panels being disabled to fix > the name clash. > > Signed-off-by: Laurent Pinchart > --- > drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig > b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig > index 8c1c5a4cfe18..744416dc530e 100644 > --- a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig > +++ b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig > @@ -49,6 +49,7 @@ config FB_OMAP2_PANEL_DSI_CM > config FB_OMAP2_PANEL_SONY_ACX565AKM > tristate "ACX565AKM Panel" > depends on SPI && BACKLIGHT_CLASS_DEVICE > + depends on DRM_PANEL_SONY_ACX565AKM = n Would: depends on !DRM_PANEL_SONY_ACX565AKM do the same? Example: config FB_INTEL tristate "Intel 830M/845G/852GM/855GM/865G/915G/945G/945GM/965G/965GM support" depends on FB && PCI && X86 && AGP_INTEL && EXPERT ... depends on !DRM_I915 DRM_915 is a tristate symbol. It is maybe bikeshedding, but the ! seems more logical/readable to me. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk
On Fri, Aug 16, 2019 at 5:24 AM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 08:54:46PM -0700, Dan Williams wrote: > > > > However, this means we cannot do any processing of ZONE_DEVICE pages > > > outside the driver lock, so eg, doing any DMA map that might rely on > > > MEMORY_DEVICE_PCI_P2PDMA has to be done in the driver lock, which is > > > a bit unfortunate. > > > > Wouldn't P2PDMA use page pins? Not needing to hold a lock over > > ZONE_DEVICE page operations was one of the motivations for plumbing > > get_dev_pagemap() with a percpu-ref. > > hmm_range_fault() doesn't use page pins at all, so if a ZONE_DEVICE > page comes out of it then it needs to use another locking pattern. > > If I follow it all right: > > We can do a get_dev_pagemap inside the page_walk and touch the pgmap, > or we can do the 'device mutex && retry' pattern and touch the pgmap > in the driver, under that lock. > > However in all cases the current get_dev_pagemap()'s in the page walk > are not necessary, and we can delete them. Yes, as long as 'struct page' instances resulting from that lookup are not passed outside of that lock. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] mm: Check if mmu notifier callbacks are allowed to fail
On Wed, Aug 14, 2019 at 10:20:23PM +0200, Daniel Vetter wrote: > Just a bit of paranoia, since if we start pushing this deep into > callchains it's hard to spot all places where an mmu notifier > implementation might fail when it's not allowed to. > > Inspired by some confusion we had discussing i915 mmu notifiers and > whether we could use the newly-introduced return value to handle some > corner cases. Until we realized that these are only for when a task > has been killed by the oom reaper. > > An alternative approach would be to split the callback into two > versions, one with the int return value, and the other with void > return value like in older kernels. But that's a lot more churn for > fairly little gain I think. > > Summary from the m-l discussion on why we want something at warning > level: This allows automated tooling in CI to catch bugs without > humans having to look at everything. If we just upgrade the existing > pr_info to a pr_warn, then we'll have false positives. And as-is, no > one will ever spot the problem since it's lost in the massive amounts > of overall dmesg noise. > > v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for > the problematic case (Michal Hocko). > > v3: Rebase on top of Glisse's arg rework. > > v4: More rebase on top of Glisse reworking everything. > > v5: Fixup rebase damage and also catch failures != EAGAIN for > !blockable (Jason). Also go back to WARN_ON as requested by Jason, so > automatic checkers can easily catch bugs by setting panic_on_warn. > > Cc: Andrew Morton > Cc: Michal Hocko > Cc: "Christian König" > Cc: David Rientjes > Cc: Daniel Vetter > Cc: "Jérôme Glisse" > Cc: linux...@kvack.org > Cc: Paolo Bonzini > Cc: Jason Gunthorpe > Signed-off-by: Daniel Vetter > --- > mm/mmu_notifier.c | 2 ++ > 1 file changed, 2 insertions(+) Applied to hmm.git, thanks Jason
Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs
On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > Backlight brightness curves can have different shapes. The two main > types are linear and non-linear curves. The human eye doesn't > perceive linearly increasing/decreasing brightness as linear (see > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > linearly to human eye"), hence many backlights use non-linear (often > logarithmic) brightness curves. The type of curve currently is opaque > to userspace, so userspace often uses more or less reliable heuristics > (like the number of brightness levels) to decide whether to treat a > backlight device as linear or non-linear. > > Export the type of the brightness curve via the new sysfs attribute > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > 'unknown'. For devices that don't provide information about the scale > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > Signed-off-by: Matthias Kaehlcke I wonder what kind of problem you are solving here. Can you describe that in a few words? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Fri, Aug 16, 2019 at 4:38 PM Jason Gunthorpe wrote: > > On Fri, Aug 16, 2019 at 04:11:34PM +0200, Daniel Vetter wrote: > > Also, aside from this patch (which is prep for the next) and some > > simple reordering conflicts they're all independent. So if there's no > > way to paint this bikeshed here (technicolor perhaps?) then I'd like > > to get at least the others considered. > > Sure, I think for conflict avoidance reasons I'm probably taking > mmu_notifier stuff via hmm.git, so: > > - Andrew had a minor remark on #1, I am ambivalent and would take it > as-is. Your decision if you want to respin. I like mine better, see also the reply from Ralph Campbell. > - #2/#3 is this issue, I would stand by the preempt_disable/etc path > Our situation matches yours, debug tests run lockdep/etc. Since Michal requested the current flavour I think we need spin a bit more on these here. I guess I'll just rebase them to the end so they're not holding up the others. > - #4 I like a lot, except the map should enclose range_end too, > this can be done after the mm_has_notifiers inside the > __mmu_notifier function To make sure I get this right: The same lockdep context, but also wrapped around invalidate_range_end? From my understanding of pte zapping that makes sense, but I'm definitely not well-versed enough for that. > Can you respin? Will do. > I will propose preloading the map in another patch > - #5 is already applied in -rc Yup, I'll drop that one. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.3-rc5
The pull request you sent on Fri, 16 Aug 2019 14:21:56 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-08-16 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ec037ac244c070f9eedcdf5cdb23bd817e7b8cf4 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: [PATCH 1/2] dma-buf: Avoid list_del during fence->cb_list iteration
Am 16.08.19 um 17:21 schrieb Chris Wilson:
> Before we notify the fence signal callback, we remove the cb from the
> list. However, since we are processing the entire list from underneath
> the spinlock, we do not need to individual delete each element, but can
> simply reset the link and the entire list.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Christian König
Reviewed-by: Christian König for the series.
> ---
> drivers/dma-buf/dma-fence.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 8025a891d3e9..ff0cd6eae766 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -149,9 +149,12 @@ int dma_fence_signal_locked(struct dma_fence *fence)
> trace_dma_fence_signaled(fence);
> }
>
> - list_for_each_entry_safe(cur, tmp, &fence->cb_list, node) {
> - list_del_init(&cur->node);
> - cur->func(fence, cur);
> + if (!list_empty(&fence->cb_list)) {
> + list_for_each_entry_safe(cur, tmp, &fence->cb_list, node) {
> + INIT_LIST_HEAD(&cur->node);
> + cur->func(fence, cur);
> + }
> + INIT_LIST_HEAD(&fence->cb_list);
> }
> return ret;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm/hmm: hmm_range_fault handle pages swapped out
On 2019-08-15 8:54 p.m., Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 08:52:56PM +, Yang, Philip wrote: >> hmm_range_fault may return NULL pages because some of pfns are equal to >> HMM_PFN_NONE. This happens randomly under memory pressure. The reason is >> for swapped out page pte path, hmm_vma_handle_pte doesn't update fault >> variable from cpu_flags, so it failed to call hmm_vam_do_fault to swap >> the page in. >> >> The fix is to call hmm_pte_need_fault to update fault variable. > >> Change-Id: I2e8611485563d11d938881c18b7935fa1e7c91ee > > I'll fix it for you but please be careful not to send Change-id's to > the public lists. > Thanks, the change-id was added by our Gerrit hook, I need generate patch files, remove change-id line and then send out modified patch files in future. > Also what is the Fixes line for this? > This fixes the issue found by the internal rocrtst, the rocrtstFunc.Memory_Max_Mem evicted some user buffers, and then following test restore those user buffers failed because the buffers are swapped out and application doesn't touch the buffers to swap it in. >> Signed-off-by: Philip Yang >> mm/hmm.c | 3 +++ >> 1 file changed, 3 insertions(+) > > Ralph has also been looking at this area also so I'll give him a bit > to chime in, otherwise with Jerome's review this looks OK to go to > linux-next > Ok, thanks for helping push this to hmm branch at https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git > Thanks, > Jason > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs
On 07/08/2019 21:15, Matthias Kaehlcke wrote: On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: Backlight brightness curves can have different shapes. The two main types are linear and non-linear curves. The human eye doesn't perceive linearly increasing/decreasing brightness as linear (see also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED linearly to human eye"), hence many backlights use non-linear (often logarithmic) brightness curves. The type of curve currently is opaque to userspace, so userspace often uses more or less reliable heuristics (like the number of brightness levels) to decide whether to treat a backlight device as linear or non-linear. Export the type of the brightness curve via the new sysfs attribute 'scale'. The value of the attribute can be 'linear', 'non-linear' or 'unknown'. For devices that don't provide information about the scale of their brightness curve the value of the 'scale' attribute is 'unknown'. Signed-off-by: Matthias Kaehlcke Daniel (et al): do you have any more comments on this patch/series or is it ready to land? I decided to leave it for a long while for others to review since I'm still a tiny bit uneasy about the linear/non-linear terminology. However that's my only concern, its fairly minor and I've dragged by feet for more then long enough, so: Reviewed-by: Daniel Thompson Daniel.
Re: [PATCH v3 0/7] backlight: gpio: simplify the driver
czw., 8 sie 2019 o 10:17 Bartosz Golaszewski napisał(a): > > śr., 24 lip 2019 o 10:25 Bartosz Golaszewski napisał(a): > > > > From: Bartosz Golaszewski > > > > While working on my other series related to gpio-backlight[1] I noticed > > that we could simplify the driver if we made the only user of platform > > data use GPIO lookups and device properties. This series tries to do > > that. > > > > The first patch adds all necessary data structures to ecovec24. Patch > > 2/7 unifies much of the code for both pdata and non-pdata cases. Patches > > 3-4/7 remove unused platform data fields. Last three patches contain > > additional improvements for the GPIO backlight driver while we're already > > modifying it. > > > > I don't have access to this HW but hopefully this works. Only compile > > tested. > > > > [1] https://lkml.org/lkml/2019/6/25/900 > > > > v1 -> v2: > > - rebased on top of v5.3-rc1 and adjusted to the recent changes from Andy > > - added additional two patches with minor improvements > > > > v2 -> v3: > > - in patch 7/7: used initializers to set values for pdata and dev local vars > > > > Bartosz Golaszewski (7): > > sh: ecovec24: add additional properties to the backlight device > > backlight: gpio: simplify the platform data handling > > sh: ecovec24: don't set unused fields in platform data > > backlight: gpio: remove unused fields from platform data > > backlight: gpio: remove dev from struct gpio_backlight > > backlight: gpio: remove def_value from struct gpio_backlight > > backlight: gpio: use a helper variable for &pdev->dev > > > > arch/sh/boards/mach-ecovec24/setup.c | 33 ++-- > > drivers/video/backlight/gpio_backlight.c | 82 +--- > > include/linux/platform_data/gpio_backlight.h | 3 - > > 3 files changed, 44 insertions(+), 74 deletions(-) > > > > -- > > 2.21.0 > > > > Hi Rich, Yoshinori, > > can you ack the sh patches in this series? > > Bart Ping.
[PATCH 2/2] dma-fence: Simply wrap dma_fence_signal_locked with dma_fence_signal
Currently dma_fence_signal() tries to avoid the spinlock and only takes
it if absolutely required to walk the callback list. However, to allow
for some users to surreptitiously insert lazy signal callbacks that
do not depend on enabling the signaling mechanism around every fence,
we always need to notify the callbacks on signaling. As such, we will
always need to take the spinlock and dma_fence_signal() effectively
becomes a clone of dma_fence_signal_locked().
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vetter
---
drivers/dma-buf/dma-fence.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index ff0cd6eae766..f23eb9f19b4e 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -176,6 +176,7 @@ EXPORT_SYMBOL(dma_fence_signal_locked);
int dma_fence_signal(struct dma_fence *fence)
{
unsigned long flags;
+ int ret;
if (!fence)
return -EINVAL;
@@ -183,21 +184,11 @@ int dma_fence_signal(struct dma_fence *fence)
if (test_and_set_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
return -EINVAL;
- fence->timestamp = ktime_get();
- set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags);
- trace_dma_fence_signaled(fence);
-
- if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags)) {
- struct dma_fence_cb *cur, *tmp;
+ spin_lock_irqsave(fence->lock, flags);
+ ret = dma_fence_signal_locked(fence);
+ spin_unlock_irqrestore(fence->lock, flags);
- spin_lock_irqsave(fence->lock, flags);
- list_for_each_entry_safe(cur, tmp, &fence->cb_list, node) {
- list_del_init(&cur->node);
- cur->func(fence, cur);
- }
- spin_unlock_irqrestore(fence->lock, flags);
- }
- return 0;
+ return ret;
}
EXPORT_SYMBOL(dma_fence_signal);
--
2.23.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dma-buf: Avoid list_del during fence->cb_list iteration
Before we notify the fence signal callback, we remove the cb from the
list. However, since we are processing the entire list from underneath
the spinlock, we do not need to individual delete each element, but can
simply reset the link and the entire list.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Christian König
---
drivers/dma-buf/dma-fence.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 8025a891d3e9..ff0cd6eae766 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -149,9 +149,12 @@ int dma_fence_signal_locked(struct dma_fence *fence)
trace_dma_fence_signaled(fence);
}
- list_for_each_entry_safe(cur, tmp, &fence->cb_list, node) {
- list_del_init(&cur->node);
- cur->func(fence, cur);
+ if (!list_empty(&fence->cb_list)) {
+ list_for_each_entry_safe(cur, tmp, &fence->cb_list, node) {
+ INIT_LIST_HEAD(&cur->node);
+ cur->func(fence, cur);
+ }
+ INIT_LIST_HEAD(&fence->cb_list);
}
return ret;
}
--
2.23.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] kernel.h: Add non_block_start/end()
On Fri, Aug 16, 2019 at 11:31:45AM -0300, Jason Gunthorpe wrote: > On Fri, Aug 16, 2019 at 02:26:25PM +0200, Michal Hocko wrote: > > On Fri 16-08-19 09:19:06, Jason Gunthorpe wrote: > > > On Fri, Aug 16, 2019 at 10:10:29AM +0200, Michal Hocko wrote: > > > > On Thu 15-08-19 17:13:23, Jason Gunthorpe wrote: > > > > > On Thu, Aug 15, 2019 at 09:35:26PM +0200, Michal Hocko wrote: [...] > > > I would like to inject it into the notifier path as this is very > > > difficult for driver authors to discover and know about, but I'm > > > worried about your false positive remark. > > > > > > I think I understand we can use only GFP_ATOMIC in the notifiers, but > > > we need a strategy to handle OOM to guarentee forward progress. > > > > Your example is from the notifier registration IIUC. > > Yes, that is where this commit hit it.. Triggering this under an > actual notifier to get a lockdep report is hard. > > > Can you pre-allocate before taking locks? Could you point me to some > > examples when the allocation is necessary in the range notifier > > callback? > > Hmm. I took a careful look, I only found mlx5 as obviously allocating > memory: > > mlx5_ib_invalidate_range() > mlx5_ib_update_xlt() >__get_free_pages(gfp, get_order(size)); > > However, I think this could be changed to fall back to some small > buffer if allocation fails. The existing scheme looks sketchy > > nouveau does: > > nouveau_svmm_invalidate > nvif_object_mthd >kmalloc(GFP_KERNEL) > > But I think it reliably uses a stack buffer here > > i915 I think Daniel said he audited. > > amd_mn.. The actual invalidate_range_start does not allocate memory, > but it is entangled with so many locks it would need careful analysis > to be sure. > > The others look generally OK, which is good, better than I hoped :) It is on my TODO list to get rid of allocation in notifier callback (iirc nouveau already use the stack unless it was lost in all the revision it wants through). Anyway i do not think we need allocation in notifier. Cheers, Jérôme
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Fri, Aug 16, 2019 at 04:11:34PM +0200, Daniel Vetter wrote: > Also, aside from this patch (which is prep for the next) and some > simple reordering conflicts they're all independent. So if there's no > way to paint this bikeshed here (technicolor perhaps?) then I'd like > to get at least the others considered. Sure, I think for conflict avoidance reasons I'm probably taking mmu_notifier stuff via hmm.git, so: - Andrew had a minor remark on #1, I am ambivalent and would take it as-is. Your decision if you want to respin. - #2/#3 is this issue, I would stand by the preempt_disable/etc path Our situation matches yours, debug tests run lockdep/etc. - #4 I like a lot, except the map should enclose range_end too, this can be done after the mm_has_notifiers inside the __mmu_notifier function Can you respin? I will propose preloading the map in another patch - #5 is already applied in -rc Jason
Re: DMA-API: cacheline tracking ENOMEM, dma-debug disabled due to nouveau ?
On Wed, Aug 14, 2019 at 07:49:27PM +0200, Daniel Vetter wrote: > On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote: > > Hello > > > > Since lot of release (at least since 4.19), I hit the following error > > message: > > DMA-API: cacheline tracking ENOMEM, dma-debug disabled > > > > After hitting that, I try to check who is creating so many DMA mapping and > > see: > > cat /sys/kernel/debug/dma-api/dump | cut -d' ' -f2 | sort | uniq -c > > 6 ahci > > 257 e1000e > > 6 ehci-pci > >5891 nouveau > > 24 uhci_hcd > > > > Does nouveau having this high number of DMA mapping is normal ? > > Yeah seems perfectly fine for a gpu. Note that it never go down and when I terminate my X session, it stays the same. So without any "real" GPU work, does it is still normal to have so many active mapping ? For example, when doing some transfer, the ahci mapping number changes and then always go down to 6. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] kernel.h: Add non_block_start/end()
On Fri, Aug 16, 2019 at 02:26:25PM +0200, Michal Hocko wrote:
> On Fri 16-08-19 09:19:06, Jason Gunthorpe wrote:
> > On Fri, Aug 16, 2019 at 10:10:29AM +0200, Michal Hocko wrote:
> > > On Thu 15-08-19 17:13:23, Jason Gunthorpe wrote:
> > > > On Thu, Aug 15, 2019 at 09:35:26PM +0200, Michal Hocko wrote:
> > > >
> > > > > > The last detail is I'm still unclear what a GFP flags a blockable
> > > > > > invalidate_range_start() should use. Is GFP_KERNEL OK?
> > > > >
> > > > > I hope I will not make this muddy again ;)
> > > > > invalidate_range_start in the blockable mode can use/depend on any
> > > > > sleepable
> > > > > allocation allowed in the context it is called from.
> > > >
> > > > 'in the context is is called from' is the magic phrase, as
> > > > invalidate_range_start is called while holding several different mm
> > > > related locks. I know at least write mmap_sem and i_mmap_rwsem
> > > > (write?)
> > > >
> > > > Can GFP_KERNEL be called while holding those locks?
> > >
> > > i_mmap_rwsem would be problematic because it is taken during the
> > > reclaim.
> >
> > Okay.. So the fs_reclaim debugging does catch errors.
>
> I do not think fs_reclaim is the udnerlying mechanism to catch this
> deadlock.
Indeed lockdep would catch it directly as an AA deadlock, but only if
we happen to take the reclaim path under the kmalloc in the notifier
and lucked into it also choosing to lock the same lock we are holding.
The trouble is this is very difficult to hit.
lockdep allows making this less difficult. For instance with a
'might_reclaim()' annotation in the allocator we could check that the
various reclaim related locks are obtainable. Testing doesn't need to
get lucky and go down the very unlikely path.
It turns out this is already happening, it is actually a side effect
of the way fs_reclaim works now.
> > Do you have any
> > reference for what a false positive looks like?
>
> I believe I have given some examples when introducing __GFP_NOLOCKDEP.
Okay, I think that is 7e7844226f10 ("lockdep: allow to disable reclaim
lockup detection") Hmm, sadly the lkml link in the commit is broken.
Hum. There are no users of __GFP_NOLOCKDEP today?? Could all the false
positives have been fixed??
Keep in mind that this fs_reclaim was reworked away from the hacky
interrupt context flag to a fairly elegant real lock map.
Based on my read of the commit message, my first reaction would be to
suggest lockdep_set_class() to solve the problem described, ie
different classes for 'inside transaction' and 'outside transaction'
on xfs_refcountbt_init_cursor()
I understood that generally that is the way to handle lockdep false
positives.
Anyhow, if you are willing to consider that lockdep isn't broken, I
have some ideas on how to make this clearer and increase
coverage. Would you be willing to look at patches on this topic? (not
soon, I have to finish my mmu notifier stuff)
> > I would like to inject it into the notifier path as this is very
> > difficult for driver authors to discover and know about, but I'm
> > worried about your false positive remark.
> >
> > I think I understand we can use only GFP_ATOMIC in the notifiers, but
> > we need a strategy to handle OOM to guarentee forward progress.
>
> Your example is from the notifier registration IIUC.
Yes, that is where this commit hit it.. Triggering this under an
actual notifier to get a lockdep report is hard.
> Can you pre-allocate before taking locks? Could you point me to some
> examples when the allocation is necessary in the range notifier
> callback?
Hmm. I took a careful look, I only found mlx5 as obviously allocating
memory:
mlx5_ib_invalidate_range()
mlx5_ib_update_xlt()
__get_free_pages(gfp, get_order(size));
However, I think this could be changed to fall back to some small
buffer if allocation fails. The existing scheme looks sketchy
nouveau does:
nouveau_svmm_invalidate
nvif_object_mthd
kmalloc(GFP_KERNEL)
But I think it reliably uses a stack buffer here
i915 I think Daniel said he audited.
amd_mn.. The actual invalidate_range_start does not allocate memory,
but it is entangled with so many locks it would need careful analysis
to be sure.
The others look generally OK, which is good, better than I hoped :)
Jason
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #107 from ReddestDream --- > Booting with amdgpu.dpm=0 on 5.2.7 works. > It is a DPM issue of some kind so although my earlier tests showed that > hard_min_level was set correctly, it still could be an issue elsewhere in the > DPM table. Great news! At least now we have a better place to investigate . . . -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110361] [CI][DRMTIP] igt@kms_chamelium@hdmi-cmp-planes-random - fail - Failed assertion: false, Conversion not implemented
https://bugs.freedesktop.org/show_bug.cgi?id=110361 emersion changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from emersion --- Not seen in 3 months. Closing. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Fri, Aug 16, 2019 at 2:12 PM Jason Gunthorpe wrote: > > On Fri, Aug 16, 2019 at 08:20:55AM +0200, Daniel Vetter wrote: > > On Fri, Aug 16, 2019 at 3:00 AM Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 10:49:31PM +0200, Daniel Vetter wrote: > > > > On Thu, Aug 15, 2019 at 10:27 PM Jason Gunthorpe wrote: > > > > > On Thu, Aug 15, 2019 at 10:16:43PM +0200, Daniel Vetter wrote: > > > > > > So if someone can explain to me how that works with lockdep I can of > > > > > > course implement it. But afaics that doesn't exist (I tried to > > > > > > explain > > > > > > that somewhere else already), and I'm no really looking forward to > > > > > > hacking also on lockdep for this little series. > > > > > > > > > > Hmm, kind of looks like it is done by calling preempt_disable() > > > > > > > > Yup. That was v1, then came the suggestion that disabling preemption > > > > is maybe not the best thing (the oom reaper could still run for a long > > > > time comparatively, if it's cleaning out gigabytes of process memory > > > > or what not, hence this dedicated debug infrastructure). > > > > > > Oh, I'm coming in late, sorry > > > > > > Anyhow, I was thinking since we agreed this can trigger on some > > > CONFIG_DEBUG flag, something like > > > > > > /* This is a sleepable region, but use preempt_disable to get > > > debugging > > > * for calls that are not allowed to block for OOM [.. insert > > > * Michal's explanation.. ] */ > > > if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP) && > > > !mmu_notifier_range_blockable(range)) > > > preempt_disable(); > > > ops->invalidate_range_start(); > > > > I think we also discussed that, and some expressed concerns it would > > change behaviour/timing too much for testing. Since this does does > > disable preemption for real, not just for might_sleep. > > I don't follow, this is a debug kernel, it will have widly different > timing. > > Further the point of this debugging on atomic_sleep is to be as > timing-independent as possible since functions with rare sleeps should > be guarded by might_sleep() in their common paths. > > I guess I don't get the push to have some low overhead debugging for > this? Is there something special you are looking for? Don't ask me, I'm just trying to get _some_ debugging for this in. I don't care one bit how much overhead it has because in our CI our debug build has lockdep and everything and it crawls anyway. I started out with the preempt_disable/enable thing like you suggested, and a few rounds later we're here. We can go back to v1 on this one, but I'd prefer to not do the lap too often. Also, aside from this patch (which is prep for the next) and some simple reordering conflicts they're all independent. So if there's no way to paint this bikeshed here (technicolor perhaps?) then I'd like to get at least the others considered. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [Intel-gfx] Linux Kernel 5.2.8 (uvc or i915?)
On Thu, 15 Aug 2019, Randy Dunlap wrote: > On 8/15/19 6:15 PM, Nathaniel Russell wrote: >> I would really like help with the kernel error with my uvcvideo driver. >> > > Hi again. > > What makes you think that the problem is related to the uvcvideo driver? > Does some previous kernel version work correctly? If so, what version(s)? > > > Does this warning message only happen when the uvcvideo driver is being > loaded? > Can you suppress loading of the uvcvideo driver to find out? > > Most of the problems/errors/warnings that I see are related to the i915 > driver: > > [ 13.032341] timed out waiting for port C ready: got 0x20, expected 0xe0 > [ 13.032872] WARNING: CPU: 1 PID: 239 at > drivers/gpu/drm/i915/intel_display.c:1597 vlv_wait_port_ready+0x99/0xe0 [i915] > [ 13.033632] RIP: 0010:vlv_wait_port_ready+0x99/0xe0 [i915] > > although there are a few uvcvideo warnings: > [ 13.039305] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not > initialized! > [ 13.039318] uvcvideo 1-5:1.0: Entity type for entity Extension 3 was not > initialized! > [ 13.039330] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was not > initialized! > [ 13.039339] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not > initialized! > > > Laurent, do you see any uvc issues here? Any ideas/suggestions? > > > @intel-gfx: any ideas about what is going on here with the i915 driver? Please file a bug over at [1], add drm.debug=14 module parameter, attach dmesg to the bug, all the way from boot to reproducing the issue. BR, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel > > > > Original message to lkml: > https://lore.kernel.org/lkml/CAONH+Jm-O6=dq+k2n5pntnmg2sq1kcvnfluwevh6w82opef...@mail.gmail.com/T/#u > > Previous message for 5.1.21 kernel: > https://lore.kernel.org/lkml/CAONH+JkTFujY9vEyNNuem+9rJ2qBKkf-PbKk9=DBSVEp6kW=y...@mail.gmail.com/ > > > thanks. -- Jani Nikula, Intel Open Source Graphics Center
[GIT PULL FOR v5.4] R-Car DU fix & misc. DRM cleanups
Hi Dave, The following changes since commit 8120ed5ebd2aaad1fee1a777effa158e5284b816: Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next (2019-08-16 12:43:21 +1000) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/du-next-20190816 for you to fetch changes up to 0b936e6122738f4cf474d1f3ff636cba0edc8b94: drm: rcar-du: lvds: Fix bridge_to_rcar_lvds (2019-08-16 15:50:27 +0300) - R-Car DU fixes - Misc. DRM cleanups Fabrizio Castro (1): drm: rcar-du: lvds: Fix bridge_to_rcar_lvds Laurent Pinchart (2): drm: Don't include drm/drm_encoder_slave.h when not needed drm: Remove bridge support from legacy helpers drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 - drivers/gpu/drm/drm_crtc_helper.c | 32 --- drivers/gpu/drm/imx/dw_hdmi-imx.c | 2 +- drivers/gpu/drm/rcar-du/rcar_lvds.c | 8 4 files changed, 5 insertions(+), 38 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] video: omapfb2: Make standard and custom panel drivers mutually exclusive
On Fri, Aug 16, 2019 at 04:20:46PM +0300, Tomi Valkeinen wrote: > On 16/08/2019 15:22, Laurent Pinchart wrote: > > Standard DRM panel drivers for several panels used by omapfb2 are now > > available. Their module name clashes with the modules from > > drivers/gpu/drm/omapdrm/displays/, part of the deprecated omapfb2 fbdev > > Shouldn't that path be drivers/video/fbdev/omap2/omapfb/displays? Absolutely :-) Could this be fixed when applying ? Otherwise I'll submit a v2. > > driver. As omapfb2 can only be compiled when the omapdrm driver is > > disabled, and the DRM panel drivers are useless in that case, make the > > omapfb2 panels depend on the standard DRM panels being disabled to fix > > the name clash. > > > > Signed-off-by: Laurent Pinchart > > --- > > drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 5 + > > 1 file changed, 5 insertions(+) > > Cc'd Bartlomiej. Oops, sorry, forgot to do that :-S > Reviewed-by: Tomi Valkeinen -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109380] [CI][BAT] igt@kms_chamelium@*- warn/fail - Last errno: 113, No route to host
https://bugs.freedesktop.org/show_bug.cgi?id=109380 --- Comment #6 from emersion --- Related bug about Chamelium not having all ports plugged in: https://bugs.freedesktop.org/show_bug.cgi?id=110940 -- 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 2/2] drm/omap: displays: Remove unused panel drivers
On 16/08/2019 15:22, Laurent Pinchart wrote: drm_panel-based drivers for the ACX565AKM, LB035Q02, LS037V7DW01, NL8048HL11, TD028TTEC1 and TD043MTEA1 are available, remove the omapdrm-specific drivers. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/omapdrm/displays/Kconfig | 38 - drivers/gpu/drm/omapdrm/displays/Makefile | 6 - .../displays/panel-lgphilips-lb035q02.c | 251 -- .../omapdrm/displays/panel-nec-nl8048hl11.c | 271 --- .../displays/panel-sharp-ls037v7dw01.c| 262 -- .../omapdrm/displays/panel-sony-acx565akm.c | 755 -- .../omapdrm/displays/panel-tpo-td028ttec1.c | 390 - .../omapdrm/displays/panel-tpo-td043mtea1.c | 513 .../gpu/drm/omapdrm/dss/omapdss-boot-init.c | 7 - 9 files changed, 2493 deletions(-) delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] video: omapfb2: Make standard and custom panel drivers mutually exclusive
On 16/08/2019 15:22, Laurent Pinchart wrote: Standard DRM panel drivers for several panels used by omapfb2 are now available. Their module name clashes with the modules from drivers/gpu/drm/omapdrm/displays/, part of the deprecated omapfb2 fbdev Shouldn't that path be drivers/video/fbdev/omap2/omapfb/displays? driver. As omapfb2 can only be compiled when the omapdrm driver is disabled, and the DRM panel drivers are useless in that case, make the omapfb2 panels depend on the standard DRM panels being disabled to fix the name clash. Signed-off-by: Laurent Pinchart --- drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 5 + 1 file changed, 5 insertions(+) Cc'd Bartlomiej. Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #106 from Tom B --- Booting with amdgpu.dpm=0 on 5.2.7 works. Performance is poor and as expected I cannot get any information about power states because /sys/kernel/debug/dri/0/amdgpu_pm_info doesn't exist. I'm guessing it runs at minimum clocks as I get ~10-17fps in unigine-heaven instead of ~60-100. It is a DPM issue of some kind so although my earlier tests showed that hard_min_level was set correctly, it still could be an issue elsewhere in the DPM table. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #105 from Tom B --- > Also, I considered that both of my monitors have audio out support. I wonder > if audio initialization might be the missing piece to the puzzle, the thing > that interrupts/changes the state of the card and prevents > smu_send_smc_msg_with_param from working where it did before. I know that in > the past with previous AMD cards, display audio has been buggy . I just tried setting admgpu.audio=0 and it didn't help. Though it doesn't rule out audio entirely, the audio backend is probably still used as part of the connection to the monitor, I'd imagine it just prevents the card appearing as an output device. -- 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
[GIT PULL FOR v5.3] R-Car LVDS fix
Hi Dave, The following changes since commit a85abd5d45adba75535b7fc6d9f78329a693b7a9: Merge tag 'drm-intel-fixes-2019-08-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2019-08-16 12:41:52 +1000) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/du-fixes-20190816 vi for you to fetch changes up to a53358a31c989c360ea59536d28762b9d2d68d19: drm: rcar_lvds: Fix dual link mode operations (2019-08-16 15:53:28 +0300) This fixes a bug introduced in v5.3, I'm thus sending it as a fix for the current kernel release candidate. If it's too late it could also be merged in v5.4. R-Car LVDS encoder fix Jacopo Mondi (1): drm: rcar_lvds: Fix dual link mode operations drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 204407] New: Bad page state in process Xorg
On 8/15/19 9:13 PM, Petr Vandrovec wrote: > Vlastimil Babka wrote on 8/15/2019 7:32 AM: >> >> Does the issue still happen with rc4? Could you apply the 3 attached >> patches (work in progress), configure-enable CONFIG_DEBUG_PAGEALLOC and >> CONFIG_PAGE_OWNER and boot kernel with debug_pagealloc=on page_owner=on >> parameters? That should print stacktraces of allocation and first >> freeing (assuming this is a double free). > > Unfortunately -rc4 does not find any my SATA disks due to some > misunderstanding between AHCI driver and HPT642L adapter (there is no > device 07:00.1, HPT is single-function device at 07:00.0): > > [ 18.003015] scsi host6: ahci > [ 18.006605] DMAR: DRHD: handling fault status reg 2 > [ 18.006619] DMAR: [DMA Write] Request device [07:00.1] fault addr > fffe [fault reason 02] Present bit in context entry is clear > [ 18.076616] DMAR: DRHD: handling fault status reg 102 > [ 18.085910] DMAR: [DMA Write] Request device [07:00.1] fault addr > fffa [fault reason 02] Present bit in context entry is clear > [ 18.100989] DMAR: DRHD: handling fault status reg 202 > [ 18.110985] DMAR: [DMA Write] Request device [07:00.1] fault addr > fffe [fault reason 02] Present bit in context entry is clear Worth reporting as well, not nice regression. > With iommu=off disks are visible, but USB keyboard (and other USB > devices) does not work: I've been told iommu=soft might help. > [ 18.174802] ehci-pci :00:1a.0: swiotlb buffer is full (sz: 8 > bytes), total 0 (slots), used 0 (slots) > [ 18.174804] ehci-pci :00:1a.0: overflow 0x000ffdc75ae8+8 of > DMA mask bus mask 0 > [ 18.174815] WARNING: CPU: 2 PID: 508 at kernel/dma/direct.c:35 > report_addr+0x2e/0x50 > [ 18.174816] Modules linked in: > [ 18.174818] CPU: 2 PID: 508 Comm: kworker/2:1 Tainted: G > T 5.3.0-rc4-64-00058-gd717b092e0b2 #77 > [ 18.174819] Hardware name: Dell Inc. Precision T3610/09M8Y8, BIOS A16 > 02/05/2018 > [ 18.174822] Workqueue: usb_hub_wq hub_event > > I'll try to find -rc4 configuration that has enabled debugging and can boot. > > > Petr > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107459] Atomically set gamma ramps are not applied until TTY switch
https://bugs.freedesktop.org/show_bug.cgi?id=107459 emersion changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] kernel.h: Add non_block_start/end()
On Fri 16-08-19 09:19:06, Jason Gunthorpe wrote: > On Fri, Aug 16, 2019 at 10:10:29AM +0200, Michal Hocko wrote: > > On Thu 15-08-19 17:13:23, Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 09:35:26PM +0200, Michal Hocko wrote: > > > > > > > > The last detail is I'm still unclear what a GFP flags a blockable > > > > > invalidate_range_start() should use. Is GFP_KERNEL OK? > > > > > > > > I hope I will not make this muddy again ;) > > > > invalidate_range_start in the blockable mode can use/depend on any > > > > sleepable > > > > allocation allowed in the context it is called from. > > > > > > 'in the context is is called from' is the magic phrase, as > > > invalidate_range_start is called while holding several different mm > > > related locks. I know at least write mmap_sem and i_mmap_rwsem > > > (write?) > > > > > > Can GFP_KERNEL be called while holding those locks? > > > > i_mmap_rwsem would be problematic because it is taken during the > > reclaim. > > Okay.. So the fs_reclaim debugging does catch errors. I do not think fs_reclaim is the udnerlying mechanism to catch this deadlock. It is a simple AA deadlock. You take i_mmap_rwsem and then go down the allocation path, direct reclaim and take the lock again. Nothing really surprising. fs_reclaim is really to catch GFP_NOFS context calling into a less restricted (e.g. GFP_KERNEL allocation context). > Do you have any > reference for what a false positive looks like? I believe I have given some examples when introducing __GFP_NOLOCKDEP. > I would like to inject it into the notifier path as this is very > difficult for driver authors to discover and know about, but I'm > worried about your false positive remark. > > I think I understand we can use only GFP_ATOMIC in the notifiers, but > we need a strategy to handle OOM to guarentee forward progress. Your example is from the notifier registration IIUC. Can you pre-allocate before taking locks? Could you point me to some examples when the allocation is necessary in the range notifier callback? -- Michal Hocko SUSE Labs
Re: linux-next: build warning after merge of the drm-misc tree
On Fri, Aug 16, 2019 at 12:47:15PM +0300, Laurent Pinchart wrote:
> On Fri, Aug 16, 2019 at 08:23:54AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 16, 2019 at 6:48 AM Sam Ravnborg wrote:
> > > > Hi all,
> > > >
> > > > After merging the drm-misc tree, today's linux-next build (x86_64
> > > > allmodconfig) produced this warning:
> > > >
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.ko
> > > > drivers/gpu/drm/panel/panel-nec-nl8048hl11.ko
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.ko
> > > > drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.ko
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.ko
> > > > drivers/gpu/drm/panel/panel-sony-acx565akm.ko
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.ko
> > > > drivers/gpu/drm/panel/panel-tpo-td028ttec1.ko
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.ko
> > > > drivers/gpu/drm/panel/panel-tpo-td043mtea1.ko
> > > >
> > > > Introduced by commits
> > > >
> > > > df439abe6501 ("drm/panel: Add driver for the NEC NL8048HL11 panel")
> > > > c9cf4c2a3bd3 ("drm/panel: Add driver for the Sharp LS037V7DW01 panel")
> > > > 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
> > > > 415b8dd08711 ("drm/panel: Add driver for the Toppoly TD028TTEC1
> > > > panel")
> > > > dc2e1e5b2799 ("drm/panel: Add driver for the Toppoly TD043MTEA1
> > > > panel")
> > >
> > > Ups, had not seen this one coming.
> > > We are in the process of removing the drivers in
> > > drivers/video/fbdev/omap2/omapfb/
> > > and decided to introduce the new drivers early to get them out of a
> > > longer patch series.
>
> Oops :-(
>
> The new drivers were initially part of a patch series that removed the
> duplicated drivers. The new drivers then got fast-tracked, and I didn't
> notice this issue.
>
> > Should we have a config dependency to not allow the old fbdev omap
> > when the drm omap driver is enabled? I think that would take care of
> > all this.
> >
> > Or too annoying for development?
> >
> > Also note that fbdev is in drm-misc now, so we should be able to fix
> > this all without cross-tree conflicts.
>
> Note that drivers/video/fbdev/omap2/omapfb/ will stay, it's
> drivers/gpu/drm/omapdrm/displays/ that is being removed. FB_OMAP2
> already depends on DRM_OMAP = n, I propose doing something similar at
> the level of the individual display drivers.
I've just posted "[PATCH 0/2] Fix module name clash with omapdrm and DRM
panel modules" that should solve this issue.
--
Regards,
Laurent Pinchart
[PATCH 0/2] Fix module name clash with omapdrm and DRM panel modules
Hello, The patch series "[PATCH v4 0/9] DRM panel drivers for omapdrm" added new DRM panel drivers for a set of panels used on OMAP platforms, with the omapdrm and omapfb2 drivers. Both those drivers contain omap-specific panel drivers, which the new DRM panel drivers aims to replace for omapdrm. The new drivers use the same module name as the old ones (with one exception), resulting in module name clashes. This needs to be fixed separately for omapfb2 and omapdrm. For omapfb2, we can disable the omapfb2-specific panel drivers in Kconfig when the standard drivers are enabled. As omapfb2 and omapdrm are mutually exclusive, the DRM panel drivers are not useful with omapfb2 in any case. This is done in patch 1/2. For omapdrm, we can simply drop the omapdrm-specific panel drivers, as the new drivers replace them. This is done in patch 2/2, which was already part of the larger omapdrm patch series "[PATCH 00/60] drm/omap: Replace custom display drivers with drm_bridge and drm_panel". Laurent Pinchart (2): video: omapfb2: Make standard and custom panel drivers mutually exclusive drm/omap: displays: Remove unused panel drivers drivers/gpu/drm/omapdrm/displays/Kconfig | 38 - drivers/gpu/drm/omapdrm/displays/Makefile | 6 - .../displays/panel-lgphilips-lb035q02.c | 251 -- .../omapdrm/displays/panel-nec-nl8048hl11.c | 271 --- .../displays/panel-sharp-ls037v7dw01.c| 262 -- .../omapdrm/displays/panel-sony-acx565akm.c | 755 -- .../omapdrm/displays/panel-tpo-td028ttec1.c | 390 - .../omapdrm/displays/panel-tpo-td043mtea1.c | 513 .../gpu/drm/omapdrm/dss/omapdss-boot-init.c | 7 - .../video/fbdev/omap2/omapfb/displays/Kconfig | 5 + 10 files changed, 5 insertions(+), 2493 deletions(-) delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] video: omapfb2: Make standard and custom panel drivers mutually exclusive
Standard DRM panel drivers for several panels used by omapfb2 are now available. Their module name clashes with the modules from drivers/gpu/drm/omapdrm/displays/, part of the deprecated omapfb2 fbdev driver. As omapfb2 can only be compiled when the omapdrm driver is disabled, and the DRM panel drivers are useless in that case, make the omapfb2 panels depend on the standard DRM panels being disabled to fix the name clash. Signed-off-by: Laurent Pinchart --- drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig index 8c1c5a4cfe18..744416dc530e 100644 --- a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig +++ b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig @@ -49,6 +49,7 @@ config FB_OMAP2_PANEL_DSI_CM config FB_OMAP2_PANEL_SONY_ACX565AKM tristate "ACX565AKM Panel" depends on SPI && BACKLIGHT_CLASS_DEVICE + depends on DRM_PANEL_SONY_ACX565AKM = n help This is the LCD panel used on Nokia N900 @@ -61,18 +62,21 @@ config FB_OMAP2_PANEL_LGPHILIPS_LB035Q02 config FB_OMAP2_PANEL_SHARP_LS037V7DW01 tristate "Sharp LS037V7DW01 LCD Panel" depends on BACKLIGHT_CLASS_DEVICE + depends on DRM_PANEL_SHARP_LS037V7DW01 = n help LCD Panel used in TI's SDP3430 and EVM boards config FB_OMAP2_PANEL_TPO_TD028TTEC1 tristate "TPO TD028TTEC1 LCD Panel" depends on SPI + depends on DRM_PANEL_TPO_TD028TTEC1 = n help LCD panel used in Openmoko. config FB_OMAP2_PANEL_TPO_TD043MTEA1 tristate "TPO TD043MTEA1 LCD Panel" depends on SPI + depends on DRM_PANEL_TPO_TD043MTEA1 = n help LCD Panel used in OMAP3 Pandora @@ -80,6 +84,7 @@ config FB_OMAP2_PANEL_NEC_NL8048HL11 tristate "NEC NL8048HL11 Panel" depends on SPI depends on BACKLIGHT_CLASS_DEVICE + depends on DRM_PANEL_NEC_NL8048HL11 = n help This NEC NL8048HL11 panel is TFT LCD used in the Zoom2/3/3630 sdp boards. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/omap: displays: Remove unused panel drivers
drm_panel-based drivers for the ACX565AKM, LB035Q02, LS037V7DW01,
NL8048HL11, TD028TTEC1 and TD043MTEA1 are available, remove the
omapdrm-specific drivers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/Kconfig | 38 -
drivers/gpu/drm/omapdrm/displays/Makefile | 6 -
.../displays/panel-lgphilips-lb035q02.c | 251 --
.../omapdrm/displays/panel-nec-nl8048hl11.c | 271 ---
.../displays/panel-sharp-ls037v7dw01.c| 262 --
.../omapdrm/displays/panel-sony-acx565akm.c | 755 --
.../omapdrm/displays/panel-tpo-td028ttec1.c | 390 -
.../omapdrm/displays/panel-tpo-td043mtea1.c | 513
.../gpu/drm/omapdrm/dss/omapdss-boot-init.c | 7 -
9 files changed, 2493 deletions(-)
delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c
diff --git a/drivers/gpu/drm/omapdrm/displays/Kconfig
b/drivers/gpu/drm/omapdrm/displays/Kconfig
index c2566da32ac4..240dda102845 100644
--- a/drivers/gpu/drm/omapdrm/displays/Kconfig
+++ b/drivers/gpu/drm/omapdrm/displays/Kconfig
@@ -29,42 +29,4 @@ config DRM_OMAP_PANEL_DSI_CM
help
Driver for generic DSI command mode panels.
-config DRM_OMAP_PANEL_SONY_ACX565AKM
- tristate "ACX565AKM Panel"
- depends on SPI && BACKLIGHT_CLASS_DEVICE
- help
- This is the LCD panel used on Nokia N900
-
-config DRM_OMAP_PANEL_LGPHILIPS_LB035Q02
- tristate "LG.Philips LB035Q02 LCD Panel"
- depends on SPI
- help
- LCD Panel used on the Gumstix Overo Palo35
-
-config DRM_OMAP_PANEL_SHARP_LS037V7DW01
-tristate "Sharp LS037V7DW01 LCD Panel"
-depends on BACKLIGHT_CLASS_DEVICE
-help
- LCD Panel used in TI's SDP3430 and EVM boards
-
-config DRM_OMAP_PANEL_TPO_TD028TTEC1
-tristate "TPO TD028TTEC1 LCD Panel"
-depends on SPI
-help
- LCD panel used in Openmoko.
-
-config DRM_OMAP_PANEL_TPO_TD043MTEA1
-tristate "TPO TD043MTEA1 LCD Panel"
-depends on SPI
-help
- LCD Panel used in OMAP3 Pandora
-
-config DRM_OMAP_PANEL_NEC_NL8048HL11
- tristate "NEC NL8048HL11 Panel"
- depends on SPI
- depends on BACKLIGHT_CLASS_DEVICE
- help
- This NEC NL8048HL11 panel is TFT LCD used in the
- Zoom2/3/3630 sdp boards.
-
endmenu
diff --git a/drivers/gpu/drm/omapdrm/displays/Makefile
b/drivers/gpu/drm/omapdrm/displays/Makefile
index 1db34d4fed64..cb76859dc574 100644
--- a/drivers/gpu/drm/omapdrm/displays/Makefile
+++ b/drivers/gpu/drm/omapdrm/displays/Makefile
@@ -4,9 +4,3 @@ obj-$(CONFIG_DRM_OMAP_ENCODER_TPD12S015) += encoder-tpd12s015.o
obj-$(CONFIG_DRM_OMAP_CONNECTOR_HDMI) += connector-hdmi.o
obj-$(CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV) += connector-analog-tv.o
obj-$(CONFIG_DRM_OMAP_PANEL_DSI_CM) += panel-dsi-cm.o
-obj-$(CONFIG_DRM_OMAP_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
-obj-$(CONFIG_DRM_OMAP_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
-obj-$(CONFIG_DRM_OMAP_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
-obj-$(CONFIG_DRM_OMAP_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
-obj-$(CONFIG_DRM_OMAP_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
-obj-$(CONFIG_DRM_OMAP_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
deleted file mode 100644
index 1fd0d84e6e38..
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ /dev/null
@@ -1,251 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * LG.Philips LB035Q02 LCD Panel driver
- *
- * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
- * Author: Tomi Valkeinen
- * Based on a driver by: Steve Sakoman
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "../dss/omapdss.h"
-
-static const struct videomode lb035q02_vm = {
- .hactive = 320,
- .vactive = 240,
-
- .pixelclock = 650,
-
- .hsync_len = 2,
- .hfront_porch = 20,
- .hback_porch= 68,
-
- .vsync_len = 2,
- .vfront_porch = 4,
- .vback_porch= 18,
-
- .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
-};
-
-struct panel_drv_data {
- struct omap_dss_device dssdev;
-
- struct spi_device *spi;
-
- struct videomode vm;
-
- struct gpio_desc *enable_gpio;
-};
-
-#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
-
-static int
Re: [PATCH 2/5] kernel.h: Add non_block_start/end()
On Fri, Aug 16, 2019 at 10:10:29AM +0200, Michal Hocko wrote: > On Thu 15-08-19 17:13:23, Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 09:35:26PM +0200, Michal Hocko wrote: > > > > > > The last detail is I'm still unclear what a GFP flags a blockable > > > > invalidate_range_start() should use. Is GFP_KERNEL OK? > > > > > > I hope I will not make this muddy again ;) > > > invalidate_range_start in the blockable mode can use/depend on any > > > sleepable > > > allocation allowed in the context it is called from. > > > > 'in the context is is called from' is the magic phrase, as > > invalidate_range_start is called while holding several different mm > > related locks. I know at least write mmap_sem and i_mmap_rwsem > > (write?) > > > > Can GFP_KERNEL be called while holding those locks? > > i_mmap_rwsem would be problematic because it is taken during the > reclaim. Okay.. So the fs_reclaim debugging does catch errors. Do you have any reference for what a false positive looks like? I would like to inject it into the notifier path as this is very difficult for driver authors to discover and know about, but I'm worried about your false positive remark. I think I understand we can use only GFP_ATOMIC in the notifiers, but we need a strategy to handle OOM to guarentee forward progress. This is just more bugs to fix :( Jason
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Fri, Aug 16, 2019 at 08:20:55AM +0200, Daniel Vetter wrote: > On Fri, Aug 16, 2019 at 3:00 AM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 10:49:31PM +0200, Daniel Vetter wrote: > > > On Thu, Aug 15, 2019 at 10:27 PM Jason Gunthorpe wrote: > > > > On Thu, Aug 15, 2019 at 10:16:43PM +0200, Daniel Vetter wrote: > > > > > So if someone can explain to me how that works with lockdep I can of > > > > > course implement it. But afaics that doesn't exist (I tried to explain > > > > > that somewhere else already), and I'm no really looking forward to > > > > > hacking also on lockdep for this little series. > > > > > > > > Hmm, kind of looks like it is done by calling preempt_disable() > > > > > > Yup. That was v1, then came the suggestion that disabling preemption > > > is maybe not the best thing (the oom reaper could still run for a long > > > time comparatively, if it's cleaning out gigabytes of process memory > > > or what not, hence this dedicated debug infrastructure). > > > > Oh, I'm coming in late, sorry > > > > Anyhow, I was thinking since we agreed this can trigger on some > > CONFIG_DEBUG flag, something like > > > > /* This is a sleepable region, but use preempt_disable to get debugging > > * for calls that are not allowed to block for OOM [.. insert > > * Michal's explanation.. ] */ > > if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP) && > > !mmu_notifier_range_blockable(range)) > > preempt_disable(); > > ops->invalidate_range_start(); > > I think we also discussed that, and some expressed concerns it would > change behaviour/timing too much for testing. Since this does does > disable preemption for real, not just for might_sleep. I don't follow, this is a debug kernel, it will have widly different timing. Further the point of this debugging on atomic_sleep is to be as timing-independent as possible since functions with rare sleeps should be guarded by might_sleep() in their common paths. I guess I don't get the push to have some low overhead debugging for this? Is there something special you are looking for? Jason
Re: [PULL] drm-misc-next
Quoting Maxime Ripard (2019-08-16 12:32:01) > Hi Daniel, Dave, > > Here's this week drm-misc-next PR. > > Maxime > > drm-misc-next-2019-08-16: > drm-misc-next for 5.4: > > UAPI Changes: > > Cross-subsystem Changes: > > Core Changes: > - dma-buf: add reservation_object_fences helper, relax > reservation_object_add_shared_fence, remove > reservation_object seq number I just undid these. Probably better to respin without the headline feature being immediately reverted :) -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Daniel, Dave, Here's this week drm-misc-next PR. Maxime drm-misc-next-2019-08-16: drm-misc-next for 5.4: UAPI Changes: Cross-subsystem Changes: Core Changes: - dma-buf: add reservation_object_fences helper, relax reservation_object_add_shared_fence, remove reservation_object seq number Driver Changes: - More dt-bindings YAML conversions - More removal of drmP.h includes - dw-hdmi: Support get_eld and various i2s improvements - gm12u320: Few fixes - meson: Global cleanup - panfrost: Few refactors, Support for GPU heap allocations - sun4i: Support for DDC enable GPIO - New panels: TI nspire, NEC NL8048HL11, LG Philips LB035Q02, Sharp LS037V7DW01, Sony ACX565AKM, Toppoly TD028TTEC1 Toppoly TD043MTEA1 The following changes since commit cc8f12996e24b102a086a253055ecc58c437c31d: drm/rockchip: fix VOP_WIN_GET macro (2019-08-08 00:23:15 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-08-16 for you to fetch changes up to dc2e1e5b279966affbd11ff7cfef52eb634ca2c9: drm/panel: Add driver for the Toppoly TD043MTEA1 panel (2019-08-14 22:23:11 +0200) drm-misc-next for 5.4: UAPI Changes: Cross-subsystem Changes: Core Changes: - dma-buf: add reservation_object_fences helper, relax reservation_object_add_shared_fence, remove reservation_object seq number Driver Changes: - More dt-bindings YAML conversions - More removal of drmP.h includes - dw-hdmi: Support get_eld and various i2s improvements - gm12u320: Few fixes - meson: Global cleanup - panfrost: Few refactors, Support for GPU heap allocations - sun4i: Support for DDC enable GPIO - New panels: TI nspire, NEC NL8048HL11, LG Philips LB035Q02, Sharp LS037V7DW01, Sony ACX565AKM, Toppoly TD028TTEC1 Toppoly TD043MTEA1 Chris Wilson (3): dma-fence: Propagate errors to dma-fence-array container dma-fence: Report the composite sync_file status dma-buf/sw_sync: Synchronize signal vs syncpt free Christian König (6): dma-buf: make dma_fence structure a bit smaller v2 dma-buf: add reservation_object_fences helper drm/i915: use new reservation_object_fences helper dma-buf: further relax reservation_object_add_shared_fence dma-buf: nuke reservation_object seq number dma-buf: rename reservation_object to dma_resv Geert Uytterhoeven (1): drm/bridge: dumb-vga-dac: Fix dereferencing -ENODEV DDC channel Gustavo A. R. Silva (1): drm/komeda: Fix potential integer overflow in komeda_crtc_update_clock_ratio Hans de Goede (4): drm: gm12u320: Some minor cleanups drm: gm12u320: Use DRM_DEV_ERROR everywhere drm: gm12u320: Do not take a mutex from a wait_event condition drm: gm12u320: Add -ENODEV to list of errors to ignore Jason Ekstrand (1): drm/syncobj: Add better overview documentation for syncobj (v2) Jerome Brunet (8): drm/bridge: dw-hdmi-i2s: support more i2s format drm/bridge: dw-hdmi: move audio channel setup out of ahb drm/bridge: dw-hdmi: set channel count in the infoframes drm/bridge: dw-hdmi-i2s: enable lpcm multi channels drm/bridge: dw-hdmi-i2s: set the channel allocation drm/bridge: dw-hdmi-i2s: reset audio fifo before applying new params drm/bridge: dw-hdmi-i2s: enable only the required i2s lanes drm/bridge: dw-hdmi-i2s: add .get_eld support Julien Masson (9): drm: meson: mask value when writing bits relaxed drm: meson: crtc: use proper macros instead of magic constants drm: meson: drv: use macro when initializing vpu drm: meson: vpp: use proper macros instead of magic constants drm: meson: viu: use proper macros instead of magic constants drm: meson: venc: use proper macros instead of magic constants drm: meson: global clean-up drm: meson: add macro used to enable HDMI PLL drm: meson: venc: set the correct macrovision max amplitude value Laurent Pinchart (9): dt-bindings: Add vendor prefix for LG Display dt-bindings: Add legacy 'toppoly' vendor prefix dt-bindings: display: panel: Add bindings for NEC NL8048HL11 panel drm/panel: Add driver for the LG Philips LB035Q02 panel drm/panel: Add driver for the NEC NL8048HL11 panel drm/panel: Add driver for the Sharp LS037V7DW01 panel drm/panel: Add driver for the Sony ACX565AKM panel drm/panel: Add driver for the Toppoly TD028TTEC1 panel drm/panel: Add driver for the Toppoly TD043MTEA1 panel Linus Walleij (3): drm/pl111: Support grayscale drm/panel: simple: Add TI nspire panel bindings drm/panel: simple: Support TI nspire panels Neil Armstrong (3): dt-bindings: display: amlogic, meson-dw-hdm
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #104 from Tom B --- I did get very similar crashing when I was running HDMI + DP at different refresh rates ( see https://bugs.freedesktop.org/show_bug.cgi?id=110510 ). I switched to DP + DP because HDMI+DP wasn't stable, it could be related. the tl;dir from that bug report, and this was on 5.0.9: - HDMI alone at 60hz works but the screen flickers off every 3-5 minutes - HDMI alone works at 59.9hz without any flickering - HDMI 60hz + DP 60hz works, but the HDMI screen flickers off every 3-5 minutes - HDMI 59.94hz + DP 60hz freezes the PC instantly. Unfortunately my monitors don't support displayport at 59.94hz so I couldn't test that combination as I think it would have worked. Still, it does tell us that these could be related and the issue could be syncing between the two displays. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #103 from Peter Hercek --- I boot in BIOS mode and I'm still getting these errors. Though they are rare in my case with the "better" kernels (around once a week). Just a note: There were tearing errors in windows drivers of Radeon VII too. One of the reasons for it was different refresh rate for different monitors. They recommended to set all refresh rates to 60 Hz or its multiple till it is fixed. In my case it is not completely possible (one monitor supports 60 Hz, but other two monitors support only 59.95 Hz). I have slight difference in the frequencies. -- 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
[v3 2/2] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500
Configure the display Quality of service (QoS) levels priority if the
optional property node "arm,malidp-aqros-value" is defined in DTS file.
QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS is
driven from the "RQOS" register, so needed to program the RQOS register
to avoid the high resolutions flicker issue on the LS1028A platform.
Signed-off-by: Wen He
---
change in v3:
- after testing more resolutions, if pixelclock > 148.5MHz will
get the flickering
drivers/gpu/drm/arm/malidp_drv.c | 6 ++
drivers/gpu/drm/arm/malidp_hw.c | 13 +
drivers/gpu/drm/arm/malidp_hw.h | 3 +++
drivers/gpu/drm/arm/malidp_regs.h | 10 ++
4 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index c27ff456eddc..80e8d15760ac 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -815,6 +815,12 @@ static int malidp_bind(struct device *dev)
malidp->core_id = version;
+ ret = of_property_read_u32(dev->of_node,
+ "arm,malidp-arqos-value",
+ &hwdev->arqos_value);
+ if (ret)
+ hwdev->arqos_value = 0x0;
+
/* set the number of lines used for output of RGB data */
ret = of_property_read_u8_array(dev->of_node,
"arm,malidp-output-port-lines",
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 380be66d4c6e..f90a367a5bc9 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -374,6 +374,19 @@ static void malidp500_modeset(struct malidp_hw_device
*hwdev, struct videomode *
malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
else
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
+
+ /*
+* Program the RQoS register to avoid high resolutions flicker
+* issue on the LS1028A.
+*/
+ if (hwdev->arqos_value) {
+ val = hwdev->arqos_value;
+
+ if (mode->pixelclock > 14850)
+ malidp_hw_setbits(hwdev, val, MALIDP500_RQOS_QUALITY);
+ else
+ malidp_hw_clearbits(hwdev, val, MALIDP500_RQOS_QUALITY);
+ }
}
int malidp_format_get_bpp(u32 fmt)
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 968a65eed371..e4c36bc90bda 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -251,6 +251,9 @@ struct malidp_hw_device {
/* size of memory used for rotating layers, up to two banks available */
u32 rotation_memory[2];
+
+ /* priority level of RQOS register used for driven the ARQOS signal */
+ u32 arqos_value;
};
static inline u32 malidp_hw_read(struct malidp_hw_device *hwdev, u32 reg)
diff --git a/drivers/gpu/drm/arm/malidp_regs.h
b/drivers/gpu/drm/arm/malidp_regs.h
index 993031542fa1..514c50dcb74d 100644
--- a/drivers/gpu/drm/arm/malidp_regs.h
+++ b/drivers/gpu/drm/arm/malidp_regs.h
@@ -210,6 +210,16 @@
#define MALIDP500_CONFIG_VALID 0x00f00
#define MALIDP500_CONFIG_ID0x00fd4
+/*
+ * The quality of service (QoS) register on the DP500. RQOS register values
+ * are driven by the ARQOS signal, using AXI transacations, dependent on the
+ * FIFO input level.
+ * The RQOS register can also set QoS levels for:
+ *- RED_ARQOS @ A 4-bit signal value for close to underflow conditions
+ *- GREEN_ARQOS @ A 4-bit signal value for normal conditions
+ */
+#define MALIDP500_RQOS_QUALITY 0x00500
+
/* register offsets and bits specific to DP550/DP650 */
#define MALIDP550_ADDR_SPACE_SIZE 0x1
#define MALIDP550_DE_CONTROL 0x00010
--
2.17.1
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #102 from Tom B --- > Grasping at straws a bit here, but it occurred to me that maybe Linux kernel > testing on Radeon VII was done on an early VBIOS that didn't have full UEFI > support yet. We know that AMD had to issue a VBIOS update for Radeon VII to > fix UEFI support shortly after the launch. So maybe enabling the CSM/Legacy > Support in the BIOS, which does impact early GPU initialization, might have > some effect on the multimonitor problem? Something I plan to test, but I > wanted to share the idea in case someone else has a chance first. I had already tried that unfortunately, I tried the following BIOS options: CSM on/off IOMMU on/of PCIE speed 16x/4x (the only options my motherboard allowed for some reason) Having said that, I didn't try booting using grub in BIOS mode as I didn't want to change my partition table, so it's possible that although I had used CSM, it was only legacy support and still booting in UEFI mode. -- 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: Linux Kernel 5.2.8 (uvc or i915? <<<)
Hi Randy, On Thu, Aug 15, 2019 at 08:10:03PM -0700, Randy Dunlap wrote: > [adding mailing lists etc. with Nathaniel's test info] > > On 8/15/19 7:21 PM, Nathaniel Russell wrote: > > Well i surpressed the uvcvideo driver and you are right Randy it > > definitely is not the uvcvideo driver. There is something going on in > > the i915 driver. > > > > On 8/15/19, Randy Dunlap wrote: > >> On 8/15/19 6:15 PM, Nathaniel Russell wrote: > >>> I would really like help with the kernel error with my uvcvideo driver. > >> > >> Hi again. > >> > >> What makes you think that the problem is related to the uvcvideo driver? > >> Does some previous kernel version work correctly? If so, what version(s)? > >> > >> > >> Does this warning message only happen when the uvcvideo driver is being > >> loaded? > >> Can you suppress loading of the uvcvideo driver to find out? > >> > >> Most of the problems/errors/warnings that I see are related to the i915 > >> driver: > >> > >> [ 13.032341] timed out waiting for port C ready: got 0x20, expected 0xe0 > >> [ 13.032872] WARNING: CPU: 1 PID: 239 at > >> drivers/gpu/drm/i915/intel_display.c:1597 vlv_wait_port_ready+0x99/0xe0 > >> [i915] > >> [ 13.033632] RIP: 0010:vlv_wait_port_ready+0x99/0xe0 [i915] > >> > >> although there are a few uvcvideo warnings: > >> [ 13.039305] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not > >> initialized! > >> [ 13.039318] uvcvideo 1-5:1.0: Entity type for entity Extension 3 was not > >> initialized! > >> [ 13.039330] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was > >> not > >> initialized! > >> [ 13.039339] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not > >> initialized! > >> > >> Laurent, do you see any uvc issues here? Any ideas/suggestions? No, uvcvideo seems completely reunlated. > >> @intel-gfx: any ideas about what is going on here with the i915 driver? > >> > >> Original message to lkml: > >> https://lore.kernel.org/lkml/CAONH+Jm-O6=dq+k2n5pntnmg2sq1kcvnfluwevh6w82opef...@mail.gmail.com/T/#u > >> > >> Previous message for 5.1.21 kernel: > >> https://lore.kernel.org/lkml/CAONH+JkTFujY9vEyNNuem+9rJ2qBKkf-PbKk9=DBSVEp6kW=y...@mail.gmail.com/ -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build warning after merge of the drm-misc tree
Hello,
On Fri, Aug 16, 2019 at 08:23:54AM +0200, Daniel Vetter wrote:
> On Fri, Aug 16, 2019 at 6:48 AM Sam Ravnborg wrote:
> > > Hi all,
> > >
> > > After merging the drm-misc tree, today's linux-next build (x86_64
> > > allmodconfig) produced this warning:
> > >
> > > warning: same module names found:
> > > drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.ko
> > > drivers/gpu/drm/panel/panel-nec-nl8048hl11.ko
> > > warning: same module names found:
> > > drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.ko
> > > drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.ko
> > > warning: same module names found:
> > > drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.ko
> > > drivers/gpu/drm/panel/panel-sony-acx565akm.ko
> > > warning: same module names found:
> > > drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.ko
> > > drivers/gpu/drm/panel/panel-tpo-td028ttec1.ko
> > > warning: same module names found:
> > > drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.ko
> > > drivers/gpu/drm/panel/panel-tpo-td043mtea1.ko
> > >
> > > Introduced by commits
> > >
> > > df439abe6501 ("drm/panel: Add driver for the NEC NL8048HL11 panel")
> > > c9cf4c2a3bd3 ("drm/panel: Add driver for the Sharp LS037V7DW01 panel")
> > > 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
> > > 415b8dd08711 ("drm/panel: Add driver for the Toppoly TD028TTEC1 panel")
> > > dc2e1e5b2799 ("drm/panel: Add driver for the Toppoly TD043MTEA1 panel")
> >
> > Ups, had not seen this one coming.
> > We are in the process of removing the drivers in
> > drivers/video/fbdev/omap2/omapfb/
> > and decided to introduce the new drivers early to get them out of a
> > longer patch series.
Oops :-(
The new drivers were initially part of a patch series that removed the
duplicated drivers. The new drivers then got fast-tracked, and I didn't
notice this issue.
> Should we have a config dependency to not allow the old fbdev omap
> when the drm omap driver is enabled? I think that would take care of
> all this.
>
> Or too annoying for development?
>
> Also note that fbdev is in drm-misc now, so we should be able to fix
> this all without cross-tree conflicts.
Note that drivers/video/fbdev/omap2/omapfb/ will stay, it's
drivers/gpu/drm/omapdrm/displays/ that is being removed. FB_OMAP2
already depends on DRM_OMAP = n, I propose doing something similar at
the level of the individual display drivers.
--
Regards,
Laurent Pinchart
[PATCH] drm/panfrost: Remove opp table when unloading
The devfreq opp table needs to be removed when unloading the driver to
free the memory associated with it.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 6 ++
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 1 +
drivers/gpu/drm/panfrost/panfrost_drv.c | 5 -
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 77e1ad24de53..710d903f8e0d 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -160,12 +160,18 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
DRM_DEV_ERROR(&pfdev->pdev->dev, "Couldn't initialize GPU
devfreq\n");
ret = PTR_ERR(pfdev->devfreq.devfreq);
pfdev->devfreq.devfreq = NULL;
+ dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
return ret;
}
return 0;
}
+void panfrost_devfreq_fini(struct panfrost_device *pfdev)
+{
+ dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
+}
+
void panfrost_devfreq_resume(struct panfrost_device *pfdev)
{
int i;
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index eb999531ed90..e3bc63e82843 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -5,6 +5,7 @@
#define __PANFROST_DEVFREQ_H__
int panfrost_devfreq_init(struct panfrost_device *pfdev);
+void panfrost_devfreq_fini(struct panfrost_device *pfdev);
void panfrost_devfreq_resume(struct panfrost_device *pfdev);
void panfrost_devfreq_suspend(struct panfrost_device *pfdev);
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index ae70200be44a..44a558c6e17e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -547,12 +547,14 @@ static int panfrost_probe(struct platform_device *pdev)
*/
err = drm_dev_register(ddev, 0);
if (err < 0)
- goto err_out1;
+ goto err_out2;
panfrost_gem_shrinker_init(ddev);
return 0;
+err_out2:
+ panfrost_devfreq_fini(pfdev);
err_out1:
panfrost_device_fini(pfdev);
err_out0:
@@ -571,6 +573,7 @@ static int panfrost_remove(struct platform_device *pdev)
pm_runtime_get_sync(pfdev->dev);
pm_runtime_put_sync_autosuspend(pfdev->dev);
pm_runtime_disable(pfdev->dev);
+ panfrost_devfreq_fini(pfdev);
panfrost_device_fini(pfdev);
drm_dev_put(ddev);
return 0;
--
2.20.1
[PATCH] drm/panfrost: Queue jobs on the hardware
The hardware has a set of '_NEXT' registers that can hold a second job
while the first is executing. Make use of these registers to enqueue a
second job per slot.
Signed-off-by: Steven Price
---
Note that this is based on top of Rob Herring's "per FD address space"
patch[1].
[1] https://marc.info/?i=20190813150115.30338-1-robh%20()%20kernel%20!%20org
drivers/gpu/drm/panfrost/panfrost_device.h | 4 +-
drivers/gpu/drm/panfrost/panfrost_job.c| 76 ++
drivers/gpu/drm/panfrost/panfrost_mmu.c| 2 +-
3 files changed, 67 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index f503c566e99f..0153defd6085 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -55,7 +55,7 @@ struct panfrost_devfreq_slot {
ktime_t busy_time;
ktime_t idle_time;
ktime_t time_last_update;
- bool busy;
+ int busy;
};
struct panfrost_device {
@@ -80,7 +80,7 @@ struct panfrost_device {
struct panfrost_job_slot *js;
- struct panfrost_job *jobs[NUM_JOB_SLOTS];
+ struct panfrost_job *jobs[NUM_JOB_SLOTS][2];
struct list_head scheduled_jobs;
struct panfrost_perfcnt *perfcnt;
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 05c85f45a0de..b2b5027af976 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -138,6 +138,37 @@ static void panfrost_job_write_affinity(struct
panfrost_device *pfdev,
job_write(pfdev, JS_AFFINITY_NEXT_HI(js), affinity >> 32);
}
+static int panfrost_job_count(struct panfrost_device *pfdev, int slot)
+{
+ if (pfdev->jobs[slot][0] == NULL)
+ return 0;
+ if (pfdev->jobs[slot][1] == NULL)
+ return 1;
+ return 2;
+}
+
+static struct panfrost_job *panfrost_dequeue_job(
+ struct panfrost_device *pfdev, int slot)
+{
+ struct panfrost_job *job = pfdev->jobs[slot][0];
+
+ pfdev->jobs[slot][0] = pfdev->jobs[slot][1];
+ pfdev->jobs[slot][1] = NULL;
+
+ return job;
+}
+
+static void panfrost_enqueue_job(struct panfrost_device *pfdev, int slot,
+struct panfrost_job *job)
+{
+ if (pfdev->jobs[slot][0] == NULL) {
+ pfdev->jobs[slot][0] = job;
+ return;
+ }
+ WARN_ON(pfdev->jobs[slot][1] != NULL);
+ pfdev->jobs[slot][1] = job;
+}
+
static void panfrost_job_hw_submit(struct panfrost_job *job, int js)
{
struct panfrost_device *pfdev = job->pfdev;
@@ -150,13 +181,16 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
if (ret < 0)
return;
- if (WARN_ON(job_read(pfdev, JS_COMMAND_NEXT(js
- goto end;
-
cfg = panfrost_mmu_as_get(pfdev, &job->file_priv->mmu);
- panfrost_devfreq_record_transition(pfdev, js);
spin_lock_irqsave(&pfdev->hwaccess_lock, flags);
+ panfrost_enqueue_job(pfdev, js, job);
+
+ if (WARN_ON(job_read(pfdev, JS_COMMAND_NEXT(js
+ goto end;
+
+ if (panfrost_job_count(pfdev, js) == 1)
+ panfrost_devfreq_record_transition(pfdev, js);
job_write(pfdev, JS_HEAD_NEXT_LO(js), jc_head & 0x);
job_write(pfdev, JS_HEAD_NEXT_HI(js), jc_head >> 32);
@@ -186,9 +220,9 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START);
+end:
spin_unlock_irqrestore(&pfdev->hwaccess_lock, flags);
-end:
pm_runtime_mark_last_busy(pfdev->dev);
pm_runtime_put_autosuspend(pfdev->dev);
}
@@ -336,8 +370,6 @@ static struct dma_fence *panfrost_job_run(struct
drm_sched_job *sched_job)
if (unlikely(job->base.s_fence->finished.error))
return NULL;
- pfdev->jobs[slot] = job;
-
fence = panfrost_fence_create(pfdev, slot);
if (IS_ERR(fence))
return NULL;
@@ -421,21 +453,36 @@ static irqreturn_t panfrost_job_irq_handler(int irq, void
*data)
struct panfrost_device *pfdev = data;
u32 status = job_read(pfdev, JOB_INT_STAT);
int j;
+ unsigned long flags;
dev_dbg(pfdev->dev, "jobslot irq status=%x\n", status);
if (!status)
return IRQ_NONE;
+ spin_lock_irqsave(&pfdev->hwaccess_lock, flags);
+
pm_runtime_mark_last_busy(pfdev->dev);
for (j = 0; status; j++) {
u32 mask = MK_JS_MASK(j);
+ int jobs = panfrost_job_count(pfdev, j);
+ int active;
if (!(status & mask))
continue;
job_write(pfdev, JOB_INT_CLEAR, mask);
+ active = (job_read(pfdev, JOB_INT_JS_STATE) &
+ JOB_INT_MASK_DONE(j))
[PATCH] drm/panfrost: Enable devfreq to work without regulator
If there is no regulator defined for the GPU then still control the
frequency using the supplied clock.
Some boards have clock control but no (direct) control of the regulator.
For example the HiKey960 uses a mailbox protocol to a MCU to control
frequencies and doesn't directly control the voltage. This patch allows
frequency control of the GPU on this system.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index a7c18bceb7fd..77e1ad24de53 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -39,7 +39,7 @@ static int panfrost_devfreq_target(struct device *dev,
unsigned long *freq,
* If frequency scaling from low to high, adjust voltage first.
* If frequency scaling from high to low, adjust frequency first.
*/
- if (old_clk_rate < target_rate) {
+ if (old_clk_rate < target_rate && pfdev->regulator) {
err = regulator_set_voltage(pfdev->regulator, target_volt,
target_volt);
if (err) {
@@ -58,7 +58,7 @@ static int panfrost_devfreq_target(struct device *dev,
unsigned long *freq,
return err;
}
- if (old_clk_rate > target_rate) {
+ if (old_clk_rate > target_rate && pfdev->regulator) {
err = regulator_set_voltage(pfdev->regulator, target_volt,
target_volt);
if (err)
@@ -136,9 +136,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
int ret;
struct dev_pm_opp *opp;
- if (!pfdev->regulator)
- return 0;
-
ret = dev_pm_opp_of_add_table(&pfdev->pdev->dev);
if (ret == -ENODEV) /* Optional, continue without devfreq */
return 0;
--
2.20.1
[GIT PULL] etnaviv-next for 5.4
Hi Daniel, Dave, after some pretty slow cycles we finally have a bit more exciting work ready for upstream. Most importantly per-process address spaces on GPUs that are capable of providing proper isolation has finished baking. This is the base for our softpin implementation, which allows us to support the texture descriptor buffers used by GC7000 series GPUs without a major UAPI extension/rework. Shortlog of notable changes: - code cleanup from Fabio - fix performance counters on GC880 and GC2000 GPUs from Christian - drmP.h header removal from Sam - per process address space support on MMUv2 GPUs from me - softpin support from me Regards, Lucas The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the Git repository at: https://git.pengutronix.de/git/lst/linux etnaviv/next for you to fetch changes up to 00ddc0b20086b71bb87b805fb63ff07c35f2: drm/etnaviv: implement softpin (2019-08-15 12:07:47 +0200) Christian Gmeiner (2): etnaviv: fix whitespace errors etnaviv: perfmon: fix total and idle HI cyleces readout Fabio Estevam (1): drm/etnaviv: Use devm_platform_ioremap_resource() Lucas Stach (16): drm/etnaviv: clean up includes drm/etnaviv: fix etnaviv_cmdbuf_suballoc_new return value drm/etnaviv: remove unused function etnaviv_gem_mapping_reference drm/etnaviv: dump only failing submit drm/etnaviv: pass mmu pointer to etnaviv_core_dump_mmu drm/etnaviv: simplify unbind checks drm/etnaviv: split out cmdbuf mapping into address space drm/etnaviv: share a single cmdbuf suballoc region across all GPUs drm/etnaviv: replace MMU flush marker with flush sequence drm/etnaviv: rework MMU handling drm/etnaviv: split out starting of FE idle loop drm/etnaviv: provide MMU context to etnaviv_gem_mapping_get drm/etnaviv: implement per-process address spaces on MMUv2 drm/etnaviv: skip command stream validation on PPAS capable GPUs drm/etnaviv: allow to request specific virtual address for gem mapping drm/etnaviv: implement softpin Sam Ravnborg (1): drm/etnaviv: drop use of drmP.h drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 93 ++ drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 58 + drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 15 ++- drivers/gpu/drm/etnaviv/etnaviv_drv.c| 68 -- drivers/gpu/drm/etnaviv/etnaviv_drv.h| 27 ++-- drivers/gpu/drm/etnaviv/etnaviv_dump.c | 65 -- drivers/gpu/drm/etnaviv/etnaviv_dump.h | 4 +- drivers/gpu/drm/etnaviv/etnaviv_gem.c| 56 drivers/gpu/drm/etnaviv/etnaviv_gem.h| 8 +- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 + drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 45 ++- drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 158 --- drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 11 +- drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 165 +++- drivers/gpu/drm/etnaviv/etnaviv_iommu.h | 20 --- drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 284 ++--- drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 326 --- drivers/gpu/drm/etnaviv/etnaviv_mmu.h| 114 - drivers/gpu/drm/etnaviv/etnaviv_perfmon.c| 48 +-- drivers/gpu/drm/etnaviv/etnaviv_sched.c | 4 +- include/uapi/drm/etnaviv_drm.h | 10 +- 21 files changed, 922 insertions(+), 659 deletions(-) delete mode 100644 drivers/gpu/drm/etnaviv/etnaviv_iommu.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109380] [CI][BAT] igt@kms_chamelium@*- warn/fail - Last errno: 113, No route to host
https://bugs.freedesktop.org/show_bug.cgi?id=109380 --- Comment #5 from Arek Hiler --- https://patchwork.freedesktop.org/patch/324290/ -- 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 -next] drm/panfrost: Fix missing unlock on error in panfrost_mmu_map_fault_addr()
On 14/08/2019 05:48, Wei Yongjun wrote:
> Add the missing unlock before return from function
> panfrost_mmu_map_fault_addr()
> in the error handling case.
>
> Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
> Signed-off-by: Wei Yongjun
Well spotted.
Reviewed-by: Steven Price
Steve
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> index 2ed411f09d80..06f1a563e940 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> @@ -327,14 +327,17 @@ int panfrost_mmu_map_fault_addr(struct panfrost_device
> *pfdev, int as, u64 addr)
> if (!bo->base.pages) {
> bo->sgts = kvmalloc_array(bo->base.base.size / SZ_2M,
>sizeof(struct sg_table), GFP_KERNEL |
> __GFP_ZERO);
> - if (!bo->sgts)
> + if (!bo->sgts) {
> + mutex_unlock(&bo->base.pages_lock);
> return -ENOMEM;
> + }
>
> pages = kvmalloc_array(bo->base.base.size >> PAGE_SHIFT,
> sizeof(struct page *), GFP_KERNEL |
> __GFP_ZERO);
> if (!pages) {
> kfree(bo->sgts);
> bo->sgts = NULL;
> + mutex_unlock(&bo->base.pages_lock);
> return -ENOMEM;
> }
> bo->base.pages = pages;
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu 15-08-19 22:16:43, Daniel Vetter wrote: > On Thu, Aug 15, 2019 at 9:35 PM Michal Hocko wrote: [...] > > > The last detail is I'm still unclear what a GFP flags a blockable > > > invalidate_range_start() should use. Is GFP_KERNEL OK? > > > > I hope I will not make this muddy again ;) > > invalidate_range_start in the blockable mode can use/depend on any sleepable > > allocation allowed in the context it is called from. So in other words > > it is no different from any other function in the kernel that calls into > > allocator. As the API is missing gfp context then I hope it is not > > called from any restricted contexts (except from the oom which we have > > !blockable for). > > Hm, that's new to me. I thought mmu notifiers very much can be called > from direct reclaim paths, so you have to be extremely careful with > getting back into that one. Correct, I should have added that notifier callbacks ideally do not allocate any memory. They can block and even that is quite a pain to be honest. -- Michal Hocko SUSE Labs
