[Bug 205589] Green screen crash with 3400G
https://bugzilla.kernel.org/show_bug.cgi?id=205589 --- Comment #6 from p...@spth.de --- I cannot reproduce the issue using kernel 5.5. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Regressions for "imply" behavior change
Hi Saeed,
On Fri, Apr 10, 2020 at 4:41 AM Saeed Mahameed wrote:
> On Thu, 2020-04-09 at 11:41 +0300, Jani Nikula wrote:
> > For example, you have two graphics drivers, one builtin and another
> > module. Then you have backlight as a module. Using IS_REACHABLE(),
> > backlight would work in one driver, but not the other. I'm sure there
> > is
> > the oddball person who finds this desirable, but the overwhelming
> > majority would just make the deps such that either you make all of
> > them
> > modules, or also require backlight to be builtin.
>
> the previous imply semantics handled this by forcing backlight to be
> built-in, which worked nicely.
Which may have worked fine for backlight, but not for other symbols
with dependencies that are not always met.
=> Use "select" to enable something unconditionally, but this can only
be used if the target's dependencies are met.
=> Use "imply" to enable an optional feature conditionally.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] staging: android: ion: use macro DEFINE_DEBUGFS_ATTRIBUTE to define debugfs fops
On Thu, Apr 09, 2020 at 10:43:18PM +0530, R Veera Kumar wrote: > It is more clear to use DEFINE_DEBUGFS_ATTRIBUTE to define debugfs file > operation rather than DEFINE_SIMPLE_ATTRIBUTE. No, it is not "more clear", the two defines are not the same thing, they do different things. If they were just identical, we would not need them both :) So please be very explicit as to _why_ you want to change this, and show how you have verified that changing this is the correct thing to do, and how you tested. Because the user-visible change can be quite different with this type of kernel change. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
On Fri, Apr 10, 2020 at 12:57 AM Benjamin Herrenschmidt wrote: > > On Thu, 2020-04-09 at 11:41 +0200, Daniel Vetter wrote: > > Now if these boxes didn't ever have agp then I think we can get away > > with deleting this, since we've already deleted the legacy radeon > > driver. And that one used vmalloc for everything. The new kms one does > > use the dma-api if the gpu isn't connected through agp > > Definitely no AGP there. Ah in that case I think we can be sure that this code is dead. Acked-by: Daniel Vetter Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206575] [amdgpu] [drm] No video signal on resume from suspend, R9 380
https://bugzilla.kernel.org/show_bug.cgi?id=206575 --- Comment #19 from Duncan (dickvandr...@gmail.com) --- I can confirm that this issue was solved on 5.6 kernel, but sadly I will continue using lts kernel because I still have problems with my webcam's fps and microphone's bitrate on others kernels. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915: Fix ref->mutex deadlock in i915_active_wait()
On Tue, Apr 07, 2020 at 12:18:09AM -0700, Sultan Alsawaf wrote:
> From: Sultan Alsawaf
>
> The following deadlock exists in i915_active_wait() due to a double lock
> on ref->mutex (call chain listed in order from top to bottom):
> i915_active_wait();
> mutex_lock_interruptible(&ref->mutex); <-- ref->mutex first acquired
> i915_active_request_retire();
> node_retire();
> active_retire();
> mutex_lock_nested(&ref->mutex, SINGLE_DEPTH_NESTING); <-- DEADLOCK
>
> Fix the deadlock by skipping the second ref->mutex lock when
> active_retire() is called through i915_active_request_retire().
>
> Note that this bug only affects 5.4 and has since been fixed in 5.5.
> Normally, a backport of the fix from 5.5 would be in order, but the
> patch set that fixes this deadlock involves massive changes that are
> neither feasible nor desirable for backporting [1][2][3]. Therefore,
> this small patch was made to address the deadlock specifically for 5.4.
>
> [1] 274cbf20fd10 ("drm/i915: Push the i915_active.retire into a worker")
> [2] 093b92287363 ("drm/i915: Split i915_active.mutex into an irq-safe
> spinlock for the rbtree")
> [3] 750bde2fd4ff ("drm/i915: Serialise with remote retirement")
>
> Fixes: 12c255b5dad1 ("drm/i915: Provide an i915_active.acquire callback")
> Cc: # 5.4.x
> Signed-off-by: Sultan Alsawaf
> ---
> drivers/gpu/drm/i915/i915_active.c | 27 +++
> drivers/gpu/drm/i915/i915_active.h | 4 ++--
> 2 files changed, 25 insertions(+), 6 deletions(-)
Now queued up, thanks.
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 07/10] Documentation: power: update Energy Model description
The Energy Model framework supports also other devices than CPUs. Update related information and add description for the new usage. Signed-off-by: Lukasz Luba --- Documentation/power/energy-model.rst | 135 +++ 1 file changed, 75 insertions(+), 60 deletions(-) diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index 90a345d57ae9..a6fb986abe3c 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -1,15 +1,17 @@ - -Energy Model of CPUs - +.. SPDX-License-Identifier: GPL-2.0 + +=== +Energy Model of devices +=== 1. Overview --- The Energy Model (EM) framework serves as an interface between drivers knowing -the power consumed by CPUs at various performance levels, and the kernel +the power consumed by devices at various performance levels, and the kernel subsystems willing to use that information to make energy-aware decisions. -The source of the information about the power consumed by CPUs can vary greatly +The source of the information about the power consumed by devices can vary greatly from one platform to another. These power costs can be estimated using devicetree data in some cases. In others, the firmware will know better. Alternatively, userspace might be best positioned. And so on. In order to avoid @@ -25,7 +27,7 @@ framework, and interested clients reading the data from it:: +---+ +-+ +---+ | Thermal (IPA) | | Scheduler (EAS) | | Other | +---+ +-+ +---+ - | | em_pd_energy()| + | | em_cpu_energy() | | | em_cpu_get() | +-+ | +-+ | | | @@ -35,7 +37,7 @@ framework, and interested clients reading the data from it:: | Framework | +-+ ^ ^ ^ - | | | em_register_perf_domain() + | | | em_dev_register_perf_domain() +--+ | +-+ | | | +---+ +---+ +--+ @@ -47,12 +49,12 @@ framework, and interested clients reading the data from it:: | Device Tree | | Firmware| | ? | +--+ +---+ +--+ -The EM framework manages power cost tables per 'performance domain' in the -system. A performance domain is a group of CPUs whose performance is scaled -together. Performance domains generally have a 1-to-1 mapping with CPUFreq -policies. All CPUs in a performance domain are required to have the same -micro-architecture. CPUs in different performance domains can have different -micro-architectures. +In case of CPU devices the EM framework manages power cost tables per +'performance domain' in the system. A performance domain is a group of CPUs +whose performance is scaled together. Performance domains generally have a +1-to-1 mapping with CPUFreq policies. All CPUs in a performance domain are +required to have the same micro-architecture. CPUs in different performance +domains can have different micro-architectures. 2. Core APIs @@ -70,14 +72,16 @@ CONFIG_ENERGY_MODEL must be enabled to use the EM framework. Drivers are expected to register performance domains into the EM framework by calling the following API:: - int em_register_perf_domain(cpumask_t *span, unsigned int nr_states, - struct em_data_callback *cb); + int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states, + struct em_data_callback *cb, cpumask_t *cpus); -Drivers must specify the CPUs of the performance domains using the cpumask -argument, and provide a callback function returning tuples -for each capacity state. The callback function provided by the driver is free +Drivers must provide a callback function returning tuples +for each performance state. The callback function provided by the driver is free to fetch data from any relevant location (DT, firmware, ...), and by any mean -deemed necessary. See Section 3. for an example of driver implementing this +deemed necessary. Only for CPU devices, drivers must specify the CPUs of the +performance domains using cpumask. For other devices than CPUs the last +argument must be set to NULL. +See Section 3. for an example of driver implementing this callback, and kernel/power/energy_model.c for further documentation on this API. @@ -85,13 +89,20 @@ API. 2.3 Accessing performance domains ^
[PATCH v1] staging: fbtft: fb_st7789v: enabled inversion
From: Oliver Graute Enable inversion mode Signed-off-by: Oliver Graute --- drivers/staging/fbtft/fb_st7789v.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/staging/fbtft/fb_st7789v.c b/drivers/staging/fbtft/fb_st7789v.c index 3c3f387936e8..84c5af2dc9a0 100644 --- a/drivers/staging/fbtft/fb_st7789v.c +++ b/drivers/staging/fbtft/fb_st7789v.c @@ -120,6 +120,10 @@ static int init_display(struct fbtft_par *par) write_reg(par, PWCTRL1, 0xA4, 0xA1); write_reg(par, MIPI_DCS_SET_DISPLAY_ON); + + /* enable inversion mode */ + write_reg(par, 0x21); + return 0; } -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/36] dt-bindings: display: allow port and ports in panel-lvds
Hi Sam, Thank you for the patch. On Wed, Apr 8, 2020 at 10:37 PM Sam Ravnborg wrote: > > Both port and ports names may be used. > port - for a single port > ports - if there is more than one port in sub-nodes > > Fixes the following warning: > advantech,idk-2121wr.example.dt.yaml: panel-lvds: 'port' is a required > property > > advantech,idk-2121wr.yaml needs several ports, so uses a ports node. > > Signed-off-by: Sam Ravnborg > Cc: Fabrizio Castro > Cc: Lad Prabhakar > Cc: Thierry Reding > Cc: Sam Ravnborg Reviewed-by: Lad Prabhakar Cheers, --Prabhakar > --- > Documentation/devicetree/bindings/display/panel/lvds.yaml | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml > b/Documentation/devicetree/bindings/display/panel/lvds.yaml > index d0083301acbe..f9132d50821c 100644 > --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml > +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml > @@ -102,6 +102,12 @@ required: >- width-mm >- height-mm >- panel-timing > - - port > + > +if: > + required: > +- port > +else: > + required: > +- ports > > ... > -- > 2.20.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 25/28] mm: remove vmalloc_user_node_flags
cc Johannes who suggested this API call originally
On Wed, Apr 8, 2020 at 5:03 AM Christoph Hellwig wrote:
>
> Open code it in __bpf_map_area_alloc, which is the only caller. Also
> clean up __bpf_map_area_alloc to have a single vmalloc call with
> slightly different flags instead of the current two different calls.
>
> For this to compile for the nommu case add a __vmalloc_node_range stub
> to nommu.c.
>
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/vmalloc.h | 1 -
> kernel/bpf/syscall.c| 23 +--
> mm/nommu.c | 14 --
> mm/vmalloc.c| 20
> 4 files changed, 21 insertions(+), 37 deletions(-)
>
> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
> index 108f49b47756..f90f2946aac2 100644
> --- a/include/linux/vmalloc.h
> +++ b/include/linux/vmalloc.h
> @@ -106,7 +106,6 @@ extern void *vzalloc(unsigned long size);
> extern void *vmalloc_user(unsigned long size);
> extern void *vmalloc_node(unsigned long size, int node);
> extern void *vzalloc_node(unsigned long size, int node);
> -extern void *vmalloc_user_node_flags(unsigned long size, int node, gfp_t
> flags);
> extern void *vmalloc_exec(unsigned long size);
> extern void *vmalloc_32(unsigned long size);
> extern void *vmalloc_32_user(unsigned long size);
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 48d98ea8fad6..249d9bd43321 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -281,26 +281,29 @@ static void *__bpf_map_area_alloc(u64 size, int
> numa_node, bool mmapable)
> * __GFP_RETRY_MAYFAIL to avoid such situations.
> */
>
> - const gfp_t flags = __GFP_NOWARN | __GFP_ZERO;
> + const gfp_t gfp = __GFP_NOWARN | __GFP_ZERO;
> + unsigned int flags = 0;
> + unsigned long align = 1;
> void *area;
>
> if (size >= SIZE_MAX)
> return NULL;
>
> /* kmalloc()'ed memory can't be mmap()'ed */
> - if (!mmapable && size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) {
> - area = kmalloc_node(size, GFP_USER | __GFP_NORETRY | flags,
> + if (mmapable) {
> + BUG_ON(!PAGE_ALIGNED(size));
> + align = SHMLBA;
> + flags = VM_USERMAP;
> + } else if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) {
> + area = kmalloc_node(size, gfp | GFP_USER | __GFP_NORETRY,
> numa_node);
> if (area != NULL)
> return area;
> }
> - if (mmapable) {
> - BUG_ON(!PAGE_ALIGNED(size));
> - return vmalloc_user_node_flags(size, numa_node, GFP_KERNEL |
> - __GFP_RETRY_MAYFAIL | flags);
> - }
> - return __vmalloc_node(size, 1, GFP_KERNEL | __GFP_RETRY_MAYFAIL |
> flags,
> - numa_node, __builtin_return_address(0));
> +
> + return __vmalloc_node_range(size, align, VMALLOC_START, VMALLOC_END,
> + gfp | GFP_KERNEL | __GFP_RETRY_MAYFAIL, PAGE_KERNEL,
> + flags, numa_node, __builtin_return_address(0));
> }
>
> void *bpf_map_area_alloc(u64 size, int numa_node)
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 81a86cd85893..b42cd6003d7d 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -150,6 +150,14 @@ void *__vmalloc(unsigned long size, gfp_t gfp_mask)
> }
> EXPORT_SYMBOL(__vmalloc);
>
> +void *__vmalloc_node_range(unsigned long size, unsigned long align,
> + unsigned long start, unsigned long end, gfp_t gfp_mask,
> + pgprot_t prot, unsigned long vm_flags, int node,
> + const void *caller)
> +{
> + return __vmalloc(size, flags);
> +}
> +
> void *__vmalloc_node(unsigned long size, unsigned long align, gfp_t gfp_mask,
> int node, const void *caller)
> {
> @@ -180,12 +188,6 @@ void *vmalloc_user(unsigned long size)
> }
> EXPORT_SYMBOL(vmalloc_user);
>
> -void *vmalloc_user_node_flags(unsigned long size, int node, gfp_t flags)
> -{
> - return __vmalloc_user_flags(size, flags | __GFP_ZERO);
> -}
> -EXPORT_SYMBOL(vmalloc_user_node_flags);
> -
> struct page *vmalloc_to_page(const void *addr)
> {
> return virt_to_page(addr);
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 333fbe77255a..f6f2acdaf70c 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2658,26 +2658,6 @@ void *vzalloc_node(unsigned long size, int node)
> }
> EXPORT_SYMBOL(vzalloc_node);
>
> -/**
> - * vmalloc_user_node_flags - allocate memory for userspace on a specific node
> - * @size: allocation size
> - * @node: numa node
> - * @flags: flags for the page level allocator
> - *
> - * The resulting memory area is zeroed so it can be mapped to userspace
> - * without leaking data.
> - *
> - * Return: pointer to the allocated memory or %NULL on error
> - */
> -void *vmalloc_user_node_flags(unsign
[PATCH v6 00/10] Add support for devices in the Energy Model
Hi all, This patch set introduces support for devices in the Energy Model (EM) framework. It will unify the power model for thermal subsystem. It will make simpler to add support for new devices willing to use more advanced features (like Intelligent Power Allocation). Now it should require less knowledge and effort for driver developer to add e.g. GPU driver with simple energy model. A more sophisticated energy model in the thermal framework is also possible, driver needs to provide a dedicated callback function. More information can be found in the updated documentation file. First 7 patches are refactoring Energy Model framework to add support of other devices that CPUs. They change: - naming convention from 'capacity' to 'performance' state, - API arguments adding device pointer and not rely only on cpumask, - change naming when 'cpu' was used, now it's a 'device' - internal structure to maintain registered devices - update users to the new API Patch 8 updates OPP framework helper function to be more generic, not CPU specific. Patch 9 changes devfreq cooling, dropping part of old power model and adding registration with Energy Model via exported GPL function. It uses as a base the new PM QoS mechanism which is now in thermal-next. Patch 10 is a simple change for Panfrost GPU driver. The patch set is based on linux-next tag next-20200409. Changes: v6: - split patch 1/5 from v5 into smaller patches as requested by Daniel and dropped ACK from Quentin which was in the old there - added function em_dev_register_perf_domain as suggested by Daniel, which would help transition into the new API - changed 'cs' (capacity state) in different places into 'ps' (performance state), since now there are many smaller patches (previously skipped because of too big size of the patch with main features and left to do later) - changed cpumask_equal() to cpumask_intersects() when checking if 'cpus' coming as an argument to registration function might overlap with already known; this shouldn't be an issue when cpufreq policy is OK, but a check doesn't harm - added Reviewed-by from Alyssa into Panfrost related patch - dropped Matthias patch with PM QoS from the series since it's in the next now v5 [5]: - devfreq cooling: rebased on top of pending patch introducing PM QoS limits - devfreq cooling: added Matthias's patch to make this series build check pass - devfreq cooling: removed OPP disable code and switched to PM QoS - devfreq cooling: since thermal code always used a pointer to devfreq_dev_status, switched to work on a local copy and avoid potential race when either busy_time or total_time could change in the background - devfreq cooling: added _normalize_load() and handle all scenarios when busy_time and total_time could have odd values (even raw counters) - Energy Model patch 2/4: removed prints from cpufreq drivers and added print inside dev_pm_opp_of_register_em() - update patch 2/4 description to better reflect upcoming changes - collected ACK from Quentin for patch 1/4 and Reviewed-by from Steven for 4/4 v4 [4]: - devfreq cooling: added two new registration functions, which will take care of registering EM for the device and simplify drivers code (suggested by Robin and Rob) - Energy Model: changed unregistering code, added kref to track usage, added code freeing tables, added helper function - added return value to function dev_pm_opp_of_register_em() and updated CPUFreq drivers code, added debug prints in case of failure - updated comments in devfreq cooling removing statement that only simple_ondemand devfreq governor is supported to work with power extentions - fixed spelling in the documentation (reported by Randy) v3 [3]: - added back the cpumask 'cpus' in the em_perf_domain due potential cache misses - removed _is_cpu_em() since there is no need for it - changed function name from em_pd_energy() to em_cpu_energy(), which is optimized for usage from the scheduler making some assumptions and not validating arguments to speed-up, there is a comment stressing that it should be used only for CPUs em_perf_domain - changed em_get_pd() to em_pd_get() which is now aligned with em_cpu_get() naming - Energy Model: add code which checks if the EM is already registered for the devfreq device - extended comment in em_cpu_get() describing the need for this function - fixed build warning reported on x86 by kbuild test robot in devfreq_cooling.c - updated documentation in the energy-model.rst - changed print messages from 'energy_model' to 'EM' - changed dev_warn to dev_dbg, should calm down test scripts in case the platform has OPPs less efficient in the OPP table (some of them are there for cooling reasons, we shouldn't warn in this case, debug info is enough) v2 [2]: - changed EM API em_register_perf_domain() adding cpumask_t pointer as last argument (which was discussed with Dietmar and Quentin) - removed dependency on PM_OPP, thanks to the cpumask_t argument - removed
[PATCH v6 06/10] PM / EM: change name of em_pd_energy to em_cpu_energy
Energy Model framework supports now other devices than CPUs. Refactor some
of the functions in order to prevent wrong usage. The old function
em_pd_energy has to generic name. It must not be used without proper
cpumask pointer, which is possible only for CPU devices. Thus, rename it
and add proper description to warn of potential wrong usage for other
devices.
Signed-off-by: Lukasz Luba
---
include/linux/energy_model.h | 11 ---
kernel/sched/fair.c | 2 +-
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
index 73c43e4c8a3b..1790199aa24f 100644
--- a/include/linux/energy_model.h
+++ b/include/linux/energy_model.h
@@ -83,15 +83,20 @@ int em_dev_register_perf_domain(struct device *dev,
unsigned int nr_states,
void em_dev_unregister_perf_domain(struct device *dev);
/**
- * em_pd_energy() - Estimates the energy consumed by the CPUs of a perf. domain
+ * em_cpu_energy() - Estimates the energy consumed by the CPUs of a
+ performance domain
* @pd : performance domain for which energy has to be estimated
* @max_util : highest utilization among CPUs of the domain
* @sum_util : sum of the utilization of all CPUs in the domain
*
+ * This function must be used only for CPU devices. There is no validation,
+ * i.e. if the EM is a CPU type and has cpumask allocated. It is called from
+ * the scheduler code quite frequently and that is why there is not checks.
+ *
* Return: the sum of the energy consumed by the CPUs of the domain assuming
* a capacity state satisfying the max utilization of the domain.
*/
-static inline unsigned long em_pd_energy(struct em_perf_domain *pd,
+static inline unsigned long em_cpu_energy(struct em_perf_domain *pd,
unsigned long max_util, unsigned long sum_util)
{
unsigned long freq, scale_cpu;
@@ -199,7 +204,7 @@ static inline struct em_perf_domain *em_pd_get(struct
device *dev)
static inline void em_pd_put(struct device *dev)
{
}
-static inline unsigned long em_pd_energy(struct em_perf_domain *pd,
+static inline unsigned long em_cpu_energy(struct em_perf_domain *pd,
unsigned long max_util, unsigned long sum_util)
{
return 0;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 02f323b85b6d..30f6392f628c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6464,7 +6464,7 @@ compute_energy(struct task_struct *p, int dst_cpu, struct
perf_domain *pd)
max_util = max(max_util, cpu_util);
}
- return em_pd_energy(pd->em_pd, max_util, sum_util);
+ return em_cpu_energy(pd->em_pd, max_util, sum_util);
}
/*
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 08/10] OPP: refactor dev_pm_opp_of_register_em() and update related drivers
The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Signed-off-by: Lukasz Luba --- drivers/cpufreq/cpufreq-dt.c | 2 +- drivers/cpufreq/imx6q-cpufreq.c| 2 +- drivers/cpufreq/mediatek-cpufreq.c | 2 +- drivers/cpufreq/omap-cpufreq.c | 2 +- drivers/cpufreq/qcom-cpufreq-hw.c | 2 +- drivers/cpufreq/scpi-cpufreq.c | 2 +- drivers/cpufreq/vexpress-spc-cpufreq.c | 2 +- drivers/opp/of.c | 71 -- include/linux/pm_opp.h | 15 +- 9 files changed, 65 insertions(+), 35 deletions(-) diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c index 26fe8dfb9ce6..f9f03fd49b83 100644 --- a/drivers/cpufreq/cpufreq-dt.c +++ b/drivers/cpufreq/cpufreq-dt.c @@ -275,7 +275,7 @@ static int cpufreq_init(struct cpufreq_policy *policy) policy->cpuinfo.transition_latency = transition_latency; policy->dvfs_possible_from_any_cpu = true; - dev_pm_opp_of_register_em(policy->cpus); + dev_pm_opp_of_register_em(cpu_dev, policy->cpus); return 0; diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c index fdb2bd15..ef7b34c1fd2b 100644 --- a/drivers/cpufreq/imx6q-cpufreq.c +++ b/drivers/cpufreq/imx6q-cpufreq.c @@ -193,7 +193,7 @@ static int imx6q_cpufreq_init(struct cpufreq_policy *policy) policy->clk = clks[ARM].clk; cpufreq_generic_init(policy, freq_table, transition_latency); policy->suspend_freq = max_freq; - dev_pm_opp_of_register_em(policy->cpus); + dev_pm_opp_of_register_em(cpu_dev, policy->cpus); return 0; } diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c index 0c98dd08273d..7d1212c9b7c8 100644 --- a/drivers/cpufreq/mediatek-cpufreq.c +++ b/drivers/cpufreq/mediatek-cpufreq.c @@ -448,7 +448,7 @@ static int mtk_cpufreq_init(struct cpufreq_policy *policy) policy->driver_data = info; policy->clk = info->cpu_clk; - dev_pm_opp_of_register_em(policy->cpus); + dev_pm_opp_of_register_em(info->cpu_dev, policy->cpus); return 0; } diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c index 8d14b42a8c6f..3694bb030df3 100644 --- a/drivers/cpufreq/omap-cpufreq.c +++ b/drivers/cpufreq/omap-cpufreq.c @@ -131,7 +131,7 @@ static int omap_cpu_init(struct cpufreq_policy *policy) /* FIXME: what's the actual transition time? */ cpufreq_generic_init(policy, freq_table, 300 * 1000); - dev_pm_opp_of_register_em(policy->cpus); + dev_pm_opp_of_register_em(mpu_dev, policy->cpus); return 0; } diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c index fc92a8842e25..0a04b6f03b9a 100644 --- a/drivers/cpufreq/qcom-cpufreq-hw.c +++ b/drivers/cpufreq/qcom-cpufreq-hw.c @@ -238,7 +238,7 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy) goto error; } - dev_pm_opp_of_register_em(policy->cpus); + dev_pm_opp_of_register_em(cpu_dev, policy->cpus); policy->fast_switch_possible = true; diff --git a/drivers/cpufreq/scpi-cpufreq.c b/drivers/cpufreq/scpi-cpufreq.c index 20d1f85d5f5a..b0f5388b8854 100644 --- a/drivers/cpufreq/scpi-cpufreq.c +++ b/drivers/cpufreq/scpi-cpufreq.c @@ -167,7 +167,7 @@ static int scpi_cpufreq_init(struct cpufreq_policy *policy) policy->fast_switch_possible = false; - dev_pm_opp_of_register_em(policy->cpus); + dev_pm_opp_of_register_em(cpu_dev, policy->cpus); return 0; diff --git a/drivers/cpufreq/vexpress-spc-cpufreq.c b/drivers/cpufreq/vexpress-spc-cpufreq.c index 83c85d3d67e3..4e8b1dee7c9a 100644 --- a/drivers/cpufreq/vexpress-spc-cpufreq.c +++ b/drivers/cpufreq/vexpress-spc-cpufreq.c @@ -450,7 +450,7 @@ static int ve_spc_cpufreq_init(struct cpufreq_policy *policy) policy->freq_table = freq_table[cur_cluster]; policy->cpuinfo.transition_latency = 100; /* 1 ms */ - dev_pm_opp_of_register_em(policy->cpus); + dev_pm_opp_of_register_em(cpu_dev, policy->cpus); if (is_bL_switching_enabled()) per_cpu(cpu_last_req_freq, policy->cpu) = diff --git a/drivers/opp/of.c b/drivers/opp/of.c index 5b75829a915d..4500ce46d476 100644 --- a/drivers/opp/of.c +++ b/drivers/opp/of.c @@ -1036,18 +1036,18 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_of_node); /* * Callback function provided to the Energy Model framework upon registration. - * This computes the power estimated by @CPU at @kHz if it is the frequency + * This computes the power estimated by @dev at @kHz if it is the frequency * of an existing OPP, or at the frequency of the first OPP above @kHz
Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
Am 09.04.20 um 10:54 schrieb Benjamin Herrenschmidt:
> On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
>> On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
>>> If this code was broken for non-coherent caches a crude powerpc hack
>>> isn't going to help anyone else. Remove the hack as it is the last
>>> user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
>>
>> Well Ben added this to make stuff work on ppc, ofc the home grown dma
>> layer in drm from back then isn't going to work in other places. I guess
>> should have at least an ack from him, in case anyone still cares about
>> this on ppc. Adding Ben to cc.
>
> This was due to some drivers (radeon ?) trying to use vmalloc pages for
> coherent DMA, which means on those 4xx powerpc's need to be non-cached.
>
> There were machines using that (440 based iirc), though I honestly
> can't tell if anybody still uses any of it.
The first-gen amigaone platform (6xx/book32s) uses the radeon driver
together with non-coherent DMA. However this only ever worked reliably
for DRI1.
br,
Gerhard
> Cheers,
> Ben.
>
>> -Daniel
>>
>>>
>>> Signed-off-by: Christoph Hellwig
>>> ---
>>> drivers/gpu/drm/drm_scatter.c | 11 +--
>>> 1 file changed, 1 insertion(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
>>> index ca520028b2cb..f4e6184d1877 100644
>>> --- a/drivers/gpu/drm/drm_scatter.c
>>> +++ b/drivers/gpu/drm/drm_scatter.c
>>> @@ -43,15 +43,6 @@
>>>
>>> #define DEBUG_SCATTER 0
>>>
>>> -static inline void *drm_vmalloc_dma(unsigned long size)
>>> -{
>>> -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
>>> - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
>>> -#else
>>> - return vmalloc_32(size);
>>> -#endif
>>> -}
>>> -
>>> static void drm_sg_cleanup(struct drm_sg_mem * entry)
>>> {
>>> struct page *page;
>>> @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void
>>> *data,
>>> return -ENOMEM;
>>> }
>>>
>>> - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
>>> + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
>>> if (!entry->virtual) {
>>> kfree(entry->busaddr);
>>> kfree(entry->pagelist);
>>> --
>>> 2.25.1
>>>
>>
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/35] docs: fix broken references to text files
On Wednesday, April 8, 2020 5:45:55 PM CEST Mauro Carvalho Chehab wrote: > Several references got broken due to txt to ReST conversion. > > Several of them can be automatically fixed with: > > scripts/documentation-file-ref-check --fix > > Reviewed-by: Mathieu Poirier # > hwtracing/coresight/Kconfig Signed-off-by: Mauro Carvalho Chehab > > --- > Documentation/memory-barriers.txt| 2 +- > Documentation/process/submit-checklist.rst | 2 +- > .../translations/it_IT/process/submit-checklist.rst | 2 +- Acked-by: Federico Vaga ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 03/10] PM / EM: update callback structure and add device pointer
The Energy Model framework is going to support devices other that CPUs. In
order to make this happen change the callback function and add pointer to
a device as an argument.
Update the related users to use new function and new callback from the
Energy Model.
Signed-off-by: Lukasz Luba
---
drivers/cpufreq/scmi-cpufreq.c | 11 +++
drivers/opp/of.c | 9 ++---
include/linux/energy_model.h | 15 ---
kernel/power/energy_model.c| 9 +
4 files changed, 18 insertions(+), 26 deletions(-)
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 61623e2ff149..11ee24e06d12 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -103,17 +103,12 @@ scmi_get_sharing_cpus(struct device *cpu_dev, struct
cpumask *cpumask)
}
static int __maybe_unused
-scmi_get_cpu_power(unsigned long *power, unsigned long *KHz, int cpu)
+scmi_get_cpu_power(unsigned long *power, unsigned long *KHz,
+ struct device *cpu_dev)
{
- struct device *cpu_dev = get_cpu_device(cpu);
unsigned long Hz;
int ret, domain;
- if (!cpu_dev) {
- pr_err("failed to get cpu%d device\n", cpu);
- return -ENODEV;
- }
-
domain = handle->perf_ops->device_domain_id(cpu_dev);
if (domain < 0)
return domain;
@@ -200,7 +195,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
policy->fast_switch_possible = true;
- em_register_perf_domain(policy->cpus, nr_opp, &em_cb);
+ em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus);
return 0;
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 9cd8f0adacae..5b75829a915d 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -1047,9 +1047,8 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_of_node);
* calculation failed because of missing parameters, 0 otherwise.
*/
static int __maybe_unused _get_cpu_power(unsigned long *mW, unsigned long *kHz,
-int cpu)
+struct device *cpu_dev)
{
- struct device *cpu_dev;
struct dev_pm_opp *opp;
struct device_node *np;
unsigned long mV, Hz;
@@ -1057,10 +1056,6 @@ static int __maybe_unused _get_cpu_power(unsigned long
*mW, unsigned long *kHz,
u64 tmp;
int ret;
- cpu_dev = get_cpu_device(cpu);
- if (!cpu_dev)
- return -ENODEV;
-
np = of_node_get(cpu_dev->of_node);
if (!np)
return -EINVAL;
@@ -1128,6 +1123,6 @@ void dev_pm_opp_of_register_em(struct cpumask *cpus)
if (ret || !cap)
return;
- em_register_perf_domain(cpus, nr_opp, &em_cb);
+ em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, cpus);
}
EXPORT_SYMBOL_GPL(dev_pm_opp_of_register_em);
diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
index 7c048df98447..7076cb22b247 100644
--- a/include/linux/energy_model.h
+++ b/include/linux/energy_model.h
@@ -48,24 +48,25 @@ struct em_perf_domain {
struct em_data_callback {
/**
* active_power() - Provide power at the next performance state of
-* a CPU
+* a device
* @power : Active power at the performance state in mW
* (modified)
* @freq: Frequency at the performance state in kHz
* (modified)
-* @cpu : CPU for which we do this operation
+* @dev : Device for which we do this operation (can be a CPU)
*
-* active_power() must find the lowest performance state of 'cpu' above
+* active_power() must find the lowest performance state of 'dev' above
* 'freq' and update 'power' and 'freq' to the matching active power
* and frequency.
*
-* The power is the one of a single CPU in the domain, expressed in
-* milli-watts. It is expected to fit in the [0, EM_MAX_POWER]
-* range.
+* In case of CPUs, the power is the one of a single CPU in the domain,
+* expressed in milli-watts. It is expected to fit in the
+* [0, EM_MAX_POWER] range.
*
* Return 0 on success.
*/
- int (*active_power)(unsigned long *power, unsigned long *freq, int cpu);
+ int (*active_power)(unsigned long *power, unsigned long *freq,
+ struct device *dev);
};
#define EM_DATA_CB(_active_power_cb) { .active_power = &_active_power_cb }
diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
index 875b163e54ab..5b8a1566526a 100644
--- a/kernel/power/energy_model.c
+++ b/kernel/power/energy_model.c
@@ -78,8 +78,9 @@ core_initcall(em_debug_init);
#else /* CONFIG_DEBUG_FS */
static void em_debug_create_pd(struct em_perf_domain *pd, int cpu) {}
#endif
-static struct em_perf_domain *em_cre
[PATCH v6 01/10] PM / EM: change naming convention from 'capacity' to 'performance'
The Energy Model uses concept of performance domain and capacity states in
order to calculate power used by CPUs. Change naming convention from
capacity to performance state would enable wider usage in future, e.g.
upcoming support for other devices other than CPUs.
Signed-off-by: Lukasz Luba
---
drivers/thermal/cpufreq_cooling.c | 12 ++---
include/linux/energy_model.h | 86 +--
kernel/power/energy_model.c | 44
kernel/sched/topology.c | 20 +++
4 files changed, 84 insertions(+), 78 deletions(-)
diff --git a/drivers/thermal/cpufreq_cooling.c
b/drivers/thermal/cpufreq_cooling.c
index e297e135c031..ad8971e26538 100644
--- a/drivers/thermal/cpufreq_cooling.c
+++ b/drivers/thermal/cpufreq_cooling.c
@@ -333,18 +333,18 @@ static inline bool em_is_sane(struct
cpufreq_cooling_device *cpufreq_cdev,
return false;
policy = cpufreq_cdev->policy;
- if (!cpumask_equal(policy->related_cpus, to_cpumask(em->cpus))) {
+ if (!cpumask_equal(policy->related_cpus, em_span_cpus(em))) {
pr_err("The span of pd %*pbl is misaligned with cpufreq policy
%*pbl\n",
- cpumask_pr_args(to_cpumask(em->cpus)),
+ cpumask_pr_args(em_span_cpus(em)),
cpumask_pr_args(policy->related_cpus));
return false;
}
nr_levels = cpufreq_cdev->max_level + 1;
- if (em->nr_cap_states != nr_levels) {
- pr_err("The number of cap states in pd %*pbl (%u) doesn't match
the number of cooling levels (%u)\n",
- cpumask_pr_args(to_cpumask(em->cpus)),
- em->nr_cap_states, nr_levels);
+ if (em_pd_nr_perf_states(em) != nr_levels) {
+ pr_err("The number of performance states in pd %*pbl (%u)
doesn't match the number of cooling levels (%u)\n",
+ cpumask_pr_args(em_span_cpus(em)),
+ em_pd_nr_perf_states(em), nr_levels);
return false;
}
diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
index ade6486a3382..fe336a9eb5d4 100644
--- a/include/linux/energy_model.h
+++ b/include/linux/energy_model.h
@@ -10,13 +10,13 @@
#include
/**
- * em_cap_state - Capacity state of a performance domain
+ * em_perf_state - Performance state of a performance domain
* @frequency: The CPU frequency in KHz, for consistency with CPUFreq
* @power: The power consumed by 1 CPU at this level, in milli-watts
* @cost: The cost coefficient associated with this level, used during
* energy calculation. Equal to: power * max_frequency / frequency
*/
-struct em_cap_state {
+struct em_perf_state {
unsigned long frequency;
unsigned long power;
unsigned long cost;
@@ -24,8 +24,8 @@ struct em_cap_state {
/**
* em_perf_domain - Performance domain
- * @table: List of capacity states, in ascending order
- * @nr_cap_states: Number of capacity states
+ * @table: List of performance states, in ascending order
+ * @nr_perf_states:Number of performance states
* @cpus: Cpumask covering the CPUs of the domain
*
* A "performance domain" represents a group of CPUs whose performance is
@@ -34,22 +34,27 @@ struct em_cap_state {
* CPUFreq policies.
*/
struct em_perf_domain {
- struct em_cap_state *table;
- int nr_cap_states;
+ struct em_perf_state *table;
+ int nr_perf_states;
unsigned long cpus[];
};
+#define em_span_cpus(em) (to_cpumask((em)->cpus))
+
#ifdef CONFIG_ENERGY_MODEL
#define EM_CPU_MAX_POWER 0x
struct em_data_callback {
/**
-* active_power() - Provide power at the next capacity state of a CPU
-* @power : Active power at the capacity state in mW (modified)
-* @freq: Frequency at the capacity state in kHz (modified)
+* active_power() - Provide power at the next performance state of
+* a CPU
+* @power : Active power at the performance state in mW
+* (modified)
+* @freq: Frequency at the performance state in kHz
+* (modified)
* @cpu : CPU for which we do this operation
*
-* active_power() must find the lowest capacity state of 'cpu' above
+* active_power() must find the lowest performance state of 'cpu' above
* 'freq' and update 'power' and 'freq' to the matching active power
* and frequency.
*
@@ -80,46 +85,46 @@ static inline unsigned long em_pd_energy(struct
em_perf_domain *pd,
unsigned long max_util, unsigned long sum_util)
{
unsigned long freq, scale_cpu;
- struct em_cap_state *cs;
+ struct em_perf_state *ps;
int i, cpu;
/*
-* In order to predict the capacity
[PATCH v6 02/10] PM / EM: introduce em_dev_register_perf_domain function
Add now function in the Energy Model framework which is going to support
new devices. This function will help in transition and make it smoother.
For now it still checks if the cpumask is a valid pointer, which will be
removed later when the new structures and infrastructure will be ready.
Signed-off-by: Lukasz Luba
---
include/linux/energy_model.h | 13 ++--
kernel/power/energy_model.c | 40 ++--
2 files changed, 45 insertions(+), 8 deletions(-)
diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
index fe336a9eb5d4..7c048df98447 100644
--- a/include/linux/energy_model.h
+++ b/include/linux/energy_model.h
@@ -2,6 +2,7 @@
#ifndef _LINUX_ENERGY_MODEL_H
#define _LINUX_ENERGY_MODEL_H
#include
+#include
#include
#include
#include
@@ -42,7 +43,7 @@ struct em_perf_domain {
#define em_span_cpus(em) (to_cpumask((em)->cpus))
#ifdef CONFIG_ENERGY_MODEL
-#define EM_CPU_MAX_POWER 0x
+#define EM_MAX_POWER 0x
struct em_data_callback {
/**
@@ -59,7 +60,7 @@ struct em_data_callback {
* and frequency.
*
* The power is the one of a single CPU in the domain, expressed in
-* milli-watts. It is expected to fit in the [0, EM_CPU_MAX_POWER]
+* milli-watts. It is expected to fit in the [0, EM_MAX_POWER]
* range.
*
* Return 0 on success.
@@ -71,6 +72,8 @@ struct em_data_callback {
struct em_perf_domain *em_cpu_get(int cpu);
int em_register_perf_domain(cpumask_t *span, unsigned int nr_states,
struct em_data_callback *cb);
+int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
+ struct em_data_callback *cb, cpumask_t *span);
/**
* em_pd_energy() - Estimates the energy consumed by the CPUs of a perf. domain
@@ -174,6 +177,12 @@ static inline int em_register_perf_domain(cpumask_t *span,
{
return -EINVAL;
}
+static inline
+int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
+ struct em_data_callback *cb, cpumask_t *span)
+{
+ return -EINVAL;
+}
static inline struct em_perf_domain *em_cpu_get(int cpu)
{
return NULL;
diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
index 9892d548a0fa..875b163e54ab 100644
--- a/kernel/power/energy_model.c
+++ b/kernel/power/energy_model.c
@@ -125,7 +125,7 @@ static struct em_perf_domain *em_create_pd(cpumask_t *span,
int nr_states,
* The power returned by active_state() is expected to be
* positive, in milli-watts and to fit into 16 bits.
*/
- if (!power || power > EM_CPU_MAX_POWER) {
+ if (!power || power > EM_MAX_POWER) {
pr_err("pd%d: invalid power: %lu\n", cpu, power);
goto free_ps_table;
}
@@ -183,10 +183,13 @@ struct em_perf_domain *em_cpu_get(int cpu)
EXPORT_SYMBOL_GPL(em_cpu_get);
/**
- * em_register_perf_domain() - Register the Energy Model of a performance
domain
- * @span : Mask of CPUs in the performance domain
+ * em_dev_register_perf_domain() - Register the Energy Model (EM) for a device
+ * @dev: Device for which the EM is to register
* @nr_states : Number of performance states to register
* @cb : Callback functions providing the data of the Energy Model
+ * @span : Pointer to cpumask_t, which in case of a CPU device is
+ * obligatory. It can be taken from i.e. 'policy->cpus'. For other
+ * type of devices this should be set to NULL.
*
* Create Energy Model tables for a performance domain using the callbacks
* defined in cb.
@@ -196,14 +199,14 @@ EXPORT_SYMBOL_GPL(em_cpu_get);
*
* Return 0 on success
*/
-int em_register_perf_domain(cpumask_t *span, unsigned int nr_states,
- struct em_data_callback *cb)
+int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
+ struct em_data_callback *cb, cpumask_t *span)
{
unsigned long cap, prev_cap = 0;
struct em_perf_domain *pd;
int cpu, ret = 0;
- if (!span || !nr_states || !cb)
+ if (!dev || !span || !nr_states || !cb)
return -EINVAL;
/*
@@ -255,4 +258,29 @@ int em_register_perf_domain(cpumask_t *span, unsigned int
nr_states,
return ret;
}
+EXPORT_SYMBOL_GPL(em_dev_register_perf_domain);
+
+/**
+ * em_register_perf_domain() - Register the Energy Model of a performance
domain
+ * @span : Mask of CPUs in the performance domain
+ * @nr_states : Number of capacity states to register
+ * @cb : Callback functions providing the data of the Energy Model
+ *
+ * Create Energy Model tables for a performance domain using the callbacks
+ * defined in cb.
+ *
+ * If multiple clients reg
[PULL] drm-misc-next-fixes
Hi Dave, Daniel, Here's this week round of drm-misc-next-fixes Maxime drm-misc-next-fixes-2020-04-09: A few DMA-related fixes, an OOB fix for virtio and a probe-related fix for analogix_dp The following changes since commit 0e7e6198af28c1573267aba1be33dd0b7fb35691: Merge branch 'ttm-transhuge' of git://people.freedesktop.org/~thomash/linux into drm-next (2020-04-03 09:07:49 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-04-09 for you to fetch changes up to 152cce0006abf7e17dfb7dc94896b044bda4e588: drm/bridge: analogix_dp: Split bind() into probe() and real bind() (2020-04-09 10:29:35 +0200) A few DMA-related fixes, an OOB fix for virtio and a probe-related fix for analogix_dp Chris Wilson (1): drm/legacy: Fix type for drm_local_map.offset Jiri Slaby (1): drm/virtio: fix OOB in virtio_gpu_object_create Marek Szyprowski (2): drm/prime: fix extracting of the DMA addresses from a scatterlist drm/bridge: analogix_dp: Split bind() into probe() and real bind() Maxime Ripard (1): Merge drm/drm-next into drm-misc-next-fixes .../bindings/display/panel/panel-dpi.yaml | 10 -- .../bindings/display/ti/ti,am65x-dss.yaml | 4 +-- .../bindings/display/ti/ti,j721e-dss.yaml | 4 +-- .../devicetree/bindings/display/ti/ti,k2g-dss.yaml | 4 +-- drivers/dma-buf/Kconfig| 11 --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 33 --- drivers/gpu/drm/drm_mm.c | 8 + drivers/gpu/drm/drm_prime.c| 37 +++--- drivers/gpu/drm/exynos/exynos_dp.c | 29 ++--- drivers/gpu/drm/panel/panel-simple.c | 11 --- drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 36 +++-- drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 +++ drivers/gpu/drm/vc4/vc4_hdmi.c | 20 +--- drivers/gpu/drm/virtio/virtgpu_object.c| 14 drivers/gpu/drm/xen/xen_drm_front.c| 2 +- drivers/video/fbdev/core/fbcon.c | 3 ++ include/drm/bridge/analogix_dp.h | 5 +-- include/drm/drm_legacy.h | 2 +- 18 files changed, 132 insertions(+), 105 deletions(-) signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: dpcd: Print more useful information during error
When DPCD access errors occur, knowing the register and request
associated with the error helps debugging, so print the
details in the debug message.
Signed-off-by: Aurabindo Pillai
---
drivers/gpu/drm/drm_dp_helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a5364b519..545606aac 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -257,7 +257,9 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
err = ret;
}
- DRM_DEBUG_KMS("Too many retries, giving up. First error: %d\n", err);
+ DRM_DEBUG_KMS("dpcd: Too many retries, giving up. First error: %d\t"
+ "address: %x\trequest: %x\t size:%zu\n",
+ err, msg.address, msg.request, msg.size);
ret = err;
unlock:
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 05/10] PM / EM: remove em_register_perf_domain
Remove old function em_register_perf_domain which is no longer needed.
There is em_dev_register_perf_domain that covers old use cases and new as
well.
Signed-off-by: Lukasz Luba
---
include/linux/energy_model.h | 7 ---
kernel/power/energy_model.c | 25 -
2 files changed, 32 deletions(-)
diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
index f6b8077cc875..73c43e4c8a3b 100644
--- a/include/linux/energy_model.h
+++ b/include/linux/energy_model.h
@@ -78,8 +78,6 @@ struct em_data_callback {
struct em_perf_domain *em_cpu_get(int cpu);
struct em_perf_domain *em_pd_get(struct device *dev);
void em_pd_put(struct device *dev);
-int em_register_perf_domain(cpumask_t *span, unsigned int nr_states,
- struct em_data_callback *cb);
int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
struct em_data_callback *cb, cpumask_t *span);
void em_dev_unregister_perf_domain(struct device *dev);
@@ -181,11 +179,6 @@ static inline int em_pd_nr_perf_states(struct
em_perf_domain *pd)
struct em_data_callback {};
#define EM_DATA_CB(_active_power_cb) { }
-static inline int em_register_perf_domain(cpumask_t *span,
- unsigned int nr_states, struct em_data_callback *cb)
-{
- return -EINVAL;
-}
static inline
int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
struct em_data_callback *cb, cpumask_t *span)
diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
index 5967a21b56fc..506d3e39b553 100644
--- a/kernel/power/energy_model.c
+++ b/kernel/power/energy_model.c
@@ -500,31 +500,6 @@ static void _em_release(struct kref *ref)
kfree(em_dev);
}
-/**
- * em_register_perf_domain() - Register the Energy Model of a performance
domain
- * @span : Mask of CPUs in the performance domain
- * @nr_states : Number of capacity states to register
- * @cb : Callback functions providing the data of the Energy Model
- *
- * Create Energy Model tables for a performance domain using the callbacks
- * defined in cb.
- *
- * If multiple clients register the same performance domain, all but the first
- * registration will be ignored.
- *
- * Return 0 on success
- */
-int em_register_perf_domain(cpumask_t *span, unsigned int nr_states,
- struct em_data_callback *cb)
-{
- struct device *cpu_dev;
-
- cpu_dev = get_cpu_device(cpumask_first(span));
-
- return em_dev_register_perf_domain(cpu_dev, nr_states, cb, span);
-}
-EXPORT_SYMBOL_GPL(em_register_perf_domain);
-
/**
* em_dev_unregister_perf_domain() - Unregister Energy Model (EM) for a device
* @dev: Device for which the EM is registered
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: host1x: Detach driver on unregister
On 4/8/20 10:38 AM, Thierry Reding wrote: From: Thierry Reding Currently when a host1x device driver is unregistered, it is not detached from the host1x controller, which means that the device will stay around and when the driver is registered again, it may bind to the old, stale device rather than the new one that was created from scratch upon driver registration. This in turn can cause various weird crashes within the driver core because it is confronted with a device that was already deleted. Fix this by detaching the driver from the host1x controller when it is unregistered. This ensures that the deleted device also is no longer present in the device list that drivers will bind to. Reported-by: Sowjanya Komatineni Signed-off-by: Thierry Reding --- Tested-by: Sowjanya Komatineni ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] staging: android: ion: use macro DEFINE_DEBUGFS_ATTRIBUTE to define debugfs fops
It is more clear to use DEFINE_DEBUGFS_ATTRIBUTE to define debugfs file
operation rather than DEFINE_SIMPLE_ATTRIBUTE.
Found using coccinelle.
Signed-off-by: R Veera Kumar
---
Changes in v2:
- Give correct explanation for patch
- Adjust git commit tag and msg accordingly
---
drivers/staging/android/ion/ion.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 38b51eace4f9..dbe4018a6f83 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -554,8 +554,8 @@ static int debug_shrink_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
- debug_shrink_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
+debug_shrink_set, "%llu\n");
void ion_device_add_heap(struct ion_heap *heap)
{
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 04/10] PM / EM: add support for other devices than CPUs in Energy Model
Add support for other devices that CPUs. The registration function
does not require a valid cpumask pointer and is ready to handle new
devices. Some of the internal structures has been reorganized in order to
keep consistent view (like removing per_cpu pd pointers). To track usage
of the Energy Model structures, they are protected with kref.
Signed-off-by: Lukasz Luba
---
include/linux/energy_model.h | 32 ++-
kernel/power/energy_model.c | 433 +--
2 files changed, 389 insertions(+), 76 deletions(-)
diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
index 7076cb22b247..f6b8077cc875 100644
--- a/include/linux/energy_model.h
+++ b/include/linux/energy_model.h
@@ -12,8 +12,10 @@
/**
* em_perf_state - Performance state of a performance domain
- * @frequency: The CPU frequency in KHz, for consistency with CPUFreq
- * @power: The power consumed by 1 CPU at this level, in milli-watts
+ * @frequency: The frequency in KHz, for consistency with CPUFreq
+ * @power: The power consumed at this level, in milli-watts (by 1 CPU or
+ by a registered device). It can be a total power: static and
+ dynamic.
* @cost: The cost coefficient associated with this level, used during
* energy calculation. Equal to: power * max_frequency / frequency
*/
@@ -27,12 +29,15 @@ struct em_perf_state {
* em_perf_domain - Performance domain
* @table: List of performance states, in ascending order
* @nr_perf_states:Number of performance states
- * @cpus: Cpumask covering the CPUs of the domain
+ * @cpus: Cpumask covering the CPUs of the domain. It's here
+ * for performance reasons to avoid potential cache
+ * misses during energy calculations in the scheduler
*
- * A "performance domain" represents a group of CPUs whose performance is
- * scaled together. All CPUs of a performance domain must have the same
- * micro-architecture. Performance domains often have a 1-to-1 mapping with
- * CPUFreq policies.
+ * In case of CPU device, a "performance domain" represents a group of CPUs
+ * whose performance is scaled together. All CPUs of a performance domain
+ * must have the same micro-architecture. Performance domains often have
+ * a 1-to-1 mapping with CPUFreq policies. In case of other devices the 'cpus'
+ * field is unused.
*/
struct em_perf_domain {
struct em_perf_state *table;
@@ -71,10 +76,13 @@ struct em_data_callback {
#define EM_DATA_CB(_active_power_cb) { .active_power = &_active_power_cb }
struct em_perf_domain *em_cpu_get(int cpu);
+struct em_perf_domain *em_pd_get(struct device *dev);
+void em_pd_put(struct device *dev);
int em_register_perf_domain(cpumask_t *span, unsigned int nr_states,
struct em_data_callback *cb);
int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
struct em_data_callback *cb, cpumask_t *span);
+void em_dev_unregister_perf_domain(struct device *dev);
/**
* em_pd_energy() - Estimates the energy consumed by the CPUs of a perf. domain
@@ -184,10 +192,20 @@ int em_dev_register_perf_domain(struct device *dev,
unsigned int nr_states,
{
return -EINVAL;
}
+static inline void em_dev_unregister_perf_domain(struct device *dev)
+{
+}
static inline struct em_perf_domain *em_cpu_get(int cpu)
{
return NULL;
}
+static inline struct em_perf_domain *em_pd_get(struct device *dev)
+{
+ return NULL;
+}
+static inline void em_pd_put(struct device *dev)
+{
+}
static inline unsigned long em_pd_energy(struct em_perf_domain *pd,
unsigned long max_util, unsigned long sum_util)
{
diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
index 5b8a1566526a..5967a21b56fc 100644
--- a/kernel/power/energy_model.c
+++ b/kernel/power/energy_model.c
@@ -2,8 +2,9 @@
/*
* Energy Model of CPUs
*
- * Copyright (c) 2018, Arm ltd.
+ * Copyright (c) 2018-2020, Arm ltd.
* Written by: Quentin Perret, Arm ltd.
+ * Improvements provided by: Lukasz Luba, Arm ltd.
*/
#define pr_fmt(fmt) "energy_model: " fmt
@@ -12,17 +13,46 @@
#include
#include
#include
+#include
+#include
#include
#include
-/* Mapping of each CPU to the performance domain to which it belongs. */
-static DEFINE_PER_CPU(struct em_perf_domain *, em_data);
+/**
+ * em_device - Performance domain wrapper for device
+ * @em_pd: Performance domain which carries the energy model
+ * @dev: Device for which this performance domain is set
+ * @id:Id of this performance domain
+ * @em_dev_list: List entry to connect all the devices perf. domain
+ * @debug_dir: Optional debug directory
+ *
+ * Internal structure. It contains a "performance domain" and the corresponding
+ * device.
+ */
+struct em_device {
+ stru
[PATCH v6 09/10] thermal: devfreq_cooling: Refactor code and switch to use Energy Model
The overhauled Energy Model (EM) framework support also devfreq devices.
The unified API interface of the EM can be used in the thermal subsystem to
not duplicate code. The power table now is taken from EM structure and
there is no need to maintain calculation for it locally. In case when the
EM is not provided by the device a simple interface for cooling device is
used.
[lkp: Reported the build warning]
Reported-by: kbuild test robot
Reviewed-by: Steven Rostedt (VMware) # for tracing code
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 474 --
include/linux/devfreq_cooling.h | 39 +--
include/trace/events/thermal.h| 19 +-
3 files changed, 277 insertions(+), 255 deletions(-)
diff --git a/drivers/thermal/devfreq_cooling.c
b/drivers/thermal/devfreq_cooling.c
index f7f32e98331b..32df5f55bde8 100644
--- a/drivers/thermal/devfreq_cooling.c
+++ b/drivers/thermal/devfreq_cooling.c
@@ -1,17 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* devfreq_cooling: Thermal cooling device implementation for devices using
* devfreq
*
- * Copyright (C) 2014-2015 ARM Limited
- *
- * 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 "as is" WITHOUT ANY WARRANTY of any
- * kind, whether express or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
+ * Copyright (C) 2014-2020 ARM Limited
*
* TODO:
*- If OPPs are added or removed after devfreq cooling has
@@ -41,36 +33,33 @@ static DEFINE_IDA(devfreq_ida);
* @cdev: Pointer to associated thermal cooling device.
* @devfreq: Pointer to associated devfreq device.
* @cooling_state: Current cooling state.
- * @power_table: Pointer to table with maximum power draw for each
- * cooling state. State is the index into the table, and
- * the power is in mW.
- * @freq_table:Pointer to a table with the frequencies sorted in
descending
- * order. You can index the table by cooling device state
- * @freq_table_size: Size of the @freq_table and @power_table
- * @power_ops: Pointer to devfreq_cooling_power, used to generate the
- * @power_table.
+ * @freq_table:Pointer to a table with the frequencies.
+ * @max_state: It is the last index, that is, one less than the number of the
+ * OPPs
+ * @power_ops: Pointer to devfreq_cooling_power, a more precised model.
* @res_util: Resource utilization scaling factor for the power.
* It is multiplied by 100 to minimize the error. It is used
* for estimation of the power budget instead of using
- * 'utilization' (which is 'busy_time / 'total_time').
- * The 'res_util' range is from 100 to (power_table[state] * 100)
- * for the corresponding 'state'.
- * @capped_state: index to cooling state with in dynamic power budget
+ * 'utilization' (which is 'busy_time' / 'total_time').
+ * The 'res_util' range is from 100 to power * 100 for the
+ * corresponding 'state'.
* @req_max_freq: PM QoS request for limiting the maximum frequency
* of the devfreq device.
+ * @em:Energy Model which represents the associated Devfreq
device
+ * @em_registered: Devfreq cooling registered the EM and should free it.
*/
struct devfreq_cooling_device {
int id;
struct thermal_cooling_device *cdev;
struct devfreq *devfreq;
unsigned long cooling_state;
- u32 *power_table;
u32 *freq_table;
- size_t freq_table_size;
+ size_t max_state;
struct devfreq_cooling_power *power_ops;
u32 res_util;
- int capped_state;
struct dev_pm_qos_request req_max_freq;
+ struct em_perf_domain *em;
+ bool em_registered;
};
static int devfreq_cooling_get_max_state(struct thermal_cooling_device *cdev,
@@ -78,7 +67,7 @@ static int devfreq_cooling_get_max_state(struct
thermal_cooling_device *cdev,
{
struct devfreq_cooling_device *dfc = cdev->devdata;
- *state = dfc->freq_table_size - 1;
+ *state = dfc->max_state;
return 0;
}
@@ -106,10 +95,16 @@ static int devfreq_cooling_set_cur_state(struct
thermal_cooling_device *cdev,
dev_dbg(dev, "Setting cooling state %lu\n", state);
- if (state >= dfc->freq_table_size)
+ if (state > dfc->max_state)
return -EINVAL;
- freq = dfc->freq_table[state];
+ if (dfc->em) {
+ /* Energy Model frequencies are in kHz */
+ freq = dfc->em->table[dfc->max_state - state].frequency;
+ freq *= 1000;
+ } else {
+
[PATCH v6 10/10] drm/panfrost: Register devfreq cooling and attempt to add Energy Model
Register devfreq cooling device and attempt to register Energy Model. This will add the devfreq device to the Energy Model framework. It will create a dedicated and unified data structures used i.e. in thermal framework. The last NULL parameter indicates that the power model is simplified and created based on DT 'dynamic-power-coefficient', voltage and frequency. Reviewed-by: Steven Price Reviewed-by: Alyssa Rosenzweig Signed-off-by: Lukasz Luba --- drivers/gpu/drm/panfrost/panfrost_devfreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c b/drivers/gpu/drm/panfrost/panfrost_devfreq.c index 413987038fbf..8759a73db153 100644 --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c @@ -105,7 +105,7 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev) } pfdev->devfreq.devfreq = devfreq; - cooling = of_devfreq_cooling_register(dev->of_node, devfreq); + cooling = devfreq_cooling_em_register(devfreq, NULL); if (IS_ERR(cooling)) DRM_DEV_INFO(dev, "Failed to register cooling device\n"); else -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/tve200: Checking for a failed platform_get_irq() call in tve200_probe()
Hello,
I have taken another look at the implementation of the function “tve200_probe”.
A software analysis approach points the following source code out for
further development considerations.
https://elixir.bootlin.com/linux/v5.6.3/source/drivers/gpu/drm/tve200/tve200_drv.c#L212
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/tve200/tve200_drv.c?id=5d30bcacd91af6874481129797af364a53cd9b46#n212
irq = platform_get_irq(pdev, 0);
if (!irq) {
ret = -EINVAL;
goto clk_disable;
}
The software documentation is providing the following information
for the used programming interface.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/platform.c?id=5d30bcacd91af6874481129797af364a53cd9b46#n221
https://elixir.bootlin.com/linux/v5.6.3/source/drivers/base/platform.c#L202
“…
* Return: IRQ number on success, negative error number on failure.
…”
Would you like to reconsider the shown condition check?
Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Regressions for "imply" behavior change
On Thu, 2020-04-09 at 11:41 +0300, Jani Nikula wrote: > On Wed, 08 Apr 2020, Jason Gunthorpe wrote: > > On Wed, Apr 08, 2020 at 10:49:48PM +0200, Arnd Bergmann wrote: > > > On Wed, Apr 8, 2020 at 10:38 PM Nicolas Pitre > > > wrote: > > > > On Wed, 8 Apr 2020, Arnd Bergmann wrote: > > > > > I have created workarounds for the Kconfig files, which now > > > > > stop using > > > > > imply and do something else in each case. I don't know > > > > > whether there was > > > > > a bug in the kconfig changes that has led to allowing > > > > > configurations that > > > > > were not meant to be legal even with the new semantics, or if > > > > > the Kconfig > > > > > files have simply become incorrect now and the tool works as > > > > > expected. > > > > > > > > In most cases it is the code that has to be fixed. It typically > > > > does: > > > > > > > > if (IS_ENABLED(CONFIG_FOO)) > > > > foo_init(); > > > > > > > > Where it should rather do: > > > > > > > > if (IS_REACHABLE(CONFIG_FOO)) > > > > foo_init(); > > > > > > > > A couple of such patches have been produced and queued in their > > > > respective trees already. > > > > > > I try to use IS_REACHABLE() only as a last resort, as it tends to > > > confuse users when a subsystem is built as a module and already > > > loaded but something relying on that subsystem does not use it. > > > > > > In the six patches I made, I had to use IS_REACHABLE() once, > > > for the others I tended to use a Kconfig dependency like > > > > > > 'depends on FOO || FOO=n' > > This assumes that the module using FOO has its own flag representing FOO which is not always the case. for example in mlx5 we use VXLAN config flag directly to compile VXLAN related files: mlx5/core/Makefile: obj-$(CONFIG_MLX5_CORE) += mlx5_core.o mlx5_core-y := mlx5_core.o mlx5_core-$(VXLAN) += mlx5_vxlan.o and in mlx5_main.o we do: if (IS_ENABLED(VXLAN)) mlx5_vxlan_init() after the change in imply semantics: our options are: 1) use IS_REACHABLE(VXLAN) instead of IS_ENABLED(VXLAN) 2) have MLX5_VXLAN in mlx5 Kconfig and use IS_ENABLED(MLX5_VXLAN) config MLX5_VXLAN depends on VXLAN || !VXLAN bool So i understand that every one agree to use solution #2 ? > > It is unfortunate kconfig doesn't have a language feature for this > > idiom, as the above is confounding without a lot of kconfig > > knowledge > > > > > I did come up with the IS_REACHABLE() macro originally, but that > > > doesn't mean I think it's a good idea to use it liberally ;-) > > > > It would be nice to have some uniform policy here > > > > I also don't like the IS_REACHABLE solution, it makes this more > > complicated, not less.. > > Just chiming "me too" here. > > IS_REACHABLE() is not a solution, it's a hack to hide a dependency > link > problem under the carpet, in a way that is difficult for the user to > debug and figure out. > > The user thinks they've enabled a feature, but it doesn't get used > anyway, because a builtin depends on something that is a module and > therefore not reachable. Can someone please give me an example where > that kind of behaviour is desirable? > > AFAICT IS_REACHABLE() is becoming more and more common in the kernel, > but arguably it's just making more undesirable configurations > possible. Configurations that should simply be blocked by using > suitable > dependencies on the Kconfig level. > > For example, you have two graphics drivers, one builtin and another > module. Then you have backlight as a module. Using IS_REACHABLE(), > backlight would work in one driver, but not the other. I'm sure there > is > the oddball person who finds this desirable, but the overwhelming > majority would just make the deps such that either you make all of > them > modules, or also require backlight to be builtin. > the previous imply semantics handled this by forcing backlight to be built-in, which worked nicely. > > BR, > Jani. > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] staging: fbtft: fb_st7789v: Initialize the Display
From: Oliver Graute Set Gamma Values and Register Values for the HSD20_IPS Signed-off-by: Oliver Graute --- drivers/staging/fbtft/fb_st7789v.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/fbtft/fb_st7789v.c b/drivers/staging/fbtft/fb_st7789v.c index 84c5af2dc9a0..b0aa96b703a8 100644 --- a/drivers/staging/fbtft/fb_st7789v.c +++ b/drivers/staging/fbtft/fb_st7789v.c @@ -17,8 +17,8 @@ #define DRVNAME "fb_st7789v" #define DEFAULT_GAMMA \ - "70 2C 2E 15 10 09 48 33 53 0B 19 18 20 25\n" \ - "70 2C 2E 15 10 09 48 33 53 0B 19 18 20 25" + "D0 05 0A 09 08 05 2E 44 45 0F 17 16 2B 33\n" \ + "D0 05 0A 09 08 05 2E 43 45 0F 16 16 2B 33" /** * enum st7789v_command - ST7789V display controller commands @@ -83,13 +83,13 @@ static int init_display(struct fbtft_par *par) /* set pixel format to RGB-565 */ write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, MIPI_DCS_PIXEL_FMT_16BIT); - write_reg(par, PORCTRL, 0x08, 0x08, 0x00, 0x22, 0x22); + write_reg(par, PORCTRL, 0x05, 0x05, 0x00, 0x33, 0x33); /* * VGH = 13.26V * VGL = -10.43V */ - write_reg(par, GCTRL, 0x35); + write_reg(par, GCTRL, 0x75); /* * VDV and VRH register values come from command write @@ -101,13 +101,13 @@ static int init_display(struct fbtft_par *par) * VAP = 4.1V + (VCOM + VCOM offset + 0.5 * VDV) * VAN = -4.1V + (VCOM + VCOM offset + 0.5 * VDV) */ - write_reg(par, VRHS, 0x0B); + write_reg(par, VRHS, 0x13); /* VDV = 0V */ write_reg(par, VDVS, 0x20); /* VCOM = 0.9V */ - write_reg(par, VCOMS, 0x20); + write_reg(par, VCOMS, 0x22); /* VCOM offset = 0V */ write_reg(par, VCMOFSET, 0x20); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/tve200: Checking for a failed platform_get_irq() call in tve200_probe()
Hi Markus.
On Thu, Apr 09, 2020 at 03:05:17PM +0200, Markus Elfring wrote:
> Hello,
>
> I have taken another look at the implementation of the function
> “tve200_probe”.
> A software analysis approach points the following source code out for
> further development considerations.
> https://elixir.bootlin.com/linux/v5.6.3/source/drivers/gpu/drm/tve200/tve200_drv.c#L212
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/tve200/tve200_drv.c?id=5d30bcacd91af6874481129797af364a53cd9b46#n212
>
> irq = platform_get_irq(pdev, 0);
> if (!irq) {
> ret = -EINVAL;
> goto clk_disable;
> }
>
>
> The software documentation is providing the following information
> for the used programming interface.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/platform.c?id=5d30bcacd91af6874481129797af364a53cd9b46#n221
> https://elixir.bootlin.com/linux/v5.6.3/source/drivers/base/platform.c#L202
>
> “…
> * Return: IRQ number on success, negative error number on failure.
> …”
>
> Would you like to reconsider the shown condition check?
Thansk for spotting this.
The right way to check for errors is to check if the return value is
less than 0.
Could you please audit all uses of platform_get_irq() in drivers/gpu/
and send a series of patches, one for each driver.
A quick "git grep -C 5 platform_get_irq" identified a few extra drivers
that does not implement the recommend way to check for errors.
Try to be a bit more terse in the changelog - but refer to
the documentation of platform_get_irq():
* Example:
* int irq = platform_get_irq(pdev, 0);
* if (irq < 0)
* return irq;
Easier to embed it - rather than to link it.
Fine with links in the intro mail.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/5] drm: bridge: dw_mipi_dsi: abstract register access using reg_fields
Hi Andrzej, Thank you for the feedback, I really appreciate it, replies are below. On Mon, 06 Apr 2020, Andrzej Hajda wrote: W dniu 30.03.2020 o 13:35, Adrian Ratiu pisze: Register existence, address/offsets, field layouts, reserved bits and so on differ between MIPI-DSI versions and between SoC vendor boards. Despite these differences the hw IP and protocols are mostly the same so the generic bridge can be made to compensate these differences. The current Rockchip and STM drivers hardcoded a lot of their common definitions in the bridge code because they're based on DSI v1.30 and 1.31 which are relatively close, but in order to support older/future versions with more diverging layouts like the v1.01 present on imx6, we abstract some of the register accesses via the regmap field APIs. The bridge detects the DSI core version and initializes the required regmap register layout. Other DSI versions / register layouts can easily be added in the future by only changing the bridge code. The platform drivers don't require any changes, DSI register layout versioning will be handled transparently by the bridge, but if in the future the regmap or layouts needs to be exposed to the drivres, it could easily be done via plat_data or a new API in dw_mipi_dsi.h. Suggested-by: Boris Brezillon Reviewed-by: Emil Velikov Signed-off-by: Adrian Ratiu --- Changes since v4: - Move regmap infrastructure logic to a separate commit (Ezequiel) - Consolidate field infrastructure in this commit (Ezequiel) - Move the dsi v1.01 layout logic to a separate commit (Ezequiel) Changes since v2: - Added const declarations to dw_mipi_dsi structs (Emil) - Fixed commit tags (Emil) Changes since v1: - Moved register definitions & regmap initialization into bridge module. Platform drivers get the regmap via plat_data after calling the bridge probe (Emil). --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 510 -- 1 file changed, 352 insertions(+), 158 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index 6d9e2f21c9cc..5b78ff925af0 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -31,6 +31,7 @@ #include #define HWVER_131 0x31333100 /* IP version 1.31 */ +#define HWVER_130 0x31333000 /* IP version 1.30 */ #define DSI_VERSION 0x00 #define VERSIONGENMASK(31, 8) @@ -47,7 +48,6 @@ #define DPI_VCID(vcid) ((vcid) & 0x3) #define DSI_DPI_COLOR_CODING 0x10 -#define LOOSELY18_EN BIT(8) #define DPI_COLOR_CODING_16BIT_1 0x0 #define DPI_COLOR_CODING_16BIT_2 0x1 #define DPI_COLOR_CODING_16BIT_3 0x2 @@ -56,11 +56,6 @@ #define DPI_COLOR_CODING_24BIT 0x5 #define DSI_DPI_CFG_POL 0x14 -#define COLORM_ACTIVE_LOW BIT(4) -#define SHUTD_ACTIVE_LOW BIT(3) -#define HSYNC_ACTIVE_LOW BIT(2) -#define VSYNC_ACTIVE_LOW BIT(1) -#define DATAEN_ACTIVE_LOW BIT(0) #define DSI_DPI_LP_CMD_TIM 0x18 #define OUTVACT_LPCMD_TIME(p) (((p) & 0xff) << 16) @@ -81,27 +76,19 @@ #define DSI_GEN_VCID 0x30 #define DSI_MODE_CFG 0x34 -#define ENABLE_VIDEO_MODE 0 -#define ENABLE_CMD_MODE BIT(0) #define DSI_VID_MODE_CFG 0x38 -#define ENABLE_LOW_POWER (0x3f << 8) -#define ENABLE_LOW_POWER_MASK (0x3f << 8) +#define ENABLE_LOW_POWER 0x3f + #define VID_MODE_TYPE_NON_BURST_SYNC_PULSES 0x0 #define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS 0x1 #define VID_MODE_TYPE_BURST 0x2 -#define VID_MODE_TYPE_MASK 0x3 -#define VID_MODE_VPG_ENABLE BIT(16) -#define VID_MODE_VPG_HORIZONTAL BIT(24) #define DSI_VID_PKT_SIZE 0x3c -#define VID_PKT_SIZE(p) ((p) & 0x3fff) #define DSI_VID_NUM_CHUNKS 0x40 -#define VID_NUM_CHUNKS(c) ((c) & 0x1fff) #define DSI_VID_NULL_SIZE 0x44 -#define VID_NULL_SIZE(b) ((b) & 0x1fff) #define DSI_VID_HSA_TIME 0x48 #define DSI_VID_HBP_TIME 0x4c @@ -125,7 +112,6 @@ #define GEN_SW_2P_TX_LP BIT(10) #define GEN_SW_1P_TX_LP BIT(9) #define GEN_SW_0P_TX_LP BIT(8) -#define ACK_RQST_EN BIT(1) #define TEAR_FX_EN BIT(0) #define CMD_MODE_ALL_LP (MAX_RD_PKT_SIZE_LP | \ @@ -154,8 +140,6 @@ #define GEN_CMD_EMPTY BIT(0) #define DSI_TO_CNT_CFG 0x78 -#define HSTX_TO_CNT(p) (((p) & 0x) << 16) -#define LPRX_TO_CNT(p) ((p) & 0x) #define DSI_HS_RD_TO_CNT 0x7c #define DSI_LP_RD_TO_CNT 0x80 @@ -164,52 +148,17 @@ #define DSI_BTA_TO_CNT 0x8c #define DSI_LPCLK_CTRL 0x94 -#define AUTO_CLKLANE_CTRL BIT(1) -#define PHY_TXREQUESTCLKHS BIT(0) - #define DSI_PHY_TMR_LPCLK_CFG 0x98 -#define PHY_CLKHS2LP_TIME(lbcc) (((lbcc) & 0x3ff) << 16) -#define PHY_CLKLP2HS_TIME(lbcc) ((lbcc) & 0x3ff) - #define DSI_PHY_TMR_CFG 0x9c -#define PHY_HS2LP_TIME(lbcc) (((lbcc) & 0xff) << 24) -#define PHY_LP2HS_TIME(lbcc) (((lbcc) & 0xff) << 16) -#define MAX_RD_TIME(lbcc) ((
Re: [PATCH v11 0/2] drm: bridge: Add NWL MIPI DSI host controller support
Hi, On Thu, Apr 09, 2020 at 04:01:30PM +0200, Sam Ravnborg wrote: > Hi Guido. > > On Thu, Apr 09, 2020 at 12:42:00PM +0200, Guido Günther wrote: > > This adds initial support for the NWL MIPI DSI Host controller found on > > i.MX8 > > SoCs. > > > > It adds support for the i.MX8MQ but the same IP core can also be found on > > e.g. > > i.MX8QXP. I added the necessary hooks to support other imx8 variants but > > since > > I only have imx8mq boards to test I omitted the platform data for other > > SoCs. > > > > The code is based on NXPs BSP so I added Robert Chiras as Co-authored-by. > > > > The most notable changes over the BSP driver are > > - Calculate HS mode timing from phy_configure_opts_mipi_dphy > > - Perform all clock setup via DT > > - Merge nwl-imx and nwl drivers > > - Add B0 silion revision quirk > > - become a bridge driver to hook into mxsfb / dcss > >imx-display-subsystem so it makes sense to make it drive a bridge for > > dsi as > >well). > > - Use panel_bridge to attach the panel > > - Use multiplex framework instead of accessing syscon directly > > > > This has been tested on a Librem 5 devkit using mxsfb with Robert's > > patches[1] > > and the mainline rocktech-jh057n00900 DSI panel driver on next-20200317 and > > on > > the Librem5 with the a Mantix MLAF057WE51-X DSI panel driver (not yet > > mainline) > > The DCSS (submitted for mainline inclusion now too) can also act as input > > source. > > Thanks for your persistence with this driver. > I got ack from Laurent on IRC to apply it (not for the driver as he had > no time to review it). > So applied to drm-misc-next now. > > I look forward for the update to support DRM_BRIDGE_ATTACH_NO_CONNECTOR > in this driver and the corresponding display driver. Thanks. I'll have a look at that (currently checking where the larger mxsfb rework of Laurent is going so i can use that as a base eventually). Cheers, -- Guido ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: Break out the loops if need_resched in bo delayed delete worker
The delayed delete list is per device which might be very huge. And in
a heavy workload test, the list might always not be empty. That will
trigger any RCU stall warnings or softlockups in non-preemptible kernels
Lets do break out the loops in that case.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9e07c3f75156..c5b516fa4eae 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -518,7 +518,7 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device
*bdev, bool remove_all)
INIT_LIST_HEAD(&removed);
spin_lock(&glob->lru_lock);
- while (!list_empty(&bdev->ddestroy)) {
+ while (!list_empty(&bdev->ddestroy) && !need_resched()) {
struct ttm_buffer_object *bo;
bo = list_first_entry(&bdev->ddestroy, struct ttm_buffer_object,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
Hi Guido,
Thank you for the patch.
On Thu, Apr 09, 2020 at 12:42:01PM +0200, Guido Günther wrote:
> The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
>
> Signed-off-by: Guido Günther
> Tested-by: Robert Chiras
> Reviewed-by: Rob Herring
> Acked-by: Sam Ravnborg
> Reviewed-by: Fabio Estevam
> ---
> .../bindings/display/bridge/nwl-dsi.yaml | 226 ++
> 1 file changed, 226 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> new file mode 100644
> index ..8aff2d68fc33
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> @@ -0,0 +1,226 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Northwest Logic MIPI-DSI controller on i.MX SoCs
> +
> +maintainers:
> + - Guido Gúnther
> + - Robert Chiras
> +
> +description: |
> + NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi
> bridge for
> + the SOCs NWL MIPI-DSI host controller.
> +
> +properties:
> + compatible:
> +const: fsl,imx8mq-nwl-dsi
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 0
> +
> + clocks:
> +items:
> + - description: DSI core clock
> + - description: RX_ESC clock (used in escape mode)
> + - description: TX_ESC clock (used in escape mode)
> + - description: PHY_REF clock
> + - description: LCDIF clock
> +
> + clock-names:
> +items:
> + - const: core
> + - const: rx_esc
> + - const: tx_esc
> + - const: phy_ref
> + - const: lcdif
> +
> + mux-controls:
> +description:
> + mux controller node to use for operating the input mux
> +
> + phys:
> +maxItems: 1
> +description:
> + A phandle to the phy module representing the DPHY
> +
> + phy-names:
> +items:
> + - const: dphy
> +
> + power-domains:
> +maxItems: 1
> +
> + resets:
> +items:
> + - description: dsi byte reset line
> + - description: dsi dpi reset line
> + - description: dsi esc reset line
> + - description: dsi pclk reset line
> +
> + reset-names:
> +items:
> + - const: byte
> + - const: dpi
> + - const: esc
> + - const: pclk
> +
> + ports:
> +type: object
> +description:
> + A node containing DSI input & output port nodes with endpoint
> + definitions as documented in
> + Documentation/devicetree/bindings/graph.txt.
> +properties:
> + port@0:
> +type: object
> +description:
> + Input port node to receive pixel data from the
> + display controller. Exactly one endpoint must be
> + specified.
> +properties:
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 0
> +
> + endpoint@0:
> +description: sub-node describing the input from LCDIF
> +type: object
> +
> + endpoint@1:
> +description: sub-node describing the input from DCSS
> +type: object
This models the two inputs to the IP core, that are connected to a mux
internally, controlled through mux-controls, right ? Why is a single
endpoint supported then, if there are two connections at the hardware
level, and why is this using endpoints instead of ports as there are
really two input ports ?
Apart from that the bindings look ok to me.
> +
> + reg:
> +const: 0
> +
> +required:
> + - '#address-cells'
> + - '#size-cells'
> + - reg
> +
> +oneOf:
> + - required:
> + - endpoint@0
> + - required:
> + - endpoint@1
> +
> +additionalProperties: false
> +
> + port@1:
> +type: object
> +description:
> + DSI output port node to the panel or the next bridge
> + in the chain
> +
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 0
> +
> +required:
> + - '#address-cells'
> + - '#size-cells'
> + - port@0
> + - port@1
> +
> +additionalProperties: false
> +
> +patternProperties:
> + "^panel@[0-9]+$":
> +type: object
> +
> +required:
> + - '#address-cells'
> + - '#size-cells'
> + - clock-names
> + - clocks
> + - compatible
> + - interrupts
> + - mux-controls
> + - phy-names
> + - phys
> + - ports
> + - reg
> + - reset-names
> + - resets
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +
> + #include
> + #include
> + #include
> +
> + mipi_dsi: mipi_dsi@30a0 {
> +
[Bug 207183] radeon.dpm=1 with second monitor runs hot
https://bugzilla.kernel.org/show_bug.cgi?id=207183 --- Comment #1 from Erik Huelsmann (ehu...@gmail.com) --- Note that the system doesn't exhibit this problem when only a single monitor is attached. Monitor output in use: HDMI. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: remove redundant assignment to variable dp_ref_clk_khz
From: Colin Ian King
The variable dp_ref_clk_khz is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c
index 26db1c5d4e4d..b210f8e9d592 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c
@@ -131,7 +131,7 @@ int dce_get_dp_ref_freq_khz(struct clk_mgr *clk_mgr_base)
struct clk_mgr_internal *clk_mgr = TO_CLK_MGR_INTERNAL(clk_mgr_base);
int dprefclk_wdivider;
int dprefclk_src_sel;
- int dp_ref_clk_khz = 60;
+ int dp_ref_clk_khz;
int target_div;
/* ASSERT DP Reference Clock source is from DFS*/
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm/i915: Fix ref->mutex deadlock in i915_active_wait()" has been added to the 5.4-stable tree
This is a note to let you know that I've just added the patch titled
drm/i915: Fix ref->mutex deadlock in i915_active_wait()
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-fix-ref-mutex-deadlock-in-i915_active_wait.patch
and it can be found in the queue-5.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From sul...@kerneltoast.com Fri Apr 10 11:07:34 2020
From: Sultan Alsawaf
Date: Tue, 7 Apr 2020 00:18:09 -0700
Subject: drm/i915: Fix ref->mutex deadlock in i915_active_wait()
To: Greg KH
Cc: sta...@vger.kernel.org, Jani Nikula , Joonas
Lahtinen , Rodrigo Vivi
, David Airlie , Daniel Vetter
, Chris Wilson ,
intel-...@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Sultan
Alsawaf
Message-ID: <20200407071809.3148-1-sul...@kerneltoast.com>
From: Sultan Alsawaf
The following deadlock exists in i915_active_wait() due to a double lock
on ref->mutex (call chain listed in order from top to bottom):
i915_active_wait();
mutex_lock_interruptible(&ref->mutex); <-- ref->mutex first acquired
i915_active_request_retire();
node_retire();
active_retire();
mutex_lock_nested(&ref->mutex, SINGLE_DEPTH_NESTING); <-- DEADLOCK
Fix the deadlock by skipping the second ref->mutex lock when
active_retire() is called through i915_active_request_retire().
Note that this bug only affects 5.4 and has since been fixed in 5.5.
Normally, a backport of the fix from 5.5 would be in order, but the
patch set that fixes this deadlock involves massive changes that are
neither feasible nor desirable for backporting [1][2][3]. Therefore,
this small patch was made to address the deadlock specifically for 5.4.
[1] 274cbf20fd10 ("drm/i915: Push the i915_active.retire into a worker")
[2] 093b92287363 ("drm/i915: Split i915_active.mutex into an irq-safe spinlock
for the rbtree")
[3] 750bde2fd4ff ("drm/i915: Serialise with remote retirement")
Fixes: 12c255b5dad1 ("drm/i915: Provide an i915_active.acquire callback")
Cc: # 5.4.x
Signed-off-by: Sultan Alsawaf
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/i915_active.c | 27 +++
drivers/gpu/drm/i915/i915_active.h |4 ++--
2 files changed, 25 insertions(+), 6 deletions(-)
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -120,13 +120,17 @@ static inline void debug_active_assert(s
#endif
+#define I915_ACTIVE_RETIRE_NOLOCK BIT(0)
+
static void
__active_retire(struct i915_active *ref)
{
struct active_node *it, *n;
struct rb_root root;
bool retire = false;
+ unsigned long bits;
+ ref = ptr_unpack_bits(ref, &bits, 2);
lockdep_assert_held(&ref->mutex);
/* return the unused nodes to our slabcache -- flushing the allocator */
@@ -138,7 +142,8 @@ __active_retire(struct i915_active *ref)
retire = true;
}
- mutex_unlock(&ref->mutex);
+ if (!(bits & I915_ACTIVE_RETIRE_NOLOCK))
+ mutex_unlock(&ref->mutex);
if (!retire)
return;
@@ -155,13 +160,18 @@ __active_retire(struct i915_active *ref)
static void
active_retire(struct i915_active *ref)
{
+ struct i915_active *ref_packed = ref;
+ unsigned long bits;
+
+ ref = ptr_unpack_bits(ref, &bits, 2);
GEM_BUG_ON(!atomic_read(&ref->count));
if (atomic_add_unless(&ref->count, -1, 1))
return;
/* One active may be flushed from inside the acquire of another */
- mutex_lock_nested(&ref->mutex, SINGLE_DEPTH_NESTING);
- __active_retire(ref);
+ if (!(bits & I915_ACTIVE_RETIRE_NOLOCK))
+ mutex_lock_nested(&ref->mutex, SINGLE_DEPTH_NESTING);
+ __active_retire(ref_packed);
}
static void
@@ -170,6 +180,14 @@ node_retire(struct i915_active_request *
active_retire(node_from_active(base)->ref);
}
+static void
+node_retire_nolock(struct i915_active_request *base, struct i915_request *rq)
+{
+ struct i915_active *ref = node_from_active(base)->ref;
+
+ active_retire(ptr_pack_bits(ref, I915_ACTIVE_RETIRE_NOLOCK, 2));
+}
+
static struct i915_active_request *
active_instance(struct i915_active *ref, struct intel_timeline *tl)
{
@@ -421,7 +439,8 @@ int i915_active_wait(struct i915_active
break;
}
- err = i915_active_request_retire(&it->base, BKL(ref));
+ err = i915_active_request_retire(&it->base, BKL(ref),
+node_retire_nolock);
if (err)
break;
}
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -309,7 +309,7 @@ i915_active_request_isset(const struct i
*/
static inline int __must_check
i915_active_request_retire(stru
[Bug 207183] radeon.dpm=1 with second monitor runs hot
https://bugzilla.kernel.org/show_bug.cgi?id=207183 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- Note that the memory clock runs at high when multiple monitors are attached because changing the memory clock has to happen during vblank time to avoid glitches on the screen and with multiple monitors that is not aligned. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/tve200: Checking for a failed platform_get_irq() call in tve200_probe()
Hi Markus. On Fri, Apr 10, 2020 at 12:56:25PM +0200, Markus Elfring wrote: > > The right way to check for errors is to check if the return value is > > less than 0. > > Thanks for your constructive feedback. > > I was unsure if I noticed another programming mistake. > > > > Could you please audit all uses of platform_get_irq() in drivers/gpu/ > > I found 20 source files from the software “Linux next-20200408” > which seem to contain similar update candidates. > Would you like to clarify any extensions for improved applications > of scripts with the semantic patch language (Coccinelle software) > for corresponding analysis and transformation purposes? Please just send a series of patches, one for each driver. Each changelog needs to explain the rationale behind the change. Look at how this is often done. As for coccinelle - I cannot help you. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Break out the loops if need_resched in bo delayed delete worker
Am 10.04.2020 12:58 schrieb "Pan, Xinhui" :
The delayed delete list is per device which might be very huge. And in
a heavy workload test, the list might always not be empty. That will
trigger any RCU stall warnings or softlockups in non-preemptible kernels
Lets do break out the loops in that case.
Signed-off-by: xinhui pan
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9e07c3f75156..c5b516fa4eae 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -518,7 +518,7 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device
*bdev, bool remove_all)
INIT_LIST_HEAD(&removed);
spin_lock(&glob->lru_lock);
- while (!list_empty(&bdev->ddestroy)) {
+ while (!list_empty(&bdev->ddestroy) && !need_resched()) {
struct ttm_buffer_object *bo;
bo = list_first_entry(&bdev->ddestroy, struct
ttm_buffer_object,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207183] radeon.dpm=1 with second monitor runs hot
https://bugzilla.kernel.org/show_bug.cgi?id=207183 --- Comment #3 from Erik Huelsmann (ehu...@gmail.com) --- Thanks for commenting. Does 'radeon.dpm=0' suppress that? I'm not having issues when I set that parameter on the kernel command line. -- 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 207183] radeon.dpm=1 with second monitor runs hot
https://bugzilla.kernel.org/show_bug.cgi?id=207183 --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Erik Huelsmann from comment #3) > Thanks for commenting. Does 'radeon.dpm=0' suppress that? I'm not having > issues when I set that parameter on the kernel command line. That leave the GPU with the boot up clocks which are low. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
Hi Laurent, On Fri, Apr 10, 2020 at 02:23:42PM +0300, Laurent Pinchart wrote: > Hi Guido, > > Thank you for the patch. > > On Thu, Apr 09, 2020 at 12:42:01PM +0200, Guido Günther wrote: > > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs. > > > > Signed-off-by: Guido Günther > > Tested-by: Robert Chiras > > Reviewed-by: Rob Herring > > Acked-by: Sam Ravnborg > > Reviewed-by: Fabio Estevam > > --- > > .../bindings/display/bridge/nwl-dsi.yaml | 226 ++ > > 1 file changed, 226 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml > > b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml > > new file mode 100644 > > index ..8aff2d68fc33 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml > > @@ -0,0 +1,226 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Northwest Logic MIPI-DSI controller on i.MX SoCs > > + > > +maintainers: > > + - Guido Gúnther > > + - Robert Chiras > > + > > +description: | > > + NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi > > bridge for > > + the SOCs NWL MIPI-DSI host controller. > > + > > +properties: > > + compatible: > > +const: fsl,imx8mq-nwl-dsi > > + > > + reg: > > +maxItems: 1 > > + > > + interrupts: > > +maxItems: 1 > > + > > + '#address-cells': > > +const: 1 > > + > > + '#size-cells': > > +const: 0 > > + > > + clocks: > > +items: > > + - description: DSI core clock > > + - description: RX_ESC clock (used in escape mode) > > + - description: TX_ESC clock (used in escape mode) > > + - description: PHY_REF clock > > + - description: LCDIF clock > > + > > + clock-names: > > +items: > > + - const: core > > + - const: rx_esc > > + - const: tx_esc > > + - const: phy_ref > > + - const: lcdif > > + > > + mux-controls: > > +description: > > + mux controller node to use for operating the input mux > > + > > + phys: > > +maxItems: 1 > > +description: > > + A phandle to the phy module representing the DPHY > > + > > + phy-names: > > +items: > > + - const: dphy > > + > > + power-domains: > > +maxItems: 1 > > + > > + resets: > > +items: > > + - description: dsi byte reset line > > + - description: dsi dpi reset line > > + - description: dsi esc reset line > > + - description: dsi pclk reset line > > + > > + reset-names: > > +items: > > + - const: byte > > + - const: dpi > > + - const: esc > > + - const: pclk > > + > > + ports: > > +type: object > > +description: > > + A node containing DSI input & output port nodes with endpoint > > + definitions as documented in > > + Documentation/devicetree/bindings/graph.txt. > > +properties: > > + port@0: > > +type: object > > +description: > > + Input port node to receive pixel data from the > > + display controller. Exactly one endpoint must be > > + specified. > > +properties: > > + '#address-cells': > > +const: 1 > > + > > + '#size-cells': > > +const: 0 > > + > > + endpoint@0: > > +description: sub-node describing the input from LCDIF > > +type: object > > + > > + endpoint@1: > > +description: sub-node describing the input from DCSS > > +type: object > > This models the two inputs to the IP core, that are connected to a mux > internally, controlled through mux-controls, right ? Why is a single > endpoint supported then, if there are two connections at the hardware > level, and why is this using endpoints instead of ports as there are > really two input ports ? That came out of https://lore.kernel.org/linux-arm-kernel/c86b7ca2-7799-eafd-c380-e4b551520...@samsung.com/ # If the ip has separate lines for DCSS and LCDIF you should distinguish # by port number. If they are shared # you can use endpoint number to specify DCSS or LCDIF, in both cases # bindings should be adjusted. I read that as - distinguish by endpoint number: eLCDIF--\| | nwl DCSS/| - distinguish by port number: eLCDIF---| | nwl DCSS | >From the imx8mq ref manual i didn't see separate input lines for DCSS vs eLCDIF the the NWL IP so i went with endpoints instead of ports. I'm happy to change that if i got it wrong. Cheers, -- Guido > > Apart from that the bindings look ok to me. > > > + > > + reg: > > +const: 0 > > + > > +required: > > + - '#addre
Re: [PATCH v11 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
Hi Guido, On Fri, Apr 10, 2020 at 02:45:16PM +0200, Guido Günther wrote: > On Fri, Apr 10, 2020 at 02:23:42PM +0300, Laurent Pinchart wrote: > > On Thu, Apr 09, 2020 at 12:42:01PM +0200, Guido Günther wrote: > > > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs. > > > > > > Signed-off-by: Guido Günther > > > Tested-by: Robert Chiras > > > Reviewed-by: Rob Herring > > > Acked-by: Sam Ravnborg > > > Reviewed-by: Fabio Estevam > > > --- > > > .../bindings/display/bridge/nwl-dsi.yaml | 226 ++ > > > 1 file changed, 226 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml > > > b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml > > > new file mode 100644 > > > index ..8aff2d68fc33 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml > > > @@ -0,0 +1,226 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Northwest Logic MIPI-DSI controller on i.MX SoCs > > > + > > > +maintainers: > > > + - Guido Gúnther > > > + - Robert Chiras > > > + > > > +description: | > > > + NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi > > > bridge for > > > + the SOCs NWL MIPI-DSI host controller. > > > + > > > +properties: > > > + compatible: > > > +const: fsl,imx8mq-nwl-dsi > > > + > > > + reg: > > > +maxItems: 1 > > > + > > > + interrupts: > > > +maxItems: 1 > > > + > > > + '#address-cells': > > > +const: 1 > > > + > > > + '#size-cells': > > > +const: 0 > > > + > > > + clocks: > > > +items: > > > + - description: DSI core clock > > > + - description: RX_ESC clock (used in escape mode) > > > + - description: TX_ESC clock (used in escape mode) > > > + - description: PHY_REF clock > > > + - description: LCDIF clock > > > + > > > + clock-names: > > > +items: > > > + - const: core > > > + - const: rx_esc > > > + - const: tx_esc > > > + - const: phy_ref > > > + - const: lcdif > > > + > > > + mux-controls: > > > +description: > > > + mux controller node to use for operating the input mux > > > + > > > + phys: > > > +maxItems: 1 > > > +description: > > > + A phandle to the phy module representing the DPHY > > > + > > > + phy-names: > > > +items: > > > + - const: dphy > > > + > > > + power-domains: > > > +maxItems: 1 > > > + > > > + resets: > > > +items: > > > + - description: dsi byte reset line > > > + - description: dsi dpi reset line > > > + - description: dsi esc reset line > > > + - description: dsi pclk reset line > > > + > > > + reset-names: > > > +items: > > > + - const: byte > > > + - const: dpi > > > + - const: esc > > > + - const: pclk > > > + > > > + ports: > > > +type: object > > > +description: > > > + A node containing DSI input & output port nodes with endpoint > > > + definitions as documented in > > > + Documentation/devicetree/bindings/graph.txt. > > > +properties: > > > + port@0: > > > +type: object > > > +description: > > > + Input port node to receive pixel data from the > > > + display controller. Exactly one endpoint must be > > > + specified. > > > +properties: > > > + '#address-cells': > > > +const: 1 > > > + > > > + '#size-cells': > > > +const: 0 > > > + > > > + endpoint@0: > > > +description: sub-node describing the input from LCDIF > > > +type: object > > > + > > > + endpoint@1: > > > +description: sub-node describing the input from DCSS > > > +type: object > > > > This models the two inputs to the IP core, that are connected to a mux > > internally, controlled through mux-controls, right ? Why is a single > > endpoint supported then, if there are two connections at the hardware > > level, and why is this using endpoints instead of ports as there are > > really two input ports ? > > That came out of > > https://lore.kernel.org/linux-arm-kernel/c86b7ca2-7799-eafd-c380-e4b551520...@samsung.com/ > > # If the ip has separate lines for DCSS and LCDIF you should distinguish > # by port number. If they are shared > # you can use endpoint number to specify DCSS or LCDIF, in both cases > # bindings should be adjusted. > > I read that as > > - distinguish by endpoint number: > > eLCDIF--\| > | nwl > DCSS/| > > - distinguish by port number: > > eLCDIF---| > | nwl > DCSS | I fully agree with you
Re: [PATCH] AMDGPU: Correctly initialize thermal controller for GPUs with Powerplay table v0 (e.g Hawaii)
Hello,
Can someone please look at this patch? It would be nice to get it
merged in, so that others using the Hawaii GPU can get proper fan
speeds reported. Thanks in advance.
Yours sincerely,
Sandeep
On Sun, 5 Apr 2020 at 22:22, Sandeep wrote:
>
> This is required for the AMDGPU driver to report fan speed for Hawaii
> GPUs (otherwise the fan speed is just reported as 0)
> ---
> .../drm/amd/powerplay/hwmgr/processpptables.c | 28 +++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> index 77c14671866c..bb58cfab1033 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> @@ -984,6 +984,34 @@ static int init_thermal_controller(
> struct pp_hwmgr *hwmgr,
> const ATOM_PPLIB_POWERPLAYTABLE *powerplay_table)
> {
> + hwmgr->thermal_controller.ucType =
> + powerplay_table->sThermalController.ucType;
> + hwmgr->thermal_controller.ucI2cLine =
> + powerplay_table->sThermalController.ucI2cLine;
> + hwmgr->thermal_controller.ucI2cAddress =
> + powerplay_table->sThermalController.ucI2cAddress;
> +
> + hwmgr->thermal_controller.fanInfo.bNoFan =
> + (0 != (powerplay_table->sThermalController.ucFanParameters &
> + ATOM_PP_FANPARAMETERS_NOFAN));
> +
> + hwmgr->thermal_controller.fanInfo.ucTachometerPulsesPerRevolution =
> + powerplay_table->sThermalController.ucFanParameters &
> + ATOM_PP_FANPARAMETERS_TACHOMETER_PULSES_PER_REVOLUTION_MASK;
> +
> + hwmgr->thermal_controller.fanInfo.ulMinRPM
> + = powerplay_table->sThermalController.ucFanMinRPM * 100UL;
> + hwmgr->thermal_controller.fanInfo.ulMaxRPM
> + = powerplay_table->sThermalController.ucFanMaxRPM * 100UL;
> +
> + set_hw_cap(
> + hwmgr,
> + ATOM_PP_THERMALCONTROLLER_NONE != hwmgr->thermal_controller.ucType,
> + PHM_PlatformCaps_ThermalController
> + );
> +
> + hwmgr->thermal_controller.use_hw_fan_control = 1;
> +
> return 0;
> }
>
> --
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207183] radeon.dpm=1 with second monitor runs hot
https://bugzilla.kernel.org/show_bug.cgi?id=207183 --- Comment #5 from Erik Huelsmann (ehu...@gmail.com) --- Is the fact that it's apparently not possible to switch the memory clock with 2 monitors attached a design error in the hardware? Unfortunately, I don't have the Windows setup anymore to investigate it. I'm extremely happy with my 'radeon.dpm=0' setup, because I'm only doing text-editing, programming and web browsing. As I understand it, it's a choice where you have to run a high clock continually or cause possible on-screen glitches? That's too bad. I personally wouldn't mind a small flicker if that would help the noise of my laptop, but I do understand others may make other choices here. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 04/10] PM / EM: add support for other devices than CPUs in Energy Model
Hi Lukasz,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20200409]
[cannot apply to pm/linux-next tip/sched/core linus/master linux/master v5.6
v5.6-rc7 v5.6-rc6 v5.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Lukasz-Luba/Add-support-for-devices-in-the-Energy-Model/20200410-172456
base:873e37a44b1ee8ad4628ca257dc51c0c7c654326
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
cppcheck warnings: (new ones prefixed by >>)
>> kernel/power/energy_model.c:394:15: warning: Variable 'ret' is assigned a
>> value that is never used. [unreadVariable]
int cpu, ret = 0;
^
vim +/ret +394 kernel/power/energy_model.c
27871f7a8a341e Quentin Perret 2018-12-03 370
27871f7a8a341e Quentin Perret 2018-12-03 371 /**
b4dc5cca354b8a Lukasz Luba 2020-04-10 372 *
em_dev_register_perf_domain() - Register the Energy Model (EM) for a device
b4dc5cca354b8a Lukasz Luba 2020-04-10 373 * @dev : Device for
which the EM is to register
1ccc27ced21bf5 Lukasz Luba 2020-04-10 374 * @nr_states : Number of
performance states to register
27871f7a8a341e Quentin Perret 2018-12-03 375 * @cb : Callback
functions providing the data of the Energy Model
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 376 * @cpus: Pointer to
cpumask_t, which in case of a CPU device is
b4dc5cca354b8a Lukasz Luba 2020-04-10 377 * obligatory. It
can be taken from i.e. 'policy->cpus'. For other
b4dc5cca354b8a Lukasz Luba 2020-04-10 378 * type of devices
this should be set to NULL.
27871f7a8a341e Quentin Perret 2018-12-03 379 *
27871f7a8a341e Quentin Perret 2018-12-03 380 * Create Energy Model tables
for a performance domain using the callbacks
27871f7a8a341e Quentin Perret 2018-12-03 381 * defined in cb.
27871f7a8a341e Quentin Perret 2018-12-03 382 *
27871f7a8a341e Quentin Perret 2018-12-03 383 * If multiple clients register
the same performance domain, all but the first
27871f7a8a341e Quentin Perret 2018-12-03 384 * registration will be ignored.
27871f7a8a341e Quentin Perret 2018-12-03 385 *
27871f7a8a341e Quentin Perret 2018-12-03 386 * Return 0 on success
27871f7a8a341e Quentin Perret 2018-12-03 387 */
b4dc5cca354b8a Lukasz Luba 2020-04-10 388 int
em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 389
struct em_data_callback *cb, cpumask_t *cpus)
27871f7a8a341e Quentin Perret 2018-12-03 390 {
27871f7a8a341e Quentin Perret 2018-12-03 391 unsigned long cap,
prev_cap = 0;
27871f7a8a341e Quentin Perret 2018-12-03 392 struct em_perf_domain
*pd;
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 393 struct em_device
*em_dev;
27871f7a8a341e Quentin Perret 2018-12-03 @394 int cpu, ret = 0;
27871f7a8a341e Quentin Perret 2018-12-03 395
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 396 if (!dev || !nr_states
|| !cb)
27871f7a8a341e Quentin Perret 2018-12-03 397 return -EINVAL;
27871f7a8a341e Quentin Perret 2018-12-03 398
27871f7a8a341e Quentin Perret 2018-12-03 399 /*
27871f7a8a341e Quentin Perret 2018-12-03 400 * Use a mutex to
serialize the registration of performance domains and
27871f7a8a341e Quentin Perret 2018-12-03 401 * let the
driver-defined callback functions sleep.
27871f7a8a341e Quentin Perret 2018-12-03 402 */
27871f7a8a341e Quentin Perret 2018-12-03 403
mutex_lock(&em_pd_mutex);
27871f7a8a341e Quentin Perret 2018-12-03 404
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 405 em_dev =
_em_dev_find_existing(dev);
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 406 if (em_dev) {
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 407
mutex_unlock(&em_pd_mutex);
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 408 dev_dbg(dev,
"EM: found exisiting pd%d\n", em_dev->id);
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 409 return -EEXIST;
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 410 }
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 411
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 412 if
(_is_cpu_device(dev)) {
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 413 if (!cpus) {
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 414
mutex_unlock(&em_pd_mutex);
9cf8494b5f4eb8 Lukasz Luba 2020-04-10 415
dev_err(dev, "EM: invalid CPU mask\n");
9
[PATCH 5/7] PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP
From: "Rafael J. Wysocki"
Rename DPM_FLAG_NEVER_SKIP to DPM_FLAG_NO_DIRECT_COMPLETE which
matches its purpose more closely.
No functional impact.
Signed-off-by: Rafael J. Wysocki
---
Documentation/driver-api/pm/devices.rst| 6 +++---
Documentation/power/pci.rst| 10 +-
drivers/base/power/main.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 2 +-
drivers/gpu/drm/i915/intel_runtime_pm.c| 2 +-
drivers/gpu/drm/radeon/radeon_kms.c| 2 +-
drivers/misc/mei/pci-me.c | 2 +-
drivers/misc/mei/pci-txe.c | 2 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/ethernet/intel/igc/igc_main.c | 2 +-
drivers/pci/pcie/portdrv_pci.c | 2 +-
include/linux/pm.h | 6 +++---
13 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/Documentation/driver-api/pm/devices.rst
b/Documentation/driver-api/pm/devices.rst
index f66c7b9126ea..4ace0eba4506 100644
--- a/Documentation/driver-api/pm/devices.rst
+++ b/Documentation/driver-api/pm/devices.rst
@@ -361,9 +361,9 @@ the phases are: ``prepare``, ``suspend``, ``suspend_late``,
``suspend_noirq``.
runtime PM disabled.
This feature also can be controlled by device drivers by using the
- ``DPM_FLAG_NEVER_SKIP`` and ``DPM_FLAG_SMART_PREPARE`` driver power
- management flags. [Typically, they are set at the time the driver is
- probed against the device in question by passing them to the
+ ``DPM_FLAG_NO_DIRECT_COMPLETE`` and ``DPM_FLAG_SMART_PREPARE`` driver
+ power management flags. [Typically, they are set at the time the driver
+ is probed against the device in question by passing them to the
:c:func:`dev_pm_set_driver_flags` helper function.] If the first of
these flags is set, the PM core will not apply the direct-complete
procedure described above to the given device and, consequenty, to any
diff --git a/Documentation/power/pci.rst b/Documentation/power/pci.rst
index aa1c7fce6cd0..9e1408121bea 100644
--- a/Documentation/power/pci.rst
+++ b/Documentation/power/pci.rst
@@ -1004,11 +1004,11 @@ including the PCI bus type. The flags should be set
once at the driver probe
time with the help of the dev_pm_set_driver_flags() function and they should
not
be updated directly afterwards.
-The DPM_FLAG_NEVER_SKIP flag prevents the PM core from using the
direct-complete
-mechanism allowing device suspend/resume callbacks to be skipped if the device
-is in runtime suspend when the system suspend starts. That also affects all of
-the ancestors of the device, so this flag should only be used if absolutely
-necessary.
+The DPM_FLAG_NO_DIRECT_COMPLETE flag prevents the PM core from using the
+direct-complete mechanism allowing device suspend/resume callbacks to be
skipped
+if the device is in runtime suspend when the system suspend starts. That also
+affects all of the ancestors of the device, so this flag should only be used if
+absolutely necessary.
The DPM_FLAG_SMART_PREPARE flag instructs the PCI bus type to only return a
positive value from pci_pm_prepare() if the ->prepare callback provided by the
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 21187ee37b22..aa9c8df9fc4b 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1850,7 +1850,7 @@ static int device_prepare(struct device *dev,
pm_message_t state)
spin_lock_irq(&dev->power.lock);
dev->power.direct_complete = state.event == PM_EVENT_SUSPEND &&
(ret > 0 || dev->power.no_pm_callbacks) &&
- !dev_pm_test_driver_flags(dev, DPM_FLAG_NEVER_SKIP);
+ !dev_pm_test_driver_flags(dev, DPM_FLAG_NO_DIRECT_COMPLETE);
spin_unlock_irq(&dev->power.lock);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index fd1dc3236eca..a9086ea1ab60 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -191,7 +191,7 @@ int amdgpu_driver_load_kms(struct drm_device *dev, unsigned
long flags)
}
if (adev->runpm) {
- dev_pm_set_driver_flags(dev->dev, DPM_FLAG_NEVER_SKIP);
+ dev_pm_set_driver_flags(dev->dev, DPM_FLAG_NO_DIRECT_COMPLETE);
pm_runtime_use_autosuspend(dev->dev);
pm_runtime_set_autosuspend_delay(dev->dev, 5000);
pm_runtime_set_active(dev->dev);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index ad719c9602af..9cb2d7548daa 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -549,7 +549,7 @@ void intel_runtime_pm_enable(struct intel_runtime_pm *rpm)
* becaue the HDA driver may require us to enable the audio power
Re: [PATCH v5 4/4] drm/mediatek: config mipitx impedance with calibration data
Hi, Jitao:
Jitao Shi 於 2020年4月10日 週五 下午12:33寫道：
>
> Read calibration data from nvmem, and config mipitx impedance with
> calibration data to make sure their impedance are 100ohm.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 40 +++
> drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 3 ++
> drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 21 ++
> 3 files changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index e301af64809e..5e91fc2c1318 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -88,6 +88,44 @@ static const struct phy_ops mtk_mipi_tx_ops = {
> .owner = THIS_MODULE,
> };
>
> +static void mtk_mipi_tx_get_calibration_datal(struct mtk_mipi_tx *mipi_tx)
> +{
> + struct nvmem_cell *cell;
> + size_t len;
> + u32 *buf;
> +
> + memset(mipi_tx->rt_code, 0, sizeof(mipi_tx->rt_code));
You use kzalloc() to allocate mipi_tx, so this is already zero-initialized.
> + cell = nvmem_cell_get(mipi_tx->dev, "calibration-data");
> + if (IS_ERR(cell)) {
> + dev_info(mipi_tx->dev, "can't get nvmem_cell_get, ignore
> it\n");
> + } else {
If you return when error, you could get rid of the 'else', so you
could reduce many 'tab' and reduce the probability of one line over 80
character.
> + buf = (u32 *)nvmem_cell_read(cell, &len);
> + nvmem_cell_put(cell);
> +
> + if (IS_ERR(buf)) {
> + dev_info(mipi_tx->dev, "can't get data, ignore it\n");
> + } else {
Ditto.
Regards,
Chun-Kuang.
> + if (len < 3 * sizeof(u32)) {
> + dev_info(mipi_tx->dev, "invalid calibration
> data\n");
> + kfree(buf);
> + return;
> + }
> +
> + mipi_tx->rt_code[0] = ((buf[0] >> 6 & 0x1f) << 5) |
> + (buf[0] >> 11 & 0x1f);
> + mipi_tx->rt_code[1] = ((buf[1] >> 27 & 0x1f) << 5) |
> + (buf[0] >> 1 & 0x1f);
> + mipi_tx->rt_code[2] = ((buf[1] >> 17 & 0x1f) << 5) |
> + (buf[1] >> 22 & 0x1f);
> + mipi_tx->rt_code[3] = ((buf[1] >> 7 & 0x1f) << 5) |
> + (buf[1] >> 12 & 0x1f);
> + mipi_tx->rt_code[4] = ((buf[2] >> 27 & 0x1f) << 5) |
> + (buf[1] >> 2 & 0x1f);
> + kfree(buf);
> + }
> + }
> +}
> +
> static int mtk_mipi_tx_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -174,6 +212,8 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
>
> mipi_tx->dev = dev;
>
> + mtk_mipi_tx_get_calibration_datal(mipi_tx);
> +
> return of_clk_add_provider(dev->of_node, of_clk_src_simple_get,
>mipi_tx->pll);
> }
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> index eea44327fe9f..c76f07c3fdeb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> @@ -12,9 +12,11 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
>
> struct mtk_mipitx_data {
> const u32 mppll_preserve;
> @@ -28,6 +30,7 @@ struct mtk_mipi_tx {
> void __iomem *regs;
> u32 data_rate;
> u32 mipitx_drive;
> + u32 rt_code[5];
> const struct mtk_mipitx_data *driver_data;
> struct clk_hw pll_hw;
> struct clk *pll;
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> index e4cc967750cb..9f3e55aeebb2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> @@ -28,6 +28,7 @@
> #define MIPITX_PLL_CON40x003c
> #define RG_DSI_PLL_IBIAS (3 << 10)
>
> +#define MIPITX_D2P_RTCODE 0x0100
> #define MIPITX_D2_SW_CTL_EN0x0144
> #define MIPITX_D0_SW_CTL_EN0x0244
> #define MIPITX_CK_CKMODE_EN0x0328
> @@ -108,6 +109,24 @@ static const struct clk_ops mtk_mipi_tx_pll_ops = {
> .recalc_rate = mtk_mipi_tx_pll_recalc_rate,
> };
>
> +static void mtk_mipi_tx_config_calibration_data(struct mtk_mipi_tx *mipi_tx)
> +{
> + int i, j;
> +
> + for (i = 0; i < 5; i++) {
> + if ((mipi_tx->rt_code[i] & 0x1f) == 0)
> + mipi_tx->rt_code[i] |= 0x10;
> +
> + if ((mipi_tx->rt_code[i] >> 5 & 0x1f) == 0)
> + mipi_tx->rt_code[i] |= 0x10 << 5;
[Bug 205491] Green external display after wake up
https://bugzilla.kernel.org/show_bug.cgi?id=205491 --- Comment #2 from Łukasz Żarnowiecki (luk...@zarnowiecki.pl) --- Issue still present in 5.6.2. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/22] dt-bindings: memory: tegra30: emc: Document new interconnect property
On Mon, 30 Mar 2020 04:08:46 +0300, Dmitry Osipenko wrote: > External memory controller is interconnected with memory controller and > with external memory. Document new interconnect property which turns > external memory controller into interconnect provider. > > Signed-off-by: Dmitry Osipenko > --- > .../bindings/memory-controllers/nvidia,tegra30-emc.yaml | 6 ++ > 1 file changed, 6 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/22] dt-bindings: memory: tegra20: emc: Document new interconnect property
On Mon, 30 Mar 2020 04:08:44 +0300, Dmitry Osipenko wrote: > External memory controller is interconnected with memory controller and > with external memory. Document new interconnect property which turns > external memory controller into interconnect provider. > > Signed-off-by: Dmitry Osipenko > --- > .../bindings/memory-controllers/nvidia,tegra20-emc.txt | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/22] dt-bindings: memory: tegra20: mc: Document new interconnect property
On Mon, 30 Mar 2020 04:08:43 +0300, Dmitry Osipenko wrote: > Memory controller is interconnected with memory clients and with the > external memory controller. Document new interconnect property which > turns memory controller into interconnect provider. > > Signed-off-by: Dmitry Osipenko > --- > .../bindings/memory-controllers/nvidia,tegra20-mc.txt | 3 +++ > 1 file changed, 3 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/22] dt-bindings: memory: tegra30: mc: Document new interconnect property
On Mon, 30 Mar 2020 04:08:45 +0300, Dmitry Osipenko wrote: > Memory controller is interconnected with memory clients and with the > external memory controller. Document new interconnect property which > turns memory controller into interconnect provider. > > Signed-off-by: Dmitry Osipenko > --- > .../bindings/memory-controllers/nvidia,tegra30-mc.yaml | 5 + > 1 file changed, 5 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 06/22] dt-bindings: memory: tegra20: Add memory client IDs
On Mon, 30 Mar 2020 04:08:48 +0300, Dmitry Osipenko wrote: > Each memory client have a unique hardware ID, this patch adds these IDs. > > Signed-off-by: Dmitry Osipenko > --- > include/dt-bindings/memory/tegra20-mc.h | 53 + > 1 file changed, 53 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/8] dt-bindings: add img,pvrsgx.yaml for Imagination GPUs
On Tue, Apr 07, 2020 at 09:00:48AM +0200, H. Nikolaus Schaller wrote: > > > Am 29.03.2020 um 19:38 schrieb H. Nikolaus Schaller : > > > > The Imagination PVR/SGX GPU is part of several SoC from > > multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo, > > Allwinner A83 and others. > > > > With this binding, we describe how the SGX processor is > > interfaced to the SoC (registers, interrupt etc.). > > > > In most cases, Clock, Reset and power management is handled > > by a parent node or elsewhere (e.g. code in the driver). > > > > Tested by make dt_binding_check dtbs_check > > > > Signed-off-by: H. Nikolaus Schaller > > --- > > .../devicetree/bindings/gpu/img,pvrsgx.yaml | 109 ++ > > 1 file changed, 109 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml > > > > diff --git a/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml > > b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml > > new file mode 100644 > > index ..aadfb2d9b012 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml > > @@ -0,0 +1,109 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/gpu/img,pvrsgx.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Imagination PVR/SGX GPU > > + > > +maintainers: > > + - H. Nikolaus Schaller > > + > > +description: |+ > > + This binding describes the Imagination SGX5 series of 3D accelerators > > which > > + are found in several different SoC like TI OMAP, Sitara, Ingenic JZ4780, > > + Allwinner A83, and Intel Poulsbo and CedarView and more. > > + > > + For an extensive list see: > > https://en.wikipedia.org/wiki/PowerVR#Implementations > > + > > + The SGX node is usually a child node of some DT node belonging to the SoC > > + which handles clocks, reset and general address space mapping of the SGX > > + register area. > > + > > +properties: > > + compatible: > > +oneOf: > > + - description: SGX530-121 based SoC > > +items: > > + - enum: > > +- ti,omap3-sgx530-121 # BeagleBoard A/B/C, OpenPandora 600MHz > > and similar > > + - const: img,sgx530-121 > > + - const: img,sgx530 > > + > > + - description: SGX530-125 based SoC > > +items: > > + - enum: > > +- ti,am3352-sgx530-125 # BeagleBone Black > > +- ti,am3517-sgx530-125 > > +- ti,am4-sgx530-125 > > +- ti,omap3-sgx530-125 # BeagleBoard XM, GTA04, OpenPandora > > 1GHz and similar > > +- ti,ti81xx-sgx530-125 > > + - const: ti,omap3-sgx530-125 > > + - const: img,sgx530-125 > > + - const: img,sgx530 > > + > > + - description: SGX535-116 based SoC > > +items: > > + - const: intel,poulsbo-gma500-sgx535 # Atom Z5xx > > + - const: img,sgx535-116 > > + - const: img,sgx535 > > + > > + - description: SGX540-116 based SoC > > +items: > > + - const: intel,medfield-gma-sgx540 # Atom Z24xx > > + - const: img,sgx540-116 > > + - const: img,sgx540 > > + > > + - description: SGX540-120 based SoC > > +items: > > + - enum: > > +- ingenic,jz4780-sgx540-120 # CI20 > > +- ti,omap4-sgx540-120 # Pandaboard, Pandaboard ES and similar > > + - const: img,sgx540-120 > > + - const: img,sgx540 > > + > > + - description: SGX544-112 based SoC > > +items: > > + - const: ti,omap4-sgx544-112 > > + - const: img,sgx544-112 > > + - const: img,sgx544 > > + > > + - description: SGX544-116 based SoC > > +items: > > + - enum: > > +- allwinner,sun8i-a83t-sgx544-116 # Banana-Pi-M3 (Allwinner > > A83T) and similar > > Philipp Rossak reported on a different list [1] that the a83t tells to have a > sgx544-115 inside. > > So it needs a separate entry. Okay, it looks fine otherwise. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/22] dt-bindings: host1x: Document new interconnect properties
On Mon, Mar 30, 2020 at 04:08:47AM +0300, Dmitry Osipenko wrote: > Most of Host1x devices have at least one memory client. These clients > are directly connected to the memory controller. The new interconnect > properties represent the memory client's connection to the memory > controller. > > Signed-off-by: Dmitry Osipenko > --- > .../display/tegra/nvidia,tegra20-host1x.txt | 68 +++ > 1 file changed, 68 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > index 255ac5b6..d92d4e814d77 100644 > --- > a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > +++ > b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > @@ -20,6 +20,10 @@ Required properties: > - reset-names: Must include the following entries: >- host1x > > +Each host1x client module having to perform DMA through the Memory Controller > +should have the interconnect endpoints set to the Memory Client and External > +Memory respectively. > + > The host1x top-level node defines a number of children, each representing one > of the following host1x client modules: > > @@ -36,6 +40,12 @@ of the following host1x client modules: >- reset-names: Must include the following entries: > - mpe > > + Optional properties: > + - interconnects: Must contain entry for the MPE memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients. Is the TRM public? Perhaps refer to the header. > + > - vi: video input > >Required properties: > @@ -49,6 +59,12 @@ of the following host1x client modules: >- reset-names: Must include the following entries: > - vi > > + Optional properties: > + - interconnects: Must contain entry for the VI memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients. > + > - epp: encoder pre-processor > >Required properties: > @@ -62,6 +78,12 @@ of the following host1x client modules: >- reset-names: Must include the following entries: > - epp > > + Optional properties: > + - interconnects: Must contain entry for the EPP memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients. > + > - isp: image signal processor > >Required properties: > @@ -75,6 +97,12 @@ of the following host1x client modules: >- reset-names: Must include the following entries: > - isp > > + Optional properties: > + - interconnects: Must contain entry for the ISP memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients. > + > - gr2d: 2D graphics engine > >Required properties: > @@ -88,6 +116,12 @@ of the following host1x client modules: >- reset-names: Must include the following entries: > - 2d > > + Optional properties: > + - interconnects: Must contain entry for the GR2D memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients. > + > - gr3d: 3D graphics engine > >Required properties: > @@ -106,6 +140,12 @@ of the following host1x client modules: > - 3d > - 3d2 (Only required on SoCs with two 3D clocks) > > + Optional properties: > + - interconnects: Must contain entry for the GR3D memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients. > + > - dc: display controller > >Required properties: > @@ -133,6 +173,10 @@ of the following host1x client modules: >- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection >- nvidia,edid: supplies a binary EDID blob >- nvidia,panel: phandle of a display panel > + - interconnects: Must contain entry for the DC memory clients. > + - interconnect-names: Must include name of the interconnect path for each > +interconnect entry. Consult TRM documentation for information about > +available memory clients. > > - hdmi: High Definition Multimedia Interface > > @@ -281,6 +325,12 @@ of the following host1x client modules: >- reset-names: Must include the following entries: > - vic > > + Optional properties: > + - interconnects: Must contain entry for the VIC memory clients. > + - interconnect-names: Must include name
Re: [PATCH v2 2/2] powerpc: Remove Xilinx PPC405/PPC440 support
On Mon, Mar 30, 2020 at 03:32:17PM +0200, Michal Simek wrote:
> The latest Xilinx design tools called ISE and EDK has been released in
> October 2013. New tool doesn't support any PPC405/PPC440 new designs.
> These platforms are no longer supported and tested.
>
> PowerPC 405/440 port is orphan from 2013 by
> commit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") and
> commit 19624236cce1 ("MAINTAINERS: Update Grant's email address and
> maintainership")
> that's why it is time to remove the support fot these platforms.
>
> Signed-off-by: Michal Simek
> Acked-by: Arnd Bergmann
> ---
>
> Changes in v2:
> - Based on my chat with Arnd I removed arch/powerpc/xmon/ changes done in
> v1 to keep them the same as before. (kbuild reported some issues with it
> too)
>
> Documentation/devicetree/bindings/xilinx.txt | 143 --
Acked-by: Rob Herring
> Documentation/powerpc/bootwrapper.rst| 28 +-
> MAINTAINERS | 6 -
> arch/powerpc/Kconfig.debug | 2 +-
> arch/powerpc/boot/Makefile | 7 +-
> arch/powerpc/boot/dts/Makefile | 1 -
> arch/powerpc/boot/dts/virtex440-ml507.dts| 406
> arch/powerpc/boot/dts/virtex440-ml510.dts| 466 ---
> arch/powerpc/boot/ops.h | 1 -
> arch/powerpc/boot/serial.c | 5 -
> arch/powerpc/boot/uartlite.c | 79
> arch/powerpc/boot/virtex.c | 97
> arch/powerpc/boot/virtex405-head.S | 31 --
> arch/powerpc/boot/wrapper| 8 -
> arch/powerpc/configs/40x/virtex_defconfig| 75 ---
> arch/powerpc/configs/44x/virtex5_defconfig | 74 ---
> arch/powerpc/configs/ppc40x_defconfig| 8 -
> arch/powerpc/configs/ppc44x_defconfig| 8 -
> arch/powerpc/include/asm/xilinx_intc.h | 16 -
> arch/powerpc/include/asm/xilinx_pci.h| 21 -
> arch/powerpc/kernel/cputable.c | 39 --
> arch/powerpc/platforms/40x/Kconfig | 31 --
> arch/powerpc/platforms/40x/Makefile | 1 -
> arch/powerpc/platforms/40x/virtex.c | 54 ---
> arch/powerpc/platforms/44x/Kconfig | 37 --
> arch/powerpc/platforms/44x/Makefile | 2 -
> arch/powerpc/platforms/44x/virtex.c | 60 ---
> arch/powerpc/platforms/44x/virtex_ml510.c| 30 --
> arch/powerpc/platforms/Kconfig | 4 -
> arch/powerpc/sysdev/Makefile | 2 -
> arch/powerpc/sysdev/xilinx_intc.c| 88
> arch/powerpc/sysdev/xilinx_pci.c | 132 --
> drivers/char/Kconfig | 2 +-
> drivers/video/fbdev/Kconfig | 2 +-
> 34 files changed, 7 insertions(+), 1959 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/22] dt-bindings: memory: tegra30: Add memory client IDs
On Mon, 30 Mar 2020 04:08:49 +0300, Dmitry Osipenko wrote: > Each memory client have a unique hardware ID, this patch adds these IDs. > > Signed-off-by: Dmitry Osipenko > --- > include/dt-bindings/memory/tegra30-mc.h | 67 + > 1 file changed, 67 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] dt-bindings: drm/msm/gpu: Document OPP phandle list for the GPU
On Tue, 31 Mar 2020 13:25:53 +0530, Sharat Masetty wrote: > Update the documentation for listing the multiple optional GPU and the > DDR OPP tables to help enable DDR scaling. > > Signed-off-by: Sharat Masetty > --- > .../devicetree/bindings/display/msm/gpu.txt| 63 > +- > 1 file changed, 61 insertions(+), 2 deletions(-) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/gt: remove redundant assignment to variable x
From: Colin Ian King
The variable x is being initialized with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 3aa8a652c16d..0b597427bde9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1205,7 +1205,7 @@ static void print_request(struct drm_printer *m,
{
const char *name = rq->fence.ops->get_timeline_name(&rq->fence);
char buf[80] = "";
- int x = 0;
+ int x;
x = print_sched_attr(rq->i915, &rq->sched.attr, buf, x, sizeof(buf));
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP
On Fri, Apr 10, 2020 at 05:56:13PM +0200, Rafael J. Wysocki wrote: > From: "Rafael J. Wysocki" > > Rename DPM_FLAG_NEVER_SKIP to DPM_FLAG_NO_DIRECT_COMPLETE which > matches its purpose more closely. > > No functional impact. > > Signed-off-by: Rafael J. Wysocki Acked-by: Bjorn Helgaas # for PCI parts > --- > Documentation/driver-api/pm/devices.rst| 6 +++--- > Documentation/power/pci.rst| 10 +- > drivers/base/power/main.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 2 +- > drivers/gpu/drm/i915/intel_runtime_pm.c| 2 +- > drivers/gpu/drm/radeon/radeon_kms.c| 2 +- > drivers/misc/mei/pci-me.c | 2 +- > drivers/misc/mei/pci-txe.c | 2 +- > drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- > drivers/net/ethernet/intel/igb/igb_main.c | 2 +- > drivers/net/ethernet/intel/igc/igc_main.c | 2 +- > drivers/pci/pcie/portdrv_pci.c | 2 +- > include/linux/pm.h | 6 +++--- > 13 files changed, 21 insertions(+), 21 deletions(-) > > diff --git a/Documentation/driver-api/pm/devices.rst > b/Documentation/driver-api/pm/devices.rst > index f66c7b9126ea..4ace0eba4506 100644 > --- a/Documentation/driver-api/pm/devices.rst > +++ b/Documentation/driver-api/pm/devices.rst > @@ -361,9 +361,9 @@ the phases are: ``prepare``, ``suspend``, > ``suspend_late``, ``suspend_noirq``. > runtime PM disabled. Minor question about a preceding paragraph that ends: In that case, the ``->complete`` callback will be invoked directly after the ``->prepare`` callback and is entirely responsible for putting the device into a consistent state as appropriate. What does" a consistent state as appropriate" mean? I know this is generic documentation at a high level, so maybe there's no good explanation for "consistent state," but I don't know what to imagine there. And what does "as appropriate" mean? Would it change the meaning to drop those two words, or are there situations where it's not appropriate to put the device into a consistent state? Or maybe it's just that the type of device determines what the consistent state is? > This feature also can be controlled by device drivers by using the > - ``DPM_FLAG_NEVER_SKIP`` and ``DPM_FLAG_SMART_PREPARE`` driver power > - management flags. [Typically, they are set at the time the driver is > - probed against the device in question by passing them to the > + ``DPM_FLAG_NO_DIRECT_COMPLETE`` and ``DPM_FLAG_SMART_PREPARE`` driver > + power management flags. [Typically, they are set at the time the driver > + is probed against the device in question by passing them to the > :c:func:`dev_pm_set_driver_flags` helper function.] If the first of > these flags is set, the PM core will not apply the direct-complete > procedure described above to the given device and, consequenty, to any s/consequenty/consequently/ Drive-by comment: I looked for a definition of "direct-complete". The closest I found is a couple paragraphs above this, where it says "Note that this direct-complete procedure ...," but that leaves me to try to reconstruct the definition from the preceding text. AFAICT, going to freeze, standby, or memory sleep includes these callbacks: ->prepare ->suspend ->suspend_late ->suspend_noirq ->complete (not mentioned in the list of phases) And "direct-complete" means we skip the suspend, suspend_late, and suspend_noirq callbacks so we only use these: ->prepare ->complete And apparently we skip those callbacks for device X if ->prepare() for X and all its descendents returns a positive value AND they are all runtime-suspended, except if a driver for X or a descendent sets DPM_FLAG_NO_DIRECT_COMPLETE. Bjorn ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
BUG: kernel NULL pointer dereference, address: 0000000000000026 after switching to 5.7 kernel
Hi folks. After upgrade kernel to 5.7 I see every boot in kernel log following error messages: [2.569513] [drm] Found UVD firmware ENC: 1.2 DEC: .43 Family ID: 19 [2.569538] [drm] PSP loading UVD firmware [2.570038] BUG: kernel NULL pointer dereference, address: 0026 [2.570045] #PF: supervisor read access in kernel mode [2.570050] #PF: error_code(0x) - not-present page [2.570055] PGD 0 P4D 0 [2.570060] Oops: [#1] SMP NOPTI [2.570065] CPU: 5 PID: 667 Comm: uvd_enc_1.1 Not tainted 5.7.0-0.rc0.git6.1.2.fc33.x86_64 #1 [2.570072] Hardware name: System manufacturer System Product Name/ROG STRIX X570-I GAMING, BIOS 1405 11/19/2019 [2.570085] RIP: 0010:__kthread_should_park+0x5/0x30 [2.570090] Code: 00 e9 fe fe ff ff e8 ca 3a 08 00 e9 49 fe ff ff 48 89 df e8 dd 38 08 00 84 c0 0f 84 6a ff ff ff e9 a6 fe ff ff 0f 1f 44 00 00 47 26 20 74 12 48 8b 87 88 09 00 00 48 8b 00 48 c1 e8 02 83 e0 [2.570103] RSP: 0018:ad8141723e50 EFLAGS: 00010246 [2.570107] RAX: 7fff RBX: 8a8d1d116ed8 RCX: [2.570112] RDX: RSI: RDI: [2.570116] RBP: 8a8d28c11300 R08: R09: [2.570120] R10: R11: R12: 8a8d1d152e40 [2.570125] R13: 8a8d1d117280 R14: 8a8d1d116ed8 R15: 8a8d1ca68000 [2.570131] FS: () GS:8a8d3aa0() knlGS: [2.570137] CS: 0010 DS: ES: CR0: 80050033 [2.570142] CR2: 0026 CR3: 0007e3dc6000 CR4: 003406e0 [2.570147] Call Trace: [2.570157] drm_sched_get_cleanup_job+0x42/0x130 [gpu_sched] [2.570166] drm_sched_main+0x6f/0x530 [gpu_sched] [2.570173] ? lockdep_hardirqs_on+0x11e/0x1b0 [2.570179] ? drm_sched_get_cleanup_job+0x130/0x130 [gpu_sched] [2.570185] kthread+0x131/0x150 [2.570189] ? __kthread_bind_mask+0x60/0x60 [2.570196] ret_from_fork+0x27/0x50 [2.570203] Modules linked in: fjes(-) amdgpu(+) amd_iommu_v2 gpu_sched ttm drm_kms_helper drm crc32c_intel igb nvme nvme_core dca i2c_algo_bit wmi pinctrl_amd br_netfilter bridge stp llc fuse [2.570223] CR2: 0026 [2.570228] ---[ end trace 80c25d326e1e0d7c ]--- [2.570233] RIP: 0010:__kthread_should_park+0x5/0x30 [2.570238] Code: 00 e9 fe fe ff ff e8 ca 3a 08 00 e9 49 fe ff ff 48 89 df e8 dd 38 08 00 84 c0 0f 84 6a ff ff ff e9 a6 fe ff ff 0f 1f 44 00 00 47 26 20 74 12 48 8b 87 88 09 00 00 48 8b 00 48 c1 e8 02 83 e0 [2.570250] RSP: 0018:ad8141723e50 EFLAGS: 00010246 [2.570255] RAX: 7fff RBX: 8a8d1d116ed8 RCX: [2.570260] RDX: RSI: RDI: [2.570265] RBP: 8a8d28c11300 R08: R09: [2.570271] R10: R11: R12: 8a8d1d152e40 [2.570276] R13: 8a8d1d117280 R14: 8a8d1d116ed8 R15: 8a8d1ca68000 [2.570281] FS: () GS:8a8d3aa0() knlGS: [2.570287] CS: 0010 DS: ES: CR0: 80050033 [2.570292] CR2: 0026 CR3: 0007e3dc6000 CR4: 003406e0 [2.570299] BUG: sleeping function called from invalid context at include/linux/percpu-rwsem.h:49 [2.570306] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 667, name: uvd_enc_1.1 [2.570311] INFO: lockdep is turned off. [2.570315] irq event stamp: 14 [2.570319] hardirqs last enabled at (13): [] _raw_spin_unlock_irqrestore+0x46/0x60 [2.570330] hardirqs last disabled at (14): [] trace_hardirqs_off_thunk+0x1a/0x1c [2.570338] softirqs last enabled at (0): [] copy_process+0x706/0x1bc0 [2.570345] softirqs last disabled at (0): [<>] 0x0 [2.570351] CPU: 5 PID: 667 Comm: uvd_enc_1.1 Tainted: G D 5.7.0-0.rc0.git6.1.2.fc33.x86_64 #1 [2.570358] Hardware name: System manufacturer System Product Name/ROG STRIX X570-I GAMING, BIOS 1405 11/19/2019 [2.570365] Call Trace: [2.570373] dump_stack+0x8b/0xc8 [2.570380] ___might_sleep.cold+0xb6/0xc6 [2.570385] exit_signals+0x1c/0x2d0 [2.570390] do_exit+0xb1/0xc30 [2.570395] ? kthread+0x131/0x150 [2.570400] rewind_stack_do_exit+0x17/0x20 [2.570559] [drm] Found VCE firmware Version: 57.6 Binary ID: 4 [2.570572] [drm] PSP loading VCE firmware [3.146462] [drm] reserve 0x40 from 0x83fe80 for PSP TMR $ /usr/src/kernels/`uname -r`/scripts/faddr2line /lib/debug/lib/modules/`uname -r`/vmlinux __kthread_should_park+0x5 __kthread_should_park+0x5/0x30: to_kthread at kernel/kthread.c:75 (inlined by) __kthread_should_park at kernel/kthread.c:109 I think this issue related to amdgpu driver. Can anyone look into it? Thanks. Full kernel log here: https://pastebin.com/RrSp6KYL -- Best Regards, Mike Gavrilov. _
[Bug 201139] amdgpu: [drm] enabling link 1 failed: 15 (vega)
https://bugzilla.kernel.org/show_bug.cgi?id=201139 Christian Thäter (ct.kernel@pipapo.org) changed: What|Removed |Added CC||ct.kernel@pipapo.org --- Comment #10 from Christian Thäter (ct.kernel@pipapo.org) --- Created attachment 288335 --> https://bugzilla.kernel.org/attachment.cgi?id=288335&action=edit Further info, kernel log I had some hard crashes recently (screen frozen or blank), sometimes as much as once a day, sometimes the System runs for days to weeks. Today one screen didn't come up after I turned it on and i found a smoking gun in the attached dmesg. Maybe thats helpful. System is AMD Ryzen 1700, Debian Buster, self built Kernel. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.7-rc1 (part two)
The pull request you sent on Fri, 10 Apr 2020 07:10:29 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-04-10 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/21c5b3c6d7579944d21ff268f241d6bec425a9b4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 Jordan Maris (jman6...@gmail.com) changed: What|Removed |Added CC||jman6...@gmail.com --- Comment #57 from Jordan Maris (jman6...@gmail.com) --- I'm also experiencing this issue on a HP Envy 13 x360 with the Ryzen 3500U APU. Has anyone found any potential solutions ? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/dp: DRM DP helper for reading Ignore MSA from DPCD
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing parameters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and EDID.
This is required for the sink to indicate that it is Adaptive sync
capable.
v3:
* Fi the typo in commit message (Manasi)
v2:
* Rename to describe what the function does (Jani Nikula)
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Signed-off-by: Manasi Navare
Reviewed-by: Harry Wentland
---
include/drm/drm_dp_helper.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 305533da13ad..2b41e8990531 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1445,6 +1445,14 @@ drm_dp_alternate_scrambler_reset_cap(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
DP_ALTERNATE_SCRAMBLER_RESET_CAP;
}
+/* Ignore MSA timing for Adaptive Sync support on DP 1.4 */
+static inline bool
+drm_dp_sink_can_do_video_without_timing_msa(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ return dpcd[DP_DOWN_STREAM_PORT_COUNT] &
+ DP_MSA_TIMING_PAR_IGNORED;
+}
+
/*
* DisplayPort AUX channel
*/
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] drm/i915/dp: Attach and set drm connector VRR property
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v3:
* intel_dp_is_vrr_capable can be used for debugfs, make it
non static (Manasi)
v2:
* Just set this in intel_dp_get_modes instead of new hook (Jani)
Cc: Ville Syrjälä
Cc: Jani Nikula
Signed-off-by: Aditya Swarup
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_dp.c | 24
drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 25f0baafd6d0..12a9a8ed6a90 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6182,6 +6182,23 @@ intel_dp_force(struct drm_connector *connector)
intel_display_power_put(dev_priv, aux_domain, wakeref);
}
+bool intel_dp_is_vrr_capable(struct drm_connector *connector)
+{
+ struct intel_dp *intel_dp =
intel_attached_dp(to_intel_connector(connector));
+ const struct drm_display_info *info = &connector->display_info;
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
+ /*
+* DP Sink is capable of Variable refresh video timings if
+* Ignore MSA bit is set in DPCD.
+* EDID monitor range also should be atleast 10 for reasonable
+* Adaptive sync/ VRR end user experience.
+*/
+ return INTEL_GEN(dev_priv) >= 12 &&
+ drm_dp_sink_can_do_video_without_timing_msa(intel_dp->dpcd) &&
+ info->monitor_range.max_vfreq - info->monitor_range.min_vfreq >
10;
+}
+
static int intel_dp_get_modes(struct drm_connector *connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
@@ -6192,6 +6209,10 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
int ret = intel_connector_update_modes(connector, edid);
if (ret)
return ret;
+
+ if (intel_dp_is_vrr_capable(connector))
+ drm_connector_set_vrr_capable_property(connector,
+ true);
}
/* if eDP has no EDID, fall back to fixed mode */
@@ -7238,6 +7259,9 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
}
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ drm_connector_attach_vrr_capable_property(connector);
}
static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 9632978e8c24..aa4cfbbbe117 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -14,6 +14,7 @@ enum pipe;
enum port;
struct drm_connector_state;
struct drm_encoder;
+struct drm_connector;
struct drm_i915_private;
struct drm_modeset_acquire_ctx;
struct intel_connector;
@@ -118,6 +119,7 @@ void intel_dp_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state);
bool intel_digital_port_connected(struct intel_encoder *encoder);
+bool intel_dp_is_vrr_capable(struct drm_connector *connector);
static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
{
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/i915/dp: Expose connector VRR info via debugfs
From: Bhanuprakash Modem
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "i915_vrr_info".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/i915_vrr_info
v2:
* Fix the typo in max_vfreq (Manasi)
* Change the name of node to i915_vrr_info so we can add
other vrr info for more debug info (Manasi)
* Change the VRR capable to display Yes or No (Manasi)
* Fix indentation checkpatch errors (Manasi)
Signed-off-by: Bhanuprakash Modem
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Ville Syrjälä
Tested-by: Manasi Navare
---
.../drm/i915/display/intel_display_debugfs.c | 22 ++-
drivers/gpu/drm/i915/display/intel_dp.c | 4 +++-
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 9f736420d83f..c10b97ac0482 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2086,6 +2086,21 @@ static const struct file_operations
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
};
+static int i915_vrr_info_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+
+ if (connector->status != connector_status_connected)
+ return -ENODEV;
+
+ seq_printf(m, "Vrr_capable: %s\n",
yesno(intel_dp_is_vrr_capable(connector)));
+ seq_printf(m, "Min: %u\n",
(u8)connector->display_info.monitor_range.min_vfreq);
+ seq_printf(m, "Max: %u\n",
(u8)connector->display_info.monitor_range.max_vfreq);
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(i915_vrr_info);
+
/**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -2120,9 +2135,14 @@ int intel_connector_debugfs_add(struct drm_connector
*connector)
if (INTEL_GEN(dev_priv) >= 10 &&
(connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
-connector->connector_type == DRM_MODE_CONNECTOR_eDP))
+connector->connector_type == DRM_MODE_CONNECTOR_eDP)) {
debugfs_create_file("i915_dsc_fec_support", S_IRUGO, root,
connector, &i915_dsc_fec_support_fops);
+ if (INTEL_GEN(dev_priv) >= 12)
+ debugfs_create_file("i915_vrr_info", S_IRUGO,
+ root, connector,
&i915_vrr_info_fops);
+ }
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 12a9a8ed6a90..e579a2ff0b63 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6210,9 +6210,11 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
if (ret)
return ret;
- if (intel_dp_is_vrr_capable(connector))
+ if (intel_dp_is_vrr_capable(connector)) {
drm_connector_set_vrr_capable_property(connector,
true);
+ DRM_DEBUG_KMS("\n VRR Debug: Setting VRR prop to true");
+ }
}
/* if eDP has no EDID, fall back to fixed mode */
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: ensure device_list is initialised before calling list_add_tail
From: Colin Ian King
Currently the call to list_add_tail will access an the uninitalised
device_list.prev. Fix this by ensuring device_list is initialized before
adding items to it.
Addresses-Coverity: ("Uninitialized pointer read")
Fixes: b3dbd6d3ec49 ("drm/amdgpu: resolve mGPU RAS query instability")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index b0aa4e1ed4df..caa4969bd46f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1447,6 +1447,7 @@ static void amdgpu_ras_do_recovery(struct work_struct
*work)
if (hive && adev->gmc.xgmi.num_physical_nodes > 1) {
device_list_handle = &hive->device_list;
} else {
+ INIT_LIST_HEAD(&device_list);
list_add_tail(&adev->gmc.xgmi.head, &device_list);
device_list_handle = &device_list;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc
Hi Sergey, On Fri, Apr 10, 2020 at 11:38:45AM +0900, Sergey Senozhatsky wrote: > On (20/04/09 10:08), Minchan Kim wrote: > > > > Even though I don't know how many usecase we have using zsmalloc as > > > > module(I heard only once by dumb reason), it could affect existing > > > > users. Thus, please include concrete explanation in the patch to > > > > justify when the complain occurs. > > > > > > The justification is 'we can unexport functions that have no sane reason > > > of being exported in the first place'. > > > > > > The Changelog pretty much says that. > > > > Okay, I hope there is no affected user since this patch. > > If there are someone, they need to provide sane reason why they want > > to have zsmalloc as module. > > I'm one of those who use zsmalloc as a module - mainly because I use zram > as a compressing general purpose block device, not as a swap device. > I create zram0, mkfs, mount, checkout and compile code, once done - > umount, rmmod. This reduces the number of writes to SSD. Some people use > tmpfs, but zram device(-s) can be much larger in size. That's a niche use > case and I'm not against the patch. It doesn't mean we couldn't use zsmalloc as module any longer. It means we couldn't use zsmalloc as module with pgtable mapping whcih was little bit faster on microbenchmark in some architecutre(However, I usually temped to remove it since it had several problems). However, we could still use zsmalloc as module as copy way instead of pgtable mapping. Thus, if someone really want to rollback the feature, they should provide reasonable reason why it doesn't work for them. "A little fast" wouldn't be enough to exports deep internal to the module. Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/hisilicon: Code refactoring for hibmc_drv_vdac
On Sat, 2020-04-11 at 10:49 +0800, Tian Tao wrote:
> code refactoring for hibmc_drv_vdac.c, no actual function changes.
Seems sensible.
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
[]
> @@ -109,13 +83,6 @@ int hibmc_vdac_init(struct hibmc_drm_private *priv)
> struct drm_connector *connector;
> int ret;
>
> - connector = hibmc_connector_init(priv);
> - if (IS_ERR(connector)) {
> - DRM_ERROR("failed to create connector: %ld\n",
> - PTR_ERR(connector));
> - return PTR_ERR(connector);
> - }
> -
> encoder = devm_kzalloc(dev->dev, sizeof(*encoder), GFP_KERNEL);
> if (!encoder) {
> DRM_ERROR("failed to alloc memory when init encoder\n");
The alloc error messages could be removed.
> @@ -131,6 +98,21 @@ int hibmc_vdac_init(struct hibmc_drm_private *priv)
> }
>
> drm_encoder_helper_add(encoder, &hibmc_encoder_helper_funcs);
> +
> + connector = devm_kzalloc(dev->dev, sizeof(*connector), GFP_KERNEL);
> + if (!connector) {
> + DRM_ERROR("failed to alloc memory when init connector\n");
and here.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: ensure device_list is initialised before calling list_add_tail
On 4/10/20 6:57 PM, Colin King wrote:
From: Colin Ian King
Currently the call to list_add_tail will access an the uninitalised
device_list.prev. Fix this by ensuring device_list is initialized before
adding items to it.
Addresses-Coverity: ("Uninitialized pointer read")
That weird, I see that his is already initialized unconditionally here -
https://elixir.bootlin.com/linux/v5.6.3/source/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c#L4022
Andrey
Fixes: b3dbd6d3ec49 ("drm/amdgpu: resolve mGPU RAS query instability")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index b0aa4e1ed4df..caa4969bd46f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1447,6 +1447,7 @@ static void amdgpu_ras_do_recovery(struct work_struct
*work)
if (hive && adev->gmc.xgmi.num_physical_nodes > 1) {
device_list_handle = &hive->device_list;
} else {
+ INIT_LIST_HEAD(&device_list);
list_add_tail(&adev->gmc.xgmi.head, &device_list);
device_list_handle = &device_list;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204609] amdgpu: powerplay failed send message
https://bugzilla.kernel.org/show_bug.cgi?id=204609 Janpieter Sollie (janpieter.sol...@edpnet.be) changed: What|Removed |Added CC||janpieter.sol...@edpnet.be --- Comment #6 from Janpieter Sollie (janpieter.sol...@edpnet.be) --- I hope this is the right place to add some comments: Using 5.5.14, when the GPU runs at full speed, it seems to overheat after some time. I'd expect powerplay to take care of this critical temperature and slow down the GPU. instead, the GPU overheats and a system reset is neccessary. The log is flooded with: Apr 11 06:45:54 linuxserver kernel: amdgpu :05:00.0: GPU reset begin! Apr 11 06:45:54 linuxserver kernel: [drm] Timeout wait for RLC serdes 0,0 Apr 11 06:45:56 linuxserver last message repeated 4 times Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: last message was failed ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: failed to send message 133 ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: last message was failed ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: failed to send message 5e ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: last message was failed ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: failed to send message 145 ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: last message was failed ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: failed to send message 146 ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: last message was failed ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: failed to send message 148 ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: last message was failed ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: failed to send message 145 ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: last message was failed ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: failed to send message 146 ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: last message was failed ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: failed to send message 16a ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: last message was failed ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: failed to send message 186 ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: last message was failed ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: failed to send message 54 ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: last message was failed ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Apr 11 06:45:57 linuxserver kernel: failed to send message 13d ret is 65535 Apr 11 06:45:57 linuxserver kernel: amdgpu: [powerplay] Then after some time, the kernel realizes it did something wrong, but it seems too late: [ 509.939497] amdgpu: [powerplay] Failed to force to switch arbf0! [ 509.939497] amdgpu: [powerplay] [disable_dpm_tasks] Failed to disable DPM! [ 509.939513] [drm:amdgpu_device_ip_suspend_phase2 [amdgpu]] *ERROR* suspend of IP block failed -22 [ 510.203234] amdgpu :05:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring kiq_2.1.0 test failed (-110) [ 510.203254] [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disable failed [ 510.313006] AMD-Vi: Completion-Wait loop timed out [ 510.730195] cp is busy, skip halt cp [ 510.744990] iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT device=05:00.0 address=0x5f38cdcf0] [ 510.993797] rlc is busy, skip halt rlc [ 511.312957] AMD-Vi: Completion-Wait loop timed out [ 511.522695] AMD-Vi: Completion-Wait loop timed out [ 511.742668] AMD-Vi: Completion-Wait loop timed out [ 511.746867] iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT device=05:00.0 address=0x5f38cdd20] [ 512.748750] iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT device=05:00
[PATCH] component: Silence bind error on -EPROBE_DEFER
If a component fails to bind due to -EPROBE_DEFER we should not log an
error as this is not a real failure.
Fixes:
vc4-drm soc:gpu: failed to bind 3f902000.hdmi (ops vc4_hdmi_ops): -517
vc4-drm soc:gpu: master bind failed: -517
Signed-off-by: James Hilliard
---
drivers/base/component.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index e97704104784..157c6c790578 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -256,7 +256,8 @@ static int try_to_bring_up_master(struct master *master,
ret = master->ops->bind(master->dev);
if (ret < 0) {
devres_release_group(master->dev, NULL);
- dev_info(master->dev, "master bind failed: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_info(master->dev, "master bind failed: %d\n", ret);
return ret;
}
@@ -611,8 +612,10 @@ static int component_bind(struct component *component,
struct master *master,
devres_release_group(component->dev, NULL);
devres_release_group(master->dev, NULL);
- dev_err(master->dev, "failed to bind %s (ops %ps): %d\n",
- dev_name(component->dev), component->ops, ret);
+ if (ret != -EPROBE_DEFER) {
+ dev_err(master->dev, "failed to bind %s (ops %ps):
%d\n",
+ dev_name(component->dev), component->ops, ret);
+ }
}
return ret;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: hdmi: Silence pixel clock error on -EPROBE_DEFER
If the vc4 hdmi driver loads before the pixel clock is available we
see a spurious "*ERROR* Failed to get pixel clock" error.
Signed-off-by: James Hilliard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 340719238753..6d4ee3f6b445 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1338,8 +1338,10 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
hdmi->pixel_clock = devm_clk_get(dev, "pixel");
if (IS_ERR(hdmi->pixel_clock)) {
- DRM_ERROR("Failed to get pixel clock\n");
- return PTR_ERR(hdmi->pixel_clock);
+ ret = PTR_ERR(hdmi->pixel_clock);
+ if (ret != -EPROBE_DEFER)
+ DRM_ERROR("Failed to get pixel clock\n");
+ return ret;
}
hdmi->hsm_clock = devm_clk_get(dev, "hdmi");
if (IS_ERR(hdmi->hsm_clock)) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
