All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
To: BALATON Zoltan <balaton@eik.bme.hu>, Alexander Graf <agraf@suse.de>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH v2] mac99: Change memory layout to better match PowerMac3, 1
Date: Mon, 23 Jun 2014 22:33:29 +0100	[thread overview]
Message-ID: <53A89D29.1070001@ilande.co.uk> (raw)
In-Reply-To: <alpine.LMD.2.02.1406232119330.2806@jedlik.phy.bme.hu>

On 23/06/14 20:25, BALATON Zoltan wrote:

>>> It's how OpenBIOS assigns MMIO addresses to pci devices. It does it
>>> by going through them in order and map them starting from the base
>>> address (with some allingment). I guess you could look at
>>> drivers/pci.c I think it's in there somewhere.
>>
>> I think it'd make more sense to just bolt the PCI devices to their
>> respective devfns that they also have on real hardware. Depending on
>> ordering magic that happens to give us different BAR maps by firmware
>> doesn't really give me a lot of confidence.
>
> I don't understand what you mean. I don't want to rewrite PCI handling
> code in OpenBIOS as that would have a higher chance of breaking
> something else (OpenBIOS is used by other archs as well). Also it would
> require more knowledge about the emulated hardware in OpenBIOS while it
> aims to be a generic implementation and wants to reduce special cases
> already in it. So I don't see a cleaner and easy way to do this. If I'm
> missing something please tell me. On the other hand you've said before
> that the mac99 machine is mostly a hack to be enough that some OS-es can
> run with it. Why reordering some devices to get the right BAR maps not
> fit in this hack?

Since the MMIO address is calculated by rounding up to the next start 
address based on region size (where size tends to be more static 
compared to start address) then I'd be okay with this as a short term hack.

Longer term I suspect we'll need to teach OpenBIOS about assigning fixed 
addresses to certain PCI devices based upon architecture, and it's 
starting to look like I may need to do this for the next part of my work 
on improving SPARC64 support.


ATB,

Mark.

  reply	other threads:[~2014-06-23 21:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-02 23:12 [Qemu-devel] [PATCH v2] mac99: Change memory layout to better match PowerMac3, 1 BALATON Zoltan
2014-06-09 20:26 ` [Qemu-devel] [Qemu-ppc] " BALATON Zoltan
2014-06-16 23:37   ` BALATON Zoltan
2014-06-17  8:46 ` [Qemu-devel] " Alexander Graf
2014-06-17  9:36   ` BALATON Zoltan
2014-06-17  9:39     ` Alexander Graf
2014-06-17 10:24       ` BALATON Zoltan
2014-06-22  9:14         ` [Qemu-devel] [Qemu-ppc] " BALATON Zoltan
2014-06-23 16:27         ` [Qemu-devel] " Alexander Graf
2014-06-23 19:25           ` BALATON Zoltan
2014-06-23 21:33             ` Mark Cave-Ayland [this message]
2014-06-23 22:32               ` BALATON Zoltan

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=53A89D29.1070001@ilande.co.uk \
    --to=mark.cave-ayland@ilande.co.uk \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=balaton@eik.bme.hu \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.