While this might be closer to the optimum for 60Hz, it would still try to pump data at around 136MHz. DP doesn't use a variable pixel clock on the physical layer. It's using either 1.62GHz (reduced bit-rate, RBR) or 2.7GHz (high bit-rate, HBR). Or (not supported by this code and likely not by the SoC) 5.4GHz (HBR2) or 8.1GHz (HBR3). Data is encoded with 10 bits per 8 bits of payload, so for a single lane at HBR you can only get up to 2.7GHz / 10 * 8 / 18 = 120MHz.
Okay, you clearly know more than me. ;) All I know is that the pixel clock is supposed to match the value in the EDID descriptor, and that we had problems with jitter on it (although that might have just been HDMI). But I'm not sure how exactly it is used... if you say the eDP clock is constant, maybe it's just being used internally on the SoC (in the connection between Video Output Processor and the eDP block)?
If it relates to what I know from Intel graphics, M/N gives the ratio how much of the bandwidth on the lanes is used for actual picture data.
I think I found it now. We're passing CALCULATED_M to that function, so it's using the second path (which only initializes N to 0x8000). It clears the FIX_M_VID bit which I think means that M is being calculated automatically by the controller.
The other lanes aren't routed on the board. This isn't going to help.
To be clear, I meant to override it with 1. As far as I understand the code, this should configure both sink and source to use only a single lane.
Oh, okay, yes, I guess that could help. Although it sounds(?) like at that point you're essentially ignoring the EDID and just trying to make up your own video mode, so it seems more like a shot in the dark.