On Sat, Jul 15, 2023 at 6:38 AM Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> wrote: > > On 7.07.2023 18:08, Rob Clark wrote: > > On Thu, Jul 6, 2023 at 5:25 PM Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> wrote: > >> > >> Apart from all these comments, I don't really see the point of this patch, > >> other than trying to tie together Qualcomm's almost-meaningless chipids on > >> a7xx into the picture.. > >> > >> Since they can't even be read back from the hardware, I don't think trying > >> to force them into the upstream kernel makes any sense. > > > > Sure, we _could_ pick our own arbitrary identifiers, we don't have to > > align with kgsl. But that would be a super huge PITA for mesa, which > > has support for both kernels. > Perhaps I'm biased towards keeping this kind of stuff out of the kernel, > but I'd say that Linux should decide on one logical path. > > In between us starting this discussion, Qualcomm managed to introduce > yet another way of deciding what GPU is present on the system in their > downstream driver[1]. We're at like 5 now. Do we wanna keep up each time? > New ID rework for A8xx when that comes out one day? [snip] > [1] they now read parts of socinfo from smem and decide the CHIPID and > speedbin based on that, but it's not available on most existing SoCs, > that was thrown in with SOCID v17 This is actually exactly what we want.. something that we can read from hw/fw and that blob userspace also uses (so we don't have to worry about qc forgetting to change the id, etc) BR, -R
