* CSR ARM SoC Subarchitecture preview
@ 2011-05-25 2:15 ` Barry Song
0 siblings, 0 replies; 12+ messages in thread
From: Barry Song @ 2011-05-25 2:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Nicolas Pitre, linux-arm-kernel, Linus Torvalds, Thomas Gleixner,
Russell King, lkml
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 20714 bytes --]
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@arndb.de>:
> On Tuesday 24 May 2011, Barry Song wrote:
>> 2011/5/19 Arnd Bergmann <arnd@arndb.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
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
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply [flat|nested] 12+ messages in thread
* CSR ARM SoC Subarchitecture preview
@ 2011-05-25 2:15 ` Barry Song
0 siblings, 0 replies; 12+ messages in thread
From: Barry Song @ 2011-05-25 2:15 UTC (permalink / raw)
To: linux-arm-kernel
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@arndb.de>:
> On Tuesday 24 May 2011, Barry Song wrote:
>> 2011/5/19 Arnd Bergmann <arnd@arndb.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
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CSR ARM SoC Subarchitecture preview
2011-05-25 2:15 ` Barry Song
@ 2011-05-25 2:24 ` Barry Song
-1 siblings, 0 replies; 12+ messages in thread
From: Barry Song @ 2011-05-25 2:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Nicolas Pitre, linux-arm-kernel, Linus Torvalds, Thomas Gleixner,
Russell King, lkml
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 21219 bytes --]
2011/5/25 Barry Song <21cnbao@gmail.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@arndb.de>:
>> On Tuesday 24 May 2011, Barry Song wrote:
>>> 2011/5/19 Arnd Bergmann <arnd@arndb.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
>
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply [flat|nested] 12+ messages in thread
* CSR ARM SoC Subarchitecture preview
@ 2011-05-25 2:24 ` Barry Song
0 siblings, 0 replies; 12+ messages in thread
From: Barry Song @ 2011-05-25 2:24 UTC (permalink / raw)
To: linux-arm-kernel
2011/5/25 Barry Song <21cnbao@gmail.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@arndb.de>:
>> On Tuesday 24 May 2011, Barry Song wrote:
>>> 2011/5/19 Arnd Bergmann <arnd@arndb.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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CSR ARM SoC Subarchitecture preview
2011-05-25 2:15 ` Barry Song
@ 2011-05-25 6:51 ` Arnd Bergmann
-1 siblings, 0 replies; 12+ messages in thread
From: Arnd Bergmann @ 2011-05-25 6:51 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Barry Song, Russell King, Nicolas Pitre, lkml, Thomas Gleixner,
Linus Torvalds
On Wednesday 25 May 2011 04:15:12 Barry Song wrote:
> >> 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.
Regarding platform data, the ideal case would be to not pass any,
and have the driver itself enquire the settings by looking at device
tree properties. There may be a few cases where that is not possible,
or where a callback into platform code ends up simplifying things
significantly, but that should stay the exception.
> > 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.
Ok, makes sense. It may be possible that after you have done all the
work to convert prima2 to device tree, it will become trivial to support
the older SoCs as well, but starting with prima2 as you say makes a lot
of sense.
> > 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.
I see. Note that in the long run, we definitely want to have the option
to build kernel binaries across different SoC families. It would be
good to make sure you don't have arbitrary differences in the mach-*
implementation that get in the way of that later. If prima2 and atlas6
turn out very similar in the end, it may be best to fold all them together
with plat-sirfsoc into a single directory. E.g. the TI omap2/3/4
platforms have all been merged into mach-omap2, despite being
rather different.
> >> 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
> 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.
>From the little I know about GPS, the controllers have a fairly standardized
serial port interface even across vendors. It would be good to be
compatible with the existing ones there, e.g. bluetooth or serial GPS that
all provide a tty interface. If your's is very different and has a
high-level API, you might want to create a new drivers/gps/ subsystem
with an architected user interface that works with both your own
implementation and the serial ones.
Turning a tty into a high-level interface is normally done using a new tty
line discipline, similar to how PPP or CAN work over serial lines.
> >> 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.
Ok, no need to forward port or submit that driver for inclusion then.
> 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.
Right, an MTD driver would be required for anyone to build products
with the mainline kernel, so that sounds like an important thing to
do. Comparing performance is also always good, so if you find that
UBI or the FTL in the kernel are lacking there, the MTD maintainers
will definitely want to know about that.
> >> 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.
There is definitely a trend towards KMS drivers, but no clear mandate yet.
If you wait long enough, you may not have the choice any more as soon
as KMS becomes a requirement for new display drivers.
Arnd
^ permalink raw reply [flat|nested] 12+ messages in thread
* CSR ARM SoC Subarchitecture preview
@ 2011-05-25 6:51 ` Arnd Bergmann
0 siblings, 0 replies; 12+ messages in thread
From: Arnd Bergmann @ 2011-05-25 6:51 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 25 May 2011 04:15:12 Barry Song wrote:
> >> 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.
Regarding platform data, the ideal case would be to not pass any,
and have the driver itself enquire the settings by looking at device
tree properties. There may be a few cases where that is not possible,
or where a callback into platform code ends up simplifying things
significantly, but that should stay the exception.
> > 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.
Ok, makes sense. It may be possible that after you have done all the
work to convert prima2 to device tree, it will become trivial to support
the older SoCs as well, but starting with prima2 as you say makes a lot
of sense.
> > 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.
I see. Note that in the long run, we definitely want to have the option
to build kernel binaries across different SoC families. It would be
good to make sure you don't have arbitrary differences in the mach-*
implementation that get in the way of that later. If prima2 and atlas6
turn out very similar in the end, it may be best to fold all them together
with plat-sirfsoc into a single directory. E.g. the TI omap2/3/4
platforms have all been merged into mach-omap2, despite being
rather different.
> >> 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
> 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.
>From the little I know about GPS, the controllers have a fairly standardized
serial port interface even across vendors. It would be good to be
compatible with the existing ones there, e.g. bluetooth or serial GPS that
all provide a tty interface. If your's is very different and has a
high-level API, you might want to create a new drivers/gps/ subsystem
with an architected user interface that works with both your own
implementation and the serial ones.
Turning a tty into a high-level interface is normally done using a new tty
line discipline, similar to how PPP or CAN work over serial lines.
> >> 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.
Ok, no need to forward port or submit that driver for inclusion then.
> 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.
Right, an MTD driver would be required for anyone to build products
with the mainline kernel, so that sounds like an important thing to
do. Comparing performance is also always good, so if you find that
UBI or the FTL in the kernel are lacking there, the MTD maintainers
will definitely want to know about that.
> >> 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.
There is definitely a trend towards KMS drivers, but no clear mandate yet.
If you wait long enough, you may not have the choice any more as soon
as KMS becomes a requirement for new display drivers.
Arnd
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CSR ARM SoC Subarchitecture preview
2011-05-25 6:51 ` Arnd Bergmann
@ 2011-05-26 15:17 ` Barry Song
-1 siblings, 0 replies; 12+ messages in thread
From: Barry Song @ 2011-05-26 15:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Russell King, Nicolas Pitre, lkml,
Thomas Gleixner, Linus Torvalds
Hi Arnd,
2011/5/25 Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 25 May 2011 04:15:12 Barry Song wrote:
>
>> >> 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.
>
> Regarding platform data, the ideal case would be to not pass any,
> and have the driver itself enquire the settings by looking at device
> tree properties. There may be a few cases where that is not possible,
> or where a callback into platform code ends up simplifying things
> significantly, but that should stay the exception.
really. some hardware-related callbacks are now in arch and make
driver codes simpler and better to cross platform without considering
trivial hardware details.
if they are moved to drivers, the drivers will be very ugly with things like:
#ifdef BOARD_X
....
#elif defined(BOARD_Y)
...
#endif
that is not what people want.
so a temp way is maybe providing funtions in arch as exported symbols
which will be called by drivers. different boards implement them in
different codes.
>
>> > 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.
>
> Ok, makes sense. It may be possible that after you have done all the
> work to convert prima2 to device tree, it will become trivial to support
> the older SoCs as well, but starting with prima2 as you say makes a lot
> of sense.
debugging device tree in prima2 now.
>
>> > 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.
>
> I see. Note that in the long run, we definitely want to have the option
> to build kernel binaries across different SoC families. It would be
> good to make sure you don't have arbitrary differences in the mach-*
> implementation that get in the way of that later. If prima2 and atlas6
> turn out very similar in the end, it may be best to fold all them together
> with plat-sirfsoc into a single directory. E.g. the TI omap2/3/4
> platforms have all been merged into mach-omap2, despite being
> rather different.
most components of prima2 and atlas6 are similar. i agree we can begin
by a mach-prima2 dir to cover both and delete plat-sirfsoc. looking
whether some day we need a plat-sirfsoc.
>
>> >> 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
>> 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.
>
> From the little I know about GPS, the controllers have a fairly standardized
> serial port interface even across vendors. It would be good to be
> compatible with the existing ones there, e.g. bluetooth or serial GPS that
> all provide a tty interface. If your's is very different and has a
> high-level API, you might want to create a new drivers/gps/ subsystem
> with an architected user interface that works with both your own
> implementation and the serial ones.
> Turning a tty into a high-level interface is normally done using a new tty
> line discipline, similar to how PPP or CAN work over serial lines.
yes. gps generally is an external module connected to SoC's uart.
actually, the char device we are talking is more like firmware inside
a common gps module. it is in lower level than an external interface.
anyway, csr is a company with gps technology. i'd like to figure out
whether we can provide a generic framework.
>
>> >> 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.
>
> Ok, no need to forward port or submit that driver for inclusion then.
>
>> 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.
>
> Right, an MTD driver would be required for anyone to build products
> with the mainline kernel, so that sounds like an important thing to
> do. Comparing performance is also always good, so if you find that
> UBI or the FTL in the kernel are lacking there, the MTD maintainers
> will definitely want to know about that.
sure.
>
>> >> 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.
>
> There is definitely a trend towards KMS drivers, but no clear mandate yet.
> If you wait long enough, you may not have the choice any more as soon
> as KMS becomes a requirement for new display drivers.
thanks! definitely that's what we want to follow.
>
> Arnd
>
-barry
^ permalink raw reply [flat|nested] 12+ messages in thread
* CSR ARM SoC Subarchitecture preview
@ 2011-05-26 15:17 ` Barry Song
0 siblings, 0 replies; 12+ messages in thread
From: Barry Song @ 2011-05-26 15:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
2011/5/25 Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 25 May 2011 04:15:12 Barry Song wrote:
>
>> >> ?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.
>
> Regarding platform data, the ideal case would be to not pass any,
> and have the driver itself enquire the settings by looking at device
> tree properties. There may be a few cases where that is not possible,
> or where a callback into platform code ends up simplifying things
> significantly, but that should stay the exception.
really. some hardware-related callbacks are now in arch and make
driver codes simpler and better to cross platform without considering
trivial hardware details.
if they are moved to drivers, the drivers will be very ugly with things like:
#ifdef BOARD_X
....
#elif defined(BOARD_Y)
...
#endif
that is not what people want.
so a temp way is maybe providing funtions in arch as exported symbols
which will be called by drivers. different boards implement them in
different codes.
>
>> > 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.
>
> Ok, makes sense. It may be possible that after you have done all the
> work to convert prima2 to device tree, it will become trivial to support
> the older SoCs as well, but starting with prima2 as you say makes a lot
> of sense.
debugging device tree in prima2 now.
>
>> > 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.
>
> I see. Note that in the long run, we definitely want to have the option
> to build kernel binaries across different SoC families. It would be
> good to make sure you don't have arbitrary differences in the mach-*
> implementation that get in the way of that later. If prima2 and atlas6
> turn out very similar in the end, it may be best to fold all them together
> with plat-sirfsoc into a single directory. E.g. the TI omap2/3/4
> platforms have all been merged into mach-omap2, despite being
> rather different.
most components of prima2 and atlas6 are similar. i agree we can begin
by a mach-prima2 dir to cover both and delete plat-sirfsoc. looking
whether some day we need a plat-sirfsoc.
>
>> >> 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
>> 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.
>
> From the little I know about GPS, the controllers have a fairly standardized
> serial port interface even across vendors. It would be good to be
> compatible with the existing ones there, e.g. bluetooth or serial GPS that
> all provide a tty interface. If your's is very different and has a
> high-level API, you might want to create a new drivers/gps/ subsystem
> with an architected user interface that works with both your own
> implementation and the serial ones.
> Turning a tty into a high-level interface is normally done using a new tty
> line discipline, similar to how PPP or CAN work over serial lines.
yes. gps generally is an external module connected to SoC's uart.
actually, the char device we are talking is more like firmware inside
a common gps module. it is in lower level than an external interface.
anyway, csr is a company with gps technology. i'd like to figure out
whether we can provide a generic framework.
>
>> >> ?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.
>
> Ok, no need to forward port or submit that driver for inclusion then.
>
>> 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.
>
> Right, an MTD driver would be required for anyone to build products
> with the mainline kernel, so that sounds like an important thing to
> do. Comparing performance is also always good, so if you find that
> UBI or the FTL in the kernel are lacking there, the MTD maintainers
> will definitely want to know about that.
sure.
>
>> >> ?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.
>
> There is definitely a trend towards KMS drivers, but no clear mandate yet.
> If you wait long enough, you may not have the choice any more as soon
> as KMS becomes a requirement for new display drivers.
thanks! definitely that's what we want to follow.
>
> ? ? ? ?Arnd
>
-barry
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CSR ARM SoC Subarchitecture preview
2011-05-26 15:17 ` Barry Song
@ 2011-05-26 15:40 ` Arnd Bergmann
-1 siblings, 0 replies; 12+ messages in thread
From: Arnd Bergmann @ 2011-05-26 15:40 UTC (permalink / raw)
To: Barry Song
Cc: linux-arm-kernel, Russell King, Nicolas Pitre, lkml,
Thomas Gleixner, Linus Torvalds
On Thursday 26 May 2011, Barry Song wrote:
> 2011/5/25 Arnd Bergmann <arnd@arndb.de>:
> > On Wednesday 25 May 2011 04:15:12 Barry Song wrote:
> >
> > Regarding platform data, the ideal case would be to not pass any,
> > and have the driver itself enquire the settings by looking at device
> > tree properties. There may be a few cases where that is not possible,
> > or where a callback into platform code ends up simplifying things
> > significantly, but that should stay the exception.
> really. some hardware-related callbacks are now in arch and make
> driver codes simpler and better to cross platform without considering
> trivial hardware details.
> if they are moved to drivers, the drivers will be very ugly with things like:
> #ifdef BOARD_X
> ....
> #elif defined(BOARD_Y)
> ...
> #endif
> that is not what people want.
>
> so a temp way is maybe providing funtions in arch as exported symbols
> which will be called by drivers. different boards implement them in
> different codes.
We really need to look at this case-by-case. The #ifdef mess you cited
is of course not acceptable, but that my feeling is that in most cases
we can find a much nicer solution. It depends of course on what code
gets run in the board specific fixup.
> > From the little I know about GPS, the controllers have a fairly standardized
> > serial port interface even across vendors. It would be good to be
> > compatible with the existing ones there, e.g. bluetooth or serial GPS that
> > all provide a tty interface. If your's is very different and has a
> > high-level API, you might want to create a new drivers/gps/ subsystem
> > with an architected user interface that works with both your own
> > implementation and the serial ones.
> > Turning a tty into a high-level interface is normally done using a new tty
> > line discipline, similar to how PPP or CAN work over serial lines.
>
> yes. gps generally is an external module connected to SoC's uart.
> actually, the char device we are talking is more like firmware inside
> a common gps module. it is in lower level than an external interface.
> anyway, csr is a company with gps technology. i'd like to figure out
> whether we can provide a generic framework.
Great! I think many people would appreciate that.
This may actually be as easy as providing a new line discipline with
very simple ioctls (e.g. GPSIO_GET_CURRENT_POSSITION).
Arnd
^ permalink raw reply [flat|nested] 12+ messages in thread
* CSR ARM SoC Subarchitecture preview
@ 2011-05-26 15:40 ` Arnd Bergmann
0 siblings, 0 replies; 12+ messages in thread
From: Arnd Bergmann @ 2011-05-26 15:40 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 26 May 2011, Barry Song wrote:
> 2011/5/25 Arnd Bergmann <arnd@arndb.de>:
> > On Wednesday 25 May 2011 04:15:12 Barry Song wrote:
> >
> > Regarding platform data, the ideal case would be to not pass any,
> > and have the driver itself enquire the settings by looking at device
> > tree properties. There may be a few cases where that is not possible,
> > or where a callback into platform code ends up simplifying things
> > significantly, but that should stay the exception.
> really. some hardware-related callbacks are now in arch and make
> driver codes simpler and better to cross platform without considering
> trivial hardware details.
> if they are moved to drivers, the drivers will be very ugly with things like:
> #ifdef BOARD_X
> ....
> #elif defined(BOARD_Y)
> ...
> #endif
> that is not what people want.
>
> so a temp way is maybe providing funtions in arch as exported symbols
> which will be called by drivers. different boards implement them in
> different codes.
We really need to look at this case-by-case. The #ifdef mess you cited
is of course not acceptable, but that my feeling is that in most cases
we can find a much nicer solution. It depends of course on what code
gets run in the board specific fixup.
> > From the little I know about GPS, the controllers have a fairly standardized
> > serial port interface even across vendors. It would be good to be
> > compatible with the existing ones there, e.g. bluetooth or serial GPS that
> > all provide a tty interface. If your's is very different and has a
> > high-level API, you might want to create a new drivers/gps/ subsystem
> > with an architected user interface that works with both your own
> > implementation and the serial ones.
> > Turning a tty into a high-level interface is normally done using a new tty
> > line discipline, similar to how PPP or CAN work over serial lines.
>
> yes. gps generally is an external module connected to SoC's uart.
> actually, the char device we are talking is more like firmware inside
> a common gps module. it is in lower level than an external interface.
> anyway, csr is a company with gps technology. i'd like to figure out
> whether we can provide a generic framework.
Great! I think many people would appreciate that.
This may actually be as easy as providing a new line discipline with
very simple ioctls (e.g. GPSIO_GET_CURRENT_POSSITION).
Arnd
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CSR ARM SoC Subarchitecture preview
2011-05-26 15:40 ` Arnd Bergmann
@ 2011-05-30 14:56 ` Barry Song
-1 siblings, 0 replies; 12+ messages in thread
From: Barry Song @ 2011-05-30 14:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Russell King, Nicolas Pitre, lkml,
Thomas Gleixner, Linus Torvalds
2011/5/26 Arnd Bergmann <arnd@arndb.de>:
> On Thursday 26 May 2011, Barry Song wrote:
>> 2011/5/25 Arnd Bergmann <arnd@arndb.de>:
>> > On Wednesday 25 May 2011 04:15:12 Barry Song wrote:
>> >
>> > Regarding platform data, the ideal case would be to not pass any,
>> > and have the driver itself enquire the settings by looking at device
>> > tree properties. There may be a few cases where that is not possible,
>> > or where a callback into platform code ends up simplifying things
>> > significantly, but that should stay the exception.
>> really. some hardware-related callbacks are now in arch and make
>> driver codes simpler and better to cross platform without considering
>> trivial hardware details.
>> if they are moved to drivers, the drivers will be very ugly with things like:
>> #ifdef BOARD_X
>> ....
>> #elif defined(BOARD_Y)
>> ...
>> #endif
>> that is not what people want.
>>
>> so a temp way is maybe providing funtions in arch as exported symbols
>> which will be called by drivers. different boards implement them in
>> different codes.
>
> We really need to look at this case-by-case. The #ifdef mess you cited
> is of course not acceptable, but that my feeling is that in most cases
> we can find a much nicer solution. It depends of course on what code
> gets run in the board specific fixup.
>
>> > From the little I know about GPS, the controllers have a fairly standardized
>> > serial port interface even across vendors. It would be good to be
>> > compatible with the existing ones there, e.g. bluetooth or serial GPS that
>> > all provide a tty interface. If your's is very different and has a
>> > high-level API, you might want to create a new drivers/gps/ subsystem
>> > with an architected user interface that works with both your own
>> > implementation and the serial ones.
>> > Turning a tty into a high-level interface is normally done using a new tty
>> > line discipline, similar to how PPP or CAN work over serial lines.
>>
>> yes. gps generally is an external module connected to SoC's uart.
>> actually, the char device we are talking is more like firmware inside
>> a common gps module. it is in lower level than an external interface.
>> anyway, csr is a company with gps technology. i'd like to figure out
>> whether we can provide a generic framework.
>
> Great! I think many people would appreciate that.
>
> This may actually be as easy as providing a new line discipline with
> very simple ioctls (e.g. GPSIO_GET_CURRENT_POSSITION).
yes. i believe that makes more senses than a simple char-based device
or misc device. the internal gps can still show as a /dev/ttyGPS or
something with a new ldisc.
>
> Arnd
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* CSR ARM SoC Subarchitecture preview
@ 2011-05-30 14:56 ` Barry Song
0 siblings, 0 replies; 12+ messages in thread
From: Barry Song @ 2011-05-30 14:56 UTC (permalink / raw)
To: linux-arm-kernel
2011/5/26 Arnd Bergmann <arnd@arndb.de>:
> On Thursday 26 May 2011, Barry Song wrote:
>> 2011/5/25 Arnd Bergmann <arnd@arndb.de>:
>> > On Wednesday 25 May 2011 04:15:12 Barry Song wrote:
>> >
>> > Regarding platform data, the ideal case would be to not pass any,
>> > and have the driver itself enquire the settings by looking at device
>> > tree properties. There may be a few cases where that is not possible,
>> > or where a callback into platform code ends up simplifying things
>> > significantly, but that should stay the exception.
>> really. some hardware-related callbacks are now in arch and make
>> driver codes simpler and better to cross platform without considering
>> trivial hardware details.
>> if they are moved to drivers, the drivers will be very ugly with things like:
>> #ifdef BOARD_X
>> ....
>> #elif defined(BOARD_Y)
>> ...
>> #endif
>> that is not what people want.
>>
>> so a temp way is maybe providing funtions in arch as exported symbols
>> which will be called by drivers. different boards implement them in
>> different codes.
>
> We really need to look at this case-by-case. The #ifdef mess you cited
> is of course not acceptable, but that my feeling is that in most cases
> we can find a much nicer solution. It depends of course on what code
> gets run in the board specific fixup.
>
>> > From the little I know about GPS, the controllers have a fairly standardized
>> > serial port interface even across vendors. It would be good to be
>> > compatible with the existing ones there, e.g. bluetooth or serial GPS that
>> > all provide a tty interface. If your's is very different and has a
>> > high-level API, you might want to create a new drivers/gps/ subsystem
>> > with an architected user interface that works with both your own
>> > implementation and the serial ones.
>> > Turning a tty into a high-level interface is normally done using a new tty
>> > line discipline, similar to how PPP or CAN work over serial lines.
>>
>> yes. gps generally is an external module connected to SoC's uart.
>> actually, the char device we are talking is more like firmware inside
>> a common gps module. it is in lower level than an external interface.
>> anyway, csr is a company with gps technology. i'd like to figure out
>> whether we can provide a generic framework.
>
> Great! I think many people would appreciate that.
>
> This may actually be as easy as providing a new line discipline with
> very simple ioctls (e.g. GPSIO_GET_CURRENT_POSSITION).
yes. i believe that makes more senses than a simple char-based device
or misc device. the internal gps can still show as a /dev/ttyGPS or
something with a new ldisc.
>
> ? ? ? ?Arnd
>
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-05-30 14:56 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-25 2:15 CSR ARM SoC Subarchitecture preview Barry Song
2011-05-25 2:15 ` Barry Song
2011-05-25 2:24 ` Barry Song
2011-05-25 2:24 ` Barry Song
2011-05-25 6:51 ` Arnd Bergmann
2011-05-25 6:51 ` Arnd Bergmann
2011-05-26 15:17 ` Barry Song
2011-05-26 15:17 ` Barry Song
2011-05-26 15:40 ` Arnd Bergmann
2011-05-26 15:40 ` Arnd Bergmann
2011-05-30 14:56 ` Barry Song
2011-05-30 14:56 ` Barry Song
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.