All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Wang <sean.wang@mediatek.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	devicetree <devicetree@vger.kernel.org>,
	Bluez mailing list <linux-bluetooth@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Rob Herring <robh@kernel.org>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>, <linux-serial@vger.kernel.org>
Subject: Re: [PATCH v1 2/7] serdev: add dev_pm_domain_attach|detach()
Date: Thu, 26 Apr 2018 13:29:58 +0800	[thread overview]
Message-ID: <1524720598.12322.37.camel@mtkswgap22> (raw)
In-Reply-To: <FD85DED4-589C-4113-8A8B-BC5A39494130@holtmann.org>

On Tue, 2018-04-03 at 12:29 +0200, Marcel Holtmann wrote:
> Hi Sean,
> 
> > In order to open up the required power gate before any operation can be
> > effectively performed over the serial bus between CPU and serdev, it's
> > clearly essential to add common attach functions for PM domains to serdev
> > at the probe phase.
> > 
> > Similarly, the relevant dettach function for the PM domains should be
> > properly and reversely added at the remove phase.
> > 
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Jiri Slaby <jslaby@suse.com>
> > Cc: linux-serial@vger.kernel.org
> > ---
> > drivers/tty/serdev/core.c | 14 +++++++++++++-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> > index df93b72..c93d8ee 100644
> > --- a/drivers/tty/serdev/core.c
> > +++ b/drivers/tty/serdev/core.c
> > @@ -13,6 +13,7 @@
> > #include <linux/module.h>
> > #include <linux/of.h>
> > #include <linux/of_device.h>
> > +#include <linux/pm_domain.h>
> > #include <linux/serdev.h>
> > #include <linux/slab.h>
> > 
> > @@ -330,8 +331,16 @@ EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
> > static int serdev_drv_probe(struct device *dev)
> > {
> > 	const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
> > +	int ret;
> > +
> > +	ret = dev_pm_domain_attach(dev, true);
> > +	if (ret != -EPROBE_DEFER) {
> > +		ret = sdrv->probe(to_serdev_device(dev));
> > +		if (ret)
> > +			dev_pm_domain_detach(dev, true);
> > +	}
> 
> so if this is deferred, when does the serdev device gets probed?
> 

driver probe deferral mechanism is supported in driver core

deferred_probe_initcall makes sure that deferred probing is
delayed until late_initcall time.


Below is a few of word I got from drivers/base/core.c I thought it helps
to understand the mechanism in complete picture

* If a required resource is not available yet, a driver can
request probing to be deferred by returning -EPROBE_DEFER from
its probe hook.

* A driver returning -EPROBE_DEFER causes the device to be added to the
pending list.  A successful driver probe will trigger moving all devices
from the pending to the active list so that the workqueue will
eventually retry them.

> > 
> > -	return sdrv->probe(to_serdev_device(dev));
> > +	return ret;
> > }
> > 
> > static int serdev_drv_remove(struct device *dev)
> > @@ -339,6 +348,9 @@ static int serdev_drv_remove(struct device *dev)
> > 	const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
> > 	if (sdrv->remove)
> > 		sdrv->remove(to_serdev_device(dev));
> > +
> > +	dev_pm_domain_detach(dev, true);
> > +
> > 	return 0;
> > }
> 
> Regards
> 
> Marcel
> 

WARNING: multiple messages have this Message-ID (diff)
From: Sean Wang <sean.wang@mediatek.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	devicetree <devicetree@vger.kernel.org>,
	Bluez mailing list <linux-bluetooth@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	linux-mediatek@lists.infradead.org,
	LKML <linux-kernel@vger.kernel.org>,
	Rob Herring <robh@kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	linux-serial@vger.kernel.org
Subject: Re: [PATCH v1 2/7] serdev: add dev_pm_domain_attach|detach()
Date: Thu, 26 Apr 2018 13:29:58 +0800	[thread overview]
Message-ID: <1524720598.12322.37.camel@mtkswgap22> (raw)
In-Reply-To: <FD85DED4-589C-4113-8A8B-BC5A39494130@holtmann.org>

