* [RESEND PATCH 2/3] ARM: EXYNOS4: Update consistent DMA size to 8MB
From: Tushar Behera @ 2011-09-21 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <23185691.178841316589732769.JavaMail.weblogic@epv6ml02>
Hi,
On Wednesday 21 September 2011 12:52 PM, HATIMALI RV wrote:
> Hello Mr. Park,
>
> As I mentioned in the cover letter of v1 patch set (http://www.spinics.net/lists/arm-kernel/msg138054.html),
> this is a temporary patch which is just for testing HDMI on SMDKV310.
> Once CMA gets merged, we will be using that to allocate memory.
>
The macro definition CONSISTENT_DMA_SIZE has been removed and has been
replaced by a function call. Please refer to this patch.
http://www.spinics.net/lists/linux-samsung-soc/msg06627.html
> Thanks for your review.
>
> Regards,
> Hatim Ali
>
> ------- Original Message -------
> Sender : Kyungmin Park<kmpark@infradead.org>
> Date : Sep 21, 2011 11:55 (GMT+05:30)
> Title : Re: [RESEND PATCH 2/3] ARM: EXYNOS4: Update consistent DMA size to 8MB
>
> Hi,
>
> As I know, CONSISTENT_DMA_SIZE is removed, please use the updated APIs.
>
> Thank you,
> Kyungmin Park
>
> On Wed, Sep 21, 2011 at 2:44 PM, Hatim Ali<hatim.rv@samsung.com> wrote:
>> Change the consistent DMA allocation to 8MB to support the
>> TVOUT driver.
>>
>> NOTE: Once CMA support is merged into mainline, we will use it for memory
>> allocation.
>>
>> Signed-off-by: Hatim Ali<hatim.rv@samsung.com>
>> ---
>> arch/arm/mach-exynos4/include/mach/memory.h | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos4/include/mach/memory.h b/arch/arm/mach-exynos4/include/mach/memory.h
>> index 374ef2c..7549742 100644
>> --- a/arch/arm/mach-exynos4/include/mach/memory.h
>> +++ b/arch/arm/mach-exynos4/include/mach/memory.h
>> @@ -15,6 +15,8 @@
>>
>> #define PLAT_PHYS_OFFSET UL(0x40000000)
>>
>> +#define CONSISTENT_DMA_SIZE SZ_8M
>> +
>> /* Maximum of 256MiB in one bank */
>> #define MAX_PHYSMEM_BITS 32
>> #define SECTION_SIZE_BITS 28
>> --
>> 1.7.2.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> N?????r??y????b?X????v?^?)??{.n?+????{?????x,????\x17????}???? z?&j:+v???\a????zZ+??+zf???h???~????i???z?
?w?????????&?)??^[fl===
--
Tushar Behera
^ permalink raw reply
* [PATCH] ARM: vexpress: initial device tree support
From: Dave Martin @ 2011-09-21 9:19 UTC (permalink / raw)
To: linux-arm-kernel
This patch implements initial support for booting using a flattened
device tree on the Versatile Express platform.
Eventually, it should be possible to present a single, core-tile-
independent board, but in this transitional patch the baseboard +
Cortex-A9x4 core tile combination is the only directly supported
platform, since the implementation is not yet fully generic.
For now, clocks and timers are not handled via the device tree.
Implementation of these can follow in later patches.
Thanks to Lorenzo Pieralisi, Grant Likely and Pawe? Moll for their
help and contributions.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Pawe? Moll <Pawel.Moll@arm.com>
---
There are some outstanding issues which need to be discussed, listed
below.
* This patch is not currently based on the GIC bindings being
discussed by Rob Herring et al. Once that discussion reaches a
conclusion, it should be straightforward to rebase onto the result.
* The following added bindings are not present upstream and need
documentation / discussion:
* arm,vexpress -- the global board binding for all platform
combinations using the Versatile Express motherboard.
* arm,vexpress-v2p-ca9 -- the specific binding for the Versatile
Express motherboard with Cortex-A9x4 core tile installed. It
is only mentioned as the most-specific match in vexpress-v2p-
ca9.dts
Since it's intended that the motherboard code should be fully
generic, and because no other core tiles are upstream yet,
perhaps we can get rid of this binding right away.
* edid -- It should be possible to have a fairly generic binding
for EDID interfaces, but none seems to exist yet. Discussion
is needed regarding what form this should take.
This might more appropriately be called "ddc" (or some
variation on that), since EDID seems only to describe the
format of the ID data retrievable via this interface; not the
interface itself.
* arm,vexpress-flash -- Needed because of the requirement to
provide the physmap_flash driver with a special .set_vpp
handler.
* idt,89hpes32h8 -- This is the IDT 89HPES32H8 PCI express
interconnect switch. This isn't needed for the Versatile
Express to work, but would be needed if using PCI-e peripherals
for real. I expect that more driver support needs to go
upstream before this is actually usable.
* nxp,isp1761 -- The driver support for this is already upstream
(with some minor issues for ARM support).
* arm,amba-bus -- widely used by other boards and patchsets, but
seems not to be documented.
* The following bindings for ARM primecell peripherals are used
elsewhere but not documented. They should be pretty simple and
uncontraversial.
* arm,pl031
* arm,pl041
* arm,pl050
* arm,pl180
* arm,sp805
Rob Herring suggested documenting simple bindings for these
(and others) along with his initial amba device tree probe
patches, but these bindings don't seem to be documented
upstream for now.
* Shawn Guo's smsc911x patch is needed for Ethernet to work. This is
headed upstream but not yet in mainline. It is available in -next.
* Minor patches are needed to the isp1760 and pata_generic drivers,
to allow OF-based initialisation across a wider group of
architectures. These are being discussed independently, but are
not yet accepted for merging upstream.
* Most core-tile peripherals are currently not described in the core-
tile device tree fragment. This is a lower-priority issue since
the motherboard code already autodetects the core-tile (though only
one core-tile is fully upstream at the moment).
* Static peripheral mappings are not yet handled in a generic way in
the board support code. This is a prerequisite for supporting
multiple core-tiles int the same kernel. It well need to get fixed
later, when extra core tile support is merged (or before).
Pawe? Moll is looking into this separately.
* The Kconfig logic for ensuring that at least one boot protocol and
at least one core tile are selected is a bit ugly. Suggestions for
improving this are certainly welcome.
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/vexpress-v2m-legacy.dtsi | 163 ++++++++++++++++++++++++++++
arch/arm/boot/dts/vexpress-v2p-ca9.dts | 80 ++++++++++++++
arch/arm/configs/vexpress_defconfig | 1 +
arch/arm/mach-vexpress/Kconfig | 45 ++++++++-
arch/arm/mach-vexpress/ct-ca9x4.c | 7 ++
arch/arm/mach-vexpress/v2m.c | 54 +++++++++-
7 files changed, 349 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/vexpress-v2m-legacy.dtsi
create mode 100644 arch/arm/boot/dts/vexpress-v2p-ca9.dts
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ebc5d9..a6e90d5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -282,6 +282,7 @@ config ARCH_VERSATILE
config ARCH_VEXPRESS
bool "ARM Ltd. Versatile Express family"
+ select ARCH_VEXPRESS_SANE_CONFIG
select ARCH_WANT_OPTIONAL_GPIOLIB
select ARM_AMBA
select ARM_TIMER_SP804
diff --git a/arch/arm/boot/dts/vexpress-v2m-legacy.dtsi b/arch/arm/boot/dts/vexpress-v2m-legacy.dtsi
new file mode 100644
index 0000000..fd6e4e4
--- /dev/null
+++ b/arch/arm/boot/dts/vexpress-v2m-legacy.dtsi
@@ -0,0 +1,163 @@
+// ARM Ltd. Versatile Express Motherboard V2M-P1 (HBI-0190D)
+// Legacy memory map
+
+/ {
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ };
+
+ motherboard {
+ compatible = "simple-bus";
+ #address-cells = <2>; // SMB chipselect number and offset
+ #size-cells = <1>;
+ #interrupt-cells = <1>;
+
+ flash at 0,00000000 {
+ compatible = "arm,vexpress-flash", "cfi-flash";
+ reg = <0 0x00000000 0x04000000
+ 1 0x00000000 0x04000000>;
+ bank-width = <4>;
+ };
+
+ psram at 2,00000000 {
+ compatible = "mtd-ram";
+ reg = <2 0x00000000 0x02000000>;
+ bank-width = <4>;
+ };
+
+ ethernet at 3,02000000 {
+ compatible = "smsc,lan9118", "smsc,lan9115";
+ reg = <3 0x02000000 0x10000>;
+ reg-io-width = <4>;
+ interrupts = <15>;
+ smsc,irq-active-high;
+ smsc,irq-push-pull;
+ };
+
+ usb at 3,03000000 {
+ compatible = "nxp,usb-isp1761";
+ reg = <3 0x03000000 0x20000>;
+ interrupts = <16>;
+ port1-otg;
+ };
+
+ peripherals at 7,00000000 {
+ compatible = "arm,amba-bus", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 7 0 0x20000>;
+
+ // PCI-E I2C bus
+ i2c0: i2c at 02000 {
+ compatible = "arm,versatile-i2c";
+ reg = <0x02000 0x1000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcie-switch at 60 {
+ compatible = "idt,89hpes32h8";
+ reg = <0x60>;
+ };
+ };
+
+ aaci at 04000 {
+ compatible = "arm,pl041", "arm,primecell";
+ reg = <0x04000 0x1000>;
+ interrupts = <11>;
+ };
+
+ mmci at 05000 {
+ compatible = "arm,pl180", "arm,primecell";
+ reg = <0x05000 0x1000>;
+ interrupts = <9 10>;
+ };
+
+ kmi at 06000 {
+ compatible = "arm,pl050", "arm,primecell";
+ reg = <0x06000 0x1000>;
+ interrupts = <12>;
+ };
+
+ kmi at 07000 {
+ compatible = "arm,pl050", "arm,primecell";
+ reg = <0x07000 0x1000>;
+ interrupts = <13>;
+ };
+
+ uart0: uart at 09000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x09000 0x1000>;
+ interrupts = <5>;
+ };
+
+ uart1: uart at 0a000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x0a000 0x1000>;
+ interrupts = <6>;
+ };
+
+ uart2: uart at 0b000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x0b000 0x1000>;
+ interrupts = <7>;
+ };
+
+ uart3: uart at 0c000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x0c000 0x1000>;
+ interrupts = <8>;
+ };
+
+ wdt at 0f000 {
+ compatible = "arm,sp805", "arm,primecell";
+ reg = <0x0f000 0x1000>;
+ interrupts = <0>;
+ };
+
+ // Timer init is hardcoded in v2m_timer_init(), for now.
+ // timer at 11000 {
+ // compatible = "arm,arm-sp804";
+ // reg = <0x11000 0x1000>;
+ // interrupts = <2>;
+ // };
+
+ // timer at 12000 {
+ // compatible = "arm,arm-sp804";
+ // reg = <0x12000 0x1000>;
+ // };
+
+ // DVI I2C bus (DDC)
+ i2c1: i2c at 16000 {
+ compatible = "arm,versatile-i2c";
+ reg = <0x16000 0x1000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edid at 50 {
+ compatible = "edid";
+ reg = <0x50>;
+ };
+ };
+
+ rtc at 17000 {
+ compatible = "arm,pl031", "arm,primecell";
+ reg = <0x017000 0x1000>;
+ interrupts = <4>;
+ };
+
+ compact-flash at 1a000 {
+ compatible = "ata-generic";
+ reg = <0x1a000 0x100
+ 0x1a100 0xf00>;
+ reg-shift = <2>;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
new file mode 100644
index 0000000..059be97
--- /dev/null
+++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
@@ -0,0 +1,80 @@
+// ARM Ltd. Versatile Express Corex-A9 (Quad Core) Core Tile V2P-CA9 (HBI-0191B)
+
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "ARM Versatile Express (Cortex-A9 Quad Core Tile)";
+ compatible = "arm,vexpress-v2p-ca9", "arm,vexpress";
+ interrupt-parent = <&intc>;
+
+ memory {
+ device_type = "memory";
+ reg = <0x60000000 0x40000000>;
+ };
+
+ intc: interrupt-controller at 1e001000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x1e001000 0x1000>,
+ <0x1e000100 0x100>;
+ };
+
+ motherboard {
+ ranges = <0 0 0x40000000 0x04000000
+ 1 0 0x44000000 0x04000000
+ 2 0 0x48000000 0x04000000
+ 3 0 0x4c000000 0x04000000
+ 7 0 0x10000000 0x00020000>;
+
+ interrupt-map-mask = <0 0 63>;
+ interrupt-map = <0 0 0 &intc 32 8
+ 0 0 1 &intc 33 4
+ 0 0 2 &intc 34 4
+ 0 0 3 &intc 35 4
+ 0 0 4 &intc 36 4
+ 0 0 5 &intc 37 4
+ 0 0 6 &intc 38 4
+ 0 0 7 &intc 39 4
+ 0 0 8 &intc 40 4
+ 0 0 9 &intc 41 4
+ 0 0 10 &intc 42 4
+ 0 0 11 &intc 43 4
+ 0 0 12 &intc 44 4
+ 0 0 13 &intc 45 4
+ 0 0 14 &intc 46 4
+ 0 0 15 &intc 47 4
+ 0 0 16 &intc 48 4
+ 0 0 17 &intc 49 4
+ 0 0 18 &intc 50 4
+ 0 0 19 &intc 51 4
+ 0 0 20 &intc 52 4
+ 0 0 21 &intc 53 4
+ 0 0 22 &intc 54 4
+ 0 0 23 &intc 55 4
+ 0 0 24 &intc 56 4
+ 0 0 25 &intc 57 4
+ 0 0 26 &intc 58 4
+ 0 0 27 &intc 59 4
+ 0 0 28 &intc 60 4
+ 0 0 29 &intc 61 4
+ 0 0 30 &intc 62 4
+ 0 0 31 &intc 63 4
+ 0 0 32 &intc 64 4
+ 0 0 33 &intc 65 4
+ 0 0 34 &intc 66 4
+ 0 0 35 &intc 67 4
+ 0 0 36 &intc 68 4
+ 0 0 37 &intc 69 4
+ 0 0 38 &intc 70 4
+ 0 0 39 &intc 71 4
+ 0 0 40 &intc 72 4
+ 0 0 41 &intc 73 4
+ 0 0 42 &intc 74 4>;
+ };
+};
+
+/include/ "vexpress-v2m-legacy.dtsi"
diff --git a/arch/arm/configs/vexpress_defconfig b/arch/arm/configs/vexpress_defconfig
index f2de51f..6c3c5f6 100644
--- a/arch/arm/configs/vexpress_defconfig
+++ b/arch/arm/configs/vexpress_defconfig
@@ -22,6 +22,7 @@ CONFIG_MODULE_UNLOAD=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_ARCH_VEXPRESS=y
+CONFIG_ARCH_VEXPRESS_ATAGS=y
CONFIG_ARCH_VEXPRESS_CA9X4=y
# CONFIG_SWP_EMULATE is not set
CONFIG_SMP=y
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 9311484..ea64630 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -1,12 +1,55 @@
menu "Versatile Express platform type"
depends on ARCH_VEXPRESS
+# ARCH_VEXPRESS ensures a sane minimal config is selected by selecting
+# ARCH_VEXPRESS_SANE_CONFIG.
+# Extend the logic here when adding new core tiles.
+
+config ARCH_VEXPRESS_SANE_CONFIG
+ bool
+ select ARCH_VEXPRESS_CA9X4
+ select ARCH_VEXPRESS_ATAGS if !ARCH_VEXPRESS_DT
+
+
+comment "At least one boot type must be selected"
+
+config ARCH_VEXPRESS_ATAGS
+ bool "Boot via ATAGs"
+ default y
+ help
+ This option enables support for the board using the standard
+ ATAGs boot protocol.
+
+ If your bootloader supports FDT-based booting and you do not
+ intend ever to boot via the traditional ATAGs method, you can say
+ N here.
+
+config ARCH_VEXPRESS_DT
+ bool "Boot via Device Tree"
+ select USE_OF
+ help
+ This option enables support for the board, and enables booting
+ via a Flattened Device Tree provided by the bootloader.
+
+ If your bootloader supports FDT-based booting, you can say Y
+ here, otherwise, say N.
+
+
+# Core Tile support options
+
+comment "At least one core tile must be selected"
+
config ARCH_VEXPRESS_CA9X4
- bool "Versatile Express Cortex-A9x4 tile"
+ bool "Versatile Express Cortex-A9x4 Core Tile"
+ default y
select CPU_V7
select ARM_GIC
select ARM_ERRATA_720789
select ARM_ERRATA_751472
select ARM_ERRATA_753970
+ help
+ Include support for the Cortex-A9x4 Core Tile (HBI-0191B).
+
+ If unsure, say Y.
endmenu
diff --git a/arch/arm/mach-vexpress/ct-ca9x4.c b/arch/arm/mach-vexpress/ct-ca9x4.c
index bfd32f5..e2fe2c9 100644
--- a/arch/arm/mach-vexpress/ct-ca9x4.c
+++ b/arch/arm/mach-vexpress/ct-ca9x4.c
@@ -9,6 +9,7 @@
#include <linux/amba/bus.h>
#include <linux/amba/clcd.h>
#include <linux/clkdev.h>
+#include <linux/irqdomain.h>
#include <asm/hardware/arm_timer.h>
#include <asm/hardware/cache-l2x0.h>
@@ -59,10 +60,16 @@ static void __init ct_ca9x4_map_io(void)
iotable_init(ct_ca9x4_io_desc, ARRAY_SIZE(ct_ca9x4_io_desc));
}
+static const struct of_device_id gic_of_match[] __initconst = {
+ { .compatible = "arm,cortex-a9-gic", },
+ {}
+};
+
static void __init ct_ca9x4_init_irq(void)
{
gic_init(0, 29, MMIO_P2V(A9_MPCORE_GIC_DIST),
MMIO_P2V(A9_MPCORE_GIC_CPU));
+ irq_domain_generate_simple(gic_of_match, A9_MPCORE_GIC_DIST, 0);
}
#if 0
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 9e6b93b..6defce6 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -6,6 +6,8 @@
#include <linux/amba/mmci.h>
#include <linux/io.h>
#include <linux/init.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
#include <linux/platform_device.h>
#include <linux/ata_platform.h>
#include <linux/smsc911x.h>
@@ -118,7 +120,7 @@ int v2m_cfg_read(u32 devfn, u32 *data)
return !!(val & SYS_CFG_ERR);
}
-
+#ifdef CONFIG_ARCH_VEXPRESS_ATAGS
static struct resource v2m_pcie_i2c_resource = {
.start = V2M_SERIAL_BUS_PCI,
.end = V2M_SERIAL_BUS_PCI + SZ_4K - 1,
@@ -200,6 +202,7 @@ static struct platform_device v2m_usb_device = {
.num_resources = ARRAY_SIZE(v2m_usb_resources),
.dev.platform_data = &v2m_usb_config,
};
+#endif /* CONFIG_ARCH_VEXPRESS_ATAGS */
static void v2m_flash_set_vpp(struct platform_device *pdev, int on)
{
@@ -211,6 +214,7 @@ static struct physmap_flash_data v2m_flash_data = {
.set_vpp = v2m_flash_set_vpp,
};
+#ifdef CONFIG_ARCH_VEXPRESS_ATAGS
static struct resource v2m_flash_resources[] = {
{
.start = V2M_NOR0,
@@ -254,6 +258,7 @@ static struct platform_device v2m_cf_device = {
.num_resources = ARRAY_SIZE(v2m_pata_resources),
.dev.platform_data = &v2m_pata_data,
};
+#endif /* CONFIG_ARCH_VEXPRESS_ATAGS */
static unsigned int v2m_mmci_status(struct device *dev)
{
@@ -265,6 +270,7 @@ static struct mmci_platform_data v2m_mmci_data = {
.status = v2m_mmci_status,
};
+#ifdef CONFIG_ARCH_VEXPRESS_ATAGS
static AMBA_DEVICE(aaci, "mb:aaci", V2M_AACI, NULL);
static AMBA_DEVICE(mmci, "mb:mmci", V2M_MMCI, &v2m_mmci_data);
static AMBA_DEVICE(kmi0, "mb:kmi0", V2M_KMI0, NULL);
@@ -288,6 +294,7 @@ static struct amba_device *v2m_amba_devs[] __initdata = {
&wdt_device,
&rtc_device,
};
+#endif /* CONFIG_ARCH_VEXPRESS_ATAGS */
static long v2m_osc_round(struct clk *clk, unsigned long rate)
@@ -415,6 +422,8 @@ static void __init v2m_init_irq(void)
ct_desc->init_irq();
}
+
+#ifdef CONFIG_ARCH_VEXPRESS_ATAGS
static void __init v2m_init(void)
{
int i;
@@ -443,3 +452,46 @@ MACHINE_START(VEXPRESS, "ARM-Versatile Express")
.timer = &v2m_timer,
.init_machine = v2m_init,
MACHINE_END
+#endif /* CONFIG_ARCH_VEXPRESS_ATAGS */
+
+#ifdef CONFIG_ARCH_VEXPRESS_DT
+struct of_dev_auxdata v2m_dt_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("arm,vexpress-flash", V2M_NOR0, "physmap-flash", &v2m_flash_data),
+ OF_DEV_AUXDATA("arm,primecell", V2M_AACI, "mb:aaci", NULL),
+ OF_DEV_AUXDATA("arm,primecell", V2M_WDT, "mb:wdt", NULL),
+ OF_DEV_AUXDATA("arm,primecell", V2M_MMCI, "mb:mmci", &v2m_mmci_data),
+ OF_DEV_AUXDATA("arm,primecell", V2M_KMI0, "mb:kmi0", NULL),
+ OF_DEV_AUXDATA("arm,primecell", V2M_KMI1, "mb:kmi1", NULL),
+ OF_DEV_AUXDATA("arm,primecell", V2M_UART0, "mb:uart0", NULL),
+ OF_DEV_AUXDATA("arm,primecell", V2M_UART1, "mb:uart1", NULL),
+ OF_DEV_AUXDATA("arm,primecell", V2M_UART2, "mb:uart2", NULL),
+ OF_DEV_AUXDATA("arm,primecell", V2M_UART3, "mb:uart3", NULL),
+ OF_DEV_AUXDATA("arm,primecell", V2M_RTC, "mb:rtc", NULL),
+ {}
+};
+
+static void __init v2m_dt_init(void)
+{
+ of_platform_populate(NULL, of_default_bus_match_table,
+ v2m_dt_auxdata_lookup, NULL);
+
+ pm_power_off = v2m_power_off;
+ arm_pm_restart = v2m_restart;
+
+ ct_desc->init_tile();
+}
+
+static const char *v2m_dt_match[] __initconst = {
+ "arm,vexpress",
+ NULL,
+};
+
+DT_MACHINE_START(VEXPRESS_DT, "ARM Versatile Express")
+ .map_io = v2m_map_io,
+ .init_early = v2m_init_early,
+ .init_irq = v2m_init_irq,
+ .timer = &v2m_timer,
+ .init_machine = v2m_dt_init,
+ .dt_compat = v2m_dt_match,
+MACHINE_END
+#endif /* CONFIG_ARCH_VEXPRESS_DT */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] drivers: create a pin control subsystem v7
From: Linus Walleij @ 2011-09-21 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF04B7321751@HQMAIL01.nvidia.com>
On Tue, Sep 20, 2011 at 11:58 PM, Stephen Warren <swarren@nvidia.com> wrote:
> Linus Walleij wrote at Friday, September 16, 2011 6:13 AM:
>> This creates a subsystem for handling of pin control devices.
>> These are devices that control different aspects of package
>> pins.
>
> I've read through the documentation and header files, but not the .c files,
> and this looks almost perfect as far as I can tell right now. I'll try to
> review the .c files sometime too.
Great, I'm hunting your Acked-by/Reviewed-by ...
I will likely request inclusion into linux-next soon-ish.
> I just have one comment:
>
>> diff --git a/include/linux/pinctrl/pinmux.h b/include/linux/pinctrl/pinmux.h
> ...
>> +/* External interface to pinmux */
>> +extern int pinmux_request_gpio(unsigned gpio);
>> +extern void pinmux_free_gpio(unsigned gpio);
>> +extern struct pinmux * __must_check pinmux_get(struct device *dev, const char *name);
>> +extern void pinmux_put(struct pinmux *pmx);
>> +extern int pinmux_enable(struct pinmux *pmx);
>> +extern void pinmux_disable(struct pinmux *pmx);
>> +extern int pinmux_config(struct pinmux *pmx, u16 param, unsigned long *data);
>
> That definition of pinmux_config doesn't seem as useful as it could be;
It should be removed. It's just there in the header file, I killed off
the implementation because specific control of a mux doesn't make
sense. We want to do stuff to pin groups directly, not related to
muxing, so that kind of thing needs to be in the generic pinctrl
interface.
> I'd like the ability to execute pinmux_config on a /named/ group, and I
> can certainly see a use-case for applying it to /named/ pins too.
That sounds correct to me.
To abstract things the stuff we can do with the group should be
something enumerated too. So:
pinctrl_config_group(const char *pinctrl_device, const char *group,
const char *mode);
pinctrl_config_pin(const char *pinctrl_device, int pin, const char *mode);
So the driver need an API to enumerate pin and group modes.
I might want to save this thing for post-merge of the basic API and
pinmux stuff though so we don't try to push too much upfront
design at once.
> The issues with applying pinmux_config to a mapping table entry are:
>
> * When there are multiple mapping table entries referenced by one
> pinmux_get, you don't necessarily want to apply the same configuration
> to all of the groups; think of a bus with a combination of low-speed
> output control signals and high-speed input data signals or something
> like that.
>
> * When muxing works in groups, you may want to apply the configuration
> to individual pins rather than the whole groups using in the mapping
> table.
Yeah, we kill this old interface.
Thanks,
Linus Walleij
^ permalink raw reply
* [PATCH 4/5] ispccdc: Configure CCDC_SYN_MODE register for UYVY8_2X8 and YUYV8_2X8 formats
From: Laurent Pinchart @ 2011-09-21 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ADF30F4D7BDE934D9B632CE7D5C7ACA4047C4D090847@dbde03.ent.ti.com>
Hi Deepthy,
On Wednesday 21 September 2011 07:32:44 Ravi, Deepthy wrote:
> On Wednesday, September 21, 2011 4:56 AM Laurent Pinchart wrote:
> > On Tuesday 20 September 2011 16:56:51 Deepthy Ravi wrote:
> >> Configure INPMOD and PACK8 fileds of CCDC_SYN_MODE
> >> register for UYVY8_2X8 and YUYV8_2X8 formats.
> >>
> >> Signed-off-by: Deepthy Ravi <deepthy.ravi@ti.com>
> >> ---
> >>
> >> drivers/media/video/omap3isp/ispccdc.c | 11 ++++++++---
> >> 1 files changed, 8 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/media/video/omap3isp/ispccdc.c
> >> b/drivers/media/video/omap3isp/ispccdc.c index 418ba65..1dcf180 100644
> >> --- a/drivers/media/video/omap3isp/ispccdc.c
> >> +++ b/drivers/media/video/omap3isp/ispccdc.c
> >> @@ -985,8 +985,12 @@ static void ccdc_config_sync_if(struct
> >> isp_ccdc_device
> >> *ccdc,
> >>
> >> syn_mode &= ~ISPCCDC_SYN_MODE_INPMOD_MASK;
> >> if (format->code == V4L2_MBUS_FMT_YUYV8_2X8 ||
> >>
> >> - format->code == V4L2_MBUS_FMT_UYVY8_2X8)
> >> - syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
> >> + format->code == V4L2_MBUS_FMT_UYVY8_2X8){
> >> + if (pdata && pdata->bt656)
> >> + syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
> >> + else
> >> + syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
> >> + }
> >>
> >> else if (format->code == V4L2_MBUS_FMT_YUYV8_1X16 ||
> >>
> >> format->code == V4L2_MBUS_FMT_UYVY8_1X16)
> >>
> >> syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
> >>
> >> @@ -1172,7 +1176,8 @@ static void ccdc_configure(struct isp_ccdc_device
> >> *ccdc) syn_mode &= ~ISPCCDC_SYN_MODE_SDR2RSZ;
> >>
> >> /* Use PACK8 mode for 1byte per pixel formats. */
> >>
> >> - if (omap3isp_video_format_info(format->code)->width <= 8)
> >> + if ((omap3isp_video_format_info(format->code)->width <= 8) &&
> >> + (omap3isp_video_format_info(format->code)->bpp <=
> >> 8))
> >
> > I'm not sure to follow you. This will clear the PACK8 bit for the
> > YUYV8_2X8 formats. Those formats are 8 bits wide, shouldn't PACK8 be set
> > to store samples on 8 bits instead of 16 bits ?
> >
> > Is this patch intended to support YUYV8_2X8 sensors in non BT.656 mode
> > with the bridge enabled ? In that case, what would you think about setting
> > the CCDC input format to YUYV8_1X16 instead ? This would better reflect
> > the reality, as the bridge converts YUYV8_2X8 to YUYV8_1X16, and the CCDC
> > is then fed with YUYV8_1X16.
>
> Yes this is intended for YUYV8_2X8 sensors in non BT.656 with 8 to 16 bit
> bridge enabled. So the data has to be stored as 16 bits per sample. Thats
> why PACK8 is cleared . I am not sure about using YUYV8_1X16.
My original idea when I wrote the YV support patches was to implement this use
case with YUYV8_2X8 at the sensor output and YUYV8_1X16 at the CCDC input. The
ISP driver could then enable the bridge automatically. I'm not sure if that's
the best solution though, it might be confusing for the users. What I would
like to keep, however, is the idea of enabling the bridge automatically.
Sakari, any opinion on this ?
> >> syn_mode |= ISPCCDC_SYN_MODE_PACK8;
> >> else
> >> syn_mode &= ~ISPCCDC_SYN_MODE_PACK8;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] dmaengine: delete redundant chan_id and chancnt initialization in dma drivers
From: Jassi Brar @ 2011-09-21 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316166200-20595-1-git-send-email-Baohua.Song@csr.com>
On Fri, Sep 16, 2011 at 3:13 PM, Barry Song <Baohua.Song@csr.com> wrote:
> dma_async_device_register will re-init chan_id and chancnt,
> so whatever chan_id and chancnt are set in drivers, they will
> be re-written by dma_async_device_register.
>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Viresh Kumar <viresh.kumar@st.com>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Piotr Ziecik <kosmo@semihalf.com>
> Cc: Yong Wang <yong.y.wang@intel.com>
> Cc: Jaswinder Singh <jassi.brar@samsung.com>
> Cc: Pelagicore AB <info@pelagicore.com>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> ---
> ?drivers/dma/at_hdmac.c ? ? ?| ? ?5 ++---
> ?drivers/dma/dw_dmac.c ? ? ? | ? ?5 ++---
> ?drivers/dma/intel_mid_dma.c | ? ?2 --
> ?drivers/dma/mpc512x_dma.c ? | ? ?1 -
> ?drivers/dma/pch_dma.c ? ? ? | ? ?2 --
> ?drivers/dma/pl330.c ? ? ? ? | ? ?2 --
> ?drivers/dma/timb_dma.c ? ? ?| ? ?3 +--
Apparently ....
drivers/dma/ppc4xx/adma.c
drivers/dma/ipu/ipu_idmac.c
still write to chan_id.
drivers/dma/amba-pl08x.c
drivers/dma/fsldma.c
drivers/dma/ioat/dma_v2.c
drivers/dma/ioat/dma.c
drivers/dma/mpc512x_dma.c
drivers/dma/shdma.c
still write to chancnt
Most of them are simply a matter of removal, but some seem
like really depending upon setting them(?)
Anyways, even after you modify those as well, chan_id and chancnt
are rendered overstaying guests in dmaengine core. Because chan_id
of each channel would be _precisely_ the order in which the
_dmac-driver_ added the channel to the 'channels' list.
So if their values are _always_ gonna be just contiguously incrementing
why need variables for that in the dmaengine api?
Dmac drivers could use local variables for that.
OTOH, why not chan_id be left solely for use by dmac drivers read by the
dmaengine only to create sysfs entries ?
^ permalink raw reply
* [PATCH 2/2 v7] pinmux: add a driver for the U300 pinmux
From: Linus Walleij @ 2011-09-21 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF04B7321777@HQMAIL01.nvidia.com>
On Wed, Sep 21, 2011 at 12:15 AM, Stephen Warren <swarren@nvidia.com> wrote:
> Linus Walleij wrote at Friday, September 16, 2011 6:14 AM:
>> + ? ? for (i = 0; i < ARRAY_SIZE(u300_mux_hogs); i++) {
>> + ? ? ? ? ? ? struct pinmux *pmx;
>> + ? ? ? ? ? ? int ret;
>> +
>> + ? ? ? ? ? ? pmx = pinmux_get(u300_mux_hogs[i].dev, NULL);
>> + ? ? ? ? ? ? if (IS_ERR(pmx)) {
>> + ? ? ? ? ? ? ? ? ? ? pr_err("u300: could not get pinmux hog %s\n",
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?u300_mux_hogs[i].name);
>> + ? ? ? ? ? ? ? ? ? ? continue;
>> + ? ? ? ? ? ? }
>> + ? ? ? ? ? ? ret = pinmux_enable(pmx);
>> + ? ? ? ? ? ? if (ret) {
>> + ? ? ? ? ? ? ? ? ? ? pr_err("u300: could enable pinmux hog %s\n",
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?u300_mux_hogs[i].name);
>> + ? ? ? ? ? ? ? ? ? ? continue;
>> + ? ? ? ? ? ? }
>> + ? ? ? ? ? ? u300_mux_hogs[i].pmx = pmx;
>> + ? ? }
>> + ? ? return 0;
>> +}
>> +subsys_initcall(u300_pinmux_fetch);
>
> Why not just have the pinmux core support hogging on non-"system" mapping
> entries; then everything I quoted above except u300_pinmux_map[] could
> be deleted, and the "hog" flag set on the last 3 u300_pinmux_map[] entries.
Very good question, luckily I have a good answer.
There is no way for the pinmux core to traverse the system and look
up the apropriate struct device * pointers.
When/if we have device tree support, I think this will be possible, then I
will be able to have the pinmux hog look up devices from device tree
and hog their pinmux.
At that point we'll likely have the mapping in the device tree too and
the core does not need to be involved at all.
What I could do right now is add some open-ended function like
pinmux_hog_device_pinmuxes(struct device **devices);
that can take an array of devices and hog their respective
pinmuxes in the hog list. Do you think it's a good idea?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCHv2 2/2] ARM: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice
From: Stephen Boyd @ 2011-09-21 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316568208-4518-2-git-send-email-sboyd@codeaurora.org>
On 9/20/2011 6:23 PM, Stephen Boyd wrote:
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 6dbcb00..31896f4 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -81,6 +81,17 @@ choice
> prompt "Kernel low-level debugging port"
> depends on DEBUG_LL
>
> + config DEBUG_ICEDCC
> + bool "Kernel low-level debugging via EmbeddedICE DCC channel"
> + depends on DEBUG_LL
Oops. This depends isn't necessary. Will fix before submitting to patch
tracker.
> + help
> + Say Y here if you want the debug print routines to direct
> + their output to the EmbeddedICE macrocell's DCC channel using
> + co-processor 14. This is known to work on the ARM9 style ICE
> + channel and on the XScale with the PEEDI.
> +
> + It does include a timeout to ensure that the system does not
> + totally freeze when there is nothing connected to read.
>
> config DEBUG_FOOTBRIDGE_COM1
> bool "Kernel low-level debugging messages via footbridge 8250 at PCI COM1"
>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Barry Song @ 2011-09-21 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4xcWkGYrRoR_uSwtW6Qt4TkSWp+yQemP36sdF8o_Q=bLw@mail.gmail.com>
2011/9/21 Barry Song <21cnbao@gmail.com>:
> 2011/9/21 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>> On Wed, Sep 21, 2011 at 01:53:37PM +0800, Barry Song wrote:
>>> yes. imx6q actually needs to enable l2 earlier than cpu_resume(and mmu
>>> resume). so how about letting outer_resume support both phy and virt
>>> address restore?
>>
>> You can't call C functions in the kernel before the MMU is enabled.
>
> well. a direct call will fall into virtual address. then we need to
> transfer it to a phy address before calling it.
stack and global variant is still a problem. then if we want a generic
function for resuming before mmu on, it seems it is best to be asm
codes.
>
>>
>
-barry
^ permalink raw reply
* [PATCH] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Russell King - ARM Linux @ 2011-09-21 7:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4xcWkGYrRoR_uSwtW6Qt4TkSWp+yQemP36sdF8o_Q=bLw@mail.gmail.com>
On Wed, Sep 21, 2011 at 03:49:23PM +0800, Barry Song wrote:
> 2011/9/21 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > On Wed, Sep 21, 2011 at 01:53:37PM +0800, Barry Song wrote:
> >> yes. imx6q actually needs to enable l2 earlier than cpu_resume(and mmu
> >> resume). so how about letting outer_resume support both phy and virt
> >> address restore?
> >
> > You can't call C functions in the kernel before the MMU is enabled.
>
> well. a direct call will fall into virtual address. then we need to
> transfer it to a phy address before calling it.
No. I say again, you can't call C functions in the kernel before the
MMU is enabled.
C functions have literal tables that contain absolute virtual addresses
of variables and such like. Without the MMU enabled, those addresses
are meaningless and won't point at the right place.
^ permalink raw reply
* [PATCH] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Barry Song @ 2011-09-21 7:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110921073853.GD17169@n2100.arm.linux.org.uk>
2011/9/21 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Wed, Sep 21, 2011 at 01:53:37PM +0800, Barry Song wrote:
>> yes. imx6q actually needs to enable l2 earlier than cpu_resume(and mmu
>> resume). so how about letting outer_resume support both phy and virt
>> address restore?
>
> You can't call C functions in the kernel before the MMU is enabled.
well. a direct call will fall into virtual address. then we need to
transfer it to a phy address before calling it.
>
^ permalink raw reply
* [PATCH] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Russell King - ARM Linux @ 2011-09-21 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4z4WJkDPhD1WYan3GecnAb0VfPx3_dgFHCmTWs7gVyFdA@mail.gmail.com>
On Wed, Sep 21, 2011 at 01:53:37PM +0800, Barry Song wrote:
> yes. imx6q actually needs to enable l2 earlier than cpu_resume(and mmu
> resume). so how about letting outer_resume support both phy and virt
> address restore?
You can't call C functions in the kernel before the MMU is enabled.
^ permalink raw reply
* [GIT PULL] ARM: kprobes: Add test code to kernel tree
From: Tixy @ 2011-09-21 7:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell
Would you please pull these patches for the next merge window? They are
pretty much an essential tool for anyone debugging or extending the
kprobes instruction simulation code and are a good regression test for
kprobes on ARM.
Thanks
--
Jon Medhurst (usually know as Tixy)
The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
Linux 3.1-rc6 (2011-09-12 14:02:02 -0700)
are available in the git repository at:
git://git.yxit.co.uk/linux kprobes-test
Jon Medhurst (10):
ARM: kprobes: Add config option for selecting the ARM kprobes tests
ARM: kprobes: Add basic API tests
ARM: kprobes: Framework for instruction set test cases
ARM: kprobes: Add Thumb instruction simulation test cases
ARM: kprobes: Add ARM instruction simulation test cases
ARM: kprobes: Add exports for test code
ARM: kprobes: Add decoding table self-consistency tests
ARM: kprobes: Add decoding table test coverage analysis
ARM: kprobes: Add some benchmarking to test module
ARM: kprobes: Add introductory comment to test code
arch/arm/Kconfig.debug | 6 +
arch/arm/kernel/Makefile | 7 +
arch/arm/kernel/kprobes-arm.c | 4 +
arch/arm/kernel/kprobes-test-arm.c | 1323 +++++++++++++++++++++++++
arch/arm/kernel/kprobes-test-thumb.c | 1187 +++++++++++++++++++++++
arch/arm/kernel/kprobes-test.c | 1748 ++++++++++++++++++++++++++++++++++
arch/arm/kernel/kprobes-test.h | 392 ++++++++
arch/arm/kernel/kprobes-thumb.c | 7 +
arch/arm/kernel/kprobes.h | 8 +
9 files changed, 4682 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/kernel/kprobes-test-arm.c
create mode 100644 arch/arm/kernel/kprobes-test-thumb.c
create mode 100644 arch/arm/kernel/kprobes-test.c
create mode 100644 arch/arm/kernel/kprobes-test.h
^ permalink raw reply
* [PATCH V7 1/5] AHCI Add the AHCI SATA feature on the MX53 platforms
From: Shawn Guo @ 2011-09-21 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110921070201.GB14191@pengutronix.de>
On Wed, Sep 21, 2011 at 09:02:01AM +0200, Sascha Hauer wrote:
> On Wed, Sep 21, 2011 at 01:04:09PM +0800, Richard Zhu wrote:
> > Hi Sascha:
> > Thanks for your comments.
> >
> > Best Regard
> > Richard Zhu
> >
> > On 21 September 2011 04:30, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > On Wed, Aug 31, 2011 at 11:50:31AM +0800, Richard Zhu wrote:
> > >> Signed-off-by: Richard Zhu <richard.zhu@linaro.org>
> > >> Tested-By: Hector Oron Martinez <hector.oron@gmail.com>
> > >> ---
> > >> ?arch/arm/mach-mx5/clock-mx51-mx53.c ? ? ? ? ? ? | ? 19 ++++
> > >> ?arch/arm/mach-mx5/devices-imx53.h ? ? ? ? ? ? ? | ? ?4 +
> > >> ?arch/arm/plat-mxc/Makefile ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> > >> ?arch/arm/plat-mxc/ahci_sata.c ? ? ? ? ? ? ? ? ? | ?104 +++++++++++++++++++++++
> > >> ?arch/arm/plat-mxc/devices/Kconfig ? ? ? ? ? ? ? | ? ?4 +
> > >> ?arch/arm/plat-mxc/devices/Makefile ? ? ? ? ? ? ?| ? ?1 +
> > >> ?arch/arm/plat-mxc/devices/platform-ahci-imx.c ? | ? 66 ++++++++++++++
> > >> ?arch/arm/plat-mxc/include/mach/ahci_sata.h ? ? ?| ? 33 +++++++
> > >> ?arch/arm/plat-mxc/include/mach/devices-common.h | ? 10 ++
> > >> ?9 files changed, 242 insertions(+), 0 deletions(-)
> > >> ?create mode 100644 arch/arm/plat-mxc/ahci_sata.c
> > >> ?create mode 100644 arch/arm/plat-mxc/devices/platform-ahci-imx.c
> > >> ?create mode 100644 arch/arm/plat-mxc/include/mach/ahci_sata.h
> > >>
> > >> diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
> > >> index 7f20308..e1fadaf 100644
> > >> --- a/arch/arm/mach-mx5/clock-mx51-mx53.c
> > >> +++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
> > >> @@ -1397,6 +1397,22 @@ static struct clk esdhc4_mx53_clk = {
> > >> ? ? ? .secondary = &esdhc4_ipg_clk,
> > >> ?};
> > >>
> > >> diff --git a/arch/arm/plat-mxc/ahci_sata.c b/arch/arm/plat-mxc/ahci_sata.c
> > >> new file mode 100644
> > >> index 0000000..4f54816
> > >> --- /dev/null
> > >> +++ b/arch/arm/plat-mxc/ahci_sata.c
> > >> @@ -0,0 +1,104 @@
> > >> +/*
> > >> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> > >> + */
> > >> +
> > >> +/*
> > >> + * This program is free software; you can redistribute it and/or modify
> > >> + * it under the terms of the GNU General Public License as published by
> > >> + * the Free Software Foundation; either version 2 of the License, or
> > >> + * (at your option) any later version.
> > >> +
> > >> + * This program is distributed in the hope that it will be useful,
> > >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
> > >> + * GNU General Public License for more details.
> > >> +
> > >> + * You should have received a copy of the GNU General Public License along
> > >> + * with this program; if not, write to the Free Software Foundation, Inc.,
> > >> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> > >> + */
> > >> +
> > >> +#include <linux/io.h>
> > >> +#include <linux/clk.h>
> > >> +#include <linux/err.h>
> > >> +#include <linux/device.h>
> > >> +#include <mach/ahci_sata.h>
> > >> +
> > >> +static struct clk *sata_clk, *sata_ref_clk;
> > >
> > > These variables make the driver single instance only.
> > [Richard Zhu] In order to handle the clock enable/disable stuff, these
> > two variables are mandatory required.
> > Otherwise, new two struct clk members had to be added into
> > ahci_platform_data struct. Then the clks can
> > be transferred by the platform data.
> > The current is preferred, refer to the second choice.
> > >
> > >> +
> > >> +/* AHCI module Initialization, if return 0, initialization is successful. */
> > >> +int sata_init(struct device *dev, void __iomem *addr)
> > >
> > > A global function with such a generic name is not a good idea.
> > > Also I wonder how we want to convert this to devicetree when we
> > > implement this as a platform specific hook. It should be done in the
> > > driver.
> > >
> > [Richard Zhu] The name of these two func can be changed.
> > But I don't have a good idea to move out these two platform specific
> > hooks (->init, ->exit).
> >
> > Refer to you comments, do you means that the ->init and ->exit should
> > be done in ahci_platform.c driver?
> > Different platform may have the different ->init and ->exit funcs to
> > handle it's own initialization and exit.
> > It would be a problem that handle all kinds of init in one driver
> > without the hooks.
>
> Maybe Shawn can comment on the device tree topic. I just think that if
> we merge this without devicetree support it should at least be
> devicetree friendly. For example each platform could provide it's own
> platform driver glue code like it's done for the sdhci driver.
>
+1
Though we have a way out for platform hooks if there is really no other
way around, using aux_data to pass a platform_data holding the hooks,
I really hate to see that. And obviously, Sascha's suggestion seems
the right thing to do.
Regards,
Shawn
> > >> diff --git a/arch/arm/plat-mxc/devices/platform-ahci-imx.c b/arch/arm/plat-mxc/devices/platform-ahci-imx.c
> > >> new file mode 100644
> > >> index 0000000..9e1b460
> > >> --- /dev/null
> > >> +++ b/arch/arm/plat-mxc/devices/platform-ahci-imx.c
> > >> @@ -0,0 +1,66 @@
> > >> +/*
> > >> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> > >> + */
> > >> +
> > >> +/*
> > >> + * This program is free software; you can redistribute it and/or modify
> > >> + * it under the terms of the GNU General Public License as published by
> > >> + * the Free Software Foundation; either version 2 of the License, or
> > >> + * (at your option) any later version.
> > >> +
> > >> + * This program is distributed in the hope that it will be useful,
> > >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
> > >> + * GNU General Public License for more details.
> > >> +
> > >> + * You should have received a copy of the GNU General Public License along
> > >> + * with this program; if not, write to the Free Software Foundation, Inc.,
> > >> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> > >> + */
> > >> +
> > >> +#include <linux/dma-mapping.h>
> > >> +#include <asm/sizes.h>
> > >> +#include <mach/hardware.h>
> > >> +#include <mach/devices-common.h>
> > >> +#include <mach/ahci_sata.h>
> > >> +
> > >> +#define imx_ahci_imx_data_entry_single(soc, _devid) ? ? ? ? ?\
> > >> + ? ? { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> > >> + ? ? ? ? ? ? .devid = _devid, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> > >> + ? ? ? ? ? ? .iobase = soc ## _SATA_BASE_ADDR, ? ? ? ? ? ? ? ? ? ? ? \
> > >> + ? ? ? ? ? ? .irq = soc ## _INT_SATA, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> > >> + ? ? }
> > >> +
> > >> +#ifdef CONFIG_SOC_IMX53
> > >> +const struct imx_ahci_imx_data imx53_ahci_imx_data __initconst =
> > >> + ? ? imx_ahci_imx_data_entry_single(MX53, "imx53-ahci");
> > >> +#endif
> > >> +
> > >> +static struct ahci_platform_data default_sata_pdata = {
> > >> + ? ? .init = sata_init,
> > >> + ? ? .exit = sata_exit,
> > >> +};
>
> If we continue going the way you started, please add the
> sata_init/sata_exit functions as static functions to this file, ...
>
> > >> +
> > >> +struct platform_device *__init imx_add_ahci_imx(
> > >> + ? ? ? ? ? ? const struct imx_ahci_imx_data *data,
> > >> + ? ? ? ? ? ? const struct ahci_platform_data *pdata)
> > >> +{
> > >> + ? ? struct resource res[] = {
> > >> + ? ? ? ? ? ? {
> > >> + ? ? ? ? ? ? ? ? ? ? .start = data->iobase,
> > >> + ? ? ? ? ? ? ? ? ? ? .end = data->iobase + SZ_4K - 1,
> > >> + ? ? ? ? ? ? ? ? ? ? .flags = IORESOURCE_MEM,
> > >> + ? ? ? ? ? ? }, {
> > >> + ? ? ? ? ? ? ? ? ? ? .start = data->irq,
> > >> + ? ? ? ? ? ? ? ? ? ? .end = data->irq,
> > >> + ? ? ? ? ? ? ? ? ? ? .flags = IORESOURCE_IRQ,
> > >> + ? ? ? ? ? ? },
> > >> + ? ? };
> > >> +
> > >> + ? ? if (pdata == NULL)
> > >> + ? ? ? ? ? ? pdata = &default_sata_pdata;
>
> ...remove these two lines, and instead introduce a function like this:
>
> struct platform_device *__init imx53_add_ahci_imx(void)
> {
> struct ahci_platform_data pdata = {
> .init = imx53_sata_init,
> .exit = imx53_sata_exit,
> };
>
> return imx_add_ahci_imx(&imx53_ahci_imx_data, &pdata);
> }
>
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 1/3] include: fb: Add definiton for window positioning structure
From: Ajay kumar @ 2011-09-21 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316586336.1949.14.camel@deskari>
On Wed, Sep 21, 2011 at 11:55 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Tue, 2011-09-20 at 20:08 +0300, Baruch Siach wrote:
>> Hi Ajay,
>>
>> On Tue, Sep 20, 2011 at 08:56:57PM +0530, Ajay kumar wrote:
>> > Hi Baruch,
>> > On Tue, Sep 20, 2011 at 4:54 PM, Baruch Siach <baruch@tkos.co.il> wrote:
>> > > Hi Ajay,
>> > >
>> > > On Tue, Sep 20, 2011 at 11:30:39AM -0400, Ajay Kumar wrote:
>> > >> This patch adds a data structure definiton to hold framebuffer windows/planes.
>> > >> An ioctl number is also added to provide user access
>> > >> to change window position dynamically.
>> > >
>> > > [snip]
>> > >
>> > >> +/* Window overlaying */
>> > >> +struct fb_overlay_win_pos {
>> > >> + ? ? __u32 win_pos_x; ? ? ? ?/* x-offset from LCD(0,0) where window starts */
>> > >> + ? ? __u32 win_pos_y; ? ? ? ?/* y-offset from LCD(0,0) where window starts */
>> > >> +};
>> > >
>> > > Why not allow negative offsets where the left or upper part of the framebuffer
>> > > is hidden?
>> >
>> > Thanks for pointing it out. Are there drivers which place the overlay
>> > windows such that some part of the window is hidden from being
>> > displayed on the screen?
>>
>> I don't know. However, since this is new userspace ABI which should stay
>> compatible forever, we should make sure to do it right. Using __s32 instead of
>> __u32 won't limit us in the future.
>
> OMAP HW doesn't allow "funny" things like overlay being outside the
> visible area, i.e. negative position or size larger than the display.
> And my guess is that hardware rarely allow things like that, as it would
> just complicate the hardware without any gain.
>
> Out-of-display-overlays can of course be emulated by the software. But
> I'm not sure if it's good to add the complexity in the driver layer, as
> it could as well be handled in the userspace.
>
> Then again, a signed value would be future safer ("just in case"), and
> if the driver can just reject values it doesn't want to support, there's
> no real harm there either.
OK. I will consider this and modify it in the next version of patches.
Ajay
^ permalink raw reply
* omap3: I2C: failure in wakeup from S2R
From: Ming Lei @ 2011-09-21 7:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Looks like beagle xM can't wakeup from S2R, and the kernel is 3.1-rc4.
See dmesg below:
root at beagleboard:~#
root at beagleboard:~# echo 9 > /proc/sys/kernel/printk
root at beagleboard:~# echo platform > /sys/power/pm_test
root at beagleboard:~# echo mem > /sys/power/state
[ 69.132354] PM: Syncing filesystems ... done.
[ 78.607269] PM: Preparing system for mem sleep
[ 78.631347] Freezing user space processes ... (elapsed 0.02 seconds) done.
[ 78.664215] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) done.
[ 78.695129] PM: Entering mem sleep
[ 78.712402] usb 1-2.1: usb suspend
[ 78.739471] hub 1-2:1.0: hub_suspend
[ 78.743652] usb 1-2: unlink qh256-0001/def54320 start 1 [1/0 us]
[ 78.751007] usb 1-2: usb suspend
[ 78.778625] hub 1-0:1.0: hub_suspend
[ 78.782440] usb usb1: bus suspend
[ 78.786163] ehci-omap ehci-omap.0: suspend root hub
[ 78.916076] PM: suspend of devices complete after 206.665 msecs
[ 78.928649] omap_device: omap_hsmmc.0: new worst case deactivate
latency 0: 152587
[ 78.937438] omap_device: usbhs_omap.-1: new worst case deactivate
latency 0: 152587
[ 78.946044] PM: late suspend of devices complete after 23.620 msecs
[ 78.952728] suspend debug: Waiting for 5 seconds.
[ 83.395080] PM: early resume of devices complete after 3.936 msecs
[ 83.405548] ------------[ cut here ]------------
[ 83.410430] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162
omap3_l3_app_irq+0x114/0x15c()
[ 83.419281] In-band Error seen by MPU at address 0
[ 83.424377] Modules linked in:
[ 83.427612] [<c001ada8>] (unwind_backtrace+0x0/0x124) from
[<c004f1ac>] (warn_slowpath_common+0x54/0x6c)
[ 83.437591] [<c004f1ac>] (warn_slowpath_common+0x54/0x6c) from
[<c004f25c>] (warn_slowpath_fmt+0x34/0x44)
[ 83.447631] [<c004f25c>] (warn_slowpath_fmt+0x34/0x44) from
[<c0032298>] (omap3_l3_app_irq+0x114/0x15c)
[ 83.457489] [<c0032298>] (omap3_l3_app_irq+0x114/0x15c) from
[<c0097c4c>] (handle_irq_event_percpu+0xb8/0x280)
[ 83.467987] [<c0097c4c>] (handle_irq_event_percpu+0xb8/0x280) from
[<c0097e58>] (handle_irq_event+0x44/0x64)
[ 83.478271] [<c0097e58>] (handle_irq_event+0x44/0x64) from
[<c009a2bc>] (handle_level_irq+0xe0/0x114)
[ 83.487945] [<c009a2bc>] (handle_level_irq+0xe0/0x114) from
[<c0097678>] (generic_handle_irq+0x28/0x38)
[ 83.497833] [<c0097678>] (generic_handle_irq+0x28/0x38) from
[<c0014098>] (handle_IRQ+0x80/0xc0)
[ 83.507049] [<c0014098>] (handle_IRQ+0x80/0xc0) from [<c04072fc>]
(__irq_svc+0x3c/0x11c)
[ 83.515563] [<c04072fc>] (__irq_svc+0x3c/0x11c) from [<c0319a80>]
(omap_i2c_unidle+0x1e8/0x2ac)
[ 83.524688] [<c0319a80>] (omap_i2c_unidle+0x1e8/0x2ac) from
[<c031a144>] (omap_i2c_xfer+0x2c/0x36c)
[ 83.534179] [<c031a144>] (omap_i2c_xfer+0x2c/0x36c) from
[<c0317cc4>] (i2c_transfer+0xc0/0x150)
[ 83.543304] [<c0317cc4>] (i2c_transfer+0xc0/0x150) from
[<c02b2014>] (twl_i2c_write+0xcc/0x114)
[ 83.552429] [<c02b2014>] (twl_i2c_write+0xcc/0x114) from
[<c02b255c>] (twl4030_sih_do_mask+0x6c/0x9c)
[ 83.562103] [<c02b255c>] (twl4030_sih_do_mask+0x6c/0x9c) from
[<c0069b7c>] (process_one_work+0x2dc/0x500)
[ 83.572174] [<c0069b7c>] (process_one_work+0x2dc/0x500) from
[<c006a2a8>] (worker_thread+0x1c0/0x2d8)
[ 83.581848] [<c006a2a8>] (worker_thread+0x1c0/0x2d8) from
[<c006e0b0>] (kthread+0x8c/0x94)
[ 83.590515] [<c006e0b0>] (kthread+0x8c/0x94) from [<c00142c0>]
(kernel_thread_exit+0x0/0x8)
[ 83.599243] ---[ end trace 1b75b31a2719ed1e ]---
[ 83.617126] ------------[ cut here ]------------
[ 83.622009] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162
omap3_l3_app_irq+0x114/0x15c()
[ 83.630859] In-band Error seen by MPU at address 0
[ 83.635955] Modules linked in:
[ 83.639190] [<c001ada8>] (unwind_backtrace+0x0/0x124) from
[<c004f1ac>] (warn_slowpath_common+0x54/0x6c)
[ 83.649169] [<c004f1ac>] (warn_slowpath_common+0x54/0x6c) from
[<c004f25c>] (warn_slowpath_fmt+0x34/0x44)
[ 83.659210] [<c004f25c>] (warn_slowpath_fmt+0x34/0x44) from
[<c0032298>] (omap3_l3_app_irq+0x114/0x15c)
[ 83.669067] [<c0032298>] (omap3_l3_app_irq+0x114/0x15c) from
[<c0097c4c>] (handle_irq_event_percpu+0xb8/0x280)
[ 83.679595] [<c0097c4c>] (handle_irq_event_percpu+0xb8/0x280) from
[<c0097e58>] (handle_irq_event+0x44/0x64)
[ 83.689910] [<c0097e58>] (handle_irq_event+0x44/0x64) from
[<c009a2bc>] (handle_level_irq+0xe0/0x114)
[ 83.699584] [<c009a2bc>] (handle_level_irq+0xe0/0x114) from
[<c0097678>] (generic_handle_irq+0x28/0x38)
[ 83.709442] [<c0097678>] (generic_handle_irq+0x28/0x38) from
[<c0014098>] (handle_IRQ+0x80/0xc0)
[ 83.718688] [<c0014098>] (handle_IRQ+0x80/0xc0) from [<c04072fc>]
(__irq_svc+0x3c/0x11c)
[ 83.727203] [<c04072fc>] (__irq_svc+0x3c/0x11c) from [<c0319ac8>]
(omap_i2c_unidle+0x230/0x2ac)
[ 83.736328] [<c0319ac8>] (omap_i2c_unidle+0x230/0x2ac) from
[<c031a144>] (omap_i2c_xfer+0x2c/0x36c)
[ 83.745819] [<c031a144>] (omap_i2c_xfer+0x2c/0x36c) from
[<c0317cc4>] (i2c_transfer+0xc0/0x150)
[ 83.754943] [<c0317cc4>] (i2c_transfer+0xc0/0x150) from
[<c02b2014>] (twl_i2c_write+0xcc/0x114)
[ 83.764068] [<c02b2014>] (twl_i2c_write+0xcc/0x114) from
[<c02b255c>] (twl4030_sih_do_mask+0x6c/0x9c)
[ 83.773742] [<c02b255c>] (twl4030_sih_do_mask+0x6c/0x9c) from
[<c0069b7c>] (process_one_work+0x2dc/0x500)
[ 83.783813] [<c0069b7c>] (process_one_work+0x2dc/0x500) from
[<c006a2a8>] (worker_thread+0x1c0/0x2d8)
[ 83.793487] [<c006a2a8>] (worker_thread+0x1c0/0x2d8) from
[<c006e0b0>] (kthread+0x8c/0x94)
[ 83.802154] [<c006e0b0>] (kthread+0x8c/0x94) from [<c00142c0>]
(kernel_thread_exit+0x0/0x8)
[ 83.810913] ---[ end trace 1b75b31a2719ed1f ]---
[ 83.816131] ------------[ cut here ]------------
[ 83.820983] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162
omap3_l3_app_irq+0x114/0x15c()
[ 83.829833] In-band Error seen by MPU at address 0
[ 83.834930] Modules linked in:
[ 83.838165] [<c001ada8>] (unwind_backtrace+0x0/0x124) from
[<c004f1ac>] (warn_slowpath_common+0x54/0x6c)
[ 83.848114] [<c004f1ac>] (warn_slowpath_common+0x54/0x6c) from
[<c004f25c>] (warn_slowpath_fmt+0x34/0x44)
[ 83.858154] [<c004f25c>] (warn_slowpath_fmt+0x34/0x44) from
[<c0032298>] (omap3_l3_app_irq+0x114/0x15c)
[ 83.868041] [<c0032298>] (omap3_l3_app_irq+0x114/0x15c) from
[<c0097c4c>] (handle_irq_event_percpu+0xb8/0x280)
[ 83.878540] [<c0097c4c>] (handle_irq_event_percpu+0xb8/0x280) from
[<c0097e58>] (handle_irq_event+0x44/0x64)
[ 83.888824] [<c0097e58>] (handle_irq_event+0x44/0x64) from
[<c009a2bc>] (handle_level_irq+0xe0/0x114)
[ 83.898498] [<c009a2bc>] (handle_level_irq+0xe0/0x114) from
[<c0097678>] (generic_handle_irq+0x28/0x38)
[ 83.908325] [<c0097678>] (generic_handle_irq+0x28/0x38) from
[<c0014098>] (handle_IRQ+0x80/0xc0)
[ 83.917572] [<c0014098>] (handle_IRQ+0x80/0xc0) from [<c04072fc>]
(__irq_svc+0x3c/0x11c)
[ 83.926055] [<c04072fc>] (__irq_svc+0x3c/0x11c) from [<c031a144>]
(omap_i2c_xfer+0x2c/0x36c)
[ 83.934936] [<c031a144>] (omap_i2c_xfer+0x2c/0x36c) from
[<c0317cc4>] (i2c_transfer+0xc0/0x150)
[ 83.944061] [<c0317cc4>] (i2c_transfer+0xc0/0x150) from
[<c02b2014>] (twl_i2c_write+0xcc/0x114)
[ 83.953186] [<c02b2014>] (twl_i2c_write+0xcc/0x114) from
[<c02b255c>] (twl4030_sih_do_mask+0x6c/0x9c)
[ 83.962829] [<c02b255c>] (twl4030_sih_do_mask+0x6c/0x9c) from
[<c0069b7c>] (process_one_work+0x2dc/0x500)
[ 83.972900] [<c0069b7c>] (process_one_work+0x2dc/0x500) from
[<c006a2a8>] (worker_thread+0x1c0/0x2d8)
[ 83.982543] [<c006a2a8>] (worker_thread+0x1c0/0x2d8) from
[<c006e0b0>] (kthread+0x8c/0x94)
[ 83.991210] [<c006e0b0>] (kthread+0x8c/0x94) from [<c00142c0>]
(kernel_thread_exit+0x0/0x8)
[ 83.999969] ---[ end trace 1b75b31a2719ed20 ]---
[ 84.004974] Unhandled fault: external abort on non-linefetch
(0x1028) at 0xfa070008
[ 84.013000] Internal error: : 1028 [#1] PREEMPT SMP
[ 84.018127] Modules linked in:
[ 84.021331] CPU: 0 Tainted: G W (3.1.0-rc4+ #226)
[ 84.027435] PC is at omap_i2c_wait_for_bb+0x6c/0x84
[ 84.032562] LR is at omap_i2c_wait_for_bb+0x20/0x84
[ 84.037689] pc : [<c0319880>] lr : [<c0319834>] psr: 20000013
[ 84.037689] sp : def43e80 ip : 00000000 fp : c0f6045c
[ 84.049682] r10: 00000001 r9 : decee8b8 r8 : 00000001
[ 84.055145] r7 : c0f605d8 r6 : decee800 r5 : ffff949d r4 : decee800
[ 84.061981] r3 : 00000008 r2 : fa070000 r1 : 83126e98 r0 : 00000080
[ 84.068847] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 84.076507] Control: 10c5387d Table: 9e44c019 DAC: 00000015
[ 84.082519] Process kworker/u:2 (pid: 480, stack limit = 0xdef422f8)
[ 84.089172] Stack: (0xdef43e80 to 0xdef44000)
[ 84.093749] 3e80: 0000001f decee868 c0f605d8 c031a14c 00000001
def42000 def43eac c04090cc
[ 84.102355] 3ea0: c0f605f4 60000013 c0f6045c decee868 00000000
ffff93d0 c0f605d8 00000001
[ 84.110900] 3ec0: 00000002 00000000 c0f6045c c0317cc4 decf7c00
def43f1c c0f605f0 0000002f
[ 84.119476] 3ee0: c0f60454 00000174 c07c4c18 c02b2014 00000001
c043915f ded23bd0 c09e05c0
[ 84.128051] 3f00: decf2400 00000000 00000000 00000002 c02b24f0
c02b255c ded23bd0 fffff22f
[ 84.136627] 3f20: c07d5a24 deecb1e0 ded23bd0 c0069b7c 00000002
00000000 c0069a8c c0080a18
[ 84.145202] 3f40: ded4a120 00000000 c0f606bc 00000000 00000000
c0545f89 00000000 00000000
[ 84.153808] 3f60: 00000001 deecb1e0 c09e05c0 deecb1f0 c09e05c0
c09e05c0 00000000 00000089
[ 84.162353] 3f80: 00000000 c006a2a8 00000000 dec81edc deecb1e0
c006a0e8 00000013 00000000
[ 84.170928] 3fa0: 00000000 c006e0b0 00000000 deecb1e0 00000000
00000000 00000000 dead4ead
[ 84.179504] 3fc0: ffffffff ffffffff c09e0bd8 00000000 00000000
c053aec3 00000000 00000000
[ 84.188110] 3fe0: def43fe0 def43fe0 dec81edc c006e024 c00142c0
c00142c0 00000000 00000000
[ 84.196685] [<c0319880>] (omap_i2c_wait_for_bb+0x6c/0x84) from
[<c031a14c>] (omap_i2c_xfer+0x34/0x36c)
[ 84.206451] [<c031a14c>] (omap_i2c_xfer+0x34/0x36c) from
[<c0317cc4>] (i2c_transfer+0xc0/0x150)
[ 84.215576] [<c0317cc4>] (i2c_transfer+0xc0/0x150) from
[<c02b2014>] (twl_i2c_write+0xcc/0x114)
[ 84.224700] [<c02b2014>] (twl_i2c_write+0xcc/0x114) from
[<c02b255c>] (twl4030_sih_do_mask+0x6c/0x9c)
[ 84.234374] [<c02b255c>] (twl4030_sih_do_mask+0x6c/0x9c) from
[<c0069b7c>] (process_one_work+0x2dc/0x500)
[ 84.244415] [<c0069b7c>] (process_one_work+0x2dc/0x500) from
[<c006a2a8>] (worker_thread+0x1c0/0x2d8)
[ 84.254089] [<c006a2a8>] (worker_thread+0x1c0/0x2d8) from
[<c006e0b0>] (kthread+0x8c/0x94)
[ 84.262756] [<c006e0b0>] (kthread+0x8c/0x94) from [<c00142c0>]
(kernel_thread_exit+0x0/0x8)
[ 84.271484] Code: e5d32002 e594300c e1a03312 e5942004 (e19200b3)
[ 84.277893] ------------[ cut here ]------------
[ 84.282745] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162
omap3_l3_app_irq+0x114/0x15c()
[ 84.291595] In-band Error seen by MPU at address 0
[ 84.296691] Modules linked in:
[ 84.299926] [<c001ada8>] (unwind_backtrace+0x0/0x124) from
[<c004f1ac>] (warn_slowpath_common+0x54/0x6c)
[ 84.309875] [<c004f1ac>] (warn_slowpath_common+0x54/0x6c) from
[<c004f25c>] (warn_slowpath_fmt+0x34/0x44)
[ 84.319915] [<c004f25c>] (warn_slowpath_fmt+0x34/0x44) from
[<c0032298>] (omap3_l3_app_irq+0x114/0x15c)
[ 84.329772] [<c0032298>] (omap3_l3_app_irq+0x114/0x15c) from
[<c0097c4c>] (handle_irq_event_percpu+0xb8/0x280)
[ 84.340270] [<c0097c4c>] (handle_irq_event_percpu+0xb8/0x280) from
[<c0097e58>] (handle_irq_event+0x44/0x64)
[ 84.350585] [<c0097e58>] (handle_irq_event+0x44/0x64) from
[<c009a2bc>] (handle_level_irq+0xe0/0x114)
[ 84.360260] [<c009a2bc>] (handle_level_irq+0xe0/0x114) from
[<c0097678>] (generic_handle_irq+0x28/0x38)
[ 84.370117] [<c0097678>] (generic_handle_irq+0x28/0x38) from
[<c0014098>] (handle_IRQ+0x80/0xc0)
[ 84.379364] [<c0014098>] (handle_IRQ+0x80/0xc0) from [<c04072fc>]
(__irq_svc+0x3c/0x11c)
[ 84.387847] [<c04072fc>] (__irq_svc+0x3c/0x11c) from [<c0407064>]
(_raw_spin_unlock_irq+0x34/0x58)
[ 84.397247] [<c0407064>] (_raw_spin_unlock_irq+0x34/0x58) from
[<c00173d8>] (die+0x160/0x1e0)
[ 84.406188] [<c00173d8>] (die+0x160/0x1e0) from [<c00088a0>]
(do_DataAbort+0x8c/0xa0)
[ 84.414398] [<c00088a0>] (do_DataAbort+0x8c/0xa0) from [<c040729c>]
(__dabt_svc+0x3c/0x60)
[ 84.423065] Exception stack(0xdef43e38 to 0xdef43e80)
[ 84.428344] 3e20:
00000080 83126e98
[ 84.436920] 3e40: fa070000 00000008 decee800 ffff949d decee800
c0f605d8 00000001 decee8b8
[ 84.445526] 3e60: 00000001 c0f6045c 00000000 def43e80 c0319834
c0319880 20000013 ffffffff
[ 84.454101] [<c040729c>] (__dabt_svc+0x3c/0x60) from [<c0319880>]
(omap_i2c_wait_for_bb+0x6c/0x84)
[ 84.463500] [<c0319880>] (omap_i2c_wait_for_bb+0x6c/0x84) from
[<c031a14c>] (omap_i2c_xfer+0x34/0x36c)
[ 84.473266] [<c031a14c>] (omap_i2c_xfer+0x34/0x36c) from
[<c0317cc4>] (i2c_transfer+0xc0/0x150)
[ 84.482391] [<c0317cc4>] (i2c_transfer+0xc0/0x150) from
[<c02b2014>] (twl_i2c_write+0xcc/0x114)
[ 84.491485] [<c02b2014>] (twl_i2c_write+0xcc/0x114) from
[<c02b255c>] (twl4030_sih_do_mask+0x6c/0x9c)
[ 84.501190] [<c02b255c>] (twl4030_sih_do_mask+0x6c/0x9c) from
[<c0069b7c>] (process_one_work+0x2dc/0x500)
[ 84.511199] [<c0069b7c>] (process_one_work+0x2dc/0x500) from
[<c006a2a8>] (worker_thread+0x1c0/0x2d8)
[ 84.520874] [<c006a2a8>] (worker_thread+0x1c0/0x2d8) from
[<c006e0b0>] (kthread+0x8c/0x94)
[ 84.529541] [<c006e0b0>] (kthread+0x8c/0x94) from [<c00142c0>]
(kernel_thread_exit+0x0/0x8)
[ 84.538299] ---[ end trace 1b75b31a2719ed21 ]---
[ 84.543212] ---[ end trace 1b75b31a2719ed22 ]---
[ 84.548309] Unable to handle kernel paging request at virtual
address fffffffc
[ 84.555877] pgd = c0004000
[ 84.558715] [fffffffc] *pgd=9f3fe821, *pte=00000000, *ppte=00000000
[ 84.565307] Internal error: Oops: 17 [#2] PREEMPT SMP
[ 84.570617] Modules linked in:
[ 84.573822] CPU: 0 Tainted: G D W (3.1.0-rc4+ #226)
[ 84.579956] PC is at kthread_data+0xc/0x14
[ 84.584259] LR is at wq_worker_sleeping+0x14/0xb8
[ 84.589172] pc : [<c006e3b0>] lr : [<c006a414>] psr: 00000193
[ 84.589172] sp : def43cb0 ip : 00000000 fp : def43d4c
[ 84.601226] r10: ded4a3a8 r9 : 00000000 r8 : ded4a32c
[ 84.606689] r7 : 00000001 r6 : c14d5740 r5 : 00000000 r4 : c14d5740
[ 84.613555] r3 : 00000000 r2 : 92696d3d r1 : 00000000 r0 : ded4a120
[ 84.620391] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment user
[ 84.627960] Control: 10c5387d Table: 9e44c019 DAC: 00000015
[ 84.633972] Process kworker/u:2 (pid: 480, stack limit = 0xdef422f8)
[ 84.640655] Stack: (0xdef43cb0 to 0xdef44000)
[ 84.645202] 3ca0: c14d5740
ded4a120 c14d5740 c04030bc
[ 84.653808] 3cc0: c04070c4 c04070c4 c009d748 c009d748 c009d850
c00530f4 000005fe ded4af50
[ 84.662384] 3ce0: c14d3bac c009d850 60000113 00000000 def050e4
c0083374 ded4af50 c14d3bac
[ 84.670959] 3d00: c07ace00 c009d850 ded4a120 ded4a120 00000000
00000000 00000001 c0051aa8
[ 84.679534] 3d20: 00000001 00000000 c0051760 ded4a120 00000001
dec40020 00000001 ded4a32c
[ 84.688110] 3d40: ded4a118 00000001 c0f6045c c00530f4 def43d50
def43d50 def43e38 def42000
[ 84.696685] 3d60: ded4a120 00000001 00001028 decee8b8 00000001
c001742c def422f8 0000000b
[ 84.705291] 3d80: 00001028 c0784a30 fa070008 def43e38 c07849b0
c00088a0 00000000 00000001
[ 84.713867] 3da0: 00000007 00000000 00000000 fa070008 00000009
c00834e8 00000000 c07ace00
[ 84.722442] 3dc0: c005602c c005602c 00000001 ded4a120 def42000
c005602c 00000101 0000000a
[ 84.731048] 3de0: c009e4d8 c009e4d8 def43e20 ded4a120 c00565dc
c00565dc c0407294 c0407294
[ 84.739593] 3e00: def43e80 ded4a120 def42000 c0407294 def43e6c
00000001 decee8b8 00000001
[ 84.748199] 3e20: c0319880 20000013 ffffffff def43e6c 00000001
c040729c 00000080 83126e98
[ 84.756774] 3e40: fa070000 00000008 decee800 ffff949d decee800
c0f605d8 00000001 decee8b8
[ 84.765350] 3e60: 00000001 c0f6045c 00000000 def43e80 c0319834
c0319880 20000013 ffffffff
[ 84.773925] 3e80: 0000001f decee868 c0f605d8 c031a14c 00000001
def42000 def43eac c04090cc
[ 84.782531] 3ea0: c0f605f4 60000013 c0f6045c decee868 00000000
ffff93d0 c0f605d8 00000001
[ 84.791107] 3ec0: 00000002 00000000 c0f6045c c0317cc4 decf7c00
def43f1c c0f605f0 0000002f
[ 84.799682] 3ee0: c0f60454 00000174 c07c4c18 c02b2014 00000001
c043915f ded23bd0 c09e05c0
[ 84.808258] 3f00: decf2400 00000000 00000000 00000002 c02b24f0
c02b255c ded23bd0 fffff22f
[ 84.816833] 3f20: c07d5a24 deecb1e0 ded23bd0 c0069b7c 00000002
00000000 c0069a8c c0080a18
[ 84.825408] 3f40: ded4a120 00000000 c0f606bc 00000000 00000000
c0545f89 00000000 00000000
[ 84.833984] 3f60: 00000001 deecb1e0 c09e05c0 deecb1f0 c09e05c0
c09e05c0 00000000 00000089
[ 84.842559] 3f80: 00000000 c006a2a8 00000000 dec81edc deecb1e0
c006a0e8 00000013 00000000
[ 84.851135] 3fa0: 00000000 c006e0b0 00000000 deecb1e0 00000001
00000000 00000000 dead4ead
[ 84.859710] 3fc0: ffffffff ffffffff c09e0bd8 00000000 00000000
c053aec3 00000000 00000000
[ 84.868286] 3fe0: def43fe0 def43fe0 dec81edc c006e024 c00142c0
c00142c0 00000000 00000000
[ 84.876892] [<c006e3b0>] (kthread_data+0xc/0x14) from [<c006a414>]
(wq_worker_sleeping+0x14/0xb8)
[ 84.886199] [<c006a414>] (wq_worker_sleeping+0x14/0xb8) from
[<c04030bc>] (schedule+0x13c/0x92c)
[ 84.895416] [<c04030bc>] (schedule+0x13c/0x92c) from [<c00530f4>]
(do_exit+0x6b8/0x6f0)
[ 84.903808] [<c00530f4>] (do_exit+0x6b8/0x6f0) from [<c001742c>]
(die+0x1b4/0x1e0)
[ 84.911773] [<c001742c>] (die+0x1b4/0x1e0) from [<c00088a0>]
(do_DataAbort+0x8c/0xa0)
[ 84.919982] [<c00088a0>] (do_DataAbort+0x8c/0xa0) from [<c040729c>]
(__dabt_svc+0x3c/0x60)
[ 84.928649] Exception stack(0xdef43e38 to 0xdef43e80)
[ 84.933929] 3e20:
00000080 83126e98
[ 84.942504] 3e40: fa070000 00000008 decee800 ffff949d decee800
c0f605d8 00000001 decee8b8
[ 84.951080] 3e60: 00000001 c0f6045c 00000000 def43e80 c0319834
c0319880 20000013 ffffffff
[ 84.959655] [<c040729c>] (__dabt_svc+0x3c/0x60) from [<c0319880>]
(omap_i2c_wait_for_bb+0x6c/0x84)
[ 84.969055] [<c0319880>] (omap_i2c_wait_for_bb+0x6c/0x84) from
[<c031a14c>] (omap_i2c_xfer+0x34/0x36c)
[ 84.978790] [<c031a14c>] (omap_i2c_xfer+0x34/0x36c) from
[<c0317cc4>] (i2c_transfer+0xc0/0x150)
[ 84.987915] [<c0317cc4>] (i2c_transfer+0xc0/0x150) from
[<c02b2014>] (twl_i2c_write+0xcc/0x114)
[ 84.997039] [<c02b2014>] (twl_i2c_write+0xcc/0x114) from
[<c02b255c>] (twl4030_sih_do_mask+0x6c/0x9c)
[ 85.006713] [<c02b255c>] (twl4030_sih_do_mask+0x6c/0x9c) from
[<c0069b7c>] (process_one_work+0x2dc/0x500)
[ 85.016754] [<c0069b7c>] (process_one_work+0x2dc/0x500) from
[<c006a2a8>] (worker_thread+0x1c0/0x2d8)
[ 85.026428] [<c006a2a8>] (worker_thread+0x1c0/0x2d8) from
[<c006e0b0>] (kthread+0x8c/0x94)
[ 85.035095] [<c006e0b0>] (kthread+0x8c/0x94) from [<c00142c0>]
(kernel_thread_exit+0x0/0x8)
[ 85.043853] Code: c0411788 e52de004 e8bd4000 e590325c (e5130004)
--
Ming Lei
^ permalink raw reply
* [PATCH 1/3] include: fb: Add definiton for window positioning structure
From: Ajay kumar @ 2011-09-21 7:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E78C579.9060305@gmx.de>
Hi Florian,
On Tue, Sep 20, 2011 at 10:25 PM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> On 09/20/2011 03:39 PM, Tomi Valkeinen wrote:
>> On Tue, 2011-09-20 at 20:16 +0530, Ajay kumar wrote:
>>> Hi Tomi,
>>>
>>> On Tue, Sep 20, 2011 at 4:40 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>> On Tue, 2011-09-20 at 11:30 -0400, Ajay Kumar wrote:
>>>>> This patch adds a data structure definiton to hold framebuffer windows/planes.
>>>>> An ioctl number is also added to provide user access
>>>>> to change window position dynamically.
>
> Ajay, do you need this urgently or can we delay this one merge window? I don't
> think that a week or so is enough to get a consistent API that gets everything
> right. So if you have a pressing need to have it within the 3.2 kernel I'd
> prefer to do it only for your driver now and adjust it when we get the thing
> done, probably in 3.3.
No. I am not in a hurry, and I do not have any issue even if it takes
more time to get a consistent API.
>>>>>
>>>>> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>>>>> Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
>>>>> Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>> ---
>>>>> ?include/linux/fb.h | ? ?7 +++++++
>>>>> ?1 files changed, 7 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/include/linux/fb.h b/include/linux/fb.h
>>>>> index 1d6836c..2141941 100644
>>>>> --- a/include/linux/fb.h
>>>>> +++ b/include/linux/fb.h
>>>>> @@ -39,6 +39,7 @@
>>>>> ?#define FBIOPUT_MODEINFO ? ? ? ?0x4617
>>>>> ?#define FBIOGET_DISPINFO ? ? ? ?0x4618
>>>>> ?#define FBIO_WAITFORVSYNC ? ?_IOW('F', 0x20, __u32)
>>>>> +#define FBIOPOS_OVERLAY_WIN ?_IOW('F', 0x21, struct fb_overlay_win_pos)
>>>>>
>>>>> ?#define FB_TYPE_PACKED_PIXELS ? ? ? ? ? ? ? ?0 ? ? ? /* Packed Pixels ? ? ? ?*/
>>>>> ?#define FB_TYPE_PLANES ? ? ? ? ? ? ? ? ? ? ? 1 ? ? ? /* Non interleaved planes */
>>>>> @@ -366,6 +367,12 @@ struct fb_image {
>>>>> ? ? ? struct fb_cmap cmap; ? ?/* color map info */
>>>>> ?};
>>>>>
>>>>> +/* Window overlaying */
>>>>> +struct fb_overlay_win_pos {
>>>>> + ? ? __u32 win_pos_x; ? ? ? ?/* x-offset from LCD(0,0) where window starts */
>>>>> + ? ? __u32 win_pos_y; ? ? ? ?/* y-offset from LCD(0,0) where window starts */
>>>>> +};
>>>>
>>>> Shouldn't this also include the window size (in case scaling is
>>>> supported)?
>>>
>>> The "xres" and "yres" fields in fb_var_screeninfo are being used to
>>> represent the size of the window (visible resolution). So we have,
>>>
>>> win_pos_x: x-offset from LCD(0,0) where window starts.
>>> win_pos_y: y-offset from LCD(0,0) where window starts.
>>> (win_pos_x + xres) : x-offset from LCD(0,0) where window ends.
>>> (win_pos_y + yres) : y-offset from LCD(0,0) where window ends.
>>
>> Sure, but the xres and yres tell the _input_ resolution, i.e. how many
>> pixels are read from the memory. What is missing is the _output_
>> resolution, which is the size of the window. These are not necessarily
>> the same, if the system supports scaling.
>
> I agree, scaling is an issue that should get solved on the way. So adding
> u32 width, height;
> with an initial/special value of 0 which means just take what the source
> width/height is.
Do you mean to say the "width" and the "height" fields which you are
suggesting, will represent the "output resolution" which OMAP needs?
>>>> This also won't work for setups where the same framebuffer is used by
>>>> multiple overlays. For example, this is the case on OMAP when the same
>>>> content is cloned to, say, LCD and TV, each of which is showing an
>>>> overlay.
>>>
>>> These x and y position are used to configure the display controller
>>> (for LCD only) and not to alter the data in physical buffer
>>> (framebuffer). Could you elaborate the above use case you have
>>> mentioned and how adding the x and y offsets would not meet that
>>> requirement.
>>
>> Nothing wrong with adding x/y offsets, but the problem is in configuring
>> the two overlays. If the framebuffer data is used by two overlays, each
>> overlay should be configured separately. And your ioctl does not have
>> any way to define which overlay is being affected.
>
> Did you have a look at the (existing) API [1] Laurent proposed for discovering
> the internal connections between the framebuffers (or with any other devices)?
> If you agree that it'd be a good idea to use it I feel that we should make the
> windowing API more compatible with it. So basically what we want to have as a
> window is one or more sunk pads so the pad-index should be also part of the
> interface. I'm still confused with how OMAP works when it does not have a "root"
> window/framebuffer. Normally I feel that the window position should be a
> property of the parent window as this is what the position is relative too. But
> if the parent is no framebuffer, should we also include the entity into the
> interface to allow configuring things that are nor even framebuffers?
> Also I think we need a z-index in case overlays overlap (might happen or?) and
> enforcing that all z-indexes are different for the same entity.
>
>> Of course, if we specify that a single framebuffer will ever go only to
>> one output, the problem disappears.
>>
>> However, even if we specify so, this will make the fbdev a bit weird:
>> what is x/yres after this patch? In the current fbdev x/yres is the size
>> of the output, and x/yres are part of video timings. After this patch
>> this is no longer the case: x/yres will be the size of the overlay. But
>> the old code will still use x/yres as part of video timings, making
>> things confusing.
>
> As I see it xres/yres (together with xoffset/yoffset) is always the visible part
> of the framebuffer. Typically that's also part of the timings as they define
> what is visible. With the introduction of overlays (and maybe even for some
> hardware anyway) it is no longer always true to have any timings at all. So on
> all framebuffer that do not have physical timings the timing interpretation is
> useless anyway (I'm thinking about adding a FB_CAP_NOTIMING) and what remains is
> the interpretation of xres/yres as visible screen region.
>
>> And generally I can't really make my mind about adding these more
>> complex features. On one hand it would be very nice to have fbdev
>> supporting overlays and whatnot, but on the other hand, I can't figure
>> out how to add them properly.
>
> I don't see it as adding new features, rather unifying what is already there for
> easier use. Sure it should be done in a consistent way.
>
>
> Best regards,
>
> Florian Tobias Schandinat
>
Ajay
> [1] http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 0/3] GIC OF bindings
From: Mitch Bradley @ 2011-09-21 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110921.012158.2252182592946972727.davem@davemloft.net>
On 9/20/2011 7:21 PM, David Miller wrote:
> From: Mitch Bradley<wmb@firmworks.com>
> Date: Tue, 20 Sep 2011 18:58:12 -1000
>
>> interrupt-parent has been part of the interrupt mapping spec from the
>> inception of same.
>>
>> http://www.openfirmware.info/docs/rec.intmap.d09.pdf
>
> Thanks for the link.
>
> In my vast collection of Sun OF dumps, I cannot find a single instance
> where they've made use of this property, which is why I've never seen
> it before.
I can't say I'm surprised at that. Sun hardware tends to be rather more
hierarchical than is the norm in, for example, the PC space. This
particular document came into being during the CHRP era, when IBM and
Apple were trying to glue a Macintosh legacy I/O system onto the side of
a PC legacy I/O system. The result was not pretty.
Sun had at least the semblance of a coherent architectural design and
review process.
^ permalink raw reply
* [GIT PULL] omap cleanup part1 for v3.2 merge window
From: Arnd Bergmann @ 2011-09-21 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920223311.GK2937@atomide.com>
On Tuesday 20 September 2011 15:33:12 Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [110920 14:12]:
> > On Tuesday 20 September 2011, Arnd Bergmann wrote:
> > >
> > > One more thing: my randconfig tests are running now and
> > > have spit out a new error after merging lost of stuff
> > > today:
>
> Good to hear you got "arndconfig" running :)
>
> Do you think we could also add support for something
> like this:
>
> $ echo CONFIG_ARCH_OMAP=y > .config
> $ make randconfig
>
> or
>
> $ make --force=CONFIG_ARCH_OMAP randconfig
>
> Where randconfig would keep the forced CONFIG_ARCH_OMAP
> static while randomly selecting the others?
>
> This would allow targeted randconfig for each patch more
> or less..
The mechanism I use is setting KCONFIG_ALLCONFIG= to a file
that has the options I want to have set to a specific value.
If you don't do that, randconfig will take the default option
for each 'choice' statement, which means we build for the
ARCH_VERSATILE platform.
See the script I'm using at the end of this mail. It should
be easy for you to pick out the parts you need.
> > It seems that you replace the #ifdef in the board-flash.c file
> > with a similar #ifdef in the header that replaces this with an
> > empty inline function when the object is not built.
>
> Oops. I'll do a fix for that. Those should be now inline
> functions in the header.
>
> As various other omap branches are based on the cleanup I'd
> rather not go mess with the original patch unless you insist.
Totally fine with me. This is just a corner case anyway, since most
configurations will have flash enabled I guess.
Arnd
8<---
#!/bin/bash
export ARCH=arm
export PATH=/usr/bin:/bin
export CROSS_COMPILE=arm-linux-gnueabihf-
export PARALLEL=-j6
export CCACHE_DISABLE=1
export O=$PWD/obj-tmp
gen_allconfig()
{
declare -a MACH
MACH[1]=OMAP
MACH[2]=EXYNOS4
MACH[3]=U8500
MACH[4]=VEXPRESS
MACH[5]=MXC
MACH[6]=MSM
MACH[7]=PXA
MACH[8]=MMP
MACH[9]=DOVE
MACH[10]=KIRKWOOD
MACH[11]=ZYNQ
MACH[12]=PRIMA2
MACH[13]=TEGRA
MACH[14]=SHMOBILE
declare -a MXC
MXC[1]=MX3
MXC[2]=MX503
MXC[3]=MX51
declare -a AT91
AT91[1]=ARCH_AT91RM9200
AT91[2]=ARCH_AT91SAM9260
AT91[3]=ARCH_AT91SAM9261
AT91[4]=ARCH_AT91SAM9G10
AT91[5]=ARCH_AT91SAM9263
AT91[6]=ARCH_AT91SAM9RL
AT91[7]=ARCH_AT91SAM9G20
AT91[8]=ARCH_AT91SAM9G45
AT91[9]=ARCH_AT91CAP9
AT91[10]=ARCH_AT91X40
# pick one ARCH_* option from the main choice statement
echo "CONFIG_ARCH_${MACH[$[ $RANDOM % ${#MACH[@]} +1 ]]}=y"
# IMX and AT91 have another choice statement
echo "CONFIG_ARCH_${MXC[$[ $RANDOM % ${#MXC[@]} +1 ]]}=y"
echo "CONFIG_${MXC[$[ $RANDOM % ${#AT91[@]} +1 ]]}=y"
# These have to be fixed in order to avoid huge build breakage.
echo "# CONFIG_XIP_KERNEL is not set"
echo "# CONFIG_STAGING is not set"
echo "CONFIG_MMU=y"
echo "CONFIG_PREVENT_FIRMWARE_BUILD=y"
# add a few choice options that don't normally get selected
[ $[RANDOM % 2 ] == 1 ] || echo "CONFIG_PROFILE_ALL_BRANCHES=y"
[ $[RANDOM % 2 ] == 1 ] || echo "CONFIG_SLAB=y"
[ $[RANDOM % 2 ] == 1 ] || echo "CONFIG_PREEMPT=y"
}
prepare()
{
mkdir -p ${O}
make O=${O} clean
gen_allconfig > ${O}/allconfig
make O=${O} KCONFIG_ALLCONFIG=${O}/allconfig randconfig
}
mkdir -p out
prepare
for i in `seq -w 9999` ; do
if ! make O=${O} -k -s ${PARALLEL} CFLAGS_KERNEL+=-Wno-uninitialized KALLSYMS_EXTRA_PASS=1 2> out/warnings-$i ; then
make O=${O} -k -s CFLAGS_KERNEL+=-Wno-uninitialized KALLSYMS_EXTRA_PASS=1 2> out/errors-$i
cp ${O}/.config out/config-broken-$i
else
cp ${O}/.config out/config-ok-$i
fi
prepare
done
^ permalink raw reply
* [PATCH V7 1/5] AHCI Add the AHCI SATA feature on the MX53 platforms
From: Richard Zhu @ 2011-09-21 7:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJNCFVJ4EGQQ2CcRsPK6OidbU2uBEDertn8R9BuqxYGSBmxbPg@mail.gmail.com>
Hi Sascha:
One proposal about how to convert the ahci driver to devicetree in future.
ahci driver system can make a reference to the evolution of the sdhc driver.
* separate the ahci to ahci common codes, ahci-pci driver and
ahci-platform driver.
* create kinds of ahci vendor's own ahci platform driver refer to the
sdhci-xxx driver solutions.
* then we can convert the ahci driver to devicetree smoothly.
It's a long term evolution.
Hi Jeff:
Do you have any suggestions or advices about it?
Best Regard
Richard Zhu
On 21 September 2011 13:04, Richard Zhu <richard.zhu@linaro.org> wrote:
> Hi Sascha:
> Thanks for your comments.
>
> Best Regard
> Richard Zhu
>
> On 21 September 2011 04:30, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> On Wed, Aug 31, 2011 at 11:50:31AM +0800, Richard Zhu wrote:
>>> Signed-off-by: Richard Zhu <richard.zhu@linaro.org>
>>> Tested-By: Hector Oron Martinez <hector.oron@gmail.com>
>>> ---
>>> ?arch/arm/mach-mx5/clock-mx51-mx53.c ? ? ? ? ? ? | ? 19 ++++
>>> ?arch/arm/mach-mx5/devices-imx53.h ? ? ? ? ? ? ? | ? ?4 +
>>> ?arch/arm/plat-mxc/Makefile ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
>>> ?arch/arm/plat-mxc/ahci_sata.c ? ? ? ? ? ? ? ? ? | ?104 +++++++++++++++++++++++
>>> ?arch/arm/plat-mxc/devices/Kconfig ? ? ? ? ? ? ? | ? ?4 +
>>> ?arch/arm/plat-mxc/devices/Makefile ? ? ? ? ? ? ?| ? ?1 +
>>> ?arch/arm/plat-mxc/devices/platform-ahci-imx.c ? | ? 66 ++++++++++++++
>>> ?arch/arm/plat-mxc/include/mach/ahci_sata.h ? ? ?| ? 33 +++++++
>>> ?arch/arm/plat-mxc/include/mach/devices-common.h | ? 10 ++
>>> ?9 files changed, 242 insertions(+), 0 deletions(-)
>>> ?create mode 100644 arch/arm/plat-mxc/ahci_sata.c
>>> ?create mode 100644 arch/arm/plat-mxc/devices/platform-ahci-imx.c
>>> ?create mode 100644 arch/arm/plat-mxc/include/mach/ahci_sata.h
>>>
>>> diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
>>> index 7f20308..e1fadaf 100644
>>> --- a/arch/arm/mach-mx5/clock-mx51-mx53.c
>>> +++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
>>> @@ -1397,6 +1397,22 @@ static struct clk esdhc4_mx53_clk = {
>>> ? ? ? .secondary = &esdhc4_ipg_clk,
>>> ?};
>>>
>>> diff --git a/arch/arm/plat-mxc/ahci_sata.c b/arch/arm/plat-mxc/ahci_sata.c
>>> new file mode 100644
>>> index 0000000..4f54816
>>> --- /dev/null
>>> +++ b/arch/arm/plat-mxc/ahci_sata.c
>>> @@ -0,0 +1,104 @@
>>> +/*
>>> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
>>> + */
>>> +
>>> +/*
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> +
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
>>> + * GNU General Public License for more details.
>>> +
>>> + * You should have received a copy of the GNU General Public License along
>>> + * with this program; if not, write to the Free Software Foundation, Inc.,
>>> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>>> + */
>>> +
>>> +#include <linux/io.h>
>>> +#include <linux/clk.h>
>>> +#include <linux/err.h>
>>> +#include <linux/device.h>
>>> +#include <mach/ahci_sata.h>
>>> +
>>> +static struct clk *sata_clk, *sata_ref_clk;
>>
>> These variables make the driver single instance only.
> [Richard Zhu] In order to handle the clock enable/disable stuff, these
> two variables are mandatory required.
> Otherwise, new two struct clk members had to be added into
> ahci_platform_data struct. Then the clks can
> be transferred by the platform data.
> The current is preferred, refer to the second choice.
>>
>>> +
>>> +/* AHCI module Initialization, if return 0, initialization is successful. */
>>> +int sata_init(struct device *dev, void __iomem *addr)
>>
>> A global function with such a generic name is not a good idea.
>> Also I wonder how we want to convert this to devicetree when we
>> implement this as a platform specific hook. It should be done in the
>> driver.
>>
> [Richard Zhu] The name of these two func can be changed.
> But I don't have a good idea to move out these two platform specific
> hooks (->init, ->exit).
>
> Refer to you comments, do you means that the ->init and ->exit should
> be done in ahci_platform.c driver?
> Different platform may have the different ->init and ->exit funcs to
> handle it's own initialization and exit.
> It would be a problem that handle all kinds of init in one driver
> without the hooks.
>
>>> +{
>>> + ? ? u32 tmpdata;
>>> + ? ? int ret = 0;
>>> + ? ? struct clk *clk;
>>> +
>>> + ? ? sata_clk = clk_get(dev, "ahci");
>>> + ? ? if (IS_ERR(sata_clk)) {
>>> + ? ? ? ? ? ? dev_err(dev, "no sata clock.\n");
>>> + ? ? ? ? ? ? return PTR_ERR(sata_clk);
>>> + ? ? }
>>> + ? ? ret = clk_enable(sata_clk);
>>> + ? ? if (ret) {
>>> + ? ? ? ? ? ? dev_err(dev, "can't enable sata clock.\n");
>>> + ? ? ? ? ? ? goto put_sata_clk;
>>> + ? ? }
>>> +
>>> + ? ? /* FSL IMX AHCI SATA uses the internal usb phy1 clk on loco */
>>
>> So this function is loco specific or is the comment wrong?
> [Richard Zhu] Comments wrong, they're common codes and should't be
> specified by the exact
> ?board, would be changed later.
>>
>>> + ? ? sata_ref_clk = clk_get(dev, "ahci_phy");
>>> + ? ? if (IS_ERR(sata_ref_clk)) {
>>> + ? ? ? ? ? ? dev_err(dev, "no sata ref clock.\n");
>>> + ? ? ? ? ? ? ret = PTR_ERR(sata_ref_clk);
>>> + ? ? ? ? ? ? goto release_sata_clk;
>>> + ? ? }
>>> + ? ? ret = clk_enable(sata_ref_clk);
>>> + ? ? if (ret) {
>>> + ? ? ? ? ? ? dev_err(dev, "can't enable sata ref clock.\n");
>>> + ? ? ? ? ? ? goto put_sata_ref_clk;
>>> + ? ? }
>>> +
>>> + ? ? /* Get the AHB clock rate, and configure the TIMER1MS reg later */
>>> + ? ? clk = clk_get(dev, "ahci_dma");
>>> + ? ? if (IS_ERR(clk)) {
>>> + ? ? ? ? ? ? dev_err(dev, "no dma clock.\n");
>>> + ? ? ? ? ? ? ret = PTR_ERR(clk);
>>> + ? ? ? ? ? ? goto release_sata_ref_clk;
>>> + ? ? }
>>> + ? ? tmpdata = clk_get_rate(clk) / 1000;
>>> + ? ? clk_put(clk);
>>> +
>>> + ? ? writel(tmpdata, addr + HOST_TIMER1MS);
>>> +
>>> + ? ? tmpdata = readl(addr + HOST_CAP);
>>> + ? ? if (!(tmpdata & HOST_CAP_SSS)) {
>>> + ? ? ? ? ? ? tmpdata |= HOST_CAP_SSS;
>>> + ? ? ? ? ? ? writel(tmpdata, addr + HOST_CAP);
>>> + ? ? }
>>> +
>>> + ? ? if (!(readl(addr + HOST_PORTS_IMPL) & 0x1))
>>> + ? ? ? ? ? ? writel((readl(addr + HOST_PORTS_IMPL) | 0x1),
>>> + ? ? ? ? ? ? ? ? ? ? addr + HOST_PORTS_IMPL);
>>> +
>>> + ? ? return 0;
>>> +
>>> +release_sata_ref_clk:
>>> + ? ? clk_disable(sata_ref_clk);
>>> +put_sata_ref_clk:
>>> + ? ? clk_put(sata_ref_clk);
>>> +release_sata_clk:
>>> + ? ? clk_disable(sata_clk);
>>> +put_sata_clk:
>>> + ? ? clk_put(sata_clk);
>>> +
>>> + ? ? return ret;
>>> +}
>>> +
>>> +void sata_exit(struct device *dev)
>>> +{
>>> + ? ? clk_disable(sata_ref_clk);
>>> + ? ? clk_put(sata_ref_clk);
>>> +
>>> + ? ? clk_disable(sata_clk);
>>> + ? ? clk_put(sata_clk);
>>> +
>>> +}
>>> diff --git a/arch/arm/plat-mxc/devices/Kconfig b/arch/arm/plat-mxc/devices/Kconfig
>>> index bd294ad..f63887b 100644
>>> --- a/arch/arm/plat-mxc/devices/Kconfig
>>> +++ b/arch/arm/plat-mxc/devices/Kconfig
>>> @@ -76,3 +76,7 @@ config IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
>>>
>>> ?config IMX_HAVE_PLATFORM_SPI_IMX
>>> ? ? ? bool
>>> +
>>> +config IMX_HAVE_PLATFORM_AHCI
>>> + ? ? bool
>>> + ? ? default y if ARCH_MX53
>>> diff --git a/arch/arm/plat-mxc/devices/Makefile b/arch/arm/plat-mxc/devices/Makefile
>>> index b41bf97..e858ad9 100644
>>> --- a/arch/arm/plat-mxc/devices/Makefile
>>> +++ b/arch/arm/plat-mxc/devices/Makefile
>>> @@ -25,3 +25,4 @@ obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_RTC) += platform-mxc_rtc.o
>>> ?obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_W1) += platform-mxc_w1.o
>>> ?obj-$(CONFIG_IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX) += platform-sdhci-esdhc-imx.o
>>> ?obj-$(CONFIG_IMX_HAVE_PLATFORM_SPI_IMX) += ?platform-spi_imx.o
>>> +obj-$(CONFIG_IMX_HAVE_PLATFORM_AHCI) += ?platform-ahci-imx.o
>>> diff --git a/arch/arm/plat-mxc/devices/platform-ahci-imx.c b/arch/arm/plat-mxc/devices/platform-ahci-imx.c
>>> new file mode 100644
>>> index 0000000..9e1b460
>>> --- /dev/null
>>> +++ b/arch/arm/plat-mxc/devices/platform-ahci-imx.c
>>> @@ -0,0 +1,66 @@
>>> +/*
>>> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
>>> + */
>>> +
>>> +/*
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> +
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
>>> + * GNU General Public License for more details.
>>> +
>>> + * You should have received a copy of the GNU General Public License along
>>> + * with this program; if not, write to the Free Software Foundation, Inc.,
>>> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>>> + */
>>> +
>>> +#include <linux/dma-mapping.h>
>>> +#include <asm/sizes.h>
>>> +#include <mach/hardware.h>
>>> +#include <mach/devices-common.h>
>>> +#include <mach/ahci_sata.h>
>>> +
>>> +#define imx_ahci_imx_data_entry_single(soc, _devid) ? ? ? ? ?\
>>> + ? ? { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
>>> + ? ? ? ? ? ? .devid = _devid, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>>> + ? ? ? ? ? ? .iobase = soc ## _SATA_BASE_ADDR, ? ? ? ? ? ? ? ? ? ? ? \
>>> + ? ? ? ? ? ? .irq = soc ## _INT_SATA, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>>> + ? ? }
>>> +
>>> +#ifdef CONFIG_SOC_IMX53
>>> +const struct imx_ahci_imx_data imx53_ahci_imx_data __initconst =
>>> + ? ? imx_ahci_imx_data_entry_single(MX53, "imx53-ahci");
>>> +#endif
>>> +
>>> +static struct ahci_platform_data default_sata_pdata = {
>>> + ? ? .init = sata_init,
>>> + ? ? .exit = sata_exit,
>>> +};
>>> +
>>> +struct platform_device *__init imx_add_ahci_imx(
>>> + ? ? ? ? ? ? const struct imx_ahci_imx_data *data,
>>> + ? ? ? ? ? ? const struct ahci_platform_data *pdata)
>>> +{
>>> + ? ? struct resource res[] = {
>>> + ? ? ? ? ? ? {
>>> + ? ? ? ? ? ? ? ? ? ? .start = data->iobase,
>>> + ? ? ? ? ? ? ? ? ? ? .end = data->iobase + SZ_4K - 1,
>>> + ? ? ? ? ? ? ? ? ? ? .flags = IORESOURCE_MEM,
>>> + ? ? ? ? ? ? }, {
>>> + ? ? ? ? ? ? ? ? ? ? .start = data->irq,
>>> + ? ? ? ? ? ? ? ? ? ? .end = data->irq,
>>> + ? ? ? ? ? ? ? ? ? ? .flags = IORESOURCE_IRQ,
>>> + ? ? ? ? ? ? },
>>> + ? ? };
>>> +
>>> + ? ? if (pdata == NULL)
>>> + ? ? ? ? ? ? pdata = &default_sata_pdata;
>>> +
>>> + ? ? return imx_add_platform_device_dmamask(data->devid, 0,
>>> + ? ? ? ? ? ? ? ? ? ? res, ARRAY_SIZE(res),
>>> + ? ? ? ? ? ? ? ? ? ? pdata, sizeof(*pdata), ?DMA_BIT_MASK(32));
>>> +}
>>> diff --git a/arch/arm/plat-mxc/include/mach/ahci_sata.h b/arch/arm/plat-mxc/include/mach/ahci_sata.h
>>> new file mode 100644
>>> index 0000000..ba297e1
>>> --- /dev/null
>>> +++ b/arch/arm/plat-mxc/include/mach/ahci_sata.h
>>> @@ -0,0 +1,33 @@
>>> +/*
>>> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
>>> + */
>>> +
>>> +/*
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> +
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
>>> + * GNU General Public License for more details.
>>> +
>>> + * You should have received a copy of the GNU General Public License along
>>> + * with this program; if not, write to the Free Software Foundation, Inc.,
>>> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>>> + */
>>> +
>>> +#ifndef __PLAT_MXC_AHCI_SATA_H__
>>> +#define __PLAT_MXC_AHCI_SATA_H__
>>> +
>>> +enum {
>>> + ? ? HOST_CAP = 0x00,
>>> + ? ? HOST_CAP_SSS = (1 << 27), /* Staggered Spin-up */
>>> + ? ? HOST_PORTS_IMPL = 0x0c,
>>> + ? ? HOST_TIMER1MS = 0xe0, /* Timer 1-ms */
>>> +};
>>> +
>>> +extern int sata_init(struct device *dev, void __iomem *addr);
>>> +extern void sata_exit(struct device *dev);
>>> +#endif /* __PLAT_MXC_AHCI_SATA_H__ */
>>> diff --git a/arch/arm/plat-mxc/include/mach/devices-common.h b/arch/arm/plat-mxc/include/mach/devices-common.h
>>> index 524538a..f04e063 100644
>>> --- a/arch/arm/plat-mxc/include/mach/devices-common.h
>>> +++ b/arch/arm/plat-mxc/include/mach/devices-common.h
>>> @@ -301,3 +301,13 @@ struct platform_device *__init imx_add_spi_imx(
>>> ?struct platform_device *imx_add_imx_dma(void);
>>> ?struct platform_device *imx_add_imx_sdma(char *name,
>>> ? ? ? resource_size_t iobase, int irq, struct sdma_platform_data *pdata);
>>> +
>>> +#include <linux/ahci_platform.h>
>>> +struct imx_ahci_imx_data {
>>> + ? ? const char *devid;
>>> + ? ? resource_size_t iobase;
>>> + ? ? resource_size_t irq;
>>> +};
>>> +struct platform_device *__init imx_add_ahci_imx(
>>> + ? ? ? ? ? ? const struct imx_ahci_imx_data *data,
>>> + ? ? ? ? ? ? const struct ahci_platform_data *pdata);
>>> --
>>> 1.7.1
>>>
>>>
>>>
>>
>> --
>> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
>> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
>> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 ? ?|
>> Amtsgericht Hildesheim, HRA 2686 ? ? ? ? ? | Fax: ? +49-5121-206917-5555 |
>>
>
^ permalink raw reply
* [PATCH V7 1/5] AHCI Add the AHCI SATA feature on the MX53 platforms
From: Sascha Hauer @ 2011-09-21 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJNCFVJ4EGQQ2CcRsPK6OidbU2uBEDertn8R9BuqxYGSBmxbPg@mail.gmail.com>
On Wed, Sep 21, 2011 at 01:04:09PM +0800, Richard Zhu wrote:
> Hi Sascha:
> Thanks for your comments.
>
> Best Regard
> Richard Zhu
>
> On 21 September 2011 04:30, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Wed, Aug 31, 2011 at 11:50:31AM +0800, Richard Zhu wrote:
> >> Signed-off-by: Richard Zhu <richard.zhu@linaro.org>
> >> Tested-By: Hector Oron Martinez <hector.oron@gmail.com>
> >> ---
> >> ?arch/arm/mach-mx5/clock-mx51-mx53.c ? ? ? ? ? ? | ? 19 ++++
> >> ?arch/arm/mach-mx5/devices-imx53.h ? ? ? ? ? ? ? | ? ?4 +
> >> ?arch/arm/plat-mxc/Makefile ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> >> ?arch/arm/plat-mxc/ahci_sata.c ? ? ? ? ? ? ? ? ? | ?104 +++++++++++++++++++++++
> >> ?arch/arm/plat-mxc/devices/Kconfig ? ? ? ? ? ? ? | ? ?4 +
> >> ?arch/arm/plat-mxc/devices/Makefile ? ? ? ? ? ? ?| ? ?1 +
> >> ?arch/arm/plat-mxc/devices/platform-ahci-imx.c ? | ? 66 ++++++++++++++
> >> ?arch/arm/plat-mxc/include/mach/ahci_sata.h ? ? ?| ? 33 +++++++
> >> ?arch/arm/plat-mxc/include/mach/devices-common.h | ? 10 ++
> >> ?9 files changed, 242 insertions(+), 0 deletions(-)
> >> ?create mode 100644 arch/arm/plat-mxc/ahci_sata.c
> >> ?create mode 100644 arch/arm/plat-mxc/devices/platform-ahci-imx.c
> >> ?create mode 100644 arch/arm/plat-mxc/include/mach/ahci_sata.h
> >>
> >> diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
> >> index 7f20308..e1fadaf 100644
> >> --- a/arch/arm/mach-mx5/clock-mx51-mx53.c
> >> +++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
> >> @@ -1397,6 +1397,22 @@ static struct clk esdhc4_mx53_clk = {
> >> ? ? ? .secondary = &esdhc4_ipg_clk,
> >> ?};
> >>
> >> diff --git a/arch/arm/plat-mxc/ahci_sata.c b/arch/arm/plat-mxc/ahci_sata.c
> >> new file mode 100644
> >> index 0000000..4f54816
> >> --- /dev/null
> >> +++ b/arch/arm/plat-mxc/ahci_sata.c
> >> @@ -0,0 +1,104 @@
> >> +/*
> >> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> >> + */
> >> +
> >> +/*
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> +
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
> >> + * GNU General Public License for more details.
> >> +
> >> + * You should have received a copy of the GNU General Public License along
> >> + * with this program; if not, write to the Free Software Foundation, Inc.,
> >> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> >> + */
> >> +
> >> +#include <linux/io.h>
> >> +#include <linux/clk.h>
> >> +#include <linux/err.h>
> >> +#include <linux/device.h>
> >> +#include <mach/ahci_sata.h>
> >> +
> >> +static struct clk *sata_clk, *sata_ref_clk;
> >
> > These variables make the driver single instance only.
> [Richard Zhu] In order to handle the clock enable/disable stuff, these
> two variables are mandatory required.
> Otherwise, new two struct clk members had to be added into
> ahci_platform_data struct. Then the clks can
> be transferred by the platform data.
> The current is preferred, refer to the second choice.
> >
> >> +
> >> +/* AHCI module Initialization, if return 0, initialization is successful. */
> >> +int sata_init(struct device *dev, void __iomem *addr)
> >
> > A global function with such a generic name is not a good idea.
> > Also I wonder how we want to convert this to devicetree when we
> > implement this as a platform specific hook. It should be done in the
> > driver.
> >
> [Richard Zhu] The name of these two func can be changed.
> But I don't have a good idea to move out these two platform specific
> hooks (->init, ->exit).
>
> Refer to you comments, do you means that the ->init and ->exit should
> be done in ahci_platform.c driver?
> Different platform may have the different ->init and ->exit funcs to
> handle it's own initialization and exit.
> It would be a problem that handle all kinds of init in one driver
> without the hooks.
Maybe Shawn can comment on the device tree topic. I just think that if
we merge this without devicetree support it should at least be
devicetree friendly. For example each platform could provide it's own
platform driver glue code like it's done for the sdhci driver.
> >> diff --git a/arch/arm/plat-mxc/devices/platform-ahci-imx.c b/arch/arm/plat-mxc/devices/platform-ahci-imx.c
> >> new file mode 100644
> >> index 0000000..9e1b460
> >> --- /dev/null
> >> +++ b/arch/arm/plat-mxc/devices/platform-ahci-imx.c
> >> @@ -0,0 +1,66 @@
> >> +/*
> >> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> >> + */
> >> +
> >> +/*
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> +
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
> >> + * GNU General Public License for more details.
> >> +
> >> + * You should have received a copy of the GNU General Public License along
> >> + * with this program; if not, write to the Free Software Foundation, Inc.,
> >> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> >> + */
> >> +
> >> +#include <linux/dma-mapping.h>
> >> +#include <asm/sizes.h>
> >> +#include <mach/hardware.h>
> >> +#include <mach/devices-common.h>
> >> +#include <mach/ahci_sata.h>
> >> +
> >> +#define imx_ahci_imx_data_entry_single(soc, _devid) ? ? ? ? ?\
> >> + ? ? { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> >> + ? ? ? ? ? ? .devid = _devid, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> >> + ? ? ? ? ? ? .iobase = soc ## _SATA_BASE_ADDR, ? ? ? ? ? ? ? ? ? ? ? \
> >> + ? ? ? ? ? ? .irq = soc ## _INT_SATA, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> >> + ? ? }
> >> +
> >> +#ifdef CONFIG_SOC_IMX53
> >> +const struct imx_ahci_imx_data imx53_ahci_imx_data __initconst =
> >> + ? ? imx_ahci_imx_data_entry_single(MX53, "imx53-ahci");
> >> +#endif
> >> +
> >> +static struct ahci_platform_data default_sata_pdata = {
> >> + ? ? .init = sata_init,
> >> + ? ? .exit = sata_exit,
> >> +};
If we continue going the way you started, please add the
sata_init/sata_exit functions as static functions to this file, ...
> >> +
> >> +struct platform_device *__init imx_add_ahci_imx(
> >> + ? ? ? ? ? ? const struct imx_ahci_imx_data *data,
> >> + ? ? ? ? ? ? const struct ahci_platform_data *pdata)
> >> +{
> >> + ? ? struct resource res[] = {
> >> + ? ? ? ? ? ? {
> >> + ? ? ? ? ? ? ? ? ? ? .start = data->iobase,
> >> + ? ? ? ? ? ? ? ? ? ? .end = data->iobase + SZ_4K - 1,
> >> + ? ? ? ? ? ? ? ? ? ? .flags = IORESOURCE_MEM,
> >> + ? ? ? ? ? ? }, {
> >> + ? ? ? ? ? ? ? ? ? ? .start = data->irq,
> >> + ? ? ? ? ? ? ? ? ? ? .end = data->irq,
> >> + ? ? ? ? ? ? ? ? ? ? .flags = IORESOURCE_IRQ,
> >> + ? ? ? ? ? ? },
> >> + ? ? };
> >> +
> >> + ? ? if (pdata == NULL)
> >> + ? ? ? ? ? ? pdata = &default_sata_pdata;
...remove these two lines, and instead introduce a function like this:
struct platform_device *__init imx53_add_ahci_imx(void)
{
struct ahci_platform_data pdata = {
.init = imx53_sata_init,
.exit = imx53_sata_exit,
};
return imx_add_ahci_imx(&imx53_ahci_imx_data, &pdata);
}
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Shawn Guo @ 2011-09-21 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4z4WJkDPhD1WYan3GecnAb0VfPx3_dgFHCmTWs7gVyFdA@mail.gmail.com>
On Wed, Sep 21, 2011 at 01:53:37PM +0800, Barry Song wrote:
> 2011/9/21 Shawn Guo <shawn.guo@freescale.com>:
> > Hi Barry,
> >
> > On Tue, Sep 20, 2011 at 06:57:45PM -0700, Barry Song wrote:
> >> we save the l2x0 registers at the first initialization, and restore
> >> them after resuming every time.
> >>
> > I'm unsure that it will work for cases like imx6q, where L2 cache is
> > retained and the controller needs to be restored at the very beginning
> > of the resume entry (running on physical space).
>
> yes. imx6q actually needs to enable l2 earlier than cpu_resume(and mmu
> resume). so how about letting outer_resume support both phy and virt
> address restore?
> for example, add early resume: outer_early_resume()
>
> Then for your case, you use asm to "bl out_resume", then "b cpu_resume".
> For those chips which lose l2 in suspend cycle, people can call it in
> C function after cpu_resume.
>
It's worth a try. Except that, I have another two comments on the
patch.
* To be safe, all the variables used to save L2 registers need to
be ensured being written external memory.
* What registers to save seems to be a platform decision. For example,
you patch save 5 registers for pl310 while I only need one aux_ctrl
on imx6q.
It seems that Lorenzo also has a plan working on this, so I Cc-ed him
for comments.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH 1/3] include: fb: Add definiton for window positioning structure
From: Tomi Valkeinen @ 2011-09-21 6:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920170858.GA3827@tarshish>
On Tue, 2011-09-20 at 20:08 +0300, Baruch Siach wrote:
> Hi Ajay,
>
> On Tue, Sep 20, 2011 at 08:56:57PM +0530, Ajay kumar wrote:
> > Hi Baruch,
> > On Tue, Sep 20, 2011 at 4:54 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> > > Hi Ajay,
> > >
> > > On Tue, Sep 20, 2011 at 11:30:39AM -0400, Ajay Kumar wrote:
> > >> This patch adds a data structure definiton to hold framebuffer windows/planes.
> > >> An ioctl number is also added to provide user access
> > >> to change window position dynamically.
> > >
> > > [snip]
> > >
> > >> +/* Window overlaying */
> > >> +struct fb_overlay_win_pos {
> > >> + __u32 win_pos_x; /* x-offset from LCD(0,0) where window starts */
> > >> + __u32 win_pos_y; /* y-offset from LCD(0,0) where window starts */
> > >> +};
> > >
> > > Why not allow negative offsets where the left or upper part of the framebuffer
> > > is hidden?
> >
> > Thanks for pointing it out. Are there drivers which place the overlay
> > windows such that some part of the window is hidden from being
> > displayed on the screen?
>
> I don't know. However, since this is new userspace ABI which should stay
> compatible forever, we should make sure to do it right. Using __s32 instead of
> __u32 won't limit us in the future.
OMAP HW doesn't allow "funny" things like overlay being outside the
visible area, i.e. negative position or size larger than the display.
And my guess is that hardware rarely allow things like that, as it would
just complicate the hardware without any gain.
Out-of-display-overlays can of course be emulated by the software. But
I'm not sure if it's good to add the complexity in the driver layer, as
it could as well be handled in the userspace.
Then again, a signed value would be future safer ("just in case"), and
if the driver can just reject values it doesn't want to support, there's
no real harm there either.
Tomi
^ permalink raw reply
* [RESEND PATCH 2/3] ARM: EXYNOS4: Update consistent DMA size to 8MB
From: Kyungmin Park @ 2011-09-21 6:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316583860-32510-3-git-send-email-hatim.rv@samsung.com>
Hi,
As I know, CONSISTENT_DMA_SIZE is removed, please use the updated APIs.
Thank you,
Kyungmin Park
On Wed, Sep 21, 2011 at 2:44 PM, Hatim Ali <hatim.rv@samsung.com> wrote:
> Change the consistent DMA allocation to 8MB to support the
> TVOUT driver.
>
> NOTE: Once CMA support is merged into mainline, we will use it for memory
> allocation.
>
> Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
> ---
> ?arch/arm/mach-exynos4/include/mach/memory.h | ? ?2 ++
> ?1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/include/mach/memory.h b/arch/arm/mach-exynos4/include/mach/memory.h
> index 374ef2c..7549742 100644
> --- a/arch/arm/mach-exynos4/include/mach/memory.h
> +++ b/arch/arm/mach-exynos4/include/mach/memory.h
> @@ -15,6 +15,8 @@
>
> ?#define PLAT_PHYS_OFFSET ? ? ? ? ? ? ? UL(0x40000000)
>
> +#define CONSISTENT_DMA_SIZE ? ? ? ? ? ?SZ_8M
> +
> ?/* Maximum of 256MiB in one bank */
> ?#define MAX_PHYSMEM_BITS ? ? ? 32
> ?#define SECTION_SIZE_BITS ? ? ?28
> --
> 1.7.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v8 00/16] To use DMA generic APIs for Samsung DMA
From: Vinod Koul @ 2011-09-21 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001601cc76b6$2627cdd0$72776970$%kim@samsung.com>
On Mon, 2011-09-19 at 19:23 +0900, Kukjin Kim wrote:
> Vinod Koul wrote:
> >
> > On Wed, 2011-09-14 at 17:03 +0530, Jassi Brar wrote:
> > > On 14 September 2011 16:47, Vinod Koul <vinod.koul@intel.com> wrote:
> > >
> > > >> The changelog for [PATCH v8 04/16] is misleading - we don't need any
> > > >> modification for the reason mentioned in changelog. But the modification
> > > >> has positive side-effect of preventing callbacks during terminate_all which
> > > >> is no way understood from the changelog. So I would like to changelog
> > > >> corrected.
> > > > I thought change log was correct in depicting what patch does and Boojin
> > > > had replied.... I will check again...
> > >
> > > I didn't reply because I ran out of ways to explain the same thing in
> > > different words.
> > I checked again the patch, change log and your comments.
> > I agree with current change log, and also your observation is right but
> > that is just a side effect, which IMO should be best left to developer
> > to choose or not, in this case she ignored it
> >
> > So no changes to this and I a ready to merge it to my next in a day or
> > two...
> >
> So as a note, pulled git://git.infradead.org/users/vkoul/slave-dma.git samsung_dma for other regarding dma patches in arch/arm/ samsung stuff.
>
> If any problems, please let me know.
>
I am pushing them to next now..
--
~Vinod
^ permalink raw reply
* [PATCH] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Barry Song @ 2011-09-21 5:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110921055223.GA28907@S2100-06.ap.freescale.net>
2011/9/21 Shawn Guo <shawn.guo@freescale.com>:
> Hi Barry,
>
> On Tue, Sep 20, 2011 at 06:57:45PM -0700, Barry Song wrote:
>> we save the l2x0 registers at the first initialization, and restore
>> them after resuming every time.
>>
> I'm unsure that it will work for cases like imx6q, where L2 cache is
> retained and the controller needs to be restored at the very beginning
> of the resume entry (running on physical space).
yes. imx6q actually needs to enable l2 earlier than cpu_resume(and mmu
resume). so how about letting outer_resume support both phy and virt
address restore?
for example, add early resume: outer_early_resume()
Then for your case, you use asm to "bl out_resume", then "b cpu_resume".
For those chips which lose l2 in suspend cycle, people can call it in
C function after cpu_resume.
>
> Regards,
> Shawn
-barry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox