From: Artem Bityutskiy <dedekind1@gmail.com>
To: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
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: Thu, 26 Apr 2012 08:20:59 +0300 [thread overview]
Message-ID: <1335417678.2290.7.camel@koala> (raw)
In-Reply-To: <1587089.0XMyH6e1Ic@acer>
[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]
On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote:
> 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.
First of all, I think this information should be in the commit message.
Also, some sort of comment in the driver code would be nice.
If locking the memory region is too coarse approach, the should have a
small separate omap-specific MPUIO subsystem which will be used by
drivers to access MPUIO?
Another question - should request_mem_region() be also removed from the
omap-gpio driver then? I think it is more sensible to put a comment
there that it is sharing MPIO with other drivers, instead of having an
illusion of exclusive memory region ownership.
But this is up to the OMAP community - I can take this patch to my
l2-mtd tree if you get an ack from Tony or other OMAP guys.
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2012-04-26 5:21 UTC|newest]
Thread overview: 11+ 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-25 15:13 ` Artem Bityutskiy
2012-04-25 17:01 ` Janusz Krzysztofik
2012-04-26 5:20 ` Artem Bityutskiy [this message]
2012-04-30 18:09 ` Janusz Krzysztofik
2012-05-04 17:11 ` Tony Lindgren
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-08 7:03 ` Artem Bityutskiy
2012-05-08 7:11 ` Artem Bityutskiy
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=1335417678.2290.7.camel@koala \
--to=dedekind1@gmail.com \
--cc=Artem.Bityutskiy@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=jkrzyszt@tis.icnet.pl \
--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 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).