https://bugzilla.novell.com/show_bug.cgi?id=445856
User matt@genesi-usa.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=445856#c7
Matt Sealey changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |ASSIGNED
Info Provider|matt@genesi-usa.com |
--- Comment #7 from Matt Sealey 2008-11-18 08:19:16 MST ---
The bcom_task->bd change was kind of important but I forget why (buffer
descriptors change size per-task I think?)
It may break audio but that's really an opportunity to fix the audio driver
more than "unpatch" possibly a working change. When the ATA DMA patch hits
mainline the audio patch will stop working again, too, on that tree.. this is
what we get for not having anyone willing to work on it or push it through the
ALSA developers.
The Kconfig changes aren't important, you're right, but they do make life
easier :)
For cmdline knobs; there are none. You need the entries in the device tree.
However patching prom_init.c means that a blanket enable will be in the kernel.
This is dangerous. Some users may be using CompactFlash adapters and some of
these do not connect the DMA lines from the DMA-capable flash card to the
DMA-capable controller, effectively cutting it off. You can't detect this in
any way except to look at the adapter with an eyeball, once the card fails.
It may well be that in certain configurations higher DMA access modes are a bad
idea, in which case setting mwdma-mode and udma-mode to the highest in the
kernel (only if not present on the device tree) is simply annoying.
Once the entries are in the device tree, libata.dma=0 will disable DMA, others
will select other DMA modes (check kernel-parameters.txt) and libata.modes will
specifically set DMA modes on specific devices (however you need to boot Linux
first and see how libata enumerates the disks to find the correct semantics)
I really do not agree with fixing the device tree in prom_init.c and I would
not approve and strongly advise against more patches. This can be considered
and applied using firmware scripting - this is why Genesi uses a dynamic
generated Open Firmware solution and allows Forth scripting. Many "useful"
nodes in the 5200B tree are not implemented for many potential drivers (I2C,
I2S, CAN, GPIO) but these are not essential to booting the board for Linux. Our
intention was always to ship a working, usable tree to a certain point and then
allow snippets of code to further describe the system - at a user level.
It is very true that someone downloading the original SUSE ISO onto an Efika
will not get DMA without an extra effort but this effort is extremely minimal
and can be edited into the nvramrc (nvedit and nvstore commands in OF) without
too much fuss. This is then a permanent addition and no external scripts would
be required.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.