Re: [PATCH v2] ARM: CSR: Adding CSR SiRFprimaII board support

2011/6/30 Arnd Bergmann <arnd <at> arndb.de>:
> On Thursday 30 June 2011, Barry Song wrote:
>
>> > Is this really just one bus with a huge address space, or rather some
>> > nested buses? I'd prefer to have the device tree representation as
>> > close as possible to the actual layout.
>>
>> there are two AXI buses in prima2. AXI-1 connect to memory, AXI-2 is
>> transferred to CSR self-defined IOBUS by CPUIF, then 1 intterupt
>> controller and 9 IO bridges are connected to the IOBUS .
>> The 9 IO bridges are SYSIOBG, PERIIOBG,CPURTCIOBG, UUSIOBG, GRAPHIOBG,
>> MEDIAIOBG, DSPIOBG, DISPIOBG, MEMIOBG. Every iobrg connect to a group
>> of controllers.
>> For example, DISPIOBG connect to VPP and LCD, SYSIOBG connect to CLKC,
>> RSTC, RSC and CPHIFBG, DSPIOBG connect to DSPIF, GPS and DSP.
>> PERIIOBG connect to TIMER, NAND, AUDIO, UART0, UART1, UART2, USP0,
>> USP1, USP2, SPI0, I2C0, I2C1, GPIO, *SYS2PCI* and so on. Then
>> *SYS2PCI* connect to SD.
>>
>> The indendation descible the device hierarchy
>> AXI-1
>>          Memory
>> AXI-2
>>          interrupt controller
>>          IOBG...
>>                   xxxx
>>          IOBG...
>>                   xxxx
>>          IOBG...
>>                   xxxx

[PATCH v4] Add ARM cpu topology definition

The affinity between ARM processors is defined in the MPIDR register.
We can identify which processors are in the same cluster,
and which ones have performance interdependency. We can define the
cpu topology of ARM platform, that is then used by sched_mc and sched_smt.

The default state of sched_mc and sched_smt config is disable.
When enabled, the behavior of the scheduler can be modified with
sched_mc_power_savings and sched_smt_power_savings sysfs interfaces.

Changes since v3 :
* Update the format of printk message
* Remove blank line

Changes since v2 :
* Update the commit message and some comments

Changes since v1 :
* Update the commit message
* Add read_cpuid_mpidr in arch/arm/include/asm/cputype.h
* Modify header of arch/arm/kernel/topology.c
* Modify tests and manipulation of MPIDR's bitfields
* Modify the place and dependancy of the config
* Modify Noop functions

Signed-off-by: Vincent Guittot <vincent.guittot <at> linaro.org>
Reviewed-by: Amit Kucheria <amit.kucheria <at> linaro.org>
---
 arch/arm/Kconfig                |   25 +++++++
 arch/arm/include/asm/cputype.h  |    6 ++
 arch/arm/include/asm/topology.h |   33 +++++++++

Re: [PATCH v5 1/3] ARM: mxs: add GPMI-NFC support for imx23/imx28

Hi,

Arnd Bergmann writes:
> On Thursday 30 June 2011 16:58:38 Lothar Waßmann wrote:
> > > 
> > > When adding new infrastructure, always keep in mind how you want it to look
> > > after the device tree conversion. The partitions and min/max_* are easily covered
> > > with that, but the init/exit function pointers are somewhat problematic.
> > > 
> > > Fortunately, you don't really require these functions for this driver. The _exit
> > > function is completely unused, so just get rid of it.
> > > 
> > > The init function is used only to set up iomux, so the logical replacement is
> > > a pointer to the iomux data, and calling mxs_iomux_setup_multiple_pads
> > > directly from the driver.
> > > 
> > NO! I strongly object that. mxs_iomux_setup_multiple_pads() is a
> > platform specific function and has no business inside a device driver
> > that should be platform agnostic.
> > Consider the same controller being part of a different SoC that
> > requires you to call mxs_iomux_v2_setup_multiple_pads() instead. You
> > would then have to check for the SoC type inside the driver to find
> > the right function to call which is quite obscene.
> 
> Won't this problem just go away as soon as we get the mxs converted to the
> generic pinmux subsystem that Linus Walleij is doing?
> 
> Obviously, you would not have to check the soc type really, you would have
> to instead check for different versions of the gpmi, which you most likely
> have to anyway because reusing the same hardware block in a new chip usually

