From: Nishanth Menon <nm@ti.com>
To: Roger Quadros <rogerq@kernel.org>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>, <richard@nod.at>,
<vigneshr@ti.com>, <kishon@ti.com>, <tony@atomide.com>,
<linux-mtd@lists.infradead.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH 4/4] mtd: nand: omap2: Add support for NAND Controller on AM64 SoC
Date: Sun, 28 Nov 2021 22:36:33 -0600 [thread overview]
Message-ID: <20211129043633.myxmgp6idbrqvx5p@unlisted> (raw)
In-Reply-To: <917ac002-9d4b-237d-94f3-bcd05f481f39@kernel.org>
On 13:10-20211126, Roger Quadros wrote:
[...]
> >>>> + /* Some SoC's have 32-bit at least, read limitation */
> >>>> + if (soc_device_match(k3_soc_devices)) {
> >>>> + dev_info(&pdev->dev, "force 32-bit\n");
> >>>> + info->force_32bit = true;
> >>>> + }
> >>>> +
> >>>
> >>> As suggested above, just adding a capability structure tied to the
> >>> compatible string and retrieved with of_device_get_match_data() should
> >>> be enough and replace this manual tree research.
> >>
> >> The trouble comes when TI updates the silicon revision to "SR2.0" and that has the issue fixed
> >> but still uses the same compatible. So compatible string by itself is not sufficient to identify
> >> the troubled devices. soc_device_match() was the easiest way to address this.
> >
> > This is precisely what compatibles are for, I believe we should declare
> > the necessary additional compatibles and fix the device trees that are
> > wrong.
>
> AFAIK TI SoCs don't have different compatibles for different revisions of the same SoC.
> My understanding is that the SoC is the same so compatible shouldn't change. Just that there were some
> hardware fixes and some quirks may not be needed anymore.
>
> Nishanth,
>
> Could you please chime in on why SoC revisions can't use different compatibles?
>
The permutations of boards (with add-on cards) and SRs become
un-manageable esp when Silicon Revisions(SRs) dont actually get into
production. Instead, what we do suggest are one of two things:
a) The dts in k.org always reflect the latest SR for the chip that is
going into production. Older SR revisions are supported as overlays on top
of the dtb.
b) Where possible, use the chip-id framework[1] to dynamically detect
the variations. This might be easier with newer K3 generation SoCs.
In this instance, an overlay corresponding to older SoC might be
feasible.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
next prev parent reply other threads:[~2021-11-29 4:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-23 10:36 [PATCH 0/4] mtd: nand: omap2: Switch to exec_ops, support AM64 SoC Roger Quadros
2021-11-23 10:36 ` [PATCH 1/4] dt-bindings: mtd: ti,gpmc-nand: Add compatible for AM64 NAND Roger Quadros
2021-11-30 22:02 ` Rob Herring
2021-11-23 10:36 ` [PATCH 2/4] mtd: nand: omap2: Allow build on K3 platforms Roger Quadros
2021-11-23 10:36 ` [PATCH 3/4] mtd: nand: omap2: move to exec_op interface Roger Quadros
2021-11-23 10:36 ` [PATCH 4/4] mtd: nand: omap2: Add support for NAND Controller on AM64 SoC Roger Quadros
2021-11-24 12:15 ` Miquel Raynal
2021-11-25 14:12 ` Roger Quadros
2021-11-26 9:42 ` Miquel Raynal
2021-11-26 11:10 ` Roger Quadros
2021-11-29 4:36 ` Nishanth Menon [this message]
2021-12-08 14:45 ` Roger Quadros
2021-12-08 16:35 ` Nishanth Menon
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=20211129043633.myxmgp6idbrqvx5p@unlisted \
--to=nm@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=kishon@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=rogerq@kernel.org \
--cc=tony@atomide.com \
--cc=vigneshr@ti.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