All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Dan Williams <dan.j.williams@intel.com>,
	<linux-cxl@vger.kernel.org>, <ben.widawsky@intel.com>,
	<vishal.l.verma@intel.com>, <ira.weiny@intel.com>,
	<alison.schofield@intel.com>
Subject: CXL type 3 which doesn't have cxl mem enabled.
Date: Tue, 26 Apr 2022 18:08:32 +0100	[thread overview]
Message-ID: <20220426180832.00005f0b@Huawei.com> (raw)

Hi All,

I ran into this whilst debugging why on the current QEMU code
we now get a probe failure for CXL mem due to the range 1 size being
non 0. 

The conditions for whether we have legacy ranges programmed don't
take into account if Mem_Enable = 1.  That is if the
DVSEC CXL Control Mem_Enable bit is set on the type 3 device.
If it's not then there is no existing user of the CXL memory
setup by firmware or similar so we can switch over to HDM
decoders and it doesn't matter what is in the range registers.

Unfortunately the QEMU code was bringing the device up with
Mem_Enabled already set.  So I fixed that.  After all default
value of that bit should be 0.

A few problems then showed up.

1. Nothing in the Linux code actually sets Mem_Enabled to 1.
2. Probing fails in mem.c as wait_for_media() checks for
   info->mem_enabled (cached value of this bit).

So, dirty hack was to 
* drop that check in wait_for_media() as media being enabled doesn't
  have much to do with CXL.mem protocol being enabled.
* Make the check in cxl_hdm_decode_init()
   if (info->mem_enabled && !global_enable && info->ranges)
* Immediately after enabling the hdm decoder global enable,
  also set the Mem_Enable bit also update info->mem_enabled.

This seems to work, but I can't help thinking I'm missing something.

Jonathan

             reply	other threads:[~2022-04-26 17:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-26 17:08 Jonathan Cameron [this message]
2022-04-26 17:19 ` CXL type 3 which doesn't have cxl mem enabled Dan Williams
2022-04-26 18:06   ` Jonathan Cameron
2022-04-26 19:00     ` Dan Williams
2022-04-26 19:38       ` Jonathan Cameron
2022-04-26 20:02         ` Dan Williams
2022-04-27  8:35           ` Jonathan Cameron
2022-04-28 21:10             ` Dan Williams

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=20220426180832.00005f0b@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=ben.widawsky@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=vishal.l.verma@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.