A couple of years ago, Linus Torvalds was discussing Linux version
numbers and said, "I think I will call it 3.11 Linux for Workgroups."
It turns out he wasn't joking. With a release candidate of Linux 3.11
now available, Torvalds has actually named the new version of the
kernel "Linux for Workgroups." He even gave it a Windows-themed boot
icon featuring Linux's mascot penguin, Tux, holding a flag emblazoned
with an old Windows logo. The name "Linux for Workgroups" follows such
whimsical past Linux version names as "Pink Farting Weasel," "Killer
Bat of Doom," "Erotic Pickled Herring," and "Jeff Thinks I Should
Change This, But To What?"
From the news:
20 years after Windows 3.11, Linus unveils “Linux for Workgroups”
You've asked way too much in one question—well, technically not, as I guess "is this understanding correct" can be answered quickly: no. But that's not a useful answer.
First, you're right about ata_piix and sd_mod apparently being compiled-in to your kernel. That's a choice you make configuring the kernel—you can omit it, include it, or include it as a module. (Same with ext4).
Second, you have assumed writes to be far simpler than they actually are. The basic outline of how a write works is that the filesystem code puts the data to be written in memory, as part of the buffer-cache, and marks it as needs-to-be-written ("dirty"). (Unless there is already too much of that in RAM, in which case it actually is forced to do the write...)
Later, various things (such as the bdflush kernel thread) actually flush the dirty pages to disk. This is when you'd see calls through sd, scsi, libata, ata_piix, io schedulers, PCI, etc. While there is very likely DMA involved in that write-out, it's of the data to be transferred, and maybe the command. But disk writes, at least in SATA, are handled by sending commands which basically mean "write sector X with data Y". But it's definitely not handled by memory-mapping the entire disk (consider: you can use disks far larger than 4GiB on 32-bit machines).
Caching is handled by the memory management subsystem (not a driver), in conjunction with the filesystem, block layer, etc.
tmpfs is special, it is basically entirely cache. Its just special cache that is never discarded or written back (though it can be swapped out). You can find the code in mm/shmem.c and several other places (try ack-grep --cc CONFIG_TMPFS to find them).
Basically, writing to disk goes through a good portion of the kernel's subsystems; networking is the only major one I can think of that isn't involved in your example. Properly explaining it requires a book-length effort; I recommend looking for one.
Best Answer
The Linux kernel never stores anything on a disk of its own behalf. It stores the files that applications tell it to store through the filesystem interface, or data on block devices accessed directly, or metadata of mounted filesystems and disk volumes.
Besides it wouldn't make any sense to store the encryption key on the same media.
The encryption key is only stored in RAM. It is entered before mounting the encrypted filesystem. The key is typically derived from a passphrase typed by the user, but it can also be loaded from e.g. a smartcard. The kernel documentation has the details.
It is possible to store the encryption key for a volume in a file outside that volume, and load that. It can make sense to have a key on a removable drive that's inserted physically at boot time, for example. But the kernel won't do this on its own, it's up to the system's startup scripts to do that.