Request for unicore32 architecture codes to merge into linux-next

Request for unicore32 architecture codes to merge into linux-next

[Guan Xuetao]

Hi,

I want to merge unicore32 repo into linux-next tree, the position is (unicore32 branch):
  git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git

Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
---
 MAINTAINERS                                   |    8 +
 arch/unicore32/.gitignore                     |   21 +
 arch/unicore32/Kconfig                        |  248 +++
 arch/unicore32/Kconfig.debug                  |   68 +
 arch/unicore32/Makefile                       |   97 ++
 arch/unicore32/boot/Makefile                  |   47 +
 arch/unicore32/boot/compressed/Makefile       |   68 +
 arch/unicore32/boot/compressed/head.S         |  204 +++
 arch/unicore32/boot/compressed/misc.c         |  126 ++
 arch/unicore32/boot/compressed/piggy.S.in     |    6 +
 arch/unicore32/boot/compressed/vmlinux.lds.in |   61 +
 arch/unicore32/configs/debug_defconfig        |  210 +++
 arch/unicore32/configs/nb0916_defconfig       |  202 +++
 arch/unicore32/include/asm/Kbuild             |    2 +
 arch/unicore32/include/asm/assembler.h        |  131 ++
 arch/unicore32/include/asm/bitops.h           |   47 +
 arch/unicore32/include/asm/byteorder.h        |   24 +
 arch/unicore32/include/asm/cache.h            |   27 +
 arch/unicore32/include/asm/cacheflush.h       |  211 +++
 arch/unicore32/include/asm/checksum.h         |   41 +
 arch/unicore32/include/asm/cpu-single.h       |   45 +
 arch/unicore32/include/asm/cputype.h          |   33 +
 arch/unicore32/include/asm/delay.h            |   52 +
 arch/unicore32/include/asm/dma-mapping.h      |  124 ++
 arch/unicore32/include/asm/dma.h              |   23 +
 arch/unicore32/include/asm/elf.h              |   94 ++
 arch/unicore32/include/asm/fpstate.h          |   26 +
 arch/unicore32/include/asm/fpu-ucf64.h        |   53 +
 arch/unicore32/include/asm/futex.h            |  143 ++
 arch/unicore32/include/asm/gpio.h             |  103 ++
 arch/unicore32/include/asm/hwcap.h            |   32 +
 arch/unicore32/include/asm/io.h               |   52 +
 arch/unicore32/include/asm/irq.h              |  107 ++
 arch/unicore32/include/asm/irqflags.h         |   53 +
 arch/unicore32/include/asm/linkage.h          |   22 +
 arch/unicore32/include/asm/memblock.h         |   46 +
 arch/unicore32/include/asm/memory.h           |  123 ++
 arch/unicore32/include/asm/mmu.h              |   17 +
 arch/unicore32/include/asm/mmu_context.h      |   87 +
 arch/unicore32/include/asm/mutex.h            |   20 +
 arch/unicore32/include/asm/page.h             |   80 +
 arch/unicore32/include/asm/pci.h              |   46 +
 arch/unicore32/include/asm/pgalloc.h          |  110 ++
 arch/unicore32/include/asm/pgtable-hwdef.h    |   55 +
 arch/unicore32/include/asm/pgtable.h          |  317 ++++
 arch/unicore32/include/asm/processor.h        |   92 ++
 arch/unicore32/include/asm/ptrace.h           |  176 +++
 arch/unicore32/include/asm/sigcontext.h       |   29 +
 arch/unicore32/include/asm/stacktrace.h       |   31 +
 arch/unicore32/include/asm/string.h           |   38 +
 arch/unicore32/include/asm/suspend.h          |   30 +
 arch/unicore32/include/asm/system.h           |  161 ++
 arch/unicore32/include/asm/thread_info.h      |  154 ++
 arch/unicore32/include/asm/timex.h            |   34 +
 arch/unicore32/include/asm/tlb.h              |   98 ++
 arch/unicore32/include/asm/tlbflush.h         |  195 +++
 arch/unicore32/include/asm/traps.h            |   21 +
 arch/unicore32/include/asm/uaccess.h          |   47 +
 arch/unicore32/include/asm/unistd.h           |   18 +
 arch/unicore32/include/mach/PKUnity.h         |  104 ++
 arch/unicore32/include/mach/bitfield.h        |   24 +
 arch/unicore32/include/mach/dma.h             |   41 +
 arch/unicore32/include/mach/hardware.h        |   45 +
 arch/unicore32/include/mach/map.h             |   20 +
 arch/unicore32/include/mach/memory.h          |   58 +
 arch/unicore32/include/mach/ocd.h             |   36 +
 arch/unicore32/include/mach/pm.h              |   43 +
 arch/unicore32/include/mach/regs-ac97.h       |   32 +
 arch/unicore32/include/mach/regs-dmac.h       |   81 +
 arch/unicore32/include/mach/regs-gpio.h       |   70 +
 arch/unicore32/include/mach/regs-i2c.h        |   63 +
 arch/unicore32/include/mach/regs-intc.h       |   28 +
 arch/unicore32/include/mach/regs-nand.h       |   79 +
 arch/unicore32/include/mach/regs-ost.h        |   92 ++
 arch/unicore32/include/mach/regs-pci.h        |   94 ++
 arch/unicore32/include/mach/regs-pm.h         |  126 ++
 arch/unicore32/include/mach/regs-ps2.h        |   20 +
 arch/unicore32/include/mach/regs-resetc.h     |   34 +
 arch/unicore32/include/mach/regs-rtc.h        |   37 +
 arch/unicore32/include/mach/regs-sdc.h        |  156 ++
 arch/unicore32/include/mach/regs-spi.h        |   98 ++
 arch/unicore32/include/mach/regs-uart.h       |    3 +
 arch/unicore32/include/mach/regs-umal.h       |  229 +++
 arch/unicore32/include/mach/regs-unigfx.h     |  200 +++
 arch/unicore32/include/mach/uncompress.h      |   34 +
 arch/unicore32/kernel/Makefile                |   34 +
 arch/unicore32/kernel/asm-offsets.c           |  112 ++
 arch/unicore32/kernel/clock.c                 |  388 +++++
 arch/unicore32/kernel/cpu-ucv2.c              |   93 ++
 arch/unicore32/kernel/debug-macro.S           |   89 ++
 arch/unicore32/kernel/debug.S                 |   85 +
 arch/unicore32/kernel/dma.c                   |  180 +++
 arch/unicore32/kernel/early_printk.c          |   59 +
 arch/unicore32/kernel/elf.c                   |   38 +
 arch/unicore32/kernel/entry.S                 |  824 ++++++++++
 arch/unicore32/kernel/fpu-ucf64.c             |  126 ++
 arch/unicore32/kernel/gpio.c                  |  122 ++
 arch/unicore32/kernel/head.S                  |  252 +++
 arch/unicore32/kernel/hibernate.c             |  160 ++
 arch/unicore32/kernel/hibernate_asm.S         |  117 ++
 arch/unicore32/kernel/init_task.c             |   44 +
 arch/unicore32/kernel/irq.c                   |  426 +++++
 arch/unicore32/kernel/ksyms.c                 |   99 ++
 arch/unicore32/kernel/ksyms.h                 |   15 +
 arch/unicore32/kernel/module.c                |  152 ++
 arch/unicore32/kernel/pci.c                   |  404 +++++
 arch/unicore32/kernel/pm.c                    |  123 ++
 arch/unicore32/kernel/process.c               |  389 +++++
 arch/unicore32/kernel/ptrace.c                |  598 +++++++
 arch/unicore32/kernel/puv3-core.c             |  260 ++++
 arch/unicore32/kernel/puv3-nb0916.c           |  175 +++
 arch/unicore32/kernel/puv3-smw0919.c          |  115 ++
 arch/unicore32/kernel/pwm.c                   |  263 ++++
 arch/unicore32/kernel/rtc.c                   |  380 +++++
 arch/unicore32/kernel/setup.c                 |  360 +++++
 arch/unicore32/kernel/setup.h                 |   30 +
 arch/unicore32/kernel/signal.c                |  494 ++++++
 arch/unicore32/kernel/sleep.S                 |  202 +++
 arch/unicore32/kernel/stacktrace.c            |  131 ++
 arch/unicore32/kernel/sys.c                   |  126 ++
 arch/unicore32/kernel/time.c                  |  148 ++
 arch/unicore32/kernel/traps.c                 |  333 ++++
 arch/unicore32/kernel/vmlinux.lds.S           |   61 +
 arch/unicore32/lib/Makefile                   |   27 +
 arch/unicore32/lib/backtrace.S                |  163 ++
 arch/unicore32/lib/clear_user.S               |   57 +
 arch/unicore32/lib/copy_from_user.S           |  108 ++
 arch/unicore32/lib/copy_page.S                |   39 +
 arch/unicore32/lib/copy_template.S            |  214 +++
 arch/unicore32/lib/copy_to_user.S             |   96 ++
 arch/unicore32/lib/delay.S                    |   51 +
 arch/unicore32/lib/findbit.S                  |   98 ++
 arch/unicore32/lib/strncpy_from_user.S        |   45 +
 arch/unicore32/lib/strnlen_user.S             |   42 +
 arch/unicore32/mm/Kconfig                     |   50 +
 arch/unicore32/mm/Makefile                    |   15 +
 arch/unicore32/mm/alignment.c                 |  523 +++++++
 arch/unicore32/mm/cache-ucv2.S                |  212 +++
 arch/unicore32/mm/dma-swiotlb.c               |   34 +
 arch/unicore32/mm/extable.c                   |   24 +
 arch/unicore32/mm/fault.c                     |  479 ++++++
 arch/unicore32/mm/flush.c                     |   98 ++
 arch/unicore32/mm/init.c                      |  517 ++++++
 arch/unicore32/mm/iomap.c                     |   56 +
 arch/unicore32/mm/ioremap.c                   |  261 ++++
 arch/unicore32/mm/mm.h                        |   39 +
 arch/unicore32/mm/mmu.c                       |  533 +++++++
 arch/unicore32/mm/pgd.c                       |  102 ++
 arch/unicore32/mm/proc-macros.S               |  145 ++
 arch/unicore32/mm/proc-syms.c                 |   23 +
 arch/unicore32/mm/proc-ucv2.S                 |  134 ++
 arch/unicore32/mm/tlb-ucv2.S                  |   89 ++
 drivers/input/keyboard/Kconfig                |   11 +
 drivers/input/keyboard/atkbd.c                |    4 +
 drivers/input/mouse/psmouse-base.c            |   41 +
 drivers/input/serio/i8042.h                   |    2 +
 drivers/pci/Makefile                          |    1 +
 drivers/staging/puv3/Kconfig                  |  125 ++
 drivers/staging/puv3/Makefile                 |   22 +
 drivers/staging/puv3/TODO                     |    7 +
 drivers/staging/puv3/i8042-ucio.h             |   89 ++
 drivers/staging/puv3/puv3-atkbd.h             |   43 +
 drivers/staging/puv3/puv3_ac97.c              |  369 +++++
 drivers/staging/puv3/puv3_i2c.c               |  309 ++++
 drivers/staging/puv3/puv3_pcm.c               |  435 ++++++
 drivers/staging/puv3/puv3_pcm.h               |   28 +
 drivers/staging/puv3/puv3_umal.c              | 2069 +++++++++++++++++++++++++
 drivers/staging/puv3/puv3_unifb.c             |  965 ++++++++++++
 include/asm-generic/ftrace.h                  |   16 +
 include/asm-generic/sizes.h                   |   47 +
 include/asm-generic/uaccess.h                 |    8 +-
 include/linux/fb.h                            |    2 +
 172 files changed, 23554 insertions(+), 3 deletions(-)

