From: nsekhar@ti•com (Sekhar Nori)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
Date: Wed, 12 Dec 2012 18:36:55 +0530 [thread overview]
Message-ID: <50C8816F.5020801@ti.com> (raw)
In-Reply-To: <CA+V-a8sTBXMCXoTAjbuT9HUJkw_Na5SRUz2qAwvrebQXPWg6Rg@mail.gmail.com>
On 12/12/2012 4:31 PM, Prabhakar Lad wrote:
> Hi Sekhar,
>
> On Wed, Dec 12, 2012 at 4:04 PM, Sekhar Nori <nsekhar@ti•com> wrote:
>> On 12/12/2012 7:06 AM, Tivy, Robert wrote:
>>>> -----Original Message-----
>>>> From: Nori, Sekhar
>>>> Sent: Friday, November 30, 2012 2:51 AM
>>>>
>>>> Hi Rob,
>>>>
>>>> On 11/29/2012 7:08 AM, Tivy, Robert wrote:
>>>>> Hi Sekhar,
>>>>>
>>>>> Please see comments and noob questions below...
>>>>>
>>>>> They can run a single image if the image supports overriding the
>>>> Kconfig settings with kernel command-line arguments.
>>>>>
>>>>> The most basic solution is constants in the .c file itself. A better
>>>> solution is Kconfig settings used by the .c file. An even better
>>>> solution is Kconfig settings with kernel command-line overrides.
>>>>
>>>> If you have kernel command line, you could default to some values which
>>>> are sane in most cases if they are not provided. No, need to have a
>>>> Kconfig as well. That will be too many hooks to control the same things
>>>> and probably not necessary.
>>>>
>>>>>
>>>>>> If you want the remoteproc driver to allocate a certain area of
>>>> memory
>>>>>> to the dsp, why don't you take that value as a module parameter so
>>>>>> people who need different values can pass them differently? It is
>>>> not
>>>>>> clear to me why this memory management needs to be dealt with in
>>>>>> platform code.
>>>>>
>>>>> Unfortunetly we need to reserve this dsp memory during early boot,
>>>> using CMA. Runtime module insertion is too late.
>>>>
>>>> Then I guess most of the time the module would be built into the kernel
>>>> and will be initialized using an early enough initcall.
>>>
>>> That's right, a .reserve function is assigned to the MACHINE_START structure, and this function calls dma_declare_contiguous().
>>
>> I meant use an early initcall in the driver.
>>
>>>
>>>>>>> +
>>>>>>> +static int __init early_rproc_mem(char *p) {
>>>>>>> + char *endp;
>>>>>>> +
>>>>>>> + rproc_size = memparse(p, &endp);
>>>>>>> + if (*endp == '@')
>>>>>>> + rproc_base = memparse(endp + 1, NULL);
>>>>>>> +
>>>>>>> + return 0;
>>>>>>> +}
>>>>>>> +early_param("rproc_mem", early_rproc_mem);
>>>>>>
>>>>>> Use of non-standard kernel parameters is discouraged. All kernel
>>>>>> parameters should be documented in Documentation/kernel-
>>>> parameters.txt
>>>>>> (this means each and every kernel parameter needs to be justified
>>>>>> well).
>>>>>
>>>>> Can I use the kernel command-line (i.e., u-boot bootargs variable) to
>>>> specify non-kernel parameters? I guess my question is more one about
>>>> the terminology "kernel parameter" - is there a way to specify a module
>>>> parameter on the kernel command line (like, perhaps, rproc.membase and
>>>> rproc.memsize)?
>>>>
>>>> Right. Module parameters are passed from kernel command line when the
>>>> module is built into the kernel.
>>>
>>> Unfortunately, it seems that module parameters, when stated on the kernel command line with module-name.var-name syntax, are not yet assigned when the kernel calls the early init .reserve functions. For the "char *" I'm using, I observed a NULL value during the early init call and the proper assigned value during a later normal __init function.
>>
>> By "later normal __init" you mean module_init()? And you see
>> dma_declare_contiguous() returning error by this time?
>>
>>>
>>> Is there any other method that allows specifying a parameter for an early CMA reservation without having to rebuild the kernel?
>>
>> Nothing else comes to mind. Can you share your code in some public repo?
>> It will allow me to try if something comes to mind.
>>
>>>
>>> If not, is this a strong enough use case to justify a new kernel parameter?
>>
>> May be it it is. You could try adding it. Just update the documentation
>> too. And add the documentation maintainers when you respin the patch.
>>
> I tried finding some alternatives apart from early_param, but there aren?t any.
> The only thought I got from Marek is to have device tree support. How about
> that as an option ?
Can you explain some more? How does device tree help here? May be give a
link to this discussion so I can read?
Thanks,
Sekhar
next prev parent reply other threads:[~2012-12-12 13:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1352853207-20602-1-git-send-email-rtivy@ti.com>
2012-11-14 10:12 ` [PATCH v3 1/6] ARM: davinci: Changed pr_warning() to pr_warn() (part 1) Sergei Shtylyov
[not found] ` <1352853207-20602-2-git-send-email-rtivy@ti.com>
2012-11-14 10:17 ` [PATCH v3 2/6] ARM: davinci: Changed pr_warning() to pr_warn() (part 2) Sergei Shtylyov
2012-11-15 1:53 ` Tivy, Robert
2012-11-15 9:46 ` Sergei Shtylyov
2012-11-20 11:27 ` Sekhar Nori
[not found] ` <1352853207-20602-5-git-send-email-rtivy@ti.com>
2012-11-20 12:26 ` [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP Sekhar Nori
2012-11-29 1:38 ` Tivy, Robert
2012-11-30 10:50 ` Sekhar Nori
2012-12-01 2:11 ` Tivy, Robert
2012-12-03 14:41 ` Sekhar Nori
2012-12-03 20:13 ` Cyril Chemparathy
2012-12-04 2:30 ` Tivy, Robert
2012-12-04 5:58 ` Sekhar Nori
[not found] ` <50BE0E54.5060607@ti.com>
[not found] ` <50BE2115.4000606@ti.com>
[not found] ` <13514BD7FAEBA745BBD7D8A672905C14311FB29D@DFLE08.ent.ti.com>
2012-12-05 8:35 ` Sekhar Nori
2012-12-07 8:24 ` Sekhar Nori
2012-12-08 1:04 ` Tivy, Robert
2012-12-12 1:36 ` Tivy, Robert
2012-12-12 10:34 ` Sekhar Nori
2012-12-12 11:01 ` Prabhakar Lad
2012-12-12 13:06 ` Sekhar Nori [this message]
2012-12-12 13:13 ` Prabhakar Lad
2012-12-13 8:18 ` Prabhakar Lad
2012-12-14 8:17 ` Sekhar Nori
2012-12-14 2:19 ` Tivy, Robert
[not found] ` <1352853207-20602-6-git-send-email-rtivy@ti.com>
2012-11-20 12:30 ` [PATCH v3 6/6] ARM: davinci: remoteproc driver " Sekhar Nori
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=50C8816F.5020801@ti.com \
--to=nsekhar@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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