remove an unused prototype

improve buffer handling

re: pointer arithmetic, i have a better idea of how to do this, but let's
see if this is a better way to handle shutdown in the mean time.

use uint8_t for bitfields

already landed in 0de6295af231aa5c13e1da2f40b29106962b6363

This really is funny, that we're working around broken IBM and Apple hardware by putting a quirk on the one conforming implementer.

update

rebase

rebase

rebase

update

rebase

rebase

rebase after jhb's vm_offset_t changes

looks like this diff got the flags stuff and shuffling around where the 'struct bus_dma_tag' is defined.
I'll go clean that up shortly.

ok, this one boots fine in p8 pseries and p9 pseries, but p8 powernv it .. just hangs during boot and eventually ends up at OPAL.

In D55315#1266124, @tpearson_raptorengineering.com wrote:

Seeing the same problem with just D54745, D55313, and D55314. I suppose it's possible D54745 could shift things around enough to make the problem appear, but I'm not comfortable merging code into the DMA system when I already know we're violating platform constraints (without D54745 I know for a fact we're allocating bounce buffer in an illegal region and Bad Things via undefined behavior are likely -- just because we get away with it long enough to boot doesn't mean we're not going to get data corruption and lockups later on).

Seeing the same problem with just D54745, D55313, and D55314. I suppose it's possible D54745 could shift things around enough to make the problem appear, but I'm not comfortable merging code into the DMA system when I already know we're violating platform constraints (without D54745 I know for a fact we're allocating bounce buffer in an illegal region and Bad Things via undefined behavior are likely -- just because we get away with it long enough to boot doesn't mean we're not going to get data corruption and lockups later on).

That actually does make sense -- physmem is different on PowerNV vs. pSeries, especially because use of the IOMMU is effectively mandatory on pSeries. I'm not sure you're going to be able to reproduce easily on qemu short of setting up a PowerNV system to test with, which in turn requires a current skiboot build, etc. Additionally, the mpr driver is unique in the entire tree as far as I can tell, I'm not sure the DMA over-allocation issue will be reproducible without an LSI card attached.

ok, does this happen without this domain change? can you just try D55312, D55313, D55314?

All that said, I bet if the mpr DMA issue was fixed the problem introduced in the port would at least be masked. I'm unclear what the "correct" behavior should be when we run out of bounce buffers; with the stock kernel, it looks like ahci and usb are simply denied buffer allocation (-ENOSPC) so they fall back to a DMA-free mode, whereas with the patch series applied they're (successfully) allocated too small of a bounce region and just lock up.

This is why I was saying we should probably find the fault in my patchset, and fix that, along with whatever is going wrong with the DMA tag setup where the mpr driver is allocating too much bounce memory. There's something different in the DMA core vs. what the old powerpc DMA code is trying to do, and whatever it is is quite subtle.

Yeah, here's the boot from a stock kernel:

oh interesting. is this different from straight -head? If it is then i need to fix it. If it isn't then it's expected behaviour!

Unfortunately this fails to boot on POWER9/PowerNV with the following patch series:

refactor

refactor

refactor

refactor