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

Groups > linux.kernel > #1220117 > unrolled thread

[PATCH v4 0/22] On-demand device probing

Back to article view | Back to linux.kernel

Contents

  [PATCH v4 0/22] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:30 +0200
    [PATCH v4 13/22] backlight: Probe backlight devices on demand Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:30 +0200
    [PATCH v4 05/22] gpio: Probe GPIO drivers on demand Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:30 +0200
    [PATCH v4 03/22] of/platform: Point to struct device from device node Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:30 +0200
    [PATCH v4 09/22] drm: Probe panels on demand Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:30 +0200
    [PATCH v4 20/22] driver core: Allow deferring probes until late init Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:30 +0200
      Re: [PATCH v4 20/22] driver core: Allow deferring probes until late  init Mark Brown <broonie@kernel.org> - 2015-09-11 14:20 +0200
        Re: [PATCH v4 20/22] driver core: Allow deferring probes until late init Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-14 11:10 +0200
    [PATCH v4 14/22] usb: phy: Probe phy devices on demand Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:30 +0200
    [PATCH v4 15/22] clk: Probe clk providers on demand Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:30 +0200
    [PATCH v4 22/22] of/platform: Defer probes of registered devices Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:30 +0200
    [PATCH v4 16/22] pinctrl: Probe pinctrl devices on demand Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:30 +0200
    [PATCH v4 21/22] driver core: Start processing deferred probes earlier Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:30 +0200
      Re: [PATCH v4 21/22] driver core: Start processing deferred probes  earlier Mark Brown <broonie@kernel.org> - 2015-09-11 14:30 +0200
        Re: [PATCH v4 21/22] driver core: Start processing deferred probes earlier Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-15 15:20 +0200
    [PATCH v4 07/22] regulator: core: Reduce critical area in _regulator_get Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:40 +0200
      Re: [PATCH v4 07/22] regulator: core: Reduce critical area in  _regulator_get Mark Brown <broonie@kernel.org> - 2015-09-11 14:20 +0200
    [PATCH v4 11/22] i2c: core: Probe i2c adapters and devices on demand Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:40 +0200
    [PATCH v4 12/22] pwm: Probe PWM chip devices on demand Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:40 +0200
    [PATCH v4 02/22] ARM: amba: Move reading of periphid to pre_probe() Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:40 +0200
    [PATCH v4 01/22] driver core: Add pre_probe callback to bus_type Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:40 +0200
      Re: [PATCH v4 01/22] driver core: Add pre_probe callback to bus_type Mark Brown <broonie@kernel.org> - 2015-09-11 14:10 +0200
    [PATCH v4 10/22] drm/tegra: Probe dpaux devices on demand Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:40 +0200
    Re: [PATCH v4 0/22] On-demand device probing Rob Herring <robherring2@gmail.com> - 2015-09-07 23:00 +0200
      Re: [PATCH v4 0/22] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-08 09:40 +0200
        Re: [PATCH v4 0/22] On-demand device probing Rob Herring <robh@kernel.org> - 2015-09-09 07:50 +0200
          Re: [PATCH v4 0/22] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-09 11:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1220139 — [PATCH v4 01/22] driver core: Add pre_probe callback to bus_type

Some buses (eg. AMBA) need access to some HW resources (it may need a
clock to be enabled so a device ID can be read) before a device can be
matched to a driver.

The pre_probe callback allows the device-driver core to request the bus
to perform this initialization and can defer the probe if any of the
resources needed are missing.

