LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: minor progress with plb_temac v3.00a, EDK 8.2, & 2.6.18.1
From: robert corley @ 2006-11-07 18:37 UTC (permalink / raw)
  To: Pradeep Sampath; +Cc: linux linuxppc-embedded

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

Pradeep;

I found the process of "uprading" the xapp902 reference design to be troublesome when I removed the GMII loop-back; as
such, I aborted the process and just started from scratch.

I am currently debugging my design and have a functional plb_temac but only at 10Mbps speeds.

-R. Corley

----- Original Message ----
From: Pradeep Sampath <pradeepsampath@yahoo.com>
To: David H. Lynch Jr. <dhlii@dlasys.net>; robert corley <rdcorle@yahoo.com>
Cc: linux linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Sent: Tuesday, November 7, 2006 1:05:08 PM
Subject: Re: minor progress with plb_temac v3.00a, EDK 8.2, & 2.6.18.1

Hello,
   
  I was able to get the booting with a ramdisk working and also  David B./Peter's uartlite patches to work. Now I see the linux command line without any kernel panics. Thanks to everybody out there.
   
  Next step is to get the PLB TEMAC 3.00.a working...
   
  Question 1: I have started with the xapp902 reference design. I replaced the existing plb_temac_0 and hard_temac_0 instances with the plb_temac_0 (version 3.00.a) and hard_temac_0 (version 3.00.b). When I "generate libraries and BSP" I get the following error.
  
ERROR:MDT - intc () - Internal error: Number of interrupt inputs on opb_intc_0
   (1) is not the same as length of total number of interrupt sources (2). If
   any interrupt source is a vector then libgen does not support this use case
       while
 executing
   "error "Internal error: Number of interrupt inputs on $periph_name
   ($num_intr_inputs) is not the same as length of total number of interrupt.....
  .....
   ARG: C_PHY_TYPE VALUE: 1
ERROR:MDT - Error while running "generate" for processor ppc405_0...
   
  Or is it better to generate the EDK design from start rather than using the reference design?
   
  Question 2: For the adapter.c for TEMAC, I am using the C:\EDK\sw\ThirdParty\bsp\linux_2_6_v1_00_a\drivers\temac_linux_2_6_v2_00_b\src\adapter.c as indicated by Rick Moleres. Can I use it as is or it requires further tweaking? If yes, then what are the changes.
   
  Question 3: Are the files under linux\arch\ppc\platforms\xilinx_ocp required? I thought the files in ../drivers/xilinx_edk => should take care of all the dma stuff?

  Could someone provide
 some insight into all these questions?
  -Pradeep
  

"David H. Lynch Jr." <dhlii@dlasys.net> wrote:
  robert corley wrote:           Pradeep;

Booting with a ramdisk is a matter of putting the appropriate image in the arch/ppc/boot/images directory (I obtained mine from the gsrd design files), adding the root=/dev/ram rw on the command-line boot options, making the .config changes for ram disk support and initrd usage, and issuing a make zImage.initrd command.

Beware when upgrading to 2.6.18.1 as
 you may have difficulties with the adapter.c you obtained previously.  The adapter.c in EDK 8.2 is not as easy to find.  Using the EDK to generate software components for linux will not expose the proper adapter.c.  I had to use the path that Rick Moleres posted earlier to retrieve the adapter.c which I used for 2.6.18.1 and in my notes.

-cy



    I am booting with a ramdisk using initramfs. Aside from its being somewhat harder to find documentation I beleive it is actually easier.
    
    In the simplest form, create a directory on your host that contains exactly what you want on the ramdisk.
    Enable CONFIG_INITRAMFS
    and point the CONFIG_INITRAMFS_SOURCE  to that directory.

    It is pretty much that simple. The linux build process creates a kernel - I use zImage.elf that has the ramdisk compressed
 and concatentated.
    Nothing except the Linux kernel itself has to make any accomidations for the ramdisk. The bootloader does not have to deal with another file, or pass pointers to it to Linux, ....
    It took some time to get it working - mostly because I did nto know what I was doing, but in hindsight it is really easy.



        ----- Original Message ----
From: Pradeep Sampath <pradeepsampath@yahoo.com>
To: robert corley <rdcorle@yahoo.com>
Sent: Thursday, November 2, 2006 7:57:25 PM
Subject: Re: minor progress with plb_temac v3.00a, EDK 8.2, & 2.6.18.1

  This is great! I played around for a while with the Sysace CF driver patches and got it to work. Since you are booting with ramdisk image would you be kind enough to add more text on how to do that? I see that you are using UART Lite? Does it require any special setting for the boot logs to show up on the standard hyperterminal. 
   
  I am planning on rebuilding the whole system using EDK 8.2 and linux kernel 2.6.18.1.
   
  -Pradeep

robert corley <rdcorle@yahoo.com> wrote:
  For those interested, I have
 acheived some measure of success with the plb_temac driver.

I have attached a txt file of what I had to do to get it working under 2.6.18.1

I am using the plb_temac in DMA mode 3

Below you will see the boot dump.

For those able to help, can anyone provide insight as to the failure of setting PHY link speed?

-cy



====================
----------------------------------------------------------------------
2.6.18.1 kernel with all patches
11/02/2006 15:30
plb_temac v3.00a
hard_temac v3.00b


loaded at: 00400000 009F1138
board data at: 009EF120 009EF138
relocated to: 004040B4 004040CC
zimage at: 00404EC7 0057C1F2
initrd at: 0057D000 009EE6FE
avail ram: 009F2000 04000000


Linux/PPC load: console=ttyUL0 single ip=192.168.1.100:192.168.1.144:192.168.1.1:255.255.255.0:nab:: ramdisk_size=4660000 root=/dev/ram rw

Uncompressing Linux...done.

Now booting the kernel

[
 0.000000] Linux version 2.6.18.1 (rdcorle@athena) (gcc version 3.4.2) #2 Thu Nov 2 21:56:32 UTC 2006
[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
[ 0.000000] Built 1 zonelists. Total pages: 16384
[ 0.000000] Kernel command line: console=ttyUL0 single ip=192.168.1.100:192.168.1.144:192.168.1.1:255.255.255.0:nab:: ramdisk_size=4660000 root=/dev/ram rw
[ 0.000000] Xilinx INTC #0 at 0xD1000FC0 mapped to 0xFDFFFFC0
[ 0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[ 0.000158] Console: colour dummy device 80x25
[ 0.000568] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.001277] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.012895] Memory: 57060k available (2548k kernel code, 640k data, 96k init, 0k highmem)
[ 0.104378] Mount-cache hash table entries: 512
[ 0.106721] checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
[ 2.414242] Freeing initrd memory:
 4549k freed
