From: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
To: dedekind1@gmail.com
Cc: Tony Lindgren <tony@atomide.com>,
Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-omap@vger.kernel.org, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
Date: Wed, 25 Apr 2012 19:01:14 +0200 [thread overview]
Message-ID: <1587089.0XMyH6e1Ic@acer> (raw)
In-Reply-To: <1335366823.6356.11.camel@koala>
Dnia środa, 25 kwietnia 2012 18:13:38 Artem Bityutskiy pisze:
> On Tue, 2012-04-17 at 15:49 +0200, Janusz Krzysztofik wrote:
> > A call to request_mem_region() has been introduced in the omap-gpio
> > driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
> > "gpio/omap: Use devm_ API and add request_mem_region"). This change
> > prevented the Amstrad Delta NAND driver, which was doing the same in
> > order to take control over OMAP MPU I/O lines that the NAND device
hangs
> > off, from loading successfully.
> >
> > There is another driver, omap-keypad, which also manipulates OMAP
MPUIO
> > registers, but has never been calling request_mem_region() on
startup,
> > so it's not affected by the change in the gpio-omap and works
correctly.
> >
> > Drop request_mem_region() call and related bits from ams-delta NAND
> > driver.
> >
> > Created and tested against linux-3.4-rc3.
> >
> > Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
>
> How about race conditions? Where is the guarantee that these 2 drivers
> won't affect each other when doing I/O at the same time to the same HW
> resources?
Both drivers use separate subsets of registers that belong to the OMAP1
MPU I/O device, but are used for controlling different sets of I/O pins.
The NAND driver reads/writes the folowing registers:
- OMAP_MPUIO_INPUT_LATCH,
- OMAP_MPUIO_OUTPUT,
- OMAP_MPUIO_IO_CNTL,
while the keypad driver - the following:
- OMAP_MPUIO_KBR_LATCH,
- OMAP_MPUIO_KBC,
- OMAP_MPUIO_KBD_MASKIT
- OMAP_MPUIO_GPIO_DEBOUNCING.
Both subsets are non-overlapping, and we rely on the drivers being free
of bugs and doing their job correctly, not stepping on each others'
feet, I guess.
Thanks,
Janusz
WARNING: multiple messages have this Message-ID (diff)
From: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
To: dedekind1@gmail.com
Cc: David Woodhouse <dwmw2@infradead.org>,
Tony Lindgren <tony@atomide.com>,
Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-omap@vger.kernel.org
Subject: Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
Date: Wed, 25 Apr 2012 19:01:14 +0200 [thread overview]
Message-ID: <1587089.0XMyH6e1Ic@acer> (raw)
In-Reply-To: <1335366823.6356.11.camel@koala>
Dnia środa, 25 kwietnia 2012 18:13:38 Artem Bityutskiy pisze:
> On Tue, 2012-04-17 at 15:49 +0200, Janusz Krzysztofik wrote:
> > A call to request_mem_region() has been introduced in the omap-gpio
> > driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
> > "gpio/omap: Use devm_ API and add request_mem_region"). This change
> > prevented the Amstrad Delta NAND driver, which was doing the same in
> > order to take control over OMAP MPU I/O lines that the NAND device
hangs
> > off, from loading successfully.
> >
> > There is another driver, omap-keypad, which also manipulates OMAP
MPUIO
> > registers, but has never been calling request_mem_region() on
startup,
> > so it's not affected by the change in the gpio-omap and works
correctly.
> >
> > Drop request_mem_region() call and related bits from ams-delta NAND
> > driver.
> >
> > Created and tested against linux-3.4-rc3.
> >
> > Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
>
> How about race conditions? Where is the guarantee that these 2 drivers
> won't affect each other when doing I/O at the same time to the same HW
> resources?
Both drivers use separate subsets of registers that belong to the OMAP1
MPU I/O device, but are used for controlling different sets of I/O pins.
The NAND driver reads/writes the folowing registers:
- OMAP_MPUIO_INPUT_LATCH,
- OMAP_MPUIO_OUTPUT,
- OMAP_MPUIO_IO_CNTL,
while the keypad driver - the following:
- OMAP_MPUIO_KBR_LATCH,
- OMAP_MPUIO_KBC,
- OMAP_MPUIO_KBD_MASKIT
- OMAP_MPUIO_GPIO_DEBOUNCING.
Both subsets are non-overlapping, and we rely on the drivers being free
of bugs and doing their job correctly, not stepping on each others'
feet, I guess.
Thanks,
Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
To: dedekind1@gmail.com
Cc: David Woodhouse <dwmw2@infradead.org>,
Tony Lindgren <tony@atomide.com>,
Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-omap@vger.kernel.org
Subject: Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
Date: Wed, 25 Apr 2012 19:01:14 +0200 [thread overview]
Message-ID: <1587089.0XMyH6e1Ic@acer> (raw)
In-Reply-To: <1335366823.6356.11.camel@koala>
Dnia środa, 25 kwietnia 2012 18:13:38 Artem Bityutskiy pisze:
> On Tue, 2012-04-17 at 15:49 +0200, Janusz Krzysztofik wrote:
> > A call to request_mem_region() has been introduced in the omap-gpio
> > driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
> > "gpio/omap: Use devm_ API and add request_mem_region"). This change
> > prevented the Amstrad Delta NAND driver, which was doing the same in
> > order to take control over OMAP MPU I/O lines that the NAND device
hangs
> > off, from loading successfully.
> >
> > There is another driver, omap-keypad, which also manipulates OMAP
MPUIO
> > registers, but has never been calling request_mem_region() on
startup,
> > so it's not affected by the change in the gpio-omap and works
correctly.
> >
> > Drop request_mem_region() call and related bits from ams-delta NAND
> > driver.
> >
> > Created and tested against linux-3.4-rc3.
> >
> > Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
>
> How about race conditions? Where is the guarantee that these 2 drivers
> won't affect each other when doing I/O at the same time to the same HW
> resources?
Both drivers use separate subsets of registers that belong to the OMAP1
MPU I/O device, but are used for controlling different sets of I/O pins.
The NAND driver reads/writes the folowing registers:
- OMAP_MPUIO_INPUT_LATCH,
- OMAP_MPUIO_OUTPUT,
- OMAP_MPUIO_IO_CNTL,
while the keypad driver - the following:
- OMAP_MPUIO_KBR_LATCH,
- OMAP_MPUIO_KBC,
- OMAP_MPUIO_KBD_MASKIT
- OMAP_MPUIO_GPIO_DEBOUNCING.
Both subsets are non-overlapping, and we rely on the drivers being free
of bugs and doing their job correctly, not stepping on each others'
feet, I guess.
Thanks,
Janusz
next prev parent reply other threads:[~2012-04-25 17:16 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-17 13:49 [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure Janusz Krzysztofik
2012-04-17 13:49 ` Janusz Krzysztofik
2012-04-17 13:49 ` Janusz Krzysztofik
2012-04-25 15:13 ` Artem Bityutskiy
2012-04-25 15:13 ` Artem Bityutskiy
2012-04-25 17:01 ` Janusz Krzysztofik [this message]
2012-04-25 17:01 ` Janusz Krzysztofik
2012-04-25 17:01 ` Janusz Krzysztofik
2012-04-26 5:20 ` Artem Bityutskiy
2012-04-26 5:20 ` Artem Bityutskiy
2012-04-30 18:09 ` Janusz Krzysztofik
2012-04-30 18:09 ` Janusz Krzysztofik
2012-05-04 17:11 ` Tony Lindgren
2012-05-04 17:11 ` Tony Lindgren
2012-05-04 19:23 ` Janusz Krzysztofik
2012-05-04 19:23 ` Janusz Krzysztofik
2012-05-07 20:51 ` [PATCH v2 3.4-rc6] MTD: NAND: ams-delta: fix " Janusz Krzysztofik
2012-05-07 20:51 ` Janusz Krzysztofik
2012-05-07 20:51 ` Janusz Krzysztofik
2012-05-08 7:03 ` Artem Bityutskiy
2012-05-08 7:03 ` Artem Bityutskiy
2012-05-08 7:03 ` Artem Bityutskiy
2012-05-08 7:11 ` Artem Bityutskiy
2012-05-08 7:11 ` Artem Bityutskiy
2012-05-08 7:11 ` Artem Bityutskiy
2012-05-08 18:46 ` Janusz Krzysztofik
2012-05-08 18:46 ` Janusz Krzysztofik
2012-05-08 18:46 ` Janusz Krzysztofik
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=1587089.0XMyH6e1Ic@acer \
--to=jkrzyszt@tis.icnet.pl \
--cc=Artem.Bityutskiy@linux.intel.com \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
/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.