From: Harald Welte <laforge@gnumonks.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
linux-kernel@vger.kernel.org, Deepak Saxena <dsaxena@laptop.org>,
linux-fbdev@vger.kernel.org, JosephChan@via.com.tw,
ScottFang@viatech.com.cn
Subject: Re: [PATCH 10/11] viafb: rework the I2C support in the VIA framebuffer driver
Date: Sat, 24 Apr 2010 15:53:16 +0200 [thread overview]
Message-ID: <20100424135316.GR24811@prithivi.gnumonks.org> (raw)
In-Reply-To: <20100424073359.349b4397@bike.lwn.net>
Hi Jon,
On Sat, Apr 24, 2010 at 07:33:59AM -0600, Jonathan Corbet wrote:
> This patch creates an i2c bus on every port which could conceivably
> have one. That's rather different from the original code, which
> created a single bus (in the kernel) then swapped it between ports 31
> and 2c in weird ways. In particular, it takes over ports which,
> conceivably, somebody else could be using for GPIO. So, perhaps, there
> is some contention going on there.
>
> If my hypothesis is correct, this problem will go away with the
> application of the second series, which doesn't create i2c buses on
> ports used for GPIO. But the problem should be fixed here so we don't
> have things broken in the middle.
>
> Harald, does this reasoning make sense to you? If so, what I should do
> is bring forward just enough of the via-core code to be able to
> configure which ports actually get i2c buses created on them. Easily
> done.
It makes a lot of sense. When I added all possible I2C busses, this was merely
the result of "let's try to make sure every possible configuration is
supported" rather than some kind of neccessity.
Simply converting the original two busses to the new code is definitely
the way to go. Maybe we'll keep the code for the other two around, but
somehow keep them inactive and don't advertise them unless somebody explicitly
does so?
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
next prev parent reply other threads:[~2010-04-24 15:09 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-18 18:21 [RFC] Initial OLPC Viafb merge (V2) Jonathan Corbet
2010-04-18 18:21 ` [PATCH 01/11] [FB] viafb: Fix various resource leaks during module_init() Jonathan Corbet
2010-04-18 18:21 ` [PATCH 02/11] viafb: use proper pci config API Jonathan Corbet
2010-04-18 18:21 ` [PATCH 03/11] viafb: Unmap the frame buffer on initialization error Jonathan Corbet
2010-04-18 18:21 ` [PATCH 04/11] viafb: Retain GEMODE reserved bits Jonathan Corbet
2010-04-18 18:21 ` [PATCH 05/11] viafb: Unify duplicated set_bpp() code Jonathan Corbet
2010-04-18 18:21 ` [PATCH 06/11] viafb: Determine type of 2D engine and store it in chip_info Jonathan Corbet
2010-04-18 18:21 ` [PATCH 07/11] viafb: complete support for VX800/VX855 accelerated framebuffer Jonathan Corbet
2010-04-18 18:21 ` [PATCH 08/11] viafb: Add 1200x900 DCON/LCD panel modes for OLPC XO-1.5 Jonathan Corbet
2010-04-18 18:21 ` [PATCH 09/11] viafb: Do not probe for LVDS/TMDS on " Jonathan Corbet
2010-04-23 20:56 ` Florian Tobias Schandinat
2010-04-23 21:09 ` Jonathan Corbet
2010-04-18 18:21 ` [PATCH 10/11] viafb: rework the I2C support in the VIA framebuffer driver Jonathan Corbet
2010-04-23 21:12 ` Florian Tobias Schandinat
2010-04-23 21:57 ` Jonathan Corbet
2010-04-23 22:40 ` Florian Tobias Schandinat
2010-04-23 22:52 ` Jonathan Corbet
2010-04-23 23:21 ` Florian Tobias Schandinat
2010-04-24 10:47 ` Florian Tobias Schandinat
2010-04-24 13:33 ` Jonathan Corbet
2010-04-24 13:53 ` Harald Welte [this message]
2010-04-25 14:38 ` Jonathan Corbet
2010-04-25 15:56 ` Florian Tobias Schandinat
2010-04-26 19:40 ` Jonathan Corbet
2010-04-18 18:21 ` [PATCH 11/11] suppress verbose debug messages: change printk() to DEBUG_MSG() Jonathan Corbet
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=20100424135316.GR24811@prithivi.gnumonks.org \
--to=laforge@gnumonks.org \
--cc=FlorianSchandinat@gmx.de \
--cc=JosephChan@via.com.tw \
--cc=ScottFang@viatech.com.cn \
--cc=corbet@lwn.net \
--cc=dsaxena@laptop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®