diff mbox series

[v3,1/8] memory: tegra: Add API for retrieving carveout bounds

Message ID 20220920081203.3237744-2-cyndis@kapsi.fi (mailing list archive)
State New, archived
Headers show
Series Support for NVDEC on Tegra234 | expand

Commit Message

Mikko Perttunen Sept. 20, 2022, 8:11 a.m. UTC
From: Mikko Perttunen <mperttunen@nvidia.com>

On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
has been loaded by a bootloader. When booting NVDEC, we need to tell it
the address of this firmware, which we can determine by checking the
starting address of the carveout. As such, add an MC API to query the
bounds of carveouts, and add related information on Tegra234.

Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
v2:
- Add check for 64-bit phys_addr_t. In practice phys_addr_t
  is always 64 bits where this runs, but it avoids warnings in
  compile test.
---
 drivers/memory/tegra/mc.c       | 25 +++++++++++++++++++++++++
 drivers/memory/tegra/tegra234.c |  5 +++++
 include/soc/tegra/mc.h          | 11 +++++++++++
 3 files changed, 41 insertions(+)

Comments

Krzysztof Kozlowski Sept. 21, 2022, 7:28 a.m. UTC | #1
On 20/09/2022 10:11, Mikko Perttunen wrote:
> From: Mikko Perttunen <mperttunen@nvidia.com>
> 
> On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
> has been loaded by a bootloader. When booting NVDEC, we need to tell it
> the address of this firmware, which we can determine by checking the
> starting address of the carveout. As such, add an MC API to query the
> bounds of carveouts, and add related information on Tegra234.
> 
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> v2:
> - Add check for 64-bit phys_addr_t. In practice phys_addr_t
>   is always 64 bits where this runs, but it avoids warnings in
>   compile test.
> ---
>  drivers/memory/tegra/mc.c       | 25 +++++++++++++++++++++++++
>  drivers/memory/tegra/tegra234.c |  5 +++++
>  include/soc/tegra/mc.h          | 11 +++++++++++

I still need here Thierry's ack.

Best regards,
Krzysztof
Krzysztof Kozlowski Sept. 21, 2022, 6:37 p.m. UTC | #2
On 20/09/2022 10:11, Mikko Perttunen wrote:
> From: Mikko Perttunen <mperttunen@nvidia.com>
> 
> On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
> has been loaded by a bootloader. When booting NVDEC, we need to tell it
> the address of this firmware, which we can determine by checking the
> starting address of the carveout. As such, add an MC API to query the
> bounds of carveouts, and add related information on Tegra234.
> 
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>


Best regards,
Krzysztof
Mikko Perttunen Sept. 21, 2022, 6:54 p.m. UTC | #3
On 9/21/22 21:37, Krzysztof Kozlowski wrote:
> On 20/09/2022 10:11, Mikko Perttunen wrote:
>> From: Mikko Perttunen <mperttunen@nvidia.com>
>>
>> On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
>> has been loaded by a bootloader. When booting NVDEC, we need to tell it
>> the address of this firmware, which we can determine by checking the
>> starting address of the carveout. As such, add an MC API to query the
>> bounds of carveouts, and add related information on Tegra234.
>>
>> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> 
> 
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> 
> Best regards,
> Krzysztof
> 

Thanks!

Mikko
Thierry Reding Oct. 24, 2022, 1:15 p.m. UTC | #4
On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko Perttunen wrote:
> From: Mikko Perttunen <mperttunen@nvidia.com>
> 
> On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
> has been loaded by a bootloader. When booting NVDEC, we need to tell it
> the address of this firmware, which we can determine by checking the
> starting address of the carveout. As such, add an MC API to query the
> bounds of carveouts, and add related information on Tegra234.
> 
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> v2:
> - Add check for 64-bit phys_addr_t. In practice phys_addr_t
>   is always 64 bits where this runs, but it avoids warnings in
>   compile test.
> ---
>  drivers/memory/tegra/mc.c       | 25 +++++++++++++++++++++++++
>  drivers/memory/tegra/tegra234.c |  5 +++++
>  include/soc/tegra/mc.h          | 11 +++++++++++
>  3 files changed, 41 insertions(+)

Krzysztof,

I've applied this to the same tree as the patch that uses it for now.
Let me know if you want me to put this on a separate stable branch for
you to pull in.

