From: Andrew Davis <afd@ti.com>
To: Siddharth Vadapalli <s-vadapalli@ti.com>
Cc: <bhelgaas@google.com>, <lpieralisi@kernel.org>, <kw@linux.com>,
<robh@kernel.org>, <vigneshr@ti.com>, <linux-pci@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <srk@ti.com>
Subject: Re: [PATCH] PCI: j721e: Extend j721e_pcie_ctrl_init() for non syscon nodes
Date: Wed, 31 Jan 2024 10:10:26 -0600 [thread overview]
Message-ID: <0fd8aa96-6ccd-4d4b-86ea-fa3c52474eb9@ti.com> (raw)
In-Reply-To: <126d520e-bd00-467b-b5dc-3423cc405410@ti.com>
On 1/30/24 10:53 PM, Siddharth Vadapalli wrote:
>
>
> On 30/01/24 20:30, Andrew Davis wrote:
>> On 1/29/24 10:50 PM, Siddharth Vadapalli wrote:
>>> Hello Andrew,
>>>
>>> On 29/01/24 20:49, Andrew Davis wrote:
>>>> On 1/29/24 4:49 AM, Siddharth Vadapalli wrote:
>>>
>>> ...
>>>
>>>>> int ret;
>>>>> - syscon = syscon_regmap_lookup_by_phandle(node, "ti,syscon-pcie-ctrl");
>>>>> + scm_conf = of_parse_phandle(node, "ti,syscon-pcie-ctrl", 0);
>>>>> + if (!scm_conf) {
>>>>> + dev_err(dev, "unable to get System Controller node\n");
>>>>> + return -ENODEV;
>>>>> + }
>>>>> +
>>>>> + syscon = device_node_to_regmap(scm_conf);
>>>>
>>>> Turning the entire "simple-bus" region into a regmap using this
>>>> function is just as broken as having it as a "syscon". The core
>>>> problem we are solving by getting rid of the blanket syscon nodes
>>>> is that it causes multiple mappings of the same register. This
>>>> can cause issues with regmap caching, read–modify–write, etc..
>>>>
>>>> What you want to do is add a subnode to the simple-bus, have that
>>>> encapsulate just the registers used for PCIe, and have the PCIe
>>>> node point to that. Then this patch isn't needed.
>>>>
>>>> For an example, see how it's done for DSS[0].
>>>
>>> Thank you for reviewing the patch. I will implement it similar to what's done
>>> for DSS as you pointed out. However, what about the existing SoCs which make use
>>> of the "ti,syscon-pcie-ctrl" property? Do you suggest that I add another
>>> device-tree property for pointing to the PCIE_CTRL register within the CTRL_MMR
>>> region, or do you suggest that I reuse the existing "ti,syscon-pcie-ctrl"
>>> property differently in the SoCs like J784S4 where the scm_conf node is a
>>> "simple-bus"?
>>>
>>> The "ti,syscon-pcie-ctrl" property as defined in the device-tree bindings has
>>> two elements with the first being the phandle to the scm_conf node and the
>>> second being the offset of the PCIE_CTRL register. The newer implementation you
>>> are suggesting will either require a new property which accepts only one element
>>> namely the phandle to the node within scm_conf corresponding to the PCIE_CTRL
>>> register. Will adding a new property be acceptable?
>>>
>>
>> Why would you need a new property? If there is no offset to the PCIE_CTRL register
>> in the new syscon space then just set the offset = 0x0, easy.
>
> Seems like a Hack to me considering that the offset will always be zero for
> non-syscon parent nodes (which will be the convention going forward), implying
> that the offset might as well be dropped and just the phandle is sufficient. For
If we check the git history, this is actually how it used to be. The offset stuff
was added later[0]. Looks like for backwards compat it still works to not provide
an offset.
Andrew
[0] 7aa256234c4c ("PCI: j721e: Get offset within "syscon" from "ti,syscon-pcie-ctrl" phandle arg")
> now I shall implement it as you suggested. Maybe once the syscon nodes in
> existing SoCs are also converted to simple-bus, then the property can be
> redefined to just be the phandle to "pcie_ctrl" register.
>
>>
>> Andrew
>
prev parent reply other threads:[~2024-01-31 16:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 10:49 [PATCH] PCI: j721e: Extend j721e_pcie_ctrl_init() for non syscon nodes Siddharth Vadapalli
2024-01-29 15:19 ` Andrew Davis
2024-01-30 4:50 ` Siddharth Vadapalli
2024-01-30 15:00 ` Andrew Davis
2024-01-31 4:53 ` Siddharth Vadapalli
2024-01-31 16:10 ` Andrew Davis [this message]
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=0fd8aa96-6ccd-4d4b-86ea-fa3c52474eb9@ti.com \
--to=afd@ti.com \
--cc=bhelgaas@google.com \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=robh@kernel.org \
--cc=s-vadapalli@ti.com \
--cc=srk@ti.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