[ 2.418712] NET: Registered protocol family 16
[ 2.427313] NET: Registered protocol family 2
[ 2.464244] IP route cache hash table entries: 512 (order: -1, 2048 bytes)
[ 2.465037] TCP established hash table entries: 2048 (order: 1, 8192 bytes)
[ 2.465205] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[ 2.465296] TCP: Hash tables configured (established 2048 bind 1024)
[ 2.465324] TCP reno registered
[ 2.474633] NTFS driver 2.1.27 [Flags: R/O].
[ 2.475046] JFS: nTxBlock = 481, nTxLock = 3854
[ 2.477623] SGI XFS with no debug enabled
[ 2.479001] io scheduler noop registered
[ 2.479109] io scheduler anticipatory registered
[ 2.479197] io scheduler deadline registered
[ 2.479402] io scheduler cfq registered (default)
[ 2.517627] uartlite.0: ttyUL0 at MMIO 0xa0000000 (irq = 1) is a uartlite
[ 2.691029] RAMDISK driver initialized: 16 RAM disks of 4660000K size 1024 blocksize
[ 2.703933] loop: loaded (max 8
 devices)
[ 2.709698] XTemac: using sgDMA mode.
[ 2.713493] XTemac: using TxDRE mode
[ 2.717081] XTemac: using RxDRE mode
[ 2.720678] XTemac: buffer descriptor size: 32768 (0x8000)
[ 2.726622] XTemac: (buffer_descriptor_init) phy: 0x580000, virt: 0xff100000, size: 0x8000
[ 2.741073] eth0: Xilinx TEMAC #0 at 0x60000000 mapped to 0xC5050000, irq=0
[ 2.748080] eth0: XTemac id 1.0f, block id 5, type 8
[ 2.753636] mice: PS/2 mouse device common for all mice
[ 2.759529] TCP bic registered
[ 3.264317] eth0: XTemac: Options: 0xb8f2
[ 15.227339] eth0: XTemac: Not able to set the speed to 1000 (status: 0x148)
[ 25.200394] eth0: XTemac: Not able to set the speed to 100 (status: 0x148)
[ 35.173357] eth0: XTemac: Not able to set the speed to 10 (status: 0x148)
[ 35.180122] eth0: XTemac: could not negotiate speed
[ 35.187740] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
[ 35.194116] eth0: XTemac: Send Wait bound = 1, Receive
 Wait bound = 1
[ 36.205399] IP-Config: Complete:
[ 36.208459] device=eth0, addr=192.168.1.100, mask=255.255.255.0, gw=192.168.1.1,
[ 36.216339] host=nab, domain=, nis-domain=(none),
[ 36.221487] bootserver=192.168.1.144, rootserver=192.168.1.144, rootpath=
[ 36.229826] RAMDISK: Compressed image found at block 0
[ 37.200498] eth0: XTemac: PHY Link carrier lost.
[ 39.097820] VFS: Mounted root (ext2 filesystem).
[ 39.102751] Freeing unused kernel memory: 96k init
[ 39.108356] ulite_startup: UART status = 0x0014
[ 39.124619] ulite_startup: UART status = 0x0014
[ 39.134313] ulite_startup: UART status = 0x0014


BusyBox v1.00-pre9 (2004.04.18-19:53+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

-sh: can't access tty; job control turned off


steps for plb_temac drivers under EDK 8.2.02i (w/SP2.4+0)
Using plb_temac v3.00a & hard_temac v3.00b

Generate s/w libraries

1. copy
 or ftp the following files from C:\EDK\sw\ThirdParty\bsp\linux_2_6_v1_00_a\linux\
to the base directory of the linux source tree

USED:
arch\ppc\platforms\4xx\xparameters\xparameters.h

** UNUSED
arch\ppc\platforms\4xx\virtex.c
arch\ppc\boot\simple\embed_config.c
include\linux\xilinx_devices.h

2. copy C:\EDK\sw\ThirdParty\bsp\linux_2_6_v1_00_a\drivers\temac_linux_2_6_v2_00_b\src\adapter.c to
../drivers/net/xilinx_temac/adapter.c

3. copy or ftp ..\linux\arch\ppc\platforms\xilinx_ocp => drivers/xilinx_edk
Note: Remove all old files first *except* Kconfig, xio.h

4. modify drivers/xilinx_edk/Makefile with the following to look like this:

# Linux file to EXPORT_SYMBOL all of the Xilinx entries.
obj-$(CONFIG_XILINX_EDK) += xilinx_syms.o
#
# # The Xilinx OS independent code.
xilinx_syms-objs := xbasic_types.o \
xdmav3.o xdmav3_intr.o xdmav3_selftest.o xdmav3_simple.o xdmav3_sg.o \
xipif_v1_23_b.o
 \
xpacket_fifo_l_v2_00_a.o xpacket_fifo_v2_00_a.o \
xversion.o

5. Modify your copied xparameters_ml403.h (see notes below) as follows:
add these lines after #define XPAR_PLB_TEMAC_0_INCLUDE_RX_CSUM

#define XPAR_TEMAC_0_IPIF_RDFIFO_DEPTH XPAR_PLB_TEMAC_0_RXFIFO_DEPTH
#define XPAR_TEMAC_0_IPIF_WRFIFO_DEPTH XPAR_PLB_TEMAC_0_TXFIFO_DEPTH
#define XPAR_TEMAC_0_MAC_FIFO_DEPTH XPAR_PLB_TEMAC_0_MAC_FIFO_DEPTH
#define XPAR_TEMAC_0_TEMAC_DCR_HOST 0
#define XPAR_TEMAC_0_INCLUDE_DRE 1


6. (optional) modify arch/ppc/platforms/virtex.h to accomodate RX_CSUM XPAR

struct xtemac_platform_data {
#ifdef XPAR_TEMAC_0_INCLUDE_RX_CSUM
u8 tx_dre;
u8 rx_dre;
u8 tx_csum;
u8 rx_csum;
u8 phy_type;
#endif
u8 dma_mode;
u32 rx_pkt_fifo_depth;
u32 tx_pkt_fifo_depth;
u16 mac_fifo_depth;
u8 dcr_host;
u8 dre;
u8 mac_addr[6];
};

7. Modify ../drivers/net/xilinx_temac/adapter.c to remove #include and
add
 #include 
add #include 

____________________________________________________________________________________
NOTES:
1. Don't forget to copy EDK-generated xparameters.h to ../arch/ppc/platforms/4xx/xparameters/xparameters_ml403.h



=====================================================
Files in latest patch:
../drivers/net/xilinx_temac =
Makefile
adapter.c
xtemac.c
xtemac_control.c
xtemac_fifo.c
xtemac_intr.c
xtemac_intr_fifo.c
xtemac_intr_sgdma.c
xtemac_l.c
xtemac_sgdma.c
xtemac.h
xtemac_i.h
xtemac_l.h

Files in ..\linux\drivers\net\xilinx_temac => (** = new
 files)

Makefile
adapter.c
xtemac.c
xtemac_control.c
xtemac_fifo.c
xtemac_g.c**
xtemac_intr.c
xtemac_intr_fifo.c
xtemac_intr_sgdma.c
xtemac_l.c
xtemac_selftest.c**
xtemac_sgdma.c
xtemac_sinit.c**
xtemac_stats.c**
xtemac.h
xtemac_i.h
xtemac_l.h

============================================================
Files in ../drivers/xilinx_edk =>

Kconfig
Makefile
xbasic_types.c
xdmav2.c
xdmav2_intr.c
xdmav2_sg.c
xdmav2_simple.c
xilinx_syms.c
xpacket_fifo_l_v2_00_a.c
xpacket_fifo_v2_00_a.c
xbasic_types.h
xdmabdv2.h
xdmav2.h
xdmav2_l.h
xio.h
xpacket_fifo_l_v2_00_a.h
xpacket_fifo_v2_00_a.h
xstatus.h

Files in
 ..\linux\arch\ppc\platforms\xilinx_ocp=>
Makefile
xbasic_types.c
xutil_memtest.c
xpacket_fifo_v2_00_a.c
xdmav3.c
xpacket_fifo_l_v2_00_a.c
xdmav3_intr.c
xipif_v1_23_b.c
xdmav3_selftest.c
xdmav3_sg.c
xdmav3_simple.c
xversion.c
xenv.h
xenv_none.h
xenv_vxworks.h
xdmav3_l.h
xipif_v1_23_b.h
xdmav3.h
xpacket_fifo_l_v2_00_a.h
xdmabdv3.h
xpacket_fifo_v2_00_a.h
xparameters_ml300.h
xstatus.h
xutil.h
xbasic_types.h
xenv_linux.h
xversion.h
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded




 
 _______________________________________________  Linuxppc-embedded mailing list  Linuxppc-embedded@ozlabs.org  https://ozlabs.org/mailman/listinfo/linuxppc-embedded

--   Dave Lynch             DLA Systems  Software Development:               Embedded Linux  717.627.3770         dhlii@dlasys.net    http://www.dlasys.net  fax: 1.253.369.9244               Cell: 1.717.587.7774  Over 25 years' experience in platforms, languages, and technologies too numerous to list.    "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite
 direction."  Albert Einstein  




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

^ permalink raw reply

* Re: Has anyone 2.6 kernel with Xenomai and MPC5200 Lite running?
From: Matthias Fechner @ 2006-11-07 18:54 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20061105214824.8FD44353A5F@atlas.denx.de>

Hello Wolfgang,

* Wolfgang Denk <wd@denx.de> [05-11-06 22:48]:
> I'm not talking about a specific board, but about MPC5200 in general.

ah ok, thx for that hint. Maybe it will change in the future :)


