Re: [PATCH v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
On Fri, Feb 01, 2013 at 08:01:41AM +0200, Luciano Coelho wrote: > On Thu, 2013-01-31 at 16:42 -0500, Matt Porter wrote: > > On Thu, Jan 31, 2013 at 08:58:39PM +, Arnd Bergmann wrote: > > > On Thursday 31 January 2013, Matt Porter wrote: > > > > On Wed, Jan 30, 2013 at 09:32:58AM +, Arnd Bergmann wrote: > > > > > On Wednesday 30 January 2013, Matt Porter wrote: > > > > > > + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); > > > > > > + of_dma_controller_register(dev->of_node, > > > > > > + of_dma_simple_xlate, > > > > > > + &edma_filter_info); > > > > > > + } > > > > > > > > > > How do you actually deal with the problem mentioned by Padma, that > > > > > the filter function does not know which edma instance it is looking > > > > > at? If you assume that there can only be a single edma instance in > > > > > the system, that is probably a limitation that should be documented > > > > > somewhere, and ideally the probe() function should check for that. > > > > > > > > I make an assumption of one edma instance in the system in the case of > > > > DT being populated. This is always true right now as the only SoC with > > > > two EDMA controllers in existence is Davinci DA850. Until recently, > > > > Davinci had no DT support. Given the steady work being done today on DT > > > > support for DA850, it'll probably be something needed in 3.10. > > > > > > > > I will add a comment and check in probe() to capture this assumption > > > > and then plan to update separately to support DA850 booting from DT. > > > > > > Ok, sounds good. Hopefully by then we will already have a nicer > > > way to write an xlate function that does not rely on a filter > > > function. > > > > Yes, it would be nice to avoid what Padma had to do. I should have > > mentioned also that the second EDMA on DA850 has no DMA events of > > immediate use on it anyway. All the in-kernel users use events on the > > first controller, except for the second MMC instance. That's only used > > for a wl12xx module on the EVM and that driver has no DT support so it > > doesn't matter yet in the DT case. Because of this, DA850 can actually > > add EDMA DT support immediately (on top of this series) and add DMA > > support to the DT support already posted for the Davinci SPI and MMC > > client drivers. > > I haven't followed this whole discussion in details, but please notice > that I'm aiming to get DT support for the WiLink modules (wlcore, > wl12xx...) for 3.10. ;) Great, looks like we'll all be synced then. ;) -Matt ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 2/4] davinci: cpuidle - move code to prevent forward declaration
The patch is mindless, it just moves the idle function below in the file
in order to prevent forward declaration in the next patch.
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-davinci/cpuidle.c | 72 +++
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index ebb8808..9438672 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -31,42 +31,6 @@ struct davinci_ops {
u32 flags;
};
-/* Actual code that puts the SoC in different idle states */
-static int davinci_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
-{
- struct cpuidle_state_usage *state_usage = &dev->states_usage[index];
- struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
-
- if (ops && ops->enter)
- ops->enter();
-
- index = cpuidle_wrap_enter(dev, drv, index,
- arm_cpuidle_simple_enter);
-
- if (ops && ops->exit)
- ops->exit();
-
- return index;
-}
-
-static struct cpuidle_driver davinci_idle_driver = {
- .name = "cpuidle-davinci",
- .owner = THIS_MODULE,
- .en_core_tk_irqen = 1,
- .states[0] = ARM_CPUIDLE_WFI_STATE,
- .states[1] = {
- .enter = davinci_enter_idle,
- .exit_latency = 10,
- .target_residency = 10,
- .flags = CPUIDLE_FLAG_TIME_VALID,
- .name = "DDR SR",
- .desc = "WFI and DDR Self Refresh",
- },
- .state_count = DAVINCI_CPUIDLE_MAX_STATES,
-};
-
static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device);
static void __iomem *ddr2_reg_base;
static bool ddr2_pdown = false;
@@ -107,6 +71,42 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
},
};
+/* Actual code that puts the SoC in different idle states */
+static int davinci_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct cpuidle_state_usage *state_usage = &dev->states_usage[index];
+ struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
+
+ if (ops && ops->enter)
+ ops->enter();
+
+ index = cpuidle_wrap_enter(dev, drv, index,
+ arm_cpuidle_simple_enter);
+
+ if (ops && ops->exit)
+ ops->exit();
+
+ return index;
+}
+
+static struct cpuidle_driver davinci_idle_driver = {
+ .name = "cpuidle-davinci",
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
+ .states[0] = ARM_CPUIDLE_WFI_STATE,
+ .states[1] = {
+ .enter = davinci_enter_idle,
+ .exit_latency = 10,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = "DDR SR",
+ .desc = "WFI and DDR Self Refresh",
+ },
+ .state_count = DAVINCI_CPUIDLE_MAX_STATES,
+};
+
static int __init davinci_cpuidle_probe(struct platform_device *pdev)
{
int ret;
--
1.7.9.5
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 4/4] davinci: cpuidle - remove useless initialization
The device->state_count is initialized in the cpuidle_register_device
function.
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-davinci/cpuidle.c |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index 28cc8e8..144839b 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -96,8 +96,6 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
ddr2_pdown = pdata->ddr2_pdown;
- device->state_count = DAVINCI_CPUIDLE_MAX_STATES;
-
ret = cpuidle_register_driver(&davinci_idle_driver);
if (ret) {
dev_err(&pdev->dev, "failed to register driver\n");
--
1.7.9.5
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/4] davinci: cpuidle - use global variable for ddr2 flag
Replace the flag by a simple global boolean in the cpuidle.c.
That will allow to cleanup the rest of the code right after,
because the ops won't make sense anymore.
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-davinci/cpuidle.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index 9107691..ebb8808 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -26,8 +26,8 @@
#define DAVINCI_CPUIDLE_MAX_STATES 2
struct davinci_ops {
- void (*enter) (u32 flags);
- void (*exit) (u32 flags);
+ void (*enter) (void);
+ void (*exit) (void);
u32 flags;
};
@@ -40,20 +40,17 @@ static int davinci_enter_idle(struct cpuidle_device *dev,
struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
if (ops && ops->enter)
- ops->enter(ops->flags);
+ ops->enter();
index = cpuidle_wrap_enter(dev, drv, index,
arm_cpuidle_simple_enter);
if (ops && ops->exit)
- ops->exit(ops->flags);
+ ops->exit();
return index;
}
-/* fields in davinci_ops.flags */
-#define DAVINCI_CPUIDLE_FLAGS_DDR2_PWDNBIT(0)
-
static struct cpuidle_driver davinci_idle_driver = {
.name = "cpuidle-davinci",
.owner = THIS_MODULE,
@@ -72,6 +69,7 @@ static struct cpuidle_driver davinci_idle_driver = {
static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device);
static void __iomem *ddr2_reg_base;
+static bool ddr2_pdown = false;
static void davinci_save_ddr_power(int enter, bool pdown)
{
@@ -92,14 +90,14 @@ static void davinci_save_ddr_power(int enter, bool pdown)
__raw_writel(val, ddr2_reg_base + DDR2_SDRCR_OFFSET);
}
-static void davinci_c2state_enter(u32 flags)
+static void davinci_c2state_enter(void)
{
- davinci_save_ddr_power(1, !!(flags & DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN));
+ davinci_save_ddr_power(1, ddr2_pdown);
}
-static void davinci_c2state_exit(u32 flags)
+static void davinci_c2state_exit(void)
{
- davinci_save_ddr_power(0, !!(flags & DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN));
+ davinci_save_ddr_power(0, ddr2_pdown);
}
static struct davinci_ops davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
@@ -124,8 +122,7 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
ddr2_reg_base = pdata->ddr2_ctlr_base;
- if (pdata->ddr2_pdown)
- davinci_states[1].flags |= DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN;
+ ddr2_pdown = pdata->ddr2_pdown;
cpuidle_set_statedata(&device->states_usage[1], &davinci_states[1]);
device->state_count = DAVINCI_CPUIDLE_MAX_STATES;
--
1.7.9.5
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 0/4] davinci: cpuidle - some cleanups
This patchset does some cleanup. It could have been folded in a single patch but the review would have been less clean than splitting it into small and trivial patches. The main purpose of this patch is to remove the usage of the driver_data field from the state_usage structure. Len Brown is doing this cleanup in the intel_idle.c file. With this patchset, the processor_idle.c file will be the last user of this field. Also, the patchset simplify the code and makes it a bit more clear to read. I don't have this hardware, the code is not tested. Daniel Lezcano (4): davinci: cpuidle - use global variable for ddr2 flag davinci: cpuidle - move code to prevent forward declaration davinci: cpuidle - remove the ops davinci: cpuidle - remove useless initialization arch/arm/mach-davinci/cpuidle.c | 84 --- 1 file changed, 25 insertions(+), 59 deletions(-) -- 1.7.9.5 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 3/4] davinci: cpuidle - remove the ops
With one function handling the idle state and a single variable,
the usage of the davinci_ops is overkill.
This patch removes these ops and simplify the code.
Furthermore, the 'driver_data' field is no longer used, we have
1 of the 3 remaining user of this field removed.
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-davinci/cpuidle.c | 33 ++---
1 file changed, 2 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index 9438672..28cc8e8 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -25,12 +25,6 @@
#define DAVINCI_CPUIDLE_MAX_STATES 2
-struct davinci_ops {
- void (*enter) (void);
- void (*exit) (void);
- u32 flags;
-};
-
static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device);
static void __iomem *ddr2_reg_base;
static bool ddr2_pdown = false;
@@ -54,39 +48,17 @@ static void davinci_save_ddr_power(int enter, bool pdown)
__raw_writel(val, ddr2_reg_base + DDR2_SDRCR_OFFSET);
}
-static void davinci_c2state_enter(void)
-{
- davinci_save_ddr_power(1, ddr2_pdown);
-}
-
-static void davinci_c2state_exit(void)
-{
- davinci_save_ddr_power(0, ddr2_pdown);
-}
-
-static struct davinci_ops davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
- [1] = {
- .enter = davinci_c2state_enter,
- .exit = davinci_c2state_exit,
- },
-};
-
/* Actual code that puts the SoC in different idle states */
static int davinci_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct cpuidle_state_usage *state_usage = &dev->states_usage[index];
- struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
-
- if (ops && ops->enter)
- ops->enter();
+ davinci_save_ddr_power(1, ddr2_pdown);
index = cpuidle_wrap_enter(dev, drv, index,
arm_cpuidle_simple_enter);
- if (ops && ops->exit)
- ops->exit();
+ davinci_save_ddr_power(0, ddr2_pdown);
return index;
}
@@ -123,7 +95,6 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
ddr2_reg_base = pdata->ddr2_ctlr_base;
ddr2_pdown = pdata->ddr2_pdown;
- cpuidle_set_statedata(&device->states_usage[1], &davinci_states[1]);
device->state_count = DAVINCI_CPUIDLE_MAX_STATES;
--
1.7.9.5
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 1/6] pinctrl: pinctrl-single: use arch_initcall and module_exit
* Linus Walleij [130129 03:03]: > On Tue, Jan 29, 2013 at 8:38 AM, Vishwanathrao Badarkhe, Manish > wrote: > > > Currently, I2C driver gets probed before pinctrl driver. > > To achieve I2C pin muxing via pinctrl driver before I2C > > probe get called, register pinctrl driver in arch_initcall. > > Also, add module_exit to unregister pinctrl driver. > > > > Signed-off-by: Vishwanathrao Badarkhe, Manish > > So your I2C driver is not returning -EPROBE_DEFER > if it cannot find its pins? > > Hm, well I can live with this, if Tony ACKs it. Hmm pinctrl is before i2c in drivers/Makefile. Making initcalls happen earlier and earlier is usually the wrong way to go. Sounds like there's some other issue here that needs to be fixed instead. Regards, Tony ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 1/6] pinctrl: pinctrl-single: use arch_initcall and module_exit
* Tony Lindgren [130201 09:12]: > * Linus Walleij [130129 03:03]: > > On Tue, Jan 29, 2013 at 8:38 AM, Vishwanathrao Badarkhe, Manish > > wrote: > > > > > Currently, I2C driver gets probed before pinctrl driver. > > > To achieve I2C pin muxing via pinctrl driver before I2C > > > probe get called, register pinctrl driver in arch_initcall. > > > Also, add module_exit to unregister pinctrl driver. > > > > > > Signed-off-by: Vishwanathrao Badarkhe, Manish > > > > So your I2C driver is not returning -EPROBE_DEFER > > if it cannot find its pins? > > > > Hm, well I can live with this, if Tony ACKs it. > > Hmm pinctrl is before i2c in drivers/Makefile. > Making initcalls happen earlier and earlier is usually the > wrong way to go. Sounds like there's some other issue here > that needs to be fixed instead. Let me guess: The i2c driver is wrongly set to run with arch_initcall? > Regards, > > Tony > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v7 04/10] dmaengine: edma: enable build for AM33XX
Enable TI EDMA option on OMAP. Signed-off-by: Matt Porter --- drivers/dma/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 0b408bb..239020b 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -220,7 +220,7 @@ config SIRF_DMA config TI_EDMA tristate "TI EDMA support" - depends on ARCH_DAVINCI + depends on ARCH_DAVINCI || ARCH_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS default n -- 1.7.9.5 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v7 00/10] DMA Engine support for AM33XX
Changes since v6:
- Converted edma_of_read_*() to wrappers around of_property_read_*()
- Fixed wording on the omap-spi generic DMA properties
- Added comment/check to clarify that the driver only supports
a single EDMA instance when booting from DT
Changes since v5:
- Dropped mmc portion and moved it to a separate series
- Incorporate corrected version of dma_request_slave_channel_compat()
- Fix #defines and enablement of TI_PRIV_EDMA option
Changes since v4:
- Fixed debug section mismatch in private edma api [01/14]
- Respun format-patch to catch the platform_data/edma.h rename [01/14]
- Removed address/size-cells from the EDMA binding [05/14]
Changes since v3:
- Rebased on 3.8-rc3
- No longer an RFC
- Fixed bugs in DT/pdata parsing reported by Vaibhav Bedia
- Restored all the Davinci pdata to const
- Removed max_segs hack in favor of using dma_get_channel_caps()
- Fixed extra parens, __raw_* accessors and, ioremap error checks
in xbar handling
- Removed excess license info in platform_data/edma.h
- Removed unneeded reserved channels data for AM33xx
- Removed test-specific pinmuxing from dts files
- Adjusted mmc1 node to be disabled by default in the dtsi
Changes since v2:
- Rebased on 3.7-rc1
- Fixed bug in DT/pdata parsing first found by Gururaja
that turned out to be masked by some toolchains
- Dropped unused mach-omap2/devices.c hsmmc patch
- Added AM33XX crossbar DMA event mux support
- Added am335x-evm support
Changes since v1:
- Rebased on top of mainline from 12250d8
- Dropped the feature removal schedule patch
- Implemented dma_request_slave_channel_compat() and
converted the mmc and spi drivers to use it
- Dropped unneeded #address-cells and #size-cells from
EDMA DT support
- Moved private EDMA header to linux/platform_data/ and
removed some unneeded definitions
- Fixed parsing of optional properties
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.
The series applies on top of 3.8-rc5 and the following patches:
- dmaengine DT support and edma dmaengine driver fix from
the git://git.infradead.org/users/vkoul/slave-dma.git next
branch
The approach taken is similar to how OMAP DMA is being converted to
DMA Engine support. With the functional EDMA private API already
existing in mach-davinci/dma.c, we first move that to an ARM common
area so it can be shared. Adding DT and runtime PM support to the
private EDMA API implementation allows it to run on AM33xx. AM33xx
*only* boots using DT so we leverage Jon's generic DT DMA helpers to
register EDMA DMAC with the of_dma framework and then add support
for calling the dma_request_slave_channel() API to both the mmc
and spi drivers.
With this series both BeagleBone and the AM335x EVM have working
SPI DMA support (and MMC support with the separate MMC series).
This is tested on BeagleBone with a SPI framebuffer driver and MMC
rootfs. A trivial gpio DMA event misc driver was used to test the
crossbar DMA event support. It is also tested on the AM335x EVM
with the onboard SPI flash and MMC rootfs. The branch at
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v7
has the complete series, dependencies, and some test
drivers/defconfigs. Note that MMC can only be tested with a
separate MMC dmaengine/DT series applied.
Regression testing was done on AM180x-EVM (which also makes use
of the EDMA dmaengine driver and the EDMA private API) using SD,
SPI flash, and the onboard audio supported by the ASoC Davinci
driver. Regression testing was also done on a BeagleBoard xM
booting from the legacy board file using MMC rootfs.
Matt Porter (10):
ARM: davinci: move private EDMA API to arm/common
ARM: edma: remove unused transfer controller handlers
ARM: edma: add AM33XX support to the private EDMA API
dmaengine: edma: enable build for AM33XX
dmaengine: edma: Add TI EDMA device tree binding
ARM: dts: add AM33XX EDMA support
dmaengine: add dma_request_slave_channel_compat()
spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
spi: omap2-mcspi: add generic DMA request support to the DT binding
ARM: dts: add AM33XX SPI DMA support
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +++
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +-
arch/arm/Kconfig |1 +
arch/arm/boot/dts/am33xx.dtsi | 30 ++
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-davinci/dm
[PATCH v7 02/10] ARM: edma: remove unused transfer controller handlers
Fix build on OMAP, the irqs are undefined on AM33xx.
These error interrupt handlers were hardcoded as disabled
so since they are unused code, simply remove them.
Signed-off-by: Matt Porter
Acked-by: Sekhar Nori
---
arch/arm/common/edma.c | 37 -
1 file changed, 37 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index aa4a49a..3440d16 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -494,26 +494,6 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
return IRQ_HANDLED;
}
-/**
- *
- * Transfer controller error interrupt handlers
- *
- */
-
-#define tc_errs_handledfalse /* disabled as long as they're NOPs */
-
-static irqreturn_t dma_tc0err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc0err_handler\n");
- return IRQ_HANDLED;
-}
-
-static irqreturn_t dma_tc1err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc1err_handler\n");
- return IRQ_HANDLED;
-}
-
static int reserve_contiguous_slots(int ctlr, unsigned int id,
unsigned int num_slots,
unsigned int start_slot)
@@ -1743,23 +1723,6 @@ static int edma_probe(struct platform_device *pdev)
arch_num_cc++;
}
- if (tc_errs_handled) {
- status = request_irq(IRQ_TCERRINT0, dma_tc0err_handler, 0,
- "edma_tc0", &pdev->dev);
- if (status < 0) {
- dev_dbg(&pdev->dev, "request_irq %d failed --> %d\n",
- IRQ_TCERRINT0, status);
- return status;
- }
- status = request_irq(IRQ_TCERRINT, dma_tc1err_handler, 0,
- "edma_tc1", &pdev->dev);
- if (status < 0) {
- dev_dbg(&pdev->dev, "request_irq %d --> %d\n",
- IRQ_TCERRINT, status);
- return status;
- }
- }
-
return 0;
fail:
--
1.7.9.5
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v7 08/10] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter
Acked-by: Mark Brown
---
drivers/spi/spi-omap2-mcspi.c | 65 -
1 file changed, 45 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b610f52..2c02c02 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -102,6 +102,9 @@ struct omap2_mcspi_dma {
struct completion dma_tx_completion;
struct completion dma_rx_completion;
+
+ char dma_rx_ch_name[14];
+ char dma_tx_ch_name[14];
};
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -822,14 +825,23 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma->dma_rx_sync_dev;
- mcspi_dma->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+
+ mcspi_dma->dma_rx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_rx_ch_name);
+
if (!mcspi_dma->dma_rx) {
dev_err(&spi->dev, "no RX DMA engine channel for McSPI\n");
return -EAGAIN;
}
sig = mcspi_dma->dma_tx_sync_dev;
- mcspi_dma->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+ mcspi_dma->dma_tx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_tx_ch_name);
+
if (!mcspi_dma->dma_tx) {
dev_err(&spi->dev, "no TX DMA engine channel for McSPI\n");
dma_release_channel(mcspi_dma->dma_rx);
@@ -1223,29 +1235,42 @@ static int omap2_mcspi_probe(struct platform_device
*pdev)
goto free_master;
for (i = 0; i < master->num_chipselect; i++) {
- char dma_ch_name[14];
+ char *dma_rx_ch_name = mcspi->dma_channels[i].dma_rx_ch_name;
+ char *dma_tx_ch_name = mcspi->dma_channels[i].dma_tx_ch_name;
struct resource *dma_res;
- sprintf(dma_ch_name, "rx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA RX channel\n");
- status = -ENODEV;
- break;
- }
+ sprintf(dma_rx_ch_name, "rx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_rx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA RX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_rx_sync_dev = dma_res->start;
- sprintf(dma_ch_name, "tx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA TX channel\n");
- status = -ENODEV;
- break;
+ mcspi->dma_channels[i].dma_rx_sync_dev =
+ dma_res->start;
}
+ sprintf(dma_tx_ch_name, "tx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_tx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA TX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_tx_sync_dev = dma_res->start;
+ mcspi->dma_channels[i].dma_tx_sync_dev =
+
[PATCH v7 05/10] dmaengine: edma: Add TI EDMA device tree binding
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..075a60e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,49 @@
+TI EDMA
+
+Required properties:
+- compatible : "ti,edma3"
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- ti,edma-queue-tc-map: List of transfer control to queue mappings
+- ti,edma-queue-priority-map: List of queue priority mappings
+- ti,edma-default-queue: Default queue value
+
+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@4900 {
+ reg = <0x4900 0x1>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-reserved-channels = <0 2
+14 2
+26 6
+48 4
+56 8>;
+ ti,edma-reserved-slots = <0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8
+ 64 127>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ ti,edma-xbar-event-map = <1 12
+ 2 13>;
+};
--
1.7.9.5
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v7 06/10] ARM: dts: add AM33XX EDMA support
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am33xx.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..e711ffb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -87,6 +87,26 @@
reg = <0x4820 0x1000>;
};
+ edma: edma@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ };
+
gpio1: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
1.7.9.5
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v7 07/10] dmaengine: add dma_request_slave_channel_compat()
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Suggested-by: Tony Lindgren
Signed-off-by: Matt Porter
Acked-by: Tony Lindgren
Acked-by: Arnd Bergmann
---
include/linux/dmaengine.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index bfcdecb..17d8ffd 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1001,6 +1001,22 @@ void dma_run_dependencies(struct dma_async_tx_descriptor
*tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
+#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
+ __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
+
+static inline struct dma_chan
+*__dma_request_slave_channel_compat(dma_cap_mask_t *mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ struct dma_chan *chan;
+
+ chan = dma_request_slave_channel(dev, name);
+ if (chan)
+ return chan;
+
+ return __dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
1.7.9.5
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
Signed-off-by: Matt Porter
Acked-by: Sekhar Nori
---
arch/arm/Kconfig |1 +
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-davinci/dma.c => common/edma.c} | 209 +++-
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
arch/arm/mach-davinci/davinci.h|2 +-
arch/arm/mach-davinci/devices-tnetv107x.c |2 +-
arch/arm/mach-davinci/devices.c|6 +-
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
drivers/dma/edma.c |2 +-
drivers/mmc/host/davinci_mmc.c |1 +
include/linux/mfd/davinci_voicecodec.h |3 +-
.../mach => include/linux/platform_data}/edma.h| 89 +
include/linux/platform_data/spi-davinci.h |2 +-
sound/soc/davinci/davinci-evm.c|1 +
sound/soc/davinci/davinci-pcm.c|1 +
sound/soc/davinci/davinci-pcm.h|2 +-
sound/soc/davinci/davinci-sffsdr.c |7 +-
23 files changed, 240 insertions(+), 106 deletions(-)
rename arch/arm/{mach-davinci/dma.c => common/edma.c} (90%)
rename {arch/arm/mach-davinci/include/mach =>
include/linux/platform_data}/edma.h (59%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..7637d31 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -932,6 +932,7 @@ config ARCH_DAVINCI
select GENERIC_IRQ_CHIP
select HAVE_IDE
select NEED_MACH_GPIO_H
+ select TI_PRIV_EDMA
select USE_OF
select ZONE_DMA
help
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 45ceeb0..9e32d0d 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -40,3 +40,6 @@ config SHARP_PARAM
config SHARP_SCOOP
bool
+
+config TI_PRIV_EDMA
+ bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..d09a39b 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP) += scoop.o
obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o
+obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c
similarity index 90%
rename from arch/arm/mach-davinci/dma.c
rename to arch/arm/common/edma.c
index a685e97..aa4a49a 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include
#include
-#include
+#include
/* Offsets matching "struct edmacc_param" */
#define PARM_OPT 0x00
@@ -1386,8 +1386,213 @@ void edma_clear_event(unsigned channel)
EXPORT_SYMBOL(edma_clear_event);
/*---*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+const char *propname, s8 *out_values,
+size_t sz)
+{
+ int ret;
+
+ ret = of_property_read_u8_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+const char *propname, s16 *out_values,
+size_t sz)
+{
+ int ret;
+
+ ret = of_property_read_u16_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_xbar_event_map(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata, int len)
+{
+ int ret = 0;
+ int i;
+ struct resource res;
+ void *xbar;
+ const s16 (*xbar_chans)[2];
+ u32 shift, offset, mux;
+
+ xbar_chans = devm_kzalloc(dev,
+ len/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!xbar_chans)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(node, 1, &res);
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ xbar = devm_ioremap(dev, res.start, res
[PATCH v7 10/10] ARM: dts: add AM33XX SPI DMA support
Adds DMA resources to the AM33XX SPI nodes. Signed-off-by: Matt Porter --- arch/arm/boot/dts/am33xx.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index e711ffb..ddf702a 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -328,6 +328,11 @@ interrupt = <65>; ti,spi-num-cs = <2>; ti,hwmods = "spi0"; + dmas = <&edma 16 + &edma 17 + &edma 18 + &edma 19>; + dma-names = "tx0", "rx0", "tx1", "rx1"; status = "disabled"; }; @@ -339,6 +344,11 @@ interrupt = <125>; ti,spi-num-cs = <2>; ti,hwmods = "spi1"; + dmas = <&edma 42 + &edma 43 + &edma 44 + &edma 45>; + dma-names = "tx0", "rx0", "tx1", "rx1"; status = "disabled"; }; -- 1.7.9.5 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v7 09/10] spi: omap2-mcspi: add generic DMA request support to the DT binding
The binding definition is based on the generic DMA request binding
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..4c85c4c 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@ Required properties:
input. The default is D0 as input and
D1 as output.
-Example:
+Optional properties:
+- dmas: List of DMA specifiers with the controller specific format
+ as described in the generic DMA client binding. A tx and rx
+ specifier is required for each chip select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the DMA specifiers listed in dmas. The string naming
+ is to be "rxN" and "txN" for RX and TX requests,
+ respectively, where N equals the chip select number.
+
+Examples:
+
+[hwmod populated DMA resources]
mcspi1: mcspi@1 {
#address-cells = <1>;
@@ -20,3 +31,17 @@ mcspi1: mcspi@1 {
ti,spi-num-cs = <4>;
};
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "ti,omap4-mcspi";
+ti,hwmods = "mcspi1";
+ti,spi-num-cs = <2>;
+dmas = <&edma 42
+ &edma 43
+ &edma 44
+ &edma 45>;
+dma-names = "tx0", "rx0", "tx1", "rx1";
+};
--
1.7.9.5
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v7 03/10] ARM: edma: add AM33XX support to the private EDMA API
Adds support for parsing the TI EDMA DT data into the
required EDMA private API platform data. Enables runtime
PM support to initialize the EDMA hwmod. Adds AM33XX EDMA
crossbar event mux support. Enables build on OMAP.
Signed-off-by: Matt Porter
Acked-by: Sekhar Nori
---
arch/arm/common/edma.c | 96
arch/arm/plat-omap/Kconfig |1 +
include/linux/platform_data/edma.h |1 +
3 files changed, 89 insertions(+), 9 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 3440d16..bd2416a 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
@@ -723,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
*/
int edma_alloc_slot(unsigned ctlr, int slot)
{
+ if (!edma_cc[ctlr])
+ return -EINVAL;
+
if (slot >= 0)
slot = EDMA_CHAN_SLOT(slot);
@@ -1575,27 +1585,69 @@ static struct of_dma_filter_info edma_filter_info = {
static int edma_probe(struct platform_device *pdev)
{
struct edma_soc_info**info = pdev->dev.platform_data;
+ struct edma_soc_info*ninfo[EDMA_MAX_CC] = {NULL, NULL};
+ struct edma_soc_infotmpinfo;
const s8(*queue_priority_mapping)[2];
const s8(*queue_tc_mapping)[2];
int i, j, off, ln, found = 0;
int status = -1;
const s16 (*rsv_chans)[2];
const s16 (*rsv_slots)[2];
+ const s16 (*xbar_chans)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
- struct resource *r[EDMA_MAX_CC] = {NULL};
+ struct resource *r[EDMA_MAX_CC] = {NULL, NULL};
+ struct resource res[EDMA_MAX_CC];
resource_size_t len[EDMA_MAX_CC];
charres_name[10];
charirq_name[10];
+ struct device_node *node = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ int ret;
+
+ if (node) {
+ /* Check if this is a second instance registered */
+ if (arch_num_cc) {
+ dev_err(dev, "only one EDMA instance is supported via
DT\n");
+ return -ENODEV;
+ }
+ info = ninfo;
+ edma_of_parse_dt(dev, node, &tmpinfo);
+ info[0] = &tmpinfo;
+
+ dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
+ of_dma_controller_register(dev->of_node,
+ of_dma_simple_xlate,
+ &edma_filter_info);
+ }
if (!info)
return -ENODEV;
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(dev, "pm_runtime_get_sync() failed\n");
+ return ret;
+ }
+
for (j = 0; j < EDMA_MAX_CC; j++) {
- sprintf(res_name, "edma_cc%d", j);
- r[j] = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ if (!info[j]) {
+ if (!found)
+ return -ENODEV;
+ break;
+ }
+ if (node) {
+ ret = of_address_to_resource(node, j, &res[j]);
+ if (!IS_ERR_VALUE(ret))
+ r[j] = &res[j];
+ } else {
+ sprintf(res_name, "edma_cc%d", j);
+ r[j] = platform_get_resource_byname(pdev,
+ IORESOURCE_MEM,
res_name);
- if (!r[j] || !info[j]) {
+ }
+ if (!r[j]) {
if (found)
break;
else
@@ -1670,8 +1722,22 @@ static int edma_probe(struct platform_device *pdev)
}
}
- sprintf(irq_name, "edma%d", j);
- irq[j] = platform_get_irq_byname(pdev, irq_name);
+ /* Clear the xbar mapped channels in unused list */
+ xbar_chans = info[j]->xbar_chans;
+ if (xbar_chans) {
+ for (i = 0; xbar_chans[i][1] != -1; i++) {
+ off = xbar_chans[i][1];
+ clear_bits(off, 1,
+ edma_cc[j]->edma_unused);
+ }
+ }
+
+ if (node)
+ irq[j] = irq_of_parse_and_map(node, 0);
+ else {
+
Re: [PATCH v7 05/10] dmaengine: edma: Add TI EDMA device tree binding
On Fri, Feb 01, 2013 at 01:22:50PM -0500, Matt Porter wrote:
> The binding definition is based on the generic DMA controller
> binding.
>
> Signed-off-by: Matt Porter
Grant or Rob, can I get an ack on this binding and others in this
series?
> ---
> Documentation/devicetree/bindings/dma/ti-edma.txt | 49
> +
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
> b/Documentation/devicetree/bindings/dma/ti-edma.txt
> new file mode 100644
> index 000..075a60e3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> @@ -0,0 +1,49 @@
> +TI EDMA
> +
> +Required properties:
> +- compatible : "ti,edma3"
> +- ti,hwmods: Name of the hwmods associated to the EDMA
> +- ti,edma-regions: Number of regions
> +- ti,edma-slots: Number of slots
> +- ti,edma-queue-tc-map: List of transfer control to queue mappings
> +- ti,edma-queue-priority-map: List of queue priority mappings
> +- ti,edma-default-queue: Default queue value
> +
> +Optional properties:
> +- ti,edma-reserved-channels: List of reserved channel regions
> +- ti,edma-reserved-slots: List of reserved slot regions
> +- ti,edma-xbar-event-map: Crossbar event to channel map
> +
> +Example:
> +
> +edma: edma@4900 {
> + reg = <0x4900 0x1>;
> + interrupt-parent = <&intc>;
> + interrupts = <12 13 14>;
> + compatible = "ti,edma3";
> + ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> + #dma-cells = <1>;
> + dma-channels = <64>;
> + ti,edma-regions = <4>;
> + ti,edma-slots = <256>;
> + ti,edma-reserved-channels = <0 2
> + 14 2
> + 26 6
> + 48 4
> + 56 8>;
> + ti,edma-reserved-slots = <0 2
> + 14 2
> + 26 6
> + 48 4
> + 56 8
> + 64 127>;
> + ti,edma-queue-tc-map = <0 0
> + 1 1
> + 2 2>;
> + ti,edma-queue-priority-map = <0 0
> + 1 1
> + 2 2>;
> + ti,edma-default-queue = <0>;
> + ti,edma-xbar-event-map = <1 12
> + 2 13>;
> +};
> --
> 1.7.9.5
>
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 07/10] dmaengine: add dma_request_slave_channel_compat()
On Fri, Feb 01, 2013 at 01:22:52PM -0500, Matt Porter wrote:
> Adds a dma_request_slave_channel_compat() wrapper which accepts
> both the arguments from dma_request_channel() and
> dma_request_slave_channel(). Based on whether the driver is
> instantiated via DT, the appropriate channel request call will be
> made.
>
> This allows for a much cleaner migration of drivers to the
> dmaengine DT API as platforms continue to be mixed between those
> that boot using DT and those that do not.
>
> Suggested-by: Tony Lindgren
> Signed-off-by: Matt Porter
> Acked-by: Tony Lindgren
> Acked-by: Arnd Bergmann
Vinod, can I get an ack on this one?
-Matt
> ---
> include/linux/dmaengine.h | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index bfcdecb..17d8ffd 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -1001,6 +1001,22 @@ void dma_run_dependencies(struct
> dma_async_tx_descriptor *tx);
> struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
> struct dma_chan *net_dma_find_channel(void);
> #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
> +#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
> + __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
> +
> +static inline struct dma_chan
> +*__dma_request_slave_channel_compat(dma_cap_mask_t *mask, dma_filter_fn fn,
> + void *fn_param, struct device *dev,
> + char *name)
> +{
> + struct dma_chan *chan;
> +
> + chan = dma_request_slave_channel(dev, name);
> + if (chan)
> + return chan;
> +
> + return __dma_request_channel(mask, fn, fn_param);
> +}
>
> /* --- Helper iov-locking functions --- */
>
> --
> 1.7.9.5
>
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 00/10] DMA Engine support for AM33XX
On Fri, Feb 01, 2013 at 01:22:45PM -0500, Matt Porter wrote:
> This series adds DMA Engine support for AM33xx, which uses
> an EDMA DMAC. The EDMA DMAC has been previously supported by only
> a private API implementation (much like the situation with OMAP
> DMA) found on the DaVinci family of SoCs.
Tony,
Will you be able to take this series in through your tree? It appears we
just need acks on the new bindings and the compat api change. I haven't
heard from you or Benoit on the dts patches so it seems those are ready
as well.
Thanks,
Matt
>
> The series applies on top of 3.8-rc5 and the following patches:
>
> - dmaengine DT support and edma dmaengine driver fix from
> the git://git.infradead.org/users/vkoul/slave-dma.git next
> branch
>
> The approach taken is similar to how OMAP DMA is being converted to
> DMA Engine support. With the functional EDMA private API already
> existing in mach-davinci/dma.c, we first move that to an ARM common
> area so it can be shared. Adding DT and runtime PM support to the
> private EDMA API implementation allows it to run on AM33xx. AM33xx
> *only* boots using DT so we leverage Jon's generic DT DMA helpers to
> register EDMA DMAC with the of_dma framework and then add support
> for calling the dma_request_slave_channel() API to both the mmc
> and spi drivers.
>
> With this series both BeagleBone and the AM335x EVM have working
> SPI DMA support (and MMC support with the separate MMC series).
>
> This is tested on BeagleBone with a SPI framebuffer driver and MMC
> rootfs. A trivial gpio DMA event misc driver was used to test the
> crossbar DMA event support. It is also tested on the AM335x EVM
> with the onboard SPI flash and MMC rootfs. The branch at
> https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v7
> has the complete series, dependencies, and some test
> drivers/defconfigs. Note that MMC can only be tested with a
> separate MMC dmaengine/DT series applied.
>
> Regression testing was done on AM180x-EVM (which also makes use
> of the EDMA dmaengine driver and the EDMA private API) using SD,
> SPI flash, and the onboard audio supported by the ASoC Davinci
> driver. Regression testing was also done on a BeagleBoard xM
> booting from the legacy board file using MMC rootfs.
>
>
> Matt Porter (10):
> ARM: davinci: move private EDMA API to arm/common
> ARM: edma: remove unused transfer controller handlers
> ARM: edma: add AM33XX support to the private EDMA API
> dmaengine: edma: enable build for AM33XX
> dmaengine: edma: Add TI EDMA device tree binding
> ARM: dts: add AM33XX EDMA support
> dmaengine: add dma_request_slave_channel_compat()
> spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
> spi: omap2-mcspi: add generic DMA request support to the DT binding
> ARM: dts: add AM33XX SPI DMA support
>
> Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +++
> Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +-
> arch/arm/Kconfig |1 +
> arch/arm/boot/dts/am33xx.dtsi | 30 ++
> arch/arm/common/Kconfig|3 +
> arch/arm/common/Makefile |1 +
> arch/arm/{mach-davinci/dma.c => common/edma.c} | 342
> +---
> arch/arm/mach-davinci/Makefile |2 +-
> arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
> arch/arm/mach-davinci/davinci.h|2 +-
> arch/arm/mach-davinci/devices-tnetv107x.c |2 +-
> arch/arm/mach-davinci/devices.c|6 +-
> arch/arm/mach-davinci/dm355.c |2 +-
> arch/arm/mach-davinci/dm365.c |2 +-
> arch/arm/mach-davinci/dm644x.c |2 +-
> arch/arm/mach-davinci/dm646x.c |2 +-
> arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
> arch/arm/plat-omap/Kconfig |1 +
> drivers/dma/Kconfig|2 +-
> drivers/dma/edma.c |2 +-
> drivers/mmc/host/davinci_mmc.c |1 +
> drivers/spi/spi-omap2-mcspi.c | 65 ++--
> include/linux/dmaengine.h | 16 +
> include/linux/mfd/davinci_voicecodec.h |3 +-
> .../mach => include/linux/platform_data}/edma.h| 90 +-
> include/linux/platform_data/spi-davinci.h |2 +-
> sound/soc/davinci/davinci-evm.c|1 +
> sound/soc/davinci/davinci-pcm.c|1 +
> sound/soc/davinci/davinci-pcm.h|2 +-
> sound/soc/davinci/davinci-sffsdr.c |7 +-
> 30 files changed, 496 insertions(+), 174 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
> rename arch/arm/{mach-davinci/dma.c => common/edma.c} (86%)
>
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
* Matt Porter [130201 10:25]: > Move mach-davinci/dma.c to common/edma.c so it can be used > by OMAP (specifically AM33xx) as well. I think this should rather go to drivers/dma/? Tony ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Fri, Feb 01, 2013 at 06:41:08PM +, Tony Lindgren wrote: > * Matt Porter [130201 10:25]: > > Move mach-davinci/dma.c to common/edma.c so it can be used > > by OMAP (specifically AM33xx) as well. > > I think this should rather go to drivers/dma/? No, this is the private EDMA API. It's the analogous thing to the private OMAP dma API that is in plat-omap/dma.c. The actual dmaengine driver is in drivers/dma/edma.c as a wrapper around this...same way OMAP DMA engine conversion is being done. -Matt ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
Hello. On 02/01/2013 09:49 PM, Matt Porter wrote: >>> Move mach-davinci/dma.c to common/edma.c so it can be used >>> by OMAP (specifically AM33xx) as well. >> I think this should rather go to drivers/dma/? > No, this is the private EDMA API. It's the analogous thing to > the private OMAP dma API that is in plat-omap/dma.c. The actual > dmaengine driver is in drivers/dma/edma.c as a wrapper around > this...same way OMAP DMA engine conversion is being done. Keeps me wondering why we couldn't have the same with CPPI 4.1 when I proposed that, instead of waiting indefinitely for TI to convert it to drivers/dma/ directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... Sigh. > -Matt WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
Hi, On Fri, Feb 01, 2013 at 10:52:46PM +0300, Sergei Shtylyov wrote: > Hello. > > On 02/01/2013 09:49 PM, Matt Porter wrote: > > >>> Move mach-davinci/dma.c to common/edma.c so it can be used > >>> by OMAP (specifically AM33xx) as well. > > >> I think this should rather go to drivers/dma/? > > > No, this is the private EDMA API. It's the analogous thing to > > the private OMAP dma API that is in plat-omap/dma.c. The actual > > dmaengine driver is in drivers/dma/edma.c as a wrapper around > > this...same way OMAP DMA engine conversion is being done. > > Keeps me wondering why we couldn't have the same with CPPI 4.1 when I > proposed > that, instead of waiting indefinitely for TI to convert it to drivers/dma/ > directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... > Sigh. good point, do you wanna send some patches ? I guess to make the MUSB side simpler we would need musb-dma-engine glue to map dmaengine to the private MUSB API. Then we would have some starting point to also move inventra (and anybody else) to dmaengine API. Once that's done, we drop MUSB's private API. -- balbi signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Fri, Feb 01, 2013 at 07:52:46PM +, Sergei Shtylyov wrote: > Hello. > > On 02/01/2013 09:49 PM, Matt Porter wrote: > > >>> Move mach-davinci/dma.c to common/edma.c so it can be used > >>> by OMAP (specifically AM33xx) as well. > > >> I think this should rather go to drivers/dma/? > > > No, this is the private EDMA API. It's the analogous thing to > > the private OMAP dma API that is in plat-omap/dma.c. The actual > > dmaengine driver is in drivers/dma/edma.c as a wrapper around > > this...same way OMAP DMA engine conversion is being done. > > Keeps me wondering why we couldn't have the same with CPPI 4.1 when I > proposed > that, instead of waiting indefinitely for TI to convert it to drivers/dma/ > directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... > Sigh. That is a shame. Yeah, I've pointed out that I was doing this exactly the same way as was acceptable for the OMAP DMA conversion since it was in RFC. The reasons are sound since in both cases, we have many drivers to convert that need to continue using the private DMA APIs. -Matt > ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
Hello. On 02/01/2013 09:58 PM, Felipe Balbi wrote: > Move mach-davinci/dma.c to common/edma.c so it can be used > by OMAP (specifically AM33xx) as well. I think this should rather go to drivers/dma/? >>> No, this is the private EDMA API. It's the analogous thing to >>> the private OMAP dma API that is in plat-omap/dma.c. The actual >>> dmaengine driver is in drivers/dma/edma.c as a wrapper around >>> this...same way OMAP DMA engine conversion is being done. >> Keeps me wondering why we couldn't have the same with CPPI 4.1 when I >> proposed >> that, instead of waiting indefinitely for TI to convert it to drivers/dma/ >> directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... >> Sigh. > good point, do you wanna send some patches ? I have already sent them countless times and even stuck CPPI 4.1 support (in arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the patch. :-( > I guess to make the MUSB side simpler we would need musb-dma-engine glue > to map dmaengine to the private MUSB API. Then we would have some > starting point to also move inventra (and anybody else) to dmaengine > API. Why? Inventra is a dedicated device's private DMA controller, why make universal DMA driver for it? > Once that's done, we drop MUSB's private API. Don't think it's a good idea. WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
hi, On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote: > > good point, do you wanna send some patches ? > >I have already sent them countless times and even stuck CPPI 4.1 support > (in > arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove > the > patch. :-( sticking into arch/arm/common/ wasn't a nice move. But then again, so wasn't asking for the patch to be removed :-s > > I guess to make the MUSB side simpler we would need musb-dma-engine glue > > to map dmaengine to the private MUSB API. Then we would have some > > starting point to also move inventra (and anybody else) to dmaengine > > API. > >Why? Inventra is a dedicated device's private DMA controller, why make > universal DMA driver for it? because it doesn't make sense to support multiple DMA APIs. We can check from MUSB's registers if it was configured with Inventra DMA support and based on that we can register MUSB's own DMA Engine to dmaengine API. > > Once that's done, we drop MUSB's private API. > >Don't think it's a good idea. see above. -- balbi signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Fri, Feb 01, 2013 at 10:56:00PM +0200, Felipe Balbi wrote: > hi, > > On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote: > > > good point, do you wanna send some patches ? > > > >I have already sent them countless times and even stuck CPPI 4.1 support > > (in > > arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove > > the > > patch. :-( > > sticking into arch/arm/common/ wasn't a nice move. But then again, so > wasn't asking for the patch to be removed :-s Err, patches don't get removed, they get moved to 'discarded'. > > > I guess to make the MUSB side simpler we would need musb-dma-engine glue > > > to map dmaengine to the private MUSB API. Then we would have some > > > starting point to also move inventra (and anybody else) to dmaengine > > > API. > > > >Why? Inventra is a dedicated device's private DMA controller, why make > > universal DMA driver for it? > > because it doesn't make sense to support multiple DMA APIs. We can check > from MUSB's registers if it was configured with Inventra DMA support and > based on that we can register MUSB's own DMA Engine to dmaengine API. Hang on. This is one of the DMA implementations which is closely coupled with the USB and only the USB? If it is... I thought this had been discussed _extensively_ before. I thought the resolution on it was: 1. It would not use the DMA engine API. 2. It would not live in arch/arm. 3. It would be placed nearby the USB driver it's associated with. (1) because we don't use APIs just for the hell of it - think. Do we use the DMA engine API for PCI bus mastering ethernet controllers? No. Do we use it for PCI bus mastering SCSI controllers? No. Because the DMA is integral to the rest of the device. The DMA engine API only makes sense if the DMA engine is a shared system resource. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH RFC v2] media: tvp514x: add OF support
Hi Prabhakar,
On 01/29/2013 02:07 PM, Prabhakar Lad wrote:
[...]
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
new file mode 100644
index 000..55d3ffd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
@@ -0,0 +1,38 @@
+* Texas Instruments TVP514x video decoder
+
+The TVP5146/TVP5146m2/TVP5147/TVP5147m1 device is high quality, single-chip
+digital video decoder that digitizes and decodes all popular baseband analog
+video formats into digital video component. The tvp514x decoder supports
analog-
+to-digital (A/D) conversion of component RGB and YPbPr signals as well as A/D
+conversion and decoding of NTSC, PAL and SECAM composite and S-video into
+component YCbCr.
+
+Required Properties :
+- compatible: Must be "ti,tvp514x-decoder"
There are no significant differences among TVP514* devices as listed above,
you would like to handle above ?
I'm just wondering if you don't need ,for instance, two separate compatible
properties, e.g. "ti,tvp5146-decoder" and "ti,tvp5147-decoder" ?
+- hsync-active: HSYNC Polarity configuration for current interface.
+- vsync-active: VSYNC Polarity configuration for current interface.
+- data-active: Clock polarity of the current interface.
I guess you mean "pclk-sample: Clock polarity..." ?
+
+Example:
+
+i2c0@1c22000 {
+ ...
+ ...
+
+ tvp514x@5c {
+ compatible = "ti,tvp514x-decoder";
+ reg =<0x5c>;
+
+ port {
+ tvp514x_1: endpoint {
+ /* Active high (Defaults to 0) */
+ hsync-active =<1>;
+ /* Active high (Defaults to 0) */
+ hsync-active =<1>;
Should it be vsync-active ?
+ /* Active low (Defaults to 0) */
+ data-active =<0>;
and this pclk-sample ?
+ };
+ };
+ };
+ ...
+};
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index a4f0a70..24ce759 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -12,6 +12,7 @@
* Hardik Shah
* Manjunath Hadli
* Karicheri Muralidharan
+ * Prabhakar Lad
*
* This package is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -33,7 +34,9 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -930,6 +933,58 @@ static struct tvp514x_decoder tvp514x_dev = {
};
+#if defined(CONFIG_OF)
+static const struct of_device_id tvp514x_of_match[] = {
+ {.compatible = "ti,tvp514x-decoder", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, tvp514x_of_match);
+
+static struct tvp514x_platform_data
+ *tvp514x_get_pdata(struct i2c_client *client)
+{
+ if (!client->dev.platform_data&& client->dev.of_node) {
+ struct tvp514x_platform_data *pdata;
+ struct v4l2_of_endpoint bus_cfg;
+ struct device_node *endpoint;
+
+ pdata = devm_kzalloc(&client->dev,
+ sizeof(struct tvp514x_platform_data),
+ GFP_KERNEL);
+ client->dev.platform_data = pdata;
Do you really need to set client->dev.platform_data this way ?
What about passing struct tvp514x_decoder pointer to this function
and initializing struct tvp514x_decoder::pdata instead ?
+ if (!pdata)
+ return NULL;
+
+ endpoint = of_get_child_by_name(client->dev.of_node, "port");
+ if (endpoint)
+ endpoint = of_get_child_by_name(endpoint, "endpoint");
I think you could replace these two calls above with
endpoint = v4l2_of_get_next_endpoint(client->dev.of_node);
Now I see I should have modified this function to ensure it works also when
'port' nodes are grouped in a 'ports' node.
+ if (!endpoint) {
+ v4l2_info(client, "Using default data!!\n");
+ } else {
+ v4l2_of_parse_parallel_bus(endpoint,&bus_cfg);
+
+ if (bus_cfg.mbus_flags& V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+ pdata->hs_polarity = 1;
+ if (bus_cfg.mbus_flags& V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+ pdata->vs_polarity = 1;
+ if (bus_cfg.mbus_flags& V4L2_MBUS_PCLK_SAMPLE_RISING)
+ pdata->clk_polarity = 1;
+ }
+ }
+
+ return client->dev.platform_data;
+}
+#else
+#define tvp514x_of_match NULL
+
+static struct tvp514x_platform_data
+ *tvp514x_get_pdata(struct i2c_client *client)
+{
+ return client->dev.platform_data;
+}
+#endif
+
/**
* tvp514x_
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
Hello. On 02-02-2013 0:56, Felipe Balbi wrote: good point, do you wanna send some patches ? I have already sent them countless times and even stuck CPPI 4.1 support (in arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the patch. :-( sticking into arch/arm/common/ wasn't a nice move. Like with EDMA we have nothing else to do with CPPI 4.1 being shared by DaVinci-like and OMAP-like SOCs. Thank TI for creatring this mess. And actually even that is not a good place since I think I know of a MIPS SoC having CPPI 4.1 as well, just out of tree. > But then again, so > wasn't asking for the patch to be removed :-s Unfortunately, Russell has done it -- all that was discuseed without me in the loop even. :-/ I guess to make the MUSB side simpler we would need musb-dma-engine glue to map dmaengine to the private MUSB API. Then we would have some starting point to also move inventra (and anybody else) to dmaengine API. Why? Inventra is a dedicated device's private DMA controller, why make universal DMA driver for it? because it doesn't make sense to support multiple DMA APIs. We can check from MUSB's registers if it was configured with Inventra DMA support and based on that we can register MUSB's own DMA Engine to dmaengine API. I still disagree. IMO drivers/dma/ is for standalone DMA engines. Else we could stick every bus mastering device's DMA engines there. CPPI 4.1 is in design standlone DMA engine, despite all in-tree implementations having it as subblock of MUSB and serving only MUSB. WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
Hello. On 01-02-2013 22:59, Matt Porter wrote: Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx) as well. I think this should rather go to drivers/dma/? No, this is the private EDMA API. It's the analogous thing to the private OMAP dma API that is in plat-omap/dma.c. The actual dmaengine driver is in drivers/dma/edma.c as a wrapper around this...same way OMAP DMA engine conversion is being done. Keeps me wondering why we couldn't have the same with CPPI 4.1 when I proposed that, instead of waiting indefinitely for TI to convert it to drivers/dma/ directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... Sigh. That is a shame. Yeah, I've pointed out that I was doing this exactly the same way as was acceptable for the OMAP DMA conversion since it was in RFC. The reasons are sound since in both cases, we have many drivers to convert that need to continue using the private DMA APIs. In case of CPPI 4.1, we'd only have to convert MUSB DMA driver. Other in-tree CPPI 4.1 having SoCs don't use it for anything but MUSB -- it even is sub-block of their MUSB device, AFAIK (I maybe wrong about Sitaras -- I don't know them well). -Matt WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
Hello. On 02-02-2013 1:30, Russell King - ARM Linux wrote: On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote: good point, do you wanna send some patches ? I have already sent them countless times and even stuck CPPI 4.1 support (in arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the patch. :-( sticking into arch/arm/common/ wasn't a nice move. But then again, so wasn't asking for the patch to be removed :-s Err, patches don't get removed, they get moved to 'discarded'. Any chance to bring it back to life? :-) Although... drivers/usb/musb/cppi41.c would need to be somewhat reworked for at least AM35x and I don't have time. But that may change, of course. I guess to make the MUSB side simpler we would need musb-dma-engine glue to map dmaengine to the private MUSB API. Then we would have some starting point to also move inventra (and anybody else) to dmaengine API. Why? Inventra is a dedicated device's private DMA controller, why make universal DMA driver for it? because it doesn't make sense to support multiple DMA APIs. We can check from MUSB's registers if it was configured with Inventra DMA support and based on that we can register MUSB's own DMA Engine to dmaengine API. Hang on. This is one of the DMA implementations which is closely coupled with the USB and only the USB? If it is... I thought this had been discussed _extensively_ before. I thought the resolution on it was: 1. It would not use the DMA engine API. 2. It would not live in arch/arm. 3. It would be placed nearby the USB driver it's associated with. (1) because we don't use APIs just for the hell of it - think. Do we use the DMA engine API for PCI bus mastering ethernet controllers? No. Do we use it for PCI bus mastering SCSI controllers? No. Because the DMA is integral to the rest of the device. The DMA engine API only makes sense if the DMA engine is a shared system resource. Thanks for such extensive wording in the support of my point. :-) WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
Hello. On 02-02-2013 1:30, Russell King - ARM Linux wrote: On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote: good point, do you wanna send some patches ? I have already sent them countless times and even stuck CPPI 4.1 support (in arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the patch. :-( sticking into arch/arm/common/ wasn't a nice move. But then again, so wasn't asking for the patch to be removed :-s Err, patches don't get removed, they get moved to 'discarded'. I guess to make the MUSB side simpler we would need musb-dma-engine glue to map dmaengine to the private MUSB API. Then we would have some starting point to also move inventra (and anybody else) to dmaengine API. Why? Inventra is a dedicated device's private DMA controller, why make universal DMA driver for it? because it doesn't make sense to support multiple DMA APIs. We can check from MUSB's registers if it was configured with Inventra DMA support and based on that we can register MUSB's own DMA Engine to dmaengine API. Hang on. This is one of the DMA implementations which is closely coupled with the USB and only the USB? If it is... I thought this had been discussed _extensively_ before. I thought the resolution on it was: 1. It would not use the DMA engine API. 2. It would not live in arch/arm. 3. It would be placed nearby the USB driver it's associated with. Note that all this doesn't apply to CPPI 4.1 controller (as contrasted to CPPI 3.0 support in MUSB aand EMAC drivers) -- it's shared by design. Just the implementations that are in tree have it as MUSB's sub-block, serving only MUSB. WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Sat, Feb 02, 2013 at 04:07:59AM +0400, Sergei Shtylyov wrote: > Hello. > > On 02-02-2013 1:30, Russell King - ARM Linux wrote: > >>> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote: > good point, do you wanna send some patches ? > I have already sent them countless times and even stuck CPPI 4.1 support (in arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the patch. :-( > >>> sticking into arch/arm/common/ wasn't a nice move. But then again, so >>> wasn't asking for the patch to be removed :-s > >> Err, patches don't get removed, they get moved to 'discarded'. > >Any chance to bring it back to life? :-) >Although... drivers/usb/musb/cppi41.c would need to be somewhat > reworked for at least AM35x and I don't have time. But that may change, > of course. Right, I've just looked back at the various meeting minutes from December 2010 when the CPPI stuff was discussed. Yes, I archive these things and all email discussions for referencing in cases like this. Unfortunately, they do not contain any useful information other than the topic having been brought up. At that point, the CPPI stuff was in mach-davinci, and I had suggested moving it into drivers/dma. The result of that was to say that it doesn't fit the DMA engine APIs. So someone came up with the idea of putting it in arch/arm/common - which I frankly ignored by email (how long have we been saying "no drivers in arch/arm" ?) Now, it would've been discussed in that meeting, but unfortunately no record exists of that. What does follow that meeting is a discussion trail. From what I can see there, but it looks to me like the decision was taken to move it to the DMA engine API, and work on sorting out MUSB was going to commence. The last email in that says "I'll get to that soon"... and that is also the final email I have on this topic. I guess if nothing has happened... Shrug, that's someone elses problem. Anyway, the answer for putting it in arch/arm/common hasn't changed, and really, where we are now, post Linus having a moan about the size of arch/arm, that answer is even more concrete in the negative. It's 54K of code which should not be under arch/arm at all. Anyway, if you need to look at the patch, it's 6305/1. Typing into the summary search box 'cppi' found it in one go. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
Hello. On 02-02-2013 4:44, Russell King - ARM Linux wrote: On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote: good point, do you wanna send some patches ? I have already sent them countless times and even stuck CPPI 4.1 support (in arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the patch. :-( sticking into arch/arm/common/ wasn't a nice move. But then again, so wasn't asking for the patch to be removed :-s Err, patches don't get removed, they get moved to 'discarded'. Any chance to bring it back to life? :-) Although... drivers/usb/musb/cppi41.c would need to be somewhat reworked for at least AM35x and I don't have time. But that may change, of course. Right, I've just looked back at the various meeting minutes from December 2010 when the CPPI stuff was discussed. Yes, I archive these things and all email discussions for referencing in cases like this. Thanks. Unfortunately, they do not contain any useful information other than the topic having been brought up. At that point, the CPPI stuff was in mach-davinci, and I had suggested moving it into drivers/dma. I don't remember that, probably was out of the loop again. The result of that was to say that it doesn't fit the DMA engine APIs. I remember this as a discussion happening post me sending the patch to the patch system and it being discarded... So someone came up with the idea of putting it in arch/arm/common - which Probably was me. There was also idea of putting it into drivers/usb/musb/ -- which TI indeed followed in its Arago prject. I firmly denied that suggestion. I frankly ignored by email (how long have we been saying "no drivers in arch/arm" ?) But there *are* drivers there! And look at edma.c which is about to be moved there... Anyway, I haven't seen such warnings, probably was too late in the game. Now, it would've been discussed in that meeting, but unfortunately no record exists of that. What does follow that meeting is a discussion trail. From what I can see there, but it looks to me like the decision was taken to move it to the DMA engine API, and work on sorting out MUSB was going to commence. The last email in that says "I'll get to that soon"... and that is also the final email I have on this topic. I guess if nothing has happened... Shrug, that's someone elses problem. Well, as usual... :-( Anyway, the answer for putting it in arch/arm/common hasn't changed, and really, where we are now, post Linus having a moan about the size of arch/arm, that answer is even more concrete in the negative. It's 54K of code which should not be under arch/arm at all. Anyway, if you need to look at the patch, it's 6305/1. Typing into the summary search box 'cppi' found it in one go. Thanks, I remember this variant was under arch/arm/common/. Now however, I see what happened to that variant in somewhat different light. Looks like it was entirely your decision to discard the patch, without TI's request... WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
