On 07/18/2013 09:23 PM, Shawn Guo wrote:
On Thu, Jul 18, 2013 at 11:45:29AM -0700, Olof Johansson wrote:
...
You're spending an awful lot of energy arguing over this, but nobody
has actually shown data of how much deferral is happening -- and that
it's a real problem. Until someone does so
Hi,
On Thu, Jul 18, 2013 at 4:25 AM, Pavel Machek pa...@denx.de wrote:
It sound to me like keeping ammount of -EPROBE_DEFER to minimum is
still preferred.
Hand-crafting initcall level ordering of various drivers and subsystem
is probably an even greater evil though. We've done it in the past,
On Wed, Jul 17, 2013 at 9:57 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 07/16/2013 09:02 PM, Shawn Guo wrote:
On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
Registering the driver earlier won't cause any bugs. However, it's not
the correct approach.
Deferred probe
On Thu, Jul 18, 2013 at 4:25 AM, Pavel Machek pa...@denx.de wrote:
Hi!
I do not quite follow the argument here. I agree with you that
deferred probe is the approach to solve dependencies. But it does not
necessarily mean that initcall can not be used to help it save some
nasty or
On Thu, Jul 18, 2013 at 11:45:29AM -0700, Olof Johansson wrote:
Hi,
On Thu, Jul 18, 2013 at 4:25 AM, Pavel Machek pa...@denx.de wrote:
It sound to me like keeping ammount of -EPROBE_DEFER to minimum is
still preferred.
Hand-crafting initcall level ordering of various drivers and
Am Dienstag, den 16.07.2013, 09:47 -0600 schrieb Stephen Warren:
On 07/16/2013 12:51 AM, Shawn Guo wrote:
On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote:
Hi Philipp,
On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
This driver implements a reset controller
On 07/16/2013 09:02 PM, Shawn Guo wrote:
On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
Registering the driver earlier won't cause any bugs. However, it's not
the correct approach.
Deferred probe /is/ the approach for assuring correct dependencies
between drivers. It works
On 07/17/2013 03:38 PM, Pavel Machek wrote:
On Wed 2013-07-17 10:57:08, Stephen Warren wrote:
On 07/16/2013 09:02 PM, Shawn Guo wrote:
On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
Registering the driver earlier won't cause any bugs. However, it's not
the correct approach.
On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote:
Hi Philipp,
On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
This driver implements a reset controller device that toggle a gpio
connected to a reset pin of a peripheral IC. The delay between assertion
and
Hi Shawn,
Am Dienstag, den 16.07.2013, 12:10 +0800 schrieb Shawn Guo:
On Mon, Jul 15, 2013 at 09:35:52PM -0600, Stephen Warren wrote:
It's a little bit late to register gpio-reset driver at module_init
time, because gpio-reset provides reset control via gpio for other
devices which are
Am Dienstag, den 16.07.2013, 14:51 +0800 schrieb Shawn Guo:
On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote:
Hi Philipp,
On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
This driver implements a reset controller device that toggle a gpio
connected to a reset
Hi Stephen,
Am Montag, den 15.07.2013, 21:35 -0600 schrieb Stephen Warren:
On 07/15/2013 07:50 PM, Shawn Guo wrote:
Hi Philipp,
On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
This driver implements a reset controller device that toggle a gpio
connected to a reset pin
On Tue, Jul 16, 2013 at 11:51:19AM +0200, Philipp Zabel wrote:
Looks good to me. I can squash it into the original patch and resend if
you like.
Yes, please. Thanks.
Shawn
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
On Tue, Jul 16, 2013 at 11:49:26AM +0200, Philipp Zabel wrote:
so you want to have gpio-reset probed at arch_initcall time and you have
gpio-pca953x probed at subsys_initcall time. Won't then all gpio-reset
devices that use gpios on pca953x to reset other peripherals need to be
deferred?
Yes,
On 07/15/2013 10:10 PM, Shawn Guo wrote:
On Mon, Jul 15, 2013 at 09:35:52PM -0600, Stephen Warren wrote:
It's a little bit late to register gpio-reset driver at module_init
time, because gpio-reset provides reset control via gpio for other
devices which are mostly probed at module_init time
On 07/16/2013 12:51 AM, Shawn Guo wrote:
On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote:
Hi Philipp,
On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
This driver implements a reset controller device that toggle a gpio
connected to a reset pin of a peripheral IC. The
On 07/16/2013 03:59 AM, Philipp Zabel wrote:
...
Deferred probing is fine, but it'd be nice to keep the probe deferral
loops to a minimum where possible and/or reasonable.
I agree, but manually selecting initcalls for drivers is not the
solution. See my other email.
On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
Registering the driver earlier won't cause any bugs. However, it's not
the correct approach.
Deferred probe /is/ the approach for assuring correct dependencies
between drivers. It works and should be used. There are not enough
On Tue, Jul 16, 2013 at 09:47:02AM -0600, Stephen Warren wrote:
diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
- gpio_set_value(drvdata-gpio, value);
+ if (gpio_cansleep(drvdata-gpio))
+ gpio_set_value_cansleep(drvdata-gpio, value);
+ else
+
On 07/15/2013 07:50 PM, Shawn Guo wrote:
Hi Philipp,
On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
This driver implements a reset controller device that toggle a gpio
connected to a reset pin of a peripheral IC. The delay between assertion
and de-assertion of the reset
On Mon, Jul 15, 2013 at 09:35:52PM -0600, Stephen Warren wrote:
It's a little bit late to register gpio-reset driver at module_init
time, because gpio-reset provides reset control via gpio for other
devices which are mostly probed at module_init time too. And it
becomes even worse, when
This driver implements a reset controller device that toggle a gpio
connected to a reset pin of a peripheral IC. The delay between assertion
and de-assertion of the reset signal can be configured via device tree.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Stephen Warren
22 matches
Mail list logo
