public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <menon.nishanth@gmail.com>
To: "Woodruff, Richard" <r-woodruff2@ti.com>
Cc: linux-omap-open-source@linux.omap.com
Subject: Re: Moving I2C2 init to plat-omap/devices.c  ?
Date: Fri, 17 Nov 2006 01:41:47 +0530	[thread overview]
Message-ID: <455CC603.9050409@gmail.com> (raw)
In-Reply-To: <EA12F909C0431D458B9D18A176BEE4A508A01E5E@dlee02.ent.ti.com>

Woodruff, Richard stated on 11/16/2006 8:28 PM:
> IP version would clarify some aspects around differences and errata.
> You would still end up with both (chip & IP) as the integration of the
> IP into a chip is an area where things are different also.  I find USB
> client to be one which can be confusing.  From 1510-2420 there are many
> bug fixes and many are not apparent by register differences.  This can
> result in older ones being broke or newer ones not running to their
> potential when sharing.
I think a V3.x driver, if defined to handle IP of range 3.0>= x <4.0,
then it can have backward compatibility based on subversion information.
I can think of more ways this will work than a omap-version based
approach.. this may not be the thread to discuss that however..


> 
> By adding enough layers of indirection/functional pointer tables you can
> usually merge things.  However, this can make the code harder to follow.
> If people wanted to take the time to merge I suspect that making the HS
> driver work in a backward compatible manner might be easier than
> upgrading the FS one.  Given what you know today would you agree with
> that?  Getting any code into the I2C tree might take a bit of effort.
I am pointing at the fact that using FIFO changes our bulk of our logic,
we need to be depending on a different set of interrupts, the transfer
logic is different etc.. makes 70-80% code look different I think.. yes
we can still have the same ARDY,NAK,timeout handling..
I am not sure to what extent..

> Tony floated an interesting idea about creating an embedded I2C using
> Daivd's frame work.  This might allow faster integration of performance
> related changes and the like with out fighting with SMB people.
> 
Err... I dont know.. is it more useful to get lm-sensor to look at that?
I dont think it makes sense to diverge off the lm-sensor line of thought
 since the client device support and framework in lmsensor is something
most folks like...but then... :) I am a wimp not ready to look at
something different :D

Regards,
Nishanth Menon

  reply	other threads:[~2006-11-16 20:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-15 20:21 Moving I2C2 init to plat-omap/devices.c ? Syed Mohammed, Khasim
2006-11-16  1:01 ` Tony Lindgren
2006-11-16  1:21   ` Syed Mohammed, Khasim
2006-11-16  1:55     ` Tony Lindgren
2006-11-16  2:30       ` Woodruff, Richard
2006-11-16  9:29         ` Nishanth Menon
2006-11-16 14:58           ` Woodruff, Richard
2006-11-16 20:11             ` Nishanth Menon [this message]
2006-11-16 21:01               ` Tony Lindgren
2006-11-16 20:19             ` David Brownell
2006-11-16 20:55               ` Tony Lindgren
2006-11-16 21:29                 ` David Brownell

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=455CC603.9050409@gmail.com \
    --to=menon.nishanth@gmail.com \
    --cc=linux-omap-open-source@linux.omap.com \
    --cc=r-woodruff2@ti.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