From: Felipe Balbi <balbi@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-omap@vger.kernel.org, Tony Lindgren <tony@atomide.com>,
stable@vger.kernel.org, linux-i2c@vger.kernel.org,
Linux ARM Kernel Mailing List
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] OMAP: board-files: fix i2c_bus for tfp410
Date: Fri, 16 Nov 2012 15:51:55 +0200 [thread overview]
Message-ID: <20121116135155.GE18527@arwen.pp.htv.fi> (raw)
In-Reply-To: <1353068553-26897-1-git-send-email-tomi.valkeinen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2068 bytes --]
Hi,
On Fri, Nov 16, 2012 at 02:22:33PM +0200, Tomi Valkeinen wrote:
> The i2c handling in tfp410 driver, which handles converting parallel RGB
> to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af. The
commit summary should be added in () after commit hash. This would look
like:
'was changed in 958f271 (OMAPDSS: TFP410: pdata rewrite).'
> patch changed what value the driver considers as invalid/undefined.
> Before the patch 0 was the invalid value, but as 0 is a valid bus
^
missing comma (,) character here.
> number, the patch changed this to -1.
>
> However, the fact was missed that many board files do not define the bus
> number at all, thus it's left to 0. This causes the driver to fail to
> get the i2c bus, exiting from the driver's probe with an error, meaning
> that the DVI output does not work for those boards.
>
> This patch fixes the issue by changing the i2c_bus number field in the
> driver's platform data from u16 to int, and setting the bus number to -1
> in the board files for the boards that did not define the bus. The
> exception is devkit8000, for which the bus is set to 1, which is the
> correct bus for that board.
>
> The bug exists in v3.5+ kernels.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reported-by: Thomas Weber <thomas@tomweber.eu>
> [for v3.5, v3.6 stable kernels]
> Cc: stable@vger.kernel.org
This format is peculiar. Usually people use:
Cc: stable@vger.kernel.org # v3.5 v3.6
To be fair, the whole i2c_bus_num looks like a big hackery introduced by
the way panel drivers are written for OMAP DSS.
TFP410 is an I2C client, not an OMAPDSS client. After a quick look at
the driver, there's is no such thing as a DSS bus, so looks like you
should have an I2C driver for TFP410 and the whole DSS stuff should be
just a list of clients, but not a struct bus at all.
The fact that you have to pass the I2C bus number down to the panel
driver is already a big indication of how wrong this is, IMHO.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: balbi@ti.com (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] OMAP: board-files: fix i2c_bus for tfp410
Date: Fri, 16 Nov 2012 15:51:55 +0200 [thread overview]
Message-ID: <20121116135155.GE18527@arwen.pp.htv.fi> (raw)
In-Reply-To: <1353068553-26897-1-git-send-email-tomi.valkeinen@ti.com>
Hi,
On Fri, Nov 16, 2012 at 02:22:33PM +0200, Tomi Valkeinen wrote:
> The i2c handling in tfp410 driver, which handles converting parallel RGB
> to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af. The
commit summary should be added in () after commit hash. This would look
like:
'was changed in 958f271 (OMAPDSS: TFP410: pdata rewrite).'
> patch changed what value the driver considers as invalid/undefined.
> Before the patch 0 was the invalid value, but as 0 is a valid bus
^
missing comma (,) character here.
> number, the patch changed this to -1.
>
> However, the fact was missed that many board files do not define the bus
> number at all, thus it's left to 0. This causes the driver to fail to
> get the i2c bus, exiting from the driver's probe with an error, meaning
> that the DVI output does not work for those boards.
>
> This patch fixes the issue by changing the i2c_bus number field in the
> driver's platform data from u16 to int, and setting the bus number to -1
> in the board files for the boards that did not define the bus. The
> exception is devkit8000, for which the bus is set to 1, which is the
> correct bus for that board.
>
> The bug exists in v3.5+ kernels.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reported-by: Thomas Weber <thomas@tomweber.eu>
> [for v3.5, v3.6 stable kernels]
> Cc: stable at vger.kernel.org
This format is peculiar. Usually people use:
Cc: stable at vger.kernel.org # v3.5 v3.6
To be fair, the whole i2c_bus_num looks like a big hackery introduced by
the way panel drivers are written for OMAP DSS.
TFP410 is an I2C client, not an OMAPDSS client. After a quick look at
the driver, there's is no such thing as a DSS bus, so looks like you
should have an I2C driver for TFP410 and the whole DSS stuff should be
just a list of clients, but not a struct bus at all.
The fact that you have to pass the I2C bus number down to the panel
driver is already a big indication of how wrong this is, IMHO.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121116/547da487/attachment.sig>
next prev parent reply other threads:[~2012-11-16 13:51 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-16 12:22 [PATCH] OMAP: board-files: fix i2c_bus for tfp410 Tomi Valkeinen
2012-11-16 13:51 ` Felipe Balbi [this message]
2012-11-16 13:51 ` Felipe Balbi
[not found] ` <20121116135155.GE18527-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-11-16 14:27 ` Tomi Valkeinen
2012-11-16 14:27 ` Tomi Valkeinen
2012-11-16 15:19 ` Felipe Balbi
2012-11-16 15:19 ` Felipe Balbi
2012-11-16 15:39 ` Tomi Valkeinen
2012-11-16 15:39 ` Tomi Valkeinen
[not found] ` <50A65E40.9040208-l0cyMroinI0@public.gmane.org>
2012-11-16 18:21 ` tfp410 and i2c_bus_num (was: Re: [PATCH] OMAP: board-files: fix i2c_bus for tfp410) Felipe Balbi
2012-11-16 18:21 ` Felipe Balbi
[not found] ` <20121116182146.GC20496-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-11-17 5:41 ` tfp410 and i2c_bus_num Tomi Valkeinen
2012-11-17 5:41 ` Tomi Valkeinen
[not found] ` <50A72390.3050509-l0cyMroinI0@public.gmane.org>
2012-11-18 11:34 ` Felipe Balbi
2012-11-18 11:34 ` Felipe Balbi
[not found] ` <20121118113437.GB30462-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-11-19 6:38 ` Tomi Valkeinen
2012-11-19 6:38 ` Tomi Valkeinen
[not found] ` <50A9D3DD.6040807-l0cyMroinI0@public.gmane.org>
2012-11-19 9:27 ` Felipe Balbi
2012-11-19 9:27 ` Felipe Balbi
[not found] ` <20121119092744.GB4211-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-11-19 11:09 ` Tomi Valkeinen
2012-11-19 11:09 ` Tomi Valkeinen
[not found] ` <50AA1376.6060801-l0cyMroinI0@public.gmane.org>
2012-11-19 12:16 ` Felipe Balbi
2012-11-19 12:16 ` Felipe Balbi
[not found] ` <20121119121630.GC15540-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-11-21 17:57 ` Tony Lindgren
2012-11-21 17:57 ` Tony Lindgren
2012-11-22 8:28 ` Tomi Valkeinen
2012-11-22 8:28 ` Tomi Valkeinen
2012-11-22 8:39 ` [PATCHv2] OMAP: board-files: fix i2c_bus for tfp410 Tomi Valkeinen
2012-11-27 10:02 ` Thomas Weber
2012-11-30 9:30 ` Tomi Valkeinen
2012-12-14 17:23 ` Tony Lindgren
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=20121116135155.GE18527@arwen.pp.htv.fi \
--to=balbi@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tomi.valkeinen@ti.com \
--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.