Re: Request for unicore32 architecture codes to merge into linux-next

[Dmitry Torokhov]

Hi,

On Sun, Jan 16, 2011 at 01:00:31AM +0800, Guan Xuetao wrote:
> Hi,
> 
> I want to merge unicore32 repo into linux-next tree, the position is (unicore32 branch):
>   git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git
> 

Have these changes been reviewed at all? Looking at the input parts I
doubt it... We try _really_ hard to avoid sprinkling arch #ifedefs in
the common code.

So, for input:

- how big is the difference between standard keytable and the one you
  are introducing? Looks like you are just adding 5 new keys that are
  not critical for booting. So please just update keymap from userpsace
  as we do for countless laptops and keyboards out there.

- Trying to enable mouse 1000 times can lead to loooong delays. Have
  you tried to figure out why you need the loop?

- What kind of mice can be connected to teh devices? I am concerned that
  your super-strict protocol checks will cause more harm then good (i do
  not believe they are valied in general case, overflow is just and
  additional bit).

Please split changes related into logically separated patches and post
them on linux-input@vger.kernel.org (along with linux-kernel if you
prefer) for review and comments.

Thanks.

-- 
Dmitry

RE: Request for unicore32 architecture codes to merge into linux-next

[Guan Xuetao]

> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Sunday, January 16, 2011 6:08 AM
> To: Guan Xuetao
> Cc: sfr@canb.auug.org.au; Arnd Bergmann; gregkh@suse.de; jbarnes@virtuousgeek.org; rubini@cvml.unipv.it; linux-
> arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-next@vger.kernel.org
> Subject: Re: Request for unicore32 architecture codes to merge into linux-next
> 
> Hi,
> 
> On Sun, Jan 16, 2011 at 01:00:31AM +0800, Guan Xuetao wrote:
> > Hi,
> >
> > I want to merge unicore32 repo into linux-next tree, the position is (unicore32 branch):
> >   git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git
> >
> 
> Have these changes been reviewed at all? Looking at the input parts I
> doubt it... We try _really_ hard to avoid sprinkling arch #ifedefs in
> the common code.
Many people helped me to review the patchset in linux-arch and linux-kernel mailist.
For ps2 driver, perhaps I should not introduce bugfix for the machine, so I remove the additional
modification, and only i8042 is necessary.
The patchset is rebased, and git dir and branch name remain the same.
Please update.
> 
> So, for input:
> 
> - how big is the difference between standard keytable and the one you
>   are introducing? Looks like you are just adding 5 new keys that are
>   not critical for booting. So please just update keymap from userpsace
>   as we do for countless laptops and keyboards out there.
I understand.
And I remove the keytable.

