All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Lyude Paul <lyude@redhat.com>, Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>,
	Thomas Graichen <thomas.graichen@gmail.com>,
	dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] drm/tegra: Use drm_dp_aux_register_ddc/chardev() helpers
Date: Fri, 12 Nov 2021 23:45:36 +0300	[thread overview]
Message-ID: <9d7c2ff8-c154-b1e8-a7c5-c7f63aa5474f@gmail.com> (raw)
In-Reply-To: <be1833c5d27e666b760c729fc112d1bbd7b7a269.camel@redhat.com>

12.11.2021 23:26, Lyude Paul пишет:
>> BTW, I see now that DPAUX I2C transfer helper may access
>> aux->drm_device. Hence v1 patch isn't correct anyways.
> 
> JFYI - unless I'm misunderstanding you, the aux->drm_dev accesses in the DPAUX
> i2c transfer functions are just from the various drm_{dbg,err,etc.} calls,
> which means that they all should be able to handle aux->drm_dev being NULL. If
> you can set aux->drm_dev before i2c transfers start that's more ideal, since
> otherwise you'll see the AUX device name as "(null)" in the kernel log, but
> any point before device registration should work.

Thanks, I realized that have seen DRM log with a such debug messages
just a day ago.

drm drm: [drm:drm_dp_i2c_do_msg] (null): transaction timed out

So yes, it's indeed not critical.

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Lyude Paul <lyude@redhat.com>, Thierry Reding <thierry.reding@gmail.com>
Cc: David Airlie <airlied@linux.ie>,
	Thomas Graichen <thomas.graichen@gmail.com>,
	linux-kernel@vger.kernel.org,
	Jonathan Hunter <jonathanh@nvidia.com>,
	dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH v1 2/2] drm/tegra: Use drm_dp_aux_register_ddc/chardev() helpers
Date: Fri, 12 Nov 2021 23:45:36 +0300	[thread overview]
Message-ID: <9d7c2ff8-c154-b1e8-a7c5-c7f63aa5474f@gmail.com> (raw)
In-Reply-To: <be1833c5d27e666b760c729fc112d1bbd7b7a269.camel@redhat.com>

12.11.2021 23:26, Lyude Paul пишет:
>> BTW, I see now that DPAUX I2C transfer helper may access
>> aux->drm_device. Hence v1 patch isn't correct anyways.
> 
> JFYI - unless I'm misunderstanding you, the aux->drm_dev accesses in the DPAUX
> i2c transfer functions are just from the various drm_{dbg,err,etc.} calls,
> which means that they all should be able to handle aux->drm_dev being NULL. If
> you can set aux->drm_dev before i2c transfers start that's more ideal, since
> otherwise you'll see the AUX device name as "(null)" in the kernel log, but
> any point before device registration should work.

Thanks, I realized that have seen DRM log with a such debug messages
just a day ago.

drm drm: [drm:drm_dp_i2c_do_msg] (null): transaction timed out

So yes, it's indeed not critical.

  reply	other threads:[~2021-11-12 20:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-07 23:08 [PATCH v1 1/2] drm/dp: Add drm_dp_aux_register_ddc/chardev() helpers Dmitry Osipenko
2021-11-07 23:08 ` Dmitry Osipenko
2021-11-07 23:08 ` [PATCH v1 2/2] drm/tegra: Use " Dmitry Osipenko
2021-11-07 23:08   ` Dmitry Osipenko
2021-11-08 15:17   ` Daniel Vetter
2021-11-08 15:17     ` Daniel Vetter
2021-11-08 18:16     ` Dmitry Osipenko
2021-11-09  9:19       ` Daniel Vetter
2021-11-09  9:19         ` Daniel Vetter
2021-11-09 13:52         ` Dmitry Osipenko
2021-11-09 14:08           ` Dmitry Osipenko
2021-11-09 14:17             ` Dmitry Osipenko
2021-11-09 14:39               ` Dmitry Osipenko
2021-11-12 10:52                 ` Thierry Reding
2021-11-12 10:52                   ` Thierry Reding
2021-11-12 14:32                   ` Dmitry Osipenko
2021-11-12 14:32                     ` Dmitry Osipenko
2021-11-12 20:26                     ` Lyude Paul
2021-11-12 20:26                       ` Lyude Paul
2021-11-12 20:45                       ` Dmitry Osipenko [this message]
2021-11-12 20:45                         ` Dmitry Osipenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9d7c2ff8-c154-b1e8-a7c5-c7f63aa5474f@gmail.com \
    --to=digetx@gmail.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=thomas.graichen@gmail.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.