Re: [PATCH v5 1/3] ARM: mxs: add GPMI-NFC support for imx23/imx28

Hi Arnd,

> If you really want to call out obsceneties, how about the fact that this
> driver comes with an 805 line patch to add a HAL for a single chip!
> 
> Such abstractions should not be introduced as long as there is only
> a single instance of the hardware.

If I understood correctly, most if not all upcoming i.MX will have the GPMI
(mx50, mx6). Huang, do you already have a draft for the mx50-hal?

Regards,

   Wolfram

--

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel <at> lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: reply: [PATCH v7 1/3] MTD : add the common code for GPMI-NFC controller driver

Hi:
> Please can to use a mailer which:
>
> 1. Understands the convention for subject lines which are replies
>     (iow doesn't prefix it with "reply")
> 2. Understands threading enough to put In-reply-to: and/or References:
>     headers into your emails.
I feel sorry about this.

I sometimes reply the mail in the home with the Microsoft's webmail GUI, 
which make the mail
like new threads.

I will take care of it in the later mails.

thanks.

Best Regards
Huang Shijie
> Your current mailer makes all your messages look like new threads of
> conversation, and are completely disconnected from their real thread.
> Not only does that makes it hard to follow the threads, but also
> makes it harder to filter messages for reading.
>
> With the amount of email on these mailing lists, this should be a
> mandatory requirement for everyone sending messages there.
>
> Thanks.
>

Re: reply: [PATCH v5 1/3] ARM: mxs: add GPMI-NFC support for imx23/imx28

Hello,

On Fri, Jul 01, 2011 at 12:29:51AM +0200, Arnd Bergmann wrote:
> On Thursday 30 June 2011 18:12:27 Huang Shijie-B32955 wrote:
> > 
> > I think gpmi-nfc is much better then gpmi-nand or gpmi-flash.
> 
> Then how do you want to name the near field communication drivers?
I'm not aware that the i.MX23/28 has support for near field
communication, still the i.MX28 Reference speaks about "GPMI NAND Mode".
I couldn't find "NFC" in the document. So I vote for gpmi-nand, too.
(IMHO gpmi-flash is too generic.)

Best regards
Uwe

--

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 7/8] at91: factorize sram init

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj <at> jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre <at> atmel.com>
Cc: Patrice Vilchez <patrice.vilchez <at> atmel.com>
---
 arch/arm/mach-at91/at91cap9.c    |   11 +-------
 arch/arm/mach-at91/at91rm9200.c  |    6 +---
 arch/arm/mach-at91/at91sam9260.c |   53 ++++++-------------------------------
 arch/arm/mach-at91/at91sam9261.c |   22 +--------------
 arch/arm/mach-at91/at91sam9263.c |   17 +----------
 arch/arm/mach-at91/at91sam9g45.c |   11 +-------
 arch/arm/mach-at91/at91sam9rl.c  |   12 +--------
 arch/arm/mach-at91/generic.h     |    2 +
 arch/arm/mach-at91/setup.c       |   20 ++++++++++++++
 9 files changed, 39 insertions(+), 115 deletions(-)

diff --git a/arch/arm/mach-at91/at91cap9.c b/arch/arm/mach-at91/at91cap9.c
index 8fabf91..bfc6844 100644
--- a/arch/arm/mach-at91/at91cap9.c
+++ b/arch/arm/mach-at91/at91cap9.c
 <at>  <at>  -29,15 +29,6  <at>  <at> 
 #include "generic.h"
 #include "clock.h"