This gives us more flexibility when setting the order in which devices
are probed because the resources needed to get the matching information
don't need to be available by the time that the bus devices are
registered.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/base/dd.c      | 24 ++++++++++++++++++++++++
 include/linux/device.h |  4 ++++
 2 files changed, 28 insertions(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index be0eb4639128..faf60bfc46b3 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -544,6 +544,17 @@ static int __device_attach(struct device *dev, bool allow_async)
 	int ret = 0;
 
 	device_lock(dev);
+
+	if (dev->bus && dev->bus->pre_probe) {
+		ret = dev->bus->pre_probe(dev);
+		if (ret) {
+			if (ret == -EPROBE_DEFER)
+				driver_deferred_probe_add(dev);
+			ret = 0;
+			goto out_unlock;
+		}
+	}
+
 	if (dev->driver) {
 		if (klist_node_attached(&dev->p->knode_driver)) {
 			ret = 1;
@@ -619,6 +630,7 @@ void device_initial_probe(struct device *dev)
 static int __driver_attach(struct device *dev, void *data)
 {
 	struct device_driver *drv = data;
+	int ret;
 
 	/*
 	 * Lock device and try to bind to it. We drop the error
@@ -636,8 +648,20 @@ static int __driver_attach(struct device *dev, void *data)
 	if (dev->parent)	/* Needed for USB */
 		device_lock(dev->parent);
 	device_lock(dev);
+
+	if (dev->bus && dev->bus->pre_probe) {
+		ret = dev->bus->pre_probe(dev);
+		if (ret) {
+			if (ret == -EPROBE_DEFER)
+				driver_deferred_probe_add(dev);
+			goto out;
+		}
+	}
+
 	if (!dev->driver)
 		driver_probe_device(drv, dev);
+
+out:
 	device_unlock(dev);
 	if (dev->parent)
 		device_unlock(dev->parent);
diff --git a/include/linux/device.h b/include/linux/device.h
index 5d7bc6349930..d8be07bc9c3f 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -74,6 +74,9 @@ extern void bus_remove_file(struct bus_type *, struct bus_attribute *);
  *		given device can be handled by the given driver.
  * @uevent:	Called when a device is added, removed, or a few other things
  *		that generate uevents to add the environment variables.
+ * @pre_probe:	Called when a new device or driver is added to this bus, to
+ *		perform any initializations that are needed so the device can
+ *		be matched to a driver.
  * @probe:	Called when a new device or driver add to this bus, and callback
  *		the specific driver's probe to initial the matched device.
  * @remove:	Called when a device removed from this bus.
@@ -113,6 +116,7 @@ struct bus_type {
 
 	int (*match)(struct device *dev, struct device_driver *drv);
 	int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
+	int (*pre_probe)(struct device *dev);
 	int (*probe)(struct device *dev);
 	int (*remove)(struct device *dev);
 	void (*shutdown)(struct device *dev);
-- 
2.4.3

--
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/

[toc] | [prev] | [next] | [standalone]

#1222747 — Re: [PATCH v4 01/22] driver core: Add pre_probe callback to bus_type

[Multipart message — attachments visible in raw view] — view raw

On Mon, Sep 07, 2015 at 02:23:26PM +0200, Tomeu Vizoso wrote:

> +	if (dev->bus && dev->bus->pre_probe) {
> +		ret = dev->bus->pre_probe(dev);
> +		if (ret) {
> +			if (ret == -EPROBE_DEFER)
> +				driver_deferred_probe_add(dev);
> +			ret = 0;
> +			goto out_unlock;
> +		}
> +	}

So if we get an error other than -EPROBE_DEFER we silently ignore it?
That seems surprising and at least worth a comment.

> +	if (dev->bus && dev->bus->pre_probe) {
> +		ret = dev->bus->pre_probe(dev);
> +		if (ret) {
> +			if (ret == -EPROBE_DEFER)
> +				driver_deferred_probe_add(dev);
> +			goto out;
> +		}
> +	}

That's more what I'd expect.

[toc] | [prev] | [next] | [standalone]

#1220144 — [PATCH v4 10/22] drm/tegra: Probe dpaux devices on demand

When looking up a dpaux device through its OF node, probe it if it
hasn't already.

The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/tegra/dpaux.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 224a7dc8e4ed..96a2eec7e020 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -12,6 +12,7 @@
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/of_gpio.h>
+#include <linux/of_device.h>
 #include <linux/platform_device.h>
 #include <linux/reset.h>
 #include <linux/regulator/consumer.h>
@@ -439,6 +440,8 @@ struct tegra_dpaux *tegra_dpaux_find_by_of_node(struct device_node *np)
 {
 	struct tegra_dpaux *dpaux;
 
+	of_device_probe(np);
+
 	mutex_lock(&dpaux_lock);
 
 	list_for_each_entry(dpaux, &dpaux_list, list)
-- 
2.4.3

--
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/

[toc] | [prev] | [next] | [standalone]

#1220395

On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
> Hello,
>
> I have a problem with the panel on my Tegra Chromebook taking longer
> than expected to be ready during boot (Stéphane Marchesin reported what
> is basically the same issue in [0]), and have looked into ordered
> probing as a better way of solving this than moving nodes around in the
> DT or playing with initcall levels and linking order.
>
> While reading the thread [1] that Alexander Holler started with his
> series to make probing order deterministic, it occurred to me that it
> should be possible to achieve the same by probing devices as they are
> referenced by other devices.
>
> This basically reuses the information that is already implicit in the
> probe() implementations, saving us from refactoring existing drivers or
> adding information to DTBs.
>
> During review of v1 of this series Linus Walleij suggested that it
> should be the device driver core to make sure that dependencies are
> ready before probing a device. I gave this idea a try [2] but Mark Brown
> pointed out to the logic duplication between the resource acquisition
> and dependency discovery code paths (though I think it's fairly minor).
>
> To address that code duplication I experimented with Arnd's devm_probe
> [3] concept of having drivers declare their dependencies instead of
> acquiring them during probe, and while it worked [4], I don't think we
> end up winning anything when compared to just probing devices on-demand
> from resource getters.
>
> One remaining objection is to the "sprinkling" of calls to
> of_device_probe() in the resource getters of each subsystem, but I think
> it's the right thing to do given that the storage of resources is
> currently subsystem-specific.
>
> We could avoid the above by moving resource storage into the core, but I
> don't think there's a compelling case for that.
>
> I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
> OMAP SoCs, and these patches were enough to eliminate all the deferred
> probes (except one in PandaBoard because omap_dma_system doesn't have a
> firmware node as of yet).
>
> Have submitted a branch [5] with only these patches on top of thursday's
> linux-next to kernelci.org and I don't see any issues that could be
> caused by them. For some reason it currently has more passes than the
> version of -next it's based on!
>
> With this series I get the kernel to output to the panel in 0.5s,
> instead of 2.8s.
>
> Regards,
>
> Tomeu
>
> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
>
> [1] https://lkml.org/lkml/2014/5/12/452
>
> [2] https://lkml.org/lkml/2015/6/17/305
>
> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689
>
> [4] https://lkml.org/lkml/2015/7/21/441a
>
> [5] https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6
>
> [6] http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/
>
> [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/
>
> Changes in v4:
> - Added bus.pre_probe callback so the probes of Primecell devices can be
>   deferred if their device IDs cannot be yet read because of the clock
>   driver not having probed when they are registered. Maybe this goes
>   overboard and the matching information should be in the DT if there is
>   one.

Seems overboard to me or at least a separate problem. Most clocks have
to be setup before the driver model simply because timers depend on
clocks usually.

Rob
--
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/

[toc] | [prev] | [next] | [standalone]

#1220549

On 7 September 2015 at 22:50, Rob Herring <robherring2@gmail.com> wrote:
> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
>> Hello,
>>
>> I have a problem with the panel on my Tegra Chromebook taking longer
>> than expected to be ready during boot (Stéphane Marchesin reported what
>> is basically the same issue in [0]), and have looked into ordered
>> probing as a better way of solving this than moving nodes around in the
>> DT or playing with initcall levels and linking order.
>>
>> While reading the thread [1] that Alexander Holler started with his
>> series to make probing order deterministic, it occurred to me that it
>> should be possible to achieve the same by probing devices as they are
>> referenced by other devices.
>>
>> This basically reuses the information that is already implicit in the
>> probe() implementations, saving us from refactoring existing drivers or
>> adding information to DTBs.
>>
>> During review of v1 of this series Linus Walleij suggested that it
>> should be the device driver core to make sure that dependencies are
>> ready before probing a device. I gave this idea a try [2] but Mark Brown
>> pointed out to the logic duplication between the resource acquisition
>> and dependency discovery code paths (though I think it's fairly minor).
>>
>> To address that code duplication I experimented with Arnd's devm_probe
>> [3] concept of having drivers declare their dependencies instead of
>> acquiring them during probe, and while it worked [4], I don't think we
>> end up winning anything when compared to just probing devices on-demand
>> from resource getters.
>>
>> One remaining objection is to the "sprinkling" of calls to
>> of_device_probe() in the resource getters of each subsystem, but I think
>> it's the right thing to do given that the storage of resources is
>> currently subsystem-specific.
>>
>> We could avoid the above by moving resource storage into the core, but I
>> don't think there's a compelling case for that.
>>
>> I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
>> OMAP SoCs, and these patches were enough to eliminate all the deferred
>> probes (except one in PandaBoard because omap_dma_system doesn't have a
>> firmware node as of yet).
>>
>> Have submitted a branch [5] with only these patches on top of thursday's
>> linux-next to kernelci.org and I don't see any issues that could be
>> caused by them. For some reason it currently has more passes than the
>> version of -next it's based on!
>>
>> With this series I get the kernel to output to the panel in 0.5s,
>> instead of 2.8s.
>>
>> Regards,
>>
>> Tomeu
>>
>> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
>>
>> [1] https://lkml.org/lkml/2014/5/12/452
>>
>> [2] https://lkml.org/lkml/2015/6/17/305
>>
>> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689
>>
>> [4] https://lkml.org/lkml/2015/7/21/441a
>>
>> [5] https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6
>>
>> [6] http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/
>>
>> [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/
>>
>> Changes in v4:
>> - Added bus.pre_probe callback so the probes of Primecell devices can be
>>   deferred if their device IDs cannot be yet read because of the clock
>>   driver not having probed when they are registered. Maybe this goes
>>   overboard and the matching information should be in the DT if there is
>>   one.
>
> Seems overboard to me or at least a separate problem.

It's a separate problem but this was preventing the series from
working on a few boards.

> Most clocks have
> to be setup before the driver model simply because timers depend on
> clocks usually.

Yes, but in this case the apb clocks for the primecell devices are
implemented in a normal platform driver (vexpress_osc_driver), instead
of using CLK_OF_DECLARE.

Regards,

Tomeu

> Rob
> --
> 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/
--
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/

[toc] | [prev] | [next] | [standalone]

#1221242

On 09/08/2015 02:30 AM, Tomeu Vizoso wrote:
> On 7 September 2015 at 22:50, Rob Herring <robherring2@gmail.com> wrote:
>> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
>>> Hello,
>>>
>>> I have a problem with the panel on my Tegra Chromebook taking longer
>>> than expected to be ready during boot (Stéphane Marchesin reported what
>>> is basically the same issue in [0]), and have looked into ordered
>>> probing as a better way of solving this than moving nodes around in the
>>> DT or playing with initcall levels and linking order.
>>>
>>> While reading the thread [1] that Alexander Holler started with his
>>> series to make probing order deterministic, it occurred to me that it
>>> should be possible to achieve the same by probing devices as they are
>>> referenced by other devices.
>>>
>>> This basically reuses the information that is already implicit in the
>>> probe() implementations, saving us from refactoring existing drivers or
>>> adding information to DTBs.
>>>
>>> During review of v1 of this series Linus Walleij suggested that it
>>> should be the device driver core to make sure that dependencies are
>>> ready before probing a device. I gave this idea a try [2] but Mark Brown
>>> pointed out to the logic duplication between the resource acquisition
>>> and dependency discovery code paths (though I think it's fairly minor).
>>>
>>> To address that code duplication I experimented with Arnd's devm_probe
>>> [3] concept of having drivers declare their dependencies instead of
>>> acquiring them during probe, and while it worked [4], I don't think we
>>> end up winning anything when compared to just probing devices on-demand
>>> from resource getters.
>>>
>>> One remaining objection is to the "sprinkling" of calls to
>>> of_device_probe() in the resource getters of each subsystem, but I think
>>> it's the right thing to do given that the storage of resources is
>>> currently subsystem-specific.
>>>
>>> We could avoid the above by moving resource storage into the core, but I
>>> don't think there's a compelling case for that.
>>>
>>> I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
>>> OMAP SoCs, and these patches were enough to eliminate all the deferred
>>> probes (except one in PandaBoard because omap_dma_system doesn't have a
>>> firmware node as of yet).
>>>
>>> Have submitted a branch [5] with only these patches on top of thursday's
>>> linux-next to kernelci.org and I don't see any issues that could be
>>> caused by them. For some reason it currently has more passes than the
>>> version of -next it's based on!
>>>
>>> With this series I get the kernel to output to the panel in 0.5s,
>>> instead of 2.8s.
>>>
>>> Regards,
>>>
>>> Tomeu
>>>
>>> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
>>>
>>> [1] https://lkml.org/lkml/2014/5/12/452
>>>
>>> [2] https://lkml.org/lkml/2015/6/17/305
>>>
>>> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689
>>>
>>> [4] https://lkml.org/lkml/2015/7/21/441a
>>>
>>> [5] https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6
>>>
>>> [6] http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/
>>>
>>> [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/
>>>
>>> Changes in v4:
>>> - Added bus.pre_probe callback so the probes of Primecell devices can be
>>>   deferred if their device IDs cannot be yet read because of the clock
>>>   driver not having probed when they are registered. Maybe this goes
>>>   overboard and the matching information should be in the DT if there is
>>>   one.
>>
>> Seems overboard to me or at least a separate problem.
> 
> It's a separate problem but this was preventing the series from
> working on a few boards.

What is the failure? Not booting? Fixing not working would certainly not
be overboard.

> 
>> Most clocks have
>> to be setup before the driver model simply because timers depend on
>> clocks usually.
> 
> Yes, but in this case the apb clocks for the primecell devices are
> implemented in a normal platform driver (vexpress_osc_driver), instead
> of using CLK_OF_DECLARE.

Okay.

Rob

--
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/

[toc] | [prev] | [next] | [standalone]

#1221346

On 9 September 2015 at 03:33, Rob Herring <robh@kernel.org> wrote:
> On 09/08/2015 02:30 AM, Tomeu Vizoso wrote:
>> On 7 September 2015 at 22:50, Rob Herring <robherring2@gmail.com> wrote:
>>> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
>>>> Hello,
>>>>
>>>> I have a problem with the panel on my Tegra Chromebook taking longer
>>>> than expected to be ready during boot (Stéphane Marchesin reported what
>>>> is basically the same issue in [0]), and have looked into ordered
>>>> probing as a better way of solving this than moving nodes around in the
>>>> DT or playing with initcall levels and linking order.
>>>>
>>>> While reading the thread [1] that Alexander Holler started with his
>>>> series to make probing order deterministic, it occurred to me that it
>>>> should be possible to achieve the same by probing devices as they are
>>>> referenced by other devices.
>>>>
>>>> This basically reuses the information that is already implicit in the
>>>> probe() implementations, saving us from refactoring existing drivers or
>>>> adding information to DTBs.
>>>>
>>>> During review of v1 of this series Linus Walleij suggested that it
>>>> should be the device driver core to make sure that dependencies are
>>>> ready before probing a device. I gave this idea a try [2] but Mark Brown
>>>> pointed out to the logic duplication between the resource acquisition
>>>> and dependency discovery code paths (though I think it's fairly minor).
>>>>
>>>> To address that code duplication I experimented with Arnd's devm_probe
>>>> [3] concept of having drivers declare their dependencies instead of
>>>> acquiring them during probe, and while it worked [4], I don't think we
>>>> end up winning anything when compared to just probing devices on-demand
>>>> from resource getters.
>>>>
>>>> One remaining objection is to the "sprinkling" of calls to
>>>> of_device_probe() in the resource getters of each subsystem, but I think
>>>> it's the right thing to do given that the storage of resources is
>>>> currently subsystem-specific.
>>>>
>>>> We could avoid the above by moving resource storage into the core, but I
>>>> don't think there's a compelling case for that.
>>>>
>>>> I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
>>>> OMAP SoCs, and these patches were enough to eliminate all the deferred
>>>> probes (except one in PandaBoard because omap_dma_system doesn't have a
>>>> firmware node as of yet).
>>>>
>>>> Have submitted a branch [5] with only these patches on top of thursday's
>>>> linux-next to kernelci.org and I don't see any issues that could be
>>>> caused by them. For some reason it currently has more passes than the
>>>> version of -next it's based on!
>>>>
>>>> With this series I get the kernel to output to the panel in 0.5s,
>>>> instead of 2.8s.
>>>>
>>>> Regards,
>>>>
>>>> Tomeu
>>>>
>>>> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
>>>>
>>>> [1] https://lkml.org/lkml/2014/5/12/452
>>>>
>>>> [2] https://lkml.org/lkml/2015/6/17/305
>>>>
>>>> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689
>>>>
>>>> [4] https://lkml.org/lkml/2015/7/21/441a
>>>>
>>>> [5] https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6
>>>>
>>>> [6] http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/
>>>>
>>>> [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/
>>>>
>>>> Changes in v4:
>>>> - Added bus.pre_probe callback so the probes of Primecell devices can be
>>>>   deferred if their device IDs cannot be yet read because of the clock
>>>>   driver not having probed when they are registered. Maybe this goes
>>>>   overboard and the matching information should be in the DT if there is
>>>>   one.
>>>
>>> Seems overboard to me or at least a separate problem.
>>
>> It's a separate problem but this was preventing the series from
>> working on a few boards.
>
> What is the failure? Not booting? Fixing not working would certainly not
> be overboard.

On the device I was testing on (qemu's vexpress-a15 machine) the
machine booted and I was able to open a ssh session, but serial was
broken among other AMBA devices:

/memory-controller@2b0a0000
/memory-controller@7ffd0000
/dma@7ffb0000
/smb/motherboard/iofpga@3,00000000/sysctl@020000
/smb/motherboard/iofpga@3,00000000/aaci@040000
/smb/motherboard/iofpga@3,00000000/mmci@050000
/smb/motherboard/iofpga@3,00000000/kmi@060000
/smb/motherboard/iofpga@3,00000000/kmi@070000
/smb/motherboard/iofpga@3,00000000/uart@090000
/smb/motherboard/iofpga@3,00000000/uart@0a0000
/smb/motherboard/iofpga@3,00000000/uart@0b0000
/smb/motherboard/iofpga@3,00000000/uart@0c0000
/smb/motherboard/iofpga@3,00000000/wdt@0f0000
/smb/motherboard/iofpga@3,00000000/timer@110000
/smb/motherboard/iofpga@3,00000000/timer@120000
/smb/motherboard/iofpga@3,00000000/rtc@170000
/smb/motherboard/iofpga@3,00000000/clcd@1f0000

Another way of avoiding this particular problem would be not delaying
the probe of devices in the configuration bus, by doing something like
this:

diff --git a/drivers/bus/vexpress-config.c b/drivers/bus/vexpress-config.c
index 6575c0fe6a4e..eda293869cd3 100644
--- a/drivers/bus/vexpress-config.c
+++ b/drivers/bus/vexpress-config.c
@@ -181,7 +181,7 @@ static int vexpress_config_populate(struct
device_node *node)
        if (WARN_ON(!parent))
                return -ENODEV;

-       return of_platform_populate(node, NULL, NULL, parent);
+       return of_platform_populate_early(node, NULL, NULL, parent);
 }

 static int __init vexpress_config_init(void)

But I think this would be papering over the underlying issue and it
would be better to have proper explicit dependencies.

Regards,

Tomeu

>>> Most clocks have
>>> to be setup before the driver model simply because timers depend on
>>> clocks usually.
>>
>> Yes, but in this case the apb clocks for the primecell devices are
>> implemented in a normal platform driver (vexpress_osc_driver), instead
>> of using CLK_OF_DECLARE.
>
> Okay.
>
> Rob
>
> --
> 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/
--
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/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web