[pasemi] problem with i2c-pasemi

[pasemi] problem with i2c-pasemi

[Christian Zigotzky]

Hello Olof,

I compiled the latest git kernel 2 days ago. The kernel boots and works 
but unfortunately I get the following error messages about the 
i2c-pasemi during the start:

[    3.553461] i2c /dev entries driver
[    3.554462] couldn't get idr
[    3.554463] ------------[ cut here ]------------
[    3.554474] WARNING: CPU: 0 PID: 1 at drivers/i2c/i2c-core.c:1789 
.__i2c_add_numbered_adapter+0x80/0xc0
[    3.554477] Modules linked in:
[    3.554482] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.8.0_a1_A-EON_AmigaONE_X1000_Nemo-05906-g194dc87-dirty #1
[    3.554485] task: c00000026d116d80 ti: c00000026d120000 task.ti: 
c00000026d120000
[    3.554487] NIP: c0000000007f1b70 LR: c0000000007f1b6c CTR: 
0000000000000000
[    3.554490] REGS: c00000026d123370 TRAP: 0700   Not tainted 
(4.8.0_a1_A-EON_AmigaONE_X1000_Nemo-05906-g194dc87-dirty)
[    3.554502] MSR: 9000000002029032 <SF,HV,VEC,EE,ME,IR,DR,RI>  CR: 
42870d22  XER: 20000000
[    3.554540] SOFTE: 1
                GPR00: c0000000007f1b6c c00000026d1235f0 
c0000000017bc600 0000000000000010
                GPR04: 0000000000000001 0000000000000000 
0000000000000010 c0000000018ec600
                GPR08: 2067657420696472 0000000000000000 
0000000000000000 0000000000000030
                GPR12: 2067657420696472 c00000000ffff000 
c000000000009b10 0000000000000000
                GPR16: 0000000000000000 0000000000000000 
0000000000000000 0000000000000000
                GPR20: 0000000000000000 0000000000000000 
0000000000000000 0000000000000000
                GPR24: 0000000000000000 c0000000016c86d8 
c000000001555110 0000000000000000
                GPR28: c000000001629ec8 c000000001628fc0 
ffffffffffffffe4 c00000026b16f408
[    3.554545] NIP [c0000000007f1b70] .__i2c_add_numbered_adapter+0x80/0xc0
[    3.554549] LR [c0000000007f1b6c] .__i2c_add_numbered_adapter+0x7c/0xc0
[    3.554551] Call Trace:
[    3.554557] [c00000026d1235f0] [c0000000007f1b6c] 
.__i2c_add_numbered_adapter+0x7c/0xc0 (unreliable)
[    3.554563] [c00000026d123680] [c0000000007f4b58] 
.pasemi_smb_probe+0x12c/0x188
[    3.554569] [c00000026d123710] [c0000000004b0fb0] 
.pci_device_probe+0x90/0x100
[    3.554576] [c00000026d1237a0] [c0000000006d3c10] 
.driver_probe_device+0x15c/0x2c8
[    3.554581] [c00000026d123840] [c0000000006d3e2c] 
.__driver_attach+0xb0/0xe0
[    3.554586] [c00000026d1238d0] [c0000000006d1920] 
.bus_for_each_dev+0xac/0xc0
[    3.554591] [c00000026d123970] [c0000000006d35ac] 
.driver_attach+0x34/0x40
[    3.554597] [c00000026d1239f0] [c0000000006d2ff4] 
.bus_add_driver+0x104/0x244
[    3.554602] [c00000026d123a90] [c0000000006d4758] 
.driver_register+0xc0/0x110
[    3.554608] [c00000026d123b20] [c0000000004b06f4] 
.__pci_register_driver+0x58/0x64
[    3.554615] [c00000026d123bb0] [c00000000153134c] 
.pasemi_smb_driver_init+0x24/0x38
[    3.554621] [c00000026d123c20] [c0000000000094ac] 
.do_one_initcall+0xd8/0x174
[    3.554626] [c00000026d123d00] [c0000000014eed98] 
.kernel_init_freeable+0x188/0x244
[    3.554632] [c00000026d123db0] [c000000000009b30] .kernel_init+0x20/0x130
[    3.554638] [c00000026d123e30] [c000000000007ee8] 
.ret_from_kernel_thread+0x58/0x70
[    3.554639] Instruction dump:
[    3.554648] 4bc8bac5 60000000 7c7e1b78 7fa3eb78 482e7ce1 60000000 
2f9e0000 409c002c
[    3.554657] 3c62ffc8 3863aaca 482eb255 60000000 <0fe00000> 2f9effe4 
3860fff0 419e002c
[    3.554661] ---[ end trace cac6a75782ca269c ]---
[    3.554673] i2c-pasemi: probe of 0000:00:1c.0 failed with error -16
[    3.554724] couldn't get idr
[    3.554725] ------------[ cut here ]------------
[    3.554733] WARNING: CPU: 0 PID: 1 at drivers/i2c/i2c-core.c:1789 
.__i2c_add_numbered_adapter+0x80/0xc0
[    3.554735] Modules linked in:
[    3.554739] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 
4.8.0_a1_A-EON_AmigaONE_X1000_Nemo-05906-g194dc87-dirty #1
[    3.554742] task: c00000026d116d80 ti: c00000026d120000 task.ti: 
c00000026d120000
[    3.554744] NIP: c0000000007f1b70 LR: c0000000007f1b6c CTR: 
0000000000000000
[    3.554747] REGS: c00000026d123370 TRAP: 0700   Tainted: G W 
(4.8.0_a1_A-EON_AmigaONE_X1000_Nemo-05906-g194dc87-dirty)
[    3.554758] MSR: 9000000002029032 <SF,HV,VEC,EE,ME,IR,DR,RI>  CR: 
42870d22  XER: 20000000
[    3.554795] SOFTE: 1
                GPR00: c0000000007f1b6c c00000026d1235f0 
c0000000017bc600 0000000000000010
                GPR04: 0000000000000001 0000000000000000 
0000000000000010 c0000000018ec600
                GPR08: 2067657420696472 0000000000000000 
0000000000000000 0000000000000030
                GPR12: 2067657420696472 c00000000ffff000 
c000000000009b10 0000000000000000
                GPR16: 0000000000000000 0000000000000000 
0000000000000000 0000000000000000
                GPR20: 0000000000000000 0000000000000000 
0000000000000000 0000000000000000
                GPR24: 0000000000000000 c0000000016c86d8 
c000000001555110 0000000000000000
                GPR28: c000000001629ec8 c000000001628fc0 
ffffffffffffffe4 c00000026b16f408
[    3.554800] NIP [c0000000007f1b70] .__i2c_add_numbered_adapter+0x80/0xc0
[    3.554805] LR [c0000000007f1b6c] .__i2c_add_numbered_adapter+0x7c/0xc0
[    3.554806] Call Trace:
[    3.554812] [c00000026d1235f0] [c0000000007f1b6c] 
.__i2c_add_numbered_adapter+0x7c/0xc0 (unreliable)
[    3.554818] [c00000026d123680] [c0000000007f4b58] 
.pasemi_smb_probe+0x12c/0x188
[    3.554823] [c00000026d123710] [c0000000004b0fb0] 
.pci_device_probe+0x90/0x100
[    3.554829] [c00000026d1237a0] [c0000000006d3c10] 
.driver_probe_device+0x15c/0x2c8
[    3.554834] [c00000026d123840] [c0000000006d3e2c] 
.__driver_attach+0xb0/0xe0
[    3.554839] [c00000026d1238d0] [c0000000006d1920] 
.bus_for_each_dev+0xac/0xc0
[    3.554844] [c00000026d123970] [c0000000006d35ac] 
.driver_attach+0x34/0x40
[    3.554850] [c00000026d1239f0] [c0000000006d2ff4] 
.bus_add_driver+0x104/0x244
[    3.554855] [c00000026d123a90] [c0000000006d4758] 
.driver_register+0xc0/0x110
[    3.554861] [c00000026d123b20] [c0000000004b06f4] 
.__pci_register_driver+0x58/0x64
[    3.554867] [c00000026d123bb0] [c00000000153134c] 
.pasemi_smb_driver_init+0x24/0x38
[    3.554873] [c00000026d123c20] [c0000000000094ac] 
.do_one_initcall+0xd8/0x174
[    3.554878] [c00000026d123d00] [c0000000014eed98] 
.kernel_init_freeable+0x188/0x244
[    3.554883] [c00000026d123db0] [c000000000009b30] .kernel_init+0x20/0x130
[    3.554889] [c00000026d123e30] [c000000000007ee8] 
.ret_from_kernel_thread+0x58/0x70
[    3.554891] Instruction dump:
[    3.554899] 4bc8bac5 60000000 7c7e1b78 7fa3eb78 482e7ce1 60000000 
2f9e0000 409c002c
[    3.554907] 3c62ffc8 3863aaca 482eb255 60000000 <0fe00000> 2f9effe4 
3860fff0 419e002c
[    3.554909] ---[ end trace cac6a75782ca269d ]---
[    3.554919] i2c-pasemi: probe of 0000:00:1c.1 failed with error -16
[    3.554968] couldn't get idr
[    3.554969] ------------[ cut here ]------------
[    3.554977] WARNING: CPU: 0 PID: 1 at drivers/i2c/i2c-core.c:1789 
.__i2c_add_numbered_adapter+0x80/0xc0
[    3.554979] Modules linked in:
[    3.554983] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 
4.8.0_a1_A-EON_AmigaONE_X1000_Nemo-05906-g194dc87-dirty #1
[    3.554986] task: c00000026d116d80 ti: c00000026d120000 task.ti: 
c00000026d120000
[    3.554988] NIP: c0000000007f1b70 LR: c0000000007f1b6c CTR: 
0000000000000000
[    3.554991] REGS: c00000026d123370 TRAP: 0700   Tainted: G W 
(4.8.0_a1_A-EON_AmigaONE_X1000_Nemo-05906-g194dc87-dirty)
[    3.555001] MSR: 9000000002029032 <SF,HV,VEC,EE,ME,IR,DR,RI>  CR: 
42870d22  XER: 20000000
[    3.555038] SOFTE: 1
                GPR00: c0000000007f1b6c c00000026d1235f0 
c0000000017bc600 0000000000000010
                GPR04: 0000000000000001 0000000000000000 
0000000000000010 c0000000018ec600
                GPR08: 2067657420696472 0000000000000000 
0000000000000000 0000000000000030
                GPR12: 2067657420696472 c00000000ffff000 
c000000000009b10 0000000000000000
                GPR16: 0000000000000000 0000000000000000 
0000000000000000 0000000000000000
                GPR20: 0000000000000000 0000000000000000 
0000000000000000 0000000000000000
                GPR24: 0000000000000000 c0000000016c86d8 
c000000001555110 0000000000000000
                GPR28: c000000001629ec8 c000000001628fc0 
ffffffffffffffe4 c00000026b16f408
[    3.555043] NIP [c0000000007f1b70] .__i2c_add_numbered_adapter+0x80/0xc0
[    3.555047] LR [c0000000007f1b6c] .__i2c_add_numbered_adapter+0x7c/0xc0
[    3.555048] Call Trace:
[    3.555055] [c00000026d1235f0] [c0000000007f1b6c] 
.__i2c_add_numbered_adapter+0x7c/0xc0 (unreliable)
[    3.555060] [c00000026d123680] [c0000000007f4b58] 
.pasemi_smb_probe+0x12c/0x188
[    3.555065] [c00000026d123710] [c0000000004b0fb0] 
.pci_device_probe+0x90/0x100
[    3.555071] [c00000026d1237a0] [c0000000006d3c10] 
.driver_probe_device+0x15c/0x2c8
[    3.555076] [c00000026d123840] [c0000000006d3e2c] 
.__driver_attach+0xb0/0xe0
[    3.555082] [c00000026d1238d0] [c0000000006d1920] 
.bus_for_each_dev+0xac/0xc0
[    3.555087] [c00000026d123970] [c0000000006d35ac] 
.driver_attach+0x34/0x40
[    3.555092] [c00000026d1239f0] [c0000000006d2ff4] 
.bus_add_driver+0x104/0x244
[    3.555097] [c00000026d123a90] [c0000000006d4758] 
.driver_register+0xc0/0x110
[    3.555103] [c00000026d123b20] [c0000000004b06f4] 
.__pci_register_driver+0x58/0x64
[    3.555109] [c00000026d123bb0] [c00000000153134c] 
.pasemi_smb_driver_init+0x24/0x38
[    3.555115] [c00000026d123c20] [c0000000000094ac] 
.do_one_initcall+0xd8/0x174
[    3.555120] [c00000026d123d00] [c0000000014eed98] 
.kernel_init_freeable+0x188/0x244
[    3.555126] [c00000026d123db0] [c000000000009b30] .kernel_init+0x20/0x130
[    3.555131] [c00000026d123e30] [c000000000007ee8] 
.ret_from_kernel_thread+0x58/0x70
[    3.555133] Instruction dump:
[    3.555141] 4bc8bac5 60000000 7c7e1b78 7fa3eb78 482e7ce1 60000000 
2f9e0000 409c002c
[    3.555149] 3c62ffc8 3863aaca 482eb255 60000000 <0fe00000> 2f9effe4 
3860fff0 419e002c
[    3.555151] ---[ end trace cac6a75782ca269e ]---
[    3.555161] i2c-pasemi: probe of 0000:00:1c.2 failed with error -16