> 
> - Trying to enable mouse 1000 times can lead to loooong delays. Have
>   you tried to figure out why you need the loop?
> 
> - What kind of mice can be connected to teh devices? I am concerned that
>   your super-strict protocol checks will cause more harm then good (i do
>   not believe they are valied in general case, overflow is just and
>   additional bit).
> 
> Please split changes related into logically separated patches and post
> them on linux-input@vger.kernel.org (along with linux-kernel if you
> prefer) for review and comments.
> 
> Thanks.
> 
> --
> Dmitry

Thanks Dmitry.

Guan Xuetao

Re: Request for unicore32 architecture codes to merge into linux-next

[Paul Mundt]

On Sun, Jan 16, 2011 at 01:00:31AM +0800, Guan Xuetao wrote:
>  drivers/staging/puv3/Kconfig                  |  125 ++
>  drivers/staging/puv3/Makefile                 |   22 +
>  drivers/staging/puv3/TODO                     |    7 +
>  drivers/staging/puv3/i8042-ucio.h             |   89 ++
>  drivers/staging/puv3/puv3-atkbd.h             |   43 +
>  drivers/staging/puv3/puv3_ac97.c              |  369 +++++
>  drivers/staging/puv3/puv3_i2c.c               |  309 ++++
>  drivers/staging/puv3/puv3_pcm.c               |  435 ++++++
>  drivers/staging/puv3/puv3_pcm.h               |   28 +
>  drivers/staging/puv3/puv3_umal.c              | 2069 +++++++++++++++++++++++++
>  drivers/staging/puv3/puv3_unifb.c             |  965 ++++++++++++

