public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
From: Armin Wolf <W_Armin@gmx.de>
To: Guenter Roeck <linux@roeck-us.net>, linux-hwmon@vger.kernel.org
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
	"René Rebe" <rene@exactcode.de>,
	"Thomas Weißschuh" <linux@weissschuh.net>,
	"Stephen Horvath" <s.horvath@outlook.com.au>,
	"Paul Menzel" <pmenzel@molgen.mpg.de>,
	"Sasha Kozachuk" <skozachuk@google.com>,
	"John Hamrick" <johnham@google.com>
Subject: Re: [RFT PATCH] hwmon: (spd5118) Add support for Renesas/ITD SPD5118 hub controllers
Date: Mon, 17 Jun 2024 00:50:41 +0200	[thread overview]
Message-ID: <da7c9855-ff4b-4e80-99b8-b2fe24a9a9d9@gmx.de> (raw)
In-Reply-To: <d2ba6ed1-3a6a-4481-9f43-265eee78c0c1@roeck-us.net>

Am 16.06.24 um 22:26 schrieb Guenter Roeck:

> Hi Armin,
>
> On 6/16/24 11:09, Armin Wolf wrote:
>> Am 14.06.24 um 20:59 schrieb Guenter Roeck:
>>
>>> The SPD5118 specification says, in its documentation of the page bits
>>> in the MR11 register:
>>>
>>> "
>>> This register only applies to non-volatile memory (1024) Bytes)
>>> access of
>>> SPD5 Hub device.
>>> For volatile memory access, this register must be programmed to '000'.
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> "
>>>
>>> Renesas/ITD SPD5118 hub controllers take this literally and disable
>>> access
>>> to volatile memory if the page selected in MR11 is != 0. Since the
>>> BIOS or
>>> ROMMON will access the non-volatile memory and likely select a page
>>> != 0,
>>> this means that the driver will not instantiate since it can not
>>> identify
>>> the chip. Even if the driver instantiates, access to volatile registers
>>> is blocked after a nvram read operation which selects a page other
>>> than 0.
>>>
>>> To solve the problem, add initialization code to select page 0 during
>>> probe. Before doing that, use basic validation to ensure that this is
>>> really a SPD5118 device and not some random EEPROM. Explicitly select
>>> page 0 when accessing the volatile register space, and protect volatile
>>> register access against nvmem access using the device mutex.
>>
>> Hi,
>>
>> maybe we can use struct regmap_range_cfg so the paged register
>> accesses are being
>> done by the regmap code itself?
>>
>
> In theory that might work, but regmap does not permit a selector
> register to
> be part of another range. The first range would be the non-volatile
> registers,
> and the selector register is part of that for all ranges.
>
> I tried the following ranges configuration.
>
> static const struct regmap_range_cfg spd5118_regmap_range_cfg[] = {
>         {
>         .selector_reg     = SPD5118_REG_I2C_LEGACY_MODE,
>         .selector_mask    = SPD5118_LEGACY_PAGE_MASK,
>         .selector_shift   = 0,
>         .window_start     = 0,
>         .window_len       = SPD5118_PAGE_SIZE,
>         .range_min        = 0,
>         .range_max        = SPD5118_PAGE_SIZE - 1,
>         },
>         {
>         .selector_reg     = SPD5118_REG_I2C_LEGACY_MODE,
>         .selector_mask    = SPD5118_LEGACY_PAGE_MASK,
>         .selector_shift   = 0,
>         .window_start     = SPD5118_PAGE_SIZE,
>         .window_len       = SPD5118_PAGE_SIZE,
>         .range_min        = SPD5118_PAGE_SIZE,
>         .range_max        = 9 * SPD5118_PAGE_SIZE - 1,
>         },
> };
>
> This results in
>
> spd5118 0-0050: Range 0: selector for 1 in window
> spd5118 0-0050: error -EINVAL: regmap init failed
>
> If you have an idea how to configure the ranges differently,
> please let me know.
>
> Thanks,
> Guenter
>
Oh, i did not think of this. In this case we indeed cannot use regmap here. I will test the patch tomorrow.

Thanks,
Armin Wolf


  reply	other threads:[~2024-06-16 22:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-14 18:59 [RFT PATCH] hwmon: (spd5118) Add support for Renesas/ITD SPD5118 hub controllers Guenter Roeck
2024-06-16 18:09 ` Armin Wolf
2024-06-16 20:26   ` Guenter Roeck
2024-06-16 22:50     ` Armin Wolf [this message]
2024-06-17 14:58       ` Guenter Roeck

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=da7c9855-ff4b-4e80-99b8-b2fe24a9a9d9@gmx.de \
    --to=w_armin@gmx.de \
    --cc=devicetree@vger.kernel.org \
    --cc=johnham@google.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=linux@weissschuh.net \
    --cc=pmenzel@molgen.mpg.de \
    --cc=rene@exactcode.de \
    --cc=s.horvath@outlook.com.au \
    --cc=skozachuk@google.com \
    --cc=wsa+renesas@sang-engineering.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox