Another comment in the tree showed that some Rockchip SOCs do have most of the requisite widgets built-in to the SoC. So the market is already moving this way. Its just not ubiquitous yet.
The protocol is described in detail in the USB-PD spec under the physical layer chapter. Its a 300 kHz biphase mark coding scheme with lots of slop available in the timing. Looks like it was designed for low-end power supplies that considered USB 1.1 to be too expensive. The PD protocol isn't horribly broken or anything. But personally, I would have preferred to see all of it managed over the classic USB D+/D- lines as a separate device profile.
The basic set of microcontroller serial peripherals (UART, SPI, I2C, etc) aren't going to handle it well, though. Maybe you could finagle a SPI device into sampling the lines, and then figure out what the bits were in software, kindof like an oversampling UART? Maybe? Or you could bit-bang via GPIOs? Not the kind of project I would be interested in. For open source work, a small FPGA would be a much better choice to work with. Its not particularly complex logic... but doing it in software is going to be very inefficient.
Well, I thought about doing it in software (bit-banging the GPIOs should probably be enough for any kind of signal at 300Hz)... I really need to read the spec, but I guess this signal is just needed for the handshake? If that's the case, you can probably afford to do it on the CPU.
As for the open source part, yeah, I was specifically thinking about open ASIC designs (whether at the RTL level, thus compilable to an FPGA, or at the layout level). The ecosystem is blooming, with open source memory compilers, as well as academic/enthusiast tools (BAG, scala, hammer-vlsi, migen) that are making great strides.
The protocol is described in detail in the USB-PD spec under the physical layer chapter. Its a 300 kHz biphase mark coding scheme with lots of slop available in the timing. Looks like it was designed for low-end power supplies that considered USB 1.1 to be too expensive. The PD protocol isn't horribly broken or anything. But personally, I would have preferred to see all of it managed over the classic USB D+/D- lines as a separate device profile.
The basic set of microcontroller serial peripherals (UART, SPI, I2C, etc) aren't going to handle it well, though. Maybe you could finagle a SPI device into sampling the lines, and then figure out what the bits were in software, kindof like an oversampling UART? Maybe? Or you could bit-bang via GPIOs? Not the kind of project I would be interested in. For open source work, a small FPGA would be a much better choice to work with. Its not particularly complex logic... but doing it in software is going to be very inefficient.