commit 9178ba294b6839eeff1a91bed95515d783f3ee6c an A-Eon Tabor Board

[Julian Margetson]

On 3/16/2016 7:56 AM, Julian Margetson wrote:
> On 2/3/2016 6:59 PM, Alexander Graf wrote:
>>
>>
>> On 02/03/2016 11:54 PM, Julian Margetson wrote:
>>> On 2/3/2016 6:20 PM, Alexander Graf wrote:
>>>>
>>>>
>>>> On 02/03/2016 11:15 PM, Julian Margetson wrote:
>>>>> On 2/3/2016 4:43 PM, Alexander Graf wrote:
>>>>>>
>>>>>>
>>>>>> On 02/03/2016 10:33 AM, Julian Margetson wrote:
>>>>>>> Resending as it was attached to and old thread relating to a 
>>>>>>> different motherboard.
>>>>>>>
>>>>>>> On 2/2/2016 9:54 AM, Julian Margetson wrote:
>>>>>>>>
>>>>>>>> Commit 9178ba294b6839eeff1a91bed95515d783f3ee6c prevents 
>>>>>>>> building of kernel 4.1 branch on A-Eon Tabor Board.
>>>>>>>>
>>>>>>>> CC arch/powerpc/math-emu/fsqrt.o
>>>>>>>> arch/powerpc/platforms/85xx/tabor.c:194:2: error: unknown field 
>>>>>>>> ‘power_off’ specified in initializer
>>>>>>
>>>>>> I can't seem to find that file in Linux upstream?
>>>>>>
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> It may have been discontinued as the patches used were maintained 
>>>>> along with patches for the (Varisys)  A-Eon Cyrus board
>>>>> which is officially supported from kernel 4.4.
>>>>>
>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c383ee84e1d575b09d167185d15df24bde25eb15 
>>>>>
>>>>
>>>> I don't quite understand how an internal API change in Linux 
>>>> breaking random external patches is a bug? Either your code is 
>>>> upstream or it can break on every git commit done upstream.
>>>>
>>>>
>>>> Alex
>>>>
>>>>
>>>>
>>>
>>> Sorry I am relatively new at this.
>>> If I manage to pinpoint a problem on my powerpc machines I report it 
>>> . Most of them so far have indeed been bugs.
>>> The random external patches were done by person with far greater 
>>> competence than me who are no longer in the picture.
>>> Any  guidance would be greatly  appreciated.
>>
>> I think the most important step really is to upstream board support, 
>> otherwise things will continue to fall apart for sure.
>>
>> As for the exact breakage you saw, just remove the line and put a 
>> line like
>>
>>   pm_power_off = tabor_power_off;
>>
>> in your board probe function in tabor.c.
>>
>>
>> Alex
>>
>>
>>
>
> Could not get it to work with the
>  pm_power_off = tabor_power_off;
>
>
> so resorted to the option below and it builds and boots (Tested Kernel 
> 4.5.0).
> shuts down but no power off.
> Can live with that for now.
>
>
> Thanks for your help .
>
>
> Regards
> Julian
>
>
> define_machine(tabor) {
> .name= "Tabor",
> .probe= tabor_probe,
> .setup_arch= tabor_setup_arch,
> .init_IRQ= tabor_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus= fsl_pcibios_fixup_bus,
> .pcibios_fixup_phb= fsl_pcibios_fixup_phb,
> #endif
> .get_irq= mpic_get_irq,
> .restart= fsl_rstcr_restart,
> .calibrate_decr= generic_calibrate_decr,
> .progress= udbg_progress,
> };
>

Revisited and got  everything working  .
Thanks again.

Regards
Julian

static void tabor_power_off(void)
{
local_irq_disable();
if (power_gpio)
/* set mcu control register */
out_be32(power_gpio, in_be32(power_gpio) & 0xefff7fff); /* MCU Power Off */
else
printk(KERN_ERR "Power control not available\n");
while (1) ;

pm_power_off = tabor_power_off;

}


define_machine(tabor) {
.name= "Tabor",
.probe= tabor_probe,
.setup_arch= tabor_setup_arch,
.init_IRQ= tabor_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus= fsl_pcibios_fixup_bus,
.pcibios_fixup_phb= fsl_pcibios_fixup_phb,
#endif
.restart= tabor_restart,
.halt= tabor_power_off,
.get_irq= mpic_get_irq,
.restart= fsl_rstcr_restart,
.calibrate_decr= generic_calibrate_decr,
.progress= udbg_progress,
};



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20160316/4492e187/attachment-0001.html>