From: Thierry Reding <thierry.reding@gmail.com>
To: Kejia Hu <kejia.hu@codethink.co.uk>
Cc: devicetree@vger.kernel.org, Ben Dooks <ben.dooks@codethink.co.uk>,
Thomas Preston <thomas.preston@codethink.co.uk>,
linux-tegra@vger.kernel.org, digetx@gmail.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/6] soc/tegra: initial tegra-automotive detection
Date: Mon, 4 Mar 2019 14:19:56 +0100 [thread overview]
Message-ID: <20190304131956.GJ9040@ulmo> (raw)
In-Reply-To: <20190301153540.14954-2-kejia.hu@codethink.co.uk>
[-- Attachment #1.1: Type: text/plain, Size: 2338 bytes --]
On Fri, Mar 01, 2019 at 03:35:35PM +0000, Kejia Hu wrote:
> From: Ben Dooks <ben.dooks@codethink.co.uk>
>
> Add an initial soc_is_tegra_auto() with detection
> via a change in the device-tree.
>
> Also print the path taken through soc_is_tegra_auto() to
> allow debugging. Only print when debug is enabled as this
> function may be be called from multiple places, resulting
> in duplicated messages in production.
>
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> Signed-off-by: Thomas Preston <thomas.preston@codethink.co.uk>
> Signed-off-by: Kejia Hu <kejia.hu@codethink.co.uk>
> ---
> drivers/soc/tegra/common.c | 23 +++++++++++++++++++++++
> drivers/soc/tegra/fuse/tegra-apbmisc.c | 2 ++
> include/soc/tegra/common.h | 1 +
> include/soc/tegra/fuse.h | 1 +
> 4 files changed, 27 insertions(+)
>
> diff --git a/drivers/soc/tegra/common.c b/drivers/soc/tegra/common.c
> index 7bfb154d6fa5..a10bd26fb5df 100644
> --- a/drivers/soc/tegra/common.c
> +++ b/drivers/soc/tegra/common.c
> @@ -9,6 +9,7 @@
> #include <linux/of.h>
>
> #include <soc/tegra/common.h>
> +#include <soc/tegra/fuse.h>
>
> static const struct of_device_id tegra_machine_match[] = {
> { .compatible = "nvidia,tegra20", },
> @@ -34,3 +35,25 @@ bool soc_is_tegra(void)
>
> return match != NULL;
> }
> +
> +static const struct of_device_id tegra_machine_match_auto[] = {
> + { .compatible = "nvidia,tegra20auto", },
> + { .compatible = "nvidia,tegra30auto", },
> + { },
> +};
> +
> +bool soc_is_tegra_auto(void)
> +{
> + struct device_node *root;
> + bool id_match = false;
> +
> + root = of_find_node_by_path("/");
> +
> + if (root && of_match_node(tegra_machine_match_auto, root))
> + id_match = true;
> +
> + pr_debug("%s of_device_id match %d, tegra_sku_info.is_automotive %d\n",
> + __func__, id_match, tegra_sku_info.is_automotive);
> +
> + return id_match || tegra_sku_info.is_automotive;
> +}
Why do we need two ways of specifying the same thing? If we can read
this information from fuses, I don't think we need the extra compatible
string matching.
Also, if you're going to use this exclusively for clock setup, then the
alternative is to do that as part of the board's device tree, as Dmitry
pointed out.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-03-04 13:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-01 15:35 [PATCH v2] tegra2/tegra3 automotive clock init Kejia Hu
2019-03-01 15:35 ` [PATCH v2 1/6] soc/tegra: initial tegra-automotive detection Kejia Hu
2019-03-04 13:19 ` Thierry Reding [this message]
2019-03-01 15:35 ` [PATCH v2 2/6] soc/tegra: fuse: add is_automotive for tegra30 Kejia Hu
2019-03-01 15:35 ` [PATCH v2 3/6] soc/tegra: fuse: Add is_automotive for tegra20 Kejia Hu
2019-03-01 15:35 ` [PATCH v2 4/6] kconfig: build device tree overlay into tegra20/30 Kejia Hu
2019-03-01 15:35 ` [PATCH v2 5/6] clk: tegra20: add automotive specific clocks as dt overlay Kejia Hu
2019-03-01 15:35 ` [PATCH v2 6/6] clk: tegra30: " Kejia Hu
2019-03-03 14:14 ` [PATCH v2] tegra2/tegra3 automotive clock init Dmitry Osipenko
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=20190304131956.GJ9040@ulmo \
--to=thierry.reding@gmail.com \
--cc=ben.dooks@codethink.co.uk \
--cc=devicetree@vger.kernel.org \
--cc=digetx@gmail.com \
--cc=kejia.hu@codethink.co.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-tegra@vger.kernel.org \
--cc=thomas.preston@codethink.co.uk \
/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;
as well as URLs for NNTP newsgroup(s).