* [PATCH] dma: imx-sdma: Add ROM script addresses to driver
@ 2013-08-19 12:16 Sascha Hauer
2013-08-19 12:16 ` [PATCH 1/3] dma: imx-sdma: Use struct for driver data Sascha Hauer
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: Sascha Hauer @ 2013-08-19 12:16 UTC (permalink / raw)
To: linux-arm-kernel
The following series adds the ROM script addresses to the driver.
These have been provided by platform_data for platform based systems,
but with devicetree the driver no longer supports the ROM script
addresses. This means that the sdma driver currently needs a firmware
to work. By adding the script addresses to the driver it can work
without additional firmware.
Sascha
----------------------------------------------------------------
Sascha Hauer (3):
dma: imx-sdma: Use struct for driver data
dma: imx-sdma: Add ROM script addresses to driver
ARM: i.MX: remove sdma script address arrays from platform data
.../devicetree/bindings/dma/fsl-imx-sdma.txt | 7 +-
arch/arm/mach-imx/mm-imx25.c | 17 --
arch/arm/mach-imx/mm-imx3.c | 67 ++----
arch/arm/mach-imx/mm-imx5.c | 14 --
drivers/dma/imx-sdma.c | 241 ++++++++++++++++++---
5 files changed, 230 insertions(+), 116 deletions(-)
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH 1/3] dma: imx-sdma: Use struct for driver data 2013-08-19 12:16 [PATCH] dma: imx-sdma: Add ROM script addresses to driver Sascha Hauer @ 2013-08-19 12:16 ` Sascha Hauer 2013-08-19 12:16 ` [PATCH 2/3] dma: imx-sdma: Add ROM script addresses to driver Sascha Hauer ` (2 subsequent siblings) 3 siblings, 0 replies; 14+ messages in thread From: Sascha Hauer @ 2013-08-19 12:16 UTC (permalink / raw) To: linux-arm-kernel Use a struct type instead of an enum type for distinguishing between different IP versions. This makes it simpler to handle multiple differences without cluttering the code with comparisons for certain IP versions. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- drivers/dma/imx-sdma.c | 63 ++++++++++++++++++++++++++------------------------ 1 file changed, 33 insertions(+), 30 deletions(-) diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index 1e44b8c..e3e7e3f 100644 --- a/drivers/dma/imx-sdma.c +++ b/drivers/dma/imx-sdma.c @@ -307,9 +307,9 @@ struct sdma_firmware_header { u32 ram_code_size; }; -enum sdma_devtype { - IMX31_SDMA, /* runs on i.mx31 */ - IMX35_SDMA, /* runs on i.mx35 and later */ +struct sdma_driver_data { + int chnenbl0; + int num_events; }; struct sdma_engine { @@ -318,8 +318,6 @@ struct sdma_engine { struct sdma_channel channel[MAX_DMA_CHANNELS]; struct sdma_channel_control *channel_control; void __iomem *regs; - enum sdma_devtype devtype; - unsigned int num_events; struct sdma_context_data *context; dma_addr_t context_phys; struct dma_device dma_device; @@ -327,15 +325,26 @@ struct sdma_engine { struct clk *clk_ahb; spinlock_t channel_0_lock; struct sdma_script_start_addrs *script_addrs; + const struct sdma_driver_data *drvdata; +}; + +struct sdma_driver_data sdma_imx31 = { + .chnenbl0 = SDMA_CHNENBL0_IMX31, + .num_events = 32, +}; + +struct sdma_driver_data sdma_imx35 = { + .chnenbl0 = SDMA_CHNENBL0_IMX35, + .num_events = 48, }; static struct platform_device_id sdma_devtypes[] = { { .name = "imx31-sdma", - .driver_data = IMX31_SDMA, + .driver_data = (unsigned long)&sdma_imx31, }, { .name = "imx35-sdma", - .driver_data = IMX35_SDMA, + .driver_data = (unsigned long)&sdma_imx35, }, { /* sentinel */ } @@ -343,8 +352,8 @@ static struct platform_device_id sdma_devtypes[] = { MODULE_DEVICE_TABLE(platform, sdma_devtypes); static const struct of_device_id sdma_dt_ids[] = { - { .compatible = "fsl,imx31-sdma", .data = &sdma_devtypes[IMX31_SDMA], }, - { .compatible = "fsl,imx35-sdma", .data = &sdma_devtypes[IMX35_SDMA], }, + { .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, }, + { .compatible = "fsl,imx35-sdma", .data = &sdma_imx35, }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, sdma_dt_ids); @@ -356,8 +365,7 @@ MODULE_DEVICE_TABLE(of, sdma_dt_ids); static inline u32 chnenbl_ofs(struct sdma_engine *sdma, unsigned int event) { - u32 chnenbl0 = (sdma->devtype == IMX31_SDMA ? SDMA_CHNENBL0_IMX31 : - SDMA_CHNENBL0_IMX35); + u32 chnenbl0 = sdma->drvdata->chnenbl0; return chnenbl0 + event * 4; } @@ -733,7 +741,7 @@ static int sdma_config_channel(struct sdma_channel *sdmac) sdmac->per_addr = 0; if (sdmac->event_id0) { - if (sdmac->event_id0 >= sdmac->sdma->num_events) + if (sdmac->event_id0 >= sdmac->sdma->drvdata->num_events) return -EINVAL; sdma_event_enable(sdmac, sdmac->event_id0); } @@ -1218,19 +1226,6 @@ static int __init sdma_init(struct sdma_engine *sdma) int i, ret; dma_addr_t ccb_phys; - switch (sdma->devtype) { - case IMX31_SDMA: - sdma->num_events = 32; - break; - case IMX35_SDMA: - sdma->num_events = 48; - break; - default: - dev_err(sdma->dev, "Unknown sdma type %d. aborting\n", - sdma->devtype); - return -ENODEV; - } - clk_enable(sdma->clk_ipg); clk_enable(sdma->clk_ahb); @@ -1257,7 +1252,7 @@ static int __init sdma_init(struct sdma_engine *sdma) MAX_DMA_CHANNELS * sizeof (struct sdma_channel_control)); /* disable all channels */ - for (i = 0; i < sdma->num_events; i++) + for (i = 0; i < sdma->drvdata->num_events; i++) writel_relaxed(0, sdma->regs + chnenbl_ofs(sdma, i)); /* All channels have priority 0 */ @@ -1339,6 +1334,17 @@ static int __init sdma_probe(struct platform_device *pdev) int i; struct sdma_engine *sdma; s32 *saddr_arr; + const struct sdma_driver_data *drvdata = NULL; + + if (of_id) + drvdata = of_id->data; + else if (pdev->id_entry) + drvdata = (void *)pdev->id_entry->driver_data; + + if (!drvdata) { + dev_err(&pdev->dev, "unable to find driver data\n"); + return -EINVAL; + } sdma = kzalloc(sizeof(*sdma), GFP_KERNEL); if (!sdma) @@ -1347,6 +1353,7 @@ static int __init sdma_probe(struct platform_device *pdev) spin_lock_init(&sdma->channel_0_lock); sdma->dev = &pdev->dev; + sdma->drvdata = drvdata; iores = platform_get_resource(pdev, IORESOURCE_MEM, 0); irq = platform_get_irq(pdev, 0); @@ -1396,10 +1403,6 @@ static int __init sdma_probe(struct platform_device *pdev) for (i = 0; i < SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1; i++) saddr_arr[i] = -EINVAL; - if (of_id) - pdev->id_entry = of_id->data; - sdma->devtype = pdev->id_entry->driver_data; - dma_cap_set(DMA_SLAVE, sdma->dma_device.cap_mask); dma_cap_set(DMA_CYCLIC, sdma->dma_device.cap_mask); -- 1.8.4.rc3 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 2/3] dma: imx-sdma: Add ROM script addresses to driver 2013-08-19 12:16 [PATCH] dma: imx-sdma: Add ROM script addresses to driver Sascha Hauer 2013-08-19 12:16 ` [PATCH 1/3] dma: imx-sdma: Use struct for driver data Sascha Hauer @ 2013-08-19 12:16 ` Sascha Hauer 2013-08-19 14:41 ` Shawn Guo 2013-08-19 12:16 ` [PATCH 3/3] ARM: i.MX: remove sdma script address arrays from platform data Sascha Hauer 2013-08-19 22:23 ` [PATCH] dma: imx-sdma: Add ROM script addresses to driver Matt Sealey 3 siblings, 1 reply; 14+ messages in thread From: Sascha Hauer @ 2013-08-19 12:16 UTC (permalink / raw) To: linux-arm-kernel This adds the ROM script addresses to the SDMA driver needed for the driver to work without additional firmware. The ROM script addresses are SoC specific and in some cases even tapeout specific. This makes it necessary to introduce SoC specific and tapeout specific bindings for the driver. While extending the binding also make the <chip_type> explicit in the binding documentation. The non tapeout specific variants of the i.MX31/35 bindings are kept for compatibility. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- .../devicetree/bindings/dma/fsl-imx-sdma.txt | 7 +- drivers/dma/imx-sdma.c | 180 ++++++++++++++++++++- 2 files changed, 185 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt index 68cee4f5..4fa814d 100644 --- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt +++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt @@ -1,7 +1,12 @@ * Freescale Smart Direct Memory Access (SDMA) Controller for i.MX Required properties: -- compatible : Should be "fsl,<chip>-sdma" +- compatible : Should be "fsl,imx31-sdma", "fsl,imx31-to1-sdma", + "fsl,imx31-to2-sdma", "fsl,imx35-sdma", "fsl,imx35-to1-sdma", + "fsl,imx35-to2-sdma", "fsl,imx51-sdma", "fsl,imx53-sdma" or + "fsl,imx6q-sdma". The -to variants should be preferred since they + allow to determnine the correct ROM script addresses needed for + the driver to work without additional firmware. - reg : Should contain SDMA registers location and length - interrupts : Should contain SDMA interrupt - #dma-cells : Must be <3>. diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index e3e7e3f..42142b7 100644 --- a/drivers/dma/imx-sdma.c +++ b/drivers/dma/imx-sdma.c @@ -310,6 +310,7 @@ struct sdma_firmware_header { struct sdma_driver_data { int chnenbl0; int num_events; + struct sdma_script_start_addrs *script_addrs; }; struct sdma_engine { @@ -328,23 +329,191 @@ struct sdma_engine { const struct sdma_driver_data *drvdata; }; +static struct sdma_script_start_addrs sdma_script_imx31_to1 = { + .per_2_per_addr = 1677, +}; + +static struct sdma_script_start_addrs sdma_script_imx31_to2 = { + .ap_2_ap_addr = 423, + .ap_2_bp_addr = 829, + .bp_2_ap_addr = 1029, +}; + struct sdma_driver_data sdma_imx31 = { .chnenbl0 = SDMA_CHNENBL0_IMX31, .num_events = 32, }; +struct sdma_driver_data sdma_imx31_to1 = { + .chnenbl0 = SDMA_CHNENBL0_IMX31, + .num_events = 32, + .script_addrs = &sdma_script_imx31_to1, +}; + +struct sdma_driver_data sdma_imx31_to2 = { + .chnenbl0 = SDMA_CHNENBL0_IMX31, + .num_events = 32, + .script_addrs = &sdma_script_imx31_to2, +}; + +static struct sdma_script_start_addrs sdma_script_imx25 = { + .ap_2_ap_addr = 729, + .uart_2_mcu_addr = 904, + .per_2_app_addr = 1255, + .mcu_2_app_addr = 834, + .uartsh_2_mcu_addr = 1120, + .per_2_shp_addr = 1329, + .mcu_2_shp_addr = 1048, + .ata_2_mcu_addr = 1560, + .mcu_2_ata_addr = 1479, + .app_2_per_addr = 1189, + .app_2_mcu_addr = 770, + .shp_2_per_addr = 1407, + .shp_2_mcu_addr = 979, +}; + +struct sdma_driver_data sdma_imx25 = { + .chnenbl0 = SDMA_CHNENBL0_IMX35, + .num_events = 48, + .script_addrs = &sdma_script_imx25, +}; + +static struct sdma_script_start_addrs sdma_script_imx35_to1 = { + .ap_2_ap_addr = 642, + .uart_2_mcu_addr = 817, + .mcu_2_app_addr = 747, + .uartsh_2_mcu_addr = 1183, + .per_2_shp_addr = 1033, + .mcu_2_shp_addr = 961, + .ata_2_mcu_addr = 1333, + .mcu_2_ata_addr = 1252, + .app_2_mcu_addr = 683, + .shp_2_per_addr = 1111, + .shp_2_mcu_addr = 892, +}; + +static struct sdma_script_start_addrs sdma_script_imx35_to2 = { + .ap_2_ap_addr = 729, + .uart_2_mcu_addr = 904, + .per_2_app_addr = 1597, + .mcu_2_app_addr = 834, + .uartsh_2_mcu_addr = 1270, + .per_2_shp_addr = 1120, + .mcu_2_shp_addr = 1048, + .ata_2_mcu_addr = 1429, + .mcu_2_ata_addr = 1339, + .app_2_per_addr = 1531, + .app_2_mcu_addr = 770, + .shp_2_per_addr = 1198, + .shp_2_mcu_addr = 979, +}; + struct sdma_driver_data sdma_imx35 = { .chnenbl0 = SDMA_CHNENBL0_IMX35, .num_events = 48, }; +struct sdma_driver_data sdma_imx35_to1 = { + .chnenbl0 = SDMA_CHNENBL0_IMX35, + .num_events = 48, + .script_addrs = &sdma_script_imx35_to1, +}; + +struct sdma_driver_data sdma_imx35_to2 = { + .chnenbl0 = SDMA_CHNENBL0_IMX35, + .num_events = 48, + .script_addrs = &sdma_script_imx35_to2, +}; + +static struct sdma_script_start_addrs sdma_script_imx51 = { + .ap_2_ap_addr = 642, + .uart_2_mcu_addr = 817, + .mcu_2_app_addr = 747, + .mcu_2_shp_addr = 961, + .ata_2_mcu_addr = 1473, + .mcu_2_ata_addr = 1392, + .app_2_per_addr = 1033, + .app_2_mcu_addr = 683, + .shp_2_per_addr = 1251, + .shp_2_mcu_addr = 892, +}; + +struct sdma_driver_data sdma_imx51 = { + .chnenbl0 = SDMA_CHNENBL0_IMX35, + .num_events = 48, + .script_addrs = &sdma_script_imx51, +}; + +static struct sdma_script_start_addrs sdma_script_imx53 = { + .ap_2_ap_addr = 642, + .app_2_mcu_addr = 683, + .mcu_2_app_addr = 747, + .uart_2_mcu_addr = 817, + .shp_2_mcu_addr = 891, + .mcu_2_shp_addr = 960, + .uartsh_2_mcu_addr = 1032, + .spdif_2_mcu_addr = 1100, + .mcu_2_spdif_addr = 1134, + .firi_2_mcu_addr = 1193, + .mcu_2_firi_addr = 1290, +}; + +struct sdma_driver_data sdma_imx53 = { + .chnenbl0 = SDMA_CHNENBL0_IMX35, + .num_events = 48, + .script_addrs = &sdma_script_imx53, +}; + +static struct sdma_script_start_addrs sdma_script_imx6q = { + .ap_2_ap_addr = 642, + .uart_2_mcu_addr = 817, + .mcu_2_app_addr = 747, + .per_2_per_addr = 6331, + .uartsh_2_mcu_addr = 1032, + .mcu_2_shp_addr = 960, + .app_2_mcu_addr = 683, + .shp_2_mcu_addr = 891, + .spdif_2_mcu_addr = 1100, + .mcu_2_spdif_addr = 1134, +}; + +struct sdma_driver_data sdma_imx6q = { + .chnenbl0 = SDMA_CHNENBL0_IMX35, + .num_events = 48, + .script_addrs = &sdma_script_imx6q, +}; + static struct platform_device_id sdma_devtypes[] = { { + .name = "imx25-sdma", + .driver_data = (unsigned long)&sdma_imx25, + }, { .name = "imx31-sdma", .driver_data = (unsigned long)&sdma_imx31, + }, { + .name = "imx31-to1-sdma", + .driver_data = (unsigned long)&sdma_imx31_to1, + }, { + .name = "imx31-to2-sdma", + .driver_data = (unsigned long)&sdma_imx31_to2, }, { .name = "imx35-sdma", .driver_data = (unsigned long)&sdma_imx35, + }, { + .name = "imx35-to1-sdma", + .driver_data = (unsigned long)&sdma_imx35_to1, + }, { + .name = "imx35-to2-sdma", + .driver_data = (unsigned long)&sdma_imx35_to2, + }, { + .name = "imx51-sdma", + .driver_data = (unsigned long)&sdma_imx51, + }, { + .name = "imx53-sdma", + .driver_data = (unsigned long)&sdma_imx53, + }, { + .name = "imx6q-sdma", + .driver_data = (unsigned long)&sdma_imx6q, }, { /* sentinel */ } @@ -352,8 +521,15 @@ static struct platform_device_id sdma_devtypes[] = { MODULE_DEVICE_TABLE(platform, sdma_devtypes); static const struct of_device_id sdma_dt_ids[] = { - { .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, }, + { .compatible = "fsl,imx6q-sdma", .data = &sdma_imx6q, }, + { .compatible = "fsl,imx53-sdma", .data = &sdma_imx53, }, + { .compatible = "fsl,imx51-sdma", .data = &sdma_imx51, }, + { .compatible = "fsl,imx35-to2-sdma", .data = &sdma_imx35_to2, }, + { .compatible = "fsl,imx35-to1-sdma", .data = &sdma_imx35_to1, }, { .compatible = "fsl,imx35-sdma", .data = &sdma_imx35, }, + { .compatible = "fsl,imx31-to2-sdma", .data = &sdma_imx31_to2, }, + { .compatible = "fsl,imx31-to1-sdma", .data = &sdma_imx31_to1, }, + { .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, sdma_dt_ids); @@ -1434,6 +1610,8 @@ static int __init sdma_probe(struct platform_device *pdev) if (ret) goto err_init; + if (sdma->drvdata->script_addrs) + sdma_add_scripts(sdma, sdma->drvdata->script_addrs); if (pdata && pdata->script_addrs) sdma_add_scripts(sdma, pdata->script_addrs); -- 1.8.4.rc3 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 2/3] dma: imx-sdma: Add ROM script addresses to driver 2013-08-19 12:16 ` [PATCH 2/3] dma: imx-sdma: Add ROM script addresses to driver Sascha Hauer @ 2013-08-19 14:41 ` Shawn Guo 2013-08-19 17:39 ` Sascha Hauer 0 siblings, 1 reply; 14+ messages in thread From: Shawn Guo @ 2013-08-19 14:41 UTC (permalink / raw) To: linux-arm-kernel Copy devicetree mailing list. On Mon, Aug 19, 2013 at 02:16:02PM +0200, Sascha Hauer wrote: > This adds the ROM script addresses to the SDMA driver needed for the > driver to work without additional firmware. > > The ROM script addresses are SoC specific and in some cases even tapeout > specific. This makes it necessary to introduce SoC specific and tapeout > specific bindings for the driver. While extending the binding also make > the <chip_type> explicit in the binding documentation. > > The non tapeout specific variants of the i.MX31/35 bindings are kept > for compatibility. > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > --- > .../devicetree/bindings/dma/fsl-imx-sdma.txt | 7 +- > drivers/dma/imx-sdma.c | 180 ++++++++++++++++++++- > 2 files changed, 185 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt > index 68cee4f5..4fa814d 100644 > --- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt > +++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt > @@ -1,7 +1,12 @@ > * Freescale Smart Direct Memory Access (SDMA) Controller for i.MX > > Required properties: > -- compatible : Should be "fsl,<chip>-sdma" > +- compatible : Should be "fsl,imx31-sdma", "fsl,imx31-to1-sdma", > + "fsl,imx31-to2-sdma", "fsl,imx35-sdma", "fsl,imx35-to1-sdma", > + "fsl,imx35-to2-sdma", "fsl,imx51-sdma", "fsl,imx53-sdma" or > + "fsl,imx6q-sdma". The -to variants should be preferred since they > + allow to determnine the correct ROM script addresses needed for > + the driver to work without additional firmware. > - reg : Should contain SDMA registers location and length > - interrupts : Should contain SDMA interrupt > - #dma-cells : Must be <3>. > diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c > index e3e7e3f..42142b7 100644 > --- a/drivers/dma/imx-sdma.c > +++ b/drivers/dma/imx-sdma.c > @@ -310,6 +310,7 @@ struct sdma_firmware_header { > struct sdma_driver_data { > int chnenbl0; > int num_events; > + struct sdma_script_start_addrs *script_addrs; > }; > > struct sdma_engine { > @@ -328,23 +329,191 @@ struct sdma_engine { > const struct sdma_driver_data *drvdata; > }; > > +static struct sdma_script_start_addrs sdma_script_imx31_to1 = { > + .per_2_per_addr = 1677, > +}; > + > +static struct sdma_script_start_addrs sdma_script_imx31_to2 = { > + .ap_2_ap_addr = 423, > + .ap_2_bp_addr = 829, > + .bp_2_ap_addr = 1029, > +}; > + > struct sdma_driver_data sdma_imx31 = { > .chnenbl0 = SDMA_CHNENBL0_IMX31, > .num_events = 32, > }; > > +struct sdma_driver_data sdma_imx31_to1 = { > + .chnenbl0 = SDMA_CHNENBL0_IMX31, > + .num_events = 32, > + .script_addrs = &sdma_script_imx31_to1, > +}; > + > +struct sdma_driver_data sdma_imx31_to2 = { > + .chnenbl0 = SDMA_CHNENBL0_IMX31, > + .num_events = 32, > + .script_addrs = &sdma_script_imx31_to2, > +}; > + > +static struct sdma_script_start_addrs sdma_script_imx25 = { > + .ap_2_ap_addr = 729, > + .uart_2_mcu_addr = 904, > + .per_2_app_addr = 1255, > + .mcu_2_app_addr = 834, > + .uartsh_2_mcu_addr = 1120, > + .per_2_shp_addr = 1329, > + .mcu_2_shp_addr = 1048, > + .ata_2_mcu_addr = 1560, > + .mcu_2_ata_addr = 1479, > + .app_2_per_addr = 1189, > + .app_2_mcu_addr = 770, > + .shp_2_per_addr = 1407, > + .shp_2_mcu_addr = 979, > +}; > + > +struct sdma_driver_data sdma_imx25 = { > + .chnenbl0 = SDMA_CHNENBL0_IMX35, > + .num_events = 48, > + .script_addrs = &sdma_script_imx25, > +}; > + > +static struct sdma_script_start_addrs sdma_script_imx35_to1 = { > + .ap_2_ap_addr = 642, > + .uart_2_mcu_addr = 817, > + .mcu_2_app_addr = 747, > + .uartsh_2_mcu_addr = 1183, > + .per_2_shp_addr = 1033, > + .mcu_2_shp_addr = 961, > + .ata_2_mcu_addr = 1333, > + .mcu_2_ata_addr = 1252, > + .app_2_mcu_addr = 683, > + .shp_2_per_addr = 1111, > + .shp_2_mcu_addr = 892, > +}; > + > +static struct sdma_script_start_addrs sdma_script_imx35_to2 = { > + .ap_2_ap_addr = 729, > + .uart_2_mcu_addr = 904, > + .per_2_app_addr = 1597, > + .mcu_2_app_addr = 834, > + .uartsh_2_mcu_addr = 1270, > + .per_2_shp_addr = 1120, > + .mcu_2_shp_addr = 1048, > + .ata_2_mcu_addr = 1429, > + .mcu_2_ata_addr = 1339, > + .app_2_per_addr = 1531, > + .app_2_mcu_addr = 770, > + .shp_2_per_addr = 1198, > + .shp_2_mcu_addr = 979, > +}; > + > struct sdma_driver_data sdma_imx35 = { > .chnenbl0 = SDMA_CHNENBL0_IMX35, > .num_events = 48, > }; > > +struct sdma_driver_data sdma_imx35_to1 = { > + .chnenbl0 = SDMA_CHNENBL0_IMX35, > + .num_events = 48, > + .script_addrs = &sdma_script_imx35_to1, > +}; > + > +struct sdma_driver_data sdma_imx35_to2 = { > + .chnenbl0 = SDMA_CHNENBL0_IMX35, > + .num_events = 48, > + .script_addrs = &sdma_script_imx35_to2, > +}; > + > +static struct sdma_script_start_addrs sdma_script_imx51 = { > + .ap_2_ap_addr = 642, > + .uart_2_mcu_addr = 817, > + .mcu_2_app_addr = 747, > + .mcu_2_shp_addr = 961, > + .ata_2_mcu_addr = 1473, > + .mcu_2_ata_addr = 1392, > + .app_2_per_addr = 1033, > + .app_2_mcu_addr = 683, > + .shp_2_per_addr = 1251, > + .shp_2_mcu_addr = 892, > +}; > + > +struct sdma_driver_data sdma_imx51 = { > + .chnenbl0 = SDMA_CHNENBL0_IMX35, > + .num_events = 48, > + .script_addrs = &sdma_script_imx51, > +}; > + > +static struct sdma_script_start_addrs sdma_script_imx53 = { > + .ap_2_ap_addr = 642, > + .app_2_mcu_addr = 683, > + .mcu_2_app_addr = 747, > + .uart_2_mcu_addr = 817, > + .shp_2_mcu_addr = 891, > + .mcu_2_shp_addr = 960, > + .uartsh_2_mcu_addr = 1032, > + .spdif_2_mcu_addr = 1100, > + .mcu_2_spdif_addr = 1134, > + .firi_2_mcu_addr = 1193, > + .mcu_2_firi_addr = 1290, > +}; > + > +struct sdma_driver_data sdma_imx53 = { > + .chnenbl0 = SDMA_CHNENBL0_IMX35, > + .num_events = 48, > + .script_addrs = &sdma_script_imx53, > +}; > + > +static struct sdma_script_start_addrs sdma_script_imx6q = { > + .ap_2_ap_addr = 642, > + .uart_2_mcu_addr = 817, > + .mcu_2_app_addr = 747, > + .per_2_per_addr = 6331, > + .uartsh_2_mcu_addr = 1032, > + .mcu_2_shp_addr = 960, > + .app_2_mcu_addr = 683, > + .shp_2_mcu_addr = 891, > + .spdif_2_mcu_addr = 1100, > + .mcu_2_spdif_addr = 1134, > +}; > + > +struct sdma_driver_data sdma_imx6q = { > + .chnenbl0 = SDMA_CHNENBL0_IMX35, > + .num_events = 48, > + .script_addrs = &sdma_script_imx6q, > +}; > + > static struct platform_device_id sdma_devtypes[] = { > { > + .name = "imx25-sdma", > + .driver_data = (unsigned long)&sdma_imx25, > + }, { > .name = "imx31-sdma", > .driver_data = (unsigned long)&sdma_imx31, > + }, { > + .name = "imx31-to1-sdma", > + .driver_data = (unsigned long)&sdma_imx31_to1, > + }, { > + .name = "imx31-to2-sdma", > + .driver_data = (unsigned long)&sdma_imx31_to2, > }, { > .name = "imx35-sdma", > .driver_data = (unsigned long)&sdma_imx35, > + }, { > + .name = "imx35-to1-sdma", > + .driver_data = (unsigned long)&sdma_imx35_to1, > + }, { > + .name = "imx35-to2-sdma", > + .driver_data = (unsigned long)&sdma_imx35_to2, > + }, { > + .name = "imx51-sdma", > + .driver_data = (unsigned long)&sdma_imx51, > + }, { > + .name = "imx53-sdma", > + .driver_data = (unsigned long)&sdma_imx53, > + }, { > + .name = "imx6q-sdma", > + .driver_data = (unsigned long)&sdma_imx6q, > }, { > /* sentinel */ > } > @@ -352,8 +521,15 @@ static struct platform_device_id sdma_devtypes[] = { > MODULE_DEVICE_TABLE(platform, sdma_devtypes); > > static const struct of_device_id sdma_dt_ids[] = { > - { .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, }, > + { .compatible = "fsl,imx6q-sdma", .data = &sdma_imx6q, }, > + { .compatible = "fsl,imx53-sdma", .data = &sdma_imx53, }, > + { .compatible = "fsl,imx51-sdma", .data = &sdma_imx51, }, > + { .compatible = "fsl,imx35-to2-sdma", .data = &sdma_imx35_to2, }, > + { .compatible = "fsl,imx35-to1-sdma", .data = &sdma_imx35_to1, }, > { .compatible = "fsl,imx35-sdma", .data = &sdma_imx35, }, Do we need to bind the compatible with sdma_imx35_to2 like below? { .compatible = "fsl,imx35-sdma", .data = &sdma_imx35_to2, }, Otherwise, we will need to patch sdma_imx35 with proper .script_addrs assignment? Also, I do not know how we will play these tapeout specific compatible in device tree. As you know, we currently do not have tapeout but only chip specific DTS, since we expect kernel will figure out the tapeout/revision and handle the differences accordingly. Shawn > + { .compatible = "fsl,imx31-to2-sdma", .data = &sdma_imx31_to2, }, > + { .compatible = "fsl,imx31-to1-sdma", .data = &sdma_imx31_to1, }, > + { .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, }, > { /* sentinel */ } > }; > MODULE_DEVICE_TABLE(of, sdma_dt_ids); > @@ -1434,6 +1610,8 @@ static int __init sdma_probe(struct platform_device *pdev) > if (ret) > goto err_init; > > + if (sdma->drvdata->script_addrs) > + sdma_add_scripts(sdma, sdma->drvdata->script_addrs); > if (pdata && pdata->script_addrs) > sdma_add_scripts(sdma, pdata->script_addrs); > > -- > 1.8.4.rc3 > ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 2/3] dma: imx-sdma: Add ROM script addresses to driver 2013-08-19 14:41 ` Shawn Guo @ 2013-08-19 17:39 ` Sascha Hauer 2013-08-20 2:35 ` Shawn Guo 0 siblings, 1 reply; 14+ messages in thread From: Sascha Hauer @ 2013-08-19 17:39 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 19, 2013 at 10:41:38PM +0800, Shawn Guo wrote: > Copy devicetree mailing list. > > > @@ -352,8 +521,15 @@ static struct platform_device_id sdma_devtypes[] = { > > MODULE_DEVICE_TABLE(platform, sdma_devtypes); > > > > static const struct of_device_id sdma_dt_ids[] = { > > - { .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, }, > > + { .compatible = "fsl,imx6q-sdma", .data = &sdma_imx6q, }, > > + { .compatible = "fsl,imx53-sdma", .data = &sdma_imx53, }, > > + { .compatible = "fsl,imx51-sdma", .data = &sdma_imx51, }, > > + { .compatible = "fsl,imx35-to2-sdma", .data = &sdma_imx35_to2, }, > > + { .compatible = "fsl,imx35-to1-sdma", .data = &sdma_imx35_to1, }, > > { .compatible = "fsl,imx35-sdma", .data = &sdma_imx35, }, > > Do we need to bind the compatible with sdma_imx35_to2 like below? > > { .compatible = "fsl,imx35-sdma", .data = &sdma_imx35_to2, }, If we do this we assume that every i.MX35 is TO2. TO1 revisions will misbehave then. I intentionally didn't do this so that the current binding continues to work as before without script addresses. > > Otherwise, we will need to patch sdma_imx35 with proper .script_addrs > assignment? > > Also, I do not know how we will play these tapeout specific compatible > in device tree. As you know, we currently do not have tapeout but only > chip specific DTS, since we expect kernel will figure out the > tapeout/revision and handle the differences accordingly. In fact the kernel does figure out the tapeout version, but I don't have access to it in the driver. Currently we have a problem anyway. We have the firmware names in the dts, but the firmware is tapeout specific for i.MX31/35. So I think our options are: - remove the tapeout specifics from the devicetrees, this would mean to also remove the firmware names. - keep the tapeout specifics in the devicetree, then we could even add some more like I did ;) I don't know what's the best way to proceed. For now I could remove the tapeout specific bindings, this way we would get the ROM script addresses at least for i.MX25/5/6. Sascha -- 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 [flat|nested] 14+ messages in thread
* [PATCH 2/3] dma: imx-sdma: Add ROM script addresses to driver 2013-08-19 17:39 ` Sascha Hauer @ 2013-08-20 2:35 ` Shawn Guo 2013-08-20 6:42 ` Sascha Hauer 0 siblings, 1 reply; 14+ messages in thread From: Shawn Guo @ 2013-08-20 2:35 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 19, 2013 at 07:39:12PM +0200, Sascha Hauer wrote: > On Mon, Aug 19, 2013 at 10:41:38PM +0800, Shawn Guo wrote: > > Copy devicetree mailing list. > > > > > @@ -352,8 +521,15 @@ static struct platform_device_id sdma_devtypes[] = { > > > MODULE_DEVICE_TABLE(platform, sdma_devtypes); > > > > > > static const struct of_device_id sdma_dt_ids[] = { > > > - { .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, }, > > > + { .compatible = "fsl,imx6q-sdma", .data = &sdma_imx6q, }, > > > + { .compatible = "fsl,imx53-sdma", .data = &sdma_imx53, }, > > > + { .compatible = "fsl,imx51-sdma", .data = &sdma_imx51, }, > > > + { .compatible = "fsl,imx35-to2-sdma", .data = &sdma_imx35_to2, }, > > > + { .compatible = "fsl,imx35-to1-sdma", .data = &sdma_imx35_to1, }, > > > { .compatible = "fsl,imx35-sdma", .data = &sdma_imx35, }, <snip> > > Also, I do not know how we will play these tapeout specific compatible > > in device tree. As you know, we currently do not have tapeout but only > > chip specific DTS, since we expect kernel will figure out the > > tapeout/revision and handle the differences accordingly. > > In fact the kernel does figure out the tapeout version, but I don't have > access to it in the driver. Yeah. But since we're using SoC for IP versioning and the version could vary even for same SoC between different revisions, I think we will see such need of accessing SoC revision from device driver more and more. Thus, we will need a generic approach for that sooner or later, I guess. One approach I can think of is that we define a property "revision" under node "soc", and ask platform code to fill this property by calling of_update_property(). Then drivers can simply get it via device tree /soc/revision. > > Currently we have a problem anyway. We have the firmware names in the > dts, but the firmware is tapeout specific for i.MX31/35. > > So I think our options are: > > - remove the tapeout specifics from the devicetrees, this would mean to > also remove the firmware names. > - keep the tapeout specifics in the devicetree, then we could even add > some more like I did ;) If I understand this option correctly, we will need something like imx35-to1.dtsi and imx35-to2.dtsi, and board level dts authors need to include the correct one per the chip revision on their boards. What about some board that solder both revisions, and socket board that can change chips? I do not think it's going to work. > > I don't know what's the best way to proceed. For now I could remove the > tapeout specific bindings, this way we would get the ROM script > addresses at least for i.MX25/5/6. Yeah, it's still something nice. Shawn ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 2/3] dma: imx-sdma: Add ROM script addresses to driver 2013-08-20 2:35 ` Shawn Guo @ 2013-08-20 6:42 ` Sascha Hauer 0 siblings, 0 replies; 14+ messages in thread From: Sascha Hauer @ 2013-08-20 6:42 UTC (permalink / raw) To: linux-arm-kernel On Tue, Aug 20, 2013 at 10:35:51AM +0800, Shawn Guo wrote: > On Mon, Aug 19, 2013 at 07:39:12PM +0200, Sascha Hauer wrote: > > On Mon, Aug 19, 2013 at 10:41:38PM +0800, Shawn Guo wrote: > > > Copy devicetree mailing list. > > > > > > > @@ -352,8 +521,15 @@ static struct platform_device_id sdma_devtypes[] = { > > > > MODULE_DEVICE_TABLE(platform, sdma_devtypes); > > > > > > > > static const struct of_device_id sdma_dt_ids[] = { > > > > - { .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, }, > > > > + { .compatible = "fsl,imx6q-sdma", .data = &sdma_imx6q, }, > > > > + { .compatible = "fsl,imx53-sdma", .data = &sdma_imx53, }, > > > > + { .compatible = "fsl,imx51-sdma", .data = &sdma_imx51, }, > > > > + { .compatible = "fsl,imx35-to2-sdma", .data = &sdma_imx35_to2, }, > > > > + { .compatible = "fsl,imx35-to1-sdma", .data = &sdma_imx35_to1, }, > > > > { .compatible = "fsl,imx35-sdma", .data = &sdma_imx35, }, > > <snip> > > > > Also, I do not know how we will play these tapeout specific compatible > > > in device tree. As you know, we currently do not have tapeout but only > > > chip specific DTS, since we expect kernel will figure out the > > > tapeout/revision and handle the differences accordingly. > > > > In fact the kernel does figure out the tapeout version, but I don't have > > access to it in the driver. > > Yeah. But since we're using SoC for IP versioning and the version could > vary even for same SoC between different revisions, I think we will see > such need of accessing SoC revision from device driver more and more. > Thus, we will need a generic approach for that sooner or later, I guess. > > One approach I can think of is that we define a property "revision" > under node "soc", and ask platform code to fill this property by calling > of_update_property(). Then drivers can simply get it via device tree > /soc/revision. If the IP differs between SoC revisions then I would argue these should have different compatible entries. Otherwise we end up coding SoC specifics in the driver, something we just recently got rid of. Of course it's not very convenient to let the bootloader adjust the dtb for different SoC revisions. This leaves the kernel architecture code to do it. > > > > > Currently we have a problem anyway. We have the firmware names in the > > dts, but the firmware is tapeout specific for i.MX31/35. > > > > So I think our options are: > > > > - remove the tapeout specifics from the devicetrees, this would mean to > > also remove the firmware names. > > - keep the tapeout specifics in the devicetree, then we could even add > > some more like I did ;) > > If I understand this option correctly, we will need something like > imx35-to1.dtsi and imx35-to2.dtsi, and board level dts authors need to > include the correct one per the chip revision on their boards. What > about some board that solder both revisions, and socket board that can > change chips? I do not think it's going to work. I would not go the way to have two different dtsi files in the kernel. If we want to go this way we either have to let the bootloader or the kernel architecture code fix it up between SoC revisions. I'll postpone this problem for now by removing the ROM script support for i.MX31/35. Sascha -- 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 [flat|nested] 14+ messages in thread
* [PATCH 3/3] ARM: i.MX: remove sdma script address arrays from platform data 2013-08-19 12:16 [PATCH] dma: imx-sdma: Add ROM script addresses to driver Sascha Hauer 2013-08-19 12:16 ` [PATCH 1/3] dma: imx-sdma: Use struct for driver data Sascha Hauer 2013-08-19 12:16 ` [PATCH 2/3] dma: imx-sdma: Add ROM script addresses to driver Sascha Hauer @ 2013-08-19 12:16 ` Sascha Hauer 2013-08-19 22:23 ` [PATCH] dma: imx-sdma: Add ROM script addresses to driver Matt Sealey 3 siblings, 0 replies; 14+ messages in thread From: Sascha Hauer @ 2013-08-19 12:16 UTC (permalink / raw) To: linux-arm-kernel Now that the sdma driver holds the address tables they are no longer needed in platform_data. Remove them. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- arch/arm/mach-imx/mm-imx25.c | 17 ----------- arch/arm/mach-imx/mm-imx3.c | 67 +++++++++----------------------------------- arch/arm/mach-imx/mm-imx5.c | 14 --------- 3 files changed, 13 insertions(+), 85 deletions(-) diff --git a/arch/arm/mach-imx/mm-imx25.c b/arch/arm/mach-imx/mm-imx25.c index e065c11..5211f62 100644 --- a/arch/arm/mach-imx/mm-imx25.c +++ b/arch/arm/mach-imx/mm-imx25.c @@ -61,25 +61,8 @@ void __init mx25_init_irq(void) mxc_init_irq(MX25_IO_ADDRESS(MX25_AVIC_BASE_ADDR)); } -static struct sdma_script_start_addrs imx25_sdma_script __initdata = { - .ap_2_ap_addr = 729, - .uart_2_mcu_addr = 904, - .per_2_app_addr = 1255, - .mcu_2_app_addr = 834, - .uartsh_2_mcu_addr = 1120, - .per_2_shp_addr = 1329, - .mcu_2_shp_addr = 1048, - .ata_2_mcu_addr = 1560, - .mcu_2_ata_addr = 1479, - .app_2_per_addr = 1189, - .app_2_mcu_addr = 770, - .shp_2_per_addr = 1407, - .shp_2_mcu_addr = 979, -}; - static struct sdma_platform_data imx25_sdma_pdata __initdata = { .fw_name = "sdma-imx25.bin", - .script_addrs = &imx25_sdma_script, }; static const struct resource imx25_audmux_res[] __initconst = { diff --git a/arch/arm/mach-imx/mm-imx3.c b/arch/arm/mach-imx/mm-imx3.c index 0884ca9..53005db 100644 --- a/arch/arm/mach-imx/mm-imx3.c +++ b/arch/arm/mach-imx/mm-imx3.c @@ -148,19 +148,8 @@ void __init mx31_init_irq(void) mxc_init_irq(MX31_IO_ADDRESS(MX31_AVIC_BASE_ADDR)); } -static struct sdma_script_start_addrs imx31_to1_sdma_script __initdata = { - .per_2_per_addr = 1677, -}; - -static struct sdma_script_start_addrs imx31_to2_sdma_script __initdata = { - .ap_2_ap_addr = 423, - .ap_2_bp_addr = 829, - .bp_2_ap_addr = 1029, -}; - static struct sdma_platform_data imx31_sdma_pdata __initdata = { .fw_name = "sdma-imx31-to2.bin", - .script_addrs = &imx31_to2_sdma_script, }; static const struct resource imx31_audmux_res[] __initconst = { @@ -170,6 +159,7 @@ static const struct resource imx31_audmux_res[] __initconst = { void __init imx31_soc_init(void) { int to_version = mx31_revision() >> 4; + char *sdmastr; imx3_init_l2x0(); @@ -182,13 +172,12 @@ void __init imx31_soc_init(void) pinctrl_provide_dummies(); - if (to_version == 1) { - strncpy(imx31_sdma_pdata.fw_name, "sdma-imx31-to1.bin", - strlen(imx31_sdma_pdata.fw_name)); - imx31_sdma_pdata.script_addrs = &imx31_to1_sdma_script; - } + if (to_version == 1) + sdmastr = "imx31-to1-sdma"; + else + sdmastr = "imx31-to2-sdma"; - imx_add_imx_sdma("imx31-sdma", MX31_SDMA_BASE_ADDR, MX31_INT_SDMA, &imx31_sdma_pdata); + imx_add_imx_sdma(sdmastr, MX31_SDMA_BASE_ADDR, MX31_INT_SDMA, &imx31_sdma_pdata); imx_set_aips(MX31_IO_ADDRESS(MX31_AIPS1_BASE_ADDR)); imx_set_aips(MX31_IO_ADDRESS(MX31_AIPS2_BASE_ADDR)); @@ -226,39 +215,8 @@ void __init mx35_init_irq(void) mxc_init_irq(MX35_IO_ADDRESS(MX35_AVIC_BASE_ADDR)); } -static struct sdma_script_start_addrs imx35_to1_sdma_script __initdata = { - .ap_2_ap_addr = 642, - .uart_2_mcu_addr = 817, - .mcu_2_app_addr = 747, - .uartsh_2_mcu_addr = 1183, - .per_2_shp_addr = 1033, - .mcu_2_shp_addr = 961, - .ata_2_mcu_addr = 1333, - .mcu_2_ata_addr = 1252, - .app_2_mcu_addr = 683, - .shp_2_per_addr = 1111, - .shp_2_mcu_addr = 892, -}; - -static struct sdma_script_start_addrs imx35_to2_sdma_script __initdata = { - .ap_2_ap_addr = 729, - .uart_2_mcu_addr = 904, - .per_2_app_addr = 1597, - .mcu_2_app_addr = 834, - .uartsh_2_mcu_addr = 1270, - .per_2_shp_addr = 1120, - .mcu_2_shp_addr = 1048, - .ata_2_mcu_addr = 1429, - .mcu_2_ata_addr = 1339, - .app_2_per_addr = 1531, - .app_2_mcu_addr = 770, - .shp_2_per_addr = 1198, - .shp_2_mcu_addr = 979, -}; - static struct sdma_platform_data imx35_sdma_pdata __initdata = { .fw_name = "sdma-imx35-to2.bin", - .script_addrs = &imx35_to2_sdma_script, }; static const struct resource imx35_audmux_res[] __initconst = { @@ -268,6 +226,7 @@ static const struct resource imx35_audmux_res[] __initconst = { void __init imx35_soc_init(void) { int to_version = mx35_revision() >> 4; + char *sdmastr; imx3_init_l2x0(); @@ -279,13 +238,13 @@ void __init imx35_soc_init(void) mxc_register_gpio("imx35-gpio", 2, MX35_GPIO3_BASE_ADDR, SZ_16K, MX35_INT_GPIO3, 0); pinctrl_provide_dummies(); - if (to_version == 1) { - strncpy(imx35_sdma_pdata.fw_name, "sdma-imx35-to1.bin", - strlen(imx35_sdma_pdata.fw_name)); - imx35_sdma_pdata.script_addrs = &imx35_to1_sdma_script; - } - imx_add_imx_sdma("imx35-sdma", MX35_SDMA_BASE_ADDR, MX35_INT_SDMA, &imx35_sdma_pdata); + if (to_version == 1) + sdmastr = "imx35-to1-sdma"; + else + sdmastr = "imx35-to2-sdma"; + + imx_add_imx_sdma(sdmastr, MX35_SDMA_BASE_ADDR, MX35_INT_SDMA, &imx35_sdma_pdata); /* Setup AIPS registers */ imx_set_aips(MX35_IO_ADDRESS(MX35_AIPS1_BASE_ADDR)); diff --git a/arch/arm/mach-imx/mm-imx5.c b/arch/arm/mach-imx/mm-imx5.c index cf193d8..051add9 100644 --- a/arch/arm/mach-imx/mm-imx5.c +++ b/arch/arm/mach-imx/mm-imx5.c @@ -103,22 +103,8 @@ void __init mx53_init_irq(void) tzic_init_irq(MX53_IO_ADDRESS(MX53_TZIC_BASE_ADDR)); } -static struct sdma_script_start_addrs imx51_sdma_script __initdata = { - .ap_2_ap_addr = 642, - .uart_2_mcu_addr = 817, - .mcu_2_app_addr = 747, - .mcu_2_shp_addr = 961, - .ata_2_mcu_addr = 1473, - .mcu_2_ata_addr = 1392, - .app_2_per_addr = 1033, - .app_2_mcu_addr = 683, - .shp_2_per_addr = 1251, - .shp_2_mcu_addr = 892, -}; - static struct sdma_platform_data imx51_sdma_pdata __initdata = { .fw_name = "sdma-imx51.bin", - .script_addrs = &imx51_sdma_script, }; static const struct resource imx51_audmux_res[] __initconst = { -- 1.8.4.rc3 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH] dma: imx-sdma: Add ROM script addresses to driver 2013-08-19 12:16 [PATCH] dma: imx-sdma: Add ROM script addresses to driver Sascha Hauer ` (2 preceding siblings ...) 2013-08-19 12:16 ` [PATCH 3/3] ARM: i.MX: remove sdma script address arrays from platform data Sascha Hauer @ 2013-08-19 22:23 ` Matt Sealey 2013-08-20 7:00 ` Sascha Hauer 3 siblings, 1 reply; 14+ messages in thread From: Matt Sealey @ 2013-08-19 22:23 UTC (permalink / raw) To: linux-arm-kernel Please could you describe how the compatible property allows matching and covers both the ROM version *and* the distributed firmware file that is also referenced in the device tree for each sdma node for each SoC supported? As far as I recall, the offsets for the (potentially buggy) on-chip version and the one in the BSP (and hopefully in upstream kernels at some soon-approaching version) are not the same for a good swath of these chips. How would the driver hope to match this up without causing some DMA explosions and/or invalid device trees if the BSP firmware is described, the BSP firmware file is not found, and the driver is left with the ROM version? Ta, Matt On Mon, Aug 19, 2013 at 7:16 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > The following series adds the ROM script addresses to the driver. > These have been provided by platform_data for platform based systems, > but with devicetree the driver no longer supports the ROM script > addresses. This means that the sdma driver currently needs a firmware > to work. By adding the script addresses to the driver it can work > without additional firmware. > > Sascha > > ---------------------------------------------------------------- > Sascha Hauer (3): > dma: imx-sdma: Use struct for driver data > dma: imx-sdma: Add ROM script addresses to driver > ARM: i.MX: remove sdma script address arrays from platform data > > .../devicetree/bindings/dma/fsl-imx-sdma.txt | 7 +- > arch/arm/mach-imx/mm-imx25.c | 17 -- > arch/arm/mach-imx/mm-imx3.c | 67 ++---- > arch/arm/mach-imx/mm-imx5.c | 14 -- > drivers/dma/imx-sdma.c | 241 ++++++++++++++++++--- > 5 files changed, 230 insertions(+), 116 deletions(-) > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] dma: imx-sdma: Add ROM script addresses to driver 2013-08-19 22:23 ` [PATCH] dma: imx-sdma: Add ROM script addresses to driver Matt Sealey @ 2013-08-20 7:00 ` Sascha Hauer 2013-08-20 13:53 ` Matt Sealey 0 siblings, 1 reply; 14+ messages in thread From: Sascha Hauer @ 2013-08-20 7:00 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 19, 2013 at 05:23:40PM -0500, Matt Sealey wrote: > Please could you describe how the compatible property allows matching > and covers both the ROM version *and* the distributed firmware file > that is also referenced in the device tree for each sdma node for each > SoC supported? As said, we have a problem here since currently the dts references a single firmware file in a compatible entry which covers two SoC revisions. Both SoC revisions need a different firmware file. > As far as I recall, the offsets for the (potentially > buggy) on-chip version and the one in the BSP (and hopefully in > upstream kernels at some soon-approaching version) are not the same > for a good swath of these chips. The patch only adds the ROM code addresses which don't change. If a ROM script turns out to be buggy, just remove the corresponding pointer from the driver. Even if you don't remove it, a RAM firmware file is always able to overwrite already existing pointers. > > How would the driver hope to match this up without causing some DMA > explosions and/or invalid device trees if the BSP firmware is > described, the BSP firmware file is not found, and the driver is left > with the ROM version? The driver only contains the ROM script addresses which don't change. As said, if one turns out to be buggy, remove the correspong pointer. What kind of DMA explosions do you envision? Sascha -- 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 [flat|nested] 14+ messages in thread
* [PATCH] dma: imx-sdma: Add ROM script addresses to driver 2013-08-20 7:00 ` Sascha Hauer @ 2013-08-20 13:53 ` Matt Sealey 2013-08-20 15:02 ` Sascha Hauer 0 siblings, 1 reply; 14+ messages in thread From: Matt Sealey @ 2013-08-20 13:53 UTC (permalink / raw) To: linux-arm-kernel You know what, I am really confused by this in the first place. Since when did the SDMA driver actually support ROM addresses in device tree anyway (referring your comments in the patch series) and when did it get removed? Why is platform data somehow now required in a driver and not being put in it's correct place in the device tree? Why require a firmware file for anything here, bugs notwithstanding? As far as I recall there were one or two in older tape-out i.MX6 (uart dma I think) and a few more in i.MX51 and i.MX53 early tapeouts. I was sure I saw some BSP commits that update the firmware to fix some bugs in production tape-outs (oddly they're seemingly not in the errata for any tape-out?). The ROM addresses should be in DT, and for those devices that now have platform_data glue hardcoding the vaues, they'll work. DT platforms won't. I don't understand here how it's not possible to specify the ROM addresses in the DT for instance using the way regulators are handled (but I'd want to see reg used to specify the address and name instead of a custom properties in this case). What I'd really like to see is the "waiting on a firmware that doesn't exist when there is a working ROM version of those scripts in the SoC" bug fixed properly, by using ROM addresses in DT - specifying the "wrong" addresses is a device tree bug for that board with that tape-out or users using the wrong device-tree. Then fudging platform_data for non-DT platforms makes sense in that they have no DTs. And when they are converted they will follow suit anyway - there's a path to take to get there that is really clear. In this case it is just hardcoding one or two SoC and then leaving the rest tha tare actually device-tree compliant to use that abominable, OS-specific firmware path name property.. keeping the hangs. I'm really trying to figure out the intent and design process here, because from a perspective of getting more device tree support this really is stepping backwards via a hack to get a couple boards to work. -- Matt ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] dma: imx-sdma: Add ROM script addresses to driver 2013-08-20 13:53 ` Matt Sealey @ 2013-08-20 15:02 ` Sascha Hauer 2013-08-29 17:23 ` Matt Sealey 0 siblings, 1 reply; 14+ messages in thread From: Sascha Hauer @ 2013-08-20 15:02 UTC (permalink / raw) To: linux-arm-kernel On Tue, Aug 20, 2013 at 08:53:42AM -0500, Matt Sealey wrote: > You know what, I am really confused by this in the first place. Since > when did the SDMA driver actually support ROM addresses in device tree > anyway (referring your comments in the patch series) and when did it > get removed? Why is platform data somehow now required in a driver and > not being put in it's correct place in the device tree? The SDMA driver never supported ROM script addresses when probed from the devicetree. This was only ever supported with platform based devices. With devicetree probing platform data never was and and is not required. > > Why require a firmware file for anything here, bugs notwithstanding? > As far as I recall there were one or two in older tape-out i.MX6 (uart > dma I think) and a few more in i.MX51 and i.MX53 early tapeouts. I was > sure I saw some BSP commits that update the firmware to fix some bugs > in production tape-outs (oddly they're seemingly not in the errata for > any tape-out?). The ROM addresses should be in DT, and for those > devices that now have platform_data glue hardcoding the vaues, they'll > work. DT platforms won't. > > I don't understand here how it's not possible to specify the ROM > addresses in the DT for instance using the way regulators are handled > (but I'd want to see reg used to specify the address and name instead > of a custom properties in this case). We could specify ROM addresses in the dt, but why should we do this? It would just add more API between the kernel and the dt for no gain. > > What I'd really like to see is the "waiting on a firmware that doesn't > exist when there is a working ROM version of those scripts in the SoC" Then this patch is for you. This is exactly what the patch solves. > bug fixed properly, by using ROM addresses in DT - specifying the > "wrong" addresses is a device tree bug for that board with that > tape-out or users using the wrong device-tree. Then fudging > platform_data for non-DT platforms makes sense in that they have no > DTs. And when they are converted they will follow suit anyway - > there's a path to take to get there that is really clear. > > In this case it is just hardcoding one or two SoC and then leaving the > rest tha tare actually device-tree compliant to use that abominable, > OS-specific firmware path name property.. keeping the hangs. I'm > really trying to figure out the intent and design process here, > because from a perspective of getting more device tree support this > really is stepping backwards via a hack to get a couple boards to > work. This patch is by no means board specific. Sascha -- 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 [flat|nested] 14+ messages in thread
* [PATCH] dma: imx-sdma: Add ROM script addresses to driver 2013-08-20 15:02 ` Sascha Hauer @ 2013-08-29 17:23 ` Matt Sealey 2013-08-31 8:56 ` Sascha Hauer 0 siblings, 1 reply; 14+ messages in thread From: Matt Sealey @ 2013-08-29 17:23 UTC (permalink / raw) To: linux-arm-kernel On Tue, Aug 20, 2013 at 10:02 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > >> What I'd really like to see is the "waiting on a firmware that doesn't >> exist when there is a working ROM version of those scripts in the SoC" > > Then this patch is for you. This is exactly what the patch solves. Only by changing the device tree and not specifying a firmware filename. The driver probes, knows about ROM script addresses as per your patch, tries to load a new file from disk; same hang. What you have now is a way to use a potentially buggy script with several functions missing (ROM script isn't as full-featured as the file-based one on some chips) or a hang on boot if you misplaced a firmware which is notoriously hard to get hold of.. How do we resolve this except to load the firmware pre-Linux (or put the firmware in the tree, argh) and describe the loaded firmware and offsets? Once it's in the internal SDMA code RAM all the versioning and headers go away.. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] dma: imx-sdma: Add ROM script addresses to driver 2013-08-29 17:23 ` Matt Sealey @ 2013-08-31 8:56 ` Sascha Hauer 0 siblings, 0 replies; 14+ messages in thread From: Sascha Hauer @ 2013-08-31 8:56 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 29, 2013 at 12:23:02PM -0500, Matt Sealey wrote: > On Tue, Aug 20, 2013 at 10:02 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > > > >> What I'd really like to see is the "waiting on a firmware that doesn't > >> exist when there is a working ROM version of those scripts in the SoC" > > > > Then this patch is for you. This is exactly what the patch solves. > > Only by changing the device tree and not specifying a firmware > filename. The driver probes, knows about ROM script addresses as per > your patch, tries to load a new file from disk; same hang. What you > have now is a way to use a potentially buggy script with several > functions missing (ROM script isn't as full-featured as the file-based > one on some chips) or a hang on boot if you misplaced a firmware which > is notoriously hard to get hold of.. > > How do we resolve this except to load the firmware pre-Linux (or put > the firmware in the tree, argh) and describe the loaded firmware and > offsets? Once it's in the internal SDMA code RAM all the versioning > and headers go away.. This seems quite academic. In theory there are many fancy things you can do with the SDMA engine. In practice it is only used for audio. This usecase is covered well by the current code and now even without loading additional firmware. If you have the need for improvements feel free to send patches. Sascha -- 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 [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-08-31 8:56 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-08-19 12:16 [PATCH] dma: imx-sdma: Add ROM script addresses to driver Sascha Hauer 2013-08-19 12:16 ` [PATCH 1/3] dma: imx-sdma: Use struct for driver data Sascha Hauer 2013-08-19 12:16 ` [PATCH 2/3] dma: imx-sdma: Add ROM script addresses to driver Sascha Hauer 2013-08-19 14:41 ` Shawn Guo 2013-08-19 17:39 ` Sascha Hauer 2013-08-20 2:35 ` Shawn Guo 2013-08-20 6:42 ` Sascha Hauer 2013-08-19 12:16 ` [PATCH 3/3] ARM: i.MX: remove sdma script address arrays from platform data Sascha Hauer 2013-08-19 22:23 ` [PATCH] dma: imx-sdma: Add ROM script addresses to driver Matt Sealey 2013-08-20 7:00 ` Sascha Hauer 2013-08-20 13:53 ` Matt Sealey 2013-08-20 15:02 ` Sascha Hauer 2013-08-29 17:23 ` Matt Sealey 2013-08-31 8:56 ` Sascha Hauer
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).