On Sat, 2012-06-09 at 15:58 +0200, Andreas Schwab wrote:
> That breaks the tas3004 driver (and most likely the pcm3052 driver as
> well), since it wants to create its own i2c device. I'm using the
> attached patch as a workaround (only tas3004 driver tested on iBook G4),
> but that needs to move t
On Sun, 2012-06-10 at 17:23 +1000, Benjamin Herrenschmidt wrote:
> Ah, excellent, so a small quirk in i2c_powermac is the way to go then,
> we can detect it by name and hack up something. Either that or even
> better, in prom_init, we could add the missing property to the
> device-tree.
>
> Any c
Benjamin Herrenschmidt writes:
> Ah, excellent, so a small quirk in i2c_powermac is the way to go then,
> we can detect it by name and hack up something. Either that or even
> better, in prom_init, we could add the missing property to the
> device-tree.
How does that look like? Though I'm not s
On Sun, 2012-06-10 at 09:13 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt writes:
>
> > On Sun, 2012-06-10 at 00:59 +0200, Andreas Schwab wrote:
> >> It's a PowerMac G5. During booting I see this:
> >
> > There's about half a dozen versions of those :-) I assume the older
> > PowerMac7,2
Benjamin Herrenschmidt writes:
> On Sun, 2012-06-10 at 00:59 +0200, Andreas Schwab wrote:
>> It's a PowerMac G5. During booting I see this:
>
> There's about half a dozen versions of those :-) I assume the older
> PowerMac7,2 ?
Yes, that's right. Sorry for being imprecise.
>> PowerMac i2c bus
On Sun, 2012-06-10 at 00:59 +0200, Andreas Schwab wrote:
> It's a PowerMac G5. During booting I see this:
There's about half a dozen versions of those :-) I assume the older
PowerMac7,2 ? It's the one that tends to have missing bits in the
device-tree. In that case, I think we still have one of t
Benjamin Herrenschmidt writes:
> On Sun, 2012-06-10 at 00:30 +0200, Andreas Schwab wrote:
>> > Should we keep the tas_create method for those ? We could have some code
>> > in the aoa core file that calls those "fixups" to create missing
>> > devices...
>>
>> I'm not sure if the function is need
On Sun, 2012-06-10 at 00:30 +0200, Andreas Schwab wrote:
> > Should we keep the tas_create method for those ? We could have some code
> > in the aoa core file that calls those "fixups" to create missing
> > devices...
>
> I'm not sure if the function is needed, if the device can be created in
> i2
Benjamin Herrenschmidt writes:
> Should we keep the tas_create method for those ? We could have some code
> in the aoa core file that calls those "fixups" to create missing
> devices...
I'm not sure if the function is needed, if the device can be created in
i2c_powermac_register_devices.
Andrea
On Sat, 2012-06-09 at 15:58 +0200, Andreas Schwab wrote:
> That breaks the tas3004 driver (and most likely the pcm3052 driver as
> well), since it wants to create its own i2c device. I'm using the
> attached patch as a workaround (only tas3004 driver tested on iBook G4),
> but that needs to move t
That breaks the tas3004 driver (and most likely the pcm3052 driver as
well), since it wants to create its own i2c device. I'm using the
attached patch as a workaround (only tas3004 driver tested on iBook G4),
but that needs to move the workarounds for the older systems that don't
have proper compa
Benjamin Herrenschmidt writes:
> + /* Make up a modalias. Note: we to _NOT_ want the standard
> + * i2c drivers to match with any of our powermac stuff
> + * unless they have been specifically modified to handle
> + * it on a case by case basis.
This causes i2c-powermac to register i2c devices exposed in the
device-tree, enabling new-style probing of devices.
Note that we prefix the IDs with "MAC," in order to prevent the
generic drivers from matching. This is done on purpose as we only
want drivers specifically tested/designed to operate
13 matches
Mail list logo
