On Mon, 22 Apr 2024, Jani Nikula wrote:
> Surprisingly many places depend on debugfs.h to be included via
> drm_print.h. Fix them.
>
> v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe
>
> v2: Also fix ivpu and vmwgfx
>
> Reviewed-by: Andrzej Hajda
&
/20240410141434.157908-1-jani.nik...@intel.com
Signed-off-by: Jani Nikula
---
Cc: Jacek Lawrynowicz
Cc: Stanislaw Gruszka
Cc: Oded Gabbay
Cc: Russell King
Cc: David Airlie
Cc: Daniel Vetter
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej
On Mon, 08 Apr 2024, Dmitry Baryshkov wrote:
> On Mon, 8 Apr 2024 at 11:09, Jani Nikula wrote:
>> Thanks! Do you take this via the msm tree?
>
> Yes, I will
Forgot to mention, there's a Tested-by at [1].
Tested-by: Aishwarya TCV
[1] https://lore.kernel.org/r/157e69d4-850f-40d2
On Fri, 05 Apr 2024, Dmitry Baryshkov wrote:
> On Fri, Apr 05, 2024 at 12:29:07PM +0300, Jani Nikula wrote:
>> Logging u32 pixel formats using %4.4s format string with a pointer to
>> the u32 is somewhat questionable, as well as dependent on byte
>> order. There's a ke
the reported build warning:
include/drm/drm_print.h:536:35: warning: '%4.4s' directive argument is
null [-Wformat-overflow=]
Reported-by: Aishwarya TCV
Closes: https://lore.kernel.org/r/2ac758ce-a196-4e89-a397-488ba3101...@arm.com
Signed-off-by: Jani Nikula
---
Tip: 'git show --color-words -w
y: Abhinav Kumar
Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 78 +
> drivers/gpu/drm/i915/display/intel_dp.c | 71 +-
> include/drm/display/drm_dp_helper.h | 3 +
> 3 files changed, 83 insertions(+), 69 deleti
h
> @@ -100,6 +100,7 @@ struct drm_dp_vsc_sdp {
>
> void drm_dp_vsc_sdp_log(const char *level, struct device *dev,
> const struct drm_dp_vsc_sdp *vsc);
> +bool drm_dp_vsc_sdp_supported(struct drm_dp_aux *aux, const u8
> dpcd[DP_RECEIVER_CAP_SIZE]);
>
> int drm_dp_psr_setup_time(const u8 psr_cap[EDP_PSR_RECEIVER_CAP_SIZE]);
--
Jani Nikula, Intel
cks, pushed to drm-misc-next, even if I
didn't get an ack from Jaroslav or Takashi. Seems rather benign anyway.
BR,
Jani.
--
Jani Nikula, Intel
On Thu, 04 Jan 2024, Jani Nikula wrote:
> hdmi-codec.h does not appear to directly need drm/drm_edid.h for
> anything. Remove it.
Jaroslav, Takashi, ack for merging this via the drm trees, please?
BR,
Jani.
>
> There are some files that get drm/drm_edid.h by proxy; include it wh
-by: Jani Nikula
---
drivers/gpu/drm/bridge/lontium-lt9611.c| 1 +
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 1 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 +
drivers/gpu/drm/msm/dp/dp_display.c| 1 +
drivers/gpu/drm/tegra/hdmi.c | 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c
On Mon, 20 Nov 2023, Heiner Kallweit wrote:
> v4:
> - more ack and review tags
Please do not send new versions just to record the acks and
reviews. They should be added while applying the patches.
Thanks,
Jani.
--
Jani Nikula, Intel
On Tue, 12 Sep 2023, Abhinav Kumar wrote:
> Hi Jani
>
> On 9/12/2023 5:16 AM, Jani Nikula wrote:
>> On Thu, 07 Sep 2023, Stephen Boyd wrote:
>>> Quoting Jani Nikula (2023-09-01 07:20:34)
>>>> The DP CTS test for EDID last block checksum expects the check
On Thu, 07 Sep 2023, Stephen Boyd wrote:
> Quoting Jani Nikula (2023-09-01 07:20:34)
>> The DP CTS test for EDID last block checksum expects the checksum for
>> the last block, invalid or not. Skip the validity check.
>>
>> For the most part (*), the EDI
inav Kumar
Cc: Dmitry Baryshkov
Cc: Kuogee Hsieh
Cc: Marijn Suijten
Cc: Rob Clark
Cc: Sean Paul
Cc: Stephen Boyd
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/msm/dp/dp_panel.c | 21 ++---
1 file
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> Hello Jani,
>
> On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
>> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
>> > Hello,
>> >
>> > while I debugged an issue in the imx-lcdc driver I
_device *. As shown by the numbers above.
If folks insist on following through with this anyway, I'm firmly in the
camp the name should be "drm" and nothing else.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
gt; +{
> + return 2 << (dsc->bits_per_component - 8);
> +}
kernel-doc? Maybe make them regular functions instead of static inline?
BR,
Jani.
> +
> #endif /* _DRM_DSC_HELPER_H_ */
--
Jani Nikula, Intel Open Source Graphics Center
drm_dsc_get_bpp_int(const struct drm_dsc_config *dsc)
> +{
> + WARN_ON_ONCE(dsc->bits_per_pixel & 0xf);
> + return dsc->bits_per_pixel >> 4;
> +}
> +
> static inline u8 drm_dsc_initial_scale_value(const struct drm_dsc_config
> *dsc)
> {
>
clude the rest of pre-SCR parameters
> drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters
>
> drivers/gpu/drm/display/drm_dsc_helper.c | 986 ++
> drivers/gpu/drm/i915/display/intel_vdsc.c | 443 ++
> include/drm/display/drm_dsc_helper.h | 9 +
> 3 files changed, 1042 insertions(+), 396 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
rivers can use
>> it. No functional changes, just cleaned up some of the code when moving it
>> over.
>>
>> Acked-by: Jani Nikula
>> Reviewed-by: Rodrigo Vivi
>> Reviewed-by: Dmitry Baryshkov
>> Signed-off-by: Sean Paul
>> Signed-off-by: Mark Y
On Wed, 08 Mar 2023, Dmitry Baryshkov wrote:
> On Wed, 8 Mar 2023 at 12:14, Jani Nikula wrote:
>>
>> On Tue, 07 Mar 2023, Dmitry Baryshkov wrote:
>> > The array of rc_parameters contains a mixture of parameters from DSC 1.1
>> > and DSC 1.2 standards. Spl
_dsc_helper.h
> b/include/drm/display/drm_dsc_helper.h
> index 1681791f65a5..c634bb2935d3 100644
> --- a/include/drm/display/drm_dsc_helper.h
> +++ b/include/drm/display/drm_dsc_helper.h
> @@ -10,12 +10,17 @@
>
> #include
>
> +enum drm_dsc_params_kind {
> + DRM_DSC_1_2_444,
> + DRM_DSC_1_1_PRE_SCR, /* legacy params from DSC 1.1 */
> +};
> +
> void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header);
> int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
> void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
> const struct drm_dsc_config *dsc_cfg);
> void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
> -int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg);
> +int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum
> drm_dsc_params_kind kind);
> int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
>
> #endif /* _DRM_DSC_HELPER_H_ */
--
Jani Nikula, Intel Open Source Graphics Center
-- a/include/drm/display/drm_dsc_helper.h
> +++ b/include/drm/display/drm_dsc_helper.h
> @@ -10,12 +10,17 @@
>
> #include
>
> +enum drm_dsc_params_kind {
> + DRM_DSC_1_2_444,
> + DRM_DSC_1_1_PRE_SCR, /* legacy params from DSC 1.1 */
> +};
> +
> void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header);
> int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
> void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
> const struct drm_dsc_config *dsc_cfg);
> void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
> -int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg);
> +int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum
> drm_dsc_params_kind kind);
> int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
>
> #endif /* _DRM_DSC_HELPER_H_ */
--
Jani Nikula, Intel Open Source Graphics Center
{ 0, 4, 10 }, { 2, 7, 8 }, { 4, 9, 6 }, { 6, 11, 4 },
> + { 9, 11, 2 }, { 9, 11, 0 }, { 9, 12, -2 }, { 10, 12, -4 },
> + { 11, 12, -6 }, { 11, 13, -8 }, { 12, 14, -10 },
> + { 13, 15, -10 }, { 13, 16, -12 }, { 15, 21, -12 },
> + { 21, 23, -12 }
> + }
> + }
> +},
> { /* sentinel */ }
> };
--
Jani Nikula, Intel Open Source Graphics Center
gt; +{ DSC_BPP(6), 8,
I was kind of hoping for a patch that would clean up the hideous
indentation in the tables. Please at least let's not add more with the
one space indent?
> /* 6BPP/8BPC */
With designated initializers I think we could just toss the comments
out.
.bpp
rc_params->rc_quant_incr_limit1;
> -
> - for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
> - vdsc_cfg->rc_range_params[i].range_min_qp =
> - rc_params->rc_range_params[i].range_min_qp;
> - vdsc_cfg->rc_range_
+ return COLUMN_INDEX_12BPC;
> + case 14:
> + return COLUMN_INDEX_14BPC;
> + case 16:
> + return COLUMN_INDEX_16BPC;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static const struct rc_parameters *get_rc_pa
; + * Only 8 bits are allowed for programming RcBufThreshold
> + */
Not sure how appropriate the hardware references are, maybe clean it up
a bit.
With that, and +static and -export mentioned earlier,
Reviewed-by: Jani Nikula
> + vdsc_cfg->rc_buf_
mpressed_bpp == 8 &&
> + vdsc_cfg->bits_per_component == 14)
> + vdsc_cfg->rc_range_params[0].range_bpg_offset = 0;
> + }
> +
I wonder if we shouldn't just use the updated values...
Maybe add a FIXME comment above the block to conside
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
> On Tue, 28 Feb 2023 at 14:25, Jani Nikula wrote:
>>
>> On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
>> > The rc_buf_thresh values are common to all DSC implementations. Move
>> > them to the common helper togethe
c_helper.h
> @@ -14,6 +14,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header
> *pps_header);
> int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
> void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
> const struct drm_dsc_config *dsc_cfg);
> +void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
> int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
>
> #endif /* _DRM_DSC_HELPER_H_ */
--
Jani Nikula, Intel Open Source Graphics Center
.2. So we will
>>>>> have to end up changing both 1.1 and 1.2 tables as they are
>>>>> different for QC.
>>>>
>>>> I haven't heard back from Kuogee about the possible causes of using
>>>> rc/qp values from 1.2 even for 1.1 panels. Maybe you can comment on
>>>> that? In other words, can we always stick to the values from 1.2
>>>> standard? What will be the drawback?
>>>>
>>>> Otherwise, we'd have to have two different sets of values, like you
>>>> do in your vendor driver.
>>>>
>>>
>>> I have responded to this in the other email.
>>>
>>> All this being said, even if the rc tables move the drm_dsc_helper
>>> either now or later on, we will still need MSM specific calculations
>>> for many of the other encoder parameters (which are again either
>>> hard-coded or calculated). Please refer to the
>>> sde_dsc_populate_dsc_config() downstream. And yes, you will not find
>>> those in the DP spec directly.
>>>
>>> So we will still need a dsc helper for MSM calculations to be common
>>> for DSI / DP irrespective of where the tables go.
>>>
>>> So, lets finalize that first.
>>
>> I went on and trimmed sde_dsc_populate_dsc_config() to remove
>> duplication with the drm_dsc_compute_rc_parameters() (which we already
>> use for the MSM DSI DSC).
>>
>> Not much is left:
>>
>> dsc->first_line_bpg_offset set via the switch
>>
>> dsc->line_buf_depth = bpc + 1;
>> dsc->mux_word_size = bpc > 10 ? DSC_MUX_WORD_SIZE_12_BPC:
>> DSC_MUX_WORD_SIZE_8_10_BPC;
>>
>> if ((dsc->dsc_version_minor == 0x2) && (dsc->native_420))
>> dsc->nsl_bpg_offset = (2048 *
>> (DIV_ROUND_UP(dsc->second_line_bpg_offset,
>> (dsc->slice_height - 1;
>>
>> dsc->initial_scale_value = 8 * dsc->rc_model_size /
>> (dsc->rc_model_size - dsc->initial_offset);
>>
>>
>> mux_word_size comes from the standard (must)
>> initial_scale_value calculation is recommended, but not required
>> nsl_bpg_offset follows the standard (must), also see below (*).
>>
>> first_line_bpg_offset calculation differs between three drivers. The
>> standard also provides a recommended formulas. I think we can leave it
>> as is for now.
>>
>> I think, that mux_word_size and nsl_bpg_offset calculation should be
>> moved to drm_dsc_compute_rc_parameters(), while leaving
>> initial_scale_value in place (in the driver code).
>>
>> * I think nsl_bpg_offset is slightly incorrectly calculated. Standard
>> demands that it is set to 'second_line_bpg_offset / (slice_height - 1),
>> rounded up to 16 fraction bits', while SDE driver code sets it to the
>> value rounded up to the next integer (having 16 fraction bits
>> representation).
>>
>> In my opinion correct calculation should be:
>> dsc->nsl_bpg_offset = DIV_ROUND_UP(2048 * dsc->second_line_bpg_offset,
>> (dsc->slice_height - 1));
>>
>> Could you please check, which one is correct according to the standard?
>>
>>
>
> Sure, i will check about nsl_bpg_offset. But sorry if I was not more
> clear about this but sde_dsc_populate_dsc_config() is only one example
> which from your analysis can be moved to the drm_dsc_helper() but not
> the initial line calculation _dce_dsc_initial_line_calc(),
> _dce_dsc_ich_reset_override_needed() , _dce_dsc_setup_helper().
>
> All of these are again common between DSI and DP.
>
> So in addition to thinking about what can be moved to the drm_dsc_helper
> also think about what is specific to MSM but common to DSI and DP modules.
>
> That was the bigger picture I was trying to convey.
--
Jani Nikula, Intel Open Source Graphics Center
iew https://github.com/intel-lab-lkp/linux
> git fetch --no-tags linux-review
> Jani-Nikula/drm-connector-move-HDR-sink-metadata-to-display-info/20230124-174322
> git checkout 1e92b5478cfc1b0df6615365217e9548b0d5
> # save the config file
> mkdir build
On Tue, 24 Jan 2023, Dmitry Baryshkov wrote:
> Extract drm_kms_helper_enable_hpd() and drm_kms_helper_disable_hpd(),
> two helpers that enable and disable HPD handling on all device's
> connectors.
Thanks for separating this, it makes the other patch easier to read.
Reviewed-by: Ja
: Alain Volmat
Cc: Emma Anholt
Cc: Maxime Ripard
Signed-off-by: Jani Nikula
---
Sorry about the crazy Cc list, but this touches a lot of drivers, and I
didn't want to blind side anyone.
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 6 +--
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 6
ync(>mode_config.output_poll_work);
> -}
> -
> /**
> * drm_kms_helper_poll_disable - disable output polling
> * @dev: drm_device
> @@ -848,7 +854,12 @@ static void drm_kms_helper_poll_disable_fini(struct
> drm_device *dev, bool fini)
> */
> void drm_kms_helper_poll_disable(struct drm_device *dev)
> {
> - drm_kms_helper_poll_disable_fini(dev, false);
> + if (dev->mode_config.poll_running)
> + drm_kms_helper_disable_hpd(dev);
> +
> + cancel_delayed_work_sync(>mode_config.output_poll_work);
> +
> + dev->mode_config.poll_running = false;
> }
> EXPORT_SYMBOL(drm_kms_helper_poll_disable);
>
> @@ -886,7 +897,12 @@ EXPORT_SYMBOL(drm_kms_helper_poll_init);
> */
> void drm_kms_helper_poll_fini(struct drm_device *dev)
> {
> - drm_kms_helper_poll_disable_fini(dev, true);
> + if (!dev->mode_config.poll_enabled)
> + return;
> +
> + drm_kms_helper_poll_disable(dev);
> +
> + dev->mode_config.poll_enabled = false;
> }
> EXPORT_SYMBOL(drm_kms_helper_poll_fini);
--
Jani Nikula, Intel Open Source Graphics Center
goto out;
>> > + }
>> >
>> > if (!mutex_trylock(>mode_config.mutex)) {
>> > repoll = true;
>> > @@ -808,30 +838,6 @@ bool drm_kms_helper_is_poll_worker(void)
>> > }
>> > EXPORT_SYMBOL(drm_kms_helper_is_poll_worker)
out.
>
> The spec, as far as I can tell, says that it's up to the panel vendor
> to use whatever means they want to decide on the "preferred" refresh
> rate. Thus, as far as the spec is concerned this decision is made on
> an individual panel basis. ;-) This was really the justification for
> why my patch was just on one panel.
>
> In any case, as I said I'm OK w/ dropping this. We'll find other ways
> to work around the issue.
FWIW, if the EDID reported preferred mode works, I also think that's
what we should prefer.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
E_CONNECTOR_DisplayPort)
If we're doing this primarily to appease the CTS, this is fine.
If we think this is a functional improvement for regular use, I suppose
we should consider doing this also for DRM_MODE_CONNECTOR_eDP. Which is
irrelevant for the CTS.
Either way,
Acked-by: Jani Nikula
>
On Tue, 10 May 2022, Tomeu Vizoso wrote:
> And use it to store expectations about what the drm/msm driver is
> supposed to pass in the IGT test suite.
>
> Also include a configuration file that points to the out-of-tree CI
> scripts.
>
> By storing the test expectations along the code we can make
> drivers/gpu/drm/msm/dp/dp_link.c| 99 +-
> drivers/gpu/drm/msm/dp/dp_panel.c | 43 +++--
> drivers/gpu/drm/msm/dp/dp_parser.c | 2 +-
> drivers/gpu/drm/msm/dp/dp_power.c | 20 ---
> 9 files changed, 283 insertions(+), 187 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
m_writeback.h
> @@ -31,7 +31,7 @@ struct drm_writeback_connector {
>* by passing the @enc_funcs parameter to drm_writeback_connector_init()
>* function.
>*/
> - struct drm_encoder encoder;
> + struct drm_encoder *encoder;
>
> /**
>* @pixel_formats_blob_ptr:
--
Jani Nikula, Intel Open Source Graphics Center
On Fri, 07 Jan 2022, Stephen Boyd wrote:
> Quoting Jani Nikula (2022-01-07 05:07:59)
>> On Thu, 06 Jan 2022, Stephen Boyd wrote:
>> > This allows aggregate driver writers to use the device passed to their
>> > probe/remove/shutdown functions properly instead of tr
struct aggregate_driver *adrv;
> +
> + int id;
> +};
> +
> +static inline struct aggregate_device *to_aggregate_device(struct device *d)
> +{
> + return container_of(d, struct aggregate_device, dev);
> +}
>
> /**
> * struct aggregate_driver - Aggregate driver (made up of other drivers)
--
Jani Nikula, Intel Open Source Graphics Center
now and list all the drm subdirectories when looking up
stuff that's part of drm but not drivers.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
On Mon, 13 Dec 2021, Thomas Zimmermann wrote:
> Hi
>
> Am 13.12.21 um 14:34 schrieb Jani Nikula:
>> On Mon, 13 Dec 2021, Thomas Zimmermann wrote:
>>> Split-off DisplayPort functions from KMS helper library and move them
>>> into their own module. Reduces the
1d9ceefcddef0be33561b1646a1cbe
> prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
> prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
> --
> 2.34.1
>
--
Jani Nikula, Intel Open Source Graphics Center
ers/gpu/drm/drm_dp_mst_topology.c
> @@ -45,7 +45,7 @@
> #include
> #include
>
> -#include "drm_crtc_helper_internal.h"
> +#include "drm_dp_helper_internal.h"
> #include "drm_dp_mst_topology_internal.h"
>
> /**
> diff --git a/drivers/gpu/drm/drm_kms_helper_common.c
> b/drivers/gpu/drm/drm_kms_helper_common.c
> index 47e92400548d..88260d26409c 100644
> --- a/drivers/gpu/drm/drm_kms_helper_common.c
> +++ b/drivers/gpu/drm/drm_kms_helper_common.c
> @@ -29,6 +29,7 @@
>
> #include
>
> +#include "drm_dp_helper_internal.h"
> #include "drm_crtc_helper_internal.h"
>
> MODULE_AUTHOR("David Airlie, Jesse Barnes");
--
Jani Nikula, Intel Open Source Graphics Center
s see if this makes it thru email servers...
> ---
> block/fops.c | 1 +
> drivers/gpu/drm/drm_gem_shmem_helper.c | 1 +
> drivers/gpu/drm/i915/gt/intel_gtt.c | 1 +
> drivers/gpu/drm/i915/i915_request.c | 1 +
For the i915 parts,
Acked-by: Jani Nikula
--
Jani Nikula, Intel Open Source Graphics Center
On Fri, 15 Oct 2021, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 03:44:48PM +0300, Jani Nikula wrote:
>> On Fri, 15 Oct 2021, Claudio Suarez wrote:
>> > Once EDID is parsed, the monitor HDMI support information is available
>> > through drm_display_info.is_hdmi. Ret
or =
> drm_detect_hdmi_monitor(edid);
> intel_sdvo->has_hdmi_audio =
> drm_detect_monitor_audio(edid);
> + intel_sdvo->has_hdmi_monitor =
> +
> intel_connector_is_hdmi_monitor(connector);
> }
> } else
> status = connector_status_disconnected;
--
Jani Nikula, Intel Open Source Graphics Center
ia drm-misc they usually will cause conflicts for
> people during drm-tip rebuild. Also I would expect to see an ack
> requested from i915 maintainers for merging anything significant via
> drm-misc, which I don't think happened in this case.
Indeed. All other things aside, it looks like it has enough conflict
potential to warrant merging via drm-intel anyway.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
0-day and
> yamllint and incorporated early review feedback from the dt/dts reviews.
>
> Please take a look,
I'll try to ping folks to get someone to review the i915 parts, but the
general idea of moving common HDCP code from i915 to drm is, I hope
obviously,
Acked-by: Jani Nikula
>
> S
+-
> drivers/gpu/drm/msm/dp/dp_display.c | 14 ++--
> drivers/gpu/drm/msm/dp/dp_panel.c | 9 ++-
> 4 files changed, 102 insertions(+), 61 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
cing +
> selftests")
>
> Signed-off-by: Rajkumar Subbiah
> Signed-off-by: Kuogee Hsieh
>
> Reviewed-by: Stephen Boyd
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
drm_dp_mst_dump_sideband_msg_tx(, txmsg);
> + }
> return ret;
> }
Seems like a sensible thing to do.
(I'd probably rip out the "unlikely" while at it, as it feels like
unnecessary optimization, but *shrug*.)
Reviewed-by: Jani Nikul
> +free_ddc:
> + if (ddc)
> + put_device(>dev);
> +
> + return ret;
> +}
> +
> +static int dp_aux_backlight_remove(struct platform_device *pdev)
> +{
> + struct backlight_device *bd = platform_get_drvdata(pdev);
> + struct dp_aux_backlight *aux_bl = bl_get_data(bd);
> + struct i2c_adapter *ddc = _bl->aux->ddc;
> +
> + if (ddc)
> + put_device(>dev);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id dp_aux_bl_of_match_table[] = {
> + { .compatible = "dp-aux-backlight"},
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, dp_aux_bl_of_match_table);
> +
> +static struct platform_driver dp_aux_backlight_driver = {
> + .driver = {
> + .name = "dp-aux-backlight",
> + .of_match_table = dp_aux_bl_of_match_table,
> + },
> + .probe = dp_aux_backlight_probe,
> + .remove = dp_aux_backlight_remove,
> +
> +};
> +module_platform_driver(dp_aux_backlight_driver);
> +
> +MODULE_DESCRIPTION("DisplayPort aux backlight driver");
> +MODULE_LICENSE("GPL v2");
--
Jani Nikula, Intel Open Source Graphics Center
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
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
> cre
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
___
Freedreno mailing list
Freedreno@lists.freed
selftests/mock_gem_device.c
> index ce4d4303229c..4725dad63e0a 100644
> --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> @@ -86,9 +86,6 @@ static struct drm_driver mock_driver = {
> .name = "mock",
> .driver_
6: Change commit message
>
> Signed-off-by: Chandan Uddaraju
> Signed-off-by: Vara Reddy
> Signed-off-by: Tanmay Shah
Acked-by: Jani Nikula
for merging via drm-misc if that helps you.
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> include/drm/drm_dp_helper.h
drm/drm_displayid.h | 2 +-
> include/uapi/drm/i915_drm.h | 4 ++--
Not sure it's worth touching uapi headers. They're full of both [0] and
[]. Again, please at least split it to a separate patch to be decided
separately.
BR,
Jani.
--
Jani Nikula, Intel Open S
> * simplify function names
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Jani Nikula
for the approach and for merging through whichever tree makes most
sense, *however* needs detailed review on the whole.
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 7 +++
>
On Fri, 10 Jan 2020, Thomas Zimmermann wrote:
> Hi
>
> Am 10.01.20 um 12:59 schrieb Jani Nikula:
>> On Fri, 10 Jan 2020, Thomas Zimmermann wrote:
>>> The callback struct drm_driver.get_scanout_position() is deprecated in
>>> favor of struct drm_crtc_
f scanlines to go until end of vblank, e.g., -1 means "one scanline
> + * until start of active scanout / end of vblank."
> + *
> + * Returns:
> + *
> + * True on success, false if a reliable scanout position counter could
> + * not be read out
On Mon, 02 Dec 2019, Chandan Uddaraju wrote:
> The constant N value (0x8000) is used by multiple DP
> drivers. Define this value in header file and use this
> in the existing i915 display driver.
>
> Signed-off-by: Chandan Uddaraju
Reviewed-by: Jani Nikula
and ack for mergi
On Tue, 24 Sep 2019, Jani Nikula wrote:
> drm/print: move drm_debug variable to drm_print.[ch]
> drm/print: add drm_debug_enabled()
> drm/etnaviv: use drm_debug_enabled() to check for debug categories
> drm/i2c/sil164: use drm_debug_enabled() to check for debug categories
>
On Tue, 01 Oct 2019, Eric Engestrom wrote:
> On Tuesday, 2019-10-01 14:03:55 +0300, Jani Nikula wrote:
>> On Thu, 26 Sep 2019, Eric Engestrom wrote:
>> > On Tuesday, 2019-09-24 15:58:56 +0300, Jani Nikula wrote:
>> >> Hi all, v2 of [1], a little refac
On Thu, 26 Sep 2019, Eric Engestrom wrote:
> On Tuesday, 2019-09-24 15:58:56 +0300, Jani Nikula wrote:
>> Hi all, v2 of [1], a little refactoring around drm_debug access to
>> abstract it better. There shouldn't be any functional changes.
>>
>> I'd appreciate acks
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
v2: Move unlikely() to drm_debug_enabled()
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Reviewed-by: Rob Clark
Signed-off-by: Jani Nikula
@lists.freedesktop.org
Cc: Francisco Jerez
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
[1] cover.1568375189.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1568375189.git.jani.nikula@intel.com
Jani Nikula (9):
drm/print: move drm_debug
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 ++--
1 file changed, 2
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
Jani Nikula (9):
drm/print: move drm_debug variable to drm_print.[ch]
drm/print: add drm_debug_enabled()
drm/etnaviv: use drm_debug_enabled() to check for debug categories
drm/i2c/sil164: use
drm_device *dev,
> + struct drm_connector *connector,
> + const struct drm_connector_funcs *funcs,
> + int connector_type,
> + struct i2c_adapter *ddc);
> void drm_connector_attach_edid_property(struct
915/Makefile we actually go for much stricter
warnings than the kernel defaults, and disable a more limited and
tailored set of warnings.
You can do this both on a subdir and file level with subdir-ccflags-y
and CFLAGS_filename.o, respectively.
BR,
Jani.
--
Jani Nikul
u/drm/exynos/Kconfig |2 --
> drivers/gpu/drm/i915/Kconfig |3 ---
> drivers/gpu/drm/i915/Kconfig.debug | 13 -
For i915,
Acked-by: Jani Nikula
and can be merged through whichever tree you like.
> drivers/gpu/drm/msm/Kconfig |2 --
>
BR,
Jani.
>
> return freed;
> }
> @@ -134,7 +134,7 @@ msm_gem_shrinker_vmap(struct notifier_block *nb, unsigned
> long event, void *ptr)
> *(unsigned long *)ptr += unmapped;
>
> if (unmapped > 0)
> - pr_info_ratelimited("Purgin
; expect.
>
> v3: Rebase on top of atomic bochs.
>
> Cc: Sam Ravnborg
> Cc: Jani Nikula
> Cc: Laurent Pinchart
> Acked-by: Rodrigo Vivi (v2)
> Acked-by: Benjamin Gaignard (v2)
> Signed-off-by: Daniel Vetter
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: virt
ink mess.
Overall looks about right and nice,
Reviewed-by: Jani Nikula
But please do take that with a grain of salt for everything outside of
i915 and drm core.
Please also find a few comments inline below.
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (
On Thu, 24 May 2018, Joe Perches <j...@perches.com> wrote:
> On Fri, 2018-05-25 at 09:41 +0300, Jani Nikula wrote:
>> On Thu, 24 May 2018, Joe Perches <j...@perches.com> wrote:
>> > There is currently a mixture of octal and symbolic permissions uses
>> > i
-
> drivers/gpu/drm/i915/intel_pipe_crc.c | 2 +-
Please send at least i915 changes separately. There's zero reason to
make our lives harder for this change.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
just one conflict down the line because it touches
the kernel all over the place, then IMO it already wasn't worth
it. Merge conflicts are inevitable, but there's no reason to make life
harder just to cater for a cleanup patch. It's not that important.
Had it been split up, the drm parts would've
On Sun, 26 Feb 2017, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Thu, Feb 16, 2017 at 02:27:08PM +0200, Jani Nikula wrote:
>> On Thu, 16 Feb 2017, Rob Clark <robdcl...@gmail.com> wrote:
>> > On Thu, Feb 16, 2017 at 7:00 AM, Dan Carpenter <dan.carpen...@oracle.
83 matches
Mail list logo
