Re: [RFC PATCH] tty: serial: Add 8250-core based omap driver
* Robert Nelson robertcnel...@gmail.com [140704 09:59]: On Fri, Jul 4, 2014 at 11:51 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: On 07/03/2014 09:34 AM, Tony Lindgren wrote: Heh. Just to summarize the reason ttyO needs to be a separate name and device entry from ttyS is because we also have external 8250 devices on GPMC and hotplug busses. So the GPMC devices will first get a higher minor/device number. The internal serial ports should show up first. I don't see the problem (yet). If you need a separate major number (and name) like we do have it now (between ttySx and ttyOx) then one of requirements would be to tell Kconfig that one driver can be active at a time. For me the ttyS vs ttyO thing is purely cosmetic. I personally don't like that it is different on different platforms like ttymxc, ttySC, ttyTHS, … The dev entry had to be different with serial-omap as it was not using 8250 code. With the code moving back to using 8250 code there are no dev conflicts so ttyS is just fine as the 8250 code handles allocating the devices. Maybe it's time to migrate them all to one name? (ttyS) Does the end user really care if they have a soc with an omap/imx serial port driver? Or do they just want to access /dev/ttySx and connect to their device? Yes the 8250 code should always use ttyS. Then maybe we could have also ttyO dev entries created by the driver for compability. Earlier serial-omap could not provide the ttyS compability easily because they were separate drivers. 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: OMAP baseline test results for v3.16-rc4
* Paul Walmsley p...@pwsan.com [140706 16:43]: Here are some basic OMAP test results for Linux v3.16-rc4. Logs and other details at: ... PM: chip retention via dynamic idle: FAIL ( 7/ 7): 2430sdp, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom PM: chip off except CORE via suspend: FAIL ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: FAIL ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom PM: chip off via dynamic idle: FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom With v3.16-rc4 the PM features for omap3 should be working finally for device tree based booting. At lest beaglexm and 3xxevm should work. Maybe you are using legacy booting path to idle the UARTs still? FYI, I'm doing this to find the UART entries: uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled $uart/wakeup echo auto $uart/control done echo 1 /sys/kernel/debug/pm_debug/enable_off_mode 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: [GIT PULL] omap fixes against v3.16-rc1
* Olof Johansson o...@lixom.net [140705 12:46]: On Fri, Jul 4, 2014 at 11:06 PM, Olof Johansson o...@lixom.net wrote: Hi, On Fri, Jul 4, 2014 at 9:47 PM, Olof Johansson o...@lixom.net wrote: On Mon, Jun 30, 2014 at 12:08:57AM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [140617 08:01]: The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: Linux 3.16-rc1 (2014-06-15 17:45:28 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.16/fixes-against-rc1 for you to fetch changes up to edc56f871eefbc56baf1fd981eeff35ef447925c: ARM: dts: dra7-evm: remove interrupt binding (2014-06-17 01:22:55 -0700) Merged. Apologies for the delay, I was planning on handling this earleir this week. I'll send this up tonight or tomorrow. Hmm. for-next with this merged in stopped omap5uevm from booting (Can't find mmcblk1 which I keep the rootfs on), see http://arm-soc.lixom.net/bootlogs/arm-soc/v3.16-rc1-76-gf5ee1b1/. One of the three configs had a DHCP timeout, I'm going to rebuild the network here to reduce the frequency of those. I'll try bisecting tomorrow. Not sending it up with this known breakage, hopefully it's something simple. Hmm, this fixes branch + current mainline (or -rc3) seems fine, while the -rc1 base we used to have does not. In other words, it seems OK to send up for merge. Note that the OMAP branch by itself doesn't boot on this machine, so bisectability is lost for a bit. Not quite as worried about it since it's not in the merge window, so we should be OK. Sorry just saw these messages. The MMC regulator issue was a known problem with v3.16-rc1 unrelated to arm-soc tree that got fixed already in the mainline kernel but was not yet merged to the mainline kernel few weeks ago when I made this branch. 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
* Nicholas Krause xerofo...@gmail.com [140704 10:03]:
This patch fixes the call to ompa_cfg_reg(USB2_SPEED) in the case
that the cpu is a omap16xx and the nwires are not equal to 3.
This is most likely unsafe to do as the pin is probably
shared with some other device and we have to rely for
the bootloader to do the right thing for the board.
Regards,
Tony
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
arch/arm/mach-omap1/usb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 4118db5..17e3139 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -504,8 +504,7 @@ static u32 __init omap1_usb2_init(unsigned nwires,
unsigned alt_pingroup)
omap_cfg_reg(W9_USB2_TXEN);
omap_cfg_reg(W5_USB2_SE0);
if (nwires != 3)
- omap_cfg_reg(Y5_USB2_RCV);
- // FIXME omap_cfg_reg(USB2_SPEED);
+ omap_cfg_reg(USB2_SPEED)
} 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 1/6] ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on
* Roger Quadros rog...@ti.com [140704 02:57]: After clarification from the hardware team it was found that this 1.8V PHY supply can't be switched OFF when SoC is Active. Since the PHY IPs don't contain isolation logic built in the design to allow the power rail to be switched off, there is a very high risk of IP reliability and additional leakage paths which can result in additional power consumption. The only scenario where this rail can be switched off is part of Power on reset sequencing, but it needs to be kept always-on during operation. This patch is required for proper functionality of USB, SATA and PCIe on DRA7-evm. CC: Rajendra Nayak rna...@ti.com CC: Tero Kristo t-kri...@ti.com Signed-off-by: Roger Quadros rog...@ti.com Best that you queue this with the series: Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/boot/dts/dra7-evm.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index 4adc280..8308954 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -240,6 +240,7 @@ regulator-name = ldo3; regulator-min-microvolt = 180; regulator-max-microvolt = 180; + regulator-always-on; regulator-boot-on; }; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/6] ARM: dts: dra7-evm: Add regulator information to USB2 PHYs
* Roger Quadros rog...@ti.com [140704 02:58]:
The ldousb_reg regulator provides power to the USB1 and USB2
High Speed PHYs.
Signed-off-by: Roger Quadros rog...@ti.com
This too:
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/dra7-evm.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 8308954..50f8022 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -496,3 +496,11 @@
};
};
};
+
+usb2_phy1 {
+ phy-supply = ldousb_reg;
+};
+
+usb2_phy2 {
+ phy-supply = ldousb_reg;
+};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on
Hi Tony, On 07/07/2014 11:29 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140704 02:57]: After clarification from the hardware team it was found that this 1.8V PHY supply can't be switched OFF when SoC is Active. Since the PHY IPs don't contain isolation logic built in the design to allow the power rail to be switched off, there is a very high risk of IP reliability and additional leakage paths which can result in additional power consumption. The only scenario where this rail can be switched off is part of Power on reset sequencing, but it needs to be kept always-on during operation. This patch is required for proper functionality of USB, SATA and PCIe on DRA7-evm. CC: Rajendra Nayak rna...@ti.com CC: Tero Kristo t-kri...@ti.com Signed-off-by: Roger Quadros rog...@ti.com Best that you queue this with the series: This patch doesn't have any dependency with the others and we're not even sure if this series will hit 3.16. But this 1V8 regulator _is_ required for normal operation of the SoC, whether the PHYs are in use or not. Can you please queue just this patch for SoC fixes for 3.16? Thanks. cheers, -roger Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/boot/dts/dra7-evm.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index 4adc280..8308954 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -240,6 +240,7 @@ regulator-name = ldo3; regulator-min-microvolt = 180; regulator-max-microvolt = 180; +regulator-always-on; regulator-boot-on; }; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: DRA7: hwmod: Add OCP2SCP3 module
Paul, On 07/06/2014 03:23 AM, Paul Walmsley wrote: Hi On Fri, 4 Jul 2014, Roger Quadros wrote: On 07/03/2014 10:48 PM, Paul Walmsley wrote: On Thu, 3 Jul 2014, Roger Quadros wrote: This module is needed for the SATA and PCIe PHYs. Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Rajendra Nayak rna...@ti.com Tested-by: Sekhar Nori nsek...@ti.com This looks like adding support for a new device, so, after discussing with Tony, queuing for v3.17. We should treat it as missing device (bug) rather than new device (feature) as the corresponding device tree node is already present. Without this patch we get the following message in kernel boot log [0.261680] platform 4a09.ocp2scp: Cannot lookup hwmod 'ocp2scp3' I would consider this patch as a fix rather than a new feature. Just to make sure I'm correctly applying the rules for sequencing -rc patches vs. merge window patches, could you please confirm my understanding of the situation: 1. The OCP2SCP3 device (and the devices that rely on it) never worked on DRA7xx in earlier kernels 2. Even with this support added, neither SATA nor PCIe will work in 3.16 on DRA7xx (SATA for unknown reasons, PCIe because the patches are targeted for 3.17). The reason for SATA not working has been identified and the fix is posted here https://lkml.org/lkml/2014/7/4/166 So this hwmod patch is the only missing piece why SATA won't work on 3.16. 3. The warning doesn't prevent the machine from booting and does not impair any previously working functionality 4. There are other DRA7xx warning messages on boot in 3.16-rc: for example, http://paste.ubuntu.com/7701601/ lists: [0.009931] omap_hwmod: l3_main_2 using broken dt data from ocp ... [0.291802] platform 4e00.dmm: Cannot lookup hwmod 'dmm' Are these four statements correct? Yes for 1,3 and 4. If so, is there some other reason why we should rush this in for 3.16-rc? Put differently: how can we justify adding this device in 3.16-rc rather than 3.17 to Linus Torvalds? Nothing else that I can think of apart from SATA not working on 3.16. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on
* Roger Quadros rog...@ti.com [140707 01:36]: Hi Tony, On 07/07/2014 11:29 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140704 02:57]: After clarification from the hardware team it was found that this 1.8V PHY supply can't be switched OFF when SoC is Active. Since the PHY IPs don't contain isolation logic built in the design to allow the power rail to be switched off, there is a very high risk of IP reliability and additional leakage paths which can result in additional power consumption. The only scenario where this rail can be switched off is part of Power on reset sequencing, but it needs to be kept always-on during operation. This patch is required for proper functionality of USB, SATA and PCIe on DRA7-evm. CC: Rajendra Nayak rna...@ti.com CC: Tero Kristo t-kri...@ti.com Signed-off-by: Roger Quadros rog...@ti.com Best that you queue this with the series: This patch doesn't have any dependency with the others and we're not even sure if this series will hit 3.16. But this 1V8 regulator _is_ required for normal operation of the SoC, whether the PHYs are in use or not. Can you please queue just this patch for SoC fixes for 3.16? Thanks. OK will do. 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 00/13] uio_pruss: add support for devicetree and am33xx
On Sun, Jun 29, 2014 at 06:21:34PM +0200, Andre Heider wrote: Hi, this series adds PRUv2 support to uio_pruss through devicetree, makes the device usable on am33xx and enables it on beaglebone black. Inspired by old patches from Matt Porter found in a downstream tree. To archieve that this series: * adds a flag to omap_hwmod.c to get PRUSS out of hardreset (patch 5 and 6) * adds devicetree support to uio_pruss (patch 7 and 9) * adds the device to the am33xx dtsi and boneblack dts (patch 12 and 13) Bits and pieces: * some cleanup (patch 1-4) * take care of a fact that SRAM on am33xx is not exposed through UIO (patch 8) * add runtime pm support to enable clocks (patch 10) * allow the driver to be compiled on SOC_AM33XX (patch 11) This is only tested on beaglebone black (as that's the only hardware of the PRUSS enabled families I have) with some basic GPIO and IRQ tests. Notes: * I just got this hardware and I don't know if this UIO PRUSS business is desired. Looking at the userspace driver I'd guess not so much ;), but this interface is there for older generations anyway, and this small series lets me use the device. * is the hardreset thing I did there the right thing to do? I think the proper way would be a reset controller (which apparently doesn't yet exist for this SoC?) and let the driver deassert/assert on probe/remove? * the platform device path has a clk_enable() / clk_put() calls. Are those now redundant with the introduced pm_runtime_enable() pm_runtime_disable() calls? @OMAP guys: any comments? The series depends on patch 5 and 6; both touch common hwmod code. I noticed that AM437x now comes with 4 PRUSS cores, maybe you had something different in mind on how to expose these? Thanks in advance, Andre -- 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
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?
if (ret)
@@ -335,8 +335,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
Re: [PATCH] ASoC: omap-mcbsp: Use devm_snd_soc_register_component
On 07/05/2014 08:09 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 efe2cd6... bfc8f8e... Msound/soc/omap/omap-mcbsp.c
sound/soc/omap/omap-mcbsp.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index efe2cd6..bfc8f8e 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -805,7 +805,7 @@ static int asoc_mcbsp_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = snd_soc_register_component(pdev-dev, omap_mcbsp_component,
+ ret = devm_snd_soc_register_component(pdev-dev, omap_mcbsp_component,
omap_mcbsp_dai, 1);
Can you align the parameters as well?
if (ret)
return ret;
@@ -817,8 +817,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] ASoC: omap-dmic: Use devm_snd_soc_register_component
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?
if (ret)
goto err_put_clk;
@@ -510,7 +510,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 3/3] ARM: OMAP2+: create dsp device only on OMAP3 SoCs
* Suman Anna s-a...@ti.com [140623 22:26]: The DSP platform device for TI DSP/Bridge is currently created unconditionally whenever CONFIG_TIDSPBRIDGE is enabled. This device should only be created on OMAP34xx/ OMAP36xx SoCs, and not for other OMAP3 derived SoCs or when booting multi-arch images on other SoCs. So, add a check for the SoC family both before creating the device and allocating the carveout memory for the device. Applying this one into omap-for-v3/16/fixes 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] ARM: OMAP2+: l2c: squelch warning dump on power control setting
* Tony Lindgren t...@atomide.com [140702 01:13]: * Felipe Balbi ba...@ti.com [140701 12:49]: On Tue, Jun 17, 2014 at 08:19:35AM -0500, Felipe Balbi wrote: On Tue, Jun 17, 2014 at 04:04:51PM +0530, Sekhar Nori wrote: ROM code on AM437x does not support writing to L2C-310 power control register. The L2C driver, however, tries writing to this register for all revisions = r3p0. This leads to a warning dump on boot which leads most users to believe that L2 cache is non-functional. Since the problem is understood, and cannot be addressed through software, replace the warning with a pr_info() while maintaining the WARN_ON() for other truly unexpected scenarios. Reported-by: Nishanth Menon n...@ti.com Signed-off-by: Sekhar Nori nsek...@ti.com Tested with today's linux-next (5f295cdf5c5dbbb0c40f10f2ddae02ff46bbf773) with am437x-sk, I can see that the WARNING goes away. Tested-by: Felipe Balbi ba...@ti.com ping here, I can't see this patch onl linus/master or next/master yet. Sorry I've been waiting for my pull request against -rc1 to get merged first, no idea why that is still pending. That's now merged into v3.16-rc4, so applying this 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] ARM: OMAP2+: l2c: squelch warning dump on power control setting
On Mon, Jul 07, 2014 at 03:47:27AM -0700, Tony Lindgren wrote: That's now merged into v3.16-rc4, so applying this into omap-for-v3.16/fixes. I intentionally left the warning in the hope that someone would update it to write to the register. From the comments in the patch, it seems that firmware doesn't provide a method to do that, which is a tad annoying. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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: OMAP2+: Make GPMC skip disabled devices
* Guido Martínez gu...@vanguardiasur.com.ar [140702 06:34]:
Currently, child nodes of the gpmc node are iterated and probed
regardless of their 'status' property. This means adding 'status =
disabled;' has no effect.
This patch changes the iteration to only probe nodes marked as
available.
Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar
---
v2: Make patch title consistent with previous gpmc patches
Thanks applying into omap-for-v3.16/fixes.
Tony
arch/arm/mach-omap2/gpmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2c0c281..8bc1338 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1615,7 +1615,7 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
- for_each_child_of_node(pdev-dev.of_node, child) {
+ for_each_available_child_of_node(pdev-dev.of_node, child) {
if (!child-name)
continue;
--
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 v2 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
On Sat, 05 Jul 2014, Peter Griffin wrote: Signed-off-by: Peter Griffin peter.grif...@linaro.org --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) Acked-by: Lee Jones lee.jo...@linaro.org 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 v2 2/3] ARM: dts: sti: Add st-dwc3 devicetree bindings documentation
Subject is wrong, this has nothing to do with ARM. Should be USB.
On Sat, 05 Jul 2014, Peter Griffin wrote:
This patch documents the device tree documentation required for
the ST usb3 controller glue layer found in STiH407 devices.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
Documentation/devicetree/bindings/usb/dwc3-st.txt | 58
+++
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt
diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
new file mode 100644
index 000..befd964
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -0,0 +1,58 @@
+ST DWC3 glue logic
+
+This file documents the parameters for the dwc3-st driver.
Does this line really add anything to do the document, considering the
name and location of the file and the title above?
+This driver provides the glue logic to use the dwc3 on STiH407 based
platforms.
s/This driver/The DWC2 driver/
+Required properties:
+ - compatible: must be st,stih407-dwc3
+ - reg : glue logic base address and USB syscfg ctrl register
offset
+ - reg-names : should be reg-glue and syscfg-reg
Any reason why you have reg-* and *-reg? If you have to put 'reg' in
the name, it's usually appended, rather than prefixed.
+ - st,syscon : should be phandle to system configuration node which
+ encompasses the glue registers
+ - resets: phandle pointing to the system powerdown controller
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property
+
+ - pinctl-names : A pinctrl state named default must be defined
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - pinctrl-0 : Pin control group
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - ranges: allows valid 1:1 translation between child's address space and
+ parent's address space
+
+Optional properties:
+ - st,dwc3-drd-device: to program the HC as device (static setup)
This will require a DT Ack.
+Sub-nodes:
+The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
+example below. The DT binding details of dwc3 can be found in:
+Documentation/devicetree/bindings/usb/dwc3.txt
+
+Example:
+
+st_dwc3: dwc3@8f94000 {
+ status = disabled;
Probably not good to disable the node in the example.
+ compatible = st,stih407-dwc3;
+ reg = 0x08f94000 0x1000, 0x110 0x4;
+ reg-names = reg-glue, syscfg-reg;
+ st,syscfg = syscfg_core;
+ resets = powerdown STIH407_USB3_POWERDOWN;
+ #address-cells = 1;
+ #size-cells = 1;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_usb3;
+ ranges;
+
+ dwc3: dwc3@990 {
+ compatible = synopsys,dwc3;
+ reg = 0x0990 0x10;
+ interrupts = GIC_SPI 155 IRQ_TYPE_NONE;
+
+ usb-phy = usb2_phy, usb3_phy;
+ };
+};
--
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] ARM: OMAP2+: l2c: squelch warning dump on power control setting
* Russell King - ARM Linux li...@arm.linux.org.uk [140707 03:51]: On Mon, Jul 07, 2014 at 03:47:27AM -0700, Tony Lindgren wrote: That's now merged into v3.16-rc4, so applying this into omap-for-v3.16/fixes. I intentionally left the warning in the hope that someone would update it to write to the register. From the comments in the patch, it seems that firmware doesn't provide a method to do that, which is a tad annoying. So it seems.. Santosh, might be worth checking if this is set up the same way for all omaps? Or do some have extra commands for OMAP4_MON_L2X0_* for ROM code calls? 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 [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?
Regards,
Tony
arch/arm/boot/dts/omap5.dtsi | 60
++
1 file changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a4ed549..8eee6fb 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -985,6 +985,66 @@
dma-names = audio_tx;
};
};
+
+ abb_mpu: regulator-abb-mpu {
+ compatible = ti,abb-v2;
+ regulator-name = abb_mpu;
+ #address-cells = 0;
+ #size-cells = 0;
+ clocks = sys_clkin;
+ ti,settling-time = 50;
+ ti,clock-cycles = 16;
+
+ reg = 0x4ae07cdc 0x8, 0x4ae06014 0x4,
+ 0x4a0021c4 0x8, 0x4ae0c318 0x4;
+ reg-names = base-address, int-address,
+ efuse-address, ldo-address;
+ ti,tranxdone-status-mask = 0x80;
+ /* LDOVBBMPU_MUX_CTRL */
+ ti,ldovbb-override-mask = 0x400;
+ /* LDOVBBMPU_VSET_OUT */
+ ti,ldovbb-vset-mask = 0x1F;
+
+ /*
+ * NOTE: only FBB mode used but actual vset will
+ * determine final biasing
+ */
+ ti,abb_info =
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 106 0 0x0 0 0x0200 0x01F0
+ 125 0 0x4 0 0x0200 0x01F0
+ ;
+ };
+
+ abb_mm: regulator-abb-mm {
+ compatible = ti,abb-v2;
+ regulator-name = abb_mm;
+ #address-cells = 0;
+ #size-cells = 0;
+ clocks = sys_clkin;
+ ti,settling-time = 50;
+ ti,clock-cycles = 16;
+
+ reg = 0x4ae07ce4 0x8, 0x4ae06010 0x4,
+ 0x4a0021a4 0x8, 0x4ae0c314 0x4;
+ reg-names = base-address, int-address,
+ efuse-address, ldo-address;
+ ti,tranxdone-status-mask = 0x8000;
+ /* LDOVBBMM_MUX_CTRL */
+ ti,ldovbb-override-mask = 0x400;
+ /* LDOVBBMM_VSET_OUT */
+ ti,ldovbb-vset-mask = 0x1F;
+
+ /*
+ * NOTE: only FBB mode used but actual vset will
+ * determine final biasing
+ */
+ ti,abb_info =
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 1025000 0 0x0 0 0x0200 0x01F0
+ 112 0 0x4 0 0x0200 0x01F0
+ ;
+ };
};
};
--
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 2/2] ARM: DTS: am335x-evmsk: Enable the McASP FIFO for audio
* Peter Ujfalusi peter.ujfal...@ti.com [140703 02:53]: The use of FIFO in McASP can reduce the risk of audio under/overrun and lowers the load on the memories since the DMA will operate in bursts. Applying both into omap-for-v3.16/fixes 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] ARM: DRA7/AM43XX: fix header definition for omap44xx_restart
* Nishanth Menon n...@ti.com [140516 15:37]: omap44xx_restart is defined as a static void inline when DRA7/AM437X is defined alone, which implies that the restart function is no longer functional even though it is built in. So, fix the definition of the same. Unfortunately, the number of SoCs starting to use omap44xx_restart is starting to grow and the definition looks a little ugly. Signed-off-by: Nishanth Menon n...@ti.com --- based on v3.15-rc5 NOTE: this generates over 80 characters checkpatch warning.. I am not sure other than introducing a definition for restart it could be simplified. Sorry found this still pending so applying into omap-for-v3.16/fixes. Regards, Tony arch/arm/mach-omap2/common.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index d88aff7..46150f4 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -154,7 +154,7 @@ static inline void omap3xxx_restart(enum reboot_mode mode, const char *cmd) } #endif -#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) +#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX) void omap44xx_restart(enum reboot_mode mode, const char *cmd); #else static inline void omap44xx_restart(enum reboot_mode mode, const char *cmd) -- 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 01/12] ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
* 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?
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] ARM: dts: Fix TI CPSW Phy mode selection on IGEP COM AQUILA.
* Enric Balletbo i Serra eballe...@iseebcn.com [140625 04:44]: As this board use external clock for RMII interface we should specify 'rmii' phy mode and 'rmii-clock-ext' to make ethernet working. Thanks applying into omap-for-v3.16/fixes. 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] ARM: OMAP2+: l2c: squelch warning dump on power control setting
On Monday 07 July 2014 04:32 PM, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [140707 03:51]: On Mon, Jul 07, 2014 at 03:47:27AM -0700, Tony Lindgren wrote: That's now merged into v3.16-rc4, so applying this into omap-for-v3.16/fixes. I intentionally left the warning in the hope that someone would update it to write to the register. From the comments in the patch, it seems that firmware doesn't provide a method to do that, which is a tad annoying. So it seems.. Santosh, might be worth checking if this is set up the same way for all omaps? Or do some have extra commands for OMAP4_MON_L2X0_* for ROM code calls? OMAP4430 had L2 cache controller version r2p0 (per the public TRM) which does not have this register. So unless there is a ROM API that was introduced after OMAP4430, this would not be there even for other OMAP4s. Public TRM of OMAP4470 does not indicate an API for this. Before creating the patch, I checked with ROM team handling AM437x and they denied an API to write to this register was present in AM437x ROM. Thanks, Sekhar -- 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] arch: arm: mach-omap2: usb-tusb6010.c: Cleaning up variable is set more than once
* Rickard Strandqvist rickard_strandqv...@spectrumdigital.se [140625 05:29]: A struct member variable is set to the same value more than once This was found using a static code analysis program called cppcheck. 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] ARM: OMAP2+: l2c: squelch warning dump on power control setting
On Mon, Jul 07, 2014 at 05:20:27PM +0530, Sekhar Nori wrote:
OMAP4430 had L2 cache controller version r2p0 (per the public TRM) which
does not have this register. So unless there is a ROM API that was
introduced after OMAP4430, this would not be there even for other
OMAP4s. Public TRM of OMAP4470 does not indicate an API for this.
Before creating the patch, I checked with ROM team handling AM437x and
they denied an API to write to this register was present in AM437x ROM.
Okay, so why are we trying to write to this register then...
Ah, we have a bug in cache-l2x0.c:
#define L2X0_CACHE_ID_PART_MASK (0xf 6)
#define L2X0_CACHE_ID_RTL_MASK 0x3f
#define L310_CACHE_ID_RTL_R3P0 0x05
unsigned rev = readl_relaxed(base + L2X0_CACHE_ID)
L2X0_CACHE_ID_PART_MASK;
if (rev = L310_CACHE_ID_RTL_R2P0) {
...
if (rev = L310_CACHE_ID_RTL_R3P0) {
l2c_write_sec(L310_DYNAMIC_CLK_GATING_EN | L310_STNDBY_MODE_EN,
base, L310_POWER_CTRL);
So, because we're masking the wrong bits, we end up with these tests
always succeeding.
So that's a NACK for the original patch, it's the wrong fix. The
right fix is to avoid writing this register by fixing the RTL masking.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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
* Russell King - ARM Linux li...@arm.linux.org.uk [140707 05:17]:
On Mon, Jul 07, 2014 at 05:20:27PM +0530, Sekhar Nori wrote:
OMAP4430 had L2 cache controller version r2p0 (per the public TRM) which
does not have this register. So unless there is a ROM API that was
introduced after OMAP4430, this would not be there even for other
OMAP4s. Public TRM of OMAP4470 does not indicate an API for this.
Before creating the patch, I checked with ROM team handling AM437x and
they denied an API to write to this register was present in AM437x ROM.
Okay, so why are we trying to write to this register then...
Ah, we have a bug in cache-l2x0.c:
#define L2X0_CACHE_ID_PART_MASK (0xf 6)
#define L2X0_CACHE_ID_RTL_MASK 0x3f
#define L310_CACHE_ID_RTL_R3P0 0x05
unsigned rev = readl_relaxed(base + L2X0_CACHE_ID)
L2X0_CACHE_ID_PART_MASK;
if (rev = L310_CACHE_ID_RTL_R2P0) {
...
if (rev = L310_CACHE_ID_RTL_R3P0) {
l2c_write_sec(L310_DYNAMIC_CLK_GATING_EN |
L310_STNDBY_MODE_EN,
base, L310_POWER_CTRL);
So, because we're masking the wrong bits, we end up with these tests
always succeeding.
So that's a NACK for the original patch, it's the wrong fix. The
right fix is to avoid writing this register by fixing the RTL masking.
Okie dokie, dropping the omap specific fix.
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 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
On Sat, 05 Jul 2014, Peter Griffin wrote:
This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/usb/dwc3/Kconfig | 9 ++
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-st.c | 325
+
3 files changed, 335 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-st.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 8eb996e..6c85c43 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -79,6 +79,15 @@ config USB_DWC3_KEYSTONE
Support of USB2/3 functionality in TI Keystone2 platforms.
Say 'Y' or 'M' here if you have one such device
+config USB_DWC3_ST
+ tristate STMicroelectronics Platforms
+ depends on ARCH_STI OF
+ default USB_DWC3_HOST
+ help
+ STMicroelectronics SoCs with one DesignWare Core USB3 IP
+ inside (i.e. STiH407).
+ Say 'Y' or 'M' if you have one such device.
+
comment Debugging features
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..11c9f54 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS)+= dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
obj-$(CONFIG_USB_DWC3_KEYSTONE) += dwc3-keystone.o
+obj-$(CONFIG_USB_DWC3_ST)+= dwc3-st.o
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
new file mode 100644
index 000..2cae9d3
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -0,0 +1,325 @@
+/**
+ * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics
platforms
+ *
+ * This is a small platform driver for the dwc3 to provide the glue logic
+ * to configure the controller. Tested on STi platforms.
Not sure about the use of the term 'platform driver' here and in the
title. We don't normally differentiate. I can find examples to the
contrary, but not many.
+ * Copyright (C) 2014 Stmicroelectronics
+ *
+ * Author: Giuseppe Cavallaro peppe.cavall...@st.com
+ * Contributors: Aymen Bouattay aymen.bouat...@st.com
+ * Peter Griffin peter.grif...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Inspired by dwc3-omap.c and dwc3-exynos.c.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/ioport.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/mfd/syscon.h
+#include linux/delay.h
+#include linux/regmap.h
+#include linux/reset.h
+
+#include core.h
+#include io.h
+
+/* Reg glue registers */
+#define USB2_CLKRST_CTRL 0x00
+#define aux_clk_en(n) ((n)0)
+#define sw_pipew_reset_n(n) ((n)4)
+#define ext_cfg_reset_n(n) ((n)8)
+#define xhci_revision(n) ((n)12)
These all need reformatting, see CodingStyle - 3.1: Spaces
#define xhci_revision(n) ((n) 12)
Lining them up with TABs would make them easier to read.
Also, I don't think there is a requirement to encapsulate the 'n'.
+#define USB2_VBUS_MNGMNT_SEL1 0x2C
+/*
+ * 2'b00 : Override value from Reg 0x30 is selected
+ * 2'b01 : utmiotg_vbusvalid from usb3_top top is selected
+ * 2'b10 : pipew_powerpresent from PIPEW instance is selected
+ * 2'b11 : value is 1'b0
+ */
What is this documenting? Isn't documentation meant to make things
clearer? Now I'm just really confused - by the documentation.
+#define SEL_OVERRIDE_VBUSVALID(n) ((n)0)
+#define SEL_OVERRIDE_POWERPRESENT(n) ((n)4)
+#define SEL_OVERRIDE_BVALID(n) ((n)8)
+
+#define USB2_VBUS_MNGMNT_VAL1 0x30
+#define OVERRIDE_VBUSVALID_VAL (1 0)
+#define OVERRIDE_POWERPRESENT_VAL (1 4)
+#define OVERRIDE_BVALID_VAL (1 8)
Use BIT() for all of these bit setting macros.
+/* Static DRD configuration */
+#define USB_HOST_DEFAULT_MASK0xffe
+#define USB_SET_PORT_DEVICE 0x1
+
+struct st_dwc3 {
+ struct platform_device *dwc3; /* platform device pointer */
+ struct device *dev; /* device pointer */
+ void __iomem *glue_base;/* ioaddr for programming the glue */
+ struct regmap *regmap; /* regmap for getting syscfg */
+ int syscfg_reg_off; /* usb syscfg control offset */
+ bool drd_device_conf; /* DRD static host/device conf */
+ struct reset_control *rstc_pwrdn;/* Rst control for powerdown*/
+};
Re: [RFC PATCH 1/4] tty: serial: 8250 core: provide a function to export uart_8250_port
On Fri, 4 Jul 2014 18:34:08 +0200 Sebastian Andrzej Siewior bige...@linutronix.de wrote: There is no access to access a struct uart_8250_port for a specific line. This is only required outside of the 8250/uart callbacks like for devices' suspend remove callbacks. For those the 8250-core provides wrapper like serial8250_unregister_port() which passes the struct to the proper function based on the line argument. For runtime suspend I need access to this struct not only to make serial_out() work but also to properly restore up-ier and up-mcr. Please update the patch to clearly describe the locking assumptions/requirements for the caller (and not to use it unless you have no other choice) -- 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: [RFC PATCH 2/4] tty: serial: 8250 core: allow to overwrite export serial8250_startup()
On Fri, 4 Jul 2014 18:34:09 +0200 Sebastian Andrzej Siewior bige...@linutronix.de wrote: The OMAP version of the 8250 can actually use 1:1 serial8250_startup(). However it needs to be extended by a wakeup irq which should to be requested enabled at -startup() time. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de Acked-by: Alan Cox a...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/4] tty: serial: 8250 core: add runtime pm
On Fri, 4 Jul 2014 18:34:10 +0200 Sebastian Andrzej Siewior bige...@linutronix.de wrote: While comparing the OMAP-serial and the 8250 part of this I noticed that the the latter does not use runtime-pm. Yes it does, but 8250 parts (generally - omap presumably is special here ?) need to be powered on to transmit/receive not just for register access. The core uart layer implements a pm operation for this. As 8250_dw uses runtime pm to implement the pm operation it's not as simple as assumign it won't get triggered. I *think* this is ok because the designware and other cases would take a reference on open and drop it on close, so avoiding any confusion, but for the register accesses on a closed port it would benefit from a further double check with Mika especially as the suspend/resume on the LPSS block on some Intel devices is a little bit too interesting for comfort. Otherwise however I think this is good. Alan -- 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 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
On Saturday, July 05, 2014 3:25 PM, Peter Griffin wrote:
This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/usb/dwc3/Kconfig | 9 ++
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-st.c | 325
+
3 files changed, 335 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-st.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 8eb996e..6c85c43 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -79,6 +79,15 @@ config USB_DWC3_KEYSTONE
Support of USB2/3 functionality in TI Keystone2 platforms.
Say 'Y' or 'M' here if you have one such device
+config USB_DWC3_ST
+ tristate STMicroelectronics Platforms
+ depends on ARCH_STI OF
+ default USB_DWC3_HOST
+ help
+ STMicroelectronics SoCs with one DesignWare Core USB3 IP
+ inside (i.e. STiH407).
+ Say 'Y' or 'M' if you have one such device.
+
comment Debugging features
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..11c9f54 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS)+= dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
obj-$(CONFIG_USB_DWC3_KEYSTONE) += dwc3-keystone.o
+obj-$(CONFIG_USB_DWC3_ST)+= dwc3-st.o
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
new file mode 100644
index 000..2cae9d3
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -0,0 +1,325 @@
+/**
+ * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics
platforms
+ *
+ * This is a small platform driver for the dwc3 to provide the glue logic
+ * to configure the controller. Tested on STi platforms.
+ *
+ * Copyright (C) 2014 Stmicroelectronics
+ *
+ * Author: Giuseppe Cavallaro peppe.cavall...@st.com
+ * Contributors: Aymen Bouattay aymen.bouat...@st.com
+ * Peter Griffin peter.grif...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Inspired by dwc3-omap.c and dwc3-exynos.c.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/ioport.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/mfd/syscon.h
+#include linux/delay.h
+#include linux/regmap.h
+#include linux/reset.h
Would you re-order these headers alphabetically?
It enhances the readability.
+
+#include core.h
+#include io.h
+
+/* Reg glue registers */
+#define USB2_CLKRST_CTRL 0x00
+#define aux_clk_en(n) ((n)0)
+#define sw_pipew_reset_n(n) ((n)4)
+#define ext_cfg_reset_n(n) ((n)8)
+#define xhci_revision(n) ((n)12)
+
+#define USB2_VBUS_MNGMNT_SEL1 0x2C
+/*
+ * 2'b00 : Override value from Reg 0x30 is selected
+ * 2'b01 : utmiotg_vbusvalid from usb3_top top is selected
+ * 2'b10 : pipew_powerpresent from PIPEW instance is selected
+ * 2'b11 : value is 1'b0
+ */
+#define SEL_OVERRIDE_VBUSVALID(n) ((n)0)
+#define SEL_OVERRIDE_POWERPRESENT(n) ((n)4)
+#define SEL_OVERRIDE_BVALID(n) ((n)8)
+
+#define USB2_VBUS_MNGMNT_VAL1 0x30
+#define OVERRIDE_VBUSVALID_VAL (1 0)
+#define OVERRIDE_POWERPRESENT_VAL (1 4)
+#define OVERRIDE_BVALID_VAL (1 8)
+
+/* Static DRD configuration */
+#define USB_HOST_DEFAULT_MASK0xffe
+#define USB_SET_PORT_DEVICE 0x1
+
+struct st_dwc3 {
+ struct platform_device *dwc3; /* platform device pointer */
+ struct device *dev; /* device pointer */
+ void __iomem *glue_base;/* ioaddr for programming the glue */
+ struct regmap *regmap; /* regmap for getting syscfg */
+ int syscfg_reg_off; /* usb syscfg control offset */
+ bool drd_device_conf; /* DRD static host/device conf */
+ struct reset_control *rstc_pwrdn;/* Rst control for powerdown*/
+};
+
+static inline u32 st_dwc3_readl(void __iomem *base, u32 offset)
+{
+ return readl_relaxed(base + offset);
+}
+
+static inline void st_dwc3_writel(void __iomem *base, u32 offset, u32 value)
+{
+ writel_relaxed(value, base + offset);
+}
+
+/**
+ * st_dwc3_drd_init: program the port
+ * @dwc3_data: driver private structure
+ * Description: this function is to program the port as either host or device
+ * according to the static configuration
Re: [RFC PATCH] tty: serial: Add 8250-core based omap driver
On Fri, 4 Jul 2014 11:57:40 -0500 Robert Nelson robertcnel...@gmail.com wrote: On Fri, Jul 4, 2014 at 11:51 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: On 07/03/2014 09:34 AM, Tony Lindgren wrote: Heh. Just to summarize the reason ttyO needs to be a separate name and device entry from ttyS is because we also have external 8250 devices on GPMC and hotplug busses. So the GPMC devices will first get a higher minor/device number. The internal serial ports should show up first. I don't see the problem (yet). If you need a separate major number (and name) like we do have it now (between ttySx and ttyOx) then one of requirements would be to tell Kconfig that one driver can be active at a time. For me the ttyS vs ttyO thing is purely cosmetic. I personally don't like that it is different on different platforms like ttymxc, ttySC, ttyTHS, … Maybe it's time to migrate them all to one name? (ttyS) Does the end user really care if they have a soc with an omap/imx serial port driver? Or do they just want to access /dev/ttySx and connect to their device? Userspace question. Actual userspace visible device naming policy belongs to udev. Alan -- 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
On Mon, Jul 07, 2014 at 05:39:26AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [140707 05:17]:
On Mon, Jul 07, 2014 at 05:20:27PM +0530, Sekhar Nori wrote:
OMAP4430 had L2 cache controller version r2p0 (per the public TRM) which
does not have this register. So unless there is a ROM API that was
introduced after OMAP4430, this would not be there even for other
OMAP4s. Public TRM of OMAP4470 does not indicate an API for this.
Before creating the patch, I checked with ROM team handling AM437x and
they denied an API to write to this register was present in AM437x ROM.
Okay, so why are we trying to write to this register then...
Ah, we have a bug in cache-l2x0.c:
#define L2X0_CACHE_ID_PART_MASK (0xf 6)
#define L2X0_CACHE_ID_RTL_MASK 0x3f
#define L310_CACHE_ID_RTL_R3P0 0x05
unsigned rev = readl_relaxed(base + L2X0_CACHE_ID)
L2X0_CACHE_ID_PART_MASK;
if (rev = L310_CACHE_ID_RTL_R2P0) {
...
if (rev = L310_CACHE_ID_RTL_R3P0) {
l2c_write_sec(L310_DYNAMIC_CLK_GATING_EN |
L310_STNDBY_MODE_EN,
base, L310_POWER_CTRL);
So, because we're masking the wrong bits, we end up with these tests
always succeeding.
So that's a NACK for the original patch, it's the wrong fix. The
right fix is to avoid writing this register by fixing the RTL masking.
Okie dokie, dropping the omap specific fix.
Here's the revision mask fix - with the existing code, the revision checks
are all useless since they would all pass irrespective of the actual
revision. (Had the L2C series been better tested rather than being largely
ignored, this may have been noticed before it was merged...) Anyway, what
isn't clear from Sekhar's message is which revision L2C310 is in the AM437x.
From: Russell King rmk+ker...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Subject: [PATCH] ARM: l2c: fix revision checking
The revision checking in l2c310_enable() was not correct; we were
masking the part number rather than the revision number. Fix this
to use the correct macro.
Fixes: 4374d64933b1 (ARM: l2c: add automatic enable of early BRESP)
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/cache-l2x0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 948f12cf6180..0b5068256baf 100644
--- 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;
if (rev = L310_CACHE_ID_RTL_R2P0) {
--
1.8.3.1
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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
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. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: l2c: squelch warning dump on power control setting
Hi,
On Mon, Jul 07, 2014 at 02:40:08PM +0100, Russell King - ARM Linux wrote:
On Mon, Jul 07, 2014 at 05:39:26AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [140707 05:17]:
On Mon, Jul 07, 2014 at 05:20:27PM +0530, Sekhar Nori wrote:
OMAP4430 had L2 cache controller version r2p0 (per the public TRM) which
does not have this register. So unless there is a ROM API that was
introduced after OMAP4430, this would not be there even for other
OMAP4s. Public TRM of OMAP4470 does not indicate an API for this.
Before creating the patch, I checked with ROM team handling AM437x and
they denied an API to write to this register was present in AM437x ROM.
Okay, so why are we trying to write to this register then...
Ah, we have a bug in cache-l2x0.c:
#define L2X0_CACHE_ID_PART_MASK (0xf 6)
#define L2X0_CACHE_ID_RTL_MASK 0x3f
#define L310_CACHE_ID_RTL_R3P0 0x05
unsigned rev = readl_relaxed(base + L2X0_CACHE_ID)
L2X0_CACHE_ID_PART_MASK;
if (rev = L310_CACHE_ID_RTL_R2P0) {
...
if (rev = L310_CACHE_ID_RTL_R3P0) {
l2c_write_sec(L310_DYNAMIC_CLK_GATING_EN |
L310_STNDBY_MODE_EN,
base, L310_POWER_CTRL);
So, because we're masking the wrong bits, we end up with these tests
always succeeding.
So that's a NACK for the original patch, it's the wrong fix. The
right fix is to avoid writing this register by fixing the RTL masking.
Okie dokie, dropping the omap specific fix.
Here's the revision mask fix - with the existing code, the revision checks
are all useless since they would all pass irrespective of the actual
revision. (Had the L2C series been better tested rather than being largely
ignored, this may have been noticed before it was merged...) Anyway, what
isn't clear from Sekhar's message is which revision L2C310 is in the AM437x.
From: Russell King rmk+ker...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Subject: [PATCH] ARM: l2c: fix revision checking
The revision checking in l2c310_enable() was not correct; we were
masking the part number rather than the revision number. Fix this
to use the correct macro.
Fixes: 4374d64933b1 (ARM: l2c: add automatic enable of early BRESP)
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/cache-l2x0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 948f12cf6180..0b5068256baf 100644
--- 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
--
balbi
signature.asc
Description: Digital signature
[GIT PULL] ARM: OMAP2+: more fixes for v3.16-rc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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/ - Roger Quadros (2): ARM: DRA7: hwmod: Fixup SATA hwmod ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss Suman Anna (1): ARM: OMAP3: PRM/CM: Add back macros used by TI DSP/Bridge driver Tero Kristo (1): ARM: OMAP2+: clock/dpll: fix _dpll_test_fint arithmetics overflow arch/arm/mach-omap2/clkt_dpll.c | 2 +- arch/arm/mach-omap2/cm-regbits-34xx.h | 3 +++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 18 +- arch/arm/mach-omap2/prm-regbits-34xx.h| 6 ++ 4 files changed, 23 insertions(+), 6 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJTusG4AAoJEMePsQ0LvSpLZvAP/i3f+F5uWBMC4gKuJr6CRf9g CbWwyjQrWjrgXKcdKjrfy+OJ8gQnc1JcPL/yhtAZYh3hI8oCNRmqRMfJ2pCmxeIK 6bb0lOHxiYe0Eymv1kk6fuuY3l/MmUXc5Ot488ogOA/pPuUugKvvKDd5xeH0nPl1 16oZM804Dky54lVVU7MCKZOm8BaB6xbBLlgpKkBnN2e5N2N5J+it91dYu4l4fFf2 cMc/CEEXVmEDWPKXQkpOhtIVcCAqVCBfdOewp7VuU/F9/DoEsqO10XE7r+qc8wCC 89Y3UfbfxOvdi+/MXRqjlNYyNlgfny7HJyZdS7DMorsqWAB+OYp/BBSFo3Ge8Qao 4Y6RCDbz7hpjOwssIXDzJeQ49vmDq2EZDwAdRdFiLoVeM0l7c70vK8yWRaM7HH1e 89ncatuKjNyrwsiyNt9euuObhs6XwwX8drkxB7IsCq4rCpjKWitwJJxpaNlvYxby Z2uA+WLBDGDRxIqKFOti7G9cKwCg3UuQfmzpwL5paBYTTVM/R51JBAlZ0OeVTvwp gSENMUAzPO6rwoyUhkgFaIAQEzJRj8nnMwV+fIh6YdwpoHM54kkXju15hJo49dbe iqOlOEiLHndzhk+z7gGalVC/WAkNK7YcGZ8Bcz1/0H1XTzKexuJ2JDGpg95mzdrE aGoUb7l0PS1KozHEoQxo =Ec2J -END PGP SIGNATURE- -- 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
Hey Tony,
This seems to be a false positive then.Please reply if it is so I can remove the
Fix me message.
Cheers Nick
On Mon, Jul 7, 2014 at 4:14 AM, Tony Lindgren t...@atomide.com wrote:
* Nicholas Krause xerofo...@gmail.com [140704 10:03]:
This patch fixes the call to ompa_cfg_reg(USB2_SPEED) in the case
that the cpu is a omap16xx and the nwires are not equal to 3.
This is most likely unsafe to do as the pin is probably
shared with some other device and we have to rely for
the bootloader to do the right thing for the board.
Regards,
Tony
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
arch/arm/mach-omap1/usb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 4118db5..17e3139 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -504,8 +504,7 @@ static u32 __init omap1_usb2_init(unsigned nwires,
unsigned alt_pingroup)
omap_cfg_reg(W9_USB2_TXEN);
omap_cfg_reg(W5_USB2_SE0);
if (nwires != 3)
- omap_cfg_reg(Y5_USB2_RCV);
- // FIXME omap_cfg_reg(USB2_SPEED);
+ omap_cfg_reg(USB2_SPEED)
} 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 00/13] uio_pruss: add support for devicetree and am33xx
On Mon, 7 Jul 2014, Andre Heider wrote:
On Sun, Jun 29, 2014 at 06:21:34PM +0200, Andre Heider wrote:
this series adds PRUv2 support to uio_pruss through devicetree, makes the
device usable on am33xx and enables it on beaglebone black.
Inspired by old patches from Matt Porter found in a downstream tree.
To archieve that this series:
* adds a flag to omap_hwmod.c to get PRUSS out of hardreset (patch 5 and 6)
...
* is the hardreset thing I did there the right thing to do? I think the
proper way would be a reset controller (which apparently doesn't yet exist
for this SoC?) and let the driver deassert/assert on probe/remove?
* the platform device path has a clk_enable() / clk_put() calls. Are those
now redundant with the introduced pm_runtime_enable() pm_runtime_disable()
calls?
Probably you only need pm_runtime_{get,put}_*() calls, unless you're
changing clock parents or rates in your driver code.
@OMAP guys: any comments? The series depends on patch 5 and 6; both touch
common hwmod code.
I'd suggest splitting the series into three independent pieces if
possible:
1. UIO code, for the UIO maintainer(s)
2. DT pieces for Tony
3. hwmod pieces for me
That way they can be cleanly merged by the respective maintainers.
As far as the hwmod piece goes, I'd be willing to merge your code as a
temporary workaround for the issue, and marking it as such; but I'd be
concerned about power management-related interactions (i.e., does the
PRUSS need to be reset upon return from deep idle states, etc.)
- Paul
--
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 3 July 2014 06:38, Ezequiel García ezequ...@vanguardiasur.com.ar wrote: On 02 Jul 02:08 PM, Dave Airlie wrote: On 2 July 2014 12:31, Darren Etheridge detheri...@ti.com wrote: On 07/01/2014 06:39 PM, Guido Martínez wrote: On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote: [snip] Otherwise I think this is a good and useful patch series. It that a Tested-by tag? :) Sure - I would prefer that the WARN_ON was silenced when the tilcdc module is removed, but the series adds improvements over what is there now. I have tested it across a few variants of AM335x boards and attached display hardware in both module form and built-in to the kernel, therefore: Tested-by: Darren Etheridge detheri...@ti.com Has someone gathered that tags and put these in a git tree by any chance? I don't think anyone has. Is that a problem? If you need a pull request with these, I can prepare something in bitbucket. Would that work you? I've picked them up manually now, so should be all fine. Thanks, Dave. -- 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
On Monday 07 July 2014 08:40 PM, Felipe Balbi wrote:
Hi,
On Mon, Jul 07, 2014 at 02:40:08PM +0100, Russell King - ARM Linux wrote:
On Mon, Jul 07, 2014 at 05:39:26AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [140707 05:17]:
On Mon, Jul 07, 2014 at 05:20:27PM +0530, Sekhar Nori wrote:
OMAP4430 had L2 cache controller version r2p0 (per the public TRM) which
does not have this register. So unless there is a ROM API that was
introduced after OMAP4430, this would not be there even for other
OMAP4s. Public TRM of OMAP4470 does not indicate an API for this.
Before creating the patch, I checked with ROM team handling AM437x and
they denied an API to write to this register was present in AM437x ROM.
Okay, so why are we trying to write to this register then...
Ah, we have a bug in cache-l2x0.c:
#define L2X0_CACHE_ID_PART_MASK (0xf 6)
#define L2X0_CACHE_ID_RTL_MASK 0x3f
#define L310_CACHE_ID_RTL_R3P0 0x05
unsigned rev = readl_relaxed(base + L2X0_CACHE_ID)
L2X0_CACHE_ID_PART_MASK;
if (rev = L310_CACHE_ID_RTL_R2P0) {
...
if (rev = L310_CACHE_ID_RTL_R3P0) {
l2c_write_sec(L310_DYNAMIC_CLK_GATING_EN |
L310_STNDBY_MODE_EN,
base, L310_POWER_CTRL);
So, because we're masking the wrong bits, we end up with these tests
always succeeding.
So that's a NACK for the original patch, it's the wrong fix. The
right fix is to avoid writing this register by fixing the RTL masking.
Okie dokie, dropping the omap specific fix.
Here's the revision mask fix - with the existing code, the revision checks
are all useless since they would all pass irrespective of the actual
revision. (Had the L2C series been better tested rather than being largely
ignored, this may have been noticed before it was merged...) Anyway, what
isn't clear from Sekhar's message is which revision L2C310 is in the AM437x.
From: Russell King rmk+ker...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Subject: [PATCH] ARM: l2c: fix revision checking
The revision checking in l2c310_enable() was not correct; we were
masking the part number rather than the revision number. Fix this
to use the correct macro.
Fixes: 4374d64933b1 (ARM: l2c: add automatic enable of early BRESP)
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/cache-l2x0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 948f12cf6180..0b5068256baf 100644
--- 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.
Thanks,
Sekhar
--
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
