Re:

Re:

[Alex Vallens]

If you have a PowerBook G3 Series (Wallstreet), simply hold the
cmd-opt-o-f keys on startup (before the chime) and the computer will
automatically boot into OF.

Alex


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re:

[Benjamin Herrenschmidt]

On Thu, 2007-04-12 at 10:44 -0500, Milton Miller wrote:
> Matt sealey wrote:
> 
> +               if (cb & 0x5) { /* if controller is configured for 
> pci-native mode for both channels */
> 
> The above expression allows 1, 4, or 5 for the masked bits.  I'm 
> guessing you
> wanted to test that equal to either 5 or 0.

I think the proper test is ((cb & 5) == 5) but I can't remember for
sure.. 

Ben.

Re: Re:

[Segher Boessenkool]

>> +               if (cb & 0x5) { /* if controller is configured for
>> pci-native mode for both channels */
>>
>> The above expression allows 1, 4, or 5 for the masked bits.  I'm
>> guessing you
>> wanted to test that equal to either 5 or 0.
>
> I think the proper test is ((cb & 5) == 5) but I can't remember for
> sure..

That is correct if you know for sure the controller
actually supports native mode, and doesn't have that
support turned off by some configuration setting;
otherwise, the test should be ((cb & 0xf) == 0xf).


Segher

Re:

[Sergei Shtylyov]

Hello.

Segher Boessenkool wrote:
>>>+               if (cb & 0x5) { /* if controller is configured for
>>>pci-native mode for both channels */

>>>The above expression allows 1, 4, or 5 for the masked bits.  I'm
>>>guessing you
>>>wanted to test that equal to either 5 or 0.

>>I think the proper test is ((cb & 5) == 5) but I can't remember for
>>sure..
 
> That is correct if you know for sure the controller
> actually supports native mode, and doesn't have that
> support turned off by some configuration setting;
> otherwise, the test should be ((cb & 0xf) == 0xf).

   "I protest your honor". :-)
   Bits 1 and 3 only indicate that bits 0 and 2 are writeable.
 
MBR, Sergei

Re: Re:

[Segher Boessenkool]

>>> I think the proper test is ((cb & 5) == 5) but I can't remember for
>>> sure..
>> That is correct if you know for sure the controller
>> actually supports native mode, and doesn't have that
>> support turned off by some configuration setting;
>> otherwise, the test should be ((cb & 0xf) == 0xf).
>
>   "I protest your honor". :-)
>   Bits 1 and 3 only indicate that bits 0 and 2 are writeable.

Darn you're right.  Sorry for the confusion.


Segher

RE:

[Scott Coulter]

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

Check your UART  interrupt setup

 






___________________________________________________________________ 

  Scott N. Coulter 
  Senior Software Engineer 
  
  Cyclone Microsystems          
  370 James Street              Phone:  203.786.5536 ext. 118 
  New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com 
  U.S.A.                        Web:    http://www.cyclone.com 
___________________________________________________________________ 

________________________________

From: linuxppc-embedded-bounces+scott.coulter=cyclone.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+scott.coulter=cyclone.com@ozlabs.org]
On Behalf Of Mead, Joseph
Sent: Friday, April 27, 2007 3:16 PM
To: linuxppc-embedded@ozlabs.org
Subject: 

 

Hi, 

I'm trying to use initramfs on an ML403 system but don't understand why
I can't see any console output after the line: 

[    1.034361] Freeing unused kernel memory: 1172k init  

 

my filesystem is built from the following: 

dir /dev 755 0 0 
nod /dev/console 644 0 0 c 5 1 
dir /proc 755 0 0 
dir /sys 755 0 0 
file /init usr/busybox 755 0 0 

 

Busybox was built statically, with init functionality so I think I can
just rename it to init and it should run the init process.   It seems to
find /dev/console because if I delete that node I get an error message
that it can't find /dev/console.   Also I think it is finding the
busybox init because I don't get a kernel panic like I do when I don't
include it.

Any help would be great. 

Thanks,
Joe 

 

Kernel boot-up messages. 

loaded at:     00400000 005E613C                                
board data at: 005E4124 005E413C                                
relocated to:  004050D0 004050E8                                
zimage at:     004057E9 005E3869                                
avail ram:     005E7000 04000000                                

Linux/PPC load: console=ttyS0,9600                                  
Uncompressing Linux...done.                           
Now booting the kernel                      
[    0.000000] Linux version 2.6.17.1 (root@ansto1) (gcc version 3.4.5)
#29 Thu Apr 27 11:13:26 EDT 2007                        

[    0.000000] Xilinx ML403 Reference System (Virtex-4 FX)

[    0.000000] Built 1 zonelists                                
[    0.000000] Kernel command line: console=ttyS0,9600

[    0.000000] Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000


[    0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)


[    0.000105] Console: colour dummy device 80x25

[    0.000394] Dentry cache hash table entries: 8192 (order: 3, 32768
bytes)


[    0.000887] Inode-cache hash table entries: 4096 (order: 2, 16384
bytes)


[    0.009214] Memory: 61964k available (1292k kernel code, 468k data,
1172k init, 0k highmem)              
[    0.096238] Mount-cache hash table entries: 512

[    0.435539] NET: Registered protocol family 16

[    0.440315] NET: Registered protocol family 2

[    0.480121] IP route cache hash table entries: 512 (order: -1, 2048
bytes)


[    0.480636] TCP established hash table entries: 2048 (order: 1, 8192
bytes)


[    0.480755] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)


[    0.480821] TCP: Hash tables configure

[    0.480843] TCP reno registered                                  
[    0.484696] io scheduler noop registered

[    0.484754] io scheduler anticipatory registered (default)


[    0.484799] io scheduler deadline registered

[    0.484890] io scheduler cfq registered

[    0.510230] Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ
sharing disabled        
[    0.511764] serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 9) is a
16550A


[    0.924578] RAMDISK driver initialized: 16 RAM disks of 65536K size
1024 blocksize     
[    0.948301] tun: Universal TUN                                
[    0.963483] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>