Best regards,
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

^ permalink raw reply

* Re: [PATCH 1/1]  PPC32 : Huge-page support for ppc440
From: Roland Dreier @ 2006-11-07 18:55 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-embedded, Edi Shmueli, linuxppc-dev
In-Reply-To: <1162900338.19697.20.camel@crusty.rchland.ibm.com>

Is this 44x work at the point where having more people would help?  I
have a 440SPe eval board that I'd like to get going with
arch/powerpc.  I could work on PCI Express or something like that...

On the other hand, I'm happy to wait and work on other stuff...

 - R.

^ permalink raw reply

* Re: Has anyone 2.6 kernel with Xenomai and MPC5200 Lite running?
From: Matthias Fechner @ 2006-11-07 18:55 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20061107090012.GA17066@server.idefix.loc>

Hi,

* Matthias Fechner <idefix@fechner.net> [07-11-06 10:00]:
> You can find what I did on:
> http://wiki.idefix.fechner.net/index.php/Xenomai

ok, problem is solved, everything is documented on my page. Hope that
helps some ppl.
(was a problem with the kernel configuration)

Best regards,
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

^ permalink raw reply

* Re: [PATCH 2.6.19 2/4] ehca: hcp_phyp.c: correct page mapping in 64k page mode
From: Roland Dreier @ 2006-11-07 19:25 UTC (permalink / raw)
  To: Hoang-Nam Nguyen; +Cc: linuxppc-dev, linux-kernel, openib-general, raisch
In-Reply-To: <200611052141.29030.hnguyen@de.ibm.com>

 > -	*mapaddr = (u64)(ioremap(physaddr, EHCA_PAGESIZE));
 > +	*mapaddr = (u64)ioremap((physaddr & PAGE_MASK), PAGE_SIZE) +
 > +		(physaddr & (~PAGE_MASK));

I'm confused -- shouldn't ioremap() do the right thing even if
physaddr isn't page-aligned?  Why is this needed?

 - R.

^ permalink raw reply

* RE: Problem connecting a Ti TUSB2077a hub to Cypress SL811 host
From: Chaffin, Michael @ 2006-11-07 19:29 UTC (permalink / raw)
  To: gear, linuxppc-embedded

> -----Original Message-----
> From: gear [mailto:gear@XXX.XXX]=20
> Sent: Tuesday, November 07, 2006 10:43 AM
> To: Chaffin, Michael
> Subject: Re: Problem connecting a Ti TUSB2077a hub to Cypress=20
> SL811 host
>=20
> error -110 is time out.
>=20
> Is interrupt correctly treatable?

Which interrupt line? I am looking at the Ti Documentation (SLLS414A -
March 2000 Revised December 2004 ) and I do not see an 'interrupt' line?


Now the hub chip is /not/ powered via the host controller,
	Sl811 Pin 7 & 8 ( USB Data +/-) to TUSB pin 3 & 4=20
	TUSB pin 9 & 46 (Vcc and -Vcc) to 3.3 Volts

Should the second set of pins (9 & 46) be attached\controlled at the
power output of the host controller?
=20
> Tomoshige Hirohata
> hirohata@XXX.XX
=20

^ permalink raw reply

* Re: ethernet interface problem with kernel 2.6.14 on MPC8343E
From: Andy Fleming @ 2006-11-07 19:53 UTC (permalink / raw)
  To: Luong Ngo; +Cc: linuxppc-embedded
In-Reply-To: <1b2aacd80611061551t78cc4f1aoef66377e82c2daed@mail.gmail.com>


On Nov 6, 2006, at 17:51, Luong Ngo wrote:

> Hello,
>
> I am having a problem with the interfaces eth0 and eth1 when  
> running 2.6.14 kernel on a board with MPC8343E. The problem I  
> encounters is only one of the eth interface is really working. Only  
> the one that is configured first, using "ifconfig eth[0/1]  
> 192.168.1.1 netmask 255.255.255.0" can ping and be pinged from  
> another host. I wonder if there is setup difference between the  
> TSEC1 and TSEC2 or this is not related to hardware but rather  
> something in the kernel. When I ping from other host, from within  
> the Gianfar driver, I can see the packet is received on both  
> interfaces but only one responds. When pinging from the system  
> itself, only the working interface sending out packet, the other  
> interface does not send anything. Please advise me what I am doing  
> wrong or missing.
>

