From: Tony Lindgren <tony@atomide.com>
To: Nishanth Menon <menon.nishanth@gmail.com>
Cc: linux-omap-open-source@linux.omap.com
Subject: Re: Moving I2C2 init to plat-omap/devices.c ?
Date: Thu, 16 Nov 2006 23:01:22 +0200 [thread overview]
Message-ID: <20061116210121.GU21064@atomide.com> (raw)
In-Reply-To: <455CC603.9050409@gmail.com>
* Nishanth Menon <menon.nishanth@gmail.com> [061116 22:12]:
> 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..
Doing different handlers in the drivers depending on the version number
is probably cleanest way to share the code that can be shared. And that
keeps the code clean of lots of if then else.
> > 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..
We could have omap_i2c_v123_whatever() and omap_i2c_v234_whatever() type
functions for the parts that are different to keep the code clean.
Regards,
Tony
next prev parent reply other threads:[~2006-11-16 21:01 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
2006-11-16 21:01 ` Tony Lindgren [this message]
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=20061116210121.GU21064@atomide.com \
--to=tony@atomide.com \
--cc=linux-omap-open-source@linux.omap.com \
--cc=menon.nishanth@gmail.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