Messages in this thread | | | Subject | Re: [PATCH V7 00/13] drivers: Boot Constraint core | From | Georgi Djakov <> | Date | Fri, 30 Mar 2018 18:24:25 +0300 |
| |
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
| |