It sounds like both work for you, but not at the same time?

If you set them both to the same IP address, it won't work.   
Actually, it won't work if you set them to different IP addresses on  
the same subnet (as defined by their netmasks).

I think you are trying to get Linux to do something that it doesn't  
do.  Try setting them to different IP addresses, like 192.168.1.1 and  
192.168.2.1

Andy

^ permalink raw reply

* No RTC interrupt for PPC440EP board.
From: Leonid @ 2006-11-07 19:49 UTC (permalink / raw)
  To: linuxppc-embedded

Hi:

I have PPC440EP board, derived from AMCC Yosemite evaluation board. My
board has Dallas DS1743 NVRAM/RTC chip, connected to local bus (CS2). I
believe, I made necessary initializations for TODC structures (I had to
add CONFIG_GEN_RTC and CONFIG_GEN_RTC_X to my kernel configuration) - I
used bamboo board as an example. Initialization goes OK and I even can
access RTC via proc interface:

~ # cat /proc/driver/rtc
rtc_time        : -8:-1:-51
rtc_date        : 1970-01--14232
rtc_epoch       : 1900
alarm           : 00:00:00
DST_enable      : no
BCD             : yes
24hr            : yes
square_wave     : no
alarm_IRQ       : no
update_IRQ      : no
periodic_IRQ    : no
periodic_freq   : 0
batt_status     : okay

However when I'm using RTC test application, suggested by Paul Gortmaker
in Documentation/rtc.txt, it gets blocked on read operation:

~ # rtctest

                        RTC Driver Test Example.

Counting 5 update (1/sec) interrupts from reading /dev/rtc:

Looks like interrupts don't arrive from device so I don't think this
device by itself would generate any interrupts. Any ideas what I'm doing
wrong? May be this test application is obsolete and I should use another
one? Some missing definitions in my kernel config file?

Thanks,

Leonid.

^ permalink raw reply

* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Matthew Wilcox @ 2006-11-07 20:07 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Greg Kroah-Hartman, linuxppc-dev, Eric W.Biederman, linux-pci,
	David S.Miller
In-Reply-To: <20061107072125.68E9F67CA7@ozlabs.org>

On Tue, Nov 07, 2006 at 06:21:23PM +1100, Michael Ellerman wrote:
> We currently (ab)use the pci_dev to store our msi_info structure. We
> were hoping to stash it in the pci_dn, but that's not a goer, so the
> pci_dev seems like the right place, even though it seems naughty to
> bloat generic structs.

We have the per-irq void *chip_data; could this be the right place to
keep it instead?  That way, it won't take up space in the pci_dev for
devices which don't use MSI.

Or do you rely on mpic_from_irq() working for MSI interrupts too?

^ permalink raw reply

* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Russell King @ 2006-11-07 20:14 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Greg Kroah-Hartman, linuxppc-dev, Eric W.Biederman, linux-pci,
	David S.Miller
In-Reply-To: <20061107200730.GY27140@parisc-linux.org>

On Tue, Nov 07, 2006 at 01:07:30PM -0700, Matthew Wilcox wrote:
> On Tue, Nov 07, 2006 at 06:21:23PM +1100, Michael Ellerman wrote:
> > We currently (ab)use the pci_dev to store our msi_info structure. We
> > were hoping to stash it in the pci_dn, but that's not a goer, so the
> > pci_dev seems like the right place, even though it seems naughty to
> > bloat generic structs.
> 
> We have the per-irq void *chip_data; could this be the right place to
> keep it instead?  That way, it won't take up space in the pci_dev for
> devices which don't use MSI.

Bah.  chip_data is supposed to be __iomem.  I bet if you build ARM
with sparse it'll kick out lots of warnings as a result of that loss.

Grumble, generic irq, pah.  Grumble.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

^ permalink raw reply

* Re: [PATCH 23/31] powerpc: Cell "Spider" MMIO workarounds
From: Benjamin Herrenschmidt @ 2006-11-07 20:29 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20061107115541.GA32171@lst.de>

On Tue, 2006-11-07 at 12:55 +0100, Christoph Hellwig wrote:
> On Tue, Nov 07, 2006 at 06:22:57PM +1100, Benjamin Herrenschmidt wrote:
> > + * This driver adds basic cpufreq support for SMU & 970FX based G5 Macs,
> > + * that is iMac G5 and latest single CPU desktop.
> 
> This doesn't make any sense ;-)

Ooops :-) Yeah, I copy/pasted the boilerplate and it looks like I copied
a bit too much :-)

Ben

^ permalink raw reply

* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Benjamin Herrenschmidt @ 2006-11-07 20:39 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Greg Kroah-Hartman, linuxppc-dev, Eric W.Biederman, linux-pci,
	David S.Miller
In-Reply-To: <20061107200730.GY27140@parisc-linux.org>

On Tue, 2006-11-07 at 13:07 -0700, Matthew Wilcox wrote:
> On Tue, Nov 07, 2006 at 06:21:23PM +1100, Michael Ellerman wrote:
> > We currently (ab)use the pci_dev to store our msi_info structure. We
> > were hoping to stash it in the pci_dn, but that's not a goer, so the
> > pci_dev seems like the right place, even though it seems naughty to
> > bloat generic structs.
> 
> We have the per-irq void *chip_data; could this be the right place to
> keep it instead?  That way, it won't take up space in the pci_dev for
> devices which don't use MSI.
> 
> Or do you rely on mpic_from_irq() working for MSI interrupts too?

Yes, we rely on that.

The chip_data is for use by the IRQ controller. In our cases, for some
controllers at least, MSIs are just an add-on to an existing controller
(they toggle existing inputs).

In general, I think it just make sense to have pci_dev contain MSI
tracking data for the device though.

Cheers,
Ben.

^ permalink raw reply

* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Benjamin Herrenschmidt @ 2006-11-07 20:40 UTC (permalink / raw)
  To: Russell King
  Cc: Matthew Wilcox, Greg Kroah-Hartman, linuxppc-dev,
	Eric W.Biederman, linux-pci, David S.Miller
In-Reply-To: <20061107201436.GE9533@flint.arm.linux.org.uk>

On Tue, 2006-11-07 at 20:14 +0000, Russell King wrote:
> On Tue, Nov 07, 2006 at 01:07:30PM -0700, Matthew Wilcox wrote:
> > On Tue, Nov 07, 2006 at 06:21:23PM +1100, Michael Ellerman wrote:
> > > We currently (ab)use the pci_dev to store our msi_info structure. We
> > > were hoping to stash it in the pci_dn, but that's not a goer, so the
> > > pci_dev seems like the right place, even though it seems naughty to
> > > bloat generic structs.
> > 
> > We have the per-irq void *chip_data; could this be the right place to
> > keep it instead?  That way, it won't take up space in the pci_dev for
> > devices which don't use MSI.
> 
> Bah.  chip_data is supposed to be __iomem.  I bet if you build ARM
> with sparse it'll kick out lots of warnings as a result of that loss.
> 
> Grumble, generic irq, pah.  Grumble.