Staging is not a shortcut around having things reviewed or broken out
logically. It's of course fine to merge the bulk of things in one go for
when a new architecture is going on, but logically disparate parts still
need to be broken out and sent to the proper places for review. It's
obvious you haven't done this for any of the non-arch bits and hiding
things under staging is not going to make this step any less necessary.

If you want your framebuffer driver reviewed, then split it out and
submit it to the linux-fbdev list for review. Once that's had a going
over and been Acked then of course it can be merged through whatever tree
you like, and there's even a good chance that you don't need to bother
with staging at all.

Using staging as a review circumvention measure however is just not going
to fly.

RE: Request for unicore32 architecture codes to merge into linux-next

[Guan Xuetao]

> -----Original Message-----
> From: Paul Mundt [mailto:lethal@linux-sh.org]
> Sent: Tuesday, January 18, 2011 12:33 PM
> To: Guan Xuetao
> Cc: sfr@canb.auug.org.au; Arnd Bergmann; gregkh@suse.de; jbarnes@virtuousgeek.org; dmitry.torokhov@gmail.com; dtor@mail.ru;
> rubini@cvml.unipv.it; linux-arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> next@vger.kernel.org
> Subject: Re: Request for unicore32 architecture codes to merge into linux-next
> 
> On Sun, Jan 16, 2011 at 01:00:31AM +0800, Guan Xuetao wrote:
> >  drivers/staging/puv3/Kconfig                  |  125 ++
> >  drivers/staging/puv3/Makefile                 |   22 +
> >  drivers/staging/puv3/TODO                     |    7 +
> >  drivers/staging/puv3/i8042-ucio.h             |   89 ++
> >  drivers/staging/puv3/puv3-atkbd.h             |   43 +
> >  drivers/staging/puv3/puv3_ac97.c              |  369 +++++
> >  drivers/staging/puv3/puv3_i2c.c               |  309 ++++
> >  drivers/staging/puv3/puv3_pcm.c               |  435 ++++++
> >  drivers/staging/puv3/puv3_pcm.h               |   28 +
> >  drivers/staging/puv3/puv3_umal.c              | 2069 +++++++++++++++++++++++++
> >  drivers/staging/puv3/puv3_unifb.c             |  965 ++++++++++++
> 
> Staging is not a shortcut around having things reviewed or broken out
> logically. It's of course fine to merge the bulk of things in one go for
> when a new architecture is going on, but logically disparate parts still
> need to be broken out and sent to the proper places for review. It's
> obvious you haven't done this for any of the non-arch bits and hiding
> things under staging is not going to make this step any less necessary.
> 
> If you want your framebuffer driver reviewed, then split it out and
> submit it to the linux-fbdev list for review. Once that's had a going
> over and been Acked then of course it can be merged through whatever tree
> you like, and there's even a good chance that you don't need to bother
> with staging at all.
> 
> Using staging as a review circumvention measure however is just not going
> to fly.
I understand.
IMO, the whole architecture specific codes need to be merged first, and only some
necessary drivers are included under staging. Then, I could split the staging drivers
into corresponding mail-list, and then, additional drivers.
Otherwise, there are no architecture basic for drivers review.

