Hi Folks,
This is the series of redo for the I2C related
patches. This series contains the following:
[Patch 1/9]U-boot-V2:ID: Add i2c_device_id
[Patch 2/9]U-boot-V2:ID: Introduce idr
[Patch 3/9]U-boot-V2:I2C: Introduce core
[Patch 4/9]U-boot-V2:I2C: Introduce i2c-dev
[Patch 5/9]U-boot-V2:cmd:
Hi Sascha,
This series of patches introduce I2C support in U-Boot v2. This support is
similar to the one in 2.6.26 rc5 kernel. i2ctools diagnostics introduced is
based on http://www.lm-sensors.org/wiki/I2CTools
The benefit is that we can backport drivers present in linux kernel to u-boot
v2
Menon, Nishanth wrote:
Hi Sascha,
This series of patches introduce I2C support in U-Boot v2. This support is
similar to the one in 2.6.26 rc5 kernel. i2ctools diagnostics introduced is
based on http://www.lm-sensors.org/wiki/I2CTools
The benefit is that we can backport drivers present
-
[EMAIL PROTECTED]
Subject: Re: [U-Boot-Users] [Patch 0/9] U-boot-V2: Introduce I2C support
for SDP3430
Do we really want to bloat U-Boot with these huge Linux drivers? U-Boot
already
has I2C support that works pretty well. Your patchset is overkill, IMHO.
Please see U-boot v2 here
Timur,
-Original Message-
From: Timur Tabi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2008 9:55 AM
To: Menon, Nishanth
Cc: Sascha Hauer; Laurent Desnogues; Kamat, Nishant; [EMAIL PROTECTED];
u-boot-
[EMAIL PROTECTED]
Subject: Re: [U-Boot-Users] [Patch 0/9] U-boot-V2
On Wed, Jun 18, 2008 at 10:39:30AM -0500, Timur Tabi wrote:
Menon, Nishanth wrote:
Please see U-boot v2 here:
Sorry, I didn't notice that your patch is for U-Boot V2.
It does not have i2c support. And IMHO, using kernel like i2c addition in
U-Boot v2 is appropriate. Why this is not
Timur,
-Original Message-
From: Timur Tabi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2008 10:40 AM
To: Menon, Nishanth
Cc: Sascha Hauer; Laurent Desnogues; Kamat, Nishant; [EMAIL PROTECTED];
u-boot-
[EMAIL PROTECTED]
Subject: Re: [U-Boot-Users] [Patch 0/9] U-boot-V2
Sascha,
-Original Message-
From: Sascha Hauer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2008 10:58 AM
To: Timur Tabi
Cc: Menon, Nishanth; Laurent Desnogues; Kamat, Nishant; [EMAIL PROTECTED];
u-boot-
[EMAIL PROTECTED]
Subject: Re: [U-Boot-Users] [Patch 0/9] U-boot-V2
On Wed, Jun 18, 2008 at 11:04:21AM -0500, Menon, Nishanth wrote:
Hmm... flexibility Vs size.. the age old argument ;).
Well, the code we have in u2 today has shown that you can get both, if
done carefully :)
When I started considering i2c I pulled code from U-Boot v1 and
started putting in
On Wed, Jun 18, 2008 at 10:39:30AM -0500, Timur Tabi wrote:
It does not have i2c support. And IMHO, using kernel like i2c
addition in U-Boot v2 is appropriate. Why this is not a bloat U-Boot
v2?
If it isn't, then it means that U-Boot V2 will be pretty bloated in
general.
Please have a
/9] U-boot-V2: Introduce I2C support for
SDP3430
So I suppose the right way to proceed is:
- let's first define use cases for what you want to achieve with the i2c
support in u-boot-v2
- let's have a look at how it would integrate into the device/driver
model and how the user-visible
Hi,
On Wed, Jun 18, 2008 at 01:48:26PM -0500, Menon, Nishanth wrote:
What issues do you see with the proposed patch set I have send out -
other than it bases itself on Linux kernel?
I've commented your first patch in the series; in short:
- It shows nicely that it is easy to copy things over
: [U-Boot-Users] [Patch 0/9] U-boot-V2: Introduce I2C support for
SDP3430
I've commented your first patch in the series; in short:
- It shows nicely that it is easy to copy things over from Linux -
that's a good sign that we didn't do too many things the wrong way. But
note
On Wed, Jun 18, 2008 at 03:21:02PM -0500, Menon, Nishanth wrote:
- Please don't bring in things which are not part of the current code
base. If you add code for subsystems, the subsystems must be there
first and *then* their users. Otherwhise we bloat the codebase and we
disable the
/9] U-boot-V2: Introduce I2C support for
SDP3430
Yea, looking forward especially for PCI patches :-)
;) not in my immediate future at least :D
Yes, but I think what we most of all need is the i2c communication with
the device. We should think about if the abstraction of the devices
*behind
15 matches
Mail list logo
