[U-Boot] List of offending drivers
Hello,
Check the following list, it's the list of drivers scattered (misplaced) across the tree. The list is not complete and might be inaccurate. But it should give a good impression of what I'm going to break soon:
arch/blackfin/cpu/serial.c arch/m68k/cpu/mcf5445x/pci.c arch/m68k/cpu/mcf547x_8x/pci.c arch/mips/cpu/mips32/au1x00/au1x00_eth.c arch/mips/cpu/mips32/au1x00/au1x00_serial.c arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.c arch/mips/cpu/mips32/incaip/asc_serial.c arch/mips/cpu/xburst/jz_serial.c arch/powerpc/cpu/mpc512x/i2c.c arch/powerpc/cpu/mpc512x/ide.c arch/powerpc/cpu/mpc512x/pci.c arch/powerpc/cpu/mpc512x/serial.c arch/powerpc/cpu/mpc5xx/serial.c arch/powerpc/cpu/mpc5xx/spi.c arch/powerpc/cpu/mpc5xxx/i2c.c arch/powerpc/cpu/mpc5xxx/ide.c arch/powerpc/cpu/mpc5xxx/pci_mpc5200.c arch/powerpc/cpu/mpc5xxx/serial.c arch/powerpc/cpu/mpc5xxx/usb.c arch/powerpc/cpu/mpc5xxx/usb_ohci.c arch/powerpc/cpu/mpc8220/fec.c arch/powerpc/cpu/mpc8220/i2c.c arch/powerpc/cpu/mpc8220/pci.c arch/powerpc/cpu/mpc8220/uart.c arch/powerpc/cpu/mpc824x/pci.c arch/powerpc/cpu/mpc824x/drivers/i2c/i2c.c arch/powerpc/cpu/mpc8260/ether_fcc.c arch/powerpc/cpu/mpc8260/ether_scc.c arch/powerpc/cpu/mpc8260/i2c.c arch/powerpc/cpu/mpc8260/pci.c arch/powerpc/cpu/mpc8260/serial_scc.c arch/powerpc/cpu/mpc8260/serial_smc.c arch/powerpc/cpu/mpc8260/spi.c arch/powerpc/cpu/mpc83xx/pci.c arch/powerpc/cpu/mpc83xx/pcie.c arch/powerpc/cpu/mpc85xx/ether_fcc.c arch/powerpc/cpu/mpc85xx/pci.c arch/powerpc/cpu/mpc85xx/serial_scc.c arch/powerpc/cpu/mpc8xx/fec.c arch/powerpc/cpu/mpc8xx/i2c.c arch/powerpc/cpu/mpc8xx/lcd.c arch/powerpc/cpu/mpc8xx/serial.c arch/powerpc/cpu/mpc8xx/spi.c arch/powerpc/cpu/mpc8xx/video.c arch/powerpc/cpu/mpc8xx/wlkbd.c arch/powerpc/cpu/ppc4xx/4xx_pci.c arch/powerpc/cpu/ppc4xx/4xx_pcie.c arch/powerpc/cpu/ppc4xx/4xx_uart.c arch/powerpc/cpu/ppc4xx/gpio.c arch/powerpc/cpu/ppc4xx/miiphy.c arch/powerpc/cpu/ppc4xx/usb.c arch/powerpc/cpu/ppc4xx/usb_ohci.c arch/sh/cpu/sh2/watchdog.c arch/sh/cpu/sh3/watchdog.c arch/sh/cpu/sh4/watchdog.c arch/sparc/cpu/leon2/serial.c arch/sparc/cpu/leon3/serial.c arch/sparc/cpu/leon3/usb_uhci.c arch/x86/cpu/sc520/sc520_pci.c
board/BuS/EB+MCF-EV123/cfm_flash.c board/BuS/EB+MCF-EV123/flash.c board/LEOX/elpt860/flash.c board/Marvell/common/flash.c board/Marvell/common/i2c.c board/Marvell/common/intel_flash.c board/Marvell/common/ns16550.c board/Marvell/common/serial.c board/Marvell/db64360/mv_eth.c board/Marvell/db64360/pci.c board/Marvell/db64460/mv_eth.c board/Marvell/db64460/pci.c board/RPXClassic/flash.c board/RPXlite/flash.c board/RPXlite_dw/flash.c board/RRvision/flash.c board/a3000/flash.c board/alaska/flash.c board/altera/common/AMDLV065D.c board/altera/common/cfide.c board/altera/common/epled.c board/altera/common/flash.c board/altera/common/sevenseg.c board/amcc/bamboo/flash.c board/amcc/bubinga/flash.c board/amcc/common/flash.c board/amcc/ebony/flash.c board/amcc/luan/flash.c board/amcc/ocotea/flash.c board/amcc/taihu/flash.c board/amcc/taihu/lcd.c board/amcc/taishan/lcd.c board/amcc/walnut/flash.c board/amcc/yucca/flash.c board/amirix/ap1000/flash.c board/amirix/ap1000/pci.c board/amirix/ap1000/serial.c board/armltd/integrator/pci.c board/atc/flash.c board/atmel/at91rm9200ek/led.c board/atmel/at91sam9260ek/led.c board/atmel/at91sam9261ek/led.c board/atmel/at91sam9263ek/led.c board/atmel/at91sam9m10g45ek/led.c board/atmel/at91sam9rlek/led.c board/bct-brettl2/cled.c board/bct-brettl2/gpio_cfi_flash.c board/bct-brettl2/smsc9303.c board/bf527-ezkit/video.c board/bf533-ezkit/flash.c board/bf533-stamp/ide-cf.c board/bf533-stamp/video.c board/bf537-stamp/ide-cf.c board/bf548-ezkit/video.c board/bmw/flash.c board/bmw/m48t59y.c board/bmw/ns16550.c board/bmw/serial.c board/c2mon/flash.c board/c2mon/pcmcia.c board/calao/sbc35_a9g20/spi.c board/calao/tny_a9260/spi.c board/cm-bf527/gpio_cfi_flash.c board/cm-bf537e/gpio_cfi_flash.c board/cm-bf537u/gpio_cfi_flash.c board/cm-bf548/video.c board/cm4008/flash.c board/cm41xx/flash.c board/cm_t35/eeprom.c board/cm_t35/leds.c board/cmi/flash.c board/cobra5272/flash.c board/cogent/flash.c board/cogent/lcd.c board/cogent/pci.c board/cogent/rtc.c board/cogent/serial.c board/cpc45/flash.c board/cpc45/pd67290.c board/cpc45/plx9030.c board/cpu86/flash.c board/cpu87/flash.c board/cray/L1/flash.c board/cu824/flash.c board/dave/PPChameleonEVB/flash.c board/dave/PPChameleonEVB/nand.c board/dave/common/flash.c board/dave/common/fpga.c board/dave/common/pci.c board/davedenx/qong/fpga.c board/dvlhost/watchdog.c board/eNET/eNET_pci.c board/earthlcd/favr-32-ezkit/flash.c board/eltec/elppc/eepro100_srom.c board/eltec/elppc/flash.c board/eltec/elppc/mpc107_i2c.c board/eltec/elppc/pci.c board/eltec/mhpc/flash.c board/emk/common/am79c874.c board/emk/common/flash.c board/emk/top9000/spi.c board/ep8260/flash.c board/ep8260/mii_phy.c board/esd/adciop/flash.c board/esd/ar405/flash.c board/esd/ash405/flash.c board/esd/canbt/canbt.c board/esd/canbt/flash.c board/esd/cms700/flash.c board/esd/common/esd405ep_nand.c board/esd/common/flash.c board/esd/common/fpga.c board/esd/common/lcd.c board/esd/common/pci.c board/esd/common/xilinx_jtag/ board/esd/cpci2dp/flash.c board/esd/cpci405/flash.c board/esd/cpci5200/strataflash.c board/esd/cpci750/i2c.c board/esd/cpci750/ide.c board/esd/cpci750/mv_eth.c board/esd/cpci750/pci.c board/esd/cpci750/serial.c board/esd/cpciiser4/flash.c board/esd/dasa_sim/eeprom.c board/esd/dasa_sim/flash.c board/esd/dp405/flash.c board/esd/du405/flash.c board/esd/hh405/flash.c board/esd/hub405/flash.c board/esd/ocrtc/flash.c board/esd/pci405/flash.c board/esd/pci405/pci405.c board/esd/pf5200/flash.c board/esd/plu405/flash.c board/esd/pmc440/fpga.c board/esd/tasreg/flash.c board/esd/vme8349/caddy.c board/esd/vme8349/pci.c board/esd/voh405/flash.c board/esd/vom405/flash.c board/esd/wuh405/flash.c board/esteem192e/flash.c board/etin/debris/flash.c board/etin/debris/phantom.c board/etx094/flash.c board/eukrea/cpu9260/led.c board/evb64260/eth_addrtbl.c board/evb64260/eth.c board/evb64260/flash.c board/evb64260/i2c.c board/evb64260/intel_flash.c board/evb64260/pci.c board/evb64260/serial.c board/fads/flash.c board/fads/lamp.c board/fads/pcmcia.c board/flagadm/flash.c board/freescale/m5253demo/flash.c board/freescale/m5329evb/nand.c board/freescale/m5373evb/nand.c board/freescale/mpc8260ads/flash.c board/freescale/mpc8266ads/flash.c board/freescale/mpc832xemds/pci.c board/freescale/mpc8349emds/pci.c board/freescale/mpc8349itx/pci.c board/freescale/mpc8360emds/pci.c board/freescale/mpc8360erdk/nand.c board/freescale/mpc837xemds/pci.c board/freescale/mpc837xerdb/pci.c board/freescale/p1_p2_rdb/pci.c board/freescale/p2041rdb/eth.c board/freescale/p3060qds/eth.c board/funkwerk/vovpn-gw/flash.c board/funkwerk/vovpn-gw/m88e6060.c board/g2000/strataflash.c board/gdsys/common/miiphybb.c board/gen860t/beeper.c board/gen860t/flash.c board/gen860t/fpga.c board/genietv/flash.c board/gth2/ee_access.c board/gth2/flash.c board/gw8260/flash.c board/hermes/flash.c board/hidden_dragon/flash.c board/hymod/eeprom.c board/hymod/env.c board/hymod/flash.c board/hymod/input.c board/icecube/flash.c board/icu862/flash.c board/icu862/pcmcia.c board/idmr/flash.c board/incaip/flash.c ard/ip860/flash.c board/iphase4539/flash.c board/ivm/flash.c board/jse/flash.c board/jse/host_bridge.c board/keymile/km83xx/km83xx_i2c.c board/kup/common/flash.c board/kup/common/pcmcia.c board/lantec/flash.c board/linkstation/ide.c board/logicpd/zoom2/led.c board/lubbock/flash.c board/lwmon/flash.c board/lwmon/pcmcia.c board/lwmon5/kbd.c board/manroland/uc100/pcmcia.c board/matrix_vision/mergerbox/fpga.c board/matrix_vision/mergerbox/pci.c board/matrix_vision/mvbc_p/fpga.c board/matrix_vision/mvblm7/fpga.c board/matrix_vision/mvblm7/pci.c board/matrix_vision/mvblx/fpga.c board/matrix_vision/mvblx/sys_eeprom.c board/matrix_vision/mvsmr/fpga.c board/mbx8xx/flash.c board/mbx8xx/pcmcia.c board/mcc200/lcd.c board/micronas/vct/ebi.c board/micronas/vct/ebi_nor_flash.c board/micronas/vct/ebi_onenand.c board/micronas/vct/ebi_smc911x.c board/micronas/vct/ehci.c board/micronas/vct/gpio.c board/micronas/vct/smc_eeprom.c board/ml2/flash.c board/ml2/serial.c board/mousse/flash.c board/mousse/m48t59y.c board/mousse/pci.c board/mpl/common/isa.c board/mpl/common/kbd.c board/mpl/common/pci.c board/mpl/common/usb_uhci.c board/musenki/flash.c board/mvblue/flash.c board/mx1ads/syncflash.c board/netphone/phone_console.c board/netphone/flash.c board/netta/codec.c board/netta/dsp.c board/netta/flash.c board/netta/pcmcia.c board/netta2/flash.c board/netvia/flash.c board/ns9750dev/flash.c board/ns9750dev/led.c board/nx823/flash.c board/o2dnt/flash.c board/pb1x00/flash.c board/pcippc2/cpc710_pci.c board/pcippc2/flash.c board/pcippc2/fpga_serial.c board/pcippc2/i2c.c board/pcippc2/pcippc2_fpga.c board/pcippc2/sconsole.c board/pcs440ep/flash.c board/pm520/flash.c board/pm826/flash.c board/pm828/flash.c board/ppmc7xx/flash.c board/ppmc7xx/pci.c board/ppmc8260/strataflash.c board/prodrive/alpr/fpga.c board/prodrive/alpr/nand.c board/prodrive/common/flash.c board/prodrive/common/fpga.c board/prodrive/p3mx/mv_eth.c board/prodrive/p3mx/pci.c board/prodrive/p3mx/serial.c board/prodrive/pdnb3/flash.c board/prodrive/pdnb3/nand.c board/psyent/pk1c20/led.c board/quad100hd/nand.c board/quantum/fpga.c board/r360mpi/flash.c board/r360mpi/pcmcia.c board/rbc823/flash.c board/rbc823/kbd.c board/renesas/ap325rxa/cpld-ap325rxa.c board/renesas/sh7785lcr/rtl8169_mac.c board/ronetix/pm9261/led.c board/ronetix/pm9263/led.c board/rpxsuper/flash.c board/rpxsuper/mii_phy.c board/rsdproto/flash.c board/sacsng/flash.c board/samsung/goni/onenand.c board/samsung/smdkc100/onenand.c board/samsung/universal_c210/onenand.c board/sandburst/common/flash.c board/sandburst/common/ppc440gx_i2c.c board/sandpoint/flash.c board/sbc405/strataflash.c board/sbc8349/pci.c board/scb9328/flash.c board/siemens/IAD210/flash.c board/siemens/SCM/flash.c board/siemens/SCM/fpga_scm.c board/siemens/common/fpga.c board/sixnet/flash.c board/snmc/qs850/flash.c board/snmc/qs860t/flash.c board/socrates/nand.c board/spd8xx/flash.c board/st-ericsson/u8500/gpio.c board/stx/stxgp3/flash.c board/svm_sc8xx/flash.c board/tcm-bf537/gpio_cfi_flash.c board/ti/beagle/led.c board/ti/omap730p2/flash.c board/tqc/tqm5200/cam5200_flash.c board/tqc/tqm8272/nand.c board/tqc/tqm834x/pci.c board/tqc/tqm85xx/nand.c board/trizepsiv/eeprom.c board/utx8245/flash.c board/v37/flash.c board/v38b/ethaddr.c board/vpac270/onenand.c board/w7o/flash.c board/w7o/fpga.c board/westel/amx860/flash.c board/xaeniax/flash.c board/xes/common/actl_nand.c board/xes/common/fsl_8xxx_pci.c
Best regards, Marek Vasut
Hi Marek,
On Fri, Jul 27, 2012 at 9:18 AM, Marek Vasut marex@denx.de wrote:
Hello,
Check the following list, it's the list of drivers scattered (misplaced) across the tree. The list is not complete and might be inaccurate. But it should give a good impression of what I'm going to break soon:
arch/x86/cpu/sc520/sc520_pci.c board/eNET/eNET_pci.c
Hmm, I'm wondering what where the line between 'driver' and 'arch/board specific driver glue' is? How was this list generated?
You seem to have missed sc520_ssi.c and sc520_timer.c
board/eNET/eNET_pci.c only contains:
pci_enet_fixup_irq() - Board specific configuration of PCI interrupt lines. This is a platform function which is specified when the board initialises the PCI driver. Note that this function calls pci_sc520_set_irq() which is located on arch/x86/cpu/sc520/sc520_pci.c (see below)
pci_init_board() - One line wrapper for pci_sc520_init() which should get dropped once the driver model and init sequence (if that gets looked at again) refactoring
pci_set_regions() - Configure the board-specific PCI memory and I/O regions
arch/x86/cpu/sc520/sc520_pci.c contains: pci_sc520_set_irq() - A support function for board-specific PCI interrupt line configuration pci_sc520_init() - SC520 specific PCI driver initialisation
So neither of these files are 'drivers' per-se. They are really just initialisation and platform specific support functions. How do these fit into the new driver model?
Regards,
Graeme
Dear Graeme Russ,
Hi Marek,
On Fri, Jul 27, 2012 at 9:18 AM, Marek Vasut marex@denx.de wrote:
Hello,
Check the following list, it's the list of drivers scattered (misplaced) across the tree. The list is not complete and might be inaccurate. But it should give a good impression of what I'm going to break soon:
arch/x86/cpu/sc520/sc520_pci.c board/eNET/eNET_pci.c
Hmm, I'm wondering what where the line between 'driver' and 'arch/board specific driver glue' is?
That's why I said the list isn't exactly precise.
How was this list generated?
By hard manual labor (=slavework).
You seem to have missed sc520_ssi.c and sc520_timer.c
I wonder if we should move the timer drivers ... maybe to drivers/timer/ ?
board/eNET/eNET_pci.c only contains:
pci_enet_fixup_irq() - Board specific configuration of PCI interrupt lines. This is a platform function which is specified when the board initialises the PCI driver. Note that this function calls pci_sc520_set_irq() which is located on arch/x86/cpu/sc520/sc520_pci.c (see below)
Ok, so this one should be left out, I didn't properly examine them all. Just wanted to share the list, the examination will follow this weekend, when I start moving them.
pci_init_board() - One line wrapper for pci_sc520_init() which should get dropped once the driver model and init sequence (if that gets looked at again) refactoring
pci_set_regions() - Configure the board-specific PCI memory and I/O regions
arch/x86/cpu/sc520/sc520_pci.c contains: pci_sc520_set_irq() - A support function for board-specific PCI interrupt line configuration pci_sc520_init() - SC520 specific PCI driver initialisation
So neither of these files are 'drivers' per-se. They are really just initialisation and platform specific support functions. How do these fit into the new driver model?
You can supply a pointer to that function to some "pci" driver I guess ... Pavel?
Regards,
Graeme
Best regards, Marek Vasut
Hi Marek,
On Fri, Jul 27, 2012 at 11:11 AM, Marek Vasut marex@denx.de wrote:
Dear Graeme Russ,
So neither of these files are 'drivers' per-se. They are really just initialisation and platform specific support functions. How do these fit into the new driver model?
You can supply a pointer to that function to some "pci" driver I guess ... Pavel?
In which case you have a board/arch specific function to intialise the pointer :) Hmm, or are we now looking at a variation of my INIT_FUNC architecture where this gets done at compile time?
Regards,
Graeme
Dear Graeme Russ,
Hi Marek,
On Fri, Jul 27, 2012 at 11:11 AM, Marek Vasut marex@denx.de wrote:
Dear Graeme Russ,
So neither of these files are 'drivers' per-se. They are really just initialisation and platform specific support functions. How do these fit into the new driver model?
You can supply a pointer to that function to some "pci" driver I guess ... Pavel?
In which case you have a board/arch specific function to intialise the pointer :)
No, you have static platform data which contain the pointer.
Hmm, or are we now looking at a variation of my INIT_FUNC architecture where this gets done at compile time?
I think you missed the point here
Regards,
Graeme
Best regards, Marek Vasut
Hi Marek,
On Fri, Jul 27, 2012 at 11:26 AM, Marek Vasut marex@denx.de wrote:
Dear Graeme Russ,
Hi Marek,
On Fri, Jul 27, 2012 at 11:11 AM, Marek Vasut marex@denx.de wrote:
Dear Graeme Russ,
So neither of these files are 'drivers' per-se. They are really just initialisation and platform specific support functions. How do these fit into the new driver model?
You can supply a pointer to that function to some "pci" driver I guess ... Pavel?
In which case you have a board/arch specific function to intialise the pointer :)
No, you have static platform data which contain the pointer.
Ah, of course
Hmm, or are we now looking at a variation of my INIT_FUNC architecture where this gets done at compile time?
I think you missed the point here
Yes, by --->| |<--- that much :)
Oh, unless of course it has to be done dynamically due to a single U-Boot image supporting multiple board hardware configurations...
Regards
Graeme
Dear Graeme Russ,
Hi Marek,
On Fri, Jul 27, 2012 at 11:26 AM, Marek Vasut marex@denx.de wrote:
Dear Graeme Russ,
Hi Marek,
On Fri, Jul 27, 2012 at 11:11 AM, Marek Vasut marex@denx.de wrote:
Dear Graeme Russ,
So neither of these files are 'drivers' per-se. They are really just initialisation and platform specific support functions. How do these fit into the new driver model?
You can supply a pointer to that function to some "pci" driver I guess ... Pavel?
In which case you have a board/arch specific function to intialise the pointer :)
No, you have static platform data which contain the pointer.
Ah, of course
Hmm, or are we now looking at a variation of my INIT_FUNC architecture where this gets done at compile time?
I think you missed the point here
Yes, by --->| |<--- that much :)
Oh, unless of course it has to be done dynamically due to a single U-Boot image supporting multiple board hardware configurations...
Which is not yet happening, let's take small steps, ok?
Regards
Graeme
Best regards, Marek Vasut
Dear Marek Vasut,
In message 201207270118.19524.marex@denx.de you wrote:
Check the following list, it's the list of drivers scattered (misplaced) across the tree. The list is not complete and might be inaccurate. But it should give a good impression of what I'm going to break soon:
board/BuS/EB+MCF-EV123/cfm_flash.c board/BuS/EB+MCF-EV123/flash.c board/LEOX/elpt860/flash.c board/Marvell/common/flash.c board/Marvell/common/intel_flash.c board/RPXClassic/flash.c board/RPXlite/flash.c board/RPXlite_dw/flash.c board/RRvision/flash.c board/a3000/flash.c board/alaska/flash.c board/altera/common/flash.c board/amcc/bamboo/flash.c board/amcc/bubinga/flash.c board/amcc/common/flash.c board/amcc/ebony/flash.c board/amcc/luan/flash.c board/amcc/ocotea/flash.c board/amcc/taihu/flash.c board/amcc/walnut/flash.c board/amcc/yucca/flash.c board/amirix/ap1000/flash.c board/atc/flash.c board/bct-brettl2/gpio_cfi_flash.c board/bf533-ezkit/flash.c board/bmw/flash.c board/c2mon/flash.c board/cm-bf527/gpio_cfi_flash.c board/cm-bf537e/gpio_cfi_flash.c board/cm-bf537u/gpio_cfi_flash.c board/cm4008/flash.c board/cm41xx/flash.c board/cmi/flash.c board/cobra5272/flash.c board/cogent/flash.c board/cpc45/flash.c board/cpu86/flash.c board/cpu87/flash.c board/cray/L1/flash.c board/cu824/flash.c board/dave/PPChameleonEVB/flash.c board/dave/common/flash.c board/earthlcd/favr-32-ezkit/flash.c board/eltec/elppc/flash.c board/eltec/mhpc/flash.c board/emk/common/flash.c board/ep8260/flash.c board/esd/adciop/flash.c board/esd/ar405/flash.c board/esd/ash405/flash.c board/esd/canbt/flash.c board/esd/cms700/flash.c board/esd/common/flash.c board/esd/cpci2dp/flash.c board/esd/cpci405/flash.c board/esd/cpci5200/strataflash.c board/esd/cpciiser4/flash.c board/esd/dasa_sim/flash.c board/esd/dp405/flash.c board/esd/du405/flash.c board/esd/hh405/flash.c board/esd/hub405/flash.c board/esd/ocrtc/flash.c board/esd/pci405/flash.c board/esd/pf5200/flash.c board/esd/plu405/flash.c board/esd/tasreg/flash.c board/esd/voh405/flash.c board/esd/vom405/flash.c board/esd/wuh405/flash.c board/esteem192e/flash.c board/etin/debris/flash.c board/etx094/flash.c board/evb64260/flash.c board/evb64260/intel_flash.c board/fads/flash.c board/flagadm/flash.c board/freescale/m5253demo/flash.c board/freescale/mpc8260ads/flash.c board/freescale/mpc8266ads/flash.c board/funkwerk/vovpn-gw/flash.c board/g2000/strataflash.c board/gen860t/flash.c board/genietv/flash.c board/gth2/flash.c board/gw8260/flash.c board/hermes/flash.c board/hidden_dragon/flash.c board/hymod/flash.c board/icecube/flash.c board/icu862/flash.c board/idmr/flash.c board/incaip/flash.c ard/ip860/flash.c board/iphase4539/flash.c board/ivm/flash.c board/jse/flash.c board/kup/common/flash.c board/lantec/flash.c board/lubbock/flash.c board/lwmon/flash.c board/mbx8xx/flash.c board/micronas/vct/ebi_nor_flash.c board/ml2/flash.c board/mousse/flash.c board/musenki/flash.c board/mvblue/flash.c board/mx1ads/syncflash.c board/netphone/flash.c board/netta/flash.c board/netta2/flash.c board/netvia/flash.c board/ns9750dev/flash.c board/nx823/flash.c board/o2dnt/flash.c board/pb1x00/flash.c board/pcippc2/flash.c board/pcs440ep/flash.c board/pm520/flash.c board/pm826/flash.c board/pm828/flash.c board/ppmc7xx/flash.c board/ppmc8260/strataflash.c board/prodrive/common/flash.c board/prodrive/pdnb3/flash.c board/r360mpi/flash.c board/rbc823/flash.c board/rpxsuper/flash.c board/rsdproto/flash.c board/sacsng/flash.c board/sandburst/common/flash.c board/sandpoint/flash.c board/sbc405/strataflash.c board/scb9328/flash.c board/siemens/IAD210/flash.c board/siemens/SCM/flash.c board/sixnet/flash.c board/snmc/qs850/flash.c board/snmc/qs860t/flash.c board/spd8xx/flash.c board/stx/stxgp3/flash.c board/svm_sc8xx/flash.c board/tcm-bf537/gpio_cfi_flash.c board/ti/omap730p2/flash.c board/tqc/tqm5200/cam5200_flash.c board/utx8245/flash.c board/v37/flash.c board/w7o/flash.c board/westel/amx860/flash.c board/xaeniax/flash.c
All these are either
1) old versions of flash drivers that predate the cfi flash implementation, so they could be replaced by the CFI driver (if there was someone to test this)
or
2) very special versions of flash drivers dealing with board specific details that prevent the use of the CFI flash driver, in which case they should remain in the board directories.
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
Dear Marek Vasut,
In message 201207270118.19524.marex@denx.de you wrote:
Check the following list, it's the list of drivers scattered (misplaced) across the tree. The list is not complete and might be inaccurate. But it should give a good impression of what I'm going to break soon:
[...]
All these are either
- old versions of flash drivers that predate the cfi flash implementation, so they could be replaced by the CFI driver (if there was someone to test this)
Well, can they not be replaced either way? Someone will eventually complain if they care enough.
or
- very special versions of flash drivers dealing with board specific details that prevent the use of the CFI flash driver, in which case they should remain in the board directories.
Can these not be unified (read stuffed with #ifdef-#endif blocks for now, later replaced with platform data) ?
Best regards,
Wolfgang Denk
Best regards, Marek Vasut
Dear Marek Vasut,
In message 201207271042.48099.marex@denx.de you wrote:
All these are either
- old versions of flash drivers that predate the cfi flash implementation, so they could be replaced by the CFI driver (if there was someone to test this)
Well, can they not be replaced either way? Someone will eventually complain if they care enough.
No. I will not accept moving reduindant crap into the drivers/ hierarchy. If this is code that can be replaced by using the CFI driver, this reorganization is the point to do it.
If the boards are uinmaintained, then so be it, we will remove broken stuff.
- very special versions of flash drivers dealing with board specific details that prevent the use of the CFI flash driver, in which case they should remain in the board directories.
Can these not be unified (read stuffed with #ifdef-#endif blocks for now, later replaced with platform data) ?
I don't see how this could be done, and it seems not worth the effort to me. I smell most of these are unmaintained boards, and it's easier to clean this up once for all.
Best regards,
Wolfgang Denk
On Friday 27 July 2012 00:41:45 Wolfgang Denk wrote:
Marek Vasut wrote:
Check the following list, it's the list of drivers scattered (misplaced) across the tree. The list is not complete and might be inaccurate. But it should give a good impression of what I'm going to break soon:
board/bf533-ezkit/flash.c
- old versions of flash drivers that predate the cfi flash implementation, so they could be replaced by the CFI driver (if there was someone to test this)
yep. this driver is wicked old, and has since languished for a few reasons: - the people who wrote it originally were (are) not exactly great programmers. in fact, they were pretty terrible. - this particular board is one of the first Blackfins to see a real open source port, but the board itself isn't terribly developer friendly, so no one pays too much attention to it. - the flash does not support the CFI query command which means none of the stock CFI code would work out of the box (it does use the AMD CFI commandset though). - the flash is funky -- it's two chips in a single package which leads to quite a bit of confusion, and it also has SRAM areas on it ! - the Blackfin maintainers who took over weren't terribly familiar with the CFI spec (i would say i only have a little familiarity at a higher level).
at any rate, i was able to figure out the JEDEC probe logic in Linux somewhat recently to make it work there, and so i ported that to u-boot which means we can drop this old driver (patches already posted). seems to probe/read/erase/write just fine, so ship it ;).
board/bct-brettl2/gpio_cfi_flash.c board/cm-bf527/gpio_cfi_flash.c board/cm-bf537e/gpio_cfi_flash.c board/cm-bf537u/gpio_cfi_flash.c board/tcm-bf537/gpio_cfi_flash.c
- very special versions of flash drivers dealing with board specific details that prevent the use of the CFI flash driver, in which case they should remain in the board directories.
yep. these are merely glue to support the flashes on these boards that use GPIO's for additional address lines. they actually use the common CFI code already.
there is a thread from a while ago discussing how to make these work better in the larger u-boot framework (NOR flashes which are not fully directly mapped), but i honestly don't think i'll ever get around to implementing that idea. i have no job that requires it, and only had a passing interest in implementing it ;). -mike
Dear Marek Vasut,
board/samsung/goni/onenand.c board/samsung/smdkc100/onenand.c board/samsung/universal_c210/onenand.c
Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are.
Dear Lukasz Majewski,
Dear Marek Vasut,
board/samsung/goni/onenand.c board/samsung/smdkc100/onenand.c board/samsung/universal_c210/onenand.c
Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are.
That's fairy possible, I did only quick inspection and I'll be taking further look this weekend.
Best regards, Marek Vasut
Hi Marek,
On 07/27/12 11:43, Marek Vasut wrote:
Dear Lukasz Majewski,
Dear Marek Vasut,
board/samsung/goni/onenand.c board/samsung/smdkc100/onenand.c board/samsung/universal_c210/onenand.c
Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are.
That's fairy possible, I did only quick inspection and I'll be taking further look this weekend.
May be you should do a further look before sending a heads up about everything you see...
Dear Igor Grinberg,
Hi Marek,
On 07/27/12 11:43, Marek Vasut wrote:
Dear Lukasz Majewski,
Dear Marek Vasut,
board/samsung/goni/onenand.c board/samsung/smdkc100/onenand.c board/samsung/universal_c210/onenand.c
Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are.
That's fairy possible, I did only quick inspection and I'll be taking further look this weekend.
May be you should do a further look before sending a heads up about everything you see...
Where are you aiming with this exactly? I clearly stated I didn't do deep inspection of these and that there might be mishits
Best regards, Marek Vasut
On 07/27/12 17:30, Marek Vasut wrote:
Dear Igor Grinberg,
Hi Marek,
On 07/27/12 11:43, Marek Vasut wrote:
Dear Lukasz Majewski,
Dear Marek Vasut,
board/samsung/goni/onenand.c board/samsung/smdkc100/onenand.c board/samsung/universal_c210/onenand.c
Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are.
That's fairy possible, I did only quick inspection and I'll be taking further look this weekend.
May be you should do a further look before sending a heads up about everything you see...
Where are you aiming with this exactly? I clearly stated I didn't do deep inspection of these and that there might be mishits
Probably, if you send the heads up email after taking a further look, the list would be shorter and hit the right people? Don't you think? Because, if you are going to look into this deeper, then what the point in sending the "quick look" list?
Dear Igor Grinberg,
On 07/27/12 17:30, Marek Vasut wrote:
Dear Igor Grinberg,
Hi Marek,
On 07/27/12 11:43, Marek Vasut wrote:
Dear Lukasz Majewski,
Dear Marek Vasut,
board/samsung/goni/onenand.c board/samsung/smdkc100/onenand.c board/samsung/universal_c210/onenand.c
Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are.
That's fairy possible, I did only quick inspection and I'll be taking further look this weekend.
May be you should do a further look before sending a heads up about everything you see...
Where are you aiming with this exactly? I clearly stated I didn't do deep inspection of these and that there might be mishits
Probably, if you send the heads up email after taking a further look, the list would be shorter and hit the right people? Don't you think? Because, if you are going to look into this deeper, then what the point in sending the "quick look" list?
http://en.wikipedia.org/wiki/Release_early,_release_often ;-)
Best regards, Marek Vasut
Dear Marek Vasut,
On 27.07.12 01:18, Marek Vasut wrote:
Hello,
Check the following list, it's the list of drivers scattered (misplaced) across the tree. The list is not complete and might be inaccurate. But it should give a good impression of what I'm going to break soon:
board/atmel/at91rm9200ek/led.c board/atmel/at91sam9260ek/led.c board/atmel/at91sam9261ek/led.c board/atmel/at91sam9263ek/led.c board/atmel/at91sam9m10g45ek/led.c board/atmel/at91sam9rlek/led.c
these atmel specific led stuff is basically for very early debug (switching a LED after relocation, another one after board init, ..). It also provides possibility to use it in assembler code sections e.g. lowlevel_init.
I do not really care about that cause I normally use JTAG to debug early code. The led switching at a specific stage could be done by one of the other generic led drivers.
Beside that, I think for debugging early stage code without JTAG the serial line is much better than a LED which can only provide two states. Has anyone thought about that? Has anyone tried to add some 'early_printf' feature?
Best regards
Andreas Bießmann
participants (7)
-
Andreas Bießmann -
Graeme Russ -
Igor Grinberg -
Lukasz Majewski -
Marek Vasut -
Mike Frysinger -
Wolfgang Denk