Restructured the signal connections for the LCD module and the pick/hold to the HPS

SPI FUNCTION SUPPORTS UP TO FOUR SLAVE SELECT SIGNALS - TWO BORROWED

The SPI capability in the Hard Processor System (HPS) side of the chip allows me to set any of four signals intended as slave select for the SPI protocol. I had been using the first two slave select lines to activate the LCD panel and touch screen chips respectively. 

Having the other two gives me a simpler way to control two more signals related to the LCD module - the reset line and the command/data signal. I set these to the other two slave select lines. By simply setting or clearing bits in a given location in processor memory, mapped to the SPI master 0 control register SER, lets me turn those two signals on and off.

The backlight wire is simply going to be wired permanently on, thus there remains one pin from the LCD module not yet connected to the HPS side and one other signal that needs to be routed to that same side.  These were connected as interrupt requests 

DISCOVERED THAT I COULD GET RID OF THE INTERRUPTS

Having read the example code from Waveshare I see that I could simply poll the interrupt signal from the touch controller instead of setting up an interrupt handler and watch for the flag to be set in my mainline code. I don't really need to be doing anything while the User Interface (UI) is active except waiting for touches on buttons. 

There is a single available GPIO pin natively wired to the HPS side - on the LTC connector. I will hook that to the touch controllers interrupt request pin, then poll it in my loop to decide when there is a touch on a button on my UI. Once the drive is switched on and I have a virtual disk cartridge file activated in the SDRAM, I switch drive_ram on and stop paying attention to the UI. 

This opened up a clever way to make use of one more connection from the SPI logic. The SPI component on the chip is able to jointly control slaves with other SPI masters, making use of a contention signal. That is, if one of the other masters is activating a slave select and switching on its clock, it sends a contention signal that is an input to my SPI master. The master turns off its outputs, thereby allowing the other master to complete its transaction. We will call this SPIM0_ss_in_n and make use of that line.

The final _n in the name indicates it is inverted polarity, thus a 0 on the signal will force our SPI master to disable its outputs while a 1 on the signal allows our master to operate as it wishes. The signal from the disk drive, -pick/hold, is an inverted signal such that when the drive tries to lower the heads onto the platter, the signal switches to a value of 0. 

This fits my needs perfectly. When the drive is not active, -pick/hold is emitting 1, hooked to SPIM0_ss_in_n and that allows the user interface to communicate with the LCD panel and touch screen. Assuming we have selected and loaded a virtual cartridge file, when the -pick/hold signal goes to 0, it also blocks the SPI master. 

We can examine a bit on one of the SPI control registers that indicates we have seen the SPIM0_ss_in_n  signal go to 0 (i.e. -pick/hold went to 0 because the drive spun up and tried to load the heads). If we see that, we send the command to the logic in the Field Programmable Gate Array (FPGA) side of the chip to switch on drive_ram state. 

The result of these actions would be to illuminate the Ready lamp on the disk drive and allow the disk controller in the IBM 1130 to issue disk access commands to the drive. Later, when the drive is switched off by the operator, -pick/hold reverts to 1 and allows the UI to resume operation through signal SPIM0_ss_in_n. 

With these simplifications, I can drop the use of interrupt request lines and therefore have no need to set up interrupt handlers in Linux for my application. Everything I need to do from the HPS side application is controlled by reading and writing from the memory mapped control registers, accessible in user mode.