* Re: w1/ds1wm regression after 2.6.39: "bus error, retrying"
@ 2011-06-26 0:58 Paul Parsons
2011-06-27 13:17 ` [PATCH] w1: ds1wm: add a reset recovery parameter Jean-François Dagenais
0 siblings, 1 reply; 12+ messages in thread
From: Paul Parsons @ 2011-06-26 0:58 UTC (permalink / raw)
To: Jean-François Dagenais; +Cc: linux-kernel, johnpol
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
Oops, yes the msleep() had been left in. I've attached debug output from the original ds1wm.c. Not sure how the mailing list copes with bzip2 compressed attachments; hopefully it will work.
Regards,
Paul
--- On Sat, 25/6/11, Jean-François Dagenais <dagenaisj@sonatest.com> wrote:
> This seems to be the output after you have restored the
> msleep. Could you provide it without so we can get a better
> idea as to what happened. If indeed this is a major
> regression for many devices, we'll have to submit a patch to
> the main branch.
> /jfd
[-- Attachment #2: dmesg.bz2 --]
[-- Type: application/x-bzip2, Size: 6987 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] w1: ds1wm: add a reset recovery parameter
2011-06-26 0:58 w1/ds1wm regression after 2.6.39: "bus error, retrying" Paul Parsons
@ 2011-06-27 13:17 ` Jean-François Dagenais
2011-06-28 9:59 ` Paul Parsons
2011-07-05 21:46 ` Andrew Morton
0 siblings, 2 replies; 12+ messages in thread
From: Jean-François Dagenais @ 2011-06-27 13:17 UTC (permalink / raw)
To: linux-kernel; +Cc: johnpol, Paul Parsons
This follows the regression on 3.0 reported by Paul Parsons regarding
the removal of the msleep(1) in the ds1wm_reset() function. This
sleep should not be required on normal circuitry provided the
pull-ups on the bus are correctly adapted to the slaves.
Unfortunately, this is not always the case. The sleep is restored
but as a parameter to the probe function in the pdata.
---
drivers/mfd/asic3.c | 1 +
drivers/mfd/htc-pasic3.c | 1 +
drivers/w1/masters/ds1wm.c | 5 +++++
include/linux/mfd/ds1wm.h | 7 +++++++
4 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/asic3.c b/drivers/mfd/asic3.c
index c27fd1f..c71ae09 100644
--- a/drivers/mfd/asic3.c
+++ b/drivers/mfd/asic3.c
@@ -619,6 +619,7 @@ static void asic3_clk_disable(struct asic3 *asic, struct asic3_clk *clk)
/* MFD cells (SPI, PWM, LED, DS1WM, MMC) */
static struct ds1wm_driver_data ds1wm_pdata = {
.active_high = 1,
+ .reset_recover_delay = 1,
};
static struct resource ds1wm_resources[] = {
diff --git a/drivers/mfd/htc-pasic3.c b/drivers/mfd/htc-pasic3.c
index 2808bd1..04c7093 100644
--- a/drivers/mfd/htc-pasic3.c
+++ b/drivers/mfd/htc-pasic3.c
@@ -99,6 +99,7 @@ static int ds1wm_disable(struct platform_device *pdev)
static struct ds1wm_driver_data ds1wm_pdata = {
.active_high = 0,
+ .reset_recover_delay = 1,
};
static struct resource ds1wm_resources[] __initdata = {
diff --git a/drivers/w1/masters/ds1wm.c b/drivers/w1/masters/ds1wm.c
index ad57593..66bf82f 100644
--- a/drivers/w1/masters/ds1wm.c
+++ b/drivers/w1/masters/ds1wm.c
@@ -109,6 +109,7 @@ struct ds1wm_data {
/* byte to write that makes all intr disabled, */
/* considering active_state (IAS) (optimization) */
u8 int_en_reg_none;
+ unsigned int reset_recover_delay; /* see ds1wm.h */
};
static inline void ds1wm_write_register(struct ds1wm_data *ds1wm_data, u32 reg,
@@ -187,6 +188,9 @@ static int ds1wm_reset(struct ds1wm_data *ds1wm_data)
return 1;
}
+ if(ds1wm_data->reset_recover_delay)
+ msleep(ds1wm_data->reset_recover_delay);
+
return 0;
}
@@ -490,6 +494,7 @@ static int ds1wm_probe(struct platform_device *pdev)
}
ds1wm_data->irq = res->start;
ds1wm_data->int_en_reg_none = (plat->active_high ? DS1WM_INTEN_IAS : 0);
+ ds1wm_data->reset_recover_delay = plat->reset_recover_delay;
if (res->flags & IORESOURCE_IRQ_HIGHEDGE)
irq_set_irq_type(ds1wm_data->irq, IRQ_TYPE_EDGE_RISING);
diff --git a/include/linux/mfd/ds1wm.h b/include/linux/mfd/ds1wm.h
index be469a3..068044f 100644
--- a/include/linux/mfd/ds1wm.h
+++ b/include/linux/mfd/ds1wm.h
@@ -3,4 +3,11 @@
struct ds1wm_driver_data {
int active_high;
int clock_rate;
+ /* in milliseconds, the amount of time to */
+ /* sleep following a reset pulse. Zero */
+ /* should work if your bus devices recover*/
+ /* time respects the 1-wire spec since the*/
+ /* ds1wm implements the precise timings of*/
+ /* a reset pulse/presence detect sequence.*/
+ unsigned int reset_recover_delay;
};
--
1.7.5.4
Jean-Francois Dagenais
Software Architect - B.Sc.A
Experience the new veo phased array flaw detector at www.sonatestveo.com.
Sonatest AP
2900 chemin des Quatre-Bourgeois
Bureau 305
Quebec City Quebec G1V 1Y4
T| +1 (418) 683 6222 x106 F| +1 (418) 683 7032 M| W| www.sonatest.com
This message (and any associated files) is intended only for the use of linux-kernel@vger.kernel.org, johnpol@2ka.mipt.ru, lost.distance@yahoo.com and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the above recipient(s) you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.
Think green - help the environment by not printing this email.
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH] w1: ds1wm: add a reset recovery parameter
2011-06-27 13:17 ` [PATCH] w1: ds1wm: add a reset recovery parameter Jean-François Dagenais
@ 2011-06-28 9:59 ` Paul Parsons
2011-07-05 21:46 ` Andrew Morton
1 sibling, 0 replies; 12+ messages in thread
From: Paul Parsons @ 2011-06-28 9:59 UTC (permalink / raw)
To: linux-kernel, Jean-François Dagenais; +Cc: johnpol
Thanks Jean-François; that patch set has resolved the problem.
Tested-by: Paul Parsons <lost.distance@yahoo.com>
--- On Mon, 27/6/11, Jean-François Dagenais <dagenaisj@sonatest.com> wrote:
> From: Jean-François Dagenais <dagenaisj@sonatest.com>
> Subject: [PATCH] w1: ds1wm: add a reset recovery parameter
> To: linux-kernel@vger.kernel.org
> Cc: johnpol@2ka.mipt.ru, "Paul Parsons" <lost.distance@yahoo.com>
> Date: Monday, 27 June, 2011, 14:17
> This follows the regression on 3.0
> reported by Paul Parsons regarding
> the removal of the msleep(1) in the ds1wm_reset() function.
> This
> sleep should not be required on normal circuitry provided
> the
> pull-ups on the bus are correctly adapted to the slaves.
> Unfortunately, this is not always the case. The sleep is
> restored
> but as a parameter to the probe function in the pdata.
> ---
> drivers/mfd/asic3.c |
> 1 +
> drivers/mfd/htc-pasic3.c | 1
> +
> drivers/w1/masters/ds1wm.c | 5 +++++
> include/linux/mfd/ds1wm.h | 7 +++++++
> 4 files changed, 14 insertions(+), 0 deletions(-)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] w1: ds1wm: add a reset recovery parameter
2011-06-27 13:17 ` [PATCH] w1: ds1wm: add a reset recovery parameter Jean-François Dagenais
2011-06-28 9:59 ` Paul Parsons
@ 2011-07-05 21:46 ` Andrew Morton
2011-07-06 13:16 ` Jean-François Dagenais
1 sibling, 1 reply; 12+ messages in thread
From: Andrew Morton @ 2011-07-05 21:46 UTC (permalink / raw)
To: Jean-François Dagenais; +Cc: linux-kernel, johnpol, Paul Parsons
On Mon, 27 Jun 2011 09:17:58 -0400
Jean-Fran__ois Dagenais <dagenaisj@sonatest.com> wrote:
> This follows the regression on 3.0 reported by Paul Parsons regarding
> the removal of the msleep(1) in the ds1wm_reset() function. This
> sleep should not be required on normal circuitry provided the
> pull-ups on the bus are correctly adapted to the slaves.
> Unfortunately, this is not always the case. The sleep is restored
> but as a parameter to the probe function in the pdata.
A few things.
- When fixing a bug, please fully describe that bug in the changelog.
So that others can determine whether your patch might fix a bug
which they are observing.
That's not so important when we're fixing a regression which was
introduced since the most recent major kernel release, but it's good
practice and who knows, someone might have backported the
regression-introducing patch.
- The patch was missing your signed-off-by. I added it. Please
ack this.
- It's conventional to give bug-reporters a hat tip via the
Reported-by: tag.
Here's what I merged:
From: Jean-Fran_ois Dagenais <dagenaisj@sonatest.com>
This fixes a regression on 3.0 reported by Paul Parsons regarding the
removal of the msleep(1) in the ds1wm_reset() function:
: The linux-3.0-rc4 DS1WM 1-wire driver is logging "bus error, retrying"
: error messages on an HP iPAQ hx4700 PDA (XScale-PXA270):
:
: <snip>
: Driver for 1-wire Dallas network protocol.
: DS1WM w1 busmaster driver - (c) 2004 Szabolcs Gyurko
: 1-Wire driver for the DS2760 battery monitor chip - (c) 2004-2005, Szabolcs Gyurko
: ds1wm ds1wm: pass: 1 bus error, retrying
: ds1wm ds1wm: pass: 2 bus error, retrying
: ds1wm ds1wm: pass: 3 bus error, retrying
: ds1wm ds1wm: pass: 4 bus error, retrying
: ds1wm ds1wm: pass: 5 bus error, retrying
: ...
:
: The visible result is that the battery charging LED is erratic; sometimes
: it works, mostly it doesn't.
:
: The linux-2.6.39 DS1WM 1-wire driver worked OK. I haven't tried 3.0-rc1,
: 3.0-rc2, or 3.0-rc3.
This sleep should not be required on normal circuitry provided the
pull-ups on the bus are correctly adapted to the slaves. Unfortunately,
this is not always the case. The sleep is restored but as a parameter to
the probe function in the pdata.
Reported-by: Paul Parsons <lost.distance@yahoo.com>
Tested-by: Paul Parsons <lost.distance@yahoo.com>
Signed-off-by: Jean-Fran_ois Dagenais <dagenaisj@sonatest.com>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/mfd/asic3.c | 1 +
drivers/mfd/htc-pasic3.c | 1 +
drivers/w1/masters/ds1wm.c | 5 +++++
include/linux/mfd/ds1wm.h | 7 +++++++
4 files changed, 14 insertions(+)
diff -puN drivers/mfd/asic3.c~w1-ds1wm-add-a-reset-recovery-parameter drivers/mfd/asic3.c
--- a/drivers/mfd/asic3.c~w1-ds1wm-add-a-reset-recovery-parameter
+++ a/drivers/mfd/asic3.c
@@ -619,6 +619,7 @@ static void asic3_clk_disable(struct asi
/* MFD cells (SPI, PWM, LED, DS1WM, MMC) */
static struct ds1wm_driver_data ds1wm_pdata = {
.active_high = 1,
+ .reset_recover_delay = 1,
};
static struct resource ds1wm_resources[] = {
diff -puN drivers/mfd/htc-pasic3.c~w1-ds1wm-add-a-reset-recovery-parameter drivers/mfd/htc-pasic3.c
--- a/drivers/mfd/htc-pasic3.c~w1-ds1wm-add-a-reset-recovery-parameter
+++ a/drivers/mfd/htc-pasic3.c
@@ -99,6 +99,7 @@ static int ds1wm_disable(struct platform
static struct ds1wm_driver_data ds1wm_pdata = {
.active_high = 0,
+ .reset_recover_delay = 1,
};
static struct resource ds1wm_resources[] __initdata = {
diff -puN drivers/w1/masters/ds1wm.c~w1-ds1wm-add-a-reset-recovery-parameter drivers/w1/masters/ds1wm.c
--- a/drivers/w1/masters/ds1wm.c~w1-ds1wm-add-a-reset-recovery-parameter
+++ a/drivers/w1/masters/ds1wm.c
@@ -109,6 +109,7 @@ struct ds1wm_data {
/* byte to write that makes all intr disabled, */
/* considering active_state (IAS) (optimization) */
u8 int_en_reg_none;
+ unsigned int reset_recover_delay; /* see ds1wm.h */
};
static inline void ds1wm_write_register(struct ds1wm_data *ds1wm_data, u32 reg,
@@ -187,6 +188,9 @@ static int ds1wm_reset(struct ds1wm_data
return 1;
}
+ if(ds1wm_data->reset_recover_delay)
+ msleep(ds1wm_data->reset_recover_delay);
+
return 0;
}
@@ -490,6 +494,7 @@ static int ds1wm_probe(struct platform_d
}
ds1wm_data->irq = res->start;
ds1wm_data->int_en_reg_none = (plat->active_high ? DS1WM_INTEN_IAS : 0);
+ ds1wm_data->reset_recover_delay = plat->reset_recover_delay;
if (res->flags & IORESOURCE_IRQ_HIGHEDGE)
irq_set_irq_type(ds1wm_data->irq, IRQ_TYPE_EDGE_RISING);
diff -puN include/linux/mfd/ds1wm.h~w1-ds1wm-add-a-reset-recovery-parameter include/linux/mfd/ds1wm.h
--- a/include/linux/mfd/ds1wm.h~w1-ds1wm-add-a-reset-recovery-parameter
+++ a/include/linux/mfd/ds1wm.h
@@ -3,4 +3,11 @@
struct ds1wm_driver_data {
int active_high;
int clock_rate;
+ /* in milliseconds, the amount of time to */
+ /* sleep following a reset pulse. Zero */
+ /* should work if your bus devices recover*/
+ /* time respects the 1-wire spec since the*/
+ /* ds1wm implements the precise timings of*/
+ /* a reset pulse/presence detect sequence.*/
+ unsigned int reset_recover_delay;
};
_
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] w1: ds1wm: add a reset recovery parameter
2011-07-05 21:46 ` Andrew Morton
@ 2011-07-06 13:16 ` Jean-François Dagenais
2011-07-06 21:25 ` Andrew Morton
0 siblings, 1 reply; 12+ messages in thread
From: Jean-François Dagenais @ 2011-07-06 13:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Jul 5, 2011, at 17:46, Andrew Morton wrote:
> On Mon, 27 Jun 2011 09:17:58 -0400
> Jean-Fran__ois Dagenais <dagenaisj@sonatest.com> wrote:
>
>> This follows the regression on 3.0 reported by Paul Parsons regarding
>> the removal of the msleep(1) in the ds1wm_reset() function. This
>> sleep should not be required on normal circuitry provided the
>> pull-ups on the bus are correctly adapted to the slaves.
>> Unfortunately, this is not always the case. The sleep is restored
>> but as a parameter to the probe function in the pdata.
>
> A few things.
>
> - When fixing a bug, please fully describe that bug in the changelog.
> So that others can determine whether your patch might fix a bug
> which they are observing.
>
> That's not so important when we're fixing a regression which was
> introduced since the most recent major kernel release, but it's good
> practice and who knows, someone might have backported the
> regression-introducing patch.
>
> - The patch was missing your signed-off-by. I added it. Please
> ack this.
>
> - It's conventional to give bug-reporters a hat tip via the
> Reported-by: tag.
>
All noted. Thanks for the constructive feedback. ds1wm mods are my first contrib to the kernel.
> Here's what I merged:
>
>
> From: Jean-Fran_ois Dagenais <dagenaisj@sonatest.com>
If the c-cedilla doesn't work please replace the '_' by a regular 'c'... actually I will re-submit the patch as v2.
>
> This fixes a regression on 3.0 reported by Paul Parsons regarding the
> removal of the msleep(1) in the ds1wm_reset() function:
>
> : The linux-3.0-rc4 DS1WM 1-wire driver is logging "bus error, retrying"
> : error messages on an HP iPAQ hx4700 PDA (XScale-PXA270):
> :
> : <snip>
> : Driver for 1-wire Dallas network protocol.
> : DS1WM w1 busmaster driver - (c) 2004 Szabolcs Gyurko
> : 1-Wire driver for the DS2760 battery monitor chip - (c) 2004-2005, Szabolcs Gyurko
> : ds1wm ds1wm: pass: 1 bus error, retrying
> : ds1wm ds1wm: pass: 2 bus error, retrying
> : ds1wm ds1wm: pass: 3 bus error, retrying
> : ds1wm ds1wm: pass: 4 bus error, retrying
> : ds1wm ds1wm: pass: 5 bus error, retrying
> : ...
> :
> : The visible result is that the battery charging LED is erratic; sometimes
> : it works, mostly it doesn't.
> :
> : The linux-2.6.39 DS1WM 1-wire driver worked OK. I haven't tried 3.0-rc1,
> : 3.0-rc2, or 3.0-rc3.
>
> This sleep should not be required on normal circuitry provided the
> pull-ups on the bus are correctly adapted to the slaves. Unfortunately,
> this is not always the case. The sleep is restored but as a parameter to
> the probe function in the pdata.
>
> Reported-by: Paul Parsons <lost.distance@yahoo.com>
> Tested-by: Paul Parsons <lost.distance@yahoo.com>
> Signed-off-by: Jean-Fran_ois Dagenais <dagenaisj@sonatest.com>
again, the '_'
> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/mfd/asic3.c | 1 +
> drivers/mfd/htc-pasic3.c | 1 +
> drivers/w1/masters/ds1wm.c | 5 +++++
> include/linux/mfd/ds1wm.h | 7 +++++++
> 4 files changed, 14 insertions(+)
>
> diff -puN drivers/mfd/asic3.c~w1-ds1wm-add-a-reset-recovery-parameter drivers/mfd/asic3.c
> --- a/drivers/mfd/asic3.c~w1-ds1wm-add-a-reset-recovery-parameter
> +++ a/drivers/mfd/asic3.c
> @@ -619,6 +619,7 @@ static void asic3_clk_disable(struct asi
> /* MFD cells (SPI, PWM, LED, DS1WM, MMC) */
> static struct ds1wm_driver_data ds1wm_pdata = {
> .active_high = 1,
> + .reset_recover_delay = 1,
> };
>
> static struct resource ds1wm_resources[] = {
> diff -puN drivers/mfd/htc-pasic3.c~w1-ds1wm-add-a-reset-recovery-parameter drivers/mfd/htc-pasic3.c
> --- a/drivers/mfd/htc-pasic3.c~w1-ds1wm-add-a-reset-recovery-parameter
> +++ a/drivers/mfd/htc-pasic3.c
> @@ -99,6 +99,7 @@ static int ds1wm_disable(struct platform
>
> static struct ds1wm_driver_data ds1wm_pdata = {
> .active_high = 0,
> + .reset_recover_delay = 1,
> };
>
> static struct resource ds1wm_resources[] __initdata = {
> diff -puN drivers/w1/masters/ds1wm.c~w1-ds1wm-add-a-reset-recovery-parameter drivers/w1/masters/ds1wm.c
> --- a/drivers/w1/masters/ds1wm.c~w1-ds1wm-add-a-reset-recovery-parameter
> +++ a/drivers/w1/masters/ds1wm.c
> @@ -109,6 +109,7 @@ struct ds1wm_data {
> /* byte to write that makes all intr disabled, */
> /* considering active_state (IAS) (optimization) */
> u8 int_en_reg_none;
> + unsigned int reset_recover_delay; /* see ds1wm.h */
> };
>
> static inline void ds1wm_write_register(struct ds1wm_data *ds1wm_data, u32 reg,
> @@ -187,6 +188,9 @@ static int ds1wm_reset(struct ds1wm_data
> return 1;
> }
>
> + if(ds1wm_data->reset_recover_delay)
> + msleep(ds1wm_data->reset_recover_delay);
> +
> return 0;
> }
>
> @@ -490,6 +494,7 @@ static int ds1wm_probe(struct platform_d
> }
> ds1wm_data->irq = res->start;
> ds1wm_data->int_en_reg_none = (plat->active_high ? DS1WM_INTEN_IAS : 0);
> + ds1wm_data->reset_recover_delay = plat->reset_recover_delay;
>
> if (res->flags & IORESOURCE_IRQ_HIGHEDGE)
> irq_set_irq_type(ds1wm_data->irq, IRQ_TYPE_EDGE_RISING);
> diff -puN include/linux/mfd/ds1wm.h~w1-ds1wm-add-a-reset-recovery-parameter include/linux/mfd/ds1wm.h
> --- a/include/linux/mfd/ds1wm.h~w1-ds1wm-add-a-reset-recovery-parameter
> +++ a/include/linux/mfd/ds1wm.h
> @@ -3,4 +3,11 @@
> struct ds1wm_driver_data {
> int active_high;
> int clock_rate;
> + /* in milliseconds, the amount of time to */
> + /* sleep following a reset pulse. Zero */
> + /* should work if your bus devices recover*/
> + /* time respects the 1-wire spec since the*/
> + /* ds1wm implements the precise timings of*/
> + /* a reset pulse/presence detect sequence.*/
> + unsigned int reset_recover_delay;
> };
> _
>
>
Jean-Francois Dagenais
Software Architect - B.Sc.A
Experience the new veo phased array flaw detector at www.sonatestveo.com.
Sonatest AP
2900 chemin des Quatre-Bourgeois
Bureau 305
Quebec City Quebec G1V 1Y4
T| +1 (418) 683 6222 x106 F| +1 (418) 683 7032 M| W| www.sonatest.com
This message (and any associated files) is intended only for the use of akpm@linux-foundation.org, linux-kernel@vger.kernel.org and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the above recipient(s) you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.
Think green - help the environment by not printing this email.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] w1: ds1wm: add a reset recovery parameter
2011-07-06 13:16 ` Jean-François Dagenais
@ 2011-07-06 21:25 ` Andrew Morton
0 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2011-07-06 21:25 UTC (permalink / raw)
To: Jean-François Dagenais; +Cc: linux-kernel
On Wed, 6 Jul 2011 09:16:57 -0400
Jean-François Dagenais <dagenaisj@Sonatest.com> wrote:
> > From: Jean-Fran_ois Dagenais <dagenaisj@sonatest.com>
> If the c-cedilla doesn't work please replace the '_' by a regular 'c'... actually I will re-submit the patch as v2.
It seems that a python script whcih Uwe wrote for me has broken. Let
me see if I can send it back for repair..
^ permalink raw reply [flat|nested] 12+ messages in thread
* w1/ds1wm regression after 2.6.39: "bus error, retrying"
@ 2011-06-24 15:08 Paul Parsons
2011-06-24 16:15 ` Jean-François Dagenais
0 siblings, 1 reply; 12+ messages in thread
From: Paul Parsons @ 2011-06-24 15:08 UTC (permalink / raw)
To: linux-kernel, johnpol, dagenaisj
The linux-3.0-rc4 DS1WM 1-wire driver is logging "bus error, retrying" error messages on an HP iPAQ hx4700 PDA (XScale-PXA270):
<snip>
Driver for 1-wire Dallas network protocol.
DS1WM w1 busmaster driver - (c) 2004 Szabolcs Gyurko
1-Wire driver for the DS2760 battery monitor chip - (c) 2004-2005, Szabolcs Gyurko
ds1wm ds1wm: pass: 1 bus error, retrying
ds1wm ds1wm: pass: 2 bus error, retrying
ds1wm ds1wm: pass: 3 bus error, retrying
ds1wm ds1wm: pass: 4 bus error, retrying
ds1wm ds1wm: pass: 5 bus error, retrying
ds1wm ds1wm: pass: 6 bus error, retrying
ds1wm ds1wm: pass: 7 bus error, retrying
ds1wm ds1wm: pass: 8 bus error, retrying
ds1wm ds1wm: pass: 9 bus error, retrying
ds1wm ds1wm: pass: 10 bus error, retrying
ds1wm ds1wm: pass: 11 bus error, retrying
ds1wm ds1wm: pass: 12 bus error, retrying
ds1wm ds1wm: pass: 13 bus error, retrying
ds1wm ds1wm: pass: 14 bus error, retrying
ds1wm ds1wm: pass: 15 bus error, retrying
ds1wm ds1wm: pass: 16 bus error, retrying
ds1wm ds1wm: pass: 17 bus error, retrying
ds1wm ds1wm: pass: 18 bus error, retrying
ds1wm ds1wm: pass: 19 bus error, retrying
ds1wm ds1wm: pass: 20 bus error, retrying
ds1wm ds1wm: pass: 21 bus error, retrying
ds1wm ds1wm: pass: 22 bus error, retrying
ds1wm ds1wm: pass: 23 bus error, retrying
ds1wm ds1wm: pass: 24 bus error, retrying
ds1wm ds1wm: pass: 25 bus error, retrying
ds1wm ds1wm: pass: 26 bus error, retrying
ds1wm ds1wm: pass: 27 bus error, retrying
ds1wm ds1wm: pass: 28 bus error, retrying
ds1wm ds1wm: pass: 29 bus error, retrying
ds1wm ds1wm: pass: 30 bus error, retrying
ds1wm ds1wm: pass: 31 bus error, retrying
ds1wm ds1wm: pass: 32 bus error, retrying
ds1wm ds1wm: pass: 33 bus error, retrying
pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0
pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 124)
scsi0 : pata_pcmcia
ata1: PATA max PIO0 cmd 0xc4820000 ctl 0xc482000e irq 124
ds1wm ds1wm: pass: 34 bus error, retrying
ds1wm ds1wm: pass: 35 bus error, retrying
ds1wm ds1wm: pass: 36 bus error, retrying
ds1wm ds1wm: pass: 37 bus error, retrying
ds1wm ds1wm: pass: 38 bus error, retrying
ds1wm ds1wm: pass: 39 bus error, retrying
ds1wm ds1wm: pass: 40 bus error, retrying
ds1wm ds1wm: pass: 41 bus error, retrying
ds1wm ds1wm: pass: 42 bus error, retrying
ds1wm ds1wm: pass: 43 bus error, retrying
ds1wm ds1wm: pass: 44 bus error, retrying
ata1.00: CFA: CF Card, Ver1.27, max PIO4
ata1.00: 2014992 sectors, multi 0: LBA
ds1wm ds1wm: pass: 45 bus error, retrying
ds1wm ds1wm: pass: 46 bus error, retrying
ata1.00: configured for PIO0
scsi 0:0:0:0: Direct-Access ATA CF Card Ver1 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 2014992 512-byte logical blocks: (1.03 GB/983 MiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI removable disk
ds1wm ds1wm: pass: 47 bus error, retrying
APM Battery Driver
mmc0 at 0xc48d2800 irq 130
Registered led device: hx4700:amber
Registered led device: hx4700:green
Registered led device: hx4700:blue
TCP cubic registered
NET: Registered protocol family 17
XScale iWMMXt coprocessor detected.
pxa-rtc pxa-rtc: setting system clock to 2000-01-01 00:00:07 UTC (946684807)
Warning: unable to open an initial console.
VFS: Mounted root (jffs2 filesystem) readonly on device 31:2.
Freeing init memory: 104K
mmc0: new SD card at address 1234
mmcblk0: mmc0:1234 SD01G 972 MiB
mmcblk0: p1
udevd (337): /proc/337/oom_adj is deprecated, please use /proc/337/oom_score_adj instead.
g_serial gadget: Gadget Serial v2.4
g_serial gadget: g_serial ready
pxa27x-udc pxa27x-udc: USB reset
pxa27x-udc pxa27x-udc: USB reset
pxa27x-udc pxa27x-udc: USB reset
g_serial gadget: full speed config #1: Generic Serial config
ds1wm ds1wm: pass: 1 bus error, retrying
ds1wm ds1wm: pass: 2 bus error, retrying
ds1wm ds1wm: pass: 3 bus error, retrying
<snip>
ds1wm ds1wm: pass: 91 bus error, retrying
ds1wm ds1wm: pass: 92 bus error, retrying
ds1wm ds1wm: pass: 93 bus error, retrying
ds1wm ds1wm: pass: 1 bus error, retrying
ds1wm ds1wm: pass: 2 bus error, retrying
ds1wm ds1wm: pass: 3 bus error, retrying
<snip>
ds1wm ds1wm: pass: 29 bus error, retrying
ds1wm ds1wm: pass: 30 bus error, retrying
ds1wm ds1wm: pass: 31 bus error, retrying
ds1wm ds1wm: pass: 1 bus error, retrying
ds1wm ds1wm: pass: 2 bus error, retrying
ds1wm ds1wm: pass: 3 bus error, retrying
<snip>
ds1wm ds1wm: pass: 98 bus error, retrying
ds1wm ds1wm: pass: 99 bus error, retrying
ds1wm ds1wm: pass: 100 bus error, retrying
ds1wm ds1wm: pass: 1 bus error, retrying
ds1wm ds1wm: pass: 2 bus error, retrying
ds1wm ds1wm: pass: 3 bus error, retrying
<snip>
ds1wm ds1wm: pass: 92 bus error, retrying
ds1wm ds1wm: pass: 93 bus error, retrying
ds1wm ds1wm: pass: 94 bus error, retrying
ds1wm ds1wm: pass: 1 bus error, retrying
ds1wm ds1wm: pass: 2 bus error, retrying
ds1wm ds1wm: pass: 3 bus error, retrying
<snip>
ds1wm ds1wm: pass: 98 bus error, retrying
ds1wm ds1wm: pass: 99 bus error, retrying
ds1wm ds1wm: pass: 100 bus error, retrying
<snip>
The visible result is that the battery charging LED is erratic; sometimes it works, mostly it doesn't.
The linux-2.6.39 DS1WM 1-wire driver worked OK. I haven't tried 3.0-rc1, 3.0-rc2, or 3.0-rc3.
Regards.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: w1/ds1wm regression after 2.6.39: "bus error, retrying"
2011-06-24 15:08 w1/ds1wm regression after 2.6.39: "bus error, retrying" Paul Parsons
@ 2011-06-24 16:15 ` Jean-François Dagenais
2011-06-24 19:07 ` Paul Parsons
0 siblings, 1 reply; 12+ messages in thread
From: Jean-François Dagenais @ 2011-06-24 16:15 UTC (permalink / raw)
To: Paul Parsons; +Cc: linux-kernel, johnpol
Hi Paul,
Sorry to hear that. 2.6.39's ds1wm driver did not support dynamically finding the slaves on the bus, it would limit it's search to 1 and exit. My modifications implement the hardware assisted search as documented by the ds1wm spec sheet.
There are a couple of ways you can workaround the problem (temporarily or permanently). You might disable the bus scanning altogether (like I explain below) and insert your slave manually (as documented in the kernel w1 docs). If only one slave is present, the bus master will usually just skip the ROM matching part of the communication by doing a "SKIP ROM" which essentially says to the slave "whoever you are, I am talking to you". You could also patch the ds1wm_search function to make it look like it was in 2.6.39, or just use the whole file if it worked fine for you.
Now, to find the real problem, could you try the following:
- to limit trace noise, disable the w1 auto probe by setting the search count to 0, either in "wire" module load ("search_count=0" in /etc/modprobe.conf or the like) or int /sys under your w1 master instance
- build the ds1wm with "#define DEBUG" at the top (before headers), this will prints lots of debug about the accelerated search algorithm progress. (you could also set the retry count to something less than 100 to also limit noise in the trace)
- once booted, trigger one search manually by writing 1 in /sys/bus/w1/devices/w1\ bus\ master/w1_master_search
dmesg will contain a nice trace (although big)
Do you have more than one slave device on the ds1wm bus?
I will try to help as much as I can.
/jfd
On Jun 24, 2011, at 11:08, Paul Parsons wrote:
> The linux-3.0-rc4 DS1WM 1-wire driver is logging "bus error, retrying" error messages on an HP iPAQ hx4700 PDA (XScale-PXA270):
>
> <snip>
> Driver for 1-wire Dallas network protocol.
> DS1WM w1 busmaster driver - (c) 2004 Szabolcs Gyurko
> 1-Wire driver for the DS2760 battery monitor chip - (c) 2004-2005, Szabolcs Gyurko
> ds1wm ds1wm: pass: 1 bus error, retrying
> ds1wm ds1wm: pass: 2 bus error, retrying
> ds1wm ds1wm: pass: 3 bus error, retrying
> ds1wm ds1wm: pass: 4 bus error, retrying
> ds1wm ds1wm: pass: 5 bus error, retrying
> ds1wm ds1wm: pass: 6 bus error, retrying
> ds1wm ds1wm: pass: 7 bus error, retrying
> ds1wm ds1wm: pass: 8 bus error, retrying
> ds1wm ds1wm: pass: 9 bus error, retrying
> ds1wm ds1wm: pass: 10 bus error, retrying
> ds1wm ds1wm: pass: 11 bus error, retrying
> ds1wm ds1wm: pass: 12 bus error, retrying
> ds1wm ds1wm: pass: 13 bus error, retrying
> ds1wm ds1wm: pass: 14 bus error, retrying
> ds1wm ds1wm: pass: 15 bus error, retrying
> ds1wm ds1wm: pass: 16 bus error, retrying
> ds1wm ds1wm: pass: 17 bus error, retrying
> ds1wm ds1wm: pass: 18 bus error, retrying
> ds1wm ds1wm: pass: 19 bus error, retrying
> ds1wm ds1wm: pass: 20 bus error, retrying
> ds1wm ds1wm: pass: 21 bus error, retrying
> ds1wm ds1wm: pass: 22 bus error, retrying
> ds1wm ds1wm: pass: 23 bus error, retrying
> ds1wm ds1wm: pass: 24 bus error, retrying
> ds1wm ds1wm: pass: 25 bus error, retrying
> ds1wm ds1wm: pass: 26 bus error, retrying
> ds1wm ds1wm: pass: 27 bus error, retrying
> ds1wm ds1wm: pass: 28 bus error, retrying
> ds1wm ds1wm: pass: 29 bus error, retrying
> ds1wm ds1wm: pass: 30 bus error, retrying
> ds1wm ds1wm: pass: 31 bus error, retrying
> ds1wm ds1wm: pass: 32 bus error, retrying
> ds1wm ds1wm: pass: 33 bus error, retrying
> pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0
> pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 124)
> scsi0 : pata_pcmcia
> ata1: PATA max PIO0 cmd 0xc4820000 ctl 0xc482000e irq 124
> ds1wm ds1wm: pass: 34 bus error, retrying
> ds1wm ds1wm: pass: 35 bus error, retrying
> ds1wm ds1wm: pass: 36 bus error, retrying
> ds1wm ds1wm: pass: 37 bus error, retrying
> ds1wm ds1wm: pass: 38 bus error, retrying
> ds1wm ds1wm: pass: 39 bus error, retrying
> ds1wm ds1wm: pass: 40 bus error, retrying
> ds1wm ds1wm: pass: 41 bus error, retrying
> ds1wm ds1wm: pass: 42 bus error, retrying
> ds1wm ds1wm: pass: 43 bus error, retrying
> ds1wm ds1wm: pass: 44 bus error, retrying
> ata1.00: CFA: CF Card, Ver1.27, max PIO4
> ata1.00: 2014992 sectors, multi 0: LBA
> ds1wm ds1wm: pass: 45 bus error, retrying
> ds1wm ds1wm: pass: 46 bus error, retrying
> ata1.00: configured for PIO0
> scsi 0:0:0:0: Direct-Access ATA CF Card Ver1 PQ: 0 ANSI: 5
> sd 0:0:0:0: [sda] 2014992 512-byte logical blocks: (1.03 GB/983 MiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> sda: sda1
> sd 0:0:0:0: [sda] Attached SCSI removable disk
> ds1wm ds1wm: pass: 47 bus error, retrying
> APM Battery Driver
> mmc0 at 0xc48d2800 irq 130
> Registered led device: hx4700:amber
> Registered led device: hx4700:green
> Registered led device: hx4700:blue
> TCP cubic registered
> NET: Registered protocol family 17
> XScale iWMMXt coprocessor detected.
> pxa-rtc pxa-rtc: setting system clock to 2000-01-01 00:00:07 UTC (946684807)
> Warning: unable to open an initial console.
> VFS: Mounted root (jffs2 filesystem) readonly on device 31:2.
> Freeing init memory: 104K
> mmc0: new SD card at address 1234
> mmcblk0: mmc0:1234 SD01G 972 MiB
> mmcblk0: p1
> udevd (337): /proc/337/oom_adj is deprecated, please use /proc/337/oom_score_adj instead.
> g_serial gadget: Gadget Serial v2.4
> g_serial gadget: g_serial ready
> pxa27x-udc pxa27x-udc: USB reset
> pxa27x-udc pxa27x-udc: USB reset
> pxa27x-udc pxa27x-udc: USB reset
> g_serial gadget: full speed config #1: Generic Serial config
> ds1wm ds1wm: pass: 1 bus error, retrying
> ds1wm ds1wm: pass: 2 bus error, retrying
> ds1wm ds1wm: pass: 3 bus error, retrying
> <snip>
> ds1wm ds1wm: pass: 91 bus error, retrying
> ds1wm ds1wm: pass: 92 bus error, retrying
> ds1wm ds1wm: pass: 93 bus error, retrying
> ds1wm ds1wm: pass: 1 bus error, retrying
> ds1wm ds1wm: pass: 2 bus error, retrying
> ds1wm ds1wm: pass: 3 bus error, retrying
> <snip>
> ds1wm ds1wm: pass: 29 bus error, retrying
> ds1wm ds1wm: pass: 30 bus error, retrying
> ds1wm ds1wm: pass: 31 bus error, retrying
> ds1wm ds1wm: pass: 1 bus error, retrying
> ds1wm ds1wm: pass: 2 bus error, retrying
> ds1wm ds1wm: pass: 3 bus error, retrying
> <snip>
> ds1wm ds1wm: pass: 98 bus error, retrying
> ds1wm ds1wm: pass: 99 bus error, retrying
> ds1wm ds1wm: pass: 100 bus error, retrying
> ds1wm ds1wm: pass: 1 bus error, retrying
> ds1wm ds1wm: pass: 2 bus error, retrying
> ds1wm ds1wm: pass: 3 bus error, retrying
> <snip>
> ds1wm ds1wm: pass: 92 bus error, retrying
> ds1wm ds1wm: pass: 93 bus error, retrying
> ds1wm ds1wm: pass: 94 bus error, retrying
> ds1wm ds1wm: pass: 1 bus error, retrying
> ds1wm ds1wm: pass: 2 bus error, retrying
> ds1wm ds1wm: pass: 3 bus error, retrying
> <snip>
> ds1wm ds1wm: pass: 98 bus error, retrying
> ds1wm ds1wm: pass: 99 bus error, retrying
> ds1wm ds1wm: pass: 100 bus error, retrying
> <snip>
>
> The visible result is that the battery charging LED is erratic; sometimes it works, mostly it doesn't.
>
> The linux-2.6.39 DS1WM 1-wire driver worked OK. I haven't tried 3.0-rc1, 3.0-rc2, or 3.0-rc3.
>
> Regards.
Jean-Francois Dagenais
Software Architect - B.Sc.A
Experience the new veo phased array flaw detector at www.sonatestveo.com.
Sonatest AP
2900 chemin des Quatre-Bourgeois
Bureau 305
Quebec City Quebec G1V 1Y4
T| +1 (418) 683 6222 x106 F| +1 (418) 683 7032 M| W| www.sonatest.com
This message (and any associated files) is intended only for the use of lost.distance@yahoo.com, linux-kernel@vger.kernel.org, johnpol@2ka.mipt.ru and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the above recipient(s) you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.
Think green - help the environment by not printing this email.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: w1/ds1wm regression after 2.6.39: "bus error, retrying"
2011-06-24 16:15 ` Jean-François Dagenais
@ 2011-06-24 19:07 ` Paul Parsons
2011-06-24 20:00 ` Jean-François Dagenais
0 siblings, 1 reply; 12+ messages in thread
From: Paul Parsons @ 2011-06-24 19:07 UTC (permalink / raw)
To: Jean-François Dagenais; +Cc: linux-kernel, johnpol
Hi Jean-Francois,
I think I've found the problem.
On a hunch I restored the msleep() call that had been removed from ds1wm_reset() after 2.6.39:
--- clean-3.0-rc4/drivers/w1/masters/ds1wm.c 2011-06-21 04:25:46.000000000 +0100
+++ linux-3.0-rc4/drivers/w1/masters/ds1wm.c 2011-06-24 19:58:03.340701823 +0100
@@ -182,6 +182,8 @@ static int ds1wm_reset(struct ds1wm_data
return 1;
}
+ msleep(1);
+
if (!ds1wm_data->slave_present) {
dev_dbg(&ds1wm_data->pdev->dev, "reset: no devices found\n");
return 1;
This has completely eliminated the "bus error, retrying" error messages, and the hx4700 seems to be functioning normally again.
Regards,
Paul
--- On Fri, 24/6/11, Jean-François Dagenais <dagenaisj@sonatest.com> wrote:
> From: Jean-François Dagenais <dagenaisj@sonatest.com>
> Subject: Re: w1/ds1wm regression after 2.6.39: "bus error, retrying"
> To: "Paul Parsons" <lost.distance@yahoo.com>
> Cc: linux-kernel@vger.kernel.org, johnpol@2ka.mipt.ru
> Date: Friday, 24 June, 2011, 17:15
> Hi Paul,
>
> Sorry to hear that. 2.6.39's ds1wm driver did not support
> dynamically finding the slaves on the bus, it would limit
> it's search to 1 and exit. My modifications implement the
> hardware assisted search as documented by the ds1wm spec
> sheet.
>
> There are a couple of ways you can workaround the problem
> (temporarily or permanently). You might disable the bus
> scanning altogether (like I explain below) and insert your
> slave manually (as documented in the kernel w1 docs). If
> only one slave is present, the bus master will usually just
> skip the ROM matching part of the communication by doing a
> "SKIP ROM" which essentially says to the slave "whoever you
> are, I am talking to you". You could also patch the
> ds1wm_search function to make it look like it was in 2.6.39,
> or just use the whole file if it worked fine for you.
>
> Now, to find the real problem, could you try the
> following:
> - to limit trace noise, disable the w1 auto probe by
> setting the search count to 0, either in "wire" module load
> ("search_count=0" in /etc/modprobe.conf or the like) or int
> /sys under your w1 master instance
> - build the ds1wm with "#define DEBUG" at the top (before
> headers), this will prints lots of debug about the
> accelerated search algorithm progress. (you could also set
> the retry count to something less than 100 to also limit
> noise in the trace)
> - once booted, trigger one search manually by writing 1 in
> /sys/bus/w1/devices/w1\ bus\ master/w1_master_search
> dmesg will contain a nice trace (although big)
>
> Do you have more than one slave device on the ds1wm bus?
>
> I will try to help as much as I can.
> /jfd
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: w1/ds1wm regression after 2.6.39: "bus error, retrying"
2011-06-24 19:07 ` Paul Parsons
@ 2011-06-24 20:00 ` Jean-François Dagenais
2011-06-24 21:32 ` Paul Parsons
0 siblings, 1 reply; 12+ messages in thread
From: Jean-François Dagenais @ 2011-06-24 20:00 UTC (permalink / raw)
To: Paul Parsons; +Cc: linux-kernel, johnpol
On Jun 24, 2011, at 15:07, Paul Parsons wrote:
> Hi Jean-Francois,
>
> I think I've found the problem.
>
> On a hunch I restored the msleep() call that had been removed from ds1wm_reset() after 2.6.39:
>
> --- clean-3.0-rc4/drivers/w1/masters/ds1wm.c 2011-06-21 04:25:46.000000000 +0100
> +++ linux-3.0-rc4/drivers/w1/masters/ds1wm.c 2011-06-24 19:58:03.340701823 +0100
> @@ -182,6 +182,8 @@ static int ds1wm_reset(struct ds1wm_data
> return 1;
> }
>
> + msleep(1);
> +
> if (!ds1wm_data->slave_present) {
> dev_dbg(&ds1wm_data->pdev->dev, "reset: no devices found\n");
> return 1;
>
> This has completely eliminated the "bus error, retrying" error messages, and the hx4700 seems to be functioning normally again.
The sleep I removed there only delays the time between the reset pulse and the function exiting, it doesn't populate the "slave_present" variable with a different value. The reset pulse and the wait that the ds1wm implements (by raising an interrupt at the end of it all) is spec'ed on the 1-wire specification, and the DS1WM_TIMEOUT is a really long time. So there should be plenty of time for the slaves to acknowledge the reset and participate in further communications.
So here's my hunch. We observed this here on our circuit too. It is possible that the pull-up resistor on your circuit is too resistive which would make the slave device fail to properly come back to life after the reset pulse (bus shorted to the ground) when the drain opens, and hence not able to cope well with the search that follows. The 1ms wait basically gives the slave(s) time to charge up again (with the drain open, the voltage is high).
The weird thing is that the ds1wm_reset function returns 0, since the while loop executes more than once, so it did find a slave (slave_present obtained from the PDR status bit), so the slave is kinda there... But the search fails somehow after that. Maybe there is something in your slave's spec sheet that could help, although the ds1wm reset timings. So I still think the debug trace and knowing if you have only one slave on the bus would help me figure this out. New question: what slave(s)? is it the DS2760?
PS: there are also controls in the DS1WM_CNTRL register that has to do with strong-pull-ups which are just not used by the driver yet. refer to: http://datasheets.maxim-ic.com/en/ds/DS1WM.pdf
>
> Regards,
> Paul
>
> --- On Fri, 24/6/11, Jean-François Dagenais <dagenaisj@sonatest.com> wrote:
>
>> From: Jean-François Dagenais <dagenaisj@sonatest.com>
>> Subject: Re: w1/ds1wm regression after 2.6.39: "bus error, retrying"
>> To: "Paul Parsons" <lost.distance@yahoo.com>
>> Cc: linux-kernel@vger.kernel.org, johnpol@2ka.mipt.ru
>> Date: Friday, 24 June, 2011, 17:15
>> Hi Paul,
>>
>> Sorry to hear that. 2.6.39's ds1wm driver did not support
>> dynamically finding the slaves on the bus, it would limit
>> it's search to 1 and exit. My modifications implement the
>> hardware assisted search as documented by the ds1wm spec
>> sheet.
>>
>> There are a couple of ways you can workaround the problem
>> (temporarily or permanently). You might disable the bus
>> scanning altogether (like I explain below) and insert your
>> slave manually (as documented in the kernel w1 docs). If
>> only one slave is present, the bus master will usually just
>> skip the ROM matching part of the communication by doing a
>> "SKIP ROM" which essentially says to the slave "whoever you
>> are, I am talking to you". You could also patch the
>> ds1wm_search function to make it look like it was in 2.6.39,
>> or just use the whole file if it worked fine for you.
>>
>> Now, to find the real problem, could you try the
>> following:
>> - to limit trace noise, disable the w1 auto probe by
>> setting the search count to 0, either in "wire" module load
>> ("search_count=0" in /etc/modprobe.conf or the like) or int
>> /sys under your w1 master instance
>> - build the ds1wm with "#define DEBUG" at the top (before
>> headers), this will prints lots of debug about the
>> accelerated search algorithm progress. (you could also set
>> the retry count to something less than 100 to also limit
>> noise in the trace)
>> - once booted, trigger one search manually by writing 1 in
>> /sys/bus/w1/devices/w1\ bus\ master/w1_master_search
>> dmesg will contain a nice trace (although big)
>>
>> Do you have more than one slave device on the ds1wm bus?
>>
>> I will try to help as much as I can.
>> /jfd
>
> --
> 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/
Jean-Francois Dagenais
Software Architect - B.Sc.A
Experience the new veo phased array flaw detector at www.sonatestveo.com.
Sonatest AP
2900 chemin des Quatre-Bourgeois
Bureau 305
Quebec City Quebec G1V 1Y4
T| +1 (418) 683 6222 x106 F| +1 (418) 683 7032 M| W| www.sonatest.com
This message (and any associated files) is intended only for the use of lost.distance@yahoo.com, linux-kernel@vger.kernel.org, johnpol@2ka.mipt.ru and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the above recipient(s) you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.
Think green - help the environment by not printing this email.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: w1/ds1wm regression after 2.6.39: "bus error, retrying"
2011-06-24 20:00 ` Jean-François Dagenais
@ 2011-06-24 21:32 ` Paul Parsons
2011-06-25 12:54 ` Jean-François Dagenais
0 siblings, 1 reply; 12+ messages in thread
From: Paul Parsons @ 2011-06-24 21:32 UTC (permalink / raw)
To: Jean-François Dagenais; +Cc: linux-kernel, johnpol
Here's the debug output from ds1wm_search():
ds1wm ds1wm: search begin
ds1wm ds1wm: pass: 1 r : 0x0000000000000000 writing SEARCH_ROM
ds1wm ds1wm: pass: 1 entering ASM
ds1wm ds1wm: pass: 1 begining nibble loop
ds1wm ds1wm: pass: 1 r': 0xd300001085da8430 d:0x0000000000000000
ds1wm ds1wm: pass: 1 nibble loop complete, exiting ASM
ds1wm ds1wm: pass: 1 resetting bus
ds1wm ds1wm: pass: 1 found 0xd300001085da8430
ds1wm ds1wm: pass: 1 complete, preparing next pass
ds1wm ds1wm: pass: 1 new d:0x0000000000000000 MS discrep bit:-1
ds1wm ds1wm: pass: 1 total: 1 search done ms d bit pos: -1
The hx4700 does indeed have a ds2760 connected to the ds1wm. I believe the ds1wm is integrated into the HTC ASIC3, but my knowledge of the hardware is almost zero.
Regards,
Paul
--- On Fri, 24/6/11, Jean-François Dagenais <dagenaisj@sonatest.com> wrote:
> The sleep I removed there only delays the time between the
> reset pulse and the function exiting, it doesn't populate
> the "slave_present" variable with a different value. The
> reset pulse and the wait that the ds1wm implements (by
> raising an interrupt at the end of it all) is spec'ed on the
> 1-wire specification, and the DS1WM_TIMEOUT is a really long
> time. So there should be plenty of time for the slaves to
> acknowledge the reset and participate in further
> communications.
>
> So here's my hunch. We observed this here on our circuit
> too. It is possible that the pull-up resistor on your
> circuit is too resistive which would make the slave device
> fail to properly come back to life after the reset pulse
> (bus shorted to the ground) when the drain opens, and hence
> not able to cope well with the search that follows. The 1ms
> wait basically gives the slave(s) time to charge up again
> (with the drain open, the voltage is high).
>
> The weird thing is that the ds1wm_reset function returns 0,
> since the while loop executes more than once, so it did find
> a slave (slave_present obtained from the PDR status bit), so
> the slave is kinda there... But the search fails somehow
> after that. Maybe there is something in your slave's spec
> sheet that could help, although the ds1wm reset timings. So
> I still think the debug trace and knowing if you have only
> one slave on the bus would help me figure this out. New
> question: what slave(s)? is it the DS2760?
>
> PS: there are also controls in the DS1WM_CNTRL register
> that has to do with strong-pull-ups which are just not used
> by the driver yet. refer to: http://datasheets.maxim-ic.com/en/ds/DS1WM.pdf
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: w1/ds1wm regression after 2.6.39: "bus error, retrying"
2011-06-24 21:32 ` Paul Parsons
@ 2011-06-25 12:54 ` Jean-François Dagenais
0 siblings, 0 replies; 12+ messages in thread
From: Jean-François Dagenais @ 2011-06-25 12:54 UTC (permalink / raw)
To: Paul Parsons; +Cc: linux-kernel, johnpol
On 2011-06-24, at 17:32, Paul Parsons wrote:
> Here's the debug output from ds1wm_search():
>
> ds1wm ds1wm: search begin
> ds1wm ds1wm: pass: 1 r : 0x0000000000000000 writing SEARCH_ROM
> ds1wm ds1wm: pass: 1 entering ASM
> ds1wm ds1wm: pass: 1 begining nibble loop
> ds1wm ds1wm: pass: 1 r': 0xd300001085da8430 d:0x0000000000000000
> ds1wm ds1wm: pass: 1 nibble loop complete, exiting ASM
> ds1wm ds1wm: pass: 1 resetting bus
> ds1wm ds1wm: pass: 1 found 0xd300001085da8430
> ds1wm ds1wm: pass: 1 complete, preparing next pass
> ds1wm ds1wm: pass: 1 new d:0x0000000000000000 MS discrep bit:-1
> ds1wm ds1wm: pass: 1 total: 1 search done ms d bit pos: -1
>
> The hx4700 does indeed have a ds2760 connected to the ds1wm. I believe the ds1wm is integrated into the HTC ASIC3, but my knowledge of the hardware is almost zero.
>
> Regards,
> Paul
Hi again Paul,
This seems to be the output after you have restored the msleep. Could you provide it without so we can get a better idea as to what happened. If indeed this is a major regression for many devices, we'll have to submit a patch to the main branch.
/jfd
>
> --- On Fri, 24/6/11, Jean-François Dagenais <dagenaisj@sonatest.com> wrote:
>> The sleep I removed there only delays the time between the
>> reset pulse and the function exiting, it doesn't populate
>> the "slave_present" variable with a different value. The
>> reset pulse and the wait that the ds1wm implements (by
>> raising an interrupt at the end of it all) is spec'ed on the
>> 1-wire specification, and the DS1WM_TIMEOUT is a really long
>> time. So there should be plenty of time for the slaves to
>> acknowledge the reset and participate in further
>> communications.
>>
>> So here's my hunch. We observed this here on our circuit
>> too. It is possible that the pull-up resistor on your
>> circuit is too resistive which would make the slave device
>> fail to properly come back to life after the reset pulse
>> (bus shorted to the ground) when the drain opens, and hence
>> not able to cope well with the search that follows. The 1ms
>> wait basically gives the slave(s) time to charge up again
>> (with the drain open, the voltage is high).
>>
>> The weird thing is that the ds1wm_reset function returns 0,
>> since the while loop executes more than once, so it did find
>> a slave (slave_present obtained from the PDR status bit), so
>> the slave is kinda there... But the search fails somehow
>> after that. Maybe there is something in your slave's spec
>> sheet that could help, although the ds1wm reset timings. So
>> I still think the debug trace and knowing if you have only
>> one slave on the bus would help me figure this out. New
>> question: what slave(s)? is it the DS2760?
>>
>> PS: there are also controls in the DS1WM_CNTRL register
>> that has to do with strong-pull-ups which are just not used
>> by the driver yet. refer to: http://datasheets.maxim-ic.com/en/ds/DS1WM.pdf
> --
> 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/
Jean-Francois Dagenais
Software Architect - B.Sc.A
Experience the new veo phased array flaw detector at www.sonatestveo.com.
Sonatest AP
2900 chemin des Quatre-Bourgeois
Bureau 305
Quebec City Quebec G1V 1Y4
T| +1 (418) 683 6222 x106 F| +1 (418) 683 7032 M| W| www.sonatest.com
This message (and any associated files) is intended only for the use of lost.distance@yahoo.com, linux-kernel@vger.kernel.org, johnpol@2ka.mipt.ru and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the above recipient(s) you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.
Think green - help the environment by not printing this email.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-07-06 21:26 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-26 0:58 w1/ds1wm regression after 2.6.39: "bus error, retrying" Paul Parsons
2011-06-27 13:17 ` [PATCH] w1: ds1wm: add a reset recovery parameter Jean-François Dagenais
2011-06-28 9:59 ` Paul Parsons
2011-07-05 21:46 ` Andrew Morton
2011-07-06 13:16 ` Jean-François Dagenais
2011-07-06 21:25 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2011-06-24 15:08 w1/ds1wm regression after 2.6.39: "bus error, retrying" Paul Parsons
2011-06-24 16:15 ` Jean-François Dagenais
2011-06-24 19:07 ` Paul Parsons
2011-06-24 20:00 ` Jean-François Dagenais
2011-06-24 21:32 ` Paul Parsons
2011-06-25 12:54 ` Jean-François Dagenais
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).