All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Manasi Navare <manasi.d.navare@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: RMW considered harmful (was: Re: [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports)
Date: Thu, 28 Mar 2019 11:18:56 +0200	[thread overview]
Message-ID: <87lg0z2w73.fsf@intel.com> (raw)
In-Reply-To: <20190322194008.GB28038@intel.com>

On Fri, 22 Mar 2019, Manasi Navare <manasi.d.navare@intel.com> wrote:
> On Fri, Mar 22, 2019 at 09:28:01PM +0200, Jani Nikula wrote:
>> On Fri, 22 Mar 2019, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>> > On Fri, Mar 22, 2019 at 11:44:21AM -0700, Manasi Navare wrote:
>> >> On Fri, Mar 22, 2019 at 08:09:50PM +0200, Ville Syrjälä wrote:
>> >> > In that case there is no point in doing a rmw.
>> >> 
>> >> But isnt it always a good idea to do rmw? I mean what if the master
>> >> select was set to something else earlier?
>> >
>> > RMW is the root of many evils. It should be avoided unless there is a
>> > really compelling reason to use it.
>> 
>> Hear, hear!
>> 
>> We have the software state that we want to write to the hardware. If we
>> use RMW to do this, it might all work by coincidence due to the old
>> values in the registers, or it might just as well break by coincidence
>> due to some garbage in the registers.
>> 
>> In most cases, there should only be one place that writes a particular
>> display register during modeset. Sometimes this isn't possible, and RMW
>> is required.
>> 
>> Some registers also have reserved bits potentially used by the hardware
>> that must not be changed, and RMW is required. These are documented in
>> bspec.
>> 
>> BR,
>> Jani.
>>
>
> Thanks for the explanation. It does make sense now that we are doing a
> full modeset, we should just be then writing the value directly?  The
> only concern I have is that say DSI code sets this somewhere els ein
> the modeset path, then we would need to modify this to do RMW or
> always make sure DSI also uses the same function for writing to this
> reg.  What do you suggest doing now?

I think all encoders in a tile group are always of the same type.

If the tile grouping in your patch is based purely on EDID, we may need
to enforce this. Surely genlock only works on encoders of the same type?

In any case DSI (at least currently) does not use tile groups, and will
never be mixed up in non-DSI tile groups. The DSI transcoders are
separate from other transcoders, so we're not writing the same registers
here.

---

Looking at the code, I am wondering if this should be pushed to encoder
hooks instead of adding into crtc enable.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-03-28  9:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22  1:59 [PATCH 1/2] drm/i915/icl: Assign genlock CRTC pointer in all slave CRTC states for tiled displays Manasi Navare
2019-03-22  1:59 ` [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports Manasi Navare
2019-03-22  9:34   ` Jani Nikula
2019-03-22 13:16     ` Ville Syrjälä
2019-03-22 17:58       ` Manasi Navare
2019-03-22 18:09         ` Ville Syrjälä
2019-03-22 18:44           ` Manasi Navare
2019-03-22 18:46             ` Ville Syrjälä
2019-03-22 19:28               ` RMW considered harmful (was: Re: [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports) Jani Nikula
2019-03-22 19:40                 ` Manasi Navare
2019-03-28  9:18                   ` Jani Nikula [this message]
2019-03-28 15:40                     ` Manasi Navare
2019-03-29 10:56                       ` Jani Nikula
2019-03-22 17:54     ` [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports Manasi Navare
2019-03-22  4:12 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/icl: Assign genlock CRTC pointer in all slave CRTC states for tiled displays Patchwork
2019-03-22  4:32 ` ✓ Fi.CI.BAT: success " Patchwork
2019-03-23  0:56 ` ✓ Fi.CI.IGT: " Patchwork
2019-03-28  9:32 ` [PATCH 1/2] " Jani Nikula
2019-03-28 18:54   ` Manasi Navare

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=87lg0z2w73.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=manasi.d.navare@intel.com \
    /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.