The commit "Merge branch 'i2c/for-4.8'" is the problem. Link: 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=66304207cd341045df34195b4a8d422075bff513

I reverted the i2c commit with:

git revert 66304207cd341045df34195b4a8d422075bff513 -m 1

After that I was able to compile it. It boots without the error messages 
about the i2c-pasemi.

Do we need to modify the "i2c-pasemi.c"?

Cheers,

Christian

Re: [pasemi] problem with i2c-pasemi

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

On Sat, Jul 30, 2016 at 03:26:04PM +0200, Christian Zigotzky wrote:
> Hello Olof,
> 
> I compiled the latest git kernel 2 days ago. The kernel boots and works but
> unfortunately I get the following error messages about the i2c-pasemi during
> the start:

Which I2C busses do you have on your board and how are they described?
Can you post that?

Thanks,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[pasemi] problem with i2c-pasemi

[Christian Zigotzky]

Information about our I2C/SMBus busses:

     00:1c.0 SMBus: PA Semi, Inc PWRficient SMBus Controller (rev 01)
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 70
        Region 0: I/O ports at 7f0200 [size=64]

     00:1c.1 SMBus: PA Semi, Inc PWRficient SMBus Controller (rev 01)
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 71
        Region 0: I/O ports at 7f0240 [size=64]

     00:1c.2 SMBus: PA Semi, Inc PWRficient SMBus Controller (rev 01)
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 72
        Region 0: I/O ports at 7f0280 [size=64]

SMbus Controllers
The CPU provides 3 SMbus controllers, and these are used to connect up 
various SMbus and I2C devices. The number of SMbusses is expanded to 7 
via a 1:4 multiplexer on SMbus 1.

SMbus 0 is connected to the 4 DIMM sockets to support Serial Presence 
Detect (SPD). It is also connected to a standard 24LC128 EEPROM, and a 
temperature sensor (Texas Instruments TMP423). This sensor is connected 
to the CPU on-die temperature diodes for the 2 cores and SOC (main logic).

Cheers,

Christian


On 30 July 2016 at 8:20 PM, Wolfram Sang wrote:
>
> Which I2C busses do you have on your board and how are they described?
> Can you post that?
>
> Thanks,
>
>     Wolfram
>

Re: [pasemi] problem with i2c-pasemi

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

>     00:1c.2 SMBus: PA Semi, Inc PWRficient SMBus Controller (rev 01)
>        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
>        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>        Interrupt: pin A routed to IRQ 72
>        Region 0: I/O ports at 7f0280 [size=64]
> 
> SMbus Controllers
> The CPU provides 3 SMbus controllers, and these are used to connect up
> various SMbus and I2C devices. The number of SMbusses is expanded to 7 via a
> 1:4 multiplexer on SMbus 1.

Can you send the output of 'i2cdetect -l' (you need i2c-tools for that).
I assume the multiplexed bus occupies the bus number the above bus 1c.2
wants to have. This was present all the time, my recent change only made
it visible.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[pasemi] problem with i2c-pasemi

[Christian Zigotzky]

Here you are:

i2c-0    i2c           Radeon i2c bit bus 0x90             I2C adapter
i2c-1    i2c           Radeon i2c bit bus 0x91             I2C adapter
i2c-2    i2c           Radeon i2c bit bus 0x92             I2C adapter
i2c-3    i2c           Radeon i2c bit bus 0x93             I2C adapter
i2c-4    i2c           Radeon i2c bit bus 0x94             I2C adapter
i2c-5    i2c           Radeon i2c bit bus 0x95             I2C adapter
i2c-6    i2c           Radeon i2c bit bus 0x96             I2C adapter
i2c-7    i2c           Radeon i2c bit bus 0x97             I2C adapter
i2c-8    i2c           card0-DP-1                          I2C adapter
i2c-9    i2c           card0-DP-2                          I2C adapter

- Christian

On 31 July 2016 at 08:36 AM, Wolfram Sang wrote:
>>      00:1c.2 SMBus: PA Semi, Inc PWRficient SMBus Controller (rev 01)
>>         Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B- DisINTx-
>>         Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>         Interrupt: pin A routed to IRQ 72
>>         Region 0: I/O ports at 7f0280 [size=64]
>>
>> SMbus Controllers
>> The CPU provides 3 SMbus controllers, and these are used to connect up
>> various SMbus and I2C devices. The number of SMbusses is expanded to 7 via a
>> 1:4 multiplexer on SMbus 1.
> Can you send the output of 'i2cdetect -l' (you need i2c-tools for that).
> I assume the multiplexed bus occupies the bus number the above bus 1c.2
> wants to have. This was present all the time, my recent change only made
> it visible.
>

Re: [pasemi] problem with i2c-pasemi

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

On Sun, Jul 31, 2016 at 09:36:00AM +0200, Christian Zigotzky wrote:
> Here you are:
> 
> i2c-0    i2c           Radeon i2c bit bus 0x90             I2C adapter
> i2c-1    i2c           Radeon i2c bit bus 0x91             I2C adapter
> i2c-2    i2c           Radeon i2c bit bus 0x92             I2C adapter
> i2c-3    i2c           Radeon i2c bit bus 0x93             I2C adapter
> i2c-4    i2c           Radeon i2c bit bus 0x94             I2C adapter
> i2c-5    i2c           Radeon i2c bit bus 0x95             I2C adapter
> i2c-6    i2c           Radeon i2c bit bus 0x96             I2C adapter
> i2c-7    i2c           Radeon i2c bit bus 0x97             I2C adapter
> i2c-8    i2c           card0-DP-1                          I2C adapter
> i2c-9    i2c           card0-DP-2                          I2C adapter

Thanks. So, that means you don't have any bus from i2c-pasemi, since all
numbered busses it wants to have [0-2] are already taken by the Radeon
card. This has always been the case, no change in behaviour since 2008.
Only since last merge window, the I2C core just reports this conflict.
Maybe a bit too noisy?

I don't think using i2c_add_numbered_adapter is a good idea together
with PCI cards. I'd prefer to see i2c_add_adapter used. However, I don't
know the platform at all and if there is someone relying on a static
numbering scheme? I would assume this is not the case, because nobody
really noticed that the busses do not probe for a while. Anyone here
with more insight about PASEMI platform?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [pasemi] problem with i2c-pasemi

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

On Sun, Jul 31, 2016 at 09:36:00AM +0200, Christian Zigotzky wrote:
> Here you are:
> 
> i2c-0    i2c           Radeon i2c bit bus 0x90             I2C adapter
> i2c-1    i2c           Radeon i2c bit bus 0x91             I2C adapter
> i2c-2    i2c           Radeon i2c bit bus 0x92             I2C adapter
> i2c-3    i2c           Radeon i2c bit bus 0x93             I2C adapter
> i2c-4    i2c           Radeon i2c bit bus 0x94             I2C adapter
> i2c-5    i2c           Radeon i2c bit bus 0x95             I2C adapter
> i2c-6    i2c           Radeon i2c bit bus 0x96             I2C adapter
> i2c-7    i2c           Radeon i2c bit bus 0x97             I2C adapter
> i2c-8    i2c           card0-DP-1                          I2C adapter
> i2c-9    i2c           card0-DP-2                          I2C adapter

Thanks. So, that means you don't have any bus from i2c-pasemi, since all
numbered busses it wants to have [0-2] are already taken by the Radeon
card. This has always been the case, no change in behaviour since 2008.
Only since last merge window, the I2C core just reports this conflict.
Maybe a bit too noisy?

I don't think using i2c_add_numbered_adapter is a good idea together
with PCI cards. I'd prefer to see i2c_add_adapter used. However, I don't
know the platform at all and if there is someone relying on a static
numbering scheme? I would assume this is not the case, because nobody
really noticed that the busses do not probe for a while. Anyone here
with more insight about PASEMI platform?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[pasemi] problem with i2c-pasemi

[Christian Zigotzky]

Hello Wolfram,

Many thanks for your explanation. Olof knows the PASEMI platform very 
well. Maybe he could explain more. Adrian has also a good knowledge 
about the Nemo board.

Cheers,

Christian

On 01 August 2016 at 09:32 AM, Wolfram Sang wrote:
> On Sun, Jul 31, 2016 at 09:36:00AM +0200, Christian Zigotzky wrote:
>> Here you are:
>>
>> i2c-0    i2c           Radeon i2c bit bus 0x90             I2C adapter
>> i2c-1    i2c           Radeon i2c bit bus 0x91             I2C adapter
>> i2c-2    i2c           Radeon i2c bit bus 0x92             I2C adapter
>> i2c-3    i2c           Radeon i2c bit bus 0x93             I2C adapter
>> i2c-4    i2c           Radeon i2c bit bus 0x94             I2C adapter
>> i2c-5    i2c           Radeon i2c bit bus 0x95             I2C adapter
>> i2c-6    i2c           Radeon i2c bit bus 0x96             I2C adapter
>> i2c-7    i2c           Radeon i2c bit bus 0x97             I2C adapter
>> i2c-8    i2c           card0-DP-1                          I2C adapter
>> i2c-9    i2c           card0-DP-2                          I2C adapter
> Thanks. So, that means you don't have any bus from i2c-pasemi, since all
> numbered busses it wants to have [0-2] are already taken by the Radeon
> card. This has always been the case, no change in behaviour since 2008.
> Only since last merge window, the I2C core just reports this conflict.
> Maybe a bit too noisy?
>
> I don't think using i2c_add_numbered_adapter is a good idea together
> with PCI cards. I'd prefer to see i2c_add_adapter used. However, I don't
> know the platform at all and if there is someone relying on a static
> numbering scheme? I would assume this is not the case, because nobody
> really noticed that the busses do not probe for a while. Anyone here
> with more insight about PASEMI platform?
>

[pasemi] Radeon HD graphics card not recognised after the powerpc-4.8-1 commit

[Christian Zigotzky]

Hello,

I tried to compile the latest Git kernel today. It boots but Xorg 
doesn't work anymore.

     [    41.210] (++) using VT number 7

     [    41.341] (II) [KMS] Kernel modesetting enabled.
     [    41.341] (EE) No devices detected.
     [    41.341] (EE)
     Fatal server error:
     [    41.341] (EE) no screens found(EE)
     [    41.341] (EE)

I reverted the commit "powerpc-4.8-1" and Xorg works. The commit 
"powerpc-4.8-1" is the problem.

Link: 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bad60e6f259a01cf9f29a1ef8d435ab6c60b2de9

Which source code modification in the commit "powerpc-4.8-1" could be 
the problem?

Cheers,

Christian

Re: [pasemi] Radeon HD graphics card not recognised after the powerpc-4.8-1 commit

[Benjamin Herrenschmidt]

On Wed, 2016-08-03 at 11:03 +0200, Christian Zigotzky wrote:
> I reverted the commit "powerpc-4.8-1" and Xorg works. The commit 
> "powerpc-4.8-1" is the problem.
> 
> Link: 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bad60e6f259a01cf9f29a1ef8d435ab6c60b2de9
> 
> Which source code modification in the commit "powerpc-4.8-1" could be 
> the problem?

This is a merge, not a commit. Can you bisect down that branch ? Also
include the kernel dmesg log.

Cheers,
Ben.

[pasemi] Radeon HD graphics card not recognised after the powerpc-4.8-1 commit

[Christian Zigotzky]

Hi All,

I figured out that the Git kernel (4.8) successfully detected my Radeon 
HD6870 but Xorg can't access it.

The reason is, that the BusID has changed between the kernel 4.7 and 4.8.

Kernel 4.7:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
[AMD/ATI] Barts XT [Radeon HD 6870]

xorg.conf:

Section "Device"
BusID       "PCI:1:0:0"

Git kernel (4.8):

e900:01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
[AMD/ATI] Barts XT [Radeon HD 6870]

How does the new BusID look like in the xorg.conf?

dmesg | grep -i radeon

     [    0.997471] [drm] radeon kernel modesetting enabled.
     [    1.171136] radeon e900:01:00.0: VRAM: 1024M 0x0000000000000000 
- 0x000000003FFFFFFF (1024M used)
     [    1.171141] radeon e900:01:00.0: GTT: 1024M 0x0000000040000000 - 
