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
next prev parent 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