On Thu, Apr 11, 2024 at 08:38:23AM -0700, Bjorn Andersson wrote: > On Thu, Apr 11, 2024 at 06:31:08AM +0300, Dmitry Baryshkov wrote: > > On Thu, 11 Apr 2024 at 06:19, Bjorn Andersson <andersson@xxxxxxxxxx> wrote: > > > > > > On Wed, Apr 10, 2024 at 01:12:15AM +0300, Dmitry Baryshkov wrote: > > > > On Tue, 9 Apr 2024 at 23:02, Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> wrote: > > > > > On 4/9/24 20:27, Dmitry Baryshkov wrote: > > > > > > Enable CONFIG_INTERCONNECT_QCOM_SM6115 as module to enable the > > > > > > interconnect driver for the SoC used on Qualcomm Robotics RB2 board. > > > > > > > > > > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > > > > > > --- > > > > > > > > > > =y for console? > > > > > > > > I think with pinctrl being set to m it won't reach the console anyway. > > > > And earlycon should work w/o ICC driver if I'm not mistaken. > > > > > > > > Several other Qualcomm platforms also have interconnects built as > > > > modules in defconfig. I really suppose that we should move all such > > > > drivers to =m and force using initrd. But this sounds like a topic for > > > > plumbers. > > > > > > > > > > That currently does not work very well, because if you probe defer the > > > UART into the future e.g. systemd will open /dev/console before it > > > exist - with no interest in reopening that later. > > > > > > So, if you care about UART, that is suboptimal. > > > > > > Resolve this, and I'd be happy to see them all go =m. > > > > Doesn't /dev/console handle switching between earlycon and actual > > console? I'll take a look at some point in the future. > > > > It does not, selection happens at open(). So user space need to reopen > /dev/console once the console has been updated. > > > But I can't help but notice that currently we have 5 ICC drivers built > > as modules (out of 21 mentioned in the defconfig). Should we fix them > > too? > > I reviewed this a while back, at which time none of these had > interconnects specified for their UART device. > > The lack of icc is likely a problem at some point, in which case this > would need to be updated. But at this time (at the time I looked at it), > there was no problem to motivate such change with. Note that on Android we have no choice but to build the interconnect drivers as modules. Vendor support is added as modules loaded on the vendor-agnostic GKI kernel. We don't have issues with earlycon there. That being said, I'm not really an expert in how the earlycon or serial drivers work. >From a HW perspective, all the busses required for the serial UART are enabled by default from bootloaders. So, no explicit voting for them should be necessary for early serial logs.