0x000000007FFFFFFF
     [    1.171270] [drm] radeon: 1024M of VRAM memory ready
     [    1.171273] [drm] radeon: 1024M of GTT memory ready.
     [    1.176557] [drm] radeon: dpm initialized
     [    1.212690] radeon e900:01:00.0: WB enabled
     [    1.212697] radeon e900:01:00.0: fence driver on ring 0 use gpu 
addr 0x0000000040000c00 and cpu addr 0xc00000026dbdbc00
     [    1.212702] radeon e900:01:00.0: fence driver on ring 3 use gpu 
addr 0x0000000040000c0c and cpu addr 0xc00000026dbdbc0c
     [    1.219475] radeon e900:01:00.0: fence driver on ring 5 use gpu 
addr 0x0000000000072118 and cpu addr 0xd0000800901b2118
     [    1.219485] radeon e900:01:00.0: radeon: MSI limited to 32-bit
     [    1.219530] [drm] radeon: irq initialized.
     [    2.070343] [drm] Radeon Display Connectors
     [    2.917509] radeon e900:01:00.0: fb0: radeondrmfb frame buffer 
device
     [    2.923810] [drm] Initialized radeon 2.46.0 20080528 for 
e900:01:00.0 on minor 0

dmesg | grep -i e900:01:00.0

     [    0.152680] pci e900:01:00.0: [1002:6738] type 00 class 0x030000
     [    0.152694] pci e900:01:00.0: calling .pci_dev_pdn_setup+0x0/0x3c
     [    0.152710] pci e900:01:00.0: reg 0x10: [mem 
0x90000000-0x9fffffff 64bit pref]
     [    0.152722] pci e900:01:00.0: reg 0x18: [mem 
0xa0020000-0xa003ffff 64bit]
     [    0.152731] pci e900:01:00.0: reg 0x20: [io  0x2000-0x20ff]
     [    0.152744] pci e900:01:00.0: reg 0x30: [mem 
0xa0000000-0xa001ffff pref]
     [    0.152755] pci e900:01:00.0: calling 
.pcibios_fixup_resources+0x0/0x110
     [    0.152763] pci e900:01:00.0: calling .quirk_no_pm_reset+0x0/0x40
     [    0.152804] pci e900:01:00.0: supports D1 D2
     [    0.494871] pci e900:01:00.0: calling .fixup_vga+0x0/0x3c
     [    1.171136] radeon e900:01:00.0: VRAM: 1024M 0x0000000000000000 
- 0x000000003FFFFFFF (1024M used)
     [    1.171141] radeon e900:01:00.0: GTT: 1024M 0x0000000040000000 - 
0x000000007FFFFFFF
     [    1.212690] radeon e900:01:00.0: WB enabled
     [    1.212697] radeon e900:01:00.0: fence driver on ring 0 use gpu 
addr 0x0000000040000c00 and cpu addr 0xc00000026dbdbc00
     [    1.212702] radeon e900:01:00.0: fence driver on ring 3 use gpu 
addr 0x0000000040000c0c and cpu addr 0xc00000026dbdbc0c
     [    1.219475] radeon e900:01:00.0: fence driver on ring 5 use gpu 
addr 0x0000000000072118 and cpu addr 0xd0000800901b2118
     [    1.219485] radeon e900:01:00.0: radeon: MSI limited to 32-bit
     [    2.917509] radeon e900:01:00.0: fb0: radeondrmfb frame buffer 
device
     [    2.923810] [drm] Initialized radeon 2.46.0 20080528 for 
e900:01:00.0 on minor 0

FBDEV with the Git kernel (4.8):

Fatal server error:
xf86MapLegacyIO(): domain out of range

Cheers,

Christian

On 03 August 2016 at 12:53 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2016-08-03 at 11:03 +0200, Christian Zigotzky wrote:
>> I reverted the commit "powerpc-4.8-1" and Xorg works. The commit
>> "powerpc-4.8-1" is the problem.
>>
>> Link:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bad60e6f259a01cf9f29a1ef8d435ab6c60b2de9
>>
>> Which source code modification in the commit "powerpc-4.8-1" could be
>> the problem?
> This is a merge, not a commit. Can you bisect down that branch ? Also
> include the kernel dmesg log.
>
> Cheers,
> Ben.
>
>

Re: [pasemi] Radeon HD graphics card not recognised after the powerpc-4.8-1 commit

[Michael Ellerman]

Christian Zigotzky <chzigotzky@xenosoft.de> writes:

> Hi All,
>
> I figured out that the Git kernel (4.8) successfully detected my Radeon 
> HD6870 but Xorg can't access it.
>
> The reason is, that the BusID has changed between the kernel 4.7 and 4.8.

This should fix it?

  https://patchwork.ozlabs.org/patch/656042/

mpe breaks pasemi again :{

cheers

[pasemi] Radeon HD graphics card not recognised after the powerpc-4.8-1 commit

[Christian Zigotzky]

Hi Michael,

Thanks a million for your patch! :-)

@All
Keep your fingers crossed!

1. git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git a

2. patch -p0 < powerpc-pci-Only-do-fixed-PHB-numbering-on-powernv.patch

3. patch -p0 < nemo_4.8-3.patch

4. yes "" | make oldconfig

5. I activated the following new BTRFS options for Srtest:

CONFIG_BTRFS_FS_POSIX_ACL=y
CONFIG_BTRFS_FS_CHECK_INTEGRITY=y
CONFIG_BTRFS_FS_RUN_SANITY_TESTS=y
# CONFIG_BTRFS_DEBUG is not set
CONFIG_BTRFS_ASSERT=y

6. make vmlinux

...

Cheers,

Christian

On 05 August 2016 at 08:46 AM, Michael Ellerman wrote:
> Christian Zigotzky <chzigotzky@xenosoft.de> writes:
>
>> Hi All,
>>
>> I figured out that the Git kernel (4.8) successfully detected my Radeon
>> HD6870 but Xorg can't access it.
>>
>> The reason is, that the BusID has changed between the kernel 4.7 and 4.8.
> This should fix it?
>
>    https://patchwork.ozlabs.org/patch/656042/
>
> mpe breaks pasemi again :{
>
> cheers
>

[pasemi] Radeon HD graphics card not recognised after the powerpc-4.8-1 commit

[Christian Zigotzky]

Hi Michael,

Xorg works!!!!!!!!!!!!!!!!!!!!!!! :-)

Next step: make modules :-)

Cheers,

Christian

On 05 August 2016 at 11:13 AM, Christian Zigotzky wrote:
> Hi Michael,
>
> Thanks a million for your patch! :-)
>
> @All
> Keep your fingers crossed!
>
> 1. git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git a
>
> 2. patch -p0 < powerpc-pci-Only-do-fixed-PHB-numbering-on-powernv.patch
>
> 3. patch -p0 < nemo_4.8-3.patch
>
> 4. yes "" | make oldconfig
>
> 5. I activated the following new BTRFS options for Srtest:
>
> CONFIG_BTRFS_FS_POSIX_ACL=y
> CONFIG_BTRFS_FS_CHECK_INTEGRITY=y
> CONFIG_BTRFS_FS_RUN_SANITY_TESTS=y
> # CONFIG_BTRFS_DEBUG is not set
> CONFIG_BTRFS_ASSERT=y
>
> 6. make vmlinux
>
> ...
>
> Cheers,
>
> Christian
>
> On 05 August 2016 at 08:46 AM, Michael Ellerman wrote:
>> Christian Zigotzky <chzigotzky@xenosoft.de> writes:
>>
>>> Hi All,
>>>
>>> I figured out that the Git kernel (4.8) successfully detected my Radeon
>>> HD6870 but Xorg can't access it.
>>>
>>> The reason is, that the BusID has changed between the kernel 4.7 and 
>>> 4.8.
>> This should fix it?
>>
>>    https://patchwork.ozlabs.org/patch/656042/
>>
>> mpe breaks pasemi again :{
>>
>> cheers
>>
>
>

Re: [pasemi] Radeon HD graphics card not recognised after the powerpc-4.8-1 commit

[Michael Ellerman]

Christian Zigotzky <chzigotzky@xenosoft.de> writes:

> Hi Michael,
>
> Thanks a million for your patch! :-)

No worries :)

> @All
> Keep your fingers crossed!
>
> 1. git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git a

Normally that would be:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux

And this:

> 2. patch -p0 < powerpc-pci-Only-do-fixed-PHB-numbering-on-powernv.patch

Would be:

$ cd linux
$ patch -p1 < powerpc-pci-Only-do-fixed-PHB-numbering-on-powernv.patch

> 3. patch -p0 < nemo_4.8-3.patch
>
> 4. yes "" | make oldconfig

And that can be done with 'make olddefconfig'.

cheers

[pasemi] Internal CompactFlash (CF) card device not recognised after the powerpc-4.8-1 merge

[Christian Zigotzky]

Hi All,

The internal PASEMI CompactFlash (CF) card device doesn't work anymore 
after the powerpc-4.8-1 merge. That means the code for the internal CF 
card device in the Nemo patch doesn't work after the first PowerPC 
merge. The CompactFlash (CF) card slot is wired to the CPU local bus. It 
is typically used to hold the Linux kernel. I know it isn't well to use 
an own patch for that but I think it is a good time to integrate the 
PASEMI internal CompactFlash (CF) card device to the official kernel. 
What do you think? I am not a programmer so I can't integrate the source 
code for the internal CF card device. But maybe you can take the patch 
and integrate it.

We use the following patch for the kernel 4.7:

     diff -rupN a/drivers/ata/pata_of_platform.c 
b/drivers/ata/pata_of_platform.c
     --- a/drivers/ata/pata_of_platform.c   2016-08-05 
09:58:41.410569036 +0200
     +++ b/drivers/ata/pata_of_platform.c   2016-08-05 
09:59:54.414288884 +0200
     @@ -41,14 +41,36 @@ static int pata_of_platform_probe(struct
            return -EINVAL;
         }

     -   ret = of_address_to_resource(dn, 1, &ctl_res);
     -   if (ret) {
     -      dev_err(&ofdev->dev, "can't get CTL address from "
     -         "device tree\n");
     -      return -EINVAL;
     +   if (of_device_is_compatible(dn, "electra-ide")) {
     +      /* Altstatus is really at offset 0x3f6 from the primary window
     +       * on electra-ide. Adjust ctl_res and io_res accordingly.
     +       */
     +      ctl_res = io_res;
     +      ctl_res.start = ctl_res.start+0x3f6;
     +      io_res.end = ctl_res.start-1;
     +
     +#ifdef CONFIG_PPC_PASEMI_SB600
     +       } else if (of_device_is_compatible(dn, "electra-cf")) {
     +               /* Task regs are at 0x800, with alt status @ 0x80e 
in the primary window
     +                * on electra-cf. Adjust ctl_res and io_res 
accordingly.
     +                */
     +               ctl_res = io_res;
     +               io_res.start += 0x800;
     +               ctl_res.start = ctl_res.start + 0x80e;
     +               io_res.end = ctl_res.start-1;
     +#endif
     +   } else {
     +      ret = of_address_to_resource(dn, 1, &ctl_res);
     +      if (ret) {
     +         dev_err(&ofdev->dev, "can't get CTL address from "
     +            "device tree\n");
     +         return -EINVAL;
     +      }
         }

         irq_res = platform_get_resource(ofdev, IORESOURCE_IRQ, 0);
     +   if (irq_res)
     +      irq_res->flags = 0;

         prop = of_get_property(dn, "reg-shift", NULL);
         if (prop)
     @@ -65,6 +87,11 @@ static int pata_of_platform_probe(struct
            dev_info(&ofdev->dev, "pio-mode unspecified, assuming PIO0\n");
         }

     +#ifdef CONFIG_PPC_PASEMI_SB600
     +       irq_res = 0;                    // force irq off (doesn't 
seem to work)
     +#endif
     +
     +
         pio_mask = 1 << pio_mode;
         pio_mask |= (1 << pio_mode) - 1;

     @@ -74,7 +101,11 @@ static int pata_of_platform_probe(struct

      static struct of_device_id pata_of_platform_match[] = {
         { .compatible = "ata-generic", },
     -   { },
     +   { .compatible = "electra-ide", },
     +#ifdef CONFIG_PPC_PASEMI_SB600
     +       { .compatible = "electra-cf",},
     +#endif
     +   {},
      };
      MODULE_DEVICE_TABLE(of, pata_of_platform_match);

dmesg with the kernel 4.7:

zcat /var/log/dmesg.1.gz | grep -i ata7

     [    2.939788] ata7: PATA max PIO0 no IRQ, using PIO polling mmio 
cmd 0xf0000800 ctl 0xf000080e
     [    3.099186] ata7.00: CFA: SanDisk SDCFB-256, HDX 2.33, max PIO4
     [    3.099191] ata7.00: 501760 sectors, multi 0: LBA
     [    3.099199] ata7.00: configured for PIO

The dmesg of the latest Git kernel doesn't have any output of our 
internal CF card device.

Could you please integrate our PASEMI CF card device again?

Thanks,

Christian

[pasemi] Radeon HD graphics card not recognised after the powerpc-4.8-1 commit

[Christian Zigotzky]

Michael,

Thanks a lot for the hints! I will use your commands. I am still 
learning Linux. :-)