Oh well... on various cases, on ppc, I use it not as __iomem but as a
pointer to a irq controller "instance" (which itself contains the
__iomem pointer, along with a bunch of other things).

But yeah, you were there first ;)

Ben.

^ permalink raw reply

* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Matthew Wilcox @ 2006-11-07 20:44 UTC (permalink / raw)
  To: Russell King
  Cc: Greg Kroah-Hartman, Ingo Molnar, linuxppc-dev, Thomas Gleixner,
	Eric W.Biederman, linux-pci, David S.Miller
In-Reply-To: <20061107201436.GE9533@flint.arm.linux.org.uk>

On Tue, Nov 07, 2006 at 08:14:36PM +0000, Russell King wrote:
> On Tue, Nov 07, 2006 at 01:07:30PM -0700, Matthew Wilcox wrote:
> > We have the per-irq void *chip_data; could this be the right place to
> > keep it instead?  That way, it won't take up space in the pci_dev for
> > devices which don't use MSI.
> 
> Bah.  chip_data is supposed to be __iomem.  I bet if you build ARM
> with sparse it'll kick out lots of warnings as a result of that loss.

Erm, since when?  When I introduced it (back in January 2005 [1]), it
was called handler_data and pointed to a struct which is chip-type
dependent.  One of the items in that struct is an IO address, but we
need more than that.

Now we have something else called handler_data, and I must
admit to being quite confused what the difference is.  The comment in
the header files and the DocBook genericirq leave me quite confused.

[1] http://git.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commit;h=1dd15c35b6bc179cd9c2a47e13360052c1e938a3

^ permalink raw reply

* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Russell King @ 2006-11-07 20:48 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Greg Kroah-Hartman, Ingo Molnar, linuxppc-dev, Thomas Gleixner,
	Eric W.Biederman, linux-pci, David S.Miller
In-Reply-To: <20061107204432.GZ27140@parisc-linux.org>

On Tue, Nov 07, 2006 at 01:44:32PM -0700, Matthew Wilcox wrote:
> On Tue, Nov 07, 2006 at 08:14:36PM +0000, Russell King wrote:
> > On Tue, Nov 07, 2006 at 01:07:30PM -0700, Matthew Wilcox wrote:
> > > We have the per-irq void *chip_data; could this be the right place to
> > > keep it instead?  That way, it won't take up space in the pci_dev for
> > > devices which don't use MSI.
> > 
> > Bah.  chip_data is supposed to be __iomem.  I bet if you build ARM
> > with sparse it'll kick out lots of warnings as a result of that loss.
> 
> Erm, since when?  When I introduced it (back in January 2005 [1]), it
> was called handler_data and pointed to a struct which is chip-type
> dependent.

Since before the generic irq merge.  If I was more expert with git
I'd post a URL, but I'm not so I won't.  But I'm sure you can find
it - look at the history of include/asm-arm/mach/irq.h.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

^ permalink raw reply

* Re: [PATCH/RFC] powerpc: Add MPC5200 Interrupt Controller support.
From: Sylvain Munaut @ 2006-11-07 20:52 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev, sven, linuxppc-embedded
In-Reply-To: <528646bc0611070830u2d490d79v5843de918c54b05f@mail.gmail.com>

Grant Likely wrote:
> On 11/7/06, Sylvain Munaut <tnt@246tnt.com> wrote:
>> Nicolas DET wrote:
>>
>> > This patch add MPC52xx Interrupt controller for ARCH=powerpc.
>> >
>> > It includes the main code in arch/powerpc/sysdev/ ad well as an
>> header file in
>> > include/asm-powerpc.
>> >
>> > The header file has now distinct section for the struct and the IRQ
>> mapping/enconding define
>> >
>> > Signed-off-by: Nicolas DET <nd@bplan-gmbh.de>
>> Acked-by: Sylvain Munaut <tnt@246tNt.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
OOps ... sorry NAK ...

All your strings got screwed up ... all your \n got replaced by just n ...

And while your at it there is two extraneous whitespace, might be a good
time to get rid
of them. One in the comment header and one after a "size64".


    Sylvain

^ permalink raw reply

* Re: [PATCH] of_irq_to_resource now returns the virq
From: Andy Fleming @ 2006-11-07 20:56 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1162857862.28571.376.camel@localhost.localdomain>


On Nov 6, 2006, at 18:04, Benjamin Herrenschmidt wrote:

> On Mon, 2006-11-06 at 17:13 -0600, Andy Fleming wrote:
>> Mostly this is to allow for error checking (check the return for  
>> NO_IRQ)
>>
>> Signed-off-by: Andrew Fleming <afleming@freescale.com>
>> ---
>> For 2.6.20
>>
>>  include/asm-powerpc/prom.h |   13 ++++++++++---
>>  1 files changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
>> index 933ba27..e9226e3 100644
>> --- a/include/asm-powerpc/prom.h
>> +++ b/include/asm-powerpc/prom.h
>> @@ -334,10 +334,17 @@ extern int of_irq_map_one(struct device_
>>  struct pci_dev;
>>  extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq  
>> *out_irq);
>>
>> -static inline void of_irq_to_resource(struct device_node *dev,  
>> int index, struct resource *r)
>> +static inline int of_irq_to_resource(struct device_node *dev, int  
>> index, struct resource *r)
>>  {
>> -	r->start = r->end = irq_of_parse_and_map(dev, index);
>> -	r->flags = IORESOURCE_IRQ;
>> +	int irq = irq_of_parse_and_map(dev, index);
>> +
>> +	/* Only dereference the resource if the irq is valid. */
>> +	if (irq != NO_IRQ) {
>
> What about if (irq != NO_IRQ && r) ?

Yeah, that's a good idea.  The reason I didn't want to dereference r  
if the IRQ was invalid was originally because I wanted my gianfar  
setup code to do this:

	while (of_irq_to_resource(np, n_res, &r[++n_res]) != NO_IRQ);

That way, I didn't have to do bounds checking on the array, as long  
as I made sure that it could hold all the possible interrupts.  I  
eventually decided that was a bad idea (since I had to hard-code that  
anyway, but that of_irq_to_resource() might as well not fill in a  
resource if the IRQ is bad.  I'm about to submit the code that uses  
this function, but now it does bounds checking.

>
>> +		r->start = r->end = irq;
>> +		r->flags = IORESOURCE_IRQ;
>> +	}
>> +
>> +	return irq;
>>  }
>
> That way, if somebody doesn't care about the resource, just pass NULL,
> though I suppose we should then also change the name of the  
> function to
> something like of_map_one_irq() ..


Well, I think it would just be irq_of_parse_and_map(), then.  :)