On Tue, 2018-04-03 at 12:29 +0200, Marcel Holtmann wrote:
> Hi Sean,
> 
> > In order to open up the required power gate before any operation can be
> > effectively performed over the serial bus between CPU and serdev, it's
> > clearly essential to add common attach functions for PM domains to serdev
> > at the probe phase.
> > 
> > Similarly, the relevant dettach function for the PM domains should be
> > properly and reversely added at the remove phase.
> > 
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Jiri Slaby <jslaby@suse.com>
> > Cc: linux-serial@vger.kernel.org
> > ---
> > drivers/tty/serdev/core.c | 14 +++++++++++++-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> > index df93b72..c93d8ee 100644
> > --- a/drivers/tty/serdev/core.c
> > +++ b/drivers/tty/serdev/core.c
> > @@ -13,6 +13,7 @@
> > #include <linux/module.h>
> > #include <linux/of.h>
> > #include <linux/of_device.h>
> > +#include <linux/pm_domain.h>
> > #include <linux/serdev.h>
> > #include <linux/slab.h>
> > 
> > @@ -330,8 +331,16 @@ EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
> > static int serdev_drv_probe(struct device *dev)
> > {
> > 	const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
> > +	int ret;
> > +
> > +	ret = dev_pm_domain_attach(dev, true);
> > +	if (ret != -EPROBE_DEFER) {
> > +		ret = sdrv->probe(to_serdev_device(dev));
> > +		if (ret)
> > +			dev_pm_domain_detach(dev, true);
> > +	}
> 
> so if this is deferred, when does the serdev device gets probed?
> 

driver probe deferral mechanism is supported in driver core

deferred_probe_initcall makes sure that deferred probing is
delayed until late_initcall time.


Below is a few of word I got from drivers/base/core.c I thought it helps
to understand the mechanism in complete picture

* If a required resource is not available yet, a driver can
request probing to be deferred by returning -EPROBE_DEFER from
its probe hook.

* A driver returning -EPROBE_DEFER causes the device to be added to the
pending list.  A successful driver probe will trigger moving all devices
from the pending to the active list so that the workqueue will
eventually retry them.

> > 
> > -	return sdrv->probe(to_serdev_device(dev));
> > +	return ret;
> > }
> > 
> > static int serdev_drv_remove(struct device *dev)
> > @@ -339,6 +348,9 @@ static int serdev_drv_remove(struct device *dev)
> > 	const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
> > 	if (sdrv->remove)
> > 		sdrv->remove(to_serdev_device(dev));
> > +
> > +	dev_pm_domain_detach(dev, true);
> > +
> > 	return 0;
> > }
> 
> Regards
> 
> Marcel
> 

WARNING: multiple messages have this Message-ID (diff)
From: sean.wang@mediatek.com (Sean Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 2/7] serdev: add dev_pm_domain_attach|detach()
Date: Thu, 26 Apr 2018 13:29:58 +0800	[thread overview]
Message-ID: <1524720598.12322.37.camel@mtkswgap22> (raw)
In-Reply-To: <FD85DED4-589C-4113-8A8B-BC5A39494130@holtmann.org>

