Re: [PATCH] i2c: powermac: don't workaround for keywest

2015-05-17 Thread Dan DeVoto
Hi,

Sorry for the delay, I found this message in my spam folder.  Anyway,
for my machine model, cat /proc/device-tree/compatible returns:

PowerBook4,3MacRISC2MacRISCPower Macintosh

It's a 14 in. iBook G3 700 MHz.

Regards,

Dan


On Mon, 5/11/15, Benjamin Herrenschmidt b...@kernel.crashing.org wrote:

Subject: Re: [PATCH] i2c: powermac: don't workaround for keywest
To: w...@the-dreams.de
Cc: linux-...@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Dan DeVoto 
dand1...@yahoo.com, Mark Elliott txliteb...@gmail.com
Date: Monday, May 11, 2015, 4:26 PM

On Mon, 2015-05-11 at 09:34 +0200, w...@the-dreams.de wrote:
 On Mon, May 11, 2015 at 08:14:47AM +1000, Benjamin Herrenschmidt wrote:
  On Sun, 2015-05-10 at 20:34 +0200, Wolfram Sang wrote:
   Okay, so this patch is bogus. I understand now that onyx uses another
   codec than TAS, so this change will regress on other machines.
   However,
   it shows that this unconditional instantiation of the TAS breaks sound
   on Macintoshs which still need non-aoa sound support. I assume there
   will be noone in the near future to convert Keywest to AOA, so we'll
   need to find a hackish way around this instantiation problem.
 

  Converting the old macs that use TAS shouldn't be *that* hard, main
  problem is I don't have the hardware to test...
  Dan and Mark (on CC) have been very helpful with testing. Maybe they are
  also in to test the proper solution?

 Possibly, depends how many machines we can cover. I also have extremely
 little time, so I'm not that keen on volunteering :-) I'll *try* to have
 a look some time this or next week.

 The main problem is the difference in the way the layout of the codec
 etc... is reported from the DT by the firmware. Otherwise the HW is the
 same between pre-AOA and post-AOA really ...

 I do have a bunch of DT snapshots lying around, so I can try
 to figure out something.

 Dan, Mark, what machine models specifically do you have ? (compatible
 property in the DT pls, ie, /proc/device-tree/compatible).

 Cheers,
 Ben.
 
 
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] i2c: powermac: don't workaround for keywest

2015-05-11 Thread wsa
On Mon, May 11, 2015 at 08:14:47AM +1000, Benjamin Herrenschmidt wrote:
 On Sun, 2015-05-10 at 20:34 +0200, Wolfram Sang wrote:
  Okay, so this patch is bogus. I understand now that onyx uses another
  codec than TAS, so this change will regress on other machines.
  However,
  it shows that this unconditional instantiation of the TAS breaks sound
  on Macintoshs which still need non-aoa sound support. I assume there
  will be noone in the near future to convert Keywest to AOA, so we'll
  need to find a hackish way around this instantiation problem.
 
 Converting the old macs that use TAS shouldn't be *that* hard, main
 problem is I don't have the hardware to test...

Dan and Mark (on CC) have been very helpful with testing. Maybe they are
also in to test the proper solution?

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] i2c: powermac: don't workaround for keywest

2015-05-11 Thread Benjamin Herrenschmidt
On Mon, 2015-05-11 at 09:34 +0200, w...@the-dreams.de wrote:
 On Mon, May 11, 2015 at 08:14:47AM +1000, Benjamin Herrenschmidt wrote:
  On Sun, 2015-05-10 at 20:34 +0200, Wolfram Sang wrote:
   Okay, so this patch is bogus. I understand now that onyx uses another
   codec than TAS, so this change will regress on other machines.
   However,
   it shows that this unconditional instantiation of the TAS breaks sound
   on Macintoshs which still need non-aoa sound support. I assume there
   will be noone in the near future to convert Keywest to AOA, so we'll
   need to find a hackish way around this instantiation problem.
  
  Converting the old macs that use TAS shouldn't be *that* hard, main
  problem is I don't have the hardware to test...
 
 Dan and Mark (on CC) have been very helpful with testing. Maybe they are
 also in to test the proper solution?

Possibly, depends how many machines we can cover. I also have extremely
little time, so I'm not that keen on volunteering :-) I'll *try* to have
a look some time this or next week.

The main problem is the difference in the way the layout of the codec
etc... is reported from the DT by the firmware. Otherwise the HW is the
same between pre-AOA and post-AOA really ...

I do have a bunch of DT snapshots lying around, so I can try to figure
out something.

Dan, Mark, what machine models specifically do you have ? (compatible
property in the DT pls, ie, /proc/device-tree/compatible).

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] i2c: powermac: don't workaround for keywest

2015-05-10 Thread Benjamin Herrenschmidt
On Sun, 2015-05-10 at 20:34 +0200, Wolfram Sang wrote:
 Okay, so this patch is bogus. I understand now that onyx uses another
 codec than TAS, so this change will regress on other machines.
 However,
 it shows that this unconditional instantiation of the TAS breaks sound
 on Macintoshs which still need non-aoa sound support. I assume there
 will be noone in the near future to convert Keywest to AOA, so we'll
 need to find a hackish way around this instantiation problem.

