RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
[...] arch/arm/boot/dts/Makefile|1 + arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 + 2 files changed, 124 insertions(+) create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 0320303..c5e9bfa 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -226,6 +226,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ am335x-evmsk.dtb \ am335x-bone.dtb \ am335x-boneblack.dtb \ + am335x-bone-memory-cape.dtb\ am335x-nano.dtb \ am335x-base0033.dtb \ am3517-evm.dtb \ diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts b/arch/arm/boot/dts/am335x-bone-memory-cape.dts new file mode 100644 index 000..7ab088d --- /dev/null +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts From discussions, option I could think are.. (a) NAND cape node added in both 'am335x-bone.dts' and 'am335x-boneblack.dts' but disabled by default. (b) NAND cape node in new '.dts' file (as mentioned above), and generate a separate blob individual for cape. (c) NAND cape node in existing 'am335x-bone-common.dtsi', disabled by default. But there is no guarantee that future boards remain compatible and same 'common_xx.dtsi' can be reused later. I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the ones who have to maintain all these. Tony ? with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: omap-dma: Implement device_slave_caps callback
Hi Tony,
On 03/12/2014 07:37 PM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [140307 05:39]:
With the callback implemented omap-dma can provide information to client
drivers regarding to supported address widths, directions, residue
granularity, etc.
This may need some testing against linux next with Russell's
omap-dma.c clean-up series merged there. Peter, care to check
if this patch is still valid against linux next?
The patch applies cleanly on top of linux-next fetched yesterday and I see
Russell's patches underneath.
--
Péter
Regards,
Tony
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 64ceca2920b8..b19f04f4390b 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1088,6 +1088,23 @@ static void omap_dma_free(struct omap_dmadev *od)
}
}
+#define OMAP_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+ BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+ BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static int omap_dma_device_slave_caps(struct dma_chan *dchan,
+ struct dma_slave_caps *caps)
+{
+caps-src_addr_widths = OMAP_DMA_BUSWIDTHS;
+caps-dstn_addr_widths = OMAP_DMA_BUSWIDTHS;
+caps-directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+caps-cmd_pause = true;
+caps-cmd_terminate = true;
+caps-residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+
+return 0;
+}
+
static int omap_dma_probe(struct platform_device *pdev)
{
struct omap_dmadev *od;
@@ -1118,6 +1135,7 @@ static int omap_dma_probe(struct platform_device *pdev)
od-ddev.device_prep_slave_sg = omap_dma_prep_slave_sg;
od-ddev.device_prep_dma_cyclic = omap_dma_prep_dma_cyclic;
od-ddev.device_control = omap_dma_control;
+od-ddev.device_slave_caps = omap_dma_device_slave_caps;
od-ddev.dev = pdev-dev;
INIT_LIST_HEAD(od-ddev.channels);
INIT_LIST_HEAD(od-pending);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: dts: overo: Add graphics output
Hi, On 03/12/2014 08:14 AM, Tomi Valkeinen wrote: On 11/03/14 14:34, Florian Vaussard wrote: Hi, This series enables the DVI / LCD graphics present on some of the Overo expansion boards. DVI output: - Tobi - Summit LCD (3.5''): - Alto35 LCD (4.3''): - Chestnut43 - Palo43 - Gallop43 I tested on Tobi, Alto35 and Gallop43 using both OMAP35xx and OMAP36xx Overo boards. This series depends on Tomi's DSS patches [1] that are not yet merged. It also depends on previous Overo series [2] and [3] that are under review. A complete testing tree is available [4]. Looks good to me. Unfortunately the video bindings are still being discussed (mainly the ports/endpoints), so there might be changes needed when some kind of conclusion is reached. Yes, I saw. This is why I posted this separately from the other patches. I will update if necessary, let's wait. Regards, Florian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: overo: Add support for DVI output
Hi,
On 03/12/2014 08:11 AM, Tomi Valkeinen wrote:
On 11/03/14 14:34, Florian Vaussard wrote:
Summit and Tobi expansion boards have a HDMI connector with a TFP410
encoder. Add a common include file for this configuration, and then
use it for Summit and Tobi.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-overo-common-dvi.dtsi| 109
+++
arch/arm/boot/dts/omap3-overo-summit-common.dtsi | 1 +
arch/arm/boot/dts/omap3-overo-tobi-common.dtsi | 1 +
3 files changed, 111 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-overo-common-dvi.dtsi
snip
+dss {
+status = ok;
+
+pinctrl-names = default;
+pinctrl-0 = dss_dpi_pins
+ i2c3_pins;
The i2c3 pins don't belong here, they are not related to dss. The
dvi-connector uses i2c3, but I don't think they belong there either, as
the i2c3 bus can be used by multiple devices. So I guess they should be
set in i2c3 node.
You are right. And as I am already using i2c3 for other things, this
duplicates the pinctrl. I will drop it.
Regards,
Florian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] ARM: dts: overo: Add new expansion boards
Hi, On 03/12/2014 06:22 PM, Tony Lindgren wrote: * Florian Vaussard florian.vauss...@epfl.ch [140311 05:24]: Hi, This series adds the support for 5 new expansion boards from Gumstix: - Palo43 - Gallop43 - Chestnut43 - Alto35 - Summit The 1st patch is a preparatory work, in order to factorize some peripherals that are common to most Gumstix expansion boards. Patch 2 adds the support for an accelerometer that is present on most boards. Palo43, Gallop43 and Chestnut43 are all pretty similar. I tested on a Gallop43 (with both OMAP35xx and OMAP36xx Overo). Alto35 is slightly different. Again, I tested with both OMAP35xx and OMAP36xx Overo. Summit is pretty similar to Tobi. I do not have a Summit at hand, but given the similarity with Tobi, it should work fine. To avoid unnecessary duplications, I put all the common stuff for each board inside an omap3-overo-xxx-common.dsti include file. By doing so, I can have minimal SoC-specific omap3-overo-xxx.dts (omap34xx based) and omap3-overo-storm-xxx.dts (omap36xx based) device trees. This series depends on my previous Overo series [1]. A complete testing tree (including the graphics support, soon to be posted) is available at [2]. Thanks, applying the whole series into omap-for-v3.15/dt-overo. As it's this close to the merge window, no guarantees anything will get pulled in though. Thanks! Let's see. Anyway, this will not kill baby bears if it can't make it into 3.15 :) Regards, Florian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/9] ARM: dts: omap3-overo: Add HSUSB PHY
On 03/12/2014 06:19 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140311 02:46]: Any sane design would maintain register offsets but it doesn't seem so with omap34xx vs omap36xx. So my assumption was wrong. I'll ack this patch. OK thanks, I'll apply the whole series with your ack to omap-for-v3.15/dt-overo. Thanks! Florian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] ARM: OMAP4+: Fix gpmc_fck clock
Hi, On 02/26/2014 11:38 AM, Florian Vaussard wrote: Hello, Trying to get my SMSC9221 working on OMAP4 with DT, I faced a misconfigured gpmc_fck (dummy clock set to 0) resulting in serveral division-by-zero, misconfigured timings and driver lost in the La La Land. To solve this, patch 1 removes gpmc_fck from the dummy clocks, and patch 2 adds the gpmc_fck DT node and reference it from the gpmc node. *Note*: For DRA7, there is no DTS node for the GPMC, so I was unable to set the corresponding clock. And without a public TRM, I cannot do much more. Tested on DuoVero/Parlor (OMAP4430) with SMSC9221 (DTS was posted on the OMAP ML [1]). Regards, Florian [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/110801 --- Since v2: - Added OMAP5 and DRA7 Since v1: - Removed the gpmc_fck clock node, and reference directly l3_ick Florian Vaussard (2): CLK: TI: OMAP4/5/DRA7: Remove gpmc_fck from dummy clocks ARM: DTS: OMAP4/5: Use l3_ick for the gpmc node Any other comments on these two patches? If it is not going into 3.15 before the merge window, it will have to go through the -rc cycle as the Duovero/Parlor .dts will be upstream. Regards, Florian arch/arm/boot/dts/omap4.dtsi | 2 ++ arch/arm/boot/dts/omap5.dtsi | 2 ++ drivers/clk/ti/clk-44xx.c| 1 - drivers/clk/ti/clk-54xx.c| 1 - drivers/clk/ti/clk-7xx.c | 1 - 5 files changed, 4 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] ARM: OMAP2+: AM43xx DSS Hwmod
Add DSS hwmod structs for AM43xx.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 104
arch/arm/mach-omap2/prcm43xx.h |1 +
2 files changed, 105 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 9002fca..6a121db 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,8 @@
#include omap_hwmod.h
#include omap_hwmod_33xx_43xx_common_data.h
#include prcm43xx.h
+#include omap_hwmod_common_data.h
+
/* IP blocks */
static struct omap_hwmod am43xx_l4_hs_hwmod = {
@@ -415,6 +417,76 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
},
};
+/* Display sub system - DSS */
+
+static struct omap_hwmod_dma_info am43xx_dss_sdma_chs[] = {
+ { .name = dispc, .dma_req = 5 },
+ { .dma_req = -1 },
+};
+
+struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
+ .manager_count = 1,
+ .has_framedonetv_irq= 0
+};
+
+
+static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_dispc_hwmod_class = {
+ .name = dispc,
+ .sysc = am43xx_dispc_sysc,
+};
+
+static struct omap_hwmod am43xx_dss_core_hwmod = {
+ .name = dss_core,
+ .class = omap2_dss_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = disp_clk,
+ .sdma_reqs = am43xx_dss_sdma_chs,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* display controller -dispc*/
+
+static struct omap_hwmod am43xx_dss_dispc_hwmod = {
+ .name = dss_dispc,
+ .class = am43xx_dispc_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = disp_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ },
+ },
+ .dev_attr = am43xx_dss_dispc_dev_attr,
+};
+
+/*RFBI*/
+
+static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
+ .name = dss_rfbi,
+ .class = omap2_rfbi_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = disp_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ },
+ },
+};
+
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -654,6 +726,34 @@ static struct omap_hwmod_ocp_if am43xx_l3_s__qspi = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_dss__l3_main = {
+ .master = am43xx_dss_core_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= disp_clk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_dss_core_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_dispc = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_dss_dispc_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_dss_rfbi_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -747,6 +847,10 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__ocp2scp1,
am43xx_l3_s__usbotgss0,
am43xx_l3_s__usbotgss1,
+ am43xx_dss__l3_main,
+ am43xx_l4_ls__dss,
+ am43xx_l4_ls__dss_dispc,
+ am43xx_l4_ls__dss_rfbi,
NULL,
};
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index 7785be9..ad7b3e9 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -142,5 +142,6 @@
#define AM43XX_CM_PER_USBPHYOCP2SCP0_CLKCTRL_OFFSET0x05B8
#define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET0x0268
#define
[PATCH v2 2/4] ARM: AM43xx: fix dpll init in bypass mode
From: Tomi Valkeinen tomi.valkei...@ti.com
On AM43xx, if a PLL is in bypass at kernel init, the code in
omap2_get_dpll_rate() will not realize this and will try to calculate
the clock rate using the multiplier and the divider, resulting in
errors.
omap2_init_dpll_parent() has similar issue.
Add the missing soc_is_am43xx() check to make the code work on AM43xx.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/clkt_dpll.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 924c230..14e9e45 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -209,7 +209,7 @@ u8 omap2_init_dpll_parent(struct clk_hw *hw)
if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
v == OMAP3XXX_EN_DPLL_FRBYPASS)
return 1;
- } else if (soc_is_am33xx() || cpu_is_omap44xx()) {
+ } else if (soc_is_am33xx() || cpu_is_omap44xx() || soc_is_am43xx()) {
if (v == OMAP4XXX_EN_DPLL_LPBYPASS ||
v == OMAP4XXX_EN_DPLL_FRBYPASS ||
v == OMAP4XXX_EN_DPLL_MNBYPASS)
@@ -255,7 +255,7 @@ unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk)
if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
v == OMAP3XXX_EN_DPLL_FRBYPASS)
return __clk_get_rate(dd-clk_bypass);
- } else if (soc_is_am33xx() || cpu_is_omap44xx()) {
+ } else if (soc_is_am33xx() || cpu_is_omap44xx() || soc_is_am43xx()) {
if (v == OMAP4XXX_EN_DPLL_LPBYPASS ||
v == OMAP4XXX_EN_DPLL_FRBYPASS ||
v == OMAP4XXX_EN_DPLL_MNBYPASS)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] OMAPDSS: Add DSS features for AM43xx
Add DSS features for AM43xx.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/mach-omap2/display.c |2 +
drivers/video/omap2/dss/dispc.c|1 +
drivers/video/omap2/dss/dpi.c |2 +
drivers/video/omap2/dss/dsi.c |1 +
drivers/video/omap2/dss/dss.c | 11 ++
drivers/video/omap2/dss/dss_features.c | 67
include/video/omapdss.h|1 +
7 files changed, 85 insertions(+)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index a4e536b..d1cac1c 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -316,6 +316,8 @@ static enum omapdss_version __init
omap_display_get_version(void)
return OMAPDSS_VER_OMAP4;
else if (soc_is_omap54xx())
return OMAPDSS_VER_OMAP5;
+ else if (soc_is_am43xx())
+ return OMAPDSS_VER_AM43xx;
else
return OMAPDSS_VER_UNKNOWN;
}
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 4ec59ca..1b4aed5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3622,6 +3622,7 @@ static int __init dispc_init_features(struct
platform_device *pdev)
case OMAPDSS_VER_OMAP34xx_ES3:
case OMAPDSS_VER_OMAP3630:
case OMAPDSS_VER_AM35xx:
+ case OMAPDSS_VER_AM43xx:
src = omap34xx_rev3_0_dispc_feats;
break;
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index bd48cde..7ee7f86 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -64,6 +64,7 @@ static struct platform_device *dpi_get_dsidev(enum
omap_channel channel)
case OMAPDSS_VER_OMAP34xx_ES3:
case OMAPDSS_VER_OMAP3630:
case OMAPDSS_VER_AM35xx:
+ case OMAPDSS_VER_AM43xx:
return NULL;
case OMAPDSS_VER_OMAP4430_ES1:
@@ -593,6 +594,7 @@ static enum omap_channel dpi_get_channel(void)
case OMAPDSS_VER_OMAP34xx_ES3:
case OMAPDSS_VER_OMAP3630:
case OMAPDSS_VER_AM35xx:
+ case OMAPDSS_VER_AM43xx:
return OMAP_DSS_CHANNEL_LCD;
case OMAPDSS_VER_OMAP4430_ES1:
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6056b27..d68b49b 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -5082,6 +5082,7 @@ static enum omap_channel dsi_get_channel(int module_id)
{
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
+ case OMAPDSS_VER_AM43xx:
DSSWARN(DSI not supported\n);
return OMAP_DSS_CHANNEL_LCD;
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index bd01608..0b60746 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -795,6 +795,13 @@ static const struct dss_features omap54xx_dss_feats
__initconst = {
.dpi_select_source = dss_dpi_select_source_omap5,
};
+static const struct dss_features am43xx_dss_feats __initconst = {
+ .fck_div_max= 0,
+ .dss_fck_multiplier = 0,
+ .parent_clk_name= NULL,
+ .dpi_select_source = dss_dpi_select_source_omap2_omap3,
+};
+
static int __init dss_init_features(struct platform_device *pdev)
{
const struct dss_features *src;
@@ -831,6 +838,10 @@ static int __init dss_init_features(struct platform_device
*pdev)
src = omap54xx_dss_feats;
break;
+ case OMAPDSS_VER_AM43xx:
+ src = am43xx_dss_feats;
+ break;
+
default:
return -ENODEV;
}
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index f8fd6db..79df1a2 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -93,6 +93,17 @@ static const struct dss_reg_field omap3_dss_reg_fields[] = {
[FEAT_REG_DSIPLL_REGM_DSI] = { 26, 23 },
};
+static const struct dss_reg_field am43xx_dss_reg_fields[] = {
+ [FEAT_REG_FIRHINC] = { 12, 0 },
+ [FEAT_REG_FIRVINC] = { 28, 16 },
+ [FEAT_REG_FIFOLOWTHRESHOLD] = { 11, 0 },
+ [FEAT_REG_FIFOHIGHTHRESHOLD]= { 27, 16 },
+ [FEAT_REG_FIFOSIZE] = { 10, 0 },
+ [FEAT_REG_HORIZONTALACCU] = { 9, 0 },
+ [FEAT_REG_VERTICALACCU] = { 25, 16 },
+ [FEAT_REG_DISPC_CLK_SWITCH] = { 0, 0 },
+};
+
static const struct dss_reg_field omap4_dss_reg_fields[] = {
[FEAT_REG_FIRHINC] = { 12, 0 },
[FEAT_REG_FIRVINC] = { 28, 16 },
@@ -149,6 +160,11 @@ static const enum omap_display_type
omap3630_dss_supported_displays[] = {
[PATCH v2 0/4] Add Display support for AM43xx
This patch series adds DSS support to the AM43x. The DPI LCD panel is supported on both am43x-epos-evm and am437x-gp-evm. The LCD panel is from OSD model: OSD057T0559-34TS Version 1 of this series can be found below[1]: [1]: https://patchwork.kernel.org/patch/3274421/ Tested on am43x-epos-evm and am437x-gp-evm. Dependent patches : Sourav patches adding device nodes for epos [2] and gp [3] evm [2]: https://patchwork.kernel.org/patch/3246701/ [3]: https://patchwork.kernel.org/patch/3246751/ AM43xx has a dedicated display pll. Hence tomi patch improving func clock handling is needed [4] [4]: https://patchwork.kernel.org/patch/3196221/ Tomi patch adding DT support to DSS [5] [5]: https://patchwork.kernel.org/patch/3516341/ Changes from V1: Rebased to latest DSS DT changes from Tomi which is under review [5] Sathya Prakash M R (3): OMAPDSS: Add DSS features for AM43xx ARM: OMAP2+: AM43xx DSS Hwmod ARM: DTS: AM43x: Add DSS node Tomi Valkeinen (1): ARM: AM43xx: fix dpll init in bypass mode arch/arm/boot/dts/am4372.dtsi | 28 arch/arm/boot/dts/am437x-gp-evm.dts| 77 arch/arm/boot/dts/am43x-epos-evm.dts | 73 +++ arch/arm/boot/dts/am43xx-clocks.dtsi |2 + arch/arm/mach-omap2/clkt_dpll.c|4 +- arch/arm/mach-omap2/display.c |2 + arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 104 arch/arm/mach-omap2/prcm43xx.h |1 + drivers/video/omap2/dss/dispc.c|1 + drivers/video/omap2/dss/dpi.c |2 + drivers/video/omap2/dss/dsi.c |1 + drivers/video/omap2/dss/dss.c | 11 +++ drivers/video/omap2/dss/dss_features.c | 67 ++ include/video/omapdss.h|1 + 14 files changed, 372 insertions(+), 2 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] ARM: DTS: AM43x: Add DSS node
Add device node for DSS module for AM4372. Both the
AM437x-Gp evm and Am43x-Epos evm use the same LCD panel.
The lcd timings are added in respective dts files.
Adds display pinctrl and enables required gpio.
Also set the right parent clock to the DSS clock.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/boot/dts/am4372.dtsi| 28 +
arch/arm/boot/dts/am437x-gp-evm.dts | 77 ++
arch/arm/boot/dts/am43x-epos-evm.dts | 73
arch/arm/boot/dts/am43xx-clocks.dtsi |2 +
4 files changed, 180 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ea55a4e..b72a7df 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -684,6 +684,34 @@
num-cs = 4;
status = disabled;
};
+
+ dss: dss@4832A000 {
+ compatible = ti,omap3-dss, simple-bus;
+ reg = 0x4832A000 0x200;
+ ti,hwmods = dss_core;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@4832A400 {
+ compatible = ti,omap3-dispc;
+ reg = 0x4832A400 0x400;
+ interrupts = GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ };
+
+ dpi: encoder@0 {
+ compatible = ti,omap3-dpi;
+ };
+
+ rfbi: rfbi@4832A800 {
+ compatible = ti,omap3-rfbi;
+ reg = 0x4832A800 0x100;
+ ti,hwmods = dss_rfbi;
+ };
+
+ };
+
};
clocks {
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 2e79bda..a178e8d 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -24,6 +24,33 @@
brightness-levels = 0 51 53 56 62 75 101 152 255;
default-brightness-level = 8;
};
+
+ aliases {
+ display0 = lcd0;
+ };
+
+ lcd0: display {
+ compatible = osddisplays,osd057T0559-34ts, panel-dpi;
+ label = lcd;
+ panel-timing {
+ clock-frequency = 3300;
+ hactive = 800;
+ vactive = 480;
+ hfront-porch = 210;
+ hback-porch = 16;
+ hsync-len = 30;
+ vback-porch = 10;
+ vfront-porch = 22;
+ vsync-len = 13;
+ hsync-active = 0;
+ vsync-active = 0;
+ de-active = 1;
+ pixelclk-active = 1;
+ };
+ lcd_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
};
am43xx_pinmux {
@@ -46,6 +73,40 @@
0x164 MUX_MODE0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
;
};
+
+ dss_pinctrl: dss_pinctrl {
+ pinctrl-single,pins =
+ 0x020 (PIN_OUTPUT_PULLUP | MUX_MODE1) /*gpmc ad 8 -
DSS DATA 23 */
+ 0x024 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x028 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x02C (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x030 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x034 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x038 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x03C (PIN_OUTPUT_PULLUP | MUX_MODE1) /*gpmc ad 15 -
DSS DATA 16 */
+ 0x0A0 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS DATA 0 */
+ 0x0A4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0A8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0AC (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0B0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0B4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0B8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0BC (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0C0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0C4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0C8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0CC (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0D0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0D4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0D8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0DC
Re: [PATCHv8 2/4] power_supply: Introduce generic psy charging driver
On Wed 2014-03-12 15:32:59, Linus Walleij wrote: On Mon, Mar 10, 2014 at 5:33 AM, Jenny Tc jenny...@intel.com wrote: On Fri, Mar 07, 2014 at 09:25:20PM +0100, Pavel Machek wrote: + /* sort based on priority. 0 has the highest priority */ + for (i = 0; i cnt; ++i) + for (j = 0; j cnt; ++j) + if (psy_prioirty(psy_lst[j]) psy_prioirty(psy_lst[i])) + swap(psy_lst[j], psy_lst[i]); + WTF? Bubble sort in kernel? Yes, it's bubble sort. Since the number of power supply objects in real systems (max 4) are limited, I feel the complexity would be as same as any other sorting algorithms. Any suggestions? You already have a kernel quicksort implementation in lib/sort.c. Please restructure the code to make use of this as it is already compiled into every kernel. Actually.. I believe the code needs more surgery than that. It should not need those string lookups -- just attach data directly to struct psy. And yes, if sort remains, it needs to use library function, but I strongly believe sorting should not be neccessary here. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] power_supply: Introduce generic psy charging driver
Hi! 30*HZ means 30 seconds in the kernel... what is hard to understand about it? Well I might be picky, but since it is a charging algorithm dealing with ampères, volts, constant-current/constant-voltage, watchdogs and timeouts, all stated in SI units, it would be nice if all such constants were specified in simple units instead of kernel-specific terms. I agree HZ is badly named, but hopefully anyone working on kernel is already familiar with it. But... what would actually help: I believe we should introduce milivolt_t, miliamp_t, milisec_t etc... types. Storing milivolts in int, then having comment saying milivolts is just wrong. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap: cm-t3530: Add MMC2/SDIO/WLAN support
On 03/12/14 19:44, Tony Lindgren wrote:
* Stefan Roese s...@denx.de [140312 03:52]:
Add support for the MMC2/SDIO WiFi Libertas (Marvell) module available
on the CM-T3530 SOM.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Dmitry Lifshitz lifsh...@compulab.co.il
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Tony Lindgren t...@atomide.com
Acked-by: Igor Grinberg grinb...@compulab.co.il
---
This patch is based on current mainline (v3.14-rc6) plus this compulab patch
series from Dmitry:
[PATCH 00/11] ARM: dts: sbc-t3x: add support for more boards
http://www.spinics.net/lists/arm-kernel/msg300078.html
Thanks applying into omap-for-v3.15/dt, no guarantees it gets merged though
as it's getting so close to the merge window.
Regards,
Tony
arch/arm/boot/dts/omap3-cm-t3530.dts | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-cm-t3530.dts
b/arch/arm/boot/dts/omap3-cm-t3530.dts
index 9faf1cd..d145849 100644
--- a/arch/arm/boot/dts/omap3-cm-t3530.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3530.dts
@@ -9,4 +9,40 @@
/ {
model = CompuLab CM-T3530;
compatible = compulab,omap3-cm-t3530, ti,omap34xx, ti,omap3;
+
+/* Regulator to trigger the reset signal of the Wifi module */
+mmc2_sdio_reset: regulator-mmc2-sdio-reset {
+compatible = regulator-fixed;
+regulator-name = regulator-mmc2-sdio-reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = twl_gpio 2 GPIO_ACTIVE_HIGH;
+enable-active-high;
+};
+};
+
+omap3_pmx_core {
+mmc2_pins: pinmux_mmc2_pins {
+pinctrl-single,pins =
+OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_clk.sdmmc2_clk */
+OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_cmd.sdmmc2_cmd */
+OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat0.sdmmc2_dat0 */
+OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat1.sdmmc2_dat1 */
+OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat2.sdmmc2_dat2 */
+OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat3.sdmmc2_dat3 */
+OMAP3_CORE1_IOPAD(0x2164, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat4.sdmmc2_dir_dat0 */
+OMAP3_CORE1_IOPAD(0x2166, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat5.sdmmc2_dir_dat1 */
+OMAP3_CORE1_IOPAD(0x2168, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat6.sdmmc2_dir_cmd */
+OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT | MUX_MODE1)
/* sdmmc2_dat7.sdmmc2_clkin */
+;
+};
+};
+
+mmc2 {
+pinctrl-names = default;
+pinctrl-0 = mmc2_pins;
+vmmc-supply = mmc2_sdio_reset;
+non-removable;
+bus-width = 4;
+cap-power-off-card;
};
--
1.8.5.5
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/18] dma: edma: Print the direction value as well when it is not supported
In case of not supported direction it is better to print the direction also.
It is unlikely, but in such an event it helps with the debugging.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 47abaac7eb18..69dd4e3de67e 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -426,7 +426,7 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
dev_width = echan-cfg.dst_addr_width;
burst = echan-cfg.dst_maxburst;
} else {
- dev_err(dev, %s: bad direction?\n, __func__);
+ dev_err(dev, %s: bad direction: %d\n, __func__, direction);
return NULL;
}
@@ -519,7 +519,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
dev_width = echan-cfg.dst_addr_width;
burst = echan-cfg.dst_maxburst;
} else {
- dev_err(dev, %s: bad direction?\n, __func__);
+ dev_err(dev, %s: bad direction: %d\n, __func__, direction);
return NULL;
}
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/18] ASoC: davinci-mcasp: Place constraint on the period size based on FIFO config
We need to place constraint on the period size (and indirectly to buffer
size) if the read or write AFIFO is enabled and it is configured for more
than one word otherwise the DMA will fail in buffer configuration where
the sizes are not aligned with the requested FIFO configuration.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/davinci/davinci-mcasp.c | 20
1 file changed, 20 insertions(+)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index 958933614ca4..17d1112bce24 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -717,7 +717,27 @@ static int davinci_mcasp_trigger(struct snd_pcm_substream
*substream,
return ret;
}
+static int davinci_mcasp_startup(struct snd_pcm_substream *substream,
+struct snd_soc_dai *cpu_dai)
+{
+ struct davinci_mcasp *mcasp = snd_soc_dai_get_drvdata(cpu_dai);
+ int afifo_numevt;
+
+ if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
+ afifo_numevt = mcasp-txnumevt;
+ else
+ afifo_numevt = mcasp-rxnumevt;
+
+ if (afifo_numevt 1)
+ snd_pcm_hw_constraint_step(substream-runtime, 0,
+ SNDRV_PCM_HW_PARAM_PERIOD_SIZE,
+ afifo_numevt);
+
+ return 0;
+}
+
static const struct snd_soc_dai_ops davinci_mcasp_dai_ops = {
+ .startup= davinci_mcasp_startup,
.trigger= davinci_mcasp_trigger,
.hw_params = davinci_mcasp_hw_params,
.set_fmt= davinci_mcasp_set_dai_fmt,
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/18] ASoC: davinci: Add edma dmaengine platform driver
Platform driver glue for SoC using eDMA3 to use dmaengine PCM.
The maximum number of periods need to be limited to 19 since the
edma dmaengine driver limits the paRAM slot use for audio at
in cyclic mode.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/davinci/Kconfig| 1 +
sound/soc/davinci/Makefile | 2 +-
sound/soc/davinci/edma-pcm.c | 77
sound/soc/davinci/edma-pcm.h | 26 +++
4 files changed, 105 insertions(+), 1 deletion(-)
create mode 100644 sound/soc/davinci/edma-pcm.c
create mode 100644 sound/soc/davinci/edma-pcm.h
diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
index a8ec1fc3e4d0..f9d9f748e743 100644
--- a/sound/soc/davinci/Kconfig
+++ b/sound/soc/davinci/Kconfig
@@ -1,6 +1,7 @@
config SND_DAVINCI_SOC
tristate SoC Audio for TI DAVINCI or AM33XX/AM43XX chips
depends on ARCH_DAVINCI || SOC_AM33XX || SOC_AM43XX
+ select SND_SOC_GENERIC_DMAENGINE_PCM
config SND_DAVINCI_SOC_I2S
tristate
diff --git a/sound/soc/davinci/Makefile b/sound/soc/davinci/Makefile
index 744d4d9a0184..97d05a2f1723 100644
--- a/sound/soc/davinci/Makefile
+++ b/sound/soc/davinci/Makefile
@@ -1,5 +1,5 @@
# DAVINCI Platform Support
-snd-soc-davinci-objs := davinci-pcm.o
+snd-soc-davinci-objs := davinci-pcm.o edma-pcm.o
snd-soc-davinci-i2s-objs := davinci-i2s.o
snd-soc-davinci-mcasp-objs:= davinci-mcasp.o
snd-soc-davinci-vcif-objs:= davinci-vcif.o
diff --git a/sound/soc/davinci/edma-pcm.c b/sound/soc/davinci/edma-pcm.c
new file mode 100644
index ..eeed927a2657
--- /dev/null
+++ b/sound/soc/davinci/edma-pcm.c
@@ -0,0 +1,77 @@
+/*
+ * edma-pcm.c - eDMA PCM driver using dmaengine for AM3xxx, AM4xxx
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * Author: Peter Ujfalusi peter.ujfal...@ti.com
+ *
+ * Based on: sound/soc/tegra/tegra_pcm.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/module.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/dmaengine_pcm.h
+#include linux/edma.h
+
+static const struct snd_pcm_hardware edma_pcm_hardware = {
+ .info = SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID |
+ SNDRV_PCM_INFO_BATCH |
+ SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME |
+ SNDRV_PCM_INFO_INTERLEAVED,
+ .buffer_bytes_max = 128 * 1024,
+ .period_bytes_min = 32,
+ .period_bytes_max = 64 * 1024,
+ .periods_min= 2,
+ .periods_max= 19, /* Limit by edma dmaengine driver */
+};
+
+static const struct snd_dmaengine_pcm_config edma_dmaengine_pcm_config = {
+ .pcm_hardware = edma_pcm_hardware,
+ .prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
+ .prealloc_buffer_size = 128 * 1024,
+};
+
+static const struct snd_dmaengine_pcm_config edma_compat_dmaengine_pcm_config
= {
+ .pcm_hardware = edma_pcm_hardware,
+ .prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
+ .compat_filter_fn = edma_filter_fn,
+ .prealloc_buffer_size = 128 * 1024,
+};
+
+int edma_pcm_platform_register(struct device *dev)
+{
+ if (dev-of_node)
+ return snd_dmaengine_pcm_register(dev,
+ edma_dmaengine_pcm_config,
+ SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
+ else
+ return snd_dmaengine_pcm_register(dev,
+ edma_compat_dmaengine_pcm_config,
+ SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
+ SND_DMAENGINE_PCM_FLAG_NO_DT |
+ SND_DMAENGINE_PCM_FLAG_COMPAT);
+}
+EXPORT_SYMBOL_GPL(edma_pcm_platform_register);
+
+void edma_pcm_platform_unregister(struct device *dev)
+{
+ snd_dmaengine_pcm_unregister(dev);
+}
+EXPORT_SYMBOL_GPL(edma_pcm_platform_unregister);
+
+MODULE_AUTHOR(Peter Ujfalusi peter.ujfal...@ti.com);
+MODULE_DESCRIPTION(eDMA PCM ASoC platform driver);
+MODULE_LICENSE(GPL);
diff --git a/sound/soc/davinci/edma-pcm.h b/sound/soc/davinci/edma-pcm.h
new file mode 100644
index ..25dc8c7ff093
--- /dev/null
+++ b/sound/soc/davinci/edma-pcm.h
@@ -0,0 +1,26 @@
+/*
+ * edma-pcm.h - eDMA PCM driver using dmaengine for AM3xxx, AM4xxx
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ *
[PATCH 16/18] ASoC: davinci-mcasp: Provide correct filter_data for dmaengine for non-DT boot
When we boot with non-DT mode the damengine will need the channel number and
a filter function in order to get the channel.
The filter_data is filled in the DAI driver while the filter_function will
be provided by the edma-pcm driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/davinci/davinci-mcasp.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index 604aa982f5c4..5428615413e2 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -1029,6 +1029,7 @@ nodata:
static int davinci_mcasp_probe(struct platform_device *pdev)
{
struct davinci_pcm_dma_params *dma_params;
+ struct snd_dmaengine_dai_dma_data *dma_data;
struct resource *mem, *ioarea, *res, *dat;
struct davinci_mcasp_pdata *pdata;
struct davinci_mcasp *mcasp;
@@ -1098,6 +1099,7 @@ static int davinci_mcasp_probe(struct platform_device
*pdev)
mcasp-dat_port = true;
dma_params = mcasp-dma_params[SNDRV_PCM_STREAM_PLAYBACK];
+ dma_data = mcasp-dma_data[SNDRV_PCM_STREAM_PLAYBACK];
dma_params-asp_chan_q = pdata-asp_chan_q;
dma_params-ram_chan_q = pdata-ram_chan_q;
dma_params-sram_pool = pdata-sram_pool;
@@ -1108,7 +1110,7 @@ static int davinci_mcasp_probe(struct platform_device
*pdev)
dma_params-dma_addr = mem-start + pdata-tx_dma_offset;
/* Unconditional dmaengine stuff */
- mcasp-dma_data[SNDRV_PCM_STREAM_PLAYBACK].addr = dma_params-dma_addr;
+ dma_data-addr = dma_params-dma_addr;
res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
if (res)
@@ -1116,7 +1118,14 @@ static int davinci_mcasp_probe(struct platform_device
*pdev)
else
dma_params-channel = pdata-tx_dma_channel;
+ /* dmaengine filter data for DT and non-DT boot */
+ if (pdev-dev.of_node)
+ dma_data-filter_data = tx;
+ else
+ dma_data-filter_data = dma_params-channel;
+
dma_params = mcasp-dma_params[SNDRV_PCM_STREAM_CAPTURE];
+ dma_data = mcasp-dma_data[SNDRV_PCM_STREAM_CAPTURE];
dma_params-asp_chan_q = pdata-asp_chan_q;
dma_params-ram_chan_q = pdata-ram_chan_q;
dma_params-sram_pool = pdata-sram_pool;
@@ -1127,7 +1136,7 @@ static int davinci_mcasp_probe(struct platform_device
*pdev)
dma_params-dma_addr = mem-start + pdata-rx_dma_offset;
/* Unconditional dmaengine stuff */
- mcasp-dma_data[SNDRV_PCM_STREAM_CAPTURE].addr = dma_params-dma_addr;
+ dma_data-addr = dma_params-dma_addr;
if (mcasp-version MCASP_VERSION_3) {
mcasp-fifo_base = DAVINCI_MCASP_V2_AFIFO_BASE;
@@ -1143,9 +1152,11 @@ static int davinci_mcasp_probe(struct platform_device
*pdev)
else
dma_params-channel = pdata-rx_dma_channel;
- /* Unconditional dmaengine stuff */
- mcasp-dma_data[SNDRV_PCM_STREAM_PLAYBACK].filter_data = tx;
- mcasp-dma_data[SNDRV_PCM_STREAM_CAPTURE].filter_data = rx;
+ /* dmaengine filter data for DT and non-DT boot */
+ if (pdev-dev.of_node)
+ dma_data-filter_data = rx;
+ else
+ dma_data-filter_data = dma_params-channel;
dev_set_drvdata(pdev-dev, mcasp);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/18] ASoC: davinci-mcasp: Assign the dma_data earlier in dai_probe callback
Remove the dai startup callback and do the dma_data setup for dmaengine
in the dai_probe function.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/davinci/davinci-mcasp.c | 35 +++
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index 5428615413e2..958933614ca4 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -717,31 +717,33 @@ static int davinci_mcasp_trigger(struct snd_pcm_substream
*substream,
return ret;
}
-static int davinci_mcasp_startup(struct snd_pcm_substream *substream,
-struct snd_soc_dai *dai)
+static const struct snd_soc_dai_ops davinci_mcasp_dai_ops = {
+ .trigger= davinci_mcasp_trigger,
+ .hw_params = davinci_mcasp_hw_params,
+ .set_fmt= davinci_mcasp_set_dai_fmt,
+ .set_clkdiv = davinci_mcasp_set_clkdiv,
+ .set_sysclk = davinci_mcasp_set_sysclk,
+};
+
+static int davinci_mcasp_dai_probe(struct snd_soc_dai *dai)
{
struct davinci_mcasp *mcasp = snd_soc_dai_get_drvdata(dai);
- if (mcasp-version = MCASP_VERSION_3)
+ if (mcasp-version = MCASP_VERSION_3) {
/* Using dmaengine PCM */
- snd_soc_dai_set_dma_data(dai, substream,
- mcasp-dma_data[substream-stream]);
- else
+ dai-playback_dma_data =
+ mcasp-dma_data[SNDRV_PCM_STREAM_PLAYBACK];
+ dai-capture_dma_data =
+ mcasp-dma_data[SNDRV_PCM_STREAM_CAPTURE];
+ } else {
/* Using davinci-pcm */
- snd_soc_dai_set_dma_data(dai, substream, mcasp-dma_params);
+ dai-playback_dma_data = mcasp-dma_params;
+ dai-capture_dma_data = mcasp-dma_params;
+ }
return 0;
}
-static const struct snd_soc_dai_ops davinci_mcasp_dai_ops = {
- .startup= davinci_mcasp_startup,
- .trigger= davinci_mcasp_trigger,
- .hw_params = davinci_mcasp_hw_params,
- .set_fmt= davinci_mcasp_set_dai_fmt,
- .set_clkdiv = davinci_mcasp_set_clkdiv,
- .set_sysclk = davinci_mcasp_set_sysclk,
-};
-
#ifdef CONFIG_PM_SLEEP
static int davinci_mcasp_suspend(struct snd_soc_dai *dai)
{
@@ -795,6 +797,7 @@ static int davinci_mcasp_resume(struct snd_soc_dai *dai)
static struct snd_soc_dai_driver davinci_mcasp_dai[] = {
{
.name = davinci-mcasp.0,
+ .probe = davinci_mcasp_dai_probe,
.suspend= davinci_mcasp_suspend,
.resume = davinci_mcasp_resume,
.playback = {
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/18] dma: edma: Prefix debug prints where the text were identical in prep callbacks
prep_slave_sg and prep_dma_cyclic callbacks have mostly same failure cases
with the same texts printed in case we hit them. It helps when debugging if
we know exactly which callback generated the errors.
At the same time change the debug level for descriptor allocation failure
from dbg to err since all other error cases are dev_err and this failure is
similarly fatal as the other ones.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index e2aa42b8342f..07ac5f4eeb56 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -430,14 +430,14 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
}
if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
- dev_err(dev, Undefined slave buswidth\n);
+ dev_err(dev, %s: Undefined slave buswidth\n, __func__);
return NULL;
}
edesc = kzalloc(sizeof(*edesc) + sg_len *
sizeof(edesc-pset[0]), GFP_ATOMIC);
if (!edesc) {
- dev_dbg(dev, Failed to allocate a descriptor\n);
+ dev_err(dev, %s: Failed to allocate a descriptor\n, __func__);
return NULL;
}
@@ -453,7 +453,8 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
EDMA_SLOT_ANY);
if (echan-slot[i] 0) {
kfree(edesc);
- dev_err(dev, Failed to allocate slot\n);
+ dev_err(dev, %s: Failed to allocate slot\n,
+ __func__);
return NULL;
}
}
@@ -522,7 +523,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
}
if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
- dev_err(dev, Undefined slave buswidth\n);
+ dev_err(dev, %s: Undefined slave buswidth\n, __func__);
return NULL;
}
@@ -547,7 +548,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc = kzalloc(sizeof(*edesc) + nslots *
sizeof(edesc-pset[0]), GFP_ATOMIC);
if (!edesc) {
- dev_dbg(dev, Failed to allocate a descriptor\n);
+ dev_err(dev, %s: Failed to allocate a descriptor\n, __func__);
return NULL;
}
@@ -565,7 +566,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
EDMA_SLOT_ANY);
if (echan-slot[i] 0) {
kfree(edesc);
- dev_err(dev, Failed to allocate slot\n);
+ dev_err(dev, %s: Failed to allocate slot\n,
+ __func__);
return NULL;
}
}
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/18] ASoC: davinci-mcasp: Use dmaengine based platform driver for AM335x/447x
Use the edma-pcm with AM335x and AM447x SoCs.
Keep using the davinci-pcm for DaVinci devices, they can be switched to use
the dmaengine based driver later when they are verified to work correctly.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/davinci/davinci-mcasp.c | 46 +--
1 file changed, 39 insertions(+), 7 deletions(-)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index b0ae0677f023..604aa982f5c4 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -36,6 +36,7 @@
#include davinci-pcm.h
#include davinci-mcasp.h
+#include edma-pcm.h
struct davinci_mcasp_context {
u32 txfmtctl;
@@ -721,10 +722,12 @@ static int davinci_mcasp_startup(struct snd_pcm_substream
*substream,
{
struct davinci_mcasp *mcasp = snd_soc_dai_get_drvdata(dai);
- if (mcasp-version == MCASP_VERSION_4)
+ if (mcasp-version = MCASP_VERSION_3)
+ /* Using dmaengine PCM */
snd_soc_dai_set_dma_data(dai, substream,
mcasp-dma_data[substream-stream]);
else
+ /* Using davinci-pcm */
snd_soc_dai_set_dma_data(dai, substream, mcasp-dma_params);
return 0;
@@ -1154,12 +1157,28 @@ static int davinci_mcasp_probe(struct platform_device
*pdev)
if (ret != 0)
goto err_release_clk;
- if (mcasp-version != MCASP_VERSION_4) {
+ /* Based on the McASP version use different platform driver */
+ switch (mcasp-version) {
+ case MCASP_VERSION_1:
+ case MCASP_VERSION_2:
ret = davinci_soc_platform_register(pdev-dev);
- if (ret) {
- dev_err(pdev-dev, register PCM failed: %d\n, ret);
- goto err_unregister_component;
- }
+ break;
+ case MCASP_VERSION_3:
+ ret = edma_pcm_platform_register(pdev-dev);
+ break;
+ case MCASP_VERSION_4:
+ /* Using omap-pcm as platform driver */
+ break;
+ default:
+ dev_err(pdev-dev, Invalid McASP version: %d\n,
+ mcasp-version);
+ ret = -EINVAL;
+ break;
+ }
+
+ if (ret) {
+ dev_err(pdev-dev, register PCM failed: %d\n, ret);
+ goto err_unregister_component;
}
return 0;
@@ -1177,8 +1196,21 @@ static int davinci_mcasp_remove(struct platform_device
*pdev)
struct davinci_mcasp *mcasp = dev_get_drvdata(pdev-dev);
snd_soc_unregister_component(pdev-dev);
- if (mcasp-version != MCASP_VERSION_4)
+
+ switch (mcasp-version) {
+ case MCASP_VERSION_1:
+ case MCASP_VERSION_2:
davinci_soc_platform_unregister(pdev-dev);
+ break;
+ case MCASP_VERSION_3:
+ edma_pcm_platform_unregister(pdev-dev);
+ break;
+ case MCASP_VERSION_4:
+ /* Using omap-pcm as platform driver */
+ break;
+ default:
+ break;
+ }
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/18] dma: edma: Add channel number to debug prints
It helps to identify issues if we have some information regarding to the
channel which the event is associated.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 07ac5f4eeb56..47abaac7eb18 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -185,7 +185,8 @@ static void edma_execute(struct edma_chan *echan)
edma_resume(echan-ch_num);
if (edesc-processed = MAX_NR_SG) {
- dev_dbg(dev, first transfer starting %d\n, echan-ch_num);
+ dev_dbg(dev, first transfer starting on channel %d\n,
+ echan-ch_num);
edma_start(echan-ch_num);
}
@@ -195,7 +196,7 @@ static void edma_execute(struct edma_chan *echan)
* MAX_NR_SG
*/
if (echan-missed) {
- dev_dbg(dev, missed event in execute detected\n);
+ dev_dbg(dev, missed event on channel %d\n, echan-ch_num);
edma_clean_channel(echan-ch_num);
edma_stop(echan-ch_num);
edma_start(echan-ch_num);
@@ -732,7 +733,7 @@ static int edma_alloc_chan_resources(struct dma_chan *chan)
echan-alloced = true;
echan-slot[0] = echan-ch_num;
- dev_dbg(dev, allocated channel for %u:%u\n,
+ dev_dbg(dev, allocated channel %d for %u:%u\n, echan-ch_num,
EDMA_CTLR(echan-ch_num), EDMA_CHAN_SLOT(echan-ch_num));
return 0;
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/18] dma: edma: Reduce debug print verbosity for non verbose debugging
Do not print the paRAM information when verbose debugging is not asked and
also reduce the number of lines printed in edma_prep_dma_cyclic()
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index e4f4a0cef58c..e2aa42b8342f 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -141,7 +141,7 @@ static void edma_execute(struct edma_chan *echan)
for (i = 0; i nslots; i++) {
j = i + edesc-processed;
edma_write_slot(echan-slot[i], edesc-pset[j]);
- dev_dbg(echan-vchan.chan.device-dev,
+ dev_vdbg(echan-vchan.chan.device-dev,
\n pset[%d]:\n
chnum\t%d\n
slot\t%d\n
@@ -554,9 +554,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc-cyclic = 1;
edesc-pset_nr = nslots;
- dev_dbg(dev, %s: nslots=%d\n, __func__, nslots);
- dev_dbg(dev, %s: period_len=%d\n, __func__, period_len);
- dev_dbg(dev, %s: buf_len=%d\n, __func__, buf_len);
+ dev_dbg(dev, %s: channel=%d nslots=%d period_len=%d buf_len=%d\n,
+ __func__, echan-ch_num, nslots, period_len, buf_len);
for (i = 0; i nslots; i++) {
/* Allocate a PaRAM slot, if needed */
@@ -590,8 +589,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
else
src_addr += period_len;
- dev_dbg(dev, %s: Configure period %d of buf:\n, __func__, i);
- dev_dbg(dev,
+ dev_vdbg(dev, %s: Configure period %d of buf:\n, __func__, i);
+ dev_vdbg(dev,
\n pset[%d]:\n
chnum\t%d\n
slot\t%d\n
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/18] DMA: edma: Use different eventq for cyclic channels
To improve latency with cyclic DMA operation it is preferred to use different eventq/tc than the default which is used by all other drivers (mmc, spi, i2c, etc). When preparing the cyclic dma ask for non default queue for the channel which is going to be used with cyclic mode. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/dma/edma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index 86d6a3fb0d92..604c7c94c731 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -624,6 +624,9 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic( edesc-pset[i].opt |= TCINTEN; } + /* Use different eventq/tc for cyclic DMA to reduce latency */ + edma_request_non_default_queue(echan-ch_num); + return vchan_tx_prep(echan-vchan, edesc-vdesc, tx_flags); } -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/18] dma: edma: Implement device_slave_caps callback
With the callback implemented omap-dma can provide information to client
drivers regarding to supported address widths, directions, residue
granularity, etc.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 604c7c94c731..1877319379fc 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -851,6 +851,23 @@ static void __init edma_chan_init(struct edma_cc *ecc,
}
}
+#define EDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static int edma_dma_device_slave_caps(struct dma_chan *dchan,
+ struct dma_slave_caps *caps)
+{
+ caps-src_addr_widths = EDMA_DMA_BUSWIDTHS;
+ caps-dstn_addr_widths = EDMA_DMA_BUSWIDTHS;
+ caps-directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+ caps-cmd_pause = true;
+ caps-cmd_terminate = true;
+ caps-residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
+
+ return 0;
+}
+
static void edma_dma_init(struct edma_cc *ecc, struct dma_device *dma,
struct device *dev)
{
@@ -861,6 +878,7 @@ static void edma_dma_init(struct edma_cc *ecc, struct
dma_device *dma,
dma-device_issue_pending = edma_issue_pending;
dma-device_tx_status = edma_tx_status;
dma-device_control = edma_control;
+ dma-device_slave_caps = edma_dma_device_slave_caps;
dma-dev = dev;
INIT_LIST_HEAD(dma-channels);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/18] arm: common: edma: Select event queue 1 as default when booted with DT
Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high priority channels, like audio. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/common/edma.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 86a8b263278f..19520e2519d9 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1546,7 +1546,8 @@ static int edma_of_parse_dt(struct device *dev, pdata-queue_priority_mapping = queue_priority_map; - pdata-default_queue = 0; + /* select queue 1 as default */ + pdata-default_queue = EVENTQ_1; prop = of_find_property(node, ti,edma-xbar-event-map, sz); if (prop) -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/18] arm: common: edma: API to request non default queue for a channel
When using eDMA3 via dmaengine all dma channels will use the default queue.
Since during request time we do not have means to change this it need to be done
later, before the DMA has been started.
With the added function it is possible to move the channel to a non default
queue if it is possible, otherwise (when only one EQ/TC is available for the CC)
the default queue is going to be used.
For example: For optimal system performance the audio (cyclic) DMA should
be placed to a separate queue which is different than what the rest of the
system is using.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 27 +++
include/linux/platform_data/edma.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index be267b2080be..eaf6dd19f082 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -712,6 +712,33 @@ int edma_alloc_channel(int channel,
}
EXPORT_SYMBOL(edma_alloc_channel);
+/**
+ * edma_request_non_default_queue - try to map the channel to non default queue
+ * @channel: dma channel returned from edma_alloc_channel()
+ *
+ * For certain type of applications like audio it is preferred to not use the
+ * default event queue/tc to avoid eDMA caused latency.
+ *
+ * This function will iterate through the event queues available for the CC and
+ * picks the first EQ/TC which is not set as the default for the CC
+ */
+void edma_request_non_default_queue(int channel)
+{
+ unsigned ctlr = EDMA_CTLR(channel);
+ enum dma_event_q eventq_no = EVENTQ_DEFAULT;
+ int i;
+
+ for (i = 0; i edma_cc[ctlr]-num_tc; i++) {
+ if (i != edma_cc[ctlr]-default_queue) {
+ eventq_no = i;
+ break;
+ }
+ }
+
+ channel = EDMA_CHAN_SLOT(channel);
+ map_dmach_queue(ctlr, channel, eventq_no);
+}
+EXPORT_SYMBOL(edma_request_non_default_queue);
/**
* edma_free_channel - deallocate DMA channel
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index 923f8a3e4ce0..5d0a1b98f205 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -117,6 +117,8 @@ int edma_alloc_channel(int channel,
void *data, enum dma_event_q);
void edma_free_channel(unsigned channel);
+void edma_request_non_default_queue(int channel);
+
/* alloc/free parameter RAM slots */
int edma_alloc_slot(unsigned ctlr, int slot);
void edma_free_slot(unsigned slot);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/18] arm: common: edma: Save the number of event queues/TCs
For later use save the number of queues available for the CC. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/common/edma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 19520e2519d9..be267b2080be 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1770,6 +1770,9 @@ static int edma_probe(struct platform_device *pdev) map_queue_tc(j, queue_tc_mapping[i][0], queue_tc_mapping[i][1]); + /* Save the number of TCs */ + edma_cc[j]-num_tc = i; + /* Event queue priority mapping */ for (i = 0; queue_priority_mapping[i][0] != -1; i++) assign_priority_to_queue(j, -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/18] platform_data: edma: Be precise with the paRAM struct
The edmacc_param struct should follow the layout of the paRAM area in the
HW. Be explicit on the size of the fields (u32) and also mark the struct
as packed to avoid any padding on non 32bit architectures.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/linux/platform_data/edma.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index f50821cb64be..923f8a3e4ce0 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -43,15 +43,15 @@
/* PaRAM slots are laid out like this */
struct edmacc_param {
- unsigned int opt;
- unsigned int src;
- unsigned int a_b_cnt;
- unsigned int dst;
- unsigned int src_dst_bidx;
- unsigned int link_bcntrld;
- unsigned int src_dst_cidx;
- unsigned int ccnt;
-};
+ u32 opt;
+ u32 src;
+ u32 a_b_cnt;
+ u32 dst;
+ u32 src_dst_bidx;
+ u32 link_bcntrld;
+ u32 src_dst_cidx;
+ u32 ccnt;
+} __packed;
/* fields in edmacc_param.opt */
#define SAMBIT(0)
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/18] dma: edma: Simplify direction configuration in edma_config_pset()
We only support DEV_TO_MEM or MEM_TO_DEV directions with edma driver and the
check for the direction has been already done in the function calling
edma_config_pset().
The error reporting is redundant and also the else if () can be removed.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 1877319379fc..e4f4a0cef58c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -368,14 +368,12 @@ static int edma_config_pset(struct dma_chan *chan, struct
edmacc_param *pset,
src_cidx = cidx;
dst_bidx = 0;
dst_cidx = 0;
- } else if (direction == DMA_DEV_TO_MEM) {
+ } else {
+ /* DMA_DEV_TO_MEM */
src_bidx = 0;
src_cidx = 0;
dst_bidx = acnt;
dst_cidx = cidx;
- } else {
- dev_err(dev, %s: direction not implemented yet\n, __func__);
- return -EINVAL;
}
pset-opt = EDMA_TCC(EDMA_CHAN_SLOT(echan-ch_num));
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/18] edma/ASoC: dmaengine PCM for AM335x and AM447x
Hi, With this series AM335x and AM447x will use the dmaengine PCM for audio. The daVinci devices will keep using the davinci-pcm for now since I do not have means to test them but the code is written in a way that they can be switched to use the edma-pcm easily (DA850/OMAP-L138 has been tested and audio was working fine). To be able to use the dmaengine PCM I needed to make changes to the edma code in arch/arm/common/ and in drivers/dma/ : Adding support for DMA pause/resume Possibility to select non default event queue/TC for cyclic (audio) dma channels: all devices using the eDMA via dmaengine was assigned to the default EQ/TC (mmc, i2c, spi, etc, and audio). This is not optimal from system performance point of view since sharing the same EQ/TC can cause latency spikes for cyclic channels (long DMA transfers for MMC for example). While debugging the edma to get things sorted out I noticed that the debug was too verbose and the important information was hidden even when the we did not asked for verbose dmaengine debug. I have included some debug cleanups for the edma dmaengine driver also. On the ASoC side: the series has been tested on AM335x and AM447x. I have report that DA850/OMAP-L138 works with this series (which boots w/o DT). Regards, Peter --- Peter Ujfalusi (18): platform_data: edma: Be precise with the paRAM struct dma: edma: Add support for DMA_PAUSE/RESUME operation dma: edma: Set DMA_CYCLIC capability flag arm: common: edma: Select event queue 1 as default when booted with DT arm: common: edma: Save the number of event queues/TCs arm: common: edma: API to request non default queue for a channel DMA: edma: Use different eventq for cyclic channels dma: edma: Implement device_slave_caps callback dma: edma: Simplify direction configuration in edma_config_pset() dma: edma: Reduce debug print verbosity for non verbose debugging dma: edma: Prefix debug prints where the text were identical in prep callbacks dma: edma: Add channel number to debug prints dma: edma: Print the direction value as well when it is not supported ASoC: davinci: Add edma dmaengine platform driver ASoC: davinci-mcasp: Use dmaengine based platform driver for AM335x/447x ASoC: davinci-mcasp: Provide correct filter_data for dmaengine for non-DT boot ASoC: davinci-mcasp: Assign the dma_data earlier in dai_probe callback ASoC: davinci-mcasp: Place constraint on the period size based on FIFO config arch/arm/common/edma.c | 34 - drivers/dma/edma.c | 92 ++ include/linux/platform_data/edma.h | 20 sound/soc/davinci/Kconfig | 1 + sound/soc/davinci/Makefile | 2 +- sound/soc/davinci/davinci-mcasp.c | 100 ++--- sound/soc/davinci/edma-pcm.c | 77 sound/soc/davinci/edma-pcm.h | 26 ++ 8 files changed, 303 insertions(+), 49 deletions(-) create mode 100644 sound/soc/davinci/edma-pcm.c create mode 100644 sound/soc/davinci/edma-pcm.h -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/18] dma: edma: Set DMA_CYCLIC capability flag
Indicate that the edma dmaengine driver has support for cyclic mode. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/common/edma.c | 1 + drivers/dma/edma.c | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 41bca32409fc..86a8b263278f 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1574,6 +1574,7 @@ static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev, return ERR_PTR(ret); dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); + dma_cap_set(DMA_CYCLIC, edma_filter_info.dma_cap); of_dma_controller_register(dev-of_node, of_dma_simple_xlate, edma_filter_info); diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index b54cd2dedde0..86d6a3fb0d92 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -887,6 +887,7 @@ static int edma_probe(struct platform_device *pdev) dma_cap_zero(ecc-dma_slave.cap_mask); dma_cap_set(DMA_SLAVE, ecc-dma_slave.cap_mask); + dma_cap_set(DMA_CYCLIC, ecc-dma_slave.cap_mask); edma_dma_init(ecc, ecc-dma_slave, pdev-dev); -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/18] dma: edma: Add support for DMA_PAUSE/RESUME operation
Pause/Resume can be used by the audio stack when the stream is paused/resumed
The edma platform code has support for this and the legacy audio stack used
this.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index cd04eb7b182e..b54cd2dedde0 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -240,6 +240,26 @@ static int edma_slave_config(struct edma_chan *echan,
return 0;
}
+static int edma_dma_pause(struct edma_chan *echan)
+{
+ /* Pause/Resume only allowed with cyclic mode */
+ if (!echan-edesc-cyclic)
+ return -EINVAL;
+
+ edma_pause(echan-ch_num);
+ return 0;
+}
+
+static int edma_dma_resume(struct edma_chan *echan)
+{
+ /* Pause/Resume only allowed with cyclic mode */
+ if (!echan-edesc-cyclic)
+ return -EINVAL;
+
+ edma_resume(echan-ch_num);
+ return 0;
+}
+
static int edma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
unsigned long arg)
{
@@ -255,6 +275,14 @@ static int edma_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd,
config = (struct dma_slave_config *)arg;
ret = edma_slave_config(echan, config);
break;
+ case DMA_PAUSE:
+ ret = edma_dma_pause(echan);
+ break;
+
+ case DMA_RESUME:
+ ret = edma_dma_resume(echan);
+ break;
+
default:
ret = -ENOSYS;
}
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] ARM: DTS: AM43x: Add DSS node
On 13/03/14 10:58, Sathya Prakash M R wrote:
Add device node for DSS module for AM4372. Both the
AM437x-Gp evm and Am43x-Epos evm use the same LCD panel.
The lcd timings are added in respective dts files.
Adds display pinctrl and enables required gpio.
Also set the right parent clock to the DSS clock.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/boot/dts/am4372.dtsi| 28 +
arch/arm/boot/dts/am437x-gp-evm.dts | 77
++
arch/arm/boot/dts/am43x-epos-evm.dts | 73
arch/arm/boot/dts/am43xx-clocks.dtsi |2 +
4 files changed, 180 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ea55a4e..b72a7df 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -684,6 +684,34 @@
num-cs = 4;
status = disabled;
};
+
+ dss: dss@4832A000 {
+ compatible = ti,omap3-dss, simple-bus;
+ reg = 0x4832A000 0x200;
+ ti,hwmods = dss_core;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@4832A400 {
+ compatible = ti,omap3-dispc;
+ reg = 0x4832A400 0x400;
+ interrupts = GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ };
+
+ dpi: encoder@0 {
+ compatible = ti,omap3-dpi;
+ };
+
+ rfbi: rfbi@4832A800 {
+ compatible = ti,omap3-rfbi;
+ reg = 0x4832A800 0x100;
+ ti,hwmods = dss_rfbi;
+ };
+
+ };
+
This seems to be based on old version of the DSS DT. Please rebase this
on top of the latest one:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
You also need to split this into smaller pieces: the dts clock fix, the
am4372.dtsi, and the board changes.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 2/4] ARM: AM43xx: fix dpll init in bypass mode
On 13/03/14 10:58, Sathya Prakash M R wrote: From: Tomi Valkeinen tomi.valkei...@ti.com On AM43xx, if a PLL is in bypass at kernel init, the code in omap2_get_dpll_rate() will not realize this and will try to calculate the clock rate using the multiplier and the divider, resulting in errors. omap2_init_dpll_parent() has similar issue. Add the missing soc_is_am43xx() check to make the code work on AM43xx. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com I see you sent this already in December, and Paul asked for your signed-off for it, but you never replied. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 4/4] ARM: DTS: AM43x: Add DSS node
On Thursday 13 March 2014 03:51 PM, Tomi Valkeinen wrote:
On 13/03/14 10:58, Sathya Prakash M R wrote:
Add device node for DSS module for AM4372. Both the
AM437x-Gp evm and Am43x-Epos evm use the same LCD panel.
The lcd timings are added in respective dts files.
Adds display pinctrl and enables required gpio.
Also set the right parent clock to the DSS clock.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/boot/dts/am4372.dtsi| 28 +
arch/arm/boot/dts/am437x-gp-evm.dts | 77 ++
arch/arm/boot/dts/am43x-epos-evm.dts | 73
arch/arm/boot/dts/am43xx-clocks.dtsi |2 +
4 files changed, 180 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ea55a4e..b72a7df 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -684,6 +684,34 @@
num-cs = 4;
status = disabled;
};
+
+ dss: dss@4832A000 {
+ compatible = ti,omap3-dss, simple-bus;
+ reg = 0x4832A000 0x200;
+ ti,hwmods = dss_core;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@4832A400 {
+ compatible = ti,omap3-dispc;
+ reg = 0x4832A400 0x400;
+ interrupts = GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ };
+
+ dpi: encoder@0 {
+ compatible = ti,omap3-dpi;
+ };
+
+ rfbi: rfbi@4832A800 {
+ compatible = ti,omap3-rfbi;
+ reg = 0x4832A800 0x100;
+ ti,hwmods = dss_rfbi;
+ };
+
+ };
+
This seems to be based on old version of the DSS DT. Please rebase this
on top of the latest one:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
Thanks. maybe i missed couple of changes. Will do that.
You also need to split this into smaller pieces: the dts clock fix, the
am4372.dtsi, and the board changes.
ok sure.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] ARM: AM43xx: fix dpll init in bypass mode
On Thursday 13 March 2014 03:54 PM, Tomi Valkeinen wrote: On 13/03/14 10:58, Sathya Prakash M R wrote: From: Tomi Valkeinen tomi.valkei...@ti.com On AM43xx, if a PLL is in bypass at kernel init, the code in omap2_get_dpll_rate() will not realize this and will try to calculate the clock rate using the multiplier and the divider, resulting in errors. omap2_init_dpll_parent() has similar issue. Add the missing soc_is_am43xx() check to make the code work on AM43xx. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com I see you sent this already in December, and Paul asked for your signed-off for it, but you never replied. just saw. Maybe i missed it during december vacation. Will update it in v3 alongwith other changes you suggested. Tomi Sathya -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] doc: Add ti,am437x-dwc3 comaptible for dwc3 glue
Hi George, On 03/07/2014 01:56 PM, George Cherian wrote: Add the compatible ti,am437x-dwc3 for dwc3 glue driver. Signed-off-by: George Cherian george.cher...@ti.com --- Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 38b2fae..38d9bb8 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -44,7 +44,9 @@ Board specific device node entry }; OMAP DWC3 GLUE - - compatible : Should be ti,dwc3 + - compatible : Should be + * ti,dwc3 for OMAP5 and DRA7 + * ti,am437x-dwc3 for AM437x Why do you need a new compatible for am437x? Isn't ti,dwc3 sufficient? - ti,hwmods : Should be usb_otg_ss - reg : Address and length of the register set for the device. - interrupts : The irq number of this device that is used to interrupt the cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/5] ARM: dts: am43xx clock data
Hi George,
On 03/07/2014 01:56 PM, George Cherian wrote:
Add USB reference clock data
Signed-off-by: George Cherian george.cher...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..506d036 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -653,4 +653,21 @@
clocks = clk_32768_ck, clk_32k_tpm_ck;
reg = 0x4260;
};
+
+ usb_otg_ss0_refclk960m: usb_otg_ss0_refclk960m {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_clkdcoldo;
+ ti,bit-shift = 8;
+ reg = 0x8a60;
+ };
+
+ usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_clkdcoldo;
+ ti,bit-shift = 8;
+ reg = 0x8a68;
+ };
+
};
I was reviewing am43xx usb clock information recently and found out that
PHY clock is missing here. e.g. usb_phy0_always_on_clk32k and
usb_phy1_always_on_clk32k.
Can you please add these clocks?
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 14/18] ASoC: davinci: Add edma dmaengine platform driver
On 03/13/2014 10:18 AM, Peter Ujfalusi wrote:
[...]
+static const struct snd_pcm_hardware edma_pcm_hardware = {
+ .info = SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID |
+ SNDRV_PCM_INFO_BATCH |
+ SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME |
+ SNDRV_PCM_INFO_INTERLEAVED,
+ .buffer_bytes_max = 128 * 1024,
+ .period_bytes_min = 32,
+ .period_bytes_max = 64 * 1024,
+ .periods_min= 2,
+ .periods_max= 19, /* Limit by edma dmaengine driver */
+};
The idea is that we can auto-discover all the things using the
dma_slave_caps API. Too bad we removed the possibility to specify the
maximum number of segments from the API. Maybe we need to add it back. Is
the 19 a hard-limit or could it be worked around by software in the
dmaengine driver?
+
+static const struct snd_dmaengine_pcm_config edma_dmaengine_pcm_config = {
+ .pcm_hardware = edma_pcm_hardware,
+ .prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
+ .prealloc_buffer_size = 128 * 1024,
Unless there is a very good reason for exactly this size, just leave it 0
and let the generic dmaengine driver use the default.
+};
+
+static const struct snd_dmaengine_pcm_config edma_compat_dmaengine_pcm_config
= {
+ .pcm_hardware = edma_pcm_hardware,
+ .prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
+ .compat_filter_fn = edma_filter_fn,
+ .prealloc_buffer_size = 128 * 1024,
+};
There is no need for different configs for DT and non-DT.
+
+int edma_pcm_platform_register(struct device *dev)
+{
+ if (dev-of_node)
+ return snd_dmaengine_pcm_register(dev,
+ edma_dmaengine_pcm_config,
+ SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
Since the edma dmaengine driver implements the slave cap API there is no
need to manually specify SND_DMAENGINE_PCM_FLAG_NO_RESIDUE manually. But
since the edma driver sets the granularity to
DMA_RESIDUE_GRANULARITY_DESCRIPTOR in this case the generic dmaengine will
not set SND_DMAENGINE_PCM_FLAG_NO_RESIDUE automatically since it assumes
that the dmaengine driver is capable of properly reporting the DMA position.
+ else
+ return snd_dmaengine_pcm_register(dev,
+ edma_compat_dmaengine_pcm_config,
+ SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
+ SND_DMAENGINE_PCM_FLAG_NO_DT |
+ SND_DMAENGINE_PCM_FLAG_COMPAT);
If you set the flags to just SND_DMAENGINE_PCM_FLAG_COMPAT it will do the
right thing in the generic dmaengine driver depending on whether
dev-of_node is set or not.
There is also a devm_ version of snd_dmaengine_pcm_register() it probably
makes sense to use it here.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] ARM: dts: AM4372: Add USB nodes
On 03/07/2014 01:57 PM, George Cherian wrote:
Add nodes for 2 instances each of
- ocp2scp
- USB PHY control module
- USB PHY
- dwc3_omap
- USB
for AM43xx.
Signed-off-by: George Cherian george.cher...@ti.com
Acked-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 95
+++
1 file changed, 95 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 5a7cc38..fdcdf1b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -698,6 +698,101 @@
edma 11;
dma-names = tx, rx;
};
+
+ am43xx_control_usb2phy1: control-phy@44e10620 {
+ compatible = ti,control-phy-usb2-am437;
+ reg = 0x44e10620 0x4;
+ reg-names = power;
+ };
+
+ am43xx_control_usb2phy2: control-phy@0x44e10628 {
+ compatible = ti,control-phy-usb2-am437;
+ reg = 0x44e10628 0x4;
+ reg-names = power;
+ };
+
+ ocp2scp0: ocp2scp@483a8000 {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ocp2scp0;
+
+ usb2_phy1: phy@483a8000 {
+ compatible = ti,am437x-usb2;
+ reg = 0x483a8000 0x8000;
+ ctrl-module = am43xx_control_usb2phy1;
+ clocks = clk_32768_ck,
shouldn't the PHY wakeup clock be usb_phy0_always_on_clk32k?
+ usb_otg_ss0_refclk960m;
+ clock-names = wkupclk, refclk;
+ #phy-cells = 0;
+ status = disabled;
+ };
+ };
+
+ ocp2scp1: ocp2scp@483e8000 {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ocp2scp1;
+
+ usb2_phy2: phy@483e8000 {
+ compatible = ti,am437x-usb2;
+ reg = 0x483e8000 0x8000;
+ ctrl-module = am43xx_control_usb2phy2;
+ clocks = clk_32768_ck,
usb_phy1_always_on_clk32k here?
+ usb_otg_ss1_refclk960m;
+ clock-names = wkupclk, refclk;
+ #phy-cells = 0;
+ status = disabled;
+ };
+ };
+
+ dwc3_1: omap_dwc3@4838 {
+ compatible = ti,am437x-dwc3;
+ ti,hwmods = usb_otg_ss0;
+ reg = 0x4838 0x1;
+ interrupts = GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH;
+ #address-cells = 1;
+ #size-cells = 1;
+ utmi-mode = 1;
+ ranges;
+
+ usb1: usb@4839 {
+ compatible = synopsys,dwc3;
+ reg = 0x4839 0x17000;
+ interrupts = GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH;
+ phys = usb2_phy1;
+ phy-names = usb2-phy;
+ maximum-speed = high-speed;
+ dr_mode = otg;
+ status = disabled;
+ };
+ };
+
+ dwc3_2: omap_dwc3@483c {
+ compatible = ti,am437x-dwc3;
+ ti,hwmods = usb_otg_ss1;
+ reg = 0x483c 0x1;
+ interrupts = GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH;
+ #address-cells = 1;
+ #size-cells = 1;
+ utmi-mode = 1;
+ ranges;
+
+ usb2: usb@483d {
+ compatible = synopsys,dwc3;
+ reg = 0x483d 0x17000;
+ interrupts = GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH;
+ phys = usb2_phy2;
+ phy-names = usb2-phy;
+ maximum-speed = high-speed;
+ dr_mode = otg;
+ status = disabled;
+ };
+ };
+
};
};
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [PATCH v3 4/5] ARM: dts: am437x-gp-evm: Enable USB
On 03/07/2014 01:57 PM, George Cherian wrote:
Enable
- ocp2scp
- USB PHY control module
- USB PHY
- dwc3_omap
- USB
for am437x-gp-evm
Signed-off-by: George Cherian george.cher...@ti.com
Acked-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 4eb72b8..347d367 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -98,3 +98,21 @@
gpio4 {
status = okay;
};
+
+usb2_phy1 {
+ status = okay;
+};
+
+usb1 {
+ dr_mode = peripheral;
+ status = okay;
+};
+
+usb2_phy2 {
+ status = okay;
+};
+
+usb2 {
+ dr_mode = host;
+ status = okay;
+};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] ARM: dts: am43x-epos-evm: Enable USB
On 03/07/2014 01:57 PM, George Cherian wrote:
Enable
- ocp2scp
- USB PHY control module
- USB PHY
- dwc3_omap
- USB
we are not enabling PHY control module here.
for am43x-epos-evm
Signed-off-by: George Cherian george.cher...@ti.com
With the description change.
Acked-by: Roger Quadros rog...@ti.com
cheers,
-roger
---
arch/arm/boot/dts/am43x-epos-evm.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index a7d0db1..0ced342 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -251,3 +251,21 @@
pinctrl-0 = spi1_pins;
status = okay;
};
+
+usb2_phy1 {
+ status = okay;
+};
+
+usb1 {
+ dr_mode = peripheral;
+ status = okay;
+};
+
+usb2_phy2 {
+ status = okay;
+};
+
+usb2 {
+ dr_mode = host;
+ status = okay;
+};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] doc: Add ti,am437x-dwc3 comaptible for dwc3 glue
On 3/13/2014 4:02 PM, Roger Quadros wrote: Hi George, On 03/07/2014 01:56 PM, George Cherian wrote: Add the compatible ti,am437x-dwc3 for dwc3 glue driver. Signed-off-by: George Cherian george.cher...@ti.com --- Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 38b2fae..38d9bb8 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -44,7 +44,9 @@ Board specific device node entry }; OMAP DWC3 GLUE - - compatible : Should be ti,dwc3 + - compatible : Should be + * ti,dwc3 for OMAP5 and DRA7 + * ti,am437x-dwc3 for AM437x Why do you need a new compatible for am437x? Isn't ti,dwc3 sufficient? There is change in register offsets for AM437x as comapred to Omap5 and dra7x. The compatible is already added in dwc3-omap.c This patch just updates the Documentation. - ti,hwmods : Should be usb_otg_ss - reg : Address and length of the register set for the device. - interrupts : The irq number of this device that is used to interrupt the cheers, -roger -- -George -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 00/14] v4l: ti-vpe: Some VPE fixes and enhancements
This patch set mainly consists of minor fixes for the VPE driver. These fixes ensure the following: - The VPE module can be inserted and removed successively. - Make sure that smaller resolutions like qcif work correctly. - Prevent race condition between firmware loading and an open call to the v4l2 device. - Prevent the possibility of output m2m queue not having sufficient 'ready' buffers. - Some VPDMA data descriptor fields weren't understood correctly before. They are now used correctly. The rest of the patches add some minor features like DMA buf support and cropping/composing. Reference branch: g...@github.com:boddob/linux.git vpe_for_315 Changes in v4: - More legible code for selection API - Stricter checking for target type vs crop type in g_selection - Minor fix in patch 13/14, there was a logical bug in buf_prepare when checking validity of top and bottom fields. Changes in v3: - improvements in selection API patch. - querycap fixes for v4l2 compliance. - v4l2_buffer 'field' and flags' fixes for compliance. - fixes in try_fmt vpe_open for compliance. - rename a IOMEM resource for better DT compatibility. Changes in v2: - selection API used instead of older cropping API. - Typo fix. - Some changes in patch 6/7 to support composing on the capture side of VPE. Archit Taneja (14): v4l: ti-vpe: Make sure in job_ready that we have the needed number of dst_bufs v4l: ti-vpe: register video device only when firmware is loaded v4l: ti-vpe: Use video_device_release_empty v4l: ti-vpe: Allow DMABUF buffer type support v4l: ti-vpe: Allow usage of smaller images v4l: ti-vpe: Fix some params in VPE data descriptors v4l: ti-vpe: Add selection API in VPE driver v4l: ti-vpe: Rename csc memory resource name v4l: ti-vpe: report correct capabilities in querycap v4l: ti-vpe: Use correct bus_info name for the device in querycap v4l: ti-vpe: Fix initial configuration queue data v4l: ti-vpe: zero out reserved fields in try_fmt v4l: ti-vpe: Set correct field parameter for output and capture buffers v4l: ti-vpe: retain v4l2_buffer flags for captured buffers drivers/media/platform/ti-vpe/csc.c | 2 +- drivers/media/platform/ti-vpe/vpdma.c | 68 ++--- drivers/media/platform/ti-vpe/vpdma.h | 17 ++- drivers/media/platform/ti-vpe/vpe.c | 272 -- 4 files changed, 290 insertions(+), 69 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 14/14] v4l: ti-vpe: retain v4l2_buffer flags for captured buffers
The dequed CAPTURE_MPLANE type buffers don't contain the flags that the
originally queued OUTPUT_MPLANE type buffers have. This breaks compliance.
Copy the source v4l2_buffer flags to the destination v4l2_buffer flags before
they are dequed.
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 362d5be..972f43f 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1288,13 +1288,12 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
s_buf = s_vb-v4l2_buf;
d_buf = d_vb-v4l2_buf;
+ d_buf-flags = s_buf-flags;
+
d_buf-timestamp = s_buf-timestamp;
- d_buf-flags = ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
- d_buf-flags |= s_buf-flags V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
- if (s_buf-flags V4L2_BUF_FLAG_TIMECODE) {
- d_buf-flags |= V4L2_BUF_FLAG_TIMECODE;
+ if (s_buf-flags V4L2_BUF_FLAG_TIMECODE)
d_buf-timecode = s_buf-timecode;
- }
+
d_buf-sequence = ctx-sequence;
d_q_data = ctx-q_data[Q_DATA_DST];
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 12/14] v4l: ti-vpe: zero out reserved fields in try_fmt
Zero out the reserved formats in v4l2_pix_format_mplane and
v4l2_plane_pix_format members of the returned v4l2_format pointer when passed
through TRY_FMT ioctl.
This ensures that the user doesn't interpret the non-zero fields as some data
passed by the driver, and ensures compliance.
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index d7befb9..c0ae847 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1488,6 +1488,7 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, struct
v4l2_format *f,
}
}
+ memset(pix-reserved, 0, sizeof(pix-reserved));
for (i = 0; i pix-num_planes; i++) {
plane_fmt = pix-plane_fmt[i];
depth = fmt-vpdma_fmt[i]-depth;
@@ -1499,6 +1500,8 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, struct
v4l2_format *f,
plane_fmt-sizeimage =
(pix-height * pix-width * depth) 3;
+
+ memset(plane_fmt-reserved, 0, sizeof(plane_fmt-reserved));
}
return 0;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 02/14] v4l: ti-vpe: register video device only when firmware is loaded
vpe fops(vpe_open in particular) should be called only when VPDMA firmware
is loaded. File operations on the video device are possible the moment it is
registered.
Currently, we register the video device for VPE at driver probe, after calling
a vpdma helper to initialize VPDMA and load firmware. This function is
non-blocking(it calls request_firmware_nowait()), and doesn't ensure that the
firmware is actually loaded when it returns.
We remove the device registration from vpe probe, and move it to a callback
provided by the vpe driver to the vpdma library, through vpdma_create().
The ready field in vpdma_data is no longer needed since we always have firmware
loaded before the device is registered.
A minor problem with this approach is that if the video_register_device
fails(which doesn't really happen), the vpe platform device would be registered.
however, there won't be any v4l2 device corresponding to it.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpdma.c | 8 +++--
drivers/media/platform/ti-vpe/vpdma.h | 7 +++--
drivers/media/platform/ti-vpe/vpe.c | 55 ---
3 files changed, 41 insertions(+), 29 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
index e8175e7..73dd38e 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -781,7 +781,7 @@ static void vpdma_firmware_cb(const struct firmware *f,
void *context)
/* already initialized */
if (read_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
VPDMA_LIST_RDY_SHFT)) {
- vpdma-ready = true;
+ vpdma-cb(vpdma-pdev);
return;
}
@@ -811,7 +811,7 @@ static void vpdma_firmware_cb(const struct firmware *f,
void *context)
goto free_buf;
}
- vpdma-ready = true;
+ vpdma-cb(vpdma-pdev);
free_buf:
vpdma_unmap_desc_buf(vpdma, fw_dma_buf);
@@ -839,7 +839,8 @@ static int vpdma_load_firmware(struct vpdma_data *vpdma)
return 0;
}
-struct vpdma_data *vpdma_create(struct platform_device *pdev)
+struct vpdma_data *vpdma_create(struct platform_device *pdev,
+ void (*cb)(struct platform_device *pdev))
{
struct resource *res;
struct vpdma_data *vpdma;
@@ -854,6 +855,7 @@ struct vpdma_data *vpdma_create(struct platform_device
*pdev)
}
vpdma-pdev = pdev;
+ vpdma-cb = cb;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, vpdma);
if (res == NULL) {
diff --git a/drivers/media/platform/ti-vpe/vpdma.h
b/drivers/media/platform/ti-vpe/vpdma.h
index cf40f11..bf5f8bb 100644
--- a/drivers/media/platform/ti-vpe/vpdma.h
+++ b/drivers/media/platform/ti-vpe/vpdma.h
@@ -35,8 +35,8 @@ struct vpdma_data {
struct platform_device *pdev;
- /* tells whether vpdma firmware is loaded or not */
- bool ready;
+ /* callback to VPE driver when the firmware is loaded */
+ void (*cb)(struct platform_device *pdev);
};
enum vpdma_data_format_type {
@@ -208,6 +208,7 @@ void vpdma_set_frame_start_event(struct vpdma_data *vpdma,
void vpdma_dump_regs(struct vpdma_data *vpdma);
/* initialize vpdma, passed with VPE's platform device pointer */
-struct vpdma_data *vpdma_create(struct platform_device *pdev);
+struct vpdma_data *vpdma_create(struct platform_device *pdev,
+ void (*cb)(struct platform_device *pdev));
#endif
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index f3143ac..f1eae67 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1817,11 +1817,6 @@ static int vpe_open(struct file *file)
vpe_dbg(dev, vpe_open\n);
- if (!dev-vpdma-ready) {
- vpe_err(dev, vpdma firmware not loaded\n);
- return -ENODEV;
- }
-
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
@@ -2039,10 +2034,40 @@ static void vpe_runtime_put(struct platform_device
*pdev)
WARN_ON(r 0 r != -ENOSYS);
}
+static void vpe_fw_cb(struct platform_device *pdev)
+{
+ struct vpe_dev *dev = platform_get_drvdata(pdev);
+ struct video_device *vfd;
+ int ret;
+
+ vfd = dev-vfd;
+ *vfd = vpe_videodev;
+ vfd-lock = dev-dev_mutex;
+ vfd-v4l2_dev = dev-v4l2_dev;
+
+ ret = video_register_device(vfd, VFL_TYPE_GRABBER, 0);
+ if (ret) {
+ vpe_err(dev, Failed to register video device\n);
+
+ vpe_set_clock_enable(dev, 0);
+ vpe_runtime_put(pdev);
+ pm_runtime_disable(pdev-dev);
+ v4l2_m2m_release(dev-m2m_dev);
+ vb2_dma_contig_cleanup_ctx(dev-alloc_ctx);
+ v4l2_device_unregister(dev-v4l2_dev);
+
+ return;
+ }
+
+
[PATCH v4 10/14] v4l: ti-vpe: Use correct bus_info name for the device in querycap
The bus_info parameter in v4l2_capabilities expects a 'platform_' prefix. This
wasn't done in the driver and hence was breaking compliance. Update the bus_info
parameter accordingly.
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index c066eb8..3a312ea 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1346,7 +1346,8 @@ static int vpe_querycap(struct file *file, void *priv,
{
strncpy(cap-driver, VPE_MODULE_NAME, sizeof(cap-driver) - 1);
strncpy(cap-card, VPE_MODULE_NAME, sizeof(cap-card) - 1);
- strlcpy(cap-bus_info, VPE_MODULE_NAME, sizeof(cap-bus_info));
+ snprintf(cap-bus_info, sizeof(cap-bus_info), platform:%s,
+ VPE_MODULE_NAME);
cap-device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
return 0;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 06/14] v4l: ti-vpe: Fix some params in VPE data descriptors
Some parameters of the VPE descriptors were understood incorrectly. They are now
fixed. The fixes are explained as follows:
- When adding an inbound data descriptor to the VPDMA descriptor list, we intend
to use c_rect as the cropped region fetched by VPDMA. Therefore, c_rect-width
shouldn't be used to calculate the line stride, the original image width
should be used for that. We add a 'width' argument which gives the buffer
width in memory.
- frame_width and frame_height describe the complete width and height of the
client to which the channel is connected. If there are multiple channels
fetching data and providing to the same client, the above 2 arguments should
be the width and height of the region covered by all the channels. In the case
where there is only one channel providing pixel data to the client
(like in VPE), frame_width and frame_height should be the cropped width and
cropped height respectively. The calculation of these params is done in the
vpe driver now.
- start_h and start_v is also used in the case of multiple channels to describe
where each channel should start filling pixel data. We don't use this in VPE,
and pass 0s to the vpdma_add_in_dtd() helper.
- Some minor changes are made to the vpdma_add_out_dtd() helper. The c_rect
param is used for specifying the 'composition' target, and 'width' is added
to calculate the line stride.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpdma.c | 60 +++
drivers/media/platform/ti-vpe/vpdma.h | 10 +++---
drivers/media/platform/ti-vpe/vpe.c | 18 +++
3 files changed, 64 insertions(+), 24 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
index 73dd38e..a51a013 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -614,8 +614,17 @@ static void dump_dtd(struct vpdma_dtd *dtd)
/*
* append an outbound data transfer descriptor to the given descriptor list,
* this sets up a 'client to memory' VPDMA transfer for the given VPDMA channel
+ *
+ * @list: vpdma desc list to which we add this decriptor
+ * @width: width of the image in pixels in memory
+ * @c_rect: compose params of output image
+ * @fmt: vpdma data format of the buffer
+ * dma_addr: dma address as seen by VPDMA
+ * chan: VPDMA channel
+ * flags: VPDMA flags to configure some descriptor fileds
*/
-void vpdma_add_out_dtd(struct vpdma_desc_list *list, struct v4l2_rect *c_rect,
+void vpdma_add_out_dtd(struct vpdma_desc_list *list, int width,
+ const struct v4l2_rect *c_rect,
const struct vpdma_data_format *fmt, dma_addr_t dma_addr,
enum vpdma_channel chan, u32 flags)
{
@@ -623,6 +632,7 @@ void vpdma_add_out_dtd(struct vpdma_desc_list *list, struct
v4l2_rect *c_rect,
int field = 0;
int notify = 1;
int channel, next_chan;
+ struct v4l2_rect rect = *c_rect;
int depth = fmt-depth;
int stride;
struct vpdma_dtd *dtd;
@@ -630,11 +640,15 @@ void vpdma_add_out_dtd(struct vpdma_desc_list *list,
struct v4l2_rect *c_rect,
channel = next_chan = chan_info[chan].num;
if (fmt-type == VPDMA_DATA_FMT_TYPE_YUV
- fmt-data_type == DATA_TYPE_C420)
+ fmt-data_type == DATA_TYPE_C420) {
+ rect.height = 1;
+ rect.top = 1;
depth = 8;
+ }
- stride = ALIGN((depth * c_rect-width) 3, VPDMA_STRIDE_ALIGN);
- dma_addr += (c_rect-left * depth) 3;
+ stride = ALIGN((depth * width) 3, VPDMA_STRIDE_ALIGN);
+
+ dma_addr += rect.top * stride + (rect.left * depth 3);
dtd = list-next;
WARN_ON((void *)(dtd + 1) (list-buf.addr + list-buf.size));
@@ -664,31 +678,48 @@ void vpdma_add_out_dtd(struct vpdma_desc_list *list,
struct v4l2_rect *c_rect,
/*
* append an inbound data transfer descriptor to the given descriptor list,
* this sets up a 'memory to client' VPDMA transfer for the given VPDMA channel
+ *
+ * @list: vpdma desc list to which we add this decriptor
+ * @width: width of the image in pixels in memory(not the cropped width)
+ * @c_rect: crop params of input image
+ * @fmt: vpdma data format of the buffer
+ * dma_addr: dma address as seen by VPDMA
+ * chan: VPDMA channel
+ * field: top or bottom field info of the input image
+ * flags: VPDMA flags to configure some descriptor fileds
+ * frame_width/height: the complete width/height of the image presented to the
+ * client (this makes sense when multiple channels are
+ * connected to the same client, forming a larger frame)
+ * start_h, start_v: position where the given channel starts providing pixel
+ * data to the client (makes sense when multiple channels
+ * contribute to the client)
*/
-void vpdma_add_in_dtd(struct
[PATCH v4 03/14] v4l: ti-vpe: Use video_device_release_empty
The video_device struct is currently embedded in the driver data struct vpe_dev.
A vpe_dev instance is allocated by the driver, and the memory for the vfd is a
part of this struct.
The v4l2 core, however, manages the removal of the vfd region, through the
video_device's .release() op, which currently is the helper
video_device_release. This causes memory corruption, and leads to issues when
we try to re-insert the vpe module.
Use the video_device_release_empty helper function instead.
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index f1eae67..0363df6 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -2000,7 +2000,7 @@ static struct video_device vpe_videodev = {
.fops = vpe_fops,
.ioctl_ops = vpe_ioctl_ops,
.minor = -1,
- .release= video_device_release,
+ .release= video_device_release_empty,
.vfl_dir= VFL_DIR_M2M,
};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 09/14] v4l: ti-vpe: report correct capabilities in querycap
querycap currently returns V4L2_CAP_VIDEO_M2M as a capability, this should be V4L2_CAP_VIDEO_M2M_MPLANE instead, as the driver supports multiplanar formats. Reviewed-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Archit Taneja arc...@ti.com --- drivers/media/platform/ti-vpe/vpe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index f3f1c10..c066eb8 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -1347,7 +1347,7 @@ static int vpe_querycap(struct file *file, void *priv, strncpy(cap-driver, VPE_MODULE_NAME, sizeof(cap-driver) - 1); strncpy(cap-card, VPE_MODULE_NAME, sizeof(cap-card) - 1); strlcpy(cap-bus_info, VPE_MODULE_NAME, sizeof(cap-bus_info)); - cap-device_caps = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING; + cap-device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING; cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS; return 0; } -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 13/14] v4l: ti-vpe: Set correct field parameter for output and capture buffers
The vpe driver wasn't setting the correct field parameter for dequed CAPTURE
type buffers for the case where the captured output is progressive.
Set the field to V4L2_FIELD_NONE for the completed destination buffers when
the captured output is progressive.
For OUTPUT type buffers, a queued buffer's field is forced to V4L2_FIELD_NONE
if the pixel format(configured through s_fmt for the buffer type
V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE specifies) the field type isn't interlaced.
If the pixel format specified was V4L2_FIELD_ALTERNATE, and the queued buffer's
field isn't V4L2_FIELD_TOP or V4L2_FIELD_BOTTOM, the vb2 buf_prepare op returns
an error.
This ensures compliance, and that the dequeued output and captured buffers
contain the field type that the driver used internally.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index c0ae847..362d5be 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1296,10 +1296,10 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
d_buf-timecode = s_buf-timecode;
}
d_buf-sequence = ctx-sequence;
- d_buf-field = ctx-field;
d_q_data = ctx-q_data[Q_DATA_DST];
if (d_q_data-flags Q_DATA_INTERLACED) {
+ d_buf-field = ctx-field;
if (ctx-field == V4L2_FIELD_BOTTOM) {
ctx-sequence++;
ctx-field = V4L2_FIELD_TOP;
@@ -1308,6 +1308,7 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
ctx-field = V4L2_FIELD_BOTTOM;
}
} else {
+ d_buf-field = V4L2_FIELD_NONE;
ctx-sequence++;
}
@@ -1880,6 +1881,16 @@ static int vpe_buf_prepare(struct vb2_buffer *vb)
q_data = get_q_data(ctx, vb-vb2_queue-type);
num_planes = q_data-fmt-coplanar ? 2 : 1;
+ if (vb-vb2_queue-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ if (!(q_data-flags Q_DATA_INTERLACED)) {
+ vb-v4l2_buf.field = V4L2_FIELD_NONE;
+ } else {
+ if (vb-v4l2_buf.field != V4L2_FIELD_TOP
+ vb-v4l2_buf.field != V4L2_FIELD_BOTTOM)
+ return -EINVAL;
+ }
+ }
+
for (i = 0; i num_planes; i++) {
if (vb2_plane_size(vb, i) q_data-sizeimage[i]) {
vpe_err(ctx-dev,
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 11/14] v4l: ti-vpe: Fix initial configuration queue data
The vpe output and capture queues are initially configured to default values in vpe_open(). A G_FMT before any S_FMTs will result in these values being populated. The colorspace and bytesperline parameter of this initial configuration are incorrect. This breaks compliance when as we get 'TRY_FMT(G_FMT) != G_FMT'. Fix the initial queue configuration such that it wouldn't need to be fixed by try_fmt. Reviewed-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Archit Taneja arc...@ti.com --- drivers/media/platform/ti-vpe/vpe.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index 3a312ea..d7befb9 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -2021,9 +2021,11 @@ static int vpe_open(struct file *file) s_q_data-fmt = vpe_formats[2]; s_q_data-width = 1920; s_q_data-height = 1080; - s_q_data-sizeimage[VPE_LUMA] = (s_q_data-width * s_q_data-height * + s_q_data-bytesperline[VPE_LUMA] = (s_q_data-width * s_q_data-fmt-vpdma_fmt[VPE_LUMA]-depth) 3; - s_q_data-colorspace = V4L2_COLORSPACE_SMPTE170M; + s_q_data-sizeimage[VPE_LUMA] = (s_q_data-bytesperline[VPE_LUMA] * + s_q_data-height); + s_q_data-colorspace = V4L2_COLORSPACE_REC709; s_q_data-field = V4L2_FIELD_NONE; s_q_data-c_rect.left = 0; s_q_data-c_rect.top = 0; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 08/14] v4l: ti-vpe: Rename csc memory resource name
Rename the memory block resource vpe_csc to csc since it also exists within
the VIP IP block. This would make the name more generic, and both VPE and VIP DT
nodes in the future can use it.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/csc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/csc.c
b/drivers/media/platform/ti-vpe/csc.c
index acfea50..039 100644
--- a/drivers/media/platform/ti-vpe/csc.c
+++ b/drivers/media/platform/ti-vpe/csc.c
@@ -180,7 +180,7 @@ struct csc_data *csc_create(struct platform_device *pdev)
csc-pdev = pdev;
csc-res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
- vpe_csc);
+ csc);
if (csc-res == NULL) {
dev_err(pdev-dev, missing platform resources data\n);
return ERR_PTR(-ENODEV);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 04/14] v4l: ti-vpe: Allow DMABUF buffer type support
For OMAP and DRA7x, we generally allocate video and graphics buffers through omapdrm since the corresponding omap-gem driver provides DMM-Tiler backed contiguous buffers. omapdrm is a dma-buf exporter. These buffers are used by other drivers in the video pipeline. Add VB2_DMABUF flag to the io_modes of the vb2 output and capture queues. This allows the driver to import dma shared buffers. Reviewed-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Archit Taneja arc...@ti.com --- drivers/media/platform/ti-vpe/vpe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index 0363df6..0e7573a 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -1770,7 +1770,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq, memset(src_vq, 0, sizeof(*src_vq)); src_vq-type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE; - src_vq-io_modes = VB2_MMAP; + src_vq-io_modes = VB2_MMAP | VB2_DMABUF; src_vq-drv_priv = ctx; src_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer); src_vq-ops = vpe_qops; @@ -1783,7 +1783,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq, memset(dst_vq, 0, sizeof(*dst_vq)); dst_vq-type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; - dst_vq-io_modes = VB2_MMAP; + dst_vq-io_modes = VB2_MMAP | VB2_DMABUF; dst_vq-drv_priv = ctx; dst_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer); dst_vq-ops = vpe_qops; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 07/14] v4l: ti-vpe: Add selection API in VPE driver
Add selection ioctl ops. For VPE, cropping makes sense only for the input to
VPE(or V4L2_BUF_TYPE_VIDEO_OUTPUT/MPLANE buffers) and composing makes sense
only for the output of VPE(or V4L2_BUF_TYPE_VIDEO_CAPTURE/MPLANE buffers).
For the CAPTURE type, V4L2_SEL_TGT_COMPOSE results in VPE writing the output
in a rectangle within the capture buffer. For the OUTPUT type, V4L2_SEL_TGT_CROP
results in selecting a rectangle region within the source buffer.
Setting the crop/compose rectangles should successfully result in
re-configuration of registers which are affected when either source or
destination dimensions change, set_srcdst_params() is called for this purpose.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 150
1 file changed, 150 insertions(+)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index ece9b96..f3f1c10 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -410,8 +410,10 @@ static struct vpe_q_data *get_q_data(struct vpe_ctx *ctx,
{
switch (type) {
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
+ case V4L2_BUF_TYPE_VIDEO_OUTPUT:
return ctx-q_data[Q_DATA_SRC];
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
+ case V4L2_BUF_TYPE_VIDEO_CAPTURE:
return ctx-q_data[Q_DATA_DST];
default:
BUG();
@@ -1587,6 +1589,151 @@ static int vpe_s_fmt(struct file *file, void *priv,
struct v4l2_format *f)
return set_srcdst_params(ctx);
}
+static int __vpe_try_selection(struct vpe_ctx *ctx, struct v4l2_selection *s)
+{
+ struct vpe_q_data *q_data;
+
+ if ((s-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ (s-type != V4L2_BUF_TYPE_VIDEO_OUTPUT))
+ return -EINVAL;
+
+ q_data = get_q_data(ctx, s-type);
+ if (!q_data)
+ return -EINVAL;
+
+ switch (s-target) {
+ case V4L2_SEL_TGT_COMPOSE:
+ /*
+* COMPOSE target is only valid for capture buffer type, return
+* error for output buffer type
+*/
+ if (s-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ return -EINVAL;
+ break;
+ case V4L2_SEL_TGT_CROP:
+ /*
+* CROP target is only valid for output buffer type, return
+* error for capture buffer type
+*/
+ if (s-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+ break;
+ /*
+* bound and default crop/compose targets are invalid targets to
+* try/set
+*/
+ default:
+ return -EINVAL;
+ }
+
+ if (s-r.top 0 || s-r.left 0) {
+ vpe_err(ctx-dev, negative values for top and left\n);
+ s-r.top = s-r.left = 0;
+ }
+
+ v4l_bound_align_image(s-r.width, MIN_W, q_data-width, 1,
+ s-r.height, MIN_H, q_data-height, H_ALIGN, S_ALIGN);
+
+ /* adjust left/top if cropping rectangle is out of bounds */
+ if (s-r.left + s-r.width q_data-width)
+ s-r.left = q_data-width - s-r.width;
+ if (s-r.top + s-r.height q_data-height)
+ s-r.top = q_data-height - s-r.height;
+
+ return 0;
+}
+
+static int vpe_g_selection(struct file *file, void *fh,
+ struct v4l2_selection *s)
+{
+ struct vpe_ctx *ctx = file2ctx(file);
+ struct vpe_q_data *q_data;
+ bool use_c_rect = false;
+
+ if ((s-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ (s-type != V4L2_BUF_TYPE_VIDEO_OUTPUT))
+ return -EINVAL;
+
+ q_data = get_q_data(ctx, s-type);
+ if (!q_data)
+ return -EINVAL;
+
+ switch (s-target) {
+ case V4L2_SEL_TGT_COMPOSE_DEFAULT:
+ case V4L2_SEL_TGT_COMPOSE_BOUNDS:
+ if (s-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ return -EINVAL;
+ break;
+ case V4L2_SEL_TGT_CROP_BOUNDS:
+ case V4L2_SEL_TGT_CROP_DEFAULT:
+ if (s-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+ break;
+ case V4L2_SEL_TGT_COMPOSE:
+ if (s-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ return -EINVAL;
+ use_c_rect = true;
+ break;
+ case V4L2_SEL_TGT_CROP:
+ if (s-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+ use_c_rect = true;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (use_c_rect) {
+ /*
+* for CROP/COMPOSE target type, return c_rect params from the
+* respective buffer type
+*/
+ s-r = q_data-c_rect;
+ } else {
+ /*
+
[PATCH v4 01/14] v4l: ti-vpe: Make sure in job_ready that we have the needed number of dst_bufs
VPE has a ctrl parameter which decides how many mem to mem transactions the active job from the job queue can perform. The driver's job_ready() made sure that the number of ready source buffers are sufficient for the job to execute successfully. But it didn't make sure if there are sufficient ready destination buffers in the capture queue for the VPE output. If the time taken by VPE to process a single frame is really slow, then it's possible that we don't need to imply such a restriction on the dst queue, but really fast transactions(small resolution, no de-interlacing) may cause us to hit the condition where we don't have any free buffers for the VPE to write on. Add the extra check in job_ready() to make sure we have the sufficient amount of destination buffers. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/media/platform/ti-vpe/vpe.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index 7a77a5b..f3143ac 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -887,6 +887,9 @@ static int job_ready(void *priv) if (v4l2_m2m_num_src_bufs_ready(ctx-m2m_ctx) needed) return 0; + if (v4l2_m2m_num_dst_bufs_ready(ctx-m2m_ctx) needed) + return 0; + return 1; } -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 05/14] v4l: ti-vpe: Allow usage of smaller images
The minimum width and height for VPE input/output was kept as 128 pixels. VPE doesn't have a constraint on the image height, it requires the image width to be at least 16 bytes. Change the minimum supported dimensions to 32x32. This allows us to de-interlace qcif content. A smaller image size than 32x32 didn't make much sense, so stopped at this. Reviewed-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Archit Taneja arc...@ti.com --- drivers/media/platform/ti-vpe/vpe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index 0e7573a..dbdc338 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -49,8 +49,8 @@ #define VPE_MODULE_NAME vpe /* minimum and maximum frame sizes */ -#define MIN_W 128 -#define MIN_H 128 +#define MIN_W 32 +#define MIN_H 32 #define MAX_W 1920 #define MAX_H 1080 -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 02/14] v4l: ti-vpe: register video device only when firmware is loaded
Hi Archit,
From: Archit Taneja [mailto:arc...@ti.com]
Sent: Tuesday, March 11, 2014 9:34 AM
vpe fops(vpe_open in particular) should be called only when VPDMA
firmware is loaded. File operations on the video device are possible
the moment it is registered.
Currently, we register the video device for VPE at driver probe, after
calling a vpdma helper to initialize VPDMA and load firmware. This
function is non-blocking(it calls request_firmware_nowait()), and
doesn't ensure that the firmware is actually loaded when it returns.
We remove the device registration from vpe probe, and move it to a
callback provided by the vpe driver to the vpdma library, through
vpdma_create().
The ready field in vpdma_data is no longer needed since we always have
firmware loaded before the device is registered.
A minor problem with this approach is that if the video_register_device
fails(which doesn't really happen), the vpe platform device would be
registered.
however, there won't be any v4l2 device corresponding to it.
Could you explain to me one thing. request_firmware cannot be used in
probe, thus you are using request_firmware_nowait. Why cannot the firmware
be
loaded on open with a regular request_firmware that is waiting?
This patch seems to swap one problem for another. The possibility that open
fails (because firmware is not yet loaded) is swapped for a vague
possibility
that video_register_device.
Best wishes,
--
Kamil Debski
Samsung RD Institute Poland
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpdma.c | 8 +++--
drivers/media/platform/ti-vpe/vpdma.h | 7 +++--
drivers/media/platform/ti-vpe/vpe.c | 55 ---
3 files changed, 41 insertions(+), 29 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
index e8175e7..73dd38e 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -781,7 +781,7 @@ static void vpdma_firmware_cb(const struct firmware
*f, void *context)
/* already initialized */
if (read_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
VPDMA_LIST_RDY_SHFT)) {
- vpdma-ready = true;
+ vpdma-cb(vpdma-pdev);
return;
}
@@ -811,7 +811,7 @@ static void vpdma_firmware_cb(const struct firmware
*f, void *context)
goto free_buf;
}
- vpdma-ready = true;
+ vpdma-cb(vpdma-pdev);
free_buf:
vpdma_unmap_desc_buf(vpdma, fw_dma_buf); @@ -839,7 +839,8 @@
static int vpdma_load_firmware(struct vpdma_data *vpdma)
return 0;
}
-struct vpdma_data *vpdma_create(struct platform_device *pdev)
+struct vpdma_data *vpdma_create(struct platform_device *pdev,
+ void (*cb)(struct platform_device *pdev))
{
struct resource *res;
struct vpdma_data *vpdma;
@@ -854,6 +855,7 @@ struct vpdma_data *vpdma_create(struct
platform_device *pdev)
}
vpdma-pdev = pdev;
+ vpdma-cb = cb;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, vpdma);
if (res == NULL) {
diff --git a/drivers/media/platform/ti-vpe/vpdma.h
b/drivers/media/platform/ti-vpe/vpdma.h
index cf40f11..bf5f8bb 100644
--- a/drivers/media/platform/ti-vpe/vpdma.h
+++ b/drivers/media/platform/ti-vpe/vpdma.h
@@ -35,8 +35,8 @@ struct vpdma_data {
struct platform_device *pdev;
- /* tells whether vpdma firmware is loaded or not */
- bool ready;
+ /* callback to VPE driver when the firmware is loaded */
+ void (*cb)(struct platform_device *pdev);
};
enum vpdma_data_format_type {
@@ -208,6 +208,7 @@ void vpdma_set_frame_start_event(struct vpdma_data
*vpdma, void vpdma_dump_regs(struct vpdma_data *vpdma);
/* initialize vpdma, passed with VPE's platform device pointer */ -
struct vpdma_data *vpdma_create(struct platform_device *pdev);
+struct vpdma_data *vpdma_create(struct platform_device *pdev,
+ void (*cb)(struct platform_device *pdev));
#endif
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index f3143ac..f1eae67 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1817,11 +1817,6 @@ static int vpe_open(struct file *file)
vpe_dbg(dev, vpe_open\n);
- if (!dev-vpdma-ready) {
- vpe_err(dev, vpdma firmware not loaded\n);
- return -ENODEV;
- }
-
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
@@ -2039,10 +2034,40 @@ static void vpe_runtime_put(struct
platform_device *pdev)
WARN_ON(r 0 r != -ENOSYS);
}
+static void vpe_fw_cb(struct platform_device *pdev) {
+ struct vpe_dev *dev = platform_get_drvdata(pdev);
+ struct video_device *vfd;
+ int ret;
+
+ vfd = dev-vfd;
+ *vfd = vpe_videodev;
Re: [alsa-devel] [PATCH 14/18] ASoC: davinci: Add edma dmaengine platform driver
On 03/13/2014 12:28 PM, Lars-Peter Clausen wrote:
On 03/13/2014 10:18 AM, Peter Ujfalusi wrote: [...]
+static const struct snd_pcm_hardware edma_pcm_hardware = { +.info
= SNDRV_PCM_INFO_MMAP | + SNDRV_PCM_INFO_MMAP_VALID | +
SNDRV_PCM_INFO_BATCH | + SNDRV_PCM_INFO_PAUSE |
SNDRV_PCM_INFO_RESUME | + SNDRV_PCM_INFO_INTERLEAVED, +
.buffer_bytes_max= 128 * 1024, +.period_bytes_min= 32, +
.period_bytes_max= 64 * 1024, +.periods_min= 2, +
.periods_max= 19, /* Limit by edma dmaengine driver */ +};
The idea is that we can auto-discover all the things using the
dma_slave_caps API. Too bad we removed the possibility to specify the
maximum number of segments from the API. Maybe we need to add it back. Is
the 19 a hard-limit or could it be worked around by software in the
dmaengine driver?
The edma dmaengine driver will refuse to configure more than 20 paRAM slots (1
for the channel + 19 for the periods). Depending on the SoC we might have
different number of paRAM entries available. The intention with the limit was
to prevent cases when we run out of paRAM entires for other devices because
audio took most of them.
+ +static const struct snd_dmaengine_pcm_config edma_dmaengine_pcm_config
= { +.pcm_hardware = edma_pcm_hardware, +.prepare_slave_config =
snd_dmaengine_pcm_prepare_slave_config, +.prealloc_buffer_size = 128
* 1024,
Unless there is a very good reason for exactly this size, just leave it 0
and let the generic dmaengine driver use the default.
I'd rather keep this here. Since I have the .pcm_hardware the core will ignore
the snd_pcm_hardware.buffer_bytes_max when preallocating and it is in fact
going to go for:
prealloc_buffer_size = 512 * 1024;
max_buffer_size = SIZE_MAX;
While I have 128 * 1024 for the snd_pcm_hardware.buffer_bytes_max.
I think as long as I have the .pcm_hardware provided from the edma-pcm driver
I will have the .prealloc_buffer_size as well.
+}; + +static const struct snd_dmaengine_pcm_config
edma_compat_dmaengine_pcm_config = { +.pcm_hardware =
edma_pcm_hardware, +.prepare_slave_config =
snd_dmaengine_pcm_prepare_slave_config, +.compat_filter_fn =
edma_filter_fn, +.prealloc_buffer_size = 128 * 1024, +};
There is no need for different configs for DT and non-DT.
+ +int edma_pcm_platform_register(struct device *dev) +{ +if
(dev-of_node) +return snd_dmaengine_pcm_register(dev, +
edma_dmaengine_pcm_config, +
SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
Since the edma dmaengine driver implements the slave cap API there is no
need to manually specify SND_DMAENGINE_PCM_FLAG_NO_RESIDUE manually. But
since the edma driver sets the granularity to
DMA_RESIDUE_GRANULARITY_DESCRIPTOR in this case the generic dmaengine will
not set SND_DMAENGINE_PCM_FLAG_NO_RESIDUE automatically since it assumes
that the dmaengine driver is capable of properly reporting the DMA
position.
+else +return snd_dmaengine_pcm_register(dev, +
edma_compat_dmaengine_pcm_config, +
SND_DMAENGINE_PCM_FLAG_NO_RESIDUE | +
SND_DMAENGINE_PCM_FLAG_NO_DT | +
SND_DMAENGINE_PCM_FLAG_COMPAT);
If you set the flags to just SND_DMAENGINE_PCM_FLAG_COMPAT it will do the
right thing in the generic dmaengine driver depending on whether
dev-of_node is set or not.
I have missed these in the core. Makes the code simpler for sure.
There is also a devm_ version of snd_dmaengine_pcm_register() it probably
makes sense to use it here.
I forgot about the devm_ version. True, I'll use that instead.
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 14/18] ASoC: davinci: Add edma dmaengine platform driver
On 03/13/2014 12:56 PM, Peter Ujfalusi wrote:
On 03/13/2014 12:28 PM, Lars-Peter Clausen wrote:
On 03/13/2014 10:18 AM, Peter Ujfalusi wrote: [...]
+static const struct snd_pcm_hardware edma_pcm_hardware = { +.info
= SNDRV_PCM_INFO_MMAP | + SNDRV_PCM_INFO_MMAP_VALID | +
SNDRV_PCM_INFO_BATCH | + SNDRV_PCM_INFO_PAUSE |
SNDRV_PCM_INFO_RESUME | + SNDRV_PCM_INFO_INTERLEAVED, +
.buffer_bytes_max= 128 * 1024, +.period_bytes_min= 32, +
.period_bytes_max= 64 * 1024, +.periods_min= 2, +
.periods_max= 19, /* Limit by edma dmaengine driver */ +};
The idea is that we can auto-discover all the things using the
dma_slave_caps API. Too bad we removed the possibility to specify the
maximum number of segments from the API. Maybe we need to add it back. Is
the 19 a hard-limit or could it be worked around by software in the
dmaengine driver?
The edma dmaengine driver will refuse to configure more than 20 paRAM slots (1
for the channel + 19 for the periods). Depending on the SoC we might have
different number of paRAM entries available. The intention with the limit was
to prevent cases when we run out of paRAM entires for other devices because
audio took most of them.
The reason why we removed the max_segments field from the slave_caps struct
was because we though it should be possible to, even when the hardware only
supports a fixed amount of segments, emulate support for more in software.
If this is not the case with the edma, we need to bring this field back.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 02/14] v4l: ti-vpe: register video device only when firmware is loaded
Hi Kamil, On Thursday 13 March 2014 05:18 PM, Kamil Debski wrote: Hi Archit, From: Archit Taneja [mailto:arc...@ti.com] Sent: Tuesday, March 11, 2014 9:34 AM vpe fops(vpe_open in particular) should be called only when VPDMA firmware is loaded. File operations on the video device are possible the moment it is registered. Currently, we register the video device for VPE at driver probe, after calling a vpdma helper to initialize VPDMA and load firmware. This function is non-blocking(it calls request_firmware_nowait()), and doesn't ensure that the firmware is actually loaded when it returns. We remove the device registration from vpe probe, and move it to a callback provided by the vpe driver to the vpdma library, through vpdma_create(). The ready field in vpdma_data is no longer needed since we always have firmware loaded before the device is registered. A minor problem with this approach is that if the video_register_device fails(which doesn't really happen), the vpe platform device would be registered. however, there won't be any v4l2 device corresponding to it. Could you explain to me one thing. request_firmware cannot be used in probe, thus you are using request_firmware_nowait. Why cannot the firmware be loaded on open with a regular request_firmware that is waiting? I totally agree with you here. Placing the firmware in open() would probably make more sense. The reason I didn't place it in open() is because I didn't want to release firmware in a corresponding close(), and be in a situation where the firmware is loaded multiple times in the driver's lifetime. There are some reasons for doing this. First, it will require more testing with respect to whether the firmware is loaded correctly successive times :), the second is that loading firmware might probably take a bit of time, and we don't want to make applications too slow(I haven't measured the time taken, so I don't have a strong case for this either) This patch seems to swap one problem for another. The possibility that open fails (because firmware is not yet loaded) is swapped for a vague possibility that video_register_device. The driver will work fine in most cases even without this patch(apart from the possibility mentioned as above). We could discard this patch from this series, and I can work on a patch which moves firmware loading to the vpe_open() call, and hence solving the issue in the right manner. Does that sound fine? Thanks, Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/5] ARM: dts: am43xx clock data
On 3/13/2014 4:05 PM, Roger Quadros wrote:
Hi George,
On 03/07/2014 01:56 PM, George Cherian wrote:
Add USB reference clock data
Signed-off-by: George Cherian george.cher...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..506d036 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -653,4 +653,21 @@
clocks = clk_32768_ck, clk_32k_tpm_ck;
reg = 0x4260;
};
+
+ usb_otg_ss0_refclk960m: usb_otg_ss0_refclk960m {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_clkdcoldo;
+ ti,bit-shift = 8;
+ reg = 0x8a60;
+ };
+
+ usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_clkdcoldo;
+ ti,bit-shift = 8;
+ reg = 0x8a68;
+ };
+
};
I was reviewing am43xx usb clock information recently and found out that
PHY clock is missing here. e.g. usb_phy0_always_on_clk32k and
usb_phy1_always_on_clk32k.
Can you please add these clocks?
okay I will add those and resend the series.
cheers,
-roger
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] doc: Add ti,am437x-dwc3 comaptible for dwc3 glue
On 03/13/2014 01:41 PM, George Cherian wrote: On 3/13/2014 4:02 PM, Roger Quadros wrote: Hi George, On 03/07/2014 01:56 PM, George Cherian wrote: Add the compatible ti,am437x-dwc3 for dwc3 glue driver. Signed-off-by: George Cherian george.cher...@ti.com --- Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 38b2fae..38d9bb8 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -44,7 +44,9 @@ Board specific device node entry }; OMAP DWC3 GLUE - - compatible : Should be ti,dwc3 + - compatible : Should be +* ti,dwc3 for OMAP5 and DRA7 +* ti,am437x-dwc3 for AM437x Why do you need a new compatible for am437x? Isn't ti,dwc3 sufficient? There is change in register offsets for AM437x as comapred to Omap5 and dra7x. The compatible is already added in dwc3-omap.c This patch just updates the Documentation. Oh ok. Then it is fine. You can add my. Acked-by: Roger Quadros rog...@ti.com cheers, -roger - ti,hwmods : Should be usb_otg_ss - reg : Address and length of the register set for the device. - interrupts : The irq number of this device that is used to interrupt the cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] ASoC: tlv320aic31xx: Add basic codec driver implementation
On Tue, Mar 11, 2014 at 12:57:32PM +0200, Jyri Sarha wrote:
This commit adds a bare bones driver support for TLV320AIC31XX family
audio codecs. The driver adds basic stereo playback trough headphone
and speaker outputs and mono capture trough microphone inputs.
Applied, thanks. One thing it'd be good to fix:
+Optional properties:
+
+- gpio-reset - gpio pin number used for codec reset
+- ai31xx-micbias-vg - MicBias Voltage setting
This is optional but...
+ of_property_read_u32(np, ai31xx-micbias-vg, value);
+ switch (value) {
+ case MICBIAS_2_0V:
+ case MICBIAS_2_5V:
+ case MICBIAS_AVDDV:
+ aic31xx-pdata.micbias_vg = value;
+ break;
+ default:
+ dev_err(aic31xx-dev,
+ Bad ai31xx-micbias-vg value %d DT\n,
+ value);
+ aic31xx-pdata.micbias_vg = MICBIAS_2_0V;
+ }
...you'll get an error if it's missing (and an uninitialised memory
read).
signature.asc
Description: Digital signature
Re: [PATCH 10/18] dma: edma: Reduce debug print verbosity for non verbose debugging
On Thu, 2014-03-13 at 11:18 +0200, Peter Ujfalusi wrote:
Do not print the paRAM information when verbose debugging is not asked and
also reduce the number of lines printed in edma_prep_dma_cyclic()
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index e4f4a0cef58c..e2aa42b8342f 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -141,7 +141,7 @@ static void edma_execute(struct edma_chan *echan)
for (i = 0; i nslots; i++) {
j = i + edesc-processed;
edma_write_slot(echan-slot[i], edesc-pset[j]);
- dev_dbg(echan-vchan.chan.device-dev,
+ dev_vdbg(echan-vchan.chan.device-dev,
\n pset[%d]:\n
chnum\t%d\n
slot\t%d\n
I believe you may move this code to separate function and reuse it
later.
Moreover %d is not good specifier for unsigned types, maybe %u?
@@ -554,9 +554,8 @@ static struct dma_async_tx_descriptor
*edma_prep_dma_cyclic(
edesc-cyclic = 1;
edesc-pset_nr = nslots;
- dev_dbg(dev, %s: nslots=%d\n, __func__, nslots);
- dev_dbg(dev, %s: period_len=%d\n, __func__, period_len);
- dev_dbg(dev, %s: buf_len=%d\n, __func__, buf_len);
+ dev_dbg(dev, %s: channel=%d nslots=%d period_len=%d buf_len=%d\n,
+ __func__, echan-ch_num, nslots, period_len, buf_len);
Consider to use proper specifiers for size_t types, namely %zd.
for (i = 0; i nslots; i++) {
/* Allocate a PaRAM slot, if needed */
@@ -590,8 +589,8 @@ static struct dma_async_tx_descriptor
*edma_prep_dma_cyclic(
else
src_addr += period_len;
- dev_dbg(dev, %s: Configure period %d of buf:\n, __func__, i);
- dev_dbg(dev,
+ dev_vdbg(dev, %s: Configure period %d of buf:\n, __func__, i);
+ dev_vdbg(dev,
See the first comment.
\n pset[%d]:\n
chnum\t%d\n
slot\t%d\n
--
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Re: [alsa-devel] [PATCH 14/18] ASoC: davinci: Add edma dmaengine platform driver
On 03/13/2014 12:28 PM, Lars-Peter Clausen wrote:
+int edma_pcm_platform_register(struct device *dev)
+{
+if (dev-of_node)
+return snd_dmaengine_pcm_register(dev,
+edma_dmaengine_pcm_config,
+SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
Since the edma dmaengine driver implements the slave cap API there is no need
to manually specify SND_DMAENGINE_PCM_FLAG_NO_RESIDUE manually. But since the
edma driver sets the granularity to DMA_RESIDUE_GRANULARITY_DESCRIPTOR in this
case the generic dmaengine will not set SND_DMAENGINE_PCM_FLAG_NO_RESIDUE
automatically since it assumes that the dmaengine driver is capable of
properly reporting the DMA position.
Hrm, I see. For eDMA I think we can support DMA_RESIDUE_GRANULARITY_SEGMENT
granularity. Since according to the documentation the _SEGMENT means that the
DMA position will be updated per periods, which is basically the same thing
what we are doing at the moment when the granularity is
DMA_RESIDUE_GRANULARITY_DESCRIPTOR.
From ALSA point of view at least they are the same: neither of them can report
exact position, the DMA pointer jumps from period to period.
IMHO in the generic dmaengine PCM we should set the SNDRV_PCM_INFO_BATCH for
both cases.
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On 03/13/2014 01:19 AM, Gupta, Pekon wrote: [..] diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts b/arch/arm/boot/dts/am335x-bone-memory-cape.dts new file mode 100644 index 000..7ab088d --- /dev/null +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts From discussions, option I could think are.. (a) NAND cape node added in both 'am335x-bone.dts' and 'am335x-boneblack.dts' but disabled by default. (b) NAND cape node in new '.dts' file (as mentioned above), and generate a separate blob individual for cape. (c) NAND cape node in existing 'am335x-bone-common.dtsi', disabled by default. But there is no guarantee that future boards remain compatible and same 'common_xx.dtsi' can be reused later. I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the ones who have to maintain all these. Tony ? Key for us is that we'd have to live with what ever we introduce in the interest of backward dtb compatibility. both (a) and (c) requires hand modification by user of nand cape - considering this might be the strategy for most common capes, we might end up with confusing entries that in many cases will require additional documentation example: option a, c: consider both audio cape (which needs hdmi disabled) and nand cape (which needs mmc2 disabled) - how'd the user know which entries to enable/disable for the user of the cape - documentation needed and potentially user error prone implementation as well. There is as well a option (d) where we wait for FDT overlay to mature, write up a resource manager and support all level capes. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On Thu, Mar 13, 2014 at 8:03 AM, Nishanth Menon n...@ti.com wrote: On 03/13/2014 01:19 AM, Gupta, Pekon wrote: [..] diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts b/arch/arm/boot/dts/am335x-bone-memory-cape.dts new file mode 100644 index 000..7ab088d --- /dev/null +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts From discussions, option I could think are.. (a) NAND cape node added in both 'am335x-bone.dts' and 'am335x-boneblack.dts' but disabled by default. (b) NAND cape node in new '.dts' file (as mentioned above), and generate a separate blob individual for cape. (c) NAND cape node in existing 'am335x-bone-common.dtsi', disabled by default. But there is no guarantee that future boards remain compatible and same 'common_xx.dtsi' can be reused later. I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the ones who have to maintain all these. Tony ? Key for us is that we'd have to live with what ever we introduce in the interest of backward dtb compatibility. both (a) and (c) requires hand modification by user of nand cape - considering this might be the strategy for most common capes, we might end up with confusing entries that in many cases will require additional documentation example: option a, c: consider both audio cape (which needs hdmi disabled) and nand cape (which needs mmc2 disabled) - how'd the user know which entries to enable/disable for the user of the cape - documentation needed and potentially user error prone implementation as well. There is as well a option (d) where we wait for FDT overlay to mature, write up a resource manager and support all level capes. (b) is the direction i'm currently trying to transition the beagleboard.org community till (d) actually shows any life/hope again. example: https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.13/patches/static-capes I really like Nishanth's simpler version he posted, so I'll be converting mine to that style later today. Also with u-boot v2014.04-rcX we now have test -e (exist support) so we can actively check for the presence of board-cape.dtb and safely fall back to board.dtb if it didn't actually exist. The only requirement is the end user specify the cape as a variable in uEnv.txt https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.04-rc2/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L76 Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 14/18] ASoC: davinci: Add edma dmaengine platform driver
On 03/13/2014 02:03 PM, Peter Ujfalusi wrote:
On 03/13/2014 12:28 PM, Lars-Peter Clausen wrote:
+int edma_pcm_platform_register(struct device *dev)
+{
+if (dev-of_node)
+return snd_dmaengine_pcm_register(dev,
+edma_dmaengine_pcm_config,
+SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
Since the edma dmaengine driver implements the slave cap API there is no need
to manually specify SND_DMAENGINE_PCM_FLAG_NO_RESIDUE manually. But since the
edma driver sets the granularity to DMA_RESIDUE_GRANULARITY_DESCRIPTOR in this
case the generic dmaengine will not set SND_DMAENGINE_PCM_FLAG_NO_RESIDUE
automatically since it assumes that the dmaengine driver is capable of
properly reporting the DMA position.
Hrm, I see. For eDMA I think we can support DMA_RESIDUE_GRANULARITY_SEGMENT
granularity. Since according to the documentation the _SEGMENT means that the
DMA position will be updated per periods, which is basically the same thing
what we are doing at the moment when the granularity is
DMA_RESIDUE_GRANULARITY_DESCRIPTOR.
From ALSA point of view at least they are the same: neither of them can report
exact position, the DMA pointer jumps from period to period.
IMHO in the generic dmaengine PCM we should set the SNDRV_PCM_INFO_BATCH for
both cases.
Ups, sorry mixed up DMA_RESIDUE_GRANULARITY_SEGMENT and
DMA_RESIDUE_GRANULARITY_DESCRIPTOR. You can just remove the
SND_DMAENGINE_PCM_FLAG_NO_RESIDUE when registering the dmaengine PCM driver
and everything will still work as expected.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/18] dma: edma: Reduce debug print verbosity for non verbose debugging
On 03/13/2014 02:53 PM, Shevchenko, Andriy wrote:
On Thu, 2014-03-13 at 11:18 +0200, Peter Ujfalusi wrote:
Do not print the paRAM information when verbose debugging is not asked and
also reduce the number of lines printed in edma_prep_dma_cyclic()
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index e4f4a0cef58c..e2aa42b8342f 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -141,7 +141,7 @@ static void edma_execute(struct edma_chan *echan)
for (i = 0; i nslots; i++) {
j = i + edesc-processed;
edma_write_slot(echan-slot[i], edesc-pset[j]);
-dev_dbg(echan-vchan.chan.device-dev,
+dev_vdbg(echan-vchan.chan.device-dev,
\n pset[%d]:\n
chnum\t%d\n
slot\t%d\n
I believe you may move this code to separate function and reuse it
later.
As the per patch description, I only changed the debug level in this patch.
Moreover %d is not good specifier for unsigned types, maybe %u?
You are right for unsigned type %u is the correct. This is why we have %d
since j, echan-ch_num and echan-slot[i] are integer.
@@ -554,9 +554,8 @@ static struct dma_async_tx_descriptor
*edma_prep_dma_cyclic(
edesc-cyclic = 1;
edesc-pset_nr = nslots;
-dev_dbg(dev, %s: nslots=%d\n, __func__, nslots);
-dev_dbg(dev, %s: period_len=%d\n, __func__, period_len);
-dev_dbg(dev, %s: buf_len=%d\n, __func__, buf_len);
+dev_dbg(dev, %s: channel=%d nslots=%d period_len=%d buf_len=%d\n,
+__func__, echan-ch_num, nslots, period_len, buf_len);
Consider to use proper specifiers for size_t types, namely %zd.
I just collapsed the three line of dev_dbg into one and have not really
checked the formats.
For size_t the correct format should be %zu.
I'll fix this up for the next version.
for (i = 0; i nslots; i++) {
/* Allocate a PaRAM slot, if needed */
@@ -590,8 +589,8 @@ static struct dma_async_tx_descriptor
*edma_prep_dma_cyclic(
else
src_addr += period_len;
-dev_dbg(dev, %s: Configure period %d of buf:\n, __func__, i);
-dev_dbg(dev,
+dev_vdbg(dev, %s: Configure period %d of buf:\n, __func__, i);
+dev_vdbg(dev,
See the first comment.
As the per patch description, I only changed the debug level in this patch.
This can be done as a separate patch later IMO as part of a bigger debug
cleanup.
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 13/18] dma: edma: Print the direction value as well when it is not supported
On 03/13/2014 03:03 PM, Shevchenko, Andriy wrote:
On Thu, 2014-03-13 at 11:18 +0200, Peter Ujfalusi wrote:
In case of not supported direction it is better to print the direction also.
It is unlikely, but in such an event it helps with the debugging.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 47abaac7eb18..69dd4e3de67e 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -426,7 +426,7 @@ static struct dma_async_tx_descriptor
*edma_prep_slave_sg(
dev_width = echan-cfg.dst_addr_width;
burst = echan-cfg.dst_maxburst;
} else {
-dev_err(dev, %s: bad direction?\n, __func__);
+dev_err(dev, %s: bad direction: %d\n, __func__, direction);
Is it possible to have direction less than zero? Maybe %u?
It is 'enum dma_transfer_direction direction'. %d should be fine.
return NULL;
}
@@ -519,7 +519,7 @@ static struct dma_async_tx_descriptor
*edma_prep_dma_cyclic(
dev_width = echan-cfg.dst_addr_width;
burst = echan-cfg.dst_maxburst;
} else {
-dev_err(dev, %s: bad direction?\n, __func__);
+dev_err(dev, %s: bad direction: %d\n, __func__, direction);
Ditto.
return NULL;
}
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] edma/ASoC: dmaengine PCM for AM335x and AM447x
On Thu, Mar 13, 2014 at 11:18:22AM +0200, Peter Ujfalusi wrote: With this series AM335x and AM447x will use the dmaengine PCM for audio. The daVinci devices will keep using the davinci-pcm for now since I do not have means to test them but the code is written in a way that they can be switched to use the edma-pcm easily (DA850/OMAP-L138 has been tested and audio was working fine). Can you please not resend the ASoC portions of this series until the EDMA portion is stable (and ideally committed)? I'm not quite sure why but every EDMA patch series seems to go through lots of iterations which gets rather noisy - my initial reaction to seeing EDMA in a subject is to just delete the thread. signature.asc Description: Digital signature
RE: [PATCH v3 02/14] v4l: ti-vpe: register video device only when firmware is loaded
Hi, From: Archit Taneja [mailto:arc...@ti.com] Sent: Thursday, March 13, 2014 1:09 PM Hi Kamil, On Thursday 13 March 2014 05:18 PM, Kamil Debski wrote: Hi Archit, From: Archit Taneja [mailto:arc...@ti.com] Sent: Tuesday, March 11, 2014 9:34 AM vpe fops(vpe_open in particular) should be called only when VPDMA firmware is loaded. File operations on the video device are possible the moment it is registered. Currently, we register the video device for VPE at driver probe, after calling a vpdma helper to initialize VPDMA and load firmware. This function is non-blocking(it calls request_firmware_nowait()), and doesn't ensure that the firmware is actually loaded when it returns. We remove the device registration from vpe probe, and move it to a callback provided by the vpe driver to the vpdma library, through vpdma_create(). The ready field in vpdma_data is no longer needed since we always have firmware loaded before the device is registered. A minor problem with this approach is that if the video_register_device fails(which doesn't really happen), the vpe platform device would be registered. however, there won't be any v4l2 device corresponding to it. Could you explain to me one thing. request_firmware cannot be used in probe, thus you are using request_firmware_nowait. Why cannot the firmware be loaded on open with a regular request_firmware that is waiting? I totally agree with you here. Placing the firmware in open() would probably make more sense. The reason I didn't place it in open() is because I didn't want to release firmware in a corresponding close(), and be in a situation where the firmware is loaded multiple times in the driver's lifetime. Would it be possible to load firmware in open and release it in remove? I know that this would disturb the symmetry between open-release and probe-remove. But this could work. There are some reasons for doing this. First, it will require more testing with respect to whether the firmware is loaded correctly successive times :), the second is that loading firmware might probably take a bit of time, and we don't want to make applications too slow(I haven't measured the time taken, so I don't have a strong case for this either) This patch seems to swap one problem for another. The possibility that open fails (because firmware is not yet loaded) is swapped for a vague possibility that video_register_device. The driver will work fine in most cases even without this patch(apart from the possibility mentioned as above). We could discard this patch from this series, and I can work on a patch which moves firmware loading to the vpe_open() call, and hence solving the issue in the right manner. Does that sound fine? I agree, this should be a good solution. Thanks, Archit Best wishes, -- Kamil Debski Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 01/14] v4l: ti-vpe: Make sure in job_ready that we have the needed number of dst_bufs
Hi, From: Archit Taneja [mailto:arc...@ti.com] Sent: Tuesday, March 11, 2014 9:34 AM VPE has a ctrl parameter which decides how many mem to mem transactions the active job from the job queue can perform. The driver's job_ready() made sure that the number of ready source buffers are sufficient for the job to execute successfully. But it didn't make sure if there are sufficient ready destination buffers in the capture queue for the VPE output. If the time taken by VPE to process a single frame is really slow, then it's possible that we don't need to imply such a restriction on the dst queue, but really fast transactions(small resolution, no de-interlacing) may cause us to hit the condition where we don't have any free buffers for the VPE to write on. Add the extra check in job_ready() to make sure we have the sufficient amount of destination buffers. Signed-off-by: Archit Taneja arc...@ti.com Acked-by: Kamil Debski k.deb...@samsung.com Best wishes, -- Kamil Debski Samsung RD Institute Poland --- drivers/media/platform/ti-vpe/vpe.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index 7a77a5b..f3143ac 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -887,6 +887,9 @@ static int job_ready(void *priv) if (v4l2_m2m_num_src_bufs_ready(ctx-m2m_ctx) needed) return 0; + if (v4l2_m2m_num_dst_bufs_ready(ctx-m2m_ctx) needed) + return 0; + return 1; } -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6] ASoC: tlv320aic31xx: Add basic codec driver implementation
This commit adds a bare bones driver support for TLV320AIC31XX family
audio codecs. The driver adds basic stereo playback trough headphone
and speaker outputs and mono capture trough microphone inputs.
The driver is currently missing support at least for mini DSP features
and jack detection. I have tested the driver only on TLV320AIC3111,
but based on the data sheets TLV320AIC3100, TLV320AIC3110, and
TLV320AIC3120 should work Ok too.
The base for the implementation was taken from:
g...@gitorious.org:ti-codecs/ti-codecs.git ajitk/topics/k3.10.1-aic31xx
-branch at commit 77504eba0294764e9e63b4a0c696b44db187cd13.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
Since v5 of this patch:
- Fix warning: unused variable 'aic31xx' from function 'aic31xx_clk_off'
.../devicetree/bindings/sound/tlv320aic31xx.txt| 61 +
include/dt-bindings/sound/tlv320aic31xx-micbias.h |8 +
sound/soc/codecs/Kconfig |4 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/tlv320aic31xx.c | 1294
sound/soc/codecs/tlv320aic31xx.h | 258
6 files changed, 1627 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
create mode 100644 include/dt-bindings/sound/tlv320aic31xx-micbias.h
create mode 100644 sound/soc/codecs/tlv320aic31xx.c
create mode 100644 sound/soc/codecs/tlv320aic31xx.h
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
new file mode 100644
index 000..74c66de
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
@@ -0,0 +1,61 @@
+Texas Instruments - tlv320aic31xx Codec module
+
+The tlv320aic31xx serial control bus communicates through I2C protocols
+
+Required properties:
+
+- compatible - string - One of:
+ti,tlv320aic310x - Generic TLV320AIC31xx with mono speaker amp
+ti,tlv320aic311x - Generic TLV320AIC31xx with stereo speaker amp
+ti,tlv320aic3100 - TLV320AIC3100 (mono speaker amp, no MiniDSP)
+ti,tlv320aic3110 - TLV320AIC3110 (stereo speaker amp, no MiniDSP)
+ti,tlv320aic3120 - TLV320AIC3120 (mono speaker amp, MiniDSP)
+ti,tlv320aic3111 - TLV320AIC3111 (stereo speaker amp, MiniDSP)
+
+- reg - int - I2C slave address
+
+
+Optional properties:
+
+- gpio-reset - gpio pin number used for codec reset
+- ai31xx-micbias-vg - MicBias Voltage setting
+1 or MICBIAS_2_0V - MICBIAS output is powered to 2.0V
+2 or MICBIAS_2_5V - MICBIAS output is powered to 2.5V
+3 or MICBIAS_AVDD - MICBIAS output is connected to AVDD
+ If this node is not mentioned or if the value is unknown, then
+ micbias is set to 2.0V.
+- HPVDD-supply, SPRVDD-supply, SPLVDD-supply, AVDD-supply, IOVDD-supply,
+ DVDD-supply : power supplies for the device as covered in
+ Documentation/devicetree/bindings/regulator/regulator.txt
+
+CODEC output pins:
+ * HPL
+ * HPR
+ * SPL, devices with stereo speaker amp
+ * SPR, devices with stereo speaker amp
+ * SPK, devices with mono speaker amp
+ * MICBIAS
+
+CODEC input pins:
+ * MIC1LP
+ * MIC1RP
+ * MIC1LM
+
+The pins can be used in referring sound node's audio-routing property.
+
+Example:
+#include dt-bindings/sound/tlv320aic31xx-micbias.h
+
+tlv320aic31xx: tlv320aic31xx@18 {
+ compatible = ti,tlv320aic311x;
+ reg = 0x18;
+
+ ai31xx-micbias-vg = MICBIAS_OFF;
+
+ HPVDD-supply = regulator;
+ SPRVDD-supply = regulator;
+ SPLVDD-supply = regulator;
+ AVDD-supply = regulator;
+ IOVDD-supply = regulator;
+ DVDD-supply = regulator;
+};
diff --git a/include/dt-bindings/sound/tlv320aic31xx-micbias.h
b/include/dt-bindings/sound/tlv320aic31xx-micbias.h
new file mode 100644
index 000..f5cb772
--- /dev/null
+++ b/include/dt-bindings/sound/tlv320aic31xx-micbias.h
@@ -0,0 +1,8 @@
+#ifndef __DT_TLV320AIC31XX_MICBIAS_H
+#define __DT_TLV320AIC31XX_MICBIAS_H
+
+#define MICBIAS_2_0V 1
+#define MICBIAS_2_5V 2
+#define MICBIAS_AVDDV 3
+
+#endif /* __DT_TLV320AIC31XX_MICBIAS_H */
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index e19b64f..af3c049 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -83,6 +83,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TAS5086 if I2C
select SND_SOC_TLV320AIC23 if I2C
select SND_SOC_TLV320AIC26 if SPI_MASTER
+ select SND_SOC_TLV320AIC31XX if I2C
select SND_SOC_TLV320AIC32X4 if I2C
select SND_SOC_TLV320AIC3X if I2C
select SND_SOC_TPA6130A2 if I2C
@@ -428,6 +429,9 @@ config SND_SOC_TLV320AIC26
tristate
depends on SPI
+config SND_SOC_TLV320AIC31XX
+tristate
+
config SND_SOC_TLV320AIC32X4
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 90ab24b..018e3f3 100644
--- a/sound/soc/codecs/Makefile
+++
RE: [PATCH v4 01/14] v4l: ti-vpe: Make sure in job_ready that we have the needed number of dst_bufs
From: Archit Taneja [mailto:arc...@ti.com] Sent: Thursday, March 13, 2014 12:44 PM VPE has a ctrl parameter which decides how many mem to mem transactions the active job from the job queue can perform. The driver's job_ready() made sure that the number of ready source buffers are sufficient for the job to execute successfully. But it didn't make sure if there are sufficient ready destination buffers in the capture queue for the VPE output. If the time taken by VPE to process a single frame is really slow, then it's possible that we don't need to imply such a restriction on the dst queue, but really fast transactions(small resolution, no de-interlacing) may cause us to hit the condition where we don't have any free buffers for the VPE to write on. Add the extra check in job_ready() to make sure we have the sufficient amount of destination buffers. Signed-off-by: Archit Taneja arc...@ti.com Acked-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/ti-vpe/vpe.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index 7a77a5b..f3143ac 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -887,6 +887,9 @@ static int job_ready(void *priv) if (v4l2_m2m_num_src_bufs_ready(ctx-m2m_ctx) needed) return 0; + if (v4l2_m2m_num_dst_bufs_ready(ctx-m2m_ctx) needed) + return 0; + return 1; } -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 08/14] v4l: ti-vpe: Rename csc memory resource name
Hi,
From: Archit Taneja [mailto:arc...@ti.com]
Sent: Thursday, March 13, 2014 12:44 PM
Rename the memory block resource vpe_csc to csc since it also
exists within the VIP IP block. This would make the name more generic,
and both VPE and VIP DT nodes in the future can use it.
I understand that this is not yet used in any public dts files. Right?
Best wishes,
--
Kamil Debski
Samsung RD Institute Poland
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/csc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/csc.c
b/drivers/media/platform/ti-vpe/csc.c
index acfea50..039 100644
--- a/drivers/media/platform/ti-vpe/csc.c
+++ b/drivers/media/platform/ti-vpe/csc.c
@@ -180,7 +180,7 @@ struct csc_data *csc_create(struct platform_device
*pdev)
csc-pdev = pdev;
csc-res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
- vpe_csc);
+ csc);
if (csc-res == NULL) {
dev_err(pdev-dev, missing platform resources data\n);
return ERR_PTR(-ENODEV);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 06/14] v4l: ti-vpe: Fix some params in VPE data descriptors
Hi,
From: Archit Taneja [mailto:arc...@ti.com]
Sent: Thursday, March 13, 2014 12:44 PM
To: k.deb...@samsung.com; hverk...@xs4all.nl
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Archit
Taneja
Subject: [PATCH v4 06/14] v4l: ti-vpe: Fix some params in VPE data
descriptors
Some parameters of the VPE descriptors were understood incorrectly.
They are now fixed. The fixes are explained as follows:
- When adding an inbound data descriptor to the VPDMA descriptor list,
we intend
to use c_rect as the cropped region fetched by VPDMA. Therefore,
c_rect-width
shouldn't be used to calculate the line stride, the original image
width
should be used for that. We add a 'width' argument which gives the
buffer
width in memory.
- frame_width and frame_height describe the complete width and height
of the
client to which the channel is connected. If there are multiple
channels
fetching data and providing to the same client, the above 2 arguments
should
be the width and height of the region covered by all the channels. In
the case
where there is only one channel providing pixel data to the client
(like in VPE), frame_width and frame_height should be the cropped
width and
cropped height respectively. The calculation of these params is done
in the
vpe driver now.
- start_h and start_v is also used in the case of multiple channels to
describe
where each channel should start filling pixel data. We don't use this
in VPE,
and pass 0s to the vpdma_add_in_dtd() helper.
- Some minor changes are made to the vpdma_add_out_dtd() helper. The
c_rect
param is used for specifying the 'composition' target, and 'width'
is added
to calculate the line stride.
This patch looks ok. Passes checkpatch and compiles. I can't say much more
as I have limited knowledge of the internals of VPE and don't have the
hardware.
Signed-off-by: Archit Taneja arc...@ti.com
Acked-by: Kamil Debski k.deb...@samsung.com
Best wishes,
--
Kamil Debski
Samsung RD Institute Poland
---
drivers/media/platform/ti-vpe/vpdma.c | 60
+++
drivers/media/platform/ti-vpe/vpdma.h | 10 +++---
drivers/media/platform/ti-vpe/vpe.c | 18 +++
3 files changed, 64 insertions(+), 24 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
index 73dd38e..a51a013 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -614,8 +614,17 @@ static void dump_dtd(struct vpdma_dtd *dtd)
/*
* append an outbound data transfer descriptor to the given descriptor
list,
* this sets up a 'client to memory' VPDMA transfer for the given
VPDMA channel
+ *
+ * @list: vpdma desc list to which we add this decriptor
+ * @width: width of the image in pixels in memory
+ * @c_rect: compose params of output image
+ * @fmt: vpdma data format of the buffer
+ * dma_addr: dma address as seen by VPDMA
+ * chan: VPDMA channel
+ * flags: VPDMA flags to configure some descriptor fileds
*/
-void vpdma_add_out_dtd(struct vpdma_desc_list *list, struct v4l2_rect
*c_rect,
+void vpdma_add_out_dtd(struct vpdma_desc_list *list, int width,
+ const struct v4l2_rect *c_rect,
const struct vpdma_data_format *fmt, dma_addr_t dma_addr,
enum vpdma_channel chan, u32 flags)
{
@@ -623,6 +632,7 @@ void vpdma_add_out_dtd(struct vpdma_desc_list *list,
struct v4l2_rect *c_rect,
int field = 0;
int notify = 1;
int channel, next_chan;
+ struct v4l2_rect rect = *c_rect;
int depth = fmt-depth;
int stride;
struct vpdma_dtd *dtd;
@@ -630,11 +640,15 @@ void vpdma_add_out_dtd(struct vpdma_desc_list
*list, struct v4l2_rect *c_rect,
channel = next_chan = chan_info[chan].num;
if (fmt-type == VPDMA_DATA_FMT_TYPE_YUV
- fmt-data_type == DATA_TYPE_C420)
+ fmt-data_type == DATA_TYPE_C420) {
+ rect.height = 1;
+ rect.top = 1;
depth = 8;
+ }
- stride = ALIGN((depth * c_rect-width) 3, VPDMA_STRIDE_ALIGN);
- dma_addr += (c_rect-left * depth) 3;
+ stride = ALIGN((depth * width) 3, VPDMA_STRIDE_ALIGN);
+
+ dma_addr += rect.top * stride + (rect.left * depth 3);
dtd = list-next;
WARN_ON((void *)(dtd + 1) (list-buf.addr + list-buf.size));
@@ -664,31 +678,48 @@ void vpdma_add_out_dtd(struct vpdma_desc_list
*list, struct v4l2_rect *c_rect,
/*
* append an inbound data transfer descriptor to the given descriptor
list,
* this sets up a 'memory to client' VPDMA transfer for the given
VPDMA channel
+ *
+ * @list: vpdma desc list to which we add this decriptor
+ * @width: width of the image in pixels in memory(not the cropped
+ width)
+ * @c_rect: crop params of input image
+ * @fmt: vpdma data format of the buffer
+ * dma_addr: dma address as seen by
[PATCH v4 0/5] Add USB nodes for am43xx epos and gp evm
The patch series adds USB dt nodes for am43xx epos and gp evm Boot tested with linux-next + Tony's omap-for-v3.15/dt Changes from v1 - v2 * Reorder doc: Add ti,am437x-dwc3 comaptible for dwc3 glue * Address v1 coments on ARM: dts: AM4372: Add USB nodes Changes from v2 - v3 * Removed unwanted dwc3_1 and dwc3_2 nodes from am437x-gp-evm.dts and am43x-epos-evm.dts Changes from v3 - v4 * Refreshed on top of Tony's omap-for-v3.15/dt tree * Added usb_phy0_always_on_clk32k and usb_phy1_always_on_clk32k Patch 2 * Used the above clocks in Patch 3 * Patch 4 and 5 edited the unwanted portions of commit log George Cherian (5): doc: Add ti,am437x-dwc3 comaptible for dwc3 glue ARM: dts: am43xx clock data ARM: dts: AM4372: Add USB nodes ARM: dts: am437x-gp-evm: Enable USB ARM: dts: am43x-epos-evm: Enable USB Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +- arch/arm/boot/dts/am4372.dtsi | 94 ++ arch/arm/boot/dts/am437x-gp-evm.dts| 26 ++ arch/arm/boot/dts/am43x-epos-evm.dts | 27 +++ arch/arm/boot/dts/am43xx-clocks.dtsi | 33 5 files changed, 183 insertions(+), 1 deletion(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 5/5] ARM: dts: am43x-epos-evm: Enable USB
Enable
- USB PHY
- USB
for am43x-epos-evm
Signed-off-by: George Cherian george.cher...@ti.com
Acked-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 167dbc8..1a4946a 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -367,3 +367,21 @@
pinctrl-0 = spi1_pins;
status = okay;
};
+
+usb2_phy1 {
+ status = okay;
+};
+
+usb1 {
+ dr_mode = peripheral;
+ status = okay;
+};
+
+usb2_phy2 {
+ status = okay;
+};
+
+usb2 {
+ dr_mode = host;
+ status = okay;
+};
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/5] ARM: dts: AM4372: Add USB nodes
Add nodes for 2 instances each of
- ocp2scp
- USB PHY control module
- USB PHY
- dwc3_omap
- USB
for AM43xx.
Signed-off-by: George Cherian george.cher...@ti.com
Acked-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 94 +++
1 file changed, 94 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 36d523a..cedb9d4 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -735,6 +735,100 @@
#size-cells = 1;
status = disabled;
};
+
+ am43xx_control_usb2phy1: control-phy@44e10620 {
+ compatible = ti,control-phy-usb2-am437;
+ reg = 0x44e10620 0x4;
+ reg-names = power;
+ };
+
+ am43xx_control_usb2phy2: control-phy@0x44e10628 {
+ compatible = ti,control-phy-usb2-am437;
+ reg = 0x44e10628 0x4;
+ reg-names = power;
+ };
+
+ ocp2scp0: ocp2scp@483a8000 {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ocp2scp0;
+
+ usb2_phy1: phy@483a8000 {
+ compatible = ti,am437x-usb2;
+ reg = 0x483a8000 0x8000;
+ ctrl-module = am43xx_control_usb2phy1;
+ clocks = usb_phy0_always_on_clk32k,
+usb_otg_ss0_refclk960m;
+ clock-names = wkupclk, refclk;
+ #phy-cells = 0;
+ status = disabled;
+ };
+ };
+
+ ocp2scp1: ocp2scp@483e8000 {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ocp2scp1;
+
+ usb2_phy2: phy@483e8000 {
+ compatible = ti,am437x-usb2;
+ reg = 0x483e8000 0x8000;
+ ctrl-module = am43xx_control_usb2phy2;
+ clocks = usb_phy1_always_on_clk32k,
+usb_otg_ss1_refclk960m;
+ clock-names = wkupclk, refclk;
+ #phy-cells = 0;
+ status = disabled;
+ };
+ };
+
+ dwc3_1: omap_dwc3@4838 {
+ compatible = ti,am437x-dwc3;
+ ti,hwmods = usb_otg_ss0;
+ reg = 0x4838 0x1;
+ interrupts = GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH;
+ #address-cells = 1;
+ #size-cells = 1;
+ utmi-mode = 1;
+ ranges;
+
+ usb1: usb@4839 {
+ compatible = synopsys,dwc3;
+ reg = 0x4839 0x17000;
+ interrupts = GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH;
+ phys = usb2_phy1;
+ phy-names = usb2-phy;
+ maximum-speed = high-speed;
+ dr_mode = otg;
+ status = disabled;
+ };
+ };
+
+ dwc3_2: omap_dwc3@483c {
+ compatible = ti,am437x-dwc3;
+ ti,hwmods = usb_otg_ss1;
+ reg = 0x483c 0x1;
+ interrupts = GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH;
+ #address-cells = 1;
+ #size-cells = 1;
+ utmi-mode = 1;
+ ranges;
+
+ usb2: usb@483d {
+ compatible = synopsys,dwc3;
+ reg = 0x483d 0x17000;
+ interrupts = GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH;
+ phys = usb2_phy2;
+ phy-names = usb2-phy;
+ maximum-speed = high-speed;
+ dr_mode = otg;
+ status = disabled;
+ };
+ };
};
};
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH v4 4/5] ARM: dts: am437x-gp-evm: Enable USB
Enable
- USB PHY
- USB
for am437x-gp-evm
Signed-off-by: George Cherian george.cher...@ti.com
Acked-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e..9e57538 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -125,3 +125,21 @@
pinctrl-0 = mmc1_pins;
cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
};
+
+usb2_phy1 {
+ status = okay;
+};
+
+usb1 {
+ dr_mode = peripheral;
+ status = okay;
+};
+
+usb2_phy2 {
+ status = okay;
+};
+
+usb2 {
+ dr_mode = host;
+ status = okay;
+};
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/5] ARM: dts: am43xx clock data
Add USB and USB PHY reference clock data
Signed-off-by: George Cherian george.cher...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..c74d45c 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -653,4 +653,36 @@
clocks = clk_32768_ck, clk_32k_tpm_ck;
reg = 0x4260;
};
+
+ usb_phy0_always_on_clk32k: usb_phy0_always_on_clk32k {
+ #clock-cells = 0;
+ compatible = fixed-factor-clock;
+ clocks = clk_32768_ck;
+ clock-mult = 1;
+ clock-div = 1;
+ };
+
+ usb_phy1_always_on_clk32k: usb_phy1_always_on_clk32k {
+ #clock-cells = 0;
+ compatible = fixed-factor-clock;
+ clocks = clk_32768_ck;
+ clock-mult = 1;
+ clock-div = 1;
+ };
+
+ usb_otg_ss0_refclk960m: usb_otg_ss0_refclk960m {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_clkdcoldo;
+ ti,bit-shift = 8;
+ reg = 0x8a60;
+ };
+
+ usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_clkdcoldo;
+ ti,bit-shift = 8;
+ reg = 0x8a68;
+ };
};
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/5] doc: Add ti,am437x-dwc3 comaptible for dwc3 glue
Add the compatible ti,am437x-dwc3 for dwc3 glue driver. Signed-off-by: George Cherian george.cher...@ti.com Acked-by: Roger Quadros rog...@ti.com --- Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 38b2fae..38d9bb8 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -44,7 +44,9 @@ Board specific device node entry }; OMAP DWC3 GLUE - - compatible : Should be ti,dwc3 + - compatible : Should be + * ti,dwc3 for OMAP5 and DRA7 + * ti,am437x-dwc3 for AM437x - ti,hwmods : Should be usb_otg_ss - reg : Address and length of the register set for the device. - interrupts : The irq number of this device that is used to interrupt the -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/5] Add USB nodes for am43xx epos and gp evm
On Thu, Mar 13, 2014 at 08:41:11PM +0530, George Cherian wrote: The patch series adds USB dt nodes for am43xx epos and gp evm Boot tested with linux-next + Tony's omap-for-v3.15/dt Changes from v1 - v2 * Reorder doc: Add ti,am437x-dwc3 comaptible for dwc3 glue * Address v1 coments on ARM: dts: AM4372: Add USB nodes Changes from v2 - v3 * Removed unwanted dwc3_1 and dwc3_2 nodes from am437x-gp-evm.dts and am43x-epos-evm.dts Changes from v3 - v4 * Refreshed on top of Tony's omap-for-v3.15/dt tree * Added usb_phy0_always_on_clk32k and usb_phy1_always_on_clk32k Patch 2 * Used the above clocks in Patch 3 * Patch 4 and 5 edited the unwanted portions of commit log hope there's still time for v3.15, it would be great to see these patches in v3.15-final. -- balbi signature.asc Description: Digital signature
Re: [PATCH v5] ASoC: tlv320aic31xx: Add basic codec driver implementation
On 03/13/2014 02:20 PM, Mark Brown wrote:
On Tue, Mar 11, 2014 at 12:57:32PM +0200, Jyri Sarha wrote:
This commit adds a bare bones driver support for TLV320AIC31XX family
audio codecs. The driver adds basic stereo playback trough headphone
and speaker outputs and mono capture trough microphone inputs.
Applied, thanks. One thing it'd be good to fix:
+Optional properties:
+
+- gpio-reset - gpio pin number used for codec reset
+- ai31xx-micbias-vg - MicBias Voltage setting
This is optional but...
+ of_property_read_u32(np, ai31xx-micbias-vg, value);
+ switch (value) {
+ case MICBIAS_2_0V:
+ case MICBIAS_2_5V:
+ case MICBIAS_AVDDV:
+ aic31xx-pdata.micbias_vg = value;
+ break;
+ default:
+ dev_err(aic31xx-dev,
+ Bad ai31xx-micbias-vg value %d DT\n,
+ value);
+ aic31xx-pdata.micbias_vg = MICBIAS_2_0V;
+ }
...you'll get an error if it's missing (and an uninitialised memory
read).
Actually you don't. The value-variable is initialized to MICBIAS_2_0V
and if ai31xx-micbias-vg is not present of_property_read_u32 leaves
the variable untouched, but I'll send a patch for fixing the unused
variable working shortly.
Forget about the v6 version of the patch.
Thanks,
Jyri
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6] ASoC: tlv320aic31xx: Fix unused variable warning from aic31xx_clk_off
Fix warning: unused variable 'aic31xx' from function 'aic31xx_clk_off'.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
sound/soc/codecs/tlv320aic31xx.c |1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
index e626b56..c9f6989 100644
--- a/sound/soc/codecs/tlv320aic31xx.c
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -945,7 +945,6 @@ static void aic31xx_clk_on(struct snd_soc_codec *codec)
static void aic31xx_clk_off(struct snd_soc_codec *codec)
{
- struct aic31xx_priv *aic31xx = snd_soc_codec_get_drvdata(codec);
u8 mask = AIC31XX_PM_MASK;
u8 off = 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ASoC: tlv320aic31xx: Remove snd_soc_codec_set_cache_io() call
Remove snd_soc_codec_set_cache_io(codec, 8, 8, SND_SOC_REGMAP) call
and codec-control_data = aic31xx-regmap assignment since that
already done by core.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
This patch should fix the last minute breakkage of v3.15 ASoC updates build.
sound/soc/codecs/tlv320aic31xx.c |9 -
1 file changed, 9 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
index c9f6989..625b184 100644
--- a/sound/soc/codecs/tlv320aic31xx.c
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -1051,18 +1051,9 @@ static int aic31xx_codec_probe(struct snd_soc_codec
*codec)
dev_dbg(aic31xx-dev, ## %s\n, __func__);
aic31xx = snd_soc_codec_get_drvdata(codec);
- codec-control_data = aic31xx-regmap;
aic31xx-codec = codec;
- ret = snd_soc_codec_set_cache_io(codec, 8, 8, SND_SOC_REGMAP);
-
- if (ret != 0) {
- dev_err(codec-dev, snd_soc_codec_set_cache_io failed %d\n,
- ret);
- return ret;
- }
-
for (i = 0; i ARRAY_SIZE(aic31xx-supplies); i++) {
aic31xx-disable_nb[i].nb.notifier_call =
aic31xx_regulator_event;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: omap-dma: Implement device_slave_caps callback
* Peter Ujfalusi peter.ujfal...@ti.com [140313 00:52]:
Hi Tony,
On 03/12/2014 07:37 PM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [140307 05:39]:
With the callback implemented omap-dma can provide information to client
drivers regarding to supported address widths, directions, residue
granularity, etc.
This may need some testing against linux next with Russell's
omap-dma.c clean-up series merged there. Peter, care to check
if this patch is still valid against linux next?
The patch applies cleanly on top of linux-next fetched yesterday and I see
Russell's patches underneath.
OK thanks for testing:
Acked-by: Tony Lindgren t...@atomide.com
Regards,
Tony
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 64ceca2920b8..b19f04f4390b 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1088,6 +1088,23 @@ static void omap_dma_free(struct omap_dmadev *od)
}
}
+#define OMAP_DMA_BUSWIDTHS(BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+ BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+ BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static int omap_dma_device_slave_caps(struct dma_chan *dchan,
+struct dma_slave_caps *caps)
+{
+ caps-src_addr_widths = OMAP_DMA_BUSWIDTHS;
+ caps-dstn_addr_widths = OMAP_DMA_BUSWIDTHS;
+ caps-directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+ caps-cmd_pause = true;
+ caps-cmd_terminate = true;
+ caps-residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+
+ return 0;
+}
+
static int omap_dma_probe(struct platform_device *pdev)
{
struct omap_dmadev *od;
@@ -1118,6 +1135,7 @@ static int omap_dma_probe(struct platform_device
*pdev)
od-ddev.device_prep_slave_sg = omap_dma_prep_slave_sg;
od-ddev.device_prep_dma_cyclic = omap_dma_prep_dma_cyclic;
od-ddev.device_control = omap_dma_control;
+ od-ddev.device_slave_caps = omap_dma_device_slave_caps;
od-ddev.dev = pdev-dev;
INIT_LIST_HEAD(od-ddev.channels);
INIT_LIST_HEAD(od-pending);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/7] hwspinlock/core: add common OF helpers
On Tue, Mar 04, 2014 at 11:38:23AM -0600, Suman Anna wrote: Hi Ohad, On 03/02/2014 02:19 PM, Bjorn Andersson wrote: On Sat, Mar 1, 2014 at 9:14 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Mon, Feb 10, 2014 at 9:14 PM, Suman Anna s-a...@ti.com wrote: On 02/07/2014 04:49 PM, Bjorn Andersson wrote: Ohad, Do you have any objections to the return code convention change? Unless strictly needed, I prefer we don't switch to the ERR_PTR code convention, as it reduces code readability and increases chances of user bugs. In our case, switching to ERR_PTR and friends seems only to optimize a few error paths, and I'm not sure it's a big win over simplicity. When introducing the ability to reference a hwspin lock via a phandle in device tree it makes a big difference to be able to differ between the case of initialization failed or device not yet probed; so that the client knows if it should fail or retry later. Can you confirm the changes you want me to make, so that I can refresh and post a v5 for 3.15? What's the status on this? I'm assuming this is going to miss 3.15? Having DT support in the core will be useful to move the Qualcomm hwspinlock driver forward as well. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
* Robert Nelson robertcnel...@gmail.com [140313 06:33]: On Thu, Mar 13, 2014 at 8:03 AM, Nishanth Menon n...@ti.com wrote: On 03/13/2014 01:19 AM, Gupta, Pekon wrote: [..] diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts b/arch/arm/boot/dts/am335x-bone-memory-cape.dts new file mode 100644 index 000..7ab088d --- /dev/null +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts From discussions, option I could think are.. (a) NAND cape node added in both 'am335x-bone.dts' and 'am335x-boneblack.dts' but disabled by default. The capes can live their own revision cycle from beaglebones, so separate .dts files for each cape are probably better. (b) NAND cape node in new '.dts' file (as mentioned above), and generate a separate blob individual for cape. (b.2) NAND cape node in new '.dts' file but devices set to disabled by default. Included into am335x-*bone*.dts files. The found and configured cape devices set back to enabled by u-boot by modifying the .dtb by using the existing ft_board_setup() and fdt_find_and_setprop() in u-boot. (c) NAND cape node in existing 'am335x-bone-common.dtsi', disabled by default. But there is no guarantee that future boards remain compatible and same 'common_xx.dtsi' can be reused later. This also has an issue of different revision cycle between beaglebones and the capes. I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the ones who have to maintain all these. Tony ? Key for us is that we'd have to live with what ever we introduce in the interest of backward dtb compatibility. both (a) and (c) requires hand modification by user of nand cape - considering this might be the strategy for most common capes, we might end up with confusing entries that in many cases will require additional documentation example: option a, c: consider both audio cape (which needs hdmi disabled) and nand cape (which needs mmc2 disabled) - how'd the user know which entries to enable/disable for the user of the cape - documentation needed and potentially user error prone implementation as well. There is as well a option (d) where we wait for FDT overlay to mature, write up a resource manager and support all level capes. Yeah option (d) and having the capes hotpluggable is probably the best way to go in the long run. Meanwhile, I'd suggest researching if option (b.2) above is doable for enabling some capes. (b) is the direction i'm currently trying to transition the beagleboard.org community till (d) actually shows any life/hope again. example: https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.13/patches/static-capes I really like Nishanth's simpler version he posted, so I'll be converting mine to that style later today. Yeah except most of these capes should be included into the am335x-*bone*.dts files as in (b.2) above. All the internal omap devices are still there on the SoC even if not wired to the cape. The GPMC devices may cause more of an issue as we cannot just override the chip select wiring by modifying the .dtb. But for the internal devices modifying the .dtb to enable some of them might be doable. Also with u-boot v2014.04-rcX we now have test -e (exist support) so we can actively check for the presence of board-cape.dtb and safely fall back to board.dtb if it didn't actually exist. The only requirement is the end user specify the cape as a variable in uEnv.txt https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.04-rc2/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L76 That's great! Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/5] ARM: dts: am43xx clock data
On 03/13/2014 05:11 PM, George Cherian wrote:
Add USB and USB PHY reference clock data
Signed-off-by: George Cherian george.cher...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..c74d45c 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -653,4 +653,36 @@
clocks = clk_32768_ck, clk_32k_tpm_ck;
reg = 0x4260;
};
+
+ usb_phy0_always_on_clk32k: usb_phy0_always_on_clk32k {
+ #clock-cells = 0;
+ compatible = fixed-factor-clock;
+ clocks = clk_32768_ck;
+ clock-mult = 1;
+ clock-div = 1;
+ };
+
+ usb_phy1_always_on_clk32k: usb_phy1_always_on_clk32k {
+ #clock-cells = 0;
+ compatible = fixed-factor-clock;
+ clocks = clk_32768_ck;
+ clock-mult = 1;
+ clock-div = 1;
+ };
Shouldn't these be like so?
usb_phy0_always_on_clk32k: usb_phy0_always_on_clk32k {
#clock-cells = 0;
compatible = ti,gate-clock;
clocks = usbphy_32khz_clkmux;
ti,bit-shift = 8;
reg = 0x2a40;
};
usb_phy1_always_on_clk32k: usb_phy1_always_on_clk32k {
#clock-cells = 0;
compatible = ti,gate-clock;
clocks = usbphy_32khz_clkmux;
ti,bit-shift = 8;
reg = 0x2a48;
};
+
+ usb_otg_ss0_refclk960m: usb_otg_ss0_refclk960m {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_clkdcoldo;
+ ti,bit-shift = 8;
+ reg = 0x8a60;
+ };
+
+ usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_clkdcoldo;
+ ti,bit-shift = 8;
+ reg = 0x8a68;
+ };
};
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] ASoC: tlv320aic31xx: Add basic codec driver implementation
On Thu, Mar 13, 2014 at 04:35:44PM +0200, Jyri Sarha wrote: This commit adds a bare bones driver support for TLV320AIC31XX family audio codecs. The driver adds basic stereo playback trough headphone and speaker outputs and mono capture trough microphone inputs. Please don't resend patches that have already been applied. signature.asc Description: Digital signature
Re: [PATCH v6] ASoC: tlv320aic31xx: Fix unused variable warning from aic31xx_clk_off
On Thu, Mar 13, 2014 at 05:37:52PM +0200, Jyri Sarha wrote: Fix warning: unused variable 'aic31xx' from function 'aic31xx_clk_off'. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] ASoC: tlv320aic31xx: Remove snd_soc_codec_set_cache_io() call
On Thu, Mar 13, 2014 at 06:22:35PM +0200, Jyri Sarha wrote: Remove snd_soc_codec_set_cache_io(codec, 8, 8, SND_SOC_REGMAP) call and codec-control_data = aic31xx-regmap assignment since that already done by core. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v2 4/4] ARM: DTS: AM43x: Add DSS node
On Thu, Mar 13, 2014 at 08:58:29AM +, Sathya Prakash M R wrote:
Add device node for DSS module for AM4372. Both the
AM437x-Gp evm and Am43x-Epos evm use the same LCD panel.
The lcd timings are added in respective dts files.
Adds display pinctrl and enables required gpio.
Also set the right parent clock to the DSS clock.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/boot/dts/am4372.dtsi| 28 +
arch/arm/boot/dts/am437x-gp-evm.dts | 77
++
arch/arm/boot/dts/am43x-epos-evm.dts | 73
arch/arm/boot/dts/am43xx-clocks.dtsi |2 +
4 files changed, 180 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ea55a4e..b72a7df 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -684,6 +684,34 @@
num-cs = 4;
status = disabled;
};
+
+ dss: dss@4832A000 {
+ compatible = ti,omap3-dss, simple-bus;
This doesn't look right to me. I'm not sure it makes sense for
simple-bus to be in the compatible list.
Are the child nodes usable in isolation, or are they dependent on the
ti,omap3-dss node? What exactly does the ti,omap3-dss node
represent?
Thanks,
Mark.
+ reg = 0x4832A000 0x200;
+ ti,hwmods = dss_core;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@4832A400 {
+ compatible = ti,omap3-dispc;
+ reg = 0x4832A400 0x400;
+ interrupts = GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ };
+
+ dpi: encoder@0 {
+ compatible = ti,omap3-dpi;
+ };
+
+ rfbi: rfbi@4832A800 {
+ compatible = ti,omap3-rfbi;
+ reg = 0x4832A800 0x100;
+ ti,hwmods = dss_rfbi;
+ };
+
+ };
+
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] ARM: DTS: AM43x: Add DSS node
On 13/03/14 19:46, Mark Rutland wrote:
On Thu, Mar 13, 2014 at 08:58:29AM +, Sathya Prakash M R wrote:
Add device node for DSS module for AM4372. Both the
AM437x-Gp evm and Am43x-Epos evm use the same LCD panel.
The lcd timings are added in respective dts files.
Adds display pinctrl and enables required gpio.
Also set the right parent clock to the DSS clock.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/boot/dts/am4372.dtsi| 28 +
arch/arm/boot/dts/am437x-gp-evm.dts | 77
++
arch/arm/boot/dts/am43x-epos-evm.dts | 73
arch/arm/boot/dts/am43xx-clocks.dtsi |2 +
4 files changed, 180 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ea55a4e..b72a7df 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -684,6 +684,34 @@
num-cs = 4;
status = disabled;
};
+
+dss: dss@4832A000 {
+compatible = ti,omap3-dss, simple-bus;
This doesn't look right to me. I'm not sure it makes sense for
simple-bus to be in the compatible list.
Are the child nodes usable in isolation, or are they dependent on the
ti,omap3-dss node? What exactly does the ti,omap3-dss node
represent?
The child nodes are dependent on the dss node.
The ti,omap3-dss represents the dss_core block of the OMAP display
subsystem. The dss_core is a small IP, a wrapper for the submodules,
handling things like clock and video path routing between the submodules
and the OMAP's other components (like the PRCM where we get clocks). It
also handles reset, so when dss_core is reset, all the submodules are reset.
The HW design is a bit odd, in my opinion, as the submodules are proper
IP blocks, and as far as I see, they could be designed to be independent
of each others. But they have not been designed so.
Having dss_core as the parent node for the submodules gives us automatic
runtime-pm handling, so when one submodule is enabled, it forces
dss_core to be enabled first. This makes the reset work right (i.e. we
don't accidentally reset dss_core when one of the submodules is in use),
and, as the dss_core is always needed to setup the clock and video path
routing, it gets properly initialized before any of the submodules will
use it.
What simple-bus mostly gives us here is automatic creation of the
platform devices for the submodules. We could also create the devices
for submodules in the driver of the dss_core. I did have that at some
point, but the simple-bus does identical job, and it seemed to make
sense to me.
Note that the same method is used for omap2/3/4 also, in the patches
that have been going around for some time in the lists.
Tomi
signature.asc
Description: OpenPGP digital signature
