* [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory initialize for
@ 2011-02-15 5:03 Kuninori Morimoto
2011-02-17 0:41 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory Simon Horman
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: Kuninori Morimoto @ 2011-02-15 5:03 UTC (permalink / raw)
To: linux-sh
Current makerel had issue which couldn't boot sometimes.
This patch fixup it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
.../mach-shmobile/include/mach/head-mackerel.txt | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-shmobile/include/mach/head-mackerel.txt b/arch/arm/mach-shmobile/include/mach/head-mackerel.txt
index efd3687..3029aba 100644
--- a/arch/arm/mach-shmobile/include/mach/head-mackerel.txt
+++ b/arch/arm/mach-shmobile/include/mach/head-mackerel.txt
@@ -6,13 +6,10 @@ LIST "RWT Setting"
EW 0xE6020004, 0xA500
EW 0xE6030004, 0xA500
-DD 0x01001000, 0x01001000
-
LIST "GPIO Setting"
EB 0xE6051013, 0xA2
LIST "CPG"
-ED 0xE6150080, 0x00000180
ED 0xE61500C0, 0x00000002
WAIT 1, 0xFE40009C
@@ -37,6 +34,9 @@ ED 0xE615002C, 0x93000040
WAIT 1, 0xFE40009C
+LIST "SUB/USBClk"
+ED 0xE6150080, 0x00000180
+
LIST "BSC"
ED 0xFEC10000, 0x00E0001B
@@ -53,7 +53,7 @@ ED 0xFE400048, 0x20C18505
ED 0xFE40004C, 0x00110209
ED 0xFE400010, 0x00000087
-WAIT 10, 0xFE40009C
+WAIT 30, 0xFE40009C
ED 0xFE400084, 0x0000003F
EB 0xFE500000, 0x00
@@ -84,7 +84,7 @@ ED 0xE6150004, 0x80331050
WAIT 1, 0xFE40009C
-ED 0xE6150354, 0x00000002
+ED 0xFE400354, 0x01AD8002
LIST "SCIF0 - Serial port for earlyprintk"
EB 0xE6053098, 0x11
--
1.7.1
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory 2011-02-15 5:03 [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory initialize for Kuninori Morimoto @ 2011-02-17 0:41 ` Simon Horman 2011-02-17 1:11 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory initialize Kuninori Morimoto ` (5 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: Simon Horman @ 2011-02-17 0:41 UTC (permalink / raw) To: linux-sh On Tue, Feb 15, 2011 at 02:03:53PM +0900, Kuninori Morimoto wrote: > Current makerel had issue which couldn't boot sometimes. > This patch fixup it. > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Hi Morimoto-san, I have verified that this boots on my Mackerel. I have also looked over the register changes and they seem reasonable to me. Reviewed-by: Simon Horman <horms@verge.net.au> > --- > .../mach-shmobile/include/mach/head-mackerel.txt | 10 +++++----- > 1 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/mach-shmobile/include/mach/head-mackerel.txt b/arch/arm/mach-shmobile/include/mach/head-mackerel.txt > index efd3687..3029aba 100644 > --- a/arch/arm/mach-shmobile/include/mach/head-mackerel.txt > +++ b/arch/arm/mach-shmobile/include/mach/head-mackerel.txt > @@ -6,13 +6,10 @@ LIST "RWT Setting" > EW 0xE6020004, 0xA500 > EW 0xE6030004, 0xA500 > > -DD 0x01001000, 0x01001000 > - > LIST "GPIO Setting" > EB 0xE6051013, 0xA2 > > LIST "CPG" > -ED 0xE6150080, 0x00000180 > ED 0xE61500C0, 0x00000002 > > WAIT 1, 0xFE40009C > @@ -37,6 +34,9 @@ ED 0xE615002C, 0x93000040 > > WAIT 1, 0xFE40009C > > +LIST "SUB/USBClk" > +ED 0xE6150080, 0x00000180 > + > LIST "BSC" > ED 0xFEC10000, 0x00E0001B > > @@ -53,7 +53,7 @@ ED 0xFE400048, 0x20C18505 > ED 0xFE40004C, 0x00110209 > ED 0xFE400010, 0x00000087 > > -WAIT 10, 0xFE40009C > +WAIT 30, 0xFE40009C > > ED 0xFE400084, 0x0000003F > EB 0xFE500000, 0x00 > @@ -84,7 +84,7 @@ ED 0xE6150004, 0x80331050 > > WAIT 1, 0xFE40009C > > -ED 0xE6150354, 0x00000002 > +ED 0xFE400354, 0x01AD8002 I don't see 0xE6150354 in the processor manual. Was it a typo? > LIST "SCIF0 - Serial port for earlyprintk" > EB 0xE6053098, 0x11 > -- > 1.7.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory initialize 2011-02-15 5:03 [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory initialize for Kuninori Morimoto 2011-02-17 0:41 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory Simon Horman @ 2011-02-17 1:11 ` Kuninori Morimoto 2011-05-25 2:49 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs support Kuninori Morimoto ` (4 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: Kuninori Morimoto @ 2011-02-17 1:11 UTC (permalink / raw) To: linux-sh Dear Simon > I have verified that this boots on my Mackerel. > I have also looked over the register changes > and they seem reasonable to me. > > Reviewed-by: Simon Horman <horms@verge.net.au> Thanks > > -ED 0xE6150354, 0x00000002 > > +ED 0xFE400354, 0x01AD8002 > > I don't see 0xE6150354 in the processor manual. Was it a typo? Yes. the original code that I got had typo. Best regards -- Kuninori Morimoto ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs support 2011-02-15 5:03 [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory initialize for Kuninori Morimoto 2011-02-17 0:41 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory Simon Horman 2011-02-17 1:11 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory initialize Kuninori Morimoto @ 2011-05-25 2:49 ` Kuninori Morimoto 2011-05-25 2:57 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs support for USB1 Paul Mundt ` (3 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: Kuninori Morimoto @ 2011-05-25 2:49 UTC (permalink / raw) To: linux-sh CN31 USB1 can be Host/Function, and it can use IRQ8 as USB-phy. This mean we can power off it if... - while USB1 is disconnected. - USB-Function is selected. - driver is supporting it. OTOH, CN22 USB0 which is only USB Function can not use USB-phy interrupt (IRQ7) on mackerel board. Because IRQ7 is already used by Touchscreen, and it is impossible to use cascaded IRQ7. renesas_usbhs driver which is supporting USB-Function is supporting USB power off when disconnect. mackerel board will use renesas_usbhs driver as USB-Function on CN31 if it have CONFIG_USB_RENESAS_USBHS. And r8a66597_hcd will be used as USB Host if it have CONFIG_USB_R8A66597_HCD. But you can not select both CONFIG_USB_R8A66597_HCD and CONFIG_USB_RENESAS_USBHS in same time for now. Because IRQ8 will be requested in different driver. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> --- arch/arm/mach-shmobile/board-mackerel.c | 175 ++++++++++++++++++++++++++++++- 1 files changed, 174 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c index efceb1d..512dc4c 100644 --- a/arch/arm/mach-shmobile/board-mackerel.c +++ b/arch/arm/mach-shmobile/board-mackerel.c @@ -43,6 +43,7 @@ #include <linux/sh_intc.h> #include <linux/tca6416_keypad.h> #include <linux/usb/r8a66597.h> +#include <linux/usb/renesas_usbhs.h> #include <video/sh_mobile_hdmi.h> #include <video/sh_mobile_lcdc.h> @@ -143,7 +144,9 @@ * open | external VBUS | Function * * *1 - * CN31 is used as Host in Linux. + * CN31 is used as + * CONFIG_USB_R8A66597_HCD Host + * CONFIG_USB_RENESAS_USBHS Function */ /* @@ -185,6 +188,7 @@ * FIXME !! * * gpio_no_direction + * gpio_pull_down * are quick_hack. * * current gpio frame work doesn't have @@ -196,6 +200,16 @@ static void __init gpio_no_direction(u32 addr) __raw_writeb(0x00, addr); } +static void __init gpio_pull_down(u32 addr) +{ + u8 data = __raw_readb(addr); + + data &= 0x0F; + data |= 0xA0; + + __raw_writeb(data, addr); +} + /* MTD */ static struct mtd_partition nor_flash_partitions[] = { { @@ -509,6 +523,162 @@ static struct platform_device usb1_host_device = { .resource = usb1_host_resources, }; +#if defined(CONFIG_USB_RENESAS_USBHS) && defined(CONFIG_USB_R8A66597_HCD) +/* same IRQ8 will be requested in different driver */ +#error dont't select R8A66597_HCD and RENESAS_USBHS in same time +#endif + +/* USB1 (Function) */ +#define USB_PHY_MODE (1 << 4) +#define USB_PHY_INT_EN ((1 << 3) | (1 << 2)) +#define USB_PHY_ON (1 << 1) +#define USB_PHY_OFF (1 << 0) +#define USB_PHY_INT_CLR (USB_PHY_ON | USB_PHY_OFF) + +struct usbhs_private { + unsigned int irq; + unsigned int usbphyaddr; + unsigned int usbcrcaddr; + struct renesas_usbhs_platform_info info; +}; + +#define usbhs_get_priv(pdev) \ + container_of(renesas_usbhs_get_info(pdev), \ + struct usbhs_private, info) + +#define usbhs_is_connected(priv) \ + (!((1 << 7) & __raw_readw(priv->usbcrcaddr))) + +static int usbhs1_get_id(struct platform_device *pdev) +{ + return USBHS_GADGET; +} + +static int usbhs1_get_vbus(struct platform_device *pdev) +{ + return usbhs_is_connected(usbhs_get_priv(pdev)); +} + +static irqreturn_t usbhs1_interrupt(int irq, void *data) +{ + struct platform_device *pdev = data; + struct usbhs_private *priv = usbhs_get_priv(pdev); + + dev_dbg(&pdev->dev, "%s\n", __func__); + + renesas_usbhs_call_notify_hotplug(pdev); + + /* clear status */ + __raw_writew(__raw_readw(priv->usbphyaddr) | USB_PHY_INT_CLR, + priv->usbphyaddr); + + return IRQ_HANDLED; +} + +static int usbhs1_hardware_init(struct platform_device *pdev) +{ + struct usbhs_private *priv = usbhs_get_priv(pdev); + int ret; + + irq_set_irq_type(priv->irq, IRQ_TYPE_LEVEL_HIGH); + + /* clear interrupt status */ + __raw_writew(USB_PHY_MODE | USB_PHY_INT_CLR, priv->usbphyaddr); + + ret = request_irq(priv->irq, usbhs1_interrupt, 0, + dev_name(&pdev->dev), pdev); + if (ret) { + dev_err(&pdev->dev, "request_irq err\n"); + return ret; + } + + /* enable USB phy interrupt */ + __raw_writew(USB_PHY_MODE | USB_PHY_INT_EN, priv->usbphyaddr); + + return 0; +} + +static void usbhs1_hardware_exit(struct platform_device *pdev) +{ + struct usbhs_private *priv = usbhs_get_priv(pdev); + + /* clear interrupt status */ + __raw_writew(USB_PHY_MODE | USB_PHY_INT_CLR, priv->usbphyaddr); + + free_irq(priv->irq, pdev); +} + +static void usbhs1_phy_reset(struct platform_device *pdev) +{ + struct usbhs_private *priv = usbhs_get_priv(pdev); + + /* init phy */ + __raw_writew(0x8a0a, priv->usbcrcaddr); +} + +static u32 usbhs1_pipe_cfg[] = { + USB_ENDPOINT_XFER_CONTROL, + USB_ENDPOINT_XFER_ISOC, + USB_ENDPOINT_XFER_ISOC, + USB_ENDPOINT_XFER_BULK, + USB_ENDPOINT_XFER_BULK, + USB_ENDPOINT_XFER_BULK, + USB_ENDPOINT_XFER_INT, + USB_ENDPOINT_XFER_INT, + USB_ENDPOINT_XFER_INT, + USB_ENDPOINT_XFER_BULK, + USB_ENDPOINT_XFER_BULK, + USB_ENDPOINT_XFER_BULK, + USB_ENDPOINT_XFER_BULK, + USB_ENDPOINT_XFER_BULK, + USB_ENDPOINT_XFER_BULK, + USB_ENDPOINT_XFER_BULK, +}; + +static struct usbhs_private usbhs1_private = { + .irq = evt2irq(0x0300), /* IRQ8 */ + .usbphyaddr = 0xE60581E2, /* USBPHY1INTAP */ + .usbcrcaddr = 0xE6058130, /* USBCR4 */ + .info = { + .platform_callback = { + .hardware_init = usbhs1_hardware_init, + .hardware_exit = usbhs1_hardware_exit, + .phy_reset = usbhs1_phy_reset, + .get_id = usbhs1_get_id, + .get_vbus = usbhs1_get_vbus, + }, + .driver_param = { + .buswait_bwait = 4, + .pipe_type = usbhs1_pipe_cfg, + .pipe_size = ARRAY_SIZE(usbhs1_pipe_cfg), + }, + }, +}; + +static struct resource usbhs1_resources[] = { + [0] = { + .name = "USBHS", + .start = 0xE68B0000, + .end = 0xE68B00E6 - 1, + .flags = IORESOURCE_MEM, + }, + [1] = { + .start = evt2irq(0x1ce0) /* USB1_USB1I0 */, + .flags = IORESOURCE_IRQ, + }, +}; + +static struct platform_device usbhs1_device = { + .name = "renesas_usbhs", + .id = 1, + .dev = { + .platform_data = &usbhs1_private.info, + }, + .num_resources = ARRAY_SIZE(usbhs1_resources), + .resource = usbhs1_resources, +}; + + /* LED */ static struct gpio_led mackerel_leds[] = { { @@ -949,6 +1119,7 @@ static struct platform_device *mackerel_devices[] __initdata = { &smc911x_device, &lcdc_device, &usb1_host_device, + &usbhs1_device, &leds_device, &fsi_device, &fsi_ak4643_device, @@ -1044,6 +1215,7 @@ static void __init mackerel_map_io(void) #define GPIO_PORT9CR 0xE6051009 #define GPIO_PORT10CR 0xE605100A +#define GPIO_PORT168CR 0xE60520A8 #define SRCR4 0xe61580bc #define USCCR1 0xE6058144 static void __init mackerel_init(void) @@ -1102,6 +1274,7 @@ static void __init mackerel_init(void) gpio_request(GPIO_FN_OVCN_1_114, NULL); gpio_request(GPIO_FN_EXTLP_1, NULL); gpio_request(GPIO_FN_OVCN2_1, NULL); + gpio_pull_down(GPIO_PORT168CR); /* setup USB phy */ __raw_writew(0x8a0a, 0xE6058130); /* USBCR4 */ -- 1.7.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs support for USB1 2011-02-15 5:03 [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory initialize for Kuninori Morimoto ` (2 preceding siblings ...) 2011-05-25 2:49 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs support Kuninori Morimoto @ 2011-05-25 2:57 ` Paul Mundt 2011-05-25 4:24 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs Kuninori Morimoto ` (2 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: Paul Mundt @ 2011-05-25 2:57 UTC (permalink / raw) To: linux-sh On Wed, May 25, 2011 at 11:49:25AM +0900, Kuninori Morimoto wrote: > CN31 USB1 can be Host/Function, and it can use IRQ8 as USB-phy. > This mean we can power off it if... > - while USB1 is disconnected. > - USB-Function is selected. > - driver is supporting it. > > OTOH, CN22 USB0 which is only USB Function > can not use USB-phy interrupt (IRQ7) on mackerel board. > Because IRQ7 is already used by Touchscreen, > and it is impossible to use cascaded IRQ7. > Why is it impossible to have an IRQ7 demux? > renesas_usbhs driver which is supporting USB-Function > is supporting USB power off when disconnect. > mackerel board will use renesas_usbhs driver as > USB-Function on CN31 if it have CONFIG_USB_RENESAS_USBHS. > And r8a66597_hcd will be used as USB Host if it have CONFIG_USB_R8A66597_HCD. > > But you can not select both CONFIG_USB_R8A66597_HCD and > CONFIG_USB_RENESAS_USBHS in same time for now. > Because IRQ8 will be requested in different driver. > Is there some particular reason why IRQF_SHARED isn't sufficient for working around this? Since you're leveraging the IORESOURCE PnP IRQ bits anyways, you could easily just or in IORESOURCE_IRQ_SHAREABLE and translate that in to an IRQF_SHARED at request_irq() time for the cases that need it. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs 2011-02-15 5:03 [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory initialize for Kuninori Morimoto ` (3 preceding siblings ...) 2011-05-25 2:57 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs support for USB1 Paul Mundt @ 2011-05-25 4:24 ` Kuninori Morimoto 2011-05-25 5:40 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs support for USB1 Paul Mundt 2012-03-01 4:25 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: Add FSI DMAEngine support Kuninori Morimoto 6 siblings, 0 replies; 8+ messages in thread From: Kuninori Morimoto @ 2011-05-25 4:24 UTC (permalink / raw) To: linux-sh Dear Paul Thank you for checking > > OTOH, CN22 USB0 which is only USB Function > > can not use USB-phy interrupt (IRQ7) on mackerel board. > > Because IRQ7 is already used by Touchscreen, > > and it is impossible to use cascaded IRQ7. > > > Why is it impossible to have an IRQ7 demux? Sorry for insufficient explanation. USB-phy needs IRQ7-PORT167, and Touchscreen needs IRQ7-PORT40. IRQ7 PORT 167/40 are controlled by GPIO. I think it is impossible to have IRQ7 demux. > > But you can not select both CONFIG_USB_R8A66597_HCD and > > CONFIG_USB_RENESAS_USBHS in same time for now. > > Because IRQ8 will be requested in different driver. > > > Is there some particular reason why IRQF_SHARED isn't sufficient for > working around this? Since you're leveraging the IORESOURCE PnP IRQ bits > anyways, you could easily just or in IORESOURCE_IRQ_SHAREABLE and > translate that in to an IRQF_SHARED at request_irq() time for the cases > that need it. renesas_usbhs is new version of r8a66597_xxx driver. This means both will access to same register. So, we can not keep correct operation if these driver are probed in same time. Does this become reason ? If yes, shall I send v2 patch ? Best regards -- Kuninori Morimoto ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs support for USB1 2011-02-15 5:03 [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory initialize for Kuninori Morimoto ` (4 preceding siblings ...) 2011-05-25 4:24 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs Kuninori Morimoto @ 2011-05-25 5:40 ` Paul Mundt 2012-03-01 4:25 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: Add FSI DMAEngine support Kuninori Morimoto 6 siblings, 0 replies; 8+ messages in thread From: Paul Mundt @ 2011-05-25 5:40 UTC (permalink / raw) To: linux-sh On Wed, May 25, 2011 at 01:24:10PM +0900, Kuninori Morimoto wrote: > > > OTOH, CN22 USB0 which is only USB Function > > > can not use USB-phy interrupt (IRQ7) on mackerel board. > > > Because IRQ7 is already used by Touchscreen, > > > and it is impossible to use cascaded IRQ7. > > > > > Why is it impossible to have an IRQ7 demux? > > Sorry for insufficient explanation. > > USB-phy needs IRQ7-PORT167, and Touchscreen needs IRQ7-PORT40. > IRQ7 PORT 167/40 are controlled by GPIO. > I think it is impossible to have IRQ7 demux. > Ok, it would be nice to see this documented somewhere (or at least in the changelog), as it's not immediately obvious to anyone that isn't staring at the data sheet. > > > But you can not select both CONFIG_USB_R8A66597_HCD and > > > CONFIG_USB_RENESAS_USBHS in same time for now. > > > Because IRQ8 will be requested in different driver. > > > > > Is there some particular reason why IRQF_SHARED isn't sufficient for > > working around this? Since you're leveraging the IORESOURCE PnP IRQ bits > > anyways, you could easily just or in IORESOURCE_IRQ_SHAREABLE and > > translate that in to an IRQF_SHARED at request_irq() time for the cases > > that need it. > > renesas_usbhs is new version of r8a66597_xxx driver. > This means both will access to same register. > So, we can not keep correct operation > if these driver are probed in same time. > > Does this become reason ? > If yes, shall I send v2 patch ? > That's ok, there are enough drivers like that in the kernel that it's quite acceptable to fall back on a runtime error (ie, request_irq() failing and the device simply never coming up). The situation we want to avoid is build-time errors for run-time behavioural problems. In this case you can simply kill off the #ifdef/#error mess and leave it to the regular error paths if the user has both configured. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] ARM: mach-shmobile: mackerel: Add FSI DMAEngine support 2011-02-15 5:03 [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory initialize for Kuninori Morimoto ` (5 preceding siblings ...) 2011-05-25 5:40 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs support for USB1 Paul Mundt @ 2012-03-01 4:25 ` Kuninori Morimoto 6 siblings, 0 replies; 8+ messages in thread From: Kuninori Morimoto @ 2012-03-01 4:25 UTC (permalink / raw) To: linux-sh We needs un-manualed address to use DMA Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> --- arch/arm/mach-shmobile/board-mackerel.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c index 6e21194..4926fdc 100644 --- a/arch/arm/mach-shmobile/board-mackerel.c +++ b/arch/arm/mach-shmobile/board-mackerel.c @@ -955,6 +955,8 @@ fsi_set_rate_end: static struct sh_fsi_platform_info fsi_info = { .port_a = { .flags = SH_FSI_BRS_INV, + .tx_id = SHDMA_SLAVE_FSIA_TX, + .rx_id = SHDMA_SLAVE_FSIA_RX, }, .port_b = { .flags = SH_FSI_BRS_INV | @@ -967,9 +969,11 @@ static struct sh_fsi_platform_info fsi_info = { static struct resource fsi_resources[] = { [0] = { + /* we need 0xFE1F0000 to access DMA + * instead of 0xFE3C0000 */ .name = "FSI", - .start = 0xFE3C0000, - .end = 0xFE3C0400 - 1, + .start = 0xFE1F0000, + .end = 0xFE1F0400 - 1, .flags = IORESOURCE_MEM, }, [1] = { -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-03-01 4:25 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-02-15 5:03 [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory initialize for Kuninori Morimoto 2011-02-17 0:41 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory Simon Horman 2011-02-17 1:11 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: fixup memory initialize Kuninori Morimoto 2011-05-25 2:49 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs support Kuninori Morimoto 2011-05-25 2:57 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs support for USB1 Paul Mundt 2011-05-25 4:24 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs Kuninori Morimoto 2011-05-25 5:40 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: add renesas_usbhs support for USB1 Paul Mundt 2012-03-01 4:25 ` [PATCH 2/2] ARM: mach-shmobile: mackerel: Add FSI DMAEngine support Kuninori Morimoto
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).