Converting the old macs that use TAS shouldn't be *that* hard, main
problem is I don't have the hardware to test...

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] i2c: powermac: don't workaround for keywest

2015-05-10 Thread Wolfram Sang
On Sat, May 09, 2015 at 07:23:33PM +0200, Wolfram Sang wrote:
 Commit 3a3dd0186f619b (i2c/powermac: Improve detection of devices from
 device-tree) added a codec device instantiation workaround
 unconditionally although it is only needed for onyx. Do it conditionally
 since keywest has its own codec instantiation in the sound drivers.
 Thanks must go to GrowlTiger from Gentoo bug report #469132 for
 bisecting.
 
 Reported-by: Dan DeVoto dand1...@yahoo.com
 Signed-off-by: Wolfram Sang w...@the-dreams.de
 Tested-by: Dan DeVoto dand1...@yahoo.com
 Tested-by: Mark Elliott txliteb...@gmail.com
 Fixes: 3a3dd0186f619b (i2c/powermac: Improve detection of devices from 
 device-tree)
 ---
  drivers/i2c/busses/i2c-powermac.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/i2c/busses/i2c-powermac.c 
 b/drivers/i2c/busses/i2c-powermac.c
 index 6abcf696e3594b..cad5552c0cd4e4 100644
 --- a/drivers/i2c/busses/i2c-powermac.c
 +++ b/drivers/i2c/busses/i2c-powermac.c
 @@ -285,7 +285,8 @@ static void i2c_powermac_add_missing(struct i2c_adapter 
 *adap,
  
  static bool i2c_powermac_get_type(struct i2c_adapter *adap,
   struct device_node *node,
 - u32 addr, char *type, int type_size)
 + u32 addr, char *type, int type_size,
 + bool found_onyx)
  {
   char tmp[16];
  
 @@ -305,8 +306,8 @@ static bool i2c_powermac_get_type(struct i2c_adapter 
 *adap,
   return true;
   }
  
 - /* Now look for known workarounds */
 - if (!strcmp(node-name, deq)) {
 + /* Now look for known workarounds for onyx/aoa */
 + if (found_onyx  !strcmp(node-name, deq)) {
   /* Apple uses address 0x34 for TAS3001 and 0x35 for TAS3004 */

Okay, so this patch is bogus. I understand now that onyx uses another
codec than TAS, so this change will regress on other machines. However,
it shows that this unconditional instantiation of the TAS breaks sound
on Macintoshs which still need non-aoa sound support. I assume there
will be noone in the near future to convert Keywest to AOA, so we'll
need to find a hackish way around this instantiation problem.



signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] i2c: powermac: don't workaround for keywest

2015-05-09 Thread Wolfram Sang
Commit 3a3dd0186f619b (i2c/powermac: Improve detection of devices from
device-tree) added a codec device instantiation workaround
unconditionally although it is only needed for onyx. Do it conditionally
since keywest has its own codec instantiation in the sound drivers.
Thanks must go to GrowlTiger from Gentoo bug report #469132 for
bisecting.

Reported-by: Dan DeVoto dand1...@yahoo.com
Signed-off-by: Wolfram Sang w...@the-dreams.de
Tested-by: Dan DeVoto dand1...@yahoo.com
Tested-by: Mark Elliott txliteb...@gmail.com
Fixes: 3a3dd0186f619b (i2c/powermac: Improve detection of devices from 
device-tree)
---
 drivers/i2c/busses/i2c-powermac.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-powermac.c 
b/drivers/i2c/busses/i2c-powermac.c
index 6abcf696e3594b..cad5552c0cd4e4 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -285,7 +285,8 @@ static void i2c_powermac_add_missing(struct i2c_adapter 
*adap,
 
 static bool i2c_powermac_get_type(struct i2c_adapter *adap,
struct device_node *node,
-   u32 addr, char *type, int type_size)
+   u32 addr, char *type, int type_size,
+   bool found_onyx)
 {
char tmp[16];
 
@@ -305,8 +306,8 @@ static bool i2c_powermac_get_type(struct i2c_adapter *adap,
return true;
}
 
-   /* Now look for known workarounds */
-   if (!strcmp(node-name, deq)) {
+   /* Now look for known workarounds for onyx/aoa */
+   if (found_onyx  !strcmp(node-name, deq)) {
/* Apple uses address 0x34 for TAS3001 and 0x35 for TAS3004 */
if (addr == 0x34) {
snprintf(type, type_size, MAC,tas3001);
@@ -362,7 +363,7 @@ static void i2c_powermac_register_devices(struct 
i2c_adapter *adap,
 
/* Make up a modalias */
if (!i2c_powermac_get_type(adap, node, addr,
-  info.type, sizeof(info.type))) {
+  info.type, sizeof(info.type), 
found_onyx)) {
continue;
}
 
-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev