| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 25 May 2011 10:24:54 +0800 From: Barry Song <21cnbao@...il.com> To: Arnd Bergmann <arnd@...db.de> Cc: Nicolas Pitre <nico@...xnic.net>, linux-arm-kernel@...ts.infradead.org, Linus Torvalds <torvalds@...ux-foundation.org>, Thomas Gleixner <tglx@...utronix.de>, Russell King <linux@....linux.org.uk>, lkml <linux-kernel@...r.kernel.org> Subject: Re: CSR ARM SoC Subarchitecture preview 2011/5/25 Barry Song <21cnbao@...il.com>: > Hi Arnd, > thanks! since the discussion has been much different with original > subject. i move to a new thread. > > 2011/5/24 Arnd Bergmann <arnd@...db.de>: >> On Tuesday 24 May 2011, Barry Song wrote: >>> 2011/5/19 Arnd Bergmann <arnd@...db.de> >>> >>> > If you can just post a diffstat of the stuff you currently have, >>> > we also get an impression of the amount of code that you are >>> > talking about. >>> Arnd, thanks very much for thinking. Now the codes are based on 2.6.38 >>> and not quanified for sending patches. we will port them to be >>> againest linux's tree. >> >> Thanks for the diffstat, that is very helpful as an estimate. It appears >> that there is a large amount of work ahead of you in this, so by the >> time you get ready for inclusion, we will most certainly require this >> to be based on device tree for probing of all devices. I'd strongly >> recommend that you investigate what that means for you before you port >> a lot of the code to 2.6.39 or 2.6.40. >> >> Since the timing is a bit unfortunate for you, you might want to stay >> on 2.6.38 with the full port and not spend too much time on forward >> porting all of it, but instead migrate the drivers to be based on >> device tree properties rather than platform data, so you can submit >> the drivers individually upstream. > > good idea. then i will branch 2.6.38 for merging device tree and other > new changes. > >> >>> mach-prima2/Kconfig | 32 >>> mach-prima2/Makefile | 11 >>> mach-prima2/Makefile.boot | 3 >>> mach-prima2/devices.c | 191 + >>> mach-prima2/include/mach/cache-sirfsoc-prima2-l2.h | 12 >>> mach-prima2/include/mach/clkdev.h | 5 >>> mach-prima2/include/mach/debug-macro.S | 38 >>> mach-prima2/include/mach/entry-macro.S | 31 >>> mach-prima2/include/mach/gpio.h | 5 >>> mach-prima2/include/mach/hardware.h | 10 >>> mach-prima2/include/mach/io.h | 20 >>> mach-prima2/include/mach/irqs.h | 284 + >>> mach-prima2/include/mach/isa-dma.h | 13 >>> mach-prima2/include/mach/map.h | 263 + >>> mach-prima2/include/mach/memory.h | 56 >> >> The irqs.h and map.h are the largest by far here, and they should go >> away for the most part with the move to device tree. >> >>> mach-prima2/include/mach/prima2.h | 20 >>> mach-prima2/include/mach/prima2_pinmux.h | 39 >>> mach-prima2/include/mach/prima2cb.h | 111 >> >> There is a new pinmux subsystem in the works, so you probably >> end up having to write a new driver for that subsystem. > > i have noticed the pinmux from Linus Walleij. that is a task we want to do. > >> >>> mach-prima2/include/mach/regs-iobrg.h | 54 >>> mach-prima2/include/mach/regs-irq.h | 42 >>> mach-prima2/include/mach/regs-reset.h | 88 >>> mach-prima2/include/mach/regs-rsc.h | 76 >> >> For the registers, they can go together with the respective drivers >> using them. > > ok. looks like they should be limited to use in special drivers for > low coupling and other drivers call functions not access registers > directly. > then i will check whether they are overall shared, which cause them be > in mach head files. > >> >>> mach-prima2/include/mach/system.h | 5 >>> mach-prima2/include/mach/timex.h | 5 >>> mach-prima2/include/mach/uncompress.h | 45 >>> mach-prima2/include/mach/vmalloc.h | 19 >>> mach-prima2/lcdinit.c | 136 >>> mach-prima2/mach-prima2cb.c | 226 + >>> mach-prima2/padmode.c | 139 >>> mach-prima2/prima2.c | 81 >>> mach-prima2/prima2cb-keypad.c | 136 >>> mach-prima2/pwrc.c | 286 + >>> mach-prima2/tsc2100_dev.c | 137 >> >> Any drivers in here should get moved to a proper place in drivers/*/ >> eventually, out of the subarchitecture code. > > things related with driver framework/callbacks will be moved out. > platform_device data/hardware-related callbacks will be kept. but if > device tree supports platform_device data/callbacks good, i will take > a look whether we can delete as many as possible. > >> >>> mm/Kconfig | 13 >>> mm/Makefile | 1 >>> mm/cache-sirfsoc-prima2-l2.c | 342 + >>> plat-sirfsoc/Kconfig | 108 >>> plat-sirfsoc/Makefile | 34 >>> plat-sirfsoc/adc.c | 1395 ++++++++ >>> plat-sirfsoc/adcprocfs.c | 348 ++ >>> plat-sirfsoc/apm.c | 107 >>> plat-sirfsoc/clock.c | 1045 ++++++ >>> plat-sirfsoc/clock.h | 32 >>> plat-sirfsoc/core.c | 245 + >>> plat-sirfsoc/cpufreq.c | 239 + >>> plat-sirfsoc/deepsleep.S | 425 ++ >>> plat-sirfsoc/dma.c | 386 ++ >>> plat-sirfsoc/hibernate.h | 118 >> >> Same here. >> >>> plat-sirfsoc/include/plat/audio_controller.h | 333 + >>> plat-sirfsoc/include/plat/belmont.h | 92 >>> plat-sirfsoc/include/plat/bootmem.h | 45 >>> plat-sirfsoc/include/plat/clkdev.h | 15 >>> plat-sirfsoc/include/plat/cpld.h | 27 >>> plat-sirfsoc/include/plat/cpld_evb.h | 200 + >>> plat-sirfsoc/include/plat/cpld_fpga.h | 201 + >>> plat-sirfsoc/include/plat/cpu.h | 51 >>> plat-sirfsoc/include/plat/debug-macro.S | 34 >>> plat-sirfsoc/include/plat/gpio.h | 92 >>> plat-sirfsoc/include/plat/hardware.h | 28 >>> plat-sirfsoc/include/plat/iobrg.h | 17 >>> plat-sirfsoc/include/plat/irqs.h | 320 + >>> plat-sirfsoc/include/plat/isa-dma.h | 111 >>> plat-sirfsoc/include/plat/lcd_panels.h | 33 >>> plat-sirfsoc/include/plat/map.h | 233 + >>> plat-sirfsoc/include/plat/memory.h | 43 >>> plat-sirfsoc/include/plat/perfmon.h | 62 >>> plat-sirfsoc/include/plat/pinmux.h | 23 >> >> It's not clear yet what will happen in the long run to the split between >> mach-* and plat-* directories. Ideally, we would not need them to be >> separate if we can completely abstract the SoCs within their broader >> families, but we might not get that far before you merge your platform. > > before prima2 SoC, we have mach-atlas4, mach-atlas5 and mach-prima. > after prima2, we will have mach-atlas6. many ip cores are shared > between these SoCs, then there is a plat. > but we will not maintain old mach-atlas4, mach-atlas5 and mach-prima > for the current and future kernel. the new mach-atlas6 is the coming > SoC we will upstream after mach-prima2. > >> >> What other mach-* do you expect to see in the future using plat-sirfsoc, >> and how similar are they to prima2? > > plat-sirfsoc should be things shared by mach-prima2/mach-atlas6 and > other future SoCs. > >> >>> plat-sirfsoc/include/plat/platform_device/android_usb_dev.h | 27 >>> plat-sirfsoc/include/plat/platform_device/audio.h | 28 >>> plat-sirfsoc/include/plat/platform_device/bt_codec.h | 26 >>> plat-sirfsoc/include/plat/platform_device/eth.h | 26 >>> plat-sirfsoc/include/plat/platform_device/gps.h | 40 >>> plat-sirfsoc/include/plat/platform_device/i2c.h | 27 >>> plat-sirfsoc/include/plat/platform_device/inner_audio.h | 26 >>> plat-sirfsoc/include/plat/platform_device/lcd.h | 85 >>> plat-sirfsoc/include/plat/platform_device/mbx.h | 37 >>> plat-sirfsoc/include/plat/platform_device/modac.h | 26 >>> plat-sirfsoc/include/plat/platform_device/mved.h | 36 >>> plat-sirfsoc/include/plat/platform_device/nand.h | 27 >>> plat-sirfsoc/include/plat/platform_device/pmem.h | 27 >>> plat-sirfsoc/include/plat/platform_device/pwm_dev.h | 31 >>> plat-sirfsoc/include/plat/platform_device/rtc.h | 27 >>> plat-sirfsoc/include/plat/platform_device/sata.h | 33 >>> plat-sirfsoc/include/plat/platform_device/sd.h | 31 >>> plat-sirfsoc/include/plat/platform_device/serial.h | 82 >>> plat-sirfsoc/include/plat/platform_device/sirfsoc_ts.h | 31 >>> plat-sirfsoc/include/plat/platform_device/snd.h | 30 >>> plat-sirfsoc/include/plat/platform_device/spi.h | 53 >>> plat-sirfsoc/include/plat/platform_device/spi_sirfsoc_gpio.h | 34 >>> plat-sirfsoc/include/plat/platform_device/ts_stream_mode.h | 26 >>> plat-sirfsoc/include/plat/platform_device/usb.h | 40 >>> plat-sirfsoc/include/plat/platform_device/usppcm.h | 25 >>> plat-sirfsoc/include/plat/platform_device/uspserial.h | 45 >>> plat-sirfsoc/include/plat/platform_device/uspspi.h | 33 >>> plat-sirfsoc/include/plat/platform_device/vpp.h | 27 >>> plat-sirfsoc/include/plat/platform_device/vxd.h | 27 >>> plat-sirfsoc/include/plat/platform_device/wdt.h | 26 >>> plat-sirfsoc/platform_device/Makefile | 36 >>> plat-sirfsoc/platform_device/android_usb_dev.c | 60 >>> plat-sirfsoc/platform_device/audio_dev.c | 88 >>> plat-sirfsoc/platform_device/bt_codec_dev.c | 26 >>> plat-sirfsoc/platform_device/camera_dev.c | 286 + >>> plat-sirfsoc/platform_device/eth_dev.c | 75 >>> plat-sirfsoc/platform_device/gps_dev.c | 106 >>> plat-sirfsoc/platform_device/i2c_dev.c | 124 >>> plat-sirfsoc/platform_device/inner_audio_dev.c | 75 >>> plat-sirfsoc/platform_device/lcd_dev.c | 156 >>> plat-sirfsoc/platform_device/mbx_dev.c | 74 >>> plat-sirfsoc/platform_device/modac_dev.c | 67 >>> plat-sirfsoc/platform_device/mved_dev.c | 70 >>> plat-sirfsoc/platform_device/nand_dev.c | 75 >>> plat-sirfsoc/platform_device/pmem_dev.c | 59 >>> plat-sirfsoc/platform_device/pwm_device.c | 79 >>> plat-sirfsoc/platform_device/sata_dev.c | 64 >>> plat-sirfsoc/platform_device/sdmmc_dev.c | 108 >>> plat-sirfsoc/platform_device/serial_dev.c | 241 + >>> plat-sirfsoc/platform_device/sirfsoc_rtcdev.c | 78 >>> plat-sirfsoc/platform_device/sirfsoc_tsdev.c | 65 >>> plat-sirfsoc/platform_device/spi_dev.c | 163 >>> plat-sirfsoc/platform_device/spigpio_dev.c | 75 >>> plat-sirfsoc/platform_device/ts_stream_mode_dev.c | 64 >>> plat-sirfsoc/platform_device/usb_dev.c | 120 >>> plat-sirfsoc/platform_device/usppcm_dev.c | 69 >>> plat-sirfsoc/platform_device/uspserial_dev.c | 197 + >>> plat-sirfsoc/platform_device/uspspi_dev.c | 97 >>> plat-sirfsoc/platform_device/vpp_dev.c | 70 >>> plat-sirfsoc/platform_device/vxd_dev.c | 68 >>> plat-sirfsoc/platform_device/wdt_dev.c | 41 >> >> These will probably all get replaced with device tree bindings. > > good. > >> >>> plat-sirfsoc/include/plat/pm.h | 41 >>> plat-sirfsoc/include/plat/pwm.h | 63 >>> plat-sirfsoc/include/plat/regs-clkc.h | 33 >>> plat-sirfsoc/include/plat/regs-gpio.h | 43 >>> plat-sirfsoc/include/plat/regs-irq.h | 39 >>> plat-sirfsoc/include/plat/regs-modac.h | 114 >>> plat-sirfsoc/include/plat/regs-power.h | 77 >>> plat-sirfsoc/include/plat/regs-pwm.h | 37 >>> plat-sirfsoc/include/plat/regs-pwrc.h | 62 >>> plat-sirfsoc/include/plat/regs-reset.h | 73 >>> plat-sirfsoc/include/plat/regs-rsc.h | 78 >>> plat-sirfsoc/include/plat/regs-rtc.h | 41 >>> plat-sirfsoc/include/plat/regs-serial.h | 87 >>> plat-sirfsoc/include/plat/regs-timer.h | 39 >>> plat-sirfsoc/include/plat/regs-vip.h | 98 >>> plat-sirfsoc/include/plat/sd.h | 110 >>> plat-sirfsoc/include/plat/sirfsoc_adc.h | 261 + >>> plat-sirfsoc/include/plat/sirfsoc_usp.h | 288 + >> >> And these can hopefully all get moved next to the respective drivers. > > good. > >> >>> plat-sirfsoc/include/plat/system.h | 39 >>> plat-sirfsoc/include/plat/timex.h | 33 >>> plat-sirfsoc/include/plat/uncompress.h | 46 >>> plat-sirfsoc/include/plat/vmalloc.h | 26 >>> plat-sirfsoc/irq.c | 102 >>> plat-sirfsoc/lcd_panels.c | 281 + >>> plat-sirfsoc/led.c | 340 + >>> plat-sirfsoc/perfmon.c | 1347 +++++++ >> >> For the perfmon implementation, I would recommend splitting it out of the >> submission at the beginning. If it's based on perf, it should be easy to >> add at a later stage. Otherwise, it's not going anywhere. If it's related >> to the ARM system trace macrocell, I'd recommend posting the code now >> (independent of the rest), because other people are interested in getting >> that to work. > sorry for not exculding this file in diff. > perfmon is a IP included by our old atlas5 and doesn't exist in > prima2, which exports bus bandwidth and latency. it is not related > with STM. and it is not based on perf too. people wrote this driver a > long time ago and simply exported some registers to userspace by proc. > it should not be in our final patches. > >> >>> plat-sirfsoc/pinmux.c | 992 +++++ >> >> -> pinmux subsystem >> >>> for drivers/: >>> Kconfig | 2 >>> Makefile | 1 >>> char/sirfsoc_gps.c | 878 +++++++++++++ >>> char/sirfsoc_gpsdrv.h | 134 + >>> input/misc/gpio_event.c | 253 +++ >> >> A new user space interface is always hard to establish. If you want these >> to get in, you should start way ahead of the other drivers that simply >> implement an existing interface. >> >> If the gps driver is just a tty device like a serial port, it should >> now be moved into drivers/tty. > > most GPS are /dev/ttySn to userspace, they are connected to SoC by > uart. DSP is one of CSR's main product lines. An internal DSP in SoC sorry for typo. *GPS* is one of CSR's main product lines. > handles GPS and we use this driver to communicate with the DSP. i will > take a look whether we can have better framework than a simple char > device. > >> >>> nanddisk/Kconfig | 17 >>> nanddisk/Makefile | 5 >>> nanddisk/nand.c | 937 +++++++++++++ >>> nanddisk/nanddisk.h | 702 ++++++++++ >> >> How does this relate to drivers/mtd? > > that is a big issue to upstream. CSR built a NTFL supporting both > WINCE/Linux with good performance and proved reliable products. the > NTFL is a binary. NAND disk is a up level block driver to call API in > the NTFL binary. > that makes the NAND related codes very difficult to be accepted since > it is completely not based on MTD. i hope we can also have a MTD based > driver and compare the performance of UBI on MTD and current > solution. > >> >>> net/dm9000.c | 290 +--- >>> net/dm9000.h | 8 >> >> Ah, code removal ;-) > > sure. some guys hacked dm9000 to make it work on my debug board. but > it is unneccessary since we can modify related platform data in > arch/arm. > >> >>> video/Kconfig | 24 >>> video/Makefile | 2 >>> video/backlight/Makefile | 1 >>> video/sirfsoc_clcdc.h | 269 ++++ >>> video/sirfsoc_fb.c | 2369 +++++++++++++++++++++++++++++++++++ >>> video/sirfsoc_vpp.c | 1166 +++++++++++++++++ >> >> Have you considered doing a KMS device driver instead of an old-style >> frame buffer? > > it depends on the whole schedule and resources of the related teams. > i'd like to see the stronger KMS driver. > >> >>> i want to upstream steps by steps. send arch/arm patches for reviewing >>> at first, then clean-up drivers and send patches to subsystem for >>> reviewing. There are really too many issues waiting for refination in >>> arch/arm for the moment, we have more than 20 tasks for team to work. >> >> Ok, no problem. >> >> Arnd >> > -barry >
Powered by blists - more mailing lists