Re: CSR ARM SoC Subarchitecture preview

[Barry Song]

2011/5/25 Barry Song <21cnbao@xxxxxxxxx>:
> 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@xxxxxxxx>:
>> On Tuesday 24 May 2011, Barry Song wrote:
>>> 2011/5/19 Arnd Bergmann <arnd@xxxxxxxx>
>>>
>>> > 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
>
¢éì®&Þ~º&¶¬–+-±éÝ¥Šw®žË±Êâmébžìdz¹Þ)í…æèw*jg¬±¨¶‰šŽŠÝj/êäz¹ÞŠà2ŠÞ¨è­Ú&¢)ß«a¶Úþø®G«éh®æj:+v‰¨Šwè†Ù>Wš±êÞiÛaxPjØm¶ŸÿÃ-»+ƒùdš_