>
> Ben.
>

^ permalink raw reply

* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Matthew Wilcox @ 2006-11-07 21:02 UTC (permalink / raw)
  To: Russell King
  Cc: Greg Kroah-Hartman, Ingo Molnar, linuxppc-dev, Thomas Gleixner,
	Eric W.Biederman, linux-pci, David S.Miller
In-Reply-To: <20061107204853.GF9533@flint.arm.linux.org.uk>

On Tue, Nov 07, 2006 at 08:48:53PM +0000, Russell King wrote:
> On Tue, Nov 07, 2006 at 01:44:32PM -0700, Matthew Wilcox wrote:
> > On Tue, Nov 07, 2006 at 08:14:36PM +0000, Russell King wrote:
> > > Bah.  chip_data is supposed to be __iomem.  I bet if you build ARM
> > > with sparse it'll kick out lots of warnings as a result of that loss.
> > 
> > Erm, since when?  When I introduced it (back in January 2005 [1]), it
> > was called handler_data and pointed to a struct which is chip-type
> > dependent.
> 
> Since before the generic irq merge.  If I was more expert with git
> I'd post a URL, but I'm not so I won't.  But I'm sure you can find
> it - look at the history of include/asm-arm/mach/irq.h.

OK.  Looks like the first mention of this is in 
4a2581a080098ca3a0c4e416d7a282e96c75ebf8 from July 2006
which is signed-off by you, Ingo Molnar and Thomas Gleixner:

-       void __iomem    *base;
[...]
+#define set_irq_chipdata(irq, d)       set_irq_chip_data(irq, d)
+#define get_irq_chipdata(irq)          get_irq_chip_data(irq)
-#define set_irq_chipdata(irq,d)                        do { irq_desc[irq].base = d; } while (0)
-#define get_irq_chipdata(irq)                  (irq_desc[irq].base)

Now, true, the __iomem has disappeared.  But there was never an __iomem
on chip_data, nor on the handler_data before it.  It went away back in
July when you signed off on the conversion to use the generic irq
handler, and apparently haven't noticed the problem since then, so I
don't see it as being a big problem.

As other architectures, you could embed the iomem pointer in a
struct (would it be useful to you to have more than an iomem pointer
in your handlers?), or you could put the cast adding __iomem in
get_irq_chipdata().

^ permalink raw reply

* [PATCH] PowerPC: clockevents and HRT support
From: Sergei Shtylyov @ 2006-11-07 21:05 UTC (permalink / raw)
  To: tglx; +Cc: linuxppc-dev, greg.weeks

Add PowerPC decrementer clock event driver and enable HRT.
Every effort has been made to support the different implementations of the
decrementer: the classic one (with 970 series variation), 40x and Book E
specific ones.

I had to make CONFIG_GENERIC_CLOCKEVENTS option selectable for the
compatibility reasons -- this option is not compatible with the PPC64
deterministic time accounting.

Thanks to Daniel Walker and Thomas Gleixner for suggestions they made...

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>

---
This patch has been reworked against 2.6.18-hrt-dyntick2 patchset and
tested on the classic and Book E 32-bit CPUs.

CONFIG_PPC_MULTIPLATFORM was the best option I was able to come up with
to cover machines built on 970 series CPU...

 arch/powerpc/Kconfig       |   13 ++++
 arch/powerpc/kernel/time.c |  121 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 133 insertions(+), 1 deletion(-)

Index: linux-2.6/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/Kconfig
+++ linux-2.6/arch/powerpc/Kconfig
@@ -281,7 +281,7 @@ config PPC_STD_MMU_32
 
 config VIRT_CPU_ACCOUNTING
 	bool "Deterministic task and CPU time accounting"
-	depends on PPC64
+	depends on PPC64 && !GENERIC_CLOCKEVENTS
 	default y
 	help
 	  Select this option to enable more accurate task and CPU time
@@ -599,6 +599,17 @@ config HIGHMEM
 	depends on PPC32
 
 source kernel/Kconfig.hz
+
+config GENERIC_CLOCKEVENTS
+	bool "Clock event devices support"
+	default n
+	help
+	  Enable support for the clock event devices necessary for the
+	  high-resolution timers and the tickless system support.
+	  NOTE: This is not compatible with the deterministic time accounting
+	  option on PPC64.
+
+source kernel/time/Kconfig
 source kernel/Kconfig.preempt
 source "fs/Kconfig.binfmt"
 
Index: linux-2.6/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/time.c
+++ linux-2.6/arch/powerpc/kernel/time.c
@@ -51,6 +51,7 @@
 #include <linux/rtc.h>
 #include <linux/jiffies.h>
 #include <linux/posix-timers.h>
+#include <linux/clockchips.h>
 
 #include <asm/io.h>
 #include <asm/processor.h>
@@ -124,6 +125,80 @@ unsigned long ppc_tb_freq;
 static u64 tb_last_jiffy __cacheline_aligned_in_smp;
 static DEFINE_PER_CPU(u64, last_jiffy);
 
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+#define DECREMENTER_MAX 0xffffffff
+#else
+#define DECREMENTER_MAX 0x7fffffff /* setting MSB triggers an interrupt */
+#endif
+
+struct decrementer_device {
+       struct clock_event_device device;
+       int mode;
+};
+
+static void decrementer_set_next_event(unsigned long evt,
+				       struct clock_event_device *dev)
+{
+#if defined(CONFIG_40x)
+	mtspr(SPRN_PIT, evt);	/* 40x has a hidden PIT auto-reload register */
+#elif defined(CONFIG_BOOKE)
+	mtspr(SPRN_DECAR, evt); /* Book E  has separate auto-reload register */
+	set_dec(evt);
+#else
+	set_dec(evt - 1);	/* Classic decrementer interrupts at -1 */
+#endif
+}
+
+static void decrementer_set_mode(enum	clock_event_mode mode,
+				 struct clock_event_device *dev)
+{
+	struct decrementer_device *decrementer;
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+	u32 tcr = mfspr(SPRN_TCR);
+
+	if (mode == CLOCK_EVT_PERIODIC)
+		tcr |=  TCR_ARE;
+	else
+		tcr &= ~TCR_ARE;
+
+	mtspr(SPRN_TCR, tcr);
+#endif
+	decrementer = container_of(dev, struct decrementer_device, device);
+	decrementer->mode = mode;
+
+	if (mode == CLOCK_EVT_PERIODIC)
+		decrementer_set_next_event(tb_ticks_per_jiffy, dev);
+}
+
+static struct clock_event_device decrementer_template = {
+	.name		= "decrementer",
+	.capabilities	= CLOCK_CAP_PROFILE | CLOCK_CAP_UPDATE |
+			  CLOCK_CAP_NEXTEVT,
+	.shift		= 32,
+	.set_mode	= decrementer_set_mode,
+	.set_next_event	= decrementer_set_next_event,
+};
+
+static DEFINE_PER_CPU(struct decrementer_device, decrementers);
+
+static void register_decrementer(void)
+{
+	int cpu = smp_processor_id();
+	struct decrementer_device *decrementer = &per_cpu(decrementers, cpu);
+
+	decrementer->device = decrementer_template;
+
+	/* We only want do_timer() to be called on a boot CPU. */
+	if (cpu == boot_cpuid) 
+		decrementer->device.capabilities |= CLOCK_CAP_TICK;
+
+	register_local_clockevent(&decrementer->device);
+}
+
+#endif /* CONFIG_GENERIC_CLOCKEVENTS */
+
 #ifdef CONFIG_VIRT_CPU_ACCOUNTING
 /*
  * Factors for converting from cputime_t (timebase ticks) to
@@ -340,6 +415,9 @@ void snapshot_timebase(void)
 {
 	__get_cpu_var(last_jiffy) = get_tb();
 	snapshot_purr();
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+	register_decrementer();
+#endif
 }
 
 void __delay(unsigned long loops)
@@ -495,7 +573,28 @@ void timer_interrupt(struct pt_regs * re
 
 	irq_enter();
 
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+#ifdef CONFIG_PPC_MULTIPLATFORM
+	/*
+	 * We must write a positive value to the decrementer to clear
+	 * the interrupt on the IBM 970 CPU series.  In periodic mode,
+	 * this happens when the decrementer gets reloaded later, but
+	 * in one-shot mode, we have to do it here since an event handler
+	 * may skip loading the new value...
+	 */
+	if (per_cpu(decrementers, cpu).mode != CLOCK_EVT_PERIODIC)
+		set_dec(DECREMENTER_MAX);
+#endif
+	/*
+	 * We can't disable the decrementer, so in the period between
+	 * CPU being marked offline and calling stop-self, it's taking
+	 * timer interrupts...
+	 */
+	if (!cpu_is_offline(cpu))
+		per_cpu(decrementers, cpu).device.event_handler(regs);
+#else
 	profile_tick(CPU_PROFILING, regs);
