In the datasheets the GPI -> GPO delay is shown as >300us, is there a way to shorten this?
Try MAX96705 : 12-bit data, 116MHz max PCLK, GPI -> GPO delay typically 21us (using packet control channel mode). This part must be used with a MAX96706 or MAX96708 deserializer.
MAX9275, in common with all MAX92xx GMSL1 parts, has GPI -> GPO delay of about 300us. This is because they were designed for slow backward requirements like frame sync for cameras (one pulse every 16-33ms) or interrupt for touch screens (one pulse every 50-100ms), so 300us was fast enough. The MAX96705-11 parts are faster, typically 21us. GMSL2 is even faster and has many more options, but of course it's not available yet (coming soon!) and will be more expensive. There is one way to get MAX9275 delay reduced, use a uC at the deserializer side. Have the uC interrupt be the GPI signal and let the uC send an I2C command to change the state of an IO pin in the MAX9275. I think this method still gives >100us delay.
Try MAX96705 : 12-bit data, 116MHz max PCLK, GPI -> GPO delay typically 21us (using packet control channel mode). This part must be used with a MAX96706 or MAX96708 deserializer.
MAX9275, in common with all MAX92xx GMSL1 parts, has GPI -> GPO delay of about 300us. This is because they were designed for slow backward requirements like frame sync for cameras (one pulse every 16-33ms) or interrupt for touch screens (one pulse every 50-100ms), so 300us was fast enough. The MAX96705-11 parts are faster, typically 21us. GMSL2 is even faster and has many more options, but of course it's not available yet (coming soon!) and will be more expensive. There is one way to get MAX9275 delay reduced, use a uC at the deserializer side. Have the uC interrupt be the GPI signal and let the uC send an I2C command to change the state of an IO pin in the MAX9275. I think this method still gives >100us delay.