Thanks
Guan Xuetao

Re: Request for unicore32 architecture codes to merge into linux-next

[Paul Mundt]

On Tue, Jan 18, 2011 at 05:07:41PM +0800, Guan Xuetao wrote:
> IMO, the whole architecture specific codes need to be merged first, and only some
> necessary drivers are included under staging. Then, I could split the staging drivers
> into corresponding mail-list, and then, additional drivers.
> Otherwise, there are no architecture basic for drivers review.
> 
That's of course fine so long as the driver changes are reasonably
self-contained. The situation we want to avoid is that you end up with
drivers that depend on some private infrastructure of API where not
enough context is provided when the two are decoupled. 

In any event, the architecture bits are the most self-contained and have
had the most review of anything in this series of patches, so it probably
makes sense to work on getting those bits integrated and then dealing
with the rest incrementally.

RE: Request for unicore32 architecture codes to merge into linux-next

[Guan Xuetao]

> -----Original Message-----
> From: linux-next-owner@vger.kernel.org [mailto:linux-next-owner@vger.kernel.org] On Behalf Of Paul Mundt
> Sent: Tuesday, January 18, 2011 5:11 PM
> To: Guan Xuetao
> Cc: sfr@canb.auug.org.au; 'Arnd Bergmann'; gregkh@suse.de; jbarnes@virtuousgeek.org; dmitry.torokhov@gmail.com; dtor@mail.ru;
> rubini@cvml.unipv.it; linux-arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> next@vger.kernel.org
> Subject: Re: Request for unicore32 architecture codes to merge into linux-next
> 
> On Tue, Jan 18, 2011 at 05:07:41PM +0800, Guan Xuetao wrote:
> > IMO, the whole architecture specific codes need to be merged first, and only some
> > necessary drivers are included under staging. Then, I could split the staging drivers
> > into corresponding mail-list, and then, additional drivers.
> > Otherwise, there are no architecture basic for drivers review.
> >
> That's of course fine so long as the driver changes are reasonably
> self-contained. The situation we want to avoid is that you end up with
> drivers that depend on some private infrastructure of API where not
> enough context is provided when the two are decoupled.
> 
> In any event, the architecture bits are the most self-contained and have
> had the most review of anything in this series of patches, so it probably
> makes sense to work on getting those bits integrated and then dealing
> with the rest incrementally.
Then, I should:
1. merge reviewed arch dir and reviewed drivers (for now, i8042)
2. submit staging drivers to review
Am I right?

