RE: [PATCH 4/5] [RFC] ARM: OMAP2+: gpmc: fix gpmc_hwecc_bch_capable
Hi Cristoph,
From: Pekon Gupta pe...@ti.com
From: Christoph Fritz [mailto:chf.fr...@googlemail.com]
Most dt omap3 boards configure nand-ecc-opt as bch8. Due
to lack of hardware elm support, bch8 software implementation
gets set.
Since commit 0611c41934ab35ce84dea ARM: OMAP2+: gpmc: update
gpmc_hwecc_bch_capable() for new platforms and ECC schemes,
nand support stops working.
This patch allows ecc software fallback.
Pleas add following tag at top of commit message.
Fixes: commit 0611c41934ab35ce84dea34ab291897ad3cbc7be
ARM: OMAP2+: gpmc: update gpmc_hwecc_bch_capable() for new platforms and ECC
schemes
And please mark it for 3.15 stable if this gets accepted after 3.15-rcx.
Cc: sta...@vger.kernel.org # 3.15.x+
---
arch/arm/mach-omap2/gpmc-nand.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 4349e82..52c4834 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -43,13 +43,17 @@ static struct platform_device gpmc_nand_device = {
.resource = gpmc_nand_resource,
};
-static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
+static bool gpmc_ecc_bch_capable(enum omap_ecc ecc_opt)
I don't think this renaming is really required with this fix, so please
drop it and just keep it simple only for OMAP3 fix.
{
/* platforms which support all ECC schemes */
if (soc_is_am33xx() || cpu_is_omap44xx() ||
soc_is_omap54xx() || soc_is_dra7xx())
return 1;
+ if ((ecc_opt == OMAP_ECC_BCH4_CODE_HW_DETECTION_SW) ||
+ (ecc_opt == OMAP_ECC_BCH8_CODE_HW_DETECTION_SW))
+ return 1;
+
Note: Some very old legacy platforms have initial version of GPMC engine
which only supports Hamming ECC, and not BCH ECC scheme, so lets
filter them out to maintain backward compatibility.
(1) As per TRM, OMAP2 platform does not support BCH ECC schemes,
So please filter out OMAP2 devices from this check ...
(2) I don't know the history but below comment says:
* For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1
if ((ecc_opt == OMAP_ECC_BCH4_CODE_HW_DETECTION_SW) ||
(ecc_opt == OMAP_ECC_BCH8_CODE_HW_DETECTION_SW)) {
if (cpu_is_omap24xx())
return 0;
else if (cpu_is_omap3630() (GET_OMAP_REVISION() == 0))
return 0;
else
return 1;
}
/* OMAP3xxx do not have ELM engine, so cannot support ECC schemes
* which require H/W based ECC error detection */
if ((cpu_is_omap34xx() || cpu_is_omap3630())
@@ -57,14 +61,6 @@ static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
(ecc_opt == OMAP_ECC_BCH8_CODE_HW)))
return 0;
- /*
- * For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1
- * and AM33xx derivates. Other chips may be added if confirmed to work.
- */
- if ((ecc_opt == OMAP_ECC_BCH4_CODE_HW_DETECTION_SW)
- (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0)))
- return 0;
-
Thanks for removing this, I too wasn't confident of this either.
/* legacy platforms support only HAM1 (1-bit Hamming) ECC scheme */
if (ecc_opt == OMAP_ECC_HAM1_CODE_HW)
return 1;
@@ -140,7 +136,7 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
gpmc_update_nand_reg(gpmc_nand_data-reg, gpmc_nand_data-cs);
- if (!gpmc_hwecc_bch_capable(gpmc_nand_data-ecc_opt)) {
+ if (!gpmc_ecc_bch_capable(gpmc_nand_data-ecc_opt)) {
Please drop this renaming from this patch.
dev_err(dev, Unsupported NAND ECC scheme selected\n);
return -EINVAL;
}
--
1.7.10.4
You may send this patch separately apart from the series, so that
this gets accepted in current 3.15-rcx.
with regards, Pekon
Do you plan to re-spin this patch with above comments, and mark it for stable?
It would be helpful for all OMAP3 users.
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 01/12] ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
Hi Tony,
On 07/07/2014 02:46 PM, Tony Lindgren wrote:
* Jyri Sarha jsa...@ti.com [140626 12:26]:
This code is not working currently and it can be removed. There is a
conflict in sharing resources with the actual HDMI driver and with
the ASoC HDMI audio DAI driver.
Is this OK to queue for v3.17 or do we need this for v3.16-rc series?
Jyri is away currently, but I think it would be great if this patch goes in
for 3.16. The patch does not introduce regression since the OMAP4/5 HDMI is in
non working state in the kernel so removing the platform device right now will
ease up the merger of the new and working code.
Regards,
Péter
Regards,
Tony
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/mach-omap2/devices.c | 28
1 file changed, 28 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 592ba0a..b6f8f34 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -297,33 +297,6 @@ static void omap_init_audio(void)
static inline void omap_init_audio(void) {}
#endif
-#if defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI) || \
-defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI_MODULE)
-
-static struct platform_device omap_hdmi_audio = {
-.name = omap-hdmi-audio,
-.id = -1,
-};
-
-static void __init omap_init_hdmi_audio(void)
-{
-struct omap_hwmod *oh;
-struct platform_device *pdev;
-
-oh = omap_hwmod_lookup(dss_hdmi);
-if (!oh)
-return;
-
-pdev = omap_device_build(omap-hdmi-audio-dai, -1, oh, NULL, 0);
-WARN(IS_ERR(pdev),
- Can't build omap_device for omap-hdmi-audio-dai.\n);
-
-platform_device_register(omap_hdmi_audio);
-}
-#else
-static inline void omap_init_hdmi_audio(void) {}
-#endif
-
#if defined(CONFIG_SPI_OMAP24XX) || defined(CONFIG_SPI_OMAP24XX_MODULE)
#include linux/platform_data/spi-omap2-mcspi.h
@@ -459,7 +432,6 @@ static int __init omap2_init_devices(void)
*/
omap_init_audio();
omap_init_camera();
-omap_init_hdmi_audio();
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
--
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
--
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 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
Hi Peter, On 07/05/2014 08:25 AM, Peter Griffin wrote: Signed-off-by: Peter Griffin peter.grif...@linaro.org Acked-by: Maxime Coquelin maxime.coque...@st.com Thanks, Maxime --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 702ca10..269ad3b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1325,6 +1325,7 @@ F:drivers/pinctrl/pinctrl-st.c F:drivers/media/rc/st_rc.c F:drivers/i2c/busses/i2c-st.c F:drivers/tty/serial/st-asc.c +F: drivers/usb/dwc3/dwc3-st.c ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT M:Lennert Buytenhek ker...@wantstofly.org -- 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] gpio: omap: Remove unnecessary lockdep class
On Fri, Jun 27, 2014 at 10:17 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: GPIO irqchips assign to the cascaded IRQs their own lock class in order to avoid warnings about lockdep recursions since that allow the lockdep core to keep track of things. Since commit e45d1c80 (gpio: put GPIO IRQs into their own lock class) there is no need to do this in a driver if it's using the GPIO irqchip helpers since gpiolib already assigns a lockdep class. Signed-off-by: Javier Martinez Canillas jmarti...@softcrates.net That's right. Patch applied. Yours, Linus Walleij -- 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 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
On Tue, 08 Jul 2014, Maxime Coquelin wrote: On 07/05/2014 08:25 AM, Peter Griffin wrote: Signed-off-by: Peter Griffin peter.grif...@linaro.org Acked-by: Maxime Coquelin maxime.coque...@st.com Maxime, Once Acked by Felipe, I think this should go in via your tree to avoid conflicts with other ARM/STI ARCHITECTURE additions. --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 702ca10..269ad3b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1325,6 +1325,7 @@ F: drivers/pinctrl/pinctrl-st.c F: drivers/media/rc/st_rc.c F: drivers/i2c/busses/i2c-st.c F: drivers/tty/serial/st-asc.c +F: drivers/usb/dwc3/dwc3-st.c ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT M: Lennert Buytenhek ker...@wantstofly.org -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/3] gpio: omap: Remove unneeded include
On Fri, Jun 27, 2014 at 10:17 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: The linux/irqchip/chained_irq.h header is already included when selecting GPIOLIB_IRQCHIP so there is no need to do it in the driver. This is a left over from commit fb655f5 (gpio: omap: convert driver to use gpiolib irqchip). Signed-off-by: Javier Martinez Canillas jmarti...@softcrates.net Patch applied. Yours, Linus Walleij -- 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 3/3] gpio: omap: Add an omap prefix to all functions
On Fri, Jun 27, 2014 at 10:17 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: The GPIO OMAP driver didn't have a consistent naming scheme for all its functions. Some of them had an omap prefix while others didn't. There are many advantages on having a separate namespace for driver functions so let's add an omap prefix to all of them. Signed-off-by: Javier Martinez Canillas jmarti...@softcrates.net Yeah that was very disturbing, patch applied, thanks! Yours, Linus Walleij -- 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: [GIT PULL] ARM: OMAP2+: more fixes for v3.16-rc
* Paul Walmsley p...@pwsan.com [140707 08:54]: Hi Tony The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee: Linux 3.16-rc2 (2014-06-21 19:02:54 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.16-rc/omap-fixes-b for you to fetch changes up to 6340c8720ce34f35b41a2e15d69fe3d755cb2104: ARM: OMAP2+: clock/dpll: fix _dpll_test_fint arithmetics overflow (2014-07-06 15:58:38 -0600) Some miscellaneous fixes for OMAP clock code, DRA7xx device data, and PRCM code (when DSPBridge is used) for v3.16-rc. Basic build, boot, and PM test logs are available here: http://www.pwsan.com/omap/testlogs/prcm-a-v3.16-rc/20140706174258/ Thanks pulling into omap-for-v3.16/fixes. 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 01/12] ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
* Peter Ujfalusi peter.ujfal...@ti.com [140708 00:32]: Hi Tony, On 07/07/2014 02:46 PM, Tony Lindgren wrote: * Jyri Sarha jsa...@ti.com [140626 12:26]: This code is not working currently and it can be removed. There is a conflict in sharing resources with the actual HDMI driver and with the ASoC HDMI audio DAI driver. Is this OK to queue for v3.17 or do we need this for v3.16-rc series? Jyri is away currently, but I think it would be great if this patch goes in for 3.16. The patch does not introduce regression since the OMAP4/5 HDMI is in non working state in the kernel so removing the platform device right now will ease up the merger of the new and working code. OK, will apply it into omap-for-v3.16/fixes as it just removes broken code. 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] mach-omap1: Fix call to omap_cfg_reg
* Nick Krause xerofo...@gmail.com [140707 10:42]: Hey Tony, This seems to be a false positive then.Please reply if it is so I can remove the Fix me message. Yes, just replace the FIXME with a comment please. 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 V2] ARM: dts: OMAP5: Add device nodes for ABB
* Nishanth Menon n...@ti.com [140707 07:25]: On Mon, Jul 7, 2014 at 6:32 AM, Tony Lindgren t...@atomide.com wrote: * Nishanth Menon n...@ti.com [140605 18:12]: From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com Add ABB device nodes for OMAP5 family of devices. Data is based on final production OMAP543x Technical Reference Manual revision Z (April 2013). Final production Data Manual for OMAP5432 SWPS050F(APRIL 2014). [n...@ti.com: co-developer and updates to latest documentation] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com --- Original patch (v1): https://patchwork.kernel.org/patch/3555191/ Rest of the series was accepted, however, I had to drop this previously to ensure that the data we introduce is compatible with production samples and existing pre-production samples on various OMAP5uEVMs already in circulation. Is this OK to queue for v3.17 or do we need it for the -rc cycle? .17 should be fine Tony. Thanks for following up. OK applying into omap-for-v3.17/fixes-not-urgent thanks. 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] omap16xx: Removes fixme no longer needed in ocpi_enable()
* Nicholas Krause xerofo...@gmail.com [140702 18:33]:
This removes the FIXME message above ocpi_enable being declared
for proper locking in this function. As of the current kernel
verisons there is no need for locking as only one driver uses
this function currently and therefore there is no need for real
locking requirements.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
Thanks applying into omap-for-v3.17/fixes-not-urgent.
Tony
---
arch/arm/mach-omap1/ocpi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap1/ocpi.c b/arch/arm/mach-omap1/ocpi.c
index 238170c..44a3d19 100644
--- a/arch/arm/mach-omap1/ocpi.c
+++ b/arch/arm/mach-omap1/ocpi.c
@@ -55,7 +55,6 @@ static struct clk *ocpi_ck;
/*
* Enables device access to OMAP buses via the OCPI bridge
- * FIXME: Add locking
*/
int ocpi_enable(void)
{
--
1.9.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: [GIT PULL] ARM: DRA7: dts: clock data fixes
* Tero Kristo t-kri...@ti.com [140703 11:05]: Hi Tony, The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: Linux 3.16-rc1 (2014-06-15 17:45:28 -1000) are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-v3.16-rc/clk-dt-fixes for you to fetch changes up to dd94324b983afe114ba9e7ee3649313b451f63ce: ARM: dts: dra7xx-clocks: Fix the l3 and l4 clock rates (2014-07-03 20:59:36 +0300) One fix for 3.16-rc. Fixes wrong dividers for l3/l4 clock nodes on DRA7. Pulling this into omap-for-v3.16/fixes thanks. Tony Rajendra Nayak (1): ARM: dts: dra7xx-clocks: Fix the l3 and l4 clock rates arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 ++ 1 file changed, 6 insertions(+), 4 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
Re: [PATCH] ARM: OMAP2+: l2c: squelch warning dump on power control setting
* Sekhar Nori nsek...@ti.com [140707 21:56]:
On Monday 07 July 2014 08:40 PM, Felipe Balbi wrote:
On Mon, Jul 07, 2014 at 02:40:08PM +0100, Russell King - ARM Linux wrote:
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -732,7 +732,7 @@ static int l2c310_cpu_enable_flz(struct notifier_block
*nb, unsigned long act, v
static void __init l2c310_enable(void __iomem *base, u32 aux, unsigned
num_lock)
{
- unsigned rev = readl_relaxed(base + L2X0_CACHE_ID)
L2X0_CACHE_ID_PART_MASK;
+ unsigned rev = readl_relaxed(base + L2X0_CACHE_ID)
L2X0_CACHE_ID_RTL_MASK;
bool cortex_a9 = read_cpuid_part() == ARM_CPU_PART_CORTEX_A9;
even with this change, l2c still tries to write to power control
register, at least on AM437x. Looking a little deeper here, AM437x
identifies itself as l2c PL310 r3p3, which should have power control
register, but aparentely there's no way to write that register. I'll
file a bug to our ROM team, but we will certainly need a way to
workaround this inside omap4-common.c
Looks like we need both my patch as well as Russell's patch. I can
respin my patch with the pr_info_once() dropped if it helps further
reduce boot noise.
In that case I'm fine with the original patch in this series. Russell,
got any better ideas?
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 v2 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
On 07/08/2014 09:53 AM, Lee Jones wrote: On Tue, 08 Jul 2014, Maxime Coquelin wrote: On 07/05/2014 08:25 AM, Peter Griffin wrote: Signed-off-by: Peter Griffin peter.grif...@linaro.org Acked-by: Maxime Coquelin maxime.coque...@st.com Maxime, Once Acked by Felipe, I think this should go in via your tree to avoid conflicts with other ARM/STI ARCHITECTURE additions. Ok --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 702ca10..269ad3b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1325,6 +1325,7 @@ F:drivers/pinctrl/pinctrl-st.c F:drivers/media/rc/st_rc.c F:drivers/i2c/busses/i2c-st.c F:drivers/tty/serial/st-asc.c +F: drivers/usb/dwc3/dwc3-st.c ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT M:Lennert Buytenhek ker...@wantstofly.org -- 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: am335x: linux 3.16-rc3: USB DMA issue
On Wed, Jul 2, 2014 at 3:28 PM, Yegor Yefremov yegorsli...@googlemail.com wrote: On Tue, Jul 1, 2014 at 5:37 PM, Ezequiel García ezequ...@vanguardiasur.com.ar wrote: On 1 July 2014 12:07, Yegor Yefremov yegorsli...@googlemail.com wrote: [..] What can be done with these error messages: of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/usb@4740/usb-phy@47401300[0]' 47401300.usb-phy supply vcc not found, using dummy regulator musb-hdrc musb-hdrc.0.auto: Failed to request rx1. musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/usb@4740/usb-phy@47401b00[0]' 47401b00.usb-phy supply vcc not found, using dummy regulator musb-hdrc musb-hdrc.1.auto: Failed to request rx1. musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517 platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral couldn't find an available UDC The above are typical deferal messages. Have you tried building everything as a module or moving the DMA devicetree node so it's probed earlier? But I'm not sure it's related to the problem you are seeing. Compiling as a module helped. Thanks. I experience another issue, that happens either in monolithic kernel or as modules. In 2-4% of power cycles the hub chip connected to USB0 won't be detected. So far I couldn't find any error messages. Any idea? Yegor -- 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/RESEND 0/9] drm: tilcdc driver fixes
On Sat, Jun 28, 2014 at 06:51:15AM -0400, Rob Clark wrote: On Fri, Jun 27, 2014 at 6:08 PM, Darren Etheridge detheri...@ti.com wrote: Guido, On 06/17/2014 09:17 AM, Guido Martínez wrote: The tilcdc driver could be compiled as a module, but was severely broken and could not be used as such. This patchset attempts to fix the issues preventing a proper load/unload of the module. Issues included dangling sysfs nodes, dangling devices, memory leaks and a double kfree. It now seems to be working ok. We have tested this by loading and unloading the driver repeteadly, with both panel and slave connectors and found no flaws. There is still one warning left on tilcdc_crtc_destroy, caused by destroying the connector while still in an ON status. We don't know why this happens or why it's an issue, so we did not fix it. Yes I see what you mean, it triggers the WARN_ON in tilcdc_crtc_destroy because DRM_MODE_DPMS_ON is still set. This WARN_ON does make some sense because DPMS_OFF would have the effect of turning off clocks and putting the monitor to sleep which seems logical considering we have torn down the display. Adding a tilcdc_crtc_dpms(DPMS_OFF) right before the WARN_ON confirms this, but it seems strange that this hasn't happened automatically (+ Russell doesn't need to do it in his Armada driver) - so I suspect there is a better way. tbh, I'm not entirely sure offhand why drm_mode_config_cleanup() doesn't remove the fb's first (which should have the effect of shutting down any lit crtc/encoder/connector).. that would seem like the sensible way to shut down.. All userspace fbs should be cleared already before going into the driver unload. Which only leaves you with driver internal fbs (usually just one for fbdev emulation). It's the driver's job to clean that up explicitly. Then you can call mode_config_cleanup and the WARN_ON in there is a really nice space leak check. If we'd unconditionally clean up all fbs we'd have trouble with driver-private embedded fbs and their refcounting and would loose the space leak check. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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 7/7] ARM: configs: omap2plus_defconfig: enable TPS65218 configs
Enable TPS65218 config options. Signed-off-by: Keerthy j-keer...@ti.com Acked-by: Felipe Balbi ba...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 536a137..f650f00 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -180,6 +180,7 @@ CONFIG_TWL4030_WATCHDOG=y CONFIG_MFD_SYSCON=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65217=y +CONFIG_MFD_TPS65218=y CONFIG_MFD_TPS65910=y CONFIG_TWL6040_CORE=y CONFIG_REGULATOR_FIXED_VOLTAGE=y @@ -188,6 +189,7 @@ CONFIG_REGULATOR_TI_ABB=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y +CONFIG_REGULATOR_TPS65218=y CONFIG_REGULATOR_TPS65910=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_PBIAS=y -- 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 6/7] regulator: tps65218: Add get_voltage ops for dcdc5 and dcdc6
Add get_voltage ops for dcdc5 and dcdc6. Both dcdc5 and 6 are fixed regulators
and hence return min_uV (or max_uV).
Signed-off-by: Keerthy j-keer...@ti.com
---
drivers/regulator/tps65218-regulator.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/regulator/tps65218-regulator.c
b/drivers/regulator/tps65218-regulator.c
index 9effe48..700c652 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -151,6 +151,14 @@ static int tps65218_pmic_disable(struct regulator_dev *dev)
dev-desc-enable_mask, TPS65218_PROTECT_L1);
}
+static int tps65218_pmic_dcdc56_get_voltage(struct regulator_dev *dev)
+{
+ struct tps65218 *tps = rdev_get_drvdata(dev);
+ unsigned int rid = rdev_get_id(dev);
+
+ return tps-info[rid]-min_uV;
+}
+
/* Operations permitted on DCDC1, DCDC2 */
static struct regulator_ops tps65218_dcdc12_ops = {
.is_enabled = regulator_is_enabled_regmap,
@@ -179,6 +187,7 @@ static struct regulator_ops tps65218_dcdc56_pmic_ops = {
.is_enabled = regulator_is_enabled_regmap,
.enable = tps65218_pmic_enable,
.disable= tps65218_pmic_disable,
+ .get_voltage= tps65218_pmic_dcdc56_get_voltage,
};
static const struct regulator_desc regulators[] = {
--
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 5/7] ARM: dts: AM437x: Add TPS65218 device tree nodes
Add TPS65218 device tree nodes. i2c clock frequency setting
also added as part of tps65218 nodes addition. As i2c clock
enabling is required.
Signed-off-by: Keerthy j-keer...@ti.com
---
Changes in V2:
*Added dcdc3, dcdc5, dcdc6 nodes
arch/arm/boot/dts/am437x-gp-evm.dts | 58 +++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 85ca430..f0422c2 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -260,6 +260,64 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c0_pins;
+ clock-frequency = 40;
+
+ tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = ti,tps65218-dcdc3;
+ regulator-name = vdcdc3;
+ regulator-min-microvolt = 135;
+ regulator-max-microvolt = 135;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ dcdc5: regulator-dcdc5 {
+ compatible = ti,tps65218-dcdc5;
+ regulator-name = v1_0bat;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ };
+
+ dcdc6: regulator-dcdc6 {
+ compatible = ti,tps65218-dcdc6;
+ regulator-name = v1_8bat;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
};
i2c1 {
--
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/7] ARM: dts: AM437x: Fix i2c nodes indentation
Fix i2c nodes indentation.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 003766c..85ca430 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -257,16 +257,15 @@
};
i2c0 {
-status = okay;
-pinctrl-names = default;
-pinctrl-0 = i2c0_pins;
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pins;
};
i2c1 {
-status = okay;
-pinctrl-names = default;
-pinctrl-0 = i2c1_pins;
-
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
pixcir_ts@5c {
compatible = pixcir,pixcir_tangoc;
pinctrl-names = default;
--
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/7] mfd: Add DT bindings for tps65218 PMIC
Add DT bindings for tps65218 PMIC
Signed-off-by: Keerthy j-keer...@ti.com
---
Changes in V2:
* Added dcdc3, dcdc5, dcdc6 compatible properties.
Documentation/devicetree/bindings/mfd/tps65218.txt | 89
1 file changed, 89 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps65218.txt
b/Documentation/devicetree/bindings/mfd/tps65218.txt
new file mode 100644
index 000..01ac973
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65218.txt
@@ -0,0 +1,89 @@
+Texas Instruments TPS65218 family
+
+The TPS65218 are Integrated Power Management Chips.
+
+Required properties:
+- compatible : Must be ti,tps65218;
+ For Integrated power-management used in AM437x based boards
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the tps65218 supports several interrupts
+ internally, it is considered as an interrupt controller cascaded to the
+ SoC one.
+- #interrupt-cells = 2;
+- interrupt-parent : The parent interrupt controller which is gic.
+
+Optional node:
+- TPS65218 PMIC has a number of child nodes. Mainly the regularors and SMPSs.
+
+Example:
+/*
+ * Integrated Power Management Chip
+ */
+tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ /* VDD_CORE voltage limits min of OPP50 and max of OPP100 */
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ /* VDD_MPU voltage limits min of OPP50 and max of OPP_NITRO */
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = ti,tps65218-dcdc3;
+ regulator-name = vdcdc3;
+ regulator-min-microvolt = 135;
+ regulator-max-microvolt = 135;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc4: regulator-dcdc4 {
+ compatible = ti,tps65218-dcdc4;
+ regulator-name = v3_3d;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc5: regulator-dcdc5 {
+ compatible = ti,tps65218-dcdc5;
+ regulator-name = v1_0bat;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ };
+
+ dcdc6: regulator-dcdc6 {
+ compatible = ti,tps65218-dcdc6;
+ regulator-name = v1_8vat;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
--
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 2/7] regulator: Add DT bindings for tps65218 PMIC regulators.
Add DT bindings for tps65218 PMIC regulators.
Signed-off-by: Keerthy j-keer...@ti.com
---
Changes in V2:
* Added dcdc3, dcdc5, dcdc6 compatible properties.
.../devicetree/bindings/regulator/tps65218.txt | 23
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt
b/Documentation/devicetree/bindings/regulator/tps65218.txt
new file mode 100644
index 000..fccc1d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -0,0 +1,23 @@
+TPS65218 family of regulators
+
+Required properties:
+For tps65218 regulators/LDOs
+- compatible:
+ - ti,tps65218-dcdc1 for DCDC1
+ - ti,tps65218-dcdc2 for DCDC2
+ - ti,tps65218-dcdc3 for DCDC3
+ - ti,tps65218-dcdc4 for DCDC4
+ - ti,tps65218-dcdc5 for DCDC5
+ - ti,tps65218-dcdc6 for DCDC6
+ - ti,tps65218-ldo1 for LDO1
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+ xyz: regulator@0 {
+ compatible = ti,tps65218-dcdc1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 300;
+ };
--
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 3/7] ARM: dts: AM43x: Add TPS65218 device tree nodes
Add TPS65218 device tree nodes. i2c clock frequency setting
also added as part of tps65218 nodes addition. As i2c clock
enabling is required.
Signed-off-by: Keerthy j-keer...@ti.com
---
Changes in V2:
* Added dcdc3, dcdc5, dcdc6 nodes.
arch/arm/boot/dts/am43x-epos-evm.dts | 59 ++
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 90098f9..f1ee7495 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -327,6 +327,65 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c0_pins;
+ clock-frequency = 40;
+
+ tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = ti,tps65218-dcdc3;
+ regulator-name = vdcdc3;
+ regulator-min-microvolt = 135;
+ regulator-max-microvolt = 135;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc5: regulator-dcdc5 {
+ compatible = ti,tps65218-dcdc5;
+ regulator-name = v1_0bat;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ };
+
+ dcdc6: regulator-dcdc6 {
+ compatible = ti,tps65218-dcdc6;
+ regulator-name = v1_8bat;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
at24@50 {
compatible = at24,24c256;
--
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 0/7] ARM: dts: AM43x: Add devcice tree nodes
The patch series adds the device tree nodes and the corresponding documentation. The series also enabled tps65218 config options in the omap2plus_defconfig. The series is boot tested on both AM43x-epos-evm and AM437x-gp-evm. Keerthy (7): mfd: Add DT bindings for tps65218 PMIC regulator: Add DT bindings for tps65218 PMIC regulators. ARM: dts: AM43x: Add TPS65218 device tree nodes ARM: dts: AM437x: Fix i2c nodes indentation ARM: dts: AM437x: Add TPS65218 device tree nodes regulator: tps65218: Add get_voltage ops for dcdc5 and dcdc6 ARM: configs: omap2plus_defconfig: enable TPS65218 configs Documentation/devicetree/bindings/mfd/tps65218.txt | 89 .../devicetree/bindings/regulator/tps65218.txt | 23 + arch/arm/boot/dts/am437x-gp-evm.dts| 71 ++-- arch/arm/boot/dts/am43x-epos-evm.dts | 59 + arch/arm/configs/omap2plus_defconfig |2 + drivers/regulator/tps65218-regulator.c |9 ++ 6 files changed, 246 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt -- 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 3/3] dma: edma: Serve cyclic (audio) channels with high priority queue
Move the DMA channel used in cyclic mode (audio) to the highest priority
event queue which helps to reduce audio problems.
When the channel is terminated, move it back to the default queue.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index b512caf46944..fe55f78ea137 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -256,8 +256,13 @@ static int edma_terminate_all(struct edma_chan *echan)
* echan-edesc is NULL and exit.)
*/
if (echan-edesc) {
+ int cyclic = echan-edesc-cyclic;
echan-edesc = NULL;
edma_stop(echan-ch_num);
+ /* Move the cyclic channel back to default queue */
+ if (cyclic)
+ edma_assign_channel_eventq(echan-ch_num,
+ EVENTQ_DEFAULT);
}
vchan_get_all_descriptors(echan-vchan, head);
@@ -724,6 +729,9 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc-pset[i].param.opt |= TCINTEN;
}
+ /* Place the cyclic channel to highest priority queue */
+ edma_assign_channel_eventq(echan-ch_num, EVENTQ_0);
+
return vchan_tx_prep(echan-vchan, edesc-vdesc, tx_flags);
}
--
2.0.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 1/3] ARM: edma: Set default queue to lowest priority
Use the lowest priority queue as default for clients. 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 485be42519b9..f834aae7720f 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1470,7 +1470,8 @@ static int edma_setup_from_hw(struct device *dev, struct edma_soc_info *pdata, queue_priority_map[i][1] = -1; pdata-queue_priority_mapping = queue_priority_map; - pdata-default_queue = 0; + /* Default queue has the lowest priority */ + pdata-default_queue = i - 1; return 0; } -- 2.0.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 2/3] ARM: edma: Add edma_assign_channel_eventq() to move channel to a give queue
In some cases it is desired to move a channel to a specific event queue.
Such a use case is audio, where it is preferred that it is served with
highest priority compared to other DMA clients.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 28
include/linux/platform_data/edma.h | 2 ++
2 files changed, 30 insertions(+)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index f834aae7720f..88099175fc56 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1414,6 +1414,34 @@ void edma_clear_event(unsigned channel)
}
EXPORT_SYMBOL(edma_clear_event);
+/*
+ * edma_assign_channel_eventq - move given channel to desired eventq
+ * Arguments:
+ * channel - channel number
+ * eventq_no - queue to move the channel
+ *
+ * Can be used to move a channel to a selected event queue.
+ */
+void edma_assign_channel_eventq(unsigned channel, enum dma_event_q eventq_no)
+{
+ unsigned ctlr;
+
+ ctlr = EDMA_CTLR(channel);
+ channel = EDMA_CHAN_SLOT(channel);
+
+ if (channel = edma_cc[ctlr]-num_channels)
+ return;
+
+ /* default to low priority queue */
+ if (eventq_no == EVENTQ_DEFAULT)
+ eventq_no = edma_cc[ctlr]-default_queue;
+ if (eventq_no = edma_cc[ctlr]-num_tc)
+ return;
+
+ map_dmach_queue(ctlr, channel, eventq_no);
+}
+EXPORT_SYMBOL(edma_assign_channel_eventq);
+
static int edma_setup_from_hw(struct device *dev, struct edma_soc_info *pdata,
struct edma *edma_cc)
{
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index eb8d5627d080..bdb2710e2aab 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -150,6 +150,8 @@ void edma_clear_event(unsigned channel);
void edma_pause(unsigned channel);
void edma_resume(unsigned channel);
+void edma_assign_channel_eventq(unsigned channel, enum dma_event_q eventq_no);
+
struct edma_rsv_info {
const s16 (*rsv_chans)[2];
--
2.0.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 0/3] ARM/dma: edma: Serve cyclic clients via high priority queue
Hi, It is preferred that audio is served with the highest priority queue in order to avoid delays in data transfer between memory and audio IP. The following series will add an API to arch code to assign a channel to a given queue. The default queue is changed from 0 (highest priority) to lowest priority. In the dmaengine driver we move the cyclic channel to queue0 (highest priority) and move it back to default queue when the channel is terminated. Regards, Peter --- Peter Ujfalusi (3): ARM: edma: Set default queue to lowest priority ARM: edma: Add edma_assign_channel_eventq() to move channel to a give queue dma: edma: Serve cyclic (audio) channels with high priority queue arch/arm/common/edma.c | 31 ++- drivers/dma/edma.c | 8 include/linux/platform_data/edma.h | 2 ++ 3 files changed, 40 insertions(+), 1 deletion(-) -- 2.0.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] ASoC: omap-hdmi: Use devm_snd_soc_register_component
Hi Peter, On Mon, Jul 7, 2014 at 2:59 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote: On 07/06/2014 09:49 AM, Manish Badarkhe wrote: Replaced snd_soc_register_component with its devres equivalent, devm_snd_soc_register_component. Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com --- :100644 100644 eb9c392... 1dc95b5... Msound/soc/omap/omap-hdmi.c sound/soc/omap/omap-hdmi.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c index eb9c392..1dc95b5 100644 --- a/sound/soc/omap/omap-hdmi.c +++ b/sound/soc/omap/omap-hdmi.c @@ -322,7 +322,7 @@ static int omap_hdmi_probe(struct platform_device *pdev) } dev_set_drvdata(pdev-dev, hdmi_data); - ret = snd_soc_register_component(pdev-dev, omap_hdmi_component, + ret = devm_snd_soc_register_component(pdev-dev, omap_hdmi_component, omap_hdmi_dai, 1); As with the omap-mcbsp: Can you align the parameters as well? Sure, will do it and send next version. Regards Manish Badarkhe -- 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] ASoC: omap-dmic: Use devm_snd_soc_register_component
Hi Peter, On Mon, Jul 7, 2014 at 3:00 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote: On 07/06/2014 09:50 AM, Manish Badarkhe wrote: Replaced snd_soc_register_component with its devres equivalent, devm_snd_soc_register_component. Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com --- :100644 100644 6925d71... 011e30e... Msound/soc/omap/omap-dmic.c sound/soc/omap/omap-dmic.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c index 6925d71..011e30e 100644 --- a/sound/soc/omap/omap-dmic.c +++ b/sound/soc/omap/omap-dmic.c @@ -490,7 +490,7 @@ static int asoc_dmic_probe(struct platform_device *pdev) } - ret = snd_soc_register_component(pdev-dev, omap_dmic_component, + ret = devm_snd_soc_register_component(pdev-dev, omap_dmic_component, omap_dmic_dai, 1); Would you align the parameters at the same time? Sure, will do it and send next version. Regards Manish Badarkhe -- 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: Anybody working on tidspbridge?
On 29/06/14 19:42, Greg KH wrote: On Fri, Jun 20, 2014 at 07:05:17PM +0300, Kristina Martšenko wrote: On 20/06/14 18:43, Kristina Martšenko wrote: Hi Omar, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving tidspbridge out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina Omar's email address in tidspbridge's TODO file seems to be outdated. Resending to more recent addresses which hopefully won't bounce. Given the total lack of response here, I suggest just deleting the driver. No one has ever done the real work that is going to be required to get this code out of staging. It has had build errors causing it to not even be usable for some kernel versions with no one noticing, so I doubt anyone cares about it anymore here. Cc'ing some more people who might be interested. If no one offers to work on the driver in the next couple of days, I'll send a patch to remove it. Kristina -- 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: Anybody working on tidspbridge?
Hello, Given the total lack of response here, I suggest just deleting the driver. No one has ever done the real work that is going to be required to get this code out of staging. It has had build errors causing it to not even be usable for some kernel versions with no one noticing, so I doubt anyone cares about it anymore here. Cc'ing some more people who might be interested. If no one offers to work on the driver in the next couple of days, I'll send a patch to remove it. I'm using the driver (with kernel 3.7) and it works reasonably well for me; removing it seems a bit harsh regards, p. -- Peter Meerwald +43-664-218 (mobile) -- 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-send PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
This patch was already send twice on 2013-10-18 and 2014-05-13. Adding
more people in Cc to review the patch.
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 65 +++
1 file changed, 65 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 20b4398..45b5113 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -273,6 +273,56 @@ static struct omap_hwmod dra7xx_ctrl_module_wkup_hwmod = {
};
/*
+ * 'gmac' class
+ * cpsw/gmac sub system
+ */
+static struct omap_hwmod_class_sysconfig dra7xx_gmac_sysc = {
+ .rev_offs = 0x0,
+ .sysc_offs = 0x8,
+ .syss_offs = 0x4,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
+ MSTANDBY_NO),
+ .sysc_fields= omap_hwmod_sysc_type3,
+};
+
+static struct omap_hwmod_class dra7xx_gmac_hwmod_class = {
+ .name = gmac,
+ .sysc = dra7xx_gmac_sysc,
+};
+
+static struct omap_hwmod dra7xx_gmac_hwmod = {
+ .name = gmac,
+ .class = dra7xx_gmac_hwmod_class,
+ .clkdm_name = gmac_clkdm,
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
+ .main_clk = dpll_gmac_ck,
+ .mpu_rt_idx = 1,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_GMAC_GMAC_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_GMAC_GMAC_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
+ * 'mdio' class
+ */
+static struct omap_hwmod_class dra7xx_mdio_hwmod_class = {
+ .name = davinci_mdio,
+};
+
+static struct omap_hwmod dra7xx_mdio_hwmod = {
+ .name = davinci_mdio,
+ .class = dra7xx_mdio_hwmod_class,
+ .clkdm_name = gmac_clkdm,
+ .main_clk = dpll_gmac_ck,
+};
+
+/*
* 'dcan' class
*
*/
@@ -1999,6 +2049,19 @@ static struct omap_hwmod_ocp_if
dra7xx_l4_wkup__ctrl_module_wkup = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__cpgmac0 = {
+ .master = dra7xx_l4_per2_hwmod,
+ .slave = dra7xx_gmac_hwmod,
+ .clk= dpll_gmac_ck,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if dra7xx_gmac__mdio = {
+ .master = dra7xx_gmac_hwmod,
+ .slave = dra7xx_mdio_hwmod,
+ .user = OCP_USER_MPU,
+};
+
/* l4_wkup - dcan1 */
static struct omap_hwmod_ocp_if dra7xx_l4_wkup__dcan1 = {
.master = dra7xx_l4_wkup_hwmod,
@@ -2642,6 +2705,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_wkup__ctrl_module_wkup,
dra7xx_l4_wkup__dcan1,
dra7xx_l4_per2__dcan2,
+ dra7xx_l4_per2__cpgmac0,
+ dra7xx_gmac__mdio,
dra7xx_l4_cfg__dma_system,
dra7xx_l3_main_1__dss,
dra7xx_l3_main_1__dispc,
--
2.0.0.390.gcb682f8
--
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/7] regulator: Add DT bindings for tps65218 PMIC regulators.
On Tue, Jul 08, 2014 at 03:46:32PM +0530, Keerthy wrote:
Add DT bindings for tps65218 PMIC regulators.
Signed-off-by: Keerthy j-keer...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
Changes in V2:
* Added dcdc3, dcdc5, dcdc6 compatible properties.
.../devicetree/bindings/regulator/tps65218.txt | 23
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt
b/Documentation/devicetree/bindings/regulator/tps65218.txt
new file mode 100644
index 000..fccc1d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -0,0 +1,23 @@
+TPS65218 family of regulators
+
+Required properties:
+For tps65218 regulators/LDOs
+- compatible:
+ - ti,tps65218-dcdc1 for DCDC1
+ - ti,tps65218-dcdc2 for DCDC2
+ - ti,tps65218-dcdc3 for DCDC3
+ - ti,tps65218-dcdc4 for DCDC4
+ - ti,tps65218-dcdc5 for DCDC5
+ - ti,tps65218-dcdc6 for DCDC6
+ - ti,tps65218-ldo1 for LDO1
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+ xyz: regulator@0 {
+ compatible = ti,tps65218-dcdc1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 300;
+ };
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 1/7] mfd: Add DT bindings for tps65218 PMIC
On Tue, Jul 08, 2014 at 03:46:31PM +0530, Keerthy wrote:
Add DT bindings for tps65218 PMIC
Signed-off-by: Keerthy j-keer...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
Changes in V2:
* Added dcdc3, dcdc5, dcdc6 compatible properties.
Documentation/devicetree/bindings/mfd/tps65218.txt | 89
1 file changed, 89 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps65218.txt
b/Documentation/devicetree/bindings/mfd/tps65218.txt
new file mode 100644
index 000..01ac973
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65218.txt
@@ -0,0 +1,89 @@
+Texas Instruments TPS65218 family
+
+The TPS65218 are Integrated Power Management Chips.
+
+Required properties:
+- compatible : Must be ti,tps65218;
+ For Integrated power-management used in AM437x based boards
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the tps65218 supports several interrupts
+ internally, it is considered as an interrupt controller cascaded to the
+ SoC one.
+- #interrupt-cells = 2;
+- interrupt-parent : The parent interrupt controller which is gic.
+
+Optional node:
+- TPS65218 PMIC has a number of child nodes. Mainly the regularors and SMPSs.
+
+Example:
+/*
+ * Integrated Power Management Chip
+ */
+tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ /* VDD_CORE voltage limits min of OPP50 and max of OPP100 */
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ /* VDD_MPU voltage limits min of OPP50 and max of OPP_NITRO */
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = ti,tps65218-dcdc3;
+ regulator-name = vdcdc3;
+ regulator-min-microvolt = 135;
+ regulator-max-microvolt = 135;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc4: regulator-dcdc4 {
+ compatible = ti,tps65218-dcdc4;
+ regulator-name = v3_3d;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc5: regulator-dcdc5 {
+ compatible = ti,tps65218-dcdc5;
+ regulator-name = v1_0bat;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ };
+
+ dcdc6: regulator-dcdc6 {
+ compatible = ti,tps65218-dcdc6;
+ regulator-name = v1_8vat;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 3/7] ARM: dts: AM43x: Add TPS65218 device tree nodes
On Tue, Jul 08, 2014 at 03:46:33PM +0530, Keerthy wrote:
Add TPS65218 device tree nodes. i2c clock frequency setting
also added as part of tps65218 nodes addition. As i2c clock
enabling is required.
Signed-off-by: Keerthy j-keer...@ti.com
---
Changes in V2:
* Added dcdc3, dcdc5, dcdc6 nodes.
It might be worth noting that dcdc4 is missing because of a possible
PMIC bug you're dealing with. Other than that:
Reviewed-by: Felipe Balbi ba...@ti.com
arch/arm/boot/dts/am43x-epos-evm.dts | 59
++
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 90098f9..f1ee7495 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -327,6 +327,65 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c0_pins;
+ clock-frequency = 40;
+
+ tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = ti,tps65218-dcdc3;
+ regulator-name = vdcdc3;
+ regulator-min-microvolt = 135;
+ regulator-max-microvolt = 135;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc5: regulator-dcdc5 {
+ compatible = ti,tps65218-dcdc5;
+ regulator-name = v1_0bat;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ };
+
+ dcdc6: regulator-dcdc6 {
+ compatible = ti,tps65218-dcdc6;
+ regulator-name = v1_8bat;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
at24@50 {
compatible = at24,24c256;
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 6/7] regulator: tps65218: Add get_voltage ops for dcdc5 and dcdc6
On Tue, Jul 08, 2014 at 03:46:36PM +0530, Keerthy wrote:
Add get_voltage ops for dcdc5 and dcdc6. Both dcdc5 and 6 are fixed regulators
and hence return min_uV (or max_uV).
Signed-off-by: Keerthy j-keer...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/regulator/tps65218-regulator.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/regulator/tps65218-regulator.c
b/drivers/regulator/tps65218-regulator.c
index 9effe48..700c652 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -151,6 +151,14 @@ static int tps65218_pmic_disable(struct regulator_dev
*dev)
dev-desc-enable_mask, TPS65218_PROTECT_L1);
}
+static int tps65218_pmic_dcdc56_get_voltage(struct regulator_dev *dev)
+{
+ struct tps65218 *tps = rdev_get_drvdata(dev);
+ unsigned int rid = rdev_get_id(dev);
+
+ return tps-info[rid]-min_uV;
+}
+
/* Operations permitted on DCDC1, DCDC2 */
static struct regulator_ops tps65218_dcdc12_ops = {
.is_enabled = regulator_is_enabled_regmap,
@@ -179,6 +187,7 @@ static struct regulator_ops tps65218_dcdc56_pmic_ops = {
.is_enabled = regulator_is_enabled_regmap,
.enable = tps65218_pmic_enable,
.disable= tps65218_pmic_disable,
+ .get_voltage= tps65218_pmic_dcdc56_get_voltage,
};
static const struct regulator_desc regulators[] = {
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 5/7] ARM: dts: AM437x: Add TPS65218 device tree nodes
On Tue, Jul 08, 2014 at 03:46:35PM +0530, Keerthy wrote:
Add TPS65218 device tree nodes. i2c clock frequency setting
also added as part of tps65218 nodes addition. As i2c clock
enabling is required.
Signed-off-by: Keerthy j-keer...@ti.com
---
Changes in V2:
*Added dcdc3, dcdc5, dcdc6 nodes
same thing wrt dcdc4
arch/arm/boot/dts/am437x-gp-evm.dts | 58
+++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 85ca430..f0422c2 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -260,6 +260,64 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c0_pins;
+ clock-frequency = 40;
+
+ tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = ti,tps65218-dcdc3;
+ regulator-name = vdcdc3;
+ regulator-min-microvolt = 135;
+ regulator-max-microvolt = 135;
+ regulator-boot-on;
+ regulator-always-on;
+ };
add a blank line here
Reviewed-by: Felipe Balbi ba...@ti.com
+ dcdc5: regulator-dcdc5 {
+ compatible = ti,tps65218-dcdc5;
+ regulator-name = v1_0bat;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ };
+
+ dcdc6: regulator-dcdc6 {
+ compatible = ti,tps65218-dcdc6;
+ regulator-name = v1_8bat;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
};
i2c1 {
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 4/7] ARM: dts: AM437x: Fix i2c nodes indentation
On Tue, Jul 08, 2014 at 03:46:34PM +0530, Keerthy wrote:
Fix i2c nodes indentation.
Signed-off-by: Keerthy j-keer...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 003766c..85ca430 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -257,16 +257,15 @@
};
i2c0 {
-status = okay;
-pinctrl-names = default;
-pinctrl-0 = i2c0_pins;
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pins;
};
i2c1 {
-status = okay;
-pinctrl-names = default;
-pinctrl-0 = i2c1_pins;
-
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
pixcir_ts@5c {
compatible = pixcir,pixcir_tangoc;
pinctrl-names = default;
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 6/7] regulator: tps65218: Add get_voltage ops for dcdc5 and dcdc6
On Tue, Jul 08, 2014 at 03:46:36PM +0530, Keerthy wrote:
+static int tps65218_pmic_dcdc56_get_voltage(struct regulator_dev *dev)
+{
+ struct tps65218 *tps = rdev_get_drvdata(dev);
+ unsigned int rid = rdev_get_id(dev);
+
+ return tps-info[rid]-min_uV;
+}
Set fixed_uV in the descriptor.
signature.asc
Description: Digital signature
Re: Anybody working on tidspbridge?
On Tue, Jul 08, 2014 at 03:03:58PM +0200, Peter Meerwald wrote: Hello, Given the total lack of response here, I suggest just deleting the driver. No one has ever done the real work that is going to be required to get this code out of staging. It has had build errors causing it to not even be usable for some kernel versions with no one noticing, so I doubt anyone cares about it anymore here. Cc'ing some more people who might be interested. If no one offers to work on the driver in the next couple of days, I'll send a patch to remove it. I'm using the driver (with kernel 3.7) and it works reasonably well for me; removing it seems a bit harsh Using it is different from being able to maintain the code and move it out of the staging tree. Also, 3.7 is really old and obsolete, not much we can do with that kernel version :) Are you able to work on the code and do the effort needed to get it out of the staging tree? If so, great, if not, we are going to have to delete it, sorry. greg k-h -- 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: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
Hi Ohad, On 07/04/2014 12:01 AM, Ohad Ben-Cohen wrote: Hi Suman, On Thu, Jul 3, 2014 at 8:28 PM, Suman Anna s-a...@ti.com wrote: OK, but we would still require this function to lookup the registered device from the controller-phandle to retrieve the base_id. Can we retrieve the base_id from the parent DT node itself? Yeah, it is possible using the of_hwspin_lock_get_base_id function added in Patch8, once we convert the phandle to a device node. The platform implementations would be using this function during the registration phase to register the base id, and we have to do the DT parse/lookup again in the core. regards Suman -- 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: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
Hi Ohad, On 07/03/2014 11:58 PM, Ohad Ben-Cohen wrote: Hi Suman, On Thu, Jul 3, 2014 at 8:35 PM, Suman Anna s-a...@ti.com wrote: Not at the moment, with the existing platform implementations. So, if I understand you correctly, you are asking to leave out the xlate ops and make the of_hwspin_lock_simple_xlate() internal until a need for an xlate method arises. Yes, please. It seems to me this way we're reducing complexity without compromising anything. OK, will make this change and add a comment in the code in the next version. This also means, we only support a value of 1 for #hwlock-cells. When a different #hwlock-cells value shows up, someone would have to write a new xlate implementation anyway. At the same time, the xlate ops could be brought back quite easily. Since we're not imposing anything on the DT data, this doesn't affect our ability to support these scenarios in the future, but unless I'm missing a current use case, these scenarios right now seems somewhat fictional. OK, fair enough. But, that would mean DT-based client users would have to invoke two function calls to request a hwspinlock. We already have an API to get the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF API for requesting a lock directly rather than giving an OF API for getting the lock id. This is in keeping in convention with what other drivers do normally - a regular get and an OF get. I can modify it if you still prefer the OF API for getting a global lock id, but I feel its a burden for client users. Let's discuss this. I was actually thinking of the more general use case of an heterogenous system: - driver gets the global lock id from a remote processor - driver then requests the specific lock Looking at these cases, the OF scenario only differs in the small part of fetching the lock id, and if we keep the regular request_specific API we'll have more common code between drivers. What do you think? We should also be thinking about the how to add the support for the reserved locks. Please take a look at the added RFC patches 9 through 13, specifically the reworked Patch 12 [1]. I moved away from adding a reserved property to the controller node, as it means updating both controller and client nodes. Depending on where we enforce the check (in the OF API or in the common request_specific, the behavior would change. Also, do you prefer an open property-name in client users (like I am doing at the moment) or imposing a standard property name hwlocks? Good point - I think we can start with an imposed hwlocks name, and evolve in the future as needed (again, only because we're not really imposing anything on the DT data - this is just kernel code that we could always extend as needed). OK. Actually, I didn't realize that I had already made this change as part of the reserved locks RFC patch. regards Suman [1] http://marc.info/?l=linux-omapm=139968467307977w=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 1/2] remoteproc: use a flag to detect the presence of IOMMU
The remoteproc driver core currently relies on iommu_present() on
the bus the device is on, to perform MMU management. However, this
logic doesn't scale for multi-arch, especially for processors that
do not have an IOMMU. Replace this logic instead by using a h/w
capability flag for the presence of IOMMU in the rproc structure.
The individual platform implementations are required to set this
flag appropriately. The default setting is to not have an MMU.
The OMAP remoteproc driver is updated while at this, to maintain
the functionality with the IOMMU detection logic change in this
patch.
Cc: Sjur Brændeland sjur.brandel...@stericsson.com
Cc: Robert Tivy rt...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/remoteproc/omap_remoteproc.c | 6 ++
drivers/remoteproc/remoteproc_core.c | 15 ++-
include/linux/remoteproc.h | 2 ++
3 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index 5168972..858abf0 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -199,6 +199,12 @@ static int omap_rproc_probe(struct platform_device *pdev)
oproc = rproc-priv;
oproc-rproc = rproc;
+ /*
+* All existing OMAP IPU and DSP processors do have an MMU, and
+* are expected to use MMU, so this statement suffices.
+* XXX: Replace this logic if and when a need arises.
+*/
+ rproc-has_iommu = true;
platform_set_drvdata(pdev, rproc);
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 3cd85a6..11cdb11 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -94,19 +94,8 @@ static int rproc_enable_iommu(struct rproc *rproc)
struct device *dev = rproc-dev.parent;
int ret;
- /*
-* We currently use iommu_present() to decide if an IOMMU
-* setup is needed.
-*
-* This works for simple cases, but will easily fail with
-* platforms that do have an IOMMU, but not for this specific
-* rproc.
-*
-* This will be easily solved by introducing hw capabilities
-* that will be set by the remoteproc driver.
-*/
- if (!iommu_present(dev-bus)) {
- dev_dbg(dev, iommu not found\n);
+ if (!rproc-has_iommu) {
+ dev_dbg(dev, iommu not present\n);
return 0;
}
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 9e7e745..78b8a9b 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -404,6 +404,7 @@ enum rproc_crash_type {
* @table_ptr: pointer to the resource table in effect
* @cached_table: copy of the resource table
* @table_csum: checksum of the resource table
+ * @has_iommu: flag to indicate if remote processor is behind an MMU
*/
struct rproc {
struct klist_node node;
@@ -435,6 +436,7 @@ struct rproc {
struct resource_table *table_ptr;
struct resource_table *cached_table;
u32 table_csum;
+ bool has_iommu;
};
/* we currently support only two vrings per rvdev */
--
2.0.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 2/2] remoteproc: add support to handle internal memories
A remote processor may need to load certain firmware sections into
internal memories (eg: RAM at L1 or L2 levels) for performance or
other reasons. Introduce a new resource type (RSC_INTMEM) and add
an associated handler function to handle such memories. The handler
creates a kernel mapping for the resource's 'pa' (physical address).
Note that no iommu mapping is performed for this resource, as the
resource is primarily used to represent physical internal memories.
If the internal memory region can only be accessed through an iommu,
a devmem resource entry should be used instead.
Signed-off-by: Robert Tivy rt...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/remoteproc/remoteproc_core.c | 85 +++-
include/linux/remoteproc.h | 43 +-
2 files changed, 126 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 11cdb11..e2bd869 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -664,6 +664,84 @@ free_carv:
return ret;
}
+/**
+ * rproc_handle_intmem() - handle internal memory resource entry
+ * @rproc: rproc handle
+ * @rsc: the intmem resource entry
+ * @offset: offset of the resource data in resource table
+ * @avail: size of available data (for image validation)
+ *
+ * This function will handle firmware requests for mapping a memory region
+ * internal to a remote processor into kernel. It neither allocates any
+ * physical pages, nor performs any iommu mapping, as this resource entry
+ * is primarily used for representing physical internal memories. If the
+ * internal memory region can only be accessed through an iommu, please
+ * use a devmem resource entry.
+ *
+ * These resource entries should be grouped near the carveout entries in
+ * the firmware's resource table, as other firmware entries might request
+ * placing other data objects inside these memory regions (e.g. data/code
+ * segments, trace resource entries, ...).
+ */
+static int rproc_handle_intmem(struct rproc *rproc, struct fw_rsc_intmem *rsc,
+ int offset, int avail)
+{
+ struct rproc_mem_entry *intmem;
+ struct device *dev = rproc-dev;
+ void *va;
+ int ret;
+
+ if (sizeof(*rsc) avail) {
+ dev_err(dev, intmem rsc is truncated\n);
+ return -EINVAL;
+ }
+
+ if (rsc-version != 1) {
+ dev_err(dev, intmem rsc version %d is not supported\n,
+ rsc-version);
+ return -EINVAL;
+ }
+
+ if (rsc-reserved) {
+ dev_err(dev, intmem rsc has non zero reserved bytes\n);
+ return -EINVAL;
+ }
+
+ dev_dbg(dev, intmem rsc: da 0x%x, pa 0x%x, len 0x%x\n,
+ rsc-da, rsc-pa, rsc-len);
+
+ intmem = kzalloc(sizeof(*intmem), GFP_KERNEL);
+ if (!intmem) {
+ dev_err(dev, kzalloc carveout failed\n);
+ return -ENOMEM;
+ }
+
+ va = (__force void *)ioremap_nocache(rsc-pa, rsc-len);
+ if (!va) {
+ dev_err(dev, ioremap_nocache err: %d\n, rsc-len);
+ ret = -ENOMEM;
+ goto free_intmem;
+ }
+
+ dev_dbg(dev, intmem mapped pa 0x%x of len 0x%x into kernel va %p\n,
+ rsc-pa, rsc-len, va);
+
+ intmem-va = va;
+ intmem-len = rsc-len;
+ intmem-dma = rsc-pa;
+ intmem-da = rsc-da;
+ intmem-priv = (void *)1;/* prevents freeing */
+
+ /* reuse the rproc-carveouts list, so that loading is automatic */
+ list_add_tail(intmem-node, rproc-carveouts);
+
+ return 0;
+
+free_intmem:
+ kfree(intmem);
+ return ret;
+}
+
static int rproc_count_vrings(struct rproc *rproc, struct fw_rsc_vdev *rsc,
int offset, int avail)
{
@@ -681,6 +759,7 @@ static rproc_handle_resource_t
rproc_loading_handlers[RSC_LAST] = {
[RSC_CARVEOUT] = (rproc_handle_resource_t)rproc_handle_carveout,
[RSC_DEVMEM] = (rproc_handle_resource_t)rproc_handle_devmem,
[RSC_TRACE] = (rproc_handle_resource_t)rproc_handle_trace,
+ [RSC_INTMEM] = (rproc_handle_resource_t)rproc_handle_intmem,
[RSC_VDEV] = NULL, /* VDEVs were handled upon registrarion */
};
@@ -768,7 +847,11 @@ static void rproc_resource_cleanup(struct rproc *rproc)
/* clean up carveout allocations */
list_for_each_entry_safe(entry, tmp, rproc-carveouts, node) {
- dma_free_coherent(dev-parent, entry-len, entry-va,
entry-dma);
+ if (!entry-priv)
+ dma_free_coherent(dev-parent, entry-len, entry-va,
+ entry-dma);
+ else
+ iounmap((__force void __iomem *)entry-va);
list_del(entry-node);
kfree(entry);
}
diff --git
[PATCH 0/2] couple of generic remoteproc enhancements
Hi Ohad, The following are couple of generic enhancements to the remoteproc core. The changes are developed to support adding new rproc drivers for processors like the WkupM3 processor on AM335/AM437, but are generic enough to apply to non-OMAP devices as well. The first patch allows MMU-enabled processors like OMAP IPU/DSP as well as other non-MMU enabled processors on multi-arch kernel images. The second-patch was developed as part of enabling internal memory loading of firmware segments on OMAP DSPs, but will also be used by the WkupM3 remoteproc driver that Dave Gerlach is gonna submit soon. The two patches are based on 3.16-rc4 and are technically independent of each other, but submitting them together as the WkupM3 remoteproc driver would need both of them. regards Suman Suman Anna (2): remoteproc: use a flag to detect the presence of IOMMU remoteproc: add support to handle internal memories drivers/remoteproc/omap_remoteproc.c | 6 +++ drivers/remoteproc/remoteproc_core.c | 100 ++- include/linux/remoteproc.h | 45 +++- 3 files changed, 136 insertions(+), 15 deletions(-) -- 2.0.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 V2] ASoC: omap-mcbsp: Use devm_snd_soc_register_component
Replaced snd_soc_register_component with its devres equivalent,
devm_snd_soc_register_component.
Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com
---
Changes since V1:
Aligned function parameter properly.
:100644 100644 efe2cd6... bd3ef2a... M sound/soc/omap/omap-mcbsp.c
sound/soc/omap/omap-mcbsp.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index efe2cd6..bd3ef2a 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -805,8 +805,9 @@ static int asoc_mcbsp_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = snd_soc_register_component(pdev-dev, omap_mcbsp_component,
-omap_mcbsp_dai, 1);
+ ret = devm_snd_soc_register_component(pdev-dev,
+ omap_mcbsp_component,
+ omap_mcbsp_dai, 1);
if (ret)
return ret;
@@ -817,8 +818,6 @@ static int asoc_mcbsp_remove(struct platform_device *pdev)
{
struct omap_mcbsp *mcbsp = platform_get_drvdata(pdev);
- snd_soc_unregister_component(pdev-dev);
-
if (mcbsp-pdata-ops mcbsp-pdata-ops-free)
mcbsp-pdata-ops-free(mcbsp-id);
--
1.7.10.4
--
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] ASoC: omap-hdmi: Use devm_snd_soc_register_component
Replaced snd_soc_register_component with its devres equivalent,
devm_snd_soc_register_component.
Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com
---
Changes since V1:
Aligned function parameter properly.
:100644 100644 eb9c392... 8dcd7f7... M sound/soc/omap/omap-hdmi.c
sound/soc/omap/omap-hdmi.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index eb9c392..8dcd7f7 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -322,8 +322,9 @@ static int omap_hdmi_probe(struct platform_device *pdev)
}
dev_set_drvdata(pdev-dev, hdmi_data);
- ret = snd_soc_register_component(pdev-dev, omap_hdmi_component,
-omap_hdmi_dai, 1);
+ ret = devm_snd_soc_register_component(pdev-dev,
+ omap_hdmi_component,
+ omap_hdmi_dai, 1);
if (ret)
return ret;
@@ -335,8 +336,6 @@ static int omap_hdmi_remove(struct platform_device *pdev)
{
struct hdmi_priv *hdmi_data = dev_get_drvdata(pdev-dev);
- snd_soc_unregister_component(pdev-dev);
-
if (hdmi_data == NULL) {
dev_err(pdev-dev, cannot obtain HDMi data\n);
return -ENODEV;
--
1.7.10.4
--
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] ASoC: omap-dmic: Use devm_snd_soc_register_component
Replaced snd_soc_register_component with its devres equivalent,
devm_snd_soc_register_component.
Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com
---
Changes since V1:
Aligned function parameter properly.
:100644 100644 6925d71... f125eb9... M sound/soc/omap/omap-dmic.c
sound/soc/omap/omap-dmic.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 6925d71..f125eb9 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -490,8 +490,9 @@ static int asoc_dmic_probe(struct platform_device *pdev)
}
- ret = snd_soc_register_component(pdev-dev, omap_dmic_component,
-omap_dmic_dai, 1);
+ ret = devm_snd_soc_register_component(pdev-dev,
+ omap_dmic_component,
+ omap_dmic_dai, 1);
if (ret)
goto err_put_clk;
@@ -510,7 +511,6 @@ static int asoc_dmic_remove(struct platform_device *pdev)
{
struct omap_dmic *dmic = platform_get_drvdata(pdev);
- snd_soc_unregister_component(pdev-dev);
clk_put(dmic-fclk);
return 0;
--
1.7.10.4
--
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/6] mailbox/omap: add support for parsing dt devices
Hi Tony, Pavel,
On 07/04/2014 03:23 AM, Tony Lindgren wrote:
* Pavel Machek pa...@ucw.cz [140704 01:07]:
Hi!
The non-DT support has to be maintained for now to not break
OMAP3 legacy boot, and the legacy-style code will be cleaned
up once OMAP3 is also converted to DT-boot only.
@@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct
omap_mbox_device *mdev)
return 0;
}
+static const struct omap_mbox_device_data omap2_data = {
+ .num_users = 4,
+ .num_fifos = 6,
+ .intr_type = MBOX_INTR_CFG_TYPE1,
+};
+
+static const struct omap_mbox_device_data omap3_data = {
+ .num_users = 2,
+ .num_fifos = 2,
+ .intr_type = MBOX_INTR_CFG_TYPE1,
+};
+
+static const struct omap_mbox_device_data am335x_data = {
+ .num_users = 4,
+ .num_fifos = 8,
+ .intr_type = MBOX_INTR_CFG_TYPE2,
+};
Aha, ok, then the intr_type should be derived from
compatible-string. Or rather... you should have three
compatible-strings for the three possibilities? (And then subtype,
currently unused, in case there are more hw differences).
The compatible string can and should be separate for each revision
unless they are the same exacat hardware revision.
ACK.
I checked the revision register from all SoCs. OMAP2 and OMAP3 have
different revisions compared to OMAP4+. All of OMAP4, OMAP5, DRA7,
AM335x and AM437x have the same version, but with different num-fifos
and num-users. So, I can switch back to using omap4-mailbox for all of
these SoCs only if we encode the num-fifos and num-users in DT.
two are HW IP design parameters, so in general putting them in DT isn't
completely a bad idea, but I will wait to see if there are any further
comments on this from Tony or DT maintainers before I make changes.
Ok, right... I'd vote for putting them into DT.
I would avoid adding custom DT properties where possible and let the
driver just initialize the right data based on the compatible flag.
If these are HW IP design parameters, we can expect to see many
different combinations. Yet we know ahead of time how to handle
different parameters HW people select.
That's right, the above OMAP4+ SoCs already demonstrate this behavior.
Thus IMO we should do it in the device tree.
Oh you mean from supporting new hardware with just .dts changes?
From that point of view it makes sense to have them as DT properties,
so I'm fine with that.
Let's just try to use something that's generic like fifosize. No idea
how the property for num_fifos should be handled though as that
implies some knowledge in the driver which num_users have fifos?
The fifos are not per num_users, but rather the total number of fifos
within the IP block. The num_users will be the number of targets the IP
block can interrupt. I tried looking for generic properties, but there
weren't any that seem to fit the description. If you want generic names,
I can use num-fifos and num-users, otherwise will stick to the
names defined in the previous series.
So unless that can be described clearly in a DT property as well,
the binding might be still unusable for new hardware :)
I don't expect the OMAP mailbox IP to change much in the future. There
is a FIFO depth parameter as well, but that's constant in all the
current versions, and even if they change it, I can already use the
generic property for that.
Tony,
Depending on the agreement here, I may have to respin the OMAP
mailbox DT/hwmod cleanup series [1]
regards
Suman
[1] http://marc.info/?l=linux-omapm=140365833121612w=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: Anybody working on tidspbridge?
Hi Peter, On 07/08/2014 09:36 AM, Greg KH wrote: On Tue, Jul 08, 2014 at 03:03:58PM +0200, Peter Meerwald wrote: Hello, Given the total lack of response here, I suggest just deleting the driver. No one has ever done the real work that is going to be required to get this code out of staging. It has had build errors causing it to not even be usable for some kernel versions with no one noticing, so I doubt anyone cares about it anymore here. Cc'ing some more people who might be interested. If no one offers to work on the driver in the next couple of days, I'll send a patch to remove it. I'm using the driver (with kernel 3.7) and it works reasonably well for me; removing it seems a bit harsh. Using it is different from being able to maintain the code and move it out of the staging tree. Also, 3.7 is really old and obsolete, not much we can do with that kernel version :) Are you able to work on the code and do the effort needed to get it out of the staging tree? If so, great, if not, we are going to have to delete it, sorry. I agree with Greg here. In fact, the current TODO does not do enough justice to the amount of work required to make it even work on the latest kernel. Most of the TIers who worked on this driver have moved on as Kristina would have figured with her bounced emails. So I do suggest that this driver be deleted from the kernel tree. If there are enough number of folks using it (not sure how many are out there), it can be worked on out-of-tree and brought back in a cleaner fashion rather than keeping a broken stale driver in the kernel. regards Suman -- 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 3/3] arm: dts: dra7: fixup qspi entry
The core complains that the number 343 is too large. The older code has here 124. This avoids the warning, the driver hasn't been tested. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- arch/arm/boot/dts/dra7.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index daf7d36..1529bca 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -821,7 +821,7 @@ clocks = qspi_gfclk_div; clock-names = fck; num-cs = 4; - interrupts = 0 343 0x4; + interrupts = 0 124 0x4; status = disabled; }; -- 2.0.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 2/3] arm: dts: dra7: Enable CPSW and MDIO for dra7xx EVM
From: Mugunthan V N mugunthan...@ti.com
Adding CPSW phy-id, CPSW and MDIO pinmux configuration for active
and sleep states and enable them in board evm dts file.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
[Resolved merge conflict and rebased on 3.8 kernel.
Update the pinmux configuration for CPSW and MDIO by removing the
macro definitons to match the 3.8 implementation.]
Signed-off-by: Praveen Rao p...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/dra7-evm.dts | 61 ++
arch/arm/boot/dts/dra7.dtsi| 48 +
2 files changed, 109 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4adc280..956a7bd 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -94,6 +94,46 @@
;
};
+ cpsw_default_pins: pinmux_cpsw_default_pins {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x250 0x0 /* rgmii1_tclk PIN_OUTPUT | MUX_MODE0 */
+ 0x254 0x0 /* rgmii1_tctl PIN_OUTPUT | MUX_MODE0 */
+ 0x258 0x0 /* rgmii1_td3 PIN_OUTPUT | MUX_MODE0 */
+ 0x25c 0x0 /* rgmii1_td2 PIN_OUTPUT | MUX_MODE0 */
+ 0x260 0x0 /* rgmii1_td1 PIN_OUTPUT | MUX_MODE0 */
+ 0x264 0x0 /* rgmii1_td0 PIN_OUTPUT | MUX_MODE0 */
+ 0x268 0x0004 /* rgmii1_rclk PIN_INPUT | MUX_MODE0
*/
+ 0x26c 0x0004 /* rgmii1_rctl PIN_INPUT | MUX_MODE0
*/
+ 0x270 0x0004 /* rgmii1_rd3 PIN_INPUT | MUX_MODE0
*/
+ 0x274 0x0004 /* rgmii1_rd2 PIN_INPUT | MUX_MODE0
*/
+ 0x278 0x0004 /* rgmii1_rd1 PIN_INPUT | MUX_MODE0
*/
+ 0x27c 0x0004 /* rgmii1_rd0 PIN_INPUT | MUX_MODE0
*/
+
+ /* Slave 2 */
+ 0x198 0x4 /* rgmii2_tclk PIN_OUTPUT | MUX_MODE4 */
+ 0x19c 0x4 /* rgmii2_tctl PIN_OUTPUT | MUX_MODE4 */
+ 0x1a0 0x4 /* rgmii2_td3 PIN_OUTPUT | MUX_MODE4 */
+ 0x1a4 0x4 /* rgmii2_td2 PIN_OUTPUT | MUX_MODE4 */
+ 0x1a8 0x4 /* rgmii2_td1 PIN_OUTPUT | MUX_MODE4 */
+ 0x1ac 0x4 /* rgmii2_td0 PIN_OUTPUT | MUX_MODE4 */
+ 0x1b0 0x00040004 /* rgmii2_rclk PIN_INPUT | MUX_MODE4
*/
+ 0x1b4 0x00040004 /* rgmii2_rctl PIN_INPUT | MUX_MODE4
*/
+ 0x1b8 0x00040004 /* rgmii2_rd3 PIN_INPUT | MUX_MODE4
*/
+ 0x1bc 0x00040004 /* rgmii2_rd2 PIN_INPUT | MUX_MODE4
*/
+ 0x1c0 0x00040004 /* rgmii2_rd1 PIN_INPUT | MUX_MODE4
*/
+ 0x1c4 0x00040004 /* rgmii2_rd0 PIN_INPUT | MUX_MODE4
*/
+ ;
+ };
+
+ davinci_mdio_default_pins: pinmux_davinci_mdio_default_pins {
+ pinctrl-single,pins =
+ /* MDIO */
+ 0x23c 0x3 /* mdio_data PIN_OUTPUT_PULLUP |
MUX_MODE0 */
+ 0x240 0x7 /* mdio_clk PIN_INPUT_PULLUP |
MUX_MODE0 */
+ ;
+ };
+
qspi1_pins: pinmux_qspi1_pins {
pinctrl-single,pins =
0x4c (PIN_INPUT | MUX_MODE1) /* gpmc_a3.qspi1_cs2 */
@@ -332,6 +372,27 @@
cpu0-supply = smps123_reg;
};
+gmac {
+ status=okay;
+ pinctrl-names = default;
+ pinctrl-0 = cpsw_default_pins;
+};
+
+davinci_mdio {
+ pinctrl-names = default;
+ pinctrl-0 = davinci_mdio_default_pins;
+};
+
+cpsw_emac0 {
+ phy_id = davinci_mdio, 2;
+ phy-mode = rgmii-txid;
+};
+
+cpsw_emac1 {
+ phy_id = davinci_mdio, 3;
+ phy-mode = rgmii-txid;
+};
+
qspi {
status = okay;
pinctrl-names = default;
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index c29945e..daf7d36 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -763,6 +763,54 @@
status = disabled;
};
+ gmac: ethernet@48484000 {
+ compatible = ti,cpsw;
+ ti,hwmods = gmac;
+ cpdma_channels = 8;
+ ale_entries = 1024;
+ bd_ram_size = 0x2000;
+ no_bd_ram = 0;
+ rx_descs = 64;
+ mac_control = 0x20;
+ slaves = 2;
+ active_slave = 0;
+ cpts_clock_mult = 0x8000;
+ cpts_clock_shift = 29;
+ reg = 0x48484000 0x800
+ 0x48485200 0x100;
+
[PATCH 1/3] arm: dra7xx: Add hwmod data for MDIO and CPSW
Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Praveen Rao p...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 96 +++
1 file changed, 96 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 20b4398..0fa2c66 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1845,6 +1845,85 @@ static struct omap_hwmod dra7xx_vcp2_hwmod = {
};
/*
+ * 'gmac' class
+ * cpsw/gmac sub system
+ */
+static struct omap_hwmod_class_sysconfig dra7xx_gmac_sysc = {
+ .rev_offs = 0x0,
+ .sysc_offs = 0x8,
+ .syss_offs = 0x4,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
+ MSTANDBY_NO),
+ .sysc_fields= omap_hwmod_sysc_type3,
+};
+
+static struct omap_hwmod_class dra7xx_gmac_hwmod_class = {
+ .name = gmac,
+ .sysc = dra7xx_gmac_sysc,
+};
+
+static struct omap_hwmod_irq_info dra7xx_gmac_irqs[] = {
+ { .name = c0_rx_thresh_pend, .irq = 50 + DRA7XX_IRQ_GIC_START, },
+ { .name = c0_rx_pend, .irq = 51 + DRA7XX_IRQ_GIC_START, },
+ { .name = c0_tx_pend, .irq = 52 + DRA7XX_IRQ_GIC_START, },
+ { .name = c0_misc_pend, .irq = 53 + DRA7XX_IRQ_GIC_START, },
+ { .irq = -1 },
+};
+static struct omap_hwmod_addr_space dra7xx_gmac_addr_space[] = {
+ /* cpsw ss */
+ {
+ .pa_start = 0x48484000,
+ .pa_end = 0x48484000 + SZ_2K - 1,
+ },
+ /* cpsw wr */
+ {
+ .pa_start = 0x48485200,
+ .pa_end = 0x48485200 + SZ_256 - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+static struct omap_hwmod dra7xx_gmac_hwmod = {
+ .name = gmac,
+ .class = dra7xx_gmac_hwmod_class,
+ .clkdm_name = gmac_clkdm,
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
+ .mpu_irqs = dra7xx_gmac_irqs,
+ .main_clk = dpll_gmac_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_GMAC_GMAC_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_GMAC_GMAC_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
+ * 'mdio' class
+ */
+static struct omap_hwmod_class dra7xx_mdio_hwmod_class = {
+ .name = davinci_mdio,
+};
+
+static struct omap_hwmod_addr_space dra7xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x48485000,
+ .pa_end = 0x48485000 + SZ_256 - 1,
+ },
+ { }
+};
+static struct omap_hwmod dra7xx_mdio_hwmod = {
+ .name = davinci_mdio,
+ .class = dra7xx_mdio_hwmod_class,
+ .clkdm_name = gmac_clkdm,
+ .main_clk = dpll_gmac_ck,
+};
+
+/*
* 'wd_timer' class
*
*/
@@ -2015,6 +2094,21 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per2__dcan2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__gmac = {
+ .master = dra7xx_l4_per2_hwmod,
+ .slave = dra7xx_gmac_hwmod,
+ .clk= dpll_gmac_ck,
+ .addr = dra7xx_gmac_addr_space,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if dra7xx_gmac__mdio = {
+ .master = dra7xx_gmac_hwmod,
+ .slave = dra7xx_mdio_hwmod,
+ .addr = dra7xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_addr_space dra7xx_dma_system_addrs[] = {
{
.pa_start = 0x4a056000,
@@ -2642,6 +2736,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_wkup__ctrl_module_wkup,
dra7xx_l4_wkup__dcan1,
dra7xx_l4_per2__dcan2,
+ dra7xx_l4_per2__gmac,
+ dra7xx_gmac__mdio,
dra7xx_l4_cfg__dma_system,
dra7xx_l3_main_1__dss,
dra7xx_l3_main_1__dispc,
--
2.0.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 3/3] regulators: tps65218: drop order dependency
By just using GCC's array initialization extension, we
can easily drop order dependency between tps65218_regulattors
enumeration and tps65218_pmic_regs array.
Signed-of-by: Felipe Balbi ba...@ti.com
---
drivers/regulator/tps65218-regulator.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/tps65218-regulator.c
b/drivers/regulator/tps65218-regulator.c
index 7fc8b3a..b5dc314 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -49,7 +49,7 @@ enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4, DCDC5,
DCDC6, LDO1 };
} \
#define TPS65218_INFO(_id, _nm, _min, _max)\
- { \
+ [_id] = { \
.id = _id, \
.name = _nm, \
.min_uV = _min, \
@@ -72,13 +72,13 @@ static const struct regulator_linear_range dcdc4_ranges[] =
{
};
static struct tps_info tps65218_pmic_regs[] = {
- TPS65218_INFO(0, DCDC1, 85, 167500),
- TPS65218_INFO(1, DCDC2, 85, 1675000),
- TPS65218_INFO(2, DCDC3, 90, 340),
- TPS65218_INFO(3, DCDC4, 1175000, 340),
- TPS65218_INFO(4, DCDC5, 100, 100),
- TPS65218_INFO(5, DCDC6, 180, 180),
- TPS65218_INFO(6, LDO1, 90, 340),
+ TPS65218_INFO(DCDC1, DCDC1, 85, 167500),
+ TPS65218_INFO(DCDC2, DCDC2, 85, 1675000),
+ TPS65218_INFO(DCDC3, DCDC3, 90, 340),
+ TPS65218_INFO(DCDC4, DCDC4, 1175000, 340),
+ TPS65218_INFO(DCDC5, DCDC5, 100, 100),
+ TPS65218_INFO(DCDC6, DCDC6, 180, 180),
+ TPS65218_INFO(LDO1, LDO1, 90, 340),
};
#define TPS65218_OF_MATCH(comp, label) \
--
2.0.0.390.gcb682f8
--
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 2/3] regulator: tps65218: drop unneeded field from our regulator macro
volt table is always NULL for all regulators,
might as well drop the argument.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/regulator/tps65218-regulator.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/tps65218-regulator.c
b/drivers/regulator/tps65218-regulator.c
index 8b7a0a9..7fc8b3a 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -29,7 +29,7 @@
enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4, DCDC5, DCDC6, LDO1 };
-#define TPS65218_REGULATOR(_name, _id, _ops, _n, _vr, _vm, _er, _em, _t, \
+#define TPS65218_REGULATOR(_name, _id, _ops, _n, _vr, _vm, _er, _em, \
_lr, _nlr, _delay) \
{ \
.name = _name,\
@@ -42,7 +42,7 @@ enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4, DCDC5,
DCDC6, LDO1 };
.vsel_mask = _vm, \
.enable_reg = _er, \
.enable_mask= _em, \
- .volt_table = _t, \
+ .volt_table = NULL, \
.linear_ranges = _lr, \
.n_linear_ranges= _nlr, \
.ramp_delay = _delay, \
@@ -185,33 +185,32 @@ static const struct regulator_desc regulators[] = {
TPS65218_REGULATOR(DCDC1, TPS65218_DCDC_1, tps65218_dcdc12_ops, 64,
TPS65218_REG_CONTROL_DCDC1,
TPS65218_CONTROL_DCDC1_MASK,
- TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC1_EN, NULL,
+ TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC1_EN,
dcdc1_dcdc2_ranges, 2, 4000),
TPS65218_REGULATOR(DCDC2, TPS65218_DCDC_2, tps65218_dcdc12_ops, 64,
TPS65218_REG_CONTROL_DCDC2,
TPS65218_CONTROL_DCDC2_MASK,
- TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC2_EN, NULL,
+ TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC2_EN,
dcdc1_dcdc2_ranges, 2, 4000),
TPS65218_REGULATOR(DCDC3, TPS65218_DCDC_3, tps65218_ldo1_dcdc34_ops,
64, TPS65218_REG_CONTROL_DCDC3,
TPS65218_CONTROL_DCDC3_MASK, TPS65218_REG_ENABLE1,
- TPS65218_ENABLE1_DC3_EN, NULL,
- ldo1_dcdc3_ranges, 2, 0),
+ TPS65218_ENABLE1_DC3_EN, ldo1_dcdc3_ranges, 2, 0),
TPS65218_REGULATOR(DCDC4, TPS65218_DCDC_4, tps65218_ldo1_dcdc34_ops,
53, TPS65218_REG_CONTROL_DCDC4,
TPS65218_CONTROL_DCDC4_MASK,
- TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC4_EN, NULL,
+ TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC4_EN,
dcdc4_ranges, 2, 0),
TPS65218_REGULATOR(DCDC5, TPS65218_DCDC_5, tps65218_dcdc56_pmic_ops,
1, -1, -1, TPS65218_REG_ENABLE1,
- TPS65218_ENABLE1_DC5_EN, NULL, NULL, 0, 0),
+ TPS65218_ENABLE1_DC5_EN, NULL, 0, 0),
TPS65218_REGULATOR(DCDC6, TPS65218_DCDC_6, tps65218_dcdc56_pmic_ops,
1, -1, -1, TPS65218_REG_ENABLE1,
- TPS65218_ENABLE1_DC6_EN, NULL, NULL, 0, 0),
+ TPS65218_ENABLE1_DC6_EN, NULL, 0, 0),
TPS65218_REGULATOR(LDO1, TPS65218_LDO_1, tps65218_ldo1_dcdc34_ops, 64,
TPS65218_REG_CONTROL_LDO1,
TPS65218_CONTROL_LDO1_MASK, TPS65218_REG_ENABLE2,
- TPS65218_ENABLE2_LDO1_EN, NULL, ldo1_dcdc3_ranges,
+ TPS65218_ENABLE2_LDO1_EN, ldo1_dcdc3_ranges,
2, 0),
};
--
2.0.0.390.gcb682f8
--
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 1/3] regulators: tps65218: fix DCDC4 linear voltage range
The second range of this particular regulator,
starts at 1.60V, not as 1.55V as it was originally
implied by code.
Signed-off-by: Felipe Balbi ba...@ti.com
---
based on datasheet only. Also boot tested on another,
yet-to-be-released HW. A 50mV difference is probably
not a big deal for any users of DCDC4 but it's still
good to be correct.
drivers/regulator/tps65218-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/tps65218-regulator.c
b/drivers/regulator/tps65218-regulator.c
index 9effe48..8b7a0a9 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -68,7 +68,7 @@ static const struct regulator_linear_range
ldo1_dcdc3_ranges[] = {
static const struct regulator_linear_range dcdc4_ranges[] = {
REGULATOR_LINEAR_RANGE(1175000, 0x0, 0xf, 25000),
- REGULATOR_LINEAR_RANGE(155, 0x10, 0x34, 5),
+ REGULATOR_LINEAR_RANGE(160, 0x10, 0x34, 5),
};
static struct tps_info tps65218_pmic_regs[] = {
--
2.0.0.390.gcb682f8
--
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] Removes FIXME message in usb.c
This patch removes a fixme message in this file:wq for setting the usb 2
speed on the board to the correct level. We need to depend on the
bootloader for doing this as the wires may be shared for the other
things on the board with the usb chipset.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
arch/arm/mach-omap1/usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 4118db5..172245a 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -505,7 +505,7 @@ static u32 __init omap1_usb2_init(unsigned nwires, unsigned
alt_pingroup)
omap_cfg_reg(W5_USB2_SE0);
if (nwires != 3)
omap_cfg_reg(Y5_USB2_RCV);
- // FIXME omap_cfg_reg(USB2_SPEED);
+ /* Depend on boatloader for USB speed to be stated for board */
} else {
pr_debug(usb%d cpu unrecognized\n, 1);
return 0;
--
1.9.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 v2 6/7] regulator: tps65218: Add get_voltage ops for dcdc5 and dcdc6
On Tuesday 08 July 2014 07:41 PM, Mark Brown wrote:
On Tue, Jul 08, 2014 at 03:46:36PM +0530, Keerthy wrote:
+static int tps65218_pmic_dcdc56_get_voltage(struct regulator_dev *dev)
+{
+ struct tps65218 *tps = rdev_get_drvdata(dev);
+ unsigned int rid = rdev_get_id(dev);
+
+ return tps-info[rid]-min_uV;
+}
Set fixed_uV in the descriptor.
Okay. I will do that. Thanks for the review.
Regards,
Keerthy
--
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] Removes FIXME message in usb.c
On Tue, Jul 08, 2014 at 09:58:39PM -0400, Nicholas Krause wrote: This patch removes a fixme message in this file:wq for setting the usb 2 I don't think you did this correctly :) speed on the board to the correct level. We need to depend on the bootloader for doing this as the wires may be shared for the other things on the board with the usb chipset. Signed-off-by: Nicholas Krause xerofo...@gmail.com --- arch/arm/mach-omap1/usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c index 4118db5..172245a 100644 --- a/arch/arm/mach-omap1/usb.c +++ b/arch/arm/mach-omap1/usb.c @@ -505,7 +505,7 @@ static u32 __init omap1_usb2_init(unsigned nwires, unsigned alt_pingroup) omap_cfg_reg(W5_USB2_SE0); if (nwires != 3) omap_cfg_reg(Y5_USB2_RCV); - // FIXME omap_cfg_reg(USB2_SPEED); + /* Depend on boatloader for USB speed to be stated for board */ Really? Is that correct? WHy? -- 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 v3 6/7] ARM: dts: AM437x: Add TPS65218 device tree nodes
Add TPS65218 device tree nodes. i2c clock frequency setting
also added as part of tps65218 nodes addition. As i2c clock
enabling is required.
Signed-off-by: Keerthy j-keer...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
Changes from V1:
* Added dcdc3, dcdc5, dcdc6 nodes.
* dcdc4 is not added because of a potential PMIC bug under investigation.
arch/arm/boot/dts/am437x-gp-evm.dts | 58 +++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 85ca430..f0422c2 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -260,6 +260,64 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c0_pins;
+ clock-frequency = 40;
+
+ tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = ti,tps65218-dcdc3;
+ regulator-name = vdcdc3;
+ regulator-min-microvolt = 135;
+ regulator-max-microvolt = 135;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ dcdc5: regulator-dcdc5 {
+ compatible = ti,tps65218-dcdc5;
+ regulator-name = v1_0bat;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ };
+
+ dcdc6: regulator-dcdc6 {
+ compatible = ti,tps65218-dcdc6;
+ regulator-name = v1_8bat;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
};
i2c1 {
--
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 v3 7/7] ARM: configs: omap2plus_defconfig: enable TPS65218 configs
Enable TPS65218 config options. Signed-off-by: Keerthy j-keer...@ti.com Acked-by: Felipe Balbi ba...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 536a137..f650f00 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -180,6 +180,7 @@ CONFIG_TWL4030_WATCHDOG=y CONFIG_MFD_SYSCON=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65217=y +CONFIG_MFD_TPS65218=y CONFIG_MFD_TPS65910=y CONFIG_TWL6040_CORE=y CONFIG_REGULATOR_FIXED_VOLTAGE=y @@ -188,6 +189,7 @@ CONFIG_REGULATOR_TI_ABB=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y +CONFIG_REGULATOR_TPS65218=y CONFIG_REGULATOR_TPS65910=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_PBIAS=y -- 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 v3 0/7] ARM: dts: AM43x: Add devcice tree nodes
The patch series adds the device tree nodes and the corresponding documentation. The series also enabled tps65218 config options in the omap2plus_defconfig. The series is boot tested on both AM43x-epos-evm and AM437x-gp-evm. Keerthy (7): regulator: tps65218: Add fixed_uV fields for dcdc5 and dcdc6 mfd: Add DT bindings for tps65218 PMIC regulator: Add DT bindings for tps65218 PMIC regulators. ARM: dts: AM43x: Add TPS65218 device tree nodes ARM: dts: AM437x: Fix i2c nodes indentation ARM: dts: AM437x: Add TPS65218 device tree nodes ARM: configs: omap2plus_defconfig: enable TPS65218 configs Documentation/devicetree/bindings/mfd/tps65218.txt | 89 .../devicetree/bindings/regulator/tps65218.txt | 23 + arch/arm/boot/dts/am437x-gp-evm.dts| 71 ++-- arch/arm/boot/dts/am43x-epos-evm.dts | 59 + arch/arm/configs/omap2plus_defconfig |2 + drivers/regulator/tps65218-regulator.c | 17 ++-- 6 files changed, 246 insertions(+), 15 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt -- 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 v3 3/7] regulator: Add DT bindings for tps65218 PMIC regulators.
Add DT bindings for tps65218 PMIC regulators.
Signed-off-by: Keerthy j-keer...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
.../devicetree/bindings/regulator/tps65218.txt | 23
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt
b/Documentation/devicetree/bindings/regulator/tps65218.txt
new file mode 100644
index 000..fccc1d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -0,0 +1,23 @@
+TPS65218 family of regulators
+
+Required properties:
+For tps65218 regulators/LDOs
+- compatible:
+ - ti,tps65218-dcdc1 for DCDC1
+ - ti,tps65218-dcdc2 for DCDC2
+ - ti,tps65218-dcdc3 for DCDC3
+ - ti,tps65218-dcdc4 for DCDC4
+ - ti,tps65218-dcdc5 for DCDC5
+ - ti,tps65218-dcdc6 for DCDC6
+ - ti,tps65218-ldo1 for LDO1
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+ xyz: regulator@0 {
+ compatible = ti,tps65218-dcdc1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 300;
+ };
--
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 v3 5/7] ARM: dts: AM437x: Fix i2c nodes indentation
Fix i2c nodes indentation.
Signed-off-by: Keerthy j-keer...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 003766c..85ca430 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -257,16 +257,15 @@
};
i2c0 {
-status = okay;
-pinctrl-names = default;
-pinctrl-0 = i2c0_pins;
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pins;
};
i2c1 {
-status = okay;
-pinctrl-names = default;
-pinctrl-0 = i2c1_pins;
-
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
pixcir_ts@5c {
compatible = pixcir,pixcir_tangoc;
pinctrl-names = default;
--
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 v3 2/7] mfd: Add DT bindings for tps65218 PMIC
Add DT bindings for tps65218 PMIC
Signed-off-by: Keerthy j-keer...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
Documentation/devicetree/bindings/mfd/tps65218.txt | 89
1 file changed, 89 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps65218.txt
b/Documentation/devicetree/bindings/mfd/tps65218.txt
new file mode 100644
index 000..01ac973
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65218.txt
@@ -0,0 +1,89 @@
+Texas Instruments TPS65218 family
+
+The TPS65218 are Integrated Power Management Chips.
+
+Required properties:
+- compatible : Must be ti,tps65218;
+ For Integrated power-management used in AM437x based boards
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the tps65218 supports several interrupts
+ internally, it is considered as an interrupt controller cascaded to the
+ SoC one.
+- #interrupt-cells = 2;
+- interrupt-parent : The parent interrupt controller which is gic.
+
+Optional node:
+- TPS65218 PMIC has a number of child nodes. Mainly the regularors and SMPSs.
+
+Example:
+/*
+ * Integrated Power Management Chip
+ */
+tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ /* VDD_CORE voltage limits min of OPP50 and max of OPP100 */
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ /* VDD_MPU voltage limits min of OPP50 and max of OPP_NITRO */
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = ti,tps65218-dcdc3;
+ regulator-name = vdcdc3;
+ regulator-min-microvolt = 135;
+ regulator-max-microvolt = 135;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc4: regulator-dcdc4 {
+ compatible = ti,tps65218-dcdc4;
+ regulator-name = v3_3d;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc5: regulator-dcdc5 {
+ compatible = ti,tps65218-dcdc5;
+ regulator-name = v1_0bat;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ };
+
+ dcdc6: regulator-dcdc6 {
+ compatible = ti,tps65218-dcdc6;
+ regulator-name = v1_8vat;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
--
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 v3 4/7] ARM: dts: AM43x: Add TPS65218 device tree nodes
Add TPS65218 device tree nodes. i2c clock frequency setting
also added as part of tps65218 nodes addition. As i2c clock
enabling is required.
Signed-off-by: Keerthy j-keer...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
Changes from V1:
* Added dcdc3, dcdc5, dcdc6 nodes.
* dcdc4 is not added because of a potential PMIC bug under investigation.
arch/arm/boot/dts/am43x-epos-evm.dts | 59 ++
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 90098f9..f1ee7495 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -327,6 +327,65 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c0_pins;
+ clock-frequency = 40;
+
+ tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = ti,tps65218-dcdc3;
+ regulator-name = vdcdc3;
+ regulator-min-microvolt = 135;
+ regulator-max-microvolt = 135;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc5: regulator-dcdc5 {
+ compatible = ti,tps65218-dcdc5;
+ regulator-name = v1_0bat;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ };
+
+ dcdc6: regulator-dcdc6 {
+ compatible = ti,tps65218-dcdc6;
+ regulator-name = v1_8bat;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
at24@50 {
compatible = at24,24c256;
--
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 v3 1/7] regulator: tps65218: Add fixed_uV fields for dcdc5 and dcdc6
Add fixed_uV fields for dcdc5 and dcdc6.
Signed-off-by: Keerthy j-keer...@ti.com
---
Changes from V2:
* Added fixed_uV fields for the regulator_desc structures.
drivers/regulator/tps65218-regulator.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/tps65218-regulator.c
b/drivers/regulator/tps65218-regulator.c
index 9effe48..27dc70d 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -30,7 +30,7 @@
enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4, DCDC5, DCDC6, LDO1 };
#define TPS65218_REGULATOR(_name, _id, _ops, _n, _vr, _vm, _er, _em, _t, \
- _lr, _nlr, _delay) \
+ _lr, _nlr, _delay, _fuv)\
{ \
.name = _name,\
.id = _id, \
@@ -46,6 +46,7 @@ enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4, DCDC5,
DCDC6, LDO1 };
.linear_ranges = _lr, \
.n_linear_ranges= _nlr, \
.ramp_delay = _delay, \
+ .fixed_uV = _fuv \
} \
#define TPS65218_INFO(_id, _nm, _min, _max)\
@@ -186,33 +187,33 @@ static const struct regulator_desc regulators[] = {
TPS65218_REG_CONTROL_DCDC1,
TPS65218_CONTROL_DCDC1_MASK,
TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC1_EN, NULL,
- dcdc1_dcdc2_ranges, 2, 4000),
+ dcdc1_dcdc2_ranges, 2, 4000, 0),
TPS65218_REGULATOR(DCDC2, TPS65218_DCDC_2, tps65218_dcdc12_ops, 64,
TPS65218_REG_CONTROL_DCDC2,
TPS65218_CONTROL_DCDC2_MASK,
TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC2_EN, NULL,
- dcdc1_dcdc2_ranges, 2, 4000),
+ dcdc1_dcdc2_ranges, 2, 4000, 0),
TPS65218_REGULATOR(DCDC3, TPS65218_DCDC_3, tps65218_ldo1_dcdc34_ops,
64, TPS65218_REG_CONTROL_DCDC3,
TPS65218_CONTROL_DCDC3_MASK, TPS65218_REG_ENABLE1,
TPS65218_ENABLE1_DC3_EN, NULL,
- ldo1_dcdc3_ranges, 2, 0),
+ ldo1_dcdc3_ranges, 2, 0, 0),
TPS65218_REGULATOR(DCDC4, TPS65218_DCDC_4, tps65218_ldo1_dcdc34_ops,
53, TPS65218_REG_CONTROL_DCDC4,
TPS65218_CONTROL_DCDC4_MASK,
TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC4_EN, NULL,
- dcdc4_ranges, 2, 0),
+ dcdc4_ranges, 2, 0, 0),
TPS65218_REGULATOR(DCDC5, TPS65218_DCDC_5, tps65218_dcdc56_pmic_ops,
1, -1, -1, TPS65218_REG_ENABLE1,
- TPS65218_ENABLE1_DC5_EN, NULL, NULL, 0, 0),
+ TPS65218_ENABLE1_DC5_EN, NULL, NULL, 0, 0, 100),
TPS65218_REGULATOR(DCDC6, TPS65218_DCDC_6, tps65218_dcdc56_pmic_ops,
1, -1, -1, TPS65218_REG_ENABLE1,
- TPS65218_ENABLE1_DC6_EN, NULL, NULL, 0, 0),
+ TPS65218_ENABLE1_DC6_EN, NULL, NULL, 0, 0, 180),
TPS65218_REGULATOR(LDO1, TPS65218_LDO_1, tps65218_ldo1_dcdc34_ops, 64,
TPS65218_REG_CONTROL_LDO1,
TPS65218_CONTROL_LDO1_MASK, TPS65218_REG_ENABLE2,
TPS65218_ENABLE2_LDO1_EN, NULL, ldo1_dcdc3_ranges,
- 2, 0),
+ 2, 0, 0),
};
static int tps65218_regulator_probe(struct platform_device *pdev)
--
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 V2] ASoC: omap-mcbsp: Use devm_snd_soc_register_component
On 07/08/2014 07:25 PM, Manish Badarkhe wrote:
Replaced snd_soc_register_component with its devres equivalent,
devm_snd_soc_register_component.
Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Changes since V1:
Aligned function parameter properly.
:100644 100644 efe2cd6... bd3ef2a... Msound/soc/omap/omap-mcbsp.c
sound/soc/omap/omap-mcbsp.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index efe2cd6..bd3ef2a 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -805,8 +805,9 @@ static int asoc_mcbsp_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = snd_soc_register_component(pdev-dev, omap_mcbsp_component,
- omap_mcbsp_dai, 1);
+ ret = devm_snd_soc_register_component(pdev-dev,
+ omap_mcbsp_component,
+ omap_mcbsp_dai, 1);
if (ret)
return ret;
@@ -817,8 +818,6 @@ static int asoc_mcbsp_remove(struct platform_device *pdev)
{
struct omap_mcbsp *mcbsp = platform_get_drvdata(pdev);
- snd_soc_unregister_component(pdev-dev);
-
if (mcbsp-pdata-ops mcbsp-pdata-ops-free)
mcbsp-pdata-ops-free(mcbsp-id);
--
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 V2] ASoC: omap-dmic: Use devm_snd_soc_register_component
On 07/08/2014 07:53 PM, Manish Badarkhe wrote:
Replaced snd_soc_register_component with its devres equivalent,
devm_snd_soc_register_component.
Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Changes since V1:
Aligned function parameter properly.
:100644 100644 6925d71... f125eb9... Msound/soc/omap/omap-dmic.c
sound/soc/omap/omap-dmic.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 6925d71..f125eb9 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -490,8 +490,9 @@ static int asoc_dmic_probe(struct platform_device *pdev)
}
- ret = snd_soc_register_component(pdev-dev, omap_dmic_component,
- omap_dmic_dai, 1);
+ ret = devm_snd_soc_register_component(pdev-dev,
+ omap_dmic_component,
+ omap_dmic_dai, 1);
if (ret)
goto err_put_clk;
@@ -510,7 +511,6 @@ static int asoc_dmic_remove(struct platform_device *pdev)
{
struct omap_dmic *dmic = platform_get_drvdata(pdev);
- snd_soc_unregister_component(pdev-dev);
clk_put(dmic-fclk);
return 0;
--
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 V2] ASoC: omap-hdmi: Use devm_snd_soc_register_component
On 07/08/2014 07:47 PM, Manish Badarkhe wrote:
Replaced snd_soc_register_component with its devres equivalent,
devm_snd_soc_register_component.
Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com
Jut to make things easier I think we should not have this patch applied since
Jyri's OMAP4+ HDMI audio rework series is going to delete this file.
---
Changes since V1:
Aligned function parameter properly.
:100644 100644 eb9c392... 8dcd7f7... Msound/soc/omap/omap-hdmi.c
sound/soc/omap/omap-hdmi.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index eb9c392..8dcd7f7 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -322,8 +322,9 @@ static int omap_hdmi_probe(struct platform_device *pdev)
}
dev_set_drvdata(pdev-dev, hdmi_data);
- ret = snd_soc_register_component(pdev-dev, omap_hdmi_component,
- omap_hdmi_dai, 1);
+ ret = devm_snd_soc_register_component(pdev-dev,
+ omap_hdmi_component,
+ omap_hdmi_dai, 1);
if (ret)
return ret;
@@ -335,8 +336,6 @@ static int omap_hdmi_remove(struct platform_device *pdev)
{
struct hdmi_priv *hdmi_data = dev_get_drvdata(pdev-dev);
- snd_soc_unregister_component(pdev-dev);
-
if (hdmi_data == NULL) {
dev_err(pdev-dev, cannot obtain HDMi data\n);
return -ENODEV;
--
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
