Populate conn_state->max_bpc with something sensible from the start.
Otherwise it's possible that we get to compute_sink_pipe_bpp() with
max_bpc==0.

The specific scenario goes as follows:
1. Initial connector state allocated with max_bpc==0
2. Trigger a modeset on the crtc feeding the connector, without
   actually adding the connector to the commit
3. drm_atomic_connector_check() is skipped because the
   connector has not yet been added, hence conn_state->max_bpc
   retains its current value
4. drm_atomic_helper_check_modeset() ->
   drm_atomic_add_affected_connectors() -> the connector
   is now part of the commit
5. compute_baseline_pipe_bpp() -> MISSING_CASE(max_bpc==0)

Note that pipe_bpp itself may not be populated on pre-g4x machines,
in which case we just fall back to max_bpc==8 and let .compute_config()
limit the resulting pipe_bpp further if necessary.

Cc: Daniel Vetter <daniel@ffwll.ch>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210216160035.4780-1-ville.syrjala@linux.intel.comTested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>