[PATCH] ARM: mach-moxart: platform port for MOXA ART SoC

[PATCH] ARM: mach-moxart: platform port for MOXA ART SoC

[Jonas Jensen]

Hi,

I ask for feedback and to submit (if possible) a new ARM SoC platform
port. This is now near complete (I think) (tested on UC-7112-LX Plus)
and applies to 2.6.34.14.

The patch contains the following drivers and platform specific implementations:

* ARCH_MOXART (FA526 processor)
* 100Hz interrupt timer
* UART
* MTD map driver
* Ethernet driver (RTL8201CP)
* MMC driver
* MOXA Smartio/Industio family multiport serial driver
* RTC driver
* Watchdog driver
* GPIO driver

Predicted patch rejects below (in need of a solution, feedback is much
appreciated) because they are critical in areas of boot, MMC and TTY.

arch/arm/boot/compressed/head.S:
A valid (and unique) architecture ID is not loaded to r1. Looks like
the bootloader is broken, it should be doing this!
http://gicl.cs.drexel.edu/people/sevy/linux/ARM_Linux_boot_sequence.html

arch/arm/tools/mach-types:
Omitted (do not edit manually / add a new machine using
http://www.arm.linux.org.uk/developer/machines/?action=new). A fix to
this and above is not feasible as long as MOXA withholds bootloader
sources (requested without success).

drivers/char/mxser.c drivers/char/mxser.h: MOXA
SMARTIO/INDUSTIO/INTELLIO SERIAL CARD (Jiří Slabý):
Force board setup for CONFIG_ARCH_MOXART.
ASYNCB_CLOSING is avoided because of a lockup (infinite wait after
tty_wait_until_sent). Why this happens is unknown (to me) I'm hoping
someone (Jiří?) can shed light. SysRq trace @ http://ideone.com/e845mr
What significance does ASYNCB_CLOSING have?
Obviously, automatic detection is better but "mxser_read_register" is
pointless on this hardware. What to do instead? Is it better to make a
copy and submit a new driver?

drivers/mmc/core/sd.c:
The MMC controller is "special"? "UNSTUFF_BITS" is redefined here
http://repo.or.cz/w/linux-2.6.19-moxart.git/blob/50cdf2c57662f9f69c5615976412f76bfd73311a:/drivers/mmc/mmc.c
. Without the new macro it'll report the wrong geometry and prod_name.
I'm thinking a driver should never have to redefine UNSTUFF_BITS.
Possible workaround: modify bits (in driver) to line up as expected
before returning the response (mmc_request_done).


For reference, this is my previous post from a few months back:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137130.html

Gitweb: http://repo.or.cz/w/linux-2.6.34.14-moxart.git/commitdiff/?h=3bc2e98ebb92961e1c5992736186920cd070f4ee&hp=b7f1d43323eceb02fd663a71eb2f8be9c17e6740

Download link (size: 193K):
https://linux-2-6-34-14-moxart.googlecode.com/files/linux-2.6.34.14-moxart.patch

Re: [PATCH] ARM: mach-moxart: platform port for MOXA ART SoC

[Daniel Mack]

Hi Jonas,

On 13.03.2013 16:37, Jonas Jensen wrote:
> I ask for feedback and to submit (if possible) a new ARM SoC platform
> port. This is now near complete (I think) (tested on UC-7112-LX Plus)
> and applies to 2.6.34.14.

First of all - thanks for submitting to the upstream kernel!

However, your patch has many severe problems which you need to address.

* please rebase your work. 2.6.34 is almost three years old now. 3.9 is
in it's stabilisation phase, and all new support has to be done for 3.10.
* all new platforms must be written with device-tree support
* all drivers must have device-tree support as well

> The patch contains the following drivers and platform specific
implementations:
>
> * ARCH_MOXART (FA526 processor)
> * 100Hz interrupt timer
> * UART
> * MTD map driver
> * Ethernet driver (RTL8201CP)
> * MMC driver
> * MOXA Smartio/Industio family multiport serial driver
> * RTC driver
> * Watchdog driver
> * GPIO driver

Never send one big patch but series of smaller ones, so the individual
subsystem maintainers can review and approve their bits.

Please also read Documentation/SubmittingPatches for a lot more
information about this subject.


Best regards,
Daniel



> Predicted patch rejects below (in need of a solution, feedback is much
> appreciated) because they are critical in areas of boot, MMC and TTY.
> 
> arch/arm/boot/compressed/head.S:
> A valid (and unique) architecture ID is not loaded to r1. Looks like
> the bootloader is broken, it should be doing this!
> http://gicl.cs.drexel.edu/people/sevy/linux/ARM_Linux_boot_sequence.html
> 
> arch/arm/tools/mach-types:
> Omitted (do not edit manually / add a new machine using
> http://www.arm.linux.org.uk/developer/machines/?action=new). A fix to
> this and above is not feasible as long as MOXA withholds bootloader
> sources (requested without success).
> 
> drivers/char/mxser.c drivers/char/mxser.h: MOXA
> SMARTIO/INDUSTIO/INTELLIO SERIAL CARD (Jiří Slabý):
> Force board setup for CONFIG_ARCH_MOXART.
> ASYNCB_CLOSING is avoided because of a lockup (infinite wait after
> tty_wait_until_sent). Why this happens is unknown (to me) I'm hoping
> someone (Jiří?) can shed light. SysRq trace @ http://ideone.com/e845mr
> What significance does ASYNCB_CLOSING have?
> Obviously, automatic detection is better but "mxser_read_register" is
> pointless on this hardware. What to do instead? Is it better to make a
> copy and submit a new driver?
> 
> drivers/mmc/core/sd.c:
> The MMC controller is "special"? "UNSTUFF_BITS" is redefined here
> http://repo.or.cz/w/linux-2.6.19-moxart.git/blob/50cdf2c57662f9f69c5615976412f76bfd73311a:/drivers/mmc/mmc.c
> . Without the new macro it'll report the wrong geometry and prod_name.
> I'm thinking a driver should never have to redefine UNSTUFF_BITS.
> Possible workaround: modify bits (in driver) to line up as expected
> before returning the response (mmc_request_done).
> 
> 
> For reference, this is my previous post from a few months back:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137130.html
> 
> Gitweb: http://repo.or.cz/w/linux-2.6.34.14-moxart.git/commitdiff/?h=3bc2e98ebb92961e1c5992736186920cd070f4ee&hp=b7f1d43323eceb02fd663a71eb2f8be9c17e6740
> 
> Download link (size: 193K):
> https://linux-2-6-34-14-moxart.googlecode.com/files/linux-2.6.34.14-moxart.patch
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [PATCH] ARM: mach-moxart: platform port for MOXA ART SoC

[Arnd Bergmann]

On Wednesday 13 March 2013, Daniel Mack wrote:
> On 13.03.2013 16:37, Jonas Jensen wrote:
> > I ask for feedback and to submit (if possible) a new ARM SoC platform
> > port. This is now near complete (I think) (tested on UC-7112-LX Plus)
> > and applies to 2.6.34.14.
> 
> First of all - thanks for submitting to the upstream kernel!
> 
> However, your patch has many severe problems which you need to address.
> 
> * please rebase your work. 2.6.34 is almost three years old now. 3.9 is
> in it's stabilisation phase, and all new support has to be done for 3.10.
> * all new platforms must be written with device-tree support
> * all drivers must have device-tree support as well

+1 all of the above.

Also, if you want to get the port included into 3.10 or later, you need to
follow the latest platform coding standards (in order of files in your patch):

* make it a sub-item under ARCH_MULTIPLATFORM, not a separate top-level
  platform
* generate the defconfig file using 'make safedefconfig' rather than copying
  the whole .config file
* Use the dmaengine subsystem for your DMA driver and put it into drivers/dma
* Remove the board file and use a device tree for adding your platform
  devices
* Use the gpio subsystem for your gpio driver and put it into drivers/gpio
* move mach/debug-macro.S to include/debug/moxart.S
* replace entry-macro.S with a .handle_irq function in the machine
  descriptor
* move your mach/hardware.h into next to the platform C files in mach-moxart
* set the arch_reset function as machine_desc->restart
* set the arch_idle function as arm_pm_idle
* remove the CLOCK_TICK_RATE
* move your irq.c to drivers/irqchip/irq-moxart.c and use IRQ domains
* move your time.c to drivers/clocksource/clocksource-moxart.c and 
  GENERIC_CLOCKEVENTS
* configure the mxser driver using DT and remove all the #ifdef in there
* submit all device drivers to the respective subsystem maintainers
* use the generic watchdog interface in the wdt driver instead of a misc device.

	Arnd

Re: [PATCH] ARM: mach-moxart: platform port for MOXA ART SoC

[Jonas Jensen]

Thank you for the feedback.

Some of the changes are sure to be a challenge for me, but I want to
move this forward, and having a list helps.

3.2.40 is as far as it'll go right now, nothing prints to UART
starting with 3.3.8 (last tested, it's somewhere around there).

I have been advised to enable early_printk (by landley on freenode IRC #edev).

Best regards,
Jonas

Re: [PATCH] ARM: mach-moxart: platform port for MOXA ART SoC

[Arnd Bergmann]

On Sunday 17 March 2013, Jonas Jensen wrote:
> Thank you for the feedback.
> 
> Some of the changes are sure to be a challenge for me, but I want to
> move this forward, and having a list helps.
> 
> 3.2.40 is as far as it'll go right now, nothing prints to UART
> starting with 3.3.8 (last tested, it's somewhere around there).
> 
> I have been advised to enable early_printk (by landley on freenode IRC #edev).

Yes, that is a good idea. I would also suggest that you don't try to port
all the code at once a few kernel versions at a time, but that you instead
move straight to the latest kernel, and basically start a new port one driver
at a time. Take one of the newer ports (highbank, virt, bcm, ...) as examples.

Since most of the code is now in drivers/ directories rather than arch/arm,
you can actually start getting stuff upstream before you have completed all
of it. If you have questions, I recommend asking on the #armlinux channel
on freenode, or here on the mailing list.

	Arnd