Thierry
Jon Hunter Nov. 4, 2022, 3:33 p.m. UTC | #5
Hi Thierry, Krzysztof,

On 24/10/2022 14:15, Thierry Reding wrote:
> On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko Perttunen wrote:
>> From: Mikko Perttunen <mperttunen@nvidia.com>
>>
>> On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
>> has been loaded by a bootloader. When booting NVDEC, we need to tell it
>> the address of this firmware, which we can determine by checking the
>> starting address of the carveout. As such, add an MC API to query the
>> bounds of carveouts, and add related information on Tegra234.
>>
>> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
>> ---
>> v2:
>> - Add check for 64-bit phys_addr_t. In practice phys_addr_t
>>    is always 64 bits where this runs, but it avoids warnings in
>>    compile test.
>> ---
>>   drivers/memory/tegra/mc.c       | 25 +++++++++++++++++++++++++
>>   drivers/memory/tegra/tegra234.c |  5 +++++
>>   include/soc/tegra/mc.h          | 11 +++++++++++
>>   3 files changed, 41 insertions(+)
> 
> Krzysztof,
> 
> I've applied this to the same tree as the patch that uses it for now.
> Let me know if you want me to put this on a separate stable branch for
> you to pull in.

Any update on this?

Thanks!
Jon
Krzysztof Kozlowski Nov. 4, 2022, 3:35 p.m. UTC | #6
On 04/11/2022 11:33, Jon Hunter wrote:
> Hi Thierry, Krzysztof,
> 
> On 24/10/2022 14:15, Thierry Reding wrote:
>> On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko Perttunen wrote:
>>> From: Mikko Perttunen <mperttunen@nvidia.com>
>>>
>>> On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
>>> has been loaded by a bootloader. When booting NVDEC, we need to tell it
>>> the address of this firmware, which we can determine by checking the
>>> starting address of the carveout. As such, add an MC API to query the
>>> bounds of carveouts, and add related information on Tegra234.
>>>
>>> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
>>> ---
>>> v2:
>>> - Add check for 64-bit phys_addr_t. In practice phys_addr_t
>>>    is always 64 bits where this runs, but it avoids warnings in
>>>    compile test.
>>> ---
>>>   drivers/memory/tegra/mc.c       | 25 +++++++++++++++++++++++++
>>>   drivers/memory/tegra/tegra234.c |  5 +++++
>>>   include/soc/tegra/mc.h          | 11 +++++++++++
>>>   3 files changed, 41 insertions(+)
>>
>> Krzysztof,
>>
>> I've applied this to the same tree as the patch that uses it for now.
>> Let me know if you want me to put this on a separate stable branch for
>> you to pull in.
> 
> Any update on this?

What kind of update do you expect?

Best regards,
Krzysztof
Jon Hunter Nov. 4, 2022, 3:46 p.m. UTC | #7
On 04/11/2022 15:35, Krzysztof Kozlowski wrote:
> On 04/11/2022 11:33, Jon Hunter wrote:
>> Hi Thierry, Krzysztof,
>>
>> On 24/10/2022 14:15, Thierry Reding wrote:
>>> On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko Perttunen wrote:
>>>> From: Mikko Perttunen <mperttunen@nvidia.com>
>>>>
>>>> On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
>>>> has been loaded by a bootloader. When booting NVDEC, we need to tell it
>>>> the address of this firmware, which we can determine by checking the
>>>> starting address of the carveout. As such, add an MC API to query the
>>>> bounds of carveouts, and add related information on Tegra234.
>>>>
>>>> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
>>>> ---
>>>> v2:
>>>> - Add check for 64-bit phys_addr_t. In practice phys_addr_t
>>>>     is always 64 bits where this runs, but it avoids warnings in
>>>>     compile test.
>>>> ---
>>>>    drivers/memory/tegra/mc.c       | 25 +++++++++++++++++++++++++
>>>>    drivers/memory/tegra/tegra234.c |  5 +++++
>>>>    include/soc/tegra/mc.h          | 11 +++++++++++
>>>>    3 files changed, 41 insertions(+)
>>>
>>> Krzysztof,
>>>
>>> I've applied this to the same tree as the patch that uses it for now.
>>> Let me know if you want me to put this on a separate stable branch for
>>> you to pull in.
>>
>> Any update on this?
> 
> What kind of update do you expect?

Ha! I guess I should be more explicit :-)

