From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Jason Cooper <jason@lakedaemon.net>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Gregory CLEMENT <gregory.clement@free-electrons.com>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] PCI: mvebu: Take control of mbus windows setup by the firmware
Date: Thu, 10 Nov 2016 09:30:37 +0100 [thread overview]
Message-ID: <20161110093037.376ae79d@free-electrons.com> (raw)
In-Reply-To: <20161026174440.GA24717@obsidianresearch.com>
Hello,
On Wed, 26 Oct 2016 11:44:40 -0600, Jason Gunthorpe wrote:
> The firmware may setup the mbus to access PCI-E and indicate this
> has happened with a ranges mapping for the PCI-E ID. If this happens
> then the mbus setup and the pci dynamic setup conflict, creating
> problems.
>
> Have PCI-E assume control of the firmware specified default mapping by
> setting the value of the bridge window to match the firmware mapping.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Sorry for the late feedback. I am not sure to fully understand what you
are trying to do here.
However, one thing that confuses me specifically is how can the kernel
get any MBus mapping set up by the firmware? Indeed, when the
mvebu-mbus driver initializes, it destroys all existing MBus windows
that might have been left by the firmware/bootloader:
static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
phys_addr_t mbuswins_phys_base,
size_t mbuswins_size,
phys_addr_t sdramwins_phys_base,
size_t sdramwins_size,
phys_addr_t mbusbridge_phys_base,
size_t mbusbridge_size,
bool is_coherent)
[...]
for (win = 0; win < mbus->soc->num_wins; win++)
mvebu_mbus_disable_window(mbus, win);
Why does Linux needs to rely on what the firmware has setup in terms of
MBus windows? Why can't Linux just find out the right BAR base/size
like it is doing for all other devices?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2016-11-10 8:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-26 17:44 [PATCH] PCI: mvebu: Take control of mbus windows setup by the firmware Jason Gunthorpe
2016-11-09 23:01 ` Jason Gunthorpe
2016-11-10 8:30 ` Thomas Petazzoni [this message]
2016-11-10 16:45 ` Jason Gunthorpe
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=20161110093037.376ae79d@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=bhelgaas@google.com \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.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 NNTP newsgroup(s).