[Public] +Grzegorz who Jan mentioned is taking over some of this. +Vijendar for sound/soc/amd > -----Original Message----- > From: Borislav Petkov <bp@xxxxxxxxx> > Sent: Monday, January 9, 2023 05:12 > To: Jan Dąbroś <jsd@xxxxxxxxxxxx>; Limonciello, Mario > <Mario.Limonciello@xxxxxxx> > Cc: Borislav Petkov <bp@xxxxxxx>; Hans de Goede > <hdegoede@xxxxxxxxxx>; Andy Shevchenko > <andriy.shevchenko@xxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; linux- > i2c@xxxxxxxxxxxxxxx; jarkko.nikula@xxxxxxxxxxxxxxx; wsa@xxxxxxxxxx; > rrangel@xxxxxxxxxxxx; upstream@xxxxxxxxxxxx; M K, Muralidhara > <Muralidhara.MK@xxxxxxx>; Chatradhi, Naveen Krishna > <NaveenKrishna.Chatradhi@xxxxxxx>; Ghannam, Yazen > <Yazen.Ghannam@xxxxxxx> > Subject: Re: [PATCH -next 1/2] i2c: designware: Switch from using MMIO > access to SMN access > > Another forgotten thread... ;-\ > > + Yazen. > > On Fri, Oct 28, 2022 at 10:32:20AM +0200, Jan Dąbroś wrote: > > So to summarize everything, I would like below order: > > > > acpi_init() -> init_amd_nbs() -> dw_i2c_init_driver() > > ^--subsys_initcall ^--fs_initicall ^--subsys_initcall > > > > but I don't have a clear idea how to achieve this in a clean way. > > > > The only option seems to be to register init_amd_nbs() as > > subsys_initcall and force it to execute after acpi_init() and before > > dw_i2c_init_drvier(). However the only option (if I'm not mistaken) > > for forcing order on initcalls placed on the same level is to modify > > their order within Makefile, so that linker puts them in the "init" > > section with addresses in desired order. This doesn't seem to be an > > option for upstream. > > > > Do you have any clue how to solve this problem? > > Make init_amd_nbs() arch_initcall_sync() so that it executes after PCI init. > > By the time subsys_initcalls come, they'll have all the facilities they need, > prepared for them... > > Along with big fat comment why. > > Btw, note to myself as I keep wondering about it each time: the sync calls > come > after the regular ones, in link order if you look at preprocessed linker script > arch/x86/kernel/vmlinux.lds: > > __initcall_start = .; > KEEP(*(.initcallearly.init)) __initcall0_start = .; > KEEP(*(.initcall0.init)) KEEP(*(.initcall0s.init)) __initcall1_start = .; > KEEP(*(.initcall1.init)) KEEP(*(.initcall1s.init)) __initcall2_start = .; > KEEP(*(.initcall2.init)) KEEP(*(.initcall2s.init)) __initcall3_start = .; > KEEP(*(.initcall3.init)) KEEP(*(.initcall3s.init)) __initcall4_start = .; > KEEP(*(.initcall4.init)) KEEP(*(.initcall4s.init)) __initcall5_start = .; > KEEP(*(.initcall5.init)) KEEP(*(.initcall5s.init)) __initcallrootfs_start = .; > KEEP(*(.initcallrootfs.init)) KEEP(*(.initcallrootfss.init)) __initcall6_start = .; > KEEP(*(.initcall6.init)) KEEP(*(.initcall6s.init)) __initcall7_start = .; > KEEP(*(.initcall7.init)) KEEP(*(.initcall7s.init)) __initcall_end = .; > > Mario, is that something that would work for what you wanna do too? > Yeah I guess as long as the I2C init comes after arch_initcall_sync this should work. If it works for Jan & Grzegorz, then I think we can also adjust the "effectively local copy" of amd_smn_write/amd_smn_read that got added into sound/soc/amd to use this too now and it should work for what I wanted to do too. Jan/Grzegorz can you please have a try on your system and comment? > Thx. > > -- > Regards/Gruss, > Boris. > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeo > ple.kernel.org%2Ftglx%2Fnotes-about- > netiquette&data=05%7C01%7Cmario.limonciello%40amd.com%7C56e3280fc > 1cd416bd7ae08daf23262d0%7C3dd8961fe4884e608e11a82d994e183d%7C0% > 7C0%7C638088595520420341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 > C%7C%7C&sdata=9t7J4u3W0kxXu717gzIyBJpAvt6YtQOKqtK9AcjWOvg%3D&r > eserved=0
