All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.