linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: snjw23@gmail.com (Sylwester Nawrocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
Date: Sun, 05 Feb 2012 21:44:01 +0100	[thread overview]
Message-ID: <4F2EEA11.9080807@gmail.com> (raw)
In-Reply-To: <20120130201307.GV28397@ponder.secretlab.ca>

Hi Grant,

On 01/30/2012 09:13 PM, Grant Likely wrote:
> The whole 'cell-index' or 'id' thing is a BadIdea(tm).  Don't use it, and tell
> others not to do it when you see it.  There are some legacy uses in powerpc,
> but those were written before I and others knew better.
> 
> The *only* situation where cell-index is acceptable is when the driver
> absolutely must know which hardware instance it is driving because it
> needs to calculate offsets in a shared register or something, and even
> then it should not be used to set the pdev->id field. That situation
> does not look to be the case here.

Thanks a lot for the clarification. Some media device drivers use the pdev->id
field to enumerate hardware entities which are shown to user space libraries/
applications through the media device interface:
<http://linuxtv.org/downloads/v4l-dvb-apis/media-ioc-enum-entities.html>

The entity name is initialized from dev_name(&pdev->dev), which in DT case
will be rather random string AFAICS. Is using 'cell-index' property justified
in such cases ? 
 
> If you're using the DT, then let the core code dynamically assign the
> i2c adapter number.

Then it means that all uses if i2c_get_adapter() that take an I2C adapter 
number as an argument need to be converted accordingly, e.g. we need an OF
version of i2c_get_adapter() ?

The V4L core provides v4l2_i2c_new_subdev_board() function which is used
by the video bridge drivers to register its sub-devices - I2C clients 
(usually image sensors or video encoders). The I2C bus ids are usually 
provided as platform data to the bridge driver. Sounds like all this will
need to be reworked quite significantly for DT support.

---

Thanks,
Sylwester

  parent reply	other threads:[~2012-02-05 20:44 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-23  8:56 [RFC PATCH 0/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
2012-01-23  8:56 ` [RFC PATCH 1/7] ARM: davinci, intc: Add OF support for TI interrupt controller Heiko Schocher
2012-02-02  4:54   ` Grant Likely
2012-02-06  6:36     ` Heiko Schocher
2012-02-14  7:15       ` Heiko Schocher
2012-01-23  8:56 ` [RFC PATCH 2/7 v2] ARM: davinci: configure davinci aemif chipselects through OF Heiko Schocher
2012-01-23  8:56 ` [RFC PATCH 3/7] ARM: davinci: mux: add OF support Heiko Schocher
2012-01-23  8:56 ` [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: " Heiko Schocher
2012-01-23 19:20   ` Anatoly Sivov
2012-01-24  6:14     ` Heiko Schocher
2012-01-30 20:22   ` Grant Likely
2012-01-31 11:27     ` Heiko Schocher
2012-02-02  0:19       ` Grant Likely
2012-01-23  8:56 ` [RFC PATCH 5/7] ARM: davinci: i2c: " Heiko Schocher
2012-01-23 20:35   ` Sylwester Nawrocki
2012-01-24  7:18     ` Heiko Schocher
2012-01-24  9:51       ` Sylwester Nawrocki
2012-01-30 20:13         ` Grant Likely
2012-01-31  7:31           ` Heiko Schocher
2012-02-05 20:44           ` Sylwester Nawrocki [this message]
2012-01-30 20:04   ` Grant Likely
2012-01-31  7:14     ` Heiko Schocher
2012-02-13 23:37   ` Ben Dooks
2012-02-14  7:16     ` Heiko Schocher
2012-01-23  8:56 ` [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller Heiko Schocher
2012-01-23 23:59   ` Scott Wood
2012-01-24  7:23     ` Heiko Schocher
2012-01-24 19:45       ` Scott Wood
2012-01-25  7:09         ` Heiko Schocher
2012-01-26 20:33           ` Scott Wood
2012-01-27  6:40             ` Heiko Schocher
2012-01-27 17:02               ` Scott Wood
2012-01-23  8:56 ` [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
2012-01-30 20:32   ` Grant Likely
2012-01-31 13:04     ` Heiko Schocher
2012-02-01 10:20       ` Sergei Shtylyov
2012-02-02  0:17         ` Grant Likely

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=4F2EEA11.9080807@gmail.com \
    --to=snjw23@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).