Get number of MC channels which are actually enabled
in current boot configuration.
Signed-off-by: Sumit Gupta <[email protected]>
---
drivers/memory/tegra/mc.c | 19 +++++++++++++++++++
drivers/memory/tegra/mc.h | 1 +
include/soc/tegra/mc.h | 1 +
3 files changed, 21 insertions(+)
diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index 4ddf9808fe6b..3d52eb3e24e4 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -881,6 +881,23 @@ static int tegra_mc_interconnect_setup(struct tegra_mc *mc)
return err;
}
+static void tegra_mc_num_channel_enabled(struct tegra_mc *mc)
+{
+ unsigned int i;
+ u32 value = 0;
+
+ value = mc_ch_readl(mc, 0, MC_EMEM_ADR_CFG_CHANNEL_ENABLE);
+ if (value <= 0) {
+ mc->num_channels = mc->soc->num_channels;
+ return;
+ }
+
+ for (i = 0; i < 32; i++) {
+ if (value & BIT(i))
+ mc->num_channels++;
+ }
+}
+
static int tegra_mc_probe(struct platform_device *pdev)
{
struct tegra_mc *mc;
@@ -919,6 +936,8 @@ static int tegra_mc_probe(struct platform_device *pdev)
return err;
}
+ tegra_mc_num_channel_enabled(mc);
+
if (mc->soc->ops && mc->soc->ops->handle_irq) {
mc->irq = platform_get_irq(pdev, 0);
if (mc->irq < 0)
diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
index bc01586b6560..c3f6655bec60 100644
--- a/drivers/memory/tegra/mc.h
+++ b/drivers/memory/tegra/mc.h
@@ -53,6 +53,7 @@
#define MC_ERR_ROUTE_SANITY_ADR 0x9c4
#define MC_ERR_GENERALIZED_CARVEOUT_STATUS 0xc00
#define MC_ERR_GENERALIZED_CARVEOUT_ADR 0xc04
+#define MC_EMEM_ADR_CFG_CHANNEL_ENABLE 0xdf8
#define MC_GLOBAL_INTSTATUS 0xf24
#define MC_ERR_ADR_HI 0x11fc
diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
index 6a94e88b6100..815c7d5f6292 100644
--- a/include/soc/tegra/mc.h
+++ b/include/soc/tegra/mc.h
@@ -236,6 +236,7 @@ struct tegra_mc {
struct tegra_mc_timing *timings;
unsigned int num_timings;
+ unsigned int num_channels;
struct reset_controller_dev reset;
--
2.17.1
On 20/12/2022 17:02, Sumit Gupta wrote:
> Get number of MC channels which are actually enabled
> in current boot configuration.
Why? You don't do anything with it. Commit msg should give the reason of
changes.
Best regards,
Krzysztof
On 22/12/22 17:07, Krzysztof Kozlowski wrote:
> External email: Use caution opening links or attachments
>
>
> On 20/12/2022 17:02, Sumit Gupta wrote:
>> Get number of MC channels which are actually enabled
>> in current boot configuration.
>
> Why? You don't do anything with it. Commit msg should give the reason of
> changes.
>
>
> Best regards,
> Krzysztof
>
CPU OPP tables have per channel bandwidth info. The "mc->num_channels"
is used in [1] (Patch v1 10/10) to make the per MC channel bandwidth
requested by the CPU cluster as a multiple of number of the enabled mc
channels.
Will update the commit description with this info.
[1]
https://lore.kernel.org/lkml/[email protected]/T/#m3ac150a86977e89b97c5d19c60384f29d7a01d21
On Fri, Jan 13, 2023 at 08:34:18PM +0530, Sumit Gupta wrote:
>
>
> On 22/12/22 17:07, Krzysztof Kozlowski wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On 20/12/2022 17:02, Sumit Gupta wrote:
> > > Get number of MC channels which are actually enabled
> > > in current boot configuration.
> >
> > Why? You don't do anything with it. Commit msg should give the reason of
> > changes.
> >
> >
> > Best regards,
> > Krzysztof
> >
>
> CPU OPP tables have per channel bandwidth info. The "mc->num_channels" is
> used in [1] (Patch v1 10/10) to make the per MC channel bandwidth requested
> by the CPU cluster as a multiple of number of the enabled mc channels.
>
> Will update the commit description with this info.
>
> [1] https://lore.kernel.org/lkml/[email protected]/T/#m3ac150a86977e89b97c5d19c60384f29d7a01d21
Both patch 9 and 10 are reasonably small, so it would be okay to merge
the two patches and avoid any need for an extra explanation.
Thierry