The LDS Bank conflicts are only related to within a workgroup. Any workgroup scheduled on a CU will have a part of LDS reserved for it. If the LDS requirements of workgroups is more, then less number of workgroups can be scheduled on a CU.
Section 18.104.22.168 In addition to registers, shared memory can also serve to limit the active
wavefronts/compute unit. Each compute unit has 32k of LDS, which is shared
among all active work-groups. LDS is allocated on a per-work-group granularity,
so it is possible (and useful) for multiple wavefronts to share the same local
memory allocation. However, large LDS allocations eventually limits the number
of workgroups that can be active
Bank conflicts are a half-wavefront issue problem, not a workgroup or even full wavefront problem. The way it works is that every cycle 16 lanes of requests are made by both one of SIMD 0 and 1 and one of or SIMD 2 and 3 in the CU. Those requests are serviced as 32-lanes per cycle by the LDS interface and hence conflicts (I think) can occur accross those 32 lanes and 32 banks.
Of course, bank conflicts that delay one wave can affect another wave on another SIMD unit in the CU because it creates a pipeline bubble.