/\(__assign_str([^,]*[^ ,]\) *,[^;]*/\1)/' $a > /tmp/test-file;
> mv /tmp/test-file $a;
> done
Try 'sed -i' ;)
> .../drm/i915/display/intel_display_trace.h| 56 -
On i915,
Acked-by: Jani Nikula
--
Jani Nikula, Intel
RM_I915_WERROR config depends on EXPERT and !COMPILE_TEST, and to
my knowledge this has never caused issues outside of i915 developers and
CI.
Maybe the fix to KVM_ERROR config should be
- depends on (X86_64 && !KASAN) || !COMPILE_TEST
- depends on (X86_64 && !KASAN) && !COMPILE_TEST
BR,
Jani.
--
Jani Nikula, Intel
c | 26 +++
> drivers/gpu/drm/drm_dp_aux_backlight.c | 191
> +
> include/drm/drm_dp_aux_backlight.h | 29
> 7 files changed, 264 insertions(+)
> create mode 100644 drivers/gpu/drm/drm_dp_aux_backlight.c
> create mode 100644 include/drm/drm_dp_aux_backlight.h
--
Jani Nikula, Intel Open Source Graphics Center
h S3RST any S3 may become S4! */
> simulate_hibernate(i915);
>
> - pm_resume(i915);
> + i915_pm_resume(i915);
>
> err = switch_to_context(ctx);
> out:
> @@ -192,7 +192,7 @@ static int igt_gem_hibernate(void *arg)
> /* Here be dragons! */
&g
On Wed, 07 Apr 2021, Andy Shevchenko wrote:
> The ascii85.h is user of exactly two headers, i.e. math.h and types.h.
> There is no need to carry on entire kernel.h.
>
> Signed-off-by: Andy Shevchenko
That's hardly drm/i915 specific!
Reviewed-by: Jani Nikula
But who's going t
On Tue, 23 Mar 2021, Lyude Paul wrote:
> On Tue, 2021-03-23 at 16:06 +0200, Jani Nikula wrote:
>> On Thu, 18 Mar 2021, Lyude Paul wrote:
>> > Actually-NAK this. I just realized I've been misreading the bug and that
>> > this
>> > doesn't actually seem to be
-387,8 +382,7 @@ static ssize_t gt_min_freq_mhz_show(struct device *kdev,
> struct device_attribute
> struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
> struct intel_rps *rps = _priv->gt.rps;
>
> - return snprintf(buf, PAGE_SIZE, "%d\n",
> - intel_gpu_freq(rps, rps->min_freq_softlimit));
> + return sysfs_emit(buf, "%d\n", intel_gpu_freq(rps,
> rps->min_freq_softlimit));
> }
>
> static ssize_t gt_min_freq_mhz_store(struct device *kdev,
> @@ -462,7 +456,7 @@ static ssize_t gt_rp_mhz_show(struct device *kdev, struct
> device_attribute *attr
> else
> BUG();
>
> - return snprintf(buf, PAGE_SIZE, "%d\n", val);
> + return sysfs_emit(buf, "%d\n", val);
> }
>
> static const struct attribute * const gen6_attrs[] = {
--
Jani Nikula, Intel Open Source Graphics Center
by the consumer (opposed to what was actually implemented in
> hardware in reply to the last request). To make this semantic obvious
> rename the function.
>
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/gpu/drm/i915/display/intel_panel.c | 4 +--
Acked-by: Jani Nikula
-
struct device *dev;
> + struct drm_device *drm_dev;
Bikeshed, I would probably have called it just drm for brevity, but no
strong feelings.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
On Mon, 29 Mar 2021, Matthew Wilcox wrote:
> On Mon, Mar 29, 2021 at 09:33:30PM +0300, Jani Nikula wrote:
>> On Mon, 29 Mar 2021, Matthew Wilcox wrote:
>> > So here's my "modest proposal":
>> >
>> > - Similar to our ".. kernel-doc::&qu
Sphinx extensions to make it convenient to
reference content in the rustdoc generated HTML from reStructuredText.
BR,
Jani.
[1]
https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-html_static_path
--
Jani Nikula, Intel Open Source Graphics Center
gfp)
>
> //rST
> // Store an entry in the XArray.
> //
> // After this function returns, loads from `index` will return `entry`.
> // Storing into an existing multi-index entry updates the entry of every
> index.
> // The marks associated with `index` are unaffected unless `entry` is
> ``NULL``.
> //
> // :Context: Any context. Takes and releases the xa_lock.
> //May sleep if the `gfp` flags permit.
> // :Return: The old entry at this index on success, xa_err(-EINVAL) if `entry`
> //cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation
> //failed.
> void *xa_store(struct xarray *xa, unsigned long index, void *entry, gfp_t gfp)
>
--
Jani Nikula, Intel Open Source Graphics Center
clude "intel_vrr.h"
>
> -#define DP_DPRX_ESI_LEN 14
> +#define DP_DPRX_ESI_LEN 16
>
> /* DP DSC throughput values used for slice count calculations KPixels/s */
> #define DP_DSC_PEAK_PIXEL_RATE 272
--
Jani Nikula, Intel Open Source Graphics Center
on't think there's an issue, but the code could use a bunch
of improvements.
Like, we have intel_print_wm_latency() for debug logging and
wm_latency_show() for debugfs, and there's a bunch of duplication and
ugh.
But this seems like the easiest fix for the warning.
Reviewed-by: Jani Nikula
> Signed-o
lue might just need to be tweaked, but for now
>> let's just disable the VESA backlight interface unless it's specified in
>> the VBT just to be safe. We might be able to try enabling this again by
>> default in the future.
>>
>> Fixes: 2227816e647a ("drm/i915
re.
> + * nothing here.
>*/
>
> val = intel_de_read(dev_priv, enable_reg);
> --
> 2.31.0
>
--
Jani Nikula, Intel Open Source Graphics Center
gt; val = intel_de_read(dev_priv, enable_reg);
> --
> 2.26.2
>
--
Jani Nikula, Intel Open Source Graphics Center
fully too if the driver didn't set that.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
urcc format specifiers are a nice cleanup, but
I don't remember them either. I'd like something like %foo{yesno} where,
if you remember the %foo part, you could actually also remember the
rest.
But really if you get *any* version accepted, I'm not going to argue
against it, and you can disregard this as meaningless bikeshedding.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
On Mon, 15 Feb 2021, Andy Shevchenko wrote:
> We have already few similar implementation and a lot of code that can benefit
> of the yesno() helper. Consolidate yesno() helpers under string.h hood.
Good luck. I gave up after just four versions. [1]
Acked-by: Jani Nikula
BR,
Jani.
[1
"Failed to write aux pwmgen bit count\n");
> -
> - break;
> -
> - /* Do nothing when it is already DPCD mode */
> - case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
> - default:
> - break;
> }
>
> if (panel->backlight.edp.vesa.pwm_freq_pre_divider) {
--
Jani Nikula, Intel Open Source Graphics Center
TMDS mode\n");
> + drm_dbg(_priv->drm, "Couldn't set FRL mode, continuing with
> TMDS mode\n");
> ret = drm_dp_pcon_reset_frl_config(_dp->aux);
> mode = drm_dp_pcon_hdmi_link_mode(_dp->aux, NULL);
--
Jani Nikula, Intel Open Source Graphics Center
e commits as well.
It's a hack on top of the tree to unblock CI results, and will be
dropped before sending the pull request.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
;name, reg);
>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> index 153ca9e65382..f498f1c80755 100644
>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> @@ -201,8 +201,10 @@
.949494] do_syslog.part.23+0x31a/0x480
<4> [71.949496] ? __mutex_lock+0xa6/0x980
<4> [71.949497] ? __mutex_lock+0x29a/0x980
<4> [71.949498] ? find_held_lock+0x2d/0x90
<4> [71.949500] ? __fdget_pos+0x45/0x50
<4> [71.949502] kmsg_read+0x3c/0x50
<4> [71.949504] vfs_read+0xa8/0x1b0
<4> [71.949505] ksys_read+0x5a/0xd0
<4> [71.949507] do_syscall_64+0x33/0x80
<4> [71.949508] entry_SYSCALL_64_after_hwframe+0x44/0xa9
<4> [71.949510] RIP: 0033:0x7faf0694b384
<4> [71.949512] Code: 84 00 00 00 00 00 41 54 55 49 89 d4 53 48 89 f5 89 fb 48
83 ec 10 e8 8b fc ff ff 4c 89 e2 41 89 c0 48 89 ee 89 df 31 c0 0f 05 <48> 3d 00
f0 ff ff 77 38 44 89 c7 48 89 44 24 08 e8 c7 fc ff ff 48
<4> [71.949513] RSP: 002b:7faf03a784c0 EFLAGS: 0246 ORIG_RAX:
<4> [71.949515] RAX: ffda RBX: 0005 RCX:
7faf0694b384
<4> [71.949516] RDX: 1fa0 RSI: 7faf03a78d00 RDI:
0005
<4> [71.949517] RBP: 7faf03a78d00 R08: R09:
561e117f8fe8
<4> [71.949518] R10: 2ce33e6c02ce33e7 R11: 0246 R12:
1fa0
<4> [71.949519] R13: 1fa0 R14: 1f9f R15:
7faf03a7ab18
<3> [71.949521] FIX kmalloc-1k: Restoring
0xde6e27d6-0xeaa949e9=0xcc
<3> [71.949529] FIX kmalloc-1k: Object at 0xb43421a9 not freed
--
Jani Nikula, Intel Open Source Graphics Center
ector)
>* until it disabled HDCP encryption for all connectors in MST topology.
>*/
> if (dig_port->num_hdcp_streams > 0)
> - return ret;
> + return 0;
>
> hdcp->hdcp_encrypted = false;
> intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
--
Jani Nikula, Intel Open Source Graphics Center
On Fri, 15 Jan 2021, Jani Nikula wrote:
> On Thu, 14 Jan 2021, Lyude Paul wrote:
>> In the next commit where we split PWM related backlight functions from
>> higher-level backlight functions, we'll want to be able to retrieve the
>> backlight level for the curre
er
> to achieve this is pass down that parameter to intel_panel_bl_funcs->get().
>
> So, fix this by accepting an additional pipe parameter in
> intel_panel_bl_funcs->get(), and leave figuring out the current display
> pipe up to the caller.
>
> Signed-off-by: Lyude Paul
Much neater t
heckpatch
> v4:
> * Fix commit message
> * Remove outdated comment in intel_panel.c
> * Rename pwm_(min|max) to pwm_level_(min|max)
> * Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
> indirection
> * Don't move intel_dp_aux_init_bcklight_funcs() call to
gt; [ cut here ]
>>
>> The bisect came to this commit:
>>
>> fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c
>> ("drm/i915: Shut down displays gracefully on reboot")
>>
>> Which makes sense, as it happens on shutdown.
Please try this pull, heading to -rc4, which cointains "drm/i915:
Disable RPM wakeref assertions during driver shutdown":
http://lore.kernel.org/r/87sg73pz42@intel.com
BR,
Jani.
>>
>> -- Steve
>
--
Jani Nikula, Intel Open Source Graphics Center
On Thu, 14 Jan 2021, Jani Nikula wrote:
> On Wed, 13 Jan 2021, Lyude Paul wrote:
>> Currently, every different type of backlight hook that i915 supports is
>> pretty straight forward - you have a backlight, probably through PWM
>> (but maybe DPCD), with a single set of pl
? 0:1);
> + SHARED_MEM_PWR_DIS, power_on ? 0:1);
Not my driver, but this is as simple as it gets:
+ SHARED_MEM_PWR_DIS, !power_on);
>
> }
--
Jani Nikula, Intel Open Source Graphics Center
; Most of my patches fix issues that have been there for years!
We auto-update the for-linux-next and for-linux-next-fixes branches, and
they seem to be up-to-date [1].
How recent are the fixes, maybe because of this: [2]?
BR,
Jani.
[1] https://cgit.freedesktop.org/drm/drm-misc
[2] http://lore.kernel.org/r/20210114113107.62210...@canb.auug.org.au
--
Jani Nikula, Intel Open Source Graphics Center
backlight(connector);
What do you think?
BR,
Jani.
> - val = intel_panel_compute_brightness(connector, val);
> - panel->backlight.level = clamp(val, panel->backlight.min,
> -panel->backlight.max);
> -
> - panel->backlight.enabled = ctl2 & BLM_PWM_ENABLE;
> + panel->backlight.pwm_enabled = ctl2 & BLM_PWM_ENABLE;
>
> return 0;
> }
> @@ -1828,24 +1815,18 @@ bxt_setup_backlight(struct intel_connector
> *connector, enum pipe unused)
--
Jani Nikula, Intel Open Source Graphics Center
On Wed, 13 Jan 2021, Lee Jones wrote:
> On Wed, 13 Jan 2021, Jani Nikula wrote:
>
>> On Wed, 13 Jan 2021, Lee Jones wrote:
>> > Clear-up any confusion surrounding the Fixes: tag with regards to the
>> > need to Cc: the stable mailing list when submittin
ates. For more information, please read
> +:ref:`Documentation/process/stable-kernel-rules.rst `
Has there been a process change, or should I take it that a Fixes: tag
without Cc: stable *may* still end up being backported to stable?
BR,
Jani.
> +
> .. _the_canonical_patch_format:
>
> The canonical patch format
--
Jani Nikula, Intel Open Source Graphics Center
t_topology_mgr {
>* @max_payloads: maximum number of payloads the GPU can generate.
>*/
> int max_payloads;
> + /**
> + * @max_source_rate: maximum link rate of source.
> + */
> + int max_source_rate;
Again, make this the actual rate in kHz. That's what I'd think it is by
reading the comment above anyway.
> /**
>* @conn_base_id: DRM connector ID this mgr is connected to. Only used
>* to build the MST connector path value.
--
Jani Nikula, Intel Open Source Graphics Center
simply forward the bug report to the proper maintainer if they are able
>> to ascertain that
>
>
> Well, do we really need bugzilla and a middleperson for triaging and
> forwarding when it we are taking about reports filed by distribution
> maintainers? They are unlikely to be newcomers to FLOSS bug reporting,
> so they IMHO should be able to read the MAINTAINERS file and follow
> Documentation/admin-guide/reporting-issues.rst
>
>> This is far from perfect and still hinges on finding a person willing to do
>
>> bug triage. However, it should hopefully improve the workflow without making
>
>> it too complicated.
>
> It might imrpove the workflow, but one question wasn't raised: why do we
> need two places to report bugs to at all? The MAINTAINERS file is there
> and the places specified there are clearly the ones maintainers prefer.
> Sure, bugzilla is easier to handle, especially for for inexperienced
> users. But is that worth it? Especially in its current state?
>
> Ciao, Thorsten
--
Jani Nikula, Intel Open Source Graphics Center
On Mon, 11 Jan 2021, Jani Nikula wrote:
> On Thu, 07 Jan 2021, Lyude Paul wrote:
>> This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
>> these quirks were added because of the issues with using the eDP
>> backlight interfaces on certain lapt
by checkpatch in
> intel_edp_init_connector()
>
> Signed-off-by: Lyude Paul
> Acked-by: Jani Nikula
Still stands.
BR,
Jani.
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
> ---
> drivers/gpu/drm/drm_dp_helper.c | 83 +--
> dr
to only probe for the Intel
> backlight interface (might be useful if we find panels in the wild that
> report the VESA interface in their VBT, but actually only support the
> Intel backlight interface).
>
> v3:
> * Rebase
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Jani Niku
ode from the DPCD
> * s/uint8_t/u8/
> * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
> * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()
>
> Signed-off-by: Lyude Paul
> Acked-by: Jani Nikula
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
> ---
&g
drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector
> *connector,
>0, user_max);
> }
>
> -static u32 intel_panel_compute_brightness(struct i
ssue on some gen4 platforms...
*facepalm*
BR,
Jani.
> drm_dbg_kms(_priv->drm,
> "CPU backlight register was enabled, switching to
> PCH override\n");
>
> /* Write converted CPU PWM value to PCH override register *
EL_DP_AUX_BACKLIGHT_ON:
> + if (i915->vbt.backlight.type !=
> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
> + try_intel_interface = true;
This could use an explanation - why not try the intel interface in this
case?
Anyway, good enough,
Reviewed-by: Ja
_backlight_funcs(struct intel_connector
> *intel_connector)
> +int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
> {
> - struct intel_panel *panel = _connector->panel;
> - struct intel_dp *intel_dp = enc_to_intel_dp(intel_connector->encoder);
enable = vlv_enable_backlight,
> .disable = vlv_disable_backlight,
> @@ -2077,7 +2102,7 @@ static const struct intel_panel_bl_funcs vlv_funcs = {
> .hz_to_pwm = vlv_hz_to_pwm,
> };
>
> -static const struct intel_panel_bl_funcs i965_funcs = {
> +static const struct intel_panel_bl_funcs i965_pwm_funcs = {
> .setup = i965_setup_backlight,
> .enable = i965_enable_backlight,
> .disable = i965_disable_backlight,
> @@ -2086,7 +2111,7 @@ static const struct intel_panel_bl_funcs i965_funcs = {
> .hz_to_pwm = i965_hz_to_pwm,
> };
>
> -static const struct intel_panel_bl_funcs i9xx_funcs = {
> +static const struct intel_panel_bl_funcs i9xx_pwm_funcs = {
> .setup = i9xx_setup_backlight,
> .enable = i9xx_enable_backlight,
> .disable = i9xx_disable_backlight,
> @@ -2095,6 +2120,14 @@ static const struct intel_panel_bl_funcs i9xx_funcs = {
> .hz_to_pwm = i9xx_hz_to_pwm,
> };
>
> +static const struct intel_panel_bl_funcs pwm_bl_funcs = {
> + .setup = intel_pwm_setup_backlight,
> + .enable = intel_pwm_enable_backlight,
> + .disable = intel_pwm_disable_backlight,
> + .set = intel_pwm_set_backlight,
> + .get = intel_pwm_get_backlight,
> +};
> +
> /* Set up chip specific backlight functions */
> static void
> intel_panel_init_backlight_funcs(struct intel_panel *panel)
> @@ -2103,36 +2136,39 @@ intel_panel_init_backlight_funcs(struct intel_panel
> *panel)
> container_of(panel, struct intel_connector, panel);
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>
> - if (connector->base.connector_type == DRM_MODE_CONNECTOR_eDP &&
> - intel_dp_aux_init_backlight_funcs(connector) == 0)
> - return;
> -
I think I'd keep this here in this patch. It helps with the
interpretation of the change here, i.e. we're not starting to utilize
the two levels just yet.
> if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI &&
> intel_dsi_dcs_init_backlight_funcs(connector) == 0)
> return;
>
> if (IS_GEN9_LP(dev_priv)) {
> - panel->backlight.funcs = _funcs;
> + panel->backlight.pwm_funcs = _pwm_funcs;
> } else if (INTEL_PCH_TYPE(dev_priv) >= PCH_CNP) {
> - panel->backlight.funcs = _funcs;
> + panel->backlight.pwm_funcs = _pwm_funcs;
> } else if (INTEL_PCH_TYPE(dev_priv) >= PCH_LPT) {
> if (HAS_PCH_LPT(dev_priv))
> - panel->backlight.funcs = _funcs;
> + panel->backlight.pwm_funcs = _pwm_funcs;
> else
> - panel->backlight.funcs = _funcs;
> + panel->backlight.pwm_funcs = _pwm_funcs;
> } else if (HAS_PCH_SPLIT(dev_priv)) {
> - panel->backlight.funcs = _funcs;
> + panel->backlight.pwm_funcs = _pwm_funcs;
> } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) {
> - panel->backlight.funcs = _pwm_funcs;
> + panel->backlight.pwm_funcs = _pwm_funcs;
> } else {
> - panel->backlight.funcs = _funcs;
> + panel->backlight.pwm_funcs = _pwm_funcs;
> }
> } else if (IS_GEN(dev_priv, 4)) {
> - panel->backlight.funcs = _funcs;
> + panel->backlight.pwm_funcs = _pwm_funcs;
> } else {
> - panel->backlight.funcs = _funcs;
> + panel->backlight.pwm_funcs = _pwm_funcs;
> }
> +
> + if (connector->base.connector_type == DRM_MODE_CONNECTOR_eDP &&
> + intel_dp_aux_init_backlight_funcs(connector) == 0)
> + return;
> +
> + /* We're using a standard PWM backlight interface */
> + panel->backlight.funcs = _bl_funcs;
> }
>
> enum drm_connector_status
--
Jani Nikula, Intel Open Source Graphics Center
review yet, just a
few notes below.
>
> Signed-off-by: Lyude Paul
> Cc: Jani Nikula
> Cc: Dave Airlie
> Cc: greg.depo...@gmail.com
> ---
> drivers/gpu/drm/drm_dp_helper.c | 332 ++
> .../drm/i915/display/intel_display_types.h
anges during runtime. So, let's simplify things by just caching
> this value in intel_panel.backlight, and re-writing it as-needed.
This isn't a full review, just something I spotted so far. Please see
inline.
BR,
Jani.
>
> Signed-off-by: Lyude Paul
> Cc: Jani Nikula
> Cc: D
t and
> postprocessing can easily deal with the occasional wraparound.
I'll let Tvrtko and Chris review the substance here, but assuming they
don't object,
Acked-by: Jani Nikula
for merging via whichever tree makes most sense.
>
> Signed-off-by: Thomas Gleixner
> Cc: Tvrtko Ursulin
&
On Thu, 10 Dec 2020, Ville Syrjälä wrote:
> On Thu, Dec 10, 2020 at 08:25:49PM +0100, Thomas Gleixner wrote:
>> Nothing uses the result and nothing should ever use it in driver code.
>>
>> Signed-off-by: Thomas Gleixner
>> Cc: Jani Nikula
>> Cc: Joonas Lah
i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_panel *panel = >panel;
> +
> + drm_WARN_ON_ONCE(_priv->drm,
> + panel->backlight.max == 0 || panel->backlight.pwm_max
> == 0);
> +
> + val = scale(val, panel->backlight.m
de register */
>> - lpt_set_backlight(connector->base.state,
>> panel->backlight.level);
>> + lpt_set_backlight(connector->base.state, val);
>> intel_de_write(dev_priv, BLC_PWM_PCH_CTL1,
>>pch_ctl1 | BLM_PCH_OVERRIDE_ENABLE);
>>
> The change here confused me since it no longer calls lpt_get_backlight
> in this path, the commit msg might explain this, but it didn't explain
> is so I could figure out if that was a mistake or intentional.
>
> Dave.
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
e difference between them and the high
> level PWM-only backlight functions is a bit more obvious.
>
> This introduces no functional changes.
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Rodrigo Vivi
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
Reviewed-by: Jani Ni
AKE(dev_priv))
> intel_dp_get_dsc_sink_cap(intel_dp);
>
> + /*
> + * If needed, program our source OUI so we can make various
> Intel-specific AUX services
> + * available (such as HDR backlight controls)
> + */
> + intel_edp_init_source_oui(intel_dp, true);
> +
> return true;
> }
--
Jani Nikula, Intel Open Source Graphics Center
On Tue, 24 Nov 2020, Christoph Hellwig wrote:
> Otherwise this looks good to me:
v3 sent.
> Reviewed-by: Christoph Hellwig
Thanks for the reviews, appreciated.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Reviewed-by: Christoph Hellwig
Signed-off-by: Jani Nikula
---
v2: Simplify after nuking some callbacks and making some others
mandatory in previous patches, as per Christoph's review comments.
I thought about adding wrappers for the now-mandatory create_buf_file
and remove_buf_file as well
create a file. So
> remove that case as well and just replace it with a sanity check in
> relay_open().
Many thanks for the feedback; sent v2 [1].
BR,
Jani.
[1] http://lore.kernel.org/r/cover.1606153547.git.jani.nik...@intel.com
--
Jani Nikula, Intel Open Source Graphics Center
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: Jens Axboe
Cc: linux-bl...@vger.kernel.org
Signed-off-by: Jani Nikula
---
kernel/trace/blktrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: Kalle Valo
Cc: QCA ath9k Development
Cc: linux-wirel...@vger.kernel.org
Acked-by: Kalle Valo
Signed-off-by: Jani Nikula
---
drivers/net/wireless/ath/ath9k/common-spectral.c | 2 +-
1 file changed, 1 insertion
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: Kalle Valo
Cc: ath...@lists.infradead.org
Signed-off-by: Jani Nikula
---
drivers/net/wireless/ath/ath11k/spectral.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath11k
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: Kalle Valo
Cc: ath...@lists.infradead.org
Acked-by: Kalle Valo
Signed-off-by: Jani Nikula
---
drivers/net/wireless/ath/ath10k/spectral.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
Signed-off-by: Jani Nikula
---
v2: Simplify after nuking some callbacks and making some others
mandatory in previous patches, as per Christoph's review comments.
I thought about adding wrappers for the now-mandatory create_buf_file
and remove_buf_file as well, for consistency, but ended up
There are no clients passing NULL callbacks, which makes sense as it
wouldn't even create a file. Require non-NULL callbacks, and throw away
the handling for NULL callbacks.
Suggested-by: Christoph Hellwig
Cc: Christoph Hellwig
Signed-off-by: Jani Nikula
---
kernel/relay.c | 14
All clients provide create_buf_file and remove_buf_file callbacks, and
they're required for relay to make sense. There is no point in them
being optional.
Also document whether each callback is mandatory/optional.
Suggested-by: Christoph Hellwig
Cc: Christoph Hellwig
Signed-off-by: Jani Nikula
No relay client uses the buf_mapped or buf_unmapped callbacks. Remove
them. This makes relay's vm_operations_struct close callback a dummy,
remove it as well.
Suggested-by: Christoph Hellwig
Cc: Christoph Hellwig
Signed-off-by: Jani Nikula
---
include/linux/relay.h | 19
...@lists.infradead.org
Cc: Kalle Valo
Cc: linux-wirel...@vger.kernel.org
Cc: QCA ath9k Development
Cc: intel-...@lists.freedesktop.org
Cc: Christoph Hellwig
Cc: Andrew Morton
Jani Nikula (9):
relay: remove unused buf_mapped and buf_unmapped callbacks
relay: require non-NULL callbacks in relay_open()
relay
ge\|Revert\)" |\
sed 's/:[^:]*$//' |\
sort | uniq -c | sort -rn | head -5
already gives me results that really aren't worse than some of the
prefixes invented by drive-by contributors.
> Has anyone actually complained about treewide:?
As Joe said, I'd feel silly applying pa
On Wed, 18 Nov 2020, Jani Nikula wrote:
> Now that relay_open() accepts const callbacks, make relay callbacks
> const.
>
> Cc: Kalle Valo
> Cc: ath...@lists.infradead.org
> Signed-off-by: Jani Nikula
Kalle, thanks for the acks on the other two ath patches - can I have
your a
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: Kalle Valo
Cc: ath...@lists.infradead.org
Signed-off-by: Jani Nikula
---
drivers/net/wireless/ath/ath11k/spectral.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath11k
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: Kalle Valo
Cc: QCA ath9k Development
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/net/wireless/ath/ath9k/common-spectral.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: Kalle Valo
Cc: ath...@lists.infradead.org
Signed-off-by: Jani Nikula
---
drivers/net/wireless/ath/ath10k/spectral.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: Jens Axboe
Cc: linux-bl...@vger.kernel.org
Signed-off-by: Jani Nikula
---
kernel/trace/blktrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
-...@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
include/linux/relay.h | 4 +-
kernel/relay.c| 182 +++---
2 files changed, 86 insertions(+), 100 deletions(-)
diff --git a/include/linux/relay.h b/include/linux/relay.h
index e13a333e7c37..7333909df65a 100644
isplay/intel_dpll_mgr.c | 2 +-
> drivers/gpu/drm/i915/i915_gem_evict.c | 2 +-
> drivers/gpu/drm/i915/i915_perf.c | 8 +---
For the i915 parts,
Acked-by: Jani Nikula
for merging via whichever tree.
> drivers/gpu/drm/scheduler/sched_main.c| 2 +-
> drive
s_create_file("mmio_diff", 0444, vgpu->debugfs, vgpu,
> _mmio_diff_fops);
> - debugfs_create_file("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
> - _scan_nonprivbb_fops);
> + debugfs_create_file_unsafe("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
> +_scan_nonprivbb_fops);
> }
>
> /**
--
Jani Nikula, Intel Open Source Graphics Center
us' tree in the next merge
window in 6-8 weeks. Which is to say this should probably have been
applied to drm-misc-fixes branch heading for v5.10-rcX, with a Cc:
stable tag, to begin with.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
;
>> Also, the author's email name is missing the leading 'P'.
>
> And it shouldn't be in the drm-intel-fixes tree.
It's temporarily on top of the fixes branch to allow our CI to test the
branch. We weren't getting results on anything -rc1 based because of
this.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
>> ---
>>>> Documentation/gpu/i915.rst | 29 +
>>>> 1 file changed, 25 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
>>>> index 33cc6ddf8f64..cff1f154b473 100644
>>>> --- a/Documentation/gpu/i915.rst
>>>> +++ b/Documentation/gpu/i915.rst
>>>> @@ -636,15 +636,36 @@ i915 Perf Observation Architecture Stream
>>>> .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
>>>> :functions: i915_oa_poll_wait
>>>>
>>>> -All i915 Perf Internals
>>>>
>>>> +Other i915 Perf Internals
>>>> +-
>>>>
>>>> -This section simply includes all currently documented i915 perf
>>>> internals, in
>>>> -no particular order, but may include some more minor utilities or platform
>>>> +This section simply includes all other currently documented i915 perf
>>>> internals,
>>>> +in no particular order, but may include some more minor utilities or
>>>> platform
>>>> specific details than found in the more high-level sections.
>>>>
>>>> .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
>>>> :internal:
>>>> + :no-identifiers:
>>>> + i915_perf_init
>>>> + i915_perf_fini
>>>> + i915_perf_register
>>>> + i915_perf_unregister
>>>> + i915_perf_open_ioctl
>>>> + i915_perf_release
>>>> + i915_perf_add_config_ioctl
>>>> + i915_perf_remove_config_ioctl
>>>> + read_properties_unlocked
>>>> + i915_perf_open_ioctl_locked
>>>> + i915_perf_destroy_locked
>>>> + i915_perf_read i915_perf_ioctl
>>>> + i915_perf_enable_locked
>>>> + i915_perf_disable_locked
>>>> + i915_perf_poll i915_perf_poll_locked
>>>> + i915_oa_stream_init i915_oa_read
>>>> + i915_oa_stream_enable
>>>> + i915_oa_stream_disable
>>>> + i915_oa_wait_unlocked
>>>> + i915_oa_poll_wait
>>>>
>>>> Style
>>>> =
>>>> --
>>>> 2.26.2
>>>>
>>
>>
>> Thanks,
>> Mauro
>
>
--
Jani Nikula, Intel Open Source Graphics Center
ons. Yet, it could be useful for maintainers to check
> about missing documents on their subsystems.
Seems like this should be part of checkpatch.pl somehow.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
is a bit more complicated, but I just redid my
>> patches to not depend on the above ones. I can revert back to the old
>> version, though. Andrew, let me know what works for you.
>
> Imo ignore, rebasing onto linux-next without those intel patches was
> the right thing for the 5.10 merge window.
> -Daniel
--
Jani Nikula, Intel Open Source Graphics Center
On Mon, 28 Sep 2020, Matt Roper wrote:
> On Mon, Sep 28, 2020 at 04:07:39PM -0700, Lucas De Marchi wrote:
>> On Mon, Sep 28, 2020 at 08:15:29PM +0300, Jani Nikula wrote:
>> > On Mon, 28 Sep 2020, "Surendrakumar Upadhyay, TejaskumarX"
>> > wrote:
>> >
the PCH
check should be used instead. Which avoids the problem altogether.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
On Mon, 28 Sep 2020, Ville Syrjälä wrote:
> On Mon, Sep 28, 2020 at 07:15:43AM -0700, James Ausmus wrote:
>> On Mon, Sep 28, 2020 at 04:43:11PM +0300, Jani Nikula wrote:
>> > On Mon, 28 Sep 2020, Tejas Upadhyay
>> > wrote:
>> > > JSL has update in vswin
bsequent IS_JASPERLAKE() branch would never be taken.
>
> BR,
> Jani.
>
> Tejas : In that case I will put attention note in comment about
> platform checks such that ladder distrubance can be avoided. What you
> suggest?
The solution is to make IS_ELKHARTLAKE() mean ELK and on
On Mon, 28 Sep 2020, "Surendrakumar Upadhyay, TejaskumarX"
wrote:
>
> From: Jani Nikula
> Sent: Monday, September 28, 2020 7:07 PM
> To: Surendrakumar Upadhyay, TejaskumarX
> ; Vivi, Rodrigo
> ; airl...@linux.ie
ombo_buf_trans(encoder, type, rate,
> _entries);
> + else if (IS_JASPERLAKE(dev_priv))
> + ddi_translations = jsl_get_combo_buf_trans(encoder, type, rate,
> +_entries);
> else if (IS_ELKHARTLAKE(dev_priv))
> ddi_translations = ehl_get_combo_buf_trans(encoder, type, rate,
> _entries);
--
Jani Nikula, Intel Open Source Graphics Center
\
> INTEL_VGA_DEVICE(0x4557, info), \
> - INTEL_VGA_DEVICE(0x4555, info), \
> + INTEL_VGA_DEVICE(0x4555, info)
> +
> +/* JSL */
> +#define INTEL_JSL_IDS(info) \
> + INTEL_VGA_DEVICE(0x4E71, info), \
> INTEL_VGA_DEVICE(0x4E61, info), \
> INTEL_VGA_DEVICE(0x4E57, info), \
> INTEL_VGA_DEVICE(0x4E55, info), \
--
Jani Nikula, Intel Open Source Graphics Center
fresh_data *self_refresh_data;
> +
> + /**
> + * worker:
Missing @, should be "@worker:".
> + *
> + * Per-CRTC worker for nonblock atomic commits.
> + */
> + struct kthread_worker *worker;
> };
>
> /**
--
Jani Nikula, Intel Open Source Graphics Center
we should restrict this to the supported platforms: cfl, whl, cml,
> icl, tgl
> no?
Mmh, this just exposes sink behaviour that I think can be supported by
any platform. I don't understand the notion of "supported platforms"
here.
>
>> +
>> return true;
>> }
>>
>> --
>> 2.26.2
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
alse;
> - fallthrough;
> + break;
> case DRM_FORMAT_MOD_LINEAR:
> case I915_FORMAT_MOD_X_TILED:
> case I915_FORMAT_MOD_Y_TILED:
Acked-by: Jani Nikula
for merging via whichever tree seems best.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
p_is_branch(dpcd) ||
> + dpcd[DP_DPCD_REV] < DP_DPCD_REV_10 ||
> + !(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
> + return 0;
Generally I think stuff like this is easier and faster to read with
multiple if statements and early return
e from drm_dp_has_mst() to drm_dp_read_mst_cap()
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Sean Paul
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 22 ++
> drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
> include/drm/drm_d
r.h
> index a1413a531eaf4..0c141fc81aaa8 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1635,6 +1635,7 @@ struct drm_dp_desc;
> bool drm_dp_has_sink_count(struct drm_connector *connector,
> const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> const struct drm_dp_desc *desc);
> +int drm_dp_get_sink_count(struct drm_dp_aux *aux);
>
> void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
> void drm_dp_aux_init(struct drm_dp_aux *aux);
--
Jani Nikula, Intel Open Source Graphics Center
re critical of accumulating a lot of inlines in
headers. Do we really want this in the header?
> +drm_dp_has_mst(struct drm_dp_aux *aux,
> +const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + u8 mstm_cap;
> +
> + if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
> + return false;
> +
> + if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, _cap) != 1)
> + return false;
> +
> + return !!(mstm_cap & DP_MST_CAP);
The !! is superfluous.
BR,
Jani.
> +}
> +
> #endif
--
Jani Nikula, Intel Open Source Graphics Center
hasn't gotten
>> sorted out in the later rc's.
>
> Yes, thank you, it seems we have a solution w/o the revert.
For posterity, I'm told the fix is [1].
BR,
Jani.
[1] https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/
--
Jani Nikula, Intel Open Source Graphics Center
d-off-by: Shuah Khan
> Signed-off-by: Dan Carpenter
> Signed-off-by: Kees Cook
> Signed-off-by: Olof Johansson
> Signed-off-by: Jonathan Corbet
> Signed-off-by: Chris Mason
> Signed-off-by: Greg Kroah-Hartman
> Signed-off-by: Dan Williams
FWIW,
Acked-by: Jani Nikula
>
ssure! That's like being a lemming when Disney
>> film makers come to push you off the cliff to create the 1958 nature
>> film "White Wilderness".
>
> :-)
Pushed, thanks for the patch and smile.
BR,
Jani.
>
>>
>> regards,
>> dan carpenter
>>
>
--
Jani Nikula, Intel Open Source Graphics Center
1 - 100 of 1745 matches
Mail list logo
