On Tue, Nov 06, 2007 at 02:02:12PM -0500, Jon Smirl wrote:
> Second pass at extending i2c core to accept strings of aliases for
> the
[snip]
> -/* With some changes from Kyösti Mälkki <[EMAIL PROTECTED]>.
> +/* With some changes from Kyösti MÀlkki <[EMAIL PROTECTED]>.
This looks like an unrelat
On Mon, Nov 05, 2007 at 03:46:45PM -0700, Grant Likely wrote:
> On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> > Jon Smirl wrote:
> > > On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> > >> Jon Smirl wrote:
> > >>> This is my first pass at reworking the Freescale i2c driver. It
> > >>> swit
Jean Delvare wrote:
> Hi Matt,
>
>> WRT cell-index this is an index of the bus on the chip (not the logical
>> i2c bus but the physical difference between two i2c controllers) and
>> then any i2c devices which need to be communicated with would be
>> child nodes, their reg property reflecting their
Hi Matt,
On Tue, 06 Nov 2007 18:53:11 +, Matt Sealey wrote:
> Jean Delvare wrote:
> > On Mon, 05 Nov 2007 21:52:06 +, Matt Sealey wrote:
> >> Well, all i2c devices have a chip id you can probe for (...)
> >
> > This statement is completely incorrect. I2C devices do NOT have
> > standard I
On Tue, 6 Nov 2007 11:26:14 -0700, Grant Likely wrote:
> On 11/6/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > Sorry, I've not been completely clear. Yes, you can use
> > i2c_new_device() on an adapter that has been added with
> > i2c_add_adapter(). However, this requires that you have a referenc
Second pass on rework of mpc-i2c.c. This doesn't include code for
supporting both old and new style chip drivers. I'm still not a fan of
cluttering up mpc-i2c.c to support old style drivers since it so easy
to convert them to the new style. I'd rather just fix up the i2c
drivers used by chips on th
Second pass at extending i2c core to accept strings of aliases for the
module. This version eliminate the need for separate name and type
fields when selecting a driver. PowerPC has to have a mapping from
device tree names to the i2c drivers, it makes sense to keep this
mapping inside the i2c drive
Jean Delvare wrote:
> On Mon, 05 Nov 2007 21:52:06 +, Matt Sealey wrote:
>> Well, all i2c devices have a chip id you can probe for (...)
>
> This statement is completely incorrect. I2C devices do NOT have
> standard ID registers. Some devices have proprietary ID registers, some
> don't, it's r
Jean Delvare wrote:
> Sorry, I've not been completely clear. Yes, you can use
> i2c_new_device() on an adapter that has been added with
> i2c_add_adapter(). However, this requires that you have a reference to
> that i2c_adapter, which is usually not the case with system-wide I2C
> buses.
But it is
On 11/6/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 11/6/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > Hi Scott,
> >
> > On Tue, 06 Nov 2007 11:36:23 -0600, Scott Wood wrote:
> > > Jean Delvare wrote:
> > > We might as well just use i2c_new_device() instead of messing around
> > >
On 11/6/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
> Hi Scott,
>
> On Tue, 06 Nov 2007 11:36:23 -0600, Scott Wood wrote:
> > Jean Delvare wrote:
> > We might as well just use i2c_new_device() instead of messing around
> > with bus numbers. Note that this is technically no longer platfor
Hi Jon,
On Tue, 6 Nov 2007 12:45:24 -0500, Jon Smirl wrote:
> On 11/6/07, Jean Delvare wrote:
> > I agree with Scott here, I don't want to fork the drivers. It is
> > possible (and easy) to support both methods in the same module, let's
> > just to that. See for example David Brownell's work on th
Hi Scott,
On Tue, 06 Nov 2007 11:36:23 -0600, Scott Wood wrote:
> Jean Delvare wrote:
> We might as well just use i2c_new_device() instead of messing around
> with bus numbers. Note that this is technically no longer platform
> code, so it's harder to justify claiming the static nu
Jean Delvare wrote:
We might as well just use i2c_new_device() instead of messing around
with bus numbers. Note that this is technically no longer platform
code, so it's harder to justify claiming the static numberspace.
>>> I was allowing control of the bus number with "cell-index"
On 11/6/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
> Hi Scott, Jon,
>
> On Mon, 05 Nov 2007 14:51:51 -0600, Scott Wood wrote:
> > Jon Smirl wrote:
> > > How about renaming the old driver file and leaving it hooked to ppc?
> > > Then it would get deleted when ppc goes away. That would let work
> >
On Mon, 05 Nov 2007 21:52:06 +, Matt Sealey wrote:
> Well, all i2c devices have a chip id you can probe for (...)
This statement is completely incorrect. I2C devices do NOT have
standard ID registers. Some devices have proprietary ID registers, some
don't, it's really up to the manfacturer.
-
Hi Scott, Jon,
On Mon, 05 Nov 2007 14:51:51 -0600, Scott Wood wrote:
> Jon Smirl wrote:
> > How about renaming the old driver file and leaving it hooked to ppc?
> > Then it would get deleted when ppc goes away. That would let work
> > progress on the powerpc version.
>
> Or we could have one driv
Jon Smirl wrote:
> On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> One side effect is that legacy style i2c drivers won't work anymore.
If you mean legacy-style client drivers, why not?
>>> i2c_new_device() doesn't work with legacy-style client drivers.
>> No, but they should still wor
Hi Jon,
On Mon, 5 Nov 2007 23:25:35 -0500 "Jon Smirl" <[EMAIL PROTECTED]> wrote:
>
> + compatible = of_get_property(node, "compatible", &len);
> + strlcpy(info.driver_name, compatible, len);
Of course, you will check len against sizeof(info.driver_name), right?
> -/* With
On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> >>> Or push these strings into the chip drivers and modify
> >>> i2c-core to also match on the device tree style names.
> >> That would be ideal; it just hasn't been done yet.
> >
> > This is not hard to do but the i2c people will have to agree. I
On Mon, 5 Nov 2007 20:34:51 -0500 "Jon Smirl" <[EMAIL PROTECTED]> wrote:
>
> On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> > > +static struct of_platform_driver mpc_i2c_driver = {
> > > + .owner = THIS_MODULE,
> > > + .name = DRV_NAME,
> > > + .match_table=
On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> > +static struct of_platform_driver mpc_i2c_driver = {
> > + .owner = THIS_MODULE,
> > + .name = DRV_NAME,
> > + .match_table= mpc_i2c_of_match,
> > + .probe = mpc_i2c_probe,
> > + .remove
On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> >>> One side effect is that legacy style i2c drivers won't work anymore.
> >> If you mean legacy-style client drivers, why not?
> >
> > i2c_new_device() doesn't work with legacy-style client drivers.
>
> No, but they should still work the old way.
On 11/5/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> > Jon Smirl wrote:
> > > On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> > >> Jon Smirl wrote:
> > >>> This is my first pass at reworking the Freescale i2c driver. It
> > >>> switches the d
On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> Matt Sealey wrote:
> > Scott Wood wrote:
> >> Jon Smirl wrote:
> >
> > cell-index = <1>;
> What is cell-index for?
> >>> I was using it to control the bus number, is that the wrong
> >>> attribute?
> >>
> >> It shouldn't be specified at a
On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> >> Jon Smirl wrote:
> >>> This is my first pass at reworking the Freescale i2c driver. It
> >>> switches the driver from being a platform driver to an open firmware
> >>> one
Matt Sealey wrote:
> Scott Wood wrote:
>> Jon Smirl wrote:
>
> cell-index = <1>;
What is cell-index for?
>>> I was using it to control the bus number, is that the wrong
>>> attribute?
>>
>> It shouldn't be specified at all -- the hardware has no concept of
>> a device number.
>
> Well,
Scott Wood wrote:
> Jon Smirl wrote:
cell-index = <1>;
>>> What is cell-index for?
>> I was using it to control the bus number, is that the wrong attribute?
>
> It shouldn't be specified at all -- the hardware has no concept of a
> device number.
Well, all i2c devices have a chip id
Jon Smirl wrote:
> On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
>> Jon Smirl wrote:
>>> This is my first pass at reworking the Freescale i2c driver. It
>>> switches the driver from being a platform driver to an open firmware
>>> one. I've checked it out on my hardware and it is working.
>> We
On 11/5/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> This is my first pass at reworking the Freescale i2c driver. It
> switches the driver from being a platform driver to an open firmware
> one. I've checked it out on my hardware and it is working.
Is there any way to have the i2c chip modules match
On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > This is my first pass at reworking the Freescale i2c driver. It
> > switches the driver from being a platform driver to an open firmware
> > one. I've checked it out on my hardware and it is working.
>
> We may want to hold of
Jon Smirl wrote:
> On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
>> Jon Smirl wrote:
>>> I can change it to remove fsl5200-clocking if someone can tell me if
>>> this is only needed on the mpc5200b.
>> Well, it appears to be needed on the mpc5200 (no 'b')...
>
> What is the recommend way to ch
On 11/5/07, Matt Sealey <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > [EMAIL PROTECTED] {
> > device_type = "i2c";
> > compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
> > cell-index = <1>;
> > reg = <3d40 40>;
> > interrupts = <2 10 0>;
> > interrupt-par
On 11/5/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > I can change it to remove fsl5200-clocking if someone can tell me if
> > this is only needed on the mpc5200b.
>
> Well, it appears to be needed on the mpc5200 (no 'b')...
What is the recommend way to check for a mpc5200 or m
On 11/5/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> This is my first pass at reworking the Freescale i2c driver. It
> switches the driver from being a platform driver to an open firmware
> one. I've checked it out on my hardware and it is working.
Isn't this device core also used in the fsl coldfir
Jon Smirl wrote:
> I can change it to remove fsl5200-clocking if someone can tell me if
> this is only needed on the mpc5200b.
Well, it appears to be needed on the mpc5200 (no 'b')...
> This driver also supports the
> MPC107/Tsi107/MPC8240/MPC8245 and MPC85xx/MPC8641.
You forgot mpc83x
On 11/5/07, Matt Sealey <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > [EMAIL PROTECTED] {
> > device_type = "i2c";
> > compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
> > cell-index = <1>;
> > reg = <3d40 40>;
> > interrupts = <2 10 0>;
> > interrupt-par
Jon Smirl wrote:
> This is my first pass at reworking the Freescale i2c driver. It
> switches the driver from being a platform driver to an open firmware
> one. I've checked it out on my hardware and it is working.
We may want to hold off on this until arch/ppc goes away (or at least
all users of
Jon Smirl wrote:
> [EMAIL PROTECTED] {
> device_type = "i2c";
> compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
> cell-index = <1>;
> reg = <3d40 40>;
> interrupts = <2 10 0>;
> interrupt-parent = <&mpc5200_pic>;
> fsl5200-clocking;
>
> [EMAIL PR
This is my first pass at reworking the Freescale i2c driver. It
switches the driver from being a platform driver to an open firmware
one. I've checked it out on my hardware and it is working.
You can specific i2c devices on a bus by adding child nodes for them
in the device tree. It does not know
40 matches
Mail list logo