[    0.982713] mice: PS/2 mouse device common for all mice

[    0.998445] TCP bic registered                                 
[    1.007702] NET: Registered protocol family 1

[    1.020827] NET: Registered protocol family 17

[    1.034361] Freeing unused kernel memory: 1172k init  


[-- Attachment #2: Type: text/html, Size: 25869 bytes --]

Re:

[Grant Likely]

On 11/1/07, Mead, Joseph <mead@bnl.gov> wrote:
>
>
>
>
> I am using a Xilinx ML403 board and created a custom IP that connects to =
the
> PLB bus.   The PLB bus is 64 bits wide.   To communicate with the custom =
IP
> I have been using iowrite32() and ioread32() function calls to grab 32 bi=
ts
> at a time.  Is it possible to grab the full 64 bits in one transfer?   I
> don't see an iowrite64() or ioread64() function=85

Not really, at least not for non-cachable regions.  The ppc405 is a 32
bit machine and if it is doing non-cached reads then it will do
individual 32 bit transactions.  You could enable cache on the region,
but if it is accessing device registers then that is probably not what
you want (because there is no cache coherency between your device and
the 405).

Cheers,
g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

RE:

[MingLiu]

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


Hi Joe,
I don't think you can do 64 bit transfer at once because ppc405 is a 32-bit CPU. So we have to the transfer in twice. 
 
BR
Ming


Date: Thu, 1 Nov 2007 14:18:07 -0400From: mead@bnl.govTo: linuxppc-embedded@ozlabs.orgSubject: 




I am using a Xilinx ML403 board and created a custom IP that connects to the PLB bus.   The PLB bus is 64 bits wide.   To communicate with the custom IP I have been using iowrite32() and ioread32() function calls to grab 32 bits at a time.  Is it possible to grab the full 64 bits in one transfer?   I don’t see an iowrite64() or ioread64() function…
 
Thanks,Joe 
 
 
_________________________________________________________________
用 Live Search 搜尽天下资讯！
http://www.live.com/?searchOnly=true

[-- Attachment #2: Type: text/html, Size: 2235 bytes --]

Re:

[rsa]

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

What?

[-- Attachment #2: Original Message.B64 --]
[-- Type: application/x-msdownload, Size: 134041 bytes --]

Re:

[Wolfgang Denk]

Dear Alexander,

In message <FCELKENEBBOLLHKPHCCBEECMCDAA.a.schmid@systeme-steuerungen.de> you wrote:
> 
> I use U-Boot 1.2.0 on MPC5200B. Console over serial works fine. I have a

U-Boot related questions are off topic here. Please post such
questions on the U-Boot mailing list, see
http://lists.denx.de/mailman/listinfo/u-boot

Second, U-Boot 1.2.0 is *very* old, please use recent code (1.3.4 or
later).

> Grafic controller at LPB Bus and U-Boot shows his console output at VGa too.
> But I would need a keyboard. I compiled U-Boot with USB and if i type "usb
> reset" the ohci controller scans the USB devices and finds a keyboard. But
> nothing happens if i push the buttons on the keyboard!

There is no USB keyboard driver in U-Boot yet. Please let me know if
you need help to develop one.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Time is fluid ... like a river with currents, eddies, backwash.
	-- Spock, "The City on the Edge of Forever", stardate 3134.0

Re:

[Benjamin Herrenschmidt]

On Thu, 2009-07-23 at 10:38 -0400, Solomon Peachy wrote:
> This patch (against 2.6.30) adds support for the ESTeem 195E Hotfoot
> SBC.  We've been maintaining this out-of-tree for some time now for
> older kernels, but recently I ported it to the new unified powerpc tree
> with the intent of pushing it upstream.

Please always have a subject or it will end up in patchwork without
a link I can clock on :-)

Cheersm
Ben.

> The board uses an ancient version of u-boot and a slightly mangled
> verison of the oft-abused ppcboot header.
> 
> There are several variants of the SBC deployed, single/dual
> ethernet/serial, and also 4MB/8MB flash units.  In the interest of
> having a single kernel image boot on all boards, the cuboot shim detects
> the differences and mangles the DTS tree appropriately.
> 
> With the exception of the CF interface that was never populated on
> production boards, this code/DTS supports all boardpop options.
> 
> Signed-off-by:  Solomon Peachy <solomon@linux-wlan.com>
> 
> diff -Naur linux-2.6.30/arch/powerpc/boot/Makefile linux-2.6.30.hotfoot/arch/powerpc/boot/Makefile
> --- linux-2.6.30/arch/powerpc/boot/Makefile	2009-06-09 23:05:27.000000000 -0400
> +++ linux-2.6.30.hotfoot/arch/powerpc/boot/Makefile	2009-07-07 12:55:18.000000000 -0400
> @@ -39,6 +39,7 @@
>  
>  $(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
>  $(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
> +$(obj)/cuboot-hotfoot.o: BOOTCFLAGS += -mcpu=405
>  $(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=405
>  $(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=405
>  $(obj)/cuboot-acadia.o: BOOTCFLAGS += -mcpu=405
> @@ -67,7 +68,7 @@
>  		cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
>  		fsl-soc.c mpc8xx.c pq2.c
>  src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c \
> -		cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
> +		cuboot-ebony.c cuboot-hotfoot.c treeboot-ebony.c prpmc2800.c \
>  		ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
>  		cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
>  		cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
> @@ -190,6 +191,7 @@
>  
>  # Board ports in arch/powerpc/platform/40x/Kconfig
>  image-$(CONFIG_EP405)			+= dtbImage.ep405
> +image-$(CONFIG_HOTFOOT)			+= cuImage.hotfoot
>  image-$(CONFIG_WALNUT)			+= treeImage.walnut
>  image-$(CONFIG_ACADIA)			+= cuImage.acadia
>  
> diff -Naur linux-2.6.30/arch/powerpc/boot/cuboot-hotfoot.c linux-2.6.30.hotfoot/arch/powerpc/boot/cuboot-hotfoot.c
> --- linux-2.6.30/arch/powerpc/boot/cuboot-hotfoot.c	1969-12-31 19:00:00.000000000 -0500
> +++ linux-2.6.30.hotfoot/arch/powerpc/boot/cuboot-hotfoot.c	2009-07-07 12:55:23.000000000 -0400
> @@ -0,0 +1,142 @@
> +/*
> + * Old U-boot compatibility for Esteem 195E Hotfoot CPU Board
> + *
> + * Author: Solomon Peachy <solomon@linux-wlan.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> + * by the Free Software Foundation.
> + */
> +
> +#include "ops.h"
> +#include "stdio.h"
> +#include "reg.h"
> +#include "dcr.h"
> +#include "4xx.h"
> +#include "cuboot.h"
> +
> +#define TARGET_4xx
> +#define TARGET_HOTFOOT
> +
> +#include "ppcboot.h"
> +
> +static bd_t bd;
> +
> +#define NUM_REGS 3
> +
> +static void hotfoot_fixups(void)
> +{
> +	u32 uart = mfdcr(DCRN_CPC0_UCR) & 0x7f;
> +
> +	dt_fixup_memory(bd.bi_memstart, bd.bi_memsize); 
> +
> +	dt_fixup_cpu_clocks(bd.bi_procfreq, bd.bi_procfreq, 0);
> +	dt_fixup_clock("/plb", bd.bi_plb_busfreq);
> +	dt_fixup_clock("/plb/opb", bd.bi_opbfreq);
> +	dt_fixup_clock("/plb/ebc", bd.bi_pci_busfreq);
> +	dt_fixup_clock("/plb/opb/serial@ef600300", bd.bi_procfreq / uart); 
> +	dt_fixup_clock("/plb/opb/serial@ef600400", bd.bi_procfreq / uart); 
> +	
> +	dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
> +	dt_fixup_mac_address_by_alias("ethernet1", bd.bi_enet1addr);
> +
> +	/* Is this a single eth/serial board? */
> +	if ((bd.bi_enet1addr[0] == 0) && 
> +	    (bd.bi_enet1addr[1] == 0) &&
> +	    (bd.bi_enet1addr[2] == 0) &&
> +	    (bd.bi_enet1addr[3] == 0) &&
> +	    (bd.bi_enet1addr[4] == 0) &&
> +	    (bd.bi_enet1addr[5] == 0)) {
> +		void *devp;
> +
> +		printf("Trimming devtree for single eth board\n");
> +
> +		devp = finddevice("/plb/opb/serial@ef600300");
> +		if (!devp)
> +			fatal("Can't find node for /plb/opb/serial@ef600300");
> +		del_node(devp);
> +
> +		devp = finddevice("/plb/opb/ethernet@ef600900");
> +		if (!devp)
> +			fatal("Can't find node for /plb/opb/ethernet@ef600900");
> +		del_node(devp);
> +	}
> +
> +	ibm4xx_quiesce_eth((u32 *)0xef600800, (u32 *)0xef600900);
> +
> +	/* Fix up flash size in fdt for 4M boards. */
> +	if (bd.bi_flashsize < 0x800000) {
> +		u32 regs[NUM_REGS];
> +		void *devp = finddevice("/plb/ebc/nor_flash@0");
> +		if (!devp)
> +			fatal("Can't find FDT node for nor_flash!??");
> +
> +		printf("Fixing devtree for 4M Flash\n");
> +		
> +		/* First fix up the base addresse */
> +		getprop(devp, "reg", regs, sizeof(regs));
> +		regs[0] = 0;
> +		regs[1] = 0xffc00000;
> +		regs[2] = 0x00400000;
> +		setprop(devp, "reg", regs, sizeof(regs));
> +		
> +		/* Then the offsets */
> +		devp = finddevice("/plb/ebc/nor_flash@0/partition@0");
> +		if (!devp)
> +			fatal("Can't find FDT node for partition@0");
> +		getprop(devp, "reg", regs, 2*sizeof(u32));
> +		regs[0] -= 0x400000;
> +		setprop(devp, "reg", regs,  2*sizeof(u32));
> +
> +		devp = finddevice("/plb/ebc/nor_flash@0/partition@1");
> +		if (!devp)
> +			fatal("Can't find FDT node for partition@1");
> +		getprop(devp, "reg", regs, 2*sizeof(u32));
> +		regs[0] -= 0x400000;
> +		setprop(devp, "reg", regs,  2*sizeof(u32));
> +
> +		devp = finddevice("/plb/ebc/nor_flash@0/partition@2");
> +		if (!devp)
> +			fatal("Can't find FDT node for partition@2");
> +		getprop(devp, "reg", regs, 2*sizeof(u32));
> +		regs[0] -= 0x400000;
> +		setprop(devp, "reg", regs,  2*sizeof(u32));
> +
> +		devp = finddevice("/plb/ebc/nor_flash@0/partition@3");
> +		if (!devp)
> +			fatal("Can't find FDT node for partition@3");
> +		getprop(devp, "reg", regs, 2*sizeof(u32));
> +		regs[0] -= 0x400000;
> +		setprop(devp, "reg", regs,  2*sizeof(u32));
> +
> +		devp = finddevice("/plb/ebc/nor_flash@0/partition@4");
> +		if (!devp)
> +			fatal("Can't find FDT node for partition@4");
> +		getprop(devp, "reg", regs, 2*sizeof(u32));
> +		regs[0] -= 0x400000;
> +		setprop(devp, "reg", regs,  2*sizeof(u32));
> +
> +		devp = finddevice("/plb/ebc/nor_flash@0/partition@6");
> +		if (!devp)
> +			fatal("Can't find FDT node for partition@6");
> +		getprop(devp, "reg", regs, 2*sizeof(u32));
> +		regs[0] -= 0x400000;
> +		setprop(devp, "reg", regs,  2*sizeof(u32));
> +
> +		/* Delete the FeatFS node */
> +		devp = finddevice("/plb/ebc/nor_flash@0/partition@5");
> +		if (!devp)
> +			fatal("Can't find FDT node for partition@5");
> +		del_node(devp);
> +	}
> +}
> +
> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> +		   unsigned long r6, unsigned long r7)
> +{
> +	CUBOOT_INIT();
> +	platform_ops.fixups = hotfoot_fixups;
> +        platform_ops.exit = ibm40x_dbcr_reset;
> +	fdt_init(_dtb_start);
> +	serial_console_init();
> +}
> diff -Naur linux-2.6.30/arch/powerpc/boot/dts/hotfoot.dts linux-2.6.30.hotfoot/arch/powerpc/boot/dts/hotfoot.dts
> --- linux-2.6.30/arch/powerpc/boot/dts/hotfoot.dts	1969-12-31 19:00:00.000000000 -0500
> +++ linux-2.6.30.hotfoot/arch/powerpc/boot/dts/hotfoot.dts	2009-07-07 12:55:23.000000000 -0400
> @@ -0,0 +1,299 @@
> +/*
> + * Device Tree Source for ESTeem 195E Hotfoot
> + *
> + * Copyright 2009 AbsoluteValue Systems <solomon@linux-wlan.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without
> + * any warranty of any kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +	model = "est,hotfoot";
> +	compatible = "est,hotfoot";
> +	dcr-parent = <&{/cpus/cpu@0}>;
> +
> +	aliases {
> +		ethernet0 = &EMAC0;
> +		ethernet1 = &EMAC1;
> +		serial0 = &UART0;
> +		serial1 = &UART1;
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			device_type = "cpu";
> +			model = "PowerPC,405EP";
> +			reg = <0x00000000>;
> +			clock-frequency = <0>; /* Filled in by zImage */
> +			timebase-frequency = <0>; /* Filled in by zImage */
> +			i-cache-line-size = <0x20>;
> +			d-cache-line-size = <0x20>;
> +			i-cache-size = <0x4000>;
> +			d-cache-size = <0x4000>;
> +			dcr-controller;
> +			dcr-access-method = "native";
> +		};
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x00000000>; /* Filled in by zImage */
> +	};
> +
> +	UIC0: interrupt-controller {
> +		compatible = "ibm,uic";
> +		interrupt-controller;
> +		cell-index = <0>;
> +		dcr-reg = <0x0c0 0x009>;
> +		#address-cells = <0>;
> +		#size-cells = <0>;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	plb {
> +		compatible = "ibm,plb3";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		clock-frequency = <0>; /* Filled in by zImage */
> +
> +		SDRAM0: memory-controller {
> +			compatible = "ibm,sdram-405ep";
> +			dcr-reg = <0x010 0x002>;
> +		};
> +
> +		MAL: mcmal {
> +			compatible = "ibm,mcmal-405ep", "ibm,mcmal";
> +			dcr-reg = <0x180 0x062>;
> +			num-tx-chans = <4>;
> +			num-rx-chans = <2>;
> +			interrupt-parent = <&UIC0>;
> +			interrupts = <
> +				0xb 0x4 /* TXEOB */
> +				0xc 0x4 /* RXEOB */
> +				0xa 0x4 /* SERR */
> +				0xd 0x4 /* TXDE */
> +				0xe 0x4 /* RXDE */>;
> +		};
> +
> +		POB0: opb {
> +			compatible = "ibm,opb-405ep", "ibm,opb";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			ranges = <0xef600000 0xef600000 0x00a00000>;
> +			dcr-reg = <0x0a0 0x005>;
> +			clock-frequency = <0>; /* Filled in by zImage */
> +
> +			/* Hotfoot has UART0/UART1 swapped */
> +
> +			UART0: serial@ef600400 {
> +				device_type = "serial";
> +				compatible = "ns16550";
> +				reg = <0xef600400 0x00000008>;
> +				virtual-reg = <0xef600400>;
> +				clock-frequency = <0>; /* Filled in by zImage */
> +				current-speed = <0x9600>;
> +				interrupt-parent = <&UIC0>;
> +				interrupts = <0x1 0x4>;
> +			};
> +
> +			UART1: serial@ef600300 {
> +				device_type = "serial";
> +				compatible = "ns16550";
> +				reg = <0xef600300 0x00000008>;
> +				virtual-reg = <0xef600300>;
> +				clock-frequency = <0>; /* Filled in by zImage */
> +				current-speed = <0x9600>;
> +				interrupt-parent = <&UIC0>;
> +				interrupts = <0x0 0x4>;
> +			};
> +
> +
> +			IIC: i2c@ef600500 {
> +				compatible = "ibm,iic-405ep", "ibm,iic";
> +				reg = <0xef600500 0x00000011>;
> +				interrupt-parent = <&UIC0>;
> +				interrupts = <0x2 0x4>;
> +
> +				rtc@68 {
> +				      /* Actually a DS1339 */
> +				      compatible = "dallas,ds1307"; 
> +				      reg = <0x68>;
> +				};
> +
> +				temp@4a { 
> +				      /* Not present on all boards */
> +				      compatible = "national,lm75";
> +				      reg = <0x4a>;
> +				};				
> +			};
> +
> +			GPIO: gpio@ef600700 {
> +			        #gpio-cells = <2>;
> +				compatible = "ibm,ppc4xx-gpio";
> +				reg = <0xef600700 0x00000020>;
> +				gpio-controller;
> +			};
> +
> +			gpio-leds {
> +			     compatible = "gpio-leds";
> +			     status {
> +			     	    label = "Status";
> +			     	    gpios = <&GPIO 1 0>;
> +				    /* linux,default=trigger = ".."; */
> +			     };
> +			     radiorx {
> +			     	    label = "Rx";
> +			     	    gpios = <&GPIO 0xe 0>;
> +				    /* linux,default=trigger = ".."; */
> +			     };
> +			};
> +
> +
> +			EMAC0: ethernet@ef600800 {
> +				linux,network-index = <0x0>;
> +				device_type = "network";
> +				compatible = "ibm,emac-405ep", "ibm,emac";
> +				interrupt-parent = <&UIC0>;
> +				interrupts = <
> +					0xf 0x4 /* Ethernet */
> +					0x9 0x4 /* Ethernet Wake Up */>;
> +				local-mac-address = [000000000000]; /* Filled in by zImage */
> +				reg = <0xef600800 0x00000070>;
> +				mal-device = <&MAL>;
> +				mal-tx-channel = <0>;
> +				mal-rx-channel = <0>;
> +				cell-index = <0>;
> +				max-frame-size = <0x5dc>;
> +				rx-fifo-size = <0x1000>;
> +				tx-fifo-size = <0x800>;
> +				phy-mode = "mii";
> +				phy-map = <0x00000000>;
> +			};
> +
> +			EMAC1: ethernet@ef600900 {
> +				linux,network-index = <0x1>;
> +				device_type = "network";
> +				compatible = "ibm,emac-405ep", "ibm,emac";
> +				interrupt-parent = <&UIC0>;
> +				interrupts = <
> +					0x11 0x4 /* Ethernet */
> +					0x9 0x4 /* Ethernet Wake Up */>;
> +				local-mac-address = [000000000000]; /* Filled in by zImage */
> +				reg = <0xef600900 0x00000070>;
> +				mal-device = <&MAL>;
> +				mal-tx-channel = <2>;
> +				mal-rx-channel = <1>;
> +				cell-index = <1>;
> +				max-frame-size = <0x5dc>;
> +				rx-fifo-size = <0x1000>;
> +				tx-fifo-size = <0x800>;
> +                                mdio-device = <&EMAC0>;
> +				phy-mode = "mii";
> +				phy-map = <0x0000001>;
> +			};
> +		};
> +
> +		EBC0: ebc {
> +			compatible = "ibm,ebc-405ep", "ibm,ebc";
> +			dcr-reg = <0x012 0x002>;
> +			#address-cells = <2>;
> +			#size-cells = <1>;
> +
> +			/* The ranges property is supplied by the bootwrapper
> +			 * and is based on the firmware's configuration of the
> +			 * EBC bridge
> +			 */
> +			clock-frequency = <0>; /* Filled in by zImage */
> +
> +                        nor_flash@0 {
> +                                compatible = "cfi-flash";
> +                                bank-width = <2>;
> +                                reg = <0x0 0xff800000 0x00800000>;
> +                                #address-cells = <1>;
> +                                #size-cells = <1>;
> +
> +				/* This mapping is for the 8M flash
> +				   4M flash has all ofssets -= 4M,
> +				   and FeatFS partition is not present */
> +				
> +                                partition@0 {
> +                                        label = "Bootloader";
> +                                        reg = <0x7c0000 0x40000>;
> +                                        /* read-only; */
> +                                };
> +                                partition@1 {
> +                                        label = "Env_and_Config_Primary";
> +                                        reg = <0x400000 0x10000>;
> +                                };
> +                                partition@2 {
> +                                        label = "Kernel";
> +                                        reg = <0x420000 0x100000>;
> +                                };
> +                                partition@3 {
> +                                        label = "Filesystem";
> +                                        reg = <0x520000 0x2a0000>;
> +                                };
> +                                partition@4 {
> +                                        label = "Env_and_Config_Secondary";
> +                                        reg = <0x410000 0x10000>;
> +                                };
> +                                partition@5 {
> +                                        label = "FeatFS";
> +                                        reg = <0x000000 0x400000>;
> +                                };
> +                                partition@6 {
> +                                        label = "Bootloader_Env";
> +                                        reg = <0x7d0000 0x10000>;
> +                                };
> +			};
> +		};
> +
> +                PCI0: pci@ec000000 {
> +                        device_type = "pci";
> +                        #interrupt-cells = <1>;
> +                        #size-cells = <2>;
> +                        #address-cells = <3>;
> +                        compatible = "ibm,plb405ep-pci", "ibm,plb-pci";
> +                        primary;
> +                        reg = <0xeec00000 0x00000008    /* Config space access */
> +                               0xeed80000 0x00000004    /* IACK */
> +                               0xeed80000 0x00000004    /* Special cycle */
> +                               0xef480000 0x00000040>;  /* Internal registers */
> +
> +                        /* Outbound ranges, one memory and one IO,
> +                         * later cannot be changed. Chip supports a second
> +                         * IO range but we don't use it for now
> +                         */
> +                        ranges = <0x02000000 0x00000000 0x80000000 0x80000000 0x00000000 0x20000000
> +                                  0x01000000 0x00000000 0x00000000 0xe8000000 0x00000000 0x00010000>;
> +
> +                        /* Inbound 2GB range starting at 0 */
> +                        dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x80000000>;
> +
> +			interrupt-parent = <&UIC0>;
> +                        interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> +                        interrupt-map = <
> +                                /* IDSEL 3 -- slot1 (optional) 27/29 A/B IRQ2/4 */
> +                                0x1800 0x0 0x0 0x1 &UIC0 0x1b 0x8
> +                                0x1800 0x0 0x0 0x2 &UIC0 0x1d 0x8
> +
> +                                /* IDSEL 4 -- slot0, 26/28 A/B IRQ1/3 */
> +                                0x2000 0x0 0x0 0x1 &UIC0 0x1a 0x8
> +                                0x2000 0x0 0x0 0x2 &UIC0 0x1c 0x8
> +                        >;
> +                };
> +	};
> +
> +	chosen {
> +		linux,stdout-path = &UART0;
> +	};
> +};
> diff -Naur linux-2.6.30/arch/powerpc/boot/ppcboot.h linux-2.6.30.hotfoot/arch/powerpc/boot/ppcboot.h
> --- linux-2.6.30/arch/powerpc/boot/ppcboot.h	2009-06-09 23:05:27.000000000 -0400
> +++ linux-2.6.30.hotfoot/arch/powerpc/boot/ppcboot.h	2009-07-07 12:55:18.000000000 -0400
> @@ -52,6 +52,11 @@
>  	unsigned long	bi_bootflags;	/* boot / reboot flag (for LynxOS) */
>  	unsigned long	bi_ip_addr;	/* IP Address */
>  	unsigned char	bi_enetaddr[6];	/* Ethernet address */
> +#if defined(TARGET_HOTFOOT)
> +	/* second onboard ethernet port */
> +	unsigned char	bi_enet1addr[6];
> +#define HAVE_ENET1ADDR
> +#endif /* TARGET_HOOTFOOT */
>  	unsigned short	bi_ethspeed;	/* Ethernet speed in Mbps */
>  	unsigned long	bi_intfreq;	/* Internal Freq, in MHz */
>  	unsigned long	bi_busfreq;	/* Bus Freq, in MHz */
> @@ -74,6 +79,9 @@
>  	unsigned int	bi_pci_busfreq;	/* PCI Bus speed, in Hz */
>  	unsigned char	bi_pci_enetaddr[6];	/* PCI Ethernet MAC address */
>  #endif
> +#if defined(TARGET_HOTFOOT)
> +	unsigned int     bi_pllouta_freq;       /* PLL OUTA speed, in Hz */
> +#endif
>  #if defined(TARGET_HYMOD)
>  	hymod_conf_t	bi_hymod_conf;	/* hymod configuration information */
>  #endif
> @@ -94,6 +102,10 @@
>  	unsigned char	bi_enet3addr[6];
>  #define HAVE_ENET3ADDR
>  #endif
> +#if defined(TARGET_HOTFOOT)
> +        int             bi_phynum[2];           /* Determines phy mapping */
> +        int             bi_phymode[2];          /* Determines phy mode */
> +#endif
>  #if defined(TARGET_4xx)
>  	unsigned int	bi_opbfreq;		/* OB clock in Hz */
>  	int		bi_iic_fast[2];		/* Use fast i2c mode */
> diff -Naur linux-2.6.30/arch/powerpc/platforms/40x/Kconfig linux-2.6.30.hotfoot/arch/powerpc/platforms/40x/Kconfig
> --- linux-2.6.30/arch/powerpc/platforms/40x/Kconfig	2009-06-09 23:05:27.000000000 -0400
> +++ linux-2.6.30.hotfoot/arch/powerpc/platforms/40x/Kconfig	2009-07-07 12:55:18.000000000 -0400
> @@ -40,6 +40,16 @@
>  	help
>  	  This option enables support for the Nestal Maschinen HCU4 board.
>  
> +config HOTFOOT
> +        bool "Hotfoot"
> +	depends on 40x
> +	default n
> +	select 405EP
> +	select PPC40x_SIMPLE
> +	select PCI
> +        help
> +	 This option enables support for the ESTEEM 195E Hotfoot board.
> +
>  config KILAUEA
>  	bool "Kilauea"
>  	depends on 40x
> diff -Naur linux-2.6.30/arch/powerpc/platforms/40x/ppc40x_simple.c linux-2.6.30.hotfoot/arch/powerpc/platforms/40x/ppc40x_simple.c
> --- linux-2.6.30/arch/powerpc/platforms/40x/ppc40x_simple.c	2009-06-09 23:05:27.000000000 -0400
> +++ linux-2.6.30.hotfoot/arch/powerpc/platforms/40x/ppc40x_simple.c	2009-07-07 12:55:18.000000000 -0400
> @@ -51,7 +51,8 @@
>   * board.c file for it rather than adding it to this list.
>   */
>  static char *board[] __initdata = {
> -	"amcc,acadia"
> +	"amcc,acadia",
> +	"est,hotfoot"
>  };
>  
>  static int __init ppc40x_probe(void)
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

(no subject)

[Wolfgang Denk]

Dear Rupjyoti,

drivers/ata/sata_dwc_460ex.c fails to build in current mainline:

...
  CC      drivers/ata/sata_dwc_460ex.o
drivers/ata/sata_dwc_460ex.c:43:1: warning: "DRV_NAME" redefined
In file included from drivers/ata/sata_dwc_460ex.c:38:
drivers/ata/libata.h:31:1: warning: this is the location of the previous definition
drivers/ata/sata_dwc_460ex.c:44:1: warning: "DRV_VERSION" redefined
drivers/ata/libata.h:32:1: warning: this is the location of the previous definition
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_exec_command_by_tag':
drivers/ata/sata_dwc_460ex.c:1356: warning: passing argument 1 of 'ata_get_cmd_descript' makes integer from pointer without a cast
drivers/ata/sata_dwc_460ex.c: At top level:
drivers/ata/sata_dwc_460ex.c:1592: warning: 'struct of_device' declared inside parameter list
drivers/ata/sata_dwc_460ex.c:1592: warning: its scope is only this definition or declaration, which is probably not what you want
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_probe':
drivers/ata/sata_dwc_460ex.c:1607: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1614: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1616: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1622: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1628: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1630: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1646: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1650: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1652: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1658: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1660: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1667: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1676: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1678: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1691: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1693: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c: At top level:
drivers/ata/sata_dwc_460ex.c:1705: warning: 'struct of_device' declared inside parameter list
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_remove':
drivers/ata/sata_dwc_460ex.c:1707: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1720: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c: At top level:
drivers/ata/sata_dwc_460ex.c:1736: warning: initialization from incompatible pointer type
drivers/ata/sata_dwc_460ex.c:1737: warning: initialization from incompatible pointer type
make[2]: *** [drivers/ata/sata_dwc_460ex.o] Error 1

Do you have any hints how to fix that?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Few people do business well who do nothing else.
                                       -- Philip Earl of Chesterfield

Re:

[Stephen Rothwell]

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

Hi Wolfgang,

On Wed, 18 Aug 2010 22:56:46 +0200 Wolfgang Denk <wd@denx.de> wrote:
>
> drivers/ata/sata_dwc_460ex.c: At top level:
> drivers/ata/sata_dwc_460ex.c:1592: warning: 'struct of_device' declared inside parameter list
> drivers/ata/sata_dwc_460ex.c:1592: warning: its scope is only this definition or declaration, which is probably not what you want
> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_probe':
> drivers/ata/sata_dwc_460ex.c:1607: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1614: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1616: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1622: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1628: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1630: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1646: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1650: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1652: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1658: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1660: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1667: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1676: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1678: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1691: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1693: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c: At top level:
> drivers/ata/sata_dwc_460ex.c:1705: warning: 'struct of_device' declared inside parameter list
> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_remove':
> drivers/ata/sata_dwc_460ex.c:1707: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c:1720: error: dereferencing pointer to incomplete type
> drivers/ata/sata_dwc_460ex.c: At top level:
> drivers/ata/sata_dwc_460ex.c:1736: warning: initialization from incompatible pointer type
> drivers/ata/sata_dwc_460ex.c:1737: warning: initialization from incompatible pointer type

I think most of these (if not all) are fixed in Linus' tree today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re:

[Wolfgang Denk]

Dear Rupjyoti, Prodyut, Mark,

two weeks ago I wrote:

In message <20100818205646.57783157D71@gemini.denx.de> you wrote:
> 
> drivers/ata/sata_dwc_460ex.c fails to build in current mainline:
...
> Do you have any hints how to fix that?

Any comments or ideas how to fix this?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Time is an illusion perpetrated by the manufacturers of space.

RE:

[Rupjyoti Sarmah]

Hi Wolfgang,

Sorry that I did not have a chance to check it recently.

Regards,
Rup

-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Thursday, September 02, 2010 11:44 AM
To: Rupjyoti Sarmah; Prodyut Hazarika; Mark Miesfeld
Cc: linuxppc-dev@ozlabs.org
Subject: Re:

Dear Rupjyoti, Prodyut, Mark,

two weeks ago I wrote:

In message <20100818205646.57783157D71@gemini.denx.de> you wrote:
>
> drivers/ata/sata_dwc_460ex.c fails to build in current mainline:
...
> Do you have any hints how to fix that?

Any comments or ideas how to fix this?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Time is an illusion perpetrated by the manufacturers of space.

RE:

[Rupjyoti Sarmah]

Hi Wolfgang,

The current mainline 2.6.36-rc3 does not report any error while building
the SATA driver.

Regards,
Rup


-----Original Message-----
From: Rupjyoti Sarmah [mailto:rsarmah@apm.com]
Sent: Thursday, September 02, 2010 8:22 PM
To: 'Wolfgang Denk'
Cc: 'linuxppc-dev@ozlabs.org'; 'Prodyut Hazarika'; 'Mark Miesfeld'
Subject: RE:

Hi Wolfgang,

Sorry that I did not have a chance to check it recently.

Regards,
Rup

-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Thursday, September 02, 2010 11:44 AM
To: Rupjyoti Sarmah; Prodyut Hazarika; Mark Miesfeld
Cc: linuxppc-dev@ozlabs.org
Subject: Re:

Dear Rupjyoti, Prodyut, Mark,

two weeks ago I wrote:

In message <20100818205646.57783157D71@gemini.denx.de> you wrote:
>
> drivers/ata/sata_dwc_460ex.c fails to build in current mainline:
...
> Do you have any hints how to fix that?

Any comments or ideas how to fix this?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Time is an illusion perpetrated by the manufacturers of space.

Re: drivers/ata/sata_dwc_460ex.c fails to build

[Wolfgang Denk]

Dear Rupjyoti Sarmah,

In message <5205dc59ca0e0fd65e50d80eeff60d01@mail.gmail.com> you wrote:
> 
> The current mainline 2.6.36-rc3 does not report any error while building
> the SATA driver.

It reports a lot of warnings, though:

-> git describe
v2.6.36-rc3
In file included from drivers/ata/sata_dwc_460ex.c:38:
drivers/ata/libata.h:31:1: warning: this is the location of the previous definition
drivers/ata/sata_dwc_460ex.c:44:1: warning: "DRV_VERSION" redefined
drivers/ata/libata.h:32:1: warning: this is the location of the previous definition
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_exec_command_by_tag':
drivers/ata/sata_dwc_460ex.c:1356: warning: passing argument 1 of 'ata_get_cmd_descript' makes integer from pointer without a cast
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_qc_issue':
drivers/ata/sata_dwc_460ex.c:1476: warning: 'err' is used uninitialized in this function
drivers/ata/sata_dwc_460ex.c:1465: note: 'err' was declared here
drivers/scsi/constants.c: In function 'scsi_print_sense':
drivers/scsi/constants.c:1407: warning: zero-length printf format string
drivers/scsi/constants.c:1413: warning: zero-length printf format string
drivers/scsi/constants.c: In function 'scsi_print_result':
drivers/scsi/constants.c:1456: warning: zero-length printf format string
drivers/scsi/sd.c: In function 'sd_print_sense_hdr':
drivers/scsi/sd.c:2628: warning: zero-length printf format string
drivers/scsi/sd.c:2630: warning: zero-length printf format string
drivers/scsi/sd.c: In function 'sd_print_result':
drivers/scsi/sd.c:2636: warning: zero-length printf format string

And the ``'err' is used uninitialized'' warning is indeed a valid one.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is mind?  No matter.  What is matter?  Never mind.
                                      -- Thomas Hewitt Key, 1799-1875

Re:

[Michal Simek]

Nishanth Aravamudan wrote:
> Use set_dma_ops and remove now used-once oddly named temp pointer sd.
> 
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> Cc: benh@kernel.crashing.org
> Cc: linuxppc-dev@lists.ozlabs.org
> ---

Maybe I forget to write you that this patch is already applied.
http://git.monstr.eu/git/gitweb.cgi?p=linux-2.6-microblaze.git;a=commit;h=9a6df6cbfd903b6d9b4b1021f46d78601adfac77


Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

Re:

[Michal Simek]

Hi,

Nishanth Aravamudan wrote:
> Use set_dma_ops and remove now used-once oddly named temp pointer sd.
> 
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> Cc: benh@kernel.crashing.org
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
>  arch/microblaze/pci/pci-common.c |    6 ++----
>  1 files changed, 2 insertions(+), 4 deletions(-)

Is there any reason why you are sending me this patch again and again?
Please STOP doing this!
This patch was added to the mainline last week.

Regards,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

Re:

[Arnd Bergmann]

On Fri, Aug 30, 2019 at 10:30 PM Michal Suchanek <msuchanek@suse.de> wrote:
>
> Subject: [PATCH] powerpc: Add back __ARCH_WANT_SYS_LLSEEK macro
>
> This partially reverts commit caf6f9c8a326 ("asm-generic: Remove
> unneeded __ARCH_WANT_SYS_LLSEEK macro")
>
> When CONFIG_COMPAT is disabled on ppc64 the kernel does not build.
>
> There is resistance to both removing the llseek syscall from the 64bit
> syscall tables and building the llseek interface unconditionally.
>
> Link: https://lore.kernel.org/lkml/20190828151552.GA16855@infradead.org/
> Link: https://lore.kernel.org/lkml/20190829214319.498c7de2@naga/
>
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

Re:

[Thomas Gleixner]

On Wed, Apr 13 2022 at 15:11, Nicholas Piggin wrote:
> So we traced the problem down to possibly a misunderstanding between 
> decrementer clock event device and core code.
>
> The decrementer is only oneshot*ish*. It actually needs to either be 
> reprogrammed or shut down otherwise it just continues to cause 
> interrupts.

I always thought that PPC had sane timers. That's really disillusioning.

> Before commit 35de589cb879, it was sort of two-shot. The initial 
> interrupt at the programmed time would set its internal next_tb variable 
> to ~0 and call the ->event_handler(). If that did not set_next_event or 
> stop the timer, the interrupt will fire again immediately, notice 
> next_tb is ~0, and only then stop the decrementer interrupt.
>
> So that was already kind of ugly, this patch just turned it into a hang.
>
> The problem happens when the tick is stopped with an event still 
> pending, then tick_nohz_handler() is called, but it bails out because 
> tick_stopped == 1 so the device never gets programmed again, and so it 
> keeps firing.
>
> How to fix it? Before commit a7cba02deced, powerpc's decrementer was 
> really oneshot, but we would like to avoid doing that because it requires 
> additional programming of the hardware on each timer interrupt. We have 
> the ONESHOT_STOPPED state which seems to be just about what we want.
>
> Did the ONESHOT_STOPPED patch just miss this case, or is there a reason 
> we don't stop it here? This patch seems to fix the hang (not heavily
> tested though).

This was definitely overlooked, but it's arguable it is is not required
for real oneshot clockevent devices. This should only handle the case
where the interrupt was already pending.

The ONESHOT_STOPPED state was introduced to handle the case where the
last timer gets canceled, so the already programmed event does not fire.

It was not necessarily meant to "fix" clockevent devices which are
pretending to be ONESHOT, but keep firing over and over.

That, said. I'm fine with the change along with a big fat comment why
this is required.

Thanks,

        tglx

Re:

[Nicholas Piggin]

Excerpts from Thomas Gleixner's message of April 23, 2022 1:53 am:
> On Wed, Apr 13 2022 at 15:11, Nicholas Piggin wrote:
>> So we traced the problem down to possibly a misunderstanding between 
>> decrementer clock event device and core code.
>>
>> The decrementer is only oneshot*ish*. It actually needs to either be 
>> reprogrammed or shut down otherwise it just continues to cause 
>> interrupts.
> 
> I always thought that PPC had sane timers. That's really disillusioning.

My comment was probably a bit misleading explanation of the whole
situation. This weirdness is actually in software in the powerpc
clock event driver due to a recent change I made assuming the clock 
event goes to oneshot-stopped.

The hardware is relatively sane I think, global synchronized constant
rate high frequency clock distributed to the CPUs so reads don't
go off-core. And per-CPU "decrementer" event interrupt at the same
frequency as the clock -- program it to a +ve value and it decrements
until zero then creates basically a level triggered interrupt.

Before my change, the decrementer interrupt would always clear the
interrupt at entry. The event_handler usually programs another
timer in so I tried to avoid that first clear counting on the
oneshot_stopped callback to clear the interrupt if there was no
other timer.

>> Before commit 35de589cb879, it was sort of two-shot. The initial 
>> interrupt at the programmed time would set its internal next_tb variable 
>> to ~0 and call the ->event_handler(). If that did not set_next_event or 
>> stop the timer, the interrupt will fire again immediately, notice 
>> next_tb is ~0, and only then stop the decrementer interrupt.
>>
>> So that was already kind of ugly, this patch just turned it into a hang.
>>
>> The problem happens when the tick is stopped with an event still 
>> pending, then tick_nohz_handler() is called, but it bails out because 
>> tick_stopped == 1 so the device never gets programmed again, and so it 
>> keeps firing.
>>
>> How to fix it? Before commit a7cba02deced, powerpc's decrementer was 
>> really oneshot, but we would like to avoid doing that because it requires 
>> additional programming of the hardware on each timer interrupt. We have 
>> the ONESHOT_STOPPED state which seems to be just about what we want.
>>
>> Did the ONESHOT_STOPPED patch just miss this case, or is there a reason 
>> we don't stop it here? This patch seems to fix the hang (not heavily
>> tested though).
> 
> This was definitely overlooked, but it's arguable it is is not required
> for real oneshot clockevent devices. This should only handle the case
> where the interrupt was already pending.
> 
> The ONESHOT_STOPPED state was introduced to handle the case where the
> last timer gets canceled, so the already programmed event does not fire.
> 
> It was not necessarily meant to "fix" clockevent devices which are
> pretending to be ONESHOT, but keep firing over and over.
> 
> That, said. I'm fine with the change along with a big fat comment why
> this is required.

Thanks for taking a look and confirming. I just sent a patch with a
comment and what looks like another missed case. Hopefully it's okay.

Thanks,
Nick