[2/5] nvmem: sunxi-sid: add support for H5's SID controller
diff mbox series

Message ID 20190217162316.14111-3-tiny.windzz@gmail.com
State New
Headers show
Series
  • nvmem: sunxi-sid: add SID controller support for H5 and H6
Related show

Commit Message

Frank Lee Feb. 17, 2019, 4:23 p.m. UTC
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(+)

Comments

Maxime Ripard Feb. 18, 2019, 8:49 a.m. UTC | #1
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.

Have you checked the SID content?

Maxime
Chen-Yu Tsai Feb. 18, 2019, 9:19 a.m. UTC | #2
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.

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?

> Have you checked the SID content?

On the A64 and H5, directly dumping the SID registers (not using the H3
read method) shows the contents are little or native endian.

ChenYu
Maxime Ripard Feb. 19, 2019, 3:03 p.m. UTC | #3
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
Chen-Yu Tsai Feb. 19, 2019, 3:07 p.m. UTC | #4
On Tue, Feb 19, 2019 at 11:03 PM Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
>
> 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?

I can't tell. There doesn't seem to be a toggle for endianess though.

> > 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?

That works. And please see my other mail about the DT nvmem cell arrangement.

ChenYu
Frank Lee Feb. 20, 2019, 2:05 p.m. UTC | #5
HI Maxime and ChenYu,

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.
>
> Have you checked the SID content?
It seems that data by hexdump /sys/bus/nvmem/devices/sunxi_sid/nvmem or
by md command in uboot , the data is different in some soc.

Sorry, I replied a bit late.
Any suggestions to solve it?

Yangtao
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Patch
diff mbox series

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,
+};
+
 static const struct of_device_id sunxi_sid_of_match[] = {
 	{ .compatible = "allwinner,sun4i-a10-sid", .data = &sun4i_a10_cfg },
 	{ .compatible = "allwinner,sun7i-a20-sid", .data = &sun7i_a20_cfg },
 	{ .compatible = "allwinner,sun8i-h3-sid", .data = &sun8i_h3_cfg },
 	{ .compatible = "allwinner,sun50i-a64-sid", .data = &sun50i_a64_cfg },
+	{ .compatible = "allwinner,sun50i-h5-sid", .data = &sun50i_h5_cfg },
 	{/* sentinel */},
 };
 MODULE_DEVICE_TABLE(of, sunxi_sid_of_match);