I think you cannot remove blocks and their routing during runtime. But you can route the SPI outputs through a MUX, and the switch during runtime between the SPI pins and a control register.
That seems different than the PSoC4 Architecture document TRM_001-85634_0C. Looking at Top Level Architecture drawing (Figure 1-2), it shows the High Speed I/O Matrix with the DSI and GPIOs in parallel. Using that drawing, it seems that even if I completely configure the SCB to be a SPI and P0 and P0 to outputs, I should still be able to use the HSIOM to switch back and forth between GPIO and SPI functions. Setting the HSIOM_PORT_SEL0 register to 0 says "0x0: GPIO: Pin is regular firmware-controlled I/O or connected to dedicated hardware block (Opamp inputs/outputs, SARMUX, SAR reference, LPCOMP inputs) .See the device datasheet for details. Proper configurations of corresponding GPIO_PRT registers are required to use dedicated hardware
The MUX that you mentioned...could that be internal to the chip, or would it need to be an external mux?
I didn't realize you were talking about the SCB SPI block. For that the pins are hard-routed to the physical pins, so you cannot use an internal mux (which you could use with an UDB SPI block).
Yes, you can meddle with the internal routing registers. But doing so relies on that the routing never changes 8which is can during a recompile, or a new Creator version). Its also not really documented.
You could try whether you can make a copy of the SCB SPI component, and can add a mux component between the SCB block and the output pins (I don't think it will work, but it is worth a try).
When in doubt, raise a support case with Cpyress and ask them directly - they should know best. (and please come back and tell the solution here...)
By changing the HSIOM register it should be possible to reclaim the pins as GPIO. I think you may have to change the drive mode of the pins. The MOSI pins may be in high impedance digital( I am expecting your psoc is slave), which you should change to strong drive. The drive mode change API can be found in SPI_1_mosi_s.c file. And while writing values on HSIOM register make sure that you are not changing any bits not corresponding to the pin you need.
I tried making changes to the HSIOM register, and it didn't work. (i.e. masking bits I was interested in, and setting to the correct value as GPIO inputs). The SPI that I am using is a SPI master (uses the SPI data bits to drive neopixels). In a second case I use those pins as inputs. (Read a sector in flash to determine whether it is a SPI master, or GPIO inputs at initialization time, it never switches between these two cases). After exhausting all fo the different possibilities of the HSIOM register, I've decided to try and fix this at a later date by maybe creating a UDB SPI block as suggested by hli. I need a deep FIFO because that provides me with the interrupt latency that I need. When I figure it out, I will post back a solution.