On Tue, 2018-04-03 at 12:29 +0200, Marcel Holtmann wrote:
> Hi Sean,
> 
> > In order to open up the required power gate before any operation can be
> > effectively performed over the serial bus between CPU and serdev, it's
> > clearly essential to add common attach functions for PM domains to serdev
> > at the probe phase.
> > 
> > Similarly, the relevant dettach function for the PM domains should be
> > properly and reversely added at the remove phase.
> > 
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Jiri Slaby <jslaby@suse.com>
> > Cc: linux-serial at vger.kernel.org
> > ---
> > drivers/tty/serdev/core.c | 14 +++++++++++++-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> > index df93b72..c93d8ee 100644
> > --- a/drivers/tty/serdev/core.c
> > +++ b/drivers/tty/serdev/core.c
> > @@ -13,6 +13,7 @@
> > #include <linux/module.h>
> > #include <linux/of.h>
> > #include <linux/of_device.h>
> > +#include <linux/pm_domain.h>
> > #include <linux/serdev.h>
> > #include <linux/slab.h>
> > 
> > @@ -330,8 +331,16 @@ EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
> > static int serdev_drv_probe(struct device *dev)
> > {
> > 	const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
> > +	int ret;
> > +
> > +	ret = dev_pm_domain_attach(dev, true);
> > +	if (ret != -EPROBE_DEFER) {
> > +		ret = sdrv->probe(to_serdev_device(dev));
> > +		if (ret)
> > +			dev_pm_domain_detach(dev, true);
> > +	}
> 
> so if this is deferred, when does the serdev device gets probed?
> 

driver probe deferral mechanism is supported in driver core

deferred_probe_initcall makes sure that deferred probing is
delayed until late_initcall time.


Below is a few of word I got from drivers/base/core.c I thought it helps
to understand the mechanism in complete picture

* If a required resource is not available yet, a driver can
request probing to be deferred by returning -EPROBE_DEFER from
its probe hook.

* A driver returning -EPROBE_DEFER causes the device to be added to the
pending list.  A successful driver probe will trigger moving all devices
from the pending to the active list so that the workqueue will
eventually retry them.

> > 
> > -	return sdrv->probe(to_serdev_device(dev));
> > +	return ret;
> > }
> > 
> > static int serdev_drv_remove(struct device *dev)
> > @@ -339,6 +348,9 @@ static int serdev_drv_remove(struct device *dev)
> > 	const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
> > 	if (sdrv->remove)
> > 		sdrv->remove(to_serdev_device(dev));
> > +
> > +	dev_pm_domain_detach(dev, true);
> > +
> > 	return 0;
> > }
> 
> Regards
> 
> Marcel
> 

  reply	other threads:[~2018-04-26  5:30 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-03  7:15 [PATCH v1 0/7] add support for Bluetooth on MT7622 SoC sean.wang
2018-04-03  7:15 ` sean.wang at mediatek.com
2018-04-03  7:15 ` sean.wang
2018-04-03  7:15 ` [PATCH v1 1/7] dt-bindings: net: bluetooth: Add mediatek-bluetooth sean.wang
2018-04-03  7:15   ` sean.wang at mediatek.com
2018-04-03  7:15   ` sean.wang
2018-04-09 21:16   ` Rob Herring
2018-04-09 21:16     ` Rob Herring
2018-04-03  7:15 ` [PATCH v1 2/7] serdev: add dev_pm_domain_attach|detach() sean.wang
2018-04-03  7:15   ` sean.wang at mediatek.com
2018-04-03  7:15   ` sean.wang
2018-04-03 10:29   ` Marcel Holtmann
2018-04-03 10:29     ` Marcel Holtmann
2018-04-26  5:29     ` Sean Wang [this message]
2018-04-26  5:29       ` Sean Wang
2018-04-26  5:29       ` Sean Wang
2018-04-03  7:15 ` [PATCH v1 3/7] soc: mediatek: reuse read[l,x]_poll_timeout helpers sean.wang
2018-04-03  7:15   ` sean.wang at mediatek.com
2018-04-03  7:15   ` sean.wang
2018-04-18 15:06   ` Matthias Brugger
2018-04-18 15:06     ` Matthias Brugger
2018-04-03  7:15 ` [PATCH v1 4/7] soc: mediatek: reuse regmap_read_poll_timeout helpers sean.wang
2018-04-03  7:15   ` sean.wang at mediatek.com
2018-04-03  7:15   ` sean.wang
2018-04-19 10:23   ` Matthias Brugger
2018-04-19 10:23     ` Matthias Brugger
2018-04-20  3:42     ` Sean Wang
2018-04-20  3:42       ` Sean Wang
2018-04-20  3:42       ` Sean Wang
2018-04-03  7:15 ` [PATCH v1 5/7] soc: mediatek: add a fixed wait for SRAM stable sean.wang
2018-04-03  7:15   ` sean.wang at mediatek.com
2018-04-03  7:15   ` sean.wang
2018-04-05 16:42   ` Sasha Levin
2018-04-05 16:42     ` Sasha Levin
2018-04-05 16:42     ` Sasha Levin
2018-04-19 10:33   ` Matthias Brugger
2018-04-19 10:33     ` Matthias Brugger
2018-04-20  3:49     ` Sean Wang
2018-04-20  3:49       ` Sean Wang
2018-04-20  3:49       ` Sean Wang
2018-04-23  8:58       ` Sean Wang
2018-04-23  8:58         ` Sean Wang
2018-04-23  8:58         ` Sean Wang
2018-04-03  7:15 ` [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices sean.wang
2018-04-03  7:15   ` sean.wang at mediatek.com
2018-04-03  7:15   ` sean.wang
2018-04-03 10:27   ` Marcel Holtmann
2018-04-03 10:27     ` Marcel Holtmann
2018-04-26  7:34     ` Sean Wang
2018-04-26  7:34       ` Sean Wang
2018-04-26  7:34       ` Sean Wang
2018-04-26  9:47       ` Marcel Holtmann
2018-04-26  9:47         ` Marcel Holtmann
2018-04-27  4:13         ` Sean Wang
2018-04-27  4:13           ` Sean Wang
2018-04-27  4:13           ` Sean Wang
2018-04-27  5:25           ` Marcel Holtmann
2018-04-27  5:25             ` Marcel Holtmann
2018-04-27  9:14             ` Sean Wang
2018-04-27  9:14               ` Sean Wang
2018-04-27  9:14               ` Sean Wang
2018-04-27 16:34               ` Marcel Holtmann
2018-04-27 16:34                 ` Marcel Holtmann
2018-05-08  6:48     ` Sean Wang
2018-05-08  6:48       ` Sean Wang
2018-05-08  6:48       ` Sean Wang
2018-05-08  7:27       ` Marcel Holtmann
2018-05-08  7:27         ` Marcel Holtmann
2018-05-08  8:22         ` Sean Wang
2018-05-08  8:22           ` Sean Wang
2018-05-08  8:22           ` Sean Wang
2018-05-08 11:18           ` Marcel Holtmann
2018-05-08 11:18             ` Marcel Holtmann
2018-05-10  6:45             ` Sean Wang
2018-05-10  6:45               ` Sean Wang
2018-05-10  6:45               ` Sean Wang
2018-04-03 12:13   ` [RFC PATCH] Bluetooth: hci_mediatek: mtk_recv_frame() can be static kbuild test robot
2018-04-03 12:13     ` kbuild test robot
2018-04-03 12:13     ` kbuild test robot
2018-04-03 12:13   ` [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices kbuild test robot
2018-04-03 12:13     ` kbuild test robot
2018-04-03 12:13     ` kbuild test robot
2018-04-03  7:15 ` [PATCH v1 7/7] MAINTAINERS: add an entry for MediaTek Bluetooth driver sean.wang
2018-04-03  7:15   ` sean.wang at mediatek.com
2018-04-03  7:15   ` sean.wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1524720598.12322.37.camel@mtkswgap22 \
    --to=sean.wang@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan.hedberg@gmail.com \
    --cc=jslaby@suse.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.