these NTSC and PAL modes, but AIUI this is part of a
grander plan to support devices with other timings.
Acked-by: Noralf Trønnes
> + { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" },
> + { DRM_MODE_TV_MODE_PAL, "PAL" },
> + { DRM_MODE_TV_MODE_PAL_M, "PAL-M" },
> + { DRM_MODE_TV_MODE_PAL_N, "PAL-N" },
> + { DRM_MODE_TV_MODE_SECAM, "SECAM" },
>
Den 17.11.2022 10.28, skrev Maxime Ripard:
> That file is included directly, so we can't use any MODULE macro. Let's
> leave a comment to avoid any future mistake.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Noralf Trønnes
Den 14.11.2022 14.00, skrev Maxime Ripard:
> KMS supports a number of named modes already, but it's never been
> documented anywhere, let's fix that.
>
> Signed-off-by: Maxime Ripard
>
> ---
Reviewed-by: Noralf Trønnes
t.c | 54
> +
> 2 files changed, 56 insertions(+)
>
This needs an entry in modedb.rst so people know named modes exist, with
that:
Reviewed-by: Noralf Trønnes
roper mode, and we
> thus can use the usual matching algo on timings, and can simply drop the
> name match.
>
> Suggested-by: Noralf Trønnes
> Signed-off-by: Maxime Ripard
>
> ---
Reviewed-by: Noralf Trønnes
; drm_display_mode we mean when passing a named mode.
>
> Tested-by: Mateusz Kwiatkowski
> Signed-off-by: Maxime Ripard
>
> ---
Reviewed-by: Noralf Trønnes
_GT(test, ret, 0);
> +
> + mode = drm_connector_pick_cmdline_mode(connector);
> + KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> + KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm),
> mode));
> +}
> +
There are 4 named mo
Den 07.11.2022 18.49, skrev Noralf Trønnes:
>
>
> Den 07.11.2022 15.16, skrev Maxime Ripard:
>> The framework will get the drm_display_mode from the drm_cmdline_mode it
>> got by parsing the video command line argument by calling
>> drm_connector_pick_cmdline_mode
Den 07.11.2022 19.03, skrev Noralf Trønnes:
>
>
> Den 07.11.2022 15.16, skrev Maxime Ripard:
>> Now that we can easily extend the named modes list, let's add a few more
>> analog TV modes that were used in the wild, and some unit tests to make
>> sure it works as
Den 07.11.2022 15.16, skrev Maxime Ripard:
> From: Noralf Trønnes
>
> Most of the TV connectors will need a similar get_modes implementation
> that will, depending on the drivers' capabilities, register the 480i and
> 576i modes.
>
> That implementation will also need
Den 07.11.2022 15.16, skrev Maxime Ripard:
> Now that we can easily extend the named modes list, let's add a few more
> analog TV modes that were used in the wild, and some unit tests to make
> sure it works as intended.
>
> Signed-off-by: Maxime Ripard
>
> ---
> Changes in v6:
> - Renamed
gt;flags &
> DRM_MODE_FLAG_INTERLACE);
> + if (!mode)
> + return NULL;
> +
> + return mode;
You can just return the result from drm_analog_tv_mode() directly.
With those considered:
Reviewed-by: Nora
Den 07.11.2022 11.21, skrev Maxime Ripard:
> Hi Noralf,
>
> I'll leave aside your comments on the code, since we'll use your
> implementation.
>
> On Sun, Nov 06, 2022 at 05:33:48PM +0100, Noralf Trønnes wrote:
>> Den 26.10.2022 17.33, skrev max...@cerno.tech:
&
Den 07.11.2022 11.07, skrev Maxime Ripard:
> Hi Noralf,
>
> On Sun, Nov 06, 2022 at 05:59:23PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 27.10.2022 00.02, skrev Mateusz Kwiatkowski:
>>> Hi Maxime,
>>>
>>> First of all, nice idea with th
Den 27.10.2022 00.02, skrev Mateusz Kwiatkowski:
> Hi Maxime,
>
> First of all, nice idea with the helper function that can be reused by
> different
> drivers. This is neat!
>
> But looking at this function, it feels a bit overcomplicated. You're creating
> the two modes, then checking which
Den 26.10.2022 17.33, skrev max...@cerno.tech:
> Most of the TV connectors will need a similar get_modes implementation
> that will, depending on the drivers' capabilities, register the 480i and
> 576i modes.
>
> That implementation will also need to set the preferred flag and order
> the
e code to allow it, and some unit tests to exercise that code.
>
> Signed-off-by: Maxime Ripard
>
> ---
I would have just squashed the named mode part of this patch together
with the 2 other named mode patches and keep just the video= option part
here, but up to you:
Reviewed-by: Noralf Trønnes
would just squash this with the previous patch, either way:
Reviewed-by: Noralf Trønnes
> drivers/gpu/drm/drm_modes.c | 9 ++---
> include/drm/drm_connector.h | 7 +++
> 2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/dr
I could find that cares
about named modes are drm_client. Did I miss something here?
Apart from that:
Reviewed-by: Noralf Trønnes
> The plan is to remove that need and move the named mode handling out of
> drivers and into the core, and only rely on modes and properties. Let's
> star
Den 26.10.2022 17.33, skrev max...@cerno.tech:
> The framework will get the drm_display_mode from the drm_cmdline_mode it
> got by parsing the video command line argument by calling
> drm_connector_pick_cmdline_mode().
>
> The heavy lifting will then be done by the
the name and some additional parameters in the future.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Noralf Trønnes
are needed, so
> it's not a 1:1 move.
>
> Signed-off-by: Maxime Ripard
>
> ---
Reviewed-by: Noralf Trønnes
Den 05.11.2022 07.00, skrev Steven Rostedt:
> From: "Steven Rostedt (Google)"
>
> Before a timer is released, timer_shutdown_sync() must be called.
>
> Link: https://lore.kernel.org/all/20221104054053.431922...@goodmis.org/
>
> Cc: "Noralf Trønnes"
Den 19.10.2022 10.48, skrev Maxime Ripard:
> On Tue, Oct 18, 2022 at 02:29:00PM +0200, Noralf Trønnes wrote:
>>
>>
>> Den 18.10.2022 11.33, skrev Maxime Ripard:
>>> On Mon, Oct 17, 2022 at 12:44:45PM +0200, Noralf Trønnes wrote:
>>>> Den 13.10.2022
Den 18.10.2022 11.33, skrev Maxime Ripard:
> On Mon, Oct 17, 2022 at 12:44:45PM +0200, Noralf Trønnes wrote:
>> Den 13.10.2022 15.18, skrev Maxime Ripard:
>>> As part of the command line parsing rework coming in the next patches,
>>> we'll need to lookup d
V norm property. We're also making use of
> the new analog TV atomic_check helper to make sure we trigger a modeset
> whenever the TV mode is updated.
>
> Acked-by: Noralf Trønnes
> Signed-off-by: Maxime Ripard
>
> ---
> @@ -276,19 +292,96 @@ static void vc4_vec_
Den 13.10.2022 15.18, skrev Maxime Ripard:
> As part of the command line parsing rework coming in the next patches,
> we'll need to lookup drm_connector_tv_mode values by their name, already
> defined in drm_tv_mode_enum_list.
>
> In order to avoid any code duplication, let's do a function
create a helper that will take care of it.
>
> Reviewed-by: Noralf Trønnes
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 75
> +++
> include/drm/drm_atomic_state_helper.h | 1 +
> 2 files changed, 76 inse
Den 16.10.2022 20.52, skrev Mateusz Kwiatkowski:
> Hi Maxime,
>
>> static int vc4_vec_connector_get_modes(struct drm_connector *connector)
>> {
>> -struct drm_connector_state *state = connector->state;
>> struct drm_display_mode *mode;
>>
>> -mode =
Den 16.10.2022 19.51, skrev Mateusz Kwiatkowski:
> Hi Maxime, Noralf & everyone,
>
> I'd like to address Noralf here in particular, and refer to these discussions
> from the past:
>
> -
> https://lore.kernel.org/linux-arm-kernel/2f607c7d-6da1-c8df-1c02-8dd344a92...@gmail.com/
> -
>
Den 13.10.2022 15.18, skrev Maxime Ripard:
> The current construction of the named mode parsing doesn't allow to extend
> it easily. Let's move it to a separate function so we can add more
> parameters and modes.
>
> In order for the tests to still pass, some extra checks are needed, so
> it's
, int mode)
> return ret;
> }
> EXPORT_SYMBOL(drm_client_modeset_dpms);
> +
> +#ifdef CONFIG_DRM_KUNIT_TEST
> +#include "tests/drm_client_modeset_test.c"
> +#endif
I can't say I like including the file like this, but exporting the
static function for testing isn't attractive either and doing it like
this is shown in the kunit docs, so:
Acked-by: Noralf Trønnes
eant to provide those kind of helpers to avoid
> duplication.
>
> Signed-off-by: Maxime Ripard
>
> ---
Reviewed-by: Noralf Trønnes
Den 13.10.2022 10.36, skrev Maxime Ripard:
> Hi Noralf,
>
> On Sat, Oct 01, 2022 at 02:52:06PM +0200, Noralf Trønnes wrote:
>> Den 29.09.2022 18.31, skrev Maxime Ripard:
>>> Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
>>> 625-lines mode
Den 29.09.2022 18.30, skrev Maxime Ripard:
> Hi,
>
> Here's a series aiming at improving the command line named modes support,
> and more importantly how we deal with all the analog TV variants.
>
> The named modes support were initially introduced to allow to specify the
> analog TV mode to
Den 29.09.2022 18.31, skrev Maxime Ripard:
> Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
> 625-lines modes in their drivers.
>
> Since those modes are fairly standard, and that we'll need to use them
> in more places in the future, it makes sense to move their
mode = drm_mode_analog_pal_576i(connector->dev);
> + if (!mode) {
> + DRM_ERROR("Failed to create a new display mode\n");
> + return -ENOMEM;
> }
>
> - return i;
> + drm_mode_probed_add(connector, mode);
> + count += 1;
> +
> + r
eant to provide those kind of helpers to avoid
> duplication.
>
> Signed-off-by: Maxime Ripard
>
Reviewed-by: Noralf Trønnes
Den 29.09.2022 18.31, skrev Maxime Ripard:
> The TV mode property has been around for a while now to select and get the
> current TV mode output on an analog TV connector.
>
> Despite that property name being generic, its content isn't and has been
> driver-specific which makes it hard to
Den 29.09.2022 18.30, skrev Maxime Ripard:
> That property is not used or exposed by any driver in the kernel. Remove
> it from the documentation.
>
> Signed-off-by: Maxime Ripard
>
> ---
> Changes in v4:
> - New patch
> ---
> Documentation/gpu/kms-properties.csv | 1 -
> 1 file changed, 1
Den 26.09.2022 12.01, skrev Maxime Ripard:
> On Sat, Sep 24, 2022 at 05:52:29PM +0200, Noralf Trønnes wrote:
>> Den 22.09.2022 16.25, skrev Maxime Ripard:
>>> The TV mode property has been around for a while now to select and get the
>>> current TV mode outpu
Den 26.09.2022 11.36, skrev Maxime Ripard:
> Hi Noralf,
>
> On Sat, Sep 24, 2022 at 08:06:17PM +0200, Noralf Trønnes wrote:
>> Den 24.09.2022 19.56, skrev Noralf Trønnes:
>>>
>>>
>>> Den 22.09.2022 16.25, skrev Maxime Ripard:
>>>> As th
egisters.
>
> Signed-off-by: Mateusz Kwiatkowski
> Signed-off-by: Maxime Ripard
>
Acked-by: Noralf Trønnes
nd up accepting a non-functional mode.
>
> Signed-off-by: Mateusz Kwiatkowski
> Signed-off-by: Maxime Ripard
>
Acked-by: Noralf Trønnes
rename this one to legacy_tv_mode to make it
> obvious we should move away from it.
>
> Signed-off-by: Maxime Ripard
>
Reviewed-by: Noralf Trønnes
oper VEC preset for this
> mode instead of just changing PAL subcarrier frequency.
>
> Signed-off-by: Mateusz Kwiatkowski
> Signed-off-by: Maxime Ripard
>
Acked-by: Noralf Trønnes
Den 22.09.2022 16.25, skrev Maxime Ripard:
> Hi,
>
> Here's a series aiming at improving the command line named modes support,
> and more importantly how we deal with all the analog TV variants.
>
> The named modes support were initially introduced to allow to specify the
> analog TV mode to
Den 22.09.2022 16.25, skrev Maxime Ripard:
> As the number of kunit tests in KMS grows further, we start to have
> multiple test suites that, for example, need to register a mock DRM
> driver to interact with the KMS function they are supposed to test.
>
> Let's add a file meant to provide
Den 24.09.2022 19.56, skrev Noralf Trønnes:
>
>
> Den 22.09.2022 16.25, skrev Maxime Ripard:
>> As the number of kunit tests in KMS grows further, we start to have
>> multiple test suites that, for example, need to register a mock DRM
>> driver to int
vc4_vec_tv_modes[state->tv.legacy_mode].mode);
> + mode = drm_mode_analog_ntsc_480i(connector->dev);
> if (!mode) {
> DRM_ERROR("Failed to create a new display mode\n");
> return -ENOMEM;
> }
>
> + mode->type
Den 22.09.2022 16.25, skrev Maxime Ripard:
> The TV mode property has been around for a while now to select and get the
> current TV mode output on an analog TV connector.
>
> Despite that property name being generic, its content isn't and has been
> driver-specific which makes it hard to
's rename that
> function to mention it's deprecated. We'll introduce a new variant of
> that function creating the property superseeding it in a later patch.
>
> Signed-off-by: Maxime Ripard
>
Reviewed-by: Noralf Trønnes
removing the display
mode check. It's only about detecting changes now.
Noralf.
>
> Let's create an atomic_check helper for those use cases.
>
> Reviewed-by: Noralf Trønnes
> Signed-off-by: Maxime Ripard
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/
Den 22.09.2022 16.25, skrev Maxime Ripard:
> Since we've recently added a ton of tests, the list starts to be a bit
> of a mess and creates unneeded conflicts.
>
> Let's order it alphabetically.
>
> Signed-off-by: Maxime Ripard
>
Reviewed-by: Noralf Trønnes
Den 21.09.2022 16.03, skrev Maxime Ripard:
> On Wed, Sep 07, 2022 at 06:44:53PM +0200, Noralf Trønnes wrote:
>>
>>
>> Den 07.09.2022 12.36, skrev Stefan Wahren:
>>> Hi Maxime,
>>>
>>> Am 05.09.22 um 16:57 schrieb Maxime Ripard:
>>>> On
Den 07.09.2022 18.44, skrev Noralf Trønnes:
>
>
> Den 07.09.2022 12.36, skrev Stefan Wahren:
>> Hi Maxime,
>>
>> Am 05.09.22 um 16:57 schrieb Maxime Ripard:
>>> On Fri, Sep 02, 2022 at 01:28:16PM +0200, Noralf Trønnes wrote:
>>>>
>>>&g
Den 07.09.2022 12.36, skrev Stefan Wahren:
> Hi Maxime,
>
> Am 05.09.22 um 16:57 schrieb Maxime Ripard:
>> On Fri, Sep 02, 2022 at 01:28:16PM +0200, Noralf Trønnes wrote:
>>>
>>> Den 01.09.2022 21.35, skrev Noralf Trønnes:
>>>>
>>>&
Den 08.09.2022 13.23, skrev Maxime Ripard:
> Hi Noralf,
>
> On Tue, Aug 30, 2022 at 09:01:08PM +0200, Noralf Trønnes wrote:
>>> +static const struct drm_prop_enum_list tv_mode_names[] = {
>>
>> Maybe call it legacy_tv_mode_enums?
>>
>&
Den 07.09.2022 11.58, skrev Maxime Ripard:
> On Mon, Sep 05, 2022 at 05:17:18PM +0200, Noralf Trønnes wrote:
>> Den 05.09.2022 16.57, skrev Maxime Ripard:
>>> On Fri, Sep 02, 2022 at 01:28:16PM +0200, Noralf Trønnes wrote:
>>>>
>>>>
>&
Den 29.08.2022 15.11, skrev Maxime Ripard:
> The TV mode property has been around for a while now to select and get the
>
> current TV mode output on an analog TV connector.
>
>
>
> Despite that property name being generic, its content isn't and has been
>
> driver-specific which makes it
Den 29.08.2022 15.11, skrev Maxime Ripard:
> The mode_fixup hooks are deprecated, and the behaviour we implement is the
>
> default one anyway. Let's remove it.
>
>
>
> Signed-off-by: Maxime Ripard
>
Reviewed-by: Noralf Trønnes
Den 29.08.2022 15.11, skrev Maxime Ripard:
> Hi,
>
>
>
> Here's a series aiming at improving the command line named modes support,
>
> and more importantly how we deal with all the analog TV variants.
>
>
>
> The named modes support were initially introduced to allow to specify the
>
>
Den 05.09.2022 16.57, skrev Maxime Ripard:
> On Fri, Sep 02, 2022 at 01:28:16PM +0200, Noralf Trønnes wrote:
>>
>>
>> Den 01.09.2022 21.35, skrev Noralf Trønnes:
>>>
>>>
>>> I have finally found a workaround for my kernel hangs.
>>>
>
.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
>
> + .config1 = VEC_CONFIG1_C_CVBS_CVBS,
>
> },
>
> [VC4_VEC_TV_MODE_PAL_M] = {
>
> .mode = _mode,
>
> - .mode_set = vc4_vec_pal_m_mode_set,
>
> + .config0 = VEC_CONFIG0
Den 29.08.2022 15.11, skrev Maxime Ripard:
> As part of the command line parsing rework coming in the next patches,
>
> we'll need to lookup drm_connector_tv_mode values by their name, already
>
> defined in drm_tv_mode_enum_list.
>
>
>
> In order to avoid any code duplication, let's do a
Den 29.08.2022 15.11, skrev Maxime Ripard:
> Since we've recently added a ton of tests, the list starts to be a bit
>
> of a mess and creates unneeded conflicts.
>
>
>
> Let's order it alphabetically.
>
>
>
> Signed-off-by: Maxime Ripard
>
>
>
Something has gone wrong with this
gt;> 16) &
>
> - 0x);
>
> + (tv_mode->custom_freq >> 16) & 0x);
>
> VEC_WRITE(VEC_FREQ1_0,
>
> - vec->tv_mode->custom_freq & 0x);
>
>
Den 29.08.2022 15.11, skrev Maxime Ripard:
> Now that the core can deal fine with analog TV modes, let's convert the vc4
>
> VEC driver to leverage those new features.
>
>
>
> We've added some backward compatibility to support the old TV mode property
>
> and translate it into the new TV
Den 29.08.2022 15.11, skrev Maxime Ripard:
> Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
>
> 625-lines modes in their drivers.
>
>
>
> Since those modes are fairly standard, and that we'll need to use them
>
> in more places in the future, it makes sense to move
Den 29.08.2022 15.11, skrev Maxime Ripard:
> Now that the core has a definition for the 525 and 625 lines analog TV
>
> modes, let's switch to it for vc4.
>
>
>
> Signed-off-by: Maxime Ripard
>
>
>
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
>
> index
ards.
>
>
>
> Previous timings were actually defined as 502 and 601 lines, resulting
>
> in non-standard 62.69 Hz and 52 Hz signals being generated,
>
> respectively.
>
>
>
> Signed-off-by: Mateusz Kwiatkowski
>
> Signed-off-by: Maxime Ripard
>
>
Acked-by: Noralf Trønnes
Den 29.08.2022 15.11, skrev Maxime Ripard:
> The VC4 VEC driver still uses legacy enable and disable hook
>
> implementation. Let's convert to the atomic variants.
>
>
>
> Signed-off-by: Maxime Ripard
>
Reviewed-by: Noralf Trønnes
igned-off-by: Maxime Ripard
>
Reviewed-by: Noralf Trønnes
Den 01.09.2022 21.35, skrev Noralf Trønnes:
>
>
> I have finally found a workaround for my kernel hangs.
>
> Dom had a look at my kernel and found that the VideoCore was fine, and
> he said this:
>
>> That suggests cause of lockup was on arm side rather than V
t;
>
> Let's create a helper that will take care of it.
>
>
>
> Signed-off-by: Maxime Ripard
>
Reviewed-by: Noralf Trønnes
Den 29.08.2022 15.11, skrev Maxime Ripard:
> The current tv_mode has driver-specific values that don't allow to
>
> easily share code using it, either at the userspace or kernel level.
>
>
>
> Since we're going to introduce a new, generic, property that fit the
>
> same purpose, let's
.contrast ||
old_conn_state->tv.flicker_reduction !=
new_conn_state->tv.flicker_reduction ||
old_conn_state->tv.overscan != new_conn_state->tv.overscan ||
old_conn_state->tv.saturation != new_conn_state->tv.saturation ||
old_conn_state->tv.h
if (!pipe->funcs || !pipe->funcs->prepare_fb) {
> + if (WARN_ON_ONCE(drm_core_check_feature(plane->dev,
> DRIVER_GEM)))
Shouldn't this check be inverted? Looks like it warns on GEM drivers.
With that considered:
Acked-by: Noralf Trønnes
Hopefully this reply will
Den 21.05.2021 11.09, skrev Daniel Vetter:
> Goes through all the drivers and deletes the default hook since it's
> the default now.
>
> Signed-off-by: Daniel Vetter
Acked-by: Noralf Trønnes
___
Intel-gfx mailing li
Den 31.07.2020 14.51, skrev Oleksandr Andrushchenko:
> From: Oleksandr Andrushchenko
>
> Add YUYV to supported formats, so the frontend can work with the
> formats used by cameras and other HW.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
Ack
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
Acked-by: Noralf Trønnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Den 12.06.2020 18.00, skrev Daniel Vetter:
> Same patch as the mipi-dbi one, atomic tracks this for us already, we
> just have to check the right thing.
>
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
> ---
crtc is off. And we don't want to
> upload frames when that's the case, so filter that out too.
>
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: David Lechner
&g
Den 05.04.2020 15.47, skrev Daniel Vetter:
> On Sun, Apr 5, 2020 at 12:18 PM Noralf Trønnes wrote:
>>
>>
>>
>> Den 03.04.2020 15.57, skrev Daniel Vetter:
>>> Also init the fbdev emulation before we register the device, that way
>>> we can rely on
parent can be NULL.
> - *
> - * Drivers that wish to subclass or embed drm_device into their
> - * own struct should look at using drm_dev_init() instead.
> + * This is the deprecated version of devm_drm_dev_alloc(), which doesn not
> support
s/doesn/does/
> + * subclassing through embedding t
ons and make the documentation for driver authors a lot
> cleaner and less confusing. There will be only one true way to
> initialize a drm_device at the end of this, which is going to be
> devm_drm_dev_alloc.
>
> Cc: Paul Kocialkowski
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
Den 03.04.2020 15.57, skrev Daniel Vetter:
> Also init the fbdev emulation before we register the device, that way
> we can rely on the auto-cleanup and simplify the probe error code even
> more.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Sean Paul
> Cc: Thomas Zimmermann
>
Den 03.04.2020 15.58, skrev Daniel Vetter:
> Already using devm_drm_dev_init, so very simple replacment.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: "Noralf Trønnes"
> Cc: Rob H
Den 03.04.2020 15.58, skrev Daniel Vetter:
> Already using devm_drm_dev_init, so very simple replacment.
>
> Signed-off-by: Daniel Vetter
> Cc: Kamlesh Gurudasani
> ---
Acked-by: Noralf Trønnes
___
Intel-gfx mailing
Den 03.04.2020 15.58, skrev Daniel Vetter:
> Already using devm_drm_dev_init, so very simple replacment.
>
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
> ---
Acked-by: Noralf Trønnes
___
Intel-g
Den 03.04.2020 15.58, skrev Daniel Vetter:
> Already using devm_drm_dev_init, so very simple replacment.
>
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
> ---
Acked-by: Noralf Trønnes
___
Intel-g
n fails, we'd be
> missing some mutex_destroy and ida_cleanup otherwise (Laurent)
>
> v4: Add a drmm_add_action_or_reset (like devm_ has) to encapsulate this
> pattern (Noralf).
>
> Cc: Laurent Pinchart
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc: Thomas
vid Airlie
> Cc: Daniel Vetter
> Cc: Eric Anholt
> Cc: David Lechner
> Cc: Kamlesh Gurudasani
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> ---
Reviewed-by: Noralf Trønnes
___
Intel-gfx mailing list
Intel-gfx@list
Den 19.02.2020 11.21, skrev Daniel Vetter:
> 7/7 drivers agree that's the right choice, let's do this.
>
> This avoids duplicating the same old error checking code over all 7
> drivers, which is the motivation here.
>
> Signed-off-by: Daniel Vetter
> ---
Review
Den 19.02.2020 11.21, skrev Daniel Vetter:
> Allows us to drop the drm_driver.release callback.
>
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
> ---
Reviewed-by: Noralf Trønnes
___
Intel-gfx mailing list
Intel-
Den 19.02.2020 11.20, skrev Daniel Vetter:
> With this we can drop the final kfree from the release function.
>
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
> ---
Reviewed-by: Noralf Trønnes
___
Intel-g
ers, the first few lines around devm_drm_dev_init
> are all the same (except for the drm_driver pointer).
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Eric Anholt
> Cc: David Lechner
> Cc:
gt; devm_drm_dev_init().
>>>>>
>>>>> Also with drmm_ explicit drm_driver->release hooks are kinda not the
>>>>> best option, so deprecate that hook to discourage future users.
>>>>>
>>>>> v2: Fixup the example in the kernel
, the emphasis is now that "I hold the lock" right?
> already" aspect, so rename the function to match.
>
> Suggested by Noralf.
>
> Cc: Noralf Trønnes
> Signed-off-by: Daniel Vetter
> ---
Reviewed-by: Noralf Trønnes
__
1 - 100 of 563 matches
Mail list logo
