Date: Fri, 18 Dec 2015 17:58:13 +0000
From: Mark Brown <broonie@kernel.org>
To: chenfeng <puck.chen@hisilicon.com>
Cc: lee.jones@linaro.org, linux-kernel@vger.kernel.org, lgirdwood@gmail.com,
        robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
        ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
        xuwei5@hisilicon.com, puck.chen@aliyun.com, yudongbin@hisilicon.com,
        saberlily.xia@hisilicon.com, suzhuangluan@hisilicon.com,
        kong.kongxinwei@hisilicon.com, xuyiping@hisilicon.com,
        z.liuxinliang@hisilicon.com, weidong2@hisilicon.com, w.f@huawei.com,
        qijiwen@hisilicon.com, peter.panshilin@hisilicon.com,
        dan.zhao@hisilicon.com, linuxarm@huawei.com
Message-ID: <20151218175813.GE5727@sirena.org.uk>
References: <1450184056-79851-1-git-send-email-puck.chen@hisilicon.com>
 <1450184056-79851-6-git-send-email-puck.chen@hisilicon.com>
 <56722B9F.8090301@hisilicon.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="InMamxIZU0LonZYu"
Content-Disposition: inline
In-Reply-To: <56722B9F.8090301@hisilicon.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Subject: Re: [PATCH v3 5/5] hisilicon/dts: Add hi655x pmic dts node
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3010
Lines: 68


--InMamxIZU0LonZYu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Dec 17, 2015 at 11:27:27AM +0800, chenfeng wrote:

>  +- regulator-vset-regs: Voltage set register offset.
>  +- regulator-vset-mask: voltage set control mask.
>  +- regulator-n-vol: The num of support voltages.
>  +- regulator-vset-table: The table of support voltages.

> > Why is this in the binding?  This is a binding for a specific device,
> > there is no point in putting all these data tables in the DT - it just
> > bloats the DT and makes it harder for us to enhance our support for this
> > device in the future.

> You mentioned in previous version,I I have some questions for it.

> This regulator-vset-regs etc are vendor specific describe. The hi655x PMIC

There's nothing vendor specific about the way this is written...

> is a series of chips. They all have this value, but the offset may be different.
> And we can generate the dts file from excel which is defined by SOC.

> I think the dts is designed to distinguish different platform. If we hard code this
> in files, it may be also different to use as common in next chip version.

If your tooling can generate DT files it can generate C code just as
well and it seems unlikely you're going to be able to build new boards
without being able to do firmware updates here.  Especially for the
sorts of systems that use DT the set of scenarios where you're able to
update the DT but not the kernel seems like it will be extremely
limited.  I don't really buy the argument that there's any practical
difference in the ability to update the kernel and DT and to the extent
there is one it seems better to keep the ABI we have to support smaller
by having the DT be minimal.

This also allows us to map things more efficiently than we can with just
a table of voltages.  For example a good selection of the regulators in
your example DT appear to be linear ranges and so should be mapped as
such so we can do direct calcuations rather than having to iterate
through a table to map voltages into selectors.  That gets especially
serious for higher resolution regulators like most DCDCs (and modern
LDOs for that matter).

--InMamxIZU0LonZYu
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWdEk0AAoJECTWi3JdVIfQJx0H/13YPFkjRpPP2O6kU1Sebnmw
y5pjhmqaweKE3x7DwiCCrONVnkT9zcGxyuX0uSFM/SDK9ESEu1+HO3pdpTgj8/Yz
9br9mXCD+buSLvdgJh5+bCHmtWIq8rCiIzV4QbbZmezkfrgtdCJqevUF25mr9oHC
I0bN9ZGmXtg+C0rzpPnkIj3XZetLYBgOWJx1bq1cEt20lzigUe2+uvpSFLOKQWTi
ZzZoHwp5n9repwg0rP+wN/UEFlkUxPZYLaZTQH6vFmqU/dr1wHFb97/HtU8hPakL
pDgk1dh6gTw8gTOls3IuVO34NxaZuKPDZwe9qjcd4mf96z1vv+Lnflm0P7PgmS4=
=sxYH
-----END PGP SIGNATURE-----

--InMamxIZU0LonZYu--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/