Cheers,

Christian

On 05 August 2016 at 12:59 PM, Michael Ellerman wrote:
> Christian Zigotzky <chzigotzky@xenosoft.de> writes:
>
>> Hi Michael,
>>
>> Thanks a million for your patch! :-)
> No worries :)
>
>> @All
>> Keep your fingers crossed!
>>
>> 1. git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git a
> Normally that would be:
>
> $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux
>
> And this:
>
>> 2. patch -p0 < powerpc-pci-Only-do-fixed-PHB-numbering-on-powernv.patch
> Would be:
>
> $ cd linux
> $ patch -p1 < powerpc-pci-Only-do-fixed-PHB-numbering-on-powernv.patch
>
>> 3. patch -p0 < nemo_4.8-3.patch
>>
>> 4. yes "" | make oldconfig
> And that can be done with 'make olddefconfig'.
>
> cheers
>

[pasemi] Internal CompactFlash (CF) card device not recognised after the powerpc-4.8-1 merge

[Christian Zigotzky]

Hi All,

I have found some information about the electra IDE CF card device: 
http://linuxppc-dev.ozlabs.narkive.com/kxQRFqGe/patch-pasemi-electra-ide-pata-platform-glue

I checked the kernel config and the merge but without any success.

Cheers,

Christian

