From: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Maxime Coquelin <maxime.coquelin-qxv4g6HH51o@public.gmane.org>,
Patrice Chotard <patrice.chotard-qxv4g6HH51o@public.gmane.org>,
Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>,
"devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: st_fdma: Firmware filename in DT?
Date: Thu, 3 Sep 2015 16:45:35 -0500 [thread overview]
Message-ID: <CAL_JsqKQqbAQCPR6xuR2Ke5gEdX4kQYb29-W3qNaZqjM_JBoYg@mail.gmail.com> (raw)
In-Reply-To: <20150903144944.GC7093@griffinp-ThinkPad-X1-Carbon-2nd>
+devicetree-spec as a good question to separate from the fire hose.
On Thu, Sep 3, 2015 at 9:49 AM, Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Hi Rob, Pawel, Mark, Ian and Kumar,
>
> Quick question regarding this series here
> https://lkml.org/lkml/2015/7/8/832. and the proposed
> st,fw-name binding.
Thanks for looking at the bigger picture.
> What are the rules with putting firmware names into DT?
Whatever you can sneak in without DT maintainers noticing...
> Is it allowed?
They are already there as you have found, so yes. But should they be
allowed? Possibly. I'm not saying no, but do have some concerns.
> If yes, is it worth having a generic binding?
If we decide it is a good idea, then yes. It doesn't look that hard to
arrive at something common.
Strictly speaking, the firmware name is just an agreed upon name
between the kernel and userspace. So why tie that into DT? Would other
OS's use it or want something different? What if we started including
paths in the names like <soc>/<firmware file>? Now we are imposing a
directory structure on the OS filesystem.
We'd also need to consider firmware that is needed to boot. In that
case, we could include firmware binary directly in the dtb. I think
that has been done before, but not in any standard way. u-boot FIT
images happen to be DTBs containing mostly binary blobs.
> From what I can see TI are using: -
> ti,pm-firmware in wkup_m3_rproc.c
>
> and Freescale are using: -
> fsl,sdma-ram-script-name in imx-sdma.c
>
> So other platforms seem to be putting firmware names into DT,
> there are probably other examples.
>
> Most other STi drivers keep the firmware name in the C code, which is
> usually my first preference. However with fdma it is more complicated
> as there are seperate firmware files for each instance of the IP block.
>
> Currently also the same IP block "fdma_mpe31" is used on a number
> of different SoC's but each firmware is named: -
>
> fdma_<SoC>_<instancenum>.elf
>
> e.g. fdma_STiH407_0.elf
>
> So currently all we need to provide is a different firmware name in DT
> for the new SoC and the driver "just works".
>
> Presumably the alternative would be to add a whole bunch of compatibles
> in the driver for each SoC, where the only difference from a
> functional point of view would be to help build the correct string for
> the firmware filename. However I'm also then wondering what the best way
> would be to find out the instance name of the IP.
If the name/path is Linux specific, then that is probably what we should do.
You could perhaps make a policy that firmware files be named by
compatible string. So rather than translating from matching compatible
to an arbitrary file name, you enforce file name is "<vendor>,<ip
block>.fw" or something. I know we don't have policy in the kernel,
but we already have it with hardcoded file names and search paths.
> We could do it by parsing the node name e.g. fdma0-audio, or by adding
> a "instance" DT property to the node?
Generally we try to avoid caring about node names. Having some index
or numbering also comes up which we also try to avoid. Generally, if
you care about which instance you use for something, then there is
some property you care about and should add.
Rob
next parent reply other threads:[~2015-09-03 21:45 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20150903144944.GC7093@griffinp-ThinkPad-X1-Carbon-2nd>
2015-09-03 21:45 ` Rob Herring [this message]
[not found] ` <CAL_JsqKQqbAQCPR6xuR2Ke5gEdX4kQYb29-W3qNaZqjM_JBoYg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-04 6:59 ` st_fdma: Firmware filename in DT? Lee Jones
2015-09-04 9:20 ` Peter Griffin
2015-09-04 10:21 ` Lee Jones
2015-09-04 13:04 ` Arnd Bergmann
[not found] ` <201509041504.38412.arnd-r2nGTMty4D4@public.gmane.org>
2015-09-04 13:26 ` Lee Jones
2015-09-04 13:44 ` Rob Herring
[not found] ` <CAL_Jsq+XpBV+BMMq1gYnvKtv6O5mjqVw6zsP4G-4Za3cQm9PzQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-04 13:54 ` Lee Jones
2015-09-04 14:36 ` Warner Losh
2015-09-05 9:17 ` Arnd Bergmann
[not found] ` <201509051117.59751.arnd-r2nGTMty4D4@public.gmane.org>
2015-09-08 3:14 ` David Gibson
2015-09-04 14:30 ` Warner Losh
[not found] ` <C93CEE95-AF30-4B2D-BD96-66733B282414-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org>
2015-09-05 8:58 ` Arnd Bergmann
[not found] ` <CANCZdfrLbbN_nGJ8WLsBHHGuM3SxGgiLgjkZ+YG4zP4BBA68YQ@mail.gmail.com>
[not found] ` <CANCZdfrLbbN_nGJ8WLsBHHGuM3SxGgiLgjkZ+YG4zP4BBA68YQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-07 12:41 ` Arnd Bergmann
2015-09-04 14:27 ` Warner Losh
[not found] ` <5E0DCAA5-DB90-4682-92F2-061A07FE973E-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org>
2015-09-04 19:04 ` Rob Herring
[not found] ` <CAL_Jsq+bw1TcXt0c8L4BSvwWK82L2cG-qdw369EkvxWe-5RXbQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-05 9:25 ` Arnd Bergmann
[not found] ` <201509051125.43527.arnd-r2nGTMty4D4@public.gmane.org>
2015-09-07 10:30 ` Daniel Thompson
[not found] ` <55ED6733.7050807-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-09-07 12:33 ` Arnd Bergmann
2015-09-07 14:36 ` Daniel Thompson
[not found] ` <55EDA0EB.1040501-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-09-07 15:59 ` Arnd Bergmann
2015-09-10 14:18 ` Peter Griffin
2015-09-11 9:17 ` Lee Jones
2015-09-11 9:21 ` Arnd Bergmann
2015-09-11 9:39 ` Lee Jones
2015-09-11 9:46 ` Peter Griffin
2015-09-11 10:25 ` Lee Jones
2015-09-11 12:31 ` Peter Griffin
2015-09-04 16:19 ` Daniel Thompson
2015-09-04 8:46 ` Peter Griffin
2015-09-08 2:57 ` David Gibson
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=CAL_JsqKQqbAQCPR6xuR2Ke5gEdX4kQYb29-W3qNaZqjM_JBoYg@mail.gmail.com \
--to=robherring2-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=ludovic.barre-qxv4g6HH51o@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=maxime.coquelin-qxv4g6HH51o@public.gmane.org \
--cc=patrice.chotard-qxv4g6HH51o@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).