+#endif
 	calculate_steal_time();
 
 #ifdef CONFIG_PPC_ISERIES
@@ -510,6 +609,7 @@ void timer_interrupt(struct pt_regs * re
 		if (__USE_RTC() && per_cpu(last_jiffy, cpu) >= 1000000000)
 			per_cpu(last_jiffy, cpu) -= 1000000000;
 
+#ifndef CONFIG_GENERIC_CLOCKEVENTS
 		/*
 		 * We cannot disable the decrementer, so in the period
 		 * between this cpu's being marked offline in cpu_online_map
@@ -519,6 +619,7 @@ void timer_interrupt(struct pt_regs * re
 		 */
 		if (!cpu_is_offline(cpu))
 			account_process_time(regs);
+#endif
 
 		/*
 		 * No need to check whether cpu is offline here; boot_cpuid
@@ -531,14 +632,23 @@ void timer_interrupt(struct pt_regs * re
 		tb_next_jiffy = tb_last_jiffy + tb_ticks_per_jiffy;
 		if (per_cpu(last_jiffy, cpu) >= tb_next_jiffy) {
 			tb_last_jiffy = tb_next_jiffy;
+#ifndef CONFIG_GENERIC_CLOCKEVENTS
 			do_timer(1);
+#endif
 			timer_check_rtc();
 		}
 		write_sequnlock(&xtime_lock);
 	}
 	
 	next_dec = tb_ticks_per_jiffy - ticks;
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+#if !defined(CONFIG_40x) && !defined(CONFIG_BOOKE)
+	if (per_cpu(decrementers, cpu).mode == CLOCK_EVT_PERIODIC)
+		set_dec(next_dec - 1);
+#endif
+#else
 	set_dec(next_dec);
+#endif
 
 #ifdef CONFIG_PPC_ISERIES
 	if (hvlpevent_is_pending())
@@ -787,8 +897,19 @@ void __init time_init(void)
 	tb_to_ns_scale = scale;
 	tb_to_ns_shift = shift;
 
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+	decrementer_template.mult = div_sc(ppc_tb_freq, NSEC_PER_SEC,
+					   decrementer_template.shift);
+	decrementer_template.max_delta_ns =
+		clockevent_delta2ns(DECREMENTER_MAX, &decrementer_template);
+	decrementer_template.min_delta_ns =
+		clockevent_delta2ns(0xf, &decrementer_template);
+
+	register_decrementer();
+#else
 	/* Not exact, but the timer interrupt takes care of this */
 	set_dec(tb_ticks_per_jiffy);
+#endif
 }
 
 #define FEBRUARY	2

^ permalink raw reply

* Re: [PATCH] adding ROM chips to device tree: respin
From: Vitaly Wool @ 2006-11-07 21:17 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: linuxppc-embedded
In-Reply-To: <4550A5E6.50409@ru.mvista.com>

> > +     - memory_space : Offset and length of the register set for the device.
> 
>     NAK. There's no need to define an extra property where "reg" should be used.

The register set is actually not there and depends on flash chip type.
So using regs here is misleading.

> > +
> > +	/*
> > +	 * We care only about physmap devices now as there's no
> > +	 * description defined for other ROM types yet
> > +	 */
> 
>     Not true. The description only says that it's *most probably* compatible 
> with "physmap", that's all. I don't see why we have to limit ourselves here.

Effectively we care about NOR chips and similar which are
memory-mapped. 

Vitaly

^ permalink raw reply

* Re: [PATCH] adding ROM chips to device tree: respin
From: Sergei Shtylyov @ 2006-11-07 21:25 UTC (permalink / raw)
  To: Vitaly Wool; +Cc: linuxppc-embedded
In-Reply-To: <1162934221.2680.2.camel@barja>

Hello.

Vitaly Wool wrote:
>>>+     - memory_space : Offset and length of the register set for the device.
>>
>>    NAK. There's no need to define an extra property where "reg" should be used.

> The register set is actually not there and depends on flash chip type.
> So using regs here is misleading.

    This is an I/O resource on the parent bus and using the property other 
than "reg" will be misleading.  That's the way this spec has it -- "reg" is 
used even for the PHY chip numbering on MDIO bus...

>>>+
>>>+	/*
>>>+	 * We care only about physmap devices now as there's no
>>>+	 * description defined for other ROM types yet
>>>+	 */

>>    Not true. The description only says that it's *most probably* compatible 
>>with "physmap", that's all. I don't see why we have to limit ourselves here.

> Effectively we care about NOR chips and similar which are
> memory-mapped. 

    So what? How "physmap" follows from this?

> Vitaly

WBR, Sergei

^ permalink raw reply

* Re: [PATCH] adding ROM chips to device tree: respin
From: Vitaly Wool @ 2006-11-07 21:44 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: linuxppc-embedded
In-Reply-To: <4550F9B8.40901@ru.mvista.com>

