The ili9xxx component works with displays connected to an SPI bus. With a reasonably small change I have adapted it to work with displays with a parallel (“8080-style”) connection.
Now I saw that ili9xxx is deprecated and mipi_spi is preferred.
Adapting mipi_spi for parallel connection is a bit of a problem. For starters it has “SPI” right in its name, so it feels wrong to put the code there. It also inherits from SPIDevice.
There is also mipi, but all the model definitions live in mipi_spi.
The best way forward would probably be to create a mipi_parallel component and move all the common definitions to mipi.
@clydebarrow, any thoughts?
Already implemented in mipi_spi using an octal SPI bus, which works with 8080 style parallel busses, and is more reliable than the ESP-IDF 8080 support.
Hm, I’m not sure that helps with my board.
This is how the display is connected:
For the SPI bus I have configured clk_pin to GPIO4 (TFT_WR) and data_pins to the various GPIOs. I have also configured type: octal and interface: software to be independent of hardware features (this board uses a regular ESP32).
For the display I have configured cs_pin to GPIO33 (TFT_CS), dc_pin to GPIO15 (TFT_RS) and reset_pin to GPIO32 (TFT_RST).
When I add bus_mode: octal I get an error: This feature is only available on ESP32P4, ESP32S2, ESP32S3.
With only the SPI bus, without display, it builds fine, even with type: octal.
True, octal SPI isn’t supported by the original ESP32, and currently the software SPI implementation only supports single bit mode. Adding octal mode support to the software SPI implementation would be one option. How does your current solution work - is it bit-banging?
When that board was designed the ESP32-S3 wasn’t available, but it’s an odd choice of interface since the display could have been used in SPI mode.
Good point. I’ll see if I can get that working.
Yes, although not using digital_write() but rather GPIO.out_w1ts, so it’s more like byte-banging. 
Yeah, that struck me as odd as well, why would you spend more GPIOs - maybe it’s faster since it’s parallel?
Well it’s potentially faster, but not if you have to bit or byte-bang. The single-bit SPI will go up to 40MHz or 5 MB/s whereas in software parallel you’re not going to get to 1MB/s.
I’m assuming you mean per lane in which case you’re right. I get about 3 MB/s (330 ns per cycle/byte) with octal SPI.
I copied the existing this->cycle_clock_() calls, which limit the data rate to the given data_rate, but they cause some overhead. When I remove them, I get 4.7 MB/s (210 ns per cycle/byte). So it may be worth introducing something like data_rate: unlimited.
Here’s my draft PR: [spi] Software quad and octal SPI on classic ESP32 by AndreKR · Pull Request #17539 · esphome/esphome · GitHub
I still need to polish it and add docs, but if you have the time, please take a look at the decisions in the PR description and let me know if you agree with all of them.