From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: "DATACOM - Érico Nunes"
<erico.nunes-rCUF4CxDseZknzVnJbg3IA@public.gmane.org>
Cc: grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Creating a new platform_bus inside a spi_driver
Date: Fri, 07 Nov 2014 11:04:36 +0100 [thread overview]
Message-ID: <707686811.tbHdnxXMgE@wuerfel> (raw)
In-Reply-To: <545BD3EC.6050503-rCUF4CxDseZknzVnJbg3IA@public.gmane.org>
On Thursday 06 November 2014 18:02:52 DATACOM - Érico Nunes wrote:
>
> The idea is that "fpga-spi" is a spi_driver which instantiates all of the
> "fpga-deviceN" as platform_devices, through the use of
> of_platform_populate(dev->of_node, NULL, NULL, dev).
>
> The visible problem we're facing with this approach is that, as the internal
> platform_devices have a "reg" property, of_platform_populate() eventually
> triggers an address translation which is apparently trying to translate the
> addresses of the internal platform_bus to addresses of the processor memory
> map.
> This translation is however not part of our intention, as we intend to have an
> internal bus with its own memory map.
> This fails when __of_translate_address() reaches the spi-master boundary
> because (as it seems to make sense) it isn't possible to translate them past
> that.
> A KERN_ERR rated message like
> "prom_parse: Bad cell count for /soc@f0000000/spi@2000/fpga@1"
> is thrown by __of_translate_address() and later it is not possible to obtain
> the "reg" address with platform_get_resource().
>
> On this scenario, we have a few questions and, depending on the outcome of
> these, possibly a patch.
>
> 1. Is it possible to have an internal platform_bus with a different memory map
> as we intended? Or are platform_busses and platform_devices supposed to always
> be mapped on the processor memory map?
It's inconsistent. We have some code that assumes that platform devices
are always memory mapped, and some other code that breaks this assumption.
> 2. If platform_bus and platform_device were actually designed to always be
> mappable to the processor memory map, what would be a different approach to
> this problem? One alternative considered was to define a new "fpga_bus" and
> "fpga_device" but that seemed as an overkill approach to the problem.
I think the existing mfd framework should do what you need, when you call
mfd_add_devices() and pass a table of cells with the compatible strings
for your devices, it should create the platform devices you want. If not,
that can probably be fixed in the mfd core code.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-11-07 10:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-06 20:02 Creating a new platform_bus inside a spi_driver DATACOM - Érico Nunes
[not found] ` <545BD3EC.6050503-rCUF4CxDseZknzVnJbg3IA@public.gmane.org>
2014-11-07 10:04 ` Arnd Bergmann [this message]
2014-11-07 16:37 ` DATACOM - Érico Nunes
2014-11-07 17:04 ` Arnd Bergmann
2014-11-11 11:07 ` Grant Likely
[not found] ` <20141111110757.3DFFAC40D48-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2014-11-13 8:52 ` Stanimir Varbanov
2014-11-15 15:23 ` DATACOM - Erico Nunes
2014-11-15 15:32 ` DATACOM - Erico Nunes
2014-11-11 11:20 ` Grant Likely
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=707686811.tbHdnxXMgE@wuerfel \
--to=arnd-r2ngtmty4d4@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=erico.nunes-rCUF4CxDseZknzVnJbg3IA@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=sameo-VuQAYsv1563Yd54FQh9/CA@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