-static struct map_desc at91cap9_sram_desc[] __initdata = {
-	{
-		.virtual	= AT91_IO_VIRT_BASE - AT91CAP9_SRAM_SIZE,
-		.pfn		= __phys_to_pfn(AT91CAP9_SRAM_BASE),
-		.length		= AT91CAP9_SRAM_SIZE,
-		.type		= MT_DEVICE,
-	},

[PATCH 8/8] at91: add arch specific ioremap support

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj <at> jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre <at> atmel.com>
Cc: Patrice Vilchez <patrice.vilchez <at> atmel.com>
---
 arch/arm/mach-at91/include/mach/io.h |   16 +++++++++++++++-
 arch/arm/mach-at91/setup.c           |   19 +++++++++++++++++++
 2 files changed, 34 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-at91/include/mach/io.h b/arch/arm/mach-at91/include/mach/io.h
index 0b0cccc..6ffc53b 100644
--- a/arch/arm/mach-at91/include/mach/io.h
+++ b/arch/arm/mach-at91/include/mach/io.h
 <at>  <at>  -21,14 +21,28  <at>  <at> 
 #ifndef __ASM_ARCH_IO_H
 #define __ASM_ARCH_IO_H

+#include <mach/hardware.h>
+
 #define IO_SPACE_LIMIT		0xFFFFFFFF

 #define __io(a)		__typesafe_io(a)
 #define __mem_pci(a)	(a)

-
 #ifndef __ASSEMBLY__

+#ifndef CONFIG_ARCH_AT91X40
+#define __arch_ioremap	at91_ioremap
+#define __arch_iounmap	at91_iounmap
+#endif

[PATCH 6/8] at91: move register clocks to soc generic init

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj <at> jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre <at> atmel.com>
Cc: Patrice Vilchez <patrice.vilchez <at> atmel.com>
---
 arch/arm/mach-at91/at91cap9.c    |    4 +---
 arch/arm/mach-at91/at91rm9200.c  |    4 +---
 arch/arm/mach-at91/at91sam9260.c |    4 +---
 arch/arm/mach-at91/at91sam9261.c |    4 +---
 arch/arm/mach-at91/at91sam9263.c |    4 +---
 arch/arm/mach-at91/at91sam9g45.c |    4 +---
 arch/arm/mach-at91/at91sam9rl.c  |    4 +---
 arch/arm/mach-at91/setup.c       |    3 +++
 arch/arm/mach-at91/soc.h         |    1 +
 9 files changed, 11 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-at91/at91cap9.c b/arch/arm/mach-at91/at91cap9.c
index bdf5097..8fabf91 100644
--- a/arch/arm/mach-at91/at91cap9.c
+++ b/arch/arm/mach-at91/at91cap9.c
 <at>  <at>  -346,9 +346,6  <at>  <at>  static void __init at91cap9_initialize(void)
 	pm_power_off = at91cap9_poweroff;
 	at91_extern_irq = (1 << AT91CAP9_ID_IRQ0) | (1 << AT91CAP9_ID_IRQ1);

-	/* Register the processor-specific clocks */
-	at91cap9_register_clocks();
-
 	/* Register GPIO subsystem */
 	at91_gpio_init(at91cap9_gpio, 4);

 <at>  <at>  -404,5 +401,6  <at>  <at>  static unsigned int at91cap9_default_irq_priority[NR_AIC_IRQS] __initdata = {

[PATCH 5/8] at91: move clock subsystem init to soc generic init

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj <at> jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre <at> atmel.com>
Cc: Patrice Vilchez <patrice.vilchez <at> atmel.com>
---
 arch/arm/mach-at91/at91cap9.c    |    6 ++----
 arch/arm/mach-at91/at91rm9200.c  |    5 +----
 arch/arm/mach-at91/at91sam9260.c |    5 +----
 arch/arm/mach-at91/at91sam9261.c |    5 +----
 arch/arm/mach-at91/at91sam9263.c |    5 +----
 arch/arm/mach-at91/at91sam9g45.c |    5 +----
 arch/arm/mach-at91/at91sam9rl.c  |    5 +----
 arch/arm/mach-at91/generic.h     |    6 +++++-
 arch/arm/mach-at91/setup.c       |    5 ++++-
 arch/arm/mach-at91/soc.h         |    2 +-
 10 files changed, 18 insertions(+), 31 deletions(-)

diff --git a/arch/arm/mach-at91/at91cap9.c b/arch/arm/mach-at91/at91cap9.c
index 6287c0d..bdf5097 100644
--- a/arch/arm/mach-at91/at91cap9.c
+++ b/arch/arm/mach-at91/at91cap9.c
 <at>  <at>  -340,14 +340,12  <at>  <at>  static void __init at91cap9_map_io(void)
 	iotable_init(at91cap9_sram_desc, ARRAY_SIZE(at91cap9_sram_desc));
 }

-static void __init at91cap9_initialize(unsigned long main_clock)
+static void __init at91cap9_initialize(void)
+{
 	at91_arch_reset = at91cap9_reset;
 	pm_power_off = at91cap9_poweroff;
 	at91_extern_irq = (1 << AT91CAP9_ID_IRQ0) | (1 << AT91CAP9_ID_IRQ1);