Thanks.
Guan Xuetao

Re: Request for unicore32 architecture codes to merge into linux-next

[Paul Mundt]

On Tue, Jan 18, 2011 at 05:33:44PM +0800, Guan Xuetao wrote:
> > -----Original Message-----
> > From: linux-next-owner@vger.kernel.org [mailto:linux-next-owner@vger.kernel.org] On Behalf Of Paul Mundt
> > Sent: Tuesday, January 18, 2011 5:11 PM
> > To: Guan Xuetao
> > Cc: sfr@canb.auug.org.au; 'Arnd Bergmann'; gregkh@suse.de; jbarnes@virtuousgeek.org; dmitry.torokhov@gmail.com; dtor@mail.ru;
> > rubini@cvml.unipv.it; linux-arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> > next@vger.kernel.org
> > Subject: Re: Request for unicore32 architecture codes to merge into linux-next
> > 
> > On Tue, Jan 18, 2011 at 05:07:41PM +0800, Guan Xuetao wrote:
> > > IMO, the whole architecture specific codes need to be merged first, and only some
> > > necessary drivers are included under staging. Then, I could split the staging drivers
> > > into corresponding mail-list, and then, additional drivers.
> > > Otherwise, there are no architecture basic for drivers review.
> > >
> > That's of course fine so long as the driver changes are reasonably
> > self-contained. The situation we want to avoid is that you end up with
> > drivers that depend on some private infrastructure of API where not
> > enough context is provided when the two are decoupled.
> > 
> > In any event, the architecture bits are the most self-contained and have
> > had the most review of anything in this series of patches, so it probably
> > makes sense to work on getting those bits integrated and then dealing
> > with the rest incrementally.
> Then, I should:
> 1. merge reviewed arch dir and reviewed drivers (for now, i8042)
> 2. submit staging drivers to review
> Am I right?
> 
That would at least make it easier to get parts of it merged while the
drivers get reviewed and reworked. If enough people are content with the
state of the architecture patches then there is no reason why they can't
be pulled in to -next once it's open for .39 changes. The drivers can
then gradually find their way in to -next via subsystem trees.

>From my point of view (though I don't believe I'm a minority in this),
staging/ in general should be a last resort for new drivers. Since you
are at least actively replying and making changes that have been
requested, there should really be no need to go the staging route for
any of the drivers at all.

On the other hand, if it turns out you have a big chunk of crazed and
incomprehensible infrastructure like an interpreter or something equally
perverse in the middle somewhere that everything depends on, that does of
course complicate things and limit your options somewhat, but those sorts
of things are hopefully corner cases (I admit the fact that you're
linking libc in to the kernel has rather scared me away from reviewing
the rest of the patches under closer scrutiny). Your goal in general
should be to avoid staging completely and submit small logically isolated
components that can be reviewed and merged wholly independently of
anything else.

