#include "intel_vdsc.h"
> #include "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
I think the fourcc 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
ch is a lot 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
> C
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
etty=format:%s -- |\
grep -v "^\(Merge\|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 com
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
On Wed, 23 Jan 2019, Edwin Zimmerman wrote:
> On Wed, 23 Jan 2019, Jani Nikula wrote:
>> On Wed, 23 Jan 2019, Greg KH wrote:
>> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>> >> Variables declared in a switch statement before any case statements
&
On Wed, 23 Jan 2019, Jani Nikula wrote:
> On Wed, 23 Jan 2019, Greg KH wrote:
>> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>>> Variables declared in a switch statement before any case statements
>>> cannot be initialized, so move all instances out of t
j = 0; /* not valid C */
case 0:
/* ... */
}
but can have e.g.:
switch (i) {
case 0:
{
int j = 0;
/* ... */
}
}
I think Kees' approach of moving such variable d
On Tue, 19 Dec 2017, Joe Perches wrote:
> drivers/gpu/drm/i915/i915_sysfs.c | 12 ++--
For i915,
Acked-by: Jani Nikula
--
Jani Nikula, Intel Open Source Technology Center
On Wed, 31 May 2017, David Miller wrote:
> And we can't understand why respinning with the requested change is
> less work than making several postings such as this one.
When our CI hits tons of non-drm issues every merge window, I imagine
our developers can start to get a little frustrated tryin
ff Kirsher
Cc: Dave Ertman
Cc: Bruce Allan
Cc: intel-wired-...@lists.osuosl.org
Cc: netdev@vger.kernel.org
Signed-off-by: Chris Wilson
[Jani: bikeshed repainted]
Signed-off-by: Jani Nikula
---
drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++-
1 file changed, 6 insertions(+), 1 delet
tel_dsm_guid, INTEL_DSM_REVISION_ID,
> + if (!acpi_check_dsm(dhandle, &intel_dsm_guid, INTEL_DSM_REVISION_ID,
> 1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) {
> DRM_DEBUG_KMS("no _DSM method for intel device\n");
> return false;
The drm/i915
On Tue, 13 Sep 2016, Shuah Khan wrote:
> On 09/13/2016 03:20 AM, Jani Nikula wrote:
>> FWIW, I'm in favor of moving *all* the code away from Documentation, not
>> just tests. Essentially removing the CONFIG_BUILD_DOCSRC config option,
>> and reserving Documentation/
the CONFIG_BUILD_DOCSRC config option,
and reserving Documentation/Makefile for documentation build. After this
series, some of the remaining code belongs under samples, some under
tools.
We could make it possible to include the code samples from samples into
the Sphinx built documentation.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
17 matches
Mail list logo
