Re: [PATCH V3 6/7] backlight: qcom-wled: add support for short circuit handling
On 19-06-18, 16:43, Kiran Gunda wrote:
> struct wled {
> const char *name;
> struct device *dev;
> struct regmap *regmap;
> + struct mutex lock; /* Lock to avoid race from ISR */
the comment is wrong as you avoid race with thread handler and not the
main ISR. The ISR runs in atomic context so you cant use a mutex but you
may do so with a thread handler
> +#define WLED_SHORT_DLY_MS20
> +#define WLED_SHORT_CNT_MAX 5
> +#define WLED_SHORT_RESET_CNT_DLY_US USEC_PER_SEC
an empty line after defines would be better
> +static int wled_configure_short_irq(struct wled *wled,
> + struct platform_device *pdev)
> +{
> + int rc = 0, short_irq;
superfluous initialization of rc
--
~Vinod
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] anv: Support wait for heterogeneous list of fences [v2]
Jason Ekstrand writes: > You can have a full reviewed-by You're too kind :-) -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] anv: add VK_EXT_display_control to anv driver [v2]
Jason Ekstrand writes: >> + if (allocator) >> + alloc = allocator; >> + else >> + alloc = >instance->alloc; >> > > This is what vk_alloc2 is for. :-) ... > And vk_free2 ... > This isn't needed if you're using vk_alloc2 Yeah, but I need to pass the allocator down to the wsi common code, and that doesn't have any way to touch the device driver allocator pointer. I bet I'm just missing something here. Help? >> + >> + fence = vk_zalloc2(>alloc, allocator, sizeof (*fence), 8, >> + VK_SYSTEM_ALLOCATION_SCOPE_OBJECT); >> > > Above you used vk_alloc and here you're using vk_zalloc. Mind picking > one? I don't think zalloc is needed but it doesn't hurt so I don't care > which. Thanks. Existing code is using zalloc for fences; I'll use that everywhere. > Indentation could be consistent between the two functions you add. I don't > care which style. Sure; these function names are kinda long. I've wrapped the first call after the ( > vk_free2? I've had to compute 'alloc' to pass into wsi_common; I figured I might as well use it. -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] anv: Support wait for heterogeneous list of fences [v2]
On June 19, 2018 22:16:37 "Keith Packard" wrote: Jason Ekstrand writes: I don't think I have any more comments on this patch. It's gross but I think it should work. I'll mark you down as 'Acked-by' then. Neither of us loves the implementation; I'll see about creating the kernel infrastructure necessary to supplant it. You can have a full reviewed-by ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/4] locking,drm: Fix ww mutex naming / algorithm inconsistency
On 06/19/2018 11:45 AM, Peter Zijlstra wrote: I suspect you want this through the DRM tree? Ingo are you OK with that? Yes, I can ask Dave to pull this. Ingo? Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] anv: Support wait for heterogeneous list of fences [v2]
Jason Ekstrand writes: > I don't think I have any more comments on this patch. It's gross but I > think it should work. I'll mark you down as 'Acked-by' then. Neither of us loves the implementation; I'll see about creating the kernel infrastructure necessary to supplant it. -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] vulkan: add VK_EXT_display_control [v5]
Jason Ekstrand writes:
>> + if (!prop)
>> + continue;
>> + if (prop->flags & DRM_MODE_PROP_ENUM) {
>> + if (!strcmp(prop->name, "DPMS"))
>> +connector->dpms_property = drm_connector->props[p];
>>
>
> break?
Not break; I need to free the property. However, an early exit from the
loop seems reasonable. How about:
for (int p = 0; connector->dpms_property == 0 && p <
drm_connector->count_props; p++) {
This skips the whole sequence if the property has already been found, or
stops as soon as it has.
>> +static bool
>> +wsi_display_fence_wait(struct wsi_fence *fence_wsi,
>> + bool absolute,
>> + uint64_t timeout)
>>
>
> Would it make more sense for this function to return a VkResult? Then you
> could tell the difference between success, timeout, and some other
> failure. I guess the only other thing to return would be
> VK_ERROR_DEVICE_LOST which seems pretty harsh but, then again,
> pthread_timed_wait just failed so that's also really bad.
That's a good idea. The boolean return is pretty ambiguous. I copied
that from the radv internal fence API, which could also benefit from
this change. I've changed the API and adjusted the anv and radv code to
match. It reads a lot better now.
>> + if (!absolute)
>> + timeout = wsi_rel_to_abs_time(timeout);
>>
>
> Are relative times really useful? I suspect it doesn't save you more than
> a couple of lines and it makes the interface weird.
No. Relative timeouts aren't actually used anywhere either. I've removed them.
I did catch a mistake in the anv driver looking at this -- the !waitAll
code wasn't bothering to check the fences if the time had already
passed, so an application polling would never catch the fences being
ready. I've changed the while (current_time < timeout) {} to a do {}
while (current_time < timeout) loop.
>> +static void
>> +wsi_display_fence_destroy(struct wsi_fence *fence_wsi)
>> +{
>> + struct wsi_display_fence *fence = (struct wsi_display_fence *)
>> fence_wsi;
>> +
>>
>
> An assert(!fence->destroyed) in here might be useful to guard against
> double-frees.
Sure. I was under the impression that application bugs weren't supposed
to be rigorously checked in the implementation though? When should I be
checking API usage issues?
>> + if (!ret)
>> + return VK_SUCCESS;
>> +
>> + if (errno != ENOMEM) {
>> + wsi_display_debug("queue vblank event %lu failed\n",
>> fence->sequence);
>> + struct timespec delay = {
>> +.tv_sec = 0,
>> +.tv_nsec = 1ull,
>> + };
>> + nanosleep(, NULL);
>> + return VK_ERROR_OUT_OF_HOST_MEMORY;
>>
>
> Why are we sleeping for 0.1s before we return? That seems fishy.
Yeah, the kernel API is not great. There's a finite queue which can be
consumed with both flip events and vblank wait events. If that fills,
we'll get an error back. The only way to empty it is to have some events
get delivered, and those will only get delivered after a vblank happens.
It's an application bug that triggers this -- requesting too many vblank
events. Throttling the application so it doesn't just spin makes it
possible to stop it.
>> + pthread_mutex_lock(>wait_mutex);
>> + ret = wsi_display_wait_for_event(wsi, wsi_rel_to_abs_time(
>> 1ull));
>>
>
> What's with the magic number?
0.1s -- a value which is longer than any display time, but short enough
to catch things like DPMS off or VT switch without unduly delaying the
application.
>> +VkResult
>> +wsi_register_device_event(VkDevice device,
>> + struct wsi_device *wsi_device,
>> + const VkDeviceEventInfoEXT *device_event_info,
>> + const VkAllocationCallbacks *allocator,
>> + struct wsi_fence **fence_p)
>> +{
>> + return VK_ERROR_FEATURE_NOT_PRESENT;
>>
>
> I don't think we're allowed to just not implemnet this. At the very least,
> we should accept the event and never trigger it. Better would be to
> actually wire up hotplug detection. I have no idea how insane that would
> be to do. :-P
It's not a big deal to implement, I just didn't need it. I suppose the
test suite will be unhappy with this? Let me know if you want to insist
on having it implemented.
> Both RegisterDeviceEvent and RegisterDisplayEvent say they can only return
> VK_SUCCESS. We should submit a MR against the extensions to also allow
> OUT_OF_HOST_MEMORY at the very least.
There's already weasel words in the section on memory allocation that
says the command must generate VK_ERROR_OUT_OF_HOST_MEMORY when
allocation fails. But, it would be nice for these APIs to be documented
as possibly returning that value.
> Any particular reason to put these all the way down here? I think my
> preference would be to move wsi_display_fence_event_handler to right after
> wsi_display_fence_check_free and give it a predeclaration
[Bug 106970] [drm:drm_sched_entity_cleanup [gpu_sched]] *ERROR* fence add callback failed (-22)
https://bugs.freedesktop.org/show_bug.cgi?id=106970 --- Comment #1 from mikhail.v.gavri...@gmail.com --- Created attachment 140241 --> https://bugs.freedesktop.org/attachment.cgi?id=140241=edit system log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106957] GPU runtime suspend broken since 4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106957 --- Comment #7 from Lukas Wunner --- I'm having a déjà vu here :-) [7.840122] snd_hda_intel :02:00.1: azx_runtime_idle: !power_save_controller = 0, !azx_has_pm_runtime(chip) = 0, azx_bus(chip)->codec_powered = 0x1, !chip->running = 0 The single codec on this HDA controller is considered powered on, hence the HDA controller refuses to runtime suspend. Same problem as in #106597. What does the following show: grep . /sys/bus/hdaudio/devices/hdaudioC1D0/widgets/*/power_caps And could you try this debug patch (in lieu of the other one) to narrow down the root cause further: https://bugs.freedesktop.org/attachment.cgi?id=139735=edit Thanks! -- 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 106970] [drm:drm_sched_entity_cleanup [gpu_sched]] *ERROR* fence add callback failed (-22)
https://bugs.freedesktop.org/show_bug.cgi?id=106970 Bug ID: 106970 Summary: [drm:drm_sched_entity_cleanup [gpu_sched]] *ERROR* fence add callback failed (-22) Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mikhail.v.gavri...@gmail.com Created attachment 140240 --> https://bugs.freedesktop.org/attachment.cgi?id=140240=edit dmesg [39383.734817] WARNING: CPU: 5 PID: 30215 at drivers/dma-buf/dma-fence.c:248 dma_fence_add_callback+0x176/0x1f0 [39383.734835] Modules linked in: macvtap macvlan tap tun fuse rfcomm devlink nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables cmac bnep sunrpc xfs vfat fat libcrc32c intel_rapl x86_pkg_temp_thermal hid_logitech_hidpp intel_powerclamp coretemp kvm_intel kvm iTCO_wdt iTCO_vendor_support irqbypass crct10dif_pclmul gpio_ich crc32_pclmul ppdev ghash_clmulni_intel intel_cstate intel_uncore intel_rapl_perf snd_hda_codec_realtek [39383.734912] snd_hda_codec_generic snd_hda_codec_hdmi snd_usb_audio btusb btrtl btbcm btintel snd_hda_intel bluetooth snd_usbmidi_lib snd_hda_codec snd_rawmidi joydev snd_hda_core snd_hwdep hid_logitech_dj snd_seq snd_seq_device snd_pcm ecdh_generic rfkill snd_timer snd mei_me soundcore i2c_i801 mei lpc_ich parport_pc parport video binfmt_misc hid_sony ff_memless amdkfd amd_iommu_v2 amdgpu chash i2c_algo_bit gpu_sched drm_kms_helper ttm drm crc32c_intel r8169 mii [39383.734967] CPU: 5 PID: 30215 Comm: gallium_drv:0 Not tainted 4.18.0-0.rc0.git9.1.fc29.x86_64 #1 [39383.734968] Hardware name: Gigabyte Technology Co., Ltd. Z87M-D3H/Z87M-D3H, BIOS F11 08/12/2014 [39383.734972] RIP: 0010:dma_fence_add_callback+0x176/0x1f0 [39383.734973] Code: f6 74 1b 49 8b 06 49 8b 7e 08 49 83 c6 18 48 89 de e8 ce 9a 71 00 49 8b 06 48 85 c0 75 e8 65 ff 0d 8f c8 92 6c e9 0f ff ff ff <0f> 0b 41 bc ea ff ff ff e9 eb fe ff ff 65 ff 05 76 c8 92 6c 48 8b [39383.735039] RSP: 0018:a0354f733c98 EFLAGS: 00010246 [39383.735042] RAX: 0004 RBX: 95348d6e3818 RCX: 00ff [39383.735043] RDX: c01e6e00 RSI: 95348d6e3818 RDI: [39383.735044] RBP: 9536ae501580 R08: 798cd856a73b R09: [39383.735046] R10: R11: R12: 953654aeb180 [39383.735047] R13: c01e6e00 R14: 9536ae5015e8 R15: 801a [39383.735049] FS: () GS:953afe00() knlGS: [39383.735050] CS: 0010 DS: 002b ES: 002b CR0: 80050033 [39383.735052] CR2: f2488ae4 CR3: 00053c612001 CR4: 001626e0 [39383.735053] Call Trace: [39383.735062] ? drm_sched_entity_wakeup+0x60/0x60 [gpu_sched] [39383.735065] drm_sched_entity_cleanup+0x10a/0x160 [gpu_sched] [39383.735143] amdgpu_ctx_mgr_entity_cleanup+0xb9/0xf0 [amdgpu] [39383.735178] amdgpu_ctx_mgr_fini+0x35/0xb0 [amdgpu] [39383.735203] amdgpu_driver_postclose_kms+0x138/0x290 [amdgpu] [39383.735208] ? __mutex_unlock_slowpath+0x4b/0x2b0 [39383.735224] drm_release+0x293/0x3f0 [drm] [39383.735231] __fput+0xca/0x250 [39383.735236] task_work_run+0xa1/0xd0 [39383.735242] do_exit+0x3fe/0xc70 [39383.735246] ? trace_hardirqs_on_caller+0xed/0x180 [39383.735251] __ia32_sys_exit+0x17/0x20 [39383.735254] do_fast_syscall_32+0xac/0x340 [39383.735257] entry_SYSENTER_compat+0x84/0x96 [39383.735266] irq event stamp: 12604 [39383.735269] hardirqs last enabled at (12603): [] ktime_get+0xec/0x130 [39383.735272] hardirqs last disabled at (12604): [] error_entry+0x89/0x110 [39383.735274] softirqs last enabled at (12482): [] __do_softirq+0x38c/0x4f7 [39383.735276] softirqs last disabled at (12465): [] irq_exit+0x101/0x110 [39383.735278] ---[ end trace 403f5176c1d37060 ]--- [39383.735281] [drm:drm_sched_entity_cleanup [gpu_sched]] *ERROR* fence add callback failed (-22) -- 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 4/7] anv: Support wait for heterogeneous list of fences [v2]
On Tue, Jun 19, 2018 at 6:22 PM, Keith Packard wrote: > Jason Ekstrand writes: > > > I suppose we probably shouldn't worry about current_time being greater > than > > INT64_MAX? I guess if that happens we have pretty big problems... > > Nope, we've already given up on that working -- it's a couple hundred > years of system uptime. Neither of us have any concerns in this area. > > >>timeout = MIN2(max_timeout, timeout); > >> > >>return (current_time + timeout); > >> } > >> > > > > Yeah, I think that's better. > > Cool. I'll wait for further review :-) > I don't think I have any more comments on this patch. It's gross but I think it should work. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] anv: Support wait for heterogeneous list of fences [v2]
Jason Ekstrand writes: > I suppose we probably shouldn't worry about current_time being greater than > INT64_MAX? I guess if that happens we have pretty big problems... Nope, we've already given up on that working -- it's a couple hundred years of system uptime. Neither of us have any concerns in this area. >>timeout = MIN2(max_timeout, timeout); >> >>return (current_time + timeout); >> } >> > > Yeah, I think that's better. Cool. I'll wait for further review :-) -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106258] AMD Xorg start failes with non-4K page sizes
https://bugs.freedesktop.org/show_bug.cgi?id=106258 --- Comment #31 from Ben Crocker --- Created attachment 140239 --> https://bugs.freedesktop.org/attachment.cgi?id=140239=edit More patches (2) for additional debug info Hi foxbat, Could you please apply these two patches on top of the patches I supplied yesterday, and post the output? (The patch to amdgpu_job.c is a corrected version of yesterday's patch.) Thanks, Ben -- 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 4/7] anv: Support wait for heterogeneous list of fences [v2]
On Tue, Jun 19, 2018 at 5:36 PM, Keith Packard wrote:
> Jason Ekstrand writes:
>
> > I still don't really like this but I agree that this code really should
> not
> > be getting hit very often so it's probably not too bad. Maybe one day
> > we'll be able to drop the non-syncobj paths entirely. Wouldn't that be
> > nice.
>
> I agree. What I want to have is kernel-side syncobj support for all of
> the WSI fences that we need here.
>
> I thought about using syncobjs and signaling them from user-space, but
> realized that we couldn't eliminate the non-syncobj path quite yet as
> that requires a new enough kernel. And, if we want to get to
> kernel-native WSI syncobjs, that would mean we'd eventually have three
> code paths. I think it's better to have one 'legacy' path, which works
> on all kernels, and then one 'modern' path which does what we want.
>
> > In the mean time, this is probably fine. I did see one issue below
> > with time conversions that should be fixed though.
>
> Always a hard thing to get right.
>
> >> +static uint64_t anv_get_absolute_timeout(uint64_t timeout)
> >> +{
> >> + if (timeout == 0)
> >> + return 0;
> >> + uint64_t current_time = gettime_ns();
> >> +
> >> + timeout = MIN2(INT64_MAX - current_time, timeout);
> >> +
> >> + return (current_time + timeout);
> >> +}
> >>
> >
> > This does not have the same behavior as the code it replaces. In
> > particular, the old code saturates at INT64_MAX whereas this code does
> not
> > do so properly anymore. If UINT64_MAX gets passed into timeout, I
> believe
> > that will be implicitly casted to signed and the MIN will yield -1 which
> > gets casted back to unsigned and you get UINT64_MAX again.
>
> It won't not get implicitly casted to signed; the implicit cast works
> the other way where OP implicitly casts the
> operand to unsigned for types of the same 'rank' (where 'rank' is not
> quite equivalent to size). Here's a fine article on this:
>
> https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+
> Understand+integer+conversion+rules
>
> However, this is a rather obscure part of the ISO standard, and I don't
> think we should expect that people reading the code know it well.
This is why I insert casts like mad in these scenarios. :-)
> Adding
> a cast to make it clear what we want is a good idea. How about this?
>
> static uint64_t anv_get_absolute_timeout(uint64_t timeout)
> {
>if (timeout == 0)
> return 0;
>uint64_t current_time = gettime_ns();
>uint64_t max_timeout = (uint64_t) INT64_MAX - current_time;
>
I suppose we probably shouldn't worry about current_time being greater than
INT64_MAX? I guess if that happens we have pretty big problems...
>timeout = MIN2(max_timeout, timeout);
>
>return (current_time + timeout);
> }
>
Yeah, I think that's better.
--Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] anv: Support wait for heterogeneous list of fences [v2]
Jason Ekstrand writes:
> I still don't really like this but I agree that this code really should not
> be getting hit very often so it's probably not too bad. Maybe one day
> we'll be able to drop the non-syncobj paths entirely. Wouldn't that be
> nice.
I agree. What I want to have is kernel-side syncobj support for all of
the WSI fences that we need here.
I thought about using syncobjs and signaling them from user-space, but
realized that we couldn't eliminate the non-syncobj path quite yet as
that requires a new enough kernel. And, if we want to get to
kernel-native WSI syncobjs, that would mean we'd eventually have three
code paths. I think it's better to have one 'legacy' path, which works
on all kernels, and then one 'modern' path which does what we want.
> In the mean time, this is probably fine. I did see one issue below
> with time conversions that should be fixed though.
Always a hard thing to get right.
>> +static uint64_t anv_get_absolute_timeout(uint64_t timeout)
>> +{
>> + if (timeout == 0)
>> + return 0;
>> + uint64_t current_time = gettime_ns();
>> +
>> + timeout = MIN2(INT64_MAX - current_time, timeout);
>> +
>> + return (current_time + timeout);
>> +}
>>
>
> This does not have the same behavior as the code it replaces. In
> particular, the old code saturates at INT64_MAX whereas this code does not
> do so properly anymore. If UINT64_MAX gets passed into timeout, I believe
> that will be implicitly casted to signed and the MIN will yield -1 which
> gets casted back to unsigned and you get UINT64_MAX again.
It won't not get implicitly casted to signed; the implicit cast works
the other way where OP implicitly casts the
operand to unsigned for types of the same 'rank' (where 'rank' is not
quite equivalent to size). Here's a fine article on this:
https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules
However, this is a rather obscure part of the ISO standard, and I don't
think we should expect that people reading the code know it well. Adding
a cast to make it clear what we want is a good idea. How about this?
static uint64_t anv_get_absolute_timeout(uint64_t timeout)
{
if (timeout == 0)
return 0;
uint64_t current_time = gettime_ns();
uint64_t max_timeout = (uint64_t) INT64_MAX - current_time;
timeout = MIN2(max_timeout, timeout);
return (current_time + timeout);
}
> This is a problem because the value we pass into the kernel ioctls is
> signed. The behavior of the kernel *should* be infinite when timeout
> < 0 but, on some older kernels, -1 is treated as 0 and you get no
> timeout.
Yeah, we definitely want to cap the values to INT64_MAX.
>> - else if (current_ns + _timeout > INT64_MAX)
>>
>
> I suspect we need to cast INT64_MAX to a uint64_t here to ensure we don't
> accidentally get an implicit conversion to signed.
Again, it's not necessary given the C conversion rules, but it is a good
way to clarify the intent.
--
-keith
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] anv: add VK_EXT_display_control to anv driver [v2]
On Thu, Jun 14, 2018 at 7:52 PM, Keith Packard wrote:
> This extension provides fences and frame count information to direct
> display contexts. It uses new kernel ioctls to provide 64-bits of
> vblank sequence and nanosecond resolution.
>
> v2: Adopt Jason Ekstrand's coding conventions
>
> Declare variables at first use, eliminate extra whitespace between
> types and names. Wrap lines to 80 columns.
>
> Add extension to list in alphabetical order
>
> Suggested-by: Jason Ekstrand
>
> Signed-off-by: Keith Packard
> ---
> src/intel/vulkan/anv_extensions.py | 1 +
> src/intel/vulkan/anv_private.h | 4 ++
> src/intel/vulkan/anv_queue.c | 22 +++
> src/intel/vulkan/anv_wsi_display.c | 97 ++
> 4 files changed, 124 insertions(+)
>
> diff --git a/src/intel/vulkan/anv_extensions.py b/src/intel/vulkan/anv_
> extensions.py
> index 68e545a40f8..8c010e9280b 100644
> --- a/src/intel/vulkan/anv_extensions.py
> +++ b/src/intel/vulkan/anv_extensions.py
> @@ -111,6 +111,7 @@ EXTENSIONS = [
> Extension('VK_EXT_acquire_xlib_display', 1,
> 'VK_USE_PLATFORM_XLIB_XRANDR_EXT'),
> Extension('VK_EXT_debug_report', 8, True),
> Extension('VK_EXT_direct_mode_display', 1,
> 'VK_USE_PLATFORM_DISPLAY_KHR'),
> +Extension('VK_EXT_display_control', 1,
> 'VK_USE_PLATFORM_DISPLAY_KHR'),
> Extension('VK_EXT_display_surface_counter', 1,
> 'VK_USE_PLATFORM_DISPLAY_KHR'),
> Extension('VK_EXT_external_memory_dma_buf', 1, True),
> Extension('VK_EXT_global_priority', 1,
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> private.h
> index fb91bc33046..c81885979ad 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -2133,6 +2133,7 @@ enum anv_fence_type {
> ANV_FENCE_TYPE_NONE = 0,
> ANV_FENCE_TYPE_BO,
> ANV_FENCE_TYPE_SYNCOBJ,
> + ANV_FENCE_TYPE_WSI,
> };
>
> enum anv_bo_fence_state {
> @@ -2167,6 +2168,9 @@ struct anv_fence_impl {
>
>/** DRM syncobj handle for syncobj-based fences */
>uint32_t syncobj;
> +
> + /** WSI fence */
> + struct wsi_fence *fence_wsi;
> };
> };
>
> diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
> index 8df99c84549..073e65acf5e 100644
> --- a/src/intel/vulkan/anv_queue.c
> +++ b/src/intel/vulkan/anv_queue.c
> @@ -324,6 +324,10 @@ anv_fence_impl_cleanup(struct anv_device *device,
>anv_gem_syncobj_destroy(device, impl->syncobj);
>break;
>
> + case ANV_FENCE_TYPE_WSI:
> + impl->fence_wsi->destroy(impl->fence_wsi);
> + break;
> +
> default:
>unreachable("Invalid fence type");
> }
> @@ -672,6 +676,21 @@ done:
> return result;
> }
>
> +static VkResult
> +anv_wait_for_wsi_fence(struct anv_device *device,
> + const VkFence _fence,
> + uint64_t abs_timeout)
> +{
> + ANV_FROM_HANDLE(anv_fence, fence, _fence);
> +
> + struct anv_fence_impl *impl = >permanent;
> + bool expired = impl->fence_wsi->wait(impl->fence_wsi, true,
> abs_timeout);
> +
> + if (!expired)
> + return VK_TIMEOUT;
> + return VK_SUCCESS;
> +}
> +
> static VkResult
> anv_wait_for_fences(struct anv_device *device,
> uint32_t fenceCount,
> @@ -694,6 +713,9 @@ anv_wait_for_fences(struct anv_device *device,
> result = anv_wait_for_syncobj_fences(device, 1, [i],
> true, abs_timeout);
> break;
> + case ANV_FENCE_TYPE_WSI:
> +result = anv_wait_for_wsi_fence(device, pFences[i],
> abs_timeout);
> +break;
> case ANV_FENCE_TYPE_NONE:
> result = VK_SUCCESS;
> break;
> diff --git a/src/intel/vulkan/anv_wsi_display.c
> b/src/intel/vulkan/anv_wsi_display.c
> index f749a8d98f7..cd736bcdd74 100644
> --- a/src/intel/vulkan/anv_wsi_display.c
> +++ b/src/intel/vulkan/anv_wsi_display.c
> @@ -168,3 +168,100 @@ anv_GetRandROutputDisplayEXT(VkPhysicalDevice
> physical_device,
> display);
> }
> #endif /* VK_USE_PLATFORM_XLIB_XRANDR_EXT */
> +
> +/* VK_EXT_display_control */
> +
> +VkResult
> +anv_DisplayPowerControlEXT(VkDevice_device,
> +VkDisplayKHRdisplay,
> +const VkDisplayPowerInfoEXT
> *display_power_info)
> +{
> + ANV_FROM_HANDLE(anv_device, device, _device);
> +
> + return wsi_display_power_control(
> + _device, >instance->physicalDevice.wsi_device,
> + display, display_power_info);
> +}
> +
> +VkResult
> +anv_RegisterDeviceEventEXT(VkDevice _device,
> +const VkDeviceEventInfoEXT *device_event_info,
> +const VkAllocationCallbacks *allocator,
> +
Re: [PATCH 5/7] vulkan: add VK_EXT_display_control [v5]
Sorry for the flood of comments. Most of it's pretty trivial. The one
that has me the most concerned is the random appearence of 0.1s in some
strange places. Other than that, I'm reasonably happy with it.
On Thu, Jun 14, 2018 at 7:52 PM, Keith Packard wrote:
> This extension provides fences and frame count information to direct
> display contexts. It uses new kernel ioctls to provide 64-bits of
> vblank sequence and nanosecond resolution.
>
> v2: Remove DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT flag. This has
> been removed from the proposed kernel API.
>
> Add NULL parameter to drmCrtcQueueSequence ioctl as we
> don't care what sequence the event was actually queued to.
>
> v3: Adapt to pthread clock switch to MONOTONIC
>
> v4: Fix scope for wsi_display_mode andwsi_display_connector allocs
>
> Suggested-by: Jason Ekstrand
>
> v5: Adopt Jason Ekstrand's coding conventions
>
> Declare variables at first use, eliminate extra whitespace between
> types and names. Wrap lines to 80 columns.
>
> Use wsi_rel_to_abs_time helper function to convert relative
> timeouts to absolute timeouts without causing overflow.
>
> Suggested-by: Jason Ekstrand
>
> Signed-off-by: Keith Packard
> ---
> src/vulkan/wsi/wsi_common.h | 10 +
> src/vulkan/wsi/wsi_common_display.c | 307 +++-
> src/vulkan/wsi/wsi_common_display.h | 29 +++
> 3 files changed, 345 insertions(+), 1 deletion(-)
>
> diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
> index 054aad23c1c..081fe1dcf8d 100644
> --- a/src/vulkan/wsi/wsi_common.h
> +++ b/src/vulkan/wsi/wsi_common.h
> @@ -66,6 +66,16 @@ struct wsi_format_modifier_properties_list {
> struct wsi_format_modifier_properties *modifier_properties;
> };
>
> +struct wsi_fence {
> + VkDevice device;
> + const struct wsi_device *wsi_device;
> + VkDisplayKHR display;
> + const VkAllocationCallbacks *alloc;
> + bool (*wait)(struct wsi_fence *fence,
> +bool absolute, uint64_t timeout);
> + void (*destroy)(struct wsi_fence *fence);
> +};
> +
> struct wsi_interface;
>
> #define VK_ICD_WSI_PLATFORM_MAX (VK_ICD_WSI_PLATFORM_DISPLAY + 1)
> diff --git a/src/vulkan/wsi/wsi_common_display.c
> b/src/vulkan/wsi/wsi_common_display.c
> index 504f7741d73..40eaa6a322e 100644
> --- a/src/vulkan/wsi/wsi_common_display.c
> +++ b/src/vulkan/wsi/wsi_common_display.c
> @@ -79,6 +79,7 @@ typedef struct wsi_display_connector {
> struct list_head display_modes;
> wsi_display_mode *current_mode;
> drmModeModeInfo current_drm_mode;
> + uint32_t dpms_property;
> #ifdef VK_USE_PLATFORM_XLIB_XRANDR_EXT
> xcb_randr_output_t output;
> #endif
> @@ -132,6 +133,15 @@ struct wsi_display_swapchain {
> struct wsi_display_image images[0];
> };
>
> +struct wsi_display_fence {
> + struct wsi_fence base;
> + bool event_received;
> + bool destroyed;
> + uint64_t sequence;
> +};
> +
> +static uint64_t fence_sequence;
> +
> ICD_DEFINE_NONDISP_HANDLE_CASTS(wsi_display_mode, VkDisplayModeKHR)
> ICD_DEFINE_NONDISP_HANDLE_CASTS(wsi_display_connector, VkDisplayKHR)
>
> @@ -307,6 +317,19 @@ wsi_display_get_connector(struct wsi_device
> *wsi_device,
>
> connector->connected = drm_connector->connection !=
> DRM_MODE_DISCONNECTED;
>
> + /* Look for a DPMS property */
> + for (int p = 0; p < drm_connector->count_props; p++) {
> + drmModePropertyPtr prop = drmModeGetProperty(wsi->fd,
> +
> drm_connector->props[p]);
> + if (!prop)
> + continue;
> + if (prop->flags & DRM_MODE_PROP_ENUM) {
> + if (!strcmp(prop->name, "DPMS"))
> +connector->dpms_property = drm_connector->props[p];
>
break?
> + }
> + drmModeFreeProperty(prop);
> + }
> +
> /* Mark all connector modes as invalid */
> wsi_display_invalidate_connector_modes(wsi_device, connector);
>
> @@ -663,7 +686,7 @@ wsi_display_surface_get_capabilities2ext(VkIcdSurfaceBase
> *icd_surface,
> caps->currentTransform = khr_caps.currentTransform;
> caps->supportedCompositeAlpha = khr_caps.supportedCompositeAlpha;
> caps->supportedUsageFlags = khr_caps.supportedUsageFlags;
> - caps->supportedSurfaceCounters = 0;
> + caps->supportedSurfaceCounters = VK_SURFACE_COUNTER_VBLANK_EXT;
> return ret;
> }
>
> @@ -896,12 +919,21 @@ static void wsi_display_page_flip_handler(int fd,
> wsi_display_page_flip_handler2(fd, frame, sec, usec, 0, data);
> }
>
> +static void wsi_display_vblank_handler(int fd, unsigned int frame,
> + unsigned int sec, unsigned int
> usec,
> + void *data);
> +
> +static void wsi_display_sequence_handler(int fd,
[PATCH libdrm 1/2] intel: Introducing Whiskey Lake platform
Whiskey Lake uses the same gen graphics as Coffe Lake, including some
ids that were previously marked as reserved on Coffe Lake, but that
now are moved to WHL page.
So, let's just move them to WHL macros that will feed into CFL macro
just to keep it better organized to make easier future code review
but it will be handled as a CFL.
This is a copy of merged i915's
commit b9be78531d27 ("drm/i915/whl: Introducing Whiskey Lake platform")
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
intel/intel_chipset.h | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 32b2c48f..44e65f9e 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -231,16 +231,17 @@
#define PCI_CHIP_COFFEELAKE_S_GT2_4 0x3E9A
#define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B
#define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94
-#define PCI_CHIP_COFFEELAKE_U_GT1_1 0x3EA1
-#define PCI_CHIP_COFFEELAKE_U_GT1_2 0x3EA4
-#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA0
-#define PCI_CHIP_COFFEELAKE_U_GT2_2 0x3EA3
-#define PCI_CHIP_COFFEELAKE_U_GT2_3 0x3EA9
-#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA2
-#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA5
-#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA6
-#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7
-#define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8
+#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA9
+#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5
+#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6
+#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7
+#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8
+
+#define PCI_CHIP_WHISKEYLAKE_U_GT1_1 0x3EA1
+#define PCI_CHIP_WHISKEYLAKE_U_GT2_1 0x3EA0
+#define PCI_CHIP_WHISKEYLAKE_U_GT3_1 0x3EA2
+#define PCI_CHIP_WHISKEYLAKE_U_GT3_2 0x3EA3
+#define PCI_CHIP_WHISKEYLAKE_U_GT3_3 0x3EA4
#define PCI_CHIP_CANNONLAKE_0 0x5A51
#define PCI_CHIP_CANNONLAKE_1 0x5A59
@@ -510,16 +511,16 @@
#define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 || \
(devid) == PCI_CHIP_COFFEELAKE_H_GT2_2)
-#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT1_1 || \
- (devid) == PCI_CHIP_COFFEELAKE_U_GT1_2 || \
- (devid) == PCI_CHIP_COFFEELAKE_U_GT2_1 || \
- (devid) == PCI_CHIP_COFFEELAKE_U_GT2_2 || \
- (devid) == PCI_CHIP_COFFEELAKE_U_GT2_3 || \
+#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT2_1 || \
(devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 || \
(devid) == PCI_CHIP_COFFEELAKE_U_GT3_2 || \
(devid) == PCI_CHIP_COFFEELAKE_U_GT3_3 || \
(devid) == PCI_CHIP_COFFEELAKE_U_GT3_4 || \
- (devid) == PCI_CHIP_COFFEELAKE_U_GT3_5)
+ (devid) == PCI_CHIP_WHISKEYLAKE_U_GT1_1 || \
+ (devid) == PCI_CHIP_WHISKEYLAKE_U_GT2_1 || \
+ (devid) == PCI_CHIP_WHISKEYLAKE_U_GT3_1 || \
+ (devid) == PCI_CHIP_WHISKEYLAKE_U_GT3_2 || \
+ (devid) == PCI_CHIP_WHISKEYLAKE_U_GT3_3)
#define IS_COFFEELAKE(devid) (IS_CFL_S(devid) || \
IS_CFL_H(devid) || \
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/2] intel: Introducing Amber Lake platform
Amber Lake uses the same gen graphics as Kaby Lake, including a id
that were previously marked as reserved on Kaby Lake, but that now is
moved to AML page.
So, let's just move it to AML macro that will feed into KBL macro
just to keep it better organized to make easier future code review
but it will be handled as a KBL.
This is a copy of merged i915's
commit e364672477a1 ("drm/i915/aml: Introducing Amber Lake platform")
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
intel/intel_chipset.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 44e65f9e..583d6447 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -201,7 +201,6 @@
#define PCI_CHIP_KABYLAKE_ULX_GT1_50x5915
#define PCI_CHIP_KABYLAKE_ULX_GT1 0x590E
#define PCI_CHIP_KABYLAKE_ULX_GT2_00x591E
-#define PCI_CHIP_KABYLAKE_ULX_GT2_10x591C
#define PCI_CHIP_KABYLAKE_DT_GT2 0x5912
#define PCI_CHIP_KABYLAKE_M_GT20x5917
#define PCI_CHIP_KABYLAKE_DT_GT1 0x5902
@@ -213,6 +212,9 @@
#define PCI_CHIP_KABYLAKE_SRV_GT1 0x590A
#define PCI_CHIP_KABYLAKE_WKS_GT2 0x591D
+#define PCI_CHIP_AMBERLAKE_ULX_GT2_1 0x591C
+#define PCI_CHIP_AMBERLAKE_ULX_GT2_2 0x87C0
+
#define PCI_CHIP_BROXTON_0 0x0A84
#define PCI_CHIP_BROXTON_1 0x1A84
#define PCI_CHIP_BROXTON_2 0x5A84
@@ -468,12 +470,13 @@
#define IS_KBL_GT2(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT2 || \
(devid) == PCI_CHIP_KABYLAKE_ULT_GT2F || \
(devid) == PCI_CHIP_KABYLAKE_ULX_GT2_0 || \
-(devid) == PCI_CHIP_KABYLAKE_ULX_GT2_1 || \
(devid) == PCI_CHIP_KABYLAKE_DT_GT2|| \
(devid) == PCI_CHIP_KABYLAKE_M_GT2 || \
(devid) == PCI_CHIP_KABYLAKE_HALO_GT2 || \
(devid) == PCI_CHIP_KABYLAKE_SRV_GT2 || \
-(devid) == PCI_CHIP_KABYLAKE_WKS_GT2)
+(devid) == PCI_CHIP_KABYLAKE_WKS_GT2 || \
+(devid) == PCI_CHIP_AMBERLAKE_ULX_GT2_1
|| \
+(devid) == PCI_CHIP_AMBERLAKE_ULX_GT2_2)
#define IS_KBL_GT3(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT3_0 || \
(devid) == PCI_CHIP_KABYLAKE_ULT_GT3_1 || \
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] anv: Support wait for heterogeneous list of fences [v2]
I still don't really like this but I agree that this code really should not
be getting hit very often so it's probably not too bad. Maybe one day
we'll be able to drop the non-syncobj paths entirely. Wouldn't that be
nice. In the mean time, this is probably fine. I did see one issue below
with time conversions that should be fixed though.
On Thu, Jun 14, 2018 at 7:52 PM, Keith Packard wrote:
> Handle the case where the set of fences to wait for is not all of the
> same type by either waiting for them sequentially (waitAll), or
> polling them until the timer has expired (!waitAll). We hope the
> latter case is not common.
>
> While the current code makes sure that it always has fences of only
> one type, that will not be true when we add WSI fences. Split out this
> refactoring to make merging that clearer.
>
> v2: Adopt Jason Ekstrand's coding conventions
>
> Declare variables at first use, eliminate extra whitespace between
> types and names. Wrap lines to 80 columns.
>
> Suggested-by: Jason Ekstrand
>
> Signed-off-by: Keith Packard
> ---
> src/intel/vulkan/anv_queue.c | 105 +--
> 1 file changed, 88 insertions(+), 17 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
> index 6fe04a0a19d..8df99c84549 100644
> --- a/src/intel/vulkan/anv_queue.c
> +++ b/src/intel/vulkan/anv_queue.c
> @@ -459,12 +459,32 @@ gettime_ns(void)
> return (uint64_t)current.tv_sec * NSEC_PER_SEC + current.tv_nsec;
> }
>
> +static uint64_t anv_get_absolute_timeout(uint64_t timeout)
> +{
> + if (timeout == 0)
> + return 0;
> + uint64_t current_time = gettime_ns();
> +
> + timeout = MIN2(INT64_MAX - current_time, timeout);
> +
> + return (current_time + timeout);
> +}
>
This does not have the same behavior as the code it replaces. In
particular, the old code saturates at INT64_MAX whereas this code does not
do so properly anymore. If UINT64_MAX gets passed into timeout, I believe
that will be implicitly casted to signed and the MIN will yield -1 which
gets casted back to unsigned and you get UINT64_MAX again. This is a
problem because the value we pass into the kernel ioctls is signed. The
behavior of the kernel *should* be infinite when timeout < 0 but, on some
older kernels, -1 is treated as 0 and you get no timeout.
That said, I think I just saw a bug in the old code which I'll point out
below.
> +
> +static int64_t anv_get_relative_timeout(uint64_t abs_timeout)
> +{
> + uint64_t now = gettime_ns();
> +
> + if (abs_timeout < now)
> + return 0;
> + return abs_timeout - now;
> +}
> +
> static VkResult
> anv_wait_for_syncobj_fences(struct anv_device *device,
> uint32_t fenceCount,
> const VkFence *pFences,
> bool waitAll,
> -uint64_t _timeout)
> +uint64_t abs_timeout_ns)
> {
> uint32_t *syncobjs = vk_zalloc(>alloc,
>sizeof(*syncobjs) * fenceCount, 8,
> @@ -484,19 +504,6 @@ anv_wait_for_syncobj_fences(struct anv_device
> *device,
>syncobjs[i] = impl->syncobj;
> }
>
> - int64_t abs_timeout_ns = 0;
> - if (_timeout > 0) {
> - uint64_t current_ns = gettime_ns();
> -
> - /* Add but saturate to INT32_MAX */
> - if (current_ns + _timeout < current_ns)
> - abs_timeout_ns = INT64_MAX;
> - else if (current_ns + _timeout > INT64_MAX)
>
I suspect we need to cast INT64_MAX to a uint64_t here to ensure we don't
accidentally get an implicit conversion to signed.
> - abs_timeout_ns = INT64_MAX;
> - else
> - abs_timeout_ns = current_ns + _timeout;
> - }
> -
> /* The gem_syncobj_wait ioctl may return early due to an inherent
> * limitation in the way it computes timeouts. Loop until we've
> actually
> * passed the timeout.
> @@ -665,6 +672,67 @@ done:
> return result;
> }
>
> +static VkResult
> +anv_wait_for_fences(struct anv_device *device,
> +uint32_t fenceCount,
> +const VkFence *pFences,
> +bool waitAll,
> +uint64_t abs_timeout)
> +{
> + VkResult result = VK_SUCCESS;
> +
> + if (fenceCount <= 1 || waitAll) {
> + for (uint32_t i = 0; i < fenceCount; i++) {
> + ANV_FROM_HANDLE(anv_fence, fence, pFences[i]);
> + switch (fence->permanent.type) {
> + case ANV_FENCE_TYPE_BO:
> +result = anv_wait_for_bo_fences(
> + device, 1, [i], true,
> + anv_get_relative_timeout(abs_timeout));
> +break;
> + case ANV_FENCE_TYPE_SYNCOBJ:
> +result = anv_wait_for_syncobj_fences(device, 1, [i],
> + true, abs_timeout);
> +break;
> + case ANV_FENCE_TYPE_NONE:
> +result = VK_SUCCESS;
> +break;
> +
[Bug 106747] [CI] igt@* - crash - An internal exception that should have been handled was not: UnicodeDecodeError
https://bugs.freedesktop.org/show_bug.cgi?id=106747 Martin Peres changed: What|Removed |Added CC||arkadiusz.hi...@intel.com, ||petri.latv...@intel.com --- Comment #2 from Martin Peres --- Cc:ing the IGT maintainers, hopefully they can check it out :) -- 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 5/5] drm/msm: Add A6XX device support
Add support for the A6XX family of Adreno GPUs. The biggest addition
is the GMU (Graphics Management Unit) which takes over most of the
power management of the GPU itself but in a ironic twist of fate
needs a goodly amount of management itself. Add support for the
A6XX core code, the GMU and the HFI (hardware firmware interface)
queue that the CPU uses to communicate with the GMU.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/Makefile |3 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1172
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 162 +++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 807 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 60 +
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 435
drivers/gpu/drm/msm/adreno/a6xx_hfi.h | 127 +++
drivers/gpu/drm/msm/adreno/adreno_device.c | 12 +
drivers/gpu/drm/msm/adreno/adreno_gpu.h|3 +
drivers/gpu/drm/msm/msm_gpu.c |2 +-
10 files changed, 2782 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.c
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.h
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.c
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.h
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.c
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index cd40c050b2d7..4affc665c0de 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -10,6 +10,9 @@ msm-y := \
adreno/a5xx_gpu.o \
adreno/a5xx_power.o \
adreno/a5xx_preempt.o \
+ adreno/a6xx_gpu.o \
+ adreno/a6xx_gmu.o \
+ adreno/a6xx_hfi.o \
hdmi/hdmi.o \
hdmi/hdmi_audio.o \
hdmi/hdmi_bridge.o \
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
new file mode 100644
index ..9ecd7afe6321
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -0,0 +1,1172 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2017-2018 The Linux Foundation. All rights reserved. */
+
+#include
+#include
+#include
+#include
+
+#include "a6xx_gpu.h"
+#include "a6xx_gmu.xml.h"
+
+static irqreturn_t a6xx_gmu_irq(int irq, void *data)
+{
+ struct a6xx_gmu *gmu = data;
+ u32 status;
+
+ status = gmu_read(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_STATUS);
+ gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_CLR, status);
+
+ if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_WDOG_BITE) {
+ dev_err_ratelimited(gmu->dev, "GMU watchdog expired\n");
+
+ /* Temporary until we can recover safely */
+ BUG();
+ }
+
+ if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_HOST_AHB_BUS_ERROR)
+ dev_err_ratelimited(gmu->dev, "GMU AHB bus error\n");
+
+ if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_FENCE_ERR)
+ dev_err_ratelimited(gmu->dev, "GMU fence error: 0x%x\n",
+ gmu_read(gmu, REG_A6XX_GMU_AHB_FENCE_STATUS));
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t a6xx_hfi_irq(int irq, void *data)
+{
+ struct a6xx_gmu *gmu = data;
+ u32 status;
+
+ status = gmu_read(gmu, REG_A6XX_GMU_GMU2HOST_INTR_INFO);
+ gmu_write(gmu, REG_A6XX_GMU_GMU2HOST_INTR_CLR, status);
+
+ if (status & A6XX_GMU_GMU2HOST_INTR_INFO_MSGQ)
+ tasklet_schedule(>hfi_tasklet);
+
+ if (status & A6XX_GMU_GMU2HOST_INTR_INFO_CM3_FAULT) {
+ dev_err_ratelimited(gmu->dev, "GMU firmware fault\n");
+
+ /* Temporary until we can recover safely */
+ BUG();
+ }
+
+ return IRQ_HANDLED;
+}
+
+/* Check to see if the GX rail is still powered */
+static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
+{
+ u32 val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
+
+ return !(val &
+ (A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_GDSC_POWER_OFF |
+ A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
+}
+
+static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
+{
+ u32 val;
+ int local = gmu->idle_level;
+
+ /* SPTP and IFPC both report as IFPC */
+ if (gmu->idle_level == GMU_IDLE_STATE_SPTP)
+ local = GMU_IDLE_STATE_IFPC;
+
+ val = gmu_read(gmu, REG_A6XX_GPU_GMU_CX_GMU_RPMH_POWER_STATE);
+
+ if (val == local) {
+ if (gmu->idle_level != GMU_IDLE_STATE_IFPC ||
+ !a6xx_gmu_gx_is_on(gmu))
+ return true;
+ }
+
+ return false;
+}
+
+/* Wait for the GMU to get to its most idle state */
+int a6xx_gmu_wait_for_idle(struct a6xx_gpu *a6xx_gpu)
+{
+ struct a6xx_gmu *gmu = _gpu->gmu;
+
+ return spin_until(a6xx_gmu_check_idle_level(gmu));
+}
+
+static int a6xx_gmu_start(struct a6xx_gmu *gmu)
+{
+ int ret;
+ u32
[PATCH 2/5] drm/msm: Add a helper function to parse clock names
Add a helper function to parse the clock names and set up
the bulk data so we can take advantage of the bulk clock
functions instead of rolling our own. This is added
as a helper function so the upcoming a6xx GMU code can
also take advantage of it.
[v2 - set gpu->nr_clocks to 0 on failed parse ]
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c | 57 ++
drivers/gpu/drm/msm/msm_drv.h | 4 +++
drivers/gpu/drm/msm/msm_gpu.c | 58 ++-
drivers/gpu/drm/msm/msm_gpu.h | 2 +-
4 files changed, 72 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 7f7321eb5312..3e86fc9be39f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -78,6 +78,63 @@ module_param(modeset, bool, 0600);
* Util/helpers:
*/
+int msm_clk_bulk_get(struct device *dev, struct clk_bulk_data **bulk)
+{
+ struct property *prop;
+ const char *name;
+ struct clk_bulk_data *local;
+ int i = 0, ret, count;
+
+ count = of_property_count_strings(dev->of_node, "clock-names");
+ if (count < 1)
+ return 0;
+
+ local = devm_kcalloc(dev, sizeof(struct clk_bulk_data *),
+ count, GFP_KERNEL);
+ if (!local)
+ return -ENOMEM;
+
+ of_property_for_each_string(dev->of_node, "clock-names", prop, name) {
+ local[i].id = devm_kstrdup(dev, name, GFP_KERNEL);
+ if (!local[i].id) {
+ devm_kfree(dev, local);
+ return -ENOMEM;
+ }
+
+ i++;
+ }
+
+ ret = devm_clk_bulk_get(dev, count, local);
+
+ if (ret) {
+ for (i = 0; i < count; i++)
+ devm_kfree(dev, (void *) local[i].id);
+ devm_kfree(dev, local);
+
+ return ret;
+ }
+
+ *bulk = local;
+ return count;
+}
+
+struct clk *msm_clk_bulk_get_clock(struct clk_bulk_data *bulk, int count,
+ const char *name)
+{
+ int i;
+ char n[32];
+
+ snprintf(n, sizeof(n), "%s_clk", name);
+
+ for (i = 0; bulk && i < count; i++) {
+ if (!strcmp(bulk[i].id, name) || !strcmp(bulk[i].id, n))
+ return bulk[i].clk;
+ }
+
+
+ return NULL;
+}
+
struct clk *msm_clk_get(struct platform_device *pdev, const char *name)
{
struct clk *clk;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 17cefca1d566..011c34ad1f93 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -307,6 +307,10 @@ static inline void msm_perf_debugfs_cleanup(struct
msm_drm_private *priv) {}
#endif
struct clk *msm_clk_get(struct platform_device *pdev, const char *name);
+int msm_clk_bulk_get(struct device *dev, struct clk_bulk_data **bulk);
+
+struct clk *msm_clk_bulk_get_clock(struct clk_bulk_data *bulk, int count,
+ const char *name);
void __iomem *msm_ioremap(struct platform_device *pdev, const char *name,
const char *dbgname);
void msm_writel(u32 data, void __iomem *addr);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 1c09acfb4028..827644f0e1a7 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -141,8 +141,6 @@ static int disable_pwrrail(struct msm_gpu *gpu)
static int enable_clk(struct msm_gpu *gpu)
{
- int i;
-
if (gpu->core_clk && gpu->fast_rate)
clk_set_rate(gpu->core_clk, gpu->fast_rate);
@@ -150,28 +148,14 @@ static int enable_clk(struct msm_gpu *gpu)
if (gpu->rbbmtimer_clk)
clk_set_rate(gpu->rbbmtimer_clk, 1920);
- for (i = gpu->nr_clocks - 1; i >= 0; i--)
- if (gpu->grp_clks[i])
- clk_prepare(gpu->grp_clks[i]);
-
- for (i = gpu->nr_clocks - 1; i >= 0; i--)
- if (gpu->grp_clks[i])
- clk_enable(gpu->grp_clks[i]);
+ clk_bulk_prepare_enable(gpu->nr_clocks, gpu->grp_clks);
return 0;
}
static int disable_clk(struct msm_gpu *gpu)
{
- int i;
-
- for (i = gpu->nr_clocks - 1; i >= 0; i--)
- if (gpu->grp_clks[i])
- clk_disable(gpu->grp_clks[i]);
-
- for (i = gpu->nr_clocks - 1; i >= 0; i--)
- if (gpu->grp_clks[i])
- clk_unprepare(gpu->grp_clks[i]);
+ clk_bulk_disable_unprepare(gpu->nr_clocks, gpu->grp_clks);
/*
* Set the clock to a deliberately low rate. On older targets the clock
@@ -660,44 +644,22 @@ static irqreturn_t irq_handler(int irq, void *data)
return gpu->funcs->irq(gpu);
}
-static struct clk *get_clock(struct device *dev, const char *name)
-{
- struct clk *clk = devm_clk_get(dev, name);
-
- return IS_ERR(clk) ? NULL : clk;
-}
-
static int get_clocks(struct
[PATCH 1/5] drm/msm: Remove pm_runtime operations from msm_iommu
Now that the IOMMU is the master of it's own power we don't need to bring
up the GPU to do IOMMU operations. This is good because bringing up a6xx
requires the GMU so calling pm_runtime_get_sync() too early in the process
gets us into some nasty circular dependency situations.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_iommu.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index b23d33622f37..e80c79b3bb5c 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -38,13 +38,8 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const char
* const *names,
int cnt)
{
struct msm_iommu *iommu = to_msm_iommu(mmu);
- int ret;
- pm_runtime_get_sync(mmu->dev);
- ret = iommu_attach_device(iommu->domain, mmu->dev);
- pm_runtime_put_sync(mmu->dev);
-
- return ret;
+ return iommu_attach_device(iommu->domain, mmu->dev);
}
static void msm_iommu_detach(struct msm_mmu *mmu, const char * const *names,
@@ -52,9 +47,7 @@ static void msm_iommu_detach(struct msm_mmu *mmu, const char
* const *names,
{
struct msm_iommu *iommu = to_msm_iommu(mmu);
- pm_runtime_get_sync(mmu->dev);
iommu_detach_device(iommu->domain, mmu->dev);
- pm_runtime_put_sync(mmu->dev);
}
static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
@@ -63,9 +56,7 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
struct msm_iommu *iommu = to_msm_iommu(mmu);
size_t ret;
-// pm_runtime_get_sync(mmu->dev);
ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
-// pm_runtime_put_sync(mmu->dev);
WARN_ON(ret < 0);
return (ret == len) ? 0 : -EINVAL;
@@ -76,9 +67,7 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t iova,
{
struct msm_iommu *iommu = to_msm_iommu(mmu);
- pm_runtime_get_sync(mmu->dev);
iommu_unmap(iommu->domain, iova, len);
- pm_runtime_put_sync(mmu->dev);
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/msm: Add generated headers for A6XX
From: Sharat Masetty
Add initial register headers for A6XX targets.
Signed-off-by: Sharat Masetty
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1784 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 382 +
2 files changed, 2166 insertions(+)
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx.xml.h
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
new file mode 100644
index ..5af12fe3f95c
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -0,0 +1,1784 @@
+#ifndef A6XX_XML
+#define A6XX_XML
+
+/* Autogenerated file, DO NOT EDIT manually!
+
+This file was generated by the rules-ng-ng headergen tool in this git
repository:
+http://github.com/freedreno/envytools/
+git clone https://github.com/freedreno/envytools.git
+
+The rules-ng-ng source files this header was generated from are:
+- ./adreno.xml (501 bytes, from 2018-05-23 16:51:57)
+- ./freedreno_copyright.xml ( 1572 bytes, from 2016-10-24 21:12:27)
+- ./adreno/a2xx.xml ( 36805 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_common.xml ( 13634 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_pm4.xml( 38703 bytes, from 2018-05-23 16:51:57)
+- ./adreno/a3xx.xml ( 83840 bytes, from 2017-12-05 18:20:27)
+- ./adreno/a4xx.xml ( 112086 bytes, from 2018-05-23 16:51:57)
+- ./adreno/a5xx.xml ( 146494 bytes, from 2018-05-23 16:51:57)
+- ./adreno/a6xx.xml ( 69957 bytes, from 2018-05-23 17:09:08)
+- ./adreno/a6xx_gmu.xml ( 10431 bytes, from 2018-05-23 16:52:19)
+- ./adreno/ocmem.xml ( 1773 bytes, from 2016-10-24 21:12:27)
+
+Copyright (C) 2013-2018 by the following authors:
+- Rob Clark (robclark)
+- Ilia Mirkin (imirkin)
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice (including the
+next paragraph) shall be included in all copies or substantial
+portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE COPYRIGHT OWNER(S) AND/OR ITS SUPPLIERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+*/
+
+
+enum a6xx_cp_perfcounter_select {
+ PERF_CP_ALWAYS_COUNT = 0,
+};
+
+enum a6xx_event_write {
+ PC_CCU_INVALIDATE_DEPTH = 24,
+ PC_CCU_INVALIDATE_COLOR = 25,
+};
+
+#define A6XX_RBBM_INT_0_MASK_RBBM_GPU_IDLE 0x0001
+#define A6XX_RBBM_INT_0_MASK_CP_AHB_ERROR 0x0002
+#define A6XX_RBBM_INT_0_MASK_RBBM_ATB_ASYNCFIFO_OVERFLOW 0x0040
+#define A6XX_RBBM_INT_0_MASK_RBBM_GPC_ERROR0x0080
+#define A6XX_RBBM_INT_0_MASK_CP_SW 0x0100
+#define A6XX_RBBM_INT_0_MASK_CP_HW_ERROR 0x0200
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_FLUSH_DEPTH_TS 0x0400
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_FLUSH_COLOR_TS 0x0800
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_RESOLVE_TS 0x1000
+#define A6XX_RBBM_INT_0_MASK_CP_IB20x2000
+#define A6XX_RBBM_INT_0_MASK_CP_IB10x4000
+#define A6XX_RBBM_INT_0_MASK_CP_RB 0x8000
+#define A6XX_RBBM_INT_0_MASK_CP_RB_DONE_TS 0x0002
+#define A6XX_RBBM_INT_0_MASK_CP_WT_DONE_TS 0x0004
+#define A6XX_RBBM_INT_0_MASK_CP_CACHE_FLUSH_TS 0x0010
+#define A6XX_RBBM_INT_0_MASK_RBBM_ATB_BUS_OVERFLOW 0x0040
+#define A6XX_RBBM_INT_0_MASK_RBBM_HANG_DETECT 0x0080
+#define A6XX_RBBM_INT_0_MASK_UCHE_OOB_ACCESS 0x0100
+#define A6XX_RBBM_INT_0_MASK_UCHE_TRAP_INTR0x0200
+#define A6XX_RBBM_INT_0_MASK_DEBBUS_INTR_0 0x0400
+#define A6XX_RBBM_INT_0_MASK_DEBBUS_INTR_1 0x0800
+#define A6XX_RBBM_INT_0_MASK_ISDB_CPU_IRQ 0x4000
+#define A6XX_RBBM_INT_0_MASK_ISDB_UNDER_DEBUG 0x8000
+#define A6XX_CP_INT_CP_OPCODE_ERROR0x0001
+#define A6XX_CP_INT_CP_UCODE_ERROR
[PATCH 3/5] drm/msm/adreno: Load the firmware before bringing up the hardware
Failure to load firmware is the primary reason to fail adreno_load_gpu().
Try to load it first before going into the hardware initialization code and
unwinding it. This is important for a6xx because the GMU gets loaded from
the runtime power code and it is more costly to fail in that path because
of missing firmware.
[v2 - fix compile error caused by adreno_load_fw declared static in
adreno_gpu ]
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 23 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 2 +-
3 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 44813624a286..37746f1d54cf 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -155,6 +155,7 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
struct msm_gpu *gpu = NULL;
+ struct adreno_gpu *adreno_gpu;
int ret;
if (pdev)
@@ -165,7 +166,27 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
return NULL;
}
- pm_runtime_get_sync(>dev);
+ adreno_gpu = to_adreno_gpu(gpu);
+
+ /*
+* The number one reason for HW init to fail is if the firmware isn't
+* loaded yet. Try that first and don't bother continuing on
+* otherwise
+*/
+
+ ret = adreno_load_fw(adreno_gpu);
+ if (ret)
+ return NULL;
+
+ /* Make sure pm runtime is active and reset any previous errors */
+ pm_runtime_set_active(>dev);
+
+ ret = pm_runtime_get_sync(>dev);
+ if (ret < 0) {
+ dev_err(dev->dev, "Couldn't power up the GPU: %d\n", ret);
+ return NULL;
+ }
+
mutex_lock(>struct_mutex);
ret = msm_gpu_hw_init(gpu);
mutex_unlock(>struct_mutex);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index bcbf9f2a29f9..ae693c28d66c 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -138,7 +138,7 @@ adreno_request_fw(struct adreno_gpu *adreno_gpu, const char
*fwname)
return ERR_PTR(-ENOENT);
}
-static int adreno_load_fw(struct adreno_gpu *adreno_gpu)
+int adreno_load_fw(struct adreno_gpu *adreno_gpu)
{
int i;
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index bc9ec27e9ed8..81397935d847 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -227,7 +227,7 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
struct adreno_gpu *gpu, const struct adreno_gpu_funcs *funcs,
int nr_rings);
void adreno_gpu_cleanup(struct adreno_gpu *gpu);
-
+int adreno_load_fw(struct adreno_gpu *adreno_gpu);
/* ringbuffer helpers (the parts that are adreno specific) */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v6 PATCH 0/5] drm/msm: Add support for Adreno a6xx
This is an initial version of support for the Adreno a6xx GPU family starting with the a630 from the sdm845 SoC. This code is ahead of much of the sdm845 code that would be needed to actually bring up a device and it is also in advance of any user side support for the a6xx GPU so this is mainly just a chance to look over the code structure and get a feel for the direction that the hardware is going in. The a6xx GPU is an iteration of a5xx so most of the GPU side code looks pretty identical except for the usual register differences. The big different is in power control. On the a5xx there was a rudimentary device called the GPMU that did some basic power stuff but left most of the complexity to the kernel. On the a6xx the power complexity is being moved to a component called the GMU (graphics management unit) which handles the power control of the GPU and shuts it down quickly after it goes idle. This stack has a number of dependencies that are in various stages of being merged: https://patchwork.kernel.org/patch/10286375/ - dev_pm_opp_get_of_node() https://patchwork.kernel.org/patch/10333575/ - command DB https://patchwork.kernel.org/patch/10301163/ - pm_runtime ops for arm-smmu [v6 - set nr_clocks to 0 when parsing fails and minor cleanup in msm_iommu for Vivek. Fix compile error in the load firmware patch ] [v5 - Move firmware loading to adreno_load_gpu() so it is easier to fail if the firmware isn't found ] [v4 - Add clock parsing helper function and use it for GPU and GMU. Update recommended clock gating settings. Fix a bug in the CMD DB parser. Update register values from updated database ] [v3 - fix inverted register definition for GMU_SPTPRAC_CLK_STATUS; fix incorrect register check in a5xx_gmu_gx_is_on(), use dev_pm_opp_get_of_node() from Rajendra and Viresh to read the qcom,level from the device tree; read qcom,level from the DT to get the voltage level to pass to the GMU, fix issues identified by smatch] [v2 - addressed comments from Lucas Stach; added pm_runtime_get_supplier calls for accesses to the GMU IOMMU; moved to SPDX headers for new files] Jordan Crouse (4): drm/msm: Remove pm_runtime operations from msm_iommu drm/msm: Add a helper function to parse clock names drm/msm/adreno: Load the firmware before bringing up the hardware drm/msm: Add A6XX device support Sharat Masetty (1): drm/msm: Add generated headers for A6XX drivers/gpu/drm/msm/Makefile |3 + drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1784 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1172 + drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 162 ++ drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 382 + drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 807 + drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 60 + drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 435 + drivers/gpu/drm/msm/adreno/a6xx_hfi.h | 127 ++ drivers/gpu/drm/msm/adreno/adreno_device.c | 35 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c|2 +- drivers/gpu/drm/msm/adreno/adreno_gpu.h|5 +- drivers/gpu/drm/msm/msm_drv.c | 57 + drivers/gpu/drm/msm/msm_drv.h |4 + drivers/gpu/drm/msm/msm_gpu.c | 60 +- drivers/gpu/drm/msm/msm_gpu.h |2 +- drivers/gpu/drm/msm/msm_iommu.c| 13 +- 17 files changed, 5045 insertions(+), 65 deletions(-) create mode 100644 drivers/gpu/drm/msm/adreno/a6xx.xml.h create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.c create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.h create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.c create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.h create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.c create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.h -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Minor subject nit: From the caller's point of view, we must convert a bus
address to a resource *always* (the caller has no knowledge of "whether it
is translated by the host bridge").
On Fri, May 18, 2018 at 10:17:51AM -0400, Sinan Kaya wrote:
> A host bridge is allowed to remap BAR addresses using _TRA attribute in
> _CRS windows.
Also, _TRA/_CRS are ACPI-specific terms and non-ACPI host bridges can
also do the same sort of translation. Another trivial nit.
> pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window]
> (bus address [0x0010-0x1fff])
> pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff]
>
> When a VGA device is behind such a host bridge and the resource is
> translated efifb driver is trying to do ioremap against bus address
> rather than the resource address and is failing to probe.
>
> efifb: probing for efifb
> efifb: cannot reserve video memory at 0x1e00
> efifb: framebuffer at 0x1e00, using 1920k, total 1875k
> efifb: mode is 800x600x32, linelength=3200, pages=1
> efifb: scrolling: redraw
> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
>
> Use the host bridge offset information to convert bus address to
> resource address in the fixup.
>
> Signed-off-by: Sinan Kaya
Reviewed-by: Bjorn Helgaas
Thanks a lot for fixing this!
> ---
> drivers/video/fbdev/efifb.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 6daac8d..429cc85 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -431,6 +431,7 @@ static void efifb_fixup_resources(struct pci_dev *dev)
> .end = screen_info.lfb_base + screen_info.lfb_size - 1,
> .flags = IORESOURCE_MEM,
> };
> + struct pci_bus_region region;
> int i;
>
> if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> @@ -442,6 +443,10 @@ static void efifb_fixup_resources(struct pci_dev *dev)
> if (!screen_res.start)
> return;
>
> + region.start = screen_res.start;
> + region.end = screen_res.end;
> + pcibios_bus_to_resource(dev->bus, _res, );
> +
> for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
> struct resource *res = >resource[i];
>
> --
> 2.7.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
On Fri, May 18, 2018 at 10:20:29AM -0400, Sinan Kaya wrote: > On 5/18/2018 6:42 AM, Robin Murphy wrote: > > > > FWIW, now that I've actually gone and looked, it appears you could simplify > > the whole function quite a bit by getting rid of these and just using the > > new local resource directly, especially since the only actual use of size > > is an open-coded resource_contains(). > > Posted V2 a minute ago. I did the simplification on a prior patch in order > not to > mix the issues. I don't see the V2 on linux-pci, but it sounds like Ard would merge this anyway. So I'll drop this and you can let me know if there's anything you need from me. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91221] UVD: GPU lockup with BARTS
https://bugs.freedesktop.org/show_bug.cgi?id=91221 --- Comment #8 from J Mueller --- Created attachment 140238 --> https://bugs.freedesktop.org/attachment.cgi?id=140238=edit dmesg/journalctl output for two GPU lockups ### ATTACHMENT [Line 854-971]: A recovered GPU-lockup, leaving the system in a stable state with some pixel-artifacts all over the desktop. [Line 972-end]: A non-recoverable GPU-lockup, which made a reboot via power-button necessary. SYSTEM System:Host: iotem-pc Kernel: 4.14.48-2-MANJARO x86_64 bits: 64 compiler: gcc v: 8.1.1 Desktop: N/A Distro: Manjaro Linux 17.1.10 Hakoila Machine: Type: Desktop System: Gigabyte product: N/A v: N/A serial: Mobo: Gigabyte model: 970A-DS3P v: x.x serial: BIOS: American Megatrends v: F2j date: 12/29/2014 CPU: Topology: 8-Core model: AMD FX-8350 bits: 64 type: MCP arch: Bulldozer L2 cache: 2048 KiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 64313 Speed: 1403 MHz min/max: 1400/4000 MHz Core speeds (MHz): 1: 1401 2: 1398 3: 1404 4: 1398 5: 1401 6: 1406 7: 1403 8: 1401 Graphics: Card-1: Advanced Micro Devices [AMD/ATI] Barts XT [Radeon HD 6870] driver: radeon v: kernel bus ID: 01:00.0 Display: x11 server: N/A driver: ati,radeon unloaded: fbdev,modesetting,vesa resolution: OpenGL: renderer: AMD BARTS (DRM 2.50.0 / 4.14.48-2-MANJARO LLVM 6.0.0) v: 3.3 Mesa 18.1.1 direct render: Yes Audio: Card-1: Advanced Micro Devices [AMD/ATI] SBx00 Azalia driver: snd_hda_intel v: kernel bus ID: 00:14.2 Card-2: AMD Barts HDMI Audio [Radeon HD 6790/6850/6870 / 7720 OEM] driver: snd_hda_intel v: kernel bus ID: 01:00.1 Sound Server: ALSA v: k4.14.48-2-MANJARO Network: Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 v: 2.3LK-NAPI port: d000 bus ID: 03:00.0 IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: fc:aa:14:74:f2:39 Drives:HDD Total Size: 1.14 TiB used: 691.30 GiB (59.4%) ID-1: /dev/sda vendor: Samsung model: SSD 850 EVO 250GB size: 232.89 GiB ID-2: /dev/sdb vendor: Western Digital model: WD10EARS-00Y5B1 size: 931.51 GiB Partition: ID-1: / size: 213.51 GiB used: 116.63 GiB (54.6%) fs: ext4 dev: /dev/sda1 ID-2: swap-1 size: 14.96 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda2 Sensors: System Temperatures: cpu: 35.0 C mobo: 21.2 C gpu: radeon temp: 44 C Fan Speeds (RPM): cpu: 0 fan-1: 580 fan-3: 0 fan-4: 0 fan-5: 0 Voltages: 12v: N/A 5v: N/A 3.3v: N/A vbat: 3.14 Info: Processes: 189 Uptime: 55m Memory: 7.82 GiB used: 1.37 GiB (17.5%) Init: systemd Compilers: gcc: 8.1.1 Shell: bash v: 4.4.19 inxi: 3.0.10 ### DESCRIPTION I also encountered this bug on my system when playing videos in vlc. Setting vlc's FFmpeg hardware decoder from "automatic" (or "VDPAU") to "VA-API video decoder" worked as a workaround for my situation. The dmesg output might help tracking down this bug, since one time the lockup was recovered (pressing CTRL-Q fast enough, thus closing vlc) and the other time it rendered the system unusable (GPU artifacts "reacting" to keyboard input (changing pattern/colors), but no recovery from this state). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [PATCH] wsi_common_display: Deal with vscan values
Jason Ekstrand writes: > Looks good. Passes the CTS. Push it! All done. Now just two more series to go in this set :-) -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [PATCH] wsi_common_display: Deal with vscan values
On Tue, Jun 19, 2018 at 1:56 PM, Keith Packard wrote: > Jason Ekstrand writes: > > > 1) We weren't setting planeReorderPossible at all and we were using 0 > > instead of VK_FALSE (they're the same but we should use the enum) for > > persistentContent > > 2) We weren't advertising disconnected connectors via > > GetPhysicalDeviceDisplayProperties but were returning them from > > GetPhysicalDeviceDisplayPlaneProperties. > > 3) We weren't setting result if the condition variable failed to > > initialize (thanks GCC!) > > > > There is one outstanding issue that the CTS is complaining about, namely > > that you can't create modes. It tests that mode creation fails for a > mode > > with a zero width, height, or refresh rate and that's all fine. It then > > tries to re-create one of the modes that we've returned to it in > > GetDisplayModeProperties and assumes that it will work. We should > probably > > at least make sure that works by walking the list and looking for a mode > > that matches the requested one and returning it. I don't think anything > > actually requires us to return a unique pointer so it can be a search > > instead of a create. > > And that seems to at least make CTS happy. I've merged your fixes into > the first patch, added support for vkCreateDisplayModeKHR, rebased to > master and pushed the results to my repository. > > It looks like we're done here but I'll wait until I hear from you before > pushing to master in case you've got additional concerns. > Looks good. Passes the CTS. Push it! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [PATCH] wsi_common_display: Deal with vscan values
Jason Ekstrand writes: > 1) We weren't setting planeReorderPossible at all and we were using 0 > instead of VK_FALSE (they're the same but we should use the enum) for > persistentContent > 2) We weren't advertising disconnected connectors via > GetPhysicalDeviceDisplayProperties but were returning them from > GetPhysicalDeviceDisplayPlaneProperties. > 3) We weren't setting result if the condition variable failed to > initialize (thanks GCC!) > > There is one outstanding issue that the CTS is complaining about, namely > that you can't create modes. It tests that mode creation fails for a mode > with a zero width, height, or refresh rate and that's all fine. It then > tries to re-create one of the modes that we've returned to it in > GetDisplayModeProperties and assumes that it will work. We should probably > at least make sure that works by walking the list and looking for a mode > that matches the requested one and returning it. I don't think anything > actually requires us to return a unique pointer so it can be a search > instead of a create. And that seems to at least make CTS happy. I've merged your fixes into the first patch, added support for vkCreateDisplayModeKHR, rebased to master and pushed the results to my repository. It looks like we're done here but I'll wait until I hear from you before pushing to master in case you've got additional concerns. -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #13 from SET --- I'm giving up on bisecting, it's getting out of control, sorry. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 107/132] sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of function 'devm_ioremap'; did you mean 'of_ioremap'?
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 486e4f30e2a3b7bdd2caa48d09b905a34f2f99cb
commit: 080d2114b794d5764c7ff4b4454317cdb9d24652 [107/132] ASoC: AMD: enable
ACP3x drivers build
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 080d2114b794d5764c7ff4b4454317cdb9d24652
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sparc64
All errors (new ones prefixed by >>):
In file included from sound/soc/amd/raven/acp3x-pcm-dma.c:26:0:
sound/soc/amd/raven/acp3x.h: In function 'rv_readl':
sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function
'readl'; did you mean 'rv_readl'? [-Werror=implicit-function-declaration]
return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
rv_readl
sound/soc/amd/raven/acp3x.h: In function 'rv_writel':
sound/soc/amd/raven/acp3x.h:33:2: error: implicit declaration of function
'writel'; did you mean 'rv_writel'? [-Werror=implicit-function-declaration]
writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
^~
rv_writel
sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
>> sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of
>> function 'devm_ioremap'; did you mean 'of_ioremap'?
>> [-Werror=implicit-function-declaration]
adata->acp3x_base = devm_ioremap(>dev, res->start,
^~~~
of_ioremap
sound/soc/amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes
pointer from integer without a cast [-Wint-conversion]
adata->acp3x_base = devm_ioremap(>dev, res->start,
^
cc1: some warnings being treated as errors
vim +638 sound/soc/amd/raven/acp3x-pcm-dma.c
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 616
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 617 static int
acp3x_audio_probe(struct platform_device *pdev)
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 618 {
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 619 int status;
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 620 struct resource *res;
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 621 struct i2s_dev_data
*adata;
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 622 unsigned int irqflags;
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 623
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 624 if
(pdev->dev.platform_data == NULL) {
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 625
dev_err(>dev, "platform_data not retrieved\n");
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 626 return -ENODEV;
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 627 }
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 628 irqflags = *((unsigned
int *)(pdev->dev.platform_data));
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 629
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 630 adata =
devm_kzalloc(>dev, sizeof(struct i2s_dev_data),
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 631
GFP_KERNEL);
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 632 res =
platform_get_resource(pdev, IORESOURCE_MEM, 0);
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 633 if (!res) {
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 634
dev_err(>dev, "IORESOURCE_IRQ FAILED\n");
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 635 return
-ENODEV;
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 636 }
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 637
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 @638 adata->acp3x_base =
devm_ioremap(>dev, res->start,
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 639
resource_size(res));
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 640
446b0f10 Maruthi Srinivas Bayyavarapu 2017-03-30 641 res =
platform_get_resource(pdev, IORESOURCE_IRQ, 0);
446b0f10 Maruthi Srinivas Bayyavarapu 2017-03-30 642 if (!res) {
446b0f10 Maruthi Srinivas Bayyavarapu 2017-03-30 643
dev_err(>dev, "IORESOURCE_IRQ FAILED\n");
446b0f10 Maruthi Srinivas Bayyavarapu 2017-03-30 644 return -ENODEV;
446b0f10 Maruthi Srinivas Bayyavarapu 2017-03-30 645 }
446b0f10 Maruthi Srinivas Bayyavarapu 2017-03-30 646
446b0f10 Maruthi Srinivas Bayyavarapu 2017-03-30 647 adata->i2s_irq =
res->start;
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 648 adata->play_stream =
NULL;
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 649 adata->capture_stream =
NULL;
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 650
15d47ef0 Maruthi Srinivas Bayyavarapu 2017-03-29 651
dev_set_drvdata(>dev, adata);
15d47ef0 Maruthi
Re: [PATCH] drm: fix fallouts from slow-work -> wq conversion
On 9 August 2010 at 20:20, Tejun Heo wrote:
> >From 9a919c46dfa48a9c1f465174609b90253eb8ffc1 Mon Sep 17 00:00:00 2001
> From: Tejun Heo
> Date: Mon, 9 Aug 2010 12:01:27 +0200
>
> Commit 991ea75c (drm: use workqueue instead of slow-work), which made
> drm to use wq instead of slow-work, didn't account for the return
> value difference between delayed_slow_work_enqueue() and
> queue_delayed_work(). The former returns 0 on success and -errno on
> failures while the latter never fails and only uses the return value
> to indicate whether the work was already pending or not.
>
> This misconversion triggered spurious error messages. Remove the now
> unnecessary return value check and error message.
>
> Markus: caught another incorrect conversion in drm_kms_helper_poll_enable()
Acked-by: David Airlie
For queuing via your tree.
Thanks,
Dave.
>
> Signed-off-by: Tejun Heo
> Reported-by: Markus Trippelsdorf
> Tested-by: Markus Trippelsdorf
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
> ---
> Oops, you're right. So, this should do it.
>
> Thank you.
>
> drivers/gpu/drm/drm_crtc_helper.c | 16
> 1 files changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 4598130..b9e4dbf 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -839,7 +839,6 @@ static void output_poll_execute(struct work_struct *work)
> struct drm_connector *connector;
> enum drm_connector_status old_status, status;
> bool repoll = false, changed = false;
> - int ret;
>
> mutex_lock(>mode_config.mutex);
> list_for_each_entry(connector, >mode_config.connector_list,
> head) {
> @@ -874,11 +873,8 @@ static void output_poll_execute(struct work_struct *work)
> dev->mode_config.funcs->output_poll_changed(dev);
> }
>
> - if (repoll) {
> - ret = queue_delayed_work(system_nrt_wq, delayed_work,
> DRM_OUTPUT_POLL_PERIOD);
> - if (ret)
> - DRM_ERROR("delayed enqueue failed %d\n", ret);
> - }
> + if (repoll)
> + queue_delayed_work(system_nrt_wq, delayed_work,
> DRM_OUTPUT_POLL_PERIOD);
> }
>
> void drm_kms_helper_poll_disable(struct drm_device *dev)
> @@ -893,18 +889,14 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
> {
> bool poll = false;
> struct drm_connector *connector;
> - int ret;
>
> list_for_each_entry(connector, >mode_config.connector_list,
> head) {
> if (connector->polled)
> poll = true;
> }
>
> - if (poll) {
> - ret = queue_delayed_work(system_nrt_wq,
> >mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
> - if (ret)
> - DRM_ERROR("delayed enqueue failed %d\n", ret);
> - }
> + if (poll)
> + queue_delayed_work(system_nrt_wq,
> >mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
> }
> EXPORT_SYMBOL(drm_kms_helper_poll_enable);
>
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: fix fallouts from slow-work -> wq conversion
>From 9a919c46dfa48a9c1f465174609b90253eb8ffc1 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Mon, 9 Aug 2010 12:01:27 +0200
Commit 991ea75c (drm: use workqueue instead of slow-work), which made
drm to use wq instead of slow-work, didn't account for the return
value difference between delayed_slow_work_enqueue() and
queue_delayed_work(). The former returns 0 on success and -errno on
failures while the latter never fails and only uses the return value
to indicate whether the work was already pending or not.
This misconversion triggered spurious error messages. Remove the now
unnecessary return value check and error message.
Markus: caught another incorrect conversion in drm_kms_helper_poll_enable()
Signed-off-by: Tejun Heo
Reported-by: Markus Trippelsdorf
Tested-by: Markus Trippelsdorf
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
Oops, you're right. So, this should do it.
Thank you.
drivers/gpu/drm/drm_crtc_helper.c | 16
1 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 4598130..b9e4dbf 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -839,7 +839,6 @@ static void output_poll_execute(struct work_struct *work)
struct drm_connector *connector;
enum drm_connector_status old_status, status;
bool repoll = false, changed = false;
- int ret;
mutex_lock(>mode_config.mutex);
list_for_each_entry(connector, >mode_config.connector_list, head) {
@@ -874,11 +873,8 @@ static void output_poll_execute(struct work_struct *work)
dev->mode_config.funcs->output_poll_changed(dev);
}
- if (repoll) {
- ret = queue_delayed_work(system_nrt_wq, delayed_work,
DRM_OUTPUT_POLL_PERIOD);
- if (ret)
- DRM_ERROR("delayed enqueue failed %d\n", ret);
- }
+ if (repoll)
+ queue_delayed_work(system_nrt_wq, delayed_work,
DRM_OUTPUT_POLL_PERIOD);
}
void drm_kms_helper_poll_disable(struct drm_device *dev)
@@ -893,18 +889,14 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
{
bool poll = false;
struct drm_connector *connector;
- int ret;
list_for_each_entry(connector, >mode_config.connector_list, head) {
if (connector->polled)
poll = true;
}
- if (poll) {
- ret = queue_delayed_work(system_nrt_wq,
>mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
- if (ret)
- DRM_ERROR("delayed enqueue failed %d\n", ret);
- }
+ if (poll)
+ queue_delayed_work(system_nrt_wq,
>mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
}
EXPORT_SYMBOL(drm_kms_helper_poll_enable);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH wq#for-linus] drm: fix a fallout from slow-work -> wq conversion
Commit 991ea75c (drm: use workqueue instead of slow-work), which made
drm to use wq instead of slow-work, didn't account for the return
value difference between delayed_slow_work_enqueue() and
queue_delayed_work(). The former returns 0 on success and -errno on
failures while the latter never fails and only uses the return value
to indicate whether the work was already pending or not.
This misconversion triggered spurious error messages. Remove the now
unnecessary return value check and error message.
Signed-off-by: Tejun Heo
Reported-by: Markus Trippelsdorf
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
Markus, it's almost trivial but it would be great if you can test this
one too.
David, may I route this wq#for-linus?
Thanks.
drivers/gpu/drm/drm_crtc_helper.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 4598130..211ed7e 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -839,7 +839,6 @@ static void output_poll_execute(struct work_struct *work)
struct drm_connector *connector;
enum drm_connector_status old_status, status;
bool repoll = false, changed = false;
- int ret;
mutex_lock(>mode_config.mutex);
list_for_each_entry(connector, >mode_config.connector_list, head) {
@@ -874,11 +873,8 @@ static void output_poll_execute(struct work_struct *work)
dev->mode_config.funcs->output_poll_changed(dev);
}
- if (repoll) {
- ret = queue_delayed_work(system_nrt_wq, delayed_work,
DRM_OUTPUT_POLL_PERIOD);
- if (ret)
- DRM_ERROR("delayed enqueue failed %d\n", ret);
- }
+ if (repoll)
+ queue_delayed_work(system_nrt_wq, delayed_work,
DRM_OUTPUT_POLL_PERIOD);
}
void drm_kms_helper_poll_disable(struct drm_device *dev)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH wq#for-linus] drm: fix a fallout from slow-work -> wq conversion
On Mon, Aug 09, 2010 at 12:00:49PM +0200, Tejun Heo wrote:
> Commit 991ea75c (drm: use workqueue instead of slow-work), which made
> drm to use wq instead of slow-work, didn't account for the return
> value difference between delayed_slow_work_enqueue() and
> queue_delayed_work(). The former returns 0 on success and -errno on
> failures while the latter never fails and only uses the return value
> to indicate whether the work was already pending or not.
>
> This misconversion triggered spurious error messages. Remove the now
> unnecessary return value check and error message.
>
> Signed-off-by: Tejun Heo
> Reported-by: Markus Trippelsdorf
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
> ---
> Markus, it's almost trivial but it would be great if you can test this
> one too.
Looks good, but drm_kms_helper_poll_disable needs the same treatment.
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 4598130..b9e4dbf 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -839,7 +839,6 @@ static void output_poll_execute(struct work_struct *work)
struct drm_connector *connector;
enum drm_connector_status old_status, status;
bool repoll = false, changed = false;
- int ret;
mutex_lock(>mode_config.mutex);
list_for_each_entry(connector, >mode_config.connector_list, head) {
@@ -874,11 +873,8 @@ static void output_poll_execute(struct work_struct *work)
dev->mode_config.funcs->output_poll_changed(dev);
}
- if (repoll) {
- ret = queue_delayed_work(system_nrt_wq, delayed_work,
DRM_OUTPUT_POLL_PERIOD);
- if (ret)
- DRM_ERROR("delayed enqueue failed %d\n", ret);
- }
+ if (repoll)
+ queue_delayed_work(system_nrt_wq, delayed_work,
DRM_OUTPUT_POLL_PERIOD);
}
void drm_kms_helper_poll_disable(struct drm_device *dev)
@@ -893,18 +889,14 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
{
bool poll = false;
struct drm_connector *connector;
- int ret;
list_for_each_entry(connector, >mode_config.connector_list, head) {
if (connector->polled)
poll = true;
}
- if (poll) {
- ret = queue_delayed_work(system_nrt_wq,
>mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
- if (ret)
- DRM_ERROR("delayed enqueue failed %d\n", ret);
- }
+ if (poll)
+ queue_delayed_work(system_nrt_wq,
>mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
}
EXPORT_SYMBOL(drm_kms_helper_poll_enable);
--
»A man who doesn't know he is in prison can never escape.«
William S. Burroughs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106957] GPU runtime suspend broken since 4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106957 --- Comment #6 from p...@cooco.de --- Created attachment 140235 --> https://bugs.freedesktop.org/attachment.cgi?id=140235=edit dmesg with debug patch -- 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] video: fbdev: simplefb: Stop including
Quoting Geert Uytterhoeven (2018-06-19 10:22:21) > Simplefb is not a clock provider, but it uses of_clk_get_parent_count(), > so it can just include instead. > > Signed-off-by: Geert Uytterhoeven > --- Acked-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106957] GPU runtime suspend broken since 4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106957 --- Comment #5 from Lukas Wunner --- Okay the HDA's runtime ref counter is 0 and it has no active children, so it should suspend. Chances are it doesn't because rpm_idle() fails for some reason. Could you try this debug patch that I had created for #106597 and post the dmesg output? https://bugs.freedesktop.org/attachment.cgi?id=139706=edit You can add "log_buf_len=10M ignore_loglevel" to the command line to ensure that dmesg isn't truncated and contains all debug output. -- 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 199619] screen stays dark for long on bootup since kernel 4.17.0-rc2+
https://bugzilla.kernel.org/show_bug.cgi?id=199619 --- Comment #9 from Elmar Stellnberger (estel...@elstel.org) --- No, I don´t see what your bug should have in common with mine, Giorgio. Mine occurs after starting the X server. Very annoying; this bug persists up to kernel 4.18.0-rc1+. -- 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 106544] Boot error: gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu] dce110_stream_encoder_update_hdmi_info_packets+0x20e/0x3a0 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=106544 --- Comment #7 from Andrei Slavoiu --- I've encountered this with an RX 480 connected via DisplayPort as well: [55207.637429] WARNING: CPU: 3 PID: 2125 at drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x102/0x148 [55207.637431] Modules linked in: sr_mod cdrom [55207.637437] CPU: 3 PID: 2125 Comm: X Tainted: GW 4.17.2-gentoo #2 [55207.637438] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./FM2A88X Extreme6+, BIOS P4.20 01/13/2016 [55207.637440] RIP: 0010:generic_reg_update_ex+0x102/0x148 [55207.637440] RSP: 0018:c90002ba3890 EFLAGS: 00010246 [55207.637442] RAX: c90002ba38b0 RBX: 88043c4a8040 RCX: [55207.637442] RDX: RSI: RDI: 88043ca5a880 [55207.637443] RBP: c90002ba3900 R08: R09: [55207.637444] R10: c90002ba3918 R11: 0001 R12: 0001 [55207.637444] R13: R14: 88043caec000 R15: 88010b0f4188 [55207.637445] FS: 7fc777d7b900() GS:88044ed8() knlGS: [55207.637446] CS: 0010 DS: ES: CR0: 80050033 [55207.637447] CR2: 7fbdd0660a10 CR3: 000427b0c000 CR4: 000406e0 [55207.637448] Call Trace: [55207.637453] dce110_stream_encoder_update_hdmi_info_packets+0x36f/0x590 [55207.637456] dce110_apply_ctx_to_hw+0x76e/0x8f8 [55207.637458] ? dc_commit_state+0x32d/0x5c8 [55207.637460] ? set_freesync_on_streams.part.6+0x48/0x240 [55207.637461] ? mod_freesync_set_user_enable+0x119/0x150 [55207.637464] ? amdgpu_dm_atomic_commit_tail+0x34b/0xce0 [55207.637467] ? _cond_resched+0x10/0x38 [55207.637468] ? wait_for_completion_timeout+0x35/0x180 [55207.637469] ? wait_for_completion_interruptible+0x30/0x1a0 [55207.637472] ? commit_tail+0x38/0x68 [55207.637473] ? drm_atomic_helper_commit+0xf7/0x100 [55207.637474] ? drm_atomic_helper_set_config+0x72/0x80 [55207.637477] ? __drm_mode_set_config_internal+0x62/0x110 [55207.637478] ? drm_mode_setcrtc+0x3ee/0x578 [55207.637480] ? drm_crtc_check_viewport+0xa8/0xa8 [55207.637481] ? drm_ioctl_kernel+0x56/0xa8 [55207.637483] ? drm_ioctl+0x2a0/0x340 [55207.637484] ? drm_crtc_check_viewport+0xa8/0xa8 [55207.637486] ? amdgpu_drm_ioctl+0x44/0x78 [55207.637489] ? do_vfs_ioctl+0x9f/0x610 [55207.637492] ? __sys_recvmsg+0x7e/0x98 [55207.637493] ? ksys_ioctl+0x35/0x60 [55207.637495] ? __x64_sys_ioctl+0x11/0x18 [55207.637497] ? do_syscall_64+0x50/0x150 [55207.637500] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 [55207.637500] Code: 48 8b 40 08 e8 a0 1f 71 00 48 8b 75 a8 65 48 33 34 25 28 00 00 00 89 d8 75 18 48 83 c4 50 5b 41 5a 41 5c 41 5d 5d c3 0f 0b eb b4 <0f> 0b e9 43 ff ff ff e8 9a 0f 9c ff 41 ba 01 00 00 00 44 89 c0 [55207.637521] ---[ end trace b2eb025a41b6045f ]--- -- 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 106957] GPU runtime suspend broken since 4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106957 --- Comment #4 from p...@cooco.de --- # cat /sys/bus/pci/devices/:02:00.0/power/runtime_usage 1 # cat /sys/bus/pci/devices/:02:00.0/power/runtime_active_kids 0 # cat /sys/bus/pci/devices/:02:00.1/power/runtime_usage 0 # cat /sys/bus/pci/devices/:02:00.1/power/runtime_active_kids 0 # lsof /dev/snd/controlC1 No output. Yes, I did run this as root. -- 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 106957] GPU runtime suspend broken since 4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106957 --- Comment #3 from Lukas Wunner --- Okay so the HDA controller is bound to a driver and is runtime active. Naturally, if it's runtime active it'll keep the GPU awake. Question is what's keeping it active. Could you check if there are any user space processes accessing the HDA controller: sudo lsof /dev/snd/controlC1 You got "No such file or directory" for some of the commands I gave you because the kernel isn't compiled with CONFIG_PM_ADVANCED_DEBUG=y. Could you enable that option and try again? Thanks! -- 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] video: fbdev: simplefb: Stop including
Hi, On 19-06-18 19:22, Geert Uytterhoeven wrote: Simplefb is not a clock provider, but it uses of_clk_get_parent_count(), so it can just include instead. Signed-off-by: Geert Uytterhoeven LGTM: Acked-by: Hans de Goede Regards, Hans --- drivers/video/fbdev/simplefb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c index a3c44ecf4523e8ed..9a9d748b07f2777d 100644 --- a/drivers/video/fbdev/simplefb.c +++ b/drivers/video/fbdev/simplefb.c @@ -27,8 +27,8 @@ #include #include #include -#include #include +#include #include #include #include ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3 2/7] backlight: qcom-wled: restructure the qcom-wled bindings
Restructure the qcom-wled bindings for the better readability. Signed-off-by: Kiran Gunda --- .../bindings/leds/backlight/qcom-wled.txt | 110 - 1 file changed, 85 insertions(+), 25 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt index fb39e32..14f28f2 100644 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt @@ -1,30 +1,90 @@ Binding for Qualcomm Technologies, Inc. WLED driver -Required properties: -- compatible: should be "qcom,pm8941-wled" -- reg: slave address - -Optional properties: -- default-brightness: brightness value on boot, value from: 0-4095 - default: 2048 -- label: The name of the backlight device -- qcom,cs-out: bool; enable current sink output -- qcom,cabc: bool; enable content adaptive backlight control -- qcom,ext-gen: bool; use externally generated modulator signal to dim -- qcom,current-limit: mA; per-string current limit; value from 0 to 25 - default: 20mA -- qcom,current-boost-limit: mA; boost current limit; one of: - 105, 385, 525, 805, 980, 1260, 1400, 1680 - default: 805mA -- qcom,switching-freq: kHz; switching frequency; one of: - 600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371, - 1600, 1920, 2400, 3200, 4800, 9600, - default: 1600kHz -- qcom,ovp: V; Over-voltage protection limit; one of: - 27, 29, 32, 35 - default: 29V -- qcom,num-strings: #; number of led strings attached; value from 1 to 3 - default: 2 +WLED (White Light Emitting Diode) driver is used for controlling display +backlight that is part of PMIC on Qualcomm Technologies, Inc. reference +platforms. The PMIC is connected to the host processor via SPMI bus. + +- compatible + Usage:required + Value type: + Definition: should be one of: + "qcom,pm8941-wled" + "qcom,pmi8998-wled" + "qcom,pm660l-wled" + +- reg + Usage:required + Value type: + Definition: Base address of the WLED modules. + +- default-brightness + Usage:optional + Value type: + Definition: brightness value on boot, value from: 0-4095 + Default: 2048 + +- label + Usage:required + Value type: + Definition: The name of the backlight device + +- qcom,cs-out + Usage:optional + Value type: + Definition: enable current sink output. + This property is supported only for PM8941. + +- qcom,cabc + Usage:optional + Value type: + Definition: enable content adaptive backlight control. + +- qcom,ext-gen + Usage:optional + Value type: + Definition: use externally generated modulator signal to dim. + This property is supported only for PM8941. + +- qcom,current-limit + Usage:optional + Value type: + Definition: mA; per-string current limit + value: For pm8941: from 0 to 25 with 5 mA step +Default 20 mA. +For pmi8998: from 0 to 30 with 5 mA step +Default 25 mA. + +- qcom,current-boost-limit + Usage:optional + Value type: + Definition: mA; boost current limit. + For pm8941: one of: 105, 385, 525, 805, 980, 1260, 1400, + 1680. Default: 805 mA + For pmi8998: one of: 105, 280, 450, 620, 970, 1150, 1300, + 1500. Default: 970 mA + +- qcom,switching-freq + Usage:optional + Value type: +Definition: kHz; switching frequency; one of: 600, 640, 685, 738, + 800, 872, 960, 1066, 1200, 1371, 1600, 1920, 2400, 3200, + 4800, 9600. + Default: for pm8941: 1600 kHz + for pmi8998: 800 kHz + +- qcom,ovp + Usage:optional + Value type: + Definition: V; Over-voltage protection limit; one of: + 27, 29, 32, 35. default: 29V + This property is supported only for PM8941. + +- qcom,num-strings + Usage:optional + Value type: + Definition: #; number of led strings attached; + value from 1 to 3. default: 2 + This property is supported only for PM8941. Example: -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG 4.17] etnaviv-gpu f1840000.gpu: recover hung GPU!
On Tue, Jun 19, 2018 at 01:11:29PM +0200, Lucas Stach wrote: > Am Dienstag, den 19.06.2018, 12:00 +0100 schrieb Russell King - ARM Linux: > > No, it's not "a really big job" - it's just that the Dove GC600 is not > > fast enough to complete _two_ 1080p sized GPU operations within 500ms. > > The preceeding job contained two blits - one of them a non-alphablend > > copy of: > > > > 0018 04200780 0,24,1920,1056 -> 0,24,1920,1056 > > > > and one an alpha blended copy of: > > > > 04380780 0,0,1920,1080 -> 0,0,1920,1080 > > > > This is (iirc) something I already fixed with the addition of the > > progress detection back before etnaviv was merged into the mainline > > kernel. > > I hadn't expected it to be this slow. I see that we might need to bring > back the progress detection to fix the userspace regression, but I'm > not fond of this, as it might lead to really bad QoS. Well, the choices are that or worse overall performance through having to ignore the GPU entirely. > I would prefer userspace tracking the size of the blits and flushing > the cmdstream at an appropriate time, so we don't end up with really > long running jobs, but I'm not sure if this would be acceptable to > you... The question becomes how to split up two operations. Yes, we could submit them individually, but if they're together taking in excess of 500ms, then it's likely that individually, each operation will take in excess of 250ms which is still a long time. In any case, I think we need to fix this for 4.17-stable and then try to work (a) which operations are taking a long time, and (b) how to solve this issue. Do we have any way to track how long each submitted job has actually taken on the GPU? (Eg, by recording the times that we receive the events?) It wouldn't be very accurate for small jobs, but given this operation is taking so long, it would give an indication of how long this operation is actually taking. etnaviv doesn't appear to have any tracepoints, which would've been ideal for that. Maybe this is a reason to add some? ;) -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3 7/7] backlight: qcom-wled: Add auto string detection logic
The auto string detection algorithm checks if the current WLED
sink configuration is valid. It tries enabling every sink and
checks if the OVP fault is observed. Based on this information
it detects and enables the valid sink configuration.
Auto calibration will be triggered when the OVP fault interrupts
are seen frequently thereby it tries to fix the sink configuration.
The auto-detection also kicks in when the connected LED string
of the display-backlight malfunctions (because of damage) and
requires the damaged string to be turned off to prevent the
complete panel and/or board from being damaged.
Signed-off-by: Kiran Gunda
---
drivers/video/backlight/qcom-wled.c | 408 +++-
1 file changed, 403 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index e87ba70..6bc627c 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -25,13 +25,23 @@
#define WLED_MAX_STRINGS 4
#define WLED_DEFAULT_BRIGHTNESS2048
-
+#define WLED_SOFT_START_DLY_US 1
#define WLED3_SINK_REG_BRIGHT_MAX 0xFFF
/* WLED3 control registers */
+#define WLED3_CTRL_REG_FAULT_STATUS0x08
+#define WLED3_CTRL_REG_ILIM_FAULT_BIT BIT(0)
+#define WLED3_CTRL_REG_OVP_FAULT_BIT BIT(1)
+#define WLED4_CTRL_REG_SC_FAULT_BIT BIT(2)
+
+#define WLED3_CTRL_REG_INT_RT_STS 0x10
+#define WLED3_CTRL_REG_OVP_FAULT_STATUS BIT(1)
+
#define WLED3_CTRL_REG_MOD_EN 0x46
#define WLED3_CTRL_REG_MOD_EN_MASKBIT(7)
+#define WLED3_CTRL_REG_FEEDBACK_CONTROL0x48
+
#define WLED3_CTRL_REG_FREQ0x4c
#define WLED3_CTRL_REG_FREQ_MASK GENMASK(3, 0)
@@ -146,6 +156,7 @@ struct wled_config {
bool ext_gen;
bool cabc;
bool external_pfet;
+ bool auto_detection_enabled;
};
struct wled {
@@ -154,16 +165,22 @@ struct wled {
struct regmap *regmap;
struct mutex lock; /* Lock to avoid race from ISR */
ktime_t last_short_event;
+ ktime_t start_ovp_fault_time;
u16 ctrl_addr;
u16 sink_addr;
+ u16 auto_detection_ovp_count;
u32 brightness;
u32 max_brightness;
u32 short_count;
+ u32 auto_detect_count;
const int *version;
bool disabled_by_short;
bool has_short_detect;
+ int ovp_irq;
+ bool ovp_irq_disabled;
struct wled_config cfg;
+ struct delayed_work ovp_work;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
int (*wled_sync_toggle)(struct wled *wled);
};
@@ -209,6 +226,27 @@ static int wled4_set_brightness(struct wled *wled, u16
brightness)
return 0;
}
+static void wled_ovp_work(struct work_struct *work)
+{
+ u32 val;
+ int rc;
+
+ struct wled *wled = container_of(work,
+struct wled, ovp_work.work);
+
+ rc = regmap_read(wled->regmap, wled->ctrl_addr + WLED3_CTRL_REG_MOD_EN,
+);
+ if (rc < 0)
+ return;
+
+ if (val & WLED3_CTRL_REG_MOD_EN_MASK) {
+ if (wled->ovp_irq > 0 && wled->ovp_irq_disabled) {
+ enable_irq(wled->ovp_irq);
+ wled->ovp_irq_disabled = false;
+ }
+ }
+}
+
static int wled_module_enable(struct wled *wled, int val)
{
int rc;
@@ -220,7 +258,20 @@ static int wled_module_enable(struct wled *wled, int val)
WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
WLED3_CTRL_REG_MOD_EN_MASK);
- return rc;
+ if (rc < 0)
+ return rc;
+
+ if (val) {
+ schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);
+ } else {
+ cancel_delayed_work(>ovp_work);
+ if (wled->ovp_irq > 0 && !wled->ovp_irq_disabled) {
+ disable_irq(wled->ovp_irq);
+ wled->ovp_irq_disabled = true;
+ }
+ }
+
+ return 0;
}
static int wled3_sync_toggle(struct wled *wled)
@@ -346,6 +397,305 @@ static irqreturn_t wled_short_irq_handler(int irq, void
*_wled)
return IRQ_HANDLED;
}
+#define AUTO_DETECT_BRIGHTNESS 200
+static int wled_auto_string_detection(struct wled *wled)
+{
+ int rc = 0, i;
+ u32 sink_config = 0, int_sts;
+ u8 sink_test = 0, sink_valid = 0, val;
+
+ /* read configured sink configuration */
+ rc = regmap_read(wled->regmap, wled->sink_addr +
+WLED4_SINK_REG_CURR_SINK, _config);
+ if (rc < 0) {
+
[PATCH V3 0/7] backlight: qcom-wled: Support for QCOM wled driver
This patch series renames the pm8941-wled.c driver to qcom-wled.c to add the support for multiple PMICs supported by qualcomm. This patch series supports both PM8941 and PMI8998 WLED. The PMI8998 WLED has the support to handle the OVP (over voltage protection) and the SC (short circuit protection) interrupts. It also has the auto string detection algorithm support to configure the right strings if the user specified string configuration is in-correct. These three features are added in this series for PMI8998. changes from v1: Fixed the commit message for backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c Changes from v2: Fixed bjorn and other reviewer's comments Seperated the device tree bindings Splitted out the WLED4 changes in seperate patch Merged OVP and auto string detection patch Kiran Gunda (7): backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c backlight: qcom-wled: restructure the qcom-wled bindings backlight: qcom-wled: Add new properties for PMI8998 backlight: qcom-wled: Rename PM8941* to WLED3 backlight: qcom-wled: Add support for WLED4 peripheral backlight: qcom-wled: add support for short circuit handling backlight: qcom-wled: Add auto string detection logic .../bindings/leds/backlight/pm8941-wled.txt| 42 - .../bindings/leds/backlight/qcom-wled.txt | 172 +++ drivers/video/backlight/Kconfig|8 +- drivers/video/backlight/Makefile |2 +- drivers/video/backlight/pm8941-wled.c | 432 --- drivers/video/backlight/qcom-wled.c| 1327 6 files changed, 1504 insertions(+), 479 deletions(-) delete mode 100644 Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt delete mode 100644 drivers/video/backlight/pm8941-wled.c create mode 100644 drivers/video/backlight/qcom-wled.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3 6/7] backlight: qcom-wled: add support for short circuit handling
Handle the short circuit interrupt and check if the short circuit
interrupt is valid. Re-enable the module to check if it goes
away. Disable the module altogether if the short circuit event
persists.
Signed-off-by: Kiran Gunda
---
drivers/video/backlight/qcom-wled.c | 130 +++-
1 file changed, 127 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index 0bc7fcd..e87ba70 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -10,6 +10,9 @@
* GNU General Public License for more details.
*/
+#include
+#include
+#include
#include
#include
#include
@@ -38,6 +41,16 @@
#define WLED3_CTRL_REG_ILIMIT 0x4e
#define WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0)
+/* WLED4 control registers */
+#define WLED4_CTRL_REG_SHORT_PROTECT 0x5e
+#define WLED4_CTRL_REG_SHORT_EN_MASK BIT(7)
+
+#define WLED4_CTRL_REG_SEC_ACCESS 0xd0
+#define WLED4_CTRL_REG_SEC_UNLOCK 0xa5
+
+#define WLED4_CTRL_REG_TEST1 0xe2
+#define WLED4_CTRL_REG_TEST1_EXT_FET_DTEST2 0x09
+
/* WLED3 sink registers */
#define WLED3_SINK_REG_SYNC0x47
#define WLED3_SINK_REG_SYNC_MASK GENMASK(2, 0)
@@ -132,17 +145,23 @@ struct wled_config {
bool cs_out_en;
bool ext_gen;
bool cabc;
+ bool external_pfet;
};
struct wled {
const char *name;
struct device *dev;
struct regmap *regmap;
+ struct mutex lock; /* Lock to avoid race from ISR */
+ ktime_t last_short_event;
u16 ctrl_addr;
u16 sink_addr;
u32 brightness;
u32 max_brightness;
+ u32 short_count;
const int *version;
+ bool disabled_by_short;
+ bool has_short_detect;
struct wled_config cfg;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
@@ -194,6 +213,9 @@ static int wled_module_enable(struct wled *wled, int val)
{
int rc;
+ if (wled->disabled_by_short)
+ return -EFAULT;
+
rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
@@ -250,18 +272,19 @@ static int wled_update_status(struct backlight_device *bl)
bl->props.state & BL_CORE_FBBLANK)
brightness = 0;
+ mutex_lock(>lock);
if (brightness) {
rc = wled->wled_set_brightness(wled, brightness);
if (rc < 0) {
dev_err(wled->dev, "wled failed to set brightness
rc:%d\n",
rc);
- return rc;
+ goto unlock_mutex;
}
rc = wled->wled_sync_toggle(wled);
if (rc < 0) {
dev_err(wled->dev, "wled sync failed rc:%d\n", rc);
- return rc;
+ goto unlock_mutex;
}
}
@@ -269,15 +292,60 @@ static int wled_update_status(struct backlight_device *bl)
rc = wled_module_enable(wled, !!brightness);
if (rc < 0) {
dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
- return rc;
+ goto unlock_mutex;
}
}
wled->brightness = brightness;
+unlock_mutex:
+ mutex_unlock(>lock);
+
return rc;
}
+#define WLED_SHORT_DLY_MS 20
+#define WLED_SHORT_CNT_MAX 5
+#define WLED_SHORT_RESET_CNT_DLY_USUSEC_PER_SEC
+static irqreturn_t wled_short_irq_handler(int irq, void *_wled)
+{
+ struct wled *wled = _wled;
+ int rc;
+ s64 elapsed_time;
+
+ wled->short_count++;
+ mutex_lock(>lock);
+ rc = wled_module_enable(wled, false);
+ if (rc < 0) {
+ dev_err(wled->dev, "wled disable failed rc:%d\n", rc);
+ goto unlock_mutex;
+ }
+
+ elapsed_time = ktime_us_delta(ktime_get(),
+ wled->last_short_event);
+ if (elapsed_time > WLED_SHORT_RESET_CNT_DLY_US)
+ wled->short_count = 0;
+
+ if (wled->short_count > WLED_SHORT_CNT_MAX) {
+ dev_err(wled->dev, "Short trigged %d times, disabling WLED
forever!\n",
+ wled->short_count);
+ wled->disabled_by_short = true;
+ goto unlock_mutex;
+ }
+
+ wled->last_short_event = ktime_get();
+
+ msleep(WLED_SHORT_DLY_MS);
+ rc = wled_module_enable(wled, true);
+ if (rc < 0)
+ dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
+
+unlock_mutex:
+
Re: [BUG 4.17] etnaviv-gpu f1840000.gpu: recover hung GPU!
On Tue, Jun 19, 2018 at 02:28:46PM +0200, Lucas Stach wrote: > Am Dienstag, den 19.06.2018, 12:42 +0100 schrieb Russell King - ARM Linux: > > On Tue, Jun 19, 2018 at 01:11:29PM +0200, Lucas Stach wrote: > > > Am Dienstag, den 19.06.2018, 12:00 +0100 schrieb Russell King - ARM Linux: > > > > No, it's not "a really big job" - it's just that the Dove GC600 is not > > > > fast enough to complete _two_ 1080p sized GPU operations within 500ms. > > > > The preceeding job contained two blits - one of them a non-alphablend > > > > copy of: > > > > > > > > 0018 04200780 0,24,1920,1056 -> 0,24,1920,1056 > > > > > > > > and one an alpha blended copy of: > > > > > > > > 04380780 0,0,1920,1080 -> 0,0,1920,1080 > > > > > > > > This is (iirc) something I already fixed with the addition of the > > > > progress detection back before etnaviv was merged into the mainline > > > > kernel. > > > > > > I hadn't expected it to be this slow. I see that we might need to bring > > > back the progress detection to fix the userspace regression, but I'm > > > not fond of this, as it might lead to really bad QoS. > > > > Well, the choices are that or worse overall performance through having > > to ignore the GPU entirely. > > > > > I would prefer userspace tracking the size of the blits and flushing > > > the cmdstream at an appropriate time, so we don't end up with really > > > long running jobs, but I'm not sure if this would be acceptable to > > > you... > > > > The question becomes how to split up two operations. Yes, we could > > submit them individually, but if they're together taking in excess of > > 500ms, then it's likely that individually, each operation will take in > > excess of 250ms which is still a long time. > > > > In any case, I think we need to fix this for 4.17-stable and then try > > to work (a) which operations are taking a long time, and (b) how to > > solve this issue. > > Agreed. I'll look into bringing back the process detection for 4.17 > stable. > > I'm still curious why the GC600 on the Dove is that slow. With > performance like this moving a big(ish) window on the screen must be a > horrible user experience. I _think_ it's down to the blend being slow on GC600 - one of the problems of running modern "desktops" on the Dove is that with Xorg and a compositing window manager (eg, modern metacity) then yes, dragging windows around is very slow because of the multiple GPU operations required - even dragging a small window results in almost the entire screen being re-blended. I don't think that's fair to blame on the Dove though - that's just total inefficiency on the Xorg/compositing side to basically redraw the _entire_ screen for small changes. The compositing window manager brings with it other issues as well, in particular with colour-keyed overlay and detecting whether anything obscures the overlay. For example, if, as a memory bandwidth optimisation, you detect that the overlay window is unobscured in the Xvideo extension, and disable the primary plane and colourkeying, this works fine with non-compositing managers. However, with a compositing manager, you can end up with there being some graphics that is blended _on top_ of the Xvideo window which is unknown to the Xvideo backend... which results in the graphics not being displayed. The blending also has a detrimental effect on the colourkeying when the graphics is displayed - because of the blending, the colourkey is no longer the expected RGB value around objects, so you get the colourkey bleeding through around (eg) a menu. I've now disabled compositing in metacity which makes things a whole lot nicer (I've actually been meaning to track down the "slow window dragging" problem for a good few months now) and solves the overlay issue too. > > Do we have any way to track how long each submitted job has actually > > taken on the GPU? (Eg, by recording the times that we receive the > > events?) It wouldn't be very accurate for small jobs, but given this > > operation is taking so long, it would give an indication of how long > > this operation is actually taking. etnaviv doesn't appear to have > > any tracepoints, which would've been ideal for that. Maybe this is > > a reason to add some? ;) > > See attached patch (which I apparently forgot to send out). The DRM GPU > scheduler has some tracepoints, which might be helpful. The attached > patch adds a drm_sched_job_run tracepoint when a job is queued in the > hardware ring. Together with the existing drm_sched_process_job, this > should get you an idea how long a job takes to process. Note that at > any time up to 4 jobs are allowed in the hardware queue, so you need to > match up the end times. Thanks, I'll try to get some data in the next week or so. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps
[PATCH V3 3/7] backlight: qcom-wled: Add new properties for PMI8998
Update the bindings with the new properties used for
PMI8998.
Signed-off-by: Kiran Gunda
---
.../bindings/leds/backlight/qcom-wled.txt | 84 --
1 file changed, 77 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
index 14f28f2..503ce87 100644
--- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -48,11 +48,15 @@ platforms. The PMIC is connected to the host processor via
SPMI bus.
- qcom,current-limit
Usage:optional
Value type:
- Definition: mA; per-string current limit
- value: For pm8941: from 0 to 25 with 5 mA step
-Default 20 mA.
-For pmi8998: from 0 to 30 with 5 mA step
-Default 25 mA.
+ Definition: mA; per-string current limit; value from 0 to 25 with
+ 1 mA step. Default 20 mA.
+ This property is supported only for pm8941.
+
+- qcom,current-limit-microamp
+ Usage:optional
+ Value type:
+ Definition: uA; per-string current limit; value from 0 to 3 with
+ 2500 uA step. Default 25000 uA.
- qcom,current-boost-limit
Usage:optional
@@ -79,12 +83,61 @@ platforms. The PMIC is connected to the host processor via
SPMI bus.
27, 29, 32, 35. default: 29V
This property is supported only for PM8941.
+- qcom,ovp-millivolt
+ Usage:optional
+ Value type:
+ Definition: mV; Over-voltage protection limit;
+ For pmi8998: one of 18100, 19600, 29600, 31100
+ Default: 29600 mV
+ If this property is not specified for PM8941, it
+ falls back to "qcom,ovp" property.
+
- qcom,num-strings
Usage:optional
Value type:
Definition: #; number of led strings attached;
- value from 1 to 3. default: 2
- This property is supported only for PM8941.
+ value: For PM8941 from 1 to 3. default: 2
+For PMI8998 from 1 to 4. default: 4
+
+- interrupts
+ Usage:optional
+ Value type:
+ Definition: Interrupts associated with WLED. This should be
+ "short" and "ovp" interrupts. Interrupts can be
+ specified as per the encoding listed under
+ Documentation/devicetree/bindings/spmi/
+ qcom,spmi-pmic-arb.txt.
+
+- interrupt-names
+ Usage:optional
+ Value type:
+ Definition: Interrupt names associated with the interrupts.
+ Must be "short" and "ovp". The short circuit detection
+ is not supported for PM8941.
+
+- qcom,enabled-strings
+ Usage:optional
+ Value tyoe:
+ Definition: Array of the WLED strings numbered from 0 to 3. Each
+ string of leds are operated individually. Specify the
+ list of strings used by the device. Any combination of
+ led strings can be used.
+ for pm8941: Default values are [00 01].
+ for pmi8998: Default values are [00 01 02 03].
+
+- qcom,external-pfet
+ Usage:optional
+ Value type:
+ Definition: Specify if external PFET control for short circuit
+ protection is used. This property is supported only
+ for PMI8998.
+
+- qcom,auto-string-detection
+ Usage:optional
+ Value type:
+ Definition: Enables auto-detection of the WLED string configuration.
+ This feature is not supported for PM8941.
+
Example:
@@ -99,4 +152,21 @@ pm8941-wled@d800 {
qcom,switching-freq = <1600>;
qcom,ovp = <29>;
qcom,num-strings = <2>;
+ qcom,enabled-strings = <0x00 0x01>;
+};
+
+pmi8998-wled@d800 {
+ compatible = "qcom,pmi8998-wled";
+ reg = <0xd800 0xd900>;
+ label = "backlight";
+
+ interrupts = <3 0xd8 2 IRQ_TYPE_EDGE_RISING>,
+<3 0xd8 1 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "short", "ovp";
+ qcom,current-limit-microamp = <25000>;
+ qcom,current-boost-limit = <805>;
+ qcom,switching-freq = <1600>;
+ qcom,ovp-millivolt = <29600>;
+ qcom,num-strings = <4>;
+ qcom,enabled-strings = <0x00 0x01 0x02 0x03>;
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[PATCH 1/3] dt-bindings: display: Document the EDT et* displays in one file.
From: Jan Tuerk Document the Emerging Display Technology Corp. (EDT) using the simple-panel binding in one single file. Reviewed-by: Rob Herring Signed-off-by: Jan Tuerk --- .../bindings/display/panel/edt,et-series.txt | 39 +++ .../display/panel/edt,et057090dhu.txt | 7 .../display/panel/edt,et070080dh6.txt | 10 - .../display/panel/edt,etm0700g0dh6.txt| 10 - 4 files changed, 39 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/edt,et-series.txt delete mode 100644 Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt delete mode 100644 Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt delete mode 100644 Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt [Changes from v4 of emCON patch-series] - rebased to mainline/master - split as requested by Shawn Guo As requested by Sha diff --git a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt new file mode 100644 index ..f56b99ebd9be --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt @@ -0,0 +1,39 @@ +Emerging Display Technology Corp. Displays +== + + +Display bindings for EDT Display Technology Corp. Displays which are +compatible with the simple-panel binding, which is specified in +simple-panel.txt + + +5,7" WVGA TFT Panels + + ++-+-+-+ +| Identifier | compatbile | description | ++=+=+=+ +| ET057090DHU | edt,et057090dhu | 5.7" VGA TFT LCD panel | ++-+-+-+ + + +7,0" WVGA TFT Panels + + ++-+-+-+ +| Identifier | compatbile | description | ++=+=+=+ +| ETM0700G0DH6| edt,etm070080dh6| WVGA TFT Display with capacitive| +| | | Touchscreen | ++-+-+-+ +| ETM0700G0BDH6 | edt,etm070080bdh6 | Same as ETM0700G0DH6 but with | +| | | inverted pixel clock. | ++-+-+-+ +| ETM0700G0EDH6 | edt,etm070080edh6 | Same display as the ETM0700G0BDH6, | +| | | but with changed Hardware for the | +| | | backlight and the touch interface | ++-+-+-+ +| ET070080DH6 | edt,etm070080dh6| Same timings as the ETM0700G0DH6, | +| | | but with resistive touch. | ++-+-+-+ + diff --git a/Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt b/Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt deleted file mode 100644 index 4903d7b1d947.. --- a/Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt +++ /dev/null @@ -1,7 +0,0 @@ -Emerging Display Technology Corp. 5.7" VGA TFT LCD panel - -Required properties: -- compatible: should be "edt,et057090dhu" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt b/Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt deleted file mode 100644 index 20cb38e836e4.. --- a/Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt +++ /dev/null @@ -1,10 +0,0 @@ -Emerging Display Technology Corp. ET070080DH6 7.0" WVGA TFT LCD panel - -Required properties: -- compatible: should be "edt,et070080dh6" - -This panel is the same as ETM0700G0DH6 except for the touchscreen. -ET070080DH6 is the model with resistive touch. - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt deleted file mode 100644 index ee4b18053e40.. --- a/Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt +++ /dev/null @@ -1,10 +0,0 @@ -Emerging Display Technology Corp. ETM0700G0DH6 7.0" WVGA TFT LCD panel - -Required properties: -- compatible:
[PATCH 2/3] drm/panel: Add support for the EDT ETM0700G0BDH6
From: Jan Tuerk
The Emerging Display Technology ETM0700G0BDH6 is exactly
the same display as the ETM0700G0DH6, exept the pixelclock
polarity. Therefore re-use the ETM0700G0DH6 modes. It is
used by default on emtrion Avari based development kits.
Signed-off-by: Jan Tuerk
---
drivers/gpu/drm/panel/panel-simple.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..8b7feb2888f2 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -909,6 +909,18 @@ static const struct panel_desc edt_etm0700g0dh6 = {
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
};
+static const struct panel_desc edt_etm0700g0bdh6 = {
+ .modes = _etm0700g0dh6_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
+};
+
static const struct drm_display_mode foxlink_fl500wvr00_a0t_mode = {
.clock = 32260,
.hdisplay = 800,
@@ -2133,6 +2145,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "edt,etm0700g0dh6",
.data = _etm0700g0dh6,
+ }, {
+ .compatible = "edt,etm0700g0bdh6",
+ .data = _etm0700g0bdh6,
}, {
.compatible = "foxlink,fl500wvr00-a0t",
.data = _fl500wvr00_a0t,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3 4/7] backlight: qcom-wled: Rename PM8941* to WLED3
Rename the PM8941* references as WLED3 to make the
driver generic and have WLED support for other PMICs.
Signed-off-by: Kiran Gunda
---
drivers/video/backlight/qcom-wled.c | 248 ++--
1 file changed, 125 insertions(+), 123 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index 0b6d219..812f3cb 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -18,77 +18,79 @@
#include
/* From DT binding */
-#define PM8941_WLED_DEFAULT_BRIGHTNESS 2048
+#define WLED_DEFAULT_BRIGHTNESS2048
-#define PM8941_WLED_REG_VAL_BASE 0x40
-#define PM8941_WLED_REG_VAL_MAX 0xFFF
+#define WLED3_SINK_REG_BRIGHT_MAX 0xFFF
+#define WLED3_CTRL_REG_VAL_BASE0x40
-#define PM8941_WLED_REG_MOD_EN 0x46
-#define PM8941_WLED_REG_MOD_EN_BITBIT(7)
-#define PM8941_WLED_REG_MOD_EN_MASK BIT(7)
+/* WLED3 control registers */
+#define WLED3_CTRL_REG_MOD_EN 0x46
+#define WLED3_CTRL_REG_MOD_EN_BIT BIT(7)
+#define WLED3_CTRL_REG_MOD_EN_MASKBIT(7)
-#define PM8941_WLED_REG_SYNC 0x47
-#define PM8941_WLED_REG_SYNC_MASK 0x07
-#define PM8941_WLED_REG_SYNC_LED1 BIT(0)
-#define PM8941_WLED_REG_SYNC_LED2 BIT(1)
-#define PM8941_WLED_REG_SYNC_LED3 BIT(2)
-#define PM8941_WLED_REG_SYNC_ALL 0x07
-#define PM8941_WLED_REG_SYNC_CLEAR0x00
+#define WLED3_CTRL_REG_FREQ0x4c
+#define WLED3_CTRL_REG_FREQ_MASK 0x0f
-#define PM8941_WLED_REG_FREQ 0x4c
-#define PM8941_WLED_REG_FREQ_MASK 0x0f
+#define WLED3_CTRL_REG_OVP 0x4d
+#define WLED3_CTRL_REG_OVP_MASK 0x03
-#define PM8941_WLED_REG_OVP0x4d
-#define PM8941_WLED_REG_OVP_MASK 0x03
+#define WLED3_CTRL_REG_ILIMIT 0x4e
+#define WLED3_CTRL_REG_ILIMIT_MASK0x07
-#define PM8941_WLED_REG_BOOST 0x4e
-#define PM8941_WLED_REG_BOOST_MASK0x07
+/* WLED3 sink registers */
+#define WLED3_SINK_REG_SYNC0x47
+#define WLED3_SINK_REG_SYNC_MASK 0x07
+#define WLED3_SINK_REG_SYNC_LED1 BIT(0)
+#define WLED3_SINK_REG_SYNC_LED2 BIT(1)
+#define WLED3_SINK_REG_SYNC_LED3 BIT(2)
+#define WLED3_SINK_REG_SYNC_ALL 0x07
+#define WLED3_SINK_REG_SYNC_CLEAR 0x00
-#define PM8941_WLED_REG_SINK 0x4f
-#define PM8941_WLED_REG_SINK_MASK 0xe0
-#define PM8941_WLED_REG_SINK_SHFT 0x05
+#define WLED3_SINK_REG_CURR_SINK 0x4f
+#define WLED3_SINK_REG_CURR_SINK_MASK 0xe0
+#define WLED3_SINK_REG_CURR_SINK_SHFT 0x05
-/* Per-'string' registers below */
-#define PM8941_WLED_REG_STR_OFFSET 0x10
+/* WLED3 per-'string' registers below */
+#define WLED3_SINK_REG_STR_OFFSET 0x10
-#define PM8941_WLED_REG_STR_MOD_EN_BASE0x60
-#define PM8941_WLED_REG_STR_MOD_MASK BIT(7)
-#define PM8941_WLED_REG_STR_MOD_ENBIT(7)
+#define WLED3_SINK_REG_STR_MOD_EN_BASE 0x60
+#define WLED3_SINK_REG_STR_MOD_MASK BIT(7)
+#define WLED3_SINK_REG_STR_MOD_EN BIT(7)
-#define PM8941_WLED_REG_STR_SCALE_BASE 0x62
-#define PM8941_WLED_REG_STR_SCALE_MASK0x1f
+#define WLED3_SINK_REG_STR_FULL_SCALE_CURR 0x62
+#define WLED3_SINK_REG_STR_FULL_SCALE_CURR_MASK 0x1f
-#define PM8941_WLED_REG_STR_MOD_SRC_BASE 0x63
-#define PM8941_WLED_REG_STR_MOD_SRC_MASK 0x01
-#define PM8941_WLED_REG_STR_MOD_SRC_INT 0x00
-#define PM8941_WLED_REG_STR_MOD_SRC_EXT 0x01
+#define WLED3_SINK_REG_STR_MOD_SRC_BASE0x63
+#define WLED3_SINK_REG_STR_MOD_SRC_MASK 0x01
+#define WLED3_SINK_REG_STR_MOD_SRC_INT0x00
+#define WLED3_SINK_REG_STR_MOD_SRC_EXT0x01
-#define PM8941_WLED_REG_STR_CABC_BASE 0x66
-#define PM8941_WLED_REG_STR_CABC_MASK BIT(7)
-#define PM8941_WLED_REG_STR_CABC_EN BIT(7)
+#define WLED3_SINK_REG_STR_CABC_BASE 0x66
+#define WLED3_SINK_REG_STR_CABC_MASK BIT(7)
+#define WLED3_SINK_REG_STR_CABC_ENBIT(7)
-struct pm8941_wled_config {
- u32 i_boost_limit;
+struct wled_config {
+ u32 boost_i_limit;
u32 ovp;
u32 switch_freq;
u32 num_strings;
- u32 i_limit;
+ u32 string_i_limit;
[PATCH V3 5/7] backlight: qcom-wled: Add support for WLED4 peripheral
WLED4 peripheral is present on some PMICs like pmi8998 and pm660l. It has a different register map and configurations are also different. Add support for it. Signed-off-by: Kiran Gunda --- drivers/video/backlight/qcom-wled.c | 635 1 file changed, 503 insertions(+), 132 deletions(-) diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c index 812f3cb..0bc7fcd 100644 --- a/drivers/video/backlight/qcom-wled.c +++ b/drivers/video/backlight/qcom-wled.c @@ -15,59 +15,112 @@ #include #include #include +#include #include /* From DT binding */ +#define WLED_MAX_STRINGS 4 + #define WLED_DEFAULT_BRIGHTNESS2048 #define WLED3_SINK_REG_BRIGHT_MAX 0xFFF -#define WLED3_CTRL_REG_VAL_BASE0x40 /* WLED3 control registers */ #define WLED3_CTRL_REG_MOD_EN 0x46 -#define WLED3_CTRL_REG_MOD_EN_BIT BIT(7) #define WLED3_CTRL_REG_MOD_EN_MASKBIT(7) #define WLED3_CTRL_REG_FREQ0x4c -#define WLED3_CTRL_REG_FREQ_MASK 0x0f +#define WLED3_CTRL_REG_FREQ_MASK GENMASK(3, 0) #define WLED3_CTRL_REG_OVP 0x4d -#define WLED3_CTRL_REG_OVP_MASK 0x03 +#define WLED3_CTRL_REG_OVP_MASK GENMASK(1, 0) #define WLED3_CTRL_REG_ILIMIT 0x4e -#define WLED3_CTRL_REG_ILIMIT_MASK0x07 +#define WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0) /* WLED3 sink registers */ #define WLED3_SINK_REG_SYNC0x47 -#define WLED3_SINK_REG_SYNC_MASK 0x07 +#define WLED3_SINK_REG_SYNC_MASK GENMASK(2, 0) +#define WLED4_SINK_REG_SYNC_MASK GENMASK(3, 0) #define WLED3_SINK_REG_SYNC_LED1 BIT(0) #define WLED3_SINK_REG_SYNC_LED2 BIT(1) #define WLED3_SINK_REG_SYNC_LED3 BIT(2) +#define WLED4_SINK_REG_SYNC_LED4 BIT(3) #define WLED3_SINK_REG_SYNC_ALL 0x07 +#define WLED4_SINK_REG_SYNC_ALL 0x0f #define WLED3_SINK_REG_SYNC_CLEAR 0x00 #define WLED3_SINK_REG_CURR_SINK 0x4f -#define WLED3_SINK_REG_CURR_SINK_MASK 0xe0 -#define WLED3_SINK_REG_CURR_SINK_SHFT 0x05 +#define WLED3_SINK_REG_CURR_SINK_MASK GENMASK(7, 5) +#define WLED3_SINK_REG_CURR_SINK_SHFT 5 /* WLED3 per-'string' registers below */ -#define WLED3_SINK_REG_STR_OFFSET 0x10 +#define WLED3_SINK_REG_BRIGHT(n) (0x40 + n) -#define WLED3_SINK_REG_STR_MOD_EN_BASE 0x60 +#define WLED3_SINK_REG_STR_MOD_EN(n) (0x60 + (n * 0x10)) #define WLED3_SINK_REG_STR_MOD_MASK BIT(7) -#define WLED3_SINK_REG_STR_MOD_EN BIT(7) -#define WLED3_SINK_REG_STR_FULL_SCALE_CURR 0x62 -#define WLED3_SINK_REG_STR_FULL_SCALE_CURR_MASK 0x1f +#define WLED3_SINK_REG_STR_FULL_SCALE_CURR(n) (0x62 + (n * 0x10)) +#define WLED3_SINK_REG_STR_FULL_SCALE_CURR_MASK GENMASK(4, 0) -#define WLED3_SINK_REG_STR_MOD_SRC_BASE0x63 -#define WLED3_SINK_REG_STR_MOD_SRC_MASK 0x01 +#define WLED3_SINK_REG_STR_MOD_SRC(n) (0x63 + (n * 0x10)) +#define WLED3_SINK_REG_STR_MOD_SRC_MASK BIT(0) #define WLED3_SINK_REG_STR_MOD_SRC_INT0x00 #define WLED3_SINK_REG_STR_MOD_SRC_EXT0x01 -#define WLED3_SINK_REG_STR_CABC_BASE 0x66 +#define WLED3_SINK_REG_STR_CABC(n) (0x66 + (n * 0x10)) #define WLED3_SINK_REG_STR_CABC_MASK BIT(7) -#define WLED3_SINK_REG_STR_CABC_ENBIT(7) + +/* WLED4 sink registers */ +#define WLED4_SINK_REG_CURR_SINK 0x46 +#define WLED4_SINK_REG_CURR_SINK_MASK GENMASK(7, 4) +#define WLED4_SINK_REG_CURR_SINK_SHFT 4 + +/* WLED4 per-'string' registers below */ +#define WLED4_SINK_REG_STR_MOD_EN(n) (0x50 + (n * 0x10)) +#define WLED4_SINK_REG_STR_MOD_MASK BIT(7) + +#define WLED4_SINK_REG_STR_FULL_SCALE_CURR(n) (0x52 + (n * 0x10)) +#define WLED4_SINK_REG_STR_FULL_SCALE_CURR_MASK GENMASK(3, 0) + +#define WLED4_SINK_REG_STR_MOD_SRC(n) (0x53 + (n * 0x10)) +#define WLED4_SINK_REG_STR_MOD_SRC_MASK BIT(0) +#define WLED4_SINK_REG_STR_MOD_SRC_INT0x00 +#define WLED4_SINK_REG_STR_MOD_SRC_EXT0x01 + +#define WLED4_SINK_REG_STR_CABC(n)
Re: [BUG 4.17] etnaviv-gpu f1840000.gpu: recover hung GPU!
On Tue, Jun 19, 2018 at 12:09:16PM +0200, Lucas Stach wrote: > Hi Russell, > > Am Dienstag, den 19.06.2018, 10:43 +0100 schrieb Russell King - ARM Linux: > > It looks like a bug has crept in to etnaviv between 4.16 and 4.17, > > which causes etnaviv to misbehave with the GC600 GPU on Dove. I > > don't think it's a GPU issue, I think it's a DRM issue. > > > > I get multiple: > > > > [ 596.711482] etnaviv-gpu f184.gpu: recover hung GPU! > > [ 597.732852] etnaviv-gpu f184.gpu: GPU failed to reset: FE not idle, > > 3D not idle, 2D not idle > > > > while Xorg is starting up. Ignore the "failed to reset", that > > just seems to be a property of the GC600, and of course is a > > subsequent issue after the primary problem. > > > > Looking at the devcoredump: > > > > 0004 = 00fe Idle: FE- DE+ PE+ SH+ PA+ SE+ RA+ TX+ VG- IM- FP- TS- > > > > So, all units on the GC600 were idle except for the front end. > > > > 0660 = 0812 Cmd: [wait DMA: idle Fetch: valid] Req idle Cal idle > > 0664 = 102d06d8 Command DMA address > > 0668 = 38c8 FE fetched word 0 > > 066c = 001f FE fetched word 1 > > > > The front end was basically idle at this point, at a WAIT 200 command. > > Digging through the ring: > > > > 00688: 08010e01 0040 LDST 0x3804=0x0040 > > 00690: 4002 102d06a0 LINK 0x102d06a0 > > 00698: 4002 102d0690 LINK 0x102d0690 > > 006a0: 08010e04 001f LDST 0x3810=0x001f > > 006a8: 4025 102d3000 LINK 0x102d3000 > > 006b0: 08010e03 0008 LDST 0x380c=0x0008 Flush PE2D > > 006b8: 08010e02 0701 LDST 0x3808=0x0701 SEM FE -> PE > > 006c0: 4800 0701 STALL FE -> PE > > 006c8: 08010e01 0041 LDST 0x3804=0x0041 > > 006d0: 38c8(001f) WAIT 200 > > > 006d8: 4002 102d06d0 LINK 0x102d06d0 <=== > > > > We've basically come to the end of the currently issued command stream > > and hit the wait-link loop. Everything else in the devcoredump looks > > normal. > > > > So, I think etnaviv DRM has missed an event signalled from the GPU. > > I don't see what would make us miss a event suddenly. > > > This worked fine in 4.16, so seems to be a regression. > > The only thing that comes to mind is that with the DRM scheduler we > enforce a job timeout of 500ms, without the previous logic to allow a > job to run indefinitely as long as it makes progress, as this is a > serious QoS issue. That is probably what's going on then - the GC600 is not particularly fast when dealing with 1080p resolutions. I think what your commit to use the DRM scheduler is missing is the progress detection in the original scheme - we used to assume that if the GPU FE DMA address had progressed, that the GPU was not hung. Now it seems we merely do this by checking for events. > This might bite you at this point, if Xorg manages to submit a really > big job. The coredump might be delayed enough that it captures the > state of the GPU when it has managed to finish the job after the job > timeout was hit. No, it's not "a really big job" - it's just that the Dove GC600 is not fast enough to complete _two_ 1080p sized GPU operations within 500ms. The preceeding job contained two blits - one of them a non-alphablend copy of: 0018 04200780 0,24,1920,1056 -> 0,24,1920,1056 and one an alpha blended copy of: 04380780 0,0,1920,1080 -> 0,0,1920,1080 This is (iirc) something I already fixed with the addition of the progress detection back before etnaviv was merged into the mainline kernel. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3 1/7] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c
pm8941-wled.c driver is supporting the WLED peripheral
on pm8941. Rename it to qcom-wled.c so that it can support
WLED on multiple PMICs.
Signed-off-by: Kiran Gunda
---
.../bindings/leds/backlight/{pm8941-wled.txt => qcom-wled.txt}| 2 +-
drivers/video/backlight/Kconfig | 8
drivers/video/backlight/Makefile | 2 +-
drivers/video/backlight/{pm8941-wled.c => qcom-wled.c}| 0
4 files changed, 6 insertions(+), 6 deletions(-)
rename Documentation/devicetree/bindings/leds/backlight/{pm8941-wled.txt =>
qcom-wled.txt} (95%)
rename drivers/video/backlight/{pm8941-wled.c => qcom-wled.c} (100%)
diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
similarity index 95%
rename from Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
rename to Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
index e5b294d..fb39e32 100644
--- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,4 +1,4 @@
-Binding for Qualcomm PM8941 WLED driver
+Binding for Qualcomm Technologies, Inc. WLED driver
Required properties:
- compatible: should be "qcom,pm8941-wled"
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 4e1d2ad..8c095e3 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -299,12 +299,12 @@ config BACKLIGHT_TOSA
If you have an Sharp SL-6000 Zaurus say Y to enable a driver
for its backlight
-config BACKLIGHT_PM8941_WLED
- tristate "Qualcomm PM8941 WLED Driver"
+config BACKLIGHT_QCOM_WLED
+ tristate "Qualcomm PMIC WLED Driver"
select REGMAP
help
- If you have the Qualcomm PM8941, say Y to enable a driver for the
- WLED block.
+ If you have the Qualcomm PMIC, say Y to enable a driver for the
+ WLED block. Currently it supports PM8941 and PMI8998.
config BACKLIGHT_SAHARA
tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 5e28f01..6fd76ef 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -49,8 +49,8 @@ obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
obj-$(CONFIG_BACKLIGHT_OT200) += ot200_bl.o
obj-$(CONFIG_BACKLIGHT_PANDORA)+= pandora_bl.o
obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
-obj-$(CONFIG_BACKLIGHT_PM8941_WLED)+= pm8941-wled.o
obj-$(CONFIG_BACKLIGHT_PWM)+= pwm_bl.o
+obj-$(CONFIG_BACKLIGHT_QCOM_WLED) += qcom-wled.o
obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
diff --git a/drivers/video/backlight/pm8941-wled.c
b/drivers/video/backlight/qcom-wled.c
similarity index 100%
rename from drivers/video/backlight/pm8941-wled.c
rename to drivers/video/backlight/qcom-wled.c
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/panel: Add support for the EDT ETM0700G0EDH6
From: Jan Tuerk
The Emerging Display Technology ETM0700G0EDH6 is the
uses the same panel as the ETM0700G0BDH6. It differs
in the hardware design for the backlight and the
touchscreen i2c interface. As the new display type has
different requirements for drive-strengths on the i2c-bus,
add an additional compatible to allow the handling of it or warn
about incompatible cpu and display combinations.
Signed-off-by: Jan Tuerk
---
drivers/gpu/drm/panel/panel-simple.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 8b7feb2888f2..2eed60134fa3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2148,6 +2148,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "edt,etm0700g0bdh6",
.data = _etm0700g0bdh6,
+ }, {
+ .compatible = "edt,etm0700g0edh6",
+ .data = _etm0700g0bdh6,
}, {
.compatible = "foxlink,fl500wvr00-a0t",
.data = _fl500wvr00_a0t,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106957] GPU runtime suspend broken since 4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106957 --- Comment #2 from p...@cooco.de --- # cat /sys/bus/pci/devices/:02:00.0/power/control # GPU auto # cat /sys/bus/pci/devices/:02:00.0/power/runtime_status# GPU active # cat /sys/bus/pci/devices/:02:00.0/power/runtime_usage # GPU cat: '/sys/bus/pci/devices/:02:00.0/power/runtime_usage': No such file or directory # cat /sys/bus/pci/devices/:02:00.0/power/runtime_active_kids # GPU cat: '/sys/bus/pci/devices/:02:00.0/power/runtime_active_kids': No such file or directory # cat /sys/bus/pci/devices/:02:00.1/power/control # HDA auto # cat /sys/bus/pci/devices/:02:00.1/power/runtime_status# HDA active # cat /sys/bus/pci/devices/:02:00.1/power/runtime_usage # HDA cat: '/sys/bus/pci/devices/:02:00.1/power/runtime_usage': No such file or directory # cat /sys/bus/pci/devices/:02:00.1/power/runtime_active_kids # HDA cat: '/sys/bus/pci/devices/:02:00.1/power/runtime_active_kids': No such file or directory # ls -l /sys/bus/pci/devices/:02:00.1/driver lrwxrwxrwx 1 root root 0 Jun 19 18:04 /sys/bus/pci/devices/:02:00.1/driver -> ../../../../bus/pci/drivers/snd_hda_intel -- 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] RFC: drm/atomic-helpers: remove legacy_cursor_update hacks
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.
For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit hooks. Support for that
for msm and vc4 landed. nouveau and i915 have their own commit
routines, doing something similar.
For everyone else it's probably better to remove the use-after-free
bug, and encourage folks to use the async support instead. The
affected drivers which register a legacy cursor plane and don't either
use the new async stuff or their own commit routine are: amdgpu,
atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.
Inspired by an amdgpu bug report.
References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
Cc: mikita.lip...@amd.com
Cc: Michel Dänzer
Cc: harry.wentl...@amd.com
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 130da5195f3b..5a576cdf26dd 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1330,13 +1330,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
*dev,
int i, ret;
unsigned crtc_mask = 0;
-/*
- * Legacy cursor ioctls are completely unsynced, and userspace
- * relies on that (by doing tons of cursor updates).
- */
- if (old_state->legacy_cursor_update)
- return;
-
for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
new_crtc_state, i) {
if (!new_crtc_state->active)
continue;
@@ -1884,12 +1877,6 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
continue;
}
- /* Legacy cursor updates are fully unsynced. */
- if (state->legacy_cursor_update) {
- complete_all(>flip_done);
- continue;
- }
-
if (!new_crtc_state->event) {
commit->event = kzalloc(sizeof(*commit->event),
GFP_KERNEL);
--
2.18.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: use atomic helper function to get crtc_state of crtc
On Tue, Jun 19, 2018 at 05:27:57PM +0200, Daniel Vetter wrote:
> On Tue, Jun 19, 2018 at 10:45:31AM -0400, mikita.lip...@amd.com wrote:
> > From: Mikita Lipski
> >
> > Use drm_atomic_get_crtc_state to get the crtc state in case
> > it has been previously freed, that might prevent use-after-free issue.
> >
> > This patch fixes the bugzilla bug:
> > Bug 199425 - BUG: KASAN: use-after-free in
> > drm_atomic_helper_wait_for_flip_done+0x247/0x260
> >
> > Signed-off-by: Mikita Lipski
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index e8c2493..e083f85 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1276,9 +1276,11 @@ void drm_atomic_helper_wait_for_flip_done(struct
> > drm_device *dev,
> > int i;
> >
> > for_each_new_crtc_in_state(old_state, crtc, new_crtc_state, i) {
> > - struct drm_crtc_commit *commit = new_crtc_state->commit;
> > + struct drm_crtc_commit *commit;
> > int ret;
> >
> > + new_crtc_state = drm_atomic_get_crtc_state(old_state, crtc);
> > + commit = new_crtc_state->commit;
>
> Uh no. wait_for_flip done is supposed to be called from the
> ->atomic_commit hook, and duplicating state objects (as is done by the
> various get_foo_state functions) is only allowed from the ->atomic_check
> hook. What that blows up for you, this isn't the fix you're looking for.
> Aside: get_foo_state can fail, the __must_check annotation should have
> been a hint for that.
>
> For starters it would be useful if you include the full details of what's
> going boom in the amdgpu driver for you.
From a quick glance at the bug report it looks like a cursor update
getting ahead of a page flip.
Actually I'm not even sure how this manages to work on i915. On i915
we allow the cursor update to go through as soon as hw_done is
completed. That would seem to mean that all the cleanup work
commit_tail does afterwards is at risk of using a freed plane state.
Well, maybe. The way this is all implemented doesn't really agree
with my brain so I can't be 100% sure.
Whacking a big sleep just after drm_atomic_helper_commit_hw_done()
should be able to confirm that I suppose.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays
Den 05.06.2018 17.49, skrev Noralf Trønnes: (cc: drm-misc maintainers) Den 04.06.2018 03.21, skrev David Lechner: On 6/3/18 5:00 PM, Noralf Trønnes wrote: Den 25.05.2018 21.36, skrev David Lechner: This series adds a new tinydrm driver for the Ilitek ILI9341 controller and a 2.4" display panel that uses this controller. David, do you have commit rights now? No. Opened a bug a while back to request access, but I guess the right person didn't see it. https://bugs.freedesktop.org/show_bug.cgi?id=105166 Could someone please look at this? David, let's not stall this, if you resend with fixed up commit message and acks/rbs, I'll apply it. Noralf. Noralf. Noralf. A few things to note here: * The datasheet for this display[1] doesn't have a vendor mentioned on it anywhere, so I have used "adafruit" as the vendor prefix. If someone has a better suggestion, please speak up. * The MAINTAINERS patch for ili9225 is included so we don't end up with a merge conflict later on. v2 changes: * change vendor prefix from "noname" to "adafruit" * new patch for "adafruit" vendor prefix * minor style changes * drop regulator from driver (instead of adding to DT bindings) [1]: https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf David Lechner (4): MAINTAINERS: fix path to ilitek,ili9225 device tree bindings dt-bindings: Add vendor prefix for Adafruit dt-bindings: new binding for Ilitek ILI9341 display panels drm/tinydrm: new driver for ILI9341 display panels .../bindings/display/ilitek,ili9341.txt | 27 ++ .../devicetree/bindings/vendor-prefixes.txt | 1 + MAINTAINERS | 8 +- drivers/gpu/drm/tinydrm/Kconfig | 10 + drivers/gpu/drm/tinydrm/Makefile | 1 + drivers/gpu/drm/tinydrm/ili9341.c | 233 ++ 6 files changed, 279 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] dma-buf: remove kmap_atomic interface
On Tue, Jun 19, 2018 at 4:47 PM, Christian König
wrote:
> Am 18.06.2018 um 10:18 schrieb Daniel Vetter:
>>
>> On Fri, Jun 01, 2018 at 02:00:17PM +0200, Christian König wrote:
>>>
>>> Neither used nor correctly implemented anywhere. Just completely remove
>>> the interface.
>>>
>>> Signed-off-by: Christian König
>>
>> I wonder whether we can nuke the normal kmap stuff too ... everyone seems
>> to want/use the vmap stuff for kernel-internal mapping needs.
>>
>> Anyway, this looks good.
>>>
>>> ---
>>> drivers/dma-buf/dma-buf.c | 44
>>> --
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 2 -
>>> drivers/gpu/drm/armada/armada_gem.c| 2 -
>>> drivers/gpu/drm/drm_prime.c| 26 -
>>> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 11 --
>>> drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 2 -
>>> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 -
>>> drivers/gpu/drm/tegra/gem.c| 14 ---
>>> drivers/gpu/drm/udl/udl_dmabuf.c | 17 -
>>> drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 13 ---
>>> .../media/common/videobuf2/videobuf2-dma-contig.c | 1 -
>>> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 1 -
>>> drivers/media/common/videobuf2/videobuf2-vmalloc.c | 1 -
>>> drivers/staging/android/ion/ion.c | 2 -
>>> drivers/tee/tee_shm.c | 6 ---
>>> include/drm/drm_prime.h| 4 --
>>> include/linux/dma-buf.h| 4 --
>>> 17 files changed, 152 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index e99a8d19991b..e4c657d9fad7 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -405,7 +405,6 @@ struct dma_buf *dma_buf_export(const struct
>>> dma_buf_export_info *exp_info)
>>> || !exp_info->ops->map_dma_buf
>>> || !exp_info->ops->unmap_dma_buf
>>> || !exp_info->ops->release
>>> - || !exp_info->ops->map_atomic
>>> || !exp_info->ops->map
>>> || !exp_info->ops->mmap)) {
>>> return ERR_PTR(-EINVAL);
>>> @@ -687,14 +686,6 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>>>* void \*dma_buf_kmap(struct dma_buf \*, unsigned long);
>>>* void dma_buf_kunmap(struct dma_buf \*, unsigned long, void \*);
>>>*
>>> - * There are also atomic variants of these interfaces. Like for kmap
>>> they
>>> - * facilitate non-blocking fast-paths. Neither the importer nor the
>>> exporter
>>> - * (in the callback) is allowed to block when using these.
>>> - *
>>> - * Interfaces::
>>> - * void \*dma_buf_kmap_atomic(struct dma_buf \*, unsigned long);
>>> - * void dma_buf_kunmap_atomic(struct dma_buf \*, unsigned long,
>>> void \*);
>>> - *
>>>* For importers all the restrictions of using kmap apply, like the
>>> limited
>>>* supply of kmap_atomic slots. Hence an importer shall only hold
>>> onto at
>>>* max 2 atomic dma_buf kmaps at the same time (in any given process
>>> context).
>>
>> This is also about atomic kmap ...
>>
>> And the subsequent language around "Note that these calls need to always
>> succeed." is also not true, might be good to update that stating that kmap
>> is optional (like we say already for vmap).
>>
>> With those docs nits addressed:
>>
>> Reviewed-by: Daniel Vetter
>
>
> I've fixed up patch #1 and #2 and added your Reviewed-by tag.
>
> Since I finally had time to install dim do you have any objections that I
> now run "dim push drm-misc-next" with those two applied?
Go ahead, that's the point of commit rights. dim might complain if you
cherry picked them and didn't pick them up using dim apply though ...
-Daniel
> Regards,
> Christian.
>
>
>>
>>> @@ -859,41 +850,6 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>>> }
>>> EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
>>> -/**
>>> - * dma_buf_kmap_atomic - Map a page of the buffer object into kernel
>>> address
>>> - * space. The same restrictions as for kmap_atomic and friends apply.
>>> - * @dmabuf:[in]buffer to map page from.
>>> - * @page_num: [in]page in PAGE_SIZE units to map.
>>> - *
>>> - * This call must always succeed, any necessary preparations that might
>>> fail
>>> - * need to be done in begin_cpu_access.
>>> - */
>>> -void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long
>>> page_num)
>>> -{
>>> - WARN_ON(!dmabuf);
>>> -
>>> - return dmabuf->ops->map_atomic(dmabuf, page_num);
>>> -}
>>> -EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
>>> -
>>> -/**
>>> - * dma_buf_kunmap_atomic - Unmap a page obtained by dma_buf_kmap_atomic.
>>> - * @dmabuf:[in]buffer to unmap page from.
>>> - * @page_num:
Re: [PATCH] drm: use atomic helper function to get crtc_state of crtc
On Tue, Jun 19, 2018 at 10:45:31AM -0400, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> Use drm_atomic_get_crtc_state to get the crtc state in case
> it has been previously freed, that might prevent use-after-free issue.
>
> This patch fixes the bugzilla bug:
> Bug 199425 - BUG: KASAN: use-after-free in
> drm_atomic_helper_wait_for_flip_done+0x247/0x260
>
> Signed-off-by: Mikita Lipski
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index e8c2493..e083f85 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1276,9 +1276,11 @@ void drm_atomic_helper_wait_for_flip_done(struct
> drm_device *dev,
> int i;
>
> for_each_new_crtc_in_state(old_state, crtc, new_crtc_state, i) {
> - struct drm_crtc_commit *commit = new_crtc_state->commit;
> + struct drm_crtc_commit *commit;
> int ret;
>
> + new_crtc_state = drm_atomic_get_crtc_state(old_state, crtc);
> + commit = new_crtc_state->commit;
Uh no. wait_for_flip done is supposed to be called from the
->atomic_commit hook, and duplicating state objects (as is done by the
various get_foo_state functions) is only allowed from the ->atomic_check
hook. What that blows up for you, this isn't the fix you're looking for.
Aside: get_foo_state can fail, the __must_check annotation should have
been a hint for that.
For starters it would be useful if you include the full details of what's
going boom in the amdgpu driver for you.
-Daniel
> if (!commit)
> continue;
>
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] drm: Replace drm_dev_unref with drm_dev_put
On Sat, Jun 9, 2018 at 9:18 AM, Thomas Zimmermann wrote: > This patch unifies the naming of DRM functions for reference counting > of struct drm_device. The resulting code is more aligned with the rest > of the Linux kernel interfaces. > > The patch also deletes the old function and removes it from the > Coccinelle script. > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4 ++-- > drivers/gpu/drm/arc/arcpgu_drv.c | 8 > drivers/gpu/drm/armada/armada_drv.c| 6 +++--- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 8 > drivers/gpu/drm/drm_drv.c | 13 - > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 8 > drivers/gpu/drm/exynos/exynos_drm_drv.c| 4 ++-- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 8 > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c| 4 ++-- > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c| 8 > drivers/gpu/drm/i915/selftests/huge_pages.c| 2 +- > drivers/gpu/drm/i915/selftests/i915_gem_context.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_gem_evict.c| 2 +- > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_gem_object.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_request.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- > drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 2 +- > drivers/gpu/drm/imx/imx-drm-core.c | 8 > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +++--- > drivers/gpu/drm/msm/msm_drv.c | 8 > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_platform.c | 2 +- > drivers/gpu/drm/omapdrm/omap_drv.c | 4 ++-- > drivers/gpu/drm/pl111/pl111_drv.c | 14 +++--- > drivers/gpu/drm/qxl/qxl_drv.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- > drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 4 ++-- > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 ++-- > drivers/gpu/drm/sti/sti_drv.c | 8 > drivers/gpu/drm/stm/drv.c | 10 +- > drivers/gpu/drm/sun4i/sun4i_drv.c | 4 ++-- > drivers/gpu/drm/tegra/drm.c| 8 > drivers/gpu/drm/tinydrm/core/tinydrm-core.c| 6 +++--- > drivers/gpu/drm/tve200/tve200_drv.c| 10 +- > drivers/gpu/drm/udl/udl_drv.c | 2 +- > drivers/gpu/drm/vc4/vc4_drv.c | 8 > drivers/gpu/drm/vgem/vgem_drv.c| 2 +- > drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 2 +- > drivers/gpu/drm/zte/zx_drm_drv.c | 4 ++-- > include/drm/drm_drv.h | 1 - > scripts/coccinelle/api/drm-get-put.cocci | 3 --- > 43 files changed, 99 insertions(+), 116 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > index b0bf2f24da48..cf5b18e7d8db 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -664,7 +664,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev, > err_pci: > pci_disable_device(pdev); > err_free: > - drm_dev_unref(dev); > + drm_dev_put(dev); > return ret; > } > > @@ -674,7 +674,7 @@ amdgpu_pci_remove(struct pci_dev *pdev) > struct drm_device *dev = pci_get_drvdata(pdev); > > drm_dev_unregister(dev); > - drm_dev_unref(dev); > + drm_dev_put(dev); > pci_disable_device(pdev); > pci_set_drvdata(pdev, NULL); > } For amdgpu: Acked-by: Alex Deucher ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: use atomic helper function to get crtc_state of crtc
Hi Mikita, thanks for sending this out. I have to defer review of the actual change to others more familiar with this code, but I have some feedback for the commit log. On 2018-06-19 04:45 PM, mikita.lip...@amd.com wrote: > From: Mikita Lipski > > Use drm_atomic_get_crtc_state to get the crtc state in case > it has been previously freed, that might prevent use-after-free issue. > > This patch fixes the bugzilla bug: > Bug 199425 - BUG: KASAN: use-after-free in > drm_atomic_helper_wait_for_flip_done+0x247/0x260 Bug reports are referenced like this: Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Also, as the issue exists since at least 4.17, this should have Cc: sta...@vger.kernel.org in order for the fix to be backported to stable branches. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] dma-buf: remove kmap_atomic interface
Am 18.06.2018 um 10:18 schrieb Daniel Vetter:
On Fri, Jun 01, 2018 at 02:00:17PM +0200, Christian König wrote:
Neither used nor correctly implemented anywhere. Just completely remove
the interface.
Signed-off-by: Christian König
I wonder whether we can nuke the normal kmap stuff too ... everyone seems
to want/use the vmap stuff for kernel-internal mapping needs.
Anyway, this looks good.
---
drivers/dma-buf/dma-buf.c | 44 --
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 2 -
drivers/gpu/drm/armada/armada_gem.c| 2 -
drivers/gpu/drm/drm_prime.c| 26 -
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 11 --
drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 2 -
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 -
drivers/gpu/drm/tegra/gem.c| 14 ---
drivers/gpu/drm/udl/udl_dmabuf.c | 17 -
drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 13 ---
.../media/common/videobuf2/videobuf2-dma-contig.c | 1 -
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 1 -
drivers/media/common/videobuf2/videobuf2-vmalloc.c | 1 -
drivers/staging/android/ion/ion.c | 2 -
drivers/tee/tee_shm.c | 6 ---
include/drm/drm_prime.h| 4 --
include/linux/dma-buf.h| 4 --
17 files changed, 152 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index e99a8d19991b..e4c657d9fad7 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -405,7 +405,6 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
|| !exp_info->ops->map_dma_buf
|| !exp_info->ops->unmap_dma_buf
|| !exp_info->ops->release
- || !exp_info->ops->map_atomic
|| !exp_info->ops->map
|| !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
@@ -687,14 +686,6 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
* void \*dma_buf_kmap(struct dma_buf \*, unsigned long);
* void dma_buf_kunmap(struct dma_buf \*, unsigned long, void \*);
*
- * There are also atomic variants of these interfaces. Like for kmap they
- * facilitate non-blocking fast-paths. Neither the importer nor the exporter
- * (in the callback) is allowed to block when using these.
- *
- * Interfaces::
- * void \*dma_buf_kmap_atomic(struct dma_buf \*, unsigned long);
- * void dma_buf_kunmap_atomic(struct dma_buf \*, unsigned long, void \*);
- *
* For importers all the restrictions of using kmap apply, like the limited
* supply of kmap_atomic slots. Hence an importer shall only hold onto at
* max 2 atomic dma_buf kmaps at the same time (in any given process
context).
This is also about atomic kmap ...
And the subsequent language around "Note that these calls need to always
succeed." is also not true, might be good to update that stating that kmap
is optional (like we say already for vmap).
With those docs nits addressed:
Reviewed-by: Daniel Vetter
I've fixed up patch #1 and #2 and added your Reviewed-by tag.
Since I finally had time to install dim do you have any objections that
I now run "dim push drm-misc-next" with those two applied?
Regards,
Christian.
@@ -859,41 +850,6 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
}
EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
-/**
- * dma_buf_kmap_atomic - Map a page of the buffer object into kernel address
- * space. The same restrictions as for kmap_atomic and friends apply.
- * @dmabuf:[in]buffer to map page from.
- * @page_num: [in]page in PAGE_SIZE units to map.
- *
- * This call must always succeed, any necessary preparations that might fail
- * need to be done in begin_cpu_access.
- */
-void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long page_num)
-{
- WARN_ON(!dmabuf);
-
- return dmabuf->ops->map_atomic(dmabuf, page_num);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
-
-/**
- * dma_buf_kunmap_atomic - Unmap a page obtained by dma_buf_kmap_atomic.
- * @dmabuf:[in]buffer to unmap page from.
- * @page_num: [in]page in PAGE_SIZE units to unmap.
- * @vaddr: [in]kernel space pointer obtained from dma_buf_kmap_atomic.
- *
- * This call must always succeed.
- */
-void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned long page_num,
- void *vaddr)
-{
- WARN_ON(!dmabuf);
-
- if (dmabuf->ops->unmap_atomic)
- dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
-
/**
* dma_buf_kmap - Map a page of the buffer object into kernel address space.
The
* same restrictions as for kmap and friends
[PATCH] drm: use atomic helper function to get crtc_state of crtc
From: Mikita Lipski
Use drm_atomic_get_crtc_state to get the crtc state in case
it has been previously freed, that might prevent use-after-free issue.
This patch fixes the bugzilla bug:
Bug 199425 - BUG: KASAN: use-after-free in
drm_atomic_helper_wait_for_flip_done+0x247/0x260
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index e8c2493..e083f85 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1276,9 +1276,11 @@ void drm_atomic_helper_wait_for_flip_done(struct
drm_device *dev,
int i;
for_each_new_crtc_in_state(old_state, crtc, new_crtc_state, i) {
- struct drm_crtc_commit *commit = new_crtc_state->commit;
+ struct drm_crtc_commit *commit;
int ret;
+ new_crtc_state = drm_atomic_get_crtc_state(old_state, crtc);
+ commit = new_crtc_state->commit;
if (!commit)
continue;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [DPU PATCH] drm/msm/dsi: add only dsi nodes with a valid device to list
On Mon, Jun 18, 2018 at 03:11:44PM -0700, abhin...@codeaurora.org wrote:
> Hi Jordan
>
> Thanks for the review.
>
> Comments inline.
>
> Abhinav
> On 2018-06-18 07:23, Jordan Crouse wrote:
> >On Fri, Jun 15, 2018 at 11:05:57PM -0700, Abhinav Kumar wrote:
> >>Before adding a DSI node to the private list check if the
> >>node has a valid device connected to it through an endpoint.
> >>
> >>This is required in cases where the chipset supports multiple
> >>DSI hosts but only one of them is being used.
> >>
> >>In the current implementation even inactive nodes get added
> >>resulting in creation of redundant connectors.
> >>
> >>Signed-off-by: Abhinav Kumar
> >>---
> >> drivers/gpu/drm/msm/dsi/dsi.c | 6 +-
> >> drivers/gpu/drm/msm/dsi/dsi.h | 1 +
> >> drivers/gpu/drm/msm/dsi/dsi_host.c | 10 ++
> >> 3 files changed, 16 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/gpu/drm/msm/dsi/dsi.c
> >>b/drivers/gpu/drm/msm/dsi/dsi.c
> >>index b744bcc..46a4906 100644
> >>--- a/drivers/gpu/drm/msm/dsi/dsi.c
> >>+++ b/drivers/gpu/drm/msm/dsi/dsi.c
> >>@@ -120,7 +120,11 @@ static int dsi_bind(struct device *dev,
> >>struct device *master, void *data)
> >>if (IS_ERR(msm_dsi))
> >>return PTR_ERR(msm_dsi);
> >>
> >>- priv->dsi[msm_dsi->id] = msm_dsi;
> >>+ /* Add only the host which has a device attached to it */
> >>+ if (msm_dsi_has_valid_device(msm_dsi->host)) {
> >>+ pr_info("id = %d has valid device\n", msm_dsi->id);
> >
> >This seems like a debug message that slipped through.
> [Abhinav] No, this was intentionally added. This will be printed
> only at probe and at most 2 times.
> This gives the information about how many devices have been initialized.
If that is the case then it should be properly constructed. It should use
dev_info like the rest of the messages in this file and it should be written
in simple present tense with the end user in mind as an audience.
Something like:
dev_info(dev, "DSI device %d is valid\n", msm_dsi->id);
or
dev_info(dev, ""DSI device %d is initialized\n", msm_dsi->id);
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106363] Powerplay support for SI asics
https://bugs.freedesktop.org/show_bug.cgi?id=106363 --- Comment #3 from Alex Deucher --- dpm is enabled by default on SI parts so setting dpm=1 doesn't change anything. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106363] Powerplay support for SI asics
https://bugs.freedesktop.org/show_bug.cgi?id=106363 --- Comment #2 from Michel Dänzer --- (In reply to Gregor Münch from comment #1) > DPMS, Suspend to Disk all is working fine. Neither DPMS nor suspend to disk has anything to do with PowerPlay (or DPM) though. :) -- 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 106363] Powerplay support for SI asics
https://bugs.freedesktop.org/show_bug.cgi?id=106363 --- Comment #1 from Gregor Münch --- Im on Tahiti and I just append amdgpu.dpm=1 to my kernel config and things started working. DPMS, Suspend to Disk all is working fine. -- 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 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 Joern Hoffmann (j.hoffm...@quapona.com) changed: What|Removed |Added CC||j.hoffm...@quapona.com --- Comment #26 from Joern Hoffmann (j.hoffm...@quapona.com) --- For me, it works to. dmesg | grep amdgpu: [3.437098] [drm] amdgpu kernel modesetting enabled. [3.442103] fb: switching to amdgpudrmfb from EFI VGA [3.442234] amdgpu :01:00.0: enabling device (0006 -> 0007) [3.443795] amdgpu :01:00.0: BAR 2: releasing [mem 0xd000-0xd01f 64bit pref] [3.443797] amdgpu :01:00.0: BAR 0: releasing [mem 0xc000-0xcfff 64bit pref] [3.443822] amdgpu :01:00.0: BAR 0: assigned [mem 0x22-0x23 64bit pref] [3.443827] amdgpu :01:00.0: BAR 2: assigned [mem 0x21-0x21001f 64bit pref] [3.443849] amdgpu :01:00.0: VRAM: 8192M 0x00F4 - 0x00F5 (8192M used) [3.443850] amdgpu :01:00.0: GTT: 256M 0x - 0x0FFF [3.443917] [drm] amdgpu: 8192M of VRAM memory ready [3.443918] [drm] amdgpu: 8192M of GTT memory ready. [4.239650] fbcon: amdgpudrmfb (fb0) is primary device [4.323338] amdgpu :01:00.0: fb0: amdgpudrmfb frame buffer device [4.340440] [drm] Initialized amdgpu 3.25.0 20150101 for :01:00.0 on minor 0 [ 10.704309] amdgpu :01:00.0: a78be373 unpin not necessary [ 10.704310] amdgpu :01:00.0: a78be373 unpin not necessary [ 10.704310] amdgpu :01:00.0: 6047af5e unpin not necessary [ 10.704311] amdgpu :01:00.0: 2d9a27ec unpin not necessary [ 11.443673] amdgpu :01:00.0: Test 0 from 8 to 13 -- 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 200139] amdgpu lockup after resume from sleep
https://bugzilla.kernel.org/show_bug.cgi?id=200139 Christian König (christian.koe...@amd.com) changed: What|Removed |Added CC||christian.koe...@amd.com --- Comment #1 from Christian König (christian.koe...@amd.com) --- Duplicate of bug https://bugzilla.kernel.org/show_bug.cgi?id=199959 -- 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 200139] New: amdgpu lockup after resume from sleep
https://bugzilla.kernel.org/show_bug.cgi?id=200139 Bug ID: 200139 Summary: amdgpu lockup after resume from sleep Product: Drivers Version: 2.5 Kernel Version: 4.17.2 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: j.hoffm...@quapona.com Regression: No Created attachment 276689 --> https://bugzilla.kernel.org/attachment.cgi?id=276689=edit HWInfo I have observed a GPU lockup when the systems resumes after a sleep. The duration of the sleep dosn't care. The problem occurs every time putting the system to sleep. I was able to narrow the problem a little bit. When I switch to the console and then putting the system to sleep, the system will come up properly (with a trace on a amgpu fuction). If I then switch back to the login manager or to the desktop, the gpu fault and eventually hangs. See logs below. I can reproduce the problem with kernel 4.16.13. Further it dosn't matter if amdgpu.dc is enabled or disable. System -- Linux 4.17.2 Debian Unstable X.Org 1.20 Mesa 18.1.1 Radeon RX 580 Series (POLARIS10, DRM 3.25.0, 4.17.2, LLVM 6.0.0) CPU Intel Core i7-8700k MB Asus Prime z380-A Kernel log after the resume from console: - Jun 19 14:24:39 moc kernel: sd 0:0:0:0: [sda] Starting disk Jun 19 14:24:39 moc kernel: [drm] PCIE GART of 256M enabled (table at 0x00F40004). Jun 19 14:24:39 moc kernel: WARNING: CPU: 7 PID: 28047 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:725 amdgpu_dm_display_resume+0x213/0x220 [amdgpu] Jun 19 14:24:39 moc kernel: Modules linked in: vmnet(OE) vmw_vsock_vmci_transport(E) vsock(E) vmw_vmci(E) vmmon(OE) fuse(E) joydev(E) hid_cherry(E) hid_generic(E) usbhid(E) hid(E) intel_rapl(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) ir Jun 19 14:24:39 moc kernel: asus_wmi(E) evdev(E) efi_pstore(E) intel_uncore(E) sparse_keymap(E) wmi_bmof(E) mxm_wmi(E) i2c_algo_bit(E) rfkill(E) sg(E) intel_rapl_perf(E) iTCO_wdt(E) efivars(E) snd(E) mei_me(E) iTCO_vendor_support(E) soundcore(E) mei(E) shpchp(E) wmi(E) v Jun 19 14:24:39 moc kernel: btrfs(E) zstd_decompress(E) zstd_compress(E) xxhash(E) raid10(E) raid456(E) async_raid6_recov(E) async_memcpy(E) async_pq(E) async_xor(E) async_tx(E) xor(E) raid6_pq(E) libcrc32c(E) crc32c_generic(E) raid1(E) raid0(E) multipath(E) linear(E) md Jun 19 14:24:39 moc kernel: CPU: 7 PID: 28047 Comm: kworker/u24:7 Tainted: G OE 4.17.2 #1 Jun 19 14:24:39 moc kernel: Hardware name: System manufacturer System Product Name/PRIME Z370-A, BIOS 0805 05/18/2018 Jun 19 14:24:39 moc kernel: Workqueue: events_unbound async_run_entry_fn Jun 19 14:24:39 moc kernel: RIP: 0010:amdgpu_dm_display_resume+0x213/0x220 [amdgpu] Jun 19 14:24:39 moc kernel: RSP: :aadd4447fd60 EFLAGS: 00010202 Jun 19 14:24:39 moc kernel: RAX: 0002 RBX: 96d7a48b RCX: 0006 Jun 19 14:24:39 moc kernel: RDX: 0006 RSI: 96d6915a2c80 RDI: 96d7898f7800 Jun 19 14:24:39 moc kernel: RBP: 96d79fb9d800 R08: R09: c14a7174 Jun 19 14:24:39 moc kernel: R10: e4dea0a9a840 R11: 0001 R12: Jun 19 14:24:39 moc kernel: R13: 96d7a5e43800 R14: 96d7a9ca8d40 R15: b4695dbb Jun 19 14:24:39 moc kernel: FS: () GS:96d7ae3c() knlGS: Jun 19 14:24:39 moc kernel: CS: 0010 DS: ES: CR0: 80050033 Jun 19 14:24:39 moc kernel: CR2: CR3: 0003aa80a001 CR4: 003606e0 Jun 19 14:24:39 moc kernel: DR0: DR1: DR2: Jun 19 14:24:39 moc kernel: DR3: DR6: fffe0ff0 DR7: 0400 Jun 19 14:24:39 moc kernel: Call Trace: Jun 19 14:24:39 moc kernel: amdgpu_device_ip_resume_phase2+0x45/0xb0 [amdgpu] Jun 19 14:24:39 moc kernel: amdgpu_device_resume+0xbf/0x380 [amdgpu] Jun 19 14:24:39 moc kernel: ? pci_pm_freeze+0xd0/0xd0 Jun 19 14:24:39 moc kernel: ? pci_pm_freeze+0xd0/0xd0 Jun 19 14:24:39 moc kernel: dpm_run_callback+0x4d/0x130 Jun 19 14:24:39 moc kernel: device_resume+0x97/0x190 Jun 19 14:24:39 moc kernel: async_resume+0x19/0x40 Jun 19 14:24:39 moc kernel: async_run_entry_fn+0x39/0x160 Jun 19 14:24:39 moc kernel: process_one_work+0x17b/0x360 Jun 19 14:24:39 moc kernel: worker_thread+0x2e/0x390 Jun 19 14:24:39 moc kernel: ? process_one_work+0x360/0x360 Jun 19 14:24:39 moc kernel: kthread+0x113/0x130 Jun 19 14:24:39 moc kernel: ? kthread_create_worker_on_cpu+0x70/0x70 Jun 19 14:24:39 moc kernel: ret_from_fork+0x35/0x40 Jun 19 14:24:39 moc kernel: Code: 00 7f ac 48 89 ef e8 dd df a5 ff 48 c7 83 90 aa 00 00 00 00 00 00 89 c5 48 89 df e8 c8 17 00 00
Re: [BUG 4.17] etnaviv-gpu f1840000.gpu: recover hung GPU!
Am Dienstag, den 19.06.2018, 12:42 +0100 schrieb Russell King - ARM Linux:
> On Tue, Jun 19, 2018 at 01:11:29PM +0200, Lucas Stach wrote:
> > Am Dienstag, den 19.06.2018, 12:00 +0100 schrieb Russell King - ARM Linux:
> > > No, it's not "a really big job" - it's just that the Dove GC600 is not
> > > fast enough to complete _two_ 1080p sized GPU operations within 500ms.
> > > The preceeding job contained two blits - one of them a non-alphablend
> > > copy of:
> > >
> > > 0018 04200780 0,24,1920,1056 -> 0,24,1920,1056
> > >
> > > and one an alpha blended copy of:
> > >
> > > 04380780 0,0,1920,1080 -> 0,0,1920,1080
> > >
> > > This is (iirc) something I already fixed with the addition of the
> > > progress detection back before etnaviv was merged into the mainline
> > > kernel.
> >
> > I hadn't expected it to be this slow. I see that we might need to bring
> > back the progress detection to fix the userspace regression, but I'm
> > not fond of this, as it might lead to really bad QoS.
>
> Well, the choices are that or worse overall performance through having
> to ignore the GPU entirely.
>
> > I would prefer userspace tracking the size of the blits and flushing
> > the cmdstream at an appropriate time, so we don't end up with really
> > long running jobs, but I'm not sure if this would be acceptable to
> > you...
>
> The question becomes how to split up two operations. Yes, we could
> submit them individually, but if they're together taking in excess of
> 500ms, then it's likely that individually, each operation will take in
> excess of 250ms which is still a long time.
>
> In any case, I think we need to fix this for 4.17-stable and then try
> to work (a) which operations are taking a long time, and (b) how to
> solve this issue.
Agreed. I'll look into bringing back the process detection for 4.17
stable.
I'm still curious why the GC600 on the Dove is that slow. With
performance like this moving a big(ish) window on the screen must be a
horrible user experience.
> Do we have any way to track how long each submitted job has actually
> taken on the GPU? (Eg, by recording the times that we receive the
> events?) It wouldn't be very accurate for small jobs, but given this
> operation is taking so long, it would give an indication of how long
> this operation is actually taking. etnaviv doesn't appear to have
> any tracepoints, which would've been ideal for that. Maybe this is
> a reason to add some? ;)
See attached patch (which I apparently forgot to send out). The DRM GPU
scheduler has some tracepoints, which might be helpful. The attached
patch adds a drm_sched_job_run tracepoint when a job is queued in the
hardware ring. Together with the existing drm_sched_process_job, this
should get you an idea how long a job takes to process. Note that at
any time up to 4 jobs are allowed in the hardware queue, so you need to
match up the end times.
Regards,
LucasFrom a9ec48d1eecddcc95018ad37ebdf154ffa7ce9a4 Mon Sep 17 00:00:00 2001
From: Lucas Stach
Date: Fri, 8 Dec 2017 18:35:43 +0100
Subject: [PATCH] drm/sched: add tracepoint for job run
When tracing GPU execution it is very interesting to know when the job gets
dequeued from the software queue and added to the hardware ring. Add a
tracepoint to allow easy access to this information.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 1 +
include/drm/gpu_scheduler_trace.h | 27 +++
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 0d95888ccc3e..ceecaef67801 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -666,6 +666,7 @@ static int drm_sched_main(void *param)
drm_sched_job_begin(sched_job);
fence = sched->ops->run_job(sched_job);
+ trace_drm_sched_job_run(sched_job, entity);
drm_sched_fence_scheduled(s_fence);
if (fence) {
diff --git a/include/drm/gpu_scheduler_trace.h b/include/drm/gpu_scheduler_trace.h
index 0789e8d0a0e1..c4d83857ae00 100644
--- a/include/drm/gpu_scheduler_trace.h
+++ b/include/drm/gpu_scheduler_trace.h
@@ -61,6 +61,33 @@ TRACE_EVENT(drm_sched_job,
__entry->job_count, __entry->hw_job_count)
);
+TRACE_EVENT(drm_sched_job_run,
+ TP_PROTO(struct drm_sched_job *sched_job, struct drm_sched_entity *entity),
+ TP_ARGS(sched_job, entity),
+ TP_STRUCT__entry(
+ __field(struct drm_sched_entity *, entity)
+ __field(struct dma_fence *, fence)
+ __field(const char *, name)
+ __field(uint64_t, id)
+ __field(u32, job_count)
+ __field(int, hw_job_count)
+ ),
+
+ TP_fast_assign(
+ __entry->entity = entity;
+ __entry->id = sched_job->id;
+ __entry->fence = _job->s_fence->finished;
+ __entry->name = sched_job->sched->name;
+ __entry->job_count = spsc_queue_count(>job_queue);
+
Re: [DPU PATCH] drm/msm/dsi: add only dsi nodes with a valid device to list
On Saturday 16 June 2018 11:35 AM, Abhinav Kumar wrote:
Before adding a DSI node to the private list check if the
node has a valid device connected to it through an endpoint.
This is required in cases where the chipset supports multiple
DSI hosts but only one of them is being used.
In the current implementation even inactive nodes get added
resulting in creation of redundant connectors.
Reviewed-by: Archit Taneja
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi.c | 6 +-
drivers/gpu/drm/msm/dsi/dsi.h | 1 +
drivers/gpu/drm/msm/dsi/dsi_host.c | 10 ++
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index b744bcc..46a4906 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -120,7 +120,11 @@ static int dsi_bind(struct device *dev, struct device
*master, void *data)
if (IS_ERR(msm_dsi))
return PTR_ERR(msm_dsi);
- priv->dsi[msm_dsi->id] = msm_dsi;
+ /* Add only the host which has a device attached to it */
+ if (msm_dsi_has_valid_device(msm_dsi->host)) {
+ pr_info("id = %d has valid device\n", msm_dsi->id);
+ priv->dsi[msm_dsi->id] = msm_dsi;
+ }
return 0;
}
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 70d9a9a..aa198ef 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -180,6 +180,7 @@ void msm_dsi_host_get_phy_clk_req(struct mipi_dsi_host
*host,
int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
struct drm_device *dev);
int msm_dsi_host_init(struct msm_dsi *msm_dsi);
+bool msm_dsi_has_valid_device(struct mipi_dsi_host *host);
int msm_dsi_runtime_suspend(struct device *dev);
int msm_dsi_runtime_resume(struct device *dev);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 2f1a278..25d65e5 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -470,6 +470,16 @@ static void dsi_bus_clk_disable(struct msm_dsi_host
*msm_host)
clk_disable_unprepare(msm_host->bus_clks[i]);
}
+bool msm_dsi_has_valid_device(struct mipi_dsi_host *host)
+{
+ struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
+
+ if (msm_host->device_node)
+ return true;
+
+ return false;
+}
+
int msm_dsi_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH] drm/msm/dsi: set encoder mode for DRM bridge explicitly
On Saturday 16 June 2018 11:26 AM, Abhinav Kumar wrote: Currently, DRM bridge for DPU relies on the default video mode setting to set the encoder mode. Add an explicit call to set the encoder mode for bridges. Reviewed-by: Archit Taneja Signed-off-by: Abhinav Kumar --- drivers/gpu/drm/msm/dsi/dsi_manager.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c b/drivers/gpu/drm/msm/dsi/dsi_manager.c index 4cb1cb6..0607ad0 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c @@ -836,6 +836,7 @@ void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags) struct msm_drm_private *priv; struct msm_kms *kms; struct drm_encoder *encoder; + bool cmd_mode; /* * drm_device pointer is assigned to msm_dsi only in the modeset_init @@ -850,10 +851,11 @@ void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags) priv = dev->dev_private; kms = priv->kms; encoder = msm_dsi_get_encoder(msm_dsi); + cmd_mode = !(device_flags & +MIPI_DSI_MODE_VIDEO); if (encoder && kms->funcs->set_encoder_mode) - if (!(device_flags & MIPI_DSI_MODE_VIDEO)) - kms->funcs->set_encoder_mode(kms, encoder, true); + kms->funcs->set_encoder_mode(kms, encoder, cmd_mode); } int msm_dsi_manager_register(struct msm_dsi *msm_dsi) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/panel: lcd_olinuxino_funcs can be static
Fixes: 17a867cdd048 ("drm/panel: Add support for Olimex LCD-OLinuXino panel")
Signed-off-by: kbuild test robot
---
panel-olimex-lcd-olinuxino.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
b/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
index 0bc04ff..daa9ef5 100644
--- a/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
+++ b/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
@@ -212,7 +212,7 @@ static int lcd_olinuxino_get_modes(struct drm_panel *panel)
return num;
}
-struct drm_panel_funcs lcd_olinuxino_funcs = {
+static struct drm_panel_funcs lcd_olinuxino_funcs = {
.disable = lcd_olinuxino_disable,
.unprepare = lcd_olinuxino_unprepare,
.prepare = lcd_olinuxino_prepare,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/panel: Add support for Olimex LCD-OLinuXino panel
Hi Stefan, I love your patch! Perhaps something to improve: [auto build test WARNING on tegra-drm/drm/tegra/for-next] [also build test WARNING on v4.18-rc1 next-20180619] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Stefan-Mavrodiev/drm-panel-Add-support-for-Olimex-LCD-OLinuXino-panel/20180619-180429 base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c:215:24: sparse: symbol >> 'lcd_olinuxino_funcs' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG 4.17] etnaviv-gpu f1840000.gpu: recover hung GPU!
Am Dienstag, den 19.06.2018, 12:00 +0100 schrieb Russell King - ARM Linux: > On Tue, Jun 19, 2018 at 12:09:16PM +0200, Lucas Stach wrote: > > Hi Russell, > > > > Am Dienstag, den 19.06.2018, 10:43 +0100 schrieb Russell King - ARM Linux: > > > It looks like a bug has crept in to etnaviv between 4.16 and 4.17, > > > which causes etnaviv to misbehave with the GC600 GPU on Dove. I > > > don't think it's a GPU issue, I think it's a DRM issue. > > > > > > I get multiple: > > > > > > [ 596.711482] etnaviv-gpu f184.gpu: recover hung GPU! > > > [ 597.732852] etnaviv-gpu f184.gpu: GPU failed to reset: FE not > > > idle, 3D not idle, 2D not idle > > > > > > while Xorg is starting up. Ignore the "failed to reset", that > > > just seems to be a property of the GC600, and of course is a > > > subsequent issue after the primary problem. > > > > > > Looking at the devcoredump: > > > > > > 0004 = 00fe Idle: FE- DE+ PE+ SH+ PA+ SE+ RA+ TX+ VG- IM- FP- TS- > > > > > > So, all units on the GC600 were idle except for the front end. > > > > > > 0660 = 0812 Cmd: [wait DMA: idle Fetch: valid] Req idle Cal idle > > > 0664 = 102d06d8 Command DMA address > > > 0668 = 38c8 FE fetched word 0 > > > 066c = 001f FE fetched word 1 > > > > > > The front end was basically idle at this point, at a WAIT 200 command. > > > Digging through the ring: > > > > > > 00688: 08010e01 0040 LDST 0x3804=0x0040 > > > 00690: 4002 102d06a0 LINK 0x102d06a0 > > > 00698: 4002 102d0690 LINK 0x102d0690 > > > 006a0: 08010e04 001f LDST 0x3810=0x001f > > > 006a8: 4025 102d3000 LINK 0x102d3000 > > > 006b0: 08010e03 0008 LDST 0x380c=0x0008 Flush PE2D > > > 006b8: 08010e02 0701 LDST 0x3808=0x0701 SEM FE -> PE > > > 006c0: 4800 0701 STALL FE -> PE > > > 006c8: 08010e01 0041 LDST 0x3804=0x0041 > > > 006d0: 38c8(001f) WAIT 200 > > > > 006d8: 4002 102d06d0 LINK 0x102d06d0 <=== > > > > > > We've basically come to the end of the currently issued command stream > > > and hit the wait-link loop. Everything else in the devcoredump looks > > > normal. > > > > > > So, I think etnaviv DRM has missed an event signalled from the GPU. > > > > I don't see what would make us miss a event suddenly. > > > > > This worked fine in 4.16, so seems to be a regression. > > > > The only thing that comes to mind is that with the DRM scheduler we > > enforce a job timeout of 500ms, without the previous logic to allow a > > job to run indefinitely as long as it makes progress, as this is a > > serious QoS issue. > > That is probably what's going on then - the GC600 is not particularly > fast when dealing with 1080p resolutions. > > I think what your commit to use the DRM scheduler is missing is the > progress detection in the original scheme - we used to assume that if > the GPU FE DMA address had progressed, that the GPU was not hung. > Now it seems we merely do this by checking for events. It was a deliberate decision to remove this, as it's a potential DoS vector where a rogue client is able to basically starve all other clients of GPU access by submitting a job that runs for a very long time, as long as it's making some progress. > > This might bite you at this point, if Xorg manages to submit a really > > big job. The coredump might be delayed enough that it captures the > > state of the GPU when it has managed to finish the job after the job > > timeout was hit. > > No, it's not "a really big job" - it's just that the Dove GC600 is not > fast enough to complete _two_ 1080p sized GPU operations within 500ms. > The preceeding job contained two blits - one of them a non-alphablend > copy of: > > 0018 04200780 0,24,1920,1056 -> 0,24,1920,1056 > > and one an alpha blended copy of: > > 04380780 0,0,1920,1080 -> 0,0,1920,1080 > > This is (iirc) something I already fixed with the addition of the > progress detection back before etnaviv was merged into the mainline > kernel. I hadn't expected it to be this slow. I see that we might need to bring back the progress detection to fix the userspace regression, but I'm not fond of this, as it might lead to really bad QoS. I would prefer userspace tracking the size of the blits and flushing the cmdstream at an appropriate time, so we don't end up with really long running jobs, but I'm not sure if this would be acceptable to you... Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: tc358764: fix noderef.cocci warnings
From: kbuild test robot
drivers/gpu/drm/bridge/tc358764.c:179:60-66: ERROR: application of sizeof to
pointer
sizeof when applied to a pointer typed expression gives the size of
the pointer
Generated by: scripts/coccinelle/misc/noderef.cocci
Fixes: 147fe90c9d51 ("drm/bridge: tc358764: Add DSI to LVDS bridge driver")
CC: Andrzej Hajda
Signed-off-by: kbuild test robot
---
tc358764.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/bridge/tc358764.c
+++ b/drivers/gpu/drm/bridge/tc358764.c
@@ -176,7 +176,8 @@ static int tc358764_read(struct tc358764
ssize_t ret;
cpu_to_le16s();
- ret = mipi_dsi_generic_read(dsi, , sizeof(addr), val, sizeof(val));
+ ret = mipi_dsi_generic_read(dsi, , sizeof(addr), val,
+ sizeof(*val));
if (ret >= 0)
le32_to_cpus(val);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/9] drm/bridge: tc358764: Add DSI to LVDS bridge driver
Hi Andrzej, I love your patch! Perhaps something to improve: [auto build test WARNING on v4.18-rc1] [also build test WARNING on next-20180619] [cannot apply to drm-exynos/exynos-drm/for-next robh/for-next drm/drm-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Maciej-Purski/drm-exynos-rename-bridge_node-to-mic_bridge_node/20180619-175136 coccinelle warnings: (new ones prefixed by >>) >> drivers/gpu/drm/bridge/tc358764.c:179:60-66: ERROR: application of sizeof to >> pointer Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] locking: WW mutex cleanup
On Tue, Jun 19, 2018 at 12:44:52PM +0200, Thomas Hellstrom wrote: > On 06/19/2018 11:44 AM, Peter Zijlstra wrote: > > On Tue, Jun 19, 2018 at 10:24:43AM +0200, Thomas Hellstrom wrote: > > > From: Peter Ziljstra > > > > > > Make the WW mutex code more readable by adding comments, splitting up > > > functions and pointing out that we're actually using the Wait-Die > > > algorithm. > > > > > > Cc: Ingo Molnar > > > Cc: Jonathan Corbet > > > Cc: Gustavo Padovan > > > Cc: Maarten Lankhorst > > > Cc: Sean Paul > > > Cc: David Airlie > > > Cc: Davidlohr Bueso > > > Cc: "Paul E. McKenney" > > > Cc: Josh Triplett > > > Cc: Thomas Gleixner > > > Cc: Kate Stewart > > > Cc: Philippe Ombredanne > > > Cc: Greg Kroah-Hartman > > > Cc: linux-...@vger.kernel.org > > > Cc: linux-me...@vger.kernel.org > > > Cc: linaro-mm-...@lists.linaro.org > > > Co-authored-by: Thomas Hellstrom > > > Signed-off-by: Thomas Hellstrom > > > --- > > > Documentation/locking/ww-mutex-design.txt | 12 +- > > > include/linux/ww_mutex.h | 28 ++--- > > > kernel/locking/mutex.c| 202 > > > ++ > > > 3 files changed, 145 insertions(+), 97 deletions(-) > > Acked-by: Peter Zijlstra (Intel) > > Hi Peter, > > Do you want to add a SOB, since you're the main author? Sure, here goes: Signed-off-by: Peter Zijlstra (Intel) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] locking: WW mutex cleanup
On 06/19/2018 11:44 AM, Peter Zijlstra wrote: On Tue, Jun 19, 2018 at 10:24:43AM +0200, Thomas Hellstrom wrote: From: Peter Ziljstra Make the WW mutex code more readable by adding comments, splitting up functions and pointing out that we're actually using the Wait-Die algorithm. Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: David Airlie Cc: Davidlohr Bueso Cc: "Paul E. McKenney" Cc: Josh Triplett Cc: Thomas Gleixner Cc: Kate Stewart Cc: Philippe Ombredanne Cc: Greg Kroah-Hartman Cc: linux-...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Co-authored-by: Thomas Hellstrom Signed-off-by: Thomas Hellstrom --- Documentation/locking/ww-mutex-design.txt | 12 +- include/linux/ww_mutex.h | 28 ++--- kernel/locking/mutex.c| 202 ++ 3 files changed, 145 insertions(+), 97 deletions(-) Acked-by: Peter Zijlstra (Intel) Hi Peter, Do you want to add a SOB, since you're the main author? Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG 4.17] etnaviv-gpu f1840000.gpu: recover hung GPU!
Hi Russell, Am Dienstag, den 19.06.2018, 10:43 +0100 schrieb Russell King - ARM Linux: > It looks like a bug has crept in to etnaviv between 4.16 and 4.17, > which causes etnaviv to misbehave with the GC600 GPU on Dove. I > don't think it's a GPU issue, I think it's a DRM issue. > > I get multiple: > > [ 596.711482] etnaviv-gpu f184.gpu: recover hung GPU! > [ 597.732852] etnaviv-gpu f184.gpu: GPU failed to reset: FE not idle, 3D > not idle, 2D not idle > > while Xorg is starting up. Ignore the "failed to reset", that > just seems to be a property of the GC600, and of course is a > subsequent issue after the primary problem. > > Looking at the devcoredump: > > 0004 = 00fe Idle: FE- DE+ PE+ SH+ PA+ SE+ RA+ TX+ VG- IM- FP- TS- > > So, all units on the GC600 were idle except for the front end. > > 0660 = 0812 Cmd: [wait DMA: idle Fetch: valid] Req idle Cal idle > 0664 = 102d06d8 Command DMA address > 0668 = 38c8 FE fetched word 0 > 066c = 001f FE fetched word 1 > > The front end was basically idle at this point, at a WAIT 200 command. > Digging through the ring: > > 00688: 08010e01 0040 LDST 0x3804=0x0040 > 00690: 4002 102d06a0 LINK 0x102d06a0 > 00698: 4002 102d0690 LINK 0x102d0690 > 006a0: 08010e04 001f LDST 0x3810=0x001f > 006a8: 4025 102d3000 LINK 0x102d3000 > 006b0: 08010e03 0008 LDST 0x380c=0x0008 Flush PE2D > 006b8: 08010e02 0701 LDST 0x3808=0x0701 SEM FE -> PE > 006c0: 4800 0701 STALL FE -> PE > 006c8: 08010e01 0041 LDST 0x3804=0x0041 > 006d0: 38c8(001f) WAIT 200 > > 006d8: 4002 102d06d0 LINK 0x102d06d0 <=== > > We've basically come to the end of the currently issued command stream > and hit the wait-link loop. Everything else in the devcoredump looks > normal. > > So, I think etnaviv DRM has missed an event signalled from the GPU. I don't see what would make us miss a event suddenly. > This worked fine in 4.16, so seems to be a regression. The only thing that comes to mind is that with the DRM scheduler we enforce a job timeout of 500ms, without the previous logic to allow a job to run indefinitely as long as it makes progress, as this is a serious QoS issue. This might bite you at this point, if Xorg manages to submit a really big job. The coredump might be delayed enough that it captures the state of the GPU when it has managed to finish the job after the job timeout was hit. Can you try if changing the timeout value to something large in drm_sched_init() in etnaviv_sched.c makes any difference? Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[BUG 4.17] etnaviv-gpu f1840000.gpu: recover hung GPU!
It looks like a bug has crept in to etnaviv between 4.16 and 4.17, which causes etnaviv to misbehave with the GC600 GPU on Dove. I don't think it's a GPU issue, I think it's a DRM issue. I get multiple: [ 596.711482] etnaviv-gpu f184.gpu: recover hung GPU! [ 597.732852] etnaviv-gpu f184.gpu: GPU failed to reset: FE not idle, 3D not idle, 2D not idle while Xorg is starting up. Ignore the "failed to reset", that just seems to be a property of the GC600, and of course is a subsequent issue after the primary problem. Looking at the devcoredump: 0004 = 00fe Idle: FE- DE+ PE+ SH+ PA+ SE+ RA+ TX+ VG- IM- FP- TS- So, all units on the GC600 were idle except for the front end. 0660 = 0812 Cmd: [wait DMA: idle Fetch: valid] Req idle Cal idle 0664 = 102d06d8 Command DMA address 0668 = 38c8 FE fetched word 0 066c = 001f FE fetched word 1 The front end was basically idle at this point, at a WAIT 200 command. Digging through the ring: 00688: 08010e01 0040 LDST 0x3804=0x0040 00690: 4002 102d06a0 LINK 0x102d06a0 00698: 4002 102d0690 LINK 0x102d0690 006a0: 08010e04 001f LDST 0x3810=0x001f 006a8: 4025 102d3000 LINK 0x102d3000 006b0: 08010e03 0008 LDST 0x380c=0x0008 Flush PE2D 006b8: 08010e02 0701 LDST 0x3808=0x0701 SEM FE -> PE 006c0: 4800 0701 STALL FE -> PE 006c8: 08010e01 0041 LDST 0x3804=0x0041 006d0: 38c8(001f) WAIT 200 006d8: 4002 102d06d0 LINK 0x102d06d0<=== We've basically come to the end of the currently issued command stream and hit the wait-link loop. Everything else in the devcoredump looks normal. So, I think etnaviv DRM has missed an event signalled from the GPU. This worked fine in 4.16, so seems to be a regression. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/9] dt-bindings: display: add DT bindings for BOE HV070WSA-100 panel
From: Andrzej Hajda
The patch adds bindings to BOE HV070-WSA WSVGA panel.
Bindings are compatible with simple panel bindings.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
.../bindings/display/panel/boe,hv070wsa-100.txt| 28 ++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
new file mode 100644
index 000..9e8eea8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
@@ -0,0 +1,28 @@
+BOE HV070WSA-100 7.01" WSVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,hv070wsa-100"
+- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
+- enable-gpio: GPIO pin to enable and disable panel (active high)
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [1]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel: panel {
+ compatible = "boe,hv070wsa-100";
+ power-supply = <_3v3_reg>;
+ enable-gpios = < 3 GPIO_ACTIVE_HIGH>;
+ port {
+ panel_ep: endpoint {
+ remote-endpoint = <_out_ep>;
+ };
+ };
+ };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/9] drm/exynos: rename "bridge_node" to "mic_bridge_node"
When adding support for peripheral out bridges, the "bridge" name
becomes imprecise as it refers to a different device than the
"out_bridge".
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index eae44fd..9599e6b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -279,7 +279,7 @@ struct exynos_dsi {
struct list_head transfer_list;
const struct exynos_dsi_driver_data *driver_data;
- struct device_node *bridge_node;
+ struct device_node *mic_bridge_node;
};
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1631,7 +1631,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
- dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
+ dsi->mic_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
return 0;
}
@@ -1642,7 +1642,7 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
struct drm_encoder *encoder = dev_get_drvdata(dev);
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
struct drm_device *drm_dev = data;
- struct drm_bridge *bridge;
+ struct drm_bridge *mic_bridge;
int ret;
drm_encoder_init(drm_dev, encoder, _dsi_encoder_funcs,
@@ -1661,10 +1661,10 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
return ret;
}
- if (dsi->bridge_node) {
- bridge = of_drm_find_bridge(dsi->bridge_node);
- if (bridge)
- drm_bridge_attach(encoder, bridge, NULL);
+ if (dsi->mic_bridge_node) {
+ mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
+ if (mic_bridge)
+ drm_bridge_attach(encoder, mic_bridge, NULL);
}
return mipi_dsi_host_register(>dsi_host);
@@ -1783,7 +1783,7 @@ static int exynos_dsi_remove(struct platform_device *pdev)
{
struct exynos_dsi *dsi = platform_get_drvdata(pdev);
- of_node_put(dsi->bridge_node);
+ of_node_put(dsi->mic_bridge_node);
pm_runtime_disable(>dev);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/panel: Add support for Olimex LCD-OLinuXino panel
This patch adds Olimex Ltd. LCD-OLinuXino bridge panel driver. The
panel is used with different LCDs (currently from 480x272 to 1280x800).
Small EEPROM chip is used for identification, which holds some
factory data and timing requirements.
Signed-off-by: Stefan Mavrodiev
---
.../display/panel/olimex,lcd-olinuxino.txt | 42 +++
MAINTAINERS| 6 +
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 360 +
5 files changed, 419 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt
create mode 100644 drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
diff --git
a/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt
b/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt
new file mode 100644
index 000..a89f9c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt
@@ -0,0 +1,42 @@
+Binding for Olimex Ltd. LCD-OLinuXino bridge panel.
+
+This device can be used as bridge between a host controller and LCD panels.
+Currently supported LCDs are:
+ - LCD-OLinuXino-4.3TS
+ - LCD-OLinuXino-5
+ - LCD-OLinuXino-7
+ - LCD-OLinuXino-10
+
+The panel itself contains:
+ - AT24C16C EEPROM holding panel identification and timing requirements
+ - AR1021 resistive touch screen controller (optional)
+ - FT5x6 capacitive touch screnn controller (optional)
+ - GT911/GT928 capacitive touch screen controller (optional)
+
+The above chips share same I2C bus. The EEPROM is factory preprogrammed with
+device information (id, serial, etc.) and timing requirements.
+
+Touchscreen bingings can be found in these files:
+ - input/touchscreen/goodix.txt
+ - input/touchscreen/edt-ft5x06.txt
+ - input/touchscreen/ar1021.txt
+
+Required properties:
+ - compatible: should be "olimex,lcd-olinuxino"
+ - reg: address of the configuration EEPROM, should be <0x50>
+ - power-supply: phandle of the regulator that provides the supply voltage
+
+Optional properties:
+ - enable-gpios: GPIO pin to enable or disable the panel
+ - backlight: phandle of the backlight device attacked to the panel
+
+Example:
+ {
+ panel@50 {
+ compatible = "olimex,lcd-olinuxino";
+ reg = <0x50>;
+ power-supply = <_vcc5v0>;
+ enable-gpios = < 7 8 GPIO_ACTIVE_HIGH>;
+ backlight = <>;
+ };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 624c3fd..30343f1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4557,6 +4557,12 @@ S: Supported
F: drivers/gpu/drm/nouveau/
F: include/uapi/drm/nouveau_drm.h
+DRM DRIVER FOR OLIMEX LCD-OLINUXINO PANELS
+M: Stefan Mavrodiev
+S: Maintained
+F: drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
+F: Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt
+
DRM DRIVER FOR PERVASIVE DISPLAYS REPAPER PANELS
M: Noralf Trønnes
S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 25682ff..0292994 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -81,6 +81,16 @@ config DRM_PANEL_LG_LG4573
Say Y here if you want to enable support for LG4573 RGB panel.
To compile this driver as a module, choose M here.
+config DRM_PANEL_OLIMEX_LCD_OLINUXINO
+ tristate "Olimex LCD-OLinuXino panel"
+ depends on OF
+ depends on I2C
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Olimex Ltd.
+ LCD-OLinuXino panel. The panel is used with different sizes LCDs,
+ from 480x272 to 1280x800, and 24 bit per pixel.
+
config DRM_PANEL_ORISETECH_OTM8009A
tristate "Orise Technology otm8009a 480x800 dsi 2dl panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f26efc1..185027f 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
+obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
panel-raspberrypi-touchscreen.o
diff --git a/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
b/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
new file mode 100644
index 000..0bc04ff
--- /dev/null
+++
[PATCH v3 7/9] drm/bridge: tc358764: Add DSI to LVDS bridge driver
From: Andrzej Hajda Add a drm_bridge driver for the Toshiba TC358764 DSI to LVDS bridge. Signed-off-by: Andrzej Hajda Signed-off-by: Maciej Purski --- drivers/gpu/drm/bridge/Kconfig| 8 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/tc358764.c | 521 ++ 3 files changed, 530 insertions(+) create mode 100644 drivers/gpu/drm/bridge/tc358764.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index fa2c799..f3da8a7 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -110,6 +110,14 @@ config DRM_THINE_THC63LVD1024 ---help--- Thine THC63LVD1024 LVDS/parallel converter driver. +config DRM_TOSHIBA_TC358764 + tristate "TC358764 DSI/LVDS bridge" + depends on DRM && DRM_PANEL + depends on OF + select DRM_MIPI_DSI + help + Toshiba TC358764 DSI/LVDS bridge driver. + config DRM_TOSHIBA_TC358767 tristate "Toshiba TC358767 eDP bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 35f88d4..bf7c0ce 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o obj-$(CONFIG_DRM_SII902X) += sii902x.o obj-$(CONFIG_DRM_SII9234) += sii9234.o obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o +obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ diff --git a/drivers/gpu/drm/bridge/tc358764.c b/drivers/gpu/drm/bridge/tc358764.c new file mode 100644 index 000..0aee155 --- /dev/null +++ b/drivers/gpu/drm/bridge/tc358764.c @@ -0,0 +1,521 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2018 Samsung Electronics Co., Ltd + * + * Authors: + * Andrzej Hajda + * Maciej Purski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. + * + */ + +#include + +#include +#include +#include + +#include +#include + +#include +#include +#include + +#include + +#define FLD_MASK(start, end)(((1 << ((start) - (end) + 1)) - 1) << (end)) +#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end)) + +/* PPI layer registers */ +#define PPI_STARTPPI 0x0104 /* START control bit */ +#define PPI_LPTXTIMECNT0x0114 /* LPTX timing signal */ +#define PPI_LANEENABLE 0x0134 /* Enables each lane */ +#define PPI_TX_RX_TA 0x013C /* BTA timing parameters */ +#define PPI_D0S_CLRSIPOCOUNT 0x0164 /* Assertion timer for Lane 0 */ +#define PPI_D1S_CLRSIPOCOUNT 0x0168 /* Assertion timer for Lane 1 */ +#define PPI_D2S_CLRSIPOCOUNT 0x016C /* Assertion timer for Lane 2 */ +#define PPI_D3S_CLRSIPOCOUNT 0x0170 /* Assertion timer for Lane 3 */ +#define PPI_START_FUNCTION 1 + +/* DSI layer registers */ +#define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */ +#define DSI_LANEENABLE 0x0210 /* Enables each lane */ +#define DSI_RX_START 1 + +/* Video path registers */ +#define VP_CTRL0x0450 /* Video Path Control */ +#define VP_CTRL_MSF(v) FLD_VAL(v, 0, 0) /* Magic square in RGB666 */ +#define VP_CTRL_VTGEN(v) FLD_VAL(v, 4, 4) /* Use chip clock for timing */ +#define VP_CTRL_EVTMODE(v) FLD_VAL(v, 5, 5) /* Event mode */ +#define VP_CTRL_RGB888(v) FLD_VAL(v, 8, 8) /* RGB888 mode */ +#define VP_CTRL_VSDELAY(v) FLD_VAL(v, 31, 20) /* VSYNC delay */ +#define VP_CTRL_HSPOL BIT(17) /* Polarity of HSYNC signal */ +#define VP_CTRL_DEPOL BIT(18) /* Polarity of DE signal */ +#define VP_CTRL_VSPOL BIT(19) /* Polarity of VSYNC signal */ +#define VP_HTIM1 0x0454 /* Horizontal Timing Control 1 */ +#define VP_HTIM1_HBP(v)FLD_VAL(v, 24, 16) +#define VP_HTIM1_HSYNC(v) FLD_VAL(v, 8, 0) +#define VP_HTIM2 0x0458 /* Horizontal Timing Control 2 */ +#define VP_HTIM2_HFP(v)FLD_VAL(v, 24, 16) +#define VP_HTIM2_HACT(v) FLD_VAL(v, 10, 0) +#define VP_VTIM1 0x045C /* Vertical Timing Control 1 */ +#define VP_VTIM1_VBP(v)FLD_VAL(v, 23, 16) +#define VP_VTIM1_VSYNC(v) FLD_VAL(v, 7, 0) +#define VP_VTIM2 0x0460 /* Vertical Timing Control 2 */ +#define VP_VTIM2_VFP(v)FLD_VAL(v, 23, 16) +#define
Re: [PATCH v4 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed
On 18/06/18 09:19, Heiko Stübner wrote:
> Hi Marc,
>
> Am Mittwoch, 13. Juni 2018, 15:01:27 CEST schrieb Marc Zyngier:
>> On 12/06/18 14:20, Heiko Stuebner wrote:
>>> From: Sandy Huang
>>>
>>> The vop irq is shared between vop and iommu and irq probing in the
>>> iommu driver moved to the probe function recently. This can in some
>>> cases lead to a stall if the irq is triggered while the vop driver
>>> still has it disabled, but the vop irq handler gets called.
>>>
>>> But there is no real need to disable the irq, as the vop can simply
>>> also track its enabled state and ignore irqs in that case.
>>> For this we can simply check the power-domain state of the vop,
>>> similar to how the iommu driver does it.
>>>
>>> So remove the enable/disable handling and add appropriate condition
>>> to the irq handler.
>>>
>>> changes in v2:
>>> - move to just check the power-domain state
>>> - add clock handling
>>> changes in v3:
>>> - clarify comment to speak of runtime-pm not power-domain
>>> changes in v4:
>>> - address Marc's comments (clk-enable WARN_ON and style improvement)
>>>
>>> Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
>>> Cc: sta...@vger.kernel.org
>>> Signed-off-by: Sandy Huang
>>> Signed-off-by: Heiko Stuebner
>>> Tested-by: Ezequiel Garcia
>>
>> Reviewed-by: Marc Zyngier
>
> could I ask you to also look at patch1 of this series, to give it an
> Ack or Review? drm-misc documentation very strongly suggests [0]
> to have at least another set of eyes on a patch and so far noone
> came forward ;-)
>
> This of course also applies to everybody else in the Cc list :-D
Please feel free to apply my
Acked-by: Marc Zyngier
to that one.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 9/9] ARM: dts: exynos5250-arndale: add DSI and panel nodes
From: Andrzej Hajda
The patch adds bridge and panel nodes.
It adds also DSI properties specific for arndale board and
regulators required by the bridge.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
arch/arm/boot/dts/exynos5250-arndale.dts | 61
1 file changed, 61 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 7a8a5c5..816d89d 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -71,6 +71,17 @@
};
};
+ panel: panel {
+ compatible = "boe,hv070wsa-100";
+ power-supply = <_3v3_reg>;
+ enable-gpios = < 3 GPIO_ACTIVE_HIGH>;
+ port {
+ panel_ep: endpoint {
+ remote-endpoint = <_out_ep>;
+ };
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -97,6 +108,30 @@
reg = <2>;
regulator-name = "hdmi-en";
};
+
+ vcc_1v2_reg: regulator@3 {
+ compatible = "regulator-fixed";
+ reg = <3>;
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ };
+
+ vcc_1v8_reg: regulator@4 {
+ compatible = "regulator-fixed";
+ reg = <4>;
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ vcc_3v3_reg: regulator@5 {
+ compatible = "regulator-fixed";
+ reg = <5>;
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
};
fixed-rate-clocks {
@@ -119,6 +154,32 @@
cpu0-supply = <_reg>;
};
+_0 {
+ vddcore-supply = <_reg>;
+ vddio-supply = <_reg>;
+ samsung,pll-clock-frequency = <2400>;
+ samsung,burst-clock-frequency = <32000>;
+ samsung,esc-clock-frequency = <1000>;
+ status = "okay";
+
+ bridge@0 {
+ reg = <0>;
+ compatible = "toshiba,tc358764";
+ vddc-supply = <_1v2_reg>;
+ vddio-supply = <_1v8_reg>;
+ vddlvds-supply = <_3v3_reg>;
+ reset-gpios = < 6 GPIO_ACTIVE_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@1 {
+ reg = <1>;
+ bridge_out_ep: endpoint {
+ remote-endpoint = <_ep>;
+ };
+ };
+ };
+};
+
{
status = "okay";
samsung,color-space = <0>;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/9] drm/exynos: move connector creation to attach callback
The current implementation assumes that the only possible peripheral
device for DSIM is a panel. Using an output bridge child device
should also be possible.
If an output bridge is available, don't create a new connector.
Instead, call drm_bridge_attach() and set encoder's bridge to NULL
in order to avoid an out bridge from being visible by the framework, as
the DSI bus needs control on enabling its child output bridge.
Such sequence is required by Toshiba TC358764 bridge, which is a DSI
peripheral bridge device.
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 38 ++---
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 9599e6b..c0408c0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -255,6 +255,7 @@ struct exynos_dsi {
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
struct drm_panel *panel;
+ struct drm_bridge *out_bridge;
struct device *dev;
void __iomem *reg_base;
@@ -1499,7 +1500,30 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
struct mipi_dsi_device *device)
{
struct exynos_dsi *dsi = host_to_dsi(host);
- struct drm_device *drm = dsi->connector.dev;
+ struct drm_encoder *encoder = >encoder;
+ struct drm_device *drm = encoder->dev;
+ struct drm_bridge *out_bridge;
+
+ out_bridge = of_drm_find_bridge(device->dev.of_node);
+ if (out_bridge) {
+ drm_bridge_attach(encoder, out_bridge, NULL);
+ dsi->out_bridge = out_bridge;
+ encoder->bridge = NULL;
+ } else {
+ int ret = exynos_dsi_create_connector(encoder);
+
+ if (ret) {
+ DRM_ERROR("failed to create connector ret = %d\n", ret);
+ drm_encoder_cleanup(encoder);
+ return ret;
+ }
+
+ dsi->panel = of_drm_find_panel(device->dev.of_node);
+ if (dsi->panel) {
+ drm_panel_attach(dsi->panel, >connector);
+ dsi->connector.status = connector_status_connected;
+ }
+ }
/*
* This is a temporary solution and should be made by more generic way.
@@ -1518,11 +1542,6 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- dsi->panel = of_drm_find_panel(device->dev.of_node);
- if (dsi->panel) {
- drm_panel_attach(dsi->panel, >connector);
- dsi->connector.status = connector_status_connected;
- }
exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
@@ -1654,13 +1673,6 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
if (ret < 0)
return ret;
- ret = exynos_dsi_create_connector(encoder);
- if (ret) {
- DRM_ERROR("failed to create connector ret = %d\n", ret);
- drm_encoder_cleanup(encoder);
- return ret;
- }
-
if (dsi->mic_bridge_node) {
mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
if (mic_bridge)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/9] drm/exynos: enable out_bridge in exynos_dsi_enable()
As the out bridge will not be enabled directly by the framework,
it should be enabled by DSI. Exynos_dsi_enable() should handle a case,
when there is an out_bridge connected as a DSI peripheral.
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 34 +
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index c0408c0..8aa7ace 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1386,25 +1386,33 @@ static void exynos_dsi_enable(struct drm_encoder
*encoder)
dsi->state |= DSIM_STATE_ENABLED;
- ret = drm_panel_prepare(dsi->panel);
- if (ret < 0) {
- dsi->state &= ~DSIM_STATE_ENABLED;
- pm_runtime_put_sync(dsi->dev);
- return;
+ if (dsi->panel) {
+ ret = drm_panel_prepare(dsi->panel);
+ if (ret < 0) {
+ dsi->state &= ~DSIM_STATE_ENABLED;
+ return;
+ }
}
+ if (dsi->out_bridge)
+ drm_bridge_pre_enable(dsi->out_bridge);
+
exynos_dsi_set_display_mode(dsi);
exynos_dsi_set_display_enable(dsi, true);
- ret = drm_panel_enable(dsi->panel);
- if (ret < 0) {
- dsi->state &= ~DSIM_STATE_ENABLED;
- exynos_dsi_set_display_enable(dsi, false);
- drm_panel_unprepare(dsi->panel);
- pm_runtime_put_sync(dsi->dev);
- return;
+ if (dsi->panel) {
+ ret = drm_panel_enable(dsi->panel);
+ if (ret < 0) {
+ dsi->state &= ~DSIM_STATE_ENABLED;
+ exynos_dsi_set_display_enable(dsi, false);
+ drm_panel_unprepare(dsi->panel);
+ return;
+ }
}
+ if (dsi->out_bridge)
+ drm_bridge_enable(dsi->out_bridge);
+
dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
}
@@ -1418,8 +1426,10 @@ static void exynos_dsi_disable(struct drm_encoder
*encoder)
dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
drm_panel_disable(dsi->panel);
+ drm_bridge_disable(dsi->out_bridge);
exynos_dsi_set_display_enable(dsi, false);
drm_panel_unprepare(dsi->panel);
+ drm_bridge_post_disable(dsi->out_bridge);
dsi->state &= ~DSIM_STATE_ENABLED;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 8/9] ARM: dts: exynos5250: add DSI node
From: Andrzej Hajda
The patch adds common part of DSI node for Exynos5250 platforms
and a required mipi-phy node.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
arch/arm/boot/dts/exynos5250.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 2daf505..9965eca 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -733,6 +733,27 @@
#phy-cells = <0>;
};
+ mipi_phy: video-phy@10040710 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ reg = <0x10040710 0x100>;
+ #phy-cells = <1>;
+ syscon = <_system_controller>;
+ };
+
+ dsi_0: dsi@1450 {
+ compatible = "samsung,exynos4210-mipi-dsi";
+ reg = <0x1450 0x1>;
+ interrupts = ;
+ samsung,power-domain = <_disp1>;
+ phys = <_phy 3>;
+ phy-names = "dsim";
+ clocks = < CLK_DSIM0>, < CLK_SCLK_MIPI1>;
+ clock-names = "bus_clk", "sclk_mipi";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
adc: adc@12d1 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12D1 0x100>;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/9] drm/panel: add support for BOE HV070WSA-100 panel to simple-panel
From: Andrzej Hajda
The patch adds support for BOE HV070WSA-100 WSVGA 7.01 inch panel
in panel-simple driver. The panel is used in Exynos5250-arndale boards.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/panel/panel-simple.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab4..d5da58d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode boe_hv070wsa_mode = {
+ .clock = 40800,
+ .hdisplay = 1024,
+ .hsync_start = 1024 + 90,
+ .hsync_end = 1024 + 90 + 90,
+ .htotal = 1024 + 90 + 90 + 90,
+ .vdisplay = 600,
+ .vsync_start = 600 + 3,
+ .vsync_end = 600 + 3 + 4,
+ .vtotal = 600 + 3 + 4 + 3,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc boe_hv070wsa = {
+ .modes = _hv070wsa_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 154,
+ .height = 90,
+ },
+};
+
static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
{
.clock = 71900,
@@ -2113,6 +2135,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+ .compatible = "boe,hv070wsa-100",
+ .data = _hv070wsa
+ }, {
.compatible = "boe,nv101wxmn51",
.data = _nv101wxmn51,
}, {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