Re: Request for unicore32 architecture codes to merge into linux-next

[Konrad Rzeszutek Wilk]

On Sun, Jan 16, 2011 at 01:00:31AM +0800, Guan Xuetao wrote:
> Hi,
> 
> I want to merge unicore32 repo into linux-next tree, the position is (unicore32 branch):
>   git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git

Where can one purchase this hardware for testing?

RE: Request for unicore32 architecture codes to merge into linux-next

[Guan Xuetao]

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Wednesday, January 19, 2011 2:33 AM
> To: Guan Xuetao
> Cc: sfr@canb.auug.org.au; Arnd Bergmann; gregkh@suse.de; jbarnes@virtuousgeek.org; dmitry.torokhov@gmail.com; dtor@mail.ru;
> rubini@cvml.unipv.it; linux-arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> next@vger.kernel.org
> Subject: Re: Request for unicore32 architecture codes to merge into linux-next
> 
> On Sun, Jan 16, 2011 at 01:00:31AM +0800, Guan Xuetao wrote:
> > Hi,
> >
> > I want to merge unicore32 repo into linux-next tree, the position is (unicore32 branch):
> >   git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git
> 
> Where can one purchase this hardware for testing?
Please contact our company:
  http://www.pkunity.com/english%20version/engcontact.htm

Guan Xuetao

Re: Request for unicore32 architecture codes to merge into linux-next

[Jesse Barnes]

On Sun, 16 Jan 2011 01:00:31 +0800
"Guan Xuetao" <guanxuetao@mprc.pku.edu.cn> wrote:

> Hi,
> 
> I want to merge unicore32 repo into linux-next tree, the position is (unicore32 branch):
>   git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git
> 
> Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
> ---

Took a quick look at the PCI parts, looks like you have a pretty big
DMA restriction.

You could provide your own dma map ops and make the allocator a bit
smarter about where it gets memory (preferentially allocating from the
DMA'able region, which you could hide).  Or do you find that swiotlb
does ok in general?

Other than that you had pretty tiny bits of enabling code, I assume
they work on your platform (config space access & setup, etc.).

-- 
Jesse Barnes, Intel Open Source Technology Center

RE: Request for unicore32 architecture codes to merge into linux-next

[Guan Xuetao]

> -----Original Message-----
> From: Jesse Barnes [mailto:jbarnes@virtuousgeek.org]
> Sent: Friday, January 21, 2011 3:42 AM
> To: Guan Xuetao
> Cc: sfr@canb.auug.org.au; Arnd Bergmann; gregkh@suse.de; dmitry.torokhov@gmail.com; dtor@mail.ru; rubini@cvml.unipv.it; linux-
> arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-next@vger.kernel.org
> Subject: Re: Request for unicore32 architecture codes to merge into linux-next
> 
> On Sun, 16 Jan 2011 01:00:31 +0800
> "Guan Xuetao" <guanxuetao@mprc.pku.edu.cn> wrote:
> 
> > Hi,
> >
> > I want to merge unicore32 repo into linux-next tree, the position is (unicore32 branch):
> >   git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git
> >
> > Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
> > ---
> 
> Took a quick look at the PCI parts, looks like you have a pretty big
> DMA restriction.
Yes, only 128MB low memory could be used as dma space for pci devices.
> 
> You could provide your own dma map ops and make the allocator a bit
> smarter about where it gets memory (preferentially allocating from the
> DMA'able region, which you could hide).  Or do you find that swiotlb
> does ok in general?
Swiotlb works well. For almost all functions are provided by IPs inside the SoC,
the dma function is used mainly through amba/axi bus,  not pci bus.

> 
> Other than that you had pretty tiny bits of enabling code, I assume
> they work on your platform (config space access & setup, etc.).
Yes.
> 
> --
> Jesse Barnes, Intel Open Source Technology Center
Thanks Jesse

Guan Xuetao