В Ср, 08/11/2006 в 00:25 +0300, Sergei Shtylyov пишет:
> Hello.
> 
> Vitaly Wool wrote:
> >>>+     - memory_space : Offset and length of the register set for the device.
> >>
> >>    NAK. There's no need to define an extra property where "reg" should be used.
> 
> > The register set is actually not there and depends on flash chip type.
> > So using regs here is misleading.
> 
>     This is an I/O resource on the parent bus and using the property other 
> than "reg" will be misleading.  That's the way this spec has it -- "reg" is 
> used even for the PHY chip numbering on MDIO bus...

So what? Lemme remind you that the actual registers *doesn't start* at
the specified "start" so using regs is really a bad idea IMHO.

> >>>+
> >>>+	/*
> >>>+	 * We care only about physmap devices now as there's no
> >>>+	 * description defined for other ROM types yet
> >>>+	 */
> 
> >>    Not true. The description only says that it's *most probably* compatible 
> >>with "physmap", that's all. I don't see why we have to limit ourselves here.
> 
> > Effectively we care about NOR chips and similar which are
> > memory-mapped. 
> 
>     So what? How "physmap" follows from this?

Okay, probably we can go you way naming of_device by what it's
compatible with. So that "physmap" compatible would be called
"physmap-flash", "nand"-compatible would be called "nand-flash" etc.
Does that work for you?

Vitaly

^ permalink raw reply

* Re: [PATCH] adding ROM chips to device tree: respin
From: Sergei Shtylyov @ 2006-11-07 21:52 UTC (permalink / raw)
  To: Vitaly Wool; +Cc: linuxppc-embedded
In-Reply-To: <1162935862.2680.7.camel@barja>

Hello.

Vitaly Wool wrote:

>>>>>+     - memory_space : Offset and length of the register set for the device.
>>>>
>>>>   NAK. There's no need to define an extra property where "reg" should be used.
>>
>>>The register set is actually not there and depends on flash chip type.
>>>So using regs here is misleading.
>>
>>    This is an I/O resource on the parent bus and using the property other 
>>than "reg" will be misleading.  That's the way this spec has it -- "reg" is 
>>used even for the PHY chip numbering on MDIO bus...

> So what? Lemme remind you that the actual registers *doesn't start* at
> the specified "start" so using regs is really a bad idea IMHO.

    We don't have any actual registers (at least "physmap" doesn't know about 
them anyway) I think, just a memory range. What registers are you talking about?

>>>>>+
>>>>>+	/*
>>>>>+	 * We care only about physmap devices now as there's no
>>>>>+	 * description defined for other ROM types yet
>>>>>+	 */

>>>>   Not true. The description only says that it's *most probably* compatible 
>>>>with "physmap", that's all. I don't see why we have to limit ourselves here.

>>>Effectively we care about NOR chips and similar which are
>>>memory-mapped. 

>>    So what? How "physmap" follows from this?

> Okay, probably we can go you way naming of_device by what it's
> compatible with. So that "physmap" compatible would be called
> "physmap-flash", "nand"-compatible would be called "nand-flash" etc.

    Actually, Generic Names spec tells to use the most generic user-parsable 
names, just like I used initally ("flash")...

> Does that work for you?

    No. Getting rid of "physmap" completely and using of_find_node_by_type() 
does. :-)

> Vitaly

WBR, Sergei

^ permalink raw reply

* Re: [PATCH] adding ROM chips to device tree: respin
From: Vitaly Wool @ 2006-11-07 22:18 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: linuxppc-embedded
In-Reply-To: <45510013.8010509@ru.mvista.com>


>     We don't have any actual registers (at least "physmap" doesn't know about 
> them anyway) I think, just a memory range. What registers are you talking about?

We do have registers there, in query mode. The CFI registers.

> > Okay, probably we can go you way naming of_device by what it's
> > compatible with. So that "physmap" compatible would be called
> > "physmap-flash", "nand"-compatible would be called "nand-flash" etc.
> 
>     Actually, Generic Names spec tells to use the most generic user-parsable 
> names, just like I used initally ("flash")...
> 
> > Does that work for you?
> 
>     No. Getting rid of "physmap" completely and using of_find_node_by_type() 
> does. :-)

That's effectively what I'm talking about. Find the device by type and
register it with the name which depends on what it's compatible with.

Vitaly

^ permalink raw reply

* Re: [RFC/PATCH 4/7] Powerpc MSI implementation
From: Russell King @ 2006-11-07 22:25 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Greg Kroah-Hartman, Ingo Molnar, linuxppc-dev, Thomas Gleixner,
	Eric W.Biederman, linux-pci, David S.Miller
In-Reply-To: <20061107210202.GA27140@parisc-linux.org>

On Tue, Nov 07, 2006 at 02:02:02PM -0700, Matthew Wilcox wrote:
> On Tue, Nov 07, 2006 at 08:48:53PM +0000, Russell King wrote:
> > On Tue, Nov 07, 2006 at 01:44:32PM -0700, Matthew Wilcox wrote:
> > > On Tue, Nov 07, 2006 at 08:14:36PM +0000, Russell King wrote:
> > > > Bah.  chip_data is supposed to be __iomem.  I bet if you build ARM
> > > > with sparse it'll kick out lots of warnings as a result of that loss.
> > > 
> > > Erm, since when?  When I introduced it (back in January 2005 [1]), it
> > > was called handler_data and pointed to a struct which is chip-type
> > > dependent.
> > 
> > Since before the generic irq merge.  If I was more expert with git
> > I'd post a URL, but I'm not so I won't.  But I'm sure you can find
> > it - look at the history of include/asm-arm/mach/irq.h.
> 
> OK.  Looks like the first mention of this is in 
> 4a2581a080098ca3a0c4e416d7a282e96c75ebf8 from July 2006
> which is signed-off by you, Ingo Molnar and Thomas Gleixner:
> 
> -       void __iomem    *base;
> [...]
> +#define set_irq_chipdata(irq, d)       set_irq_chip_data(irq, d)
> +#define get_irq_chipdata(irq)          get_irq_chip_data(irq)
> -#define set_irq_chipdata(irq,d)                        do { irq_desc[irq].base = d; } while (0)
> -#define get_irq_chipdata(irq)                  (irq_desc[irq].base)

Yes and now I'm regretting having switched ARM over to the generic IRQ
stuff - the old stuff did _precisely_ what we wanted the way we wanted.
None of these compromises.

> As other architectures, you could embed the iomem pointer in a
> struct (would it be useful to you to have more than an iomem pointer
> in your handlers?), or you could put the cast adding __iomem in
> get_irq_chipdata().

That's extremely wasteful - the only way to do that would be to kmalloc
some memory, and that's 32 bytes minimum, just to store 4 bytes of
pointer.  There's no other information which needs to be stored.

I guess we'll just have to add __force casts all over the code. ;(

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox