From: Thierry Reding <[email protected]>
With the introduction of commit 9365bf006f53 ("PCI: tegra194: Add
interconnect support in Tegra234"), the PCI driver on Tegra194 and later
requires an interconnect provider. However, a provider is currently only
exposed on Tegra234 and this causes PCI on Tegra194 to defer probe
indefinitely.
Fix this by adding a dummy implementation on Tegra194. This allows nodes
to be provided to interconnect consumers, but doesn't do any bandwidth
accounting or frequency scaling.
Fixes: 9365bf006f53 ("PCI: tegra194: Add interconnect support in Tegra234")
Reported-by: Jon Hunter <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
---
drivers/memory/tegra/mc.c | 37 +++++++++++++++++++++++++++++++++
drivers/memory/tegra/tegra194.c | 1 +
drivers/memory/tegra/tegra234.c | 23 +-------------------
include/soc/tegra/mc.h | 3 +++
4 files changed, 42 insertions(+), 22 deletions(-)
diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index 4a750da1c12a..deb6e65b59af 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -755,6 +755,43 @@ const char *const tegra_mc_error_names[8] = {
[6] = "SMMU translation error",
};
+struct icc_node *tegra_mc_icc_xlate(struct of_phandle_args *spec, void *data)
+{
+ struct tegra_mc *mc = icc_provider_to_tegra_mc(data);
+ struct icc_node *node;
+
+ list_for_each_entry(node, &mc->provider.nodes, node_list) {
+ if (node->id == spec->args[0])
+ return node;
+ }
+
+ /*
+ * If a client driver calls devm_of_icc_get() before the MC driver
+ * is probed, then return EPROBE_DEFER to the client driver.
+ */
+ return ERR_PTR(-EPROBE_DEFER);
+}
+
+static int tegra_mc_icc_get(struct icc_node *node, u32 *average, u32 *peak)
+{
+ *average = 0;
+ *peak = 0;
+
+ return 0;
+}
+
+static int tegra_mc_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+ return 0;
+}
+
+const struct tegra_mc_icc_ops tegra_mc_icc_ops = {
+ .xlate = tegra_mc_icc_xlate,
+ .aggregate = icc_std_aggregate,
+ .get_bw = tegra_mc_icc_get,
+ .set = tegra_mc_icc_set,
+};
+
/*
* Memory Controller (MC) has few Memory Clients that are issuing memory
* bandwidth allocation requests to the MC interconnect provider. The MC
diff --git a/drivers/memory/tegra/tegra194.c b/drivers/memory/tegra/tegra194.c
index b2416ee3ac26..26035ac3a1eb 100644
--- a/drivers/memory/tegra/tegra194.c
+++ b/drivers/memory/tegra/tegra194.c
@@ -1355,6 +1355,7 @@ const struct tegra_mc_soc tegra194_mc_soc = {
MC_INT_SECURITY_VIOLATION | MC_INT_DECERR_EMEM,
.has_addr_hi_reg = true,
.ops = &tegra186_mc_ops,
+ .icc_ops = &tegra_mc_icc_ops,
.ch_intmask = 0x00000f00,
.global_intstatus_channel_shift = 8,
};
diff --git a/drivers/memory/tegra/tegra234.c b/drivers/memory/tegra/tegra234.c
index 78daa61ccd46..2fe8a61928e6 100644
--- a/drivers/memory/tegra/tegra234.c
+++ b/drivers/memory/tegra/tegra234.c
@@ -909,27 +909,6 @@ static int tegra234_mc_icc_aggregate(struct icc_node *node, u32 tag, u32 avg_bw,
return 0;
}
-static struct icc_node*
-tegra234_mc_of_icc_xlate(struct of_phandle_args *spec, void *data)
-{
- struct tegra_mc *mc = icc_provider_to_tegra_mc(data);
- unsigned int cl_id = spec->args[0];
- struct icc_node *node;
-
- list_for_each_entry(node, &mc->provider.nodes, node_list) {
- if (node->id != cl_id)
- continue;
-
- return node;
- }
-
- /*
- * If a client driver calls devm_of_icc_get() before the MC driver
- * is probed, then return EPROBE_DEFER to the client driver.
- */
- return ERR_PTR(-EPROBE_DEFER);
-}
-
static int tegra234_mc_icc_get_init_bw(struct icc_node *node, u32 *avg, u32 *peak)
{
*avg = 0;
@@ -939,7 +918,7 @@ static int tegra234_mc_icc_get_init_bw(struct icc_node *node, u32 *avg, u32 *pea
}
static const struct tegra_mc_icc_ops tegra234_mc_icc_ops = {
- .xlate = tegra234_mc_of_icc_xlate,
+ .xlate = tegra_mc_icc_xlate,
.aggregate = tegra234_mc_icc_aggregate,
.get_bw = tegra234_mc_icc_get_init_bw,
.set = tegra234_mc_icc_set,
diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
index fc3001483e62..a5ef84944a06 100644
--- a/include/soc/tegra/mc.h
+++ b/include/soc/tegra/mc.h
@@ -175,6 +175,9 @@ struct tegra_mc_icc_ops {
int (*get_bw)(struct icc_node *node, u32 *avg, u32 *peak);
};
+struct icc_node *tegra_mc_icc_xlate(struct of_phandle_args *spec, void *data);
+extern const struct tegra_mc_icc_ops tegra_mc_icc_ops;
+
struct tegra_mc_ops {
/*
* @probe: Callback to set up SoC-specific bits of the memory controller. This is called
--
2.41.0
On 29/06/23 21:31, Thierry Reding wrote:
> External email: Use caution opening links or attachments
>
>
> From: Thierry Reding <[email protected]>
>
> With the introduction of commit 9365bf006f53 ("PCI: tegra194: Add
> interconnect support in Tegra234"), the PCI driver on Tegra194 and later
> requires an interconnect provider. However, a provider is currently only
> exposed on Tegra234 and this causes PCI on Tegra194 to defer probe
> indefinitely.
>
> Fix this by adding a dummy implementation on Tegra194. This allows nodes
> to be provided to interconnect consumers, but doesn't do any bandwidth
> accounting or frequency scaling.
>
> Fixes: 9365bf006f53 ("PCI: tegra194: Add interconnect support in Tegra234")
> Reported-by: Jon Hunter <[email protected]>
> Signed-off-by: Thierry Reding <[email protected]>
> ---
Reviewed-by: Sumit Gupta <[email protected]>
Tested-by: Sumit Gupta <[email protected]>
Thank you,
Sumit Gupta
On Thu, 29 Jun 2023 18:01:32 +0200, Thierry Reding wrote:
> With the introduction of commit 9365bf006f53 ("PCI: tegra194: Add
> interconnect support in Tegra234"), the PCI driver on Tegra194 and later
> requires an interconnect provider. However, a provider is currently only
> exposed on Tegra234 and this causes PCI on Tegra194 to defer probe
> indefinitely.
>
> Fix this by adding a dummy implementation on Tegra194. This allows nodes
> to be provided to interconnect consumers, but doesn't do any bandwidth
> accounting or frequency scaling.
>
> [...]
Applied, thanks!
[1/1] memory: tegra: Add dummy implementation on Tegra194
https://git.kernel.org/krzk/linux-mem-ctrl/c/d1478aea649e739a0a0e4890cd8b049ae5d08c13
Best regards,
--
Krzysztof Kozlowski <[email protected]>
On 29/06/2023 18:01, Thierry Reding wrote:
> From: Thierry Reding <[email protected]>
>
> With the introduction of commit 9365bf006f53 ("PCI: tegra194: Add
> interconnect support in Tegra234"), the PCI driver on Tegra194 and later
> requires an interconnect provider. However, a provider is currently only
> exposed on Tegra234 and this causes PCI on Tegra194 to defer probe
> indefinitely.
>
> Fix this by adding a dummy implementation on Tegra194. This allows nodes
> to be provided to interconnect consumers, but doesn't do any bandwidth
> accounting or frequency scaling.
>
> Fixes: 9365bf006f53 ("PCI: tegra194: Add interconnect support in Tegra234")
> Reported-by: Jon Hunter <[email protected]>
Applied with checkpatch warning. Please be sure you run checkpatch
before sending the patches.
Best regards,
Krzysztof
On Mon, Jul 10, 2023 at 12:10:43PM +0200, Krzysztof Kozlowski wrote:
> On 29/06/2023 18:01, Thierry Reding wrote:
> > From: Thierry Reding <[email protected]>
> >
> > With the introduction of commit 9365bf006f53 ("PCI: tegra194: Add
> > interconnect support in Tegra234"), the PCI driver on Tegra194 and later
> > requires an interconnect provider. However, a provider is currently only
> > exposed on Tegra234 and this causes PCI on Tegra194 to defer probe
> > indefinitely.
> >
> > Fix this by adding a dummy implementation on Tegra194. This allows nodes
> > to be provided to interconnect consumers, but doesn't do any bandwidth
> > accounting or frequency scaling.
> >
> > Fixes: 9365bf006f53 ("PCI: tegra194: Add interconnect support in Tegra234")
> > Reported-by: Jon Hunter <[email protected]>
>
> Applied with checkpatch warning. Please be sure you run checkpatch
> before sending the patches.
Are you referring to the Reported-by/Closes complaint? I didn't include
a URL here because this came from an internal test report and there's no
corresponding public reference.
I suppose I could've left out the Reported-by altogether.
Thierry
On 10/07/2023 15:06, Thierry Reding wrote:
> On Mon, Jul 10, 2023 at 12:10:43PM +0200, Krzysztof Kozlowski wrote:
>> On 29/06/2023 18:01, Thierry Reding wrote:
>>> From: Thierry Reding <[email protected]>
>>>
>>> With the introduction of commit 9365bf006f53 ("PCI: tegra194: Add
>>> interconnect support in Tegra234"), the PCI driver on Tegra194 and later
>>> requires an interconnect provider. However, a provider is currently only
>>> exposed on Tegra234 and this causes PCI on Tegra194 to defer probe
>>> indefinitely.
>>>
>>> Fix this by adding a dummy implementation on Tegra194. This allows nodes
>>> to be provided to interconnect consumers, but doesn't do any bandwidth
>>> accounting or frequency scaling.
>>>
>>> Fixes: 9365bf006f53 ("PCI: tegra194: Add interconnect support in Tegra234")
>>> Reported-by: Jon Hunter <[email protected]>
>>
>> Applied with checkpatch warning. Please be sure you run checkpatch
>> before sending the patches.
>
> Are you referring to the Reported-by/Closes complaint?
Yes.
> I didn't include
> a URL here because this came from an internal test report and there's no
> corresponding public reference.
Ah, ok, apologies for pickiness then. :)
>
> I suppose I could've left out the Reported-by altogether.
I think it is fine. Checkpatch warning is just advisory.
Best regards,
Krzysztof
Hi Krzysztof,
On 10/07/2023 14:29, Krzysztof Kozlowski wrote:
> On 10/07/2023 15:06, Thierry Reding wrote:
>> On Mon, Jul 10, 2023 at 12:10:43PM +0200, Krzysztof Kozlowski wrote:
>>> On 29/06/2023 18:01, Thierry Reding wrote:
>>>> From: Thierry Reding <[email protected]>
>>>>
>>>> With the introduction of commit 9365bf006f53 ("PCI: tegra194: Add
>>>> interconnect support in Tegra234"), the PCI driver on Tegra194 and later
>>>> requires an interconnect provider. However, a provider is currently only
>>>> exposed on Tegra234 and this causes PCI on Tegra194 to defer probe
>>>> indefinitely.
>>>>
>>>> Fix this by adding a dummy implementation on Tegra194. This allows nodes
>>>> to be provided to interconnect consumers, but doesn't do any bandwidth
>>>> accounting or frequency scaling.
>>>>
>>>> Fixes: 9365bf006f53 ("PCI: tegra194: Add interconnect support in Tegra234")
>>>> Reported-by: Jon Hunter <[email protected]>
>>>
>>> Applied with checkpatch warning. Please be sure you run checkpatch
>>> before sending the patches.
>>
>> Are you referring to the Reported-by/Closes complaint?
>
> Yes.
>
>> I didn't include
>> a URL here because this came from an internal test report and there's no
>> corresponding public reference.
>
> Ah, ok, apologies for pickiness then. :)
>
>>
>> I suppose I could've left out the Reported-by altogether.
>
> I think it is fine. Checkpatch warning is just advisory.
We need this in v6.5 as a fix, because without this change PCIe support
is broken on Tegra194 devices. Would you be able to send as a fix for v6.5?
Thanks!
Jon
--
nvpublic
On 25/07/2023 12:14, Jon Hunter wrote:
> Hi Krzysztof,
>
> On 10/07/2023 14:29, Krzysztof Kozlowski wrote:
>> On 10/07/2023 15:06, Thierry Reding wrote:
>>> On Mon, Jul 10, 2023 at 12:10:43PM +0200, Krzysztof Kozlowski wrote:
>>>> On 29/06/2023 18:01, Thierry Reding wrote:
>>>>> From: Thierry Reding <[email protected]>
>>>>>
>>>>> With the introduction of commit 9365bf006f53 ("PCI: tegra194: Add
>>>>> interconnect support in Tegra234"), the PCI driver on Tegra194 and later
>>>>> requires an interconnect provider. However, a provider is currently only
>>>>> exposed on Tegra234 and this causes PCI on Tegra194 to defer probe
>>>>> indefinitely.
>>>>>
>>>>> Fix this by adding a dummy implementation on Tegra194. This allows nodes
>>>>> to be provided to interconnect consumers, but doesn't do any bandwidth
>>>>> accounting or frequency scaling.
>>>>>
>>>>> Fixes: 9365bf006f53 ("PCI: tegra194: Add interconnect support in Tegra234")
>>>>> Reported-by: Jon Hunter <[email protected]>
>>>>
>>>> Applied with checkpatch warning. Please be sure you run checkpatch
>>>> before sending the patches.
>>>
>>> Are you referring to the Reported-by/Closes complaint?
>>
>> Yes.
>>
>>> I didn't include
>>> a URL here because this came from an internal test report and there's no
>>> corresponding public reference.
>>
>> Ah, ok, apologies for pickiness then. :)
>>
>>>
>>> I suppose I could've left out the Reported-by altogether.
>>
>> I think it is fine. Checkpatch warning is just advisory.
>
>
> We need this in v6.5 as a fix, because without this change PCIe support
> is broken on Tegra194 devices. Would you be able to send as a fix for v6.5?
Thanks for letting me know. I'll send it soon.
Best regards,
Krzysztof