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 chance
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 the
Benjamin Herrenschmidt b...@kernel.crashing.org 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.
On Sun, 2012-06-10 at 09:13 +0200, Andreas Schwab wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org 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
Benjamin Herrenschmidt b...@kernel.crashing.org 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
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
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 the
Benjamin Herrenschmidt b...@kernel.crashing.org 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
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
Benjamin Herrenschmidt b...@kernel.crashing.org 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
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
Benjamin Herrenschmidt b...@kernel.crashing.org 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
12 matches
Mail list logo
