PPC: Mac: Fix guest exported tbfreq values

We can tell the guest the frequency of its time base through fwcfg.

However, we tell it a different value from the speed tb actually runs
at. Let's fix it and make the tbfreq initialization and the fwcfg exposure
use the same values.

Signed-off-by: Alexander Graf <agraf@suse.de>
PPC: g3beige:  Move secondary IDE bus to mac-io

On a real G3 Beige the secondary IDE bus lives on the mac-io chip, not
on some random PCI device. Move it there to become more compatible.

While at it, also clean up the IDE channel connection logic.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v1 -> v2:

  - fix spaces
PPC: Macio: Replace tabs with spaces

s/^I/        /g on the file.

Signed-off-by: Alexander Graf <agraf@suse.de>
PPC: dbdma: Replace tabs with spaces

s/^I/        /g on the file with a few manual tweaks to align things.

Signed-off-by: Alexander Graf <agraf@suse.de>
PPC: Mac: Add debug prints in macio and dbdma code

The macio code is basically undebuggable as it stands today, with no
debug prints anywhere whatsoever. DBDMA was better, but I needed a
few more to create reasonable logs that tell me where breakage is.

Add a DPRINTF macro in the macio source file and add a bunch of debug
prints that are all disabled by default of course.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v1 -> v2:

  - use non-bitrotting DPRINTF for macio
  - clean up
PPC: dbdma: Fix debug print

There was a debug print that didn't compile for me because the format
and the arguments weren't in sync. Fix it up.

Signed-off-by: Alexander Graf <agraf@suse.de>
PPC: dbdma: Allow new commands in RUN state

The DBDMA controller can not change its command stream while it's
actively streaming data, true. But the fact that it's in RUN state
doesn't actually indicate anything. It could just as well be in
WAIT while in RUN. And then it's legal to change commands.

This fixes a real world issue I've encountered with Mac OS X.

Signed-off-by: Alexander Graf <agraf@suse.de>
PPC: dbdma: Move defines into header file

We usually keep struct and constant definitions in header files. Move
them there to stay consistent and to make access to fields easier.

Signed-off-by: Alexander Graf <agraf@suse.de>
PPC: dbdma: Introduce kick function

The DBDMA engine really is running all the time, waiting for input. However
we don't want to waste cycles constantly polling.

So introduce a kick function that data providers can call to notify the
DBDMA controller of new input.

Signed-off-by: Alexander Graf <agraf@suse.de>
PPC: dbdma: Move static bh variable to device struct

The DBDMA controller has a bottom half to asynchronously process DMA
request queues.

This bh was stored as a gross static variable. Move it into the device
struct instead.

While at it, move all users of it to the new generic kick function.

Signed-off-by: Alexander Graf <agraf@suse.de>
PPC: dbdma: macio: Add DMA callback

We need to know when the IDE core starts a DMA transfer. Add a notifier
function so we have the chance to start transmitting data.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v1 -> v2:

  - fix dprintf
PPC: dbdma: Move processing to io

Soon we will introduce intermediate processing pauses which will
allow the bottom half to restart a DMA request that couldn't be
fulfilled yet.

For that to work, move the processing variable into the io struct
which is what DMA providers work with.

While touching it, also change it into a bool

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v1 -> v2:

  - make processing a bool
PPC: dbdma: Wait for DMA until we have data

We should only start processing DMA requests when we have data to process.
Hold off working through the DMA shuffling until the IDE core told us that
it's ready.

This is required because the guest can program the DMA engine or the IDE
transfer first. Both are legal.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v1 -> v2:

  - move processing to bool
PPC: dbdma: Support unaligned DMA access

The DBDMA engine really just reads bytes from a producing device (IDE
in our case) and shoves these bytes into memory. It doesn't care whether
any alignment takes place or not.

Our code today however assumes that block accesses always happen on
sector (512 byte) boundaries. This is a fair assumption for most cases.

However, Mac OS X really likes to do unaligned, incomplete accesses
that it finishes with the next DMA request.

So we need to read / write the unaligned bits independent of the actual
asynchronous request, because that one can only handle 512-byte-aligned
data. We also need to cache these unaligned sectors until the next DMA
request, at which point the data might be successfully flushed from the
pipe.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v2 -> v3:

  - create a new sg list before restarting an atapi request
PPC: Add timer handler for newworld mac-io

Mac OS X accesses fancy timer registers inside of the mac-io on bootup.

These really should be ticking at the mac-io bus frequency, but I don't
see anyone upset when we just make them as fast as we want to.

With this patch on top of my previous patch queue and latest OpenBIOS
I am able to boot Mac OS X 10.4 with -M mac99.

Signed-off-by: Alexander Graf <agraf@suse.de>
PPC: dbdma: Support more multi-issue DMA requests

A DMA request can happen for data that hasn't been completely been
provided by the IDE core yet. For example

  - DBDMA request for 0x1000 bytes
  - IDE request for 1 sector
  - DBDMA wants to read 0x1000 bytes (8 sectors) from bdrv
  - breakage

Instead, we should truncate our bdrv request to the maximum number
of sectors we're allowed to read at that given time. Once that transfer
is through, we will fall into our recently introduced waiting logic.

  - DBDMA requests for 0x1000 bytes
  - IDE request for 1 sector
  - DBDMA wants to read MIN(0x1000, 1 * 512) bytes
  - DBDMA finishes reading, indicates to IDE core that transfer is complete
  - IDE request for 7 sectors
  - DBDMA finishes the DMA

Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Alexander Graf <agraf@suse.de>