Well, I would like to see this change in -next and so I was hoping that 
you would respond to the above to indicate how you would like to pull 
this in.

Cheers!
Jon
Krzysztof Kozlowski Nov. 4, 2022, 3:48 p.m. UTC | #8
On 04/11/2022 11:46, Jon Hunter wrote:
> 
> On 04/11/2022 15:35, Krzysztof Kozlowski wrote:
>> On 04/11/2022 11:33, Jon Hunter wrote:
>>> Hi Thierry, Krzysztof,
>>>
>>> On 24/10/2022 14:15, Thierry Reding wrote:
>>>> On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko Perttunen wrote:
>>>>> From: Mikko Perttunen <mperttunen@nvidia.com>
>>>>>
>>>>> On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
>>>>> has been loaded by a bootloader. When booting NVDEC, we need to tell it
>>>>> the address of this firmware, which we can determine by checking the
>>>>> starting address of the carveout. As such, add an MC API to query the
>>>>> bounds of carveouts, and add related information on Tegra234.
>>>>>
>>>>> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
>>>>> ---
>>>>> v2:
>>>>> - Add check for 64-bit phys_addr_t. In practice phys_addr_t
>>>>>     is always 64 bits where this runs, but it avoids warnings in
>>>>>     compile test.
>>>>> ---
>>>>>    drivers/memory/tegra/mc.c       | 25 +++++++++++++++++++++++++
>>>>>    drivers/memory/tegra/tegra234.c |  5 +++++
>>>>>    include/soc/tegra/mc.h          | 11 +++++++++++
>>>>>    3 files changed, 41 insertions(+)
>>>>
>>>> Krzysztof,
>>>>
>>>> I've applied this to the same tree as the patch that uses it for now.
>>>> Let me know if you want me to put this on a separate stable branch for
>>>> you to pull in.
>>>
>>> Any update on this?
>>
>> What kind of update do you expect?
> 
> Ha! I guess I should be more explicit :-)
> 
> Well, I would like to see this change in -next and so I was hoping that 
> you would respond to the above to indicate how you would like to pull 
> this in.

The change will be in next via Thierry. I do not have to pull this in.

The maintainer which applies patches is responsible for:
1. Having his tree in linux-next,
2. Sending the patches to upstream maintainer (e.g. arm-soc, Linus)
later in pull request.

There is no job for me here, if I agree with Thierry. There would be a
job if I needed a separate stable branch, but that I did not decide
yet... Do you think I need to pull it? If so, why?

Best regards,
Krzysztof
Jon Hunter Nov. 4, 2022, 4:01 p.m. UTC | #9
On 04/11/2022 15:48, Krzysztof Kozlowski wrote:
> On 04/11/2022 11:46, Jon Hunter wrote:
>>
>> On 04/11/2022 15:35, Krzysztof Kozlowski wrote:
>>> On 04/11/2022 11:33, Jon Hunter wrote:
>>>> Hi Thierry, Krzysztof,
>>>>
>>>> On 24/10/2022 14:15, Thierry Reding wrote:
>>>>> On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko Perttunen wrote:
>>>>>> From: Mikko Perttunen <mperttunen@nvidia.com>
>>>>>>
>>>>>> On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
>>>>>> has been loaded by a bootloader. When booting NVDEC, we need to tell it
>>>>>> the address of this firmware, which we can determine by checking the
>>>>>> starting address of the carveout. As such, add an MC API to query the
>>>>>> bounds of carveouts, and add related information on Tegra234.
>>>>>>
>>>>>> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
>>>>>> ---
>>>>>> v2:
>>>>>> - Add check for 64-bit phys_addr_t. In practice phys_addr_t
>>>>>>      is always 64 bits where this runs, but it avoids warnings in
>>>>>>      compile test.
>>>>>> ---
>>>>>>     drivers/memory/tegra/mc.c       | 25 +++++++++++++++++++++++++
>>>>>>     drivers/memory/tegra/tegra234.c |  5 +++++
>>>>>>     include/soc/tegra/mc.h          | 11 +++++++++++
>>>>>>     3 files changed, 41 insertions(+)
>>>>>
>>>>> Krzysztof,
>>>>>
>>>>> I've applied this to the same tree as the patch that uses it for now.
>>>>> Let me know if you want me to put this on a separate stable branch for
>>>>> you to pull in.
>>>>
>>>> Any update on this?
>>>
>>> What kind of update do you expect?
>>
>> Ha! I guess I should be more explicit :-)
>>
>> Well, I would like to see this change in -next and so I was hoping that
>> you would respond to the above to indicate how you would like to pull
>> this in.
> 
> The change will be in next via Thierry. I do not have to pull this in.
> 
> The maintainer which applies patches is responsible for:
> 1. Having his tree in linux-next,
> 2. Sending the patches to upstream maintainer (e.g. arm-soc, Linus)
> later in pull request.
> 
> There is no job for me here, if I agree with Thierry. There would be a
> job if I needed a separate stable branch, but that I did not decide
> yet... Do you think I need to pull it? If so, why?