On 05 August 2016 at 1:41 PM, Christian Zigotzky wrote:
> Hi All,
>
> The internal PASEMI CompactFlash (CF) card device doesn't work anymore 
> after the powerpc-4.8-1 merge. That means the code for the internal CF 
> card device in the Nemo patch doesn't work after the first PowerPC 
> merge. The CompactFlash (CF) card slot is wired to the CPU local bus. 
> It is typically used to hold the Linux kernel. I know it isn't well to 
> use an own patch for that but I think it is a good time to integrate 
> the PASEMI internal CompactFlash (CF) card device to the official 
> kernel. What do you think? I am not a programmer so I can't integrate 
> the source code for the internal CF card device. But maybe you can 
> take the patch and integrate it.
>
> We use the following patch for the kernel 4.7:
>
>     diff -rupN a/drivers/ata/pata_of_platform.c 
> b/drivers/ata/pata_of_platform.c
>     --- a/drivers/ata/pata_of_platform.c   2016-08-05 
> 09:58:41.410569036 +0200
>     +++ b/drivers/ata/pata_of_platform.c   2016-08-05 
> 09:59:54.414288884 +0200
>     @@ -41,14 +41,36 @@ static int pata_of_platform_probe(struct
>            return -EINVAL;
>         }
>
>     -   ret = of_address_to_resource(dn, 1, &ctl_res);
>     -   if (ret) {
>     -      dev_err(&ofdev->dev, "can't get CTL address from "
>     -         "device tree\n");
>     -      return -EINVAL;
>     +   if (of_device_is_compatible(dn, "electra-ide")) {
>     +      /* Altstatus is really at offset 0x3f6 from the primary window
>     +       * on electra-ide. Adjust ctl_res and io_res accordingly.
>     +       */
>     +      ctl_res = io_res;
>     +      ctl_res.start = ctl_res.start+0x3f6;
>     +      io_res.end = ctl_res.start-1;
>     +
>     +#ifdef CONFIG_PPC_PASEMI_SB600
>     +       } else if (of_device_is_compatible(dn, "electra-cf")) {
>     +               /* Task regs are at 0x800, with alt status @ 0x80e 
> in the primary window
>     +                * on electra-cf. Adjust ctl_res and io_res 
> accordingly.
>     +                */
>     +               ctl_res = io_res;
>     +               io_res.start += 0x800;
>     +               ctl_res.start = ctl_res.start + 0x80e;
>     +               io_res.end = ctl_res.start-1;
>     +#endif
>     +   } else {
>     +      ret = of_address_to_resource(dn, 1, &ctl_res);
>     +      if (ret) {
>     +         dev_err(&ofdev->dev, "can't get CTL address from "
>     +            "device tree\n");
>     +         return -EINVAL;
>     +      }
>         }
>
>         irq_res = platform_get_resource(ofdev, IORESOURCE_IRQ, 0);
>     +   if (irq_res)
>     +      irq_res->flags = 0;
>
>         prop = of_get_property(dn, "reg-shift", NULL);
>         if (prop)
>     @@ -65,6 +87,11 @@ static int pata_of_platform_probe(struct
>            dev_info(&ofdev->dev, "pio-mode unspecified, assuming 
> PIO0\n");
>         }
>
>     +#ifdef CONFIG_PPC_PASEMI_SB600
>     +       irq_res = 0;                    // force irq off (doesn't 
> seem to work)
>     +#endif
>     +
>     +
>         pio_mask = 1 << pio_mode;
>         pio_mask |= (1 << pio_mode) - 1;
>
>     @@ -74,7 +101,11 @@ static int pata_of_platform_probe(struct
>
>      static struct of_device_id pata_of_platform_match[] = {
>         { .compatible = "ata-generic", },
>     -   { },
>     +   { .compatible = "electra-ide", },
>     +#ifdef CONFIG_PPC_PASEMI_SB600
>     +       { .compatible = "electra-cf",},
>     +#endif
>     +   {},
>      };
>      MODULE_DEVICE_TABLE(of, pata_of_platform_match);
>
> dmesg with the kernel 4.7:
>
> zcat /var/log/dmesg.1.gz | grep -i ata7
>
>     [    2.939788] ata7: PATA max PIO0 no IRQ, using PIO polling mmio 
> cmd 0xf0000800 ctl 0xf000080e
>     [    3.099186] ata7.00: CFA: SanDisk SDCFB-256, HDX 2.33, max PIO4
>     [    3.099191] ata7.00: 501760 sectors, multi 0: LBA
>     [    3.099199] ata7.00: configured for PIO
>
> The dmesg of the latest Git kernel doesn't have any output of our 
> internal CF card device.
>
> Could you please integrate our PASEMI CF card device again?
>
> Thanks,
>
> Christian
>
>

[pasemi] Problem with the PA Semi PWRficient Gigabit Ethernet

[Christian Zigotzky]

Hi All,

It seems there is a problem with the PA Semi PWRficient Gigabit 
Ethernet. It tries very often to connect to the network but there isn't 
a network cable plugged in. There are two new commits about the PA Semi 
PWRficient Gigabit Ethernet in the Git source code.

- 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cf285de0231e53057726aea1fb87ab772765cb7
- 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=80721e7fa68f914a21b2685a01399b3aa80ac116

Cheers,

Christian

Re: [pasemi] Internal CompactFlash (CF) card device not recognised after the powerpc-4.8-1 merge

[Nicholas Piggin]

On Fri, 5 Aug 2016 16:38:17 +0200
Christian Zigotzky <chzigotzky@xenosoft.de> wrote:

> Hi All,


Hi Christian,

Firstly, thanks for the report. As a suggestion, it can be
better to reduce the CC list unless you have found a specific
commit that causes the problem. powerpc developers read this
list so you can send initial bug reports there.

Have you been able to bisect the exact commit which caused the
regression? If it's possible, that is the fastest way to get a
response to your report.

As for your driver support, it would indeed be a good idea to
get it supported in the upstream kernel. You should post a
new mail about that. Take a look at these 3 commits:

61f7162117d4767875825abf2f6ed1eeebbcceed
9cd55be4d22376893d2818ce3c0e5706a3d74121
ca99140a63b7326ee9a38f64c326317f2c63b594

Your patch comes from code based on the second one. The last
commit removed it, and says that it is not the best way to
implement it. You could cc this list and some of the people
involved with those commits and ask ask for advice about
getting your driver supported.

Thanks,
Nick


> I have found some information about the electra IDE CF card device: 
> http://linuxppc-dev.ozlabs.narkive.com/kxQRFqGe/patch-pasemi-electra-ide-pata-platform-glue
> 
> I checked the kernel config and the merge but without any success.
> 
> Cheers,
> 
> Christian
> 
> On 05 August 2016 at 1:41 PM, Christian Zigotzky wrote:
> > Hi All,
> >
> > The internal PASEMI CompactFlash (CF) card device doesn't work anymore 
> > after the powerpc-4.8-1 merge. That means the code for the internal CF 
> > card device in the Nemo patch doesn't work after the first PowerPC 
> > merge. The CompactFlash (CF) card slot is wired to the CPU local bus. 
> > It is typically used to hold the Linux kernel. I know it isn't well to 
> > use an own patch for that but I think it is a good time to integrate 
> > the PASEMI internal CompactFlash (CF) card device to the official 
> > kernel. What do you think? I am not a programmer so I can't integrate 
> > the source code for the internal CF card device. But maybe you can 
> > take the patch and integrate it.
> >
> > We use the following patch for the kernel 4.7:

Re: Internal CompactFlash (CF) card device not recognised after the powerpc-4.8-1 merge

[Darren Stevens]

Hello Nicholas

On 06/08/2016, Nicholas Piggin wrote:
> On Fri, 5 Aug 2016 16:38:17 +0200
> Christian Zigotzky <chzigotzky@xenosoft.de> wrote:
>
>> Hi All,
>
>
> Hi Christian,
[...]
> As for your driver support, it would indeed be a good idea to
> get it supported in the upstream kernel. You should post a
> new mail about that. Take a look at these 3 commits:
>
> 61f7162117d4767875825abf2f6ed1eeebbcceed
> 9cd55be4d22376893d2818ce3c0e5706a3d74121
> ca99140a63b7326ee9a38f64c326317f2c63b594
>
> Your patch comes from code based on the second one. The last
> commit removed it, and says that it is not the best way to
> implement it. You could cc this list and some of the people
> involved with those commits and ask ask for advice about
> getting your driver supported.

Actually, it's almost supported by the base PASemi code anyway, there is a
PCMCIA driver in setup.c, but our hardware has been changed enough to make it
hang the system when used. I should probably take another look and see If I
can fix that. The other option would be to move the above patch to where we
add our rtc platform device. One thing that does confuse me is the interrupt,
it's attached to GPIO 0, so should be on the mpic int 0 (or maybe 16?)but I
could never get it to work.

Regards
Darren

[pasemi] Internal CompactFlash (CF) card device not recognised after the powerpc-4.8-1 merge

[Christian Zigotzky]

Hi All,

I was able to patch the RC1 with the Nemo and PHB-numbering patch. 
Additionally I added some printks in the file pata_of_platform.c. I 
wanted to know which values have the following variables:

ctl_res = io_res;
io_res.start += 0x800;
ctl_res.start = ctl_res.start + 0x80e;
io_res.end = ctl_res.start-1;

It compiled without any problems but unfortunately I didn't see any 
printk outputs of these variables. The output of pata_of_platform is 
missing too. I see this output in the dmesg of the kernel 4.7 but I 
don't see it in the dmesg of the kernel 4.8.

I have the feeling, that pata_of_platform doesn't work anymore. Maybe 
this is the reason, why the CF card doesn't work anymore.

Maybe this is the problem: 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/platforms/pasemi/setup.c?id=bad60e6f259a01cf9f29a1ef8d435ab6c60b2de9

Do you have any hints for me?

Cheers,

Christian

On 05 August 2016 at 11:42 PM, Darren Stevens wrote:
> Hello Nicholas
>
> On 06/08/2016, Nicholas Piggin wrote:
>>
>> Hi Christian,
> On 05 August 2016 at 1:41 PM, Christian Zigotzky wrote:
>
> Hi All,
>
>
>
> The internal PASEMI CompactFlash (CF) card device doesn't work anymore
> after the powerpc-4.8-1 merge. That means the code for the internal CF
> card device in the Nemo patch doesn't work after the first PowerPC
> merge. The CompactFlash (CF) card slot is wired to the CPU local bus.
> It is typically used to hold the Linux kernel. I know it isn't well to
> use an own patch for that but I think it is a good time to integrate
> the PASEMI internal CompactFlash (CF) card device to the official
> kernel. What do you think? I am not a programmer so I can't integrate
> the source code for the internal CF card device. But maybe you can
> take the patch and integrate it.
>
>
>
> We use the following patch for the kernel 4.7:
>
>
>
>      diff -rupN a/drivers/ata/pata_of_platform.c
> b/drivers/ata/pata_of_platform.c
>
>      --- a/drivers/ata/pata_of_platform.c   2016-08-05
> 09:58:41.410569036 +0200
>
>      +++ b/drivers/ata/pata_of_platform.c   2016-08-05
> 09:59:54.414288884 +0200
>
>      @@ -41,14 +41,36 @@ static int pata_of_platform_probe(struct
>
>             return -EINVAL;
>
>          }
>
>
>
>      -   ret = of_address_to_resource(dn, 1, &ctl_res);
>
>      -   if (ret) {
>
>      -      dev_err(&ofdev->dev, "can't get CTL address from "
>
>      -         "device tree\n");
>
>      -      return -EINVAL;
>
>      +   if (of_device_is_compatible(dn, "electra-ide")) {
>
>      +      /* Altstatus is really at offset 0x3f6 from the primary window
>
>      +       * on electra-ide. Adjust ctl_res and io_res accordingly.
>
>      +       */
>
>      +      ctl_res = io_res;
>
>      +      ctl_res.start = ctl_res.start+0x3f6;
>
>      +      io_res.end = ctl_res.start-1;
>
>      +
>
>      +#ifdef CONFIG_PPC_PASEMI_SB600
>
>      +       } else if (of_device_is_compatible(dn, "electra-cf")) {
>
>      +               /* Task regs are at 0x800, with alt status @ 0x80e
> in the primary window
>
>      +                * on electra-cf. Adjust ctl_res and io_res
> accordingly.
>
>      +                */
>
>      +               ctl_res = io_res;
>
>      +               io_res.start += 0x800;
>
>      +               ctl_res.start = ctl_res.start + 0x80e;
>
>      +               io_res.end = ctl_res.start-1;
>
>      +#endif
>
>      +   } else {
>
>      +      ret = of_address_to_resource(dn, 1, &ctl_res);
>
>      +      if (ret) {
>
>      +         dev_err(&ofdev->dev, "can't get CTL address from "
>
>      +            "device tree\n");
>
>      +         return -EINVAL;
>
>      +      }
>
>          }
>
>
>
>          irq_res = platform_get_resource(ofdev, IORESOURCE_IRQ, 0);
>
>      +   if (irq_res)
>
>      +      irq_res->flags = 0;
>
>
>
>          prop = of_get_property(dn, "reg-shift", NULL);
>
>          if (prop)
>
>      @@ -65,6 +87,11 @@ static int pata_of_platform_probe(struct
>
>             dev_info(&ofdev->dev, "pio-mode unspecified, assuming
> PIO0\n");
>
>          }
>
>
>
>      +#ifdef CONFIG_PPC_PASEMI_SB600
>
>      +       irq_res = 0;                    // force irq off (doesn't
> seem to work)
>
>      +#endif
>
>      +
>
>      +
>
>          pio_mask = 1 << pio_mode;
>
>          pio_mask |= (1 << pio_mode) - 1;
>
>
>
>      @@ -74,7 +101,11 @@ static int pata_of_platform_probe(struct
>
>
>
>       static struct of_device_id pata_of_platform_match[] = {
>
>          { .compatible = "ata-generic", },
>
>      -   { },
>
>      +   { .compatible = "electra-ide", },
>
>      +#ifdef CONFIG_PPC_PASEMI_SB600
>
>      +       { .compatible = "electra-cf",},
>
>      +#endif
>
>      +   {},
>
>       };
>
>       MODULE_DEVICE_TABLE(of, pata_of_platform_match);
>
>
>
> dmesg with the kernel 4.7:
>
>
>
> zcat /var/log/dmesg.1.gz | grep -i ata7
>
>
>
>      [    2.939788] ata7: PATA max PIO0 no IRQ, using PIO polling mmio
> cmd 0xf0000800 ctl 0xf000080e
>
>      [    3.099186] ata7.00: CFA: SanDisk SDCFB-256, HDX 2.33, max PIO4
>
>      [    3.099191] ata7.00: 501760 sectors, multi 0: LBA
>
>      [    3.099199] ata7.00: configured for PIO
>
>
>
> The dmesg of the latest Git kernel doesn't have any output of our
> internal CF card device.
>
>
>
> Could you please integrate our PASEMI CF card device again?
>
>
>
> Thanks,
>
>
>
> Christian
>
>
>
>> As for your driver support, it would indeed be a good idea to
>> get it supported in the upstream kernel. You should post a
>> new mail about that. Take a look at these 3 commits:
>>
>> 61f7162117d4767875825abf2f6ed1eeebbcceed
>> 9cd55be4d22376893d2818ce3c0e5706a3d74121
>> ca99140a63b7326ee9a38f64c326317f2c63b594
>>
>> Your patch comes from code based on the second one. The last
>> commit removed it, and says that it is not the best way to
>> implement it. You could cc this list and some of the people
>> involved with those commits and ask ask for advice about
>> getting your driver supported.
> Actually, it's almost supported by the base PASemi code anyway, there is a
> PCMCIA driver in setup.c, but our hardware has been changed enough to make it
> hang the system when used. I should probably take another look and see If I
> can fix that. The other option would be to move the above patch to where we
> add our rtc platform device. One thing that does confuse me is the interrupt,
> it's attached to GPIO 0, so should be on the mpic int 0 (or maybe 16?)but I
> could never get it to work.
>
> Regards
> Darren
>
>

[pasemi] Internal CompactFlash (CF) card device not recognised after the powerpc-4.8-1 merge

[Christian Zigotzky]

Hi All,

I reverted the commit 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/platforms/pasemi/setup.c?id=bad60e6f259a01cf9f29a1ef8d435ab6c60b2de9. 
It boots but it doesn't find any partitions.

Cheers,

Christian

On 11 August 2016 at 5:03 PM, Christian Zigotzky wrote:
> Hi All,
>
> I was able to patch the RC1 with the Nemo and PHB-numbering patch. 
> Additionally I added some printks in the file pata_of_platform.c. I 
> wanted to know which values have the following variables:
>
> ctl_res = io_res;
> io_res.start += 0x800;
> ctl_res.start = ctl_res.start + 0x80e;
> io_res.end = ctl_res.start-1;
>
> It compiled without any problems but unfortunately I didn't see any 
> printk outputs of these variables. The output of pata_of_platform is 
> missing too. I see this output in the dmesg of the kernel 4.7 but I 
> don't see it in the dmesg of the kernel 4.8.
>
> I have the feeling, that pata_of_platform doesn't work anymore. Maybe 
> this is the reason, why the CF card doesn't work anymore.
>
> Maybe this is the problem: 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/platforms/pasemi/setup.c?id=bad60e6f259a01cf9f29a1ef8d435ab6c60b2de9
>
> Do you have any hints for me?
>
> Cheers,
>
> Christian
>
> On 05 August 2016 at 11:42 PM, Darren Stevens wrote:
>> Hello Nicholas
>>
>> On 06/08/2016, Nicholas Piggin wrote:
>>>
>>> Hi Christian,
>> On 05 August 2016 at 1:41 PM, Christian Zigotzky wrote:
>>
>> Hi All,
>>
>>
>>
>> The internal PASEMI CompactFlash (CF) card device doesn't work anymore
>> after the powerpc-4.8-1 merge. That means the code for the internal CF
>> card device in the Nemo patch doesn't work after the first PowerPC
>> merge. The CompactFlash (CF) card slot is wired to the CPU local bus.
>> It is typically used to hold the Linux kernel. I know it isn't well to
>> use an own patch for that but I think it is a good time to integrate
>> the PASEMI internal CompactFlash (CF) card device to the official
>> kernel. What do you think? I am not a programmer so I can't integrate
>> the source code for the internal CF card device. But maybe you can
>> take the patch and integrate it.
>>
>>
>>
>> We use the following patch for the kernel 4.7:
>>
>>
>>
>>      diff -rupN a/drivers/ata/pata_of_platform.c
>> b/drivers/ata/pata_of_platform.c
>>
>>      --- a/drivers/ata/pata_of_platform.c   2016-08-05
>> 09:58:41.410569036 +0200
>>
>>      +++ b/drivers/ata/pata_of_platform.c   2016-08-05
>> 09:59:54.414288884 +0200
>>
>>      @@ -41,14 +41,36 @@ static int pata_of_platform_probe(struct
>>
>>             return -EINVAL;
>>
>>          }
>>
>>
>>
>>      -   ret = of_address_to_resource(dn, 1, &ctl_res);
>>
>>      -   if (ret) {
>>
>>      -      dev_err(&ofdev->dev, "can't get CTL address from "
>>
>>      -         "device tree\n");
>>
>>      -      return -EINVAL;
>>
>>      +   if (of_device_is_compatible(dn, "electra-ide")) {
>>
>>      +      /* Altstatus is really at offset 0x3f6 from the primary 
>> window
>>
>>      +       * on electra-ide. Adjust ctl_res and io_res accordingly.
>>
>>      +       */
>>
>>      +      ctl_res = io_res;
>>
>>      +      ctl_res.start = ctl_res.start+0x3f6;
>>
>>      +      io_res.end = ctl_res.start-1;
>>
>>      +
>>
>>      +#ifdef CONFIG_PPC_PASEMI_SB600
>>
>>      +       } else if (of_device_is_compatible(dn, "electra-cf")) {
>>
>>      +               /* Task regs are at 0x800, with alt status @ 0x80e
>> in the primary window
>>
>>      +                * on electra-cf. Adjust ctl_res and io_res
>> accordingly.
>>
>>      +                */
>>
>>      +               ctl_res = io_res;
>>
>>      +               io_res.start += 0x800;
>>
>>      +               ctl_res.start = ctl_res.start + 0x80e;
>>
>>      +               io_res.end = ctl_res.start-1;
>>
>>      +#endif
>>
>>      +   } else {
>>
>>      +      ret = of_address_to_resource(dn, 1, &ctl_res);
>>
>>      +      if (ret) {
>>
>>      +         dev_err(&ofdev->dev, "can't get CTL address from "
>>
>>      +            "device tree\n");
>>
>>      +         return -EINVAL;
>>
>>      +      }
>>
>>          }
>>
>>
>>
>>          irq_res = platform_get_resource(ofdev, IORESOURCE_IRQ, 0);
>>
>>      +   if (irq_res)
>>
>>      +      irq_res->flags = 0;
>>
>>
>>
>>          prop = of_get_property(dn, "reg-shift", NULL);
>>
>>          if (prop)
>>
>>      @@ -65,6 +87,11 @@ static int pata_of_platform_probe(struct
>>
>>             dev_info(&ofdev->dev, "pio-mode unspecified, assuming
>> PIO0\n");
>>
>>          }
>>
>>
>>
>>      +#ifdef CONFIG_PPC_PASEMI_SB600
>>
>>      +       irq_res = 0;                    // force irq off (doesn't
>> seem to work)
>>
>>      +#endif
>>
>>      +
>>
>>      +
>>
>>          pio_mask = 1 << pio_mode;
>>
>>          pio_mask |= (1 << pio_mode) - 1;
>>
>>
>>
>>      @@ -74,7 +101,11 @@ static int pata_of_platform_probe(struct
>>
>>
>>
>>       static struct of_device_id pata_of_platform_match[] = {
>>
>>          { .compatible = "ata-generic", },
>>
>>      -   { },
>>
>>      +   { .compatible = "electra-ide", },
>>
>>      +#ifdef CONFIG_PPC_PASEMI_SB600
>>
>>      +       { .compatible = "electra-cf",},
>>
>>      +#endif
>>
>>      +   {},
>>
>>       };
>>
>>       MODULE_DEVICE_TABLE(of, pata_of_platform_match);
>>
>>
>>
>> dmesg with the kernel 4.7:
>>
>>
>>
>> zcat /var/log/dmesg.1.gz | grep -i ata7
>>
>>
>>
>>      [    2.939788] ata7: PATA max PIO0 no IRQ, using PIO polling mmio
>> cmd 0xf0000800 ctl 0xf000080e
>>
>>      [    3.099186] ata7.00: CFA: SanDisk SDCFB-256, HDX 2.33, max PIO4
>>
>>      [    3.099191] ata7.00: 501760 sectors, multi 0: LBA
>>
>>      [    3.099199] ata7.00: configured for PIO
>>
>>
>>
>> The dmesg of the latest Git kernel doesn't have any output of our
>> internal CF card device.
>>
>>
>>
>> Could you please integrate our PASEMI CF card device again?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Christian
>>
>>
>>
>>> As for your driver support, it would indeed be a good idea to
>>> get it supported in the upstream kernel. You should post a
>>> new mail about that. Take a look at these 3 commits:
>>>
>>> 61f7162117d4767875825abf2f6ed1eeebbcceed
>>> 9cd55be4d22376893d2818ce3c0e5706a3d74121
>>> ca99140a63b7326ee9a38f64c326317f2c63b594
>>>
>>> Your patch comes from code based on the second one. The last
>>> commit removed it, and says that it is not the best way to
>>> implement it. You could cc this list and some of the people
>>> involved with those commits and ask ask for advice about
>>> getting your driver supported.
>> Actually, it's almost supported by the base PASemi code anyway, there 
>> is a
>> PCMCIA driver in setup.c, but our hardware has been changed enough to 
>> make it
>> hang the system when used. I should probably take another look and 
>> see If I
>> can fix that. The other option would be to move the above patch to 
>> where we
>> add our rtc platform device. One thing that does confuse me is the 
>> interrupt,
>> it's attached to GPIO 0, so should be on the mpic int 0 (or maybe 
>> 16?)but I
>> could never get it to work.
>>
>> Regards
>> Darren
>>
>>
>
>
>

[pasemi] Internal CompactFlash (CF) card device not recognised after the powerpc-4.8-1 merge

[Christian Zigotzky]

I meant, I reverted the setup.c.

- Christian

On 12 August 2016 at 11:00 AM, Christian Zigotzky wrote:
> Hi All,
>
> I reverted the commit 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/platforms/pasemi/setup.c?id=bad60e6f259a01cf9f29a1ef8d435ab6c60b2de9. 
> It boots but it doesn't find any partitions.
>
> Cheers,
>
> Christian
>
> On 11 August 2016 at 5:03 PM, Christian Zigotzky wrote:
>> Hi All,
>>
>> I was able to patch the RC1 with the Nemo and PHB-numbering patch. 
>> Additionally I added some printks in the file pata_of_platform.c. I 
>> wanted to know which values have the following variables:
>>
>> ctl_res = io_res;
>> io_res.start += 0x800;
>> ctl_res.start = ctl_res.start + 0x80e;
>> io_res.end = ctl_res.start-1;
>>
>> It compiled without any problems but unfortunately I didn't see any 
>> printk outputs of these variables. The output of pata_of_platform is 
>> missing too. I see this output in the dmesg of the kernel 4.7 but I 
>> don't see it in the dmesg of the kernel 4.8.
>>
>> I have the feeling, that pata_of_platform doesn't work anymore. Maybe 
>> this is the reason, why the CF card doesn't work anymore.
>>
>> Maybe this is the problem: 
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/platforms/pasemi/setup.c?id=bad60e6f259a01cf9f29a1ef8d435ab6c60b2de9
>>
>> Do you have any hints for me?
>>
>> Cheers,
>>
>> Christian
>>
>> On 05 August 2016 at 11:42 PM, Darren Stevens wrote:
>>> Hello Nicholas
>>>
>>> On 06/08/2016, Nicholas Piggin wrote:
>>>>
>>>> Hi Christian,
>>> On 05 August 2016 at 1:41 PM, Christian Zigotzky wrote:
>>>
>>> Hi All,
>>>
>>>
>>>
>>> The internal PASEMI CompactFlash (CF) card device doesn't work anymore
>>> after the powerpc-4.8-1 merge. That means the code for the internal CF
>>> card device in the Nemo patch doesn't work after the first PowerPC
>>> merge. The CompactFlash (CF) card slot is wired to the CPU local bus.
>>> It is typically used to hold the Linux kernel. I know it isn't well to
>>> use an own patch for that but I think it is a good time to integrate
>>> the PASEMI internal CompactFlash (CF) card device to the official
>>> kernel. What do you think? I am not a programmer so I can't integrate
>>> the source code for the internal CF card device. But maybe you can
>>> take the patch and integrate it.
>>>
>>>
>>>
>>> We use the following patch for the kernel 4.7:
>>>
>>>
>>>
>>>      diff -rupN a/drivers/ata/pata_of_platform.c
>>> b/drivers/ata/pata_of_platform.c
>>>
>>>      --- a/drivers/ata/pata_of_platform.c   2016-08-05
>>> 09:58:41.410569036 +0200
>>>
>>>      +++ b/drivers/ata/pata_of_platform.c   2016-08-05
>>> 09:59:54.414288884 +0200
>>>
>>>      @@ -41,14 +41,36 @@ static int pata_of_platform_probe(struct
>>>
>>>             return -EINVAL;
>>>
>>>          }
>>>
>>>
>>>
>>>      -   ret = of_address_to_resource(dn, 1, &ctl_res);
>>>
>>>      -   if (ret) {
>>>
>>>      -      dev_err(&ofdev->dev, "can't get CTL address from "
>>>
>>>      -         "device tree\n");
>>>
>>>      -      return -EINVAL;
>>>
>>>      +   if (of_device_is_compatible(dn, "electra-ide")) {
>>>
>>>      +      /* Altstatus is really at offset 0x3f6 from the primary 
>>> window
>>>
>>>      +       * on electra-ide. Adjust ctl_res and io_res accordingly.
>>>
>>>      +       */
>>>
>>>      +      ctl_res = io_res;
>>>
>>>      +      ctl_res.start = ctl_res.start+0x3f6;
>>>
>>>      +      io_res.end = ctl_res.start-1;
>>>
>>>      +
>>>
>>>      +#ifdef CONFIG_PPC_PASEMI_SB600
>>>
>>>      +       } else if (of_device_is_compatible(dn, "electra-cf")) {
>>>
>>>      +               /* Task regs are at 0x800, with alt status @ 0x80e
>>> in the primary window
>>>
>>>      +                * on electra-cf. Adjust ctl_res and io_res
>>> accordingly.
>>>
>>>      +                */
>>>
>>>      +               ctl_res = io_res;
>>>
>>>      +               io_res.start += 0x800;
>>>
>>>      +               ctl_res.start = ctl_res.start + 0x80e;
>>>
>>>      +               io_res.end = ctl_res.start-1;
>>>
>>>      +#endif
>>>
>>>      +   } else {
>>>
>>>      +      ret = of_address_to_resource(dn, 1, &ctl_res);
>>>
>>>      +      if (ret) {
>>>
>>>      +         dev_err(&ofdev->dev, "can't get CTL address from "
>>>
>>>      +            "device tree\n");
>>>
>>>      +         return -EINVAL;
>>>
>>>      +      }
>>>
>>>          }
>>>
>>>
>>>
>>>          irq_res = platform_get_resource(ofdev, IORESOURCE_IRQ, 0);
>>>
>>>      +   if (irq_res)
>>>
>>>      +      irq_res->flags = 0;
>>>
>>>
>>>
>>>          prop = of_get_property(dn, "reg-shift", NULL);
>>>
>>>          if (prop)
>>>
>>>      @@ -65,6 +87,11 @@ static int pata_of_platform_probe(struct
>>>
>>>             dev_info(&ofdev->dev, "pio-mode unspecified, assuming
>>> PIO0\n");
>>>
>>>          }
>>>
>>>
>>>
>>>      +#ifdef CONFIG_PPC_PASEMI_SB600
>>>
>>>      +       irq_res = 0;                    // force irq off (doesn't
>>> seem to work)
>>>
>>>      +#endif
>>>
>>>      +
>>>
>>>      +
>>>
>>>          pio_mask = 1 << pio_mode;
>>>
>>>          pio_mask |= (1 << pio_mode) - 1;
>>>
>>>
>>>
>>>      @@ -74,7 +101,11 @@ static int pata_of_platform_probe(struct
>>>
>>>
>>>
>>>       static struct of_device_id pata_of_platform_match[] = {
>>>
>>>          { .compatible = "ata-generic", },
>>>
>>>      -   { },
>>>
>>>      +   { .compatible = "electra-ide", },
>>>
>>>      +#ifdef CONFIG_PPC_PASEMI_SB600
>>>
>>>      +       { .compatible = "electra-cf",},
>>>
>>>      +#endif
>>>
>>>      +   {},
>>>
>>>       };
>>>
>>>       MODULE_DEVICE_TABLE(of, pata_of_platform_match);
>>>
>>>
>>>
>>> dmesg with the kernel 4.7:
>>>
>>>
>>>
>>> zcat /var/log/dmesg.1.gz | grep -i ata7
>>>
>>>
>>>
>>>      [    2.939788] ata7: PATA max PIO0 no IRQ, using PIO polling mmio
>>> cmd 0xf0000800 ctl 0xf000080e
>>>
>>>      [    3.099186] ata7.00: CFA: SanDisk SDCFB-256, HDX 2.33, max PIO4
>>>
>>>      [    3.099191] ata7.00: 501760 sectors, multi 0: LBA
>>>
>>>      [    3.099199] ata7.00: configured for PIO
>>>
>>>
>>>
>>> The dmesg of the latest Git kernel doesn't have any output of our
>>> internal CF card device.
>>>
>>>
>>>
>>> Could you please integrate our PASEMI CF card device again?
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Christian
>>>
>>>
>>>
>>>> As for your driver support, it would indeed be a good idea to
>>>> get it supported in the upstream kernel. You should post a
>>>> new mail about that. Take a look at these 3 commits:
>>>>
>>>> 61f7162117d4767875825abf2f6ed1eeebbcceed
>>>> 9cd55be4d22376893d2818ce3c0e5706a3d74121
>>>> ca99140a63b7326ee9a38f64c326317f2c63b594
>>>>
>>>> Your patch comes from code based on the second one. The last
>>>> commit removed it, and says that it is not the best way to
>>>> implement it. You could cc this list and some of the people
>>>> involved with those commits and ask ask for advice about
>>>> getting your driver supported.
>>> Actually, it's almost supported by the base PASemi code anyway, 
>>> there is a
>>> PCMCIA driver in setup.c, but our hardware has been changed enough 
>>> to make it
>>> hang the system when used. I should probably take another look and 
>>> see If I
>>> can fix that. The other option would be to move the above patch to 
>>> where we
>>> add our rtc platform device. One thing that does confuse me is the 
>>> interrupt,
>>> it's attached to GPIO 0, so should be on the mpic int 0 (or maybe 
>>> 16?)but I
>>> could never get it to work.
>>>
>>> Regards
>>> Darren
>>>
>>>
>>
>>
>>
>
>

[pasemi] Internal CompactFlash (CF) card device not recognised after the powerpc-4.8-1 merge

[Christian Zigotzky]

Hi All,

I compiled the RC1 of kernel 4.8 with Olof's CompactFlash driver for PA 
Semi Electra boards today. Unfortunately this driver doesn't detect our 
CF device.

dmesg | grep -i pasemi

[    0.000000] mpic: Setting up MPIC "PASEMI-OPIC" version 1.3 at 
fc000000, max 2 CPUs
[    2.937676] pasemi_mac 0000:00:15.0: no mac address in device tree, 
not configuring
[    4.288347] [c00000026d127680] [c000000000816cdc] 
.pasemi_smb_probe+0x12c/0x188
[    4.288399] [c00000026d127bb0] [c000000001560198] 
.pasemi_smb_driver_init+0x24/0x38
[    4.288455] i2c-pasemi: probe of 0000:00:1c.0 failed with error -16
[    4.288596] [c00000026d127680] [c000000000816cdc] 
.pasemi_smb_probe+0x12c/0x188
[    4.288645] [c00000026d127bb0] [c000000001560198] 
.pasemi_smb_driver_init+0x24/0x38
[    4.288695] i2c-pasemi: probe of 0000:00:1c.1 failed with error -16
[    4.288834] [c00000026d127680] [c000000000816cdc] 
.pasemi_smb_probe+0x12c/0x188
[    4.288883] [c00000026d127bb0] [c000000001560198] 
.pasemi_smb_driver_init+0x24/0x38
[    4.288933] i2c-pasemi: probe of 0000:00:1c.2 failed with error -16
[    4.289745] EDAC MC0: Giving out device to module pasemi_edac 
controller pasemi,pwrficient-mc: DEV 0000:00:04.0 (POLLED)
[    4.290425] EDAC MC1: Giving out device to module pasemi_edac 
controller pasemi,pwrficient-mc: DEV 0000:00:05.0 (POLLED)
[   33.061617] pasemi_mac 0000:00:14.3: PHY init failed: -19.
[   33.061622] pasemi_mac 0000:00:14.3: Defaulting to 1Gbit full duplex

dmesg | grep -i ata

[    0.000000] Memory: 8072880K/8388608K available (11312K kernel code, 
2116K rwdata, 10256K rodata, 860K init, 1813K bss, 315728K reserved, 0K 
cma-reserved)
[    0.157114] pci 0000:05:12.0: calling .quirk_no_ata_d3+0x0/0x30
[    0.157217] pci 0000:05:12.0: set SATA to AHCI mode
[    0.158892] pci 0000:05:14.1: calling .quirk_no_ata_d3+0x0/0x30
[    0.411908] libata version 3.00 loaded.
[    2.917640] ahci 0000:05:12.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 
0xf impl SATA mode
[    2.920704] ata1: SATA max UDMA/133 abar m1024@0xa0209400 port 
0xa0209500 irq 9
[    2.921186] ata2: SATA max UDMA/133 abar m1024@0xa0209400 port 
0xa0209580 irq 9
[    2.921657] ata3: SATA max UDMA/133 abar m1024@0xa0209400 port 
0xa0209600 irq 9
[    2.922137] ata4: SATA max UDMA/133 abar m1024@0xa0209400 port 
0xa0209680 irq 9
[    2.923384] scsi host4: pata_atiixp
[    2.923722] scsi host5: pata_atiixp
[    2.923998] ata5: PATA max UDMA/100 cmd 0x1030 ctl 0x1054 bmdma 
0x1000 irq 9
[    2.924453] ata6: DUMMY
[    3.232241] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    3.232308] ata2: SATA link down (SStatus 0 SControl 300)
[    3.232351] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    3.232384] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    3.252058] ata3.00: ATAPI: HL-DT-ST DVDRAM GH22NS50, TN01, max UDMA/100
[    3.252064] ata3.00: SB600 AHCI: limiting to 255 sectors per cmd
[    3.292581] ata3.00: SB600 AHCI: limiting to 255 sectors per cmd
[    3.292584] ata3.00: configured for UDMA/100
[    3.333404] ata4.00: ATA-8: ESA3SF1240GB, 4.C.V, max UDMA/133
[    3.333408] ata4.00: 468862128 sectors, multi 16: LBA48 NCQ (depth 
31/32), AA
[    3.333415] ata4.00: SB600 AHCI: limiting to 255 sectors per cmd
[    3.433200] ata4.00: SB600 AHCI: limiting to 255 sectors per cmd
[    3.433203] ata4.00: configured for UDMA/133
[    3.844943] ata1.00: ATA-8: ST2000DM001-9YN164, CC4B, max UDMA/133
[    3.844947] ata1.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 
31/32), AA
[    3.844955] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
[    3.903500] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
[    3.903504] ata1.00: configured for UDMA/133
[    3.926117] scsi 0:0:0:0: Direct-Access     ATA ST2000DM001-9YN1 CC4B 
PQ: 0 ANSI: 5
[    4.363105] scsi 3:0:0:0: Direct-Access     ATA ESA3SF1240GB     V    
PQ: 0 ANSI: 5
[   10.432400] EXT4-fs (sda4): mounted filesystem with ordered data 
mode. Opts: (null)

Please help us.

Cheers,

Christian


On 12 August 2016 at 11:20 AM, Christian Zigotzky wrote:
> I meant, I reverted the setup.c.
>
> - Christian
>
> On 12 August 2016 at 11:00 AM, Christian Zigotzky wrote:
>> Hi All,
>>
>> I reverted the commit 
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/platforms/pasemi/setup.c?id=bad60e6f259a01cf9f29a1ef8d435ab6c60b2de9. 
>> It boots but it doesn't find any partitions.
>>
>> Cheers,
>>
>> Christian
>>
>> On 11 August 2016 at 5:03 PM, Christian Zigotzky wrote:
>>> Hi All,
>>>
>>> I was able to patch the RC1 with the Nemo and PHB-numbering patch. 
>>> Additionally I added some printks in the file pata_of_platform.c. I 
>>> wanted to know which values have the following variables:
>>>
>>> ctl_res = io_res;
>>> io_res.start += 0x800;
>>> ctl_res.start = ctl_res.start + 0x80e;
>>> io_res.end = ctl_res.start-1;
>>>
>>> It compiled without any problems but unfortunately I didn't see any 
>>> printk outputs of these variables. The output of pata_of_platform is 
>>> missing too. I see this output in the dmesg of the kernel 4.7 but I 
>>> don't see it in the dmesg of the kernel 4.8.
>>>
>>> I have the feeling, that pata_of_platform doesn't work anymore. 
>>> Maybe this is the reason, why the CF card doesn't work anymore.
>>>
>>> Maybe this is the problem: 
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/platforms/pasemi/setup.c?id=bad60e6f259a01cf9f29a1ef8d435ab6c60b2de9
>>>
>>> Do you have any hints for me?
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>> On 05 August 2016 at 11:42 PM, Darren Stevens wrote:
>>>> Hello Nicholas
>>>>
>>>> On 06/08/2016, Nicholas Piggin wrote:
>>>>>
>>>>> Hi Christian,
>>>> On 05 August 2016 at 1:41 PM, Christian Zigotzky wrote:
>>>>
>>>> Hi All,
>>>>
>>>>
>>>>
>>>> The internal PASEMI CompactFlash (CF) card device doesn't work anymore
>>>> after the powerpc-4.8-1 merge. That means the code for the internal CF
>>>> card device in the Nemo patch doesn't work after the first PowerPC
>>>> merge. The CompactFlash (CF) card slot is wired to the CPU local bus.
>>>> It is typically used to hold the Linux kernel. I know it isn't well to
>>>> use an own patch for that but I think it is a good time to integrate
>>>> the PASEMI internal CompactFlash (CF) card device to the official
>>>> kernel. What do you think? I am not a programmer so I can't integrate
>>>> the source code for the internal CF card device. But maybe you can
>>>> take the patch and integrate it.
>>>>
>>>>
>>>>
>>>> We use the following patch for the kernel 4.7:
>>>>
>>>>
>>>>
>>>>      diff -rupN a/drivers/ata/pata_of_platform.c
>>>> b/drivers/ata/pata_of_platform.c
>>>>
>>>>      --- a/drivers/ata/pata_of_platform.c   2016-08-05
>>>> 09:58:41.410569036 +0200
>>>>
>>>>      +++ b/drivers/ata/pata_of_platform.c   2016-08-05
>>>> 09:59:54.414288884 +0200
>>>>
>>>>      @@ -41,14 +41,36 @@ static int pata_of_platform_probe(struct
>>>>
>>>>             return -EINVAL;
>>>>
>>>>          }
>>>>
>>>>
>>>>
>>>>      -   ret = of_address_to_resource(dn, 1, &ctl_res);
>>>>
>>>>      -   if (ret) {
>>>>
>>>>      -      dev_err(&ofdev->dev, "can't get CTL address from "
>>>>
>>>>      -         "device tree\n");
>>>>
>>>>      -      return -EINVAL;
>>>>
>>>>      +   if (of_device_is_compatible(dn, "electra-ide")) {
>>>>
>>>>      +      /* Altstatus is really at offset 0x3f6 from the primary 
>>>> window
>>>>
>>>>      +       * on electra-ide. Adjust ctl_res and io_res accordingly.
>>>>
>>>>      +       */
>>>>
>>>>      +      ctl_res = io_res;
>>>>
>>>>      +      ctl_res.start = ctl_res.start+0x3f6;
>>>>
>>>>      +      io_res.end = ctl_res.start-1;
>>>>
>>>>      +
>>>>
>>>>      +#ifdef CONFIG_PPC_PASEMI_SB600
>>>>
>>>>      +       } else if (of_device_is_compatible(dn, "electra-cf")) {
>>>>
>>>>      +               /* Task regs are at 0x800, with alt status @ 
>>>> 0x80e
>>>> in the primary window
>>>>
>>>>      +                * on electra-cf. Adjust ctl_res and io_res
>>>> accordingly.
>>>>
>>>>      +                */
>>>>
>>>>      +               ctl_res = io_res;
>>>>
>>>>      +               io_res.start += 0x800;
>>>>
>>>>      +               ctl_res.start = ctl_res.start + 0x80e;
>>>>
>>>>      +               io_res.end = ctl_res.start-1;
>>>>
>>>>      +#endif
>>>>
>>>>      +   } else {
>>>>
>>>>      +      ret = of_address_to_resource(dn, 1, &ctl_res);
>>>>
>>>>      +      if (ret) {
>>>>
>>>>      +         dev_err(&ofdev->dev, "can't get CTL address from "
>>>>
>>>>      +            "device tree\n");
>>>>
>>>>      +         return -EINVAL;
>>>>
>>>>      +      }
>>>>
>>>>          }
>>>>
>>>>
>>>>
>>>>          irq_res = platform_get_resource(ofdev, IORESOURCE_IRQ, 0);
>>>>
>>>>      +   if (irq_res)
>>>>
>>>>      +      irq_res->flags = 0;
>>>>
>>>>
>>>>
>>>>          prop = of_get_property(dn, "reg-shift", NULL);
>>>>
>>>>          if (prop)
>>>>
>>>>      @@ -65,6 +87,11 @@ static int pata_of_platform_probe(struct
>>>>
>>>>             dev_info(&ofdev->dev, "pio-mode unspecified, assuming
>>>> PIO0\n");
>>>>
>>>>          }
>>>>
>>>>
>>>>
>>>>      +#ifdef CONFIG_PPC_PASEMI_SB600
>>>>
>>>>      +       irq_res = 0;                    // force irq off (doesn't
>>>> seem to work)
>>>>
>>>>      +#endif
>>>>
>>>>      +
>>>>
>>>>      +
>>>>
>>>>          pio_mask = 1 << pio_mode;
>>>>
>>>>          pio_mask |= (1 << pio_mode) - 1;
>>>>
>>>>
>>>>
>>>>      @@ -74,7 +101,11 @@ static int pata_of_platform_probe(struct
>>>>
>>>>
>>>>
>>>>       static struct of_device_id pata_of_platform_match[] = {
>>>>
>>>>          { .compatible = "ata-generic", },
>>>>
>>>>      -   { },
>>>>
>>>>      +   { .compatible = "electra-ide", },
>>>>
>>>>      +#ifdef CONFIG_PPC_PASEMI_SB600
>>>>
>>>>      +       { .compatible = "electra-cf",},
>>>>
>>>>      +#endif
>>>>
>>>>      +   {},
>>>>
>>>>       };
>>>>
>>>>       MODULE_DEVICE_TABLE(of, pata_of_platform_match);
>>>>
>>>>
>>>>
>>>> dmesg with the kernel 4.7:
>>>>
>>>>
>>>>
>>>> zcat /var/log/dmesg.1.gz | grep -i ata7
>>>>
>>>>
>>>>
>>>>      [    2.939788] ata7: PATA max PIO0 no IRQ, using PIO polling mmio
>>>> cmd 0xf0000800 ctl 0xf000080e
>>>>
>>>>      [    3.099186] ata7.00: CFA: SanDisk SDCFB-256, HDX 2.33, max 
>>>> PIO4
>>>>
>>>>      [    3.099191] ata7.00: 501760 sectors, multi 0: LBA
>>>>
>>>>      [    3.099199] ata7.00: configured for PIO
>>>>
>>>>
>>>>
>>>> The dmesg of the latest Git kernel doesn't have any output of our
>>>> internal CF card device.
>>>>
>>>>
>>>>
>>>> Could you please integrate our PASEMI CF card device again?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> Christian
>>>>
>>>>
>>>>
>>>>> As for your driver support, it would indeed be a good idea to
>>>>> get it supported in the upstream kernel. You should post a
>>>>> new mail about that. Take a look at these 3 commits:
>>>>>
>>>>> 61f7162117d4767875825abf2f6ed1eeebbcceed
>>>>> 9cd55be4d22376893d2818ce3c0e5706a3d74121
>>>>> ca99140a63b7326ee9a38f64c326317f2c63b594
>>>>>
>>>>> Your patch comes from code based on the second one. The last
>>>>> commit removed it, and says that it is not the best way to
>>>>> implement it. You could cc this list and some of the people
>>>>> involved with those commits and ask ask for advice about
>>>>> getting your driver supported.
>>>> Actually, it's almost supported by the base PASemi code anyway, 
>>>> there is a
>>>> PCMCIA driver in setup.c, but our hardware has been changed enough 
>>>> to make it
>>>> hang the system when used. I should probably take another look and 
>>>> see If I
>>>> can fix that. The other option would be to move the above patch to 
>>>> where we
>>>> add our rtc platform device. One thing that does confuse me is the 
>>>> interrupt,
>>>> it's attached to GPIO 0, so should be on the mpic int 0 (or maybe 
>>>> 16?)but I
>>>> could never get it to work.
>>>>
>>>> Regards
>>>> Darren
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

Problem with the commit "console: don't prefer first registered if DT specifies stdout-path"

[Christian Zigotzky]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

Hello Paul,

After your commit "console: don't prefer first registered if DT 
specifies stdout-path" [1] we couldn't see any kernel boot messages 
anymore. I restored the old code and after that I was able to see the 
messages again.

System: Nemo board with P.A. Semi PA6T PowerPC CPU

I understand your idea of this patch but unfortunately it doesn't work 
with our system. There isn't a possibility to modify the DT.

We have created a patch for removing your commit but I hope you have a 
better idea.

Cheers,
Christian

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=05fd007e46296afb24d15c7d589d535e5a5b9d5c

[-- Attachment #2: console.patch --]
[-- Type: text/x-patch, Size: 1884 bytes --]

diff -rupN a/drivers/of/base.c b/drivers/of/base.c
--- a/drivers/of/base.c	2016-10-29 22:52:02.000000000 +0200
+++ b/drivers/of/base.c	2016-11-04 11:59:07.049568281 +0100
@@ -2077,8 +2077,6 @@ void of_alias_scan(void * (*dt_alloc)(u6
 			name = of_get_property(of_aliases, "stdout", NULL);
 		if (name)
 			of_stdout = of_find_node_opts_by_path(name, &of_stdout_options);
-		if (of_stdout)
-			console_set_by_of();
 	}
 
 	if (!of_aliases)
diff -rupN a/include/linux/console.h b/include/linux/console.h
--- a/include/linux/console.h	2016-10-29 22:52:02.000000000 +0200
+++ b/include/linux/console.h	2016-11-04 12:00:22.808701652 +0100
@@ -173,12 +173,6 @@ static inline void console_sysfs_notify(
 #endif
 extern bool console_suspend_enabled;
 
-#ifdef CONFIG_OF
-extern void console_set_by_of(void);
-#else
-static inline void console_set_by_of(void) {}
-#endif
-
 /* Suspend and resume console messages over PM events */
 extern void suspend_console(void);
 extern void resume_console(void);
diff -rupN a/kernel/printk/printk.c b/kernel/printk/printk.c
--- a/kernel/printk/printk.c	2016-10-29 22:52:02.000000000 +0200
+++ b/kernel/printk/printk.c	2016-11-04 12:04:36.083094450 +0100
@@ -253,17 +253,6 @@ static int preferred_console = -1;
 int console_set_on_cmdline;
 EXPORT_SYMBOL(console_set_on_cmdline);
 
-#ifdef CONFIG_OF
-static bool of_specified_console;
-
-void console_set_by_of(void)
-{
-	of_specified_console = true;
-}
-#else
-# define of_specified_console false
-#endif
-
 /* Flag: console code may call schedule() */
 static int console_may_schedule;
 
@@ -2657,7 +2646,7 @@ void register_console(struct console *ne
 	 *	didn't select a console we take the first one
 	 *	that registers here.
 	 */
-	if (preferred_console < 0 && !of_specified_console) {
+	if (preferred_console < 0) {
 		if (newcon->index < 0)
 			newcon->index = 0;
 		if (newcon->setup == NULL ||

Re: Problem with the commit "console: don't prefer first registered if DT specifies stdout-path"

[Aaro Koskinen]

On Sat, Nov 05, 2016 at 04:11:11PM +0100, Christian Zigotzky wrote:
> After your commit "console: don't prefer first registered if DT specifies
> stdout-path" [1] we couldn't see any kernel boot messages anymore. I
> restored the old code and after that I was able to see the messages again.
> 
> System: Nemo board with P.A. Semi PA6T PowerPC CPU
> 
> I understand your idea of this patch but unfortunately it doesn't work with
> our system. There isn't a possibility to modify the DT.

I faced the same issue today with PowerBook G4.

/sys/firmware/devicetree/base/chosen # hexdump -C linux,stdout-path
00000000  2f 70 63 69 40 66 30 30  30 30 30 30 30 2f 4e 56  |/pci@f0000000/NV|
00000010  44 41 2c 50 61 72 65 6e  74 40 31 30 2f 4e 56 44  |DA,Parent@10/NVD|
00000020  41 2c 44 69 73 70 6c 61  79 2d 41 40 30 00        |A,Display-A@0.|
0000002e

# dmesg|grep -i console
[    0.000000] bootconsole [udbg0] enabled
[    0.000774] Console: colour dummy device 80x25
[    2.288125] Console: switching to colour frame buffer device 128x48
[    4.318611] Warning: unable to open an initial console.

A workaround seems to be explicitly pass console=tty0 on the kernel
command line...

A.

> We have created a patch for removing your commit but I hope you have a
> better idea.
> 
> Cheers,
> Christian
> 
> [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=05fd007e46296afb24d15c7d589d535e5a5b9d5c

> diff -rupN a/drivers/of/base.c b/drivers/of/base.c
> --- a/drivers/of/base.c	2016-10-29 22:52:02.000000000 +0200
> +++ b/drivers/of/base.c	2016-11-04 11:59:07.049568281 +0100
> @@ -2077,8 +2077,6 @@ void of_alias_scan(void * (*dt_alloc)(u6
>  			name = of_get_property(of_aliases, "stdout", NULL);
>  		if (name)
>  			of_stdout = of_find_node_opts_by_path(name, &of_stdout_options);
> -		if (of_stdout)
> -			console_set_by_of();
>  	}
>  
>  	if (!of_aliases)
> diff -rupN a/include/linux/console.h b/include/linux/console.h
> --- a/include/linux/console.h	2016-10-29 22:52:02.000000000 +0200
> +++ b/include/linux/console.h	2016-11-04 12:00:22.808701652 +0100
> @@ -173,12 +173,6 @@ static inline void console_sysfs_notify(
>  #endif
>  extern bool console_suspend_enabled;
>  
> -#ifdef CONFIG_OF
> -extern void console_set_by_of(void);
> -#else
> -static inline void console_set_by_of(void) {}
> -#endif
> -
>  /* Suspend and resume console messages over PM events */
>  extern void suspend_console(void);
>  extern void resume_console(void);
> diff -rupN a/kernel/printk/printk.c b/kernel/printk/printk.c
> --- a/kernel/printk/printk.c	2016-10-29 22:52:02.000000000 +0200
> +++ b/kernel/printk/printk.c	2016-11-04 12:04:36.083094450 +0100
> @@ -253,17 +253,6 @@ static int preferred_console = -1;
>  int console_set_on_cmdline;
>  EXPORT_SYMBOL(console_set_on_cmdline);
>  
> -#ifdef CONFIG_OF
> -static bool of_specified_console;
> -
> -void console_set_by_of(void)
> -{
> -	of_specified_console = true;
> -}
> -#else
> -# define of_specified_console false
> -#endif
> -
>  /* Flag: console code may call schedule() */
>  static int console_may_schedule;
>  
> @@ -2657,7 +2646,7 @@ void register_console(struct console *ne
>  	 *	didn't select a console we take the first one
>  	 *	that registers here.
>  	 */
> -	if (preferred_console < 0 && !of_specified_console) {
> +	if (preferred_console < 0) {
>  		if (newcon->index < 0)
>  			newcon->index = 0;
>  		if (newcon->setup == NULL ||

P.A. Semi: "PR" KVM configure error after KVM changes for 4.12

[Christian Zigotzky]

Hi All,

After the first batch of KVM changes for 4.12 merge window I get the 
following error message if I want to configure the Linux kernel with KVM 
PR support on my P.A. Semi board.

warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct 
dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))

Did you change the system requirements for KVM? Does it only work on IBM 
pSeries machines now?

Before the changes, I successfully compiled the Git version of kernel 
4.12 with KVM PR support. I successfully tested it with Mac-on-Linux/KVM PR.

Cheers,

Christian

P.A. Semi: "PR" KVM configure error after KVM changes for 4.12

[Christian Zigotzky]

Hi All,

After the first batch of KVM changes for 4.12 merge window I get the 
following error message if I want to configure the Linux kernel with KVM 
PR support on my P.A. Semi board.

warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct 
dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))

Did you change the system requirements for KVM? Does it only work on IBM 
pSeries machines now?

Before the changes, I successfully compiled the Git version of kernel 
4.12 with KVM PR support. I successfully tested it with Mac-on-Linux/KVM PR.

Cheers,

Christian

Re: P.A. Semi: "PR" KVM configure error after KVM changes for 4.12

[Paul Mackerras]

On Tue, May 09, 2017 at 10:42:51AM +0200, Christian Zigotzky wrote:
> Hi All,
> 
> After the first batch of KVM changes for 4.12 merge window I get the
> following error message if I want to configure the Linux kernel with KVM PR
> support on my P.A. Semi board.
> 
> warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct
> dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))
> 
> Did you change the system requirements for KVM? Does it only work on IBM
> pSeries machines now?

That probably came in with Alexey Kardashevskiy's patches to
accelerate the TCE (IOMMU) hypercalls.  There was no deliberate
intention to restrict PR KVM to IBM machines.  I'll fix it.

However, I expect that at least for now we will not support PCI
pass-through on machines other than IBM pSeries, because the KVM vfio
code needs some specific services from the iommu layer which are
platform-dependent and probably not implemented on other platforms
(maple, pasemi, powermac).  If you have been using PCI pass-through
successfully in the past with PR KVM then please let me know and we'll
look at what is needed to keep it working.

Paul.

Re: P.A. Semi: "PR" KVM configure error after KVM changes for 4.12

[Paul Mackerras]

On Tue, May 09, 2017 at 10:42:51AM +0200, Christian Zigotzky wrote:
> Hi All,
> 
> After the first batch of KVM changes for 4.12 merge window I get the
> following error message if I want to configure the Linux kernel with KVM PR
> support on my P.A. Semi board.
> 
> warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct
> dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))
> 
> Did you change the system requirements for KVM? Does it only work on IBM
> pSeries machines now?

That probably came in with Alexey Kardashevskiy's patches to
accelerate the TCE (IOMMU) hypercalls.  There was no deliberate
intention to restrict PR KVM to IBM machines.  I'll fix it.

However, I expect that at least for now we will not support PCI
pass-through on machines other than IBM pSeries, because the KVM vfio
code needs some specific services from the iommu layer which are
platform-dependent and probably not implemented on other platforms
(maple, pasemi, powermac).  If you have been using PCI pass-through
successfully in the past with PR KVM then please let me know and we'll
look at what is needed to keep it working.

Paul.

Re: P.A. Semi: "PR" KVM configure error after KVM changes for 4.12

[Christian Zigotzky]

On 09 May 2017 at 11:08 AM, Paul Mackerras wrote:
> On Tue, May 09, 2017 at 10:42:51AM +0200, Christian Zigotzky wrote:
>> Hi All,
>>
>> After the first batch of KVM changes for 4.12 merge window I get the
>> following error message if I want to configure the Linux kernel with KVM PR
>> support on my P.A. Semi board.
>>
>> warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct
>> dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))
>>
>> Did you change the system requirements for KVM? Does it only work on IBM
>> pSeries machines now?
> That probably came in with Alexey Kardashevskiy's patches to
> accelerate the TCE (IOMMU) hypercalls.  There was no deliberate
> intention to restrict PR KVM to IBM machines.  I'll fix it.
>
> However, I expect that at least for now we will not support PCI
> pass-through on machines other than IBM pSeries, because the KVM vfio
> code needs some specific services from the iommu layer which are
> platform-dependent and probably not implemented on other platforms
> (maple, pasemi, powermac).  If you have been using PCI pass-through
> successfully in the past with PR KVM then please let me know and we'll
> look at what is needed to keep it working.
>
> Paul.
>
Hi Paul,

Thanks a lot for your fast reply. I had to select POWERNV as well 
because without it, the kernel didn't compile. After that I tested 
Mac-on-Linux/KVM PR with the new kernel. It works without any problems.

Screenshot: https://plus.google.com/115515624056477014971/posts/fVrEXs3S3dU

It would be nice if you could fix it.

Thanks,

Christian

Re: P.A. Semi: "PR" KVM configure error after KVM changes for 4.12

[Christian Zigotzky]

On 09 May 2017 at 11:08 AM, Paul Mackerras wrote:
> On Tue, May 09, 2017 at 10:42:51AM +0200, Christian Zigotzky wrote:
>> Hi All,
>>
>> After the first batch of KVM changes for 4.12 merge window I get the
>> following error message if I want to configure the Linux kernel with KVM PR
>> support on my P.A. Semi board.
>>
>> warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct
>> dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))
>>
>> Did you change the system requirements for KVM? Does it only work on IBM
>> pSeries machines now?
> That probably came in with Alexey Kardashevskiy's patches to
> accelerate the TCE (IOMMU) hypercalls.  There was no deliberate
> intention to restrict PR KVM to IBM machines.  I'll fix it.
>
> However, I expect that at least for now we will not support PCI
> pass-through on machines other than IBM pSeries, because the KVM vfio
> code needs some specific services from the iommu layer which are
> platform-dependent and probably not implemented on other platforms
> (maple, pasemi, powermac).  If you have been using PCI pass-through
> successfully in the past with PR KVM then please let me know and we'll
> look at what is needed to keep it working.
>
> Paul.
>
Hi Paul,

Thanks a lot for your fast reply. I had to select POWERNV as well 
because without it, the kernel didn't compile. After that I tested 
Mac-on-Linux/KVM PR with the new kernel. It works without any problems.

Screenshot: https://plus.google.com/115515624056477014971/posts/fVrEXs3S3dU

It would be nice if you could fix it.

Thanks,

Christian