From: Maxime Ripard <maxime.ripard@bootlin.com>
To: Chen-Yu Tsai <wens@csie.org>
Cc: Yangtao Li <tiny.windzz@gmail.com>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
devicetree <devicetree@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/5] nvmem: sunxi-sid: add support for H5's SID controller
Date: Tue, 19 Feb 2019 16:03:11 +0100 [thread overview]
Message-ID: <20190219150311.yfqkr5svs6b3arjy@flea> (raw)
In-Reply-To: <CAGb2v65Frw+=DjcuqNUPd-UG6qsiVDBH0bd5btx+5=ns7VAQrQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2245 bytes --]
Hi,
On Mon, Feb 18, 2019 at 05:19:40PM +0800, Chen-Yu Tsai wrote:
> On Mon, Feb 18, 2019 at 4:49 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Sun, Feb 17, 2019 at 11:23:13AM -0500, Yangtao Li wrote:
> > > Add support for H5's SID controller.
> > >
> > > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > > ---
> > > drivers/nvmem/sunxi_sid.c | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
> > > index 570a2e354f30..036029e90921 100644
> > > --- a/drivers/nvmem/sunxi_sid.c
> > > +++ b/drivers/nvmem/sunxi_sid.c
> > > @@ -219,11 +219,17 @@ static const struct sunxi_sid_cfg sun50i_a64_cfg = {
> > > .size = 0x100,
> > > };
> > >
> > > +static const struct sunxi_sid_cfg sun50i_h5_cfg = {
> > > + .value_offset = 0x200,
> > > + .size = 0x100,
> > > +};
> >
> > IIRC, there was an endianness issue on the newer SoCs, with the driver
> > converting the data from big endian to little endian, while it's
> > actually stored little endian in the SID.
>
> About that, it seems the internals are either little endian or native (same
> as the bus). Either way the nvmem the driver currently exposes is wrong.
Do you mean that it can be configured either way, or it's little
endian and since you are running a little endian system you can't
tell?
> My idea is to keep the current one with the current name, but have it not
> associate itself with the DT node. We then register an extra one, called
> "sunxi-sid-native" which uses the native endian. This one will be associated
> with the DT node, so the THS driver can consume nvmem cells.
>
> What do you think?
I thought about this some more, and I don't think anyone really has
used the sysfs interface for it. Since the data are in an unusable
order (without an additional conversion at least), we would have had a
bug report by now (just like we had when someone tried to use it for
the thermal calibration).
So maybe the easy way out is just to disable the conversion on the
affected SoCs, and see if anyone complains?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2019-02-19 15:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-17 16:23 [PATCH 0/5] nvmem: sunxi-sid: add SID controller support for H5 and H6 Yangtao Li
2019-02-17 16:23 ` [PATCH 1/5] nvmem: sunxi-sid: fix wrong description in kernel doc Yangtao Li
2019-02-18 8:48 ` Maxime Ripard
2019-02-28 19:03 ` Rob Herring
2019-02-17 16:23 ` [PATCH 2/5] nvmem: sunxi-sid: add support for H5's SID controller Yangtao Li
2019-02-18 8:49 ` Maxime Ripard
2019-02-18 9:19 ` Chen-Yu Tsai
2019-02-19 15:03 ` Maxime Ripard [this message]
2019-02-19 15:07 ` Chen-Yu Tsai
2019-02-20 14:05 ` Frank Lee
2019-02-17 16:23 ` [PATCH 3/5] nvmem: sunxi-sid: add binding for H6's " Yangtao Li
2019-02-18 8:50 ` Maxime Ripard
2019-02-28 19:03 ` Rob Herring
2019-02-17 16:23 ` [PATCH 4/5] nvmem: sunxi-sid: add support " Yangtao Li
2019-02-17 16:23 ` [PATCH 5/5] nvmem: sunxi-sid: convert to SPDX license tags Yangtao Li
2019-02-18 8:50 ` Maxime Ripard
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=20190219150311.yfqkr5svs6b3arjy@flea \
--to=maxime.ripard@bootlin.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=tiny.windzz@gmail.com \
--cc=wens@csie.org \
/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