Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] remoteproc: pru: future-proof PRU ID matching
To:     Suman Anna <s-anna@ti.com>, linux-remoteproc@vger.kernel.org
Cc:     Ohad Ben-Cohen <ohad@wizery.com>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>,
        linux-kernel@vger.kernel.org
References: <20210104211816.420602-1-david@lechnology.com>
 <ccc1ee4b-ed73-f7c8-ca1e-f15eedeeb84b@ti.com>
 <e2a0a40d-f720-8139-29f3-39a473c69119@ti.com>
From:   David Lechner <david@lechnology.com>
Message-ID: <5fed434e-1569-ab9f-b1a4-475aa820ef47@lechnology.com>
Date:   Thu, 28 Jan 2021 17:21:21 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <e2a0a40d-f720-8139-29f3-39a473c69119@ti.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 1/28/21 4:55 PM, Suman Anna wrote:
> Hi David,
> 
> On 1/15/21 6:53 PM, Suman Anna wrote:
>> On 1/4/21 3:18 PM, David Lechner wrote:
>>>   static int pru_rproc_probe(struct platform_device *pdev)
>>> @@ -825,20 +808,28 @@ static int pru_rproc_remove(struct platform_device *pdev)
>>>   
>>>   static const struct pru_private_data pru_data = {
>>>   	.type = PRU_TYPE_PRU,
>>> +	.pru0_iram_offset = 0x4000,
>>> +	.pru1_iram_offset = 0x8000,
> 
> The offsets for the PRU cores are actually 0x34000 and 0x38000 respectively from
> the base of the PRUSS on non-Davinci SoCs.
> 
> If we were to use this static data approach, then we might as well continue to
> use the current address masking logic with the appropriate masks for Davinci
> (0x38000 and 0x3C000, not true offsets but as masks they would work). Davinci
> PRUSS is the only one with its differences being the first PRUSS IP, and I would
> prefer to keep the logic aligned to the IPs on all the recent SoCs on 3
> different TI SoC families (OMAP, Keystone 2 and K3).
> 
> Let me know what you think.

I'm not too picky as long as it works. :-)

If keeping the static data to a minimum is really important, I suppose we could
introduce a new type = PRU_TYPE_PRU_V1 for these PRUSSs instead. It sounds like
this information might be useful elsewhere anyway.