No. Like I said I just want to get this into -next for testing. I had 
_wrongly_ assumed that Thierry was waiting on feedback from you. I see 
this is not the case and so let me check with Thierry where this is.

Jon
diff mbox series

Patch

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index 2f7a58a9df1a..592907546ee6 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -107,6 +107,31 @@  int tegra_mc_probe_device(struct tegra_mc *mc, struct device *dev)
 }
 EXPORT_SYMBOL_GPL(tegra_mc_probe_device);
 
+int tegra_mc_get_carveout_info(struct tegra_mc *mc, unsigned int id,
+                               phys_addr_t *base, u64 *size)
+{
+	u32 offset;
+
+	if (id < 1 || id >= mc->soc->num_carveouts)
+		return -EINVAL;
+
+	if (id < 6)
+		offset = 0xc0c + 0x50 * (id - 1);
+	else
+		offset = 0x2004 + 0x50 * (id - 6);
+
+	*base = mc_ch_readl(mc, MC_BROADCAST_CHANNEL, offset + 0x0);
+#ifdef CONFIG_PHYS_ADDR_T_64BIT
+	*base |= (phys_addr_t)mc_ch_readl(mc, MC_BROADCAST_CHANNEL, offset + 0x4) << 32;
+#endif
+
+	if (size)
+		*size = mc_ch_readl(mc, MC_BROADCAST_CHANNEL, offset + 0x8) << 17;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(tegra_mc_get_carveout_info);
+
 static int tegra_mc_block_dma_common(struct tegra_mc *mc,
 				     const struct tegra_mc_reset *rst)
 {
diff --git a/drivers/memory/tegra/tegra234.c b/drivers/memory/tegra/tegra234.c
index a9e8fd99730f..74d291d66366 100644
--- a/drivers/memory/tegra/tegra234.c
+++ b/drivers/memory/tegra/tegra234.c
@@ -187,4 +187,9 @@  const struct tegra_mc_soc tegra234_mc_soc = {
 	.ops = &tegra186_mc_ops,
 	.ch_intmask = 0x0000ff00,
 	.global_intstatus_channel_shift = 8,
+	/*
+	 * Additionally, there are lite carveouts but those are not currently
+	 * supported.
+	 */
+	.num_carveouts = 32,
 };
diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
index 47ce6d434427..51a2263e1bc5 100644
--- a/include/soc/tegra/mc.h
+++ b/include/soc/tegra/mc.h
@@ -193,6 +193,8 @@  struct tegra_mc_soc {
 	unsigned int num_address_bits;
 	unsigned int atom_size;
 
+	unsigned int num_carveouts;
+
 	u16 client_id_mask;
 	u8 num_channels;
 
@@ -244,6 +246,8 @@  unsigned int tegra_mc_get_emem_device_count(struct tegra_mc *mc);
 #ifdef CONFIG_TEGRA_MC
 struct tegra_mc *devm_tegra_memory_controller_get(struct device *dev);
 int tegra_mc_probe_device(struct tegra_mc *mc, struct device *dev);
+int tegra_mc_get_carveout_info(struct tegra_mc *mc, unsigned int id,
+                               phys_addr_t *base, u64 *size);
 #else
 static inline struct tegra_mc *
 devm_tegra_memory_controller_get(struct device *dev)
@@ -256,6 +260,13 @@  tegra_mc_probe_device(struct tegra_mc *mc, struct device *dev)
 {
 	return -ENODEV;
 }
+
+static inline int
+tegra_mc_get_carveout_info(struct tegra_mc *mc, unsigned int id,
+                           phys_addr_t *base, u64 *size)
+{
+	return -ENODEV;
+}
 #endif
 
 #endif /* __SOC_TEGRA_MC_H__ */