Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1249439

Re: [GIT PULL] On-demand device probing

From Rob Clark <robdclark@gmail.com>
Newsgroups linux.kernel
Subject Re: [GIT PULL] On-demand device probing
Date 2015-10-17 21:50 +0200
Message-ID <qkFEm-7j6-5@gated-at.bofh.it> (permalink)
References (5 earlier) <qkCZP-3ox-7@gated-at.bofh.it> <qkDVU-4Kw-17@gated-at.bofh.it> <qkEoW-5xv-1@gated-at.bofh.it> <qkEIh-5Va-3@gated-at.bofh.it> <qkF1D-6za-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Sat, Oct 17, 2015 at 3:04 PM, Noralf Trønnes <noralf@tronnes.org> wrote:
>
> Den 17.10.2015 20:45, skrev Rob Clark:
>>
>> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>>>
>>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>>>>
>>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>>>> <gregkh@linuxfoundation.org> wrote:
>>>>>>
>>>>>> I'm guessing the time is a matter of probing and undoing the probes
>>>>>> rather than slow h/w. We could maybe improve things by making sure
>>>>>> drivers move what they defer on to the beginning of probe, but that
>>>>>> seems like a horrible, fragile hack.
>>>>>
>>>>> How can calling probe and failing cause 2 seconds?  How many different
>>>>> probe calls are failing here?  Again, a boot log graph would be great
>>>>> to
>>>>> see as it will show the root cause, not just guessing at this.
>>>>
>>>>
>>>> just fwiw, but when you have a driver that depends on several other
>>>> drivers (which in turn depend on other drivers and so on), the amount
>>>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>>>> probably is some room to optimize by juggling around order drivers do
>>>> things in probe.  But that doesn't solve the fundamental problem with
>>>> the current state, about probe order having no clue about
>>>> dependencies..
>>>
>>> I can imagine it is a lot of iterations, but how long does it really
>>> take?  How many different devices are involved that it takes multiple
>>> loops in order to finally work out the correct order?  Where is the time
>>> delays here, just calling probe() and having it instantly return
>>> shouldn't take all that long.
>>
>> offhand, I think the dependencies go at *least* three levels deep..
>> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
>> get all the way through requesting it's various different
>> regulators/clks/gpios.  I hadn't really paid attention to how many
>> tries the drivers I depend on go through.  (Of those, I take clks from
>> two different clk drivers (which have dependency on a 3rd clk driver),
>> and regulators and gpio's come from at least two places, which in turn
>> have dependencies on clks, etc.)  I don't have really good hard
>> numbers handy (since my observations of this are w/ console over uart
>> which effects timings, and so I see it taking much longer than 2sec)..
>> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
>> me.
>>
>> I can try to get better #'s... I should have my kernel hat on at least
>> some of the time next week.. but the 2sec figure didn't seem
>> unrealistic to me.
>
>
> Are you saying that the total boot time is increased by 2 sec due to
> deferred probing, or that display initialization is happening 2 sec
> after it's first try?
>

The 2sec figure was from Tomeu, but I guess display should be probed
in first pass through list of devices (and ofc deferring the first
time), I'll say "probably both"..

BR,
-R
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-14 10:40 +0200
  Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-14 11:30 +0200
    [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-15 13:50 +0200
      Re: [GIT PULL] On-demand device probing Olof Johansson <olof@lixom.net> - 2015-10-16 23:30 +0200
        Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-17 17:30 +0200
  Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 09:00 +0200
    Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-17 17:10 +0200
      Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 17:50 +0200
        Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-17 18:30 +0200
          Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 19:00 +0200
            Re: [GIT PULL] On-demand device probing Rob Clark <robdclark@gmail.com> - 2015-10-17 20:00 +0200
              Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 20:30 +0200
                Re: [GIT PULL] On-demand device probing Rob Clark <robdclark@gmail.com> - 2015-10-17 20:50 +0200
                Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 21:00 +0200
                Re: [GIT PULL] On-demand device probing Rob Clark <robdclark@gmail.com> - 2015-10-17 21:40 +0200
                Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 22:30 +0200
                Re: [GIT PULL] On-demand device probing Noralf Trønnes <noralf@tronnes.org> - 2015-10-17 21:10 +0200
                Re: [GIT PULL] On-demand device probing Rob Clark <robdclark@gmail.com> - 2015-10-17 21:50 +0200

csiph-web