Hi Nishanth,
On 29/11/2021 06:36, Nishanth Menon wrote:
> 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.
>
Did I understand correctly that we can use a different compatible for older SoC
in the overlay? e.g. ti,am642-es1.0 ?
If so then I can get rid of soc_device_match and use compatibles matching only in this patch.
>
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
>
cheers,
-roger
