| Message ID | cover.1519380923.git.viresh.kumar@linaro.org |
|---|---|
| Headers | show |
| Series | drivers: Boot Constraint core | expand |
On 23-02-18, 15:53, Viresh Kumar wrote: > Hi Greg, > > The V7 version incorporates the organizational changes suggested by Olof > earlier. Everything else is same otherwise. > > I have tested the Hisilicon patches (again) on hikey 9660 board, IMX stuff was > earlier tested by Sascha (Pengutronix) on i.MX6 and Qualcomm stuff was earlier > tested by Rajendra (Qualcomm) on Dragonboard 410C (This required some more > patches related to display driver which Rajendra should be sending separately > later on). Hi Greg, Are you going to pick this one for 4.17 ? Thanks. -- viresh
On 23-02-18, 15:53, Viresh Kumar wrote: > Problem statement: > > Some devices are powered ON by the bootloader before the bootloader > handovers control to Linux. It maybe important for some of those devices > to keep working until the time a Linux device driver probes the device > and reconfigure its resources. > > A typical example of that can be the LCD controller, which is used by > the bootloaders to show image(s) while the platform is booting into > Linux. The LCD controller can be using some resources, like clk, > regulators, etc, that are shared between several devices. These shared > resources should be configured to satisfy need of all the users. If > another device's (X) driver gets probed before the LCD controller driver > in this case, then it may end up disabling or reconfiguring these > resources to ranges satisfying the current users (only device X) and > that can make the LCD screen unstable. > > Another case can be a debug serial port enabled from the bootloader. > > Of course we can have more complex cases where the same resource is > getting used by two devices while the kernel boots and the order in > which devices get probed wouldn't matter as the other device will surely > break then. And we have a _real_ use case for this complex scenario as well. Georgi (cc'd) is currently working[1] on implementing generic support for the interconnect bus, which tries to play with the bandwidth of the bus based on how much are the requirements from different parts of the SoC. The 4th version was posted recently by him, and things are looking good/positive. The bootloader configures the interconnect to provide sufficient bandwidth for all the devices which are used during boot, few of them are the CPUs, serial and the LCD controller. As the kernel starts taking control of things, the drivers being probed start putting their requirements on the interconnect bus. Because the interconnect doesn't have any representation from the devices which are not yet initialized by the kernel, the interconnect core incorrectly reduces the bandwidth of the bus to a level unacceptable to the devices running currently, like the CPUs and this makes kernel boot awfully slow. This is not an ordering problem as no matter which device we probe first, we are going to break something else. Georgi already tried using the boot constraint patches to solve this complex problem, and its a perfect fit. -- viresh [1] http://lkml.kernel.org/r/20180309210958.16672-1-georgi.djakov@linaro.org
On Thu, Mar 22, 2018 at 09:26:06AM +0800, Viresh Kumar wrote: > On 23-02-18, 15:53, Viresh Kumar wrote: > > Problem statement: > > > > Some devices are powered ON by the bootloader before the bootloader > > handovers control to Linux. It maybe important for some of those devices > > to keep working until the time a Linux device driver probes the device > > and reconfigure its resources. > > > > A typical example of that can be the LCD controller, which is used by > > the bootloaders to show image(s) while the platform is booting into > > Linux. The LCD controller can be using some resources, like clk, > > regulators, etc, that are shared between several devices. These shared > > resources should be configured to satisfy need of all the users. If > > another device's (X) driver gets probed before the LCD controller driver > > in this case, then it may end up disabling or reconfiguring these > > resources to ranges satisfying the current users (only device X) and > > that can make the LCD screen unstable. > > > > Another case can be a debug serial port enabled from the bootloader. > > > > Of course we can have more complex cases where the same resource is > > getting used by two devices while the kernel boots and the order in > > which devices get probed wouldn't matter as the other device will surely > > break then. > > And we have a _real_ use case for this complex scenario as well. > > Georgi (cc'd) is currently working[1] on implementing generic support for the > interconnect bus, which tries to play with the bandwidth of the bus based on how > much are the requirements from different parts of the SoC. The 4th version was > posted recently by him, and things are looking good/positive. > > The bootloader configures the interconnect to provide sufficient bandwidth for > all the devices which are used during boot, few of them are the CPUs, serial and > the LCD controller. As the kernel starts taking control of things, the drivers > being probed start putting their requirements on the interconnect bus. Because > the interconnect doesn't have any representation from the devices which are not > yet initialized by the kernel, the interconnect core incorrectly reduces the > bandwidth of the bus to a level unacceptable to the devices running currently, > like the CPUs and this makes kernel boot awfully slow. This is not an ordering > problem as no matter which device we probe first, we are going to break > something else. > > Georgi already tried using the boot constraint patches to solve this complex > problem, and its a perfect fit. I'm delaying this as I still don't see that "perfect fit" yet. If there are add-on patches that take better advantage of this, great, let's see those, but right now, it feels like you are the only one wanting this. And the increased complexity overall seems not really worth it yet :( greg k-h
Hi Greg and Viresh, On 03/23/2018 05:04 PM, Greg Kroah-Hartman wrote: > On Thu, Mar 22, 2018 at 09:26:06AM +0800, Viresh Kumar wrote: >> On 23-02-18, 15:53, Viresh Kumar wrote: >>> Problem statement: >>> >>> Some devices are powered ON by the bootloader before the bootloader >>> handovers control to Linux. It maybe important for some of those devices >>> to keep working until the time a Linux device driver probes the device >>> and reconfigure its resources. >>> >>> A typical example of that can be the LCD controller, which is used by >>> the bootloaders to show image(s) while the platform is booting into >>> Linux. The LCD controller can be using some resources, like clk, >>> regulators, etc, that are shared between several devices. These shared >>> resources should be configured to satisfy need of all the users. If >>> another device's (X) driver gets probed before the LCD controller driver >>> in this case, then it may end up disabling or reconfiguring these >>> resources to ranges satisfying the current users (only device X) and >>> that can make the LCD screen unstable. >>> >>> Another case can be a debug serial port enabled from the bootloader. >>> >>> Of course we can have more complex cases where the same resource is >>> getting used by two devices while the kernel boots and the order in >>> which devices get probed wouldn't matter as the other device will surely >>> break then. >> >> And we have a _real_ use case for this complex scenario as well. >> >> Georgi (cc'd) is currently working[1] on implementing generic support for the >> interconnect bus, which tries to play with the bandwidth of the bus based on how >> much are the requirements from different parts of the SoC. The 4th version was >> posted recently by him, and things are looking good/positive. >> >> The bootloader configures the interconnect to provide sufficient bandwidth for >> all the devices which are used during boot, few of them are the CPUs, serial and >> the LCD controller. As the kernel starts taking control of things, the drivers >> being probed start putting their requirements on the interconnect bus. Because >> the interconnect doesn't have any representation from the devices which are not >> yet initialized by the kernel, the interconnect core incorrectly reduces the >> bandwidth of the bus to a level unacceptable to the devices running currently, >> like the CPUs and this makes kernel boot awfully slow. This is not an ordering >> problem as no matter which device we probe first, we are going to break >> something else. The interconnect core takes requests from consumer drivers for their bandwidth needs and configures the hardware to keep the lowest possible power profile. I think that the boot constraint patches would be useful to make a board run at maximum performance during boot, until all consumer drivers are probed and all bandwidth requests are taken into account. >> Georgi already tried using the boot constraint patches to solve this complex >> problem, and its a perfect fit. These patches solve a common problem for different subsystems, so it makes sense to handle it into the driver core, instead of leaving each subsystem to do their own hacks. > I'm delaying this as I still don't see that "perfect fit" yet. If there > are add-on patches that take better advantage of this, great, let's see > those, but right now, it feels like you are the only one wanting this. > And the increased complexity overall seems not really worth it yet :( The interconnect code is still under review, but on the next submission i will include a patch to make use of the boot constraints, so that we hopefully move this forward. Thanks, Georgi
Hi Georgi, Am Freitag, den 30.03.2018, 18:24 +0300 schrieb Georgi Djakov: [...] > The interconnect core takes requests from consumer drivers for their > bandwidth needs and configures the hardware to keep the lowest possible > power profile. I think that the boot constraint patches would be useful > to make a board run at maximum performance during boot, until all > consumer drivers are probed and all bandwidth requests are taken into > account. Can you please describe how this bootconstraints core integration is simpler than a "run things at max performance until late kernel init", which could be triggered by a simple initcall similar to what is done for clocks and regulators? To me the bootcontraints stuff looks like a fairly complex solution and your use-case doesn't even sound like you strictly want to keep a bootloader configuration, but rather run things at max performance until you are reasonably sure that you got all the necessary bandwidth requests. Regards, Lucas
On 10-04-18, 15:40, Lucas Stach wrote: > Can you please describe how this bootconstraints core integration is > simpler than a "run things at max performance until late kernel init", > which could be triggered by a simple initcall similar to what is done > for clocks and regulators? > > To me the bootcontraints stuff looks like a fairly complex solution and > your use-case doesn't even sound like you strictly want to keep a > bootloader configuration, but rather run things at max performance > until you are reasonably sure that you got all the necessary bandwidth > requests. What about this case where drivers of some of the devices used during boot are built as modules, like display, HDMI, etc., and would be available only after userspace is up. We need to take care of their bandwidth requirements as well, until the time their driver comes up. -- viresh